《异常检测——从经典算法到深度学习》27 可执行且可解释的在线服务系统中重复故障定位方法

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

  • 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

相关:

  • VAE 模型基本原理简单介绍
  • GAN 数学原理简单介绍以及代码实践
  • 单指标时间序列异常检测——基于重构概率的变分自编码(VAE)代码实现(详细解释)

27. 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
下载地址:netman
源码地址:github
数据集:https://www.dropbox.com/sh/ist4ojr03e2oeuw/AAD5NkpAFg1nOI2Ttug3h2qja?dl=0
https://doi.org/10.5281/zenodo.6955909

在线服务系统中重复故障的可操作和可解释故障定位
在这里插入图片描述

27.1 论文概述

本节主要回答三个问题,论文想解决什么问题,使用什么方法,从理论上回答为什么能解决问题。

27.1.1 背景知识:论文要解决什么问题

论文旨在解决 在线服务系统中 1 ^1 1 重复故障的可操作和可解释故障 2 ^2 2 定位问题 3 ^3 3,通过自动化和机器学习方法改进现有的依赖于人工经验和知识的工业实践,克服现有方法在处理大量多样监控数据与复杂组件依赖时的局限性,以及无法满足工程师对定位结果操作性和解释性的需求。

从论文标题中已经给出这个问题的答案,但结合摘要内容可以概述如上。主要可以分为三个模块,即在某场景中,出现的某类型的故障,现在我们需要定位这个故障。(分别对应前面的右上角表示 1 2 3)。

27.1.2 主要方法:论文使用了什么方法来解决问题

论文提出了名为DejaVu的方法来解决在线服务系统中反复出现故障的自动化和可解释性定位问题。DejaVu通过以下步骤实现:

  1. 利用历史故障数据和系统内部依赖关系,在离线阶段训练故障定位模型。
  2. 对于新发生的故障,DejaVu 在线实时推荐可能故障的位置(故障组件)和故障类别(一组指示性指标),指导工程师采取补救措施。
  3. 为了统一表示不同数量度量指标的故障单元并解决特征工程难题,引入了一个能够捕获度量指标的时间序列信息和相关性的特征提取模块。
  4. 使用基于图注意力网络(GAT)的特征聚合器,将故障依赖图(FDG)中的结构信息编码成聚合特征,以模拟故障传播过程。
  5. 通过一个分类器根据每个故障单元的聚合特征给出可疑得分,以便确定最可能的故障源头。
  6. 采用经过修订的损失函数训练模型,并考虑类平衡策略以应对训练数据中各类故障频率不均的情况。

更多明细我们在后面内容中介绍(主要是基于图5中的 workflow 而展开)。

27.1.3 理论解释:为什么此方法可以解决该问题

论文通过以下几个方面来解释DejaVu方法的有效性:

  1. 实验验证:研究人员在四个数据集上对DejaVu进行了广泛的测试,其中包括基于真实世界的系统数据集,涵盖了总共601个故障案例,其中有99个真实的生产环境故障。实验结果显示,DejaVu在定位故障单元方面的平均排序成绩(MAR)达到了1.66至5.03之间,显著超越了基准方法,提高幅度在54.52%至97.92%之间。

  2. 模型组件贡献分析:实验表明DejaVu中诸如特征提取器和基于图注意力网络(GAT)的聚合模块等主要部分确实发挥了积极作用,对整体性能有所贡献。

  3. 可操作性评估:DejaVu能够在接收到故障时迅速推荐故障发生的位置以及故障的具体类型,使得工程师能够及时识别潜在的故障原因,并立即采取措施减轻故障影响,从而保障软件服务的质量。

  4. 可解释性展示:针对模型预测结果的可解释性,论文提出了两种解释方法。一种是在故障依赖图(FDG)上找到代表性的历史故障案例,揭示模型可能从中学习到做出当前故障推荐的原因。另一种则是模仿决策树的形式将训练好的模型转化为人类可读的规则,全局解读模型的工作机制。

  5. 性能稳定性与通用性:DejaVu不仅在已知故障上有优秀表现,对未曾遇到过的故障也能取得类似的效果,这体现了模型的良好泛化能力。同时,考虑到在线服务系统频繁的变化和更新,论文提到DejaVu支持周期性重新训练以适应变化,并能在新的故障场景下使用新的故障单元定义。

  6. 有效性衡量指标:采用了如前 k 准确率(A@k)和平均平均排名(MAR)等广泛使用的评价指标,量化地证实了DejaVu在故障定位任务上的有效性。其中A@k测量的是在前k个推荐中包含正确故障答案的比例,而MAR则反映了诊断一个故障平均需要检查多少个推荐项,数值越小说明定位效率越高。

27.2 论文结构

章节编号章节标题简要内容
摘要概述了在线服务系统中故障定位的挑战,提出DejaVu方法,旨在自动化并增强对重复故障的定位效果,使之既可操作又可解释。
1. 引言描述了故障定位的重要性,尤其是针对频繁重现的故障,并引出当前业界手动实践的问题和改进目标。
2. 背景与问题定义
2.1问题背景描述了在线服务系统中故障的重复性质及其普遍性,强调从历史故障中学习诊断价值。
2.2故障单元与故障依赖图(FDG)定义定义了故障单元的概念,以及FDG如何描绘组件间的依赖关系和故障传播途径。
2.3问题陈述明确了本研究的目标:给定最新的FDG和对应指标值时,推荐出故障所在的故障单元。
3. DejaVu模型设计
3.1概览展示DejaVu模型的整体架构,输入为故障时间点的度量指标和FDG,输出为每个故障单元的可疑评分。
3.2特征提取器解释如何通过一维卷积神经网络和GELU激活函数处理时间窗口内的度量矩阵,生成固定维度的单元级特征向量。
3.3特征聚合器描述了如何利用图注意力网络(GAT)动态计算关联故障单元的聚合权重,模拟多跳故障传播,形成聚合特征。
3.4分类器讲述如何基于聚合特征对故障单元进行打分,以此判断故障的可能性。
3.5损失函数与优化介绍模型训练时采用的修订损失函数以及为应对类别不平衡问题采取的类平衡策略。
4. 实验与结果报告了DejaVu在不同数据集上的性能对比、效率分析以及对模型参数影响的研究。
5. 结论与未来工作总结DejaVu在各种情况下的优秀性能,讨论其实效性和可解释性,并展望未来改进方向。

