Prometheus的架構(gòu)原理從“監(jiān)控”談起

Prometheus是繼Kubernetes（k8s）之后，CNCF畢業(yè)的第二個(gè)開源項(xiàng)目，其來源于Google的Borgmon。本文從“監(jiān)控”這件事說起，深入淺出Prometheus的架構(gòu)原理、目標(biāo)發(fā)現(xiàn)、指標(biāo)模型、聚合查詢等設(shè)計(jì)核心點(diǎn)。

一、前言

接觸過各式各樣的監(jiān)控，開源的CAT、Zipkin、Pinpoint等等，并深度二次開發(fā)過；也接觸過收費(fèi)的聽云系A(chǔ)PM，對(duì)各類監(jiān)控的亮點(diǎn)與局限有足夠的了解。

去年10月我們快速落地了一套易用、靈活、有亮點(diǎn)的業(yè)務(wù)監(jiān)控平臺(tái)，其中使用到了Prometheus。從技術(shù)選型階段，Prometheus以及它的生態(tài)就讓我們印象深刻，今天就聊聊監(jiān)控設(shè)計(jì)與Prometheus。

通常一個(gè)監(jiān)控系統(tǒng)主要包含 采集（信息源：log、metrics）、上報(bào)（協(xié)議：http、tcp）、聚合、存儲(chǔ)、可視化以及告警等等。其中采集上報(bào)主要是客戶端的核心功能，一般有定期外圍探測(cè)的（早期的Nagios、Zabbix）、AOP方式手動(dòng)織入代碼的（埋點(diǎn)）、字節(jié)碼自動(dòng)織入等方式（無埋點(diǎn)）。

二、什么是監(jiān)控

一套產(chǎn)品化的，用來量化管理技術(shù)、業(yè)務(wù)的服務(wù)體系或解決方案。

這套產(chǎn)品主要解決兩個(gè)問題（產(chǎn)品價(jià)值）：

技術(shù)：將系統(tǒng)的各種功能、狀態(tài)等技術(shù)表現(xiàn)數(shù)據(jù)化、可視化，來保證技術(shù)體系的穩(wěn)定、安全等。

業(yè)務(wù)：將各種業(yè)務(wù)表現(xiàn)數(shù)據(jù)化、可視化，以供分析、及時(shí)干預(yù)，保證業(yè)務(wù)高效開展。

三、監(jiān)控的基礎(chǔ)原則

事前監(jiān)控：架構(gòu)設(shè)計(jì)階段務(wù)必需要考慮監(jiān)控，而不是等到部署上線才去考慮

監(jiān)控什么：全局視角，自頂（業(yè)務(wù)）向下。對(duì)于一般業(yè)務(wù)來講，建議先監(jiān)控離用戶最近的地方，用戶的良好體驗(yàn)是推動(dòng)業(yè)務(wù)發(fā)展的動(dòng)力，這也是最敏感、重要的地方。

對(duì)用戶友好：監(jiān)控服務(wù)易用，易接入，盡可能自動(dòng)化

技術(shù)人員、業(yè)務(wù)人員的信息源、能夠協(xié)助故障定位與解決

可視化：清晰的顯示各類數(shù)據(jù)（各類圖表展示），以及告警等信息記錄

告警：

哪些問題需要通知？（如：需要人工干預(yù)的，有意義的）

通知誰？（如：一線系統(tǒng)負(fù)責(zé)人）

如何通知？（如：短信、電話、其他通信工具；信息清晰、準(zhǔn)確、可操作）

多久通知一次？（如：5分鐘）

何時(shí)停止通知以及何時(shí)升級(jí)到其他人？（如：已恢復(fù)正常；兩個(gè)小時(shí)問題未恢復(fù)，升級(jí)通知到上級(jí)負(fù)責(zé)人）

四、Prometheus設(shè)計(jì)剖析

Prometheu聚焦于當(dāng)下正在發(fā)生的各類數(shù)據(jù)，而不是追蹤數(shù)周以前的數(shù)據(jù)，因?yàn)樗麄冋J(rèn)為“大多數(shù)監(jiān)控查詢以及告警等都是一天內(nèi)的數(shù)據(jù)”，F(xiàn)acebook相關(guān)論文也驗(yàn)證了這一點(diǎn)：85%的時(shí)序查詢是26小時(shí)之內(nèi)的。

