文章來源：【公眾號：云加社區(qū)】?

目錄

• 簡介

• 整體生態(tài)

• 工作原理

• Metric 指標

• PromQL

• Grafana 可視化

• 監(jiān)控告警

簡介

Prometheus 是一個開源的完整監(jiān)控解決方案，本文將從指標抓取到查詢及可視化展示，以及最后的監(jiān)控告警，對 Prometheus 做一個基本的認識。

Prometheus 是古希臘神話里泰坦族的一名神明，名字的意思是“先見之明”，下圖中是 Prometheus 被宙斯懲罰，飽受肝臟日食夜長之苦。

下面就是我們 CRUD Boy 所了解的 Prometheus，下面是其官網(wǎng)封面圖引導(dǎo)語：From metrics to insight，從指標到洞察力，通過指標去洞察你的系統(tǒng)，為我們的系統(tǒng)提供指標收集和監(jiān)控的開源解決方案。

也就是說，Prometheus 是一個數(shù)據(jù)監(jiān)控的解決方案，讓我們能隨時掌握系統(tǒng)運行的狀態(tài)，快速定位問題和排除故障。

Prometheus 發(fā)展速度很快，12 年開發(fā)完成，16 年加入 CNCF，成為繼 K8s 之后第二個 CNCF 托管的項目，而且社區(qū)很活躍，維護頻率很高，基本穩(wěn)定在 1 個月 1 個小版本的迭代速度。

整體生態(tài)

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

| 指標暴露

每一個被 Prometheus 監(jiān)控的服務(wù)都是一個 Job，Prometheus 為這些 Job 提供了官方的 SDK ，利用這個 SDK 可以自定義并導(dǎo)出自己的業(yè)務(wù)指標，也可以使用 Prometheus 官方提供的各種常用組件和中間件的 Exporter（比如常用的 MySQL，Consul 等等）。

對于短時間執(zhí)行的腳本任務(wù)或者不好直接 Pull 指標的服務(wù)，Prometheus 提供了 PushGateWay 網(wǎng)關(guān)給這些任務(wù)將服務(wù)指標主動推 Push 到網(wǎng)關(guān)，Prometheus 再從這個網(wǎng)關(guān)里 Pull 指標。

| 指標抓取

上面提到了 Push 和 Pull，其實這是兩種指標抓取模型。

Pull 模型：監(jiān)控服務(wù)主動拉取被監(jiān)控服務(wù)的指標。

被監(jiān)控服務(wù)一般通過主動暴露 metrics 端口或者通過 Exporter 的方式暴露指標，監(jiān)控服務(wù)依賴服務(wù)發(fā)現(xiàn)模塊發(fā)現(xiàn)被監(jiān)控服務(wù)，從而去定期的抓取指標。

Push 模型：被監(jiān)控服務(wù)主動將指標推送到監(jiān)控服務(wù)，可能需要對指標做協(xié)議適配，必須得符合監(jiān)控服務(wù)要求的指標格式。

對于 Prometheus 中的指標抓取，采用的是 Pull 模型，默認是一分鐘去拉取一次指標，通過 Prometheus.yaml 配置文件中的 scrape_interval 配置項配置。

Prometheus 對外都是用的 Pull 模型，一個是 Pull Exporter 的暴露的指標，一個是 Pull PushGateway 暴露的指標。

| 指標存儲和查詢

指標抓取后會存儲在內(nèi)置的時序數(shù)據(jù)庫中，Prometheus 也提供了 PromQL 查詢語言給我們做指標的查詢，我們可以在 Prometheus 的 WebUI 上通過 PromQL，可視化查詢我們的指標，也可以很方便的接入第三方的可視化工具，例如 grafana。

| 監(jiān)控告警

Prometheus 提供了 alertmanageer 基于 promql 來做系統(tǒng)的監(jiān)控告警，當 promql 查詢出來的指標超過我們定義的閾值時，prometheus 會發(fā)送一條告警信息到 alertmanager，manager 會將告警下發(fā)到配置好的郵箱或者微信。

工作原理

Prometheus 的從被監(jiān)控服務(wù)的注冊到指標抓取到指標查詢的流程分為五個步驟：

| 服務(wù)注冊

被監(jiān)控服務(wù)在 Prometheus 中是一個 Job 存在，被監(jiān)控服務(wù)的所有實例在? Prometheus 中是一個 target 的存在，所以被監(jiān)控服務(wù)的注冊就是在 Prometheus 中注冊一個 Job 和其所有的 target，這個注冊分為：靜態(tài)注冊和動態(tài)注冊。

靜態(tài)注冊：靜態(tài)的將服務(wù)的 IP 和抓取指標的端口號配置在 Prometheus yaml 文件的 scrape_configs 配置下。

scrape_configs:-?job_name:?"prometheus"static_configs:-?targets:?["localhost:9090"]

以上就是注冊了一個名為 prometheus 的服務(wù)，這個服務(wù)下有一個實例，暴露的抓取地址是 localhost:9090。

動態(tài)注冊：動態(tài)注冊就是在 Prometheus yaml 文件的 scrape_configs 配置下配置服務(wù)發(fā)現(xiàn)的地址和服務(wù)名。

Prometheus 會去該地址，根據(jù)你提供的服務(wù)名動態(tài)發(fā)現(xiàn)實例列表，在 Prometheus 中，支持 consul，DNS，文件，K8s 等多種服務(wù)發(fā)現(xiàn)機制。

基于 consul 的服務(wù)發(fā)現(xiàn)：

-?job_name:?"node_export_consul"metrics_path:?/node_metricsscheme:?httpconsul_sd_configs:-?server:?localhost:8500services:-?node_exporter

我們 consul 的地址就是：localhost:8500，服務(wù)名是 node_exporter，在這個服務(wù)下有一個 exporter 實例：localhost:9600。

注意：如果是動態(tài)注冊，最好加上這兩配置，靜態(tài)注冊指標拉取的路徑會默認的幫我們指定為 metrics_path:/metrics，所以如果暴露的指標抓取路徑不同或者是動態(tài)的服務(wù)注冊，最好加上這兩個配置。

不然會報錯“INVALID“ is not a valid start token，演示下，百度了一下，這里可能是數(shù)據(jù)格式不統(tǒng)一導(dǎo)致。

metrics_path:?/node_metrics scheme:?http

最后可以在 webUI 中查看發(fā)現(xiàn)的實例：

目前，Prometheus 支持多達二十多種服務(wù)發(fā)現(xiàn)協(xié)議：

<azure_sd_config> <consul_sd_config> <digitalocean_sd_config> <docker_sd_config> <dockerswarm_sd_config> <dns_sd_config> <ec2_sd_config> <openstack_sd_config> <file_sd_config> <gce_sd_config> <hetzner_sd_config> <http_sd_config> <kubernetes_sd_config> <kuma_sd_config> <lightsail_sd_config> <linode_sd_config> <marathon_sd_config> <nerve_sd_config> <serverset_sd_config> <triton_sd_config> <eureka_sd_config> <scaleway_sd_config> <static_config>

| 配置更新

在更新完 Prometheus 的配置文件后，我們需要更新我們的配置到程序內(nèi)存里，這里的更新方式有兩種，第一種簡單粗暴，就是重啟 Prometheus，第二種是動態(tài)更新的方式。如何實現(xiàn)動態(tài)的更新 Prometheus 配置？

第一步：首先要保證啟動 Prometheus 的時候帶上啟動參數(shù)：--web.enable-lifecycle。

prometheus?--config.file=/usr/local/etc/prometheus.yml?--web.enable-lifecycle

第二步：去更新我們的 Prometheus 配置。

curl?-v?--request?POST?'http://localhost:9090/-/reload'

第三步：更新完配置后，我們可以通過 Post 請求的方式，動態(tài)更新配置。

原理：Prometheus 在 web 模塊中，注冊了一個 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)??? }

通過 h.reload 這個 handler 方法實現(xiàn)：這個 handler 就是往一個 channle 中發(fā)送一個信號。

func?(h?*Handler)?reload(w?http.ResponseWriter,?r?*http.Request)?{rc?:=?make(chan?error)h.reloadCh?<-?rc????//?發(fā)送一個信號到channe了中if?err?:=?<-rc;?err?!=?nil?{http.Error(w,?fmt.Sprintf("failed?to?reload?config:?%s",?err),?http.StatusInternalServerError)} }

在 main 函數(shù)中會去監(jiān)聽這個 channel，只要有監(jiān)聽到信號，就會做配置的 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 對指標的抓取采取主動 Pull 的方式，即周期性的請求被監(jiān)控服務(wù)暴露的 metrics 接口或者是 PushGateway，從而獲取到 Metrics 指標，默認時間是 15s 抓取一次。

配置項如下：

global:scrape_interval:?15s

抓取到的指標會被以時間序列的形式保存在內(nèi)存中，并且定時刷到磁盤上，默認是兩個小時回刷一次。

并且為了防止 Prometheus 發(fā)生崩潰或重啟時能夠恢復(fù)數(shù)據(jù)，Prometheus 也提供了類似 MySQL 中 binlog 一樣的預(yù)寫日志，當 Prometheus 崩潰重啟時，會讀這個預(yù)寫日志來恢復(fù)數(shù)據(jù)。

Metric 指標

| 數(shù)據(jù)模型

Prometheus 采集的所有指標都是以時間序列的形式進行存儲，每一個時間序列有三部分組成：

• 指標名和指標標簽集合：metric_name{<label1=v1>,<label2=v2>....}，指標名：表示這個指標是監(jiān)控哪一方面的狀態(tài)，比如 http_request_total 表示：請求數(shù)量；指標標簽，描述這個指標有哪些維度，比如 http_request_total 這個指標，有請求狀態(tài)碼 code= 200/400/500，請求方式：method=get/post 等，實際上指標名稱實際上是以標簽的形式保存，這個標簽是 name，即：name=。

• 時間戳：描述當前時間序列的時間，單位：毫秒。

• 樣本值：當前監(jiān)控指標的具體數(shù)值，比如 http_request_total 的值就是請求數(shù)是多少。

可以通過查看 Prometheus 的 metrics 接口查看所有上報的指標：

所有的指標也都是通過如下所示的格式來標識的：

# HELP ???// HELP：這里描述的指標的信息，表示這個是一個什么指標，統(tǒng)計什么的 # TYPE ???// TYPE：這個指標是什么類型的 <metric?name>{<label?name>=<label?value>,?...}??value????//?指標的具體格式，<指標名>{標簽集合}?指標值

| 指標類型

Prometheus 底層存儲上其實并沒有對指標做類型的區(qū)分，都是以時間序列的形式存儲。

但是為了方便用戶的使用和理解不同監(jiān)控指標之間的差異，Prometheus 定義了 4 種不同的指標類型：計數(shù)器 counter，儀表盤 gauge，直方圖 histogram，摘要 summary。

Counter 計數(shù)器：Counter 類型和 redis 的自增命令一樣，只增不減，通過 Counter 指標可以統(tǒng)計 Http 請求數(shù)量，請求錯誤數(shù)，接口調(diào)用次數(shù)等單調(diào)遞增的數(shù)據(jù)。

同時可以結(jié)合 increase 和 rate 等函數(shù)統(tǒng)計變化速率，后續(xù)我們會提到這些內(nèi)置函數(shù)。

Gauge 儀表盤：和 Counter 不同，Gauge 是可增可減的，可以反映一些動態(tài)變化的數(shù)據(jù)。

例如當前內(nèi)存占用，CPU 利用，Gc 次數(shù)等動態(tài)可上升可下降的數(shù)據(jù)，在 Prometheus 上通過 Gauge，可以不用經(jīng)過內(nèi)置函數(shù)直觀的反映數(shù)據(jù)的變化情況。

如下圖表示堆可分配的空間大小：

上面兩種是數(shù)值指標，代表數(shù)據(jù)的變化情況，Histogram 和 Summary 是統(tǒng)計類型的指標，表示數(shù)據(jù)的分布情況。

Histogram 直方圖：Histogram 是一種直方圖類型，可以觀察到指標在各個不同的區(qū)間范圍的分布情況。

如下圖所示：可以觀察到請求耗時在各個桶的分布。

有一點要注意的是，Histogram 是累計直方圖，即每一個桶的是只有上區(qū)間，例如下圖表示小于 0.1 毫秒（le=“0.1”）的請求數(shù)量是 18173 個，小于 0.2 毫秒（le=“0.2”)的請求是 18182 個。

在le=“0.2”這個桶中是包含了 le=“0.1”這個桶的數(shù)據(jù)，如果我們要拿到 0.1 毫秒到 0.2 毫秒的請求數(shù)量，可以通過兩個桶想減得到。

在直方圖中，還可以通過 histogram_quantile 函數(shù)求出百分位數(shù)，比如 P50，P90，P99 等數(shù)據(jù)。

Summary 摘要：Summary 也是用來做統(tǒng)計分析的，和 Histogram 區(qū)別在于，Summary 直接存儲的就是百分位數(shù)。

如下所示：可以直觀的觀察到樣本的中位數(shù)，P90 和 P99。

Summary 的百分位數(shù)是客戶端計算好直接讓 Prometheus 抓取的，不需要 Prometheus 計算，直方圖是通過內(nèi)置函數(shù) histogram_quantile 在 Prometheus 服務(wù)端計算求出。

| 指標導(dǎo)出

指標導(dǎo)出有兩種方式，一種是使用 Prometheus 社區(qū)提供的定制好的 Exporter 對一些組件諸如 MySQL，Kafka 等的指標作導(dǎo)出，也可以利用社區(qū)提供的 Client 來自定義指標導(dǎo)出。

github.com/prometheus/client_golang/prometheus/promhttp

自定義 Prometheus exporter：

package?mainimport?("net/http""github.com/prometheus/client_golang/prometheus/promhttp" )func?main()??{http.Handle("/metrics",?promhttp.Handler())http.ListenAndServe(":8080",?nil) }

訪問：http://localhost:8080/metrics，即可看到導(dǎo)出的指標，這里我們沒有自定義任何的指標，但是能看到一些內(nèi)置的 Go 的運行時指標和 promhttp 相關(guān)的指標。

這個 Client 默認為我們暴露的指標，go_：以 go_ 為前綴的指標是關(guān)于 Go 運行時相關(guān)的指標，比如垃圾回收時間、goroutine 數(shù)量等，這些都是 Go 客戶端庫特有的，其他語言的客戶端庫可能會暴露各自語言的其他運行時指標。

promhttp_：來自 promhttp 工具包的相關(guān)指標，用于跟蹤對指標請求的處理。

添加自定義指標：

package?mainimport?("net/http""github.com/prometheus/client_golang/prometheus""github.com/prometheus/client_golang/prometheus/promhttp" )func?main()?{//?1.定義指標（類型，名字，幫助信息）myCounter?:=?prometheus.NewCounter(prometheus.CounterOpts{Name:?"my_counter_total",Help:?"自定義counter",})//?2.注冊指標prometheus.MustRegister(myCounter)//?3.設(shè)置指標值myCounter.Add(23)http.Handle("/metrics",?promhttp.Handler())http.ListenAndServe(":8080",?nil) }

運行：

模擬下在業(yè)務(wù)中上報接口請求量：

package?mainimport?("fmt""net/http""github.com/prometheus/client_golang/prometheus" )var?(MyCounter?prometheus.Counter )//?init?注冊指標 func?init()?{//?1.定義指標（類型，名字，幫助信息）MyCounter?=?prometheus.NewCounter(prometheus.CounterOpts{Name:?"my_counter_total",Help:?"自定義counter",})//?2.注冊指標prometheus.MustRegister(MyCounter) }//?Sayhello func?Sayhello(w?http.ResponseWriter,?r?*http.Request)?{//?接口請求量遞增MyCounter.Inc()fmt.Fprintf(w,?"Hello?Wrold!") }

main.go：

package?mainimport?("net/http""github.com/prometheus/client_golang/prometheus/promhttp" )func?main()?{http.Handle("/metrics",?promhttp.Handler())http.HandleFunc("/counter",Sayhello)http.ListenAndServe(":8080",?nil) }

一開始啟動時，指標 counter 是 0：

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

對于其他指標定義方式是一樣的：

var?(MyCounter?prometheus.CounterMyGauge?prometheus.GaugeMyHistogram?prometheus.HistogramMySummary?prometheus.Summary )//?init?注冊指標 func?init()?{//?1.定義指標（類型，名字，幫助信息）MyCounter?=?prometheus.NewCounter(prometheus.CounterOpts{Name:?"my_counter_total",Help:?"自定義counter",})//?定義gauge類型指標MyGauge?=?prometheus.NewGauge(prometheus.GaugeOpts{Name:?"my_gauge_num",Help:?"自定義gauge",})//?定義histogramMyHistogram?=?prometheus.NewHistogram(prometheus.HistogramOpts{Name:?"my_histogram_bucket",Help:?"自定義histogram",Buckets:?[]float64{0.1,0.2,0.3,0.4,0.5},???//?需要指定桶})//?定義SummaryMySummary?=?prometheus.NewSummary(prometheus.SummaryOpts{Name:?"my_summary_bucket",Help:?"自定義summary",//?這部分可以算好后在setObjectives:?map[float64]float64{0.5:?0.05,0.9:?0.01,???0.99:?0.001,?},})//?2.注冊指標prometheus.MustRegister(MyCounter)prometheus.MustRegister(MyGauge)prometheus.MustRegister(MyHistogram)prometheus.MustRegister(MySummary) }

上面的指標都是沒有設(shè)置標簽的，我們一般的指標都是帶有標簽的，如何設(shè)置指標的標簽?zāi)?#xff1f;

如果我要設(shè)置帶標簽的 counter 類型指標，只需要將原來的 NewCounter 方法替換為 NewCounterVec 方法即可，并且傳入標簽集合。

MyCounter?*prometheus.CounterVec //?1.定義指標（類型，名字，幫助信息） MyCounter?=?prometheus.NewCounterVec(prometheus.CounterOpts{Name:?"my_counter_total",Help:?"自定義counter",},//?標簽集合[]string{"label1","label2"}, ) //?帶標簽的set指標值 MyCounter.With(prometheus.Labels{"label1":"1","label2":"2"}).Inc()

其他同理。

PromQL

剛剛提到了 Prometheus 中指標有哪些類型以及如何導(dǎo)出我們的指標，現(xiàn)在指標導(dǎo)出到 Prometheus 了，利用其提供的 PromQL 可以查詢我們導(dǎo)出的指標。

PromQL 是 Prometheus 為我們提供的函數(shù)式的查詢語言，查詢表達式有四種類型：

• 字符串：只作為某些內(nèi)置函數(shù)的參數(shù)出現(xiàn)

• 標量：單一的數(shù)字值，可以是函數(shù)參數(shù)，也可以是函數(shù)的返回結(jié)果

• 瞬時向量：某一時刻的時序數(shù)據(jù)

• 區(qū)間向量：某一時間區(qū)間內(nèi)的時序數(shù)據(jù)集合

| 瞬時查詢

直接通過指標名即可進行查詢，查詢結(jié)果是當前指標最新的時間序列，比如查詢 Gc 累積消耗的時間：

go_gc_duration_seconds_count

我們可以看到查詢出來有多個同名指標結(jié)果 可以用{}做標簽過濾查詢：比如我們想查指定實例的指標。

go_gc_duration_seconds_count{instance="127.0.0.1:9600"}

而且也支持則表達式，通過 =~ 指定正則表達式，如下所示：查詢所有 instance 是 localhost 開頭的指標。

go_gc_duration_seconds_count{instance=~"localhost.*"}

| 范圍查詢

范圍查詢的結(jié)果集就是區(qū)間向量，可以通過[]指定時間來做范圍查詢，查詢 5 分鐘內(nèi)的 Gc 累積消耗時間：

go_gc_duration_seconds_count{}[5m]

注意：這里范圍查詢第一個點并不一定精確到剛剛好 5 分鐘前的那個時序樣本點，他是以 5 分鐘作為一個區(qū)間，尋找這個區(qū)間的第一個點到最后一個樣本點。

