过去一年，ARMS基于eBPF技术打造了Kubernetes监控，提供多语言无侵入的应用性能，系统性能，网络性能观测能力，验证了eBPF技术的有效性。eBPF技术和生态发展很好，未来前景广大，作为该技术的实践者，本文目标是通过回答7个核心问题介绍eBPF技术本身，为大家解开eBPF的面纱。

eBPF是什么？

eBPF是一个能够在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制。随着内核的发展，eBPF 逐步从最初的数据包过滤扩展到了网络、内核、安全、跟踪等，而且它的功能特性还在快速发展中，早期的 BPF 被称为经典 BPF，简称cBPF，正是这种功能扩展，使得现在的BPF被称为扩展BPF，简称eBPF。

eBPF的应用场景是什么？

网络优化

eBPF兼具高性能和高可扩展特性，使得其成为网络方案中网络包处理的优选方案：

高性能

JIT编译器提供近乎内核本地代码的执行效率。

高可扩展

在内核的上下文里，可以快速地增加协议解析和路由策略。

故障诊断

eBPF通过kprobe，tracepoints跟踪机制兼具内核和用户的跟踪能力，这种端到端的跟踪能力可以快速进行故障诊断，与此同时eBPF支持以更加高效的方式透出profiling的统计数据，而不需要像传统系统需要将大量的采样数据透出，使得持续地实时profiling成为可能。

安全控制

eBPF可以看到所有系统调用，所有网络数据包和socket网络操作，一体化结合进程上下文跟踪，网络操作级别过滤，系统调用过滤，可以更好地提供安全控制。

性能监控

相比于传统的系统监控组件比如sar，只能提供静态的counters和gauges，eBPF支持可编程地动态收集和边缘计算聚合自定义的指标和事件，极大地提升了性能监控的效率和想象空间。

eBPF为什么会出现？

eBPF的出现本质上是为了解决内核迭代速度慢和系统需求快速变化的矛盾，在eBPF领域常用的一个例子是eBPF相对于Linux Kernel类似于Javascript相对于HTML，突出的是可编程性。一般来说可编程性的支持通常会带来一些新的问题，比如内核模块其实也是为了解决这个问题，但是他没有提供很好的边界，导致内核模块会影响内核本身的稳定性，在不同的内核版本需要做适配等。eBPF采用以下策略，使得其成为一种安全高效地内核可编程技术：

安全

eBPF 程序必须被验证器校验通过后才能执行，且不能包含无法到达的指令；eBPF 程序不能随意调用内核函数，只能调用在 API 中定义的辅助函数；eBPF 程序栈空间最多只有 512 字节，想要更大的存储，就必须要借助映射存储。

高效

借助即时编译器（JIT），且因为 eBPF 指令依然运行在内核中，无需向用户态复制数据，大大提高了事件处理的效率。

标准

通过BPF Helpers，BTF，PERF MAP提供标准的接口和数据模型供开发者使用。

功能强大

eBPF 不仅扩展了寄存器的数量，引入了全新的 BPF 映射存储，还在 4.x 内核中将原本单一的数据包过滤事件逐步扩展到了内核态函数、用户态函数、跟踪点、性能事件（perf_events）以及安全控制等领域。

eBPF怎么用？

5个步骤

1、使用 C 语言开发一个 eBPF 程序；

即插桩点触发事件时要调用的eBPF沙箱程序，该程序会在内核态运行。

2、借助 LLVM 把 eBPF 程序编译成 BPF 字节码；

eBPF 程序编译成 BPF 字节码，用于后续在eBPF虚拟机内验证并运行。

3、通过 bpf 系统调用，把 BPF 字节码提交给内核；

在用户态通过bpf系统，将BPF字节码加载到内核。

4、内核验证并运行 BPF 字节码，并把相应的状态保存到 BPF 映射中；

内核验证BPF字节码安全，并且确保对应事件发生时调用正确的eBPF程序，如果有状态需要保存，则写入对应BPF映射中，比如监控数据就可以写到BPF映射中。

5、用户程序通过 BPF 映射查询 BPF 字节码的运行状态。

用户态通过查询BPF映射的内容，获取字节码运行的状态，比如获取抓取到的监控数据。

