サービスの構成

可用性定義 (汎用サービスおよび集計サービス)

サービスの可用性は、ユーザーがいつでもサービスを使用できるかどうかを示します。何をもって可用性とするかの基準は、アプリケーションによって異なります。たとえば、カスタマ・リレーションシップ・マネジメント(CRM)・アプリケーションでは、可用性はユーザーがアプリケーションに正常にログオンして売上レポートにアクセスできることを意味します。電子メール・アプリケーションの場合は、ユーザーがアプリケーションにアクセスして電子メールを送受信できることが可用性です。

可用性を定義するサービスをクリックし、「サービス・ホーム」ページにナビゲートします。「汎用サービス」メニューから、「管理」、「可用性」の順に選択します。サービスの可用性は、次のことに基づいて判別できます。

サービス・テスト: エンド・ユーザーの重要な機能の可用性によってサービスの可用性が決定される場合、このオプションを選択します。このような重要な機能の例として、電子メールへのアクセス、販売レポートの生成、オンライン銀行業務トランザクションの実行などがあります。サービス・テストを定義する場合、ビジネス・プロセスの重要な機能に最も適したプロトコルと、ユーザー・コミュニティの場所に適したビーコンの場所を選択します。

標準プロトコルを使用して1つ以上のサービス・テストを定義し、1つ以上のサービス・テストをキー・テストとして指定できます。キー・テストは、様々なユーザー・コミュニティ内で1つ以上のキー・ビーコンによって実行されます。また、「キー・サービス・テスト」チェック・ボックスを選択し、サービス・テストがキー・テストであると指示することもできます。サービスの可用性計算には、キー・サービス・テストのみが使用されます。次にビーコンを選択し、キー・テストの実行およびサービスの可用性判断に使用できます。定義に応じて、すべてのキー・サービス・テストが成功しているか、または1つ以上のキー・サービス・テストが成功している場合にサービスが利用可能とみなされます。ビーコンの詳細とその作成方法については、「ビーコンのデプロイおよび使用」を参照してください。

どの場合にサービスを利用可能とするべきかを指定できます。
- すべてのキー・サービス・テストが成功(デフォルト)このオプションをお薦めします。
- 1つ以上のキー・サービス・テストが成功
ノート:

サービス・テストは、1つ以上のキー・ビーコンによって実行できる場合に使用可能であるとみなされます。キー・ビーコンがない場合、サービス・テストのステータスは不明になります。
システム: サービスの可用性は、サービスをホストしている基盤のシステムまたは選択したシステム・コンポーネントに基づいている場合もあります。可用性が選択したシステム・コンポーネントに基づく場合、サービスの実行に対して重要なコンポーネントを選択し、サービスの可用性を決定するために使用するキー・コンポーネントとして1つ以上のコンポーネントを指定します。可用性の定義に応じて、1つ以上またはすべてのキー・コンポーネントが起動して実行されているかぎり、サービスは使用可能であると判断されます。

どの場合にサービスを利用可能とするべきかを指定できます。
- すべてのキー・コンポーネントが稼働中(デフォルト)
- 1つ以上のキー・コンポーネントが稼働中
また、1つ以上のコンポーネントを、サービスの可用性計算に使用されるキー・システム・コンポーネントとしてマークすることもできます。キー・システム・コンポーネントは、可能性のあるサービス失敗の根本原因特定で使用されます。詳細は、「根本原因分析の構成」を参照してください。
サブ・サービス: 集約サービスの場合、可用性は、サブ・サービスの可用性にも基づきます。すべてのサブサービスまたは単一のサブサービスの可用性に基づいて、可用性を判別するかを指定できます。

根本原因分析の構成

根本原因分析(RCA)を使用して、一連のイベントをフィルタ処理し、システム、サービスまたはアプリケーションのより高レベルな問題の原因を特定できます。RCAは、根本原因に見えるが、問題の実際の根本原因の副作用または兆候でしかない明らかなパフォーマンスの問題を排除するために役立ち、問題領域を簡単に識別できます。RCAの結果は、現在停止しているサービスのホームページまたは「トポロジ」ページ上から確認できます。トポロジ・ページでは、サービス、システムおよびコンポーネントの依存関係がグラフィカルに表示されます。トポロジ・ページでは、サービスの失敗の原因であるターゲットが強調表示されます。

