Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用

11gリリース1(10.3.6)

B60994-04(原本部品番号:E13714-05)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- WebLogic診断フレームワークとは

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- ダウンロードのために利用可能なWLDF例

- このリリースでの新機能と変更点

2 WLDFアーキテクチャの概要

- WebLogic診断フレームワークの概要

- データの作成、収集、およびインストゥルメンテーション

- アーカイブ

- 監視および通知

- データ・アクセサ

- 監視ダッシュボードおよびリクエスト・パフォーマンス・ページ

- 監視ダッシュボード

- 診断リクエスト・パフォーマンス・ページ

- 診断イメージ・キャプチャ

- 全体の構成

3 Oracle JRockitフライト・レコーダと連携したWLDFの使用

- Oracle JRockitフライト・レコーダについて

- JRockitフライト・レコーダとのWLDF統合の主な機能

- JRockitフライト・レコーダのユース・ケース

- クリティカル障害の診断 - 「ブラック・ボックス」

- パフォーマンス・テストまたは本番の場合のプロファイリング

- リアルタイム・アプリケーション診断および報告(RADAR)

- JRockitフライト記録ファイルの取得

- JRockit Mission Control内のフライト・レコーダ・データの分析

- JFRグラフィカル・ユーザー・インタフェース

- 実行フローの分析 - サンプル・ウォークスルー

- 製品サブコンポーネントのイベント・データの表示

- 詳細を示すためのイベント・ログの表示

- 操作セットの分析による実行フローのトラキング

- 操作セットの展開および相関診断データの表示

- 一時JFRファイルの場所の変更

4 WLDF構成について

- 構成MBeanとXML

- WLDFの構成用ツール

- WLDF構成の区分

- サーバー・レベルの構成

- アプリケーション・レベルの構成

- 診断イメージ・キャプチャと診断アーカイブの構成

- JRockitフライト・レコーダ用の診断イメージ・キャプチャの構成

- 診断システム・モジュールの構成

- 診断システム・モジュールとそのリソース記述子

- config.xmlからの診断システム・モジュールの参照

- DIAG_MODULE.xmlリソース記述子の構成

- 診断システム・モジュールの管理

- 診断システム・リソースの構成の詳細

- アプリケーション用の診断モジュールの構成

- WLDF構成MBeanとXML要素へのマッピング

5 診断イメージの構成とキャプチャ

- イメージ・キャプチャの開始方法

- 診断イメージ・キャプチャの構成

- WLDF診断ボリュームの構成

- イメージ・キャプチャ生成用のWLSTコマンド

- サーバーの構成における診断イメージ・キャプチャの永続化

- キャプチャされたイメージ・ファイルの内容

- 診断イメージ・キャプチャ・ファイルに含まれるデータ

- 診断イメージ・キャプチャのダウンロード用のWLSTオンライン・コマンド

6 診断アーカイブの構成

- アーカイブの構成

- ファイル・ベースのストアの構成

- JDBCベースのストアの構成

- データベースでのWLDF表の作成

- WLDF用のJDBCリソースの構成

- アーカイブのデータの廃棄

- サーバー・レベルでのデータ廃棄の構成

- 診断アーカイブに対する期間に基づいたデータ廃棄ポリシーの構成

- サンプル構成

7 メトリック収集用のハーベスタの構成

- メトリック収集、収集可能データ、および収集対象データ

- 様々な収集可能エンティティからのデータ収集

- ハーベスタの構成

- ハーベスタのサンプリング期間の構成

- 収集するデータの種類の構成

- WebLogic Server MBeanとカスタムMBeanの型名の指定

- DomainRuntime MBeanServerからの収集

- 構成設定を検証するタイミング

- 様々な収集可能な型の構成のサンプル

8 監視および通知の構成

- 監視および通知

- 監視および通知の構成の概要

- 監視および通知の構成のサンプル

9 監視の構成

- 監視の種類

- すべての種類の監視で共有される構成オプション

- ハーベスタ監視の構成

- ログ監視の構成

- インストゥルメンテーション監視の構成

- 監視ルール式の定義

10 通知の構成

- 通知の種類

- JMX通知の構成

- JMS通知の構成

- SNMP通知の構成

- SMTP通知の構成

- イメージ通知の構成

11 インストゥルメンテーションの構成

- 概念と用語

- インストゥルメンテーションのスコープ

- 構成とデプロイメント

- ジョインポイント、ポイントカット、診断ロケーション

- 診断モニターのタイプ

- 診断アクション

- インストゥルメンテーション構成ファイル

- インストゥルメンテーションに使用するXML要素

- <Instrumentation> XML要素

- <wldf-instrumentation-monitor> XML要素

- 各モニター・タイプへの<wldf-instrumentation-monitor>のXML要素のマッピング

- サーバー・スコープのインストゥルメンテーションの構成

- アプリケーション・スコープのインストゥルメンテーションの構成

- システム・スコープのインストゥルメンテーションとアプリケーション・スコープのインストゥルメンテーションの比較

- アプリケーションのインストゥルメントに必要な手順の概要

- 委任モニターの記述子ファイルの作成

- カスタム・モニターの記述子ファイルの作成

- カスタム・モニターのポイントカットの定義

- アノテーション・ベースのポイントカット

- リクエスト・パフォーマンス・データの作成

12 診断コンテキストを管理するためのDyeInjectionモニターの構成

- 診断コンテキストの内容、ライフサイクル、構成

- コンテキストのライフ・サイクルとコンテキストID

- 仕分け、仕分けフラグ、仕分けベクトル

- 診断コンテキストが構成される場所

- プロセスの概要

- DyeInjectionモニターを介した仕分けベクトルの構成

- DyeInjectionモニターでサポートされる仕分け

- PROTOCOL仕分けフラグ

- THROTTLE仕分けフラグ

- 診断コンテキストの作成条件

- 仕分けフィルタを使用するための委任モニターの構成

- 仕分けマスクによるモニターへ渡すリクエストのフィルタ方法

- 仕分けフィルタの例

- インストゥルメンテーション・イベントの量を制御するスロットル機能の使用

- THROTTLE仕分けの構成

- 委任モニター、カスタム・モニターでのスロットル機能の処理方法

- weblogic.diagnostics.contextの使い方

13 データ・アクセサを使用した診断データへのアクセス

- データ・アクセサのアクセス対象のデータ・ストア

- 診断データへのオンライン・アクセス

- 管理コンソールを使用してデータへのアクセス

- ランタイムMBeanを使用してプログラム的にデータへのアクセス

- WLSTを使用してオンラインで診断データへのアクセス

- データ・アクセサでWLDF問合せ言語の使用

- 診断データへのオフライン・アクセス

- 診断データへのプログラム的なアクセス

- システム・クロックをリセットすることによるデータのアーカイブおよび取得に対する影響

14 WLDFアプリケーション・モジュールのデプロイメント

- 診断モジュールのアプリケーション・スコープ・リソースとしてのデプロイ

- インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用

- デプロイメント・プランの使用:概要

- weblogic.PlanGeneratorによるデプロイメント・プランの作成

- 診断用のデプロイメント・プランのサンプル

- Javaホットスワップ機能の有効化

- デプロイメント・プランによるアプリケーションのデプロイ

- 変更したプランによるアプリケーションの更新

15 監視ダッシュボードの使用

- 監視ダッシュボードの実行

- 表示される診断情報の範囲

- 監視ダッシュボードのインタフェースについて

- ビュー・リスト

- メトリック・ブラウザ

- ビューの表示のパネル

- メトリックの収集と表示の方法

- メトリックおよびチャート・タイプについて

- 現在時間範囲チャート

- カスタム時間範囲チャート

- メトリック・データが表示される順序

- メトリック・データ保存に関する注意

- チャートの構成要素

16 WLDFのプログラム的な構成と使用

- WLDFによるデータの生成と取得

- BeanおよびパッケージへのWLDFコンポーネントのマッピング

- プログラミング・ツール

- 構成APIと実行時API

- 構成API

- 実行時API

- WLDFパッケージ

- WLDFプログラミング:サンプル

- サンプル: DiagnosticContextExample.java

- サンプル: HarvesterMonitor.java

- 通知リスナー

- HarvesterMonitor.java

- サンプル: JMXAccessorExample.java

A WLDF問合せ言語

- 問合せ式の構成要素

- サポートされる演算子

- 演算子の優先順位

- String型の列でサポートされる数値の比較演算

- サポートされる数値定数と文字列リテラル

- 式内の変数について

- 監視ルール式の作成

- ログ・イベントの監視ルール式の作成

- インストゥルメンテーション・イベントの監視ルール式の作成

- ハーベスタの監視ルール式の作成

- データ・アクセサ問合せの作成

- データ・ストアの論理名

- データ・ストアの列名

- ログ・フィルタ式の作成

- 複雑な式の作成

B WLDFインストゥルメンテーション・ライブラリ

- 診断モニター・ライブラリ

- 診断アクション・ライブラリ

- TraceAction

- DisplayArgumentsAction

- TraceElapsedTimeAction

- TraceMemoryAllocationAction

- StackDumpAction

- ThreadDumpAction

- MethodInvocationStatisticsAction

- MethodInvocationStatisticsActionを使用したアプリケーションのインストゥルメントと結果に対する問合せ

- MethodInvocationStatisticsActionデータを収集するためのハーベスタの構成

- MethodInvocationStatisticsメトリックに基づく監視ルールの構成

- JMXによるデータの収集

- MethodMemoryAllocationStatisticsAction

C 式でのワイルドカードの使用

- ハーベスタ・インスタンス名でのワイルドカードの使用

- 例

- ハーベスタの複合属性およびネストされた属性の指定

- 例

- 収集された複合属性またはネストされた属性に関するアクセサの使用

- 監視ルール・インスタンス名でのワイルドカードの使用

- ハーベスタの監視ルールでの複合属性の指定

D WebLogic Scripting Toolのサンプル

- サンプル: DyeInjectionモニターの動的な作成

- 例: 監視とJMX通知の構成

- サンプル: JMXWatchNotificationListenerクラスの記述

- サンプル:収集用のMBeanと属性の登録

- 例: WLDF診断ボリュームの設定

- 例: 診断イメージのキャプチャ

- 例: 診断イメージ・キャプチャからのJFRファイルの取得

用語集

Oracle® Fusion Middleware

Oracle WebLogic Server診断フレームワークの構成と使用

11gリリース1(10.3.6)

B60994-04(原本部品番号:E13714-05)

2011年11月

このドキュメントでは、WLDFによるモニター・サービスと診断サービスを構成および使用する方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用, 11gリリース1(10.3.6)

B60994-04

Copyright © 2007, 2011, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、このガイド『Oracle WebLogic診断フレームワークの構成と使用』のドキュメント・アクセシビリティ機能と使用されている表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

次の項では、『WebLogic診断フレームワークの構成と使用』ガイドの内容と読者について説明します。

- WebLogic診断フレームワークとは

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サンプルとチュートリアル

- このリリースでの新機能と変更点

WebLogic診断フレームワークとは

WebLogic診断フレームワーク(WLDF)とは、WebLogic Serverのプロセス内で実行され標準的なサーバーのライフサイクルに参加する、一連のサービスを定義および実装するモニターおよび診断フレームワークです。WLDFを使用すると、実行中のサーバーおよびそのコンテナ内にデプロイされているアプリケーションによって生成された、診断データを作成、収集、分析、アーカイブし、それらのデータに対するアクセスを行うことができます。このデータを基に、サーバーおよびアプリケーションの実行時パフォーマンスを把握できます。また、フォルト発生時に、このデータを使用して、フォルトを隔離および診断できます。

WLDFには、以下のようなデータの収集および分析用コンポーネントが含まれています。

- Oracle JRockitとの統合 - WebLogic ServerがJRockitとともに構成されている場合、WLDFはJRockitフライト記録ファイルで取得したWebLogic Serverに関する診断情報を生成することができます。

- 診断イメージ・キャプチャ - 障害発生後の分析に使用できる診断スナップショットをサーバーから作成します。診断イメージ・キャプチャには、JRockitフライト・レコーダ・データが含まれていて、それが使用可能である場合、JRockit Mission Controlで表示できます。

- アーカイバ - サーバー・インスタンスおよびアプリケーションから、データ・イベント、ログ・レコード、およびメトリックをキャプチャし、永続化します。

- インストゥルメンテーション - WebLogic Serverインスタンスおよびその上で実行されているアプリケーションに診断コードを追加し、コード内の指定された場所で診断アクションを実行します。インストゥルメンテーション・コンポーネントは、システム内のリクエストの流れを追跡できるように、診断コンテキストをリクエストに関連付けるための手段を提供します。WebLogic Server管理コンソールには、アプリケーションにおけるパフォーマンスの問題の識別に役に立つツールとして機能しているWLDFインストゥルメンテーション機能から取得したメソッド・パフォーマンス情報のリアルタイムおよび履歴ビューを表示する「リクエスト・パフォーマンス」ページが含まれています。

- ハーベスタ - WebLogic Server MBeanやカスタムMBeanなどのランタイムMBeanからメトリックをキャプチャします。メトリックはアーカイブして、履歴データを参照するために後でアクセスできます。

- 監視および通知 - サーバーおよびアプリケーションの状態をモニターし、監視の中で設定されている条件に基づいて通知を送信する手段を提供します。

- 監視ダッシュボード - WebLogic Serverおよびホストされたアプリケーションの現在の動作状態と動作状態の履歴をグラフィカルに表示します。WebLogic Server管理コンソールからアクセスされた監視ダッシュボードは、重要性の高いランタイムWebLogic Serverのパフォーマンス・メトリックおよびそれらのメトリックの一定時間での変化を表示するビューに診断データを編成し表示するための一連のツールを提供します

- ロギング・サービス - サーバー、サブシステムおよびアプリケーション・イベントを監視するためのログを管理します。WebLogic Serverロギング・サービスは、WebLogic診断フレームワークの他の部分とは別個のドキュメントで説明されています。『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。

WLDFは、診断データに対する動的なアクセスと制御を可能にする標準化された一連のアプリケーション・プログラミング・インタフェース(API)、ならびにサーバーに関する可視性をもたらす改良されたモニターを実現します。独立系ソフトウェア・ベンダー(ISV)は、カスタム・モニタリングとWLDFとの統合に使用される診断ツールの開発にこれらのAPIを使用できます。

WLDFにより、標準インタフェースを通じてサーバー・データへの動的なアクセスが可能となり、特定の時点にアクセスされたデータを、サーバーの停止および再起動を行うことなく変更できます。

ドキュメントのスコープと対象読者

このドキュメントでは、WLDFによるモニター・サービスと診断サービスを構成および使用する方法について説明します。

WLDFは、WebLogic Serverインスタンスおよびクラスタを実行する際の問題点や、それらにデプロイされているアプリケーションにおける問題点をモニターし、診断するための機能を提供します。したがって、このドキュメント内の情報は、システム管理者とアプリケーション開発者の双方を対象としています。また、WLDFをサポートおよび拡張するツールを構築するサード・パーティのツール開発者向けの情報も記載しています。

読者は、Webテクノロジ、およびWebLogic Serverがインストールされているオペレーティング・システムとプラットフォームに精通していることが前提となっています。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- この章「概要とロードマップ」では、WLDFコンポーネントの概要を示し、このガイドの対象読者について説明します。

- 第2章「WLDFアーキテクチャの概要」では、WLDFアーキテクチャの概要を示します。

- 第3章「Oracle JRockitフライト・レコーダと連携したWLDFの使用」では、JRockitフライト・レコーダのWLDF統合機能および基本使用方法のシナリオを説明し、JRockitフライト・レコーダ・ファイルに取得されたWebLogic Serverイベントを確認するためにJRockit Mission Controlを使用したサンプル・ウォークスルーを提供します。

- 第4章「WLDF構成について」では、WLDFの機能がサーバーとアプリケーションでどのように構成されるかについての概要を示します。

- 第5章「診断イメージの構成とキャプチャ」では、サーバーの重要な構成設定と状態のスナップショットをキャプチャするために、WLDF診断イメージ・キャプチャ・コンポーネントを構成および使用する方法について説明します。

- 第6章「診断アーカイブの構成」では、診断データをファイル・ストアまたはデータベースで永続化するために、WLDF診断アーカイブ・コンポーネントを構成および使用する方法について説明します。

- 第7章「メトリック収集用のハーベスタの構成」では、WebLogic Server MBeanおよびカスタムMBeanを含むランタイムMBeanからメトリックを収集するために、WLDFハーベスタ・コンポーネントを構成および使用する方法について説明します。

- 第8章「監視および通知の構成」では、WLDF監視および通知の概要を示します。

- 第9章「監視の構成」では、指定した条件に対してサーバー・インスタンスおよびアプリケーションをモニターして、その条件に合致した場合に通知を送信するように監視を構成する方法について説明します。

- 第10章「通知の構成」では、監視によってトリガー可能な通知を構成する方法について説明します。

- 第11章「インストゥルメンテーションの構成」では、WebLogic Serverクラスおよびサーバー上で実行しているアプリケーションのクラスに診断インストゥルメンテーション・コードを追加する方法について説明します。

- 第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」では、DyeInjectionモニターを使用する方法、および診断モニターで仕分けフィルタを使用する方法について説明します。

- 第13章「データ・アクセサを使用した診断データへのアクセス」では、診断データを取得するためにWLDFデータ・アクセサ・コンポーネントを使用する方法について説明します。

- 第14章「WLDFアプリケーション・モジュールのデプロイ」では、診断アプリケーション・モジュールとしてアプリケーションのインストゥルメンテーションを構成および管理する方法について説明します。

- 第15章「監視ダッシュボードの使用方法」では、WebLogic Serverの現在の動作状態および動作状態の履歴、およびWLDFでキャプチャした診断データを一部的に使用するホストされたアプリケーションをグラフィカルに表示する方法について説明します。

- 第16章「WLDFのプログラムの構成と使用」では、JMX APIおよびWebLogic Scripting Tool (weblogic.WLST)を使用してWLDFの各コンポーネントを構成および使用する方法について概要を示します。

- 付録A「WLDF問合せ言語」では、データ・アクセサを使用して診断データを問合わせたり、監視ルールを作成したり、ログをフィルタ処理するためのルールを作成する式を作るためのWLDF問合せ言語について説明します。

- 付録B「WLDFインストゥルメンテーション・ライブラリ」では、WLDFインストゥルメンテーション・ライブラリであらかじめ定義されている診断モニターと診断アクションについて説明します。

- 付録C「式でのワイルドカードの使用方法」では、どのようにワイルドカードをWLDF式で使用するかについて説明します。

- 付録D「WebLogic Scripting Toolのサンプル」では、WebLogic Scripting Toolを使用してWLDFモニター・アクティビティと診断アクティビティを実行する方法の例を示します。

- 「用語集」はWLDFの用語集です。

関連ドキュメント

- 『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』では、WLDFロギング・サービスを使用してサーバー、サブシステムおよびアプリケーション・イベントをモニターする方法を説明します。

- 管理コンソール・オンライン・ヘルプのWebLogic診断フレームワークの構成に関する項では、WebLogic管理コンソールのビジュアル・ツールを使用してWLDFを構成する方法を説明します。

- WLDFシステム・リソース記述子はweblogic-diagnostics.xsdスキーマに準拠しています。このスキーマは、http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsdで参照できます。

サンプルとチュートリアル

このドキュメントの他にも、WLDFの構成や使い方を示す様々なサンプルとチュートリアルが用意されています。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、推奨されるベスト・プラクティスを重要点として示します。MedRecはWebLogic Server配布キットに含まれており、Windowsマシンの「スタート」メニューからアクセスできます。Linuxなどのプラットフォームでは、WL_HOME\samples\domains\medrecディレクトリからMedRecを起動できます。WL_HOMEは、WebLogic Platformの最上位ディレクトリです。

ダウンロード可能なWLDFサンプル

https://www.samplecode.oracle.com/sf/projects/codesamples/には、ダウンロード用の追加のWLDFサンプルがさらにあります。これらのサンプルは、既存WebLogic Serverサンプル・ディレクトリ構成に展開できる.zipファイルとして配布されています。これらのサンプルには、Oracleが認定したもののほかに、開発協力者から提示されたサンプルもあります。

このリリースでの新機能と変更点

2つの診断モニターが追加されました。

- JDBC_After_Reserve_Connection_Internal

- JDBC_After_Release_Connection_Internal

サーバー・レベルで、WLDFモジュールでこれらの診断モニターを構成できます。JDBC接続の予約時と解放時の可視性が高まります。詳細は、「診断モニター・ライブラリ」を参照してください。

このリリースで導入されたWebLogic Serverの総合的な新機能一覧は、『Oracle WebLogic Serverの新機能』を参照してください。

2 WLDFアーキテクチャの概要

WebLogic診断フレームワーク(WLDF)は、WebLogic Serverインスタンスとそのインスタンスがホストするアプリケーションに関する診断情報の収集、アーカイブ、およびアクセスを行うために共同で動作する、いくつかのコンポーネントで構成されています。この章では、これらのコンポーネントのアーキテクチャの概要を示します。

注意:
この章では、WLDFの仕組みが理解しやすくなるように概念を説明しています。構成APIや実行時API、およびWebLogic Server管理コンソールにおけるWLDFの表現とは異なる部分もあります。すぐWLDFを構成して、使用し始めたい場合、この議論をスキップして第4章「WLDF構成について」から始めても支障はありません。

次の項では、WLDFアーキテクチャについて説明します。

- WebLogic診断フレームワークの概要

- データの作成、収集、およびインストゥルメンテーション

- アーカイブ

- 監視および通知

- データ・アクセサ

- 監視ダッシュボードおよびリクエスト・パフォーマンス・ページ

- 診断イメージ・キャプチャ

- 全体の構成

WebLogic診断フレームワークの概要

WLDFは以下で構成されています。

- データ・クリエータ(WLDFコンポーネント全体に分散されるデータ・パブリッシャおよびデータ・プロバイダ)

- データ・コレクタ(ロガー・コンポーネントとハーベスタ・コンポーネント)

- アーカイブ・コンポーネント

- アクセサ・コンポーネント

- インストゥルメンテーション・コンポーネント

- 監視および通知コンポーネント

- イメージ・キャプチャ・コンポーネント

- 監視ダッシュボード

データ・クリエータは、ロガーやハーベスタによって消費される診断データを生成します。ロガーおよびハーベスタ・コンポーネントは、アーカイブと連携してデータを永続化し、監視および通知サブシステムと連携して自動化されたモニターを提供します。アクセサは、ロガーおよびハーベスタと対話して現在の診断データを公開し、アーカイブと対話して履歴データを提示します。イメージ・キャプチャ機能は、主要なサーバーの状態の診断スナップショットをキャプチャする手段を提供します。これらのコンポーネント間の関係を図2-1に示します。

図2-1 主要なWLDFコンポーネント

「図2-1 主要なWLDFコンポーネント」の説明

すべてのフレームワーク・コンポーネントは、サーバー・レベルで動作し、サーバーのスコープしか認識しません。コンポーネントはすべてサーバーのプロセス内に存在し、標準的なサーバーのライフサイクルに参加しています。フレームワークのアーティファクトはすべて、サーバーごとに構成および格納されます。

データの作成、収集、およびインストゥルメンテーション

診断データは、いくつかのソースから収集されます。これらのソースは論理的に、現在の値を収集するために一定の間隔でサンプリングされるデータ・クリエータであるデータ・プロバイダか、同期的にイベントを生成するデータ・クリエータであるデータ・パブリッシャのいずれかに分類できます。データ・プロバイダとデータ・パブリッシャはコンポーネント全体にわたって配布され、図2-2 に示されているように、ロガー および/またはハーベスタによって生成されたデータを収集することができます。

図2-2 データ作成コンポーネントとデータ収集コンポーネントの関係

「図2-2 データ作成コンポーネントとデータ収集コンポーネントの関係」の説明

サーバー・ロギング・インフラストラクチャの呼出しは、インライン・データ・パブリッシャとして機能し、生成されたデータは、イベントとして生成されます。(ロギング・インフラストラクチャは、カタログ・インフラストラクチャかデバッグ・モデルを通じて、または直接ロガーを通じて呼び出せます)。

インストゥルメンテーション・コンポーネントは、モニターを作成して実行フロー内の定義された位置に挿入します。モニターはアーカイブにデータを直接パブリッシュします。

MBeanサーバーに登録されたコンポーネントも、ハーベスタに登録することでデータ・プロバイダとして認識できるようになります。収集されたデータは、監視および通知システムに公開されて自動的にモニターされると共に、アーカイブに公開されて永続化されます。

アーカイブ

システム内のフォルトの診断において、過去の状態が重要性を持つことがしばしばあります。そのため、状態をキャプチャして将来アクセスできるようアーカイブし、履歴アーカイブを作成しておくことが必要となります。WLDFでは、複数の永続化コンポーネントを持つアーカイブ・コンポーネントが、この要件に対応しています。イベントおよび収集されたメトリックの双方が、永続化されて履歴確認できるようになります。

人間に判読可能であり、サーバー・ログに含めることが意図されている、従来のロギング情報は、標準のロギング・アペンダによって永続化されます。システムでの消費が意図されている新しいイベント・データは、イベント・アーカイバを使用してイベント・ストア内で永続化されます。メトリック・データは、データ・アーカイバを使用して、データ・ストア内に永続化されます。アーカイブとロガーおよびハーベスタとの関係を図2-3 に示します。

アーカイブがアクセス・インタフェースを提供するので、アクセサは任意の永続化された履歴データを公開できるようになります。

図2-3 アーカイブとロガーおよびハーベスタとの関係

「図2-3 アーカイブとロガーおよびハーベスタとの関係」の説明

監視および通知

監視および通知システムは、特定の診断状態を観察する自動化されたモニターを作成し、構成されたルールに基づいて通知を送信するのに使用できます。

監視ルールでは、ログ・データ、インストゥルメンテーション・コンポーネントのイベント・データ、ハーベスタによって収集されるデータ・プロバイダのメトリック・データをモニターできます。監視マネージャは、いくつかの監視ルールで構成される監視の管理を行うことができます。関係は図2-4 に示します。

図2-4 ロガーおよびハーベスタと、監視および通知システムの関係

「図2-4 ロガーおよびハーベスタと、監視および通知システムの関係」の説明

1つまたは複数の通知を、監視による使用に備えて構成できます。デフォルトでは、各監視が、サーバー・ログ内にイベントを記録します。SMTP、SNMP、JMX、およびJMS通知もサポートされています。

データ・アクセサ

アクセサは、ログ、イベント、メトリック・データなど、WLDFによって収集されたすべてのデータへのアクセスを提供します。アクセサは、アーカイブと対話して、ログに記録されたイベント・データや永続化されたメトリックなどの履歴データを取得します。

実行中のサーバーのデータにアクセスする場合は、JMXベースのアクセス・サービスが使用されます。アクセサは、型、コンポーネント、および属性を基準としたデータ・ルックアップに対応しています。時間ベースのフィルタ処理を許可し、またイベントの場合には、重大度、ソース、およびコンテンツごとのフィルタ処理を許可します。

ツールでは、現在非アクティブなサーバーで永続化されたデータにアクセスすべき場合があります。そのような場合に備えて、オフライン・アクセサがあります。オフライン・アクセサを使用すると、後でアクセスできるように、アーカイブ済みのデータをXMLファイルにエクスポートすることができます。アクセサをこのように使用するには、WebLogic Scripting Tool (WLST)を使用します。また、マシンに物理的にアクセスする必要があります。

アクセサとハーベスタおよびアーカイブとの関係を、図2-5 に示します。

図2-5 オンラインおよびオフライン・アクセサとアーカイブの関係

「図2-5 オンラインおよびオフライン・アクセサとアーカイブの関係」の説明

監視ダッシュボードおよびリクエスト・パフォーマンス・ページ

WLDFでは、診断データが視覚的に表示される2つのWebページが用意されています。

- 監視ダッシュボード

- 診断リクエスト・パフォーマンス・ページ

監視ダッシュボード

監視ダッシュボードは、メトリック・ランタイムMBean属性を視覚的に提供し、WebLogic Serverおよびホストされたアプリケーションの現在および過去の動作状態を表示します。このメトリック・ランタイムMBean属性で、重要性の高いランタイム・パフォーマンス・メトリックの一部およびこのメトリックの一定期間での変更が表示されます。過去の動作状態が、アーカイブで永続化されている収集メトリックで表されています。収集されたメトリックをアーカイブから表示する場合、ハーベスタを構成して監視するデータをキャプチャする必要があります。

監視ダッシュボードは、メトリック情報の一連のビューを表示します。ビューは、メトリックを表示する1つ以上のチャートの集合です。監視ダッシュボードには、ドメイン内のすべての実行中のWebLogic Serverインスタンスに使用可能なランタイム・メトリックの組込みビューの事前定義したセットが含まれます。組込みビューは、重要性の高いランタイムWebLogic Serverパフォーマンス・メトリックの一部を提示し、監視ダッシュボードのグラフィック機能の例として機能します。

カスタム・ビューは、それを作成したユーザーのみ使用可能です。カスタム・ビューは自動的に永続化され、監視ダッシュボード・セッションを再起動すると、再度アクセスできます。

詳細は、第15章「監視ダッシュボードの使用」を参照してください。

診断リクエスト・パフォーマンス・ページ

WebLogic Server管理コンソールの診断リクエスト・パフォーマンス・ページには、インストゥルメンテーション・コンポーネントを使用してキャプチャしたメソッド・パフォーマンス情報のリアルタイムおよび履歴ビューが表示されます。リクエスト・パフォーマンス情報を表示する場合、このデータを使用するには、最初にインストゥルメンテーション・コンポーネントを構成する必要があります。

詳細は、「リクエスト・パフォーマンス・データの作成」を参照してください。

診断イメージ・キャプチャ

診断イメージ・キャプチャのサポートでは、問題の診断に使用される主要なサーバーの状態について最も一般的な情報を収集します。図2-6 に示されているように、技術者を支援するために利用可能な単一のアーティファクトにその状態をパッケージ化します。診断イメージは、実質的にはサーバーからの診断スナップショットまたはダンプであり、UNIXの「コア」ダンプと似ています。

WebLogic ServerがOracle JRockitで構成され、JRockitフライト・レコーダが無効になっていない場合、診断イメージ・キャプチャにはすべてのプロデューサから使用できるすべてのJRockitフライト・レコーダ・データが含まれます。また、JRockitフライト・レコーダでキャプチャされたWebLogic Server診断情報を生成するようにWLDFを構成すると、その情報もJFRファイルに含まれます。JFRファイルは診断イメージ・キャプチャから抽出し、JRockit Mission Controlで表示することができます。第3章「Oracle JRockitフライト・レコーダと連携したWLDFの使用」を参照してください。

イメージ・キャプチャ・サポートには次のものが含まれます。

- WebLogic Server管理コンソール、WLSTスクリプトまたはJMXアプリケーションから発行された操作またはコマンドにより、診断イメージ・キャプチャで作成されたオンデマンド・キャプチャ。

- 関連するハーベスタ監視、ログ監視またはインストゥルメンテーション監視のルールのトリガーに応じて、診断イメージ・キャプチャを自動的に作成するイメージ通知。たとえば、特定のランタイムMBeanインスタンスから収集されたメトリックでパフォーマンス問題が表示された場合、実行中サーバーのランタイムMBean属性を監視するハーベスタ監視でイメージ通知をトリガーできます。問題の原因を判断するために、診断イメージ・キャプチャのデータを分析できます。

詳細は、次を参照してください:

- 第5章「診断イメージの構成とキャプチャ」

- イメージ通知の構成

図2-6 診断イメージ・キャプチャ

「図2-6 診断イメージ・キャプチャ」の説明

全体の構成

図2-7は、WLDFのすべての要素がどのように組み合わさっているかを示します。

図2-7 WebLogic診断フレームワークの全体図

「図2-7 WebLogic診断フレームワークの全体図」の説明

3 Oracle JRockitフライト・レコーダと連携したWLDFの使用

WLDFには、JRockit Flight Recorderとの固有の統合点が用意されています。ランタイムまたはインシデント後処理の分析に対して共通データ・セットに含めるためにWebLogic Serverイベントをオプションでフライト・レコーダに伝播できます。また、フライト記録データはWLDF診断イメージ・キャプチャにも含まれています。それにより、WLDF監視ルールに基づいてフライト記録スナップショットを取得できます。この機能のフル・セットにより、JVMおよびFusion Middlewareの両方で実行しているコンポーネントに対してランタイム・システム情報を単一ビューで取得して、分析できます。

次の項では、WLDFのJRockitフライト・レコーダとの統合に関する概要を示し、この統合をWebLogic Serverに基づく本番システムに対しての包括的なパフォーマンス分析および診断ファウンデーションに提供する方法を表示する共通使用方法のシナリオについて説明します。

- Oracle JRockitフライト・レコーダについて

- JRockitフライト・レコーダとのWLDF統合の主な機能

- JRockitフライト・レコーダのユース・ケース

- JRockitフライト記録ファイルの取得

- JRockit Mission Control内のフライト・レコーダ・データの分析

Oracle JRockitフライト・レコーダについて

WebLogic Serverインストール・プログラムで利用可能なOracle JRockitのバージョンには、JRockitフライト・レコーダ(JFR)と呼ばれるコンポーネント、パフォーマンス監視およびプロファイリング・ツールが含まれています。JFRは、診断情報を継続的に記録して、システム・クラッシュなどの突発障害でもそれを利用可能にします。

JFRは、必要に応じてアクセスできるフライト記録またはJFRファイルと呼ばれる診断およびプロファイリング・データのバッファを保持します。図3-1で示されているように、フライト記録機能は、新しいデータが継続的に追加され、古いデータが削除される航空機の「ブラック・ボックス」と同じ方法で動作します。

図3-1 循環フライト記録のバッファ

「図3-1 循環フライト記録のバッファ」の説明

JFRフライト記録の詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』のフライト・レコーダ・データ・フローに関する項を参照してください。

イベントに対して生成されたシステム実行フローの詳細を検討するには、JFRファイルをいつでも分析できます。JFRファイルのデータには、JVMからのイベントおよびWebLogic ServerとOracle動的モニター・システム(DMS)などの他のイベント・プロデューサが含まれています。

JFRの記録を有効にする場合およびJFRでキャプチャするWebLogic Server診断が発生するようにWLDFを構成した場合に生じる追加処理オーバーヘッドの量は最小限です。これは、特に最大値を追加する本番環境でフルタイム・ベースで使用できます。

JFRには、次の重要な利点があります。

- 継続的に実行するように設計されている - フライト記録でキャプチャしたJVMとWLDFの両方のイベントでフルタイム・ベースで実行するようにJFRを構成すると、システム・クラッシュなどのイベントが発生したとき診断データを常に使用できます。これにより、イベントまでの診断データが使用できるようになり、イベントを再作成せずに診断することができます。

- 包括的なデータ - JFRでは、JRockitランタイム・アナライザおよびJRockit待機時間分析ツールによって、生成したデータが組み合され、1つの場所に表示されます。

- イベント・プロバイダとの統合 - JRockitでは、JFRによって、WebLogic Server、Oracle Dynamic Monitoring System (DMS)、および他のOracleの製品など追加システム・コンポーネントを監視できるAPIのセットが含まれます。

JFRの詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』のフライト・レコーダの概要に関する項を参照してください。

JRockitフライト・レコーダとのWLDF統合の主な機能

JFRとの統合を利用するために、WLDFで提供される主な機能には次のものが含まれます。

- JFRフライト記録でキャプチャされたWLDF診断データ
JFRフライト・レコードでキャプチャされたWebLogic Serverイベントの診断データを生成するようにWLDFを構成できます。キャプチャされたイベントには、Webアプリケーション、EJB、JDBC、JTAとJMSリソース、リソース・アダプタおよびWebLogic Webサービスなどのコンポーネントが含まれます。

- WLDF診断ボリュームの調節
フライト記録のWebLogic Serverイベント・データを生成する機能は、WLDF診断ボリューム構成によって制御されます。この制御では、JFRによってキャプチャされたWebLogic Serverイベント・データの量も決定し、生成された各WebLogic Serverのデータ量を調整できます。詳細は、「WLDF診断ボリュームの構成」を参照してください。

注意:

- デフォルトでは、WLDF診断ボリュームは低に設定されています。

- WLDF診断ボリューム設定は、明示的に構成された診断モジュールには影響しません。

- 負荷時の生成されたイベントの自動スロットル
該当WebLogic Serverインスタンスで処理される負荷を増加すると、WLDFはイベント発生とJFRファイルに記録するために選択された受信WebLogic Serverリクエストの数を自動的にスロットルし始めます。システム負荷の増加および下落に伴って、スロットルの程度は継続的に調整されます。

スロットルには、3つの重要な利点があります。

- JFR用のWLDFによって発生したキャプチャ・イベントのオーバーヘッドは、システムが特に負荷のかかっている状況の場合、最小化されます。

- JFRフライト記録のバッファに含まれる時間間隔が最大化され、よりよい履歴レコード・データが取得できます。

- スロットルには、サンプリング受信WebLogic Serverリクエストの影響があり、負荷のかかっている状況下でシステム・アクティビティの正確な包括的ビューを提供しながら高いパフォーマンスを維持します。

注意:
スロットルは、WLDFで取得したフライト記録データのみに影響します。これは、JVMなど、他のイベント・プロデューサによって取得されたデータに影響しません。

- JFRファイル用のWLDF診断イメージ・キャプチャ・サポート
フライト・レコーダによってJFRファイルが生成されている場合、WLDF診断イメージのキャプチャには自動的にJFRファイルが含まれます。JFRファイルには、WebLogic Serverを含むすべてのアクティブなイベント・プロデューサによって生成されたデータが含まれます。監視および通知コンポーネントを使用して取得したイメージには、可能な場合JFRファイルが含まれます。

- 診断イメージのキャプチャのコンテンツをダウンロードするWLSTコマンド
WLSTには、「診断イメージ・キャプチャのダウンロード用のWLSTオンライン・コマンド」で説明した診断イメージのキャプチャのコンテンツをダウンロードするコマンドが含まれています。一般的には、これらのコマンドは、診断イメージのキャプチャに含むすべてのエントリのリスト、コピーおよびダウンロードに役に立ちますが、可能な場合、JFRファイルの取得にも使用できます。一度診断イメージのキャプチャから取得すると、JFRファイルはJRockit Mission Controlで表示されます。

JRockitフライト・レコーダのユース・ケース

この項では、重要な診断に関する問題を解決するために役に立つJRockitフライト・レコーダを使用した3つの一般的なビジネス・ケースが要約されています。

- クリティカル障害の診断 - 「ブラック・ボックス」

- パフォーマンス・テストまたは本番の場合のプロファイリング

- リアルタイム・アプリケーション診断および報告(RADAR)

これらのシナリオの詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』のフライト・レコーダ・ユース・ケースに関する項を参照してください。

クリティカル障害の診断 - 「ブラック・ボックス」

「破滅的な」失敗が発生した場合、フライト・レコーダ・バッファの内容は、航空機のブラック・ボックスと類似した方法で問題発生後の解析として使用できます。アプリケーションの終了によって生じるJVMクラッシュまたはメモリー不足エラー(OOME)はこのような失敗の例です。

これらの状況では、フライト・レコードには、障害の原因を判別するのに役に立つ次の情報が含まれます。

- クラッシュのときのフライト・レコーダの構成のメタデータを含むJVMコア・ダンプ。さらに、フライト・レコーダが永続記憶城のモードで実行している場合、データ・バッファ・ファイルには、ある程度のデータが含まれている可能性があります。

- 障害が発生する前のWLDFによってキャプチャされたWebLogic Serverイベント。

永続モードで実行している場合、JFRはメモリーとディスクの組合せを使用して、そのバッファを格納します。最新のデータはメモリーに格納され、「古く」なるとディスクにフラッシュされます。このモードでは、停電または同様の大惨事が起こった場合もディスク上のデータは使用できます。最新のデータのみ使用できなくなりますん(たとえば、ディスクにフラッシュされていないデータ)。テキスト・ダンプ・ファイルには、適用可能な場合データ・バッファへのパスを含む大惨事の場合のフライト・レコーダ構成のメタデータがあります。永続モードの詳細は、『Oracle JRockit Flight Recorderラン・タイム・ガイド』のオペレーティング・モードに関する項を参照してください。

パフォーマンス・テストまたは本番の場合のプロファイリング

プロファイリングでは、特定時点で始まるデータがキャプチャされます。これによって、その時点の後に発生したイベントを分析することができます。次の項で説明するRADARとは対照的に、プロファイリングには、これより前のデータではなく、特定のイベントが発生した後に発生した診断データの分析が含まれます。

JRockitフライト・レコーダでのプロファイリングにより、ロック競合の詳細分析および待機時間の原因を実行する機能を最適化できます。

リアルタイム・アプリケーション診断および報告(RADAR)

RADARは、特定のイベントがそのイベントに先立つシステム・アクティビティを理解するために発生したときの実行時に生成される診断データの調査です。たとえば、重大なエラー・メッセージが生成される前に発生するシステム・アクティビティなどです。JRockit Flight RecorderとともにWLDFで利用できる診断機能を使用して、問題が発生する場合に大量のシステム全体の診断データを取得できます。そして、それぞれのイベントを他のシステム・アクティビティに迅速に関連付けるよう、JRockit Mission Controlの機能を利用して、JFRファイルに指定された「スナップショット時間」内に実行データを処理します。それにより、問題の原因を切り離すことができます。

イメージ通知は、JRockit Flight Recorderを使用してRADAR性能を強力にするWLDF機能の1つです。それにより、特定のイベントまたはエラー条件に対して診断イメージ・キャプチャを自動的に作成できます。イメージ通知の結果として作成された診断イメージ・キャプチャには、JFRファイルが自動的に含まれます。また、JFRファイルを診断イメージ・キャプチャから抽出でき、ただちにJRockit Mission Controlで調査するか、または後で分析するために保存できます。JRockit Flight RecorderによってWLDFデータが取得される時に使用するイメージ通知は、特にこの種類の断続的な問題のリアルタイム診断に適しています。

イメージ通知はWLDFの監視および通知システムの一部です。イメージ通知を設定するには、1つ以上の個々の監視ルールを作成します。監視ルールには、検出する監視のイベントを指定するためにWLDF問合せ言語を使用する論理式が含まれています。たとえば、次のログ・イベント監視ルールは、重大度レベルがクリティカルでIDがBEA-149618のサーバー・ログ・メッセージを検出します。

(SEVERITY = 'Critical') AND (MSGID = 'BEA-149618')

監視ルールは次のいずれかを監視できます。

- ローカル・ランタイムMBeanサーバー内の収集可能なランタイムMBeanインスタンス
ランタイムMBean属性が高メモリー使用率またはサーバーとのオープン・ソケット接続に関する問題などのパフォーマンス問題を検出する場合、ハーベスタの監視がイメージ通知をトリガーできます。

- サーバー・ログに発行されたメッセージ
特定のメッセージ、重大度レベルまたは文字列を発行する場合、ログ監視がイメージ通知をトリガーできます。

- WLDFインストゥルメンテーション・コンポーネントで生成されたイベント
インストゥルメンテーション・サービスが特定のイベントを生成する場合、イベント監視がイメージ通知をトリガーできます。

詳細については、次のトピックを参照してください。

- 第8章「監視および通知の構成」

- イメージ通知の構成

- 付録A「WLDF問合せ言語」

次の項では、診断イメージ・キャプチャからのJFRファイルの取得方法およびJFRファイルにあるWebLogic Serverイベントを確認するためのJRockit Mission Controlの使用例について説明します。

- JRockitフライト記録ファイルの取得

- JRockit Mission Control内のフライト・レコーダ・データの分析

JRockitフライト記録ファイルの取得

診断イメージ・キャプチャ自体は、異なるサーバー・サブシステムで作成された個々のイメージを含む単一のJFRファイルです。JFRファイルがある場合、それはファイルFlightRecording.jfrとして診断イメージに含まれています。

診断イメージ・キャプチャは、たとえばWebLogic Server管理コンソール、WLSTまたはJMXアプリケーションなどのオンデマンドで生成できます。または、イメージ通知の結果として生成できます。診断イメージ・キャプチャの生成方法および作成される場所の構成方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断イメージの構成と取得に関する項を参照してください。

JFRファイルの内容を表示するには、まず初めに、第5章「診断イメージの構成と取得」の説明に従って、診断イメージ・キャプチャからJFRファイルを抽出する必要があります。JFRファイルを抽出した後、JRockit Mission Controlでその内容を表示できます。

たとえば、診断イメージ・ファイルからJFRファイルを取得して、ローカル・ディレクトリに保存するWLSTスクリプトは、「サンプル: 診断イメージ・キャプチャからのJFRファイルの取得」を参照してください。

JRockit Mission Control内のフライト・レコーダ・データの分析

JRockit Mission Controlを使用して、診断イメージ・キャプチャから抽出した後にフライト・レコーダ・ファイルの内容を確認します。次の項では、WebLogic ServerイベントのWLDFのみならずJRockit JVMなどの他のすべての使用可能なイベント・プロデューサから生成された診断データにドリルダウンするためにツール・サポートの大部分を指定するJRockit Mission Controlグラフィカル・ユーザー・インタフェースの機能の一部について説明します。

- JFRグラフィカル・ユーザー・インタフェース

- 実行フローの分析 - サンプル・ウォークスルー

- 一時JFRファイルの場所の変更

JRockit Mission Controlインタフェースの詳細は、Oracle JRockit Mission Controlオンライン・ヘルプを参照してください。「JRockit Mission Controlクライアントの概要」も参照してください。

JFRグラフィカル・ユーザー・インタフェース

JRockit Mission ControlにはJRockitフライト・レコーダ・グラフィカル・ユーザー・インタフェースが含まれており、これによりOracle JRockitのフライト・レコーダ対応バージョンを実行しているユーザーはJVMの記録、現在の記録設定およびランタイム・パラメータを表示できます。JFRインタフェースには、イベント・プロデューサおよびタイプ、イベント・ロギングおよびグラフ化、スレッドによるイベント、イベント・スタック・トレースおよびイベント・ヒストグラムなどのJFRファイルに記録されたイベント情報に直接アクセスできるイベント・タイプ・ビューが含まれています。

JFRインタフェース内の「概要」タブを使用して、ボトルネックまたはシステム状態不良の他の原因を表す動作を公開できるため、システムの一般的な状態を分析できます。図3-2には、イベント・タイプ・ビュー内の「概要」タブの例を示します。

図3-2で示した情報について次の点に注意してください。

- 「イベント」タブ・グループのアイコンを選択して、「イベント・タイプ」ビューが表示されます。

- フライト・レコーダ・ファイル名が「概要」タブの上部に表示されます。JFRは常にFlightRecording.jfrと名付けられており、診断イメージ・キャプチャからダウンロードした後、これをわかりやすい名前に変更すると便利です。

- 左側の「イベント・タイプ」ブラウザは、記録にある使用可能なイベントを表示するツリーです。これは「イベント」タブ・グループとともに機能し、関心のあるイベントまたはイベントのグループを選択し、それについて詳細な情報を取得できます。
「イベント・タイプ」ブラウザでエントリの選択または選択解除すると、「概要」タブで表示される情報が動的にフィルタされます。たとえば、WebLogic Serverのみ選択すると、すべての非WebLogicイベント・プロデューサがフィルタされ除去されます。

- 範囲ナビゲータは、「概要」タブ・タイトルの下に表示されるグラフであり、選択したタブで表示されるデータに関連する記録のすべてのイベントを表示するタイムラインです。表示されたデータの範囲を調整するためにボタン・セットがあります。これによって、フライト・レコーダ・データの詳細へのドリルダウン処理が簡略化されます。

- 「プロデューサ」セクションでは、表示されているデータが発生した各イベント・プロデューサを識別されます。各プロデューサにメトリックがあり、表示されたイベント・データの総数セットの一部として各プロデューサによって生成されたアクティビティのボリュームを示します。

- 「イベント・タイプ」セクションでは、各イベント用の主要なメトリック・データとともに、「概要」タブに表示されるすべてのイベントがリストされます。

図3-2 JRockit Mission Control内のJRockitフライト・レコーダ・ファイルの概要ページの例

「図3-2 JRockit Mission Control内のJRockitフライト・レコーダ・ファイルの概要ページの例」の説明

実行フローの分析 - サンプル・ウォークスルー

この項では、WebLogic ServerでホストされるWebアプリケーション内の特定のリクエストに関連付けられたイベント・アクティビティを識別するために開発者およびサポート・エンジニアが使用する手順の例を示します。この例は、パフォーマンスの問題を診断する特定の方法をお薦めするものではありませんが、パフォーマンスの問題を検索して分析するプロセスを簡単にすることのできるJFRグラフィカル・ユーザー・インタフェースの使用方法を簡単に示します。

この項では、次の例を説明します。

- 製品サブコンポーネントのイベント・データの表示

- 詳細を示すためのイベント・ログの表示

- 操作セットの分析による実行フローのトラキング

- 操作セットの展開および相関診断データの表示

製品サブコンポーネントのイベント・データの表示

JRockit Mission Controlを起動してJFRファイルを開く場合、分析する特定のイベントを迅速に選択するよう「イベント・タイプ」ビューを使用できます。「イベント・タイプ」ブラウザ(イベント・タイプ・ビューで使用可能)のアイテムを選択および選択解除することで、選択したイベント・タイプのみの情報を表示するようにJFRグラフィカル・ユーザー・インタフェースで表示される情報が迅速に変更されます。

図3-3は、サーブレット・イベント・タイプのみを選択している状態でのイベント・タイプ・ブラウザを示します。

図3-3 イベント・タイプ・ブラウザ

「図3-3 イベント・タイプ・ブラウザ」の説明

詳細を示すためのイベント・ログの表示

1つ以上のイベント・タイプによって記録されるイベントの詳細を表示するには、JFRグラフィカル・ユーザー・インタフェースの下部にある「ログ」タブを選択します。サーブレット・イベント・タイプの「ログ」タブの例を、図3-4に示しています。

図3-4 サーブレット・イベント・ログ

「図3-4 サーブレット・イベント・ログ」の説明

「ログ」タブを使用する場合は、次のようにイベントの詳細を表示できます。

- 「イベント・ログ」表の個々の列の先頭をクリックして、イベントのソート順を変更できます。たとえば、「期間」列をクリックすると、実行に最長時間がかかったイベントを迅速に識別できます。

- 「イベント・ログ」表でイベントを選択すると、「イベント属性」表ではそのイベントの詳細が表示されます。たとえば、図3-4では、次の属性を示します。

- イベントの開始時間、終了時間および継続時間

- サブーレットでリクエストを発行したユーザーのID

- 呼び出されたサーブレットのメソッド、クラス名およびURI

- 実行コンテキストのID (ECID)

異なるイベント・タイプには異なる属性があります。たとえば、JDBCイベントの場合、SQL文、使用したJDBC接続およびこれを呼び出したスタックを表示する属性をスクロールできます。インタフェースによって、詳細に分析できる予期しない動作を簡単にスキャンできます。

注意:
ECIDの値は一意の識別子で、各イベントを同一のリクエスト実行フローの一部として相関させるために使用できます。たとえば、操作セットの分析による実行フローのトラッキングに関する項で示されるように、特定のリクエストに関連すると識別されるイベントは、通常、同一のECID値を持ちます。ただし、ECID文字列自体の形式は、変更しやすい内部メカニズムによって決定されるため、その形式に依存関係を持ったり配置してはなりません。

操作セットの分析による実行フローのトラキング

JRockit Mission Control内のJFRグラフィカル・ユーザー・インタフェースでは、特定のイベントの結果として発生したシステム・アクティビティのランタイム・トレイルを分析できます。この例では、まず操作セットが定義され、ランタイム・トレイルが分析されます。操作セットは、JRockit Mission Controlで動作するために選択するイベントのいずれかのセットです。

この項に示された例では、操作セットが、図3-4で示した「イベント・ログ」表で選択したサーブレット呼出しイベントとして、同じ実行コンテキストID (ECID)属性を持つイベントのために作成されます。操作セットは、そのサーブレット呼出しの結果とした実行フローを参照するために分析されます。(異なる属性にも一致するイベントを含めるようにこの操作セットを拡張できます。たとえば、特定のSQL文を含みますが、必ずしも同じECIDではないイベント)。

図3-5 Execution Context ID (ECID)で定義した操作セット

「図3-5 Execution Context ID (ECID)で定義した操作セット」の説明

この操作セットは、「イベント・ログ」内の任意のイベントを右クリックし、「操作セット」>一致するECIDの追加>「ecid」の順に選択して定義します。図3-6を参照してください。.

図3-6 一致するECIDによる操作セットの定義

「図3-6 一致するECIDによる操作セットの定義」の説明

操作セットは、さらに、図3-7に示すイベント・ログ表上の「操作セットのみを表示」を選択して表示されます。操作セットが、範囲ナビゲータでどのように示されているかに注意してください。

図3-7 操作セットの表示

「図3-7 操作セットの表示」の説明

サーブレットの呼び出しイベントを生成したリクエストの結果表示された実行フローの実行時トレイルは、追加イベント・タイプを含めて表示できます。たとえば、図3-8では、「イベント・タイプ」ブラウザを使用してすべてのWebLogic Serverイベント・タイプが追加され、イベントが発生順にリストされているときの操作セットを示します。(「開始時間」列の先頭を選択してイベントを発生順にソートできます。)

図3-8 操作セットへのすべてのWebLogic Serverイベントの追加

「図3-8 操作セットへのすべてのWebLogic Serverイベントの追加」の説明

この例では、イベント・ログに表示される実行フローの一部が示されています。

1. サーブレットのURIが呼び出されます。

2. サーブレットはEJBを使用するため、データベースへのアクセスが必要となります。

3. JDBC接続を取得し、トランザクションが開始されます。

操作セットの展開および相関診断データの表示

操作セットは、実行フローの時間間隔を制約し、追加プロデューサからの相関イベントを追加して、さらに分析できます。表示されたイベントために時間間隔を制約することにより、操作セットと同時に発生したイベント・ログにイベントを追加できます。これよって、パフォーマンスの問題を診断するために役に立つ実行コンテキストの詳細を追加できます。

範囲ナビゲータで範囲選択バーを選択して時間間隔を制約することができます。このバーをポインタでグラブし、内側または外側にドラッグして、イベント・ログに表示されるイベントの範囲を変更することができます。図3-9で示すように、ナビゲータのいずれかの先端上マウスポインタを乗せると、範囲選択バーがアクティブ化されます。

図3-9 範囲ナビゲータの選択バー

「図3-9 範囲ナビゲータの選択バー」の説明

JRockit JVM,などの追加プロデューサからのイベントは「イベント・タイプ」ブラウザから選択できます。JVMイベントにはECID属性がないため、そのイベントを操作セットのWLDFイベントに含めることはできません。したがって、JVMイベントを表示するには、「操作セットのみを表示」の選択を解除する必要があります。

この時点でイベント・ログに表示されるイベントは、選択した時間間隔で発生されたイベントであり、他との関連はありません。図3-10では、JDBCイベントおよびJVMソケット・イベントのみの選択によるJDBCアクティビティのドリルダウンを示します。選択した時間間隔でJDBCイベントのフローと同時に発生するソケット・アクティビティを表示するために、イベント・ログが更新され、時系列順に表示されます。

図3-10 JDBCイベント・ログへのJVMイベントの追加

「図3-10 JDBCイベント・ログへのJVMイベントの追加」の説明

一時JFRファイルの場所の変更

オペレーティング・システムのtempディレクトリに作成される一時JFRファイルは、JRockitによって直接管理されます。WLDFはこれらのファイルを制御しません。(デフォルトでは、JFRレコーディングに関連するWLDFの一時ファイルはDOMAIN_NAME\servers\SERVER_NAME/server/logs/diagnostic_imagesディレクトリに格納されます。)

ただし、JRockitがその一時ファイルを格納する場所は、JFR起動時に次のコマンドライン・オプションを使用して変更できます。ここで、パスは優先場所を示します。

-XX:FlightRecorderOptions=repository=path

JFR構成設定の詳細は、『Oracle JRockitフライト・レコーダ・ランタイム・ガイド』のフライト・レコーダの起動に関する項を参照してください。

4 WLDF構成について

WebLogic診断フレームワーク(WLDF)では、WebLogic Serverインスタンスおよびサーバー・インスタンスにデプロイされたアプリケーションから診断データを生成、収集、解析、永続化できます。サーバー・スコープの診断では、一部のWLDF機能は、ドメイン内のサーバーの構成の一部として構成されます。その他の機能は、サーバー(またはクラスタ)をターゲットとするシステム・リソース記述子として構成されます。アプリケーション・スコープの診断では、診断機能は、アプリケーションのリソース記述子として構成されます。

次の項では、WLDF構成の概要について説明します。

- 構成MBeanとXML

- WLDFの構成用ツール

- WLDF構成の区分

- 診断イメージ・キャプチャと診断アーカイブの構成

- JRockitフライト・レコーダ用の診断イメージ・キャプチャの構成

- 診断システム・モジュールの構成

- アプリケーション用の診断モジュールの構成

- WLDF構成MBeanとXML要素へのマッピング

WebLogic Serverドメイン構成の一般情報は、『Oracle WebLogic Serverドメイン構成の理解』を参照してください。

構成MBeanとXML

他のWebLogic Serverサブシステムと同様に、WLDFは構成MBean(マネージドBean)を使用して構成され、構成はXML構成ファイルに永続化されます。構成MBeanは、XMLファイルの構成設定に基づいて、起動時にインスタンス化されます。MBean属性の値を変更して構成を変更すると、それらの変更内容はXMLファイルに保存(永続化)されます。

構成MBeanの属性は構成XML要素に直接マップされます。たとえば、WLDFInstrumentationBeanのEnable属性は診断モジュールのための資源記述子ファイル(構成ファイル)で直接<instrumentation>要素の<enabled>下位要素にマップします。MBean属性の値を変更した場合、構成を保存するときにXML要素の内容も変更されます。反対に、構成ファイルのXML要素を直接編集した場合(推奨されません)、MBean値の変更は次のセッションが開始するときに有効になります。

WLDF構成MBeansの詳細は、「WLDF構成MBeanとXML要素へのマッピング」を参照してください。WebLogic ServerでどのようにMBeanが実装され、使用されるかの一般情報は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeansについてに関する項を参照してください。

WLDFの構成用ツール

他のWebLogic Serverサブシステムと同様に、WLDFの構成には、以下のような複数の方法があります。

- 管理コンソールを使用して、サーバー・インスタンスおよびクラスタ用にWLDFを構成します。管理コンソール・オンライン・ヘルプのWebLogic診断フレームワークの構成に関する項を参照してください。

- WebLogic Scripting Tool (WLST)で実行するスクリプトを書き込みます。WLDFでWLSTを使用する際の詳細は、付録D「WebLogic Scripting Toolのサンプル」を参照してください。WLSTの一般情報は、『Oracle WebLogic Scripting Tool』を参照してください。

- JMXおよびWLDF構成MBeanを使用してWLDFのプログラムを構成します。WLDFのプログラミングの詳細は、第16章「WLDFのプログラムの構成と使用」を参照してください。プログラミング時のリファレンスとしてOracle WebLogic Server MBeanリファレンスを参照して、特定のMBeanを参照または検索します。

- XML構成ファイルを直接編集します。このドキュメントでは、構成ファイルのXML要素を例示および説明することで、さまざまな構成タスクについて説明します。XMLはわかりやすく、構成ファイルを直接編集できますが、そうすることはお薦めしません。(ファイルを直接編集する適切な理由がある場合は、まず、管理コンソールでWLDFを構成してXMLファイルを生成してください。そうすることで、有効なXMLの青写真が得られます。)

注意:
構成ファイルを編集して構成を変更した場合、その変更を有効にするにはサーバーを再起動する必要があります。

WLDF構成の区分

WLDFを使用すると、サーバー・インスタンス(とクラスタ)およびアプリケーションに対して診断タスクを実行できます。

サーバー・レベルの構成

以下のコンポーネントは、ドメインのサーバー・インスタンスの一部として構成します。構成設定はMBeanを使用して制御され、ドメインのconfig.xmlファイルに永続化されます。

- 診断イメージ・キャプチャ

- 診断アーカイブ

「診断イメージ・キャプチャと診断アーカイブの構成」を参照してください。

以下のWLDFコンポーネントは、1つまたは複数のサーバー・インスタンス(またはクラスタ)にデプロイできる、1つまたは複数の診断システム・モジュールまたはリソースの一部として構成します。これらの構成設定はBeanを使用して構成され、1つまたは複数のサーバー・インスタンス(またはクラスタ)に対してターゲット指定できる、1つまたは複数の診断リソース記述子ファイル(構成ファイル)に永続化されます。

- ハーベスタ(メトリック収集用)

- 監視および通知

- インストゥルメンテーション

「診断システム・モジュールの構成」を参照してください。

アプリケーション・レベルの構成

WLDFインストゥルメンテーション・コンポーネントは、サーバー・レベルだけでなくアプリケーション・レベルでも使用できます。インストゥルメンテーション・コンポーネントは、アプリケーション・アーカイブ・ファイルのアプリケーションでデプロイされたリソース記述子ファイルで構成されます。「アプリケーション用の診断モジュールの構成」を参照してください。

診断イメージ・キャプチャと診断アーカイブの構成

ドメインのconfig.xmlファイルでは、<server-diagnostic-config>要素の診断イメージ・キャプチャ・コンポーネントおよび診断アーカイブ・コンポーネントを構成します。<server-diagnostic-config>要素はドメインの子要素です。例を例4-1に示します。

例4-1 ドメインのconfig.xmlファイルにあるWLDF構成情報のサンプル

<domain>
<server>
<name>myserver</name>
<server-diagnostic-config>
<image-dir>logs/diagnostic_images</image-dir>
<image-timeout>3</image-timeout>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-data-archive-type>FileStoreArchive
</diagnostic-data-archive-type>
</server-diagnostic-config>
</server>
<!-- Other server elements to configure other servers in this domain -->
<!-- Other domain-based configuration elements, including references to
WLDF system resources, or diagnostic system modules.
See Example 4-2. -->
</domain>

注意:
WebLogic ServerがOracle JRockitと構成されているとき、JRockitフライト・レコーダが有効である場合、診断イメージ・キャプチャには、WebLogic Serverイベントを含むJRockitフライト・レコーダ(JFR)ファイルを含められます。JFRファイルは「JRockit Mission Control」で表示できます。

詳細については、次を参照してください。

- 第5章「診断イメージの構成とキャプチャ」

- 第6章「診断アーカイブの構成」

JRockitフライト・レコーダ用の診断イメージ・キャプチャの構成

WebLogic ServerがOracle JRockit R28以降で構成されていて、JRockitフライト・レコーダが明示的に無効にされていない場合、JFRファイルが診断イメージ・キャプチャに自動で含まれます。JFRファイルは、有効な状態にあるすべてのイベント・プロデューサからのデータを含みます。ただし、JFRに含まれるWebLogic Serverイベント・データ量はWLDF診断ボリュームの構成により決定されます。

注意:
デフォルトでは、WLDF診断ボリュームは低に設定されています。

WebLogic Serverのイベント・データをJFRファイルに含めるには:

1. WebLogic ServerがWebLogic Serverのインストール・プログラムから使用可能であるOracle JRockit R28で構成されていることを確認してください。
詳細は、『Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

2. JRockitでJFRフライト記録が無効になっていないことを確認します。
Oracle JRockitのデフォルト・インストールでは、フライト・レコーダはデフォルトのデータ収集モードで動作します。JVMイベントをJFRファイルに含めるのにJRockitの設定は必要ありません。

詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』を参照してください。

3. WLDF診断ボリュームを適切に設定します。一般的な使用には、低いのデフォルト設定をお薦めします。ただし、ボリュームを中または高いに設定することにより、生成されるWebLogic Serverイベント・データのボリュームを適切に増加できます。
WLDF診断ボリュームの設定は、JVMなどの他のイベント・プロデューサに記録したデータには影響しません。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプのWLDF診断ボリュームの構成に関する項を参照してください。

注意:
WLDF診断ボリュームがOffに設定し、フライト・レコーダが明示的に無効にされていない場合、JFRファイルは引き続きJVMイベント・データを含み、常に診断イメージ・キャプチャに含まれます。

診断システム・モジュールの構成

インストゥルメンテーション、ハーベスタ、監視と通知の各コンポーネントをサーバー・レベルで構成して使用するには、「診断システム・モジュール」というシステム・リソースをあらかじめ作成する必要があります。診断システム・モジュールには、これらのすべてのコンポーネントの構成が含まれます。以下の点に注意してください。次の点に留意してください:

- システム・モジュールは、ドメインで構成されているサーバーおよびクラスタにグローバルにターゲット指定できます。

- 特定のドメインでは、個別の構成を持つ複数の診断システム・モジュールを作成できます。

- 特定のサーバーまたはクラスタに対してターゲット指定できる診断システム・モジュールは1つのみです。

診断システム・モジュールとそのリソース記述子

診断システム・モジュールは管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して作成します。診断システム・モジュールはWLDFResourceBeanとして作成され、構成はDIAG_MODULE.xmlというリソース記述子ファイル(構成ファイル)に永続化されます。DIAG_MODULEは診断モジュールの名前です。記述子ファイル名は指定できますが、必須ではありません。ファイル名を付けなかった場合、記述子ファイルの<name>要素の値を基に名前が付けられます。デフォルトでは、ファイルはDOMAIN_NAME \config\diagnostics directoryディレクトリに作成されます。DOMAIN_NAMEは、ドメインのホーム・ディレクトリ名です。ファイルには、.xml拡張子があります。

注意:
診断モジュールはdiagnostics.xsdスキーマに準拠しています。このスキーマは、http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsdで参照できます。

診断システム・モジュールの作成手順は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュールの作成に関する項を参照してください。

config.xmlからの診断システム・モジュールの参照

管理コンソールまたはWebLogic Scripting Tool (WLST)を使って診断システム・モジュールを作成すると、WebLogic Serverは、DOMAIN_NAME/config/diagnosticsディレクトリに診断システム・モジュールを作成します。また、ドメインのconfig.xmlファイルに、モジュールへの参照が追加されます。

注意:
XML構成ファイルを直接記述しないことをお薦めします。直接記述する必要がある場合は、まず、コンソールから診断モジュールを作成してください。それにより、コンソールが作成する有効なXMLを利用できます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュールの作成に関する項を参照してください。

config.xmlファイルでは、1つまたは複数の<wldf-system-resource>要素を使って診断モジュールへの参照を複数指定できます。<wldf-system-resource>要素には、診断モジュール・ファイル名、およびその診断モジュールのターゲットとなるサーバーとクラスタのリストが含まれます。

例4-2では、myserverサーバーをターゲットにしたmyDiagnosticModuleというモジュールに加え、ManagedServer1およびManagedServer2のサーバーをターゲットとするたnewDiagnosticModというモジュールの例を示します。

例4-2 ドメインのconfig.xmlファイルにあるWLDF構成情報のサンプル

<domain>
<!-- Other domain-level configuration elements -->
<wldf-system-resource
xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics">
<name>myDiagnosticModule</name>
<target>myserver</target>
<descriptor-file-name>diagnostics/MyDiagnosticModule.xml
</descriptor-file-name>
<description>My diagnostic module</description>
</wldf-system-resource>
<wldf-system-resource>
<name>newDiagnosticMod</name>
<target>ManagedServer1,ManagedServer2</target>
<descriptor-file-name>diagnostics/newDiagnosticMod.xml
</descriptor-file-name>
<description>A diagnostic module for my managed servers</description>
</wldf-system-resource>
<!-- Other WLDF system resource configurations -->
</domain>

config.xmlファイルとMyDiagnosticModule.xmlファイルの関係を図4-1に示します。

図4-1 config.xmlとシステム記述子ファイルとの関係

「図4-1 システム記述子ファイルへのconfig.xmlの関係」の説明

DIAG_MODULE.xmlリソース記述子の構成

診断システム・モジュールの名前とターゲットのリストは、前述のようにconfig.xmlファイルに記述されますが、それ以外の診断システム・モジュールに関する構成は、すべてリソース記述子ファイルに保存されます。例4-3 はmyDiagnosticModuleという診断システム・モジュールのための記述子ファイルの一部を示します。

例4-3 診断システム・モジュール記述子ファイルMyDiagnosticModule.xmlのサンプル構造

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>MyDiagnosticModule</name>
<instrumentation>
<!-- Configuration elements for zero or more diagnostic monitors -->
</instrumentation>
<harvester>
<!-- Configuration elements for harvesting metrics from zero or more
MBean types, instances, and attributes -->
</harvester>
<watch-notification>
<!-- Configuration elements for one or more watches and one or more
notifications-->
</watch-notification>
</wldf-resource>

診断システム・モジュールの管理

1つのサーバーをターゲットにできるモジュールは一度に1つだけですが、診断システム・モジュールは、0個、1つ、または複数のサーバーまたはクラスタをターゲットにできます。システムの様々な側面をモニターするために、複数のモジュールを作成できます。複数のモジュールを作成した場合、その時にモニターする内容を基に、サーバーまたはクラスタをターゲットにするモジュールを選択できます。

同じモジュールで複数のサーバーまたはクラスタをターゲットにできるので、ドメイン内全体で使用する汎用モジュールを作成できます。

診断モジュールのターゲットを変更した場合でも、ターゲット指定したサーバーまたはターゲット指定を解除したサーバーを再起動する必要はありません。これにより、特定の診断目的に対応する診断モニターを柔軟に作成および使用できます。また、その際、サーバー・インスタンス自体の操作が妨げられることはありません。

診断システム・リソースの構成の詳細

WLDFシステム・リソースの詳細な構成手順については、以下の章を参照してください。

- 第7章「メトリック収集用のハーベスタの構成」

- 第8章「監視および通知の構成」

- 第11章「インストゥルメンテーションの構成」

- 第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」

アプリケーション用の診断モジュールの構成

アプリケーションの診断記述子では、インストゥルメンテーション・コンポーネントのみを構成できます。

アプリケーション・スコープのインストゥルメンテーションを、診断システム・モジュールに類似した診断モジュールとして、構成およびデプロイします。ただし、アプリケーション・モジュールはweblogic-diagnostics.xmlというXML記述子(構成)ファイルで構成されます。このファイルは、デプロイされるアプリケーションのARCHIVE_PATH/META-INFディレクトリ内で、アプリケーション・アーカイブと一緒にパッケージ化されます。たとえば、D:\bea\wlserver_10.3\samples\server\medrec\dist\standalone\exploded\medrec\META-INF\weblogic-diagnostics.xml

注意:
(システム内を通過するリクエストを追跡する方法として)診断コンテキストを構成する際に使用されるDyeInjectionモニターは、サーバー・レベルでのみ構成できます。ただし、診断コンテキストが作成されると、受信したリクエストにアタッチされた診断コンテキストは、リクエストと一緒にアプリケーション内を通過します。診断コンテキストの情報は、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

アプリケーションの診断モジュールの構成とデプロイの詳細については、次を参照してください。

- アプリケーション・スコープのインストゥルメンテーションの構成

- 第14章「WLDFアプリケーション・モジュールのデプロイ」

WLDF構成MBeanとXML要素へのマッピング

図4-2はWebLogic ServerドメインのWLDFオブジェクトのためにWLDF構成MBeansと診断システム・モジュールBeanの階層構造を示します。

図4-2 WLDF構成Beanツリー

「図4-2 WLDF構成Beanツリー」の説明

以下のWLDF MBeanは、サーバー・レベルでWLDFを構成します。また、ドメインのconfig.xml構成ファイルのXML要素にマッピングされます。

- WLDFServerDiagnosticMBeanは、サーバーのデータ・アーカイブ・コンポーネントと診断イメージ・コンポーネントの構成設定を制御します。診断モジュールの診断コンテキストをグローバルに有効化または無効化するかどうかを制御します(診断コンテキストは、リクエストを一意に識別し、システム内を通過する際にリクエストを追跡する手段です。第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。)
このMBeanは、サーバーのドメインのconfig.xmlファイルで、<server>要素の<server-diagnostic-config>子要素で表されます。

- WLDFSystemResourceMBeanには、DOMAIN_NAME/config/diagnosticsディレクトリにある診断モジュールの記述子ファイルの名前、およびそのモジュールがデプロイされるターゲット・サーバー(複数可)の名前が含まれます。
このMBeanは、ドメインのconfig.xmlファイルの<wldf-system-resource>要素で表されます。

注意:
ドメイン内に複数の診断システム・モジュールを作成できます。モジュールの構成は、ドメインのconfig/diagnosticsディレクトリの複数の記述子ファイルに保存されます。したがって、ドメインのconfig.xmlファイルには、それらのモジュールを表す複数の<wldf-system-resource>要素を指定できます。ただし、サーバーに対してターゲット指定できる診断システム・モジュールは一度に1つのみです。同じサーバーをアクティブなターゲットにしている2つのファイルがconfig/diagnosticsディレクトリに存在することはできません。

- WLDFResourceBeanには、診断システム・モジュールの構成設定が収められています。このBeanは、ドメインのconfig/diagnosticsディレクトリにあるDIAG_MODULE.xml診断記述子ファイルの<wldf-resource>要素で表されます。(図4-1および例4-3を参照してください。)WLDFResourceBeanには、次のコンポーネントの構成設定が収められています。

- ハーベスタ: WLDFHarvesterBeanは、DIAG_MODULE.xmlファイルの<harvester>要素で表されます。

- インストゥルメンテーション: WLDFInstrumentationBeanは、DIAG_MODULE.xmlファイルの<instrumentation>要素で表されます。

- 監視および通知: WLDFWatchNotificationBeanは、DIAG_MODULE.xmlファイルの<watch-notification>要素で表されます。

WLDFResourceBeanがWLDFSystemResourceMBeanからリンクされている場合、そのWLDFコンポーネントの設定はターゲット指定されたサーバーに適用されます。アプリケーション・アーカイブの一部としてデプロイされているweblogic-diagnostics.xml記述子ファイルにWLDFResourceBeanが含まれている場合、構成可能なのはインストゥルメンテーション・コンポーネントのみであり、設定はそのアプリケーションにのみ適用されます。後者の場合、WLDFResourceMBeanはWLDFSystemResourceMBeanの子ではありません。

5 診断イメージの構成とキャプチャ

WebLogic診断フレームワーク(WLDF)の診断イメージ・キャプチャ・コンポーネントを使用すると、キャプチャ時のサーバー内部の実行時状態について診断スナップショット(またはダンプ)を作成できます。この情報は、サーバー障害の原因の分析に役立ちます。

WebLogic ServerがOracle JRockitで構成され、JRockitフライト・レコーダが有効になっている場合、診断イメージのキャプチャには、JRockit Mission Controlで表示できるWebLogic Server診断データが存在します。

次の項では、診断イメージ・キャプチャ・コンポーネントについて説明します。

- イメージ・キャプチャの開始方法

- 診断イメージ・キャプチャの構成

- サーバーの構成における診断イメージ・キャプチャの永続化

- キャプチャされたイメージ・ファイルの内容

イメージ・キャプチャの開始方法

診断イメージ・キャプチャは、以下のいずれかによって開始されます。

- 構成された監視通知。第10章「通知の構成」を参照してください。

- 管理コンソールでユーザーが開始したリクエスト(および、サードパーティの診断ツールから開始されたリクエスト)。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断イメージの構成とキャプチャに関する項を参照してください。

- JMXによるAPIの直接呼出し。例5-1を参照してください。

- WLSTコマンド

診断イメージ・キャプチャの構成

診断イメージ・キャプチャは、主に障害発生後の解析ツールとして利用するものなので、どのような情報をキャプチャするかについては限られた権限しか与えられていません。診断イメージ・キャプチャで指定可能な構成オプションは次のとおりです。

- イメージの宛先

- デフォルトの宛先とは別の宛先(指定したキャプチャの場合)

- サーバーの障害発生から回復までにイメージがキャプチャされる頻度を設定するロックアウト(タイムアウト)期間

- フライト・レコーダ・ファイルでキャプチャされるWebLogic Serverイベント情報のボリュームを決定するWLDF診断ボリューム。

他のWLDFコンポーネントと同様に、診断イメージ・キャプチャは、管理コンソール(Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断イメージの構成とキャプチャを参照してください)やWebLogic Scripting Tool (WLST)を使用して、またはプログラムで構成できます。

注意:
多くの場合、サーバー障害の発生時に診断イメージ・キャプチャを生成するのが有効です。そのためには、サーバーの状態がFAILEDに変更されたときにtrueに評価されるように監視ルールを設定し、監視にイメージ通知を関連付けます。
監視ルールは以下のとおりです。

(${[weblogic.management.runtime.ServerRuntimeMBean]//State} = 'FAILED')

詳細は、「ハーベスタ監視の構成」および「イメージ通知の構成」を参照してください。また、『Oracle WebLogic Server管理コンソール・ヘルプ』の監視および通知の構成に関する項も参照してください。

WLDF診断ボリュームの構成

WebLogic ServeがOracle JRockitで構成され、JRockitフライト・レコーダを有効にしている場合、JRockitフライト・レコーダ・データも診断イメージのキャプチャで自動的にキャプチャされます。このデータは、診断イメージのキャプチャから抽出され、JRockit Mission Controlで表示できます。JRockitフライト・レコーダを有効にしていない場合、またはWebLogic Serverを別のJVMで構成した場合、フライト・レコーダ・データが診断イメージのキャプチャで抽出されません。

キャプチャしたフライト・レコーダ・データのボリュームはWebLogic Server管理コンソールから構成することができます。これによって、次の設定が指定できます。

- Off -フライト・レコーダ診断イメージでデータがキャプチャされません。

- Low - (デフォルト)「緊急」、「アラート」または「クリティカル」レベルのメッセージが記録された場合、基本情報をキャプチャします。

注意:
WLDF診断ボリュームのデフォルト設定はLowです。

- Medium - 「エラー」レベル以上のメッセージが記録された場合、追加情報をキャプチャします。

- High - 「エラー」レベル以上のメッセージが記録された場合、詳細情報をキャプチャします。

キャプチャしたデータのボリュームを設定する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWLDF診断ボリュームの構成に関する項を参照してください。

イメージ・キャプチャ生成用のWLSTコマンド

例5-1では、イメージ・キャプチャを生成するためのWLSTコマンドの例を示します。

例5-1 診断イメージを生成するためのWLSTコマンドのサンプル

url='t3://localhost:7001'
username='system'
password='gumby1234'
server='myserver'
timeout=120
connect(username, password, url)
serverRuntime()
cd('WLDFRuntime/WLDFRuntime/WLDFImageRuntime/Image')
argTypes = jarray.array(['java.lang.Integer'],java.lang.String)
argValues = jarray.array([timeout],java.lang.Object)
invoke('captureImage', argValues, argTypes)

サーバーの構成における診断イメージ・キャプチャの永続化

診断イメージ・キャプチャの構成はドメインのconfig.xmlファイルで永続化されます(サーバーの<server>要素の<server-diagnostic-config>要素内)。例5-2を参照してください。

例5-2 診断イメージ・キャプチャの構成のサンプル

<domain>
<!-- Other domain configuration elements -->
<server>
<name>myserver</name>
<server-diagnostic-config>
<image-dir>logs\diagnostic_images</image-dir>
<image-timeout>2</image-timeout>
</server-diagnostic-config>
<!-- Other configuration details for this server -->
</server>
<!-- Other server configurations in this domain-->
</domain>

注意:
Oracleは、直接config.xmlファイルを編集しないことをお薦めします。

キャプチャされたイメージ・ファイルの内容

診断イメージ・キャプチャでは、以下のようなサーバーの状態の最も一般的な情報がキャプチャされます。

- 構成

- ログ・キャッシュの状態

- Java仮想マシン(JVM)

- ワーク・マネージャの状態

- JNDIの状態

- 最近収集されたデータ

診断イメージ・キャプチャ・コンポーネントは、様々なサーバー・サブシステムによって生成されたイメージをキャプチャおよび結合して、単一のZIPファイルにします。サーバー状態の最も一般的な情報をキャプチャするだけでなく、このコンポーネントは、たとえばJMS、JDBC、EJB、およびJNDIサブシステムによって生成されたイメージなど、すべてのサーバー・サブシステムからイメージをキャプチャします。

WebLogic ServerがOracle JRockitで構成され、JRockitフライト・レコーダを有効にすると、診断イメージのキャプチャには、JRockit Mission Controlで表示されるJRockitフライト・レコーダのイメージFlightRecording.jfrが含まれます。JRockit Flight Recorderイメージには、Flight Recorderからの使用可能なすべてのデータが含まれていて、診断ボリュームの設定によっては、WLDFで作成されたデータのボリュームが含まれます。JRockit Flight Recorderを有効にすると、データは常にOracle JRockitによって提供されます。オプションで、WebLogic Serverから提供されるデータが含まれます。Oracle Dynamic Monitoring System (DMS)などのOracleの追加コンポーネントからのデータをFlight Recorderイメージに含めることもできます。

注意:

1. 診断イメージは、重大な障害を診断するためにサーバー・レベルの状態ダンプとして利用できる、サイズの大きなアーティファクトです。診断イメージは、構造化されたフォーマットで重要なデータを大量にキャプチャできるので、サポート部門のスタッフによる問題の解析に役立てることができます。

2. DMSなどのWebLogic Server環境の非WebLogicイベント・プロデューサがデータを記録するようにJRockitフライト・レコーダを構成した場合、WLDF診断ボリュームの設定がOffの場合でも、WLDF診断イメージ・キャプチャには記録したデータを含むフライト・レコーダ・イメージ・ファイルが含まれます。

診断イメージ・キャプチャ・ファイルに含まれるデータ

各イメージは、サーバー全体で1つのファイルとしてキャプチャされます。デフォルトの場所はSERVER\logs\diagnostic_images。各イメージ・インスタンスには、次のように一意の名前が付けられます。

diagnostic_image_DOMAIN_SERVER_YYYY_MM_DD_HH_MM_SS.zip

ファイルには、少なくとも以下の情報が収められています。

- 診断イメージの作成日および作成時間

- キャプチャリクエストのソース

- 診断イメージに含まれる各イメージ・ソースの名前と処理にかかった時間

- JVMおよびOS情報(取得可能な場合)

- コマンド・ライン引数(使用可能な場合)

- WLSのバージョン(パッチおよびビルド番号情報を含む)

「JRockitフライト・レコーダ用の診断イメージ・キャプチャの構成」での説明のように、WLDFがOracle JRockitで構成されている場合、イメージには、JRockitフライト・レコーダ(JFR)ファイル、FlightRecording.jfrも含まれます。診断イメージ・キャプチャのダウンロード用のWLSTオンライン・コマンドでの説明のように、JFRファイルを抽出し、JRockit Mission Controlで表示できます。詳細は、『Oracle JRockitフライト・レコーダ・ラン・タイム・ガイド』を参照してください。

図5-1はイメージ・ファイルの内容を示します。このZIPファイル内のほとんどのファイルは、テキスト・エディタで開いて内容を確認できます。

図5-1 イメージ・ファイル

「図5-1 イメージ・ファイル」の説明

診断イメージ・キャプチャのダウンロード用のWLSTオンライン・コマンド

WLSTオンラインでは、WLSTが接続されているサーバーから診断イメージのキャプチャをダウンロードするための次のコマンドが提供されます。

- getAvailableCapturedImages - サーバーで構成した診断イメージの宛先ディレクトリで作成された診断イメージのリストを戻します。

- saveDiagnosticImageCaptureFile - 指定した診断イメージのキャプチャ・ファイルをダウンロードします。

- saveDiagnosticImageCaptureEntryFile - 診断イメージのキャプチャ内の特定のエントリをダウンロードします。JRockit Mission Controlに表示する診断データを取得するときにこのコマンドが特に役立ちます。

これらのコマンドと使用方法の例の詳細は、「WebLogic Scripting Toolのコマンド・リファレンス」を参照してください。診断イメージのリストを戻し、その中のJFRファイルを取得するWLSTスクリプトの例は、付録D「WebLogic Scripting Toolの例」を参照してください。

6 診断アーカイブの構成

WebLogic診断フレームワーク(WLDF)のアーカイブ・コンポーネントは、サーバー・インスタンスおよびそのサーバー・インスタンスで実行されているアプリケーションからWLDFによって収集されたすべてのデータ・イベント、ログ・レコード、およびメトリックをキャプチャし、永続化します。オンライン・モードで(つまり実行中のサーバーで)アーカイブされた診断データにアクセスできます。また、オフライン・モードでも、WebLogic Scripting Tool (WLST)を使用して、アーカイブされたデータにアクセスできます。

次の項で説明するように、ファイル・ストアまたはJava Database Connectivity (JDBC)データ・ソースに診断データをアーカイブするようにWLDFを構成できます。

- アーカイブの構成

- ファイル・ベースのストアの構成

- JDBCベースのストアの構成

また、次の項で説明するように、古いデータをアーカイブから削除する時期や条件を指定することもできます。

- アーカイブのデータの廃棄

アーカイブの構成

診断アーカイブをサーバーごとに構成します。構成はドメインのconfig.xmlファイルで永続化されます(サーバーの<server-diagnostic-config>要素内)。ファイルベースのストアの構成の例を例6-1、JDBCベースのストアの例を例6-3に示します。

注意:
診断データがアーカイブに書き込まれている際にシステム・クロックをリセットすると、予期しない結果が生じることがあります。詳細は、「システム・クロックのリセットによるデータのアーカイブおよび取得への影響」を参照してください。

ファイル・ベースのストアの構成

ファイル・ベースのストアの場合、WLDFではアーカイブされた情報を格納するためのファイルが作成されます。WLDFのファイル・ベースのアーカイブで指定可能な構成オプションは、このテキスト・ファイルを作成および保持するディレクトリのみです。デフォルトのディレクトリはDOMAIN_NAME/servers/SERVER_NAME/data/store/diagnosticsです。DOMAIN_NAMEはドメインのホーム・ディレクトリ、SERVER_NAMEはサーバー・インスタンスのホーム・ディレクトリです。

ファイルベースのストアに保存する場合、WLDFはWebLogic Server永続ストアを使用します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。

例6-1に、ファイルベースのストアの構成の例を示します。

例6-1 ファイル・ベースの診断アーカイブの構成のサンプル(config.xml内)

<domain>
<!-- Other domain configuration elements -->
<server>
<name>myserver</name>
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-data-archive-type>FileStoreArchive
</diagnostic-data-archive-type>
</server-diagnostic-config>
</server>
<!-- Other server configurations in this domain -->
</domain>

JDBCベースのストアの構成

JDBCストアを使用するには、データベースに適切な表があり、そのデータベースに接続するようにJDBCが構成されている必要があります。管理コンソールを使用してJDBCを構成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのデータベース接続の構成に関する項を参照してください。JDBCの構成の詳細は、『Oracle WebLogic Server JDBCの構成と管理』を参照してください。

データベースでのWLDF表の作成

WLDFで使用するデータベース表がない場合は、JDBCベースのストアにデータを保存する表を作成する必要があります。2つの表が必要です。

- wls_events表には、WLDFインストゥルメンテーション・イベントから生成されるデータが格納されます。

- wls_hvst表には、WLDFハーベスタ・コンポーネントから生成されるデータが格納されます。

表の作成に使用するSQLのデータ定義言語(Data Definition Language: DDL)は、データベースでサポートされているSQLの種類によって、データベースごとに異なる可能性があります。例6-2では、Apache DerbyデータベースにWLDF表を作成する場合に使用可能なDDLを示します。

例6-2 Apache DerbyにWLDF表を作成するためのDDL

-- WLDF Instrumentation and Harvester archive DDLs using Derby

AUTOCOMMIT OFF;

-- DDL for creating wls_events table for instrumentation events

DROP TABLE wls_events;

CREATE TABLE wls_events (
RECORDID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1),
TIMESTAMP BIGINT default NULL,
CONTEXTID varchar(128) default NULL,
TXID varchar(32) default NULL,
USERID varchar(32) default NULL,
TYPE varchar(64) default NULL,
DOMAIN varchar(64) default NULL,
SERVER varchar(64) default NULL,
SCOPE varchar(64) default NULL,
MODULE varchar(64) default NULL,
MONITOR varchar(64) default NULL,
FILENAME varchar(64) default NULL,
LINENUM INTEGER default NULL,
CLASSNAME varchar(250) default NULL,
METHODNAME varchar(64) default NULL,
METHODDSC varchar(4000) default NULL,
ARGUMENTS clob(100000) default NULL,
RETVAL varchar(4000) default NULL,
PAYLOAD blob(100000),
CTXPAYLOAD VARCHAR(4000),
DYES BIGINT default NULL,
THREADNAME varchar(128) default NULL
);

-- DDL for creating wls_events table for instrumentation events

DROP TABLE wls_hvst;

CREATE TABLE wls_hvst (
RECORDID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1),
TIMESTAMP BIGINT default NULL,
DOMAIN varchar(64) default NULL,
SERVER varchar(64) default NULL,
TYPE varchar(64) default NULL,
NAME varchar(250) default NULL,
ATTRNAME varchar(64) default NULL,
ATTRTYPE INTEGER default NULL,
ATTRVALUE VARCHAR(4000)
);

COMMIT;

実際に使用しているデータベース用にこれらの表を作成する具体的な手順については、データベースのドキュメントを参照するか、データベース管理者に問い合わせてください。

WLDF用のJDBCリソースの構成

データベースに表を作成したら、その表にアクセスするようにJDBCを構成する必要があります(『Oracle WebLogic Server JDBCの構成と管理』を参照してください)。次に、サーバー構成の中で、サーバーのアーカイブに使用するデータ・ストアとしてそのJDBCリソースを指定します。

例6-3に、JDBCベースのストアの構成の例を示します。

例6-3 JDBCベースの診断アーカイブの構成のサンプル(config.xml内)

<domain>
<!-- Other domain configuration elements -->
<server>
<name>myserver</name>
<server-diagnostic-config>
<diagnostic-data-archive-type>JDBCArchive
</diagnostic-data-archive-type>
<diagnostic-jdbc-resource>JDBCResource</diagnostic-jdbc-resource>
<server-diagnostic-config>
</server>
<!-- Other server configurations in this domain -->
</domain>

JDBCリソースを指定していて、その構成が正しくない場合、または、必要な表がデータベースに存在しない場合、WLDFはデフォルトのファイル・ベースの永続ストアを使用します。

アーカイブのデータの廃棄

WLDFにはデータ廃棄機能があります。構成を行うことによって、アーカイブから古い診断データを定期的に削除できます。以下の節で説明するように、サーバー・レベルではサイズに基づいたデータ廃棄を、個々のアーカイブ・レベルでは期間に基づいたデータ廃棄を構成できます。

サーバー・レベルでのデータ廃棄の構成

サーバー・インスタンスに対して、以下のデータ廃棄オプションを設定できます。

- サーバー・インスタンスのデータ・ストアの望ましい最大サイズ(<preferred-store-size-limit>)と、そのサイズを超過しているかどうかを正時にチェックする間隔(<store-size-check-period>)。
ストア・サイズが最大サイズを超過していることが検出されると、適切な数のレコードが古いものから削除され、指定されたしきい値を下回るようにサイズが縮小されます。これを「サイズに基づいたデータ廃棄」と呼びます。

注意:
サイズに基づいたデータ廃棄は、ファイル・ベースのストアに対してのみ使用できます。上記のオプションは、データベース・ベースのストアでは無視されます。

- サーバー・インスタンスでのデータ廃棄の有効化または無効化。
ファイル・ベースの診断ストアの場合は、この設定により、前述のサイズに基づいたデータ廃棄のオプションが有効化または無効化されます。ファイル・ベースのストアとデータベース・ベースのストアが混在している場合は、この設定により、ストア内の個々のアーカイブに対する期間に基づいたデータ廃棄ポリシーも有効化または無効化されます。「診断アーカイブに対する期間に基づいたデータ廃棄ポリシーの構成」を参照してください。

診断アーカイブに対する期間に基づいたデータ廃棄ポリシーの構成

サーバー・インスタンスのデータ・ストアには、以下のタイプの診断データ・アーカイブを格納できます(それらのアーカイブのレコードはデータ廃棄機能を使用して廃棄できます)。

- 収集された メトリック・データ(論理名: HarvestedDataArchive)

- インストゥルメンテーション・イベント・データ(論理名: EventsDataArchive)

- カスタム・データ(ユーザー定義の名前)

注意:
WebLogic Serverログ・ファイルは、サーバー・レベルとドメイン・レベルの両方で保持されます。データは、ログ・ローテーション機能に基づく現在のログから廃棄されます。詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogicロギング・サービスの構成に関する項を参照してください。

期間に基づいたポリシーは、個々のアーカイブに適用されます。サーバー・インスタンスのデータ・ストアでは、期間に基づいたポリシーを、HarvestedDataArchive、EventsDataArchive、および各カスタム・アーカイブに対して1つずつ指定できます。

指定された期間が経過すると、アーカイブのレコードは削除されます。

サンプル構成

データ廃棄の構成設定は、サーバーのドメインのconfig.xml構成ファイルに保持されます。例6-4を参照してください。

例6-4 config.xmlのデータ廃棄の構成設定

<domain>
<!-- other domain configuration settings -->
<server>
<name>MedRecServer</name>
<!-- other server configuration settings -->
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-data-archive-type>FileStoreArchive
</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>120</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
<wldf-data-retirement-by-age>
<name>HarvestedDataRetirementPolicy</name>
<enabled>true</enabled>
<archive-name>HarvestedDataArchive</archive-name>
<retirement-time>1</retirement-time>
<retirement-period>24</retirement-period>
<retirement-age>45</retirement-age>
</wldf-data-retirement-by-age>
<wldf-data-retirement-by-age>
<name>EventsDataRetirementPolicy</name>
<enabled>true</enabled>
<archive-name>EventsDataArchive</archive-name>
<retirement-time>10</retirement-time>
<retirement-period>24</retirement-period>
<retirement-age>72</retirement-age>
</wldf-data-retirement-by-age>
</server-diagnostic-config>
</server>
</domain>

7 メトリック収集用のハーベスタの構成

WebLogic診断フレームワーク(WLDF)のハーベスタ・コンポーネントでは、実行中のサーバーでインスタンス化される修飾されたMBeanの属性からメトリックを収集します。ハーベスタは、WebLogic Server MBeansおよびカスタムMBeansからメトリックを収集できます。

次の項では、収集およびハーベスタの構成プロセスについて説明します。

- メトリック収集、収集可能データ、および収集対象データ

- 様々な収集可能エンティティからのデータ収集

- ハーベスタの構成

メトリック収集、収集可能データ、および収集対象データ

「メトリック収集」とは、システムの状態やパフォーマンスをモニターするのに役立つデータを収集するプロセスです。メトリックは、限定されたMBeanの属性としてWLDFに公開されます。ハーベスタは、指定したサンプリング・レートで、選択したMBean属性から値を収集します。そのため、変動する可能性がある値を継続して追跡できます。

データが収集可能な状態になるには、一定の条件が必要です。また、収集対象になるには、さらに条件が必要となります。

- 「収集可能データ」は、MBeanの型、インスタンス、属性など、「収集可能エンティティ」から収集できるデータです。収集可能な状態にするには、MBeanがローカルのWebLogic ServerランタイムMBeanサーバーに登録されている必要があります。MBeanの単純型の属性のみが収集可能です。

- 「収集対象データ」は、現在収集されているデータです。収集対象の状態にするには、データが以下の条件をすべて満たしている必要があります。

- データが収集可能な状態である必要があります。

- データが収集対象になるように構成されている必要があります。

- カスタムMBeanの場合は、MBeanがJMXサーバーに現在登録されている必要があります。

- データの収集中に例外がスローしてはなりません。

WLDFHarvesterRuntimeMBeanによって獲得可能なデータと獲得済みのデータのセットが提供されます。このMBeanが戻す情報は変化可能な状態のスナップショットです。このMBeanが提供するデータに関する詳細情報は、Oracle WebLogic Server MBeanリファレンスのweblogic.management.runtime.WLDFHarvesterRuntimeMBeanに関する項を参照してください。

管理コンソール、WebLogic Scripting Tool (weblogic.WLST)、またはJMXを使用すると、サーバーMBeanおよびカスタムMBeanに格納されているメトリックを収集およびアーカイブするようにハーベスタを構成できます。

様々な収集可能エンティティからのデータ収集

指定したMBeanの型、インスタンス、属性からデータを獲得するようにハーベスタを構成できます。すべての場合では、ハーベスタは、表7-1 で説明されているように、MBeanインスタンスの属性の値を集めます。

表7-1 様々な構成からの収集対象データのソース

収集対象として構成されているエンティティ

データの収集元

型(のみ)

指定した型のすべてのインスタンスの収集可能なすべての属性

型の属性

(型+属性)

指定した型のすべてのインスタンスの指定した属性

型のインスタンス

(型+インスタンス)

指定した型の指定したインスタンスの収集可能なすべての属性

以下の型の1つのインスタンスの1つの属性

(型+インスタンス+属性)

指定した型の指定したインスタンスの指定した属性

すべてのWebLogic ServerランタイムMBeanの型と属性は、起動時に認識されます。そのため、ハーベスタの構成がロードされる場合、WebLogic Serverの収集可能エンティティのセットは、WebLogic ServerランタイムMBeanの型と属性と同じです。型がインスタンス化されると、そのインスタンスも認識されて収集可能になります。

収集可能なカスタムMBeanの型のセットは変動します。カスタムMBeanは、その型が認識される前にインスタンス化する必要があります(型が存在するようになるのは、少なくとも1つのインスタンスが作成されたときからです)。したがって、カスタムMBeanがMBeanサーバーに登録されたり、MBeanサーバーから削除されたりするとともに、カスタムMBeanの収集可能な型のセットは大きくなったり小さくなったりします。新しいMBeanの登録に基づいて新しい型を検出するこのプロセスを、「型検出」と呼びます。

管理コンソールを使用してハーベスタを構成する場合は、コンソールによって構成できる獲得可能なエンティティのリストが提供されます。このリストはWebLogic Server MBeanのためにいつも完全なものですが、カスタムMBeanのためのリストには現在に発見されたタイプのみ含まれます。Oracle WebLogic Server管理コンソール・ヘルプの「診断システム・モジュールで収集するメトリックの構成」を参照してください。

ハーベスタの構成

ハーベスタが構成され、メトリックが収集されるのは、1つまたは複数のサーバー・インスタンスを対象にした診断モジュールの範囲内です。

例7-1は、WLDFシステム・リソース記述子ファイルmyWLDF.xmlのハーベスタ構成要素を示します。このサンプル構成では、ServerRuntimeMBean、WLDFHarvesterRuntimeMBean、およびカスタム(非WLS) MBeanからデータを獲得します。リストに続いて、リスト内の各要素について説明します。

例7-1 ハーベスタ構成のサンプル(DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<name>myWLDF</name>
<harvester>
<enabled>true</enabled>
<sample-period>5000</sample-period>
<harvested-type>
<name>weblogic.management.runtime.ServerRuntimeMBean</name>
</harvested-type>
<harvested-type>
<name>weblogic.management.runtime.WLDFHarvesterRuntimeMBean</name>
<harvested-attribute>TotalSamplingTime</harvested-attribute>
<harvested-attribute>CurrentSnapshotElapsedTime
</harvested-attribute>
</harvested-type>
<harvested-type>
<name>myMBeans.MySimpleStandard</name>
<harvested-instance>myCustomDomain:Name=myCustomMBean1
</harvested-instance>
<harvested-instance>myCustomDomain:Name=myCustomMBean2
</harvested-instance>
</harvested-type>
</harvester>
<!-- ----- Other elements ----- -->
</wldf-resource>

ハーベスタのサンプリング期間の構成

<sample-period>要素は、ハーベスタのサンプル期間をミリ秒で設定します。例:

<sample-period>5000</sample-period>

サンプル期間には、各サイクル間の時間を指定します。たとえば、ハーベスタがTで指定した時間に実行を開始し、サンプル期間がIの場合、次の収集サイクルはT + I に開始されます。サイクルが完了するまでA秒かかり、AがIを上回っている場合、次のサイクルはT+Aに開始されます。この場合ハーベスタは、平均間隔がIになるように、より早く次のサイクルを開始しようとします。

収集するデータの種類の構成

1つまたは複数の<harvested-type>要素で、収集するデータの種類を指定します。各<harvested-type>要素には、メトリックを収集するMBeanの型を指定します。下位要素では、収集されるその型のインスタンスと属性のどちらか、または両方を指定します(オプション)。各オプションを次のように設定します。

- <harvested-instance>要素(オプション)では、指定した型のリストされているインスタンスからのみメトリックを収集するように指定します。通常、インスタンスを指定する場合は、そのJMX ObjectNameをJMXの標準書式で記述します。ただし、「ハーベスタ・インスタンス名でのワイルドカードの使用」で説明するように、パターン・マッチを使用すると非標準形式でインスタンス名を指定できます。

- <harvested-instance>の指定がない場合、各収集サイクルにおいて、そのときに存在するすべてのインスタンスが収集されます。

- <harvested-attribute>要素(オプション)では、指定した型のリストされている属性からのみメトリックを収集するように指定します。通常、属性はその名前を記述して指定します。最初の文字は大文字にする必要があります。たとえば、ゲッター・メソッドgetFoo()が定義されている属性の名前はFooです。
また、<harvested-attribute>要素は、リスト、マップ、単純なPOJO (Plain Old Java Object)、およびこれらが様々な形でネストされたものなど複合、または集約オブジェクトである属性に「ドリルダウン」するための式構文もサポートします。この構文の詳細は、「ハーベスタの複合属性およびネストされた属性の指定」を参照してください。ただし、データを収集するには、これらの式の結果が組込みの単純型(整数、ブール、文字列など)でなければならない点に注意してください。

- <harvested-attribute>の指定がない場合、その型に定義されているすべての属性が収集されます。

- 1つの型の中で属性とインスタンスのリストを組み合わせることができます。

WebLogic Server MBeanとカスタムMBeanの型名の指定

ハーベスタは、WebLogic Server MBeanとカスタムMBeanをサポートしています。WebLogic Server MBeanは、WebLogic Serverの一部としてパッケージ化されているMBeanです。カスタムMBeanは、ローカル・ランタイムMBeanサーバーに登録されている間は収集可能です。

WebLogic Serverとカスタムの型では、その指定方法が異なります。WebLogic Server MBeanの型では、型名はそのMBeanを定義するJavaインタフェースの名前です。たとえば、サーバーのランタイムMBeanの型名はweblogic.management.runtime.ServerRuntimeMBeanです。

カスタムMBeanの場合、ハーベスタは次のルールに従います。

- MBeanがModelMBeanでなければ、型名は実装クラス名です。(たとえば、例7-1を参照してください。)

- MBeanがModelMBeanの場合、型名はMBean記述子フィールドDiagnosticTypeNameの値。

これらの条件のどちらも満たされていない場合(MBeanがModelMBeanであり、MBean記述子field DiagnosticTypeNameのための値がなければ)、MBeanを収集することができません。

DomainRuntime MBeanServerからの収集

<harvested-type>要素は、DomainRuntime MBeanServerに登録されたMBeansからメトリックを収集ことができる<namespace>属性をサポートします。ただし、この属性を使用した収集は、ServerLifeCycleRuntimeMBeanなど、DomainRuntime固有のMBeanのみに制限することをお薦めします。リモートの管理対象サーバーMBeanもDomainRuntime MBeanServerを介して収集できますが、パフォーマンスに影響するため推奨されません。ベスト・プラクティスは、各管理対象サーバーで常駐ハーベスタを使用し、その管理対象サーバー・インスタンスに関連するメトリックをキャプチャすることです。

<namespace>属性は2つの値の1つを持つことができます。

- ServerRuntime

- DomainRuntime

<namespace>属性が省略される場合、それはServerRuntimeをデフォルトとします。

注意:
DomainRuntime MBeanサーバーからの獲得は管理サーバーでのみ使用可能です。管理対象サーバーでDomainRuntime MBeansの収集ができません。たとえば、例7-5を参照してください。

構成設定を検証するタイミング

WLDFでは、できる限り速やかに構成を検証しようとします。ほとんどの構成は、サーバーの起動時および動的な変更がコミットされる度に検証されます。ただし、JMXの制限により、カスタムMBeanはそのインスタンスがMBeanサーバーに登録されるまでは検証されません。

様々な収集可能な型の構成のサンプル

例7-2では、DIAG_MODULE.xml構成ファイルの<harvested-type>の要素は、ServerRuntimeMBeanが収集られることになっていると指定します。<harvested-instance>の下位要素が存在しないので、タイプのすべてのインスタンスが集められます。ただし、サーバーのランタイムMBeanのインスタンスは常に1つだけなので、特定のインスタンスのリストを指定する必要はありません。そして、<harvested-attribute>のある下位要素もないため、MBeanのすべての利用可能な属性がそれぞれの2つのインスタンスに対して収集されます。

例7-2 型のすべてのインスタンスと属性を収集する構成のサンプル(DIAG_MODULE.xml内)

<harvested-type>
<name>weblogic.management.runtime.ServerRuntimeMBean</name>
</harvested-type>

例7-3で、DIAG_MODULE.xml構成ファイルの<harvested-type>要素では、WLDFHarvesterRuntimeMBeanが収集されることを指定しています。上記の例と同様に、存在するWLDFHarvesterRuntimeMBeanは1つだけなので、特定のインスタンスのリストを指定する必要がありません。下位要素<harvested-attribute>は、WLDFHarvesterRuntimeMBeanの2つの利用可能な属性だけが収集られると指定しますTotalSamplingTimeとCurrentSnapshotElapsedTime。

例7-3 型のすべてのインスタンスの指定した属性を収集する構成のサンプル(DIAG_MODULE.xml内)

<harvested-type>
<name>weblogic.management.runtime.WLDFHarvesterRuntimeMBean</name>
<harvested-attribute>TotalSamplingTime</harvested-attribute>
<harvested-attribute>CurrentSnapshotElapsedTime
</harvested-attribute>
</harvested-type>

例7-4で、DIAG_MODULE.xml構成ファイルの<harvested-type>要素では、カスタムMBean型の1つのインスタンスが収集されることを指定しています。この場合、カスタムMBeanなので、型名は実装クラスです。この例では、2つの<harvested-instance>要素で、この型のインスタンスが2つだけ収集されるように指定しています。各インスタンスは、JMX ObjectNameの標準表現を使用することで指定されます。<harvested-attribute>のインスタンスは指定されていないので、すべての属性が収集の対象になります。

例7-4 型の指定したインスタンスの指定したすべての属性を収集する構成のサンプル(DIAG_MODULE.xml内)

<harvested-type>
<name>myMBeans.MySimpleStandard</name>
<harvested-instance>myCustomDomain:Name=myCustomMBean1
</harvested-instance>
<harvested-instance>myCustomDomain:Name=myCustomMBean2
</harvested-instance>
</harvested-type>

例7-5で、DIAG_MODULE.xml構成ファイルの<harvested-type>要素では、ServerLifeCycleRuntimeMBeanが収集されることを指定しています。<namespace>属性では、これがDomainRuntime MBeanであることを指定しているため、この構成が適用されるのは管理サーバーのみです(「DomainRuntime MBeanServerからの収集」の「注意」を参照)。下位要素<harvested-attribute>は、StateVal属性だけが収集されることを指定します。

例7-5 ServerLifeCycleMBean型の指定したインスタンスの指定した属性を収集する構成のサンプル

<harvested-type>
<name>weblogic.management.runtime.ServerLifeCycleRuntimeMBean</name>
<namespace>DomainRuntime</namespace>
<known-type>true</known-type>
<harvested-attribute>StateVal</harvested-attribute>
</harvested-type>

8 監視および通知の構成

WebLogic診断フレームワーク(WLDF)の監視および通知コンポーネントでは、サーバーとアプリケーションの状態をモニターし、監視で設定した条件に基づく通知を送信できます。監視および通知は、ドメイン内の1つまたは複数のサーバーをターゲットとする診断モジュールの一部として構成されます。

監視および通知については、次の項で説明します。

- 監視および通知

- 監視および通知の構成の概要

- 監視および通知の構成のサンプル

監視および通知

監視は、モニターまたは診断目的で捕捉する状況を識別します。監視は、ログ・レコード、データ・イベント、および収集されたメトリックを分析するよう構成できます。監視は、監視ルールとして指定されます。

- 監視ルール式

- アラーム設定

- 1つまたは複数の通知ハンドラ

通知は、監視ルール式の評価がtrueとなった場合のアクションです。WLDFでは、以下の種類の通知をサポートしています。

- Java Management Extensions (JMX)

- Java Message Service (JMS)

- 電子メールなどのSimple Mail Transfer Protocol (SMTP)

- Simple Network Management Protocol (SNMP)

- 診断イメージ

監視は、実行中のサーバーの指定した状態またはアクティビティについて管理者に通知する場合など、役に立つ診断アクティビティの通知に関連付ける必要があります。

監視および通知は、それぞれ別に構成されます。通知は複数の監視に関連付けることができ、監視は複数の通知に関連付けることができます。そのため、現在のニーズに応じて、監視および通知を柔軟に再結合し、再利用することができます。

監視および通知の構成の概要

完全な監視および通知の構成には、1つまたは複数の監視、1つまたは複数の通知、通知媒体で必要な基底の構成(たとえば、SNMPベースの通知の場合はSNMP構成)の設定が含まれます。

WLDFシステム・リソース記述子ファイルDIAG_MODULE.xmlの、監視および通知の構成に必要な主な要素を例8-1に示します。例で示すように、監視および通知を定義するための基本要素は<watch-notification>です。監視は<watch>要素で定義され、通知は、種類ごとに指定されている要素<jms-notification>、<jmx-notification>、<smtp-notification>、<image-notification>などで定義されます。

例8-1 監視および通知の構成のスケルトン(DIAG_MODULE.xml内)

<wldf-resource>
<!-- ----- Other system resource configuration elements ----- -->
<watch-notification>
<log-watch-severity>
<!-- Threshold severity for a log watch to be evaluated further
(This can be narrowed further at the watch level.) -->
</log-watch-severity>
<!-- ----- Watch configuration elements: ----- -->
<watch>
<!-- A watch rule -->
</watch>
<watch>
<!-- A watch rule -->
</watch>
<!-- Any other watch configurations -->

<!-- ----- Notification configuration elements: ----- -->
<!-- The following notification configuration elements show one of each
type of supported notifications. However, not all types are
required in any one system resource configuration, and multiples
of any type are permitted. -->
<jms-notification>
<!-- Configuration for a JMS-based notification; requires a
corresponding JMS configuration via a jms-server element and a
jms-system-resource element -->
</jms-notification>

<jmx-notification>
<!-- Configuration for a JMX-based notification -->
</jmx-notification>
<smtp-notification>
<!-- Configuration for an SMTP-based notification; requires a
corresponding SMTP configuration via a mail-session element -->
</smtp-notification>
<snmp-notification>
<!-- Configuration for an SNMP-based notification; requires a
corresponding SNMP agent configuration via an snmp-agent
element -->
</snmp-notification>
<image-notification>
<!-- Configuration for an image-based notification -->
</image-notification>
<watch-notification>
<!-- ----- Other configuration elements ----- -->
</wldf-resource>

注意:
通知媒体は、その通知媒体に応じた通知で使用できるように構成する必要がありますが、その構成は、診断モジュール自体の構成の一部ではありません。つまり、通知媒体は、診断モジュールの構成ファイルの<wldf-resource>要素で構成されるものではありません。

監視および/または通知に対して個別に<enabled>true</enabled>または<enabled>false</enabled>を設定することにより、個々の監視および通知を個別に有効化および無効化できます。また、すべての監視および通知に対して<enabled>true</enabled>または<enabled>false</enabled>を設定すると、監視および通知の機能全体を有効化および無効化できます。デフォルト値は<enabled>true</enabled>です。

<watch-notification>要素には、<log-watch-severity>下位要素があります。この下位要素は、ログ・ルールの監視によってトリガーされる通知の起動に影響します。

監視をトリガーしたログ・メッセージの最大の重大度レベルが、指定されている重大度レベルと同じレベル以上でなければ、その監視でトリガーされる通知は起動しません。ただし、これはログ・ルール・タイプの監視によって起動される通知にのみ適用されます。この要素を、監視に対して定義する<severity>要素と混同しないでください。<severity>要素は、監視自体に重大度を割り当てるものですが、<log-watch-severity>要素は、ログ・ルールの監視によってどの通知が起動されるかを指定します。

管理コンソールを使用した監視および通知を構成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの監視および通知の構成に関する項を参照してください。

監視および通知の構成のサンプル

診断モジュールの監視および通知の構成のセットに関する完全な構成を例8-2に示します。この例については、以下の2つの章で詳しく説明します。

- 第9章「監視の構成」

- 第10章「通知の構成」

例8-2 監視および通知の構成のサンプル(DIAG_MODULE.xml内)

<?xml version='1.0' encoding='UTF-8'?>
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<!-- Instrumentation must be configured and enabled for instrumentation
watches -->
<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>DyeInjection</name>
<description>Dye Injection monitor</description>
<dye-mask xsi:nil="true"></dye-mask>       <properties>ADDR1=127.0.0.1</properties>
</wldf-instrumentation-monitor>
</instrumentation>
<!-- Harvesting does not have to be configured and enabled for harvester
watches. However, configuring the Harvester can provide advantages;
for example the data will be archived. -->
<harvester>
<name>mywldf1</name>
<sample-period>20000</sample-period>
<harvested-type>
<name>weblogic.management.runtime.ServerRuntimeMBean</name>
</harvested-type>
<harvested-type>
<name>weblogic.management.runtime.WLDFHarvesterRuntimeMBean</name>
</harvested-type>
</harvester>
<!-- All watches and notifications are defined under the
watch-notification element -->
<watch-notification>
<enabled>true</enabled>
<log-watch-severity>Info</log-watch-severity>
<!-- A harvester watch configuration -->
<watch>
<name>myWatch</name>
<enabled>true</enabled>
<rule-type>Harvester</rule-type>
<rule-expression>${com.bea:Name=myserver,Type=ServerRuntime//SocketsOpenedTotalCount} &gt;= 1</rule-expression>
<alarm-type>AutomaticReset</alarm-type>
<alarm-reset-period>60000</alarm-reset-period>
<notification>myMailNotif,myJMXNotif,mySNMPNotif</notification>
</watch>
<!-- An instrumentation watch configuration -->
<watch>
<name>myWatch2</name>
<enabled>true</enabled>
<rule-type>EventData</rule-type>
<rule-expression>
(MONITOR LIKE 'JDBC_After_Execute') AND
(DOMAIN = 'MedRecDomain') AND
(SERVER = 'medrec-adminServer') AND
((TYPE = 'ThreadDumpAction') OR (TYPE = TraceElapsedTimeAction')) AND
(SCOPE = 'MedRecEAR')
</rule-expression>
<notification>JMXNotifInstr</notification>
</watch>
<!-- A log watch configuration -->
<watch>
<name>myLogWatch</name>
<rule-type>Log</rule-type>
<rule-expression>MSGID='BEA-000360'</rule-expression>
<severity>Info</severity>
<notification>myMailNotif2</notification>
</watch>
<!-- A JMX notification -->
<jmx-notification>
<name>myJMXNotif</name>
</jmx-notification>
<!-- Two SMTP notifications -->
<smtp-notification>
<name>myMailNotif</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject>This is a harvester alert</subject>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
<smtp-notification>
<name>myMailNotif2</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject>This is a log alert</subject>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
<!-- An SNMP notification -->
<snmp-notification>
<name>mySNMPNotif</name>
<enabled>true</enabled>
</snmp-notification>
</watch-notification>
</wldf-resource>

9 監視の構成

次の項では、監視の種類とそれぞれの構成オプションについて説明します。

- 監視の種類

- すべての種類の監視で共有される構成オプション

- ハーベスタ監視の構成

- ログ監視の構成

- インストゥルメンテーション監視の構成

- 監視ルール式の定義

管理コンソールを使用して監視を作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュール用の監視の作成に関する項を参照してください。

監視の種類

WLDFでは、何をモニターするかによって3種類の監視を使用できます。

- ハーベスタ監視では、ローカル・ランタイムMBeanサーバーの収集可能なMBeanのセットをモニターします。

- ログ監視では、サーバー・ログに生成されるメッセージのセットをモニターします。

- インストゥルメンテーション (またはイベント・データ)監視では、WLDFインストゥルメンテーション・コンポーネントによって生成されるイベントのセットをモニターします。

診断モジュールのWLDFシステム・リソース構成ファイルでは、各種類の監視は、<watch>の子要素である<rule-type>要素で定義されます。例:

<watch>
<rule-type>Harvester</rule-type>
<!-- Other configuration elements -->
</watch>

ルールの種類が異なる監視では、以下の2つの点に違いがあります。

- 監視対象となる条件を指定するためのルール構文。ルール構文は、ルールの種類ごとに異なります。

- ログ監視とインストゥルメンテーション監視はリアルタイムでトリガーされますが、ハーベスタ監視は、現在の収集サイクルが終了してからトリガーされます。

すべての種類の監視で共有される構成オプション

どの監視でも共有される構成オプションは以下のとおりです。

- 監視ルール式
診断モジュール構成ファイルでは、監視ルール式は<rule-expression>要素で定義されます。

監視ルール式は、監視が捕捉する重要なイベントを指定する論理式です。各種類の監視ルールで使用可能な構文など、監視ルールの定義に使用する問合せ言語については、付録A「WLDF問合せ言語」を参照してください。

- 監視に関連付けられる通知
診断モジュール構成ファイルでは、通知は<notification>要素で定義されます。

各監視は、監視の評価がtrueのときにトリガーされる1つまたは複数の通知に関連付けることができます。この要素には、複数の通知をカンマ区切りのリストで指定します。通知の構成については、第10章「通知の構成」を参照してください。

- アラーム・オプション
診断モジュール構成ファイルでは、アラーム・オプションは<alarm-type>要素と<alarm-reset-period>要素で設定します。

監視は繰返しトリガーするように指定することも、条件に合致したときに一度だけトリガーするように指定することもできます。繰返しトリガーする監視については、任意でそのトリガー間の最短間隔を定義できます。<alarm-type>要素では、監視で自動的に繰返しトリガーするかどうか、トリガーする場合にはどの程度の間隔で行うかを定義します。noneを値として指定すると、監視は可能なときにいつでもトリガーします。AutomaticResetを値として指定した場合にも、監視は可能なときにいつでもトリガーしますが、<alarm-reset-period>で指定されたミリ秒間隔が経過するまで後続のトリガーは発生しません。ManualResetを値として指定すると、監視は一度だけ起動します。起動した後にもう一度起動させるには、手動で再設定する必要があります。たとえば、WatchNotificationRuntimeMBeanを使用すると、手動による監視を再設定できます。<alarm-type>のデフォルトはNoneです。

- 重大度オプション
監視には、通知先に渡す重大度の値を指定します。許容される重大度の値は、ロギング・サブシステムに定義されている値と同じです。この重大度の値は下位要素<severity>を使用して指定します。デフォルトはNoticeです。

- 有効化オプション
個々の監視を、下位要素<enabled>を使用して個別に有効または無効にできます。無効にした場合、監視ではトリガーを行わず、対応する通知も起動しません。より包括的な監視通知フラグを無効にすれば、個々の監視を確実に無効にできます(つまり、個別の監視におけるこのフラグの値が無視されます)。

ハーベスタ監視の構成

ハーベスタ監視では、ローカル・ランタイムMBeanサーバーの任意のランタイムMBeanをモニターできます。

注意:
ハーベスタがデータを収集しないように構成されているMBean (またはMBean属性)をモニターするように監視ルールを定義している場合、監視は実行されます。ハーベスタは、定義された監視ルールで設定された要件を満たす値を「暗黙的」に収集します。ただし、この方法で(つまり、監視用に暗黙的に)収集されたデータはアーカイブされません。ハーベスタの詳細は、第7章「メトリック収集用のハーベスタの構成」を参照してください。

ハーベスタ監視は、ハーベスタ・サイクルに応じてトリガーされます。そのためハーベスタ監視の場合、ハーベスタのサンプル期間は、ある状況が識別されてから、通知によって報告されるまでの間隔を定義します。平均して、この遅延はサンプル期間/2になります。

例9-1に、複数のランタイムMBeanをモニターするハーベスタ監視の構成例を示します。監視ルール(<rule-expression>要素で定義)の評価がtrueの場合、トピックとキュー用にJMX通知、SMTP通知、SNMP通知、イメージ通知、およびJMS通知の6種類の通知が送られます。

監視ルールは、4つのハーベスタ変数で構成される論理式です。監視ルールの形式は次のとおりです。

( (A >= 100) AND (B > 0) ) OR C OR D.equals("active")

各変数の形式は次のとおりです。

{entityName}//{attributeName}

{entityName}は、ランタイムMBeanサーバーに登録されているJMXのObjectNameまたはハーベスタで定義されている型名、{attributeName}は、そのMBean型に定義されている属性の名前です。

注意:
比較演算子は、XMLで有効となるように適切な形をとっています。

例9-1 ハーベスタ監視の構成のサンプル(DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<harvester>
<!-- Harvesting does not have to be configured and enabled for harvester
watches. However, configuring the Harvester can provide advantages;
for example the data will be archived. -->
<harvested-type>
<name>myMBeans.MySimpleStandard</name>
<harvested-instance>myCustomDomain:Name=myCustomMBean1
</harvested-instance>
<harvested-instance>myCustomDomain:Name=myCustomMBean2
</harvested-instance>
</harvested-type>
<!-- Other Harvester configuration elements -->
</harvester>
<watch-notification>
<watch>
<name>simpleWebLogicMBeanWatchRepeatingAfterWait</name>
<enabled>true</enabled>
<rule-type>Harvester</rule-type>
<rule-expression>
(${mydomain:Name=WLDFHarvesterRuntime,ServerRuntime=myserver,Type=
WLDFHarvesterRuntime,WLDFRuntime=WLDFRuntime//TotalSamplingTime}
&gt;= 100
AND
${mydomain:Name=myserver,Type=
ServerRuntime//OpenSocketsCurrentCount} &gt; 0)
OR
${mydomain:Name=WLDFWatchNotificationRuntime,ServerRuntime=
myserver,Type=WLDFWatchNotificationRuntime,
WLDFRuntime=WLDFRuntime//Enabled} = true
OR
${myCustomDomain:Name=myCustomMBean3//State} =
'active')
</rule-expression>
<severity>Warning</severity>
<alarm-type>AutomaticReset</alarm-type>
<alarm-reset-period>10000</alarm-reset-period>
<notification>myJMXNotif,myImageNotif,
myJMSTopicNotif,myJMSQueueNotif,mySNMPNotif,
mySMTPNotif</notification>
</watch>
<!-- Other watch-notification configuration elements -->
</watch-notification>
</wldf-resource>

この監視では、AutomaticResetタイプのアラームを使用しています。つまり、最後に起動されたときからの時間が、アラーム・リセット期間として設定された間隔(この場合10000ミリ秒)よりも長くなると、繰返しトリガーされる可能性があります。

指定された重大度レベルWarningは、監視のトリガーには影響しませんが、通知によって伝達されます。

ログ監視の構成

ログ監視を使用して、サーバー・ログにおける特定のメッセージまたは文字列の出現をモニターします。この種類の監視は、指定されたデータを含むログ・メッセージが発行されるとトリガーされます。

例9-2に、ログ監視の構成の例を示します。

例9-2 ログ監視の構成のサンプル(DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<enabled>true</enabled>
<log-watch-severity>Info</log-watch-severity>
<watch>
<name>myLogWatch</name>
<rule-type>Log</rule-type>
<rule-expression>MSGID='BEA-000360'</rule-expression>
<severity>Info</severity>
<notification>myMailNotif2</notification>
</watch>
<smtp-notification>
<name>myMailNotif2</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject>This is a log alert</subject>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
</watch-notification>
</wldf-resource>

インストゥルメンテーション監視の構成

インストゥルメンテーション監視は、WLDFのインストゥルメンテーション・コンポーネントに由来するイベントをモニターするために使用します。この種類の監視は、イベントがポストされるとトリガーされます。

例9-3に、インストゥルメンテーション監視の構成の例を示します。

例9-3 インストゥルメンテーション監視の構成のサンプル(DIAG_MODULE.xml内)

<watch-notification>
<watch>
<name>myInstWatch</name>
<enabled>true</enabled>
<rule-type>EventData</rule-type>
<rule-expression>
(PAYLOAD &gt; 100000000) AND (MONITOR = 'Servlet_Around_Service')
</rule-expression>
<alarm-type xsi:nil="true"></alarm-type>
<notification>mySMTPNotification</notification>
</watch>
<smtp-notification>
<name>mySMTPNotification</name>
<enabled>true</enabled>
<mail-session-jndi-name>myMailSession</mail-session-jndi-name>
<subject xsi:nil="true"></subject>
<body xsi:nil="true"></body>
<recipient>username@emailservice.com</recipient>
</smtp-notification>
</watch-notification>

監視ルール式の定義

監視ルール式は、ルールの指定に必要なすべての情報をカプセル化します。各種類の監視ルールの定義に使用する問合せ言語については、付録A「WLDF問合せ言語」を参照してください。

10 通知の構成

次の項では、通知の種類とそれぞれの:構成オプションについて説明します。

- 通知の種類

- JMX通知の構成

- JMS通知の構成

- SNMP通知の構成

- SMTP通知の構成

- イメージ通知の構成

管理コンソールを使用して通知を作成する方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュールの監視用の通知の作成に関する項を参照してください。

通知の種類

通知監視ルールの評価がtrueとなった場合にトリガーされるアクションです。WLDFでは、配信メカニズムに従って、Java Management Extensions (JMX)、Java Message Service (JMS)、Simple Mail Transfer Protocol (SMTP)、およびSimple Network Management Protocol (SNMP)の4種類の診断通知がサポートされています。また、診断イメージを生成する通知を作成することもできます。

診断モジュールの構成ファイルでは、以下の要素によって、種類の異なる通知が識別されます。

- <jmx-notification>

- <jms-notification>

- <snmp-notification>

- <smtp-notification>

- <image-notification>

上記のいずれの通知にも、<name>および<enabled>構成オプションがあります。<name>の値は、監視を対応する通知にマップするために監視の<notification>要素の値として使用されます。<enabled>要素をtrueに設定すると、その通知が有効になります。つまり、関連する監視がtrueと評価すると、通知が起動されます。<name>および<enabled>を除き、各通知は一意です。

注意:
通知はweblogic.diagnostics.watch.WatchNotificationを使用してプログラム的に定義します。

JMX通知の構成

関連する監視がトリガーされると、WLDFは、定義されたJMX通知ごとにJMXイベント(通知)を発行します。すべての通知を受信し、指定した出力をフィルタ処理するために、各アプリケーションは、通知リスナーをサーバーのWLDFWatchJMXNotificationRuntimeMBeanに登録できます。JMXクライアントがフィルタとして使用できるJMX「通知タイプ」の文字列を指定することもできます。

例10-1では、JMX通知の構成の例を示します。

例10-1 JMX通知の構成のサンプル

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more watch configurations -->
<jmx-notification>
<name>myJMXNotif</name>
<enabled>true</enabled>
</jmx-notification>
<!-- Other notification configurations -->
</watch-notification>
</wldf-resource>

次に、JMX通知の例を示します。

Notification name:    myjmx called. Count= 42.
Watch severity:         Notice
Watch time:             Jul 19, 2005 3:40:38 PM EDT
Watch ServerName:       myserver
Watch RuleType:         Harvester
Watch Rule:               ${com.bea:Name=myserver,Type=ServerRuntime//OpenSocketsCurrentCount} > 1
Watch Name:             mywatch
Watch DomainName:       mydomain
Watch AlarmType:        None
Watch AlarmResetPeriod: 10000

JMS通知の構成

JMS通知は、関連する監視のトリガーに応じてJMSトピックまたはJMSキューにメッセージをポストするために使用します。システム・リソース構成ファイルの<destination-jndi-name>要素と<connection-factory-jndi-name>要素で、メッセージの配信方法を定義します。

例10-2に、指定した接続ファクトリを使用して、指定トピックおよびキューからJMSメッセージを送信する2つのJMS通知を示します。この処理を適切に行うためには、ドメインのconfig.xmlファイルでJMSが適切に構成されている必要があります。また、JMSリソースがこのサーバーにターゲット指定されている必要があります。

例10-2 JMS通知のサンプル

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more watch configurations -->
<jms-notification>
<name>myJMSTopicNotif</name>
<destination-jndi-name>MyJMSTopic</destination-jndi-name>
<connection-factory-jndi-name>weblogic.jms.ConnectionFactory
</connection-factory-jndi-name>
</jms-notification>
<jms-notification>
<name>myJMSQueueNotif</name>
<destination-jndi-name>MyJMSQueue</destination-jndi-name>
<connection-factory-jndi-name>weblogic.jms.ConnectionFactory
</connection-factory-jndi-name>
</jms-notification>
<!-- Other notification configurations -->
</watch-notification>
</wldf-resource>

監視および通知の詳細は、通知メッセージの内容で示されます。

SNMP通知の構成

Simple Network Management Protocol (SNMP)通知は、関連する監視のトリガーに応じてSNMPトラップをポストするために使用します。SNMP通知を定義するには、例10-3に示すように、通知名を指定するだけで済みます。生成されたトラップには、トラップが生成される原因になった監視および通知の両方の名前が含まれます。SNMPトラップを適切に行うためには、ドメインのconfig.xml構成ファイルでSNMPが適切に構成されている必要があります。

例10-3 SNMP通知の構成のサンプル

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more watch configurations -->
<snmp-notification>
<name>mySNMPNotif</name>
</snmp-notification>
<!-- Other notification configurations -->
</watch-notification>
</wldf-resource>

例10-3のSNMP通知の構成によって生成されるトラップの型は85です。ここには、以下の値が含まれます(構成された値は山カッコ「<>」で示します)。

.1.3.6.1.4.1.140.625.100.5   timestamp (e.g. Dec 9, 2004 6:46:37 PM EST
.1.3.6.1.4.1.140.625.100.145  domainName (e.g. mydomain")
.1.3.6.1.4.1.140.625.100.10   serverName (e.g. myserver)
.1.3.6.1.4.1.140.625.100.120  <severity> (e.g. Notice)
.1.3.6.1.4.1.140.625.100.105  <name> [of watch] (e.g.
simpleWebLogicMBeanWatchRepeatingAfterWait)
.1.3.6.1.4.1.140.625.100.110  <rule-type> (e.g. HarvesterRule)
.1.3.6.1.4.1.140.625.100.115  <rule-expression>
.1.3.6.1.4.1.140.625.100.125  values which caused rule to
fire (e.g..State =
null,weblogic.management.runtime.WLDFHarvesterRuntimeMBean.
TotalSamplingTime = 886,.Enabled =
null,weblogic.management.runtime.ServerRuntimeMBean.
OpenSocketsCurrentCount = 1,)
.1.3.6.1.4.1.140.625.100.130  <alarm-type> (e.g. None)
.1.3.6.1.4.1.140.625.100.135  <alarm-reset-period> (e.g. 10000)
.1.3.6.1.4.1.140.625.100.140  <name> [of notification]
(e.g.mySNMPNotif)

SMTP通知の構成

Simple Mail Transfer Protocol (SMTP)通知は、関連する監視のトリガーに応じてSMTPプロトコルでメッセージ(電子メール)を送信するために使用します。SMTP通知を定義するには、最初にSMTPセッションを構成します。その構成は、ドメインのconfig.xml構成ファイルで永続化されます。DIAG_MODULE.xmlで、下位要素<mail-session-jndi-name>を使用して、構成済みのSMTPセッションを指定し、下位要素<recipients>を使用して、宛先(少なくとも1つ)のリストを指定します。下位要素<subject>では件名、<body>では本文を指定できます(いずれも省略可能)。これらを指定しない場合、デフォルトが使用されます。

例10-4に、構成されたSMTPセッションから構成された宛先にSMTP (電子メール)メッセージを配信するSMTP通知を示します。この通知の構成では、カスタム・サブジェクトおよび本文が記述されています。件名または本文を指定しなかった場合は、デフォルト設定(監視および通知の詳細表示)が使用されます。

例10-4 SMTP通知の構成のサンプル(DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more watch configurations -->
<smtp-notification>
<name>mySMTPNotif</name>
<mail-session-jndi-name>MyMailSession</mail-session-jndi-name>
<subject>Critical Problem!</subject>
<body>A system issue occurred. Call Winston ASAP.
Reference number 81767366662AG-USA23.</body>
<recipients>administrator@myCompany.com</recipients>
</smtp-notification>
<!-- Other notification configurations -->
</watch-notification>
</wldf-resource>

監視および通知の詳細は、通知メッセージの内容で示されます。

イメージ通知の構成

イメージ通知を使用すると、関連する監視のトリガーに応じて診断イメージが生成されます。イメージ通知には、ディレクトリとロックアウト期間の2つのオプションを構成できます。

ディレクトリ名はイメージの生成先を示します。ロックアウト期間には、最後にイメージが生成されてから新しいイメージが生成されるまでに経過する必要のある秒数を指定します。サーバーの障害と回復が繰り返される場合に、生成されるイメージの数を制限するのに便利です。

DOMAIN_NAME\servers\SERVER_NAMEディレクトリを基準とした相対的なディレクトリ名を指定できます。DOMAIN_NAMEはドメインのホーム・ディレクトリ、SERVER_NAMEはサーバーの名前です。デフォルトのディレクトリはDOMAIN_NAME\servers\SERVER_NAME\logs\diagnostic-imagesです。

イメージ・ファイル名は、その時点のタイムスタンプを基に生成されます(たとえば、diagnostic_image_myserver_2005_08_09_13_40_34.zip)。この通知は、起動するたびに別個のイメージ・ファイルを生成するので、何度でも起動可能です。

構成はDIAG_MODULE.xml構成ファイルで永続化されます。例10-5に、ロックアウト期間が2分間で、イメージがDOMAIN_NAME\servers\SERVER_NAME\imagesディレクトリに生成されることを指定したイメージ通知の構成を示します。

例10-5 イメージ通知の構成のサンプル( DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more watch configurations -->
<image-notification>
<name>myImageNotif</name>
<enabled>true</enabled>
<image-lockout>2</image-lockout>
<image-directory>images</image-directory>
</image-notification>
<!-- Other notification configurations -->
</watch-notification>
</wldf-resource>

診断イメージの詳細は、第5章「診断イメージの構成とキャプチャ」参照してください。

11 インストゥルメンテーションの構成

WebLogic診断フレームワーク(WLDF)のインストゥルメンテーション・コンポーネントは、WebLogic Serverインスタンスおよびそのサーバー・インスタンスで実行中のアプリケーションに診断コードを追加するためのメカニズムを提供します。WLDFのインストゥルメンテーションでの主な機能は次のとおりです。

- 診断モニター。サーバーまたはアプリケーション・コードの特定の場所に挿入され、動的に管理できるひとまとまりの診断コードです。モニターは、スコープ(システム、アプリケーション)および種類(標準、委任、カスタム)を基に定義します。

- 診断アクション。プログラムの実行中にトリガーされたモニターが行うアクションです。

- 診断コンテキスト。診断コンテキストは、送信元のIPアドレスやユーザーIDなど、特定のリクエスト・プロパティの存在を示すフラグや固有のリクエスト識別子などのコンテキスト情報です。診断コンテキストでは、プログラムの実行を追跡したり、モニターが診断アクションをトリガーするタイミングを制御できます。第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

WLDFには、あらかじめ定義された診断モニターと診断アクションのライブラリが用意されています。また、アプリケーション・スコープのカスタム・モニターを作成し、診断コードが挿入されるアプリケーション内の位置をユーザーが決めることもできます。

インストゥルメンテーションについては、次の項で説明します。

- 概念と用語

- インストゥルメンテーション構成ファイル

- インストゥルメンテーションに使用するXML要素

- サーバー・スコープのインストゥルメンテーションの構成

- アプリケーション・スコープのインストゥルメンテーションの構成

- リクエスト・パフォーマンス・データの作成

概念と用語

この項では、インストゥルメンテーションの概念と用語について説明します。以下の内容について説明します。

- インストゥルメンテーションのスコープ

- 構成とデプロイメント

- ジョインポイント、ポイントカット、診断ロケーション

- 診断モニターのタイプ

- 診断アクション

インストゥルメンテーションのスコープ

実行可能なインストゥルメンテーション・サービスには、システム・レベル(サーバーおよびクラスタ)のものとアプリケーション・レベルのものがあります。概念、サービス、構成オプション、および実装機能の多くは両者とも同じです。ただし、相違点もいくつかあります。それらについては、このドキュメントで説明しています。サーバー・スコープ・インストゥルメンテーションは、WebLogic Serverインスタンスおよびクラスタ固有のインストゥルメンテーションの構成と機能を指します。これに対して、アプリケーション・スコープ・インストゥルメンテーションは、WebLogic Serverにデプロイされているアプリケーション固有の構成と機能を指します。スコープは各診断モニターに組み込まれており、ユーザーがモニターのスコープを変更することはできません。

構成とデプロイメント

サーバーまたはクラスタ向けのサーバー・スコープ・インストゥルメンテーションは、診断モジュールの一部として、DOMAIN_NAME/config/diagnosticsディレクトリにあるXML構成ファイルで構成およびデプロイされ、config.xmlからリンクされています。

アプリケーション・スコープ・インストゥルメンテーションも、診断モジュールとして構成およびデプロイされます。ただし、アプリケーション・スコープの場合は、デプロイされるアプリケーションのARCHIVE_PATH/META-INFディレクトリ内のアプリケーション・アーカイブとともにパッケージ化されたweblogic-diagnostics.xmlというXML構成ファイルを使用します。

ジョインポイント、ポイントカット、診断ロケーション

インストゥルメンテーション・コードは、サーバーおよびアプリケーションのコード内の特定の場所に挿入(またはウィービング)されます。この特定の場所を表すために、以下の用語が使用されています。

- 「ジョインポイント」は、クラス内の特定の場所です。たとえば、メソッドの入り口や出口のポイント、メソッド内のコール・サイトなどを指します。

- 「ポイントカット」は、ジョインポイントのセットを示す用語で、作業項目のスケジューリング、開始、および実行に関わるすべてのメソッドなどを指します。ポイントカットを定義するXML要素は<pointcut>です。ポイントカットについては、「カスタム・モニターのポイントカットの定義」を参照してください。

- 「診断ロケーション」は、ジョインポイントを基準にした、診断アクティビティが実行される位置です。診断ロケーションには、Before(ジョインポイントの前)、After(ジョインポイントの後)、Around(ジョインポイントの前後)のいずれかを指定できます。診断ロケーションを定義するXML要素は<location-type>です。

診断モニターのタイプ

診断モニターは、そのスコープと種類によって分類されます。スコープは、サーバー・スコープかアプリケーション・スコープのどちらかです。種類は、モニターのポイントカット、診断場所、およびアクションによって決まります。たとえば、Servlet_Around_Serviceはアプリケーション・スコープの委任モニターです。このモニターを使用すると、特定のサーブレット・メソッドやJSPメソッドの入り口と出口で診断アクションをトリガーできます。

診断モニターには、次に示す3種類があります。

- 標準モニターは、あらかじめ定義されている特定のポイントカットおよび診断ロケーションで、あらかじめ定義されている特定の診断アクションを実行します。標準モニターでは、これらのアクション、ポイントカット、診断ロケーションはハード・コード化されています。モニターを有効または無効にできますが、モニターの動作は変更できません。
標準モニターはDyeInjectionモニターのみです。このモニターはサーバー・スコープ・モニターであり、サーバー・レベルで診断コンテキストを作成して仕分けの注入を構成するために使用します。第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

標準のアプリケーション・スコープ・モニターはHttpSessionDebugのみです。このモニターは、HTTP Sessionオブジェクトを検査するために使用します。

- 委任モニターでは、スコープ、ポイントカットおよびロケーションがハード・コード化されていますが、モニターで実行するアクションは、ユーザーが選択します。つまり、このモニターでは、あらかじめ定義されているアクションにかわって、ユーザーが選択したアクションが実行されます。委任モニターは、サーバー・スコープかアプリケーション・スコープのどちらかです。
委任モニターは、それ自体では完成していません。委任モニターが意味のある処理を行うには、少なくとも1つのアクションをモニターに割り当てる必要があります。

すべてのアクションがどのモニターにも割当て可能なわけではありません。管理コンソールで委任モニターを構成する場合、選択したモニターで対応可能なアクションのみを指定できます。WLSTを使用するか記述子ファイルを手動で編集して委任モニターを構成する場合、アクションはそのモニターに対応する必要があります。WLDFは、委任モニターのXML構成ファイルがデプロイ時にロードされるときにその委任モニターを検証します。

WLDFインストゥルメンテーション・ライブラリで利用可能な委任モニターとアクションについては付録B「WLDFインストゥルメンテーション・ライブラリ」を参照してください。

- カスタム・モニターは、次の特徴を持つ特殊な委任モニターです。

- アプリケーション・スコープ・インストゥルメンテーションにのみ利用できます。

- あらかじめ定義されたポイントカットやロケーションがありません。

カスタム・モニターを構成するには、カスタム・モニターに名前を付け、モニターで使用するポイントカットと診断ロケーションを定義し、あらかじめ定義されている診断アクションのセットからアクションを割り当てます。<pointcut>要素と<location type>要素はカスタム・モニターでは必須です。

表11-1に、各種類のモニターの違いを簡単に示します。

表11-1 診断監視のタイプ

モニター・タイプ

スコープ

ポイントカット

場所

アクション

標準モニター

サーバー

固定

固定

固定

委任モニター

サーバーまたはアプリケーション

固定

固定

構成可能

カスタム・モニター

アプリケーション

構成可能

構成可能

構成可能

モニターに対して「仕分けマスク」を設定すると、診断アクションがトリガーされるタイミングを制限できます。このマスクによって、診断コンテキストのどの仕分けフラグがアクションをトリガーするかが決まります。モニターの仕分けマスクの設定については、「<wldf-instrumentation-monitor> XML要素」を参照してください。

注意:
診断コンテキスト、仕分けの注入、および仕分けフィルタについては、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」で説明します。

診断アクション

診断アクションは、関連する委任モニターまたはカスタム・モニターに対応する診断コードを実行します(標準モニターの場合、アクションはあらかじめ定義されています)。委任モニターまたはカスタム・モニターがなんらかの意味のある処理を行うには、モニターに対して少なくとも1つのアクションを構成する必要があります。

WLDF診断ライブラリでは、以下のアクションを利用できます。アクションをモニターにアタッチするには、DIAG_MODULE.xml構成ファイルの<action>要素でアクション名を指定します。

- DisplayArgumentsAction

- MethodInvocationStatisticsAction

- MethodMemoryAllocationStatisticsAction

- StackDumpAction

- ThreadDumpAction

- TraceAction

- TraceElapsedTimeAction

- TraceMemoryAllocationAction

アクションは、モニターに正しく対応している必要があります。たとえば、TraceElapsedTimeアクションは、診断ロケーションの種類がAroundのカスタム・モニター、または委任モニターで使用できます。詳細は、付録B「WLDFインストゥルメンテーション・ライブラリ」を参照してください。

インストゥルメンテーション構成ファイル

インストゥルメンテーションは、診断記述子の一部としてXML構成ファイルで構成されます。このファイルの名前と格納場所は、システム・レベル(サーバー・スコープ)のインストゥルメンテーションを実装しているか、アプリケーション・レベル(アプリケーション・スコープ)のインストゥルメンテーションを実装しているかによって異なります。

- システム・レベルのインストゥルメンテーション構成は、次のディレクトリの1つ以上の診断記述子に格納されます。

DOMAIN_NAME/config/diagnostics

このディレクトリには、複数のシステム・レベルの診断記述子ファイルを格納できます。ファイル名は任意ですが、myDiag.xmlのように.xmlで終わる必要があります。各ファイルには、次のうち、1つまたは複数のデプロイ可能な診断コンポーネントの構成情報を格納できます。

- ハーベスタ

- インストゥルメンテーション

- 監視および通知

1つ以上の診断モニターの構成は、記述子ファイルの <instrumentation>セクションに定義できます。サーバー・スコープのインストゥルメンテーションは、サーバーを再起動しなくても有効化および無効化でき、再構成も可能です。

サーバー(またはクラスタ)では、いつでも1つのWLDFシステム・リソース(つまり、1つのシステム・レベルの診断記述子ファイル)のみをアクティブにできます。アクティブな記述子は、次の構成ファイルからリンクおよびターゲット指定されます。

DOMAIN_NAME/config/config.xml

診断システム・モジュールの構成の詳細は、「診断システム・モジュールの構成」を参照してください。WebLogic Serverの構成ファイルの作成、コンテンツおよび解析の一般情報については、『Oracle WebLogic Serverドメイン構成の理解』を参照してください。

- アプリケーション・レベルのインストゥルメンテーション構成は、以下の場所にあるアプリケーションのアーカイブ内にパッケージ化されます。

META-INF/weblogic-diagnostics.xml

アプリケーションにデプロイ可能な診断コンポーネントはインストゥルメンテーションだけです。したがって、この記述子には、インストゥルメンテーションの構成情報のみを格納できます。

注意:
インストゥルメンテーションをアプリケーションで使用できるようにするには、アプリケーションがデプロイされるサーバーでインストゥルメンテーションを有効にする必要があります。(サーバー・スコープ・インストゥルメンテーションは、サーバーの診断記述子の<instrumentation>要素で有効にしたり無効にしたりできます)。

アプリケーションを再デプロイせずに診断モニターを有効にしたり無効にしたりできます。ただし、ポイントカットの定義やモニターの追加または削除など、他のインストゥルメンテーション機能を変更した後には、アプリケーションを再デプロイする必要があります。再デプロイする必要があるかどうかは、インストゥルメンテーションの構成方法とアプリケーションのデプロイ方法によって異なります。3つの選択肢があります。

- JSR-88デプロイメント・プランを使用しないで、アプリケーションのインストゥルメンテーション構成を直接定義および変更します。

- インストゥルメンテーション設定のプレースホルダーを含むデプロイメント・プランを使用して、アプリケーションを構成およびデプロイします。

- サーバーの起動時にホットスワップ機能を有効にし、インストゥルメンテーション設定のプレースホルダーを含むデプロイメント・プランを使用してデプロイします。

これらの選択肢の詳細は、「インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用」を参照してください。

診断アプリケーション・モジュールのデプロイと変更の詳細は、第14章「WLDFアプリケーション・モジュールのデプロイメント」を参照してください。

診断XMLスキーマは以下の場所にあります。

http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd

各診断記述子ファイルは、以下の行で始まる必要があります。

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

WLDFリソースの構成の概要は、第4章「WLDFの構成について」を参照してください。

インストゥルメンテーションに使用するXML要素

この項では、記述子のコード・フラグメント、インストゥルメンテーションの構成に使用するXML要素をまとめた表、および診断モニターについて簡単に説明した表を示します。

- 「<Instrumentation> XML要素」では、<instrumentation>要素内で使用する最上位の各要素について説明します。

- 「<wldf-instrumentation-monitor> XML要素」では、<wldf-instrumentation-monitor>要素内で使用する各要素について説明します。

- 「各モニター・タイプへの<wldf-instrumentation-monitor>のXML要素のマッピング」では、どのインストゥルメンテーション要素をどのモニターに適用するかについて説明します。

<instrumentation> XML要素

表11-2では、DIAG_MODULE.xmlファイルの<instrumentation>要素について説明します。次の構成フラグメントでは、この要素の使用方法を示します。

<wldf-resource>
<name>MyDiagnosticModule</name>
<instrumentation>
<enabled>true</enabled>
<!-- The following <include> element would apply only to an
application-scoped Instrumentation descriptor -->
<include>foo.bar.com.*</include>
<!-- &lt;wldf-instrumentation-monitor&gt; elements to define diagnostic
monitors for this diagnostic module -->
</instrumentation>
<!-- Other elements to configure this diagnostic module -->
</wldf-resource>

表11-2 DIAG_MODULE.xml構成ファイル内の<instrumentation> XML要素

XML要素" width="100%">

要素

説明

<instrumentation>

インストゥルメンテーション構成を開始する要素。

<enabled>

trueの場合、インストゥルメンテーションは有効です。falseの場合、インストゥルメントされたコードは、このインストゥルメンテーション・スコープのクラスに挿入されておらず、このスコープ内のすべての診断モニターは無効です。デフォルト値はfalseです。

サーバーとそこにデプロイされているアプリケーションに対するインストゥルメンテーションを有効にするには、サーバー・レベルでインストゥルメンテーションを有効にする必要があります。さらに、(サーバー・スコープのインストゥルメンテーションの有効化に加えて)アプリケーションに対するインストゥルメンテーションを有効にするには、アプリケーション・レベルでインストゥルメンテーションを有効にする必要があります。

<include>

インストゥルメントされたコードを挿入できるクラスのリストを指定する要素(オプション)。ワイルドカード(*)がサポートされています。複数の<include>要素を指定できます。指定した場合、インストゥルメンテーションの対象となるには、クラスは<include>パターンに一致する必要があります。

アプリケーション・スコープのインストゥルメンテーションの場合にのみ有効です。<include>または<exclude>パターンを指定すると、アプリケーション・スコープ全体に適用されます。

注意: 特定の診断モニターに対して<include>パターンおよび<exclude>パターンを指定することもできます。表11-1の<include>および<exclude>の項目を参照してください。

クラスがロードされると、インストゥルメンテーション・コードを挿入する前に、include/excludeのパターン・チェックに成功する必要があります。クラスがinclude/excludeのパターン・チェックに成功した場合でも、インストゥルメントされるかどうかは、構成記述子で定義されている診断モニターによって決まります。ライブラリ内にあるアプリケーション・スコープの委任モニターには、あらかじめ定義されている独自のクラスおよびポイントカットがあります。カスタム・モニターでは、独自のポイントカット式を指定します。そのため、include/excludeのパターン・チェックに成功しても、クラスはインストゥルメントされない場合があります。

注意:インストゥルメンテーションは、クラスのロード時にアプリケーションに挿入されます。サイズの大きなアプリケーションを頻繁にロードする環境では、<include>または<exclude>要素をうまく使用すれば、利便性の向上を期待できます。小さなアプリケーションや、中規模または大規模のアプリケーションでも頻繁にロードしない場合は、この要素を無視してもかまいません。

<exclude>

インストゥルメントされたコードを挿入できないクラスのリストを指定する要素(オプション)。ワイルドカード(*)がサポートされています。複数の<exclude>要素を指定できます。指定した場合、<exclude>パターンに一致するクラスはインストゥルメントされません。

アプリケーション・スコープのインストゥルメンテーションの場合にのみ有効です。<include>要素の前述の説明を参照してください。

<wldf-instrumentation-monitor> XML要素

診断モニターは、次の記述子の<instrumentation>要素の子である<wldf-instrumentation-monitor>要素で定義されます。

- サーバー・スコープ・インストゥルメンテーションの場合はDIAG_MODULE.xml記述子

- アプリケーション・スコープ・インストゥルメンテーションの場合はMETA-INF/weblogic-diagnostics.xml記述子

次のフラグメントは、アプリケーションの委任モニターおよびカスタム・モニターの構成を示しています。(サーバー・スコープのインストゥルメンテーションの場合は、アプリケーション・スコープのモニターをサーバー・スコープのモニターに置き換えれば、このフラグメントを変更できます)。

<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モニターの構成は、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

表11-3は、<wldf-instrumentation-monitor>要素について説明します。

表11-3 DIAG_MODULE.xmlまたはweblogic-diagnostics.xmlファイル内の<wldf-instrumentation-monitor> XML要素

XML要素" width="100%">

要素

説明

<wldf-instrumentation-monitor>

診断モニターの構成を開始する要素。

<enabled>

trueの場合、モニターは有効です。falseの場合、モニターは無効です。各モニターを個別に有効または無効にできます。デフォルト値はtrueです。

<name>

モニターの名前。標準モニターと代理モニターの場合は、付録B「WLDFインストゥルメンテーション・ライブラリ」であらかじめ定義されているモニターの名前を使用します。カスタム・モニターの場合は、モニターを識別する任意の文字列です。カスタム・モニターの名前は一意でなければなりません。つまり、ライブラリ内の他のモニターと名前が重複することはできません。

<description>

モニターを説明する要素(オプション)。

<action>

委任モニターとカスタム・モニターに適用される要素(オプション)。少なくともアクションを1つは指定しないと、モニターは情報を生成しません。複数の<action>要素を指定できます。アクションは、モニターのタイプに対応している必要があります。委任モニターとカスタム・モニター用にあらかじめ定義されているアクションのリストは、付録B「WLDFインストゥルメンテーション・ライブラリ」を参照してください。

<dye-filtering-enabled>

省略可能な要素。trueの場合、そのモニターで仕分けフィルタが有効になります。falseの場合、仕分けフィルタは無効です。デフォルト値はfalseです。

仕分けフィルタを使用するには、DyeInjectionモニターをサーバー・レベルで適切に構成する必要があります。

<dye-mask>

省略可能な要素。仕分けフィルタが有効になっている場合、仕分けマスクは、診断コンテキスト内の値と比較して、アクションを起こすかどうかを決定します。仕分けおよび仕分けフィルタの詳細は、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

<properties>

省略可能な要素。仕分けフラグ用にname=valueのペアを設定します。

現在はDyeInjectionモニターにのみ適用されます。

<location-type>

before、after、aroundのいずれかの値を持つ要素(オプション)。この要素によって、ポイントカットを基準にアクションがトリガーされるタイミング(ポイントカットの前でトリガーされるか、ポイントカットの後でトリガーされるか、ポイントカットの前後でトリガーされるか)が決まります。

カスタム・モニターの場合にのみ有効。標準モニターおよび代理モニターでは、この値はあらかじめ定義されています。カスタム・モニターでは、診断ロケーションの種類とポイントカットを定義する必要があります。

<pointcut>

省略可能な要素。ポイントカット要素には、診断コードが挿入されるジョインポイントを定義する式が格納されます。

カスタム・モニターの場合にのみ有効です。標準モニターおよび委任モニターでは、この値はあらかじめ定義されています。カスタム・モニターでは、診断ロケーションの種類とポイントカットを定義する必要があります。

ポイントカットの構文については、「カスタム・モニターのポイントカットの定義」を参照してください。

<include>

インストゥルメントされたコードを挿入できるクラスのリストを指定する要素(オプション)。ワイルドカード(*)がサポートされています。複数の<include>要素を指定できます。指定した場合、インストゥルメンテーションの対象となるには、クラスは<include>パターンに一致する必要があります。

アプリケーション・スコープのインストゥルメンテーションの場合にのみ有効です。<include>または<exclude>パターンを指定すると、親<wldf-instrumentation-monitor>要素で定義されるモニターにのみ適用されます。

注意:インストゥルメントされたアプリケーション・スコープ全体に対して<include>パターンおよび<exclude>パターンを指定することもできます。表11-1の<include>および<exclude>の項目を参照してください。

クラスがロードされると、インストゥルメンテーション・コードを挿入する前に、include/excludeのパターン・チェックに成功する必要があります。クラスがinclude/excludeのパターン・チェックに成功した場合でも、インストゥルメントされるかどうかは、構成記述子で定義されている診断モニターによって決まります。ライブラリ内にあるアプリケーション・スコープの委任モニターには、あらかじめ定義されている独自のクラスおよびポイントカットがあります。カスタム・モニターでは、独自のポイントカット式を指定します。そのため、include/excludeのパターン・チェックに成功しても、クラスはインストゥルメントされない場合があります。

注意:インストゥルメンテーションは、クラスのロード時にアプリケーションに挿入されます。サイズの大きなアプリケーションを頻繁にロードする環境では、<include>または<exclude>要素をうまく使えば、利便性の向上を期待できます。小さなアプリケーションや、中規模または大規模のアプリケーションでも頻繁にロードしない場合は、この要素を無視してもかまいません。

<exclude>

インストゥルメントされたコードを挿入できないクラスのリストを指定する要素(オプション)。ワイルドカード(*)がサポートされています。複数の<exclude>要素を指定できます。指定した場合、<exclude>パターンに一致するクラスはインストゥルメントされません。

アプリケーション・スコープのインストゥルメンテーションの診断モニターにのみ有効です。上記の<include>の説明を参照してください。

<dye-filtering-enabled>と<dye-mask>の各要素については、さらに次の情報があります。

- DyeInjectionモニターが有効になっており、サーバーまたはクラスタ用に構成されている場合、下流にある委任モニターおよびカスタム・モニターに対して仕分けフィルタを使用し、リクエストの診断コンテキストに対してそのDyeInjectionモニターが実行した仕分けを検査できます。

- DyeInjectionモニターの構成によって、診断コンテキストに関連付けられた64ビット仕分けベクトルでどのビットが設定されるかが決まります。<dye-filtering-enabled>属性がモニターに対して有効になっていても、リクエストの診断コンテキストの仕分けベクトルが、モニターで構成された仕分けマスクと一致していない場合、診断アクティビティは実行されません。仕分けベクトルが仕分けマスクと一致している場合(ビット単位のANDの場合)、アプリケーションは診断アクションを実行できます。

(dye_vector & dye_mask == dye_mask)

このうようにして、仕分けフィルタのメカニズムを使用すると、モニターは特定のリクエストに対してのみ診断アクションを実行でき、それによって他のリクエストの処理が遅くなることはありません。診断コンテキストおよび仕分けベクトルの詳細は、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。

モニター・タイプへの<wldf-instrumentation-monitor>XML要素のマッピング

表11-4に、各モニター・タイプに適用する<wldf-instrumentation-monitor>要素を示します。Xの場合、要素は対応するモニターに適用され、N/Aの場合は適用されません。

表11-4 モニター・タイプへのインストゥルメンテーションXML要素のマッピング

要素

標準

委任

カスタム

<wldf-instrumentation-monitor>

X

X

X

<name>

X

X

X

<description>

X

X

X

<enabled>

X

X

X

<action>

N/A

X

X

<dye-filtering-enabled>

N/A

X

X

<dye-mask>

N/A

X

X

<properties>

X脚注 1

N/A

N/A

<location-type>

N/A

N/A

X

<pointcut>

N/A

N/A

X

脚注 1 現在は、DyeInjectionモニターで、仕分けフラグにname=valueペアを設定する場合にのみ使用されます。

サーバー・スコープのインストゥルメンテーションの構成

サーバー・レベルでインストゥルメンテーションを有効にし、サーバー・スコープのモニターを構成するには、以下の手順を実行します。

1. 作成するWLDFシステム・リソースの数を決定します。
ドメイン内に複数のDIAG_MODULE.xml診断記述子ファイルを持つことができます。ただし、ドメイン内のサーバーまたはクラスタごとにデプロイできるのは、常に1つの診断記述子ファイルのみになります。複数のファイルを作成する理由は、柔軟性です。たとえば、DOMAIN_NAME/config/diagnosticsディレクトリに5つの診断記述子ファイルを保存できます。ファイルごとに異なるインストゥルメンテーション(に加え、おそらくハーベスタおよび監視および通知)の構成を格納できます。アクティブにする特定のモニターに対応する記述子ファイルをデプロイします。

2. どのサーバー・スコープ・モニターを構成に含めるかを決めます。

- サーバーまたはそのサーバーにデプロイされているものに対して仕分けフィルタを使用する場合は、DyeInjectionモニターを構成します。

- 1つまたは複数のサーバー・スコープ委任モニターを使用する場合は、どのモニターを使用し、各モニターにどのアクションを関連付けるかを決めます。

3. 構成ファイル(複数可)を作成して構成します。

- 管理コンソールを使用して委任モニター用のDIAG_MODULE.xmlファイルを作成する場合(推奨手順)、コンソールには、そのモニターに対応するアクションのみが表示されます。エディタまたはWebLogic Scripting Tool (WLST)で構成ファイルを作成する場合は、アクションとモニターを正しく関連付ける必要があります。

- 詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。

4. デプロイメント記述子ファイルを検証してデプロイします。サーバー・スコープのインストゥルメンテーションの場合は、サーバーの実行中にモニターを追加および削除したり、モニターを有効または無効にしたりできます。

例11-1に、サーバー・スコープ・インストゥルメンテーションの構成ファイルのサンプルを示します。このサンプルでは、インストゥルメンテーションを有効にし、DyeInjection標準モニターおよびConnector_Before_Work委任モニターを構成します。1つの<instrumentation>要素に、モジュールのすべてのインストゥルメンテーションの構成が格納されます。各診断モニターは、個別の<wldf-instrumentation-monitor>要素で定義されます。

例11-1 サーバー・スコープのインストゥルメンテーションのサンプル(DIAG_MODULE.xml内)

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-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のみです。アプリケーション・スコープの標準モニターはHttpSessionDebugのみです。詳細は、「診断モニター・ライブラリ」のHttpSessionDebugの項目を参照してください。

- 委任モニターは、サーバー・スコープかアプリケーション・スコープのどちらかです。アプリケーションは、アプリケーション・スコープの委任モニターを使用する必要があります。

- カスタム・モニターはすべてアプリケーション・スコープです。

- サーバーのインストゥルメンテーション設定は、アプリケーションに影響します。インストゥルメンテーションをアプリケーションに対して有効にするには、アプリケーションがデプロイされるサーバーでインストゥルメンテーションを有効にする必要があります。デプロイメント時にサーバーのインストゥルメンテーションが有効である場合、アプリケーションでインストゥルメンテーションを利用できます。デプロイメント時にサーバーでインストゥルメンテーションが有効になっていない場合、アプリケーションでインストゥルメンテーションを有効にしても無視されます。

- アプリケーションのインストゥルメンテーションが、weblogic-diagnostics.xml記述子で構成する必要があります。ユーザーはMETA-INF/weblogic-diagnostics.xmlファイルを作成し、インストゥルメンテーションを構成して、アプリケーションのアーカイブにファイルを格納します。アーカイブがデプロイされると、インストゥルメンテーションは、アプリケーションがロードされたときに自動的に挿入されます。

- 「デプロイメント・プラン」を使用すると、アプリケーションを再デプロイしなくても、構成要素を動的に更新できます。「インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用」を参照してください。

アプリケーション・スコープ・インストゥルメンテーションのXML記述子は、サーバー・スコープ・インストゥルメンテーションの場合と同じ方法で定義されます。WLDFインストゥルメンテーション・ライブラリで使用可能な委任モニターと診断アクションを使用すると、アプリケーション専用のインストゥルメンテーションを構成できます。また、ユーザー独自のカスタム・モニターも作成できますが、カスタム・モニターにアタッチする診断アクションは、WLDFインストゥルメンテーション・ライブラリから指定する必要があります。

表11-5では、システム・モジュールとアプリケーション・モジュールの機能とスコープを比較します。

表11-5 システム・モジュールとアプリケーション・モジュールの比較

モジュールの種類

オブジェクトの動的な追加または削除

コンソールでのオブジェクトの追加または削除

JMXでのリモート変更

JSR-88での変更(非リモート)

コンソールでの変更

仕分けフィルタと仕分けマスクの動的な有効化または無効化

システム・モジュール

はい

はい

はい

いいえ

はい

(JMXから)

はい

アプリケーション・モジュール

可(ホットスワップが有効な場合)

不可(ホットスワップが有効でない場合: モジュールを再デプロイする必要があります)

はい

いいえ

はい

はい

(プランから)

はい

アプリケーションのインストゥルメントに必要な手順の概要

注意:
WLS10.3では、前のWLSリリースにおけるケースのように、アプリケーションのMETA-INFディレクトリのweblogic-diagnostics.xmlファイルを作成する必要はありません。ただし、この方法でアプリケーションの診断モニターを最初に構成することもできます。

アプリケーションの診断モニターを実装するには、以下の手順を実行します。

1. サーバーでインストゥルメンテーションが有効になっていることを確認します。「サーバー・スコープのインストゥルメンテーションの構成」を参照してください。

2. 適切な形式のMETA-INF/weblogic-diagnostics.xml記述子ファイルをアプリケーション用に作成します。アプリケーションがデプロイされるたびに自動的に有効化されるモニターを追加する場合、以下のようにします。

- <instrumentation>要素を有効(<enabled>true</enabled>)にします。

- 対応可能なアクションがアタッチされた診断モニターを少なくとも1つ追加して有効にします(モニターが有効になっており、イベントを生成するアクションがそのモニターにアタッチされている場合にのみ、モニターは診断イベントを生成します)。

各モニターのタイプ用に整形された記述子ファイルのサンプルについては、「委任モニターの記述子ファイルの作成」および「カスタム・モニターの記述子ファイルの作成」を参照してください。

ポイントカット式の作成については、「カスタム・モニターのポイントカットの定義」を参照してください。

3. アプリケーション・アーカイブに記述子ファイルを格納します。

4. アプリケーションをデプロイします。第14章「WLDFアプリケーション・モジュールのデプロイメント」を参照してください。

以下の点に注意します。

- weblogic-diagnostics.xmlで定義された診断モニターは、管理コンソールの「デプロイメント」>「<サーバー名>」>「構成」>「インストゥルメンテーション」ページに表示されます。

- アプリケーション・アーカイブのMETA-INF/weblogic-diagnostics.xml記述子がモニターを定義する場合、管理コンソールを使用することでそれを取り除くことができません。ただし、無効化や有効化は管理コンソールでも可能です。

- 管理コンソールから別のモニターを追加できます。管理コンソールから追加したすべてのモニターは、weblogic-diagnostics.xmlには保持されず、アプリケーションのデプロイメント計画に保存されます。この方法で追加したモニターは、管理コンソールで削除できます。

委任モニターの記述子ファイルの作成

次に、アプリケーション・スコープの代理モニター用に整形されたMETA-INF/weblogic-diagnostics.xml記述子ファイルの例を示します。このファイルには少なくとも太字で示す行を含める必要があります。この例では、モニターが1つのみ定義されています(Servlet_Before_Service)。ただし、記述子ファイルに複数のモニターを定義できます。

<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-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モニター構成に従って、リクエストがサーバーに入る時点で、DyeInjectionモニターを介してシステム・レベルで設定されます。たとえば、DyeInjectionモニターがUSER1=weblogicプロパティで構成され、リクエストがユーザーweblogicによって溯源された場合、仕分けベクトルにおけるUSER1仕分けフラグが設定されます。

したがって、このアプリケーションのServlet_Before_Serviceモニターは、仕分けベクトルを検査し、USER1フラグ・セットを見つけるまで、基本的に何も行いません。このフィルタ処理を実行すれば、生成される診断データの量を減らし、その時点で管理者にとって意味のあるデータのみを生成することができます。

カスタム・モニターの記述子ファイルの作成

次に、カスタム・モニターの整形式META-INF/weblogic-diagnostics.xmlファイルの例を示します。このファイルには少なくとも太字で示す行を含める必要があります。

例11-2 カスタム・モニターの構成のサンプル(DIAG_MODULE.xml内)

<?xml version="1.0" encoding="UTF-8"?>
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-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>は、開発者が指定した任意の文字列です。このモニターはカスタムなので、アクションの呼出し用にあらかじめ定義された診断ロケーションはありません。記述子ファイルでは、診断ロケーションの種類とポイントカット式を定義する必要があります。この例では、TraceActionアクションは、ポイントカット式で定義されたメソッドが呼び出される前(</location-type>の前の<location-type>)に呼び出されます。表11-1は、例11-2からポイントカット式が解析される仕組みを示します。(ワイルドカードの使用に注意してください。)

表11-6 ポイントカット式のサンプルの説明

ポイントカット式

説明

call( * com.foo.bar.* get* (...))

call( ):ジョインポイントがこのポイントカット式の残りで定義されているメソッドが呼び出されたときに、定義されたアクションをトリガーします。

call( * com.foo.bar.* get* (...))

*:戻り値。ワイルドカードは、メソッドの戻り値の型を問わないことを示します。

call( * com.foo.bar.* get* (...))

com.foo.bar.*: com.foo.barクラスとそのサブパッケージのメソッドが当てはまります。

call( * com.foo.bar.* get* (...))

get* : getという文字列で始まる任意のメソッドが当てはまります。

call( * com.foo.bar.* get* (...))

(...) :省略符号は、メソッドで指定できる引数の数に制限がないことを示します。

このポイントカット式は、パッケージcom.foo.barとそのサブパッケージ内にあるすべてのクラスのget*()メソッドに一致します。メソッドは、voidを含む任意の型の値を返すことができます。また、任意の型の引数を、数に制限なく持つことができます。インストゥルメンテーション・コードは、これらのメソッドの前に挿入され、そのメソッドが呼び出される直前に、TraceActionアクションが呼び出されます。

ポイントカットの定義に使用する文法の詳細は、「カスタム・モニターのポイントカットの定義」を参照してください。

カスタム・モニターのポイントカットの定義

カスタム・モニターでは、診断アクションの呼出し場所を指定するポイントカット式をユーザーが作成するので、委任モニターよりも柔軟な操作が可能です。委任モニターの場合は、アクション・ライブラリからアクションを選択する必要があります。

ジョインポイントは、精密に定義された、プログラム内の固有の位置です。ポイントカットは、ジョインポイントのセットを指定する式です。この項では、以下のポイントカット構文を使用して、ポイントカットの式を定義する方法について説明します。

カスタム・モニターでは2種類のポイントカットを指定できます。

- call :メソッドが呼び出されると、アクションを実行します。

- execution :メソッドが実行されると、アクションを実行します。

ポイントカット式を定義する構文は次のとおりです。

pointcutExpr  :=  orExpr  ( 'OR' orExpr ) *
orExpr := andExpr ( 'AND' andExpr ) *
andExpr := 'NOT' ? termExpr
termExpr := exec_pointcut | call_pointcut | '(' pointcutExpr ')'
exec_pointcut := 'execution' '(' modifiers?
returnSpec
classSpecWithAnnotations
methodSpec '(' parameterList ')'
')'
call_pointcut := 'call' '(' returnSpec
classSpec
methodSpec '(' parameterList ')'
')'
modifiers := modifier ( 'OR' modifier ) * modifier := 'public' | 'protected' | 'private' | 'static'
returnSpec :=  '*' | typeSpec
classSpecWithAnnotations := '@' IDENTIFIER ( 'OR' IDENTIFIER ) * | classSpec
classSpec := '+' ? classOrMethodPattern | '*'
typeSpec :=  '%' ? ( primitiveType | classSpec ) ( '[]' )*
methodSpec :=  classOrMethodPattern
parameterList := param ( ',' param ) *
param := typeSpec | '...'
primitiveType := 'byte' | 'char' | 'boolean' | 'short' | 'int' | 'float' | 'long' | 'double' | 'void'
classOrMethodPattern :=  '*' ? IDENTIFIER '*'? | '*'

以下のルールが適用されます。

- ワイルドカード文字(*)を、クラスの型やメソッド名に使用できます。

- 引数リストの省略符号(...)は、その引数以外に任意の型の引数がいくつか(数は可変)あることを示します。

- %(パーセント記号)接頭辞は、静的でないクラスのインスタンス化、パラメータまたは戻り値を指定する値が、機密情報を含まないまたは公開しないことを指定します。この演算子は、メソッド引数または戻り値を取得するDisplayArgumentsActionアクションで特に有効です。この接頭辞が明示的に使用されていない場合は、戻される値にアスタリスクが代入されます。この動作によって、インストゥルメンテーション・イベントがジョインポイントの入力引数を取得する場合またはジョインポイントから値を戻す場合に、アプリケーション内の機密データが誤って送信されないことをことを保証します。

注意:
%演算子は、ポイントカット式内の省略記号またはワイルドカードには適用できません。

- クラスの型に付けられた+ (プラス記号)接頭辞は、指定したクラス/インタフェース・パターンを実装しているすべてのサブクラス、サブインタフェース、または具象クラスを示します。

- ポイントカット式は、適合するジョインポイントを識別するパターンを指定します。パターンに対してジョインポイントを適合させると、有効な適合かどうかを示すブール型の値が返されます。

- ポイントカット式は、AND、OR、またはNOTブール演算子と組み合わせて、複雑なポイントカット式ツリーを構築できます。

たとえば、次のポイントカットは、パッケージcom.foo.barとそのサブパッケージ内のすべてのクラスのすべてのパブリックなinitializeメソッドのメソッド実行に一致します。initializeメソッドは、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>

アノテーション・ベースのポイントカット

実行ポイントのクラス指定子やメソッド指定子でJDKスタイルのアノテーションを使用することができます。アスタリスク(@)で始まるクラス指定子またはメソッド指定子はアノテーション名として解釈されます。

クラス指定子として使用したアノテーションは、@が付けられたすべてのクラスに一致します。照合の実行中には、アノテーション名のみが考慮されます。アノテーション属性は無視されます。

例:

execution(public void @Service @Invocation (...)

前述のポイントカットは次のメソッドと一致します。

- パブリック・メソッド

- voidを戻すメソッド

- @Serviceのアノテーションが付けられたクラスに含まれるメソッド

- @Invocationのアノテーションが付けられたメソッドを持つメソッド

- 任意の数の引数を持つメソッド

注意:
アノテーション・ベースの指定子は、実行ポイントカットでのみ使用できます。呼出しポポイントカットでは使用できません。

アノテーション・ベースのクラス指定子およびメソッド指定子では、次のワイルドカードを使用できます。

- * :あらゆるものに一致します。

- 先頭の* :指定した文字列で終わるクラス/インタフェースまたはメソッドの名前に一致します。たとえば、「*Bean」は、weblogic.management.configuration.ServerMBeanに一致します。

- 最後の* :指定した文字列で始まるクラス/インタフェースまたはメソッドの名前に一致します。たとえば、「weblogic.*」は、weblogicおよびそのサブパッケージ内のすべてのクラスおよびインタフェースに一致します。

- ポイントカットは、内部クラスの名前に基づいて指定できます。例:

public class Foo {
class Bar {
public int getValue() {...}
}
}

内部クラスBarのgetValueメソッドをカバーするポイントカットは、次の指定で定義できます。

execution (public int Foo$Bar getValue(...));

ワイルドカードを使うこともできます。例:

execution ( * Foo$Bar get*(...));

前述のポイントカットは、クラスFooの内部クラスBarのgetterメソッドとのみ一致します。

次のように先頭と末尾にワイルドカードを使用することもできます。例:

execution ( * Foo$Ba* get*(...));
execution ( * *oo$Bar get*(...));
execution ( * *oo$Ba* get*(...));

前述のポイントカットは、クラスFoo$Barのgetterメソッドとも一致します。

リクエスト・パフォーマンス・データの作成

サーバー・スコープまたはアプリケーション・スコープのインストゥルメントを構成している場合、リクエスト・パフォーマンス・データをWebLogic Server管理コンソールに表示できます。「リクエスト・パフォーマンス」ページには、Weblogic診断フレームワーク・インストゥルメンテーション機能で取得するメソッド・パフォーマンスのリアルタイムと履歴ビューの情報が表示されます。

リクエスト・パフォーマンス・データを作成するには、次の基準が満たされる必要があります。

- WLDFシステム・リソースを作成し、サーバーにターゲット指定する必要があります。「インストゥルメンテーション構成ファイル」に説明されているとおりに、システム・リソースを作成してください。これは、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して行います。

- ターゲットとなるWLDFシステム・リソースで、インストゥルメンテーションが有効になっている必要があります。

- アプリケーション・インストゥルメンテーションは、「インストゥルメンテーション構成ファイル」に説明されているとおりに、アプリケーションのMETA-INFディレクトリ内に作成するweblogic-diagnostics.xml記述子で有効にする必要があります。

- アプリケーション・インストゥルメンテーションの記述子では、Aroundタイプの診断モニターにアタッチされたTraceElapsedTimeAction診断アクションを使用する必要があります。たとえば、次のような記述が含まれる記述子を使用します。

<instrumentation>
<enabled>true</enabled>
<wldf-instrumentation-monitor>
<name>Connector_Around_Inbound</name>
<action>TraceElapsedTimeAction</action>
</wldf-instrumentation-monitor>
</instrumentation>

注意:
WebLogic Serverでは、デプロイ済アプリケーションのインストゥルメンテーションを変更をするために、weblogic-diagnostics.xml記述子がアプリケーションのアーカイブにプリバンドルされている必要はありません。

- アプリケーションでデプロイメント・プランを使用している場合、アプリケーションをデプロイする前にJavaホットスワップを有効にすると、アプリケーションを再デプロイせずに実行時にインストゥルメンテーションを変更できます。

- デプロイされたアプリケーションにデプロイメント計画がない場合、アプリケーションのインストゥルメンテーション構成を変更すると、管理コンソールは、自動的にデプロイメント計画を作成して、ユーザーに保存先を求めます。

- デプロイメント・プランでホットスワップが有効になっていない場合またはデプロイメント・プランを使用しない場合、いくつかのインストゥルメンテーション設定を再デプロイする必要があります。

詳細は、第14章「WLDFアプリケーション・モジュールのデプロイ」を参照してください。

Aroundタイプ・モニターのリストは、付録B「WLDFインストゥルメンテーション・ライブラリ」を参照してください。

Weblogic Server管理コンソールでのリクエスト・パフォーマンス・データの作成と分析の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのリクエスト・パフォーマンスの分析に関する項を参照してください。

12 診断コンテキストを管理するためのDyeInjectionモニターの構成

WLDFインストゥルメンテーション・コンポーネントは、リクエスト(HTTPリクエストまたはRMIリクエスト)を一意に識別し、それらのリクエストがシステムで処理される過程を追跡する手段を提供します。システムに参加するあらゆるリクエストの特定の特性(発信元のユーザー、クライアント・アドレスなど)を確認し、そのリクエストに診断コンテキストをアタッチするようにWLDFを構成できます。この構成によって、特定のリクエストの経過時間などを測定でき、すべてのリクエストがシステムを通過する際にどのように処理されているかを把握することができます。

診断コンテキストは、リクエストの特性を表す64ビットの仕分けベクトルと一意のコンテキストIDから構成されます。特定のリクエストに関連付けられたコンテキストIDはイベント・アーカイブに記録され、以下の処理に使用できます。

- インストゥルメンテーション・イベントの生成を抑制します。つまり、指定された条件に一致する場合のイベントの生成頻度を決定します。

- ログ・レコードをリクエストに関連付けます。

- WLDFアクセサ・コンポーネントを使用して、ログ・レコードやイベント・レコードの検索をフィルタ処理します(第13章「データ・アクセサを使用した診断データへのアクセス」を参照してください)。

次の項では、診断コンテキストの構成と使用のプロセスについて説明します。

- 診断コンテキストの内容、ライフサイクル、構成

- プロセスの概要

- DyeInjectionモニターを介した仕分けベクトルの構成

- 仕分けフィルタを使用するための委任モニターの構成

- 仕分けマスクによるモニターへ渡すリクエストのフィルタ方法

- インストゥルメンテーション・イベントの量を制御するスロットル機能の使用

診断コンテキストの内容、ライフサイクル、構成

診断コンテキストには、一意のコンテキストIDおよび64ビットの仕分けベクトルが含まれます。仕分けベクトルには、リクエストに関連した診断コンテキストの特性を識別するために設定されるフラグが含まれます。現在、仕分けベクトルの32ビットが使用可能な各仕分けフラグにつき1つずつ使用されています(表12-1を参照してください)。

コンテキストのライフ・サイクルとコンテキストID

リクエストの診断コンテキストはそのリクエストがシステムに参加したとき(たとえばクライアントで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アーカイブに追加されます。

診断モニターのタイプ、(ジョインポイントを定義する)ポイントカット、および診断アクションについては、第11章「インストゥルメンテーションの構成」を参照してください。

プロセスの概要

ここでは、サーバー・スコープの診断モジュールにおけるコンテキストの構成と使用について概説します。

1. DyeInjectionモジュールを介して仕分けベクトルを構成します。「DyeInjectionモニターを介した仕分けベクトルの構成」を参照してください。

2. システムにリクエストが入ると、そのリクエストの診断コンテキストがWLDFによって作成されインスタンス化されます。このコンテキストには、一意のコンテキストIDと仕分けベクトルが含まれます。

3. DyeInjectionモニターは、WLDF診断モジュール内でシステム・レベルで有効化されている場合、そのリクエストを調査して、仕分けベクトルで構成されている仕分け値のいずれかがリクエストの属性と一致しているかどうかを確認します。たとえば、そのリクエストの発行元がUSER1またはUSER2に関連付けられているユーザーかどうか、およびADDR1またはADDR2に関連付けられているIPアドレスかどうかが確認されます。

4. 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仕分けビットが設定されます。

5. リクエストがシステム内を移動する過程では、仕分けベクトルを持つ診断コンテキストもそのリクエストと共に移動します。この64ビットの仕分けベクトルの内容はフラグのみで、値は含まれません。そのため、この例では明示的に設定した2つのフラグUSER1とADDR2のみが仕分けベクトルに含まれます。これにはUSER1とADDR2に関する実際のユーザー名とIPアドレスは含まれていません。

注意:
すべての仕分けベクトルには、暗黙的なPROTOCOL仕分け群の1つも含まれます。これについては、「DyeInjectionモニターを介した仕分けベクトルの構成」で説明しています。

6. 管理者は下流のコード内で診断モニター(アプリケーション・スコープまたはサーバー・スコープの診断モニター)がアクティブとなるように構成し、モニターの仕分けマスクをUSER1およびADDR2と設定します。詳細は、「仕分けフィルタを使用するための委任モニターの構成」を参照してください。

7. 診断モニターは、診断コンテキストの仕分けベクトルで設定されている仕分けフラグが診断モニターの仕分けマスクと一致すると、関連付けられている1つまたは複数のアクションを実行します。詳細は、「仕分けマスクによるモニターへ渡すリクエストのフィルタ方法」を参照してください。この例では、USER1とADDR2フラグが仕分けベクトルに設定されていると、モニターはアクションを実行します。さらに、リクエストに関連するイベントがイベント・アーカイブに書き込まれます。

DyeInjectionモニターを介した仕分けベクトルの構成

システムに参加するすべてのリクエストに対して診断コンテキストを作成するには、次の手順に従います。

1. モニターする1つまたは複数のサーバー用に診断モジュールを作成して有効にします。

2. 診断モジュールのインストゥルメンテーションを有効にします。

3. モジュールのDyeInjectionモニターを構成して有効にします。(1つのモジュールで同時に使用できるDyeInjectionモニターは1つのみ。)

DyeInjectionモニターを構成するには、仕分けに値を割り当てます。使用できる仕分けフラグについては、表12-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に割り当てます。

管理コンソールでは、DyeInjectionの設定ページの「プロパティ」フィールドに値を入力して、仕分けに値を割り当てます。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュールでの診断監視の構成に関する項を参照してください。

図12-1 管理コンソールにおける仕分けの値の設定

「図12-1 管理コンソールにおける仕分けの値の設定」の説明

これらの設定は、診断モジュールの記述子ファイルでは以下の例に示すように表されます。

例12-1 DIAG_MODULE.xml内のDyeInjectionモニターの構成の例

<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>
<!-- Other elements to configure instrumentation -->
<instrumentation>
<!-- Other elements to configure this diagnostic monitor -->
<wldf-resource>

DyeInjectionモニターでサポートされる仕分け

仕分けベクトルで利用できる仕分けについて、以下の表にリストして説明します。

表12-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を使用して、コネクタ・ドライバの特性を識別します。

これらの仕分けフィルタは、コネクタ・ドライバによって状況に特有のリクエストのプロパティを識別するために設定されます。これらは、ユーザーが管理コンソールまたは記述子ファイルに直接構成するものではありません。これらの仕分けにはコネクタ・ドライバによって(コネクタAPIを使用して)値が割り当てられ、その結果、接続に関する情報が診断コンテキストに保持されて運ばれます。

COOKIE1

COOKIE2

COOKIE3

COOKIE4

COOKIE1、COOKIE2、COOKIE3、およびCOOKIE4は、HTTPまたはHTTPSリクエストにweblogic.diagnostics.dyeというCookieが含まれていて、その値が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)に指定されているユーザーによってリクエストが発信されると、それぞれに対応する仕分けフラグがそのリクエストの診断コンテキストに設定されます。

PROTOCOL仕分けフラグ

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仕分けフラグを使用して、仕分けを設定した受信リクエストの量を制御できます。THROTTLEは他のフラグとは異なる方法で構成され、WLDFでの使用方法も異なります。詳細は、「インストゥルメンテーション・イベントの量を制御するスロットル機能の使用方法」を参照してください。

診断コンテキストの作成条件

診断モジュールでDyeInjectionモニターが有効になっている場合、受信するすべてのリクエストについて診断コンテキストが作成されます。診断モジュールでインストゥルメンテーションを有効にするとき、DyeInjectionモニターはデフォルトで有効にされます。これにより診断コンテキストIDが利用でき、イベントが関連付けられます。DyeInjectionモニターに明示的に設定されているプロパティがない場合でも、一意のコンテキストIDと、暗黙的なPROTOCOL仕分け群のうち1つが指定された仕分けベクトルがすべてのリクエストのコンテキストに含まれます。

DyeInjectionモニターが診断モジュールに無効になっている場合、受信するどのリクエストについても診断コンテキストは作成されません。

仕分けフィルタ処理を使用するための委任モニターの構成

注意:
アプリケーション(Webアプリケーションなど)に診断モニターを実装する方法については、「アプリケーションのインストゥルメントに必要な手順の概要」を参照してください。

DyeInjectionモニターを、診断モジュールの委任診断モニターまたはカスタム診断モニターのトリガー条件を制限するメカニズムとして使用できます。このプロセスを仕分けフィルタ処理と呼びます。

それぞれのモニターに仕分けマスクを設定できます。仕分けマスクにはDyeInjectionモニターから選択された仕分けが指定されます。診断モニターに対して仕分けフィルタが有効になっている場合、マスクで設定された条件に一致するリクエストでのみ、モニターの診断アクションがトリガーされ、診断イベントが生成されます。

図 12-2に、構成されている診断アクションがトリガーされたときに、生成された診断イベントの例を示します。すべてのイベントのコンテキストIDが同じであることが分かります。これは、これらのイベントが同じリクエストに関連していることを示しています。このコンテキストIDを使用して、リクエストに関連付けられているログ・レコードを問い合わせることができます。リクエストに関連付けられているユーザーIDとDyeInjectionモニターで構成したUSER値は常に同じではありません。リクエストがシステムで処理される過程で、そのリクエストに関連付けられているユーザーが変わることによって、システムで特定の機能を実行することができます(たとえば、ユーザーIDがkernelに変わる場合があります)。

図12-2 リクエストに関連付けられた診断イベントの例

「図12-2 リクエストに関連した診断イベントの例」の説明

サンプル構成

TraceElapsedTimeActionアクションがアタッチされているServlet_Around_Serviceアプリケーション・スコープの診断モニターについて検討します。仕分けフィルタ処理が有効になっていない場合、Servlet_Around_Serviceで処理されるすべてのリクエストによってTraceElapsedTimeActionがトリガーされます。ただし、IPアドレス127.0.0.1のユーザーadmin@avitek.comからのリクエストに対してのみTraceElapsedTimeActionのトリガーとして仕分けフィルタを使用できます。

1. USER1=admin@avitek.comおよびADDR1=127.0.0.1となるようにDyeInjectionモニターを構成して、DyeInjectionモニターを有効にします。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの診断システム・モジュールでの診断監視の構成に関する項を参照してください。

2. 仕分けマスクを構成して、Servlet_Before_Service診断モニターの仕分けフィルタ処理を有効にします。管理コンソールで次の手順に従います。

1. Oracle WebLogic Server管理コンソール・ヘルプのアプリケーションのインストゥルメンテーションの構成に関する項の説明のとおり、WLDFインストゥルメンテーション・ライブラリからのServlet_Around_Service監視をアプリケーションに追加します。

2. モニターの追加後、「<アプリケーション名>の設定」ページで「保存」をクリックします。

3. 「Servlet_Around_Service」リンクをクリックし、「Servlet_Around_Serviceの設定」ページを表示します。

4. 「有効」チェック・ボックスを選択してモニターを有効にします。

5. 「アクション」下の「使用可能」リストから「選択済み」リストに「TraceElapsedTimeAction」を移動します。

6. 「仕分けマスク」セクションで、「USER1」および「ADDR1」を「使用可能」リストから「選択済」リストへ移動します。

7. 「仕分けフィルタを有効化」チェック・ボックスを選択します。

8. 「保存」をクリックします。

3. アプリケーションを再デプロイします。

管理コンソールで追加した構成は、アプリケーションのMETA-INFディレクトリの weblogic-diagnostics.xmlファイルやDIAG_MODULE.xmlファイルには保持されず、アプリケーションのデプロイメント・プランに保存されます。

DIAG_MODULE.xmlファイルを手作業で更新して診断モニターを追加することもできます(例12-2を参照してください)が、この方法はお薦めしません。構成は、実行サーバーの管理コンソールで変更することをお薦めします。DIAG_MODULE.xmlに対して行った変更は、アプリケーションを再デプロイするまで有効になりません。

例12-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>
<!-- Other elements to configure instrumentation -->
</instrumentation>
<!-- Other elements to configure this diagnostic monitor -->
<wldf-resource>

この構成では、IPアドレス127.0.0.1とユーザーadmin@avitek.comから発信されたリクエストでのみServlet_Around_Service診断モニターのTraceElapsedTimeActionアクションがトリガーされます。

診断モニターで有効となるフラグは、イベント・アーカイブに書きこむようにリクエストの仕分けベクトルで動作がトリガーされるように設定されたビットとイベントに正確に一致する必要があります。たとえば、診断モニターがUSER1とADDR1フラグの両方を有効にし、USER1フラグのみがリクエストの仕分けベクトルで設定されると、トリガーされる動作はなく、イベントも生成されません。

注意:
診断モニターを構成する際、同じタイプの複数のフラグを有効化しないでください。たとえば、USER1フラグとUSER2フラグの両方を有効化しないでください。これは、特定のリクエストの仕分けベクトルでUSER1フラグとUSER2フラグの両方が設定されない場合があるためです。

仕分けマスクによるモニターへ渡すリクエストのフィルタ方法

リクエストにアタッチされる仕分けベクトルには複数の仕分けを指定でき、委任モニターにアタッチされる仕分けマスクにも複数の仕分けを指定できます。委任モニターの仕分けマスクを使用して、モニターがリクエストに対してアクションを実行できるようにするには、以下の条件をすべて満たしている必要があります。

- アプリケーションのweblogic-diagnostics.xml記述子、または管理コンソールを使用して委任モニターまたはカスタム・モニターの仕分けフィルタ処理を有効にします。

- リクエストの仕分けベクトルに、モニターの仕分けマスクで定義されているすべての仕分けが含まれています。(仕分けベクトルには、仕分けマスクにない仕分けが含まれている可能性もあります。)

仕分けフィルタ処理の例

図12-3 では、3つの診断モニターを持つ診断モジュールを使用した仕分けフィルタ処理の仕組みを示しています。

- DyeInjectionモニターは次のように構成されています。

ADDR1=127.0.0.1
USER1=weblogic

- Servlet_Around_Serviceモニターには、ADDR1のみを含む仕分けマスクが構成されています。

- EJB_Around_SessionEjbBusinessMethodsモニターには、USER1のみを含む仕分けマスクが構成されています。

図12-3 仕分けフィルタ処理の例

「図12-3 仕分けフィルタ処理の例」の説明

1. IPアドレス127.0.0.1のユーザーguestによって開始されたリクエストがシステムに届きます。ユーザーguestはDyeInjectionモニターのUSER1の値に一致しないため、このリクエストは仕分けベクターUSER1で仕分けされません。発信元IPアドレス(127.0.0.1)はDyeInjectionモニターで定義されたADDR1の値に一致するため、リクエストは仕分けベクターADDR1で仕分けされます。

2. リクエスト(ADDR1で仕分け済み)がServletコンポーネントに届きます。このコンポーネントでは、診断モニターServlet_Around_Serviceがコード内に織り込まれています。(Servlet_Around_Serviceは特定のサーブレット・メソッドまたはJSPメソッドの入り口と出口で、診断アクションをトリガーします)。このモニターでは仕分けモニターが有効になっており、仕分けマスクにはADDR1という値が1つ定義されています。

3. Servlet_Around_Serviceでインストゥルメントされているメソッドにリクエストが入るか出るときに、診断モニターはリクエストに仕分けベクトルADDR1があるかどうかをチェックし、それが見つかります。その結果、モニターは診断アクションをトリガーします。イベント・アーカイブへのデータの書込みなどの診断イベントが発生します。

4. リクエストがSessionEJBコンポーネントに届きます。このコンポーネントでは、診断モニターEJB_Around_SessionEjbBusinessMethodsがコード内に織り込まれています。(EJB_Around_SessionEjbBusinessMethodsはすべてのSessionBeanメソッドの入り口と出口で診断アクションをトリガーします)。このモニターでは仕分けモニターが有効になっており、仕分けマスクにはUSER1という値が1つ定義されています。

5. SessionBeanメソッド(EJB_Around_SessionEjbBusinessMethodsでインストゥルメントされている)にリクエストが入るか出るときに、診断モニターはリクエストに仕分けベクトルUSER1があるかどうかをチェックしますが、見つかりません。したがって、モニターは診断アクションをトリガーしないので、診断イベントは発生しません。

インストゥルメンテーション・イベントの量を制御するスロットル機能の使用方法

スロットル機能を使用すると、診断モジュールのモニターで処理されるリクエストの数を制御できます。スロットル機能は、DyeInjectionモニターに定義されるTHROTTLE仕分けを使用して構成します。

注意:
USERnおよびADDR n仕分けを使用すると、特定のユーザーまたはIPアドレスからのリクエストを検査することができます。ただし、任意のユーザー・トランザクションを調べる手段にはなりません。THROTTLE仕分けでは、リクエストのサンプリングによりその機能を提供します。

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仕分けが構成されます。管理コンソールでのTHROTTLE構成の設定を、以下の図に示します。

図12-4 THROTTLE仕分けの構成

「図12-4 THROTTLE仕分けの構成」の説明

例12-3に、結果として診断モジュールの記述子ファイルに記述される構成を示します。

例12-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>
<!-- Other elements to configure this diagnostic monitor -->
</wldf-resource>

例12-4に、仕分けマスクにTHROTTLE仕分けが設定されているJDBC_Before_Start_Internal委任モニターの構成を示します。

例12-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>
<!-- Other elements to configure this diagnostic monitor -->
</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パッケージを使用すると、アプリケーションから診断コンテキストに制限付きでアクセスできます。

アプリケーションでは一連のweblogic.diagnostics.context.DiagnosticContextHelper APIを使用して、以下の関数を実行できます。

- 診断コンテキストの不変のコンテキストIDの検査。

- コンテキストの仕分けベクトルにある仕分けフラグの設定の検査。

- 有効な仕分けフラグ名の配列の取得。

- コンテキストの仕分けベクトルにあるDYE_0からDYE_7までのフラグについての設定または設定の解除。(これらのフラグ・ビットをXMLを介して設定する方法はありません。DyeInjectionモニターの<properties>を構成すると、アプリケーション固有でないフラグ・ビットについてXMLを介して設定できますが、仕分けベクトルのDYE_0からDYE_7までを設定できるのはsetDye()メソッドのみです)。

- 診断コンテキストへのペイロード(String型)のアタッチ、または既存のペイロードの読込み。

以下についてはアプリケーションでは処理できません。

- アプリケーション用に予約されている8フラグ以外の仕分けベクトルのフラグの設定。

- 仕分けベクトルの同じアプリケーション・フラグが別のアプリケーションで設定されることの回避。適切に動作するアプリケーションであれば、仕分けフラグを設定する前にあらかじめ設定されているかどうかをテストできます。

- 別のアプリケーションによるペイロードの置換えの回避。適切に動作するアプリケーションであれば、ペイロードを追加する前にペイロードが存在するかどうかをテストできます。

注意:
診断コンテキストのペイロードは、同一実行コンテキスト内の他のコードによって表示可能で、Workインスタンスと共にプロセスから流れ、同一実行コンテキスト内で実行されている他のコードによって上書き可能です。そのため、アプリケーションで次の動作を確認する必要があります。

- getPayload()メソッドによって返される可能性のあるような機密データをペイロードには含めないようにします。

- コンテキスト・ペイロードで使用可能な特定のデータに関する依存関係を作成しないでください。たとえば、アプリケーションは特定のコンテキストIDへ依存してはなりません。アプリケーションは、ペイロードのコンテンツを使用する場合、最初にそのコンテンツが期待通りのものか検証する必要があります。

アプリケーションでDYE_0からDYE_7までのフラグうち1つまたは複数を設定した時点以降には、モニターや別のアプリケーションでそれらのフラグをチェックするように仕分けマスクを設定し、そのフラグ(群)がコンテキストの仕分けベクトルに存在する場合にアクションを実行できます。診断コンテキストにペイロードがアタッチされている場合、モニターで実行されるアクションはペイロードに格納されてアーカイブ化され、結果としてアクセサ・コンポーネントを通じて利用できるようになります。

例12-5は、診断コンテキストを(黙示的に)作成し、コンテキストIDを出力して、DYE_0フラグの値をチェックした上で設定する簡単なサンプルです。

例12-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));
}
}

13 データ・アクセサを使用した診断データへのアクセス

WebLogic診断フレームワーク(WLDF)のデータ・アクセサ・コンポーネントを使用すると、ログ・レコード、データ・イベント、収集されたメトリックなどの様々なソースからの診断データにアクセスできます。

データ・アクセサを使用すると、型、コンポーネント、属性を基準としてデータをルックアップできます。時間ベースのフィルタ処理を実行でき、イベントにアクセスする際には重大度、ソース、コンテンツを基準としたフィルタ処理が可能です。また、表形式の診断データにアクセスすることもできます。

次の項では、データ・アクセサについて説明し、オンライン(サーバーが実行中の状態)およびオフライン(サーバーが実行中でない状態)でデータ・アクセサを使用する方法について示します。

- データ・アクセサのアクセス対象のデータ・ストア

- 診断データへのオンライン・アクセス

- 診断データへのオフライン・アクセス

- システム・クロックをリセットすることによるデータのアーカイブおよび取得に対する影響

データ・アクセサのアクセス対象のデータ・ストア

データ・アクセサでは、他のWLDFコンポーネントから診断情報を取得します。キャプチャされた情報は、診断データの種類別に分かれた複数の論理データ・ストア内に分類されます。たとえば、サーバー・ログ、HTTPログ、収集されたメトリックは、それぞれ別のデータ・ストアにキャプチャされます。

WLDFでは、診断データがサーバー単位で管理されます。そのため、データ・アクセサでは個々のサーバーのデータ・ストアにアクセスできます。

データ・ストアは表形式を取ることがあります。表の各レコードが1つの項目を表し、その項目の特性が複数の列で説明されます。様々なデータ・ストアに多様な列がありますが。データ項目が収集された時間などほとんどのデータ・ストアで共有される列もあります。

データ・アクセサでは、サーバーのWLDFで使用されるデータ・ストアについて以下のような情報を取得できます。

- サポートされるデータ・ストアのタイプのリスト。以下のようなものがあります。

- HTTP_LOG

- HARVESTED_DATA_ARCHIVE

- EVENTS_DATA_ARCHIVE

- SERVER_LOG

- DOMAIN_LOG

- HTTP_ACCESS_LOG

- WEBAPP_LOG

- CONNECTOR_LOG

- JMS_MESSAGE_LOG

- CUSTOM_LOG

- 利用可能なデータ・ストアのインスタンスのリスト。

- 各データ・ストアのレイアウト(データ・ストアの列が記述された情報)

WLDFAccessRuntimeMBeanを使用すると、このようなデータ・ストアを検索したり、データ・ストアにあるデータの性質を判断したりできます。また、問合せを使用してそうしたデータに選択的にアクセスすることもできます。

WebLogicログの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』を参照してください。

診断データへのオンライン・アクセス

実行中のサーバーの診断データには、管理コンソール、JMX API群、またはWebLogic Scripting Tool (WLST)を使用してアクセスします。

管理コンソールを使用してデータへのアクセス

管理コンソールでは、明示的にデータ・アクセサを使用することはありませんが、アクセサで収集された情報は管理コンソールに表示されます。たとえば、「ログ・ファイルの概要」ページなどがそれに該当します。Oracle WebLogic Server管理コンソール・ヘルプのログの表示と構成に関する項を参照してください。

ランタイムMBeanを使用してプログラム的にデータへのアクセス

データ・アクセサには、データ・ストアの検索とデータ・ストアからのデータ取得のために以下のランタイムMBeanが用意されています。

- 以下の処理にはWLDFAccessRuntimeMBeanを使用します。

- サーバー上の利用可能なデータ・ストアの論理名を取得します。

- 特定のデータ・ソースのデータにアクセスするために、論理名を基にWLDFDataAccessRuntimeMBeanをルックアップします。様々なデータ・ストアは、各自の論理名によって一意に識別されます。

Oracle WebLogic Server MBeanリファレンスのWLDFAccessRuntimeMBeanに関する項を参照してください。

- 検索条件または問合せに基づいてデータ・ストアを取得するには、WLDFDataAccessRuntimeMBeanを使用します。問合せには任意で時間間隔を指定して、特定の時間内にデータ・レコードを取得するようにできます。このMBeanには、データ・セットの複数の列、およびデータ・ストア内のレコード群の最古と最新のタイムスタンプに関するメタデータが備わっています。
現在、データ・アクセサのランタイムMBeanが作成されて登録されるまでには時間がかかります。そのため、リモート・クライアントがそれらにアクセスしようとすると、それらが存在せず、InstanceNotFoundExceptionがスローされることがあります。

クライアントは、WLDFAccessRuntimeのWLDFDataAccessRuntime属性を取得して、認識されているすべてのデータ・アクセス・ランタイムを作成するようにできます。例:

ObjectName objName =
new ObjectName("com.bea:ServerRuntime=" + serverName +
",Name=Accessor," +
"Type=WLDFAccessRuntime," +
"WLDFRuntime=WLDFRuntime");
rmbs.getAttribute(objName, "WLDFDataAccessRuntimes");

Oracle WebLogic Server MBeanリファレンスのWLDFDataAccessRuntimeMBeanに関する項を参照してください。

WLSTを使用してオンラインで診断データへのアクセス

WLSTのexportDiagnosticDataFromServerコマンドを使用すると、実行中のサーバーの診断データにアクセスできます。このコマンドの構文とサンプルは、『WebLogic Scripting Toolコマンド・リファレンス』の診断コマンドに関する項を参照してください。

データ・アクセサでWLDF問合せ言語の使用

データ・ストアのデータを問い合わせるには、WLDF問合せ言語を使用します。データ・アクセサの問合せ言語の構文の詳細は、付録A「WLDF問合せ言語」を参照してください。

診断データへのオフライン・アクセス

WLSTのexportDiagnosticDataコマンドを使用すると、オフライン状態にあるサーバーの診断データの履歴にアクセスできます。このコマンドの構文とサンプルは、『WebLogic Scripting Toolコマンド・リファレンス』の診断コマンドに関する項を参照してください。

注意:
データが固持されるマシンだけから格納されたデータにアクセスするのにexportDiagnosticDataを使用できます。
データ・アクセサのオフライン・モードでは、データ・ストア・インスタンスの検索はできません。インスタンスについてはあらかじめ認識しておく必要があります。

診断データへのプログラム的なアクセス

例13-1では、アクセサを使用して様々なアーカイブ・データ・ストアに問い合せるユーティリティのJavaソース・コードを示します。

例13-1 WLDFアクセサを使用するサンプル・コード

/*
* WLAccessor.java
*
* Demonstration utility that allows query of the different ARCV data stores
* via the WLDF Accessor.
*
*/

import javax.naming.Context;
import weblogic.jndi.Environment;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Properties;
import weblogic.management.ManagementException;
import weblogic.management.runtime.WLDFAccessRuntimeMBean;
import weblogic.management.runtime.WLDFDataAccessRuntimeMBean;
import weblogic.diagnostics.accessor.ColumnInfo;
import weblogic.diagnostics.accessor.DataRecord;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.management.ObjectName;
import weblogic.management.mbeanservers.runtime.RuntimeServiceMBean;
import weblogic.management.runtime.ServerRuntimeMBean;
import weblogic.management.jmx.MBeanServerInvocationHandler;
import weblogic.management.configuration.ServerMBean;

/**
* Demonstration utility that allows query of the different ARCV data stores
* via the WLDF Accessor. The class looks up the appropriate accessor and
* executes the query given the specified query parameters.
*
* To see information about it's usage, compile this file and run
*
*   java WLAccessor usage
*/
public class WLAccessor {

/** Creates a new instance of WLAccessor */
public WLAccessor(Properties p) {
initialize(p);
}

/**
* Retrieve the specfied WLDFDataAccessRuntimeMBean instance for querying.
*/
public WLDFDataAccessRuntimeMBean getAccessor(String accessorType)
throws Throwable
{
// Get the runtime MBeanServerConnection
MBeanServerConnection runtimeMBS = this.getRuntimeMBeanServerConnection();

// Lookup the runtime service for the connected server
ObjectName rtSvcObjName = new ObjectName(RuntimeServiceMBean.OBJECT_NAME);
RuntimeServiceMBean rtService = null;

rtService = (RuntimeServiceMBean)
MBeanServerInvocationHandler.newProxyInstance(
runtimeMBS, rtSvcObjName
);

// Walk the Runtime tree to the desired accessor instance.
ServerRuntimeMBean srt = rtService.getServerRuntime();

WLDFDataAccessRuntimeMBean ddar =
srt.getWLDFRuntime().getWLDFAccessRuntime().
lookupWLDFDataAccessRuntime(accessorType);

return ddar;
}

/**
* Execute the query using the given parameters, and display the formatted
* records.
*/
public void queryEventData() throws Throwable
{
String logicalName = "EventsDataArchive";
WLDFDataAccessRuntimeMBean accessor = getAccessor(accessorType);

ColumnInfo[] colinfo = accessor.getColumns();
inform("Query string: " + queryString);

int recordsFound = 0;
Iterator actualIt =
accessor.retrieveDataRecords(beginTime, endTime, queryString);
while (actualIt.hasNext()) {
DataRecord rec = (DataRecord)actualIt.next();
inform("Record[" + recordsFound + "]: {");
Object[] values = rec.getValues();
for (int colno=0; colno < values.length; colno++) {
inform("[" + colno + "]  "
+ colinfo[colno].getColumnName() +
" (" +  colinfo[colno].getColumnTypeName() + "):   " +
values[colno]);
}
inform("}");
inform("");
recordsFound++;
}
inform("Found " + recordsFound + " results");
}

/**
* Main method that implements the tool.
* @param args the command line arguments
*/
public static void main(String[] args) {
try {
WLAccessor acsr = new WLAccessor(handleArgs(args));
acsr.queryEventData();
} catch (UsageException uex) {
usage();
} catch (Throwable t) {
inform("Caught exception, " + t.getMessage(), t);
inform("");
usage();
}
}

public static class UsageException extends Exception {}

/**
* Process the command line arguments, which are provided as name/value pairs.
*/
public static Properties handleArgs(String[] args) throws Exception
{
Properties p = checkForDefaults();
for (int i = 0; i < args.length; i++) {
if (args[i].equalsIgnoreCase("usage"))
throw new UsageException();

String[] nvpair = new String[2];
int token = args[i].indexOf('=');
if (token < 0)
throw new Exception("Invalid argument, " + args[i]);
nvpair[0] = args[i].substring(0,token);
nvpair[1] = args[i].substring(token+1);
p.put(nvpair[0], nvpair[1]);
}
return p;
}

/**
* Look for a default properties file
*/
public static Properties checkForDefaults() throws IOException {
Properties defaults = new Properties();
try {
File defaultprops = new File("accessor-defaults.properties");
FileInputStream defaultsIS = new FileInputStream(defaultprops);
//inform("loading options from accessor-defaults.properties");
defaults.load(defaultsIS);
} catch (FileNotFoundException fnfex) {
//inform("No accessor-defaults.properties found");
}
return defaults;
}
public static void inform(String s) {
System.out.println(s);
}
public static void inform(String s, Throwable t) {
System.out.println(s);
t.printStackTrace();
}

private MBeanServerConnection getRuntimeMBeanServerConnection()
throws IOException
{
// construct jmx service url

// "service:jmx:[url]/jndi/[mbeanserver-jndi-name]"
JMXServiceURL serviceURL =
new JMXServiceURL(
"service:jmx:" + getServerUrl() +
"/jndi/" + RuntimeServiceMBean.MBEANSERVER_JNDI_NAME
);

// specify the user and pwd. Also specify weblogic provide package
inform("user name [" + username + "]");
inform("password [" + password + "]");
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL, username);
h.put(Context.SECURITY_CREDENTIALS, password);
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"weblogic.management.remote");
// get jmx connector
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, h);

inform("Using JMX Connector to connect to " + serviceURL);
return connector.getMBeanServerConnection();
}

private void initialize(Properties p) {
serverUrl = p.getProperty("url","t3://localhost:7001");
username = p.getProperty("user","weblogic");
password = p.getProperty("pass","weblogic");
queryString = p.getProperty("query","SEVERITY IN
('Error','Warning','Critical','Emergency')");
accessorType = p.getProperty("type","ServerLog");

try {
beginTime = Long.parseLong(p.getProperty("begin","0"));

String end = p.getProperty("end");
endTime = (end==null) ? Long.MAX_VALUE : Long.parseLong(end);
} catch (NumberFormatException nfex) {
throw new RuntimeException("Error formatting time bounds", nfex);
}
}

private static void usage() {
inform("");
inform("");
inform("Usage: ");
inform("");
inform("  java WLAccessor [options]");
inform("");
inform("where [options] can be any combination of the following: ");
inform("");
inform("    usage                   Prints this text and exits");
inform("    url=<url>               default: 't3://localhost:7001'");
inform("    user=<username>         default: 'weblogic'");
inform("    pass=<password>         default: 'weblogic'");
inform("    begin=<begin-timestamp> default: 0");
inform("    end=<end-timestamp>     default: Long.MAX_VALUE");
inform("    query=<query-string>    default: \"SEVERITY IN ('Error','Warning','Critical','Emergency')\"");
inform("    type=<accessor-type>    default: 'ServerLog'");
inform("");
inform("Example:");
inform("");
inform("    java WLAccessor user=system pass=gumby1234 url=http://myhost:8000 \\");
inform("       query=\"SEVERITY = 'Error'\" begin=1088011734496 type=ServerLog");
inform("");
inform("");
inform("");
inform("All properties (except \"usage\") can all be specified in a file ");
inform("in the current working directory. The file must be named: ");
inform("");
inform("           \"accessor-defaults.properties\"");
inform("");
inform("Each property specified in the defaults file can still be ");
inform("overridden on the command-line as shown above");
inform("");
}

/** Getter for property serverUrl.
* @return Value of property serverUrl.
*
*/
public java.lang.String getServerUrl() {
return serverUrl;
}

/** Setter for property serverUrl.
* @param serverUrl New value of property serverUrl.
*
*/
public void setServerUrl(java.lang.String serverUrl) {
this.serverUrl = serverUrl;
}

protected String serverName = null;
protected String username = null;
protected String password = null;
protected String queryString = "";
private String serverUrl = "t3://localhost:7001";
private String accessorType = null;

private long endTime = Long.MAX_VALUE;
private long beginTime = 0;

private WLDFAccessRuntimeMBean dar = null;

}

システム・クロックをリセットすることによるデータのアーカイブおよび取得に対する影響

診断データがWLDFアーカイブまたはログに書き込まれている間にシステム・クロックをより前の時間にリセットすると、タイムスタンプに基づいてデータを問い合わせる際に、予期しない結果が生じる可能性があります。たとえば、イベントのシーケンスが次のような場合を考えます。

1. 2:00 PMに、診断イベントがRECORD_200として、2:00:00 PMのタイムスタンプでアーカイブされます。

2. 2:30 PMに、診断イベントがRECORD_230として、2:30:00 PMのタイムスタンプでアーカイブされます。

3. 3:00 PMに、システム・クロックを2:00 PMにリセットします。

4. 2:15 PM(クロックのリセット後)に、診断イベントがRECORD_215として、2:15:00 PMのタイムスタンプでアーカイブされます。

5. 2:00 PMと2:20 PMの間に生成されたレコードを取得する問合せを発行します。

問合せは、2:30:00 PMのタイムスタンプを持つRECORD_230によって終了するため、RECORD_215を取得しません。

14 WLDFアプリケーション・モジュールのデプロイメント

アプリケーションで使用できるWebLogic診断フレームワーク(WLDF)コンポーネントはインストゥルメンテーションのみです。「アプリケーション・スコープのインストゥルメンテーションの構成」を参照してください

アプリケーションに対するインストゥルメンテーションは、アプリケーション・スコープのリソースである診断アプリケーション・モジュールとして構成および管理します。構成はアプリケーションと共にデプロイする記述子ファイル内に永続化されます。このようにデプロイされる診断モジュールは、同梱のアプリケーションでのみ使用可能です。アプリケーション・スコープのリソースを使用することにより、アプリケーションは常に、必要なリソースへ確実にアクセスでき、アプリケーションを新しい環境にデプロイする処理が簡素化されます。

デプロイメント・プランを使用してアプリケーションをデプロイできます。デプロイメント・プランを使用すると、構成の動的な更新が可能になります。

注意:
インストゥルメンテーションをアプリケーションで使用できるようにするには、アプリケーションがデプロイされるサーバーでインストゥルメンテーションを有効にする必要があります。(サーバー・スコープ・インストゥルメンテーションは、サーバーの診断記述子の<instrumentation>要素で有効にしたり無効にしたりできます)。

次の項では、WLDFアプリケーション・モジュールのデプロイ方法について説明します。

- 診断モジュールのアプリケーション・スコープ・リソースとしてのデプロイ

- インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用

- デプロイメント・プランの使用:概要

- weblogic.PlanGeneratorによるデプロイメント・プランの作成

- 診断用のデプロイメント・プランのサンプル

- Javaホットスワップ機能の有効化

- デプロイメント・プランによるアプリケーションのデプロイ

- 変更したプランによるアプリケーションの更新

診断モジュールのアプリケーション・スコープ・リソースとしてのデプロイ

診断モジュールをアプリケーション・スコープ・リソースとしてデプロイするには、weblogic-diagnostics.xmlという記述子ファイルでモジュールを構成します。次に、アプリケーション・アーカイブがデプロイ済みのアプリケーションのARCHIVE_PATH/META-INFディレクトリにある状態で、記述子ファイルをパッケージします。例:

D:\bea\wlserver_10.3\samples\server\medrec\dist\standalone\exploded\medrec\META-INF\weblogic-diagnostics.xml

診断モジュールは、展開形式でも、展開形式でないアーカイブでもデプロイできます。

注意:
META-INFディレクトリにweblogic-diagnostics.xml記述子があるWAR、RARまたはEJBモジュールがEARアーカイブに含まれている場合、その記述子は無視されます。

デプロイメント制御用に用意された任意の標準WebLogic Serverツールを使用できます。このようなツールには、管理コンソールやWebLogic Scripting Tool (WLST)などがあります。

モジュールの作成およびアプリケーションのデプロイの方法の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

診断アプリケーション・モジュールおよび診断システム・モジュールがデプロイされる方法には様々な方法があるため、再構成の方法や変更が行われる場合については、相違点があります。表14-2を参照してください。診断アプリケーション・モジュールの作業については、この項で説明します。診断システム・モジュールの作業の詳細は、第11章「インストゥルメンテーションの構成」を参照してください。

表14-1 システム・モジュールとアプリケーション・モジュールの比較

モニター・タイプ

オブジェクトの動的な追加/削除

コンソールでのオブジェクトの追加/削除

JMXでのリモート変更

JSR-88での変更(非リモート)

コンソールでの変更

システム・モジュール

はい

はい

はい

いいえ

可 - JMXから

アプリケーション・モジュール

可(Javaホットスワップ脚注 1 が有効な場合)

不可(ホットスワップが有効でない場合: モジュールを再デプロイする必要があります)

はい

いいえ

はい

可 - プランから

脚注 1 Javaホットスワップの詳細は、「インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用」を参照してください。

インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用

WebLogic Serverでは、Java EEデプロイメント仕様API(JSR-88)で指定されているように、デプロイメント・プランをサポートしています。デプロイメント・プランを使用すると、アプリケーションのビルド後に、そのアプリケーションのアーカイブに変更を加えることなく、構成を変更できます。WebLogic Serverにおけるデプロイメント・プランの使用の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番デプロイメントのためのアプリケーションの構成に関する項を参照してください。

デプロイメント・プランを使用せずにデプロイされたアプリケーションを再構成する場合は、アプリケーションをアンデプロイしてアーカイブを展開し、再構成して再びアーカイブしてから、再デプロイする必要があります。デプロイメント・プランを使用すると、アプリケーション・アーカイブを変更せずに、プランを更新するだけで、多くの構成オプションを動的に変更できます。

デプロイメント・プランを使用してアプリケーションをデプロイする前に、Javaホットスワップという機能を有効にしておくと(「Javaホットスワップ機能の有効化」を参照)、アプリケーションを再デプロイせずに、すべてのインストゥルメンテーション設定を動的に更新できます。ホットスワップを有効にしていない場合、または、デプロイメント・プランを使用しない場合、一部のインストゥルメンテーション設定の変更では、再デプロイメントが必要になります。表14-2を参照してください。

表14-2 アプリケーション・インストゥルメンテーションの構成の変更が有効になる場合

使用するシナリオ ・ 設定 =>

モニターの追加と削除

アクションのアタッチとデタッチ

モニターの有効化と無効化

デプロイメント・プランを使用してデプロイされるアプリケーション(ホットスワップが有効な場合)

動的

動的

動的

デプロイメント・プランを使用してデプロイされるアプリケーション(ホットスワップが有効ではない場合)

アプリケーションの再デプロイが必要脚注 1

動的

動的

デプロイメント・プランを使用せずにデプロイされるアプリケーション

アプリケーションの再デプロイが必要

アプリケーションの再デプロイが必要

アプリケーションの再デプロイが必要

脚注 1 ホットスワップが有効になっていない場合、モニターを削除できますが、そのモニターは無効になるのみです。インストゥルメンテーション・コードはアプリケーション・コードにウィービングされたままになります。変更後のプランを使用しても、そのモニターは再び有効にはなりません。

デプロイメント・プランを使用すると、アプリケーションを再デプロイしなくても、構成要素を動的に更新できます。

- <enabled>

- <dye-filtering-enabled>

- <dye-mask>

- <action>

デプロイメント・プランの使用:概要

デプロイメント・プランを作成および使用する一般的なプロセスは次のとおりです。

1. アプリケーションに対して整形式のweblogic-diagnostics.xml記述子ファイルを作成します。
空の記述子を作成することをお薦めします。そうすることで、構成を柔軟に動的に変更できます。元の記述子ファイル内にモニターを作成し、デプロイメント・プランを使用してその設定をオーバーライドすることができます。ただし、再デプロイしないとモニターを完全には削除できません。デプロイメント・プランを使用して空の記述子にモニターを追加した場合、そのモニターはすべて削除できます。診断アプリケーション・モジュールの構成については、「アプリケーション・スコープのインストゥルメンテーションの構成」を参照してください。

診断モジュールはdiagnostics.xsdスキーマに準拠しています。このスキーマは、http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsdで参照できます。

2. 該当するアーカイブの最上位のMETA-INFディレクトリに、記述子ファイルweblogic-diagnostics.xmlを置きます。

3. たとえば、weblogic.PlanGeneratorを使用して、デプロイメント・プランを作成します。「weblogic.PlanGeneratorによるデプロイメント・プランの作成」を参照してください。

4. サーバーを起動します。必要に応じてJavaホットスワップを有効にします。「Javaホットスワップ機能の有効化」を参照してください。

5. デプロイメント・プランを使用してアプリケーションをデプロイします。「デプロイメント・プランによるアプリケーションのデプロイ」を参照してください。

6. 必要な場合は、プランを編集し、そのプランを使用してアプリケーションを更新します。「変更したプランによるアプリケーションの更新」を参照してください。

weblogic.PlanGeneratorによるデプロイメント・プランの作成

weblogic.PlanGeneratorツールを使用すると、初期状態のデプロイメント・プランを作成できます。またこのツールにはweblogic-diagnostics.xml記述子の特定のプロパティを対話形式でオーバーライドする機能もあります。

PlanGeneratorツールは、選択したアプリケーションにあるすべてのJava EEデプロイメント記述子を検査し、アプリケーション用に外部リソースを構成するWebLogic Serverデプロイメント・プロパティのうち、関連するものに対して、変数部分が指定されていないデプロイメント・プランを作成します。

プランを作成するには、次の構文を使用します。

java weblogic.PlanGenerator -plan output-plan.xml [options]
application-path

例:

java weblogic.PlanGenerator -plan foo.plan -dynamics /test/apps/mywar

注意:
-dynamicsオプションは、動的に更新できるオプションのみを含めてプランを生成することを指定します。

デプロイメント・プランの作成および使用の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番デプロイメントのためのアプリケーションの構成に関する項を参照してください。

PlanGeneratorの使用方法の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.PlanGeneratorコマンド・ライン・リファレンスおよび新しい環境にデプロイメントするためのアプリケーションのエクスポートに関する項を参照してください。

診断用のデプロイメント・プランのサンプル

例14-1では、weblogic.PlanGeneratorを使用して生成される簡単なデプロイメント・プランを示します。(読みやすくするため、一部の情報は削除されています)。このプランでは、Servlet_Before_Serviceモニターを有効にして、それをアクションDisplayArgumentsActionおよびStackDumpActionに加えています。

例14-1 サンプル・デプロイメント・プラン

<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
global-variables="false">
<application-name>jsp_expr_root</application-name>

<variable-definition>
<!-- Add two additional actions to Servlet_Before_Service monitor -->
<variable>
<name>WLDFInstrumentationMonitor_Servlet_Before_Service_Actions_113050559713922</name>
<value>"DisplayArgumentsAction","StackDumpAction"</value>
</variable>
<-- Enable the Servlet_Before_Service monitor -->
<variable>
<name>WLDFInstrumentationMonitor_Servlet_Before_Service_Enabled_113050559713927</name>
<value>true</value>
</variable>
</variable-definition>

<module-override>
<module-name>jspExpressionWar</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>wldf-resource</root-element>
<uri>META-INF/weblogic-diagnostics.xml</uri>
<variable-assignment>
<name>WLDFInstrumentationMonitor_Servlet_Before_Service_Actions_113050559713922</name>
<xpath>/wldf-resource/instrumentation/wldf-instrumentation-monitor/[name="Servlet_Before_Service"]/action</xpath>
</variable-assignment>
<variable-assignment>
<name>WLDFInstrumentationMonitor_Servlet_Before_Service_Enabled_113050559713927</name>
<xpath>/wldf-resource/instrumentation/wldf-instrumentation-monitor/[name="Servlet_Before_Service"]/enabled</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
<config-root xsi:nil="true"></config-root>
</deployment-plan>

デプロイメント・プランで指定できる診断モニターとアクションのリストと説明については、付録B「WLDFインストゥルメンテーション・ライブラリ」を参照してください。

Javaホットスワップ機能の有効化

Javaホットスワップ機能を有効にするには、次のコマンドライン・スイッチを使用してサーバーを起動します。

-javaagent:$WL_HOME/server/lib/diagnostics-agent.jar

デプロイメント・プランによるアプリケーションのデプロイ

デプロイメント・プランによって提供される動的な制御を利用するには、プランを使用してアプリケーションをデプロイする必要があります。

デプロイメントを制御するには、管理コンソールやWebLogic Scripting Tool (WLST)などの標準のWebLogic Serverツールを使用できます。たとえば、次のWLSTコマンドでは、対応するデプロイメント・プランでアプリケーションをデプロイします。

wls:/mydomain/serverConfig> deploy('myApp', './myApp.ear', 'myserver',
'nostage', './plan.xml')

デプロイメント後に有効な診断モニター構成は、元の記述子と、プランから得られるオーバーライドされた属性値の組み合わせです。元の記述子に所定の名前のモニターが含まれず、プランでそのモニターの属性をオーバーライドした場合、そのモニターはアプリケーションで使用されるモニターのセットに追加されます。このように、アプリケーションが空のweblogic-diagnostics.xml記述子と一緒にビルドされていれば、デプロイメント・プロセス中やその後で、アプリケーションのアーカイブを変更せずにアプリケーションに診断モニターを追加できます。

変更したプランによるアプリケーションの更新

構成設定を変更するには、デプロイメント・プランを変更してから、ホットスワップが有効になっているかどうかに応じて、アプリケーションを更新または再デプロイします(表14-2を参照して、アプリケーションを更新するのみでよい場合と再デプロイが必要な場合を確認します)。更新または再デプロイを行うには、管理コンソールやWebLogic Scripting Tool (WLST)などの標準のWebLogic Serverツールを使用できます。

ホットスワップを有効にした場合は、プランを使用してアプリケーションを更新すると、変更後のプランの値でアプリケーションの構成を更新できます。たとえば、以下のWLSTコマンドは、プランを使用してアプリケーションを更新します。

wls:/mydomain/serverConfig> updateApplication('BigApp',
'c:/myapps/BigApp/newPlan/plan.xml', stageMode='STAGE',
testMode='false')

ホットスワップを有効にしなかった場合、特定の変更を有効にするには、アプリケーションを再デプロイする必要があります。たとえば、以下のWLSTコマンドは、プランを使用してアプリケーションを再デプロイします。

wls:/mydomain/serverConfig> redeploy('myApp' 'c:/myapps/plan.xml')

15 監視ダッシュボードの使用

監視ダッシュボードでは、そこで実行されているサーバーおよびアプリケーションの診断データをグラフで表示するためにビューとツールが提供されます。WebLogic診断フレームワークによって、診断データの生成、取得およ永続化するための次の機能が提供されます。また、監視ダッシュボードでは、そのデータをチャートとグラフで表示するために追加ツールが提供されます。

次の項では、監視ダッシュボードについて説明します。

- 監視ダッシュボードの実行

- 表示される診断情報の範囲

- 監視ダッシュボードのインタフェースについて

- メトリックの収集と表示の方法

- チャートの構成要素

監視ダッシュボードの実行

WebLogic Server管理コンソールから監視ダッシュボードを起動するか、またはWebブラウザで単独で実行できます。ブラウザに設定されたプリファレンスに応じて、監視ダッシュボードは常に独自のタブまたはウィンドウで表示されます。管理コンソールでログインせずに、監視ダッシュボードを使用できます。ただし、ログインしていない場合、ユーザー名とパスワードの資格証明を求められます。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプの監視ダッシュボードの起動に関する項を参照してください。

表示される診断情報の範囲

監視ダッシュボードにより表示される診断データでは、測定に役立つ数値またはブール値を持つランタイムMBean属性の現在値または系時的に変更した値が表示されます。これらの値は、監視ダッシュボードでメトリックと呼ばれ、ドメイン内の1つ以上のサーバーの1つ以上のランタイムMBeanインスタンスから送信されます。

監視ダッシュボードは、次の2つのソースからメトリックを取得します。

- アクティブなランタイムMBeanインスタンスから直接 - この章では、これらのメトリックはポーリングされるメトリックと呼ばれています。

- ハーベスタから収集されたアーカイブ先から - これらのメトリックは、アクティブなランタイムMBeanインスタンスから直接取得され、監視ダッシュボードに戻される値のメトリックと区別するために収集されたメトリックと呼ばれています。

監視ダッシュボードのインタフェースについて

監視ダッシュボードでは、2つのメイン・パネルがあります。 次の図に示す、エクスプローラ・パネルとビューの表示パネルです。

図15-1 監視ダッシュボードのパネル

「図15-1 監視ダッシュボード・パネル」の説明

エクスプローラ・パネルでは、次にアクセスできます。

- 「ビュー・リスト」 - 既存の組込みおよびカスタムのビューのセット。これは、作成、コピー、名前の変更およびビューの削除の制御があります。詳細は、「ビュー・リスト」を参照してください。

- 「メトリック・ブラウザ」 - ビューにあるチャートにメトリックの値を表示する特定のMBeanインスタンス属性の移動および選択のための手段が提供されます。詳細は、「メトリック・ブラウザ」を参照してください。

ビュー・リスト

ビューを表示するには、図15-2で示すように、「ビュー・リスト」でビューを選択します。

図15-2 ビュー・リストで表示される組込みビューおよびカスタム・ビュー

「図15-2 ビュー・リストで示した組込みおよびカスタムのビュー」の説明

ビューは、次の2つの主カテゴリで表示されます。

- 組込みのビュー

組込みビューは、ドメイン内のすべての実行中のWebLogic Serverインスタンスに使用できるランタイム・メトリックの事前定義された一連のビューです。これらのビューでは、重要性の高いWebLogic Serverパフォーマンス・メトリックが表示され、監視ダッシュボードのビューとチャート機能の例になります。

組込みビューについて次の点に注意してください。

- 組込みビューは、動的です。たとえば、4つのサーバーを実行している場合、使用できる一連の組込みビューとそのチャートがその4つのサーバーと関連付けられます。5つのサーバーを実行している場合、一連の組込みビューとそのチャートが各追加サーバーに対して拡張されます。また、ダッシュボードを使用しているときにサーバー・インスタンスの数が変更された場合(たとえば、サーバーが起動または停止した場合)、現在実行中の一連のサーバー・インスタンスの新しい組込みビューを表示するには、「ビュー・リスト」メニューで「リフレッシュ」を選択して、ビューのリストをリフレッシュします。

- 組込みビューは、各WebLogic Serverのインストールで自動的にインストールされ、管理コンソールまたは監視ダッシュボードにログインしたすべてのユーザーが使用できます。

- 組込みビューは修正できませんが、コピーすることはできます。コピーした後に、ビューの修正、名前の変更、保存および削除ができます。

- カスタム・ビュー
カスタム・ビューは、ユーザーによって作成されたビューです。カスタム・ビューは、これを作成したユーザーのみが使用できます。カスタム・ビューはそのユーザーに自動的に保持され、そのユーザー・アカウントおよび現在のドメイン内でのみ有効です。(ただし、「監視ダッシュボード」ウィンドウを閉じている場合は、カスタム・ビューで表示されるポーリングしたメトリック値は、組込みビューで保持されないのと同じように保持されませんのでご注意ください。)

デフォルトで使用できるカスタム・ビューはありません。

詳細は、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。

- 監視ダッシュボードのビューの使用

- ビューの開始と終了

- カスタム・ビューの作成

- ビューのコピー

- ビューの削除

メトリック・ブラウザ

チャートには、MBeanインスタンスの属性であるメトリックが表示されます。メトリックは、次のいずれかになります。

- 実行中のWebLogic ServerインスタンスでのアクティブなMBeanインスタンスから値を取得したメトリック。
実行中のサーバー・インスタンスは定期的にポーリングされ、戻されたメトリック値を表示するチャートが定期的に更新されます。(詳細は、「現在時間の範囲チャート」を参照してください)。

- アーカイブから値を取得した収集されたメトリック。
収集されたメトリックは、以前WLDFハーベスタによってキャプチャされたメトリックで、アーカイブに配置されていて、過去の状態のレコードを提供します。収集されたメトリックのみを表示するチャートは更新されません。(詳細は、「カスタム時間の範囲チャート」を参照してください)。

チャートに追加するメトリックを選択するために、メトリック・ブラウザを使用します。図15-3で示したメトリック・ブラウザには次のものが表示されます。

- 現在登録されているWebLogic MBeanタイプ

- 現在登録されているMBeanタイプのインスタンス

- 登録されているインスタンスの属性

ハーベスタによって収集されるメトリックを選択するための便利な方法として、「メトリック・ブラウザ」には「収集対象メトリックのみ」というボタンが提供されています。このボタンを選択すると、「メトリック・ブラウザ」には収集対象メトリックのみが表示されます。

現在アクティブなインスタンスかどうかに関係なく、すべてのランタイムMBeanタイプを表示するには、「すべてのタイプを含める」を選択します。ハーベスタによってメトリックが収集されているかどうかを決定するには、メトリックを選択するか、マウスをこの上に配置します。ノート・ウィンドウは、収集されているメトリック(ハーベスタによって収集されたメトリック)かどうかを含め、メトリックについての情報が提供されます。

図15-3 メトリック・ブラウザ

「図15-3 メトリック・ブラウザ」の説明

「メトリック・ブラウザ」を選択するには、表示するメトリック値を含むサーバー・インスタンスを選択します。「メトリック・ブラウザ」には、オプションで、メトリック・データが収集されているもののみに対して表示されるMBeanタイプ、登録したインスタンスおよびメトリックのリストを制限するか、またはアクティブなインスタンスがなくても、サーバーのすべてのMBeanタイプを表示します。

また、メトリックを検索するには、まずそのMBeanタイプを選択してからこのメトリックが存在するインスタンスを選択するという必要はありません。任意の順序でメトリックを選択できます。たとえば、必要に応じてまずメトリックを選択することも、MBeanインスタンスを選択することもできます。また、表示されるものを制限するために、各リストにフィルタを適用できます。

任意の順序で選択およびフィルタをすることができます。1つのリストで項目を選択すると、他のリストでも選択され、そのリストを制限する場合もあります。次の動作に注意してください。

- 最初は、「タイプ」リスト・ボックスで、(「収集対象メトリックのみ」および「すべてのタイプを含める」チェック・ボックスの設定で決定したとおり)すべてのMBeanタイプが表示されます。「インスタンス」リスト・ボックスで、すべてのMBeanインスタンスおよび「メトリック」リスト・ボックスで、すべてのメトリックが表示されます。

- 特定のMBeanタイプを選択すると、MBeanインスタンス・リストが同じタイプのインスタンスに制限され、メトリック・リストが同じタイプのメトリックに制限されます。

- 「タイプ」リストで(なし)を選択するとタイプを指定しないこととなり、「インスタンス」および「メトリック」リストのエントリに制限がなくなります。

- 他の選択の前または後に特定のMBeanインスタンスを選択すると、次のようになります。

- 「タイプ」リスト・ボックスで対応するMBeanタイプが選択されます。

- 「メトリック」リストにあるエントリが、そのMBeanインスタンスのメトリックのみに制限されます。

- 他の選択の前または後に「メトリック」リスト・ボックスで特定のエントリを選択すると、次のようになります。

- メトリックが対応する特定のMBeanタイプが「タイプ」リストで選択されます。

- 「インスタンス」リストが、メトリックが対応するMBeanインスタンスに制限されます。

- リスト・ボックスにフィルタ文字列を入力すると、フィルタと一致する項目のみを含むようにリストの内容を制限します。フィルタと組み合せて使用する、前の項目で指定した動作は、「論理的AND」と同様の動作となります。

これらの動作によって、MBeanタイプ、MBeanインスタンスとメトリックの間の関係が強化できます。各MBeanインスタンスは特定のMBeanタイプであり、各メトリックは特定のMBeanタイプに対応します。MBeanタイプによって、そのタイプのすべてのインスタンスとともに、タイプにあるすべてのメトリックも決定されます。

メトリック・ブラウザの使用については、Oracle WebLogic Server管理コンソール・ヘルプにある次のトピックを参照してください。

- メトリック・ブラウザの使用

- 監視するサーバーの選択

- メトリック・ブラウザでの項目の表示

- MBeanインスタンスおよびメトリック・ブラウザ内のメトッリクについてのサマリー・ノートの表示

ビューの表示パネル

図15-4で表示されているように、ビューは、キャプチャされたメトリック値を表示する1つ以上のチャートの集まりです。監視ダッシュボードでは一度に表示できるビューは1つのみですが、複数のビューを同時に実行できます。

図15-4 4つのチャートを含むビュー

「図15-4 4つのチャートを含むビュー」の説明

ビュー内の各チャートには、凡例、ラベル、およびデータを識別し表示するためのコントロールが含まれています。次のようなチャート・スタイルをビューに含めることができます。

- 長期間にわたって各メトリック値の変化を示す折れ線グラフまたは棒グラフなどの時系列チャート

- メトリック値に対して収集された次の統計値とともにメトリックの現在値または最新値を示すゲージ

- 最小

- 最大

- 平均

- 標準偏差

現在の時間範囲のメトリックをチャートで表示できます。つまり、監視ダッシュボードが定期的にメトリックの新しい値を取得するのに伴って、チャートは継続的に更新されます.。または、すでに過ぎたカスタム時間範囲を指定したチャートでは、ハーベスタによってキャプチャされたアーカイブアから取得した収集メトリックを表示できます。

ビューの表示と開始およびその中のチャートの配置の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。

- チャート、メトリックおよびビューの表示または作成: 主な手順

- 監視ダッシュボードのビューの使用

- ビューの表示

- ビューの開始と終了

監視ダッシュボード・チャートの概要の詳細は、「チャートのパーツ」を参照してください。

メトリックの収集と表示方法について

表示される診断情報の範囲に記述のとおり、監視ダッシュボードには次の2つのソースからのメトリックが表示されます。

- 実行しているWebLogic Serverインスタンスから定期的に取得して監視ダッシュボードに戻す、リアルタイムな、ポーリングされているメトリック値。

- ハーベスタによって収集され、アーカイブに配置されるメトリック。

監視ダッシュボードで、リアルタイムな、ポーリングされているメトリックを表示するために、ハーベスタを構成する必要はありません。リアルタイムな、ポーリングされているメトリックを1つ以上含むチャートを使用してビューを起動すると、それらのメトリックに対応するランタイムMBeanインスタンスが各構成済間隔でポーリングされ、リクエストしたメトリック値を監視ダッシュボードに戻します。ポーリングされているメトリックは、複数のチャートまたは複数のビューに追加されていた場合でも監視ダッシュボードで1回のみ格納されます。それぞれのメトリック値が表示されるチャートまたはビューの数に関係なく、そのメトリックに対応するランタイムMBeanインスタンスも各間隔で1回のみポーリングされます。したがって、メトリックの更新された値が監視ダッシュボードで受信される場合、そのメトリックを含むすべてのチャートが同時に更新されます。これにより、監視ダッシュボードでシステム上のパフォーマンスのオーバーヘッドが最小化され、全体的な効率が最大化されます。

収集されたメトリックを表示するには、監視するデータを収集するためにハーベスタを構成し、アーカイブに含む必要があります。収集されたメトリックを含む1つまたは複数のカスタム時間範囲チャートのビューでは、特定のカスタム時間範囲チャートに対応するメトリックの値をアーカイブから1回取得し、そのチャートに表示します。収集されたデータは、プログラムでのアクセスで使用でき、標準の管理コンソールと監視ダッシュボードを使用してビューできる標準ログHarvestedDataArchiveで書き込まれることに注意してください。メトリックを収集するためのハーベスタ構成の詳細は、第7章「メトリック収集用のハーベスタの構成」を参照してください。

メトリックおよびチャート・タイプについて

監視ダッシュボードのメトリックを示す方法は、表示されるチャートによって異なります。チャートをビューに追加後、次のいずれかの時間範囲を指定するために「チャート・プロパティ」ダイアログ・ボックスを使用できます。

- 現在

- カスタム

次の項では、各チャート・タイプでメトリックを示す方法についての主要な情報を提供します。

現在時間範囲チャート

これは、監視ダッシュボードにおけるチャートのデフォルトの時間範囲です。この時間範囲は、現在の時間範囲チャートのみで表示できるリアルタイムな、ポーリングされているメトリックを表示するために使用します。これらのチャートは、デフォルトで20秒ごとに一定の間隔で更新されます。(サンプル間隔は「ダッシュボードのプリファレンス」ダイアログ・ボックスでカスタマイズできます。)

現在の時間範囲チャートにメトリックを追加すると、監視ダッシュボードがそのメトリックに対してアーカイブから少数の履歴データを取得します。現在の時間範囲チャートに対してアーカイブから取得したメトリック値に関しては次のことに注意してください。

- 取得した値の数は格納したサンプルの保存範囲時間をチャートの最大サンプル数で乗算して求められます。(デフォルトのサンプリング間隔は20秒で、デフォルトのサンプル最大時間は100秒です。これは、2000秒または約33.3分の時間範囲を示します。)

- ハーベスタが使用するサンプリング間隔が監視ダッシュボードに対して構成されたサンプリング間隔と異なる場合は、そのメトリックのグラフにゆがみが表示されることがあります。

カスタム時間範囲チャート

カスタム時間範囲で構成されているチャートには収集対象メトリックのみが表示されます。チャートのカスタム時間範囲を指定して収集対象メトリックを追加する場合、監視ダッシュボードは指定された時間範囲に一致するアーカイブからメトリック値を取得します。これらのチャートは静的です。監視ダッシュボードがカスタム時間範囲チャートで収集対象メトリックを表示すると、それらのメトリックの値が変更されることはありません。

次に注意してください:

- カスタム時間範囲チャートには、リアルタイムおよびポーリングされるメトリック値が含まれていません。

- カスタム時間範囲チャートを作成するための便利な方法として、「メトリック・ブラウザ」には「収集対象メトリックのみ」というラベルのボタンを提供されています。このボタンを選択すると、「メトリック・ブラウザ」には収集対象メトリックのみが表示されます。

メトリック・データが表示される順序

ハーベスタが、収集対象ランタイムMBeanメトリックに構成される場合、収集は監視ダッシュボードを実行しているかどうかに関係なく個別に開始できます。この項では、監視ダッシュボードが現在時間範囲とカスタム時間範囲チャートにメトリックを収集して表示するときに生成されるアクティビティの手順を示します。

1. ハーベスタがメトリックに対してデータを収集するように構成される場合、サーバーの起動後、そのデータのハーベスタを開始します。データはアーカイブで維持されます。

2. 監視ダッシュボードが起動するとき、使用可能な組込みビューとカスタム・ビューのリストが表示されます。ただし、1つ以上のビューを開始しないと、JMXによるメトリック値の直接的なリアルタイム・ポーリングが開始しません。

3. 現在の時間範囲チャートがあるビューを開始すると、次の操作が行われます。

- 監視ダッシュボードがチャートにあるメトリックに対応するランタイムMBeanインスタンスのポーリングを開始します。

- ハーベスタがアーカイブでこのメトリックのデータを収集した場合、そのデータがすぐにチャートに追加されます。監視ダッシュボードがアーカイブから取得するサンプル数がチャートの時間範囲に対応します。

- ハーベスタがこのメトリックに対してデータを収集するように構成されていない場合、このメトリックのアーカイブから履歴データが取得されず、何も表示されません。

4. カスタム時間範囲チャートを含むビューを作成した場合、監視ダッシュボードがアーカイブからそのチャートに指定したカスタム時間範囲に一致するメトリックの値セットを取得します。値がチャートに表示された後は、チャートは更新されません。カスタム時間範囲チャートを追加しているビューは、収集したメトリックの値を表示するために開始する必要はありません。

5. メトリックのポーリング・データ値が監視ダッシュボードに到達すると、新しい値がチャートに追加されます。アーカイブから取得した最も古い値(存在する場合)がパージされます。
チャートは常に最新データを表示します。チャートの最大サンプル数は、現在の時間範囲チャートおよびカスタム時間範囲チャート両方にメトリックのために保存できるサンプル数を決定します。チャートの最大サンプル数のしきい値に達した後、最新の値を受信すると最も古いメトリック値が削除されます。

メトリック・データ保存に関する注意

監視ダッシュボードのウィンドウを閉じるまたはログ・アウトして監視ダッシュボードを終了すると、監視ダッシュボードでセッション中に取得したすべてのメトリック値が失われるため、ブラウザにより選択を確認するように促されます。監視ダッシュボードを終了しても、アーカイブに存続している収集したメトリックに影響はありません。ただし、アーカイブでは、データの保存時間に制限するデータ・リタイア・ポリシーがあることがあります。情報は、「アーカイブからデータのリタイア」を参照してください。

チャートの構成要素

チャートは、次の要素で構成されます。

- チャート名

- チャート・タイプに従って表示される1つ以上のデータ値を示すチャート・ビューポート。タイプとして、指定された時間範囲への個別データ・ポイントをプロットする時系列チャート、またはメトリックの現在や最新の値を表示するゲージおよび最大値、最小値、平均値と標準偏差値を示す統計を使用できます。

- 診断データをプロットするためのX軸とY軸。

- 時系列チャートの場合、データ・ポイントは時間ベースのX軸に対してプロットします。ズーム・インまたはズーム・アウトして、ビューポートの時間セグメントを拡大または縮小して表示できます。

- Y軸には範囲があり、デフォルトでチャートのすべてのデータ・ポイントを含むように自動的に設定されています。Y軸の最小値と最大値をオプションで構成できます。

- メトリック名を含む各メトリックの凡例およびチャートのビューポートでのメトリックのために使用された色付きのマーカー記号。
メトリック凡例には、選択するとメトリックで実行できる操作へのアクセスを提供するボタンが含まれています。メトリックで実行できる操作は次のとおりです。

- チャートのメトリックのために表示されたメトリック名、およびチャート・ビューポートに表示されたメトリック・データ・ポイントに使用される形状と色を変更します。

- 他のチャートにメトリックをコピーまたは移動するか、カレント・チャート内に凡例を移動するか、チャートからメトリックを削除します。

- チャート系列概要
時系列チャートに利用できるチャート系列概要には、表された期間の該当するメトリックに対して収集されたデータ・セット全体に関連してチャートに現在表示されているメトリック・データの一部を表示します。ビューポートまたはチャート系列概要でドラッグして選択すると、チャートのデータをズーム・インまたはズーム・アウトできます。

チャート系列概要はオプションで非表示にでき、監視ダッシュボードで同時に表示されるUIアーティファクト数を減らすために利用でき、処理速度の遅いシステムまたはブラウザのパフォーマンスも向上できます。

チャート系列概要の表示設定のカスタマイズの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのダッシュボード・プリファレンスの設定に関する項を参照してください。

- チャートのX軸に表示されるデータをパンおよびズームするためのボタン。これらのボタンはチャート系列概要の一部であるため、チャート系列概要に設定された表示プロパティもこれらのボタンに適用されます。

- オプションのY軸単位のラベル

- チャート・メニュー・ボタンを選択して使用できる「チャート」メニュー
チャート・メニューを使用して、メトリックの追加、チャート・タイプの変更、ビューポートに表示されるデータのパンおよびズームができます。また、様々なチャート・プロパティを設定できます。

- 編集ツール
編集ツールを選択して、チャート名、Y軸単位のラベルおよびチャートに追加された各メトリックを識別するために使用される名前を変更します。

図15-5は、ライン・プロット・チャートで表示されるこれらの各パートを示します。

図15-5 チャートの構成要素

「図15-5 チャートの構成要素」の説明

図15-6で示されるゲージ・チャートには、追加された各メトリックに関する次の追加情報が含まれます。

- 最大値および最小値

- 平均値

- 標準偏差

図15-6 ゲージ・チャート・タイプで表示されるデータ値

「図15-6 ゲージ・チャート・タイプで表示されるデータ値」の説明

ゲージ・チャートの特定のメトリックに関連付けられたそれぞれのアーティファクトによって示される数値を表示するには、表15-0で示されるように、現在の値ラベルごとにマウス・ポインタを該当するメトリックのマーカー・シンボルの上に置きます。

監視ダッシュボードのチャートの作成、変更および使用方法の詳細は、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。

- チャート内のメトリックの取扱い

- ビューへのチャートの追加

- チャート・タイプの選択

- チャートのメトリックのサマリー情報の表示

- チャートで表示されるメトリック・データのパンおよびズーム

- ゲージ統計のリセット

- チャートのコピーまたは移動

- チャート時間範囲の設定

- Y軸範囲の制御

- チャートのしきい値の表示

16 WLDFのプログラム的な構成と使用

前の章で説明したように、WebLogic Server管理コンソールを使用して、WebLogic診断フレームワーク(WLDF)などのWebLogic Serverの機能を有効化、構成、およびモニターすることができます。また、JMX APIとWebLogic Scripting Tool (WLST)を使用して、同じタスクをプログラムで実行することもできます。

次の項では、WLDFのプログラム的な構成について説明します。

- WLDFによるデータの生成と取得

- BeanおよびパッケージへのWLDFコンポーネントのマッピング

- プログラミング・ツール

- WLDFパッケージ

- WLDFプログラミング:サンプル

アプリケーションの開発とデプロイ、およびWLSTの使い方については、次の項での説明に加え、次のマニュアルも参照してください。

- Oracle WebLogic Serverアプリケーションの開発

- Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発

- Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発

- Oracle WebLogic Serverへのアプリケーションのデプロイ

- Oracle WebLogic Scripting Toolガイド

WLDFによるデータの生成と取得

通常、診断データは、以下のプロセスでWLDFコンポーネントによって生成および取得されます。

- ハーベスタ、インストゥルメンテーション、イメージ・キャプチャ、および監視および通知の各コンポーネントのWLDF XML記述子ファイルの設定によって、サーバーの実行中に生成される診断データの種類と量が決まります。

- 診断コンテキストとインストゥルメンテーションの設定によって、診断データがシステム内を流れる過程でフィルタ処理およびモニターされます。データが収集され、アクションがトリガーされ、イベントが生成され、構成された通知が送信されます。

- アーカイブ・コンポーネントによってデータが格納されます。

- アクセサ・コンポーネントによってデータが取得されます。

構成は主に管理タスクであり、管理コンソールまたはWLSTスクリプトを使用して行います。システム・レベル(サーバーおよびクラスタ)やアプリケーション・レベルでデプロイ可能な記述子モジュールとXML構成ファイルは、診断リソースを構成するための主なメソッドです。(WLDFリソースの構成の詳細は、第4章「WLDF構成について」を参照してください。)

アクセサ・コンポーネントによる出力の取得は、管理タスクになる場合と、プログラム的なタスクになる場合があります。

BeanおよびパッケージへのWLDFコンポーネントのマッピング

管理コンソールまたはWLSTを使ってWLDFリソースを作成すると、WebLogic Serverは各リソースについてMBean(マネージドBean)を作成します。JMXまたはWLSTを使用してこれらのMBeanにアクセスできます。weblogic.WLSTはJMXクライアントであるため、WLSTを使用して実行できるすべてのタスクは、JMXを使用してプログラム的に実行することもできます。

表16-1には、WLDFおよびそのコンポーネントに関係するBeanとパッケージを示します。図16-1では、Beanをタイプ別にグループ化しています。

表16-1 BeanおよびパッケージへのWLDFコンポーネントのマッピング

コンポーネント

Bean /パッケージ

WLDF

WLDFServerDiagnosticMBean

WLDFSystemResourceMBean

WLDFBean (abstract)

WLDFResourceBean

WLDFRuntimeMBean

診断イメージ

WLDFImageNotificationBean

WLDFImageCreationTaskRuntimeMBean

WLDFImageRuntimeMBean

インストゥルメンテーション

WLDFInstrumentationBean

WLDFInstrumentationMonitorBean

WLDFInstrumentationRuntimeMBean

診断コンテキスト

パッケージ: weblogic.diagnostics.context

DiagnosticContextHelper

DiagnosticContextConstants

ハーベスタ

WLDFHarvesterBean

WLDFHarvestedTypeBean

WLDFHarvesterRuntimeMBean

監視および通知

WLDFNotificationBean

WLDFWatchNotificationBean

WLDFJMSNotificationBean

WLDFJMXNotificationBean

WLDFSMTPNotificationBean

WLDFSNMPNotificationBean

WLDFWatchJMXNotificationRuntimeMBean

WLDFWatchNotificationRuntimeMBean

パッケージ: weblogic.diagnostics.watch

JMXWatchNotification

WatchNotification

アーカイブ

WLDFArchiveRuntimeMBean

WLDFDbstoreArchiveRuntimeMBean

WLDFFileArchiveRuntimeMBean

WLDFWlstoreArchiveRuntimeMBean

アクセサ

WLDFAccessRuntimeMBean

WLDFDataAccessRuntimeMBean

図16-1 WLDF 構成MBean、ランタイムMBean、およびシステム・モジュールBean

「図16-1 WLDF構成MBean、ランタイムMBean、およびシステム・モジュールBean」の説明

プログラミング・ツール

WebLogic診断フレームワークを使用すると、次のタスクをプログラムで実行できます。

- 診断記述子ファイルを作成および変更して、WLDFハーベスタ、インストゥルメンテーション、および監視および通知コンポーネントをサーバー・レベルで構成します。

- JMXを使用して、WLDFの操作と属性にアクセスします。

- JMXを使用して、収集可能なデータを格納するカスタムMBeanを作成します。次に、ハーベスタを構成してデータを収集したり、監視および通知を構成して値をモニターしたりできます。

- 次のタスクを実行するJavaプログラムを作成します。

- JMXリスナーによる通知のキャプチャ。

- JMSによる通知のキャプチャ。

- アクセサによるアーカイブされたデータの取得(アクセサは、他のコンポーネントと同様にJMXとして表面化されており、WLSTやJMXプログラミングによって診断データを取り出すことができます)。

構成APIと実行時API

構成APIと実行時APIは、WLDFを構成およびモニターします。構成APIと実行時APIは、双方ともMBeanとして公開されます。

- 構成MBeanとシステム・モジュールBeanは、WLDFリソースを作成および構成し、その実行時の動作を決定します。

- ランタイムMBeanは、様々なコンポーネントの実行時状態および定義された処理をモニターします。

構成APIと実行時APIを使用すると、データ収集を構成、アクティブ化、非アクティブ化したり、監視、通知、アラーム、診断イメージ・キャプチャを構成したり、データにアクセスしたりできます。

構成API

構成APIは、次のWLDFコンポーネントの構成に使用するインタフェースを定義します。

- データ・コレクタ:構成APIを使用すると、インストゥルメンテーション、収集、イメージ・キャプチャを構成および制御できます。

- インストゥルメンテーション・コンポーネントでは、サーバー・レベルのインストゥルメンテーションおよびインストゥルメンテーション・モニターを有効化、無効化、作成、および破棄できます。

注意:
構成APIでは、アプリケーション・レベルのインストゥルメンテーションの構成をサポートしていません。ただし、Java Specification Request (JSR) 88 APIを使用している場合、アプリケーション・レベルのインストゥルメンテーションに対する構成の変更が影響を受ける可能性があります。

- ハーベスタ・コンポーネントでは、収集する型を追加および削除したり、その型のどの属性およびインスタンスを収集するかを指定したり、ハーベスタのサンプル期間を設定したりできます。

- 診断イメージ・キャプチャ・コンポーネントでは、イメージ・キャプチャを格納するディレクトリの名前とパス、イベント・イメージ・キャプチャの間隔(最近アーカイブされたイベントが診断イメージにキャプチャされる時間間隔)を設定できます。

- 監視および通知:構成APIを使用すると、監視および通知の有効化、無効化、作成および破棄を行えます。また、構成APIを使用すると、次のことが可能になります。

- ルールの種類、監視ルール式、監視の重大度の設定

- 通知に対するアラームの種類およびアラーム・リセット期間の設定

- 診断イメージ・キャプチャをトリガーするための監視の構成

- 監視への通知の追加、および監視からの通知の削除

- アーカイブ:アーカイブの種類およびアーカイブ・ディレクトリを設定できます。

実行時API

実行時APIは、WLDFコンポーネントの実行時の状態をモニターするためのインタフェースを定義します。これらのAPIのインスタンスは、個々の管理対象サーバーのインスタンス上でインスタンス化されます。実行時APIは、ランタイムMBeanとして定義されているので、JMXクライアントが簡単にアクセスできます。

実行時APIは、個々のWLDFコンポーネントの他のすべての実行時インスタンスをカプセル化します。これらのAPIは、weblogic.management.runtimeパッケージに入っています。

実行時APIを使用すると、以下のWLDFコンポーネントをモニターできます。

- データ・コレクタ:実行時APIを使用すると、インストゥルメンテーション、ハーベスタ、イメージ・キャプチャの各コンポーネントをモニターできます。

- インストゥルメンテーション・コンポーネントでは、ジョインポイント数の統計、インストゥルメンテーション・モニターで検査されたクラスの数、変更されたクラスの数、およびインストゥルメンテーション・モニターでクラスの検査にかかった時間をモニターできます。

- ハーベスタ・コンポーネントでは、収集可能な型のセット、収集可能な属性、および収集可能なインスタンス(つまり、特定の型で現在収集可能なインスタンス)を問い合わせることができます。また、収集用に現在構成されている型、属性、およびインスタンスを問い合わせることもできます。サンプリング間隔、および収集プロセスに関する様々な実行時統計も利用可能です。

- イメージ・キャプチャ・コンポーネントでは、診断イメージの出力先およびロックアウト期間を指定して、イメージ・キャプチャを開始できます。

- 監視および通知:実行時APIを使用すると、監視および通知およびアーカイブの各コンポーネントをモニターできます。

- 監視および通知コンポーネントでは、監視アラームを設定したり、アラーム、イベント、ログ・レコード、収集されたメトリックの解析に関する情報など、監視ルールの評価やトリガーされた監視に関する統計をモニターしたりできます。

- アーカイブ:ファイル名、アーカイブの統計など、アーカイブに関する情報をモニターできます。

- データ・アクセサ:実行時APIを使用すると、別のアーカイブに保持されている診断データを取り出すことができます。また、実行時APIでは、基底のアーカイブからデータを検索する問合せ式を指定できるので、データのフィルタ処理も利用できます。列型のマップ(診断データの対応する型名に列名を関連付けたマップ)、データ・レコード数とタイムスタンプに関する統計、カーソル(クライアントがデータ・レコードを取得するためのカーソル)に関する情報をモニターできます。

WLDFパッケージ

以下の2つのパッケージが用意されています。

- weblogic.diagnostics.contextには以下が含まれます。

- DiagnosticContextConstants、WebLogic診断システムでサポートされる仕分けフラグの索引を定義します。

- DiagnosticContextHelper、アプリケーションから診断コンテキストへの限定的なアクセスを提供します。

- weblogic.diagnostics.watchには以下が含まれます。

- JMXWatchNotification、通知に関する追加情報を含む拡張JMX通知オブジェクトです。この情報は、getExtendedInfoメソッドから返される参照されたWatchNotificationオブジェクトに保持されます。

- WatchNotification、監視ルールの通知を定義します。

WLDFプログラミング:サンプル

以下のサンプルでは、WLDF Beanおよびパッケージを使用し、実行中のサーバーの情報にアクセスして変更します。

- サンプル: DiagnosticContextExample.java

- サンプル: HarvesterMonitor.java

- サンプル: JMXAccessorExample.java

また、付録D「WebLogic Scripting Toolのサンプル」のWLSTおよびJMXのサンプルも参照してください。

サンプル: DiagnosticContextExample.java

次のサンプルでは、weblogic.diagnostics.contextパッケージのDiagnosticContextHelperクラスを使用して、DYE_0フラグの値を取得および設定します。(診断コンテキストの詳細は、第12章「診断コンテキストを管理するためのDyeInjectionモニターの構成」を参照してください。)

このプログラムをコンパイルして実行するには:

1. DiagnosticContextExample.javaサンプル(例16-2)をディレクトリにコピーし、次のコマンドを使用してコンパイルします。

javac -d . DiagnosticContextExample.java

これにより、/weblogic/diagnostics/examplesディレクトリが作成され、その中にDiagnosticContextExample.classが格納されます。

2. プログラムを実行します。コマンドの構文は次のようになります。

java weblogic.diagnostics.examples.DiagnosticContextExample

サンプル出力は次のようになります。

# java weblogic.diagnostics.examples.DiagnosticContextExample
ContextId=5b7898f93bf010ce:40305614:1048582efd4:-8000-0000000000000001
isDyedWith(DYE_0)=false
isDyedWith(DYE_0)=true

例16-1 サンプル: 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("ContextId=" +
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));
}
}

サンプル: HarvesterMonitor.java

HarvesterMonitorプログラムでは、ハーベスタJMX通知を使用して、収集サイクルの発生を識別します。次に、アクセサを使用して新しい値を取得します。すべてのアクセスは、JMXを使用して実行します。次の項では、HarvesterMonitor.javaのコードを示す前に、通知リスナーについて説明します。

- 通知リスナー

- HarvesterMonitor.java

ハーベスタ・コンポーネントの詳細は、第7章「メトリック収集用のハーベスタの構成」を参照してください。

通知リスナー

通知リスナーでは、特定のトランスポート媒体に対応する実装が用意されています。たとえば、SMTP通知リスナーでは、メール・サーバーとのSMTP接続を確立し、そのSMTP通知リスナーが受信する通知インスタンスで電子メールをトリガーするメカニズムを利用できます。JMX、SNMP、JMSなどの種類のリスナーでも、それぞれに対応した実装があります。

注意:
SMTP、JMX、SNMP、またはJMS以外のトランスポート媒体を使用して、WebLogic診断フレームワークで生成されたイベントを伝播するプラグインを開発できます。1つの方法としては、JMX NotificationListenerインタフェースを使用してオブジェクトを実装し、選択したトランスポート媒体の要件に従って通知を伝播します。

表16-2に、WebLogic Serverで利用可能な各通知リスナーの種類、およびその種類に対応する構成を示します。

表16-2 通知リスナーの種類

通知媒体

説明

必要な構成パラメータ

JMS

JMS Messageキューまたはトピックを介して伝播。

必須:宛先のJNDI名。

省略可能:接続ファクトリのJNDI名(ない場合は、デフォルトJMS接続ファクトリを使用)。

JMX

標準JMX通知を介して伝播。

必須パラメータはなし。イベントのポストにはあらかじめ定義されたシングルトンを使用します。

SMTP

通常の電子メールを介して伝播。

必須: MailSession JNDI名とDestinationの電子メール。

省略可能:電子メールの件名と本文(指定しない場合は、デフォルトを使用)

SNMP

SNMPトラップおよびWebLogic Server SNMPエージェントを介して伝播。

必須パラメータはなし。ただし、WebLogic SNMPエージェントでSNMPTrapDestination MBeanを定義する必要があります。

デフォルトでは、監視ルールから起動したすべての通知は、構成された媒体を介して起動されるとともに、サーバー・ログ・ファイルに格納されます。

HarvesterMonitor.java

HarvesterMonitorプログラムをコンパイルして実行するには:

1. HarvesterMonitor.javaサンプル(例16-2)をディレクトリにコピーし、次のコマンドを使用してコンパイルします。

javac -d . HarvesterMonitor.java

これにより、/weblogic/diagnostics/examplesディレクトリが作成され、その中にHarvesterMonitor.classおよびHarvesterMonitor$HarvestCycleHandler.classが格納されます。

2. モニターを開始します。コマンドの構文は次のようになります。

java HarvesterMonitor <server> <port> <uname> <pw> [<types>]

WebLogic Serverインスタンスにアクセスし、サーバーの名前、ポート番号、管理者のログイン名、および管理者のパスワードを調べる必要があります。

収集される型名のリストを指定することもできます。指定した場合、プログラムを実行するとそれらの型の値のみが表示されます。ただし、選択したそれぞれの型について収集した値がすべて表示されます。表示される値を制約する方法は提供されていません。

収集が明示的に構成された値のみが表示されます。監視ルールをサポートするためだけに収集された値(暗黙的な値)は表示されません。

次のコマンドでは、CLASSPATH変数に「.」を含める必要があります。また、このコマンドは、プログラムをコンパイルしたディレクトリから実行する必要があります。このコマンドを実行すると、ポート7001、ユーザーweblogic、パスワードweblogicでmyserverサーバーに接続されます。

java weblogic.diagnostics.examples.HarvesterMonitor myserver 7001
weblogic weblogic

HarvesterMonitorからの出力のサンプルについては、例16-3を参照してください。

例16-2 サンプル: HarvesterMonitor.java

package weblogic.diagnostics.examples;
import weblogic.management.mbeanservers.runtime.RuntimeServiceMBean;
import javax.management.*;
import javax.management.remote.*;
import javax.naming.Context;
import java.util.*;
public class HarvesterMonitor {

private static String accessorRuntimeMBeanName;
private static ObjectName accessorRuntimeMBeanObjectName;
private static String harvRuntimeMBeanName;
private static ObjectName harvRuntimeMBeanObjectName;
private static MBeanServerConnection rmbs;
private static ObjectName getObjectName(String objectNameStr) {
try { return new ObjectName(getCanonicalName(objectNameStr)); }
catch (RuntimeException x) { throw x; }
catch (Exception x) { x.printStackTrace(); throw new
RuntimeException(x); }
}
private static String getCanonicalName(String objectNameStr) {
try { return new ObjectName(objectNameStr).getCanonicalName(); }
catch (RuntimeException x) { throw x; }
catch (Exception x) { x.printStackTrace(); throw new
RuntimeException(x); }
}
private static String serverName;
private static int port;
private static String userName;
private static String password;
private static ArrayList typesToMonitor = null;
public static void main(String[] args) throws Exception {
if (args.length < 4) {
System.out.println(
"Usage: java weblogic.diagnostics.harvester.HarvesterMonitor " +
"<serverName> <port> <userName> <password> [<types>]" +
weblogic.utils.PlatformConstants.EOL +
"   where <types> (optional) is a comma-separated list " +
"of types to monitor.");
System.exit(1);
}
serverName = args[0];
port = Integer.parseInt(args[1]);
userName = args[2];
password = args[3];
accessorRuntimeMBeanName = getCanonicalName(
"com.bea:ServerRuntime=" + serverName +
",Name=HarvestedDataArchive,Type=WLDFDataAccessRuntime" +
",WLDFAccessRuntime=Accessor,WLDFRuntime=WLDFRuntime");
accessorRuntimeMBeanObjectName =
getObjectName(accessorRuntimeMBeanName);
harvRuntimeMBeanName = getCanonicalName(
"com.bea:ServerRuntime=" + serverName +
",Name=WLDFHarvesterRuntime,Type=WLDFHarvesterRuntime" +
",WLDFRuntime=WLDFRuntime");
harvRuntimeMBeanObjectName = getObjectName(harvRuntimeMBeanName);
if (args.length > 4) {
String typesStr = args[4];
typesToMonitor = new ArrayList();
int index;
while ((index = typesStr.indexOf(",")) > 0) {
String typeName = typesStr.substring(0,index).trim();
typesToMonitor.add(typeName);
typesStr = typesStr.substring(index+1);
}
typesToMonitor.add(typesStr.trim());
}
rmbs = getRuntimeMBeanServerConnection();
new HarvesterMonitor().new HarvestCycleHandler();
while(true) {Thread.sleep(100000);}
}
static protected String JNDI = "/jndi/";
static public MBeanServerConnection getRuntimeMBeanServerConnection()
throws Exception {
JMXServiceURL serviceURL;
serviceURL =
new JMXServiceURL("t3",
"localhost",
port,
JNDI + RuntimeServiceMBean.MBEANSERVER_JNDI_NAME);
System.out.println("ServerName=" + serverName);
System.out.println("URL=" + serviceURL);
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL, userName);
h.put(Context.SECURITY_CREDENTIALS, password);
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"weblogic.management.remote");
JMXConnector connector = JMXConnectorFactory.connect(serviceURL,h);
return connector.getMBeanServerConnection();
}
class HarvestCycleHandler implements NotificationListener {
// used to track harvest cycles
private int timestampIndex;
private int domainIndex;
private int serverIndex;
private int typeIndex;
private int instNameIndex;
private int attrNameIndex;
private int attrTypeIndex;
private int attrValueIndex;
long lastSampleTime = System.currentTimeMillis();
HarvestCycleHandler() throws Exception{
System.out.println("Harvester monitor started...");
try {
setUpRecordIndices();
rmbs.addNotificationListener(harvRuntimeMBeanObjectName,
this, null, null);
}
catch (javax.management.InstanceNotFoundException x) {
System.out.println("Cannot find JMX data. " +
"Is the server name correct?");
System.exit(1);
}
}
private void setUpRecordIndices() throws Exception {
Map columnIndexMap = (Map)rmbs.getAttribute(
accessorRuntimeMBeanObjectName, "ColumnIndexMap");
timestampIndex =              ((Integer)columnIndexMap.get("TIMESTAMP")).intValue();
domainIndex =
((Integer)columnIndexMap.get("DOMAIN")).intValue();
serverIndex =
((Integer)columnIndexMap.get("SERVER")).intValue();
typeIndex =
((Integer)columnIndexMap.get("TYPE")).intValue();
instNameIndex =
((Integer)columnIndexMap.get("NAME")).intValue();
attrNameIndex =
((Integer)columnIndexMap.get("ATTRNAME")).intValue();
attrTypeIndex =
((Integer)columnIndexMap.get("ATTRTYPE")).intValue();
attrValueIndex =              ((Integer)columnIndexMap.get("ATTRVALUE")).intValue();
}
public synchronized void handleNotification(Notification notification,
Object handback) {
System.out.println("\n------------------------------------------");
long thisSampleTime = System.currentTimeMillis()+1;
try {
String lastTypeName = null;
String lastInstName = null;
String cursor = (String)rmbs.invoke(accessorRuntimeMBeanObjectName,
"openCursor",
new Object[]{new Long(lastSampleTime),
new Long(thisSampleTime), null},
new String[]{ "java.lang.Long",
"java.lang.Long", "java.lang.String" } );
while (((Boolean)rmbs.invoke(accessorRuntimeMBeanObjectName,
"hasMoreData",
new Object[]{cursor},
new String[]{"java.lang.String"})).booleanValue()) {
Object[] os = (Object[])rmbs.invoke(accessorRuntimeMBeanObjectName,
"fetch",
new Object[]{cursor},
new String[]{"java.lang.String"});
for (int i = 0; i < os.length; i++) {
Object[] values = (Object[])os[i];
String typeName = (String)values[typeIndex];
String instName = (String)values[instNameIndex];
String attrName = (String)values[attrNameIndex];
if (!typeName.equals(lastTypeName)) {
if (typesToMonitor != null &&
!typesToMonitor.contains(typeName)) continue;
System.out.println("\nType " + typeName);
lastTypeName = typeName;
}
if (!instName.equals(lastInstName)) {
System.out.println("\n  Instance " + instName);
lastInstName = instName;
}
Object attrValue = values[attrValueIndex];
System.out.println("    - " + attrName + "=" + attrValue);
}
}
lastSampleTime = thisSampleTime;
}
catch (Exception e) {e.printStackTrace();}
}
}
}

例16-3に、HarvesterMonitorプログラムからの出力のサンプルを示します。

例16-3 HarvesterMonitorからのサンプル出力

ServerName=myserver
URL=service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
Harvester monitor started...
------------------------------------------------------
Type weblogic.management.runtime.WLDFHarvesterRuntimeMBean
Instance com.bea:Name=WLDFHarvesterRuntime,ServerRuntime=myserver,Type=WLDFHarvesterRuntime,WLDFRuntime=WLDFRuntime
- TotalSamplingTime=202048863
- CurrentSnapshotElapsedTime=1839619
Type weblogic.management.runtime.ServerRuntimeMBean
Instance com.bea:Name=myserver,Type=ServerRuntime
- RestartRequired=false
- ListenPortEnabled=true
- ActivationTime=1118319317071
- ServerStartupTime=40671
- ServerClasspath= [deleted long classpath listing]
- CurrentMachine=
- SocketsOpenedTotalCount=1
- State=RUNNING
- RestartsTotalCount=0
- AdminServer=true
- AdminServerListenPort=7001
- ClusterMaster=false
- StateVal=2
- CurrentDirectory=C:\testdomain\.
- AdminServerHost=10.40.8.123
- OpenSocketsCurrentCount=1
- ShuttingDown=false
- SSLListenPortEnabled=false
- AdministrationPortEnabled=false
- AdminServerListenPortSecure=false
- Registered=true

サンプル: JMXAccessorExample.java

次のサンプルでは、JMXを使用してログ・エントリを標準出力します。すべてのアクセスは、JMXを使用して実行します。(アクセサ・コンポーネントの詳細は、第13章「データ・アクセサを使用した診断データへのアクセス」を参照してください。)

このプログラムをコンパイルして実行するには:

1. JMXAccessorExample.javaの例(例16-4)をディレクトリにコピーし、次のコマンドを使用してコンパイルします。

javac -d . JMXAccessorExample.java

これにより、/weblogic/diagnostics/examplesディレクトリが作成され、その中にJMXAccessorExample.classが格納されます。

2. プログラムを実行します。コマンドの構文は次のようになります。

java weblogic.diagnostics.example.JMXAccessor <logicalName> <query>

WebLogic Serverインスタンスにアクセスし、サーバーの名前、ポート番号、管理者のログイン名、および管理者のパスワードを調べる必要があります。

logicalNameはログの名前です。有効な名前は、HarvestedDataArchive、EventsDataArchive、ServerLog、DomainLog、HTTPAccessLog、ServletAccessorHelper.WEBAPP_LOG、RAUtil.CONNECTOR_LOG、JMSMessageLog、およびCUSTOMです。

問合せは、付録A「WLDF問合せ言語」で説明する構文を使用して作成されます。JMXAccessorExampleプログラムでは、空のquery (空の二重引用符のペア、"")を指定すると、ログ内のすべてのエントリが返されます。

次のコマンドでは、CLASSPATH変数に「.」を含める必要があります。また、このコマンドは、プログラムをコンパイルしたディレクトリから実行する必要があります。プログラムでは、IIOP (Internet Inter-ORB Protocol)プロトコルを使用して、ユーザーweblogic、パスワードweblogicでポート7001に接続し、ServerLogログ内のすべてのエントリを標準出力に出力します。

java weblogic.diagnostics.examples.JMXAccessorExample ServerLog ""

このサンプルは、適切なユーザー名とパスワードを使用するように変更できます。

例16-4 JMXAccessorExample.java

package weblogic.diagnostics.examples;
import java.io.IOException;
import java.net.MalformedURLException;
import java.util.Hashtable;
import java.util.Iterator;
import javax.management.MBeanServerConnection;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;
public class JMXAccessorExample {
private static final String JNDI = "/jndi/";
public static void main(String[] args) {
try {
if (args.length != 2) {
System.err.println("Incorrect invocation. Correct usage is:\n" +
"java weblogic.diagnostics.examples.JMXAccessorExample " +
"<logicalName> <query>");
System.exit(1);
}
String logicalName = args[0];
String query = args[1];
MBeanServerConnection mbeanServerConnection =
lookupMBeanServerConnection();
ObjectName service = new
ObjectName(weblogic.management.mbeanservers.runtime.RuntimeServiceMBean.OBJECT_NAME);
ObjectName serverRuntime =
(ObjectName) mbeanServerConnection.getAttribute(service,
"ServerRuntime");
ObjectName wldfRuntime =
(ObjectName) mbeanServerConnection.getAttribute(serverRuntime,
"WLDFRuntime");
ObjectName wldfAccessRuntime =
(ObjectName) mbeanServerConnection.getAttribute(wldfRuntime,
"WLDFAccessRuntime");
ObjectName wldfDataAccessRuntime =
(ObjectName) mbeanServerConnection.invoke(wldfAccessRuntime,
"lookupWLDFDataAccessRuntime", new Object[] {logicalName},
new String[] {"java.lang.String"});
String cursor =
(String) mbeanServerConnection.invoke(wldfDataAccessRuntime,
"openCursor", new Object[] {query},
new String[] {"java.lang.String"});
int fetchedCount = 0;
do {
Object[] rows =
(Object[]) mbeanServerConnection.invoke(wldfDataAccessRuntime,
"fetch", new Object[] {cursor},
new String[] {"java.lang.String"});
fetchedCount = rows.length;
for (int i=0; i<rows.length; i++) {
StringBuffer sb = new StringBuffer();
Object[] cols = (Object[]) rows[i];
for (int j=0; j<cols.length; j++) {
sb.append("Index " + j + "=" + cols[j].toString() + " ");
}
System.out.println("Found row = " + sb.toString());
}
} while (fetchedCount > 0);
mbeanServerConnection.invoke(wldfDataAccessRuntime,
"closeCursor", new Object[] {cursor},
new String[] {"java.lang.String"});
} catch(Throwable th) {
th.printStackTrace();
System.exit(1);
}
}
private static MBeanServerConnection lookupMBeanServerConnection ()
throws Exception {
// construct JMX service URL
JMXServiceURL serviceURL;
serviceURL = new JMXServiceURL("iiop", "localhost", 7001,
JNDI + "weblogic.management.mbeanservers.runtime");
// Specify the user, password, and WebLogic provider package
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL,"weblogic");
h.put(Context.SECURITY_CREDENTIALS,"weblogic");
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"weblogic.management.remote");
// Get jmx connector
JMXConnector connector = JMXConnectorFactory.connect(serviceURL,h);
// return MBean server connection class
return connector.getMBeanServerConnection();
} // End - lookupMBeanServerConnection
}

A WLDF問合せ言語

WLDFには、監視ルール式、データ・アクセサ問合せ式、およびログ・フィルタ式を作成するための問合せ言語が含まれています。問合せ言語の構文は、SQL構文の一部を簡略化したものです。

次の項では、この問合せ言語について説明します。

- 問合せ式の構成要素

- サポートされる演算子

- 演算子の優先順位

- String型の列でサポートされる数値の比較演算

- サポートされる数値定数と文字列リテラル

- 監視ルール式の作成

- データ・アクセサ問合せの作成

- ログ・フィルタ式の作成

- 複雑な式の作成

問合せ式の構成要素

問合せ式には以下のものを含めることができます。

- 演算子。(「サポートされる演算子」を参照してください)

- リテラル。(「サポートされる数値定数と文字列リテラル」を参照してください)

- 変数。サポートされる変数は、式の種類ごとに異なります(「式内の変数について」を参照してください)。

問合せ言語では、大文字と小文字は区別されます。

サポートされる演算子

問合せ言語は表A-1に記載されたオペレータをサポートします。

表A-1 WLDF問合せ言語の演算子

演算子

演算子の種類

サポートされるオペランドの種類

定義

AND

論理二項

ブール

両方の式がtrueのときtrueと評価されます。

OR

論理二項

ブール

どちらかの式がtrueのときtrueと評価されます。

NOT

論理単項

ブール

式がtrueでないときtrueと評価されます。

&

ビット二項

数値

仕分けフラグ

各オペランドの同じ位置のビットのペアに対して、ビット単位のAND関数を実行します。両方のオペランドのビットが 1の場合、&関数の演算結果として1が設定されます。それ以外の場合、演算結果は0に設定されます。

&演算子と|演算子の例を以下に示します。

1010 & 0010 = 0010

1010 | 0001 = 1011

( 1010 & ( 1100 | 1101 )) = 1000

|

ビット二項

数値

仕分けフラグ

各オペランドのそれぞれの平行な組のビットでのビット単位のOR機能を実行します。いずれかのオペランド・ビットが1である場合、|関数は演算結果のビットが1設定します。それ以外の場合、演算結果は0に設定されます。

例に関して、上のbitwise &演算子のエントリを参照してください。

=

比較

数値、文字列

等しい

!=

比較

数値

等しくない

<

比較

数値

より小さい

>

比較

数値

より大きい

<=

比較

数値

以下

>=

比較

数値

以上

LIKE

一致

文字列

文字列が指定したパターン(ワイルドカード使用可)に一致するときにtrueと評価されます。

LIKEは2つのワイルド・カード・キャラクタをサポートします。

パーセント記号(%)はゼロのどんなストリングか、より多くのキャラクタにも合っています。

ピリオド(.)は単一の文字に一致します。

MATCHES

一致

文字列

対象の文字列がオペランドStringの正規表現パターンに一致するときにtrueと評価されます。

IN

検索

文字列

変数の値があらかじめ定義されたセット内に存在するときにtrueと評価されます - 例:

SUBSYSTEM IN ('A','B')

演算子の優先順位

以下に、演算子間の優先順位のレベルを、高いものから順に示します。同じ行に示す演算子は、すべて同等の優先順位です。

1. ( )

2. NOT

3. &, |

4. =, !=, <, >, <=, >=, LIKE, MATCHES,IN

5. AND

6. OR

String型の列でサポートされる数値の比較演算

String型列のデータが数値である場合、列で数値の比較演算を実行できます。たとえば、STATUSがString型である場合、数値オペランドとの比較演算が行われている間は、列の値は数値として扱われます。たとえば、以下の比較を考えます。

STATUS = 100

STATUS != 100

STATUS < 100

STATUS <= 100

STATUS > 100

STATUS >= 100

上記のような比較では、問合せ評価にあたって、比較前に文字列値の適切な数値への変換が試みられます。文字列値を数値に変換できない場合、問合せは失敗します。

サポートされる数値定数と文字列リテラル

数値定数のルールは以下のとおりです。

- 数値リテラルとしては、整数または浮動小数点数を使用できます。

- 数値リテラルは、Javaの場合と同じように指定します。数値リテラルの例としては、2、2.0、12.856f、2.1934E-4、123456L、2.0Dなどを挙げることができます。

文字列リテラルのルールは以下のとおりです。

- 文字列リテラルは、一重引用符で囲む必要があります。

- 文字列リテラル内では、ワイルドカードとしてパーセント文字(%)を使用できます。

- アンダースコア文字(_)は、任意の1文字を表すワイルドカードとして使用できます。

- バックスラッシュ文字(\)は、引用符(')やパーセント文字(%)などの特殊文字をエスケープするために使用できます。

- 監視ルール式では、比較演算子を使用して、文字列、整数、Long、Double、ブールの各リテラルのしきい値を指定できます。

- 関係演算子は、文字列の字句を比較します。詳細は、java.lang.String.compareTo(String str)メソッドに関するドキュメントを参照してください。

式内の変数について

変数は、実行時に評価される問合せ式の動的な部分を表します。次の項の説明に従って、作成する式の種類に合った適切な変数を使用する必要があります。

- 監視ルール式の作成

- データ・アクセサ問合せの作成

- ログ・フィルタ式の作成

監視ルール式の作成

監視は、ログ・イベント、インストゥルメンテーション・イベント、および収集された属性に基づいて作成できます。式の作成でサポートされる変数は、監視の種類ごとに異なります。次の項を参照してください。

- ログ・イベントの監視ルール式の作成

- インストゥルメンテーション・イベントの監視ルール式の作成

- ハーベスタの監視ルール式の作成

WLDF監視の構成および使い方の詳細は、次を参照してください。

- 第8章「監視および通知の構成」

- 第9章「監視の構成」

ログ・イベントの監視ルール式の作成

ログ・イベントの監視ルール式は、サーバー・ログからのログ・メッセージの属性に基づいています。

表A-2では、ログ・メッセージ属性の変数名について説明します。

表A-2 ログ・イベントの監視ルール式の変数名

変数

説明

データ型

CONTEXTID

リクエストと一緒に伝播されるリクエストID。

文字列

DATE

ログ・メッセージが作成されたときの日付。

文字列

MACHINE

ログ・メッセージを生成したマシンの名前。

文字列

MESSAGE

ログ・メッセージのメッセージ・コンテンツ。

文字列

MSGID

ログ・メッセージのID (通常、「BEA=」で始まります)。

文字列

RECORDID

ログ内のレコードの数。

Long

SERVER

ログ・メッセージを生成したサーバーの名前。

文字列

SEVERITY

ログ・メッセージ属性の重大度。値は、ALERT、CRITICAL、DEBUG、EMERGENCY、ERROR、INFO、NOTICE、OFF、TRACE、およびWARNING。

文字列

SUBSYTEM

ログ・メッセージを送信するサブシステムの名前。

文字列

THREAD

ログ・メッセージを生成したスレッドの名前。

文字列

TIMESTAMP

ログ・メッセージが作成されたときのタイムスタンプ。

Long

TXID

ログ・メッセージを生成したスレッドのJTAトランザクションID。

文字列

USERID

ログ・メッセージを生成したユーザーのID。

文字列

次に、ログ・イベントの監視ルール式の例を示します。

(SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')

インストゥルメンテーション・イベントの監視ルール式の作成

インストゥルメンテーション・イベントの監視ルール式は、診断モニター・アクションによって作成されたデータ・レコードの属性に基づきます。

表A-3では、インストゥルメンテーション・データ・レコード属性の変数名について説明します。

表A-3 インストゥルメンテーション・イベントのルール式の変数名

変数

説明

データ型

ARGUMENTS

呼び出されたメソッドに渡される引数。

文字列

CLASSNAME

ジョインポイントのクラス名。

文字列

CONTEXTID

インストゥルメンテーション・イベントの診断コンテキストID。

文字列

CTXPAYLOAD

このリクエストに関連付けられたコンテキスト・ペイロード。

文字列

DOMAIN

ドメインの名前。

文字列

DYES

このリクエストに関連付けられた仕分け。

Long

FILENAME

ソース・ファイル名。

文字列

LINENUM

ソース・ファイルの行番号。

整数

METHODNAME

ジョインポイントのメソッド名。

文字列

METHODDSC

ジョインポイントのメソッドの引数。

文字列

MODULE

診断モジュールの名前。

文字列

MONITOR

モニターの名前。

文字列

PAYLOAD

インストゥルメンテーション・イベントのペイロード。

文字列

RECORDID

ログ内のレコードの数。

Long

RETVAL

ジョインポイントの戻り値。

文字列

SCOPE

インストゥルメンテーション・スコープの名前。

文字列

SERVER

インストゥルメンテーション・イベントを作成したサーバーの名前。

文字列

TIMESTAMP

インストゥルメンテーション・イベントが作成されたときのタイムスタンプ。

Long

TXID

インストゥルメンテーション・イベントを作成したスレッドのJTAトランザクションID。

文字列

TYPE

モニターの種類。

文字列

USERID

インストゥルメンテーション・イベントを作成したユーザーのID。

文字列

次に、インストゥルメンテーション・イベント・データのルール式の例を示します。

(USERID = 'weblogic')

ハーベスタの監視ルール式の作成

ハーベスタの監視ルール式は、収集可能な1つまたは複数のMBean属性に基づきます。式では、MBean型、インスタンス、および属性を指定できます。

インスタンス・ベースの式および型ベースの式には、オプションのネームスペース・コンポーネントを含められます。このコンポーネントは、監視対象メトリックのネームスペースです。これは、ServerRuntimeまたはDomainRuntimeに設定できます。指定しない場合のデフォルト値はServerRuntimeです。

DomainRuntimeに含められていて、設定される場合、用法をServerLifeCycleRuntimeMBeanなどのDomainRuntime特有のMBeansだけをモニターするのに制限する必要があります。リモートの管理対象サーバーMBeanもDomainRuntime MBeanServerを介してモニターできますが、パフォーマンスに影響するため推奨されません。ベスト・プラクティスは、各管理対象サーバーで常駐ウォッチャを使用し、その管理対象サーバー・インスタンスに関連するメトリックをモニターすることです。

ハーベスタの監視ルール式でインスタンス名にワイルドカードを使用したり、複合属性を指定することもできます。付録C「式でのワイルドカードの使用」を参照してください。

ハーベスタの監視ルール式を作成するための構文は次のとおりです。

- 1つの型のすべてのインスタンスの1つの属性を指定するには、次の構文を使用します。

${namespace//[type_name]//attribute_name}

- 1つのWebLogic型の1つのインスタンスの1つの属性を指定するには、次の構文を使用します。

${com.bea:namespace//instance_name//attribute_name}

- 1つのカスタムMBean型の1つのインスタンスの1つの属性を指定するには、次の構文を使用します。

${domain_name:instance_name//attribute_name}

注意:
WebLogic Serverドメイン名の場合はdomain_nameは必要ありません。

式には、次の例に示すように、MBeanオブジェクトの完全な名前を指定する必要があります。

${com.bea:Name=HarvesterRuntime,Location=myserver,Type=HarvesterRuntime,
ServerRuntime=myserver//TotalSamplingCycles} > 10

データ・アクセサ問合せの作成

データ・アクセサ・コンポーネントでWLDF問合せ言語を使用すると、サーバー・ログ、HTTPログ、収集されたメトリックなどのデータをデータ・ストアから取り出すことができます。データ・アクセサ問合せの作成に使用する変数は、データの抽出元となるデータ・ストアの列名に基づいています。

データ・アクセサ問合せには以下が含まれます。

- データ・ストアの論理名。「データ・ストアの論理名」を参照してください。

- データを取得する1つまたは複数の列の名前(オプション)。「データ・ストアの列名」を参照してください。

一致するデータがあると、一致した行のすべての列が返されます。

データ・ストアの論理名

データ・ストアの論理名は、一意のものである必要があります。論理名によって示されるのは、サーバー上で利用可能な特定のデータ・ストアです。論理名は、ログの種類を表すキーワードと、フォワード・スラッシュ(/)デリミタで区切られた0個以上の識別子で構成されます。たとえば、サーバー・ログ・データ・ストアの論理名は単純にServerLogとなります。しかし、他の種類のログの場合は、表A-4に示すように追加の識別子が必要になることがあります。

表A-4 ログの種類のネーミング・ルール

ログの種類

省略可能な識別子

例

ConnectorLog

接続ファクトリのJNDI名

ConnectorLog/eis/ 900eisaBlackBoxXATxConnectorJNDINAME

説明:

eis/900eisaBlackBoxXATxConnectorJNDINAME

は、weblogic-ra.xmlデプロイメント記述子で指定された接続ファクトリのJNDI名。

DomainLog

なし

DomainLog

EventsDataArchive

なし

EventsDataArchive

HarvestedDataArchive

なし

HarvestedDataArchive

HTTPAccessLog

仮想ホスト名

HTTPAccessLog - デフォルトのWebサーバーのアクセス・ログ。

HTTPAccessLog/MyVirtualHost - 現在のサーバーにデプロイされているMyVirtualHostという仮想ホスト

注意: HTTPAccessLogの拡張フォーマットでは、列数をユーザーが定義できます。

JMSMessageLog

JMSサーバーの名前

JMSMessageLog/MyJMSServer

ServerLog

なし

ServerLog

WebAppLog

Webサーバー名+ルート・サーブレットのコンテキスト名

WebAppLog/MyWebServer/MyRootServletContext

データ・ストアの列名

問合せに含まれる列名は、データの行ごとに解決されます。結果セットに行が追加されるのは、指定したすべての列についてその行が問合せ条件を満たしたときだけです。問合せで列名を省略した場合、ログのすべてのエントリが返されます。

表A-5に、WebLogic Serverの全種類のログの列名をすべて示します。

表A-5 ログの種類の列名

ログの種類

列名

ConnectorLog

LINE、RECORDID

DomainLog

CONTEXTID、DATE、MACHINE、MESSAGE、MSGID、RECORDID、SERVER、SEVERITY、SUBSYSTEM、THREAD、TIMESTAMP、TXID、USERID

EventsDataArchive

ARGUMENTS、CLASSNAME、CONTEXTID、CTXPAYLOAD、DOMAIN、DYES、FILENAME、LINENUM、METHODNAME、METHODDSC、MODULE、MONITOR、PAYLOAD、RECORDID、RETVAL、SCOPE、SERVER、THREADNAME、TIMESTAMP、TXID、TYPE、USERID

HarvestedDataArchive

ATTRNAME、ATTRTYPE、ATTRVALUE、DOMAIN、NAME、RECORDID、SERVER、TIMESTAMP、TYPE

HTTPAccessLog

AUTHUSER、BYTECOUNT、HOST、RECORDID、REMOTEUSER、REQUEST、STATUS、TIMESTAMP

JDBCLog

DomainLogと同じ

JMSMessageLog

CONTEXTID、DATE、DESTINATION、EVENT、JMSCORRELATIONID、JMSMESSAGEID、MESSAGE、MESSAGECONSUMER、NANOTIMESTAMP、RECORDID、SELECTOR、TIMESTAMP、TXID、USERID

ServerLog

DomainLogと同じ

WebAppLog

DomainLogと同じ

次に、データ・アクセサ問合せの例を示します。

(SUBSYSTEM = 'Deployer') AND (MESSAGE LIKE '%Failed%')

この例の場合、アクセサはDeployerサブシステムから「Failed」という文字列を含むすべてのメッセージを取得します。

次の例では、APIメソッドの呼出しを示します。この例には、timeStampFrom (その時間を含む)からtimeStampTo (その時間を含まない)の間隔内での、MyPoolというJDBC接続プールの収集された属性の問合せが含まれています。

WLDFDataAccessRuntimeMBean.retrieveDataRecords(timeStampFrom,
timeStampTo, "TYPE='JDBCConnectionPoolRuntime' AND NAME='MyPool'")

WLDFデータ・アクセサの詳細は、第13章「データ・アクセサを使用した診断データへのアクセス」を参照してください。

ログ・フィルタ式の作成

問合せ言語を使用すると、サーバー・ログに書き込まれたログをフィルタ処理できます。ログ・フィルタ式の作成に使用する変数は、ログの列を表します。

- CONTEXTID

- DATE

- MACHINE

- MESSAGE

- MSGID

- RECORDID

- SEVERITY

- SUBSYSTEM

- SERVER

- THREAD

- TIMESTAMP

- TXID

- USERID

注意:
これらの変数は、既存のサーバー・ログから診断データの履歴を取得するデータ・アクセサ問合せの作成に使用する変数と同じです。

WebLogic Serverロギング・サービスの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のWebLogic Serverログ・メッセージのフィルタ処理に関する項を参照してください。

複雑な式の作成

変数、バイナリ比較、その他の複雑なサブ式を含む、サブ式を使用した複雑な問合せ式を作成できます。ネストのレベルに制限はありません。以下のルールが適用されます。

- 次のようにサブ式をカッコで囲んで、問合せをネストすることができます。

(SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')

- MBeanオブジェクト名の場合と同じように、特殊な文字が含まれる場合は変数名を${}で囲むことができます。例:

${mydomain:Name=myserver,
Type=ServerRuntime//SocketsOpenedTotalCount} >= 1

監視の変数名では、オブジェクト名と属性名が「//」で区切られます。

B WLDFインストゥルメンテーション・ライブラリ

WebLogic診断フレームワークのインストゥルメンテーション・ライブラリには診断モニターと診断アクションが含まれています。次の項は、これらのライブラリについて説明します。

- 診断モニター・ライブラリ

- 診断アクション・ライブラリ

インストゥルメンテーション・ライブラリの項目の使用方法は、第11章「インストゥルメンテーションの構成」を参照してください。

診断モニター・ライブラリ

診断モニターは、サーバー・スコープのモニターとアプリケーション・スコープのモニターに大別されます。サーバー・スコープのモニターはWebLogic Serverクラスのインストゥルメントに使用できます。アプリケーション・スコープのモニターはアプリケーション・クラスのインストゥルメントに使用します。DyeInjectionモニターを除くすべてのモニターは委任モニターで、組込みの診断アクションがありません。代わりに、モニターにアタッチされているアクションに委任して、診断アクティビティを実行します。

すべてのモニターには、それぞれのポイントカットがあらかじめ構成されています。ただし、その作用を受ける実際の場所はインストゥルメントされるクラスによって異なります。たとえば、Servlet_Before_Serviceモニターでは、様々なサーブレット実装のいろいろな場所にあるサーブレットまたはJava Server Page (JSP)サービス・メソッドの入口に診断コードが追加されます。

すべての委任モニターには、対応するアクションのみをアタッチできます。対応するかどうかはモニターの性質によって決まります。

次の表では、サーバー・スコープ(WebLogic Serverクラス)内で使用できる診断モニターをリストして説明します。各モニターに対応する診断アクションについては、表の対応アクション・タイプ列を参照してください。

表B-1 サーバー・スコープ内で使用する診断モニター

モニター名

モニター・タイプ

対応アクション・タイプ

ポイントカット

Connector_Before_Inbound

前

ステートレス

着信接続を処理するメソッドの入口。

Connector_After_Inbound

サーバー

ステートレス

着信接続を処理するメソッドの出口。

Connector_Around_Inbound

前後

前後

着信接続を処理するメソッドの入口と出口。

Connector_Before_Outbound

前

ステートレス

発信接続を処理するメソッドの入口。

Connector_After_Outbound

後

ステートレス

発信接続を処理するメソッドの出口。

Connector_Around_Outbound

前後

前後

発信接続を処理するメソッドの入口と出口。

Connector_Before_Tx

前

ステートレス

トランザクションの登録、登録解除、開始、ロールバック、コミットを行うメソッドの入口。

Connector_After_Tx

後

ステートレス

トランザクションの登録、登録解除、開始、ロールバック、コミットを行うメソッドの出口。

Connector_Around_Tx

前後

前後

トランザクションの登録、登録解除、開始、ロールバック、コミットを行うメソッドの入口と出口。

Connector_Before_Work

前

ステートレス

コネクタの作業項目のスケジューリング、開始、実行に関するメソッドの入口。

Connector_After_Work

後

ステートレス

コネクタの作業項目のスケジューリング、開始、実行に関するメソッドの出口。

Connector_Around_Work

前後

前後

コネクタの作業項目のスケジューリング、開始、実行に関するメソッドの入口と出口。

DyeInjection

前

組込み

リクエストがサーバーに届く場所。

JDBC_Before_Commit_Internal

前

ステートレス

JDBCサブシステムの内部コード。

JDBC_After_Commit_Internal

後

ステートレス

JDBCサブシステムの内部コード。

JDBC_Before_Connection_

Internal

前

ステートレス

以下のメソッドの呼出しの前。

Driver.connect

DataSource.getConnection

JDBC_After_Connection_Internal

前

ステートレス

JDBCサブシステムの内部コード。

JDBC_Before_Rollback_Internal

前

ステートレス

JDBCサブシステムの内部コード。

JDBC_After_Rollback_Internal

後

ステートレス

JDBCサブシステムの内部コード。

JDBC_Before_Start_Internal

前

ステートレス

JDBCサブシステムの内部コード。

JDBC_After_Start_Internal

後

ステートレス

JDBCサブシステムの内部コード。

JDBC_Before_Statement_

Internal

前

ステートレス

JDBCサブシステムの内部コード。

JDBC_After_Statement_

Internal

後

ステートレス

JDBCサブシステムの内部コード。

JDBC_After_Reserve_Connection_Internal

後

ステートレス

JDBC接続が接続プールから控えられるとき。

JDBC_After_Release_Connection_Internal

後

ステートレス

JDBC接続が接続接続プールに解放された後。

表B-2はアプリケーション・スコープ(デプロイ済アプリケーション)内で使用できる診断モニターをリストします。各モニターに対応する診断アクションについては、表の対応アクション・タイプ列を参照してください。

表B-2 アプリケーション・スコープ内で使用する診断モニター

モニター名

モニター・タイプ

対応アクション・タイプ

ポイントカット

EJB_After_EntityEjbBusiness Methods

後

ステートレス

すべてのEntityBeanメソッドの出口。これは標準のEJBメソッドではありません。

EJB_Around_EntityEjbBusinessMethods

前後

前後

すべてのEntityBeanメソッドの入口と出口。これは標準のEJBメソッドではありません。

EJB_After_EntityEjbMethods

後

ステートレス

以下のメソッドの出口。

EnitityBean.setEntityContext

EnitityBean.unsetEntityContext

EnitityBean.ejbRemove

EnitityBean.ejbActivate

EnitityBean.ejbPassivate

EnitityBean.ejbLoad

EnitityBean.ejbStore

EJB_Around_EntityEjbMethods

前後

前後

以下のメソッドの出口。

EnitityBean.setEntityContext

EnitityBean.unsetEntityContext

EnitityBean.ejbRemove

EnitityBean.ejbActivate

EnitityBean.ejbPassivate

EnitityBean.ejbLoad

EnitityBean.ejbStore

EJB_After_EntityEjbSemantic Methods

後

ステートレス

以下のメソッドの出口。

EnitityBean.set*

EnitityBean.get*

EnitityBean.ejbFind*

EnitityBean.ejbHome*

EnitityBean.ejbSelect*

EnitityBean.ejbCreate*

EnitityBean.ejbPostCreate*

EJB_Around_EntityEjbSemanticMethods

前後

前後

以下のメソッドの入口と出口。

EnitityBean.set*

EnitityBean.get*

EnitityBean.ejbFind*

EnitityBean.ejbHome*

EnitityBean.ejbSelect*

EnitityBean.ejbCreate*

EnitityBean.ejbPostCreate*

EJB_After_SessionEjbMethods

後

ステートレス

以下のメソッドの出口。

SessionBean.setSessionContext

SessionBean.ejbRemove

SessionBean.ejbActivate

SessionBean.ejbPassivate

EJB_Around_SessionEjbMethods

前後

前後

以下のメソッドの入口と出口。

SessionBean.setSessionContext

SessionBean.ejbRemove

SessionBean.ejbActivate

SessionBean.ejbPassivate

EJB_After_SessionEjbBusinessMethods

後

ステートレス

すべてのSessionBeanメソッドの出口。これは標準のEJBメソッドではありません。

EJB_Around_SessionEjb

BusinessMethods

前後

前後

すべてのSessionBeanメソッドの入口と出口。これは標準のEJBメソッドではありません。

EJB_After_SessionEjbSemanticMethods

後

ステートレス

以下のメソッドの出口。

SessionBean.ejbCreateSessionBean.ejbPostCreate

EJB_Around_SessionEjb

SemanticMethods

前後

前後

以下のメソッドの入口と出口。

SessionBean.ejbCreate

SessionBean.ejbPostCreate

EJB_Before_EntityEjbBusinessMethods

前

ステートレス

すべてのEntityBeanメソッドの出口。これは標準のEJBメソッドではありません。

EJB_Before_EntityEjbMethods

前

ステートレス

以下のメソッドの入口。

EnitityBean.setEntityContext

EnitityBean.unsetEntityContext

EnitityBean.ejbRemove

EnitityBean.ejbActivate

EnitityBean.ejbPassivate

EnitityBean.ejbLoad

EnitityBean.ejbStore

EJB_Before_EntityEjbSemanticMethods

前

ステートレス

以下のメソッドの入口。

EnitityBean.set*

EnitityBean.get*

EnitityBean.ejbFind*

EnitityBean.ejbHome*

EnitityBean.ejbSelect*

EnitityBean.ejbCreate*

EnitityBean.ejbPostCreate*

EJB_Before_SessionEjb

BusinessMethods

前

ステートレス

すべてのSessionBeanメソッドの出口。これは標準のEJBメソッドではありません。

EJB_Before_SessionEjbMethods

前

ステートレス

以下のメソッドの入口。

SessionBean.setSessionContext

SessionBean.ejbRemove

SessionBean.ejbActivate

SessionBean.ejbPassivate

EJB_Before_SessionEjb

SemanticMethods

前

ステートレス

以下のメソッドの入口。

SessionBean.ejbCreate

SessionBean.ejbPostCreate

HttpSessionDebug

前後

組込み

getSession - 返されたHTTPセッションを検査

以下のメソッドの呼出しの前後。

getAttribute

setAttribute

removeAttribute

検査点で、およそのセッションのサイズが計算され、生成されたイベントのペイロードとして格納されます。このサイズはセッションをバイト配列にフラット化することで計算されます。セッションをフラット化する際にエラーが発生した場合は、負のサイズが報告されます。

JDBC_Before_CloseConnection

前

ステートレス

以下のメソッドの呼出しの前。

Connection.close

JDBC_After_CloseConnection

後

ステートレス

以下のメソッドの呼出しの後。

Connection.close

JDBC_Around_CloseConnection

前後

前後

以下のメソッドの呼出しの前後。

Connection.close

JDBC_Before_CommitRollback

前

ステートレス

以下のメソッドの呼出しの前。

Connection.commit

Connection.rollback

JDBC_After_CommitRollback

後

ステートレス

以下のメソッドの呼出しの後。

Connection.commit

Connection.rollback

JDBC_Around_CommitRollback

前後

前後

以下のメソッドの呼出しの前後。

Connection.commit

Connection.rollback

JDBC_Before_Execute

前

ステートレス

以下のメソッドの呼出しの前。

Statement.execute*

PreparedStatement.execute*

JDBC_After_Execute

後

ステートレス

以下のメソッドの呼出しの後。

Statement.execute*

PreparedStatement.execute*

JDBC_Around_Execute

前後

前後

以下のメソッドの呼出しの前後。

Statement.execute*

PreparedStatement.execute*

JDBC_Before_GetConnection

前

ステートレス

以下のメソッドの呼出しの前。

Driver.connect

DataSource.getConnection

JDBC_After_GetConnection

後

ステートレス

以下のメソッドの呼出しの後。

Driver.connect

DataSource.getConnection

JDBC_Around_GetConnection

前後

前後

以下のメソッドの呼出しの前後。

Driver.connect

DataSource.getConnection

JDBC_Before_Statement

前

ステートレス

以下のメソッドの呼出しの前。

Connection.prepareStatement

Connection.prepareCall

Statement.addBatch

RowSet.setCommand

JDBC_After_Statement

後

ステートレス

以下のメソッドの呼出しの後。

Connection.prepareStatement

Connection.prepareCall

Statement.addBatch

RowSet.setCommand

JDBC_Around_Statement

前後

前後

以下のメソッドの呼出しの前後。

Connection.prepareStatement

Connection.prepareCall

Statement.addBatch

RowSet.setCommand

JMS_Before_AsyncMessage

Received

前

ステートレス

以下のメソッドの入口。

MessageListener.onMessage

JMS_After_AsyncMessage

Received

後

ステートレス

以下のメソッドの出口。

MessageListener.onMessage

JMS_Around_AsyncMessage

Received

前後

前後

以下のメソッドの入口と出口。

MessageListener.onMessage

JMS_Before_MessageSent

前

ステートレス

以下のメソッドの呼出しの前。

QueSender send

JMS_After_MessageSent

後

ステートレス

以下のメソッドの呼出しの後。

QueSender send

JMS_Around_MessageSent

前後

前後

以下のメソッドの呼出しの前後。

QueSender send

JMS_Before_SyncMessage

Received

前

ステートレス

以下のメソッドの呼出しの前。

MessageConsumer.receive*

JMS_After_SyncMessage

Received

後

ステートレス

以下のメソッドの呼出しの後。

MessageConsumer.receive*

JMS_Around_SyncMessage

Received

前後

前後

以下のメソッドの呼出しの前後。

MessageConsumer.receive*

JMS_Before_TopicPublished

前

ステートレス

以下のメソッドの呼出しの前。

TopicPublisher.publish

JMS_After_TopicPublished

後

ステートレス

以下のメソッドの呼出しの後。

TopicPublisher.publish

JMS_Around_TopicPublished

前後

前後

以下のメソッドの呼出しの前後。

TopicPublisher.publish

JNDI_Before_Lookup

前

ステートレス

javax.naming.Contextのlookupメソッドの呼出しの前。

Context.lookup*

JNDI_After_Lookup

後

ステートレス

javax.naming.Contextのlookupメソッドの呼出しの後。

Context.lookup*

JNDI_Around_Lookup

前後

前後

javax.naming.Contextのlookupメソッドの呼出しの前後。

Context.lookup*

JTA_Before_Commit

前

ステートレス

以下のメソッドの入口。

UserTransaction.commit

JTA_After_Commit

後

ステートレス・アドバイス

以下のメソッドの出口。

UserTransaction.commit

JTA_Around_Commit

前後

前後

以下のメソッドの入口と出口。

UserTransaction.commit

JTA_Before_Rollback

前

ステートレス

以下のメソッドの入口。

UserTransaction.rollback

JTA_After_Rollback

後

ステートレス・アドバイス

以下のメソッドの出口。

UserTransaction.rollback

JTA_Around_Rollback

前後

前後

以下のメソッドの入口と出口。

UserTransaction.rollback

JTA_Before_Start

前

ステートレス

以下のメソッドの入口。

UserTransaction.begin

JTA_After_Start

後

ステートレス・アドバイス

以下のメソッドの出口。

UserTransaction.begin

JTA_Around_Start

前後

前後

以下のメソッドの入口と出口。

UserTransaction.begin

MDB_Before_MessageReceived

前

ステートレス

以下のメソッドの入口。

MessageDrivenBean.onMessage

MDB_After_MessageReceived

後

ステートレス

以下のメソッドの出口。

MessageDrivenBean.onMessage

MDB_Around_MessageReceived

前後

前後

以下のメソッドの入口と出口。

MessageDrivenBean.onMessage

MDB_Before_Remove

前

ステートレス

以下のメソッドの入口。

MessageDrivenBean.ejbRemove

MDB_After_Remove

後

ステートレス

以下のメソッドの出口。

MessageDrivenBean.ejbRemove

MDB_Around_Remove

前後

前後

以下のメソッドの入口と出口。

MessageDrivenBean.ejbRemove

MDB_Before_SetMessageDriven

Context

前

ステートレス

以下のメソッドの入口。

MessageDrivenBean.setMessage

DrivenContext

MDB_After_SetMessageDriven

Context

後

ステートレス

以下のメソッドの出口。

MessageDrivenBean.setMessageDrivenContext

MDB_Around_SetMessageDriven

Context

前後

前後

以下のメソッドの入口と出口。

MessageDrivenBean.setMessageDrivenContext

Servlet_Before_Service

前

ステートレス

以下のサーブレットまたはJSPメソッドの入口。

HttpJspPage._jspService

Servlet.service

HttpServlet.doGet

HttpServlet.doPost

Filter.doFilter

Servlet_After_Service

後

ステートレス

以下のサーブレットまたはJSPメソッドの出口。

HttpJspPage._jspService

Servlet.service

HttpServlet.doGet

HttpServlet.doPost

Filter.doFilter

Servlet_Around_Service

前後

前後

以下のサーブレットまたはJSPメソッドの入口と出口。

HttpJspPage._jspService

Servlet.service

HttpServlet.doGet

HttpServlet.doPost

Filter.doFilter

Servlet_Before_Session

前

ステートレス

以下のサーブレット・メソッドの呼出しの前。

HttpServletRequest.getSession

HttpSession.setAttribute/

putValue

HttpSession.getAttribute/

getValue

HttpSession.removeAttribute/

removeValue

HttpSession.invalidate

Servlet_Around_Session

前後

前後

以下のサーブレット・メソッドの呼出しの前後。

HttpServletRequest.getSession

HttpSession.setAttribute/

putValue

HttpSession.getAttribute/

getValue

HttpSession.removeAttribute/

removeValue

HttpSession.invalidate

Servlet_After_Session

後

ステートレス

以下のサーブレット・メソッドの呼出しの後。

HttpServletRequest.getSession

HttpSession.setAttribute/

putValue

HttpSession.getAttribute/

getValue

HttpSession.removeAttribute/

removeValue

HttpSession.invalidate

Servlet_Before_Tags

前

ステートレス

以下のJSPメソッドの呼出しの前。

Tag.doStartTag

Tag.doEndTag

Servlet_After_Tags

後

ステートレス

以下のJSPメソッドの呼出しの後。

Tag.doStartTag

Tag.doEndTag

Servlet_Around_Tags

前後

前後

以下のJSPメソッドの呼出しの前後。

Tag.doStartTag

Tag.doEndTag

診断アクション・ライブラリ

診断アクション・ライブラリには、以下のアクションが含まれます。

- TraceAction

- DisplayArgumentsAction

- TraceElapsedTimeAction

- TraceMemoryAllocationAction

- StackDumpAction

- ThreadDumpAction

- MethodInvocationStatisticsAction

- MethodMemoryAllocationStatisticsAction

これらの診断アクションは、上の2つの表で説明した委任モニターで使用できます。また、ユーザーが定義してアプリケーション内で使用できるカスタム・モニターと一緒に使用することもできます。各診断アクションは、対応モニター・タイプ列に示されている対応するモニターとのみ一緒に使用できます。いくつかの動作(たとえば、TraceElapsedTimeAction)がイベント・ペイロードを生成します。

TraceAction

TraceActionはStatelessアクションで、BeforeおよびAfterモニター・タイプに対応しています。

TraceActionは、プログラムの実行中に作用場所にトレース・イベントを生成します。以下の情報が生成されます。

- タイムスタンプ

- リクエストを一意に特定する診断コンテキストからのコンテキスト識別子

- トランザクション識別子(可能な場合)

- ユーザーID

- アクション・タイプ(つまりTraceAction)

- ドメイン

- サーバー名

- インストゥルメンテーション・スコープ名(たとえばアプリケーション名)

- 診断モニター名

- モジュール名

- コード内でアクションをコールした場所。次の場所が含まれます。

- クラス名

- メソッド名

- メソッド・シグネチャ

- 行番号

- スレッド名

- 診断コンテキストによって保持されるペイロード(存在する場合)

DisplayArgumentsAction

DisplayArgumentsActionはStatelessアクションで、BeforeおよびAfterモニター・タイプに対応しています。

DisplayArgumentsActionは、プログラムの実行中に作用場所にインストゥルメンテーション・イベントを生成し、メソッドの引数または戻り値をキャプチャします。

このアクションが実行されると、イベント・アーカイブにディスパッチされるインストゥルメンテーション・イベントが発生します。インストゥルメンテーション・イベントがBeforeモニターにアタッチされた場合は、ジョインポイントへの入力引数(たとえばメソッド引数)がキャプチャされます。インストゥルメンテーション・イベントがAfterモニターにアタッチされた場合は、ジョインポイントからの戻り値がキャプチャされます。イベントは、以下の情報を保持します。

- タイムスタンプ

- リクエストを一意に特定する診断コンテキストからのコンテキスト識別子

- トランザクション識別子(可能な場合)

- ユーザーID

- アクション・タイプ(つまりDisplayArgumentsAction)

- ドメイン

- サーバー名

- インストゥルメンテーション・スコープ名(たとえばアプリケーション名)

- 診断モニター名

- モジュール名

- コード内でアクションをコールした場所。次の場所が含まれます。

- クラス名

- メソッド名

- メソッド・シグネチャ

- 行番号

- スレッド名

- 診断コンテキストによって保持されるペイロード(存在する場合)

- Beforeモニターにアタッチされたときの入力引数(存在する場合)

- Afterモニターにアタッチされたときの戻り値(存在する場合)

TraceElapsedTimeAction

TraceElapsedTimeActionはAroundアクションで、Aroundモニター・タイプに対応しています。

TraceElapsedTimeActionは2つのイベント(プログラム実行中の特定の場所の前と後)を生成します。

このアクションが実行されると、関連付けられたジョインポイントの実行前と実行後のタイムスタンプがキャプチャされます。そして、これらの差を計算することで経過時間が算出されます。このアクションでは、イベント・アーカイブにディスパッチされるインストゥルメンテーション・イベントが生成されます。経過時間は、イベント・ペイロードとして格納されます。イベントは、以下の情報を保持します。

- タイムスタンプ

- リクエストを一意に特定する診断コンテキストからのコンテキスト識別子

- トランザクション識別子(可能な場合)

- ユーザーID

- アクション・タイプ(つまりTraceElapsedTimeAction)

- ドメイン

- サーバー名

- インストゥルメンテーション・スコープ名(たとえばアプリケーション名)

- 診断モニター名

- モジュール名

- コード内でアクションを呼び出した場所 - 次を含みます。

- クラス名

- メソッド名

- メソッド・シグネチャ

- 行番号

- スレッド名

- 診断コンテキストによって保持されるペイロード(存在する場合)

- ジョインポイントの処理にかかったナノ秒単位の時間(イベント・ペイロードとして)

TraceMemoryAllocationAction

TraceMemoryAllocationActionは、メソッド呼出しのとき、スレッドにより割り当てられたバイト数をトレースするためにJRockit APIを使用します。このアクションは、メソッド呼出し内に割り当てられたメモリーがトレースされる点を除けば、TraceElapsedTimeActionとよく似ています。

TraceMemoryAllocationActionのアクションは次のとおりです。

- 永続化されたインストゥルメンテーション・イベントを作成します。

- 委任とカスタム監視から使用できます。

StackDumpAction

StackDumpActionはStatelessアクションで、BeforeおよびAfterモニター・タイプに対応しています。

StackDumpActionは、プログラムの実行中に作用場所にインストゥルメンテーション・イベントを生成し、スタック・ダンプをキャプチャします。

このアクションが実行されると、イベント・アーカイブにディスパッチされるインストゥルメンテーション・イベントが生成されます。スタック・トレースは、イベント・ペイロードとしてキャプチャされます。イベントは、以下の情報を保持します。

- タイムスタンプ

- リクエストを一意に特定する診断コンテキストからのコンテキスト識別子

- トランザクション識別子(可能な場合)

- ユーザーID

- アクション・タイプ(つまりStackDumpAction)

- ドメイン

- サーバー名

- インストゥルメンテーション・スコープ名(たとえばアプリケーション名)

- 診断モニター名

- モジュール名

- コード内でアクションをコールした場所。次の場所が含まれます。

- クラス名

- メソッド名

- メソッド・シグネチャ

- 行番号

- スレッド名

- 診断コンテキストによって保持されるペイロード(存在する場合)

- スタック・トレース(イベント・ペイロードとして)

ThreadDumpAction

ThreadDumpActionはStatelessアクションで、BeforeおよびAfterモニター・タイプに対応しています。

ThreadDumpActionは、プログラムの実行中に影響のある場所にインストゥルメンテーション・イベントを生成し、スレッド・ダンプをキャプチャします(基底のVMのサポート対象となっている場合)。JDK 1.5 (Oracle JRockitおよびSun)ではこのアクションをサポートします。

このアクションでは、イベント・アーカイブにディスパッチされるインストゥルメンテーション・イベントが生成されます。このアクションはJRockit JVMでのみ使用できます。他のJVMの場合は無視されます。スレッド・ダンプは、イベント・ペイロードとしてキャプチャされます。イベントは、以下の情報を保持します。

- タイムスタンプ

- リクエストを一意に特定する診断コンテキストからのコンテキスト識別子

- トランザクション識別子(可能な場合)

- ユーザーID

- アクション・タイプ(つまりThreadDumpAction)

- ドメイン

- サーバー名

- インストゥルメンテーション・スコープ名(たとえばアプリケーション名)

- 診断モニター名

- モジュール名

- コード内でアクションをコールした場所。次の場所が含まれます。

- クラス名

- メソッド名

- メソッド・シグネチャ

- 行番号

- スレッド名

- 診断コンテキストによって保持されるペイロード(存在する場合)

- スレッド・ダンプ(イベント・ペイロードとして)

MethodInvocationStatisticsAction

MethodInvocationStatisticsActionはAroundアクションで、Aroundモニター・タイプに対応しています。

MethodInvocationStatisticsActionは、呼出しごとにイベントをアーカイブに保存せずに、ジョインポイント前後のパフォーマンス・メトリックをメモリーにキャプチャします。統計が収集され、WLDFInstrumentationRuntimeMBeanで利用できます。収集された統計は、ハーベスタ・コンポーネントや監視と通知コンポーネントでも使用できます。これによって、インストゥルメンテーション・システムからのリクエスト情報と他のランタイムMBeanからのメトリック情報を結合可能な監視ルールを作成できます。

キャプチャが可能な統計の一部を次に示します。

- 呼出しの数

- 平均実行時間(ナノ秒単位)

- 観察対象実行時間の標準偏差

- 最小実行時間

- 最大実行時間

任意のスコープのWLDFInstrumentationRuntimeMBeanインスタンスは、MethodInvocationStatistics属性を使用して、構成されているAround診断モニターにアタッチされているMethodInvocationStatisticsActionインスタンスから収集したデータを公開します。図B-1に示すように、MethodInvocationStatistics属性には、Mapオブジェクトの階層が含まれます。

図B-1 MethodInvocationStatistics属性の構造

「図B-1 MethodInvocationStatistics属性の構造」の説明

MethodInvocationStatistics属性では、次のセマンティクスが使用されます。

MethodInvocationStatistics::= Map<className, MethodMap>
MethodMap::= Map<methodName, MethodParamsSignatureMap>
MethodParamsSignatureMap::= Map<MethodParamsSignature, MethodDataMap>
MethodDataMap::= <MetricName, Statistic>
MetricName:= min | max | avg | count | sum | sum_of_squares | std_deviation

MethodInvocationStatisticsActionは、情報をメモリーにのみキャプチャしてアーカイブには保存しないため、このアクションでは、他のインストゥルメンテーション・アクションのI/Oオーバーヘッドが生じることはありません。そのため、このアクションはパフォーマンス統計をキャプチャして、アプリケーションのボトルネックの特定に役立つ軽量メカニズムになります。マップ構造をナビゲートして、アプリケーションのパフォーマンスが低い箇所を特定できます。

MethodInvocationStatisticsActionを使用したアプリケーションのインストゥルメントと結果に対する問合せ

この項では、MethodInvocationStatisticsActionを使用するカスタム・モニターでサンプル・アプリケーションAvitek Medical Records(MedRec)をインストゥルメントする例を示します。次にこの例では、WLSTオンラインを使用して、収集されたパフォーマンス統計に問合せを実行する方法を示します。この問合せを実行するには、インストゥルメントされたアプリケーションに関連するWLDFInstrumentationRuntimeMBeanインスタンスをナビゲートします。

WLSTオンラインでは、MBeanに簡単にアクセスできます。JMX APIでは、MBeanに対して照会を行なうためにJMXオブジェクト名を使用する必要がありますが、WLSTでは、ファイル・システム内のファイルの階層を移動するのと同様なやり方で、MBeanの階層を移動できます。詳細は、『Oracle WebLogic Scripting Tool』のMBeanのナビゲートと照会に関する項を参照してください。

この例には、次の項が含まれています。

- MethodInvocationStatisticsActionを使用するためのカスタム・モニターの構成

- WLSTを使用したメソッドのパフォーマンス統計への問合せ

注意:
WebLogic Serverをインストールすると、Java EE APIおよび他のWebLogic Serverの機能を示すサンプル・コードも提供されます。これらのサンプル・コードを利用しながら作業するには、WebLogic Serverをインストールする際にカスタム・インストール・オプションを選択し、WebLogic Serverのサンプルのインストールを選択します。詳細は、『Oracle WebLogic Serverインフォメーション・ロードマップ』のサンプル・アプリケーションおよびコード例に関する項を参照してください。

MethodInvocationStatisticsActionを使用するためのカスタム・モニターの構成

WebLogic Server 10.3以降では、カスタム・モニターの構成でアプリケーションのMETA-INFディレクトリにweblogic-diagnostics.xmlファイルを作成する必要がなくなりました。かわりに、MedRecサンプル・アプリケーションをインストゥルメントする次の手順に従い、管理コンソールから必要な手順をすべて実行できます。

1. 管理コンソールの「ドメイン構造」ペインで「デプロイメント」を選択します。

2. 「デプロイメントのサマリー」ページで、「制御」を選択し、「デプロイメント」表でmedrecをクリックします。
「medrecの設定」ページが表示されます。

3. 「構成」→「インストゥルメンテーション」を選択します。

4. 「このモジュールの診断監視」表で、「カスタム監視を追加」をクリックします。

5. 「カスタム監視を追加」ページで、モニター名にMethodStatsMonitorと入力します。簡単な説明をオプションで入力できます。

6. 「場所のタイプ」選択ボックスで、「前後」を選択します。

7. 「ポイントカット」テキスト・ボックスで、次のポイントカット式を入力します。

execution(public * com.bea.medrec.* *(...)) AND NOT
execution(public * com.bea.medrec.* get*(...)) OR
execution(public * com.bea.medrec.* set*(...)) OR
execution(public * com.bea.medrec.* __WL_*(...)));

このポイントカット式は、名前がcom.bea.medrecで始まるパッケージ内のクラスのすべてのパブリック・メソッドのジョインポイントを指定します。ただし、次のメソッドは除外されます。

- すべてのアクセサ・メソッド

- 文字列__WL_で始まるメソッド

このポイントカット式には、MedRecの様々なパブリック・メソッドとクラスが含まれます。ただし、すべてのgetterメソッドとsetterメソッド、およびWebLogic Serverで生成されるコードは無視されます。

8. ポイントカット式のテキスト・ボックスの下で「OK」をクリックします。

9. 「デプロイメント・プランの保存」ページで、デプロイメント・プランの新しいパスを入力するか、デフォルトの場所を受け入れ、「OK」をクリックします。

10. 「構成」→「インストゥルメンテーション」を選択して、「このモジュールの診断監視」表にリストされている新しいカスタム・モニターの名前MethodStatsMonitorをクリックします。
「MethodStatsMonitorの設定」ページが表示されます。

11. 図B-2に示すように、「アクション」表で、カスタム・モニターにMethodInvocationStatisticsActionを割り当てます。

図B-2 カスタム・モニターへのMethodInvocationStatisticsActionの選択

「図B-2 カスタム・モニターへのMethodInvocationStatisticsActionの選択」の説明

12. 「MethodStatsMonitorの設定」ページの下部で「保存」をクリックします。

13. 更新されたデプロイメント・プランをMedRecアプリケーションに適用します。

1. 「ドメイン構造」ペインで、「デプロイメント」を選択します。

2. 「デプロイメントのサマリー」ページで「制御」を選択し、図B-3に示すように、「デプロイメント」表でmedrecに隣接する選択ボックスをクリックします。

図B-3 MedRecデプロイメントの選択

「図B-3 MedRecデプロイメントの選択」の説明

3. 「更新」をクリックします。

4. 「アプリケーション更新アシスタント」ページで、「このアプリケーションを次のデプロイメント・ファイルを使用して再デプロイします。」を選択します。

5. 「次」、「終了」の順にクリックします。

MedRecアプリケーションが再デプロイされ、カスタム・モニターMethodStatsMonitorがアクティブになります。

注意:
Javaホットスワップが有効ではない場合、アプリケーションの構成に新しいポイントカットを追加するには、カスタム・モニターをアプリケーション・コードにウィービングできるようにアプリケーションを再デプロイする必要があります。(ただし、アプリケーションのモニター構成の大部分は再デプロイせずに変更できます。たとえば、カスタム・モニターの「アクション」、「プロパティ」、「仕分けフィルタの有効化」、「説明」の各属性(つまり、バイトコードのウィービングを必要としない属性)などを変更できます。
ただし、ホットスワップが有効な場合は、アプリケーションを再デプロイせずにモニター属性の変更やアプリケーションの更新が可能です。詳細は、「インストゥルメンテーション構成を動的に制御するためのデプロイメント・プランの使用」を参照してください。

WLSTを使用したメソッドのパフォーマンス統計への問合せ

MedRecを再デプロイした場合、インストゥルメントされたコードが実行されると、MethodInvocationStatisticsActionはメソッドのパフォーマンス統計のキャプチャを開始します。この項では、カスタム・モニターが有効なMedRec親アプリケーションをナビゲートすることで統計をすばやく簡単に生成する方法を示します。次に、WLSTオンラインを使用して統計を確認する方法を示します。

MedRecに構成されたカスタム・モニターを使用してメソッドのパフォーマンス統計をキャプチャし、WLSTを使用してその結果を問い合せるには、次の手順に従います。

1. 『Oracle WebLogic Serverの紹介』のWebLogic Server APIのサンプルおよびサンプル・アプリケーションに関する項の説明に従い、MedRecアプリケーションを開始します。
患者、管理者または医師としてログインし、数回の操作を行います。

2. 次の例の手順に示すように、WLSTオンラインを呼び出し、WLDFInstrumentationRuntimeMBeanインスタンスにナビゲートします。

1. 次のようにMedRecサーバーに接続します。

wls:/offline> connect('weblogic','welcome1','localhost:7011')
Connecting to t3://localhost:7011 with userid weblogic ...
Successfully connected to Admin Server 'MedRecServer' that belongs to domain 'medrec'.

2. cdコマンドを実行して、MedRecアプリケーションに関連するWLDFInstrumentationRuntimeMBeanインスタンスにナビゲートします。

cd('serverRuntime:/WLDFRuntime/WLDFRuntime/WLDFInstrumentationRuntimes/medrec')
Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.
For more help, use help(serverRuntime)

3. WLDFInstrumentationRuntimeMBeanに対して次のメソッドを呼び出して、MethodInvocationStatisticsActionで収集された特定の値にアクセスします。

public Object getMethodInvocationStatisticsData(String expr) throws ManagementException;

WLSTをインタラクティブに使用すると、このメソッドにルックアップ式を渡すことができます。ルックアップ式では、表示する値の特定のサブセットを指定します。これらの値は、MethodInvocationStatisticsActionで作成されるマップ構造から取得されます。たとえば、次のWLSTコマンドは、MethodInvocationStatisticsActionでインストゥルメントされるすべてのメソッドの平均実行時間(ナノ秒単位)を戻します。

cmo.getMethodInvocationStatisticsData("(com.bea%)(*)(?)(avg)")
array(java.lang.Object,[3352.0, 3632.0, 145270.0, 4050.5, 8450.916666666666, 1798645.75,
583538.0, 3610515.0, 1.9541031E7, 1.2796319E7, 3.07897E8, 4470.0, 3073.0, 3073.0,
2.4644752E7, 3492.5, 1051530.0, 2794.0, 390552.3333333333, 3632.0, 2095.5, 189409.33333333334,
2607.6666666666665, 2793.6666666666665, 4749.333333333333, 5308.0, 65930.0, 3.3950405E7,
3353.0, 3911.5])

収集されたデータ値のセット全体を表示する場合、図B-4に示すように、大量の情報がWLSTコンソールに表示されることがあります。

図B-4 MethodInvocationStatisticsActionで収集されたすべてのデータ値の表示

「図B-4 MethodInvocationStatisticsActionで収集されたすべてのデータ値の表示」の説明

また、次の例のように、MethodInvocationStatisticsを呼び出して、収集されたデータが読みやすくなるようにフォーマットするWLSTスクリプトを作成する方法もあります。

例B-1 WLSTを使用したMethodInvocationStatisticsの呼出しと結果の表示

import sys

def getPositionalArgument(pos, default):
value=None
try:
value=sys.argv[pos]
except:
value=default
return value

url = getPositionalArgument(1, "t3://localhost:7001")
user = getPositionalArgument(2, "weblogic")
password = getPositionalArgument(3, "welcome1")
appName = getPositionalArgument(4, "myapp")

connect(user,password,url)
serverRuntime()
cd('/WLDFRuntime/WLDFRuntime/WLDFInstrumentationRuntimes/' + appName)

print "# Class Method | Count | Min | Max | Average | Std-dev |"
stats=cmo.getMethodInvocationStatistics()
for className in stats.keySet():
classMap=stats.get(className)
for methodName in classMap.keySet():
methodMap=classMap.get(methodName)
for sig in methodMap.keySet():
str= className + " " + methodName + "(" + sig + ")"
sigMap=methodMap.get(sig)
count=sigMap.get('count')
min=sigMap.get('min')
max=sigMap.get('max')
avg=sigMap.get('avg')
std_deviation=sigMap.get('std_deviation')
print str, "|", count, "|", min, "|", max, "|", avg, "|", std_deviation, "|"

次に、例B-1に示すWLSTスクリプトで生成される出力を示します。

# Class Method | Count | Min | Max | Average | Std-dev |
jsp_servlet.__index _isStale() | 1 | 1378000 | 1378000 | 1378000.0 | 0.0 |
jsp_servlet.__index _getBytes(java.lang.String) | 3 | 1000 | 754000 | 252666.66666666666 | 354497.1399351795 |
jsp_servlet.__index _staticIsStale(weblogic.servlet.jsp.StaleChecker) | 1 | 861000 | 861000 | 861000.0 | 0.0 |
jsp_servlet.__index _jspService(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse) | 2 | 70000 | 2113000 | 1091500.0 | 1021500.0 |
jsp_servlet.__index$MyMap containsKey(java.lang.Object) | 2 | 2000 | 101000 | 51500.0 | 49500.0 |
jsp_servlet.__index$MyMap containsValue(java.lang.Object) | 2 | 1000 | 2000 | 1500.0 | 500.0 |

MethodInvocationStatisticsActionデータを収集するためのハーベスタの構成

MethodInvocationStatisticsActionインスタンスで収集されたデータをハーベスタが集めるように構成するには、次の属性を使用してWLDFHarvesterBeanのインスタンスを構成する必要があります。

Name=weblogic.management.runtime.WLDFInstrumentationRuntimeMBean

スコープはインスタンスの構成によって選択されます。

属性の指定では、ハーベスタで収集するデータを定義します。マップの一連の要素には、次の表記法でアクセスできます。

MethodInvocationStatistics(className)(methodName)(methodParamSignature)
(metricName)

前述の表記法では、次のようになります。

- classNameは、完全修飾Javaクラス名を表します。クラス名にはワイルドカード文字「*」を使用できます。

- methodNameは指定のクラスから特定のメソッドを選択します。メソッド名にはワイルドカード文字「*」を使用できます。

- methodParamSignatureはメソッドの入力引数の型をカンマ区切りのリストで表す文字列を表します。シグネチャの指定では、引数名を除いたJava型名のみを含めます。Java言語と同様に、シグネチャ内のパラメータの順序には意味があります。
この要素は、ワイルドカード文字「*」にも対応します。ワイルドカード文字は、指定のメソッドに入力引数の型のリスト全体を指定するかわりに使用できます。ワイルドカード文字「*」は、methodParamSignature式でワイルドカード文字が出現した後の位置のゼロ個以上の引数の型と一致します。

また、「?」のワイルドカード文字も使用できます。これは、パラメータの型の順序付けられたリスト内の任意の位置で単一の引数の型に一致します。

これらのワイルドカード文字はどちらも、式のどのような場所にも出現する可能性があります。例については、表B-3を参照してください。

- metricNameは、収集する統計を表します。このキー内でワイルドカード文字「*」を使用すると、サポートされているすべてのメトリックを収集できます。

表B-3は、MethodInvocationStatisticsActionインスタンスを構成して、次のオーバーロードのメソッドを含むcom.Foo.Barというオブジェクトの統計を収集する方法を示しています。

public void doIt();
public void doIt(int a);
public void doit(int a, String s)
public void doIt(Stringa, int b);
public void doIt(String a, String b);
public void doIt(String[] a);
public void doNothing();
public void doNothing(com.foo.Baz);

表B-3 MethodInvocationStatisticsActionの構成例

使用するMethodInvocationStatisticsActionインスタンスの構成

収集する内容

MethodInvocationStatistics(com.foo.Bar)(*)(*)(*)

com.Foo.Barに対する全メソッドのすべての統計。

MethodInvocationStatistics(com.foo.Bar)(doIt)()(*)

入力引数を持っていないdoIt()メソッドのすべての統計。

MethodInvocationStatistics(com.foo.Bar)(doIt)(*)(*)

全doIt()メソッドのすべての統計。

MethodInvocationStatistics(com.foo.Bar)(doIt)(int, *)(*)

doIt(int)メソッドとdoIt(int, String)メソッドのすべての統計。

MethodInvocationStatistics(com.foo.Bar)(doIt)(String[])(*)

doIt(String[])メソッドのすべての統計。

配列パラメータは、型名の後に一対の角括弧([])を使用して指定します。スペース文字は、ハーベスタの場合、重要ではありません。

MethodInvocationStatistics(com.foo.Bar)(doIt)(String, ?)(*)

2つの入力パラメータを持ち、最初の引数の型がStringであるdoIt()メソッドのすべての統計。この例のクラスでは、このインスタンス構成は次のメソッドと一致します。

- doIt(String, int)

- doIt(String, String)

MethodInvocationStatistics(com.foo.Bar)(doNothing)(com.foo.Baz)(min|max)

com.foo.Baz型の単一の入力パラメータを持つdoNothing()メソッドの最小および最大の実行時間。

注意:
classNameパラメータでワイルドカード文字を使用すると、パフォーマンスに悪影響を与える場合があります。

MethodInvocationStatisticsメトリックに基づく監視ルールの構成

監視ルールでMethodInvocationStatisticsメトリックを使用するには、前の項で説明した同じ構文を使用できます。ワイルドカード文字を使用しない重要な監視ルールをMetricName要素に作成するには、特定のメソッドにmin、max、avg、count、sum、sum_of_squares、std_deviationのいずれかの変数を指定します。

JMXによるデータの収集

JMXを使用してデータを収集する際にWLDFInstrumentationRuntimeMBeanに対してgetAttribute("MethodInvocationStatistics")メソッドを呼び出すと、サーバーのパフォーマンスに影響する場合があります。これは、インストゥルメントされたクラスによっては、ネストされたマップ構造に高価なシリアライゼーションを伴う大量のデータが含まれる場合があるためです。

JMXを使用してデータを収集する場合、getMethodInvocationStatisticsData(String)メソッドを使用することをお薦めします。

MethodMemoryAllocationStatisticsAction

このアクションは、メソッド呼出しのとき、スレッドにより割り当てられたバイト数を追跡するためにJRockit APIを使用します。メモリー割当てにあるメモリー内に統計が保存されます。ただし、このアクションによりインストゥルメンテーション・イベントは作成されません。

MethodMemoryAllocationStatisticsActionは、既存のMethodInvocationStatisticsActionとかなり似ています。ただし、MethodMemoryAllocationStatisticsActionで追跡される統計は、メソッド・コール内で割り当てられるメモリーに関連します。

MethodInvocationStatisticsActionは、インストゥルメンテーション・イベントを作成しません。JRockitが使用可能な場合、WLDFInstrumentationRuntimeMBeanを介して統計が使用できます。

各メソッド用に、次の統計が保持されます。

- count

- min

- max

- avg

- sum

- sum_of_squares

- std_deviation

C 式でのワイルドカードの使用

WLDFでは、<harvested-instance>要素内のインスタンス名にワイルドカードを使用できます。また、<harvested-attribute>要素の属性指定でドリルダウン機能とワイルドカード機能を使用できます。

ハーベスタの監視ルールではインスタンス名に同じワイルドカード機能を使用できるだけでなく、複合属性も指定できます。

これらの機能については、次の項で説明します。

- ハーベスタ・インスタンス名でのワイルドカードの使用

- ハーベスタの複合属性およびネストされた属性の指定

- 収集された複合属性またはネストされた属性に関するアクセサの使用

- 監視ルール・インスタンス名でのワイルドカードの使用

- ハーベスタの監視ルールでの複合属性の指定

ハーベスタ・インスタンス名でのワイルドカードの使用

<harvested-instance>要素内でインスタンス名を指定する場合、以下の処理が可能です。

- インスタンス名を非標準形式で表します。これによって、ObjectNameのプロパティ・リストを順不同で指定できます。

- ObjectNameをJMX ObjectName問合せパターンとして表します。この際、プロパティ・リストの順序を気にする必要はありません。

- ObjectNameのプロパティ・リスト内の任意の値で0個以上の「*」ワイルドカードを使用します。Name=*などと指定します。

- 0個以上の「*」ワイルドカードを使用して、標準形式のObjectName文字列内の任意の文字シーケンスを置換します。この場合、ワイルドカードで指定していないObjectNameのプロパティはすべて標準形式でなければなりません。

例

例C-1におけるインスタンスの指定では、WorkManagerRuntimeMBeanのすべてのインスタンスが収集されることを示しています。これは、<harvested-type>宣言内でインスタンス名修飾を1つも指定しないのと同じです。

例C-1 MBeanのすべてのインスタンスの収集

<harvested-type>
<name>weblogic.management.runtime.WorkManagerRuntimeMBean</name>
<harvested-instance>*<harvested-instance>
<known-type>true</known-type>
<harvested-attribute>PendingRequests</harvested-attribute>
</harvested-type>

例C-2の例は<harvested-instance>の値としてJMX ObjectNameパターンを示しています。

例C-2 JMX ObjectNameパターンの使用

<harvested-type>
<name>com.acme.CustomMBean</name>
<harvested-instance>adomain:Type=MyType,*</harvested-instance>
<known-type>false</known-type>
</harvested-type>

例C-3の例では、ObjectNameプロパティ・リストの一部の値でワイルドカードが指定されています。

例C-3 プロパティ・リストでのワイルドカードの使用

<harvested-type>
<name>com.acme.CustomMBean</name>
<harvested-instance>adomain:Type=My*,Name=*,*</harvested-instance>
<known-type>false</known-type>
</harvested-type>

例C-4の例は、com.acme.CustomMBeanのすべてのインスタンスのすべての収集可能な属性が収集されますが、インスタンス名に「Name=mybean」ストリングが含まれる場合のみであることを示します。

例C-4 複数のインスタンスのすべての属性の収集

<harvested-type>
<name>coma.acme.CustomMBean</name>
<harvested-instance>*Name=mybean*</harvested-instance>
<known-type>true</known-type>
</harvested-type>

ハーベスタの複合属性およびネストされた属性の指定

ハーベスタは、MBeanの複合属性内にネストされたメトリック値にアクセスできます。複合属性とは、マップ、リスト・オブジェクト、単純なPOJO、またはこれらのオブジェクトが様々な形でネストされたものを指します。例:

- anObject.anAttribute

- arrayAttribute[1]

- mapAttribute(akey)

- aList[1](aKey)

さらに、リスト索引やマップ・キーにワイルドカードを使用して、これらの集合内の複数の要素を指定することができます。以下のワイルドカードを使用できます。

- * :このワイルドカードを使用すると、マップ属性のすべてのキー値を指定できます。

- % :このワイルドカードを使用すると、マップ・キー文字列の一部を置き換え、特定のパターンに一致するキーのグループを同一に扱うことができます。

また、カンマ区切りのリストを使用して個々のキー値のセットを指定することもできます。

例:

- aList[1](partial%Key%)

- aList[*](key1,key3,keyN)

- aList[*](*)

最後の例では、リストの索引として、およびネストされたマップ・オブジェクトに対するキー値としてワイルドカード「*」が使用されており、ネストされた値の配列が返されます。

次のように、カンマ区切りのマップ・キー・リストにワイルドカード「*」を埋め込むこともできます。

aList[*](key1,*,keyN)

これは、すべてのマップ・キーを指定しているのと同じです。

aList[*](*)

注意:
先頭または末尾のスペースは、マップ・キーを二重引用符で囲まない限りマップ・キーから取り除かれます。
マップ・キー・パターンを使用すると、大量の要素がスキャンまたは返される場合があります。マップ内の要素数に応じて、パターン・マッチがパフォーマンスに与える影響も大きくなります。

パターン・マッチの複雑度に応じて、処理時間も長くなります。

例

ServerRuntime MBeanでHealthState属性のネストされた状態プロパティを収集するのにドリルダウン構文を使用するために、以下の診断記述子を使用します。

例C-5 ドリルダウン構文の使用

<harvester>
<sample-period>10000</sample-period>
<harvested-type>
<name>weblogic.management.runtime.ServerRuntimeMBean</name>
<harvested-attribute>HealthState.State</harvested-attribute>
</harvested-type>
</harvester>

配列またはリストの要素を収集するために、ハーベスタでは、配列またはリスト内の索引位置に基づいて値が参照される添え字表記法がサポートされています。たとえば、URLPatterns「0」を指定して、ServletRuntimeMBeanの配列属性URLPatternsにおける最初の要素を示してください。ワイルドカードを使用してURLPatternsのすべての要素を参照するには、次のように指定します。

例C-6 ワイルドカードによるすべての配列要素の参照

<harvester>
<sample-period>10000</sample-period>
<harvested-type>
<name>weblogic.management.runtime.ServletRuntimeMBean</name>
<harvested-attribute>URLPatterns[*]</harvested-attribute>
</harvested-type>
</harvester>

マップの要素を収集するには、キーをカッコで囲んで個々の値を参照します。複数のキーもカンマ区切りのリストで指定することができます。この場合、マップ内の指定したキーに対応する値が収集されます。

次のサンプル・コードは、キーFooを持つマップから値を収集します。

<harvested-attribute>MyMap(Foo)</harvested-attribute>

次の例は、キーFooおよびBarを持つマップから値を収集します。

<harvested-attribute>MyMap(Foo,Bar)</harvested-attribute>

次の例は、キーの指定で%文字を使用し、先頭がFooで末尾がBarのキーを持つマップからすべての値を収集します。

<harvested-attribute>MyMap(Foo%Bar)</harvested-attribute>

次の例は、*文字を使用してマップからすべての値を収集します。

<harvested-attribute>MyMap(*)</harvested-attribute>

次の例では、MBeanはネストされたマップ・タイプ属性MyMapがあるJavaBean属性MyBeanを持っています。このサンプル・コードは、キーがFooのマップからこの値を収集します。

<harvested-attribute>MyBeanMyMap(Foo)</harvested-attribute>

収集された複合属性またはネストされた属性に関するアクセサの使用

ハーベスタや監視および通知の構成では、単一の式で多数の複合属性やネストされた属性を指定できますが、実際のメトリックは各メトリックが個別に収集されるように保持されます。

たとえば、次のような属性の指定を考えます。

mymap(*).(a,b,c)

これは、以下の実際のネストされた属性にマップされます。

mymap(key1).a
mymap(key1).b
mymap(key1).c
mymap(key2).a
mymap(key2).b
mymap(key2).c

これらの6つの各メトリックはHarvestedDataArchiveに個別のレコードとして格納され、ここに示した属性の名前が、対応する各レコードのATTRNAME列に格納されます。アーカイブからレコードを取得する際は、このATTRNAME列内の値をアクセサの問合せで指定する必要があります。

以下にサンプル問合せをいくつか示します。

NAME="foo:Name=MyMBean" ATTRNAME="mymap(key1).a"
NAME="foo"Name=MyBean" ATTRNAME LIKE "mymap(%).a"
NAME="fooName=MyMBean" ATTRNAME MATCHES "mymap\((.*?)\).a"

監視ルール・インスタンス名でのワイルドカードの使用

ハーベスタの監視ルールでは、「*」ワイルドカードを使用してObjectNameの一部を指定でき、複数の型の複数のインスタンスを監視することができます。

たとえば、名前がmanagedで始まるServerRuntimeMBeanのすべてのインスタンスのOpenSocketsCurrentCount属性を指定するには、次の構文を使用します。

${com.bea:*Name=managed*Type=ServerRuntime*//OpenSocketCurrentCount}

または、次のようにJMX ObjectName問合せパターンを使用することもできます。

${mydomain:Key1=MyMBean,*//simpleAttribute}

注意:
ハーベスタでサポートされるObjectName問合せパターン構文は、基底のJMX実装でサポートされているものになります。上記の例では、バージョン5以降のJDKでサポートされている構文を示しています。サポートされる完全な構文のためにサーバーを実行するのに使用される特定のJDKバージョンのためにjavax.management.ObjectNameについてJavaDocを参照してください。

ハーベスタの監視ルールでの複合属性の指定

ハーベスタの監視ルール式では複合属性(集合、配列型、または組込みの属性型がネストされているオブジェクト)を指定できます。複合属性は複数の方法で指定できます。

次の例では、複合型のネストされた属性へのドリルダウンを示しており、それが0より大きいかどうかを確認しています。

${somedomain:name=MyMbean//complexAttribute.nestedAttribute} > 0

ワイルドカードを使用すると、複数のマップ・キーを指定することもできます。複合属性の指定には以下のワイルドカードを使用できます。

- * :このワイルドカードを使用すると、マップ属性のすべてのキー値を指定できます。

- % :このワイルドカードを使用すると、マップ・キー文字列の一部を置き換え、特定のパターンに一致するキーのグループを同一に扱うことができます。

また、カンマ区切りのリストを使用すると、個々のキー値のセットを指定することができます。

この例では:

${[com.bea.foo.BarClass]//aList[*].(some%partialKey%).(aValue,bValue)} > 0

ルールはcom.bea.foo.BarClassのすべての例のaList属性のすべての要素を調べて、someテキストから始めて、その後partialKeyテキストを含むすべてのキーのためにネストされたマップに選択します。戻り値はMapインスタンスであると思われます。キーaValueとbValueのための値は、それらが0以上であるかどうか確認するために例から比較されます。

WLDFInstrumentationRuntimeタイプにMethodInvocationStatistics属性を使用するとき、システムは、変数からタイプを決定する必要があります。属性式の評価時にこの型を特定できない場合、その式は機能しません。次のような式があるとします。

${ com.bea:Name=myScope, * //MethodInvocationStatistics.(...).(...)

この式は機能しません。この場合、次のサンプル・コードに示すように、ネストされたマップ構造へドリルダウンする型を明示的に宣言する必要があります。

$(com.bea:Name=hello,Type=WLDFInstrumentationRuntime,*//MethodInvocationStatistics(*)(*)(*)(count)) >= 1

D WebLogic Scripting Toolのサンプル

以下のサンプルでは、WLSTおよびJMXを使用してWLDFコンポーネントと対話します。

- サンプル: DyeInjectionモニターの動的な作成

- 例: 監視とJMX通知の構成

- サンプル: JMXWatchNotificationListenerクラスの記述

- サンプル:収集用のMBeanと属性の登録

- 例: WLDF診断ボリュームの設定

- 例: 診断イメージのキャプチャ

- 例: 診断イメージ・キャプチャからのJFRファイルの取得

WebLogic Scripting Tool (weblogic.WLST)スクリプトの実行は、『Oracle WebLogic Scripting Tool』のAntからのWLSTの実行に関する項を参照してください。JMXアプリケーションの開発の詳細は、『Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発』を参照してください。

サンプル: DyeInjectionモニターの動的な作成

このデモ・スクリプトでは(例D-1を参照)、weblogic.WLSTツールを使用して動的にDyeInjectionモニターを作成する方法について示します。このスクリプトでは以下のことを行います。

- サーバーに接続し、必要な場合には始めにサーバーを起動します。

- WLDFシステム・リソースをルックアップまたは作成します。

- DyeInjectionモニターを作成します。

- 仕分け条件を指定します。

- モニターを有効にします。

- 構成を保存してアクティブ化します。

- ServerDiagnosticConfigMBeanを介して診断コンテキスト機能を有効にします。

例D-1のデモ・スクリプトは、診断コンテキストへ仕分け値をインジェクションする仕分けモニターのみを構成します。イベントをトリガーするには、指定された仕分け条件に基づいて仕分けフィルタを使用してトリガーする下流工程の診断モニターを実装する必要があります。下流工程のモニター・アーティファクトの例は、例D-2に示します。これはweblogic-diagnostics.xmlのファイルに設定して、アプリケーションのアーカイブのMETA-INFディレクトリに配置する必要があります。JSR-88のデプロイメント・プランを使用してモニターを作成することも可能です。アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

例D-1 例: WLSTを使用したDyeInjectionモニター(demoDyeMonitorCreate.py)の動的な作成

# Script name: demoDyeMonitorCreate.py
#########################################################################
# Demo script showing how to create a DyeInjectionMonitor dynamically
# via WLST. This script will:
# - Connect to a server, booting it first if necessary
# - Look up or create a WLDF System Resource
# - Create the DyeInjection Monitor (DIM)
# - Set the dye criteria
# - Enable the monitor
# - Save and activate
# - Enable the Diagnostic Context functionality via the
#   ServerDiagnosticConfig MBean
# Note: This will only configure the dye monitor, which will inject dye
# values into the Diagnostic Context.  To trigger events requires the
# existence of "downstream" monitors set to trigger on the specified
# dye criteria.
##########################################################################
myDomainDirectory="domain"
url="t3://localhost:7001"
user="weblogic"
password="weblogic"
myServerName="myserver"
myDomain="mydomain"
props="weblogic.GenerateDefaultConfig=true,weblogic.RootDirectory="\
+myDomainDirectory
try:
connect(user,password,url)
except:
startServer(adminServerName=myServerName,domainName=myDomain,
username=user,password=password,systemProperties=props,
domainDir=myDomainDirectory,block="true")
connect(user,password,url)
# Start an edit session
edit()
startEdit()
cd ("/")
# Look up or create the WLDF System resource.
wldfResourceName = "mywldf"
myWldfVar = cmo.lookupSystemResource(wldfResourceName)
if myWldfVar==None:
print "Unable to find named resource,\
creating WLDF System Resource: " + wldfResourceName
myWldfVar=cmo.createWLDFSystemResource(wldfResourceName)
# Target the System Resource to the demo server.
wldfServer=cmo.lookupServer(serverName)
myWldfVar.addTarget(wldfServer)
# create and set properties of the DyeInjection Monitor (DIM).
mywldfResource=myWldfVar.getWLDFResource()
mywldfInst=mywldfResource.getInstrumentation()
mywldfInst.setEnabled(1)
monitor=mywldfInst.createWLDFInstrumentationMonitor("DyeInjection")
monitor.setEnabled(1)
# Need to include newlines when setting properties
# on the DyeInjection monitor.
monitor.setProperties("\nUSER1=larry@celtics.com\
\nUSER2=brady@patriots.com\n")
monitor.setDyeFilteringEnabled(1)
# Enable the diagnostic context functionality via the
# ServerDiagnosticConfig.
cd("/Servers/"+serverName+"/ServerDiagnosticConfig/"+serverName)
cmo.setDiagnosticContextEnabled(1)
# save and disconnect
save()
activate()
disconnect()
exit()

例D-2 例:下流工程のモニター・アーティファクト

<?xml version="1.0" encoding="UTF-8"?>
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<instrumentation>
<enabled>true</enabled>
<!-- Servlet Session Monitors -->
<wldf-instrumentation-monitor>
<name>Servlet_Before_Session</name>
<enabled>true</enabled>
<dye-mask>USER1</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>TraceAction</action>
<action>StackDumpAction</action>
<action>DisplayArgumentsAction</action>
<action>ThreadDumpAction</action>
</wldf-instrumentation-monitor>
<wldf-instrumentation-monitor>
<name>Servlet_After_Session</name>
<enabled>true</enabled>
<dye-mask>USER2</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>TraceAction</action>
<action>StackDumpAction</action>
<action>DisplayArgumentsAction</action>
<action>ThreadDumpAction</action>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>

例:監視とJMX通知の構成

このデモ・スクリプトでは(例D-3を参照してください)、weblogic.WLSTツールを用いて、WLDFの監視および通知コンポーネントを使用する、監視とJMX通知を構成する方法を示します。このスクリプトでは以下のことを行います。

- サーバーに接続し、必要な場合には始めにサーバーを起動します。

- WLDFシステム・リソースをルックアップまたは作成します。

- ServerRuntimeMBeanにOpenSocketsCurrentCount属性用の監視と監視ルールを作成します。

- JMX通知手段を使用するように監視を構成します。

このスクリプトは以下のファイルおよびスクリプトと連携させることで使用できます。

- JMXWatchNotificationListener.javaクラス(「サンプル: JMXWatchNotificationListenerクラスの記述」を参照)。

- 収集するためにハーベスタにOpenSocketsCurrentCount属性を登録するdemoHarvester.pyスクリプト(「例:収集用のMBeanと属性の登録」を参照してください。)

これらのファイルを連携させるには、以下の手順を実行します。

1. 次のように入力して、監視の構成スクリプト(demoWatch.py)を実行します。

java weblogic.WLST demoWatch.py

2. 次のように入力して、JMXWatchNotificationListener.javaソースをコンパイルします。

javac JMXWatchNotificationListener.java

3. 次のように入力して、JMXWatchNotificationListener.classファイルを実行します。

java JMXWatchNotificationListener

注意:
前の手順で作成したクラスが見つかるよう、カレント・ディレクトリがクラス・パス内にあることを確認してください。

4. 次のように入力して、demoHarvester.pyスクリプトを実行します。

java weblogic.WLST demoHarvester.py

demoHarvester.pyスクリプトを実行すると、ステップ1で構成された監視のJMX通知がトリガーされます。

例D-3 例: 監視とJMX通知(demoWatch.py)

# Script name: demoWatch.py
##########################################################################
# Demo script showing how to configure a Watch and a JMXNotification
# using the WLDF Watches and Notification framework.
# The script will:
# - Connect to a server, booting it first if necessary
# - Look up or create a WLDF System Resource
# - Create a watch and watch rule on the ServerRuntimeMBean for the
#     "OpenSocketsCurrentCount" attribute
# - Configure the watch to use a JMXNotification medium
#
# This script can be used in conjunction with
# - the JMXWatchNotificationListener.java class
# - the demoHarvester.py script, which registers the
#   "OpenSocketsCurrentCount" attribute with the harvester for collection.
# To see these work together:
# 1. Run the watch configuration script
#       java weblogic.WLST demoWatch.py
# 2. Compile and run the JMXWatchNotificationListener.java source code
#       javac JMXWatchNotificationListener.java
#         java JMXWatchNotificationListener
# 3. Run the demoHarvester.py script
#       java weblogic.WLST demoHarvester.py
# When the demoHarvester.py script runs, it triggers the
# JMXNotification for the watch configured in step 1.
#########################################################################
myDomainDirectory="domain"
url="t3://localhost:7001"
user="weblogic"
myServerName="myserver"
myDomain="mydomain"
props="weblogic.GenerateDefaultConfig=true\
weblogic.RootDirectory="+myDomainDirectory
try:
connect(user,user,url)
except:
startServer(adminServerName=myServerName,domainName=myDomain,
username=user,password=user,systemProperties=props,
domainDir=myDomainDirectory,block="true")
connect(user,user,url)
edit()
startEdit()
# Look up or create the WLDF System resource
wldfResourceName = "mywldf"
myWldfVar = cmo.lookupSystemResource(wldfResourceName)
if myWldfVar==None:
print "Unable to find named resource"
print "creating WLDF System Resource: " + wldfResourceName
myWldfVar=cmo.createWLDFSystemResource(wldfResourceName)
# Target the System Resource to the demo server
wldfServer=cmo.lookupServer(myServerName)
myWldfVar.addTarget(wldfServer)
cd("/WLDFSystemResources/mywldf/WLDFResource/mywldf/WatchNotification/mywldf")
watch=cmo.createWatch("mywatch")
watch.setEnabled(1)
jmxnot=cmo.createJMXNotification("myjmx")
watch.addNotification(jmxnot)
serverRuntime()
cd("/")
on=cmo.getObjectName().getCanonicalName()
watch.setRuleExpression("${"+on+"} > 1")
watch.getRuleExpression()
watch.setRuleExpression("${"+on+"//OpenSocketsCurrentCount} > 1")
watch.setAlarmResetPeriod(10000)
edit()
save()
activate()
disconnect()
exit()

サンプル: JMXWatchNotificationListenerクラスの記述

例D-4に、JMXWatchNotificationListenerの記述方法について示します。

例D-4 例: JMXWatchNotificationListenerクラス(JMXWatchNotificationListener.java)

import javax.management.*;
import weblogic.diagnostics.watch.*;
import weblogic.diagnostics.watch.JMXWatchNotification;
import javax.management.Notification;
import javax.management.remote.JMXServiceURL;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXConnector;
import javax.naming.Context;
import java.util.Hashtable;
import weblogic.management.mbeanservers.runtime.RuntimeServiceMBean;
public class JMXWatchNotificationListener implements NotificationListener, Runnable {
private MBeanServerConnection rmbs = null;
private String notifName = "myjmx";
private int notifCount = 0;
private String serverName = "myserver";
public JMXWatchNotificationListener(String serverName) {
}
public void register() throws Exception {
rmbs = getRuntimeMBeanServerConnection();
addNotificationHandler();
}
public void handleNotification(Notification notif, Object handback) {
synchronized (this) {
try {
if (notif instanceof JMXWatchNotification) {
WatchNotification wNotif =
((JMXWatchNotification)notif).getExtendedInfo();
notifCount++;
System.out.println("===============================================");
System.out.println("Notification name:    " +
notifName + " called. Count= " + notifCount + ".");
System.out.println("Watch severity:         " +
wNotif.getWatchSeverityLevel());
System.out.println("Watch time:             " +
wNotif.getWatchTime());
System.out.println("Watch ServerName:       " +
wNotif.getWatchServerName());
System.out.println("Watch RuleType:         " +
wNotif.getWatchRuleType());
System.out.println("Watch Rule:             " +
wNotif.getWatchRule());
System.out.println("Watch Name:             " +
wNotif.getWatchName());
System.out.println("Watch DomainName:       " +
wNotif.getWatchDomainName());
System.out.println("Watch AlarmType:        " +
wNotif.getWatchAlarmType());
System.out.println("Watch AlarmResetPeriod: " +
wNotif.getWatchAlarmResetPeriod());
System.out.println("===============================================");
}
} catch (Throwable x) {
System.out.println("Exception occurred processing JMX watch
notification: " + notifName +"\n" + x);
x.printStackTrace();
}
}
}
private void addNotificationHandler() throws Exception {
/*
* The JMX Watch notification listener registers with a Runtime MBean
* that matches the name of the corresponding watch bean.
* Each watch has its own Runtime MBean instance.
*/
ObjectName oname =
new ObjectName(
"com.bea:ServerRuntime=" + serverName + ",Name=" +
JMXWatchNotification.GLOBAL_JMX_NOTIFICATION_PRODUCER_NAME +
",Type=WLDFWatchJMXNotificationRuntime," +
"WLDFWatchNotificationRuntime=WatchNotification," +
"WLDFRuntime=WLDFRuntime"
);
System.out.println("Adding notification handler for: " +
oname.getCanonicalName());
rmbs.addNotificationListener(oname, this, null, null);
}
private void removeNotificationHandler(String name,
NotificationListener list) throws Exception {
ObjectName oname =
new ObjectName(
"com.bea:ServerRuntime=" + serverName + ",Name=" +
JMXWatchNotification.GLOBAL_JMX_NOTIFICATION_PRODUCER_NAME +
",Type=WLDFWatchJMXNotificationRuntime," +
"WLDFWatchNotificationRuntime=WatchNotification," +
"WLDFRuntime=WLDFRuntime"
);
System.out.println("Removing notification handler for: " +
oname.getCanonicalName());
rmbs.removeNotificationListener(oname, list);
}
public void run() {
try {
System.out.println("VM shutdown, unregistering notification
listener");
removeNotificationHandler(notifName, this);
} catch (Throwable t) {
System.out.println("Caught exception in shutdown hook");
t.printStackTrace();
}
}
private String user = "weblogic";
private String password = "weblogic";
public MBeanServerConnection getRuntimeMBeanServerConnection()
throws Exception {
String JNDI = "/jndi/";
JMXServiceURL serviceURL;
serviceURL =
new JMXServiceURL("t3", "localhost", 7001,
JNDI + RuntimeServiceMBean.MBEANSERVER_JNDI_NAME);
System.out.println("URL=" + serviceURL);
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL,user);
h.put(Context.SECURITY_CREDENTIALS,password);
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"weblogic.management.remote");
JMXConnector connector = JMXConnectorFactory.connect(serviceURL,h);
return connector.getMBeanServerConnection();
}
public static void  main(String[] args) {
try {
String serverName = "myserver";
if (args.length > 0)
serverName = args[0];
JMXWatchNotificationListener listener =
new JMXWatchNotificationListener(serverName);
System.out.println("Adding shutdown hook");
Runtime.getRuntime().addShutdownHook(new Thread(listener));
listener.register();
// Sleep waiting for notifications
Thread.sleep(Long.MAX_VALUE);
} catch (Throwable e) {
e.printStackTrace();
} // end of try-catch
} // end of main()
}

サンプル:収集用のMBeanと属性の登録

このデモ・スクリプトでは、WLDFハーベスタで収集するために、weblogic.WLSTツールを使用してMBeanおよび属性を登録する方法を示します。このスクリプトでは以下のことを行います。

- サーバーに接続し、必要な場合には始めにサーバーを起動します。

- WLDFシステム・リソースをルックアップまたは作成します。

- サンプリングの頻度を設定します。

- 収集する型を追加します。

- 収集する特定のインスタンスの属性を追加します。

- 構成を保存してアクティブ化します。

- 数サイクル分の収集対象データを表示します。

例D-5 例: MBeanの登録とデータ収集(demoHarvester.py)

# Script name: demoHarvester.py
##################################################################
# Demo script showing how register MBeans and attributes for collection
# by the WLDF Harvester Service.  This script will:
# - Connect to a server, booting it first if necessary
# - Look up or create a WLDF System Resource
# - Set the sampling frequency
# - Add a type for collection
# - Add an attribute of a specific instance for collection
# - Save and activate
#####################################################################
from java.util import Date
from java.text import SimpleDateFormat
from java.lang import Long
import jarray
#####################################################################
# Helper functions for adding types/attributes to the harvester
# configuration
#######################################################################
def findHarvestedType(harvester, typeName):
htypes=harvester.getHarvestedTypes()
for ht in (htypes):
if ht.getName() == typeName:
return ht
return None
def addType(harvester, mbeanInstance):
typeName = "weblogic.management.runtime."\
+ mbeanInstance.getType() + "MBean"
ht=findHarvestedType(harvester, typeName)
if ht == None:
print "Adding " + typeName + " to harvestables collection for "\
+ harvester.getName()
ht=harvester.createHarvestedType(typeName)
return ht;
def addAttributeToHarvestedType(harvestedType, targetAttribute):
currentAttributes = PyList()
currentAttributes.extend(harvestedType.getHarvestedAttributes());
print "Current attributes: " + str(currentAttributes)
try:
currentAttributes.index(targetAttribute)
print "Attribute is already in set"
return
except ValueError:
print targetAttribute + " not in list, adding"
currentAttributes.append(targetAttribute)
newSet = jarray.array(currentAttributes, java.lang.String)
print "New attributes for type "\
+ harvestedType.getName() + ": " + str(newSet)
harvestedType.setHarvestedAttributes(newSet)
return
def addTypeForInstance(harvester, mbeanInstance):
typeName = "weblogic.management.runtime."\
+ mbeanInstance.getType() + "MBean"
return addTypeByName(harvester, typeName, 1)
def addInstanceToHarvestedType(harvester, mbeanInstance):
harvestedType = addTypeForInstance(harvester, mbeanInstance)
currentInstances = PyList()
currentInstances.extend(harvestedType.getHarvestedAttributes());
on = mbeanInstance.getObjectName().getCanonicalName()
print "Adding " + str(on) + " to set of harvested instances for type "\
+ harvestedType.getName()
print "Current instances : " + str(currentInstances)
for inst in currentInstances:
if inst == on:
print "Found " + on + " in existing set"
return harvestedType
# only get here if the target attribute is not in the set
currentInstances.append(on)
# convert the new list back to a Java String array
newSet = jarray.array(currentInstances, java.lang.String)
print "New instance set for type " + harvestedType.getName()\
+ ": " + str(newSet)
harvestedType.setHarvestedInstances(newSet)
return harvestedType
def addTypeByName(harvester, _typeName, knownType=0):
ht=findHarvestedType(harvester, _typeName)
if ht == None:
print "Adding " + _typeName + " to harvestables collection for "\
+ harvester.getName()
ht=harvester.createHarvestedType(_typeName)
if knownType == 1:
print "Setting known type attribute to true for " + _typeName
ht.setKnownType(knownType)
return ht;
def addAttributeForInstance(harvester, mbeanInstance, attributeName):
typeName = mbeanInstance.getType() + "MBean"
ht = addInstanceToHarvestedType(harvester, mbeanInstance)
return addAttributeToHarvestedType(ht,attributeName)
#####################################################################
# Display the currently registered types for the specified harvester
#######################################################################
def displayHarvestedTypes(harvester):
harvestedTypes = harvester.getHarvestedTypes()
print ""
print "Harvested types:"
print ""
for ht in (harvestedTypes):
print "Type: " + ht.getName()
attributes = ht.getHarvestedAttributes()
if attributes != None:
print "  Attributes: " + str(attributes)
instances = ht.getHarvestedInstances()
print "  Instances:  " + str(instances)
print ""
return
########################################################################
# Main script flow -- create a WLDF System resource and add harvestables
########################################################################
myDomainDirectory="domain"
url="t3://localhost:7001"
user="weblogic"
myServerName="myserver"
myDomain="mydomain"
props="weblogic.GenerateDefaultConfig=true,weblogic.RootDirectory="\
+myDomainDirectory
try:
connect(user,user,url)
except:
startServer(adminServerName=myServerName,domainName=myDomain,
username=user,password=user,systemProperties=props,
domainDir=myDomainDirectory,block="true")
connect(user,user,url)
# start an edit session
edit()
startEdit()
cd("/")
# Look up or create the WLDF System resource
wldfResourceName = "mywldf"
systemResource = cmo.lookupSystemResource(wldfResourceName)
if systemResource==None:
print "Unable to find named resource,\
creating WLDF System Resource: " + wldfResourceName
systemResource=cmo.createWLDFSystemResource(wldfResourceName
# Obtain the harvester bean instance for configuration
print "Getting WLDF Resource Bean from " + str(wldfResourceName)
wldfResource = systemResource.getWLDFResource()
print "Getting Harvester Configuration Bean from " + wldfResourceName
harvester = wldfResource.getHarvester()
print "Harvester: " + harvester.getName()
# Target the WLDF System Resource to the demo server
wldfServer=cmo.lookupServer(myServerName)
systemResource.addTarget(wldfServer)
# The harvester Jython wrapper maintains refs to
# the SystemResource objects
harvester.setSamplePeriod(5000)
harvester.setEnabled(1)
# add an instance-based RT MBean attribute for collection
serverRuntime()
cd("/")
addAttributeForInstance(harvester, cmo, "OpenSocketsCurrentCount")
# have to return to the edit tree to activate
edit()
# add a RT MBean type, all instances and attributes,
# with KnownType = "true"
addTypeByName(harvester,
"weblogic.management.runtime.WLDFInstrumentationRuntimeMBean", 1)
addTypeByName(harvester,
"weblogic.management.runtime.WLDFWatchNotificationRuntimeMBean", 1)
addTypeByName(harvester,
"weblogic.management.runtime.WLDFHarvesterRuntimeMBean", 1)
try:
save()
activate(block="true")
except:
print "Error while trying to save and/or activate."
dumpStack()
# display the data
displayHarvestedTypes(harvester)
disconnect()
exit()

例: WLDF診断ボリュームの設定

デフォルトでは、Oracle JRockitもWLDFもデータを収集せず、他のインスタンスに特に構成されていないかぎり、ほとんどのイベントがWebLogic Serverインスタンスに記録されます。WLDF診断ボリュームがOffに設定されている場合でも、JRockitおよびWLDFは記録設定に関する情報を持つグローバル・イベントを生成することに注意してください。たとえば、アクティブな記録をリストするJVMメタデータ・イベントおよびドメイン、サーバーおよびマシンのボリューム・レベルをリストするWLDF GlobalInformationEventsです。

例D-6では、WLDF診断ボリュームをMediumに変更する方法を示します。

例D-6 WLDF診断ボリュームの設定

connect()
edit()
startEdit()
cd("Servers/myserver")
cd("ServerDiagnosticConfig")
cd("myserver")
cmo.setWLDFDiagnosticVolume("Medium")
save()
activate()

例: 診断イメージのキャプチャ

診断イメージのキャプチャは、次のいずれかの方法でWebLogic Serverインスタンスに対して作成できます。

- WebLogic Server管理コンソール

- WLSTスクリプト

- 監視および通知コンポーネントを使用したイメージの通知

注意:
WebLogic Serverが本番モードで実行中の場合、スクリプトに含まれるコマンドを実行するときにサーバーのSSLポートを使用する必要があります。

例D-7は診断イメージをキャプチャするサンプルWLSTスクリプトを示します。この例では、次の操作を行います。

- 接続後、診断イメージをキャプチャして、イメージに関するタスクが完了するまで待機します。

- getAvailableCapturedImages()コマンドを使用してサーバーのイメージ・ディレクトリ内の使用可能な診断イメージのリストを取得します。

- 診断イメージ・キャプチャの使用可能なイメージのリストをループし、saveDiagnosticImageCaptureFile()コマンドを使用して各イメージ・ファイルをローカルに保存します。

例D-7 診断イメージ・キャプチャの作成

#
# WLST script to capture a WLDF Diagnostic Image and
# retrieve the image files to a local dir.
#
# Usage:
#
# java weblogic.WLST captureImage.py [username] [passwd] [url] [output-dir]
#
# where
#
#   username       Username to use to connect
#   passwd         Password for connecting to server
#   url            URL to connect to the server
#   output-dir     Path to place saved entries
#
from java.io import File

# Retrieve a positional argument if it exists; if not,
# the provided default is returned.
#
# Params:
# pos   The integer location in sys.argv of the parameter
# default  The default value to return if the parameter does not exist
#
# returns the value at sys.argv[pos], or the provided default if necesssary
def getPositionalArgument(pos, default):
value=None
try:
value=sys.argv[pos]
except:
value=default
return value

# Credential arguments
uname=getPositionalArgument(1, "weblogic")
passwd=getPositionalArgument(2, "welcome1")
url=getPositionalArgument(3, "t3://localhost:7001")
outputDir=getPositionalArgument(4, ".")

connect(uname, passwd, url)
serverRuntime()
currentDrive=currentTree()

# Capture a new diagnostic image
try:
cd("serverRuntime:/WLDFRuntime/WLDFRuntime/WLDFImageRuntime/Image")
task=cmo.captureImage()
Thread.sleep(1000)
while task.isRunning():
Thread.sleep(5000)
cmo.resetImageLockout();
finally:
currentDrive()

# List the available diagnostic image files in the server's image capture dir
images=getAvailableCapturedImages()
if len(images) > 0:
# For each diagnostic image found, retrieve image file, renaming it as
# the user sees fit
for image in images:
saveName=outputDir+File.separator+serverName+'-'+image
saveDiagnosticImageCaptureFile(image,saveName)

例: 診断イメージ・キャプチャからのJFRファイルの取得

次の例では、サーバーのイメージ宛先ディレクトリにある各診断イメージ・キャプチャからのJRockitフライト記録(JFR)ファイルの取得およびローカル・ディレクトリへのコピーを示します。このスクリプト例では次の事項を実行します。

- 必要な資格証明を渡してWebLogic Serverに接続します。

- 診断イメージ・キャプチャを作成します。

- サーバーに構成されたイメージ・ディレクトリ内の使用可能な診断イメージ・ファイルのリストを取得します。

- 各診断イメージ・ファイルに対して、JFRファイルの取得を試み、ファイルの上書きを防止するために各ファイル名が必要に応じて変更されていることを確認してローカル・ディレクトリに保存します。

注意:
WebLogic Serverが本番モードで実行中の場合、スクリプトに含まれるコマンドを実行するときにサーバーのSSLポートを使用する必要があります。

例D-8 診断イメージ・キャプチャ・ファイルの取得

#
# WLST script to capture a WLDF Diagnostic Image and
# save the FlightRecording.jfr entry locally
#
# Usage:
#
# java weblogic.WLST captureImageEntry.py [username] [passwd] [url] [output-dir] [image-suffix]
#
# where
#
#   username       Username to use to connect
#   passwd         Password for connecting to server
#   url            URL to connect to the server
#   output-dir     Path to place saved entries
#   image-suffix   Suffix to use to rename JFR image entries locally
#
import os.path
from java.io import File

# Retrieve a positional argument if it exists; if not,
# the provided default is returned.
#
# Params:
# pos   The integer location in sys.argv of the parameter
# default  The default value to return if the parameter does not exist
#
# returns the value at sys.argv[pos], or the provided default if necesssary
def getPositionalArgument(pos, default):
value=None
try:
value=sys.argv[pos]
except:
value=default
return value

# Credential arguments
uname=getPositionalArgument(1, "weblogic")
passwd=getPositionalArgument(2, "welcome1")
url=getPositionalArgument(3, "t3://localhost:7001")
outputDir=getPositionalArgument(4, ".")
imageSuffix=getPositionalArgument(5, "_WLS")

connect(uname, passwd, url)
serverRuntime()
currentDrive=currentTree()

# Capture a new diagnostic image capture file
try:
cd("serverRuntime:/WLDFRuntime/WLDFRuntime/WLDFImageRuntime/Image")
task=cmo.captureImage()
Thread.sleep(1000)
while task.isRunning():
Thread.sleep(5000)
cmo.resetImageLockout();
finally:
currentDrive()

# List the available diagnostic image captures in the server's image capture dir
images=getAvailableCapturedImages()
if len(images) > 0:
# For each image capture found, retrieve the JFR entry and save it to a local
# file, renaming it to avoid collisions in the event there are multiple
# diagnostic image capture files with JFR entries.
i=0
for image in images:
saveName=outputDir+File.separator+"FlightRecording_"+imageSuffix+"-"+str(i)+".jfr"
while os.path.exists(saveName):
i+=1
saveName=outputDir+File.separator+"FlightRecording_"+imageSuffix+"-"+str(i)+".jfr"
saveDiagnosticImageCaptureEntryFile(image,'FlightRecording.jfr',saveName)
i+=1

用語集

診断およびモニターに関するドキュメントで扱う主な用語は以下のとおりです。

アーティファクト

WebLogic診断フレームワークで生成され、ディスクに保存された、物理的なエンティティまたはデータ。後で診断を解析するために使用できます。たとえば、サーバーで障害が発生したときに作成される診断イメージ・ファイルはアーティファクトです。この診断イメージ・アーティファクトは、サーバーの障害の原因を判断するための解析を行うサポート担当者用に提供されます。WebLogic診断フレームワークでは、多様なアーティファクトが数多く作成されます。

コンテキスト作成

診断モニター機能が有効になっている場合、システムにリクエストが届いたときにWebLogic Serverによって診断コンテキストが作成され、初期化されて設定されます。WebLogic Serverでは、リクエストが届いたときにそのリクエストに診断コンテキストが付属しているかどうかが判断されます。付属している場合、リクエストはその所定のコンテキストと共に伝播されます。付属していない場合、新しいコンテキストが特定の名前(weblogic.management.DiagnosticContext)で作成されます。診断コンテキストのコンテキスト・データは、診断コンテキスト・ペイロードに格納されます。したがって、リクエストが実行中である間は必ず診断コンテキストがあることになります。

コンテキスト・ペイロード

診断コンテキストの実際のコンテキスト・データの格納先。「コンテキスト作成」、「診断コンテキスト」、「リクエストの仕分け」も参照してください。

データ・ストア

表形式で表されたデータ(レコード)の集合。表の各レコードがデータを表します。表の列にはデータのいろいろな特性が記述されます。様々なデータ・ストアに多様な列があり得ますが、データ項目が収集された時間など、ほとんどのデータ・ストアで共有される列もあります。

WebLogic Serverでは、WebLogic診断フレームワークでキャプチャした情報は複数の論理データ・ストアに分類されて格納されます。論理データ・ストアは診断データのタイプ別に分かれています。たとえば、サーバー・ログ、HTTPログ、収集されたメトリックは、それぞれ別のデータ・ストアにキャプチャされます。

診断アクション

ポイントカットで定義されているジョインポイントに到達したときに実行される、ビジネス・ロジックまたは診断コード。診断アクションは特定のポイントカットに関連付けられます。診断アクションにはジョインポイントで実行するコードが指定されます。別の言い方で言うと、ポイントカットでは場所が宣言され、診断アクションではそのポイントカットが特定する場所で何が実行されるかが宣言されます。

診断アクションを使用すると、実行中のサーバーおよびアプリケーションの状態を認識できます。診断アクティビティは、場所またはポイントカットで実行される診断アクション(実装されるモニターによって定義される)を指定します。診断モニターはアクションが定義されていて初めて実用に役立ちます。

診断アクションの機能によっては、指定された作業をするために特定の環境が必要なことがあります。そうした環境は必ず、その診断アクションが関連付けられているモニターで提供されます。したがって、診断アクションは対応するモニターとのみ使用できます。そのため、診断アクションはタイプ別に分類されていて、対応するモニターを判断できるようになっています。

有用な診断モニターを簡単に実装できるようにするため、WebLogic Server製品には適切な診断アクションのライブラリが用意されています。

診断コンテキスト

WebLogic診断フレームワークは、すべてのリクエストがシステムに届いたときにコンテキスト情報を付加します。このコンテキスト情報は診断コンテキストと呼ばれ、これを使用してトランザクション・イベントを再構築したり、発生の時期や論理的な関係に基づいてイベントを相互に関連付けたりできます。診断コンテキストを使用すると、リクエストからレスポンスまでの実行の流れを再構築したりつなぎ合わせたりできます。

診断コンテキストは、ロギング・サービスや診断モニターなどの様々な診断コンポーネントを使用して、生成されたデータ・イベントへのタグ付けをします。このタグを使用して、診断データの照合、フィルタ処理、WebLogic診断フレームワークやサード・パーティのツールで相互の関連付けができます。

また診断コンテキストでは、診断コンテキスト内のコンテキスト情報が一定の基準を満たしている場合にのみ、診断情報が生成されるようにもできます。この機能により、生成される情報量を管理可能なレベルに保つことで、そのような情報生成のオーバーヘッドを比較的低く抑えておけます。「コンテキスト作成」、「コンテキスト・ペイロード」、「リクエストの仕分け」も参照してください。

診断イメージ

サーバーのインスタンスから得られた主要な状態を格納するアーティファクト。重大な障害の診断目的でサーバー・レベルの状態ダンプとして利用するために作成されます。このアーティファクトを使用すると、サーバーの電源をいったん切って入れなおした後にも問題を診断して分析できます。

診断モジュール

WebLogic診断フレームワークに適用される構成設定の定義。この構成設定により、収集して処理するデータ、そのデータの分析方法とアーカイブ方法、発生させる通知と警告、および診断イメージ・キャプチャ・コンポーネントの操作パラメータが決まります。診断モジュールは定義(構成)されると、収集されるデータのある実行中のサーバーに配布できます。

診断モニター

次の内容を定義する診断コードの単位。

1. 診断コードを追加するプログラムの場所

2. プログラムの場所で実行される診断アクション

WebLogic Serverには、有用な診断モニターのライブラリが用意されています。それらのモニターをサーバー・クラスやアプリケーション・クラスに統合できます。統合した後には、サーバー・クラスについてはサーバーの起動時、アプリケーション・クラスについてはアプリケーションのデプロイメントまたは再デプロイメント時に、モニターが有効になります。

診断通知

監視ルールの評価に合格した結果として発生するアクション。WebLogic診断フレームワークでは、Java Management Extensions (JMX)、Java Message Service (JMS)、Simple Mail Transfer Protocol (SMTP)、Simple Network Management Protocol (SNMP)、およびWLDFイメージ・キャプチャの種類の診断通知がサポートされています。「診断イメージ」も参照してください。

仕分けフィルタ

仕分けマスクを確認し、診断モニターでデータ・イベントを生成するためにアクションを実行すべきかどうかを決定するプロセス。仕分けフィルタは仕分けマスクに依存しています。仕分けフィルタ処理を行うには、仕分けマスクを定義する必要があります。「仕分けマスク」および「リクエストの仕分け」も参照してください。

仕分けマスク

データ・イベントを生成するかしないかを決定するために診断モニターの仕分けフィルタで使用する、あらかじめ定義された一連の条件を格納するエンティティ。「仕分けフィルタ」および「リクエストの仕分け」も参照してください。

収集可能エンティティ

ハーベスタを介してデータの消費に利用できる任意のエンティティ。エンティティが収集可能なリソースとして識別されると、ハーベスタでそのエンティティをデータ収集のプロセスに関与させられるようになります。

収集可能エンティティでは、次の情報へのアクセスが提供されます。収集可能な属性、収集可能な属性の値、収集可能な属性のメタデータ、および収集可能エンティティの名前。「収集可能データ」、「収集対象データ」、「ハーベスタ構成データ・セット」、「MBean型検出」も参照してください。

収集可能データ

収集可能データ(型、インスタンス、属性)とは、収集可能なエンティティが収集対象として構成された場合に収集される可能性のあるデータのセット。したがって、収集可能データのセットは、どのデータが収集されるように構成されているか、またどのデータ・サンプルが取得されるかという指定とは無関係に存在します。

WLDFHarvesterRuntimeMBeanは収集可能データのセットをユーザーに提供します。このMbeanによって提供された収集可能データの情報の記述に関しては、weblogic.management.runtimeの説明を参照してください。Oracle WebLogic Server MBeanリファレンスのWLDFHarvesterRuntimeMBeanに関する項を参照してください。

WebLogic診断フレームワークでは、ランタイムMBeanが単に収集可能になり得る状態として提供されます。MBeanを収集可能な状態にするには、そのMBeanがローカルのWebLogic ServerランタイムMBeanサーバーに登録されている必要があります。「収集可能エンティティ」、「収集対象データ」、「ハーベスタ構成データ・セット」、「MBean型検出」も参照してください。

収集対象データ

現在収集されている型、インスタンス、または属性。この定義の基準に合致するデータは、1)収集されるように構成されていて、2)これに該当する場合には必ず検出されていて、3)収集されている間に例外がスローされない必要があります。

「収集可能エンティティ」、「収集可能データ」、「ハーベスタ構成データ・セット」も参照してください。

ハーベスタ構成データ・セット

ハーベスタの構成に定義されているとおりに収集されるデータのセット。構成されるデータのセットには、収集可能でない項目や現在収集されていない項目も含められます。

「収集可能エンティティ」、「収集可能データ」、「ハーベスタ構成データ・セット」も参照してください。

ジョインポイント

プログラム・フロー中に明確に定義された、診断コードを追加できる場所。インストゥルメンテーション・コンポーネントでは、このような診断ジョインポイントを一般的な式で表して識別できます。

ポイントカット

明確に定義されたジョインポイントのセット。通常、一般的な式で識別されます。ポイントカットにより、ジョインポイントが識別されます。ジョインポイントは、メソッド呼出しやメソッド実行サイトなどの実行フロー中の明確なポイントです。インストゥルメンテーション・コンポーネントのメカニズムを使用すると、このようなポイントカットで特定の診断コードを実行できます。そうした診断コードは、インストゥルメンテーション・コンポーネントによってサーバー・コードやアプリケーション・コードに追加されます。

MBean(マネージドBean)

基底のリソースの管理インタフェースを提供するJavaオブジェクト。MBeanはJava Management Extensions (JMX)の一部です。

WebLogic診断フレームワークでは、MBeanクラスを使用してサービスを構成し、サービスの実行時状態をモニターします。MBeanは、WebLogic Serverの内部で稼動するMBeanサーバーに登録されます。MBeanは、標準MBeanとして実装されます。つまり、各クラスに独自のMBeanインタフェースが実装されます。

MBean型検出

WebLogic Serverエンティティについては、収集可能な型のセットはシステムの起動時に明らかですが、収集可能なインスタンスの完全なセットは不明です。一方、カスタム定義のMBeanについては、実行時にMBeanが増えると、型のセットも動的に増大します。新しいMBeanの登録に基づいて新しい型を検出するプロセスを、型検出と呼びます。MBean型検出は、ユーザー作成MBeanにのみ適用されます。

MBean型のメタデータ

型(またはその型のインスタンス)において収集可能な属性のセットは、その型のメタデータで定義されます。WebLogic ServerモデルがMBeansであるので、MBeanInfosを通してメタデータを提供します。WebLogicタイプ情報がいつも利用可能であるので、また、WebLogic Serverタイプ(そして、存在と潜在的インスタンス)のための収集可能な属性のセットもいつも利用可能です。一方、カスタム定義の型では、その型が存在するかどうかによって収集可能な属性のセットが認識されるかどうかが決まります。型が存在するようになるのは、少なくとも1つのインスタンスが作成されたときからです。そのため、ユーザー定義の型の収集可能な属性のリストは、その型のインスタンスが少なくとも1つ登録されるまでは不明です。

カスタムMBeanの情報が利用可能になるまでのレイテンシについて留意しておくことは重要です。このレイテンシがあることにより、管理コンソールではハーベスタを構成するためにユーザーが選択したリストですべての収集可能データを一覧表示できません。WebLogic Serverエンティティの収集可能データのセットは常に完全なものですが、カスタム定義のエンティティの収集可能データのセットは(さらにはエンティティのセット自体も)不完全な場合があります。

メタデータ

WebLogic診断フレームワークで収集する情報を説明する情報です。このサービスではさまざまなソースから診断情報を収集するため、どの診断情報が収集され利用できるのかをその情報を消費する側で認識する必要があります。このようなニーズを満たすために、このメタデータをプログラム的に取得する機能がデータ・アクセサに備わっています。データ・アクセサを使用して入手できるメタデータには次のようなものがあります。1)サポートされているデータ・ストアのタイプのリスト。たとえば、SERVER_LOG、HTTP_LOG、HARVESTED_DATA。2)利用可能なデータ・ストアのリスト。3)各データ・ストアのレイアウト(データ・ストア内の列の情報)。

メトリック

システム処理のモニターや問題の診断は、実行中のシステムから取得したデータに基づいて行われます。メトリックは、システムのパフォーマンスの測定値です。サポート担当者は、こうした測定値からシステムが正常に動作しているのか問題が生じているのかを判断できます。

通常、メトリックは限定されたMBeanの属性としてWebLogic診断フレームワークに公開されます。WebLogic Serverにおけるメトリックには、オペレーティング・システム、仮想マシン、システム・ランタイム、およびサーバーで実行中のアプリケーションに関するパフォーマンス測定値があります。

リクエストの仕分け

リクエストが重要であることを示すために、そのリクエストを仕分け(特別にマーク)できます。たとえば、実行中のシステムで特別にマークされたテスト・リクエストを送信して、そのリクエストを追跡用のモニターで条件付きで追跡できるようにすることが望ましい場合があります。この仕分け機能を利用すると、特別に焦点を絞った診断情報を作成できます。それによって他のリクエストの処理が遅くなることもありません。

通常、リクエストはシステムに届いたときに診断コンテキストでフラグを設定することによりマークされます。診断コンテキストには多数のフラグが用意されています。これらは全部で64個で、個別に設定したりリセットしたりできます。

「コンテキスト作成」、「コンテキスト・ペイロード」、「診断コンテキスト」を参照してください。

システム・イメージ・キャプチャ

システム障害の際には、必ず障害が発生したときのシステム状態の確認が必要になります。そのため、障害の診断には障害発生時のシステム状態をキャプチャする手段が重要な意味を持ちます。その手段がシステム・イメージ・キャプチャです。システム・イメージ・キャプチャでは基本的に、重大な障害の診断を目的としてシステムから診断スナップショット(ダンプ)が作成されます。

WebLogic ServerではWebLogic診断フレームワークを構成することにより、その第一障害通知機能でサーバーが異常停止した際に自動的にシステム・イメージ・キャプチャをトリガーできます。また、監視を実装して重大な障害の発生時に自動的に診断イメージ・キャプチャをトリガーしたり、必要に応じて手動で診断イメージ・キャプチャを開始したりできます。

監視

監視ルールに関するすべての情報がカプセル化されたもの。監視には、監視ルール式、監視に対するアラームの設定、および監視ルール式がtrueと評価されると開始される様々な通知ハンドラが格納されます。

ウィービング時間

必要に応じて、クラス・ロード時に、サーバー・クラスやアプリケーション・クラスを検査して特定の場所に診断バイト・コードを挿入するのにかかる時間。診断バイト・コードを使用するとWebLogic診断フレームワークで診断アクションを実行できます。ウィービング時間は、サーバー・レベルでインストゥルメントされたクラスのロード時間とアプリケーション・レベルのクラスのアプリケーション・デプロイメント時間の両方に影響します。

Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved.