背景介绍

随着云计算的快速发展，越来越多的系统转移到云上。在整个过程中实现了软件和硬件资源共享的同时，也降低了整体成本。随着系统复杂性的提高，伴随而来的是大量的组件交互导致快速定位故障根因的困难。为提高运维效率，在运维发生故障的过程中提高MTTR(平均解决时间)和减小MTTA(平均响应时间)已成为重中之重。因此运维智能化重要性成为业界共识，如何快速定位根因，避免损失成为极大关注点。
2020年AIOps国际挑战赛以“微服务应用系统故障发现和根因定位”为题。赛题数据来源于浙江移动真实生产环境数据。此次比赛要求参赛选手在最短时间内提交检测结果，对检测速度和检测准确度都提出了极大挑战。其中故障类型包含数据库类型故障，容器类型故障，主机类型故障等。新华三代表队在保证所有故障都在1分钟内进行快速定位的同时，最快可达到1秒内定位根因，做到了秒级识别和秒级定位。最终在2020年AIOps国际挑战赛中获得冠军。
数据介绍
为方便选手对整体系统进行充分了解，主办方提供了不同网元中的实时性能指标、黄金业务指标、调用链数据、部署清单等。
实时性能指标分为操作系统指标、数据库指标、中间件指标和容器指标。每个指标信息中会包含该指标的名称、时间、指标类型及所在网元等信息。

表1 实时性能指标

实时业务黄金指标体现了整个系统在不同时间的请求数量，请求接入个数，成功率等信息。

表2 实时业务黄金指标

调用链数据可以全面体现微服务中全部调用信息。

表3调用链数据

应用部署架构数据提供了整个系统的部署信息，方便根因定位时排除因部署造成的异常情况。

表4 部分部署清单

比赛方式

本次比赛的要求是当故障发生时，在及时定位出问题网元情况下，还要精确到网元内具体的性能指标（故障网元为docker时，无需定位具体性能指标）。实验环境为主办方统一提供的云计算资源，数据获取方式为实时获取主办方kafka中的数据。参赛队伍需在发生异常后的规定时间内产生结果，系统会从平均定位时间、定位精度和查全率等指标评判参赛队伍的算法效果。

图1 故障数据示例

方案介绍

本方案采取实时检测异常的方式，当检测到异常后开启根因定位，并返回相应的故障性能指标。为了更高效准确的定位到微服务系统的故障，本方案采用将多种算法与调用链数据的有效结合，以提高根因定位效果。
本方案总体分为三个步骤：定位异常时刻，定位异常网元，定位网元内异常指标。
**

定位异常时刻

**
异常时刻的定位主要通过对黄金业务指标的异常检测获得。黄金业务指标一般是指对用户体验有较明显影响的指标。经过大量的数据分析工作后，将服务响应时间、服务请求成功率、服务接入个数等作为黄金业务指标进行优先处理。
异常时刻定位为整体方案的第一个步骤，定位的准确性直接决定了最终定位的准确性。为提高整体方案的准确性，采用针对不同的黄金业务指标采取不同的异常检测算法，检测出异常后立即开启根因定位。
基于规则异常检测
对接入成功率这类指标采用基于规则的异常检测算法。如图中的success_rate展示的为每分钟内服务的接入成功率，对该指标采用接入成功率低于某一固定值时立即开启根因定位。

图2 接入成功率
基于统计的异常检测
对于一些周期性和趋势性信息较不明显的指标采用基于统计的异常检测算法，如3Sigma算法。如图所示的服务响应时间数据，非异常时刻数据较为平稳，采用基于统计的异常检测算法可以较为有效地检测出异常（图中的尖刺点）。

Figure 3 服务响应时间

定位异常网元

异常网元定位通过对调用链数据进行数据处理，对不同网元进行异常分数构造以及定位来得到最终的问题网元。
数据处理
由于原始的调用链信息中存在大量的冗余信息，无法提供准确的数据特征，因此需要对调用链数据进行预处理。处理的目的是为了较为清晰地获取网元间的调用链信息以及每个网元运行的时间，用于构造关键特征。
网元拓扑信息
调用链数据主要提供了整个系统的网元拓扑信息及每个网元持续调用时间。首先需要根据原始的调用链数据构造整个系统的网元拓扑，清晰化每个网元之间的调用关系。

Figure 4 某单一调用链中的网元拓扑

网元关键特征提取

