監控不是把能量的都量、把能報的都報。好監控只回答兩件事：壞了什麼（症狀） 和 為什麼（原因）——而且只在「緊急、可行動、影響使用者」時才叫醒人。
🧠 Core Ideas
TIP
只能量四個就量這四個——延遲、流量、錯誤、飽和度。它們涵蓋了「使用者有沒有在痛」與「系統快不快撐不住」。
- 延遲 (Latency)：成功與失敗請求要分開量（慢失敗比快失敗更糟）。
- 流量 (Traffic)：施加的需求量（Web 的 QPS、串流的連線數）。
- 錯誤 (Errors)：明示（500）、暗示（200 但內容錯）、政策（超過約定延遲算錯）。
- 飽和度 (Saturation)：最受限資源多滿；高百分位延遲常是它的領先指標。
⚖️ Tradeoffs
症狀 vs 原因、黑箱 vs 白箱
- 告警應以症狀驅動（「使用者收不到圖」），原因型告警退為除錯輔助——這是「高信號、低噪音」的關鍵。
- 黑箱（從使用者視角）強制紀律「真的壞了才叫人」；白箱（內部指標）能抓「即將壞、被重試掩蓋」的問題。兩者都要。
- 一個人的症狀是另一個人的原因（DB「讀取慢」對前端是「網站慢」的原因）。
看分佈，不要看平均
- 平均會被長尾騙：平均 100 ms 的服務裡 1% 可能慢到 5 秒；使用者串多個後端時，某後端的 99th 常就是前端的中位數。
- 把延遲分桶做 histogram，看 50/95/99/99.9 百分位。
- 解析度依面向調：CPU 尖峰要細、年可用度探測不必每秒。
盡量簡單，否則會腐爛
- 抓最常見事件的規則要最簡單最可預測；一季沒用到的告警/蒐集是移除候選。
- 別把監控跟 profiling / load test / log 分析糅成一個系統——鬆耦合才長壽。
- 每條告警先自問：緊急嗎？可行動嗎？確定影響使用者嗎？回應需要「智慧」還是機械式（後者不該 page）？
🔑 Takeaways
- 四個黃金指標：延遲、流量、錯誤、飽和度——涵蓋監控的最小必要集。
- 症狀驅動 page、看百分位不看平均，是高信號低噪音的兩條鐵律。
- 告警會腐爛：規則越簡單越好，機械式的 page 是該自動化的紅旗。
No notes yet — jot your takeaways or Q&A here.