当前位置：首页 > news >正文

《异常检测——从经典算法到深度学习》30. 在线服务系统中重复故障的可操作和可解释的故障定位

news 来源：原创 2025/6/30 16:31:45

《异常检测——从经典算法到深度学习》

0 概论
1 基于隔离森林的异常检测算法
2 基于LOF的异常检测算法
3 基于One-Class SVM的异常检测算法
4 基于高斯概率密度异常检测算法
5 Opprentice——异常检测经典算法最终篇
6 基于重构概率的 VAE 异常检测
7 基于条件VAE异常检测
8 Donut: 基于 VAE 的 Web 应用周期性 KPI 无监督异常检测
9 异常检测资料汇总（持续更新&抛砖引玉）
10 Bagel: 基于条件 VAE 的鲁棒无监督KPI异常检测
11 ADS: 针对大量出现的KPI流快速部署异常检测模型
12 Buzz: 对复杂 KPI 基于VAE对抗训练的非监督异常检测
13 MAD: 基于GANs的时间序列数据多元异常检测
14 对于流数据基于 RRCF 的异常检测
15 通过无监督和主动学习进行实用的白盒异常检测
16 基于VAE和LOF的无监督KPI异常检测算法
17 基于 VAE-LSTM 混合模型的时间异常检测
18 USAD：多元时间序列的无监督异常检测
19 OmniAnomaly：基于随机循环网络的多元时间序列鲁棒异常检测
20 HotSpot：多维特征 Additive KPI 的异常定位
21 Anomaly Transformer: 基于关联差异的时间序列异常检测
22 Kontrast: 通过自监督对比学习识别软件变更中的错误
23 TimesNet: 用于常规时间序列分析的时间二维变化模型
24 TSB-UAD：用于单变量时间序列异常检测的端到端基准套件
25 DIF：基于深度隔离林的异常检测算法
26 Time-LLM：基于大语言模型的时间序列预测
27 Dejavu: Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems
28 UNRAVEL ANOMALIES：基于周期与趋势分解的时间序列异常检测端到端方法
29 EasyTSAD: 用于时间序列异常检测模型的工业级基准
30 在线服务系统中重复故障的可操作和可解释的故障定位

30. Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems

在这里插入图片描述

论文名称：Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems
会议名称：ESEC/FSE 2022
论文地址：ieee | 阿里云盘 | netman |
PPT 下载：https://netman.aiops.org/wp-content/uploads/2022/11/DejaVu-slides.pdf
源码地址：https://github.com/netmanaiops/dejavu

30.1 论文概述

在现代在线服务平台中，由于系统的复杂性和规模庞大，故障不可避免地发生，导致巨大的经济损失和用户不满。为了解决这一问题，研究者们开发了一种名为DéjàVu的方法，旨在为反复出现的故障提供可操作且可解释的故障定位。该方法不仅能够告知工程师故障发生的位置（即有故障的组件），还试图确定故障的具体类型（如内存泄漏）。通过直接分析监控指标，DéjàVu能够在多个真实世界数据集上实现高效准确的故障定位。

论文提出，在实际工业实践中，经验丰富的工程师通常基于系统知识和历史故障经验，针对重复出现的故障进行定位。这种方法虽然可操作且可解释，但高度依赖人工，速度慢且可能不准确。因此，论文旨在通过机器学习自动化这一过程，提出一种名为Déjà Vu的方法，针对在线服务系统中的重复故障进行可操作且可解释的故障定位。

论文脑图：
在这里插入图片描述

30.2 背景与相关技术

30.2.1 背景介绍

1. 在线服务系统的重要性：举例说明在线服务系统在日常生活中的重要性。
在这里插入图片描述
2. 在线服务系统的复杂性导致错误发现与分析任务变得困难

30.2.2 相关技术介绍

前面提到了在线服务系统的背景（抛出问题），这里开始介绍当前的主要解决方法：

1. 24 x 7 的指标监控系统：对于不同的层级进行相应的指标监控，并依据监控结果来定位问题。
在这里插入图片描述
2. 重复出现的故障：图中总结了几个常见的重复故障原因，并且抛出了核心问题：如何检测重复出现的故障？

这里主要强调：反复出现的故障在实践中普遍存在。

30.3 核心方法

结合PPT截图，上文已经抛出了论文的核心问题：如何检测现在系统中重复出现的故障。

本节内容介绍本论文提到的核心方法。

30.3.1 方法描述

