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

背景介绍

随着云计算的快速发展,越来越多的系统转移到云上。在整个过程中实现了软件和硬件资源共享的同时,也降低了整体成本。随着系统复杂性的提高,伴随而来的是大量的组件交互导致快速定位故障根因的困难。为提高运维效率,在运维发生故障的过程中提高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指标。打破传统异常分析的局限性,同时在每个步骤中都采用了多种算法结合的方式对数据进行检测和检验以保证定位的准确性。
同时本方案中还存在一些不足之处,如在构造异常分数过程中,将程序缓冲区设置过长,无法更快的适应数据的变化,容易产生误报,可以考虑根据数据特性缩短程序缓冲区,使用较少的历史数据进行异常分数构造。同时平台指标的异常检测方法较少,无法适应数据的多样性,可以考虑根据数据特性增加异常检测算法。

  • 6
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
2020年摩拜杯算法挑战赛是一场针对算法开发者的竞赛,旨在促进算法的研究和应用。这场比赛以解决实际问题为目标,主要涉及城市公共自行车共享系统的优化和改进。 比赛内容主要包括两个方面:一是自行车调度优化,二是用户需求预测。自行车调度优化指的是如何在不同区域的自行车供需不平衡的情况下,调度自行车,使得用户更便利地获得自行车并保持系统的平衡;用户需求预测则涉及如何通过算法预测用户在不同时间和地点的自行车需求量,以便提前做好调度和供给准备。 此次比赛采用评测系统对算法进行评估。参赛选手需要根据提供的数据集,设计和实现算法,以最大程度地优化自行车调度策略和用户需求预测准确性。评测系统将根据各种指标对算法进行评分,包括自行车调度效率、调度准确性和用户需求预测准确性等。 这场比赛为算法开发者提供了一个展示自己研究成果和能力的舞台,也为解决城市共享自行车系统面临的问题提供了创新的解决方案。通过比赛的推动,有望推动共享自行车系统的智能化和优化发展,提高城市居民的出行效率和便利性。 摩拜杯算法挑战赛不仅对参赛选手具有挑战性,也对整个行业具有积极的推动作用。未来,有望通过更多的类似比赛和技术创新,进一步促进共享自行车领域的发展,并为城市出行提供更加智能化、高效和便捷的解决方案。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值