一个完整的 eBPF 程序，通常包含用户态和内核态两部分：用户态程序需要通过 BPF 系统调用跟内核进行交互，进而完成 eBPF 程序加载、事件挂载以及映射创建和更新等任务；而在内核态中，eBPF 程序也不能任意调用内核函数，而是需要通过 BPF 辅助函数完成所需的任务。尤其是在访问内存地址的时候，必须要借助 bpf_probe_read 系列函数读取内存数据，以确保内存的安全和高效访问。在 eBPF 程序需要大块存储时，我们还需要根据应用场景，引入特定类型的 BPF 映射，并借助它向用户空间的程序提供运行状态的数据。

eBPF程序分类和使用场景

bpftool feature probe | grep program_type

以上命令可以查看系统支持的eBPF程序类型，一般有如下类型：

eBPF program_type socket_filter is availableeBPF program_type kprobe is availableeBPF program_type sched_cls is availableeBPF program_type sched_act is availableeBPF program_type tracepoint is availableeBPF program_type xdp is availableeBPF program_type perf_event is availableeBPF program_type cgroup_skb is availableeBPF program_type cgroup_sock is availableeBPF program_type lwt_in is availableeBPF program_type lwt_out is availableeBPF program_type lwt_xmit is availableeBPF program_type sock_ops is availableeBPF program_type sk_skb is availableeBPF program_type cgroup_device is availableeBPF program_type sk_msg is availableeBPF program_type raw_tracepoint is availableeBPF program_type cgroup_sock_addr is availableeBPF program_type lwt_seg6local is availableeBPF program_type lirc_mode2 is NOT availableeBPF program_type sk_reuseport is availableeBPF program_type flow_dissector is availableeBPF program_type cgroup_sysctl is availableeBPF program_type raw_tracepoint_writable is availableeBPF program_type cgroup_sockopt is availableeBPF program_type tracing is availableeBPF program_type struct_ops is availableeBPF program_type ext is availableeBPF program_type lsm is available

具体可参考

主要是分为3大使用场景：

跟踪

tracepoint, kprobe, perf_event等，主要用于从系统中提取跟踪信息，进而为监控、排错、性能优化等提供数据支撑。

网络

xdp, sock_ops, cgroup_sock_addr , sk_msg等，主要用于对网络数据包进行过滤和处理，进而实现网络的观测、过滤、流量控制以及性能优化等各种丰富的功能，这里可以丢包，重定向。

cilium基本用了所有的hook点。

安全和其他

lsm，用于安全，其他还有flow_dissector, lwt_in都是一些不怎么常用的，不再赘述。

eBPF的最佳实践是什么？

寻找内核的插桩点

从前面可以看出来eBPF程序本身并不困难，困难的是为其寻找合适的事件源来触发运行。对于监控和诊断领域来说，跟踪类eBPF程序的事件源包含3类：内核函数（kprobe）、内核跟踪点（tracepoint）或性能事件（perf_event）。此时有2个问题需要回答：

1、内核中都有哪些内核函数、内核跟踪点或性能事件？

使用调试信息获取内核函数、内核跟踪点

sudo ls /sys/kernel/debug/tracing/events

# 查询所有内核插桩和跟踪点sudo bpftrace -l# 使用通配符查询所有的系统调用跟踪点sudo bpftrace -l 'tracepoint:syscalls:*'# 使用通配符查询所有名字包含"open"的跟踪点sudo bpftrace -l '*open*'

sudo perf list tracepoint

2、对于内核函数和内核跟踪点，在需要跟踪它们的传入参数和返回值的时候，又该如何查询这些数据结构的定义格式呢？

使用调试信息获取

sudo cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/format

sudo bpftrace -lv tracepoint:syscalls:sys_enter_openat

具体如何使用以上信息，请参考bcc。

寻找应用的插桩点

1、如何查询用户进程的跟踪点？

静态编译语言通过-g编译选项保留调试信息，应用程序二进制会包含DWARF（Debugging With Attributed Record Format），有了调试信息，可以通过 readelf、objdump、nm 等工具，查询可用于跟踪的函数、变量等符号列表

# 查询符号表readelf -Ws /usr/lib/x86_64-linux-gnu/libc.so.6# 查询USDT信息readelf -n /usr/lib/x86_64-linux-gnu/libc.so.6

# 查询uprobebpftrace -l 'uprobe:/usr/lib/x86_64-linux-gnu/libc.so.6:*'# 查询USDTbpftrace -l 'usdt:/usr/lib/x86_64-linux-gnu/libc.so.6:*'

uprobe 是基于文件的。当文件中的某个函数被跟踪时，除非对进程 PID 进行了过滤，默认所有使用到这个文件的进程都会被插桩。

