Hello，大家好！最近呢，程序员小鱼借助数据分析技能，为公司解决了一个算法问题：集群慢盘检测算法。本篇文章小鱼会对集群慢盘检测算法实现的总体流程进行总结，代码及细节涉及公司利益，不便公开，感谢大家的理解和支持 (╹▽╹) ~
一. 探索阶段
在开始数据分析工作前，绘图是非常有效的手段，可以为我们带来宝贵的解决问题的思路。
注：svctm 为平均 io 服务时长，使用一段时间内的 io 服务时长 io_time 除以 io 个数 io_count 计算得到。
下面是小鱼使用 Seaborn 的 pairplot 绘制的 HDD 磁盘变量 io_time io_count svctm 之间的散点图。
通过观察 io_count 和 io_time 之间的散点图我们发现，当 io_count 大于一定值之后，可以找到一条曲线来很好地拟合所有的数据点。
但如果我们使用回归分析的方式，将曲线上方的点视为离群点，那就需要针对不同厂商生产的磁盘训练不同的模型，而且受限于数据方面的限制，没办法获取到所有厂商的硬盘数据。
为此，需要我们转换思维方式，寻求更简洁有效的方案，不妨继续观察一下 io_count 和 svctm 之间的相关性。
在 io_count 比较小的时候，平均 io 服务时长会出现一些 4ms 以上的离群点，而随着 io_count 的增加，磁盘的 svctm 也越来越接近磁盘的能力上限，所有的点基本都分布在一条线上。
这给了我们一个很好的启发，如果统计周期内，同类磁盘中，大家处理 io 数量都差不多，并且能够累积到足够多的 io 时，那么大家的 svctm 也应该相差不大。
而我们的分布式存储集群恰好符合这样的特点，通过 io 均衡算法，业务端的 io 会相对均匀地分配到不同的磁盘。为此，检测周期内，集群磁盘的 svctm 将符合正太分布，中间的值占多数，两边的离群点只占少数。
如此，集群慢盘检测算法的思路也就确定下来了，即通过比较各类磁盘中，每块盘的 svctm 与集群 svctm 水平的大小，来确定慢盘。
二. 检测过程
集群慢盘检测任务属于周期任务，每轮检测中通过比较磁盘的 svctm 与集群 svctm 四分位距内的加权平均值 svctm_avg ，来确定慢盘。默认情况下当某个磁盘的 svctm 达到 svctm_avg 的 N 倍时，在一轮检测中会被判定为慢盘。在需要 提高 / 降低 检测的灵敏度时，可以对 N 进行配置。
下面是一轮完整的慢盘检测过程中，采集 io 信息，计算 svctm svctm_avg 以及判定慢盘的流程图。
慢盘检测算法运行在集群的 Mon Leader 节点，搜集 io 信息并完成慢盘判定。在统计 io 信息时以下磁盘需要豁免：
- 系统盘
- 虚拟机磁盘
- 正在一致性检查、后台初始化、状态异常或者 BBU 电量低的 Raid 盘
- io_time 和 io_count 小于各类磁盘的检测值时，将其豁免
系统盘与用于存储的磁盘 IO 压力不同，其 svctm 无可比性；虚拟机磁盘不是物理盘，无需进行慢盘检测。
此外，io_time 太小时，观测到的仅仅是磁盘在瞬时的表现，svctm 的随机性会比较大；io_count 太小时，svctm 分布不集中。处于以上特殊状态下的 Riad 盘 IO 处理能力会变弱，在统计 svctm 时需要被豁免。
计算 svctm_avg 时，去掉了两端的极值点，计算加权平均值。尤其是慢盘的 svctm 如果不去掉，会将平均值拉到很高，影响慢盘的判定。因此，svctm_avg 的计算使用的是盒图中 “盒子” 部分的数据计算得到的。
图中，35ms 和 40ms 处的点是人为注入了延迟的磁盘 192.168.171.2.sda：
至此，我们已经得到了 svctm_avg ，就可以很轻松地判定本轮检测中的慢盘了。慢盘须同时满足以下 3 个条件：
- svctm 属于离群点
- svctm 大于最小预警值
- svctm 大于 N*svctm_avg
第一个条件，也就是慢盘位于盒须图胡须的上方；第二个条件，最小预警值每类磁盘不同，比如我们统计到的 HDD 磁盘 svctm 基本在 3~4 ms 以内都是正常的；第三个条件中的 N 用于条件检测的灵敏度，对慢盘不敏感的话，可以设置较大的 N 值。
以上就是一轮完整的慢盘检测过程啦，Leader 节点会通过周期任务来循环执行上述检测流程。
三. 慢盘告警
在计算磁盘的 svctm 时，有时就会是出现一些异常的点，比如从 HDD 的 svctm 分布中，5ms~10ms 之间就存在一些离群点。
在散点图中也可以清晰地看到：
对于这些少数的离群点，处理它们最好的办法就是多观测几轮，如果包括本轮在内的前 N 次慢盘检测中，该磁盘有 N*50% 次都被判定为了慢盘，那么才会发出最后的告警。
以下是一次完整的慢盘告警流程图：
当然了，告警邮件不能一直发个没完，24 小时内，检测到慢盘发一次就好了。
四. 总结
我们知道数据和特征对于机器学习任务是非常重要的，好的数据和特征带来的提升往往比调参的效果更好。但实际工作中，受限于时间、成本等各方面的原因，我们应该懂得变通，并不一定要用机器学习算法，或许可以结合自身项目的特殊性，找到更高效、成本更低的解决办法。
网友评论