智能运维(AIOps)系统中的异常检测方案

https://mp.weixin.qq.com/s/okKnaqJVV7bfS1_iUtdIWg

1.概览

异常检测是智能运维(AIOps)系统中一项基础且重要功能,其旨在通过算法自动地发现KPI时间序列数据中的异常波动,为后续的告警、自动止损、根因分析等提供决策依据。在实际场景下,由于异常点数据稀少,异常类型多样以及KPI类型多样,给异常检测带来了很大的挑战。

本文整理了LogicMonitor-AI团队在AIOps决赛暨首届AIOps研讨会中的分享内容,主要介绍了我们在AIOps异常检测竞赛中的算法设计思路和实现细节。
这里写图片描述
接下来主要分三部分来介绍:

• 首先介绍这次竞赛的背景和需求,在此基础上给出我们方案的设计原则

• 第二部分会详细介绍这次竞赛中使用的算法方案

• 最后探讨方案的不足与改进计划

2.需求分析

这里写图片描述
问题描述

在竞赛中,主办方提供了两份数据集,分别用作训练和测试,数据集由若干KPI时间序列组成,这些数据都来源于真实的运维场景。训练数据事先由运维人员手工标注出了异常段,要求根据训练数据生成模型并对测试数据进行异常检测(即对每个数据点标注是否为异常点)。

评估

通过对比测试集上模型的检测结果与真实标注数据,计算F-Score作为算法的评估标准,考察算法的精准率和召回率。通常情况下,运维人员往往只关心异常检测算法能否检测到某一连续异常区间,而非检测到该异常区间的每一个异常点。因此,对于连续的异常段,规定了时效性窗口,只要在窗口内检出异常点,那么该异常段都算作成功检出,否则都判为失败。

考虑到算法的实用性,竞赛还补充了几点规则:

• 禁用手工干预:在模型训练阶段,不允许手动地建立从“KPI曲线ID或KPI曲线计算得出的特征”到“算法和参数”的一一映射。即在模型训练阶段,不允许手动针对一条特定的KPI曲线进行算法的选择和参数的调优。

• 禁用未来信息:不允许参赛算法使用未来点的信息对当前点的异常做出判断

关于这两点规则,放到实际应用场景下很好理解。在实际监控系统中,首先,KPI数据规模是非常大的,几乎不可能针对每条KPI手工地去配置算法、参数以及调优。那么就要求算法足够的稳定和普适。其次,异常检测往往需要实时地对数据点进行判定,自然也是无法利用未来信息来帮助判定。

设计原则

基于以上需求分析,我们确立了以下几条设计原则:

• 监督学习:因为数据本身是带标注的,自然很适合用监督学习来进行训练

• 自动化:为了避免手工干预,我们需要将整个机器学习流程设计为自动化的方式,同时在算法模型选择上尽量避免调参需求高的模型。实际上,在决赛中,我们全程是无法接触到数据以及程序运行过程的,这一点也要求方案本身有较高的鲁棒性。

• 流处理:按流处理的方式对测试数据进行特征提取并实时进行异常检测,避免使用到未来数据。在特征方面,需要选择能够通过流式获取到的特征,避免使用批处理方式提取特征。

在以上三点的基础上,兼顾普适性:

• 框架通用,适用于相同场景下的其他数据集

• 实现简单,流程清晰,易维护

• 性能良好,满足真实生产环境需求

• 算法表现稳定

3.方案详解

这里写图片描述
我们将异常检测作为二分类问题来处理,按照机器学习流程分为四个阶段:预处理,特征提取,模型训练和最后的异常检测。

技术栈方面,整个方案通过Python来进行实现,用到的主要工具包括:Keras, Numpy,Pandas和Sklearn
这里写图片描述
在预处理过程中,我们首先面对的一个挑战是样本极度不平衡,这也是异常检测问题的主要特点。如图所示,在本次竞赛中,异常样本比例只有2%,远远低于正常样本。在实际应用中,这个比例可能会更低。如果直接将样本进行训练,模型会倾向于将所有样本预测为正常样本,那么将无法达到异常检测的目的。

为了解决这个问题,我们尝试了几种方案

  1. 对正常样本进行欠采样以达到正负样本1:1,实验发现这种方案因为丢失了大量的样本信息,模型会出现比较严重的过拟合,泛化性能不佳

  2. 欠采样加集成学习。这种方式虽然效果有所提升,但由于每个基分类器的正确率很低,集成后的效果也不是很理想

  3. 异常样本过采样以达到正负样本1:1,最后通过阈值进行决策调整。实测下来,这种方式的结果比较理想,成为了我们的最终方案。