RCAを実行する前に、次の内容を選択できます。

サービス失敗時に自動的に実行されるようにツールを構成します。
「分析モード」(デフォルト)を「手動」に変更してRCAを無効化します。
サービスのコンポーネント・テストおよび個々のテストのしきい値を定義します。

根本原因分析を構成するステップは、次のとおりです。

サービスのホームページで、「モニタリング構成」をクリックします。
「モニタリング構成」ページで、「根本原因分析の構成」をクリックします。
現在のモードが「自動」に設定されている場合は、「モードを手動に設定」をクリックしてRCAを無効化します。分析を手動で実行するように選択すると、サービスが停止状態の場合に「分析の実行」を選択して、いつでもサービスのホームページから分析を実行できます。現在のモードが「手動」に設定されている場合、サービスおよびそのコンポーネントの状態が変化した際に「モードを自動に設定」をクリックしてRCAを有効化します。
管理するキー・コンポーネント用の表の「コンポーネント・テスト」列のリンクをクリックします。これにより、コンポーネント・テスト・ページ上で、コンポーネント・テストの追加、削除または編集を行うことで、サービスのキー・コンポーネントを管理できます。サービスが停止したときは、キー・コンポーネントをドリルダウンして、根底にある問題を確認できます。コンポーネント・テストの定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

ノート:

RCAを無効化し、自動モードに設定を戻した場合、RCAにはこれまでの履歴結果は格納されず、今後、参照用としていずれの履歴も表示されません。

根本原因分析の最大限の活用

根本原因分析(RCA)は、サービスに関連する大量のデータをフィルタ処理し、サービスの可用性に影響する最も重要なイベントの発生を識別できることから、大きな価値をもたらします。Enterprise Managerで独自のサービスを構成する場合、RCAを最大活用することを考慮および計画して、サービスを定義することが重要です。

RCAを最大活用する上で最初に考慮が必要な項目は、他のサービスまたはシステム・コンポーネントに対してサービスが持つ一連の依存性です。タスクを達成するためにサービスが使用するすべてのシステム・コンポーネントを必ず識別してください。キー・コンポーネントを省略し、サービスが失敗した場合、RCAでは、そのコンポーネントを可能性のある原因として識別できなくなります。逆に、実際にはサービスが依存していないコンポーネントをサービス定義に含めると、RCAで、そのコンポーネントがサービス失敗の原因として誤って識別される場合があります。

サービス依存性を構築する場合、Enterprise Managerでサポートされている集約サービスの概念を利用することを念頭に置いてください。これにより、それぞれ独自の一連の依存性を持つ、より小さなサブサービスにサービスを分割できます。RCAはサブサービス(依存しているサービス)のステータスのみではなく、サブサービスが依存するシステム・コンポーネントまたはサービスも同様に考慮します。

RCAを最大限活用する上で次に考慮が必要な項目は、コンポーネント・テストの使用です。サービスが依存するシステム・コンポーネントを定義する際、これらのコンポーネントには、コンポーネント自体が失敗しなくても、サービス失敗となる部分が存在する場合があることを考慮します。コンポーネント・テストにより、ターゲット自体のステータスのみでなく、その主要部分のステータスもRCAでテストできます。

RCAシステムでは、キー・コンポーネントで使用可能なメトリックに基づくコンポーネント・テストを作成できます。これには、コンポーネント用に作成したメトリック拡張が含まれるため、サービスが失敗した場合は、そのコンポーネントの各部分をRCAによってきわめて柔軟にテストできます。RCAは2つのモードで実行するように構成できます。サービスの失敗に基づき自動的に実行されるか、手動で実行するように構成することができます。モニター対象のサービスの予想されるサービス・レベル合意のパーセントに基づいてモードを決定できます。予想されるサービス・レベル合意のパーセントが高い場合、自動モードを選択し、発生する可能性のあるエラーや失敗の根本原因を、容易に検知できるようにする必要があります。

