虚拟化IO latency监控

前言：

Linux的很多监控组件，主要针对IOPS和IO带宽进行监控。很多业务场景下，希望对IO的延迟做监控。单纯的await并不能反映出来IO的延迟具体情况。

例如，ETCD的QPS偏高的时候，latency发生了抖动，长尾效应比较明显。第一反映是IO抖动？还是GC导致？

如果有监控组件，这段时间内，IO latency的抖动和QPS的抖动基本一致，那就比较容易判断是不是IO导致的问题。

分析：

1，QEMU IO

图片选自前文《[linux][storage]Linux存储栈 》

nvme设备的栈没有画出，但是和最左侧的virtio blk设备的栈类似。/dev/nvme0n1设备是直接从PCI/PCI-e上block layer注册的，性能比较好的设备，需要的软件路径越短。

从层次上看，QEMU能够给Guest提供的后端存储的访问大约有几种类型：

a，用户态文件，例如常用的raw和qcow2格式文件。

b，用户态直接使用裸块设备，包括/dev/sdx设备和lvm的logic volume。

c，用户态的网络协议，包括http，iscsi，rbd等。

d，透传scsi generic设备，通过bypass scsi command实现。

e，通过pci passthrough实现。

那么，对于经过QEMU用户态处理的场景，由于所有的Guest的IO请求都需要经过QEMU，就很容易实现对每个IO的latency统计。d场景并非常用场景，e场景目前作者没有想到好办法。

2，block latency histogram

QEMU-2.12开始，实现了对于块设备的latency统计，可以生成对应的数据。

实现逻辑在qemu-2.12/block/accounting.c

大致逻辑：

a，默认没有打开block latency histogram。可以通过qmp动态配置或者关闭。

b，对于Guest的IO请求，如果打开了latency统计，就进行统计。

c，关闭latency统计的化，则清空数据。

3，example

virsh qemu-monitor-command INSTANCEID '{"execute":"x-block-latency-histogram-set","arguments":{"device":"drive-virtio-disk1","boundaries":[10000000,20000000,40000000]}}'

示例中，对virtio disk1进行设置，boundaries 的单位是纳秒（ns）。其中统计的阈值的范围是小于 10000000ns， 10000000ns～ 20000000ns之间， 20000000ns～ 40000000ns之间的IO数量。

virsh qemu-monitor-command INSTANCEID '{"execute":"query-blockstats"}'

通过query-blockstats查询结果。

例如ETCD的长尾效应发生的时候，作者统计到的数据通过json如图，可见写延迟超过80ms的请求占用了一定的比例。虽不能排除GO的GC问题，但是起码说明后端的IO已经是问题了。

4，注意事项

前后两次设置不同的参数，就会清空上一次统计的数据。例如先设置virsh qemu-monitor-command INSTANCEID '{"execute":"x-block-latency-histogram-set","arguments":{"device":"drive-virtio-disk1","boundaries":[10000000,20000000,40000000]}}'

再设置virsh qemu-monitor-command INSTANCEID '{"execute":"x-block-latency-histogram-set","arguments":{"device":"drive-virtio-disk1","boundaries":[10000000,20000000,40000000,80000000]}}'

虽然数据重合，但是QEMU的代码逻辑中没有判断，直接做了清空处理。

另外，设置的 boundaries必须是从小到大的顺序。如果不是按照顺序，QEMU内部实际上设置失败，但是QEMU返回的qmp命令是成功的。就会以为设置成功了，但是没有数据。。。

修复的patch（http://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03868.html）已经mail给maintainer，需要等待maintainer回复。