必须确认内核字段对齐，因老内核（4.19）仅11列、新内核（5.10+）扩至14列，硬按索引取值易错位；应按设备名匹配后取语义固定位置字段，如sda行第4个非空字段为读完成次数。
直接读/proc/diskstats前必须确认内核字段对齐
Linux /proc/diskstats 是累计值，不是实时速率；直接差值计算会出负数或突增，除非你确保两次采样间隔 ≥100ms 且设备行完全对齐。老内核（如 4.19）只有 11 列，新内核（5.10+）扩展到 14 列，第 4 列（读完成次数）、第 8 列（写完成次数）、第 13 列（weighted_io_ms）才是关键指标。硬按索引取 fields[3] 或 fields[7] 在不同节点上会错位。
正确做法是：用空格切分每行后跳过空字符串，再按设备名匹配整行，最后从固定语义位置取值——比如找到 sda 行后，取第 4 个非空字段为读完成次数。别依赖 strings.Fields 的返回长度做判断，它在多空格时行为不稳定；改用 strings.FieldsFunc(line, unicode.IsSpace) 更可靠。
用weighted_io_ms而非io_ticks评估真实负载压力
io_ticks（第 10 列）单位是 jiffies，受系统 HZ 影响，换算麻烦且不直观；weighted_io_ms（第 13 列）是加权毫秒数，已按 I/O 队列长度加权，数值高直接说明磁盘在排队等服务，更适合做瓶颈判定。
- 容量评估场景（如判断是否触发缩容）：只看
weighted_io_ms差值 / 时间间隔，>500ms/s 持续 2 分钟就值得告警 - 延迟分析不能只靠它：它不区分读/写，也不含存储网络延迟；要拆解，得结合
/sys/block/*/stat中的read_ticks和write_ticks - 容器环境可能无
/proc/diskstats：先os.Stat("/proc/diskstats")，失败则 fallback 到遍历/sys/block/*/stat，过滤掉loop、ram等伪设备
监控上报时http.Client不设超时会堆积连接
把 IO 指标打到 Pushgateway 或自建 API 时，若用默认 http.DefaultClient，一旦目标不可达，goroutine 就卡在 Write 上，几十秒后积压数百连接，最终触发 too many open files 错误，连带影响采集周期和时间戳准确性。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
必须显式配置超时：
client := &http.Client{
Timeout: 5 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
},
}
别省略 Transport 层超时——仅设 Client.Timeout 不覆盖 DNS 解析和 TLS 握手阶段。
细粒度归因必须关联cgroup v2 io.stat与设备统计
node_exporter 只暴露聚合指标，无法回答“哪个 Pod 正在压垮 nvme0n1”。你要做节点级 IO 归因，就得自己读 /sys/fs/cgroup/<pod-uid>/io.stat</pod-uid>，再和 /proc/diskstats 对齐设备主次号。
关键点：
- 必须检测
CGROUP2_SUPER_MAGIC，cgroup v1/v2 混合环境里读错路径会返回空或权限错误 -
io.stat中的bytes是累计值，瞬时速率 = 差值 / 采样间隔；别直接当速率用，否则出现突刺 - Pod UID 要从
/proc/[pid]/cgroup反查，不能硬编码路径；每个 cgroup 目录下需检查type文件确认是否为 v2 - 设备名映射：
dm-0这类名字需通过/sys/block/dm-0/dev读出主次号，再匹配/proc/diskstats第 1–2 列，否则归因失效
实际跑通这四步，才能在 K8s 节点上稳定拿到可归因、可告警、不漂移的磁盘 IO 负载数据。最容易被跳过的，是字段对齐校验和 cgroup v2 的 magic number 检测——它们不出错时不显眼，一出错就是全量指标失真。
