eBPF 在生产里的真正角色：不是“炫技”，是把观测点下沉到内核

eBPF 在 2026 年已经走过了“能不能用”的阶段，进入“用在哪里最值”的工程判断。Cloudflare 用它做 XDP 抓包和高分辨率内核直方图，在数据包损坏类故障的诊断中起了决定性作用。Google 用它做实时锁竞争分析和跨机群诊断，把诊断变更部署到基础设施的时间大幅缩短。浙商证券把 eBPF 和 Wasm 结合，在信创证券核心交易系统里做无侵入全链路可观测。

这些案例的共同点不是“eBPF 很酷”，而是它们都遇到了同一个问题：应用层埋点看不到的瓶颈，在内核里。

传统可观测性依赖应用埋点，但有些问题埋点解决不了：系统调用层面的延迟、网络协议栈里的丢包和重传、锁竞争导致的调度延迟、容器网络里的路径异常。这些问题发生在应用代码之外，应用层指标只能看到“变慢了”，看不到“慢在哪一层”。eBPF 的价值是把观测点下沉到内核，在不修改应用代码的前提下，拿到系统调用、网络事件、调度器行为这些底层信号。

落地时最值得先做的不是“全量采集”，而是选一个应用层解释不了的性能问题，用 eBPF 去补那一段盲区。比如 P99 延迟高但应用指标正常，可以用 eBPF 看系统调用耗时分布和锁等待；容器网络吞吐不达预期，可以看内核协议栈里的丢包和重传。eBPF 和 OpenTelemetry 的融合是 2026 年的一个明确趋势：把 eBPF 采集的原始数据转成标准的 OTel Span 和 Metric，和应用埋点数据拼在一起，而不是另起一套观测体系。

需要清醒的是，eBPF 不是免费的全知视角。它有内核版本依赖、有安全策略限制、有性能开销，采集粒度越细，开销越大。它的定位应该是“应用层观测的补集”，而不是“替代应用层观测”。先问“我有什么问题是应用层看不到的”，再决定要不要上 eBPF。没有这个前提，eBPF 只会变成又一套没人看的仪表盘。