eBPF 运维观测入门
eBPF 能在受验证的前提下把程序挂载到内核或用户态事件上，用于网络、性能、安全和故障观测。它可以提供传统应用日志看不到的低层证据，但不是“零成本、自动找到根因”的万能工具。
一、适合解决什么问题
- 找出某进程在进行哪些系统调用及其耗时；
- 观察 TCP 建连、重传、丢包和延迟；
- 分析 CPU 调度、阻塞 I/O、文件访问和内存行为；
- 在不修改应用代码时补充服务调用与网络可见性；
- 构建运行时安全检测和策略证据。
如果应用已经有清晰 Trace 和日志，先使用现有证据。eBPF 更适合处理内核边界、未知进程、无埋点组件和短暂性能异常。
二、基本组成
- eBPF 程序：在内核验证后运行的小程序。
- Hook：系统调用、kprobe、tracepoint、网络路径、cgroup 或用户态探针等挂载点。
- Map：内核与用户态共享状态的数据结构。
- Verifier：检查程序是否满足安全和可终止要求。
- 用户态加载器：负责加载、附加、读取数据和展示结果。
CO-RE 与 BTF 能改善跨内核版本可移植性，但不代表任意程序在任意内核都兼容。
三、从成熟工具开始
初学阶段优先使用发行版或可信项目提供的 bpftrace、BCC 工具或成熟观测产品，不要一开始就编写内核探针。先在测试环境使用只读脚本观察短时间窗口，并记录工具版本、内核版本和权限。
示例仅用于观察，命令和探针名称以当前工具版本为准：
uname -r
bpftool feature probe
bpftrace -l 'tracepoint:syscalls:sys_enter_*'
四、生产安全边界
- eBPF 往往需要较高权限，加载器和脚本应受代码审查、签名和最小权限控制。
- 高频 Hook、过多堆栈采样和高基数标签可能增加 CPU、内存与输出压力。
- 用户态参数、文件路径和网络载荷可能包含敏感数据，应在采集端过滤。
- 限制观测持续时间和输出大小，先小范围验证再扩大。
- 监控 eBPF 工具自身资源消耗，并准备快速卸载方式。
五、一次网络延迟排查思路
- 用应用指标确认受影响接口、实例和时间窗口。
- 用 Trace 判断延迟发生在应用、数据库还是外部调用。
- 若怀疑网络，观察 TCP 建连、重传、RTT 和队列。
- 若怀疑主机，观察 CPU 调度延迟、磁盘 I/O 和系统调用。
- 将 eBPF 结果与日志、指标和变更时间线关联，而不是孤立解释一张火焰图。
六、常见误区
- 看见内核函数耗时就直接判定根因，没有对照业务和系统指标。
- 在所有节点常驻高频采样，造成新的性能和费用问题。
- 忽略容器命名空间、PID 映射和短生命周期工作负载。
- 使用来源不明的脚本并授予高权限。
- 没有保存内核、工具、过滤条件和时间范围，导致结果不可复现。
七、验收清单
- 工具与目标内核兼容，权限和来源可审计；
- 采集范围、持续时间、频率和数据量受控；
- 敏感字段已过滤；
- 可将进程、容器、Pod、服务和请求上下文关联；
- 结论由多个独立证据支持；
- 观测程序可卸载且不会残留异常状态。