ヘッダーをスキップ
Oracle® Business Transaction Managementインストレーション・ガイド
12.1.0.7
E61980-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

8 モニターのインストール

この章では、Business Transaction Managementモニターのインストール方法について説明します。シングルトンのモニターおよびモニター・グループの両方のインストール手順を説明します。

シングルトンのモニターとは、オブザーバから直接監視結果を受け取るモニターの単一インスタンスです。モニター・グループとは、ロード・バランサの背後に配置されるレプリケートされたモニター・インスタンスのグループです。モニター・グループの場合、オブザーバは監視結果をロード・バランサに送り、ロード・バランサが監視結果をグループ内のモニターに配布します。

モニターが監視結果を受信できるオブザーバ数には、制限がありません。理論上は、単一のモニターをデプロイしてシステム内のすべてのオブザーバからの監視結果を処理することも可能です。ただし、システムによって生成される監視結果の速度やサイズが大きい場合、単一のモニターでは対応しきれない場合があります。そのような状況では、監視システムのパフォーマンスの低下や、監視データのロストにつながる可能性があります。

複数のモニターをデプロイすることによって、このような潜在的なボトルネックを排除することができます。監視のニーズに必要な数のモニターをデプロイできます。また、モニターは、シングルトン・モニター、モニター・グループまたはこの2つの組み合わせとしてデプロイできます。たとえば、各オブザーバに専用のモニターをデプロイすることも可能です。なお、オブザーバは監視結果を1つのシングルトン・モニターまたはモニター・グループのみに送信できます。シングルトン・モニターの処理より早く監視結果を生成するオブザーバがある場合は、そのオブザーバ向けにモニター・グループをデプロイする必要があります。

モニター・グループを使用することによって、監視システムが拡張できるのみでなく、耐障害性も高まります。モニター・グループには、オブザーバからモニターへメッセージをルーティングするためのTCPをサポートするサードパーティ製ロード・バランサが必要です。モニター・グループには、レプリケートされたモニターのインスタンス間でデータを共有するためのOracle 10gまたは11gデータベースへのアクセスも必要です。これは、他のBusiness Transaction Managementコンポーネントで使用しているデータベースと同じデータベースでも構いません。モニター・グループのレプリケートされたインスタンスをネットワークに広く分散させることはできますが、すべてこの同じデータベースにアクセスできる必要があります(モニター・グループ・データベースの詳細は、第5.4.1項「モニター・グループ・データベースの設定」を参照)。一般的なモニター・グループのデプロイメントを、次の図に示します。

図8-1 一般的なモニター・グループのデプロイメント

図8-1の説明が続きます
「図8-1 一般的なモニター・グループのデプロイメント」の説明

8.1 モニターのインストールの概要

この項では、モニターのインストールの際に実行する必要があるタスクの概要について説明します。以降の項で、このタスクの実行方法について詳しく説明します。システムが適切に構成されるように、手順は示されている順番で実行する必要があります。

  1. 必要に応じて、セキュリティを構成します(第4章「セキュリティの構成」を参照)。


    注意:

    セントラル・サーバーでアサーション秘密および暗号化鍵を構成した場合、モニターも同じアサーション秘密および暗号化鍵を使用するよう構成する必要があります。一方、セントラル・サーバーでデフォルトのセキュリティ構成を使用している場合、モニターでもデフォルトのセキュリティ構成を使用する必要があります(第4.3項「アサーション秘密および暗号化鍵の構成」を参照)。

  2. 以下を含む第5章で説明されているすべての前提条件および設定が満たされていることを確認します。

  3. 省略可能 – モニター用の永続記憶域ディレクトリを構成します。第7.2項で説明されているセントラル・サーバー用の手順と同じ手順を使用します。

  4. モニターのデプロイおよび登録を行います(第8.2項を参照)。

    1. セントラル・サーバーがインストール済で稼働中であることを確認します。

    2. アプリケーション・サーバーのデプロイメント・ツールを使用して、モニターを対象のアプリケーション・サーバーにデプロイします。

    3. registerMonitor CLIコマンドで、モニターを登録します。

  5. レプリケートされたモニターの場合のみ – モニター・グループを設定します(第8.3項を参照)。

    1. モニター・グループを作成します。

    2. モニターをモニター・グループに割り当てます。

  6. レプリケートされたモニターの場合のみ – ロード・バランサを構成します(第8.4項を参照)。

  7. オブザーバ通信ポリシーを適用します(第8.5項を参照)。

8.2 モニターのデプロイおよび登録

