新しいアプリケーションの監視を開始する方法
発行: 2016年3月
適用対象: System Center 2012 R2 Operations Manager,System Center 2012 - Operations Manager,System Center 2012 SP1 - Operations Manager
新しいアプリケーションについての理解を深めるために、System Center 2012 – Operations Manager の .NET アプリケーション パフォーマンス監視テンプレートを使用してそのアプリケーションの監視を構成できます。 ここでは、新しいアプリケーションの理解に役立ついくつかの基本的な設定について説明します。 また、監視はテスト環境や開発環境で使い始めるのが理想的です。
新しいアプリケーションの監視設定
次に説明する新しいアプリケーションを監視するための方針は、お使いのシステムや顧客の環境におけるアプリケーションの動作を理解する上で役立ちます。
単純な監視対象システムと短期的な設定によりサーバー側のみで監視を開始する
最初に、単純な構成を使用します。 1 つのサーバー上の 1 つのアプリケーションを監視します。 次に、新しいアプリケーションの監視のために .NET アプリケーション パフォーマンス監視を初めて構成するときに、ある程度の傾向を把握するのに十分な期間にわたってその設定を維持するように計画を立てます。 1 日分に相当するデータにより、アプリケーションのパフォーマンスと使用パターンについて把握できるはずです。
既定の設定と特定の設定を使用してベースライン パフォーマンスを確立する
多くの場合に、既定の設定をそのまま利用することになります。 既定の設定により、アプリケーションの大きな問題を把握しながら、監視対象となるアプリケーションへの影響を最小限に抑えることができます。
パフォーマンス イベントや例外イベントが発生していない場合、次の手順を使用してベースライン パフォーマンスがどのようなものか大まかに把握できます。
監視を開始する際に、以下のように設定を調整できます。
パフォーマンスのしきい値を下げます。 これにより、アプリケーションの現在のパフォーマンス特性がどのようなものかを確認することで、ベースライン パフォーマンスの基準を定義できます。
名前空間をすべて有効にします。 これにより、関連するすべての名前空間を確認できるようになります。特定の名前空間を最初に設定すると、エラーが発生している名前を見逃してしまう可能性があります。
重大な例外だけでなく、例外をすべて収集します。 どのような例外がスローされているのか理解する必要があります。 既知の例外ハンドラーを使用した場合、受信する例外が制限されます。
この結果、長期監視で求められている以上の大量データが生じる可能性があります。しかし、当初このデータ量は、顧客のシステムの利用動向や、通常のパフォーマンス状態などの傾向を確認するために役立ちます。
データ収集が完了したら、アプリケーションのパフォーマンス分析などの Application Advisor レポートを使用し、監視対象のアプリケーションの状態を確認します。 このレポートを使用し、システムで最も負荷の高い (最も長時間にわたる) 呼び出しの平均時間と、要求の処理に費やされる最長時間を確認できます。 これにより、実際のアプリケーション パフォーマンスに基づいてカスタマイズされたスマートなしきい値を設定できます。 また、他の関数よりも高速で実行されている関数も確認でき、重大なメソッドに対して特定の Web ページ、Web メソッド、およびの関数のトランザクションを作成し、アプリケーション全体よりも厳しい SLA に従って応答させることができます。 レポート表示の詳細については、「Application Advisor を使用したアラートの優先順位設定」で Application Advisor レポートのスコープ設定方法および実行方法を参照してください。
設定の調整およびベースラインとの比較
ベースライン パフォーマンス基準を定義したあとは、設定の調整を始めて、発生している例外の種類を検出できるように監視を調整します。 例外をすべて報告することで、アラートを受信すべき例外をキャッチしている既定の例外ハンドラーがアプリケーションにあるかどうかが分かります。 取得されるデータは調整のたびにより有意なものとなり、少数になります。
収集したデータに基づいてカスタム設定を削除し、しきい値を設定します。
ベースライン フェーズ中に見つかったパフォーマンス イベントと例外イベントのコール スタックに基づいて、特定の名前空間を追加します。
アプリケーション外部への例外の送信を防ぐ "キャッチオール" ハンドラーと、.NET Framework 例外ハンドラーに、あらゆるアプリケーション レベル用の例外ハンドラーを追加します。
アプリケーション全体よりも高レベルの SLA に従う必要がある一般的なメソッドのパフォーマンスを監視するために、特化したトランザクションをモニターに追加します。
新しいデータをベースラインと比較します。 たとえば、実際の平均応答時間を確認できるようになります。 これによりアプリケーションが送信するさまざまなパフォーマンス例外を把握できるため、名前空間をすべて監視する代わりに、必要な特定の名前空間を追加できます。 アプリケーションは測定されたパフォーマンス レベルに基づいて監視されるように構成され、正常なレベルから外れるとアラートが生じます。
システムのより多くの監視対象サーバーにアプリケーションを徐々に展開する
新しい監視構成でアプリケーションをしばらく監視したあと、アプリケーションが正常だと判断される場合は、アプリケーションを実行して監視しているサーバーの数をたとえば 1 から 10 に増やします。 そのレベルで正常に実行することが確認できたら、より多くのサーバーに徐々に展開と監視を拡張します。 この段階的なロールアウトのアプローチにより、アプリケーションの監視の信頼度を高め、システムのヘルスを保証できます。
クライアント側の監視を開始する
システムでアプリケーションが正常に実行されていることを確信したら、次はカスタマー エクスペリエンスを監視できます。 これは、クライアント側のアプリケーション監視で実行します。 クライアント側の監視を有効にする方法については、「.NET アプリケーションの監視を構成する方法」を参照してください。
この情報を利用してオペレーターができること
オペレーターはこの基本情報を利用し、問題がアプリケーションまたはインフラストラクチャのどこに起因するのかをより明確に把握し、開発チームだけが解決できるのか、それともオペレーターが自分で直接対処できるのかを判断することができます。