上面说的是静态编译语言，他和内核的跟踪类似，应用程序的符号信息可以存放在 ELF 二进制文件中，也可以以单独文件的形式，放到调试文件中；而内核的符号信息除了可以存放到内核二进制文件中之外，还会以 /proc/kallsyms 和 /sys/kernel/debug 等形式暴露到用户空间。

对于非静态编译语言来说，主要是两种：

1、解释型语言

使用类似编译型语言应用程序的跟踪点查询方法，查询它们在解释器层面的 uprobe 和 USDT 跟踪点，如何将解释器层面的行为和应用行为关联需要相关语言的专家来分析。

2、即时编译型语言

这类语言的应用源代码会先编译为字节码，再由即时编译器（JIT）编译为机器码执行，还会有大量的优化，跟踪难度很大，同解释型编程语言类似，uprobe 和 USDT 跟踪只能用在即时编译器上，从即时编译器的跟踪点参数里面获取最终应用程序的函数信息。找出即时编译器的跟踪点同应用程序运行之间的关系需要相关语言的专家来分析。

可以参考BCC的应用程序跟踪，用户进程的跟踪，本质上是通过断点去执行 uprobe 处理程序。虽然内核社区已经对 BPF 做了很多的性能调优，跟踪用户态函数（特别是锁争用、内存分配之类的高频函数）还是有可能带来很大的性能开销。因此，我们在使用 uprobe 时，应该尽量避免跟踪高频函数。

具体如何使用以上信息，请参考：

关联问题与插桩点

一个理想的状态是所有问题都清楚应当观察那些插桩点，但是这个要求技术人员对端到端的软件栈细节都了解十分透彻，一个更加合理的方法是二八法则，将软件栈数据流的最核心的80%脉络抓住，保障出现问题一定会在这个脉络被发现即可。此时再使用内核栈和用户栈来查看具体的调用栈即可发现核心问题，比如说发现了网络在丢包，但是不知道为什么丢，此时我们知道网络丢包一定会调用kfree_skb内核函数，那么我们可以通过：

sudo bpftrace -e 'kprobe:kfree_skb /comm=="<your comm>"/ {printf("kstack: %s\n", kstack);}'

发现该函数的调用栈：

kstack: kfree_skb+1 udpv6_destroy_sock+66 sk_common_release+34 udp_lib_close+9 inet_release+75 inet6_release+49 __sock_release+66 sock_close+21 __fput+159 ____fput+14 task_work_run+103 exit_to_user_mode_loop+411 exit_to_user_mode_prepare+187 syscall_exit_to_user_mode+23 do_syscall_64+110 entry_SYSCALL_64_after_hwframe+68

那么就可以回溯上面的函数，看看他们具体是哪一行在什么条件下调用的，就能够定位到问题。这个方法不仅可以定位问题，也可以用于加深对内核调用的理解，比如：

bpftrace -e 'tracepoint:net:* { printf("%s(%d): %s %s\n", comm, pid, probe, kstack()); }'

可以查看所有网络相关的跟踪点及其调用栈。

eBPF的实现原理是什么？

5个模块

eBPF在内核主要由5个模块协作：

1、BPF Verifier（验证器）

确保 eBPF 程序的安全。验证器会将待执行的指令创建为一个有向无环图（DAG），确保程序中不包含不可达指令；接着再模拟指令的执行过程，确保不会执行无效指令，这里通过和个别同学了解到，这里的验证器并无法保证100%的安全，所以对于所有BPF程序，都还需要严格的监控和评审。

2、BPF JIT

将 eBPF 字节码编译成本地机器指令，以便更高效地在内核中执行。

3、多个 64 位寄存器、一个程序计数器和一个 512 字节的栈组成的存储模块

用于控制eBPF程序的运行，保存栈数据，入参与出参。

4、BPF Helpers（辅助函数）

提供了一系列用于 eBPF 程序与内核其他模块进行交互的函数。这些函数并不是任意一个 eBPF 程序都可以调用的，具体可用的函数集由 BPF 程序类型决定。注意，eBPF里面所有对入参，出参的修改都必须符合BPF规范，除了本地变量的变更，其他变化都应当使用BPF Helpers完成，如果BPF Helpers不支持，则无法修改。

bpftool feature probe

通过以上命令可以看到不同类型的eBPF程序可以运行哪些BPF Helpers。

5、BPF Map & context

