監(jiān)控利器Prometheus怎么用

監(jiān)控利器Prometheus怎么用，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

前言：

Kubernetes作為當(dāng)下最炙手可熱的容器管理平臺(tái)，在給應(yīng)用部署運(yùn)維帶來便捷的同時(shí)，也給應(yīng)用及性能監(jiān)控帶來了新的挑戰(zhàn)。下面給大家分享一款十分火熱的開源監(jiān)控工具Prometheus，讓我們一起來看它是如何兼顧傳統(tǒng)的應(yīng)用監(jiān)控、主機(jī)性能監(jiān)控和

一、Prometheus簡介

什么是Prometheus？

Prometheus是一個(gè)開源的系統(tǒng)監(jiān)控及告警工具，最初建設(shè)在SoundCloud。從2012 Prometheus推出以來，許多公司都采用它搭建監(jiān)控及告警系統(tǒng)。同時(shí)，項(xiàng)目擁有非?；钴S的開發(fā)者和用戶社區(qū)。

它現(xiàn)在是一個(gè)獨(dú)立于任何公司的開源項(xiàng)目，為了強(qiáng)調(diào)這一點(diǎn)并明確項(xiàng)目的管理結(jié)構(gòu)，在2016年P(guān)rometheus加入CNCF基金會(huì)成為繼Kubernetes之后的第二個(gè)托管項(xiàng)目。

Prometheus有什么特點(diǎn)？

• 多維的數(shù)據(jù)模型（基于時(shí)間序列的k/v鍵值對(duì)）。

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

• 不依賴分布式存儲(chǔ)，節(jié)點(diǎn)自治。

• 基于HTTP的pull模式采集時(shí)間序列數(shù)據(jù)。

• 可以使用pushgateway（prometheus的可選中間件）實(shí)現(xiàn)push模式。

• 可以使用動(dòng)態(tài)服務(wù)發(fā)現(xiàn)或靜態(tài)配置采集的目標(biāo)機(jī)器。

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

Prometheus適用場(chǎng)景。

在選擇Prometheus作為監(jiān)控工具前，要明確它的適用范圍，以及不適用的場(chǎng)景。

Prometheus在記錄純數(shù)值時(shí)間序列方面表現(xiàn)非常好。它既適用于以服務(wù)器為中心的監(jiān)控，也適用于高動(dòng)態(tài)的面向服務(wù)架構(gòu)的監(jiān)控。

在微服務(wù)的監(jiān)控上，Prometheus對(duì)多維度數(shù)據(jù)采集及查詢的支持也是特殊的優(yōu)勢(shì)。

Prometheus更強(qiáng)調(diào)可靠性，即使在故障的情況下也能查看系統(tǒng)的統(tǒng)計(jì)信息。權(quán)衡利弊，以可能丟失少量數(shù)據(jù)為代價(jià)確保整個(gè)系統(tǒng)的可用性。因此，它不適用于對(duì)數(shù)據(jù)準(zhǔn)確率要求100%的系統(tǒng)，比如實(shí)時(shí)計(jì)費(fèi)系統(tǒng)（涉及到錢）。

二、Prometheus構(gòu)架圖

上圖是Prometheus的架構(gòu)圖，從圖中可以看出Prometheus的架構(gòu)設(shè)計(jì)理念，中心化的數(shù)據(jù)采集，分析。

1. Prometheus Server：Prometheus的核心，根據(jù)配置完成數(shù)據(jù)采集，  服務(wù)發(fā)現(xiàn)以及數(shù)據(jù)存儲(chǔ)。

2. Pushgateway：為應(yīng)對(duì)部分push場(chǎng)景提供的插件，監(jiān)控?cái)?shù)據(jù)先推送到pushgateway上，然后再由server端采集pull。（若server采集間隔期間，pushgateway上的數(shù)據(jù)沒有變化，server將采集2次相同數(shù)據(jù)，僅時(shí)間戳不同）

3. Prometheus targets：探針（exporter）提供采集接口，或應(yīng)用本身提供的支持Prometheus數(shù)據(jù)模型的采集接口。

4. Service discovery：支持根據(jù)配置file_sd監(jiān)控本地配置文件的方式實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)（需配合其他工具修改本地配置文件），同時(shí)支持配置監(jiān)聽Kubernetes的API來動(dòng)態(tài)發(fā)現(xiàn)服務(wù)。

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

三、Prometheus架構(gòu)詳解

接下來，讓我們一起了解rometheus架構(gòu)中各個(gè)組件是如何協(xié)同工作來完成監(jiān)控任務(wù)。

• Prometheus server and targets

   

