参考文献

Nezha: Interpretable Fine-Grained Root Causes Analysis for Microservices on Multi-modal Observability Data | Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering

Root cause analysis (RCA) is a structured investigation of a problem to detect the causes that need to be prevented. We applied ARCA, an RCA method, to target problems of four medium-sized software companies and collected 648 causes of software ...

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

论文笔记✍

📜研究内容

⚙️ 做了什么：

• 我们提出了一种新的方法，将异构多模态可观测数据(即度量、痕迹和日志)以统一的同构事件格式表示。这种表示能够实现事件图的构建，并为未来跨多模态可观测性数据的集成分析提供了便利。

• 我们提出了Nezha，一种可解释的、细粒度的微服务RCA方法。Nezha是一种将更细粒度和可操作的根源(即代码区域或资源类型)进行局部化的统计方法，具有较高的可解释性，便于SREs在有信心的情况下采取缓解行动。

• 我们实现了Nezha的原型，并在两个广泛使用的微服务应用程序上进行了广泛的实验，以验证Nezha的有效性和效率。结果表明，无论在服务层面还是在内部服务层面，Nezha方法都优于当前最先进的RCA方法。

• 我们增强了两个广泛使用的微服务应用Online Boutique和Trainticket的可观测性，并对其进行了开源，这将为未来多模态数据的异常检测和RCA研究提供便利。

🔬 现状不足

问题1:日志主要负责局部，trace负责全局

• 对于一个失败的请求，现有的RCA方法无法确定哪些跨多个服务传播的日志与失败的请求相关联，从而推断其根本原因。

• trace捕获了跨不同服务器的全局服务交互，但对个体范围内的局部行为提供了有限的洞察力。

问题2：注入CPU争用和网络阻塞故障时，基于日志或基于轨迹的RCA方法可能会遗漏根本原因

• 虽然日志和痕迹为RCA提供了丰富的线索，但在这些来源中某些异常可能并不明显，从而导致与根本原因有关的关键信息的潜在损失。

• 只发生在有故障阶段，而不发生在无故障阶段的日志和迹跨度被认为是异常的。

• 然而，由于种种原因，这种整合过程可能是劳动密集型和无效的

• 每一种故障都要单独人工检验因此，SREs被迫对每个结果逐一进行人工验证，这是一项劳动密集型的任务

• 获取带数据标签的DATA不是很实际

• 多模态方法PDiagnose [ 21 ]将异构多模态数据转换为时间序列，通过评估异常时间序列来识别根本原因。虽然这种转换可以产生有效的结果，但该过程可能会导致执行上下文的丢失

🔁 步骤简述

• 1 异常检测器(§4.1)实时检测系统的性能和可用性是否异常。

• 2 数据整合器(§4.2)将异常时间窗口内的多模态数据统一为事件，并将这些事件整合成事件图。

• 3 模式挖掘器(§4.3)并行地从事件图中提取共同模式并计算它们的支持度。

• 4 模式排序器(§4.4)中的预期排序器对那些在正常阶段经常出现但在故障阶段罕见的模式进行排序，将其作为预期模式。实际排序器则对那些在故障阶段经常出现但在正常阶段罕见的模式进行排序，将其作为实际模式

• 5 模式聚合器(§4.5)聚合预期模式和实际模式，以确定具有可解释性的根因候选项排序列表。与现有的根因分析方法相比，Nezha提供了更细粒度的根因候选项（即代码缺陷区域或资源类型），并向SRE工程师解释候选项异常的原因。

👩🏻‍💻 模型架构

异常检测器(“Anomaly Detector”)

• 通过k-σ rules方法来检测P90延迟异常(可以更换)

数据集成器(“Data Integrator”)

Metric

• 为了克服数值度量和文本结构日志之间的异构性，将度量集合替换为可疑的度量警报（就是大量日志出现了问题可能metric才可能出一次错，所以大大能减小那个数据量）

• 我们只考虑RCA中的系统级指标。

• 此外，我们发现一些警报频繁发生，无论是否有故障。这种经常性的警报对RCA没有帮助，有时甚至会误导SREs。所以我们进行了排除了在生产阶段也发生在施工阶段的警报。

Log

• 首先从原始日志消息中提取并记录跟踪ID、跨度ID (详见§ 2.2)和时间戳。

• 采用最新的日志解析方法Drain，以流式的方式从原始日志消息中提取静态日志模板和动态日志参数。

• 在日志解析之后，我们将静态日志模板视为日志事件。

• 为了区分与不同请求相关联的日志事件，每个日志事件都伴随着其对应的迹ID、跨度ID和时间戳。

Trace

• 父子跨度之间的关系可以分为同步调用和异步调用。
• 对于同步调用，我们将一个跨度的开始和结束看作两个跟踪事件。这两个事件消息可以表示为跨度名称与"开始"或"结束"字符串的串联。
• 异步调用方面，将它们表示为由span名称和' asyn '字符串组成的事件，例如e = ' Cart / GetCart _ asyn '。每个迹事件都附有其迹ID、跨度ID和来自跨度记录的时间戳。

事件图的构建

1. 对于同一个span的请求事件：
• 根据日志和跟踪事件的时间戳将它们按时间顺序排列成一个事件组，并在该组中添加一个事件到下一个事件的序列关系。

