论文笔记✍

Robust Multimodal Failure Detection for Microservice Systems | Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining

Certain gateways (e.g., some cable or DSL modems)are known to have low reliability and low availability.Most failures of these devices can however be "fixed"by rejuvenating the device after a failure has been detected.Such a detection based rejuvenation ...

https://dl.acm.org/doi/10.1145/3580305.3599902

🏷️ Mind Map

📜 INTRODUCTION

当前问题

• 单模态数据无法揭示所有类型的故障，更不用说其本身可能被遗漏或收集得太慢
• 例如，在表1中，当发生"无法生成QR码"故障时，只有实例的度量指标，即内存利用率急剧增加，并表现出异常行为。如果只进行日志或踪迹异常检测，这类故障将被错误地忽略

• 单模态异常检测方法检测到的(瞬态)异常可能不代表任何实例故障
• 假设一个实例的网络吞吐量指标经历了一个异常，并报告了一个警报，因为该指标突然增加，并在短期内恢复到正常水平。但系统仍然提供了正常的服务，因为没有任何痕迹数据变得异常，用户体验也没有受到影响。因此，不应该报告实例失败

我们的模型AnoFusion

• 我们首先确定了探索多模态监测数据(即度量、日志和痕迹)相关性的重要性，并使用GTN对多模态数据进行相关性分析，用于故障检测。

• ·我们的方法，根据每个模态的特点，将三个模态的数据序列化。它结合了GTN和GAT，能够鲁棒地检测动态多模态数据中的异常。此外，GRU层用于捕获多模态数据的时间信息。

• 我们采用两个微服务系统，分别由10个和28个实例组成，以评估AnoFusion的性能。评估结果表明，AnoFusion检测实例故障的F1值平均值分别为0.857和0.922，优于基线满足

🔬 BACKGROUND AND RELATED WORK

单模态异常检测

关于Metric log trace三个近期的研究重点

• metric：不需要异常标签的无监督方法成为近年来的研究热点。

• log：提取日志模板及其参数是分析日志数据的标准步骤

• trace：大多数trace异常检测方法根据每次调用的响应时间是否急剧增加和调用路径是否表现异常来检测异常。
• 然而，一方面，仅有迹异常并不一定意味着实例失败
• 举个例子：
• 正常情况：
用户请求 -> 网关 -> 服务A -> 服务B -> 数据库
响应时间：200ms
出现trace异常但系统仍正常工作：
用户请求 -> 网关 -> 服务A -> 服务B -> 数据库
响应时间：800ms（因为数据库在进行备份）
• 另一方面，一个实例的失败可能不会在跟踪数据中表现出来。
• 举个例子：
• 快速失败（失败的时间很短，表面上看着十分的正常）
• 再比如：
• 消息队列处理：
正常：消息发送 -> 队列 -> 处理 -> 确认
异常：消息发送 -> 队列 -> 消息丢失（无trace记录）
• 所以我们一般都和log或者其他的因素相结合

多模态异常检测

• Vijayanand等人提出了一个使用多维数据的云服务器异常检测框架，包括来自主机日志的网络流量序列特征、CPU使用率和内存使用率等不同特征。这些提取的多维特征被馈送到识别异常的检测模型中，最大限度地提高了检测精度。通过对指标和日志进行相关性分析来发现云操作中的异常模式。

• 此外，SCWarn通过将度量和日志分别序列化，并采用LSTM来检测故障，从而将度量和日志结合起来进行异常检测。然而，在这些工作中，对实例至关重要的痕迹是缺失的

• 这篇文章是第一次用了多模态数据

图神经网络

GTN

• 举个例子：
• 异构图就像购物中心里有不同类型的数据：
• 顾客（人）
• 商铺（店）
• 购物记录（交易）
• 摄像头记录（视频）
• 支付系统记录（支付）

