本文介绍了阿里云存储集群中fail-slow实例的检测系统-fail-slow
是一种故障模式，在这种模式下，硬件可能会随着时间的推移持续降低性能而出现非显而易见的故障。虽然大规模部署在数据中心的硬件由于各种原因（包括环境条件和硬件缺陷）而出现故障，但自动检测通常会发现这些问题，从而允许数据中心的值班工程师快速修复。不幸的是，并非所有的硬件不当行为都遵循这条路径，正如之前对 fail-slow 的研究所指出的那样。
Perseus 论文特别关注检测存储设备中的 fail-slow，尽管问题类别会影响各种各样的硬件。如果不解决，fail-slow 实例会显着影响性能和尾部延迟
例如，如果驱动器发生故障，到达该驱动器的数据库写入可能会自动失败或需要很长时间才能完成。对于在将成功返回给客户端之前需要对写入进行多次确认的分布式系统，性能下降尤为严重
硬件的持续加速进一步加剧了这个问题
由于各种原因，故障缓慢现象难以检测。监控固定性能阈值的典型基于 SLO 的方法不够敏感 – 变化的负载可能导致周期性性能回归，即使驱动器是健康的。
识别故障缓慢案例依赖于与应用程序的深度集成，这对于云提供商来说是不可能的（他们通常对用户工作负载的可见性有限）。 Perseus 的论文在几个方面都很新颖，包括不依赖于对其正在监测的工作负载的深入了解来进行检测。
该系统如何运作？
非侵入式：阿里巴巴运行云工作负载，不一定需要（或不想）依赖与客户应用程序的更深入集成。
细粒度：系统识别的故障应该具体说明发生故障的硬件及其原因。
准确：系统应正确识别故障，限制值班工程师浪费的时间。
一般：解决方案应该能够识别同一类别中不同类型硬件的问题（例如 SSD 和 HDD）。
该团队使用部署在阿里云中的守护进程构建了一个驱动器性能数据集，记录了平均延迟时间序列，由机器和驱动器（因为一台机器可以有多个驱动器）作为关键的平均吞吐量。
考虑到这些目标，作者评估了三种不同的检测 fail-slow 实例的技术：阈值过滤、同行评估，以及一种基于先前名为 IASO 的研究的方法
这些技术中的每一种在设计目标方面都有其缺点。
阈值过滤依赖于通过记录写入延迟是否增加超过固定阈值来识别有问题的驱动器。这种方法行不通，因为在重负载下磁盘延迟会周期性地激增，与驱动器故障的相关性很小。
同行评估将同一台机器上的驱动器性能相互比较 – 理论上，如果由同一客户使用，连接到同一台机器的驱动器应该接收类似的工作负载，因此驱动器性能与其邻居的反复偏差将标记驱动器进一步检查。这种方法的主要缺点是依赖微调来进行正确的检测——偏差的持续时间和频率因集群和工作负载而异，需要大量的工程工作才能准确检测失败缓慢事件。
作者描述的最后一种尝试方法是基于 IASO 之前的研究：A Fail-Slow Detection and Mitigation Framework for Distributed Storage Services。这种基于 IASO 的模型依赖于超时——例如，计算 Cassandra 对特定节点的超时次数，然后将其用作一组有问题的设备的代理。由于多种原因，基于 IASO 的方法并不适用，包括它以节点（而不是特定设备）为目标，并且依赖于对工作负载的了解（阿里巴巴的云并非如此）。作者仍然试图通过重用上述同行评估方法的输出来使其适应他们的需要
作者实施的最终方法被赋予代号 Perseus。它依赖于延迟与吞吐量分布的分析
对于一个节点——使用阿里巴巴守护进程收集的指标，作者确定延迟与吞吐量在集群内和数据库节点内可能会有所不同（取决于特定的工作负载）。但是，在特定节点内，延迟和吞吐量之间存在更密切的关系，从而可以分析连接到节点的特定驱动器的性能是否与其相邻节点有偏差。
Perseus 使用节点的延迟与吞吐量数据，遵循四个步骤：对原始数据执行离群值检测、构建回归模型、识别失败缓慢事件以及评估任何检测到的事件的风险。
在第一步中，Perseus 使用了两种算法（DBScan 和主成分分析
用于识别离群数据点。
接下来，系统排除异常值并建立回归模型，生成适合剩余数据点的曲线。
Perseus 然后在时间序列上为节点中的每个驱动器运行此回归模型 – 对于每个驱动器，给定的吞吐量应该产生给定的延迟。然后，系统使用减速比（预期延迟的上限除以实际驱动器延迟）测量给定吞吐量的驱动器实际延迟和预期延迟之间的差异。
最后，系统扫描每个驱动器的减速比时间序列，根据它们的持续时间和严重性（由驱动器与预期性能的差异表示）查找和分类减速事件。反复出现严重减速的驱动器会被标记，以供现场工程师进一步调查。
如何评估研究？
不同方法的 – “精度表明由一种方法识别的驱动器的百分比确实是一个故障缓慢的驱动器。召回是一种方法识别出的真正故障慢速驱动器的百分比。”作者使用 MCC 是因为“它在不平衡数据集上更公平地评估二元分类模型。” Perseus 在这三个指标上优于其他每一种方法。
该论文还评估了 Perseus 设计的不同组成部分。例如，测量异常值移除的影响、主成分分析与 DBScan 的组合，以及用于给定吞吐量的预期延迟上限的阈值（计算减速比的一个因素）。论文中的数据支持他们的决策。
最后，该论文指出移除慢速驱动器对尾部延迟很重要：
本文最后深入探讨了阿里巴巴生产集群中失败的慢速实例的几个根本原因。软件问题导致了大部分故障。
一个示例根本原因发生是因为操作系统错误引入了线程争用
每个驱动器从操作系统接收一个线程来管理 IO，但软件错误会导致多个驱动器共享同一个线程，从而影响性能。
该论文的一个有趣方面是量化单一硬件类别中的少数故障-慢速事件对拖尾延迟的影响（该论文使用 315 个实例的测试数据集）。我也很欣赏确定该方法潜在缺点的研究。例如，Perseus 假设节点上的单个（或几个）驱动器将同时发生故障减速。如果连接到机器的所有驱动器都发生故障（这是可能的），系统可能不会检测到问题。
对于客户工作负载仪器有限的云提供商，这种方法似乎很有前途，尤其是有可能扩展到其他故障缓慢的情况，如内存和网络。与此同时，越来越多地采用商品化基础设施
可能意味着类似 Perseus 的方法仅适用于低级基础设施。