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