iostat本身不支持多租户隔离监控，仅反映底层块设备全局i/o；需结合docker inspect、virsh domblklist、lvs等定位租户对应物理设备，并用iostat -dx -p与iotop、cgroup blkio统计交叉验证租户级资源使用及blkio权重效果。
iostat 本身不直接支持多租户资源隔离监控，它只能反映底层块设备（如 /dev/nvme0n1、/dev/sda）的全局 I/O 活动。但在多租户环境（如容器、KVM 虚拟机、LVM 逻辑卷）中，仍可通过组合策略实现有效的资源使用归因与瓶颈定位。
识别租户对应的物理设备路径
多租户共享存储时，关键第一步是明确每个租户实际使用的底层设备：
- 容器场景：用
docker inspect <container> | grep -A 5 Mounts</container>或podman inspect查看挂载源；再通过lsblk -f或findmnt -D追溯到宿主机上的真实块设备（如/dev/nvme0n1p2） - KVM 虚拟机：检查
virsh domblklist <vm></vm>输出，结合ls -l /dev/disk/by-path/映射到物理盘或 LUN - LVM 环境：运行
lvs -o +seg_pe_ranges和pvs，确认 LV 所在 PV 对应的物理磁盘
用 iostat -x 捕获细粒度指标并交叉比对
单独运行 iostat -dx 1 只能看到设备级统计，需结合其他工具完成租户级归因：
- 对目标设备执行
iostat -dx -p <device> 1</device>（例如iostat -dx -p nvme0n1 1），重点关注await、avgqu-sz、r/s、w/s、rkB/s、wkB/s - 同时在另一终端运行
iotop -o -P -a，观察哪些进程（及所属用户/容器）正在产生高 I/O；配合ps -eo pid,user,comm,args --sort=-%mem | head -10辅助识别租户身份 - 若使用 cgroup v1/v2，可查
/sys/fs/cgroup/blkio/<tenant_group>/blkio.io_service_bytes</tenant_group>获取该租户实际读写字节数，与 iostat 的rkB/s/wkB/s总量对比，判断是否占比异常偏高
监控 blkio 权重生效情况（适用于容器/K8s）
当租户通过 blkio.weight 实现 IO 带宽分配时，iostat 不显示权重值，但能验证其效果：
- 在多个租户并发压测时，分别运行
iostat -dx <device> 2</device>，观察各租户对应进程的await是否随权重升高而降低 - 若权重为 800 的租户
await显著低于权重为 200 的租户，说明调度生效；若两者await接近且都飙升，则可能是设备已达吞吐上限，权重失去调节空间 - 注意：权重仅在设备忙时起作用，空闲状态下所有租户均可自由使用带宽，此时 iostat 显示
%util很低，不能说明隔离失效
避免误读 %util 和混淆设备层级
多租户环境下，%util 容易误导判断：
-
%util是设备“有 I/O 活动的时间占比”，对 NVMe/多队列 SSD 参考价值低；即使显示 100%，只要await 且 <code>avgqu-sz未超队列深度（如 64），就未必存在瓶颈 - iostat 默认不显示 LVM 逻辑卷（如
/dev/mapper/vg-tenant1）或容器 overlay 分区，只显示最底层物理设备。不能直接说“tenant1 占用 70% util”，而应说“/dev/nvme0n1上 tenant1 相关进程贡献了约 70% 的读请求” - 若租户使用本地 SSD 缓存（如 dm-cache）、ZFS ARC 或 bcache，iostat 无法区分缓存命中与真实磁盘访问，需结合
cat /proc/diskstats或perf stat -e block:*进一步下钻
