Microsoft Azure Storage (クラシック) の監視、診断、トラブルシューティング

このガイドでは、Azure Storage Analytics、Azure Storage クライアント ライブラリでのクライアント側のログ記録、その他のサード パーティ製ツールなどの機能を使用して、Azure Storage 関連の問題を特定、診断、トラブルシューティングする方法について説明します。

このガイドは、主に、そのようなオンライン サービスの管理を担当する Azure Storage Services と IT 担当者を使用するオンライン サービスの開発者が読むよう意図されています。 このガイドの目標は次のとおりです。

• Azure Storage アカウントの正常性とパフォーマンスを維持するのに役立ちます。
• アプリケーションの問題または問題が Azure Storage に関連しているかどうかを判断するのに役立つ必要なプロセスとツールを提供します。
• Azure Storage に関連する問題を解決するための実用的なガイダンスを提供します。

概要

クラウド環境でホストされている分散アプリケーションでの問題の診断とトラブルシューティングは、従来の環境よりも複雑になる可能性があります。 アプリケーションは、PaaS または IaaS インフラストラクチャ、オンプレミス、モバイル デバイス、またはこれらの環境の組み合わせでデプロイできます。 通常、アプリケーションのネットワーク トラフィックはパブリック ネットワークとプライベート ネットワークを経由する場合があり、アプリケーションでは、リレーショナル データベースやドキュメント データベースなどの他のデータ ストアに加えて、Microsoft Azure Storage テーブル、BLOB、キュー、ファイルなどの複数のストレージ テクノロジを使用する場合があります。

このようなアプリケーションを正常に管理するには、それらを事前に監視し、それらのアプリケーションとその依存テクノロジのすべての側面を診断してトラブルシューティングする方法を理解する必要があります。 Azure Storage サービスのユーザーは、アプリケーションが予期しない動作の変更 (通常よりも遅い応答時間など) に対して使用するストレージ サービスを継続的に監視し、ログを使用してより詳細なデータを収集し、問題を詳細に分析する必要があります。 監視とログ記録から取得する診断情報は、アプリケーションで発生した問題の根本原因を特定するのに役立ちます。 その後、問題のトラブルシューティングを行い、修復するための適切な手順を決定できます。 Azure Storage は Azure のコア サービスであり、お客様が Azure インフラストラクチャにデプロイする大部分のソリューションの重要な部分を形成します。 Azure Storage には、クラウドベースのアプリケーションでのストレージの問題の監視、診断、トラブルシューティングを簡略化する機能が含まれています。

このガイドの編成方法

「ストレージ サービスの監視」セクションでは、Azure Storage Analytics メトリック (ストレージ メトリック) を使用して Azure Storage サービスの正常性とパフォーマンスを監視する方法について説明します。

「ストレージの問題の診断」セクションでは、Azure Storage Analytics ログ (ストレージ ログ) を使用して問題を診断する方法について説明します。 また、.NET 用ストレージ クライアント ライブラリや Azure SDK for Java など、いずれかのクライアント ライブラリの機能を使用してクライアント側のログ記録を有効にする方法についても説明します。

[ エンドツーエンド トレース ] セクションでは、さまざまなログ ファイルとメトリック データに含まれる情報を関連付ける方法について説明します。

「 トラブルシューティング ガイダンス 」セクションでは、発生する可能性がある一般的なストレージ関連の問題のトラブルシューティング ガイダンスを示します。

Appendices セクションには、ネットワーク パケット データを分析するためのWiresharkや Netmon、HTTP/HTTPS メッセージを分析するための Fiddler など、他のツールの使用に関する情報が含まれています。

ストレージ サービスの監視

Windows のパフォーマンス監視に精通している場合は、ストレージ メトリックは、Windows パフォーマンス モニター カウンターと同等の Azure Storage であると考えることができます。 [ストレージ メトリック] には、サービスの可用性、サービスに対する要求の合計数、サービスに対する成功した要求の割合など、包括的なメトリックセット (Windows パフォーマンス モニター用語のカウンター) が表示されます。 使用可能なメトリックの完全な一覧については、「Storage Analyticsメトリック テーブル スキーマ」を参照してください。 ストレージ サービスで 1 時間ごとまたは 1 分ごとにメトリックを収集および集計するかどうかを指定できます。 メトリックを有効にしてストレージ アカウントを監視する方法の詳細については、「 ストレージ メトリックの有効化とメトリック データの表示」を参照してください。

Azure portalに表示する時間単位のメトリックを選択し、1 時間あたりのメトリックが特定のしきい値を超えるたびに管理者に電子メールで通知するルールを構成できます。 詳細については、「 アラート通知の受信」を参照してください。

Azure Monitor for Storage (プレビュー) を確認することをお勧めします。 Azure Monitor の機能であり、Azure Storage サービスのパフォーマンス、容量、可用性を統合したビューを提供することで、Azure Storage アカウントを包括的に監視できます。 何も有効または構成する必要はありません。事前に定義された対話型グラフやその他の視覚化からこれらのメトリックをすぐに表示できます。

ストレージ サービスはメトリックの収集に最善を尽くしますが、すべてのストレージ操作を記録することはできません。

Azure portalでは、ストレージ アカウントの可用性、合計要求数、平均待機時間数などのメトリックを表示できます。 また、可用性が一定のレベルを下回った場合に管理者に警告するように通知ルールも設定されています。 このデータを表示すると、調査の可能性のある領域の 1 つは、テーブル サービスの成功率が 100% を下回っていることです (詳細については、「 メトリックは、低 PercentSuccess または分析ログ エントリに ClientOtherErrors のトランザクション状態を持つ操作があることを示す 」セクションを参照してください)。

Azure アプリケーションが正常で、期待どおりに実行されていることを確認するには、継続的に監視する必要があります。

• 現在のデータを比較し、Azure Storage とアプリケーションの動作に大きな変化を特定できるようにする、アプリケーションのベースライン メトリックをいくつか確立します。 ベースライン メトリックの値は、多くの場合、アプリケーション固有であり、アプリケーションのパフォーマンス テスト時にそれらを確立する必要があります。
• 分単位のメトリックを記録し、それらを使用して、エラー数や要求率の急増など、予期しないエラーや異常をアクティブに監視します。
• 時間単位のメトリックを記録し、それらを使用して平均エラー数や要求率などの平均値を監視します。
• 「ストレージの問題の診断」セクションで後述するように、診断 ツールを使用して潜在的な問題を調査します。

次の図のグラフは、時間単位のメトリックに対して発生する平均化がアクティビティのスパイクを隠す方法を示しています。 時間単位のメトリックは安定した要求率を示しているように見えますが、分のメトリックは実際に行われている変動を明らかにします。

このセクションの残りの部分では、監視する必要があるメトリックとその理由について説明します。

サービスの正常性の監視

Azure portalを使用して、世界中のすべての Azure リージョンの Storage サービス (およびその他の Azure サービス) の正常性を表示できます。 監視を使用すると、コントロール外の問題が、アプリケーションに使用するリージョンのストレージ サービスに影響しているかどうかをすぐに確認できます。

Azure portalは、さまざまな Azure サービスに影響を与えるインシデントの通知を提供することもできます。

容量の監視

ストレージ メトリックは BLOB サービスの容量メトリックのみを格納します。BLOB は通常、格納されているデータの最大の割合を占めます (書き込みの時点では、ストレージ メトリックを使用してテーブルとキューの容量を監視することはできません)。 BLOB サービスの監視を $MetricsCapacityBlob 有効にしている場合は、このデータをテーブルに表示できます。 ストレージ メトリックは、このデータを 1 日に 1 回記録し、 の RowKey 値を使用して、ユーザー データ (値 data) または分析データ (値 analytics) に関連するエンティティが行に含まれているかどうかを判断できます。 各格納済みエンティティには、使用されているストレージの量 (Capacityバイト単位) と、ストレージ アカウントで使用されているコンテナー () と BLOB (ContainerCountObjectCount) の現在の数に関する情報が含まれています。 テーブルに格納されている$MetricsCapacityBlob容量メトリックの詳細については、「メトリック テーブル スキーマのStorage Analytics」を参照してください。