• 举个例子
• 相当于数据之间的关联方式，比如：
• 顾客-商铺-购物记录：表示"谁在哪个店买了什么"
• 商铺-摄像头-顾客：表示"哪个店的摄像头拍到了谁"
• 顾客-支付-商铺：表示"谁给哪个店付了钱"

• 监控系统发现异常时：
1. 收集当时的所有数据：
• 系统日志
• 性能指标
• 错误信息
• 用户行为
2. GTN帮助发现：
• 哪些数据之间存在关联
• 哪些异常是相关的
• 问题可能的传播路径

GAT

GRU

✨ MOTIVATION

Metric anomaly detection（Jump Starter和USAD）

• Jump Starter从度量数据中提取实时正常模式，但没有考虑历史数据的模式。

• USAD的抗噪性不是很好，导致大量的假阳性和假阴性。

• 此外，对于故障检测任务来说，它们缺少日志和痕迹中的必要信息。

Log anomaly detection（LogAnomaly和Deeplog）

Trace anomaly detection（TraceAnomaly）

JLT

• JumpStarter：可能基于资源性能指标。

• LogAnomaly：基于系统日志分析异常。

• TraceAnomaly：基于调用链（trace）数据检测异常。

• 多数投票（majority voting）：当至少两种方法同时检测到异常时，JLT 判定系统发生了故障。

• 目标：通过综合多种模态的数据，提高故障检测的鲁棒性。

1. D1 数据集上的低精度

• 问题：低精度意味着误报率（false positive rate）高，即模型检测出大量非故障情况为故障。

• 原因：JumpStarter、LogAnomaly 和 TraceAnomaly 本身在 D1 数据集上的精度较低，各方法的误报会相互叠加，导致 JLT 的误报率也很高。

• D2 数据集上的低召回

• 问题：低召回意味着漏报率（false negative rate）高，即模型未能检测出许多真实故障。

• 原因：
• 单模态故障：某些故障仅表现为单一数据模态的异常（例如，只在日志或 trace 中显现）。
• 多数投票策略的局限性：要求至少两种模态同时检测到异常才能判定故障，这导致单模态故障无法被检测到，出现漏报问题。

👩🏻‍💻 模型架构

AnoFusion 的整体框架

• 为了捕捉多模态数据的异质性和相关性，AnoFusion 使用 GTN（Graph Transformer Network） 更新异质图。

• 为了提升模型的鲁棒性，使其在训练集和测试集数据模式不同的情况下依然稳定，AnoFusion 在 GTN 之后应用了 GAT（Graph Attention Network）。

• 为了实现无监督的故障检测并更好地适应时间序列数据，AnoFusion 使用 GRU（Gated Recurrent Unit） 预测下一时刻的多模态数据。

离线训练阶段

• metric
• 对metric进行归一化（因为其是有序的所以不需要特殊操作）

• log
• 正确解析日志和提取日志模板是日志序列化必不可少的两个步骤
• 使用日志解析算法Drain提取日志模板，有两个步骤
• 聚类：将相似的日志模板分组成簇，如果由于软件更新而出现新的日志模板，就可以计算新的日志模板与之前的聚类中心之间的相似度，并判断新的日志模板是否属于现有的聚类，还是应该被视为新的聚类。由于AnoFusion是一种基于所有训练样本都具有正常模式的无监督学习方法，因此去除异常日志模板将提高模型的性能（基于上述分析，我们最终利用" bert-base-uncased"模型google-bert/bert-base-uncased · Hugging Face获得句子嵌入向量，并应用DBSCAN 算法深度解读DBSCAN聚类算法：技术与实战全解析 - techlead_krischang - 博客园对这些向量进行聚类。）
• 序列化：
• 输入中的每个日志项的类别可以通过计算其句子嵌入向量与每个簇的质心之间的距离来确定
• 例如，日志可能分为 M 类，每条日志会归入离它最近的类别。
• 之后，AnoFusion使用滑动窗口将输入的日志数据分割成窗口，每个窗口都有窗口长度θ和步长δ。
• 例如，θ=10，表示每个窗口包含10条日志或10个时间单位内的日志，δ=5，表示窗口每次移动5条日志或5个时间单位。
• 我们统计每个类别日志的数量以及每个窗口中日志的总数，形成M + 1个时间序列，其中M是日志模板簇的数量。横轴Timestamp对应输入日志的采集时间。
• 解释一下：对于每个滑动窗口
• 统计每个类别的日志数量：
• 假设聚类的类别数为 M，那么会统计窗口中属于每个类别的日志数量。
• 统计日志总数量：
• 统计窗口内日志的总数，作为额外的一维时间序列。
• 最终，生成 M+1个时间序列：
• M 个类别日志数量序列；
• 1 个总日志数量序列。
• 为了更清楚地理解这一过程，下面用一个具体的例子来说明AnoFusion日志序列化的过程。

