Alertmanager常用配置详解

Alertmanager 是监控体系中一个非常强大而关键的组件。它为 Prometheus 提供了强大的通知发送能力,也为用户提供了便捷高效的告警接收与管理手段。

Alertmanager 可以实现:

• 根据标签对大量告警进行高效处理,提取对用户最为关键的信息。
• 根据时间生成通知组,避免重复通知引起“告警疲劳”。
• 灵活的路由规则,将不同类别的告警发送到合适的接收器。
• 集群部署,每个实例都处理完全相同的告警,无单点故障。
• 支持丰富的 API 与 webhook 集成,灵活扩展接收器方式。

基础 的启动参数：

--web.route-prefix=/alertmanager  # 指定基础路径，默认无，加上后访问web UI则为 ip:9093/alertmanager 
--config.file=/etc/alertmanager/alertmanager.yml # 指定配置文件
--storage.path=/alertmanager/data/ # 指定存储文件路径
--web.listen-address=:9093 # 指定端口
--web.external-url=https://xxx.com/alertmanager/ # 外部访问目录
--web.enable-lifecycle # 设置热加载 开启后可通过“/-/reload”接口加载配置
--web.enable-admin-api # 开启管理接口(不常用)

Alertmanager 的配置主要包括三部分:

1. global:全局配置,包括 resolved 超时时间、SMTP 等。
2. route:告警路由规则,根据匹配条件将告警发送到不同接收器。
3. receivers:接收器列表,定义各种通知渠道如 email、webhook 等。

一个基本的 Alertmanager 配置如下:

global:
  resolve_timeout: 5m

route:
  receiver: default-receiver
  group_by: ['alertname']

receivers:
- name: 'default-receiver'
  email_configs:
  - to: 'xxx@example.com'

说明

1. global:

• resolve_timeout:至少 2 倍评估间隔。可避免提前 resolve。
• smtp_smarthost / smtp_from / etc:如果使用 email 接收器,需要定义 SMTP 相关配置。

2. route:

• receiver:每个 route 至少指向一个接收器,否则告警无处发送。
• group_by:合理的分组方式,避免重复通知。常用 alertname + 其他标签。
• group_interval:不短于 5 分钟,避免通知过于频繁。
• repeat_interval:不短于 30 分钟,重复通知的周期。
• match_re:使用正则表达式匹配告警可以实现灵活路由。

3. receivers:

• name:接收器名,在 route 中指向。
• email_configs:如果使用 email,定义 to、from、smarthost 等。
• webhook_configs:定义 webhook_url。重要的可以定义 send_resolved。

此外,还有一些高级配置:

• inhibit_rules:定义抑制规则,抑制无意义告警。
• templates:使用模板定义路由与接收器,实现重用。

route

route 部分定义了告警的分发路由规则。它通过匹配接收器和分组方式,控制告警被发送到哪些接收器以及如何进行分组。route 部分是 Alertmanager 配置中最为强大和核心的部分。
一个基本的 route 配置如下:

route:
  receiver: default-receiver
  group_by: ['alertname']

这个规则会将所有的告警发送到 default-receiver 接收器,并按 alertname 标签进行分组。
route 支持以下主要配置:

• receiver: 告警发送到的接收器,必须配置。可配置多个。
• group_by: 告警分组方式,通常使用 alertname 或者其它标签。
• group_interval: 分组间隔,默认 5 分钟。控制通知频率。
• repeat_interval: 重复通知间隔,默认 4 小时。
• match: match 多个条件时使用,支持:
  • alertname: 告警名称
  • severity: 告警级别
  • labels: 告警标签
• match_re: 使用正则表达式匹配
• continue: 继续到下一个路由,不匹配则报错

进阶配置：

route:

# 严重告警发送短信  
- receiver: 'sms-receiver'     
  match:      
    severity: critical     
  continue: true  

# 除严重外其它发送邮件  
- receiver: 'email-receiver'  

# 告警A发送opsgenie, 告警B发送webhook
- match:  
     alertname: AlertA 
  receiver: 'opsgenie-receiver'
- match:    
     alertname: AlertB   
  receiver: 'webhook-receiver' 

以上route 配置实现了:

• 严重(critical)告警发送短信
• 非严重告警发送邮件
• 告警A发送opsgenie
• 告警B发送webhook

大致来说,route 的匹配方式有:

