BPF与eBPF简介：核心概念与观测工具概览

BPF的起源与演进：从Berkeley Packet Filter到通用执行引擎

BPF（Berkeley Packet Filter）最初于1992年由Steven McCanne和Van Jacobson提出，旨在提升网络包捕获工具的性能。它通过在内核中运行精简的指令集，只复制用户感兴趣的数据包，显著降低了数据拷贝的开销。经过二十多年的发展，2013年Alexei Starovoitov提出对BPF进行重大重写，随后与Daniel Borkmann共同完善，于2014年合入Linux内核主线。这一新版本被称为eBPF（Extended BPF），但官方缩写仍统一为BPF。如今的BPF已不再是单纯的包过滤器，而是一个通用的内核执行引擎，允许用户在内核和应用程序事件上运行小型安全程序，覆盖网络、可观测性、安全三大领域。本书将聚焦于可观测性（tracing）方向。

eBPF核心能力：指令集、验证器与JIT编译

eBPF的核心由三部分组成：

指令集：eBPF定义了一套虚拟指令集（类似RISC架构），支持64位寄存器、跳转、函数调用等，程序大小最初限制为4096条指令（后扩展至100万条）。
验证器（Verifier）：所有eBPF程序在加载时必须通过静态验证，确保程序不会导致内核崩溃或死循环。验证器会模拟执行每条指令，检查指针访问范围、循环边界等。
JIT编译器：eBPF程序可以即时编译为本地机器指令，从而获得接近原生性能。内核同时保留解释器用于调试或低负载场景。
存储对象（Maps）：eBPF程序通过Map与用户态共享数据，Map支持键值对、数组、哈希表等结构，程序运行时可以更新和查询Map。

关键术语辨析：Tracing、Snooping、Sampling与Observability

在性能分析领域，理解以下术语至关重要：

Tracing（追踪） ：基于事件的记录。工具捕获原始事件及其元数据（如系统调用参数、时间戳）。典型工具如strace(1)、tcpdump(8)。BPF程序可以在事件发生时执行自定义统计，避免后处理开销。
Snooping（窥探） ：与Tracing含义相近，常见于早期Solaris工具命名（如execsnoop、opensnoop）。Bruce Gregg早期在Solaris上开发的工具采用了"snooping"术语，并延续至今。
Sampling（采样） ：按固定间隔采集子集数据，例如每秒100次采样。开销低，但可能丢失短时事件。profile(8)是典型采样工具。
Profiling（性能分析）：通常与Sampling同义，侧重通过采样构建执行路径的统计画像。
Observability（可观测性）：通过观测系统状态来理解行为，包括Tracing、Sampling及基于固定计数器的工具。BPF工具属于可观测性工具，不改变系统状态（与基准测试工具区分）。

BPF前端工具：BCC与bpftrace

直接编写eBPF指令极其繁琐，社区开发了高层前端框架，主要为BCC和bpftrace。

BCC（BPF Compiler Collection）

BCC是首个为tracing设计的BPF高层框架。它提供C语言编写内核BPF代码，用户态接口支持Python、Lua和C++。BCC仓库包含超过70个现成工具，可直接运行，无需编写代码。例如：

bash 复制代码

# execsnoop -t
TIME(s) PCOMM PID PPID RET ARGS
0.437 run 15524 4469 0 ./run
0.438 bash 15524 4469 0 /bin/bash

BCC工具功能复杂，支持多种命令行选项（如-x仅显示失败调用、-p指定进程ID等），适合长时间运行或需要精细控制的场景。

bpftrace

bpftrace提供专为tracing设计的高级语言，语法简洁，一行代码即可完成复杂任务。例如：

console 复制代码

# bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }'

bpftrace适合快速定制的单行命令和短脚本。它依赖libbcc和libbpf库，同样属于IO Visor项目。BCC与bpftrace互补：bpftrace用于快速原型和调试，BCC用于生产级复杂工具。

IO Visor项目

BCC和bpftrace均托管在Linux基金会下的IO Visor项目中，代码仓库位于GitHub：

该项目还包含其他BPF相关工具和库（如libbpf）。

动态插桩与静态插桩：选择与策略

BPF支持多种事件源，插桩方式分为动态和静态两类。

动态插桩（kprobes / uprobes）

通过修改内存中指令的方式，可以任意插入探针到内核函数（kprobes）或用户态函数（uprobes）。优点是无额外开销（不使用时），且能探查几乎所有函数。缺点是函数名可能因版本升级变更，或编译器内联导致探针失效。

Probe	描述
`kprobe:vfs_read`	内核`vfs_read()`函数入口
`kretprobe:vfs_read`	内核`vfs_read()`函数返回
`uprobe:/bin/bash:readline`	`/bin/bash`中`readline()`函数入口
`uretprobe:/bin/bash:readline`	`/bin/bash`中`readline()`函数返回

静态插桩（Tracepoints / USDT）

内核开发者预定义的稳定探针点（tracepoints），以及应用层通过USDT（用户级静态定义跟踪）暴露的探针。优点是接口稳定，不会被内联影响；缺点是维护负担重，数量有限。

Probe	描述
`tracepoint:syscalls:sys_enter_open`	`open(2)`系统调用入口
`usdt:/usr/sbin/mysqld:mysql:query__start`	MySQL查询开始事件

实践策略

推荐优先使用静态插桩（tracepoints / USDT），因为接口稳定；当静态点不足时，再回退至动态插桩。例如，opensnoop既可使用tracepoint:syscalls:sys_enter_openat，也可使用kprobe:do_sys_open。静态插桩提供更好的兼容性。

实践示例：使用execsnoop和opensnoop

用execsnoop发现短期进程

BCC的execsnoop(8)跟踪execve(2)系统调用，实时打印新进程信息。在生产环境中曾发现某服务器每隔一秒启动30个进程（由错误配置的服务引发），导致基准测试结果波动。运行execsnoop后问题立即暴露：

bash 复制代码

# execsnoop
PCOMM PID PPID RET ARGS
run 12983 4469 0 ./run
bash 12983 4469 0 /bin/bash

用biolatency分析磁盘延迟分布

biolatency(8)将块设备I/O延迟汇总为直方图：

bash 复制代码

# biolatency -m
Tracing block device I/O... Hit Ctrl-C to end.
^C
msecs               : count     distribution
0 -> 1              : 16335    |****************************************|
2 -> 3              : 2272     |*****                                |
...
512 -> 1023         : 11       |                                    |

输出显示双峰分布，且存在512--1023ms的异常值，可进一步用其他BPF工具定位。

bpftrace与BCC的opensnoop对比

bpftrace版opensnoop.bt：

console 复制代码

# opensnoop.bt
PID    COMM            FD ERR PATH
2440   snmp-pass       4   0   /proc/cpuinfo

BCC版opensnoop支持-x、-p等20+选项，更灵活：

bash 复制代码

# opensnoop -x
PID    COMM            FD ERR PATH
991    irqbalance      -1   2   /proc/irq/133/smp_affinity

两种工具均可直接使用，无需编程。

总结

BPF/eBPF为Linux提供了前所未有的可观测性能力。理解其核心概念（指令集、验证器、Map），明确Tracing/Sampling等术语，掌握BCC和bpftrace的用法与差异，并合理选择动态/静态插桩策略，是高效使用BPF性能工具的基础。对于开发者而言，BCC提供开箱即用的丰富工具，bpftrace则适合快速编写自定义探针。建议从尝试execsnoop、biolatency等工具开始，逐步深入实践。