Cách xây dựng hệ thống logging tập trung cho microservices

Hệ thống logging tập trung gom log từ mọi service, container và máy chủ về một nơi để tìm kiếm, lọc và cảnh báo. Với microservices, đây gần như là điều bắt buộc: một request của người dùng có thể đi qua năm sáu service, và nếu log nằm rải rác trên từng container (vốn có thể biến mất khi restart), việc điều tra sự cố trở thành đoán mò. Một hệ thống tốt gồm bốn phần: log có cấu trúc với mã định danh request, agent thu thập, kho lưu trữ có chỉ mục và giao diện truy vấn kèm cảnh báo.

Những gì cần đạt được

Trước khi chọn công cụ, xác định yêu cầu:

• Tìm toàn bộ log của một request qua mọi service chỉ bằng một mã.
• Lọc theo service, môi trường, mức độ, khoảng thời gian, người dùng.
• Thời gian từ lúc ghi log đến lúc tìm thấy được ngắn (vài giây đến vài chục giây).
• Lưu đủ lâu cho điều tra và yêu cầu kiểm toán, nhưng chi phí kiểm soát được.
• Không làm lộ dữ liệu nhạy cảm như mật khẩu, token, số thẻ.

Viết log đúng cách ngay từ ứng dụng

Log có cấu trúc

Thay vì dòng văn bản tự do, ghi log dạng JSON với các trường cố định: thời gian (ISO 8601, UTC), mức độ, tên service, phiên bản, môi trường, thông điệp, cùng các trường ngữ cảnh như mã đơn hàng, mã người dùng. Log có cấu trúc cho phép lọc chính xác "mọi lỗi của service thanh toán với mã đối tác X" mà không phải viết biểu thức chính quy.

Correlation ID và trace ID

Mỗi request khi vào hệ thống (tại API gateway) được gán một mã duy nhất, truyền qua header cho mọi service phía sau và qua metadata của tin nhắn trong hàng đợi. Mọi dòng log đều kèm mã này. Chuẩn W3C Trace Context (header traceparent) và OpenTelemetry giúp làm việc này thống nhất giữa các ngôn ngữ, đồng thời liên kết log với trace.

Chọn mức độ log hợp lý

Lỗi phổ biến là log ERROR cho những việc bình thường (người dùng nhập sai mật khẩu), khiến cảnh báo bị nhiễu và đội dần bỏ qua.

Không log dữ liệu nhạy cảm

Che hoặc loại bỏ mật khẩu, token, số thẻ, số CMND/CCCD trước khi ghi. Tốt nhất là xử lý ở thư viện logging dùng chung với danh sách trường bị che, và thêm một lớp lọc tại agent thu thập để dự phòng.

Kiến trúc thu thập và lưu trữ

Luồng điển hình:

1. Ứng dụng ghi log ra stdout/stderr (chuẩn với container), không tự gửi qua mạng.
2. Agent chạy trên mỗi node (Fluent Bit, Vector, Filebeat, OpenTelemetry Collector) đọc log, gắn metadata (tên pod, namespace, node), lọc, che dữ liệu nhạy cảm.
3. Bộ đệm (tùy chọn) như Kafka giữ log khi kho lưu trữ chậm hoặc bảo trì, tránh mất log lúc cao điểm. Bài so sánh RabbitMQ, Kafka và Redis Pub/Sub giải thích vì sao Kafka hợp cho vai trò này.
4. Kho lưu trữ có chỉ mục phục vụ truy vấn.
5. Giao diện để tìm kiếm, dashboard và cảnh báo.

Chọn kho lưu trữ log

Với Loki, tránh dùng giá trị có số lượng lớn (mã người dùng, mã request) làm nhãn vì sẽ làm bùng nổ số luồng dữ liệu; để chúng trong nội dung log và lọc lúc truy vấn.

Kiểm soát chi phí

Log có xu hướng tăng nhanh hơn lưu lượng nghiệp vụ. Một vài biện pháp:

• Chia tầng lưu trữ: 7 đến 30 ngày ở kho nóng để truy vấn nhanh, lâu hơn chuyển sang object storage rẻ, chỉ khôi phục khi cần.
• Lấy mẫu log mức INFO cho các endpoint lưu lượng cực lớn như health check, giữ nguyên 100% log lỗi.
• Loại bỏ log trùng lặp, stack trace lặp lại hàng nghìn lần trong một phút.
• Theo dõi dung lượng log theo service, cảnh báo khi một service đột nhiên ghi gấp nhiều lần bình thường (thường là dấu hiệu lỗi).

Từ log đến cảnh báo và bảo mật

Log là một trong ba trụ cột của khả năng quan sát (observability) cùng metrics và traces. Không nên cảnh báo dựa trên từng dòng log lỗi, vì sẽ bị nhiễu; thay vào đó đếm tỷ lệ lỗi trong khoảng thời gian và kết hợp với chỉ số như mô tả trong bài xây dựng hệ thống monitoring cho production.

Log cũng là nguồn dữ liệu bảo mật quan trọng: đăng nhập thất bại liên tục, truy cập từ địa chỉ lạ, thay đổi quyền quản trị. Những cuộc dò mật khẩu hàng loạt vào dịch vụ đăng nhập từ xa, như trường hợp được phân tích trong bài về tấn công dò mật khẩu RDP vào doanh nghiệp, thường lộ ra rất sớm nếu log xác thực được gom về và có quy tắc cảnh báo.

Với log phục vụ kiểm toán (ai sửa dữ liệu gì, khi nào), cần lưu tách riêng, hạn chế quyền xóa và có thời gian lưu theo yêu cầu nội bộ hoặc pháp lý.

Checklist triển khai

1. Thống nhất định dạng log JSON và thư viện logging dùng chung cho mọi service.
2. Thêm correlation ID tại gateway và truyền qua mọi lời gọi, tin nhắn.
3. Triển khai agent thu thập trên mọi node, có lọc dữ liệu nhạy cảm.
4. Chọn kho lưu trữ theo quy mô và ngân sách, đặt chính sách lưu giữ.
5. Tạo dashboard theo service và các truy vấn mẫu cho sự cố thường gặp.
6. Diễn tập: chọn một lỗi giả định và thử tìm nguyên nhân chỉ bằng log.