eBPF 实战入门：从 BCC 到 bpftrace 的可观测性工具链

为什么你该关注 eBPF 工具链

近几年，围绕 eBPF 的可观测性工具井喷式出现，但真正让一线工程师感受到“这东西能干活”的，往往不是那些高大上的商业方案，而是两个轻量级的命令行工具：BCC 和 bpftrace。它们早就在 Netflix、Facebook 等公司的生产环境中默默服役，只是很多人对它们的认知还停留在“高级调试工具”的层面，没意识到这其实是一条完整的内核级可观测性工具链。

传统的系统监控，要么靠读取 /proc 文件系统获得粗糙的统计信息，要么插入内核模块（比如 SystemTap）带来稳定性和安全风险。eBPF 的出现，让我们可以在不修改内核、不重启服务的前提下，安全地运行自定义的观测程序，直接从内核函数、系统调用、网络事件中提取指标。这听起来很理想，但上手时你会发现，直接写 eBPF 程序门槛很高，需要了解内核数据结构、eBPF 字节码和验证器规则。于是，BCC 和 bpftrace 作为 eBPF 的前端工具，承担了降低门槛的角色。

BCC 和 bpftrace 不是竞争对手

很多人第一次接触这两个工具时，会下意识地比较谁更好用、谁更强大。这种想法容易让人忽略它们的本质定位：BCC 是一个 Python 库，提供了一套封装好的 eBPF 编程接口，允许你用 Python 编写 eBPF 程序，然后加载到内核中；而 bpftrace 则是一种专门为 eBPF 设计的脚本语言，灵感来自 DTrace 和 awk，适合单行命令或短脚本。

换句话说，BCC 更像是一套 SDK，bpftrace 更像是一个命令行工具。如果你需要长期运行的监控代理、复杂的统计逻辑，或者有自己的输出格式需求，BCC 的 Python 灵活性会让你得心应手；如果你只是想快速揪出某个系统调用的延迟抖动，或者统计某个内核函数的调用频率，bpftrace 的一行命令比任何工具都直接。

它们都属于 iovisor 项目，共享 eBPF 基础设施，但针对的问题域不同。一个不恰当的类比：BCC 像是用 C 写一个专用工具，bpftrace 像是用 AWK 写一个一次性脚本。在工程中，它们往往配合使用，而不是二选一。

一个场景看清谁的效率更高

假设你正在负责一个在线服务，突然收到告警说 P99 延迟从 200ms 飙升到了 3 秒，但 CPU、内存、网络流量都很正常。这种时候，传统监控可能帮不上忙，你需要直接看内核中发生了什么。你怀疑是某个文件系统操作变慢了，但不确定是哪个文件、哪个进程。用 bpftrace，你可以即时执行一条命令：

bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } kretprobe:vfs_read /@start[tid]/ { @ms = hist((nsecs - @start[tid]) / 1000000); delete(@start[tid]); }'

这条命令会统计所有 vfs_read 调用的延迟分布，并以直方图形式输出。几秒钟后，你就能看到大多数请求都很快，但有一个明显的尾巴，延迟集中在某个区间。结合 comm 或 pid 过滤，你很快就能定位到元凶。整个过程不需要编译，不需要重启，甚至不需要 root 权限（如果配置了 CAP_BPF）。

现在考虑另一个场景：你的团队需要长期监控所有容器内 TCP 连接的建立时长，并输出到 Prometheus。这种需求就不适合 bpftrace 了，因为它缺少持久化、复杂的指标聚合和外部输出能力。用 BCC，你可以写一个 Python 脚本，在内核中跟踪 tcp_set_state 的变化，计算连接建立时间，然后通过 eBPF map 将数据传递到用户态，再暴露为 HTTP 端点。BCC 的 Python 绑定让你可以轻松处理这些逻辑，而不用在内核态写复杂的代码。

这两个例子展示了核心区别：bpftrace 适合“一时一地的诊断”，BCC 适合“持续运行的观测”。

代码对比：统计系统调用，bpftrace 一行 vs BCC 几十行

为了更直观地感受差异，我们来看一个简单任务：统计所有进程调用 read() 系统调用的次数。bpftrace 的实现如下：

bpftrace -e 'tracepoint:syscalls:sys_enter_read { @counts[comm] = count(); }'

它会持续输出每个进程的 read 调用计数，按 Ctrl-C 时打印汇总。而 BCC 实现同样的功能，需要这样一个 Python 脚本：

from bcc import BPF

bpf_text = '''
#include 

BPF_HASH(counts, u32);

int trace_read(struct tracepoint__syscalls__sys_enter_read *ctx) {
    u32 pid = bpf_get_current_pid_tgid() >> 32;
    counts.increment(pid);
    return 0;
}
'''

