3 篇博文 含有标签「根因分析」

我们的 AI SRE 智能体 Syncause 致力于通过AI技术提升故障诊断效率。前几天，我们发布了根因分析场景的准确率测试结果。在Train Ticket微服务系统的根因定位任务中，Syncause的AC@3准确率（前3候选根因命中真实故障的概率）达到96.67%，成为目前公开可复现的最高水平。

那么，准确率高就足够了吗？几年前AIOps也承诺较高的根因分析准确率，但在实际落地中因缺少可解释性而不被信任。所以，高准确率仅是起点，在实践中，AI结论的可信度与可验证性同样关键。准确率再高，没有可见的证据，也难以建立真正的信任。

准确率之外的信任困境​

生产环境故障的决策成本极高，工程师无法将关键判断权交给一个“不可解释”的系统。即使AI输出正确结果，若无法追溯其推理路径，仍可能导致以下问题：

• 信任缺失：结论缺乏证据支撑，难以形成团队共识；
• 重复验证成本：工程师需独立复核AI结论，抵消效率优势；
• 风险控制失效：无法复盘错误推理逻辑，阻碍系统迭代优化。

为此，Syncause推出推理视图功能，通过结构化、可视化的推理链路，实现AI诊断过程的全透明化。

推理视图详解​

树状结构化证据展示推理路径​

在 AI 根因分析中，如果工程师只能看到最终结论，就很难判断其背后的验证路径。而复杂系统的诊断往往涉及多层级、多假设的推演过程。

推理视图通过 树状结构 展示 AI 的推理步骤，包括：

• 假设生成：基于故障上下文提出初步假设，如基础设施资源问题、依赖服务问题、数据库问题等；
• 验证步骤：通过指标、日志、链路或事件验证假设的合理性；
• 状态标记：节点状态（正常/异常）直观反映诊断进展。

异常路径通过高亮标记快速定位关键问题，从而帮助工程师快速锁定关键路径。

可视化证据：即时验证上下文​

推理链条的可信度依赖证据质量。因此，我们将每个推理节点都设计为可展开查看证据来源和内容，包括指标曲线（如CPU利用率、请求延迟）、错误日志、上下游调用链、数据库慢查询日志等。

所有数据来自实际监控系统或日志源，在这里可以快速判断 AI 的推理是否符合事实，而不必跳转回原有的监控系统中进行验证。

防幻觉：算法与大模型的协同​

在故障诊断中，避免幻觉比生成答案更重要。为实现这一点，我们采用了混合式的推理架构：

• 由确定性算法执行异常检测：采用统计方法、规则、特定模型，确保不会“编造”异常
• 大模型负责抽象理解、上下文串联与推理方向选择：负责抽象推理与上下文关联分析，生成可解释的诊断路径。

两者的结合既保证了诊断的严谨性，又保留了大模型对复杂场景的泛化能力。

延伸价值：从可信验证到效率提升​

推理视图不仅解决信任问题，更通过降低重复验证成本提升整体故障排查效率：

• 减少人工复核：AI已验证的路径可直接作为诊断参考；
• 支持流程自动化：未来将支持自定义检查流程的集成，AI自动执行标准验证步骤。

---

演示​

当用户抱怨访问速度变得很慢，我们可以第一时间向Syncause提问：“用户抱怨系统访问很慢，帮我做根因分析”，Syncause会马上响应并开始查询数据进行分析。

AI通过检查指标、链路等数据执行多步骤分析，得出结论，是由于ts-price-service的CPU使用率异常升高，导致延时影响了整体，在“结构化证据”中可以查看推理路径：

AI针对服务检查了依赖服务、依赖数据库、基础设施和自身代码执行情况，发现CPU资源升高是罪魁祸首。

共建AI运维新范式​

我们相信，AI在运维领域的终极形态不是"替代工程师"，而是成为可信赖的智能协作者。它的每一步操作都要有记录，每一个结论都要有依据，每一次失败都可以复盘。

而这，才是人类与AI协作最该有的样子。

Syncause 目前已经开放注册，如果你希望在真实场景中试用，欢迎通过微信联系我们或通过官网注册使用。