BLOB などのさまざまなストレージ オブジェクトのサイズを見積もるには、ブログ記事「 Azure Storage の課金 - 帯域幅、トランザクション、容量について」を参照してください。

可用性の監視

ストレージ アカウント内のストレージ サービスの可用性を監視するには、時間単位または分単位のメトリック テーブル (、 $MetricsMinutePrimaryTransactionsTable$MetricsCapacityBlob$MetricsHourPrimaryTransactionsQueue$MetricsMinutePrimaryTransactionsQueue$MetricsHourPrimaryTransactionsTable$MetricsMinutePrimaryTransactionsBlob) の列の値Availabilityを監視する必要があります。 $MetricsHourPrimaryTransactionsBlob Availability列には、行によって表されるサービスまたは API 操作の可用性を示すパーセンテージ値が含まれています (RowKey行にサービス全体または特定の API 操作のメトリックが含まれているかどうかを示します)。

100% 未満の値は、一部のストレージ要求が失敗していることを示します。 エラーの種類が異なる要求の数 (ServerTimeoutError など) を示すメトリック データ内の他の列を調べると、失敗する理由を確認できます。 サービスがパーティションをより適切な負荷分散要求に Availability 移動する一方で、一時的なサーバー タイムアウトなどの理由により、一時的に 100% を下回ると予想されます。クライアント アプリケーションの再試行ロジックでは、このような断続的な条件を処理する必要があります。 「ログに記録された操作と状態メッセージ」Storage Analytics記事には、ストレージ メトリックの計算に含まれるトランザクションの種類がAvailability一覧表示されます。

Azure portalでは、サービスが指定したしきい値を下回った場合Availabilityに通知するアラート ルールを追加できます。

このガイドの 「トラブルシューティング ガイダンス 」セクションでは、可用性に関連する一般的なストレージ サービスの問題について説明します。

パフォーマンスの監視

ストレージ サービスのパフォーマンスを監視するには、時間単位と分単位のメトリック テーブルから次のメトリックを使用できます。

• と AverageServerLatency 列のAverageE2ELatency値は、ストレージ サービスまたは API 操作の種類が要求の処理に使用する平均時間を示します。 AverageE2ELatency は、要求の読み取りと応答の送信にかかった時間と、要求の処理にかかった時間 (したがって、要求がストレージ サービスに到達した後のネットワーク待機時間を含む) を含むエンドツーエンドの待機時間の測定値です。 AverageServerLatency は処理時間の測定値であるため、クライアントとの通信に関連するネットワーク待機時間は除外されます。 この 2 つの値の間に大きな違いがある理由については、このガイドの後半の「 Metrics show high AverageE2ELatency and low AverageServerLatency 」セクションを参照してください。
• 列と TotalEgress 列のTotalIngress値は、ストレージ サービスまたは特定の API 操作の種類に対するデータの合計量 (バイト単位) を示します。
• 列の値は、 TotalRequests API 操作のストレージ サービスが受信している要求の合計数を示します。 TotalRequests は、ストレージ サービスが受け取る要求の合計数です。

通常、調査が必要な問題があることを示す、これらの値のいずれかに予期しない変更がないか監視します。

Azure portalでは、このサービスのパフォーマンス メトリックが指定したしきい値を下回るか超えている場合に通知するアラート ルールを追加できます。

このガイドの 「トラブルシューティング ガイダンス 」セクションでは、パフォーマンスに関連する一般的なストレージ サービスの問題について説明します。

ストレージの問題の診断

アプリケーションで問題や問題に気付く方法はいくつかあります。次に例を示します。

• アプリケーションのクラッシュまたは動作停止を引き起こす重大なエラー。
• 前のセクション「 ストレージ サービスの監視」で説明したように、監視しているメトリックのベースライン値からの大幅な変更。
• アプリケーションのユーザーから、特定の操作が想定どおりに完了しなかったか、一部の機能が機能していないことが報告されます。
• アプリケーション内で生成されたエラー。ログ ファイルまたは他の通知方法で表示されます。

通常、Azure ストレージ サービスに関連する問題は、次の 4 つのカテゴリのいずれかに分類されます。

• アプリケーションにパフォーマンスの問題があります。これは、ユーザーによって報告されるか、パフォーマンス メトリックの変更によって明らかになります。
• 1 つ以上のリージョンの Azure Storage インフラストラクチャに問題があります。
• アプリケーションでエラーが発生しています。ユーザーによって報告されるか、監視するエラー数メトリックの 1 つ増加によって表示されます。
• 開発とテスト中に、ローカル ストレージ エミュレーターを使用している可能性があります。ストレージ エミュレーターの使用に特に関連するいくつかの問題が発生する可能性があります。

次のセクションでは、これら 4 つのカテゴリの各問題を診断してトラブルシューティングするために従う必要がある手順について説明します。 このガイドの後半の 「トラブルシューティング ガイダンス 」セクションでは、発生する可能性がある一般的な問題について詳しく説明します。

サービス正常性の問題

サービス正常性の問題は通常、コントロールの外にあります。 Azure portalは、ストレージ サービスを含む Azure サービスに関する進行中の問題に関する情報を提供します。 ストレージ アカウントの作成時にストレージの Read-Access Geo-Redundant を選択した場合、プライマリの場所でデータが使用できなくなった場合、アプリケーションはセカンダリの場所の読み取り専用コピーに一時的に切り替えることができます。 セカンダリから読み取りを行うには、アプリケーションでプライマリストレージとセカンダリストレージの場所を切り替え、読み取り専用データを使用して機能制限モードで動作できる必要があります。 Azure Storage クライアント ライブラリを使用すると、プライマリ ストレージからの読み取りが失敗した場合にセカンダリ ストレージから読み取ることができる再試行ポリシーを定義できます。 また、アプリケーションでは、セカンダリの場所のデータが最終的に一貫性を持っていることを認識する必要があります。 詳細については、 ブログ記事「Azure Storage 冗長オプション」および「読み取りアクセス geo 冗長ストレージ」を参照してください。

パフォーマンスの問題

アプリケーションのパフォーマンスは、特にユーザーの観点から主観的な場合があります。 そのため、パフォーマンスの問題が発生する可能性がある場所を特定するために、ベースライン メトリックを使用できるようにする必要があります。 多くの要因が、クライアント アプリケーションの観点から Azure ストレージ サービスのパフォーマンスに影響を与える可能性があります。 これらの要因は、ストレージ サービス、クライアント、またはネットワーク インフラストラクチャで動作する可能性があります。したがって、パフォーマンスの問題の発生元を特定するための戦略を持つことが重要です。

メトリックからパフォーマンスの問題の原因の可能性が高い場所を特定したら、ログ ファイルを使用して詳細情報を見つけ、問題をさらに診断してトラブルシューティングできます。

このガイドの後半の 「トラブルシューティング ガイダンス 」セクションでは、発生する可能性がある一般的なパフォーマンス関連の問題について詳しく説明します。

エラーの診断

アプリケーションのユーザーは、クライアント アプリケーションによって報告されたエラーを通知することがあります。 ストレージ メトリックは、NetworkError、ClientTimeoutError、AuthorizationError など、ストレージ サービスのさまざまなエラーの種類の数も記録します。 ストレージ メトリックはさまざまなエラーの種類の数のみを記録しますが、サーバー側、クライアント側、およびネットワーク ログを調べることで、個々の要求に関する詳細を取得できます。 通常、ストレージ サービスによって返される HTTP 状態コードは、要求が失敗した理由を示します。