システム・アソシエーション

システムとは、相互に機能することでアプリケーションをホスティングする、一連のインフラストラクチャ・コンポーネント(ホスト、データベース、アプリケーション・サーバーなど)を指します。たとえば、電子メール・アプリケーションはデータベース、リスナー、アプリケーション・サーバー、およびこれらのコンポーネントが常駐するホストによってホスティングされています。

サービスを定義すると、システム内のコンポーネント間の接続または相互関係を論理的に表すため、コンポーネント間の関連付けを指定できます。たとえば、関連付けを定義し、データベースとリスナー間の関連を示すことができます。これらの関連付けはシステムのトポロジ・ビューアに表示されます。一部のデータ・センターには、1つのアプリケーションまたはサービス専用のシステムがあります。その他のデータ・センターのシステムは複数のサービスをホスティングします。データ・センターのセットアップ方法に基づいて、1つまたは複数のサービスをシステムに関連付けできます。

このページでは、このサービスをホストするために使用するEnterprise Managerシステムを選択できます。次の操作を実行できます。

システムの追加または選択
選択したシステムの変更または削除

システムを選択してから、1つ以上のシステム・コンポーネントをキー・コンポーネントとしてマークします。このキー・コンポーネントは、サービスの実行に不可欠です。このキー・コンポーネントを使用して、サービスの可用性の判断や、サービスの障害の原因の識別を行います。

モニタリング設定

各サービスについて、頻度(アプリケーションに対してサービスがトリガーされる頻度を決定)およびパフォーマンスしきい値を定義できます。サービスがそのパフォーマンスしきい値を超えると、アラートが生成されます。

メトリックおよびしきい値を定義するには、「汎用サービス」メニューから、「管理」、「テストのモニタリング設定」の順に選択します。「メトリックとポリシー設定」ページが表示されます。「モニタリング設定」リンクをクリックします。「モニタリング設定 - しきい値」ページが表示されます。

表示方法 - メトリック、ビーコン - この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。サービスに追加される新しいビーコンは、デフォルトのしきい値を使用します。「メトリックの追加」をクリックして、1つ以上のメトリックを追加します。
表示方法 - ビーコン、メトリック - この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「表示」モード間の切替えができます。「編集」モードでは、メトリックのパラメータを変更できます。特定のビーコンのメトリックのパラメータを変更することもできます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。
- 表示方法: ステップ、メトリック、ビーコン: この表示で、「ビーコンのオーバーライドの追加」をクリックすると、1つ以上のビーコンのデフォルトのしきい値を上書きできます。この場合、上書きのないビーコンにのみデフォルトのしきい値が使用されます。「メトリックの追加」をクリックして、1つ以上のメトリックのしきい値を定義します。
- 表示方法: ステップ、ビーコン、メトリック: この表示で、「デフォルト」アイコンをクリックすると、特定のメトリックの「編集」および「ビュー」モード間の切替えができます。「編集」モードでは、特定のビーコンのメトリックのパラメータを変更できます。「表示」モードでは、メトリックのデフォルト・パラメータが使用されます。「データの粒度」プロパティの値が「ステップ」に設定されている場合のみ、インシデントが生成されます。

デフォルトの収集頻度および収集プロパティを定義するには、「モニタリング設定」ページの「収集の設定」タブをクリックします。次の操作を実行できます。

すべてのビーコンのデフォルトの収集頻度を指定します。特定のビーコンの収集頻度を上書きするには、「ビーコンのオーバーライドの追加」をクリックします。
1つ以上のビーコンの収集プロパティおよび対応する値を指定します。

収集間隔およびパフォーマンスしきい値の定義の詳細は、Enterprise Managerのオンライン・ヘルプを参照してください。

サービス・テストとビーコン

サービス・テストを追加し、これらのサービス・テストを実行する1つ以上のビーコンを指定できます。サービス・テストを追加、または既存のサービス・テストを変更するには、モニタリング構成ページの「サービス・テストとビーコン」リンクをクリックします。「サービス・テストとビーコン」ページが表示されます。ドロップダウン・リストからテスト・タイプを選択し、サービス・テストを作成できます。

