主流監(jiān)控系統(tǒng) Prometheus 學(xué)習(xí)指南
Prometheus 是一個(gè)開(kāi)源的完整監(jiān)控解決方案,本文將從指標(biāo)抓取到查詢(xún)及可視化展示,以及最后的監(jiān)控告警,對(duì) Prometheus 做一個(gè)基本的認(rèn)識(shí)。
—?1?—
Prometheus 是古希臘神話(huà)里泰坦族的一名神明,名字的意思是“先見(jiàn)之明”,下圖中是 Prometheus 被宙斯懲罰,飽受肝臟日食夜長(zhǎng)之苦。

下面就是我們 CRUD Boy 所了解的 Prometheus,其官網(wǎng)封面圖引導(dǎo)語(yǔ):From metrics to insight,從指標(biāo)到洞察力,通過(guò)指標(biāo)去洞察你的系統(tǒng),為我們的系統(tǒng)提供指標(biāo)收集和監(jiān)控的開(kāi)源解決方案。也就是說(shuō),Prometheus 是一個(gè)數(shù)據(jù)監(jiān)控的解決方案,讓我們能隨時(shí)掌握系統(tǒng)運(yùn)行的狀態(tài),快速定位問(wèn)題和排除故障。

Prometheus 發(fā)展速度很快,12 年開(kāi)發(fā)完成,16 年加入 CNCF,成為繼 Kubernetes?之后第二個(gè) CNCF 托管的項(xiàng)目,目前 GitHub 42k 的 ??,而且社區(qū)很活躍,維護(hù)頻率很高,基本穩(wěn)定在 1 個(gè)月 1 個(gè)小版本的迭代速度。

—?2?—
Prometheus 提供了從指標(biāo)暴露,到指標(biāo)抓取、存儲(chǔ)和可視化,以及最后的監(jiān)控告警等一系列組件。

指標(biāo)暴露
每一個(gè)被 Prometheus 監(jiān)控的服務(wù)都是一個(gè) Job,Prometheus 為這些 Job 提供了官方的 SDK ,利用這個(gè) SDK 可以自定義并導(dǎo)出自己的業(yè)務(wù)指標(biāo),也可以使用 Prometheus 官方提供的各種常用組件和中間件的 Exporter(比如常用的 MySQL,Consul 等等)。
對(duì)于短時(shí)間執(zhí)行的腳本任務(wù)或者不好直接 Pull 指標(biāo)的服務(wù),Prometheus 提供了 PushGateWay 網(wǎng)關(guān)給這些任務(wù)將服務(wù)指標(biāo)主動(dòng)推 Push 到網(wǎng)關(guān),Prometheus 再?gòu)倪@個(gè)網(wǎng)關(guān)里 Pull 指標(biāo)。
指標(biāo)抓取
上面提到了 Push 和 Pull,其實(shí)這是兩種指標(biāo)抓取模型。
Pull 模型:監(jiān)控服務(wù)主動(dòng)拉取被監(jiān)控服務(wù)的指標(biāo)。

被監(jiān)控服務(wù)一般通過(guò)主動(dòng)暴露 metrics 端口或者通過(guò) Exporter 的方式暴露指標(biāo),監(jiān)控服務(wù)依賴(lài)服務(wù)發(fā)現(xiàn)模塊發(fā)現(xiàn)被監(jiān)控服務(wù),從而去定期的抓取指標(biāo)。
Push 模型:被監(jiān)控服務(wù)主動(dòng)將指標(biāo)推送到監(jiān)控服務(wù),可能需要對(duì)指標(biāo)做協(xié)議適配,必須得符合監(jiān)控服務(wù)要求的指標(biāo)格式。

對(duì)于 Prometheus 中的指標(biāo)抓取,采用的是 Pull 模型,默認(rèn)是一分鐘去拉取一次指標(biāo),通過(guò) Prometheus.yaml 配置文件中的 scrape_interval 配置項(xiàng)配置,Prometheus 對(duì)外都是用的 Pull 模型,一個(gè)是 Pull Exporter 的暴露的指標(biāo),一個(gè)是 Pull PushGateway 暴露的指標(biāo)。
指標(biāo)存儲(chǔ)和查詢(xún)
指標(biāo)抓取后會(huì)存儲(chǔ)在內(nèi)置的時(shí)序數(shù)據(jù)庫(kù)中,Prometheus 也提供了 PromQL 查詢(xún)語(yǔ)言給我們做指標(biāo)的查詢(xún),我們可以在 Prometheus 的 WebUI 上通過(guò) PromQL,可視化查詢(xún)我們的指標(biāo),也可以很方便的接入第三方的可視化工具,例如 Grafana。
監(jiān)控告警
Prometheus 提供了 Alertmanageer 基于 PromQL?來(lái)做系統(tǒng)的監(jiān)控告警,當(dāng) PromQL 查詢(xún)出來(lái)的指標(biāo)超過(guò)我們定義的閾值時(shí),Prometheus 會(huì)發(fā)送一條告警信息到 Alertmanager,manager 會(huì)將告警下發(fā)到配置好的郵箱或者微信。
—?3?—
Prometheus 的從被監(jiān)控服務(wù)的注冊(cè)到指標(biāo)抓取到指標(biāo)查詢(xún)的流程分為五個(gè)步驟:

