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

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

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

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

适用于

文件共享类型 SMB NFS
标准文件共享 (GPv2)、LRS/ZRS 是 否
标准文件共享 (GPv2)、GRS/GZRS 是 否
高级文件共享 (FileStorage)、LRS/ZRS 是 是

支持的指标

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 文件存储时,请务必始终将聚合视为平均值,而不是最大值最小值。 使用平均可帮助你了解遇到错误的请求百分比,以及它们是否位于 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 时的利用率和带宽(仅限高级)

由于 Azure 高级文件共享按预配的模型计费(其中预配的每 GiB 存储容量有权获得更多 IOPS 和吞吐量),因此确定最大 IOPS 和带宽通常会非常有用。 吞吐量用于成功传输的实际数据量,而带宽指的是最大数据传输速率。

使用 Azure 高级文件共享时,可以使用 最大 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 时的带宽。