追加のサービス・テストの定義

プロトコルおよびビーコンの場所に基づき、異なるタイプのサービス・テストを作成できます。「サービス・テストとビーコン」ページで、次のことを実行できます。

サービスに1つ以上のサービス・テストを追加します。テスト・タイプを選択し、「追加」をクリックします。定義可能なテスト・タイプには、ATS、FTP、、DNS、SOAPなどがあります。
サービス・テストを作成した後は、これを有効にする必要があります。サービス・テストが有効でない場合は、いずれのビーコンによっても実行されません。1つ以上のサービス・テストをキー・テストとして定義できます。これらのキー・テストは、サービスの可用性およびパフォーマンスのモニターに使用されます。有効なサービス・テストのみ、キー・テストとして指定できます。サービス・テストをキー・テストとして設定するには、ページの下部にある「可用性定義」リンクをクリックします。
ビーコンを作成、追加または削除します。ビーコンの場所を識別する場合、企業内のネットワーク、またはE-Businessに重要なインターネット上の場所を選択します。通常、これらはエンドユーザーが存在する場所です。たとえば、ビジネスがカナダでホストされ、顧客がアメリカ合衆国にいる場合、アメリカ合衆国のホスト・コンピュータにインストールされたビーコンを使用して、アプリケーションの可用性およびパフォーマンスを測定します。
サービス・テストの作成後、「サービス・テストの検証」をクリックして、検証します。「ステータス」アイコンは、サービス・テストのステータス(キー・ビーコンが正常に実行できるかどうか)を示します。サービスにキー・ビーコンが定義されていない場合、他のビーコンがサービス・テストを実行していてもステータスは不明になります。「ステータス」をクリックすると、ステータス履歴ページに移動します。
ノート:
- SOAP(シンプル・オブジェクト・アクセス・プロトコル)サービス・テストの定義中にアクセスするWSDL URLが企業のイントラネット外にある場合は、$OMS_HOME/sysman/config/emoms.propertiesファイルにプロキシ設定を追加する必要があります。
  
  たとえば、www-myproxy.myco.comをプロキシとして設定するには、次のように値を指定します。
  
  proxyHost=www-myproxy.myco.com
  
  proxyPort=80
  
  dontProxyFor=myco.com,mycorp.com
  
  proxyUser、proxyPwd、proxyRealmおよびproxyPropsEncryptedプロパティが、認証されたプロキシの構成に使用されます。プロキシ設定を変更した後、変更が適用されるようにするには、すべてのOMSを再起動する必要があります。
異なるタイプのサービス・テストの作成の詳細は、Enterprise Managerオンライン・ヘルプで説明しています。この章では、例としてATSテスト・タイプの作成について説明しています。

ビーコンのデプロイと使用

ビーコンは、管理エージェントがサービスをリモートでモニターできるターゲットです。ビーコンは、常に1つ以上のサービスをモニターできます。

ノート:

ビーコンを作成する前に、Oracle Beacon 12.1.0.2以上のプラグインがデプロイされていることを確認する必要があります。

1つ以上のサービス・テストを実行するビーコンを作成するには、次のステップに従います。

「ターゲット」メニューから「サービス」を選択し、「サービス」ページを表示します。
「サービス機能」メニューで、「ビーコン」を選択し、「作成」をクリックします。
ビーコンの作成ページが表示されます。
次の詳細を入力します:
- 名前: 作成するビーコンの名前です。
- エージェント: ビーコンが実行する管理エージェントを選択します。
- プロキシ情報: ビーコンがファイアウォールを介してサービスにアクセス中の場合は、プロキシ・サーバー設定を次のように指定する必要があります。
  - プロキシ・ホストおよびポート: ビーコンと通信を行うプロキシ・サーバーのホストの名前。
  - プロキシ認証レルム: プロキシ・サーバーで資格証明の検証(Basic認証スキームとDigest認証スキーム)に使用される認証レルム
  - プロキシ認証ユーザー名: プロキシ・サーバー認証に使用されるユーザー名(完全修飾名)
  - プロキシ認証パスワード: プロキシ・サーバー認証で一緒に使用されるパスワード
