eBPF 与 bpftrace更深入地观测内核实验环境Ubuntu 24.04 / 内核 6.8.0-106-generic / Cgroup v2 / 华为云 FlexusX 8C16G本文所有命令输出均来自真实实验机可直接复现。bpftrace 版本 v0.20.2内核自带 BTF。一、引子ftrace 还不够聪明的时候上一篇 ftrace 能看调用链、能插桩内核函数但它有个天花板所有逻辑都在内核态记录聚合、过滤、统计得事后在用户态做。如果你想问这个容器过去 10 秒里每次read的延时分布是多少“哪个 cgroup 的openat最多”“把几十万次事件按进程聚合出一张直方图”——ftrace 做不到在内核里就地算好再回传。这时候需要eBPF一套运行在内核态、带 JIT、有 Verifier 安全保障的虚拟机让你写一小段 C 逻辑挂到 kprobe / tracepoint / syscalls 上在内核里直接聚合数据进 map用户态只来取结果。再配上bpftrace类 awk 的一行脚本语言无需写 C、无需编译就能把上面的问题一行搞定。二、eBPF 原理简述2.1 它是怎么跑起来的写程序用 CBCC或 bpftrace 脚本描述探针触发时做什么。编译 VerifierLLVM 把 eBPF 字节码编译内核Verifier在加载前做严格校验——无越界、无死循环、只访问合法内存、调用受限 helper——不通过就拒绝加载因此 eBPF 不会把内核搞崩。JIT校验通过后eBPF 字节码被JIT 编译为原生机器码执行开销接近普通内核代码。MapeBPF 程序与用户态通过Map内核里的键值存储哈希表/数组/直方图等交换数据。探针高频写 map用户态低频读 map——这就是内核态聚合的关键。挂载点eBPF 程序可挂到kprobe / kretprobe动态同 ftrace 的 kprobe、tracepoint静态、perf event、XDP网络、cgroup等。2.2 它比 ftrace 强在哪维度ftraceeBPF聚合只能全量记录事后分析内核态就地聚合hist/sum/count过滤函数级 / 简单谓词任意 C 表达式谓词comm、pid、算数数据结构文本 trace 缓冲Map直方图、统计、栈表编程能力无配置式图灵完备可计算延时、关联事件安全内核内置稳Verifier 沙箱保障典型用途看调用链/耗时统计分布、按 cgroup 聚合、网络观测一句话ftrace 回答发生了什么调用eBPF 回答这些调用按 X 维度聚合后长什么样。三、bpftrace 单行实战bpftrace 语法probe { action }变量name是全局 Map退出时自动打印。下面每个都真跑过。3.1 系统调用次数 Top谁最忙rootecs-a8bb-0002:~# bpftrace -e tracepoint:raw_syscalls:sys_enter { [comm] count(); }Attaching1probe... [wpa_supplicant]:1[cron]:7[timeout]:9[sh]:109[irqbalance]:102[multipathd]:97[pluginctl]:148[bpftrace]:304[remotectl]:348[containerd]:929[uniagentd]:3848一眼看出本机系统调用最密集的是uniagentd云监控 agent3848 次、containerd929 次。count()在 Map 里累加退出时按值排序打印——这正是 eBPF 内核态聚合的缩影。3.2 跟踪 execveexecsnoop 效果execsnoop是经典工具谁在偷偷起进程可能是攻击、cron、 Hook。bpftrace 一行复刻rootecs-a8bb-0002:~# bpftrace -e tracepoint:syscalls:sys_enter_execve { printf(%-6d %-12s %s\n, pid, comm, str(args-filename)); }Attaching1probe...49032bash/usr/bin/ls49033bash/usr/bin/whoami49034bash/usr/bin/sleep49035bash/usr/bin/grep49036bash/usr/bin/headargs-filename是 tracepoint 的上下文字段str()把它从内核指针解成字符串。跑ls/whoami时被实时抓到——排查未知进程从哪来非常直接。3.3 I/O 延时直方图本来想做块 I/O 延时直方图block:block_rq_issue/block_rq_complete算差值。但本环境块设备走 virtio 半虚拟化实测block:*tracepoint 完全不触发已用count()验证block_rq_complete恒为 0。这是云环境的真实限制按替代方案原则我换成VFS read 延时直方图——技法完全一样入口记时间戳、出口算差值、丢进hist()且必然可复现rootecs-a8bb-0002:~# bpftrace -e tracepoint:syscalls:sys_enter_read{start[pid]nsecs;}tracepoint:syscalls:sys_exit_read /start[pid]/{ushist((nsecs - start[pid])/1000);delete(start[pid]);} us:[0]190|[1]210||[2,4)194|[4,8)20|[8,16)23|[16,32)28|[32,64)15|[128,256)11|[256,512)5|[512, 1K)1|[1K, 2K)8|[2K, 4K)1|[4K, 8K)3|解读绝大多数read在0~4µs内完成命中页缓存极快右侧长尾ms 级是首次读/页错误/落到磁盘的那几次。这正是直方图的价值——一眼看出分布而非只看平均值。同样的hist() issue/complete 时间戳差值技法可直接套到块 I/O / 网络 / 任意两点间延时。3.4 跟踪容器内进程按 comm 过滤要观测某个容器在宿主机上用 eBPF 最方便的是按进程名comm过滤——容器的业务进程通常 comm 固定且不同于宿主。我编译了一个只做open/read的iohog放容器里跑commiohog宿主机上按 comm 过滤统计它的系统调用rootecs-a8bb-0002:~# docker run -d -v /root/iohog:/iohog --name bpf-ct alpine /iohogrootecs-a8bb-0002:~# bpftrace -e tracepoint:syscalls:sys_enter_openat /commiohog/{opencount();}tracepoint:syscalls:sys_enter_read /commiohog/{readcount();} open:5787read:115987 秒内容器内iohog进程触发了 5787 次openat、11598 次read——完全隔离于宿主其他进程。如果把探针换成sys_enter_openat打印str(args-filename)就能逐条列出容器打开了哪些文件换成sys_enter_accept4 /commnginx/就是经典的nginx 容器连接接受观测。这就是生产里看清一个容器在干啥的标准手法。关于 cgroup 过滤更精确的做法是按 cgroup id 过滤bpftrace 有cgroup内建函数返回当前任务的 cgroup id。本机 cgroup v2 目录无cgroup.id文件但 cgroup id 等于该目录的 inode 号stat -c %i /sys/fs/cgroup/.../docker-id.scope可取用/ cgroup id /即可精准锁定某容器。本实验用 comm 过滤已能干净隔离故采用之。四、BCC 与 bpftrace怎么选bpftraceBCC形态单行/短脚本类 awkPython C完整项目上手极快改一行就能跑需写 C 程序 Python 胶水能力覆盖 90% 观测场景任意复杂逻辑、自定义 Map、USDT、网络/XDP依赖少bpftrace BTF多LLVM、Python、头文件典型临时排障、快速验证常驻监控、定制化工具、产品化实践建议临时排查、验证假设用bpftrace 一行脚本5 秒出结果。要做成常驻监控 / 复杂关联如按 cgroup 聚合所有容器的 TCP 重传用BCC写工具或基于 eBPF 的 Prometheus exporter如cilium/ebpf、bcc的TC/socket类。容器场景bpftrace 在宿主机跑配合comm/cgroup/pid过滤观测任意容器无需进容器。五、排查思路eBPF 在排障里的位置先问聚合后长啥样延时分布hist、Top Ncount、速率interval这类问题首选 eBPF/bpftrace。容器观测范式宿主机起 bpftrace → 用comm/cgroup/pid过滤器圈定目标容器 → 选 tracepointsyscalls/sched/block 等或 kprobe → 用 Map 聚合。与 perf/ftrace 联动perf 定位CPU 热点函数 → ftrace 看单次调用链与耗时 → eBPF 看海量事件的分布与按维度聚合。三者构成完整的核观测栈。注意环境限制如本机block:*tracepoint 不触发半虚拟化存储、部分 tracepoint 在容器视角的参数需str()解引用。遇到不触发就换同类探针如块 I/O 改 VFS read别卡死。六、小结与思考题小结eBPF 是运行在内核态、经 Verifier 校验、JIT 执行的虚拟机通过 Map 在内核态聚合、用户态取数比 ftrace 更适合统计分布与多维过滤。bpftrace 用一行脚本即可完成系统调用 Top、execsnoop、延时直方图、按 comm 过滤观测容器等任务。本环境实测block:*不触发以 VFS read 延时直方图替代技法一致。BCC 适合复杂/常驻场景bpftrace 适合临时排障。思考题eBPF 的 Verifier 为什么要禁止无界循环如果允许会有什么后果上面 read 延时直方图里为什么大部分在 0~4µs却有 ms 级长尾提示页缓存命中 vs 页错误/磁盘要统计每个 cgroup 的 TCP 重传次数bpftrace 该挂哪个探针、用什么 Map为什么用comm过滤容器不如用cgroup过滤精确什么情况下 comm 过滤会误伤或漏掉block:block_rq_complete在本机恒为 0这能说明磁盘没有 I/O吗为什么内核调试工具专题完。perf / ftrace / eBPF 三件套分别对应热点占比 / 调用链耗时 / 内核态聚合三层观测能力配合使用可覆盖绝大多数内核态排障场景。