跳到主要内容

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

查看所有标签

根因分析新范式:我们的实践方向被最新研究证实

· 阅读需 9 分钟

cover 图

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

背景

在当前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指标,具体包括:

子系统指标例子描述
调度runtimerq time,iowait time线程在CPU、runqueue、iowait上的耗时
futexfutex wait timewake count锁竞争情况,包括等待和唤醒频次
pipe/socketpipe wait timesocket wait count跨线程通信延迟,识别阻塞关系
epollepoll wait timeepoll file wait识别异步IO等待瓶颈
block IOsector 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

1 图