Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

了解 Workload Factory for EDA 中的延迟监控

贡献者 netapp-sineadd
PDF

Workload Factory for EDA 中的延迟监控可帮助您查找和修复 FSx for ONTAP 卷中的性能减慢问题。它使用 CloudWatch 指标跟踪读取和写入延迟，并自动分析数据以帮助确定性能问题的原因。

延迟监控的工作原理

延迟分析收集连接到您的 AWS 帐户的所有 FSx for ONTAP 卷上的读取和写入活动的 CloudWatch 指标。它会根据定义的限制不断检查这些指标，以便及早发现性能问题。

如果延迟增加，Workload Factory 会自动查看 ONTAP QoS 延迟指标，以确定减速的主要原因。对于涉及数据或集群组件的更复杂问题，您可以运行可选的 AI 分析，提供可能的根本原因，识别受影响的客户端，并提出解决问题的步骤。

警报生成

只有当这些条件在整个选定的时间范围内均为真时，警报才会触发：延迟保持在阈值以上，且 IOPS 保持在阈值以上。同时满足这两个条件可确保仅在系统处理实际工作负载时出现高延迟，从而减少误报。

您可以为以下项配置单独的阈值：

  • 读取操作

  • 写入操作

  • 警告严重程度

  • 严重严重性

所有检测到的事件都会显示在延迟事件表中。如果设置了通知，您还会收到一封电子邮件或 Amazon SNS 消息，其中包含有关受影响卷的详细信息。您可以控制接收通知的频率——每天按文件系统接收，或每 20 分钟接收一次。

了解警报

了解如何触发警报有助于您配置适当的阈值并解释结果。

收集的指标

系统会收集每个卷的以下 CloudWatch 指标：

  • 读取延迟阈值：计算为 1000 * m2/(m1+0.000001)，其中 m1 = DataReadOperations，m2 = DataReadOperationTime

  • 写入延迟阈值：以 1000 * m2/(m1+0.000001) 计算，其中 m1 = DataWriteOperations，m2 = DataWriteOperationTime

警报触发条件

当满足以下所有条件时，将触发警报：

  • 操作类型（读取或写入）超过延迟阈值。

  • 此操作类型超出 IOPS 阈值。

  • 对于配置时间段内的所有数据点，这两种情况都存在。

例如，使用默认警告阈值时，只有当读取延迟超过 6 ms 且读取 IOPS 在 10 分钟时间段内的所有数据点都超过 100 ops/sec 时，读取警报才会触发。

事件严重性

  • 警告事件：表示可能需要注意的延迟升高

  • 关键事件：表示需要立即调查的严重延迟

延迟分析

Workload Factory 提供两个级别的分析，以帮助您解决延迟问题。

基本分析

当延迟事件发生时，Workload Factory 会自动运行基本分析以查找原因。它使用 ONTAP QoS 延迟中心指标来查看哪个组件负责导致速度减慢，例如 FlexCache、容量池、QoS 限制、磁盘、数据、集群或其他子系统。这可以快速识别延迟的来源，而无需手动调查。

备注 只有当链接与 FSx for ONTAP 文件系统关联时，才能看到组件细分。如果没有链接，您仍然可以查看延迟、IOPS 和吞吐量的图形。
备注 ONTAP QoS 分析和 CloudWatch 的延迟值可能略有不同，因为它们以不同的方式收集数据。基本分析使用 ONTAP 数据来确定根本原因。

AI 分析

虽然基本分析可以识别延迟的来源，但涉及数据或集群组件的更复杂情况通常需要更深入的调查。AI 分析通过发现卷过载、配置不当或需要添加更多容量等基本分析可能遗漏的问题，提供更深入的故障排除。

运行 AI 分析时，系统提供：

  • 潜在根本原因：导致延迟问题的详细说明

  • 受影响的客户端：受延迟影响的 EC2 实例名称列表

  • 潜在的补救措施：两个或多个具体措施来解决问题

AI 分析需要在 Workload Factory 设置中提供 Amazon Bedrock 模型 ARN。如果未设置 Bedrock，您仍然可以使用延迟监控和基本自动化分析。