服務(wù)注冊(cè)
被監(jiān)控服務(wù)在 Prometheus 中是一個(gè) Job 存在,被監(jiān)控服務(wù)的所有實(shí)例在 Prometheus 中是一個(gè) target 的存在,所以被監(jiān)控服務(wù)的注冊(cè)就是在 Prometheus 中注冊(cè)一個(gè) Job 和其所有的 target,這個(gè)注冊(cè)分為:
靜態(tài)注冊(cè)
動(dòng)態(tài)注冊(cè)
靜態(tài)注冊(cè):靜態(tài)的將服務(wù)的 IP 和抓取指標(biāo)的端口號(hào)配置在 Prometheus yaml 文件的 scrape_configs 配置下:
scrape_configs:
?-?job_name:?"prometheus"
???static_configs:
???-?targets:?["localhost:9090"]
以上就是注冊(cè)了一個(gè)名為 Prometheus 的服務(wù),這個(gè)服務(wù)下有一個(gè)實(shí)例,暴露的抓取地址是 localhost:9090。
動(dòng)態(tài)注冊(cè):動(dòng)態(tài)注冊(cè)就是在 Prometheus yaml 文件的 scrape_configs 配置下配置服務(wù)發(fā)現(xiàn)的地址和服務(wù)名,Prometheus 會(huì)去該地址,根據(jù)你提供的服務(wù)名動(dòng)態(tài)發(fā)現(xiàn)實(shí)例列表,在 Prometheus 中,支持 Consul、DNS、文件、Kubernetes?等多種服務(wù)發(fā)現(xiàn)機(jī)制。
基于 Consul 的服務(wù)發(fā)現(xiàn):
?-?job_name:?"node_export_consul"
??metrics_path:?/node_metrics
??scheme:?http
??consul_sd_configs:
???-?server:?localhost:8500
?????services:
?????-?node_exporter
我們 Consul 的地址就是:localhost:8500,服務(wù)名是 node_exporter,在這個(gè)服務(wù)下有一個(gè) exporter 實(shí)例:localhost:9600。

注意:如果是動(dòng)態(tài)注冊(cè),最好加上這兩配置,靜態(tài)注冊(cè)指標(biāo)拉取的路徑會(huì)默認(rèn)的幫我們指定為 metrics_path:/metrics,所以如果暴露的指標(biāo)抓取路徑不同或者是動(dòng)態(tài)的服務(wù)注冊(cè),最好加上這兩個(gè)配置。不然會(huì)報(bào)錯(cuò)“INVALID?is not a valid start token”,演示下,百度了一下,這里可能是數(shù)據(jù)格式不統(tǒng)一導(dǎo)致。
metrics_path:?/node_metrics
scheme:?http
最后可以在 WebUI 中查看發(fā)現(xiàn)的實(shí)例:

目前,Prometheus 支持多達(dá)二十多種服務(wù)發(fā)現(xiàn)協(xié)議:
在更新完 Prometheus 的配置文件后,我們需要更新我們的配置到程序內(nèi)存里,這里的更新方式有兩種,第一種簡(jiǎn)單粗暴,就是重啟 Prometheus,第二種是動(dòng)態(tài)更新的方式。如何實(shí)現(xiàn)動(dòng)態(tài)的更新 Prometheus 配置。
第一步:首先要保證啟動(dòng) Prometheus 的時(shí)候帶上啟動(dòng)參數(shù):--web.enable-lifecycle。
prometheus?--config.file=/usr/local/etc/prometheus.yml?--web.enable-lifecycle
第二步:去更新我們的 Prometheus 配置。
第三步:更新完配置后,我們可以通過(guò) Post 請(qǐng)求的方式,動(dòng)態(tài)更新配置:
curl?-v?--request?POST?'http://localhost:9090/-/reload'
原理:
Prometheus 在 Web 模塊中,注冊(cè)了一個(gè) handler:
if?o.EnableLifecycle?{
??router.Post("/-/quit",?h.quit)
??router.Put("/-/quit",?h.quit)
??router.Post("/-/reload",?h.reload)?//?reload配置
??router.Put("/-/reload",?h.reload)
}
通過(guò) h.reload 這個(gè) handler 方法實(shí)現(xiàn):這個(gè) handler 就是往一個(gè) channle 中發(fā)送一個(gè)信號(hào):
func?(h?*Handler)?reload(w?http.ResponseWriter,?r?*http.Request)?{
??rc?:=?make(chan?error)
??h.reloadCh?<-?rc??//?發(fā)送一個(gè)信號(hào)到channe了中
??if?err?:=?<-rc;?err?!=?nil?{
???http.Error(w,?fmt.Sprintf("failed?to?reload?config:?%s",?err),?http.StatusInternalServerError)
??}
}
在 main 函數(shù)中會(huì)去監(jiān)聽(tīng)這個(gè) channel,只要有監(jiān)聽(tīng)到信號(hào),就會(huì)做配置的 reload,重新將新配置加載到內(nèi)存中:
case?rc?:=?<-webHandler.Reload():
??if?err?:=?reloadConfig(cfg.configFile,?cfg.enableExpandExternalLabels,?cfg.tsdb.EnableExemplarStorage,?logger,?noStepSubqueryInterval,?reloaders...);?err?!=?nil?{
???level.Error(logger).Log("msg",?"Error?reloading?config",?"err",?err)
???rc?<-?err
??}?else?{
???rc?<-?nil
??}
Prometheus 對(duì)指標(biāo)的抓取采取主動(dòng) Pull 的方式,即周期性的請(qǐng)求被監(jiān)控服務(wù)暴露的 Metrics 接口或者是 PushGateway,從而獲取到 Metrics 指標(biāo),默認(rèn)時(shí)間是 15s 抓取一次,配置項(xiàng)如下:
global:
?scrape_interval:?15s
抓取到的指標(biāo)會(huì)被以時(shí)間序列的形式保存在內(nèi)存中,并且定時(shí)刷到磁盤(pán)上,默認(rèn)是兩個(gè)小時(shí)回刷一次。并且為了防止 Prometheus 發(fā)生崩潰或重啟時(shí)能夠恢復(fù)數(shù)據(jù),Prometheus 也提供了類(lèi)似 MySQL 中 binlog 一樣的預(yù)寫(xiě)日志,當(dāng) Prometheus 崩潰重啟時(shí),會(huì)讀這個(gè)預(yù)寫(xiě)日志來(lái)恢復(fù)數(shù)據(jù)。
—?4?—
數(shù)據(jù)模型

Prometheus 采集的所有指標(biāo)都是以時(shí)間序列的形式進(jìn)行存儲(chǔ),每一個(gè)時(shí)間序列有三部分組成:
指標(biāo)名和指標(biāo)標(biāo)簽集合:metric_name{
, ....},指標(biāo)名:表示這個(gè)指標(biāo)是監(jiān)控哪一方面的狀態(tài),比如 http_request_total 表示請(qǐng)求數(shù)量;指標(biāo)標(biāo)簽:描述這個(gè)指標(biāo)有哪些維度,比如 http_request_total 這個(gè)指標(biāo),有請(qǐng)求狀態(tài)碼 code = 200/400/500,請(qǐng)求方式 method = get/post 等,實(shí)際上指標(biāo)名稱(chēng)實(shí)際上是以標(biāo)簽的形式保存,這個(gè)標(biāo)簽是 name,即:name=。 時(shí)間戳:描述當(dāng)前時(shí)間序列的時(shí)間,單位:毫秒。
樣本值:當(dāng)前監(jiān)控指標(biāo)的具體數(shù)值,比如 http_request_total 的值就是請(qǐng)求數(shù)是多少。
可以通過(guò)查看 Prometheus 的 Metrics 接口查看所有上報(bào)的指標(biāo):

所有的指標(biāo)也都是通過(guò)如下所示的格式來(lái)標(biāo)識(shí)的:
# HELP ?// HELP:這里描述的指標(biāo)的信息,表示這個(gè)是一個(gè)什么指標(biāo),統(tǒng)計(jì)什么的
# TYPE ?// TYPE:這個(gè)指標(biāo)是什么類(lèi)型的{
Prometheus 底層存儲(chǔ)上其實(shí)并沒(méi)有對(duì)指標(biāo)做類(lèi)型的區(qū)分,都是以時(shí)間序列的形式存儲(chǔ),但是為了方便用戶(hù)的使用和理解不同監(jiān)控指標(biāo)之間的差異,Prometheus 定義了 4 種不同的指標(biāo)類(lèi)型:計(jì)數(shù)器 counter,儀表盤(pán) gauge,直方圖 histogram,摘要 summary。
Docker+K8s+Jenkins 主流技術(shù)全解視頻資料

