嘉宾 | 王张军 赵晨雨
出品 | CSDN云原生
在解读 CNCF 云原生计算基金会 2021 年度云原生调查时，CNCF 执行董事Priyanka Sharma 曾表示：“随着容器基础设施的上层和底层不断成熟，2022年将成为边缘、可观测性和安全等新兴云原生领域的标志性一年。”
今年，我们明显感觉出“可观测性”的热潮席卷了云原生领域，而eBPF无疑是这个热潮的中心。
但与此同时，你是否对可观测性、eBPF还有些疑问？为此，我们整理了2022年 Thoughtworks 技术雷达峰会上《eBPF可观测性的落地与实践》的专题演讲，并对两位讲者 Thoughtworks 安全与系统研发事业部咨询师王张军、赵晨雨进行了补充采访，形成此文，希望为你揭开迷雾。
技术雷达（Tech Radar）是 Thoughtworks 每半年发布一次的技术趋势报告，对技术成熟度进行持续评估。
什么是可观测性
可观测性的概念最早由现代控制理论之父Rudolf Kalman提出：“如果对于状态和控制向量的任何可能演变，仅使用输出的信息就可以估计当前状态，则称系统是可观测的。”
在王张军看来，抽象理解这个概念就是：在开销极度小的情况下，通过引入可观测性工具或组件查看系统内部的运行状态。而通俗的理解则是：可观测性是在基本不改变系统状态的前提下，引入工具、数据源及一些方法来理解一项技术在系统中是如何运作的。
可以通过一个例子进一步来说明可观测性的重要性。
假设有这样一个场景：生产服务器存在偶发性断开的问题。按照常规的处理方式，可以通过使用抓包工具如Wireshark初步找寻断开的原因，但难以通过常规工具更进一步地定位根因。如果此时我们拥有一个灵活的可观测性系统的话，就可以动态地观察问题并确定原因，且不需要重新编译系统。
云原生时代，为何要转向可观测性
在可观测性出现之前，大家使用最多的是监控系统。但随着业务的扩大与复杂，监控系统的不足开始显现，它无法有效满足大家对于问题定位、性能优化的需求，这个时候可观测性就被提出了。
监控系统通常是根据可预见性的问题而设计的，如对容易出现异常的指标进行重点监控。而复杂场景中通常存在大量无法预料的问题，对于这些问题，监控并不能进行高效处理，而可观测性系统正是动态高效地定位并解决突发性问题的良好手段。
云服务的发展经历了由“单体—分布式—服务网格”的变迁，发展十分快速，同时也遇到了很多问题，所以起初可观测性大多被应用在了云原生场景中，那么非云原生环境就不能做可观测性吗？
当然不是，赵晨雨表示，在谈论可观测性时，一定要限定在某个具体的场景下，因为每一个领域对可观测性的要求都不相同。当前大家做可观测性最直接的目的在于问题定位以及性能优化，尤其是嵌入式设备的性能持续优化上。相比于云原生场景来说，嵌入式场景并没有迫切的可观测性需求。但在未来，是一定需要可观测性的，只是其目前亟待解决的问题并不需要采用大量的可观测性工具就可以得到解决。
可观测性当前的不足
可观测性是一个概念，不同的领域、组织对可观测性的理解可能都会存在差异。在具体构建的过程中，底层技术一定要以系统的使用场景以及功能需求为前提，不能够滥用技术直接做可观测性。
因此，在使用可观测系统定位问题时，往往还需要更细粒度的观测、更深层次的数据支撑，以及需要基于一些事件驱动的判断。
为了满足更细粒度的观测需求，通常需要引入额外的代码来实现数据收集、行为分析等。所以，开销问题自然就成为了大家关注的焦点。同时，与大量的引用代码一同而来的是更多的安全隐患。
赵晨雨说，大家都希望能够在不改变系统状态的前提下，通过引入新的工具或数据源来查看当前系统内部的工作状态，但工具只要在系统上运行，就一定会带来开销，损耗在多大时可以认为没有改变系统状态呢？这并没有一个明确客观的定义。
当前，现代软件系统的规模正在呈指数型增长，服务之间的交互异常复杂。在这种场景下，传统NPM、APM无法有效地实现全链路问题追踪，只能通过碎片化的信息追因。而在当每一个子系统及组件具有可观测性的能力后，便可以实现无侵入情况下的快速排障，eBPF就是这样一种有效的手段。
eBPF是什么
eBPF起源于Linux内核，是Linux内核一种革命性的技术，可以在内核中运行沙盒程序。该技术可以安全而高效地扩展内核的能力，而无需修改内核源代码或者装载内核模块。同时可以弥补可观测性所具有的观测盲点、数据深度限制等不足。
以JavaScript为例，可以帮助大家更好地理解eBPF。
众所周知，JavaScript可以在网页中实现复杂功能，能够很容易地将一段代码嵌入到网页中，使网页不再是静态内容。以此类比，eBPF可以将任何一段代码嵌入到操作系统或用户态的任何一个函数上，可以在内核中实现功能，使内核不再是难以触碰到的。
eBPF架构模型
eBPF分为用户空间程序和内核程序两个部分。
-
用户空间程序负责加载eBPF字节码至内核，如需要也会负责读取内核回传的统计信息或事件详情；
-
内核中的eBPF字节码负责在内核中执行特定事件，如需要也会将执行的结果通过eBPF Maps或者Perf-event事件发送至用户空间；
-
其中用户空间程序与内核eBPF字节码程序可以使用Maps结构实现双向通信，这为内核中运行的eBPF字节码程序提供了更加灵活的控制。同时，eBPF程序注入到内核之前会经过验证器，保证其是“内核安全的”。
eBPF的优势
-
编译方面，eBPF支持即时（JIT）编译器，字节码被编译完成后会直接调用eBPF而不是对每个方法的字节码进行新的解释；
-
安全方面，eBPF程序的验证步骤确保资源不会被运行无限循环的程序阻塞；
-
出错模式方面，eBPF提供Error Message帮助实现代码优化；
-
资源访问方面，eBPF为同时保证安全性与通用性，提供Helpers方法，几乎可以访问全部内核导出的数据。
eBPF使用注意事项
首先，在开发运行方式上，eBPF当前没有完整的开发流程，同时可用资料较少，这会使开发难度大幅增加。
其次，eBPF开发成功后会编译成字节码下发至内核，校验器对程序内部进行检验，其中包括指令与数目的限制。当eBPF程序段超过一定的指令数后，会被禁止执行，这会直接导致复杂逻辑难以实现。
再者，eBPF对内核内存的访问有严格限制，大多数情况下只允许读取，Write能力十分受限。正是如此，eBPF多用作可观测性，而很少使用其做调度优化等。
虽然使用eBPF在一定程度下能够带来性能的提升，但它本身也存在非常多的限制，所以要对使用场景的具体情况进行具体分析，绝不能“一刀切”，王张军总结道。
可以看出，我们想要通过eBPF实现的两个关键点分别是安全和高效。
安全可以通过Verifier来保证资源不会被运行无限循环的程序阻塞。JIT编译器可以将eBPF字节码编译成与本地机器一致的机器码，以此保证eBPF运行时的效率与原生机器码保持一致。
云原生环境下的可观测性
当前eBPF落地最主要的场景是云原生。云原生环境下，单体应用已经逐渐容器化、微服务化，这就直接导致了软件内部交互复杂的问题。
根据以往的经验及社区的方法，可以总结出eBPF应用在云原生环境下时需要三大组件的支持：
-
GUI：GUI要保证一些基本功能的实现，如用户认证、权限控制、节点管理、可视化、数据检索等；
-
Scheduler：当eBPF程序数量增多、处于“点—线—面”的过渡时，Scheduler则需负责策略下发、管理编排等功能；
-
Agent：不同环境的复杂度不同，在部署可观测性方案的过程中一定会遇到环境问题。理想状况下，可观测性提供的Agent功能能够实现零侵入、零干扰、零依赖，同时具有良好的兼容性。
我们到底要通过可观测性落地实现什么？
实际上，自底向上是源数据映射到系统资源再映射到应用态能力的过程。
内核是高度抽象的，在内核态只能获取到最基本的源数据，如PID、Cgroup、Namespace等。将源数据映射至用户态也就是在得到源数据后实现资源识别的过程。通过资源识别，可以带来更为直接的价值如性能、安全等。
添加eBPF可观测性的挑战
挑战1：原理层面
想要知道为什么内核原理层面是应用eBPF时的挑战，首先要知道我们为什么要在内核态做观测？原因很简单，因为用户态千变万化，内核态相对稳定，是做可观测性的最佳场景。
上图是一个网络数据包的构造/解析流程。每一个函数上面都会提取到相应的源数据，将其保存在到eBPF的Maps当中，再将数据传输到用户态。
看似简单的功能实现其实并不简单。每一个小小的功能的背后，都需要对内核原理有充分了解。
挑战2：运行时
在实际落地过程中，经常会遇到以下问题。
-
易用性
-
兼容性
-
管理编排
eBPF有两个目标，一是让非内核开发人员能够轻易的修改内核，二是提高易用性。但权限方面，eBPF在内核态运行需要Root权限，但并不是所有节点都有Root权限。其次，eBPF本身也不易于调试。
eBPF本身对内核版本要求较高，而业内环境中所使用的Linux内核版本一般较低，不同的内核版本和低版本内核的应用会带来兼容性的问题。
当前eBPF多是单点应用，随着之后“点—线—面”的发展，在节点的管理编排上也会出现困难。
推荐基于eBPF的工具/脚手架/框架/项目
-
使用现有的基于eBPF的工具：BCC bpftrace；
-
基于eBPF开发复杂功能，甚至是一个产品：libbpf C(CO-RE)，BBC python，libbpf-rs，cilium/eBPF Go；
-
优秀的基于eBPF的可观测性项目：Pixie、Falco、MetaFlow。
针对可观测性的观测盲点、数据深度限制等不足，eBPF有效地进行了弥补。而随着云原生的快速发展，eBPF的用武之地才刚刚开始。
,
