eBPF 在 Linux 块设备层 (blk-mq) 的深度可观测性工程实践

在现代数据中心，存储 IO 延迟的 P99 抖动往往是性能的隐形杀手。本文从 blk-mq 内核架构出发，系统讲解如何利用 eBPF 的 kprobe、tracepoint 和 BPF maps 实现块设备全链路的实时可观测性——涵盖 IO 提交、调度、设备队列到完成回调的完整数据路径，并给出生产级部署方案与性能开销分析。

一、为什么传统的 blktrace 不够用

Linux 块设备层是存储栈的核心枢纽。从文件系统下来的每一个 bio，都要经过 blk-mq 的软硬件队列分发，最终由 NVMe/SATA/SAS 驱动提交到物理设备。这条路径上的延迟分布，直接决定了数据库、KV 存储和高性能计算应用的尾延迟表现。

传统的 blktrace / blkparse 工具虽然能提供 IO 事件时间戳，但存在三个根本性缺陷：

1. 采样粒度不足：blktrace 按设备全量抓取，在高 IOPS 场景（NVMe SSD 可达 200 万 IOPS）下产生巨大的 trace buffer 开销。
2. 无法聚合计算：blkparse 只能做离线分析，无法实时计算 P99 延迟或检测 IO hang。
3. 缺少上下文关联：blktrace 事件不含进程名、cgroup、文件系统等上层上下文，排障时难以定位根因。

eBPF 的引入彻底改变了这一格局。通过在内核的 IO 路径关键位置动态挂载探针，结合 BPF maps 做内核态聚合统计，我们可以在亚毫秒粒度上实现持续性的块设备可观测性，而不会成为性能瓶颈。

二、blk-mq 架构数据路径解析

深入 eBPF 探针之前，先年建立对 blk-mq 数据路径的清晰认知。整个过程可以分为四个阶段：

2.1 阶段一：Block Layer 入口

// 核心入口：生物请求从文件系统层到达块层
void submit_bio(struct bio *bio)
{
    // 1. 根据请求队列的 ops 分发
    // 2. 走 plug/unplug 批处理逻辑
    // 3. 调用 blk_mq_submit_bio() 进入多队列层
}

这个阶段的关键函数是 blk_mq_submit_bio()。eBPF 探针挂载于此，可以捕获每个 IO 的初始时间戳、操作类型（READ/WRITE/DISCARD）、数据大小和进程上下文。

2.2 阶段二：软件队列到硬件队列

blk-mq 维护一个 struct blk_mq_hw_ctx 数组，每个硬件队列映射一个 CPU 组。blk_mq_dispatch_rq_list() 是软件队列（ctx）向硬件队列（hctx）分发的核心函数。

分发逻辑包含两个关键行为：IO 调度器插入（mq-deadline / bfq / kyber）和 CPU 亲和性选择。通过在此处设置探针，可以观测 IO 在硬件队列中的排队时间和调度顺序。

2.3 阶段三：设备驱动提交

对于 NVMe 驱动，数据路径最终到达 nvme_queue_rq()，该函数构造 SQ 提交队列条目（Submission Queue Entry）写入 MMIO 门铃寄存器：

static blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
                                    const struct blk_mq_queue_data *bd)
{
    struct nvme_ns *ns = hctx->queue->queuedata;
    struct nvme_command *cmd = &ns->ctrl->cmd;

    // 构造 NVMe 命令：opcode, prp, nsid, slba, length
    blk_mq_start_request(rq);
    nvme_submit_cmd(nvmeq, cmd);  // 写入 SQ 并敲门铃
    return BLK_STS_OK;
}

这里可以捕获 IO 离开块层、进入设备驱动的确切时间戳，这是计算设备侧延迟的起点。

2.4 阶段四：中断完成路径

设备通过 MSI-X 中断通知 IO 完成。NVMe 驱动在中断处理程序中轮询完成队列（CQ），调用 blk_mq_complete_request() 沿回调链向上传播：

MSI-X IRQ → nvme_irq() → nvme_process_cq() → blk_mq_complete_request() → req.end_io()

通过在此处设置探针，可以获得 IO 完成的精确时间戳，将其与提交时间戳相减，即可得到单次 IO 的设备侧延迟（device latency）。

三、eBPF 探针布局策略

基于上述数据路径，生产级部署需要在五个关键位置设置探针，构建完整的时间追踪链：

3.1 核心 eBPF C 监控代码

以下是一个完整的 eBPF 探针集，实现从 submit 到 complete 的全链路追踪：

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

#define MAX_DEVICES 256
#define MAX_REQS 65536
#define IRQ_BUCKETS 64

/* ========== 数据结构定义 ========== */

struct io_key {
    u32 dev;       // 设备号 (MAJOR:MINOR)
    u64 rq_ptr;    // request 指针
};