27.3 相关技术

先看一下图2,这里介绍了各个部分之间的关系。
在这里插入图片描述

27.3.1 Monitoring Metrics

如下图所示,监听指标过程从上往下可以概述为:

  1. 用户端提交请求(比如某个业务上,可以点击按钮,发送http请求等);
  2. 服务端接收请求,各种服务之间存在相互调用的关系等;
  3. 相关容器以及处理器,比如磁盘单元,内存单元,CPU 单元等;
  4. 基础组件,网络、存储、处理器单元等。

整个流程中将会产生非常多的指标,并且这些指标之间存在一定的拓扑关系。也就是我们接下来要将的故障依赖图(FDG)

在这里插入图片描述

27.3.2 Recurring Failures

Recurring Failures 指的是在线服务系统中重复发生的同类故障,这些故障并非偶然事件,而是具有一定规律性地在不同时间、不同地点以相似的方式反复出现。
在这里插入图片描述
论文分析了一个生产银行信息系统的576张故障单,时间跨度为一年。
在这里插入图片描述

27.3.3 FDG (failure dependency graph)

前面有提到各个组件、各个服务、服务与组件之间存在依赖关系,这里定义的FDG图与此有关,具体定义如下:
在这里插入图片描述
大概可以理解为 FDG \text{FDG} FDG 是一个无向图,记作 G = ( V , E ) G=(V,E) G=(V,E),其中 V V V 是在线服务系统的所有定义的候选故障单元的集合。其中相互依赖的边 ( v i , v j ) (v_i, v_j) (vi,vj) 组成集合 E E E

比如论文提到的例子如 图3 所示:
在这里插入图片描述
例如,系统 A 仅包括27个组件,这是复杂的(见表1)。在图3中,由于服务部署在 Docker6上,Docker上CPU耗尽导致的故障传播到服务请求。它进一步传播到服务1请求、服务2请求和OSB1请求,因为服务1和服务2依赖于服务,而osbi依赖于这两个服务。

论文采用自动构建 FDGs 方法,因为 FDGs 是复杂和动态的(例如,在微服务系统中,pod 是动态创建和删除的),基于调用和部署组件关系。例如,在 sysA 。我们通过跟踪工具(图4中最左边的图)收集OSBS、服务和数据库之间的调用关系,并通过配置管理数据库收集服务、容器和服务器之间的部署关系。通过组合组件关系和故障单元,我们自动构建 FDG。例如,当Service 1部署在Docker1 上时(见图4),Service1 请求连接到 Docker1 CPU / Memory(见图3)。此外,工程师可以根据自己的领域知识和现有的诊断知识手动添加或删除FDG上的边。例如,当两个服务依赖于一个有状态的第三方服务(无法通过跟踪捕获)时,工程师可以在 FDGs 上手动连接它们。
在这里插入图片描述

27.3.4 Problem Statement

在这项工作中,我们的目标是在故障发生时,在给定最新FDG和相应度量值的情况下,推荐故障单元。故障故障单元精确定位故障发生的位置(部件)和发生的故障类型(由指标指示),从而帮助工程师迅速采取正确的缓解措施。寻找故障单元或 FDG 的最有用的规范和故障发现不在本文的范围内。

27.4 核心方法

27.4.1 Workflow of DejaVu

从论文图5 中可以大致看一下 DejaVu 的大致流程。
在这里插入图片描述
Dejavu的流程主要包括以下几个步骤:

  1. 数据准备:收集在线服务系统的历史故障数据,包括过去发生的故障实例及其相关的监控指标、日志、调用链等信息。同时,构建系统的故障依赖图(FDG),该图描绘了系统中各组件之间的依赖关系,以及故障如何在这些组件间传播。

  2. 模型训练:利用历史故障数据和FDG作为输入,进行离线训练。训练过程中,Dejavu模型学习如何从故障单元的度量指标和其在FDG中的相对结构信息中识别出故障的模式和特征。

    • 特征提取:对每个故障单元的度量指标进行处理,提取出能够反映故障状态的时间序列特征。
    • 特征聚合:利用图注意力网络(GAT)对故障单元之间的关系进行建模,通过多跳传递信息,模拟故障在系统中的传播过程,并生成聚合后的特征。
    • 分类器:基于聚合后的特征,对每个故障单元进行可疑度评分,确定其是否为潜在故障源。

    采用修订的损失函数进行模型优化,并考虑到故障类别间的不平衡性,采用类平衡策略确保模型对各类故障的识别能力。

  3. 在线故障诊断:当在线服务系统中出现新的故障时,Dejavu模型接收当前故障时刻的度量指标数据和最新FDG,快速做出如下决策:

    • 故障定位:根据模型预测,推荐出最可能的故障发生位置,即故障组件
    • 故障类型识别:识别出此次故障所属的指示性度量指标组,即一组与故障类型密切相关的系统指标,提供故障的初步诊断信息。

    这些诊断结果为工程师提供了直接的行动指南,即应关注哪些组件以及应检查哪些指标以确认和解决问题。

  4. 结果解释与反馈:为了增强模型预测的可解释性和可信度,Dejavu提供了两种解释方法:

    • 局部解释:通过找出与当前故障相似的历史故障案例,揭示模型可能从中学习到的故障模式,帮助理解为何推荐特定故障单元。
    • 全局解释:将训练好的模型转换为人类可读的规则形式(如决策树),直观展示模型的推理逻辑。

    工程师根据模型推荐和解释,采取相应措施进行故障排查和修复。在故障得到解决后,将人工确认的故障真相保存下来,用于未来模型的再训练和持续优化。