1. 简单配置:所有告警发送到默认接收器,使用 group_by 分组。
2. match 匹配:通过 alertname、labels 选择发送到的接收器。
3. match_re 正则匹配:通过正则表达式灵活路由。
4. 多个规则:按顺序匹配,可以实现复杂的告警路由逻辑。

send_resolved

send_resolved 设置决定了接收器是否发送恢复通知。
其配置格式为:
send_resolved:
位置在 receivers 中各接收器的 webhook_configs | email_configs 中。例如:

receivers:
- name: 'default-receiver' 
  webhook_configs:
  - send_resolved: true   # 发送恢复通知
    url: <webhook_url>

- name: 'email-receiver'
  email_configs:
  - send_resolved: false  # 不发送恢复通知 
    to: <email_address> 

send_resolved可以在各种通知方式的具体配置中设置,控制该通知方式是否发送恢复通知。
send_resolved 的设置需要根据接收器的性质、负载能力及承载的告警类型综合判断。主要考量因素有:

1. 接收器的重要性与负载能力
2. 所承载告警的关键性与严重程度
3. 恢复通知的价值与意义
4. 避免干扰或淹没接收器

inhibit_rules

在 Alertmanager 中,inhibit_rules 用于配置告警抑制规则。它可以避免发送无意义的重复告警通知,提高警报的信噪比。
inhibit_rules 的配置方式如下:

inhibit_rules:
  # 规则1:来源匹配器,抑制目标匹配器
  - source_match:  
      severity: 'critical'
    target_match:
      severity: 'warning'  # 抑制严重性为 warning 的告警
    # 告警需相等的标识列表  
    equal: ['alertname', 'instance']  

  # 规则2:当存在XXX类型的警告,则抑制严重性为critical的其他告警   
  - source_match:
      alertname: 'XXX'  
      severity: 'critical'
    target_match:
      severity: 'critical'
    equal: ['instance']  # 告警需在同一instance上  

• source_match:来源告警的匹配条件,当触发此匹配的告警时会激活抑制规则。
• target_match:被抑制的目标告警匹配条件,与此匹配的告警会被抑制。
• equal:触发来源告警与目标告警需相等的标识列表,这保证它们是相同或相关的告警,应该被抑制。

inhibit_rules的工作流程是:
1. 当触发与 source_match 匹配的来源告警时,激活对应抑制规则。
2. 此后,所有与 target_match 匹配且在 equal列表中的标识与来源告警相等的目标告警会被抑制。
3. 来源告警恢复后,规则停止激活,目标告警恢复正常发送。

使用抑制规则可以避免频繁发送无意义的重复告警,减轻警报负荷,提高警报的价值与可用性。但是,也需要注意:
1. 不要过度抑制,可能会抑制掉关键告警。
2. equal 列表选取合适的标识,不同类型告警选取的标识会有所不同。
3. 同一个目标告警可以被多个规则抑制,规则之间不存在优先级。
4. 来源告警恢复并不能直接恢复被抑制的目标告警,目标告警需等到自己恢复。

Alertmanager配置钉钉告警的示例

global:
  resolve_timeout: 5m
  dingtalk_api_url: 'https://oapi.dingtalk.com/robot/send?access_token=...'  # 钉钉机器人Access Token

route:
  receiver: default-receiver    # 默认接收器
  group_by: [alertname]      # 按alertname分组
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
receivers:
- name: default-receiver      # 默认接收器
  dingtalk_configs:
  - send_resolved: true     # 发送恢复通知
    mention_users:   # 可提醒的用户  
     - '156xxxx8827'   
     - '189xxxx8301'

- name: critical-receiver   # 严重告警接收器
  dingtalk_configs: 
  - channel: '578xxxx'   # 钉钉群
    secrets:   
     - "key1": "value1"     # 自定义密钥,用于钉钉模板渲染  
     - "key2": "value2"

routes:
- match_re: {severity: critical} # 匹配严重性为critical的告警
  receiver: critical-receiver   # 发送至critical-receiver

templates:
- '/etc/alertmanager/dingtalk.tmpl'  # 钉钉通知模板

配置说明:

• 定义默认接收器default-receiver发送至钉钉机器人
• 定义严重接收器critical-receiver发送至指定钉钉群
• 使用自定义密钥为通知模板传入变量
• 按严重性critical路由至critical-receiver
• 使用dingtalk.tmpl模板定制钉钉通知内容