eBPF内核可观测性实战：从TCP重传到生产排障

去年我们线上发生了一次诡异的高频超时：数据库连接偶发建立失败，丢包率不到0.1%，但每次抖动都精准砸在连接建立那几十毫秒上。我用netstat、ss、strace排查了大半天，数据都有，但没人能告诉我“这个重传到底发生在哪条连接、由哪个进程触发、为什么偏偏在这一刻发生”。后来我把一个大约20行的 eBPF 程序挂到 Linux 内核的 TCP tracepoint 上，三分钟就看到了答案。也就是从那次之后，我彻底相信了一件事：内核可观测性已经进入了 eBPF 时代。

这篇文章我想用一线实践的视角，把 eBPF 拆开讲清楚：它为什么被称为 Linux 内核可观测性革命，背后的安全模型和运行时机制到底怎么工作，以及从写第一个脚本到排查一次真实线上故障，最值得你关注的细节和坑。适合的对象主要是：天天在 Linux 上排查问题的后端工程师、正在做容器网络和存储优化的 SRE / 平台工程师、需要理解内核行为的性能工程师，以及刚开始读内核源码、想找一个安全入口观察内核运行过程的同学。就算你之前完全没写过内核代码，只要熟悉 Linux 命令和一点 Python，这篇文章的前半部分也能跟上。

1. 从“黑盒猜谜”到可观测性革命

1.1 传统内核问题定位的三个困境

在讲 eBPF 之前，我想先聊聊那些“旧时代”的排查手段到底缺了什么。任何一个在 Linux 上做过深度排障的人，应该都经历过这样的场景：应用层日志显示连接建立失败，但网络抓包看不到异常；/proc/net/tcp里有大量 TIME_WAIT，/netstat -s却看不出哪里不对；想确认某个 Socket 是哪个进程创建的，只能靠lsof列出当前活着的连接，历史轨迹一概没有。你面对的是一个反馈极不稳定的内核黑盒。

三种常用手段各有明显短板。第一种是修改内核源码加日志，然后重新编译、重新部署，这个周期通常是小时到天，生产环境基本不会让你这么干。第二种是借助strace、perf、systemtap这类动态跟踪工具，它们确实能用，但有些操作需要加载内核模块，对高并发进程的影响也不小，部署成本不低。第三种是凭经验“猜”，靠负载曲线、监控指标和源码阅读去推断根因，这种方法最常用，但也最容易漏掉关键证据。

这些困境的核心是同一个问题：你缺少一种能力，能在内核事件发生的瞬间、以极低的开销读取现场。而 eBPF 解决的，正是这件事。

1.2 eBPF到底改变了什么

eBPF（Extended Berkeley Packet Filter）提供了一套机制，让用户态程序可以安全地“钻进”内核事件流里。简单说，你把自己写的一段受限程序挂到内核的某个 hook 点，当事件发生时，内核会执行这段小程序，并用受控方式把结果输出到指定的 map 或环形缓冲区。整个过程发生在内核上下文，但你不需要改内核源码，不需要加载内核模块，执行前还会经过严格的安全验证。

它的价值不仅是“能看”，更是“能看得非常细”且“代价足够低”。比如你想统计某个进程在5分钟内发起了多少次 TCP 重传，传统方式要么抓包、要么靠ss -ti轮询，而 eBPF 可以直接捕获每一次重传事件，把 pid、进程名、源端口、目的地址一次性捞出来。这类观测能力如果靠改内核代码实现，成本高到根本不适合在日常生产环境使用。

所以说它是“革命”并不夸张。今天的 Kubernetes 集群排障、服务网格数据面观测、安全运行时检测，都开始把 eBPF 当作底层基础设施来用。理解它，你就等于多了一把打开内核黑盒的钥匙。

2. 内核原理篇：为什么eBPF既安全又高效

2.1 hook点体系与事件驱动模型

eBPF 程序按挂载位置可以分为几大类。kprobe/kretprobe 可以挂在任意内核函数的入口和返回点，适合观察函数内部逻辑和参数返回值；tracepoint 是内核预先定义好的稳定事件点，比如tcp_retransmit_skb、sys_enter_openat，它们有稳定的参数结构，是我最推荐的生产环境选择；uprobe/uretprobe 挂在用户态应用的函数上，适合分析用户态代码性能；还有 XDP、tc、cgroup 等网络路径上的 hook，用来做包处理和流量控制。

理解这些 hook 的区别是第一个关键点。我的建议很简单：只要能使用 tracepoint，就不要使用 kprobe。原因是 tracepoint 的参数属于内核维护者保留的稳定接口，基本不会在小版本升级时被破坏；而 kprobe 挂的是内核内部函数，函数名和签名随时可能变化。今天能成功 attach 的脚本，内核一升级就可能加载失败。我见过很多线上排查脚本都挂在 kprobe 上，换了个新内核镜像环境就全部失效，这个教训值得记一笔。

事件驱动模型是 eBPF 高性能的基础。每个事件产生时，内核只调用你绑定的那段程序，而不是像轮询采样那样不断扫描系统状态。所以事件稀疏时，eBPF 的开销趋近于零；事件密集时，程序本身必须在几微秒内处理完，否则就会影响内核路径的执行。这也是为什么写 eBPF 程序时要克制：不能在里面做重活，要抱着“只是记一笔账就走”的心态。

2.2 验证器如何守住安全底线

如果说 hook 机制决定了 eBPF 能做什么，那么验证器（verifier）决定了它能不能安全地做。每个 eBPF 程序加载前，内核验证器都会做一次完整的静态分析：检查代码是否会越界访问内存、是否能在有限步骤内结束、是否存在不可达路径、是否使用了被禁止的 helper 函数。验证器会拒绝一切无法证明安全性的程序。这样设计的结果是，用户态可以把“执行代码”安全地交给内核，而不用像加载内核模块那样承担系统崩溃的风险。

验证器的严格也带来了开发上的约束。最直观的体感是：eBPF 程序里不能随便写循环，早期版本循环必须完全展开，后来虽然支持了有限循环，但循环次数必须在编译期能确定，而且要受验证器上限约束；栈空间限制在 512 字节，复杂程序里变量一多就要想方设法压缩；可访问的全局数据规模也有限。这些限制会逼迫你写出更简单、更直接的程序逻辑。

刚开始接触的人最容易犯的错误，是把 eBPF 当成“把普通 C 程序塞进内核里跑”，然后在程序里尝试调用 glibc、动态申请内存、写日志文件，结果是编译能过、加载被拒。理解验证器的定位很重要：它就像机场安检，允许你随身携带有限配额物品进入禁区，而不是让你在内核里随便折腾。

2.3 运行时数据交互：map、ring buffer 与 perf event

eBPF 程序运行在内核上下文，用户态程序在另一层，两者之间的桥梁是映射（map）。map 是内核里维护的一组数据结构，比如哈希表、数组、LRU、队列等。eBPF 程序通过 helper 更新和查询它们，用户态则通过bpf()系统调用读写。最常见的设计模式是“内核收集、用户态展示”：eBPF 把事件计数或最新状态写进 map，用户态程序周期性地读取并聚合展示。

如果你需要把实时事件数据流式传到用户态，还有两个选择：perf event buffer 和更现代的 BPF ring buffer（ringbuf）。它们的区别在于：perf event buffer 为每个 CPU 维护独立缓冲区，多核高并发场景下可能因为事件分布不均而产生部分乱序；ring buffer 则提供统一环形缓冲，支持数据丢失避免、批量读取，是当前官方推荐的实时大流量数据通道。我的使用经验是：只要采集频率不高、数据结构简单，用 map 聚合就足够；需要记录每条事件明细时，优先考虑 ring buffer。

这里再补充一个容易忽略的点：map 也不是随便用的。哈希 map 的 key 设计要尽量内聚，很多初学者会把 pid 和 comm 分开建 key，导致查询时组合困难。正确的思路是把“一次观测事件”当成一条记录，把能唯一定位它的字段拼成一个 key，比如pid + 端口 + 方向，这样后面做聚合统计会顺手得多。

3. 实操：从零写一个可上线的eBPF跟踪工具

3.1 环境选型与工具链对比

开发 eBPF 主要有三条路线：BCC、libbpf + CO-RE、bpftrace。

BCC 是入门最快的全家桶，它把 eBPF 的加载、编译、map 读写都封装成了 Python 接口。你只要写一小段 C 代码放进字符串，调用 attach 方法绑定事件，脚本就能跑起来。缺点是依赖 Python、LLVM 和运行时编译，在精简容器里体积不小；传统的 BCC 每次启动都会重新编译一次 BPF 代码，不太适合做长期驻留的 agent。

libbpf + CO-RE（Compile Once - Run Everywhere）是新一代首选。用 Clang 把 eBPF 程序编译成带 BTF 信息的 ELF 目标文件，拷到目标机器上可以直接加载，不需要运行时编译，而且在合理的内核版本范围内可以做到“一次编译，到处运行”。代价是手动写 C 代码的复杂度更高，学习曲线更陡。

bpftrace 语法最精简，特别适合快速现场排查和临时分析。很多复杂工具的一行式版本就是用 bpftrace 写的，但做长期监控还是得回到前两条路线。

我的建议非常直接：快速验证和应急排障用 bpftrace；要建稳定的可观测性设施用 libbpf + CO-RE；BCC 适合做教学和中期原型。内核版本最好在 5.10 以上，并且确认开启了 CONFIG_DEBUG_INFO_BTF。如果你的生产环境大多是相对老的发行版，可以先检查/sys/kernel/btf/vmlinux是否存在，存在就可以安心用 CO-RE，不存在就需要走 BCC 运行时编译方案，或者找同版本内核手动补充 BTF 信息。

3.2 快速验证版：bpftrace 追踪 TCP 重传

先看应急版。假设线上出现连接抖动，你想知道重传发生在哪些进程和连接上，一个一键 bpftrace 脚本就能搞定：

bpftrace -e ' tracepoint:tcp:tcp_retransmit_skb { @retrans[pid, comm] = count(); } interval:s:5 { print(@retrans); clear(@retrans); } '

tracepoint:tcp:tcp_retransmit_skb是钩子，每次内核准备重传一个 TCP 段时触发；pid和comm是 bpftrace 提供的当前进程信息。运行5分钟后，你会看到一张清晰的表格：哪个进程在持续触发重传，频率有多高。如果还想看端口维度，可以进一步在 args 里取源端口和目的端口，按[pid, comm, dport]聚合。

这种脚本是典型的“5分钟看现场”工具。它不会对应用产生什么影响，因为 tracepoint 是内核预埋的稳定事件点，触发频率也不会高到拖垮性能。你在应急时先跑这种脚本，能快速决定下一步是抓包、看内核日志还是直接修应用。

3.3 生产版：BCC + Python 闭环监控

再看一个真正的“工具”形态。假设你也想收集重传事件，然后接入告警平台，可以用 BCC 把同一段逻辑做成长期运行的后台监控。eBPF 部分用 C 写，Python 负责事件接收、格式化和告警触发。

from bcc import BPF import socket bpf_src = ''' #include <linux/sched.h> #include <net/inet_sock.h> struct retrans_evt { u32 pid; u32 sport; u32 dport; u64 ts; char comm[TASK_COMM_LEN]; }; BPF_PERF_OUTPUT(events); int on_tcp_retrans(struct tracepoint__tcp__tcp_retransmit_skb *args) { struct sock *sk = args->sk; struct inet_sock *inet = (struct inet_sock *)sk; struct retrans_evt evt = {}; evt.pid = bpf_get_current_pid_tgid() >> 32; bpf_get_current_comm(&evt.comm, sizeof(evt.comm)); evt.sport = inet->inet_sport; evt.dport = inet->inet_dport; evt.ts = bpf_ktime_get_ns(); events.perf_submit(args, &evt, sizeof(evt)); return 0; } ''' bpf = BPF(text=bpf_src) bpf.attach_tracepoint("tcp", "tcp_retransmit_skb", "on_tcp_retrans") def handle_event(cpu, data, size): evt = bpf["events"].event(data) print(f"pid={evt.pid} comm={evt.comm.decode()}" f" sport={socket.ntohs(evt.sport)}" f" dport={socket.ntohs(evt.dport)}" f" ts={evt.ts}") bpf["events"].open_perf_buffer(handle_event) while True: bpf.perf_buffer_poll(timeout=100)

这段代码演示了典型的“内嵌寄存器 + perf 事件”模式。BPF_PERF_OUTPUT(events)声明一个输出通道；events.perf_submit在内核侧把evt结构发送出去；用户态通过open_perf_buffer注册回调，在perf_buffer_poll里持续消费事件。运行方式很简单，有CAP_BPF权限或者 root 权限即可：

sudo python3 tcp_retrans_monitor.py

如果内核支持 ringbuf，在 BCC 里可以换成BPF_RINGBUF_OUTPUT(events)和events.ringbuf_output(...)，用户态再改用bpf["events"].open_ring_buffer(...)。这一版在我的实测中吞吐更高，CPU 占用也更低，适合事件量大的场景。

3.4 基于 libbpf 的现代落地方式

如果你要把 eBPF 观测能力做成常驻监控 agent，BCC 的“Python 外挂 + 运行时编译”模式在资源占用和部署包体积上都会成为负担。这时候建议切到 libbpf + CO-RE 组合。工作流大概是这样的：

首先用bpftool把目标内核的 BTF 信息导出成头文件：

bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

然后在 eBPF C 文件里直接#include "vmlinux.h"，不再依赖 BCC 头文件。用 Clang 编译成目标文件：

clang -g -O2 -target bpf -c trace_retrans.bpf.c -o trace_retrans.bpf.o

再用 bpftool 生成工程骨架：

bpftool gen skeleton trace_retrans.bpf.o > trace_retrans.skel.h

宿主 C 程序 include 这个骨架文件，依次调用 open、load、attach，再轮询 ring buffer 读取事件。由于.bpf.o里已经记录了 BTF 信息，同一个 ELF 在多个内核小版本上都能正常加载，部署时不需要再带 LLVM 和一堆内核头文件。这种“一次编译、到处运行”的能力，是它替换 BCC 成为生产标准的根本原因。

需要提醒的是，CO-RE 不是银弹。如果你的机器内核压根没有开启 BTF，常规做法是找同版本内核导出 vmlinux BTF 并覆盖到目标机器，或者老老实实退回 BCC 运行时编译方案。实践中，大部分还在维护的生产发行版内核都默认开了 CONFIG_DEBUG_INFO_BTF，但一定在动手前检查清楚，免得编译好一个 agent，部署时才发现一堆机器加载不了。

4. 实战记录：一次线上数据库连接超时的eBPF排查

4.1 现象与常规手段的失效

去年大促前的一次压测，业务方报“数据库连接偶发超时”，发生率不到0.5%，特征非常诡异：应用日志显示连接建立耗时动辄3秒甚至直接 connect 超时，但网络抓包却几乎看不出问题，因为重现率太低，抓包窗口很难覆盖到异常瞬间。我们用ss -tin查看连接状态，只看到大量正常流量；netstat -s里 ListenOverflows、ListenDrops 也都是正常值。所有能看到的数据都正常，但问题又确实存在。

这就是典型的“监控指标撑不住现场”的场景。常规的 TCP 状态、包量、错误计数都是累计型指标，频率太低的事故很难通过它们定位；抓包虽然能看到协议栈边界，但看不到内核内部的排队和调度情况。那一天我决定换个思路：不再问“网络包去哪了”，而是问“内核的事件处理路径上，到底哪一步变慢了”。

4.2 三个eBPF脚本锁定根因

第一个脚本，我抓的是软中断处理耗时。网络包从网卡进入后，会触发 NET_RX 软中断，如果 CPU 忙，软中断会被延后很久。用 tracepoint 对irq:softirq_entry和irq:softirq_exit做配对，按 CPU 和软中断类型统计耗时分布：

bpftrace -e ' tracepoint:irq:softirq_entry { @start[cpu, args->vec] = nsecs; } tracepoint:irq:softirq_exit { $t = nsecs - @start[cpu, args->vec]; @delay_us[args->vec] = hist(($t)/1000); } '

跑了一会儿，分布图里 NET_RX（vec 3）在 CPU2 上出现了一条明显的长尾，最大延迟超过30毫秒。这就是一个非常有价值的信号：网络软中断被人为延后了。第二个脚本继续看 CPU2 上到底谁在抢占。用调度 tracepoint 统计每个进程在 CPU2 上的运行时间：

bpftrace -e ' tracepoint:sched:sched_switch { @cpu_usage[pid, comm] = sum(nsecs - @last[cpu]); @last[cpu] = nsecs; } '

多跑几分钟，发现一个和数据库业务毫无关系的编排进程在 CPU2 上占了近70%的运行时间。第三个脚本验证影响面：把网卡 RX 队列的 CPU 亲和性和软中断处理结果合起来看，确认持续被压的 RX 队列正好和这个进程绑在了同一个核心上。

到这里根因已经完全清楚了：这台机器没有做中断亲和性配置，irqbalance 又没来得及介入，导致数据库服务所在宿主机上某个编排进程长期占满 CPU2，把网络软中断排队挤到了几十毫秒级别。数据库连接建立的 SYN 包在这个 CPU 上被延后处理，自然表现为连接超时。找到根因后，我们把网卡中断单独绑定到两个专用核心上，超时现象立刻消失，后续压测再也没有复现。

4.3 开销评估与量化对比

整个排查过程里，我始终在关注 eBPF 本身会不会引入新的扰动。实测下来，使用 tracepoint 做事件计数和直方图统计时，单事件开销通常在几百纳秒到几微秒的量级，对生产流量几乎无感。即使是最复杂的场景，比如在 softirq_entry 里记录时间戳、exit 里做一两次 map 更新，额外开销也不会成为系统的瓶颈。

作为对比，可以看看传统的替代方案：改内核源码重新编译需要小时级时间；用tcpdump全量抓包在高并发下会消耗大量 CPU 和磁盘 IO；用 GDB 在目标进程上 attach 通常会被生产环境禁用，而且对服务影响很大。eBPF 事件驱动、按需统计的模式，使得我们可以只针对特定 tracepoint 做细粒度采样，不需要收集无关数据，这就是它能在生产环境常态化使用的原因。

还有一个容易被忽略的价值：事后可解释性。排查结束之后，我保留了这几个 eBPF 脚本作为模板。下次遇到类似的“指标正常但响应异常”，我可以直接套用，甚至建立定期运行一轮的巡检任务。这种能力在传统手段下几乎是不可复用的，因为每个问题的现场都要重新抓取。

5. 避坑清单：验证器、权限、内核版本的六个雷区

5.1 最容易踩的六个坑

我把这几年用 eBPF 踩过的坑整理成一个速查表，按频率排序：

这六个坑里，前三个是环境兼容问题，后三个是程序设计问题。环境兼容问题在踩过一次之后基本能形成条件反射：先看内核版本、BTF 开关、容器权限；而程序设计问题需要多一点经验积累，尤其是 map key 的设计，我见过太多人在这里翻车。

5.2 验证器报错的快速解读

验证器的报错通常伴随一段指令级别的提示，第一次见到确实劝退。我总结了最常出现的几类：

invalid mem access是最常见的报错，意思是访问了不确定的内存区域，通常是没做空指针判断，或者访问的指针类型不匹配。解决办法很简单：读取任何可能为空的指针前，先判空；访问结构体字段时，确认类型是从 tracepoint 参数或 map 中推导出来的，而不是强转出来的。

back-edge或loop limit exceeded是和循环有关的报错。如果你在程序里写了 while 循环，验证器会要求循环边界必须在编译期可知。实在需要遍历，常见的做法是把循环展开成固定长度的代码段，或者把数据放到 map 里，用多次 bpf_probe_read 代替循环。

invalid indirect read from stack一般出现在把未初始化变量直接写入 map 或 perf buffer 时。内核要求读出的内存必须是初始化过的，解决方案是定义结构体时用= {}做零初始化。

面对报错，我的经验是不要试图改两行再硬试，而应该先看验证器给出的指令号，再回看源码对应位置。很多时候是类型推导的问题，加一个bpf_probe_read_kernel或重新组织局部变量就能解决。

5.3 兼容性与升级策略

内核版本兼容是 eBPF 落地最需要提前规划的环节。如果你管理的机器从 CentOS 7 到新发行版都有，那要面对的差异会非常大：旧内核可能没有 BTF、没有 ringbuf map、验证器能力差异也大。

我的兼容性策略有三条。第一，核心 agent 固定使用 libbpf + CO-RE，并维护一个最低内核版本基线，比如基线设为 5.10，低于这个版本就禁用高级特性，只保留基础观测能力。第二，所有自定义 eBPF 程序都优先挂 tracepoint 而不是 kprobe，因为 tracepoint 的稳定性要强得多。第三，每次发布前在目标内核版本矩阵上跑一遍冒烟测试，至少验证加载和基本事件采集正常。

如果你需要支持老内核，但又想用新内核的 BPF 特性，可以考虑在容器内挂载宿主的 BTF 文件，或者用 bpftool 从同版本内核导出 BTF 后手动覆盖到目标机器。这条路可行，但要清楚这是一种维护负担，能自动化尽量自动化。

6. 团队落地与个人体会

6.1 让eBPF在团队里真正可用

单打独斗玩 eBPF 是一回事，让一个团队稳定使用是另一回事。我的经验是，一定要在团队里先固化“最小可用工具箱”，而不是让大家各自写各自的脚本。比如，把常用的 tracepoint 观测脚本整理成一个 git 仓库，统一目录结构、统一输出格式、统一告警接口。这样任何一个成员面对类似问题，都能在一分钟内找到对应的观测工具，而不是从零再去查文档。

第二件事是明确分工：临时排查和应急定位用 bpftrace，因为上手快；常态化监控和告警场景用 libbpf + CO-RE 做成的 agent，因为它稳定且不依赖运行时环境。BCC 适合做原型验证和培训教学，但要控制它进入生产环境的机会，否则部署时的体积和运行时编译依赖会成为麻烦。

还有一点权限管理要提前想清楚。eBPF 需要较高的内核权限，如果团队里每个人都在生产环境直接 sudo 跑 bpftrace，安全和审计都会变得混乱。我建议只在专门的运维跳板机上开放完整的 eBPF 权限，其余场景通过统一 agent 来承载观测请求，这样既能保留灵活性，又能让事情可追踪、可回滚。

6.2 值得继续深入的方向

eBPF 现在已经是内核可观测性的主流技术，但它的边界还在不断扩展。我自己持续关注的几个方向包括：网络数据路径上的 XDP 和 tc hook，它们能做的不仅是观测，还能执行限速、转发、丢弃等策略，是构建高性能网络代理的底层能力；安全领域里基于 eBPF 的运行时检测，比起传统的内核模块方案更可控、更安全；还有 eBPF 程序之间的组合编排，如何让多个观测程序共享 map、避免重复采集，这会直接决定一套观测平台的资源消耗上限。

另外，我在实际使用中发现，很多人会忽略 eBPF 程序的“可读性维护”。内核侧代码虽然短，但因为它要受验证器限制，代码风格和用户态代码很不一样。如果不在注释里写清楚每个 map 的用途、每个 key 的组成，一个月后再回来看，基本就得靠反编译来找线索了。我这边的习惯是，每个 eBPF 程序头部都写清楚“观测目标、hook 点、产出 map、示例输出”，这个习惯帮我省了非常多重复排障的时间。

回到开头那个数据库连接超时的案例，那次经历让我印象最深的不是 eBPF 把根因找得有多快，而是整个排查过程的确定性：你不再需要靠猜测去缩小范围，你可以直接站在内核事件流上，看到每一步究竟发生了什么。这种“把内核黑盒打开”的能力，就是 eBPF 给我带来的最大价值。如果这篇文章能让你在下次排查问题时，想起还有这样一个工具，那我的目的就达到了。