监控告警那些没人愿意说的实在事

上周三凌晨两点十七分，我手机连震八下。摸过来的时候脑壳都是懵的。是个告警——说订单接口的响应时长超了200ms。爬起来登VPN，翻日志，查链路，折腾了四十分钟，最后发现是公司楼下的运营商光纤被挖断了半根，我们自己的系统半毛钱问题没有。那时候就想，这破告警，除了把人整失眠，到底有啥用？

你手机里的告警，有一半是凑数的

我之前帮一个做电商的团队捋告警规则，数了下他们接在企业微信上的告警源，光接口性能类的就有127条规则，其中89条的触发阈值，是当初搭监控的时候照着网上的教程抄的，根本没跟着业务量调过。大促的时候流量翻三倍，阈值还是原来的，那告警能不炸吗？平时半夜没人的时候，接口延迟个100ms也要报，根本不管是不是刚好有个定时任务在跑。

那个团队的运维小哥跟我吐槽，说他现在手机只要一震，心脏就抽一下，条件反射式掏手机，结果十次有九次是没用的。说实话，换你你也烦。天天收一堆没有实际影响的告警，人会慢慢形成“告警免疫”——下次真出问题的时候，弹窗弹出来，手一划就划掉了，根本不会点开看。

我见过最离谱的告警规则，是给企业内部OA系统设了“登录失败次数超过3次就发告警”。有个同事输错密码把自己锁了，半小时给告警群发了47条消息，全是无关紧要的内容。这种告警发多了，谁会当回事？

最坑的告警，从来不是响得太早

很多团队被告警炸得烦了，就开始乱调阈值。原来CPU到80%就报，现在调到95%才报；原来错误率超0.5%就报，现在调到2%才报。美其名曰“减少告警噪音”，结果呢？等真的CPU跑满，服务已经挂了三秒，用户已经投诉到客服那边了。

还有更离谱的——监控系统自己挂了。本来应该报“监控系统离线”的告警，结果因为监控系统自己挂了，这个告警根本发不出来。真的，这种事我遇过不止一次。等我们发现数据断流的时候，已经有两个小时没看到系统状态了，这时候之前所有的“减少噪音”的操作，全成了自欺欺人。

之前有个做在线教育的客户，去年秋季班开课的时候，直播系统突然卡了。等他们收到告警的时候，已经有三千多个家长在群里骂了。翻回去查监控日志才发现，他们的告警规则设的是“错误率超过1%持续10分钟才触发”，那天错误率从0.1%涨到1.2%的时候，刚好卡着10分钟的点发了告警，但那时候流量已经堆到把服务压垮了。说白了，他们的告警是“事后报丧”，不是“提前预警”。

把告警做有用，根本不需要花大价钱

很多人觉得要把监控做好，就得买很贵的商业系统，就得搭复杂的链路追踪，其实根本不是。先从最基础的事做起就行。

把现有的告警规则过一遍，把那些三个月都没触发过的规则先关了——谁没事会给一个从来不出问题的服务器设告警？然后把告警分级，能半夜把人叫起来的告警，必须是真的会影响用户掏钱的问题，比如支付接口报错、核心链路断了，这种才叫最高优先级，直接打运维电话，发微信，哪怕你把人从床上拽起来都应该。那种磁盘使用率涨了2%、非核心服务的CPU波动，这种低优先级的，攒着第二天上班再看就行，别天天半夜发。

还有，告警发过来的时候，别只甩一句“接口超时”，要把信息给全：哪个接口、从哪个节点到哪个节点出的问题、最近一次的变更记录是什么、关联的日志链接在哪里，别让接告警的人爬起来还要自己花十分钟找问题在哪——那谁愿意接啊？

上次帮那个电商团队捋完规则，原来的127条告警砍到剩21条，大家的告警接收量直接降了80%。原来大家看到告警就烦，现在只要弹出来，就知道是真的要处理的事，再也不会出现告警被划掉、真出问题没人看的情况。大促的时候，他们提前把核心链路的告警阈值调得比平时严一点，提前十分钟就发现了CDN节点的缓存命中率掉了，赶紧切了备用节点，整个大促期间没出一次影响用户的故障。

真正有价值的告警，从来不是追求“零延迟发现问题”，而是在问题还没影响用户之前，把该找的人找过来。你想想，你家的烟雾报警器，天天因为炒辣椒就响，真的着火的时候，你根本不会当回事。对吧？