eBPF 到底是可观测领域的神器 or 鸡肋？真相其实是 ——

当下，eBPF 无疑是最火热的技术之一，它为云原生环境下的网络、安全和可观测性解决方案提供了全新的思路。

作为一种无需入侵应用代码、直接向操作系统内核安全添加代码的革命性技术，eBPF 使得企业能够不依赖内核固有的指标数据，直接编写代码收集自定义数据，并生成可观测性指标和事件。这不仅将可观测性扩展到内核，还能够实现零插桩的应用代码可观测性，同时保证了运行安全和开销可控。于是，不少人认为 eBPF 是可观测领域的未来之星。

然而，也有人觉得，eBPF 的作用被夸大了。它并不是适合每个项目或生态系统的灵丹妙药 —— 仅限于 Linux 和它的最新内核。而且“沙箱程序也是有限制的”，通过限制程序可以访问的操作系统部分，功能也可能受到限制。因此 eBPF 只不过是可观测体系中的一个小补充罢了，并不是可观测领域的未来主要方向。

对此，真实的情况是怎样的？实际应用中，它更有可能帮大忙，还是拖后腿？对此，开源中国邀请了云杉网络研发 VP 向阳、观测云创始人兼 CEO 蒋烁淼、《SRE 原理与实践》作者张观石、某智能制造业运维吴秋鑫、SUGA Data Science Team Leader Jaron Tam，一起进行了讨论。

为什么说 eBPF 是神器？

正方：向阳 speaking ——

是不是神器，有对比就能看出来。

之前用 APM Agent 的时候，它的侵扰性和它的盲点直接导致发现问题和定界其实是很困难的。

首先是侵扰性：

比如说我们把一段 SDK 或者一个 Java Agent 的插到一个应用程序里面来了以后，它变了。这时候出现了一个灵魂拷问——我们本来是要观测原来那个程序的，但我们插入了一个 SDK 和 Java Agent 以后它已经不是它了，那我们到底观测的是谁？我们保证的是谁的可观测性？

被迫插桩后的应用，还是以前那个应用吗？

不仅如此，之后还有一堆随之而来的问题：

• 代码冲突：多个 Java Agent 运行时冲突，或者 SDK 依赖库版本编译时冲突，怎么办？
• 维护困难：Agent 多久可发版一次，要维护多少个版本，要适配多少种语言？
• 边界模糊：预期之外的性能衰减、运行故障，是谁的锅？

归根结底，APM Agent 不是一个商业行为，而是开发的一个自主行为，而且是一个百花齐放的行为，开发选择什么都可以。这就导致在一些非常核心的领域，例如金融、能源、电信、制造等等，就完全落地不了。

此外是盲点：

在云原生的场景下，两个 app 之间的通信其实是很复杂的。还有网络传输、系统调用、数据库、中间件等等，各种各样的网关在等着你。这时候，出了问题，连定界都困难。

比如说，一个 pod 访问一个云服务发生故障了，这时你的责任边界是这个应用进程，但是你去提工单、去做定界的时候，你怎么确定是哪个部门的问题？假设一个 pod 里面有很复杂的路径，从业务到三叉，再到网络收发的 K8s，可能还有网络服务 IPVS，再做一些转发，再到 KVM，以及什么私有云专有云，这些就都很复杂，很多地方插桩都插不进去，还怎么确定问题呢？

这时候，eBPF 就能解决这个问题。eBPF 可以去追踪服务内的行为，也可以去追踪服务间的行为，全程零侵扰，不用改代码，当天就能落地；遇到问题，全栈5分钟就能定界。

APM Agent 在关键行业落地不了的，eBPF 能落；云原生环境有盲点，eBPF 能解决。

有了 eBPF ，可观测性就能实现，你说它是不是神器？

eBPF 只是个普通的工具而已，别夸大了

反方：蒋烁淼 speaking ——

先反对一下把 eBPF 吹成神器的调调。

eBPF 只是个手段，不要把手段当成目的。

第一，不要把可观测性，等同于数据采集的方便性。

第二，正方讲的都是可观测性只用于排障的部分，但可观测性的目的不只是用于排障，排障只是其中非常小的一个阶段。

第三，可观测性本身最大的价值就是构建一个完整的、了解系统的平台，而 eBPF 只是了解这个系统的手段之一。

不能因为我本身做 SD-WAN 相关，我就变成一个榔头满世界找钉子。可观测性可不仅仅是干这个的。

我们今天讲的主题是 eBPF 对于可观测性的价值。那 eBPF 对可观测性到底价值几何呢？我们来好好称一称。

首先，用了 eBPF 对观测对象就没影响了？Too naive.