---

假设
1. 日志条目（Log Entries）
• 输入包含 6 条日志，按时间顺序排列：
• L1: "User login failed"
• L2: "Database connection timeout"
• L3: "User login successful"
• L4: "File not found"
• L5: "User login failed"
• L6: "File access denied"
• 通过嵌入向量和聚类算法，这些日志被分为 3 类（M = 3）：
• Cluster 1（C1）: 与用户相关的日志（例如登录相关的日志）
• Cluster 2（C2）: 与数据库相关的日志
• Cluster 3（C3）: 与文件操作相关的日志
2. 滑动窗口参数
• 窗口长度 (θ): 4 条日志
• 步长 (δ): 2 条日志
3. 目标
• 将这些日志按类别统计，形成 3（类别数量）+ 1（总数）= 4 个时间序列。

---

步骤 1：滑动窗口划分日志
按照窗口长度和步长划分日志：
• 窗口 1: [L1,L2,L3,L4]
• 窗口 2: [L3,L4,L5,L6]
• 窗口 3: [L5,L6]

---

步骤 2：统计每个窗口内日志的类别数量
对于每个窗口，统计每个类别的日志数量以及总数量：
• 窗口 1
• C1（用户相关日志）: 2（L1, L3）
• C2（数据库相关日志）: 1（L2）
• C3（文件相关日志）: 1（L4）
• 总数: 4
• 结果向量: [2,1,1,4]
• 窗口 2
• C1: 1（L3）
• C2: 0
• C3: 3（L4, L5, L6）
• 总数: 4
• 结果向量: [1,0,3,4]
• 窗口 3
• C1: 0
• C2: 0
• C3: 2（L5, L6）
• 总数: 2
• 结果向量: [0,0,2,2]

---

步骤 3：生成时间序列
每一类日志的数量形成一个时间序列，最终得到 4 个时间序列：
1. C1（用户相关日志）数量序列: [2,1,0]
2. C2（数据库相关日志）数量序列: [1,0,0]
3. C3（文件相关日志）数量序列: [1,3,2]
4. 总日志数量序列: [4,4,2]
横轴对应每个滑动窗口的时间范围（时间戳）。如果每条日志带有收集时间，可以进一步明确每个窗口对应的具体时间段。

• trace
• 每个窗口包含与实例相关的调用的追踪数据(以RT的形式)
• 追踪数据示例
假设一个实例的调用包含以下Trace数据：
• [ {"trace_id": "abcd1234", "span_id": "1", "service_name": "frontend", "operation_name": "GET /home", "start_time": 1690200000000, "duration": 100},
• {"trace_id": "abcd1234", "span_id": "2", "service_name": "backend", "operation_name": "FetchData", "start_time": 1690200000200, "duration": 200},
• {"trace_id": "abcd1234", "span_id": "3", "service_name": "recommendation", "operation_name": "GetRecommendations", "start_time": 1690200000400, "duration": 300} ]
注意字段解释:
• start_time: 调用的开始时间。
• duration: 调用的响应时间（RT），以毫秒为单位。

