WebLogic 診断フレームワークのコンフィグレーションと使い方
|
 |
 |
|
WebLogic 診断フレームワーク (WebLogic Diagnostic Framework : WLDF) のインスツルメンテーション コンポーネントは、BEA WebLogic Server® インスタンスおよびそのサーバ インスタンスで実行中のアプリケーションに診断コードを追加するためのメカニズムを提供します。WLDF のインスツルメンテーションで主要な機能は次のとおりです。
WLDF には、あらかじめ定義された診断モニタと診断アクションのライブラリが用意されています。また、アプリケーション スコープのカスタム モニタを作成し、診断コードが挿入されるアプリケーション内の位置をユーザが決めることもできます。
この節では、インスツルメンテーションの概念と用語について説明します。
実行可能なインスツルメンテーション サービスには、システム レベル (サーバおよびクラスタ) のものとアプリケーション レベルのものがあります。 概念、サービス、コンフィグレーション オプション、および実装機能の多くは両者とも同じです。ただし、相違点もいくつかあります。それらについて、このマニュアルで説明します。「サーバ スコープ インスツルメンテーション」は、WebLogic Server インスタンスおよびクラスタ固有のインスツルメンテーションのコンフィグレーションと機能を指し、「アプリケーション スコープ インスツルメンテーション」は、WebLogic サーバにデプロイされているアプリケーション固有のコンフィグレーションと機能を指します。スコープは各モニタに組み込まれており、ユーザがモニタのスコープを変更することはできません。
サーバまたはクラスタ向けのサーバ スコープ インスツルメンテーションは、診断モジュールの一部として、DOMAIN_NAME/config/diagnostics ディレクトリにある XML コンフィグレーション ファイルでコンフィグレーションおよびデプロイされ、config.xml からリンクされています。
アプリケーション スコープ インスツルメンテーションも、診断モジュールとしてコンフィグレーションおよびデプロイされます。ただし、アプリケーション スコープの場合は、アプリケーション アーカイブでパッケージ化された weblogic-diagnostics.xml という XML コンフィグレーション ファイルを使用します。
インスツルメンテーション用コードは、サーバおよびアプリケーションのコード内の特定の場所に挿入されます。この特定の場所を表すために、以下の用語が使用されています。
<pointcut> です。ポイントカットについては、「カスタム モニタのポイントカットの定義」を参照してください。<location-type> です。診断モニタは、そのスコープと種類によって分類されます。スコープは、サーバ スコープかアプリケーション スコープのどちらかです。種類は、モニタのポイントカット、診断場所、およびアクションによって決まります。たとえば、Connector_After_Inbound はアプリケーション スコープの代理モニタです。このモニタは、着信接続を処理するメソッドの出口 (つまり、after) で診断アクションをトリガするために使用できます。
インスツルメンテーション診断モニタには、以下に示す 3 種類があります。
現在のリリースでは、DyeInjection モニタだけが標準モニタです。このモニタは、サーバ スコープ モニタで、診断コンテキストと仕分けの注入をサーバ レベルでコンフィグレーションするために使用します。詳細については、「診断コンテキストのコンフィグレーション」を参照してください。
代理モニタは、それ自体では完成していません。代理モニタが何らかの意味のある処理を行うには、少なくとも 1 つのアクションをモニタに割り当てる必要があります。
すべてのアクションがどのモニタにも割り当て可能なわけではありません。Administration Console で代理モニタをコンフィグレーションする場合、選択したモニタで対応可能なアクションのみを指定できます。WLST を使用する場合、または記述子ファイルに直接記述する場合は、アクションがそのモニタで対応可能かどうかを確認する必要があります。XML ファイルがデプロイメント時にロードされたときに、検証が実行されます。
WLDF インスツルメンテーション ライブラリで利用可能な代理モニタとアクションについては、「WLDF インスツルメンテーション ライブラリ」を参照してください。
表 9-1 に、各種類のモニタの違いを簡単に示します。
診断アクションは、関連する代理モニタまたはカスタム モニタに対応する診断コードを実行します (標準モニタの場合、アクションはあらかじめ定義されています)。代理モニタまたはカスタム モニタが何らかの意味のある処理を行うには、モニタに対して少なくとも 1 つのアクションをコンフィグレーションする必要があります。
WLDF 診断ライブラリでは、以下のアクションを利用できます。モニタのコンフィグレーション時に、このアクション名のいずれかを <action> 要素で指定すると、そのアクションをモニタにアタッチできます。
アクションは、モニタに正しく対応している必要があります。たとえば、TraceElapsedTime アクションは、診断ロケーションの種類が around のカスタム モニタ、または代理モニタで使用できます。詳細については、「WLDF インスツルメンテーション ライブラリ」を参照してください。
モニタに対して「仕分けマスク」を設定すると、診断アクションがトリガされるタイミングを制限できます。このマスクによって、診断コンテキストのどの仕分けフラグがアクションをトリガするかが決まります。モニタの仕分けマスクの設定については、「<wldf-instrumentation-monitor> の XML 要素」を参照してください。
注意 : 診断コンテキスト、仕分けの注入、および仕分けフィルタについては、「診断コンテキストのコンフィグレーション」で説明します。
インスツルメンテーションは、診断記述子の一部として XML コンフィグレーション ファイルでコンフィグレーションされます。このファイルの名前と格納場所は、システムレベル (サーバ スコープ) のインスツルメンテーションを実装しているか、アプリケーション レベル (アプリケーション スコープ) のインスツルメンテーションを実装しているかによって異なります。
DOMAIN_NAME/config/diagnostics
このディレクトリには、複数の診断記述子ファイルを格納できます。ファイル名は任意ですが、.xml で終わる必要があります (myDiag.xml は有効なファイル名です)。各ファイルには、ハーベスタ、インスツルメンテーション、または監視と通知のうち、1 つまたは複数のデプロイ可能な診断コンポーネントのコンフィグレーション情報を格納できます。記述子ファイルの <instrumentation> セクションでは、1 つまたは複数の診断モニタをコンフィグレーションできます。サーバ スコープのインスツルメンテーションは、サーバを再起動しなくても有効化および無効化でき、ほとんどの場合、再コンフィグレーションも可能です。
サーバ (またはクラスタ) でアクティブにできるシステム レベルの診断記述子ファイルは、一度に 1 つだけです。アクティブ ファイルは、以下のコンフィグレーション ファイルからリンクおよび対象指定されます。
DOMAIN_NAME/config/config.xml
コンフィグレーション ファイルの作成、解析、およびファイルの内容の概要については、『ドメインのコンフィグレーションについて』を参照してください。
META-INF/weblogic-diagnostics.xml
アプリケーションにデプロイ可能な診断コンポーネントはインスツルメンテーションだけです。したがって、このファイルには、インスツルメンテーションのコンフィグレーション情報のみを格納できます。アプリケーション スコープのインスツルメンテーションは、アプリケーションを再デプロイしなくても有効および無効にできます。また、JSR-88 デプロイメント プランを使用すると、モニタを有効または無効にしたり、モニタに関連付けられているアクションを変更したりすることも可能です。
インスツルメンテーションをアプリケーションで使用できるようにするには、アプリケーションがデプロイされるサーバでインスツルメンテーションを有効にする必要があります。
http://www.bea.com/ns/weblogic/90/diagnostics.xsd
ドキュメントについては、『WebLogic Server Diagnostics Configuration Schema Reference』を参照してください。
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
WLDF リソースのコンフィグレーションの概要については、「WLDF コンフィグレーションについて」を参照してください。
この節では、記述子のコード フラグメント、インスツルメンテーションのコンフィグレーションに使用する XML 要素をまとめた表、および各インスツルメンテーション診断モニタについて簡単に説明した表を示します。
<instrumentation> 要素内で使用する最上位の各要素について説明します。<wldf-instrumentation-monitor> 要素内で使用する各要素について説明します。表 9-2 に、<instrumentation> の各要素を示します。以下のコンフィグレーション フラグメントでは、それらの要素の使用方法を示します。
<instrumentation>
<enabled>true</enabled>
<!-- 以下の <include> 要素は
アプリケーション スコープのモニタにのみ適用される -->
<include>foo.bar.com.*</include>
</instrumentation>
表 9-3 に、<wldf-instrumentation-monitor> の各要素を示します。以下のコンフィグレーション フラグメントでは、それらの要素の使用方法を示します。フラグメントでは、アプリケーション スコープの代理モニタおよびカスタム モニタをコンフィグレーションします。サーバ スコープのインスツルメンテーションの場合は、アプリケーション スコープのモニタをサーバ スコープのモニタに置き換えれば、このフラグメントを変更できます。
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>Servlet_Before_Service</name>
<enabled>true</enabled>
<dye-mask>USER1</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>TraceAction</action>
</wldf-instrumentation-monitor>
<wldf-instrumentation-monitor>
<name>MyCustomMonitor</name>
<enabled>true</enabled>
<action>TraceAction</action>
<location-type>before</location-type>
<pointcut>call( * com.foo.bar.* get*(...));</pointcut>
</wldf-instrumentation-monitor>
</instrumentation>
ここでは、Servlet_Before_Service モニタは仕分けマスクを設定しており、仕分けフィルタが有効になっています。これは、インスツルメンテーションがサーバ レベルで有効になっており、DyeInjection モニタが有効化されて適切にコンフィグレーションされている場合にのみ役に立ちます。DyeInjection モニタのコンフィグレーションについては、「診断コンテキストのコンフィグレーション」を参照してください。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<dye-filtering-enabled> と <dye-mask> については、さらに以下の情報があります。
DyeInjection モニタが有効になっており、サーバまたはクラスタ用にコンフィグレーションされている場合、下流にある代理モニタおよびカスタム モニタに対して仕分けフィルタを使用し、要求の診断コンテキストに対してその DyeInjection モニタが実行した仕分けを確認できます。DyeInjection モニタのコンフィグレーションによって、診断コンテキストに関連付けられた 64 ビット仕分けベクトルでどのビットが設定されるかが決まります。<dye-filtering-enabled> 属性がモニタに対して有効になっていても、要求の診断コンテキストの仕分けベクトルが、モニタでコンフィグレーションされた仕分けマスクと一致していない場合、診断アクティビティは実行されません。仕分けベクトルが仕分けマスクと一致している場合 (ビット単位の AND の場合)、アプリケーションは診断アクションを実行できます。(dye_vector & dye_mask == dye_mask)
したがって、仕分けフィルタのメカニズムを使用すると、モニタは特定の要求に対してのみ診断アクションを実行でき、それによって他の要求の処理が遅くなることはありません。診断コンテキストおよび仕分けベクトルの詳細については、「診断コンテキストのコンフィグレーション」を参照してください。
表 9-4 に、どの <wldf-instrumentation-monitor> 要素がどのモニタに対応しているかを示します。
|
|
|||
DyeInjection モニタが仕分けフラグ用に name=value のペアを設定する場合にのみ使用。
サーバ レベルでインスツルメンテーションを有効にし、サーバ スコープのモニタをコンフィグレーションするには、以下の手順を実行します。
1 つのドメインで複数の診断記述子ファイルを使用できますが、サーバ (またはクラスタ) ごとにデプロイできる診断記述子ファイルは一度に 1 つだけです。複数のファイルを作成する理由は、柔軟性です。たとえば、DOMAIN_NAME/config/diagnostics ディレクトリに 5 つの診断記述子ファイルを保存し、ファイルごとに異なるインスツルメンテーション (に加え、おそらくハーベスタおよび監視と通知) のコンフィグレーションを格納できます。次に、特定の状況でどのモニタをアクティブにするかに基づいて、サーバにファイルをデプロイします。
DyeInjection モニタをコンフィグレーションします。コード リスト 9-1 に、サーバ スコープ インスツルメンテーションのコンフィグレーション ファイルのサンプルを示します。このサンプルでは、インスツルメンテーションを有効にし、DyeInjection 標準モニタおよび Connector_Before_Work 代理モニタをコンフィグレーションします。1 つの <instrumentation> 要素に、モジュールのすべてのインスツルメンテーションのコンフィグレーションが格納されます。各診断モニタは、個別の <wldf-instrumentation-monitor> 要素で定義されます。
コード リスト 9-1 サーバ スコープ インスツルメンテーションの記述子ファイルのサンプル
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>DyeInjection</name>
<description>Inject USER1 and ADDR1 dyes</description>
<enabled>true</enabled>
<properties>USER1=weblogic
ADDR1=127.0.0.1</properties>
</wldf-instrumentation-monitor>
<wldf-instrumentation-monitor>
<name>Connector_Before_Work</name>
<enabled>true</enabled>
<action>TraceAction</action>
<dye-filtering-enabled>true</dye-filtering-enabled>
<dye-mask>USER1</dye-mask>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>
アプリケーション レベルでは、WLDF のインスツルメンテーションは、デプロイ可能なモジュールとしてコンフィグレーションされます。このモジュールは、アプリケーションの一部としてデプロイされます。
以下の節では、アプリケーション スコープのインスツルメンテーションのコンフィグレーションで必要な情報について説明します。
アプリケーションのインスツルメントは、システム レベルでのインスツルメントと似ていますが、以下の点が違います。
DyeInjection はサーバ スコープです。weblogic-diagnostics.xml 記述子ファイルでコンフィグレーションされます。ユーザは META-INF/weblogic-diagnostics.xml ファイルを作成し、インスツルメンテーションをコンフィグレーションして、アプリケーションのアーカイブにファイルを格納します。アーカイブがデプロイされると、インスツルメンテーションは、アプリケーションがロードされたときに自動的に挿入されます。<wldf-instrumentation-monitor> を変更) することもできます。ただし、アプリケーションからモニタを削除する場合は、アプリケーションを再デプロイする必要があります (モニタは動的に無効にできますが、アプリケーションを再デプロイするまで、モニタはアプリケーション コードから削除されません)。アプリケーション スコープ インスツルメンテーションの XML 記述子は、サーバ スコープ インスツルメンテーションの場合と同じ方法で定義されます。WLDF インスツルメンテーション ライブラリで使用可能な代理モニタと診断アクションを使用すると、アプリケーション専用のインスツルメンテーションをコンフィグレーションできます。ユーザ独自のカスタム モニタを作成できますが、カスタム モニタにアタッチする診断アクションは、インスツルメンテーション ライブラリから指定する必要があります。
アプリケーションの診断モニタを実装するには、以下の手順を実行します。
META-INF/weblogic-diagnostics.xml 記述子ファイルをアプリケーション用に作成します。<instrumentation> 要素を有効 (<enabled>true</enabled>) にします。各モニタのタイプ用に整形された記述子ファイルのサンプルについては、「代理モニタの記述子ファイルの作成」および「カスタム モニタの記述子ファイルの作成」を参照してください。
ポイントカット式の作成については、「カスタム モニタのポイントカットの定義」を参照してください。
次に、アプリケーション スコープの代理モニタ用に整形された META-INF/weblogic-diagnostics.xml ファイルの例を示します。
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>Servlet_Before_Service</name>
<enabled>true</enabled>
<dye-mask>USER1</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>TraceAction</action>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>
Servlet_Before_Service モニタは、WLDF モニタ ライブラリから選択したアプリケーション スコープのモニタです。これは、複数のサーブレット/jsp メソッドのメソッドの入り口にジョインポイントを設定するポイントカットでハードコード化されています。アプリケーションは仕分けフィルタを有効にし、仕分けマスクに USER1 フラグを設定しているので、TraceAction アクションは、アプリケーションに渡される診断コンテキスト内の仕分けベクトルに USER1 フラグ セットがある場合にのみ呼び出されます (仕分けベクトルは、DyeInjection モニタを介してシステム レベルで設定されます)。したがって、このアプリケーションの Servlet_Before_Service モニタは、仕分けベクトルを確認し、USER1 フラグ セットを見つけるまで、基本的に何も行いません。このフィルタ処理を実行すれば、生成される診断データの量を減らし、その時点で管理者にとって意味のあるデータのみを生成することができます。
次に、カスタム モニタ用に整形された META-INF/weblogic-diagnostics.xml ファイルの例を示します。
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90/diagnostics.xsd">
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>MyCustomMonitor</name>
<enabled>true</enabled>
<action>TraceAction</action>
<location-type>before</location-type>
<pointcut>call( * com.foo.bar.* get* (...));</pointcut>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>
カスタム モニタの場合、<name> は、開発者が指定した任意の文字列です。このモニタはカスタムなので、アクションの呼び出し用にあらかじめ定義された診断ロケーションはありません。記述子ファイルでは、診断ロケーションの種類とポイントカット式を定義する必要があります。この例では、TraceActionc アクションは、ポイントカット式で定義されたメソッドが呼び出される前 (<location-type>before</location-type) に呼び出されます。この例のポイントカット式は、以下のように渡されます (ワイルドカードの使い方に注意してください)。
したがって、このポイントカット式は、パッケージ com.foo.bar とそのサブパッケージ内にあるすべてのクラスの get*() を一致対象にします。メソッドは、void を含む任意の型の値を返すことができます。また、任意の型の引数を、数に制限なく持つことができます。インスツルメンテーション コードは、これらのメソッドの前に挿入され、そのメソッドが呼び出される直前に、TraceAction アクションが呼び出されます。
ポイントカットの定義に使用する文法の詳細については、「カスタム モニタのポイントカットの定義」を参照してください。
カスタム モニタでは、診断アクションの呼び出し場所を指定するポイントカット式をユーザが作成するので、代理モニタよりも柔軟な操作が可能です。代理モニタの場合は、アクション ライブラリからアクションを選択する必要があります。
ジョインポイントは、精密に定義された、プログラム内の固有の位置です。ポイントカットは、ジョインポイントのセットを指定する式です。この節では、AspectJ ポイントカット構文の一部を使用して、ポイントカットの式がどのように定義されるかについて説明します。
カスタム モニタでは 2 種類のポイントカットを指定できます。
<pointcut> ::= <execution-pointcut> | <callsite-pointcut>
<execution-pointcut> ::=execution( <access-type> <joinpoint-signature> )
<callsite-pointcut> ::=call( <joinpoint-signature> )
<joinpoint-signature> ::= <method-signature>
<method-signature> ::= <return-type> <class-type>.<method-name> ( <parameter-list> )
<return-type> ::= <class-type> | <primitive-type>
<parameter-list> ::= <parameter-type> (, <parameter-type>) *
<parameter-type> ::= <class-type> | <primitive-type> | <elepsis>
<class-type> ::= (<use-class-heirarchy>) ?<class-or-interface-name-pattern>
<use-class-heirarchy> ::= '+'
<elepsis> ::= '...'
*) は、クラスの型やメソッド名に使用できます。 ...) は、その引数以外に任意の型の引数がいくつか (数は可変) あることを示します。 + (プラス記号) プレフィックスは、指定したクラス/インタフェース パターンを実装しているすべてのサブクラス、サブインタフェース、または具象クラスを示します。 たとえば、以下のポイントカットは、パッケージ com.foo.bar とそのサブパッケージ内にあるすべてのクラスの、初期化された全パブリック メソッドのメソッド実行を一致対象にします。初期化されたメソッドは、void を含む任意の型の値を返すことができます。また、任意の型の引数を、数に制限なく持つことができます。
execution(public * com.foo.bar.* initialize(...))
以下のポイントカットは、com.foo.bar.MyInterface インタフェース (または、たまたまクラスだった場合はサブクラス) を直接または間接的に実装するすべてのクラスにあるメソッド呼び出し (呼び出しサイト) を一致対象にします。名前が get で始まり、int 値を返すパブリック メソッドが対象になります。また、メソッドは、java.lang.String 型の引数 1 つを受け付けるものでなければなりません。
call(int +com.foo.bar.MyInterface get*(java.lang.String))
以下の例では、ブール演算子を使用してポイントカット式ツリーを構築する方法を示します。
call(void com.foo.bar.* set*(java.lang.String)) OR
call( * com.foo.bar.* get*())
以下の例では、前の式ツリーが、コンフィグレーション ファイルでどのように <pointcut> 要素として変換されるかを示します。
<pointcut>call(void com.foo.bar.* set*(java.lang.String)) OR
call( * com.foo.bar.* get*())</pointcut>
アプリケーションが適切な形式の META-INF/weblogic-diagnostics.xml 診断記述子ファイルでデプロイされた場合、インスツルメンテーション コンポーネントは、適合するアプリケーション クラスがロードされたときに、自動的に診断インスツルメンテーション コードをそのクラスに挿入します。
この記述子はアプリケーションの ear アーカイブ内に指定することも、war、rar、ejb などのスタンドアロン モジュール内に指定することもできます。また、展開形式のアーカイブにも展開形式でないアーカイブにも指定できます。
注意 : アプリケーションの ear アーカイブに war、rar、または ejb モジュールが含まれ、それらの META-INF ディレクトリに weblogic-diagnostics.xml 記述子がある場合、そのような記述子は無視されます。
デプロイメント制御用に用意された任意の標準 WebLogic Server ツールを使用できます。こうしたツールには、Administration Console や WebLogic Scripting Tool (WLST) などがあります。
weblogic.PlanGenerator ツールを使用すると、初期状態のデプロイメント プランを作成できます。またこのツールには weblogic-diagnostics.xml 記述子の特定のプロパティを対話形式でオーバーライドする機能もあります。たとえば、プランを作成するには、次のように指定します。
java weblogic.PlanGenerator -root c:\exportapps\myApplication
PlanGenerator ツールは、選択したアプリケーションにあるすべての J2EE デプロイメント記述子を確認し、アプリケーション用に外部リソースをコンフィグレーションする WebLogic Server デプロイメント プロパティのうち、関連するものに対して、変数部分が指定されていないデプロイメント プランを作成します。
デプロイメント プランの作成と使用に関する詳細については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Configuring Applications for Production Deployment」を参照してください。
アプリケーションの WebLogic Server デプロイメント コンフィグレーションをカスタム デプロイメント プランにエクスポートする際の詳細 (PlanGenerator の使用手順も含む) については、『WebLogic Server 9.0 アプリケーションのデプロイメント』の「Exporting an Application for Deployment to New Environments」を参照してください。
アプリケーション内の診断モニタを動的に制御するためには、デプロイメント プランでアプリケーションをデプロイする必要があります。この場合も、管理者は、Administration Console や WebLogic Scripting Tool (WLST) を始めとする、デプロイメント制御用に用意された任意の標準 WebLogic Server ツールを使用できます。たとえば、次の WLST コマンドでは、対応するデプロイメント プランでアプリケーションをデプロイします。
wls:/mydomain/serverConfig> deploy('myApp', './myApp.ear', 'myserver',
'nostage', './plan.xml')
デプロイメント後に有効な診断モニタ コンフィグレーションは、元の記述子と、プランから得られるオーバーライドされた属性値の組み合わせです。元の記述子に所定の名前のモニタが含まれず、プランでそのモニタの属性をオーバーライドした場合、そのモニタはアプリケーションで使用されるモニタのセットに追加されます。このように、アプリケーションが空の weblogic-diagnostics.xml 記述子と一緒にビルドされていれば、デプロイメント プロセス中にアプリケーションのアーカイブを変更せずにアプリケーションに診断モニタを追加できます。
アプリケーション内のインスツルメンテーション モニタは、デプロイメント プラン (JSR-88) メカニズムで動的に制御できます。デプロイメント プランを使用すると、ビルド後のアプリケーションに診断モニタを追加できます。この際、アプリケーションのアーカイブを変更する必要はありません。ただし、アプリケーション インスツルメンテーションが機能するためには、アプリケーションに空の weblogic-diagnostics.xml 記述子が少なくとも 1 つある必要があります。デプロイメント プランを使用すると、アプリケーションのアーカイブ内の記述子にはないモニタを追加できます。また、デプロイメント プランを用いるとモニタの特定の属性を更新することもでき、この際にサーバを再起動したりアプリケーションを再デプロイしたりする必要はありません。たとえば、アプリケーションを再デプロイせずに、診断モニタを有効または無効にしたり、モニタに対してアクションを追加または削除したりできます。
すでに紹介したツールを用いてデプロイメント プランを変更しアプリケーションを更新するだけで、デプロイ済みのアプリケーションで使用されているモニタを動的に制御できます。たとえば、モニタを有効または無効にしたり、モニタにアタッチされているアクションを追加または削除したりできます。また、モニタの仕分けフィルタの有効化または無効化、仕分けマスクの変更も動的に行えます。こうした変更はアプリケーションを再デプロイしなくても直ちに有効になります。たとえば、次の WLST コマンドを使用して、変更後のプランの値でアプリケーションを更新します。
wls:/mydomain/serverConfig> updateApplication('testapp',
'c:/tmp/plan.xml')
|
|
|