摘要：根據(jù)配置文件，對(duì)接收到的警報(bào)進(jìn)行處理，發(fā)出告警。在默認(rèn)情況下，用戶(hù)只需要部署多套，采集相同的即可實(shí)現(xiàn)基本的。通過(guò)將監(jiān)控與數(shù)據(jù)分離，能夠更好地進(jìn)行彈性擴(kuò)展。參考文檔本文為容器監(jiān)控實(shí)踐系列文章，完整內(nèi)容見(jiàn)

1.x版本的Prometheus的架構(gòu)圖為：

目前Prometheus版本為2.7，架構(gòu)圖為：

Prometheus從exporter拉取數(shù)據(jù)，或者間接地通過(guò)網(wǎng)關(guān)gateway拉取數(shù)據(jù)（如果在k8s內(nèi)部署，可以使用服務(wù)發(fā)現(xiàn)的方式），它默認(rèn)本地存儲(chǔ)抓取的所有數(shù)據(jù)，并通過(guò)一定規(guī)則進(jìn)行清理和整理數(shù)據(jù)，并把得到的結(jié)果存儲(chǔ)到新的時(shí)間序列中，采集到的數(shù)據(jù)有兩個(gè)去向，一個(gè)是報(bào)警，另一個(gè)是可視化。PromQL和其他API可視化地展示收集的數(shù)據(jù)，并通過(guò)Alertmanager提供報(bào)警能力。

Prometheus Server
負(fù)責(zé)從 Exporter 拉取和存儲(chǔ)監(jiān)控?cái)?shù)據(jù),并提供一套靈活的查詢(xún)語(yǔ)言（PromQL）

Retrieval: 采樣模塊

TSDB: 存儲(chǔ)模塊默認(rèn)本地存儲(chǔ)為tsdb

HTTP Server: 提供http接口查詢(xún)和面板，默認(rèn)端口為9090

Exporters/Jobs

負(fù)責(zé)收集目標(biāo)對(duì)象（host, container…）的性能數(shù)據(jù)，并通過(guò) HTTP 接口供 Prometheus Server 獲取。支持?jǐn)?shù)據(jù)庫(kù)、硬件、消息中間件、存儲(chǔ)系統(tǒng)、http服務(wù)器、jmx等。只要符合接口格式，就可以被采集。

Short-lived jobs

瞬時(shí)任務(wù)的場(chǎng)景，無(wú)法通過(guò)pull方式拉取，需要使用push方式，與PushGateway搭配使用

PushGateway

可選組件，主要用于短期的 jobs。由于這類(lèi) jobs 存在時(shí)間較短，可能在 Prometheus 來(lái) pull 之前就消失了。為此，這次 jobs 可以直接向 Prometheus server 端推送它們的 metrics。這種方式主要用于服務(wù)層面的 metrics，對(duì)于機(jī)器層面的 metrices，需要使用 node exporter。

客戶(hù)端sdk

官方提供的客戶(hù)端類(lèi)庫(kù)有g(shù)o、java、scala、python、ruby，其他還有很多第三方開(kāi)發(fā)的類(lèi)庫(kù)，支持nodejs、php、erlang等

PromDash

使用rails開(kāi)發(fā)的dashboard，用于可視化指標(biāo)數(shù)據(jù)，已廢棄

Alertmanager

從 Prometheus server 端接收到 alerts 后，會(huì)進(jìn)行去除重復(fù)數(shù)據(jù)，分組，并路由到對(duì)收的接受方式，發(fā)出報(bào)警。常見(jiàn)的接收方式有：電子郵件，pagerduty，OpsGenie, webhook 等。

Service Discovery

服務(wù)發(fā)現(xiàn)，Prometheus支持多種服務(wù)發(fā)現(xiàn)機(jī)制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服務(wù)發(fā)現(xiàn)的過(guò)程并不復(fù)雜，通過(guò)第三方提供的接口，Prometheus查詢(xún)到需要監(jiān)控的Target列表，然后輪訓(xùn)這些Target獲取監(jiān)控?cái)?shù)據(jù)。

其大概的工作流程是：

Prometheus server 定期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來(lái)自 Pushgateway 發(fā)過(guò)來(lái)的 metrics，或者從其他的 Prometheus server 中拉 metrics。

