| Oracle® Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方 11g リリース 1 (10.3.1) B55523-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方 11g リリース 1 (10.3.1) B55523-01 |
|
戻る |
次へ |
WLDF インスツルメンテーション コンポーネントは、要求 (HTTP リクエストまたは RMI リクエスト) をユニークに識別し、それらの要求がシステムで処理される過程を追跡する手段を提供します。システムに参加するあらゆる要求の特定の特性 (発信元のユーザ、クライアント アドレスなど) を確認し、その要求に診断コンテキストをアタッチするように WLDF をコンフィグレーションすることができます。このコンフィグレーションによって、特定の要求の経過時間などを測定でき、すべての要求がシステムを通過する際にどのように処理されているかを把握することができます。
診断コンテキストは、要求の特性を表す 64 ビットの仕分けベクトルとユニークなコンテキスト ID から構成されます。特定の要求に関連付けられたコンテキスト ID はイベント アーカイブに記録され、以下の処理に使用できます。
インスツルメンテーション イベントの生成を抑制する。つまり、指定された条件に一致する場合のイベントの生成頻度を決定します。
ログ レコードを要求に関連付ける。
WLDF アクセサ コンポーネントを使用して、ログ レコードやイベント レコードの検索をフィルタ処理する。（「データ アクセサを使用した診断データへのアクセス」）を参照してください。
以下の節では、診断コンテキストのコンフィグレーションと使用のプロセスについて説明します。
診断コンテキストには、ユニークなコンテキスト ID と 64 ビットの仕分けベクトルが含まれます。仕分けベクトルには、要求に関連付けられた診断コンテキストの特性を識別するために設定されるフラグが含まれます。現在、仕分けベクトルの32ビットはそれぞれの利用可能な仕分けフラグあたり1つずつ使用されています （表 11-1 を参照）。
要求の診断コンテキストはその要求がシステムに参加したとき (たとえばクライアントで HTTP リクエストを発行したとき) に作成され、初期化されます。診断コンテキストは、要求がスレッド境界や Java 仮想マシン (Java Virtual Machine JVM) 境界を越えてもその要求にアタッチされ続けます。診断コンテキストは、要求のライフ サイクル全体を通して存続します。
すべての診断コンテキストは、ドメイン内でユニークなコンテキスト ID によって識別されます。このコンテキスト ID は要求と共に移動するため、特定の要求がシステムで処理される過程でその要求に関連付けられたイベントやログ エントリを特定することができます。
コンテキスト情報は、64 ビットの仕分けベクトルとして要求と共に移動します。それぞれのビットは仕分けの存在を識別するフラグです。各仕分けが要求の 1 つの属性 (発信したユーザ、発信したクライアント IP アドレス、アクセス プロトコルなど) を表します。
特定の属性に対応する仕分けフラグが設定されている場合、その属性が存在することを示しています。フラグが設定されていない場合、その属性が存在しないことを示しています。
たとえば、以下のようなコンフィグレーションを考えます。
要求の発信元が IP アドレス 127.0.0.1 であることを示すために仕分けフラグ ADDR1 がコンフィグレーションされています。
要求の発信元が IP アドレス 127.0.0.2 であることを示すために仕分けフラグ ADDR2 がコンフィグレーションされています。
USER1 フラグは、ユーザ admin@avitek.com からのリクエストを示すためにコンフィグレーションされます。
IP アドレス 127.0.0.1 からの要求がシステムに参加すると、その要求の仕分けベクトルの ADDR1 仕分けフラグが設定されます。ADDR2 と USER1 仕分けフラグは設定されません。
admin@avitek.com からの要求が 127.0.0.1 か 127.0.0.2 以外の IPアドレスからのシステムを登録する場合、要求に対して仕分けベクトルに USER1 フラグが設定されます。ADDR1 と ADDR2 仕分けフラグは設定されません。
admin@avitek.com からの要求が 127.0.0.2 の IP アドレスからシステムを登録する場合、要求に対する仕分けベクトルに USER1 と ADDR2 フラグが設定されます。ADDR1 フラグは設定されません。
診断コンテキストを利用する診断およびモニタ機能では、仕分けベクトルを調査することにより、1 つまたは複数の属性が存在する (すなわち、関連付けられたフラグが設定されている) かどうかを特定することができます。上記の例では、診断モニタをコンフィグレーションして、ADDR1 仕分けの設定されたすべての要求、つまり IP アドレス 127.0.0.1 から発信されたすべての要求を追跡できます。ADDR1 と USER1 の両方で IP アドレス 127.0.0.1 のユーザ admin@avitek.com からのあらゆる要求を追跡する診断モニターをコンフィグレーションできます。(127.0.0.1 以外のユーザからの要求は追跡されません。)
また、仕分けベクトルには受信する要求に仕分設定の頻度を指定する THROTTLE 仕分けもあります。この特別な仕分けの詳細については、「THROTTLE 仕分けフラグ」を参照してください。
利用できる仕分けとそれによって表される属性のリストについては、「DyeInjection モニタでサポートされる仕分け」を参照してください。仕分けベクトルをコンフィグレーションおよび使用するプロセスについては、この章の以降の節で説明します。
診断コンテキストは、診断モジュールの一部としてコンフィグレーションされます。診断コンテキストをコンフィグレーションするのにサーバ レベルに DyeInjection モニタを使用します。DyeInjection モニターが標準診断モニタであるので、振舞いを変更できません。DyeInjection モニタがコードにウィービングされるジョインポイントは、要求がシステムに参加する可能性のある場所です。
診断アクションによって、各要求が DyeInjection モニタのコンフィグレーションに対してチェックされてから、その要求にコンテキストが作成されてアタッチされ、必要に応じた仕分けフラグが設定されます。要求に設定される仕分けフラグが、下流の診断モニタに対してコンフィグレーションされる仕分けフラグに適合する場合、要求の関連 Context ID があるイベントは Event アーカイブに追加されます。たとえば、要求が USER1 と ADDR1 仕分けフラグのみを設定し、USER1 と ADDR1 フラグ設定の両方で対して要求を追跡するためのコンフィグレーションされた診断モニタがある場合（他に設定されたフラグがない）イベントは Event アーカイブに追加されます。
診断モニタのタイプ、(ジョインポイントを定義する) ポイントカット、および診断アクションについては、「インスツルメンテーションのコンフィグレーション」を参照してください。
ここでは、サーバ スコープの診断モジュールにおけるコンテキストのコンフィグレーションと使用について概説します。
DyeInjection モジュールを介して仕分けベクトルをコンフィグレーションします。「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」を参照してください。
システムに要求が入ると、その要求の診断コンテキストが WLDF によって作成されインスタンス化されます。このコンテキストには、ユニークなコンテキスト ID と仕分けベクトルが含まれます。
DyeInjection モニタは、WLDF 診断モジュール内でシステム レベルで有効化されている場合、その要求を調査して、仕分けベクトルでコンフィグレーションされている仕分け値のいずれかが要求の属性と一致しているかどうかを確認します。たとえば、その要求の発行元が USER1 または USER2 に関連付けられているユーザかどうか、および ADDR1 または ADDR2 に関連付けられている IP アドレスかどうかが確認されます。
DyeInjection モニタは、要求の属性に一致する各仕分け値について、診断コンテキスト内で関連付けられている仕分けビットを設定します。たとえば、DyeInjection モニタが、USER1=weblogic、USER2=admin@avitek.com、ADDR1=}127.0.0.1、ADDR2=}127.0.0.2 のようにコンフィグレーションされており、要求の発行元が IP アドレス 127.0.0.2 のユーザ weblogic である場合、仕分けベクトル内で USER1 および ADDR2 仕分けビットが設定されます。
要求がシステム内を移動する過程では、仕分けベクトルを持つ診断コンテキストもその要求と共に移動します。この 64 ビットの仕分けベクトルの内容はフラグのみで、値は含まれません。そのため、この例では明示的に設定した 2 つのフラグ USER1 と ADDR2 のみが仕分けベクトルに含まれます。これには USER1 と ADDR2 に関する実際のユーザ名と IP アドレスは含まれていません。
|
注意 : すべての仕分けベクトルには、暗黙的に PROTOCOL 仕分け群の 1 つも含まれます。これについては、「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」で説明します。 |
管理者は下流のコード内で診断モニタ (アプリケーション スコープまたはサーバ スコープの診断モニタ) がアクティブとなるようにコンフィグレーションし、そのモニタの仕分けマスクを USER1 および ADDR2 として設定します。詳細については、「仕分けフィルタを使用するための代理モニタのコンフィグレーション」を参照してください。
診断モニタは、診断コンテキストの仕分けベクトルで設定されている仕分けフラグが診断モニタの仕分けマスクと一致すると、関連付けられている 1 つまたは複数のアクションを実行します。詳細については、「仕分けマスクによるモニタへ渡す要求のフィルタ方法」を参照してください。この例では、USER1 と ADDR2 フラグが仕分けベクトルに設定されていると、モニタは動作を実行します。さらに、要求に関連するイベントがイベント アーカイブに書き込まれます。
システムに参加するすべての要求に対して診断コンテキストを作成するには、次の手順に従います。
モニタする 1 つまたは複数のサーバ用に診断モジュールを作成して有効にします。
診断モジュールのインスツルメンテーションを有効にします。
モジュールの DyeInjection モニタをコンフィグレーションして有効にする。(1 つのモジュールで同時に使用できる DyeInjection モニタは 1 つのみ)。
DyeInjection モニタをコンフィグレーションするには、仕分けベクトルの仕分けに値を割り当てます。利用できる仕分けフラグについては、表 11-1 で説明します。
たとえば、USER1=weblogic、USER2=admin@avitek.com、ADDR1=127.0.0.1、ADDR2=127.0.0.2 などのようにフラグを設定できます。基本的に、モニタする要求の発行元となる 1 人または複数のユーザ、1 つまたは複数の IP アドレスに対して 1 つまたは複数のフラグの値を設定します。
たとえば、IP アドレスが 127.0.0.1 のクライアントから admin@avitek というユーザによって開始されたすべての要求をモニタするには、値 admin@avitek を USER1 に、値 127.0.0.1 を ADDR1 に割り当てます。
Administration Console で仕分けに値を割り当てるには、[DyeInjection の設定] ページの [プロパティ] フィールドに値を入力します。手順については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「診断システム モジュールの診断モニタのコンフィグレーション」を参照してください。
これらの設定は、診断モジュールの記述子ファイルでは以下のコード リストに示すように表されます。
コード リスト 11-1 DyeInjection モニタのコンフィグレーションのサンプル DIAG_MODULE内
<wldf-resource> <name>MyDiagnosticModule</name> <instrumentation> <enabled>true</enabled> <wldf-instrumentation-monitor> <name>DyeInjection</name> <enabled>true</enabled> <dye-mask xsi:nil="true"></dye-mask> <properties>ADDR1=127.0.0.1 USER1= admin@avitek </properties> </wldf-instrumentation-monitor> <!-- インスツルメンテーションをコンフィグレーションするための他の要素 --> <instrumentation> <!-- この診断モニタをコンフィグレーションするための他の要素 --> <wldf-resource>
仕分けベクトルで利用できる仕分けについて、以下の表にリストして説明します。
表 11-1 サポートされる診断コンテキストの仕分けと対応する要求のプロトコル
| 仕分けフラグ | 説明 |
|---|---|
|
ADDR1 ADDR2 ADDR3 ADDR4 |
仕分け ADDR1、ADDR2、ADDR3、および ADDR4 を使用して、要求を発信したクライアントの IP アドレスを指定する。DyeInjection モニタのプロパティ (ADDR1、ADDR2、ADDR3、ADDR4) に指定されている IP アドレスから要求が発信されると、それぞれ対応する仕分けフラグがその要求の診断コンテキストに設定される。 これらの仕分けを使用して DNS 名を指定することはできない。 |
|
CONNECTOR1 CONNECTOR2 CONNECTOR3 CONNECTOR4 |
仕分け CONNECTOR1、CONNECTOR2、CONNECTOR3、および CONNECTOR4 を使用して、コネクタ ドライバの特性を識別する。 これらの仕分けフィルタは、コネクタ ドライバによって状況に特有の要求のプロパティを識別するために設定される。これらは、ユーザが Administration Console または記述子ファイルに直接コンフィグレーションするものではない。これらの仕分けにはコネクタ ドライバによって (コネクタ API を使用して) 値が割り当てられ、その結果、接続に関する情報が診断コンテキストに保持されて運ばれる。 |
|
COOKIE1 COOKIE2 COOKIE3 COOKIE4 |
COOKIE1、COOKIE2、COOKIE3、および COOKIE4 は、HTTP または HTTPS 要求に weblogic.diagnostics.dye というクッキーが含まれていて、その値が DyeInjection モニタのそれぞれに対応するプロパティ (COOKIE1、COOKIE2、COOKIE3、COOKIE4) の値と同じ場合に、その要求の診断コンテキストに設定される。 |
|
DYE_0 DYE_1 DYE_2 DYE_3 DYE_4 DYE_5 DYE_6 DYE_7 |
DYE_0 から DYE_7 は、アプリケーションの開発者のみが使用できる。weblogic.diagnostics.context の使い方を参照してくさい。 |
|
PROTOCOL_HTTP PROTOCOL_IIOP PROTOCOL_JRMP PROTOCOL_RMI PROTOCOL_SOAP PROTOCOL_SSL PROTOCOL_T3 |
DyeInjection モニタにより要求に使用されているプロトコルが暗黙的に識別され、使用されているプロトコルに応じて、仕分けベクトルの適切な仕分け (1 つまたは複数) が設定される。 PROTOCOL_HTTP は、要求に HTTP または HTTPS プロトコルが使用されている場合に要求の診断コンテキストに設定される。 PROTOCOL_IIOP は、要求に Internet Inter-ORB Protocol (IIOP) プロトコルが使用されている場合に要求の診断コンテキストに設定される。 PROTOCOL_JRMP は、要求に Java Remote Method Protocol (JRMP) プロトコルが使用されている場合に要求の診断コンテキストに設定される。 PROTOCOL_RMI は、要求に Java Remote Method Invocation (RMI) プロトコルが使用されている場合に要求の診断コンテキストに設定される。 PROTOCOL_SSL は、要求に Secure Sockets Layer (SSL) プロトコルが使用されている場合に要求の診断コンテキストに設定される。 PROTOCOL_T3 は、要求に T3 または T3 プロトコルが使用されている場合に要求の診断コンテキストに設定される。 |
|
THROTTLE |
THROTTLE 仕分けは、要求が DyeInjection モニタの THROTTLE_INTERVAL または THROTTLE_RATE プロパティに指定された要件を満たす場合に、要求の診断コンテキストに設定される。 |
|
USER1 USER2 USER3 USER4 |
仕分け USER1、USER2、USER3、および USER4 を使用して、要求を発信したクライアントのユーザ名を指定する。DyeInjection モニタのプロパティ (USER1、USER2、USER3、USER4) に指定されているユーザによって要求が発信されると、それぞれに対応する仕分けフラグがその要求の診断コンテキストに設定される。 |
DyeInjection モニタの仕分けフラグ USERn, ADDRn, COOKIEn, and CONNECTORn については、明示的に値を設定する必要があります。一方、フラグ PROTOCOL_HTTP、PROTOCOL_IIOP、ROTOCOL_JRMP、PROTOCOL_RMI、PROTOCOL_SOAP、PROTOCOL_SSL および PROTOCOL_T3は、WLDF により暗黙的に設定されます。DyeInjection モニタが有効になっていれば、すべての要求に適切なプロトコルの仕分けが挿入されます。たとえば、HTTP によって届いた要求にはすべて仕分け PROTOCOL_HTTP が挿入されます。
THROTTLE 仕分けフラグを使用して、受信要求のうち仕分けを設定するものの量を制御できます。THROTTLE は他のフラグとは異なる方法でコンフィグレーションされ、WLDF での使用方法も異なります。詳細については、「インスツルメンテーション イベントの量を制御するスロットル機能の使い方」を参照してください。
診断モジュールで DyeInjection モニタが有効になっている場合、受信するすべての要求について診断コンテキストが作成されます。診断モジュールでインスツルメンテーションを有効にするとき、DyeInjection モニタはデフォルトで有効にされます。これにより診断コンテキスト ID が利用でき、イベントが関連付けられます。DyeInjection モニタに明示的に設定されているプロパティがない場合でも、ユニークなコンテキスト ID と、暗黙的な PROTOCOL 仕分け群のうち 1 つが指定された仕分けベクトルがすべての要求のコンテキストに含まれます。
DyeInjection モニタが診断モジュールに無効になっている場合、受信するどの要求についても診断コンテキストは作成されません。
DyeInjection モニタを、診断モジュールの代理診断モニタまたはカスタム診断モニタのトリガ条件を制限するメカニズムとして使用できます。このプロセスを仕分けフィルタと呼びます。
それぞれのモニタに仕分けマスクを設定できます。仕分けマスクには DyeInjection モニタから選択された仕分けが指定されます。診断モニタに対して仕分けフィルタが有効になっている場合、マスクで設定された条件に一致する要求でのみ、モニタの診断アクションがトリガされ、診断イベントが生成されます。
図 11-2 に、コンフィグレーションされている診断アクションがトリガされたときに、生成された診断イベントの例を示します。すべてのイベントのコンテキスト ID が同じであることが分かります。これは、これらのイベントが同じ要求に関連していることを示しています。このコンテキスト ID を使用して、要求に関連付けられているログ レコードを問い合わせることができます。要求に関連付けられているユーザ ID と DyeInjection モニタでコンフィグレーションした USER 値は常に同じではありません。要求がシステムで処理される過程で、その要求に関連付けられているユーザが変わることによって、システムで特定の機能を実行することができます (たとえば、ユーザ ID が kernel に変わる場合があります)。
サンプル コンフィグレーション
TraceElapsedTimeAction アクションがアタッチされている Servlet_Around_Service アプリケーション スコープの診断モニタについて検討します。仕分けフィルタが有効になっていない場合、Servlet_Around_Service で処理されるすべての要求によって TraceElapsedTimeAction がトリガされます。ただし、IP アドレス 127.0.0.1 のユーザ admin@avitek.com からの要求に対してのみ TraceElapsedTimeAction のトリガとして仕分けフィルタを使用できます。
DyeInjection モニタで USER1=admin@avitek.com と ADDR1=127.0.0.1 とコンフィグレーションして、DyeInjection モニタを有効にします。手順については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「診断システム モジュールの診断モニタのコンフィグレーション」を参照してください。
仕分けマスクをコンフィグレーションして、Servlet_Before_Service 診断モニタの仕分けフィルタを有効にします。Administration Console で次の手順に従います。
『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「アプリケーションのインスツルメンテーションのコンフィグ」の説明にあるように、Servlet_Around_Service モニタを WLDF インスツルメンテーションライブラリからアプリケーションに追加してください。
モニタの追加後、[<アプリケーション名> の設定] ページで [保存] をクリックします。
[Servlet_Around_Service] リンクをクリックし、[Servlet_Around_Service の設定] ページを表示します。
[有効] チェック ボックスを選択してモニタを有効にします。
[アクション] 下の [使用可能] リストから [選択済み] リストに [TraceElapsedTimeAction] を移動します。
[仕分けマスク] セクションで、[USER1] および [ADDR1] を [使用可能] リストから [選択済み] リストへ移動します。
[仕分けフィルタを有効化] チェック ボックスを選択します。
[保存] をクリックします。
アプリケーションを再デプロイします。
Administration Console で追加したコンフィグレーションは、アプリケーションの META-INF ディレクトリの weblogic-diagnostics.xml ファイルや DIAG_MODULE.xml ファイルには保持されず、アプリケーションのデプロイメント プランに保存されます。
DIAG_MODULE.xml ファイルを手作業で更新して診断モニタを追加することもできます (コード リスト 11-2 を参照) が、この方法を推奨されません。コンフィグレーションは、実行サーバの Administration Console で変更することをお勧めします。DIAG_MODULE.xml に対して行った変更は、アプリケーションを再デプロイするまで有効になりません。
コード リスト 11-2 代理モニタで仕分けフィルタを使用するコンフィグレーションのサンプル (DIAG_MODULE.xml 内)
<wldf-resource> <name>MyDiagnosticModule</name> <instrumentation> <enabled>true</enabled> <wldf-instrumentation-monitor> <name>DyeInjection</name> <enabled>true</enabled> <properties>ADDR1=127.0.0.1 USER1=admin@avitek.com</properties> </wldf-instrumentation-monitor> <wldf-instrumentation-monitor> <name>Servlet_Around_Service</name> <dye-mask>ADDR1 USER1</dye-mask> <dye-filtering-enabled>true</dye-filtering-enabled> <action>TraceElapsedTimeAction</action> </wldf-instrumentation-monitor> <!-- インスツルメンテーションをコンフィグレーションするための他の要素 --> </instrumentation> <!-- 診断モニタをコンフィグレーションするための他の要素 --> <wldf-resource>
このコンフィグレーションでは、IP アドレス 127.0.0.1 とユーザ admin@avitek.com から発信された要求でのみ Servlet_Around_Service 診断モニタの TraceElapsedTimeAction アクションがトリガされます。
診断モニタでイネーブルとなるフラグは、イベント アーカイブに書きこむように要求の仕分けベクトルで動作がトリガされるように設定されたビットとイベントに正確に一致する必要があります。たとえば、診断モニタが USER1 と ADDR1 フラグの両方をイネーブルにし、USER1フラグのみを要求の仕分けベクトルで設定されると、トリガされる動作はなく、イベントも生成されません。
|
注意 : 診断モニタをコンフィグレーションする際、同じタイプの複数のフラグを有効化しないでください。たとえば、USER1 フラグと USER2 フラグの両方を有効化しないでください。これは、特定の要求の仕分けベクトルで USER1 フラグと USER2 フラグの両方が設定されない場合があるためです。 |
要求にアタッチされる仕分けベクトルには複数の仕分けを指定でき、代理モニタにアタッチされる仕分けマスクにも複数の仕分けを指定できます。代理モニタの仕分けマスクを使用して、モニタが要求に対してアクションを実行できるようにするには、以下の条件をすべて満たしている必要があります。
アプリケーションの weblogic-diagnostics.xml 記述子で、代理モニタまたはカスタム モニタの仕分けフィルタが有効になっている。
要求の仕分けベクトルに、モニタの仕分けマスクで定義されているすべての仕分けが含まれている(仕分けベクトルには、仕分けマスクにない仕分けが含まれている可能性もあります)。
図 11-3 では、3 つの診断モニタを持つ診断モジュールを使用した仕分けフィルタの仕組みを示しています。
DyeInjection モニタは次のようにコンフィグレーションされている。
ADDR1=127.0.0.1 USER1=weblogic
Servlet_Around_Service モニタには、ADDR1 のみを含む仕分けマスクがコンフィグレーションされている。
EJB_Around_SessionEjbBusinessMethods モニタには、USER1 のみを含む仕分けマスクがコンフィグレーションされている。
IP アドレス 127.0.0.1 のユーザ guest によって開始された要求がシステムに届きます。ユーザ guest は DyeInjection モニタの USER1 の値に一致しないため、この要求は仕分けベクタ USER1 で仕分けされません。発信元 IP アドレス (127.0.0.1) は DyeInjection モニタで定義された ADDR1 の値に一致するため、要求は仕分けベクタ ADDR1 で仕分けされます。
要求 (ADDR1 で仕分け済み) が Servlet コンポーネントに届きます。このコンポーネントでは、診断モニタ Servlet_Around_Service がコード内に織り込まれています。（Servlet_Around_Service は特定のサーブレット メソッドまたは JSP メソッドの入り口と出口で、診断アクションをトリガします)。このモニタでは仕分けモニタが有効になっており、仕分けマスクには ADDR1 という値が 1 つ定義されています。
Servlet_Around_Service でインスツルメンテーションされているメソッドに要求が入るか出るときに、診断モニタは要求に仕分けベクトル ADDR1 があるかどうかをチェックし、その仕分けベクトルが検出されます。その結果、モニタは診断アクションをトリガします。イベント アーカイブへのデータの書き込みなどの診断イベントが発生します。
要求が SessionEJB コンポーネントに届きます。このコンポーネントでは、診断モニタ EJB_Around_SessionEjbBusinessMethods がコード内に織り込まれています。(EJB_Around_SessionEjbBusinessMethods はすべての SessionBean メソッドの入り口と出口で診断アクションをトリガします)。このモニタでは仕分けモニタが有効になっており、仕分けマスクには USER1 という値が 1 つ定義されています。
Servlet_Around_Service でインスツルメンテーションされているメソッドに要求が入るか出るときに、診断モニタは要求に仕分けベクトル USER1 があるかどうかをチェックし、その仕分けベクトルが見つかります。したがって、モニタは診断アクションをトリガしないので、診断イベントは発生しません。
スロットル機能を使用すると、診断モジュールのモニタで処理される要求の数を制御できます。スロットル機能は、DyeInjection モニタに定義される THROTTLE 仕分けを使用してコンフィグレーションします。
|
注意 : USERn および ADDR n 仕分けを使用すると、特定のユーザまたは IP アドレスからの要求を調べることができます。ただし、任意のユーザ トランザクションを調べる手段にはなりません。THROTTLE 仕分けでは、要求のサンプリングによりその機能を提供します。 |
仕分けベクトルの他の仕分けと異なり、THROTTLE 仕分けは 2 つのプロパティを通じてコンフィグレーションされます。
THROTTLE_INTERVAL に、新しく受信される要求に THROTTLE 仕分けが指定されるまでの間隔 (ミリ秒) を設定する。
THROTTLE_INTERVAL が 0 より大きい場合、DyeInjection モニタでは、最後に THROTTLE 仕分けが指定された要求が届いてから少なくとも THROTTLE_INTERVAL のミリ秒数だけ経過した後に受信された要求に対して、その新しい要求の仕分けベクトルにある THROTTLE 仕分けフラグが設定されます。たとえば THROTTLE_INTERVAL=3000 と指定した場合、DyeInjection モニタでは少なくとも 3000 ミリ秒の待機後に、受信したリクエストに THROTTLE 仕分けが指定されます。
THROTTLE_RATE に、新しく受信される要求に THROTTLE 仕分けが指定される度合い (受信される要求の数で表す) を設定する。
THROTTLE_RATE が 0 より大きい場合、DyeInjection モニタでは、最後に THROTTLE 仕分けが設定された要求以降の要求の数が THROTTLE_RATE と同じになったときに、受信された要求の仕分けベクトルにある THROTTLE 仕分けフラグが設定されます。たとえば、THROTTLE_RATE = 6 と指定した場合、6 要求ごとに THROTTLE 仕分けが指定されます。
THROTTLE_INTERVAL と THROTTLE_RATE は併用できます。いずれかの要求を満たす場合、要求は THROTTLE 仕分けされます。
THROTTLE_INTERVAL または THROTTLE_RATE のどちらかに値を割り当てる場合 (両方に割り当てることもいずれにも割り当てないことも可)、THROTTLE 仕分けがコンフィグレーションされます。Administration Console での THROTTLE コンフィグレーションの設定を、以下の図に示します。
コード リスト 11-3 に、結果として診断モジュールの記述子ファイルに記述されるコンフィグレーションを示します。
コード リスト 11-3 DyeInjection モニタの THROTTLE コンフィグレーションのサンプル、DIAG_MODULE.xml 内
<wldf-resource> <name>MyDiagnosticModule</name> <instrumentation> <wldf-instrumentation-monitor> <name>DyeInjection</name> <properties> THROTTLE_INTERVAL=3000 THROTTLE_RATE=6 </properties> </wldf-instrumentation-monitor> </instrumentation> <!-- この診断モニタをコンフィグレーションするための他の要素 --> </wldf-resource>
コード リスト 11-4 に、仕分けマスクに THROTTLE 仕分けが設定されている JDBC_Before_Start_Internal 代理モニタのコンフィグレーションを示します。
コード リスト 11-4 代理モニタの仕分けマスクに THROTTLE を設定するコンフィグレーションのサンプル (DIAG_MODULE.xml 内)
<wldf-resource> <name>MyDiagnosticModule</name> <instrumentation> <wldf-instrumentation-monitor> <name>JDBC_Before_Start_Internal</name> <enabled>true</enabled> <dye-mask>THROTTLE</dye-mask> </wldf-instrumentation-monitor> </instrumentation> <!-- この診断モニタをコンフィグレーションするための他の要素 --> </wldf-resource>
仕分けマスクおよび仕分けフィルタによるメカニズムを使用して、代理モニタおよびカスタム モニタで処理するために渡す要求を、要求のプロパティに基づいて制限できます。「DyeInjection モニタを介した仕分けベクトルのコンフィグレーション」で説明したように、要求におけるプロパティの存在は仕分けの存在によって示されます。THROTTLE 仕分けもそうした仕分けの 1 つと見なされるため、THROTTLE も他の仕分けと同様にフィルタできます。
以下に、スロットル機能の処理方法について説明します。
代理モニタまたはカスタム モニタの仕分けフィルタが有効になっていてモニタに仕分けマスクがある場合、仕分けマスクに基づいてフィルタが実行される。このマスクには THROTTLE 仕分けが含まれても含まれなくても構いません。仕分けマスクに THROTTLE が含まれる場合、モニタに渡される要求の仕分けベクトルにも THROTTLE が含まれている必要があります。一方、仕分けマスクに THROTTLE が含まれない場合、要求の仕分けベクトルに THROTTLE が含まれているかどうかに関わらず、適切な要求はすべてモニタに渡されます。
代理モニタまたはカスタム モニタの仕分けフィルタが有効でなく、DyeInjection モニタに THROTTLE プロパティが設定されていない場合、仕分けフィルタもスロットル機能も実行されない。
代理モニタまたはカスタム モニタの仕分けフィルタが有効でなく、DyeInjection モニタに THROTTLE がコンフィグレーションされている場合、代理モニタでは仕分けマスクが無視されるが、すべての要求について THROTTLE 仕分けの存在がチェックされる。THROTTLE 仕分けの指定された要求のみが代理モニタに渡されて処理されます。したがって、THROTTLE_RATE または THROTTLE_INTERVAL (あるいはその両方) を DyeInjection モニタに設定すると、すべての代理モニタで処理される要求の数が減少します。スロットル機能を利用するために、すべての代理モニタに仕分けマスクをコンフィグレーションする必要はありません。
代理モニタまたはカスタム モニタの仕分けフィルタが有効になっていて、仕分けマスクに設定されている仕分けが THROTTLE のみの場合、THROTTLE 仕分けが指定されている要求のみが代理モニタに渡される。この動作は、仕分けフィルタが有効でなく DyeInjection モニタに THROTTLE がコンフィグレーションされている場合と同じです。
weblogic.diagnostics.context パッケージを使用すると、アプリケーションから診断コンテキストに制限付きでアクセスできます。
アプリケーションでは一連の weblogic.diagnostics.context.DiagnosticContextHelper API を使用して、以下の関数を実行できます。
診断コンテキストの不変のコンテキスト ID の調査。
コンテキストの仕分けベクトルにある仕分けフラグの設定の調査。
有効な仕分けフラグ名の配列の取得。
コンテキストの仕分けベクトルにある DYE_0 から DYE_7 までのフラグについての設定または設定の解除。(これらのフラグ ビットを XML を介して設定する方法はありません。DyeInjection モニタの <properties> をコンフィグレーションすると、アプリケーション固有でないフラグ ビットについて XML を介して設定できますが、仕分けベクトルの DYE_0 から DYE_7 までを設定できるのは setDye() メソッドのみです)。
診断コンテキストへのペイロード (String 型) のアタッチ、または既存のペイロードの読み込み。
以下についてはアプリケーションでは処理できません。
アプリケーション用に予約されている 8 フラグ以外の仕分けベクトルのフラグの設定。
仕分けベクトルの同じアプリケーション フラグが別のアプリケーションで設定されることの回避。適切に動作するアプリケーションであれば、仕分けフラグを設定する前にあらかじめ設定されているかどうかをテストできます。
別のアプリケーションによるペイロードの置き換えの回避。適切に動作するアプリケーションであれば、ペイロードを追加する前にペイロードが存在するかどうかをテストできます。
アプリケーションで DYE_0 から DYE_7 までのフラグうち 1 つまたは複数を設定した時点以降には、モニタや別のアプリケーションでそれらのフラグをチェックするように仕分けマスクを設定し、そのフラグ (群) がコンテキストの仕分けベクトルに存在する場合にアクションを実行できます。診断コンテキストにペイロードがアタッチされている場合、モニタで実行されるアクションはペイロードに格納されてアーカイブ化され、結果としてアクセサ コンポーネントを通じて利用できるようになります。
コード リスト 11-5 は、診断コンテキストを (暗黙的に) 作成し、コンテキスト ID を出力して、DYE_0 フラグの値をチェックした上で設定する簡単なサンプルです。
コード リスト 11-5 サンプル : DiagnosticContextExample.java
package weblogic.diagnostics.examples;
import weblogic.diagnostics.context.DiagnosticContextHelper;
public class DiagnosticContextExample {
public static void main(String args[]) throws Exception {
System.out.println("\nContextId=" +
DiagnosticContextHelper.getContextId());
System.out.println("isDyedWith(DYE_0)=" +
DiagnosticContextHelper.isDyedWith(DiagnosticContextHelper.DYE_0));
DiagnosticContextHelper.setDye(DiagnosticContextHelper.DYE_0, true);
System.out.println("isDyedWith(DYE_0)=" +
DiagnosticContextHelper.isDyedWith(DiagnosticContextHelper.DYE_0));
}
}
