本文來自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方法表現的更好。

原文來源：Rancher Labs

本文出自 “12452495” 博客，請務必保留此出處http://12462495.blog.51cto.com/12452495/1971929

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