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

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

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

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

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

流量录制原理

录制内容

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

实现思路

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

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

• 首先，调用accept获得一个调用方的连接；

• 第二步，在这个连接上通过调用 recv 读取请求数据，解析请求；

• 第三步，目标服务开始执行业务逻辑，过程中可能需要调用一个或多个依赖服务，对于每一次依赖服务调用，目标服务需要通过connect与依赖服务建立连接，然后在这个连接上通过 send 发送请求数据，通过 recv 接收依赖服务响应；

• 最后，目标服务通过send给调用方返回响应数据。

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

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

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

区分不同的请求

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

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

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

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

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

区分数据类型

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

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

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

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

流量录制实现

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

• 录制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 的内存地址上：

接下来，我们找到 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 支持的逐渐完善，很多问题也在逐步得到解决，后续的开发体验也会变得更顺畅。

安全机制

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

总结

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

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

软件测试面试文档

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