アプリケーションのトラブルシューティング

  • [アーティクル]

AppFabric には、IIS でホストされる .NET Framework Version 4 WCF および WF のサービスを管理する機能があります。 たとえば、永続ワークフロー サービスをホストするための信頼性メカニズムを備えています。また、アプリケーションの構成を簡単に実行できるようになっています。さらに、.NET Framework 4 WCF および WF のサービスの正常性を監視するための各種ツールも付属しています。 ここでは、監視ツールを使用してサービスのトラブルシューティングを行う方法を説明します。

WCF および WF のサービスのトラブルシューティングは、ダッシュボードから開始します。 IIS マネージャーの中で、[AppFabric] グループの [ダッシュボード] アイコンをクリックすると、[ダッシュボード] ページが表示されます。 このページでは、IIS の特定のスコープにおける、展開済みのアプリケーションの正常性の要約が表示されます。また、このページにあるリンクをクリックして、より具体的なトラブルシューティング情報を表示することもできます。 ダッシュボードや関連ページに表示される数値だけでは情報不足で問題を解決できない場合は、WCF または WF のアプリケーションのトラブルシューティングのための System.Diagnostics トレースを AppFabric のツールから有効化することができます。

ダッシュボードを使用したトラブルシューティング

分散アプリケーションの問題の特定は、1 つのカウンターを見るだけで、あるいは 1 つのツールを使用するだけで済むほど単純ではありません。 分散サービス環境においては、さまざまなツールやカウンターからのデータを相互に関連付けて初めて、1 つの問題の真の原因がつかめるということも珍しくありません。 ダッシュボードにある 3 つのウィジェット ([永続的な WF インスタンス]、[WCF 呼び出しの履歴]、および [WF インスタンスの履歴]) を使用すると、アプリケーションのトラブルシューティングのための情報を互いに関連付けることができます。 これらのウィジェットのうち、2 番目と 3 番目は履歴メトリックです。つまり、ダッシュボードの上部にある [期間] で設定された時間 ([過去 1 分間]、[過去 24 時間] など) に応じて、表示される内容が変化します。

この 3 つのウィジェットを最初に開くか表示すると、メトリックの状態について高レベルのサマリーを把握できます。 そのレベルでの問題があるかどうかがすぐにわかります。 たとえば、[永続的な WF インスタンス] ウィジェットに最初に表示されるのは、ライブの永続ワークフロー インスタンスのうち、その状態が永続化ストアに保存されているもののステータスです。 このサマリー ステータス画面では、"アクティブ"、"アイドル"、または "中断" の状態の永続的インスタンスの数が表示されます。 したがって、永続的ワークフローのレベルで問題があるかどうかがすぐにわかります。 サマリー ページのリンクをクリックすると、その特定のサマリー カウンターに関する追加の情報を得ることができます。

[永続的な WF インスタンス] のメトリックの使用

[永続的な WF インスタンス] ウィジェットには、ライブのワークフロー インスタンスのうち、その状態が永続化ストアに保存されているもののステータスが表示されます。 ここには、状態が "アクティブ"、"アイドル"、または "中断" である永続的インスタンスの数が表示されます。 各見出しおよびサマリー カウント自体は、生データが含まれる [永続的な WF インスタンス] ページへのリンクです。

中断状態のインスタンスをトラブルシューティングするときに、問題について詳しく調べるには、ダッシュボードの [中断されたインスタンス] リンクをクリックします。 [永続的な WF インスタンス] ページに、中断状態のインスタンスがすべて表示されます。 中断状態のインスタンスの 1 つを選択すると、画面下部の [詳細] ウィンドウに、そのインスタンスのサマリー情報が表示されます。 [エラー] タブに、そのインスタンスが中断された理由が表示されます。 追加情報が必要な場合は、インスタンスを右クリックして [追跡対象イベントの表示] オプションを選択します。 [追跡対象イベント] ページが開いて、その中断状態ワークフロー インスタンスの追跡対象イベントがすべて表示されます。 既定では、イベントは最新のものから順に表示されます。

[WCF 呼び出しの履歴] のメトリックの使用