我们期待与先进团队一起验证、改进并推动这项能力在实际生产环境中的落地。

---

在最新的 Train Ticket 微服务系统根因分析测试中，Syncause 根因分析准确率（AC@3）达到 96.67% —— 在同类测试场景中，这一数字是目前能公开复现的最高水平。

AC@k (Accuracy@k) 是学术研究中衡量算法准确度的指标。  含义是：当系统推荐前 k 个最可能的根因时，真实根因出现在这前 k 个结果中的概率。

换句话说，当其他算法仍在“猜”，Syncause 已经能在前三个候选根因服务中准确命中真实故障原因。

根因分析难上加难​

在微服务与云原生体系中，根因分析（Root Cause Analysis, RCA）被称为运维自动化的“圣杯”。

系统出现异常时，你需要在数十个微服务、数千个指标和海量日志中找出真正的罪魁祸首。

过去几年，学术界与业界都在尝试利用机器学习、图分析、时间序列建模等方法自动化这一过程，但现实问题依然突出：

• 模型需要在真实生产环境中长时间训练与调优；
• 算法泛化能力差，新环境迁移困难；
• 机器学习算法的分析结果缺乏可解释性；
• 离线算法无法适应实时运维场景。

因此，虽然已有不少论文成果，但“真正能在线落地的 RCA 系统”仍然凤毛麟角。随着大语言模型（LLM）推理能力的提升，这一问题出现了新的突破口。  Syncause 基于 LLM 构建了智能 RCA Agent，让根因分析变得“即装即用、实时可解释、可验证”。、

学术论文指标 vs Syncause 实测结果​

我们研究了 RCA 领域中最具代表性的几篇论文结果：

研究 / 方法	数据集	指标	最佳准确率
ONLINE MULTI-MODAL ROOT CAUSE ANALYSIS[1]	Train Ticket	PR@5 (≈AC@5)	~40%
RCAEval[2]	Train Ticket	AC@3	70~88%
OPENRCA[3] (LLM-based)	独有数据集	AC@1	~15%
GALA[4] (Graph-Augmented LLM)	OnlineBoutique	AC@3	60~78%

以上所有对比数据均来源于各论文公开结果或复现实验。

Syncause 分别在 OnlineBoutique 和 Train Ticket 两个测试场景上进行复现，在我们特有的 eBPF 数据的辅助下，AC@3 准确率均达到 96.67%。

模型 / 方法	案例数	AC@1 准确度	AC@3 准确度
grok-4-fast-non-reasoning	30	86.67% (20/30)	96.67% (29/30)
qwen-plus	30	90% (27/30)	96.67% (29/30)

同时，当我们关闭 eBPF 辅助数据，仅使用传统指标与日志时，AC@1 下降至 60%，AC@3 下降至 90%——这体现了 eBPF 数据在提升根因分析准确率中的关键作用。

在这些结果中可以看到一个明显对比：Syncause RCA 在保持在线、无需训练的前提下，准确率超越当前主流研究方法。

测试案例中主要包含高CPU使用率、高内存占用、网络延时、网络丢包等故障，我们仍然在不断扩充案例场景，后续将持续公开测试结果。

---

为什么 Syncause 能做到？​

eBPF 驱动的底层观测能力​

Syncause 基于 eBPF（Extended Berkeley Packet Filter） 技术实现实时捕获内核级事件，如系统调用延迟、锁等待、IO 阻塞等，形成比传统指标更直接的因果线索。  

当 LLM 接入这些“真实执行路径”信息后，能更精准地判断问题根因所在的服务与资源。

LLM + 可观测数据的因果推理架构​

Syncause 不依赖固定训练模型，而是通过 LLM 的语义理解能力，对多模态数据（Metrics、Logs、Traces、eBPF）进行因果推理：

1. LLM 生成可能的根因假设；
2. Syncause 验证这些假设与观测数据是否一致；
3. 将推理路径可视化展示给用户。

即使分析结果不是百分百准确，Syncause 仍然展示推理链条，让用户理解“系统为什么这样判断”。

这种“解释性推理”让 RCA 不再是一个“黑盒模型”，而是一场透明的推理过程。

