

【AIOps探索】基于CauseInfer方法的根因定位

嘉为蓝鲸

2021-07-15

导读：AIOps探索专栏第三期——运维“终极命题”，如何精确定位故障发生节点，进行根因分析？

‍‍‍‍‍‍‍‍‍‍‍‍‍

背景

近些年来，在需要支持多平台的互联网应用中，越来越多的公司选择从单体系统迁移到微服务架构。微服务系统通常包含成百上千的应用，这些系统是高度动态和复杂的，一个服务可以有几个到几千个实例运行在不同的容器和服务器上，而可用性问题一直是大规模微服务系统面临的一个关键挑战。在这些系统中，服务质量（如性能、可靠性）的任何异常都有可能沿着服务调用链传播，由少量的根因节点影响到关联节点，并最终导致业务级别的可用性问题（如访问成功率下跌）。

针对运维中的难题，全球权威的IT研究与顾问咨询公司 Gartner于2016年提出了AIOps(Artificial Intelligence for IT Operations)概念，即智能运维。AIOps分析的运维数据主要有三种：指标、日志、调用链（如上图）。本文所探索的论文《CauseInfer:Automatic and Distributed Performance Diagnosis with Hierarchical Causality Graph in Large Distributed Systems》即以性能指标数据为依据，通过构建服务调用拓扑和指标因果拓扑，利用深度优先搜索（DFS）遍历搜索根因性能指标，最终输出根因指标的排序。

根因定位浅谈

根因定位是智能化运维中一项重要且难以实现的领域，看起来很庞大，很抽象，无从下手，也被称之为运维的“终极命题”。目前行业内外有已有多种根因定位方案投入使用，但因为系统之间差异性及根因定位的复杂性，目前仍然没有一套能在所有系统行之有效的方案。

因为针对不同的系统/业务，通常要针对性的使用方法，大多数人对要解决的问题都模糊不清，就想着有“尚方宝剑”一刀切的解决这个难题，这是不现实的。根因定位要具体情况具体分析，将复杂抽象的问题分解成具体明确的条件情况，下面列举常见的根因定位场景：

搜索定位类：当多维KPI异常，如何定位到其根因维度，也叫指标下钻分析，是2019年AIOps挑战赛的赛题。
指标关联类：该类根因分析旨在分析海量的多维时间序列，找到故障时不同指标之间的关联关系（因果关系）。
调用异常类：该类根因分析一般具有明确的服务调用拓扑关系（图），旨在捕捉服务链路上的异常，定位异常实体。

以上三个场景是研究人员常关注的问题，各有多篇相关论文阐述。

微服务相关的异常：可以分为性能异常（一般表现为响应时间增加，本文探讨的即属于此种），可靠性异常（一般表现为错误数量增加），流量异常（QPS异常）引起的微服务系统故障，此类根因定位方法关注的指标不尽相同。

针对不同的场景根因定位方法不同，针对相同的场景根因定位方法也会不同，目前大型公司使用的方法大致有以下几种：基于调用链的根因定位方案，基于异常范围搜索的HotSpot算法进行根因分析，知识图谱方法，基于报警聚类的方法进行根因分析，基于时间序列相关性分析的算法等等。

微服务架构异常诊断的难点‍‍‍

当出现业务级别的可用性问题时（黄金指标异常），通过指标异常检测定位到异常的主机/节点并不难，难点在于如何从异常的节点集合中找到引起这次异常的根因节点/根因指标。通常来说，表现在以下几个方面：

① 微服务的异常可能是由多方面的原因造成：比如网络的抖动，机器的性能故障，有时人为的操作变更也会引起微服务的故障，有效的根因定位通常需要考虑多方面的原因。

② 难以获取固定的服务调用拓扑：不同的厂家微服务设计尚未规范化，且服务调用经常频繁变化，基于静态的异常定位方法难以解决动态的服务调用情况。

③ 当根因节点发生异常时，与其相关的其他节点的服务指标都会随之发生抖动，形成了多节点异常，多节点内的多指标异常，如何“从万军之中取上将首级”地找到根因节点的根因指标，也是微服务根因定位的一大难点。

基于CauseInfer方法的根因定位

研究领域：

CauseInfer是针对微服务领域性能问题的根因定位方法，其主要考虑物理资源、逻辑资源（锁）异常引起的微服务异常问题（如下图）。

推理过程：

