最近公司数据库的监控系统总是“叮叮咚咚”响个不停，凌晨三点手机还在震动，点开一看又是慢查询告警。这种情况不少人都遇到过——监控是设了，可告警太频繁，反而让人麻木，真出了问题反倒容易忽略。其实，告警频繁不是监控太灵敏，而是配置没跟上实际业务节奏。
先搞清楚：告警到底在说什么
别一看到红色就改参数。得先翻翻日志，看看这些告警是不是集中在某个时间段，比如每天晚上的数据同步期间 CPU 飙高，这种周期性波动其实是正常的。如果每次告警都是同一个 SQL 执行超时，那可能就是这条语句本身写得有问题，而不是系统出故障。
比如有次我们发现 Redis 内存使用率告警频发，查了一圈才发现是某个开发临时加了个缓存 key，没设过期时间，一直往里塞数据。问题根源不在监控，而在使用方式。
调整阈值，别让“小感冒”当“重病”报
很多团队用的是默认阈值，比如 MySQL 连接数超过 150 就报警。但如果你的业务高峰期本来就有 180 个连接，这告警天天响也没意义。不如根据历史数据画个趋势图，把阈值设在真实异常点之上，留出合理缓冲空间。
像 CPU 使用率这种指标，可以结合负载一起看。单纯看 CPU 90% 不一定有问题，但如果同时伴随 QPS 下降和响应变慢，那才值得介入。
合并同类项，减少噪音
一个数据库实例同时报“磁盘 IO 高”“响应延迟”“慢查询增多”，其实可能是同一个原因导致的。这时候可以把相关规则做聚合，比如设置复合条件触发告警：
只有当“慢查询数量 > 10 条/分钟”且“平均响应时间 > 2s”时才通知，避免单条异常刷屏。
利用沉默期和恢复机制
很多监控工具支持“告警沉默期”。比如某类告警触发后，30 分钟内不再重复推送，防止半夜被同一问题吵醒十几次。等处理完再收一条恢复通知，心里也踏实。
以 Prometheus + Alertmanager 为例，可以这样配置：
group_wait: 30s
group_interval: 5m
repeat_interval: 30m意思是：首次告警等 30 秒再发，防止抖动；同一组告警每 5 分钟归并一次；重复提醒至少间隔 30 分钟。
给告警分级，别所有事都打电话
不是每个告警都需要立刻处理。可以把告警分成三级：
一级是数据库宕机、主从断开这类必须马上处理的；
二级是性能下降、连接数接近上限，白天看到就得跟进；
三级是某些非核心表索引缺失，周会提一下就行。
不同级别走不同通知渠道，一级发电话+短信，三级只推企业微信消息。
定期清理失效规则
系统上线两年，当初设的 20 多条告警规则，现在还有多少在用？有些表已经下线了，对应的监控却还挂着，成了“幽灵告警”。建议每季度 review 一次规则库，关掉那些长期不触发或已被替代的规则。
就像家里衣柜，放着太多旧衣服，真正要出门的时候反而找不到合适的。监控规则也得断舍离。