セールス: 1-800-867-1380

Azure アプリケーションの開発に関するトラブルシューティングのベスト プラクティス

更新日: 2014年11月

執筆者: Microsoft 主任エスカレーション エンジニア、William Bellamy

寄稿者:

  • Microsoft シニア プログラム マネージャー (製品品質担当)、Bryan Lamos

  • Microsoft シニア エスカレーション エンジニア (Azure 開発者サポート担当)、Kevin Williamson

  • Microsoft シニア プログラム マネージャー (Azure 製品サービス担当)、Pranay Doshi

  • Microsoft シニア エスカレーション エンジニア (Azure 開発者サポート担当)、Tom Christian

発行: 2012 年 1 月

Microsoft の最も重要な優先事項は、Azure のお客様がアプリケーションの実行を維持できるようにすることです。Azure サービス レベル契約では、複数のロール インスタンスをデプロイする際の外部接続の可用性が 99.95% であることが定義されています。ただし、外部接続によって Microsoft ���データ センター外部からアプリケーションにアクセスできますが、これは "サイトが稼働している" ことと同じではありません。ほとんどの Azure サービスには、SQL Azure、キャッシュ、コンテンツ配信ネットワーク、(Azure Connect を通じた) 内部リソースなど、複数の依存関係があります。これらの依存関係のいずれかに障害が発生すると、Azure サービスは想定どおりに機能しません。

この記事では、Microsoft の Azure プラットフォーム向けに耐性に優れたアプリケーションを設計および開発できるように、トラブルシューティングの各種課題と推奨される設計手法について説明します。問題が発生した場合 (そうでなくても)、時間が重要になります。適切な計画を立てると、サポートのために Microsoft に問い合わせなくても、問題を見つけて修正できるようになります。さらに、この記事で推奨している手法を使用すると、Microsoft のサポートを必要とする問題の解決が早まります。

この記事は、ソフトウェア技術者 (Azure ソリューションを設計、構築、デプロイするソフトウェア設計者、アーキテクト、IT プロフェッショナル、システム インテグレーター、開発者、およびテスター) 向けのリソースとなることを目的としています。

Azure 開発およびランタイム環境の用語やさまざまなコンポーネントを含めて、Azure アプリケーションのアプリケーション開発サイクルについて基本的な理解があることを前提としています。

また、Azure SDK の最新バージョンの使用、運用環境に移行する前のコードの変更のテストなど、Azure の基本的なガイドラインに従うことを前提としています。

このドキュメントは以下の 2 つのセクションで構成されています。

  • Azure 診断リソースの概要:

    • Azure リソース

    • サード パーティのリソース

  • サポート可能な設計、開発、およびデプロイのベスト プラクティス:

    • アプリケーションをデプロイする前。

    • Fail Fast 設計と監視。

    • 問題が発生した場合の対応。

運用環境に移行した時点でアプリケーションがダウンすると予期している開発者はいません。開発中は最善を尽くしてコードをテストし、次のプロジェクトに移動するときにはエラーなく実行されるための十分な堅牢性を備えるようにします。それでもコードのエラーは発生します。分散環境では、アプリケーション コンポーネントの分離に特有の複雑さにより、軽度なエラーが致命的になる可能性があります。このため、最初からログ記録とトレース戦略をアプリケーションに組み込む必要があります。コンポーネント レベルでログ記録の種類と量を再構築/再デプロイすることなく、動的に調整するための準備がこの戦略に含まれることが理想的です。大量のログがあっても、迅速な解決は保証されません。データが多いと暗号解読に時間がかかり、アプリケーションのパフォーマンスを低下させる可能性があるため、データの量が多いことが良いとは限りません。調整可能なログ記録により、ログ データのサイズとストレージ コストの両方を管理できます。

Azure Platform で実行されるアプリケーションなどの分散アプリケーションには、ユーザーがアプリケーションを操作するときに相互にやり取りする複数のコンポーネントがあります。外部サービスへの呼び出しに特に注意して、コードのフローを継続的かつ豊富に記録することで、だれでもアプリケーションの実行フローを実質的に追うことができます。これは、今後 1 ~ 2 年に運用環境で問題が発生したときに役立つ可能性があります。ログ記録のレベルは ServiceConfiguration.cscfg ファイルから調整可能にし、再デプロイすることなく変更できるようにすることが理想的です。

最大量のエラー情報を得るためには、開発中にデバッグ ビルドを使用すると便利です。通常、開発者はデバッグ ステートメントを追加し、別のエラー ログを記録することもあります。問題は、運用ビルドではデバッグ ステートメントが削除され、問題が発生した場合に困るということです。ほとんどのお客様は、運用環境の問題を解決するためにデバッグ ビルドの再デプロイを望んでいません。Mike Kelly が、開発者が構成する必要がある 4 種類の診断の出力について説明しています。

  • デバッグ出力 - Assert が含まれているのはデバッグ ビルドのみです

  • トレース - 実行中に制御のフローを追跡します。

  • イベントのログ記録 - 重要なイベント

  • エラーのログ記録 - 例外的または危険な状況

デバッグ メッセージの多くは、おそらくさまざまなトレース レベルを活用するためにトレース ステートメントにする必要があります。Azure 診断では、診断を構成し、転送を無効にして、永続ストレージに情報を書き込むタイミングを管理することができます。

以下のセクションでは、Azure でアプリケーションを構築する開発者が利用できるトラブルシューティング リソースのいくつかについて説明します。

Azure の前に、Windows Server アプリケーションの現在のトラブルシューティング パラダイムについて説明します。通常、開発者は、運用環境の問題が発生するとログを調べます。イベント ログと IIS ログは既定で有効になり、(ディスク障害がない限り) 再起動しても有効です。

この同じプロセスは、リモート デスクトップが有効になっている場合、Azure アプリケーションで機能します。開発者は各インスタンスに接続して診断データを収集できます。この収集は、ログをストレージにコピーするか RDP を構成し、それらをローカル コンピューターにコピーできるようにすることによって実行できます。このプロセスは時間がかかり、インスタンスのイメージが最適用されると失敗します。その場合、Web またはワーカー ロールのクリーン バージョンが起動されます。このクリーン バージョンには、すべての以前のログはありません。イメージの再適用が発生するのは、ホストまたはゲスト仮想マシンのオペレーティング システムのアップグレード時です。再イメージ化は Azure アーキテクチャの正常な処理です。

元の Azure SDK 1.0 には、診断情報を収集し、総称して Azure 診断 (WAD) と呼ばれる Azure Storage に保存する機能が用意されていました。このソフトウェアは Event Tracing for Windows (ETW) フレームワーク上に構築されていて、Azure スケールアウト アーキテクチャによって導入された次の 2 つの設計要件を満たします。

  1. インスタンスのイメージの再適用中に失われる診断データを保存する。

  2. 複数のインスタンスから診断の一元的なレポジトリを提供する。

Microsoft.WindowsAzure.Diagnostic 名前空間は System.Diagnostics 名前空間を拡張するので、Azure アプリケーション内で ETW フレームワークを使用できます。

Windows Azure - 診断フロー図

WAD は、Azure 診断をロール (ServiceConfiguration.cscfg および ServiceDefinition.csdef) に含めた後で、その特定のロールのすべてのインスタンスから診断データを収集します。診断データは、デバッグ、トラブルシューティング、パフォーマンスの測定、リソース利用状況の監視、トラフィック分析、キャパシティ プランニング、監査などに使用できます。永続化のための Azure Storage アカウントへの転送は、スケジュールすることも、オンデマンドにすることもできます。

Azure 診断は、次の 4 つの重要な方法でサーバー パラダイムを変更します。

  1. 診断はアプリケーション作成時に有効にする必要があります。

  2. 診断結果を視覚化するために、特定のツール/手順が必要です。

  3. クラッシュが発生すると、永続ストレージ (各インスタンス上ではなく Azure Storage) に書き込まれない限り、診断データは失われます。

  4. 診断ストレージでは、Azure Storage に格納されると毎月コストが発生します。

Azure プラットフォームの主要な利点の 1 つとしてコスト削減があるため、コストは特に重要です。現在、WAD の使用コストを削減する唯一の方法は、データを仮想マシンに残すことです。これは小規模なデプロイでは有効な場合がありますが、多くのインスタンスがある状況では現実的ではありません。コストの影響を最小化するには、次のようにいくつかの方法があります。

  1. ストレージ アカウントがアプリケーションと同じデータ センターにあるようにします。なんらかの理由で同じデータ センターにない場合は、スケジュールされた転送の間隔を適切に選択します。転送間隔が短いとデータの関連性が高まりますが、その利点は帯域幅や処理オーバーヘッドの増加に見合わない場合があります。

  2. Azure Storage から定期的に診断データをコピーして消去します。診断データは Azure Storage を通過しますが、必ずしもそこに存在するとは限りません。そのためには、Azure 向け System Center Monitoring Pack、Cerebrata の Azure Diagnostics Manager、Azure PowerShell コマンドレットなど、数多くのツールがあります。

  3. アプリケーションのトラブルシューティングと監視に必要な診断データのみを選択します。あまりに多くのデータをキャプチャすると、コストが大幅に高くなるだけでなく、トラブルシューティングが困難になります。

  4. アプリケーションでオンデマンド スイッチを実装して診断データの収集と程度を管理します。

  5. ログ記録レベル (詳細、情報、警告、エラー) を利用してすべての情報を使用可能にし、デプロイ後の WAD 構成を利用して選択的にデータを収集します。

Azure Storage は、サポート可能なアプリケーションの基盤となります。すべてのアプリケーションでこの機能を構成し、アクティブにすることが理想的です。

Azure Storage Analytics では、ログが記録され、ストレージ アカウントのメトリック データを得ることができます。このデータを使用して、ストレージ要求のトレース、使用傾向の分析、およびストレージ アカウントの問題の診断を行うことができます。

サポート可能な SQL Azure コードを記述する鍵は、戻りコードを調べ、障害を処理するための確実な再試行コードがあることを確認することです。

この Monitoring Pack を使用すると、Microsoft System Center Operations Manager を使用して Azure アプリケーションの可用性とパフォーマンスを監視することができます。

  • Azure アプリケーションを検出します。

  • 各ロール インスタンスの状態を提供します。

  • パフォーマンス情報を収集して監視します。

  • Windows イベントを収集し、監視します。

  • 各ロール インスタンスから .NET Framework トレース メッセージを収集し、監視します。

  • Azure ストレージ アカウントからパフォーマンス、イベント、および .NET Framework トレース データを整備します。

  • ロール インスタンス数を変更します。

Microsoft System Center Operations Manager 2007 の使用は、Azure アプリケーションの状態を監視するための最適な方法です。

