Prometheus官方文檔
入門指導(dǎo)
- 手把手教你構(gòu)建Prometheus系統(tǒng)
- Prometheus Server
- Node Exporter
- The expression language
- Instrument code(使用Prometheus客戶端庫構(gòu)建應(yīng)用代碼，通過Prometheus監(jiān)控應(yīng)用)
- Dashboard
- Alerting
- Pushgateway
- 提出一些問題，這些問題有助于你對(duì)Prometheus的使用和理解
- 安排一些任務(wù)，通過完成這些任務(wù)(沒有答案)，幫助你使用Prometheus系統(tǒng)
- 文章相對(duì)比較老(2016.08.05, Prometheus < 2.0)，不過對(duì)入門來說很有參考價(jià)值
這個(gè)文章相對(duì)比較老，不過可以作為基于Docker部署Prometheus，Node Exporter，Grafana的入門參考：
- 使用Docker部署相關(guān)Prometheus組件
- Prometheus，Node Exporter，Grafana的簡單書用
- 例子中Prometheus的版本是2.0之前的，有些命令參數(shù)已經(jīng)不再使用了
博客
必讀。這篇博客對(duì)Prometheus整體做了一個(gè)概括性的、比較詳細(xì)的介紹(Prometheus起源于SoundCloud)：
- Prometheus的前世今生
- Pormetheus的設(shè)計(jì)哲學(xué)
- 文章相對(duì)比較老(2015.01.26)，有些內(nèi)容不適于Prometheus 2.0
Prometheus
- 對(duì)監(jiān)控系統(tǒng)來說，關(guān)鍵特性等級(jí)：可靠性>準(zhǔn)確性>一致性>持久性。監(jiān)控系統(tǒng)最重要的是可用性，沒必要依賴集群
- 集群更看中一致性，而不是可靠性；并且集群會(huì)有各種各樣的問題，很難保證可靠性
- 集群更適用于一個(gè)節(jié)點(diǎn)性能無法滿足需要的應(yīng)用，而Prometheus十分高效，不需要集群
- Prometheus的高可用性是通過運(yùn)行多個(gè)相同的Prometheus實(shí)例來實(shí)現(xiàn)的，實(shí)例之間獨(dú)立
- 多個(gè)獨(dú)立Prometheus實(shí)例，會(huì)造成數(shù)據(jù)有輕微的不一致。但是這個(gè)不一致，并不影響監(jiān)控、報(bào)警的正確性；也不會(huì)影響監(jiān)控?cái)?shù)據(jù)的準(zhǔn)確性。所以這個(gè)不一致，無所謂
- 警報(bào)需要處理警報(bào)中的噪聲
- 一天之后的監(jiān)控?cái)?shù)據(jù)針對(duì)監(jiān)控和報(bào)警來說，不會(huì)再有意義；當(dāng)然性能分析等等除外
- 基礎(chǔ)設(shè)施和服務(wù)down，不可避免，不用過于擔(dān)心；需要有個(gè)強(qiáng)壯的監(jiān)控系統(tǒng)
- 高可用
- 至少兩個(gè)同樣的Prometheus服務(wù)
- 使用Alertmanager本身提供的集群功能
- 配置所有的Prometheus實(shí)例與所有的Alertmanager通信
<relabel_config>配置是通過修改label來控制某些target不被抓取<metric_relabel_configs>配置是通過修改label來控制某些時(shí)間序列不被抓取<relabel_config>配置是通過修改label來控制某些alert不被發(fā)送給Alertmanager<relabel_config>配置是通過修改label來控制某些時(shí)間序列不被寫入遠(yuǎn)端- relabel行為中，
dropandkeep行為(特殊)類似與過濾器，如果label不匹配，相應(yīng)數(shù)據(jù)會(huì)被丟棄；而其它的relabel行為，會(huì)繼續(xù)處理數(shù)據(jù)(不論匹配與否)
- 一個(gè)單點(diǎn)的Prometheus能夠處理百萬級(jí)別的時(shí)間序列；也就是：上千個(gè)服務(wù)，每個(gè)服務(wù)上千個(gè)樣本，采集間隔10s
- 如果你有多個(gè)數(shù)據(jù)中心，希望能夠看到“全局”級(jí)別的聚合數(shù)據(jù)，需要使用Prometheus的聯(lián)盟功能
- 如果你的數(shù)據(jù)量很大(一個(gè)Prometheus性能無法滿足)，需要根據(jù)數(shù)據(jù)進(jìn)行分區(qū)(分片)；比如根據(jù)前端、后端、主機(jī)等，每一個(gè)分區(qū)一個(gè)Prometheus，再構(gòu)成Prometheus聯(lián)盟
- 如果數(shù)據(jù)量再大；再分，再聯(lián)盟
Alert
- Reduce Noise From Disk Space Alerts(August 7, 2015)
- 通過例子簡單介紹Prometheus警報(bào)規(guī)則語法
- 應(yīng)用Prometheus
predict_linear()函數(shù)作警報(bào)預(yù)測- Simple linear regression
- Alerting on Down Instances(September 1, 2015)
- 監(jiān)控、告警實(shí)例是否down (通過
upmetrics)- 監(jiān)控、告警down實(shí)例的百分比
- 簡單使用Blackbox Exporter (這個(gè)Exporter是個(gè)好東西)
- 簡單使用relabel功能
- 發(fā)送通知給webhook(使用webhook處理警報(bào)信息)
Alertmanager與之前版本的區(qū)別
- 通過路由規(guī)則樹處理警報(bào)，之前僅僅是列表(功能更強(qiáng)大)
- 可以通過模版定制化警報(bào)的通知(有默認(rèn)配置)
- 多條警報(bào)可以聚合成一條通知
- 配置Alertmanager，通過Gmail發(fā)送警報(bào)郵件
- Alertmanager默認(rèn)的警報(bào)信息模版，信息不夠詳細(xì)
- 問什么Prometheus和Alertmanager是分離的
- Prometheus十分注重可靠性而不是持久化
- 為什么不使用分布式數(shù)據(jù)庫(可靠性很難保證)
- 針對(duì)當(dāng)前分布式數(shù)據(jù)庫的研究--Jepsen
- 警報(bào)路由匹配時(shí)，當(dāng)匹配成功，其它路由規(guī)則就不會(huì)再處理該警報(bào)(一般情況)
*continue可以改變上述默認(rèn)行為，匹配成功之后會(huì)繼續(xù)匹配之后的規(guī)則，直至匹配成功
- 警報(bào)閾值，除了靜態(tài)配置外，還可以通過
recording rules或者exporter生成閾值時(shí)間序列(包含標(biāo)簽)- 閾值時(shí)間序列可以通過
group_left操作與相應(yīng)的時(shí)間序列匹配- 上述方法可以與 use labels to direct email notifications 結(jié)合使用(alertmanager可以更具label數(shù)據(jù)，動(dòng)態(tài)處理)
- A handy feature of the Alertmanager is that almost all notification fields are templatable. This can be used to route emails based on labels.
- 前提，目標(biāo)地址(比如，郵件目的地址)需要存在于標(biāo)簽集中：
mymetric{job="myjob",email_to="foo@example.org",instance="host1"}- Alertmanager需要配合做兩件事情：1、通過分組，確保每個(gè)目標(biāo)地址(比如，郵件地址)有對(duì)應(yīng)的通知；2、通過警報(bào)模版豐富通知內(nèi)容，發(fā)送給目標(biāo)地址
- Prometheus 2.0的一個(gè)主要改變是對(duì)
staleness的處理- Prometheus 2.0允許對(duì)消失的
targets和 時(shí)間序列進(jìn)行跟蹤- 上述變化會(huì)影響警報(bào)規(guī)則的創(chuàng)建，比如，如何監(jiān)控實(shí)例是否down：用
avg_over_time(up{job="jobname"} [5m]) < 0.9，替換up{job="jobname"} < 1。否則會(huì)引起誤報(bào)或者不報(bào)
- 監(jiān)控應(yīng)用頻繁的重啟
- Prometheus客戶端庫會(huì)提供
process_start_time_secondsmetric，表示進(jìn)程的開始時(shí)間(如果進(jìn)程重啟，這個(gè)時(shí)間序列的值就會(huì)變化)avg without(instance)(changes(process_start_time_seconds[1h]))：一個(gè)job一個(gè)小時(shí)內(nèi)重啟的平均次數(shù)- 如果進(jìn)程重啟頻率高于采集頻率，上述數(shù)據(jù)會(huì)丟失部分(不過對(duì)監(jiān)控沒有影響)
- 上述監(jiān)控方法依賴于：目標(biāo)的label集不變(盡管應(yīng)用重啟)
- 帶寬的限制
- 額外的工作
- 通知中可以包含dashboard的鏈接，而不是曲線圖本身
- 如何正確的使用警報(bào)系統(tǒng)是一門藝術(shù)，少而精
- 警報(bào)不能太少(無法有效的監(jiān)控)，也不能太多(噪聲太多，無法有效的抓住問題重點(diǎn))
- 即要有當(dāng)前狀態(tài)警報(bào)，也要有預(yù)測警報(bào)
- 嚴(yán)重問題的警報(bào)、需要立即修復(fù)問題的警報(bào)
- 關(guān)于用戶體驗(yàn)的警報(bào)，是非常重要的警報(bào)
- 在線服務(wù)警報(bào)：alerting on conditions like high latency and error rates as high up in the stack as possible
- 針對(duì)容量警報(bào)(比如，磁盤)：alerts to detect when you will run out of space that will lead to an outage.
- 批量任務(wù)警報(bào)：alert when a job has not succeeded recently enough
- 警報(bào)通知需要有相應(yīng)dashboard的鏈接，為oncall提供數(shù)據(jù)支持
- 監(jiān)控監(jiān)控系統(tǒng)本身
- 使用
Black Exporter監(jiān)控服務(wù)宕機(jī)的時(shí)長
Metrics
- 由于
up不是來源于scrape本身，metric_relabel_configs不適用于它- 只要
service discovery能夠返回target，up的值就是1(不論真實(shí)的實(shí)例是否真的存在)- 有類似于
up的metrics，以scrape_開頭- 除了
up，有時(shí)有必要使用Blackbox Exporter來檢測target的健康情況
Alert補(bǔ)充資料
一個(gè)有著7年oncall經(jīng)驗(yàn)的人(Rob Ewaschuk)對(duì)警報(bào)系統(tǒng)使用的經(jīng)驗(yàn)總結(jié)。
- 警報(bào)分類(類型、級(jí)別，通知方式)
- 警報(bào)規(guī)則創(chuàng)建指導(dǎo)
- 警報(bào)處理的完整流程
思考
- How to have alerts to ensure that Prometheus servers, Alertmanagers, PushGateways, and other monitoring infrastructure are available and running correctly?