この項は、シングルトンおよびレプリケートされたモニターの両方に関係しています。このタスクは、すべてのインストール・シナリオで実行する必要があります。

  1. Business Transaction Managementのセントラル・サービスがインストール済で稼働中であることを確認します。

  2. アプリケーション・サーバーのデプロイメント・ツールを使用して、モニターをホストする各アプリケーション・サーバーにbtmMonitor.earデプロイメント・パッケージをインストールします。


    注意:

    1つのアプリケーション・サーバーに複数のモニターをデプロイしないでください。また、他のBusiness Transaction Managementセントラル・サービスをホストしているアプリケーション・サーバーにモニターをデプロイしないでください。

    (Business Transaction Managementコンソールやその他のドキュメントでは、アプリケーション・サーバーをコンテナと呼ぶこともあります。)

  3. モニターのデプロイを開始します。

  4. registerMonitor CLIコマンドを使用して、デプロイしたそれぞれのモニターを登録します。次に例を示します。

    btmcli registerMonitor -e http://my_monitor_host:8080/btmmonitor/agent/agent
                       -fn My_BTM_Monitor
                       -s http://localhost:8080/btmcentral/sphere
                       -l my_admin_username:my_admin_password

    表8-1 registerMonitor CLIコマンドのフラグ

    フラグ 説明

    -e | -endpointUrl

    必須です。

    登録するモニターのURLを指定します。次に例を示します。

    http://my_monitor_host:8080/btmmonitor/agent/agent

    ホスト名およびポート番号は、適切な値で置換します。URLは常にbtmmonitor/agent/agentで終わる必要があります。

    -fn | -friendlyName

    省略可。

    モニターのエンドポイントとして、わかりやすい名前を指定します。

    -s | -sphereUrl

    AP_SPHERE_URL環境変数が設定されている場合を除き、必須です。

    スフィアのURLを指定します。次に例を示します。

    http://mySphereHost:8080/btmcentral/sphere/

    ホスト名およびポート番号は、適切な値で置換します。URLは常にbtmcentral/sphere/で終わる必要があります。

    -l | -userLogin

    AP_USER_LOGIN環境変数が設定されている場合を除き、必須です。

    btmadminロールを持つユーザーの資格証明を、username:password形式で指定します

    encryptPassword CLIコマンドを使用してパスワードを暗号化することができます。次に例を示します。

    btmcli encryptPassword -password "myPassword"

    CLIコマンドの呼出し方法の詳細は、第15章にある「CLIの起動」を参照してください。CLIについてのその他の情報は、Business Transaction Managementオンライン・ヘルプを参照してください。

  5. すべてのモニターおよびシステム・サービスが正常に稼働していることを確認します。

8.3 モニター・グループの設定

この項は、レプリケートされたモニターのみに関係します。レプリケートされたモニターを使用する場合、このタスクを実行する必要があります。

  1. 次の手順に従い、モニター・グループを作成します。

    1. Business Transaction Managementコンソールで、「管理」→「システム・ポリシーの作成」→「モニター・エージェント・グループ」を選択します。

    2. モニター・グループの名前を入力します(「バージョン」および「ノート」フィールドに説明を入力することもできます)。

    3. データベースへの接続文字列を指定します。

      デフォルトの文字列を使用する場合は、中カッコ内のテキスト(および中カッコ自身)をデータベース向けの適切な値で置換します。このデータベースには、モニター・グループのすべてのメンバーがアクセスできる必要があります。モニター・グループ・データベースの詳細は、第5.4.1項「モニター・グループ・データベースの設定」を参照してください。

    4. データベースにアクセスするユーザー名およびパスワードを指定します。

    5. 「適用」をクリックします。

  2. モニターを、直前で作成したモニター・グループに割り当てます。


    注意:

    モニターがデフォルトのオブザーバ通信ポリシーを使用しない場合は、この項を継続する前に第8.5項「オブザーバ通信ポリシーの適用」を完了させる必要があります。これが必要になるシナリオは、同じマシン内で複数のモニターが実行されている場合です。この場合、異なるソケット・ポートでリスニングする必要があるため、別々のオブザーバ通信ポリシーが必要になります。

    1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

    2. メイン・エリアで、グループを割り当てるモニターを選択します。

    3. 「変更」→「プロファイルの編集: モニター・エージェント」を選択します。

    4. 「モニター・グループ」フィールドにモニター・グループの名前を入力します。

      この名前は、モニター・グループの登録に使用したモニター・グループ・ポリシーの「名前」フィールドの値と一致している必要があります。

    5. 「適用」をクリックします。

8.4 ロード・バランサの構成

この項は、レプリケートされたモニターのみに関係します。レプリケートされたモニターを使用する場合、このタスクを実行する必要があります。

  1. HTTP仮想サーバーおよびソケット仮想サーバーの両方を定義し、ロード・バランサをオブザーバと通信できるように構成します。

    ロード・バランサには、2つのオブザーバ通信チャネルが必要です。片方はHTTP仮想サーバーと呼ばれ、もう片方はソケット仮想サーバーと呼ばれます。

    • HTTP仮想サーバーは、管理目的で使用されます。たとえばオブザーバは、HTTP仮想サーバーを使用してレプリケートされたモニターのいずれかから構成を取得します。

    • オブザーバは監視結果データをソケット仮想サーバーに送信し、ロード・バランサはこのデータをレプリケートされたすべてのモニターに配布します。このようなデータを含むメッセージは、監視メッセージと呼ばれます。


      注意:

      レプリケートされたモニターは、Business Transaction Managementセントラル・サーバーおよびデータベースと、ロード・バランサ経由ではなく、直接通信します。

  2. ソケット仮想サーバーのIPアドレスおよびポートを書きとめます。

    オブザーバ通信ポリシーを構成する際に、この情報が必要になります(第8.5項を参照)。

  3. 監視メッセージをすべてのレプリケートされたモニターに配布するために、次の手順に従ってロード・バランサを構成します。

    1. ソケット仮想サーバー用のプールを作成します。

    2. モニターが監視結果を受信するポートを割り当てることによって、各モニターにプールを割り当てます。

  4. ソケット仮想サーバーのプールに割り当てるモニターのポート番号を書きとめます。

    オブザーバ通信ポリシーを構成する際に、この情報が必要になります(第8.5項を参照)。


    注意:

    すべてのモニターが同じポート番号でリスニングすることによって、オブザーバ通信ポリシーの構成は簡単になります。

  5. すべてのレプリケートされたモニターに管理メッセージを配布するために、次の手順に従ってロード・バランサを構成します。

    1. HTTP仮想サーバー用のプールを作成します。

    2. モニターのアプリケーション・サーバーがリスニングするポートを割り当てることによって、各モニターにプールを割り当てます。

  6. オブザーバをホストしているアプリケーション・サーバーで、AP_NANO_CONFIG_URL Javaシステム・プロパティまたはAmberPoint:NanoConfigUrl Windowsキー(プラットフォームによる)がロード・バランサのHTTP仮想サーバー経由でモニターのURLに設定されていることを確認します。

    たとえば、HTTP仮想サーバーのIPアドレスが10.147.46.152でポート番号が5072の場合、HTTP仮想サーバーを経由するモニターのURLは、次のようになります。

    http://10.147.46.152:5072/btmmonitor/agent/agent/

    このトピックの詳細は、第9章「オブザーバのインストールの概要」を参照してください。