現在、Azure はお客様がホステッド サービスを監視し、管理するための完全なソリューションは提供していません。ネットワークの情報については、speedtest.net に、応答時間、帯域幅、および全体的な接続品質を測定するツールが用意されています。マイクロソフトのさまざまなデータ センター間の遅延は、Matthew Rosoff 氏の Azure Statistics を使用して表示することができます。Azure を操作するときは、数多くのツールが役立ちます。次の一覧は、サード パーティの特定のツールを承認または推奨するものではありません。

Azure PowerShell コマンドレット

診断をリモートで管理するための最適な方法は、Azure PowerShell コマンドレットを使用することです。このコマンドレットは Azure 管理および診断 API に基づいており、CodePlex プロジェクトから完全なソース コードを入手できるので、基になる API の理解を深めることができます。バージョン 2.0 リリースでは、Azure 診断の構成/ダウンロード/クリーンアップのすべての操作を行うことができます。Michael Washam 氏のブログに、優れたスクリプト例が記載されています。

Network Monitoring: AlertBot、Gomez、Keynote、Pingdom

Compuware の Gomez アプリケーション パフォーマンス管理、KeynotePingdom、および AlertBot は、外部から Azure アプリケーションを監視するためのソリューションです。これらを使用すると、アプリケーションの可用性を監視し、パフォーマンスを最適化できます。Pingom など一部のサービスでは、エラーが検出されたときに、電子メール、SMS、またはデスクトップ通知を有効にすることができます。この種類の監視では、正常に監視するためのエンド ユーザーの操作をシミュレートする必要があります。これは、完全に機能することなく Web ロールにホーム ページが表示される場合があるためです。

Azure Check

Apica の AzureCheck は、"外部から" Azure Web アプリケーションを監視するツールです。このツールを使用するためには、コードをダウンロードし、スタートアップ タスクとしてデプロイに追加する必要があります。このツールの利点は、ログをストレージ アカウントに保存する必要がないため、監視コストが下がることです。

Azure Diagnostics Manager

Cerebrata の Azure Diagnostic Manager は、Azure 診断を管理するための Windows ベースのクライアントです。このクライアントは、WAD によって収集されたログを表示またはダウンロードします。WAD 構成を管理することもでき、ダッシュボードによりライブ パフォーマンスを監視できます。

Azure ストレージ エクスプローラー

Azure Storage を参照するには、数多くの方法があります。Azure Storage チームは、ストレージ エクスプローラーの一覧を作成しました。これらのうちいずれを使用しても、WAD ファイルと Azure Storage 解析ファイルを表示することができます。Cloudberry Lab の Explorer for Azure Blob Storage は、[ストレージ設定] をクリックすることでアプリケーションで直接 Storage Analytics を有効にすることができるユーザー インターフェイスを備えています。

IntelliTrace

Microsoft Visual Studio 2010 Ultimate には、運用環境へのデプロイの前にアプリケーションをデバッグするために有効にできる IntelliTrace が含まれています。IntelliTrace は ASP.NET および WCF アプリケーションをサポートしています。Intellitrace は運用サービスで有効にしたときはサポートされませんが、Azure へのデプロイ後にアプリケーションの例外を取得するために使用できます。Jim Nakashima のブログ投稿では、IntelliTrace を使用して Azure クラウド サービスをデバッグする方法が説明されています。

AVIcode

Microsoft は AVIcode を買収し、AVIcode は、現在 Microsoft System Center の一部となっています。AVIcode は、アプリケーション監視機能の総合的なスイートにより、.NET アプリケーション パフォーマンスの監視機能を提供します。

Fiddler

Fiddler は、コンピューターとインターネット間ですべての HTTP(S) トラフィックを記録する Web デバッグ プロキシです。Fiddler を使用すると、トラフィックを検証し、ブレークポイントを設定して、受信データまたは送信データを操作することができます。Fiddler は、特に Azure Storage のトラブルシューティングに役立ちます。

ローカル開発ファブリックに対して Fiddler を使用するには、127.0.0.1 の代わりに ipv4.fiddler を使用します。

  1. Fiddler を起動します。

  2. 開発ファブリックでサービスを起動します。

  3. http://ipv4.fiddler:/ を参照します。Fiddler が要求をトレースします。

ローカル開発ストレージに対して Fiddler を使用するには、サービス構成ファイルを変更して Fiddler を指します。

  1. ServiceConfiguration.cscfg ファイルを開き、設定文字列を次のように変更します。

    Value=“UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler”

  2. Fiddler を起動します。

  3. サービスを起動します。Fiddler がストレージ要求を追跡します。

パフォーマンス プロファイル

Azure で Azure アプリケーションを実行しているときに、Azure アプリケーションをプロファイリングしてパフォーマンスの問題を特定できるようになります。Visual Studio から Azure に Azure アプリケーションを発行するときには、アプリケーションのプロファイリングを選択し、必要なプロファイル設定を選択することができます。

Azure VM Assistant

VM Assitant ツールは、リモート デスクトップをインスタンスに配置するときに、すべての関連データを 1 つの場所に収集して問題の診断時間を節約できる CodePlex プロジェクトです。[VM Health] ボタンにより、インスタンスの現在の状態がわかります。

クラウド ベースのソリューションの場合、ソフトウェア設計者や開発者は、企業データセンターのサーバーにデプロイされる従来のボックス製品ソフトウェアの場合と比較して、設計時に問題への準備を行うことが重要になります。ここでは、クラウドでの軽減について開発者が責任を持つ特定のシナリオを示し、問題が発生したときにすばやく解決できるように準備する方法について説明します。

従来のサーバー ベースのデプロイとの基本的な違いは、サーバー ハードウェアにアクセスできないということです。Azure SDK 1.3 では、Azure ロールにアクセスするためにリモート デスクトップ サービスを使用する機能が追加されました。最新の SDK を使用すると、最適なエクスペリエンスを得ることができます。リモート デスクトップを有効にすることは、サポート可能な Azure サービスを作成するための必須の最初の手順です。この手順は、デプロイ前にのみ行うことができます。

リモート デスクトップを有効にするために必要な手順の 1 つは、ユーザー名、パスワード、およびアカウントの有効期限の選択です。これら 3 つの項目は、Azure 管理ポータルで変更できます。これは、サービスを最初にデプロイした数か月前に設定したパスワードを忘れたときに便利です。

ポータルの [構成] ボタンをクリックしてこれら 3 つのいずれかのパラメーターを変更すると、通常は"更新しています...、ホストを待機しています...、ロールが正常に更新されました、ホストを待機しています...、準備完了" というシーケンスが表示されます。これは、ロールの受信に続いて変更イベントの処理に該当します。お客様は、RoleEnvironment イベントにサブスクライブし、RoleEnvironment.Changing Event を受信したら、変更を受け入れ、実行を維持する (既定) か、インスタンスをオフラインにして変更を適用し、もう一度オンラインにする (e.Cancel = true) ことができます。

変更イベントでコードがロールを再利用する場合、そのホステッド サービスのすべてのロールのすべてのインスタンスが再利用されます。ロールごとに複数のインスタンスがあるサービスでは、更新ドメイン アーキテクチャが原因でダウンタイムは発生しませんが、各ドメインが再利用されるとパフォーマンスが低下する場合があります。さらに重要なのは、1 か月に 1 回のみ再現される問題の発生中は、インスタンスの状態をキャプチャできる機会がないことです。したがって、有効期限が切れていない既知の安全な資格情報でリモート デスクトップ接続を有効にすることをお勧めします。

次に、接続が機能することをテストする必要があります。これを簡単に行うには、ポータルの [接続] をクリックします。ほとんどの場合は、RDP ファイルのコピーを維持し、[ローカル リソース] セクションを変更してローカル ディスクを含めることができるようにします。これにより、インスタンスとの間で簡単にファイルをコピーできます。これを行うには、[ローカル リソース] タブをクリックし、[その他] をクリックします。[全般] タブの接続設定により、.RDP ファイルに設定を保存することができます。

Windows Azure - リモート デスクトップ接続のダイアログ ボックス

VM でのトラブルシューティング方法

これでインスタンスに接続したので、次に何をしたらよいでしょうか。起動しないロールのトラブルシューティングを行っている場合は、こちらの MSDN 記事を参照してください。Kevin Williamson が、ログ ファイルの場所とデバッグするプロセスの概要に関する優れたブログ投稿を公開しています。

VM Assistant をインストールしてログ ファイルを表示し、インスタンスの有益な情報を得ることもできます。また、ネットワーク モニター、Fiddler などのツールをインストールし、ネットワークの状況を確認することもできます。最も簡単なテストは、インスタンスで Internet Explorer を実行して Web サイトに接続することです。これにより、例外の詳細が表示されるためです。

Hosted Web Core のデバッグ

Hosted Web Core を実行している場合、仮想マシンで使用できるのは 1 つのコマンド ウィンドウのみなので、コマンド プロンプトから start を実行して新しいコマンド ウィンドウを開く必要があります。それ以外の場合、Windows Server の完全なエクスペリエンスが取得されます。いくつかの基本的なコマンドの一覧を次に示します。

  • Start – 新しいコマンド ウィンドウを開きます

  • explorer – Windows Explorer を開きます

  • eventvwr – イベント ログ ビューアーを開きます

  • taskmgr – タスク マネージャーを開きます

  • start iexplore – Internet Explorer を実行します

  • services.msc – Service Manager を開きます

  • control – コントロール パネルを開きます

  • certmgr.msc – 証明書マネージャー スナップインを開きます

  • regedit – レジストリ エディターを開きます

  • shutdown /r /t 0 – 仮想マシン インスタンスを再起動します

  • Start Task Manager – コマンド プロンプトを失い、新しいコマンド プロンプトを起動する必要がある場合に便利です (タスク マネージャーから、[ファイル] -> [実行] -> [Cmd] を選択します)

リモート デスクトップは、サポート可能な Azure サービスの基盤ですが、ロール数とインスタンス数が増えたときに制限があります。たとえば、100 以上のインスタンスがある場合に、接続先のインスタンスはどのようにして知ればよいでしょうか。このトラブルシューティング方法を使用すると、確認する項目やその場所がわからない場合に、サイトを再稼働するために必要な時間が増える可能性があります。

重要な点は次のとおりです。

  • デプロイ中に各ロールでリモート デスクトップを有効にします。

  • 強力な既知のパスワードを設定し、資格情報の有効期限が切れないようにします。

  • アクセスをテストし、問題が発生する前に動作することを確認します。

  • 接続の RDP ファイルを保存します。

