eBPF 工程实践：观测能力与上线边界

修订于 2026-10-12：原文“凌晨事故”“200 多个服务”“零开销”等说法没有运行记录，已撤下。本文依据 Linux 内核文档讨论一般机制。

eBPF 允许经过验证的程序附着到受支持的内核钩子上，用于网络处理、跟踪和其他场景。它可以减少某些场景下对应用代码埋点的依赖，但不等于无需权限、没有性能开销，或能看到所有业务上下文。

三个核心概念

• 程序与钩子：程序在特定事件触发时执行；可用钩子和辅助函数取决于内核版本、程序类型与运行环境。
• Verifier：内核在加载时检查程序的控制流和内存访问等安全条件。通过验证是加载条件，不代表业务逻辑正确或运行时开销可忽略。
• Map：Map 在内核与用户空间之间保存和交换状态。容量、更新频率和清理策略会影响内存与处理成本。

跨内核版本部署还需处理结构布局变化。BPF CO-RE 通过 BTF 类型信息、编译器重定位和加载器支持提高可移植性；“Compile Once – Run Everywhere”是设计目标，实际兼容性仍需在目标内核验证。

观测方案怎么选

先写清楚要回答的问题，例如“哪类系统调用耗时增加”或“哪些网络路径出现丢包”。再选择合适的事件点与现成工具。只采集必要字段，避免在高频路径上记录过多数据。eBPF 能观察内核层事件，但业务请求 ID、用户身份等信息可能仍需应用侧遥测配合。

上线前应：

1. 核对目标内核、发行版、BTF、容器环境以及所需权限。
2. 在测试节点加载程序，检查 Verifier 结果、Map 容量和卸载路径。
3. 以目标流量测量 CPU、内存、延迟和事件丢失率；记录基线与采样率。
4. 灰度发布，设置资源限额和回滚条件，并验证程序卸载后状态是否清理。
5. 对采集的进程、网络和用户数据设置访问范围与保留期限。

不要从某一内核版本号推导所有 eBPF 特性均可用。准确支持范围应看发行版内核、配置和工具文档。

参考资料

• Linux 内核文档：eBPF Verifier
• Linux 内核文档：BPF Maps
• Linux 内核文档：libbpf 概览
• eBPF 文档：BPF CO-RE