Counter 計(jì)數(shù)器:
Counter 類(lèi)型和 Redis 的自增命令一樣,只增不減,通過(guò) Counter 指標(biāo)可以統(tǒng)計(jì) Http 請(qǐng)求數(shù)量,請(qǐng)求錯(cuò)誤數(shù),接口調(diào)用次數(shù)等單調(diào)遞增的數(shù)據(jù)。同時(shí)可以結(jié)合 increase 和 rate 等函數(shù)統(tǒng)計(jì)變化速率,后續(xù)我們會(huì)提到這些內(nèi)置函數(shù)。

Gauge 儀表盤(pán):
和 Counter 不同,Gauge 是可增可減的,可以反映一些動(dòng)態(tài)變化的數(shù)據(jù),例如當(dāng)前內(nèi)存占用,CPU 利用,Gc 次數(shù)等動(dòng)態(tài)可上升可下降的數(shù)據(jù),在 Prometheus 上通過(guò) Gauge,可以不用經(jīng)過(guò)內(nèi)置函數(shù)直觀的反映數(shù)據(jù)的變化情況,如下圖表示堆可分配的空間大小:

上面兩種是數(shù)值指標(biāo),代表數(shù)據(jù)的變化情況,Histogram 和 Summary 是統(tǒng)計(jì)類(lèi)型的指標(biāo),表示數(shù)據(jù)的分布情況。
Histogram 直方圖:
Histogram 是一種直方圖類(lèi)型,可以觀察到指標(biāo)在各個(gè)不同的區(qū)間范圍的分布情況,如下圖所示:可以觀察到請(qǐng)求耗時(shí)在各個(gè)桶的分布。

有一點(diǎn)要注意的是,Histogram 是累計(jì)直方圖,即每一個(gè)桶的是只有上區(qū)間,例如下圖表示小于 0.1 毫秒(le="0.1")的請(qǐng)求數(shù)量是 18173 個(gè),小于 0.2 毫秒(le="0.2")的請(qǐng)求是 18182 個(gè),在 le="0.2" 這個(gè)桶中是包含了 le="0.1"這個(gè)桶的數(shù)據(jù),如果我們要拿到 0.1 毫秒到 0.2 毫秒的請(qǐng)求數(shù)量,可以通過(guò)兩個(gè)桶想減得到。

在直方圖中,還可以通過(guò) histogram_quantile 函數(shù)求出百分位數(shù),比如 P50、P90、P99 等數(shù)據(jù)。
Summary 摘要:
Summary 也是用來(lái)做統(tǒng)計(jì)分析的,和 Histogram 區(qū)別在于,Summary 直接存儲(chǔ)的就是百分位數(shù),如下所示:可以直觀的觀察到樣本的中位數(shù),P90 和 P99。

Summary 的百分位數(shù)是客戶(hù)端計(jì)算好直接讓 Prometheus 抓取的,不需要 Prometheus 計(jì)算,直方圖是通過(guò)內(nèi)置函數(shù) histogram_quantile 在 Prometheus 服務(wù)端計(jì)算求出。
指標(biāo)導(dǎo)出
指標(biāo)導(dǎo)出有兩種方式,一種是使用 Prometheus 社區(qū)提供的定制好的 Exporter 對(duì)一些組件諸如 MySQL,Kafka 等的指標(biāo)作導(dǎo)出,也可以利用社區(qū)提供的 Client 來(lái)自定義指標(biāo)導(dǎo)出。
github.com/prometheus/client_golang/prometheus/promhttp
自定義 Prometheus exporter:
package?main
import?(
??"net/http"
??"github.com/prometheus/client_golang/prometheus/promhttp"
)
func?main()?{
??http.Handle("/metrics",?promhttp.Handler())
??http.ListenAndServe(":8080",?nil)
}
訪問(wèn):http://localhost:8080/metrics,即可看到導(dǎo)出的指標(biāo),這里我們沒(méi)有自定義任何的指標(biāo),但是能看到一些內(nèi)置的 Go 的運(yùn)行時(shí)指標(biāo)和 promhttp 相關(guān)的指標(biāo),這個(gè) Client 默認(rèn)為我們暴露的指標(biāo),go_:以 go 為前綴的指標(biāo)是關(guān)于 Go 運(yùn)行時(shí)相關(guān)的指標(biāo),比如垃圾回收時(shí)間、goroutine 數(shù)量等,這些都是 Go 客戶(hù)端庫(kù)特有的,其他語(yǔ)言的客戶(hù)端庫(kù)可能會(huì)暴露各自語(yǔ)言的其他運(yùn)行時(shí)指標(biāo)。
promhttp:來(lái)自 promhttp 工具包的相關(guān)指標(biāo),用于跟蹤對(duì)指標(biāo)請(qǐng)求的處理。