Azure 診断を使用するには 4 つの主要なタスクがあります。

  1. WAD のセットアップ

  2. データ コレクションの構成

  3. コードのインストルメント化

  4. データの表示

WAD のセットアップ

Azure 診断のアーキテクチャでは、最初にインスタンスのデータを収集し、次にそのデータを Azure Storage で保持します。したがって、最初に Azure Management Portal に移動してストレージ アカウント (たとえば、mylogs) を作成する必要があります。外部の帯域幅に対する追加料金を回避すると同時に待機時間を減らすためには、Azure アプリケーションと同じ地理的な場所にストレージ アカウントを配置することをベスト プラクティスとしてお勧めします。

Azure Tools for Visual Studio バージョン 1.4 (2011 年 8 月) 以降の優れた開発機能の 1 つは、ローカルとクラウドで異なる設定ファイル (ServiceConfiguration.cscfg) を持つことができることです。Nick Harris 氏が自身のブログで指摘しているように、この機能には複数の優れた使用法があります。ローカル テスト用に無料でストレージ エミュレーターを使用する一方、運用環境用に別の構成ファイルを使用できるため、複数のサービス構成を使用できることは診断を行う際に便利です。Azure にパブリッシュしたときに起動しないアプリケーションの主な原因の 1 つとして、UseDevelopmentStorage=true を含む接続文字列を false に変更し忘れる場合があります。

Visual Studio では、[Azure Storage エミュレーターの使用] をクリックすることで、テスト中に簡単に診断を有効にすることができます。

Windows Azure - ストレージ アカウント接続のダイアログ ボックス

アプリケーションをテストし、パブリッシュの準備ができたら、クラウドに対して構成するストレージ アカウント (ServiceConfiguration.Cloug.cscfg) が必要です。David Makogon 氏のブログに、アプリケーションのデータ ストレージとは別に、診断専用のストレージ アカウントを持つ 3 つの理由が示されています。

  1. 診断用に別のアクセス キーを持つことで、アプリケーション データへのリスクなしにログにアクセスできます。

  2. 複数のストレージ アカウントを持ってもコストはかかりません。これは、データ サイズに基づいているためです。

  3. 別のアカウントを持つことで、パフォーマンスが向上する場合があります。

次に、接続文字列を設定します。

<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>" />

AccountName および AccountKey の値は、Management Portal のストレージ アカウント セクションで入手できます。AccountName は、テーブルおよび BLOB ストレージ エンドポイントの URL の最初の部分 (".table.core.windows.net" の前の部分) です。AccountKey は、ストレージ アカウントの base-64 エンコード プライマリ アクセス キーです。

既定では、Azure ログが有効になっているだけで保持されないので、収集するデータの量と、ログを転送するタイミングを次に決定する必要があります。これらは、アプリケーションのパフォーマンスに影響し、ストレージへの毎月の課金を決定するため、些細な決定ではありません。

最初に、Azure 診断によって収集されるデータに必要な合計ストレージを決定する必要があります。この値は、インスタンス/仮想マシン サイズのディスク サイズおよび DiagnosticMonitorConfiguration クラスの OverallQuotaInMB プロパティによって制御されます。たとえば、ExtraSmall 仮想マシン サイズを使用するようにサービス モデルを構成した場合、使用可能なローカル ストレージの最大量は 20 GB になります。既定では、OverallQuotaInMB は 4 GB に設定されます。つまり、合計ローカル ストレージは 16 GB のみになり、アプリケーションおよび一時ファイルに対しては十分でない可能性があります。OverallQuotaInMB は、書き込み可能ラップアラウンド バッファーのサイズを設定します。一方、Web サイトに多くのトラフィックがあり、多くのパフォーマンス カウンターを構成した場合、特に定期的に永続化ストレージに転送しないと、診断データが上書きされる可能性があります。

仮想マシン サイズを設定した後で、4 GB より大きくしたい場合があります。これを行うには、sizeInMB 属性を ServiceDefinition.csdef ファイルで新しいサイズに設定し、OverallQuotaInMB 値を適切に変更して、DiagnosticStore の <LocalStorage> 要素を追加します。

<LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>

cleanOnRoleRecycle 属性の値を false に設定すると、ロールが再利用されたときにローカル ストレージ "DiagnosticStore" がクリーンアップされなくなります。ServiceDefinition.csdef の完全なコードについては、「付録 D:ServiceDefinition.csdef」を参照してください。インスタンスが移動された場合 (ハードウェアの問題など)、この設定によってデータが残ることは保証されません。診断設定は 1 つのロールに固有なため、各ロールに DiagnosticStore を個別に追加する必要があります。

合計が OverallQuotaInMB を超えた場合、Azure 診断は失敗するため、構成した診断データの最大サイズの計算は非常に重要です。このエラーを表示する唯一の方法は、デバッガーをアタッチするか、OnStart メソッドに try catch を追加することです。これは、キャッチ コードがイベントを書き込む場合にアプリケーション イベント ログに表示されます。

Windows Azure - イベント ログ

それでは、"要求されるサブクォータの合計" はどのように計算するのでしょうか。各項目の収集の種類 (イベント ログ、パフォーマンス カウンターなど) には、関連するデータ バッファーがあり、これは既定で 0 です。BufferQuotaInMB プロパティは、既定の 0 のままにするか (OverallQuotainMB より少ない) または明示的に設定できます。OverallQuotaInMB はすべての BufferQuotaInMB プロパティの合計よりも少ない必要があります。

クォータに達した場合、新しいデータが追加されるときに最も古いデータが削除されます。バッファーに対して転送間隔を構成した場合も、この削除ポリシーが適用されます。転送が発生すると、データはローカル ストレージに残り、上のポリシーに従って削除されます。


// Set an overall quota of 8GB.
config.OverallQuotaInMB = 8192;

// Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
config.Logs.BufferQuotaInMB = 1024;
config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
 config.WindowsEventLog.BufferQuotaInMB = 1024;
config.PerformanceCounters.BufferQuotaInMB = 1024;
config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

ディレクトリ サブクォータは 0 に設定され、使用可能なストレージ クォータの残りが使用されます。特定の値を入力する場合、IIS ログ (Web ロール) とクラッシュ ダンプを含めるのに十分なサイズでなければならないた���、他のクォータと同じかそれより大きい必要があります。既定では、Directory.QuotaInMB は 1024 MB に設定されます。この場合、クラッシュ ダンプが 1 GB より大きい場合、ダンプは書き込みに失敗します。ミニダンプは、ダンプのサイズを減らすための 1 つの方法です。

フル ダンプ ファイルには、クラッシュ時のプロセスのメモリ (仮想バイト) が含まれます。64 ビット バージョンの Windows を実行しているので、メモリの上限はコンピューターの物理メモリになります。この値を調べるには、インスタンス/仮想マシン サイズ の表のメモリ列を参照してください。たとえば、ExtraLarge インスタンスのフル クラッシュ ダンプは最大 14 GB です。明らかに、これは使用可能なすべてのメモリをプロセスが使用している最悪なケースのシナリオですが、これはダンプ ファイルをキャプチャする場合に必要となります。

これで収集する診断データの量がわかったので、そのデータを保持するための戦略を決定する必要があります。

1 つのオプションは、問題が発生したことを特定するまでは、データの収集を開始しないことです。このオプションには 2 つの欠陥があります。

  1. 問題が発生したことをどのようにして知るか。重大な問題の報告についてはお客様に任せることができますが、メモリ リークなど潜行性の問題の場合はどうでしょうか。

  2. 問題が発生する前のベースラインは何か。アプリケーションは常に 80% の CPU で実行されるのか、これは問題の兆候でしょうか。

驚くべきことに、このオプションにはコスト、計画、またはアクションが必要ないため、これが最も一般的になっています。これは疑いなく最悪のオプションでもあります。

オプション 2 は、必要なすべてのカウンターを設定するが、Windows Azure Storage にはデータを保持しない方法です。問題が発生したときに、データを検証するか、転送を手動で開始できます。これは、問題が発生するまでにコストが発生しないため、理想的なソリューションのように見えます。残念ながら、オプション 1 と同じ問題がオプション 2 にも該当し、復旧の時間が増えます。

オプション 3 は、診断データがインスタンス上で上書きされない程度に短く、かつアプリケーションのパフォーマンスに悪影響を及ぼさない程度に長い、異なる ScheduledTransferPeriod プロパティを設定する方法です。指定できる最小の転送間隔は 1 分です。それより少ない値は 1 に切り上げられるので、永続化は無効になりません。このため、本当に必要になる前に診断データが転送されていることを確認してください。

多くのコード サンプルでの 1 つの一般的な問題は、ScheduledTransferPeriod が 1 分に設定され、これにより運用環境のアプリケーションのパフォーマンスに悪影響があることです。サンプルで最小値を使用する理由は、動作をすばやく確認できるようにするためです。ほとんどの開発者は、ログの転送の確認に 30 分以上かかることを望みません。この問題に対処するには、2 つの方法があります。その他の便利なツールのいずれかを使用してデプロイ後に WAD 構成を体系的に変更するか、このセクションで前に説明した複数のサービス構成ファイル機能を利用して、コードと設定を ServiceConfiguration.cscfg ファイルに追加します。この設定は ServiceConfiguration.Local.cscfg で次のように作成されます。

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />

ServiceConfiguration.Cloud.cscfg では次のようになります。

<ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="30" />

OnStart メソッドと RoleEnvironmentChanging イベントのコードは次のようになります。

// Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
config.Logs.ScheduledTransferPeriod = myTimeSpan;
config.Directories.ScheduledTransferPeriod = myTimeSpan;
config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

収集されるデータの量の影響する別の変数に、ログ レベルがあります。収集する最も重要なデータ ソースの 1 つはアプリケーション イベント ログです。アプリケーション イベント ログと、場合によってはシステム イベント ログが役立つ場合があります。セキュリティ イベント ログは WAD を通じて使用できません。これらのファイルのサイズは、次のフィルター値を使用してログ エントリのレベルを指定することによって軽減できます。

  • 重大

  • Error

  • 警告

  • 情報

  • 詳細

ログ レベルは累積なので、フィルターが [警告] に設定されている場合、[エラー] と [重大] の両方も同様に転送されます。上の方法を使用して、ローカル構成とクラウド構成に固有の特定の LogLevelFilter レベルを構成できます。ServiceConfiguration.Local.cscfg は次のように��ります。

<Setting name="LogLevelFilter" value="Information" />

ServiceConfiguration.Cloud.cscfg は次のようになります。

      <Setting name="LogLevelFilter" value="Error" />

OnStart メソッドと RoleEnvironmentChanging イベントのコードは次のようになります。

// Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
var myLogLevel = LogLevel.Undefined;
switch (LogLevelFilter)
{
    case ("Information"):
        myLogLevel = LogLevel.Information;
        break;
    case ("Verbose"):
        myLogLevel = LogLevel.Verbose;
        break;
    case ("Warning"):
        myLogLevel = LogLevel.Warning;
        break;
    case ("Critical"):
        myLogLevel = LogLevel.Critical;
        break;
    case ("Error"):
        myLogLevel = LogLevel.Error;
        break;
    default:
        break;
} 

// Filter what will be sent to persistent storage.
config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

推奨のコードはニーズに合う場合と、合わない場合があります。コードを追加せず、コードで設定されているものではなく最後の既知の構成を使用する場合は、別のソリューションがあります。

構成ファイルの使用

Azure SDK 1.3 では、コードを記述する代わりに XML ファイルに構成を配置する機能が追加されました。David Hardin は、これが Azure ロールのすべての種類について、診断を構成するための最も効率的な方法であると主張しています。この方法には、次のようにコードの記述に対して多くの利点があります。

  1. WAD は OnStart が実行される前に起動するので、スタートアップ タスクのエラーがキャッチされます。

  2. 実行時に構成に加えた変更が再起動後も維持されます。

  3. ロールが起動しなくなる例外の原因となる追加のコードを必要とすることなく、設定された構成で診断を自動的に開始します。

  4. これはベータ仮想マシン ロールから診断を取得するための唯一の方法です。

  5. 構成の変更でコードをリビルドする必要がありません。

サンプルの diagnostics.wadcfg は「付録 F:diagnostics.wadcfg」にあります。diagnostics.wadcfg という名前の構成ファイルが次の場所に配置されている必要があります。必ず [出力ディレクトリにコピー] を [常にコピーする] に設定します。

  • ワーカー ロールの場合、構成ファイルはロールのルート ディレクトリにあります。

  • Web ロールの場合、構成ファイルはロールのルート ディレクトリ内の bin ディレクトリにあります。

  • ベータ仮想マシン ロールの場合、構成ファイルは、Azure Management Portal にアップロードするサーバー イメージの %ProgramFiles%\Azure Integration Components\<VersionNumber>\Diagnostics フォルダーにある必要があります。<VersionNumber> は、使用している Azure SDK のバージョンです。既定のファイルは、変更できるこのフォルダーにあります。または、独自のファイルでこのファイルを上書きすることもできます。

このファイルの形式は次の MSDN ドキュメントに記載されています。wad-control-container BLOB ストレージ コンテナーに既に XML 構成がある場合、.wadcfg ファイルは無視されます。また、ファイル内のすべてが正しいことを確認する必要があり、そうしないと診断は収集されません。

これで、収集する情報を決定する準備が整いました。

データ コレクションの構成

構成ファイルを使用しない場合、診断を開始する最適な場所は、try/catch ブロック内の OnStart メソッドです。ブロックにより、問題があった場合に適切に処理することができ、それによりロールの再利用がスタックすることがなくなります。OnStart メソッドにコードを配置する危険は、すべての例外を処理しない場合、ロールはデバッグが困難な再利用ループに入ることです。このメソッドでは、ロール インスタンスは Busy に設定され、インスタンスは Azure ロード バランサーを通じて使用できません。OnStart メソッドが false を返すか、例外がある場合、ロール インスタンスはすぐに停止されます。メソッドが true を返す場合、Azure は Run メソッドを呼び出してロールを開始します。

try/catch ブロックで OnStart コードをラップすることで、例外が発生したときにロールで再利用を回避する (Management Portal の状態が準備完了にならない) ことができます。catch コードには Trace.WriteLine メソッド呼び出し (MSDN の例) を含めるか、イベント ログ エラーを記録する (ASP.NET デバッグ ブログ) ことができます。イベントをイベント ログに記録することで、ロールが開始しない理由を確認しやすくなります。Tom Christian が提案しているこのコードの小変更は、次のようにアプリケーション イベント ログに例外を記録することです。