8.5 オブザーバ通信ポリシーの適用

この項は、シングルトンおよびレプリケートされたモニターの両方に関係しています。すべてのモニターに、正しく構成されたオブザーバ通信ポリシーを確実に適用する必要があります。次の項で、このポリシーの構成および適用方法を説明します。

8.5.1 オブザーバ通信ポリシーについて

オブザーバ通信ポリシーは、オブザーバとモニターまたはモニター・グループ間の通信を設定します。デフォルトでは、このポリシーはモニターおよびオブザーバの両方を次のように構成します。

  • オブザーバからモニターへの通信チャネルの設定(セキュリティ設定を含む)

  • オブザーバ用ランタイム設定の構成(検出および監視されるコンポーネントの種類の選択を含む)

リリース12.1.0.4より前では、1つのモニターに1つのオブザーバ通信ポリシーのみを適用できました。つまり、同じモニターに関連付けられたすべてのオブザーバは、同じ構成を受信していました。オブザーバ構成の柔軟性向上のため、リリース12.1.0.4では1つのモニターに複数のオブザーバ通信ポリシーを適用でき、それぞれのポリシーを異なるオブザーバまたはオブザーバ・セットのターゲットにできるようになりました。

このようなシナリオでは、モニター構成を生成するソースとして1つのポリシーを指定します(これを、「モニター」ポリシーと呼びます)。その後、その他の各ポリシーをオブザーバ構成を生成するソースに指定します(これらを、「オブザーバ専用」ポリシーと呼びます)。

モニター・ポリシーはモニター構成に加えてオブザーバ構成も生成することに注意してください。この構成は、オブザーバ専用ポリシーと同様にオブザーバ・セットにターゲット指定することも、ターゲット指定しないままにすることもできます。ターゲット指定しない場合は、構成によってターゲット指定されていないオブザーバのデフォルトの構成となります。

希望する場合(個別にオブザーバのターゲット指定をする必要がない場合)は、以前のリリースと同様に、モニターおよびそれに関連付けられたすべてのオブザーバの構成に単一のポリシーを使用することもできます。このようなシナリオでは、特定のオブザーバを対象としない「モニター・ポリシー」を使用します。このポリシーはデフォルトのオブザーバ・ポリシーを生成します。特定のオブザーバを対象としていないので、モニターと関連付けられたすべてのオブザーバがこのデフォルトの構成を受信します。

8.5.2 オブザーバ通信ポリシーの適用手順

次の手順は、オブザーバ通信ポリシーの適用方法についての概要レベルでの説明です。この手順の後に、モニターおよびオブザーバに関係するポリシー・フィールドの構成方法の詳細を説明するサブ項目が続いています。

  1. モニターの構成に使用するオブザーバ通信ポリシーを開きます(これが「モニター」ポリシーです)。

    事前構成済のポリシーのいずれかを編集することも、新しいポリシーを作成することも可能です(事前構成済ポリシーの説明は、第8.5.4項「事前構成済のオブザーバ通信ポリシー」を参照)。

    • 事前構成済オブザーバ通信ポリシーを編集するには、次の手順に従います。

      ナビゲータで「管理」→「システム・ポリシー」を選択します。

      メイン・エリアで編集したい事前構成済ポリシーを選択します。

      「変更」→「定義の編集: My_Policy」を選択します。My_Policyはポリシーの名前です。

    • 新しいオブザーバ通信ポリシーを作成するには、次の手順に従います。

      「管理」→「システム・ポリシーの作成」→「オブザーバ通信」を選択します。


    注意:

    デフォルトで、「オブザーバ通信ポリシー - デフォルト」という名前の事前構成済ポリシーは、モニター構成の生成およびシステム内のすべてのモニターへの適用の両方を行います。可能な場合は、モニターの構成にこのデフォルトのポリシーを使用してください。モニターの構成に異なるポリシーを使用する場合は、最初にデフォルト・ポリシーを編集し、モニター構成を生成しないようにするか、構成するモニターに適用されないようにするか、どちらか(または両方)になっていることを確認する必要があります。モニターのターゲット指定は、1つのモニター構成でのみ可能です。

  2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを解除して、このポリシーをモニター構成を生成するソースに指定します。

  3. モニターに関係するポリシー・フィールドを構成します。

    手順の詳細は、第8.5.2.1項「オブザーバ通信ポリシーのモニター関連フィールドの構成」を参照してください。

  4. モニター・ポリシーによって生成されたオブザーバ構成をデフォルトのオブザーバ構成に使用するか、特定のオブザーバをターゲットにするかを決定します。


    注意:

    デフォルトでは、「オブザーバ通信ポリシー - デフォルト」という名前のポリシーがターゲット未指定のオブザーバ構成を生成し、これがシステム内のすべてのモニターに適用されます。つまり、デフォルトでは、このオブザーバ構成がシステム内のすべてのオブザーバのデフォルトの構成となります。オブザーバにデフォルトの構成が必要な場合は、このポリシーのオブザーバのターゲットを指定しないままにしてください。一方、デフォルトのオブザーバ構成が不要な場合は、このポリシーを編集してなんらかのオブザーバのターゲットとする必要があります。

  5. オブザーバに関するポリシー・フィールドを構成します。

    手順の詳細は、第8.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」を参照してください。

  6. 省略可能 - 追加のオブザーバのターゲットを指定します。

    1. 「オブザーバ専用」ポリシーとして使用するために、いずれかの事前構成済ポリシーを開くか新しいポリシーを作成します。

    2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを選択して、このポリシーをオブザーバ構成のみを生成するソースに指定します。

    3. モニター関連フィールドと、モニター・ポリシーの対応するフィールドの値が一致していることを確認します。

    4. オブザーバに関するポリシー・フィールドを構成します。

    手順の詳細は、第8.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」を参照してください。

