bpftrace 通过高度抽象的封装来使用 eBPF，大多数功能只需要寥寥几笔就可以运行起来，可以很快让我们搞清楚 eBPF 是什么样的，而暂时不关心 eBPF 复杂的内部机理。由于 bpftrace 深受 AWK 和 c 的影响，bpftrace 使用起来于 AWK 非常相似，那些内核 hook 注入点几乎可以按普通字符串匹配来理解，非常容易上手。

前面我们介绍了如何部署bpftrace工具，并且介绍了如何运行bpftrace脚本，这篇文章将介绍bpftrace脚本的语法。

bpftrace脚本语法

脚本格式

• bpftrace脚本基本格式如下：

• bpftrace语法深受AWK的影响，{前的部分相当于AWK的condition，{}中的部分相当于AWK的action。只不过bpftrace执行actions的条件是触发probe名称指定的事件。
• probe是探针的名称，我们知道内核中函数非常多，为了方便，内核对probe做了namespace处理，这里的probe通常是以冒号:分割的一组名称，比如:

• 显然，最后一部分表示的是函数名称，其他部分则是namespace，这样做有两点好处：①便于查找函数；②便于定位不同模块中的同名函数。

• bpftrace除了可以监听指定的probe事件，还有两个特殊的probe：BEGIN，END。这与AWK类似，它们分别在bpftrace程序执行开始、结束时，无条件的执行一些操作，比如完成一些初始化、清理工作等。

• filter是可选的，有时候我们只需要探测特定条件下函数的行为，比如参数为某个值的时候，就可以用到filter，这需要了解bpftrace如何访问probe的变量，我们稍晚再说。

prbbe参数

ebpf支持的probe：hardware，iter，kfunc，kprobe，software，tracepoint，uprobe。

• ebpf提供了内核和应用的动态trace，分别用于探测函数入口处和函数返回(ret)处的信息。

• ①面向内核的 kprobe/kretprobe，k = kernel
• ②面向应用的 uprobe/uretprobe，u = user land

• kprobe/kretprobe 可以探测内核大部分函数，出于安全考虑，有部分内核函数不允许安装探针，另外也可以配合 offset 探测函数中任意位置的信息。

• uprobe/uretprobe 则可以为应用的任意函数安装探针。

• 动态 trace 技术依赖内核和应用的符号表，对于那些 inline 或者 static 函数则无法直接安装探针，需要自行通过 offset 实现。可以借助 nm 或者 strings 指令查看应用的符号表。

• 这两种动态 trace 技术的原理与 GDB 类似，当对某段代码安装探针，内核会将目标位置指令复制一份，并替换为 int3 中断, 执行流跳转到用户指定的探针 handler，再执行备份的指令，如果此时也指定了 ret 探针，也会被执行，最后再跳转回原来的指令序列。

• kprobe 和 uprobe 可以通过 arg0、arg1... ... 访问所有参数；kretprobe 和 uretprobe 通过 retval 访问函数的返回值。除了基本类型：char、int 等，字符串需通过 str() 函数才能访问。

• 静态 trace，所谓 “静态” 是指探针的位置、名称都是在代码中硬编码的，编译时就确定了。静态 trace 的实现原理类似 callback，当被激活时执行，关闭时不执行，性能比动态 trace 高一些。

• ① 内核中的静态trace：tracepoint
• ② 应用中的静态trace: usdt = Userland Statically Defined Tracing

• 静态 trace 已经在内核和应用中饱含了探针参数信息，可以直接通过 args->参数名 访问函数参数。tracepoint 的 参数 format 信息可以通过 bpftrace -v probe 查看：

• 或者访问debugfs：

内置变量

无论 Dynamic tracing 或者 Static tracing，它们的目的都是监听特定函数调用事件，这些函数即可以在内核中，也可以在用户态的应用或者 lib 中。获知这些函数调用时的参数、返回值就已经实现了开发者大半目标。除此之外，bpfstrace 还内置了一些变量，用户访获得探测对象自身信息。这些变量在 bpftrace 中直接访问即可，如下：

• pid / tid：Bpftrace或者说eBPF工作在内核，因此这些变量都与内核中进程表示有关。先说tid，内核中线程与进程没做作明确区分，它们都是相同的调度对象task_sruct。tid是thread id的缩写，由于历史原因，在task中的成员是task_sruct.pid。所以对于Linux内核，线程=轻量级进程。而pid实际上指的是内核中进程组，由task中的task_sruct.tgid成员表示。也就是说，进程=线程组。
• uid / gid：执行函数的用户ID、组ID。
• nsecs：时间戳，纳秒。
• elapsed：ebpfs 启动后的纳秒数。
• numaid：NUMA = Non-Uniform Memory Access，与多核 CPU 的内存访问相关。
• cpu：当前 cpu 编号，从 0 开始。
• comm：进程名称，通常为进程可执行文件名。
• kstack：内核栈。
• ustack: 用户栈。
• arg0, arg1, ..., argN：函数参数。
• sarg0, sarg1, ..., sargN：函数参数(栈中)。
• retval：返回值。
• func：函数名，可以在可执行文件的符号表中这个函数名。
• probe：探针的完整名称，也就是 bpftrace 中 形如 'kprobe:do_nanosleep'
• curtask：当前 task struct。
• rand：一个无符号 32 位随机数。
• cgroup：当前进程的 Cgroup，内核资源组，类似 namespace，docker 等虚拟化技术即基于内核提供的这一基础设施。
• cpid：子进程 pid，bpftrace 允许通过 -c 指定一个 cmd 运行，然后在该进程上安装 probe。
• 2, ..., #：bpftrace 程序自身的位置参数

全局变量

• 全局变量@name，所谓的全局变量：①对所有的probe actions可见，②bpftrace生命周期内可见。

• bpftrace支持两种变量形式：

• ① 简单变量，@name = value；简单变量就是单纯的变量名和值，很容易理解，你可以在脚本中创建任意数量的简单变量。
• ② Map，@name[key] = value；Map非常接近Python中的Dict，或者C中的数组，但数组索引可以是数字、字符串等。例如借助内置变量tid可以为每个线程记录独立的数值。

• 测试例子：

• 运行效果：

临时变量

$name， 只在当前action中有效，超出action的{}不具备记忆能力。

内置函数

bpftrace无法自定义函数，但提供了约36个内置函数，可以在bpftrace脚本的任意位置调用它们。完整的列表可以参考官方文档：(https://github.com/iovisor/bpftrace/blob/master/docs/reference_guide.md)。

bpftrace的函数非常有限，原因是bpftrace脚本会编译为bytecode，交由内核中的eBPF VM执行，出于安全和效率考虑，eBPF VM不能允许用户执行任意函数，仅允许执行限定的函数，或缺有限的数据。

• %S 秒，00-60;
• %M 分钟，00-59；
• %I 小时，01-12；%H 小时，00-23；
• %d 每月的第几天，01-31；
• %w 星期，0-6, 0 指 星期日；
• %m 月份，01-12；
• %y 年份，00-99；%Y 完整的年份；

「注意：格式化字符结尾不要忘记换行，否则不会自动清空缓冲区到标准输出，就看不到输出了。」

• mode，stack 模式，可选 bpftrace、perf；
• limit，一个整数，获取 stack 的最大深度；

控制语句

bpftrace 也提供了常见的流程控制语句：① 条件语句 ② 循环语句

• bpftrace的条件语句用法与C语言完全一样：

• 当满足条件时执行 A 处语句，否则执行 B 处语句。当然也可能有以下更简单的形式，没有 else 部分，条件满足时执行 A 处语句，然后执行 B 处语句，否则跳过 A 处语句：

• 多个 if-else 也可能连接在一起：

• 测试样例：

• 测试样例结果：

• bpftrace 支持一种最常见的循环形式：

• 测试样例：

• 测试样例结果：