監控:四個黃金訊號

上一篇說 SLI 是量到的可靠度數字——而那些數字,就來自監控。但監控最容易走歪的地方,是把它當成「收集越多數字越好」,結果儀表板上一百個圖,真出事時反而找不到重點。這篇講 Google 給的精煉答案:如果一個服務只能盯四個指標,盯哪四個——四個黃金訊號。

監控其實只要回答兩個問題

先把目的講清楚。監控不是為了好看的儀表板,是為了回答兩個問題:「現在壞了嗎?」(即時偵測)和「快壞了嗎?」(趨勢預警)。抓住這兩個問題,你就不會掉進「什麼都量、但什麼都看不出來」的陷阱。而能同時回答這兩題、又幾乎涵蓋所有使用者面向服務健康的,就是這四個訊號:

四個各自的重點:

• Latency 延遲:請求要多久才回。有個陷阱——一定要把成功和失敗的延遲分開看。失敗請求可能很快(直接回 500)也可能很慢(卡到 timeout),混進成功請求裡算,平均會被嚴重誤導。
• Traffic 流量:系統現在多忙,通常是 QPS 或每秒交易數。它是理解另外三個的背景——延遲變高,是因為流量暴增還是系統出問題?
• Errors 錯誤:失敗請求的比例。要小心「隱性失敗」——回了 200、但內容是錯的;或「政策失敗」——回得太慢,對你就算失敗。
• Saturation 飽和度:系統有多滿、離極限多近(CPU、記憶體、連線池用了幾成)。它最難量,卻最能預警——因為它告訴你「還能撐多久」,而不是「已經倒了」。

別看平均,平均會騙你

第二個一定要建立的觀念:看延遲(或任何分佈)時,別看平均,看分佈——尤其是 p99。 平均最會騙人,因為它把長尾藏起來了:

這也解釋了上一篇為什麼 SLI/SLO 幾乎都用 percentile(「99% 的請求 < 300ms」),而不是「平均 < 300ms」。平均對你好看,p99 對使用者誠實。

對「症狀」告警,黑箱 + 白箱一起用

最後兩個要點,順帶帶到下一篇。第一,監控要盯「症狀」而不是「原因」:使用者在乎的是「網頁打不開」(症狀),不是「某台 DB 的 CPU 高」(原因——它可能根本沒影響到任何人)。所以黃金訊號才好用,因為它們天生是症狀。第二,黑箱與白箱要一起用:黑箱監控從外面像使用者一樣打你的服務(「現在到底通不通」),白箱監控從裡面看內部指標(出事時幫你找「為什麼」)。黑箱抓症狀、白箱查原因——兩個配著用。至於「什麼時候該把人吵醒」,是下一篇告警的主題。

反思

「只能量四個」的紀律,比「什麼都量」有用

我看過的監控問題,九成不是「量得太少」,而是「量得太多、太雜」——幾百個圖表沒人真的看得懂,真出事時大家在儀表板海裡撈半天找不到重點。四個黃金訊號的價值,不在它列了哪四個,而在它逼你聚焦:先把這四個顧到位,再談其他。這跟我做任何事的習慣一樣——先抓住最關鍵的那幾個,而不是貪心地什麼都要。監控的成熟,是敢於只看少數幾個真正重要的訊號。

平均是最會騙人的統計

「別看平均、看 p99」這件事,我覺得遠不只適用於監控。平均的本質就是把差異抹平,而真正的問題往往就藏在被抹平的那條尾巴裡——延遲如此,成本、回應時間、甚至團隊負載都如此。少數極端值(那 1% 等了一秒的使用者、那幾個爆量的請求)才是會咬你的東西,平均卻讓它們隱形。所以我現在看任何指標,反射動作是問一句:「這是平均嗎?分佈長怎樣?尾巴呢?」——被平均安慰過太多次,就學乖了。

對症狀告警,而不是對原因

這個原則改變了我設計監控的方式。以前會忍不住對每個內部指標(CPU、記憶體、佇列長度)都設告警,結果半夜被一堆「其實沒影響使用者」的原因吵醒。後來想通:該叫醒人的是症狀(使用者受影響了),原因是查問題時才需要的線索。 把告警綁在症狀(黃金訊號、SLI)上,不但少了一堆假警報,也讓「什麼時候該緊張」跟「使用者痛不痛」對齊了。這正好是下一篇要展開的:告警,到底該在什麼條件下把人吵醒。