---

滑动窗口聚合
假设滑动窗口参数为：
• 窗口长度 (θ): 2 个请求。
• 步长 (δ): 1 个请求。
按照滑动窗口划分后，窗口中仅包含 RT 数据：

窗口编号	RT数据
窗口 1	[100ms, 200ms]
窗口 2	[200ms, 300ms]

• 对于每个窗口，AnoFusion计算调用RT的均值、中位数、极差和标准差，分别生成4个时间序列。
• 演示序列化过程

---

假设
1. 追踪数据
• 某实例在时间段内的响应时间（RT）记录如下（按时间顺序）：
RT: [100ms, 200ms, 150ms, 400ms, 250ms, 300ms, 350ms, 500ms]
2. 滑动窗口参数
• 窗口长度 (θ) = 4
• 窗口步长 (δ) = 2

---

步骤 1: 滑动窗口划分
按照 θ=4和 δ=2 划分追踪数据：
• 窗口 1: [100ms, 200ms, 150ms, 400ms]
• 窗口 2: [150ms, 400ms, 250ms, 300ms]
• 窗口 3: [250ms, 300ms, 350ms, 500ms]

---

步骤 2: 计算统计特征
对于每个窗口，分别计算以下统计量：
1. 均值（Mean）
2. 中位数（Median）
3. 范围（Range）
4. 标准差（Standard Deviation）
窗口 1: [100ms, 200ms, 150ms, 400ms]
• 均值: 212.5ms
• 中位数:175ms
• 范围: 300ms
• 标准差: 125.83ms
窗口 2: [150ms, 400ms, 250ms, 300ms]
• 均值: 275ms
• 中位数: 275ms
• 范围: 250ms
• 标准差:93.54ms
窗口 3: [250ms, 300ms, 350ms, 500ms]
• 均值: 350ms
• 中位数: 325ms
• 范围: 250ms
• 标准差:93.54ms

---

步骤 3: 生成时间序列
根据每个窗口的统计结果，生成 4 个时间序列：
1. 均值时间序列: [212.5,275,350]
2. 中位数时间序列:[175,275,325]
3. 范围时间序列: [300,250,250]
4. 标准差时间序列: [125.83,93.54,93.54]
• 如果状态码可用，AnoFusion可以将它们作为第五个时间序列。我们将每个时间序列视为一个数据通道，类似于日志数据的序列化。
• 假设
1. 追踪数据
• 每次调用的响应时间（RT）和对应的状态码如下：
RT: [100ms, 200ms, 150ms, 400ms, 250ms, 300ms, 350ms, 500ms]
• Status Code: [200, 500, 200, 500, 200, 200, 400, 500]
• 状态码说明：
• 200: 成功
• 400: 客户端错误
• 500: 服务器错误
2. 滑动窗口参数
• 窗口长度 (θ) = 4
• 窗口步长 (δ) = 2

---

步骤 1: 滑动窗口划分
按照 θ=4 和 δ=2 划分数据：
• 窗口 1: [RT:100,200,150,400],[Status:200,500,200,500]
• 窗口 2: [RT:150,400,250,300],[Status:200,500,200,200]
• 窗口 3: [RT:250,300,350,500],[Status:200,200,400,500]

---

步骤 2: 计算状态码的分布
在每个窗口中统计每种状态码的出现次数或比例。这里选择按次数统计：
窗口 1:
• 200: 2 次
• 500: 2 次
• 总计: 4 次
窗口 2:
• 200: 3 次
• 500: 1 次
• 总计: 4 次
窗口 3:
• 200: 2 次
• 400: 1 次
• 500: 1 次
• 总计: 4 次

---

