該關注哪些指標#
Prometheus 從應用程式與 Exporter 收集了上百種指標,但是並非每個都值得長期盯著看。參考社群分享的 Dashboard 是個快速起步的方式,但若要把監控做得有條理,還需要一些方法論作為依據。本章介紹三套常見的監控原則:USE、Four Golden Signals、RED。
USE 方法#
USE 方法(Utilization, Saturation, Errors)由 Brendan Gregg 提出,主要用於排查系統效能問題,能快速定位資源瓶頸或錯誤。USE 三個字母分別代表:
- Utilization 使用率:資源在多少比率的時間是忙碌的,例如 CPU 使用率、網路使用率、磁碟使用率。
- Saturation 飽和度:資源有多少工作在排隊等候,例如 CPU Run Queue、網路 Buffer、磁碟 I/O Queue。
- Errors 錯誤:錯誤事件數,例如 HTTP 500、磁碟 I/O Error。
USE 的精神是:當系統出包時,針對 CPU、記憶體、網路、磁碟等資源,依序檢查這三個面向,多半就能找到問題所在;反過來說,平時穩定監控這三類指標,也有機會提早發現問題。
四黃金訊號(Four Golden Signals)#
四黃金訊號(Four Golden Signals:Latency, Traffic, Errors, Saturation)出自 Google 的 Site Reliability Engineering,是觀察分散式系統時的四大核心指標:
- Latency 服務請求時間:處理請求所需時間,必須區分成功與失敗的請求。HTTP 500 可能很快回應,正常請求反而要走完完整邏輯,混在一起會看不出真正的延遲。
- Traffic 使用者用量:依服務類型定義流量單位,例如:
- API、Web:每秒請求數。
- 串流服務:網路 I/O、連線數。
- DB:每秒查詢數、交易數。
- Errors 錯誤比率:失敗請求的比例。需要同時觀察:
- 顯式錯誤:例如 HTTP 500、HTTP 404。
- 隱式錯誤:HTTP 200 但業務邏輯失敗,例如回傳內容的
returnCode = -1。
- Saturation 資源飽和度:資源還剩多少容量。一旦飽和,服務的效能會大幅下滑,例如磁碟空間、網路頻寬、Thread Pool 等。
RED 方法#
RED 方法(Rate, Errors, Duration)由 Weaveworks 前工程師、現任 Grafana Labs CTO Tom Wilkie 提出,融合了 USE 與 Four Golden Signals 的精神,把「微服務應該被怎麼觀察」收斂成三個指標:
- Rate(Request Rate):每秒請求數。
- Errors(Request Errors):每秒失敗請求數。
- Duration(Request Duration):請求耗時的分布。
RED 的好處是極為精煉,幾乎所有微服務都能套用同一組 Dashboard 模板。
Lab 摘要#
範例 07-monitoring-best-practices 透過 Docker Compose 啟動:
docker-compose up -d主要服務:
- Prometheus:
http://localhost:9090 - FastAPI App:
http://localhost:8000,可瀏覽/metrics確認指標格式。 - Grafana:
http://localhost:3000,預設admin/admin。
可透過瀏覽器手動發送 Request,或使用 k6 壓測:
k6 run --vus 1 --duration 300s k6-script.js關閉服務:
docker-compose downLab 的目標:
- 根據 Prometheus 收集到的 FastAPI App Metrics,在 Grafana 建立一個套用 RED 方法的 Dashboard。
小結#
三套方法論的關注重心略有不同:
- USE 方法:聚焦資源瓶頸與效能。
- 四黃金訊號:聚焦分散式系統的關鍵體驗指標。
- RED 方法:以微服務為單位,整合前兩者的精華。
當你被 Dashboard 上眼花撩亂的指標淹沒時,試著從這三套方法挑一套作為起點,再慢慢往外擴展,會比一開始就「看好看滿」更務實。
了解 Prometheus 的生成、收集、應用,以及監控原則後,下一階段將進入長期儲存與替代工具的世界。
原文出處#
- 原書/iThome:https://ithelp.ithome.com.tw/articles/10323545