一、背景

轉轉基于Prometheus落地了一體化監控系統，并自研了告警系統，但研發同學每人每天都會接收到很多告警，導致重要的告警被淹沒，部分同學會選擇直接屏蔽掉所有告警，進一步加重問題。告警過多等同于沒有告警。

另外，多個告警之間通常具有一定的關聯性，如：SQL執行錯誤告警導致異常日志過多告警。而面對雜亂無章的告警，很難快速分析出告警的根本原因。

告警降噪治理十分重要，在此背景下，我們基于Alertmanager擴展研發了轉轉告警中心。

二、規范與SDK

2.1 發送告警

Alertmanager提供了告警發送的OpenAPI，其中，告警的labels用于識別同一條告警并對告警去重、降噪，相同labels的告警的annotations會被覆蓋。startsAt與endsAt分別為告警發生時間與結束時間。

[
    {
        "labels": {
            "<labelname>": "<labelvalue>",
            ...
        },
        "annotations": {
            "<labelname>": "<labelvalue>",
        },
        "startsAt": "<rfc3339>",
        "endsAt": "<rfc3339>",
        "generatorURL": "<generator_url>"
    },
    ...
]

一條告警從提交到發送再到接收人的流程大致如下圖所示，其中，Alertmanager需要集群部署來保證高可用性，需要注意的是，發送告警時不能對集群做負載均衡，必須要對集群內所有的Alertmanager發送告警才能保證高可用性。

2.2 常用標簽

Alertmanager為基于標簽的告警降噪，需提前規范告警常見標簽。

• ENV：環境，如：線上環境、測試環境
• APP：服務名
• SOURCE：告警來源，如：日志告警、JVM告警
• NAME：告警名稱
• LEVEL：告警等級，如：P0告警、P5告警
• INSTANCE：告警實例IP
• RECEIVER_TYPE：告警接受者類型
• RECEIVER：告警接受者，與RECEIVER_TYPE配合使用，如RECEIVER_TYPE=郵件，RECEIVER即為郵箱地址。

Alertmanager標簽名的正則規則為??[a-zA-Z_][a-zA-Z0-9_]*??，在真正發送通知時，最好將標簽名做一次中文映射轉換。

2.3 SDK

我們針對Alertmanager開發了發送告警的SDK，如下所示，發送告警非常簡單，SDK默認會為每條告警自動增加服務名、環境、IP、告警等級，并按照接收方拆開為多條告警發送。每一項內容都是標簽，其中value較為特殊，放在了annotations內，其他均放在了labels內用于唯一識別一條告警。

AlertManager alertManager = AlertManager.builder()
               //告警名稱，必傳
              .name("告警Demo")
               //告警標簽，拓展信息，非必傳
              .label("label1", "value1")
              .label("label2", "value2")
               //告警值，非必傳
              .value("123")
               //指定為企業微信告警，并指定發送人
              .wechat("zhangsan", "lisi")
              .build();
//同步發送告警
alertManager.send();
//異步發送，默認線程池
alertManager.sendAsync();
//自定義線程池發送
ThreadPoolExecutor executor;
executor.execute(alertManager);

三、告警降噪

3.1 分組去重

分組機制可以將多條告警信息合并成一個通知。例如，當集群中有數百個正在運行的服務實例，假如此時發生了網絡故障，結果就會有數百個告警被發送到Alertmanager。

而作為用戶，可能只希望能夠在一個通知中就能查看哪些服務實例受到影響。這時可以按照服務所在集群或者告警名稱對告警進行分組，將這些告警聚合在一起成為一個通知。

Alertmanager可以將收到的告警按照特定的標簽分組、去重，并基于以下參數決定何時發送組內的告警通知，Alertmanager的每一次通知都會包含當前組內的所有告警。

• 初始等待時間（group_wait）：一組告警第一次發送之前等待的時間，用于等待同一組的更多告警合并發送。
• 變化等待時間（group_interval）：一組已發送初始通知的告警在接收到新告警或有告警恢復后，再次發送通知前等待的時間。
• 重復等待時間（repeat_interval）：一組已發送初始通知的告警，組內告警均沒有恢復且沒有新增告警，再次發送通知前等待的時間。

下面以一張圖，來展示從告警產生到合并到某個集合中，到發送通知的整個過程。三角形和圓形表示不斷產生的告警，矩形代表實際的通知時間以及告警內容。

3.2 恢復通知

Alertmanager自帶恢復通知，默認5m沒有收到告警后，告警將被認為恢復，然后會等待group_interval后通知給用戶。發送告警時也可以指定告警恢復時間，如下所示：

//告警發生時間
Date startTime = new Date();
//告警結束時間，如果在startTime~endTime期間沒有告警，則認為告警恢復
Date endTime = new Date(new Date().getTime() + 5 * 60 * 1000);
AlertManager.builder().startsAt(startTime).endsAt(endTime)..

需要注意的是，endTime如果小于當前時間，會認為告警在發出時就已經恢復，這條告警不會通知。

3.3 告警分級

我們將告警分為P0~P5六個等級，告警等級默認取決于服務重要性，轉轉服務按照重要性分了A、B、C、D、E五個等級，服務重要性與告警等級的對應關系：A → P1，B → P2，C → P3，D → P4，E → P5。發送告警時也可以指定告警等級，如下：

AlertManager.builder().level(AlertManager.Level.P0)...

告警分級的目的是盡量讓高等級的告警及時發出，低等級的告警減少用戶打擾次數。不同等級告警的分組、去重時間均不相同。