利用Prometheus官方或第三方提供的探針，基本可以完成對(duì)所有常用中間件或第三方工具的監(jiān)控。

之前講到Prometheus是中心化的數(shù)據(jù)采集分析，那這里的探針（exporter）是做什么工作呢？

上圖中硬件及系統(tǒng)監(jiān)控探針node exporter通過getMemInfo()方法獲取機(jī)器的內(nèi)存信息，然后將機(jī)器總內(nèi)存數(shù)據(jù)對(duì)應(yīng)上指標(biāo)node_memory_MemTotal。

Jenkins探針Jenkins Exporter通過訪問Jenkins的api獲取到Jenkins的job數(shù)量并對(duì)應(yīng)指標(biāo)Jenkins_job_count_value。

探針的作用就是通過調(diào)用應(yīng)用或系統(tǒng)接口的方式采集監(jiān)控?cái)?shù)據(jù)并對(duì)應(yīng)成指標(biāo)返回給prometheus server。（探針不一定要和監(jiān)控的應(yīng)用部署在一臺(tái)機(jī)器）

總的來說Prometheus數(shù)據(jù)采集流程就是，在Prometheus server中配置探針暴露的端口地址以及采集的間隔時(shí)間，Prometheus按配置的時(shí)間間隔通過http的方式去訪問探針，這時(shí)探針通過調(diào)用接口的方式獲取監(jiān)控?cái)?shù)據(jù)并對(duì)應(yīng)指標(biāo)返回給Prometheus server進(jìn)行存儲(chǔ)。（若探針在Prometheus配置的采集間隔時(shí)間內(nèi)沒有完成采集數(shù)據(jù)，這部分?jǐn)?shù)據(jù)就會(huì)丟失）

• Prometheus alerting

Prometheus serve又是如何根據(jù)采集到的監(jiān)控?cái)?shù)據(jù)配和alertmanager完成告警呢？

舉一個(gè)常見的告警示例，在主機(jī)可用內(nèi)存低于總內(nèi)存的20%時(shí)發(fā)送告警。我們可以根據(jù)Prometheus server采集的主機(jī)性能指標(biāo)配置這樣一條規(guī)則node_memory_Active/node_memory_MemTotal < 0.2，Prometheus server分析采集到的數(shù)據(jù)，當(dāng)滿足該條件時(shí)，發(fā)送告警信息到alertmanager，alertmanager根據(jù)本地配置處理告警信息并發(fā)送到第三方工具由相關(guān)的負(fù)責(zé)人接收。

Prometheus server在這里主要負(fù)責(zé)根據(jù)告警規(guī)則分析數(shù)據(jù)并發(fā)送告警信息到alertmanager，alertmanager則是根據(jù)配置處理告警信息并發(fā)送。

Alertmanager又有哪些處理告警信息的方式呢？

1. 分組：將監(jiān)控目標(biāo)相同的告警進(jìn)行分組。如發(fā)生停電，收到的應(yīng)該是單一信息，信息中包含所有受影響宕機(jī)的機(jī)器，而不是針對(duì)每臺(tái)宕機(jī)的機(jī)器都發(fā)送一條告警信息。

2. 抑制：抑制是指當(dāng)告警發(fā)出后，停止發(fā)送由此告警引發(fā)的其他告警的機(jī)制。如機(jī)器網(wǎng)絡(luò)不可達(dá)，就不再發(fā)送因網(wǎng)絡(luò)問題造成的其他告警。

3. 沉默：根據(jù)定義的規(guī)則過濾告警信息，匹配的告警信息不會(huì)發(fā)送。

• Service discovery

Prometheus支持多種服務(wù)發(fā)現(xiàn)的方式，這里主要介紹架構(gòu)圖中提到的file_sd的方式。之前提到Prometheus server的數(shù)據(jù)采集配置都是通過配置文件，那服務(wù)發(fā)現(xiàn)該怎么做？總不能每次要添加采集目標(biāo)還要修改配置文件并重啟服務(wù)吧。

這里使用file_sd_configs指定定義了采集目標(biāo)的文件。Prometheus server會(huì)動(dòng)態(tài)檢測(cè)該配置文件的變化來更新采集目標(biāo)信息?，F(xiàn)在只要能更新這個(gè)配置文件就能動(dòng)態(tài)的修改采集目標(biāo)的配置了。

這里采用consul+consul template的方式。在新增或減少探針（增減采集目標(biāo)）時(shí)在consul更新k/v，如新增一個(gè)探針，添加如下記錄Prometheus/linux/node/10.15.15.132=10.15.15.132:9100，然后配置consul template監(jiān)控consul的Prometheus/linux/node/目錄下k/v的變化，根據(jù)k/v的值以及提前定義的discovery.ctmpl模板動(dòng)態(tài)生成Prometheus server的配置文件discovery.yml。