時間單位：

d：天，h：小時，m：分鐘，ms：毫秒，s：秒，w：周，y：年。

同樣支持類似 SQL 中的 offset 查詢，如下：查詢一天前當前 5 分鐘前的時序數(shù)據(jù)集。

go_gc_duration_seconds_count{}[5m]?offset?1d

| 內(nèi)置函數(shù)

Prometheus 內(nèi)置了很多函數(shù)，這里主要記錄下常用的幾個函數(shù)的使用：?

rate 和 irate 函數(shù)：rate 函數(shù)可以用來求指標的平均變化速率。

rate函數(shù)=時間區(qū)間前后兩個點的差?/?時間范圍

一般 rate 函數(shù)可以用來求某個時間區(qū)間內(nèi)的請求速率，也就是我們常說的 QPS。

但是 rate 函數(shù)只是算出來了某個時間區(qū)間內(nèi)的平均速率，沒辦法反映突發(fā)變化，假設(shè)在一分鐘的時間區(qū)間里，前 50 秒的請求量都是 0 到 10 左右，但是最后 10 秒的請求量暴增到 100 以上，這時候算出來的值可能無法很好的反映這個峰值變化。

這個問題可以通過 irate 函數(shù)解決，irate 函數(shù)求出來的就是瞬時變化率。

時間區(qū)間內(nèi)最后兩個樣本點的差?/?最后兩個樣本點的時間差

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

rate 函數(shù)：

irate 函數(shù)：

聚合函數(shù)：Sum() by() without()

也是上邊的例子，我們在求指定接口的 QPS 的時候，可能會出現(xiàn)多個實例的 QPS 的計算結(jié)果，如下是存在多個接口，三個服務(wù)的 QPS。

rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m])

利用 sum 函數(shù)可以將三個 QPS 聚合，即可得到整個服務(wù)該接口的 QPS：其實 Sum 就是將指標值做相加。

但是這樣直接的相加太籠統(tǒng)抽象了，可以配合 by 和 without 函數(shù)在 sum 的時候，基于某些標簽分組，類似 SQL 中的 group by。

例如，我可以根據(jù)請求接口標簽分組：這樣拿到的就是具體接口的 QPS：

sum(rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m]))?by(path)

也可以不根據(jù)接口路徑分組：通過 without 指定。

sum(rate(demo_api_request_duration_seconds_count{job="demo",?method="GET",?status="200"}[5m]))?without(path)

可以通過 histogram_quantile 函數(shù)做數(shù)據(jù)統(tǒng)計：可以用來統(tǒng)計百分位數(shù)：第一個參數(shù)是百分位，第二個 histogram 指標，這樣計算出來的就是中位數(shù)，即 P50。

histogram_quantile(0.5,go_gc_pauses_seconds_total_bucket)

分享之前和同事一起發(fā)現(xiàn)的坑：在剛剛寫的自定義 exporter 上新增幾個 histogram 的樣本點。

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},????//?需要指定桶 })

如果這樣的話，所有指標都會直接進入到第一個桶，即 0 到 2.5 這個桶，如果我要計算中位數(shù)，那么這個中位數(shù)按照數(shù)學(xué)公式來算的話，肯定是在 0 到 2 之間的，而且肯定是 0.3 到 0.5 之間。

我用 histogram_quantile 函數(shù)計算下：計算結(jié)果是 1.25，其實已經(jīng)不對了。

histogram_quantile(0.5,my_histogram_bucket_bucket)

我在計算下 P99，等于 2.475：

histogram_quantile(0.99,my_histogram_bucket_bucket)

我的指標都是不大于 1 的，為啥算出來的 P50 和 P99 都這么離譜呢？

這是因為 Prometheus 他是不保存你具體的指標數(shù)值的，他會幫你把指標放到具體的桶，但是他不會保存你指標的值，計算的分位數(shù)是一個預(yù)估的值，怎么預(yù)估呢？

就是假設(shè)每個桶內(nèi)的樣本分布是均勻的，線性分布來計算的，比如剛剛的 P50，其實就是算排在第 50% 位置的樣本值。

