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

监控 Workload Factory for EDA 中的卷延迟

贡献者 netapp-sineadd

作为管理 EDA 工作负载的 IT 管理员或 DevOps 工程师,您可以使用延迟分析来监控 FSx for ONTAP 卷的读写延迟。配置警告和关键阈值以尽早检测性能问题。发生事件时,Workload Factory 提供自动化的基本分析,您可以选择运行 AI 代理分析,了解根本原因详细信息、受影响的客户端和建议的补救步骤。

概述

延迟分析收集与您的 AWS 凭据关联的所有 FSx for ONTAP 卷上的读取和写入操作的 CloudWatch 指标。当配置时间范围内的所有数据点都超过延迟阈值和 IOPS 阈值时会生成警报。这通过确保在实际负载下保持较高的延迟来减少误报。您可以查看所有检测到的事件,如果您已配置通知,则会收到电子邮件或 Amazon SNS 通知,其中包含有关受影响卷的详细信息。

检测到事件时,Workload Factory 使用 ONTAP QoS 延迟中心指标运行基本分析,以确定主要延迟因素(例如,FlexCache、容量池、QoS 限制、磁盘、数据、集群或其他子系统)。然后,您可以"分析延迟趋势"使用交互式图表。

对于数据和集群场景,您可以选择运行 AI 代理分析,以获取详细的根本原因解释、受影响的 EC2 客户端列表以及建议的修复步骤。

要求

要使用延迟监控和分析功能,请确保满足以下要求:

AWS凭证和权限

您必须将 AWS 凭据添加到具有读/写权限的 Workload Factory。延迟监控功能需要访问与您的 AWS 凭据关联的所有 FSx for ONTAP 卷的 CloudWatch 指标。

Basic 模式和 Read-only 模式权限不支持延迟监控。

如果您尚未配置 AWS 凭据,请参见 "添加 AWS 凭据"

FSx for ONTAP文件系统

您需要在 AWS 环境中至少部署一个带有卷的 FSx for ONTAP 文件系统。延迟监控功能会自动收集与您配置的 AWS 凭据相关联的所有卷的指标。

链接到 FSx for ONTAP

要查看基本分析见解,您必须将链接与 FSx for ONTAP 文件系统关联。如果没有链接,事件仍然可以被检测到,但分析提供的见解有限。如果尚未关联任何链接,请在 EDA 中选择*关联链接*,选择是否创建新链接或关联现有链接,然后选择*继续*以自动转到 Storage workloads 中的链接创建页面。

有关创建和关联链接的说明,请参见 "创建链接"

Amazon Bedrock 模型 ARN(可选)

要使用可选的 AI 代理分析功能,您必须在 Workload Factory 设置中提供 Amazon Bedrock 模型 ARN。

有关更多详细信息,请参见 "基本 GenAI 要求"

如果您不配置 Bedrock 模型 ARN,您仍然可以使用延迟监控和自动化基本分析,但 AI 代理分析不可用。

通知配置(可选)

要在检测到延迟事件时接收电子邮件或 Amazon SNS 通知,请在 Workload Factory 设置中配置通知首选项。有关详细信息,请参见 配置延迟通知

了解警报

延迟分析使用 CloudWatch 警报来监控卷性能。了解如何触发警报有助于您配置适当的阈值并解释结果。

收集的指标

系统会收集每个卷的以下 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 时,读取警报才会触发。

事件严重性

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

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

配置延迟阈值

您可以为读取和写入操作配置警告和关键阈值。系统会持续评估阈值,并在满足条件时生成警报。

备注 您必须将关键事件阈值设置为高于警告事件阈值,以确保正确的警报升级。否则,您无法保存配置。
步骤
  1. 使用以下任一方式登录 "主机体验"

  2. 选择菜单 汉堡菜单图标,然后选择 EDA

  3. 选择 Latency 选项卡。

  4. 在 EDA 延迟配置页面中,配置以下阈值:

    • 警告事件

      • 读取延迟阈值:输入延迟阈值(以毫秒为单位)。默认值:6 ms。

      • 读取 IOPS 阈值:以每秒操作数为单位输入 IOPS 阈值。默认值:100 ops/sec。

      • 读取时间范围:输入以分钟为单位的时间范围(5-20)。默认值:10 分钟。

      • 写入延迟阈值:输入以毫秒为单位的延迟阈值。默认值:8 ms。

      • 写入 IOPS 阈值:以每秒操作数输入 IOPS 阈值。默认值:100 ops/sec。

      • 写入时间范围:输入以分钟为单位的时间范围(5-20)。默认值:10 分钟。

    • 严重事件

      • 读取延迟阈值:输入延迟阈值(以毫秒为单位)。默认值:12 ms。

      • 读取 IOPS 阈值:以每秒操作数为单位输入 IOPS 阈值。默认值:100 ops/sec。

      • 读取时间范围:输入以分钟为单位的时间范围(5-20)。默认值:10 分钟。

      • 写入延迟阈值:输入以毫秒为单位的延迟阈值。默认值:15 ms。

      • 写入 IOPS 阈值:以每秒操作数输入 IOPS 阈值。默认值:100 ops/sec。

      • 写入时间范围:输入以分钟为单位的时间范围(5-20)。默认值:10 分钟。

  5. 选择*应用*。