[WCF 呼び出しの履歴] ウィジェットには、受信されて監視ストアに記録された WCF 呼び出しの数が表示されます。 見出しには、完了した呼び出しの数、発生した例外の数、およびスロットル ヒット回数のサマリー カウントが表示されます。 最初の列には、完了した呼び出しの数が多い順にサービスが上位 5 位まで表示されます。 2 列目には、WCF エラーの内訳がエラーの種類別に表示されます。 3 列目には、サービス例外の数が多い順にサービスが上位 5 位まで表示されます。 各メトリックは [追跡対象イベント] ページへのリンクとなっており、このページには、ダッシュボードに要約されているデータの生データが表示されます。

たとえば、失敗した呼び出しに関する詳しい情報を表示するには、[失敗した呼び出し] サマリー カウンターをクリックして [追跡対象イベント] ページに進みます。 このページには、IIS 階層内の選択されたスコープに対する失敗した WCF 呼び出しが、新しい順に表示されます。 イベントの 1 つを選択すると、画面下部の [詳細] ウィンドウにその情報が表示されます。 [エラー] タブには、失敗に関する例外情報が表示されます。 失敗した呼び出しの状況をさらに詳しく調べるには、イベントを右クリックして [すべての関連イベントの表示] オプションを選択します。 [追跡対象イベント] ページが更新され、最初のイベントに関連するすべてのイベントが表示されます。

ヒント

[すべての関連イベントの表示] オプションを使用するには、アプリケーションの監視レベルを [エンド ツー エンド監視] 以上に設定する必要があります。 このレベルに設定すると、エンド ツー エンド アクティビティ ID (E2EActivityId) どうしを関連付ける転送イベントが監視インフラストラクチャによって収集されます。

[WF インスタンスの履歴] のメトリックの使用

[WF インスタンスの履歴] ウィジェットには、アクティブ化された、失敗した、または完了したワークフロー インスタンスの数が表示されます。 最初の列には、アクティブ化の数が多い順にサービスが上位 5 位まで表示されます。 2 列目には、失敗の数が多い順にサービスが上位 5 位まで表示されます。 3 列目には、失敗したインスタンスのうち回復されたものの数が表示されます。 たとえば、あるワークフロー インスタンスでエラーが発生してそのインスタンスが中断状態になり、後に再開されて完了した場合は、[失敗] 列と [回復済み] 列の両方に 1 というカウントが表示されます。

[WF インスタンスの履歴] ウィジェットの情報を使用してトラブルシューティングする手順は、[永続的な WF インスタンス] ウィジェットを使用する場合と同様です。 見出しのいずれかをクリックすると、[追跡対象 WF インスタンス] ページにワークフロー インスタンスのサマリー情報が表示されます。 ただし、[WF インスタンスの履歴] ウィジェットに表示されるワークフロー インスタンスは既に完了していることもあるため、[永続的な WF インスタンス] ページとは異なり、インスタンス制御アクションは表示されません。 [追跡対象 WF インスタンス] ページで、インスタンスを右クリックして追跡対象イベントの表示を選択すると、そのインスタンスの低レベルの追跡データを見ることができます。

System.Diagnostics トレース機能を使用したトラブルシューティング

AppFabric では、.NET Framework 4 における WCF トレーシングおよび WF トラッキングの機能強化が活用されており、イベントを Windows イベント トレーシング (ETW) サブシステムに生成するようになっています。 ETW は、高速のイベント トレーシング インフラストラクチャです。 ただし、状況によっては、トラブルシューティングを行うために、入手可能なあらゆる診断情報を見ることが必要になります。 AppFabric では、System.Diagnostics トレースをアプリケーションまたはサイトのレベルで有効化することができます。 このトレーシング情報は、ディスク上のファイルに書き込まれます。表示するには、サービス トレース ビューアー ツールを使用します。

警告

System.Diagnostics トレーシングを有効化すると、ホスティングされるアプリケーションのパフォーマンスが低下します。また、大きなトレース ファイルが生成されます。 アプリケーションのトラブルシューティングを行うとき以外は、System.Diagnostics トレースを無効にしてください。

分散型 ASP.NET アプリケーションに関するトラブルシューティング

アクティビティ ID (前述の「[WCF 呼び出しの履歴] のメトリックの使用」セクションで説明済み) を使用して永続インスタンス ID を参照し、複数の AppFabric サーバー コンピューターで WCF サービスと通信する ASP.NET アプリケーションのトラブルシューティングに役立てることができます。 これを行うには、監視レベルをエンドツーエンド監視以上に設定してアクティビティの追跡を構成する必要があります。では、この使い方を次の例で説明しましょう。 

