根因分析新范式：我们的实践方向被最新研究证实
“很多用户觉得我们在吹牛，根因分析做不出来，其实我们一直在做对的事——现在论文也证明了这点。”
背景
在当前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. 分析方法：选择性线程追踪 + 行为分布变化检测
诊断的关键流程如下：
- 识别入口线程：通过 socket wait、epoll wait等指标找到对外提供服务的入口线程；
- 追踪依赖线程：只追踪与入口线程有pipe/socket/futex等资源交互的“对等线程”，逐步构建线程依赖链；
- 检测异常分布变化：将每个线程的指标时间序列与业务KPI（如95延迟）对齐，对齐后若出现类似分布漂移，即可标记该线程及其资源为瓶颈点；
- 推断资源约束路径：如果瓶颈线程依赖于某共享资源（如同一个pipe、锁、磁盘），则反推出具体瓶颈资源；
- 生成可解释路径：最终输出“哪个线程被谁阻塞、阻塞了多久、原因是哪个资源”，而非一个黑盒评分。
这种方法类似于“因果链回溯”，但基于资源交互而非trace span依赖，因此更真实可靠。
4. 实验设计与验证
论文通过多个真实系统场景验证该方法，包括：
- MySQL 磁盘与锁竞争混合瓶颈；
- Redis CPU瓶颈；
- Kafka 外部服务阻塞；
- Teastore 微服务依赖延迟放大。
实验结果表明，仅靠这16个eBPF指标，就能精准还原各类瓶颈根因，诊断准确率和解释性俱佳。且 instrumentation 开销极低，Redis 平均增加仅 0.3ms。
5. 总结与价值
该论文的几个关键贡献与我们坚持的方向高度一致：
- 以线程为单位，而非进程或服务；
- 以资源交互为基础，而非指标波动为假设；
- 只追踪相关线程，避免trace噪声污染；
- 可解释性极强，每一个瓶颈都有清晰的因果链路；
- 通用性极高，适用于多语言、跨系统架构。
这使得论文不仅是我们方法论的理论背书，更是整个“新一代根因分析体系”的奠基石。
论文原文 https://www.arxiv.org/pdf/2505.13160