catch (Exception e)  
    {
            string sSource;
            string sEvent;
            sSource = "WaAppAgent";
            sEvent = "WorkerRole OnStart Event: " + e.Message;
            EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

完全なコードが「付録 B:Web ロールのコード サンプル」にあります。診断を構成する最も強力な方法は、構成ファイルと、Management Portal から構成を動的に変更できるコードの両方を使用することです。

これで Azure 診断を設定できたので、データの収集を開始できます。収集できるデータの種類は次の 5 つです。

  • クラッシュ ダンプ

  • Windows イベント ログ

  • パフォーマンス カウンター

  • IIS ログ

  • FREB ログ

次の表は、既定でローカルに収集されるデータと、明示的に構成する必要があるデータの概要を示しています。

 

データ ソース 既定の構成 説明

DiagnosticInfrastructureLogs

有効、ローカルに保存、永続的ストレージへの転送は定義されていません。ストレージ テーブル WADDiagnosticInfrastructureLogsTable に転送します

診断インフラストラクチャそのものに固有のログです。通常、これらはあまり役に立ちません。

ログ

有効、ローカルに保存、永続的ストレージへの転送は定義されていません。ストレージ テーブル WADLogsTable に転送します

アプリケーション コードに配置される System.Diagnostics.Trace ログ。

ディレクトリ

wad-iis-failedreqlogfiles wad-iis-logfiles、および wad-crash-dumps BLOB は自動的に既定で作成され、それぞれで DirectoryQuotaInMB プロパティが 1024 MB に設定されます。追加のディレクトリを構成することもできます

ログ データは ScheduledTransferPeriod の転送間隔で転送されます。

PerformanceCounters

無効。これが追加された場合、ストレージ テーブル名は WADPerformanceCountersTable になります

パフォーマンス カウンターは明示的に指定する必要があります

WindowsEventLog

無効。これが追加された場合、ストレージ テーブル名は WADWindowsEventLogsTable になります

Windows イベント ログには DataSources は指定されません。

CrashDumps

ミニ クラッシュ ダンプがローカルに収集されます。完全なダンプを有効にできます。wad-crash-dumps は、BLOB ストレージで作成された名前です。

完全なクラッシュ ダンプを取得するには、EnableCollection(true) メソッドを呼び出します。

IIS 7.0 で失敗した要求トレース データ

無効。これを追加すると、BLOB ストレージ名は wad-iis-failedreqlogfiles になります

これは Web.config で有効にする必要があります

  • クラッシュ ダンプ

    Azure 診断では自動的にクラッシュ ダンプが収集されません。ミニダンプを収集するには、次のコードを追加する必要があるため、構文はわかりにくくなります。

    // Enable crash mini dump collection.
                    CrashDumps.EnableCollection(false);
    
    完全なダンプを収集するコードは次のようになります。

                    // Enable full crash dump collection.
                    CrashDumps.EnableCollection(true);
    
    Directory.QuotaInMB の設定の説明では、完全なダンプがある場合、完全なダンプを保存するには十分なローカル ストレージとストレージ全体を割り当てる必要があります。

  • イベント ログ

    イベント ログは、アプリケーション エラーを検索するための最も便利な方法です。アプリケーション イベントとシステム イベントを追加する方法は次のとおりです。

    // Add in configuration settings for Windows Event logs           config.WindowsEventLog.DataSources.Add("Application!*");
    config.WindowsEventLog.DataSources.Add("System!*");
    
    Azure 診断の開始後に発生したイベントのみが収集され、これにより、診断の開始と構成に関する推奨の方法を使用しない限り、イベント ログは起動の問題の診断には役に立たなくなります。

    特定のイベントのみをフィルター処理することもできます。Steve Marx 氏のブログに、XPath クエリを作成して役立つ情報のみを取得する方法が説明されています。たとえば、次の XPath クエリを Add メソッドと共に使用すると、WaAppAgent メッセージのみが取得されます。

    ("Application!*[System[Provider[@Name='WaAppAgent']]]")
    
  • パフォーマンス カウンター

    パフォーマンス カウンターは明示的に追加する必要があります。これらのカウンターを設定するうえでの問題は、1 つが間違っている場合、そのロールのすべてのカウンターに障害が発生することです。コンピューティング エミュレーターの出力ウィンドウには、次のエラーが表示されます。

    [MonAgentHost] Error:  PdhExpandWildCardPath(\Process(_Total)) failed
    
    Web およびワーカー ロールは、次の複数の言語を使用できます。すべての種類のロールについて、推奨される基本的なパフォーマンス カウンターがあります。次の例のプロセス名 (WaWorkerHost) は、Web ロールに対して WaIISHost に変更する必要があります。.NET コードを実行しないワーカー ロールに固有のコードについては、「付録 C:ワーカー ロールのコード サンプル」を参照してください。

    • @"\Process(WaWorkerHost)\% Processor Time "

    • @"\Process(WaWorkerHost)\Private Bytes "

    • @"\Process(WaWorkerHost)\Thread Count"

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    .NET 言語コードを実行する Web ロールまたはワーカー ロールについては、監視する必要がある追加のカウンターがあります。ここでも、次の例のプロセス名 (w3wp) を、これがワーカー ロールの場合は WaWorkerHost に変更し、完全な IIS モードで Web ロールを使用している場合は WaIISHost に変更する必要があります。.NET 言語コードを実行する Web ロールの推奨のカウンターについては、「付録 B:Web ロールのコード サンプル」を参照してください。

    • @"\Process(w3wp)\% Processor Time "

    • @"\Process(w3wp)\Private Bytes "

    • @"\Process(w3wp)\Thread Count "

    • @"\Processor(_Total)\% Processor Time"

    • @"\Memory\Available Bytes"

    • @"\ASP.NET\Applications Running"

    • @"\.NET CLR Interop(_Global_)\# of marshalling"

    • @"\.NET CLR Jit(_Global_)\% Time in Jit"

    • @"\.NET CLR Loading(_Global_)\% Time Loading"

    • @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec"

    • @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps"

    • @"\.NET CLR Networking(_Global_)\Connections Established"

    • @"\.NET CLR Remoting(_Global_)\Remote Calls/sec"

    完全な IIS モードが使用されていない場合、文字列 WaIISHost は w3wp に変更する必要があります。前に説明したように、ScheduledTransferPeriod により、カウンターがストレージに保持されるかどうかと、そのタイミングが決定されます。

  • IIS ログ

    Azure Web ロールは既定で ログ記録を有効にして IIS で実行され、UTF-8 でエンコードされた W3C 形式で、アプリケーションのリソース フォルダー (たとえば、C:\Resources\directory\c5c31518818e46569fa68f0809b5a6aa.fm_WebRole.DiagnosticStore\LogFiles\Web) に、ログ ファイル ロールオーバー を [毎時間] に設定されて書き込まれます。サイトごとに 1 つのログ ファイルがあります。いずれかのインスタンスにリモートで接続し、インターネット インフォメーション サービス マネージャーを開くと、次の設定が表示されます。

    Windows Azure - ログのダイアログ ボックス

    既定のログ記録オプションは特定の要件に合わせて変更することができます。任意の変更をスタートアップ タスクに組み込む必要があるため、各インスタンスの再起動時に設定が失われることはありません。たとえば、ログ エラーのみを記録するには、Appcmd.exe を利用します。これはスタートアップ タスクの IIS7 の一部で、次のコマンドが含まれます。

    appcmd set config /section:httpLogging /dontLog:False /selectiveLogging:LogError
    
  • 失敗した要求トレース

    Web ロールがある場合は、失敗した要求トレース (以前の失敗した要求バッファリングまたは FREB) ログを収集します。これは Web.config ファイルで、次の行を <system.webServer> セクションに追加して行います。

    <tracing>
          <traceFailedRequests>
            <add path="*">
              <traceAreas>
                <add provider="ASP" verbosity="Verbose" />
                <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                <add provider="WWW Server" areas="Authentication, Security, Filter, StaticFile, CGI, Compression, Cache, RequestNotifications,Module" verbosity="Verbose" />
              </traceAreas>
              <failureDefinitions timeTaken="00:00:20" statusCodes="400-599" />
            </add>
          </traceFailedRequests>
        </tracing>
    
    これにより、15 秒以上かかる要求や、ステータス コードが 400 ~ 599 (failureDefinitions 要素) の要求の障害ログが記録されます。FREB ログが作成されると、自動的にストレージに永続化されます。

  • その他のディレクトリ

    インスタンスに書き込まれる他のファイル (特にゲスト エージェント ファイル) を収集することをお勧めします。これらのファイルにより、ゲスト エージェントと Azure ファブリック コントローラー間の処理に関する情報を得ることができます。そのためには、Azure 診断でコピーされるディレクトリを設定する必要があります。

              // Add a custom directory transfer
              DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
              directoryConfiguration.Container = "wad-custom-logs";
              directoryConfiguration.DirectoryQuotaInMB = 0;
              directoryConfiguration.Path = @"c:\logs\WaAppAgent.log";
              config.Directories.DataSources.Add(directoryConfiguration);
    
    構成が失敗した場合、ここでも同じ問題が該当します。コンピューティング エミュレーターをテストするには、このフォルダーを作成し、複数のロールがこのコードを実行していないことを確認する必要があります。そうしないと、共有違反が発生します。各インスタンスが異なるため、このエラーはクラウド構成では発生しません。

WAD のトラブルシューティング

これですべてを構成したので、コンピューティング エミュレーターと Azure のデプロイでテストする必要があります。診断が表示されない場合はどうなるのでしょうか。確認する項目の一覧を次に示します。

  1. 診断ストレージ アカウントで wad-control-container BLOB コンテナーの BLOB を確認しま���。<deploymentID>/<RoleName>/<RoleInstance> (3981bcff0eb743ddb9b7574a8821e955/WebRole1/WebRole1_IN_0) という名前の BLOB を探します。

    1. XML ファイルを開き、想定どおりに構成されていることを確認します。特定のデータ ソースで <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes> が表示される場合は、データを転送するように診断が構成されていません。

    2. 複数のインスタンスがあり、その一部が診断を転送しているがそうでないインスタンスもある場合は、XML ファイルを比較し、すべてが正しく構成されていることを確認します。

    3. デプロイ後に診断を構成し、診断がランダムに動作を停止する場合、おそらくロールが再利用されたか、インスタンスが再起動されたことが原因です。インスタンスが再起動すると、カスタムのデプロイ後設定は失われ、コードで構成された診断が使用されます。.wadcfg ファイルを使用する主要な利点の 1 つは、この構成はロールの再利用で上書きされないことです。

  2. 診断ストレージ アカウントの WADDiagnosticInfrastructureLogsTable テーブルのログを確認します。DeploymentId (DeploymentId eq 'bd9e149f76e8413aba8865c77326e449') に基づいてフィルター処理することをお勧めします。診断が転送されない理由を示す例外またはメッセージを探します。

  3. Diagnostics.Trace 情報が収集されない場合は、DiagnosticMonitorTraceListener が web.config または app.config で構成されていることを確認します。この構成は、既定でクラウド プロジェクトで構成されますが、変更される場合もあり、その場合は診断でトレース ステートメントが収集されません。

  4. 一般的な問題は、診断ストレージに正しくクエリを実行しないために結果が返されず、診断が正しくキャプチャされていないと判断することです。診断テーブルに対してクエリを実行し、DeploymentID をフィルター処理して、診断が正しく転送されているかどうかを確認します。一般的なクエリのミスを次に示します。DeploymentID にフィルターを設定せず、継続トークンに従わない。

  5. デプロイ後、インスタンスが起動しない場合は、ServiceConfiguration.cscfg ファイルで構成されたストレージ アカウントが "UseDevelopmentStorage=true" に設定されていないことを確認します。2011 年 8 月以降のバージョンの Azure Tools for Visual Studio 2011 を使用している場合は、警告が表示されます。インスタンスへの RDP 接続が必要ない場合は、C:\Config フォルダーにあるロール構成ファイルを確認します。

  6. さらに、インスタンスに接続しているときは、DiagnosticsAgent.exe と MonAgentHost.exe が実行されていることを確認します。実行されている場合は、WinDBG をインストールおよびアタッチして、例外がスローされるかどうかを確認できます。

  7. また、診断がローカルに書き込まれるかどうかも確認できます。

    • 開発環境では、.tsf ファイルは次の場所に書き込まれます。

      c:\Users\<username>\AppData\Local\dftmp\Resources\<deploymentID>\directory\DiagnosticStore\Monitor\Tables

    • 実行中のインスタンスでは、ファイルは次の場所に書き込まれます。

      c:\Resources\<deploymentID>.<role>\directory\DiagnosticStore\Monitor\Tables

    現在、これらのファイルを読み取るには、サポート ケースを作成し、それらを Microsoft に送信する必要があります。

  8. 複数のインスタンスがあり、その一部のみが診断を正しく転送していない場合は、Management Portal からロールのイメージを再適用してみてください。その場合、問題発生の根本的な理由を判断することができなくなるため、これは最終的な手段として使用する必要があります。

コードのインストルメント化

最も重要と見なされる診断データは、開発者が独自に記述するコードに追加するトレース メッセージです。システム データによって例外が示されたり、エラー メッセージが記録されたりすることがあります。依存システムへの特定の呼び出しにまでトレースできます。エラーになる可能性がある依存システム (たとえば、サード パーティの認証サービス) を呼び出すときにトレース メッセージを追加することをベスト プラクティスとしてお勧めします。

ETW フレームワークは TraceEventType を各イベントに関連付けます。

 

TraceEventType レベル 意味

重大

1

0x0001

致命的なエラーまたはアプリケーション クラッシュ

Error

2

0x0002

復旧可能なエラー

警告

3

0x0004

重大でない問題: より重大な問題が発生することを示している可能性があります

情報

4

0x0008

情報メッセージ

詳細

5

0x0010

デバッグ トレース (詳細な例外フロー情報、パラメーターなど)

開始

0x0100

論理操作の開始

中止

0x0200

論理操作の停止

コードのインストルメント方法を計画したら、System.Diagnostics 名前空間を追加し、トレース メッセージを追加します。C# では次のようになります。

Trace.WriteLine("LoggingWorkerRole entry point called", "Information");

Azure はフル IIS (SDK 1.3) の実行を開始したので、Web アプリケーション コードは RoleEntryPoint とは別のアプリケーション ドメインとプロセスで実行されます。この場合、Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener 以下の Web.Config にトレース リスナーを追加しない限り、トレース メッセージはコンピューティング エミュレーターに表示されません。

<add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
    <filter type=""/>
</add>

より複雑なアプリケーションでは、EventId 手法により、ログをより効率的にフィルター処理でき、それにより問題解決を迅速化できます。C# の WriteLine を使用すると、EventId は常に 0 になります。EventId を指定するには、TraceEvent メソッドを使用する必要があります。traceType については、上の表を参照してください。

Trace.TraceEvent(traceType, eventId, message);

トレース メッセージは WADLogsTable 表に永続化されます。Azure は記録された各イベントに、タイムスタンプ、(100 ナノ秒の粒度のより細かなタイミングを与える) ティック数、およびデプロイ、ロール、およびロール インスタンスに関する情報を自動的に関連付けます。これにより、特定のインスタンスにログを絞り込むことができます。メッセージは XML 形式で次のように格納されます。


<Properties>
 <EventTickCount>634402131502204503</EventTickCount>
 <DeploymentId>deployment(28)</DeploymentId>
 <Role>WebRole1</Role>
 <RoleInstance>deployment(28).Sample.WebRole1.0</RoleInstance>
 <Level>3</Level>
 <EventId>20</EventId>
 <Pid>10796</Pid>
 <Tid>7172</Tid>
 <Message>trace message; TraceSource 'Data' event</Message> 
</Properties>

レベルは TraceEventType に対応します。上の表では、レベル 3 は "警告" に対応することがわかります。TraceEventType が指定されていないか、Trace.WriteLine を使用する場合、レベルは 5 (詳細) に設定されます。

ほとんどの時間、標準のログ記録で十分です。より詳細な種類のログ記録の場合、カスタム トレース リスナーを作成できます。

Azure Table Query は、LINQ クエリを使用して WADLogsTable にクエリを実行できるようにする Web ロールの CodePlex プロジェクトです。

データの表示

診断を収集する理由は、問題が発生したときに容易に診断を利用できるようにするためです。つまり、データのバックアップが正しく動作していることを確認するのと同様に、問題が発生する前にすべてが正しく動作していることを確認する必要があります。つまり、アプリケーションのテスト中に診断データを表示し、次に定期的にそれが動作していることを確認します。言い換えれば、ベースラインを作成し、異常なパフォーマンスが発生したときにそれを知ることができるようにします。

すべての Azure 診断データは、WAD を起動するときに指定するストレージ アカウントに格納されます。Visual Studio Server Explorer または多くの storage explorers の 1 つを使用してこのデータを視覚化できます。

wad-control-container BLOB には、診断構造そのもののログ記録が含まれます。ここで、データが特定のインスタンスから転送されているかどうかを確認できます。BLOB の ID は次の形式になります。

0aef2b51ad1d49ef915dd41d3ca01f24/WorkerRole1/WorkerRole1_IN_0

この ID は 3 つの部分に区切られます。

  1. 長い数値はデプロイメント ID です - 0aef2b51ad1d49ef915dd41d3ca01f24

  2. ロール名 - WorkerRole1

  3. インスタンス名 - WorkerRole1_IN_0

複数のインスタンスがある場合、ゼロ ベースのサフィックスが増加します。たとえば、WorkerRole1_IN_1 が 2 番目のインスタンスになります。

次の表は、各ログの書き込み先を示しています。

 

ログの種類 Azure Storage 形式 説明

コードから生成された Azure ログ

Table

トレース リスナーを web.config または app.config ファイルに追加する必要があります。ファイルは WADLogsTable に格納されます。

IIS 7.0 ログ

BLOB

Web ロールのみ。パス wad-iis-logfiles\<デプロイ ID>\<Web ロール名>\<ロール インスタンス>\W3SVC1 以下の BLOB コンテナーに格納されます。

Windows 診断インフラストラクチャ ログ

Table

診断サービスそのものに関する情報です。WADDiagnosticInfrastructureLogs テーブルに格納されます。

失敗した要求ログ

BLOB

Web ロールのみ。web.config の system.WebServer 以下のトレース オプションを設定して有効にします。パス wad-iis-failedreqlogfiles\<デプロイ ID>\<Web ロール名>\<ロール インスタンス>\W3SVC1 以下の BLOB コンテナーに格納されます。

Windows イベント ログ

Table

初期構成を行うときに DiagnosticMonitor Configuration.WindowsEventLog を変更にして有効にします。WADWindowsEventLogs テーブルに格納されます。

パフォーマンス カウンター

Table

DiagnosticMonitor Configuration. PerformanceCounters を変更して有効にします。WADPerformanceCounters テーブルに格納されます。サンプル コードのワーカー ロールがパフォーマンス カウンターを設定します。

クラッシュ ダンプ

BLOB

CrashDumps.EnableCollection を呼び出して有効にします。パス wad-crash-dumps 以下の BLOB コンテナーに保存されます。ASP.NET によってほとんどの例外が処理されるため、これは一般的にワーカー ロールに対してのみ機能します。

カスタム エラー ログ

BLOB

この方法の有益な例については、Neil Mackenzie 氏のブログを参照してください。

永続ストレージにクラッシュ ダンプ データを転送すると、wad-crash-dumps BLOB コンテナーに格納されます。IIS ログは wad-iis-logfiles BLOB コンテナーに転送されます。失敗した要求は wad-iis-failedreqlogfiles BLOB コンテナーに格納されます。

イベント ログは永続ストレージの WADWindowsEventLogs テーブルに転送されます。パフォーマンス カウンターは指定された間隔で WADPerformanceCounters テーブルに転送されます。WADDiagnosticInfrastructureLogs には、診断インフラストラクチャに関するログが含まれます。トレース リスナーは WADLogsTable テーブルにあります。

診断データを表示するには、Jason Haley 氏の AzureLogsWithLINQPad サンプルで LINQPad を使用する方法があります。

診断の管理

これらすべてのログ ファイルを Azure Storage に保持すると、費用と時間の両方がかかります。最適なソリューションは、特定の問題を解決する必要があるときに "ジャスト イン タイム" でトレースを有効にすることです。診断設定を動的に変更するときは、手動で元の設定に戻すか、変更が必要な場合は元の設定を変更する必要があります。.wadcfg ファイルを使用していないときは、この意識的な手順が特に重要になります。インスタンスを再起動すると、新しい設定はコードで構成した診断設定に置き換えられるためです。

Azure PowerShell コマンドレットにより、診断を含む Azure サービスの実行に関する多くの側面を管理できます。これらのコマンドレットはローカル コンピューターから実行します。コマンドレットは、Azure 管理 API および診断 API を使用してインターネット経由でサービスに接続し、情報および調整パラメーターを提供します。

Windows PowerShell は Windows 7 と共にインストールされ、Azure Management Tool (MMC) と共にインストールされるサービス管理コマンドレットが発展したものです。より有益なコマンドレットのいくつかを次に示します。

  • Get-DiagnosticConfiguration - 指定されたバッファー名 (Logs、Directories、PerformanceCounters、WindowsEventLogs、または DiagnosticInfrastructureLogs) のバッファー構成を取得します。

  • ロールの構成を変更するには、Set-DiagnosticConfiguration コマンドレットを使用します。

  • Start-OnDemandTransfer - 指定されたデータ バッファーのオンデマンド転送を開始します。これにより、データが Azure Storage (テーブルまたは BLOB ストレージ) に移動します。

David Aiken 氏のブログ に、一部のログ ファイル (IIS ログ ファイルおよび wad-control-container XML ファイル) をクリーンアップするスクリプトが公開されています。Clear-Container コマンドレットを各コンテナーに対して呼び出す必要があります。スケジュールされた転送が削除と重複しないことを確認する必要もあります。また、テーブルに格納されたログ (パフォーマンス カウンター、イベント ログなど) の戦略も考慮する必要があります。一部のユーザーは Azure Storage からすべてのダウンロードし、SQL Server データベースに配置して、ストレージに対して課金されず、データでより複雑なクエリを実行できるようにしています。

開発者は、Azure 診断リソースを理解することで、以下に示す設計のベスト プラクティスを使用してサポート可能なアプリケーションを構築できます。

アプリケーションの状態はベースラインに対して測定する必要があります。ホーム ページが表示されることは、必ずしもアプリケーションが正常であるという意味ではありません。ビジネス ロジックの状態とパフォーマンスの理解も、状態の完全なベースラインを作成するために必要です。

次の手順では、状態のロールアップについて理解します。良い状態の最初の柱となるのは、Azure の請求に対して期限どおりに支払いを行うことです。未払いのサブスクリプションがあると、徐々に悪影響が生じ、最終的にはアプリケーションが削除されることになります。

Azure ホステッド サービスでは、各サブスクリプションについて、アプリケーションの状態に影響する 4 つのレベルがあります。

Windows Azure - 動作状態のレベル

たとえば、ハードウェアの障害や再起動、ソフトウェアの更新によってインスタンスに障害が発生する可能性があります。構成しているインスタンスが 1 つのみでない限り、これによってロールに障害は発生しません。同様に、各ホステッド サービスは特定の地区 (米国中南部など) にあります。この重要な情報によって、アプリケーションがサービス中断イベント (中断) によって影響を受けるかどうかが決まります。低いレベルの障害では、アプリケーション設計に冗長性が組み込まれていない場合、ホステッド サービス レベルで障害が発生する場合があります。

ほとんどの Azure アプリケーションでは、前の図よりも複雑なアーキテクチャを必要とします。おそらく、アプリケーションは次のようになります。

Windows Azure - アーキテクチャの例

分散されているという性質により、考えられる複数の障害ポイントが発生します。これらの重要なパスを記録しておくと、トラブルシューティングの効率が高まります。たとえば、上の図では、Access Control で障害が発生したことをどのようにテストするのでしょうか。

アプリケーションで発生した問題を理解するためには、アプリケーションの状態を監視および記録する必要があります。一般的に、アプリケーションに関して 4 つのカテゴリの情報を記録します。

  • プログラム: 例外、主要な変数の値、およびアプリケーションのデバッグに必要な情報。

  • ビジネス プロセス: セキュリティ、変更の追跡、コンプライアンスに必要な監査。

  • システムの安定性: パフォーマンス、スケーラビリティ、スループット、待機時間。

  • ビジネスの想定事項の検証: アプリケーションは想定どおりに使用されていますか。

人間の性質の最も基礎的な要素は、危機が発生したときに動きを止めてしまうことです。トレーニングと練習により、この性質を克服することができます。私たちが消火訓練を行ったり、一部の航空会社が衝突安全性のコースを実施しているのはこのためです。ほとんどの大企業は予算のかなりの額を災害復旧計画に費やしています。ベスト プラクティスとして、「データセンターの災害復旧の Microsoft IT 実装」を参照してください。

ここでは、問題が発生した場合のトラブルシューティングを迅速化するテクニックについて紹介します。アプリケーションがトラブルシューティングを容易にする方法で構築されていることがわかれば、サイトを稼働させるための時間を減らしているときに問題が発生しても、ストレスを軽減することができます。コストの利点分析により、システムに組み込むフォールト トレランスの量が決定されます。たとえば、ダウンタイムを減らすために Traffic Manager によって提供されるホット バックアップを持つことによって発生する追加のコストは価値があるのでしょうか。

Azure Traffic Manager では、同じデータ センターにデプロイされているか、世界の別のセンターにデプロイされているかにかかわらず、受信トラフィックを管理し、Azure ホステッド サービスに分散することができます。これは、フェールオーバー サービスを構成する機能を提供し、プライマリ サービスがダウンした場合に、一覧で次に使用可能なサービスにトラフィックを送ります。AkamaiLimelight などのサード パーティ製ソフトウェアにも、負荷分散ソリューションがあります。

解決を迅速化するための 5 つの手順の計画を次に示します。

計画の最初の手順では、発生したらすぐに問題について知る必要があります。問題が発生しているのを早く知れば、復旧計画の実装を開始できます。このため、監視が鍵となります。

2 番目の手順では、問題の発生源 (Azure プラットフォームまたはアプリケーション内) を特定します。最初に調べる場所は、Azure サービス ダッシュボードです。このサイトでは、アプリケーションが使用するすべてのサービスと、サービスがデプロイされるデータ センターを知っておく必要があります。アプリケーションに影響するサービスの低下は 1 つのみです。

Azure プラットフォームのサービス イベントを監視するために、アプリケーションのすべての RSS フィードにサブスクライブする方法があります。たとえば、アプリケーションが米国中北部のデータ センターでホストされている場合、こちらの RSS フィードにサブスクライブします。

Azure Storage はフォールト ドメイン (ラック、ネットワーク スイッチ、パワー) を使用してハードウェア障害の影響を制限しています。Azure Storage に関して、1 つの場所 (米国中南部など) 以外のデータのレプリカは、自動的にレプリカにフェールオーバーするという誤解がよくあります。ストレージで特定の場所に問題がある場合、データへのアクセスが影響を受けます。次のストレージ チームのブログに、新しい地域レプリケーション機能のすべての詳細が公開されています。

3 番目の手順では、問題をローカライズします。これはおそらく、複数の Azure サービスを使用する複雑なアプリケーションでの最も困難な手順です。ステートレスなサービスを構築すると、アプリケーションのさまざまな部分を分離することができます。すべての依存サービスが正常に実行されている場合は、コンピューティング サービスの状態を判断する必要があります。これを行うには、Management Portal で [ホステッド サービス、ストレージ アカウント、CDN] セクションを開き、デプロイを選択します。プロパティ ウィンドウで、次のように表示されます。

Windows Azure - デプロイ プロパティ

この場合、過去 8 日、デプロイは正常に実行されていることがわかります。これは操作が最後に完了した時間と最後に更新された時間の差によって計算されます。一方、デプロイが最近中止または再起動された場合、これにより、確認する場所を正確に特定するのに役立ちます。これが特定のデータ センターのすべてのデプロイに影響するサービス イベントであると思われる場合は、Microsoft (866) 676-6546 にすぐにご連絡ください

4 番目の手順では、ログ ファイルやイベント ログの確認、デバッガーのアタッチ、Procmon やネットワーク モニターなどのツールの使用により標準的なトラブルシューティング手順を実行し、問題の兆候が見つかるかどうか確認します。Azure ホステッド サービス デプロイで最初に確認する場所はアプリケーション イベント ログです。アプリケーションによってスローされる例外がないことを確認します。現在、すべてのサポートは無料なので、これは不要に思われる場合があります。実際には、お客様のアプリケーションの全体範囲について知識を持っていない熟練のマイクロソフト サポート エンジニアよりも、お客様の方が問題を見つけ、修正できることの方が多くなっています。サイトが稼働することが不可欠の場合は、最初に確認することが最善の代替手段です。

5 番目の手順は、Microsoft サポートに連絡することです。問題の解決を迅速化するには、サブスクリプションのアカウント所有者に関連付けられたフェデレーション ID (Windows Live ID) を提供する必要があります。これは、Microsoft Online Services カスタマー ポータルにログインしてサブスクリプションを管理するために利用する電子メール アドレスです。さまざまなログ ファイルで見つかった問題とエラーのソースの分析結果も提供する必要があります。Microsoft サポート エンジニアは、自分をサブスクリプションの共同管理者として追加し、お客様とまったく同じように Management Portal を表示できるように要求する場合があります。

パフォーマンスは美しさに似ています。それは見る人の目に映るものです。パフォーマンスが許容されなくなるしきい値はどれでしょうか。ページのタイムアウトでしょうか。最大読み込み時間を定量化しても、お客様のすべての顧客に対してページが読み込まれることは保証されません。DNS ルートとネットワークの信頼性は、ページの読み込み時間を決定する 2 つの主要な要素です。たとえば、テキサス州メンフィスのお客様の場合、ISP がテキサス州サンアントニオのトラフィックを最初にシカゴに送っていました。Microsoft Online Services では、応答時間、帯域幅、および全般的な接続品質を測定するパフォーマンス ツール テストを提供しています。マイクロソフトのさまざまなデータ センター間の遅延を確認するには、Matthew Rosoff 氏の Azure 統計情報を参照してください。

この記事では、パフォーマンスの詳細な説明は行いません。Azure での開発のベスト プラクティスについては、TechNet の記事「SQL Azure パフォーマンス/弾力性ガイド」を参照してください。パフォーマンスのトラブルシューティングは、ベースラインの設定で開始します。このため、長期間にわたりパフォーマンス データを収集することが不可欠です。ベースラインを設定すると、傾向や異常を確認できるようになります。

Azure プラットフォームでは、さまざまなサービスの可用性/接続のレベルを定義するサービス レベル契約 (SLA) を提供しています。お客様の SLA は何でしょうか。私個人の ISP は、パッケージに SLA がないため、接続を仕事用に使用するべきではないと伝えてきたことがあります。信頼性は、それがお客様の基になるネットワーク接続に大きく依存していて、見る人の判断によって決まる点がパフォーマンスと少し似ています。上のリンクは、ネットワーク接続のパフォーマンスを理解するうえで役立ちます。

1 つの一般的なミスは、Azure プラットフォーム SLA がアプリケーションに対しても同じ SLA を保証すると想定することです。最初に、次の 2 番目の文を読まないユーザーがいます。

コンピューティングに関して、異なるフォールトで複数のロール インスタンスをデプロイし、ドメインをアップグレードした場合、インターネットに接するロールは少なくとも 99.95% の時間、外部接続が可能なことを保証します。

この文には語句が欠落しており、正しくは "1 ロールあたり複数のロール インスタンス" です。つまり、Web ロールとワーカー ロールがあり、それぞれに 1 つのインスタンスがある場合、アプリケーションはホスト OS のアップグレードがあるか、なんらかの種類のシステム修復があるたびに使用できなくなることを意味します。Azure コンピューティングでは、フォールト ドメインを使用して SLA に準拠するようにしています。

別の誤解として、特定の OS バージョンを選択した場合、OS の更新によって中止は発生しないという認識があります。これはインスタンスで実行されるゲスト OS の場合は当てはまりますが、データ センターで実行される物理コンピューター上で実行されるホスト OS には当てはまりません。

信頼性を最大化するには、Window Azure 診断データを使用して内部的にサイトを監視すると共に、Apica の AzureCheck、Compuware の Gomez、または Pingdom を使用して外部的にサイトを監視する必要があります。また、最新のセキュリティ修正プログラムを適用し、コード変更の検証計画を持っていることも確認する必要があります。

Visual Studio で新しいアプリケーションを作成するときの既定の動作では、ServiceConfiguration.cscfg ファイルで次のようにゲスト OS バージョンを設定します。

osFamily="1" osVersion="*"

これにより、自動更新が可能になります。これは PaaS の主要な利点の 1 つです。最新の OS を使用していないため、これは最適ではありません。最新の OS バージョン (Windows Server 2008 R2) を使用するためには、設定は次のようである必要があります。

osFamily="2" osVersion="*"

残念なことに、多くのお客様は、ゲスト OS の更新を回避することで稼働時間を増やそうとして、特定のバージョンの OS をロックすることを決定します。ステージングで各更新をシステム的にテストし、運用環境で実行されているミッション クリティカルなアプリケーションで VIP スワップをスケジュールする企業のお客様にとって、これは唯一の合理的な戦略です。各ゲスト OS の更新をテストしないその他のお客様にとって、自動更新を構成しないことは、Azure アプリケーションをリスクにさらすことになります。

特に緊急の場合にサービスを更新する必要があるときのプランは何でしょうか。しばしば無視されるこの手順により、サイトがダウンするか、ステージングのわずかな問題に対応するかの差が生まれます。多くの時間と労力が Azure アプリケーションの初期計画とリリースに費やされますが、変更の修正はボックス製品よりも容易であるため、多くの場合、更新には多くのテストは必要ないと想定されます。後退は迅速に修正できます。残念なことに、後退によって致命的な障害も簡単に発生します。

運用アプリケーションへのすべての変更は、運用環境への最終的なデプロイの前にテストする必要があります。障害により発生する可能性のある結果を考慮すれば、ある程度の時間をかける価値は十分にあります。詳細については、「Azure サービスの更新の概要」を参照してください。

この記事で説明しているトピックを検討いただき、ありがとうございました。何がお客様にとって有効であったかについて、お客様のフィードバックをお寄せください。サービスがダウンすることによるコストを、診断データを収集するコストと比較する必要があります。この計算は運用環境に移行する前に行う必要があります。信頼性の高い Azure アプリケーションの開発に必要な作業は新しいものではなく、革新的でもなければ技術的に困難なものでもありません。設計者と開発者は、アプリケーションで発生する可能性のある問題について検討し、この記事で説明している手法を適用するだけです。

  • Tom Christian、「初期化/ビジー/停止状態でスタックした Azure ロールのヘルプ」、ブログ、2011 年 2 月 25 日。

  • Andy Cross「Azure コンピューティング エミュレーター SDK V1.3 のトレース」、ブログ、2011 年 1 月 22 日。

  • Jason Haley「方法: LINQPad を使用した Azure ログ テーブルのクエリ」、ブログ、2010 年 1 月 28 日 15:09。

  • David Hardin「diagnostics.wadcfg 構成ファイルを介した WAD の構成」、ブログ、2011 年 3 月 29 日。

  • Mike Kelly「Azure でのログ記録とトレースの管理」、MSDN マガジン、2010 年 6 月。

  • Neil Mackenzie「Azure のカスタム診断」、ブログ、2009 年 12 月 8 日。

  • David Makogon「Azure 今日のヒント: 別の診断ストレージ アカウント」、ブログ、2010 年 8 月 15 日。

  • Steve Marx「Azure 診断でのフィルター処理された Windows イベントのキャプチャ」、ブログ、2010 年 4 月 21 日。

  • Toddy Mladenov「Azure でのイベント ログの収集」、ブログ、2010 年 5 月 2 日。

  • Walter Myers「Azure Web およびワーカー ロールでのパフォーマンス カウンターの設定」、ブログ、2011 年 1 月 31 日。

  • Jim Nakashima「IntelliTrace を使用した Azure クラウド サービスのデバッグ」、ブログ、2010 年 6 月 7 日。

  • Jim O'Neil「Azure デプロイでの 500 とその他のエラー」、ブログ、2011 年 4 月 11 日 4:47 AM。

  • Michael Stiefel「私の Azure アプリケーションがクラッシュした理由。Azure 診断 API を使用したコードの問題の発見」、ブログ、2011 年 9 月 8 日。

  • Michael Washam「Azure PowerShell コマンドレット 2.0 を使用したログ ファイルの管理」、ブログ、2011 年 9 月 20 日。

  • Kevin Williamson「Azure ロール アーキテクチャ」、ブログ、2011 年 5 月 5 日。

  • Azure 管理ポータル (http://manage.windowsazure.com)。

  • Azure プラットフォーム トレーニング コース - 演習 3 - Azure でのアプリケーションの監視。

  • Azure ポータル http://www.microsoft.com/windowsazure/

 

ファブリック

コンピューターの論理クラスター。仮想マシン内でロール実行環境を提供します。

FREB

失敗した要求トレース (旧称は失敗した要求バッファリング)

Management Portal

Azure Management Portal は、Azure サービスを管理、デプロイ、および監視するための管理ポータルです。Management Portal は http://manage.windowsazure.com でアクセスできます。

REST

Representational State Transfer: Web サービスをリソースとして表示し、その URL によって識別できるステートレスなクライアント サーバー アーキテクチャを使用するソフトウェア設計。

SLA

サービス レベル アグリーメント

仮想マシン

実際のコンピューターの分離されたパーティションで実行されるコンピューターのソフトウェア エミュレーション。

WAD

Azure Diagnostics

Web ロール

Web ロールは、IIS 7 と ASP.NET によってサポートされている Web アプリケーション プログラミング用にカスタマイズされたロールです。

ワーカー ロール

ワーカー ロールは、一般化された開発に役立ち、Web ロールのためにバックグラウンド処理を実行できるロールです。

この付録では、Azure 診断を構成するために必要なコードについて説明します。ロール インスタンスの起動をカスタマイズできるように、RoleEntryPoint.OnStart メソッドが呼び出されます。OnStart の独自の実装を提供して、ロールに合わせて WAD の構成に必要なコードを実行できます。

public override bool OnStart()
{
    string sSource = "WaAppAgent";
    string sEvent = null;

    try
    {
        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;

        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        } 

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);
 

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Private Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(w3wp)\Thread Count",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Interop(_Global_)\# of marshalling",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
             CounterSpecifier = @"\.NET CLR Jit(_Global_)\% Time in Jit",
             SampleRate = perfSampleRate
         });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Loading(_Global_)\% Time Loading",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Memory(_Global_)\# Bytes in all Heaps",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Networking(_Global_)\Connections Established",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\.NET CLR Remoting(_Global_)\Remote Calls/sec",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

        sEvent = "Management OnStart called diagnostics";
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType. Information, 0);
    }
    catch (Exception e)
    {
        sEvent = "Management OnStart Event: " + e.Message;
        EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
    }

    return base.OnStart();
}

