它负责什么
规则引擎评估规则并推送触发的告警，接收端负责后续处理：去重、分组、抑制、静默与路由通知。它是告警送达链路的核心组件，也是最常出现告警已产生却没人收到问题的地方。
常见误解
最常见的误解是在接收端找阈值：阈值与表达式都在规则文件里，接收端只决定告警送到哪里、以什么形式送达。排查未送达问题时，顺序应是先确认规则是否已推送，再看路由是否匹配到预期通道，最后验证通道可用。
基本信息
| 去重 | 同一告警的多次推送合并为一条 |
|---|---|
| 分组 | 按维度把相关告警合并成一条通知 |
| 抑制 | 上游故障压制衍生告警 |
| 静默 | 窗口内按条件压掉通知 |
| 路由 | 按标签把告警送到对应接收方 |
典型使用场景
- 分级通知：不同级别送到不同通道
- 批量降噪：机房级故障时压制大量衍生告警
- 变更静默：发布窗口内压掉已知告警
- 团队分流：按服务归属把告警送到对应团队
- 统一收敛：把多条相关告警合并为一条可读通知
告警数据流
告警数据流
规则引擎评估
| 推送已触发与已解决的告警
v
告警接收端
| 去重 -> 分组 -> 抑制 -> 静默 -> 路由
v
接收通道：邮件 / 即时消息 / 电话服务 / 回调接口处理环节
| 环节 | 作用 | 排障关注点 |
|---|---|---|
| 去重 | 合并重复推送 | 同一告警是否只出现一次 |
| 分组 | 把相关告警合成一条 | 通知条数与可读性 |
| 抑制 | 压制衍生告警 | 是否误压真实故障 |
| 静默 | 窗口内压掉通知 | 是否存在过期未清理的静默 |
| 路由 | 决定发送方向 | 匹配顺序与接收通道 |
排查告警未送达的顺序
- 确认规则是否已触发并推送到接收端
- 确认路由匹配结果是否符合预期
- 确认接收通道本身可用，而不是被静默或抑制
告警的判定与送达分属两个系统：判定在规则引擎，送达在接收端，排障时先明确问题出在哪一段。
长期未清理的静默与过宽的抑制会造成监控盲区：这类配置需要定期巡检，而不是只在创建时检查一次。