​

近年来，随着 eBPF 技术的兴起，很多人有这样的疑惑：eBPF 和 APM 有什么区别？他们是竞争关系还是合作关系？本文将就此展开讨论，并给出切实有效的落地方案。

01APM

APM 全称：Application Performance Management。目前市场上的 APM 方案大多是参考 Google 的 Dapper（大规模分布式系统的跟踪系统）实现的，如 Cat、Skywalking。

APM 技术，历经长期演进与积淀，逐步趋向采纳 OpenTelemetry 这一标准化的开源框架，实现了 Tracing 领域的深刻变革，极大促进了追踪技术的统一化、标准化进程，标志着监控技术迈向了一个全新的专业化高度。

02eBPF

eBPF 全称：extended Berkeley Packet Filter，扩展伯克利数据包过滤器。它是一项功能强大的技术，最初起源于 UNIX 系统中的 BPF，可以在 Linux 内核中进行编程，以实现高效的系统监控、网络分析和安全审计等功能

03APM 和 eBPF 的对比

3.1 采集的位置对比

• APM 主要是在业务程序代码中进行拦截：意味着可以拿到业务进程中更多的信息

• eBPF 主要是在操作系统代码中进行拦截：意味着可以拿到操作系统中更多的信息

3.2 采集的数据对比

在可观测领域中，APM 和 eBPF 是两种不同的采集方式，最终目的都是为了实现排查故障。所以，我们必须对故障有一个清晰的认知。大多数的应用故障是从代码中产生的。不同类型的代码对应的数据采集方式也有所不同。

目前大概有 5 种采集方案：

① APM 方案

• 对业务程序：采用字节码插桩或者手动埋点的方式

② eBPF 方案

• 对业务程序：采用 eBPF 解析流量数据包的方式

• 对操作系统：采用 eBPF 对关键内核方法进行检测

③ APM+指标采集+流量采集

• 对业务程序：采用字节码插桩或者手动埋点的方式

• 对操作系统：采集操作系统/proc 文件的指标数据，对于一些 socket 指标可以通过连接跟踪来采集

④ APM+eBPF

• 对业务程序：采用字节码插桩或者手动埋点的方式

• 对操作系统：采用 eBPF 对关键内核方法进行检测

⑤ APM+指标采集+流量采集+少量 eBPF

• 对业务程序：采用字节码插桩或者手动埋点的方式

• 对操作系统：采集操作系统/proc 文件的指标数据，对于一些 socket 指标可以通过连接跟踪来采集，对网络 Span 跟 Trace 的关联可以采用 eBPF

下表中，我们列出了所有的代码分类，和定位故障所需要的数据，以及对应的采集方式。

3.3 采集方案的优劣势

下表中从 18 个维度对 5 种不同采集方案做了对比。

​

我们又对每种采集方案的落地情况做了对比，如下表所示。

04 总结

4.1 未来方向

总体上看，APM 和 eBPF 各有优略，擅长的领域不同，谁也无法替代谁，二者应该是合作关系，共同完成对业务程序和操作系统的全面可观测。

• APM 完成微服务的可观测

• eBPF 完成操作系统网络和磁盘 IO 的可观测

4.2 落地策略

鉴于 eBPF 对内核版本要求比较高、同时 eBPF 自身还在快速变化迭代中，当前阶段更稳妥的选型方案是 APM+指标采集+流量采集+少量 eBPF 采集。

​

过去 5 年的方案

• APM 和 指标采集、流量采集有些还比较独立，有些已经融合在一起。

未来 5 年的方案

• 由于操作系统内核限制的原因导致 eBPF 还暂时无法大力的推广，更多还是借助指标采集+流量采集来完成。

• 针对一些操作系统内核版本高的场景，可以使用 eBPF 采集到更加精确的操作系统 Span 和业务 Trace 进行关联。

未来 10 年的方案

• 当操作系统内核普遍升上去之后，APM+大量 eBPF 方案才会得到普及。

• 不过此时的 APM+指标采集+流量采集+少量 eBPF 采集方案仍然是有力竞争者

​