Prometheus server 在本地存儲(chǔ)收集到的 metrics，并運(yùn)行已定義好的 alert.rules，記錄新的時(shí)間序列或者向 Alertmanager 推送警報(bào)。

Alertmanager 根據(jù)配置文件，對(duì)接收到的警報(bào)進(jìn)行處理，發(fā)出告警。

在圖形界面中，可視化采集數(shù)據(jù)。

Prometheus采集數(shù)據(jù)是用的pull也就是拉模型,通過(guò)HTTP協(xié)議去采集指標(biāo)，只要應(yīng)用系統(tǒng)能夠提供HTTP接口就可以接入監(jiān)控系統(tǒng)，相比于私有協(xié)議或二進(jìn)制協(xié)議來(lái)說(shuō)開(kāi)發(fā)、簡(jiǎn)單。優(yōu)點(diǎn)主要是：

開(kāi)發(fā)任何新功能，你甚至可以在電腦上查看你的監(jiān)控

如果目標(biāo)實(shí)例掛掉，你可以很快知道

你可以手動(dòng)指定目標(biāo)實(shí)例，并且在瀏覽器中查看他的健康狀態(tài)

總體來(lái)說(shuō)，Pull模式比Push模式更好一些，在監(jiān)控系統(tǒng)中這也不是一個(gè)很重要的點(diǎn)。
如果要使用push的方式，可以使用Pushgateway的方式，如定時(shí)任務(wù)的采集。

對(duì)于定時(shí)任務(wù)這種短周期的指標(biāo)采集，如果采用pull模式，可能造成任務(wù)結(jié)束了，Prometheus還沒(méi)有來(lái)得及采集，這個(gè)時(shí)候可以使用加一個(gè)中轉(zhuǎn)層，客戶(hù)端推數(shù)據(jù)到Push Gateway緩存一下，由Prometheus從push gateway pull指標(biāo)過(guò)來(lái)。(需要額外搭建Push Gateway，同時(shí)需要新增job去從gateway采數(shù)據(jù))

推的代表有 ElasticSearch，InfluxDB，OpenTSDB 等，需要你從程序中將指標(biāo)使用 TCP，UDP 等方式推送至相關(guān)監(jiān)控應(yīng)用，只是使用 TCP 的話(huà)，一旦監(jiān)控應(yīng)用掛掉或存在瓶頸，容易對(duì)應(yīng)用本身產(chǎn)生影響，而使用 UDP 的話(huà)，雖然不用擔(dān)心監(jiān)控應(yīng)用，但是容易丟數(shù)據(jù)。

拉的代表，主要代表就是 Prometheus，讓我們不用擔(dān)心監(jiān)控應(yīng)用本身的狀態(tài)。而且，可以利用 DNS-SRV 或者 Consul 等服務(wù)發(fā)現(xiàn)功能就可以自動(dòng)添加監(jiān)控。

當(dāng)然，InfluxDB 加上 collector，或者 ES 加上 metricbeat 也可以變?yōu)?『拉』，而 Prometheus 加上 Push Gateway 也可以變?yōu)?『推』。

更多區(qū)別可以參考下圖：

Prometheus有著非常高效的時(shí)間序列數(shù)據(jù)存儲(chǔ)方法，每個(gè)采樣數(shù)據(jù)僅僅占用3.5byte左右空間，上百萬(wàn)條時(shí)間序列，30秒間隔，保留60天，大概花了200多G（引用官方PPT）。

Prometheus內(nèi)部主要分為三大塊，Retrieval是負(fù)責(zé)定時(shí)去暴露的目標(biāo)頁(yè)面上去抓取采樣指標(biāo)數(shù)據(jù)，Storage是負(fù)責(zé)將采樣數(shù)據(jù)寫(xiě)磁盤(pán)，PromQL是Prometheus提供的查詢(xún)語(yǔ)言模塊。

Prometheus內(nèi)置了一個(gè)基于本地存儲(chǔ)的時(shí)間序列數(shù)據(jù)庫(kù)。在Prometheus設(shè)計(jì)上，使用本地存儲(chǔ)可以降低Prometheus部署和管理的復(fù)雜度同時(shí)減少高可用（HA）帶來(lái)的復(fù)雜性。 在默認(rèn)情況下，用戶(hù)只需要部署多套Prometheus，采集相同的Targets即可實(shí)現(xiàn)基本的HA。同時(shí)由于Promethus高效的數(shù)據(jù)處理能力，單個(gè)Prometheus Server基本上能夠應(yīng)對(duì)大部分用戶(hù)監(jiān)控規(guī)模的需求。