- メッセージIDのリクエスト・ヘッダーの有効化: HTTP Pingサービスのテストの実行時に発行されるHTTPリクエストに追加ヘッダーを含めるには、このチェック・ボックスを選択します。これにより、Real User Experience Insight (RUEI)は、HTTP Pingのテストをモニタリングできます。
「作成」をクリックして、ビーコンを作成し、「ビーコンのホームページ」に戻ります。これでビーコンを使用してサービス・テストをモニターできるようになりました。
「汎用サービス」メニューで、「管理」、「サービス・テストとビーコン」の順に選択します。ビーコンのリストと、有効化されたサービス・テストのリストが表示されます。
モニターするサービス・テストを選択し、「ビーコン」表から作成したビーコンを選択します。それがキー・ビーコンかどうかが示されます。
「サービス・テストの検証」をクリックして、選択したビーコンごとにサービス・テストを実行します。

ビーコンの構成

この項では、その他のビーコン関連の構成タスクについて説明します。

ビーコンのSSL証明書の構成: HTTPS URLを使用してSecure Sockets Layer(SSL)でURLをモニターする際にビーコンを使用する場合、そのURLが存在するWebサイトで使用されている認証局を認識するようにビーコンを構成する必要があります。

ポート・チェッカ・テストでSSLオプションを使用するには、管理エージェントのモニタリング・ウォレットに証明書を追加する必要がある場合があります。追加証明書を追加するには、次のステップを実行します。
1. Base64encoded X.509 (.CER)形式の、b64SiteCertificate.txtファイル内の証明書を取得します。(ファイル名は構成により異なる可能性があります)。ファイルの内容の例を次に示します。
```
------BEGIN CERTIFICATE--------------
MIIDBzCCAnCgAw...
...... base 64 certificate content .....
------END CERTIFICATE-----------------
```
  ファイルは管理エージェントのホーム・ディレクトリに<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txtファイルとして保存されています。
2. b64InternetCertificate.txtファイルが作成されていない場合は、エージェントのコア・ディレクトリとインスタンス・ディレクトリに作成します。
```
<AGENT_BASE>/agent_inst/sysman/config/b64InternetCertificate.txt 
<AGENT_BASE>/core/12.1.0.2.0/sysman/config/b64InternetCertificate.txt 
```
3. 両方のb64InternetCertificate.txtファイルの末尾に、Base64encoded X.509証明書を追加します。BEGIN行とEND CERTIFICATE行の両方を含めます。
4. 管理エージェントを再起動します。

専用ビーコンの構成: エージェントのビーコン機能には、内部Java VMを使用する必要があります。Java VMの使用により、エージェントの仮想メモリー・サイズを数100MB増加できます。メモリーの制約のため、専用ホスト上で稼働するエージェント上でのみ、ビーコンを作成することをお薦めします。所定のビーコンで多数のテスト(毎分数百回)を実行する場合は、専用ホスト上へのそのビーコンのエージェントのインストールもお薦めします。専用ハードウェアを最大限に利用するには、エージェントの$ORACLE_HOME/sysman/config/emd.propertiesファイルを次のように編集します。

applicationmetadataquota: 各アプリケーション領域に対するディスクの割当てバイト数
- ThreadPoolModel=LARGEプロパティを設定します。これにより、エージェントで多数のスレッドを同時に実行できるようになります。
- useAllCPUs=TRUEプロパティを設定します。これにより、複数のCPU上でエージェントを同時に実行できるようになります。
- applicationMetadataQuota_BEACONプロパティは、ATSのzipファイルを格納するために使用できる合計サイズを指定します。ATSのzipファイルを使用する場合、またはビーコンに小規模なATSのzipファイルを多数構成する必要がある場合、applicationMetadataQuota_BEACONプロパティには大きな値を指定する必要があります。
- @ このプロパティは、ビーコンが次のものの格納に使用できる合計サイズを指定します。
  
  @ ATS zipファイル。ユーザーが大規模なATS zipファイルを使用する予定の場合や、
  
  @ ビーコンに小規模なATS zipファイルを多数構成する必要がある場合は、このプロパティを
  
  @ 適宜増やす必要があります。
