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

WLDF クエリ言語

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

以下の節では、このクエリ言語について説明します。

クエリ式の構成要素

クエリ式には、以下のものを指定できます。

演算子 (「サポートされる演算子」を参照)。
リテラル (「サポートされる数値定数と文字列リテラル」を参照)。
変数。サポートされる変数は、式の種類ごとに異なります (「式内の変数について」を参照)。

クエリ言語では、大文字と小文字は区別されます。

サポートされる演算子

クエリ言語では、表 A-1 に示す演算子がサポートされます。

表 A-1 WLDF クエリ言語の演算子

演算子	演算子の種類	サポートされるオペランドの種類	定義
`AND`	論理二項	ブール	両方の式が true のとき true と評価される。
`OR`	論理二項	ブール	どちらかの式が true のとき true と評価される。
`NOT`	論理単項	ブール	式が true でないとき true と評価される。
`=`	比較	数値、文字列	等しい
`!=`	比較	数値	等しくない
`<`	比較	数値	より小さい
`>`	比較	数値	より大きい
`<=`	比較	数値	以下
`>=`	比較	数値	以上
`LIKE`	一致	文字列	文字列が指定したパターン (ワイルドカード使用可) に一致するときに true と評価される。 `LIKE` では、以下の 2 つのワイルドカードがサポートされる。パーセント記号 `(%)` は 0 文字以上の文字に一致する。ピリオド (.) は単一の文字に一致する。
`MATCHES`	一致	文字列	対象の文字列がオペランド `String` の正規表現パターンに一致するときに true と評価される。
`IN`	検索	文字列	変数の値があらかじめ定義されたセット内に存在するときに true と評価される。次に例を示す。 `SUBSYSTEM IN ('A','B')`

演算子の優先順位

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

( )

NOT

=、!=、<、>、<=、>=、LIKE.MATCHES、IN

AND

OR

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

数値定数のルールは以下のとおりです。

数値リテラルとしては、整数または不動小数点数を使用できる。
数値リテラルは、Java の場合と同じように指定する。数値リテラルの例としては、2、2.0、12.856f、2.1934E-4、123456L、2.0D などを挙げることができます。

文字列リテラルのルールは以下のとおりです。

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

式内の変数について

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

監視ルール式の作成

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

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

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

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

表 A-2 では、ログメッセージ属性の変数名について説明します。

表 A-2 ログイベントの監視ルール式の変数名

変数	説明	データ型
CONTEXTID	要求と一緒に伝播される要求 ID。	文字列
DATE	ログメッセージが作成されたときの日付。	文字列
MACHINE	ログメッセージを生成したマシンの名前。	文字列
MESSAGE	ログメッセージのメッセージコンテンツ。	文字列
MSGID	ログメッセージの ID (通常、「BEA=」で始まる)。	文字列
SERVER	ログメッセージを生成したサーバの名前。	文字列
SEVERITY	ログメッセージ属性の重大度。値は、ALERT、CRITICAL、DEBUG、EMERGENCY、ERROR、INFO、NOTICE、OFF、TRACE、および WARNING。	文字列
SUBSYTEM	ログメッセージを送信するサブシステムの名前。	文字列
THREAD	ログメッセージを生成したスレッドの名前。	文字列
TIMESTAMP	ログメッセージが作成されたときのタイムスタンプ。	Long
TXID	ログメッセージを生成したスレッドの JTA トランザクション ID。	文字列
USER_ID	ログメッセージを生成したユーザの ID。	文字列

次に、ログイベントの監視ルール式の例を示します。

(Severity = 'Warning') AND (Id = 'BEA-320012')

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

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

表 A-3 では、インスツルメンテーションデータレコード属性の変数名について説明します。

表 A-3 インスツルメンテーションイベントのルール式の変数名

変数	説明	データ型
ARGUMENTS	呼び出されたメソッドに渡される引数。	文字列
CLASSNAME	ジョインポイントのクラス名。	文字列
CONTEXTID	インスツルメンテーションイベントの診断コンテキスト ID。	文字列
CTXPAYLOAD	この要求に関連付けられたコンテキストペイロード。	文字列
DOMAIN	ドメインの名前。	文字列
FILENAME	ソースファイル名。	文字列
LINENUM	ソースファイルの行番号。	整数
METHODNAME	ジョインポイントのメソッド名。	文字列
METHODDSC	ジョインポイントのメソッドの引数。	文字列
MONITOR	モニタの名前。	文字列
PAYLOAD	インスツルメンテーションイベントのペイロード。	文字列
RECORDID	ログ内のレコードの数。	Long
RETVAL	ジョインポイントの戻り値。	文字列
SCOPE	インスツルメンテーションスコープの名前。	文字列
SERVER	インスツルメンテーションイベントを作成したサーバの名前。	文字列
TIMESTAMP	インスツルメンテーションイベントが作成されたときのタイムスタンプ。	Long
TXID	インスツルメンテーションイベントを作成したスレッドの JTA トランザクション ID。	文字列
TYPE	モニタの種類。	文字列
USERID	インスツルメンテーションイベントを作成したユーザの ID。	文字列
DYES	この要求に関連付けられた仕分け。	Long

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

(ActionType = 'ThreadDumpAction')

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

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

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

1 つの型のすべてのインスタンスの 1 つの属性を指定するには、次の構文を使用します。

      ${[type_name]//attribute_name}

1 つの WebLogic 型の 1 つのインスタンスの 1 つの属性を指定するには、次の構文を使用します。

      ${com.bea: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、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 データアクセサの詳細については、「データアクセサを使用した診断データへのアクセス」を参照してください。

ログフィルタ式の作成

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

CONTEXTID
DATE
MACHINE
MESSAGE
MSGID
RECORDID
SEVERITY
SUBSYSTEM
SERVER
THREAD
TIMESTAMP
TXID
USERID

注意 : これらの変数は、既存のサーバログから診断データの履歴を取得するデータアクセサクエリの作成に使用する変数と同じです。

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

複雑な式の作成

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

次のようにサブ式を括弧で囲んで、クエリをネストすることができる。

  (Severity = 'Warning') AND (Id = 'BEA-320012')

MBean オブジェクト名の場合と同じように、特殊な文字が含まれる場合は変数名を ${} で囲むことができる。次に例を示します。

${mydomain:Name=myserver,
      Type=ServerRuntime//SocketsOpenedTotalCount} >= 1

監視の変数名では、オブジェクト名と属性名が「//」で区切られます。