监控“黑科技” | XDFS“天眼”技术再升级！

大道云行(以下简称“TaoCloud”)作为新一代全闪软件定义存储行业领导者，随着其存储产品向众多新兴应用场景不断拓展，管理平台也迫切的需要对存储的使用状况进行精准监控。基于此，我们对监控做了全方位调研、系统的梳理设计，从方案敲定到项目实施，再到产品孵化及最终落地，各环节层层把控。监控项目犹如XDFS衍生出的“天眼”，洞察XDFS分布式文件系统内部的压力和延迟。运维人员、客户可做到实时掌握存储的健康状态。

1 监控指标

按照《SRE：Google运维解密》中描述的，分布式系统监控的四类黄金指标是：延迟(Latency)、流量(Traffic)、错误(Errors)、饱和度(Saturation)。

对每一个系统来说，这四类监控指标覆盖了：输入、输出、系统自身。

监控项都需要时序指标异常检测技术，除此之外，它们还有自己的特征：

01  流量类

主要关注点如下：

• 兼容性异常流量:突增或突降、同比环比不一致；

• 历史峰值，以及基于历史流量预测未来流量，主要的技术难点在异常点的干扰；

• 基于鲁棒回归的预测算法，可以不受异常点的影响，精准地预测流量水位值；

• 基于泊松分布的检测算法，可以从概率的角度对流量建模，能够使用简单的恒定阈值来精准地检测流量异常。

02  错误类

常态错误是不可取的，这部分要么应该归入某种业务状态，要么就要分析解决。

• 可归入业务状态：需要看某种状态的走势，就回到流量类的异常走势分析。

• 错误类：要分析发生的原因，并看如何避免问题发生。

错误率突升或者成功率突降代表系统自身的处理逻辑可能存在问题，这类指标的异常检测利用了二项式分布，以解决正常和异常的边界区分问题。

03  延迟类

• 服务接口有超时等待、超时重试相关设置，这部分的时间是底线时间。

• 由于吞吐量 = 流量*平均耗时 ,一旦耗时增大，服务的处理能力会下降，如果正好是高峰期，有无法应对的隐患。

对于耗时大于一定阈值的(尤其是高峰期时)，要做分析和解决，比如典型的数据库慢查询。

04  饱和度类

问：负荷程度如何？

答：由最短板所决定

比如：在内存受限的系统中，即为内存；在I/O受限的系统中，即为I/O。

很多系统在达到100% 利用率之前性能会严重下降，因此合理的利用率是极为重要的一点。

2 技术目标

从技术指标的延迟类出发，期望达成XDFS分布式文件系统的技术目标如下所述：

XDFS分布式文件系统提供目录级别的监控。

监控目录的监控数据类别要覆盖带宽、IOPS、延迟等。

监控数据的细粒度可以追溯到散列在XDFS分布式存储后端存储节点的具体分布。

3 监控的痛点

对于分布式文件系统监控，我们调研了软件内部的辅助插件以及BPF Compiler Collection方案。和我们的设计初衷相比，都存在一定的缺陷。

由于调研方案中存在的缺陷不能满足我们XDFS文件系统对客户的监控承诺，所以果断放弃。

当我们从分布式文件系统的设计原理出发，在不断探索的过程中，发现XDFS框架和我们监控想要实现的效果不谋而合，于是数据聚合逻辑我们借鉴了DHT、监控数据的标识我们借鉴了QUOTA，最终寻找到了答案。

4 软件的架构

监控方案的设计实现主要包含三大模块：监控信息的采集模块、汇总监控信息模块、CLI交互模块。

监控信息采集模块：主要完成请求在分布式文件系统后端存储节点上信息统计。可以记录不同类型请求的带宽、IOPS、延迟等信息。导出的不同share目录数据各自记录，互不影响。

信息汇总模块：将分布式文件系统后端存储上统计的监控内容进行汇总，为输出反馈客户做准备工作。

CLI交互模块：主要做监控数据的输出工作。客户可以直观感受存储的使用情况。

 

5 监控技术

01  兼容性

分布式存储卷的类型有很多，如AFR、EC、TIER、DHT等。不同的卷组织方式不一样，比如TIER可能是由一个AFR卷和EC卷组成的、AFR、EC、DHT又是独立类型的分布式卷，每个卷都会管理一定数量保存数据的后端存储节点。

这给监控的数据结构、以及监控的聚合带来了挑战。

所以，不能冗余的为每一种类型卷设计一套聚合算法。我们采用类金字塔形式的客户端模型，最顶层记录的是标签信息，标签信息具体记录了当前监控数据位置；具体的数据位置记录了后端不同存储节点的监控源数据信息。完美兼容了所有类型卷的信息汇总。

{  all:infos  {infos}, {infos} ... }

{ infos }

{ store1 },{ store2 }

