Azure ストレージ アカウントでのクライアント アプリケーション エラーのトラブルシューティング

この記事は、Azure Monitor のメトリック、クライアント側のログ、およびリソース ログを使用して、クライアント アプリケーション エラーを調査するのに役立ちます。

エラーの診断

アプリケーションのユーザーから、クライアント アプリケーションの報告したエラーについて通知されることがあります。 Azure Monitor では、ストレージ サービスからのさまざまな応答の種類 (ResponseType ディメンション) の数 ( NetworkError、 ClientTimeoutError、 AuthorizationError も記録されます。 Azure Monitor にはエラーの種類ごとの数しか記録されませんが、サーバー側のログ、クライアント側のログ、およびネットワーク ログを調べれば個々の要求に関する詳細を取得できます。 一般に、要求が失敗した理由は、Storage サービスから返される HTTP 状態コードに示されます。

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

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

クライアントが HTTP 403 (許可されていません) のメッセージを受け取る

クライアント アプリケーションが HTTP 403 (許可されていません) エラーをスローする場合、可能性の高い原因は、クライアントがストレージ要求を送信するときに期限切れの Shared Access Signature (SAS) を使用していることです (原因の他の可能性としては、クロック スキュー、無効なキー、空のヘッダーなどがあります)。

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

以下の表に、この問題が生じたときにストレージ クライアント ライブラリによって生成されるクライアント側のログのサンプルを示します。

このシナリオでは、クライアントが SAS トークンをサーバーに送信する前にトークンが期限切れになった理由を調査しなければなりません。

• 通常、クライアントがすぐに使用する SAS を作成する場合は、開始時刻を設定しないでください。 現在の時刻を使用して SAS を生成するホストと、Storage サービスのクロックに小さな差異が存在すると、有効になっていない SAS を Storage サービスが受け取る可能性があります。

• SAS で非常に短い有効期限を設定しないでください。 やはり、SAS を生成するホストと Storage サービス間のクロックに小さい差異があると、予想されていたよりも早く 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 コードにオブジェクトへのアクセス許可がない。

• ネットワーク障害。

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

クライアントがストレージ サービス内のデータの読み取り、更新、または削除を試みるシナリオでは、ストレージ リソースで、対象のオブジェクトをストレージ サービスから削除した以前の操作をログに記録するのは簡単です。 多くの場合、ログ データに別のユーザーまたはプロセスがオブジェクトを削除したことが示されています。 Azure Monitor ログ (サーバー側) には、クライアントがオブジェクトを削除した日時が表示されます。

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

ストレージ クライアント ライブラリのクライアント側ログを使用して、クライアントがストレージ サービスに特定の要求を送信するタイミングをより深く理解できます。

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

ログ エントリ:

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

共有アクセス署名 (SAS) 認証の問題

クライアント アプリケーションが、操作に必要なアクセス許可が含まれていない SAS キーを使用しようとすると、Storage サービスは "HTTP 404 (Not found)" というメッセージをクライアントに返します。 同時に、Azure Monitor メトリックでは、ResponseType ディメンションの AuthorizationError も表示されます。

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

クライアント側の JavaScript コードにオブジェクトへのアクセス許可がない

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

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

これらのエラーは、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 サービスのテーブルを調べると、要求どおりにサービスがエンティティを削除したことがわかります。

クライアントにおける例外の詳細には、Table Service によって要求に割り当てられた要求 ID (7e84f12d…) が含まれます。この情報を使用して、ログ エントリの操作がどのように認証されたかを説明するフィールドで検索することにより、Azure Monitor でストレージ リソース ログにある要求の詳細を見つけることができます。 メトリックを使用して、このようなエラーが発生した時刻を特定し、エラーがメトリックに記録された時刻に基づいてログ ファイルを検索することもできます。 このログ エントリには、状態メッセージ "HTTP (404) Client Other Error" を出して削除が失敗したことが示されます。 同じログ エントリには、 client-request-id 列 (813ea74f...) にクライアントによって生成された要求 ID も含まれます。

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

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

この問題が頻繁に発生する場合は、クライアントが Table サービスからの受信確認の受け取りに失敗している原因を調べてください。 問題が断続的に発生する場合は、クライアントで "HTTP (404) 未検出" エラーをトラップしてログに記録する一方でクライアントの実行を継続できるようにする必要があります。

クライアントが HTTP 409 (競合) のメッセージを受け取る

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

削除/再作成のパターンをよく使用する場合、クライアント アプリケーションは、新規コンテナーの作成時に必ず一意のコンテナー名を使用する必要があります。

メトリックの示す PercentSuccess が低い、または分析ログ エントリの中にトランザクション ステータスが ClientOtherErrors の操作がある

Success の値と等しい ResponseType ディメンションは、操作の HTTP 状態コードに基づいて、成功した操作の割合をキャプチャします。 状態コードが 2XX の操作は成功としてカウントされますが、状態コードが 3XX、4XX、5XX の範囲の操作は失敗としてカウントされ、成功メトリック値は小さくなります。 ストレージ リソース ログには、これらの操作が ClientOtherError のトランザクション状態で記録されます。

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

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

「REST API の一般的なエラー コード」に、Storage サービスが返す一般的な REST API エラー コードの一覧を記載しています。

関連項目

• Azure Blob Storage の監視
• Azure Files の監視
• Azure Queue Storage の監視
• Azure Table Storage の監視
• パフォーマンスに関する問題のトラブルシューティング
• 可用性に関する問題のトラブルシューティング
• Azure Storage の監視、診断、トラブルシューティング

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

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