- agentJavaDefinesプロパティに-Xms512m -Xmx1024mを追加します。これにより、Java VMのヒープ・サイズを1024MBに増加できます。
ビーコンのWebプロキシの構成: ネットワーク構成によっては、Webプロキシが使用されるようにビーコンを構成する必要がある場合があります。ビーコンのWebプロキシを構成するには、「すべてのターゲット」ページでビーコンを検索します。構成するビーコンを選択し、「構成」をクリックします。Webプロキシのプロパティを入力します。たとえば、ビーコンのWebプロキシとしてwww-proxy.example.comを設定するには、次のように値を指定します。
```
Proxy Host: www-proxy.example.com
Proxy Port: 80
Don't use Proxy for: .example.com,.example1.com
```

パフォーマンス・メトリック

パフォーマンス・メトリックは、サービスのパフォーマンスの測定に使用されます。サービス・テストが、このサービスに対して定義されている場合、そのサービス・テストの実行の結果行われるレスポンス時間の測定値が、サービスのパフォーマンス・メトリックの基準として使用されます。もう1つの方法として、基礎となるシステム・コンポーネントからのパフォーマンス・メトリックを使用してサービスのパフォーマンスを判断できます。

パフォーマンス・メトリックは、各リモート・ビーコンに対してサービス・テストがどの程度適切に実行されているかの判別に役立ちます。一般に、ローカル・ビーコンは、Webアプリケーション・ホストに対してローカルなので、非常に有効で一貫したレスポンス時間を備えています。リモート・ビーコンは、アプリケーションのエンドユーザーの実際のレスポンス時間を反映したデータを提供します。

次の操作を実行できます。

サービス・テスト用のパフォーマンス・メトリックを追加できます。メトリックを選択後、次の内容を選択できます。

1つのビーコンからのメトリック値を使用します。サービスのパフォーマンスがある特定の場所のパフォーマンスに基づくようにする場合に、このオプションを選択します。

複数のビーコン間のメトリックを集計します。複数の場所のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、次の中から適切な集計関数を選択する必要があります。

表9-1 ビーコン集計関数

関数	説明
Maximum	すべてのビーコン間で集計されたデータからのメトリックの最大値が使用されます。すべてのビーコン間で最もパフォーマンスの低いものを測定するには、この関数を使用します。
Minimum	すべてのビーコン間で集計されたデータからのメトリックの最小値が使用されます。すべてのビーコン間で最もパフォーマンスの高いものを測定するには、この関数を使用します。
Average	メトリックの平均値が使用されます。すべてのビーコン間で平均的なパフォーマンスを測定する場合に、この関数を使用します。
Sum	メトリック値の合計が計算されます。各ビーコン間のすべてのレスポンス時間の合計を計算する場合に、この関数を使用します。

サービスをホストする基礎となるシステム・コンポーネントのパフォーマンス・メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

特定のコンポーネントからメトリックを使用します。サービスのパフォーマンスがある特定のシステム・コンポーネントのパフォーマンスに基づくようにする場合に、このオプションを選択します。このオプションを選択すると、「ルール・ベース・ターゲット・リスト」を選択できます。

複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間のパフォーマンスを考慮する場合に、このオプションを選択します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

表9-2 システム集計関数

関数	説明
Maximum	すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。
Minimum	すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。
Average	すべてのコンポーネント間のメトリックの平均値が使用されます。
Sum	すべてのコンポーネント間のメトリックの値の合計が計算されます。

ノート:

システムが削除されると、そのシステムに関連付けられているパフォーマンス・メトリックは収集されません。

定義済のパフォーマンス・メトリックを編集します。サービス・テストベースのパフォーマンス・メトリックの場合は、メトリック値の計算に使用されるビーコン関数を変更できます。システムベースのパフォーマンス・メトリックの場合は、ターゲット・タイプ、メトリック、および集計関数を使用するかどうかの設定を変更できます。また、メトリックのクリティカルしきい値および警告しきい値も変更できます。
定義済のパフォーマンス・メトリックを削除します。