除了网元拓扑，调用链数据中还可以提取出每个网元的持续调用时间（elapsedTime）。elapsedTime是指该网元从接收请求到发回响应的整体时间，其中还包含了该网元调用其他网元的时间。通过对调用时间的处理，消除子调用的影响。同时当异常样本数据量足够大时，可以挖掘出某个网元调用时间过长对应了哪种类型的故障。
在对网元调用信息进行处理时不难发现，当系统中出现故障时，一段时间内的elapsedTime会增大。但是在一段时间内，如何准确定位某个网元的elapsedTime为异常，也成为一个难题。
单纯分析某一网元的elapsedTime，无法获取精确异常时间。如图所示，该网元OSB在05:39:15后数值突然变大，没办法找到任何规律，没有太大价值。

图5 单一网元每次调用的elapsedTime
为构建有价值的特征，经过对数据的分析，采用单个网元在一段时间内的平均elapsedTime做为特征进行分析。如图所示，同一网元的平均elapsedTime更具有分析的价值。

图 6 同一网元每分钟的平均elapsedTime

异常分数构造

为了检测出具体的故障网元，还需要使用上述的关键指标构造异常分数并进行异常检测。由于新构建的特征属于时序特征，大部分情况下不具备周期性和趋势性，可以采用S-H-ESD算法进行异常分数构造。
以单个网元为例，如果我们想计算当前时刻i该网元的调用时间xi的异常分数，需要选取A时刻前一段时间的平均elapsedTime，记为数据X。首先计算时刻xi与数据X之间的MAD，以及当前时刻的临界值。并通过相应的异常分数公式构造异常分数。
MAD=median(|x_i-median(X)|)
异常分数＝(x_i-MAD)/临界值
**

定位问题网元

**
问题网元的定位主要通过对异常分数的分析来确定。对于异常分数可以采用构造转移矩阵，对转移矩阵采用随机游走或者连乘的方式进行处理，定位出问题网元。但是上述方式耗时较长，无法快速定位出异常网元。本方案采用了构造调用链异常分数表的方式进行问题网元定位。
将每次调用的参与方看成一个调用对，被调用方为行，调用方为列，为避免异常分数表受到拓扑关系的影响，表中的数值为被调用方的异常分数。如果分数为NaN，代表二者不存在调用关系。

图 7 调用链异常分数表
在实际操作过程中，调用分数表可以帮助排除掉部分网元。由于本次比赛故障类型较多，异常分数表大多数情况下会展示出多个网元出现异常。因此在多个异常网元中找到核心异常网元也成为一大难题。获得异常分数表后需要结合整体部署清单以及调用链数据中的False信息对异常网元进行进一步的分析比较。如可以采用排序方法，找到异常排名较为靠前的网元进行网元的性能指标分析。
当自调用发生异常时，自调用的异常分数明显高于其他调用异常分数。数据库发生异常时一般伴随着调用链数据中的False较多。当异常分数表中发现多个异常时，此时需要借助主办方提供的部署清单进行根因判断。如多个部署在某一os上的网元发生异常时，该os为问题根因可能性较大。

定位网元内异常指标

根据比赛要求，在定位到异常网元后需要进一步定位出导致当前网元异常的具体指标。本步骤通过采用多种关联分析算法对平台指标数据进行关联分析，得到各个指标的优先级，并且对各个指标进行异常检测，针对不同类型的指标（平稳型、周期型）采取不同的异常检测方法。对于暂时没有分到已知类型指标，对差分进行检测 (主要考虑能导致网元的异常发生,则本身的变化也就是差值会比较明显)，将异常检测得到的异常分，根据优先级的不同乘以不同的系数，优先级越大，则系数越大。
基于时间的关联分析
本算法首先检测出异常网元中全部平台指标的异常时间点，通过比较异常网元与异常平台指标的异常时刻，来进行判断。
如果指标异常早于网元异常，可以判定为该指标导致的网元异常。但是由于不同的平台指标的采样周期不同，部分网元不太适用该方法。
格兰杰因果关系检验
格兰杰因果检验主要是针对预测关系进行检验，而非因果关系，比如燕子低飞是先于下雨而发生的，所以你做检验，就会得到燕子低飞是下雨的Granger Causality（零假设被拒绝）；但是从哲学角度来看，下雨才是燕子低飞的真正原因。本方案主要使用格兰杰检验来对根因效果进行验证。
通过对性能指标两两进行格兰杰因果关系检验，找出有最明显影响的指标。如对连接统计数量（ss_total）和网络接口出流量（Outgoing_network_traffic）进行检验，发现当滞后阶数（lags）为2时，二者的影响关系较大。

图8 网络接口出流量

图9 连接统计数量