簡(jiǎn)單來概括，Prometheus是一個(gè)準(zhǔn)實(shí)時(shí)監(jiān)控系統(tǒng)，并自帶時(shí)序數(shù)據(jù)能力。

1. 整體架構(gòu)

Prometheus架構(gòu)圖（引用自Prometheus官網(wǎng)）

簡(jiǎn)化點(diǎn)的架構(gòu)圖如下：

Prometheus 主要通過pull的方式獲取被監(jiān)控程序（targetexports）中暴漏出來的時(shí)序數(shù)據(jù)。當(dāng)然也提供了pushgateway服務(wù)，一般少量數(shù)據(jù)也可以push方式發(fā)送。

2. 目標(biāo)發(fā)現(xiàn)

Prometheus通過pull的方式獲取服務(wù)的指標(biāo)數(shù)據(jù)，那么它是如何發(fā)現(xiàn)這些服務(wù)的呢？

可以通過多種方式來處理目標(biāo)資源的發(fā)現(xiàn)：

2.1 人工的配置文件列表

通過手工方式，添加靜態(tài)配置，指定需要監(jiān)控的服務(wù)，如下target塊：

prometheus.yml

scrape_configs：

。..。.

#監(jiān)控活動(dòng)

- job_name： ‘xxxxxxactivity-wap’ metrics_path： /prometheus/metrics static_configs：

- targets： ［‘10.xx.xx.xx:8080’，

。..。.. 。..。..］

#監(jiān)控優(yōu)惠券

- job_name： ‘xxxxxxshop-coupon’ metrics_path： /prometheus/metrics static_configs：

- targets： ［‘10.xx.xx.xx:8080’，

。..。.. 。..。..］

#營(yíng)銷

- job_name： ‘xxxxxx-sales-api’ metrics_path： /prometheus/metrics static_configs：

- targets： ［‘10.xx.xx.xx:8080’，

。..。.. 。..。..

］

。..。..

顯而易見，這種方式雖然很簡(jiǎn)單，但是在繁忙的工作中持續(xù)維護(hù)一長(zhǎng)串服務(wù)主機(jī)列表并不是一個(gè)可擴(kuò)展的優(yōu)雅方式，動(dòng)態(tài)性、大規(guī)模會(huì)讓這種方式無法繼續(xù)下去。

指定加載目錄，這些目錄文件的變更將通過磁盤監(jiān)視檢測(cè)發(fā)現(xiàn)，然后Prometheus會(huì)立即應(yīng)用這些變更。作為備用方案，文件內(nèi)容也將以指定的刷新間隔（refresh_interval）定期被Prometheus重新讀取，發(fā)現(xiàn)變更后生效。

示例如下：

prometheus.yml

。..。.. #監(jiān)控 訂單中心OMS-API scrape_configs： - job_name： ‘oms-api’ metrics_path： /prometheus/metrics file_sd_configs： - files： - ‘conf/oms-targets.json’ #默認(rèn) 5分鐘 refresh_interval:5m 。..。..

conf/oms-targets.json文件（此文件的變動(dòng)將被監(jiān)聽，通常這個(gè)文件由另一個(gè)程序產(chǎn)生，如CMDB源）：

oms-targets.json

［

{ “l(fā)abels”： { “job”： “oms-api” }， “targets”： ［

‘ip1:8080’，‘ip2:8080’，。..。..

］

}

］

2.3 基于API的自動(dòng)發(fā)現(xiàn)

當(dāng)前可以用的本機(jī)服務(wù)發(fā)現(xiàn)插件有AmazonEC2、Azure、Consul、Kubernetes等等。

下文以Consul為例，實(shí)例啟動(dòng)成功時(shí)可以通過腳本（或其他）方式將當(dāng)前節(jié)點(diǎn)信息，注冊(cè)到Consul上（類似啟動(dòng)后向zk或redis寫入當(dāng)前節(jié)點(diǎn)信息）。Prometheus會(huì)實(shí)時(shí)的感知到Consul數(shù)據(jù)的變動(dòng)，并自動(dòng)去做熱加載。