添加自定義指標(biāo):
package?main
import?(
??"net/http"
??"github.com/prometheus/client_golang/prometheus"
??"github.com/prometheus/client_golang/prometheus/promhttp"
)
func?main()?{
??//?1.定義指標(biāo)(類(lèi)型,名字,幫助信息)
??myCounter?:=?prometheus.NewCounter(prometheus.CounterOpts{
???Name:?"my_counter_total",
???Help:?"自定義counter",
??})
??//?2.注冊(cè)指標(biāo)
??prometheus.MustRegister(myCounter)
??//?3.設(shè)置指標(biāo)值
??myCounter.Add(23)
??http.Handle("/metrics",?promhttp.Handler())
??http.ListenAndServe(":8080",?nil)
}
運(yùn)行:

模擬下在業(yè)務(wù)中上報(bào)接口請(qǐng)求量:
package?main
import?(
??"fmt"
??"net/http"
??"github.com/prometheus/client_golang/prometheus"
)
var?(
??MyCounter?prometheus.Counter
)
//?init?注冊(cè)指標(biāo)
func?init()?{
??//?1.定義指標(biāo)(類(lèi)型,名字,幫助信息)
??MyCounter?=?prometheus.NewCounter(prometheus.CounterOpts{
???Name:?"my_counter_total",
???Help:?"自定義counter",
??})
??//?2.注冊(cè)指標(biāo)
??prometheus.MustRegister(MyCounter)
}
//?Sayhello
func?Sayhello(w?http.ResponseWriter,?r?*http.Request)?{
??//?接口請(qǐng)求量遞增
??MyCounter.Inc()
??fmt.Fprintf(w,?"Hello?Wrold!")
}
main.go:
package?main
import?(
??"net/http"
??"github.com/prometheus/client_golang/prometheus/promhttp"
)
func?main()?{
??http.Handle("/metrics",?promhttp.Handler())
??http.HandleFunc("/counter",Sayhello)
??http.ListenAndServe(":8080",?nil)
}
一開(kāi)始啟動(dòng)時(shí),指標(biāo) counter 是 0:

調(diào)用:/counter 接口后,指標(biāo)數(shù)據(jù)發(fā)生了變化,這樣就可以簡(jiǎn)單實(shí)現(xiàn)了接口請(qǐng)求數(shù)的統(tǒng)計(jì):

對(duì)于其他指標(biāo)定義方式是一樣的:
var?(
??MyCounter?prometheus.Counter
??MyGauge?prometheus.Gauge
??MyHistogram?prometheus.Histogram
??MySummary?prometheus.Summary
)
//?init?注冊(cè)指標(biāo)
func?init()?{
??//?1.定義指標(biāo)(類(lèi)型,名字,幫助信息)
??MyCounter?=?prometheus.NewCounter(prometheus.CounterOpts{
???Name:?"my_counter_total",
???Help:?"自定義counter",
??})
??//?定義gauge類(lèi)型指標(biāo)
??MyGauge?=?prometheus.NewGauge(prometheus.GaugeOpts{
???Name:?"my_gauge_num",
???Help:?"自定義gauge",
??})
??//?定義histogram
??MyHistogram?=?prometheus.NewHistogram(prometheus.HistogramOpts{
???Name:?"my_histogram_bucket",
???Help:?"自定義histogram",
???Buckets:?[]float64{0.1,0.2,0.3,0.4,0.5},??//?需要指定桶
??})
??//?定義Summary
??MySummary?=?prometheus.NewSummary(prometheus.SummaryOpts{
???Name:?"my_summary_bucket",
???Help:?"自定義summary",
???//?這部分可以算好后在set
???Objectives:?map[float64]float64{
?????0.5:?0.05,
?????0.9:?0.01,
?????0.99:?0.001,
???},
??})
??//?2.注冊(cè)指標(biāo)
??prometheus.MustRegister(MyCounter)
??prometheus.MustRegister(MyGauge)
??prometheus.MustRegister(MyHistogram)
??prometheus.MustRegister(MySummary)
}

上面的指標(biāo)都是沒(méi)有設(shè)置標(biāo)簽的,我們一般的指標(biāo)都是帶有標(biāo)簽的,如何設(shè)置指標(biāo)的標(biāo)簽?zāi)兀?/span>
如果我要設(shè)置帶標(biāo)簽的 counter 類(lèi)型指標(biāo),只需要將原來(lái)的 NewCounter 方法替換為 NewCounterVec 方法即可,并且傳入標(biāo)簽集合。
MyCounter?*prometheus.CounterVec
//?1.定義指標(biāo)(類(lèi)型,名字,幫助信息)
MyCounter?=?prometheus.NewCounterVec(
??prometheus.CounterOpts{
??Name:?"my_counter_total",
??Help:?"自定義counter",
??},
??//?標(biāo)簽集合
??[]string{"label1","label2"},
)
//?帶標(biāo)簽的set指標(biāo)值
MyCounter.With(prometheus.Labels{"label1":"1","label2":"2"}).Inc()

