如何基于eBPF实现跨语言、无侵入的流量录制？

曾经终败给现在 2023-10-14 16:02 17阅读 0赞

测试是产品发布上线的一个重要环节，但随着业务规模和复杂度不断提高，每次上线需要回归的功能越来越多，给测试工作带来了巨大的压力。在这样的大背景下，越来越多的团队开始使用流量回放对服务进行回归测试。

在建设流量回放能力之前，我们必须将线上服务的流量录制下来。通常要结合对流量特征的要求、实现成本、对业务的侵入性等方面综合考虑，选择不同的实现方式。

![图片][144054dead841f9c988250552abc271c.jpeg]

对于Java和PHP语言，目前业界已经有比较成熟的解决方案 jvm-sandbox-repeater、rdebug，基本可以做到低成本、无侵入式的流量录制；但Go语言由于缺少像jvm或libc等可利用的中间层，现有的方案 sharingan 需要修改官方Go源码并且侵入业务代码，稳定性风险较大；并且随着官方Go版本升级，需要持续维护迭代，使用和维护成本较高。

鉴于滴滴多语言的技术栈，我们经过调研发现可以通过eBPF实现一种**跨语言**、**无侵入**的流量录制方案，大幅降低流量录制的使用和维护成本。

**流量录制原理**

录制内容

流量回放时需要对下游依赖服务进行mock，因此录制的一条完整流量中不仅需要包含入口调用的请求/响应，还需要包含处理这次请求时所调用依赖服务的请求/响应。

![图片][81bfe727c2521b581ed170e681a28084.jpeg]

实现思路

在介绍流量录制方案之前，我们先来看一个请求的处理过程（简化后）：

![图片][e17eb083155e39f5aef5bb824a70d534.jpeg]

观察上述流程我们发现目标服务处理一个请求的大致流程如下：

*  首先，调用accept获得一个调用方的连接；
 *  第二步，在这个连接上通过调用 recv 读取请求数据，解析请求；
 *  第三步，目标服务开始执行业务逻辑，过程中可能需要调用一个或多个依赖服务，对于每一次依赖服务调用，目标服务需要通过connect与依赖服务建立连接，然后在这个连接上通过 send 发送请求数据，通过 recv 接收依赖服务响应；
 *  最后，目标服务通过send给调用方返回响应数据。

为了实现流量录制，我们需要把图中所有的请求和响应数据保存下来。传统的流量录制方法需要跟踪服务框架、RPC框架、依赖服务sdk等所有涉及发送/接收数据的方法，将数据收集并保存下来。由于框架和sdk多种多样，需要大量的代码改造和开发工作，成本难以控制。

这里我们考虑更通用的方式：**跟踪socket相关操作**，例如accept、connect、send、recv 等。通过这种方式我们可以不用关心业务中使用的应用层协议、框架、sdk等，实现更通用的流量录制方法。

但是，由于实现录制的位置更底层，能够获取的上下文信息更少，只有每个 socket 发送和接收的数据是不够的。我们需要借助其他信息对原始数据进行串联，从而组装完整的一条流量。

**区分不同的请求**

线上服务处理的请求大多是并发的，同时会有多个请求交织在一起，我们录制到原始数据是分散的，如何把同一个请求的数据合并，把不同请求的数据区分开呢？通过分析实际的请求处理过程，我们不难发现：

1.通常情况下，每个请求是在单独的线程中进行处理的。

![图片][babd8eb762780e621acdf64fb93e8668.jpeg]

2.为了提高处理速度，可能创建子线程并发调用依赖服务。

![图片][cbca66c421b25ea3a05fe758efcafdb4.jpeg]

实际上，子线程也可能再创建子线程，形成下图所示的线程关系：

![图片][4159fa83fc0c36eee8fbdf50d8b1807e.png]

对于这种涉及子线程的场景，我们只要把子线程的数据合并到请求处理线程即可。每个请求都会对应一个请求处理线程和一系列的子线程，最终我们可以根据**线程ID**来区分出不同请求。

**区分数据类型**

在每一条流量中包含了两类数据：入口调用的请求和响应，下游依赖调用的请求和响应。我们需要在流量录制时进行区分。通过观察请求处理流程，我们不难发现其中的规律：

1.入口调用的请求和响应是在accept获得的socket上接收和发送的，recv 的数据是 request，send 的数据是 response。

2.下游依赖调用的请求和响应是在 connect 获得的 socket 上接收和发送的，send 的数据是 request，recv 的数据是 response；不同的 socket 对应不同的下游调用。

因此，我们可以根据 **socket 类型和标识**区分出不同的数据类型和不同的下游依赖调用。

**流量录制实现**

考虑到目前大部分服务已经上云，因此方案需要支持容器化部署。eBPF程序运行在内核中，而同一宿主机上的所有容器共享同一个内核，因此eBPF程序只需要加载一次即可录制到所有进程的数据。整体方案如下：

![图片][35cc90549acd324bc08eeff719dada7c.png]

*  **录制agent**：与目标进程部署在相同容器中，根据进程名找到要录制的目标进程 pid，(1) 控制录制 server 开启/关闭录制；(7) 从录制 server 接收原始数据，解析成完整流量，(8) 保存到日志文件中。
 *  **录制server**：部署在宿主机上，负责 (2, 3) 加载/挂载 eBPF程序、(6) 从 eBPF Map 中读取原始数据。
 *  **eBPF程序**：负责在目标进程 (4) 发送和接收数据时，(5) 从挂载的函数中读取原始数据并写入 eBPF Map 中。

选择插桩点

根据前面的讨论，我们需要跟踪的socket操作包括：

*  accept和connect用于区分socket类型。
 *  send和recv用于捕获发送和接收的数据。
 *  close用于识别调用的结束。

对于Go语言，还需要获取执行上述socket操作的goroutine id和跟踪goroutine的父子关系。

在开发eBPF程序之前，需要选择合适的eBPF程序挂载位置，不同的eBPF程序类型，能够获取到的上下文不同，可调用的 bpf-helper 函数也不同。我们需要录制的数据只有TCP和UDP两种协议，因此可以通过kprobe挂载到内核的以下函数：

*  inet\_accept
 *  inet\_stream\_connect
 *  inet\_sendmsg
 *  inet\_recvmsg
 *  inet\_release

为了跟踪 goroutine 之间的关系，我们可以通过 uprobe 挂载到 Go 运行时的 runtime.newproc1 函数，从 callergp 和 newg 中获取对应的 goroutine 信息。

开发eBPF程序

流量录制虽然涉及了多个内核函数，但流程基本是一样的，下面以录制 socket 发送数据为例进行详细介绍。

函数签名：

int inet_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)

参数说明：

*  sock socket 指针
 *  msg 要发送的数据
 *  size 要发送数据的长度

返回值：

*  成功时返回发送的数据长度，失败时返回错误码。

由于实际发送的数据长度是在函数返回时才能获取到的，因此我们需要开发两个程序，分别完成以下工作：

*  在函数入口处记录函数参数和上下文
 *  在函数返回时记录实际发送的数据内容

函数入口 eBPF 程序：

SEC("kprobe/inet_sendmsg")
    int BPF_KPROBE(inet_sendmsg_entry, struct socket *sock, struct msghdr *msg)
    {
        struct probe_ctx pctx = {
            .bpf_ctx = ctx,
            .version = EVENT_VERSION,
            .source = EVENT_SOURCE_SOCKET,
            .type = EVENT_SOCK_SENDMSG,
            .sr.sock = sock,
        };
        int err;
    
    
    
    
        // 过滤掉不需要录制的进程
        if (pid_filter(&pctx)) {
            return 0;
        }
    
    
    
    
        // 读取 socket 类型信息
        err = read_socket_info(&pctx, &pctx.sr.sockinfo, sock);
        if (err) {
            tm_err2(&pctx, ERROR_READ_SOCKET_INFO, __LINE__, err);
            return 0;
        }
    
    
    
    
        // 记录 msg 中的数据信息
        err = bpf_probe_read(&pctx.sr.iter, sizeof(pctx.sr.iter), &msg->msg_iter);
        if (err) {
            tm_err2(&pctx, ERROR_BPF_PROBE_READ, __LINE__, err);
            return 0;
        }
    
    
    
    
        // 将相关上下文信息保存到 map 中
        pctx.id = bpf_ktime_get_ns();
        err = save_context(pctx.pid, &pctx);
        if (err) {
            tm_err2(&pctx, ERROR_SAVE_CONTEXT, __LINE__, err);
        }
        return 0;
    }

函数返回 eBPF 程序：

SEC("kretprobe/inet_sendmsg")
    int BPF_KRETPROBE(inet_sendmsg_exit, int retval)
    {
        struct probe_ctx pctx = {
            .bpf_ctx = ctx,
            .version = EVENT_VERSION,
            .source = EVENT_SOURCE_SOCKET,
            .type = EVENT_SOCK_SENDMSG,
        };
        struct sock_send_recv_event event = {};
        int err;
    
    
    
    
        // 过滤掉不需要录制的进程
        if (pid_filter(&pctx)) {
            return 0;
        }
    
    
    
    
        // 如果发送失败, 跳过录制数据
        if (retval <= 0) {
            goto out;
        }
    
    
    
    
        // 从 map 中读取提前保存的上下文信息
        err = read_context(pctx.pid, &pctx);
        if (err) {
            tm_err2(&pctx, ERROR_READ_CONTEXT, __LINE__, err);
            goto out;
        }
    
    
    
    
        // 构造 sendmsg 报文
        event.version = pctx.version;
        event.source = pctx.source;
        event.type = pctx.type;
        event.tgid = pctx.tgid;
        event.pid = pctx.pid;
        event.id = pctx.id;
        event.sock = (u64)pctx.sr.s;
        event.sock_family = pctx.sr.sockinfo.sock_family;
        event.sock_type = pctx.sr.sockinfo.sock_type;
    
    
    
    
        // 从 msg 中读取数据填充到 event 报文, 并通过 map 传递到用户空间
        sock_data_output(&pctx, &event, &pctx.sr.iter);
    
    
    
    
    out:
        // 清理上下文信息
        err = delete_context(pctx.pid);
        if (err) {
            tm_err2(&pctx, ERROR_DELETE_CONTEXT, __LINE__, err);
        }
        return 0;
    }

**获取goid**

对于 Go 语言，我们需要根据发送和接收数据时 goroutine id 进行数据串联，如何在 eBPF 程序中获取呢？通过分析 go 源码，我们发现 goroutine id 是保存在 struct g 中的，并且可以通过 getg() 来获取当前 g 的指针。

**getg 函数：**

根据函数注释，当前 g 的指针是放在线程本地存储（TLS）中的，调用 getg() 的代码由编译器进行重写。为了找到 getg() 的实现方式，我们看到 runtime.newg 函数中调用了 getg，对它进行反汇编，发现 g 的指针保存在 fs 寄存器 -8 的内存地址上：

![图片][db21e5cf8c021824faf000ed8c35a0f9.png]

接下来，我们找到 struct g 中的 goid 字段（位于 runtime/runtime2.go）：

type g struct {
        .... 此处省略大量字段
        goid         int64
        .... 此处省略大量字段
    }

拿到 g 的指针后，只要加上 goid 字段的偏移量即可获取到 goid。同时，考虑到不同的 go 版本之间，goid 偏移量可能不同，最终在 eBPF 程序中我们可以这样获取当前 goid：

static __always_inline
    u64 get_goid()
    {
          struct task_struct *task = (struct task_struct *)bpf_get_current_task();
          unsigned long fsbase = 0;
          void *g = NULL;
          u64 goid = 0;
          bpf_probe_read(&fsbase, sizeof(fsbase), &task->thread.fsbase);
          bpf_probe_read(&g, sizeof(g), (void*)fsbase-8);
          bpf_probe_read(&goid, sizeof(goid), (void*)g+GOID_OFFSET);
          return goid;
    }

遇到的问题

eBPF 程序虽然可以使用C语言开发，但是与普通C语言开发过程有较大的差别，增加了很多限制。

以下为开发时遇到的比较关键的问题和解决思路：

*  不允许使用全局变量、常量字符串或数组，可以保存到 map 中。
 *  不支持函数调用，可以通过 inline 内联解决。
 *  栈空间不能超过512字节，必要时可通过 array 类型的 map 做缓冲区。
 *  不能直接访问用户态和内核态内存，要通过 bpf-helper 的相关函数。
 *  单个程序指令条数不能超过 1000000，尽量保持 eBPF 程序逻辑简单，复杂的处理放在用户态程序完成。
 *  循环必须有明确的次数上限，不能只靠运行时判断。
 *  结构体成员要内存对齐，否则可能导致部分内存未初始化，引发 verifier 报错。
 *  代码经过编译器优化后 verifier 可能误报内存访问越界问题，可以在代码中增加 if 判断帮助 verifer 识别，必要时可通过内联汇编的方式解决。
 *  ....

随着 clang 和内核对 ebpf 支持的逐渐完善，很多问题也在逐步得到解决，后续的开发体验也会变得更顺畅。

安全机制

为了保障流量数据的安全性，降低数据脱敏对线上机器的性能影响，我们选择在流量采集阶段进行加密：

![图片][93f1d2ccb5e690055fc31d304748fbfd.jpeg]

## **总结** ##

本文介绍了eBPF在流量录制方向的应用，希望可以帮助大家降低流量录制的实现和接入成本，快速建设流量回放能力。

**最后：**下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取**【保100%免费】**

![8b0171187dce405e878f274a8cdd9ec0.png][]

#### **软件测试面试文档** ####

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

![a3e4226c935c4242804cbdf26b571bc6.png][]

![58df6cd288094ad8874e814f2477620b.gif][]

[144054dead841f9c988250552abc271c.jpeg]: https://img-blog.csdnimg.cn/img_convert/144054dead841f9c988250552abc271c.jpeg
[81bfe727c2521b581ed170e681a28084.jpeg]: https://img-blog.csdnimg.cn/img_convert/81bfe727c2521b581ed170e681a28084.jpeg
[e17eb083155e39f5aef5bb824a70d534.jpeg]: https://img-blog.csdnimg.cn/img_convert/e17eb083155e39f5aef5bb824a70d534.jpeg
[babd8eb762780e621acdf64fb93e8668.jpeg]: https://img-blog.csdnimg.cn/img_convert/babd8eb762780e621acdf64fb93e8668.jpeg
[cbca66c421b25ea3a05fe758efcafdb4.jpeg]: https://img-blog.csdnimg.cn/img_convert/cbca66c421b25ea3a05fe758efcafdb4.jpeg
[4159fa83fc0c36eee8fbdf50d8b1807e.png]: https://img-blog.csdnimg.cn/img_convert/4159fa83fc0c36eee8fbdf50d8b1807e.png
[35cc90549acd324bc08eeff719dada7c.png]: https://img-blog.csdnimg.cn/img_convert/35cc90549acd324bc08eeff719dada7c.png
[db21e5cf8c021824faf000ed8c35a0f9.png]: https://img-blog.csdnimg.cn/img_convert/db21e5cf8c021824faf000ed8c35a0f9.png
[93f1d2ccb5e690055fc31d304748fbfd.jpeg]: https://img-blog.csdnimg.cn/img_convert/93f1d2ccb5e690055fc31d304748fbfd.jpeg
[8b0171187dce405e878f274a8cdd9ec0.png]: https://img-blog.csdnimg.cn/8b0171187dce405e878f274a8cdd9ec0.png
[a3e4226c935c4242804cbdf26b571bc6.png]: https://img-blog.csdnimg.cn/a3e4226c935c4242804cbdf26b571bc6.png
[58df6cd288094ad8874e814f2477620b.gif]: https://img-blog.csdnimg.cn/58df6cd288094ad8874e814f2477620b.gif