步骤 3: 状态码生成时间序列
为每种状态码生成一个时间序列，记录其在各窗口中的出现次数：
1. 状态码 200: [2,3,2]
2. 状态码 500: [2,1,1]
3. 状态码 400: [0,0,1]
若还需要一个总的状态码序列（或比例），可以用状态码总数或错误率作为时间序列：
• 状态码总数序列: [4,4,4]
• 错误率序列（非 200 状态的比例）:
• 窗口 1: (2/4)=0.5
• 窗口 2: (1/4)=0.25
• 窗口 3: (2/4)=0.5
• 时间序列: [0.5,0.25,0.5]

---

最终时间序列结果
1. 基于响应时间（RT）的时间序列：
• 均值时间序列: [212.5,275,350]
• 中位数时间序列: [175,275,325]
• 范围时间序列: [300,250,250]
• 标准差时间序列: [125.83,93.54,93.54]
2. 基于状态码的时间序列：
• 状态码 200 时间序列: [2,3,2]
• 状态码 500 时间序列: [2,1,1]
• 状态码 400 时间序列: [0,0,1]
• 错误率时间序列: [0.5,0.25,0.5]

• 时钟同步
• 三种模态的监测数据时钟是相对同步的。每分钟采集一次度量数据
• 三种模态的数据（metrics、logs、traces）形成节点特征向量

1. 输入数据的结构

• 输入数据由 N 个数据通道组成，每个通道表示一个独立的数据源。

• 示例：CPU 使用率、日志条目数量、调用链的平均延迟等。
• 数据结构： X={x(1),x(2),…,x(N)}
• 其中，x(i) 是第 i个数据通道随时间变化的序列。

1. 时间戳 t下的数据

• 对于每个时间戳 t，构造一个 异构图 Gt

• 图的节点集合为： Xt = {xt(1),xt(2),…,xt(N)}
• 节点含义：xt(i)是第 i个数据通道在时间 t 的值。
• 示例：
• 如果 xt(1)=75，表示时间 t的 CPU 使用率为 75%。
• 如果 xt(2)=3，表示时间 t生成了 3 条日志。

1. 异构图的节点类型

• 数据通道分为 三种模态：
1. Metrics：如 CPU 使用率、内存使用率等。
2. Logs：如错误日志、警告日志数量等。
3. Traces：如调用链的总延迟、调用次数等。

• 节点类型：
• 图中的每个节点被划分为三种类型：metrics 节点、logs 节点、traces 节点。
• 节点类型帮助模型捕捉不同模态之间的特性。

1. 异构图的边类型

• 边类型的数量：
• 异构图的边类型 K=6，表示节点之间的六种可能关系：
1. Metrics-Metrics
2. Metrics-Logs
3. Metrics-Traces
4. Logs-Logs
5. Logs-Traces
6. Traces-Traces

• 边的定义：
• 边可以表示相似性、因果关系或关联性。
• 示例：
• Metrics-Metrics：CPU 使用率与内存使用率之间的相关性。
• Logs-Traces：日志条目数量与调用链延迟之间的关系。

1. 邻接矩阵的定义

• 对于每种边类型 k，用邻接矩阵A^{(k)} \in \mathbb{R}^{N \times N}表示：
• N 是节点的总数（即数据通道的数量）。
• A(k)[i,j] 表示节点 i和节点 j之间是否存在类型为 k 的边，以及该边的权重。(挺好理解)

1. 计算邻接矩阵元素

• 这个公式比较难理解

• 记住邻接矩阵 的一个元素值。这一值反映了在第 k 种边类型下，节点 i（和节点 j之间的关联强度。

• 举个例子说明：
• 数据假设
1. 节点 l和 j：
• 节点 l：表示一个服务的 CPU 使用率；
• 节点 j：表示一个服务的 内存占用率。
2. 时间步数 τ=3：
• 时间步 t=1,2,3
3. 节点的时间序列特征：
• 节点 l 的特征值：x_i^{(1)}=0.2,x_i^{(2)}=0.4 ,x_i^{(3)}=0.6
• 节点 j 的特征值：x_j^{(1)}=0.5,x_j^{(2)}=0.6 ,x_j^{(3)}=0.7

