监控神器Prometheus,开箱即用!
文章來源:【公眾號:云加社區】?
目錄
簡介
整體生態
工作原理
Metric 指標
PromQL
Grafana 可視化
監控告警
簡介
Prometheus 是一個開源的完整監控解決方案,本文將從指標抓取到查詢及可視化展示,以及最后的監控告警,對 Prometheus 做一個基本的認識。
Prometheus 是古希臘神話里泰坦族的一名神明,名字的意思是“先見之明”,下圖中是 Prometheus 被宙斯懲罰,飽受肝臟日食夜長之苦。
下面就是我們 CRUD Boy 所了解的 Prometheus,下面是其官網封面圖引導語:From metrics to insight,從指標到洞察力,通過指標去洞察你的系統,為我們的系統提供指標收集和監控的開源解決方案。
也就是說,Prometheus 是一個數據監控的解決方案,讓我們能隨時掌握系統運行的狀態,快速定位問題和排除故障。
Prometheus 發展速度很快,12 年開發完成,16 年加入 CNCF,成為繼 K8s 之后第二個 CNCF 托管的項目,而且社區很活躍,維護頻率很高,基本穩定在 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_metricsscheme:?httpconsul_sd_configs:-?server:?localhost:8500services:-?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 支持多達二十多種服務發現協議:
<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 的配置文件后,我們需要更新我們的配置到程序內存里,這里的更新方式有兩種,第一種簡單粗暴,就是重啟 Prometheus,第二種是動態更新的方式。如何實現動態的更新 Prometheus 配置?
第一步:首先要保證啟動 Prometheus 的時候帶上啟動參數:--web.enable-lifecycle。
prometheus?--config.file=/usr/local/etc/prometheus.yml?--web.enable-lifecycle第二步:去更新我們的 Prometheus 配置。
curl?-v?--request?POST?'http://localhost:9090/-/reload'第三步:更新完配置后,我們可以通過 Post 請求的方式,動態更新配置。
原理: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 方法實現:這個 handler 就是往一個 channle 中發送一個信號。
func?(h?*Handler)?reload(w?http.ResponseWriter,?r?*http.Request)?{rc?:=?make(chan?error)h.reloadCh?<-?rc????//?發送一個信號到channe了中if?err?:=?<-rc;?err?!=?nil?{http.Error(w,?fmt.Sprintf("failed?to?reload?config:?%s",?err),?http.StatusInternalServerError)} }在 main 函數中會去監聽這個 channel,只要有監聽到信號,就會做配置的 reload,重新將新配置加載到內存中。
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 的方式,即周期性的請求被監控服務暴露的 metrics 接口或者是 PushGateway,從而獲取到 Metrics 指標,默認時間是 15s 抓取一次。
配置項如下:
global:scrape_interval:?15s抓取到的指標會被以時間序列的形式保存在內存中,并且定時刷到磁盤上,默認是兩個小時回刷一次。
并且為了防止 Prometheus 發生崩潰或重啟時能夠恢復數據,Prometheus 也提供了類似 MySQL 中 binlog 一樣的預寫日志,當 Prometheus 崩潰重啟時,會讀這個預寫日志來恢復數據。
Metric 指標
| 數據模型
Prometheus 采集的所有指標都是以時間序列的形式進行存儲,每一個時間序列有三部分組成:
指標名和指標標簽集合:metric_name{<label1=v1>,<label2=v2>....},指標名:表示這個指標是監控哪一方面的狀態,比如 http_request_total 表示:請求數量;指標標簽,描述這個指標有哪些維度,比如 http_request_total 這個指標,有請求狀態碼 code= 200/400/500,請求方式:method=get/post 等,實際上指標名稱實際上是以標簽的形式保存,這個標簽是 name,即:name=。
時間戳:描述當前時間序列的時間,單位:毫秒。
樣本值:當前監控指標的具體數值,比如 http_request_total 的值就是請求數是多少。
可以通過查看 Prometheus 的 metrics 接口查看所有上報的指標:
所有的指標也都是通過如下所示的格式來標識的:
# HELP ???// HELP:這里描述的指標的信息,表示這個是一個什么指標,統計什么的 # TYPE ???// TYPE:這個指標是什么類型的 <metric?name>{<label?name>=<label?value>,?...}??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:
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,即可看到導出的指標,這里我們沒有自定義任何的指標,但是能看到一些內置的 Go 的運行時指標和 promhttp 相關的指標。
這個 Client 默認為我們暴露的指標,go_:以 go_ 為前綴的指標是關于 Go 運行時相關的指標,比如垃圾回收時間、goroutine 數量等,這些都是 Go 客戶端庫特有的,其他語言的客戶端庫可能會暴露各自語言的其他運行時指標。
promhttp_:來自 promhttp 工具包的相關指標,用于跟蹤對指標請求的處理。
添加自定義指標:
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.設置指標值myCounter.Add(23)http.Handle("/metrics",?promhttp.Handler())http.ListenAndServe(":8080",?nil) }運行:
模擬下在業務中上報接口請求量:
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:
調用:/counter 接口后,指標數據發生了變化,這樣就可以簡單實現了接口請求數的統計:
對于其他指標定義方式是一樣的:
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) }上面的指標都是沒有設置標簽的,我們一般的指標都是帶有標簽的,如何設置指標的標簽呢?
如果我要設置帶標簽的 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]?offset?1d| 內置函數
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-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"配置告警信息,例如告警發送地址,告警內容模版,分組策略等都在 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???????????//分組等待的時間,收到報警不是立馬發送出去,而是等待一段時間,看看同一組中是否有其他報警,如果有一并發送 #??group_interval???????//告警時間間隔 #??repeat_interval??????//重復告警時間間隔,可以減少發送告警的頻率 #??receiver?????????????//接收者是誰 #??routes???????????????//子路由配置 receivers: -?name:?'mail-receiver'email_configs:-?to:?'xxxx@qq.com'當我 kill 進程:
prometheus 已經觸發告警:
在等待 1 分鐘,如果持續還是符合告警策略,則狀態為從 pending 變為 FIRING 會發送郵件到我的郵箱。
此時我的郵箱收到了一條告警消息:
alertmanager 也支持對告警進行靜默,在 alertmanager 的 WEBUI 中配置即可:
間隔了 4 分鐘,沒有收到告警,靜默生效:
一個小時沒有收到告警信息:
強勢開源一款小程序! 2021-11-07 強力推薦一個完善的物流(WMS)管理項目(附代碼) 2021-10-23 推薦一個 Spring Boot + MyBatis + Vue 音樂網站 2021-10-19 分享一套家庭理財系統(附源碼) 2021-09-20 推薦一個互聯網企業級別的開源支付系統 2021-09-04 推薦一套開源通用后臺管理系統(附源碼) 2021-08-21 一款神仙接私活兒軟件,吊到不行! 2021-07-31 基于 SpringBoot 的仿豆瓣平臺【源碼分享】 2021-07-18 干掉 Wordpress!這個開源建站神器有點吊! 2021-06-18 從朋友那里搞了 20 個實戰項目,速領! 2021-06-12如有收獲,點個在看,誠摯感謝
總結
以上是生活随笔為你收集整理的监控神器Prometheus,开箱即用!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 开源办公OA开发:新版考勤管理介绍
- 下一篇: 《MongoDB入门教程》第12篇 查询