監控利器Prometheus初探

導讀：Kubernetes做爲當下最煊赫一時的容器管理平臺，在給應用部署運維帶來便捷的同時，也給應用及性能監控帶來了新的挑戰。本文給你們分享一款十分火熱的開源監控工具Prometheus，讓咱們一塊兒來看它是如何兼顧傳統的應用監控、主機性能監控和Kubernetes監控的。

目錄：

1、Prometheus簡介

2、Prometheus架構圖

3、Prometheus架構詳解

4、Prometheus監控Kubernetes

1、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%的系統，好比實時計費系統（涉及到錢）。

2、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等。

3、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這類指標。

4、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。經過這種方式就能夠完成動態添加須要採集的應用。

精選提問：

問1：Prometheus webui 和 Grafana的界面是獨立分開的，仍是集成在一塊兒的？

答：是獨立頁面。

問2：獨立頁面的話，那用戶須要登陸兩個界面系統？

答：Prometheus自帶的界面比較簡單，通常是用Grafana作頁面展現。Prometheus的界面能夠查看採集目標，指標，和作簡單的頁面展示。

問3：微課堂中提到的缺點，消耗資源偏大。（在Prometheus2.0版本有所改善)。這個偏大有量化的指標嗎？

答：以前1.7版本的時候使用時，一臺4C8G的機器，十多個採集目標，而後用Grafana作查詢展示發現CPU會佔用比較高。大概70%。

問4：Prometheus和傳統zabbix有哪些優點？

答：zabbix在傳統的監控中使用比較廣泛，倒也說不上Prometheus有什麼優點。Prometheus在Kubernetes的監控應該是有很大優點的。