eBPF 可观测性落地：先找“应用层解释不了的那个问题”，而不是先建一套新仪表盘

eBPF 在 2026 年的可观测性版图里已经不是一个实验性选项。Cloudflare 用它做自定义 XDP 抓包和高分辨率内核直方图，在数据包损坏类故障的诊断中起了决定性作用。Google 用它做实时锁竞争分析和跨机群诊断。滴滴开源的 HUATUO 基于 eBPF 和内核追踪，覆盖 TCP/IP 协议栈、CPU 调度、内存管理，自动捕获 softlockup、OOM、网络延迟等事件，已经在生产环境规模化部署。

这些案例的共同点不是“eBPF 很酷”，而是它们都遇到了应用层埋点看不到的问题。应用层的指标能告诉你“P99 变慢了”，但看不到慢在系统调用的哪个阶段、锁在哪个内核路径上竞争、网络包在协议栈的哪一层被丢弃。eBPF 的价值是把观测点下沉到内核，在不修改应用代码的前提下拿到这些信号。

但这个价值有一个前提：你得先有一个“应用层解释不了的问题”。很多团队落地 eBPF 的方式是“先上一套 eBPF 采集，把能采的都采了”，结果得到大量内核事件，却不知道哪些和业务故障相关，最终变成一套没人看的仪表盘。更有效的顺序是反过来：先从一个具体的、应用层指标无法定位的性能问题出发，用 eBPF 去补那一段盲区，验证它能不能给出可行动的答案，再考虑扩大采集范围。

一个具体的切入场景是“延迟高但应用指标正常”。应用层的 span 显示某个 RPC 耗时 800ms，但下游服务的处理时间只有 50ms，中间的时间去哪了？eBPF 可以看系统调用耗时、调度延迟、网络协议栈里的重传和排队。另一个场景是“容器网络吞吐不达预期”，应用层看不到内核协议栈里的丢包和拥塞控制行为，eBPF 可以看到。

工程上需要提前接受的约束包括：内核版本依赖、安全策略限制、以及采集本身的开销。采集粒度越细、事件频率越高，CPU 和内存开销越大。生产环境里通常需要采样和聚合，而不是全量事件流。eBPF 和 OpenTelemetry 的融合是一个合理的方向：把 eBPF 采集的数据转成 OTel 的 Span 和 Metric，和应用埋点拼在同一条 trace 里，而不是另起一套观测体系。但这要求团队对 trace 的语义有一致的定义，否则拼出来的数据只是“更多数据”，不是“更好的解释”。

eBPF 的定位应该是应用层观测的补集。它解决的是“应用层看不到”的问题，不是“替代应用层”。先有那个问题，再上 eBPF；没有那个问题，eBPF 只是又多了一套需要维护的基础设施。