次のリソースは、ストレージ関連の状態とエラー コードを理解するのに役立ちます。

• 一般的な REST API エラー コード
• Blob Service エラー コード
• キュー サービスのエラー コード
• Table Service エラー コード
• ファイル サービスのエラー コード

ストレージ エミュレーターの問題

Azure SDK には、開発ワークステーションで実行できるストレージ エミュレーターが含まれています。 このエミュレーターは、Azure ストレージ サービスのほとんどの動作をシミュレートし、開発とテスト中に役立ちます。これにより、Azure サブスクリプションと Azure ストレージ アカウントを必要とせずに、Azure ストレージ サービスを使用するアプリケーションを実行できます。

このガイドの 「トラブルシューティング ガイダンス 」セクションでは、ストレージ エミュレーターを使用して発生する一般的な問題について説明します。

ストレージ ログ ツール

ストレージ ログは、Azure ストレージ アカウント内のストレージ要求のサーバー側のログ記録を提供します。 サーバー側のログ記録を有効にしてログ データにアクセスする方法の詳細については、「 記憶域ログの有効化とログ データへのアクセス」を参照してください。

.NET 用ストレージ クライアント ライブラリを使用すると、アプリケーションによって実行されるストレージ操作に関連するクライアント側のログ データを収集できます。 詳細については、「 .NET Storage クライアント ライブラリを使用したクライアント側のログ記録」を参照してください。

ネットワーク ログ ツールの使用

クライアントとサーバーの間のトラフィックをキャプチャして、クライアントとサーバーが交換しているデータと基になるネットワーク条件に関する詳細情報を提供できます。 便利なネットワーク ログ ツールは次のとおりです。

• Fiddler は、HTTP および HTTPS 要求および応答メッセージのヘッダーとペイロード データを調べるために使用できる無料の Web デバッグ プロキシです。 詳細については、「 付録 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャ」を参照してください。
• Microsoft Network Monitor (Netmon) と Wireshark は、さまざまなネットワーク プロトコルの詳細なパケット情報を表示できる無料のネットワーク プロトコル アナライザーです。 Wiresharkの詳細については、「付録 2: Wiresharkを使用したネットワーク トラフィックのキャプチャ」を参照してください。
• 基本的な接続テストを実行して、クライアント コンピューターがネットワーク経由で Azure ストレージ サービスに接続できることをチェックする場合は、クライアントの標準 ping ツールを使用してこれを行うことはできません。 ただし、tcping ツールを使用して接続をチェックできます。

多くの場合、ストレージ ログとストレージ クライアント ライブラリからのログ データで問題を診断するのに十分ですが、シナリオによっては、これらのネットワーク ログ ツールが提供できるより詳細な情報が必要になる場合があります。 たとえば、Fiddler を使用して HTTP メッセージと HTTPS メッセージを表示すると、ストレージ サービスとの間で送受信されるヘッダーデータとペイロード データを表示できます。これにより、クライアント アプリケーションがストレージ操作を再試行する方法を調べることができます。 Wiresharkなどのプロトコル アナライザーはパケット レベルで動作し、TCP データを表示できるため、パケットの損失や接続の問題のトラブルシューティングを行うことができます。

エンドツーエンドトレース

さまざまなログ ファイルを使用したエンドツーエンドのトレースは、潜在的な問題を調査するための便利な手法です。 メトリック データの日付/時刻情報を使用して、ログ ファイルの検索を開始する場所を示して、問題のトラブルシューティングに役立つ詳細情報を確認できます。

ログ データの関連付け

クライアント アプリケーション、ネットワーク トレース、およびサーバー側のストレージ ログからログを表示する場合は、さまざまなログ ファイル間で要求を関連付けることができることが重要です。 ログ ファイルには、関連付け識別子として役立つさまざまなフィールドが含まれています。 クライアント要求 ID は、さまざまなログ内のエントリを関連付けるために使用する最も便利なフィールドです。 ただし、サーバー要求 ID またはタイムスタンプを使用すると便利な場合があります。 以下のセクションでは、これらのオプションの詳細について説明します。

クライアント要求 ID

ストレージ クライアント ライブラリは、要求ごとに一意のクライアント要求 ID を自動的に生成します。

• ストレージ クライアント ライブラリが作成するクライアント側ログでは、要求に関連するすべてのログ エントリのフィールドにクライアント要求 ID が表示されます Client Request ID 。
• Fiddler によってキャプチャされたネットワーク トレースでは、クライアント要求 ID が HTTP ヘッダー値として x-ms-client-request-id 要求メッセージに表示されます。
• サーバー側のストレージ ログ ログに、クライアント要求 ID が [クライアント要求 ID] 列に表示されます。

サーバー要求 ID

ストレージ サービスは、サーバー要求 ID を自動的に生成します。

• サーバー側のストレージ ログ ログに、サーバー要求 ID が列に Request ID header 表示されます。
• Fiddler によってキャプチャされたネットワーク トレースでは、サーバー要求 ID が HTTP ヘッダー値として応答メッセージに x-ms-request-id 表示されます。
• ストレージ クライアント ライブラリが作成するクライアント側のログでは、サーバーの応答の詳細を Operation Text 示すログ エントリの列にサーバー要求 ID が表示されます。

var connectionString = Constants.connectionString;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

BlobContainerClient blobContainerClient = blobServiceClient.GetBlobContainerClient("demcontainer");

BlobClient blobClient = blobContainerClient.GetBlobClient("testImage.jpg");

string clientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

using (HttpPipeline.CreateClientRequestIdScope(clientRequestID))
{
    BlobDownloadInfo download = blobClient.Download();

    using (FileStream downloadFileStream = File.OpenWrite("C:\\testImage.jpg"))
    {
        download.Content.CopyTo(downloadFileStream);
        downloadFileStream.Close();
    }
}

//Parse the connection string for the storage account.
const string ConnectionString = "DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key";
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Create an Operation Context that includes custom ClientRequestId string based on constants defined within the application along with a Guid.
OperationContext oc = new OperationContext();
oc.ClientRequestID = String.Format("{0} {1} {2} {3}", HOSTNAME, APPNAME, USERID, Guid.NewGuid().ToString());

try
{
    CloudBlobContainer container = blobClient.GetContainerReference("democontainer");
    ICloudBlob blob = container.GetBlobReferenceFromServer("testImage.jpg", null, null, oc);  
    var downloadToPath = string.Format("./{0}", blob.Name);
    using (var fs = File.OpenWrite(downloadToPath))
    {
        blob.DownloadToStream(fs, null, null, oc);
        Console.WriteLine("\t Blob downloaded to file: {0}", downloadToPath);
    }
}
catch (StorageException storageException)
{
    Console.WriteLine("Storage exception {0} occurred", storageException.Message);
    // Multiple results may exist due to client side retry logic - each retried operation will have a unique ServiceRequestId
    foreach (var result in oc.RequestResults)
    {
            Console.WriteLine("HttpStatus: {0}, ServiceRequestId {1}", result.HttpStatusCode, result.ServiceRequestID);
    }
}

タイムスタンプ

タイムスタンプを使用して関連するログ エントリを見つけることもできますが、存在する可能性があるクライアントとサーバーの間のクロック スキューには注意してください。 クライアントSearchタイムスタンプに基づいてサーバー側エントリを照合する場合は、プラスまたはマイナス 15 分です。 メトリックを含む BLOB の BLOB メタデータは、BLOB に格納されているメトリックの時間範囲を示します。 この時間範囲は、同じ分または 1 時間に多数のメトリック BLOB がある場合に便利です。

トラブルシューティング ガイダンス

このセクションは、Azure Storage サービスを使用するときにアプリケーションで発生する可能性がある一般的な問題の診断とトラブルシューティングに役立ちます。 以下の一覧を使用して、特定の問題に関連する情報を見つけます。

