eBPF可观测性原理可以概括为：在受验证的条件下，把小段程序挂到内核事件点上，采集网络、进程、文件、系统调用等运行时信号，再把事件通过 maps 或 ring buffer 传给用户态分析。它补的是“应用不知道、日志没记录、指标太粗”的那一层，但它并不替代所有可观测性手段。
如果你关注指标、日志和链路三类信号的整体建设，可先阅读 可观测性平台怎么建？三类信号分层；如果关注微服务调用链，可结合 OpenTelemetry链路追踪实践 理解应用层语义。
图1：eBPF 可观测性的内核事件分层架构图，说明 eBPF
eBPF 看到的是内核事件，不是业务意图
根据 eBPF 官方介绍，eBPF 可在内核事件点运行受验证的程序，用于网络、安全和可观测性等场景[1]。它的观测对象通常是内核事件或内核数据结构，而不是“订单失败”“用户登录慢”这样的业务语义。
| 事件层 | eBPF 更擅长 | 仍需其他信号补充 |
|---|---|---|
| 网络 | 连接、丢包、延迟、TCP 状态 | 业务请求路径、用户行为 |
| 进程 | fork、exec、退出、资源占用 | 应用日志、错误栈 |
| 系统调用 | 文件、网络、权限相关调用 | 业务操作上下文 |
| 容器运行时 | cgroup、namespace、进程关系 | Kubernetes 对象语义 |
内核事件需要被翻译成平台语义
eBPF 采集到的是低层事件，平台需要把它映射到 Pod、Service、Namespace、应用和告警规则。没有这一步，团队只能看到大量事件流，却难以判断哪个业务受影响。
探针类型决定能观测到什么
eBPF 常见挂载点包括 kprobe、tracepoint、uprobes、XDP、tc 等。不同挂载点的稳定性、开销和适用范围不同。根据 Linux Kernel BPF 文档，BPF 子系统包含程序类型、maps、helper、验证器等机制，实际能力会受内核版本和配置影响[2]。
常见选择可以这样理解：
- kprobe：挂到内核函数，灵活但对内核实现变化更敏感。
- tracepoint：挂到内核预定义跟踪点，语义更稳定，适合通用事件。
- uprobes：观测用户态函数，适合补充运行时或库调用信息。
- XDP / tc：靠近网络数据路径，适合高性能网络观测和过滤。
- LSM hooks：适合安全策略和访问控制观测，需关注内核支持范围。
这些挂载点不是越多越好。采集点越靠近高频路径，越要评估性能、数据量和误报风险。
图2：eBPF 探针选择与事件流向，展示网络、内核函数、跟踪点
maps 和 ring buffer 连接内核态与用户态
eBPF 程序通常不能直接做复杂分析，而是把事件、计数器或状态写入 maps、perf buffer 或 ring buffer，再由用户态 agent 读取、聚合和上报。这样既控制内核态逻辑复杂度，也便于把数据接入 Prometheus、OpenTelemetry Collector 或自研平台。
| 组件 | 作用 | 边界 |
|---|---|---|
| eBPF 程序 | 在事件点采集和过滤 | 逻辑应尽量短小 |
| verifier | 加载前检查安全性 | 复杂程序可能被拒绝 |
| maps | 存储计数、状态、关联信息 | 需要管理容量和生命周期 |
| 用户态 agent | 读取、聚合、标注和导出 | 负责语义补全和限流 |
采集链路本身也要可观测
用户态 agent 丢事件、maps 容量不足、内核版本不兼容、权限缺失，都可能让观测结果不完整；这类 maps、helper 和验证器约束需要结合 Linux Kernel BPF 文档理解[2]。eBPF 工具自身也需要健康检查和丢弃率指标。
eBPF 可观测性的边界在哪里
eBPF 的优势是接近运行时真相，但边界也很明确。它不能自动理解业务事务，也不能绕过权限和内核能力限制，采集设计还需要为运行开销和数据安全留出治理空间。
常见边界包括：
- 内核版本边界：不同发行版、内核版本和运行时条件会影响程序类型、helper 和 BTF 支持。
- 权限边界：加载 eBPF 程序通常需要较高权限或特定能力，容器化部署要谨慎设计。
- 性能边界：高频事件采集会产生 CPU、内存和网络开销，需要采样、过滤和聚合。
- 语义边界：内核事件不等于业务链路，需要结合 Kubernetes、服务发现和应用遥测。
- 安全边界：采集系统调用、网络和进程事件时，要避免泄露敏感数据。
根据 Cilium eBPF and Cilium 文档，eBPF 能用于高性能网络和安全能力，但在生产中仍需要围绕内核能力、数据路径和运维方式设计边界[3]。
图3：eBPF 采集边界与落地检查清单，对应内核能力、加载权限
与指标、日志、链路追踪如何配合
eBPF 更适合发现底层运行时事实，OpenTelemetry、Prometheus 和日志更适合表达应用语义和长期趋势。两者不是替代关系。
| 问题 | 更适合的信号 | eBPF 的补充价值 |
|---|---|---|
| 某接口慢 | Trace、指标、日志 | 判断是否网络、DNS、系统调用层异常 |
| Pod 网络异常 | 指标、事件、eBPF | 补充连接、丢包和内核路径信息 |
| 进程异常退出 | 日志、事件、eBPF | 捕获 exec、exit、文件和权限行为 |
| 安全可疑行为 | 审计日志、eBPF、安全规则 | 捕获系统调用和进程关系 |
不要用 eBPF 替代应用埋点
如果目标是分析订单流程、用户路径或业务成功率，应用层指标和 tracing 仍然更直接。eBPF 适合补盲区，而不是把所有业务语义从内核事件里反推出来。
小结
eBPF可观测性原理的核心是“在内核事件点采集低层运行时信号，再由用户态系统补充语义并导出”。它适合补网络、进程、系统调用和运行时盲区，但要正视内核版本、权限、性能、数据安全和业务语义边界。生产落地时，建议把 eBPF 作为可观测性平台的一层，而不是唯一信号来源。
原创声明：本文为 CNBPA 云原生社区原创技术内容，非商业转载须注明出处：https://www.cloudnative-tech.com/p/9322/。文中原创图示、架构图和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
参考资料
常见问题
1. eBPF可观测性原理和传统监控有什么区别？
传统监控多从应用、进程或导出器采集指标；eBPF 可以在内核事件点观测网络、系统调用、进程和容器运行时行为。它更接近底层，但需要额外语义映射。
2. eBPF 会不会影响生产性能？
可能会，影响大小取决于采集点、事件频率、过滤逻辑和导出方式。建议从低风险事件开始，设置采样、过滤、限流和 agent 健康指标，不要无差别采集高频路径。
3. Kubernetes 中部署 eBPF agent 需要注意什么？
要关注节点内核版本、容器权限、BPF 文件系统、host namespace、Pod 安全策略和升级兼容性。生产环境应尽量使用成熟项目，并限制 agent 权限范围。
4. eBPF 能替代 OpenTelemetry 吗？
不能简单替代。OpenTelemetry 更适合应用层 trace、metric 和 log 语义；eBPF 更适合补充内核和运行时事件。两者结合能让平台同时看到业务链路和底层行为。
