嘉宾 | 王章军赵晨宇

出品 | CSDN 云原生

在解读 CNCF 云原生计算基金会 2021 年云原生调查时，CNCF 执行董事曾表示：“随着容器基础设施上下层的不断成熟，2022 年将成为边缘、可观察性和安全等新兴云原生领域。具有里程碑意义的一年。”

今年，我们明显感受到了席卷云原生领域的“可观察性”热潮，而 eBPF 无疑是这股热潮的中心。

但与此同时，您是否还有一些关于可观察性、eBPF 的问题？为此，我们在2022技术雷达峰会上编写了“eBPF可观测性的实现与实践”专题演讲，并对安全与系统研发部顾问王章军和赵晨宇两位演讲者进行了补充采访, 形成这份报告。温，希望能为你解开迷雾。

Tech Radar 是一份持续评估技术成熟度的半年度技术趋势报告。

什么是可观察性

可观察性的概念最早是由现代控制理论之父提出的：“如果对于状态和控制向量的任何可能演变，仅使用输出信息可以估计当前状态，则称系统是可观察的。”

在王章军看来，对这个概念的抽象理解是：在开销极小的情况下，通过引入可观察性工具或组件来查看系统内部的运行状态。通俗的理解是：可观察性是在不基本改变系统状态的情况下，引入工具、数据源和方法来理解一项技术在系统中是如何工作的。

可观察性的重要性可以通过一个例子来进一步说明。

假设存在生产服务器偶尔出现断线问题的场景。按照传统的处理方法，可以通过抓包工具初步找到断线的原因，但是通过传统的工具很难进一步定位到根本原因。如果此时我们有一个灵活的可观察性系统，我们可以动态地观察问题并确定原因，而无需重新编译系统。

云原生时代，为什么要转向可观察性

在可观察性出现之前，大多数人使用监控系统。但是，随着业务的扩展和复杂化，监控系统的不足开始显现。无法有效满足大家对问题定位和性能优化的需求。这时，提出了可观察性。

监控系统通常是根据可预测的问题来设计的，比如关注容易出现异常的监控指标。但是，在复杂的场景中通常会出现大量无法预料的问题。对于这些问题，无法有效地进行监控，而可观察性系统是动态、高效地定位和解决突发问题的好手段。

云服务的发展经历了从“单体-分布式-服务网格”的转变。发展很快，但也遇到了很多问题。因此，最初可观察性主要应用于云原生场景。原生环境不能做可观察性吗？

当然不是，赵晨宇说，说到可观察性，一定要局限在特定的场景，因为每个领域对可观察性的要求都不一样。目前，可观察性最直接的目的是问题定位和性能优化，尤其是嵌入式设备性能的持续优化。与云原生场景相比，嵌入式场景没有迫切的可观测性需求。但是未来肯定需要可观察性，但是目前需要解决的问题楼宇自控扩展模块，不用大量的可观察性工具就可以解决。

当前可观察性的缺陷

可观察性是一个概念，不同的领域和组织可能对可观察性有不同的理解。在具体建设过程中，底层技术必须基于系统的使用场景和功能需求，不能滥用该技术进行直接可观察性。

因此，在使用可观察系统定位问题时，往往需要更细粒度的观察，更深层次的数据支持，以及一些事件驱动的判断。

为了满足更细粒度的观察需求，往往需要引入额外的代码进行数据采集、行为分析等，因此成本问题自然成为大家关注的焦点。同时，大量的参考代码也带来了更多的安全隐患。

赵晨宇表示，大家希望能够在不改变系统状态的情况下，通过引入新的工具或者数据源，查看系统当前内部的工作状态，但是只要工具在系统上运行，肯定会带来开销，而且损失在什么年代可以认为系统状态没有改变？对此没有明确和客观的定义。

eBPF 带来解决问题的新思路

如今，现代软件系统的规模呈指数级增长，服务之间的交互极其复杂。在这种场景下，传统的 NPM 和 APM 无法有效地追踪到所有的链路问题，只能通过碎片化的信息进行追踪。当每个子系统和组件都具备可观察的能力时，就可以实现无入侵的快速故障排除。eBPF 就是这样一种有效的方法。

什么是 eBPF

eBPF起源于Linux内核，是Linux内核中的一项革命性技术，可以在内核中运行沙盒程序。该技术可以在不修改内核源代码或加载内核模块的情况下安全有效地扩展内核的能力。同时可以弥补观测盲点、数据深度限制等可观测性的不足。

举个例子来帮助你更好地理解 eBPF。

众所周知，复杂的功能可以在网页中实现，一段代码可以很方便的嵌入到网页中，让网页不再是静态内容。这样，eBPF可以将任意一段代码嵌入到操作系统或用户态的任意功能中，并且可以在内核中实现功能，让内核不再难于触碰。

eBPF 架构模型

eBPF分为两部分：用户空间程序和内核程序。

eBPF 的优势

使用 eBPF 的注意事项

首先，在开发和运营模式上，eBPF目前还没有完整的开发流程，同时可用的资料也很少，这将大大增加开发难度。

其次，eBPF开发成功后，会编译成字节码发送给内核，会检查程序内部，包括指令和数量的限制。当eBPF程序段超过一定数量的指令时，会被禁止执行，直接导致复杂逻辑难以实现。

此外，eBPF 对内核内存的访问有严格的限制。大多数情况下，只允许读取，写入能力非常有限。因此，eBPF 主要用于可观察性，很少用于调度优化等。

虽然使用 eBPF 可以在一定程度上提高性能，但它也有很多局限性。因此，需要具体分析使用场景的具体情况，不能“一刀切”，王章军总结道。

eBPF 可观察性实践

可以看出，我们希望用 eBPF 实现的两个关键点是安全和效率。

安全可以通过确保资源不被无限循环运行的程序阻塞来实现。JIT编译器可以将eBPF字节码编译成与本地机器一致的机器码，从而保证eBPF运行时效率与本地机器码一致。

云原生环境中的可观察性

当前 eBPF 实现最重要的场景是云原生。在云原生环境下，单体应用逐渐被容器化和微服务化，这直接导致了内部软件交互复杂的问题。

根据以往的经验和社区方法，可以得出结论，云原生环境中的 eBPF 应用需要三个组件的支持：

我们到底想通过可观察性来实现什么？

实际上，自底向上是将源数据映射到系统资源，再映射到应用状态能力的过程。

内核是高度抽象的，在内核态中只能获取最基本的源数据，如PID、...等。将源数据映射到用户态是获取源数据后实现资源识别的过程。通过资源识别，可以带来性能、安全等更直接的价值。

添加 eBPF 可观察性的挑战

挑战一：原则层面

如果你想知道为什么在应用 eBPF 时内核原理层面是一个挑战，你首先要知道为什么我们需要在内核态进行观察？原因很简单，因为用户态是千变万化的，内核态相对稳定，是可观察性最好的场景。

上图是一个网络包的构造/解析过程。每个函数都会提取相应的源数据，保存在 eBPF 的 Maps 中，然后将数据传输到用户态。

看似简单的功能实现，其实并不简单。每一个小功能的背后，都需要对内核原理有一个全面的了解。

挑战 2：运行时

在实际落地过程中，经常会遇到以下问题。

推荐基于eBPF的工具/脚手架/框架/项目

针对可观测性的观察盲点和数据深度的限制，eBPF有效弥补了这一点。随着云原生的飞速发展，eBPF 的使用才刚刚开始。