b = BPF(text=bpf_text)
b.attach_tracepoint(tp=\"syscalls:sys_enter_read\", fn_name=\"trace_read\")

while True:
    try:
        sleep(1)
        for k, v in b[\"counts\"].items():
            print(\"Pid %d: %d\" % (k.value, v.value))
        b[\"counts\"].clear()
    except KeyboardInterrupt:
        exit()

可以看到，BCC 需要你显式定义 eBPF 程序、声明 map、处理数据读取，而 bpftrace 把这些都抽象掉了。但 BCC 的代码也给了你更大的控制权：你可以自定义输出格式、添加过滤条件、将数据发送到外部系统，这些在 bpftrace 中很难做到。

选型中容易踩的四个坑

误区一：bpftrace 只能做简单的统计。实际上 bpftrace 支持条件判断、聚合函数、多探针关联，甚至能调用少量内置函数，完成相当复杂的分析，比如追踪内存分配、分析锁竞争。但它的限制在于程序是单次运行的，状态只在 map 中保存，不能做复杂的控制流。如果你需要根据历史数据做决策，或者需要将数据写入外部存储，bpftrace 就不够用了。

误区二：BCC 一定比 bpftrace 性能好。BCC 允许你精细控制 eBPF 程序的加载和 map 的使用，理论上可以做到更优。但多数情况下，bpftrace 的默认开销已经极低，因为它会尽量合并事件、减少数据拷贝。对于临时排查，性能差异可以忽略不计。真正影响性能的是你追踪的事件频率和你写的逻辑，而不是工具。

误区三：学会 BCC 就掌握了 eBPF。BCC 隐藏了很多 eBPF 的细节，比如编译、验证、map 类型等，使用 BCC 不需要直接写 eBPF 字节码，但如果你打算深入 eBPF 开发，比如写自己的 eBPF 程序加载器，或者需要绕过 BCC 的限制，你会发现 bpftrace 的透明性反而让你更接近 eBPF 的本质。两者结合学习，才能真正理解 eBPF 的运作方式。

误区四：eBPF 程序一定会拖慢系统性能。eBPF 程序运行在内核中，的确会引入开销，但现代内核的 JIT 编译和验证器会将开销降到极低，对于大多数监控场景，影响小于 1%。真正危险的是在高频事件上（如网络数据包）进行复杂的聚合和打印，这会导致事件缓冲区溢出，甚至丢失数据。BCC 和 bpftrace 都提供了限制事件速率的方法，比如 bpftrace 的 -M 选项，可以设定最大每秒事件数，避免教科书级的自残式追踪。只要合理使用，eBPF 不会成为性能瓶颈，反而能帮你找到真正的瓶颈。

一张表帮你整理选型思路

这不是非黑即白的选择，很多团队会同时使用两者：日常监控用 BCC 开发的工具，突发问题用 bpftrace 现场诊断。

入门路径：从 bpftrace 开始，向 BCC 深入

如果你刚刚接触 eBPF 可观测性，建议先花几天时间玩转 bpftrace。它的语法直观，你可以在几分钟内写出第一个探针，立刻看到内核级的数据。这种正反馈很重要，否则很容易被 BCC 的安装和编译劝退。有几点实践建议：

• 先用 bpftrace 的 -l 参数列出所有可用的探针点，比如 bpftrace -l 'kprobe:vfs_*'，了解内核中哪些函数可以追踪。
• 从简单的计数开始，比如统计系统调用、磁盘 I/O 大小，再尝试直方图、延时统计。
• 学会使用 map 和条件过滤，实现更复杂的分析，比如只追踪特定进程、特定文件描述符。

当你能熟练地用 bpftrace 解决线上问题后，再尝试用 BCC 将一些常用的分析脚本固化为工具。BCC 的安装可能略麻烦，需要内核头文件和 LLVM 编译环境，但一旦就绪，你就可以复用社区已有的 BCC 工具，或者基于它们修改。一个比较好的实践是，先用 bpftrace 验证你的追踪思路，确认该探针能提供有效信息，再用 BCC 将它产品化，添加错误处理、日志、指标输出。

另外，无论是 BCC 还是 bpftrace，都要注意内核版本和 eBPF 特性支持。较新的内核（5.x 以上）对 BTF、环形缓冲区等支持更好，能显著简化 BCC 的开发。如果内核太旧，你可能需要依赖 BCC 的运行时编译，这又会增加复杂度。在内核版本选择上，往前看永远比向后兼容更划算。

不要神化 eBPF，工具链是手段

最后想强调的是，eBPF 虽然强大，但它不是银弹。它适合深入内核、网络和数据路径的可观测性，但对应用层逻辑、业务指标、分布式追踪，还是需要结合传统的 APM 和日志系统。BCC 和 bpftrace 让你拥有了内核级的视角，但如何解读数据、定位问题，仍然依赖你对系统的理解。别把工具当成目的，你的目标是搞清楚系统到底在做什么。有了 BCC 和 bpftrace 这条工具链，你手里就多了一把打开内核黑盒的钥匙，但怎么用，还是得靠你自己。