告警太多，根本看不过来
上周刚上线了一个新服务，本以为万事大吉，结果半夜手机开始“叮叮叮”响个不停。打开一看，又是服务器CPU飙高、磁盘快满了、接口响应超时……一条接一条，像短信轰炸一样。第二天上班整个人都是懵的，不是告警太多没注意，就是关键问题被淹没了。
先别急着调阈值，搞清楚原因才是正事
很多人一看到告警频繁，第一反应是“把阈值调松一点”。比如原来CPU超过80%就报警，干脆改成90%甚至95%。这就像把闹钟声音关小，以为能睡得更香，其实只是错过了起床时间。
真正该做的是翻日志、查监控图表，看看是不是有规律可循。比如：
- 是不是每天下午3点定时任务跑批处理，资源占用猛增？
- 是不是某个API被恶意刷了请求？
- 是不是日志写得太频繁，把磁盘撑爆了？
合并同类项，别让一个故障刷屏十条
同一个问题引发多个组件告警，这种情况太常见了。比如数据库慢了，导致后端服务超时，接着前端接口报错，缓存堆积，最后全部炸锅。这时候你收到的不是一条告警，而是一连串“尸体堆成山”。
解决方案是设置告警聚合规则。以Prometheus + Alertmanager为例，可以按故障根源分组：
route:
group_by: ['alertname', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 1h
receiver: 'webhook-notifier'这样同一类问题会合并成一条通知，避免凌晨三点被连环call醒。
加个“冷静期”，别一抖就报警
很多监控工具支持设置“持续时间”条件。比如CPU连续5分钟超过85%才触发告警，而不是只要超过立刻报警。这对应对瞬时波动特别有用。
在Grafana里配置时，可以这样写：
avg(last_5m): avg(cpu_usage{job="app"}) > 85这样哪怕短时间冲到90%，只要没持续多久，就不会打扰你睡觉。
给告警分级，别所有消息都标红
不是所有告警都值得马上处理。可以把告警分成几档：
- 紧急级：服务挂了、数据库连不上——必须立刻处理，电话call醒都合理；
- 警告级：磁盘使用率85%、响应变慢——白天看到就得跟进，但不用半夜爬起来；
- 提示级：日志中有少量错误、连接池接近上限——记录下来，排期优化。
然后根据不同级别走不同通知渠道。紧急走电话+短信，警告发企业微信，提示只存进日志系统就行。
定期清理“僵尸告警”
项目迭代多了，有些服务下线了，但监控规则还留着。于是你总收到“xxx-service无法连接”的告警，点开才发现这服务半年前就退役了。
建议每季度做一次告警规则审计，删掉无效的、过时的规则。顺便看看有没有重复定义的，比如同一个指标被两个不同的表达式监控，结果报两次。
用标签管理，别让告警乱成一锅粥
给每个告警加上清晰的标签，比如 service、team、severity、environment。这样不仅能快速定位，还能实现自动路由。
比如加上 team=payment 的标签，Alertmanager就能自动转发给支付组的值班人，而不是全员轰炸。
少一点噪音，才能抓住真正的异常
监控的目的是发现问题，不是制造焦虑。告警频繁不可怕，可怕的是习惯了忽略它们。把规则理清楚，让每一次提醒都有价值，你才会愿意认真对待它。
下次再被刷屏，先别动手调阈值，坐下来喝杯茶，问问自己：这些告警真的都有意义吗？