最近注意到一场网络辩论：《eBPF 到底是可观测性领域的神器 or 鸡肋？》，国内 eBPF 领域的代表 DeepFlow 和国内可观测性厂家的代表观测云对此展开了热烈的探讨，那么 eBPF 对于可观测性领域到底是什么样的地位？eBPF 到底是不是神器呢？带着这个问题我们来看看 eBPF 在国内外的应用。

到底什么是 eBPF？

回答这些问题之前，先了解下到底什么是 eBPF，这里我们以问答的形式来展开。

什么是 eBPF？

eBPF 其实不算是一种新的技术，BPF 最早是伯克利包过滤器（Berkely Packet Filter）的简称，内核自 3.15 开始对 BPF 进行扩展，通过增加 BPF 程序寄存器个数、扩充 BPF 程序可使用内存以及增加多个 BPF 事件使得 BPF 具备高可定制性。为了和扩展前的 BPF 进行区分，将 3.15 之前的 BPF 称为 cBPF（classic BPF），扩展后的 BPF 称为 eBPF （extended BPF），而 BPF 也从一种缩写更多的成为了一种技术的代称。

以上的解释来源一篇微信公众号文章：《服务拓扑串联难？eBPF为滴滴可观测带来解题新思路》，个人觉得是对 eBPF 可观测性技术比较客观的介绍。

用 eBPF 可以做什么？

实际上，eBPF 的能力不仅仅用在可观测性领域。eBPF 这种不需要修改内核代码，从而内核功能进行自定义的能力，使其在流量调度、安全性、可靠性和性能方面都有所应用。例如，Cilium 基于 eBPF 提供了多集群路由、替代 kube-proxy 实现负载均衡、透明加密以及网络和服务安全等诸多功能。以下仅讨论 eBPF 在可观测性方面的应用。

eBPF 对内核版本有什么要求？

不管是海外的 eBPF 开源项目 Pixie 还是国内的 DeepFlow，完整的 eBPF 可观测性能力都需要内核版本大于 4.14。实际上，低版本的内核也可能引入一下 eBPF 相关的 patch，也可能会支持其能力。笔者在公司 3.10 内核的 Kubernetes 集群安装 DeepFlow 后，Distributed Tracing 只有 NIC 类型，并没有完整的调用链，由此可见，eBPF 对内核版本是有比较高的要求。

eBPF 对性能影响如何？

不管是 Pixie 还是 DeepFlow 等 eBPF 开源项目，宣称对性能影响非常小。实际上，为了实现跨线程，跨协程的完整追踪能力，eBPF 势必要引入 uprobe 能力，正如滴滴对 eBPF 的实践报告来看，uprobe 涉及到用户态和内核态的两次切换对性能有不少的影响。

Windows 支持 eBPF 吗？

2021 年，微软开源了自己的 eBPF 能力：https://github.com/Microsoft/ebpf-for-windows，按照官网的描述来看，其支持 Windows 10+ 和 Windows Server 2019+ 的版本。

eBPF 开源项目 Pixie 不支持 Windows。DeepFlow 虽然官网宣称支持 Windows，但是没有找到任何其 Agent 的 exe 安装包，所以也无法验证。

eBPF 有什么优势？

eBPF 零插装实现的 Distributed Tracing 和 Continuous Profiling 能力，不需要修改代码，这种愿景是极好的。并且，eBPF 的能力能够提供一些传统 APM agent 无法观测到的网络细节，在有些场景下，能够为我们带来不一样的视角。

eBPF 有什么局限性 ？

任何技术，都有其优越性，也有其局限性。实际生产的系统，其调用关系是非常复杂的，使用的技术栈也是参差不齐，至少 eBPF 还没有完全解决跨线程和跨协程的问题，就很难具备生产使用的意义。但是我们应该保持对新技术的跟进，并贡献自己的力量，让这种不可能变成可能。

eBPF 和可观测性的关系

实际上，不管是国外的可观测性 Pixie 还是国内的 DeepFlow，eBPF 更多的提供的是一个零插装的工具。eBPF 不能代表可观测性，可观测性也不完全通过 eBPF 来实现。从海外比较先进的可观测性的厂商来看，他们是怎么定位 eBPF 的呢？

2022 年，DataDog 收购了来自以色列的 eBPF 项目 Seekret，作为补充其 eBPF 相关能力。目前 DataDog 基于 eBPF 提供了三种能力：

• Universal Service Monitoring: 类似 DeepFlow 宣称的零插装分布式追踪能力。

• Network Performance Monitoring: 网络监控相关的能力。

• Cloud Security Management: 云基础设施安全相关的能力。

DataDog 利用 eBPF 完善了其可观测性的信号量，除了原来的 metrics、logging、tracing、rum、profiling 等，通过 eBPF 扩容加入了 eBPF trace 和 network 的信号量。所以说，eBPF 仅仅是作为 DataDog 的一个 Data source 的补充。实际上，DataDog 宣称的可观测性能力，是覆盖了 RUM (Real User Monitoring)，APM (Application Performance Monitoring)，Logs，Infra，Metrics，Security 等多方位全面的能力。

New Relic 开源的 Pixie 是目前 eBPF 最火热的项目。从 New Relic 的数据接入来看，也仅仅把 Pixie 作为一种 Kubernetes 的可观测性工具的 Data source。New Relic 的可观测性集成能力包括了从前端 Web/Android/iOS 等设备，也包括了各种语言的后端，以及各种类型的中间件和各种各样的平台。

