Tweet
Distributed Logging – Vì sao Logging đã trở thành một bài toán kiến trúc trong kỷ nguyên Cloud Native?
Ngày trước, logging là một việc khá đơn giản. Ứng dụng chạy trên một máy chủ hoặc một thiết bị mạng, log sẽ được ghi vào một vài file trên hệ điều hành. Khi có sự cố thì chúng ta sẽ SSH vào server và đọc log. Nhưng trong thế giới Cloud, Container, Kubernetes và Microservices ngày nay, câu chuyện đã hoàn toàn khác. Một request của người dùng có thể đi qua Load Balancer, API Gateway, nhiều Microservices, Database, Cache, Message Queue và các dịch vụ bên thứ ba. Nếu xảy ra lỗi, câu hỏi không còn là "log nằm ở đâu?" mà là "làm sao ghép được toàn bộ câu chuyện từ hàng trăm hệ thống khác nhau?" Mời các bạn đọc tiếp nhé!
Tại sao Distributed Logging trở nên quan trọng?
Trong môi trường phân tán, ứng dụng có thể chạy trên nhiều máy chủ khác nhau hoặc đang chạy trong container có vòng đời ngắn. Chưa kể, giải pháp của chúng ta còn tự động scale up hoặc scale down và liên tục tạo mới hoặc hủy các instance. Điều này khiến việc lưu log cục bộ trở nên không còn phù hợp vì log có thể biến mất ngay khi container bị xóa. Vì vậy, tất cả log cần được tập trung về một hệ thống lưu trữ trung tâm để phục vụ giám sát, phân tích và điều tra sự cố. Ngoài ra, một hệ thống phân tán còn phải đối mặt với nhiều thách thức mới phát sinh như:
Để có khả năng quan sát (Observability) đầy đủ, hệ thống hiện đại thường thu thập nhiều loại log khác nhau. Sau đây, chúng ta hãy cùng điểm qua các loại logs. Application Logs
Đây là nguồn thông tin quan trọng nhất. Application log ghi nhận trạng thái ứng dụng, các thay đổi trạng thái, những request thành công hoặc thất bại, các user input, Exception và Error... Nhờ đó chúng ta biết chính xác điều gì đang xảy ra bên trong ứng dụng. System Logs
Nhiều khi ứng dụng không hề lỗi.
Ví dụ Ứng dụng đột ngột biến mất. Application log không ghi nhận gì bất thường. Khi kiểm tra System Log thì chúng ta mới phát hiện Linux Kernel đã kích hoạt OOM Killer và buộc phải kill process do thiếu RAM. Đây là lý do System Log luôn cần được thu thập cùng với Application Log. Thông thường bao gồm Syslog trên Linux/Unix, Windows Event Log trên Windows
Database Logs
Database thường cung cấp Error Logs, Query Logs, Security Logs, Slow Query Logs. Các log này giúp phân tích hiệu năng và xử lý sự cố liên quan đến truy vấn dữ liệu.
Web Access Logs
Web Access Log ghi nhận Source IP, User-Agent, URL được truy cập, Response Code, Cookie, Thông tin Request.... Đây vừa là nguồn dữ liệu vận hành vừa là nguồn dữ liệu bảo mật cực kỳ giá trị.
Event Logs
Trong kiến trúc Event-Driven Architecture (EDA), Event Log giúp theo dõi luồng sự kiện giữa các thành phần trong hệ thống.
Đây là nguồn dữ liệu quan trọng khi điều tra các hệ thống sử dụng Kafka, RabbitMQ, NATS hoặc các Event Bus khác.
Kiến trúc Distributed Logging hiện đại
Một hệ thống logging hiện đại thường gồm nhiều tầng. Đầu tiên là các Collector Agent nằm gần nguồn sinh log. Ví dụ có thể kể ra như Filebeat, Fluent Bit, Fluentd, Vector.... Các agent này thu thập log và gửi về hệ thống trung tâm. Tiếp theo là tầng Aggregation.
Nhiệm vụ của tầng này là chuẩn hóa dữ liệu, phân tích log, gắn metadata, chuyển tiếp đến hệ thống lưu trữ. Sau đó dữ liệu được lưu vào hệ thống Search hoặc Object Storage. Tiếp theo là Indexing giúp Full-text Search, Field Search, Correlation Search. Cuối cùng là tầng Analytics và Alerting. Tầng này liên tục kiểm tra log để phát hiện tấn công bảo mật, lỗi hệ thống, sự cố ứng dụng, các hành vi bất thường trong vận hành.
Những Best Practice quan trọng
Sử dụng Correlation ID
Một giao dịch có thể tạo ra Web Access Log, Application Log, Database Log... Nếu không có Correlation ID, việc ghép các log này lại gần như không thể. Correlation ID giúp theo dõi toàn bộ hành trình của một request xuyên suốt hệ thống.
Đồng bộ thời gian
Trong môi trường phân tán, không bao giờ tin tưởng nhiều đồng hồ khác nhau. Tất cả hệ thống nên đồng bộ bằng NTP, Chrony, Enterprise Time Source. (Nhờ các anh system/network triển khai giúp phần này). Nếu timestamp sai lệch, quá trình điều tra sự cố sẽ trở nên vô cùng khó khăn.
Xử lý Logging Failure
Không nên giả định rằng log luôn gửi thành công. Collector nên có bộ nhớ đệm (buffer), có local cache, hỗ trợ retry. Khi mạng hoặc logging server phục hồi, log sẽ được gửi lại để tránh mất dữ liệu.
ELK Stack – Bộ công cụ phổ biến nhất
Một trong những nền tảng logging phổ biến nhất hiện nay là ELK Stack. ELK bao gồm:
Elasticsearch
Lưu trữ, tìm kiếm và phân tích log.
Logstash
Thu thập, chuyển đổi và xử lý log.
Kibana
Dashboard trực quan hóa dữ liệu. Ngoài ra còn có:
Filebeat
Thu thập log file.
Metricbeat
Thu thập metrics như CPU, Memory, Disk, Process. Luồng hoạt động điển hình: Filebeat → Logstash → Elasticsearch → Kibana.
Góc nhìn DevSecOps
Một sai lầm rất phổ biến là xem hệ thống logging chỉ là công cụ vận hành. Thực tế, logging thường chứa Tài khoản người dùng, Token, Session ID, Địa chỉ IP, Thông tin giao dịch và các dữ liệu nhạy cảm. Đã từng có nhiều sự cố Elasticsearch công khai trên Internet khiến kẻ tấn công truy cập được toàn bộ dữ liệu log của doanh nghiệp. Vì vậy hệ thống logging phải được bảo vệ như một tài sản trọng yếu của tổ chức, bao gồm phân quyền truy cập, mã hóa, giám sát và kiểm toán liên tục.
Kết THÚC bài 1 về logging
Trong kiến trúc Monolithic, logging chỉ là một chức năng hỗ trợ. Nhưng trong kiến trúc Microservices, Cloud Native và Event-Driven hiện đại, logging đã trở thành một thành phần nền tảng của Observability. Nếu không có Distributed Logging, việc troubleshooting, performance analysis, security investigation và vận hành hệ thống ở quy mô lớn gần như không thể thực hiện hiệu quả. (còn tiếp).
(Nguồn: Tổng hợp và biên dịch từ tài liệu "Effective Distributed Application Logging Strategies")
Ngày trước, logging là một việc khá đơn giản. Ứng dụng chạy trên một máy chủ hoặc một thiết bị mạng, log sẽ được ghi vào một vài file trên hệ điều hành. Khi có sự cố thì chúng ta sẽ SSH vào server và đọc log. Nhưng trong thế giới Cloud, Container, Kubernetes và Microservices ngày nay, câu chuyện đã hoàn toàn khác. Một request của người dùng có thể đi qua Load Balancer, API Gateway, nhiều Microservices, Database, Cache, Message Queue và các dịch vụ bên thứ ba. Nếu xảy ra lỗi, câu hỏi không còn là "log nằm ở đâu?" mà là "làm sao ghép được toàn bộ câu chuyện từ hàng trăm hệ thống khác nhau?" Mời các bạn đọc tiếp nhé!
Tại sao Distributed Logging trở nên quan trọng?
Trong môi trường phân tán, ứng dụng có thể chạy trên nhiều máy chủ khác nhau hoặc đang chạy trong container có vòng đời ngắn. Chưa kể, giải pháp của chúng ta còn tự động scale up hoặc scale down và liên tục tạo mới hoặc hủy các instance. Điều này khiến việc lưu log cục bộ trở nên không còn phù hợp vì log có thể biến mất ngay khi container bị xóa. Vì vậy, tất cả log cần được tập trung về một hệ thống lưu trữ trung tâm để phục vụ giám sát, phân tích và điều tra sự cố. Ngoài ra, một hệ thống phân tán còn phải đối mặt với nhiều thách thức mới phát sinh như:
- Nhiều định dạng log khác nhau.
- Nhiều nguồn dữ liệu khác nhau.
- Mất kết nối mạng.
- Log không được gửi thành công.
- Đồng bộ thời gian giữa các hệ thống.
- Khả năng tìm kiếm và tương quan sự kiện giữa nhiều dịch vụ.
Để có khả năng quan sát (Observability) đầy đủ, hệ thống hiện đại thường thu thập nhiều loại log khác nhau. Sau đây, chúng ta hãy cùng điểm qua các loại logs. Application Logs
Đây là nguồn thông tin quan trọng nhất. Application log ghi nhận trạng thái ứng dụng, các thay đổi trạng thái, những request thành công hoặc thất bại, các user input, Exception và Error... Nhờ đó chúng ta biết chính xác điều gì đang xảy ra bên trong ứng dụng. System Logs
Nhiều khi ứng dụng không hề lỗi.
Ví dụ Ứng dụng đột ngột biến mất. Application log không ghi nhận gì bất thường. Khi kiểm tra System Log thì chúng ta mới phát hiện Linux Kernel đã kích hoạt OOM Killer và buộc phải kill process do thiếu RAM. Đây là lý do System Log luôn cần được thu thập cùng với Application Log. Thông thường bao gồm Syslog trên Linux/Unix, Windows Event Log trên Windows
Database Logs
Database thường cung cấp Error Logs, Query Logs, Security Logs, Slow Query Logs. Các log này giúp phân tích hiệu năng và xử lý sự cố liên quan đến truy vấn dữ liệu.
Web Access Logs
Web Access Log ghi nhận Source IP, User-Agent, URL được truy cập, Response Code, Cookie, Thông tin Request.... Đây vừa là nguồn dữ liệu vận hành vừa là nguồn dữ liệu bảo mật cực kỳ giá trị.
Event Logs
Trong kiến trúc Event-Driven Architecture (EDA), Event Log giúp theo dõi luồng sự kiện giữa các thành phần trong hệ thống.
Đây là nguồn dữ liệu quan trọng khi điều tra các hệ thống sử dụng Kafka, RabbitMQ, NATS hoặc các Event Bus khác.
Kiến trúc Distributed Logging hiện đại
Một hệ thống logging hiện đại thường gồm nhiều tầng. Đầu tiên là các Collector Agent nằm gần nguồn sinh log. Ví dụ có thể kể ra như Filebeat, Fluent Bit, Fluentd, Vector.... Các agent này thu thập log và gửi về hệ thống trung tâm. Tiếp theo là tầng Aggregation.
Nhiệm vụ của tầng này là chuẩn hóa dữ liệu, phân tích log, gắn metadata, chuyển tiếp đến hệ thống lưu trữ. Sau đó dữ liệu được lưu vào hệ thống Search hoặc Object Storage. Tiếp theo là Indexing giúp Full-text Search, Field Search, Correlation Search. Cuối cùng là tầng Analytics và Alerting. Tầng này liên tục kiểm tra log để phát hiện tấn công bảo mật, lỗi hệ thống, sự cố ứng dụng, các hành vi bất thường trong vận hành.
Những Best Practice quan trọng
Sử dụng Correlation ID
Một giao dịch có thể tạo ra Web Access Log, Application Log, Database Log... Nếu không có Correlation ID, việc ghép các log này lại gần như không thể. Correlation ID giúp theo dõi toàn bộ hành trình của một request xuyên suốt hệ thống.
Đồng bộ thời gian
Trong môi trường phân tán, không bao giờ tin tưởng nhiều đồng hồ khác nhau. Tất cả hệ thống nên đồng bộ bằng NTP, Chrony, Enterprise Time Source. (Nhờ các anh system/network triển khai giúp phần này). Nếu timestamp sai lệch, quá trình điều tra sự cố sẽ trở nên vô cùng khó khăn.
Xử lý Logging Failure
Không nên giả định rằng log luôn gửi thành công. Collector nên có bộ nhớ đệm (buffer), có local cache, hỗ trợ retry. Khi mạng hoặc logging server phục hồi, log sẽ được gửi lại để tránh mất dữ liệu.
ELK Stack – Bộ công cụ phổ biến nhất
Một trong những nền tảng logging phổ biến nhất hiện nay là ELK Stack. ELK bao gồm:
Elasticsearch
Lưu trữ, tìm kiếm và phân tích log.
Logstash
Thu thập, chuyển đổi và xử lý log.
Kibana
Dashboard trực quan hóa dữ liệu. Ngoài ra còn có:
Filebeat
Thu thập log file.
Metricbeat
Thu thập metrics như CPU, Memory, Disk, Process. Luồng hoạt động điển hình: Filebeat → Logstash → Elasticsearch → Kibana.
Góc nhìn DevSecOps
Một sai lầm rất phổ biến là xem hệ thống logging chỉ là công cụ vận hành. Thực tế, logging thường chứa Tài khoản người dùng, Token, Session ID, Địa chỉ IP, Thông tin giao dịch và các dữ liệu nhạy cảm. Đã từng có nhiều sự cố Elasticsearch công khai trên Internet khiến kẻ tấn công truy cập được toàn bộ dữ liệu log của doanh nghiệp. Vì vậy hệ thống logging phải được bảo vệ như một tài sản trọng yếu của tổ chức, bao gồm phân quyền truy cập, mã hóa, giám sát và kiểm toán liên tục.
Kết THÚC bài 1 về logging
Trong kiến trúc Monolithic, logging chỉ là một chức năng hỗ trợ. Nhưng trong kiến trúc Microservices, Cloud Native và Event-Driven hiện đại, logging đã trở thành một thành phần nền tảng của Observability. Nếu không có Distributed Logging, việc troubleshooting, performance analysis, security investigation và vận hành hệ thống ở quy mô lớn gần như không thể thực hiện hiệu quả. (còn tiếp).
(Nguồn: Tổng hợp và biên dịch từ tài liệu "Effective Distributed Application Logging Strategies")
Attached Files