根因分析新范式:我们的实践方向被最新研究证实
“很多用户觉得我们在吹牛,根因分析做不出来,其实我们一直在做对的事——现在论文也证明了这点。”
背景
在当前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