管理者が ASP や IIS の監視ツールを使用して Web アプリケーションを監視しています。あるとき、サービスとの通信中に ASP.NET アプリケーションのタイムアウト エラーが増えていることに気が付きました。管理者はエラーを確認した後、エラー発生時にアクティブになっているアクティビティ ID を取得し、AppFabric ダッシュボードを使用して、そのアクティビティ ID に関するクエリを作成して実行します。すると、1 つのイベントが返されました。サービス X のインスタンス Y での受信イベントです。そのイベントに関連するメッセージ フローを表示すると、"同時呼び出しの最大数の超過のスロットル" というイベントがあることに気が付きました。サービス概要のページを見ると、[WCF スロットル ヒット] は 20 に設定されています。また、過去 24 時間の呼び出しを表示すると、この 30 分間で急増していました。 他の日を見てみると、同じ曜日の同じ時間に同じことが起こっています。管理者は、その曜日のその時間帯に負荷が増大しているという結論に達し、同時呼び出しの最大数のスロットル設定を 25 に増やすことにしました。注意深く観察を続けると、スロットル イベントの発生が激減し、WCF サービスの呼び出し時に発生していた ASP.NET アプリケーションのタイムアウト エラーも激減していることがわかりました。

SQL Server エージェント Windows サービスのジョブ

SQL Server エージェント Windows サービスの役割は、SQL Server の動作の監視、管理に必要な処理の自動化、アラートの生成、およびジョブのスケジューリングと実行です。 SQL Server ジョブは、指定された一連の操作で構成されており、これらの操作は SQL Server エージェントによって順に実行されます。このエージェントは、データベースに関連するさまざまなタスクを実行します。 SQL Server を使用するように AppFabric が構成されている場合は、イベントを監視データ ストアにインポートするときや、監視データ ストアから古いデータを定期的に削除するときに SQL Server エージェントが使用されます。

SQL Server エージェントが稼働していなければ、インストールされた SQL Server でスケジュールに従って AppFabric ジョブを実行することはできません。そのようなジョブを確実に、SQL Server エージェント Windows サービスを使用してスケジュールどおりに実行するには、次に示す手順を実行してください。

  1. SQL Server エージェント Windows サービスが実行されていることを確認します。確認するには、この Windows サービスの状態を調べます。 [管理ツール] をクリックし、[サービス] を選択します。[SQL Server エージェント (MSSQLSVR)] を選択して、その [状態] に [開始] と表示されていることを確認します。 そうではない場合は、サービスを開始します。

  2. ストアが初期化されると、次の 4 つの SQL Server ジョブが作成されます。

    • Microsoft_ApplicationServer_Monitoring_AutoPurge_<監視 DB 名>

    • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<監視 DB 名>

    • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<監視 DB 名>

    • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<監視 DB 名>

    SQL Server エージェント Windows サービスの状態が "開始" で、AppFabric ジョブが実行されていない場合は、ジョブの最後の実行時にエラーが発生したかどうかを調べてください。

  3. ジョブは終了しているけれどもイベント テーブルにはイベントが何もない場合は、監視データ ストアにある ASFailedStagingTable テーブルを調べてください。このテーブルには、ErrorNumber や ErrorMessage など、エラーの原因解明に役立つ列があります。エラーが発生していなければ、このテーブルは空です。

AppFabric SQL Server エージェントのジョブを実行する Windows ID (所有者) には、ログイン ユーザー以外のものを使用してください。 具体的には、事前構成済みの Windows セキュリティ アカウントである AS_MonitoringDbJobsAdmin の ID で実行してください。 このアカウントは、ドメイン アカウントであるのが理想的です。監視ストアにおけるこのアカウントのアクセス許可は、インストール後に Initialize-ASMonitoringDatabase コマンドレットが実行されたときに付与されます。

