一、抑制機制
Alertmanager的抑制機制可以避免當某種問題告警產生之後使用者接收到大量由此問題導致的一系列的其它告警通知。例如當叢集不可用時，使用者可能只希望接收到一條告警，告訴他這時候叢集出現了問題，而不是大量的如叢集中的應用異常、中介軟體服務異常的告警通知。
在Alertmanager配置檔案中，使用inhibit_rules定義一組告警的抑制規則：
inhibit_rules: [ - <inhibit_rule> ... ]
每一條抑制規則的具體配置如下：
target_match: [ <labelname>: <labelvalue>, ... ] target_match_re: [ <labelname>: <regex>, ... ] source_match: [ <labelname>: <labelvalue>, ... ] source_match_re: [ <labelname>: <regex>, ... ] [ equal: '[' <labelname>, ... ']' ]
當已經傳送的告警通知匹配到target_match和target_match_re規則，當有新的告警規則如果滿足source_match或者定義的匹配規則，並且已傳送的告警與新產生的告警中equal定義的標籤完全相同，則啟動抑制機制，新的告警不會傳送。
具體配置
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
二、臨時靜默
除了基於抑制機制可以控制告警通知的行為以外，使用者或者管理員還可以直接透過Alertmanager的UI臨時遮蔽特定的告警通知。透過定義標籤的匹配規則(字串或者正規表示式)，如果新的告警通知滿足靜默規則的設定，則停止向receiver傳送通知。
用於停機維護，或者有一個不需要處理的告警資訊
http://192.168.10.14:9093/#/alerts
- 建立靜默規則
進入Alertmanager UI，點選"Silences"---在點右上角的"New Silence"顯示如下內容：
或者
進入Alertmanager UI，點選“點選Alerts”----那個服務多長時間不需要報警
定義靜默規則的開始時間以及持續時間和結束時間，透過Matchers部分可以設定多條匹配規則(字串匹配或者正則匹配)。填寫當前靜默規則的建立者以及建立原因後，點選"Create"按鈕即可。
透過"Preview Alerts"可以檢視預覽當前匹配規則匹配到的告警資訊。靜默規則建立成功後，Alertmanager會開始載入該規則並且設定狀態為Pending,當規則生效後則進行到Active狀態。
- 檢視靜默規則
點選”silences“在“Active”檢視正在執行的靜默規則
- 匹配告警資訊失效
當靜默規則生效以後，從Alertmanager的Alerts頁面下使用者將不會看到該規則匹配到的告警資訊。
- 取消靜默規則
對於已經生效的規則，使用者可以透過手動點選”Expire“按鈕使當前規則過期。
三、路由匹配
每一個告警都會從配置檔案中頂級的route進入路由樹，需要注意的是頂級的route必須匹配所有告警(即不能有任何的匹配設定match和match_re)，每一個路由都可以定義自己的接受人以及匹配規則。預設情況下，告警進入到頂級route後會遍歷所有的子節點，直到找到最深的匹配route，並將告警傳送到該route定義的receiver中。但如果route中設定continue的值為false，那麼告警在匹配到第一個子節點之後就直接停止。如果continue為true，報警則會繼續進行後續子節點的匹配。如果當前告警匹配不到任何的子節點，那該告警將會基於當前路由節點的接收器配置方式進行處理。
其中告警的匹配有兩種方式可以選擇。一種方式基於字串驗證，透過設定match規則判斷當前告警中是否存在標籤labelname並且其值等於labelvalue。第二種方式則基於正規表示式，透過設定match_re驗證當前告警標籤的值是否滿足正規表示式的內容。
如果警報已經成功傳送通知, 如果想設定傳送告警通知之前要等待時間，則可以透過repeat_interval引數進行設定。
案例1：根據服務名稱匹配
route:
group_by: ['alertname'] //定義分組,根據label標籤進行分組
group_wait: 10s //分組等待時間，也就是說在10秒內同一個組中有沒有一起報警的，如果有則同時發出報警郵件，也就是有2個報警同時發在一個郵件
group_interval: 10s //告警時間間隔
repeat_interval: 10m //重複告警間隔，也就是觸發的一個告警在10分鐘內沒有處理則再次發一封郵件。
continue: false //若路由上的continue欄位的值為false，則遇到第一個匹配的路由分支後即終止。否則，將繼續匹配後續的子節點;
receiver: 'receiver-01' //預設郵箱
routes: //啟用一個子路由
- receiver: 'receiver-dba' //接收者為receiver-dba
group_wait: 10s //分組等待時間
match_re: //匹配一個正則
service: mysql|db //service標籤包含mysql和db的統一傳送給dba的郵箱
continue: false //若路由上的continue欄位的值為false，則遇到第一個匹配的路由分支後即終止。否則，將繼續匹配後續的子節點;
- receiver: 'receiver-01' //接收者為receiver-01
group_wait: 10s //分組時間
match:
serverity: error //將serverity標籤值包含error的傳送給yunwei的郵箱
continue: false //若路由上的continue欄位的值為false，則遇到第一個匹配的路由分支後即終止。否則，將繼續匹配後續的子節點;
receivers: //定義接收者的郵箱
- name: 'receiver-01' //接收者名字，要和routes中的receiver對應
email_configs:
- to: '11111@qq.com' //receiver-01的郵箱地址
- name: 'receiver-dba' //接收者名字，要和routes中的receiver對應
email_configs:
- to: '2222@qq.com' //receiver-dba的郵箱地址
案例2：根據告警規則名稱匹配
route:
group_by: ['instance'] # 根據 instance 標籤分組
continue: true # 為true則還需要去匹配子路由。
receiver: receiver-01
routes:
- receiver: 'receiver-01'
match:
alertname: 'InstanceDown' # 告警的名字是 InstanceDown 則傳送給 receiver-03
- receiver: 'webchat'
match_re:
alertname: 'Cpu.*' # 告警的名字以 Cpu開頭的 則傳送給 webchat
- receiver: 'dingtalk'
match:
alertname: 'InstanceDown' # 告警的名字是 InstanceDown 則傳送給 dingtalk
receivers:
- name: 'receiver-01'
email_configs:
- to: '1111@qq.com'
- name: 'webchat'
webhook_configs:
- url: 'http://192.168.11.61:5000'
send_resolved: true
- name: 'dingtalk'
webhook_configs:
- url: 'http://192.168.11.61:8060/dingtalk/webhook1/send'
send_resolved: true
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 60s
repeat_interval: 24h
receiver: webchat
routes:
- receiver: wechat
group_wait: 10s
continue: true #當訊息傳送給微信後，繼續匹配，就能把訊息在傳送到釘釘
- receiver: dingtalk
group_wait: 10s
receivers:
- name: 'wechat'
webhook_configs:
- url: 'http://192.168.11.60:8999/webhook?key=自己的key'
- name: 'dingtalk'
webhook_configs:
- url: 'http://192.168.11.60:8060/dingtalk/webhook1/send'
四、告警分組
有的時候為了能夠一次性收集和傳送更多的相關資訊時，可以透過group_wait引數設定等待時間，如果在等待時間內當前group接收到了新的告警，這些告警將會合併為一個通知向receiver傳送。
而group_interval配置，則用於定義相同的Group之間傳送告警通知的時間間隔。
例如，當使用Prometheus監控多個叢集以及部署在叢集中的應用和資料庫服務，並且定義以下的告警處理路由規則來對叢集中的異常進行通知。
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
預設情況下所有的告警都會傳送給叢集管理員default-receiver，因此在Alertmanager的配置檔案的根路由中，對告警資訊按照叢集以及告警的名稱對告警進行分組。
如果告警時來源於資料庫服務如MySQL或者Cassandra，此時則需要將告警傳送給相應的資料庫管理員(database-pager)。這裡定義了一個單獨子路由，如果告警中包含service標籤，並且service為MySQL或者Cassandra,則向database-pager傳送告警通知，由於這裡沒有定義group_by等屬性，這些屬性的配置資訊將從上級路由繼承，database-pager將會接收到按cluster和alertname進行分組的告警通知。
而某些告警規則來源可能來源於開發團隊的定義，這些告警中透過新增標籤team來標示這些告警的建立者。在Alertmanager配置檔案的告警路由下，定義單獨子路由用於處理這一類的告警通知，如果匹配到告警中包含標籤team，並且team的值為frontend，Alertmanager將會按照標籤product和environment對告警進行分組。此時如果應用出現異常，開發團隊就能清楚的知道哪一個環境(environment)中的哪一個應用程式出現了問題，可以快速對應用進行問題定位。
告警規則：https://samber.github.io/awesome-prometheus-alerts/rules.html#host-and-hardware