国产亚洲精品久久午夜电影,亚洲欧美v国产一区二区三区,91插插插永久免费

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

一、簡介

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

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

也就是說，Prometheus是一個數據監控的解決方案，讓我們能隨時掌握系統運行的狀態，快速定位問題和排除故障。

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

二、整體生態

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

（一）指標暴露

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

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

（二）指標抓取

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

Pull模型： 監控服務主動拉取被監控服務的指標。

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

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

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

（三）指標存儲和查詢

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

（四）監控告警

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

三、工作原理

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

（一）服務注冊

被監控服務在Prometheus中是一個Job存在，被監控服務的所有實例在 Prometheus中是一個target的存在，所以被監控服務的注冊就是在 Prometheus中注冊一個Job和其所有的target，這個注冊分為：靜態注冊和動態注冊。

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

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

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

動態注冊： 動態注冊就是在Prometheus yaml文件的scrape_configs配置下配置服務發現的地址和服務名，Prometheus會去該地址，根據你提供的服務名動態發現實例列表，在Prometheus中，支持consul，DNS，文件，K8s等多種服務發現機制。基于consul的服務發現：

-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。

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

不然會報錯“INVALID“ is not a valid start token，演示下，百度了一下，這里可能是數據格式不統一導致。

metrics_path:/node_metrics
scheme:http

最后可以在webUI中查看發現的實例：

目前，Prometheus支持多達二十多種服務發現協議：

（二）配置更新

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

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

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

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

curl-v--requestPOST'http://localhost:9090/-/reload'

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

原理：

Prometheus在web模塊中，注冊了一個handler：

ifo.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方法實現：這個handler就是往一個channle中發送一個信號：

func(h*Handler)reload(whttp.ResponseWriter,r*http.Request){
rc:=make(chanerror)
h.reloadCh<-?rc????//?發送一個信號到channe了中
???iferr:=<-rc;?err?!=?nil?{
??????http.Error(w,?fmt.Sprintf("failedtoreloadconfig:%s",err),http.StatusInternalServerError)
}
}

在main函數中會去監聽這個channel，只要有監聽到信號，就會做配置的reload，重新將新配置加載到內存中

caserc:=<-webHandler.Reload():
???iferr:=reloadConfig(cfg.configFile,cfg.enableExpandExternalLabels,cfg.tsdb.EnableExemplarStorage,logger,noStepSubqueryInterval,reloaders...);err!=nil{
level.Error(logger).Log("msg","Errorreloadingconfig","err",err)
rc<-?err
???}?else{
rc<-?nil
???}

（三）指標抓取和存儲

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

global:
scrape_interval:15s

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

四、Metric指標

（一）數據模型

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

指標名和指標標簽集合：metric_name{,....}，指標名：表示這個指標是監控哪一方面的狀態，比如http_request_total表示：請求數量；指標標簽，描述這個指標有哪些維度，比如http_request_total這個指標，有請求狀態碼code= 200/400/500，請求方式：method=get/post等，實際上指標名稱實際上是以標簽的形式保存，這個標簽是name，即：name=。
時間戳：描述當前時間序列的時間，單位：毫秒。
樣本值：當前監控指標的具體數值，比如http_request_total的值就是請求數是多少。

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

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

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

（二）指標類型

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

Counter計數器：

Counter類型和redis的自增命令一樣，只增不減，通過Counter指標可以統計Http請求數量，請求錯誤數，接口調用次數等單調遞增的數據。同時可以結合increase和rate等函數統計變化速率，后續我們會提到這些內置函數。

Gauge儀表盤：

和Counter不同，Gauge是可增可減的，可以反映一些動態變化的數據，例如當前內存占用，CPU利用，Gc次數等動態可上升可下降的數據，在Prometheus上通過Gauge，可以不用經過內置函數直觀的反映數據的變化情況，如下圖表示堆可分配的空間大小：

上面兩種是數值指標，代表數據的變化情況，Histogram和Summary是統計類型的指標，表示數據的分布情況。

Histogram直方圖：

Histogram是一種直方圖類型，可以觀察到指標在各個不同的區間范圍的分布情況，如下圖所示：可以觀察到請求耗時在各個桶的分布。

有一點要注意的是，Histogram是累計直方圖，即每一個桶的是只有上區間，例如下圖表示小于0.1毫秒（le=“0.1”）的請求數量是18173個，小于 0.2毫秒（le=“0.2”)的請求是18182 個，在le=“0.2”這個桶中是包含了 le=“0.1”這個桶的數據，如果我們要拿到0.1毫秒到0.2毫秒的請求數量，可以通過兩個桶想減得到。

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

Summary摘要

Summary也是用來做統計分析的，和Histogram區別在于，Summary直接存儲的就是百分位數，如下所示：可以直觀的觀察到樣本的中位數，P90和P99。

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

（三）指標導出

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

github.com/prometheus/client_golang/prometheus/promhttp

自定義Prometheus exporter：

packagemain

import(
"net/http"

"github.com/prometheus/client_golang/prometheus/promhttp"
)

