eBPF 可观测性接入前如何划分内核事件、用户态采集和权限范围

eBPF 可观测性接入最容易出现的误区，是把“能在内核里看到事件”理解成“所有处理都应该放进内核”。更稳妥的划分是：内核侧负责在合适的 hook 捕获并过滤事件，用户态负责补全业务语义、符号化、聚合展示和远端导出；权限则单独按加载、读取和网络能力核对。

官方资料：https://ebpf.io/what-is-ebpf/

一、先把观测问题映射到内核事件

第一步不是安装采集器，而是写清楚“要解释哪一种现象”。例如，进程系统调用延迟适合从 syscall 或 tracepoint 入手；想观察某个内核函数的进入和返回，可以考虑 kprobe；想看用户程序的函数边界，则更接近 uprobe。网络路径还要结合 socket、流量方向和部署位置判断 hook。

选择 hook 时保留三个约束：事件必须能回答一个运维问题，字段必须能在内核上下文中安全获得，事件量必须有上限。不要因为某个 hook 覆盖面大，就把所有进程、所有调用栈和所有包元数据都打开。

二、把内核短路径和用户态长流程分开

内核侧适合做过滤、计数、时间戳、少量上下文提取，以及把结果写入 map 或 ring buffer。它不适合承担复杂字符串处理、远程请求、规则热加载或业务标签查询。eBPF 文档把 maps 定义为内核程序与用户态应用共享数据和状态的机制，这正好构成职责交接面。

用户态采集器拿到事件后，再完成进程名和容器标签补全、符号化、去重、批量发送和后端协议转换。这样做的好处是：内核程序更容易通过 verifier，业务字段变化不会频繁改动内核侧，采集器也能单独限速和重启。

一个实用判断是：如果某项逻辑需要访问业务数据库、等待网络、读取复杂配置或频繁改变，就把它放在用户态。内核侧只输出后续决策确实需要的字段，并为 ring buffer、map 大小和事件速率设置上限。

三、按能力拆解权限，而不是直接给 root

权限问题至少分三层：采集器能不能把程序加载并挂到 hook，能不能读取 map 或性能数据，以及它是否还需要额外的网络、进程或主机信息访问。把三层混成“容器需要特权模式”，既难审计，也会扩大故障影响面。

Linux capabilities 文档说明，CAP_BPF 自 Linux 5.8 起用于从过载的 CAP_SYS_ADMIN 中分离 BPF 特权；但这不意味着所有 eBPF 场景只要这一项就够。部署前应把“加载失败”“读不到事件”“标签不完整”分别记录，再给对应能力，而不是一次性打开全部权限。

四、用灰度清单验证接入边界

先选少量节点和少数目标进程，记录四类指标：事件吞吐、丢弃数量、采集器 CPU/内存、缓冲区占用。接着故意回收一项能力，确认失败发生在加载、读取还是元数据补全阶段；这一步能把权限设计从猜测变成可解释的故障矩阵。

上线前还要准备回滚动作：停止用户态采集器、解除 hook、清理 maps，以及恢复原有指标链路。对于跨内核版本或跨容器运行时的环境，先验证目标 hook、verifier 和能力组合，再扩大节点范围。eBPF 的 verifier 能检查程序安全性，但它不会替你判断业务字段是否合规、权限是否过宽或采集成本是否值得。

相关问题

eBPF 程序一定要用 root 加载吗？

不一定。是否需要 root 取决于内核配置、程序类型和所需能力；生产环境应优先核对细粒度 capability 与实际 hook，而不是默认使用特权容器。

为什么能加载程序却读不到完整事件？

加载权限和数据读取、进程元数据读取是不同边界。先检查 map 或 ring buffer 的读取路径，再检查目标命名空间、文件和进程访问范围。

哪些逻辑不应放进 eBPF 内核侧？

需要网络等待、复杂字符串处理、业务数据库查询、频繁变更规则或大规模标签关联的逻辑，应放到用户态采集器。