【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

智能运维系列(九)| 基于交易树的根因告警定位方法

  • 2020-08-11
  • 本文字数:3102 字

    阅读完需:约 10 分钟

智能运维系列(九)| 基于交易树的根因告警定位方法

监控告警是故障发现的重要一环,异常发生时,运维人员常常可以从一些告警中找到蛛丝马迹,但是每天动辄上万笔的告警却让运维人员无从下手。就像战场上的子弹,99%都是做掩护,只有 1%的子弹能打中敌人!“到底哪些告警才是故障真正的根因?”相信很多运维同学都曾在深夜发出这样的灵魂拷问。如何找到一个有效的方法来帮助运维人员定位出真正的根因?本文就和读者分享一下微众银行技术团队的心路历程。

本文收录在专题《智能时代下的运维》系列


“告警定位”简简单单四个字,想要做好却不是一件容易的事情。每一条告警,都会包含相应的告警级别(根据程度分为 critical, major, minor, warning),告警类型(根据告警源分为网络告警,专线告警,主机告警,TDSQL 告警,WEMQ 告警等),告警对象(具体的异常点比如主机 A,数据库 B),告警发生时间等信息。传统的做法是将故障时间段内的低级别的告警过滤掉,只保留高级别的告警,然后按照专家经验对剩下的告警进行优先级排序,比如说网络告警的优先级最高,优先推出;母机、子机告警同时出现,母机告警优先推出;TDSQL 节点告警和 TDSQL 主机告警同时出现,优先推节点告警。类似这种规则还有很多很多,大多都是根据历史案例和运维人员的专家知识归纳总结出来的。这种做法存在几点问题:


  1. 规则覆盖的范围总是有限的,有时会出现误告,需要运维或开发人员对现有的规则进行修改或者添加新的判断分支,费时费力,并且随着规则库的不断扩大,维护起来也越发麻烦,新的规则和原有的规则冲突的情况也时有发生。

  2. 有时低级别的告警往往包含了更重要的信息,是更应该被推出来的根因,但是按照现在的逻辑是会被过滤掉的,从而导致信息丢失;如果放开限制,对全级别的告警进行分析,又会引入很多噪声,从而导致误判。

  3. 可解释性较差,根据规则推出的告警经常会让运维人员一头雾水,因为这种做法缺乏推理的过程,运维人员只看到最后的结果,却不清楚这个结果是怎么得到的,难以让大家信服。


好的告警定位的方法应该是一个由表及里、从大到小的过程。通过故障发生时的表象,一步步推导,过滤掉干扰项,缩小候选告警集合的范围,最后定位到关键的一条或者几条告警,再整理成方便运维人员阅读的根因话术输出。


对于微众银行而言,故障发生直接会导致一部分交易出现超时、中断等现象。因此,异常交易就成为了一个很好的故障分析切入点。而交易的超时和中断怎么判断,依赖于交易树的信息。下面,我简单介绍一下交易树的概念。一笔交易从开始到结束,会在 RMB(消息总线)上留下调用消息的日志,这里称之为“原始消息日志”;原始消息日志通过规则引擎预处理之后,得到多个消息对,每个消息对包含 request 和 response 两条 message,代表一次调用;结合 cmdb(配置管理数据库)的数据,处理消息对,依据调用的响应方,生成多个 tree node(一个响应方,一个节点);将离散的 tree node 依据 node 的上游以及下游转换成若干条 tree chain;将若干条 chain 依据相同父链路等规则合并成树,再做一些整理,如横向合并、纵向合并就得到最后的交易树。处理流程如图 1:



图 1  交易树处理流程图


不同业务场景(借款,还款,账户查询)下的交易,结构可能会差别很大,如图 2,图 3,但是处理的流程都是一样的。



图 2 场景 A 的交易树示例



图 3 场景 B 的交易树示例



图 4  一棵具体的交易树


