Đây là ba trụ cột của observability. Chúng trả lời các câu hỏi khác nhau: metrics cho bạn biết rằng có gì đó sai, logs cho biết chuyện gì đã xảy ra, và traces cho biết thời gian hoặc lỗi rơi vào trong một luồng phân tán.
Đây là ba trụ cột của observability. Chúng trả lời các câu hỏi khác nhau: metrics cho bạn biết rằng có gì đó sai, logs cho biết chuyện gì đã xảy ra, và traces cho biết thời gian hoặc lỗi rơi vào trong một luồng phân tán.
METRICS các con số tổng hợp theo thời gian (counter, gauge, histogram)
→ rẻ, cardinality thấp, tuyệt cho xu hướng & ALERTING
→ vd. error rate = 2%, p99 latency = 800ms
LOGS các sự kiện rời rạc, có timestamp, kèm chi tiết (thường là JSON có cấu trúc)
→ ngữ cảnh phong phú để DEBUG một request cụ thể
→ vd. {"level":"error","user":123,"msg":"payment declined"}
TRACES đường đi của một request qua các service, kèm thời gian mỗi span
→ cho thấy PHÂN RÃ latency và chỗ một lời gọi fail
→ vd. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alert: "checkout p99 latency nhảy lên 2s" → bạn biết CÓ vấn đề
2. TRACE một request chậm: 1.8s trong 2s nằm ở inventory service
→ bạn biết nó Ở ĐÂU
3. LOGS của inventory service tại thời điểm đó: "slow query: missing index"
→ bạn biết CHUYỆN GÌ xảy ra
Metrics thu hẹp bạn về một triệu chứng và khung thời gian; traces khoanh vùng nó về một service hay lời gọi; logs cho nguyên nhân chính xác. Lao thẳng vào logs mà không có metrics nghĩa là dò mù.
Metrics được tổng hợp nên vẫn rẻ kể cả ở quy mô lớn — lý tưởng cho dashboard và alert luôn-bật. Logs và traces là theo từng sự kiện và đắt, nên thường được lấy mẫu (sample) và truy vấn theo nhu cầu trong lúc điều tra.
Dùng sai trụ cột làm tốn thời gian: bạn không thể alert hiệu quả trên log thô (quá nhiễu, quá tốn kém), và không thể debug một request fail cụ thể từ một metric tổng hợp. Biết rằng metrics phát hiện, traces khoanh vùng, và logs giải thích cho bạn một lối đi nhanh, lặp lại được từ "có gì đó sai" tới nguyên nhân gốc.