Logging service - part 3

Phần 2

Tiếp tục với phần cuối của chủ để logging service, bài này mô tả chi tiết hơn phải giải pháp deployment, log rotation, backup log

Như đã mô tả ở bài trước , service logs push log vào rabbitMQ, và Logstash pull logs từ rabbitMQ đẩy vào elastic search để visualize trên Kibana

Rabbit MQ

Hệ thống có nhiều microservice như Blockchain service, Realtime Hub service, API service… log của mỗi service này sẽ được đẩy vào các queue riêng biệt

Các logstash pipeline tách biệt subscribe queue tương ứng để đẩy vào elastic search

Mỗi loại logs được lưu vào ES index tương ứng trên ES ví dự như log-blockchain, log-realtime, log-api …

Cơ chế để log service push log vào queue như sau

Logging service không push thẳng log vào queue mà push log thông qua broker (Direct exchange), broker này mới push vào queue thông qua các routing key tương ứng

Có thể giải thích overview về cơ chế Broker của RabbitMQ như hình dưới, exchange có 3 hình thức là Direct (gửi thẳng tới queue qua binding key) Topic (routing the pattern) hoặc Fanout (Broadcast message tới một loạt queue)

Code C#

channel.BasicPublish(exchange: RABBIT_DEBUG_EXCHANGE,
                        routingKey: GetQueueKey(logObj.ESIndex),
                        basicProperties: null,
                        body: body);
_logger.Debug(" [x] Sent {0}", item);

Logstash

Logstash được deploy trên Azure AKS, các pipeline được lưu dưới dạng các config map vì dụ như api-log-configmap, realtime-log-configmap, blockchain-log-configmap… Mỗi khi có 1 service mới onboard, thì 1 pipeline mới được tao thêm,

Mỗi configmap được define theo format chuẩn của logstash

 input {
        rabbitmq {
        }
 }

 filter {
    }
 
output {
        elasticsearch {
       }
 }

Configmap chính của logstash khai báo toàn bộ list các pipeline của logstash

apiVersion: v1
kind: ConfigMap
metadata:
  name: logstash-configmap
  namespace: lex-elk
data:
  logstash.yml: |
    http.host: "0.0.0.0"
  
  pipelines.yml: |
    - pipeline.id: pipeline-web-api
      path.config: "/usr/share/logstash/config/api/api.conf"
    - pipeline.id: pipeline-realtime-hub
      path.config: "/usr/share/logstash/config/realtime/realtime.conf"

giaosucan@giaosucan:~/Fpt/Lex-Infra/staging$ kubectl get configmap -n lex-elk
NAME                          DATA   AGE

log-configmap                 2      39d
logstash-configmap            2      43d
logstash-realtime-configmap   1      33d
logstash-web-api-configmap    1      33d

Như vậy mỗi khi có logs push vào queue, logstash pipeline execute pull log và đẩy vào ES index tương ứng

Elastic Search

Log data được lưu trong ES dưới dạng các ES Index như đã nói ở trên . Khi deploy ES, một volume tầm 100GB được mount vào ES để lưu ES data (ES Index, document …) Volume này được backup snapshot daily/weekly bằng Azure Backup vault.

Do số lượng log được đẩy vào hàng ngày rất lớn nên cần phải xem xét đến log rotation. Các logs cũ hơn 30 ngày sẽ được xóa để tiết kiệm disk space bằng công cụ curator cuả ES. Tool này levearge ES API để thực hiện xóa logs trên ES. Tuy nhiên nếu xóa log theo kiểu delete documents API thì performance rất chậm và không phải là best practice . Cho nên các xóa ở đây là xóa thẳng ES index theo pattern

log-api-<YYYY.MM.DD>

log-realtime-<YYYY.MM.DD>

Tức là thay vì tạo một ES index cố định cho từng service thì logstash sẽ push logs vào ES theo index

output {
        elasticsearch {
          id => "es-web-api"
          index => "log-api-%{+YYYY.MM.dd}"

Trên Kibana sẽ visualize log theo patten log-api-* , log-realtime-*

Một cronjob được tạo trên AKS, để thực hiện xóa các ES index older hơn 30 ngày dùng curator . Configuration của curator cũng được lưu thành configmap tương tự như logstash pipeline

Đây là toàn bộ giải pháp về logging (app) trên ELK dùng cho developer debug

Tuy nhiên đối với log cho BI analytics, giải pháp cần có 1 số thay đổi cho phù hợp

Hóng series tiếp theo