デシジョン ツリーのトラブルシューティング

問題は、いずれかのストレージ サービスのパフォーマンスに関連していますか?

• メトリックは AverageE2ELatency が高く、AverageServerLatency が低いことが示されます。
• メトリックは AverageE2ELatency が低く、AverageServerLatency が低いことが示されますが、クライアントでは待機時間が長くなっています。
• メトリックは AverageServerLatency が高いを示します。
• キューでのメッセージ配信に予期しない遅延が発生しています。

問題は、いずれかのストレージ サービスの可用性に関連していますか?

• メトリックは PercentThrottlingError の増加を示します。
• メトリックは PercentTimeoutError の増加を示します。
• メトリックは PercentNetworkError の増加を示します。

クライアント アプリケーションがストレージ サービスから HTTP 4XX (404 など) 応答を受信していますか?

• クライアントは HTTP 403 (禁止) メッセージを受信しています。
• クライアントが HTTP 404 (見つかりません) メッセージを受信しています。
• クライアントが HTTP 409 (競合) メッセージを受信しています。

メトリックは、トランザクションの状態が ClientOtherErrors の操作を持つ低い PercentSuccess または分析ログ エントリを示します。

容量メトリックは、ストレージ容量の使用量が予期しない増加を示します。

開発またはテストにストレージ エミュレーターを使用すると、問題が発生します。

Azure SDK for .NET のインストールに関する問題が発生しています。

ストレージ サービスに別の問題があります。

メトリックは AverageE2ELatency が高く、AverageServerLatency が低い

次のAzure portal監視ツールの図は、AverageE2ELatency が AverageServerLatency よりも大幅に高い例を示しています。

ストレージ サービスでは、成功した要求の メトリック AverageE2ELatency のみが計算され、 AverageServerLatency とは異なり、クライアントがデータを送信し、ストレージ サービスから受信確認を受け取るためにかかる時間が含まれます。 そのため、 AverageE2ELatency と AverageServerLatency の違いは、クライアント アプリケーションの応答速度が低下しているか、ネットワーク上の状態が原因である可能性があります。

クライアントのパフォーマンスの問題の調査

クライアントの応答が遅くなる原因としては、使用可能な接続またはスレッドの数が限られているか、CPU、メモリ、ネットワーク帯域幅などのリソースが不足している可能性があります。 問題を解決するには、クライアント コードをより効率的に変更するか (たとえば、ストレージ サービスへの非同期呼び出しを使用するなど)、またはより大きな仮想マシン (より多くのコアとより多くのメモリを使用) を使用できます。

テーブルおよびキュー サービスの場合、Nagle アルゴリズムによって AverageServerLatency と比較して AverageE2ELatency が高くなる可能性もあります。 詳細については、「 Nagle のアルゴリズムは小さな要求に対してフレンドリではありません」を参照してください。 名前空間の クラスを使用 ServicePointManager して、コードで Nagle アルゴリズムを System.Net 無効にすることができます。 既に開いている接続には影響しないため、アプリケーション内のテーブルまたはキュー サービスを呼び出す前に、これを行う必要があります。 次の例は、worker ロールの Application_Start メソッドに由来します。

var connectionString = Constants.connectionString;

QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);

ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

var storageAccount = CloudStorageAccount.Parse(connStr);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(storageAccount.QueueEndpoint);
queueServicePoint.UseNagleAlgorithm = false;

クライアント側のログをチェックして、クライアント アプリケーションが送信している要求の数を確認し、一般的な をチェックする必要があります。CPU、.NET ガベージ コレクション、ネットワーク使用率、メモリなど、クライアント内の NET 関連のパフォーマンスのボトルネック。 .NET クライアント アプリケーションのトラブルシューティングの出発点として、「 デバッグ、トレース、プロファイリング」を参照してください。

ネットワーク待機時間の問題の調査

通常、ネットワークによって発生するエンド ツー エンドの待機時間が長い場合は、一時的な状態が原因です。 Wiresharkなどのツールを使用して、パケットの破棄など、一時的なネットワークの問題と永続的なネットワークの問題の両方を調査できます。

Wiresharkを使用したネットワークの問題のトラブルシューティングの詳細については、「付録 2: Wiresharkを使用したネットワーク トラフィックのキャプチャ」を参照してください。

メトリックは AverageE2ELatency が低く、AverageServerLatency が低いが、クライアントで待機時間が長い

このシナリオでは、最も可能性の高い原因は、ストレージ サービスに到達するストレージ要求の遅延です。 クライアントからの要求が BLOB サービスに送信されない理由を調査する必要があります。

クライアントが要求の送信を遅らせる理由の 1 つは、使用可能な接続またはスレッドの数が限られているということです。

また、クライアントが複数の再試行を実行しているかどうかをチェックし、その理由を調査します。 クライアントが複数の再試行を実行しているかどうかを判断するには、次の操作を行います。

• Storage Analytics ログを調べます。 再試行が複数回行われると、同じクライアント要求 ID を持ち、サーバー要求 ID が異なる複数の操作が表示されます。
• クライアント ログを調べます。 詳細ログは、再試行が発生したことを示します。
• コードをデバッグし、要求に関連付けられているオブジェクトのプロパティをOperationContextチェックします。 操作が再試行された場合、プロパティには複数の RequestResults 一意のサーバー要求 ID が含まれます。 各要求の開始時刻と終了時刻をチェックすることもできます。 詳細については、「 サーバー要求 ID」セクションのコード サンプルを参照してください。

クライアントに問題がない場合は、パケット損失などの潜在的なネットワークの問題を調査する必要があります。 Wiresharkなどのツールを使用して、ネットワークの問題を調査できます。

Wiresharkを使用したネットワークの問題のトラブルシューティングの詳細については、「付録 2: Wiresharkを使用したネットワーク トラフィックのキャプチャ」を参照してください。

メトリックは AverageServerLatency が高い

BLOB ダウンロード要求の AverageServerLatency が 高い場合は、ストレージ ログ ログを使用して、同じ BLOB (または BLOB のセット) に対して繰り返し要求があるかどうかを確認する必要があります。 BLOB アップロード要求の場合は、クライアントが使用しているブロック サイズを調査する必要があります (たとえば、サイズが 64 K 未満のブロックは、読み取りも 64 K チャンク未満でない限りオーバーヘッドが発生する可能性があります)、複数のクライアントが同じ BLOB にブロックを並列にアップロードしている場合。 また、1 秒あたりのスケーラビリティ ターゲットを超える要求数の急増に関する 1 分あたりのメトリックもチェックする必要があります。 詳細については、 PercentTimeoutError の増加を示すメトリックに関するページを参照してください。

同じ BLOB または BLOB のセットに対して要求が繰り返される場合、BLOB ダウンロード要求に対して AverageServerLatency が高い場合は、Azure Cache または Azure Content Delivery Network (CDN) を使用してこれらの BLOB をキャッシュすることを検討してください。 アップロード要求の場合は、より大きなブロック サイズを使用してスループットを向上させることができます。 テーブルに対するクエリの場合は、同じクエリ操作を実行し、データが頻繁に変更されないクライアントに対してクライアント側キャッシュを実装することもできます。

AverageServerLatency の値が高いと、スキャン操作が発生したり、append/prepend アンチパターンに従ったりする、設計が不十分なテーブルやクエリの症状になる可能性もあります。 詳細については、「 メトリックは PercentThrottlingError の増加を示す」を参照してください。

キューでのメッセージ配信で予期しない遅延が発生している

アプリケーションがキューにメッセージを追加してからキューから読み取れるまでの間に遅延が発生している場合は、次の手順を実行して問題を診断します。

