Prometheus是繼Kubernetes(k8s)之后,CNCF畢業(yè)的第二個開源項目,其來源于Google的Borgmon。本文從“監(jiān)控”這件事說起,深入淺出Prometheus的架構(gòu)原理、目標發(fā)現(xiàn)、指標模型、聚合查詢等設(shè)計核心點。
一、前言
接觸過各式各樣的監(jiān)控,開源的CAT、Zipkin、Pinpoint等等,并深度二次開發(fā)過;也接觸過收費的聽云系A(chǔ)PM,對各類監(jiān)控的亮點與局限有足夠的了解。
去年10月我們快速落地了一套易用、靈活、有亮點的業(yè)務(wù)監(jiān)控平臺,其中使用到了Prometheus。從技術(shù)選型階段,Prometheus以及它的生態(tài)就讓我們印象深刻,今天就聊聊監(jiān)控設(shè)計與Prometheus。
通常一個監(jiān)控系統(tǒng)主要包含 采集(信息源:log、metrics)、上報(協(xié)議:http、tcp)、聚合、存儲、可視化以及告警等等。其中采集上報主要是客戶端的核心功能,一般有定期外圍探測的(早期的Nagios、Zabbix)、AOP方式手動織入代碼的(埋點)、字節(jié)碼自動織入等方式(無埋點)。
二、什么是監(jiān)控
一套產(chǎn)品化的,用來量化管理技術(shù)、業(yè)務(wù)的服務(wù)體系或解決方案。
這套產(chǎn)品主要解決兩個問題(產(chǎn)品價值):
技術(shù):將系統(tǒng)的各種功能、狀態(tài)等技術(shù)表現(xiàn)數(shù)據(jù)化、可視化,來保證技術(shù)體系的穩(wěn)定、安全等。
業(yè)務(wù):將各種業(yè)務(wù)表現(xiàn)數(shù)據(jù)化、可視化,以供分析、及時干預,保證業(yè)務(wù)高效開展。
三、監(jiān)控的基礎(chǔ)原則
事前監(jiān)控:架構(gòu)設(shè)計階段務(wù)必需要考慮監(jiān)控,而不是等到部署上線才去考慮
監(jiān)控什么:全局視角,自頂(業(yè)務(wù))向下。對于一般業(yè)務(wù)來講,建議先監(jiān)控離用戶最近的地方,用戶的良好體驗是推動業(yè)務(wù)發(fā)展的動力,這也是最敏感、重要的地方。
對用戶友好:監(jiān)控服務(wù)易用,易接入,盡可能自動化
技術(shù)人員、業(yè)務(wù)人員的信息源、能夠協(xié)助故障定位與解決
可視化:清晰的顯示各類數(shù)據(jù)(各類圖表展示),以及告警等信息記錄
告警:
哪些問題需要通知?(如:需要人工干預的,有意義的)
通知誰?(如:一線系統(tǒng)負責人)
如何通知?(如:短信、電話、其他通信工具;信息清晰、準確、可操作)
多久通知一次?(如:5分鐘)
何時停止通知以及何時升級到其他人?(如:已恢復正常;兩個小時問題未恢復,升級通知到上級負責人)
四、Prometheus設(shè)計剖析
Prometheu聚焦于當下正在發(fā)生的各類數(shù)據(jù),而不是追蹤數(shù)周以前的數(shù)據(jù),因為他們認為“大多數(shù)監(jiān)控查詢以及告警等都是一天內(nèi)的數(shù)據(jù)”,F(xiàn)acebook相關(guān)論文也驗證了這一點:85%的時序查詢是26小時之內(nèi)的。
簡單來概括,Prometheus是一個準實時監(jiān)控系統(tǒng),并自帶時序數(shù)據(jù)能力。
1. 整體架構(gòu)
Prometheus架構(gòu)圖(引用自Prometheus官網(wǎng))
簡化點的架構(gòu)圖如下:
Prometheus 主要通過pull的方式獲取被監(jiān)控程序(targetexports)中暴漏出來的時序數(shù)據(jù)。當然也提供了pushgateway服務(wù),一般少量數(shù)據(jù)也可以push方式發(fā)送。
2. 目標發(fā)現(xiàn)
Prometheus通過pull的方式獲取服務(wù)的指標數(shù)據(jù),那么它是如何發(fā)現(xiàn)這些服務(wù)的呢?
可以通過多種方式來處理目標資源的發(fā)現(xiàn):
2.1 人工的配置文件列表
通過手工方式,添加靜態(tài)配置,指定需要監(jiān)控的服務(wù),如下target塊:
prometheus.yml
scrape_configs:
。..。.
#監(jiān)控活動
- 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’,
。..。.. 。..。..]
#營銷
- job_name: ‘xxxxxx-sales-api’ metrics_path: /prometheus/metrics static_configs:
- targets: [‘10.xx.xx.xx:8080’,
。..。.. 。..。..
]
。..。..
顯而易見,這種方式雖然很簡單,但是在繁忙的工作中持續(xù)維護一長串服務(wù)主機列表并不是一個可擴展的優(yōu)雅方式,動態(tài)性、大規(guī)模會讓這種方式無法繼續(xù)下去。
指定加載目錄,這些目錄文件的變更將通過磁盤監(jiān)視檢測發(fā)現(xiàn),然后Prometheus會立即應(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’ #默認 5分鐘 refresh_interval:5m 。..。..
conf/oms-targets.json文件(此文件的變動將被監(jiān)聽,通常這個文件由另一個程序產(chǎn)生,如CMDB源):
oms-targets.json
[
{ “l(fā)abels”: { “job”: “oms-api” }, “targets”: [
‘ip1:8080’,‘ip2:8080’,。..。..
]
}
]
2.3 基于API的自動發(fā)現(xiàn)
當前可以用的本機服務(wù)發(fā)現(xiàn)插件有AmazonEC2、Azure、Consul、Kubernetes等等。
下文以Consul為例,實例啟動成功時可以通過腳本(或其他)方式將當前節(jié)點信息,注冊到Consul上(類似啟動后向zk或redis寫入當前節(jié)點信息)。Prometheus會實時的感知到Consul數(shù)據(jù)的變動,并自動去做熱加載。
prometheus.yml
#監(jiān)控 訂單中心OMS-API - job_name: ‘oms-api’ consul_sd_configs: #consul 地址,默認監(jiān)聽所有服務(wù)地址信息 - server: ‘xxxxxx’ services: []
注:Consul 是基于 GO 語言開發(fā)的開源工具,主要面向分布式,服務(wù)化的系統(tǒng)提供服務(wù)注冊、服務(wù)發(fā)現(xiàn)和配置管理的功能。Consul 提供服務(wù)注冊/發(fā)現(xiàn)、健康檢查、Key/Value存儲、多數(shù)據(jù)中心和分布式一致性保證等功能
2.4 基于DNS的自動發(fā)現(xiàn)
在前幾種方式都不適合的情況下,DNS服務(wù)發(fā)現(xiàn)允許你指定DNS條目列表,然后查詢這些條目中的記錄,以發(fā)現(xiàn)獲取目標列表。用的比較少,不贅述。
被監(jiān)控的目標成功被發(fā)現(xiàn)后,可以在自帶的web頁面上可視化查看,如圖(本地模擬環(huán)境):
3. 指標收集與聚合
Prometheus通過pull的方式拉取外部進程中的時序數(shù)據(jù)指標(Exporter),拉取過程細節(jié)允許用戶配置相關(guān)信息:如頻率、提前聚合規(guī)則、目標進程暴漏方式(http url)、如何連接、連接身份驗證等等。
指標
所謂指標就是軟件或硬件多種屬性的量化度量。有別于日志采集的那種ELK監(jiān)控,Prometheus通過四種指標類型完成:
(1)測量型(Gauge):可增可減的數(shù)字(本質(zhì)上是度量的快照)。常見的如內(nèi)存使用率。
(2)計數(shù)型(counter):只增不減,除非重置為0。比如某系統(tǒng)的HTTP請求量。
(3)直方圖(histogram):通過對監(jiān)控的指標點進行抽樣,展示數(shù)據(jù)分布頻率情況的類型。
上圖強調(diào)了分布情況對于理解延遲等指標的重要性。如果我們假設(shè)這個指標的SLO(服務(wù)等級目標)為150ms,那么137ms的平均延遲看起來是可以接受的;但實際上,每10個請求中就有1個在193ms以上完成,每100個請求中就有10個不達標!(如圖:90線、99線均不達標)
(4)摘要(summary):與Histogram非常類似,主要區(qū)別是summary在客戶端完成聚合,而Histogram在服務(wù)端完成。因此summary只適合不需要集中聚合的單體指標(如GC相關(guān)指標)。
三條經(jīng)驗法則:
如果需要多個采集節(jié)點的數(shù)據(jù)聚合、匯總,請選擇直方圖;
如果需要觀察多個采集節(jié)點數(shù)據(jù)的分布情況,請選擇直方圖;
如果不需要考慮集群(如GC相關(guān)信息),可選擇summary,它可以提供更加準確的分位數(shù)。
4. 聚合、查詢
內(nèi)置的數(shù)據(jù)查詢DSL語言:PromQL,它可以快速的支持聚合和多種形式的查詢,并通過自帶的web界面,可以快速在瀏覽器中查詢使用。在我們的實踐中,使用Grafana做可視化更加實用、美觀。
關(guān)于PromQL更多語法使用,可以查看官網(wǎng)文檔,不贅述。
關(guān)于指標聚合
對于指標的聚合,Prometheus提供了多種函數(shù)。以下列聚合指標為例:
平均數(shù)
中間數(shù)
百分位數(shù)(如下圖99線:百分之99的請求要低于12s這個值)
標準差(衡量數(shù)據(jù)集差異情況,0代表與平均數(shù)一樣,越大表示數(shù)據(jù)差異越大)
變化率
5. 數(shù)據(jù)模型
Prometheus與其他主流時序數(shù)據(jù)庫一樣,在數(shù)據(jù)模型定義上,也會包含metric name、一個或多個labels(同InfluxDB里的tags含義)以及metric value。
如用JSON表示一個時序數(shù)據(jù)庫中的原始時序數(shù)據(jù):
一個json表示的時序數(shù)據(jù)示例
##用JSON表示一個時序數(shù)據(jù)
{ “timestamp”: 1346846400, // 時間戳 “metric”: “total_website_visits”, // 指標名 “tags”:{ // 標簽組 “instance”: “aaa”, “job”: “job001” }, “value”: 18 // 指標值 }
metric name加一組labels作為唯一標識來定義time series(也就是時間線)。一旦label改變,則會創(chuàng)建新的時間序列,原有基于這個時間序列的配置將無效。在查詢時,支持根據(jù)labels條件查找time series,支持簡單的條件也支持復雜的條件。
上圖是所有數(shù)據(jù)點分布的一個簡單視圖,橫軸是時間,縱軸是時間線,區(qū)域內(nèi)每個點就是數(shù)據(jù)點。Prometheus每次接收數(shù)據(jù),收到的是圖中區(qū)域內(nèi)縱向的一條線。這個表述很形象,因為在同一時刻,每條時間線只會產(chǎn)生一個數(shù)據(jù)點,但同時會有多條時間線產(chǎn)生數(shù)據(jù),把這些數(shù)據(jù)點連在一起,就是一條豎線。這個特征很重要,影響數(shù)據(jù)寫入和壓縮的優(yōu)化策略。
保留時間
Prometheus專注于短期監(jiān)控、告警而設(shè)計,所以默認它只保存15天的時間序列數(shù)據(jù)。如果要更長期,建議考慮數(shù)據(jù)單獨存儲到其他平臺。目前我們的方案是遠端存儲,Prometheus拉取的數(shù)據(jù)會落到InfluxDB上,這樣保證了更好的存儲彈性,數(shù)據(jù)的實時落地存儲。
6.Prometheus開源生態(tài)
Prometheus生態(tài)系統(tǒng)包括了提供告警引擎、告警管理的AlertManager,支持push模式數(shù)據(jù)上報的PushGateWay,提供更優(yōu)雅美觀的可視化界面的Grafana,支持遠端存儲的RemoteStoreAdapter;log轉(zhuǎn)換為metric的Mtail等等。
除此之外,還有一系列Exporter(可以理解為監(jiān)控agent),這些Exporter可以直接安裝使用。自動監(jiān)控應(yīng)用程序、機器、主流數(shù)據(jù)庫、MQ等等。
Prometheus生態(tài)中還有一系列客戶端庫,支持各種主流編程語言Java、C、Python等等。
可以說Prometheus的生態(tài)是比較完善的,并且社區(qū)足夠活躍,未來可期。
編輯:hfy
-
DNS
+關(guān)注
關(guān)注
0文章
219瀏覽量
19938 -
監(jiān)控設(shè)計
+關(guān)注
關(guān)注
0文章
3瀏覽量
7125 -
Prometheus
+關(guān)注
關(guān)注
0文章
28瀏覽量
1732
發(fā)布評論請先 登錄
相關(guān)推薦
Prometheus的基本原理與開發(fā)指南
![<b class='flag-5'>Prometheus</b>的基本原理與開發(fā)指南](https://file1.elecfans.com/web2/M00/AE/F8/wKgZomVMSESAWJotAAAAjgjvZ2U667.png)
prometheus做監(jiān)控服務(wù)的整個流程介紹
使用Thanos+Prometheus+Grafana構(gòu)建監(jiān)控系統(tǒng)
監(jiān)控神器:Prometheus
關(guān)于Prometheus監(jiān)控系統(tǒng)相關(guān)的知識體系
prometheus下載安裝教程
![<b class='flag-5'>prometheus</b>下載安裝教程](https://file.elecfans.com/web2/M00/8B/1A/pYYBAGPBESyAAOteAACrlDGRN5o173.png)
兩種監(jiān)控工具prometheus和zabbix架構(gòu)對比
Prometheus存儲引擎簡析
基于kube-prometheus的大數(shù)據(jù)平臺監(jiān)控系統(tǒng)設(shè)計
40個步驟安裝部署Prometheus監(jiān)控系統(tǒng)
![40個步驟安裝部署<b class='flag-5'>Prometheus</b><b class='flag-5'>監(jiān)控</b>系統(tǒng)](https://file1.elecfans.com/web2/M00/90/6A/wKgaomTZpaaAIp3zAAAg_KYKbYM042.png)
基于Prometheus開源的完整監(jiān)控解決方案
![基于<b class='flag-5'>Prometheus</b>開源的完整<b class='flag-5'>監(jiān)控</b>解決方案](https://file1.elecfans.com/web2/M00/A8/EE/wKgaomUvMwCAazwnAAAiOxub22s048.png)
從零入門Prometheus:構(gòu)建企業(yè)級監(jiān)控與報警系統(tǒng)的最佳實踐指南
![<b class='flag-5'>從</b>零入門<b class='flag-5'>Prometheus</b>:構(gòu)建企業(yè)級<b class='flag-5'>監(jiān)控</b>與報警系統(tǒng)的最佳實踐指南](https://file1.elecfans.com/web3/M00/07/B0/wKgZO2epcqmAUC0TAAAucVlRH98601.png)
評論