如图 4 所示,交易树上的每一个节点对应行内的一个子系统,包含子系统 id、所在 dcn、所在 ip、处理耗时、提供服务以及关联到的 tdsql、wemq 等信息。


故障发生时,一般会有多笔交易受到影响,对单笔交易而言,根据相应的接口日志、节点耗时、是否发生中断等信息可以快速定位到异常子系统。比如节点耗时,可以采用同环比,即比较具有相同交易树结构的异常交易和正常交易的节点耗时,耗时增幅最大的子系统即认为是异常子系统;或者采用深度学习算法例如变分自编码器 VAE 来学习每种交易树结构中不同子系统的耗时分布,这部分本文不展开介绍,感兴趣的同学可以自己查阅相关资料。考虑到有可能是上游子系统出了问题进而影响到了下游子系统,我们就把每笔异常交易定位出的异常子系统和它的上游子系统结合起来进行分析,这样既大大缩小了根因告警的范围又尽可能的覆盖到故障出现的所有位置,可谓一举两得。


定位到故障的子系统后,接下来就只需要去找故障发生时间段内这些子系统所能关联到的各种类型的告警。比如说对于主机告警,用到的信息有子系统 id、所在 dcn、所在 ip,我们采取从精确范围到模糊范围逐步扩大范围的方式去关联,先去关联该子系统该 ip 的主机告警,没有的话就去关联该子系统该 dcn 的主机告警,还是没有的话再去关联该子系统所有能关联到的主机告警,当然随着范围的不断扩大,关联到的主机告警的置信度也是不断降低的;对于 TDSQL 或者 WEMQ 告警,直接去找该子系统所能关联到的 tdset 节点/wemq 集群上面是否存在相应的告警即可。


对于关联到的告警,我们需要对它进行打分,目前用到的打分参数是:告警等级(critical, major, minor, warning)、关联子系统类型(上游子系统,下游子系统)、关联到的交易数量等要素。通过复盘历史案例,可以得到不同参数的权重以及判定阈值。得分高于这个阈值的告警认为是引起本次故障的原因之一,加入根因告警集合;得分低于阈值的告警常常是频繁、周期性发生的,或者是提供的信息在得分较高的告警中已经包含,故可以过滤掉。目前由于异常告警的得分和正常告警的得分有比较明显的区分度,故可以直接手动确定阈值和不同参数的权重;后续随着故障案例的不断增加以及新的打分依据的出现,可以用机器学习的方式来确定阈值与参数权重,常见的算法有 LR(逻辑回归), GBDT(梯度提升迭代决策树)等。


根因告警集合中可能包含多种类型的多条告警,可读性是较差的,所以需要我们进一步进行聚类,把相同类型的告警(常见的分类是:TDSQL、WEMQ、应用主机、网络、内部程序、TGW 等)合并在一起,每类只保留一条汇总的、可读性较强的根因告警,同时每类告警的结果我们会赋予一个置信度,最后将这些结果按置信度排序输出,方便运维人员快速、准确的定位到故障。


一个典型的案例是某业务的当前平均时延指标突增,定位到的异常子系统上也出现了大量的外部接口报错日志,从表象上来看大概率是外部合作伙伴问题。但是通过搜索异常子系统所关联到的 tdset 节点,可以发现该节点上存在多条 critical 级别的告警,且影响了多笔交易,故认为异常更有可能是由 TDSQL 引起的。后经运维人员确认当时该节点确实存在大量的慢查询,导致业务的平均时延突增,外部接口报错只是表象,数据库慢查询才是故障的根因。由此可以看出,精准的告警定位可以帮助我们找到问题的真相,让我们“拨开云雾见月明”。


当然现有做法也有一些不足:对于网络类型的告警,是无法通过交易树关联到的,改进的方法是对于每个历史案例,提取相应的告警特征,训练一个分类器(LR,SVM,GBDT 等)来帮助我们判断故障类型,这样当新的故障发生时,只需要把分类器输出的类别下相应的告警聚类即可。