其他同理。
—?5?—
剛剛提到了 Prometheus 中指標(biāo)有哪些類(lèi)型以及如何導(dǎo)出我們的指標(biāo),現(xiàn)在指標(biāo)導(dǎo)出到 Prometheus 了,利用其提供的 PromQL 可以查詢(xún)我們導(dǎo)出的指標(biāo)。
PromQL 是 Prometheus 為我們提供的函數(shù)式的查詢(xún)語(yǔ)言,查詢(xún)表達(dá)式有四種類(lèi)型:
字符串:只作為某些內(nèi)置函數(shù)的參數(shù)出現(xiàn)
標(biāo)量:?jiǎn)我坏臄?shù)字值,可以是函數(shù)參數(shù),也可以是函數(shù)的返回結(jié)果
瞬時(shí)向量:某一時(shí)刻的時(shí)序數(shù)據(jù)
區(qū)間向量:某一時(shí)間區(qū)間內(nèi)的時(shí)序數(shù)據(jù)集合
瞬時(shí)查詢(xún)
直接通過(guò)指標(biāo)名即可進(jìn)行查詢(xún),查詢(xún)結(jié)果是當(dāng)前指標(biāo)最新的時(shí)間序列,比如查詢(xún) Gc 累積消耗的時(shí)間:
go_gc_duration_seconds_count

我們可以看到查詢(xún)出來(lái)有多個(gè)同名指標(biāo)結(jié)果,可以用{}做標(biāo)簽過(guò)濾查詢(xún):比如我們想查指定實(shí)例的指標(biāo)。
go_gc_duration_seconds_count{instance="127.0.0.1:9600"}

而且也支持則表達(dá)式,通過(guò) =~ 指定正則表達(dá)式,如下所示:查詢(xún)所有 instance 是 localhost 開(kāi)頭的指標(biāo)。
go_gc_duration_seconds_count{instance=~"localhost.*"}

范圍查詢(xún)
范圍查詢(xún)的結(jié)果集就是區(qū)間向量,可以通過(guò)[]指定時(shí)間來(lái)做范圍查詢(xún),查詢(xún) 5 分鐘內(nèi)的 Gc 累積消耗時(shí)間:
go_gc_duration_seconds_count{}[5m]
注意:這里范圍查詢(xún)第一個(gè)點(diǎn)并不一定精確到剛剛好 5 分鐘前的那個(gè)時(shí)序樣本點(diǎn),他是以 5 分鐘作為一個(gè)區(qū)間,尋找這個(gè)區(qū)間的第一個(gè)點(diǎn)到最后一個(gè)樣本點(diǎn)。

時(shí)間單位:

d:天,h:小時(shí),m:分鐘,ms:毫秒,s:秒,w:周,y:年
同樣支持類(lèi)似 SQL 中的 offset 查詢(xún),如下:查詢(xún)一天前當(dāng)前 5 分鐘前的時(shí)序數(shù)據(jù)集:
go_gc_duration_seconds_count{}[5m]?offset?1d
Prometheus 內(nèi)置了很多函數(shù),這里主要記錄下常用的幾個(gè)函數(shù)的使用:
rate 和 irate 函數(shù)
rate 函數(shù)可以用來(lái)求指標(biāo)的平均變化速率:rate函數(shù)=時(shí)間區(qū)間前后兩個(gè)點(diǎn)的差 / 時(shí)間范圍。
一般 rate 函數(shù)可以用來(lái)求某個(gè)時(shí)間區(qū)間內(nèi)的請(qǐng)求速率,也就是我們常說(shuō)的 QPS:

但是 rate 函數(shù)只是算出來(lái)了某個(gè)時(shí)間區(qū)間內(nèi)的平均速率,沒(méi)辦法反映突發(fā)變化,假設(shè)在一分鐘的時(shí)間區(qū)間里,前 50 秒的請(qǐng)求量都是 0 到 10 左右,但是最后 10 秒的請(qǐng)求量暴增到 100 以上,這時(shí)候算出來(lái)的值可能無(wú)法很好的反映這個(gè)峰值變化。這個(gè)問(wèn)題可以通過(guò) irate 函數(shù)解決,irate 函數(shù)求出來(lái)的就是瞬時(shí)變化率。
時(shí)間區(qū)間內(nèi)最后兩個(gè)樣本點(diǎn)的差 / 最后兩個(gè)樣本點(diǎn)的時(shí)間差。

可以通過(guò)圖像看下兩者的區(qū)別:irate 函數(shù)的圖像峰值變化大,rate 函數(shù)變化較為平緩。
rate 函數(shù):

irate 函數(shù):

聚合函數(shù):Sum() by() without()
也是上邊的例子,我們?cè)谇笾付ń涌诘?QPS 的時(shí)候,可能會(huì)出現(xiàn)多個(gè)實(shí)例的 QPS 的計(jì)算結(jié)果,如下是存在多個(gè)接口,三個(gè)服務(wù)的 QPS。
rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m])

