该用bcc而非bpftrace的场景是需精细控制ebpf生命周期、复用c逻辑或嵌入python/c++应用时;bpftrace仅适合一次性命令行探针。

什么时候该用 bcc,而不是 bpftrace
bcc 适合需要精细控制 eBPF 程序生命周期、频繁复用 C 风格逻辑、或要嵌入到 Python/C++ 应用里的场景。比如你要写一个持续采集 TCP 重传事件并聚合进 Prometheus 的守护进程,bcc 提供的 BPF 类和 perf_buffer 接口能直接对接业务逻辑;而 bpftrace 更像“一次性命令行探针”,写完就跑,不便于状态维护或复杂数据结构处理。
常见错误现象:用 bpftrace 尝试做跨事件状态跟踪(比如匹配 tcp_sendmsg 和后续的 tcp_retransmit_skb),结果发现没有变量持久化能力,脚本卡死或输出错乱。
-
bcc支持自定义 map 类型(如LRU_HASH)、用户态回调函数、多阶段加载,bpftrace只支持固定几种内置 map(hist,count,sum) -
bcc编译依赖完整内核头文件(/lib/modules/$(uname -r)/build),bpftrace只需运行时内核 BTF 或调试信息 -
bcc的 Python 绑定在容器里容易因ctypes加载失败报ImportError: libbcc.so;bpftrace是静态链接二进制,更轻量
libbpf-tools 和 bcc 的根本区别在哪
libbpf-tools 是纯 C 实现、基于 libbpf + BTF + CO-RE 的工具集,目标是“一次编译、到处运行”;bcc 是运行时 JIT 编译,每次启动都要解析 C 代码、生成 eBPF 字节码、再加载,对内核版本强敏感。
典型使用场景:你在 CentOS 7(内核 3.10)上没法用 bcc 运行 biolatency,因为缺少 bpf_probe_read_kernel 等 helper;但 libbpf-tools/biolatency 如果有对应 BTF,就能直接跑——前提是你的内核开启了 CONFIG_DEBUG_INFO_BTF=y。
-
libbpf-tools不依赖 clang/LLVM 运行时,部署包体积小(单个可执行文件),bcc需要安装python3-bcc+clang+ 内核头 -
libbpf-tools的错误提示更底层(比如libbpf: failed to load object: Invalid argument),往往指向 BTF 缺失或 CO-RE 重定位失败;bcc报错更“友好”但可能掩盖真实问题(如把struct sock成员偏移算错归为“unknown field”) -
libbpf-tools默认不带 Python 接口,想二次开发得自己写libbpf调用;bcc天然支持 Python 脚本热改逻辑
为什么 bpftrace 的 tracepoint 比 kprobe 更稳
因为 tracepoint 是内核预定义的稳定钩子点,接口契约明确;kprobe 是动态插桩函数入口,一旦内核函数签名变更(比如加了参数、改了 inline 行为),bpftrace 的 kprobe:do_sys_open 就可能找不到符号,或者读取寄存器出错导致 invalid memory access。
常见错误现象:在较新内核(6.1+)上用 bpftrace -e 'kprobe:tcp_v4_connect { printf("hit\n"); }' 无输出,但换成 tracepoint:net:inet_connect 就立刻生效——后者由内核维护 ABI 兼容性,前者依赖具体函数实现细节。
-
tracepoint性能开销更低(无寄存器保存/恢复),且不会因函数内联失效 -
tracepoint参数类型固定(通过/sys/kernel/debug/tracing/events/<cat>/<event>/format</event></cat>查),kprobe得靠ptregs手动解析,容易错位 - 不是所有函数都有对应
tracepoint,查可用列表用ls /sys/kernel/debug/tracing/events/,缺的话只能退回到kprobe或换bcc做条件判断
libbpf-tools 启动失败最常见的三个原因
不是代码写错了,而是环境没对齐。最常卡在 BTF、CO-RE 和权限三块。
典型错误信息:libbpf: failed to find valid kernel BTF、libbpf: Error in bpf_object__load_xattr: Permission denied、libbpf: prog 'xxx': failed to apply relocations。
- BTF 缺失:检查
/sys/kernel/btf/vmlinux是否存在,不存在就装kernel-debuginfo包(RHEL/CentOS)或linux-image-extra-$(uname -r)(Ubuntu) - CO-RE 重定位失败:说明目标内核结构体布局和编译时差异太大,尝试加
#define LIBBPF_FORCE_COERCE或降级到更接近的内核版本重新编译 - 权限不足:普通用户无法加载部分 program type(如
tracing),需sudo或配置/proc/sys/kernel/unprivileged_bpf_disabled=0(注意安全影响)
bpftrace -l | grep tcp 看 tracepoint 是否覆盖你要的路径,再试 libbpf-tools/biosnoop 能不能跑通,最后才决定要不要上 bcc 写定制逻辑。BTF 和 CO-RE 这些词听着高级,但卡住的时候,往往就是少装了一个 debuginfo 包。










