论文解读:Rapid Deployment of Anomaly Detection Models for Large Number of Emerging KPI Streams

摘要

为了保证服务的可靠行,基于Internet的服务会时刻监视和检测其应用或系统中KPI流的异常。本文的主旨就是提出一个:为大量新兴KPI流快速部署异常检测的模型,此模型不需要人工选择算法、调整参数、或为每一个新出现的KPI流添加标签。
一个框架:ADS,通过聚类+半监督学习的方法解决上述问题

一些名词解释

系统的KPI: 关键性能指标,比如CPU利用率,每秒查询数,响应延迟等
KPI上的异常: KPI流中的尖峰或下降,可能表明因特网服务的潜在故障,比如服务器故障,网络过载,外部攻击,并且应该准确且快速地检测到。
CPLE: 一种半监督学习的算法,contrastive pessimistic likelihood estimation

介绍

  1. 为了避免假警报或者错过警报的情况,为了避免影响用户体验,Internet服务运营商需要一个异常检测模型,时刻检测KPI流的变动。
  2. KPI流大量涌现的原因
  3. 对于传统算法,为达到较好精度,需要为每一个KPI流手动选择算法、调整参数
    对于监督学习,需要为每一个KPI流人工标记异常
    对于无监督学习,精度低,或者需要大量训练数据
  4. ADS,一个框架,规避以上缺点,基于两个观察
    (1) 许多KPI流具有隐含的关联和相似性,可用相似的算法和参数
    (2) ROCKA聚类方法可被用来根据其相似性进行集群
  5. ADS提出几点:
    (1) 将所有已经存在的KPI流聚类
    (2) 为所有聚类质心人工标记
    (3) 将每一个新出现的KPI流分配到已经存在的聚类中
    (4) 结合未标记的新KPI流的数据和它已标记的集群质心,使用半监督学习为每个新的KPI流训练一个新模型。
  6. ADS优势:既拥有监督学习的所有优点,同时只需要标记极小部分的历史KPI流

本文贡献总结

  • 本文首次确定了为大量新兴KPI流快速部署异常检测模型的常见且重要的问题,无需手动算法选择,参数调整或标记任何新生成的KPI流异常,并提出解决此问题的第一个框架ADS。
  • 采用稳健的半监督学习模型CPLE,其适用于KPI异常检测,并且仅需要现有标记KPI流与新KPI流之间的类似数据分布。
  • 使用70个历史KPI流和81个新KPI流进行了大量实验。通过70个历史KPI流的仅5个群集质心的标签,ADS在81个新的KPI流上实现了平均最佳F-score =0.92,与最先进的监督方法几乎相同,并且大大优于无监督方法Isolation Forest和最先进的无监督算法 Donut。

KPI流异常检测模型介绍

1. KPI流模型

异常KPI流展示如下图:

时间与KPI值的图像
时间与KPI值图像

  • 计算时间点的KPI值,设置阈值,根据KPI值是否超过阈值来判定该时间点是否异常;
    可以看到KPI异常检测实际上是一个二分类问题,本文选择F-score来评价异常检测算法

  • 应用于KPI流的传统算法:SVD, Wavelet,ARIMA,Time Series Decomposition ,
    Holt-Winters等

  • 应用于KPI流的监督学习算法:EGADS, Opprentice

  • 应用于KPI流的无监督学习算法:isolation based method, VAE(Donut)

  • 半监督学习算法使用未标记的数据来修改参数和模型,以最大限度提高性能

2. KPI流的聚类
  • 采用ROCKA聚类算法

ADS框架:

  • 对于历史KPI流,ADS使用填充缺失点和标准化对它们进行预处理,使用ROCKA对预处理的KPI流进行聚类,并在聚类质心上为KPI流提取特征(即,不同异常检测算法和参数的输出结果)
  • 当生成新的KPI流时,ADS对其进行预处理,并将其分类为上述群集之一,之后提取此新KPI流的特征。
  • 基于新KPI流的特征,以及新KPI流的聚类质心的特征和标签,ADS使用CPLE算法训练半监督学习模型。
  • 最后,ADS根据上述模型和严重性阈值(aThld)检测新KPI流中的异常。
1. 预处理和聚类
  • 使用线性插值来填充KPI流上的缺失点(可能因为机器故障或者错误配置产生的)
  • 标准化KPI流(为了使不同的KPI流具有可比性)
  • 采用ROCKA进行聚类,并且获取每个聚类的质心KPI流
