| Oracle® Enterprise Manager概要 11gリリース11.1.0.1 B61020-01 |
|
 戻る |
 次へ |
この章では、サービスの概要とサービス管理について説明します。内容は次のとおりです。
今日のビジネス・アプリケーションの持つ重要かつ複雑な性質のため、IT組織にとって、アプリケーションのサービス・レベルを監視および管理して、その高い可用性を維持することは非常に重要です。エンタープライズが直面する問題には、サービスの失敗やパフォーマンスの低下があります。これらのサービスは業務上の伝達を行う上で重要な役割を果すため、サービスを監視し、業務に影響を及ぼす前に問題を迅速に解消することはすべてのエンタープライズにとって重要です。
サービス・レベル契約を使用して、サービスの可用性、パフォーマンスおよび使用状況を評価します。サービス・レベルを定期的に監視することによって、IT組織は、問題とその予想される影響を見極め、サービスの失敗の根本的な原因を診断し、サービス・レベル契約に従ってこれらを修正できます。
Enterprise Managerには、概要レベルから個々のコンポーネント・レベルまでのサービスを効率的に管理できる包括的な監視ソリューションが用意されています。サービスに障害が発生した場合やパフォーマンスが低下した場合に備えて、Grid Controlには、問題を迅速かつ効率的に解決し、問題の特定および解決にかかる管理コストを大幅に削減できる診断ツールが用意されています。最後に、カスタマイズされたレポートには、一定期間にわたってアプリケーションの動作を分析できる有益なメカニズムが提供されています。
Grid Controlは、ITインフラストラクチャ内の個々のコンポーネントだけでなく、これらのコンポーネントによってホストされるアプリケーションも監視します。このため、トップダウン方式を使用して、またはエンド・ユーザーの観点からビジネス機能をモデル化および監視できます。サービスを正しくモデル化すると、モデル化された機能またはアプリケーションの可用性、パフォーマンスおよび使用状況をサービスで正確に測定できるようになります。
サービスは、ユーザーの役に立つ機能を提供するエンティティとして定義されます。たとえば、サービスには、CRMアプリケーション、オンライン・バンキングおよび電子メール・サービスなどがあります。より単純な形式のサービスには、DNS、LDAP、POP、SMTPなどのプロトコルによってサポートされるビジネス機能があります。
Grid Controlを使用して、エンタープライズ内で実行するビジネス機能またはアプリケーションを表す1つ以上のサービスを定義できます。これらのサービスを定義するには、共通のエンド・ユーザー機能をシミュレートする1つ以上のサービス・テストを作成します。これらのサービス・テストを使用して、重要なビジネス機能のパフォーマンスおよび可用性の測定、問題発生時におけるアラートの受信、よく発生する問題の特定、および障害原因の診断を行うことができます。
定義可能なサービス・タイプには、汎用サービス、Webアプリケーション、Formsアプリケーションおよび集約サービスがあります。特別なタイプのサービスであるWebアプリケーションは、Webトランザクションを監視するために使用されます。FormsアプリケーションはFormsトランザクションのモデル化および監視に使用されます。
Grid Controlのサービス・レベル管理機能を理解する上で、次の要素が重要になります。
サービス: ビジネス・プロセスまたはアプリケーションのモデル化。
サービス・テスト: サービスが使用可能で実行されているかどうかを確認するためにEnterprise Manager管理者がサービスに対して定義する機能テスト。
システム: 基礎となるコンポーネントのグループで、サービスを実行するホスト、データベースおよびアプリケーション・サーバーなど。システムの詳細は、この章の「システムの管理」を参照してください。
パフォーマンスおよび使用状況: パフォーマンスは、エンド・ユーザーが体験するレスポンス時間を示します。使用状況は、システムにおけるユーザーによる要求または負荷を示します。
サービスと呼ばれる新しいターゲットを作成し、Grid Control内からビジネス・アプリケーションをモデル化および監視できます。サービスの作成時には、可用性、パフォーマンスと使用状況のパラメータ、およびサービス・レベルのルールを定義できます。
サービスの可用性は、ある時点においてエンド・ユーザーがサービスにアクセスできるかどうかを示す指標です。ただし、可用性を構成するルールは、アプリケーションごとに異なる場合があります。たとえば、カスタマ・リレーションシップ・マネジメント（CRM）アプリケーションの場合、可用性とは、ユーザーがアプリケーションに正常にログインし、販売レポートにアクセスできることです。一方、オンライン・ストアの場合、可用性は、ユーザーがアプリケーションに正常にログインし、ストアを閲覧してオンラインで購入できるかどうかについて監視されます。
Grid Controlでは、サービス・テストまたはサービス・システムに基づいてサービスの可用性を定義できます。
サービス・テスト・ベースの可用性: エンド・ユーザーの重要な機能の可用性によってサービスの可用性が決定される場合、このオプションを選択します。このような重要な機能の例として、電子メールへのアクセス、販売レポートの生成、オンライン銀行業務トランザクションの実行などがあります。サービス・テストを定義する場合、ビジネス・プロセスの重要な機能に最も適したプロトコルと、ユーザー・コミュニティの場所に適したビーコンの場所を選択します。標準プロトコルを使用して1つ以上のサービス・テストを定義し、1つ以上のサービス・テストをキー・テストとして指定できます。キー・テストは、様々なユーザー・コミュニティ内で1つ以上のキー・ビーコンによって実行されます。サービスが使用可能だと認められるのは、可用性の定義に応じて、少なくとも1つのビーコンによって1つまたはすべてのキー・テストを正常に実行できる場合です。
システム・ベースの可用性: サービスの可用性は、サービスをホストする基盤システムをベースにすることもできます。サービスを実行する上で重要なコンポーネントを選択し、1つ以上のコンポーネントをキー・コンポーネントとして指定します。これらのコンポーネントを使用して、サービスの可用性が決定されます。可用性の定義に応じて、少なくとも1つまたはすべてのキー・コンポーネントが起動し、動作していれば、サービスは使用可能と認められます。システムの詳細は、この章の「システムの管理」を参照してください。
サービスのパフォーマンスおよび使用状況を測定するためのメトリックを定義できます。パフォーマンスは、エンド・ユーザーが体験するサービスのレスポンス時間を示します。使用状況メトリックは、システムにおけるユーザーによる要求または負荷に基づいています。
パフォーマンス・メトリックは、ビーコンによってサービス・テストが実行されるときにサービス・テストに対して収集されます。複数のビーコンによって収集されたレスポンス・データの最小値、最大値および平均値を計算できます。たとえば、サンフランシスコ、東京およびロンドンの電子メール・サービスから電子メールを受信するために要する時間を監視し、これらの結果を比較できます。また、システム・コンポーネントについてもパフォーマンス・メトリックを収集し、すべてのコンポーネントにわたって最小値、最大値および平均値を計算できます。たとえば、複数のホストを対象として平均のCPU使用率、メモリー使用率およびディスクI/O使用率を監視できます。
使用状況メトリックは、サービスがホストされているシステム・コンポーネントの使用状況に基づいて収集されます。たとえば、IMAPサーバーに基づく電子メール・サービスを定義する場合、IMAPサーバーの合計クライアント接続メトリックを使用して、この電子メール・サービスの使用状況を示すことができます。特定のコンポーネントの使用状況を監視したり、一連のコンポーネントの最小、最大および平均の値を統計的に計算できます。また、前述のメトリックに対してしきい値を設定し、通知およびアラートを受信することもできます。しきい値の設定の詳細は、この章の「サービスの監視」を参照してください。
組織におけるビジネスのパフォーマンスを測定するためのメトリックを定義できます。ビジネス・メトリックは、システム・ベースのサービスのために収集されます。システム・ベースではないメトリックは、データ交換機能を使用して定義できます。データ交換機能の詳細は、『Oracle Enterprise Manager統合ガイド』を参照してください。
特定のシステム・コンポーネントまたは集計のパフォーマンスに基づいて、ビジネス・メトリックを定義できます。また、これらのメトリックに対してしきい値を設定し、通知およびアラートを受信することもできます。
サービス・レベルのパラメータを使用して、サービスの品質を測定します。通常、これらのパラメータは、実際のサービス・レベル契約または業務目的に基づいています。
Grid Controlのサービス・レベル管理機能を使用して、サービス・レベル契約を下回っていないかどうかエンタープライズを能動的に監視し、サービスの営業時間内での可用性、パフォーマンスおよびビジネス・ニーズが満たされているかどうかを確認できます。サービス・レベル契約については、業務上または契約上の目的に応じてレベルを指定できます。
サービス・レベルを基準として監視を行うことにより、ビジネス・プロセスおよびアプリケーションの品質を保証し、そのコンプライアンスを確認できます。
管理者は、多くのアプリケーションに対して、同じ監視属性やルールを定義するタスクに直面することがしばしばあります。このような場合、同じルール・セットを様々なアプリケーションに適用できます。これを行うには、Grid Controlの監視テンプレート機能を使用します。サービスの監視テンプレートには、1つ以上のサービス・テストの定義の他、監視ビーコンのリストが含まれています。標準サービス・ターゲットから監視テンプレートを作成し、このテンプレートをコピーして任意の数のサービス・ターゲットに対してサービス・テストを作成し、監視ビーコンのリストを指定できます。これにより、多数のアプリケーションを監視する必要がある場合にかかる構成時間を短縮できます。
システムは、1つ以上のサービスを集中してホストするターゲットの論理グループです。連携して1つ以上のアプリケーションやサービスを提供する、一連のインフラストラクチャ・ターゲット（ホスト、データベース、アプリケーション・サーバーなど）です。
Enterprise Managerでは、複数のシステムによって1つの新しいターゲット・タイプが構成されます。たとえば、Enterprise Managerで電子メール・アプリケーションを監視するには、最初に、電子メール・アプリケーションが動作するターゲットであるデータベース、リスナー、アプリケーション・サーバーおよびホストで構成されるメール・システムなどのシステムを作成します。次に、電子メール・アプリケーションを表すサービス・ターゲットを作成して、この電子メール・アプリケーションがメール・システム・ターゲット上で動作するように指定します。
|
注意: Enterprise Managerのシステムは、サービスが実行されているコンポーネントを監視することを目的として使用されます。グループとシステムにはよく似た機能が数多くあります。 |
「システムの作成」ページを使用して、次の構成タスクを実行します。
新しいシステムのターゲット・コンポーネントを選択します。
トポロジ・ビューアを使用してシステムのコンポーネント間の関連を定義します。
該当するシステムの「グラフ」ページに表示されるグラフを追加します。このグラフは、システムまたはシステムのコンポーネントの全体的なパフォーマンスを示しています。「コンポーネント」ページで選択したコンポーネントのターゲット・タイプに基づいて、一部のグラフは事前に定義されています。
「システム・コンポーネント」ページおよびOracle Grid Controlのこのシステムのダッシュボードに表示する一連の列を選択します。
リフレッシュ頻度をカスタマイズし、Oracle Grid Controlのこのシステムのダッシュボードでコンポーネント・ステータス、アラートおよびポリシー違反を表示する書式を指定します。
Enterprise Managerには、複数のアプリケーションを対象としたトポロジ・ビューアが用意されています。トポロジ・ビューアを使用すると、様々なOracleアプリケーション内のコンポーネント間、ノード間またはオブジェクト間の関連を表示できるようになります。選択詳細およびサマリー情報をズーム、パン、表示し、集計コンポーネントを評価できます。オブジェクト・タイプごとに異なるアイコンが使用され、すべてのアプリケーションに対して標準化されたビジュアル・インジケータが使用されます。
次のような様々な理由によって、システム・トポロジを作成する場合があります。
リレーションシップを視覚的にモデル化
障害原因の特定
高度な問題検出を目的としたビジュアル分析の実行
システム・トポロジを作成する場合、システムのコンポーネント間の関連を指定し、これらの間の接続または相互作用を論理的に示します。たとえば、関連付けを定義し、データベースとリスナー間の関連を示すことができます。コンポーネントはアイコンとして表され、関連付けはコンポーネント間の矢印リンクとして記述されます。ニーズに合うようにトポロジをカスタマイズした後は、該当するシステムの「トポロジ」ページにアクセスし、コンポーネントの全体的なステータスを表示できます。
|
関連項目: Enterprise Managerのオンライン・ヘルプの「システムの作成」の「トポロジ」ページに関するトピック |
サービスを監視すると、業務目標およびサービス・レベル目標を達成しやすくなります。サービスを監視するには、サービスのエンド・ユーザーによって通常アクセスされるアクティビティまたは機能をシミュレートするサービス・テストを定義します。たとえば、DNS、LDAPおよびIMAPなどの特定のプロトコルに基づいてサービスを測定する場合があります。様々な場所にいるユーザーに対するサービスの可用性およびレスポンスを能動的に監視するには、これらのサービス・テストを実行する地理的な場所を指定します。Enterprise Managerのビーコンを使用して特定の場所からサービス・テストを実行します。サービスのシステム・コンポーネントの使用状況に基づいてサービスを測定することもできます。
Grid Controlでは、サービス・レベルは、サービスが特定の可用性、パフォーマンスおよびビジネス基準を満たす時間の営業時間に対する割合として定義されます。管理者は、サービス・ダッシュボードを使用して、サービス・レベルがビジネス上の期待と目標に沿っているかどうかを確認できます。
管理者は、サービス・ダッシュボードを使用して、中央からサービス・レベル関連のすべての情報を参照できます。サービス・ダッシュボードには、各サービスの可用性ステータス、パフォーマンスおよび使用状況データ、サービス・レベルの統計が表示されます。問題の根本原因にドリルダウンすることや、失敗したコンポーネントがサービス自体に及ぼす影響を確認できます。
サービス・ダッシュボードには、次のような詳細が表示されます。
可用性: エンド・ユーザーがある時点においてサービスにアクセスできるかどうかを示す基準です。通常、サービス・レベル契約によって、少なくとも最小限の比率の時間にサービスが使用可能であることが求められます。
パフォーマンス: レスポンス時間は、エンド・ユーザーがサービスにアクセスするときに体感するパフォーマンスを測る上で適しています。サービスのパフォーマンスが低い場合、サービスの可用性に影響する可能性があります。
使用状況: エージェントによるサービスの使用状況またはユーザー・アクティビティのレベルを示します。
ビジネス: ビジネス・メトリックは、組織におけるビジネスのパフォーマンスを測定します。ビジネス・メトリックは、1つ以上のキー・ビジネス・インジケータがサービスに関連付けられている場合にのみ、表示されます。サービス・レベルは、特定のビジネス・メトリックに対してクリティカル・アラートが生成されると、影響を受けます。
該当するシステムの「トポロジ」ページを使用し、システムのコンポーネント間の依存関係を表示できます。トポロジ・ビューから詳細ページにドリルダウンし、キー・コンポーネント、アラートおよびポリシー違反、考えられる根本原因、影響を受けるサービスなどに関する情報を取得できます。
図8-3に示すように、作成したシステムの「トポロジ」ページを使用し、システムのコンポーネントのステータスの一覧を表示します。各アイコンのステータス・インジケータを使用して、停止しているコンポーネントまたはオープン・アラートがあるコンポーネントを速やかに評価できます。このページから、キー・コンポーネントに関する詳細情報を取得できます。
図8-4に示すように、該当するサービスの「トポロジ」ページを使用し、サービス、システム・コンポーネント、および可用性を定義するその他のサービスの間にある依存関係を表示します。サービスが失敗したときは、根本原因分析によって特定された潜在的な原因がトポロジ・ビューでハイライト表示されます。トポロジでは、サービスとシステムの間の依存関係を表示できます。
データ・センターによっては、1つのアプリケーションまたはサービスに特化したシステムを持つものや、複数のサービスをホストする共有システムを持つものがあります。Grid Controlでは、データ・センターの設定に応じて1つまたは複数のサービスをシステムに関連付けできます。
図8-4 Collaboration Suiteサービスの該当するサービスの「トポロジ」ページ
Enterprise Managerには、サービスおよびWebアプリケーションを監視する上で役に立つ即時利用可能なレポートが用意されています。また、レポートに公開オプションを設定することにより、指定した時間帯に電子メールを介してレポートを送信できます。生成可能なレポートには、Webアプリケーションのアラート、Webアプリケーションのトランザクション・パフォーマンスの詳細、サービス・ステータスのサマリーがあります。
Grid Controlを使用し、サービスを監視してユーザーが影響を受ける前に問題に能動的に対処できます。各サービス定義にはパフォーマンスおよび使用状況メトリックがあり、これらのメトリックには対応するクリティカルしきい値および警告しきい値があります。しきい値に達すると、Grid Controlによってアラートが表示されます。通知ルールの標準セットが用意されており、通知を適切な管理者に送信するためのアラート条件を指定できます。ルールの標準セットとは別に、特定のアラート条件を満たしたときに管理者に通知するスケジュールを定義および設定できます。たとえば、システムが停止した場合、エンド・ユーザーがアプリケーションにログインできない場合、オンライン・トランザクションを正常に完了できない場合などにアラートが生成されるようにしきい値を定義できます。
一定期間のベースラインを設定し、これらのベースラインを使用してパフォーマンスを評価できます。特定のターゲット・メトリックのベースライン期間全体の統計が計算されます。これらの統計を使用して、アラートのメトリックしきい値を自動的に設定することや、サービス・パフォーマンスのグラフ表示を正規化できます。
Grid Controlでは、過去および現在のパフォーマンスと使用状況の傾向がパフォーマンスおよび使用状況グラフに表示されます。当日（24時間）、7日間または31日間のメトリック・データを表示できます。また、グラフには、選択した期間に生成されたパフォーマンスまたは使用状況アラートのしきい値も表示されます。これによって、一定期間にわたってサービス・テストのパフォーマンスおよび使用状況を簡単に追跡し、サービス障害の原因を調査できます。ユーザーは、サービスのホームページのデフォルトのグラフを選択できます。「グラフ」ページには、すべてのパフォーマンスおよび使用状況グラフが表示されます。
「テスト・パフォーマンス」ページを使用し、各ビーコンからサービス・テストの過去および現在のパフォーマンスを表示します。このサービスのサービス・テストが定義されている場合、このサービス・テストの実行結果であるレスポンス時間測定値をサービスのパフォーマンス・メトリックのベースとして使用できます。サービスへのアクセスに複数の手順がある場合、またはサービスに複数のビジネス機能が用意されている場合、レスポンス時間測定を複数回実行できます。また、下位で動作するシステム・コンポーネントのパフォーマンス・メトリックを使用し、サービスのパフォーマンスを測定することもできます。
サービスのパフォーマンスが低い場合、サービスの使用率が高いことが原因である可能性があります。サービスの使用状況を監視すると、システム・コンポーネントの使用率が高いことがサービスに影響を与えているかどうかがわかるため、パフォーマンスの低さの診断に役立ちます。
今日のE-Businessは、重要なビジネス・プロセスをオンラインで実行するためにWebアプリケーションに大きく依存しています。情報へのアクセスを素早く、リモートで、正確に行うことが重要になるにつれ、オンラインの顧客が、正確にトランザクションを実行できることをどのように保証すればよいのでしょうか。販売員が、現場で必要な情報に効率的にアクセスできているという確信はありますか。
Webアプリケーション管理機能は、Enterprise Managerの従来のターゲット監視機能を補完するものです。Enterprise Managerのターゲット監視機能との完全な統合により、バックエンド・データベースと中間層アプリケーション・サーバーを含む、アプリケーションのテクノロジ環境を構成するコンポーネントのパフォーマンスと可用性を監視できます。
Grid Controlでは、Webアプリケーション・サービスを定義し、Webトランザクションを監視できます。これによって、E-Buinessシステムをトップダウンで能動的に監視したり、Webサイトでのエンド・ユーザーの操作を追跡できます。サービス・ダッシュボード、トポロジ・ビューア、グラフおよびレポートなどを介してWebアプリケーション・サービスを監視できます。これらの機能の詳細は、この章の「サービスの監視」を参照してください。
また、エンド・ユーザーのパフォーマンスのレスポンス時間を監視することによって、効率的にE-Businessシステムを管理し、アプリケーションのサービス・レベルの問題によって影響が発生していることを知ることができます。
トランザクションをサービス・テストとして、Webアプリケーションのパフォーマンスと可用性をテストするために使用できます。Webアプリケーションの重要なビジネス活動はトランザクションとして記録されます。トランザクションを使用し、Webアプリケーションのパフォーマンスと可用性をテストできます。少なくとも1回のビーコンによって正常に実行できた場合、トランザクションは使用可能だと認められます。一連のユーザー・アクションおよびナビゲーション・パスを自動的に記録する使いやすい再生レコーダを使用してトランザクションを記録できます。
Oracle Real User Experience（RUEI）は、ネットワークからリクエストおよび生成された実際のユーザー通信量についてのレポート作成に使用できる強力なWebベース・ユーティリティです。このユーティリティは、ネットワーク・インフラストラクチャにおいて最も重要な箇所でのページおよびトランザクションのレスポンス時間を計測します。強力なセッション診断機能により、アプリケーション管理者およびIT技術スタッフは根本原因を分析できます。
このユーティリティでは、実際のユーザー体験に基づくサーバーおよびネットワーク時間の表示、重要なパフォーマンス・インジケータ（KPI）およびサービス・レベル契約（SLA）の監視、および定義された目標値に違反するインシデントに対するアラート通知のトリガーが可能です。
ページ内容、サイト・エラーおよびトランザクションの機能要件に対するチェック機能を実装できます。この情報に基づき、業務および技術面での運用状況を確認できます。RUEIで識別されるすべての項目の可用性、スループットおよび通信量に対してカスタム・アラートを設定できます。
RUEIには、実業務の担当者と技術担当者の両方に、有効な意思決定を下すために必要な情報を提供する強力なレポート・ライブラリが用意されています。また、権限を付与されたユーザーは、独自のレポートの作成または既存のレポートの修正を迅速に行えます。このレポートを使用すると、Webデータと直接やりとりし、Webアプリケーションの全体のステータスだけではなく、オンライン利用の動作の詳細も把握できます。これらのレポートを対話形式で表示したり、電子メールでレポートを受信したりできます。RUEIの動的なドリルダウン機能を使用すると、必要なレベルのWeb結果を迅速に表示できます。情報のソート、フィルタリングおよびエクスポートが可能です。さらに、すべてのデータを、時間、クライアントの場所、トランザクション、ユーザー名などの様々な幅広い基準で相互に関連付けることができます。セッション診断機能を使用すると、業務上の問題の根本原因を分析できます。セッション診断機能では、個々のセッションにアクセスし、そのセッション内のすべてのユーザーのアクティビティを確認できます。詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
Oracle Formsでは、一連の統合されたビルダーが提供され、アプリケーション開発者は、これを使用することで、高度なデータベース・フォームおよびビジネス・ロジックを最小限の労力で簡単に迅速に構築できます。Oracle Formsの強力な宣言型の機能により、開発者はデータベース定義から完全に機能するアプリケーションを、最小のコーディングで開発できます。
Formは特定の目的を持つUIウィジェットの集合です。通常、これは1つの独立したタスク（ユーザー・データのアクセスおよび表示など）を実行するために構築されます。Formsアプリケーションは、相互関連しあう一連のFormです。たとえば、Financialsは、DISPLAY_SALARY、EDIT_ACCOUNTおよびPRINT_TAX_ACCOUNTなどのFormを含むFormsアプリケーションです。
Enterprise ManagerのFormsアプリケーションのターゲットは、特定のFormsアプリケーションをモデル化および監視するために使用されます。各フローを単一のFormsトランザクションとして記録するFormsアプリケーションの特定のフローを定義、監視および再生できます。また、Formsアプリケーションを操作して、エンド・ユーザーが体験するレスポンス時間のデータを測定できます。Commit、Query、Runform、Callform、NewformおよびOpenformなどのForms操作について、合計レスポンス時間、サーバー時間およびデータベース時間を測定できます。
Formsトランザクションは、Formsを使用する場合に、単一のアプリケーション内に一連のユーザー・アクションで構成されます。Formsアクションを自動的に記録する使いやすい再生レコーダを使用して、複数のFormsトランザクションを記録できます。このトランザクションを定期的に監視して、トランザクションを再生する時に関連するメトリックを集めることができます。
エンドユーザー・パフォーマンス監視ユーティリティを使用して、レスポンスの速さに関する情報を表示し、アプリケーションのレスポンス時間を測定できます。Oracle Application Server Web CacheまたはOracle HTTP Server/Apache HTTP Serverとともに構成する場合、エンドユーザー・パフォーマンス監視機能により、エンド・ユーザーが実際にFormsアプリケーションにアクセスし、一連のFormsアクションを実行することによって生成されたレスポンス時間のデータが表示されます。
Formsアプリケーションにアクセスすると、エンドユーザー・パフォーマンス監視ユーティリティティにより、Commit、Query、Runform、Callform、NewformおよびOpenformなどのFormsアクションのレスポンス時間が測定されます。Formsアクションを監視し、ユーザーが体験するレスポンス時間に基づいたレポートを表示できます。また、監視する必要がある最も重要なFormsアクションの監視リストを設定し、これらの重要な操作のレスポンス・メトリックを一目で確認できます。
Enterprise Manager Grid Controlには、サービスの問題を診断するためのツールとして、根本原因分析、トポロジ・ビューアおよびWebアプリケーション診断などがあります。サービスが使用できない、またはパフォーマンスが低い場合、これらのツールを使用して原因の候補を洗い出します。
サービスが失敗すると、根本原因分析によって、該当のサービスのホームページに原因の候補リストが戻されます。根本原因の候補としては、サブサービスの失敗と、キー・システム・コンポーネントの失敗があります。
デフォルトでは、根本原因分析によって、キー・コンポーネントの可用性ステータスが評価され、これがサービスの失敗の原因であるかどうかか判断されます。根本原因分析による検討の対象として、追加条件またはコンポーネント・テストを指定できます。キー・コンポーネントを使用できない場合、またはコンポーネント・テストの条件が満たされていない場合、このコンポーネントがサービスの失敗の原因だと考えられます。
また、このキー・コンポーネントがあるホストに対して追加条件またはコンポーネント・ホストのテストを指定することもできます。根本原因分析によって、このキー・コンポーネントがサービスの失敗の原因だと特定された場合、コンポーネントのホストが分析され、このホストがこのコンポーネントの失敗、そしてこのサービスの失敗の原因である可能性があるかどうかが判定されます。
また、トポロジ・ビューアからも根本原因分析にアクセスできます。トポロジ・ビューアには、コンポーネント間の関係を示す階層レベルがグラフ表示されます。サービスとシステム・コンポーネント間の赤い線は、関連する失敗を示します。これらの赤い線を辿り、考えられる失敗の原因を探し出します。
Enterprise Manager Grid ControlをEMC SMARTSソリューションと統合することによって、根本原因分析のネットワーク障害を検出することもできます。ネットワークに問題が検出された場合、SMARTSネットワーク・アダプタを使用して、ネットワーク内のホストとIPアドレスに関連する根本原因分析情報を問い合せることができます。
