System DesignObservability = khả năng suy ra trạng thái bên trong hệ thống từ output bên ngoài. Ba trụ cột bổ trợ nhau:
- Metrics — số liệu tổng hợp theo thời gian (request/s, p99 latency, error rate, CPU). Rẻ, lưu lâu, dùng cho dashboard + alerting. Trả lời "có gì bất thường không?".
- Logs — sự kiện rời rạc có timestamp, nên là structured (JSON). Trả lời "chuyện gì xảy ra ở thời điểm X?". Tốn dung lượng → cần sampling/retention.
- Traces — theo dấu một request đi qua nhiều service (mỗi chặng là một span). Trả lời "thời gian đi đâu mất?", lộ ra service nào chậm trong chuỗi.
Quy trình debug điển hình: Metric/alert báo p99 tăng → mở trace của request chậm để thấy service nghẽn → đọc log của service đó (cùng trace_id) để biết nguyên nhân.
Lưu ý:
- Correlation là chìa khóa: nhúng trace_id vào mọi log để nhảy giữa ba trụ cột.
- OpenTelemetry là chuẩn chung để instrument cả ba, tránh khóa vendor.
- Đừng nhầm monitoring (theo dõi cái đã biết) với observability (điều tra cái chưa biết).
Observability = inferring a system's internal state from external outputs. The three pillars complement each other:
- Metrics — aggregated numbers over time (req/s, p99 latency, error rate, CPU). Cheap, long retention, for dashboards + alerting. Answers "is anything abnormal?".
- Logs — discrete timestamped events, ideally structured (JSON). Answers "what happened at time X?". Storage-heavy → needs sampling/retention.
- Traces — follow one request across many services (each hop is a span). Answers "where did the time go?", exposing the slow service in a chain.
Typical debug flow: a metric/alert shows p99 rising → open a trace of a slow request to find the bottleneck service → read that service's logs (same trace_id) for the cause.
Notes:
- Correlation is key: embed trace_id in every log to jump across pillars.
- OpenTelemetry is the common standard to instrument all three, avoiding vendor lock-in.
- Don't conflate monitoring (watching known things) with observability (investigating unknowns).