可复现、实时、无需模型训练​

与传统机器学习方法需要长时间训练不同，Syncause 在任何环境下即装即用。

在基准测试中，Syncause RCA 能够直接在线推理，单故障分析案例平均延迟 < 3 分钟，成本低于0.06美元。

向更智能、更透明的 AI SRE 迈进​

我们相信 RCA 领域下一步的发展方向，不是单纯提升准确率，而是让分析过程变得可验证、可比较、可重现。

Syncause Benchmark 结果已在 GitHub 上开源，搜索syncause-benchmark即可找到。

我们的愿景不仅是打造一款产品，而是推动整个行业走向透明、可验证的 AI SRE Agent 生态。

欢迎关注！未来版本将持续加入更多内容：

• 更多 LLM 模型性能对比（Claude, GPT, Gemini 等）
• 新的数据集与更复杂的分布式系统场景
• 因果验证与信任度量化指标

结语：AI正让根因分析重新发生​

系统问题总会发生，但分析方式正在改变。AI 让我们离“智能运维系统”更近了一步。

Syncause 的核心不是取代工程师，而是让每一次故障分析都有迹可循。

即使结论不完美，过程仍然可验证、可学习、可改进。

如果你希望亲自验证这些结果、或在你的系统中体验智能 RCA，欢迎联系我们或访问官网进行试用： 👉 https://syn-cause.com

---

参考文献:​

[1] Lecheng Zheng, Zhengzhang Chen, Haifeng Chen, Jingrui He. 2024. Online Multi-modal Root Cause Analysis. arXiv preprint arXiv:2410.10021.

[2] Luan Pham, Hongyu Zhang, Huong Ha, Flora Salim, and Xiuzhen Zhang. 2025. RCAEval: A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data. In The 2025 ACM Web Conference (WWW). 777–780.

[3] Junjielong Xu, Qinan Zhang, Zhiqing Zhong, Shilin He, Chaoyun Zhang, Qingwei Lin, Dan Pei, Pinjia He, Dongmei Zhang, and Qi Zhang. 2025. OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures?. In The Thirteenth International Conference on Learning Representations.

[4] Yifang Tian, Yaming Liu, Zichun Chong, Zihang Huang, Hans-Arno Jacobsen. 2025. GALA: Can Graph-Augmented Large Language Model Agentic Workflows Elevate Root Cause Analysis?. arXiv preprint arXiv:2508.12472.

“很多用户觉得我们在吹牛，根因分析做不出来，其实我们一直在做对的事——现在论文也证明了这点。”

背景​

在当前AIOps领域，主流做法多集中在围绕 Trace、Log、Metrics 的机器学习建模与关联挖掘，寄希望于在复杂数据中“找出”故障根因。但我们在与大量企业沟通后发现，这种方式在实际生产环境中往往难以落地 —— 算法容易泛化失败，结果无法解释，根因归因流于表面，甚至被质疑“是否真的能做到”。

我们的观点是：如果一个经验丰富的人都很难给出确定且可解释的根因判断，而需要依赖现象推测与试错过程来还原问题，那算法更不可能自动做到这一点。因为这些故障往往需要通过上下文、调用链、线程与资源的交互等复杂的程序行为路径来还原，不是简单依赖几个KPI指标变化，靠模型“拟合波动模式”就能判断出来的。这类问题的本质并不是数据挖掘，而是“对程序运行机制的理解”与“对故障传播路径的观察”。只有把这些底层行为真正观测到，才能找出根因。

我们致力于通过eBPF技术直接采集线程级的内核资源交互信息，从线程与锁、磁盘、CPU调度、futex、epoll、socket 等系统资源的精细互动中还原问题现场。然后基于这些数据，结合我们的经验构建出专家规则小模型，并使用业界相对比较成熟的算法来实现故障根因分析 —— 用最基础但最扎实的方式解决根因定位的“最后一公里”。

我们这套理论比较新，和很多用户交流的时候，很多用户觉得我们在吹牛。我们理解这种质疑，但我们一直坚信：我们不是在“吹牛”，我们是在做对的事。

