前言：

Kubernetes作為當下最炙手可熱的容器管理平臺，在給應用部署運維帶來便捷的同時，也給應用及效能監控帶來了新的挑戰。本文給大家分享一款十分火熱的開源監控工具Prometheus，讓我們一起來看它是如何兼顧傳統的應用監控、主機 效能監控和Kubernetes監控的。

目錄：

一、Prometheus簡介

二、Prometheus架構圖

三、Prometheus架構詳解

四、Prometheus監控Kubernetes

一、Prometheus簡介

什麼是Prometheus？Prometheus是一個開源的系統監控及告警工具，最初建設在SoundCloud。從2012 Prometheus推出以來，許多公司都採用它搭建監控及告警系統。同時，專案擁有非常活躍的開發者和使用者社群。

它現在是一個獨立於任何公司的開源專案，為了強調這一點並明確專案的管理結構，在2016年Prometheus加入CNCF基金會成為繼Kubernetes之後的第二個託管專案。

Prometheus有什麼特點？

• 多維的資料模型（基於時間序列的k/v鍵值對）。

• 靈活的查詢及聚合語句（PromQL）。

• 不依賴分散式儲存，節點自治。

• 基於HTTP的pull模式採集時間序列資料。

• 可以使用pushgateway（prometheus的可選中介軟體）實現push模式。

• 可以使用動態服務發現或靜態配置採集的目標機器。

• 支援多種圖形及儀表盤。

Prometheus適用場景。

在選擇Prometheus作為監控工具前，要明確它的適用範圍，以及不適用的場景。

Prometheus在記錄純數值時間序列方面表現非常好。它既適用於以伺服器為中心的監控，也適用於高動態的面向服務架構的監控。

在微服務的監控上，Prometheus對多維度資料採集及查詢的支援也是特殊的優勢。

Prometheus更強調可靠性，即使在故障的情況下也能檢視系統的統計資訊。權衡利弊，以可能丟失少量資料為代價確保整個系統的可用性。因此，它不適用於對資料準確率要求100%的系統，比如實時計費系統（涉及到錢）。

二、Prometheus構架圖

上圖是Prometheus的架構圖，從圖中可以看出Prometheus的架構設計理念，中心化的資料採集，分析。

1. Prometheus Server：Prometheus的核心，根據配置完成資料採集， 服務發現以及資料儲存。

2. Pushgateway：為應對部分push場景提供的外掛，監控資料先推送到pushgateway上，然後再由server端採集pull。（若server採集間隔期間，pushgateway上的資料沒有變化，server將採集2次相同資料，僅時間戳不同）

3. Prometheus targets：探針（exporter）提供採集介面，或應用本身提供的支援Prometheus資料模型的採集介面。

4. Service discovery：支援根據配置file_sd監控本地配置檔案的方式實現服務發現（需配合其他工具修改本地配置檔案），同時支援配置監聽Kubernetes的API來動態發現服務。

5. Alertmanager：Prometheus告警外掛，支援傳送告警到郵件，Pagerduty，HipChat等。

三、Prometheus架構詳解

接下來，讓我們一起了解rometheus架構中各個元件是如何協同工作來完成監控任務。

• Prometheus server and targets

利用Prometheus官方或第三方提供的探針，基本可以完成對所有常用中介軟體或第三方工具的監控。

之前講到Prometheus是中心化的資料採集分析，那這裡的探針（exporter）是做什麼工作呢？

上圖中硬體及系統監控探針node exporter通過getMemInfo()方法獲取機器的記憶體資訊，然後將機器總記憶體資料對應上指標node_memory_MemTotal。

Jenkins探針Jenkins Exporter通過訪問Jenkins的api獲取到Jenkins的job數量並對應指標Jenkins_job_count_value。

探針的作用就是通過呼叫應用或系統介面的方式採集監控資料並對應成指標返回給prometheus server。（探針不一定要和監控的應用部署在一臺機器）

總的來說Prometheus資料採集流程就是，在Prometheus server中配置探針暴露的埠地址以及採集的間隔時間，Prometheus按配置的時間間隔通過http的方式去訪問探針，這時探針通過呼叫介面的方式獲取監控資料並對應指標返回給Prometheus server進行儲存。（若探針在Prometheus配置的採集間隔時間內沒有完成採集資料，這部分資料就會丟失）

• Prometheus alerting

Prometheus serve又是如何根據採集到的監控資料配和alertmanager完成告警呢？

舉一個常見的告警示例，在主機可用記憶體低於總記憶體的20%時傳送告警。我們可以根據Prometheus server採集的主機效能指標配置這樣一條規則node_memory_Active/node_memory_MemTotal < 0.2，Prometheus server分析採集到的資料，當滿足該條件時，傳送告警資訊到alertmanager，alertmanager根據本地配置處理告警資訊併傳送到第三方工具由相關的負責人接收。

Prometheus server在這裡主要負責根據告警規則分析資料併傳送告警資訊到alertmanager，alertmanager則是根據配置處理告警資訊併傳送。