8.5.2.1 オブザーバ通信ポリシーのモニター関連フィールドの構成

次の手順で、オブザーバ通信ポリシーのモニター関連のフィールドの構成方法について説明します。この手順では、第8.5.2項「オブザーバ通信ポリシーの適用手順」で説明されているように、編集するポリシーをすでに開いていることを仮定しています。

  1. この手順の実行方法は、モニターがシングルトンかレプリケートかによって異なります。

    シングルトン・モニターの場合は、次の手順に従います。

    1. 「通信パス」フィールドを「直接モニターへ」に設定します(これはデフォルトの設定です)。

    2. 「モニターのポート番号」フィールドに、モニターがリスニングするポート番号を指定します。

      これは、オブザーバが監視結果を送信し、モニターが監視結果を受信するポートです。この設定は、モニターおよびオブザーバの両方を構成します。


      注意:

      モニターのホスト名を指定する必要はありません。ホスト名は、AP_NANO_CONFIG_URL Javaシステム・プロパティまたはAmberPoint:NanoConfigUrl Windowsキーから取得されます。オブザーバをインストールするアプリケーション・サーバー上に、このシステム・プロパティまたはキーを設定します(第9.2項を参照)。

    レプリケートされたモニターの場合は、次の手順に従います。

    1. 「通信パス」フィールドを「ルーターからモニター・グループへ」に設定します。

    2. 「ルーターのIPアドレス」および「ルーターのポート番号」フィールドに、ロード・バランサのソケット仮想サーバーのIPアドレスおよびポート番号を指定します。

      この設定によって、オブザーバは監視結果をロード・バランサの受信アドレス(第8.4項で構成したロード・バランサのソケット仮想サーバー)に送信するよう構成されます。

    3. 「モニターのポート番号」フィールドに、モニターが監視結果を受け取るポート番号を指定します。

      この設定によって、モニターは指定されたポートでリスニングするよう構成されます。このポート番号は、第8.4項でロード・バランサのソケット仮想サーバーのプールで割り当てたモニター・ポート番号と一致する必要があります。


    注意:

    この後にモニター・グループのモニターを追加または削除する場合は、ロード・バランサを適切に再構成する必要があります。

  2. オブザーバからモニターへの監視メッセージの転送にセキュリティで保護された接続を使用する場合は、「SSLの有効化」チェック・ボックスを選択したままにし、次の手順に進みます(SSLはデフォルトで有効になっています)。

    一方、セキュリティで保護された接続を使用しない場合は、チェック・ボックスの選択を解除し、手順6に進みます。

    「SSLの有効化」チェック・ボックスが選択されている場合は、追加のフィールドが表示されます。

  3. SSLを有効化した場合は、「プロトコル」フィールドで接続プロトコルを指定します。

    TLS 1.0を使用する場合は、「TLSv1」を選択します。

    SSL 3.0を使用する場合は、「SSLv3」を選択します(「SSLv3」は.NETベースのオブザーバではサポートされていません。)。

    「いずれか」を選択すると、コンポーネントが実行時に最適なプロトコルを決定します。これがデフォルトの設定です。

  4. デフォルトでは、SSLが有効化されるとビルトインの事前構成済セキュリティ・ストアが使用されます。これらのビルトイン・セキュリティ・ストアを使用する場合は、サブ手順dに進みます。

    独自のセキュリティ・ストアを使用する場合は、「デフォルト・ストアの使用」チェック・ボックスの選択を解除し、以下のすべての手順を実行します(この場合、追加のフィールドが表示されます)。

    1. 次のように、モニターのキー・ストア情報を指定します。

      キー・ストアの場所 – キー・ストアの場所です。キー・ストア・ファイルがモニターのローカルにある場合は絶対パスで、HTTP GETでアクセスできる場所にある場合はHTTP(S) URLで指定します。

      キー・ストア・パスワード – キー・ストアにアクセスするためのパスワードです。

      キー・ストア・タイプ – JKS、JCEKS、PKCS12などのキー・ストアのタイプです。

      キー名 – 証明書および秘密鍵です。キーの別名または「CN=値, UID=値」などの形式の証明書の属性を指定できます。

      キー・パスワード – 証明書および秘密鍵にアクセスするパスワードです。指定されない場合、キー・ストアのパスワードが使用されます。

    2. モニターがJavaベースのオブザーバにトラスト・ストアを自動でディスパッチするようにしたい場合は、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスを選択します。

    3. 次のように、トラスト・ストア情報を指定します。

      トラスト・ストアの場所 – トラスト・ストアの場所です。キー・ストア・ファイルがオブザーバのローカル(自動ディスパッチを使用する場合はモニターのローカル)にある場合は絶対パスで、HTTP GETでアクセスできる場所にある場合はHTTP(S) URLで指定します。

      トラスト・ストア・パスワード – トラスト・ストアにアクセスするためのパスワードです。

      トラスト・ストア・タイプ – JKS、JCEKS、PKCS12などのトラスト・ストアのタイプです。

    4. .NETベースのオブザーバを使用している場合は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」の説明に従ってオブザーバをホストしているマシンに適切な証明書をデプロイしていることを確認します。

  5. SSLを有効にすると、モニターはオブザーバに対して自身を認証する必要があります。ただし、オブザーバがモニターに対して自身を認証するかどうかは、「オブザーバ認証」フィールドの設定によります。次のいずれかの値でこのフィールドの設定を調整します。

    接続認証の使用 – これはデフォルト値で、接続を確立するたびにオブザーバはモニターに対して自身を認証する必要があります。

    なし – オブザーバ認証をオフにします。

    メッセージ認証の使用 – モニターにメッセージを送信するたびにオブザーバは自身を認証する必要があります。なお、メッセージ認証を使用すると、大幅にパフォーマンスが低下する可能性があります。この設定は、必要な場合のみ使用してください。オブザーバが、(接続ごとではなく)メッセージごとのバランシングを行うロード・バランサで構成されているモニター・グループに対してメッセージを送信する場合、接続認証は使用できません。この場合は、このフィールドを「なし」または「メッセージ認証の使用」のどちらかに設定する必要があります。

  6. 「基準」セクションで、ポリシーが正しいモニターに適用されていることを確認します。

    「モニター・グループ」句を追加すると、ポリシーを特定のモニター・グループ内のすべてのモニターに適用できます。次に例を示します。

    周囲のテキストでmonitor_group_criteria.gifを説明しています。

    注意:

    モニターに適用できるモニター構成を生成するオブザーバ通信ポリシーは、1つのみです。モニター構成を生成するすべての他のオブザーバ通信ポリシーの「基準」セクションでは、このポリシーを適用するモニターを含めないようにするか、このポリシーを適用するモニターを明示的に除外する必要があります。

  7. 「適用」をクリックします。

