Observability dựa trên ba trụ cột — log, metric, và trace — và mục tiêu là trả lời "cái gì sai và tại sao" cho một hệ thống quá lớn để kiểm tra bằng tay. Ở quy mô lớn, chiến lược xoay quanh sự tương quan (correlation), lấy mẫu (sampling), và chi phí.
| Trụ cột | Trả lời | Công cụ |
|---|
| Metric | Có gì đó sai không? (tỷ lệ, độ trễ) | Prometheus, Grafana |
| Trace | Sai ở đâu trong luồng? | OpenTelemetry, Jaeger |
| Log | Chính xác điều gì đã xảy ra? | ELK, Loki |
Metric cảnh báo ─▶ trace khoanh đúng service chậm ─▶ log giải thích nguyên nhân
(rộng) (đường đi) (chi tiết)
Trace/correlation ID phải xuyên suốt qua các nhãn metric, dòng log, và span, nhờ đó bạn có thể xoay trục giữa chúng.
dòng log: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ cùng id xuất hiện trong trace + metric
✓ Chuẩn hóa: OpenTelemetry xuyên mọi service
✓ Dùng log có cấu trúc (JSON) — truy vấn được, không chỉ grep
✓ Sample trace (ví dụ giữ tất cả lỗi + 1% thành công) để kiểm soát chi phí
✓ Định nghĩa SLO và cảnh báo theo triệu chứng (độ trễ/tỷ lệ lỗi), không phải nhiễu
✓ Phương pháp RED/USE cho dashboard (Rate, Errors, Duration)
Log mọi thứ ở 100% là không kham nổi và nhấn chìm tín hiệu. Hãy sample, cấu trúc hóa, và cảnh báo theo SLO thay vào đó.
Với hàng trăm service, bạn không thể SSH vào và nhìn — observability là cách duy nhất để hiểu hành vi production.
Chiến lược thắng cuộc là có tương quan, có lấy mẫu, và do SLO dẫn dắt: nó phơi bày vấn đề thật nhanh chóng mà không làm bạn phá sản vì lưu trữ telemetry hay chôn vùi đội on-call trong nhiễu.