容器监控依赖宿主机内核与运行时环境：需内核≥5.4（推荐5.15+），启用config_bpf等选项，挂载debugfs，root权限执行工具；通过cgroup、comm等过滤精准定位容器；优先选用tracepoint探针，辅以kprobe/uprobe；调试时注意权限、tracepoint存在性及事件触发时机。
容器本身不直接“支持”bpf监控，关键在于宿主机内核和运行时环境是否就绪。bpf程序运行在宿主机内核空间，天然能观测到容器进程产生的系统调用、网络事件和文件操作——只要内核版本够新、权限正确、探针可用。
确认宿主机内核与基础配置
这是前提，缺一不可：
- 内核版本 ≥ 5.4（推荐 5.15+），确保启用
CONFIG_BPF=y、CONFIG_BPF_SYSCALL=y、CONFIG_TRACEPOINTS=y、CONFIG_DEBUG_FS=y - 挂载 debugfs：运行
sudo mount -t debugfs none /sys/kernel/debug（部分发行版默认未挂载） - 检查 tracepoint 是否可用：例如
ls /sys/kernel/debug/tracing/events/syscalls/sys_enter_connect/，存在即说明该系统调用追踪点已编译进内核 - 必须使用 root 权限执行 bpftrace 或 bcc 工具，普通用户无权访问内核 tracing 接口
利用容器命名空间精准过滤
BPF 可自动感知 cgroup 和 pid namespace，这是实现“按容器监控”的核心机制：
- 通过
cgroup过滤：Docker 容器默认属于/sys/fs/cgroup/pids/docker/下的子目录，bpftrace 中可用pid.cgroup字段匹配，例如：bpftrace -e 'tracepoint:syscalls:sys_enter_open /pid.cgroup =~ /docker\// { printf("%s %s ", comm, args->filename) }' - 通过
comm或pid辅助定位：若容器内主进程名明确（如nginx、redis-server），可加/comm == "nginx"/快速聚焦 - 避免仅用
pid做键：多线程容器中不同线程 tid 不同，应优先用tid或组合pid, comm防止统计失真
选择合适探针类型适配容器场景
不同探针适用不同监控目标，稳定性与覆盖范围需权衡：
-
tracepoint（推荐首选）：如
tracepoint:syscalls:sys_enter_connect或tracepoint:sock:inet_sock_set_state，开销极低、ABI 稳定，适合长期运行的网络连接监控 -
kprobe/kretprobe：如
kprobe:vfs_read，能捕获更底层的内核路径，但受内联优化影响，不同内核版本行为可能变化 - uprobe/uretprobe：用于跟踪容器内特定二进制（如 nginx、java）的用户态函数，需容器内有调试符号或 USDT 探针，适合深度应用层分析
验证与调试常见卡点
脚本没输出？多半是以下原因：
- 权限不足 → 用
sudo重试 - tracepoint 不存在 → 查
/sys/kernel/debug/tracing/events/路径，或换用更通用的kprobe - 容器刚启动，事件尚未触发 → 先在容器内手动执行一次操作（如
curl http://localhost），再运行脚本 - 输出被缓冲 → 加
fflush()或用printf后立即system("sync")（不常用），更稳妥是加-f参数让 bpftrace 实时 flush