ノート:

集約サービスにパフォーマンス・メトリックを定義すると、次の操作が可能です。

単一のサブ・サービスからのパフォーマンス・メトリックを追加します。
複数のメトリックの統計による集計を指定します。

メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。

ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

すべて(すべてのシステム・コンポーネント)
次を含む(指定された基準を含む任意のコンポーネント)
次で始まる(指定された基準で始まる任意のシステム・コンポーネント)
次で終わる(指定された基準で終わる任意のシステム・コンポーネント)
次と等しい(指定された基準に一致する任意のシステム・コンポーネント)

静的ベースのターゲット・リスト

この場合、選択される依存ターゲットがメトリック評価に参加し、選択されないターゲットは含まれません。

使用状況メトリック

使用状況メトリックは、サービスに対するユーザーの要求の測定に使用されます。使用状況メトリックは、サービスをホストする基礎となるシステム・コンポーネントの使用状況に基づいて収集されます。特定のコンポーネントの使用状況をモニターすることも、一連のコンポーネントの平均値、最小値および最大値を統計的に計算することも可能です。たとえば、IMAPサーバーに依存する電子メール・サービスを定義する場合、IMAPサーバーの「合計クライアント接続」メトリックを使用して、この電子メール・サービスの使用状況を表すことができます。使用状況メトリックは、システムと関連付けられたサービスに対してのみ定義できます。次の操作を実行できます。

使用状況メトリックを追加します。ターゲットのメトリックを選択後、次の内容を選択できます。

特定のコンポーネントからメトリックを使用します。特定のコンポーネントの使用状況をモニターする場合に、このオプションを使用します。

複数のコンポーネント間のメトリックを集計します。複数のコンポーネント間の使用状況の統計を計算する場合に、このオプションを使用します。このオプションを選択した場合、適切な集計関数を選択する必要があります。

表9-3 集計関数 - 使用状況メトリック

関数	説明
Maximum	すべてのコンポーネント間のメトリックの最大値が、サービスのパフォーマンス・メトリックの値として使用されます。
Minimum	すべてのコンポーネント間のメトリックの最小値が、サービスの使用状況メトリック値として使用されます。
Average	すべてのコンポーネント間のメトリックの平均値が使用されます。
Sum	すべてのコンポーネント間のメトリックの値の合計が計算されます。

定義済の使用状況メトリックを編集します。
定義済の使用状況メトリックを削除します。

システム・ターゲットからのメトリックのみを使用状況メトリックとして追加できることに注意してください。テストからのメトリックは使用状況を示さないため、使用状況メトリックとして追加できません。

ノート:

集約サービスに使用状況メトリックを定義すると、次の操作が可能です。

単一のサブ・サービスからの使用状況メトリックを追加します。
複数のメトリックの統計による集計を指定します。

使用状況メトリックを選択した後、インシデントのトリガーに使用されるしきい値を設定したり、必要がなくなったメトリックを削除できます。

ルール・ベース・ターゲット・リスト

ルール・ベース・ターゲット・リストは、システム・ベースのパフォーマンス・メトリックおよびシステムの直接メンバーに適用可能です。選択したシステム・コンポーネントを照合するルールを定義できます。これにより、評価のパフォーマンス・メトリックを促進できます。ユーザー指定のルールに一致するシステム・コンポーネントは、メトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で追加されると、このコンポーネントもメトリック評価プロセスに参加します。このルールに一致する任意のシステム・コンポーネントが後で削除されると、このコンポーネントは、メトリック評価プロセスに参加しません。定義するルールは次のものに基づきます。

すべて(すべてのシステム・コンポーネント)
次を含む(指定された基準を含む任意のコンポーネント)
次で始まる(指定された基準で始まる任意のシステム・コンポーネント)
次で終わる(指定された基準で終わる任意のシステム・コンポーネント)
次と等しい(指定された基準に一致する任意のシステム・コンポーネント)