eBPF 可观测性工具怎样选择内核事件与用户态探针

eBPF 可观测性工具并不是“能挂上就用哪个”：要观察调度、网络、文件系统等内核事件，优先从 tracepoint 或 fentry/fexit 开始；要抓某个内核函数的动态细节，再考虑 kprobe/kretprobe；要定位应用函数，则选择 uprobe/uretprobe，若应用暴露了稳定的用户态静态追踪点，USDT 通常比盯着编译符号更容易长期维护。真正的选择标准是探针位置、事件频率、开销和数据粒度，而不是工具名称。

先按观测对象选探针位置

探针挂在内核还是用户态，决定了你能回答什么问题。内核事件适合回答“哪个进程触发了网络、调度或文件系统行为”；用户态探针适合回答“应用的哪个函数、哪个参数造成了延迟”。两者可以串起来，但不应把一套探针当成万能入口。

稳定性与开销：为什么不要一开始就铺满 kprobe

tracepoint 是内核预先定义的事件接口，字段语义更适合跨内核版本维护。fentry/fexit 通过 BPF trampoline 进入函数入口或返回点，通常比 kprobe 更轻，并且能直接拿到参数与返回值。它们适合已经明确函数边界、又希望持续采样的场景。

kprobe/kretprobe 的优势是灵活：可以动态追踪内核函数，适合定位尚未有专用 tracepoint 的问题。但灵活意味着维护成本更高。内核文档提醒，内联函数不一定覆盖所有实例，kretprobe 还可能因为并发返回实例不足而出现未捕获情况。因此它更适合作为短期诊断或小范围灰度手段，而不是默认的全量采集方式。

用户态也有类似取舍。uprobe 可以在应用函数执行时采集参数，适合没有静态追踪点的遗留程序；USDT 则把语义和参数契约交给应用发布者，版本升级时不必依赖某个内部函数名。对于持续生产观测，稳定的语义事件通常比“能抓到更多细节”更重要。

按事件频率和数据粒度控制采集范围

同一个工具可以挂很多探针，但不代表应该同时开启。高频系统调用、网络收包或热点函数若每次都把完整上下文送到用户态，成本会迅速转化为 ring buffer 压力、CPU 消耗和下游存储量。更稳妥的顺序是：内核侧先按进程、容器、端口或错误码过滤，再只保留延迟、返回值和必要的关联 ID，最后在用户态聚合。

# 先确认当前内核是否具备目标探针与 BTF 能力
bpftool feature probe kernel | grep -E 'BPF_PROG_TYPE_TRACING|BTF'
# 只在灰度节点验证功能，避免把高频事件直接铺到全量集群
bpftool prog show

如果你需要“某类事件发生了多少次”，tracepoint 加计数器通常足够；如果你需要“哪个函数参数导致一次慢请求”，才值得进入 fentry/fexit 或 uprobe。数据粒度越细，越要把采样比例、过滤条件和丢失计数写进运行手册。

上线前的最小检查清单

1. 先确认目标挂点：事件、内核函数、用户态函数还是 USDT。
2. 记录目标内核、BTF、架构和二进制符号条件，不能只在开发机验证。
3. 在灰度节点看命中率、丢失事件、ring buffer 使用率和 CPU 增量。
4. 为 kprobe、uprobe 设退出条件：函数改名、内联变化或二进制升级就重新评估。

行业工具正在把 eBPF 采集接入更统一的可观测性管道，但“零代码改动”并不等于零运维成本。OpenTelemetry 的 eBPF profiling agent 面向 Linux 持续采样，仍需要你明确采样范围、数据出口和资源上限。

常见问题

tracepoint 和 kprobe 应该怎么选？

能用稳定 tracepoint 回答问题时优先 tracepoint；只有需要未暴露的函数细节，或正在定位特定内核路径时，再使用 kprobe。

uprobe 能代替应用埋点吗？

它可以在不改代码的前提下观察函数，但依赖二进制符号和 ABI。长期稳定的业务语义更适合由应用发布 USDT 或保留正式埋点。

为什么探针命中数和请求数对不上？

可能是函数内联、返回实例不足、过滤条件不同或 ring buffer 丢失。先对照探针类型和丢失计数，不要直接把差异归因于业务漏报。

参考资料：https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_KPROBE/、https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_TRACING/、https://opentelemetry.io/docs/concepts/signals/profiles/、https://docs.kernel.org/trace/kprobes.html。