詳細設定については、Business Transaction Managementオンライン・ヘルプを参照してください。

8.5.2.2 オブザーバ通信ポリシーのオブザーバ関連フィールドの構成

次の手順で、オブザーバ通信ポリシーのオブザーバ関連のフィールドの構成方法について説明します。この手順では、第8.5.2項「オブザーバ通信ポリシーの適用手順」で説明されているように、編集するポリシーをすでに開いていることを仮定しています。

  1. 「アクティブ・プローブ」セクションで、適切なプローブをアクティブ化または非アクティブ化して検出および監視するビジネス・コンポーネントのタイプを選択します。


    注意:

    プローブとは、特定のタイプのビジネス・コンポーネントの検出および監視を担当するオブザーバ内のコンポーネントです。ほとんどのタイプのオブザーバには、複数のプローブが含まれています。プローブの詳細は、第1.1項「アーキテクチャ」を参照してください。

    JAVAプローブは、ローカルのJava呼出しを監視します。これはほとんどの場合不要です。通常、大量のローカルJava呼出しが発生するので、邪魔になる可能性があるためです。JAVAプローブを使用するには、最初にデプロイおよび構成を行う必要があります。JAVAプローブのデプロイおよび構成の詳細は、My Oracle Support (support.oracle.com)でサービス・リクエストを入力してください。

    すでにRMIプローブが非アクティブ化されていない場合、ほとんどの状況でこのプローブを非アクティブ化する必要があります。ほとんどのアプリケーションは、JAX-RPC、JAX-WS、EJBおよびJMSのような高レベルAPIを通してRMIを使用しています。このような場合は、これらの高レベルコンポーネント用のプローブのみをアクティブ化することを推奨します。ただし、アプリケーションが直接RMI呼出しを行う場合は、RMIプローブをアクティブ化する必要があるかもしれません。

    パフォーマンスの点からも、その他の理由からも、インストールされていない明示的にプローブを非アクティブ化する必要はありません。アンインストールされたプローブは、元々アクティブ化されていません(プローブがインストールされるのは、プローブを含むオブザーバがインストールされる場合のみです)。プローブを非アクティブ化するのは、(1)プローブがインストールされ、かつ(2)プローブが監視するビジネス・コンポーネントのタイプを監視したくない場合のみです。さらに、いずれかのSOAプローブを非アクティブ化(またはアクティブ化)した場合、すべてのSOAプローブをまとめて非アクティブ化(またはアクティブ化)する必要があります。

    コンポーネント・タイプに関連付けられた検出メカニズムをアクティブ化/非アクティブ化するには、「検出の有効化」チェック・ボックスを選択/解除します。あるコンポーネント・タイプの検出がアクティブ化されると、次にメッセージまたは呼出しを受信したタイミングで、そのコンポーネントが検出され、管理コンソールに表示されます。

    あるコンポーネント・タイプを検出した際に即時に監視を開始する場合は、「検出時に監視」チェック・ボックスを選択にします。そのタイプのコンポーネントを監視しない場合は、チェック・ボックスの選択を解除します。


    注意:

    検出を有効にして監視は有効にせず、その後にポリシーを編集して監視を有効化した場合、検出済のコンポーネントの監視は開始されません。システムが監視するのは、監視を有効化した後に検出されたコンポーネントのみです。検出済のコンポーネントの監視の有効化の詳細は、オンライン・ヘルプのトピック「エンドポイントの監視の開始および終了」を参照してください。

  2. このポリシーでオブザーバのみを構成している場合、次の手順を実行します。

    1. 「通信チャネル」セクション(「オブザーバのみ対象の構成の生成」チェック・ボックスは除くが、「SSL構成」セクションのフィールドは含む)のすべてのフィールドを、モニターの構成に使用するポリシーと一致するように設定します。

    2. 「オブザーバのみ対象の構成の生成」チェック・ボックスを選択します。

  3. 特定のオブザーバのみにこのポリシーから生成された構成を受信させたい場合、次の手順を実行してターゲットをそのオブザーバに指定します。

    1. 「構成ラベル」や「オブザーバのベース・アドレス」フィールドで、ターゲットにするオブザーバを指定します(前述のフィールドや関連するフィールドの詳細は、第8.5.5.1項「オブザーバ構成ラベル」および第8.5.5.4項「オブザーバのターゲット指定フィールドについての参考情報」を参照)。

    2. ある「オブザーバ・ポリシー」で指定されたラベルおよびアドレスは、同じモニターに適用される他のポリシーで指定されていないことを確認します(詳細は、第8.5.5.2項「オブザーバ通信ポリシーの拒否」を参照)。

    3. 省略可能 – ターゲット指定するすべてのオブザーバがBusiness Transaction Managementに認識されていることを保証するには、「アドレスの検証」チェック・ボックスを選択します。

      認識されていないオブザーバをターゲットにしてこのフィールドを選択した場合、ポリシーは拒否されます。現在は認識されていないが、今後認識されるオブザーバをターゲットとする場合は、このフィールドの選択を解除する必要があります。

    4. 省略可能 – (複数のモニターにポリシーを適用する場合は、このチェック・ボックスを選択しないでください。)ターゲットとするすべてのオブザーバがポリシーを適用するモニターと関連付けられているかどうかを検証するには、「モニターに施行」フィールドを選択します。

  4. 「基準」セクションで、ポリシーが適切なモニターに適用されていることを確認します。

    このポリシーでオブザーバのみを構成している場合、これらの設定はモニターの構成に使用するポリシーの設定と一致している必要があります。

  5. 「適用」をクリックします。

