适用场景

eBPF 的价值在于「不用改业务代码就能看到内核态发生了什么」。排障时它能把「服务慢」拆成「内核协议栈慢、队列慢、还是对端慢」。但 eBPF 依赖内核版本和权限，落地前先确认内核版本与安全策略，别在生产上随便加载探针。

配置步骤（排障工具链与常用命令）

# 1) 连接与延迟：追踪 TCP 建连耗时
tcpconnect-bpfcc -t                 # 谁在连谁
biolatency-bpfcc -D                  # 块设备延迟分布
tcplife-bpfcc -t                     # 连接生命周期

# 2) 时延分段：应用 syscall
execsnoop-bpfcc
trace-bpfcc -T 't:syscalls:sys_enter_accept4' '%s %d' comm pid

# 3) 内核协议栈重传与丢包（新内核）
nstat -s | head -20
ss -s
cat /proc/net/snmp | grep -A1 Tcp

# 4) 队列与拥塞
tcpretrans-bpfcc -T

关键参数与建议

  • 内核版本：4.19 以上功能较完整，5.x 以上可用较新的 BTF 与 CO-RE 能力
  • 权限：加载探针需要 CAP_BPF/CAP_SYS_ADMIN，生产环境按需授权并记录
  • 观测点选择：TCP 重传、连接建立耗时、socket 队列、文件读写延迟最实用
  • 采样率：高流量场景必须采样或按条件过滤，否则开销明显
  • 数据落地：指标进 Prometheus，明细进日志或对象存储，避免内存爆
  • 安全边界：内核升级或容器运行时升级后要回归验证探针兼容性
  • 与现有工具配合：ebpf 看内核，应用 APM 看代码，两边对齐时间戳

容易踩的坑

  • 内核版本不够还硬上 CO-RE 方案，加载直接失败
  • 在生产高峰期跑全量探针，CPU 抖升被业务投诉
  • 探针版本与内核不匹配，数据看不准还以为是业务问题
  • 只采数据不做聚合，内存被明细撑爆
  • 没对齐时间戳，用 eBPF 数据和应用日志对不上
  • 忽略容器命名空间，看到的 PID 和容器内对不上

验证与巡检

# 内核与 BTF 能力确认
uname -r
ls /sys/kernel/btf/vmlinux
bpftool feature probe | head -30

# 开销观察：运行探针前后 cpustat
mpstat 1 5
  • 巡检：探针加载无报错、CPU 开销 < 3%、数据保留周期明确、内核升级后有回归记录

小结

eBPF 落地检验：能用一个命令说清某次慢请求的时间都花在哪一段（应用、内核队列、网络、对端），并且开销可控。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。