Microsoft Azure Storage (クラシック) の監視、診断、およびトラブルシューティング
このガイドでは、Azure Storage Analytics、Azure Storage クライアント ライブラリでのクライアント側のログ記録、その他のサード パーティ製ツールなどの機能を使用して、Azure Storage 関連の問題を特定、診断、トラブルシューティングする方法について説明します。
このガイドの主な対象読者は、Azure Storage サービスを使用するオンライン サービスの開発者と、そのようなオンライン サービスを管理する IT プロフェッショナルです。 このガイドの目的を次に示します。
- Azure ストレージ アカウントの正常性およびパフォーマンスを維持できるようにする。
- アプリケーションの問題が Azure Storage に関するものかどうかを判断するために必要なプロセスおよびツールを示す。
- Azure Storage に関する問題を解決するための実用的なガイダンスを提供する。
Note
この記事は、 Classic メトリックとログと呼ばれる Storage Analytics のメトリックとログの使用に基づいています。 Microsoft では、Storage Analytics ログの代わりに、Azure Monitor の 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 などの他のツールの使用に関する情報が含まれています。
Storage サービスの監視
Windows のパフォーマンス監視に詳しい人は、Storage メトリックのことを Windows パフォーマンス モニターのカウンターに相当する Azure Storage の機能だと考えることができます。 ストレージ メトリックでは、サービスの可用性、サービスへの要求の合計数、サービスに対する成功した要求の割合など、包括的なメトリックセット (Windows パフォーマンス モニター用語のカウンター) が表示されます。 使用可能なメトリックの詳細なリストについては、「 Storage Analytics Metrics のテーブル スキーマ」を参照してください。 Storage サービスでメトリックを収集および集計する間隔は、1 時間または 1 分を指定できます。 メトリックを有効にしてストレージ アカウントを監視する方法の詳細については、 ストレージ メトリックの有効化とメトリック データの表示に関するページをご覧ください。
Azure Portal に表示する時間単位のメトリックを選ぶことができます。また、時間単位メトリックが特定のしきい値を超えたときに必ず電子メールで管理者に通知するようにルールを構成することもできます。 詳しくは、「アラート通知を受け取る」をご覧ください。
Azure Monitor for Storage (プレビュー) を確認することをお勧めします。 これは、Azure Storage サービスのパフォーマンス、容量、可用性の統合されたビューが提供されることで、Azure Storage アカウントを包括的に監視できる Azure Monitor の機能です。 何も有効にしたり構成したりする必要はありません。これらのメトリックは、あらかじめ定義されている対話型のグラフやその他の含まれている視覚エフェクトからすぐに表示できます。
ストレージ サービスは、メトリックの収集に最善を尽くしますが、すべてのストレージ操作を記録するわけではありません。
Azure Portal では、ストレージ アカウントの可用性、要求の総数、平均待機時間などのメトリックを表示できます。 可用性が特定のレベルを下回った場合に管理者にアラートを送信する通知ルールもセットアップされています。 このデータを表示すると、テーブル サービスの成功率が 100% を下回る可能性があります (詳細については、「 Metrics show low PercentSuccess or analytics log entries have operations with transaction status of ClientOtherErrors section」を参照してください)。
次の方法により、Azure アプリケーションを継続して監視し、アプリケーションが正常であり、予期されるパフォーマンスが実現されていることを確認する必要があります。
- 現在のデータを比較し、Azure Storage とアプリケーションの動作に重大な変更を特定できるようにする、アプリケーションのベースライン メトリックをいくつか確立します。 ベースライン メトリックの値は、多くの場合、アプリケーション固有であり、アプリケーションのパフォーマンス テスト時にそれらを確立する必要があります。
- 分単位のメトリックを記録し、それらを使用して、予期しないエラーや異常 (エラー数や要求率の急増など) をアクティブに監視します。
- 時間単位のメトリックを記録し、それらを使用して、エラーの数や要求レートの平均などの平均値を監視します。
- ストレージの問題の診断セクションで後述するように、診断ツールを使用して潜在的な問題を調査します。
下の図のグラフは、時間単位メトリックでなされる平均値の算出によってアクティビティの急増が隠れてしまう状況を示しています。 時間単位メトリックには安定した要求レートが示されますが、分単位メトリックから、実際は変動していることが分かります。
このセクションの残りの部分では、監視する必要があるメトリックとその理由について説明します。
サービス正常性の監視
Azure Portal を使うことにより、世界中のすべての Azure リージョンの Storage サービス (およびその他の Azure サービス) の正常性を確認できます。 監視を使用すると、制御の範囲外の問題が、アプリケーションに使用するリージョンのストレージ サービスに影響しているかどうかをすぐに確認できます。
Azure Portal には、さまざまな Azure サービスに影響を与えるアクシデントについての通知も表示されます。
Note
この情報は、以前は Azure サービス ダッシュボード上で履歴データと共に入手できました。 Azure DevOps の Application Insights の詳細については、「 Appendix 5: Azure DevOps の Application Insights を使用した監視を参照してください。
容量監視
Storage メトリックは、一般に保管データの大部分を BLOB が占めるため、BLOB サービスの容量メトリックのみを保存します (現時点では、Storage メトリックを使用してテーブルおよびキューの容量を監視することはできません)。 BLOB サービスの監視を有効にしている場合は、このデータを $MetricsCapacityBlob テーブルで確認できます。 ストレージ メトリックでは、このデータを 1 日に 1 回記録します。 RowKey の値を使用して、ユーザー データ (値 data) または分析データ (値 analytics) に関連するエンティティが行に含まれているかどうかを判断できます。 格納されている各エンティティには、ストレージ アカウントで使用されているストレージの量 (Capacity バイト単位で測定) と、現在使用されているコンテナーの数 (ContainerCount) と BLOB (ObjectCount) に関する情報が含まれています。 $MetricsCapacityBlob テーブルに格納されている容量メトリックの詳細については、「Storage Analytics Metrics Table Schema」を参照してください。
Note
ストレージ アカウントの容量制限に近づいていることを示す早期警告として、これらの値を監視する必要があります。 Azure portal では、集計ストレージの使用が指定したしきい値を超えたか下回った場合に通知するアラート ルールを追加できます。
BLOB など、さまざまなストレージ オブジェクトのサイズを見積もる方法については、ブログ記事 「Azure Storage の課金の概要 - 帯域幅、トランザクション、容量を参照してください。
可用性の監視
ストレージ アカウント内のストレージ サービスの可用性を監視するには、時間単位または分単位のメトリック テーブル ($MetricsHourPrimaryTransactionsBlob、$MetricsHourPrimaryTransactionsTable、$MetricsHourPrimaryTransactionsQueue、$MetricsMinutePrimaryTransactionsBlob、$MetricsMinutePrimaryTransactionsTable、$MetricsMinutePrimaryTransactionsQueue、$MetricsCapacityBlob) のAvailability列の値を監視する必要があります。 Availability列には、行によって表されるサービスまたは API 操作の可用性を示すパーセンテージ値が含まれます (RowKeyは、行にサービス全体または特定の API 操作のメトリックが含まれているかどうかを示します)。
100% より低い値は、一部のストレージ要求が失敗したことを示します。 エラーの種類が異なる要求の数を示すメトリック データ内の他の列 (ServerTimeoutError など) を調べることで、失敗する理由を確認できます。 一時的なサーバー タイムアウトなどの理由により、 Availability が一時的に 100% を下回ると予想されます。サービスはパーティションを移動して要求の負荷分散を強化します。クライアント アプリケーションの再試行ロジックでは、このような断続的な状態を処理する必要があります。 Storage Analytics ログに記録された操作とステータス メッセージに関する記事ではストレージ メトリックがAvailability計算に含めるトランザクションの種類を示します。
Azure ポータルでは、サービスのAvailabilityが指定したしきい値を下回った場合に通知するアラート ルールを追加できます。
このガイドの「 トラブルシューティングガイダンス セクションでは、可用性に関連するいくつかの一般的なストレージ サービスの問題について説明します。
パフォーマンス監視
Storage サービスのパフォーマンスを監視するには、時間単位および分単位のメトリック テーブルにある次のメトリックを使用します。
AverageE2ELatency列とAverageServerLatency列の値は、ストレージ サービスまたは API 操作の種類が要求の処理にかかった平均時間を示します。AverageE2ELatencyは、要求の読み取りと応答の送信にかかった時間を含むエンドツーエンドの待機時間の測定値です (要求がストレージ サービスに到達した後のネットワーク待ち時間が含まれます)。AverageServerLatencyは処理時間のみを測定するため、クライアントとの通信に関連するネットワーク待機時間は除外されます。 この 2 つの値の間に大きな違いがある理由については、このガイドの後半の「 Metrics show high AverageE2ELatency and low AverageServerLatency 」セクションを参照してください。TotalIngress列とTotalEgress列の値は、ストレージ サービスに入ったり、ストレージ サービスから出て行ったり、特定の API 操作の種類を介して送信されたりするデータの合計量をバイト単位で示します。TotalRequests列の値は、API 操作のストレージ サービスが受信している要求の合計数を示します。TotalRequestsは、ストレージ サービスが受信する要求の合計数です。
通常は、調査が必要な問題があることを示すので、これらの値の予期しない変更を監視します。
Azure ポータルでは、このサービスのパフォーマンス メトリックが指定したしきい値を下回った場合やしきい値を超えた場合に通知するアラート ルールを追加できます。
このガイドの「 トラブルシューティングガイダンス 」セクションでは、パフォーマンスに関連するいくつかの一般的なストレージ サービスの問題について説明します。
ストレージ問題の診断
アプリケーションの問題を認識するようになる状況には次のようなものがあります。
- アプリケーションのクラッシュまたは動作停止を引き起こす重大なエラー。
- 前のセクションで説明したように、監視するメトリックのベースライン値からの大幅な変更 ストレージ サービスの監視。
- アプリケーションのユーザーから、特定の操作が予期したとおりに完了しなかった、または、特定の機能が正常に使用できないとの報告を受ける。
- アプリケーション内部でエラーが発生し、ログ ファイルに記録される、または、他の何らかの通知方式を介して明らかになる。
一般に、Azure Storage サービスに関する問題は、大まかに次の 4 つのカテゴリに分けられます。
- アプリケーションにパフォーマンスの問題があり、ユーザーによって報告されるか、パフォーマンス メトリックの変更によって表示されます。
- 1 つ以上のリージョンの Azure Storage インフラストラクチャに問題がある。
- アプリケーションでエラーが発生しています。これは、ユーザーによって報告されるか、監視するエラー数メトリックの 1 つが増加することによって明らかになります。
- 開発とテスト中は、ローカル ストレージ エミュレーターを使用している可能性があります。ストレージ エミュレーターの使用に特に関連するいくつかの問題が発生する可能性があります。
次のセクションでは、これらの 4 つのカテゴリのそれぞれの問題を診断およびトラブルシューティングするときに従う必要のある手順を大まかに説明します。 トラブルシューティングのガイダンスこのガイドの後半のセクションでは、発生する可能性がある一般的な問題について詳しく説明します。
サービス正常性の問題
一般に、サービス正常性の問題は制御不能です。 Azure ポータルは、ストレージ サービスを含む Azure サービスに関する継続的な問題に関する情報を提供します。 ストレージ アカウントの作成時に読み取りアクセス地理冗長ストレージを選択していた場合は、プライマリ ロケーションのデータが使用できなくなったときに、アプリケーションはセカンダリ ロケーションの読み取り専用コピーに一時的に切り替えることができます。 セカンダリから読み取るために、アプリケーションはプライマリストレージとセカンダリストレージの場所を切り替え、読み取り専用データを使用して機能制限モードで動作できる必要があります。 Azure ストレージ クライアント ライブラリを使用して、プライマリ ストレージから読み取れなくなった場合にセカンダリ ストレージから読み取れるようにする再試行ポリシーを定義できます。 また、アプリケーションは、セカンダリ ロケーションのデータが実際に一貫性のあるデータかどうかを認識できる必要もあります。 詳細については、Azure Storage の冗長オプションおよび読み取りアクセス地理冗長ストレージに関するブログ記事を参照してください。
パフォーマンスの問題
アプリケーションのパフォーマンスは主観的であり、特にユーザーの見方によって変わることがあります。 そのため、パフォーマンスに問題がある可能性のある場所を特定できるように、メトリックの基準値を設けておくことが重要です。 クライアント アプリケーションの観点から見ると、Azure Storage サービスのパフォーマンスはさまざまな要因によって影響を受ける可能性があります。 これらの要因は、ストレージ サービス、クライアント、またはネットワーク インフラストラクチャで動作する可能性があります。したがって、パフォーマンスの問題の発生源を特定するための戦略を立つことが重要です。
メトリックを使用してパフォーマンス問題の原因と考えられる場所を特定したら、ログ ファイルを使用して詳細な情報を見つけ、問題をさらに診断してトラブルシューティングすることができます。
トラブルシューティングのガイダンスこのガイドの後半のセクションでは、発生する可能性がある一般的なパフォーマンス関連の問題について詳しく説明します。
エラーの診断
アプリケーションのユーザーから、クライアント アプリケーションの報告したエラーについて通知されることがあります。 ストレージ メトリックは、NetworkError、ClientTimeoutError、AuthorizationError など、ストレージ サービスのさまざまなエラーの種類の数も記録します。 ストレージ メトリックにはエラーの種類ごとの数しか記録されませんが、サーバー側のログ、クライアント側のログ、およびネットワーク ログを調べれば個々の要求に関する詳細を取得できます。 一般に、要求が失敗した理由は、Storage サービスから返される HTTP 状態コードに示されます。
Note
一時的なネットワーク状態やアプリケーション エラーによるエラーなど、断続的なエラーが発生する可能性があることに注意してください。
次のリソースは、ストレージ関連の状態コードおよびエラー コードの理解に役立ちます。
- 一般的な REST API エラー コード
- Blob Service のエラー コード
- Queue Service のエラー コード
- Table Service のエラー コード
- ファイル サービスのエラー コード
Storage エミュレーターの問題
Azure SDK には、開発用ワークステーションで実行できるストレージ エミュレーターが含まれています。 このエミュレーターは、Azure ストレージ サービスのほとんどの動作をシミュレートし、開発とテスト中に役立ちます。これにより、Azure サブスクリプションと Azure ストレージ アカウントを必要とせずに、Azure ストレージ サービスを使用するアプリケーションを実行できます。
このガイドの「 トラブルシューティングガイダンス 」セクションでは、ストレージ エミュレーターを使用して発生する一般的な問題について説明します。
ストレージ ログ ツール
ストレージ ログによって、Azure ストレージ アカウントのストレージ要求をサーバー側でログに記録できます。 サーバー側のログを有効にしてログ データにアクセスする方法の詳細については、 ストレージ ログの有効化とログデータへのアクセスに関するページをご覧ください。
Storage Client Library for .NET では、アプリケーションで実行されたストレージ操作に関するクライアント側のログ データを収集できます。 詳細については、「 .NET ストレージ クライアント ライブラリによるクライアント側のログ」を参照してください。
Note
(SAS の許可エラーなどの) 状況によっては、サーバー側の ストレージ ログには要求データが見つからないエラーを、ユーザーから報告される可能性があります。 ストレージ クライアント ライブラリのログ機能を使用して問題の原因がクライアント側にあるか調べたり、ネットワーク監視ツールを使用してネットワークを調べたりできます。
ネットワーク ログ ツールの使用
クライアントとサーバーの間のトラフィックをキャプチャして、クライアントとサーバーの間で交換されたデータおよび基礎ネットワークの状態に関する詳細な情報を取得できます。 便利なネットワーク ログ ツールには次のようなものがあります。
- Fiddler は、無料の Web デバッグ プロキシです。HTTP および HTTPS の要求および応答メッセージのヘッダーおよびペイロード データを調べることができます。 詳細については、「付録 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャ」を参照してください。
- Microsoft Network Monitor (Netmon) および Wireshark は、無料のネットワーク プロトコル アナライザーです。さまざまな種類のネットワーク プロトコルの詳細なパケット情報を表示できます。 Wireshark の詳細については、「 Appendix 2: Wireshark を使用したネットワーク トラフィックのキャプチャを参照してください。
- クライアント マシンが Azure Storage サービスにネットワーク経由で接続できることを確認するための基本的な接続テストを実行する目的で、クライアント側で標準的な ping ツールを使用することはできません。 しかし、 tcping ツールを使用して接続を確認することはできます。
多くの場合、問題の診断には ストレージ ログおよび ストレージ クライアント ライブラリのログ データで十分ですが、状況によっては、これらのネットワーク ログ ツールを使用して取得できる詳細な情報が必要になります。 たとえば、Fiddler を使用して HTTP および HTTPS メッセージを表示し、Storage サービスとの間で送受信されたヘッダーおよびペイロード データを確認して、クライアント アプリケーションがどのようにストレージ操作を再試行したのかを調べることができます。 Wireshark などのパケット レベルで動作するプロトコル アナライザーを使用して TCP データを表示し、失われたパケットや接続問題をトラブルシューティングすることができます。
エンド ツー エンド トレース
各種ログ ファイルを使用したエンド ツー エンド トレースは、潜在的な問題を調査するための有用な手法です。 メトリック データの日付/時刻情報を使用して、問題のトラブルシューティングに役立つ詳細情報をログ ファイルの検索を開始する場所を示すことができます。
ログ データの関連付け
クライアント アプリケーション、ネットワーク トレース、およびサーバー側ストレージ ログからログを表示する場合は、さまざまなログ ファイル間で要求を関連付けることができることが重要です。 ログ ファイルには、相関 ID として役立つ多数の各種フィールドが含まれます。 クライアント要求 ID は、各種ログのエントリを相関付けるために使う最も役立つフィールドです。 ただし、サーバー要求 ID またはタイムスタンプを使用すると便利な場合があります。 以下のシナリオは、こうしたオプションの詳細を示しています。
クライアント要求 ID
ストレージ クライアント ライブラリは、要求ごとに固有のクライアント要求 ID を自動生成します。
- ストレージ クライアント ライブラリによって作成されるクライアント側のログでは、クライアント要求 ID は、要求に関連するすべてのログ エントリの
Client Request IDフィールドに表示されます。 - Fiddler によってキャプチャされたネットワーク トレースでは、クライアント要求 ID は、
x-ms-client-request-idHTTP ヘッダー値として要求メッセージに表示されます。 - サーバー側の Storage Logging ログの場合、クライアント要求 ID は クライアント要求 ID 列に表示されます。
Note
複数の要求が同じクライアント要求 ID を共有する場合があります。これは、クライアントがこの値を割り当てることができるからです (一方、Storage クライアント ライブラリは新しい値を自動的に割り当てます)。 クライアントが再試行を行う際には、すべての試行で同じクライアント要求 ID が共有されます。 クライアントから送信されるバッチの場合、バッチのクライアント要求 ID は 1 つだけです。
サーバー要求 ID
Storage サービスにより、サーバー要求 ID が自動生成されます。
- サーバー側のストレージ ログ ログでは、サーバー要求 ID が
Request ID header列に表示されます。 - Fiddler によってキャプチャされたネットワーク トレースでは、サーバー要求 ID が応答メッセージに
x-ms-request-idHTTP ヘッダー値として表示されます。 - ストレージ クライアント ライブラリが作成するクライアント側のログでは、サーバー要求 ID が、サーバー応答の詳細を示すログ エントリの
Operation Text列に表示されます。
Note
Storage サービスは受け取るすべての要求に対して必ず固有のサーバー要求 ID を割り当て、クライアントが実行するすべての再試行操作およびバッチに含まれるすべての操作において、サーバー要求 ID が固有になるようにします。
次のコード サンプルは、カスタム クライアント要求 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();
}
}
タイムスタンプ
またタイムスタンプを使用して、関連するログ エントリを見つけることもできます。ただし、クライアントとサーバー間で存在する可能性があるクロック スキューに注意してください。 サーバー側の項目は、クライアントのタイムスタンプを基準として前後に 15 分ずつずらして一致項目を検索してください。 メトリックが含まれる BLOB 用の BLOB メタデータは、BLOB で格納されているメトリックの時間範囲を示しています。 この時間範囲は、同じ分数または時間で多くのメトリック BLOB が含まれる場合に役立ちます。
トラブルシューティング ガイダンス
このセクションは、Azure Storage サービスを使用するときにご使用のアプリケーションで生じる可能性がある一般的な問題のいくつかを診断したりトラブルシューティングしたりするために役立ちます。 以下のリストを使用して、特定の問題に関連する情報を見つけてください。
デシジョン ツリーのトラブルシューティング
問題は、Storage サービスのいずれかのパフォーマンスと関連がありますか。
- メトリックは、AverageE2ELatency が高く、AverageServerLatency が低いを示します。
- メトリックは AverageE2ELatency が低く、AverageServerLatency が低いことが示されますが、クライアントでは待機時間が長くなっています。
- メトリックは AverageServerLatency が高く表示されます。
- キューでのメッセージ配信に予期しない遅延が発生しています。
問題は、Storage サービスのいずれかの可用性と関連がありますか。
- メトリックは、PercentThrottlingError の増加を示します。
- メトリックは、PercentTimeoutError の増加を示します。
- メトリックは、PercentNetworkError の増加を示します。
クライアント アプリケーションは、Storage サービスから HTTP 4XX (404 など) の応答を受信しましたか。
- クライアントは HTTP 403 (禁止) メッセージを受信しています。
- クライアントは HTTP 404 (見つかりません) メッセージを受信しています。
- クライアントが HTTP 409 (競合) のメッセージを受け取る
メトリックは、トランザクション状態が ClientOtherErrors の操作を持つ低い PercentSuccess または分析ログ エントリを示します。
容量メトリックは、ストレージ容量の使用量の予期しない増加を示します。
開発またはテストにストレージ エミュレーターを使用すると問題が発生します。
Azure SDK for .NET のインストールで問題が発生しています。
メトリックが示す AverageE2ELatency が高く、AverageServerLatency が低い
Azure Portal 監視ツールに基づいて示されている以下の例の場合、AverageE2ELatency が AverageServerLatency よりもかなり高くなっています。
Storage サービスは、正常な要求に対するメトリック AverageE2ELatency のみを計算します。AverageServerLatency と違い、クライアントでデータを送信し、Storage サービスから確認応答を受け取るまでにかかる時間が含まれます。 そのため、 AverageE2ELatency と AverageServerLatency の違いは、クライアント アプリケーションの応答が遅いか、ネットワーク上の状態が原因である可能性があります。
Note
Storage Logging ログ データの個々のストレージ操作に関して、E2ELatency と ServerLatency を表示することもできます。
クライアントのパフォーマンス上の問題に関する調査
クライアントが応答が遅くなる原因としては、使用可能な接続またはスレッドの数が限られているか、CPU、メモリ、ネットワーク帯域幅などのリソースが不足している可能性があります。 より効率的にクライアント コードを変更するか (たとえば、ストレージ サービスへの非同期呼び出しを使用して)、またはより大きな仮想マシン (より多くのコアとより多くのメモリを持つ) を使用して、問題を解決できる場合があります。
テーブル サービスとキュー サービスの場合、Nagle アルゴリズムは、AverageServerLatencyと比較してAverageE2ELatency が高いを引き起こす可能性もあります。 詳細については、「 Nagle のアルゴリズムは小さな要求に対してフレンドリではありませんを参照してください。 System.Net名前空間の ServicePointManager クラスを使用して、コード内の Nagle アルゴリズムを無効にすることができます。 この操作は、既に開かれている接続には影響を与えないため、アプリケーションで Table サービスまたは Queue サービスを呼び出す前に実行する必要があります。 次の例は、worker ロールの Application_Start メソッドに由来します。
var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;
クライアント側のログを調べて、クライアント アプリケーションが送信している要求の数を確認し、一般的な要求を確認する必要があります。CPU、.NET ガベージ コレクション、ネットワーク使用率、メモリなど、クライアントでの NET 関連のパフォーマンスのボトルネック。 .NET クライアント アプリケーションのトラブルシューティングの開始点として、「 Debugging, Tracing, and Profiling (デバッグ、トレース、およびプロファイリング)」を参照してください。
ネットワーク待ち時間に関する問題の調査
一般的に、エンド ツー エンドの待ち時間が長くなるのは、ネットワークの一時的な状態に起因します。 Wireshark などのツールを使用して、破棄されたパケットなどの一時的なネットワークの問題と永続的なネットワークの問題の両方を調査できます。
Wireshark を使用したネットワークの問題のトラブルシューティングの詳細については、「 Appendix 2: Wireshark を使用したネットワーク トラフィックのキャプチャを参照してください。
メトリックでは AverageE2ELatency も AverageServerLatency も低いのにクライアントで大きな遅延が発生している
このシナリオの場合、最も可能性が高い原因は、Storage サービスに到達するストレージ要求の遅延です。 クライアントの要求が BLOB サービスにうまく送られない原因を調査する必要があります。
要求送信でクライアントに遅延が生じる理由の 1 つとして、使用可能な接続またはスレッドの数が制限されていることが考えられます。
また、クライアントが複数回再試行を実行しているかどうかを確認し、その理由を調査します。 クライアントが複数回再試行しているかどうかを確認するには、以下を実行できます。
- Storage Analytics のログを調べます。 再試行が複数回発生している場合は、クライアント要求 ID が同じでサーバー要求 ID が異なる複数の操作があります。
- クライアントのログを調べます。 詳細ログに、再試行が発生したことが示されます。
- コードをデバッグし、要求に関連付けられている
OperationContextオブジェクトのプロパティを確認します。 操作が再試行された場合、RequestResultsプロパティには複数の一意のサーバー要求 ID が含まれます。 各要求の開始時刻と終了時刻をチェックすることもできます。 詳細については、「 サーバー要求 ID」セクションのコード サンプルを参照してください。
クライアントに問題がない場合、パケット損失などの考えられるネットワーク問題について調査してください。 Wireshark などのツールを使用して、ネットワーク問題を調査できます。
Wireshark を使用したネットワークの問題のトラブルシューティングの詳細については、「 Appendix 2: Wireshark を使用したネットワーク トラフィックのキャプチャを参照してください。
メトリックが高い AverageServerLatency を示す
BLOB ダウンロード要求の AverageServerLatency が高い場合、Storage Logging ログを使用して、同じ BLOB (または BLOB セット) に対して反復されている要求がないかどうかを確かめます。 BLOB アップロード要求の場合は、クライアントが使用しているブロック サイズを調査する必要があります (たとえば、サイズが 64 K 未満のブロックは、読み取りも 64 K 未満のチャンクに含まれている場合を除き、オーバーヘッドが発生する可能性があります)。また、複数のクライアントがブロックを同じ BLOB に並列にアップロードしている場合などです。 また、1 秒あたりのスケーラビリティ ターゲットを超える要求数の急増がないか、分単位のメトリックを確認する必要があります。 詳細については、「 Metrics で PercentTimeoutError の増加を示すを参照してください。
同じ BLOB または BLOB のセットに対して要求が繰り返し発生したときに BLOB ダウンロード要求の AverageServerLatency が高い場合は、Azure Cache または Azure Content Delivery Network (CDN) を使用してこれらの BLOB をキャッシュすることを検討してください。 アップロード要求に関しては、ブロック サイズを大きくすることによってスループットを改善できます。 テーブルに対するクエリの場合、同じクエリ操作を実行し、データが頻繁に変更されないクライアントにクライアント側のキャッシュを実装することもできます。
また AverageServerLatency 値が高いという症状は、テーブルやクエリがうまく設計されていないために、スキャン操作が生じたり、前後にアンチ パターンが存在したりする場合に起こり得ます。 詳細については、「 メトリックは PercentThrottlingError の増加を示していますを参照してください。
キューのメッセージ配信で予期しない遅延が発生する
アプリケーションがキューにメッセージを追加してからキューから読み取れるまでの間に遅延が発生している場合は、次の手順を実行して問題を診断します。
- アプリケーションがキューにメッセージを正常に追加していることを確認します。 成功する前に、アプリケーションが
AddMessageメソッドを複数回再試行していないことを確認します。 ストレージ クライアント ライブラリ ログには、ストレージ操作の再試行の反復が表示されます。 - キューにメッセージを追加する worker ロールと、キューからメッセージを読み取る worker ロールの間にクロック スキューがないことを確認します。 クロック スキューにより、処理に遅延があるかのように表示されます。
- キューからのメッセージを読み取る worker ロールに障害がないことを確かめます。 キュー クライアントが
GetMessageメソッドを呼び出したが、受信確認で応答できない場合、メッセージは、invisibilityTimeout期間が経過するまでキューに表示されなくなります。 有効期限が切れた時点で、メッセージは再び処理可能になります。 - キューの長さが時間の経過とともに大きくなっているかどうかを確認してください。 これは、他のワーカーがキューに配置しているすべてのメッセージを処理するのに十分なワーカーがない場合に発生する可能性があります。 また、メトリックを調べて、削除要求が失敗しているかどうかを確認し、メッセージのデキュー数を確認します。これは、メッセージの削除試行が繰り返し失敗したことを示している可能性があります。
- 通常よりも長期間に渡り、予想された E2ELatency 値および ServerLatency 値よりも高くなっているキュー操作がないかどうか、Storage Logging ログを調べます。
メトリックが PercentThrottlingError の増加を示す
Storage サービスのスケーラビリティ ターゲットを超えると、調整エラーが生じます。 Storage サービスは、1 つのクライアントやテナントがサービスを占有してしまうことがないよう、調整を行います。 詳細については、「Standard Storage アカウントのスケーラビリティとパフォーマンスのターゲット」を参照し、ストレージ アカウントのスケーラビリティ ターゲットと、ストレージ アカウントのパーティション用のパフォーマンス ターゲットの詳細を確認してください。
PercentThrottlingError メトリックに、調整エラーで失敗した要求の割合が増加している場合は、次の 2 つのシナリオのいずれかを調査する必要があります。
PercentThrottlingError の増加は、多くの場合、ストレージ要求の数の増加と同時に、またはアプリケーションを最初にロード テストするときに発生します。 また、ストレージ操作により、「503 サーバーはビジー状態」または「500 操作タイムアウト」HTTP ステータス メッセージがクライアントで示されることもあります。
PercentThrottlingError の一時的増加
アプリケーションのアクティビティが高い期間と一致する PercentThrottlingError の値が急増している場合は、クライアントで再試行のための指数関数的 (線形ではない) バックオフ戦略を実装できます。 バックオフ再試行により、パーティションに対する即時の負荷が軽減され、アプリケーションがトラフィックの急増をスムーズにするのに役立ちます。 ストレージ クライアント ライブラリを使って再試行ポリシーを実装する方法の詳細については、「Microsoft.Azure.Storage.RetryPolicies 名前空間」を参照してください。
Note
また、 PercentThrottlingError アプリケーションのアクティビティが高い期間と一致しない値が急増する場合もあります。 最も可能性の高い原因は、負荷分散を向上させるためにパーティションを移動するストレージ サービスです。
PercentThrottlingError の永続的な増加
PercentThrottlingError の値が一貫して高い場合はトランザクション ボリュームが永続的に増加した後、またはアプリケーションで初期ロード テストを実行する場合は、アプリケーションがストレージ パーティションをどのように使用しているか、およびストレージ アカウントのスケーラビリティ ターゲットに近づいているかどうかを評価する必要があります。 たとえば、(1 つのパーティションとしてカウントされる) キューで調整エラーが発生する場合は、追加のキューを使用してトランザクションを複数のパーティションに分散することを検討してください。 テーブルで調整エラーが発生する場合、より広い範囲のパーティション キー値を使用して複数のパーティションにトランザクションを分散させるため、異なるパーティション スキームを使用することを検討する必要があります。 この問題の一般的な原因の 1 つは、パーティション キーとして日付を選択し、特定の日のすべてのデータが 1 つのパーティションに書き込まれる先頭/追加のアンチパターンです。読み込み中、書き込みのボトルネックが発生する可能性があります。 別のパーティション設計を考慮するか、Blob Storage を使用する方がよいソリューションとなるかどうかを考えてください。 また、トラフィックの急増の結果として調整が発生しているかどうかを確認し、要求のパターンを平滑化する方法を調査します。
トランザクションを複数のパーティションに分散する場合であっても、ストレージ アカウントに設定されているスケーラビリティ限界に注意してください。 たとえば、10 個のキューを使用し、1 秒あたり最大 2,000 1 KB のメッセージを処理した場合、ストレージ アカウントの全体的な上限は 1 秒あたり 20,000 メッセージになります。 1 秒あたり 20,000 を超えるエンティティを処理する必要がある場合は、複数のストレージ アカウントを使用することを検討してください。 また、要求とエンティティのサイズは、ストレージ サービスがクライアントを調整するタイミングに影響を与える点にも注意してください。 要求とエンティティが大きい場合は、より早く調整される可能性があります。
クエリの設計が非効率的な場合も、テーブル パーティションのスケーラビリティ限界に達する原因となる可能性があります。 たとえば、1 つのパーティションのエンティティの 1% だけを選択するフィルターが指定されたクエリが、パーティション内のすべてのエンティティをスキャンする場合、各エンティティにアクセスする必要があります。 エンティティを読み取る操作それぞれが、パーティション内のトランザクション数合計に含まれるので、すぐにスケーラビリティ ターゲットに達してしまいます。
Note
パフォーマンス テストを実行すると、アプリケーションにおける非効率的なクエリ設計が明らかになります。
メトリックが PercentTimeoutError の増加を示す
メトリックが、いずれかの Storage サービスの PercentTimeoutError が増加していることを示しています。 同時に、クライアントは、ストレージ操作により「500 操作タイムアウト」HTTP ステータス メッセージを大量に受け取ります。
Note
パーティションを新しいサーバーに移動するときに、Storage サービスの負荷分散要求としてタイムアウト エラーが一時的に表示される場合もあります。
PercentTimeoutError メトリックは、ClientTimeoutError、AnonymousClientTimeoutError、SASClientTimeoutError、ServerTimeoutError、AnonymousServerTimeoutError、SASServerTimeoutError の各メトリックを統合したメトリックです。
サーバー タイムアウトは、サーバー上のエラーが原因で生じます。 クライアントのタイムアウトは、サーバー上の操作がクライアントで指定されたタイムアウトを超えたために発生します。たとえば、ストレージ クライアント ライブラリを使用するクライアントは、QueueRequestOptions クラスの ServerTimeout プロパティを使用して、操作のタイムアウトを設定できます。
サーバー タイムアウトは、Storage サービスに問題があることを示します。この場合、さらに調査が必要です。 サービスのスケーラビリティの限界に達したかどうかを示すメトリック、およびこの問題の原因となっている可能性があるトラフィックの急増を示すメトリックを使用できます。 問題が断続的な場合、サービスにおける負荷分散アクティビティが原因となっている可能性があります。 問題が解決せず、アプリケーションがサービスのスケーラビリティの限界に達したことが原因ではない場合には、サポートの問題をご報告ください。 クライアントのタイムアウトの場合は、タイムアウトがクライアントで適切な値に設定されているかどうかを判断し、クライアントで設定されたタイムアウト値を変更するか、ストレージ サービスの操作のパフォーマンスを向上させる方法 (たとえば、テーブル クエリの最適化やメッセージのサイズの縮小など) を調査する必要があります。
メトリックが PercentNetworkError の増加を示す
メトリックが、いずれかの Storage サービスの PercentNetworkError が増加していることを示しています。 PercentNetworkError メトリックは、NetworkError、AnonymousNetworkError、SASNetworkError の各メトリックの集計です。 このエラーは、クライアントがストレージ要求を出す際に Storage サービスによりネットワーク エラーが検出されると生じます。
多くの場合、このエラーの原因は、Storage サービスでタイムアウト期間が切れる前にクライアントが切断することです。 クライアントのコードを調べて、Storage サービスからクライアントが切断した理由とタイミングを把握してください。 Wireshark または Tcping を使用して、クライアントからのネットワーク接続の問題を調査することもできます。 こうしたツールについては、 付録で取り上げられています。
クライアントが HTTP 403 (許可されていません) のメッセージを受け取る
クライアント アプリケーションが HTTP 403 (許可されていません) エラーをスローする場合、可能性の高い原因は、クライアントがストレージ要求を送信するときに期限切れの Shared Access Signature (SAS) を使用していることです (原因の他の可能性としては、クロック スキュー、無効なキー、空のヘッダーなどがあります)。 有効期限が切れた SAS キーが原因の場合、サーバー側のストレージ ログ ログ データにエントリは表示されません。 以下の表に、この問題が生じたときにストレージ クライアント ライブラリによって生成されるクライアント側のログのサンプルを示します。
| source | 詳細度 | 詳細度 | クライアント要求 ID | [操作テキスト] |
|---|---|---|---|---|
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | Starting operation with location Primary per location mode PrimaryOnly. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | Starting synchronous request to https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | Waiting for response. |
| Microsoft.Azure.Storage | 警告 | 2 | 85d077ab -… | Exception thrown while waiting for response: The remote server returned an error: (403) Forbidden. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | Response received. Status code = 403, Request ID = <Request ID>, Content-MD5 = , ETag = . |
| Microsoft.Azure.Storage | 警告 | 2 | 85d077ab -… | Exception thrown during the operation: The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | Checking if the operation should be retried. Retry count = 0, HTTP status code = 403, Exception = The remote server returned an error: (403) Forbidden.. |
| Microsoft.Azure.Storage | Information | 3 | 85d077ab -… | The next location has been set to Primary, based on the location mode. |
| Microsoft.Azure.Storage | エラー | 1 | 85d077ab -… | Retry policy did not allow for a retry. Failing with The remote server returned an error: (403) Forbidden. |
このシナリオでは、クライアントが SAS トークンをサーバーに送信する前にトークンが期限切れになった理由を調査しなければなりません。
- 通常、クライアントがすぐに使用する SAS を作成する場合は、開始時刻を設定しないでください。 現在の時刻を使用して SAS を生成するホストとストレージ サービスの間に小さなクロックの違いがある場合、ストレージ サービスがまだ有効ではない SAS を受信する可能性があります。
- SAS で非常に短い有効期限を設定しないでください。 ここでも、SAS を生成するホストとストレージ サービスのクロックの違いが小さいと、SAS の有効期限が予想よりも早く切れる可能性があります。
- SAS キーの version パラメーター (たとえば、
sv=2015-04-05) は、使用しているストレージ クライアント ライブラリのバージョンと一致しますか? 常に最新バージョンの ストレージ クライアント ライブラリを使用することをお勧めします。 - ストレージ アクセス キーを再生成すると、既存の SAS トークンが無効になる可能性があります。 この状況は、SAS トークンを生成する際にクライアント アプリケーションがキャッシュする有効期限を長く設定していると、問題が生じることがあります。
Storage クライアント ライブラリを使用して SAS トークンを生成している場合、有効なトークンの作成が容易です。 ただし、Storage REST API を使用し、手動で SAS トークンを構成している場合は、Shared Access Signature によるアクセスの委任に関するトピックをご覧ください。
クライアントが HTTP 404 (見つからない) のメッセージを受け取る
クライアント アプリケーションが "HTTP 404 (Not found)" というメッセージをサーバーから受け取る場合、クライアントが使用しようとしていたオブジェクト (エンティティ、テーブル、BLOB、コンテナー、キューなど) が Storage サービス内に存在しないことを意味します。 これには以下のようなさまざまな理由が考えられます。
- クライアントまたは別のプロセスがそのオブジェクトを以前に削除した。
- Shared Access Signature (SAS) 承認の問題。
- クライアント側の JavaScript コードにオブジェクトへのアクセス許可がない。
- ネットワーク障害。
クライアントまたは別のプロセスがそのオブジェクトを以前に削除した
クライアントがストレージ サービス内のデータの読み取り、更新、または削除を試みるシナリオでは、通常、対象のオブジェクトをストレージ サービスから削除した以前の操作をサーバー側でログに記録して簡単に識別できます。 多くの場合、ログ データに別のユーザーまたはプロセスがオブジェクトを削除したことが示されています。 ストレージ ログのサーバー側のログでは、operation-type 列および requested-object-key 列からクライアントがオブジェクトを削除したことが分かります。
クライアントがオブジェクトを挿入しようとしているシナリオでは、クライアントが新しいオブジェクトを作成していることを考えると、これが HTTP 404 (Not found) 応答になる理由はすぐには明らかでない場合があります。 ただし、クライアントが BLOB を作成している場合は、BLOB コンテナーを見つけることができる必要があります。 クライアントがメッセージを作成している場合は、キューを検索できる必要があります。 また、クライアントが行を追加する場合は、テーブルを検索できる必要があります。
ストレージ クライアント ライブラリのクライアント側ログを使用して、クライアントが Storage サービスに特定の要求を送ったときの状況を詳しく調べることができます。
Storage クライアント ライブラリによって生成された以下のクライアント側のログには、作成する BLOB 用のコンテナーをクライアントが検出できないという問題が示されています。 このログには、以下のストレージ操作の詳細が示されています。
| 要求 ID | 操作 |
|---|---|
| 07b26a5d-... | DeleteIfExists BLOB コンテナーを削除するメソッド。 この操作には、コンテナーの存在を確認する HEAD 要求が含まれていることに注意してください。 |
| e2d06d78… | CreateIfNotExists BLOB コンテナーを作成するメソッド。 この操作には、コンテナーの存在を確認する HEAD 要求が含まれていることに注意してください。 HEADは 404 メッセージを返しますが、続行されます。 |
| de8b1c3c-... | UploadFromStream BLOB を作成するメソッド。 PUT要求は 404 メッセージで失敗します。 |
ログ エントリ:
| 要求 ID | [操作テキスト] |
|---|---|
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = HEAD............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:11 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 200, Request ID = eeead849-...Content-MD5 = , ETag = "0x8D14D2DC63D059B". |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| 07b26a5d-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| 07b26a5d-... | StringToSign = DELETE............x-ms-client-request-id:07b26a5d-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| 07b26a5d-... | Waiting for response. |
| 07b26a5d-... | Response received. Status code = 202, Request ID = 6ab2a4cf-..., Content-MD5 = , ETag = . |
| 07b26a5d-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| 07b26a5d-... | Downloading response body. |
| 07b26a5d-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = HEAD............x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Starting synchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | StringToSign = PUT...64.qCmF+TQLPhq/YYK50mP9ZQ==........x-ms-blob-type:BlockBlob.x-ms-client-request-id:de8b1c3c-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer/blobCreated.txt. |
| de8b1c3c-... | Preparing to write request data. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Response received. Status code = 404, Request ID = 353ae3bc-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Response headers were processed successfully, proceeding with the rest of the operation. |
| e2d06d78-... | Downloading response body. |
| e2d06d78-... | Operation completed successfully. |
| e2d06d78-... | Starting asynchronous request to https://domemaildist.blob.core.windows.net/azuremmblobcontainer. |
| e2d06d78-... | StringToSign = PUT...0.........x-ms-client-request-id:e2d06d78-....x-ms-date:Tue, 03 Jun 2014 10:33:12 GMT.x-ms-version:2014-02-14./domemaildist/azuremmblobcontainer.restype:container. |
| e2d06d78-... | Waiting for response. |
| de8b1c3c-... | Writing request data. |
| de8b1c3c-... | Waiting for response. |
| e2d06d78-... | Exception thrown while waiting for response: The remote server returned an error: (409) Conflict.. |
| e2d06d78-... | Response received. Status code = 409, Request ID = c27da20e-..., Content-MD5 = , ETag = . |
| e2d06d78-... | Downloading error response body. |
| de8b1c3c-... | Exception thrown while waiting for response: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Response received. Status code = 404, Request ID = 0eaeab3e-..., Content-MD5 = , ETag = . |
| de8b1c3c-... | Exception thrown during the operation: The remote server returned an error: (404) Not Found.. |
| de8b1c3c-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (404) Not Found.. |
| e2d06d78-... | Retry policy did not allow for a retry. Failing with The remote server returned an error: (409) Conflict.. |
この例では、クライアントが CreateIfNotExists メソッドからの要求 (要求 ID e2d06d78...) と UploadFromStream メソッドからの要求 (de8b1c3c-...) をインターリーブしていることを示しています。このインターリーブは、クライアント アプリケーションがこれらのメソッドを非同期的に呼び出しているために発生します。 必ず、コンテナーを作成してからそのコンテナーの BLOB にデータをアップロードするように、クライアントの非同期コードを変更してください。 すべてのコンテナーをあらかじめ作成しておくことをお勧めします。
共有アクセス署名 (SAS) 認証の問題
クライアント アプリケーションが、操作に必要なアクセス許可が含まれていない SAS キーを使用しようとすると、Storage サービスは "HTTP 404 (Not found)" というメッセージをクライアントに返します。 同時に、メトリック内の SASAuthorizationError に対して 0 以外の値も表示されます。
以下の表に、ストレージ ログのログ ファイルのサーバー側ログ メッセージの例を示します。
| 名前 | 値 |
|---|---|
| 要求の開始時刻 | 2014-05-30T06:17:48.4473697Z |
| 操作の種類 | GetBlobProperties |
| 要求の状態 | SASAuthorizationError |
| HTTP 状態コード | 404 |
| 認証の種類 | SAS |
| サービスの種類 | BLOB |
| 要求 URL | https://domemaildist.blob.core.windows.net/azureimblobcontainer/blobCreatedViaSAS.txt |
| ?sv=2014-02-14&sr=c>si=mypolicy&sig=XXXXX>api-version=2014-02-14 | |
| 要求 ID ヘッダー | <要求 ID ヘッダー> |
| クライアント要求 ID | <クライアント要求 ID> |
アクセス許可が付与されていない操作をクライアント アプリケーションが実行しようとしている理由を調査します。
クライアント側の JavaScript コードにオブジェクトへのアクセス許可がない
JavaScript クライアントを使用していて Storage サービスから HTTP 404 メッセージが返された場合は、以下の JavaScript エラーをブラウザーで確認します。
SEC7120: 配信元 http://localhost:56309 Access-Control-Allow-Origin ヘッダーに見つかりません。
SCRIPT7002: XMLHttpRequest: ネットワーク エラー 0x80070005、アクセスが拒否されました。
Note
クライアント側の JavaScript の問題をトラブルシューティングするときには、Internet Explorer の F12 開発者ツールを使用して、ブラウザーと Storage サービスの間で交換されたメッセージをトレースできます。
これらのエラーは、Web ページがそのページのドメインとは異なるドメインの API を呼び出さないようにする Same Origin Policy セキュリティ制限を Web ブラウザーで実装しているために発生します。
JavaScript の問題を回避するには、クライアントがアクセスしているストレージ サービスのクロスオリジン リソース共有 (CORS) を構成します。 詳細については、 Azure Storage サービスでのクロス オリジン リソース共有 (CORS) のサポートに関するページをご覧ください。
以下のコード サンプルは、Contoso ドメインで実行される JavaScript に対して Blob Storage サービスの 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);
ネットワーク エラー
状況によっては、ネットワーク パケットの紛失が原因で、Storage サービスが HTTP 404 メッセージをクライアントに返すことがあります。 たとえば、クライアント アプリケーションがテーブル サービスからエンティティを削除すると、クライアントがストレージ例外をスローし、Table Service から "HTTP 404 (Not Found)" 状態メッセージが報告されることがわかります。 Table Storage サービスのテーブルを調べると、要求どおりにサービスがエンティティを削除したことがわかります。
クライアントの例外の詳細には、要求のテーブル サービスによって割り当てられた要求 ID (7e84f12d...) が含まれます。 この情報を使用して、ログ ファイルの request-id-header 列を検索することで、サーバー側ストレージ ログ内の要求の詳細を検索できます。 メトリックを使用して、このようなエラーが発生した時刻を特定し、エラーがメトリックに記録された時刻に基づいてログ ファイルを検索することもできます。 このログ エントリには、状態メッセージ "HTTP (404) Client Other Error" を出して削除が失敗したことが示されます。 同じログ エントリには、 client-request-id 列 (813ea74f...) にクライアントによって生成された要求 ID も含まれます。
サーバー側ログには、同じエンティティと同じクライアントからの削除操作が成功した場合に、同じ client-request-id 値 (813ea74f...) を持つ別のエントリも含まれます。 この成功した削除操作は、失敗した削除要求の直前に発生しています。
このシナリオの最も可能性の高い原因は、クライアントがエンティティの削除要求を Table Service に送信したが、成功したがサーバーから受信確認を受信しなかった (おそらく一時的なネットワークの問題が原因である) ことが原因です。 その後、クライアントは (同じ client-request-idを使用して) 操作を自動的に再試行し、エンティティが既に削除されているため、この再試行に失敗しました。
この問題が頻繁に発生する場合は、クライアントが Table サービスからの受信確認の受け取りに失敗している原因を調べてください。 問題が断続的に発生する場合は、クライアントで "HTTP (404) 未検出" エラーをトラップしてログに記録する一方でクライアントの実行を継続できるようにする必要があります。
クライアントが HTTP 409 (競合) のメッセージを受け取る
次の表は、2 つのクライアント操作のサーバー側ログからの抽出を示しています。 DeleteIfExists 直後に、同じ BLOB コンテナー名を使用して CreateIfNotExists します。 各クライアント操作では、2 つの要求がサーバーに送信され、最初にコンテナーが存在するかどうかを確認する GetContainerProperties 要求が送信され、その後に DeleteContainer または CreateContainer 要求が送信されます。
| タイムスタンプ | 操作 | 結果 | コンテナー名 | クライアント要求 ID |
|---|---|---|---|---|
| 05:10:13.7167225 | GetContainerProperties |
200 | mmcont | c9f52c89-… |
| 05:10:13.8167325 | DeleteContainer |
202 | mmcont | c9f52c89-… |
| 05:10:13.8987407 | GetContainerProperties |
404 | mmcont | bc881924-… |
| 05:10:14.2147723 | CreateContainer |
409 | mmcont | bc881924-… |
クライアント アプリケーションのコードは、同じ名前を使用して BLOB コンテナーを削除し、すぐに再作成します。 CreateIfNotExists メソッド (クライアント要求 ID bc881924-...) は、最終的に HTTP 409 (競合) エラーで失敗します。 クライアントが BLOB コンテナー、テーブル、またはキューを削除すると、名前が再び使用可能になるまでの短い期間があります。
削除/再作成のパターンをよく使用する場合、クライアント アプリケーションは、新規コンテナーの作成時に必ず一意のコンテナー名を使用する必要があります。
メトリックの示す PercentSuccess が低い、または分析ログ エントリの中にトランザクション ステータスが ClientOtherErrors の操作がある
PercentSuccess メトリックは、操作の HTTP 状態コードに基づいて、成功した操作の割合をキャプチャします。 状態コードが 2XX の操作は成功としてカウントされますが、状態コードが 3XX、4XX、5XX の範囲の操作は失敗としてカウントされ、 PercentSuccess メトリック値が下げられます。 サーバー側のストレージ ログ ファイルには、これらの操作が ClientOtherErrorsのトランザクション状態で記録されます。
これらの操作は正常に完了しているため、可用性などの他のメトリックには影響しません。 正常に実行されても失敗の HTTP 状態コードを返される可能性のある操作の例を以下に示します。
- ResourceNotFound (Not Found 404) (たとえば、
GET要求から存在しない BLOB まで)。 - たとえば、リソースが既に存在する
CreateIfNotExist操作の ResourceAlreadyExists (競合 409)。 - ConditionNotMet (Not Modified 304) は、たとえば、クライアントが
ETag値と HTTPIf-None-Matchヘッダーを送信して、前回の操作以降に更新された場合にのみイメージを要求する場合などの条件付き操作から取得されます。
ストレージ サービスが返す一般的な REST API エラー コードの一覧は、 Common REST API エラー コードページにあります。
ストレージ使用量の予期しない増加が容量メトリックに示される
突然、ストレージ アカウントの使用量に予期しない変化が発生した場合、まず、可用性メトリックを確認して理由を調べます。たとえば、領域を解放すると想定していたアプリケーション固有のクリーンアップ操作が、(領域の解放に使用する SAS トークンの期限が切れていたなどの理由で) 想定どおりに機能しなかったために削除要求の失敗の数が増加し、その結果、Blob Storage の使用量が増加した可能性があります。
開発またはテストでのストレージ エミュレーターの使用に起因する問題
通常は、Azure ストレージ アカウントの要件を回避するために、開発およびテスト中にストレージ エミュレーターを使用します。 ストレージ エミュレーターを使用する場合に発生する可能性のある一般的な問題を以下に示します。
- ストレージ エミュレーターで機能 "X" が機能していません。
- ストレージ エミュレーターを使用する場合、"HTTP ヘッダーの値が正しい形式ではありません" というエラーが発生しました。
- ストレージ エミュレーターを実行するには、管理特権が必要です。
機能 "X" がストレージ エミュレーターで機能しない
ストレージ エミュレーターは、ファイル サービスなどの Azure ストレージ サービスのすべての機能をサポートしているわけではありません。 詳細については、「 開発とテストのための Azure のストレージ エミュレーター使用」を参照してください。
ストレージ エミュレーターでサポートされない機能については、クラウドの Azure Storage サービスを使用してください。
ストレージ エミュレーターを使用するとエラー "HTTP ヘッダーのいずれかの値の形式が正しくありません" が発生する
ローカル ストレージ エミュレーターに対してストレージ クライアント ライブラリを使用するアプリケーションをテストしていて、 CreateIfNotExists などのメソッド呼び出しが失敗し、"いずれかの HTTP ヘッダーの値が正しい形式ではありません" というエラー メッセージが表示されます。これは、使用しているストレージ エミュレーターのバージョンが、使用しているストレージ クライアント ライブラリのバージョンをサポートしていないことを示します。 ストレージ クライアント ライブラリは、ヘッダー x-ms-version をすべての要求に追加します。 ストレージ エミュレーターが x-ms-version ヘッダーの値を認識しない場合、要求は拒否されます。
ストレージ ライブラリ クライアントのログを使用して、送信している x-ms-version header の値を確認できます。 Fiddler を使用してクライアント アプリケーションからの要求をトレースする場合は、 x-ms-version header の値を確認することもできます。
通常、ストレージ エミュレーターを更新せずに、最新バージョンのストレージ クライアント ライブラリをインストールして使用すると、この状況が発生します。 開発とテストには、最新バージョンのストレージ エミュレーターをインストールするか、エミュレーターの代わりにクラウド ストレージを使用する必要があります。
ストレージ エミュレーターの実行に管理者権限が必要になる
ストレージ エミュレーターを実行する際に、管理者の資格情報を入力するように求められます。 これは、ストレージ エミュレーターを初めて初期化する場合にのみ発生します。 ストレージ エミュレーターを初期化した後は、再度実行するための管理特権は必要ありません。
詳細については、「 開発とテストのための Azure のストレージ エミュレーター使用」を参照してください。 Visual Studio でストレージ エミュレーターを初期化することもできますが、その場合も管理者権限が必要になります。
Azure SDK for .NET のインストールで問題が発生する
SDK をインストールしようとすると、ローカル コンピューターにストレージ エミュレーターをインストールしようとすると失敗します。 インストール ログには、以下のメッセージのいずれかが含まれています。
- CAQuietExec: エラー: SQL インスタンスにアクセスできません
- CAQuietExec: エラー: データベースを作成できません
原因は、既存の LocalDB インストールに関する問題です。 既定では、Azure Storage サービスをシミュレートするときに、ストレージ エミュレーターは LocalDB を使用してデータを保持します。 SDK のインストールを試行する前に、コマンド プロンプト ウィンドウで次のコマンドを使用することによって、LocalDB インスタンスをリセットできます。
sqllocaldb stop v11.0
sqllocaldb delete v11.0
delete %USERPROFILE%\WAStorageEmulatorDb3*.*
sqllocaldb create v11.0
delete コマンドは、ストレージ エミュレーターの以前のインストールから古いデータベース ファイルを削除します。
Storage サービスで別の問題が発生する
これまでのトラブルシューティング セクションに、Storage サービスで発生している問題が含まれていない場合は、以下のアプローチによって問題を診断およびトラブルシューティングする必要があります。
- メトリックを調べて、予想されるベースラインの動作から何らかの変更があるかどうかを確認します。 メトリックから、問題が一時的か永続的か、および問題が影響を受けるストレージ操作を判断できる場合があります。
- メトリック情報を使用してサーバー側のログ データを検索することで、発生している問題に関するより詳細な情報を得ることができます。 その情報を基に、問題をトラブルシューティングして解決できる可能性があります。
- サーバー側のログの情報で問題を正常にトラブルシューティングできない場合は、ストレージ クライアント ライブラリのクライアント側ログを使用して、クライアント アプリケーションの動作と Fiddler や Wireshark などのツールを使用してネットワークを調査できます。
Fiddler の使用方法の詳細については、「 Appendix 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャを参照してください。
Wireshark の使用の詳細については、「 Appendix 2: Wireshark を使用したネットワーク トラフィックのキャプチャを参照してください。
付録
付録では、Azure Storage (およびその他のサービス) の問題を診断およびトラブルシューティングするときに役立つ可能性のあるいくつかのツールについて説明します。 これらのツールは Azure Storage の一部ではなく、一部はサードパーティ製品です。 そのため、これらの付録で説明されているツールは、Microsoft Azure または Azure Storage とのサポート契約には含まれません。 そのため、評価プロセスの一環として、これらのツールのプロバイダーから利用できるライセンスとサポート のオプションを確認する必要があります。
付録 1: Fiddler を使用した HTTP および HTTPS トラフィックのキャプチャ
Fiddler は、クライアント アプリケーションと、使用する Azure Storage サービスの間の HTTP および HTTPS トラフィックを分析するのに役立つツールです。
Note
Fiddler は HTTPS トラフィックをデコードできます。 Fiddler のドキュメントを注意深く読んで、それがどのように行われ、そのセキュリティへの影響を理解する必要があります。
この付録では、Fiddler をインストールしたローカル マシンと Azure Storage サービスの間のトラフィックをキャプチャするための Fiddler の構成方法について簡単に説明します。
Fiddler を起動すると、ローカル マシンの HTTP および HTTPS トラフィックのキャプチャが開始されます。 以下に、Fiddler の操作に役立ついくつかのコマンドを示します。
- トラフィックのキャプチャを停止および開始します。 メイン メニューで、 File に移動し、 Capture Traffic を選択してキャプチャのオンとオフを切り替えます。
- キャプチャしたトラフィック データを保存します。 メイン メニューで、 File に移動し、 保存を選択し、すべてのセッション 選択。 これにより、トラフィックをセッション アーカイブ ファイルに保存できます。 セッション アーカイブを後で再読み込みして分析したり、Microsoft サポートに要求された場合は送信したりできます。
Fiddler がキャプチャするトラフィックの量を制限するには、[ Filters ] タブで構成したフィルターを使用できます。次のスクリーンショットは、 contosoemaildist.table.core.windows.net ストレージ エンドポイントに送信されたトラフィックのみをキャプチャするフィルターを示しています。
付録 2: Wireshark を使用したネットワーク トラフィックのキャプチャ
Wireshark は、さまざまなネットワーク プロトコルの詳細なパケット情報を表示できるネットワーク プロトコル アナライザーです。
以下の手順は、Wireshark をインストールしたローカル マシンから Azure ストレージ アカウントの Table サービスへのトラフィックに関する詳細なパケット情報をキャプチャする方法を示しています。
ローカル マシンで Wireshark を起動します。
[Start] セクションで、インターネットに接続されているローカル ネットワーク インターフェイスを選択します。
Capture オプションを選択します。
フィルターを [Capture Filter] テキストボックスに追加します。 たとえば、
host contosoemaildist.table.core.windows.netは、 contosoemaildist ストレージ アカウント内の table service エンドポイントに送受信されるパケットのみをキャプチャするように Wireshark を構成します。 キャプチャ フィルターの完全な一覧を確認してください。![[Capture Filter] ボックスにフィルターを追加する方法を示すスクリーンショット。](media/storage-monitoring-diagnosing-troubleshooting/interface-list.png)
[スタート] を選択します。 Wireshark では、ローカル コンピューターでクライアント アプリケーションを使用するときに、Table Service エンドポイントに送受信されるすべてのパケットがキャプチャされるようになりました。
完了したら、メイン メニューの Capture>Stop を選択します。
キャプチャしたデータを Wireshark Capture ファイルに保存するには、メイン メニューの File>Save を選択します。
WireShark は、 [packetlist] ウィンドウに存在するエラーをすべて強調表示します。 Expert Info ウィンドウ (Analyze>Expert Info を選択) を使用して、エラーと警告の概要を表示することもできます。
![エラーと警告の概要を表示できる [Expert Info] ウィンドウを示すスクリーンショット。](media/storage-monitoring-diagnosing-troubleshooting/wireshark-expert-information.png)
アプリケーション レイヤーで見られる形で TCP データを表示するように選択することもできます。このためには、TCP データを右クリックしてから [Follow TCP Stream] を選択します。 これは、キャプチャ フィルターを使用せずにダンプをキャプチャした場合に便利です。 詳細については、Follow TCP Stream に関する記事を参照してください。
Note
Wireshark の使用方法の詳細については、『Wireshark Users Guide』を参照してください。
付録 4: Excel を使用したメトリックおよびログ データの表示
さまざまなツールを使用して、Excel に簡単に読み込んで表示したり分析したりできる区切り形式で、ストレージ メトリック データを Azure Table Storage からダウンロードすることができます。 Azure Blob Storage のストレージ ログ データは、既に、Excel に読み込み可能な区切り形式になっています。 ただし、 Storage Analytics ログ形式 と Storage Analytics メトリック テーブル スキーマの情報に基づいて、適切な列見出しを追加する必要があります。
BLOB ストレージからダウンロードしたストレージ ログ データを Excel にインポートするには、以下の手順に従います。
- [ Data ] メニューの [テキストから を選択。
- 表示するログ ファイルを参照し、 Import を選択します。
- テキストインポートウィザードの手順 1 でDelimitedを選択します。
テキストのインポート ウィザードの手順 1 で唯一の区切り記号として Semicolon を選択し、Text 修飾子として二重引用符を選択。 次に Finish を選択し、ブックにデータを配置する場所を選択します。
付録 5: Application Insights for Azure DevOps を使用した監視
パフォーマンスと可用性の監視の一部として、Azure DevOps 用の Application Insights 機能を使用することもできます。 このツールは、以下を実行できます。
- Web サービスが使用可能および応答可能であることを確認できます。 アプリが Web サイトであるか、Web サービスを使用するデバイス アプリであるかに関係なく、世界中の場所から数分ごとに URL をテストし、問題があるかどうかを知らせることができます。
- Web サービスのパフォーマンス上の問題または例外をすばやく診断できます。 CPU やその他のリソースが限界まで使用されていることを検出したり、例外からスタック トレースを取得したり、ログ トレース全体を簡単に検索したりできます。 アプリのパフォーマンスの低下が許容できる限界を超えている場合には、Microsoft から電子メールを送信できます。 .NET と Java の両方の Web サービスを監視できます。
詳細については、「 Application Insights とは何か?」を参照してください。
次のステップ
Azure Storage の分析については、次のリソースを参照してください。
- Azure Portal でのストレージ アカウントの監視
- Storage Analytics
- Storage Analytics のメトリック
- Storage Analytics Metrics のテーブル スキーマ
- Storage Analytics のログ
- Storage Analytics のログの形式
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。