核心是优化告警策略而非降低监控灵敏度：通过均值替代瞬时判断、时间过滤、变化率阈值解决误报；用抑制规则、聚合分组、分级响应和角色路由提升处置效率；定期清理失效规则并实施阶梯式响应。
频繁告警不是监控太灵敏，而是阈值没跟上系统真实行为。核心要解决三类问题：瞬时抖动误报、多指标同源误扰、接收人与处置能力错配。
用持续周期替代瞬时判断
CPU 短时冲到 85% 在业务高峰很常见，但 cpu_usage > 80% 会立刻告警。这不是异常，是常态。
- Prometheus 中改用
avg_over_time(cpu_usage[5m]) > 80%，要求连续 5 分钟均值超标才触发 - 对有规律的指标（如凌晨 2 点的备份 IO 尖峰），加时间过滤：
hour() != 2 && avg_over_time(disk_io_wait[3m]) > 90% - 低基数指标（如凌晨 0 点的 HTTP 请求数）别设绝对阈值，改用变化率：
rate(http_requests_total[1h]) == 0
按依赖链抑制告警风暴
一个网络抖动可能同时触发主机不可达、端口失败、HTTP 探针失败、下游超时等 10+ 条告警，但根源只有一个。
- 在 Alertmanager 中配置
inhibit_rules：让host_down抑制所有基于该主机的service_unavailable和probe_failed - 同类告警聚合：对磁盘满告警，用
group_by: [instance, device]+group_wait: 30s合并成一条 - 关键路径优先：API 网关、数据库主库设 P1 告警；缓存、日志等旁路系统降为 P3 或仅记录
按角色路由并嵌入处置线索
把数据库慢查询发给前端工程师，等于把消防警报发给园丁——响应时间全耗在转手路上。
- Alertmanager 的
route里用标签匹配：match: {team: "db"}或match: {service: "payment-api"} - 告警描述中直接写可执行命令：
check: "SELECT * FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > '5min';" - 定期清理无人认领规则：禁用超过 3 个月未确认、未关闭的告警，特别是测试环境遗留的
test-metrics-high类规则
分场景设置阶梯式响应阈值
磁盘空间卡死 90% 只会让人疲于删日志，不如让告警自己“学会分级”。
- 85%：邮件提醒，触发自动巡检脚本检查
/var/log和/var/lib/docker - 92%：企业微信告警，附带
du -sh /var/log/* | sort -hr | head -3结果 - 95%：自动调用归档脚本，压缩旧日志、清理
journalctl --vacuum-size=200M，不删不碰核心文件
