eBPF 发展脉络、挂载点与应用场景eBPFextended Berkeley Packet Filter是 Linux 内核中一套可编程、可校验的扩展机制把用户编写的小程序安全地挂到内核事件上用于网络、安全、性能分析与可观测性。本文梳理从 BPF 到 eBPF 的演进、与kprobe / uprobe / fentry / tracepoint等挂载点的关系以及常见应用场景——不依赖其他篇章即可建立整体图景。目录为什么需要 eBPF从 cBPF 到 eBPF可观测性在说什么挂载点跟踪能力从何而来典型应用场景和「改内核 / 内核模块」比选型速记为什么需要 eBPF网络流量分析、安全监控、性能优化等需求长期卡在一个矛盾上做法优点痛点用户态采样 / 日志安全、易部署看不到内核与协议栈细节开销或延迟大改内核 / 写内核模块能力强升级慢、风险高、难分发固定内核探针有标准事件覆盖面与表达力有限eBPF 的折中是在内核里跑一段经过校验的字节码对数据包、系统调用、内核函数等做实时分析与受控的处理同时尽量不牺牲稳定性。从 cBPF 到 eBPF经典 BPFcBPF1990 年代初Steven McCanne 与 Van Jacobson 提出Berkeley Packet Filter用于用户态高效抓包过滤。1992 年 USENIX 论文The BSD Packet Filter: A New Architecture for User-level Packet Capture描述了指令集寄存器极少、面向过滤虚拟机在内核中解释执行过滤器过滤器模型决定哪些包拷到用户态tcpdump/libpcap对外仍常用cBPF 语法描述过滤器。但在现代 Linux 内核中加载后的 cBPF 指令通常会被透明转换为 eBPF 指令再执行——真正的执行引擎已是 eBPF。传统 BPF指令集固定、用途偏网络过滤本身难以支撑通用跟踪与复杂逻辑这也是后来扩展为 eBPF 的动力。eBPF通用内核虚拟机约2014年起Alexei Starovoitov 等将 BPF 扩展为更通用的虚拟机eBPF更多寄存器、更丰富的指令与辅助函数、Map 数据结构、多种程序类型不仅是包过滤。约2015年LLVM/Clang支持把 C 编译成 eBPF 字节码开发者不必再手写伪汇编生态开始爆发。1992 cBPF包过滤2014 eBPF通用 VMClang/LLVMC → 字节码可观测 / 网络 / 安全一句话cBPF 是「面向过滤的经典模型与语法」eBPF 是「内核里可校验的通用小程序运行时」。今天即使用 tcpdump内核侧也往往跑在 eBPF 引擎上。可观测性在说什么可观测性Observability通过采集、关联、分析指标与事件理解系统运行状态、性能与行为支撑排障、优化与容量规划。相对传统「监控几个固定指标」可观测性更强调问题未事先预知时仍能从信号反推内部状态Metrics / Logs / Traces及内核事件可关联对延迟、错误、饱和等有端到端可见性eBPF 的价值在于在几乎不改应用、不重启业务的前提下从内核与运行时边界拿到高保真事件系统调用、网络路径、锁竞争、文件 I/O 等补齐用户态遥测的盲区。挂载点跟踪能力从何而来在 eBPF 大规模流行之前Linux 已有多套跟踪与诊断机制。今天大量 eBPF 跟踪能力是挂在这些机制之上的而不是另起一套无关的探针体系。机制跟踪对象要点kprobe / kretprobe内核函数入口 / 返回动态插桩灵活但开销与稳定性需注意uprobe / uretprobe用户态函数入口 / 返回类似 kprobe目标在用户进程如 libc、OpenSSLfentry / fexit内核函数入口 / 返回编译期预留 NOP挂接时替换通常比 kprobe 更轻、更现代tracepoint内核预定义事件点接口相对稳定适合「官方埋好的点」kprobe / kretprobekprobe在目标内核函数入口插入处理逻辑。kretprobe在返回路径上挂钩便于看返回值与耗时。传统实现常依赖断点类机制如int3触发处理例程动态、强大但对热点路径开销更敏感。uprobe / uretprobe机制与 kprobe 族类似但目标是用户态二进制中的符号/偏移。典型用途跟踪malloc、pthread、数据库客户端库在加解密前后观测明文见 SSL 相关实践类文章需要注意符号裁剪、静态链接、JIT 代码等会使挂点定位变难。fentry / fexit相对 kprobefentry/fexit复用的是内核ftrace基础设施编译时通过 GCC 的-mfentry同属 profiling/mcount调用约定一脉在函数入口预留NOP 槽位挂接处理函数时把 NOP 换成调用。因此它和ftrace、动态跟踪是同一条「编译期埋点、运行时改写」的道路而不是另起炉灶。常见收益路径更短、开销通常低于经典 kprobe与 BPF trampoline 等现代机制配合更好新内核上写内核跟踪在能力可用时优先考虑 fentry/fexit。tracepoint内核在关键路径上预留的稳定事件点如调度、系统调用、块设备。优点是 ABI 相对克制缺点是「没有埋点就钩不到」。eBPF 可通过BPF_PROG_TYPE_TRACEPOINT等类型订阅。eBPF 程序常见挂载面kprobe/kretprobeuprobe/uretprobefentry/fexittracepoint校验后的字节码Map / ringbuf用户态读取与可视化典型应用场景上一节的挂载点解决「钩在哪」下面按场景看「钩完能干什么」。工具链BCC/bpftrace偏系统可观测XDP/网格偏数据面再往上还可以把同一套能力接到业务可观测Metrics / Traces。内核软件栈上的位置全景先建立空间感示意非完整协议栈跟踪面横切网络路径由早到晚用户态应用 / 库Socket API网卡驱动XDPTC ingress/egress协议栈 IP/TCPtracepointkprobe / fentryuprobe位置典型用途XDP进栈前处理/统计极限 PPSTC分类、策略、容器 veth 边界观测协议栈 / Socket连接、重传、队列积压tracepoint / fentry内核事件与函数级延迟uprobe用户态库与业务函数跟踪与性能分析工具工具角色BCC工具集 Python/C 库便于写自定义 eBPF 并做网络/系统分析bpftrace声明式脚本语言适合临时排查、adhoc 跟踪二者都建立在 eBPF 上述挂载点之上BCC 偏「可编程工具箱」bpftrace 偏「一行脚本看现场」。业务可观测性不只是「看内核」系统指标之外eBPF 也能补应用侧盲区并与现有遥测对齐例如用uprobe跟踪业务进程内关键函数序列化、ORM、RPC stub的耗时与错误率导出为Metrics在出入站边界打点把内核侧延迟段拼进分布式 Trace的本地 span对「未埋点的遗留服务」做黑盒式延迟画像再决定要不要改代码加 OpenTelemetry这与第三节的可观测性定义同一条线eBPF 提供高保真事件是否变成业务可观测取决于你是否把事件关联到服务、接口与用户请求 ID。网络数据路径XDPXDPeXpress Data Path允许在数据包进入完整协议栈之前做处理丢弃、重定向、改写等。适合 DDoS 缓解、负载均衡前置、高速过滤等与「只观测」的 trace 类程序不同XDP 更偏可编程数据面。落地时务必区分运行模式——这是新手踩坑重灾区模式含义观感NativeDriverXDP_DRV驱动支持在驱动收包路径尽早执行性能最好目标形态GenericXDP_SKB驱动不支持时的内核通用回退能跑但慢很多虚拟机/老网卡上常见「以为上了 XDP、体感却一般」OffloadXDP_OFFLOAD卸载到智能网卡等硬件吞吐潜力大依赖具体硬件与驱动选型与压测前先确认当前网卡/驱动是 Native 还是掉进了 Generic。安全与运行时防护系统调用审计、进程行为画像、容器逃逸检测等常组合tracepoint / LSM hook / 网络程序把策略下沉到内核事件流。服务网格与云原生旁路部分方案用 eBPF 做套接字级加速或可观测减少传统 sidecar 的跳数选型需看内核版本、可移植性与运维成本。和「改内核 / 内核模块」比维度内核模块 / 改源码eBPF安全出错可直接打挂内核Verifier先静态检查边界、类型、有限循环等升级强绑定内核版本CO-RE BTF 可改善跨版本移植表达力几乎任意受程序类型、辅助函数、复杂度上限约束分发难用户态加载字节码即可仍需权限与内核能力eBPF不是「万能内核插件」复杂状态机、任意睡眠、随意指针算术都会撞上校验器或模型限制。适合事件驱动的短逻辑 Map 聚合。选型速记你的目标优先考虑临时看延迟、谁在调什么 syscallbpftrace / BCC 现成工具生产长期探针、跨内核版本libbpf CO-RE/BTF超高速包处理XDP先确认Native vs Generic勿被兼容模式骗过用户态库内部行为含 TLSuprobe注意符号与合规稳定内核事件tracepoint / 稳定 ABI收束eBPF 把「可编程」带进内核同时用校验器守住安全边界可观测性场景里真正决定你能看见什么的往往是挂在哪类 hook 上而不只是「写了 eBPF」四个字。整理自《深入理解 eBPF 与可观测性》相关章节并补充演进与选型说明。