通过以上流程,Dejavu实现了对在线服务系统中重复故障的自动化、可执行且可解释的定位,极大地提高了故障诊断的效率和准确性,减轻了工程师的工作负担,促进了系统故障的快速响应和有效管理。

27.4.1 Overview

各个章节的概述前面表格中已经罗列,这里我们只含论文翻译。

在这里插入图片描述

如图 6 所示,DejaVu 模型以故障时间前后的度量值和FDG作为输入,并使用二进制分类器输出每个故障单元的可疑分数。请注意,不同的故障可能具有不同的相应FDG

更具体地说,首先,为了解决统一表示故障单元的挑战,我们引入了一个特征提取器模块,该模块可以掌握度量的时间信息和度量之间的相关性(原论文 §3.2)。训练特征提取器以将相同故障类别的任何故障单元的度量映射到固定宽度向量(单元级特征)中。我们为每个故障类别训练一个故障提取器,因为不同故障类别的故障单元包含不同的度量。其次,为了能够对故障传播进行建模,我们使用特征聚合器将FDG上的结构信息编码为聚合特征(原论文 3.3)。特征聚合器利用注意力机制来更多地关注相关的故障单元。最后,我们引入了一个分类器,根据其聚合特征对每个故障单元进行评分(原论文 3.4)。为了通用性,同一故障类中的故障单元共享一个特征提取器,所有故障单元共享特征聚合器和分类器。对于不同的故障类,除了输入大小之外,它们的特征提取器都是相同的。这样,故障单元(例如,图3中的 Docker6 CPU)的得分主要由其度量值及其相关故障单元(如服务6请求、服务2请求、OSB1请求)的度量值决定,而不是由其位置决定。

我们的模型是通过最小化修正的损失函数(§3.5)来训练的。此外,我们采用类平衡进行训练,因为训练数据中每个失败类的频率各不相同(§3.6)。

27.4.2 Feature Extractor

故障单元的每个度量都具有时间信息,并且度量之间存在相关性。为了更好地提取有意义的特征,我们使用了三阶段特征提取方法。具体来说,第一阶段学习时间信息,而后两阶段学习更高层次的特征。

在第一阶段,使用门控递归单元(GRU)递归神经网络提取故障单元的时间特征。GRU是一种具有门控机制的递归神经网络,但与LSTM相比,其结构更简单,参数更少。故障单元的输入度量被编码为维度的数字矩阵 W × M v W \times M_v W×Mv , 其中 W W W 是我们在故障时划分的时间窗口的长度,以及 M v M_v Mv 是失败单元 v v v 的度量数。在本文中,我们根据经验设置 W W W 为 20分钟来捕捉度量的近历史。

在第二阶段,我们将一维卷积神经网络(1-D-CNN)和 GELU(高斯误差线性单元)激活函数应用于第一阶段获得的时间特征矩阵。通过应用一维CNN,我们得到了多个特征图,提取了不同时间点和度量之间的相关性。GELU通过在正激活中保持线性并抑制负激活来提供非线性,同时缓解消失梯度问题。

在第三阶段中,应用全连通层来学习在第二阶段中获得的不同特征图之间的关系,并输出维数为的数值单位级特征向量 Z Z Z.

27.4.3 Feature Aggregator

第二个模块,即特征聚合器,负责聚合故障单元的相关故障单元的单元级特征 v v v 并且基于 FDG G G G 将结构信息合并为一个聚合特征 f ^ ( v ) \hat{f}^{(v)} f^(v)。为了便于推广,特征聚合器应该是独立于结构的。因此,图卷积网络(GCN)是不合适的。由于任何一对故障单元之间的关系各不相同,因此也不适合像GraphSAGE 那样简单地将连接的故障单元的特征平均在一起。因此,对于每个故障单元,我们通过图注意力网络(GAT)基于其单元级特征动态计算其相关故障单元的聚合权重。

然而,单个 GAT 仅聚合故障单元的邻居的特征,而故障沿着 FDG 传播不止一跳(路径长度大于 1)。因此,我们将多个GAT依次堆叠在一起,最后一个GAT的输出被作为下一个GAT的输入。通过这种方式,我们聚合了进一步相关的故障单元的特征,从而对多跳故障传播进行建模。尽管多层图神经网络可能会受到过度平滑(over-smoothing)的影响,但我们应用残差连接来缓解这个问题[32]。另一方面,我们还引入了多头注意力,以提高能力并稳定训练过程。具体来说,我们并行应用多个GAT,并将它们的输出连接在一起。我们将顺序堆叠的GAT的数量表示为𝐿 头的数量为𝐻. 我们设置 H = 4 H = 4 H=4 L = 8 L = 8 L=8,并在 §5.3 中讨论其影响。为了通用性,所有故障单元都共享特征聚合器,而不考虑它们的类。总之,特征聚合器可以被形式化如下。