詳細設定については、Business Transaction Managementオンライン・ヘルプを参照してください。

8.5.3 適用する必要があるオブザーバ通信ポリシーの数

「オブザーバ通信ポリシー - デフォルト」という名前の事前構成済オブザーバ通信ポリシーは、モニターおよびオブザーバの両方の構成を生成し、デフォルトでBusiness Transaction Managementスフィアのすべてのモニターに適用されます。これは、デフォルトでは、すべてのモニターおよびオブザーバがこの単一のポリシーによって構成されることを意味します。単純なデプロイメント・トポグラフィや監視ニーズを満たすには、必要に応じてこのデフォルトのポリシーを単に編集します。複雑なデプロイメント・トポグラフィや監視ニーズに対応するためには、追加のポリシーを適用してモニターおよびオブザーバを他と異なる構成にしなければならない可能性もあります。

ご使用の環境で次のすべての点が該当する場合、オブザーバ通信ポリシーは1つのみ必要であるため、単純にデフォルトのポリシーを編集することができます。

  • すべてのモニターがシングルトンまたは単一のロード・バランサの後にあるレプリケートされたモニターである。シングルトンとレプリケートされたモニターが混在する場合や、複数のロード・バランサを使用する場合は、単一のポリシーは使用できません。

  • すべてのモニターが同じポート番号で監視結果を受信する。

  • モニターが監視結果をSSLで受信する場合、すべてのモニターが同じ秘密鍵や証明書を使用し、セキュリティ・ストアがすべてのモニターおよびオブザーバにとって同じ相対位置にある。

  • すべてのオブザーバが同じコンポーネント監視能力を持つように構成される(同じプローブが有効になっている)。

  • 一部のモニターおよびオブザーバに対して詳細設定を編集する必要がない。ほとんどの場合、詳細設定はデフォルトのままで構いません。

次の各シナリオでは、追加のオブザーバ通信ポリシーの適用が必要となります。

  • モニターが監視結果を異なるポート番号で受信する。この場合、各ポート番号に対して別々のポリシーを適用する必要があります。

  • モニターが複数のロード・バランサの後にレプリケートされている。この場合、各ロード・バランサに対して別々のポリシーを適用する必要があります。また、異なるポート番号で(ロード・バランサからの)監視結果を受信するように個々のモニターを構成する場合、ロード・バランサごとに各ポート番号に対する別々のポリシーを適用する必要があります。

  • シングルトンおよびレプリケートされたモニターが混在している。この場合、シングルトン・モニターに対してはポート番号ごとに1つのポリシーを適用し、レプリケートされたモニターに対してはポート番号とロード・バランサごとに1つのポリシーを適用する必要があります。

  • モニターはSSLで監視結果を受信するが、すべてのモニターが同じ秘密鍵と証明書のペアを使用しない。この場合、各秘密鍵と証明書のペアに対して別々のポリシーを適用する必要があります。

  • モニターはSSLで監視結果を受信するが、キー・ストアの場所がモニターによって異なるか、トラスト・ストアの場所がオブザーバによって異なる。この場合、各場所に対して別々のポリシーを適用する必要があります。

  • オブザーバによって必要なコンポーネント監視能力が異なる。たとえば、あるオブザーバはOSBプローブをアクティブ化し、SOAプローブを非アクティブ化する必要がある。一方、他のオブザーバはSOAプローブをアクティブ化し、OSBプローブを非アクティブ化する必要がある。この場合、オブザーバが必要とするアクティブ化するプローブの各組合せに対して別々のポリシーを適用する必要があります。

  • 一部のモニターまたはオブザーバに対して詳細設定を編集する必要がある。この場合、詳細設定の組合せごとに別々のポリシーが必要です。

8.5.4 事前構成済オブザーバ通信ポリシー