最近我们看到一篇 arXiv 上的最新论文《eBPF-Based Instrumentation for Generalisable Diagnosis of Performance Degradation》（2025年5月），首次从学术角度全面验证了我们坚持的方向是可行且高效的。

该研究提出了一套跨应用、跨语言的 eBPF 监控体系，通过16类内核子系统指标构建“线程行为画像”，在Kafka、MySQL、Cassandra等典型系统中完成了无需trace、无需日志的自动根因归因，准确识别出锁竞争、磁盘瓶颈、CPU争用、外部依赖等多种常见性能劣化问题，诊断路径完全可解释。

我们采集的数据基本一致，只是分析角度和论文略有区别，下面是论文的核心思路。

---

论文思路​

这篇论文的核心目标，是探索一套无需依赖应用层trace和日志，仅通过eBPF从系统内核采集“线程与关键资源交互数据”，就能完成跨应用场景的性能劣化诊断的方法论。

1. 核心问题定义​

论文指出，当前性能诊断面临两个核心难点：

• 第一是数据粒度不够：系统级指标（如CPU利用率）过于粗糙，无法解释“到底哪个线程在等待什么资源”；

• 第二是通用性差：很多诊断方法依赖特定中间件、语言、日志或trace结构，难以跨系统使用。 因此，作者尝试构建一个通用、跨平台、跨语言的“线程行为画像”体系，通过eBPF捕获线程与资源的交互路径，反推出性能问题的根因。

2. 指标体系设计​

作者基于六大内核子系统构建了16类eBPF指标，具体包括：

子系统	指标例子	描述
调度	runtime，rq time，iowait time	线程在CPU、runqueue、iowait上的耗时
futex	futex wait time，wake count	锁竞争情况，包括等待和唤醒频次
pipe/socket	pipe wait time，socket wait count	跨线程通信延迟，识别阻塞关系
epoll	epoll wait time，epoll file wait	识别异步IO等待瓶颈
block IO	sector count	识别磁盘压力或争用情况
VFS/网络	多个等待与访问频次指标	提供线程级资源使用视角

指标采集遵循“只监控与目标应用有关的线程”，避免全系统追踪带来的性能开销。

3. 分析方法：选择性线程追踪 + 行为分布变化检测​

诊断的关键流程如下：

1. 识别入口线程：通过 socket wait、epoll wait等指标找到对外提供服务的入口线程；
2. 追踪依赖线程：只追踪与入口线程有pipe/socket/futex等资源交互的“对等线程”，逐步构建线程依赖链；
3. 检测异常分布变化：将每个线程的指标时间序列与业务KPI（如95延迟）对齐，对齐后若出现类似分布漂移，即可标记该线程及其资源为瓶颈点；
4. 推断资源约束路径：如果瓶颈线程依赖于某共享资源（如同一个pipe、锁、磁盘），则反推出具体瓶颈资源；
5. 生成可解释路径：最终输出“哪个线程被谁阻塞、阻塞了多久、原因是哪个资源”，而非一个黑盒评分。

这种方法类似于“因果链回溯”，但基于资源交互而非trace span依赖，因此更真实可靠。

4. 实验设计与验证​

论文通过多个真实系统场景验证该方法，包括：

• MySQL 磁盘与锁竞争混合瓶颈；
• Redis CPU瓶颈；
• Kafka 外部服务阻塞；
• Teastore 微服务依赖延迟放大。

实验结果表明，仅靠这16个eBPF指标，就能精准还原各类瓶颈根因，诊断准确率和解释性俱佳。且 instrumentation 开销极低，Redis 平均增加仅 0.3ms。

5. 总结与价值​

该论文的几个关键贡献与我们坚持的方向高度一致：

• 以线程为单位，而非进程或服务；
• 以资源交互为基础，而非指标波动为假设；
• 只追踪相关线程，避免trace噪声污染；
• 可解释性极强，每一个瓶颈都有清晰的因果链路；
• 通用性极高，适用于多语言、跨系统架构。

这使得论文不仅是我们方法论的理论背书，更是整个“新一代根因分析体系”的奠基石。

---

论文原文 https://www.arxiv.org/pdf/2505.13160