一文带你了解可观测领域中APM与eBPF的技术差异

近年来，随着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采集方案仍然是有力竞争者