Alertmanager 處理由 Prometheus 服務器等客戶端應用程序發送的告警。負責對它們進行分組、靜默、抑制、去重并路由到正確的接收方，例如Email、Wechat、Webhook。

路由分組

在文章《》中我們介紹了告警（Alerts）進入Alertmanager后，首先進行路由匹配，本篇我們將詳解如何實現靈活、可擴展的路由配置。

Alertmanager的路由設計比較新穎，借鑒了Kubernetes的label selector能力，并結合樹形多層次深度優先匹配，實現了非常靈活和可擴展的路由，總結特點如下：

基于label匹配Alerts，解耦了告警規則與接收人

基于樹形結構深度優先匹配，支持多層次靈活匹配

在支持深度優先匹配基礎上，同時支持是否繼續匹配兄弟節點路由

我們將探討如何基于Alertmanger靈活強大的路由設計出適應組織的告警路由。

從一個小型團隊開始，Alertmanager能提供很好的能力，只需要配置簡單的業務轉發邏輯就可以工作。例如基礎告警轉到oncall，業務告警轉到業務負責部門。這些基本功能很好配置，不需要太多設計。

在一個更大的組織中，事情并不是那么簡單。可能有很多團隊，每個團隊都有自己的需求，希望將通知以不同的方式發送到不同的地方。一個組織通常會共享一組 Alertmanagers，因此首先要做的是在每個 Prometheus 的規則上建立一些標準標簽，例如service或team作為external_label以標識告警對應哪個團隊或者服務。

根路由

Alertmanger支持樹形路由，首先我們需要設置一個根路由（root route），以接收所有Alerts，并作為默認的路由。

需要確保根路由有一個合理的receiver，以便在未得到其他路由匹配時也可以及時處理。

子路由

在根路由下面，每個團隊都有一條路由，使用team標簽來匹配每個團隊的警報。每個團隊的Alerts都會路由到對應的團隊路由下，不會影響其他團隊。每個團隊都可以擁有子路由，例如，將非生產環境的Alerts發送到oncall，其他Alerts根據業務不同發給不同的開發同學。隨著時間的推移，可能會有更多的路線來覆蓋服務中的細微之處，例如應用不同的通知group_by或group_interval某些通知。

對于給定的組織或者團隊，雖然警報規則可能會經常更改，但Alertmanager的配置應該很少更改，通常最多每隔幾個月更改一次。因此，將所有內容保存在一個大文件中，可以通過git和Pull Rrequest向運行警報管理器的監控團隊完成任何更改申請，有點類似gitops的感覺。

可以在源代碼控制中為每個團隊提供一個YAML文件，他們可以使用他們的路由和接收器進行編輯，然后自動將它們整合在一起。同時要進行必要格式和邏輯檢查以防止破壞，可以借助 Alertmanager的工具實現解析和check配置。

需要注意的事情是，抑制規則目前是全局性的，如果沒有設計很好的labels方案，很難利用好抑制規則。

多路由匹配

Alertmanger支持匹配多條路由，可以在路由的每個節點開啟或者關閉，利用該特性，這可以支持特定的組織范圍的路由，只需要將該路由放到其他其他子路由前面，并開啟繼續匹配后續兄弟節點路由的開關即可。

例如，一些組織喜歡通過webhook記錄所有Alerts，并且不影響繼續路由到各個團隊，就可以利用該特性實現。

總結一下

根路由作為默認路由

每個團隊新建團隊范圍的路由，隔離不同團隊的Alerts

然后在各個團隊內，可以根據需要再細化出更多的路由