この付録では、ワーカー ロールで Azure 診断を構成するために必要なコードについて説明します。

public override bool OnStart()
{
    // Set the maximum number of concurrent connections 
    ServicePointManager.DefaultConnectionLimit = 12;
    string sSource = "WaAppAgent";
    string sEvent = "WorkerRole OnStart Event: ";

    try
    {
        // For information on handling configuration changes
        // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

        DiagnosticMonitorConfiguration config = DiagnosticMonitor.GetDefaultInitialConfiguration();

        // Set an overall quota of 8GB.
        config.OverallQuotaInMB = 8192;
        // Set the sub-quotas and make sure it is less than the OverallQuotaInMB set above
        config.Logs.BufferQuotaInMB = 1024;
        config.Directories.BufferQuotaInMB = 0; // Use the rest of the storage here
        config.WindowsEventLog.BufferQuotaInMB = 1024;
        config.PerformanceCounters.BufferQuotaInMB = 1024;
        config.DiagnosticInfrastructureLogs.BufferQuotaInMB = 1024;

        // Get ScheduledTransferPeriod setting from ServiceConfiguration.cscfg and then set it 
        var myScheduledTransferPeriod = RoleEnvironment.GetConfigurationSettingValue("ScheduledTransferPeriod");
        TimeSpan myTimeSpan = TimeSpan.FromMinutes(Convert.ToDouble(myScheduledTransferPeriod));
        config.Logs.ScheduledTransferPeriod = myTimeSpan;
        config.Directories.ScheduledTransferPeriod = myTimeSpan;
        config.WindowsEventLog.ScheduledTransferPeriod = myTimeSpan;
        config.PerformanceCounters.ScheduledTransferPeriod = myTimeSpan;
        config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = myTimeSpan;

        // Get LogLevelFilter setting from ServiceConfiguration.cscfg and then set it
        var LogLevelFilter = RoleEnvironment.GetConfigurationSettingValue("LogLevelFilter");
        var myLogLevel = LogLevel.Undefined;
        switch (LogLevelFilter)
        {
            case ("Information"):
                myLogLevel = LogLevel.Information;
                break;
            case ("Verbose"):
                myLogLevel = LogLevel.Verbose;
                break;
            case ("Warning"):
                myLogLevel = LogLevel.Warning;
                break;
            case ("Critical"):
                myLogLevel = LogLevel.Critical;
                break;
            case ("Error"):
                myLogLevel = LogLevel.Error;
                break;
            default:
                break;
        }

        // Filter what will be sent to persistent storage.
        config.Logs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = myLogLevel;
        config.WindowsEventLog.ScheduledTransferLogLevelFilter = myLogLevel;

        // Add in configuration settings for Windows Event logs
        config.WindowsEventLog.DataSources.Add("Application!*");
        config.WindowsEventLog.DataSources.Add("System!*");

        // Add a custom directory transfer
        DirectoryConfiguration directoryConfiguration = new DirectoryConfiguration();
        directoryConfiguration.Container = "wad-custom-logs";
        directoryConfiguration.DirectoryQuotaInMB = 0;
        directoryConfiguration.Path = @"c:\logs";
        config.Directories.DataSources.Add(directoryConfiguration);

        // Enable full crash dump collection.
        CrashDumps.EnableCollection(true);

        // Use 30 seconds for the perf counter sample rate.
        TimeSpan perfSampleRate = TimeSpan.FromSeconds(30D);

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Memory\Available Bytes",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Processor(_Total)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\% Processor Time",
            SampleRate = perfSampleRate
        });

        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Private Bytes",
            SampleRate = perfSampleRate
        }); 
                
        config.PerformanceCounters.DataSources.Add(new PerformanceCounterConfiguration()
        {
            CounterSpecifier = @"\Process(WaWorkerHost)\Thread Count",
            SampleRate = perfSampleRate
        });

        // Apply the updated configuration to the diagnostic monitor.
        // The first parameter is for the connection string configuration setting.
        DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);

    }
    catch (Exception e)  
        {
                sEvent += e.Message;
                EventLog.WriteEntry(sSource, sEvent, EventLogEntryType.Error, 0);
        } 
            
    return base.OnStart();   
}

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" cleanOnRoleRecycle="false" sizeInMB="8192" />
    </LocalResources>
  </WebRole>
  <WorkerRole name="WorkerRole1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
    <LocalResources>
      <LocalStorage name="DiagnosticStore" sizeInMB="8192" cleanOnRoleRecycle="false" />
    </LocalResources>
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" />
      <Setting name="LogLevelFilter" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

