Prometheus監控的最佳實踐——關於監控的3項關鍵指標

本文來自Weaveworks的工程師Anita Burhrle在Rancher Labs與Weaveworks聯合舉辦的Online Meetup上的技術分享。在這次分享中，嘉賓們討論瞭如何使用Rancher、Weave Cloud和Prometheus來輕鬆部署、管理與監控Kubernetes。本文將分享Weave是爲什麼以及如何開發出RED最佳實踐方法來使用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方法表現的更好。