• Web UI

至此，已經(jīng)完成了數(shù)據(jù)采集和告警配置，是時(shí)候通過頁面展示一波成果了。

Grafana已經(jīng)對(duì)Prometheus做了很好的支撐，在Grafana中添加Prometheus數(shù)據(jù)源，然后就可以使用PromQL查詢語句結(jié)合grafana強(qiáng)大的圖形化能力來配置我們的性能監(jiān)控頁面了。

• 聯(lián)邦模式

中心化的數(shù)據(jù)采集存儲(chǔ)，分析，而且還不支持集群模式。帶來的性能問題顯而易見。Prometheus給出了一種聯(lián)邦的部署方式，就是Prometheus server可以從其他的Prometheus server采集數(shù)據(jù)。

可能有人會(huì)問，這樣最后的數(shù)據(jù)不是還是要全部匯集到Prometheus的global節(jié)點(diǎn)嗎？

并不是這樣的，我們可以在shard節(jié)點(diǎn)就完成分析處理，然后global節(jié)點(diǎn)直接采集分析處理過的數(shù)據(jù)進(jìn)行展示。

比如在shard節(jié)點(diǎn)定義指標(biāo)可用內(nèi)存占比job:memory_available:proportion的結(jié)果為(node_memory_MemFree + node_memory_Buffers + node_memory_Cached)/node_memory_MemTotal，這樣在shard節(jié)點(diǎn)就可以完成聚合操作，然后global節(jié)點(diǎn)直接采集處理過的數(shù)據(jù)就可以了，而不用采集零散的如node_memory_MemFree這類指標(biāo)。

四、Prometheus監(jiān)控Kubernetes

Kubernetes官方之前推薦了一種性能監(jiān)控的解決方案，heapster+influxdb，heapster根據(jù)定義的間隔時(shí)間從Advisor中獲取的關(guān)于pod及container的性能數(shù)據(jù)并存儲(chǔ)到時(shí)間序列數(shù)據(jù)庫influxdb。

也可以使用grafana配置influxdb的數(shù)據(jù)源并配置dashboard來做展現(xiàn)。而且Kubernetes中pod的自動(dòng)伸縮的功能（Horizontal Pod Autoscaling）也是基于heapster，默認(rèn)支持根據(jù)cpu的指標(biāo)做動(dòng)態(tài)伸縮，也可以自定義擴(kuò)展使用其他指標(biāo)。

但是Heapster無法做Kubernetes下應(yīng)用的監(jiān)控?，F(xiàn)在，Heapster作為Kubernetes下的開源監(jiān)控解決方案已經(jīng)被其棄用（https://github.com/kubernetes/heapster），Prometheus成為Kubernetes官方推薦的監(jiān)控解決方案。

Prometheus同樣通過Kubernetes的cAdvisor接口（/api/v1/nodes/${1}/proxy/metrics/cadvisor）獲取pod和container的性能監(jiān)控?cái)?shù)據(jù)，同時(shí)可以使用Kubernetes的Kube-state-metrics插件來獲取集群上Pod, DaemonSet, Deployment, Job, CronJob等各種資源對(duì)象的狀態(tài)，這反應(yīng)了使用這些資源的應(yīng)用的狀態(tài)。

同時(shí)通過Kubernetes api獲取node，service，pod，endpoints，ingress等服務(wù)的信息，然后通過匹配注解中的值來獲取采集目標(biāo)。

上面提到了Prometheus可以通過Kubernetes的api接口實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，并將匹配定義了annotation參數(shù)的pod，service等配置成采集目標(biāo)。那現(xiàn)在要解決的問題就是探針到應(yīng)用部署配置問題了。

這里我們使用了Kubernetes的pod部署的sidecar模式，單個(gè)應(yīng)用pod部署2個(gè)容器，利用單個(gè)pod中僅共享網(wǎng)絡(luò)的namespace的隔離特性，探針與應(yīng)用一同運(yùn)行，并可以使用localhost直接訪問應(yīng)用的端口，而在pod的注解中僅暴露探針的端口（prometheus.io/port: “9104”）即可。

Prometheus server根據(jù)配置匹配定義注解prometheus.io/scrape: “true”的pod，并將pod ip和注解中定義的端口（prometheus.io/port: “9104”）和路徑（prometheus.io/path: “/metrics”）拼接成采集目標(biāo)http://10.244.3.123:9104/metrics。通過這種方式就可以完成動(dòng)態(tài)添加需要采集的應(yīng)用。

關(guān)于監(jiān)控利器Prometheus怎么用問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。