Business Transaction Managementでは、特定の種類のアプリケーションの監視用に事前構成された多くのオブザーバ通信ポリシーが提供されています。これらのポリシーは、監視ニーズに合うよう編集することができます。各ポリシーの名前は太字で表示され、後に説明も表示されます。

  • オブザーバ通信ポリシー - デフォルト

    このポリシーは、モニター構成および未ターゲット(デフォルト)のオブザーバ構成の両方を生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、異なるポリシーによって個別にターゲット指定されていないすべての関連するオブザーバに配布されます。

  • オブザーバ通信ポリシー - Fusionアプリケーション

    このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_FAPPSラベルでタグ付けされているオブザーバが対象です。Oracle Fusion Applicationコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

  • オブザーバ通信ポリシー - JavaEE

    このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_JAVAEEラベルでタグ付けされているオブザーバが対象です。JavaEEコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

  • オブザーバ通信ポリシー - OSB

    このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_OSBラベルでタグ付けされているオブザーバが対象です。Oracle Service Busコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

  • オブザーバ通信ポリシー - SOA

    このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、CONFIG_LABEL_SOAラベルでタグ付けされているオブザーバが対象です。Oracle SOAコンポーネントを監視するために、この構成によってプローブがアクティブ化され、オブザーバ・ランタイム設定が調整されます。

8.5.5 オブザーバのターゲット指定についての参考情報

以下のサブ項目は、オブザーバのターゲット指定に関する背景および参考情報です。

8.5.5.1 オブザーバ構成ラベル