{{type1:info},{type2:info}},{type1:info},{type2:info}}

下图是描述监控数据的结构。

02  独特性

依托软件架构的设计，实现了对分布式集群中share子目录监控，客户端可以根据需求灵活的配置share子目录的个数。

03   细粒度

我们知道，在分布式文件系统中文件的分布经过Hash算法后是随机散列在集群的后端存储节点中，客户端访问某一share目录的时候同样也就会访问到不同的存储节点。触发监控信息汇总，范围覆盖到share子目录所有散列在存储后端节点上的统计信息（带宽、IOPS、延迟等）。下面以图例的形式展示了监控的各个模块的工作逻辑，以及监控的源数据信息。

monitord守护进程进行数据聚合，将后端所有存储节点的监控数据进行汇总。

CLI命令行接口统一进行获取数据。

XDFS管理平台进行数据的展示。

04  高效率

监控功能开启，数据聚合，只有元数据请求流入集群后端存储，不会后端存储造成压力；

监控数据的标记动作是不影响业务IO的情况下进行异步标记。

根据实测，对存储的性能影响几乎忽略不计。

在优秀硬件资源的加持下，对性能的损耗非常低，几乎可以忽略不计。

05  丰富度

监控功能提供了丰富使用配置项：

features.monitor-fops可以指定那些具体的请求被监控。

feature.monitor-dentrys-limit指定分布式文件系统中可以配置监控目录的上限。

features.monitor-latency-measurement指定监控功能是否开启延迟信息的统计。

features.monitor指定监控功能是否开启。

6 监控能效

监控功能在XDFS分布式文件系统中扮演着至关重要的角色，无论是对巡查存储系统健康状态的管理员、运维人员，还是排查问题、优化系统的研发人员，都有很大帮助。

01  系统运维

监控信息的访问方式：

登录到分布式存储server端使用xdfs-monitor-tool查看监控的内容，支持xml格式；

登录XDFS管理平台查看监控条目；

对接Zabbix监控平台，或者其它监控平台。

通过采集存储的监控数据，在Zabbix监控平台和XDFS管理平台，将监控数据抽象成曲线图。

图示是share /dir1子目录在将近18:00的时候WRITE请求的延迟突然增加，之后就会发送告警信息通知管理员。每一个监控share的每一种类型的请求根据监控数据都能抽象成一条曲线图，对此，XDFS监控系统是精准可靠的。

存储监控系统可以提供足够细粒度的参数，监控平台可以根据不同类型的请求，灵活设置告警阈值。图示中给出了WRITE请求，可以配置其他类型的请求监控。

任何达到判定存储系统异常的参数，如图所示：如果配置WRITE延迟超过600为警戒线，在接近18:00的时候会邮件通知管理运维人员。

当服务器发生异常，系统能够快速响应，协助运维人员进行排查。

监控平台设置的告警阈值越严格，越能预判到存储系统可能要发生的故障，将存储中的异常在没有对系统构成威胁之前就及时发现，可尽快的人为介入排查处理隐患。防患于未然，为客户的数据增加了极其安全可靠的保障。

02  助力研发

监控系统为管理运维人员提供便利的同时，对研发也起到帮助作用。

在研发进行故障定位查的时候，监控系统可以提供IO级别的历史监控数据。如监控能效中的系统运维章节的图示中，17:00之前的写请求延迟统计趋于平缓，17:00之后延迟突然增加。如果需要进一步分析延迟增加的原因，需借助profile、metrics等工具。

Profile可以观察到后端存储节点上请求的累计统计数据（Cumulative）和阶段性统计数据（Interval）。

metrics提供的数据可以计算出请求在每一层xlator的延迟情况。

通过如上流程，我们总结如下：我们可以很快的锁定在后端的存储节点上，有什么样类型的请求发生了异常，并且在过去的时间段内持续了多长时间，极大的缩小排查范围、缩短定位排查周期。

7 未来可期

监控功能是XDFS分布式文件系统一个小小的新起点，而非终点。我们在现有监控方案的基础上规划了如下内容：

支撑慢盘坏盘定位：我们可以根据文件系统中的IO延迟情况，设计异常延迟算法，对存储节点上的硬盘进行损坏程度定义，分别是不健康状态、亚健康状态。达到异常状态的存储节点，状态通过监控数据被采集客户端后，然后做进一步的确认、做相关的运维措施。

客户端QOS定向流控：我们在XDFS监控数据中记录不同客户端的任务投递数量，根据存储节点pending队列的深度，并且获取到pending队列中客户端投递任务的占比。将投递任务数量多，并且在pending队列中占比较高的客户端则被选定为限流的对象。

XDFS的分布式文件系统中监控功能扮演着重要的角色，在发挥监控效能的同时，也在为客户提供极致化服务。XDFS持续更新中，敬请期待吧！