Linux eBPF 的 bcc vs bpftrace vs libbpf-tools 的开发工具链对比

该用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("hitn"); }' 无输出，但换成 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 包。