智能运维系列（九）| 基于交易树的根因告警定位方法
监控告警是故障发现的重要一环，异常发生时，运维人员常常可以从一些告警中找到蛛丝马迹，但是每天动辄上万笔的告警却让运维人员无从下手。就像战场上的子弹，99%都是做掩护，只有1%的子弹能打中敌人！“到底哪些告警才是故障真正的根因？”相信很多运维同学都曾在深夜发出这样的灵魂拷问。如何找到一个有效的方法来帮助运维人员定位出真正的根因？本文就和读者分享一下微众银行技术团队的心路历程。 本文收录在专题《智能时代下的运维》系列 。
“告警定位”简简单单四个字，想要做好却不是一件容易的事情。每一条告警，都会包含相应的告警级别（根据程度分为critical, major, minor, warning），告警类型（根据告警源分为网络告警，专线告警，主机告警，TDSQL告警，WEMQ告警等），告警对象（具体的异常点比如主机A，数据库B），告警发生时间等信息。传统的做法是将故障时间段内的低级别的告警过滤掉，只保留高级别的告警，然后按照专家经验对剩下的告警进行优先级排序，比如说网络告警的优先级最高，优先推出；母机、子机告警同时出现，母机告警优先推出；TDSQL节点告警和TDSQL主机告警同时出现，优先推节点告警。类似这种规则还有很多很多，大多都是根据历史案例和运维人员的专家知识归纳总结出来的。这种做法存在几点问题：
- 规则覆盖的范围总是有限的，有时会出现误告，需要运维或开发人员对现有的规则进行修改或者添加新的判断分支，费时费力，并且随着规则库的不断扩大，维护起来也越发麻烦，新的规则和原有的规则冲突的情况也时有发生。
- 有时低级别的告警往往包含了更重要的信息，是更应该被推出来的根因，但是按照现在的逻辑是会被过滤掉的，从而导致信息丢失；如果放开限制，对全级别的告警进行分析，又会引入很多噪声，从而导致误判。
- 可解释性较差，根据规则推出的告警经常会让运维人员一头雾水，因为这种做法缺乏推理的过程，运维人员只看到最后的结果，却不清楚这个结果是怎么得到的，难以让大家信服。
好的告警定位的方法应该是一个由表及里、从大到小的过程。通过故障发生时的表象，一步步推导，过滤掉干扰项，缩小候选告警集合的范围，最后定位到关键的一条或者几条告警，再整理成方便运维人员阅读的根因话术输出。
对于微众银行而言，故障发生直接会导致一部分交易出现超时、中断等现象。因此，异常交易就成为了一个很好的故障分析切入点。而交易的超时和中断怎么判断，依赖于交易树的信息。下面，我简单介绍一下交易树的概念。一笔交易从开始到结束，会在 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 等）来帮助我们判断故障类型，这样当新的故障发生时，只需要把分类器输出的类别下相应的告警聚类即可。
除了故障根因定位以外，故障预警也是一个可以展开的方向。上文我们有提到过有一些级别较低的告警，实际上在故障大规模发生之前，往往系统会出现性能降低、可用率下降等情况，导致少量的交易流水出现问题，虽然还够不上一个异常事件，可是一旦没有及时处理，问题逐渐累积，就会引发一次故障。如果我们能够用这些异常交易来关联低级别的告警提前进行分析，也许就能够防患于未然，做到故障提前发现、提前处理。
如果希望了解我们在智能运维中使用的机器学习算法以及支持根因分析的具体方法，请参阅该系列其他文章。
前文回顾
作者简介
微众银行智能运维系统核心开发者 薛文满
- 发表于:
- 本文为 InfoQ 中文站特供稿件
- 首发地址：https://www.infoq.cn/article/t1YTBqmBkp7xXdAjkV1P
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