利用 Sum 函數(shù)可以將三個(gè) QPS 聚合,即可得到整個(gè)服務(wù)該接口的 QPS:其實(shí) Sum 就是將指標(biāo)值做相加。

但是這樣直接的相加太籠統(tǒng)抽象了,可以配合 by 和 without 函數(shù)在 sum 的時(shí)候,基于某些標(biāo)簽分組,類(lèi)似 SQL 中的 group by。
例如,我可以根據(jù)請(qǐng)求接口標(biāo)簽分組:這樣拿到的就是具體接口的 QPS:
sum(rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m]))?by(path)

也可以不根據(jù)接口路徑分組:通過(guò) without 指定:
sum(rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m]))?without(path)

可以通過(guò) histogram_quantile 函數(shù)做數(shù)據(jù)統(tǒng)計(jì):可以用來(lái)統(tǒng)計(jì)百分位數(shù):第一個(gè)參數(shù)是百分位,第二個(gè) histogram 指標(biāo),這樣計(jì)算出來(lái)的就是中位數(shù),即 P50。
histogram_quantile(0.5,go_gc_pauses_seconds_total_bucket)

分享之前和同事一起發(fā)現(xiàn)的坑:
在剛剛寫(xiě)的自定義 exporter 上新增幾個(gè) histogram 的樣本點(diǎn):
MyHistogram.Observe(0.3)
MyHistogram.Observe(0.4)
MyHistogram.Observe(0.5)
histogram 的桶設(shè)置:
MyHistogram?=?prometheus.NewHistogram(prometheus.HistogramOpts{
??Name:?"my_histogram_bucket",
??Help:?"自定義histogram",
??Buckets:?[]float64{0,2.5,5,7.5,10},??//?需要指定桶
})
如果這樣的話(huà),所有指標(biāo)都會(huì)直接進(jìn)入到第一個(gè)桶,即 0 到 2.5 這個(gè)桶,如果我要計(jì)算中位數(shù),那么這個(gè)中位數(shù)按照數(shù)學(xué)公式來(lái)算的話(huà),肯定是在 0 到 2.5 之間的,而且肯定是 0.3 到 0.5 之間。
我用 histogram_quantile 函數(shù)計(jì)算下:計(jì)算結(jié)果是 1.25,其實(shí)已經(jīng)不對(duì)了。
histogram_quantile(0.5,my_histogram_bucket_bucket)

我在計(jì)算下 P99,等于 2.475:
histogram_quantile(0.99,my_histogram_bucket_bucket)

我的指標(biāo)都是不大于 1 的,為啥算出來(lái)的 P50 和 P99 都這么離譜呢?
這是因?yàn)?Prometheus 他是不保存你具體的指標(biāo)數(shù)值的,他會(huì)幫你把指標(biāo)放到具體的桶,但是他不會(huì)保存你指標(biāo)的值,計(jì)算的分位數(shù)是一個(gè)預(yù)估的值,怎么預(yù)估呢?
就是假設(shè)每個(gè)桶內(nèi)的樣本分布是均勻的,線性分布來(lái)計(jì)算的,比如剛剛的 P50,其實(shí)就是算排在第 50%位置的樣本值,因?yàn)閯倓偹械臄?shù)據(jù)都落在了第一個(gè)桶,那么他在計(jì)算的時(shí)候就會(huì)假定這個(gè) 50%值在第一個(gè)桶的中點(diǎn),他就會(huì)假定這個(gè)數(shù)就是 0.5 _ 2.5,P99 就是第一個(gè)桶的 99%的位置,他就會(huì)假定這個(gè)數(shù)就是 0.99 _ 2.5。
導(dǎo)致這個(gè)誤差較大的原因就是我們的 bucket 設(shè)置的不合理。
重新定義桶:
//?定義histogram
MyHistogram?=?prometheus.NewHistogram(prometheus.HistogramOpts{
??Name:?"my_histogram_bucket",
??Help:?"自定義histogram",
??Buckets:?[]float64{0.1,0.2,0.3,0.4,0.5},??//?需要指定桶
})
上報(bào)數(shù)據(jù):
MyHistogram.Observe(0.1)
MyHistogram.Observe(0.3)
MyHistogram.Observe(0.4)

重新計(jì)算 P50,P99:


桶設(shè)置的越合理,計(jì)算的誤差越小。
—?6?—
除了可以利用 Prometheus 提供的 webUI 可視化我們的指標(biāo)外,還可以接入 Grafana 來(lái)做指標(biāo)的可視化。
第一步,對(duì)接數(shù)據(jù)源:

配置好 prometheus 的地址:

第二步,創(chuàng)建儀表盤(pán):