funcmain(){
http.Handle("/metrics",promhttp.Handler())
http.ListenAndServe(":8080",nil)
}

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

添加自定義指標：

packagemain

import(
"net/http"

"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)

funcmain(){

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

運行：

模擬下在業務中上報接口請求量：

packagemain

import(
"fmt"
"net/http"

"github.com/prometheus/client_golang/prometheus"
)

var(
MyCounterprometheus.Counter
)

//init注冊指標
funcinit(){
//1.定義指標（類型，名字，幫助信息）
MyCounter=prometheus.NewCounter(prometheus.CounterOpts{
Name:"my_counter_total",
Help:"自定義counter",
})
//2.注冊指標
prometheus.MustRegister(MyCounter)
}

//Sayhello
funcSayhello(whttp.ResponseWriter,r*http.Request){
//接口請求量遞增
MyCounter.Inc()
fmt.Fprintf(w,"HelloWrold!")
}

main.go：

packagemain

import(
"net/http"

"github.com/prometheus/client_golang/prometheus/promhttp"
)

funcmain(){

http.Handle("/metrics",promhttp.Handler())
http.HandleFunc("/counter",Sayhello)
http.ListenAndServe(":8080",nil)
}

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

調用：/counter接口后，指標數據發生了變化，這樣就可以簡單實現了接口請求數的統計：

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

var(
MyCounterprometheus.Counter
MyGaugeprometheus.Gauge
MyHistogramprometheus.Histogram
MySummaryprometheus.Summary
)

//init注冊指標
funcinit(){
//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()

其他同理。

五、PromQL

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

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

字符串：只作為某些內置函數的參數出現；
標量：單一的數字值，可以是函數參數，也可以是函數的返回結果；
瞬時向量：某一時刻的時序數據；
區間向量：某一時間區間內的時序數據集合。

（一）瞬時查詢

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

go_gc_duration_seconds_count

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

go_gc_duration_seconds_count{instance="127.0.0.1:9600"}

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

go_gc_duration_seconds_count{instance=~"localhost.*"}

（二）范圍查詢

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

go_gc_duration_seconds_count{}[5m]

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

時間單位：

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

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

go_gc_duration_seconds_count{}[5m]offset1d

（三）內置函數

Prometheus內置了很多函數，這里主要記錄下常用的幾個函數的使用：

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

rate函數=時間區間前后兩個點的差/時間范圍

一般rate函數可以用來求某個時間區間內的請求速率，也就是我們常說的QPS

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

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

時間區間內最后兩個樣本點的差/最后兩個樣本點的時間差

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

rate函數

irate函數

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

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

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

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

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

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

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

也可以不根據接口路徑分組：通過without指定：

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

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

histogram_quantile(0.5,go_gc_pauses_seconds_total_bucket)

分享之前和同事一起發現的坑：

在剛剛寫的自定義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這個桶，如果我要計算中位數，那么這個中位數按照數學公式來算的話，肯定是在0到2.之間的，而且肯定是0.3到0.5之間。

我用histogram_quantile函數計算下：計算結果是1.25，其實已經不對了。

histogram_quantile(0.5,my_histogram_bucket_bucket)

我在計算下P99，等于2.475：

histogram_quantile(0.99,my_histogram_bucket_bucket)

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

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

就是假設每個桶內的樣本分布是均勻的，線性分布來計算的，比如剛剛的P50，其實就是算排在第50%位置的樣本值，因為剛剛所有的數據都落在了第一個桶，那么他在計算的時候就會假定這個50%值在第一個桶的中點，他就會假定這個數就是0.5_ 2.5，P99就是第一個桶的99%的位置，他就會假定這個數就是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},//需要指定桶
})

上報數據：

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

重新計算 P50，P99：

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

六、Grafana可視化

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

第一步，對接數據源：

配置好prometheus的地址：

第二步：創建儀表盤

編輯儀表盤：

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

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

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

七、監控告警

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

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

groups:
-name:simulator-alert-rule
rules:
-alert:HttpSimulatorDown
expr:sum(up{job="http_srv"})==0
for:1m
labels:
severity:critical

在prometheus.yml中配置告警配置文件，需要配置上alertmanager的地址和告警文件的地址

#Alertmanagerconfiguration
alerting:
alertmanagers:
-static_configs:
-targets:['localhost:9093']
#Loadrulesonceandperiodicallyevaluatethemaccordingtotheglobal'evaluation_interval'.
rule_files:
-"alert_rules.yml"
#-"first_rules.yml"

配置告警信息，例如告警發送地址，告警內容模版，分組策略等都在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//分組等待的時間，收到報警不是立馬發送出去，而是等待一段時間，看看同一組中是否有其他報警，如果有一并發送
#group_interval//告警時間間隔
#repeat_interval//重復告警時間間隔，可以減少發送告警的頻率
#receiver//接收者是誰
#routes//子路由配置
receivers:
-name:'mail-receiver'
email_configs:
-to:'xxxx@qq.com'