简介：磁盘被打满到底是实在的业务需求量上来了呢？还是有什么野过程在占用 IO？iofsstat 帮你精准定位。
编者按：sysAK（system analyse kit），是龙蜥社区零碎运维 SIG 上面的一个开源我的项目，汇集阿里百万服务器的多年运维教训，针对不同的运维需要提供了一系列工具，造成对立的产品进行服务。本文总结了理论工作中 IO 打满、IO util 高问题的解决教训，将它梳理成一套实践分析方法并造成 iofsstat 工具，集成到了 sysAK 工具集里。以下将由作者带大家一道领略 iofsstat 的独特魅力。
文 / 李光水：零碎运维 SIG 核心成员、毛文安：零碎运维 SIG 负责人。
一、需要背景
常常碰到这样一类问题：磁盘被打满，而后 io utils 高，触发业务监控告警，磁盘应用的是 HDD，呈现问题的时候 iops 曾经被打到几百、bps 也曾经到了上百 MB/s，而后继续个几秒钟完结，而后过个几十秒又呈现，这就造成了业务监控频繁告警。业务方会苦恼，磁盘被打满了到底是实在的业务需求量上来了呢？还是有什么野过程在占用 IO。比方之前碰到一例线上问题，平时都是失常的，忽然某一天发现 IO 高了很多，而后客户想晓得是谁把 IO 整高了，前面通过零碎的各个命令组合 +ftrace 脚本统计，找到了奉献最高的过程来自于一个与业务不相干的容器，他会定时启动，谜个别的做大量的文件拷贝动作。
二、现有工具
在定位问题这类问题的过程中，咱们会通过零碎的现有工具，定位具体的过程、文件或者容器，而后采取下一步措施解决问题，如停掉过程、容器并查看问题景象是否隐没。个别地，如下几类工具会应用比拟频繁：
基于内核 diskstats 衍生的工具，如 iostat、sar- 类命令的 IO 统计性能、vmstat-d
——能够宏观的从整个磁盘角度去统计 io 信息，如统计整盘的 iops、bps
基于内核 proc/$pid/io 衍生的工具，如 pidstat -d
——能够统计到过程奉献的总体 IO
基于 Taskstats 衍生的工具，如 iotop
——能够统计到过程奉献的总体 IO 以及奉献的 iowait
只管零碎为咱们提供了比拟丰盛的工具，但总有这样一种感觉：应用已有的命令，只管晓得磁盘的 IO 高了，但不晓得是哪个过程奉献的；晓得零碎外面的某个过程奉献的 IO 高了，但又不确定这里有多少 IO 是被我关怀的磁盘给生产的，也不晓得这些 IO 都是在操作什么文件，总感觉哪哪都差一点儿。所以总结下来，失去如下几点诉求：
● 在磁盘 IO 被打满的状况下，心愿察看是哪个过程奉献了比拟多的 IO
● 零碎上统计到某个过程奉献了大量的 IO，心愿察看到这些 IO 最终是被哪个磁盘给生产，或者这些 IO 是在拜访哪个文件，如果这个过程是来自某个容器，心愿仍然能够获取拜访的文件以及此过程所在的容器
而本文所介绍的 iofsstat，实现了从过程角度来统计 IO 信息、文件读写信息，满足了之前提到的几个诉求，能够利用到 io utils 高、io 打满类问题的定位中。
三、iofsstat 性能介绍
3.1 统计指定磁盘的过程文件 IO
次要统计某过程对某文件奉献了多少 IO，对用户出现的指标为过程角度 + 磁盘角度，磁盘角度这个毋庸置疑是为了可能看到磁盘的全貌，过程角度，是更细粒度的，能够看到对应的在这个时刻，各过程的奉献状况（PS：这里并非过程奉献的总和要等于磁盘整体的统计，因为统计的原理不统一，这里能够更多的关注两个角度之间的关联性，如在某一时刻，磁盘统计到高了，这个时候能够看到对应的这个时刻的各个过程的奉献水平），各指标如下：
过程角度：
comm：过程名、pid：过程 id、cnt_rd：读文件次数、bw_rd：读文件 ” 带宽 ”、cnt_wr：写文件次数、bw_wr：写文件 ” 带宽 ”、inode：文件 inode 编号、filepath：文件门路，当在一次采集周期内因为过程拜访文件很快完结状况下，获取不到文件名则为 ”-“。
如过程来自某个容器，在文件名后缀会显示 [containterId:xxxxxx]
磁盘角度：
xxx-stat:r_iops：磁盘总的读 iops、xxx-stat:w_iops：磁盘总的写 iops、xxx-stat:r_bps：磁盘总的读 bps、xxx-stat:w_bps：磁盘总的写 bps、xxx-stat:wait：磁盘均匀 io 提早、xxx-stat:r_wait：磁盘均匀读 io 提早、xxx-stat:w_wait：磁盘均匀写 io 提早、xxx-stat:util%：磁盘 io utils
sysak iofsstat -d vdb1 --fs 1 #距离 1 秒统计一次 vdb 磁盘上的过程读写文件状况
2022/01/19 14:13:48
vda-stat: r_iops w_iops r_bps w_bps wait r_wait w_wait util%
0.00 98.00 0.00 91.5MB/s 946.34 0.00 946.34 93.20
comm pid cnt_rd bw_rd cnt_wr bw_wr inode filepath
dd 55937 0 0 1096 137.0MB/s 9226 /home/data/tfatsf
...
显示后果依照 bw_rd 与 bw_wr 的和做降序排列，如输入后果较多想只看某过程状况下，能够应用 -p PID 只查看指定过程
此性能基于 surftrace 开发，surftrace 是在 ftrace 根底上封装的一系列工具集，用于 trace 内核信息，以后发行版次要蕴含 surftrace、surfGuide 两大工具，前期还将蕴含 pylcc(python libbpf compile collections)。更多详情参考可点击文末 surftrace 我的项目代码链接查看。
3.1.1 过程、磁盘、文件信息
因为简单的 IO 软件栈，从用户态到落盘，IO 经验了不同的数据结构上的变动，同时通过 fs 和 block 之后，IO 的生产者也可能发生变化，因而在现有的条件下，无奈做到不实现内核代码就能够间接获取到这些信息，咱们所关注的信息仍须要在内核中解析某些数据结构体外加推演来获取，像获取文件名、IO 大小、过程信息等，比方咱们通过在 block 层解析每个 io request 就能够获取到相当丰满的信息：
通过这种形式，首先能够捕捉到所有类别的 IO，也必定能够获取 io 对应的文件信息，然而在 buffer io 状况下，须要在内核大动干戈的去轮询所有的 task 的 files strcut 反推失去理论写这个文件的过程，而且一旦过程曾经敞开了这个文件，将会推导不出过程，因而不可取，另外应尽可能的避开内核 ko，防止后续应用上受限于内核版本问题；因而思考 fs 层是否存在可用且稳固不会变动的 tracepoint。
实际上满足性能的需要，只须要获取过程信息、IO 大小、dev 编号、文件 inode 编号就够了，而在文件系统层没有现成的合乎这些需要的 tracepoint，因而思考通过 kprobe_events 去 hook 特定函数；kprobe_events 又绕不开因为不同内核版本，数据结构会不统一，造成输出到 kprobe_events 的表达式不统一的问题，侥幸的是因为 surftrace 曾经帮咱们解决了这个问题，咱们只须要关注 kprobe 之后数据的解析，而无需关注表达式的变动。
3.1.2 如何获取文件门路
通过 3.1.1 曾经获取文件 inode 编号，通过 find -inum 指定磁盘的挂载目录，或者通过 debugfs 形式，获取到文件名，但这种形式不仅耗时间也可能会耗 io；因为曾经获取到了过程信息，接下来能够在 /proc/$pid/fd 过滤出来属于指定磁盘下的文件，而后比对文件的 inode 即可获取文件名，简略高效，但毛病是当比对文件过程中文件拜访完结被 close 掉了，就获取不到文件名了，但这种状况个别在有问题的状况下呈现概率也很低（个别关注的 IO 打满问题根本持续时间也都是秒级别）。
3.2 统计指定磁盘的过程 IO 奉献
次要统计某过程对某磁盘奉献了多少 IO，对用户出现的指标为过程角度 + 磁盘角度，磁盘角度这个毋庸置疑是为了可能看到磁盘的全貌，过程角度，是更细粒度的，能够看到对应的在这个时刻，各过程的奉献状况（PS：这里并非过程奉献的总和要等于磁盘整体的统计，因为统计的原理不统一，这里能够更多的关注两个角度之间的关联性，如在某一时刻，磁盘统计到高了，这个时候能够看到对应的这个时刻的各个过程的奉献水平），各指标如下：
过程角度：
comm：过程名、pid：过程 id、iops_rd：过程奉献的读 iops、bps_rd：过程奉献的读 bps、iops_wr：过程奉献的写 iops、bps_wr：过程奉献的写 bps。
磁盘角度：
同 3.1 节磁盘角度。
sysak iofsstat -d vdb 1 #距离 1 秒统计一次 vdb 磁盘上的过程 io 奉献状况
2022/01/19 12:04:38
vda-stat: r_iops w_iops r_bps w_bps wait r_wait w_wait util%
0.00 118.00 0.00 104.2MB/s 976.82 0.00 976.82 95.60
comm pid iops_rd bps_rd iops_wr bps_wr
[dd] 98675 1 4.0KB/s 259 32.4MB/s
[kworker/u12:0] 91022 1 4.0KB/s 198 167.5MB/s
[jbd2/vdb1-8] 19510 0 0 1 4.0KB/s
...显示后果依照 iops_rd 与 iops_wr 的和做降序排列，如输入后果较多想只看某过程状况下，能够应用 -p PID 只查看指定过程，假如看到的是 kworker 类过程奉献的 io 最高，能够进一步通过 3.1 节性能从 fs 角度来查看是哪个过程、哪个文件的 IO 最多。
3.2.1 实现原理
此性能基于 block 的 tracepoint，可获取到指定磁盘的来自各过程的 IO 详细信息，而后统计每个过程的 iops、bps 奉献。
四、性能开销
iofsstat 实质上是基于 ftrace 的实现，不会引发宕机，能够放心使用，因为应用的 ftrace 根本内核版本稳固，因而对内核版本依赖性也低，性能开销方面，通过统计纯 IO 统计性能（3.2 节）开销单核 1% 以下，文件 IO 统计性能（3.1 节）略微高一点，0.x%～3.x%，还在优化。
五、代码开源
iofsstat 代码将在 3 月中旬开源，敬请期待。
Gitee sysak 代码仓链接：https://gitee.com/anolis/sysak
surftrace 我的项目代码链接：https://github.com/aliyun/sur…
零碎运维 SIG 地址：https://openanolis.cn/sig/sysom
原文链接
本文为阿里云原创内容，未经容许不得转载。