直接上手编写bpftrace脚本并不困难，但如果不深入理解探针类型和变量的作用域，脚本很可能无法正常运行，或者输出结果一片空白，让人困惑不已。
为什么执行bpftrace命令没有反应？
例如，当你满怀期待地输入 bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("hit\n"); }' 后，终端却毫无动静。这通常不是脚本语法错误，而是运行环境未正确配置所致。
首要原因往往是权限不足，或者内核未启用对应的追踪点。并非所有系统调用的tracepoint都默认可用，尤其是在一些较旧或经过特定配置的内核上。
- 首先确认追踪点是否存在：执行命令
ls /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/。如果该目录不存在，基本可以断定内核在编译时未包含此追踪点。 - 必须使用root权限：bpftrace需要访问内核追踪接口，务必记得加上
sudo。 - 检查debugfs文件系统：某些Linux发行版（如RHEL/CentOS 8+）默认不挂载debugfs，需要手动执行：
sudo mount -t debugfs none /sys/kernel/debug。 - 缩小监控范围：如果只想观察特定进程（例如
curl），添加过滤条件会更加可靠：/comm == "curl"/ { printf("open by %s\n", comm); }。
kprobe和tracepoint，究竟该选择哪一个？
同样是监控读操作，kprobe:vfs_read 和 tracepoint:syscalls:sys_enter_read 看起来相似，实则存在显著差异。前者是动态插桩，后者是内核预埋的静态追踪点，在实际观测中行为表现明显不同：
- 覆盖范围：
kprobe:vfs_read能够捕获内核态中所有的read路径（包括文件、管道、套接字），但可能被编译器的内联优化绕过；而tracepoint:syscalls:sys_enter_read只捕获从用户态发起的read()系统调用入口，虽然稳定，但覆盖范围相对较窄。 - 参数访问方式：使用
kprobe时，通过arg0–argN来获取寄存器中的参数；使用tracepoint时，则必须通过结构体字段访问，例如args->fd、args->count。 - 性能开销：通常
tracepoint的开销更低。kprobe如果挂载在高频调用的内核函数上（例如schedule），很容易触发内核的采样限流机制（受perf_event_max_sample_rate参数控制）。
如何安全地测量函数执行耗时？
想要测量系统调用的耗时，常见的思路是使用map记录开始时间。但这里存在一个陷阱：如果不进行配对清理和条件判断，很容易因为线程复用或异常退出，导致map中的键不断堆积，甚至时间戳被意外覆盖。
- 防止时间戳覆盖：在记录开始时间之前，必须检查该键是否已存在：
kprobe:sys_write /!@start[tid]/ { @start[tid] = nsecs; }。否则，同一个线程的连续调用会覆盖掉前一次的时间戳。 - 防止内存泄漏：在返回探针中，要附带非空判断再进行清理：
kretprobe:sys_write /@start[tid]/ { @dur = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); }。 - 键的选择策略：不要使用
pid作为map的key。在多线程进程中，不同线程的tid不同，但共享同一个pid，使用pid会导致统计结果完全失真。 - 超时兜底机制：添加一行
interval:s:10 { exit(); }是个好习惯，能够防止脚本意外卡死。
监控内存分配，为什么输出结果全是0？
尝试使用 kprobe:__kmalloc 监控内存分配大小，却发现输出的 arg0 值全是0？这很可能不是你脚本的问题，而是不同内核版本间的“暗坑”。
__kmalloc 函数的参数顺序在不同内核版本中可能发生变化。在5.10+版本的内核里，arg0 可能对应分配大小，但在4.19版本的内核里，arg0 对应的可能是 gfp_flags。硬编码参数位置极易导致脚本失效。
- 优先使用tracepoint：如果内核支持，优先使用
tracepoint:kmalloc:kmalloc，它提供了标准化的字段，例如args->bytes_alloc。 - 查证内核符号：如果必须使用kprobe，务必查证当前内核的符号定义：
sudo cat /proc/kallsyms | grep __kmalloc，再结合objdump -t /lib/modules/$(uname -r)/build/vmlinux | grep __kmalloc来确认参数布局。 - 注意观测覆盖度：有些内存分配路径（例如SLAB分配器内部）不会经过
__kmalloc，可能需要配合tracepoint:kmalloc:kmalloc_node等追踪点来补全观测。
归根结底，bpftrace真正的难点，不在于写出一行脚本，而在于搞清楚你看到的每一个 arg0、args->xxx、@map，在当前运行的内核版本里，究竟对应着什么内存布局和生命周期。不事先查好 /sys/kernel/debug/tracing/events/ 和 /proc/kallsyms 就动手编写，无异于蒙着眼睛调参。掌握这些内核动态追踪技巧，是进行Linux性能分析和深度监控的关键。