{ f ^ ( l + 1 , v ) ∣ v ∈ V } = [ GAT ⁡ ( { f ^ ( l , v ) ∣ v ∈ V } ) ; … ; GAT ⁡ ( { f ^ ( l , v ) ∣ v ∈ V } ) ] ⏟ H GATs in total  \left\{\hat{f}^{(l+1, v)} \mid v \in V\right\}=\underbrace{\left[\operatorname{GAT}\left(\left\{\hat{f}^{(l, v)} \mid v \in V\right\}\right) ; \ldots ; \operatorname{GAT}\left(\left\{\hat{f}^{(l, v)} \mid v \in V\right\}\right)\right]}_{H \text { GATs in total }} {f^(l+1,v)vV}=H GATs in total  [GAT({f^(l,v)vV});;GAT({f^(l,v)vV})]

其中 l ∈ { 0 , 1 , 2 , . . . , L − 1 } l \in \{0, 1,2,...,L-1\} l{0,1,2,...,L1} f ^ ( 0 , v ) : = f ( v ) \hat{f}^{(0,v)}:=f^{(v)} f^(0,v):=f(v) f ^ v : = f ^ ( L , v ) \hat{f}^{v}:=\hat{f}^{(L,v)} f^v:=f^(L,v) G A T ( ⋅ ) GAT(\cdot) GAT() 计算FDG中所有故障单元的聚合特征。

27.4.4 Classifier

