監控不等於可觀測性：儀表板全綠，使用者正在客訴

「監控」和「可觀測性」常被當成同義詞換著用，但它們回答的是兩種形狀完全不同的問題。分清楚這件事，才知道為什麼多加二十張儀表板救不了你。

監控：預先定義好的問題集合

監控的運作方式是：你先想到一個可能出錯的地方，然後為它做一個指標和一條告警。

「CPU 會不會滿？」        → 收 CPU 使用率 + 告警 > 80%
「服務會不會噴 500？」    → 收錯誤率 + 告警 > 1%
「磁碟會不會滿？」        → 收使用率 + 告警 > 90%

這些都是已知的未知（known unknowns）：你知道這件事可能發生，只是不知道何時發生。監控在這一類問題上非常有效，而且應該做好。

可觀測性：能不能回答一個你昨天沒想到的問題

這是未知的未知（unknown unknowns）。它的形狀長這樣：

「為什麼只有使用某張特定銀行卡、金額超過三萬、
  又剛好被導到新版風控的那批請求會失敗？」

沒有任何一張事先做好的儀表板會有這個維度組合。而如果你的回答是「我加個 log 再上線一次看看」，那就代表你的系統在這個問題上是不可觀測的——因為你必須改程式才能提問。

為什麼這個分界很實際

• 監控的產出是「告警」：它告訴你「有事發生了」。做得好可以把 MTTD（發現時間）壓低。
• 可觀測性的產出是「回答問題的能力」：它讓你在事發之後能一路追下去。它影響的是 MTTR（修復時間）。
• 兩者都要，而且順序是先監控再可觀測性——連「有事」都不知道的時候，能問任意問題也沒用。

一個容易誤解的地方

可觀測性不是「收集更多資料」。無差別地把所有東西都收起來，只會得到一堆昂貴又查不動的資料（這一章最後會算這筆帳）。它的關鍵是「維度」與「可關聯性」：資料裡有沒有足夠的維度讓你切分，以及不同來源的資料能不能串成一條線索（這是這一軌的第三條主線，本章倒數第二節會展開）。

三本柱人人會背，但真正該記的不是「它們各是什麼」，而是它們的成本隨著什麼東西成長——因為這決定了什麼資訊該放哪一邊。

Metrics：便宜，但維度是乘法

一個指標記錄的是「數值隨時間的變化」。它已經被聚合過了：一億次請求和一千次請求，只要維度組合一樣，儲存成本幾乎相同。

Logs：什麼都能記，但每一筆都要付錢

日誌保留了完整的上下文，是最靈活的一種。代價是它與流量成正比：QPS 翻倍，日誌帳單就翻倍。所以日誌的核心問題永遠是「記什麼、記多久、怎麼取樣」（ch04 專講）。

Traces：唯一能回答「時間花在哪」的東西

在單體服務裡，一句慢 SQL 用 db ch01 的方法就能查。但在五個服務串起來的鏈路裡，「這個請求花了 3 秒」這件事，metrics 只會告訴你每個服務各自的延遲分佈——它沒辦法告訴你這一次的 3 秒是在哪一跳被吃掉的。那是 trace 存在的唯一理由（ch05 專講）。

由成本模型推出的一條實用規則

同一套系統，可以從兩個位置觀察，而它們會給出不同的答案——當兩者矛盾時，永遠相信外面那個。

白箱：從系統內部看

• 應用程式自己吐出的指標（QPS、錯誤率、GC 時間、連線池使用率）。
• 優點：資訊豐富，能直接指向原因，是排查根因的主力。
• 盲點：它只涵蓋「請求有進到你的程式」的那部分。如果請求根本沒進來（DNS 解析失敗、負載平衡器把流量丟到已死的節點、TLS 憑證過期、CDN 設定錯誤），你的白箱指標會顯示「一切正常，甚至流量還變少了，負載更輕鬆了」。

黑箱：從使用者的位置看

• 從外部真的發一個請求進去，量它成不成功、花多久（合成監控／探針）。
• 它是唯一能證明「使用者現在能不能用」的東西。
• 缺點是頻率有限、成本較高，而且只覆蓋你寫的那幾條路徑。

推論：SLO 要用黑箱視角定義