Dynatrace 通过 eBPF 获取 NetTracer，目前支持 Centos 和 Ubuntu 两个平台，主要对网络连接进行解析，获取网络相关的监控数据。比较核心的服务调用 Trace 目前还是通过 Dynatrace 的 Agent 进行获取。

所以说，eBPF 作为一个还在不断完善的技术，在可观测性领域只是作为一种数据收集的手段。往往我们面临的系统是极其复杂的，不可能依靠 eBPF 一个信号量完成所有可观测性的事情，我们只有不断地充分地收集系统产生的任何维度的数据，来健全我们的可观测性能力，才能做到在面临故障时游刃有余。

eBPF 无法完全替换 APM

eBPF 相对传统的 APM，有其先进性，但是 eBPF 还不能完全替换传统的 APM 技术，究其原因有如下三点：

1. 数据采集不全：不管是 DataDog 还是 New Relic，都没有把 eBPF trace 作为其 APM 的推荐接入方式，究其原因，主要在于 eBPF 的 trace 还无法完全覆盖 APM Agent 采集到的数据。作为一名 Java 工程师，我可能要关注每一次调用的方法级别的监控，要知道在什么包什么类的哪一行代码执行了多长时间，以及抛了什么 Exception。eBPF 在用户态无法实现这么细粒度的追踪能力，但是 APM Agent 就可以很轻松实现。所以，eBPF 无法完全替换 APM，两者其实可以作为补充，实际上 DeepFlow 也支持把 SkyWalking 和 OpenTelemetry 作为其外部数据源进行补充。

1. 无法覆盖全部场景：笔者的公司在 AWS 上使用了大量的 lambda 函数，目前我们还是再使用 DataDog lambda 监控能力。对于这种 serverless 服务，服务端不在掌控下的场景，eBPF 也就失效了，也就无法替代传统的 APM。其次，由于 eBPF 的局限性，目前对于跨线程和跨协程的应用支持并不够友好，部分的生产系统会存在链路缺失的问题。

1. 无法追踪业务：APM Agent 不光提供了分布式追踪的能力，我们可以利用其提供的 SDK 添加任何业务需要的 tag 和 log，从而实现业务层面的追踪能力，比如追踪特定用户或订单的调用链路。eBPF 虽然可以通过一些方式注入业务层面的语义，但是需要业务相关的 ID 要在请求流量中进行呈现，这种灵活性是无法比拟 APM Agent。

综上，eBPF 不能完全替换 APM Agent，反而这两者之间的补充可能是一个比较好的方案。

eBPF 真正的使用场景

不管是国外的 DataDog，NewRelic，Dynatrace，还是国内的观测云也好，基本上对 eBPF 的定位在于 request trace 和 network monitor 能力，DeepFlow 对 eBPF 的使用场景做了更多的一些扩充，无埋点的 request trace, request log 和 network metric，其 Profiling 的能力借助于 Pyroscope 来实现。

从开源生态来看，国内的 DeepFlow，海外的 Pixie，opentelemetry-ebpf，最近还有 Grafana 开源的 Beyla，越来越多的 eBPF 开源项目开始涌现。

eBPF 的优点在于无埋点零侵入，对于 Java、Python、.Net、PHP 这类由虚拟机运行的代码，本身的 APM Agent 就可以做到无侵入监测，eBPF 可以作为网络层 span 的补充，实现应用调用的更细粒度的观测。对于 Go、C/C++ 类型的服务，只能通过埋点的方式实现 APM 能力，eBPF 优势相对就比较明显了，尤其对于混合异构的系统，eBPF 能够快速实现不同语言，不同技术栈之间的 trace 能力，这点是非常有吸引力的。

其次，eBPF 能给我们带来不少的惊喜，比如 Pixie 利用 eBPF 实现的 Dynamic Golang Logging，自动插入一条 fmt.Printf 语句打印每个函数的入参， 还有一些和 DB Query 结合，主机 IO 情况结合的场景，能够为我们提供不少便利的观测能力。

所以，我不认为 eBPF 的出现是为了解决传统行业无法安装 Agent 的问题，实际上，大量的电信、能源、金融行业的系统仍然跑在比较老的内核版本上，一些传统行业的生产制造系统大部分是运行在 Windows Server 上，这类系统就算利用 eBPF 能够观测到的数据还是比较少，如果是利用 BPF 这类技术，这跟传统的 NPM 解决方案没有什么两样。

可观测性跟传统监控最大的区别在于，可观测性采集的数据颗粒度是远远大于传统的监控系统，作为一个比较好的可观测性平台，就必须具备海量数据的收集和分析能力。eBPF 其实作为可观测性的一种数据源的补充，可以给我们提供更细粒度的观测能力，或者提供一种全新的信号量，从而使得我们更好的掌控系统运行情况。

最后的话

eBPF 可观测性作为一种零插装技术，其在 Distributed Tracing 和 Network Performance Monitoring 表现出来的能力，目前我更多还是把它定位为网络可观测性的技术。eBPF 不是可观测性领域的神器，它解决不了所有问题，但它绝对是可观测性领域的一个亮点技术，值得我们长期跟进。

所以说，这场辩论的结果并不重要。作为一个客户，我需要 DeepFlow 宣称的 eBPF 实现真正意义上的零侵入性的分布式追踪能力。同样，我也需要观测云提供的统一可观测性平台能力，实现数据的统一采集、统一存储和统一分析能力。就像 Seekret 之于 DataDog，实际上 eBPF 技术的好坏并不能决定任何其中任何一个产品的好坏，作为一个企业的技术决策者，在合适的时机引入合适的产品解决现阶段的痛点更加重要。