Alertmanager又有哪些處理告警資訊的方式呢？

1. 分組：將監控目標相同的告警進行分組。如發生停電，收到的應該是單一資訊，資訊中包含所有受影響當機的機器，而不是針對每臺當機的機器都傳送一條告警資訊。

2. 抑制：抑制是指當告警發出後，停止傳送由此告警引發的其他告警的機制。如機器網路不可達，就不再傳送因網路問題造成的其他告警。

3. 沉默：根據定義的規則過濾告警資訊，匹配的告警資訊不會傳送。

• Service discovery

Prometheus支援多種服務發現的方式，這裡主要介紹架構圖中提到的file_sd的方式。之前提到Prometheus server的資料採集配置都是通過配置檔案，那服務發現該怎麼做？總不能每次要新增採集目標還要修改配置檔案並重啟服務吧。

這裡使用file_sd_configs指定定義了採集目標的檔案。Prometheus server會動態檢測該配置檔案的變化來更新採集目標資訊。現在只要能更新這個配置檔案就能動態的修改採集目標的配置了。

這裡採用consul+consul template的方式。在新增或減少探針（增減採集目標）時在consul更新k/v，如新增一個探針，新增如下記錄Prometheus/linux/node/10.15.15.132=10.15.15.132:9100，然後配置consul template監控consul的Prometheus/linux/node/目錄下k/v的變化，根據k/v的值以及提前定義的discovery.ctmpl模板動態生成Prometheus server的配置檔案discovery.yml。

• Web UI

至此，已經完成了資料採集和告警配置，是時候通過頁面展示一波成果了。

Grafana已經對Prometheus做了很好的支撐，在Grafana中新增Prometheus資料來源，然後就可以使用PromQL查詢語句結合grafana強大的圖形化能力來配置我們的效能監控頁面了。

• 聯邦模式

中心化的資料採集儲存，分析，而且還不支援叢集模式。帶來的效能問題顯而易見。Prometheus給出了一種聯邦的部署方式，就是Prometheus server可以從其他的Prometheus server採集資料。

可能有人會問，這樣最後的資料不是還是要全部彙集到Prometheus的global節點嗎？

並不是這樣的，我們可以在shard節點就完成分析處理，然後global節點直接採集分析處理過的資料進行展示。

比如在shard節點定義指標可用記憶體佔比job:memory_available:proportion的結果為(node_memory_MemFree + node_memory_Buffers + node_memory_Cached)/node_memory_MemTotal，這樣在shard節點就可以完成聚合操作，然後global節點直接採集處理過的資料就可以了，而不用採集零散的如node_memory_MemFree這類指標。

四、Prometheus監控Kubernetes

Kubernetes官方之前推薦了一種效能監控的解決方案，heapster+influxdb，heapster根據定義的間隔時間從Advisor中獲取的關於pod及container的效能資料並儲存到時間序列資料庫influxdb。

也可以使用grafana配置influxdb的資料來源並配置dashboard來做展現。而且Kubernetes中pod的自動伸縮的功能（Horizontal Pod Autoscaling）也是基於heapster，預設支援根據cpu的指標做動態伸縮，也可以自定義擴充套件使用其他指標。

但是Heapster無法做Kubernetes下應用的監控。現在，Heapster作為Kubernetes下的開源監控解決方案已經被其棄用（https://github.com/kubernetes/heapster），Prometheus成為Kubernetes官方推薦的監控解決方案。

Prometheus同樣通過Kubernetes的cAdvisor介面（/api/v1/nodes/${1}/proxy/metrics/cadvisor）獲取pod和container的效能監控資料，同時可以使用Kubernetes的Kube-state-metrics外掛來獲取叢集上Pod, DaemonSet, Deployment, Job, CronJob等各種資源物件的狀態，這反應了使用這些資源的應用的狀態。

同時通過Kubernetes api獲取node，service，pod，endpoints，ingress等服務的資訊，然後通過匹配註解中的值來獲取採集目標。

上面提到了Prometheus可以通過Kubernetes的api介面實現服務發現，並將匹配定義了annotation引數的pod，service等配置成採集目標。那現在要解決的問題就是探針到應用部署配置問題了。

這裡我們使用了Kubernetes的pod部署的sidecar模式，單個應用pod部署2個容器，利用單個pod中僅共享網路的namespace的隔離特性，探針與應用一同執行，並可以使用localhost直接訪問應用的埠，而在pod的註解中僅暴露探針的埠（prometheus.io/port: “9104”）即可。

Prometheus server根據配置匹配定義註解prometheus.io/scrape: “true”的pod，並將pod ip和註解中定義的埠（prometheus.io/port: “9104”）和路徑（prometheus.io/path: “/metrics”）拼接成採集目標http://10.244.3.123:9104/metrics。通過這種方式就可以完成動態新增需要採集的應用。

本文轉自掘金-開源監控利器Prometheus初探