• アプリケーションがキューにメッセージを正常に追加していることを確認します。 成功する前に、アプリケーションがメソッドを AddMessage 複数回再試行していないことを確認します。 ストレージ クライアント ライブラリ ログには、ストレージ操作の再試行が繰り返し表示されます。
• キューにメッセージを追加するワーカー ロールと、キューからメッセージを読み取るワーカー ロールの間にクロック スキューがないことを確認します。 クロック スキューにより、処理に遅延があるかのように表示されます。
• キューからメッセージを読み取るワーカー ロールが失敗しているかどうかを確認します。 キュー クライアントが メソッドを GetMessage 呼び出しても受信確認の応答に失敗した場合、メッセージは期限切れになるまで invisibilityTimeout キューに表示されなくなります。 この時点で、メッセージはもう一度処理できるようになります。
• キューの長さが時間の経過と同時に長くなっているかどうかを確認します。 これは、他のワーカーがキューに配置しているすべてのメッセージを処理できる十分なワーカーがない場合に発生する可能性があります。 また、メトリックをチェックして、削除要求が失敗しているかどうかを確認し、メッセージのデキューカウントを確認します。これは、メッセージの削除試行が繰り返し失敗したことを示している可能性があります。
• 通常よりも長い期間にわたって、 E2ELatency と ServerLatency の値が予想よりも高いキュー操作がないか、ストレージ ログ ログを調べます。

メトリックは PercentThrottlingError の増加を示します

調整エラーは、ストレージ サービスのスケーラビリティ ターゲットを超えると発生します。 ストレージ サービスは、1 つのクライアントまたはテナントが他のユーザーを犠牲にしてサービスを使用できないように調整します。 詳細については、 ストレージ アカウントのスケーラビリティ ターゲットとストレージ アカウント内のパーティションのパフォーマンス ターゲット の詳細については、「標準ストレージ アカウントのスケーラビリティとパフォーマンスのターゲット」を参照してください。

PercentThrottlingError メトリックで、調整エラーで失敗している要求の割合が増加している場合は、次の 2 つのシナリオのいずれかを調査する必要があります。

• PercentThrottlingError の一時的な増加
• PercentThrottlingError エラーの永続的な増加

PercentThrottlingError の増加は、多くの場合、ストレージ要求の数の増加と同時に、またはアプリケーションを最初にロード テストするときに発生します。 これは、クライアント内で"503 Server Busy" または "500 操作タイムアウト" の HTTP 状態メッセージとして表示される場合もあります。

PercentThrottlingError の一時的な増加

アプリケーションの高いアクティビティの期間と一致する PercentThrottlingError の値が急増している場合は、クライアントで再試行のための指数関数 (線形ではない) バックオフ戦略を実装できます。 バックオフ再試行は、パーティションの即時負荷を軽減し、アプリケーションがトラフィックの急増をスムーズにするのに役立ちます。 ストレージ クライアント ライブラリを使用して再試行ポリシーを実装する方法の詳細については、 Microsoft.Azure.Storage.RetryPolicies 名前空間を参照してください。

PercentThrottlingError の永続的な増加

トランザクション ボリュームが永続的に増加した後、またはアプリケーションで初期ロード テストを実行しているときに PercentThrottlingError の値が一貫して高い場合は、アプリケーションがストレージ パーティションをどのように使用しているか、ストレージ アカウントのスケーラビリティ ターゲットに近づいているかどうかを評価する必要があります。 たとえば、キューで調整エラー (1 つのパーティションとしてカウントされます) が表示される場合は、追加のキューを使用してトランザクションを複数のパーティションに分散することを検討してください。 テーブルで調整エラーが発生する場合は、さまざまなパーティション キー値を使用してトランザクションを複数のパーティションに分散させるために、別のパーティション分割スキームを使用することを検討する必要があります。 この問題の一般的な原因の 1 つは、パーティション キーとして日付を選択し、特定の日のすべてのデータが 1 つのパーティションに書き込まれる前に、追加/追加のアンチパターンです。読み込み中に、書き込みのボトルネックが発生する可能性があります。 別のパーティション分割設計を検討するか、BLOB ストレージを使用することがより優れたソリューションであるかどうかを評価します。 また、トラフィックの急増の結果として調整が発生しているかどうかをチェックし、要求のパターンをスムージングする方法を調査します。

トランザクションを複数のパーティションに分散する場合でも、ストレージ アカウントに設定されているスケーラビリティの制限に注意する必要があります。 たとえば、10 個のキューを使用し、1 秒あたり最大 2,000 1KB のメッセージを処理する場合、ストレージ アカウントの 1 秒あたり 20,000 メッセージの全体的な制限になります。 1 秒あたり 20,000 を超えるエンティティを処理する必要がある場合は、複数のストレージ アカウントを使用することを検討してください。 また、要求とエンティティのサイズは、ストレージ サービスがクライアントを調整する場合に影響を与える点にも注意してください。 より大きな要求とエンティティがある場合は、より早く調整される可能性があります。

クエリの設計が非効率的な場合、テーブル パーティションのスケーラビリティの制限に達する可能性もあります。 たとえば、パーティション内のエンティティの 1% のみを選択するが、パーティション内のすべてのエンティティをスキャンするフィルターを含むクエリは、各エンティティにアクセスする必要があります。 読み取られたすべてのエンティティは、そのパーティション内のトランザクションの合計数にカウントされます。そのため、スケーラビリティ ターゲットに簡単に到達できます。

メトリックは PercentTimeoutError の増加を示します

メトリックは、いずれかのストレージ サービスの PercentTimeoutError の増加を示します。 同時に、クライアントはストレージ操作から大量の "500 操作タイムアウト" HTTP 状態メッセージを受信します。

PercentTimeoutError メトリックは、ClientTimeoutError、AnonymousClientTimeoutError、SASClientTimeoutError、ServerTimeoutError、AnonymousServerTimeoutError、SASServerTimeoutError の各メトリックの集計です。

サーバーのタイムアウトは、サーバー上のエラーが原因で発生します。 クライアントのタイムアウトは、サーバー上の操作がクライアントによって指定されたタイムアウトを超えたために発生します。たとえば、ストレージ クライアント ライブラリを使用するクライアントは、 クラスの プロパティを使用して操作のタイムアウトをServerTimeoutQueueRequestOptions設定できます。

サーバーのタイムアウトは、ストレージ サービスに関する問題を示し、さらに調査する必要があります。 メトリックを使用して、サービスのスケーラビリティの制限に達しているかどうかを確認し、この問題の原因となっている可能性のあるトラフィックの急増を特定できます。 問題が断続的な場合は、サービスの負荷分散アクティビティが原因である可能性があります。 問題が永続的であり、アプリケーションがサービスのスケーラビリティの制限に達したために発生しない場合は、サポートの問題を発生させる必要があります。 クライアントのタイムアウトの場合は、タイムアウトがクライアントで適切な値に設定されているかどうかを判断し、クライアントで設定されたタイムアウト値を変更するか、テーブル クエリの最適化やメッセージのサイズの縮小など、ストレージ サービスの操作のパフォーマンスを向上させる方法を調査する必要があります。

メトリックは PercentNetworkError の増加を示します

メトリックは、いずれかのストレージ サービスの PercentNetworkError の増加を示します。 PercentNetworkError メトリックは、NetworkError、AnonymousNetworkError、SASNetworkError の各メトリックの集計です。 これは、クライアントがストレージ要求を行ったときにストレージ サービスがネットワーク エラーを検出したときに発生します。

このエラーの最も一般的な原因は、ストレージ サービスでタイムアウトが切れる前のクライアントの切断です。 クライアントのコードを調査して、クライアントがストレージ サービスから切断される理由とタイミングを理解します。 Wiresharkまたは Tcping を使用して、クライアントからのネットワーク接続の問題を調査することもできます。 これらのツールについては、「 付録」を参照してください。