noteメモ
この構成ファイルはコンピューティング エミュレーターでローカルに使用するものです。

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Windows_Azure_Full_Diagnostics" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="ScheduledTransferPeriod" value="1" />
      <Setting name="LogLevelFilter" value="Verbose" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="me" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="MIIBnQYJKoZIhvcNAQcDoIIBjjCCAYoCAQAxggFOMIIBSgIBADAyMB4xHDAaBgNVBAMME1dpbmRvd3MgQXp1cmUgVG9vbHMCEDra5x6UQkuIRHdUChkiglEwDQYJKoZIhvcNAQEBBQAEggEAp8ADE0ov0pKTFo6V1AI94NmsUr8YcQ/dl4M63zbBQkrjSvqqzgofMcMwxYVO8gTwmr3eXawTNp2fbPdN68ZynNgRwEHBm67QP3y6lcAFvx8Amxvp8GZ6qxpAYGE8LhpqBNzoel55mot6IZg0I3qfXtl6SHyfLcyGuPv3nDEzhuYGuPSFR+UF82G2ZK0omLzSuI3KQcbFyTxaUYDIu/fSNOkHVOWwgpNND3SIvg+nSHfS38w+nskAA7bo7oN06LnC+3lLNRrpoKsPBaqogqfyhTkivc3+AJoQ6UAHIyyAJU6kfp4iP7gMl0ZU1mLVeqX5oDwmywf9FGRf7vSn2uEfiTAzBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECAw305eQdOSogBA6i8i7rTruZOxAadm1g545" />
      <Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2011-12-31T23:59:59.0000000-05:00" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="D91092F38C839BE56787A0528591E49510FCC711" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