用于提供大块的存储，这些存储可被用户空间程序用来进行访问，进而控制 eBPF 程序的运行状态。

bpftool feature probe | grep map_type

通过以上命令可以看到系统支持哪些类型的map。

3个动作

先说下重要的系统调用bpf：

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

这里cmd是关键，attr是cmd的参数，size是参数大小，所以关键是看cmd有哪些：

// 5.11内核enum bpf_cmd {BPF_MAP_CREATE,  BPF_MAP_LOOKUP_ELEM,  BPF_MAP_UPDATE_ELEM,  BPF_MAP_DELETE_ELEM, BPF_MAP_GET_NEXT_KEY, BPF_PROG_LOAD,BPF_OBJ_PIN,BPF_OBJ_GET,  BPF_PROG_ATTACH, BPF_PROG_DETACH,  BPF_PROG_TEST_RUN,BPF_PROG_GET_NEXT_ID,  BPF_MAP_GET_NEXT_ID, BPF_PROG_GET_FD_BY_ID, BPF_MAP_GET_FD_BY_ID,BPF_OBJ_GET_INFO_BY_FD, BPF_PROG_QUERY, BPF_RAW_TRACEPOINT_OPEN, BPF_BTF_LOAD, BPF_BTF_GET_FD_BY_ID, BPF_TASK_FD_QUERY, BPF_MAP_LOOKUP_AND_DELETE_ELEM, BPF_MAP_FREEZE, BPF_BTF_GET_NEXT_ID, BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH,  BPF_MAP_DELETE_BATCH,  BPF_LINK_CREATE,BPF_LINK_UPDATE, BPF_LINK_GET_FD_BY_ID,BPF_LINK_GET_NEXT_ID, BPF_ENABLE_STATS, BPF_ITER_CREATE,BPF_LINK_DETACH,BPF_PROG_BIND_MAP,};

最核心的就是PROG，MAP相关的cmd，就是程序加载和映射处理。

1、程序加载

调用BPF_PROG_LOAD cmd，会将BPF程序加载到内核，但eBPF 程序并不像常规的线程那样，启动后就一直运行在那里，它需要事件触发后才会执行。这些事件包括系统调用、内核跟踪点、内核函数和用户态函数的调用退出、网络事件，等等，所以需要第2个动作。

2、绑定事件

b.attach_kprobe(event="xxx", fn_name="yyy")

以上就是将特定的事件绑定到特定的BPF函数，实际实现原理如下：

（1）借助 bpf 系统调用，加载 BPF 程序之后，会记住返回的文件描述符；

（2）通过attach操作知道对应函数类型的事件编号；

（3）根据attach的返回值调用 perf_event_open 创建性能监控事件；

（4）通过 ioctl 的 PERF_EVENT_IOC_SET_BPF 命令，将 BPF 程序绑定到性能监控事件。

3、映射操作

通过MAP相关的cmd，控制MAP增删，然后用户态基于该MAP与内核状态进行交互。

eBPF的发展现状？

内核支持

建议>=4.14

生态

eBPF的生态自下而上的情况如下：

1、基础设施

支持eBPF基础能力的发展。

Linux KernalLLVM

2、开发工具集

主要是用于加载，编译，调试eBPF程序，不同语言有不同的开发工具集：

GoC/C++

3、eBPF应用

bcc（）

提供一套开发工具和脚本。

bpftrace（）

基于bcc，提供一个脚本语言。

cilium（）

网络优化和安全

Falco（）

网络安全

Katran（）

高性能4层负载均衡

Hubble（）

可观测

Kindling（）

可观测

Pixie（）

可观测

kubectl trace（）

调度bpftrace脚本

L3AF（）

分布式环境下启动和管理eBPF程序的平台

ply（）

动态linux trace

Tracee（）

Linux运行时安全监测

4、跟踪生态的网站

写在最后

用好eBPF的前提是对软件栈的理解

通过上面的介绍，相信大家对eBPF已经有了足够的理解，eBPF提供的只是一个框架和机制，核心还是需要用eBPF的人对软件栈的理解，找到合适的插桩点，能够和应用问题进行关联。

eBPF的杀手锏是全覆盖，无侵入，可编程

1、全覆盖

内核，应用程序插桩点全覆盖。

2、无侵入

不需要修改任何被hook的代码。

3、可编程

动态下发eBPF程序，边缘动态执行指令，动态聚合分析。

作者 | 炎寻

原文链接：

本文为阿里云原创内容，未经允许不得转载。