Bpf

BPF 与内核 tracepoint 能在源头观察行为，且占用极小：不加 agent、不重启、不打断正在跑的工作负载。传统剖析意味着装东西、带 flag 重启、或暂停进程——每样都扰动被研究对象，或在生产根本不被允许。BPF 探针挂到跑着的内核上，收走答案就摘掉，工作负载原样归还。 BPF 给的是日志给不了的答案：哪些 syscall 烧时间，哪些文件卡磁盘，TCP 重传聚在哪，全从主机每个进程实时采样。“哪里慢"“现在发生什么”，对的一行命令一分钟，胜过日志考古一小时。 不断流地探测 一个很小的 eBPF 程序挂到某个既有 tracepoint 上，一边累计计数或直方图统计数据，工作负载照常跑。它运行在内核上下文，探针几乎不会成为瓶颈。程序加载前先过验证器——内核检查内存安全与可终止——有 bug 的探针被拒绝，而不是带崩机器。聚合发生在内核 map 里，几百万事件先坍成小直方图再出用户态；常见开销个位数百分比，往往比团队本来就跑着的日志还便宜。 从问题出发，不从工具出发。“哪个进程开文件最多"是一种 trace 形态，“按设备看 p99 磁盘延迟"是另一种，bpftrace 一行命令画廊两种都覆盖，不用写 C。优先高级前端——bpftrace、bcc 工具——真需要定制逻辑再碰 raw BPF；故障时写得出的一行，胜过下周才写完的完美程序。 tracepoint 是更稳定的名字 内核 tracepoint 标记 block I/O、调度、syscall 进出这类事件，名称比裸 kprobe 更不易碎，跨内核升级依旧健壮。kprobe 钉内核函数地址，版本一换就漂；tracepoint 命名内核承诺保持的语义事件，周二补丁重启后同一探针照跑。挂离行为最近的：磁盘问题挂 block，离 CPU 延迟挂调度，“谁调什么"挂 syscall。 ...