大綱
第一節：監控採集、計算和告警
第二節：告警分組、抑制、靜默
告警分組
告警抑制
告警靜默
收斂小結
第三節：告警延時
延時的三個參數
延時小結
總結
Prometheus+Grafana是監控告警解決方案裏的後起之秀，比如大家熟悉的PMM，就是使用了這個方案；前不久羅老師在3306pi公衆號上就寫過完整的使用教程《構建狂拽炫酷屌的MySQL 監控平臺》，所以我們在這裏就不再贅述具體如何搭建使用。
今天我們聊一些Prometheus幾個有意思的特性，這些特性能幫助大家更深入的瞭解Prometheus的一條告警是怎麼觸發的；本文提綱如下：
監控採集，計算和告警
告警分組，抑制和靜默
告警延時
第一節 監控採集、計算和告警
Prometheus以scrape_interval（默認爲1m）規則週期，從監控目標上收集信息。其中scrape_interval可以基於全局或基於單個metric定義；然後將監控信息持久存儲在其本地存儲上。
Prometheus以evaluation_interval（默認爲1m）另一個獨立的規則週期，對告警規則做定期計算。其中evaluation_interval只有全局值；然後更新告警狀態。
其中包含三種告警狀態：
inactive：沒有觸發閾值
pending：已觸發閾值但未滿足告警持續時間
firing：已觸發閾值且滿足告警持續時間
舉一個例子，閾值告警的配置如下：
如上圖所示：
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
告警分組
告警分組的作用
同類告警的聚合幫助運維排查問題
通過告警郵件的合併，減少告警數量
舉例來說：我們按照mysql的實例id對告警分組；如下圖所示，告警信息會被拆分成兩組。
mysql-A
mysql_cpu_high
mysql-B
mysql_uptime
mysql_slave_sql_thread_down
mysql_slave_io_thread_down
實例A分組下的告警會合併成一個告警郵件發送；
實例B分組下的告警會合併成一個告警郵件發送；
通過分組合並，能幫助運維降低告警數量，同時能有效聚合告警信息，幫助問題分析。
告警抑制
告警抑制的作用
消除冗餘的告警
舉例來說：同一臺server-A的告警，如果有如下兩條告警，並且配置了抑制規則。
mysql_uptime
server_uptime
最後只會收到一條server_uptime的告警。
A機器掛了，勢必導致A服務器上的mysql也掛了；如配置了抑制規則，通過服務器down來抑制這臺服務器上的其他告警；這樣就能消除冗餘的告警，幫助運維第一時間掌握最核心的告警信息。
告警靜默
告警靜默的作用
阻止發送可預期的告警
舉例來說：夜間跑批時間，批量任務會導致實例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階段，如圖：
延時的三個參數
我們還是舉例來說，假設如下：
配置了延時參數：
group_wait:5s
group_interval:5m
repeat_interval: 60m
有同組告警集A，如下：
a1
a2
a3
有同組告警集B，如下：
b1
b2
場景一：
a1先到達告警系統，此時在group_wait:5s的作用下，a1不會立刻告出來，a1等待5s，下一刻a2在5s內也觸發，a1,a2會在5s後合併爲一個分組，通過一個告警消息發出來；
a1,a2持續未解決，它們會在repeat_interval: 60m的作用下，每隔一小時發送告警消息。
場景二：
a1,a2持續未解決，中間又有新的同組告警a3出現，此時在group_interval:5m的作用下，由於同組的狀態發生變化，a1,a2,a3會在5min中內快速的告知運維，不會被收斂60min（repeat_interval）的時間；
a1,a2,a3如持續無變化，它們會在repeat_interval: 60m的作用下，再次每隔一小時發送告警消息。
場景三：
a1,a2發生的過程中，發生了b1的告警，由於b1分組規則不在集合A中，所以b1遵循集合B的時間線；
b1發生後發生了b2，b1,b2按照類似集合A的延時規則收斂，但是時間線獨立。
延時小結
通過三個延時參數，告警實現了分組等待的合併發送（group_wait），未解決告警的重複提醒（repeat_interval），分組變化後快速提醒（group_interval）。
總結
本文通過監控信息的週期性採集、告警公式的週期性計算、合併同類告警的分組、減少冗餘告警的抑制、降低可預期告警的靜默、同時配合三個延時參數，講解了Prometheus的一條告警是怎麼觸發的；當然對於Prometheus，還有很多特性可以實踐。