首页 / it.itcdj.com / 正文

AIOps告警降噪与根因定位 把值班从告警堆里捞出来

前阵子陪做运维的朋友在值班区蹲了半宿。

告警提示音就没停过。

手机震动弹消息,桌面监控平台的弹窗跳个没完,一晚上数下来,光收到的告警就快两千条。人盯着屏幕盯到眼睛发花,连去接杯水都不敢走远,生怕漏了真故障。

裸告警的代价没人扛得住

裸告警的代价没人扛得住

很多团队刚搭监控体系的时候,总恨不得把所有可观测的指标都拉出来设个告警阈值。CPU涨5%要弹,磁盘IO飘一下要弹,接口超时100ms要弹,根本不管这些指标背后的依赖关系。

就说那天凌晨三点弹的一波告警,数了下一共127条。真正影响用户的只有1条——核心支付接口因为数据库连接池打满超时。剩下126条全是连锁反应:订单系统调支付失败弹告警,优惠券系统调订单失败弹告警,用户中心拿不到订单状态弹告警,甚至连后台日志采集agent因为带宽被挤断了,都跟着弹了条告警。

值班的人那天晚上光点“已读”就点了快半小时。

[AIOps告警关联聚合前后告警数量对比图]

很多人第一反应是把告警阈值调松点。没用。你把CPU告警阈值从70%调到90%,真到CPU跑满的时候,业务已经卡了十分钟,用户投诉都到客服台了。

说白了,拍脑袋调阈值本质是掩耳盗铃。你不知道哪个阈值对应真的业务损失,哪个只是系统的正常波动。调太严,告警把人淹了;调太松,漏了真故障要担责任。这种两难,全是没做分层降噪的裸告警闹出来的。

降噪不是删告警

降噪不是删告警
降噪不是删告警

我见过太多团队对AIOps告警降噪的误解。觉得降噪就是把重复的告警合并、把不重要的告警删掉,凑个“告警量下降70%”的漂亮汇报数据就行。

之前碰到过一个团队,花三个月写规则做降噪,把同IP、同接口的告警全合并。结果上线第一个月就漏了三次真故障。他们的规则把“磁盘满导致日志写失败”和“日志采集延迟”这两个有因果关联的告警合并成了一条通用告警,值班的人一看是老问题,直接点了已处理,结果磁盘真的满到连系统进程都写不了临时文件,整个节点挂了半小时。

真正的降噪从来不是减少告警的数量,而是把和用户体验、业务损失强相关的信号从噪音里摘出来。

现在很多人讲降噪,张口就是告警收敛、关联分析,听着玄,其实核心逻辑特别简单:先把所有告警的依赖关系理清楚。哪个是因,哪个是果,哪个是上游故障传导下来的次生告警。比如前面说的数据库连接池打满,这是根因节点,后面所有调用它的系统报的超时、失败,全是次生告警,这些完全可以聚合到根因节点下面,不用单独弹给值班人。

[微服务架构下AIOps根因定位依赖关系拓扑图]

当然,也不能走极端。别想着把所有果告警全屏蔽了就万事大吉。麻烦在于,你没法100%确定每个果告警背后的因是什么。同样是支付接口超时,可能是数据库连接池打满,也可能是第三方支付通道本身抽风。如果你把所有支付超时的告警都归到数据库的名下,碰到第三方故障的时候,你查半天数据库,最后才发现是外面的问题,耽误的时间全是实打实的业务损失。

根因定位不是算命

根因定位不是算命
根因定位不是算命

市面上太多AIOps产品吹得神乎其神。说什么“一键定位根因,秒级排查故障”。上次碰到个厂商销售,跟客户拍胸脯说他们的系统能做到告警出来3秒定位根因,结果现场测试,拿了个之前出现过的“缓存集群节点宕机导致数据库压力飙升”的故障,系统转了两分钟,最后跳出来的根因是“应用服务器内存使用率过高”,完全驴唇不对马嘴。

这事没那么玄。

根因定位的核心,从来不是靠大模型瞎猜,也不是靠什么玄学算法算概率。本质上就是把过去半年的故障记录、调用链数据、指标波动时间点全部对齐——哪个指标在故障发生前10秒出现了异常,哪个服务的调用量在故障节点出现了断崖式下跌,哪个依赖组件的错误率最先抬头。

所有的根因定位,本质上都是把“最先出现异常的那个节点”从一堆同时跳出来的告警里找出来,而不是凭空算出故障原因。

很多团队上AIOps的时候,上来就花大价钱买算力堆模型,结果连自己系统的调用关系图都没理清楚。哪个服务调哪个接口,哪个组件依赖哪个数据库,全是一笔糊涂账。你想啊,连基本的依赖关系都错了,系统给你指的根因位置,能准吗?

之前有个团队跟我算过账,为了把AIOps用顺,光清洗历史监控数据就花了四个月。之前的监控数据散在三个不同的平台,指标口径不统一,告警标签乱贴,有的告警只写了“订单系统异常”,连是哪个机房、哪个实例的都没标。最后清洗完能用的数据,还不到原来总量的30%。

很多人觉得这钱花得亏。其实不然。这些脏数据不洗干净,后面的所有降噪、根因分析全是空中楼阁。

后来那个团队调整完AIOps的逻辑,值班区的告警量从一晚上两千多条降到了四十多条。其中真正需要值班人动手处理的,也就三四条。那天陪我蹲点的小伙子说,之前他一晚上要灌三罐功能饮料,现在能趴在桌上眯两个小时。碰到告警弹出来,系统直接把关联的调用链、指标波动图附在旁边,不用自己切好几个平台挨个查,从告警出来到定位完根因,原来要二十分钟,现在三分钟就够了。

别信什么一劳永逸的解决方案。

架构改了,新服务上了,新的依赖加进来,原来的规则就得跟着调。但至少,不用再在两千条告警里捞那一条真故障了。