実行を依頼された AppFabric Server ジョブを SQL Server エージェントが処理する方法が、所有者によってどのように異なるかを、次に説明します。

  • SQL Server エージェント ジョブの所有者がドメイン アカウントの場合は、SQL Server はドメイン コントローラーにアクセスして、そのアカウントが有効であるかどうかを調べます。 有効である場合は、そのドメイン アカウントで実行し、そうでない場合はローカル アカウントでの実行を試みます。

  • SQL Server エージェント ジョブの所有者がローカル sysadmin アカウントの場合は、ジョブ ステップの "実行するアカウント名" ID で指定されたアカウントがそのまま使用されて、"ユーザーを AS_MonitoringDbJobsAdmin として実行" コマンドが発行されます。 つまり、ジョブは AS_MonitoringDbJobsAdmin アカウントの ID で実行されます。

    ヒント

    ジョブの "実行するアカウント名" ID を SQL Server Management Studio で表示するには、ジョブを右クリックして [プロパティ] をクリックし、次に [詳細] タブをクリックします。 この値は、AS_MonitoringDbJobsAdmin アカウントに設定されている必要があります。

  • SQL Server エージェント ジョブの所有者がローカル アカウントであるけれども sysadmin ではない場合は、ジョブ ステップで指定された "実行するアカウント名" ID は無視されます。  この場合は、そのローカル所有者のアカウントでジョブが実行されるように構成されます。

  • ドメインが接続されていない場合 (たとえばノート PC の場合) に、SQL Server 監視ジョブの ID がドメイン ユーザーのときは、SQL Server エージェントはそのアカウントを検証するためにドメイン コントローラーにアクセスしようとします。SQL Server エージェント ジョブを実行するコンピューターがドメインに接続されていなければ、検証に失敗します。この問題を回避するためには、次の 2 つのオプションがあります。

    1. 最初の、かつ最も簡単な方法は、ジョブを構成する (つまり、Initialize-ASMonitoringDatabase コマンドレットを実行する) ときにローカル ユーザー アカウントを使用するというものです。

    2. 2 つ目の選択肢は、ジョブの構成時に所有者としてドメイン アカウントが使用された場合に、後でジョブ所有者をローカル ユーザー アカウントに更新するというものです。更新するには、SQL Server のストアド プロシージャ sp_update_job を使用します。

ローカル ログオン アカウントで SQL Server エージェント Windows サービスを実行するように構成することをお勧めします。 このようにすれば、AppFabric のコンピューターがネットワークに接続できないときでもサービスを実行できるようになります。 このサービスがドメイン アカウントで実行され、そのドメインがアクセス不可能の場合は、SQL Server エージェント Windows サービスが資格情報を取得できません。 つまり、監視イベントを最終的な保存場所であるテーブルに正常に移動することができなくなります。 その結果、ダッシュボードに新しいデータが何も表示されなくなります。

SQL Server Express のジョブ

ジョブが失敗した理由を診断する手順は SQL Server の場合とほぼ同様ですが、SQL Server Express の場合は ASJobsTable テーブルを調べる必要があります。このテーブルは、SQL Server Express がインストールされている場合にのみ存在し、SQL Server がインストールされた環境には存在しません。 このテーブル内で、特定のジョブの行の LastRunOn 列と LastRunSuccess 列の値を見ると、そのジョブが正常に完了したか失敗したかがわかります。

SQL Server Express では、SQL Server エージェント Windows サービスは使用されず、 SQL Service Broker が活用されます。Service Broker の内部ではタイムアウト値が設定されており、この値に従って Microsoft_ApplicationServer_Monitoring_AutoPurge_<監視 DB 名> ジョブが実行されます。 このタイムアウトの時間が経過すると、SQL Server のジョブ キューにメッセージが送信されます。 このメッセージが送信されると、Microsoft_ApplicationServer_Monitoring_AutoPurge_<監視 DB 名> ジョブの一部として実行されるストアド プロシージャがアクティブになります。 このストアド プロシージャによって、SQL Server Express ストアに対する自動削除機能が実行されます。

この自動ストア削除機能の進行状況を監視するのに役立つ T-SQL クエリを次に示します。

  • 現在スケジュールされているジョブを表示する: SELECT * FROM ASJobsTable

  • dialog_timer 列 (UTC 時間) を見てジョブが次回実行される日時を調べる: SELECT * FROM sys.conversation_endpoints

  • 現在実行中のアクティブ化プロシージャの数を表示する: SELECT * FROM sys.dm_broker_activated_tasks

  • まだキューの中にあるメッセージの数を調べる (実行中のジョブが 1 つもない場合は 0 が返されます): SELECT * FROM ASScheduledJobQueue

関連項目

参照

[Windows Server AppFabric ダッシュボード] ページ
[永続的な WF インスタンス] ページ
[追跡対象 WF インスタンス] ページ
[追跡対象イベント] ページ

  2011-12-05