当下，eBPF 无疑是最火热的技术之一，它为云原生环境下的网络、安全和可观测性解决方案提供了全新的思路。
作为一种无需入侵应用代码、直接向操作系统内核安全添加代码的革命性技术，eBPF 使得企业能够不依赖内核固有的指标数据，直接编写代码收集自定义数据，并生成可观测性指标和事件。这不仅将可观测性扩展到内核，还能够实现零插桩的应用代码可观测性，同时保证了运行安全和开销可控。于是，不少人认为 eBPF 是可观测领域的未来之星。
然而，也有人觉得，eBPF 的作用被夸大了。它并不是适合每个项目或生态系统的灵丹妙药 —— 仅限于 Linux 和它的最新内核。而且“沙箱程序也是有限制的”，通过限制程序可以访问的操作系统部分，功能也可能受到限制。因此 eBPF 只不过是可观测体系中的一个小补充罢了，并不是可观测领域的未来主要方向。
对此，真实的情况是怎样的？实际应用中，它更有可能帮大忙，还是拖后腿？对此，开源中国邀请了云杉网络研发 VP 向阳、观测云创始人兼 CEO 蒋烁淼、《SRE 原理与实践》作者张观石、某智能制造业运维吴秋鑫、SUGA Data Science Team Leader Jaron Tam，一起进行了讨论。
为什么说 eBPF 是神器？
正方：向阳 speaking ——
是不是神器，有对比就能看出来。
以前我们使用 APM Agent 来实现可观测性，它对于业务代码的侵扰性使得落地和维护非常困难，它在云原生环境下的盲点使得故障定界非常困难。
首先是侵扰性：
比如说我们把一个 SDK 或者一个 Java Agent 插入到一个应用程序里面来以后，此时应用程序已经变了。现在来发起一个灵魂拷问：我们本来要观测的原始程序 A，在插入 SDK 或 Java Agent 以后已经变成了 B，此时我们到底是实现了 A 的可观测性，还是 B 的可观测性？
被迫插桩后的应用，还是以前那个应用吗？
不仅如此，之后还有一堆随之而来的问题：
- 代码冲突：多个 Java Agent 运行时冲突，或者 SDK 依赖库版本编译时冲突，怎么办？
- 维护困难：Agent 多久可发版一次，要维护多少个版本，要适配多少种语言？
- 边界模糊：预期之外的性能衰减、运行故障，是谁的锅？
我们可以看到，这些障碍使得 APM Agent 这种方式不适合作为一个服务能力来跨团队提供，它只能是开发团队的一个自主行为，而且是开发人员可以百花齐放灵活选择具体方案的行为。而 SkyWalking 等开源社区的火热其实也间接说明了一点，APM 在开发者主导的开源领域获得了成功，但难以（至少尚未）在企业服务领域复制这样的成功。在一些非常核心的领域，例如金融、能源、电信、制造等行业，由于部门分工细致、软件外采普遍等特点，插桩的方案很难落地。
此外是盲点：
在云原生的场景下，两个 APP 之间的通信其实是很复杂的。除了业务代码框架代码以外，还有更复杂的网络传输、系统调用、数据库访问、中间件访问、各种网关和代理转发等等。而除了业务代码和框架代码以外，复杂的云原生基础设施通信路径都难以插桩。这时候出了问题，定界十分困难。
比如说，一个 Pod 访问一个云服务发生了故障，作为一个开发，你的责任边界是这个 Pod 内的应用进程，但是你去提工单的时候，怎么确定要提给哪个部门？一个 Pod 里面有很复杂的通信路径，从业务代码到系统调用，再到网络收发，可能还会有 Sidecar 的流量拦截，出了 Pod 以后还有 IPVS，到 KVM 以后还有 vSwitch/Bridge，可以看到非常复杂，而且基本上每一跳关键节点都无法插桩。此时问题的定界基本靠猜。
我们认为，eBPF 是解决侵扰性和盲点的绝佳方案。eBPF 可以去追踪服务内的行为，也可以去追踪服务间的行为，全程零侵扰，不用改代码，当天部署当天就能用；遇到问题，由于它的全栈覆盖能力，通常 5 分钟就能完成定界。
没有 eBPF，插桩只能靠强推，盲点定界只能靠瞎猜。而有了 eBPF ，这些都不是问题，真正的云原生应用可观测性才能得以实现，你说它是不是神器？
eBPF 只是个普通的工具而已，别夸大了
反方：蒋烁淼 speaking ——
先反对一下把 eBPF 吹成神器的调调。
eBPF 只是个手段，不要把手段当成目的。
第一，不要把可观测性，等同于数据采集的方便性。
第二，正方讲的都是可观测性只用于排障的部分，但可观测性的目的不只是用于排障，排障只是其中非常小的一个阶段。
第三，可观测性本身最大的价值就是构建一个完整的、了解系统的平台，而 eBPF 只是了解这个系统的手段之一。
不能因为我本身做 SD-WAN 相关，我就变成一个榔头满世界找钉子。可观测性可不仅仅是干这个的。
我们今天讲的主题是 eBPF 对于可观测性的价值。那 eBPF 对可观测性到底价值几何呢？我们来好好称一称。
首先，用了 eBPF 对观测对象就没影响了？Too naive.
从数据角度来说，你通过旁路 eBPF 的方式是能查到一些东西，但其实也会缺失很多信息。如果通过 eBPF 去做，如果大到 uprobe 级别的话，你其实就是在插代码了，你就有可能影响代码的运行。你说完全不影响是不可能的，这个风险会一直存在，观察者一定会影响被观察者。
在内核中也是一样，你不能认为说通过 eBPF 的内核技术，通过虚拟机技术就一定不影响，这也是不确定的。你甚至会影响网络流量呢，网络流量都会对机器造成负担，所以认为完全不影响是不成立的。
其次，不是所有的指标都是予取予求的。
这个世界上没有完整的方案，如果你要做一些业务中的处理，你会发现中间有很多的 trade-off，数据是不一定能取到的。
我举个例子，你从网络流量中无法获取一个用户有效的访问，你要追踪一个充值接口是否有效，和你的运作过程是否一致。那么，如果你在整个网络协议层上，对于这个充值的金额和充值的对象做了加密或者掩码，你通过 eBPF 还能取到这个变量吗？你根本取不到。因为代码调用和在网络流上都没有这个字段，你怎么可能产生得了？
说 eBPF 是神器，是因为有它的独特性在
正方：向阳 speaking ——
在 eBPF 之前，有很多方法可以进行观测。
我们可以编写内核 .ko 模块、替换应用运行依赖的 glibc、通过 Java Agent 做字节码增强，这些方式确实能做到不修改代码，但哪一种不是做的战战兢兢？你会担心出现 kernel panic，会担心出现 glibc 兼容性问题，会担心 Java Agent 之间引入的运行时冲突。当出现性能衰减时，由于插桩代码已深入融入到了应用的运行时中，不可避免的要将怀疑的方向朝插桩引导。这些在部门权责明确的行业客户中更为明显。
在这样一个背景之下，eBPF 有一个非常牛逼的特性，能够避免上述的幺蛾子，那就是它是在沙箱中运行的。而且它有 verifier 机制，可以保证你的 eBPF 程序肯定能在有限的步骤内停止。它的指令集是受限的，指令条数是受限的，能够运行终止，而且不会有内存泄露或 Crash。这是区别于插桩方案的核心特点。插桩是裸着进入到原来的代码里面，不分你我，很容易把自己搞挂了。而 eBPF 它是安全的，它带来的安全性、零侵扰性，是传统技术做不到的。
除此之外，我们在 eBPF 的应用实践中，通过和 Wasm 的结合实现了零侵扰的业务语义信息标注，而且已经在金融、电信、游戏行业有非常好的落地案例。具体来讲，利用 eBPF 零侵扰的拿到 Socket Data 以后，通过内核的协议解析能力实现应用语义信息的标注，在此基础上通过 Wasm Plugin 实现深层次协议解析，提取协议中的交易流水号、5G 呼叫流水号、用户 ID 等业务语义信息。这里我们选择 Wasm（而非 .so 等其他 Plugin 机制）的理由也是零侵扰，由于 Wasm Plugin 的运行受沙箱保护，Plugin 也不会对 eBPF Agent 的运行产生预期之外的干扰。
所以，从这些外部数据里面，我们就能确定内部的状态。这不就是可观测性吗？飞船在天上飞，不用让它动，我就能实现可观测性。
eBPF 只是个探针，不能代表可观测性本身
反方：蒋烁淼 speaking ——
我还是这个观点： eBPF 只是实现可观测性的一个 agent 或者一个探测的手段。它只是手段之一，我们应该根据实际情况的多寡采取不同的手段，而不是把 eBPF 当事人和 linux 内核的能力，当成观测性。其实你只是一个探针，无非这个探针取数据的方式不一样而已，对系统的影响方式各有各的优劣势。
我们今天要建立可观测性，本质上就是建立一个统一的数据存储，让用户从前端后端终端右端，从任何一个角度都可以理解这个系统。如果为了用 eBPF 而用 eBPF，导致单独产生了一个监控系统，和其他监控系统混在一起，大家数据格式都不统一，大家数据内容都不一样，没法互相调用，那还怎么理解系统呢？
所以说，我认为构建可观测性，就是构建一个可以实时处理各种各样可观测信号的数据仓库，而获取这个数据仓库里面的原始信息的手段有很多，我们因地制宜去用这些手段。 eBPF 是通过网络协议层或者通过 cisco 等等层面上去获取相关数据的手段之一。但是根据各种业务情况的不同，根据你所要观测的对象不同，我们应该选择不同的手段，而不是把其中的手段和可观测性划等号，从而单独搞出一个别的数仓调用不了的数据平台。这对于整体的数据建设而言，本末倒置了。
毕竟，你最后产生的这个数据结果，一定是要符合整体观测性的数据需要的。
总结：
总的来说， eBPF 在特定的系统和场景下，在界定问题、观测内核这方面，确实是个给力的工具；但是，eBPF 也有其局限性，比如端侧的市场，其实不能用 eBPF；换到 Windows，也很难发挥作用。不过，好刀也有背，能在自己的领域派上大用，它就已经及格了。
大家对 eBPF 怎么看呢？来点用过 eBPF 的人来说说感受吧~
直播回放如下，不服的扫码看看回放吧↓↓↓
![]()
