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

AIOps告警优先级分层判定逻辑流程图
举个最实在的例子:同样是告警,触发了核心交易链路超时的告警,优先级肯定比某台非核心测试服务器的磁盘使用率高。但很多旧的监控系统,给这两类告警标的是一样的等级,值班的人一晚上要处理几十条测试服务器的告警,等真正的核心告警弹出来的时候,已经被刷到屏幕最下面看不见了,对吧?
所谓的降噪,本质上就是帮人把这些无效的、重复的、低影响的告警筛掉,把最需要马上处理的内容推到最前面。
很多团队做完第一版降噪之后,就顺理成章地开始做根因定位。逻辑很简单:告警都关联成事件了,顺着链路找最早触发的那条告警,不就是根因了?
哪有这么容易。
根因定位最大的问题,是你拿到的链路,很多时候是断的。比如你只监控了应用层的接口耗时,没监控底层交换机的端口丢包,就算算法把所有关联告警都串得再顺,最后也只能定位到“接口慢”,根本找不着是哪根网线松了。
说白了,这事没那么玄。你监控埋点都不全,再好的模型也是巧妇难为无米之炊。

分布式链路追踪根因节点关联拓扑图
监控埋点的覆盖密度,直接决定了AIOps根因定位的准确率上限。
之前有个做了十年运维的老大哥跟我吐槽,他们刚上AIOps平台的时候,把所有历史告警都导进去训练,结果模型把“每次大促前服务器计划内重启”这种常规运维操作,当成了核心故障的根因特征。后来每次大促前,系统都会自动弹根因报告,说“预计未来两小时全链路将出现告警,原因是服务器计划内重启”。值班的人看着报告,哭笑不得。
告警堆成山的时候,没人在乎算法多先进
很多人对告警降噪的第一印象,就是把相同规则触发的告警合并到一起,省得翻来覆去看一样的内容。 麻烦在于,现在的系统架构早就不是单机房的单体应用了。一条用户侧的接口超时,可能牵连着十几层的依赖链路:主机的CPU打满、数据库的慢查询、消息队列的堆积、网关的限流规则、甚至是某个边缘节点的网络抖动。这些告警的触发规则完全不一样,只是刚好在同一个时间窗口弹了出来。 你硬把这些告警捏成一个事件,看起来数量是少了。 等真要查问题的时候,根本分不清哪个是因哪个是果。 之前碰到个团队,刚上第一版降噪系统的时候,把一天五千多条的告警量压到了三百条,全团队都觉得终于能松口气了。结果真碰到核心交易链路故障的时候,三百条告警里连数据库连接池打满的那条都被系统判定为重复内容静默了。值班的人盯着屏幕上的接口超时告警,愣了十分钟才反应过来事不对。 真到出大事的时候。 没人敢赌算法给的优先级是不是对的。降噪不是做减法,是给告警排优先级
现在很多厂商的宣传材料里,总把高降噪率当成核心卖点。好像能把告警量压得越低,系统就越先进。 说实话,这个数字根本没那么有参考价值。 那些所谓的95%以上的降噪率,都是拿全量历史告警跑出来的平均数据。真放到生产环境里,你敢把占比最高的那类告警全压了?比如磁盘使用率到80%的告警,可能占了所有告警的40%,看起来都是无关痛痒的预警。但上次有个节点磁盘满了把日志分区写爆,就是因为这类告警被系统判定为低价值,直接进了静默列表。 真正的AIOps告警降噪,从来不是追求告警数量的绝对值下降,而是把值班人员的注意力,往真正会影响业务的事件上引。
