| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
前 |
次 |
この章では、Business Transaction Managementの管理に役立つ情報を提供します。この章の内容は次のとおりです。
この項では、Business Transaction Managementオブザーバの管理に役立つ情報を提供します。この項の内容は次のとおりです。
オブザーバは、監視対象のビジネス・アプリケーションのアプリケーション・サーバーにインストールするBusiness Transaction Managementコンポーネントです。オブザーバは、ビジネス・アプリケーションのコンポーネント間のメッセージおよびコールを監視します。
オブザーバには、プローブと呼ばれる1つ以上のサブコンポーネントが含まれています。各プローブにより、特定のタイプのビジネス・コンポーネントを監視する機能がオブザーバに提供されます。このため、オブザーバの監視機能はオブザーバに含まれているプローブのコレクションによって異なります。
次の表に、Business Transaction Managementに用意されているオブザーバのタイプ、各オブザーバ内に含まれているプローブおよび各プローブによってオブザーバに提供される監視機能を示します。
表12-1 使用可能なオブザーバ、オブザーバに含まれているプローブおよびオブザーバが監視するコンポーネントのタイプ
| オブザーバ | プローブ | 監視対象のコンポーネント |
|---|---|---|
|
JavaEE |
EJB |
Enterprise JavaBean (EJB) |
|
- |
JAVA |
Java (ローカルJavaメソッド・コールを監視します) |
|
- |
JAXRPC |
JAX-RPC (JAX-RPC APIを使用するJMSトラフィックの監視が含まれています) |
|
- |
JAX-RS |
JAX-RS (RESTfulアプリケーションを監視します。JSR 339を参照) |
|
- |
JAXWS |
JAX-WS (JAX-WS APIを使用するJMSトラフィックの監視が含まれています) |
|
- |
JDBC |
JDBC (Javaデータベース・コールを監視します) |
|
- |
JMS |
JMS (JMS APIを使用するトラフィックを監視します) |
|
- |
RMI |
Remote Method Invocation(RMI) |
|
- |
WEB_APP |
Javaサーブレット・アプリケーション |
|
OSB |
OSB |
Oracle Service Busプロキシ・サービスおよびビジネス・サービス |
|
Oracle SOA Suite |
SOA_ADAPTER |
Oracle SOA Suite Adapter (このプローブは、Oracle Service Bus 10g用のオブザーバでのみ提供されます) |
|
- |
SOA_BIZRULE |
Oracle SOA Suite Business Rule |
|
- |
SOA_B2B |
SOA B2B (企業間) |
|
- |
SOA_BPEL |
Oracle SOA Suite Business Process Execution Language (BPEL) |
|
- |
SOA_BPMN |
Oracle SOA Suite Business Process Modelling Notation (BPMN) |
|
- |
SOA_CALLBACK |
非同期コールのコールバック・リクエスト |
|
- |
SOA_DIRECT |
SOAコンポジット間およびSOAとOSB間の直接バインディング・コール |
|
- |
SOA_EDN |
Oracle SOA Suite Event Delivery Network |
|
- |
SOA_JCA |
AQ、データベース、ファイル、FTP、JMS、MQ Series、ソケット、Oracle ApplicationsなどのJCAアダプタ |
|
- |
SOA_MEDIATOR |
Oracle SOA Suite Mediator |
|
- |
SOA_REST |
Oracle SOA Suite REST |
|
- |
SOA_SPRING |
Oracle SOA Suite Spring Bean |
|
- |
SOA_WORKFLOW |
Oracle SOAヒューマン・ワークフロー・コンポーネントおよび通知 |
|
- |
SOA_WS |
Oracle SOA Suite Webサービス(ヒューマン・ワークフローWebサービスなど) |
|
- |
SOA_WSA |
Oracle SOA Suite Webサービス・アダプタ |
|
- |
WEB_APP |
Javaサーブレット・アプリケーション |
|
Oracle Fusion Applications (ADF-UI、ADF-BCおよびSOAデプロイメントをサポートしています) |
ESS |
Oracle Enterprise Scheduling Service |
|
- |
JavaEEオブザーバにあるすべてのプローブ(JDBCプローブを除く) |
JavaEEオブザーバのエントリを参照 |
|
- |
SOA Suiteオブザーバにあるすべてのプローブ |
SOA Suiteオブザーバのエントリを参照 |
|
ユニバーサル |
JavaEE、OSB、Oracle SOA SuiteおよびOracle Fusion Applicationsオブザーバにあるすべてのプローブ |
JavaEE、OSB、Oracle SOA SuiteおよびOracle Fusion Applicationsオブザーバのエントリを参照 |
|
WCF |
WCF |
Microsoft WCFサービス |
|
Oracle Enterprise Gateway (OEG) |
OEG |
OEG Webサービス・プロキシが前にあるWebサービス |
|
注意: Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。 |
単一のオブザーバ・インストールでは、適切なプローブが含まれているかぎり、アプリケーション・サーバーで実行中の任意の数のコンポーネントを監視できます。
オブザーバは、モニターと呼ばれる別のBusiness Transaction Managementコンポーネント経由でBusiness Transaction Managementスフィアと通信します。モニターのジョブの1つは、構成をいくつかのオブザーバに配布することです。オブザーバは起動すると、モニターと通信し、構成を取得します。オブザーバは、構成の更新がないか定期的にモニターをポーリングします。
オブザーバ構成は、オブザーバ通信ポリシーから生成されます。デフォルトでは、事前構成済オブザーバ通信ポリシーがすべてのモニターに適用されます(このデフォルト・ポリシーの名前は「オブザーバ通信ポリシー - デフォルト」です)。このポリシーは、ポリシーの適用先のモニターを構成する他、それらのモニターにオブザーバ構成を提供します。オブザーバ構成は、デフォルトでは関連するすべてのオブザーバに分散されます。このデフォルト・ポリシーを編集したり、独自のポリシーを適用することができます。
オブザーバは実行されると、スループット、フォルト・カウント、レスポンス時間などビジネス・アプリケーションのメッセージやコール・フローの様々な側面を測定します(測定の完全なリストは、第6章「インスツルメントについて」を参照してください)。オブザーバは、次の図に示すように、分析およびデータベースへの最終的な保管のためにこれらの測定をモニターに定期的に送信します。
このように構成された場合、オブザーバはメッセージ・ロギングおよびさらなる分析という目的で様々なタイプのメッセージおよびコールを標準化されたXML形式のメッセージに変換します。オブザーバは、これらのメッセージをモニターに転送します。これらのメッセージはコピーであり、元のメッセージ/コールは変更されることもリダイレクトされることもありません。
オブザーバはビジネス・コンポーネントのアプリケーション・サーバーにインストールされ、クライアントはオブザーバがインストールされる前と同じように引き続きビジネス・コンポーネントにアクセスします。任意の数のモニター、およびモニターごとに任意の数の関連付けられたオブザーバをインストールできますが、Business Transaction Managementセントラル・サーバーまたはモニターをホストするアプリケーション・サーバーにオブザーバがインストールされることはありません。
Business Transaction Managementシステム全体の概要は、1.3項「アーキテクチャの概要」を参照してください。モニターのレプリケートによる監視システムのスケール・アップについては、『Business Transaction Managementインストレーション・ガイド』を参照してください。
オブザーバ通信ポリシーにより、オブザーバと1つのモニターまたはモニター・グループ間の通信が設定されます。デフォルトでは、このポリシーは次のようにモニターとオブザーバの両方を構成します。
オブザーバとモニター間の通信チャネルを設定します。
オブザーバのランタイム設定を構成します。
リリース12.1.0.4より前では、任意の1つのモニターに単一のオブザーバ通信ポリシーのみを適用できました。つまり、同じモニターに関連付けられたすべてのオブザーバは同じ構成を受信していました。オブザーバ構成の柔軟性を高めるため、リリース12.1.0.4では単一のモニターに複数のオブザーバ通信ポリシーを適用し、これらの各ポリシーをそれぞれ異なるオブザーバまたはオブザーバ・セットでターゲットにすることができるようになりました。このようなシナリオでは、1つのポリシーのみをモニターの構成に使用するポリシーとして指定し、残りのすべてのポリシーをオブザーバの構成にのみ使用するポリシーとして指定します。モニターを構成するポリシーは、必要に応じてオブザーバの構成にも使用できます。このトピックの詳細は、12.1.2.7項「オブザーバのターゲット」を参照してください。
デフォルトでは、事前構成済のオブザーバ通信ポリシーが、システムに登録されたすべてのモニターに適用されます。このデフォルト・ポリシーは、すべての関連付けられたオブザーバをターゲットにするように事前構成されています。必要に応じて、このデフォルト・ポリシーを編集したり、新しいポリシーを作成することができます。
デフォルトのオブザーバ通信ポリシー・インスタンスを編集するには:
ナビゲータで、「管理」→「システム・ポリシー」を選択します。
サマリー領域の「オブザーバ通信ポリシー - デフォルト」(以前のリリースではこのポリシーの名前は「デフォルト・オブザーバ通信ポリシー」)を選択します。
「変更」→「定義の編集: オブザーバ通信ポリシー - デフォルト」を選択します。
オブザーバ通信ポリシーの新しいインスタンスを作成するには:
「管理」→「システム・ポリシーの作成」→「オブザーバ通信」を選択します。
次に、このポリシーを使用して実行できる一般的な構成タスクを示します。
12.1.2.11項の「詳細設定フィールドのリファレンス」の表では、次のタスクおよびその他の詳細タスクに関連する情報を確認できます。
オブザーバには、ビジネス・アプリケーションを構成する様々なタイプのコンポーネントを監視するための多様なプローブが含まれています。このポリシーを使用して、システムにインストールされているプローブを個別にアクティブ化または非アクティブ化できます(任意の特定のプローブは、システムにインストールされているオブザーバ内に含まれている場合、インストール済とみなされます)。デフォルトでは、JAVAおよびRMIを除いて、新規に作成したポリシー内のすべてのプローブがアクティブ化されます。
パフォーマンス上の理由からでもそれ以外の理由からでも、インストールされていないプローブを明示的に非アクティブ化する必要はありません(アンインストールされたプローブは本質的にアクティブ化されません)。プローブを非アクティブ化する唯一の理由は、(1)プローブがインストールされており、かつ(2)そのプローブが監視するビジネス・コンポーネントを監視しない場合です。また、SOA Suiteプローブはグループとして非アクティブ化(またはアクティブ化)する必要があります(SOA Suiteプローブは、SOA_ADAPTER、SOA_B2B、SOA_BIZRULE、SOA_BPEL、SOA_BPMN、SOA_CALLBACK、SOA_EDN、SOA_JCA、SOA_MEDIATOR、SOA_REST、SOA_SPRING、SOA_WSおよびSOA_WSAです)。
ポリシーの「アクティブ・プローブ」セクションには、プローブのタイプごとに「検出の有効化」チェック・ボックスおよび「検出時に監視」チェック・ボックスがあります。
「検出の有効化」チェック・ボックスは、関連付けられたコンポーネント・タイプの検出メカニズムをアクティブ化する場合に選択します。そのタイプのコンポーネントは、次回メッセージまたはコールを受信したときに検出されて管理コンソールに表示されます。
コンポーネント・タイプの「検出時に監視」チェック・ボックスは、そのタイプのコンポーネントの監視を検出時にただちに開始する場合に選択します。
|
注意: 検出を有効にするものの監視は実施せず、後でポリシーを編集し監視を有効にする場合、以前に検出されたコンポーネントの監視は開始されません。監視を有効にした後で検出されたコンポーネントのみの監視が開始されます。以前に検出されたコンポーネントの監視の有効化については、12.8.4項「エンドポイントの監視の開始および停止」を参照してください。 |
Business Transaction Managementのアップグレード後、監視用に新しいタイプのプローブが使用可能になる場合があります。ただし、アップグレード処理により、このような新しいプローブは既存のオブザーバ通信ポリシーに自動的には追加されません。既存のポリシーで新しいプローブを使用するには、次のように手動でポリシーに追加する必要があります。
ナビゲータで、「管理」→「システム・ポリシー」を選択します。
サマリー領域でポリシーを選択します。
「変更」→「定義の編集: My_Policy」を選択します。My_Policyはポリシーの名前です。
「アクティブ・プローブ」セクションの最下部にスクロールし、「プローブを追加」をクリックします。
これでカーソルが空のテキスト・フィールドに挿入されます。
カーソルがすでに空のテキスト・フィールドに挿入された状態で、テキスト・フィールド内をクリックします。
すべてのプローブ・タイプの名前が含まれているドロップ・リストが開きます。
追加するプローブ・タイプを選択します。
必要に応じて「検出の有効化」チェック・ボックスおよび「検出時に監視」チェック・ボックスの設定を編集します(これらのフィールドについては、12.1.2.2項「プローブのアクティブ化および非アクティブ化」を参照してください)。
「適用」をクリックします。
デフォルトのオブザーバ通信ポリシーは、オブザーバとモニター間の直接通信を設定します。直接通信により、複数のシングルトン・モニターを使用して、各モニターで複数のオブザーバから監視を収集できます。
オブザーバとレプリケート対象モニターのグループとの間にロード・バランサを配置してモニターをレプリケートする場合は、次に示すように、「通信チャネル」セクションの次の各フィールドの値を設定する必要があります。
| フィールド名 | 値 |
|---|---|
| 通信パス | オブザーバがロード・バランサを介してモニター・グループと通信する場合は、「ルーターからモニター・グループへ」を選択します。この選択により、ポリシーの次の各フィールドが表示されます。 |
| ルーターのIPアドレス | 監視メッセージを受信するロード・バランサのIPアドレスを指定します。 |
| ルーターのポート番号 | ロード・バランサが監視メッセージを受信するポート番号を指定します。
注意: また、ルーターにこのポートを構成する必要があります。 |
| モニターのポート番号 | 転送された監視メッセージをモニターが受信するポート番号を指定します。 |
このトピックの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。
デフォルトのオブザーバ通信ポリシーは、オブザーバからモニターへの監視メッセージの送信に使用されるセキュア・ソケット接続を設定します。この接続に非セキュア・ソケットを使用する場合は、ポリシーの「SSLの有効化」チェック・ボックスを無効にします。
SSLが有効である場合、モニターはオブザーバに対して自己認証する必要があります。デフォルトでは、SSL接続は組込みの事前構成済セキュリティ・ストアを使用します。独自のセキュリティ・ストアを使用する場合は、「デフォルト・ストアの使用」チェック・ボックスを無効にし、次の表の情報を使用して追加フィールドに値を入力します。
|
注意: .NETベースのオブザーバを使用中の場合、SSL接続を使用するにはオブザーバをホストするマシンに証明書をデプロイする必要があります。デフォルト・ストアを使用中の場合は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\server.cerにある事前構成済証明書を使用します。事前構成済証明書のデプロイの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。 |
| フィールド名(太字はセクション名) | 説明 |
|---|---|
| プロトコル | 表示されている場合は必須です。SSLプロトコルを選択します。選択肢は「TLSv1」、「SSLv3」または「いずれか」です。SSLv3は、.NETオブザーバではサポートされていません。このフィールドは、モニターとオブザーバの両方を構成します。 |
| デフォルト・ストアの使用 | このチェック・ボックスはデフォルトで有効になっています。
組込みの事前構成済セキュリティ・ストアを使用する場合は、このチェック・ボックスを有効のままにしてください。この場合、Javaベースのオブザーバのみを使用している場合は作業完了です。.NETベースのオブザーバを使用している場合は、そのオブザーバをホストするマシンに事前構成済証明書をデプロイする必要があります。事前構成済証明書は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\server.cerで確認できます。事前構成済証明書のデプロイの詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください。 このチェック・ボックスを無効にすると、追加フィールドが表示され、独自のセキュリティ・ストアを指定できます。 |
| モニター | ---------- これはセクション・ラベルです ---------
次の5つのフィールドは、モニターのキー・ストアに関連しています。次のすべてのフィールドは、「デフォルト・ストアの使用」チェック・ボックスが無効になっている場合にのみ表示されます。 |
| キー・ストアの場所 | 表示されている場合は必須です。モニターのSSLキー・ストアの場所を指定します。この場所は、キー・ストア・ファイルがモニターに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。
新しいポリシーを開いたときの初期値はAP-MONITOR-SSL:DefaultKeyStore.ksです。この値は、btmmonitor.warデプロイメントのWEB-INF/ssl/DefaultKeyStore.ksにある組込みの事前構成済キー・ストアを指します。 |
| キー・ストア・パスワード | 表示されている場合は必須です。SSLキー・ストアにアクセスするためのパスワードを指定します。 |
| キー・ストア・タイプ | 表示されている場合は必須です。使用するモニターのJCE (Java Cryptographic Extensions)キー・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。 |
| キー名 | 表示されている場合は必須です。証明書および秘密鍵を指定します。CN=valueやUID=valueなどの形式で鍵の別名または証明書属性を入力できます。 |
| キー・パスワード | 表示されている場合は必須です。証明書および秘密鍵にアクセスするためのパスワードを指定します。指定しない場合は、キー・ストアのパスワードが使用されます。 |
| トラスト・ストアをJavaオブザーバへ自動ディスパッチ | このチェック・ボックスが有効である場合、モニターはトラスト・ストアをシリアライズしてすべての関連付けられたJavaオブザーバに自動的に送信します。このオプションは.NETオブザーバでは無視されます。このチェック・ボックスはデフォルトでは無効になっています。 |
| 自動ディスパッチJavaトラスト・ストア | ---------- これはセクション・ラベルです ---------
次の3つのフィールドは自動ディスパッチ・トラスト・ストアに関連しており、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスが有効である場合にのみ表示されます。 |
| トラスト・ストアの場所 | 表示されている場合は必須です。
モニターがJavaオブザーバにディスパッチするSSLトラスト・ストアの場所を指定します。この場所は、トラスト・ストア・ファイルがモニターに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。 新しいポリシーを開いたときの初期値はAP-MONITOR-SSL:DefaultTrustStore.ksです。この値は、btmmonitor.warデプロイメントのWEB-INF/ssl/DefaultTrustStore.ksにある組込みの事前構成済トラスト・ストアを指します。 |
| トラスト・ストア・パスワード | 表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするSSLトラスト・ストアにアクセスするためのパスワードを指定します。 |
| トラスト・ストア・タイプ | 表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするJCE (Java Cryptographic Extensions)トラスト・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。 |
| Javaオブザーバ | ---------- これはセクション・ラベルです ---------
次の3つのフィールドは、手動でインストールしたトラスト・ストアに関連しており、「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」チェック・ボックスが無効である場合にのみ表示されます。 |
| トラスト・ストアの場所 | 表示されている場合は必須です。
Java実行環境にデプロイされたオブザーバによって使用されるSSLトラスト・ストアの場所を指定します。この場所は、トラスト・ストア・ファイルがオブザーバに対してローカルである場合には絶対パスとして指定でき、ファイルがHTTP GETでアクセス可能である場合にはHTTP(S) URLとして指定できます。 新しいポリシーを開いたときの初期値はAP-OBSERVER-SSL:DefaultTrustStore.ksです。この値は、オブザーバ・インストール・ディレクトリのnanoagent\config\ssl\DefaultTrustStore.ksにある組込みの事前構成済トラスト・ストアを指します。 |
| トラスト・ストア・パスワード | 表示されている場合は必須です。SSLトラスト・ストアにアクセスするためのパスワードを指定します。 |
| トラスト・ストア・タイプ | 表示されている場合は必須です。モニターがJavaオブザーバにディスパッチするJCE (Java Cryptographic Extensions)トラスト・ストアのタイプを指定します。たとえば、JKS、JCEKS、PKCS12です。初期値はJKSです。 |
デフォルトのオブザーバ通信ポリシーにより、オブザーバは接続を確立するたびにモニターに対して自己認証する必要があります。この設定は、「オブザーバ認証」フィールドを介して調整できます。このフィールドを「なし」に設定すると、オブザーバ認証をオフにできます。
また、このフィールドを「メッセージ認証の使用」に設定して、メッセージをモニターに送信するたびにオブザーバに自己認証を求めることもできます。ただし、メッセージ認証の使用により、パフォーマンスが大幅に低下する場合があります。この設定は必要な場合にのみ使用してください。たとえば、ロード・バランサが(接続単位ではなく)メッセージ単位のバランシング用に構成されているモニター・グループにオブザーバがメッセージを送信する場合は接続認証を使用できません。この場合、このフィールドを「なし」または「メッセージ認証の使用」に設定する必要があります。
|
注意: 「オブザーバ認証」フィールドは、「SSLの有効化」フィールドが有効である場合にのみ表示されます。「SSLの有効化」フィールドを無効にすると、SSL接続だけでなくオブザーバ認証も無効になります。 |
リリース12.1.0.4が備える新機能により、オブザーバをさらに柔軟に構成できます。以前のリリースでは、任意の1つのモニターに単一のオブザーバ通信ポリシーのみを適用できました。モニターはこのポリシーから単一のオブザーバ構成を生成して、関連付けられたすべてのオブザーバに配布しました(オブザーバにモニターの場所を提供して、インストール時にオブザーバをモニターに関連付けます)。
リリース12.1.0.4から、単一のモニターに複数のオブザーバ通信ポリシーを適用し、これらの各ポリシーをそれぞれ異なるオブザーバまたはオブザーバ・セットでターゲットにすることができます(ターゲットにするオブザーバはモニターに関連付ける必要があります)。次に、オブザーバをターゲットにする手順を説明します。
|
注意: これらの手順の順序は、オブザーバのターゲットにかかわる概念の理解を助けることを目的としています。ただし、タスクを実際に実行するときは、1つのポリシーですべての手順を完了してから次のポリシーに移ることが最も効率的です。 |
「オブザーバのみ対象の構成の生成」チェック・ボックスを無効にしたままにして、モニターの構成を生成するためのソースとして1つのポリシーを指定します(このポリシーをモニター・ポリシーと呼びます)。
モニター・ポリシーにより、モニター構成と1つのオブザーバ構成が生成されます。
オブザーバを構成するために必要な数の追加ポリシーをモニターに適用します(これらのポリシーをオブザーバ・ポリシーと呼びます)。
特定のオブザーバでオブザーバ・ポリシーをターゲットにします。
「構成ラベル」フィールドや「オブザーバのベース・アドレス」フィールドを使用して、どのオブザーバをオブザーバ構成のターゲットにするかを指定します(これらのフィールドおよび関連するフィールドの詳細は、12.1.2.7.1項「オブザーバ構成ラベル」および12.1.2.7.5項「オブザーバのターゲットに関するフィールドのリファレンス」を参照してください)。
あるオブザーバ・ポリシーに指定されているラベルおよびアドレスが、同じモニターに適用されるそれ以外のポリシーに指定されていないことを確認します(詳細は、12.1.2.7.2項「オブザーバ通信ポリシーの拒否」を参照してください)。
オプション - ターゲットのすべてのオブザーバがBusiness Transaction Managementに認識されるようにするには、「アドレスの検証」チェック・ボックスを有効にします。
不明なオブザーバをターゲットにし、このフィールドを有効にした場合、ポリシーは拒否されます。現時点ではまだ不明であるものの後で判明するオブザーバをターゲットにする場合は、このフィールドを無効にしてください。
オプション - (ポリシーを複数のモニターに適用する場合は、このチェック・ボックスを有効にしないでください。)ターゲットのすべてのオブザーバがポリシーの適用先のモニターに関連付けられるようにするには、「モニターに施行」フィールドを有効にします。
オプション - あるポリシーをターゲットにしないままにすると、そのポリシーは適用先のモニターに関連付けられたすべてのオブザーバに対するデフォルトのオブザーバ構成として機能します。
ターゲットでないポリシーは、別のポリシーによって特にターゲットにされていないオブザーバのデフォルトの構成として機能します。たとえば、モニター・ポリシーをターゲットにしないままにして、デフォルトのオブザーバ構成として使用できます。2つ目のターゲットでないポリシーを作成しようとすると、その2つ目のポリシーは拒否されます(ポリシーの拒否については、12.1.2.7.2項「オブザーバ通信ポリシーの拒否」を参照してください)。
|
注意: 様々なポリシーを使用して様々なモニター(またはモニターのグループ)を構成する場合は、それぞれに異なるデフォルトのオブザーバ構成を定義できます。 |
以前のリリースと同じく、必要に応じて単一のポリシーを使用して複数のモニターおよび関連するすべてのオブザーバを構成できます(つまり、特定のオブザーバをターゲットにする必要はありません)。このようなシナリオでは、特定のオブザーバのターゲットではないモニター・ポリシーを使用します。このポリシーは、デフォルトのオブザーバ・ポリシーを生成します。また、特定のオブザーバがターゲットではないため、モニターに関連付けられたすべてのオブザーバがこのデフォルト構成を受信します。
オブザーバ構成ラベルは、オブザーバ・セットを概念的に識別する簡単なテキスト文字列です(たとえば、CONFIG_LABEL_MY_OBSERVERS)。オブザーバがデプロイされているアプリケーション・サーバーのラベルまたは絶対アドレス(たとえば、http://my_host.com:7011)を指定して、オブザーバをターゲットにします。単一のポリシーで任意の数のラベルやアドレスを指定し、任意の数のオブザーバをターゲットにできます。
ラベルを使用すると、構成目的で物理的ではなく論理的にオブザーバをグループ化できます。ラベルの適用は、順不同で実行できる2つのステップからなる手順です。
オブザーバをホストするアプリケーション・サーバーで、ap.nano.config.labelという名前でシステム・プロパティを作成し、その値をラベル文字列に設定します(その方法の詳細は、『Business Transaction Managementインストレーション・ガイド』を参照してください)。
オブザーバの構成に使用するオブザーバ通信ポリシーの「構成ラベル」フィールドをap.nano.config.labelと同じ値に設定します。
オブザーバのターゲットに関連して、誤ってオブザーバ通信ポリシーが拒否される可能性が多々あります。次のいずれのシナリオでも、ポリシーが拒否されます。
ターゲットでない複数のポリシー(デフォルトのオブザーバ構成)を同じモニターに適用しようとしました。
同じモニターに適用される2つの異なるポリシーに同じオブザーバ構成ラベルを指定しようとしました。
同じモニターに適用される2つの異なるポリシーに同じオブザーバ・ベース・アドレスを指定しようとしました。
ラベルは、ポリシーが適用されるモニターにスコープされます。つまり、複数のポリシーがそれぞれ異なるモニターに適用される場合にはそれらのポリシーに特定のラベル名を再利用できますが、同じモニターに適用される複数のポリシーにラベル名を再利用することはできません。このスコープの原則は、ターゲットでないポリシーにも関連しています。
ポリシーが拒否された場合は、コンソールの作業領域でポリシーを選択し、「ターゲット」タブを表示します。このタブには、拒否されたポリシーの原因に関する情報が記載されています。
オブザーバがどの構成を受信するかを決定する優先順位は次のとおりです。
オブザーバのベース・アドレス
ポリシーにオブザーバのベース・アドレスが指定されている場合、オブザーバはそのポリシーによって生成された構成を受信します。
オブザーバ構成ラベル
あるポリシーにオブザーバの構成ラベルが指定され、どのポリシーにもベース・アドレスが指定されていない場合、オブザーバは構成ラベルが指定されているポリシーによって生成された構成を受信します。
ターゲットでないポリシー
ターゲットでないポリシーが存在し、どのポリシーにもオブザーバのベース・アドレスや構成ラベルが指定されていない場合、オブザーバはターゲットでないポリシーによって生成された構成を受信します。
Business Transaction Managementには、特定のタイプのアプリケーションを監視するために事前構成されたオブザーバ通信ポリシーが数多く用意されています。これらのポリシーはいずれも編集可能で、監視ニーズにあわせて調整できます。各ポリシーの名前は太字で表示されており、その後に説明が続きます。
オブザーバ通信ポリシー - デフォルト
このポリシーは、モニター構成とターゲットでない(デフォルト)オブザーバ構成の両方を生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、別のポリシーによって特にターゲットにされていないすべての関連付けられたオブザーバに配布されます。
オブザーバ通信ポリシー - Fusionアプリケーション
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_FAPPSでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle Fusion Applicationsコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。
オブザーバ通信ポリシー - JavaEE
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_JAVAEEでタグ付けされたオブザーバのターゲットになります。この構成は、JavaEEコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。
オブザーバ通信ポリシー - OSB
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_OSBでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle Service Busコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。
オブザーバ通信ポリシー - SOA
このポリシーは、オブザーバ構成のみを生成します。デフォルトでは、このポリシーはシステム内のすべてのモニターに適用されます。オブザーバ構成は、ラベルCONFIG_LABEL_SOAでタグ付けされたオブザーバのターゲットになります。この構成は、Oracle SOAコンポーネントを監視するためにプローブをアクティブ化し、オブザーバのランタイム設定を調整します。
ユーザーがOracle Enterprise Manager Real User Experience InsightからBusiness Transaction Managementへのユーザー・インタフェース・ドリルダウンを実行できるかどうかを制御できます。デフォルトでは、ドリルダウン機能は有効になっています。ドリルダウン機能を無効または再度有効にするには、12.1.2.9項の説明に従ってWEB_APPプローブのrueiPresent属性を設定します。
WEB_APPプローブを使用すると、Javaサーブレットとして実装されているWebアプリケーションを監視できます。このプローブは、あらゆるタイプのJavaサーブレットで使用できる汎用形式の処理と、Oracle Application Development Framework (ADF)アプリケーションでの使用に最適化された特別な形式の処理を備えています。この項では、これらの多様な処理をルールセットと呼びます。汎用タイプの処理はURLルールセットと呼び、ADFアプリケーションに使用されるタイプの処理はADFルールセットと呼びます。プローブは、デフォルトではURLルールセットに設定されます。
別途構成されている場合を除き、WEB_APPプローブは監視対象アプリケーション・サーバーのWebアプリケーションに対するすべてのリクエストを監視します。ただし、多くの場合、すべてのリクエストを監視することはお薦めしません。たとえば、イメージ・ファイルやHTMLファイルなど静的リソースに対するリクエストは監視しないことをお薦めします。そのため、デフォルトのオブザーバ通信ポリシーはjpg、jpeg、html、htm、css、gif、png、ico、js、swf、curのファイル拡張子を持つリソースに対するリクエストを監視しないように構成されています。このように選択的に監視することは、デフォルト・ポリシーの「WEB_APPプローブ構成」フィールドに表示されるXML構成コードのスニペットによって指定されています。
このデフォルトのXML構成コードを編集して、監視対象のリクエストのタイプを制御できます。また、XML要素を追加して管理コンソールでの表示用にアプリケーションの操作名をどのように短縮するかも制御できます(操作名はリクエストURLから導出されます)。次の表に、構成コードで使用可能なXML要素および属性を示します。表の後に使用例を示します。
|
注意: XML要素の順序は重要です。要素に必須の順序については表で説明します。順序を誤ると、ポリシーは拒否されます。 |
| 要素 | 属性 | 説明 | サポートされるルールセット |
|---|---|---|---|
| servletObserver | - | WEB_APPプローブによって監視されるすべてのアプリケーションの構成情報が含まれている、タグで囲まれた要素。<servletObserver>要素は1つのみ存在します。 | ADF URL |
| - | rueiPresent | Oracle Enterprise Manager Real User Experience Insightが監視対象アプリケーションの前にインストールされていることを示します。この属性は、ユーザーがReal User Experience InsightからBusiness Transaction Managementへのユーザー・インタフェース・ドリルダウンを実行できるかどうかを制御します。
有効な値: trueまたはfalse。デフォルト設定はtrueです。 この属性がtrueに設定されている場合、Business Transaction ManagementはHttpResponseにヘッダーを追加してドリルダウン機能を有効にします。ドリルダウン機能を無効にするには、この属性をfalseに設定します。 |
ADF URL |
| - | rueiMatches | Real User Experience Insightネーミング・スキームがBusiness Transaction Managementネーミング・スキームに一致することを示します。有効な値: trueまたはfalse。 | ADF URL |
| globalExcludeList | - | この要素では、指定したURLを監視からグローバルに除外します。ファイル・タイプ、コンテキスト・ルート、パターン一致または長さで除外するURLを指定できます。
要素順序: 使用した場合、この要素は<servletObserver>要素の最初の子として配置する必要があります。<servletObserver>ごとに1つのみ存在できます。 |
ADF URL |
| - | ext | ext="html, htm, jpg, css"というように、ファイル拡張子のカンマ区切りリストが含まれています。指定したタイプのファイルは、監視から除外されます。 | ADF URL |
| - | contextRoot | contextRoot="console, medrec, bookmart"というように、コンテキスト・ルートのカンマ区切りリストが含まれています。指定したコンテキスト・ルートのいずれかが含まれているURLは、監視から除外されます。
空白のコンテキスト・ルートを指定するには、/を使用します。たとえば、contextRoot="console, /, bookmart"とします。 |
ADF URL |
| - | pathPattern | URLパターンのカンマ区切りリストが含まれています。指定したパターンのいずれかに一致するURLは、監視から除外されます。ワイルドカードが許可されており、*を使用して表します。
パターン一致に関する注意(pathPattern属性とpattern属性の両方に当てはまります):
|
ADF URL |
| - | pathLength | 正の整数。この文字数を超えるURLは、監視から除外されます。
プロトコル、ホスト名、ポート番号および問合せ文字列の文字はカウントに含まれません。この属性が作用するURLのセクションは、pathPattern属性と同じです。 |
ADF URL |
| application | - | 監視するアプリケーションを示します。
要素順序: この要素は<servletObserver>要素の子です。<globalExcludeList>要素または<globalAdfOptions>要素に先行しないようにしてください。<servletObserver>要素ごとに任意の数だけ存在可能です。 |
ADF URL |
| - | contextRoot | 監視対象アプリケーションのコンテキスト・ルート。この属性の値はサービス名として使用されます。空白のコンテキスト・ルートを指定するには、/を使用します。たとえば、contextRoot="/"とします。 | ADF URL |
| framework | - | この要素は、<include>子要素を使用してどのURLをどのルールセットで処理するかを指定する場合に使用します。
要素順序: 使用した場合、この要素は<application>要素の最初の子として配置する必要があります。<application>要素のルールセット・タイプごとに1つ存在可能です。 |
ADF URL |
| - | type | <include> URLパターンを処理するルールセットを指定します。有効な値はADFおよびURLです。ADF Webアプリケーションの場合、この属性をADFに設定します。その他のWebアプリケーションの場合、この属性をURLに設定します。各ルールセットによって処理されるリクエストは相互排他的です。
<framework>タグが指定されている場合、プローブはデフォルトでURLルールセットに設定されます。<framework>タグが指定されている場合、デフォルト値はありません。 |
ADF URL |
| include | - | この要素を使用すると、リクエストをルールセットにマップするときに、指定したワイルドカード式に一致するものを除いてすべてのリクエストを除外できます。
この要素を使用して、以前に除外したURLを含めることはできません。たとえば、<globalExcludeList>を使用してpng拡張子を除外した場合、<include>要素に*.pngを指定してその除外をオーバーライドすることはできません。 要素順序: この要素は<framework>要素の子です。<framework>要素ごとに多数存在可能です。 |
ADF URL |
| - | pattern | 一致させるURLパターン。ワイルドカードが許可されており、*を使用して表します。
この属性は、pathPattern属性と同じパターン一致ルールに従います。これらのルールについては、<globalExcludeList>要素のpathPattern属性を参照してください。 |
ADF URL |
| excludeList | - | この要素では、監視から除外する、特定のアプリケーション内のファイル・タイプを指定します。この要素は、特定のアプリケーションの<globalExcludeList>要素をオーバーライドします。
要素順序: この要素は<application>要素の子です。どの<framework>要素にも先行せず、すべての<adfOptions>要素および<operationRule>要素に先行する必要があります。<application>要素ごとに1つのみ存在可能です。 |
ADF URL |
| - | ext | html, htm, jpg, cssというように、ファイル拡張子のカンマ区切りリストが含まれています。指定したタイプのファイル(親アプリケーション内)は、監視から除外されます。
アプリケーション内のすべてのファイル・タイプを監視する場合に、<globalExcludeList>要素のext属性が設定されているときは、このext属性をヌル文字列に設定します(たとえば、ext="")。 |
ADF URL |
| adfOptions | - | この要素では、ADF UIリクエスト・パラメータoracle.adf.view.rich.monitoring.UserActivityInfoに含まれているプロパティ値を操作名に追加して、特定のアプリケーション内の操作をパーティション化します。この機能を使用するには、UserActivityInfoリクエスト・パラメータを有効にする必要があります(12.1.2.9.1項「UserActivityInfoリクエスト・パラメータの有効化」を参照)。この要素の属性は、UserActivityInfoリクエスト・パラメータのプロパティに対応しています。属性は、プロパティ値が操作名に追加されるかどうかを制御します。プロパティ値は、リクエスト・パラメータに存在する場合にのみ追加されます。
要素順序: この要素は<application>要素の子です。どの<framework>要素またはどの<excludeList>要素にも先行せず、すべての<operationRule>要素に先行する必要があります。<application>要素ごとに1つのみ存在可能です。 |
ADF URL |
| - | appendRegionViewId | __regionViewIdという書式を使用してregionViewIdプロパティの値を操作名に追加するには、この属性をtrueに設定します。デフォルト設定はfalseです。 | ADF URL |
| operationRule | - | この要素には、URLのうち、値の一意の組合せが操作を構成する部分を指定します。この要素では、URLから導出される操作名を短縮します。
要素順序: この要素は<application>要素の子です。<framework>、<excludeList>、<adfOptions>のどの要素にも先行しないようにしてください。<application>要素ごとに1つのみ存在可能です。 |
ADF URL |
| - | excludeDirectories | 操作名から除外するディレクトリ・レベルのカンマ区切りリストが含まれています。たとえば、/facesまたはセッションIDを除外できます。コンテキスト・ルートはディレクトリ・レベルとみなされないことに注意してください。また、excludeDirectoriesカウントは0ではなく1から始まります。 | ADF URL |
| paramGroup | - | この要素では、複数のリクエスト・パラメータで操作をパーティション化します。<partitionByParam>要素をこの要素の子として追加して、リクエスト・パラメータを指定します。パーティション化は、指定したすべてのパラメータがリクエストに存在する場合にのみ発生します。パラメータ名および値は、次の書式で操作名に追加されます。
_name1_value1__name2_value2__name3_value3
名前と値の各ペア間にアンダースコア文字が2つあることに留意してください。この要素には、最大3つの<partitionByParam>要素を含めることができます。 注意: この要素を使用して既存のトランザクション定義に使用されている操作をパーティション化すると、そのトランザクションのセマンティクスが変更されます。たとえば、指定したパラメータが含まれているリクエストは元の操作に対するリクエストとしてカウントされないため、トランザクションに属するものとしてカウントされません。トランザクションの定義を適宜更新することが必要になる場合があります。 要素順序: 使用した場合、この要素は<operationRule>要素の最初の子として配置する必要があります。複数の<paramGroup>要素が存在可能です。この要素は、すべてのスタンドアロンの<partitionByParam>要素(つまり、<paramGroup>要素の子でないもの)に先行する必要があります。 |
ADF URL |
| partitionByParam | - | この要素は、指定されたリクエスト・パラメータの値に基づいて操作をパーティション化します。一意の各パラメータ値は、それぞれ独立した操作としてモデル化されます。パラメータは、URLパラメータまたはPOSTパラメータのいずれかにできます。
たとえば、actionという名前のパラメータを取るorderApplication.jspがあるとします。通常、orderApplication.jspへのリクエストはorderApplication.jspという名前の単一の操作へのリクエストとしてモデル化されます。ただし、<partitionByParam>を使用し、actionパラメータでパーティション化した場合、actionパラメータが含まれているorderApplication.jspへのすべてのリクエストがorderApplication.jsp_action_paramValueという名前の操作へのリクエストとしてモデル化されます。paramValueはactionパラメータの値です。また重要なのは、actionパラメータが含まれているリクエストは操作orderApplication.jspへのリクエストとしてカウントされないことです。(「例2 - 操作名へのパラメータ名/値のペアの追加」も参照してください。) 注意: この要素を使用して既存のトランザクション定義に使用されている操作をパーティション化すると、そのトランザクションのセマンティクスが変更されます。たとえば、指定したパラメータが含まれているリクエストは元の操作に対するリクエストとしてカウントされないため、トランザクションに属するものとしてカウントされません。トランザクションの定義を適宜更新することが必要になる場合があります。 要素順序: 使用した場合、この要素を次の2つの位置に配置できます。
<operationRule>要素ごとに任意の数だけ存在可能です。<paramGroup>の前に単一の<partitionByParam>要素を使用する場合は、その<paramGroup>要素の内側に配置します。 注意: この要素では、ADFページ入力パラメータがサポートされません。 |
ADF URL |
| - | name | リクエストのパーティション化に使用されるパラメータの名前。特定のパラメータの各個別値は、それぞれの操作に対応しています。パラメータはname_valueとして操作名に追加されます(nameはパラメータの名前で、valueはその値です)。 | ADF URL |
| secureParam | - | この要素は、操作名とBusiness Transaction Managementメッセージの両方で値が非表示になるか、またはいっさい格納されないURLパラメータまたはPOSTパラメータ(たとえば、パスワード)を表します。
要素順序: この要素は<operationRule>要素の子です。どの<paramGroup>要素または<partitionByParam>要素にも先行しないようにしてください。<operationRule>要素ごとに任意の数だけ存在可能です。 |
ADF URL |
| - | name | 値が非表示になるか、またはいっさい格納されないパラメータの名前。 | ADF URL |
|
注意: (1) サービスおよび操作名は、リクエストURLから導出されます。XML規格に準拠するために、プローブはスラッシュ、疑問符、等号(/、-、=)などの特殊文字をアンダースコア記号(_)に置き換えます。 (2) サービスおよび操作名は、255バイトを超える場合には短縮されます。この短縮は、名前を252バイトに切り捨ててから…を追加することによって行われます。 (3) pathLength属性の処理は、pathPattern属性の処理よりも前に行われます。サービスおよび操作名の短縮は、処理の最後に行われます。実行の完全な順序は次のとおりです。
|
例1 - 操作名の短縮
<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf"> <ap:application contextRoot="/mywebshop"> <ap:operationRule excludeDirectories="1, 2" /> </ap:application> </ap:servletObserver>
前の構成コードが次のリクエストURLに適用されます。
http://secure.banking.de:7001/mywebshop/shopping/s28373/basket/checkout.jsp
この構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。
| オブジェクト | 値 | 説明 |
|---|---|---|
| Service | mywebshop | サービス名はcontextRoot属性の値です。 |
| Endpoint | http://secure.banking.de:7001/mywebshop | エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。 |
| Operation | basket_checkout.jsp | デフォルトでは、操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はshopping/s28373/basket/checkout.jspになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(shopping/s28373/)は除外されます。 |
例2 - 操作名へのパラメータ名/値のペアの追加
<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf"> <ap:application contextRoot="/physician"> <ap:operationRule> <ap:partitionByParam name="lastName"/> </ap:operationRule> </ap:application> </ap:servletObserver>
前の構成コードが次のリクエストURLに適用されます。
http://stbdm02:7011/physician/physicianSection/viewRecordSummary.action
POSTパラメータがlastName=Einsteinになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。
| オブジェクト | 値 | 説明 |
|---|---|---|
| Service | physician | サービス名はcontextRoot属性の値です。 |
| Endpoint | http://stbdm02:7011/physician | エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。 |
| Operation | physicianSection_viewRecordSummary.action_lastName_Einstein | <partitionByParam>要素で指定されているパラメータの名前および値がデフォルトの操作名に追加されます。 |
例3 - リクエストのフィルタ処理およびルールセットの適用
<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf"> <ap:application contextRoot="/em"> <ap:framework type="ADF"> <ap:include pattern="*/faces*"/> </ap:framework> <ap:framework type="URL"> <ap:include pattern="*/console*" /> </ap:framework> <ap:operationRule excludeDirectories="1, 2" /> </ap:application> </ap:servletObserver>
前の構成コードが次のリクエストURLに適用されます。
http://myhost:17861/em/faces/ocamm/managers/ocammHome http://myhost:17861/em/console/all/targets/search http://myhost:17861/em/em2go/about.jsp
この構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。
| オブジェクト | 値 | 説明 |
|---|---|---|
| Service | em | サービス名はcontextRoot属性の値です。 |
| Endpoint | http://myhost:17861/em | エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。 |
| Operation | managers_ocammHome | (これは最初の例のURLに関連しています)
<framework>要素のタイプはADFに設定されているため、ADFルールセットが使用されます。このため、デフォルトでは操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はfaces/ocamm/managers/ocammHomeになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(faces/ocamm/)は除外されます。 |
| Operation | targets_search | (これは2つ目の例のURLに関連しています)
<framework>要素のタイプはURLに設定されているため、URLルールセットが使用されます。このため、デフォルトでは操作名はリクエストURLからのディレクトリとファイル名で構成されています。この場合、デフォルトの操作名はconsole/all/targets/searchになります。ただし、<operationRule>要素のexcludeDirectories属性が1, 2に設定されているため、1つ目と2つ目のディレクトリ(console/all/)は除外されます。 |
| N/A | N/A | (これは3つ目の例のURLに関連しています)
タイプURLの<framework>要素は、パターン*/console*のみで指定されました。このリクエストはそのパターンに適合しません。また、ADF <framework>要素に指定されているパターンにも適合しません。このため、監視から除外されます。 |
例4 - 操作名へのパラメータ名と値の複数のペアの追加
<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/physician">
<ap:operationRule>
<ap:paramGroup>
<ap:partitionByParam name="firstName"/>
<ap:partitionByParam name="lastName"/>
</ap:paramGroup>
</ap:operationRule>
</ap:application>
</ap:servletObserver>
前の構成コードが次のリクエストURLに適用されます。
http://st02:7011/physician/physicianSection/viewRecordSummary.action
POSTパラメータがfirstName=JohnおよびlastName=Doeになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。
| オブジェクト | 値 | 説明 |
|---|---|---|
| Service | physician | サービス名はcontextRoot属性の値です。 |
| Endpoint | http://st02:7011/physician | エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。 |
| Operation | physicianSection_viewRecordSummary.action_firstName_John__lastName_Doe | <paramGroup>要素内に指定されたパラメータの名前および値は、リストされる順にデフォルトの操作名に追加されます。firstNameパラメータまたはlastNameパラメータが使用可能でなかった場合、この<paramGroup>要素は無視され、その結果physicianSection_viewRecordSummary.actionの値になります。 |
例5 - パラメータの優先順位処理
<ap:servletObserver xmlns:ap="http://namespace.amberpoint.com/amf">
<ap:application contextRoot="/physician">
<ap:operationRule>
<ap:paramGroup>
<ap:partitionByParam name="firstName"/>
<ap:partitionByParam name="lastName"/>
</ap:paramGroup>
<ap:partitionByParam name="lastName"/>
<ap:partitionByParam name="middleName"/>
</ap:operationRule>
</ap:application>
</ap:servletObserver>
前の構成コードが次のリクエストURLに適用されます。
http://st02:7011/physician/physicianSection/viewRecordSummary.action
POSTパラメータがlastName=SmithおよびmiddleName=Rodneyになっている構成コードにより、Business Transaction Managementで次のオブジェクトが生成されます。
| オブジェクト | 値 | 説明 |
|---|---|---|
| Service | physician | サービス名はcontextRoot属性の値です。 |
| Endpoint | http://st02:7011/physician | エンドポイントは、監視対象Webアプリケーションにサービス名(contextRoot属性の値)を付加したものの物理的位置です。 |
| Operation | physicianSection_viewRecordSummary.action_lastName_Smith | プローブはまず、<paramGroup>要素に指定されているパラメータがリクエストにあるかどうかをチェックします。firstNameパラメータが指定されていないため、<paramGroup>要素全体がスキップされます。次にプローブは、次の<paramGroup>要素またはスタンドアロンの<partitionByParam>要素をチェックします。次の要素にlastNameパラメータが指定され、そのパラメータがリクエストにあるため、そのパラメータの名前と値が操作名(_lastName_Smith)に追加されます。この一致の検出後、プローブはパラメータのチェックを停止します。つまり、middleNameパラメータは操作名に追加されません。 |
<adfOptions>要素および<globalAdfOptions>要素が備える操作パーティション化機能を使用する場合は、UserActivityInfoリクエスト・パラメータがアプリケーションに対して有効であることを確認する必要があります。Oracle Enterprise Manager Real User Experience InsightでADFサポートを使用する環境だけでなく、Oracle Fusion Applications環境でもこれがデフォルトで有効になっています。
ADFアプリケーションでUserActivityInfoリクエスト・パラメータを有効にするには、アプリケーションのweb.xmlファイルで次のプロパティを設定します。
<context-param>
<description>
This parameter notifies ADF Faces that the ExecutionContextProvider
service provider is enabled. When enabled, this will start
monitoring and aggregating user activity information for the client
initiated requests. By default, this param is not set or is false.
</description>
<param-name>
oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER
</param-name>
<param-value>true</param-value>
</context-param>
| フィールド名 | 説明 |
|---|---|
| 名前 | 必須。ポリシーの名前を指定します。このフィールドを一意の文字列に設定できます。 |
| バージョン | オプション。このフィールドは説明用であり、ポリシーの関連情報を入力するために用意されています。 |
| 注意 | オプション。このフィールドは説明用であり、ポリシーの関連情報を入力するために用意されています。 |
| フィールド名(太字はセクション名) | 説明 |
|---|---|
| オブザーバの動作 | - |
| 構成ポーリング間隔 | 必須。このフィールドでは、オブザーバが新しい構成がないかどうかをチェックする頻度を秒単位で指定します。 |
| インスツルメント更新間隔 | 必須。このフィールドでは、オブザーバが測定データをモニターに送信する頻度を秒単位で指定します。 |
| 接続数 | このフィールドでは、オブザーバが開くソケット接続の数を指定します。複数の接続を使用すると、監視のスループットが向上します。 |
| マッピング・アルゴリズム | リクエストおよびWSDL URLのホスト名とポート番号の部分の変更に使用されるアルゴリズムを指定します。次の値から選択してください。
送信時のまま: オブザーバは、URLを書き換えずにそのままモニターに転送します。 ホスト名を使用: オブザーバは、URLのホスト名の部分をサーバーのホストの完全修飾名に置き換えます。また、URLのポート番号の部分をサーバーがリスニングしているポート番号に置き換えます。ホスト名およびポート番号は、デプロイメント環境から取得されます。 このアルゴリズムは、クラスタ化されたサーバーの前にロード・バランサがある場合に有益です。このシナリオでは、元のリクエストURLはロード・バランサのもので、ロード・バランサのホスト名およびポート番号が指定されています。オブザーバが元のリクエストURLをモニターに渡した場合、サーバーのクラスタ全体が単一のサーバーとしてモデル化されます。アルゴリズムがuseHostnameに設定されると、各サーバーは個別にモデル化されます。 IPアドレスを使用: オブザーバは、URLのホスト名をIPアドレスに変換します。ポート番号はそのままです。IPアドレスは、デプロイメント環境から取得されます。 このアルゴリズムは、モニターがホスト名を有効なIPアドレスに解決できない場合に便利です。サーバーに複数のIPアドレスがある場合には、このアルゴリズムを使用しないでください。 完全修飾名(FQN)を使用: オブザーバは、URLのホスト名を完全修飾名に変換します。ポート番号はそのままです。 このアルゴリズムは、サーバーに複数のIPアドレスがある場合に便利です。 代替を使用: このアルゴリズムでは、ホスト名、ポート番号およびプロトコルに特定の値を指定できます。次の3つのフィールドを使用して値を入力します。いずれかのフィールドに値を指定しない場合、URLの対応する部分はそのままになります。 注意: OSBオブザーバの場合、ターゲット・サービスURLは常にオブザーバ構成のFQNに設定されますが、この設定はこのポリシーには表示されていません。 |
| 代替ホスト | URLのホスト部分として使用される値。 |
| 代替ポート | URLのポート番号部分として使用される値。 |
| 代替プロトコル | URLのプロトコル部分として使用される値。 |
| 検出処理間隔 | オブザーバが新しいコンポーネントの検出を試みる一定の間隔(分単位)を指定します。デフォルト値は3分です。1440分(1日)を超える値は1440分と解釈されます。負の値は3分と解釈されます。 |
| 動的検出期間の有効化 | オブザーバが新しいコンポーネントの検出を試みる際のタイミングのアルゴリズムを有効化します。有効化されている場合、検出間隔は各検出後に倍になり、指定されている検出処理間隔の最大32倍にまでなります。1440分(1日)を超える計算値は1440分と解釈されます。この機能により、変更されていないコンポーネントが頻繁に処理されなくなります。
たとえば、検出処理間隔が300に設定されていて、このオプションが有効化されている場合、2番目の検出は600分後に発生し、次に1200分となりますが、1440分を超えて増加することはありません。 |
| オブザーバのトラブルシューティング | - |
| トレース・ロギングの有効化 | トレース・ロギングは常に有効になっており、デフォルトでは「情報」に設定されています。このチェック・ボックスは、「トレース・ロギング・レベル」フィールドを有効にして設定を編集できるようにする場合に使用します。
他のタイプのオブザーバ・エラーのロギング、エラー・ログ・ファイルの場所およびエラー・ログの場所の構成については、12.1.3項「オブザーバ・エラーおよびデバッグ情報のロギング」を参照してください。 |
| トレース・ロギング・レベル | このフィールドでは、ログ・ファイルに書き込む情報のレベルを指定します。有効な値は情報量の少ない順に次のとおりです。
「情報」、「普通」、「詳細」、「最も詳細」 |
| トレース・ファイルのサイズ | このフィールドには、トレース・ログ・ファイルのサイズをKB単位で指定します。 |
| トレース・ファイルのカウント(切替え) | このフィールドには、トレース・ログ・ファイルの最大数を指定します。トレース・ログ・ファイルの最大数に達すると、切替えが発生して最も古いファイルが新しいファイルで上書きされます。
一般に、この設定を変更するのはOracleサポートからそうするように求められたときのみです。 |
| 監視対象メッセージをファイルに記録 | 監視対象メッセージをファイルに書き込む場合には、このチェック・ボックスを有効にします。 |
| 監視ログ・ディレクトリ | 監視ログ・ファイルが含まれているディレクトリへのパス。WebLogic、OC4J、WebSphereおよびJBossサーバーの場合、絶対パスまたは相対パスを指定できます。その他のサーバーの場合、絶対パスのみを指定できます。相対パスはデフォルトの場所を基準にします。デフォルトの場所は次のとおりです。
注意: WCFおよびASP.NETのデフォルトのログの場所は実際のデフォルトではありません。単にAmberPoint:NanoLogBaseDirキーのデフォルトの設定にすぎません。このキーをnullに設定した場合、ログ・ファイルは作成されません。 |
| オブザーバのメッセージ・キュー | このセクションのフィールドは、オブザーバの監視キューの動作に影響を及ぼします。オブザーバは、監視対象でサービス宛てのメッセージをこの送信キューにコピーします。これらの監視はその後、キューから取り出されてモニターに送信されます。 |
| キュー・サイズ | 必須。このフィールドには、オブザーバの監視キューが保持できるメッセージの最大数を指定します。数を大きくすると、キューに割り当てられるメモリー量が増えます。 |
| 最大メッセージ・サイズ | オプション。このフィールドには、オブザーバの監視キューに配置できるメッセージの最大サイズをKBで指定します。指定したサイズよりも大きいメッセージは、まず切り捨てられ、その後キューに配置されます。
このフィールドを使用すると、ネットワークおよびモニターの負荷を軽減できます。 切捨ては、メッセージの本文にのみ適用されます。メッセージのエンベロープはそのままです。 注意: サービスが他のサービスに対するクライアントである場合、この設定はそれらのサービスを監視するオブザーバと同じ値に設定する必要があります。そうしないと、依存性トラッキング・メカニズムが混乱し、存在しないクライアントが依存性ダイアグラムに表示されます。 |
| キューが満杯の場合 | 注意: Oracleサポートから編集の指示がないかぎり、このフィールドはデフォルト設定のままにしてください。このフィールドのデフォルト設定は「サービス宛てのメッセージをキューにコピーせずに転送」です。
「キューが満杯の場合」フィールドには、オブザーバの監視キューが満杯になった場合の動作を指定します。次のオプションのいずれかを選択してください。 サービス宛てのメッセージをキューが空いてコピー可能になるまで延期: キューが満杯の場合、オブザーバは元のメッセージをサービスに転送する前に、キューが監視を保持するのに十分な領域を確保するまで待機します。この設定によって、すべてのメッセージのコピーがモニターに転送されるようになります。ポリシーのモニター構成セクションで「ソケットを介した監視対象メッセージの受信をキューが空くまで延期」オプションとともにこのオプションを選択すると、すべての監視がログに記録されるようになります。ただし、通信量が多い状況では、このような設定にすると、監視対象アプリケーションによるメッセージ処理の速度が低下する場合があります。 サービス宛てのメッセージをキューにコピーせずに転送: キューが満杯の場合、オブザーバはキューにコピーすることなく元のメッセージをサービスに転送します。このオプションを選択すると、監視対象アプリケーションのメッセージ処理速度が低下することなく監視がログに記録されるようになります。ただし、通信量が多い状況では、この設定にすると監視が失われる場合があります。 注意: どのような場合にも、オブザーバが元のサービス宛てのメッセージを破棄することはありません。 |
| モニターのメッセージ・キュー | このセクションのフィールドは、モニターの監視キューの動作に影響を及ぼします。監視は、モニターに到達すると、この受信キューに配置されます。モニターはその後、パフォーマンスやトランザクションなどに関するデータを収集するためにキューから監視を取り出して処理します。 |
| キュー・サイズ | 必須。このフィールドには、モニターの監視キューが保持できるメッセージの最大数を指定します。数を大きくすると、キューに割り当てられるメモリー量が増えます。 |
| 最大メッセージ・サイズ | オプション。このフィールドには、モニターの監視キューで受け付けられるメッセージの最大サイズをKBで指定します。このフィールドを使用すると、サイズの大きなメッセージの処理を制限してモニターの負荷を軽減できます。
このフィールドに値を指定することにより、指定した値よりも大きくなった場合にはリクエストとレスポンスの両方のメッセージ(またはフォルトの場合はフォルト・メッセージ)を削除するようにBusiness Transaction Managementに指示します。サイズが大きすぎるメッセージは処理されずに削除され、スループットや平均レスポンス時間などのパフォーマンス測定の計算に使用されません。 |
| アイドル・ソケット・タイムアウト | 必須。このフィールドには、トラフィックがない場合にモニターが監視を受信するソケットを開いたままにする最大ミリ秒数を指定します。 |
| リクエスト・メッセージの最大保持時間 | オプション。この設定には、レスポンスが届かないとみなされるまでに、モニターがリクエスト・メッセージを保持する秒数を指定します。この時間を超えると、リクエストはレスポンス・メッセージがタイムアウトした場合と同じように処理されます。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の60秒が使用されます。 |
| メッセージを処理するスレッドの数 | オプション。このフィールドには、モニターが監視メッセージの処理用に割り当てるスレッドの数を指定します。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の5秒が使用されます。 |
| エンドポイント検出を処理するスレッドの数 | オプション。このフィールドには、モニターがエンドポイント検出メッセージの処理用に割り当てるスレッドの数を指定します。このフィールドを空白のままにするか、または0に設定した場合は、デフォルト値の2秒が使用されます。 |
| キューが満杯の場合 | 必須。このフィールドには、モニターの監視キューが満杯になった場合の動作を指定します。次のオプションのいずれかを選択してください。
ソケットを介した監視対象メッセージの受信をキューが空くまで延期: 満杯になった場合、キューは監視の受信(メッセージのコピー)をそのための領域が確保できるまで拒否します。この場合、オブザーバはキューに正常に配置されるまで監視を再送信します。ポリシーのオブザーバ構成セクションで「サービス宛てのメッセージをキューが空いてコピー可能になるまで延期」オプションとともにこのオプションを選択すると、すべての監視がログに記録されるようになります。ただし、通信量が多い状況では、このような設定にすると、監視対象アプリケーションによるメッセージ処理の速度が低下する場合があります。 受信した監視対象メッセージを破棄: 満杯になった場合、キューは受信した監視を破棄します。ポリシーのオブザーバ構成セクションで「サービス宛てのメッセージをキューにコピーせずに転送」オプションとともにこのオプションを選択すると、監視対象アプリケーションのメッセージ処理速度が低下しなくなります。ただし、通信量が多い状況では、この設定にすると監視が失われる場合があります。 注意: どのような場合にも、モニターは元のアプリケーション・メッセージを破棄しません。 |
| サーブレット・オブザーバ構成 | - |
| WEB_APPプローブ構成の指定 | このチェック・ボックスはWEB_APPプローブに関連しており、リクエストの監視および操作のモデル化を選択的に構成できるようになります。このチェック・ボックスを有効にすると、「WEB_APPプローブ構成」フィールドが表示され、これらのオプションの構成コードを入力できます。このフィールドはデフォルトで有効になっています。
注意: 「カスタム・オブザーバ構成」フィールドにカスタム・オブザーバ構成を指定する場合は、このチェック・ボックスを有効にしないでください。かわりに、「カスタム・オブザーバ構成」フィールドのカスタム・オブザーバ構成にフィルタ処理/モデル化のコードを追加する必要があります。このコードは、<servletObserver>要素に含め、カスタム構成の<nanoAgentConfigurations>要素(カスタム構成のルート要素)の最後の子として追加する必要があります。 |
| WEB_APPプローブ構成 | このフィールドは、「WEB_APPプローブ構成の指定」チェック・ボックスが有効になっている場合にのみ表示されます。
このフィールドを使用してWEB_APPプローブの構成に<servletObserver>要素を入力します。この要素により、リクエストの選択的監視および操作のモデル化を制御できます。 デフォルトでは、このフィールドに次のコードが含まれており、プローブは指定された拡張子を持つファイルに対するリクエストを監視しないように指示されます。 <ap:servletObserver rueiPresent="true" rueiMatches="false" xmlns:ap="http://namespace.amberpoint.com/amf"> <ap:globalExcludeList ext="jpg, jpeg, html, htm, css, gif, png, ico, js, swf, cur"/> </ap:servletObserver> <servletObserver>要素のコーディングについては、12.1.2.9項「WEB_APPプローブ用のリクエストの監視および操作のモデル化」を参照してください。 |
| カスタム・オブザーバ構成 | - |
| カスタム構成の使用 | このポリシーで使用可能でないオブザーバ構成オプションが必要である場合は、このチェック・ボックスを有効にし、次のフィールドにオブザーバ構成を入力します。このチェック・ボックスが有効である場合、カスタム構成はこのポリシーの他のすべてのフィールドをオーバーライドします。 |
| カスタム・オブザーバ構成 | このフィールドでは、カスタム・オブザーバ構成を入力します。このフィールドは、「カスタム構成の使用」チェック・ボックスが有効になっている場合にのみ表示されます。 |
| モデル構成 | このセクションのフィールドでは、Business Transaction Managementが特定のタイプのコンポーネントをどのようにモデル化するかを制御します。
警告: オブザーバをインストールしてコンポーネントを検出する前に、これらのフィールドを適切な設定にあわせて調整してください。すでに検出されたコンポーネントに対してこれらの設定を編集する場合は、既存のトランザクション定義を変更したり、モデルをリセットすることが必要になる場合があります(モデルのリセット方法については、10.11項「deleteAll」を参照してください)。 |
| SOA | このフィールドは、SOAコンポーネントをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのSOAコンポーネントをモデル化します。 フローのエッジのモデル化: 各SOAコンポジット・アプリケーションの最初のコンポーネント(たとえば、Webサービス・インタフェース)のみをモデル化します。これがデフォルトの設定です。この設定は、この設定にかかわらずすべてのコンポーネントが常にモデル化されるSOA_B2BまたはSOA_JCAには適用されません。 |
| ローカルEJB | このフィールドは、ローカルEJBコンポーネントをどのようにモデル化するかを制御します。リモートEJBコンポーネントのモデル化には影響しません(すべてのリモートEJBが常に監視されます)。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのローカルEJBコンポーネントをモデル化します。 モデル化しない: ローカルEJBコンポーネントをモデル化しません。これがデフォルトの設定です。 フローのエッジのモデル化: 各ローカル・リクエスト・フローの最初のローカルEJBコンポーネントのみをモデル化します。 ORA-WSのモデル化: EJB実装クラスに関する次のいずれかの注釈の存在に基づいてOracle Webサービス(ORA-WS) Webサービス用のビジネス・ロジックを実装するローカルEJBコンポーネントのみをモデル化します。
このオプションは、特にORA-WS向けに設計されています。ORA-WSは、主としてFusion ApplicationsなどのOracleパッケージ・アプリケーションで使用されます。 |
| OSB | このフィールドは、Oracle Service Busコンポーネントをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: OSBビジネス・サービス、プロキシ・サービス、分割-結合タスク、発行元が分割-結合タスクであるメッセージのパラレル・フローなど、すべてのOracle Service Busコンポーネントをモデル化します。 フローのエッジのモデル化: プロキシ・サービスのみをモデル化します。これがデフォルトの設定です。 |
| JMS | このフィールドは、JMSトピック、キューおよびメッセージ・リスナーをどのようにモデル化するかを制御します。次のオプションのいずれかを選択してください。
すべてモデル化: すべてのJMSトピック、JMSキューおよびその関連するメッセージ・リスナーをモデル化します。 フローのエッジのモデル化: JMSトピックに関連付けられたメッセージ・リスナーのみをモデル化します。これがデフォルトの設定です。 |
| JDBCサマリー | このセクションのフィールドは、JDBCサマリー・モードを制御します。サマリー・モードを有効にすると、関連するJDBCコールの監視が集計され、単一サマリー監視メッセージとしてモニターに送信されます。サマリー・モードを有効にすることで、特に監視されるサービスがJDBCコールを多数使用し、これらの操作に対してメッセージ・ロギングを有効にしている場合、BTMシステムのパフォーマンスを改善し、データベースのディスク領域要件を低減できます。監視メッセージのボリュームの低減、およびメッセージ・ログ・データベースに書き込まれるJDBCコール数の制約の両方により、これらの利得が達成されます。メッセージ・ロギングの制約を制御できるオプションが用意されています。
注意: JDBCサマリー・モードは、レスポンス時間などパフォーマンス測定の収集、記録または表示に影響を及ぼしません。 |
| サマリー・モード有効化 | このフィールドでは、JDBCサマリー・モードを有効または無効にします。デフォルトでは、この設定は有効です。 |
| ログに記録する最遅JDBCコール数 | ログを記録する必要がある最遅JDBCコール数を指定します。たとえば、2を指定した場合、2つの最遅コールのみがサマリー監視メッセージに含まれ、メッセージ・ログ・データベースにログが記録されます(その操作に対してメッセージ・ロギングが有効であると想定します)。デフォルト値は3つのコールです。 |
| JDBCコールの時間制限 | 非推奨。この機能は指定された時間制限に達したときにのみシステム・アラートを送信します。この時間制限は、想定される最長のSQL問合せ時間よりも大きく設定することをお薦めします。JDBCコールの完了に必要と思われる最長期間を秒単位で指定します。JDBCコールが時間制限を超えた場合、サマリー監視メッセージが即時に送信されます。この不完全なサマリー監視メッセージは、問合せの完了に想定よりも長く時間がかかっているという警告として機能します(未完了のJDBCコールのレスポンス時間の値は「タイムアウト」の値で示されます)。不完全なJDBCコールを後で完了する場合、または他の関連するコールが監視される場合、前のサマリー・メッセージからの情報と、新しく完了したコールまたは新しく監視されたコール(あるいはその両方)からの情報を組み合せたフォローアップ・サマリー監視メッセージが送信されます。デフォルト値は10秒。 |
| ログに記録するフォルト・メッセージ数 | ログを記録する必要があるフォルト・メッセージ数を指定します。たとえば、1を指定した場合、最初に受信したフォルト・メッセージのみがサマリー監視メッセージに含まれ、メッセージ・ログ・データベースにログが記録されます(その操作に対してメッセージ・ロギングが有効であると想定します)。2を指定した場合、最初と最後がログに記録されます。3を指定した場合、最初、2番目、最後がログに記録されます(以降同様)。デフォルト値は2つのフォルトです。 |
| コール元がコンテンツを取得するように構成されている場合にのみサマリーを取得 | 通常、エンドポイントがトランザクションに含まれ、ロギングが有効になっている場合、そのエンドポイントがトランザクションの外部から呼び出されたときでも、メッセージは取得されます。
このボックスを選択すると、JDBCおよびJDBCコール操作に対してロギングが有効である場合にのみ、(フォルトおよび最遅メッセージの)メッセージ・コンテンツがログに記録されます。(トランザクション全体に対してインスタンス・ロギングが有効であるか、またはJDBCコール操作に対してロギングが有効であるため、ロギングはJDBCコール操作に対して有効です。) このボックスを選択しないと、コール元がトランザクションに含まれていない場合でも、JDBCエンドポイントに送信されるすべてのメッセージがカウントされます。フォルト・メッセージおよび最遅メッセージのコンテンツが記録されます。 |
| JDBC拡張構成 | このセクションのフィールドにより、JDBC機能を詳細に制御できます。 |
| SQLパラメータの表示 | 通常、関連するJDBCコールの監視を集約して単一のサマリー監視メッセージとしてモニターに送信する際、すべての定数パラメータは非表示になります。このオプションを有効化した場合、パラメータが表示されます。パラメータには、機密情報が含まれる場合があることに注意してください。 |
| コール・スタックの表示 | このオプションを有効化した場合、Javaコール・スタックが表示されます。このオプションを有効化すると、パフォーマンスに影響する可能性があることに注意してください。 |
| Oracle SQL-IDの表示 | このオプションを有効化した場合、各問合せのSQL-IDが表示されます。これにより、データベース管理者によって実行される問合せを詳細に分析できます。 |
オブザーバは、次のログ・ファイルにエラーおよびデバッグ情報を書き込みます。
NanoAgentErrorTrace.log: 他のログ・ファイルに記録されたすべてのエラーおよび警告の出現が1回分のみ含まれています。各エラーおよび警告のエントリは、<Ref>要素内で一意の識別子で参照されます。たとえば、次のとおりです。
<Ref: Dq/QGNWqOmbdXPigC+vsO40eXgs=>
この識別子を使用して、他のログ・ファイル(通常NanoAgent.log)内のエラーまたは警告のすべての出現を検索できます。これは一般に、問題が発生したときに最初にチェックするログ・ファイルです。
このログ・ファイルのデフォルト・サイズは10MBで、サーバーの再起動のたびに再作成されます。ただし、デフォルトの切替えが2に設定されているため、前のログ・ファイルはサーバーの再起動後も保持されます。
NanoAgent.log: ランタイム・エラー、構成関連のエラーおよびデバッグ情報が含まれています(このロガーの設定は、オブザーバ通信ポリシーの「トレース・ロギングの有効化」オプションを使用して調整できます)。
NanoAgentPreprocessTrace.log: バイトコード・インスツルメンテーションのエラーとデバッグ、クラスロードおよび前処理に関する情報が含まれています。このファイルは、サーバーの再起動のたびに再生成されます。このログ・ファイルの最大サイズは10MBです。
リリース12.1.0.2.2では、このファイルの名前が変更されました。以前のリリースのオブザーバでは、ファイルはAWTrace.logという名前でした。
|
注意: また、監視対象メッセージをログに記録するようにオブザーバを構成することもできます。このトピックについては、12.1.2.11項「詳細設定フィールドのリファレンス」の「監視対象メッセージをファイルに記録」エントリを参照してください。 |
ログ・ファイルのデフォルトの場所は次のとおりです。
WebLogic: domain_root_directory/nanoagent/logs/server_nameディレクトリ(このディレクトリを特定できない場合、デフォルトではドメイン・ルート・ディレクトリに設定されます)
OC4J: SOA Suiteインストール・ディレクトリ内のj2ee\homeディレクトリ
Enterprise Gateway: Enterprise Gatewayサーバーのホーム・ディレクトリ(最上位のインストール・ディレクトリ)。
WebSphere: プロファイル・ディレクトリ
JBoss: JBOSS_HOME/binディレクトリ
WCFおよびASP.NET: C:/temp/NanoAgentBaseDirディレクトリ
|
注意: WCFおよびASP.NETのデフォルトのログの場所は実際のデフォルトではありません。単にAmberPoint:NanoLogBaseDirキーのデフォルトの設定にすぎません。このキーをnullに設定した場合、ログ・ファイルは作成されません。 |
別のディレクトリにログ・ファイルを生成する場合は、AP_NANO_LOG_BASEDIRというJavaプロパティまたはAmberPoint:NanoLogBaseDirというWindowsキーを設定します。Javaアプリケーション・サーバーの場合、このプロパティを絶対パスまたはデフォルトのログ・ディレクトリを基準にしたパスに設定できます。Enterprise Gateway、WCFおよびASP.NETの場合、このプロパティまたはキーを絶対パスに設定する必要があります。次の例は、このプロパティまたはキーの設定方法を示しています。
WebLogicでは、ローカル・スクリプトを編集してサーバーを構成する場合、WL_HOME/nanoagent/binディレクトリにあるnanoEnvWeblogicスクリプトを編集します。ファイルのオプションのセクションでは、-DAP_NANO_LOG_BASEDIR="my_log_dir"をNANOAGENT_JAVA_OPTIONSの最後に追加します。この相対パスにより、ドメイン・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。
ノード・マネージャを使用してWebLogicサーバーを構成する場合は、WebLogic管理コンソールを開き、サーバーを選択し、構成/サーバー起動タブを表示します。次に、-DAP_NANO_LOG_BASEDIR=my_log_dirを「引数」フィールドに追加します。この相対パスにより、ドメイン・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。
OC4Jで、-DAP_NANO_LOG_BASEDIR=my_log_dirをJava起動オプションに追加します。この相対パスにより、SOA Suiteインストール・ディレクトリ内のj2ee\homeディレクトリにあるmy_log_dirディレクトリにログ・ファイルが生成されます。
Enterprise Gatewayで、OEG_HOME/system/conf/jvm.xmlをテキスト・エディタで開き、<SystemProperty name="AP_NANO_LOG_BASEDIR" value="C:\OEG\my_log_dir"/>を<JVMSettings>要素の子として追加します。この絶対パスにより、C:\OEG\my_log_dirディレクトリにログ・ファイルが生成されます。
WebSphereのWebSphere管理コンソールで、「Servers」→「Application servers」→「server1」→「Server Infrastructure」→「Java and Process Management」→「Process Definition」→「Java Virtual Machine」→「Custom Properties」に移動します(server1を別のサーバー名に置き換えることが必要になる場合があります)。AP_NANO_LOG_BASEDIRという名前でカスタム・プロパティを作成し、その値をmy_log_dirに設定します。この相対パスにより、プロファイル・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。
JBossで、サーバー起動スクリプトJBOSS_HOME/bin/runを編集します。ファイルのオプションのセクションで、set JAVA_OPTS=-DAP_NANO_LOG_BASEDIR="my_log_dir"を追加します。この相対パスにより、JBOSS_HOME/bin/my_log_dirディレクトリにログ・ファイルが生成されます。
WCFまたはASP.NETの場合、アプリケーション構成ファイル(たとえば、Web.config)を編集し、AmberPoint:NanoLogBaseDirキーの値をC:/Inetpub/wwwroot/my_log_dirに設定します。この絶対パスにより、デフォルトのWebサイト・ディレクトリのmy_log_dirディレクトリにログ・ファイルが生成されます。たとえば、次のとおりです。
<configuration>
<configSections>
...
</configSections>
<AmberPoint>
<NanoAgentDataSection>
<add key="AmberPoint:NanoConfig" value="c:/temp/NanoAgentLogBaseDir/nanoagentDiscovery.CONFIGURATION"/>
<add key="AmberPoint:NanoLogBaseDir" value="c:/Inetpub/wwwroot/my_log_dir"/>
<add key="AmberPoint:NanoCreateLogBaseDir" value="false"/>
</NanoAgentDataSection>
</AmberPoint>
<system.web>
...
</system.web>
</configuration>
オブザーバがログ・ファイルを生成するために、オブザーバを実行中のユーザーがログ・ディレクトリに書き込む権限を持っていることを確認します。Javaオブザーバの場合、ユーザーはアプリケーション・サーバーを実行しているユーザーです。IISオブザーバ(WCFおよびASP.NET)の場合、ユーザーは次のとおりです。
IIS 5.x: オブザーバのユーザーはASPNETです。
IIS 6.xおよび7.x: オブザーバのユーザーはNETWORK SERVICEです。
デフォルトでは、AP_NANO_LOG_BASEDIRプロパティで指定されているディレクトリは、存在しない場合、自動的に作成されます。このディレクトリを自動的に作成しないようにする場合は、AP_NANO_CREATE_LOG_BASEDIRプロパティをfalseに設定します。この場合、ディレクトリを自分で作成する必要があります。AP_NANO_LOG_BASEDIRの場合と同じようにこのプロパティを設定します。
|
注意: Javaアプリケーション・サーバーの場合: ログ・ディレクトリが存在せず、AP_NANO_CREATE_LOG_BASEDIRがfalseに設定されている場合、ランタイム・エラーが発生し、オブザーバが初期化されないことがあります。IISの場合: NanoLogBaseDirというWindowsキーがnullに設定されている場合、ログ・ファイルは作成されません。 |
この項では、Business Transaction Managementの永続的データの管理に役立つ情報を提供します。この項の内容は次のとおりです。
Business Transaction Managementをインストールしたときに、Oracle Databaseを使用するように構成しました。データベースへのアクセスに使用される資格証明が変更された場合は、それに関連付けられた設定をBusiness Transaction Managementで適宜変更する必要があります。
データベース資格証明設定を変更するには:
「管理」→「データベース設定の編集」を選択します。
「データベース設定の編集」ツールが開きます。このツールを使用すると、Business Transaction Managementの一元的サービスで使用されているユーザー名およびパスワードを設定して、Business Transaction Managementデータベースにアクセスできます。
|
注意: 「組込みデータベース」オプションは選択しないでください。3つすべてのデータベースで「外部データベース」オプションが選択されています。 |
各データベースに応じてユーザー名およびパスワードを編集します。
「適用」をクリックします。
トランザクションに対してメッセージ・ロギングを有効にする場合は、メッセージをログに記録するモニター用にデータベースを設定する必要があります。Business Transaction Managementのインストールおよび初期構成時に、メッセージ・ログ・データベース(messageLogDB)を作成し、このデータベースの接続設定を指定しました。これらの接続設定は、デフォルト・メッセージ・ログ・データベース・ポリシーに自動的に格納され、すべてのモニターに適用されました。
ただし、メッセージ・ロギングに単一のデータベースを使用するという制限はありません。追加のデータベースを作成し、データベースごとに使用するモニターが異なるように構成できます。このためにはまず、別のデータベースにログを記録するモニターにはポリシーが適用されなくなるように、デフォルト・ポリシーの「基準」セクションを編集します。次に、新しいデータベースごとに新しいポリシーを作成し、各ポリシーの「基準」セクションを使用してポリシーを適切なモニターに適用します。モニターごとに1つのポリシーのみが適用されることに注意する必要があります。メッセージ・ログ・データベースの作成方法については、『Business Transaction Managementインストレーション・ガイド』を参照してください。
いずれかのメッセージ・ログ・データベースの場所またはログオン資格証明を変更した場合は、モニターがそのデータベースへの接続に使用する設定を再構成する必要があります。そのためには、適切なメッセージ・ログ・データベース・ポリシーを編集します。
既存のメッセージ・ログ・ポリシーが適用されるモニターを表示するには:
ナビゲータで、「管理」→「システム・ポリシー」を選択します。
メイン領域でポリシーを選択します。
「ターゲット」タブをクリックします。
新しいメッセージ・ログ・データベースを編集または適用するには:
メッセージ・ログ・データベース用に使用するOracle Databaseインスタンスを作成または特定します。
データベース接続の構成に使用するメッセージ・ログ・データベース・ポリシーを開きます。
デフォルトのメッセージ・ログ・データベース・ポリシーを編集する場合は:
ナビゲータで、「管理」→「システム・ポリシー」を選択します。
メイン領域で「デフォルト・メッセージ・ロギング・データベース・ポリシー」を選択します。
「変更」→「定義の編集: デフォルト・メッセージ・ロギング・データベース・ポリシー」を選択します。
新しいメッセージ・ログ・データベース・ポリシーを適用する場合は、「管理」→「システム・ポリシーの作成」→「メッセージ・ログ・データベース」を選択します。
メッセージ・ログ・データベースの作成ポリシーが開きます。
「データベース・タイプ」が「外部のOracleデータベースを使用」に設定されていることを確認します。
Business Transaction Managementの一元的サービスからメッセージ・ログ・データベースに直接アクセスできるようにする場合は、「一元的アクセスの許可」オプションが有効になっていることを確認します。
このオプションが無効になっている場合、一元的サービスはモニターを介してのみメッセージ・ログ・データベースにアクセスできます。
一部の一元的サービス(トランザクション監視コンポーネントなど)では、メッセージ・ログ・データベースに格納されているメッセージ・コンテンツへのアクセスが必要になります。このような一元的サービスは、モニター経由または直接接続でデータベースにアクセスできます。直接接続を使用すると、メッセージ・ログ問合せのパフォーマンスが向上します。この通信チャネルは、可能な場合には有効にしてください。
デプロイメント・シナリオによっては、一元的サービスからデータベースに直接問い合せず、かわりにモニターがその問合せを行うようにすることをお薦めします。このような事例の1つが、モニターおよびデータベースが一元的サービスからファイアウォールで保護されている場合です。このようなシナリオでは、一元的サービスはモニターとは通信できますが、データベースとは通信できない可能性があります。
データベースにアクセスするための接続文字列およびユーザー資格証明を指定します。
指定した資格証明を持つユーザーは、表および索引を作成および削除する権限を持っている必要があります。
必要に応じて「最大トランザクション・メトリック行数」を調整します。
当初、これはデフォルト設定のままである可能性があります。
このフィールドには、一時表に記録する行の最大数を指定します。一時表は、トランザクション測定の集計を計算する前に個々のトランザクション開始/終了メッセージを追跡するために使用されます。この値を大きくすると、パフォーマンス・サーバーがトランザクション測定をより効率的に処理できるようになりますが、メッセージ・ログ・データベースによるディスク使用量が増加するというデメリットがあります。
「拡張オプションの表示」チェック・ボックスを有効にして、拡張オプションを編集できます。
次の表では、拡張オプションについて説明します。
| 拡張オプション | UIのデフォルト設定 | 説明 |
|---|---|---|
| インデクサ・チューニング・パラメータ | - | - |
| 自動統計を使用 | 有効 | ブール
このパラメータが有効になっている場合、モニターはデータベースからデータベース統計を定期的に収集します。メッセージ・ログ問合せを効率よく実行するには、最新のデータベース統計を維持する必要があります。統計は、これまでに行われたデータベースへの挿入の数に基づいて収集されます。 |
| ログ・バンドル読取りバッチ・サイズ | 300 | 整数
単一のデータベース・トランザクションのインデクサによって処理されるメッセージの数を決定します。 |
| インデクサ再開間隔 | 10 | 整数 - 時間(秒単位)
インデクサがウェイクアップして差し迫った作業がないかどうかをチェックする頻度を決定します。 |
| クリーンなデータベース・チェック間隔 | 120 | 整数 - 時間(秒単位)
インデクサが様々なメンテナンス・タスクを実行する間隔を決定します。メンテナンスを実行するとき、インデクサは次のことを行います。
|
| クリーンなカーソル・チェック間隔 | 3600 | 整数 - 時間(秒単位)
インデクサがデータベースから期限切れの問合せ結果を削除する間隔を決定します。 このタスクはインデクサの通常のメンテナンスの一部ですが、これは他のタスクよりも頻繁に行うことが必要になる場合があります。 |
| 索引付けの停止 | 無効 | ブール
trueに設定すると、このオプションはすべてのアクティビティを一時停止するようにインデクサに指示します。索引付けされるコンテンツは引き続きアクティブなロギング・ポリシーによって取得されますが、索引付けが再開されるまでディスク上の記憶域からデータベースに転送されません。 このオプションは、特に大量のメッセージ・トラフィックが発生している場合に便利です。この場合、リソースの最適化およびトラフィックの安定した流れの方が、索引付けされたメッセージを検査できることよりも重要です。後で「索引付けの停止」の値をfalseに設定すると、Business Transaction Managementではメッセージを索引付けしてデータベースに入力できるようになります。 注意: インデクサが一時停止している間、Business Transaction Managementでは使用中のディスク領域を管理するための作業が行われません。ロギング・ポリシーによってログに記録されているメッセージを取得するために十分な空のディスク領域があることを確認します。 |
| データベース・エラー最小遅延 | 10 | 整数 - 時間(秒単位)
データベース・エラーの発生時にロギング関連のデータベース操作を再試行するまでに、インデクサが待機する最小時間を指定します。以後の各障害では、現在の遅延に「データベース・エラー遅延拡張要因」パラメータの値を乗算することにより、遅延が伸びる方向で調整されます。再試行間の最大待機時間は、「データベース・エラー最大遅延」によって制限されています。 このパラメータが適用されるデータベース・エラーの一例は、モニターがデータベースに問い合せることができなくなることです。たとえば、デフォルト設定では、モニターはデータベースへの接続を失うと10秒後に再接続を試みます。再接続できないと、20秒待機してから再度試みます(以降同様)。試行間の最長待機時間は3600秒(1時間)です。 |
| データベース・エラー最大遅延 | 3600 | 整数 - 時間(秒単位)
「データベース・エラー最小遅延」の説明を参照してください。 |
| データベース・エラー遅延拡張要因 | 2.0 | 「データベース・エラー最小遅延」の説明を参照してください。 |
| バンドル実行ごとに索引付けされる最大メッセージ数 | 5000 | 整数
各インデクサ実行で特定のエンドポイントに対して索引付けするメッセージの最大数を制限します。単一のモニターのすべてのエンドポイントは、単一のワーカーによって索引付けされます。 |
| インデクサ問合せの最大実行時間 | 300 | 長整数 - 時間(秒単位)
インデクサが開始する問合せの実行時間に対する時間制限の上限を指定します。 |
| 問合せの最大実行時間 | 30 | 長整数 - 時間(秒単位)
ユーザーが開始する問合せの実行時間に対する時間制限の上限を指定します。ユーザーは、メッセージ・ログに対して長時間実行の問合せを開始する場合があります。いったん送信されると、ユーザーには問合せを取り消す方法はなく、完了するまで待機する必要があります。 このパラメータのデフォルト値は30秒です。この値を0に設定すると、複雑さに関係なくすべての問合せが完了まで実行されます。そのため、この設定(0)はお薦めしません。 |
| インデクサ・ワーカー・スレッド数 | 3 | 長整数
ログ・ポリシー・インデクサで使用されているワーカー・スレッドの数を指定します。インデクサは、ロギング・ポリシーが適用されたエンドポイントを循環し、各エンドポイントを順に索引付けします。スレッドを追加すると、さらに多くのエンドポイントを同時に索引付けできます。 |
| メタデータ挿入バッチ・サイズ | 300 | 長整数
メタデータ挿入文を制御します。このパラメータには、SQL文を実行する前にバッチにまとめる特定のタイプの行数を指定します。実際のバッチ・サイズは、「ログ・バンドル読取りバッチ・サイズ」パラメータの影響も受けます。このパラメータによって最大トランザクション・サイズが設定されるためです。 |
| メッセージ挿入バッチ・サイズ | 30 | 長整数
メッセージ挿入文を制御します。このパラメータには、SQL文を実行する前にバッチにまとめる特定のタイプの行数を指定します。実際のバッチ・サイズは、「ログ・バンドル読取りバッチ・サイズ」パラメータの影響も受けます。このパラメータによって最大トランザクション・サイズが設定されるためです。 |
| ユーザー問合せ接続数 | 5 | 長整数
ユーザー問合せの目的で確立する必要があるメッセージ・ログ・データベースへの接続の数を指定します。プールは共有プールであり、システム処理用に確立される接続(「インデクサ・ワーカー・スレッド数」によって制御されます)およびユーザー問合せ用の接続(「ユーザー問合せ接続数」によって制御されます)で構成されています。 |
| 表の再利用 | 無効 | ブール
「メッセージ履歴」ポリシーの「切替え間隔」設定によって、メッセージがデータベースに保持される期間が制御されます。デフォルトでは、メッセージは表の削除によって削除され、表の追加によって追加されます。新しい表を削除および作成するのではなく表を再利用する場合は、この設定を有効にします。表は、再利用される前にクリアされます。ほとんどのシナリオでは、この設定を無効のままにした方が効率的です。 |
| フラグメント当たりの最小エントリ | 0 | 長整数
メッセージは、フラグメントと呼ばれる一連の表に格納されます。この設定では、切替え前にフラグメントが保持している必要があるメッセージの最小数を指定します。この制約は、「メッセージ履歴」ポリシーの「切替え間隔」設定の制約を補足するものです。注意: リクエスト/レスポンスのペアは、2つのメッセージであるとみなされます。 |
| インデクサ設定データ・バージョン | - | - |
| label.IndexerSetupData.generateEndpointStatistics | 無効 | 一般に、このフィールドを有効にするのは、Oracleサポートからそうするように求められた場合のみです。
モニターがトランザクションに参加するエンドポイントを管理中である場合、モニターはロギング目的でメッセージ・インデクサ(アウト・オブ・バンド・インデクサ)を実行することになります。メッセージ・インデクサがモニターで実行中である場合、モニターの「ステータス」タブにはメッセージ・インデクサのパフォーマンスに関する情報が含まれています。デフォルトでは、このタブにはメッセージの索引付けがアクティブなすべてのエンドポイントについてサマリー・インデクサ統計が表示されます。この設定を有効にすると、タブのインデクサ統計にはメッセージの索引付けに参加しているエンドポイントごとに詳細なパフォーマンス情報が含まれます。 |
「基準」セクションで、データベースにログを記録するモニターを選択します。
|
注意: 単一のモニターに複数のメッセージ・ログ・データベース・ポリシーを適用しないように注意してください。つまり、新しいメッセージ・ログ・データベース・ポリシーを適用している場合は、まず新しいポリシーと同じモニターに適用されないように既存のポリシーの「基準」セクションを編集する必要があります。単一のモニターに複数のメッセージ・ログ・データベース・ポリシーを適用した場合は、Business Transaction Managementによってシステム・アラートが生成されます。モニター・グループのすべてのモニターが同じメッセージ・ログ・データベースにログを記録する必要があります。 |
「適用」をクリックします。
初期起動時に、Business Transaction Managementはシステム出力ログ・エントリを収集し、システム・デプロイメント用にユーザー・プリファレンスを格納するために一連の永続記憶域ディレクトリを作成します。デフォルトでは、永続記憶域ディレクトリはWL_install_dir/user_projects/domains/domain_name/servers/server_name/btmstorage/*にあるアプリケーション・サーバーのインストール・ディレクトリ内に作成されます。
永続記憶域に関する社内の手順およびルールにより、これとは異なる場所に永続記憶域ディレクトリを配置することが必要になる場合があります。このような場合、永続記憶域ディレクトリの場所を再構成できます。
インストールされたBusiness Transaction Managementシステムは一連のデプロイメント(EARファイル)で構成され、このデプロイメント自体はサブデプロイメント(WARファイル)で構成されています。各サブデプロイメントには、.warを除いた同じ名前の永続記憶域ディレクトリが関連付けられています。次の表に、デプロイメント、サブデプロイメントおよび永続記憶域ディレクトリの名前を示します。
表12-2 Business Transaction Managementのデプロイメント、サブデプロイメントおよび永続記憶域ディレクトリ
| デプロイメント(EAR) | サブデプロイメント(WAR) | 永続記憶域ディレクトリ |
|---|---|---|
|
btmMain |
btmui btmcentral btmcontainer |
btmui btmcentral btmcontainer |
|
btmPerformanceServer |
btmcontainer btmperformance |
btmcontainer btmperformance |
|
btmTransactionServer |
btmcontainer btmtransaction |
btmcontainer btmtransaction |
|
btmMonitor |
btmmonitor |
btmmonitor |
このトピックでは、Business Transaction Managementデプロイメント用永続記憶域ディレクトリのデフォルトの場所を、これらのデプロイメントをホストするコンテナの外側にある場所に変更する方法について説明します。
このトピックには次の各項が含まれており、永続記憶域ディレクトリの再配置に必要な手順を説明します。
永続記憶域ディレクトリの場所を再配置するための手順に従う前に、コンテナのデフォルトの場所にすでに存在する永続記憶域ディレクトリをバックアップすることが非常に重要です。これらのデフォルトの永続記憶域ディレクトリは、初めてBusiness Transaction Managementデプロイメントを起動すると作成され、各コンテナの下にあるセクションにリストされます。後でこれらのディレクトリのコンテンツを各デプロイメントの永続記憶域ディレクトリ用に定義した新しい場所にコピーする必要があります。
既存の永続記憶域ディレクトリのバックアップおよび削除を行わない場合、次回Business Transaction Managementを再起動したときに、新しい永続記憶域ディレクトリの設定がロードされず、使用されないことがあります。デフォルトでは、Business Transaction Managementはデプロイメントの永続記憶域ディレクトリのデフォルトの場所を参照します。新しい場所を設定した後も引き続きデフォルトのディレクトリが存在する場合、新しい場所が認識されない可能性があります。これらの記憶域ディレクトリ内には、ユーザー・プリファレンスも含まれています。Business Transaction Managementは、再起動のたびにこれらのユーザー・プリファレンス・ファイルを読み取ります。
永続記憶域ディレクトリのデフォルトの場所はWAS_install_dir/profiles/profile_name_name/btmstorage/node_name/server_name/*です。
永続記憶域ディレクトリの再配置場所を文書化しておく必要があります。Business Transaction Managementアプリケーションを再デプロイする場合(たとえば、アップグレード時)には、その場所を再度定義する必要があるためです。LogMergerツールを使用して新しい永続記憶域ディレクトリの場所からシステム・ログ・メッセージを収集してその出力をマージする場合は、これらの場所を文書化することも重要です。最も簡単なのは、LogMergerツール用の構成ファイルを作成することです。このファイルは、新しい永続記憶域ディレクトリの場所のドキュメント・ソースとしても機能するためです。LogMergerツールおよびこのツール用の構成ファイルの作成方法の詳細は、11.3項「logMergerユーティリティ」を参照してください。
次の手順では、永続記憶域ディレクトリを再配置するための一般的な手順について説明します。
Business Transaction Managementデプロイメントを停止します。
永続記憶域ディレクトリをバックアップし、安全な場所に配置します。
各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を変更します。
永続記憶域ディレクトリのバックアップ・コピーを新しい永続記憶域ディレクトリの場所に移動します。
|
注意: すでに永続記憶域ディレクトリに収集した情報を新しい場所で使用する予定がない場合は、元の記憶域ディレクトリと同じ名前を使用して新しい場所に空の永続記憶域ディレクトリを作成する必要があります。 |
必要に応じて、永続記憶域ディレクトリを再配置する各デプロイメントをパッケージ化して再デプロイします。
デプロイメントを再起動します。
新しい場所で新しいシステム出力ログ(logdir)エントリを確認します。
Business Transaction Managementデプロイメントは、次のディレクトリの場所にあります。各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を編集するためには、これらのデプロイメントの場所を確認する必要があります。
WL_install_dir/user_projects/domains/domain_name/server_name/ .wlnotdelete/extract/server_name_n_n/public/btmstorage/*
たとえば、btmcentralデプロイメントは次のディレクトリにあります。
WL_install_dir/user_projects/domains/domain_name/server_name/ .wlnotdelete/extract/server_name_btmcentral_btmcentral/public/btmstorage/btmcentral
永続記憶域ディレクトリを再配置するには:
Business Transaction Managementデプロイメントを停止します。
現在のデフォルトの永続記憶域ディレクトリにあるコンテンツをバックアップし、安全な場所に配置します。
各デプロイメントのweb.xmlファイルで永続記憶域ディレクトリの場所を変更します。
記憶域ディレクトリを変更するデプロイメントの展開済warファイルがある場所を特定します。
展開済warファイルから、テキスト・エディタまたはXMLエディタでデプロイメントのWEB-INF/web.xmlファイルを開きます。
そのデプロイメントのstorageDirectoryパラメータ値を次のように設定して、永続記憶域ディレクトリの新しい場所を設定します。
次の行のAmberPointDefault値を編集して、新しい記憶域ディレクトリの場所に設定します。
<!-- PERSISTENT STORAGE DIRECTORY To set the persistent storage area to some value, change the value of param-value to some EXISTING directory where you want things stored. --> <context-param> <param-name>com.amberpoint.storageDirectory</param-name> <param-value>AmberPointDefault</param-value> </context-param>
|
注意: 永続記憶域ディレクトリの名前は変更しないでください。ディレクトリへのパスのみが変更可能です。 |
例:
Windowsシステムの場合: btmcentralの永続記憶域ディレクトリをC:\btm_data\btmcentralに配置する場合は、btmcentral web.xmlファイル内のデフォルト・エントリを次のように変更します。
<context-param> <param-name>com.amberpoint.storageDirectory</param-name> <param-value>C:\btm_data\btmcentral</param-value> </context-param>
UNIX系システムの場合: btmcentralの永続記憶域ディレクトリをopt/webserviceapplogs/btm_data/btmcentralに配置する場合は、btmcentral web.xmlファイル内のデフォルト・エントリを次のように変更します。
<context-param> <param-name>com.amberpoint.storageDirectory</param-name> <param-value>/opt/webserviceapplogs/btm_data/btmcentral</param-value> </context-param>
新しい場所に新しい空の永続記憶域ディレクトリを作成するか(最初から始める場合)、または元の永続記憶域ディレクトリのバックアップ・コピーを新しいディレクトリの場所に移動します。
必要に応じて、永続記憶域ディレクトリを再配置する各デプロイメントを次のようにアンデプロイしてから再デプロイします。
|
注意: システム・デプロイメントを再パッケージ化するときは、デプロイメントに関連付けられたマニフェスト・ファイルを必ず含めてください。このファイルにはデプロイメントに必要な重要な情報が含まれているためです。 |
編集したweb.xmlファイルが含まれている新しいデプロイメントを新しいアプリケーションのwarファイルにパッケージ化します。
WebLogic Consoleを使用して既存のデプロイメントをアンデプロイします。
WebLogicサーバーを停止し、元の永続記憶域ディレクトリを削除します。
|
注意: デフォルトの場所から永続記憶域ディレクトリを削除する必要があります。デプロイメントは、デフォルトの場所で永続記憶域ディレクトリを検出すると、新しいディレクトリの場所を無視します。 |
WebLogicを再起動し、WebLogic Consoleを使用して新しいシステム・デプロイメントを再デプロイします。
デプロイメントを再起動します。
新しい場所で新しいシステム出力ログ(logdir)エントリを確認します。
この時点で、各デプロイメントのweb.xmlファイルに定義した永続記憶域ディレクトリの場所にデータが書き込まれます。コンテナの起動時に、新しいシステム・サービス・ログ・ファイル(logdir)とその他のディレクトリが新しい場所に作成されたことを確認します。
logMergerツールを使用してシステム・サービス・ログをマージする場合は、ログ・ファイルをマージするときに新しい永続記憶域ディレクトリの場所を参照する必要があります。
この項では、Business Transaction Managementシステムのセキュリティの管理に役立つ情報を提供します。この項の内容は次のとおりです。
Business Transaction Managementは、認証およびユーザーへのロールの関連付け用にデプロイされているWebLogicサーバーを利用します。デフォルトでは、認証は管理コンソールに対して有効です。認証を無効にするには、現在使用中のアプリケーション・サーバーに適した任意のツールまたはプロシージャを使用します。
|
注意: 管理コンソールにログインするには、btmAdmin、btmUser、btmObserverのBusiness Transaction Managementユーザー・ロールの1つ以上にマップされている資格証明を使用する必要があります。 |
認証を無効にした場合も、引き続き管理コンソールのユーザーがログインする必要があります。ただし、任意のユーザー名を使用してログイン可能であり、パスワードを指定する必要はありません。ナビゲータ、フィルタ、列セットに対する編集などすべてのUIパーソナライズは、プリファレンスとして格納され、ユーザー名に関連付けられることに注意してください。
このトピックでは、サポートされているアプリケーション・サーバーがどのようにユーザーを認証して、Business Transaction Managementアプリケーション・ロールにマップするかを説明します。
|
注意: ロールbtmInspectorはデフォルトではbtmInspectorsという名前のグループにマップされますが、アプリケーション・サーバー管理者はbtmInspectorsという名前のグループを作成し、そのグループを適切なユーザーに割り当てる必要があります。 |
Business Transaction Managementは、ロールを使用してユーザー・インタフェースの様々な部分へのアクセスを認可します。
各ユーザーには、1つ以上のプライマリ・ロールを割り当てる必要があります。プライマリ・ロールは次のとおりです。
btmAdmin: このロールを持つユーザーには、すべての権限が付与されます。このようなユーザーは、機密プロパティの表示と作成、すべてのメッセージ・コンテンツの表示など、Business Transaction Managementコンソールが備えるすべてのツールおよび機能を使用できます。
btmUser: このロールを持つユーザーは、基本的な監視の構成に必要なほとんどの権限を持っています。たとえば、モニターの構成、ポリシー(システム・ポリシーを除く)の作成、編集および削除、サービスの登録、サービスおよびエンドポイントに関するレジストリ属性の設定、トランザクションおよび条件の作成と編集などが可能です。また、btmObserverのすべての権限も持っています。このロールでは、Business Transaction Management環境の変更、メッセージ・コンテンツへのアクセスまたは機密プロパティの表示と編集に必要な権限は付与されません。
btmObserver: このロールを持つユーザーは、基本的な監視機能のほとんどを使用するための権限を持っています。監視システムに関するサマリー、依存性および管理情報を表示することはできますが、監視システムに関連するポリシーおよび設定を構成することはできません。また、トランザクションおよび条件を表示することはできますが、作成および編集することはできません。このロールでは、ユーザーはBusiness Transaction Management環境の変更、メッセージ・コンテンツへのアクセスまたは機密プロパティの表示と編集は許可されません。
|
注意: 管理コンソールでのすべての移動および表示は、すべてのプライマリ・ロールで可能です。ただし、ロールによっては特定のメニューとメニュー項目、およびそれらに関連付けられたツールにアクセスできません。 |
プライマリ・ロールの他、Business Transaction Managementには補助ロールが定義されています。補助ロールにより、特定のユーザーに割当て可能な追加の権限が提供されます。たとえば、あるユーザーにメッセージ・コンテンツへのアクセスは許可するものの、フル管理権限は付与しない場合があります。これを実現するために、ユーザーにbtmUserのプライマリ・ロールおよびbtmInspectorの補助ロールを割り当てることができます。補助ロールは次のとおりです。
btmInspector: このロールを持つユーザーは、メッセージ・コンテンツを表示し、プロパティ(機密プロパティを含む)を表示および作成できます。
|
注意: btmAdminロールは、btmInspectorのすべての権限を持っています。 |
次の各項では、システムのバックアップとリストアの方法について説明します。トピックは次のとおりです。
Oracle Business Transaction Managementは、大量のデータを格納します。このデータは、システムの構成、現在監視中の対象、および監視対象アプリケーションの現在と過去の状態に関するものです。このデータのいずれもシステムの運用に必要です。なんらかの事態が発生してこのデータが消失または破損した場合、システムは想定どおりに実行できなくなります。このような理由から、システムのデータのバックアップを作成し、このデータをリカバリできることが重要です。
次の様々な理由でBusiness Transaction Managementをバックアップすることが必要になります。
予期しない出来事からのリカバリを可能にする定期的なバックアップ
新しいスフィアに移行する前
Business Transaction Management環境でアプリケーション・サーバーをアップグレードする前またはアプリケーション・サーバーを追加する前
新しいバージョンのBusiness Transaction Managementをインストールする前
この項では、バックアップおよびリカバリの一般的なガイドラインを示し、定義した処理をテストするためのマイルストンを提案します。データをバックアップしてチェックポイントを作成する頻度は、アプリケーションのライフサイクル・ステージおよびビジネス要件に全面的に依存します。
Business Transaction Managementのバックアップおよびリストアには、ホストしているアプリケーション・サーバーとその構成設定のバックアップおよびリカバリは含まれていません。含まれていないものには、JVM設定やJavaシステム・プロパティなど、Business Transaction Managementが正しく機能するために必要なものもあります。アプリケーション・サーバーとその構成をバックアップするための処理はすでに用意されています。
Business Transaction Managementは複雑な環境で動作します。そのため、バックアップする前に、Business Transaction Managementコンポーネントを分離できることと、バックアップ手順とリカバリ手順の影響を受ける可能性がある他のシステムを特定できることを確認することが重要です。次のような問題について検討します。
データベースがBusiness Transaction Management以外のコンポーネントと共有されている場合があります。問題がデータベース自体の障害である場合を除き、Business Transaction Managementで使用されるデータベース・インスタンスのみをリストアすることが重要です。
リカバリは他のシステムに影響を及ぼす可能性があります。たとえば、Business Transaction Managementが他のアプリケーションとJDBCドライバを共有している場合、リカバリによってドライバが以前のバージョンにリストアされ、それが原因でそのドライバを使用している他のアプリケーションで障害が発生することがあります。
リカバリを試し、他の問題を発生させることなくシステムを目的の状態に戻すことができることを確認することにより、バックアップ手順を定期的にテストしてください。バックアップ手順に関する問題を特定して解決することにより、リカバリが重要になったときにリカバリを正常に完了できるようになります。バックアップ検証チェックリストには、次の事項を含めてください。
データベースとファイル・システムの構造、および権限が想定どおりであること
Business Transaction Managementが機能し、想定どおりの状態であること(コンソールにすべてが順調であり、サービスにアクセス可能であり、トラフィックが正常に流れていることなどが表示される)
同じリソースを共有するどのアプリケーションも悪影響を受けていないこと
この項では、Business Transaction Managementデータの編成方法、各タイプのデータのバックアップ方法およびバックアップに関連するタイミングの問題について説明します。
次の図に、多種多様なBusiness Transaction Managementデータおよびこのデータを利用するBusiness Transaction Managementシステム・サービスを示します。
この図では、データのバックアップの基本原理は次のとおりです。
データベースに含まれているすべてのデータは、データベースのバックアップによってバックアップされます。
ファイルまたはディレクトリに含まれているすべてのデータは、btmstorageディレクトリのバックアップによってバックアップされます。このディレクトリは、Business Transaction Managementシステム・サービスまたは監視の1つがデプロイされているあらゆるホストに存在します。自分のサーバーでのこのディレクトリの場所は、12.4.2.2項「Business Transaction Managementデータのバックアップ」に指定されています。
この項では以降、前掲の図に示した要素について詳しく説明します。バックアップおよびリカバリを実行するのみの場合、このレベルまで詳しく知る必要はありません。しかし、この詳細はBusiness Transaction Managementで使用されているリソースのトラブルシューティングおよび理解に役立つ場合があります。必要に応じて、12.4.2.2項「Business Transaction Managementデータのバックアップ」までスキップできます。
図に示すように、Business Transaction Managementは複数のシステム・サービスで構成されています。
Business Transaction Managementの操作全体およびそのメンバー・サービスの調整を担当するスフィア
パフォーマンス測定の収集を担当するSLMサービス
トランザクション管理を担当するExMサービス
オブザーバからのデータの収集を担当するモニター・エージェント
これらの各サービスは、システムの構成を指定し、現在監視中の対象を表し、監視対象アプリケーションの状態を記録するというデータに依存しています。このデータは、図に示された3つのカテゴリにグループ化できます。
定義メタデータは2か所に格納され、次の情報が含まれています。
スフィア・データベースには、Business Transaction Managementと監視対象ユーザー・システムを説明するデータが含まれています。それには、ユーザーのアプリケーション、その監視に使用されるポリシー、トランザクション定義の説明などが含まれています。
モニター・エージェント構成ファイルには、各ユーザー・エンドポイントが監視中かどうか、およびその方法について説明するデータが含まれています。
操作データはBusiness Transaction Managementがユーザー・アプリケーションについて収集する情報で、パフォーマンスと行動のメトリック、ログ・メッセージ、トランザクション・インスタンスおよび生成されたアラートがあります。この情報は図に示された測定、トランザクション、エージェント・メッセージ・ログの各データベースに格納されます。
システム構成データはBusiness Transaction Managementの基本的な動作を制御するものであり、接続先のデータベース、コンテナがスフィアへの接続に使用するアドレス、デフォルトのGUI表示とレイアウトがあります。この情報は、初期構成データ、GUIカスタマイズ、設定データ、コンテナ登録、その他の構成ファイルなど様々な構成ファイルに保存されます。
Business Transaction Managementのバックアップは非常に簡単です。データベースに含まれているデータをバックアップするには、それぞれのデータベースをバックアップします。ファイルまたはディレクトリに含まれているデータをバックアップするには、btmstorageディレクトリをバックアップします。
btmstorageディレクトリは、Business Transaction Managementシステム・サービスまたは監視の1つが次の場所にデプロイされているあらゆるホストに存在します。
WebLogic_InstllDir/user_projects/domains/MyDomain/servers/MyServer/btmstorage
データベースおよびbtmstorageディレクトリのバックアップが終了すると、バックアップ処理は完了です。
一般に、データのサブセットのみが破損または消失した場合でも、すべてのデータをバックアップし、リカバリすることをお薦めします。ただし、Business Transaction Managementで使用されている個々のコンポーネントをさらに詳しく知りたい場合は、12.4.4項「データ記憶域のリファレンス」を参照してください。
Business Transaction Managementをリストアする目的は、他の問題を発生させることなく目的の状態に戻すことです。この処理を開始する前に、リストアしようとしているBusiness Transaction Managementシステムについて完全かつ正確な情報を持っていることを確認します。
Business Transaction Managementをバックアップ元と同じ環境にリストアするものと想定しています。異なる環境にリカバリする必要がある場合(たとえばハードウェア障害の場合)は、リストアするマシンのホスト名をその障害が発生したマシンのホスト名に(オペレーティング・システム・レベルで)変更する必要があります。また、新しいマシンにホストされているBusiness Transaction Managementサービスが古いマシンと同じポートで動作することを確認する必要もあります。その場合、サービスを中断することなく新しいマシンにリカバリできます。
リストア処理では、バックアップ処理によって作成された最後のチェックポイントにシステム全体がリカバリされます。
|
注意: リストア後、データベース・スキーマおよびファイル・システムにはバックアップ時点の状態が反映されている必要があります。これを確実にするため、リストアする前に、既存のデータベースおよび記憶域ディレクトリが完全にクリーンであることを確認してください。2つの記憶域の場所にあるデータは様々な方法で接続されるため、どちらかがバックアップされたデータよりも新しいデータを保持していると、問題が発生することがあります。このため、既存のbtmstorageディレクトリにバックアップをリストアしないでください。ほとんどのデータベース・リストアはこの問題に対処していますが、ご使用のデータベースも対処していることを確認してください。 |
リストア処理は、次の2つの手順で構成されています。
データベースをリストアします。
システム・サービスまたはモニターをホストする各サーバーにbtmstorageディレクトリをリストアします。
なんらかの原因でインストールしたインスタンスが損傷または破損したためにBusiness Transaction Managementソフトウェア自体に損傷がある場合は、次の手順を実行することをお薦めします。
Business Transaction Managementソフトウェアを再インストールします。
システム・サービスまたはモニター・エージェントをホストする各サーバーにbtmstorageディレクトリをリストアします。
データベースをリストアします。
|
注意: 損傷がEAR、WARまたはJARファイル自体にのみ影響を及ぼす場合、必要なのはBusiness Transaction Managementソフトウェアの簡単な再インストールを実行することのみです。 |
次の表に、Business Transaction Managementコンポーネントに関する追加の詳細を示します。この詳細は、各コンポーネントの役割を理解する場合や、特定の情報を探す場合に役立ちます。
この項では、ある環境から別の環境にデータを移行するために必要な手順の概要を説明します。たとえば、テスト環境から本番環境に移行するときには、これを行うことが必要になる場合があります。
ある環境から別の環境にデータを移行するには、次の手順を実行します。
常に、データを移行する前にシステムをバックアップします。システムのバックアップについては、12.4項「Business Transaction Managementのバックアップおよびリストア」を参照してください。
次のように、CLIコマンドを使用してデータをエクスポートします。エクスポートの順序は重要ではありません。
exportProfileコマンドを使用して、プロパティ定義をエクスポートします。まだプロパティを定義していない場合は、これを行う必要はありません。
ビジネス・オブジェクトの自動作成を使用しない場合は、exportBusinessObjectsコマンドを使用してコンシューマ・データをエクスポートします。
新しい環境で使用するために停止時間スケジュールを作成した場合は、exportSchedulesコマンドを使用してそれらをエクスポートします。
exportPoliciesコマンドを使用して、ポリシー定義をエクスポートします。
必要な操作は、ユーザー定義のポリシーをエクスポートすることのみです。これはほとんどの場合SLAポリシーです。システム・ポリシーまたはトランザクション用に作成されたポリシーはエクスポートしないでください。システム・ポリシーは環境の構成に関連しており、新しい環境では異なる可能性があります。トランザクション用にシステムが生成したポリシーは、トランザクション定義をインポートすると自動的に再作成されます。
新しいBTM環境をインストールし、構成します。
新しいシステムでは、エクスポートしたトランザクションの作成に使用した本番環境のあらゆるものを監視できることを確認してください。トランザクションに含まれているサービスがわかっている場合は、BTMコンソールを使用して必要なサービスを探し、そのサービスがすでに監視対象になっていることを確認できます。
CLIコマンドを使用して、次に示す順序でデータをインポートします。
この時点でトランザクションは新しい環境で機能します。ある程度のトラフィックを実行して、トランザクション監視が想定どおりに機能していることを確認してください。
ロード・バランサを設定すると、Business Transaction Managementでトラフィックのフローを正しくモデル化し、Business Transaction Managementコンソールからロード・バランサの管理コンソールにアクセスできます。
この項では、F5デバイスを設定して、1つのオブザーバから複数のモニターにメッセージのロード・バランシングを行う方法について説明します。内容は、次のとおりです。
複数のコンテナにサービスをデプロイした場合、Business Transaction Managementはこれらのレプリケートされたエンドポイントが同じサービスの一部であると認識し、これらのレプリケートされたエンドポイントにメッセージをルーティングするロード・バランサの存在を推察できます。つまり、Business Transaction Managementはロード・バランサ自体ではトラフィックのフローを監視しない場合でも、依存性ダイアグラムでトラフィックのフローを正しくモデル化できます。ただし、ユーザーの助けがないと、Business Transaction Managementは推察したロード・バランサに関する詳細な情報を提供できません。ロード・バランサを設定すると、Business Transaction Managementに情報が提供されて次のことを実行できるようになります。
管理コンソールにロード・バランサに関する情報を提供します。たとえば、ロード・バランサの表示名やロード・バランサに関連付けられたベンダーなどです。
ロード・バランサをホストしているデバイスを識別します。
ロード・バランサの管理コンソールに容易にアクセスします。
ロード・バランサ・デバイスのライフサイクル・フェーズおよびそのデバイス内に作成されるすべてのエンドポイントを指定します。
ロード・バランサの設定は、その登録から始まります。ロード・バランサを登録するには、CLIコマンドregisterDeviceを使用するか、または管理コンソールを使用します。場合によっては、ロード・バランサへのエントリ・ポイントを指定し、メッセージのルーティング先に対応するターゲット・エントリ・ポイントを定義することが必要になる場合もあります。
この項では、ロード・バランシングに関連するいくつかの基本的な用語、Business Transaction Managementでサポートされているデバイス、さらに次のユーザー・タスクについて説明します。
ロード・バランサの登録
ロード・バランサに関する情報の変更
ルーティング関係を示すエントリ・ポイントの追加
ロード・バランサの登録解除
Business Transaction Managementでは、様々なロード・バランシング・デバイスがサポートされています。F5ロード・バランサに対して最大のサポートが提供されますが、他のハードウェア・ロード・バランサおよびソフトウェア・ロード・バランサを認識し、モデル化することもできます。
次の図に、ロード・バランサを使用してメッセージAおよびBを3つのレプリケート・エンドポイント(E1、E2、E3)にルーティングする様子を示します。マークされた要素、つまりルーティング・エントリ・ポイントとターゲット・エントリ・ポイントに注意してください。ロード・バランサは、ルーティング・エントリ・ポイントでメッセージを受信してターゲット・エントリ・ポイントに転送します。ロード・バランサを登録した後、次の項の説明に従ってエントリ・ポイント情報を指定することが必要になる場合があります。
Business Transaction Managementでは、F5デバイス、その他のハードウェア・デバイス、ソフトウェア・ロード・バランサの3種類のロード・バランサを操作できます。Business Transaction Managementでメッセージ・トラフィックのモデル化を行うために必要な作業は、個々の事例によって異なります。
Business Transaction Managementは、F5デバイスに関するほとんどの情報を認識しており、1つの登録手順のみで必要な情報を導出できます。Business Transaction Managementは、メッセージのルーティングにおけるF5のロールの全体像を示すために追加の検出パスを実行する場合があります。
ハードウェア・ロード・バランサの場合、Business Transaction Managementは通常、監視対象メッセージのHTTPホスト・ヘッダーの情報に基づいて自動的にルーティング・エントリ・ポイントを検出し、モデル化できます。ただし、デバイスを明示的に登録すると(CLIコマンドregisterDeviceまたは管理コンソールを使用)、Business Transaction Managementでデバイスの場所およびその他の属性に関する情報を表示できます。
どのデバイスも登録しない場合、Business Transaction Managementではデフォルトのロード・バランサを自動的に登録し、このデバイスによるメッセージの流れをモデル化できます。この場合も、デフォルトのロード・バランサの「プロファイル」ページを編集して名前、ベース・アドレス、管理UIおよびベンダーを指定できます。
監視対象メッセージがHTTPホスト・ヘッダーで元の受信者(ロード・バランサ)に関する情報を伝送しない場合は、次に説明するように、ソフトウェア・ロード・バランサの場合と同じくデバイスを登録し、ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを指定する必要があります。
バックエンド・サーバーへのHTTP接続を別途確立する(単にHTTPメッセージを転送するのではなく)ソフトウェアによって実装されたロード・バランサの場合、Business Transaction Managementでルーティング関係が正しくモデル化されるようにルーティング関係を記述する必要があります。このためには、デバイスを登録し、ロード・バランサのエントリ・ポイントを追加し、メッセージのルーティング先に対応するターゲット・エントリ・ポイントを指定する必要があります。
デフォルトのロード・バランサは、最初に登録されたロード・バランサまたはsetDefaultLoadBalancerコマンドを使用してデフォルトに設定したロード・バランサです。
コール元のサービスは、ルーティング・エントリ・ポイントを使用してロード・バランサと通信します。Business Transaction Managementは、メッセージを監視してルーティング・エントリ・ポイントを検出します。ロード・バランサがまだ登録されていない場合、Business Transaction Managementはデフォルトのロード・バランサを作成し、検出したルーティング・エントリ・ポートを割り当てます。新たに検出されたルーティング・エントリ・ポイントは、登録済F5ロード・バランサに属している場合を除いて、デフォルトのデバイスの一部としてモデル化されます。
自動的に作成されたデフォルトのロード・バランサのプロファイルを編集して追加で詳細な情報を提供したり、必要に応じてデフォルトのロード・バランサを登録解除し、実際のロード・バランサを明示的に登録することもできます。
CLIコマンドregisterDeviceまたはコンソールを使用して、ハードウェア・ロード・バランサまたはソフトウェア・ロード・バランサを登録できます。
登録完了後、ナビゲータで「エクスプローラ」→「デバイス」を選択すると、デバイスがサマリー・ペインにリストされます。
コンソールを使用してハードウェア・ロード・バランサまたはソフトウェア・ロード・バランサを登録するには:
「管理」→「登録」→「デバイス」を選択し、次に「F5ネットワーク」を選択してF5ロード・バランサを登録するか、または「その他」を選択してその他のロード・バランサを登録します。
次のダイアログで、次の表に示すように値を指定します。
| フィールド | 説明 |
|---|---|
| ベンダー | F5では編集不可。他のロード・バランサでは必須。
手順1で「F5ネットワーク」を選択した場合、このフィールドは「F5」という編集不可の値に設定されます。 「その他」を選択した場合は、ロード・バランサのベンダーの名前を指定します。このフィールドは単に説明を目的としたものです。任意の値(「F5」を除く)を指定できます。指定した値は、管理コンソールに表示されます。 |
| デバイス名 | 必須。
ロード・バランサのわかりやすい名前を指定します。この名前は、管理コンソールに表示されます。 |
| 注意 | オプション。このロード・バランサの性質または目的を思い出せるようにノートを追加します。 |
| ライフサイクル・フェーズ | ドロップダウン・リストからライフサイクル・フェーズを選択します。使用可能な値は、「非推奨」、「開発」、「本番」、「ステージング」および「テスト」です。これらは大文字/小文字が区別されません。 |
| 構成URL | 必須であり、F5を選択した場合にのみ表示されます。
次の書式でF5コンソールのURLを指定します。 https://managementPortIP/iControl/iControlPortal.cgi managementPortIPを適切なホスト名およびポート番号に置き換えます。このURLは通常、iControl/IControlPortal.cgiで終了します。 |
| ユーザー名とパスワード | この値は必須であり、「F5ネットワーク」を選択した場合にのみ表示されます。
F5ロード・バランサのアカウントのユーザー名およびパスワードを指定します。Guestのユーザー・ロールで十分な権限が与えられます。 CLIコマンド
|
| ベース・アドレス | 必須であり、「その他」を選択した場合にのみ表示されます。
ロード・バランサのURLのベース・アドレスを指定します。たとえば、次のようにします。 https://myLoadBalancer:443/ |
| 管理用URL | オプションであり、「その他」を選択した場合にのみ表示されます。
ロード・バランサのHTML管理コンソールのURLを指定します。このURLへのリンクはBusiness Transaction Managementの管理コンソールに表示され、ロード・バランサのコンソールに簡単にアクセスできます。 Business Transaction ManagementがURLを自動的に取得するため、このフラグはF5ロード・バランサでは必要ありません。 |
「適用」をクリックします。
必要に応じて、12.6.1.6項「ルーティング関係を示すエントリ・ポイントの追加」の説明に従って、ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを割り当てます。
すでに登録したデバイスまたはデフォルトのデバイスに関する情報を変更できます。
デバイスに関する情報を変更するには:
ナビゲータから「エクスプローラ」→「デバイス」を選択します。
サマリー領域で、属性を指定または編集するデバイスを選択します。
「変更」→「プロファイルの編集: deviceName」を編集します。
次のダイアログで、関心のあるフィールドを(デバイス登録時の説明に従って)変更します。
「適用」をクリックします。
ほとんどの場合、Business Transaction Managementはメッセージ・トラフィックを監視し、メッセージ・ヘッダーから宛先情報を読み取ることにより、ルーティング関係を自動的に検出してモデル化します。ただし、監視対象メッセージがHTTPホスト・ヘッダーで元の受信者(ロード・バランサ)に関する情報を伝送しない場合は、ロード・バランサへのルーティング・エントリ・ポイントを手動で作成する必要があります。また、ターゲット・エントリ・ポイントを追加してメッセージのルーティング先を示す必要もあります。
ルーティング関係を指定しないと、Business Transaction Managementは連続する依存性フローを描画できなくなります。トランザクションの場合にも、手動キーを使用して関連するサービスをリンクすることにより、これらの非結合フローを接続できます。
ルーティング・エントリ・ポイントおよびターゲット・エントリ・ポイントを追加するには:
ナビゲータから「エクスプローラ」→「デバイス」を選択します。
サマリー領域で、ルーティング関係を明確化するデバイスを選択します。
「作成」→「エントリ・ポイント: deviceName」を選択します。
次のエントリ・ポイントの作成ツールで、次の情報を指定します。--「ホスト先」セクションで、ロード・バランサが監視メッセージを受信するIPアドレスおよびポート番号を指定します(HTTPポート)。--「ターゲット・エントリ・ポイントを追加」をクリックし、ドロップダウン・リストから宛先を選択します。各宛先は、ロード・バランサがメッセージをルーティングしているターゲット・エントリ・ポイントを参照します。使用する可能性がある宛先ごとにこれを行ってください。注意: ドロップダウン・リストには、ルーターが使用しているよりも多くのエントリ・ポイントがあります。その一部は、別のロード・バランサがメッセージを送信しているアドレスである可能性があります。(基本的に、ドロップダウン・リストにはスフィアに認識されているすべてのエントリ・ポイントが表示されます。)
「適用」をクリックします。
Business Transaction Managementでの監視では、特定のサービスを介してメッセージ・トラフィックを監視するオブザーバと、オブザーバによって取得されたデータを分析して格納するモニターとの間で発生する通信が利用されます。
システムの規模を変更し、システムをフォルト・トレラントにするために、いくつかのレプリケート対象モニター(モニター・グループ)をオブザーバに関連付けることができます。レプリケート対象モニターには、メッセージをオブザーバからモニターにルーティングできるサード・パーティ・ロード・バランサが必要です。この項では、オブザーバから2つ以上のモニターに対してメッセージのロード・バランシングが行われるようにF5デバイスを設定する方法について説明します。
F5の設定を理解するには、オブザーバと単一のモニターとの通信を可能にするメカニズムを確認することが役立ちます。次の図にこれを示します。
図に示すように、オブザーバとモニター間の通信は2つのパスによって行われます。
オブザーバは、モニターに構成情報を問い合せて、モニターのHTTPポートからその情報を受信します。(構成データの大部分はモニターからオブザーバに流れますが、接続はオブザーバによって確立されます。)このポートは、プラットフォームに応じてAP_NANO_CONFIG_URLというJavaシステム・プロパティまたはAmberPoint:NanoConfigRLというWindowsキーを使用して指定します。図に示されたサンプルのURLは、MyApSvr:8080/apmonitor/agent/agentです。オブザーバは起動するとリクエストをこのURLに送信して構成情報を受け取り、測定内容とその頻度が指示されます。このように、様々な種類の情報に対するニーズの変化に応じてオブザーバを動的に再構成できます。
オブザーバは、オブザーバ通信ポリシーに指定されているソケット・ポートで測定データをモニターに送信します。デフォルトでは、このポートは36963です。
F5デバイス経由でオブザーバとレプリケート対象モニターとの間に通信を確立する場合、F5デバイスは追加したあらゆるレプリケート対象モニターに対してこの同じ2つの(構成およびデータ)パスを含めるように構成されている必要があります。次の図に、F5デバイスがどのようにオブザーバをレプリケート対象モニターと接続するかを示します。
前述のような体系を確立するには、F5デバイスの構成、Javaシステム・プロパティまたはWindowsキーの設定およびレプリケート対象モニター用オブザーバ通信ポリシーの定義が必要です。
F5デバイスを設定するときは、そのデバイス用の管理コンソールを使用して次のことを行う必要があります。
オブザーバが構成情報を受け取るために使用するHTTP仮想サーバーを作成します。前掲の図では、これはポート5060で示されています。
接続先のモニターのHTTPポートに対応するメンバー・ポート番号を持つHTTP仮想サーバーにプールを割り当てます。図に示すように、HTTP仮想サーバーのプールにはポート11080および11081が含まれています。
オブザーバがデータをモニターのソケット・ポートに送信するために使用するソケット仮想サーバーを作成します。前掲の図では、これはポート5061で示されています。接続先のモニターのソケット(データ)ポートに対応するメンバー・ポート番号を持つソケット・サーバーにプールを割り当てます。図に示すように、ソケット仮想サーバーのプールには各ホスト・マシンの36330のポートが含まれています。
AP_NANO_CONFIG_URLというJavaシステム・プロパティまたはAmberPoint:NanoConfigURLというWindowsキーを設定するときは、次のような値を指定する必要があります。
http://10.147.46.152:5060/btmmonitor/agent/agent/
URLの太字の部分をメモします。これは、F5デバイス(ホスト)のIPアドレスと仮想サーバーのHTTPポートです。(これらの値は実際のデプロイメントでは異なります。)
オブザーバ通信ポリシーに指定する値は、次のように、F5デバイスに対して定義されている値に対応しています。
| オブザーバ通信ポリシー(ルーターからモニター・グループへ) | F5デバイスの値 |
|---|---|
| ルーターのIPアドレス | F5デバイスのIPアドレス。図ではこれは10.147.46.152になります。 |
| ルーターのポート番号 | 仮想サーバーのソケット番号。図ではこれは5061になります。 |
| モニターのポート番号 | プール・メンバー・ポートの1つ。図ではこれは36630になります。
なんらかの理由で複数のレプリケート対象モニターが同じマシンにある場合、各モニターのポート番号はそれぞれ異なるものになり、モニターごとに異なるオブザーバ通信ポリシーが必要になります。 |
オブザーバ通信ポリシーを最初に定義し、次にF5を定義するかどうかは重要ではありません。重要なのは、モニターに割り当てられたソケット・ポートがF5デバイスの仮想サーバー・ソケット・プールに定義されたものと対応していることです。
この項では、レプリケート対象モニターをデプロイおよび登録し、モニター・グループを作成するための作業がある程度すでに完了しているものとしています。その方法およびオブザーバ通信ポリシーの定義方法については、『Business Transaction Managementインストレーション・ガイド』を参照してください。
有用な検出構成を作成しようとすると、特にBusiness Transaction Managementを使用する早い段階では何度か繰り返し作業することになる場合があります。プローブを有効にするためのデフォルト設定にあまりにも多くの情報が含まれる場合や、デプロイメントまたはオブザーバ・モニター・トポロジの変更によって情報が冗長になったり誤ったものになる場合があります。システムを再インストールしたり、すべての監視対象エンティティおよび関連するアーティファクトを手動で削除する必要がないようにするために、Business Transaction ManagementにはdeleteAllコマンドが用意されています。このコマンドは、すでに検出されたオブジェクトをトランザクション、プロパティ、登録済サービス、デバイス、コンテナなど関連するアーティファクトとともに削除します。
監視したオブジェクトに関する履歴データなどのデータの不要な損失を防ぐために、このコマンドは慎重に使用してください。このコマンドが最も適しているのは、Business Transaction Managementでの作業を開始し、検出方式を微調整するときです。本番環境では使用しないでください。詳細は、10.11項「deleteAll」を参照してください。
検出構成を微調整し、Business Transaction Managementでしばらく作業した後、引き続き問題が発生する場合があります。サービスを監視できない最も単純な理由は次のとおりです。
Business Transaction Managementがサービスを表示するほど十分に長くまたは十分に多様にトラフィックが実行されていません。この場合の解決策は、より多くのトラフィックを実行し、可能性のあるすべてのブランチをトラバースしてみることです。
サービスの監視を担当するプローブがアクティブ化されていません。確認するには、ナビゲータから「管理」→「オブザーバ」を選択し、検出しようとしているサービスのタイプに適したプローブがアクティブであることを確認します。そうでない場合は、オブザーバ通信ポリシーを編集してアクティブ化します。デフォルトでは、JAVAプローブを除くすべてのプローブがアクティブ化されています。JAVAプローブを有効にするには、監視する特定のJavaクラスの名前でJAVAプローブを構成する必要があります。
サービスがレプリケートであるかどうかを決定する場合には、さらに複雑な問題が発生します。サービスおよびエンドポイントを適切に検出して表現する処理では、サービスのコピーが有効なレプリケートを表しているかどうか、逆に言うとWSDL定義が同じではないサービスが同じインタフェースを実際に実装しているかどうかをBusiness Transaction Managementが認識する必要があります。これらの決定は、検出されたWSDLを比較し、システム・サービス・バージョニング・ポリシーで定義されている基準に従うことによって行われます。また、所有権またはアカウントの問題のため、異なるバージョンのサービスを分離またはマージすると効果的である場合もあります。Business Transaction Managementには、レプリケーションおよび重複の問題と、ユーザーのニーズや意図を推測できない事例の解決に使用可能なコマンドおよびツールが用意されています。
この項では、このような問題の概要を説明し、問題の対処に使用するコマンドを紹介します。また、管理コンソールからアクセスする「エンドポイントの明確化」ツールを使用して解決できる検出問題もあります。この項の内容は、次のとおりです。
デフォルトでは、サービス・バージョニング・ポリシーはBusiness Transaction Managementで新規または変更済のWSDLにどのように対処するかに関するガイドラインを設定します。
サービスの修飾名、ポート・タイプ名およびポート定義が一致した場合、2つのエンドポイントは同じサービス・バージョンの一部として扱われます。
既存のサービスの異なるバージョンを定義するWSDLが検出された場合、登録するエンドポイント位置のホストとポートに基づいて新しいサービス・バージョンが作成されます。
WSDLの再読取り時に、サービスの修飾名が変更された場合は、以前のエンドポイントが置き換えられるため、すべての測定結果が失われます。
デフォルトのサービス・バージョニング・ポリシーを編集してこれらの基準を強化または緩和することによって、検出問題を未然に防ぐことができる場合があります。ポリシーの変更では不十分な場合、検出結果の修正に使用可能でコンソールからアクセスできる数多くのCLIコマンドと1つのツールがあります。追加情報
デフォルトのサービス・バージョニング・ポリシーを編集するには
ナビゲータで、「管理」→「システム・ポリシー」を選択します。
サマリー領域で「サービス・バージョニング・ポリシー」項目をダブルクリックして、詳細領域に現在のバージョニング・ポリシーを表示します。
「変更」メニューから、「定義の編集: サービス・バージョニング・ポリシー」を選択します。
必要な変更を行い、「適用」をクリックします。
複数のコンテナにサービスをデプロイした場合、Business Transaction Managementは同じサービスがすべてのエンドポイントから参照され、すべてのエンドポイントが1つのインタフェースを共有していると認識できます。したがって、サービス・レベルでレプリケートに関する統計の集約が可能になり、その結果、サービスのすべてのエンドポイントで共有される操作に関してメッセージ・プロパティを定義できます。
同じサービスのレプリケートとして扱われる2つのエンドポイントでは、次のことが必要です。
2つのサービスのWSDLは修飾名(ターゲット・ネームスペースと簡単な名前)が同じです。
エンドポイントには、同じインタフェースが実装されています。
エンドポイントのサービス・タイプが同じです。
例をあげると、同じ名前を持つユーザーWebサービス、OSBビジネス・サービスおよびOSBプロキシ・サービスは、それぞれのサービス・タイプが異なるため、3つの異なるサービスとして表示されます。
ただし、この情報は決定を下すのに十分でなく、2つのエンドポイントが同じか異なるかをシステムに通知することが必要になる場合があります。次のいずれの場合にも、なんらかの対策を講じるように警告されます。
開発環境で、同じサービスの複数のバージョンが互換性のないまま作成される場合があります。Business Transaction Managementでは、以前のものとは異なって見えるバージョンが検出されると、別のバージョンとして扱われます。その違いが重要でない場合は、mergeServicesコマンドを実行して2つのバージョンを1つにマージできます。
ローリング・アップグレードであるために、すべてのサーバーがアップグレードされるまで、パラレル・バージョンが一時的に共存することが必要になる場合があります。この場合、Business Transaction Managementでは新しいサービス・バージョンは生成されませんが、アラートは生成されます。それにより、アップグレードされたエンドポイントを必要に応じて新しいサービス・バージョンに移動できます。既存のポリシーがアップグレードされたバージョンと互換性がないと、このような状態になる場合があります。moveEndpointsコマンドを使用して、アップグレードされたエンドポイントを新しいサービス・バージョンに移動できます。アップグレードが完了するまでには、すべてのエンドポイントが新しいサービス・バージョンになります。
アップグレードが失敗したり不完全であると、意図しなかったバージョン・スキューが発生しますが、これによりサービスの2つの異なるバージョンが存在することになります。2つのバージョンをマージすることも、分離することもできます。
並行アップグレードによってアプリケーションの新しいバージョンがデプロイされ、新しいエンドポイント位置でインタフェースが更新されると、Business Transaction Managementはデフォルトでは新しいサービス・バージョンを生成します。これを受け入れることも、新しいバージョンを古いバージョンとマージしてサービス履歴を保持することもできます。
同じサービスを識別するWSDLの2つのセットは通常はレプリケートとして扱われますが、サービスの様々なインスタンスが各部門によって異なる方法で使用されるため、サービス・バージョン間でエンドポイントを手動で分けることが必要になる場合があります(moveEndpoints)。この場合、新しいレプリケート・エンドポイントが検出されるとBusiness Transaction Managementはアラートを生成します。これにより、そのエンドポイントがどのサービス・バージョンに属しているかを判断できます。
サービスの更新後のバージョンをデプロイすると、Business Transaction Managementによって古いバージョンが削除される場合があります。古いバージョンに関連付けられた測定結果を保持する場合は、moveMeasurementsコマンドを使用して測定結果を古いバージョンから新しいバージョンに移動できます。
Business Transaction Managementは、マシン名またはコンテナのリスニング・アドレスを変更した結果または同じホスト名に複数の別名を使用した結果発生した問題を、ユーザーの支援を受けることなく解決しようとします。システムによって推測されたこのような状態への対処方法が誤っている場合、最もよく見られる症状は、実際には1つのみ存在するサービスまたはエンドポイントが重複して検出されることです。次の表に記載されているコマンドを使用して、重複の問題の回避または解決に役立てることができます。
WSDL、サービスまたはエンドポイントの識別子として使用される部分は次のとおりです(次の例の場合)。
http://jbujes-pc.edge.com:8080/Bookmart/Credit/CreditService?wsdl
ベース・アドレスはhttp://jbujes-pc.edge.comです。
ノードはjbujes-pc.edge.comです。
パスはBookmart/Credit/CreditService?wsdlです。
一般に、removeDuplicateEndpoint (またはaddBaseAddressAlias)コマンドを使用すると、必要なすべてが実現されます。つまり、重複が再び発生しないように、重複した項目が削除され、適切な別名が定義されます。ただし、次にあげるコマンドで行われるすべての別名修正では遡って修正されないことに注意してください。つまり、誤ってすでに作成された重複は削除されません。
この他に重複が見られるのは、2つのエンドポイントが同じURLを共有し、それらの説明が記述されているWSDLで同じポート名が指定されている場合です。デフォルトでは、ポート名はわかりやすい名前として使用されます。わかりやすい名前は一意である必要はありませんが、一意のエンドポイントを参照する必要があるコマンドではわかりやすい名前ではなくエンドポイントURL (および場合によってはその他の特性)を指定する必要があります。renameEndpointコマンドを使用して(あるいは単に目的のエンドポイントを選択し、その「プロファイル」タブでわかりやすい名前を変更して)、エンドポイントを相互に区別できます。
「エンドポイントの明確化」ツールを(コンソールから)使用して、次のことを行うことができます。
サービスのマージ: ソース・サービスを指定のターゲット・サービスにマージします。
エンドポイントの移動: ソース・エンドポイントを既存または新規のサービスに移動します。
重複するエンドポイントの削除: ターゲット・エンドポイントの重複であるソース・エンドポイントを削除します。
ソース・サービスまたはソース・エンドポイントを選択し、「管理」→「エンドポイントの明確化」を選択します。「エンドポイントの明確化」ツールがコンソールに表示されます。ツールは主に3つの領域で構成されています。ソースとターゲットを比較する領域、使用可能なアクションをリストする領域および実際に実行する前にアクションの影響をプレビューできる領域です。
ソースのドロップ・リストには、システムでの重複という内部評価に基づいて可能性のあるすべてのソースが含まれています。最上部に示されるサービスまたはエンドポイントは、ツールを開いたときに選択したものです。必要に応じて別のものを選択できます。
ターゲットのドロップ・リストには、可能性のあるすべてのターゲットが含まれており、ソースに対して選択した項目が指定されています。
ドロップ・リストの下に、選択したソースおよびターゲットの基本情報が表示されます。アイコン(等しい/等しくない)は、ソースとターゲットの要素が同じかどうかを示します。WSDLのリストでの違いを表示するには、リンクをクリックしてWSDLの内容を表示します。
ドロップ・リストを使用して、ソースおよびターゲットを選択します。
新しいサービスをターゲット・サービスとして作成する場合は、新規サービス・チェック・ボックスを選択し、サービスの名前およびバージョンを指定します。まだ存在しないサービスにソース・エンドポイントを移動する場合には、これを行うことをお薦めします。
「エンドポイントの明確化」ツールのアクション部分には、選択したソースおよびターゲットに基づいて、実行できる可能性があるアクションが表示されます。
有効なアクションをクリックします。目的のアクションが使用可能でない場合は、ターゲットを変更するか、または「新しいサービスの作成」を選択することが必要になる場合があります。これらの各アクションの影響の詳細は、mergeServices、removeDuplicateEndpointまたはmoveEndpointsの対応するコマンドラインを調べてください。これらのアクションを必要とするユースケースについては、すでに説明しています。
アクションを選択した後、そのアクションの影響が「プレビュー」領域に表示されます。表示された結果が想定どおりである場合は、「OK」ボタンをクリックして選択したアクションを実行します。
この項では、Business Transaction Managementの管理に役立つその他の情報を提供します。この項の内容は次のとおりです。
サービスを登録解除するには、管理コンソールで次の手順を使用します。また、CLIコマンドunregisterを使用してサービスを登録解除することもできます。このCLIコマンドの使用方法については、第10章「コマンドおよびスクリプト」を参照してください。
サービスを登録解除するには
サービスを選択します。
「変更」→「My_Service登録の削除」を選択します。My_Serviceは選択したサービスの名前です。
「サービス登録の削除」ツールが開きます。
「削除」をクリックします。
次のリストでは、システム・サービスのステータスの確認方法について説明します。リストには、これらのタスクが高レベルから低レベル(上位から下位)の順に並んでいます。リストされた各タスクにより、監視を実行できる場所へと移動し、さらに詳細な情報へのリンクが提供されます。
次のものを確認するには:
システム・サービスおよびシステム・アラートのサマリー
「ダッシュボード」→「操作状態サマリー」に移動します。
すべてのシステム・アラートの詳細なビュー
「過去1時間のアラート」→「システム・アラート」に移動します。
特定のシステム・サービスの現在のステータス
特定のシステム・サービスに移動し、「ステータス」タブを表示します。
システム・アラートは、Business Transaction Managementインフラストラクチャの状態に関する情報を提供します。Business Transaction Managementは、致命的なエラー、コンテナの停止、ポリシーの拒否、使用中の属性の削除などが発生した場合にシステム・アラートを発行します。
選択したBusiness Transaction Managementシステム・サービスのステータスを確認するには、「ステータス」タブを使用します。
サービス・ステータス表
「ステータス」タブの最上部にある表には、サービスに関する次の情報が記載されています。
URL: Business Transaction ManagementがサービスのUUIDが見つかると認識している場所。
ID: サービスに割り当てられたUUID。
ステータス: サービス・ステータスは、次のいずれかの値になります。
RUNNING: システム・サービスは実行中で正しく動作しています。システム・サービスがRUNNINGである場合、そのすべての関連付けられたリソースはアクセス可能で実行中である必要があります。
DEGRADED: リソースはアクセス不可である場合がありますが、そのリソースはシステム・サービスの稼働に必須ではありません。低下状態のサービスに対するアクセス不可のリソースを調べることをお薦めします。システムの再同期により、低下状態のサービスが修正される場合があります。低下状態のサービスは、システム・ログへのアラートをトリガーしません。
FAULTED: 必須のリソースにアクセスできません。通常、フォルト値はサービスが必要とするデータベースが停止したときに表示されます。サービスは、フォルト状態になると、使用できないとみなされます。その後、エラーがシステム全体に伝わらないように、サービスへのアクセスが停止します。フォルト状態のサービスは、システム・ログへのアラートをトリガーします。このアラートにより、問題の根本原因への対処方法に関する情報が提供されます。システムの再同期により、フォルト状態のサービスが修正されることはありません。そのかわり、まず問題の根本原因に対処し、次にフォルト状態のサービスが含まれているBusiness Transaction Managementデプロイメントを再起動する必要があります。
SETUP_REQUIRED: システム・サービスの必須のリソースや要素がまだアップグレードされていません。たとえば、トランザクション管理コンポーネントがデータベースに接続されていません。
INITIALIZING: サービスは、その存続時間の冒頭でこの一時的な状態になります。
リソース・ステータス表
サービス・ステータス表の下にリソース・ステータス表があり、選択したサービスに関係があるBusiness Transaction Management環境の他のコンポーネントに関するステータス情報が提供されます。たとえば、いくつかのシステム・サービスがデータベースを使用します。リソースのセクションでは、データベースが実行中で正しく動作していることを確認できます。
リソース・ステータス表では、次のタイプの情報が提供されます。
ステータス: リソース・ステータスは、次のいずれかの値になります。
OK: リソースは実行中で正しく動作しています。
FAULTED: 必須のリソースにアクセスできません。
SETUP_REQUIRED: 必須のリソースがまだアップグレードされていません。
最終アクセス: サービスがリソースへの最終アクセスを試みたときのタイムスタンプ。
最後の正常なアクセス: サービスが最後にリソースにアクセスしたときのタイムスタンプ。システム・ログを使用して問題を診断するときは、リソースの「最後の正常なアクセス」のタイムスタンプが適切な開始点です。
リソース・ステータス表に含まれているもう1つの重要な情報は、選択したシステム・サービスが関連付けられているスフィア・サービスのURLです。
|
注意: リソースURLは、ダッシュ「-」またはカッコ「()」とともに表示されます。ダッシュとともに表示されるURLはスフィア・サービスなどインストール内に1回のみ存在できるリソースを表し、カッコとともに表示されるURLはモニターなど複数のインスタンスを存在させることができるリソースを表します。 |
スフィアは約15分おきに同期します。「管理」→「システムの再同期」を選択して、スフィアを手動で再同期できます。再同期によって、スフィアにシステムの現在の状態が反映されるようになります。また、「システムの再同期」では同時に稼働ステータス・チェックも実行されます。
デフォルトでは、稼働ステータスが2分おきにチェックされて、サービスが稼働しているのか停止しているのかが確認されます。次の説明に従って、自動稼働ステータス・チェックの時間間隔を変更できます。(CLIで稼働ステータス・チェックに相当するのは、configureAlivenessCheckコマンドです。)
Business Transaction Managementは、オブザーバ通信ポリシーの設定方法に応じてコンポーネントを自動的に検出および監視します。コンポーネントの検出の完了後、エンドポイントの監視を明示的に開始および停止できます。
エンドポイントの監視を開始または停止すると、モニターとオブザーバ構成の両方が更新されます。監視が停止すると、パフォーマンス測定は記録されず、メッセージはログに記録されず、トランザクションはトレースされません。
エンドポイントの監視を停止するには
エンドポイント(またはサービス)を選択します。
「管理」→「監視の停止」を選択します。
監視の停止ツールが開き、監視を停止する追加のエンドポイントを選択できます。
エンドポイントの監視を開始するには
エンドポイント(またはサービス)を選択します。
「管理」→「監視の開始」を選択します。
監視の開始ツールが開き、監視を開始する追加のエンドポイントを選択できます。
|
注意: Business Transaction Managementは、監視対象外コンテナで実行中のサービス・エンドポイントが監視対象コンテナ内のサービスと対話している場合、依存性分析を使用してそれらのエンドポイントを検出できます。registerExternalContainerコマンドを使用して、このようなエンドポイントのコンテナを定義できます。 |
ナビゲータで「エクスプローラ」→「コンテナ」を選択して、登録済のコンテナを調べることができます。サマリー領域にすべての登録済のコンテナがリストされます。
メイン領域でコンテナを選択して、「プロファイル」タブにそのコンテナに関する情報を表示します。「管理UIコンソール」フィールドのURLをクリックして、コンテナの管理コンソールを開きます。「変更」→「プロファイルの編集: the_selected_container」を選択して、コンテナのプロファイルを編集できます。
コンテナで実行中のサービスを表示するには、そのコンテナを選択し、「サービス」タブを表示します。また、メイン領域にコンテナを展開して、そのコンテナで実行中のサービス・エンドポイントにドリルダウンすることもできます。
次のリストでは、コンテナの状態の監視方法について説明します。リストには、これらの監視タスクが高レベルから低レベル(上位から下位)の順に並んでいます。リストされた各タスクにより、監視を実行できる場所へと移動し、さらに詳細な情報へのリンクが提供されます。
次のものを確認するには:
すべてのコンテナの全体的な現在の状態
「ダッシュボード」→「操作状態サマリー」に移動します。
すべてのコンテナ関連の問題(さらに他のシステム関連の問題)の最新履歴
「過去1時間のアラート」→「システム・アラート」に移動します。
特定のコンテナの現在の状態
特定のコンテナに移動し、サマリー領域で「稼働中/停止ステータス」アイコンを選択します。
コンテナを登録解除する必要がある場合があります(つまり、スフィアおよび管理コンソールからコンテナを削除します)。たとえば、次のいずれかの記述が当てはまる場合、コンテナの登録解除が可能であり、そうすることをお薦めします。
異なるスフィアでコンテナを登録しました。
異なるスフィアに登録されているモニターに監視を送信するようにオブザーバを再構成すると、このようになります。この場合、オブザーバが稼働中のコンテナは、トラフィックが監視されるとすぐに他のスフィアに自動的に登録されます。
コンテナからオブザーバをアンインストールしました。
システムからコンテナをアンインストールしたか、または物理的に除外しました。
このいずれの記述も当てはまらない場合にコンテナを登録解除したときは、コンテナとの間でメッセージ・トラフィックが監視されるとすぐにコンテナが自動的に再登録されます。
コンテナを登録解除するには
登録解除するコンテナを選択します。
「変更」→「selected_container登録の削除」を選択します。
登録の削除ツールが開きます。
「削除」をクリックします。
システム・ポリシーは通常、管理者が使用します。ほとんどのシステム・ポリシーは編集できません。変更できるポリシーでは、カスタム属性の定義、メッセージ・ロギング・データベースへの接続の構成、検出の構成、測定を集約して収集する間隔の指定、新規または変更されたWSDLに対して実行するアクションに関するシステムへの通知が可能です。
この項では、使用可能なシステム・ポリシー、システム・ポリシーへのアクセス方法、システム・ポリシー定義の表示方法、システム・ポリシーの定義方法およびシステム・ポリシーの変更方法について説明します。
ナビゲータで「管理」→「システム・ポリシー」を選択して、システム・ポリシーを表示できます。次の表では、次のポリシーについて説明します。
| 名前 | 説明 |
|---|---|
| ベースライン格納 | エンドポイント、サービスおよびトランザクションに対するベースライン値の導出と格納が可能です。 |
| コールアウト測定 | 特定のリンクの平均レスポンス時間、スループットおよびフォルト・カウントの測定と表示が可能です。このポリシーは編集できません。 |
| 条件測定 | 特定のトランザクションに対する条件アラート数および条件アラート数率の測定が可能です。このポリシーは編集できません。 |
| コア測定 | 特定のエンドポイントとサービスについて、平均レスポンス時間、最大レスポンス時間、スループット、フォルト・カウント、トラフィック、フォルトの割合、スループット率およびフォルト率のカウントの計算が可能です。このポリシーは編集できません。 |
| データ・モデル属性定義 | サービス、エンドポイント、操作、コンテナ、エージェント、ビジネス・オブジェクト、トランザクションおよびタイプ・ドメインのカスタム属性を拡張します。 |
| デフォルト・メッセージ・ロギング・データベース | メッセージのロギングに使用されるデータベースへの接続を構成します。詳細は、12.2.2項「メッセージ・ログ・データベースの設定」を参照してください。 |
| デフォルト・オブザーバ通信ポリシー | どのジャンルを監視するかを決定し、モニターのポート番号を指定します。 |
| イベント生成ポリシー | イベント通知の発生に基づいてイベントの生成を構成します。 |
| イベント通知測定ポリシー | 通知サービスで使用されます。このポリシーの基準は再定義のみ可能です。 |
| 測定間隔ポリシー | 測定結果がBusiness Transaction Management全体で集計および収集される間隔を指定します。 |
| サービス・バージョニング・ポリシー | 新規または変更されたWSDLに対して実行するアクションをシステムに指示します。詳細は、12.7項「検出問題の解決」を参照してください。 |
| シンプル・トランザクション測定ポリシー | 特定のトランザクションの平均レスポンス時間、最大レスポンス時間、完了済トランザクション・カウント、開始済トランザクション・カウント、完了済トランザクション率および開始済トランザクション率の測定が可能です。
Business Transaction Managementは、トランザクションの定義方法および使用されている機能に応じて、このポリシーまたはトランザクション測定ポリシーを使用して、トランザクション・パフォーマンスを測定します。 このポリシーは編集できません。 |
| トランザクションのシステム生成ログ・ポリシー | トランザクション・メッセージの格納場所、時間ストアの制限、切替え間隔を指定し、ロギングの範囲を定義します。
このポリシーは編集できません。 |
| トランザクション測定 | 特定のトランザクションの平均レスポンス時間、最大レスポンス時間、完了済トランザクション・カウント、開始済トランザクション・カウント、完了済トランザクション率および開始済トランザクション率の測定が可能です。
Business Transaction Managementは、トランザクションの定義方法および使用されている機能に応じて、このポリシーまたはシンプル・トランザクション測定ポリシーを使用して、トランザクション・パフォーマンスを測定します。 このポリシーは編集できません。 |
| 稼働時間測定 | 特定のエンドポイントとサービスの稼働時間の測定が可能です。このポリシーは編集できません。 |
| モニター・グループ・ポリシー | モニター・エージェント・グループの作成と構成を行います。 |
システム・ポリシー定義を表示するには:
「管理」→「システム・ポリシー」を選択します。
メイン・ペインで関心のあるポリシーをダブルクリックします。
「プロファイル」タブをクリックします。
システム・ポリシーを定義するには:
「管理」メニューから「システム・ポリシーの作成」を選択します。
「メッセージ・ログ・データベース」、「モニター・エージェント・グループ」、「オブザーバ通信」のいずれかを選択します。
必須の情報を指定し、「適用」をクリックします。
ポリシーを定義するときは、識別情報としてポリシーの名前およびそれが有効かどうかを指定する必要があります。また、ポリシーが実現する内容を決定する設定と、ポリシーが適用されるエンドポイント(ターゲット)を決定する条件を指定する必要があります。
一部のシステム・ポリシーは変更のみが可能で、ナビゲータの「管理」→「システム・ポリシー」からアクセスする必要があります。
システム・ポリシーを変更するには
「管理」→「システム・ポリシー」を選択します。
メイン領域で関心のあるポリシーを選択します。
「変更」→「定義の編集: policy」を選択します。このメニュー項目が使用可能でない場合、ポリシーは変更できません。
