监控告警从噪音到价值的实操手记

上个月周三凌晨两点，我手机震得跟要炸了似的。

摸起来一看，企业微信告警刷了三百多条，全是同一个接口的502。

爬起来登VPN查了半小时，才发现是测试组昨天上线的时候忘了把压测流量的规则从生产环境摘了。

合着我熬到三点，就为了给别人的失误擦屁股？

这种事，干这行的谁没遇过？

被噪音淹掉的真告警

很多团队的监控告警，现在就是个纯粹的噪音制造机。

CPU使用率超过80%就弹消息，磁盘用到70%就发通知，甚至连运维手动重启个nginx服务，都要给所有相关的人发一条“服务已重启”的提醒。

没人真的去算，这个阈值对自己的业务来说到底意味着什么。

之前有个做垂直电商的朋友，他们大促期间交易网关的CPU常年跑在85%以上，告警一天能弹两百多条，最后整个运维组干脆把告警群设成了永久免打扰。

结果真出了数据库主从延迟10秒的告警，直接被埋在几百条消息堆里，过了俩小时才有人注意到，当天的订单直接掉了三百多万。

真的，太亏了。

很多人觉得告警越多越安全，恨不得把服务器上每一个进程的内存占用、每一块网卡的流量都监控起来，配个告警规则。最后导致的结果就是所有人都对告警消息产生了免疫力，手指看到红色的未读提示，下意识就划掉，根本不会仔细看内容。

你想啊，每天上班打开电脑，先刷两百条告警消息，换谁谁不烦？

别拿阈值当万能药

我见过太多团队配告警，流程简单到离谱——打开监控平台，拖个滑块把阈值设成行业通用的80%、90%，保存，完事。

根本不想这个数字放在自己的业务场景里，到底合不合理。

比如刚才说的交易网关CPU阈值，放在普通的内部OA系统，80%确实该警惕，但放在大促扛流量的核心节点，85%可能都是健康的水位。反过来，要是用户的下单接口，哪怕错误率只到0.1%，都该拉响最高级别的警报——毕竟每一笔失败的订单，都是真金白银的损失，还有用户的信任。

还有那种周期性的固定场景，比如每天凌晨三点定时跑批，数据库IO会飙到100%，这种事每周都按点发生，你还给它设IO阈值告警，不是纯纯浪费大家的精力？

说白了，大部分团队的告警配置，都是从别的公司抄来的，没人真的对着自己的业务量、流量峰值、历史故障数据算过数。

之前我们团队就干过这事，照着网上的教程把磁盘告警阈值设成80%，结果有个存日志的分区，因为历史数据一直涨，半个月就触发了一次告警，每次大家爬起来清完日志，过俩礼拜又满了，来回折腾了三次才反应过来——哦，我们根本没给这个日志分区设自动清理的规则。

把告警从通知变成动作

改了几轮告警规则之后，我们才慢慢摸出点门道。

首先是告警分级，这个真的能解决80%的问题。

P0级的告警，直接绑定电话呼叫，打给当天的值班负责人，15分钟没响应就自动升级打给技术总监。这种级别的告警，我们团队一个月可能都出不了两次，但只要出了，都是真的能搞出大问题的事——比如核心接口错误率飙升、数据库主从断开、用户登录全量失败。

P1级的告警，发消息@对应业务的开发负责人，要求半小时内认领处理，比如单个服务的实例异常、非核心接口的小范围报错。

剩下的什么磁盘快满了、定时任务跑慢了、证书还有30天到期这种事，全归到P2，攒够了每天下午的运维例会统一处理就行，绝对不许大半夜发消息打扰人。

然后是告警聚合，同一个问题触发的多条关联告警，直接合并成一条消息，别连着弹十几次刷大家的屏。比如之前机房交换机抖动，导致整个机柜的服务器全报网络不通，原来的规则能发两百多条告警，现在直接聚合成一条“XX机柜网络异常”，点进去就能看到所有受影响的实例，省了好多事。

最有用的其实是预案联动。很多人配告警，就只想着发消息通知人，从来不想能不能让系统自己先把问题处理了。比如之前CDN节点出故障，告警触发之后自动把流量切到备用节点，等我们在告警群里看到消息的时候，流量已经切完了，用户根本没感知。还有之前数据库连接数打满，告警触发之后自动把低优先级的查询连接杀掉，根本不用人爬起来登数据库敲命令。

哦对，别为了降噪把真问题给盖过去。我们之前试过压测期间临时屏蔽告警，结果有一次压测脚本不小心打到生产环境，因为屏蔽规则没设到期时间，直接把生产的服务打挂了都没告警。所以现在所有的临时屏蔽规则，最长有效期不能超过24小时，而且必须两个人审批才能生效，绝对不许搞永久屏蔽的骚操作。

说真的，改完这些规则之后，我们值班的人现在手机晚上都敢开声音了。搁一年前，谁敢啊？

上周跟个做了十年SRE的老大哥喝酒，他说现在很多公司花大价钱买最贵的监控平台，配了几百条告警规则，最后用下来还不如我们手动改的那几十条实用。

说白了，监控告警从来不是给老板看的漂亮报表，是给一线干活的人递的安全网。

你要是把这张网全堵上噪音的破洞，等真的出事的时候，没人能接得住你。