从数据角度来说，你通过旁路 eBPF 的方式是能查到一些东西，但其实也会缺失很多信息。如果通过 eBPF 去做，如果大到 uprobe 级别的话，你其实就是在插代码了，你就有可能影响代码的运行。你说完全不影响是不可能的，这个风险会一直存在，观察者一定会影响被观察者。

在内核中也是一样，你不能认为说通过 eBPF 的内核技术，通过虚拟机技术就一定不影响，这也是不确定的。你甚至会影响网络流量呢，网络流量都会对机器造成负担，所以认为完全不影响是不成立的。

其次，不是所有的指标都是予取予求的。

这个世界上没有完整的方案，如果你要做一些业务中的处理，你会发现中间有很多的 trade-off，数据是不一定能取到的。

我举个例子，你从网络流量中无法获取一个用户有效的访问，你要追踪一个充值接口是否有效，和你的运作过程是否一致。那么，如果你在整个网络协议层上，对于这个充值的金额和充值的对象做了加密或者掩码，你通过 eBPF 还能取到这个变量吗？你根本取不到。因为代码调用和在网络流上都没有这个字段，你怎么可能产生得了？

说 eBPF 是神器，是因为有它的独特性在

正方：向阳 speaking ——

在 eBPF 之前，有很多方法可以进行观测。我们替换 live，替换 Java Agent ，但都替换得战战兢兢。不时就会出现什么 Kernel 崩溃啦，什么进成档啦，什么跑出死循环啦，这样的故事不要太多。

在这样一个背景之下，eBPF 有一个非常牛逼的特性，能够避免上述的幺蛾子，那就是它是在沙箱中运行的。而且它有 verifier，可以保证你在有限的步骤内，指令集是受限的，数量是受限的，能够运行终止，而且不会有内存泄露，不会有这些异常的终止。这是区别于我们所谓的插桩的。插桩是裸着进入到原来的代码里面，不分你我，很容易把自己搞挂了。而 eBPF 它是安全的，这就是它区别于别的技术的核心点。它带来的安全性、零侵扰性，是别的技术做不到的。

其次就是业务字段这方面，我们在金融行业、在电信行业、在游戏行业，都有很详尽的案例了。我们通过您插桩的技术，通过 eBPF 把它的 data 拿到以后，我们再去做业务层的一个解析，通过我们的 Awesome Plugin 的机制，无论是面向业务的属性，还是用户的属性，全部都能呈现出来。这同样是零侵扰的，而且 Awesome Plugin 也提供了一个沙箱的机制。比方说这个插件，它运行多少套指令之后就应该终止。终止不了，就把它干掉。这都是有一个非常强大的保障的。

所以，从这些外部数据里面，我们就能确定内部的状态。这不就是可观测性吗？飞船在天上飞，不用让它动，我就能实现可观测性。

eBPF 只是个探针，不能代表可观测性本身

反方：蒋烁淼 speaking ——

我还是这个观点： eBPF 只是实现可观测性的一个 agent 或者一个探测的手段。它只是手段之一，我们应该根据实际情况的多寡采取不同的手段，而不是把 eBPF 当事人和 linux 内核的能力，当成观测性。其实你只是一个探针，无非这个探针取数据的方式不一样而已，对系统的影响方式各有各的优劣势。

我们今天要建立可观测性，本质上就是建立一个统一的数据存储，让用户从前端后端终端右端，从任何一个角度都可以理解这个系统。如果为了用 eBPF 而用 eBPF，导致单独产生了一个监控系统，和其他监控系统混在一起，大家数据格式都不统一，大家数据内容都不一样，没法互相调用，那还怎么理解系统呢？

所以说，我认为构建可观测性，就是构建一个可以实时处理各种各样可观测信号的数据仓库，而获取这个数据仓库里面的原始信息的手段有很多，我们因地制宜去用这些手段。 eBPF 是通过网络协议层或者通过 cisco 等等层面上去获取相关数据的手段之一。但是根据各种业务情况的不同，根据你所要观测的对象不同，我们应该选择不同的手段，而不是把其中的手段和可观测性划等号，从而单独搞出一个别的数仓调用不了的数据平台。这对于整体的数据建设而言，本末倒置了。

毕竟，你最后产生的这个数据结果，一定是要符合整体观测性的数据需要的。

总结：

总的来说， eBPF 在特定的系统和场景下，在界定问题、观测内核这方面，确实是个给力的工具；但是，eBPF 也有其局限性，比如端侧的市场，其实不能用 eBPF；换到 Windows，也很难发挥作用。不过，好刀也有背，能在自己的领域派上大用，它就已经及格了。

大家对 eBPF 怎么看呢？来点用过 eBPF 的人来说说感受吧~

直播回放如下，不服的扫码看看回放吧↓↓↓