Prometheus一條告警是怎麼觸發的

文章來源：愛可生雲數據庫
做者：張沈波

大綱

第一節：監控採集、計算和告警
第二節：告警分組、抑制、靜默
告警分組
告警抑制
告警靜默
收斂小結
第三節：告警延時
延時的三個參數
延時小結
總結

Prometheus+Grafana是監控告警解決方案裏的後起之秀，好比你們熟悉的PMM，就是使用了這個方案；前不久羅老師在3306pi公衆號上就寫過完整的使用教程《構建狂拽炫酷屌的MySQL 監控平臺》，因此咱們在這裏就再也不贅述具體如何搭建使用。

今天咱們聊一些Prometheus幾個有意思的特性，這些特性能幫助你們更深刻的瞭解Prometheus的一條告警是怎麼觸發的；本文提綱以下：

監控採集，計算和告警
告警分組，抑制和靜默
告警延時

第一節 監控採集、計算和告警
·
Prometheus以scrape_interval（默認爲1m）規則週期，從監控目標上收集信息。其中scrape_interval能夠基於全局或基於單個metric定義；而後將監控信息持久存儲在其本地存儲上。

Prometheus以evaluation_interval（默認爲1m）另外一個獨立的規則週期，對告警規則作按期計算。其中evaluation_interval只有全局值；而後更新告警狀態。

其中包含三種告警狀態：

·inactive：沒有觸發閾值
·pending：已觸發閾值但未知足告警持續時間
·firing：已觸發閾值且知足告警持續時間

舉一個例子，閾值告警的配置以下：

·收集到的mysql_uptime>=30,告警狀態爲inactive
·收集到的mysql_uptime<30,且持續時間小於10s，告警狀態爲pending
·收集到的mysql_uptime<30,且持續時間大於10s，告警狀態爲firing

⚠ 注意：配置中的for語法就是用來設置告警持續時間的；若是配置中不設置for或者設置爲0，那麼pending狀態會被直接跳過。

那麼怎麼來計算告警閾值持續時間呢，須要回到上文的scrape_interval和evaluation_interval，假設scrape_interval爲5s採集一次信息；evaluation_interval爲10s；mysql_uptime告警閾值須要知足10s持續時間。

如上圖所示：
Prometheus以5s（scrape_interval）一個採集週期採集狀態；
而後根據採集到狀態按照10s（evaluation_interval）一個計算週期，計算表達式；
表達式爲真，告警狀態切換到pending；
下個計算週期，表達式仍爲真，且符合for持續10s，告警狀態變動爲active，並將告警從Prometheus發送給Altermanger；
下個計算週期，表達式仍爲真，且符合for持續10s，持續告警給Altermanger；
直到某個計算週期，表達式爲假，告警狀態變動爲inactive，發送一個resolve給Altermanger，說明此告警已解決。

第二節 告警分組、抑制、靜默

第一節咱們成功的把一條mysql_uptime的告警發送給了Altermanger;可是Altermanger並非把一條從Prometheus接收到的告警簡簡單單的直接發送出去；直接發送出去會致使告警信息過多，運維人員會被告警淹沒；因此Altermanger須要對告警作合理的收斂。

如上圖，藍色框標柱的分別爲告警的接收端和發送端；這張Altermanger的架構圖裏，能夠清晰的看到，中間還會有一系列複雜且重要的流程，等待着咱們的mysql_uptime告警。

下面咱們來說Altermanger很是重要的告警收斂手段。

·分組：group
·抑制：inhibitor
·靜默：silencer

1.告警分組

告警分組的做用
·同類告警的聚合幫助運維排查問題
·經過告警郵件的合併，減小告警數量

舉例來講：咱們按照mysql的實例id對告警分組；以下圖所示，告警信息會被拆分紅兩組。

·mysql-A

mysql_cpu_high

·mysql-B

mysql_uptime
 mysql_slave_sql_thread_down
 mysql_slave_io_thread_down

實例A分組下的告警會合併成一個告警郵件發送；
實例B分組下的告警會合併成一個告警郵件發送；

經過分組合並，能幫助運維下降告警數量，同時能有效聚合告警信息，幫助問題分析。

2.告警抑制

告警抑制的做用

·消除冗餘的告警

舉例來講：同一臺server-A的告警，若是有以下兩條告警，而且配置了抑制規則。

·mysql_uptime
·server_uptime

