| Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.2.0) E82864-01 |
|
 前 |
 次 |
スケジュール済ポリシーでは、特定のスケジュールに応じてランタイムMBeanによって生成される診断データをモニターします。これらのポリシーを使用して、特定の時間またはスケジュールでアクションを実行することもできます。
ログ・ポリシーでは、サーバー・ログまたはドメイン・ログに生成されるメッセージをモニターします。
インストゥルメンテーション・ポリシー(イベント・データ・ポリシーとも呼ばれる)では、WLDFインストゥルメンテーション・コンポーネントによって生成されるイベントをモニターします。
この章では、各ポリシー・タイプの構成方法について説明します。この章の内容は次のとおりです。
WebLogic Server管理コンソールを使用してポリシーを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュール用のポリシーの作成に関する項を参照してください。
次のツールのいずれかを使用して、診断システム・モジュール用のポリシーを構成できます。
WebLogic Server管理コンソール
Fusion Middleware Control
WLST
REST
JMXアプリケーション
この章では、主にWebLogic Server管理コンソールまたはWLSTを使用する方法について説明します。
次の表では、ポリシーの作成時に構成する属性、要素およびオプションを要約し、同時に特定のポリシー・タイプについて各構成項目に存在する要件を示します。
| 項目 | 説明 | ポリシー要件 |
|---|---|---|
ポリシーのタイプを決定する属性。 デフォルトは、 |
ログ・ポリシーとインストゥルメンテーション・ポリシーでは指定が必須です。スケジュール済ポリシーではオプションです。 |
|
ポリシー式で使用される言語を確定する属性。サポートされる2つの言語は、Java式言語(EL)およびWLDF問合せ言語(非推奨)です。 |
すべてのポリシー・タイプでELを使用してください。WLDF問合せ言語はサポートされますが、非推奨です。 |
|
モニターまたは診断目的で捕捉する状況または条件を識別する式。式では、ルール・タイプの設定に応じてログ・レコード、データ・イベントまたはMBeanメトリックを分析できます。 |
スケジュール済ポリシーではオプションですが、他のすべてのポリシーでは必須です。 スケジュール済ポリシーに式が含まれない場合、ポリシーは、ポリシー・スケジュールに応じて常に関連するアクションを実行します。 |
|
ポリシー式が |
オプション。 |
|
スケジュール済ポリシーの評価時期を決定するカレンダ・ベースのスケジュール。 |
すべてのスケジュール済ポリシーで必須です。ログ・ポリシーまたはインストゥルメンテーション・ポリシーでは使用できません。 |
|
ポリシーが デフォルトは、 |
すべてのポリシー・タイプでオプションです。 |
|
ポリシーが
デフォルトは、 |
すべてのポリシー・タイプでオプションです。 |
|
評価に基づいてポリシーを有効化または無効化するフラグ。 デフォルトは、 |
すべてのポリシー・タイプでオプションです。 |
ポリシーを作成する場合、ルール・タイプ属性でそのタイプを定義する必要があります。ルールの種類が異なるポリシーでは、次の2つの点に違いがあります。
モニター対象となる条件を指定するための構文は、ルール・タイプごとに異なります。
ログ・ポリシーとインストゥルメンテーション・ポリシーは、リアルタイムでトリガーされますが、スケジュール済ポリシーは、「ポリシー・スケジュール」に示すとおり、WLDFScheduleBeanインタフェースの設定によってトリガーされます。
ルール・タイプの定義方法は、ポリシーの作成に使用するツールに応じて異なります。
WebLogic Server管理コンソールまたはFusion Middleware Controlを使用する場合、ルール・タイプは、作成するポリシー・タイプによって決定されます。いずれかのコンソールで選択できるポリシー・タイプごとに、次の表に、対応するルール・タイプと、そのポリシーに定義されるWLDFWatchBean.RuleType属性の値を示します。
| ポリシー・タイプ . . . | ルール・タイプ | WLDFWatchBean.RuleTypeの値 |
|---|---|---|
スマート・ルール |
ハーベスタ |
Harvester |
カレンダ・ベース |
ハーベスタ |
Harvester |
収集対象メトリック |
ハーベスタ |
Harvester |
サーバー・ログ |
ログ |
Log |
ドメイン・ログ |
ログ |
DomainLog |
イベント・データ |
インストゥルメンテーション |
EventData |
WebLogic Server管理コンソールを使用してポリシー・タイプを選択する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュール用のポリシーの作成に関する項を参照してください。
WLST、RESTまたはJMXを使用してポリシーを構成する場合、次のようにWLDFWatchBean.RuleType属性を設定します。
| ポリシー・タイプ | ルール・タイプ属性 |
|---|---|
スケジュール済ポリシー |
Harvester |
ログ・ポリシー |
|
インストゥルメンテーション |
|
ポリシー式は、次のいずれかの言語を使用して作成できます。
Java式言語(EL) (推奨)
WLDF問合せ言語(WebLogic Server 12.2.1では非推奨)
注意:
この章で説明されているポリシーは、Java ELベースです。WLDF問合せ言語を使用するポリシーの構成の詳細は、「WLDF問合せ言語ベースのポリシー」を参照してください。
以前のリリースのWebLogic Serverで作成された診断システム・モジュールがある場合、WLDFでは、WLDF問合せ言語を使用する式がサポートされます。既存の、または新しい診断システム・モジュール用に新しいポリシーを作成する場合、ポリシー式言語としてJava ELを使用することを強くお薦めします。
Java (EL)の詳細は、JSR-000341 Expression Language 3.0仕様(https://jcp.org/aboutJava/communityprocess/final/jsr341/index.html)を参照してください。
ポリシー式は、trueに評価されたときに関連するアクションを実行するルールを指定するために必要なすべての情報をカプセル化します。式言語としてJava ELを使用すると、次の即時利用可能なリソースを使用するポリシー式を構成して、関連するアクションを起動するかどうかを決定する条件を設定できます。
Bean
Beanは、MBeanからのメトリックなど、ドメイン内のほぼすべてのものを表現できるJavaオブジェクト(または他のBeanによって表面化される構造化データ)です。
関数
関数は、メトリック・データに対して呼び出すことができるEL自体またはWLDFによって提供される操作のセットです。
スマート・ルール
スマート・ルールは、より複雑なロジックおよびモニター機能をカプセル化する関数の特別なセットで、WebLogic Server管理コンソールとFusion Middleware Controlの両方で特別なサポートが提供されます。これらは、単独で使用することも、より長く複雑な式の一部として他の式コンポーネントとともに使用することもできます。
すべてのスケジュール済ポリシーは、スケジュールを使用して構成する必要があります。スケジューリングによって、ポリシーは、カレンダ・スケジュールに従って、特定の時間、一定期間の後、または指定された間隔で評価されます。
ポリシー・スケジュールを構成するには、WLDFScheduleBeanインタフェース(WLDFWatchBeanのプロパティ)で属性を設定します。これらの属性は、WebLogic Server管理コンソール、WLST、RESTまたはJMXアプリケーションを使用して設定できます。新しいポリシーを構成する場合、WebLogic Server管理コンソールおよびFusion Middleware Controlによって、共通のスケジューリング・シナリオを構成するための便利なアシスタントおよびワークフローが提供されます。
注意:
WLDFScheduleBeanは、次の場合にのみポリシー評価に使用されます。
構成されたポリシー・ルール・タイプが"Harvester"の場合。
ポリシーに構成された式言語が"EL"の場合。
スケジューリングにWLDFScheduleBeanを使用するスケジュール済ポリシーがハーベスタ・タイプとして構成されていても、WLDFハーベスタ・コンポーネントはスケジューリングに使用されないことにも注意してください。
表10-1に、WLDFScheduleBeanの属性とそのデフォルト値を示しますが、これらはjavax.ejb.ScheduleExpressionインタフェースと同じです。また、特定の時間単位の値、範囲、リストまたは間隔を指定する構文も、ScheduleExpressionインタフェースで説明されているものと同じです。詳細は、http://docs.oracle.com/javaee/7/api/javax/ejb/ScheduleExpression.htmlを参照してください。
表10-1 WLDFScheduleBeanの属性とデフォルト値
| 属性 | 説明 | デフォルト | 許容される値および例 |
|---|---|---|---|
second |
1分のうちの秒(1以上) |
0 |
許容される値: 値、範囲、リストまたは間隔を指定できます。1分のうちの 例:
|
minute |
1時間のうちの分(1以上) |
*/5 |
許容される値: 値、範囲、リストまたは間隔を指定できます。1時間のうちの 例:
|
hour |
1日のうちの時間(1以上) |
* |
許容される値: 値、範囲、リストまたは間隔を指定できます。 例:
|
dayOfWeek |
1週間のうちの日(1以上) |
* |
許容される値:
値、範囲またはリストを指定できます。例:
|
dayOfMonth |
1か月のうちの日(1以上) |
* |
許容される値:
1週間のうちの日で指定された 値、範囲またはリストを指定できます。例:
|
month |
1年のうちの月(1以上) |
* |
許容される値:
値、範囲またはリストを指定できます。例:
|
year |
特定の暦年 |
* |
許容される値: 4桁の暦年 1つの値を指定できます。例:
|
timezone |
スケジュールのタイムゾーン |
null |
デフォルトでローカルVMのタイムゾーンに設定されます。この属性を使用して、スケジュール指定を評価するコンテキストとなるデフォルト以外のタイムゾーンIDを指定できます。 |
trueに評価されたポリシーは、トリガーされたと表現されます。繰り返し実行されるポリシーの場合、ポリシーのトリガー後にそのポリシーを再度評価する時期をアラームが決定します。ポリシーがアラームを使用して構成されている場合、トリガーされたポリシーは、アラームがリセットされるまで再評価されません。繰り返し評価されるポリシーの場合、ポリシーがトリガーされた後で、ポリシーが再評価される前に経過する必要のある最小時間をオプションで定義できます。
関連するアクションが頻繁に何度も実行されることを避けるため(電子メールやJMX通知が大量に生成されるなど)、繰り返し実行されるポリシーにアラームを構成することは重要です。たとえば、動的クラスタでスケール・アップ・アクションを実行するスケジュール済ポリシーがある場合、動的クラスタが完全にスケール・アップされ、受信リクエストを処理するようになるまでポリシーの再評価を遅延させるアラームを設定する必要があります。この遅延は、アラーム・リセット期間と呼ばれます。適切なアラーム・リセット期間が存在しない場合、スケール・アップ・アクションは、早期に再実行され、逆効果となる可能性があります。
ポリシーにアラームを構成するには、次の項目を指定します。
アラーム・タイプ
アラーム・リセット期間
次の表では、使用可能な各アラーム・タイプをリストして説明します。
| アラーム・タイプ | 説明 |
|---|---|
None |
可能であれば常にポリシーのトリガーが許可されます。これはデフォルトです。 |
AutomaticReset |
可能であれば常にポリシーのトリガーが許可されますが、アラーム・リセット期間で指定された間隔が経過するまで後続のトリガーは発生しません。 |
ManualReset |
1回のみポリシーのトリガーが許可されます。トリガー後に再度起動するには、手動でそれをリセットする必要があります。ランタイムMBean操作を使用して、プログラム的に、またはWLSTによってアラームをリセットできます。たとえば、 |
次のアラーム状態の動作に注意してください。
アラーム・タイプがAutomaticResetの場合、ポリシーは、トリガーされるとアラーム状態に移行し、アラーム・リセット期間で指定された時間間隔が経過するまで、その状態に留まります。
ポリシーがManualResetアラームを使用して構成されている場合、ポリシーは、トリガーされるとアラーム状態に移行し、それが手動でリセットされるまでその状態に留まります。
ポリシーは、アラーム状態にある場合、アラームがリセットされるまで再評価されません。
ポリシーのアラーム・タイプがNoneの場合、構成されたアクションは、ポリシーがトリガーされるたびに実行されます。この場合、アラーム状態が設定されることはありません。
ポリシーがトリガーされると、常にロギング・システムにメッセージが自動的に生成されます。重大度オプションは、次の場合に構成できるオプション値です。
ロギング・システムで生成されるログ・メッセージの重大度の値として割り当てる場合。
ポリシーで構成されているアクションにも渡す場合。
重大度オプションは、weblogic.logging.SeveritiesクラスのWebLogicロギング・サービスに定義されているものである必要があります。許容される値は、Info、Notice、Warning、Error、Critical、AlertおよびEmergencyです。デフォルトは、Noticeです。
ポリシーのEnabled属性を使用することで、個々のポリシーを個別に有効化および無効化できます。この属性に指定する値は、trueまたはfalseです。無効化すると、ポリシーは評価されず、その構成済アクションも実行されません。
ただし、診断システム・モジュールのすべてのポリシーおよびアクション構成の親であるWLDFWatchNotificationBeanにも、Enabled属性があることに注意してください。WLDFWatchNotificationBean.Enabled属性の値がfalseの場合、個々のポリシーが有効として構成されているかどうかにかかわらず、診断システム・モジュールのすべての個別ポリシーが無効化されます。
スケジュール済ポリシーは、WebLogic ServerランタイムMBeanサーバー内のMBean (WebLogic ServerランタイムMBeanサーバーの読取り専用構成MBeanを含む)から受信したデータで構成される診断データをモニターします。メトリックと呼ばれるこれらの値は、次のような共通のWebLogic Server JMXデータ・ソースから取得されます。
WebLogic ServerランタイムMBeanサーバー
ドメイン・ランタイムMBeanサーバー
JVMプラットフォームMBeanサーバー
スケジュール済ポリシーは、WebLogic Server環境で実行時状態の情報をモニターするために役立ちます。スケジュール済ポリシーを使用したモニターで役立つ診断データの例は、次のとおりです。
平均JVMヒープ使用量の時間経過に伴う変化
空きヒープの平均容量が、ポリシー式で定義されている特定のしきい値に到達すると、構成済のアクションが実行されます(システム管理者への電子メールの送信など)。
組み合せて考慮される複数のサービスからのデータ(ロード・バランサによりレポートされるレスポンス時間メトリックとメッセージ・キューからのメッセージ・バックログ・メトリックなど)
データの組合せが、ポリシー式で定義されている特定の基準セットに一致する場合、ポリシーによってスケーリング・アクションを起動できます
次の項では、3つのスケジュール済ポリシー・タイプの構成方法について説明し、それらの例を示します。
Beanと同じWLDFモジュール内で定義されている他のポリシーの状態を参照できるポリシー式を作成する方法の詳細は、「ポリシーのチェーン」も参照してください。ポリシーのチェーンによって、あるポリシーの状態を、別のポリシーの式の一部にすることができます。
スケジュール済ポリシーの最も簡単なタイプは、カレンダ・ベース・ポリシーです。カレンダ・ベース・ポリシーを使用して、ポリシーのスケジュールに従って、関連する任意のアクションを起動できます。
カレンダ・ベース・ポリシーは、式が関連付けられていない単純なスケジュール済ポリシーです。これにより、純粋にスケジュール駆動型のアクションの実行が可能になります(指定したスケジュールでアクションのセットを無条件に実行できます)。式が指定されていない場合、スケジュールされた時間になると、ポリシーは、空の式をtrueの結果として扱い、関連するアクションを実行します。
注意:
カレンダ・ベース・ポリシーは、次の構成属性を持つポリシーでのみサポートされます。
'Harvester'として指定されたルール・タイプ
'EL'として指定された式言語
次の例は、WLSTを使用したカレンダ・ベース・ポリシーの構成を示しています。このポリシーによって、12月26日の午前3:00にスケール・アップ・アクションが起動されます。
calendarScaleUp=wn.lookupWatch('ChristmasReturnsScaleUpWatch')
if calendarScaleUp == None:
print "Creating scale-up for the post-Christmas returns rush on Dec 26 at 3am"
calendarScaleUp=wn.createWatch('ChristmasReturnsScaleUpWatch')
calendarScaleUp.setRuleType('Harvester')
calendarScaleUp.setExpressionLanguage('EL')
calendarScaleUp.getSchedule().setHour('3')
calendarScaleUp.getSchedule().setMinute('0')
calendarScaleUp.getSchedule().setSecond('0')
calendarScaleUp.getSchedule().setDayOfMonth('26')
calendarScaleUp.getSchedule().setMonth('Dec')
calendarScaleUp.setEnabled(false)
calendarScaleUp.addNotification(scaleUp)
スマート・ルールは、ポリシー式の作成を大幅に簡略化する事前パッケージ済の関数です。特に、WebLogic Server管理コンソールおよびFusion Middleware Controlには、作成するポリシーのスマート・ルールを構成するタスクを大幅に簡略化するスマート・ルール・エディタが含まれます。
スマート・ルールでは、多数の複雑な操作を実行できますが、表面化されるのは設定する構成パラメータのうちごく少数です。収集される特定の低レベル・メトリックの詳細やその使用方法などは、隠蔽されるため、容易に使用できます。スマート・ルールは、ポリシーがtrueに評価されるかどうかを決定するブール値のみを返します。
スマート・ルールをポリシー式で術語として使用するには、単純にそのスマート・ルールで必要なパラメータを指定します。たとえば、ローカル・サーバーの平均スレッド・プール・キュー長に特定の増加が認められるかどうかを評価するには、ポリシー式としてServerHighQueueLengthスマート・ルールを指定するポリシーを作成し、次のパラメータを指定します。
ThreadPoolRuntimeMBean.QueueLength属性の値を収集するためのサンプリング期間
サンプルを保持する期間(最新の時間ウィンドウ)
キュー内のスレッドの最大許容可能数を決定するしきい値
スマート・ルールは、指定した時間間隔での適切なメトリックのサンプリング、平均の計算、しきい値の比較、およびスマート・ルールをtrueに評価するかどうかの決定について、処理を行います。
注意:
スマート・ルールがサポートされるのは、式言語としてJava ELで構成されているスケジュール済ポリシーで使用する場合のみです。
スマート・ルールでは、次のような項目について、時間経過に伴ってサーバーまたはクラスタのメトリックの傾向をモニターできます。
平均システム・スループット
プロセスCPU負荷
保留中のユーザー・リクエストの数
アイドルまたはスタック・スレッド数
受信リクエスト・キュー・サイズ
平均システム負荷
JVM空きヒープ・サイズ
JMXで認識可能な任意のメトリック値(カスタムMBean値など)
スマート・ルールは、ポリシー式の構成要素として使用できます。最も単純な使用例では、単一のスマート・ルールをポリシー式で単独で使用できます。また、スマート・ルールを他のEL構成要素などと組み合せてより複雑な式を作成することもできます。
たとえば、サーバー・インスタンスまたはクラスタで次の状況がすべて同時に発生した場合に電子メール通知を送信するポリシーを構成できます。
JVM空きヒープ率の低下
スタック・スレッド数の増加
受信リクエスト・キュー・サイズの増加
WLDFで提供されるすべてのスマート・ルールの詳細は、「スマート・ルールのリファレンス」を参照してください。
ClusterLowHeapFreePercentスマート・ルールは、JVMRuntimeMBean.HeapFreePercent属性の値をモニターして、クラスタ内のすべての管理対象サーバーで平均空きヒープを比較します。クラスタ内の管理対象サーバーの最小割合が、特定のしきい値を下回る平均空きヒープを持つようになると、このスマート・ルールを使用するポリシー式は、trueに評価されます。
ClusterLowHeapFreePercentスマート・ルールには、次の入力パラメータがあります。
クラスタ名
サンプリング期間 - HeapFreePercentメトリックの値を収集する頻度
保存ウィンドウ - サンプルを保持するスライディング時間ウィンドウ。たとえば、最新の5分間です。
percentFreeLimit - 低い空きヒープ率のしきい値を表す値。
percentServersLimit - 式がtrueに評価されるために、percentFreeLimitを下回る平均空きヒープを持つ必要があるクラスタ内の管理対象サーバーの割合。
次に、ClusterLowHeapFreePercentスマート・ルールの構成例を示します。
wls:ClusterLowHeapFreePercent("myCluster","30 seconds","10 minutes",20,60)
このスマート・ルールは、myCluster内のすべての管理対象サーバーから30秒ごとにHeapFreePercentの値を収集し、そのデータを最新の10分間保持し、myCluster内の管理対象サーバーの60%以上が、20%を下回る平均空きヒープ率を持つ場合、trueに評価されます。
このスマート・ルールは、trueに評価されたときにアクションを起動するように構成できます(システム管理者に、クラスタ内の空きヒープが低下していることをレポートする電子メールを送信するなど)。その後、システム管理者は、必要に応じて修正アクションを実行できます。
「エラスティック・アクションの構成」の説明に従って、スマート・ルールをスケーリング・アクションと組み合せて使用し、動的クラスタのポリシー・ベース・スケーリングを構成できます。この機能によって、そのクラスタの自動拡張度が有効になります。ダウンロードして実行できるデモなどの詳細は、『Oracle WebLogic Server動的クラスタの拡張度の構成』の「ポリシーベースのスケーリング」を参照してください。
収集対象メトリック・ベース・ポリシーは、スケジュール済ポリシーの一種で、そのポリシー式内でWLDF付属のBeanおよび関数を使用できます。これらのBeanは、次のような共通のWebLogic Server JMXデータ・ソースへのアクセスを取得できるJavaBeanオブジェクトです。
WebLogic ServerランタイムMBeanサーバー
ドメイン・ランタイムMBeanサーバー
JVMプラットフォームMBeanサーバー
次の項では、Beanおよび関数を使用して収集対象メトリック・ベース・ポリシーを構成する方法について説明します。
表10-2では、WebLogic Serverで提供されるBeanを要約します。これらの各Beanの完全なリファレンス情報は、「WLDF Beanのリファレンス」を参照してください。
表10-2 WebLogic Serverで提供されるBean
| 名前 | 接頭辞 | スコープ | サマリー |
|---|---|---|---|
runtime |
wls |
パーティション・スコープの診断システム・モジュールのデプロイメントおよびパーティションからのみ使用可能 |
ローカルのWebLogic ServerランタイムMBeanサーバーのMBeanへのアクセスを提供します。これらのMBeanには、読取り専用構成MBeanとRuntimeMBeanインスタンスの両方が含まれます。 |
domainRuntime |
wls |
管理サーバー |
ドメイン・ランタイムMBeanサーバーのMBeanへのアクセスを提供します(管理サーバー専用)。 |
clusterRuntime |
wls |
管理サーバー |
クラスタ・メンバー・データへのドメイン全体アクセスを提供します(管理サーバー専用)。 |
instrumentationEvent |
wls |
管理サーバー、管理対象サーバーおよびパーティション |
インストゥルメンテーション・ポリシー式のインストゥルメンテーション・フィールドへのアクセスを提供します。 |
log |
wls |
管理サーバー、管理対象サーバーおよびパーティション |
ログ・ポリシー式のログ・イベント・フィールドへのアクセスを提供します。 |
platform |
wls |
管理サーバーまたは管理対象サーバー |
JVMのプラットフォームMBeanサーバーへのアクセスを提供します。 ほとんどの場合、 |
partition |
wls |
パーティション・スコープのWLDF診断システム・モジュールのデプロイメント。 |
パーティション・スコープ・メトリックへのアクセスを提供します。 このBeanを使用できるのは、このBeanがスコープ指定されている同じパーティションにデプロイされた診断システム・モジュールで構成されたポリシーのみです。 |
resource |
N/A |
管理サーバー、管理対象サーバーおよびパーティション |
診断システム・モジュールのデプロイメント内のBeanおよび状態情報へのアクセスを提供します。 アクセスは、同じ診断システム・モジュール内で構成されたポリシーに制限されます。 |
デフォルトでJava ELに付属するバンドル済の関数および演算子に加え、メトリック・データの一般的な操作のため、および履歴とともにメトリックのセットを保持するために、ポリシー式内でWLDF付属の関数を使用することもできます。WLDFに含まれているすべての関数のリファレンス情報は、「関数のリファレンス」を参照してください。
同じ診断システム・モジュール内で、あるポリシーの式は、その式内のBeanとして他のポリシーを参照できます。この方法で、複雑なポリシー式を再利用し、組み合せてチェーンにすることで、あるポリシーの状態を、別のポリシーの式の一部にすることができます。これによって、より複雑で相互に関連付けられたポリシーを記述する一方で、そのようなポリシー構成の可読性と管理性を向上できます。
式内のポリシー状態にアクセスできるようにするには、各ポリシーのグローバルBeanネームスペース内のresource Beanを使用します。resource Beanでは、watchesという名前のMap属性がサポートされます(この場合、マップ内の各キーは、同じ診断システム・モジュール内で定義されているポリシーの名前です)。
ポリシーのマップの各値は、指定されたポリシーを表すBeanです。これらのポリシーBeanでは、次のセマンティクスを持つ単純なブール型アラーム属性がサポートされます。
ポリシーがNone以外のアラーム・タイプで構成されている場合、ポリシーが現在アラーム状態にある場合、アラーム属性によってtrueが返されます。
ポリシーでアラーム・タイプが構成されていない場合、アラーム属性によって、最新の評価の結果が生成されます。
指定されたポリシーが評価サイクルを正常に完了する前に、ポリシーBeanのアラーム属性にアクセスすると、NotEnoughDataExceptionがスローされます。この状態には、その評価サイクル中は式が無効化されるという効果もあり、ポリシーは無効化されませんが、発生しても事実上結果は生成されません。
ログ・ポリシーを使用して、サーバー・ログまたはドメイン・ログ内の特定のメッセージまたは文字列の出現をモニターします。このタイプのポリシーは、指定されたデータを含むログ・メッセージが発行されるとトリガーされます。
ログ・ポリシーの作成時には、EL式でlog Beanを使用してログ・メッセージ・フィールドにアクセスできます。log Bean属性の詳細は、logを参照してください。
注意:
RUNNING状態メッセージIDを検索するログ・ポリシーでは、メッセージID BEA-000360ではなくBEA-000365を検索する必要があります。メッセージID BEA-000360は状態がRUNNINGに変わるすぐ前に発行され、BEA-000365はそのすぐ後に発行されます。そのため、そのようなログ・ポリシーでは、メッセージID BEA-000365のみを見つけることができます。
例10-1に、サーバー・ログ・ポリシーの構成例を示します。
例10-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>
<watch-notification>
<enabled>true</enabled>
<log-watch-severity>Info</log-watch-severity>
<watch>
<name>myLogWatch</name>
<enabled>true</enabled>
<rule-type>Log</rule-type>
<rule-expression>log.messageId == 'BEA-000360'</rule-expression>
<expression-language>EL</expression-language>
<alarm-type>ManualReset</alarm-type>
</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>
例10-1では、<rule-type>がLogであるため、サーバー・ログに書き込まれたメッセージまたは文字列が監視されます。<rule-type>がDomainLogであるため、ドメイン・ログ内のメッセージまたは文字列がモニターされます。
インストゥルメンテーション・ポリシーは、WLDFのインストゥルメンテーション・コンポーネントに由来するイベントをモニターするために使用します。このタイプのポリシーは、イベントがポストされるとトリガーされます。
例10-2に、インストゥルメンテーション・ポリシーの構成例を示します。
例10-2 インストゥルメンテーション・ポリシーの構成のサンプル(DIAG_MODULE.xml内)
<watch-notification>
<watch>
<name>myInstWatch</name>
<enabled>true</enabled>
<rule-type>EventData</rule-type>
<rule-expression>instrumentationEvent.payload > 100000000 && instrumentationEvent.monitor == 'Servlet_Around_Service'</rule-expression>
<expression-language>EL</expression-language>
<alarm-type>ManualReset</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>
