eBPF（extended Berkeley Packet Filter）是 Linux 内核提供的可编程沙箱环境，允许在不修改内核源码、不加载内核模块的前提下，在内核态运行用户定义的字节码程序。eBPF 可观测性工具链已成为服务器性能诊断和网络故障排查的核心基础设施，相较于传统工具（strace、tcpdump）具有极低开销和内核级精度的优势。
eBPF技术架构与内核挂载点机制
eBPF 程序通过 Hook 机制挂载到内核的各个执行路径上。主要挂载点类型包括：
– kprobe / kretprobe：内核函数入口和返回处插桩，可追踪任意内核函数调用
– tracepoint：内核预定义的静态探针点，相比 kprobe 更稳定，不受内核版本函数重命名影响
– uprobe / uretprobe：用户态函数插桩，用于追踪应用程序内部行为
– XDP：网卡驱动层的数据包处理点，在 SKB 分配之前执行，延迟最低
– cgroup：容器和进程组的资源监控点，适用于 cgroups v2 环境
eBPF 程序使用 verifier 进行安全验证，确保不会导致内核崩溃。验证器检查所有可能的执行路径，保证程序在有限时间内终止且不越界访问内存。通过验证的程序经过 JIT 编译器转为原生机器码执行，运行时性能接近内核原生函数。
bpftrace工具编写内核追踪脚本
bpftrace 是 eBPF 生态中最易用的追踪工具，使用类 awk 的脚本语法。以下脚本统计 TCP 连接建立耗时：
#!/usr/bin/env bpftrace
#include <linux/socket.h>
kprobe:tcp_v4_connect {
@start[tid] = nsecs;
@sip[tid] = arg1;
}
kretprobe:tcp_v4_connect /@start[tid]/ {
$dur = (nsecs - @start[tid]) / 1000000;
printf("PID %d TCP connect took %d ms\n", pid, $dur);
delete(@start[tid]);
}
统计文件读操作延迟分布直方图：
bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; }
kretprobe:vfs_read /@start[tid]/ {
@us = hist((nsecs - @start[tid]) / 1000);
delete(@start[tid]);
}'
输出会以 power-of-2 直方图展示读操作的微秒级延迟分布，快速定位慢 I/O 问题。hist() 函数自动按 2 的幂次分桶，比手动统计更直观。
BCC工具集网络延迟与TCP重传分析
BCC（BPF Compiler Collection）提供了一系列生产可用的 eBPF 工具。TCP 重传追踪是网络诊断的高频场景：
from bcc import BPF
bpf_text = """
#include <uapi/linux/ptrace.h>
#include <net/sock.h>
BPF_HASH(last, u32);
int trace_retransmit(struct pt_regs *ctx, struct sock *sk) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
bpf_trace_printk("TCP retransmit PID=%d dport=%d\n", pid, ntohs(dport));
return 0;
}
"""
b = BPF(text=bpf_text)
b.attach_kprobe(event="tcp_retransmit_skb", fn_name="trace_retransmit")
print("Tracing TCP retransmits... Ctrl-C to end")
b.trace_print()
使用 tcprtt 工具直接分析 TCP 往返延迟分布：
sudo tcprtt -i eth0 -d 10
该命令对指定网卡抓取 10 秒 TCP RTT 数据，输出延迟分布、P50/P90/P99 百分位值。如果 P99 远高于 P50，说明存在网络抖动或拥塞。
Cilium eBPF网络策略与可观测性平台部署
Cilium 将 eBPF 引入 Kubernetes 网络层，替代传统 kube-proxy iptables 规则。部署 Cilium 后，可以使用 Hubble 实现服务级别可观测性：
helm install cilium cilium/cilium \
--namespace kube-system \
--set hubble.enabled=true \
--set hubble.metrics.enabled="{dns,http,tcp,drop,flow}"
查看服务间流量拓扑：
hubble observe --type flow --verdict DROPPED
这条命令实时输出所有被网络策略丢弃的数据包，包含源 Pod、目标 Pod、协议、端口信息。相较于 tcpdump 在每个节点抓包再汇总的传统方式，eBPF 方案在内核层直接过滤和聚合，网络延迟开销接近零。
eBPF性能基准测试与开销评估
eBPF 程序对系统性能的影响取决于挂载点和程序复杂度。对比基准测试数据：
– kprobe 挂载简单计数器：单核开销约 50-100ns，对系统调用吞吐量影响小于1%
– tracepoint 挂载数据采集：开销约 30-80ns，比 kprobe 更低（静态探针无内核函数查找开销）
– XDP 数据包处理：单包处理延迟小于100ns，10Gbps 线速下 CPU 占用低于5%
– bpftrace 复杂聚合脚本：取决于采集频率和数据量，生产环境建议限制输出频率
实际部署中，建议将 eBPF 追踪程序的输出通过 ring buffer 而非 perf buffer 传递，ring buffer 在多核并发写入时性能更优，CPU 缓存友好性更高。Linux 5.8 以上版本已支持 BPF ring buffer，单次写入延迟低于 50ns。对于高频事件采集场景，ring buffer 相比 perf buffer 可减少 30-50% 的 CPU 开销。
原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linuxebpf-ke-guan-ce-xing-gong-ju-lian-yu-wang-luo-xing/
