2025 年 4 月 19 日，西安邮电大学计算机学院的第三届 eBPF 开发者大会在长安校区如期举行。本届大会选择以线下举办、线上同步直播的形式进行，吸引了众多技术爱好者和行业专家的关注。乘云数字技术专家匠心受邀参加，并为大家呈上了“ebpf 在故障定位中的应用”的主题演讲。

下面是关于这次演讲的内容精选。

ebpf 在故障定位中的应用

故障定位相关的三大类产品

以往与运维或故障定位相关的产品，大致可以分为三大类，NPM, APM 和 BPM。

• NPM 产品关注的对象是网络设备以及网络流量相关的指标。一方面 NPM 会通过 NetFlow, sFlow, SNMP 等协议采集网络设备的内部数据，另一方面，这类产品还会通过网络旁路抓包的方式，对流量进行协议解析并计算出各类指标。

• APM 产品关注的对象是应用/服务，是应用/服务的内部工作状态，关注接口相关的黄金指标，如请求/响应的吞吐率、错误率、资源饱和度等。APM 产品的主要功能有链路追踪、日志关联、服务拓扑等，目前主流的实现方案有应用代理、字节码增强等。

• 最后一类是 BPM，BPM 产品专注于业务指标和流程性能监控的技术领域，涉及业务数据建模技术，业务数据关联等。

通过以上三类产品的简单描述，可知它们的目标对象和解决的问题各不相同，甚至由一个公司的不同部门人在使用。平时，每个部门的人只关心他们职能范围之内的事情，比如：

• NPM 产品通常由网络运维部门的人使用，用来观察公司的网络设备是否正常工作，网络传输是否顺畅；

• APM 产品可能由软件平台/软件基础设施的团队使用，用来维护公司的基础组件、中间件、数据库等是否运行无误；

• 而 BPM 产品更多地跟业务团队紧密结合，用来支撑业务的高效运转。

相安无事的时候，一切其乐融融，但是当一个故障发生，而又无法快速定位到故障原因时，“故障就会转移”，一会儿怀疑是网络原因，一会儿怀疑是服务原因。三类产品齐上阵，却因各自独立，数据无法关联，无法输出统一有效的排障流程。最终只能多部门联合，通过各种各样的日志信息，靠人工一点一点地对比梳理来确定原因，这过程往往要耗费数天之久。

eBPF 打破工具壁垒

eBPF 的出现可以帮助打破工具壁垒，打通三类产品的数据通道，在此简单描述一下这个过程：

• NPM 从流量中可以很轻易地获取到连接的五元组（协议+ IP + Port），以及以连接为视角的时延、吞吐率等指标。

• APM 以进程和服务为对象，通过进程 ID、进程名为视角建立接口的各类指标。

• BPM 同样以进程和服务为对象，建立业务的指标。

通过 eBPF 挂载到如 sendto 的系统调用函数，从中可以获取到进程和套接字信息（包含五元组信息），这样，NPM 和 APM 通过 eBPF 的信息，轻易地实现了连接，就像数据库中两张独立的数据表通过外键实现关联一样。

类似的，eBPF 的 uprobe 可以挂载到用户态的函数，从中获取业务相关的信息，再根据进程信息，完成与 NPM 和 APM 的数据连接。

乘云作为一家专业全面的可观测方案提供商，结合自身产品的特点，我们以 APM+eBPF+NPM 为切入点，提供了核心能力如下：

●     将采集指标深入到系统内部，如 tcp 连接队列、io 时延。

●     拓展 NPM 网络指标的维度，如进程 id, netns.

●     提高 NPM 相关指标的精度，如 rtt, rtt-var.

●     事后分析告警进化为事前预警和事中告警

●     部分业务数据的采集能力

案例

下面，我们来看一个案例，如下图：

观察图中的报文数据，我们总结出如下信息：

●     这是一条 HTTP/1.1 的长连接会话。

●     从第 5、9 报文看出，服务端接收到请求数据后，立即确认。

●     从第 10 个报文开始，服务端不会立即确认接收的数据，而是与响应数据一起确认，这说明 tcp 延迟确认机制开始工作。

●     从第 7、11、14、17 报文可以看出，客户端每次都是延迟约 40 ms 回复确认，这是常见的延迟确认机制超时时间。

在上图中，接下来有可能会发生以下的情形 (假设服务端没有设置 TCP_NODELAY 选项，即没有关闭 nagle 算法)：

●     服务端在发送响应数据时，每次的数据量不足 MSS（1460 字节）大小，常见于通过 chunk 方式传输。

●     由于客户端的延迟确认，服务端每次都必须 40 ms 以后才能发送后续数据，这极大地限制了吞吐量（< 1460 / 40ms = 36 KB/s）。

以上的网络行为，通过 eBPF 的能力可以实时地观察到协议栈的工作状态，再结合 APM 对应用程序的分析，可以清晰地识别应用潜在问题。

接下来，我们看一段代码：

这段代码的本意是希望设置套接字的接收缓存区为 512 KB，结果程序运行正常，没有任何错误日志，但事实是该设置没有生效。通过下图的报文信息，可以发现原因: 缓存区的大小最终反应在 TCP 协议的接收窗口，大于 64 K 的接收窗口，需要通过 TCP 窗口扩展机制，而该扩展在 TCP 连接的三次握手时就已经完成。因此，对于从 accept 返回的套接字将继承 listen 的套接字设置，结果缓冲区仍然为 256 KB。

NPM 可以观察到 TCP 协议的各种字段值，但是却无法判断这些设置是否是真实的应用设置。而 eBPF 可以观察应用程序的上下文调用，再加上 APM 的跟踪信息，可以准确地检测到类似的问题。

Databuff 根因定位

最后，介绍一下乘云的 Databuff 根因定位功能，关于平台的试用申请、操作介绍等详细信息可以参考我司之前的技术文章和视频公众号。这里简要介绍一下目前平台集成的部分 eBPF 能力。

首先，在故障注入时，使用 eBPF 可以制造更多的故障类型，如造成某个请求或是系统调用的超时，或是根据注入时的故障参数，通过 sockops 类型修改某些网络设置，如下图所示

其次，通过 eBPF 采集的系统内部指标，为根因分析提供了更精准和实时的数据来源，极大提高故障定位的准确性。下图展示了 Databuff 平台在检测到网络指标出现异常时，推断出出现故障的服务接口，以及受到影响的服务调用链。

eBPF 技术对于运维产品带来的技术性推动，促进 NPM, APM,BPM 产品相关功能的整合，从而有助于更高效地定位 IT 故障。此外，我们乘云也在积极地拥抱 eBPF，正逐步地使用 eBPF 技术增强我们的故障注入平台和根因定位功能。