Logging service - bài toán BI

Tiếp tục phần 3, bài viết này tiếp tục đề cập đến 1 số vấn đề liên quan đến logging. Trong hệ thống có nhiều loại log như log của application, log của platform, log container…Logging service chỉ log được application log là loại log do developer implement trong code. Thực tế khi triển khai, có những trường hợp fatal error ví dụ như application crash, app logs không thể gửi tới ELK. Do đó cần phải có giải pháp collect cả những loại log của platform, OS để gửi tới ELK

System logs

Do application được buid thành docker image và deploy lên Azure app service nên development team sử dụng Event Hub, một real-time data ingestion service của azure, tương tự như kafka của Linkedin

Tổng cộng có khoảng hơn 20 app services chạy trên hệ thống, mỗi app service được config để push container logs vào event hub

Một logstash pipeline được config để get event logs từ EventHub rồi push vào Elasticsearch

input {
      azure_event_hubs {
        event_hub_connections => ["Endpoint="]
        threads => 8
        decorate_events => true
        consumer_group => "logstash"        
      }    
    }

BI logs

Bên cạnh log truyền thống dùng để debug như app log, container logs, một loại log nữa cần phải collect đó là BI logs phụ vụ cho data analysis

Có 4 loại BI logs cần collect

User Experiences: Track every interaction of users toward the application

Security: Track any user who tries to crawl data from the application

Compliances: Track event user authentication, import export data

Business analysis : Track cái giao dịch của user..

Giải pháp collect data cho BI có khá nhiều, đặc biệt Azure cung cấp giải pháp trọn gói như ở dưới với công cụ như Azure Synapse

Một số hệ thống BI trên GCP sử dụng giải pháp BigQuery

Tuy nhiên các giải pháp trên chi phí khá tốn kém và thường áp dụng cho hệ thống lớn, big data. Đối với bài toán hiện tại, dữ liệu chưa lớn, giới hạn về budget, cần có giải pháp low cost

ELK vẫn được sử dụng để lưu trữ log BI, 4 loại logs trên được lưu trong 4 indices của elasticsearch là bi-event-ux-*, bi-even-sec-*, bi-event-compliance-*, bi-event-analystic-*

Logging service vẫn được sử dụng để đẩy log BI vào ELK

Một điều quan trọng đội BA cần làm đó là xây dựng bộ BI Specs, hiểu nhanh là define danh sách các event cần collect trong hệ thống

Một event được định nghĩa dưới dạng 1 json object . Bao gồm 2 thuộc tính chính

Common propeties: Những thuộc tính chung mà event nào cũng phải có, vd như event name, event type, createdTime, user.

Specific propeties: Những thuộc tính mà chỉ có event đó có ví dụ như event user upload (upload file nào, dung lượng bao nhiêu) sẽ có thuộc tính khác với event user login (login bằng user nào, login success hay fail, retry mấy lần)

Ví dụ về 1 event BI payload, cần define đúng theo format để BI pipeline có thể ingest vào elasticsearch

{
  "type": "UX",
  "event": "DATA_UPLOAD",
  "eventId": "bfe65c20-eeb5-4525-9070-4343eb",
  "timestamp": "2019-04-18T00:00:25.425Z",
  "userId": "69612829944896",
  "properties": {
    "fileName": "VYZ",
    "fileType": "pdf",
    "fileSize": "30",
    "result" : {
         "success" : false,
         "message"  : "the file size exceed limitation"
    }
}

Để define ra được event specs, BA team cần đặt ra những business question, những thông tin nào cần collect

Sau khi event specs được build, developer căn cứ vào event specs để generate ra payload rồi call logging service API để ghi event vào ELK.

Data engineer visualize BI event trên Kibana để thực hiện phân tích data

Có thể nói so với giải pháp BI sẵn có trên Azure hay AWS, thì cách trên không hiệu quả bằng tuy nhiên bù lại đó là cost saving, và đủ để giải quyết nhu cầu của hệ thống ban đầu