问题背景
某客户反馈了3台ECS发生云盘IO抖动，体现在IOUtil、IOWait较⾼， 同时提供了同时间的⽹络总流量不超过60Mb及相关负载较低的情况，表示在相关负载较低的情况下不 应该出现云盘IOUtil、IOWait⾼情况，同时此前已引导过该客户升级了云盘类型（使⽤了更⾼ 规格的SSD云盘）。
分析过程
分析过程1
1、复核客户所提供截图发现：当时客户的1分钟粒度⽹络PPS从20+k飙升到100+K，但是对于客户使⽤ 的ECS机型来说，这样的⽹络PPS算下来每秒⼤概在200+左右，并不算⾼，不过相对于之前的未发⽣ IOWait与IOUtil⾼的情况来说确实有所上升，客户反馈业务类型为顺序写类型，所以在写的过程中若这 些IO有落地的话，也是导致IOWait与IOUtil上升的可能点之⼀；
2、业务请求类型是顺序写，顺序写场景的IOUtil可能会出现偏差（由于顺序写的特征并不能代表当时的 磁盘处理性能，有可能仅仅是请求数量较多），所以可以暂时不以IOUtil作为参考；
3、客户提供了其中⼀台机器授权，登陆该机器从⽇志看未发现ECS OS层⾯的异常，但从sar历史记录 user态CPU负载有上所上升，user态⼀般是由⾮内核应⽤程序导致（⽐如hd、中间件等）； 综上分析，由于客户反馈的是3台ECS同时存在异常现象（即不⼤可能是单⼀云盘问题，除⾮3台ECS的 云盘都在同⼀个云盘集群上），从客户提供截图看异常时间点也⽐较接近，加上⽹络PPS同时间有上 升，所以可以基本排除云盘底层问题，⼤概率是客户应⽤⾃身问题，需要定位该问题分两步⾛：
A、由于⽆法确认3台ECS云盘是否在同⼀个云盘集群上，且当时底层⾏为是否存在影响IO的情况，需要 找云盘PD进⾏⼆次确认；
B、客户反馈的时间点都在周三，那么在下次周三之前要准备好捕获现场的环境，我打算⽤atop先分析 看看，因为atop⽐较轻量，分析后有⽅向再针对性的部署dignose-tools进⾏堆栈录制进⾏深⼊分析，看 下客户业务上的影响点在哪⾥。
分析过程2
经过客户部署atop、blktrace后在2020-12-09 21:08 现场复现时成功捕获到相关数据，从客户提供的监 控图看当时客户⼤数据节点bdhbaes09存在IOwait⽑刺：
通过分析atop（秒级）08～09⼀分钟的数据，发现期间并未有IOwait上升的情况（客户涉及三个盘均未 出现）：
通过分析blktrace分析的链路，未发现⾼延迟，耗时较⻓的主要在D2C链路，即ECS内IO到驱动（io vmexit到kvm的交互路径）上，但也未表现出异常(平均耗时为0.2ms)：
通过sar分钟级归档数据确认，均摊在21:07、21:08、21:09期间的IOWait都不⾼：
经过询问客户是否有业务的体现，客户反馈⽆业务异常，故怀疑是客户侧监控数据体现形式不同，客户 反馈监控使⽤的是开源的openfalcon监控，分析openfalcon源码发现，openfalcon的iowait指标是经过 ⾃⼰的公式进⾏计算：
经过分析openfalcon的await计算公式的值来源于nux的diskstat，⽽该函数取值是通过读 取/proc/diskstat的不同域值来进⾏计算（相当于openfalcon⾃⼰实现了⼀个iostat），所以精度、敏感 度⽐借助iostat实现的云监控、atop都要⾼，因此粒度⽐云监控、atop⾼，当捕捉到⼀个（仅1个时）较 ⼤iowait时也会体现在MAX值上（客户反馈的曲线图取值来⾃于MAX）：
结论
- 排查ECS内部IO情况、阿⾥云监控、ESSD云盘底层均未发现异常；
- 由于监控粒度不同，从openfalcon的源码级分析发现openfalcon的IOWait MAX值采集⽐较敏感，在 ⽆业务影响情况下，建议参考AVG（平均值）作为ESSD云盘性能参考；
- openfalcon采集到的个别IOwait较⾼导致MAX值曲线呈现⽑刺，建议atop抓到现场时再进⾏⼆次分 析，⽬前请保持在每周三进⾏导⼊数据时atop的秒级监控（通过设置归档天数可⻓期开着收集），在业 务有体现或者atop显示有IOWait有异常时提单反馈；
