直接使用ebpf_exporter的biolatency.yaml即可开箱监控磁盘读写延迟，因其已集成经压测验证的eBPF实现：基于稳定tracepoint、exp2直方图桶与BTF兼容解析，避免自写代码导致的内核版本适配、事件丢失和桶划分失准等风险。
直接用 ebpf_exporter 的 biolatency.yaml 配置就能开箱统计磁盘读写延迟，不需要自己写 eBPF 程序——除非你要定制指标维度或聚合逻辑。
为什么别急着手写 eBPF C 代码
磁盘 IO 延迟（如 bio 类事件）已有成熟、压测验证过的 eBPF 实现：内核自带的 biosnoop、biolatency 工具背后就是 tracepoint + ringbuf + 直方图 map 的标准模式。自己重写容易踩三类坑：
- 误用
kprobehooksubmit_bio等函数——参数布局随内核版本剧烈变化，5.15+ 中struct bio *字段偏移已不兼容硬编码读取 - 用
perf_event_array而非ringbuf收集延迟样本——在高 IO 场景下 perf event ring buffer 易丢事件，且 Go 侧解析需手动处理 mmap 页边界 - 直方图桶（bucket）用线性划分（0–1ms、1–2ms…）——实际磁盘延迟呈指数分布，
exp2桶（1,2,4,8,16…μs）才能覆盖 NVMe 到 HDD 的全量范围
用 ebpf_exporter 快速跑通 biolatency
它默认加载的 examples/biolatency.yaml 就是为磁盘延迟设计的完整闭环：
- attach 到
tracepoint:block:block_rq_issue和block:block_rq_complete—— 这两个 tracepoint 参数稳定（BTF 可解析），且覆盖所有块设备请求，不依赖具体驱动 - 用
BPF_MAP_TYPE_HASH存储请求开始时间（key =req->cmd_flags & 0xff+req->sector），避免 kprobe 下无法安全获取唯一 request ID 的问题 - 延迟值存入
BPF_MAP_TYPE_ARRAY直方图，桶定义为exp2:12（即 2^0 到 2^11 μs，覆盖 1μs–2048μs） - 输出指标名是
node_disk_io_time_weighted_seconds_total和node_disk_io_time_seconds_total，与 node_exporter 兼容，可直接套用 Grafana 磁盘看板
若必须用 Go 自己加载 biolatency.o，注意三个硬性条件
你得确保 Go 用户态程序能正确加载并读取内核侧生成的延迟数据，否则 metrics 会一直是 0：
立即学习“go语言免费学习笔记（深入）”；
-
CONFIG_DEBUG_INFO_BTF=y必须开启——libbpf-go依赖 BTF 推导struct trace_event_raw_block_rq_issue中rwbs、comm等字段偏移，cilium/ebpf在此场景会静默失败 - eBPF 字节码编译命令必须是
clang -O2 -target bpf -c biolatency.c -o biolatency.o——-O3可能触发 verifier 拒绝“stack limit exceeded”，而-O1会导致某些内联失败，map 更新逻辑异常 - Go 侧读 histogram map 时，不能用
Map.Lookup(key)单点查——要调用Map.GetNextKey(nil, &key)循环遍历所有桶索引，再用Map.GetValue(&key, value)提取计数值；否则只拿到第一个桶
延迟数据从内核到 Prometheus 的链路断点排查
如果 /metrics 页面看不到磁盘延迟指标，按顺序检查：
- 运行
sudo cat /sys/kernel/debug/tracing/events/block/block_rq_issue/enable—— 输出应为1，否则 tracepoint 未启用 - 执行
sudo bpftool prog list | grep biolatency—— 确认程序已加载且 attach 状态为tracepoint - 检查
ebpf_exporter日志是否有failed to load object: invalid argument—— 多半是内核 BTF 缺失或.o文件编译目标错误 - 在 Go 用户态代码中加
bpf_printk到关键路径（如请求发出和完成处），用sudo cat /sys/kernel/debug/tracing/trace_pipe实时确认事件是否触发
真正难的不是把延迟数字算出来，而是让每个 IO 请求都能被稳定、无损地捕获——这取决于 tracepoint 选择、BTF 可用性、ringbuf 大小配置，以及 Go 侧 map 遍历是否阻塞了事件提交路径。
