| Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.3.0) E90355-03 |
|
 前 |
 次 |
スケジュール済ポリシーでは、特定のスケジュールに応じてランタイムMBeanによって生成される診断データをモニターします。これらのポリシーを使用して、特定の時間またはスケジュールでアクションを実行することもできます。
ログ・ポリシーでは、サーバー・ログまたはドメイン・ログに生成されるメッセージをモニターします。
インストゥルメンテーション・ポリシー(イベント・データ・ポリシーとも呼ばれる)では、WLDFインストゥルメンテーション・コンポーネントによって生成されるイベントをモニターします。
この章では、各ポリシー・タイプの構成方法について説明します。この章の内容は次のとおりです。
WebLogic Server管理コンソールを使用してポリシーを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュール用のポリシーの作成に関する項を参照してください。
ポリシーには構成可能ないくつかのコンポーネントがあります。たとえば、タイプ、式、ポリシーがtrueだと判断されたときに実行される対応するアクションなどです。
次のツールのいずれかを使用して、診断システム・モジュール用のポリシーを構成できます。
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チュートリアル(https://docs.oracle.com/javaee/7/tutorial/jsf-el.htm#GJDDD)を参照してください。Java (EL)の詳細は、JSR-000341 Expression Language 3.0仕様(https://jcp.org/aboutJava/communityprocess/final/jsr341/index.html)を参照してください。
以前のリリースのWebLogic Serverで作成された診断システム・モジュールがある場合、WLDFでは、WLDF問合せ言語を使用する式がサポートされます。既存の、または新しい診断システム・モジュール用に新しいポリシーを作成する場合、ポリシー式言語としてJava ELを使用することを強くお薦めします。
ノート:
この章で説明されているポリシーは、Java ELベースです。WLDF問合せ言語を使用するポリシーの構成の詳細は、「WLDF問合せ言語ベースのポリシー」を参照してください。
ポリシー式は、trueに評価されたときに関連するアクションを実行するルールを指定するために必要なすべての情報をカプセル化します。式言語としてJava ELを使用すると、次の即時利用可能なリソースを使用するポリシー式を構成して、関連するアクションを起動するかどうかを決定する条件を設定できます。
Bean
Beanは、MBeanのメトリック、ログ・イベント情報、または他のBeanによって表面化される構造化データなど、使用するポリシー式に利用できるデータを表現するJavaオブジェクトです。標準JavaBean規則を使用してポリシー式で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サーバー
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動的クラスタの拡張度の構成』の「ポリシーベースのスケーリング」を参照してください。
同じ診断システム・モジュール内で、あるポリシーの式は、その式内のBeanとして他のポリシーを参照できます。この方法で、複雑なポリシー式を再利用し、組み合せてチェーンにすることで、あるポリシーの状態を、別のポリシーの式の一部にすることができます。これによって、より複雑で相互に関連付けられたポリシーを記述する一方で、そのようなポリシー構成の可読性と管理性を向上できます。
式内のポリシー状態にアクセスできるようにするには、各ポリシーのグローバルBeanネームスペース内のresource Beanを使用します。resource Beanでは、watchesという名前のMap属性がサポートされます(この場合、マップ内の各キーは、同じ診断システム・モジュール内で定義されているポリシーの名前です)。
ポリシーのマップの各値は、指定されたポリシーを表すBeanです。これらのポリシーBeanでは、次のセマンティクスを持つ単純なブール型アラーム属性がサポートされます。
ポリシーがNone以外のアラーム・タイプで構成されている場合、ポリシーが現在アラーム状態にある場合、アラーム属性によってtrueが返されます。
ポリシーでアラーム・タイプが構成されていない場合、アラーム属性によって、最新の評価の結果が生成されます。
指定されたポリシーが評価サイクルを正常に完了する前に、ポリシーBeanのアラーム属性にアクセスすると、NotEnoughDataExceptionがスローされます。この状態には、その評価サイクル中は式が無効化されるという効果もあり、ポリシーは無効化されませんが、発生しても事実上結果は生成されません。
ログ・ポリシーを使用して、サーバー・ログまたはドメイン・ログ内の特定のメッセージまたは文字列の出現をモニターします。このタイプのポリシーは、指定されたデータを含むログ・メッセージが発行されるとトリガーされます。
ログ・ポリシーの作成時には、ポリシー式でlog Beanを使用して、ログ・メッセージ・フィールドのデータにアクセスできます。使用可能なlog Bean属性の詳細は、logを参照してください。
次の例では、サーバーがRUNNING状態に入ったことを示すログ・メッセージを検索します。
w=cmo.createWatch("ServerLogRunningState")
w.setExpressionLanguage('EL')
w.setRuleType('Log')
w.setRuleExpression("log.messageId == 'BEA-000365' and log.logMessage.contains('RUNNING')")
log BeanはシンプルなJavaBeanオブジェクトであるため、Javaメソッドとフィールド・アクセサを使用してログのデータにアクセスすることもできます。次に、前述の例に相当するポリシー式を示します。
w=cmo.createWatch("ServerLogRunningState2")
w.setExpressionLanguage('EL')
w.setRuleType('Log')
w.setRuleExpression("log.getMessageId().contains('000365') && log.getLogMessage().contains('RUNNING')")
ノート:
RUNNING状態メッセージIDを検索するログ・ポリシーでは、メッセージID BEA-000360ではなくBEA-000365を検索する必要があります。メッセージID BEA-000360は状態がRUNNINGに変わるすぐ前に発行され、BEA-000365はそのすぐ後に発行されます。WLDFは、サーバーがRUNNING状態になるまでルールの評価を開始しません。そのため、そのようなログ・ポリシーでは、メッセージID BEA-000365のみを見つけることができます。
インストゥルメンテーション・ポリシーは、WLDFのインストゥルメンテーション・コンポーネントに由来するイベントをモニターするために使用します。このタイプのポリシーはインストゥルメンテーション・コンポーネントによって送信されているイベントの結果として評価され、デプロイされたインストゥルメンテーション・モニターと一致するコードが実行されるときに評価が実行されます。
インストゥルメンテーション・ポリシー式ではinstrumentationEventという名前の単一のBeanが使用されます。このBeanは、インストゥルメンテーション・イベントでキャプチャされたデータへのアクセスを提供します。ログ、DomainLogおよび収集対象メトリック・ポリシーと同様に、ポリシー式でJavaBean規則を使用してインストゥルメンテーション・イベントのデータにアクセスできます。instrumentationEvent Beanで、アクセス可能なフィールドのセットを参照してください。
次の例は、instrumentationEvent Beanを使用してインストゥルメンテーション・ポリシーのデータにアクセスする方法を示しています。
instrumentationEvent.payload > 100000000 && instrumentationEvent.monitor == 'Servlet_Around_Service'
このポリシーがトリガーされるのは、モニター・イベントがServlet_Around_Serviceタイプで、ペイロード値(この場合は、Servlet_Around_Serviceモニターによって記録されるサーブレットの実行時間)が100000000ナノ秒(100ミリ秒)より大きい場合です。また、instrumentationEvent BeanはシンプルなJavaBeanオブジェクトであるため、Javaメソッドとフィールド・アクセサを使用してinstrumentationEventのデータにアクセスすることもできます。次に、前述の例に相当するポリシー式を示します。
instrumentationEvent.getPayload() > 100000000 && instrumentationEvent.getMonitor().equals(‘Servlet_Around_Service')
例10-1に、インストゥルメンテーション・ポリシーの構成例を示します。
例10-1 インストゥルメンテーション・ポリシーの構成のサンプル(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>
WLDFとともにパッケージされたスマート・ルールのライブラリは、サーバーまたはクラスタのランタイム・パフォーマンス・データを評価するためのスケジュール済ポリシー作成のニーズを十分に満たすでしょう。ただし、スマート・ルールでは対応できないような特殊なスケジュール済ポリシーが必要な場合、WLDFにはJava ELの拡張機能も用意されています。これらの拡張機能は、WebLogicドメインのランタイムMBeanサーバーから収集されたメトリックについて、非常に特殊な特徴または傾向を評価するポリシーで使用します。
この項の内容は、複雑なプログラミング技術の知識を持つ開発者が対象です。できればJava ELの使用経験も必要です。
WLDF Beanと関数の使用
WLDFではポリシー式を記述する言語としてJava ELが使用されます。Java ELは標準の拡張可能で堅牢なスクリプト言語です。WLDFではJava ELを採用して拡張したため、ポリシー式を記述するためにWebLogic診断データとイベントにアクセスできます。WLDFには、次の診断データとイベントを使用するポリシー式を記述するために、関数とJavaBeanオブジェクトのセットが用意されています。
WebLogicランタイムMBeanデータ
WebLogicロギング・イベント
WebLogicインストゥルメンテーション・イベント
Java EL内で使用可能なすべての機能を、ポリシー式を記述するためのWLDF拡張機能とともに使用できます。収集対象メトリック・ベース・ポリシーは、スケジュール済ポリシーの一種で、そのポリシー式内で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 |
管理サーバー |
クラスタ・メンバー・データへのドメイン全体アクセスを提供します(管理サーバー専用)。 |
platform |
wls |
管理サーバーまたは管理対象サーバー |
JVMのプラットフォームMBeanサーバーへのアクセスを提供します。 ほとんどの場合、 |
partition |
wls |
パーティション・スコープのWLDF診断システム・モジュールのデプロイメント。 |
パーティション・スコープ・メトリックへのアクセスを提供します。 このBeanを使用できるのは、このBeanがスコープ指定されている同じパーティションにデプロイされた診断システム・モジュールで構成されたポリシーのみです。 |
resource |
N/A |
管理サーバー、管理対象サーバーおよびパーティション |
診断システム・モジュールのデプロイメント内のBeanおよび状態情報へのアクセスを提供します。 アクセスは、同じ診断システム・モジュール内で構成されたポリシーに制限されます。 |
表10-2に示すBeanは、WebLogic ServerのランタイムMBeanメトリックへのアクセスを提供します。Java ELを使用したポリシー式では、WLDFが提供するBeanを使用して各ランタイムMBeanのメトリック・データにアクセスします。次に構文を示します。
wls.bean-name.attribute-or-operation.attribute-or-operation…
WLDF Beanを使用するすべてのELベースのポリシー式は、ネームスペース接頭辞wlsで開始する必要があります。接頭辞wlsは、ポリシー式で使用できるすべてのWLDF Beanを含むネームスペースと似ています。Beanおよびその属性とメソッドには、標準JavaBean規則を使用してアクセスできます。次の例に示す簡単なポリシー式は、JVMRuntimeMBeanのHeapFreePercent属性の値が20未満のときにtrueを返します。
wls.runtime.serverRuntime.JVMRuntime.heapFreePercent < 20
前述のポリシー式の例では、次の順序でHeapFreePercentの値にアクセスします。
runtime Beanに、wls Beanネームスペースからアクセスします。
runtime Beanは、ローカル・ランタイムMBeanによって収集されたメトリックへのエントリ・ポイント、さらにWebLogic ServerランタイムMBeanサーバーの読取り専用構成のMBeanデータへのエントリ・ポイントを提供します。
serverRuntime属性に、runtime Beanからアクセスします。
runtime BeanのserverRuntime属性は、式が評価されている任意のローカルで実行中のサーバー・インスタンスのServerRuntimeMBeanインスタンスに直接対応します。
JVMRuntime属性(ローカルServerRuntimeMBean配下のJVMRuntimeMBeanインスタンスに対応)に、serverRuntime Beanからアクセスします。
heapFreePercent属性に、返されたJVMRuntimeインスタンスからアクセスします。
runtime Beanから、serverRuntime属性を介してランタイム・メトリックとモニタリング・データを入手できます。domain属性はローカル読取り専用DomainMBeanツリーの現在の構成データへのアクセスを提供します。このアクセスにより、ポリシーを使用してポリシー式内で現在のインメモリー構成を調査できます。
WLDFが提供する式BeanからBean属性としてアクセスされるMBeanは、ほとんどの属性、および式で使用可能な一部の操作(Oracle WebLogic Server MBeanリファレンスを参照)への読取り専用アクセスを持ちます。ただし、セキュリティ上の一部の例外があります。
ノート:
属性にアクセスする場合、JMX規則とJavaBean規則では構文にわずかな違いがあります。たとえば、JMX属性のHeapFreePercentにアクセスするためのJavaBean規則では、キャメルケース構文を使用する必要があります。JMXを使用する場合は、HeapFreePercentという名前によって属性にアクセスします。ただし、EL式の場合は同じ属性にheapFreePercentとしてアクセスします。たとえば、ServerRuntimeMBeanのHealthState属性など、一部のMBean属性は複雑なオブジェクトを返します。このような属性にJavaBean規則を使用してアクセスできます。次の例では、サーバーのヘルス状態がゼロ以外の値のときにポリシー式がtrueを返します。
wls.runtime.serverRuntime.healthState.state != 0
配列属性の操作
多くのWLDF Bean属性は子MBeanの配列を返します。配列などのコレクションを操作するためにJava ELに用意されているstream演算子を使用して、配列とリストをストリーム・オブジェクトに変換し、他のJava ELおよびWLDFの関数と演算子に使用できます。次の例では、ポリシー式を使用してローカル・サーバー・インスタンスのすべてのJDBCDataSourceRuntimeMBeanインスタンスを調査し、いずれかがOverloaded状態のときにtrueを返します。
wls.runtime.serverRuntime.JDBCServiceRuntime.JDBCDataSourceRuntimeMBeans.stream().anyMatch(ds -> ds.state == “Overloaded”)
ポリシー式は次の順序で実行されます。
JDBCServiceRuntimeMBeanの子に、ServerRuntimeMBeanからアクセスします。
配列属性JDBCDataSourceRuntimeMBeansに、JDBCServiceRuntimeMBeanからアクセスします。
Java ELのstream演算子を使用して配列をストリームに変換し、WLDFおよび標準Java ELのコレクション操作で使用できるようにします。
anyMatchコレクション操作を使用して、返されたJDBCDataSourceRuntimeMBeanインスタンスのいずれかにOverloaded状態があるか検索します。
anyMatch操作でOverloaded状態と一致すると、trueが返されます。
表10-2で定義されているMBeanは収集対象メトリック・ポリシー式で使用されます。これらすべてのBeanがqueryメソッドをサポートするため、同種のMBeanのセットに対して、MBean属性値のセットの問合せを実行できます。
メソッドでは次の構文が使用されます。
query(target-list, object-name-pattern, attribute-expression)
queryメソッドは、一致する各MBeanインスタンスに対してattribute-expressionを使用して取得した値の反復可能なリストを返します。
表10-3 メソッド・パラメータ
| パラメータ | 説明 |
|---|---|
|
この引数は、管理サーバーで実行されるポリシーにのみ使用可能な これはドメイン内のサーバーまたはクラスタのリストです。この引数により、ポリシー式が、同じ式内でドメイン全体のMBean値を調べることができます。 |
|
この引数は任意の有効なJMX ObjectNameパターンを使用します。パターンは一重引用符(')文字で囲まれた文字列値として指定します。たとえば:
|
|
この引数は引用符の付いたEL副次式で、object-name-pattern引数に一致する各MBeanから属性にアクセスするために使用されます。attribute-expression引数は次のいずれかのタイプになります。
ノート: |
queryメソッドが返す値を、これらの値を調べる大きなポリシー式の一部として使用できます。
ノート:
queryメソッドは、本来はMBeanインスタンスの同種のセットに対して使用されますが、指定されたMBeanがすべての同じタイプになるように強制する方法はありません。したがって、異なるタイプのMBeanを含むobject-name-patternを指定した場合、ポリシー式の評価の際にエラーが発生することがあります。例10-2 queryメソッドの使用例
表10-4に、ポリシー式でqueryメソッドを使用する例を示します。
ノート:
この例はqueryメソッドの使用方法を示すもので、完全なポリシー式は取り上げません。表10-4 queryメソッドの例
| 例 | 説明 |
|---|---|
|
|
|
|
ポリシー式のqueryメソッドの使用および結果セットを次の図で示します。
次にポリシー式の完全な例を示します。queryメソッドを使用して、ローカルWebLogic Serverインスタンスの任意のWorkManagerRuntimeMBeanのStuckThreadCount属性がゼロより大きいかどうかを判定します。
wls.runtime.query('com.bea:Type=WorkManagerRuntime,*', 'StuckThreadCount').stream().anyMatch( x -> x > 0 )
WorkManagerRuntimeMBeanのすべてのインスタンスのStuckThreadCount値が必要です。各値を調べてゼロより大きいか確認しますが、大きい場合はサーバーのスタック・スレッドを意味します。streamコレクション操作はJava EL標準の一部で、反復可能セットをストリームに変換して、例に示したanyMatchなどでJava ELコレクション操作とともに使用できるようにします。
デフォルトでJava ELに付属するバンドル済の関数およびコレクション操作に加え、メトリック・データの一般的な操作のため、および履歴とともにメトリックのセットを保持するために、ポリシー式内でWLDF付属の関数を使用することもできます。
WLDF付属の関数には次のものがあります。
wls:tableChanges
wls:tableAverages
wls:extract
wls:average
wls:changes
wls:aliveServersCount
WLDF付属の各EL関数の詳細は、「関数のリファレンス」を参照してください。
接頭辞wlsを使用して関数を呼び出します。
wls:<function-call>
たとえば、wls:aliveServersCount('cluster1')は、cluster1クラスタに対して、WLDFによって提供されるaliveServersCount()関数を呼び出します。
コレクション操作
WLDFにはコレクション操作のセットも用意されています。これはJava ELに用意されたコレクション操作と同じように呼び出すことができます。WLDFに用意されたコレクション操作には次のものがあります。
tableAverages
percenMatch
即時の値を評価するかわりに、時間経過に伴うメトリック・データの傾向を調査できます。wls:extract関数を使用して、指定されたサンプリング・レート・スケジュールおよび時間ウィンドウに基づいて、指定された入力ソースのセットから時系列の表を抽出します。
extract関数の構文は次のとおりです。
wls:extract(sources, sampling rate, retention window)
このメソッドは、結果の2次元セットからなる反復可能セットを返します。関数へのメトリック入力は、retention windowパラメータで定義される特定の期間中に複数のMBeanインスタンスから発生します。結果のデータは表に似ており、各行に時間ウィンドウ内の特定のMBeanインスタンスからの値のセットが格納されます。
パラメータ
表10-5 extract()関数のパラメータの説明
| パラメータ | 説明 |
|---|---|
|
メトリック・ソースのセット。 |
|
データを収集する頻度を特定する文字列。この文字列は、時、分または秒として指定できます。構文は柔軟で、30秒の場合は、たとえば30s、30secまたは30 secondsとして指定できます。 ノート: 頻度はメトリックの収集レートのみに適用され、全体的なポリシー評価スケジュールとは関係ありません。 |
|
保存ウィンドウを特定する文字列。このウィンドウに対して、 スライディング・ウィンドウ・アルゴリズムを実装されるため、配列が満杯になると、セット内の最も古いデータが無効になります。 retention windowを参照してください。 |
例10-3 extract関数の使用例
表10-6はextract関数の使用例を示しています。
ノート:
この例は
extract関数の呼出し法を示すもので、完全なポリシー式は取り上げません。表10-6 extract関数の例
| 例 | 説明 |
|---|---|
|
|
|
|
|
|
extract関数はスカラー値の表を返します。任意のコレクション操作を使用して結果セットを調査または操作できます。WLDFには、tableAveragesやpercentMatchなど、extract関数から返されるデータに対して使用するもの以外のコレクション操作も用意されています。全体的なポリシー式の一部として、extractの結果を他の関数または操作に入力できます。
次に示すポリシー式の例では、extract関数を使用してcluster1全体のサーバーのPendingUserRequestCount属性値を収集します。結果をtableAveragesおよびpercentMatchコレクション操作と組み合せて、ブール値を生成します。
wls:extract(wls.domainRuntime.query({'cluster1'}, 'com.bea:Type=ThreadPoolRuntime,*', 'PendingUserRequestCount'), '30s', '2m').tableAverages().stream().percentMatch(pendingCount -> pendingCount > 100) > 0.75
このポリシー式がtrueを返すのは、PendingUserRequestCount属性の2分間の平均値が、cluster1のサーバーの75%で100を超えた場合です。ポリシー式は次の順序で実行されます。
extract関数によってPendingUserRequestCount属性の値の表が作成され、各行には、2分間にわたるcluster1のサーバーからの1セットの値が含まれます。
tableAverages操作は、extract関数によって返される表の各行の2分間にわたる平均を計算します。
streamは標準Java ELコレクション操作で、tableAveragesのベクトルの結果をJava ELストリームに変換します。
percentMatch操作はtableAveragesで計算されたすべての平均値を調べ、そのセット内で100を超える値の割合を計算します。
percentMatchの結果は0から1の範囲の値で、適切なしきい値である0.75と比較されます。
extract関数は、定義された期間にわたって指定された入力ソースからデータを抽出します。WLDFポリシー・エンジンにより、式の中に最初にextract関数が検出されると、ポリシー式で示された適切なメトリックの収集が開始されます。ポリシー・エンジンによるサンプル収集は、extract関数を使用するポリシーが無効にされるかアンデプロイされるまで続行します。
extract関数を使用するポリシー式が評価されるのは、呼出しで指定されたスライディング・ウィンドウ間隔を満たすために適切なメトリックの十分なデータが収集されたときです。関数呼出しで5分間のデータが必要だと指定された場合、ポリシーがデプロイされた瞬間から5分間のデータ収集が実行されなければ、式を正しく評価できません。
次に示す例では、式が評価されるのは、PendingUserRequestCount属性の2分間のデータが収集されたときです。
wls:extract(wls.runtime.query("com.bea:Type=ThreadPoolRuntime,*", "PendingUserRequestCount"), "30s", "2m")
