前言：           

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

目錄：

一、Prometheus簡介

二、Prometheus架構圖

三、Prometheus架構詳解

四、Prometheus監控Kubernetes

                               一、Prometheus簡介

 

什么是Prometheus？

Prometheus是由SoundCloud使用Go語言開發；

它是開源監控報警系統和時序列數據庫(TSDB)。

它是Google BorgMon監控系統的開源版本。

2016年由Google發起Linux基金會旗下的原生云基金會(Cloud Native Computing Foundation), 將Prometheus納入其下第二大開源項目。Prometheus目前在開源社區相當活躍。

Prometheus和Heapster(Heapster是K8S的一個子項目，用于獲取集群的性能數據。)相比功能更完善、更全面。Prometheus性能也足夠支撐上萬臺規模的集群。

Prometheus是一個開源的網絡監控工具，它專為監控時間序列數據而構建。你可以按時間長度標準或關鍵詞對來標識時間序列數據。時間序列數據存儲在本地磁盤上，以便在緊急情況下輕松訪問。

Prometheus的Alertmanager負責消息通知，Alertmanager可以通過電子郵件，PagerDuty或OpsGenie發送通知，如有必要，你也可以關閉警報通知

Prometheus的UI元素非常出色，允許你從瀏覽器切換到模板語言和Grafana集成。你還可以將各種第三方數據源從Docker，StatsD和JMX中集成到Prometheus中，來自定義Prometheus。

Prometheus是一個開源的系統監控及告警工具，最初建設在SoundCloud。從2012 Prometheus推出以來，許多公司都采用它搭建監控及告警系統。同時，項目擁有非?；钴S的開發者和用戶社區。

它現在是一個獨立于任何公司的開源項目，為了強調這一點并明確項目的管理結構，在2016年Prometheus加入CNCF基金會成為繼Kubernetes之后的第二個托管項目。

Prometheus有什么特點？

• 多維的數據模型（基于時間序列的k/v鍵值對）。

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

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

• 基于HTTP的pull模式采集時間序列數據。

• 可以使用pushgateway（prometheus的可選中間件）實現push模式。

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

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

Prometheus組件

1. Prometheus Server 負責監控數據收集和存儲

2. Prometheus Alert manager 負責根據告警規則進行告警，可集成很多告警通道

3. node-exporter 的作用就是從機器讀取指標，然后暴露一個 http 服務，Prometheus 就是從這個服務中收集監控指標。當然 Prometheus 官方還有各種各樣的 exporter。

注意 ：  釘釘集成 Prometheus 告警的組件：prometheus-webhook-dingtalk。

Prometheus適用場景

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

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

在微服務的監控上，Prometheus對多維度數據采集及查詢的支持也是特殊的優勢。

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

                              二、Prometheus構架圖

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

 

Prometheus組件

Prometheus生態系統由多個組件組成，它們中的一些是可選的。多數Prometheus組件是Go語言寫的，這使得這些組件很容易編譯和部署。

1. Prometheus Server：Prometheus的核心，根據配置完成數據采集，  服務發現以及數據存儲 ,提供PromQL查詢語言的支持。

 

2. Push Gateway：為應對部分push場景提供的插件，監控數據先推送到pushgateway上，然后再由server端采集pull。（若server采集間隔期間，pushgateway上的數據沒有變化，server將采集2次相同數據，僅時間戳不同）。支持臨時性Job主動推送指標的中間網關。

 

3. Prometheus targets：探針（exporter）提供采集接口，或應用本身提供的支持Prometheus數據模型的采集接口。

 

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

 

5. Alertmanager：Prometheus告警插件，支持發送告警到郵件，Pagerduty，HipChat等。

6、PromDash

使用Rails開發可視化的Dashboard，用于可視化指標數據。

7、客戶端SDK 

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

8、Exporter

Exporter是Prometheus的一類數據采集組件的總稱。它負責從目標處搜集數據，并將其轉化為Prometheus支持的格式。與傳統的數據采集組件不同的是，它并不向中央服務器發送數據，而是等待中央服務器主動前來抓取。

9、alertmanager

警告管理器，用來進行報警。

10、prometheus_cli

命令行工具。

其他輔助性工具

多種導出工具，可以支持Prometheus存儲數據轉化為HAProxy、StatsD、Graphite等工具所需要的數據存儲格式

 

                          三、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會動態檢測該配置文件的變化來更新采集目標信息?，F在只要能更新這個配置文件就能動態的修改采集目標的配置了。

 

這里采用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下應用的監控?，F在，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的監控應該是有很大優勢的。

 

鏈接　?。?/p>

Prometheus+grafana　　　?。骸ttp://blog.51cto.com/youerning/2050543

Kubernetes+Prometheus+Grafana部署筆記薦       ： http://blog.51cto.com/kaliarch/2160569

監控篇 | Prometheus 認識    ： https://mp.weixin.qq.com/s/tO1dzAHBc553QI3qaSXNFQ

 

監控篇 | Prometheus 安裝  ：https://mp.weixin.qq.com/s/m9GNwhJQjkFjhd3RnBAJ4Q

監控篇 | Prometheus 架構  : https://mp.weixin.qq.com/s/TK5nsRdohOvSOmxRGEn0ig

Grafana+Prometheus打造全方位立體監控系統  ： http://blog.51cto.com/itstyle/1980064

監控篇 | prometheus架構 ：https://mp.weixin.qq.com/s/xjKUbzQYnTaFItIPMSH2MA

監控篇 | prometheus安裝 ： https://mp.weixin.qq.com/s/jveLQQOPztgtHpsZ0e2ESA

監控篇 | 認識Prometheus ：https://mp.weixin.qq.com/s/4qS7-iFTtmAx9-E97hW-kg

Prometheus 使用總結：我踩過得那些坑 : https://mp.weixin.qq.com/s/8AqQPZfG_plMKivpblylhg

老張監控技術|Zabbix4.2集成Prometheus基礎入門+自動發現詳解 ： https://mp.weixin.qq.com/s/nyRMKPC2y4p89BsHtkWBEg

搞搞 Prometheus: Alertmanager ： https://mp.weixin.qq.com/s/K06OQRu5RdqpKdAUPeGTvw

通過 Telegraf + InfluxDB + Grafana 快速搭建監控體系的詳細步驟 ： https://www.linuxidc.com/Linux/2019-07/159204.htm