Prometheus監控（1）

Prometheus簡介

Prometheus受啟發于Google的Brogmon監控系統（相似的Kubernetes是從Google的Brog系統演變而來），從2012年開始由前Google工程師在Soundcloud以開源軟體的形式進行研發，并且于2015年早期對外釋出早期版本。2016年5月繼Kubernetes之後成為第二個正式加入CNCF基金會的項目，同年6月正式釋出1.0版本。2017年底釋出了基于全新存儲層的2.0版本，能更好地與容器平台、雲平台配合。

Prometheus作為新一代的雲原生監控系統，目前已經有超過650+位貢獻者參與到Prometheus的研發工作上，并且超過120+項的第三方內建。

整體架構圖

Prometheus從exporter拉取資料，或者間接地通過網關gateway拉取資料（如果在k8s内部署，可以使用服務發現的方式），它預設本地存儲抓取的所有資料，并通過一定規則進行清理和整理資料，并把得到的結果存儲到新的時間序列中，采集到的資料有兩個去向，一個是報警，另一個是可視化。PromQL和其他API可視化地展示收集的資料，并通過Alertmanager提供報警能力。

元件内容

• Prometheus Server

  負責從 Exporter 拉取和存儲監控資料,并提供一套靈活的查詢語言（PromQL）

• Retrieval: 采樣子產品
• TSDB: 存儲子產品預設本地存儲為tsdb
• HTTP Server: 提供http接口查詢和面闆，預設端口為9090

• Exporters/Jobs

  負責收集目标對象（host, container…）的性能資料，并通過 HTTP 接口供 Prometheus Server 擷取。支援資料庫、硬體、消息中間件、存儲系統、http伺服器、jmx等。隻要符合接口格式，就可以被采集。

• Short-lived jobs

  瞬時任務的場景，無法通過pull方式拉取，需要使用push方式，與PushGateway搭配使用

• PushGateway

  可選元件，主要用于短期的 jobs。由于這類 jobs 存在時間較短，可能在 Prometheus 來 pull 之前就消失了。為此，這次 jobs 可以直接向 Prometheus server 端推送它們的 metrics。這種方式主要用于服務層面的 metrics，對于機器層面的 metrices，需要使用 node exporter。

• 用戶端sdk

  官方提供的用戶端類庫有go、java、scala、python、ruby，其他還有很多第三方開發的類庫，支援nodejs、php、erlang等

• Alertmanager

  從 Prometheus server 端接收到 alerts 後，會進行去除重複資料，分組，并路由到對收的接受方式，發出報警。常見的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等。

• Service Discovery

  服務發現，Prometheus支援多種服務發現機制：檔案，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服務發現的過程并不複雜，通過第三方提供的接口，Prometheus查詢到需要監控的Target清單，然後輪訓這些Target擷取監控資料。

其大概的工作流程是：

• Prometheus server 定期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 Pushgateway 發過來的 metrics，或者從其他的 Prometheus server 中拉 metrics。
• Prometheus server 在本地存儲收集到的 metrics，并運作已定義好的 alert.rules，記錄新的時間序列或者向 Alertmanager 推送警報。

• Alertmanager 根據配置檔案，對接收到的警報進行處理，發出告警。

  報警系統 包括⼏種主要的展現形式 ：短信報警，郵件報警，電話報警（語⾳播報） , 通訊軟體（微信、企業微信、釘釘、飛書等）

• 在圖形界面中，可視化采集資料。

資料采集

應該采集監測什麼？

• 從服務的類型來講，應該監測所有類型的服務：線上服務、離線服務和批處理任務
• 從單一服務的實作來講，應該監測服務的關鍵邏輯，比如關鍵邏輯執行的總數、失敗次數、重試次數等
• 從服務的品質來講，應該監測服務的請求總數、請求錯誤率和請求響應時間
• 從系統資源上來講，應該監測資源的使用率、飽和度和錯誤

Prometheus 将采集的資料分為 Counter、Gauge、Histogram、Summary 四種類型。需要注意的是，這隻是一種邏輯分類，Prometheus 内部并沒有使用采集的資料的類型資訊，而是将它們做為無類型的資料進行處理。這在未來可能會改變。下面，我們将具體介紹這四種類型。

Counter

Counter 是計數器類型，适合單調遞增的場景，比如請求的總數、完成的任務總數、出現的錯誤總數等。它擁有很好的不相關性，不會因為重新開機而重置為 0。

Gauge

Gauge 用來表示可增可減的值，比如 CPU 和記憶體的使用量、IO 大小等。

Histogram

