【QCon】精华内容上线85%,全面覆盖“人工智能+”的典型案例!>>> 了解详情
写点什么

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

  • 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:332550
用户头像
陈思 InfoQ编辑

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

关注

评论

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

走进Redis,让你重新认识redis。绝不是表面

派大星

签约计划第三季

使用 Solidity 和 Node.js 构建简单的区块链预言机

devpoint

区块链 Node 预言机 7月月更

一文详解:SRv6 Policy模型、算路及引流

穿过生命散发芬芳

7月月更 SRv6

HarmonyOS分布式协同演奏技术实现路线(Java)

程序员啊叶

Java 编程 程序员 架构 java面试

SMI 与 Gateway API 的 GAMMA 倡议意味着什么?

张晓辉

Kubernetes 服务网格 SMI

首发!阿里技术大牛最新耗时半个月整理出最全MySQL性能优化和高可用架构技术宝典,直接封神!

了不起的程序猿

MySQL 数据库 程序员 性能优化 JAV A

深入浅出边缘云 | 3. 资源配置

俞凡

架构 边缘计算 网络 深入浅出边缘云

设备树的引入与体验

贾献华

7月月更

真香!180页100+题15W+字解析的《Java高级面试指南》,果断收下

程序员啊叶

Java 编程 程序员 架构 java面试

大厂面试突击必备:“网络编程”高频八连击,扛得住吗?

程序员啊叶

Java 编程 程序员 架构 java面试

加密生活,Web3 项目合伙人的一天

TinTinLand

区块链

Moonbeam创始人解读多链新概念Connected Contract

One Block Community

区块链

设计消息队列存储消息数据的 MySQL 表格

爱晒太阳的大白

SocialFi 何以成就 Web3 去中心化社交未来

One Block Community

区块链

Snowflake vs. Redshift的2022战报:两个数据平台谁更适合你?

雨果

数据质量提升

奔向架构师

数据质量 7月月更

openim支持十万超级大群

Geek_1ef48b

好的plm软件有哪些?plm软件排行榜

PingCode

JAVA编程规范之服务器

源字节1号

软件开发 后端开发

leetcode 406. Queue Reconstruction by Height 根据身高重建队列(中等)

okokabcd

LeetCode 数据结构与算法 贪心算法

备战金九银十,两份JAVA面试题2022最新整合版,祝你脱颖而出

王小凡

Java MySQL spring 面试 springboot

腾讯被裁,转头去字节!Java后端核心面试题在手,怎能进不去大厂

程序员啊叶

Java 编程 程序员 架构 java面试

阿里内网最新发布“M8”级Java面试笔记,助力金九银十

程序员啊叶

Java 编程 程序员 架构 java面试

大家都在用的plm项目管理软件有哪些

PingCode

项目管理

浅谈非 EVM 公链的可能性: 兼容多类型虚拟机是否是区块链未来?

One Block Community

区块链

DTSE Tech Talk丨第2期:1小时深度解读SaaS应用系统设计

华为云开发者联盟

云计算 后端 SaaS

华为云数据治理生产线DataArts,让“数据'慧'说话”

华为云开发者联盟

云计算 华为云

(WebFlux)001、如何自定义注解实现功能

编号94530

spring springmvc WebFlux 拦截器 @WebFilter

jQuery 遍历-后代深入解析分析【前端jQuery框架】

恒山其若陋兮

7月月更

SpringBoot日志收集-Aop方式-存进数据库

宁在春

aop springboot 7月月更

小心你的字典和样板代码

白日梦想家

总结 编码 反思 编程、 编码风格

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