Monitoring Microservices — Log, Metric & Correlation ID (BMS)
Mở đầu
Khi hệ thống mới chỉ có vài service, muốn biết nó có ổn hay không, mở terminal gõ vài lệnh là đủ. Nhưng một khi đã chia thành hàng chục service, mỗi cái lại có database và máy chủ riêng, chuyện "xem hệ thống đang chạy thế nào" trở nên hóc búa khác hẳn. Chapter 10 của cuốn "Building Microservices" bàn về đúng nỗi đau này: làm sao quan sát được một hệ phân tán khi mà lỗi có thể nằm ở bất kỳ mắt xích nào, và dữ liệu lại rải rác khắp nơi.
Sam Newman gọi đây là bài toán observability — khả năng hiểu được trạng thái bên trong của hệ thống chỉ dựa vào đầu ra bên ngoài (log, metric, trace). Với backend engineer, đây kỹ năng "sống còn": hệ thống càng tản mạn, mắt càng phải sắc.
Ba trụ của observability: Log, Metric và Trace
Ảnh: AlphaTradeZone — Pexels
Ba loại dữ liệu quan sát chính mà bất kỳ hệ phân tán nào cũng cần, mỗi loại trả lời một câu hỏi khác nhau. Log trả lời "cụ thể đã xảy ra chuyện gì" — một sự kiện rời rạc kèm thời điểm, chi tiết. Metric trả lời "tổng thể đang ra sao" — con số gộp lại theo thời gian như số request/giây, latency p99, tỷ lệ lỗi, có thể vẽ đồ thị và đặt cảnh báo. Trace trả lời "một request đã đi qua những đâu" — hành trình của một lời gọi xuyên qua nhiều service.
Hình dung như một phi vụ ship hàng: log giống biên bản từng điểm dừng, metric giống báo cáo tổng số chuyến trong ngày, còn trace giống bản đồ chỉ đúng con đường mà kiện hàng đó đã đi. Thiếu bất kỳ loại nào, bức tranh sẽ mù mờ. Nhiều đội mới làm microservices chỉ cài đúng metric rồi tưởng đã đủ — chỉ đến khi gặp sự cố khó nuốt mới nhận ra cần cả trace và log mới tìm ra gốc rễ.
Correlation ID — Nối các log rời rạc thành một câu chuyện
Ảnh: Daniil Komov — Pexels
Vấn đề với log trong microservices: mỗi service ghi log riêng, nên một request duy nhất có thể làm phát sinh mấy chục dòng log nằm rải rác ở các máy khác nhau. Làm sao gom hết về một mối để biết chuyện gì đã xảy ra? Câu trả lời kinh điển mà Sam Newman nhấn mạnh là correlation ID — một ID duy nhất sinh ra ở trạm đầu tiên đón request, rồi truyền xuống mọi service khác theo chuỗi gọi.
Mỗi service nhận request kèm ID này, ghi nó vào log của mình. Khi điều tra sự cố, chỉ cần query theo correlation ID là thấy trọn vẹn hành trình — thay vì mò mẫm tìm những dòng log vô danh. Kỹ thuật này đơn giản nhưng cực kỳ mạnh: có thể bắt đầu chỉ bằng một trường trong header HTTP, rồi lan dần sang message từ queue, ghi vào user agent, thậm chí trả về cho client để hỗ trợ viên dán ID lên khi gọi hotline.
Chuẩn hoá log & tập trung hoá việc gom log
Ảnh: Rafael Minguet Delgado — Pexels
Log chỉ có ích khi đọc được. Sam Newman khuyên nên thống nhất format log giữa các service — ví dụ dùng cấu trúc JSON để máy parse dễ dàng, nhiều trường chung như timestamp, service name, log level, correlation ID. Đừng để mỗi team tự do ghi theo kiểu riêng, bởi lúc mở dashboard tìm lỗi giữa đêm, sự đồng nhất này cứu cả team.
Song song đó là thói quen tập trung hoá log: dù service chạy ở đâu cũng đẩy log về một nơi chung (như Elasticsearch, Loki) để tìm kiếm toàn cục. Kèm theo là vấn đề metric correlation — đừng chỉ gộp log lại, hãy phối giữa các nguồn dữ liệu: thấy metric giảm mạnh thì phải truy xuất được log và trace tương ứng để tìm ra nguyên nhân. Cảnh báo chỉ nên đánh thức người trực khi có biểu hiện thật sự bất thường, đừng gào lên vì những thứ ambient vô thưởng vô phạt.
Key Takeaways
- Observability gồm ba trụ: log (điều gì đã xảy ra), metric (tổng thể ra sao), trace (đi qua những đâu) — thiếu một trong ba là bức tranh mù mờ.
- Correlation ID giúp gom log rải rác của một request xuyên nhiều service thành một câu chuyện duy nhất — điều tra sự cố nhanh gấp bội.
- Chuẩn hoá format log (JSON, trường chung) và tập trung hoá log về một chỗ là điều kiện tiên quyết để log thực sự hữu dụng.
- Metric correlation: phối log + metric + trace với nhau để từ cảnh báo đi thẳng tới gốc rễ vấn đề.
📋 Phụ lục thuật ngữ
| Thuật ngữ | Ý nghĩa |
|---|---|
| Observability | Khả năng hiểu trạng thái bên trong hệ thống qua dữ liệu đầu ra bên ngoài |
| Metric | Dữ liệu số gộp theo thời gian (request/giây, latency, tỷ lệ lỗi), dùng vẽ đồ thị và cảnh báo |
| Correlation ID | ID duy nhất sinh ở trạm đầu, truyền qua các service để nối log của một request |
| Log aggregation | Tập trung hoá log từ mọi service về một kho chung để tìm kiếm toàn cục |
| Trace | Lịch sử hành trình của một request xuyên qua nhiều service |
| Distributed tracing | Kỹ thuật theo dõi và tái dựng hành trình request trong hệ phân tán |
| Metric correlation | Phối hợp log, metric, trace để truy vết sự cố từ dấu hiệu tổng quan tới nguyên nhân cụ thể |
Kết
Giám sát một hệ microservices không phải chuyện mua thêm công cụ xịn, mà là xây cho đủ ba trụ quan sát và nối chúng lại bằng correlation ID. Làm đúng những điều tưởng nhỏ này sẽ giúp bạn không bị mù khi hệ thống phình to. Có được đôi mắt quan sát rồi, vấn đề tiếp theo đặt ra là an toàn — làm sao để giữa hàng chục service gọi nhau qua mạng, dữ liệu vẫn được bảo vệ đúng chuẩn. Chapter tiếp theo của series sẽ nói về security và mô hình zero trust.