2. 然后把metric加进去事件组里面：
• 在事件组的第一个事件之后插入警报事件，前提是相应的服务中存在警报事件（不失一般性）。当然，这些警报事件也可以插入到其他约定的固定位置。如果检测到同一服务的多个警报事件，所有警报事件会按顺序依次插入在第一个事件之后

3. 把孩子组插到父母组里：
• 我们直接使用时间戳是因为这两个组是在同一个服务实例上，在同一个节点上，所以它们不存在时钟漂移的问题。
• 在父组的第一个事件后插入子组，以父组的span ID为基础，克服时钟漂移

模型对比

模式挖掘器(“Pattern Miner”)

模式p是事件图G中连续事件的一个子图

1. Nesha会从Gc和Gp两个事件图中提取无故障和有故障的模式

2. 这是通过并行遍历所有事件图来完成的

3. 事件图是有限的,因为日志已被解析成模板,只考虑直接相连的事件(p:c1->c2->c3)

给定一个模式p和它的计数集合Cp={c1,...,ck},其中ci表示模式p在事件图gi中出现ci次，模式p的支持度s(p)是所有图中的计数总和: s(p) = Σci

1. 为了防止SC的重复计算，我们将SC的结果保存到Pattern Storer中

2. 们通过过滤支持度小于smin (默认smin = 5)的模式来丢弃那些很少出现的模式。

模式排序器（“Pattern Ranker” ）

• 在无故障阶段，某些事件模式并不遵循其预期的执行路径

• (图七)SREs然后将e2和e3之间的码区作为根原因候选，并检查e2→e3转化为e2→e6的原因，以确定最终的解决方案。

Expected Pattern Ranker

1. 主要目标：
• 识别哪些事件模式偏离了预期的执行路径
• 将这些偏离的模式标记为"预期模式"
• 让SRE工程师能检查这些模式为什么会偏离正常执行路径，从而解决故障

2. 核心思想
• 主要关注那些在正常阶段(fault-free phase)经常出现但在故障阶段(fault-suffering phase)很少出现的事件模式

3. 评分机制(Score_E)来衡量每个模式对根因诊断的贡献
• 如果模式p在GC中多次出现，而在GP中很少出现，则p被赋予更高的分值。因此，排序得分较高的模式更可能是根本原因

Actual Pattern Ranker

1. 主要目标
• 虽然Expected Pattern Ranker能识别不遵循预期执行路径的模式，但还需要了解这些模式在故障阶段是如何发生变化的
• 来定位新出现的模式，这些模式打破了它们的预期执行路径，并将它们作为实际模式。

2. 核心思想
• 关注那些在故障阶段(fault-suffering phase)频繁出现，但在正常阶段(fault-free phase)很少出现的事件模式，将这些模式标记为"actual patterns"（实际模式）

3. 评分机制(Score_A)来衡量每个模式对根因诊断的贡献
• 如果模式p在GP中多次出现，而在GC中很少出现，则p被赋予更高的分值。量化了模式p在故障图(GP)相对于正常图(GC)的独特性
• 高分数的模式更可能反映故障发生时的实际行为

模式集结器(“Pattern Aggregator”)

• 故障可能会导致GP中根原因的下游模式发生改变，从而导致GC中所有根原因的下游模式都具有较高的得分作为根原因(e2->e3和e3->e5)

• 在本研究中，我们将e3→e5这样得分相同的下游模式称为冗余模式。模式聚合器旨在排除Expected Ranker的冗余模式，为SREs提供更有价值的列表，以加快排除故障的速度

• Expected Pattern
• 如果模式ei→e j和e j→ek都在列表中，且Score ( ei→ej)≥Score ( ej→ek)，则模式集散商将ek加入到ei→e j (即ei→e j→ek)中。

• 把expected和actual联系起来
• Nezha通过寻找共同前缀(common prefix)来关联期望模式和实际模式
• 我们选择得分最高的实际模式作为实际模式作为匹配

• 根因候选项的排序机制：主要根据期望模式的分数进行降序排序
• 对于分数相同的期望模式：
• 在事件图中深度更深的模式会排在更前面
• 原因是浅层深度的模式更可能是由异常传播造成的
• 这样的排序有助于找到更接近根本原因的模式

🤔 结果指标：

• 服务级别的Top - k准确率( AS @ k )是指根原因服务包含在top - k结果中的概率。

• 内部服务级别的Top - k准确率( AIS @ k )是指内部服务根原因(资源类型或代码区域)包含在top - k结果中的概率。

📌 待解决点：

• 它不能识别逃离异常检测的故障的根本原因。未来的工作可以集成更鲁棒的异常检测算法(例如, USAD)，并监测P90延迟和成功率以外的其他指标，以避免遗漏故障。

• 仅限于对多模态数据中表现出异常模式的故障进行排查。一些拜占庭故障，例如向用户返回一个不合理的结果，无法被Nezha识别，因为这些故障并不表现为任何异常模式。对类似[ 65 ]这样的拜占庭故障进行排查是未来改进Nezha的工作。

• 如果一个非变化的故障没有被我过滤，我们也会生成一个可疑列表供SRE检查，这增加了SRE的检查负担。