你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用 Azure Monitor 分析 Azure 文件存储指标

了解如何监视文件共享性能对于确保应用程序尽可能高效运行至关重要。 本文介绍了如何使用 Azure Monitor 分析 Azure 文件存储指标,例如可用性、延迟和利用率。

请参阅监视 Azure 文件存储,详细了解可为 Azure 文件存储收集的监视数据以及如何使用这些数据。

适用于

管理模型 计费模式 媒体层 冗余 中小型企业 (SMB) 网络文件系统(NFS)
Microsoft.Storage 预配 v2 HDD(标准) 本地 (LRS) 是 否
Microsoft.Storage 预配 v2 HDD(标准) 区域 (ZRS) 是 否
Microsoft.Storage 预配 v2 HDD(标准) 异地 (GRS) 是 否
Microsoft.Storage 预配 v2 HDD(标准) GeoZone (GZRS) 是 否
Microsoft.Storage 预配版本 v1 SSD(高级) 本地 (LRS) 是 是
Microsoft.Storage 预配版本 v1 SSD(高级) 区域 (ZRS) 是 是
Microsoft.Storage 即用即付 HDD(标准) 本地 (LRS) 是 否
Microsoft.Storage 即用即付 HDD(标准) 区域 (ZRS) 是 否
Microsoft.Storage 即用即付 HDD(标准) 异地 (GRS) 是 否
Microsoft.Storage 即用即付 HDD(标准) GeoZone (GZRS) 是 否

支持的指标

Azure 文件存储的指标位于以下命名空间:

  • Microsoft.Storage/storageAccounts
  • Microsoft.Storage/storageAccounts/fileServices

有关 Azure 文件存储的可用指标列表,请查看 Azure 文件存储监视数据参考

有关所有 Azure Monitor 支持指标(包括 Azure 文件存储)的列表,请参阅 Azure Monitor 支持的指标

查看 Azure 文件存储指标数据

可以通过 Azure 门户、PowerShell、Azure CLI 或 .NET 查看 Azure 文件存储指标。

你可以使用 Azure Monitor 指标资源管理器通过其他 Azure 服务中的指标分析 Azure 存储的指标。 从 Azure Monitor 菜单中选择“指标”,打开指标资源管理器。 有关使用此工具的详细信息,请参阅使用 Azure Monitor 指标资源管理器分析指标

对于支持维度的指标,可使用所需的维度值筛选指标。 有关 Azure 存储支持的维度的完整列表,请参阅指标维度

监视工作负载性能

可以使用 Azure Monitor 来分析利用 Azure 文件存储的工作负载。 请执行这些步骤。

  1. Azure 门户中导航到存储帐户。
  2. 在服务菜单中的监视下面,选择指标
  3. 在“指标命名空间”下,选择“文件”。

显示如何选择文件指标命名空间的屏幕截图。

现在,你可以根据要监视的内容选择指标。

监视可用性

在 Azure Monitor 中,当从应用程序或用户的角度来看存在明显错误时,或者在对警报进行故障排除时,可用性指标会很有用。

将此指标与 Azure 文件配合使用时,请务必始终将聚合视为 平均值 而不是 最大值最小值。 使用 Average 会显示请求的百分比是否遇到错误,以及这些请求是否位于 Azure 文件的 SLA 中。

显示 Azure Monitor 中可用事务指标的屏幕截图。

监视延迟

两个最重要的延迟指标是成功 E2E 延迟成功服务器延迟。 这些是开始任何性能调查时要选择的理想指标。 平均值是建议的聚合。 如前所述,最大值和最小值有时可能具有误导性。

在以下图表中,蓝色线指示总延迟(成功 E2E 延迟)所用时间,粉色线指示仅 Azure 文件存储服务(成功服务器延迟)所用时间。

此图表显示具有装载的 Azure 文件共享的本地客户端,例如,从远程位置进行连接的典型用户。 客户端和 Azure 区域之间的物理距离与相应的客户端延迟密切相关,这表示 E2E 与服务器延迟之间的差异。

显示连接到 Azure 文件共享的用户的延迟指标的屏幕截图。

相比之下,下图显示了客户端和 Azure 文件共享位于同一区域中的情况。 请注意,客户端延迟仅为 0.17 毫秒,而第一个图表为 43.9 毫秒。 这说明了为什么必须最大程度地降低客户端延迟,才能实现最佳性能。

显示客户端和 Azure 文件共享位于同一区域时的延迟指标的屏幕截图。

另一个可能表明问题的延迟指示器是成功服务器延迟的频率增加或异常峰值。 这通常是因为超出了预配文件共享的预配上限(或即用即付文件共享的整体规模上限)导致的限制。 请参阅 了解 Azure 文件计费 以及 Azure 文件的可伸缩性和性能目标

