Tweet
Distributed Logging: Kiến trúc 5 tầng giúp quan sát hệ thống Microservices hiệu quả
Khi hệ thống còn là Monolith, logging thường chỉ đơn giản là ghi dữ liệu vào file trên máy chủ. Nhưng khi chuyển sang kiến trúc Microservices, Cloud Native và Kubernetes, hàng chục hoặc hàng trăm service có thể tạo ra hàng triệu log mỗi ngày. Lúc này, logging không còn là một tính năng phụ trợ mà đã trở thành một thành phần cốt lõi của tính khả kiến Observability. Một hệ thống Distributed Logging được thiết kế đúng cách thường chia thành 5 giai đoạn chính.
1. Collection Stage – Thu thập log
Đây là bước đầu tiên của toàn bộ quy trình. Các Collector Agent được triển khai gần nguồn sinh log nhất, thường nằm trên các máy chủ vật lý, máy ảo, Container, Kubernetes Node. Collector có thể hoạt động theo nhiều cách như theo dõi file log, theo dõi sự thay đổi của file, cung cấp API để ứng dụng gửi log hoặc Subscribe vào các nguồn log. Mục tiêu của giai đoạn này là thu thập dữ liệu càng gần nguồn phát sinh càng tốt.
2. Forwarding Stage – Chuyển tiếp log
Sau khi thu thập, log sẽ được gửi đến một Log Aggregator.
Log Aggregator đóng vai trò tập trung dữ liệu từ nhiều nguồn khác nhau như từ Application, từ Database, từ Operating System, Web Server, Event Queue... Đây là bước biến hàng trăm nguồn log phân tán thành một luồng dữ liệu tập trung.
3. Storage Stage – Lưu trữ log
Các log sau đó được ghi vào hệ thống lưu trữ. Tùy theo quy mô hệ thống, nơi lưu trữ có thể là Local Storage, Shared Storage, Object Storage, Distributed File System. Tại đây doanh nghiệp thường thiết lập các chính sách Retention Period, Log Rotation, Data Lifecycle, Archiving Policy... Ví dụ các bạn có thể thấy các chính sách như Giữ log vận hành trong 30 ngày, giữ log bảo mật trong 1 năm, chuyển log cũ sang Object Storage giá rẻ....
4. Indexing Stage – Đánh chỉ mục
Đây là bước giúp việc tìm kiếm log trở nên thực tế. Thay vì đọc từng file log thủ công, hệ thống sẽ tạo chỉ mục theo Thời gian, Ứng dụng, theo địa chỉ Máy chủ, Mức độ nghiêm trọng, Correlation ID...
Sau khi được đánh chỉ mục, các công cụ như Elasticsearch có thể thực hiện Full Text Search, Analytics, Dashboard, Trend Analysis
trong thời gian gần như tức thì.
5. Alerting Stage – Cảnh báo
Đây là tầng thông minh nhất của hệ thống logging. Nó liên tục phân tích log để phát hiện các lỗi bất thường, các tấn công bảo mật, Service bị gián đoạn, tăng đột biến lưu lượng, Không nhận được log từ một máy chủ nào đó. ...Khi phát hiện sự kiện bất thường, hệ thống có thể thực hiện các hành động như Gửi Email, Gửi Slack, Gửi Teams, Tạo Incident Ticket, Kích hoạt Automation Workflow....
Những Best Practice quan trọng trong Distributed Logging
Chuẩn hóa nền tảng logging
Trong môi trường Microservices, các nhóm phát triển có thể sử dụng Java, Python, Go, Node.js. Tuy nhiên nền tảng logging nên được thống nhất. Nếu mỗi service sử dụng một giải pháp logging khác nhau, việc quản lý và phân tích log sẽ trở nên cực kỳ phức tạp.
Sử dụng Correlation ID
Một giao dịch có thể đi qua:
User → API Gateway → Service A → Service B → Database
Nếu không có Correlation ID, việc truy vết lỗi gần như là ác mộng.
Correlation ID được gắn vào mọi log liên quan đến cùng một request để dễ dàng theo dõi toàn bộ hành trình của giao dịch.
Đây là kỹ thuật gần như bắt buộc trong kiến trúc Microservices hiện đại.
Không tin tưởng nhiều nguồn thời gian
Một vấn đề rất hay gặp là lệch giờ giữa các máy chủ.
Ví dụ:
09:01:05 User được cập nhật
09:01:03 User được tạo
Rõ ràng đây là điều vô lý. Để tránh hiện tượng này, toàn bộ hạ tầng cần đồng bộ thời gian bằng NTP, Chrony, Enterprise Time Service
Và tốt nhất nên xem một nguồn thời gian là "nguồn sự thật" duy nhất.
Luôn giả định hệ thống logging sẽ hỏng
Đây là tư duy DevOps rất quan trọng. Logging Server cũng là một dịch vụ và hoàn toàn có thể gặp sự cố. Collector Agent nên tự Buffer dữ liệu, Cache cục bộ, Retry khi kết nối phục hồi. Nếu không, bạn sẽ mất chính những log quan trọng nhất vào lúc hệ thống gặp sự cố.
Ghi log có ngữ cảnh
Thông báo lỗi kiểu Error occurred gần như vô dụng vì chúng không cung cấp thông tin hữu ích. Một log tốt nên bao gồm:
Hỗ trợ Query Log
Giá trị thực sự của logging không nằm ở việc lưu trữ log mà nằm ở khả năng trả lời câu hỏi. Ví dụ:
ELK Stack – Bộ công cụ phổ biến nhất cho Distributed Logging
Một trong những giải pháp được sử dụng rộng rãi nhất hiện nay là ELK Stack. ELK bao gồm ba thành phần chính:
Elasticsearch
Là công cụ lưu trữ, tìm kiếm và phân tích dữ liệu dựa trên Apache Lucene. Khả năng Full Text Search cực kỳ mạnh mẽ giúp truy vấn hàng tỷ bản ghi log.
Logstash
Là tầng thu thập và xử lý log. Logstash nhận dữ liệu từ nhiều nguồn, chuyển đổi định dạng và chuyển tiếp đến hệ thống lưu trữ.
Kibana
Là giao diện trực quan hóa. Kibana cho phép Xây dựng Dashboard, Theo dõi thời gian thực, Điều tra sự cố, Phân tích xu hướng.
Ngoài ra ELK còn sử dụng các Collector Agent gọi là Beats.
Phổ biến nhất gồm:
Application
↓
Beats
↓
Logstash
↓
Elasticsearch
↓
Kibana
Góc nhìn DevOps
Nếu phải chọn một thuộc tính quan trọng nhất của Distributed Logging, câu trả lời không phải là định dạng dữ liệu, tính toàn vẹn dữ liệu hay khả năng tìm kiếm. Đó là Data Aggregation.
Bởi vì giá trị lớn nhất của Distributed Logging là đưa toàn bộ log từ hàng trăm hệ thống khác nhau về một nơi duy nhất. Chỉ khi dữ liệu được tập trung, chúng ta mới có thể thực hiện tìm kiếm, phân tích, cảnh báo và điều tra sự cố một cách hiệu quả.
Đây cũng chính là lý do mà trong các nền tảng DevOps, SRE, AIOps và DevSecOps hiện đại, hệ thống Logging luôn được xem là một phần không thể thiếu của nền tảng Observability.
Khi hệ thống còn là Monolith, logging thường chỉ đơn giản là ghi dữ liệu vào file trên máy chủ. Nhưng khi chuyển sang kiến trúc Microservices, Cloud Native và Kubernetes, hàng chục hoặc hàng trăm service có thể tạo ra hàng triệu log mỗi ngày. Lúc này, logging không còn là một tính năng phụ trợ mà đã trở thành một thành phần cốt lõi của tính khả kiến Observability. Một hệ thống Distributed Logging được thiết kế đúng cách thường chia thành 5 giai đoạn chính.
1. Collection Stage – Thu thập log
Đây là bước đầu tiên của toàn bộ quy trình. Các Collector Agent được triển khai gần nguồn sinh log nhất, thường nằm trên các máy chủ vật lý, máy ảo, Container, Kubernetes Node. Collector có thể hoạt động theo nhiều cách như theo dõi file log, theo dõi sự thay đổi của file, cung cấp API để ứng dụng gửi log hoặc Subscribe vào các nguồn log. Mục tiêu của giai đoạn này là thu thập dữ liệu càng gần nguồn phát sinh càng tốt.
2. Forwarding Stage – Chuyển tiếp log
Sau khi thu thập, log sẽ được gửi đến một Log Aggregator.
Log Aggregator đóng vai trò tập trung dữ liệu từ nhiều nguồn khác nhau như từ Application, từ Database, từ Operating System, Web Server, Event Queue... Đây là bước biến hàng trăm nguồn log phân tán thành một luồng dữ liệu tập trung.
3. Storage Stage – Lưu trữ log
Các log sau đó được ghi vào hệ thống lưu trữ. Tùy theo quy mô hệ thống, nơi lưu trữ có thể là Local Storage, Shared Storage, Object Storage, Distributed File System. Tại đây doanh nghiệp thường thiết lập các chính sách Retention Period, Log Rotation, Data Lifecycle, Archiving Policy... Ví dụ các bạn có thể thấy các chính sách như Giữ log vận hành trong 30 ngày, giữ log bảo mật trong 1 năm, chuyển log cũ sang Object Storage giá rẻ....
4. Indexing Stage – Đánh chỉ mục
Đây là bước giúp việc tìm kiếm log trở nên thực tế. Thay vì đọc từng file log thủ công, hệ thống sẽ tạo chỉ mục theo Thời gian, Ứng dụng, theo địa chỉ Máy chủ, Mức độ nghiêm trọng, Correlation ID...
Sau khi được đánh chỉ mục, các công cụ như Elasticsearch có thể thực hiện Full Text Search, Analytics, Dashboard, Trend Analysis
trong thời gian gần như tức thì.
5. Alerting Stage – Cảnh báo
Đây là tầng thông minh nhất của hệ thống logging. Nó liên tục phân tích log để phát hiện các lỗi bất thường, các tấn công bảo mật, Service bị gián đoạn, tăng đột biến lưu lượng, Không nhận được log từ một máy chủ nào đó. ...Khi phát hiện sự kiện bất thường, hệ thống có thể thực hiện các hành động như Gửi Email, Gửi Slack, Gửi Teams, Tạo Incident Ticket, Kích hoạt Automation Workflow....
Những Best Practice quan trọng trong Distributed Logging
Chuẩn hóa nền tảng logging
Trong môi trường Microservices, các nhóm phát triển có thể sử dụng Java, Python, Go, Node.js. Tuy nhiên nền tảng logging nên được thống nhất. Nếu mỗi service sử dụng một giải pháp logging khác nhau, việc quản lý và phân tích log sẽ trở nên cực kỳ phức tạp.
Sử dụng Correlation ID
Một giao dịch có thể đi qua:
User → API Gateway → Service A → Service B → Database
Nếu không có Correlation ID, việc truy vết lỗi gần như là ác mộng.
Correlation ID được gắn vào mọi log liên quan đến cùng một request để dễ dàng theo dõi toàn bộ hành trình của giao dịch.
Đây là kỹ thuật gần như bắt buộc trong kiến trúc Microservices hiện đại.
Không tin tưởng nhiều nguồn thời gian
Một vấn đề rất hay gặp là lệch giờ giữa các máy chủ.
Ví dụ:
09:01:05 User được cập nhật
09:01:03 User được tạo
Rõ ràng đây là điều vô lý. Để tránh hiện tượng này, toàn bộ hạ tầng cần đồng bộ thời gian bằng NTP, Chrony, Enterprise Time Service
Và tốt nhất nên xem một nguồn thời gian là "nguồn sự thật" duy nhất.
Luôn giả định hệ thống logging sẽ hỏng
Đây là tư duy DevOps rất quan trọng. Logging Server cũng là một dịch vụ và hoàn toàn có thể gặp sự cố. Collector Agent nên tự Buffer dữ liệu, Cache cục bộ, Retry khi kết nối phục hồi. Nếu không, bạn sẽ mất chính những log quan trọng nhất vào lúc hệ thống gặp sự cố.
Ghi log có ngữ cảnh
Thông báo lỗi kiểu Error occurred gần như vô dụng vì chúng không cung cấp thông tin hữu ích. Một log tốt nên bao gồm:
- Timestamp
- Service Name
- Function Name
- Correlation ID
- Stack Trace
- Client IP
- User Agent
- Error Details
Hỗ trợ Query Log
Giá trị thực sự của logging không nằm ở việc lưu trữ log mà nằm ở khả năng trả lời câu hỏi. Ví dụ:
- Service nào lỗi nhiều nhất trong giờ cao điểm?
- API nào có thời gian phản hồi lâu nhất?
- Người dùng từ quốc gia nào tạo nhiều lỗi nhất?
- Sau khi deploy phiên bản mới thì tỷ lệ lỗi thay đổi ra sao?
ELK Stack – Bộ công cụ phổ biến nhất cho Distributed Logging
Một trong những giải pháp được sử dụng rộng rãi nhất hiện nay là ELK Stack. ELK bao gồm ba thành phần chính:
Elasticsearch
Là công cụ lưu trữ, tìm kiếm và phân tích dữ liệu dựa trên Apache Lucene. Khả năng Full Text Search cực kỳ mạnh mẽ giúp truy vấn hàng tỷ bản ghi log.
Logstash
Là tầng thu thập và xử lý log. Logstash nhận dữ liệu từ nhiều nguồn, chuyển đổi định dạng và chuyển tiếp đến hệ thống lưu trữ.
Kibana
Là giao diện trực quan hóa. Kibana cho phép Xây dựng Dashboard, Theo dõi thời gian thực, Điều tra sự cố, Phân tích xu hướng.
Ngoài ra ELK còn sử dụng các Collector Agent gọi là Beats.
Phổ biến nhất gồm:
- Filebeat: Thu thập log file
- Metricbeat: Thu thập CPU, Memory, Disk, Process
- Packetbeat: Thu thập lưu lượng mạng
- Auditbeat: Thu thập sự kiện bảo mật
Application
↓
Beats
↓
Logstash
↓
Elasticsearch
↓
Kibana
Góc nhìn DevOps
Nếu phải chọn một thuộc tính quan trọng nhất của Distributed Logging, câu trả lời không phải là định dạng dữ liệu, tính toàn vẹn dữ liệu hay khả năng tìm kiếm. Đó là Data Aggregation.
Bởi vì giá trị lớn nhất của Distributed Logging là đưa toàn bộ log từ hàng trăm hệ thống khác nhau về một nơi duy nhất. Chỉ khi dữ liệu được tập trung, chúng ta mới có thể thực hiện tìm kiếm, phân tích, cảnh báo và điều tra sự cố một cách hiệu quả.
Đây cũng chính là lý do mà trong các nền tảng DevOps, SRE, AIOps và DevSecOps hiện đại, hệ thống Logging luôn được xem là một phần không thể thiếu của nền tảng Observability.
Attached Files