结果

Workload Factory 开始收集与您的 AWS 凭据关联的所有 FSx for ONTAP 卷的延迟指标。指标至少每 20 分钟收集一次。任何超出您配置的阈值的卷都会显示。

查看延迟事件

延迟事件表提供了过去 72 小时内检测到的所有警告和关键事件的集中视图。

  • 仅显示每个卷的最新违规行为。如果某个卷经历了多次违规,则仅显示最近的事件。

  • 事件将在 72 小时后自动删除。

  • 最多显示 200 个事件。随着新事件的添加,旧事件将被删除。

  • 即使没有链接与文件系统关联,也会显示事件。查看基本分析详细信息和运行 AI 代理分析需要链接。

步骤
  1. Latency 选项卡中,查看每个事件的信息,包括:

    • 严重程度:指示事件是 Critical 还是 Warning

    • Volume name:受影响卷的名称

    • Volume ID:受影响卷的 ID

    • 文件系统:包含卷的 FSx for ONTAP 文件系统

    • 中位延迟 (ms):数据泄露期间的中位延迟值

    • % above threshold:延迟超过配置阈值的百分比

    • 检测到时间:检测到违规行为的时间

  2. 要查看延迟事件的详细信息,请在 Severity 列中选择该事件。这将打开该事件的延迟分析面板。

  3. 要对表格进行排序,请选择任意列标题。默认情况下,将首先显示按时间排序的关键事件,然后显示按时间排序的警告事件。

  4. 要关闭一个或多个事件,请在每个事件旁边选择 操作菜单图标 Dismiss

  5. 要向表中添加列,请选择 列图标,选择列,然后选择 Apply

  6. 要分析一段时间内的延迟趋势,请选择一个事件以打开延迟分析面板。使用 Over time 选项卡查看交互式延迟图。有关详细信息,请参阅 "分析延迟趋势"

分析延迟事件

基本分析可帮助您快速确定延迟问题的根本原因,而无需手动调查。当检测到延迟事件时,Workload Factory 会使用 ONTAP QoS 延迟中心指标自动执行基本分析。分析确定了导致延迟的组件并提供了简短的描述。

备注 由于不同的收集方法,ONTAP QoS 分析的延迟值与 CloudWatch 数据之间可能存在轻微差异。基本分析使用 ONTAP 数据进行根本原因识别。

延迟分析面板

严重性 列中选择一个延迟事件,以打开该事件的延迟分析面板。该面板包括提供延迟事件不同视图的选项卡:

  • 概述:显示基本分析结果,显示哪个组件导致了延迟

  • 随着时间的推移:显示具有历史数据的交互式延迟图

概述

概述 选项卡显示自动化基本分析的结果,确定导致延迟的组件:

  • FlexCache:来自 FlexCache 操作的延迟

  • 容量池:来自容量池操作的延迟

  • QoS min:来自 QoS 策略组下限的延迟

  • QoS max:来自 QoS 策略组上限的延迟

  • 磁盘:存储子系统的延迟

  • 数据:来自 WAFL 子系统的延迟,包括 CPU 处理、元数据更新和缓存管理

  • Cluster:内部连接节点的延迟

  • 其他:来自其他子系统(如 NVRAM 和网络)的延迟

如果配置了 Amazon Bedrock 模型 ARN,*概述*选项卡还包括一个选项,用于对数据和群集场景运行 AI 代理分析。如果未配置 Bedrock,则选项卡将显示指向特定文件系统的 Storage workloads 配置页面的链接,您可以在其中配置 Bedrock 访问权限。

随着时间的推移

Over time 选项卡显示一个交互式延迟图表,显示受影响卷随着时间推移的 CloudWatch 延迟指标。该图显示了读取或写入延迟,具体取决于触发事件的警报类型。您可以选择不同的时间范围(1H、3H、12H、24H、72H)来查看不同时间段的延迟行为。

有关使用图形的详细说明,请参见 "分析延迟趋势"

运行 AI-agent 分析

虽然基本分析可以识别延迟源,但涉及数据或集群组件的复杂场景通常需要更深入的调查,以确定具体的根本原因和潜在的修复步骤。AI 代理分析通过识别霸道卷、非最优配置或基本分析无法检测到的横向扩展需求等问题,提供了更深层次的故障排除。

开始之前

在 Workload Factory 设置中配置 Amazon Bedrock 模型 ARN,请参见"基本 GenAI 要求"

关于此任务

运行 AI-agent 分析时,系统会自动刷新基本分析数据,并将其用作 AI-agent 的输入。AI-agent 评估延迟场景并提供:

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

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

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

AI 代理遵循基本分析指南来识别场景,例如:

  • 占用过多资源的卷(用于数据延迟)

  • 非最佳挂载点配置(用于集群延迟)

  • FlexGroup 重新平衡需求(针对集群延迟)

  • 横向扩展要求(用于集群延迟)

步骤
  1. 延迟 选项卡中,找到要分析的事件。

  2. Severity 列中,选择一个延迟事件以打开该事件的分析面板。

    如果没有链接与文件系统关联,则会显示提示,要求您将链接与受影响的文件系统关联。选择提示以重定向到该文件系统的链接设置页面。

  3. 查看 Overview 选项卡以了解基本分析结果并识别延迟源。

  4. 如果延迟源被识别为数据或集群,请选择 分析 以运行 AI-agent 分析。

  5. 查看 AI-agent 分析结果。

  6. 实施建议的修正步骤以解决延迟问题。

  7. 修复后,监控延迟事件表以验证问题已解决。

管理延迟配置

完成初始配置后,您可以编辑阈值。

步骤
  1. Latency 页面中,选择 Edit

  2. 根据需要修改任何阈值。

    备注 确保关键阈值保持高于警告阈值。如果配置的关键阈值低于警告阈值,则系统将显示错误。
  3. 选择 Apply 以保存所做更改。

配置延迟通知

您可以配置电子邮件或 Amazon SNS 通知,以便在检测到延迟事件时接收警报。每次卷突破您配置的阈值时都会发送通知,从而实时了解性能问题。要启用通知,请参见 "配置通知设置"

延迟通知是根据每个文件系统发送的。当文件系统中的一个或多个卷违反延迟阈值时,您会收到列出所有受影响卷的单个通知。

备注 如果受影响的卷超过 10 个,电子邮件将显示前 10 个卷,并指示受影响的其他卷的数量。您可以在 Workload Factory 控制台中查看所有受影响的卷。

通知包括:

  • 文件系统详细信息

  • 违反阈值的卷列表

  • 事件严重性(Warning 或 Critical)

  • 延迟值和阈值比较

  • 直接链接到延迟页面进行调查

通知渠道:

  • 电子邮件:发送到 Workload Factory 通知设置中配置的电子邮件地址

  • Amazon SNS:发布到您配置的 SNS 主题,以便与其他系统集成

最佳实践

在配置和使用延迟分析时,请考虑以下建议:

  • 设置实际阈值:根据您的工作负载要求配置阈值。默认值提供了一个起点,但可能需要根据您的特定环境进行调整。

  • 从警告阈值开始:在微调关键阈值之前,使用警告事件来建立基线性能预期。

  • 仔细考虑时间范围:较短的时间范围(5-10 分钟)可以更快地检测到问题,但可能会生成更多警报。较长的时间范围(15-20 分钟)可减少误报,但可能会延迟检测。

  • 监控趋势:定期查看延迟事件表,以识别可能指示潜在配置问题的模式或反复出现的问题。

  • 协调 IOPS 和延迟阈值:双条件逻辑意味着必须超出两者。设置非常高的 IOPS 阈值也可能会阻止警报,即使延迟有问题。

  • 审查被驳回的事件:定期审查事件被驳回的原因,以确定阈值调整或基础设施改进的机会。

  • 战略性地使用 AI 代理分析:对基本分析推荐的数据和集群场景运行 AI 代理分析。AI 代理分析为需要详细故障排除的复杂性能问题提供更深入的见解。

有关分析延迟趋势的最佳实践,请参见 "图形解释"