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

一、簡介

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

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

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

二、整體生態(tài)

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

（一）指標(biāo)暴露

每一個被Prometheus監(jiān)控的服務(wù)都是一個Job，Prometheus為這些Job 提供了官方的SDK ，利用這個SDK可以自定義并導(dǎo)出自己的業(yè)務(wù)指標(biāo)，也可以使用Prometheus官方提供的各種常用組件和中間件的Exporter（比如常用的MySQL，Consul等等）。對于短時間執(zhí)行的腳本任務(wù)或者不好直接 Pull指標(biāo)的服務(wù)，Prometheus提供了PushGateWay網(wǎng)關(guān)給這些任務(wù)將服務(wù)指標(biāo)主動推Push到網(wǎng)關(guān)，Prometheus再從這個網(wǎng)關(guān)里Pull指標(biāo)。

（二）指標(biāo)抓取

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

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

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

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

對于Prometheus中的指標(biāo)抓取，采用的是Pull模型，默認(rèn)是一分鐘去拉取一次指標(biāo)，通過Prometheus.yaml配置文件中的scrape_interval配置項配置，Prometheus對外都是用的Pull模型，一個是Pull Exporter的暴露的指標(biāo)，一個是Pull PushGateway暴露的指標(biāo)。

（三）指標(biāo)存儲和查詢

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

（四）監(jiān)控告警

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

三、工作原理

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

（一）服務(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和抓取指標(biāo)的端口號配置在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)機(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，在這個服務(wù)下有一個exporter實例：localhost:9600。

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

metrics_path: /node_metricsscheme: http

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

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

（二）配置更新

在更新完P(guān)rometheus的配置文件后，我們需要更新我們的配置到程序內(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   }

（三）指標(biāo)抓取和存儲

Prometheus對指標(biāo)的抓取采取主動Pull的方式，即周期性的請求被監(jiān)控服務(wù)暴露的metrics接口或者是PushGateway，從而獲取到Metrics指標(biāo)，默認(rèn)時間是15s抓取一次，配置項如下：

global: scrape_interval: 15s

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

四、Metric指標(biāo)

（一）數(shù)據(jù)模型

Prometheus采集的所有指標(biāo)都是以時間序列的形式進(jìn)行存儲，每一個時間序列有三部分組成：

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

時間戳：描述當(dāng)前時間序列的時間，單位：毫秒。

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

可以通過查看Prometheus的metrics接口查看所有上報的指標(biāo)：

所有的指標(biāo)也都是通過如下所示的格式來標(biāo)識的：

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

（二）指標(biāo)類型

Prometheus底層存儲上其實并沒有對指標(biāo)做類型的區(qū)分，都是以時間序列的形式存儲，但是為了方便用戶的使用和理解不同監(jiān)控指標(biāo)之間的差異，Prometheus定義了4種不同的指標(biāo)類型：計數(shù)器counter，儀表盤gauge，直方圖histogram，摘要summary。

Counter計數(shù)器：

Counter類型和redis的自增命令一樣，只增不減，通過Counter指標(biāo)可以統(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ù)，例如當(dāng)前內(nèi)存占用，CPU利用，Gc次數(shù)等動態(tài)可上升可下降的數(shù)據(jù)，在Prometheus上通過Gauge，可以不用經(jīng)過內(nèi)置函數(shù)直觀的反映數(shù)據(jù)的變化情況，如下圖表示堆可分配的空間大?。?/span>

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

Histogram直方圖：

Histogram是一種直方圖類型，可以觀察到指標(biāo)在各個不同的區(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ù)端計算求出。

（三）指標(biāo)導(dǎo)出

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

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

添加自定義指標(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)（類型，名字，幫助信息）   myCounter := prometheus.NewCounter(prometheus.CounterOpts{      Name: "my_counter_total",      Help: "自定義counter",   })   // 2.注冊指標(biāo)   prometheus.MustRegister(myCounter)   // 3.設(shè)置指標(biāo)值   myCounter.Add(23)
   http.Handle("/metrics", promhttp.Handler())   http.ListenAndServe(":8080", nil)}

運行：

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

package main
import (   "fmt"   "net/http"
   "github.com/prometheus/client_golang/prometheus")
var (   MyCounter prometheus.Counter)
// init 注冊指標(biāo)func init() {   // 1.定義指標(biāo)（類型，名字，幫助信息）   MyCounter = prometheus.NewCounter(prometheus.CounterOpts{      Name: "my_counter_total",      Help: "自定義counter",   })   // 2.注冊指標(biāo)   prometheus.MustRegister(MyCounter)}
// Sayhellofunc 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)}

一開始啟動時，指標(biāo)counter是0

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

對于其他指標(biāo)定義方式是一樣的：

var (   MyCounter prometheus.Counter   MyGauge prometheus.Gauge   MyHistogram prometheus.Histogram   MySummary prometheus.Summary)
// init 注冊指標(biāo)func init() {   // 1.定義指標(biāo)（類型，名字，幫助信息）   MyCounter = prometheus.NewCounter(prometheus.CounterOpts{      Name: "my_counter_total",      Help: "自定義counter",   })   // 定義gauge類型指標(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.注冊指標(biāo)   prometheus.MustRegister(MyCounter)   prometheus.MustRegister(MyGauge)   prometheus.MustRegister(MyHistogram)   prometheus.MustRegister(MySummary)}

上面的指標(biāo)都是沒有設(shè)置標(biāo)簽的，我們一般的指標(biāo)都是帶有標(biāo)簽的，如何設(shè)置指標(biāo)的標(biāo)簽?zāi)兀?/span>

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

MyCounter *prometheus.CounterVec// 1.定義指標(biāo)（類型，名字，幫助信息）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()

其他同理。

五、PromQL

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

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

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

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

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

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

（一）瞬時查詢

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

go_gc_duration_seconds_count

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

go_gc_duration_seconds_count{instance="127.0.0.1:9600"}

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

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查詢，如下：查詢一天前當(dāng)前5分鐘前的時序數(shù)據(jù)集：

go_gc_duration_seconds_count{}[5m] offset 1d

（三）內(nèi)置函數(shù)

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

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

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就是將指標(biāo)值做相加。

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

例如，我可以根據(jù)請求接口標(biāo)簽分組：這樣拿到的就是具體接口的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指標(biāo)，這樣計算出來的就是中位數(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},    // 需要指定桶})

如果這樣的話，所有指標(biāo)都會直接進(jìn)入到第一個桶，即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)

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

這是因為Prometheus他是不保存你具體的指標(biāo)數(shù)值的，他會幫你把指標(biāo)放到具體的桶，但是他不會保存你指標(biāo)的值，計算的分位數(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è)置的不合理。

重新定義桶：

// 定義histogramMyHistogram = 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可視化我們的指標(biāo)外，還可以接入Grafana來做指標(biāo)的可視化。

第一步，對接數(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進(jìn)行定制的。

編寫告警配置：當(dāng)Http_srv這個服務(wù)掛了，Prometheus采集不到指標(biāo)，并且持續(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 configurationalerting:  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             //采用哪個標(biāo)簽作為分組#  group_wait           //分組等待的時間，收到報警不是立馬發(fā)送出去，而是等待一段時間，看看同一組中是否有其他報警，如果有一并發(fā)送#  group_interval       //告警時間間隔#  repeat_interval      //重復(fù)告警時間間隔，可以減少發(fā)送告警的頻率#  receiver             //接收者是誰#  routes               //子路由配置receivers:- name: 'mail-receiver'  email_configs:    - to: '[email protected]'