最後只會收到一條server_uptime的告警。

A機器掛了，勢必致使A服務器上的mysql也掛了；如配置了抑制規則，經過服務器down來抑制這臺服務器上的其餘告警；這樣就能消除冗餘的告警，幫助運維第一時間掌握最核心的告警信息。

3.告警靜默

告警靜默的做用

阻止發送可預期的告警

舉例來講：夜間跑批時間，批量任務會致使實例A壓力升高；咱們配置了對實例A的靜默規則。

·mysql-A

qps_more_than_3000
  tps_more_than_2000
  thread_running_over_200

·mysql-B

thread_running_over_200

最後咱們只會收到一條實例B的告警。

A壓力高是可預期的，週期性的告警會影響運維判斷；這種場景下，運維須要聚焦處理實例B的問題便可。

收斂小結
這一節，咱們mysql_uptime同窗從Prometheus被出發後，進入了Altermanger的內部流程，並無如預期的被順利告出警來；它會先被分組，被抑制掉，被靜默掉；之因此這麼作，是由於咱們的運維同窗很忙很忙，精力很是有限；只有mysql_uptime同窗證實本身是很是重要的，咱們才安排它和運維同窗會面。

第三節 告警延時

第二節咱們提到了分組的概念，分組勢必會帶來延時；合理的配置延時，才能避免告警不及時的問題，同時幫助咱們避免告警轟炸的問題。

咱們先來看告警延時的幾個重要參數：

group_by:分組參數，第二節已經介紹，好比按照[mysql-id]分組
group_wait:分組等待時間，好比：5s
group_interval:分組嘗試再次發送告警的時間間隔，好比：5m
Repeat_interval: 分組內發送相同告警的時間間隔，好比：60m

延時參數主要做用在Altermanger的Dedup階段，如圖：

1.延時的三個參數

咱們仍是舉例來講，假設以下：

·配置了延時參數：

group_wait:5s
      group_interval:5m

repeat_interval: 60m
·有同組告警集A，以下：

a1
      a2
      a3

·有同組告警集B，以下：

b1
      b2

場景一：

1.a1先到達告警系統，此時在group_wait:5s的做用下，a1不會馬上告出來，a1等待5s，下一刻a2在5s內也觸發，a1,a2會在5s後合併爲一個分組，經過一個告警消息發出來；
2.a1,a2持續未解決，它們會在repeat_interval: 60m的做用下，每隔一小時發送告警消息。

場景二：

1.a1,a2持續未解決，中間又有新的同組告警a3出現，此時在group_interval:5m的做用下，因爲同組的狀態發生變化，a1,a2,a3會在5min中內快速的告知運維，不會被收斂60min（repeat_interval）的時間；
2.a1,a2,a3如持續無變化，它們會在repeat_interval: 60m的做用下，再次每隔一小時發送告警消息。

場景三：

1.a1,a2發生的過程當中，發生了b1的告警，因爲b1分組規則不在集合A中，因此b1遵循集合B的時間線；
2.b1發生後發生了b2，b1,b2按照相似集合A的延時規則收斂，可是時間線獨立。

延時小結

經過三個延時參數，告警實現了分組等待的合併發送（group_wait），未解決告警的重複提醒（repeat_interval），分組變化後快速提醒（group_interval）。

總結

本文經過監控信息的週期性採集、告警公式的週期性計算、合併同類告警的分組、減小冗餘告警的抑制、下降可預期告警的靜默、同時配合三個延時參數，講解了Prometheus的一條告警是怎麼觸發的；固然對於Prometheus，還有不少特性能夠實踐；如您有興趣，歡迎聯繫咱們，咱們是愛可生。

PS：雲樹Umon，針對大集羣監控告警作了大量的易用性的改造；一鍵圖形化部署安裝、圖形化配置Prometheus，告別羞澀的yaml配置、同時提供完善的告警統計分析視圖等特性，也一樣歡迎你們體驗~

精選文章彙總：
MySQL中間件性能測試 I
MySQL性能診斷實踐之系統觀測工具
Prometheus一條告警是怎麼觸發的
多從庫時半同步複製不工做的BUG分析
大規模集羣之告警系統實踐
安全考慮，binlog_row_image建議儘可能使用FULL
多從庫時半同步複製不工做的BUG分析
MySQL瓶頸分析與優化
使用VS Code調試MySQL