本文提出的De’JaVu模型是一种针对在线服务系统故障诊断的深度学习模型。该模型通过历史故障数据和FDG（故障分布图）来预测当前故障可能的故障单元，并给出相应的可疑分数。具体来说，该模型包括三个主要模块：特征提取器、特征聚合器和分类器。其中，特征提取器使用GRU神经网络和 1D-CNN等技术来提取时间序列数据中的时空信息；特征聚合器则利用注意力机制和多层图神经网络来对相关故障单元进行聚合；最后，分类器使用密集神经网络来进行二元分类。

30.3.2 DejáVu模型的工作流程

如下图所示，首先，该模型需要历史故障数据和相应的故障图来训练。在训练过程中，模型会从历史故障数据中学习到故障模式，并将其表示为固定长度的向量。然后，当一个新的故障事件发生时，模型会将当前的故障图和相关的指标值输入到模型中，模型会对每个故障单元进行评分，并输出最有可能的故障单元和其对应的故障类型。整个过程可以看作是一个端到端的学习和推理过程，能够有效地自动化故障诊断的过程。

其中，图中左边部分提到：监控系统的指标出现故障时，报警（Alerts）作为触发器（Trigger）来触发整个模型的工作流程。

在这里插入图片描述

30.3.3 DejáVu 模型架构

如下图所示，从左往右，模型主要模块与工作流程可以概述如下：

故障单元的指标 -> 特征提取器：：前文已经介绍由监控系统中的故障指标触发整个流程，第一个步骤是根据指标数据，提取相关特征；
特征提起器 -> 单元级别故障特征：这里可以理解为一个归类过程，将所有故障特征根据 unit 进行划分，不同的 unit 对应的十不同的单元特征。
单元级别故障 -> 特征聚合器：特征聚合器则将所有故障单元的特征向量进行编码，以便于建模故障传播关系。
特征聚合器 -> 分类器 分类器根据聚合后的特征向量对每个故障单元进行分类，以确定最可能的故障位置和类型。
分类型 -> 评分：计算分数并选择最佳故障单元：在这个阶段，模型使用分类器对每个故障单元进行打分，并选择得分最高的作为最终预测结果。

在这里插入图片描述

30.4 核心组件详情

本章的内容主要与论文的 3.2 ~ 3.6 节相对应。

30.4.1 特征提取器（Feature Extractor）

该模块的主要任务是学习故障单元的时间序列特征，并捕捉不同指标之间的相关性。为了实现这一目标，该模块采用了三阶段特征提取方法。第一阶段利用门控循环神经网络（GRU）模型来学习故障单元的时间序列特征。输入指标被表示为一个固定长度的时间窗口内的数值矩阵，其中时间窗口的长度在实验中被设置为 20 分钟。第二阶段应用了一维卷积神经网络（1-D CNN）和高斯误差线性单元（GELU）激活函数来进一步处理时间序列特征矩阵，提取不同时间点和指标之间的相关性。第三阶段采用全连接层来学习不同特征映射之间的关系，并输出一个表示故障单元的单位级特征向量。这些特征向量将作为后续特征聚合器的输入，以进一步建模故障传播关系。总之，特征提取器模块通过多阶段的学习过程，能够有效地从故障单元的时间序列数据中提取有用的特征信息，为后续的故障定位提供有力支持。

30.4.2 特征聚合器（Feature Aggregator）

该模块的任务是在整个系统架构图上对每个故障单元及其相关特征进行编码，以便更好地建模故障传播关系。具体来说，在训练过程中，对于每个历史故障事件，特征聚合器会将其对应的故障单元及其相关特征向量传递给全局特征聚合器。全局特征聚合器会对所有故障单元的特征向量进行聚合，得到一个表示整个系统状态的全局特征向量。然后，全局特征向量会被传递到分类器中，用于预测当前故障单元的类型。在推理过程中，当一个新的故障事件发生时，特征聚合器会将其对应的故障单元及其相关特征向量传递给全局特征聚合器，同样地，全局特征聚合器会对所有故障单元的特征向量进行聚合，得到一个表示整个系统状态的全局特征向量。这个全局特征向量可以用来判断当前故障是否属于已知类型的故障，从而快速诊断故障并给出相应的解决方案。总的来说，特征聚合器模块通过将故障单元的特征向量进行聚合，实现了对整个系统状态的有效建模，提高了故障定位的速度和准确性。

30.4.3 分类器（Classifier）

