通知策略与路由树

从一条默认策略说起

每个组织都有一棵通知策略树，根节点就是默认策略（Default policy）：任何没被下级规则命中的告警都会落到它绑定的联系点。所以第一件事是配好一个「兜底」联系点，保证没有告警会静悄悄地掉在地上。

按标签路由

树的下层是若干路由（nested policy），每条按标签匹配器决定告警去向，命中即走。匹配用的标签来自规则或实例的 label（见告警规则），一条示意路由树：

Default → email-oncall
 ├─ severity="critical"            → PagerDuty
 │   └─ team="payments"            → slack-payments（覆盖父级）
 ├─ team="payments"                → slack-payments
 └─ alertname=~"disk_.*"           → webhook-tickets

要点：子规则在父规则命中的分支内继续匹配；匹配操作符支持 =、!=、=~（正则）、!~。

分组与四个时间参数

通知不是「一条告警一条消息」，而是先按标签分组再发送，四个参数共同决定节奏：

注意： 这四个参数在 UI 上属于每条策略节点，留空的会继承父级。半夜被同一组告警反复刷屏，多半是 repeat_interval 设得太短，先查这里。

抑制与静音时段

• 抑制（Inhibition）：高级别告警存在时，压掉由它派生的低级别告警。例如集群整体宕机的 critical 正在 Firing 时，其上几十台机器的 warning 磁盘告警就被抑制。规则由「源匹配器 + 目标匹配器 + 相等标签」三部分组成。
• 静音时段（Mute timing）：按时间窗口临时屏蔽通知，例如非工作时间不发送低优先级告警。它基于策略所在时区计算日历时间，与静默（silence，按标签与有效期屏蔽）互补，静默的用法见静默与通知模板。

升级路径

OSS 版没有内置的「N 分钟无人处理则换人」式升级编排；实践中通常把 severity="critical" 路由到 PagerDuty，用其自身的升级策略（escalation policy）完成电话→短信→备值的逐级升级。Enterprise 与 Cloud 版本在通知策略上提供更多编排与文件化管理能力（策略的 Provisioning 即属此类），具体以你的实例界面为准。

常见坑

• 只配了路由没配标签：规则忘打 team 标签，告警全部落到默认策略，看起来像「路由坏了」。
• 子节点覆盖了父联系点：子规则命中后用自己的联系点，不再回退父级。
• 界面改不动策略：策略被文件 Provisioning 或企业版功能接管时 UI 只读，检查实例版本与 provisioning 目录。

下一步

• 上游标签从哪来，看告警规则。
• 出口渠道怎么建，看联系点。
• 临时消音与消息定制，读静默与通知模板。
• 全链路演练，见指标与日志告警实战。