除了故障根因定位以外,故障预警也是一个可以展开的方向。上文我们有提到过有一些级别较低的告警,实际上在故障大规模发生之前,往往系统会出现性能降低、可用率下降等情况,导致少量的交易流水出现问题,虽然还够不上一个异常事件,可是一旦没有及时处理,问题逐渐累积,就会引发一次故障。如果我们能够用这些异常交易来关联低级别的告警提前进行分析,也许就能够防患于未然,做到故障提前发现、提前处理。


如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法,请参阅该系列其他文章。


前文回顾


专题 | 智能时代下的运维


作者简介


微众银行智能运维系统核心开发者 薛文满


公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2020-08-11 11:332565
用户头像
陈思 InfoQ编辑

发布了 576 篇内容, 共 261.3 次阅读, 收获喜欢 1293 次。

关注

评论

发布
暂无评论
发现更多内容

用 GitBook 创建一本书

耳东@Erdong

git markdown gitbook

发布一本用 GitBook 编辑的书

耳东@Erdong

git gitbook

Vagrant 创建多台主机

FeiLong

vagrant 虚拟机

运行 client-go 测试用例.md

FeiLong

Kubernetes

Apache BeanUtils和Spring BeanUtils剖析

Bruce Duan

BeanUtils 浅拷贝和深拷贝

计算机网络基础(六)---网络层-网络地址转换NAT技术

书旅

laravel 计算机网络 网络协议 计算机基础 NAT

罪羊树——暴力也是种优雅

烫烫烫个喵啊

算法 二叉树 替罪羊 平衡二叉树

自从用完Gradle后,有点嫌弃Maven了!速度贼快!

xcbeyond

maven Gradle

ARTS 05 - 使用 Ecto.Migration 来做数据库迁移

jerry.mei

学习 算法 ARTS 打卡计划 函数式编程 Elixir

技术革新产业变革新动能

CECBC

week7 总结 性能测试

a晖

redis系列之——事物及乐观锁

诸葛小猿

redis 乐观锁 事物 原子性 隔离性

架构师训练营第七周作业--web压测工具

CATTY

JDK1.8新特性(二):为什么要关注JDK1.8

xcbeyond

新特性 JDK1.8 JDK1.8新特性

JDK1.8新特性(五):Stream,集合操作利器,让你好用到飞起来

xcbeyond

stream 集合 新特性 JDK1.8 JDK1.8新特性

应届生求职面试真的有那么难吗

xcbeyond

面试 应届生

MyBatis几种好用的写法

Bruce Duan

MyBatis标签

我关闭了微信朋友圈广告!

诸葛小猿

广告 微信朋友圈 关闭

Windows Sandbox应用

Dare Devor

容器 Sandbox 虚拟化

如何保证消息不丢失?处理重复消息?消息有序性?消息堆积处理?

Bruce Duan

消息队列 保证消息不丢失 处理重复消息 消息有序性 消息堆积处理

架构师训练营作业 (第七周)

默默

MySQL 大表优化方案

Bruce Duan

MySQL优化

Docker容器中一定要避免的10件事

xcbeyond

Docker 避坑

架构师训练营 -- 第七周学习总结

花花大脸猫

记一次西安thoughtworks的面试经历

xcbeyond

面试 thoughtworks

IDEA 插件: EasyCode 一键生成所需代码

Bruce Duan

idea插件 easycode 生成代码

分布式锁用 Redis 还是 Zookeeper?

xcbeyond

redis zookeeper 分布式锁

JDK1.8新特性(三):Lambda表达式,让你爱不释手

xcbeyond

Lambda 新特性 JDK1.8 JDK1.8新特性

JDK1.8新特性(四):函数式接口

xcbeyond

新特性 函数式编程 JDK1.8 JDK1.8新特性

关于性能优化的总结

罗亮

Prometheus 删除指定 Metric

耳东@Erdong

Prometheus metrics

智能运维系列(九)| 基于交易树的根因告警定位方法_AI&大模型_薛文满_InfoQ精选文章