同時(shí)為了適應(yīng)數(shù)據(jù)持久化的問(wèn)題，Prometheus提供了remote_write和remote_read的特性，支持將數(shù)據(jù)存儲(chǔ)到遠(yuǎn)端和從遠(yuǎn)端讀取數(shù)據(jù)。通過(guò)將監(jiān)控與數(shù)據(jù)分離，Prometheus能夠更好地進(jìn)行彈性擴(kuò)展。

關(guān)于存儲(chǔ)用量規(guī)劃：https://www.jianshu.com/p/934...
更多：Prometheus存儲(chǔ)機(jī)制詳解

https://yunlzheng.gitbook.io/...

https://www.cnblogs.com/vovli...

https://www.linuxidc.com/Linu...

https://segmentfault.com/a/11...

https://www.infoq.cn/article/...

不建議將日志監(jiān)控放在Prometheus中，這不是他的專(zhuān)長(zhǎng)，還是使用ELK或EFK的方式處理日志信息

參考: https://toutiao.io/posts/fsjq...

服務(wù)端度量指標(biāo)元數(shù)據(jù)支持
在度量指標(biāo)類(lèi)型和其他元數(shù)據(jù)僅僅在客戶(hù)庫(kù)和展示格式中使用，并不會(huì)在Prometheus服務(wù)中持久保留或者利用。將來(lái)我們計(jì)劃充分利用這些元數(shù)據(jù)。第一步是在Prometheus服務(wù)的內(nèi)存中聚合這些數(shù)據(jù)，并開(kāi)放一些實(shí)驗(yàn)性的API來(lái)提供服務(wù)

支持OpenMetrics

OpenMetrics組開(kāi)放了一個(gè)新的監(jiān)控指標(biāo)暴露標(biāo)準(zhǔn)，我們將支持這種標(biāo)準(zhǔn)：https://openmetrics.io/

回溯時(shí)間序列

允許將過(guò)去一段時(shí)間的數(shù)據(jù)發(fā)送到其他的監(jiān)控系統(tǒng)

HTTP服務(wù)支持TLS安全認(rèn)證

當(dāng)前的Prometheus, Alertmanager和一些官方exporter，暴露服務(wù)時(shí)，都不支持tls認(rèn)證，有很大的安全風(fēng)險(xiǎn)，現(xiàn)在的實(shí)現(xiàn)都是基于反向代理，之后將內(nèi)置到組件中

支持子查詢(xún)

當(dāng)前的Promq不支持子查詢(xún)，如max_over_time() of a rate())，后續(xù)將會(huì)支持

支持生態(tài)建設(shè)

Prometheus有很多的client庫(kù)和exporter，我們將會(huì)對(duì)其進(jìn)行規(guī)范和生態(tài)建設(shè)。

在之前的版本中，k8s默認(rèn)以及推薦的監(jiān)控體系是它自己的一套東西：Heapster + cAdvisor + Influxdb + Grafana，1.8后Heaspter由Metric-server替代。如果你部署了Dashboard，就能看到監(jiān)控?cái)?shù)據(jù)（來(lái)自heapster）

k8s 自身的 HPA (Horizontal Pod Autoscaler)，默認(rèn)從 Heapster 中獲取數(shù)據(jù)進(jìn)行自動(dòng)伸縮

1.8版本以后，K8S希望將核心監(jiān)控指標(biāo)收攏到metric api的形式，而自定義監(jiān)控指標(biāo)，由prometheus來(lái)實(shí)現(xiàn)，prometheus正式成為k8s推薦的監(jiān)控實(shí)現(xiàn)方案。

參考文檔：

https://www.ibm.com/developer...

https://prometheus.io/docs/in...

https://www.kancloud.cn/cdh08...

https://yunlzheng.gitbook.io/...

本文為容器監(jiān)控實(shí)踐系列文章，完整內(nèi)容見(jiàn)：container-monitor-book