概述
前面已經介紹了Prometheus的數據存儲模型以及4種指標類型，同時Prometheus提供的強大的PromQL可以實現對數據的個性化處理。Promthues基於指標提供了一個通用的監控解決方案，那麼在實現監控時，我們到底應該監控哪些對象以及哪些指標？
Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community. It is now a standalone open source project and maintained independently of any company.
監控所有
監控的基本目標，首先是及時發現問題其次是要能夠快速對問題進行定位。下面列舉一些常用的監控維度。
4個黃金指標
除了上述介紹的不同監控級別以外。實際上根據不同的系統類型和目標，這裡還有一些通用的套路和模式可以使用。
Four Golden Signals是Google針對大量分布式監控的經驗總結，4個黃金指標可以在服務級別幫助衡量終端用戶體驗、服務中斷、業務影響等層面的問題。主要關注與以下四種類型的指標：延遲，通訊量，錯誤以及飽和度：
- 延遲：服務請求所需時間。
記錄用戶所有請求所需的時間，重點是要區分成功請求的延遲時間和失敗請求的延遲時間。 例如在資料庫或者其他關鍵禍端服務異常觸發HTTP 500的情況下，用戶也可能會很快得到請求失敗的響應內容，如果不加區分計算這些請求的延遲，可能導致計算結果與實際結果產生巨大的差異。除此以外，在微服務中通常提倡「快速失敗」，開發人員需要特別注意這些延遲較大的錯誤，因為這些緩慢的錯誤會明顯影響系統的性能，因此追蹤這些錯誤的延遲也是非常重要的。
- 通訊量：監控當前系統的流量，用于衡量服務的容量需求。
流量對於不同類型的系統而言可能代表不同的含義。例如，在HTTP REST API中, 流量通常是每秒HTTP請求數；
- 錯誤：監控當前系統所有發生的錯誤請求，衡量當前系統錯誤發生的速率。
對於失敗而言有些是顯式的(比如, HTTP 500錯誤)，而有些是隱式(比如，HTTP響應200，但實際業務流程依然是失敗的)。
對於一些顯式的錯誤如HTTP 500可以通過在負載均衡器(如Nginx)上進行捕獲，而對於一些系統內部的異常，則可能需要直接從服務中添加鉤子統計並進行獲取。
- 飽和度：衡量當前服務的飽和度。
主要強調最能影響服務狀態的受限制的資源。 例如，如果系統主要受內存影響，那就主要關注系統的內存狀態，如果系統主要受限與磁碟I/O，那就主要觀測磁碟I/O的狀態。因為通常情況下，當這些資源達到飽和後，服務的性能會明顯下降。同時還可以利用飽和度對系統做出預測，比如，「磁碟是否可能在4個小時候就滿了」。
RED方法
RED方法是Weave Cloud在基於Google的「4個黃金指標」的原則下結合Prometheus以及Kubernetes容器實踐，細化和總結的方法論，特別適合於雲原生應用以及微服務架構應用的監控和度量。主要關注以下三種關鍵指標：
- (請求)速率：服務每秒接收的請求數。
- (請求)錯誤：每秒失敗的請求數。
- (請求)耗時：每個請求的耗時。
在「4大黃金信號」的原則下，RED方法可以有效的幫助用戶衡量雲原生以及微服務應用下的用戶體驗問題。
USE方法
USE方法全稱"Utilization Saturation and Errors Method"，主要用於分析系統性能問題，可以指導用戶快速識別資源瓶頸以及錯誤的方法。正如USE方法的名字所表示的含義，USE方法主要關注與資源的：使用率(Utilization)、飽和度(Saturation)以及錯誤(Errors)。
- 使用率：關注系統資源的使用情況。 這裡的資源主要包括但不限於：CPU，內存，網絡，磁碟等等。100%的使用率通常是系統性能瓶頸的標誌。
- 飽和度：例如CPU的平均運行排隊長度，這裡主要是針對資源的飽和度(注意，不同於4大黃金信號)。任何資源在某種程度上的飽和都可能導致系統性能的下降。
- 錯誤：錯誤計數。例如：「網卡在數據包傳輸過程中檢測到的乙太網網絡衝突了14次」。
通過對資源以上指標持續觀察，通過以下流程可以知道用戶識別資源瓶頸：
識別資源瓶頸
覺得有用的朋友多幫忙轉發哦！後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~