本页目录
先把问题压成可观测问句
第 15 章先把 BPF 的门槛说清。BPF 最值钱的时候，不是“什么都能看”，而是你已经知道自己缺的是哪段证据。
在这之前，BPF 往往只会把复杂度抬高。
别把 BPF 当成高级 printf。面对 malloc、网络收发这类每秒百万次的高频事件，逐条打印明细只会把系统和自己一起拖垮；BPF 真正值钱的地方，是在内核里先就地聚合成 map、直方图或计数，再把结果带回用户态。
BPF 最适合补哪类证据
下面这些情况，更适合考虑 BPF：
- 标准指标和采样已经不够
- 你需要更贴问题本身的事件、分布或关联关系
- 你知道应该挂在哪一层、看什么事件
- 你要的是低开销、定制化观测
这时候 BPF 才会真正发力。
别先写脚本，再回头想自己要验证什么
最常见的错法有四种：
- 因为 BPF 很强，就把它当前置默认工具
- 问题还没定义清楚，就先写脚本抓事件
- 一次性验证问题，结果做成了长期工具工程
- 数据抓了很多，但问句本身还是模糊的
这些错法都不是工具问题，是问题设计没先站住。
什么时候 BPF 值得投入
一般要同时满足这几件事：
- 你已经知道普通指标和标准工具不够了
- 你能写出明确的可观测问句
- 你知道挂点大概在哪
- 你知道自己想要的，是频率、分布、延迟还是关联关系
这几件事站住了，BPF 的投入才划算。
一个最典型的错法：先写脚本，后想问题
现场里一碰到复杂问题，很多人会觉得“这次得上 BPF 了”。
但如果顺序反了，最后很容易变成这样：
- 脚本越来越多
- 事件越抓越细
- 但最核心的问题还是没被问清
更稳的做法是先把问题写成一句可观测问句，再决定事件、挂点和输出形式。
先把问句、挂点和字段写清
先写一句可观测问句
以后上 BPF 前，先写成一句话：
我想知道在什么条件下，哪类事件，以什么频率或延迟分布发生。
这句话写不出来，就先别上。
一次性验证和长期工具分开做
先分清这次是：
- 快速验证
- 一次性分析
- 长期沉淀
这三种目标不同，投入也不同。别一上来就做重型工具化。
还要再防一个很像“写得快”的陷阱：通配符探针。像 kprobe:vfs_* 这种写法表面省事，实际可能瞬间匹配出几百个挂点，既把开销打爆，也会直接撞上 bpftrace 的最大探针数上限。真正落命令前，先用 bpftrace -l 摸底会展开成多少个探针。
BPF 结果默认先服务当前假设
BPF 不是为了收更多数据，而是为了验证当前假设。假设一旦改了，脚本也该跟着改。
定制观测站住以后，再回到完整案例
第 15 章解决的是“定制观测什么时候值得上”。第 16 章接着把前面的方法、层次和工具收回一个完整案例里。