写点什么

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

2020 年 8 月 11 日

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

监控告警是故障发现的重要一环,异常发生时,运维人员常常可以从一些告警中找到蛛丝马迹,但是每天动辄上万笔的告警却让运维人员无从下手。就像战场上的子弹,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 等)来帮助我们判断故障类型,这样当新的故障发生时,只需要把分类器输出的类别下相应的告警聚类即可。


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


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


前文回顾


专题 | 智能时代下的运维


作者简介


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


2020 年 8 月 11 日 11:331227
用户头像
陈思 InfoQ编辑

发布了 575 篇内容, 共 204.1 次阅读, 收获喜欢 1180 次。

关注

评论

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

后端服务太多,且涉及多种语言,如何进行高效管理?

我爱娃哈哈😍

架构 架构设计 架构场景实战

产品经理训练营 Week4 学习心得

Mai

陌陌一面,为什么SpringBoot的 jar 可以独立运行?

Java小咖秀

jar maven springboot 集成 pom

一文带你更方便的控制 goroutine

Kevin Wan

go 线程 并发 goroutine

几十年来户外广告为什么能不被取代?

󠀛Ferry

四月日更

关于 Spring 中 getBean 的全流程源码解析

小傅哥

Java spring 源码分析 小傅哥 getBean流程

深入剖析共识性算法 Raft

vivo互联网技术

复制 选举 分布式协调 Leader Follower

女朋友问我:MySQL 事务与 MVCC 原理是怎样的?

一个优秀的废人

Java 数据库 事务隔离级别 事务 MVCC

图算法系列之无向图的数据结构

Silently9527

Java 数据结构和算法 图算法 无向图

视频怎么插入慢动作?Adobe国际认证,三秒解决视频剪辑难题

Adobe国际认证

新一代容器,安全容器kata-container实践

陈迪

Kubernetes 容器 容器安全

产品经理训练营 Week3 学习心得

Mai

Spark任务等待与运行策略

小舰

4月日更

app架构师,10天拿到字节跳动安卓岗位offer,好文推荐

欢喜学安卓

android 程序员 面试 移动开发

MySQL权限管理实战!

Simon

MySQL 权限管理

微信朋友圈高性能架构

chenmin

6种常见的地标识别算法整理和总结

华为云开发者社区

KNN CNN 地标识别 GLDv2 地标识别算法

使用gradle插件发布项目到nexus中央仓库

程序那些事

Java maven Gradle 程序那些事

面向K8s设计误区

阿里巴巴中间件

云计算 Kubernetes 容器 分布式

带你入门目标检测算法

华为云开发者社区

网络 数据集 目标检测 yolo two-stage

【LeetCode】移除元素Java题解

HQ数字卡

算法 LeetCode 4月日更

阿里P7手把手教你!系统学Android从零开始,内含福利

欢喜学安卓

android 程序员 面试 移动开发

女朋友问我:什么是 MySQL 的全局锁、表锁、行锁?

一个优秀的废人

MySQL 数据库 锁机制 备份

模块二:课后作业

iHai

架构实战营

模块二课后作业

Damon

聪明人的训练(十九)

Changing Lin

4月日更

细说Python Lambda函数的用法,建议收藏!

华为云开发者社区

Python 函数 匿名 Lambda函数 表达式

一文搞懂分布式锁的原理与实现

架构精进之路

分布式锁 4月日更

用WASM连接Rust与Python | Rust 学习笔记(三)

李大狗

Python rust 狗哥 Wasm

这三年被分布式坑惨了,曝光十大坑

悟空聊架构

技术干货 | 基于MindSpore更好的理解Focal Loss

华为云开发者社区

损失函数 mindspore Focal Loss 图像物体检测 采样

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

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