| Oracle ® Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方 11g リリース 1 (10.3.1) B55523-01 |
|
 戻る |
 次へ |
| Oracle ® Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方 11g リリース 1 (10.3.1) B55523-01 |
|
戻る |
次へ |
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 設定します。それ以外の場合、演算結果は ０ に設定される。 例に関して、上の bitwise & 演算子のエントリーを参照してください。 |
|
= |
比較 |
数値、文字列 |
等しい |
|
!= |
比較 |
数値 |
等しくない |
|
< |
比較 |
数値 |
より小さい |
|
> |
比較 |
数値 |
より大きい |
|
<= |
比較 |
数値 |
以下 |
|
>= |
比較 |
数値 |
以上 |
|
LIKE |
一致 |
文字列 |
文字列が指定したパターン (ワイルドカード使用可) に一致するときに true と評価される。 LIKE は 2 つのワイルド カード キャラクタをサポートします。 パーセント記号 (%) はゼロのどんなストリングか、より多くのキャラクタにも合っています。 ピリオド (.) は単一の文字に一致する。 |
|
MATCHES |
一致 |
文字列 |
対象の文字列がオペランド String の正規表現パターンに一致するときに true と評価される。 |
|
IN |
検索 |
文字列 |
変数の値があらかじめ定義されたセット内に存在するときに true と評価される。次に例を示す。 SUBSYSTEM IN ('A','B') |
以下に、演算子間の優先順位のレベルを、高いものから順に示します。同じ行に示す演算子は、すべて同等の優先順位です。
( )
NOT
&, |
=, !=, <, >, <=, >=, LIKE, MATCHES,IN
AND
OR
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) メソッドに関するマニュアルを参照してください。
変数は、実行時に評価されるクエリ式の動的な部分を表します。以下の節の説明に従って、作成する式の種類に合った適切な変数を使用する必要があります。
監視は、ログ イベント、インスツルメンテーション イベント、および収集された属性に基づいて作成できます。式の作成でサポートされる変数は、監視の種類ごとに異なります。以下の節を参照してください。
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。 |
文字列 |
次に、ログ イベントの監視ルール式の例を示します。
(SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')
インスツルメンテーション イベントの監視ルール式は、診断モニタ アクションによって作成されたデータ レコードの属性に基づきます。
表 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。 |
文字列 |
次に、インスツルメンテーション イベント データのルール式の例を示します。
(USERID = 'weblogic')
ハーベスタの監視ルール式は、収集可能な 1 つまたは複数の MBean 属性に基づきます。式では、MBean 型、インスタンス、および属性を指定できます。
インスタンスベースの式および型ベースの式には、監視対象メトリックのネームスペースである namespace コンポーネントを必要に応じて含めることができます。このネームスペースは、ServerRuntime または DomainRuntime に設定できます。指定しない場合のデフォルト値は ServerRuntime です。
DomainRuntime に含められていて、設定される場合、用法を ServerLifeCycleRuntimeMBean などの DomainRuntime 特有の MBeans だけをモニターするのに制限する必要があります。リモートの管理対象サーバ 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 となります。しかし、他の種類のログの場合は、表 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 と同じ |
次に、データ アクセサ クエリの例を示します。
(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 Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic Server ログ メッセージのフィルタ処理」を参照してください。
変数、バイナリ比較、その他の複雑なサブ式を含む、サブ式を使用した複雑なクエリ式を作成できます。ネストのレベルに制限はありません。以下のルールが適用されます。
次のようにサブ式を括弧で囲んで、クエリをネストすることができる。
(SEVERITY = 'Warning') AND (MSGID = 'BEA-320012')
MBean オブジェクト名の場合と同じように、特殊な文字が含まれる場合は変数名を $｛｝で囲むことができる。次に例を示します。
${mydomain:Name=myserver,
Type=ServerRuntime//SocketsOpenedTotalCount} >= 1
監視の変数名では、オブジェクト名と属性名が「//」で区切られます。
