為什麼需要方法論#

大多數團隊的監控起步都很類似：裝上監控工具，然後「能收集什麼就收集什麼」。CPU、記憶體、磁碟、網路……儀表板上密密麻麻幾十張圖表，看起來很專業。

然後某天服務掛了，值班工程師盯著那幾十張圖表，不知道該看哪一張。

這就是缺乏方法論的代價。指標收集得再多，如果沒有結構化的思考框架，你在事故當下依然會迷失方向。方法論的價值不在於告訴你「要監控什麼指標」，而是告訴你「要先看什麼、再看什麼、用什麼邏輯推導」。

以下介紹三種業界最廣泛使用的監控方法論。它們各有不同的適用範圍，理解它們的差異才能選對工具。

USE Method#

提出者：Brendan Gregg（Netflix 效能工程師）

適用對象：基礎設施資源（CPU、記憶體、磁碟、網路介面、匯流排等）

USE 代表三個維度：

Utilization（使用率）#

資源在一段時間內被使用的比例。例如 CPU 使用率 80% 代表在觀測期間，CPU 有 80% 的時間在工作。

• 使用率高不一定代表有問題，但它提供了一個基準線
• 當使用率持續接近 100%，通常意味著該資源即將成為瓶頸

Saturation（飽和度）#

資源無法再處理而被排隊等待的工作量。例如 CPU 的 Run Queue Length、磁碟的 I/O Wait Queue。

• 飽和度是比使用率更敏感的預警指標
• 即使使用率看起來不高，如果飽和度持續上升，代表資源已經在排隊了

Errors（錯誤）#

資源層級的錯誤事件數量。例如網路介面的 CRC 錯誤、磁碟的讀寫錯誤、記憶體的 ECC 錯誤。

• 很多基礎設施錯誤是靜默的 ── 系統不會直接告訴你硬碟正在壞掉，但錯誤計數器會持續增加

USE Method 的使用方式是：對每一種資源，都檢查 U、S、E 三個維度。這提供了一個系統性的掃描清單，確保你不會遺漏任何資源的異常。

USE 的優勢與侷限#

• 優勢：提供了一個簡單、系統化的資源檢查清單，特別適合排查效能問題的初期階段
• 侷限：只關注資源層級，無法直接反映使用者體驗。CPU 使用率正常不代表使用者的請求延遲正常

Four Golden Signals#

提出者：Google SRE Book

適用對象：服務層級的監控 ── 任何接受請求並回傳回應的服務

Google SRE 團隊在《Site Reliability Engineering》一書中提出，如果你只能監控四件事，就監控這四個：

Latency（延遲）#

處理一個請求所需的時間。

• 關鍵區分：必須分開追蹤成功請求和失敗請求的延遲。一個快速回傳的錯誤（例如 500 Internal Server Error 在 2ms 內回傳）會把整體延遲拉低，掩蓋真實的效能問題
• 建議追蹤分位數而非平均值：P50 反映典型體驗，P95/P99 反映尾端延遲

Traffic（流量）#

系統承受的需求量。

• 對 Web 服務來說，通常是每秒 HTTP 請求數
• 對訊息佇列來說，可能是每秒入列的訊息數
• 流量指標讓你理解系統的負載水位，也是其他指標的參照背景 ── 延遲上升時，先看流量是否也上升了

Errors（錯誤）#

請求失敗的比率。

• 顯性錯誤：HTTP 5xx 回應碼
• 隱性錯誤：HTTP 200 但回應內容不正確，或是回應時間超過 SLA 定義的閾值
• 錯誤率通常比錯誤絕對數更有意義 ── 每秒 10 個錯誤在每秒 10 萬請求中微不足道，但在每秒 100 請求中就是災難

Saturation（飽和度）#

服務中最受限資源的使用程度。

• 可能是 CPU、記憶體、I/O，也可能是應用層面的限制（如執行緒池大小、資料庫連線池）
• 飽和度指標的重點是預測：在系統真正崩潰之前發出預警

Four Golden Signals 的核心精神是「以使用者體驗為中心」。延遲和錯誤直接影響使用者，流量反映使用者行為，飽和度預測使用者何時會受到影響。

RED Method#

提出者：Tom Wilkie（Grafana Labs）

適用對象：微服務 ── 特別是以「請求/回應」為主要互動模式的服務

RED 是 Four Golden Signals 的進一步簡化，專注於最核心的三個維度：

Rate（速率）#

每秒處理的請求數。等同於 Golden Signals 中的 Traffic。

Errors（錯誤）#

每秒失敗的請求數（或錯誤率）。等同於 Golden Signals 中的 Errors。

Duration（持續時間）#

每個請求的處理時間分佈。等同於 Golden Signals 中的 Latency。

你可能注意到 RED 相比 Golden Signals 少了 Saturation。這是刻意的取捨 ── 在微服務架構中，每個服務通常只需要關注它自己的 Rate、Errors、Duration。飽和度則由底層的基礎設施監控（USE Method）來覆蓋。

RED 的設計哲學#

RED Method 的設計哲學是：對每一個微服務，都監控這三個維度。當你有幾十甚至上百個微服務時，每個服務都有統一的 R、E、D 指標，排查問題時就能快速定位是哪個服務出了狀況。

這種一致性帶來的好處是巨大的 ── 新進團隊成員不需要了解每個服務的內部細節，只要看 RED Dashboard 就能判斷該服務是否健康。

三種方法的比較與選擇#

它們不是互斥的#

這三種方法不是「三選一」的關係，而是互補的：

• USE 幫你監控底層資源 ── 伺服器、虛擬機、容器的硬體與作業系統層
• Golden Signals / RED 幫你監控上層服務 ── 你的應用程式對外提供的服務品質

一個完整的監控架構，通常是底層用 USE、上層用 RED 或 Golden Signals。

從哪裡開始#

如果你的團隊剛開始建立監控體系，以下是建議的優先順序：

1. 先導入 RED / Golden Signals：從使用者能感受到的指標開始。如果使用者感覺不到問題，基礎設施的指標再多也只是噪音
2. 再加入 USE：當上層指標顯示異常（例如延遲上升），你需要底層指標來判斷是否是資源瓶頸
3. 根據架構調整：如果你是傳統的單體應用，Golden Signals 可能比 RED 更適合；如果你是微服務架構，RED 的統一性會帶來更大的好處

方法論是思考的框架，不是死板的清單。不要為了「完整實施 USE Method」而去監控一個你永遠不會瓶頸的資源。從你最痛的問題開始，用方法論引導你系統性地擴展監控範圍。