根因分析新范式:我们的实践方向被最新研究证实
“很多用户觉得我们在吹牛,根因分析做不出来,其实我们一直在做对的事——现在论文也证明了这点。”
背景
在当前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从系统内核采集“线程与关键资源交互数据”,就能完成跨应用场景的性能劣化诊断的方法论。