| Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方 11g リリース1 (10.3.3) B60994-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方 11g リリース1 (10.3.3) B60994-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設定します。それ以外の場合、演算結果は0に設定されます。 例に関して、上の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を介してモニターできますが、パフォーマンスに影響するため推奨されません。ベスト・プラクティスは、各管理対象サーバーで常駐ウォッチャを使用し、その管理対象サーバー・インスタンスに関連するメトリックをモニターすることです。
ハーベスタの監視ルール式でインスタンス名にワイルドカードを使用したり、複合属性を指定することもできます。付録C「式でのワイルドカードの使用」を参照してください。
ハーベスタの監視ルール式を作成するための構文は次のとおりです。
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データ・アクセサの詳細は、第13章「データ・アクセサを使用した診断データへのアクセス」を参照してください。
問合せ言語を使用すると、サーバー・ログに書き込まれたログをフィルタ処理できます。ログ・フィルタ式の作成に使用する変数は、ログの列を表します。
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
監視の変数名では、オブジェクト名と属性名が「//」で区切られます。
