Template blog

ABC là một công ty startup tại Ấn Độ, sản phẩm của họ là một hệ thống trading platform cho phép user mua sản phẩm bằng hình thức đấu giá. CEO của công ty muốn lưu những behavior của user hàng ngày như họ hay tìm kiếm từ khóa nào, hay sử dụng chức năng nào… để phục vụ cho việc phân tích hành vi user, cụ thể là Business Intelligent. Ngoài việc lưu log BI, thì log hệ thống, application cho developer debug vẫn cần được lưu trữ

Ngoài ra logs cũng cần có 1 số yêu cầu như sau

  • Các thông tin credentials không được lưu trong log
  • Log cần được rotated trong một khoảng thời gian
  • Log phải được collect và analyzed, lưu trữ trong một log collection platform duy nhất
  • Việc access vào log resources cần được bảo mật và phân quyền cho 1 số user duy nhất

Hiện tại có khá nhiều platform dành cho việc phân tích và lưu trữ log như ELK stack, Splunk, Loki Grafana, Azure log analytics workspace sau nhiều thử nghiệm và đánh giá

Splunk là logging platform tốt nhất nhưng chi phí khá cao

Loki Grafana có ưu điểm là nhẹ, dễ cài đặt nhưng khả năng phân tích tìm kiếm log còn yếu không phù hợp với bài toán BI như yêu cầu của CEO

Azure log analytics workspace chỉ phù hợp với hệ sinh thái dùng Azure

Cuối cùng ELK là giải pháp được lựa chọn cuối cùng nhờ khả năng phân tích search log của Kibana, Free opensource

Ban đầu, team dự định sử ELK theo architect truyền thống

Trên các app và service implement phần logging sử dụng framework như log4net, log4j để ghi log ra file. Trên mỗi server instance, setup filebeat agent để ship file logs tới Logstash à đẩy vào elasticsearch rồi visualize on Kibana

Tuy nhiên khi đưa vào thử nghiệm thì phát hiện 1 số vấn đề

Hệ thống có nhiều server, app khác nhau, nhiều developer, họ đang sử dụng nhiều framework logging và cách coding output log không thống nhất, dẫn đến khó khan trong việc collect logs

Mỗi khi cần thay đổi về framework logs hay logging format…, toàn bộ code logging trên các app phải thay đổi theo

Vấn đề performance của logstash khi số lượng log đẩy vào tăng lên, vì có log BI nên dung lượng log phải 20G/ngày

Team đã quyết định thay vì implement logs trực tiếp trên các app service thì viết riêng một logging service chuyên dùng để ghi logs, các app service sẽ gọi logging service này qua REST API và truyền data để service này ghi logs

Data truyền đi có format kiểu như

type LoggingJSON struct {
   Type          string                 `json:"Type" validate:"required"`
   Env           string                 `json:"Env" validate:"required"`
   App           string                 `json:"App" validate:"required"`
   Timestamp     string                 `json:"Timestamp" validate:"optional"`
   LogLevel      int                    `json:"LogLevel" validate:"required"`
   Message       string                 `json:"Message" validate:"required"`
   ...

}

Ngoài ra còn thêm 1 số field khác như elastic search index, machine id…

Log Level thì vẫn theo standard như FATAL, INFO, DEBUG .. .

Service logs khi nhận được request sẽ ghi logs ra file

Cách làm này có ưu điểm là mỗi khi có thay đổi gì về format, cách ghi logs. framework log thì chỉ cần sửa code của service logs là được, loose coupling phần logging khỏi app

Service logs, rabbitMQ, ELK được deploy trên AKS của Azure như hình dưới

Service logs được deploy lên k8s dưới dạng pod và mount với 1 azure storage volume để lưu logs. Volume này được snapshot định kì để backup và rotation sau một khoảng thời gian do admin quy định

3 1 vote
Article Rating
guest
0 Comments
Inline Feedbacks
View all comments