クライアントが HTTP 403 (禁止) メッセージを受信している

クライアント アプリケーションが HTTP 403 (禁止) エラーをスローしている場合、クライアントがストレージ要求を送信するときに期限切れの Shared Access Signature (SAS) を使用している可能性があります (ただし、その他の原因にはクロック スキュー、無効なキー、空のヘッダーが含まれます)。 有効期限が切れた SAS キーが原因の場合、サーバー側のストレージ ログ ログ データにエントリは表示されません。 次の表は、ストレージ クライアント ライブラリによって生成されたクライアント側ログのサンプルを示しています。この問題が発生していることを示します。

このシナリオでは、クライアントがサーバーにトークンを送信する前に、SAS トークンの有効期限が切れている理由を調査する必要があります。

• 通常、クライアントがすぐに使用する SAS を作成するときに開始時刻を設定しないでください。 現在の時刻を使用して SAS を生成するホストとストレージ サービスの間に小さなクロックの違いがある場合、ストレージ サービスがまだ有効ではない SAS を受け取る可能性があります。
• SAS で非常に短い有効期限を設定しないでください。 ここでも、SAS を生成するホストとストレージ サービスの間の小さなクロックの違いにより、SAS が予想よりも早く期限切れになる可能性があります。
• SAS キーの version パラメーター (=2015-04-05 など) は、 sv使用しているストレージ クライアント ライブラリのバージョンと一致しますか? 常に最新バージョンの ストレージ クライアント ライブラリを使用することをお勧めします。
• ストレージ アクセス キーを再生成すると、既存の SAS トークンが無効になる可能性があります。 この問題は、クライアント アプリケーションがキャッシュするために有効期限が長い SAS トークンを生成する場合に発生する可能性があります。

ストレージ クライアント ライブラリを使用して SAS トークンを生成する場合は、有効なトークンを簡単に作成できます。 ただし、Storage REST API を使用して SAS トークンを手動で構築する場合は、「 Shared Access Signature を使用したアクセスの委任」を参照してください。

クライアントが HTTP 404 (見つかりません) メッセージを受信している

クライアント アプリケーションがサーバーから HTTP 404 (見つかりません) メッセージを受信した場合、これは、クライアントが使用しようとしているオブジェクト (エンティティ、テーブル、BLOB、コンテナー、キューなど) がストレージ サービスに存在しないことを意味します。 これには、次のようないくつかの理由が考えられます。

• クライアントまたは別のプロセスが以前にオブジェクトを削除しました。
• Shared Access Signature (SAS) 承認の問題。
• クライアント側の JavaScript コードには、オブジェクトにアクセスするためのアクセス許可がありません。
• ネットワーク障害。

以前にオブジェクトを削除したクライアントまたは別のプロセス

クライアントがストレージ サービス内のデータの読み取り、更新、または削除を試みるシナリオでは、通常、ストレージ サービスから対象のオブジェクトを削除した以前の操作をサーバー側でログに記録して簡単に識別できます。 多くの場合、ログ データは、別のユーザーまたはプロセスがオブジェクトを削除したことを示します。 サーバー側のストレージ ログ ログでは、クライアントがオブジェクトを削除したときに、操作の種類と requested-object-key 列が表示されます。

クライアントがオブジェクトを挿入しようとしているシナリオでは、クライアントが新しいオブジェクトを作成していることを考えると、HTTP 404 (見つかりません) 応答が発生する理由はすぐには明らかでない場合があります。 ただし、クライアントが BLOB を作成している場合は、BLOB コンテナーを見つけることができる必要があります。 クライアントがメッセージを作成している場合は、キューを検索できる必要があります。 また、クライアントが行を追加している場合は、テーブルを検索できる必要があります。

ストレージ クライアント ライブラリのクライアント側ログを使用すると、クライアントがストレージ サービスに特定の要求を送信するタイミングをより詳細に把握できます。

ストレージ クライアント ライブラリによって生成される次のクライアント側ログは、クライアントが作成している BLOB のコンテナーが見つからない場合の問題を示しています。 このログには、次のストレージ操作の詳細が含まれています。

ログ エントリ:

この例では、ログは、クライアントがメソッドからの CreateIfNotExists 要求 (要求 ID e2d06d78....) とメソッドからの UploadFromStream 要求 (de8b1c3c-...) をインターリーブしていることを示しています。このインターリーブは、クライアント アプリケーションがこれらのメソッドを非同期的に呼び出しているために発生します。 クライアントの非同期コードを変更して、コンテナー内の BLOB にデータをアップロードする前にコンテナーが作成されるようにします。 理想的には、すべてのコンテナーを事前に作成する必要があります。

Shared Access Signature (SAS) 承認の問題

クライアント アプリケーションが操作に必要なアクセス許可を含まない SAS キーを使用しようとすると、ストレージ サービスは HTTP 404 (見つかりません) メッセージをクライアントに返します。 同時に、メトリックには の 0 以外の SASAuthorizationError 値も表示されます。

次の表は、ストレージ ログ ログ ファイルからのサーバー側ログ メッセージの例を示しています。

クライアント アプリケーションにアクセス許可が付与されていない操作を実行しようとしている理由を調査します。

クライアント側の JavaScript コードには、オブジェクトにアクセスするためのアクセス許可がありません

JavaScript クライアントを使用していて、ストレージ サービスが HTTP 404 メッセージを返している場合は、ブラウザーで次の JavaScript エラーをチェック。

SEC7120: Access-Control-Allow-Origin http://localhost:56309 ヘッダーに配信元が見つかりません。
SCRIPT7002: XMLHttpRequest: ネットワーク エラー 0x80070005、アクセスは拒否されます。

これらのエラーは、Web ブラウザーが 同じ配信元ポリシー のセキュリティ制限を実装しているために発生します。これにより、Web ページがページの元のドメインとは異なるドメイン内の API を呼び出すのを防ぎます。

JavaScript の問題を回避するには、クライアントがアクセスしているストレージ サービスのクロスオリジン リソース共有 (CORS) を構成します。 詳細については、「 Azure Storage Services のクロスオリジン リソース共有 (CORS) サポート」を参照してください。

次のコード サンプルは、Contoso ドメインで実行されている JavaScript が BLOB ストレージ サービス内の BLOB にアクセスできるように BLOB サービスを構成する方法を示しています。

var connectionString = Constants.connectionString;

 BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

 BlobServiceProperties sp = blobServiceClient.GetProperties();

 // Set the service properties.
 sp.DefaultServiceVersion = "2013-08-15";
 BlobCorsRule bcr = new BlobCorsRule();
 bcr.AllowedHeaders = "*";

 bcr.AllowedMethods = "GET,POST";
 bcr.AllowedOrigins = "http://www.contoso.com";
 bcr.ExposedHeaders = "x-ms-*";
 bcr.MaxAgeInSeconds = 5;
 sp.Cors.Clear();
 sp.Cors.Add(bcr);
 blobServiceClient.SetProperties(sp);

CloudBlobClient client = new CloudBlobClient(blobEndpoint, new StorageCredentials(accountName, accountKey));
// Set the service properties.
ServiceProperties sp = client.GetServiceProperties();
sp.DefaultServiceVersion = "2013-08-15";
CorsRule cr = new CorsRule();
cr.AllowedHeaders.Add("*");
cr.AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Put;
cr.AllowedOrigins.Add("http://www.contoso.com");
cr.ExposedHeaders.Add("x-ms-*");
cr.MaxAgeInSeconds = 5;
sp.Cors.CorsRules.Clear();
sp.Cors.CorsRules.Add(cr);
client.SetServiceProperties(sp);

ネットワーク エラー

