共計 2131 個字符，預計需要花費 6 分鐘才能閱讀完成。
這篇文章主要講解了“如何使用 Prometheus 在 Kubernetes 中監控應用程序”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“如何使用 Prometheus 在 Kubernetes 中監控應用程序”吧！
什么是 Prometheus 監控？
最近有很多關于 Prometheus 的消息，尤其是在 Kubernetes 中監控應用程序這方面。深入 RED 方法之前，我們先了解一些背景內容。應用程序運行在容器上并由 Kubernetes 負責調度，在此環境中它們是高度自動化并且動態的。傳統的監控工具一般是基于服務器，只監控靜態的服務，所以當要在這種動態環境監控應用程序時，傳統的監控工具往往很難滿足這一需求。
這時就需要 Prometheus 出馬了。
Prometheus 是一個開源項目，最初由 SoundCloud 的工程師開發。它專門用于監控那些運行在容器中的微服務。每經過一個時間間隔，數據都會從運行的服務中流出，存儲到一個時間序列數據庫中，這個數據庫之后可以通過 PromQL 語言查詢。另外，因為數據是以時間序列存儲的，當出現問題時，可以根據這些時間間隔進行診斷，另外還可以預測基礎設施的長期監控趨勢 —- 這是 Prometheus 的兩大功能。
在 Weaveworks，我們把服務搭建在 Prometheus 的開源分布上，并且創建了一個可擴展、多租戶的版本，這是我們軟件即服務概念的一部分，稱為 Weave Cloud。
現在，該服務已經運行了幾個月，同時也使用 Weave Cloud 監控自己本身，在這個過程中我們積累到了一些有關監控云本機應用程序的經驗，并根據這些經驗設計了一個系統來確定在檢測代碼前需要測量什么。
該檢測什么？
在搭建 Prometheus 監控時，確定需要收集的指標類型十分重要，這些指標和應用程序相關。選擇的指標可以簡化故障發生時排除故障的流程，并且還可以在服務和基礎設施上保持很高的穩定性。為幫助理解 instrument 的重要性，我們定義了一個稱之為 RED 方法的系統。
RED 方法遵循 Four Golden Signals 中提及的原則，聚焦于檢測最終用戶在使用 web 服務時關心的東西。
在 RED 方法中，我們通過監控三項關鍵指標來管理架構中的每個微服務：
（Request）Rate – 你的服務所服務的每秒的請求數
（Request）Errors – 每秒失敗的請求數
（Request）Duration – 每個請求所花費的時間，用時間間隔表示
RED 方法希望由 Rate、Errors、Duration 三項指標涵蓋最典型的 Web 服務問題。同時這些指標還能夠反映出請求的錯誤率。通過這三項指標，我們就能監測到通常情況下會影響客戶體驗的問題。
如果想要獲得更細節的信息，還需要用到 Saturation 指標。Saturation 指標用在 USE（Utilization Saturation and Errors）方法中，它指的是一種帶有額外作業的資源，而該資源不能夠提供服務，因此必須添加到隊列中以備后續處理。
USE vs. RED 方法
對比兩種方法，USE 方法更側重于監控的性能，并以此為出發點尋找影響性能問題的根本原因以及其他系統的瓶頸。
在理想狀態下，我們可以在監控應用程序時同時使用 USE 和 RED 方法。
為什么要對每個服務衡量相同的指標
從監控的角度來看，如果能處理好每項服務，你的運營團隊就可以在此基礎上繼續擴展服務。
擴展性對運營團隊意味著什么？我們從這個角度看待問題，一個團隊可以支持多少個服務。在理想狀態下，一個團隊可以支持的服務數量和團隊規模無關，而取決于其他因素，比如 SLA 協議的響應類型以及是否需要全天候覆蓋等等。
如何將可支持的服務數量與團隊規模去藕化？辦法是讓每一個服務都變得一樣。這既減少了團隊針對特定的服務進行培訓的數量，還減少了在高壓事件響應場景或者所謂“認知負載”這些針對特定服務的特殊情況發生時，呼叫者需要記錄的內容。
容量規劃：考慮 QPS（每秒查詢次數）和延遲
自動化任務以及發出警報：RED 方法的優點在于它可以幫助你考慮如何在儀表板中顯示信息。通過這三個指標，你可以對儀表板的布局進行調整，讓它更易于閱讀，并在問題發生時發出警報。例如，一個布局可能意味著 — 每個服務都有一個不同的 Weave Cloud 記事本，包含了 PromQL 查詢的請求 錯誤，以及每個服務的延遲。
毫無疑問，如果把所有的服務都視為一樣的，那么將會更加易于自動化執行重復任務。
PromQL 查詢
在 Weave Cloud 上監控 RED 方法中的指標
局限性
事實上，這種方法（RED）僅適用于請求驅動的服務——比如，它在處理面向批處理的服務或者流服務時會發生錯誤。對于請求驅動它也不是完全適用，當需要監控其他東西——比如主機 CPU 內存或者緩存資源時，USE 方法表現的更好。
感謝各位的閱讀，以上就是“如何使用 Prometheus 在 Kubernetes 中監控應用程序”的內容了，經過本文的學習后，相信大家對如何使用 Prometheus 在 Kubernetes 中監控應用程序這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