2. 特征提取
  • 基于历史数据进行训练:由于每个聚类质心上的KPI流表示其整体的特征,因此我们在每个聚类质心上提取KPI流的特征。
  • 基于新数据进行训练:我们提取新生成的KPI流的特征(新KPI流的特征,新KPI流的聚类质心的特征和异常标签共同构成了训练集)。
  • 如何提取特征
    1. 使用不同异常检测器的输出结果作为KPI流的特征
    2. 当向异常检测器中输入一个值,在其内部就会产生一个称为严重性的非负值
    3. 检测器和其内部的参数共同决定了给定数据点的严重性。
    4. ADS中的特征提取,训练和分类都用于处理单个数据点,因此半监督学习算法可以有足够的数据用于训练。
3. 半监督学习算法
  • 采用CPLE,一种自我训练的扩展模型。 是一个适用于任何监督学习分类器的弹性半监督学习框架,它将基础模型的预测概率作为输入来充分利用未标记的数据。
  • 优点: 灵活、空间复杂性低、强大、精确、支持增量学习

    在这里插入图片描述
    二元分类的负对数损失
4. 阈值的调整
  • 通过半监督学习,获得了一个异常检测模型之后,为了衡量数据点的异常程度,ADS为每一个新出现的KPI流中的数据点,计算一个非负的值;ADS基于阈值和该非负值的关系,决定一个点是否是异常点。
  • 如果我们设定一个默认的阈值,ADS就面临着低精度的问题
  • 一个监督学习的异常检测模型的训练是基于KPI流的,阈值根据F-Score和训练集得到,F-Score兼顾了精度和召回率的问题,阈值是使训练集中的F-Score最大化的值。
  • 一个无监督学习,训练集中的KPI流没有标签,因而我们无法计算任何F-Score,这时,一个elbow point 通常用于设置严重性阈值。
  • ADS基于F-Score和已标记的KPI流来设置阈值。换句话说,aThld是使质心KPI流中F-Score最大化的值。

评测

1. 数据集
  • 重要的三支KPI流:成功率、在线玩家、延迟
  • 运营商将70个历史KPI流手工分为5个聚类,继而将新的81个KPI流分配到五组之中
2. 评价指标
  • 一个简单的策略:如果可以通过选择的阈值检测到真实情况中异常段的任何点,我们就能正确检测到该段,并且该段中的所有点都被视为可以依照次阈值检测到它们。同时,异常段外的点照常处理。

  • 采用F-score作为评价异常检测模型的指标

  • 使用81个新KPI流的:

      前60%进行特征提取和人工标记聚类质心        
      后40%进行ADS检测
    
3. 性能评估
  • 将ADS与iForest、Donut、和Opprentice进行比较
  • 绘制CDFs
  • ADS和Opprentice有更好的性能;但是Opprentice是监督学习算法,需要更多的标记工作,人工进行不现实
4. CPLE评价
  • 采用强大的半监督学习模型CPLE,适用于KPI异常检测,并且仅需要现有标记KPI流和新KPI流之间的相似的数据分布
  • 使用ADS(CPLE+ROCKA)与模型(ROCKA+Opprentice)进行比较,应用于每一个质心KPI流
  • ADS优于(ROCKA+Opprentice);因为ROCKA通常只是提取KPI流的基线却忽略其波动,ADS不仅从质心KPI流的标签中学习,还从波动中学习。

原文链接:Rapid Deployment of Anomaly Detection Models for Large Number of Emerging KPI Streams

Artifact deployment error in test1:war typically occurs when there's a problem while deploying a WAR (Web Application Archive) file to a server, such as Apache Tomcat or a similar web application container. This error usually indicates that the server is unable to complete the deployment process due to various reasons, which might include: 1. Invalid or missing dependencies: The WAR file may be dependent on other libraries that are not present in the server's classpath. 2. Configuration issues: Incorrect server configuration, like incorrect context path, servlet mapping, or security settings, can lead to deployment errors. 3. Class loading problems: If there's a conflict between classes or resource files within the WAR, it could cause issues. 4. Server resource limitations: Insufficient memory or disk space, or reaching max number of deployed applications, can prevent successful deployment. 5. Runtime exceptions: There could be a runtime issue in the application code that surfaces during deployment. To resolve this error, you should check the server logs for detailed information about the specific error, which will usually provide more context and steps to fix the issue. Here are some steps to troubleshoot: 1. **Review server logs**: Look for stack traces, error messages, or warnings that can guide you to the root cause. 2. **Check the deployment descriptor**: If you have a `web.xml` file in your WAR, verify that all configurations are correct. 3. **Maven dependencies**: Ensure that all necessary libraries are included and have compatible versions. 4. **Clean and redeploy**: Try cleaning the server's work directory or undeploying the problematic application before redeploying. 5. **Run tests locally**: If possible, deploy the application locally using a development server to isolate the issue from the production environment.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值