Histogram 是一種累積直方圖，它通常用來描述監控項的長尾效應。舉個例子：假設使用 Hitogram 來分析 API 調用的響應時間，使用數組 [30ms, 100ms, 300ms, 1s, 3s, 5s, 10s] 将響應時間分為 8 個區間。那麼每次采集到響應時間，比如 200ms，那麼對應的區間 (0, 30ms], (30ms, 100ms], (100ms, 300ms] 的計數都會加 1。最終以響應時間為橫坐标，每個區間的計數值為縱坐标，就能得到 API 調用響應時間的累積直方圖。

Summary

Summary 和 Histogram 類似，它記錄的是監控項的分位數。什麼是分位數？舉個例子：假設對于一個 http 請求調用了 100 次，得到 100 個響應時間值。将這 100 個時間響應值按照從小到大的順序排列，那麼 0.9 分位數（90% 位置）就代表着第 90 個數。通過 Histogram 可以近似的計算出百分位數，但是結果并不準确，而 Summary 是在用戶端計算的，比 Histogram 更準确。不過，Summary 計算消耗的資源更多，并且計算的名額不能再擷取平均數或者關聯其他名額，是以它通常獨立使用。

告警

報警系統中 最重要的⼀個概念之⼀ 就是對報警門檻值的了解。

門檻值(Trigger Value) ，是監控系統中 對資料到達某⼀個臨界值的定義。

例如：通過監控發現，目前某⼀台機器的CPU突然升⾼，到達了 99%的使⽤率， 99 就是作為⼀次報警的觸發門檻值。

Pagerduty 的年頭不短了，在企業中 尤其是外企 出鏡率⾮常⾼。

雖然是收費監控，但是費⽤對于⼀個企業來說很便宜 甚⾄對于 個⼈⽤戶來說其實也不算⾼。

Pagerduty是一套付費監控報警系統，經常作為SRE/運維人員的監控報警工具，可以和市面上常見的監控工具直接整合，例如和zabbix整合，我遇到的最多的場景還是和zabbix整合，當有伺服器出現異常的時候，zabbix會通過pagerduty對目前設定的值班的人員進行短信+電話通知.

支援的API Client Libraries

Pagerduty 擁有 短信，電話，郵件 所有的報警機制。

Pagerduty 還有⾮常實⽤的必要的 運維值班管理制度 和 報警更新等等 擴充功能。

Pagerduty的優點⾮常多，使⽤率⾮常⾼（外企⼏乎清⼀⾊的使⽤，國内企業很多也在使⽤）

但是有優點就肯定也有不⾜

Pagerduty有⼏個⼩問題 需要提⾼

• 對中⽂的⽀持不好 或者說⼏乎不⽀持 （指的是 語⾳播報⽅⾯ ） 

• 站點主要在美國和海外 ⽹速有時候不太給⼒ => 可以⾛代理的⽅式 加快速度

優勢

Prometheus相⽐其他⽼款監控的 不可被替代的巨⼤優勢，以及⼀些不⾜有待提⾼的地⽅。

• 監控資料的精細程度 絕對的第⼀ 可以精确到 1～5秒的采集精度 4 5分鐘 理想的狀态 我們來算算采集精度 （存儲 性能）
• 叢集部署的速度 監控腳本的制作 （指的是熟練之後） ⾮常快速 ⼤⼤縮短監控的搭建時間成本
• 周邊插件很豐富 exporter pushgateway ⼤多數都不需要⾃⼰開發了
• 本⾝基于數學計算模型，⼤量的實⽤函數 可以實作很複雜規則的業務邏輯監控（例如QPS的曲線 彎曲 凸起 下跌的 ⽐例等等模糊概念）
• 可以嵌⼊很多開源⼯具的内部 進⾏監控 資料更準時 更可信（其他監控很難做到這⼀點）
• 本⾝是開源的，更新速度快， bug修複快。⽀持N多種語⾔做本⾝和插件的⼆次開發
• 圖形很⾼⼤上 很美觀 ⽼闆特别喜歡看這種業務圖 （主要是指跟Grafana的結合）

• ⼀些不⾜的地⽅

  因其資料采集的精度 如果叢集數量太⼤，那麼單點的監控有性能瓶頸 ⽬前尚不⽀持叢集 隻能workaround

• 學習成本太⼤，尤其是其獨有的數學指令⾏
• 對磁盤資源也是耗費的較⼤，這個具體要看 監控的叢集量 和 監控項的多少 和儲存時間的長短
• 本⾝的使⽤ 需要使⽤者的數學不能太差 要有⼀定的數學頭腦