Metrics 告訴你出事了、logs 告訴你那一刻發生什麼、traces 告訴你慢/錯在哪一段。三者回答不同問題，互補而非擇一；現代趨勢是用高基數的結構化事件把三者串起來。
🧠 Intuition
TIP
偵錯像查案：metrics 是「警報器響了」，traces 是「兇手往哪條路逃」，logs 是「現場監視器的逐格畫面」。先用 metrics 發現、用 traces 定位、再用 logs 看細節。
- Metrics：數值時間序列（QPS、延遲、錯誤率）。便宜、可長期保存、適合告警與儀表板；但是聚合後遺失個體脈絡。
- Logs：離散事件記錄。脈絡最豐富；但量大、貴、難跨服務關聯。結構化（JSON）才好查。
- Traces：一個請求跨服務的完整路徑與各段耗時。分散式系統定位瓶頸的關鍵；需要 context 傳遞（trace ID）。
⚖️ Tradeoffs
三套各自獨立的系統 — 傳統做法
- Metrics 進 Prometheus、logs 進 ELK、traces 進 Jaeger，各管各的。
- 好處：每套工具都成熟、各自最佳化儲存。
- 痛點：事故時要在三個 UI 間人腦關聯（這條 trace 對應哪些 log？），MTTR 被切換成本拖長。
高基數結構化事件（wide events）— 現代取向
- 每個請求發一筆寬事件，帶上幾十個維度（user_id、region、版本、耗時…），traces/metrics 由事件「導出」。
- 好處：可在事後任意維度切片問「沒預設過的問題」（unknown-unknowns），不必預先決定要量什麼。
- 代價：高基數儲存與查詢成本高，需專門後端（如 columnar store）；採樣策略要設計好。
🔑 Takeaways
- 三本柱回答不同問題：metrics「有沒有事」、traces「哪一段」、logs「細節」。
- 別把它們當競品——好的工作流是 metrics 告警 → traces 定位 → logs 看現場。
- 三柱會「失聯」是傳統痛點；高基數結構化事件讓你事後任意切片，回答沒預設過的問題。
2026-07-01
- Q：「可觀測性」跟傳統「監控（monitoring）」差在哪？只是換個潮一點的詞？
- A：監控偏向「對預先知道會出事的指標設告警」（known-unknowns），回答你已經想得到要問的問題。可觀測性追求的是事後能對系統任意切片，回答「沒預想過的問題」（unknown-unknowns）——這正是高基數寬事件的價值。三本柱是手段，可觀測性是「能不能問出沒預設過的問題」這個能力。