WLDF クエリ言語

WLDF には、監視ルール式、データアクセサクエリ式、およびログフィルタ式を作成するためのクエリ言語が含まれています。クエリ言語の構文は、SQL 構文の一部を簡略化したものです。

クエリ式の構成要素

サポートされる演算子

クエリ言語では、表 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` に設定される。この例については、上記のビット `&` 演算子の例を参照。
`=`	比較	数値、文字列	等しい
`!=`	比較	数値	等しくない
`<`	比較	数値	より小さい
`>`	比較	数値	より大きい
`<=`	比較	数値	以下
`>=`	比較	数値	以上
`LIKE`	一致	文字列	文字列が指定したパターン (ワイルドカード使用可) に一致するときに true と評価される。 `LIKE` では、以下の 2 つのワイルドカード文字がサポートされる。パーセント記号 `(%)` は 0 文字以上の文字に一致する。ピリオド (.) は単一の文字に一致する。
`MATCHES`	一致	文字列	対象の文字列がオペランド `String` の正規表現パターンに一致するときに true と評価される。
`IN`	検索	文字列	変数の値があらかじめ定義されたセット内に存在するときに true と評価される。次に例を示す。 `SUBSYSTEM IN ('A','B')`

演算子の優先順位

以下に、演算子間の優先順位のレベルを、高いものから順に示します。同じ行に示す演算子は、すべて同等の優先順位です。

( )
NOT
&、|
=、 !=、 <、 >、 <=、 >=、 LIKE、 MATCHES、IN
AND
OR

String 型のカラムでサポートされる数値の比較演算

String 型カラムのデータが数値である場合、カラムで数値の比較演算を実行できます。たとえば、STATUS が String 型である場合、数値オペランドとの比較演算が行われている間は、カラムの値は数値として扱われます。たとえば、以下の比較を考えます。

上記のような比較では、クエリ評価にあたって、比較前に文字列値の適切な数値への変換が試みられます。文字列値を数値に変換できない場合、クエリは失敗します。

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

文字列リテラルは、一重引用符で囲む必要がある。
文字列リテラル内では、ワイルドカードとしてパーセント文字 (%) を使用できる。
アンダースコア文字 (_) は、任意の 1 文字を表すワイルドカードとして使用できる。
バックスラッシュ文字 (\) は、引用符 (`) やパーセント文字 (%) などの特殊文字をエスケープするために使用できる。
監視ルール式では、比較演算子を使用して、文字列、整数、Long、Double、ブールの各リテラルのしきい値を指定できる。
比較演算子は、文字列の字句を比較する。詳細については、java.lang.String.compareTo(String str) メソッドに関するマニュアルを参照してください。

式内の変数について

変数は、実行時に評価されるクエリ式の動的な部分を表します。以下の節の説明に従って、作成する式の種類に合った適切な変数を使用する必要があります。

監視ルール式の作成

監視は、ログイベント、インスツルメンテーションイベント、および収集された属性に基づいて作成できます。式の作成でサポートされる変数は、監視の種類ごとに異なります。以下の節を参照してください。

WLDF 監視のコンフィグレーションおよび使い方の詳細については、以下を参照してください。

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

ログイベントの監視ルール式は、サーバログからのログメッセージの属性に基づいています。

表 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。	文字列

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

インスツルメンテーションイベントの監視ルール式は、診断モニタアクションによって作成されたデータレコードの属性に基づきます。

表 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。	文字列

次に、インスツルメンテーションイベントデータのルール式の例を示します。

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

ハーベスタの監視ルール式は、収集可能な 1 つまたは複数の MBean 属性に基づきます。式では、MBean 型、インスタンス、および属性を指定できます。

インスタンスベースの式および型ベースの式には、監視対象メトリックのネームスペースである namespace コンポーネントを必要に応じて含めることができます。このネームスペースは、ServerRuntime または DomainRuntime に設定できます。指定しない場合のデフォルト値は ServerRuntime です。

このコンポーネントを含めて DomainRuntime に設定すると、ServerLifeCycleRuntimeMBean など、DomainRuntime 固有の MBean のみをモニタするよう制限されます。リモートの管理対象サーバ MBean も DomainRuntime MBeanServer を介してモニタできますが、パフォーマンスに影響するため推奨されません。ベストプラクティスは、各管理対象サーバで常駐ウォッチャを使用し、その管理対象サーバインスタンスに関連するメトリックをモニタすることです。

ハーベスタの監視ルール式でインスタンス名にワイルドカードを使用したり、複合属性を指定することもできます。「式でのワイルドカードの使用」を参照してください。

ハーベスタの監視ルール式を作成するための構文は次のとおりです。

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 オブジェクトの完全な名前を指定する必要があります。

データアクセサクエリの作成

データアクセサコンポーネントで WLDF クエリ言語を使用すると、サーバログ、HTTP ログ、収集されたメトリックなどのデータをデータストアから取り出すことができます。データアクセサクエリの作成に使用する変数は、データの抽出元となるデータストアのカラム名に基づいています。

一致するデータがあると、一致した行のすべてのカラムが返されます。

データストアの論理名

データストアの論理名は、ユニークなものである必要があります。論理名によって示されるのは、サーバ上で利用可能な特定のデータストアです。論理名は、ログの種類を表すキーワードと、フォワードスラッシュ (/) で区切られた 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` と同じ

この例のアクセサは、文字列「Failed」を含むすべてのメッセージを Deployer サブシステムから取得します。

次の例では、API メソッドの呼び出しを示します。この例には、timeStampFrom (その時間を含む) から timeStampTo (その時間を含まない) の間隔内での、MyPool という JDBC 接続プールの収集された属性のクエリが含まれています。

ログフィルタ式の作成

クエリ言語を使用すると、サーバログに書き込まれたログをフィルタ処理できます。ログフィルタ式の作成に使用する変数は、ログのカラムを表します。

WebLogic Server のロギングサービスの詳細については、『ログファイルのコンフィグレーションとログメッセージのフィルタ処理』の「WebLogic Server ログメッセージのフィルタ処理」を参照してください。

複雑な式の作成

変数、バイナリ比較、その他の複雑なサブ式を含む、サブ式を使用した複雑なクエリ式を作成できます。ネストのレベルに制限はありません。以下のルールが適用されます。

WebLogic 診断フレームワークのコンフィグレーションと使い方