3. Alertmanager核心概念
Alertmanager 是 Prometheus 生态中负责告警路由、去重、静默与通知发送的核心组件。理解其五大核心概念——分组 (Grouping)、抑制 (Inhibition)、静默 (Silence)、路由 (Routing)、接收器 (Receiver)——是编写可靠告警自愈剧本的前提。本章将逐一拆解这些概念,并给出可直接复用的配置示例。
学习目标:掌握 Alertmanager 配置结构中 route、receivers、inhibit_rules、silences 的协作关系,能够独立设计告警分组策略与抑制规则。
3.1 核心概念总览
下表从功能定位、配置入口、典型场景三个维度对比五大概念,帮助建立全局认知:
| 概念 | 功能定位 | 配置入口 | 典型场景 |
|---|---|---|---|
| 分组 (Grouping) | 将相似告警合并为一条通知,减少告警风暴 | route.group_by |
同一主机多指标同时告警,合并为一条消息 |
| 抑制 (Inhibition) | 当某告警触发时,抑制其他相关告警 | inhibit_rules |
主机宕机后抑制其上的所有服务告警 |
| 静默 (Silence) | 基于匹配器临时屏蔽特定告警,不发送通知 | API / amtool / Web UI | 计划内维护窗口屏蔽对应告警 |
| 路由 (Routing) | 根据标签匹配将告警分发到不同接收器 | route.routes |
严重级别告警发 PagerDuty,普通告警发邮件 |
| 接收器 (Receiver) | 定义通知发送的目标渠道与配置 | receivers |
Email、Slack、Webhook、PagerDuty 等 |
3.2 分组 (Grouping) —— 合并同类告警
分组是 Alertmanager 最核心的降噪机制。当大量告警同时触发时,分组将具有相同 group_by 标签值的告警合并为一条通知,避免接收者被信息淹没。
3.2.1 分组参数详解
| 参数 | 默认值 | 说明 |
|---|---|---|
group_by |
['alertname', 'cluster'] |
按哪些标签分组,支持数组 |
group_wait |
30s |
首次通知前等待更多告警加入分组 |
group_interval |
5m |
同一分组新告警的发送间隔 |
repeat_interval |
4h |
已解决告警重新发送的间隔 |
3.2.2 分组配置示例
route:
receiver: 'default-receiver'
group_by: ['alertname', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- match:
severity: 'critical'
receiver: 'critical-receiver'
group_wait: 10s
group_interval: 1m
实战建议:对于 critical 级别告警,建议缩短
group_wait 和 group_interval,确保关键问题快速触达;对于 warning 级别,可适当延长以减少干扰。
3.3 抑制 (Inhibition) —— 消除冗余告警
抑制规则定义了一种“如果某告警存在,则抑制其他告警”的依赖关系。典型场景:当节点宕机 (NodeDown) 触发时,抑制该节点上所有服务不可达告警。
3.3.1 抑制规则结构
inhibit_rules:
- source_matchers:
- 'alertname = NodeDown'
target_matchers:
- 'alertname =~ ".*Down|.*Unreachable"'
equal:
- 'instance'
| 字段 | 说明 |
|---|---|
source_matchers |
源告警匹配条件,触发抑制的告警 |
target_matchers |
目标告警匹配条件,被抑制的告警 |
equal |
标签列表,源和目标在这些标签值相同时才抑制 |
注意:
equal 字段必须谨慎设置。如果缺失,可能导致跨实例的误抑制。例如,equal: ['instance'] 确保只有同一实例的告警才会被抑制。
3.4 静默 (Silence) —— 计划内屏蔽
静默用于在特定时间段内屏蔽匹配的告警,常用于维护窗口、已知问题豁免。静默可以通过 Alertmanager Web UI、amtool 命令行或 API 创建。
3.4.1 静默匹配器语法
| 操作符 | 示例 | 说明 |
|---|---|---|
= |
severity = critical |
精确匹配 |
!= |
severity != info |
不等于 |
=~ |
alertname =~ ".*Down" |
正则匹配 |
!~ |
instance !~ "dev-.*" |
正则排除 |
3.4.2 使用 amtool 创建静默
amtool silence add \
--alertmanager.url=http://alertmanager:9093 \
--author="sre-team" \
--comment="Scheduled maintenance for db cluster" \
--duration=2h \
'alertname =~ ".*Down"' \
'instance =~ "db-.*"'
3.5 路由 (Routing) —— 告警分发决策树
路由树是 Alertmanager 配置中最复杂的部分。Alertmanager 从根路由开始,逐级匹配子路由,将告警分发到对应的接收器。
3.5.1 路由匹配逻辑
- 根路由:必须存在,定义全局默认接收器和分组参数。
- 子路由:通过
match或match_re匹配告警标签,支持嵌套。 - 匹配优先级:子路由按配置顺序匹配,第一个匹配成功的路由生效,后续路由不再检查。
- 继续匹配:设置
continue: true可使告警继续匹配后续路由,实现多接收器通知。
3.5.2 路由配置示例
route:
receiver: 'default-receiver'
group_by: ['alertname']
routes:
- match:
severity: 'critical'
receiver: 'pagerduty-critical'
continue: false
- match_re:
service: '^(api|web)'
receiver: 'slack-frontend'
continue: true
- match:
team: 'database'
receiver: 'email-dba'
调试技巧:使用
amtool alert query 查看告警当前匹配的路由和接收器,快速定位分发问题。
3.6 接收器 (Receiver) —— 通知渠道集成
接收器定义了告警通知的最终去向。Alertmanager 原生支持多种集成,最常用的是 Webhook(用于自愈剧本触发)和 Email。
3.6.1 常用接收器配置
| 接收器类型 | 配置字段 | 适用场景 |
|---|---|---|
webhook_configs |
url, send_resolved |
触发自愈剧本、对接工单系统 |
email_configs |
to, smarthost, auth_* |
非紧急告警通知 |
slack_configs |
api_url, channel, title |
团队即时通讯 |
pagerduty_configs |
routing_key, severity |
关键告警值班调度 |
3.6.2 Webhook 接收器示例(自愈剧本入口)
receivers:
- name: 'autoheal-webhook'
webhook_configs:
- url: 'http://autoheal-engine:8080/webhook'
send_resolved: true
http_config:
basic_auth:
username: 'sre'
password: 'secret'
自愈集成要点:务必设置
send_resolved: true,让自愈引擎能感知告警恢复,避免重复执行修复动作。同时建议在 Webhook 请求中携带 X-Alertmanager-Instance 自定义头,便于多实例负载均衡。
3.7 完整配置示例与 SVG 流程
下图展示了一个生产级 Alertmanager 配置的完整告警处理流程,涵盖分组、路由、抑制、静默和接收器协作:
3.8 配置验证与调试
完成配置后,务必使用以下方法验证正确性:
- 语法检查:
amtool check-config alertmanager.yml - 路由模拟:
amtool config routes --alertmanager.url=http://localhost:9093 - 告警注入测试:使用
curl向 Alertmanager API 发送测试告警,观察路由与接收器行为。
# 注入测试告警
curl -X POST http://alertmanager:9093/api/v1/alerts \
-H "Content-Type: application/json" \
-d '[
{
"labels": {
"alertname": "TestAlert",
"severity": "critical",
"instance": "node1"
},
"annotations": {
"summary": "This is a test alert"
}
}
]'
常见陷阱:
- 路由
continue: true可能导致告警被重复发送到多个接收器,需确认业务是否接受。 - 抑制规则中
equal字段缺失会导致跨实例误抑制,务必显式声明。 - 静默匹配器使用正则时,注意转义特殊字符,建议先用
amtool silence query验证匹配范围。