struct io_event {
    u64 submit_ts;    // blk_mq_submit_bio 时刻(ns)
    u64 dispatch_ts;  // dispatch 时刻
    u64 submit_nvme_ts; // nvme_queue_rq 时刻
    u64 complete_ts;  // complete 时刻
    u64 slba;         // NVMe 起始 LBA
    u32 len;          // 数据长度 (bytes)
    u8  op;           // 操作码: 0=Read, 1=Write, 2=Discard
    u16 hwq_id;       // 硬件队列 ID
    u32 pid;          // 发起进程 PID
    u64 cgroup_id;    // cgroup ID
    char comm[16];    // 进程名
};

struct lat_bucket {
    u64 lat_ns;
    u64 count;
    u64 total_ns;
};

/* ========== BPF Maps ========== */

/* 进行中的 IO 请求表：key = rq_ptr, value = io_event */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_REQS);
    __type(key, u64);
    __type(value, struct io_event);
} in_flight SEC(".maps");

/* 每设备的延迟分布直方图 */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_DEVICES);
    __type(key, u32);
    __type(value, struct lat_bucket[IRQ_BUCKETS]);
} lat_hist SEC(".maps");

/* 每 cgroup 的 IO 统计 */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 4096);
    __type(key, u64);
    __type(value, struct {
        u64 read_count;
        u64 write_count;
        u64 read_bytes;
        u64 write_bytes;
        u64 read_lat_total;
        u64 write_lat_total;
    });
} cgroup_stats SEC(".maps");

/* ========== 探针实现 ========== */

/* 探针1：blk_mk_request 入口 - 记录 IO 起点 */
SEC("tp/block/block_bio_queue")
int trace_bio_queue(struct trace_event_raw_block_bio_queue *ctx)
{
    u64 rq_ptr = (u64)ctx->rq;
    struct io_event ev = {};

    ev.submit_ts = bpf_ktime_get_ns();
    ev.op = BPF_CORE_READ(ctx, rwbs[0]);  // 'R' or 'W'
    ev.len = BPF_CORE_READ(ctx, bytes);
    ev.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&ev.comm, sizeof(ev.comm));
    ev.cgroup_id = bpf_get_current_cgroup_id();

    bpf_map_update_elem(&in_flight, &rq_ptr, &ev, BPF_ANY);
    return 0;
}

/* 探针2：IO 分发到硬件队列 */
SEC("tp/block/block_rq_issue")
int trace_rq_issue(struct trace_event_raw_block_rq_issue *ctx)
{
    u64 rq_ptr = (u64)ctx->rq;
    struct io_event *ev = bpf_map_lookup_elem(&in_flight, &rq_ptr);
    if (!ev)
        return 0;

    ev->dispatch_ts = bpf_ktime_get_ns();
    ev->slba = ctx->sector * 512;
    ev->hwq_id = bpf_get_smp_processor_id();

    bpf_map_update_elem(&in_flight, &rq_ptr, ev, BPF_ANY);
    return 0;
}

/* 探针3：blk_mk_complete - IO 完成，计算延迟并更新直方图 */
SEC("tp/block/block_rq_complete")
int trace_rq_complete(struct trace_event_raw_block_rq_completion *ctx)
{
    u64 rq_ptr = (u64)ctx->rq;
    struct io_event *ev = bpf_map_lookup_elem(&in_flight, &rq_ptr);
    if (!ev)
        return 0;

    u64 complete_ts = bpf_ktime_get_ns();
    ev->complete_ts = complete_ts;

    // 计算各段延迟
    u64 total_lat = complete_ts - ev->submit_ts;
    u64 queue_lat = 0, driver_lat = 0;

    if (ev->dispatch_ts)
        queue_lat = ev->dispatch_ts - ev->submit_ts;
    if (ev->dispatch_ts && ev->submit_nvme_ts)
        driver_lat = ev->submit_nvme_ts - ev->dispatch_ts;

    // 更新延迟直方图 (对数分桶)
    u32 dev = ctx->dev;
    struct lat_bucket *buckets = bpf_map_lookup_elem(&lat_hist, &dev);
    if (buckets) {
        u32 bucket = 0;
        u64 lat = total_lat;
        if (lat > 1000) {
            __asm__("bsrq %1,%0" : "=r"(bucket) : "r"(lat));
            bucket = bucket > IRQ_BUCKETS - 1 ? IRQ_BUCKETS - 1 : bucket;
        }
        __sync_fetch_and_add(&buckets[bucket].count, 1);
        __sync_fetch_and_add(&buckets[bucket].total_ns, total_lat);
    }

    // 更新 cgroup 统计
    if (ev->cgroup_id) {
        u64 key = ev->cgroup_id;
        struct {
            u64 read_count, write_count;
            u64 read_bytes, write_bytes;
            u64 read_lat_total, write_lat_total;
        } *cg = bpf_map_lookup_elem(&cgroup_stats, &key);

        if (cg) {
            if (ev->op == 0) {
                __sync_fetch_and_add(&cg->read_count, 1);
                __sync_fetch_and_add(&cg->read_bytes, ev->len);
                __sync_fetch_and_add(&cg->read_lat_total, total_lat);
            } else {
                __sync_fetch_and_add(&cg->write_count, 1);
                __sync_fetch_and_add(&cg->write_bytes, ev->len);
                __sync_fetch_and_add(&cg->write_lat_total, total_lat);
            }
        }
    }

    // 清理
    bpf_map_delete_elem(&in_flight, &rq_ptr);
    return 0;
}