這是這一軌後面（ch06）會反覆用到的一條原則：

❌ 「應用程式回傳 5xx 的比例 < 0.1%」
     —— 請求沒進來的時候，這個數字永遠漂亮

✅ 「從使用者的位置量，付款請求在 2 秒內成功完成的比例 > 99.9%」
     —— 不管卡在哪一層，只要使用者做不到，它就算失敗

這也是這一軌的第二條主線：症狀優先於原因。SLI 與告警都要從「使用者感受到什麼」出發，而不是從「機器上有哪些數字可以收」出發。機器指標是拿來找原因的，不是拿來定義「好不好」的。

兩者的分工

「我該收哪些指標？」這個問題有三套現成答案，它們不是競爭關係，而是分別對應不同的觀測對象。

四個黃金訊號（Google SRE）—— 面向服務

• 延遲（Latency）：請求花多久。成功與失敗的延遲一定要分開量——失敗通常很快（例如立刻回 400），混在一起會把平均值拉低，讓你看不出真正的問題。
• 流量（Traffic）：多少請求。它是其他指標的分母，也是判斷「是不是量變了」的依據。
• 錯誤（Errors）：失敗比例。注意「回了 200 但內容是錯的」也算錯誤——這種最難抓。
• 飽和度（Saturation）：離滿還有多遠。最容易被忽略也最有預測價值——它是唯一能讓你在爆炸之前知道的訊號。

RED —— 面向請求驅動的服務

Rate（每秒請求）、Errors（錯誤率）、Duration（延遲分佈）。等於黃金訊號拿掉飽和度，最適合微服務與 API：每個服務都用同一組三個指標，儀表板長得一模一樣，換服務不用重新學怎麼看。

USE —— 面向資源

Utilization（使用率）、Saturation（飽和／排隊）、Errors（錯誤）。適用於 CPU、記憶體、磁碟、網路卡、還有連線池與執行緒池。

怎麼組合

對外的 API／每個微服務  → RED（＋飽和度）
機器、連線池、執行緒池、佇列 → USE
面向使用者的關鍵旅程    → 黑箱探針 + 之後的 SLI（ch06）

先把 RED 舖滿所有服務，再對關鍵資源補 USE。這兩層蓋完，大部分「有沒有事」的問題就答得出來了——剩下的「為什麼」交給 trace 與 log。

如果要選一個「害最多人誤判」的東西，那就是平均值。而它幾乎是所有預設儀表板的預設選項。

一組數字

1000 次請求：
  970 次  →  50 毫秒
   30 次  →  30 秒（逾時）

平均回應時間 = (970×0.05 + 30×30) / 1000 ≈ 0.95 秒

儀表板上顯示「平均 950 毫秒」，看起來只是有點慢。但真實情況是每 33 個使用者就有一個完全用不了。

該看的是分位數

• p50（中位數）：典型使用者的體驗。
• p95 / p99：倒楣的那群人的體驗。SLO 通常訂在這裡（ch06）。
• p999：在高流量系統才有意義；QPS 100 的服務看 p999 是在看雜訊。
• max：對抓「有沒有極端案例」有用，但它極易被單一異常值主導，不適合當告警依據。

比分位數更根本的一件事：分佈可能是多峰的

就算你看了 p99，仍然可能被騙。當系統有兩種以上的行為模式時，分位數會混在一起：

快取命中的請求：  5 毫秒（佔 90%）
快取沒中的請求：800 毫秒（佔 10%）

p50 = 5ms、p95 ≈ 800ms —— 中間那段其實不存在任何請求

看到 p50 和 p99 差距極大時，不要想「怎麼把 p99 壓下來」，要先想「是不是有兩群不同的請求被混在一起量了」。正確的做法是拆維度（依端點、依快取命中與否、依客戶類型分開量）——這正是第一節說的「維度」為什麼是可觀測性的關鍵。

還有一個要早點知道的坑

徵狀

週五晚上八點，客服累積了十幾則「付款一直失敗」的訊息。而工程團隊看到的是：

• 所有服務的錯誤率 0.02%（正常水位）。
• 延遲 p99 正常，甚至比平常低一點。
• CPU、記憶體、資料庫、佇列全部正常。
• 沒有任何一條告警觸發。
• 總交易量比上週同時段少了 3%——但週五晚上本來就會波動，沒人覺得奇怪。

