Azure Storage のメトリックおよびログ、AzCopy、Message Analyzer を使用したエンド ツー エンド トラブルシューティング
診断とトラブルシューティングは、Microsoft Azure Storage を使用してクライアント アプリケーションを構築し、サポートするうえでの重要なスキルです。 Azure アプリケーションの分散型の性質により、エラーやパフォーマンスの問題に対する診断とトラブルシューティングは、従来の環境で実施するよりも複雑になる場合があります。
このチュートリアルでは、クライアント アプリケーションの最適化を目的に、パフォーマンスに影響する可能性のある特定のエラーを特定すると共に、Microsoft と Azure Storage が提供するツールを使用して、これらのエラーについてエンド ツー エンドのトラブルシューティングを実施する方法を説明します。
このチュートリアルでは、エンド ツー エンド トラブルシューティングのシナリオを実践的に学ぶことができます。 Azure Storage アプリケーションのトラブルシューティングに関する詳細な概念ガイドについては、「 Microsoft Azure Storage の監視、診断、およびトラブルシューティング」を参照してください。
Azure Storage アプリケーションのトラブルシューティングに使用するツール
Microsoft Azure Storage を使用してクライアント アプリケーションのトラブルシューティングを実施する場合、問題がいつ発生したのか、原因は何なのかを見極めるために複数のツールを組み合わせて使用することができます。 これには以下のツールが含まれます。
Azure Storage Analytics。 Azure Storage Analytics では、Azure Storage 向けのメトリックとログが利用できます。
- ストレージ メトリック は、ストレージ アカウントのトランザクション メトリックと容量メトリックを追跡するためのものです。 メトリックを使用すると、アプリケーションがどのように機能しているかを、さまざまな基準に従って判断できます。 Storage Analytics が追跡するメトリックの種類の詳細については、「 Storage Analytics Metrics のテーブル スキーマ 」を参照してください。
- ストレージ ログ は、Azure Storage サービスへの各要求をサーバー側のログに記録します。 このログは、実行された操作、操作のステータス、遅延情報などを含む各要求の詳細データを追跡します。 Storage Analytics がログに書き込む要求および応答データの詳細については、「 Storage Analytics のログの形式 」を参照してください。
Azure Portal Azure Portal では、ストレージ アカウントのメトリックとログを構成することができます。 アプリケーションの経時的な動作を表すチャートやグラフを表示できるほか、指定したメトリックに関してアプリケーションが予期しない動作をした場合に通知するよう、アラートを構成することもできます。
Azure Portal での監視の構成については、「Azure Portal でのストレージ アカウントの監視」をご覧ください。
AzCopy。 Azure Storage のサーバー ログは BLOB として格納されているので、AzCopy を使用してログ BLOB をローカル ディレクトリにコピーし、Microsoft Message Analyzer による分析に使用することができます。 AzCopy の詳細については、「AzCopy コマンド ライン ユーティリティを使用してデータを転送する」をご覧ください。
Microsoft Message Analyzer。 Message Analyzer はログ ファイルを使用してログ データを画像形式で表示するツールです。これにより、ログ データのフィルター処理や検索のほか、エラーやパフォーマンス問題の分析に使用できる有用なデータ セットへのグループ化が容易になります。 Message Analyzer の詳細については、Microsoft Message Analyzer の操作ガイドを参照してください。
サンプル シナリオについて
このチュートリアルでは、Azure Storage を呼び出すアプリケーションの成功率に関して、Azure Storage メトリックが低い割合を示すシナリオについて調べます。 低い成功率メトリック (PercentSuccess として Azure Portal とメトリック テーブル内に表示される) では、成功した操作を追跡しますが、299 を超える数字の HTTP 状態コードを返します。 サーバー側のストレージ ログ ファイルには、これらの操作が ClientOtherErrorsのトランザクション状態で記録されます。 低い成功率メトリックの詳細については、「 メトリックの示す PercentSuccess が低い、または分析ログ エントリの中にトランザクション ステータスが ClientOtherErrors の操作がある」を参照してください。
Azure Storage の操作では、その通常の機能の一部として 299 を超える数字の HTTP 状態コードを返す場合があります。 しかしこれらのエラーは、クライアント アプリケーションのパフォーマンスを最適化できる可能性があることを示している場合もあります。
このシナリオでは、100% 未満の値についてはすべて低い成功率であると判断します。 ただし、必要に応じて異なるメトリック レベルを選択することができます。 アプリケーションのテスト時には、主なパフォーマンス メトリックについて基準となる許容値を設定することをお勧めします。 たとえば、アプリケーションの成功率は 90% または 85% を維持する必要があることを、テストに基づいて決定することができます。 アプリケーションがその数値から外れていることをメトリック データが示している場合、その増加を引き起こしているのが何なのかを調査することができます。
サンプル シナリオでは、成功率メトリックの割合を 100% 未満に設定した後、ログを調べてそのメトリックと相関関係があるエラーを見つけ、それを使用して成功率が低くなる原因を解明します。 ここでは、特に 400 番台のエラーに着目します。 その後、404 (Not Found) エラーに的を絞って調査します。
400 番台のエラーの原因
以下の例では、Azure Blob Storage への要求に関するいくつかの 400 番台のエラーと、その考えられる原因を示します。 これらのエラーは、300 および 500 番台のエラーと同様に、いずれも低い成功率の一因となる可能性があります。
以下の一覧は不完全であるという点に注意してください。 通常の Azure Storage エラーおよび各ストレージ サービスに特有のエラーの詳細については、MSDN の「 状態コードとエラー コード 」を参照してください。
状態コード 404 (Not Found) の例
BLOB またはコンテナーが見つからないことが原因で、それらに対する読み取り操作が失敗した場合に発生します。
- この要求の前に別のクライアントによってコンテナーまたは BLOB が削除された場合に発生します。
- コンテナーまたは BLOB を作成する前に、それらが存在するかどうかを確認する API 呼び出しを使用する場合に発生します。 CreateIfNotExists API は最初に HEAD 呼び出しを実行し、コンテナーまたは BLOB が存在するかどうかを確認します。存在しない場合は 404 エラーが返され、その後、2 番目の PUT 呼び出しを実行してコンテナーまたは BLOB を書き込みます。
状態コード 409 (Conflict) の例
- Create API を使用して最初に存在を確認することなくコンテナーまたは BLOB を作成する際、同じ名前のコンテナーまたは BLOB が既に存在する場合に発生します。
- コンテナーが削除される際、その削除操作が完了する前に同じ名前の新しいコンテナーを作成しようとした場合に発生します。
- コンテナーまたは BLOB にリースを指定する際、既にリースが存在している場合に発生します。
状態コード 412 (Precondition Failed) の例
- 条件ヘッダーにより指定された条件が満たされていない場合に発生します。
- 指定されたリース ID がコンテナーまたは BLOB のリース ID と一致しない場合に発生します。
分析用にログ ファイルを生成する
このチュートリアルでは、Message Analyzer を使用して 3 種類のログ ファイルを操作しますが、実際にはどれか 1 つを選択して操作できます。
- サーバー ログは、Azure Storage ログを有効にすると作成されます。 サーバー ログには、Azure Storage サービスの 1 つ、つまり BLOB、キュー、テーブル、ファイルに対して呼び出された各操作についてのデータが含まれます。 サーバー ログは、どの操作が呼び出され、どの状態コードが返されたかに加え、要求と応答に関するその他の詳細を示します。
- .NET クライアント ログは、.NET アプリケーション内部からクライアント側のログを有効にした場合に作成されます。 このクライアント ログには、クライアントが要求を準備し、応答を受信して処理する方法についての詳細情報が含まれます。
- HTTP ネットワーク トレース ログは、HTTP/HTTPS の要求および応答データを収集しますが、これには Azure Storage に対する操作についてのデータも含まれます。 このチュートリアルでは、Message Analyzer を使用してネットワーク トレースを生成します。
サーバー側のログとメトリックを構成する
まず、サービス側から分析用データを取得できるよう、Azure Storage のログとメトリックを構成する必要があります。 Azure Portal や PowerShell を使用する方法、プログラミングによって構成する方法など、さまざまな方法でログとメトリックを構成することができます。 ログとメトリックの構成の詳細については、メトリックの有効化に関するページとログの有効化に関するページをご覧ください。
.NET のクライアント側のログを構成する
.NET アプリケーションのクライアント側のログを構成するには、アプリケーションの構成ファイル (web.config または app.config) 内で .NET 診断を有効にします。 詳しくは、MSDN の「.NET ストレージ クライアント ライブラリと、クライアント側のログ記録」および「Microsoft Azure Storage SDK for Java によるクライアント側のログ」をご覧ください。
クライアント側のログには、クライアントが要求を準備し、応答を受信して処理する方法についての詳細情報が含まれます。
ストレージ クライアント ライブラリは、クライアント側のログ データをアプリケーションの構成ファイル (web.config または app.config) 内で指定した場所に格納します。
ネットワーク トレースを収集する
Message Analyzer を使用して、クライアント アプリケーションの動作時の HTTP/HTTPS ネットワーク トレースを収集することができます。 Message Analyzer は、バックエンドで Fiddler を使用します。 ネットワーク トレースを収集する前に、暗号化されていない HTTPS トラフィックを記録するよう、Fiddler を構成することをお勧めします。
- Fiddlerをインストールします。
- Fiddler を起動します。
- [Tools]、[Fiddler Options] の順に選択します。
- Options ダイアログで、以下に示すように [Capture HTTPS CONNECTs] と [Decrypt HTTPS Traffic] が両方とも選択されている状態にします。
このチュートリアルでは、まず Message Analyzer でネットワーク トレースを収集して保存し、次に分析セッションを作成してトレースとログを分析します。 Message Analyzer でネットワーク トレースを収集するには:
Message Analyzer で、 [File]、[Quick Trace]、[Unencrypted HTTPS] の順に選択します。
すぐにトレースが開始します。 [Stop] を選択してトレースを停止します。これで、ストレージ トラフィックのみをトレースするように構成することができます。
[Edit] を選択してトレース セッションを編集します。
Microsoft-Pef-WebProxy ETW プロバイダーの右側にある [Configure] リンクを選択します。
[Advanced Settings] ダイアログで、 [Provider] タブをクリックします。
Hostname Filter フィールドに、スペースで区切られたストレージ エンドポイントを指定します。 たとえば、次のようにエンドポイントを指定することができます。
storagesampleをストレージ アカウントの名前に変更してください。storagesample.blob.core.windows.net storagesample.queue.core.windows.net storagesample.table.core.windows.netダイアログを終了し、 [Restart] をクリックして、ホスト名フィルターを配置した状態でトレースの収集を開始します。これで、Azure Storage ネットワーク トラフィックのみがトレースに含まれるようになります。
注意
ネットワーク トレースの収集が完了したら、Fiddler で変更した HTTPS トラフィックを復号化する設定を元に戻すことを強くお勧めします。 [Fiddler Options] ダイアログで、 [Capture HTTPS CONNECTs] および [Decrypt HTTPS Traffic] チェックボックスをオフにします。
詳細については、Technet の ネットワーク トレース機能の使用 に関するページを参照してください。
Azure Portal でメトリック データを確認する
アプリケーションが動作を開始してから一定の時間が経過すると、Azure Portal に表示されるメトリック チャートを確認し、サービスがどのように動作しているかを観察することができます。
まず、Azure Portal のストレージ アカウントに移動します。 既定では、成功のパーセンテージ メトリック付きの監視グラフが [アカウント] ブレードに表示されます。 別のメトリックを表示するようにグラフを変更している場合は、成功のパーセンテージ メトリックを追加します。
これで、監視グラフに 成功のパーセンテージが、追加した他のメトリックと共に表示されます。 次に調査するシナリオでは Message Analyzer でログを分析しますが、成功率が 100% をいくらか下回っています。
メトリック グラフへの追加とカスタマイズの詳細については、「メトリック グラフのカスタマイズ」を参照してください。
注意
ストレージ メトリックを有効にした後、Azure Portal にメトリック データが表示されるまでには少し時間がかかる場合があります。 これは、1 つ前の時間単位メトリックが、現在の単位時間が経過するまでは Azure Portal に表示されないためです。 また、分単位メトリックについては現在のところ Azure Portal には表示されません。 つまり、メトリックを有効にしたタイミングによっては、メトリック データが表示されるまでに最大で 2 時間を要する可能性があります。
AzCopy を使用してサーバー ログをローカル ディレクトリにコピーする
Azure Storage は、サーバー ログ データを BLOB に書き込みますが、メトリックについてはテーブルに書き込みます。 ログ BLOB は、ストレージ アカウントの $logs コンテナー内にあります。 ログ BLOB は、年、月、日、時間により階層的に名前が付けられるので、調査する時間範囲が簡単に見つかります。 たとえば、storagesample アカウントでの、2015 年 1 月 2 日の午前 8 時から 9 時に記録されたログ BLOB のコンテナーは、https://storagesample.blob.core.windows.net/$logs/blob/2015/01/08/0800 です。 このコンテナー内の個々の BLOB は、 000000.logから始まる連番で名前が付けられます。
AzCopy コマンドライン ツールを使用して、これらのサーバー側のログ ファイルをローカル コンピューター上の好きな場所にダウンロードすることができます。 たとえば、次のコマンドを使用して、2015 年 1 月 2 日に記録された BLOB 操作のログ ファイルを、C:\Temp\Logs\Server フォルダーにダウンロードすることができます。<storageaccountname> はストレージ アカウント名に置き換えます。
azcopy copy 'http://<storageaccountname>.blob.core.windows.net/$logs/blob/2015/01/02' 'C:\Temp\Logs\Server' --recursive
AzCopy は、 Azure ダウンロード のページからダウンロードできます。 AzCopy の使用方法の詳細については、「 AzCopy コマンド ライン ユーティリティを使用してデータを転送する」をご覧ください。
サーバー側のログのダウンロードの詳細については、「 ストレージ ログのログ データのダウンロード」をご覧ください。
Microsoft Message Analyzer を使用してログ データを分析する
Microsoft Message Analyzer は、トラブルシューティングや診断のシナリオにおいて、プロトコル メッセージング トラフィック、イベント、およびその他のシステムやアプリケーションに対してキャプチャ、表示、分析を実施するためのツールです。 また、Message Analyzer では、ログや保存したトレース ファイルからのデータの読み込み、集計、分析ができます。 Message Analyzer の詳細については、 Microsoft Message Analyzer の操作ガイドに関するページを参照してください。
Message Analyzer には、サーバー、クライアント、およびネットワーク ログの分析に役立つ、Azure Storage 向けのアセットが含まれています。 このセクションでは、それらのツールを使用して、ストレージ ログにおける低い成功率の問題に対処する方法を説明します。
Message Analyzer と Azure Storage アセットをダウンロードしてインストールする
- Message Analyzer をダウンロードします。
- Message Analyzer を起動します。
- [ツール] メニューの [資産マネージャー] を選択します。 [資産マネージャー] ダイアログで、 [ダウンロード] を選択し、Azure Storage をフィルター処理します。 以下の画像のように、Azure Storage アセットが表示されます。
-
[Sync All Displayed Items] をクリックして、Azure Storage アセットをインストールします。 以下に利用できるアセットを挙げます。
- Azure Storage の色ルール: Azure Storage の色ルールにより、色、テキスト、およびフォント スタイルを使用する特別なフィルターを定義し、トレース内の特定の情報を含むメッセージを強調表示することができます。
- Azure Storage チャート: Azure Storage チャートは、サーバー ログ データをグラフ化する定義済みのチャートです。 現時点で Azure Storage チャートを使用する場合、Analysis Grid に読み込むことができるのはサーバー ログのみである点に注意してください。
- Azure Storage パーサー: Azure Storage パーサーは、Azure Storage クライアント、サーバー、および HTTP のログを解析して Analysis Grid に表示します。
- Azure Storage フィルター: Azure Storage フィルターは、Analysis Grid でデータのクエリに使用できる、定義済みの条件です。
- Azure Storage ビュー レイアウト: Azure Storage ビュー レイアウトは、列の定義済みレイアウトであり、Analysis Grid 内のグループです。
- アセットのインストール後に、Message Analyzer を再起動します。
注意
このチュートリアルのために、表示された Azure Storage アセットはすべてインストールしてください。
ログ ファイルを Message Analyzer にインポートする
すべての保存済みログ ファイル (サーバー側、クライアント側、ネットワーク) を、分析のために Microsoft Message Analyzer 内の単一のセッションにインポートできます。
- Microsoft Message Analyzer の [File] メニューで、 [New Session] 、 [Blank Session] の順にクリックします。 [New Session] ダイアログで、分析セッションの名前を入力します。 [Session Details] パネルで、 [Files] をクリックします。
- Message Analyzer によって生成されるネットワーク トレース データを読み込むには、 [Add Files] をクリックし、Web トレース セッションから .matp ファイルを保存した場所に移動して .matp ファイルを選択し、 [Open] をクリックします。
- サーバー側のログ データを読み込むには、 [Add Files] をクリックし、サーバー側のログをダウンロードした場所に移動します。そのうえで、分析対象の時間範囲のログ ファイルを選択し、 [Open] をクリックします。 次に、 [Session Details] パネルで、各サーバー側ログ ファイルの [Text Log Configuration] ボックスを [AzureStorageLog] に設定し、Microsoft Message Analyzer がログ ファイルを正しく解析できるようにします。
- クライアント側のログ データを読み込むには、 [Add Files] をクリックし、クライアント側のログを保存した場所に移動します。そのうえで、分析対象のログ ファイルを選択し、 [Open] をクリックします。 次に、 [Session Details] パネルで、各クライアント側ログ ファイルの [Text Log Configuration] ボックスを [AzureStorageClientDotNetV4] に設定し、Microsoft Message Analyzer がログ ファイルを正しく解析できるようにします。
- [New Session] ダイアログで [Start] をクリックし、ログ データの読み込みと解析を実施します。 ログ データは Message Analyzer Analysis Grid に表示されます。
以下の画像では、サーバー、クライアント、およびネットワーク トレースのログ ファイルで構成したセッションの例が表示されています。
Message Analyzer はログ ファイルをメモリに読み込むという点に注意してください。 大きなサイズのログ データ セットを持っている場合は、Message Analyzer のパフォーマンスを最大限に引き出すため、そのファイルにフィルターを適用することをお勧めします。
最初に、確認したいタイム フレームを決めますが、このタイム フレームはできる限り短い期間にします。 多くの場合、確認するタイム フレームは数分から、最大でも数時間に制限する必要があります。 必要条件を満たすログ セットの中から、最小サイズのものをインポートします。
まだサイズの大きいログ データが残っている場合は、セッション フィルターを指定して、読み込む前にログ データをフィルター処理する必要があります。 [Session Filter] ボックスで、 [Library] をクリックして定義済みのフィルターを選択します。たとえば、Azure Storage フィルターから [Global Time Filter I] を選択して、時間間隔によるフィルターを適用します。 その後、フィルター条件を編集し、確認したい時間間隔について開始および終了時のタイムスタンプを指定することができます。 特定の状態コードによってフィルターを適用することもできます。たとえば、状態コードが 404 のログ エントリのみを読み込むように選択できます。
Microsoft Message Analyzer に対するログ データのインポートの詳細については、TechNet の メッセージ データの取得 に関するページを参照してください。
クライアント要求 ID を使用してログ ファイル データを関連付ける
Azure ストレージ クライアント ライブラリは、すべての要求に対して自動的に一意のクライアント要求 ID を生成します。 この値はクライアント ログ、サーバー ログ、ネットワーク トレースに書き込まれるため、Message Analyzer 内の 3 種類のログすべてにわたって、この値をデータの関連付けに使用することができます。 クライアント要求 ID の詳細については、「 クライアント要求 ID 」を参照してください。
以下のセクションでは、定義済みのカスタム レイアウト ビューを使用して、クライアント要求 ID に基づきデータの関連付けとグループ化を行う方法について説明します。
ビュー レイアウトを選択して Analysis Grid に表示する
Message Analyzer 向けの Storage アセットには Azure Storage View Layouts という定義済みのビューが含まれていますが、これを使用すると、さまざまなシナリオに役立つグループや列によってデータを表示することができます。 カスタム ビュー レイアウトを作成し、それを保存して再利用することもできます。
以下の画像では、ツール バー リボンから [View Layout] を選択するとことでアクセスできる、 [View Layout] メニューが表示されています。 Azure Storage のビュー レイアウトは、このメニューの [Azure Storage] ノードの下にグループ化されています。 検索ボックスで Azure Storage を検索すると、Azure Storage ビュー レイアウトのみでフィルター処理できます。 ビュー レイアウトの横にある星を選択してお気に入りに設定し、メニューの最上部に表示することもできます。
![[View Layout] メニュー](media/storage-e2e-troubleshooting/view-layout-menu.png)
まずは、 [Grouped by ClientRequestID and Module] を選択します。 このビュー レイアウトは、3 種類すべてのログからのログ データを、最初はクライアント要求 ID、次にソース ログ ファイル (または Message Analyzer 内の Module ) によってグループ化しています。 このビューを使用すると、特定のクライアント要求 ID へとドリル ダウンし、そのクライアント要求 ID について、3 種類すべてのログ ファイルのデータを見ることができます。
以下の画像では、このレイアウト ビューがサンプル ログ データに適用され、列のサブセットが表示されています。 特定のクライアント要求 ID について、Analysis Grid がクライアント ログ、サーバー ログ、ネットワーク トレースのデータを表示していることがわかります。
注意
ログ ファイルの種類によって含まれる列は異なるため、Analysis Grid に複数のログ ファイルのデータが表示された場合、いくつかの列は任意の行に何のデータも含まれていない場合があります。 たとえば前の図では、 [Timestamp] 、 [TimeElapsed] 、 [Source] 、 [Destination] の各列について、クライアント ログの行には何のデータも表示されていませんが、この原因は、クライアント ログにはこれらの列が存在せず、ネットワーク トレースには存在するためです。 同様に、 [Timestamp] 列にはサーバー ログのタイムスタンプ データが表示されていますが、サーバー ログには含まれていない [TimeElapsed] 、 [Source] 、 [Destination] の各列には何も表示されていません。
Azure Storage ビュー レイアウトを使用するだけでなく、独自のビュー レイアウトを定義して保存することもできます。 データのグループ化に必要なその他のフィールドを選択し、そのグループをカスタム レイアウトの一部として保存することができます。
Analysis Grid にカラー ルールを適用する
Storage アセットにはカラー ルールも含まれており、これによって Analysis Grid で異なる種類のエラーを視覚的に識別できます。 定義済みのカラー ルールは HTTP エラーに適用されるため、サーバー ログとネットワーク トレースに対してだけ影響があります。
カラー ルールを適用するには、ツール バー リボンから [Color Rules] を選択します。 Azure Storage カラー ルールがメニューに表示されます。 このチュートリアルでは、以下の画像のように [Client Errors (StatusCode between 400 and 499)] を選択します。
Azure Storage カラー ルールを使用するだけでなく、独自のカラー ルールを定義して保存することもできます。
ログ データをグループ化してフィルターを適用し、400 番台のエラーを見つける
次に、ログ データをグループ化してフィルターを適用し、400 番台のすべてのエラーを見つけます。
Analysis Grid で [StatusCode] 列を見つけて列見出しを右クリックし、 [Group] を選択します。
次に、 [ClientRequestId] 列によってグループ化します。 これで、Analysis Grid 内のデータが状態コードとクライアント要求 ID によって整理されたことがわかります。
View Filter ツール ウィンドウがまだ表示されていない場合、これを表示します。 ツール バー リボンで、 [Tool Windows] 、 [View Filter] の順に選択します。
ログ データにフィルターを適用して 400 番台のエラーのみを表示するには、次のフィルター条件を [View Filter] ウィンドウに追加し、 [Apply] をクリックします。
(AzureStorageLog.StatusCode >= 400 && AzureStorageLog.StatusCode <=499) || (HTTP.StatusCode >= 400 && HTTP.StatusCode <= 499)
以下の画像では、このグループ化およびフィルター適用の結果が表示されています。 たとえば、状態コード 409 のグループ内にある ClientRequestID フィールドを展開し、その状態コードを引き起こした操作を表示します。
クライアント ログに StatusCode 列が含まれていないため、このフィルターを適用した後は、クライアント ログの行が除外されていることがわかります。 まず、サーバーおよびネットワーク トレース ログを確認して 404 エラーを見つけてから、クライアント ログに戻ってそのエラーを引き起こしたクライアント操作を調べます。
注意
ステータス コードが null であるログ エントリを含むフィルターに式を追加すると、 [StatusCode] 列によるフィルターを適用しつつ、クライアント ログを含む 3 つのログすべてのデータを表示することができます。 このフィルター式を作成するには、以下を使用します:
*StatusCode >= 400 or !*StatusCode
このフィルターは、クライアント ログのすべての行を返し、サーバー ログと HTTP ログからは状態コードが 400 を超える行のみを返します。 クライアント要求 ID とモジュールによりグループ化したビュー レイアウトにこれを適用した場合、ログ エントリを検索するか下へスクロールすれば、3 つのログがすべて表示されている場所を見つけることができます。
ログ データにフィルターを適用して 404 エラーを見つける
Storage アセットには定義済みのフィルターが含まれており、これを使用してログ データを絞り込み、探しているエラーや傾向を見つけることができます。 次は、2 つの定義済みフィルターを適用します。1 つは 404 エラーについてサーバーおよびネットワーク トレース ログに適用するフィルターで、もう 1 つは指定した時間範囲についてそれらのデータに適用するフィルターです。
View Filter ツール ウィンドウがまだ表示されていない場合、これを表示します。 ツール バー リボンで、 [Tool Windows] 、 [View Filter] の順に選択します。
View Filter ウィンドウで、 [Library] を選択し、
Azure Storageを検索して Azure Storage フィルターを見つけます。 [404 (Not Found) messages in all logs] のフィルターを選択します。もう一度 [Library] メニューを表示し、 [Global Time Filter] を見つけて選択します。
フィルター内に表示されるタイムスタンプを、確認したい範囲に編集します。 これにより、分析するデータの範囲を絞り込むことができます。
フィルターは以下の例のように表示されます。 [Apply] をクリックして Analysis Grid にフィルターを適用します。
((AzureStorageLog.StatusCode == 404 || HTTP.StatusCode == 404)) And (#Timestamp >= 2014-10-20T16:36:38 and #Timestamp <= 2014-10-20T16:36:39)
ログ データを分析する
データをグループ化してフィルターを適用したので、404 エラーを生成した個々の要求について詳細を調べることができます。 現在のビュー レイアウトでは、データはまずクライアント要求 ID、次にログ ソースによってグループ化されています。 StatusCode フィールドに 404 が含まれる要求によってフィルター処理しているため、サーバーおよびネットワーク トレースのデータのみが表示され、クライアント ログのデータは表示されません。
以下の画像の要求を見ると、BLOB が存在しないために、Get Blob 操作によって 404 が発生しています。 関連データを表示するために、標準ビューから削除されている列があることに注意してください。
次に、このクライアント要求 ID とクライアント ログ データを関連付けて、エラーが発生した際にクライアントがどのように対処していたかを確認します。 このセッションのために新しい Analysis Grid ビューを表示してクライアント ログ データを確認することができますが、このビューは 2 番目のタブに開きます。
まず、 ClientRequestId フィールドの値をクリップボードにコピーします。 コピーするには、ClientRequestId フィールドにあるどちらかの行を選択し、データ値を右クリックして [Copy 'ClientRequestId'] を選択します。
ツール バー リボンで、 [New Viewer] 、 [Analysis Grid] の順に選択して新しいタブを開きます。新しいタブは、ログ ファイル内のすべてのデータを、グループ化やフィルター、カラー ルールを適用せずに表示します。
ツール バー リボンで、 [View Layout] を選択し、 [Azure Storage] セクションの [All .NET Client Columns] を選択します。 このビュー レイアウトでは、サーバーおよびネットワーク トレース ログだけでなく、クライアント ログのデータも表示されます。 このデータは、既定では [MessageNumber] 列によって並べ替えが行われています。
次に、クライアント ログでクライアント要求 ID を検索します。 ツール バー リボンで [Find Messages] を選択し、Find フィールドでクライアント要求 ID についてのカスタム フィルターを指定します。 フィルターには、この構文を使用して独自のクライアント要求 ID を指定します。
*ClientRequestId == "398bac41-7725-484b-8a69-2a9e48fc669a"
Message Analyzer は、検索条件がクライアント要求 ID に一致する最初のログ エントリを見つけて選択します。 クライアント ログには、各クライアント要求 ID に対して複数のエントリがあるため、それらをまとめて確認しやすいように、 ClientRequestId フィールドでグループ化する必要があります。 以下の画像では、指定したクライアント要求 ID のクライアント ログにあるすべてのメッセージが表示されています。
これら 2 つのタブのビュー レイアウトに表示されているデータを使用することで、要求データを分析して何がエラーを引き起こしたのかを判断することができます。 また、これに先行する要求を確認して、以前のイベントが 404 エラーを引き起こした可能性があるかどうかを調べることもできます。 たとえば、このクライアント要求 ID に先行するクライアント ログを確認して、BLOB が削除されていないか、あるいはクライアント アプリケーションがコンテナーまたは BLOB に対して CreateIfNotExists API を呼び出したことがエラーの発生原因ではないかを判断できます。 クライアント ログでは、Description フィールドに BLOB のアドレスが表示されます。サーバーおよびネットワーク トレース ログの場合、この情報は Summary フィールドに表示されます。
404 エラーを引き起こした BLOB のアドレスが判明したら、さらに調査を進めることができます。 同じ BLOB に対する操作に関連付けられた他のメッセージのログ エントリを検索した場合、クライアントが事前にそのエンティティを削除していたかどうかが確認できます。
他の種類のストレージ エラーを分析する
Message Analyzer を使用したログ データの分析に慣れてきたところで、ビュー レイアウト、カラー ルール、検索、フィルター処理を使用して他の種類のログ データを分析することもできます。 以下の表は、発生する可能性のある問題と、それらの特定に使用できるフィルター条件の一覧です。 フィルターの作成方法および Message Analyzer フィルタリング言語の詳細については、 メッセージ データのフィルター処理に関するページを参照してください。
| 調査目的… | 使用するフィルター式… | 式を適用するログ (クライアント、サーバー、ネットワーク、すべて) |
|---|---|---|
| キューのメッセージ配信での予期しない遅延 | AzureStorageClientDotNetV4.Description に "失敗した操作の再試行" が含まれている。 | Client |
| HTTP の PercentThrottlingError の増加 | HTTP。Response.StatusCode == 500 ||HTTP。Response.StatusCode == 503 | ネットワーク |
| PercentTimeoutError の増加 | HTTP.Response.StatusCode == 500 | ネットワーク |
| PercentTimeoutError の増加 (すべて) | *StatusCode == 500 | All |
| PercentNetworkError の増加 | AzureStorageClientDotNetV4.EventLogEntry.Level < 2 | Client |
| HTTP 403 (Forbidden) メッセージ | HTTP.Response.StatusCode == 403 | ネットワーク |
| HTTP 404 (Not found) メッセージ | HTTP.Response.StatusCode == 404 | ネットワーク |
| 404 (すべて) | *StatusCode == 404 | All |
| Shared Access Signature (SAS) 認証の問題 | AzureStorageLog.RequestStatus == "SASAuthorizationError" | ネットワーク |
| HTTP 409 (Conflict) メッセージ | HTTP.Response.StatusCode == 409 | ネットワーク |
| 409 (すべて) | *StatusCode == 409 | すべて |
| PercentSuccess が低いか、分析ログ エントリにトランザクションの状態が ClientOtherErrors の操作がある | AzureStorageLog.RequestStatus == "ClientOtherError" | サーバー |
| Nagle 警告 | ((AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS) > (AzureStorageLog.ServerLatencyMS * 1.5))および (AzureStorageLog.RequestPacketSize <1460) と (AzureStorageLog.EndToEndLatencyMS - AzureStorageLog.ServerLatencyMS >= 200) | サーバー |
| サーバーおよびネットワーク ログの時間範囲 | >#Timestamp = 2014-10-20T16:36:38 および #Timestamp <= 2014-10-20T16:36:39 | サーバー、ネットワーク |
| サーバー ログの時間範囲 | AzureStorageLog.Timestamp >= 2014-10-20T16:36:38 および AzureStorageLog.Timestamp <= 2014-10-20T16:36:39 | サーバー |
次のステップ
Azure Storage におけるエンド ツー エンド シナリオのトラブルシューティングの詳細については、次のリソースを参照してください。