Azure Monitor を使用して Azure Files のメトリックを分析する
[アーティクル] 08/19/2024
2 人の共同作成者
フィードバック
この記事の内容
ファイル共有のパフォーマンスを監視する方法を理解することは、アプリケーションができる限り効率的に実行されていることを確認するために重要です。 この記事では、可用性、待機時間、使用率などの Azure Files メトリックを、Azure Monitor を使用して分析する方法について説明します。
Azure Files 用に収集可能な監視データとその使用方法の詳細については、「Azure Files の監視 」を参照してください。
適用対象
ファイル共有の種類
SMB
NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS
サポートされるメトリック
Azure Files のメトリックは、こちらの名前空間にあります。
Microsoft.Storage/storageAccounts
Microsoft.Storage/storageAccounts/fileServices
Azure Files で使用可能なメトリックの一覧については、「Azure Files 監視データのリファレンス 」をご覧ください。
すべての Azure Monitor サポート メトリック (Azure Files を含む) の一覧については、「Azure Monitor のサポートされるメトリック 」をご覧ください。
Azure Files のメトリック データを表示する
Azure Portal、PowerShell、Azure CLI、または .NET を使用して、Azure Files メトリックを表示できます。
Azure Monitor メトリックス エクスプローラーを使用して、他の Azure サービスのメトリックと共に Azure Storage のメトリックを分析できます。 メトリックス エクスプローラーを開くには、[Azure Monitor] メニューの [メトリック] を選択します。 このツールの使用方法の詳細については、「Azure Monitor メトリックス エクスプローラーでメトリックスを分析する 」を参照してください。
ディメンションをサポートするメトリックについては、目的のディメンション値でメトリックをフィルター処理できます。 Azure Storage でサポートされるディメンションの完全な一覧については、「メトリックのディメンション 」をご覧ください。
メトリック定義の一覧表示
ストレージ アカウントまたは Azure Files サービスのメトリック定義を一覧表示できます。 Get-AzMetricDefinition コマンドレットを使用します。
この例では、<resource-ID>
プレースホルダーをストレージ アカウント全体のリソース ID または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
$resourceId = "<resource-ID>"
Get-AzMetricDefinition -ResourceId $resourceId
メトリック値を読み取る
ストレージ アカウントまたは Azure Files サービスのアカウント レベルのメトリック値を読み取ることができます。 Get-AzMetric コマンドレットを使用します。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
ディメンションのあるメトリック値を読み取る
メトリックにディメンションが付いている場合、メトリック値を読み取り、ディメンション値をフィルターにしてメトリック値を絞り込むことができます。 Get-AzMetric コマンドレットを使用します。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
$resourceId = "<resource-ID>"
$dimFilter = [String](New-AzMetricFilter -Dimension ApiName -Operator eq -Value "GetFile" 3> $null)
Get-AzMetric -ResourceId $resourceId -MetricName Transactions -TimeGrain 01:00:00 -MetricFilter $dimFilter -AggregationType "Total"
アカウント レベルのメトリック定義を一覧表示する
ストレージ アカウントまたは Azure Files サービスのメトリック定義を一覧表示できます。 az monitor metrics list-definitions コマンドを使用します。
この例では、<resource-ID>
プレースホルダーをストレージ アカウント全体のリソース ID または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
az monitor metrics list-definitions --resource <resource-ID>
アカウント レベルのメトリック値を読み取る
ストレージ アカウントまたは Azure Files サービスのメトリック値を読み取ることができます。 az monitor metrics list コマンドを使用します。
az monitor metrics list --resource <resource-ID> --metric "UsedCapacity" --interval PT1H
ディメンションのあるメトリック値を読み取る
メトリックにディメンションが付いている場合、メトリック値を読み取り、ディメンション値をフィルターにしてメトリック値を絞り込むことができます。 az monitor metrics list コマンドを使用します。
az monitor metrics list --resource <resource-ID> --metric "Transactions" --interval PT1H --filter "ApiName eq 'GetFile' " --aggregation "Total"
Azure Monitor には、メトリックの定義と値を読み取るための .NET SDK が用意されています。 サンプル コード では、さまざまなパラメーターで SDK を使用する方法を示します。 ストレージ メトリックスについては 0.18.0-preview
以降のバージョンを使用する必要があります。
この例では、<resource-ID>
プレースホルダーをストレージ アカウント全体または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
<subscription-ID>
変数をご自身のサブスクリプションの ID に置き換えます。 <tenant-ID>
、<application-ID>
、<AccessKey>
の値を取得する方法のガイダンスについては、ポータルを使って、リソースにアクセスできる Microsoft Entra アプリケーションとサービス プリンシパルを作成する方法 に関する記事をご覧ください。
アカウント レベルのメトリック定義を一覧表示する
次の例は、アカウント レベルでメトリック定義を一覧表示する方法を示しています。
public static async Task ListStorageMetricDefinition()
{
var resourceId = "<resource-ID>";
var subscriptionId = "<subscription-ID>";
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
IEnumerable<MetricDefinition> metricDefinitions = await readOnlyClient.MetricDefinitions.ListAsync(resourceUri: resourceId, cancellationToken: new CancellationToken());
foreach (var metricDefinition in metricDefinitions)
{
// Enumerate metric definition:
// Id
// ResourceId
// Name
// Unit
// MetricAvailabilities
// PrimaryAggregationType
// Dimensions
// IsDimensionRequired
}
}
アカウント レベルのメトリック値を読み取る
次の例は、アカウント レベルで UsedCapacity
データを読み取る方法を示しています。
public static async Task ReadStorageMetricValue()
{
var resourceId = "<resource-ID>";
var subscriptionId = "<subscription-ID>";
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
Microsoft.Azure.Management.Monitor.Models.Response Response;
string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
string endDate = DateTime.Now.ToUniversalTime().ToString("o");
string timeSpan = startDate + "/" + endDate;
Response = await readOnlyClient.Metrics.ListAsync(
resourceUri: resourceId,
timespan: timeSpan,
interval: System.TimeSpan.FromHours(1),
metricnames: "UsedCapacity",
aggregation: "Average",
resultType: ResultType.Data,
cancellationToken: CancellationToken.None);
foreach (var metric in Response.Value)
{
// Enumerate metric value
// Id
// Name
// Type
// Unit
// Timeseries
// - Data
// - Metadatavalues
}
}
多次元メトリック値を読み取る
多次元メトリックの場合、特定のディメンション値に対するメトリック データを読み取る必要がある場合は、メタデータ フィルターを定義する必要があります。
次の例では、多次元をサポートするメトリックについてのメトリック データを読み取る方法を示します。
public static async Task ReadStorageMetricValueTest()
{
// Resource ID for Azure Files
var resourceId = "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}/fileServices/default";
var subscriptionId = "<subscription-ID}";
// How to identify Tenant ID, Application ID and Access Key: https://azure.microsoft.com/documentation/articles/resource-group-create-service-principal-portal/
var tenantId = "<tenant-ID>";
var applicationId = "<application-ID>";
var accessKey = "<AccessKey>";
MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
Microsoft.Azure.Management.Monitor.Models.Response Response;
string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
string endDate = DateTime.Now.ToUniversalTime().ToString("o");
string timeSpan = startDate + "/" + endDate;
// It's applicable to define meta data filter when a metric support dimension
// More conditions can be added with the 'or' and 'and' operators, example: BlobType eq 'BlockBlob' or BlobType eq 'PageBlob'
ODataQuery<MetadataValue> odataFilterMetrics = new ODataQuery<MetadataValue>(
string.Format("BlobType eq '{0}'", "BlockBlob"));
Response = readOnlyClient.Metrics.List(
resourceUri: resourceId,
timespan: timeSpan,
interval: System.TimeSpan.FromHours(1),
metricnames: "BlobCapacity",
odataQuery: odataFilterMetrics,
aggregation: "Average",
resultType: ResultType.Data);
foreach (var metric in Response.Value)
{
//Enumerate metric value
// Id
// Name
// Type
// Unit
// Timeseries
// - Data
// - Metadatavalues
}
}
Azure Monitor を使用して、Azure Files を利用するワークロードを分析できます。 以下の手順に従ってください。
Azure Portal のストレージ アカウントに移動します。
サービス メニューの [監視] の下の [メトリック] を選択します。
[メトリック名前空間] で [ファイル] を選択します。
監視対象に応じてメトリックを選択できるようになりました。
可用性を監視する
Azure Monitor では、可用性 メトリックは、アプリケーションまたはユーザーの観点から明らかに問題がある場合や、アラートのトラブルシューティングを行うときに役立ちます。
Azure Files でこのメトリックを使用する場合は、集計を Max または Min ではなく、常に Average として表示することが重要です。 Average を使用すると、要求の何パーセントにエラーが発生しているか、また、それらが Azure Files の SLA 内におさまっているかどうかを理解するのに役立ちます。
待機時間を監視する
最も重要な 2 つの待機時間メトリックは、[成功した場合の E2E 待機時間] と [成功した場合のサーバー待機時間] です。 これらは、パフォーマンス調査を開始するときに選択するのに理想的なメトリックです。 Average が推奨される集計です。 前述のように、Max と Min は誤解を招く可能性があります。
次のグラフでは、青い線は合計待機時間 (成功した場合の E2E 待機時間) に費やされた時間を示し、ピンクの線は Azure Files サービスでのみ費やされた時間 (成功した場合のサーバー待機時間) を示しています。
このグラフは、オンプレミス環境から Azure ファイル共有をマウントしたクライアント マシンの例です。 これは通常、オフィス、自宅、またはその他のリモートの場所から接続する一般的なユーザーを表します。 クライアントと Azure リージョンの間の物理的な距離が、対応するクライアント側の待機時間と密接に関連していることがわかります。これは、E2E とサーバーの待機時間の違いを表しています。
これに対し、次のグラフは、クライアントと Azure ファイル共有の両方が同じリージョン内にある状況を示しています。 クライアント側の待機時間は、最初のグラフの 43.9 ミリ秒と比較してわずか 0.17 ミリ秒であることに注意してください。 これは、最適なパフォーマンスを実現するためには、クライアント側の待機時間を最小限に抑えることが不可欠である理由を表しています。
それを表すもう 1 つの待機時間インジケーターは、成功した場合のサーバー待機時間 の頻度の増加または異常な急増が問題であることを示唆している可能性があります。 これは一般的に、標準ファイル共有の Azure Files スケール制限 を超えたことによる、または Azure Files Premium 共有 のプロビジョニング不足による調整が原因です。
詳細については、「待機時間が長い、スループットが低い、または IOPS が低い」のトラブルシューティング のページを参照してください。
使用率を監視する
送信されるデータの量 (スループット) または処理される操作 (IOPS) を測定する使用率メトリックは、一般的に、アプリケーションまたはワークロードによって実行されている作業量を判断するために使用されます。 トランザクション メトリックにより、Azure Files サービスに対する操作または要求の数をさまざまな時間の粒度で確認できます。
エグレス またはイングレス メトリックを使用して受信または送信データの量を調べる場合は、Sum 集計を使用して、ファイル共有との間で送受信されるデータの合計量を 1 分から 1 日の時間粒度で確認します。 Average 、Max 、Min などの他の集計では、個々の I/O サイズの値のみが表示されます。 このため、ほとんどのお客様の場合、Max 集計を使用するときに通常は 1 MiB が表示されます。 それは最大、最小、または平均の I/O サイズについてサイズを理解するには便利ですが、ワークロードの使用パターン別に生成された I/O サイズの分布を表示することはできません。
次のグラフに示すように、応答の種類 (成功、失敗、エラー) または API 操作 (読み取り、書き込み、作成、閉じる) に対して [分割を適用する] を選択して、追加の詳細を表示することもできます。
ワークロードの 1 秒あたりの平均 I/O (IOPS) を確認するには、最初に 1 分間のトランザクションの合計数を調べ、その数を 60 秒で割ります。 たとえば、1 分間に 120,000 トランザクション / 60 秒 = 平均 2,000 IOPS です。
ワークロードの平均スループットを判断するには、イングレス とエグレス のメトリックを合わせて (合計スループット) 送信されたデータの合計量を取得し、60 秒で割ります。 たとえば、1 分間で 1 GiB の合計スループット / 60 秒 = 平均スループット 17 MiB です。
最大の IOPS と帯域幅での使用率を監視する (Premium のみ)
Azure Premium ファイル共有は、プロビジョニング モデルで課金され、プロビジョニングするストレージ容量の GiB ごとに、より多くの IOPS とスループットが提供されるため、多くの場合、最大 IOPS と帯域幅を確認すると便利です。 スループットは、正常に送信されたデータの実際の量を測定します。これに対し、帯域幅は最大データ転送速度を表します。
Azure Premium ファイル共有の場合、最大 IOPS でのトランザクション と最大 MiB/秒での帯域幅 のメトリックを使用して、ピーク時のワークロードによる達成状況を表示できます。 これらのメトリックを使用してワークロードを分析すると、実際の能力を広範囲に理解するだけでなく、Azure Premium ファイル共有を最適にプロビジョニングできるように、スループットと IOPS の増加の影響を理解するためのベースラインを確立するのに役立ちます。
次のグラフは、1 時間にわたって 263 万件のトランザクションを生成したワークロードを示しています。 263 万件のトランザクションを 3,600 秒で割ると、平均 730 IOPS が得られます。
平均 IOPS と最大 IOPS でのトランザクション を比較すると、ピーク時の負荷で 1,840 IOPS を達成していたことがわかります。これは、ワークロードの能力をより適切に、十分に表しています。
[メトリックの追加] を選択して、イングレス とエグレス のメトリック を 1 つのグラフに結合します。 これは、1 時間に 76.2 GiB (78,028 MiB) が転送されたことを表示しています。これにより、その同じ時間の平均スループットは 21.67 MiB になります。
最大 MiB/秒での帯域幅 と比較すると、ピーク時に 123 MiB/秒を達成していました。
関連するコンテンツ