診斷

先做唯一能繞過所有內部指標的事：用使用者的身分，從外面走一次那條路徑。

為什麼所有監控都沒響

• 全部是白箱指標：沒有任何一個觀測點站在使用者的位置。
• 告警都是「比率型」：錯誤數 / 總請求數。分子分母同時消失時，比率不會動。
• 健康檢查只驗證 process 活著：/health 回 200，而它走的是內網、不經過那張憑證。
• 流量下降沒有告警：大家只告警「太多」，很少告警「太少」。

修法

教訓

很多團隊三樣都有了，卻還是查不動問題。原因通常不是資料不夠，而是三份資料之間沒有橋——每次排查都要在三個系統之間靠人腦與複製貼上接力。

正確的使用順序

橋要怎麼搭（三個具體的做法）

• trace_id 貫穿全部：每一筆日誌都要帶上當前的 trace_id 與 span_id。這是最重要的一條，而在 Spring 專案裡它幾乎是免費的（ch05／ch08 會做）。
• Exemplar：讓 metrics 的資料點掛上一個「代表性 trace 的 id」。這樣在 Grafana 上看到 p99 的那個突起，可以直接點進去看那一次的 trace——它就是第 1 步到第 2 步之間的那座橋（ch03 會設定它）。
• 統一的標籤語彙：三邊的 service.name、env、version 要用同一套命名（OpenTelemetry 的 semantic conventions 就是在做這件事，ch05 講）。否則你會在 metrics 裡叫 payment-svc、在 log 裡叫 payment，然後無法自動關聯。

從哪裡開始建：從使用者旅程往回推

不要從「有哪些指標可以收」開始——那會得到一堆沒人看的儀表板。從使用者做的事情往回推：

① 列出關鍵旅程：登入、瀏覽商品、下單、付款、查訂單
② 每條旅程定義「成功」是什麼（含時間上限）  → 未來的 SLI（ch06）
③ 為每條旅程做黑箱探針                    → 「壞了沒」
④ 沿著旅程經過的每個服務舖 RED             → 「壞在哪一段」
⑤ 對關鍵資源補 USE                        → 「為什麼壞」
⑥ 把 trace_id 串起來                      → 讓上面四層可以互相導航

這個順序的好處是：每一步都對應一個真實的問題，而不是對應一個工具的功能清單。

這一章講了很多「應該要有」的東西。這一節講它們的帳單——因為可觀測性系統很容易變成整個架構裡最貴的一套系統（ch08 會把這筆帳完整算一次）。

五筆帳

• 儲存與查詢：日誌與 trace 的量與流量成正比。高流量服務的可觀測性帳單超過運算本身的成本，是常見的事，不是異常。
• 維度爆炸：metrics 的成本是乘法。一個看似無害的 label 可以讓時序數翻幾百倍——下一章整章都在講這件事。
• 效能開銷：儀器化不是免費的。同步寫日誌會阻塞請求執行緒；trace 的 span 建立與匯出要 CPU 與記憶體；細到每個方法都插樁的 profiling 可能吃掉個位數百分比的效能。
• 人的成本：儀表板會腐化。改了服務、改了指標名稱，卻沒人維護那張圖——而一張顯示錯誤資料的儀表板，比沒有儀表板更危險，因為它會讓人做出有信心的錯誤判斷。
• 告警疲勞：這是最隱形的成本。當一半的告警不需要行動，人就會開始忽略全部的告警——包括真的那一次（ch07 專講）。

這一章的方法看不到的東西

• 它不會告訴你「多少算好」。p99 是 300 毫秒——好還是不好？沒有 SLO 就沒有答案，只有感覺（ch06）。
• 它不會告訴你什麼時候該被叫醒。有異常不等於要處理，這是告警設計的問題（ch07）。
• 它看不到「沒發生的事」。排程沒有跑、訊息沒有被消費、對帳檔沒有產生——這些故障沒有任何一筆資料會出現，只能靠「預期它應該出現」的反向告警來抓。

把這一章收成三句

下一章進入實作：Prometheus 的資料模型只有一句話，但那句話決定了它會不會在某天早上把你的記憶體吃光。