C WLDF問合せ言語

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

この付録の内容は次のとおりです。

問合せ式の構成要素

問合せ式には以下のものを含めることができます。

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

問合せ言語では、大文字と小文字は区別されます。

サポートされる演算子

問合せ言語は表C-1に記載された演算子をサポートします。

表C-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')

演算子の優先順位

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

( )
NOT
&, |
=, !=, <, >, <=, >=, LIKE, MATCHES,IN
AND
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)メソッドに関するドキュメントを参照してください。

式内の変数について

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

注意:

ポリシー式の変数で、カスタムMBean ObjectNameインスタンスに一致するワイルドカード・パターンを指定する場合、パターンが正確であることを確認します。MBeanタイプ名を含め、不正確なインスタンス・パターンを使用すると、次のような結果になる場合があります。

WebLogic Server実行時MBeanインスタンスのみがパターンに一致します。
目的のカスタムMBeanインスタンスが無視される。

たとえば、次のObjectNameパターンは、タイプを明示的に宣言せず、WebLogic Server実行時MBeanインスタンスと一致する可能性がある曖昧なObjectNameパターンを使用します。

${ServerRuntime//com.b*:Type=Server*,*}

前述のパターンはWebLogic ServerランタイムMBeanインスタンスに一致し、同じパターンに一致するカスタムMBeanは無視されます。

ポリシー式の作成

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

WLDFポリシーの構成および使用の詳細は、次を参照してください。

ログ・イベントのポリシー式の作成

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

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

表C-2 ログ・イベントのポリシー式の変数名

変数	説明	データ型
`CONTEXTID`	リクエストと一緒に伝播されるリクエストID。	文字列
`DATE`	ログ・メッセージが作成されたときの日付。	文字列
`MACHINE`	ログ・メッセージを生成したマシンの名前。	文字列
`MESSAGE`	ログ・メッセージのメッセージ・コンテンツ。	文字列
`MSGID`	ログ・メッセージのID (通常、「BEA=」で始まります)。	文字列
`RECORDID`	ログ内のレコードの数。	Long
`SERVER`	ログ・メッセージを生成したサーバーの名前。	文字列
`SEVERITY`	ログ・メッセージ属性の重大度。有効な値は、`Info`、`Notice`、`Warning`、`Error`、`Critical`、`Alert`および`Emergency`です。	文字列
`SUBSYTEM`	ログ・メッセージを送信するサブシステムの名前。	文字列
`THREAD`	ログ・メッセージを生成したスレッドの名前。	文字列
`TIMESTAMP`	ログ・メッセージが作成されたときのタイムスタンプ。	Long
`TXID`	ログ・メッセージを生成したスレッドのJTAトランザクションID。	文字列
`USERID`	ログ・メッセージを生成したユーザーのID。	文字列

次に、ログ・イベントのポリシー式の例を示します。

  (SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')

インストゥルメンテーション・イベントのポリシー式の作成

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

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

表C-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型、インスタンス、属性、またはインスタンスと属性を指定できます。

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

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

${com.bea:Name=HarvesterRuntime,Location=myserver,Type=HarvesterRuntime,
      ServerRuntime=myserver//TotalSamplingCycles} > 10

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

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

データ・アクセサ問合せには以下が含まれます。

データ・ストアの論理名。「データ・ストアの論理名」を参照してください。
データを取得する1つまたは複数の列の名前(オプション)。「データ・ストアの列名」を参照してください.。

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

データ・ストアの論理名

データ・ストアの論理名は、一意のものである必要があります。論理名によって示されるのは、サーバー上で利用可能な特定のデータ・ストアです。論理名は、ログの種類を表すキーワードと、フォワード・スラッシュ(/)デリミタで区切られた0個以上の識別子で構成されます。たとえば、サーバー・ログ・データ・ストアの論理名は単純にServerLogとなります。しかし、他の種類のログの場合は、表C-4に示すように追加の識別子が必要になることがあります。

表C-4 ログの種類の命名規則

ログの種類	省略可能な識別子	例
ConnectorLog	接続ファクトリのJNDI名	ConnectorLog/eis/ 900eisaBlackBoxXATxConnectorJNDINAME この例の`eis/900eisaBlackBoxXATxConnectorJNDINAME`は、`weblogic-ra.xml`デプロイメント記述子で指定されている接続ファクトリのJNDI名です。
DataSourceLog	なし	`DataSourceLog`
DomainLog	なし	DomainLog
EventsDataArchive	なし	EventsDataArchive
HarvestedDataArchive	なし	HarvestedDataArchive
HTTPAccessLog	仮想ホスト名	`HTTPAccessLog` — デフォルトのWebサーバーのアクセス・ログ `HTTPAccessLog/MyVirtualHost` — 現在のサーバーにデプロイされているMyVirtualHostという仮想ホスト注意: HTTPAccessLogの拡張フォーマットでは、列数をユーザーが定義できます。
JMSMessageLog	JMSサーバーの名前	JMSMessageLog/MyJMSServer
JMSSAFMessageLog	SAFエージェントの名前。	`JMSSAFMessageLog/MySAFAgent`
ServerLog	なし	ServerLog
WebAppLog	Webサーバー名+ルート・サーブレットのコンテキスト名	WebAppLog/MyWebServer/MyRootServletContext

データ・ストアの列名

問合せに含まれる列名は、データの行ごとに解決されます。結果セットに行が追加されるのは、指定したすべての列についてその行が問合せ条件を満たしたときだけです。問合せで列名を省略した場合、ログのすべてのエントリが返されます。

表C-5に、WebLogic Serverの全種類のログの列名をすべて示します。

表C-5 ログの種類の列名

ログの種類	列名
ConnectorLog	LINE、RECORDID
DataSourceLog	RECORDID、DATASOURCE、PROFILETYPE、TIMESTAMP、USER、PROFILEINFORMATION、SUPP_ATTRS、PARTITION_ID、PARTITION_NAME
DomainLog	CONTEXTID、DATE、MACHINE、MESSAGE、MSGID、RECORDID、SERVER、SEVERITY、SUBSYSTEM、THREAD、TIMESTAMP、TXID、USERID、SUPP_ATTRS、SEVERITY_VALUE、PARTITION_ID、PARTITION_NAME
EventsDataArchive	ARGUMENTS、CLASSNAME、CONTEXTID、CTXPAYLOAD、DOMAIN、DYES、FILENAME、LINENUM、METHODNAME、METHODDSC、MODULE、MONITOR、PAYLOAD、RECORDID、RETVAL、SCOPE、SERVER、THREADNAME、TIMESTAMP、TXID、TYPE、USERID、PARTITION_ID、PARTITION_NAME
HarvestedDataArchive	ATTRNAME、ATTRTYPE、ATTRVALUE、DOMAIN、NAME、RECORDID、SERVER、TIMESTAMP、TYPE、WLDFMODULE、PARTITION_ID、PARTITION_NAME
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
JMSSAFMessageLog	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ロギング・サービスの詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』の「WebLogic Serverログ・メッセージのフィルタ処理」を参照してください。

複雑な式の作成

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

次のようにサブ式をカッコで囲んで、問合せをネストできます。
```
  (SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')
```
MBeanオブジェクト名の場合と同じように、特殊な文字が含まれる場合は変数名を${}で囲むことができる。例:
```
${mydomain:Name=myserver,
      Type=ServerRuntime//SocketsOpenedTotalCount} >= 1
```
ポリシーの変数名では、オブジェクト名と属性名を連続するフォワード・スラッシュ(//)で区切ります。