有关详细信息,请参阅高延迟、低吞吐量或低 IOPS 故障排除

监视利用率

衡量传输的数据量(吞吐量)或服务操作量 (IOPS) 的利用率指标通常用于确定应用程序或工作负载正在执行的工作量。 事务指标可以确定针对不同时间粒度的 Azure 文件存储服务的操作或请求数。

如果使用流出量流出量指标来确定入站或出站数据量,请使用总和聚合来确定 1 分钟到 1 天时间粒度的传入和传出文件共享的总数据量。 其他聚合(如平均值最大值最小值)仅显示单个 I/O 大小的值。 这就是为什么大多数客户在使用 最大 聚合时通常会看到 1 MiB 的原因。 虽然了解最大、最小甚至平均 I/O 大小可能非常有用,但它无法显示工作负载的使用模式所生成的 I/O 大小的分布。

还可以选择对响应类型(成功、失败、错误)或 API 操作(读取、写入、创建、关闭)“应用拆分”,以显示其他详细信息,如下图所示。

屏幕截图显示了按 API 名称拆分的利用率指标。

要确定工作负载的每秒平均 I/O (IOPS),请先确定一分钟内事务总数,然后将该数字除以 60 秒。 例如,每 1 分钟/60 秒内发生 120,000 个事务 = 2,000 个平均 IOPS。

要确定工作负载的平均吞吐量,请将流入量流出量指标合并得出传输数据总量(总吞吐量),然后将其除以 60 秒。 例如,1 分钟/60 秒的总吞吐量为 1 GiB = 17 MiB 平均吞吐量。

按最大 IOPS 和最大带宽监控使用情况(仅限预配)

预配的文件共享提供了按最大 IOPS 的事务量和按最大 MiB/秒的带宽指标,以显示您的工作负载在高峰时间的表现。 使用这些指标分析工作负荷有助于了解真正的大规模功能,并建立基线来了解更多吞吐量和 IOPS 的影响,以便以最佳方式预配 Azure 文件共享。

下图显示了在 1 小时内生成 263 万个事务的工作负载。 用 263 万个事务除以 3,600 秒,则得出平均值为 730 个 IOPS。

屏幕截图显示了工作负载在 1 小时内生成的事务数。

现在,在将平均 IOPS 与最大 IOPS 时的事务数进行比较时,我们会发现在峰值负载下达到 1,840 个 IOPS,这可以更好地表示工作负载的大规模能力。

屏幕截图显示了最大 IOPS 时的事务数。

选择“添加指标”,以在单个图形合并流入量流出量指标。 结果显示在一小时内传输了 76.2 GiB (78,028 MiB),可以得出在同一小时内的平均吞吐量为 21.67 MiB。

屏幕截图显示如何将流入量和流出量指标合并到单个图中。

最大 MiB/秒的带宽相比,我们在峰值时达到 123 MiB/秒。

屏幕截图显示了最大 MIBS 时的带宽。

通过元数据 IOPS 监视利用率

在 Azure 文件共享上,纵向扩展至 12K 元数据 IOPS。 这意味着,运行包含大量“打开”、“关闭”或“删除”操作的元数据密集型工作负载会增加元数据 IOPS 限制的可能性。 此限制与文件共享的总体预配 IOPS 无关。

由于没有两个元数据密集型工作负荷遵循相同的使用模式,因此客户很难主动监视其工作负荷并设置准确的警报。

为了解决此问题,我们引入了两个特定于元数据的 Azure 文件共享指标:

  • 成功但出现元数据警告:指示元数据 IOPS 即将接近其限制,且如果元数据 IOPS 保持较高或继续增加,可能会受到限制。 这些警告的数量或频率增加表明元数据限流的风险正在增加。

  • 元数据限速成功: 表示元数据 IOPS 已超出文件共享的容量,因此导致限速。 虽然 IOPS 操作从未失败,并且在重试后最终成功,但延迟在限制期间会受到影响。

若要在 Azure Monitor 中查看,请选择 “事务 ”指标,并在响应类型上 应用拆分 。 仅当活动在所选时间范围内发生时,元数据响应类型才会显示在下拉列表中。

下图说明了一个工作负载,它经历了元数据IOPS(事务)的突然增加,触发了“成功但出现元数据警告”,这指示存在元数据限制的风险。 在此示例中,工作负载随后降低了其交易量,防止了元数据节流现象的发生。

显示按响应类型显示的元数据警告的屏幕截图。

如果工作负载遇到“成功但出现元数据警告”或“成功但出现元数据限制”响应类型,请考虑实施以下一个或多个建议:

  • 对于 SSD SMB 文件共享,请启用 元数据缓存
  • 在多个文件共享之间对工作负载进行分配(分片)。
  • 减少元数据 IOPS 的数量。