最后一个模块,分类器,分配一个可疑的分数 s ( v ) s(v) s(v), 对于给定的每个故障单元其聚合特征 f ^ ( v ) \hat{f}^{(v)} f^(v)。具体地说,我们简单地使用两层密集神经网络,因为它已经足以实现令人满意的性能。为了限制输出在 [0,1] 之间,我们使用 sigmoid 函数 σ \sigma σ 作为输出激活函数。总之,对于故障单元 v v v 它的输出可疑分数(记作(s(v))的公式如下:

s ( v ) = ( σ ∘ Dense  ∘ GELU  ∘ Dense  ) ( f ^ ( v ) ) (1) s(v)=(\sigma \circ \text { Dense } \circ \text { GELU } \circ \text { Dense })\left(\hat{f}^{(v)}\right) \tag{1} s(v)=(σ Dense  GELU  Dense )(f^(v))(1)

我们不需要可疑分数的阈值来获得故障单元的二元分类。相反,我们只按可疑分数降序排列所有故障单元,工程师可以根据这些分数逐一检查可疑故障单元。

27.4.5 Loss Function

对于某个故障 T T T 中的每一个故障单元 v v v,我们期望可疑分数 s T ( v ) ∈ [ 0 , 1 ] s_T(v) \in [0,1] sT(v)[0,1] 尽可能接近其基本真相标签 r T ( v ) ∈ { 0 , 1 } r_T(v)\in \{0,1\} rT(v){0,1}。为了量化 s T ( v ) s_T(v) sT(v) r T ( v ) r_T(v) rT(v) 之间的差异,我们使用广泛使用的二进制交叉熵:

B C E ( r T ( v ) , s T ( v ) ) = r T ( v ) ⋅ log ⁡ ( s T ( v ) ) + ( 1 − r T ( v ) ) ⋅ log ⁡ ( 1 − s T ( v ) ) B C E\left(r_T(v), s_T(v)\right)=r_T(v) \cdot \log \left(s_T(v)\right)+\left(1-r_T(v)\right) \cdot \log \left(1-s_T(v)\right) BCE(rT(v),sT(v))=rT(v)log(sT(v))+(1rT(v))log(1sT(v))

由于大多数故障单元没有故障,因此与故障单元相比,它们的损失占主导地位。因此,该模型可能会倒退,对每个失败单元一视同仁。为了解决这个问题,我们给故障和正常故障单元分配不同的权重,使故障故障单元的权重等于所有正常故障单元的总和。具体来说,正常和故障故障单元的权重分别为 1 1 1 N N N (故障单元的数量)。

总之,

L S = 1 N H ∑ T ∈ { T 1 , ⋯ , T N H } [ ∑ v ∈ V w v ( T ) B C E ( r T ( v ) , s T ( v ) ) ∑ v ∈ V w v ( T ) ] (2) \mathcal{L}_S=\frac{1}{N_H} \sum_{T \in\left\{T_1, \cdots, T_{N_H}\right\}}\left[\frac{\sum_{v \in V} \boldsymbol{w}_v^{(T)} B C E\left(r_T(v), s_T(v)\right)}{\sum_{v \in V} \boldsymbol{w}_v^{(T)}}\right] \tag{2} LS=NH1T{T1,,TNH}[vVwv(T)vVwv(T)BCE(rT(v),sT(v))](2)

其中 V V V 是故障单元组成的集合, w v ( T ) = r T ( v ) ⋅ ∣ V ∣ + ( 1 − r T ( v ) ) ⋅ 1 \boldsymbol{w}_v^{(T)}=r_T(v) \cdot|V|+\left(1-r_T(v)\right)\cdot 1 wv(T)=rT(v)V+(1rT(v))1 { T 1 , … , T N H } \{T_1,\ldots,T_{N_H}\} {T1,,TNH} 是训练数据中失败单元组成的集合。基于历史故障最小化 L S \mathcal{L}_S LS,我们训练得到模型 DejaVu。

27.4.6 Class Balanc

在实践中,不同类别的故障数量各不相同。因此,为了防止 DejaVu 模型在训练过程中忽视样本数量较少的故障类型,我们增加了这些类的历史失败案例的样本。假设总共有 C C C 类故障类型,其中第 i i i 类的故障数目为 N H ( i ) N_H^{(i)} NH(i),我们每个训练步骤中采样故障的概率为 1 / ( C ⋅ N H ( i ) ) 1/(C\cdot N_H^{(i)}) 1/(CNH(i))。这样,每类的故障的被采样带的概率相等,即 1 / C 1/C 1/C

27.5 INTERPRETATION METH

第4部分介绍了DejaVu模型的两种解释方法,即全局解释和局部解释,以增强工程师对模型决策的信任和理解。这两种解释方法从不同角度提供了对故障定位结果的解读。

全局解释
全局解释的目标是使用简单且易于理解的模型(如决策树)来近似复杂黑盒DejaVu模型的决策过程。这些替代模型接收易于解释的时间序列特征作为输入,输出目标为DejaVu模型给出的可疑分数。选择这种方法的原因在于工程师更关心原始数据与故障根本原因之间的关系,而非深入理解模型内部机制。

具体实现时,首先从tsfresh库中选取易于理解的57个时间序列特征提取器,如范围计数和方差,它们能够为每个指标提取191个特征,每个特征代表该指标的一个可理解属性,如水平或方差。然而,单个故障单元的时间序列特征数量可能非常庞大(例如数千个),而DejaVu模型的特征维度则要低得多(例如3个)。因此,需要对这些原始特征进行选择,保留那些对模型预测有显著影响的特征。

为了构建决策树,将DejaVu模型提供的可疑分数分类为三种类别:高分(>0.9)表示故障故障单元,低分(<0.1)表示正常故障单元,中间值表示模型不确定。针对每种故障类别训练一个决策树,重点关注仅指向“故障”或“正常”故障单元的决策路径,这些路径即为DejaVu模型从历史故障中学习到的诊断规则。尽管决策树的性能低于DejaVu模型,且其解释也可能出错,工程师应关注决策条件的定性含义(如外部服务的成功率极低)而非具体阈值,以此辅助理解和信任DejaVu模型的决策。

局部解释
局部解释旨在揭示DejaVu模型如何通过学习历史故障来诊断给定故障。它通过比较新故障与历史故障在由训练好的DejaVu模型提取的聚合特征上的差异来实现这一目标。比较在故障类别层面进行,而非直接在故障单元层面,因为相似的故障可能发生在不同位置(从而具有不同的故障单元)。由于篇幅限制,这部分细节未在文中详述,但可以在相关代码中找到。

综上,DejaVu模型的全局解释通过构建决策树近似模型决策过程,并提炼出诊断规则供工程师参考;局部解释则通过比较新故障与历史故障在聚合特征上的相似性,揭示模型如何基于历史知识对特定故障进行诊断。这两种解释方法共同增强了DejaVu模型的可解释性,有助于工程师更好地理解和信任模型的故障定位结果。

27.5.1 Global Interpretation

在这里插入图片描述
在这里插入图片描述
我们的核心思想是使用更简单但可解释的模型来尽可能准确地近似(而不是优于)复杂的黑盒 DejaVu模型。如图 7 所示,我们使用决策树(DT)作为代理模型。DT 的输入是故障单元度量的可解释时间序列特征,目标是 DejaVu 的可疑分数。我们不使用现有的深度学习模型解释方法有两个原因。一方面虽然有许多解释方法旨在通过理解深度学习模型的内部机制来解释它们,工程师主要关注原始数据和根本原因之间的关系。另一方面,我们问题的投入和目标是不标准的,需要额外的努力。

首先,我们从 tsfresh 中选择了57个易于理解的时间序列特征提取器(例如,范围计数和方差)。他们将为每个度量提取 191 个时间序列特征,每个特征都代表度量的一个可理解的特征,如等级(level)和方差(variance)。

然而,故障单元的时间序列特征的数量(即#metrics × 191 \times 191 ×191)可能非常大(比如上千),DejaVu 的特征维度(即 Z Z Z ) 低得多(例如 3 个)。这表明 DejaVu 不能考虑这些时间序列的大部分特征。为了去除无用和有噪声的时间序列特征,对于每个故障类,我们首先训练解码器从 DejaVu 给出的单位级特征中重构度量,然后比较从原始度量和重构度量中提取的时间序列特性。解码器包括一维转置卷积(1D-DeConv)层和全连接层,该层可以被视为 Conv1D 的转置运算,并且通过最小化原始度量和重构度量之间的均方误差来训练解码器。如果时间序列特征在原始度量和重建度量中有很大差异,则 DejaVu 不会保留该特征模型,应该删除。

故障单元决策树的训练样本包括其度量的选定时间序列特征(作为输入)和 DejaVu 模型给出的分类可疑分数(作为目标)。在解释 DejaVu 模型时,我们并不关心它所依赖的知识。因此我们将可疑分数(即 前面定义的 s ( v ) s(v) s(v) )分为三个不同的类别。特别是如果 s ( v ) > 0.9 s(v)>0.9 s(v)>0.9 时,则故障单元 v v v 被归类为故障故障单元;如果 s ( v ) < 0.1 s(v)<0.1 s(v)<0.1 ,则故障单元 v v v 是一个正常故障单元;否则,DejaVu 模型是不确定的。使用训练样本,我们训练模仿 DejaVu 的决策树模型(图 7 中的第 3 部分),并将故障单元分类为 “故障” 或 “正常” 由于不同故障类别中的故障单元包含不同的度量,我们为每个故障类别训练一个决策树。

在这里插入图片描述

在经过训练的决策树上,我们将重点放在只导致故障或正常故障单元的决策路径上(图7 中的第 4 部分)。这些路径是 DejaVu 模型从历史故障中学习的诊断规则。这些规则用于帮助工程师理解和信任 DejaVu 模型,而不是取代它。一方面,决策树的性能仍然比 DejaVu 更差。另一方面,决策树提供的解释也可能出错。因此,工程师应该关注分裂条件的定性含义(例如,外部服务的成功率非常低),而不是特定的阈值。

27.5.2 Local Interpretation

由于 DejaVu 模型是用历史故障进行训练的,因此通过找出它从哪些历史故障中学习到的推荐故障单元,可以很容易地解释它是如何诊断给定故障的。为了实现这一目标,我们基于训练的 DejaVu 模型提取的聚合特征,将传入故障与每个历史故障进行比较。比较是在每对故障类别而不是故障单元上进行的,因为两个类似的故障可能发生在不同的位置(因此具有不同的故障单元)。由于篇幅限制,我们省略了详细信息,这些信息可以在我们的代码中找到。

27.6 论文实验

篇幅原因这里我们只进行概述。

第5部分详细阐述了DejaVu在四个实际系统上的评估结果,以及与多种基线方法的对比分析。本部分旨在验证DejaVu在定位重复故障方面的性能、效率、泛化能力和可解释性。

评估设置

  • 数据集:采用包含502个注入故障(18种类型)和99个真实世界故障的四个数据集,其中三个基于实际系统。这些数据集涵盖了多种故障场景,确保了评估的全面性和真实性。
  • 基线方法:与多种基线方法进行比较,包括MonitorRank、MEPFL、FluxRank、iSQUAD、LogCluster、LogSig、DrCIF等,涵盖无监督、监督、半监督等多种故障定位策略。
  • 评估指标:使用平均排名(Mean Rank)、准确率(Accuracy@k)、召回率(Recall@k)、故障诊断时间(Diagnosis Time)等多维度指标评价模型性能。

实验结果与分析

  1. 故障定位性能:DejaVu在定位故障单元方面表现出色,平均排名优于所有基线方法,提高幅度在54.52%至97.92%之间。特别是在真实故障数据集上,DejaVu的准确率和召回率均显著高于基线,展现了对实际故障场景的有效处理能力。
  2. 效率:DejaVu的故障诊断时间不足一秒,显著快于其他方法。这得益于其高效的模型架构和算法设计,使得在实际应用中能快速响应故障事件,及时提供定位结果。
  3. 泛化能力:在包含未见故障类型的评估中,DejaVu展现出良好的泛化性能,对未见故障的定位准确率与已见故障相当,表明其能够有效地应对系统中新出现的故障类型。
  4. 可解释性:通过与GNNExplainer和LIME等解释方法的对比,DejaVu提供的解释更具针对性和有效性,有助于工程师快速理解故障场景并找到正确的缓解措施。GNNExplainer 仅展示重要邻居而缺乏对重要性的直接解释,LIME 对相似故障给出的指标重要性可能不一致,易引发混淆。而DejaVu通过全局解释(决策树)和局部解释(历史故障比较)为工程师提供了清晰、一致的故障解释。

工业实践反馈

  • 实用性验证:DejaVu已在生产系统中成功应用,并在实际故障场景中得到验证,证明了其在实际运维环境下的实用性。
  • 经验教训:从compA公司的工业实践中总结出几点教训,包括:
    • 依赖工程师诊断经验形成直觉,启发了从历史故障中学习;
    • 由于软件和部署变更频繁,实践中需定期重新训练模型,耗时约几十分钟;
    • DejaVu支持使用新的故障数据图(FDG)和故障单元;
    • 对于非重复故障,DejaVu会给出较低的可疑度评分,提示工程师可能存在新类型故障。

结论
通过对多个实际系统、多种故障类型和基线方法的全面评估,以及工业实践的应用验证,本部分有力地证明了DejaVu在定位在线服务系统重复故障方面的优越性能、高效性、泛化能力和出色的可解释性。这些特性使得DejaVu成为解决此类问题的理想工具,有望在实际运维场景中显著提升故障诊断与修复效率。

27.7 本章总结

论文提出DejaVu,首个针对在线服务系统重复故障的可行动、可解释定位方法。利用历史故障离线训练模型,实时推荐并解释故障组件。实验证明其在定位准确性、效率、泛化性及可解释性上优于基线方法,已在工业实践中应用并获积极反馈。

论文值得学习的地方很多,个人概括大概包含:

  1. 问题针对性:针对在线服务系统中重复发生的故障,论文提出了专门的故障定位方法DejaVu,聚焦于解决此类系统特有的大规模、多样化数据和复杂组件依赖关系带来的定位难题,具有很高的实际应用价值。

  2. 创新性模型设计:DejaVu模型结合了历史故障学习、新型定位模型以及基于图神经网络(GAT)的特征聚合技术,创新性地解决了四个关键挑战,体现了作者在故障定位领域的新颖思路和技术融合。

  3. 全面实验验证:论文在包含大量真实故障的数据集上进行了广泛的实验评估,对比多种基线方法,展示了DejaVu在定位准确率、效率、泛化能力等方面的显著优势,提供了坚实的数据支持和实践证据。

  4. 强调可解释性:DejaVu不仅注重定位的准确性,还特别关注模型的可解释性,通过全局解释(决策树)和局部解释(历史故障比较)提供清晰的故障解释,有助于工程师理解模型决策过程,快速采取行动,这是许多传统故障定位方法所欠缺的。

  5. 工业实践验证与经验分享:论文不仅在实验环境中验证了DejaVu的有效性,还将其成功应用于生产系统中,并从实际运维经验中提炼出有价值的教训,增强了研究成果的实用性和可信度。

  6. 对未来工作的启示:论文指出了DejaVu的局限性与未来可能的研究方向,如考虑将指标模式纳入故障单元定义、改进知识整合方式、探索模型迁移学习等,为后续研究者提供了有益的启示和研究线索。

综上所述,该论文在理论创新、方法设计、实验严谨性、实际应用价值以及对未来研究的前瞻性思考等方面均有突出表现,对研究者、工程师和运维人员在处理在线服务系统故障定位问题时提供了重要的参考依据和实践指导。

可拓展思考

  1. 跨系统迁移学习:虽然论文指出DejaVu目前不能直接应用于不同系统,但提出了未来可能探索类似系统间的迁移学习。研究如何设计有效的迁移学习机制,使DejaVu在面对具有相似结构或行为特征的其他在线服务系统时,能够利用已有的模型知识快速适应并准确定位故障,减少在新系统上的训练成本和时间。

  2. 动态环境适应:现代在线服务系统频繁变更,论文提及需要持续关注模型的适应性问题。探究如何实时或定期更新DejaVu模型以应对系统软件、配置或架构的变化,确保定位精度不随时间推移而降低。这可能涉及自适应学习算法、增量学习技术或在线更新策略的研究。

  3. 集成更多数据源:尽管论文中DejaVu已经利用了包括指标、历史故障和组件关系在内的多种数据,但还可以考虑纳入其他类型的数据源,如日志、追踪数据、用户反馈等,以丰富模型的输入信息,进一步提升定位准确性。同时,研究如何有效融合这些异构数据,构建更全面的故障表示。

  4. 增强故障类型识别能力:论文提到可考虑将指标模式纳入故障单元定义以提升故障类型的识别能力。研究如何通过深度学习或其他高级数据分析技术,自动识别和提取故障相关的指标模式,以及如何将这些模式有效地融入DejaVu模型中,以便更准确地区分不同类型的故障。

  5. 智能故障修复建议:在精准定位故障的基础上,进一步研究生成针对已定位故障的可行修复建议。这可能涉及到利用强化学习、生成模型或规则推理等技术,根据故障类型、受影响组件以及系统上下文,生成适用于特定故障场景的修复步骤或代码补丁。

  6. 实时性能优化:除了定位故障,DejaVu模型所学习到的系统行为知识也可用于实时性能监控和优化。探索如何利用模型输出的可疑分数或其他中间结果,实时调整系统参数、资源分配或调度策略,以预防潜在故障或优化系统整体性能。

  7. 用户交互与知识共享:研究如何将DejaVu的解释性结果以更直观、友好的形式呈现给工程师,如可视化界面或交互式查询工具,便于他们快速理解和采纳。同时,探讨如何构建知识管理系统,将工程师在实际诊断过程中积累的专家知识与DejaVu的自动学习成果相结合,形成共享的知识库,提升整个团队的故障处理能力。

这里我个人认为比较容易实现的包括 137。而第 5 点特别适合现在比较火的 AI Agent 研究方向。

源码阅读以及实验部分将会在另外的博客中编写,感谢各位阅读评论点赞支持 ~

感谢阅读 ~

感谢点赞 ~

在这里插入图片描述

Smileyan

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/316058.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

AI 工具合集

以下工具来源于互联网&#xff0c;可能会失效&#xff0c;请参考使用 网红工具 名称链接说明GPT-4https://chat.openai.com/ 需要梯子&#xff0c;需要付费。功能最强大的聊天机 器人。 文心一言https://yiyan.baidu.com/welcome 国内版 GPT&#xff0c;需要申请账号。回答问…

ChromaDB教程

使用 Chroma DB&#xff0c;管理文本文档、将文本嵌入以及进行相似度搜索。 随着大型语言模型 &#xff08;LLM&#xff09; 及其应用的兴起&#xff0c;我们看到向量数据库越来越受欢迎。这是因为使用 LLM 需要一种与传统机器学习模型不同的方法。 LLM 的核心支持技术之一是…

IDEA使用技巧(常用设置、快捷键等)

IDEA使用技巧 一、IDEA常用基本设置设置代码背景颜色/主题/字体Ctrl鼠标滚轮缩放字体大小设置字符编码左右两侧的Project&#xff0c;Structure&#xff0c;Maven等按钮消失新增类似sout,psvm的模版切换某个模块编译的JDK版本 二、常用快捷键CtrlAltT包裹代码Alt回车联想补全Ct…

How to solve matplotlib Chinese garbled characters in Ubuntu 22.04

conda create -n huizhou python3.8conda activate huizhouconda install numpy matplotlibpip install mplfontsmplfonts init# 导入必要的库 import numpy as np import matplotlib.pyplot as plt# 创建角度数组&#xff0c;从0到2π x np.linspace(0, 2 * np.pi, 100)# 计算…

七、OSPF特殊区域及其特性

目录 OSPF区域分类 hello报文中option字段 1.末节区域&#xff08;Stub区域&#xff09; 2.完全末节区域&#xff08;Toally Stub区域&#xff09; 3.七类LSA 4.非完全末节区域&#xff08;NSSA区域&#xff09; 5.完全非完全末节区域&#xff08;Toally NSSA区域&#…

Windows Server配置网卡绑定:NIC组合

正文共&#xff1a;1024 字 12 图&#xff0c;预估阅读时间&#xff1a;1 分钟 在网络设备上&#xff0c;为了提高可靠性&#xff0c;一般会配置链路聚合&#xff08;Link Aggregation&#xff09;&#xff08;网络之路28&#xff1a;二层链路聚合&#xff09;&#xff0c;同样…

# 从浅入深 学习 SpringCloud 微服务架构(四)Ribbon

从浅入深 学习 SpringCloud 微服务架构&#xff08;四&#xff09;Ribbon 段子手168 一、ribbon 概述以及基于 ribbon 的远程调用。 1、ribbon 概述&#xff1a; Ribbon 是 Netflixfa 发布的一个负载均衡器,有助于控制 HTTP 和 TCP客户端行为。 在 SpringCloud 中 Eureka …

UE Snap03 启动参数设置

UE Snap03 启动参数设置 UE打包后传入自定义参数及解析。 void UGameInstance::StartGameInstance() {Super::StartGameInstance();UE_LOG(LogTemp, Warning, TEXT("--StartGameInstance--"));FString param;FParse::Value(FCommandLine::Get(), TEXT("-UserN…

【Ant-Desgin 头像上传框】限制数量为1张图片,base64,其他需求可以改我组件中的代码

Ant-Desgin 头像上传框 样式图参数主要代码UpLoad 组件父组件 样式图 图片数量限制为1&#xff0c;当选择了图片后&#xff0c;需要切换图像时需点击头像完成切换 参数 /*** description: 图片上传组件* param {*} action: 上传地址* param {*} width: 宽度* param {*} height…

flink Unsupported operand types: IF(boolean, NULL, String)

问题&#xff1a;业务方存储了NULL 字符串&#xff0c;需要处理为 null select if(anull&#xff0c;null&#xff0c;a); 结果遇到了 Unsupported operand types: IF(boolean, NULL, String)&#xff0c;根据报错反馈&#xff0c;很明显应该是没有对 null 自动转换&#xff…

应用层协议 -- HTTPS 协议

目录 一、了解 HTTPS 协议 1、升级版的 HTTP 协议 2、理解“加密” 二、对称加密 1、理解对称加密 2、对称加密存在的问题 三、非对称加密 1、理解非对称加密 2、中间人攻击 3、CA 证书和数字签名 四、总结 一、了解 HTTPS 协议 1、升级版的 HTTP 协议 HTTPS 也是…

untiy avpro播放超过8K视频的解决方案

安转LAV Filters解码器&#xff0c;然后指定Avpro使用这个解码器播放即可 第一步 安装解码器 下载链接 第二步 AVPro设置 MediaPlayer脚本中一共两处

jasypt组件死锁bug案例分享

事故描述 1、上午9.55发布了一个Apollo动态配置参数&#xff1b; 2、片刻后&#xff0c;服务器接口开始出现大量的超时告警&#xff0c;似乎是某资源被耗尽不足分配&#xff1b; 3、正值业务请求高峰的上午十点&#xff08;平台上午10点会有一些活动会拉一波用户流量&#x…

深入docker-swarm overlay网络模型

目录 1.简介 2.网络模型 3.docker_gwbridge网络 3.1.docker_gwbridge网关地址 3.2.检查docker_gwbridge网络 3.2.1.查找任务容器eth接口 3.2.2.查找ingress-sbox容器eth接口 4.检查ingress网络 4.1.检查ingress网络 4.2.检查ingress网络的命名空间 4.2.1.查找任务容…

VBA技术资料MF147:从Excel运行PowerPoint演示文稿

我给VBA的定义&#xff1a;VBA是个人小型自动化处理的有效工具。利用好了&#xff0c;可以大大提高自己的工作效率&#xff0c;而且可以提高数据的准确度。“VBA语言専攻”提供的教程一共九套&#xff0c;分为初级、中级、高级三大部分&#xff0c;教程是对VBA的系统讲解&#…

12 Junit单元测试、反射、注解

单元测试 介绍 Junit单元测试是做什么的&#xff1f; 就是针对最小的功能单元(方法)&#xff0c;编写测试代码对其进行正确性测试。 Junit单元测试框架 可以用来对方法进行测试&#xff0c;它是由Junit公司开源出来的 Junit单元测试的优点是什么&#xff1f; 可以灵活的…

深度学习中的子空间、线性变换和矩阵概念应用

1.表示子空间 在深度学习中&#xff0c;“不同的表示子空间”通常是指模型通过不同的参数&#xff08;例如权重矩阵&#xff09;将输入数据映射到不同的高维空间&#xff0c;这些空间被称为表示子空间。每个子空间都能够捕获输入数据中不同的特征或模式。以下是一些详细解释&am…

Spring Boot 中Mybatis使用Like的使用方式和注意点

说明 模糊查询在项目中还是经常使用的&#xff0c;本文就简单整理Mybatis中使用Like进行模糊查询的几种写法以及一些常见的问题。 使用Springboot简单配置一下Mybatis&#xff0c;然后进行说明。Springboot集成Mybatis这里就不做介绍了&#xff0c;这里我们主要介绍一下在mybat…

VS Code开发STM32F4xx jlink接口swd模式

VS Code开发STM32F4xx jlink接口swd模式(测试OK) 下面的代码(已验证),只作为参考,不同情况的更改参照文章末尾链接 c_cpp_properties.json代码 (其中include路径和宏定义可以参照makefile添加) : {"configurations": [{"name"…

第三节课,后端登录【1】.1--本人

一、后端登录逻辑&#xff0c;检测账户密码是否合法及密码输入是否正确 视频链接&#xff1a; 网址&#xff1a; 第三节&#xff1a;【视频】后端登录逻辑&#xff0c;检测账户密码是否合法及密码输入是否正确视频链接&#xff1a;-CSDN博客 从5.1开始 这是一个Java方法&am…