---

• AnoFusion通过GTN更新异构图流G和GAT学习失效模式进行特征过滤
1. Graph Transformer Network
• GT
• 首先，它通过一个1 × 1的卷积层从构造了几种图结构



• 假设数据如下：





• Q(2)类似
• Q(k) 是对边类型 k的新生成图，融合了多种边类型的加权信息



• 矩阵乘积 ：将 K 种生成的图结构 Q(k)相乘。这种乘积对应于一种高阶的“元路径”（meta-path），能够捕捉跨模态的复杂关系。
• 归一化：通过度矩阵 D 进行归一化，避免数值溢出，同时平衡节点的连接性。



• Graph Attention Network
• 在异构图流上使用GAT区分多模态数据通道的显著性，完成特征过滤。多头注意力机制也被用来稳定这个过程
• 这里就是有点晦涩难懂
• 举个例子：
• 首先：

• 我们可以使用GRU来捕获其复杂的时间依赖性，并预测数据通道在τ时刻的值

• 利用该损失函数对GRU网络进行迭代更新。

• 这里其实使用两个门得到状态ht来预测类来的X，之后损失函数进行一个更新

在线检测阶段

• 这里用gpt总结的，写的很好

⚙️ EVALUATION

• RQ1：AnoFusion在故障检测中的表现如何

• RQ2：每个组件对AnoFusion是否有贡献

• RQ3：AnoFusion的主要超参数如何影响其性能

实验设计

数据集

1. Cloud Wise1的Generic AIOps Atlas ( GAIA )数据集。它包含了从一个由10个实例组成的系统中收集的多模态数据，该系统在两周内收集了超过70万个指标、8700万条日志和2800万条痕迹。

2. 某商业银行运营的大型微服务系统。该系统拥有Web服务器、应用服务器、数据库等28个实例，每天为数百万用户提供服务。由专业操作人员手动向系统注入故障并采集多模态监测数据(即度量、日志和跟踪)。（无法公开）

执行

• a Linux Server

• θ = 60 and step size δ = 1

• 对于GTN，GT to 5

• 对于GAT，H为6

• 每个实例和测试集前60 %的数据包含其余40 %的数据。

基准方法

• Jump Starter [ 25 ]、USAD [ 1 ]、Log Anomaly [ 27 ]、Deeplog [ 5 ]、Trace Anomaly [ 21 ]、SCWarn [ 46 ]和JLT

评价指标

• 真阳性( True Positive，TP )、假阳性( False Positive，FP )和假阴性( False Negative，FN )

• 精确率= T P / ( T P + F P)，召回率= T P / ( T P + F N)，F1值= 2 ·精确率·召回率/ (精确率+召回率)来评估各方法的整体性能

RQ1: AnoFusion在故障检测中的表现如何

• 与JLT相比，AnoFusion使用异构图流显著提高了实例故障检测的有效性

• AnoFusion很健壮

• 这几个模型效率都很好，AnoFusion效率很高

RQ2：每个组件对AnoFusion是否有贡献

• 创建了AnoFusion的三个变体，并进行了一系列的实验来比较它们的性能。

三种变体的设计与目的

• 变体描述：移除了 GTN（Graph Transformer Network），即不再使用GTN对多模态数据的异质性和相关性建模。

• 研究目的：验证 GTN 是否能够有效捕捉多模态数据之间的异质性和相关性。

• 变体描述：用 GCN（Graph Convolutional Network）替代了 GAT（Graph Attention Network）。

• 研究目的：分析 注意力机制（GAT 的关键特性）对模型性能的影响。GAT 的特点是可以为图中的不同邻居节点动态分配不同权重，而 GCN 对所有邻居节点一视同仁。

• 变体描述：移除了 GAT。