prometheus.yml

#監(jiān)控 訂單中心OMS-API - job_name： ‘oms-api’ consul_sd_configs： #consul 地址，默認(rèn)監(jiān)聽所有服務(wù)地址信息 - server： ‘xxxxxx’ services： ［］

注：Consul 是基于 GO 語言開發(fā)的開源工具，主要面向分布式，服務(wù)化的系統(tǒng)提供服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)和配置管理的功能。Consul 提供服務(wù)注冊(cè)/發(fā)現(xiàn)、健康檢查、Key/Value存儲(chǔ)、多數(shù)據(jù)中心和分布式一致性保證等功能

2.4 基于DNS的自動(dòng)發(fā)現(xiàn)

在前幾種方式都不適合的情況下，DNS服務(wù)發(fā)現(xiàn)允許你指定DNS條目列表，然后查詢這些條目中的記錄，以發(fā)現(xiàn)獲取目標(biāo)列表。用的比較少，不贅述。

被監(jiān)控的目標(biāo)成功被發(fā)現(xiàn)后，可以在自帶的web頁面上可視化查看，如圖（本地模擬環(huán)境）：

3. 指標(biāo)收集與聚合

Prometheus通過pull的方式拉取外部進(jìn)程中的時(shí)序數(shù)據(jù)指標(biāo)（Exporter），拉取過程細(xì)節(jié)允許用戶配置相關(guān)信息：如頻率、提前聚合規(guī)則、目標(biāo)進(jìn)程暴漏方式（http url）、如何連接、連接身份驗(yàn)證等等。

指標(biāo)

所謂指標(biāo)就是軟件或硬件多種屬性的量化度量。有別于日志采集的那種ELK監(jiān)控，Prometheus通過四種指標(biāo)類型完成：

（1）測(cè)量型（Gauge）：可增可減的數(shù)字（本質(zhì)上是度量的快照）。常見的如內(nèi)存使用率。

（2）計(jì)數(shù)型（counter）：只增不減，除非重置為0。比如某系統(tǒng)的HTTP請(qǐng)求量。

（3）直方圖（histogram）：通過對(duì)監(jiān)控的指標(biāo)點(diǎn)進(jìn)行抽樣，展示數(shù)據(jù)分布頻率情況的類型。

上圖強(qiáng)調(diào)了分布情況對(duì)于理解延遲等指標(biāo)的重要性。如果我們假設(shè)這個(gè)指標(biāo)的SLO（服務(wù)等級(jí)目標(biāo)）為150ms，那么137ms的平均延遲看起來是可以接受的;但實(shí)際上，每10個(gè)請(qǐng)求中就有1個(gè)在193ms以上完成，每100個(gè)請(qǐng)求中就有10個(gè)不達(dá)標(biāo)?。ㄈ鐖D：90線、99線均不達(dá)標(biāo)）

（4）摘要（summary）：與Histogram非常類似，主要區(qū)別是summary在客戶端完成聚合，而Histogram在服務(wù)端完成。因此summary只適合不需要集中聚合的單體指標(biāo)（如GC相關(guān)指標(biāo)）。

三條經(jīng)驗(yàn)法則：

如果需要多個(gè)采集節(jié)點(diǎn)的數(shù)據(jù)聚合、匯總，請(qǐng)選擇直方圖；

如果需要觀察多個(gè)采集節(jié)點(diǎn)數(shù)據(jù)的分布情況，請(qǐng)選擇直方圖；

如果不需要考慮集群（如GC相關(guān)信息），可選擇summary，它可以提供更加準(zhǔn)確的分位數(shù)。

4. 聚合、查詢

內(nèi)置的數(shù)據(jù)查詢DSL語言：PromQL，它可以快速的支持聚合和多種形式的查詢，并通過自帶的web界面，可以快速在瀏覽器中查詢使用。在我們的實(shí)踐中，使用Grafana做可視化更加實(shí)用、美觀。

關(guān)于PromQL更多語法使用，可以查看官網(wǎng)文檔，不贅述。

關(guān)于指標(biāo)聚合

