前言

eBPF 彻底改变了 Linux 内核中的可观察性。在我之前的系列文章中，我介绍了eBPF 生态系统的基本构建模块，简要介绍了XDP，并展示了它与 eBPF 基础设施如何密切合作，以便在网络堆栈中引入一个快速处理的数据路径。

然而，eBPF 并不只是用在内核空间跟踪。如果我们可以在生产环境中运行的应用程序上也能享受 eBPF 驱动的跟踪的，这是不是很好呢?

这就是 uprobes 发挥作用的地方。可以将它们看作是一种 kprobes ，它加载到了用户空间跟踪点而不是内核符号。多语言运行时、数据库系统和其他软件栈都包含了可以被 BCC 工具使用的钩子。具体地说，ustat 工具收集了大量有用事件，如垃圾收集事件、对象创建统计信息、方法调用等。

但是“官方”语言运行时的版本，如 Node.js 和 Python，不带 DTrace 支持，这就需要你必须从源代码构建，将 –with-dtrace_ 标志传递给编译器。这不是说必须一定要本机编译语言。只要符号表可用，就可以对二进制文本段中出现的任何符号应用动态跟踪。在运行的二进制文件上检测 Go 或 Rust stdlib 函数调用就是通过这种方式完成的。

可用于检测分析应用程序的 eBPF 技术

跟踪用户空间进程有多种方法：

• 静态声明的 USDT

• 动态声明的 USDT

• 使用 uprobes 进行动态跟踪

静态声明的 USDT

USDT (Userland Statically Defined Tracing) 的做法是直接在用户代码中嵌入探测。该技术的起源可以追溯到 Solaris/BSD DTrace 时代，包括使用 DTRACE_PROBE() 宏在重要代码位置上声明跟踪点。与常规符号不同，USDT 钩子保证即使代码被重构也能保持稳定。下图描述了在用户代码中声明 USDT 跟踪点的过程，直到在内核中执行为止。

开发人员可以先通过 DTRACE_PROBE 和 DTRACE_PROBE1 宏来在需要的代码块中植入跟踪点。两个宏都接受两个强制参数，如提供者/探测名称，后面跟着你希望从跟踪点查询的任何值。编译器将把USDT 跟踪点塞进目标二进制文件 ELF 段中 。编译器和跟踪工具之间规定了 USDT 元数据所在的位置必须存在 .note.stapstd 段。

USDT 跟踪工具检查 ELF 段，并在被转为 int3 中断的跟踪点位置上放置一个断点。每当在跟踪点的标记处执行时，就会触发中断处理程序，并在内核中调用与 uprobe 关联的程序来处理事件并将它们广播到用户空间，执行映射聚合等等。

【文章福利】小编推荐自己的Linux内核技术交流群:【891587639】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！（含视频教程、电子书、实战项目及代码)    

动态声明的 USDT

由于 USDT 被加入静态生成的 ELF 段，所以USDT不能运行在解释性语言或基于 jit 的语言上的软件上。幸运的是，可以通过 libstapsdt 在运行时中定义跟踪点。它生成一个带有 USDT 信息的小型共享对象，该共享对象被映射到进程的地址空间，因此跟踪工具可以附加到目标跟踪点上。在许多语言中都有 libstapsdt 。要了解如何在 Node.js 中安装 USDT 探测可以参考这个 example。

使用 uprobes 进行动态跟踪

这种类型的跟踪机制不需要目标进程提供任何额外的功能，只需要它的符号表是可访问的。这是最通用和最强大的插装方法，因为它允许在任意指令上注入断点，甚至不需要重启运行的进程。

跟踪例子

After a brief theoretical introduction, let’s see some concrete examples on how to instrument real-world apps crafted in diverse languages. 在简单的理论介绍之后，我们来看一些具体的例子，看看如何用跟踪分析不同的语言的应用程序。

C 语言

Redis is a popular key-value data structures server built in C. Taking a sneak peek into the Redis symbol table reveals a vast number of functions that are candidates for capturing via uprobes. Redis 是一个用 C 语言开发的非常流行的 k-v 数据库服务，仔细看一下 Redis 符号表，就会发现大量可以通过 uprobes 捕获的函数。

有一个有趣的 createStringObject 函数，Redis 内部利用它来分配围绕 robj 结构建模的字符串。Redis 命令通过 createStringObject 调用来执行。通过跟踪这个函数，我们可以监视发送到 Redis 服务器的任何命令。为此，我将使用 BCC 工具包中的 trace 功能。

以上是在 Redis CLI 客户端执行 “set octi fest” 和 “get octi” 的输出结果。

Java语言

现代 JVM 版本自带对 USDT 的内置支持。所有探针都是用 libjvm 共享对象带来的。我们可以在 ELF 段中到可用的追踪点。

为了捕获所有的类加载事件，我们可以使用以下命令：

类似的，我们可以观察线程创建事件：

$ /usr/share/bcc/tools/trace'u:/usr/lib/jvm/jdk-11-oracle/lib/server/libjvm.so:thread__start "%s", arg1'

当扩展探测通过 -XX:+ExtendedDTraceProbes 属性启用时，uflow 工具 能够实时跟踪和绘制所有方法执行的图形。

但是，就扩展探针所产生的开销而言，这往往非常昂贵，因此不适合在生产环境中调试。

Go语言

我将用一个 Go 中的例子来结束跟踪技术的演示。因为 Go 是一种原生编译语言，所以使用跟踪工具将 uprobe 程序附加到目标符号上是尝试性的。你可以用下面这个简单的代码片段自己尝试一下:

除了打印这里的 " Hi “字符串，我们在参数列中看到打印了一些随机的垃圾信息。这在一定程度上是由于 trace 不能处理 Println 可变参数造成的，但也可能和 ABI 调用约定的参数使用的错误假设有关。在 C/C++ 中，传递参数的首选方式是在常规寄存器中，而 Go 在堆栈上传递参数。

由于我们不能依赖 trace 工具来来演示如何跟踪 Go 代码，所以我将构建一个简单的工具来跟踪由 http.Get 函数发出的所有 HTTP GET 请求。你可以很容易地修改它来捕获其他 HTTP 请求动词，大家可以参与贡献。完整的源代码可以在这个 repo 中找到。

我不会详细介绍 uprobe 附加/加载过程，因为我们正在使用 Go 绑定 来 帮 libbcc 完成复杂的工作。让我们分析一下实际的 uprobe 程序。

在必需的 include 语句之后，有宏的定义，该宏通过偏移量处理的方式负责从堆栈中获取参数。

接下来，我们声明数据结构用于封装通过 reqs map流传递的事件。map 用 BPF_PERF_OUTPUT 宏来定义。我们程序的核心是__uprobe_http_get 函数。当 http.Get 被调用，则在内核空间中触发前面的函数。我们知道 HTTP . get 只有一个参数，表示 HTTP 请求被发送到的 URL。C 语言和 Go 语言的另一个区别是字符串内存中布局处理。

C 字符串是以空结束的序列串，而 Go 用 2 个值来描述：指向内存缓冲区的指针和字符串长度。这就解释了我们需要对 bpf_probe_read 进行两个调用——一个用于读取字符串，另一个用于提取字符串的长度。

稍后在用户空间中，URL 将从字节片裁剪到相应的长度。作为一个附加说明，我想提到的是，该工具的草案版本能够通过注入 uretprobe 来检测出每个 HTTP GET 请求的延迟。然而，每次 Go 运行时决定收缩/增长堆栈就会有一个灾难性的影响，因为 uretprobes 补丁的返回地址是在堆栈上的跳转函数，它在 eBPF VM 的上下文中执行。在退出 uretprobe 函数时，指令指针被恢复到原始的返回地址，该地址可能指向一个无效的位置，打乱堆栈并导致进程崩溃。有一些建议来解决这个问题。

结论

我们的 eBPF 之旅已经走到了终点。在这最后一篇文章中，我们介绍了一些 eBPF 特性用于用户空间进程插装 。通过几个实用案例，我们展示了 BCC 框架在捕获可观察性信号方面的多功能性。最后，我们亲自动手建立了一个小工具，用于跟踪实时 Go 应用程序上的 HTTP 请求。