图10 格兰杰检验结果
格兰杰检验可以作为根因定位效果的检验，但是对于不同的环境效果差异较大。
PCMCI
PCMCI算法会将网元异常与性能指标异常进行关联分析，构建因果关系图。越靠近根节点的指标优先级越高。

图11 PCMCI算法
实际使用时因为PCMCI类的算法受到一些条件制约，比如所有的原因指标要可见等因素才能保证因果图的准确性，因此只是将PCMCI得到的结果作为一个参考，离根节点越近的指标赋予的优先级更高，反之亦然。

图12 PCMCI获取指标因果关系图

关联性分析
将异常网元中性能指标进行两两相关性分析，相关性越大，则优先级越高。这样指标A异常肯定会导致某一类异常(将此指标优先级提高)，平时指标A异常或不异常的条件下, 特定网元的异常分布是相同的(将此指标优先级降低)，具体使用的方法可以通过计算互信息，样本数量够多时可用MIC最大互信息系数等方法。

方案总结

本方案的核心思想为通过网元间的调用关系来定位问题网元，而并未局限于检测网元内部的异常KPI指标。打破传统异常分析的局限性，同时在每个步骤中都采用了多种算法结合的方式对数据进行检测和检验以保证定位的准确性。
同时本方案中还存在一些不足之处，如在构造异常分数过程中，将程序缓冲区设置过长，无法更快的适应数据的变化，容易产生误报，可以考虑根据数据特性缩短程序缓冲区，使用较少的历史数据进行异常分数构造。同时平台指标的异常检测方法较少，无法适应数据的多样性，可以考虑根据数据特性增加异常检测算法。

AIOPS挑战赛冠军场景算法分享相关推荐

ICPR 2020|大规模商品图像识别挑战赛冠军技术干货分享
点击上方"小白学视觉",选择加"星标"或"置顶" 重磅干货,第一时间送达来源:新智元编辑:SF [导读]近日,国际模式识别大会(ICPR ...
ICCV 2019 COCO Mapillary挑战赛冠军团队技术分享
近日,在 ICCV 2019 Workshop 举办的 COCO + Mapillary Joint Recognition Challenge(COCO + Mapillary 联合挑战赛)公布了最 ...
【CVPR智慧城市挑战赛】无监督交通异常检测，冠军团队技术分享
[新智元导读]"智能交通视频分析界的ImageNet竞赛"--英伟达城市挑战赛落下帷幕.新加坡松下研究院联合中科院自动化所,提出了一种双模态动静联合检测方案,在交通异常检测比赛中拔 ...
2020数字中国创新大赛 • 算法赛道冠军技术方案分享
写在前面的话作者说:我是来自京东数科的朱翔宇,也是此次大赛 Champion Chasing Boy 团队的 DOTA(常用ID),在与队友鱼遇雨欲语与余(京东零售). 尘沙杰少.林有夕.嗯哼哼唧 ...
中兴的计算机视觉水平,中兴通讯视频算法获IEEE CVPR挑战赛冠军助力5G大视频业务发展...
21日,记者从中兴通讯获悉,在美国加利福尼亚长滩举办的计算机视觉领域国际顶级会议IEEE CVPR( Computer Vision and Pattern Recognition)大会上,中兴通讯荣 ...
CVPR 2020 SLAM挑战赛冠军方案解读，搞定超难数据集TartanAir
点击上方"3D视觉工坊",选择"星标" 干货第一时间送达作者丨R 来源丨旷视研究院编辑丨极市平台导读在CVPR 2020 SLAM挑战赛上,旷视研究院参 ...
CVPR 2018 | 8篇论文、10+Demo、双项挑战赛冠军，旷视科技掀起CVPR产学研交流热潮
第 31 届计算机视觉和模式识别大会 CVPR 2018(Conference on Computer Vision and Pattern Recognition)在 6 月 18 日至 22 日于 ...
7次KDD CupKaggle冠军的经验分享：从多领域优化到AutoML框架
本文结合笔者在7次Kaggle/KDD Cup中的冠军经验,围绕多领域建模优化.AutoML技术框架以及面对新问题如何分析建模等三个方面进行了介绍.希望能够帮更多同学了解比赛中通用的高效建模方法与问题 ...
华为2021软件精英挑战赛复赛赛后方案分享
华为2021软件精英挑战赛复赛赛后方案分享引言: 赛题介绍资源规划和调度输入示例: 输出示例: 总体处理流程部署策略购买策略迁移策略赛后感受开源代码引言: 我是来自成渝赛区UESTC ...

AIOPS挑战赛冠军场景算法分享