Alertmanager 告警路由

路由树决定谁接收、何时接收以及哪些告警合并为一条通知。先定义标签契约和团队责任，再编写 Route；不要基于告警标题或描述文本做机器路由。

1. 基于标签路由

标签	用途	示例
severity	决定优先级与升级方式	critical、warning、info
team	路由到责任团队	platform、checkout
service	聚合业务影响与下钻	checkout-api
environment	隔离测试与生产	production
cluster	多集群去重与定位	production-a

路由先匹配环境与团队，再按严重程度细分。根路由必须保留可审计的兜底 Receiver，防止新告警因遗漏标签被静默丢弃。

route:
  receiver: platform-default
  group_by: [alertname, cluster, service]
  routes:
    - matchers: [environment="production", team="checkout"]
      receiver: checkout-warning
      routes:
        - matchers: [severity="critical"]
          receiver: checkout-oncall

2. 多团队告警管理

平台告警由平台团队接收，应用可用性告警由开发/业务团队接收，业务指标告警由业务责任人接收。共同依赖故障可由平台先接收并通过抑制降低应用症状告警，而不是将所有告警统一广播。

团队、服务和通知组映射应纳入版本控制。组织变更、服务迁移和 OnCall 轮换后，需验证旧路由已回收、新路由可以收到 firing 与 resolved。

3. 路由最佳实践

• group_by 常包含 alertname、cluster、service，不能只按严重度分组。
• group_wait 用于合并首次出现的相关告警；repeat_interval 控制持续告警提醒。
• 测试、预发与生产使用不同接收器，避免演练呼叫生产值班。
• 通过测试告警验证路由，不能只依赖 amtool check-config 的语法结果。
• 每个 Receiver 明确负责人、渠道 SLA、失败监控和回退方案。