告警定期巡检是什么
告警定期巡检是按月对规则清单做治理：看触发历史、是否可行动、有没有对应的处置说明，把没有预案的僵尸告警降级或删除，把过时阈值更新掉，所有变更走评审流程。它解决的是告警只增不减的问题——规则一旦加上就无人再管，噪声逐年累积，最终表现为值班人对所有通知都麻木。
基本信息
| 巡检周期 | 常规按月，事故后追加专项 |
|---|---|
| 取数方式 | 导出规则清单与近 90 天触发记录 |
| 评审结论 | 保留、降级、合并、删除、改造 |
| 关键检查点 | 是否可行动、是否有处置说明、阈值是否仍合理 |
| 权限要求 | 规则与告警配置的修改权限 |
巡检步骤
- 导出规则清单与近 90 天的触发记录
- 标记噪声源、长期零触发的僵尸规则、动作重复的规则组
- 逐条给出结论：保留、降级、合并、删除或改造
- 对保留下来的关键告警核对处置说明链接是否仍然有效
- 把决议留档，并在下一次巡检时核对执行情况
使用要点
- 巡检也要看「好告警是否正常触发」，长期零触发可能是阈值错了或链路断了
- 删除前核对规则与服务目标、故障场景的对应关系，避免误伤
- 每条规则问一次「触发时该做什么」，答不上来就是候选删除对象
- 阈值更新要注明依据，便于下次复盘时理解背景
- 把巡检结论与变更流程打通，避免评审通过后无人执行
触发历史取样
触发历史取样
# 过去 90 天 firing 评估次数排行，用于巡检取样
topk(50, sum by (alertname) (count_over_time(ALERTS{alertstate="firing"}[90d])))
# 逐条问三个问题：
# 1) 触发时该做什么？2) 有对应的处置说明吗？3) 阈值还需要调整吗？决议类型
| 决议 | 适用情形 | 注意 |
|---|---|---|
| 保留 | 可行动且有预案 | 核对说明链接的有效性 |
| 降级 | 有价值但不需即时响应 | 同步调整通知路由 |
| 合并 | 多条告警来自同一根因 | 确认新规则覆盖全部场景 |
| 删除 | 没有可执行的动作 | 先核对与故障场景的对应关系 |
| 改造 | 阈值或表达式已过时 | 注明依据并纳入评审 |
巡检结论要落到具体责任人与时间，否则「下个季度再看」会让整套规则长期停留在无人治理的状态。