17.7.4 告警路由、分组与抑制策略

告警路由、分组与抑制策略是降低噪声、提升处置效率的核心能力。本节从路由匹配、分组聚合、抑制规则与常见误区四个维度说明设计方法与最佳实践，并提供可执行示例、验证与排错方法。

一、告警路由（Routing）#

路由决定告警发送到哪个接收器（receiver），以及匹配顺序与继承规则。

匹配方式：基于标签（labels）匹配，常见标签包含 severity、team、service、env。
匹配逻辑：
match：精确匹配
match_re：正则匹配
路由树结构：自顶向下匹配，子路由继承父路由的分组、抑制与接收器配置，直至命中并发送。
默认路由：必须配置 receiver 作为兜底，防止无路由告警丢失。

配置示例（含路由树与接收器）
路径：/etc/alertmanager/alertmanager.yml

global:
  resolve_timeout: 5m

route:
  receiver: "default-email"   # 兜底路由
  group_by: ["alertname","service","cluster"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h

  routes:
  - match:
      env: "prod"
      severity: "critical"
    receiver: "oncall-sms"
  - match_re:
      team: "ops|db"
    receiver: "team-im"
  - match:
      env: "staging"
    receiver: "staging-im"

receivers:
- name: "default-email"
  email_configs:
  - to: "ops@example.com"
    from: "alertmanager@example.com"
    smarthost: "smtp.example.com:25"

- name: "oncall-sms"
  webhook_configs:
  - url: "http://sms-gateway.local/alert"

- name: "team-im"
  webhook_configs:
  - url: "http://im-bot.local/alert"

- name: "staging-im"
  webhook_configs:
  - url: "http://im-bot.local/alert-staging"

应用配置并验证

# 1) 校验语法
amtool check-config /etc/alertmanager/alertmanager.yml

# 2) 重新加载 Alertmanager（HTTP reload）
curl -X POST http://127.0.0.1:9093/-/reload

# 3) 发送测试告警（包含标签用于路由）
cat > /tmp/alert.json <<'EOF'
[
  {
    "labels": {
      "alertname": "HostDown",
      "severity": "critical",
      "env": "prod",
      "team": "ops",
      "service": "node",
      "cluster": "c1"
    },
    "annotations": {
      "summary": "node down"
    },
    "startsAt": "2024-01-01T00:00:00Z"
  }
]
EOF

curl -X POST -H "Content-Type: application/json" \
  -d @/tmp/alert.json \
  http://127.0.0.1:9093/api/v2/alerts

命令解释
- amtool check-config：检查配置语法与必填字段。
- /-/reload：热加载配置，无需重启服务。
- /api/v2/alerts：注入测试告警验证路由是否符合预期。

二、告警分组（Grouping）#

分组用于将相同“根因”告警聚合为一条通知，降低重复告警。

分组依据：group_by 标签组合，如 ["alertname","service","cluster"]。
关键参数：
group_wait：首次告警等待时间，用于聚合短时间内爆发的告警。
group_interval：同组告警再次通知间隔。
repeat_interval：未恢复告警的重复提醒间隔。
实践建议：
过细分组会导致噪声；过粗分组会掩盖问题。
业务维度告警建议按 service + cluster 分组；基础设施可按 instance 分组。

分组效果演示（Prometheus 告警规则）
路径：/etc/prometheus/rules/node.rules.yml

groups:
- name: node.rules
  rules:
  - alert: NodeHighCPU
    expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 2m
    labels:
      severity: warning
      env: prod
      team: ops
      service: node
      cluster: c1
    annotations:
      summary: "CPU high on {{ $labels.instance }}"

预期效果
- 同一 alertname/service/cluster 下的多个实例告警被合并。
- group_wait=30s 内触发的告警在首次通知中聚合。

三、告警抑制（Inhibit）#

抑制用于“高级别告警出现时，屏蔽低级别告警”，避免重复处理。

核心场景：
主机宕机时抑制其上所有服务告警。
集群不可用告警出现时抑制单节点告警。
抑制规则要点：
source_match：触发抑制的高优先级告警。
target_match：被抑制的低优先级告警。
equal：必须一致的标签集合，如 ["service","cluster"]。
注意事项：
抑制规则过多易造成“告警黑洞”，需定期审计。
被抑制告警依然保留在 Alertmanager UI 中，便于回溯。

抑制规则示例
路径：/etc/alertmanager/alertmanager.yml

inhibit_rules:
- source_match:
    alertname: "ClusterDown"
    severity: "critical"
  target_match_re:
    severity: "warning|info"
  equal: ["service","cluster"]

- source_match:
    alertname: "HostDown"
    severity: "critical"
  target_match:
    service: "node"
  equal: ["instance"]

抑制效果验证

# 注入两条告警：ClusterDown（critical）+ NodeHighCPU（warning）
# 预期：warning 被抑制，仅在 UI 中标记为 inhibited
curl -X POST -H "Content-Type: application/json" \
  -d @/tmp/alert.json \
  http://127.0.0.1:9093/api/v2/alerts

# 观察抑制情况
amtool alert --alertmanager.url=http://127.0.0.1:9093

四、设计与落地建议#

统一标签规范：保证路由、分组与抑制可预测，推荐统一 env、team、service、severity。
分层告警级别：至少划分 critical、warning、info。
按业务分流：路由树按团队/业务域划分，避免跨团队噪声。
设置合理间隔：短时抖动使用 for 持续时间 + group_wait 控制。
先分组后抑制：分组减少通知数量，抑制减少无意义告警。

五、常见排错与处理#

告警未发送
检查路由是否命中：amtool alert -o json 查看标签与路由条件是否匹配。
查看 Alertmanager 日志：journalctl -u alertmanager -n 200.
告警大量重复
调大 group_wait 或 group_interval。
检查 group_by 是否过细（例如把 instance 放进业务告警）。
抑制失效
检查 equal 标签是否完全一致。
确保 source 告警为 firing 状态。

六、练习#

配置一条路由：env=prod 且 severity=critical 走短信，其余走 IM；通过 curl 注入告警验证命中情况。
将 group_by 调整为 ["alertname","service"]，观察同一集群多个实例是否被聚合。
编写抑制规则：当 HostDown 触发时抑制 NodeHighCPU，并用 amtool alert 验证 inhibited 状态。
模拟配置错误（去掉 receiver），使用 amtool check-config 找出问题并修复。