編輯儀表盤(pán):

在 Metrics 處編寫(xiě) PromQL 即可完成查詢(xún)和可視化:

儀表盤(pán)編輯完后,可以導(dǎo)出對(duì)應(yīng)的 json 文件,方便下次導(dǎo)入同樣的儀表盤(pán):

以上是我之前搭建的儀表盤(pán):

—?7?—
AlertManager 是 Prometheus 提供的告警信息下發(fā)組件,包含了對(duì)告警信息的分組,下發(fā),靜默等策略。配置完成后可以在 WebUI 上看到對(duì)應(yīng)的告警策略信息。告警規(guī)則也是基于 PromQL 進(jìn)行定制的。
編寫(xiě)告警配置:當(dāng) Http_srv 這個(gè)服務(wù)掛了,Prometheus 采集不到指標(biāo),并且持續(xù)時(shí)間 1 分鐘,就會(huì)觸發(fā)告警。
groups:
\-?name:?simulator-alert-rule
?rules:
?\-?alert:?HttpSimulatorDown
??expr:?sum(up{job="http_srv"})?==?0
??for:?1m
??labels:
???severity:?critical
在 prometheus.yml 中配置告警配置文件,需要配置上 Alertmanager 的地址和告警文件的地址。
\#?Alertmanager?configuration
alerting:
?alertmanagers:
?\-?static_configs:
??\-?targets:?['localhost:9093']
\#?Load?rules?once?and?periodically?evaluate?them?according?to?the?global?'evaluation_interval'.
rule_files:
??\-?"alert_rules.yml"
??\#-?"first_rules.yml"
配置告警信息,例如告警發(fā)送地址,告警內(nèi)容模版,分組策略等都在 Alertmanager 的配置文件中配置:
global:
?smtp_smarthost:?'smtp.qq.com:465'
?smtp_from:?'[email protected]'
?smtp_auth_username:?'[email protected]'
?smtp_auth_password:?'xxxx'
?smtp_require_tls:?false
route:
?group_interval:?1m
?repeat_interval:?1m
?receiver:?'mail-receiver'
#?group_by???????//采用哪個(gè)標(biāo)簽作為分組
#?group_wait??????//分組等待的時(shí)間,收到報(bào)警不是立馬發(fā)送出去,而是等待一段時(shí)間,看看同一組中是否有其他報(bào)警,如果有一并發(fā)送
#?group_interval????//告警時(shí)間間隔
#?repeat_interval???//重復(fù)告警時(shí)間間隔,可以減少發(fā)送告警的頻率
#?receiver???????//接收者是誰(shuí)
#?routes????????//子路由配置
receivers:
\-?name:?'mail-receiver'
?email_configs:
??\-?to:?'[email protected]'
當(dāng)我 kill 進(jìn)程:

Prometheus 已經(jīng)觸發(fā)告警:

在等待 1 分鐘,如果持續(xù)還是符合告警策略,則狀態(tài)為從 pending 變?yōu)?FIRING 會(huì)發(fā)送郵件到我的郵箱。

此時(shí)我的郵箱收到了一條告警消息:

Alertmanager 也支持對(duì)告警進(jìn)行靜默,在 Alertmanager 的 WebUI 中配置即可:

間隔了 4 分鐘,沒(méi)有收到告警,靜默生效:

一個(gè)小時(shí)沒(méi)有收到告警信息:

- END - ?推薦閱讀? 31天拿下K8s含金量最高的CKA+CKS證書(shū)! 基于 eBPF 的 Kubernetes 問(wèn)題排查全景圖發(fā)布 一文掌握 Ansible 自動(dòng)化運(yùn)維 Linux 使用 Systemd 管理進(jìn)程服務(wù),劃重點(diǎn)~ Linux的10個(gè)最危險(xiǎn)命令 Kubernetes網(wǎng)絡(luò)難懂?可能是沒(méi)看到這篇文章 100個(gè)Linux Shell腳本經(jīng)典案例(附PDF) 24 個(gè) Docker 常見(jiàn)問(wèn)題處理技巧 23 款 DevOps 工具建設(shè)云原生時(shí)代 Shell分析日志文件,全面解鎖新姿勢(shì)! 這篇文章帶你全面掌握 Nginx ! 基于Nginx實(shí)現(xiàn)灰度發(fā)布與AB測(cè)試 一文搞懂 Kubernetes 網(wǎng)絡(luò)通信原理 SRE本質(zhì)就是一個(gè)懂運(yùn)維的資深開(kāi)發(fā) Kubernetes 4000節(jié)點(diǎn)運(yùn)維經(jīng)驗(yàn)分享 搭建一套完整的企業(yè)級(jí) K8s 集群(kubeadm方式) 點(diǎn)亮,服務(wù)器三年不宕機(jī)