これは、Web ロールの diagnostics.wadcfg ファイルの例です。

<?xml version="1.0" encoding="utf-8" ?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
      configurationChangePollInterval="PT1M"
      overallQuotaInMB="4096">
  <DiagnosticInfrastructureLogs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Logs bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M" />
  <Directories bufferQuotaInMB="0"
     scheduledTransferPeriod="PT1M">

    <!-- These three elements specify the special directories 
           that are set up for the log types -->
    <CrashDumps container="wad-crash-dumps" directoryQuotaInMB="0" />
    <FailedRequestLogs container="wad-frq" directoryQuotaInMB="0" />
    <IISLogs container="wad-iis" directoryQuotaInMB="0" />
  </Directories>

  <PerformanceCounters bufferQuotaInMB="0" scheduledTransferPeriod="PT1M">
    <!-- The counter specifier is in the same format as the imperative 
           diagnostics configuration API -->
    <PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\% Processor Time" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Private Bytes" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\Process(w3wp)\Thread Count" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Interop(_Global_)\# of marshalling" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Loading(_Global_)\% Time Loading" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR LocksAndThreads(_Global_)\Contention Rate / sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Memory(_Global_)\# Bytes in all Heaps" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Networking(_Global_)\Connections Established" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Remoting(_Global_)\Remote Calls/sec" sampleRate="PT30S" />
    <PerformanceCounterConfiguration counterSpecifier="\.NET CLR Jit(_Global_)\% Time in Jit" sampleRate="PT30S" />
  </PerformanceCounters>
  <WindowsEventLog bufferQuotaInMB="0"
     scheduledTransferLogLevelFilter="Verbose"
     scheduledTransferPeriod="PT1M">
    <!-- The event log name is in the same format as the imperative 
           diagnostics configuration API -->
    <DataSource name="Application!*" />
    <DataSource name="System!*" />
  </WindowsEventLog>
</DiagnosticMonitorConfiguration>

これは wad-control-container BLOB に書き込まれる既定の構成です。

<?xml version="1.0"?>
<ConfigRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <DataSources>
    <OverallQuotaInMB>4080</OverallQuotaInMB>
    <Logs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </Logs>
    <DiagnosticInfrastructureLogs>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </DiagnosticInfrastructureLogs>
    <PerformanceCounters>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
    </PerformanceCounters>
    <WindowsEventLog>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions />
      <ScheduledTransferLogLevelFilter>Undefined</ScheduledTransferLogLevelFilter>
    </WindowsEventLog>
    <Directories>
      <BufferQuotaInMB>0</BufferQuotaInMB>
      <ScheduledTransferPeriodInMinutes>0</ScheduledTransferPeriodInMinutes>
      <Subscriptions>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\FailedReqLogFiles</Path>
          <Container>wad-iis-failedreqlogfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\LogFiles</Path>
          <Container>wad-iis-logfiles</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
        <DirectoryConfiguration>
          <Path>C:\Users\me\AppData\Local\dftmp\Resources\c95f5289-7d10-4bff-b105-198904c9ad93\directory\DiagnosticStore\CrashDumps</Path>
          <Container>wad-crash-dumps</Container>
          <DirectoryQuotaInMB>1024</DirectoryQuotaInMB>
        </DirectoryConfiguration>
      </Subscriptions>
    </Directories>
  </DataSources>
  <IsDefault>true</IsDefault>
</ConfigRequest>

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft