观点 | 光大银行基于eBPF云可观测之路的思考

欢迎金融科技工作者积极投稿！

投稿邮箱：[e-mail]

                                              ——金融电子化

      

文 / 中国光大银行信息科技部    解培  冯帆

eBPF（Extended Berkeley Packet Filter）是一项扩展操作系统内核的革命性技术，它支持在内核中高效地运行用户编写的沙箱程序，而不需要修改编译内核源代码或者加载内核模块，并且保证内核安全运行。eBPF由BPF技术演进扩展而来，BPF最早是tcp dump等工具获取和过滤匹配特定规则的网络数据包方法，更多的目的是为了处理内核中网络相关问题。Alexei Starovoitov 在2014年引入了扩展 BPF设计，支持直接将BPF虚拟机开放至用户空间，eBPF从而诞生。

eBPF不仅继承了BPF初衷，适合编写网络程序，还可以修改已建立的网络套接字的设置。由于eBPF 程序可以访问内核数据结构，开发人员可以编写和测试新的调试代码，而无需重新编译内核，具有在几乎所有类型的事件、内核函数上运行特定动作的能力。虽然eBPF技术并不是新出现的技术，但如今云、容器以及分布式应用的发展使基于eBPF的程序应用有了更多契合场景，在云安全、容器网络、分布式应用追踪以及可观测性等方面得到了广泛使用与创新。

eBPF技术的优势

eBPF程序是一个64位的指令序列，运行将严格考虑到两个方面：一是所有的 eBPF 指令在加载时必须是可验证的，以确保内核的安全；二是eBPF代码需要尽可能快地被执行。所以eBPF具有强安全和高性能的优势。

◆ 强安全：BPF验证器（Verifier）会保证每个程序能够安全运行，它会去检查将要运行到内核空间的程序的每一行是否安全可靠，如果检查不通过，它将拒绝这个程序被加载到内核中去，从而保证内核本身不会崩溃，这是不同于开发内核模块的。比如以下几种情况是无法通过BPF验证器的：

● 没有实际加载BPF程序所需的权限；

● 访问任意内核空间的内存数据；

● 将任意内核空间的内存数据暴露给用户空间。

◆ 高性能：一旦通过了BPF验证器，那么它就会进入JIT编译阶段，利用Just-In-Time编译器，编译生成通用的字节码，它是完全可移植的，可以在x86和ARM等任意CPU架构上加载，这样我们能获得本地编译后的程序运行速度，而且是安全可靠的。

eBPF解决了在内核编程中经常遇到的挑战，让内核释放出巨大的可能性。直接修改内核代码进行开发需要重新编译内核，通过编写API调用实现，用户环境兼容是一大挑战。通过加载的内核模块实现，同样面临内核版本的更新、内核API的变化，所以内核模块需要随着每一个内核版本的发布而更新。

eBPF通过严格的运行验证和限制解决了工程师内核编程中最大的问题——安全稳定问题，释怀了时刻要小心的“Kernel Panic恶梦”。eBPF比传统的内核编程更加方便快捷，它能基于现有的抽象层来打造更加智能、功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。

光大银行全栈基于eBPF可观测性建设的思考

在eBPF社区中，应用追踪及云可观测性是非常火热的应用领域，光大银行全栈云在建设之初就将观测性纳入设计，eBPF技术将对云及云上应用在以下几个方面带来新思路及创新。

1. 观测数据多样性

相比于操作系统提供的静态计数器，eBPF能在内核中收集和聚合自定义指标数据，并能从不同数据源生成可观测数据。这既扩展了可观测性的深度，也显著减少了整体系统开销，因为可以选择只收集需要的数据，并且是预处理后的格式，直接用于直方图、火焰图等，而非原始采样数据。

 图1    eBPF技术架构

如图1所示，eBPF 程序能够加载到追踪点（Trace Point），包括内核及用户空间应用程序。用户空间应用程序负责加载eBPF字节码至内核，也可以读取内核回传的统计信息或事件详情；内核中的eBPF字节码负责在内核中执行特定事件，也可以将执行的结果通过eBPF Maps或者Perf-event事件发送至用户空间，用户空间应用程序与内核eBPF字节码程序可以使用Maps结构实现双向通信。这种能力对应用程序运行时的行为和系统本身提供了前所未有的可观测性。应用端和系统端的观测能力相结合，能在排查系统性能问题时提供强大的关联信息，避免导出海量的原始采样数据。

2. 基础设施与系统应用将更加紧密

传统IT环境中监控相对独立，监控对象的边界也相对清晰，以网络性能监控（NPM）与应用性能监控（APM）为例，在物理网络中，IP在网络层标识流量（Traffic）、流（Flow）以及端点，而在云环境中，流量涉及到虚拟机、容器POD、服务、命名空间等标签或维度，IP很难再独立描述云内流量。应用程序的调用依赖与性能则由应用分析团队来完成，有些应用监控则需要开发规范的引入来达到。

eBPF提供面向所有层面数据的获取方式，覆盖运行在云或容器平台之上的所有应用、系统、网络的监控与观测数据。这让应用间的API调用、分布式性能追踪、容器平台弹性扩展，能够直接关联到所属虚拟机、容器POD间的拓扑、网络流，包括异常、吞吐与时延等。eBPF让应用、系统、容器、云等不同平面的观测数据整体化获取和关联成为可能，降低了监控数据获取代价。

在性能分析领域，应用性能、网络性能追踪数据关联后，将大大降低对于云原生应用的性能优化、排障成本，将从云原生环境整体进行观测。在性能分析或排障中经常用到性能火焰图，但应用和网络性能数据是相互独立的，想要关联起来，需要不同团队间协作分析排查，这不是一个高效的状态。

 图2    API调用性能火焰图

图2是一个Http API调用访问的性能火焰图的例子，eBPF将应用与网络性能结合在一起，“S”标记开头的是服务相关性能消耗，“N”标记开头的是网络相关性能消耗。对于不同层面的工程师，看到这张图，都可以快速进行性能定界，不再需要通过拉会，工单来进行协查，简单的点击就可以直观看到网络建连、DNS查询、网络传输、系统调用、应用处理的分段性能。云管理团队发现网络连接等基础设施异常，也能快速对应到应用协议、微服务等平面。漫长漆黑的多层下钻关联，通过观测数据变成即时的点击工具。

3. 降低观测数据成本，保障操作系统运行安全

eBPF带给行业中低代价的观测数据获取成本，给整个云及云上应用保障带来了全新的架构设计可能性。从基础设施层面可以统一建设观测数据处理管道及数据湖，服务于网络等基础设施、系统调用、应用程序的指标、追踪以及日志数据。数据消费端不必再重复关注高基多维数据存储查询的性能扩展、数据标签设置等问题，重点放在各类数据的分析价值。

运维侧提升排障效率，提升云整体运行无故障时长、降低故障定位时长，故障恢复时长等。应用层面可以直接获取基础设施标签，精准定位涉及到的异常资源；网络异常可以追踪应用调用访问，划分影响的业务范围。通过API调用、输出大屏以及对接工作流软件等，业务、安全、审计等部门都可以直接使用到整体观测数据，让数据流转到更多的使用领域中。

同时，我们可以基于eBPF对内核编程来开发更多的安全扩展功能，进而实现针对操作系统运行风险的即时监控，实现对各种安全事件的动态跟踪。例如：检测操作系统中异常进程和用户异常操作、可疑的脚本执行、异常的端口监听、软件包或配置更新等。还可以实现对危险进程的实时跟踪，对进程的所有异常行为进行监控或终止，实现对操作系统或容器运行时的各类安全管控。

未来展望

国外相关技术专家将eBPF定义为过去50年操作系统最大的变革，从行业趋势看，越来越多的大厂在生产环境大规模应用eBPF，尤其在与Kubernetes的结合上，iptables在逐渐被替代。Linux内核继续朝着成为BPF runtime-powerd microkernel前进，设想不久的未来，Linux只保留一个非常小的核心内核，其他内核功能都可以由用户通过BPF来实现定义，这将极大地减少对内核的攻击面，同时减少资源占用，CPU等资源可以用在更有意义的地方。光大银行将持续关注eBPF的发展，挖掘更多有意义的场景应用在我行云平台发展之中。

往期精选：

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