如：P4/P5的告警初始時會等待3m收集告警，并將當前告警接收者的所有告警匯總到一條通知內；

P0的告警只會等待15s收集告警，并按照告警接收者、環境、服務名、告警來源、告警名稱為維度拆分成多個通知。

route:
group_by: ['...']
receiver: 'web.hook'
routes:
  - group_by: ['_RECEIVER', '_RECEIVER_TYPE']
    group_wait: 3m
    group_interval: 10m
    repeat_interval: 4h
    matchers:
    - _LEVEL =~ "P4|P5"
    continue: false
  - group_by: ['_RECEIVER', '_RECEIVER_TYPE', '_ENV']
    group_wait: 2m
    group_interval: 10m
    repeat_interval: 2h
    matchers:
    - _LEVEL = "P3"
    continue: false
  # ... 省略P3、P2、P1、P0降噪策略

3.4 通知合并

統一使用Alertmanager webhook通知，一次通知內容會包含分組內的多個報警，我們會按照告警相似度對告警做合并，如下為6條報警合并成一條通知，其中，告警值與服務實例一一對應。

定義相似度：對于多個報警的labels，只有一個label value不一樣，剩余的label key與label value均相同，則認為相似并合并；一次Alertmanager webhook通知可按照相似度拆分成多種告警，不同的告警提取公共標簽，最終推送到一條通知內。

如下，為4條告警合并到一條通知，可清晰的看到兩臺機器的異常日志報警的原因是由于Druid執行SQL錯誤導致。

3.5 告警抑制

抑制是指當某一告警發出后，可以停止重復發送由此告警引發的其它告警的機制。

當同一個服務、環境、告警來源、IP、接受者、告警名稱，同時出現多個等級的告警時，高等級的告警會抑制低等級告警的通知。

如：告警名稱為FGC次數，P1告警閾值為20次，P2告警為10次，當某個實例的FGC次數達到20次以上時，只會發送P1告警，不會發送P2告警。

inhibit_rules:
  - source_matchers:
      - _LEVEL="P4"
    target_matchers:
      - _LEVEL="P5"
    equal: ['_APP', '_ENV', '_SOURCE', '_INSTANCE', '_RECEIVER', '_RECEIVER_TYPE', '_NAME']
  - source_matchers:
      - _LEVEL="P3"
    target_matchers:
      - _LEVEL=~"P4|P5"
    equal: ['_APP', '_ENV', '_SOURCE', '_INSTANCE', '_RECEIVER', '_RECEIVER_TYPE', '_NAME']
  # ... 省略P2、P1、P0抑制策略

四、多通知機制

支持企業微信、企業微信群、短信、郵件、電話、WebHook，可在一個告警內同時指定多種接收方式，我們會自動按照接收人拆分成多條告警。

• 企業微信、企業微信群、郵件、WebHook：最詳細，發送告警與恢復通知。
• 短信：相對以上，只是不會發送恢復通知。
• 電話：不會發送恢復通知，并且只會播報報警標題與告警服務名。

AlertManager.builder()
           //企業微信
          .wechat("zhangsan","lisi")
           //指定了消息通道的企業微信
          .wechat(Arrays.asList("zhangsan","lisi"), "10")
           //企業微信群聊機器人
          .wechatRobot("企業微信群機器人key")
           //郵件
          .mail("zhangsan@zhuanzhuan.com", "lisi@zhuanzhuan.com")
           //Http回調
          .webhook("http://www.baidu.com")
           //短信
          .sms("188xxxxxxxx", "180xxxxxxxx")
           //語音電話
          .phone("188xxxxxxxx", "180xxxxxxxx")..

五、未恢復告警

為了防止告警過多時淹沒了重要告警，在每條告警的最后，都提供了一個未恢復告警鏈接，用于實時查詢當前未恢復的告警。

未恢復告警擁有三種狀態：活躍、靜默、抑制。其中，活躍狀態可以設置靜默，靜默狀態可以查看被誰靜默。

六、靜默告警

基于Alertmanager OpenAPI，支持基于標簽的靜默告警，每條告警通知內都提供了一個鏈接用于快速靜默，也可以在未恢復告警內靜默告警。

點擊新增靜默后，會自動補充靜默匹配的標簽項，也可以增減標簽項，如：去掉INSTANCE標簽維度以便匹配所有的機器，修改_RECEIVER為其他人等。需要注意的是，添加靜默時RECEIVER必須要指定。

添加完成后，會自動跳轉到靜默列表，并展示剛剛添加的靜默項。

在靜默列表內可查詢所有的活躍、過期的靜默項，可編輯、刪除、查看影響的告警。

查看受影響的告警為實時查詢，如果當前靜默沒有匹配到任何告警，查詢結果會為空。

七、告警歷史

告警通知給用戶后，我們會保留三個月的歷史告警記錄列表。

八、總結

Alertmanager提供了告警降噪的策略，我們在Alertmanager的基礎上制定了標簽規范、告警分級降噪、分級抑制、告警合并，并基于Alertmanager OpenAPI擴展了未恢復告警、靜默告警、告警歷史。Alertmanager雖然不是告警降噪的銀彈，但也可以解決大部分問題，如果你也面臨著告警轟炸的問題，可以嘗試一下。

關于作者

苑沖，轉轉架構部存儲服務負責人，主要負責MQ、監控系統、Redis、KV存儲等。愛學習，喜歡以辯證思維與變化思維思考。