對(duì)于指標(biāo)的聚合，Prometheus提供了多種函數(shù)。以下列聚合指標(biāo)為例：

平均數(shù)

中間數(shù)

百分位數(shù)（如下圖99線：百分之99的請(qǐng)求要低于12s這個(gè)值）

標(biāo)準(zhǔn)差（衡量數(shù)據(jù)集差異情況，0代表與平均數(shù)一樣，越大表示數(shù)據(jù)差異越大）

變化率

5. 數(shù)據(jù)模型

Prometheus與其他主流時(shí)序數(shù)據(jù)庫一樣，在數(shù)據(jù)模型定義上，也會(huì)包含metric name、一個(gè)或多個(gè)labels（同InfluxDB里的tags含義）以及metric value。

如用JSON表示一個(gè)時(shí)序數(shù)據(jù)庫中的原始時(shí)序數(shù)據(jù)：

一個(gè)json表示的時(shí)序數(shù)據(jù)示例

##用JSON表示一個(gè)時(shí)序數(shù)據(jù)

{ “timestamp”： 1346846400， // 時(shí)間戳 “metric”： “total_website_visits”， // 指標(biāo)名 “tags”：{ // 標(biāo)簽組 “instance”： “aaa”， “job”： “job001” }， “value”： 18 // 指標(biāo)值 }

metric name加一組labels作為唯一標(biāo)識(shí)來定義time series（也就是時(shí)間線）。一旦label改變，則會(huì)創(chuàng)建新的時(shí)間序列，原有基于這個(gè)時(shí)間序列的配置將無效。在查詢時(shí)，支持根據(jù)labels條件查找time series，支持簡(jiǎn)單的條件也支持復(fù)雜的條件。

上圖是所有數(shù)據(jù)點(diǎn)分布的一個(gè)簡(jiǎn)單視圖，橫軸是時(shí)間，縱軸是時(shí)間線，區(qū)域內(nèi)每個(gè)點(diǎn)就是數(shù)據(jù)點(diǎn)。Prometheus每次接收數(shù)據(jù)，收到的是圖中區(qū)域內(nèi)縱向的一條線。這個(gè)表述很形象，因?yàn)樵谕粫r(shí)刻，每條時(shí)間線只會(huì)產(chǎn)生一個(gè)數(shù)據(jù)點(diǎn)，但同時(shí)會(huì)有多條時(shí)間線產(chǎn)生數(shù)據(jù)，把這些數(shù)據(jù)點(diǎn)連在一起，就是一條豎線。這個(gè)特征很重要，影響數(shù)據(jù)寫入和壓縮的優(yōu)化策略。

保留時(shí)間

Prometheus專注于短期監(jiān)控、告警而設(shè)計(jì)，所以默認(rèn)它只保存15天的時(shí)間序列數(shù)據(jù)。如果要更長(zhǎng)期，建議考慮數(shù)據(jù)單獨(dú)存儲(chǔ)到其他平臺(tái)。目前我們的方案是遠(yuǎn)端存儲(chǔ)，Prometheus拉取的數(shù)據(jù)會(huì)落到InfluxDB上，這樣保證了更好的存儲(chǔ)彈性，數(shù)據(jù)的實(shí)時(shí)落地存儲(chǔ)。

6.Prometheus開源生態(tài)

Prometheus生態(tài)系統(tǒng)包括了提供告警引擎、告警管理的AlertManager，支持push模式數(shù)據(jù)上報(bào)的PushGateWay，提供更優(yōu)雅美觀的可視化界面的Grafana，支持遠(yuǎn)端存儲(chǔ)的RemoteStoreAdapter；log轉(zhuǎn)換為metric的Mtail等等。

除此之外，還有一系列Exporter（可以理解為監(jiān)控agent），這些Exporter可以直接安裝使用。自動(dòng)監(jiān)控應(yīng)用程序、機(jī)器、主流數(shù)據(jù)庫、MQ等等。

Prometheus生態(tài)中還有一系列客戶端庫，支持各種主流編程語言Java、C、Python等等。

可以說Prometheus的生態(tài)是比較完善的，并且社區(qū)足夠活躍，未來可期。
編輯：hfy