因為剛剛所有的數(shù)據(jù)都落在了第一個桶，那么他在計算的時候就會假定這個 50% 值在第一個桶的中點，他就會假定這個數(shù)就是 0.5_ 2.5，P99 就是第一個桶的 99% 的位置，他就會假定這個數(shù)就是 0.99 _ 2.5。

導(dǎo)致這個誤差較大的原因就是我們的 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},???//?需要指定桶 })

上報數(shù)據(jù)：

MyHistogram.Observe(0.1) MyHistogram.Observe(0.3) MyHistogram.Observe(0.4)

重新計算 P50，P99：

桶設(shè)置的越合理，計算的誤差越小。

Grafana 可視化

除了可以利用 Prometheus 提供的 webUI 可視化我們的指標外，還可以接入 Grafana 來做指標的可視化。

第一步，對接數(shù)據(jù)源。

配置好 prometheus 的地址：

第二步：創(chuàng)建儀表盤。

編輯儀表盤：

在 metrics 處編寫 PromQL 即可完成查詢和可視化：

儀表盤編輯完后，可以導(dǎo)出對應(yīng)的 json 文件，方便下次導(dǎo)入同樣的儀表盤：

以上是我之前搭建的儀表盤：

監(jiān)控告警

AlertManager 是 prometheus 提供的告警信息下發(fā)組件，包含了對告警信息的分組，下發(fā)，靜默等策略。

配置完成后可以在 webui 上看到對應(yīng)的告警策略信息。告警規(guī)則也是基于 PromQL 進行定制的。

編寫告警配置：當 Http_srv 這個服務(wù)掛了，Prometheus 采集不到指標，并且持續(xù)時間 1 分鐘，就會觸發(fā)告警。

groups: -?name:?simulator-alert-rulerules:-?alert:?HttpSimulatorDownexpr:?sum(up{job="http_srv"})?==?0?for:?1mlabels: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:?'xxxx@qq.com'smtp_auth_username:?'xxxx@qq.com'smtp_auth_password:?'xxxx'smtp_require_tls:?falseroute:group_interval:?1mrepeat_interval:?1mreceiver:?'mail-receiver'#??group_by?????????????//采用哪個標簽作為分組 #??group_wait???????????//分組等待的時間，收到報警不是立馬發(fā)送出去，而是等待一段時間，看看同一組中是否有其他報警，如果有一并發(fā)送 #??group_interval???????//告警時間間隔 #??repeat_interval??????//重復(fù)告警時間間隔，可以減少發(fā)送告警的頻率 #??receiver?????????????//接收者是誰 #??routes???????????????//子路由配置 receivers: -?name:?'mail-receiver'email_configs:-?to:?'xxxx@qq.com'

當我 kill 進程：

prometheus 已經(jīng)觸發(fā)告警：

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

此時我的郵箱收到了一條告警消息：

alertmanager 也支持對告警進行靜默，在 alertmanager 的 WEBUI 中配置即可：

間隔了 4 分鐘，沒有收到告警，靜默生效：

一個小時沒有收到告警信息：

強勢開源一款小程序！ 2021-11-07 強力推薦一個完善的物流（WMS）管理項目（附代碼） 2021-10-23 推薦一個 Spring Boot + MyBatis + Vue 音樂網(wǎng)站 2021-10-19 分享一套家庭理財系統(tǒng)（附源碼） 2021-09-20 推薦一個互聯(lián)網(wǎng)企業(yè)級別的開源支付系統(tǒng) 2021-09-04 推薦一套開源通用后臺管理系統(tǒng)（附源碼） 2021-08-21 一款神仙接私活兒軟件，吊到不行！ 2021-07-31 基于 SpringBoot 的仿豆瓣平臺【源碼分享】 2021-07-18 干掉 Wordpress！這個開源建站神器有點吊！ 2021-06-18 從朋友那里搞了 20 個實戰(zhàn)項目，速領(lǐng)！ 2021-06-12

如有收獲，點個在看，誠摯感謝

總結(jié)

以上是生活随笔為你收集整理的监控神器Prometheus，开箱即用！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。