/* 探针4：IO hang 检测 - 超时未完成请求扫描 */
SEC("tp/block/block_rq_insert")
int trace_rq_insert(struct trace_event_raw_block_rq_insert *ctx)
{
    // 可用于追踪 IO 在 plug 层的排队情况
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

3.2 BPF Map 输出格式

上述代码中使用的是 Linux 内核原生 tracepoint（block/block_bio_queue、block/block_rq_issue、block/block_rq_complete），这些 tracepoint 从 Linux 4.1+ 起稳定存在，无需内核版本适配。对于更精确的 NVMe 命令级监控，可以额外挂载 nvme_setup_cmd 和 nvme_complete_rq 这两个 NVMe 专用 tracepoint。

四、数据分析与可视化：从内核直方图到 Prometheus

eBPF 上报的原始数据需要通过用户态程序提取并暴露为可查询的指标。

4.1 Python + BCC 数据读取

#!/usr/bin/env python3
"""blk_mq_latency_exporter - eBPF 块设备延迟数据导出器"""

from bcc import BPF
import time
import struct
from prometheus_client import start_http_server, Histogram, Gauge, Counter

# 加载 eBPF 程序
bpf = BPF(src_file="blk_mq_lat.bpf.c")

# Prometheus 指标定义
io_latency = Histogram(
    'blk_mq_io_latency_seconds',
    'Block device IO latency distribution',
    buckets=[1e-6, 5e-6, 10e-5, 5e-5, 1e-4, 5e-4, 1e-3, 5e-3, 1e-2, 5e-2]
)
iops_gauge = Gauge('blk_mq_device_current_iops', 'Current IOPS per device', ['device'])
queue_depth = Gauge('blk_mq_hwq_depth', 'Hardware queue depth', ['device', 'hwq'])
io_errors = Counter('blk_mq_io_errors_total', 'Total IO errors', ['device', 'type'])

def export_histogram():
    """从 BPF maps 读取延迟直方图并更新 Prometheus 指标"""
    lat_hist = bpf['lat_hist']
    for dev, buckets in lat_hist.items():
        major = (dev >> 20) & 0xFFF
        minor = dev & 0xFFFFF
        dev_name = f"{major}:{minor}"

        for i, bucket in enumerate(buckets):
            if bucket.count > 0:
                # 将 bucket 索引转换为延迟对数值
                lat_upper = 2 ** i * 1e-6  # 秒
                # 上报到对应桶
                for _ in range(min(bucket.count, 100)):  # 采样限流
                    io_latency.observe(lat_upper)

if __name__ == "__main__":
    start_http_server(9101)
    print("blk_mq_latency_exporter running on :9101/metrics")

    while True:
        export_histogram()
        time.sleep(1)

4.2 Grafana 看板关键面板

一个生产环境的 blk-mq 监控看板通常包含以下面板：

• 各设备端到端延迟 P50/P95/P99：基于直方图计算的延迟分位线
• 每 cgroup IOPS 与带宽：用于多租户存储中的 IO 隔离审计
• 硬件队列深度热力图：×设备 × 硬件队列的 2D 热力图，快速发现队列不均衡
• IO Hang 计数器：超过阈值（如 5s）未完成 IO 的告警计数
• 调度器分发延迟：queue_lat = dispatch_ts - submit_ts，用于 IO 调度器调优

五、IO Hang 自动检测与告警

存储 IO hang 是生产环境最常见的高影响故障之一。传统的监控依赖 /proc/diskstats 中的 io_ticks 字段——严重滞后且无法提供单 IO 级别的诊断信息。

5.1 eBPF 实现单 IO 超时检测

/* 位于 io_hang.bpf.c */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_REQS);
    __type(key, u64);     // rq_ptr
    __type(value, u64);   // dispatch_ts
} timed_out SEC(".maps");