该模块的任务是根据输入的全局特征向量，对每个故障单元进行分类，并输出其可疑度得分。具体来说，在训练过程中，分类器会接收全局特征向量作为输入，并学习如何将其映射到各个故障单元的类别概率分布上。在推理过程中，分类器会接收新的全局特征向量作为输入，并输出每个故障单元的可疑度得分。这些得分可以按照从高到低的顺序排列，工程师可以根据排名情况逐个检查可疑度较高的故障单元，从而快速定位故障原因。总的来说，分类器模块通过学习全局特征向量与各个故障单元之间的关系，实现了对故障单元的自动分类和可疑度评估，提高了故障定位的效率和准确性。

这里摘录论文公式如下，其中 $\hat{f}^{(v)}$ 表示故障单元 $v$ 的聚合特征， $\sigma$ 表示输出层的激活函数，两个Dense 表示普通的神经网络层

$(\sigma \circ \text{Dense} \circ \text{GELU} \circ \text{Dense}) (\hat{f}^{(v)}) \tag{1}$

30.4.4 损失函数（Loss Function）

本小节在损失函数方面，论文采用了二元交叉熵作为损失函数。具体来说，他们将可疑度得分与实际标签进行比较，并根据差异来更新模型参数。为了避免正常单元被错误地赋予高可疑度得分，作者还引入了一些技巧来平衡正常单元和故障单元的权重。总的来说，这种损失函数的设计使得模型能够快速而准确地识别出故障单元，并给出相应的可疑度得分。

30.4.5 类别均衡 Class Balanci

本小节作者提到由于不同故障类别的频率可能会有所不同，因此需要对训练数据进行类别平衡处理。具体来说，他们采用的方法是在每次迭代时随机选择一些正常单元和故障单元，并且确保它们的数量大致相等。这样做的目的是为了防止模型过于关注某些特定的故障类别，从而导致其他类别的性能下降。通过这种方式，作者成功地提高了模型的泛化能力和鲁棒性，使其能够在实际应用中更加可靠地进行故障定位。

30.5 源码运行

本节主要是帮助没有代码基础，不太会部署与运行源码的同学。

这里强烈建议各位小伙伴们使用 docker 部署这个项目。

30.5.1 下拉镜像

$ docker pull lizytalk/dejavu

在这里插入图片描述
等待一段时间，拉镜像完成以后，即可开始下一步操作。

30.5.2 启动容器

如果电脑不含显卡，则运行下面的命令即可。

$ docker run -it --rm -v F:\\dejavu:/workspace lizytalk/dejavu bash

如果电脑含有显卡，请运行下面的命令，使用显卡来运行项目会快一些。
在这里插入图片描述

$ docker run --gpus all -it --rm -v  F:\\dejavu:/workspace lizytalk/dejavu bash

30.5.3 下载或者 clone 源码到 workspace 目录下

这里的 workspace 是上一行命令中指定的目录，需要根据实际情况来定。

30.5.4 下载数据集，并解压到指定的位置

前往 https://www.dropbox.com/scl/fo/otvnxp4j5jl5e8myh5sop/AHKvJsGU2-sNMRjNkn87_Fo?rlkey=znxsescrsyl5m7g9lvv3fvnjq&e=1&dl=0 下载数据集，可以考虑只下载一个数据集压缩包先跑着试试。

解压到 ./DejaVu/data 目录下，注意，如果刚刚克隆下来的项目名字叫做 dejavu，那么它的绝对路径是 workspace/dejavu/DejaVu/data。

30.5.6 根据作者的提示，执行相关脚本即可进行实验

在这里插入图片描述

30.6 总结

文章优点
本文提出了一种针对在线服务系统中频繁出现的故障问题的可操作性和可解释性的故障定位方法De’JaVu。该方法利用历史故障数据训练模型，并通过连接故障单元构建故障依赖图来考虑复杂的依赖关系。实验结果表明，De’JaVu在识别故障单元方面具有较高的准确率和效率，并且能够处理以前未见过的故障情况。此外，文章还提供了两种可解释的方法，以帮助工程师理解模型的决策过程。

方法创新点
De’JaVu采用了新颖的深度学习模型，结合了故障单元之间的依赖关系，使得模型可以更好地捕捉复杂的关系。同时，作者提出了两种可解释的方法，即基于历史故障推荐相似故障和基于规则集的全局解释，以便工程师更好地理解和使用模型。

Smileyan
2025.04.01 00:08