首页 / 资讯 / 蹲过运维大夜才懂的AIOps告警降噪与根因定位

蹲过运维大夜才懂的AIOps告警降噪与根因定位

凌晨三点。 手机震得搁在铁皮桌上哐哐响。 两百多条告警堆在屏幕上,翻都翻不完。
运维值班岗凌晨告警弹窗堆叠实拍图
这是大多数一线运维都经历过的场景。值班手机的震动频率超过闹钟的时候,没人会关心你用的是Transformer还是传统统计算法。大家只想赶紧把告警清完,看看是不是真出了影响业务的故障,别耽误了补觉的时间。

告警堆成山的时候,没人在乎算法多先进

很多人对告警降噪的第一印象,就是把相同规则触发的告警合并到一起,省得翻来覆去看一样的内容。 麻烦在于,现在的系统架构早就不是单机房的单体应用了。一条用户侧的接口超时,可能牵连着十几层的依赖链路:主机的CPU打满、数据库的慢查询、消息队列的堆积、网关的限流规则、甚至是某个边缘节点的网络抖动。这些告警的触发规则完全不一样,只是刚好在同一个时间窗口弹了出来。 你硬把这些告警捏成一个事件,看起来数量是少了。 等真要查问题的时候,根本分不清哪个是因哪个是果。 之前碰到个团队,刚上第一版降噪系统的时候,把一天五千多条的告警量压到了三百条,全团队都觉得终于能松口气了。结果真碰到核心交易链路故障的时候,三百条告警里连数据库连接池打满的那条都被系统判定为重复内容静默了。值班的人盯着屏幕上的接口超时告警,愣了十分钟才反应过来事不对。 真到出大事的时候。 没人敢赌算法给的优先级是不是对的。

降噪不是做减法,是给告警排优先级

现在很多厂商的宣传材料里,总把高降噪率当成核心卖点。好像能把告警量压得越低,系统就越先进。 说实话,这个数字根本没那么有参考价值。 那些所谓的95%以上的降噪率,都是拿全量历史告警跑出来的平均数据。真放到生产环境里,你敢把占比最高的那类告警全压了?比如磁盘使用率到80%的告警,可能占了所有告警的40%,看起来都是无关痛痒的预警。但上次有个节点磁盘满了把日志分区写爆,就是因为这类告警被系统判定为低价值,直接进了静默列表。 真正的AIOps告警降噪,从来不是追求告警数量的绝对值下降,而是把值班人员的注意力,往真正会影响业务的事件上引。
AIOps告警优先级分层判定逻辑流程图
AIOps告警优先级分层判定逻辑流程图
举个最实在的例子:同样是告警,触发了核心交易链路超时的告警,优先级肯定比某台非核心测试服务器的磁盘使用率高。但很多旧的监控系统,给这两类告警标的是一样的等级,值班的人一晚上要处理几十条测试服务器的告警,等真正的核心告警弹出来的时候,已经被刷到屏幕最下面看不见了,对吧? 所谓的降噪,本质上就是帮人把这些无效的、重复的、低影响的告警筛掉,把最需要马上处理的内容推到最前面。 很多团队做完第一版降噪之后,就顺理成章地开始做根因定位。逻辑很简单:告警都关联成事件了,顺着链路找最早触发的那条告警,不就是根因了? 哪有这么容易。 根因定位最大的问题,是你拿到的链路,很多时候是断的。比如你只监控了应用层的接口耗时,没监控底层交换机的端口丢包,就算算法把所有关联告警都串得再顺,最后也只能定位到“接口慢”,根本找不着是哪根网线松了。 说白了,这事没那么玄。你监控埋点都不全,再好的模型也是巧妇难为无米之炊。
分布式链路追踪根因节点关联拓扑图
分布式链路追踪根因节点关联拓扑图
监控埋点的覆盖密度,直接决定了AIOps根因定位的准确率上限。 之前有个做了十年运维的老大哥跟我吐槽,他们刚上AIOps平台的时候,把所有历史告警都导进去训练,结果模型把“每次大促前服务器计划内重启”这种常规运维操作,当成了核心故障的根因特征。后来每次大促前,系统都会自动弹根因报告,说“预计未来两小时全链路将出现告警,原因是服务器计划内重启”。值班的人看着报告,哭笑不得。

别等故障炸了才想起补监控

很多团队在选型AIOps平台的时候,总想着靠算法解决所有遗留问题。比如监控埋点不全、告警规则混乱、历史数据质量差——这些之前攒了好几年的技术债,好像只要上一套智能平台,就能自动消化干净。 花了大几十万买的系统,跑了半年,根因定位的准确率还不到30%。 为啥? 因为你平时的监控数据就只覆盖了30%的系统组件,剩下的70%连基础指标都没采,算法再聪明,也不能凭空知道哪台设备出了问题。 上次在南京的技术圈聚会,碰到个做平台研发的工程师,他说他们团队现在做AIOps,第一步根本不是搭模型,是花了整整三个月,把所有系统的监控埋点过了一遍,删了两百多条重复的告警规则,补了三十多个之前漏采的核心组件指标。哦对,他当时还说,删规则的时候,翻到三年前的一条告警,是监控某台已经下线的测试机的磁盘使用率,系统每个小时都要弹一次,值班的人已经习惯性把这条告警的通知关了,根本没人记得还有这么个规则。等这些基础工作做完,模型跑出来的根因定位准确率,比一开始直接把全量数据丢进去训练的结果高了两倍还多。 这事没捷径。 很多技术分享里,一讲AIOps就拿那种理想场景的案例,说算法几秒就能定位根因,把故障恢复时间从两小时压到五分钟。真在一线待过的人都知道,这背后要补多少监控埋点,要跟多少个业务团队对齐告警规则,要清理多少条无意义的历史脏数据。这些累活,根本不是靠一个算法模型就能搞定的。 上次值班到后半夜,泡了第三杯速溶咖啡的时候,看着降噪后留在屏幕上的十几条核心告警,突然觉得这事其实很简单。工具从来都是帮人省力气的,不是替人扛责任的。你要是指望买个系统就能让值班的人睡整觉,那最后大概率还是会被凌晨的告警炸醒。