这里写图片描述
在需求分析中,我们提到了竞赛评估标准中有时效性需求,即对于一段连续异常,我们需要在首个异常点出现的后的时效窗口内检出异常点。这句话怎么理解呢?我们来看上面这幅图,图中红点表示发生了一段连续异常,蓝色框表示时效窗口,基于规则,我们需要在蓝框包含的样本点检出异常,否则后续异常点即使判断正确也会视作失败。

自然地,起始端的异常样本点价值是远远大于后续样本的,因此我们需要增强该类样本的权重以提升其价值。结合前面提到的样本均衡策略,样本权重增强也是通过过采样来实现的。

这是预处理阶段的第二个关键点。
这里写图片描述
接下来我们来看特征提取,时间序列的重要特点是在时间维度上的相关性,即上下文信息。所以我们不宜直接将单个数据点作为样本来训练,而需要将上下文特征提取出来。

异常往往意味着某个维度上的突变,可能是原始值的突变,也可能是均值、方差等统计量的突变,通过前后对比能够很好的捕捉到这类变化。

考虑到这些特点,我们通过三种方式来获取特征

第一类,通过滑动窗口,提取该窗口类数据的统计特征

第二类,通过序列前后值的对比,得到对比特征

第三类,结合滑动窗口和对比,得到比统计特征

上图示意了,在T时刻,通过三种方式获取T时刻对应的不同特征。
这里写图片描述

统计特征方面,我们主要使用了均值、方差和分位数等

对比特征方面,使用了差分和变化比例这两种对比方式,差分代表了绝对变化,变化比例则是相对值。需要注意的是,变化比例在原始数据接近0时很容易出现畸变,所以某些场景下不是太好用。

另外我们选择了不同的窗口宽度来进行特征提取,所以总的特征集是窗口宽度、统计特征、对比特征的交叉组合。

上图右侧是特征提取的一个例子,将原始数据转换到方差差分特征空间后,异常样本的辨识度明显提升,这也利于后续模型训练和识别。
这里写图片描述
关于模型,我们主要考量有两点,第一能够适应较大的样本量,第二是能够自适应地控制过拟合,因为样本不均衡容易带来严重的过拟合,还有一点是希望模型超参数够少,尽量避免人工调参。

我们测试过三种模型

第一个是IsolationForest,这是一种常用的异常检测模型,但由于它对局部异常不敏感,在这个问题上表现欠佳

第二个是随机森林,作为一种集成模型,总体表现很稳定,泛化能力也不错,实测结果略低于DNN

最终的选择方案是深度学习模型,主要考虑到模型有足够的表达能力,能适应大数据,泛化能力强。实测下来,表现也是非常的好。
这里写图片描述
这是我们最终使用的深度模型,有两个全连接隐层和一个Sigmoid输出层,两个隐藏神经元数量都是128。通过Dropout和L1正则化控制模型的过拟合,以增强泛化能力。

DNN输出数据点的异常概率,再通过阈值进行二分类。阈值如何确定呢?以F-Score作为评估标准,通过网格搜索的方式确定最优阈值。这里使用阈值的目的主要是为了修正样本不均带来的偏斜。
这里写图片描述
普适性上,我们做到了以下几点:

• 通用:在竞赛中,所有KPI的异常检测都能通过一套框架来解决,这套方案也可以很容易地推广到类似的场景和问题,且容易实现和维护。

• 自动:整套流程无需人工介入,算法模型有较高的自适应能力

• 性能:对于普通监控数据(分钟级采样),单个KPI的模型训练时间在3分钟以内(单机,单GPU),流处理情况下单数据点检测时间在毫秒级,基本满足生产环境需求。

• 稳定:在不同数据集上,算法的评估分数非常一致和稳定
这里写图片描述
最后来看一下这套算法方案的评估结果,上图列出了算法在预赛训练集、预赛测试集以及决赛测试集上的F-Score得分,在三个不同数据集上,得分稳定在0.8左右,表现非常稳定,有不错的泛化能力。
这里写图片描述
在测试集标注公开以后,我们对算法的误报、漏报情况做过分析,发现目前还存在这样一些不足:

• 有些异常模式只存在于测试集中,模型无法从训练集中学习出该模式,这类异常容易出现漏报

• 部分异常在局部不明显,只能通过周期同比的方式发现,这类也容易出现漏报

针对这些问题,我们后续计划从以下几点对方案做进一步的优化

• 引入周期或时间相关的特征,比如周期同比、星期、小时等维度,用于发现这类维度上异常

• 集成无监督模型,以适应异常样本极度稀少或分布不均的情况

• 提供集成业务规则的能力,以支持业务规则下的异常检测

4.总结

本文以AIOps挑战赛为背景,介绍了LogicMonitor-AI团队对异常检测的理解和思考,分享了详细的算法方案。该方案通用性强,高效且算法表现稳定,适用于有标注的KPI异常检测问题。

猜你喜欢

转载自blog.csdn.net/daydayup_668819/article/details/80894023