/* CONFIG_HZ = 250 时，每 4ms 触发一次软中断 */
SEC("tp/timer/tick_stop")
int detect_hang(struct trace_event_raw_timer *ctx)
{
    u64 now = bpf_ktime_get_ns();
    u64 timeout_ns = 5ULL * 1000 * 1000 * 1000;  // 5s 超时

    u64 rq_ptr, *ts_p;
    struct bpf_iter iter;

    bpf_for_each_map_elem(&in_flight, rq_ptr, ts_p, iter) {
        if (now - *ts_p > timeout_ns) {
            // 上报超时事件：通过 perf buffer 发送到用户态
            struct hang_event *ev;
            ev = bpf_ringbuf_reserve(&hang_rb, sizeof(*ev), 0);
            if (ev) {
                ev->rq_ptr = rq_ptr;
                ev->elapsed_ns = now - *ts_p;
                ev->hwq_id = BPF_CORE_READ(&in_flight, value->hwq_id);
                bpf_get_current_comm(&ev->comm, sizeof(ev->comm));
                bpf_ringbuf_submit(ev, 0);
            }
        }
    }
    return 0;
}

这种方式的优势在于：纳秒级精度、包含完整上下文（进程名、cgroup、操作类型）、零侵入无需修改内核。

5.2 用户态告警处理

# hang_notifier.py - IO hang 告警
import json, subprocess
from datetime import datetime

def handle_hang_event(cpu, data, size):
    ev = bpf["hang_rb"].event(data)
    msg = json.dumps({
        "alert": "IO_HANG_DETECTED",
        "timestamp": datetime.utcnow().isoformat(),
        "rq_ptr": hex(ev.rq_ptr),
        "elapsed_sec": ev.elapsed_ns / 1e9,
        "hwq_id": ev.hwq_id,
        "process": ev.comm.decode(),
        "action": "consider_force_umount_or_reboot"
    })
    # 发送到 Alertmanager / 企业微信 / PagerDuty
    subprocess.run(["curl", "-X", "POST", 
                    "http://alertmanager:9093/api/v1/alerts",
                    "-d", msg])

六、生产部署与性能开销

6.1 性能指标

在 AWS i3en.6xlarge（6 × 3.75TB NVMe）上的实测数据：

开销来源主要是 tracepoint 调用和少量 map 操作。使用 BPF_MAP_TYPE_PERCPU_HASH 可进一步降低锁争用。

6.2 推荐的 BPF Map 类型选择

对于高 IOPS 场景的延迟统计，内推广使用 Per-CPU Map 以避免原子操作：

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_HASH);
    __uint(max_entries, MAX_DEVICES);
    __type(key, u32);
    __type(value, u64[IRQ_BUCKETS]);
} lat_hist_percpu SEC(".maps");

在读取时对每个 CPU 桶的值做求和聚合。对于固定大小的环形缓冲区上报，使用 BPF_MAP_TYPE_RINGBUF（Linux 5.8+），相比 perf_buffer 可减少约 50% 的 CPU 开销。

6.3 内核版本兼容性

• Linux 4.1+：基础 block tracepoint（blktrace 事件同源的 tracepoint）
• Linux 4.17+：NVMe 专用 tracepoint（nvme:nvme_setup_cmd, nvme:nvme_complete_rq）
• Linux 5.8+：BPF_MAP_TYPE_RINGBUF
• Linux 5.15+：bpf_for_each_map_elem 迭代器（用于 IO hang 扫描）

七、进阶方向：从追踪到主动控制

blk-mq 可观测性的下一步是闭环控制——基于 eBPF 采集的实时数据，动态调整 IO 行为：

1. BPF 限流：在 blk_mq_submit_bio() 处实现令牌桶算法，限制特定 cgroup 的 IOPS 突发。
2. 拥塞控制：基于硬件队列深度信号反馈到应用层，实现应用-内核协同的 IO 反压。
3. IO 优先级动态调整：根据 IO 大小和历史延迟，自动调整 ioprio 值，保证小 IO 优先。

这些方向都已在 Linux 6.x 的 cgroup v2 io控制器 和 BPF IO 限流 patch 中逐步落地，eBPF 是实现这些功能的核心工具。

总结

eBPF 在 Linux 块设备层的深度可观测性工程实践，核心在于：

• 全面覆盖：在 IO 全路径的四个阶段部署探针，构建完整的时间追踪链。
• 内核聚合：用 Per-CPU Hash Map 做延迟直方图统计，避免用户态转换开销。
• 关联上下文：同时在探针中捕获 cgroup、进程名、CPU、队列 ID 等多维标签。
• 主动告警：通过 BPF 环形缓冲区和超时扫描实现毫秒级 IO hang 检测。

相比 blktrace 等事后分析工具，eBPF 提供了持续在线、亚毫秒精度、零侵入代价的生产级监控能力。对于运行 NVMe 全闪存储、Ceph、TiKV 等高性能存储系统的团队，这是保障 SLA 不可或缺的基础设施。