状況によっては、ネットワーク パケットが失われると、ストレージ サービスが HTTP 404 メッセージをクライアントに返す可能性があります。 たとえば、クライアント アプリケーションがテーブル サービスからエンティティを削除している場合、クライアントは、テーブル サービスから "HTTP 404 (Not Found)" 状態メッセージを報告するストレージ例外をスローすることがわかります。 テーブル ストレージ サービス内のテーブルを調査すると、要求に応じてサービスによってエンティティが削除されたことがわかります。

クライアントの例外の詳細には、要求に対してテーブル サービスによって割り当てられた要求 ID (7e84f12d...) が含まれます。 この情報を使用すると、ログ ファイルの列を検索して、サーバー側ストレージ ログ内の request-id-header 要求の詳細を見つけることができます。 また、メトリックを使用して、このようなエラーが発生したタイミングを特定し、メトリックがこのエラーを記録した時刻に基づいてログ ファイルを検索することもできます。 このログ エントリは、削除が "HTTP (404) Client Other Error" 状態メッセージで失敗したことを示しています。 同じログ エントリには、列 (813ea74f...) に client-request-id クライアントによって生成された要求 ID も含まれています。

サーバー側ログには、同じエンティティと同じクライアントからの削除操作が成功した場合に、同じ client-request-id 値 (813ea74f...) を持つ別のエントリも含まれます。 この正常な削除操作は、失敗した削除要求の直前に行われました。

このシナリオの最も可能性の高い原因は、クライアントがエンティティの削除要求をテーブル サービスに送信したことです。この要求は成功しましたが、サーバーから受信確認を受信しませんでした (一時的なネットワークの問題が原因である可能性があります)。 その後、クライアントは (同じ client-request-idを使用して) 操作を自動的に再試行し、エンティティが既に削除されているため、この再試行は失敗しました。

この問題が頻繁に発生する場合は、クライアントがテーブル サービスから受信確認を受信できない理由を調査する必要があります。 問題が断続的な場合は、"HTTP (404) Not Found" エラーをトラップし、クライアントにログを記録しますが、クライアントの続行を許可する必要があります。

クライアントが HTTP 409 (競合) メッセージを受信している

次の表は、2 つのクライアント操作 DeleteIfExists に対するサーバー側ログからの抽出を示しています。その直後 CreateIfNotExists に、同じ BLOB コンテナー名を使用します。 各クライアント操作では、2 つの要求がサーバーに送信され、最初GetContainerPropertiesにコンテナーが存在する場合にチェック要求が送信され、その後に または CreateContainer 要求がDeleteContainer送信されます。

クライアント アプリケーションのコードは、同じ名前 CreateIfNotExists (クライアント要求 ID bc881924-...) を使用して BLOB コンテナーを削除し、すぐに再作成します。最終的に HTTP 409 (Conflict) エラーで失敗します。 クライアントが BLOB コンテナー、テーブル、またはキューを削除すると、名前が再び使用可能になるまでの短い期間があります。

削除/再作成パターンが一般的な場合、クライアント アプリケーションは新しいコンテナーを作成するたびに一意のコンテナー名を使用する必要があります。

メトリックは、トランザクション状態が ClientOtherErrors の操作を持つ低 PercentSuccess または分析ログ エントリを示します

PercentSuccess メトリックは、HTTP 状態コードに基づいて成功した操作の割合をキャプチャします。 状態コードが 2XX の操作は成功とカウントされますが、3XX、4XX、および 5XX の範囲の状態コードを持つ操作は失敗としてカウントされ、 PercentSuccess メトリック値が下げられます。 サーバー側のストレージ ログ ファイルでは、これらの操作は ClientOtherErrors のトランザクション状態で記録されます。

これらの操作は正常に完了しているため、可用性などの他のメトリックには影響しません。 正常に実行されるが、HTTP 状態コードが失敗する可能性がある操作の例を次に示します。

• ResourceNotFound (Not Found 404) (たとえば、要求から GET 存在しない BLOB まで)。
• ResourceAlreadyExists (Conflict 409) (たとえば、リソースが既に存在する操作から CreateIfNotExist )。
• ConditionNotMet (Not Modified 304) は、たとえば、クライアントが値を送信 ETag するときや、最後の操作以降に更新された場合にのみイメージを要求する HTTP If-None-Match ヘッダーなどの条件付き操作からです。

ストレージ サービスから返される一般的な REST API エラー コードの一覧については、 共通 REST API エラー コードに関するページを参照してください。

容量メトリックは、ストレージ容量の使用量の予期しない増加を示します

ストレージ アカウントの容量使用量に突然予期しない変更が発生した場合は、まず可用性メトリックを調べることで、その理由を調査できます。たとえば、失敗した削除要求の数が増えると、アプリケーション固有のクリーンアップ操作として使用している BLOB ストレージの量が増加する可能性があります。たとえば、空き領域を解放するために使用される SAS トークンの有効期限が切れているなど、想定どおりに機能しない可能性があります。

開発またはテストにストレージ エミュレーターを使用して問題が発生する

通常、Azure ストレージ アカウントの要件を回避するために、開発とテスト中にストレージ エミュレーターを使用します。 ストレージ エミュレーターを使用しているときに発生する可能性がある一般的な問題は次のとおりです。

• ストレージ エミュレーターで機能 "X" が機能していません。
• ストレージ エミュレーターを使用しているときにエラー "HTTP ヘッダーの 1 つの値が正しい形式ではありません" というエラーが表示されます。
• ストレージ エミュレーターを実行するには、管理特権が必要です。

ストレージ エミュレーターで機能 "X" が機能しない

ストレージ エミュレーターは、ファイル サービスなど、Azure ストレージ サービスのすべての機能をサポートしているわけではありません。 詳細については、「 Azure Storage Emulator for Development and Testing の使用」を参照してください。

ストレージ エミュレーターがサポートしていない機能については、クラウドで Azure ストレージ サービスを使用します。

ストレージ エミュレーターを使用するときにエラー "HTTP ヘッダーの 1 つの値が正しい形式ではありません"

ローカル ストレージ エミュレーターに対してストレージ クライアント ライブラリを使用するアプリケーションと、"HTTP ヘッダーの 1 つの値が正しい形式ではありません" というエラー メッセージで失敗するなどの CreateIfNotExists メソッド呼び出しをテストしています。これは、使用しているストレージ エミュレーターのバージョンが、使用しているストレージ クライアント ライブラリのバージョンをサポートしていないことを示します。 ストレージ クライアント ライブラリは、行うすべての要求にヘッダー x-ms-version を追加します。 ストレージ エミュレーターがヘッダー内 x-ms-version の値を認識しない場合、要求は拒否されます。

ストレージ ライブラリ クライアント ログを使用して、送信している値を x-ms-version header 確認できます。 Fiddler を使用してクライアント アプリケーションからの要求をトレースする場合は、 の値 x-ms-version header も確認できます。

このシナリオは、通常、ストレージ エミュレーターを更新せずに最新バージョンのストレージ クライアント ライブラリをインストールして使用する場合に発生します。 最新バージョンのストレージ エミュレーターをインストールするか、エミュレーターの代わりにクラウド ストレージを使用して開発とテストを行う必要があります。

ストレージ エミュレーターを実行するには、管理特権が必要です

ストレージ エミュレーターを実行すると、管理者の資格情報の入力を求められます。 これは、ストレージ エミュレーターを初めて初期化する場合にのみ発生します。 ストレージ エミュレーターを初期化した後は、もう一度実行するための管理特権は必要ありません。

詳細については、「 Azure Storage Emulator for Development and Testing の使用」を参照してください。 Visual Studio でストレージ エミュレーターを初期化することもできます。管理特権も必要になります。

Azure SDK for .NET のインストールに関する問題が発生しています

SDK をインストールしようとすると、ローカル コンピューターにストレージ エミュレーターをインストールしようとして失敗します。 インストール ログには、次のいずれかのメッセージが含まれています。