オブザーバ構成ラベルとは、オブザーバを概念的に区別するための単純なテキスト文字列(たとえば、CONFIG_LABEL_MY_OBSERVERS)です。ラベルまたはオブザーバがデプロイされているアプリケーション・サーバーのアドレス(たとえば、http://my_host.com:7011)を指定することによって、オブザーバのターゲットを指定できます。指定できるラベルやアドレスの数に制限はありません。また、1つのポリシーでターゲット指定できるオブザーバの数にも制限はありません。


注意:

ラベルがサポートされるのは、Javaプラットフォームのみです。.NETにデプロイされているオブザーバのターゲットを指定する場合は、アドレスを使用する必要があります。

ラベルを使用すると、オブザーバを構成目的で物理的にではなく論理的にグループ分けすることができます。ラベルの適用には、任意の順番で実行できる次の2段階の手順が必要です。

  • オブザーバをホストしているアプリケーション・サーバーで、ap.nano.config.labelという名前のシステム・プロパティを作成し、その値にラベル文字列を設定します(このタスクの説明は、アプリケーション・サーバーへのオブザーバ・ライブラリのインストール手順にあります)。

  • オブザーバの構成に使用するオブザーバ通信ポリシーの「構成ラベル」フィールドに、ap.nano.config.labelと同じ値を設定します(このタスクの説明は、第8.5.2.2項「オブザーバ通信ポリシーのオブザーバ関連フィールドの構成」にあります)。

8.5.5.2 オブザーバ通信ポリシーの拒否

オブザーバのターゲット指定では、様々な状況でオブザーバ通信ポリシーが意図せず拒否される場合があります。次のシナリオでは、ポリシーが拒否されます。

  • 同じモニターに複数のターゲット未指定のポリシー(デフォルトのオブザーバ構成)を適用しようとした

  • 同じモニターに適用される2つの異なるポリシーに同じオブザーバ構成ラベルを指定しようとした

  • 同じモニターに適用される2つの異なるポリシーに同じオブザーバ・ベース・アドレスを指定しようとした

ラベルは、ポリシーが適用されるモニターにスコープ指定されています。つまり、ポリシーが異なるモニターに適用される場合は特定のラベル名を複数のポリシーで再利用できますが、同じモニターに適用される複数のポリシーではラベル名の再利用はできません。このスコープの原理は、ターゲット未指定のポリシーにも関係します。

ポリシーが拒否された場合は、コンソールの作業領域でポリシーを選択し、「ターゲット」タブを表示します。このタブに、ポリシーの拒否理由が示されています。

8.5.5.3 優先順位

オブザーバがどの構成を受信するかを決定する優先順位は、次のとおりです。

  1. オブザーバ・ベース・アドレス

    あるポリシーにオブザーバのベース・アドレスが指定されている場合、そのオブザーバはそのポリシーから生成された構成を受信します。

  2. オブザーバ構成ラベル

    あるポリシーにオブザーバの構成ラベルが指定され、そのオブザーバのベース・アドレスが指定されているポリシーがない場合、そのオブザーバは構成ラベルを指定したポリシーから生成された構成を受信します。

  3. ターゲット未指定のポリシー

    ターゲット未指定のポリシーがあり、オブザーバのベース・アドレスや構成ラベルを指定しているポリシーがない場合、そのオブザーバはターゲット未指定のポリシーから生成された構成を受信します。

8.5.5.4 オブザーバのターゲット指定フィールドについての参考情報

フィールド名(太字はセクション名) 説明
オブザーバのみ対象の構成の生成 このポリシーでモニターおよびオブザーバの両方の構成を生成したい場合は、このチェック・ボックスを選択しないでください。そのようなポリシーは、モニターに1つのみ適用できます。モニターに追加のポリシーを適用する場合は、このチェック・ボックスを選択する必要があります。チェック・ボックスを選択すると、ポリシーはオブザーバ構成のみを生成します。チェック・ボックスが選択されている場合でも、ポリシーの「通信チャネル」セクション内の他のすべてのフィールドの値を指定する必要があり、それらの値は同じモニターに適用される他のすべてのポリシーと一致している必要があります。
対象のオブザーバ ---------- これはセクションのラベルです ----------

このセクションでは、このポリシーから生成されるオブザーバ構成を受信するオブザーバを指定します。
対象の指定オブザーバ このポリシーから生成されるオブザーバ構成で特定のオブザーバのみを構成する場合、このチェック・ボックスを選択します。このチェック・ボックスを選択すると、どのオブザーバが構成を受信するべきかを指定する追加のフィールドが表示されます。この追加フィールドで、アドレスやラベルを使用してオブザーバのターゲットを指定します。

このチェック・ボックスを選択しない場合、ポリシーはターゲット未指定となり、ポリシーが適用されるモニターに関連付けられたすべてのオブザーバ向けのデフォルトの構成を生成します。関連付けられたオブザーバがいずれかのポリシーによってターゲット指定されていない場合、デフォルトの構成を受信します。モニターに適用できるターゲット未指定のポリシーは1つのみです。モニターに2つ目のターゲット未指定のポリシーを適用しようとすると、ポリシーは拒否されます。

注意: オブザーバのターゲットは、アドレスとラベルという2つの異なるメカニズムで指定できます。ただし、ある特定のオブザーバに対して同じメカニズムでターゲットを指定できるのは、1つのポリシーのみです。たとえば、ポリシーAがラベルでオブザーバのターゲットを指定する場合、ポリシーBはラベルで同じオブザーバのターゲットを指定することはできません。この場合、ポリシーBは拒否されます。ただし、ポリシーBはアドレスでそのオブザーバのターゲットを指定できます。この場合、アドレスはラベルより優先されるので、オブザーバはポリシーBからの構成を受信します。
構成ラベル 省略可能 – カンマ区切りでオブザーバ構成ラベルのリストを指定します。指定されたラベルのいずれかでタグ付けされたオブザーバが、このポリシーから生成される構成を受信します(別のポリシーがアドレスでオブザーバのターゲットを指定している場合を除く)。このフィールドにはテキストで入力します。大文字と小文字は区別されません。

注意: オブザーバをホストしているアプリケーション・サーバーのap.nano.config.labelという名前のシステム・プロパティによってオブザーバをタグ付けします。ラベルがサポートされるのは、Javaプラットフォームのみです。.NETにデプロイされているオブザーバのターゲットを指定する場合は、アドレスを使用する必要があります。
既知のアドレス ---------- これはセクションのラベルです ----------

省略可能 – このセクションでは、Business Management Transactionの既知のアドレスのドロップダウン・リストからオブザーバのアドレスを.選択できます。指定されたオブザーバが、このポリシーから生成される構成を受信します。
オブザーバのベース・アドレス このドロップダウン・リストから、オブザーバがデプロイされているコンテナのアドレスを選択します。
[オブザーバ・アドレスの追加] 「オブザーバのベース・アドレス」ドロップダウン・リストに追加するには、このリンクをクリックします。
任意のアドレス ---------- これはセクションのラベルです ----------

省略可能 – このセクションでは、テキスト・フィールドにオブザーバのアドレスを手動で入力できます。指定されたオブザーバが、このポリシーから生成される構成を受信します。
オブザーバのベース・アドレス このフィールドに、オブザーバがデプロイされているアプリケーション・サーバーのアドレスを手動で入力します。たとえば、http://my_host.com:7011のように入力します。
[オブザーバ・アドレスの追加] 「オブザーバのベース・アドレス」テキスト・フィールドに追加するには、このリンクをクリックします。
アドレスの検証 このポリシーによってターゲットを指定するすべてのオブザーバがBusiness Transaction Managementに認識されていることを保証するには、このチェック・ボックスを選択します。認識されていないオブザーバをターゲットにしてこのフィールドを選択した場合、ポリシーは拒否されます。

現在は認識されていないが、今後認識されるオブザーバをターゲットとする場合は、このフィールドの選択を解除する必要があります。
モニターに施行 ターゲット指定するすべてのオブザーバがポリシーを適用するモニターと関連付けられているかどうかを検証するには、このチェック・ボックスを選択します。

複数のモニターにポリシーを適用する場合は、このチェック・ボックスを選択しないでください。

8.6 モニター・グループ・メンバーの追加および削除

モニター・グループ内のレプリケートされたモニターは、メンバーと呼ばれます。モニター・グループの設定後に、メンバーを追加または削除しなければならないことがあるかもしれません。このような操作は自由に行うことができますが、この項で説明されている手順のとおりに実行する必要があります。

8.6.1 モニター・グループへのメンバーの追加

  1. 第8.2項「モニターのデプロイおよび登録」で説明されているように、追加したいモニターのデプロイおよび登録を行います。

  2. 第8.3項「モニター・グループの設定」で説明されているように、モニターをモニター・グループのメンバーに割り当てます。

  3. 第8.4項「ロード・バランサの構成」で説明されているように、モニターにロード・バランサのソケット仮想サーバー・プールを割り当てます。

8.6.2 モニター・グループからのメンバーの削除

  1. ロード・バランサのソケット仮想サーバー・プールからメンバーを削除します。

  2. 次の手順に従って、モニター・グループからメンバーを削除します。

    1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

    2. メイン・エリアで、モニター・グループから削除するメンバーを選択します。

    3. 「変更」→「プロファイルの編集: Your_Monitor」を選択します。Your_Monitorは削除するメンバーの名前です。

      プロファイルの編集ツールが開きます。

    4. 「モニター・グループ」フィールドからモニター・グループの名前を削除します。

    5. 「適用」をクリックします。

    6. モニターをモニター・グループのメンバーからは削除するが、Business Transaction Managementシステムの一部のままにしておく場合は、ここで終了します。モニターをシステムから完全に削除するには、以降の手順を実行します。

  3. アプリケーション・サーバーの管理ツールを使用して、モニターをアンデプロイします。

  4. 次の手順に従って、モニターを登録解除します。

    1. Business Transaction Managementコンソールのナビゲータで、「管理」→「モニター」を選択します。

    2. メイン・エリアでモニターを選択します。

    3. 「変更」→「Your_Monitor登録の削除」を選択します。Your_Monitorはモニターの名前です。

      モニター登録の削除ツールが開きます。

    4. 「削除」をクリックします。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引