• 研究目的：验证 GAT 是否能有效聚焦图中最相关的信息，避免冗余或噪声干扰。

结果

• 捕捉多模态数据之间的复杂异质性关系，综合不同模态的信息，减少误报。

• 如果移除 GTN，模型的 精确率 和 召回率 均显著降低，尤其是 精确率。

• 动态分配邻居节点权重，对时间序列中不同节点的行为差异更敏感。

• 替代 GAT 使用 GCN 或移除 GAT，都会显著降低模型性能。

RQ3：AnoFusion的主要超参数如何影响其性能

• 如果θ太大，它将包含太多的季节变化，并且将很难重建当前状态；如果θ过小，模型将无法全面地从历史数据中学习信息，从而降低AnoFusion的性能，θ在40 ~ 90之间可以获得较好的性能。因此，我们取θ = 60

• 我们将GAT，H中的注意力头数从2变为10。H为6时性能最好。如果H过小，由于模型尺寸的减小，AnoFusion的性能会略微下降；如果H过大，可能会产生更多的冗余信息，干扰AnoFusion的训练

🔖 DISCUSSION

教训

实时采集多模态监测数据

• 建议利用开源的监控系统或Azure Monitor2来构建数据管道。

• 例如，Prometheus3可以用来收集度量指标。使用ELK ( Elasticsearch、Logstash、Kibana) Stack4采集日志。Skywalking5可用于采集痕迹。

• 此外，使用16天的数据进行训练。当模型训练完成后，AnoFusion在在线检测阶段消化10分钟的数据进行实时检测，在实际应用中具有高效性和有效性。

metric的选取

• 在线检测阶段，AnoFusion采用EVT算法[ 34 ]来获得最佳F1值。

• 然而，在实际应用中，根据业务类型的不同，操作者可能对准确率和召回率有不同的偏好。

• 例如，运营商一般会对提供网购服务的核心服务寻求较高的召回率。他们不希望错过任何可能对用户体验产生负面影响的潜在故障。

• 仅仅关注F1值并不适合所有情况

• 未来，我们计划提供一个接口，允许操作员应用额外的权重，评估其中一个的精确率或召回率高于另一个。

对有效性的威胁

失败标签

• 人工标注的异常可能包含很少的噪声。我们认为，由于操作者的丰富经验，标记噪声是最小的。

• 此外，为了减少标记噪声的影响，我们采用广泛使用的评估指标来检测连续的故障片段，而不是逐点异常

粒度效应

• 实验中监测数据的粒度为1分钟

• 未来我们将在更大的系统规模上对AnoFusion进行实验。

数据模式

• 真实世界的场景中，只要监测数据的模态不低于两个，算法就会正常运行。

• 此外，如果一个故障仅表现在一种监测数据中，AnoFusion将不仅考虑历史多模态数据之间的相关性，而且还考虑异常在所有监测数据中的比例，以确定实例是否发生故障。

🤔 生词扫盲：

📌 CONCLUSION

• 在这项工作中，我们提出了AnoFusion，这是第一个使用多模态数据，即度量、日志和痕迹，鲁棒地检测微服务系统中实例的故障的研究之一。

• 具体来说，我们首先将三种模态的数据序列化，构建异构图结构。然后，使用GTN更新异构图，并使用GAT捕获显著特征。最后，我们使用GRU来预测下一时刻的数据模式。预测值和观察值之间的偏差被用作失败分数。

• 我们在两个微服务系统上应用了AnoFusion，证明了其对故障检测的F1值有明显的提升。

• 我们相信，应用多模态数据进行故障检测的解决方案将使微服务系统以外的更多领域受益

💭 参考文章以及项目

1. https://dl.acm.org/doi/10.1145/3580305.3599902

2. 深度解读DBSCAN聚类算法：技术与实战全解析 - techlead_krischang - 博客园

3. google-bert/bert-base-uncased · Hugging Face