1. 项目概述为什么要在 CentOS 7 上折腾 eBPF 工具链先给不太熟悉的朋友交个底bcc 和 bpftrace 都是基于 eBPF扩展的伯克利包过滤器技术的动态追踪工具它们可以让你在不修改内核源码、不加载内核模块的情况下安全地观测内核和应用程序的运行时行为。简单说服务器出了性能问题、进程行为诡异、网络延迟突然升高这类问题靠 top、iostat、ss 这些传统工具往往只能看到表象而 bcc 和 bpftrace 能直接看到内脏——比如某个函数被调用了多少次、每次耗时多少、堆内存是谁分配的、某个进程为什么卡在 D 状态。这个项目解决的问题很明确在 CentOS 7 这个上了年纪的操作系统上把 eBPF 工具链完整地跑起来。CentOS 7 默认自带的 3.10 内核其实已经支持了 eBPF 的基础能力但官方源里的工具链版本很老内核头文件和用户态工具之间还经常出现版本不匹配的问题很多人在第一步就被各种编译错误劝退。适合看这篇文章的人手里还攥着 CentOS 7 服务器没迁移的运维工程师、想学 eBPF 但手头只有老环境的后端开发、以及在大规模集群里需要排查诡异性能问题的 SRE。我自己当年在这个环境下折腾了整整两天从 yum 源到源码编译踩了个遍这篇文章就是把那些坑一个一个填平之后总结出来的完整路径。2. 环境评估与前置条件动手之前先看清家底2.1 内核版本与权限检查三分钟确认能不能玩eBPF 对内核版本有硬性要求CentOS 7 的 3.10 内核是支持 eBPF 的最低配但不同小版本之间差异很大。建议先执行两条命令uname -r cat /boot/config-$(uname -r) | grep BPF如果内核配置文件里能看到CONFIG_BPFy、CONFIG_BPF_SYSCALLy、CONFIG_KPROBESy、CONFIG_BPF_JITy这几项就说明核心功能已经打开了。我见过有些云厂商提供的 CentOS 7 镜像阉割过内核配置BPF_JIT 没开导致后续性能折损严重所以这一步值得花三分钟确认。还要确认你有 root 权限。eBPF 程序加载本身需要CAP_BPF或 root 权限普通用户即使能跑工具也会在加载阶段直接报Operation not permitted。开发环境就直接用 root生产环境建议配合 sudo 策略把特定工具授权给指定账号就行。2.2 开发工具链准备gcc 版本是个隐形门槛CentOS 7 出厂自带的 gcc 是 4.8.5这个版本编译普通的 C 程序没问题但遇到 bcc 和 bpftrace 的现代 C 代码就会报各种奇奇怪怪的语法错误。网上很多教程没提这茬导致大家卡在编译第一步还以为是依赖没装全。解决方法是启用 Software CollectionsSCL源把 gcc 升级到 7.x 或更高yum install -y centos-release-scl yum install -y devtoolset-7 scl enable devtoolset-7 bash注意scl enable只在当前终端生效如果想永久生效就写进/etc/profile.d/下。另外建议把cmake3也装上bcc 的源码编译默认找的是 cmake 而非 cmake3CentOS 7 上需要做个小软链。yum install -y cmake3 ln -s /usr/bin/cmake3 /usr/local/bin/cmake顺带把后续编译可能用到的依赖一次性装齐yum install -y git gcc-c flex bison python3 python3-devel \ elfutils-libelf-devel libtraceevent-devel luajit-devel \ ncurses-devel有个细节容易忽略libtraceevent-devel在 CentOS 7 默认源里没有需要先开启 EPEL 源。如果装不上也别慌bpftrace 源码包里自带了一个 libtraceevent 的依赖目录但强烈建议优先用系统包否则编译时间会明显变长。2.3 内核头文件与 debuginfo两个经典大坑CentOS 7 上跑 eBPF 工具内核头文件的重要性怎么强调都不过分。bcc 在加载 kprobe 类程序时需要在宿主机上找到内核符号表和结构体定义缺了这些头文件工具会直接报cannot find kernel version或者failed to open /lib/modules/$(uname -r)/build。标准的安装命令yum install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)这里有个常年不变的坑CentOS 7 的 yum 源里面 kernel-devel 的版本号可能跟当前内核版本对不上尤其是你手动升级过内核的情况下。如果你发现 yum 装不上对应版本别无脑换源直接去 vault.centos.org 找到对应版本的 RPM 手动装更快。另外强烈建议安装 kernel-debuginfo因为 bcc 的部分功能特别是 trace 和 profile 类的工具需要 DWARF 调试信息才能做变量的精准解析。Debuginfo 包体积很大大概 1-2 GB但能让你少踩一半的坑。如果磁盘吃紧可以只装kernel-debuginfo-common至少能解决大部分结构体解析问题。3. 安装路径选型yum、预编译二进制、源码编译三条路线实测3.1 yum 官方源与第三方源对比版本老但能用CentOS 7 默认源里其实是有 bcc 的版本大概是 0.10 左右bpftrace 则根本不在源里。如果你的场景只是做基础的追踪分析yum 直装是性价比最高的方案但它有个硬伤——bcc 0.10 对 Python3 脚本的支持不完整部分新特性比如bpf_iter完全没有。yum install -y bcc bcc-tools python3-bcc装完验证一下ls /usr/share/bcc/tools/ | head -20 /usr/share/bcc/tools/execsnoop这里要多说一句CentOS 7 上 bcc 的工具目录是/usr/share/bcc/tools/而非新版本 CentOS 下的/usr/share/bcc/tools/或者/usr/sbin/环境变量 PATH 里动过手脚的朋友容易以为没装上。如果想要新版本业界常用的第三方源是 IO Visor 项目维护的 yum 源。这个源提供的 bcc 和 bpftrace 都比较新安装也省事但问题是源地址在国外国内服务器的下载速度不稳定而且镜像失效的情况时有发生。3.2 源码编译 bcc自定义功能的前提如果你需要最新的 bcc 特性或者需要在编译时打开额外的功能开关源码编译是绕过老版本问题的根治手段。bcc 的编译依赖包括完整的内核开发环境kernel-devel 必须严格匹配LuaJIT1.0 以上版本libelf、elfutils 库Python3 开发头文件编译动作本身不算复杂git clone https://github.com/iovisor/bcc.git mkdir -p bcc/build cd bcc/build cmake .. -DCMAKE_INSTALL_PREFIX/usr/local -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg make -j$(nproc) make install但有几个细节会让第一次编译的人吃大亏elfutils 版本CentOS 7 自带的 elfutils 版本偏低编译 bcc 时可能会链接失败报什么libdw相关错误。解决方法是升级到较新的 elfutils 版本这一步千万别跳过否则编到一半出错会浪费大量时间。Python 绑定bcc 的 Python 绑定是要单独被 cmake 识别的如果 cmake 找不到 Python3 的开发库编译出来就只有 cc 工具可以工作。可以在 cmake 之后查看输出的摘要信息确认PYTHON3 bindings: YES再继续。LLVM 依赖问题bcc 的代码生成依赖 LLVM。CentOS 7 的默认 LLVM 版本同样偏老具体表现是编译时报Unsupported LLVM version。解决方案是升级 LLVM 到 7.0 以上或者最直接的办法就是用 EPEL 或 SCLL 源里的 LLVM 版本。考虑到 CentOS 7 的源码编译链路非常脆弱我的建议是优先尝试安装预编译版本只在必须使用最新特性时才做源码编译且把源码编译放在编译过程中可以反复循环利用的容器或虚拟机上。3.3 源码编译 bpftrace与 bcc 的依赖关系bpftrace 的源码编译比 bcc 更容易踩坑因为它对依赖的版本更加敏感。官方要求的依赖包括新版内核中出现的 BPF 特性CentOS 7 的 3.10 需要自行确认libbpf新版 bpftrace 使用 libbpf 作为 BPF 程序的加载后端LLVM同样需要新版libpcap用于从离线包捕获的网络追踪编译过程大致是git clone https://github.com/iovisor/bpftrace.git cd bpftrace mkdir -p build cd build cmake -DCMAKE_BUILD_TYPERelease .. make -j$(nproc) make install这里有个非常危险的点bpftrace 的大部分版本需要libbpf的动态加载支持而 CentOS 7 的libbpf源码编译依赖libelf和zlib。如果你在编译 bpftrace 时发现Could NOT find LibBpf之类提示优先检查系统里有没有安装libbpf-dev或者源码编译的libbpf-devel。重要提示bpftrace 和 bcc 的源码在编译时可能相互影响。比如你先把 bcc 装到了/usr/local/include/bcc/bpftrace 的 cmake 在探测系统 bcc 的时候可能会错误地将 bpftrace 指向 bcc 的头文件路径导致类型冲突。建议先编译安装 bcc 一步到位再编译 bpftrace别交叉装。3.4 三种方案对比总结我把三种方案的利弊整理成表格方便决策方案优点缺点适用场景yum 默认源安装快、依赖自动处理版本老、bpftrace 没有快速验证、传统运维场景IO Visor 第三方源bcc 和 bpftrace 都有、版本较新国内网络慢、镜像不稳定有外网、不想编译的用户源码编译版本最新、可定制特性编译时间长、依赖坑多需要新功能、二次开发我在实际工作中通常用第二种方案做快速验证验证过了再去生产环境用第一种方案——生产环境求稳工具版本老一点无所谓能稳定输出数据才是硬道理。如果确实遇到内核版本和工具版本不兼容的情况才会考虑第三种方案。4. 内核与 bcc/bpftrace 的适配细节3.10 内核的特殊性4.1 3.10 内核上 eBPF 的功能边界CentOS 7 默认的 3.10 内核支持 eBPF 基本机制但缺少很多后续内核才有的高级特性。常见的受限制能力包括Map 并发操作的原子语义差异Helper 函数的数量有限制tracepoint 暴露的事件种类不够多kprobe 在部分特定函数上无法挂载其中影响最大的还是 perf event 相关的 BPF 程序类型。在 3.10 上如果你想用 bcc 做 CPU 性能分析需要开启 perf event 的采样机制这个功能在 3.10 上确实可用但对采样频率上限有限制不如新版内核顺畅。另外3.10 内核不支持 BPF-to-BPF 函数调用bpf2bpf这意味着你写 bcc 脚本时不能像新版那样方便地拆分公共函数所有逻辑基本要靠 inline 或者宏展开来完成。这在复杂脚本里特别让人抓狂写出来的代码又长又绕。如果业务确实需要复杂脚本我个人建议尽早转向 4.18 内核的发行版。4.2 kprobe、tracepoint 与 uprobe 的挂载限制在实际使用 bcc 和 bpftrace 时最常接触的三种采集点是 kprobe、tracepoint 和 uprobe。CentOS 7 内核在这三者的支持上都有自己的脾气kprobe通过动态修改内核指令来插入探针适合追踪内核函数。3.10 的 kprobe 在多数常见函数上都能工作但如果你追踪的函数处于内核热路径且优化级别高kprobe 可能因为指令替换位置不可用而注册失败。遇到这种情况可以改用 kretprobe返回值探针或者换一个同功能的 tracepoint。tracepoint是内核静态埋点稳定性最高。3.10 的 tracepoint 数量大概有几百个覆盖了调度、块设备、内存、网络等核心子系统。推荐优先用 tracepoint因为它不受函数 inline 影响参数解析也可靠。uprobe用于追踪用户态程序。3.10 的 uprobe 功能已经能工作但有一个常见坑如果你追踪的目标程序是动态共享库符号可能不在主执行文件里面这时 uprobe 挂载会失败或者挂到错误的地址。更好的做法是用uretprobe搭配特定符号来追踪。4.3 内核参数与安全模块的影响CentOS 7 上还需要注意kernel.unprivileged_bpf_disabled这个 sysctl 参数。默认情况下这个值可能是 0表示允许非特权用户加载部分类型的 BPF 程序。但 bcc 和 bpftrace 大多数工具都需要 root 权限所以这个参数影响不大。真正影响大的是 SELinux 和容器环境。如果你的 CentOS 7 开了 SELinux enforcing 模式bcc 工具可能因为安全策略禁止访问/sys/kernel/debug/tracing而失败。遇到这种问题临时测试可以setenforce 0但更合理的做法是写一条针对性的 SELinux 模块放行而不是全局关闭。容器场景要特别留意在容器内使用 bcc 基本都会失败因为容器默认没有挂载/sys/kernel/debug也没有权限访问宿主机的 tracefs。需要在 docker run 时显式挂载docker run -it --privileged \ -v /sys/kernel/debug:/sys/kernel/debug:rw \ -v /lib/modules:/lib/modules:ro \ -v /usr/src:/usr/src:ro \ your-image5. 实操过程与核心环节实现跑通第一个 eBPF 程序5.1 环境自检脚本废话不多说先写一个环境自检脚本把前面所有要点都串起来。这段脚本可以帮你判断当前环境是否具备运行 bcc 工具的条件#!/bin/bash echo Kernel Version uname -r echo Kernel BPF Config grep -E CONFIG_BPF|CONFIG_KPROBES|CONFIG_TRACEPOINT /boot/config-$(uname -r) 2/dev/null || \ zcat /proc/config.gz 2/dev/null | grep -E CONFIG_BPF|CONFIG_KPROBES|CONFIG_TRACEPOINT || \ echo Cannot find kernel config echo Kernel Headers ls -d /usr/src/kernels/$(uname -r) 2/dev/null || echo kernel-devel missing echo Debugfs mount | grep debugfs || echo debugfs not mounted echo BCC Tools ls /usr/share/bcc/tools/ 2/dev/null | head -10 echo bpftrace which bpftrace bpftrace --version这个脚本的好处是把几个最容易出问题的点一次性暴露出来。在实际操作中我遇到过 debugfs 未挂载的情况其实一条mount -t debugfs none /sys/kernel/debug就能解决但如果没检查到它你会被 bcc 报的Failed to open tracefs错误误导半天。5.2 验证 bcc 工具链execsnoop 的完整流程装好 bcc 后第一个验证工具通常选execsnoop它负责跟踪系统中所有进程的 exec 调用相当于实时监控谁在创建新进程。因为它只依赖 tracepoint不涉及复杂的函数参数解析所以成功率最高。/usr/share/bcc/tools/execsnoop运行后另外开一个终端敲个ls或者sleep 1你会看到类似这样的输出PCOMM PID PPID RET ARGS ls 12845 12567 0 /usr/bin/ls --colorauto sleep 12902 12902 0 /usr/bin/sleep 1如果 execsnoop 能正常运行并捕获 exec 事件说明环境已经 OK 了。这里有个经验如果 execsnoop 报错大概率不是 bcc 本身的问题而是内核 tracepoint 或权限问题。想深入一步可以换个更硬的工具试试biolatency它会统计块设备 IO 延迟分布/usr/share/bcc/tools/biolatency -d 5这个工具在 3.10 内核上需要正确的 tracepoint 支持如果报unknown tracepoint相关错误说明内核缺少 block 子系统的 tracepoint 事件这种情况只能升级内核或者放弃该工具。5.3 验证 bpftrace一行脚本快速验证bpftrace 的验证更简单它的单行命令机制非常适合快速测试环境bpftrace -e BEGIN { printf(hello eBPF\n); exit(); }如果输出hello eBPF说明 bpftrace 的核心加载链路没问题。接下来再试一个实际事件的探测bpftrace -e tracepoint:syscalls:sys_enter_openat { printf(%s opened a file\n, comm); }这个命令会在任何进程调用 openat 时打印一行。如果你能稳定看到输出说明 kprobe/tracepoint 链路、事件回调、printf 输出全部正常整个 bpftrace 环境基本宣告搭建完成。5.4 实操中常遇到的三种失败模式及根源结合我在 CentOS 7 上跑过的几十个案例最常遇到的失败模式有以下三种失败模式一库版本冲突错误提示往往是error while loading shared libraries: libbcc.so.0: cannot open shared object file这个根源是 bcc 用/usr/local/lib作为安装前缀而 CentOS 7 默认的 ldconfig 缓存里没有这个目录。解决办法echo /usr/local/lib /etc/ld.so.conf.d/bcc.conf ldconfig失败模式二内核头文件路径不对bcc 编译或运行时报cannot find kernel version 3.10.0-xxx根源是/lib/modules/$(uname -r)/build软链指向的/usr/src/kernels/$(uname -r)目录不存在。症状很明显但原因可能是你升级过内核之后没重启、或者云镜像没把对应 headers 包装上。解决办法就是确认并补齐 kernel-devel。失败模式三缺少调试符号导致参数解析失败bcc 的许多工具比如trace在分析内核函数参数时需要调试信息如果没装 debuginfo 包工具不会直接拒绝运行而是在输出里一片问号或者报could not determine address of member。这个场景最容易误导人让你以为是自己命令写错了。6. 实战案例用 bpftrace 排查一次线上文件句柄泄漏6.1 问题场景描述某天下午一台 CentOS 7 应用服务器的文件句柄数持续上涨已经接近fs.file-max的限制。用lsof看半天也没看出是哪个进程在持续打开文件因为进程数量实在太多。传统的排查手段在这里效率很低因为你需要反复刷 lsof 做 diff而且抓不住瞬间的 fd 增长。这种场景非常适合用 bpftrace 来看系统调用层面的行为谁调用了 openat、返回值是多少、调用栈来自哪里。6.2 追踪 openat 高频调用先跑一个统计脚本看看哪类进程在疯狂触发 openatbpftrace -e tracepoint:syscalls:sys_enter_openat { [comm] count(); }等待约 30 秒后按下Ctrl-Cbpftrace 会自动输出统计结果。假设你看到某个名为java的进程调用次数远超其他进程那就锁定了目标然后把追踪粒度缩小到这个进程上bpftrace -e tracepoint:syscalls:sys_enter_openat /comm java/ { [comm, filename] count(); }这一步能看到这个 Java 进程到底在频繁打开哪些文件。如果结果清一色指向某个临时文件目录或者某个 socket 文件那基本可以断定是程序逻辑里的连接池或临时文件没有正确释放。6.3 追踪 openat 失败返回值有时候 fd 泄漏不是打开多而是打开失败后不断重试整体表现为 fd 数量持续波动且错误日志激增。这类问题就要追踪返回值bpftrace -e tracepoint:syscalls:sys_exit_openat /comm java args-ret 0/ { printf(open %s failed: %d\n, comm, args-ret); }如果大量失败返回值集中在-ENFILE系统文件句柄已满或-EMFILE进程文件句柄已达上限排查方向就从谁在开文件变成了为什么到了上限。后面再结合cat /proc/pid/limits看进程的软限制就知道是 nproc 配太低还是真的泄漏过头了。这个案例可能看起来跟环境搭建有些偏离但恰恰是我要强调的环境搭好的意义不是看它跑通 hello world而是让你在线上故障发生时有拿得出手的工具。bpftrace 的价值就在于把以前需要反复抓包、不停翻日志的事变成一条命令直接看到根因。7. 常见问题与排查技巧实录7.1 速查表报错信息与解决办法报错信息根本原因解决动作Failed to open tracefsdebugfs/tracefs 未挂载mount -t tracefs none /sys/kernel/tracingcannot find kernel versionkernel-devel 缺失或版本不匹配重装对应内核版本的 kernel-develerror while loading shared librariesldconfig 未包含安装路径写 ld.so.conf 并执行 ldconfigUnsupported LLVM versionLLVM 版本过老安装新版 LLVM 或在容器内编译unknown tracepoint内核不支持该 tracepoint换用 kprobe 或升级内核Kernel not compiled with BPF support内核未开启 BPF 配置重新编译内核或换内核Permission denied权限不足或 SELinux 拦截确认 root/SELinux 放行策略libbpf not found缺少 libbpf 库安装 libbpf-devel 或源码编译安装7.2 独门排查心得先看 dmesg 再查配置我在 CentOS 7 上排查 bcc 相关报错时有一个习惯——先看dmesg | tail。eBPF 程序的加载失败通常会留下内核日志比如bpf: prog type mis-match或者failed to load bpf program这些日志比用户态的报错信息更接近真相。比如有一次 bcc 工具报Invalid argument用户态日志完全看不出原因我翻了 dmesg 才发现是内核拒绝了一个非法的 map 类型定义。这种问题如果一上来就怀疑是环境没装好往往绕一大圈。另一个心得是CentOS 7 上做 eBPF 开发尽量把工具链装在独立的目录或容器中不要把/usr/local/bin弄得太乱。因为 eBPF 工具链涉及很多动态链接库一旦多个版本混在一起错误会变得非常难以排查。7.3 版本管理技巧CentOS 7 仓库里同时存在多套 eBPF 相关工具已经很常见尤其当你又用 yum 装了旧版、又用源码编译了新版时两个版本的 bcc 可能同时存在于系统中互相覆盖头文件和库文件。建议养成一个习惯源码安装时明确指定前缀比如-DCMAKE_INSTALL_PREFIX/opt/bcc并且把所有 eBPF 工具的二进制路径统一管理。要让某个工具从/opt/bcc加载而不是系统路径可以设置环境变量export PATH/opt/bcc/bin:$PATH export LD_LIBRARY_PATH/opt/bcc/lib:$LD_LIBRARY_PATH export PYTHONPATH/opt/bcc/lib/python3.6/site-packages:$PYTHONPATH这套环境变量写进专门的 profile 脚本里需要时再source避免污染全局环境。特别是在你看不清当前到底用的是哪套 bcc 的时候检查这组变量的内容能快速定位。8. 扩展与进阶从环境搭建走向实际落地8.1 在 CentOS 7 上继续使用 bcc 的局限提醒环境搭建成功之后我还是要泼一盆冷水CentOS 7 的 3.10 内核毕竟太老新版本 bcc 和 bpftrace 的很多特性都无法使用。你已经了解了 3.10 内核的限制——缺乏 BPF-to-BPF 调用、helper 函数少、锁语义弱、map 类型不全。这些限制会导致你辛辛苦苦写出来的复杂脚本在新版工具链上跑不动或者结果和预期不一致。如果项目的长期目标是系统性使用 eBPF 做可观测性建设还是尽早规划迁移到支持 4.18 内核的操作系统版本。但作为存量环境治理CentOS 7 上搭一套能用的 bcc 和 bpftrace 依然有巨大的日常运维价值。8.2 结合 systemd 管理 eBPF 采集任务实际落地时你不太可能一直开着终端跑 bpftrace。我建议把常用脚本封装成 systemd service用日志文件或直接输出到标准输出的方式持久化采集结果。下面给一个最小化的 service 模板[Unit] Descriptionbpftrace opensnoop collector Afternetwork.target [Service] ExecStart/usr/local/bin/bpftrace /opt/ebpf/scripts/opensnoop.bt Restarton-failure RestartSec5 StandardOutputappend:/var/log/bpftrace-opensnoop.log StandardErrorappend:/var/log/bpftrace-opensnoop.log [Install] WantedBymulti-user.target把脚本放到/opt/ebpf/scripts/然后systemctl enable opensnoop.service即可开机自启。这里需要注意的是 bpftrace 脚本的输出是带格式的纯文本追加到日志文件之后按行解析不是什么难事但如果想对接后续的分析系统建议输出到 JSON 格式。8.3 云原生环境下的替代工具如果你的业务逐渐往容器化迁移CentOS 7 上这套 eBPF 工具链的适用空间会越来越窄。业界有一些基于 eBPF 的可观测性开源项目比如 Cilium 的 Hubble 或者 Pixie它们通常对内核版本要求更高大部分都要求 4.19 以上。如果你所在的环境跑的是新版 Kubernetes 和云原生技术栈与其在 CentOS 7 上强行维护一套老工具链不如直接在自己的开发环境或者新的操作系统上搭一套标准的 eBPF 观测平台。8.4 下一步学习路线建议环境搭好只是起点要把 eBPF 工具真正用起来我的建议是按这个顺序推进先用execsnoop、opensnoop、biolatency这些现成工具解决日常问题逐步熟悉输出字段的含义。再用 bpftrace 的单行命令尝试组合多个探针理解事件过滤、聚合、时间戳这些基础语法。然后尝试阅读 bcc 提供的 Python 工具源码了解 BPF 程序是怎么从 C 代码被编译和加载的。最后才是自己写工具这时候你会用到 bcc 底层的 BPF C 编程接口也能领会到内核 3.10 的限制到底卡在哪。我个人在实际操作中最大的体会是不要急于从写程序开始先把现成工具用透。bcc 自带的 80 多个工具几乎覆盖了 CPU、内存、网络、IO 的所有高频排查场景先把它们逐个摸熟你对系统的理解深度会上一个台阶。这些工具在 CentOS 7 上虽然受内核版本限制但覆盖日常问题排查完全足够。最后再分享一个实用小技巧把环境搭建过程写成一键脚本保存下来。别觉得麻烦eBPF 工具链的环境非常容易因内核小版本升级而失效重建环境是常有的事。我自己的习惯是维护一个setup_ebpf_centos7.sh把本文提到所有检查和安装步骤都固化进去遇到新机器先跑一遍省得每次从零开始试错。这套流程我已经在十几台 CentOS 7 机器上验证过踏实得很。