告警治理需优化阈值、抑制风暴、精准路由：用持续周期判断替代瞬时阈值，按依赖链抑制多级告警，按角色路由并嵌入处置指令，定期清理无效规则。
告警阈值设置不合理导致高频抖动
很多运维人员直接套用监控工具默认阈值，比如 cpu_usage > 80% 就告警。但业务高峰期 CPU 短时冲到 85% 很常见，这类告警本质是噪音。
- 改用「持续 N 个周期」判断：Prometheus 中用
avg_over_time(cpu_usage[5m]) > 80%替代瞬时值 - 对有规律的指标（如每日备份任务触发的磁盘 IO 尖峰），在告警规则中加时间过滤：
hour() != 2 && avg_over_time(disk_io_wait[3m]) > 90% - 避免对低基数指标设绝对阈值：比如
http_requests_total 在凌晨本就该为 0，应改用变化率或环比判断
同一故障引发多级告警（告警风暴）
一个网络抖动可能同时触发：主机 ping 不通、服务端口不可达、HTTP 探针失败、下游依赖超时……最终收到 10+ 条告警，但根源只有一个。
- 按依赖链做告警抑制：Alertmanager 中配置
inhibit_rules，让host_down抑制所有基于该主机的service_unavailable和probe_failed - 合并同类项：把同一批节点上的
disk_full告警聚合成一条，用group_by: [instance, device]+group_wait: 30s - 关键路径优先：只对直接影响用户请求的组件（如 API 网关、数据库主库）开启 P1 告警，缓存、日志等旁路系统降级为 P3 或仅记录
告警接收人与处置能力不匹配
把所有告警都发到大群，结果谁都不处理；或者把数据库慢查询告警发给前端工程师，白白消耗响应时间。
- 按角色拆分路由：Alertmanager 的
route配置里，用标签如team: "db"或service: "payment-api"匹配不同接收方 - 加入处置提示：在告警描述中嵌入可执行线索，例如：
check: "SELECT * FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > '5min';" - 禁用无人认领的告警：定期清理超过 3 个月未被确认或关闭的规则，尤其是测试环境遗留的
test-metrics-high类规则
真正难的不是加告警，是敢删告警。每条还在触发的告警，背后都应该对应一次真实介入、一次根因分析、一次规则优化。否则它只是在消耗注意力，而不是保护系统。
