Prometheus Alertmanager生產設定趟過的坑總結

簡介

Alertmanager 處理由使用者端應用程式（如 Prometheus server）傳送的警報。它負責去重(deduplicating)，分組(grouping)，並將它們路由(routing)到正確的接收器(receiver)整合，如電子郵件，微信，或釘釘。它還負責處理警報的靜默/遮蔽(silencing)、定時傳送/不傳送(Mute)和抑制(inhibition)問題。

AlertManager 作為 開源的為 Prometheus 而設計的告警應用, 已經具備了告警應用各類豐富、靈活、可客製化的功能：

• 去重(deduplicating)：比如高可用 AlertManager 部署下，同一個告警同時發到所有的高可用節點，會根據 hash 進行去重
• 分組（grouping）：比如可以根據 AlertName, Instance, Job 等任意 label 對海量告警進行分組. 典型情況就是, 突然好多 Pod 都發出了 AlertName: InstanceDown 的 Alerts, 那麼可以直接根據 AlertName 進行分組後傳送, 這樣使用者只會收到一封 xxx 個 Pods InstanceDown 的告警郵件. 大大減少告警接收人員的收件量.
• 路由(routing): 將告警跟進一定的過濾條件傳送到指定的 receiver. 如: 滿足 job=db 的告警路由給 DBA; 滿足 team=team-A 的告警路由給 team-A 的郵件組...
• 接收器(receiver): 具體的通知渠道 + 收件人. 如: 郵件通知渠道+DBA郵箱; 釘釘通知渠道+SRE聯絡人;
• 靜默/遮蔽(silencing): 如應用釋出的時間段, 遮蔽相關的告警.
• 定時傳送/不傳送(Mute): 如工作時間(965, 每週 5天)通過郵件渠道傳送; 非工作時間(下班、週末、節假日)正常渠道 mute， 僅通過 on-call 渠道傳送給 on-call 人員
• 抑制(inhibition)：常用場景，高階別的告警觸發（firing）後，低階別的告警就不用發了。比如：磁碟空間的 critical 級別告警已經觸發(空間使用超過 90%), 這時候 warning 級別的告警(空間使用超過 80%)就被抑制.

除了沒有多租戶功能、沒有很好的 UI 介面、沒有告警歷史統計展示之外，作為告警應用， AlertManager 已經是非常強大了。