基于Prometheus開源的完整監(jiān)控解決方案

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

— 簡介

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

下面就是我們 CRUD Boy 所了解的 Prometheus，其官網(wǎng)封面圖引導語：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，成為繼 Kubernetes 之后第二個 CNCF 托管的項目，目前 GitHub 42k 的 ，而且社區(qū)很活躍，維護頻率很高，基本穩(wěn)定在 1 個月 1 個小版本的迭代速度。

—?2?— 整體生態(tài)

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

指標暴露

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

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

指標抓取

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

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

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

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

對于 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ā)到配置好的郵箱或者微信。

—?3?— 工作原理

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

服務注冊

被監(jiān)控服務在 Prometheus 中是一個 Job 存在，被監(jiān)控服務的所有實例在 Prometheus 中是一個 target 的存在，所以被監(jiān)控服務的注冊就是在 Prometheus 中注冊一個 Job 和其所有的 target，這個注冊分為：

靜態(tài)注冊

動態(tài)注冊

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

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

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

動態(tài)注冊：動態(tài)注冊就是在 Prometheus yaml 文件的 scrape_configs 配置下配置服務發(fā)現(xiàn)的地址和服務名，Prometheus 會去該地址，根據(jù)你提供的服務名動態(tài)發(fā)現(xiàn)實例列表，在 Prometheus 中，支持 Consul、DNS、文件、Kubernetes 等多種服務發(fā)現(xiàn)機制。

基于 Consul 的服務發(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，服務名是 node_exporter，在這個服務下有一個 exporter 實例：localhost:9600。

注意：如果是動態(tài)注冊，最好加上這兩配置，靜態(tài)注冊指標拉取的路徑會默認的幫我們指定為 metrics_path:/metrics，所以如果暴露的指標抓取路徑不同或者是動態(tài)的服務注冊，最好加上這兩個配置。不然會報錯“INVALID is not a valid start token”，演示下，百度了一下，這里可能是數(shù)據(jù)格式不統(tǒng)一導致。

metrics_path:?/node_metrics scheme:?http

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

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

配置更新

在更新完 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 配置。

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

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

原理：

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)控服務暴露的 Metrics 接口或者是 PushGateway，從而獲取到 Metrics 指標，默認時間是 15s 抓取一次，配置項如下：

global: ?scrape_interval:?15s

抓取到的指標會被以時間序列的形式保存在內(nèi)存中，并且定時刷到磁盤上，默認是兩個小時回刷一次。并且為了防止 Prometheus 發(fā)生崩潰或重啟時能夠恢復數(shù)據(jù)，Prometheus 也提供了類似 MySQL 中 binlog 一樣的預寫日志，當 Prometheus 崩潰重啟時，會讀這個預寫日志來恢復數(shù)據(jù)。

—?4?— Metric 指標

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

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

指標名和指標標簽集合：metric_name{,....}，指標名：表示這個指標是監(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：這個指標是什么類型的 {=,?...}?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ù)的變化情況，如下圖表示堆可分配的空間大?。?/p>

上面兩種是數(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 服務端計算求出。

指標導出

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

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) }

訪問：http://localhost:8080/metrics，即可看到導出的指標，這里我們沒有自定義任何的指標，但是能看到一些內(nèi)置的 Go 的運行時指標和 promhttp 相關的指標，這個 Client 默認為我們暴露的指標，go_：以 go 為前綴的指標是關于 Go 運行時相關的指標，比如垃圾回收時間、goroutine 數(shù)量等，這些都是 Go 客戶端庫特有的，其他語言的客戶端庫可能會暴露各自語言的其他運行時指標。

promhttp：來自 promhttp 工具包的相關指標，用于跟蹤對指標請求的處理。

添加自定義指標：

package?main import?( ??"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.設置指標值 ??myCounter.Add(23) ??http.Handle("/metrics",?promhttp.Handler()) ??http.ListenAndServe(":8080",?nil) }

運行：

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

package?main import?( ??"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?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) }

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

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

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

var?( ??MyCounter?prometheus.Counter ??MyGauge?prometheus.Gauge ??MyHistogram?prometheus.Histogram ??MySummary?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", ??}) ??//?定義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.注冊指標 ??prometheus.MustRegister(MyCounter) ??prometheus.MustRegister(MyGauge) ??prometheus.MustRegister(MyHistogram) ??prometheus.MustRegister(MySummary) }

上面的指標都是沒有設置標簽的，我們一般的指標都是帶有標簽的，如何設置指標的標簽呢？

如果我要設置帶標簽的 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()

其他同理。

—?5?— PromQL

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

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ā)變化，假設在一分鐘的時間區(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é)果，如下是存在多個接口，三個服務的 QPS。

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

利用 Sum 函數(shù)可以將三個 QPS 聚合，即可得到整個服務該接口的 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 的桶設置：

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ù)學公式來算的話，肯定是在 0 到 2.5 之間的，而且肯定是 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ù)是一個預估的值，怎么預估呢？

就是假設每個桶內(nèi)的樣本分布是均勻的，線性分布來計算的，比如剛剛的 P50，其實就是算排在第 50%位置的樣本值，因為剛剛所有的數(shù)據(jù)都落在了第一個桶，那么他在計算的時候就會假定這個 50%值在第一個桶的中點，他就會假定這個數(shù)就是 0.5 _ 2.5，P99 就是第一個桶的 99%的位置，他就會假定這個數(shù)就是 0.99 _ 2.5。

導致這個誤差較大的原因就是我們的 bucket 設置的不合理。

重新定義桶：

//?定義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：

桶設置的越合理，計算的誤差越小。

—?6?— Grafana 可視化

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

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

配置好 prometheus 的地址：

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

編輯儀表盤：

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

儀表盤編輯完后，可以導出對應的 json 文件，方便下次導入同樣的儀表盤：

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

—?7?— 監(jiān)控告警

AlertManager 是 Prometheus 提供的告警信息下發(fā)組件，包含了對告警信息的分組，下發(fā)，靜默等策略。配置完成后可以在 WebUI 上看到對應的告警策略信息。告警規(guī)則也是基于 PromQL 進行定制的。

編寫告警配置：當 Http_srv 這個服務掛了，Prometheus 采集不到指標，并且持續(xù)時間 1 分鐘，就會觸發(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:?'xxxx@qq.com' ?smtp_auth_username:?'xxxx@qq.com' ?smtp_auth_password:?'xxxx' ?smtp_require_tls:?false route: ?group_interval:?1m ?repeat_interval:?1m ?receiver:?'mail-receiver' #?group_by???????//采用哪個標簽作為分組 #?group_wait??????//分組等待的時間，收到報警不是立馬發(fā)送出去，而是等待一段時間，看看同一組中是否有其他報警，如果有一并發(fā)送 #?group_interval????//告警時間間隔 #?repeat_interval???//重復告警時間間隔，可以減少發(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 分鐘，沒有收到告警，靜默生效：

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

編輯：黃飛