• CAQuietExec: エラー: SQL インスタンスにアクセスできません
• CAQuietExec: エラー: データベースを作成できません

原因は、既存の LocalDB インストールに関する問題です。 既定では、ストレージ エミュレーターは、Azure ストレージ サービスをシミュレートするときに LocalDB を使用してデータを保持します。 SDK をインストールする前にコマンド プロンプト ウィンドウで次のコマンドを実行することで、LocalDB インスタンスをリセットできます。

sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0

このコマンドは delete 、ストレージ エミュレーターの以前のインストールから古いデータベース ファイルを削除します。

ストレージ サービスに関して別の問題がある

前のトラブルシューティング セクションにストレージ サービスで発生している問題が含まれていない場合は、問題の診断とトラブルシューティングに次のアプローチを採用する必要があります。

• メトリックを確認して、予想されるベースライン動作から何らかの変更があるかどうかを確認します。 メトリックから、問題が一時的か永続的か、問題が影響を受けるストレージ操作を判断できる場合があります。
• メトリック情報を使用すると、発生しているエラーに関する詳細情報をサーバー側のログ データで検索するのに役立ちます。 この情報は、問題のトラブルシューティングと解決に役立つ場合があります。
• サーバー側ログの情報が問題のトラブルシューティングに十分でない場合は、ストレージ クライアント ライブラリクライアント側ログを使用して、クライアント アプリケーションと Fiddler などのツールの動作を調査し、ネットワークを調査するためのWiresharkを使用できます。

Fiddler の使用の詳細については、「 付録 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャ」を参照してください。

Wiresharkの使用の詳細については、「付録 2: Wiresharkを使用したネットワーク トラフィックのキャプチャ」を参照してください。

付録

付録では、Azure Storage (およびその他のサービス) に関する問題の診断とトラブルシューティングを行うときに役立つ可能性のあるいくつかのツールについて説明します。 これらのツールは Azure Storage の一部ではなく、一部はサードパーティ製品です。 そのため、これらの付録で説明されているツールは、Microsoft Azure または Azure Storage とのサポート契約の対象になりません。 そのため、評価プロセスの一環として、これらのツールのプロバイダーから利用できるライセンスとサポート オプションを確認する必要があります。

付録 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャ

Fiddler は、クライアント アプリケーションと使用している Azure ストレージ サービスの間の HTTP トラフィックと HTTPS トラフィックを分析するのに便利なツールです。

この付録では、Fiddler をインストールしたローカル コンピューターと Azure ストレージ サービスの間のトラフィックをキャプチャするように Fiddler を構成する方法の簡単なチュートリアルを示します。

Fiddler を起動すると、ローカル コンピューターで HTTP トラフィックと HTTPS トラフィックのキャプチャが開始されます。 Fiddler を制御するための便利なコマンドを次に示します。

• トラフィックのキャプチャを停止して開始します。 [メイン] メニューの [ファイル] に移動し、[トラフィックのキャプチャ] を選択して、キャプチャのオンとオフを切り替えます。
• キャプチャしたトラフィック データを保存します。 [メイン] メニューの [ファイル] に移動し、[保存] を選択し、[すべてのセッション] を選択します。 これにより、トラフィックをセッション アーカイブ ファイルに保存できます。 後でセッション アーカイブを再読み込みして分析したり、Microsoft サポートに要求された場合に送信したりできます。

Fiddler がキャプチャするトラフィックの量を制限するには、[フィルター] タブで構成した フィルター を使用できます。次のスクリーンショットは、ストレージ エンドポイントに送信されたトラフィックのみをキャプチャするフィルターを contosoemaildist.table.core.windows.net 示しています。

付録 2: Wiresharkを使用したネットワーク トラフィックのキャプチャ

Wiresharkは、さまざまなネットワーク プロトコルの詳細なパケット情報を表示できるネットワーク プロトコル アナライザーです。

次の手順では、Wiresharkをインストールしたローカル コンピューターから Azure ストレージ アカウントのテーブル サービスへのトラフィックの詳細なパケット情報をキャプチャする方法を示します。

1. ローカル コンピューターでWiresharkを起動します。

2. [ スタート ] セクションで、インターネットに接続されているローカル ネットワーク インターフェイスまたはインターフェイスを選択します。

3. [ キャプチャ オプション] を選択します。

4. [キャプチャ フィルター] ボックスに フィルター を追加します。 たとえば、 host contosoemaildist.table.core.windows.netcontosoemaildist ストレージ アカウント内のテーブル サービス エンドポイントと送受信されるパケットのみをキャプチャするようにWiresharkを構成します。 キャプチャ フィルターの完全な一覧を確認してください。

   

5. [スタート] を選択します。 Wiresharkでは、ローカル コンピューターでクライアント アプリケーションを使用するときに、テーブル サービス エンドポイントと送受信されるすべてのパケットがキャプチャされるようになりました。

6. 完了したら、メイン メニューの [キャプチャ>の停止] を選択します。

7. キャプチャしたデータをWiresharkキャプチャ ファイルに保存するには、メイン メニューの [ファイル>の保存] を選択します。

WireShark では、 パケットリスト ウィンドウに存在するエラーが強調表示されます。 [エキスパート情報] ウィンドウ ([エキスパート情報の分析>] を選択) を使用して、エラーと警告の概要を表示することもできます。

また、TCP データを右クリックし、[TCP Streamに従う] を選択することで、アプリケーション レイヤーに表示される TCP データを表示することもできます。 これは、キャプチャ フィルターなしでダンプをキャプチャした場合に便利です。 詳細については、「 TCP ストリームのフォロー」を参照してください。

付録 4: Excel を使用したメトリックとログ データの表示

多くのツールを使用すると、Azure テーブル ストレージから区切られた形式でストレージ メトリック データをダウンロードできます。これにより、表示と分析のためにデータを Excel に簡単に読み込むことができます。 Azure Blob Storageからのストレージ ログ データは、既に区切られた形式で Excel に読み込むことができます。 ただし、「ログ形式」および「メトリック テーブル スキーマ」の情報に基づいて、適切な列見出しStorage Analytics追加Storage Analytics必要があります。

BLOB ストレージからダウンロードした後にストレージ ログ データを Excel にインポートするには:

• [ データ ] メニューの [ テキストから] を選択します。
• 表示するログ ファイルを参照し、[インポート] を選択 します。
• テキスト インポート ウィザードの手順 1 で、[区切り記号] を選択します。

テキストインポートウィザードの手順 1 で、唯一の区切り記号としてセミコロンを選択し、テキスト修飾子として二重引用符を選択します。 次に、[ 完了] を選択し、ブックにデータを配置する場所を選択します。

付録 5: Azure DevOps の Application Insights を使用した監視

また、パフォーマンスと可用性の監視の一部として、Azure DevOps の Application Insights 機能を使用することもできます。 このツールでは、次のことができます。

• Web サービスが使用可能で応答性が高いかどうかを確認します。 アプリが Web サイトであるか、Web サービスを使用するデバイス アプリであるかに関係なく、世界中の場所から数分ごとに URL をテストし、問題があるかどうかを知らせることができます。
• Web サービスのパフォーマンスの問題や例外をすばやく診断します。 CPU またはその他のリソースが拡張されているかどうかを確認し、例外からスタック トレースを取得し、ログ トレースを簡単に検索します。 アプリのパフォーマンスが許容される制限を下回った場合、Microsoft からメールを送信できます。 .NET Web サービスと Java Web サービスの両方を監視できます。

詳細については、「 Application Insights とは」を参照してください。

次の手順

Azure Storage の分析の詳細については、次のリソースを参照してください。

• Azure portalでストレージ アカウントを監視する
• ストレージ分析
• ストレージ分析メトリック
• ストレージ分析メトリックテーブル スキーマ
• ストレージ分析ログ
• ストレージ分析ログの形式

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。