CauseInfer原型机可以轻量级的部署在每个节点中并分布式的工作，通过TCP请求延迟低时间复杂度的生成服务之间的拓扑关系，通过PC-Algotithm和D-Separate方法建立节点性能指标的因果拓扑图。基于生成的服务调用因果图和指标依赖因果图，当SLO指标发生异常时，通过DFS算法搜索所有异常节点，并根据得分对根因进行排序输出（如下图）。

步骤详情：

A. 数据收集：

从多个跨栈数据源（app,进程,OS）收集高维数据流。

在服务因果图的构建阶段，需要每个app的SLO，由于不是每个应用（比如mysql,hadoop）都有，且不同的应用的SLO不尽相同，因此作者提出统一用TCP请求延迟作为每个应用的SLO指标。

B. 异常点检测：

对于在线的异常点检测，CauseInfer使用Cusum的方法（此方法对噪声敏感，在离线分析中很难检测长期变化，会有较高误报率），对于离线的长时间的时间序列数据，使用BCP（贝叶斯变点检测）方法。两个方法的效果对比如下图。

C. 因果图构建：

因果的定义：变量X的变化会影响到变量Y的分布，则称X是Y的原因，记作X→Y，默认X、Y不会互相影响。所以要构建的目标因果图是一个DAG。（有向无环图）
服务因果图：

各主机执行netstat命令获取连接信息列表。（包含协议、源、目标、连接状态等）
提取TCP连接的部分构造成：source_ip:port→destination_ip:port的列表形式。
查询端口对应的服务名，将上面的列表元素中端口替换成服务名，得到source_ip:service1→destination_ip:service2的列表。
通过Client、Server之间发送流量的滞后相关性确认(ip,service)元组（比如(192.168.1.115,tomcat) — (192.168.1.117, httpd)）之间的因果关系。假设服务A发送的流量是(X1,X2,…..XN)，服务B发送的流量是(B1,B2,…..BN)，则滞后相关性ρ(k)计算如下，k∈[-30,30]，通过下面的计算公式找到|ρ|max时的K值，当K>0则说明A→B，否则B→A（下图2说明k=4时，ρ最大且大于0，说明A→B。

指标因果图：

基于PC-Algorithm生成，这是一种从一组变量的集合中建立DAG的算法。G=(V,E)，V表示变量集，E表示边集。
基于条件交叉熵G2确认变量是否独立（如下公式），m表示样本集的大小，CE表示某种情况下的交叉熵，若G2>0.05,则说明(X,Y|Z)独立。
通过PC算法生成一个完全联通的DAG，通过G2确定DAG中独立的部分，从而获得骨架图。
使用D-Separate方法确认剩下变量的因果方向，即可得到指标因果图。（基于PC算法，根据是否有先验因果关系可分成2种方法）
使用PC算法生成的DAG可能包含多个孤立子图，违反直觉的因果关系和双向链接，通过以下方式选出最大子图：

1）TCP延迟指标无子级

2）最终的影响指标在图中从每条路径都可抵达

3）预设的根因指标无父级

4）对于双向链路，随机取舍一个方向

根因判断：

在线的异常点检测：使用带滑动窗口的双边Cusum方法判断应用的SLO指标是否异常。
假设应用X指标为(X1,X2,…..XN)，窗口长度为60，通过检测[XT-60,XT]的Cusum来判断XT是否异常（设定上下阈值），若出现异常，则窗口暂停。
DFS深度优先算法遍历本应用的性能指标因果图，当某个异常节点无异常子节点，则判断此指标为根因指标，如果本服务性能指标正常，则对父服务SLO进行异常检测，重复此步骤。
如果输出的是根因节点的集合，则通过下面的公式计算得分，对根因进行排序输出。

实践

依照论文思路和实际情况，我们构建了模型，并用数据进行实验

总结

当前，在大型Internet系统中，基于微服务架构的应用变得越来越普遍，而高度动态的实时运行环境使得微服务系统很容易出现性能和可用性问题。快速故障根因定位可以提高服务质量并减少收入损失。本文探索的CauseInfer方法可以自动构造两层层次因果图且推断故障的原因，对于微服务系统下的性能诊断有着良好的借鉴意义。

【参考文献】

P Chen,Y Qi,P Zheng,D Hou,CauseInfer: Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems,IEEE 2014

感谢您的阅读

如果您的企业有相关研运需求

请点击阅读原文，留下您的需求

我们将安排对应区域的同事与您详细介绍

好文回顾

Reading