5 Oracle Dynamic Monitoring Serviceの使用
Oracle Dynamic Monitoring Service (DMS)は、コンポーネントのパフォーマンス・データを公開します。
- Dynamic Monitoring Service (DMS)について
Oracle Dynamic Monitoring Service (DMS)を使用すると、Oracle Fusion MiddlewareコンポーネントでOracle Enterprise Managerなどの管理ツールにコンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できます。 - DMSの可用性について
DMS機能をすべての認証されたJava EEサーバーで使用できます。 - DMSのアーキテクチャについて
DMSのコンポーネントについて理解し、他のOracle Fusion Middlewareコンポーネントとの対話方法を理解することが重要です。 - DMSメトリックの表示
開発者、システム管理者およびサポート・アナリストがシステム・パフォーマンスの分析やシステム・ステータスのモニタリングを実行できる情報を収集するため、Oracle Fusion Middlewareコンポーネントは、DMSメトリックでインストゥルメンテーションします。 - WLDFを使用したDMSメトリックのアクセス
特定の条件が満たされたときに、モニタリングの目的でMBeanデータを収集するようWLDFを構成できます。 - DMS実行コンテキストについて
DMS実行コンテキストは、リクエスト(RMIリクエストなど)を一意に識別してシステム内での動向を追跡できるメカニズムです。 - DMSトレースおよびイベント
DMSトレース機能を使用すると、問題を診断したり、特定の基準セットを使用して特定時間の特定データを収集したりできます。 - DMSのベスト・プラクティス
DMSメトリックを使用する際には、次のベスト・プラクティスを実施します。
親トピック: 概要
Dynamic Monitoring Service (DMS)について
Oracle Dynamic Monitoring Service (DMS)を使用すると、Oracle Fusion MiddlewareコンポーネントでOracle Enterprise Managerなどの管理ツールにコンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できます。
Fusion MiddlewareコンポーネントはDMSにデータをプッシュし、DMSは異なるコンポーネントの範囲でそのデータを公開します。DMSは、メトリック、トレース・イベントおよびシステム・パフォーマンスを測定および報告し、これらのコンポーネントのコンテキスト相関サービスを提供します。
共通のDMSの用語と概念の理解
DMSには、DMSセンサー、DMSナウンおよびDMSトレースとイベントに関連する共通の用語および概念があります。
DMSセンサー
DMS センサーは、パフォーマンス・データを測定します。このセンサーによって、DMSによる一連のメトリックの定義および収集が可能になります。メトリックには、センサーに常に含まれるものとオプションとして含まれるものがあります。
DMS PhaseEventセンサー
DMS PhaseEventセンサーは、コード内の特定セクションの開始から終了までにかかる時間を測定します。あるメソッドまたはコード・ブロックの処理にかかる時間を追跡する場合は、PhaseEventセンサーを使用します。
DMSでは、PhaseEventセンサーの処理にかかる平均時間、最大時間、最小時間など、PhaseEventに関連するオプションのメトリックを計算できます。
表5-1に、PhaseEventセンサーで使用可能なメトリックを示します。
表5-1 DMS PhaseEventセンサーのメトリック
| メトリック | 説明 |
|---|---|
|
|
フェーズ デフォルトのメトリック: |
|
|
プロセスの開始以降にフェーズ オプションのメトリック。 |
|
|
オプションのメトリック。 |
|
|
オプションのメトリック。 |
|
|
フェーズ オプションのメトリック。 |
|
|
DMS統計の収集時にフェーズ オプションのメトリック。 |
|
|
プロセスの開始以降に、フェーズ オプションのメトリック。 |
親トピック: DMSセンサー
DMSイベント・センサー
DMSイベント・センサーは、システム・イベントをカウントします。継続時間の短いシステム・イベントや、イベントの発生が重要な場合は、DMSイベント・センサーで追跡します。
表5-2に、イベント・センサー関連のメトリックを示します。
表5-2 DMSイベント・センサーのメトリック
| メトリック | 説明 |
|---|---|
|
|
プロセスの開始以降にイベントが発生した回数を示します。 デフォルト: |
親トピック: DMSセンサー
DMS状態センサー
DMS状態センサーは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。サポートされている型は、integer、double、longおよびobjectです。システムのステータス情報を追跡する場合や、イベントに関係のないメトリックが必要な場合は、状態センサーを使用します。たとえば、状態センサーを使用して、キューの長さ、プール・サイズ、バッファ・サイズまたはホスト名を追跡します。状態センサーには、事前に計算された値を割り当てます。
表5-3に、状態センサーのメトリックを示します。状態センサーは、デフォルトのメトリックvalueおよびオプションのメトリックをサポートします。オプションのminValueメトリックおよびmaxValueメトリックは、状態センサーが(integer型、double型、long型などの)数値のJavaプリミティブを表す場合にのみ適用されます。
表5-3 DMS状態センサーのメトリック
| メトリック | 説明 |
|---|---|
|
|
デフォルト: |
|
|
オプションのメトリック。 |
|
|
起動後の オプションのメトリック。 |
|
|
起動後のこの オプションのメトリック。 |
親トピック: DMSセンサー
センサーの命名規則
次のリストは、DMSセンサーの命名規則を示しています。
-
Sensor名は、簡潔で説明的なものにする必要があります。冗長になるのを避けるため、センサー名には、ナウン名の一部やナウン・タイプを含めないようにします。
-
Sensor名には、個々のメトリックの値を含めないでください。
-
センサーを説明するために複数の単語を組み合せる必要がある場合は、最初の単語は小文字で、以降の単語は大文字で始める必要があります。たとえば、
computeSeries。 -
一般に、センサー名に/を使用することは避けてください。ただし、/を含む名前を使用することに意味がある場合もあります。ナウン名またはセンサー名に/を使用した場合は、そのセンサーをDMSメソッドの文字列で使用する際に、かわりのデリミタとして、パスにまったく存在しない,や_などを使用する必要があります。そうすることで、/はデリミタではなく、ナウン名またはセンサー名の一部であることが正しく認識されるようになります。
たとえば、次のような名前の子ナウンがあるとします。
examples/jsp/num/numguess.jsp
これは、次のような文字列を使用して検索できます。
,default,WEBs,defaultWebApp,JSPs,example/jsp/num/numguess.jsp,service
この場合のデリミタは,です。
-
EventセンサーおよびPhaseEventセンサーの名前は、英単語を動詞+名詞という形式で組み合せて定義します。たとえば、
activateInstanceおよびrunMethod。PhaseEventによって関数、メソッドまたはコード・ブロックを監視する場合は、実行されるタスクをできるだけ明確に反映した名前を使用する必要があります。 -
状態センサーの名前には名詞を使用する必要があります。場合によっては、この状態センサーで追跡する値の内容を説明する形容詞が前に付きます。たとえば、
lastComputed、totalMemory、port、availableThreads, activeInstances。 -
混乱を避けるため、
.time、.value、.avgなどの文字列をセンサー名に使用しないでください。表5-1、表5-2および表5-3に示したとおり、これらはセンサー・メトリックの名前であるためです。
親トピック: DMSセンサー
DMSナウン
DMSナウンはパフォーマンス・データを編成します。センサーは、関連付けられたメトリックとともに、ナウンに従って階層に編成されます。ナウンを使用すると、ファイル・システムのディレクトリ構造と同様の方法で、DMSメトリックを編成できます。たとえば、ナウンは、クラス、メソッド、オブジェクト、キュー、接続、アプリケーション、データベース、その他の測定の対象を表すことができます。
ナウン・タイプはナウンの種類を識別する属性です。エンティティと似たタイプを表すナウンは、一般に同じナウン・タイプを持ち、通常はそれらの各エンティティについて共通の測定セットを記録します。
一般的なDMSネーミング
ナウン名は、デリミタを含まない単純な文字列です。たとえば、BasicBinomialはナウン名です。ナウンのフルネームは、ナウン名にネームスペースとローカルパートを付けて構成されます。ナウン名の前に、その親のフルネームとデリミタが付きます。たとえば、/dmsDemo/BasicBinomial/"{http://mynamespace/}JAXWSHelloService"はナウンのフルネームです。
センサー名は、.や派生を含まない単純な文字列です。たとえば、computeSeries、loopsおよびlastComputedはセンサー名です。
センサーのフルネームは、そのセンサーが関連付けられたナウンの名前、デリミタ、センサー名で構成されます。たとえば、/dmsDemo/BasicBinomial/computeSeries、/dmsDemo/BasicBinomial/loops、/dmsDemo/BasicBinomial/lastComputedなどです。
DMSメトリック名は、センサー名、.文字、メトリックで構成されます。たとえば、computeSeries.time、loops.countおよびlastComputed.valueは有効なDMSメトリック名です。
ノート:
接尾辞.time、.countおよび.valueは変更できません。ただし、センサー名およびナウン名は必要に応じて変更可能です。
親トピック: DMSナウン
一般的なDMS命名規則と文字セット
DMSには可能なかぎり簡潔な名前を付ける必要があります。また、ナウンやセンサーの名前を定義する場合は、特殊文字(空白、スラッシュ、ピリオド、カッコ、カンマ、制御文字など)を使用しないでください。
表5-4に、DMSの名前の中で特殊文字のかわりに使用する代替文字を示します。
表5-4 DMSの名前の中で特殊文字のかわりに使用する代替文字
| 文字 | DMSの代替文字 |
|---|---|
|
空白文字 |
アンダースコア: |
|
ピリオド: |
アンダースコア: |
|
制御文字 |
アンダースコア: |
|
より小さい: |
開きカッコ: |
|
より大きい: |
閉じカッコ: |
|
アンパサンド: |
カレット: |
|
二重引用符: |
バッククォート: |
|
一重引用符: |
バッククォート: |
ノート:
Oracle Fusion Middlewareには、組込みメトリックがいくつか用意されています。Oracle Fusion Middlewareの組込みメトリックが、このDMS命名規則に常に従っているとはかぎりません。
親トピック: DMSナウン
ナウンおよびナウン・タイプの命名規則
ナウンおよびナウン・タイプのネーミングに次の規則が使用されます。
-
ナウン名は一意である必要があります。
-
ナウンには、特定のエンティティを識別する名前を付る必要があります。
-
ナウン・タイプには、収集対象となるメトリックのセットを明確に表す名前を使用する必要があります。たとえば、Servletというナウン・タイプは、そのナウンで特定のサーブレットに固有のメトリックを収集することを示します。
-
ナウン・タイプ名は、他のDMSの名前と区別するために大文字で始める必要があります。同じタイプのナウンはすべて、同じセンサーのセットを持つ必要があります。
-
ナウンのネーミング方式では階層のルートに/を使用し、各ナウンがルート、または親ナウンの下にあるコンテナとして機能します。
親トピック: DMSナウン
DMSトレースおよびイベント
概念的にはDMSはイベント・ストリームを生成し、その各イベントは、DMSと統合するコンポーネント(更新されるセンサーなど)によりDMS APIに対して実行された、いずれかのイベント作成アクションの応答です。このイベント・ストリームは無視するか、またはなんらかの方法でイベントに応答できる宛先にルーティング(および、オプションでフィルタ)できます。
表5-5に、DMSトレースおよびイベントの用語のリストを示します。
表5-5 DMSトレースおよびイベントの用語
| DMSの用語 | 定義 |
|---|---|
|
条件 |
条件は、条件フィルタのロジックです。条件で定義されたルールに基づいて、フィルタを通過するイベントを決定します。各条件フィルタにはゼロか1つのルート条件がありますが、ANDまたはOR引数を含めて複合条件を作成できます。単一のルート条件を使用して、比較的複雑なルールを示すことができます。 次の2つのタイプの条件が存在します。
「DMSトレースおよびイベント」を参照してください。 |
|
宛先 |
宛先は、渡されるイベントに対応するメカニズムを実装します。たとえば、ファイルにイベントのログを記録する宛先、Javaフライト・レコーダにイベントの変換されたコピーを送信される宛先、MBeanのデータとして着信イベントから収集された情報をレンダリングする宛先などがあります。 |
|
イベント・ルート |
イベント・ルートは、フィルタを宛先に接続します。イベント・ルートを有効または無効にできます。 |
|
フィルタ |
イベント・トレース・フィルタは、すべての使用可能なDMSランタイム・イベントのサブセットを選択的に渡します。渡されるイベントとブロックされるイベントを決定するルールとともにフィルタを構成できます。 たとえば、次の目的でフィルタを定義できます。
「DMSトレースおよびイベント」を参照してください。 |
|
リスナー |
DMSリスナーは、宛先とも呼ばれます。「宛先の構成」を参照してください。 |
親トピック: 共通のDMSの用語と概念の理解
DMSの可用性について
DMS機能をすべての認証されたJava EEサーバーで使用できます。
これには、実行時機能およびサポートしているコマンドの両方が含まれます。また、DMSのいくつかの機能がJSEアプリケーションおよびスタンドアロンCアプリケーションで動作します。
動作保証されているサーバーの詳細は、Oracle Fusion Middlewareの動作保証マトリクスを参照してください。
DMSのアーキテクチャについて
DMSのコンポーネントについて理解し、他のOracle Fusion Middlewareコンポーネントとの対話方法を理解することが重要です。
DMSは、次の機能で構成されます。
-
DMSメトリック: DMSメトリック機能は、パフォーマンス測定および他の便利な状態メトリックでコードのインストゥルメンテーションを行うためにOracle Fusion Middlewareコンポーネントで使用されるJavaおよびC APIを用意しています。
-
実行コンテキスト: 実行コンテキストは、Oracleスタック全体の特定のコンテキスト構造のメンテナンスおよび伝播をサポートします。伝播されたコンテキスト構造を利用することにより、Oracle Oracle Fusion Middlewareコンポーネントは同じまたは異なるサーバーおよびホスト上で実行される様々なコンポーネントや製品間で相関可能な診断情報(ログ・レコードなど)を記録できます。「DMS実行コンテキストについて」を参照してください。
-
イベントおよびトレース: イベント・トレースにより、再起動しないでライブ・トレースを構成できます。Oracle Fusion Middleware製品を使用して更新されたDMSメトリックは、DMSイベント・トレース機能を使用してトレースする必要があります。システムは、トレースを容易にするだけではなくDMSアクティビティから起動する他の機能もサポートするよう設計されています。
図5-1は、DMSのコンポーネントおよび他のOracle Fusion Middlewareコンポーネントとの対話方法を示しています。矢印は、コンポーネント間の情報フローの方向を示しています。
DMSメトリックの表示
開発者、システム管理者およびサポート・アナリストがシステム・パフォーマンスの分析やシステム・ステータスのモニタリングを実行できる情報を収集するため、Oracle Fusion Middlewareコンポーネントは、DMSメトリックでインストゥルメンテーションします。
Fusion Middleware Controlオンライン・ヘルプは、特定のメトリックごとの情報を示します。メトリック情報へのアクセスの詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのパフォーマンスの表示に関する項を参照してください。
Oracle Fusion Middlewareメトリックは、様々なソースおよび場所から発生します。これには、MBean属性およびDMSメトリックが含まれます。また、Oracleサーバーなどの非Java EEサーバーからも発生します。
様々なツールを使用してDMSメトリックを表示できます。
スパイ・サーブレットを使用したメトリックの表示
スパイ・サーブレットは、JRF拡張インストールでデフォルトでデプロイされるDMSアプリケーションの一部です。http://<host>:<port>/dms/Spyからスパイ・サーブレットが起動します。WebLogicのデフォルト・ポートは1521です。
DMSアプリケーションのWebアーカイブ・ファイルはdms.warで、dms.jar: oracle_common/modules/oracle.dms_12.1.2/dms.warと同じディレクトリにあります。
「DMSスパイ・サーブレット」を参照してください。
ノート:
スパイ・サーブレットはWebアプリケーションのweb.xmlファイルで標準のJava EEの宣言型セキュリティを使用して保護され、アクセスは管理者グループのメンバーにのみ付与されます。
親トピック: DMSメトリックの表示
WLDF (WebLogic診断フレームワーク)を使用したメトリックの表示
WebLogic診断フレームワーク(WLDF)を使用して、DMSメトリックMBeanからDMSメトリックを収集できます。WLDFを使用して、MBeanの属性値の変更もモニターできます。『Oracle WebLogic Server診断フレームワークの構成と使用』の「メトリック収集用のハーベスタの構成」を参照してください。
親トピック: DMSメトリックの表示
WLST (Oracle WebLogic Server)を使用したメトリックの表示
DMSには、WLSTでメトリックを表示する次の3つのコマンドがあり、それらの詳細を次の表に示します。
表5-6 DMSコマンド
| 使用するコマンド | 操作 |
|---|---|
|
|
使用できるメトリック表の名前を示します。 多数のメトリック表がある場合は、 ノート: たとえば:
|
|
|
DMSメトリック表の内容を示します。 多数のDMSメトリック表がある場合は、 ノート: たとえば:
|
|
|
内部形式でメトリックを表示します。dumpMetricsコマンドの有効な形式には、RAW、XMLおよびPDMLがあります。 多数のDMSメトリック表がある場合は、 ノート: たとえば:
|
これらのコマンドは、テキスト出力を表示して、スクリプトの処理に使用できる構造化オブジェクトまたは単一の値も戻します。
これらのコマンドの使用の詳細は、次の項を参照してください。
-
『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイド
-
『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のDMSメトリック・コマンドに関する項
親トピック: DMSメトリックの表示
JConsoleを使用したメトリックの表示
メトリックにアクセスする標準ベースの手段を提供するため、DMSはMBeanを通じてメトリックを公開します。ランタイムMBeanサーバーで入力された各ナウンにMBeanが作成および登録されます。ナウンに含まれるDMSセンサーがMBeanの属性として公開されます。MBeanとしてDMSメトリックを公開すると、管理者はJConsole (Javaモニタリングおよび管理コンソール)などのツールを使用でき、他のJava Management Extension (JMX)クライアントはDMSメトリックにアクセスできます。
WLDFを使用したDMSメトリックのアクセスに示すとおり、MBeanはWLDF (WebLogic診断フレームワーク)などの他のOracle診断ソフトウェアと統合することもできます。ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。
ノート:
JConsoleを使用すると、DMSで生成されたMBeanをJava EEサーバーでローカルまたはリモートに表示できます。DMSは、有効なナウン・タイプを持つ各Java DMSナウンのMBeanを生成します。非Java EEコンポーネントのメトリックおよびナウン・タイプを持たないDMSナウンのMBeanは生成しません。ナウンに含まれる各DMSメトリックがメトリックMBeanの属性にマップされます。
親トピック: DMSメトリックの表示
Oracle Enterprise Managerを使用したメトリックの表示
Oracle Fusion Middlewareは、コンポーネントのパフォーマンス、状態および進行中の動作に関するデータを自動的および継続的に測定します。メトリックが自動的に有効になるので、オプションの設定やメトリックを収集する余分な構成の実行は必要ありません。「Oracle Enterprise Manager Fusion Middleware Control」を参照してください
親トピック: DMSメトリックの表示
WLDFを使用したDMSメトリックのアクセス
特定の条件が満たされたときに、モニタリングの目的でMBeanデータを収集するようWLDFを構成できます。
WLDFには、特定の条件でMBean属性を収集およびモニターできる診断機能が用意されています。これにより、条件がトリガーされた場合に環境のアクティビティのモニタリングと電子メールおよびJMX通知の作成を事前に行う手段が提供されます。
次のステップは、WLDFを構成してWebLogic管理コンソールで電子メール通知を送信する方法を示しています。
また、WLDFを構成して、オフラインの格納および分析のためにMBeanデータを収集できます。特定のMBean属性を収集するためにWLDF診断モジュールを構成してこれを実施し、WebLogic管理コンソールを使用して実行できます。
WLDFを使用したMBeanデータの収集および監視の詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』の「メトリック収集用のハーベスタの構成」を参照してください。
DMS実行コンテキストについて
DMS実行コンテキストは、リクエスト(RMIリクエストなど)を一意に識別してシステム内での動向を追跡できるメカニズムです。
リクエストの遂行に含まれる連携しているFusion Middlewareコンポーネントの間でコンテキスト情報を通信できる手段も提供します。
DMS実行リクエストおよびサブタスク
リクエストまたはルート・タスクを完了するために調整される多くのサブタスクが単一のリクエスト(またはタスク)で作成できることを考慮して、DMS実行コンテキストが開発されています。リクエストおよび関連するサブタスクの次の例を検討してください。
-
ブラウザから直接Oracle WebLogic Serverに送信されるリクエスト
-
Oracle WebLogic Serverのルート・タスクのみ
-
-
リバース・プロキシとして動作するOracle ServerからOracle WebLogic Serverに送信されるリクエスト
-
Oracle Serverのルート・タスク
-
Oracle WebLogic Serverの単一のサブタスク
-
-
リクエストがリバース・プロキシとして動作するOracle ServerからOracle WebLogic Serverに送信され、Oracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になります。
-
Oracle Serverのルート・タスク
-
Oracle WebLogic Serverの単一のサブタスク
-
Webサービスごとの合計2つのサブタスク
-
DMS実行コンテキストは、次の内容で構成されます。
-
一意の識別子、実行コンテキストID (ECID)
ECIDは新しいルート・タスクごとに一意で、ルート・タスクに関連するタスクのツリーで共有されます。
-
リレーションシップ識別子、関係ID (RID)
RIDは、タスクのツリーで各タスクの場所を示す順序付けされた数値の集合です。先頭の数値は通常ゼロです。先頭の数値の1は、全体のサブタスク・ツリー内でサブタスクの場所を追跡できないことを示します。
-
グローバル関連データをOracle Fusion Middlewareコンポーネントで共有できる名前/値ペアのセット
次の3つのシナリオは、リクエストがリバース・プロキシとして動作するOracle ServerからOracle WebLogic Serverに送信され、Oracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になる場合のECIDおよびRIDの使用方法を示しています。
-
Oracle Serverのルート・タスク:
-
新しいECID = B5C094FA...BE4AE8
-
ルートRID = 0
-
-
Oracle WebLogic Serverの単一のサブタスク
-
同じECID = B5C094FA...BE4AE8
-
サブタスクRID = 0:1
-
-
Webサービスごとの合計2つのサブタスク
-
起動される最初のWebサービス
同じECID = B5C094FA...BE4AE8
サブタスクRID = 0:1:1
-
起動される2番目のWebサービス
同じECID = B5C094FA...BE4AE8
サブタスクRID = 0:1:2
-
親トピック: DMS実行コンテキストについて
DMS実行コンテキストの使用
サーバー間のログ・メッセージを関連付けると、DMS実行コンテキストの最も直接的な利点がわかります。ロギングのOracle標準形式には、ECID専用フィールドが含まれます。エラー・レベルのログ・メッセージからの読込みなどでECIDを確認した後、そのECIDを含むメッセージのログ・ファイルを問い合せて、タスクに関連する他のすべてのログ・メッセージを検索できます。
コマンドを使用する非常に特殊なケースの例を次に示します。
displayLogs(ecid="B5C094FA...BE4AE8");
この例では、ECID B5C094FA...BE4AE8を含むメッセージのログ・ファイルが表示されます。
親トピック: DMS実行コンテキストについて
DMS実行コンテキストの通信
図5-2は、DMS実行コンテキストを相互に通信するために連携するコンポーネントを示しています。コンポーネントを参照する矢印は、受信コンテキスト情報を検証するプロトコルを示します。外側の矢印は、コンテキスト情報が追加されるプロトコルを示します。単一のコンポーネントが自身にリクエストを送信し、そのリクエストにコンテキスト情報を渡すことできます。
親トピック: DMS実行コンテキストについて
DMSトレースおよびイベント
DMSトレース機能を使用すると、問題を診断したり、特定の基準セットを使用して特定時間の特定データを収集したりできます。
DMSは次のものを選択的にトレースできます。
-
DMSセンサー・ライフサイクル・イベント(状態センサー、イベント・センサーおよびフェーズ・センサーの作成、更新、削除)
-
コンテキスト・イベント(開始、停止)
-
イベント(開始、停止)
これらのタイプのイベントのトレースおよび処理方法を制御する構成がdms_config.xmlファイルに記録されます。DMSトレース構成は、次の3つに分類されます。
-
フィルタ構成
特定のイベントを選択するルールを定義します。
-
宛先構成
イベントの使用方法を定義します。
-
イベント・ルート(eventRoute)構成
使用するフィルタおよび接続する宛先を定義します。
フィルタを1つ以上の宛先に関連付けることができるので、管理者は一度フィルタ・ルールを定義して、1つ以上の宛先で処理されるすべての使用可能なイベントの結果サブセットを利用できます。
実行時にDMS構成MBeanまたはWLSTコマンドを使用して、構成を変更できます。このため、特定の期間に発生する問題の診断や特定の基準セットを使用した特定の時間の特定のデータの収集にDMSトレース機能が非常に役立ちます。
『Oracle Fusion Middlewareの管理』のWLSTを使用した選択的トレースの構成に関する項を参照してください。
次のタイプのフィルタ・ルールがサポートされます。
-
イベント・タイプ条件
イベントが
PHASE_SENSORのSTARTまたはSTOPからトリガーされているかどうかを識別するために使用されます。 -
コンテキスト・タイプ条件
コンテキストに値(
USERなど)が含まれる作業単位からイベントが生成されたかどうかを識別するために使用されます。 -
ナウン・タイプ条件
ナウンが特定のタイプ(
JDBC_CONNECTIONなど)のセンサーからイベントがトリガーされたかどうかを識別するために使用されます。 -
前述の条件の論理
ANDおよびORの組合せ
DMSイベント・システムの構成
構成は、各サーバーのdms_config.xmlファイルに記録されます。コマンド行インタフェース(CLI)コマンドおよびイベント構成Mbeanを使用して、実行時にMBeanを更新できます。スレッド・セーフの非アトミックの方法で構成の更新が実行中のシステムに適用されます。
DMSイベント構成MBeanのオブジェクト名は、oracle.dms.event.config:name=DMSEventConfigMBean,type=JMXEventConfigです。
システムのDMSイベント構成の現在の状態を確認するには、次のコマンドを使用します。
listDMSEventConfiguration([server=<server>])
出力結果は次のようになります。
Event routes:
FILTER : auto662515911
DESTINATION : destination1
ENABLED : true
FILTER : filter0
DESTINATION : q
ENABLED : true
Filters with no event route:
Fred
Destinations with no event route:
des4
フィルタの追加および編集
フィルタは、トレースに検討するイベントを選択するルールを定義します。
次の例は、JDBC操作に関連するすべてのイベントを選択するフィルタの追加方法を示しています。
addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE sw JDBC_'})
または
addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE startsWith JDBC_'})
このフィルタは、JDBC操作に関連するすべてのDMSセンサーの更新が名前がJDBC_で始まるタイプのナウンに実行されると仮定します。
ルールを変更する必要がある場合、次の例のようにフィルタを更新する必要があります。
updateDMSEventFilter(id="myJDBCFilter", props={'condition': 'NOUNTYPE startsWith JDBC_ OR NOUNTYPE startsWith MDS_'});
Oracle Fusion Middleware 11.1.1.6.0から、次の短縮された便利な演算子が追加されています。演算子は、短縮名または詳細名のいずれかを使用して指定できます。
アンダースコアが付いている演算子は非推奨になっているため、大文字と小文字の両方を使用するODL形式をお薦めします。たとえば、not_equalsはnotEqualsまたはneになります。古い形式でも機能しますが、非推奨です。
表5-7 DMS演算子
| ナウン・タイプ演算子 | 詳細 |
|---|---|
|
|
|
|
|
|
|
|
- |
| コンテキスト演算子 | 詳細 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
例:
addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE eq MDS_Connections AND CONTEXT user ne bruce'})
addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE equals MDS_Connections AND CONTEXT user notequals bruce'}) フィルタのルール(条件プロパティ)を示すために使用される構文の詳細は、WebLogic Scripting Toolコマンド・リファレンスまたはコマンド・ヘルプを参照してください。
親トピック: DMSイベント・システムの構成
宛先の追加および編集
宛先は、イベントに対応するロジックをカプセル化します。たとえば、基本の宛先でイベントのログを記録し、異なる宛先でイベントを変換して別のシステムに渡して追加処理を実行できます。
次の例は、イベントのログを記録する宛先の追加方法を示しています。
addDMSEventDestination(id="myLoggerDestination", class="oracle.dms.trace2.runtime.LoggerDestination", props={"loggerName":"myLogger"});
宛先の追加だけではイベントのログを記録できないので、イベント・ルートを使用してフィルタと宛先を関連付け、イベント・ルートを有効(デフォルト)にする必要があります。
使用できる宛先のタイプおよび構成オプションは、宛先の構成に説明されています。次の例は、既存の宛先の編集方法を示しています。
updateDMSEventDestination(id="myLoggerDestination", props={"loggerName":"myTraceLogger"});親トピック: DMSイベント・システムの構成
イベント・ルートの追加および編集
次の例は、フィルタの結合方法および宛先の作成方法を示しています。
addDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination')
明示的なfilterIdを使用しないでaddDMSEventRouteを起動できます。これらのシナリオでは、すべてのイベントがフィルタなしで宛先に渡されます。
フィルタまたは宛先を削除するには、フィルタまたは宛先に関連するイベント・ルートを無効になっていても最初に削除する必要があります。たとえば、myJDBCFilterを削除する場合、次の例に示すように、前の例で作成したイベント・ルートを最初に削除してからフィルタを削除する必要があります。
removeDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination') removeDMSEventFilter(id='myJDBCFilter')
親トピック: DMSイベント・システムの構成
複合操作
イベント・ルートの追加および編集のように2つの個別のコマンドではなく単一のコマンドを使用して、フィルタおよびそのフィルタに基づくイベント・ルートを作成できます。
ノート:
イベント・ルートで使用される宛先が事前に定義されている必要があります。
enableDMSEventTrace (destinationid='myLoggerDestination', condition='NOUNTYPE starts_with JDBC_')
前述の例で、enableDMSEventTraceは、指定された条件でフィルタを自動的に作成し、新しいフィルタおよび指定された宛先を使用してイベント・ルートを作成および有効化できます。次に、出力例を示します。
Filter "auto605449842" using Destination "myLoggerDestination" added, and event-route enabled for server "AdminServer"
親トピック: DMSイベント・システムの構成
宛先の構成
DMSは、複数のタイプの宛先を提供します。
LoggerDestination
表5-8 ロガー宛先
| プロパティ | 詳細 |
|---|---|
|
説明 |
LoggerDestinationは、各イベントを関連するロガーに書き込みます。 |
|
実装クラス |
oracle.dms.trace2.runtime.LoggerDestination |
|
プロパティ |
|
|
|
イベントが書き込まれるODLロガーの名前。 |
ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。
loggerNameプロパティにロガーの名前を指定しますが、必ずしもロガーをlogging.xmlに示す必要はありません。ロガー名がlogging.xmlで明示的に名前が付けられているロガーを示す場合、そのロガーは静的ロガーと呼ばれます(静的ロガーおよびハンドラを参照してください)。ロガー名がlogging.xmlで明示的に名前が付けられていないロガーを示す場合、そのロガーは動的ロガーと呼ばれます(動的ロガーおよびハンドラを参照してください)。
デフォルト構成: デフォルト構成は、LoggerDestinationを確認してロガー宛先を定義します。このインスタンスはeventRouteの一部を構成しないので、アクティブではありません。便宜上提供され、動的ロガーを使用します。
静的ロガーおよびハンドラ
ロガーは、ログの記録が示されるオブジェクトです。ログ・ハンドラは、ログの記録がログ・ファイルに書き込まれるオブジェクトです。
DMSトレース・データが書き込まれるログ・ファイルを完全に制御するには、logging.xmlのロガー宛先の名前のロガーを定義します。これにより、ログ・ファイルの名前、最大サイズ、形式、ファイル・ローテーションおよびポリシーを定義できます。
ここに示すコマンドを使用して構成を更新することをお薦めします。
setLogLevel(logger="myTraceLogger", level="FINER", addLogger=1); configureLogHandler(name="my-trace-handler", addToLogger=["myTraceLogger"], path="/tmp/myTraceLogFiles/trace", maxFileSize="10m", maxLogSize="50m", handlerType="oracle.core.ojdl.logging.ODLHandlerFactory", addHandler=1, useParentHandlers=0); configureLogHandler(name="my-trace-handler", propertyName="useSourceClassandMethod", propertyValue="false", addProperty=1);
ロギング構成の詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。
オプションのプロパティuseSourceClassandMethodを使用してFALSEに設定すると、SRC_CLASSおよびSRC_METHODが各メッセージに表示されなくなり、ファイルの出力時間が短縮されてパフォーマンスがわずかに改善します。
静的ロガーの場合、useParentHandlersパラメータをFALSEに設定することを検討してください。そうしない場合、重複したイベント・メッセージが[server]-diagnostics.logにログとして記録され、ログの問合せに表示されます。
「ログ・メッセージのDMSイベント・フォーマットの理解」を参照してください。
親トピック: LoggerDestination
動的ロガーおよびハンドラ
名前が付いたロガーに、logging.xmlに定義されたハンドラが関連付けられていない場合、サーバーのデフォルトのログ出力ディレクトリにあるファイルに書き込むハンドラ・オブジェクトがロガー宛先によって動的に作成されます。(ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。)ファイル名は、ロガー名の後に-event.logが付きます。たとえば、静的ロガーおよびハンドラの例では、DMSイベントはmyTraceLogger-event.logに書き込まれます。
親トピック: LoggerDestination
logging.xmlファイルのデフォルトの場所
logging.xmlファイルは、一般的に次のプラットフォームの場所のいずれかにあります。
表5-9 logging.xmlファイルのデフォルトの場所
| プラットフォーム | サーバー | 場所 |
|---|---|---|
|
Oracle WebLogic Server |
|
|
親トピック: LoggerDestination
CLIコマンドを使用したトレース・ログ・ファイルの問合せ
ロガー宛先のロガーおよびハンドラがlogging.xmlファイルに定義されている場合、displayLogs()コマンドを利用して、手動で特定または検索することなくログに記録されたトレース・データにアクセスできます。
例:
-
myTraceLoggerのすべてのログ・メッセージを表示するには、次のコマンドを実行します。
displayLogs(query='MODULE equals myTraceLogger')
-
ECIDが
0000HpmSpLWEkJQ6ub3FEH194kwB000004のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004')
-
最後の10分のECIDが
0000HpmSpLWEkJQ6ub3FEH194kwB000004のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004', last=10)
-
動的ロガーのすべてのログ・メッセージを表示するには、ログのファイル名を含める必要があります。
displayLogs(disconnected=1, log=DOMAIN_ROOT+"/servers/AdminServer/logs/myTraceLogger-event.log")
親トピック: LoggerDestination
MBean Creatorの宛先
表5-10 MBean Creatorの宛先の詳細
| プロパティ | 詳細 |
|---|---|
|
説明 |
MBean Creatorの宛先を使用すると、WLDF、JConsoleなどを使用したアクセスのためにナウンがMBeanとしてアクセス可能になり、属性としてそのメトリックを公開します。 |
|
実装クラス |
|
デフォルト構成の使用: MBean Creatorの宛先のインスタンスが構成されてデフォルトでアクティブになり、サーバーに作成されたすべてのナウンのMBeanが作成されます。
この宛先タイプのインスタンスをナウン・タイプのルールに基づくフィルタに関連付けると、管理者が指定するナウン・タイプのみをMBeanとして公開できます。
実行時にMBean Creatorの宛先に関連付けられた構成を変更できますが、このタイプの宛先の再初期化プロセスがパフォーマンスに影響することを理解する必要があります。そのため、頻繁な実行時の再構成は推奨されていません。
WebLogic診断フレームワーク(WLDF)を使用すると、MBean Creator宛先で公開されるDMSメトリックを収集できます。『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。
親トピック: 宛先の構成
メトリックMBeanのオブジェクト名
ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。
たとえば、ナウンのフルパス名は次のとおりです。
/oracle/dfw/ofm/base_domain/AdminServer
ナウン・タイプはDFW_Incidentで、ナウンを表すMBeanのオブジェクト名は次のとおりです。
oracle.dms:Location=AdminServer,name=/oracle/dfw/ofm/base_domain/AdminServer,type=DFW_Incident
親トピック: MBean Creatorの宛先
リクエスト・トラッカの宛先
表5-11 リクエスト・トラッカの宛先
| プロパティ | 詳細 |
|---|---|
|
説明 |
リクエスト・トラッカの宛先は、アクティブなリクエストのリストを保持し、リクエストを他の診断フレームワーク(DFW)コンポーネントでアクセス可能にします。 |
|
実装クラス |
|
|
プロパティ |
|
|
|
追跡から除外されるヘッダー名のカンマ区切りのリスト。 |
デフォルト構成の使用: リクエスト・トラッカ宛先のインスタンスはデフォルトで有効です。生成されるDFWインシデントの場合、アクティブなリクエストのリストが自動的にダンプされるので、管理者は障害と特定のリクエストを相互に関連付けることができます。
リクエストごとに次の情報がダンプされます。
-
Uniform Resource Identifier(URI)
-
リクエストの開始時間
-
実行コンテキストID (ECID)
-
問合せ文字列
-
ヘッダー
リクエスト・トラッカが有効ではない場合、リクエスト・ダンプが次の内容を出力します。
Requests are not being tracked. To enable request tracking enable the DMS oracle.dms.event.RequestTrackerDestination in dms_config.xml
親トピック: 宛先の構成
リクエスト・トラッカのダンプの実行
リクエスト・トラッカに保持される情報に手動でアクセスできます。リクエスト情報を報告するダンプを実行するには、サーバーの接続時に、次のようにWLST executeDumpコマンドを使用できます。
> executeDump(name=".requests") Active Requests: StartTime: 2009-12-14 02:24:41.870 ECID: 0000IMChyqEC8xT6uBf9EH1B9X9^000009,0 URI: /myApp/Welcome.jsp QueryString: Headers: Host: myHost.example.com:7001 Connection: keep-alive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip,deflate Cookie: ORA_MOS_LOCALE=en%7CGB; s_nr... Accept-Language: en-GB,en-US;q=0.8,en;q=0.6 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
親トピック: リクエスト・トラッカの宛先
Javaフライト・レコーダの宛先
Javaフライト・レコーダ(JFR)は、Java JVMの実行時ステータスおよび動作に関する情報を記録します。JFRは、サード・パーティ・イベントを報告できるAPIも公開します。
DMSはトレースを実行し、JFRはサーバーで実行されているアクション全体の表示部分のみをトレースします。JFRとDMSの統合は、次に示すように管理者と開発者が使用できる診断情報を拡張します。
-
アプリケーション・レベル・イベントおよびJVMレベル・イベントを1つの手順として報告できます。これにより、タイムスタンプだけに基づいて個別のログ・ファイルからこのようなイベントを結合する必要がなくなります(同時に作成されるイベントを正確に順序付けできるほど迅速に動作しない場合があります)。
-
任意にJVMから遡及して最近のDMSアクティビティをダンプできます。
-
JVMが正常に終了する致命的なエラーの場合、最近のDMSおよびJVMイベントをディスクにダンプできます。
-
DMS ECIDを使用すると、JFR記録期間に同じリクエストに関連するアクティビティ(作業単位)を相互に関連付けることができます。
-
DMS ECIDを使用すると、JFRで記録される単一および一連のイベントに関連するすべてのシステムの診断情報を収集できます。
動的に導出されたJFRイベント・タイプ - 名前、値および説明
DMSナウン・タイプは、JFR InstantEventイベント・タイプに関連付けられます。
-
ナウン・タイプのJFRイベント・タイプの名前は、接尾辞
stateの付いたナウン・タイプの名前になります。 -
ナウン・タイプのJFRイベント・タイプのパスは、
dms/、プロデューサ名、イベント・タイプ名の順に付けられます。 -
イベント・センサーは、値をJFRイベント・タイプに提供しません。
-
ナウン・タイプのJFRイベントの値を表5-12に示します。
表5-12 ナウン・タイプのJFRイベントの値
値の名前 説明 リレーショナル ノート ECIDアクションに関連付けられた実行コンテキストID (ECID)。
はい
RIDアクションに関連付けられたRID。
はい
<ナウン・タイプ>名ナウンのフルパス。
このフィールドは、ナウンのフルパスに移入されます。フィールドの名前は、noun_typeを使用してそのタイプのナウンで測定されているすべてのオブジェクトが適切に分類されていると仮定します。
<state-sensor-name>状態センサーの値。
いいえ
ナウンに属する各状態センサーは、これらの値のいずれかを即時イベントに提供します。各ナウンに複数の値が存在する場合があります。
イベント名更新されたイベント・センサーの名前(それ以外の場合はnull)。
いいえ
DMSイベント・センサーが更新された回数を記録するには、イベント名フィールドが必要です(イベント・センサーは値をイベント・タイプに提供しません)。
DMSフェーズ・センサーは、次のようにJFR DurationEventイベント・タイプに関連付けられます。
-
特定のナウン・タイプのナウンに属しているフェーズ・センサーのJFRイベント・タイプの名前は、後にフェーズ・センサーの名前が付けられるナウン・タイプの名前になります。
-
ナウン・タイプのJFRイベントのパスは、
dms/、プロデューサ名、イベント・タイプ名の順に付けられます。 -
期間イベントの値は前述のようになります(sensorName値を除きます)。たとえば、フェーズ・イベントの停止がフェーズ・イベントの親ナウンの状態情報を含むJFRに報告されるJFR期間イベントになります。
いくつかのDMSオブジェクトにより、インテグレータで説明を追加できます。DMSオブジェクトの説明は、次のように使用されます。
-
ナウン・タイプの説明は、JFRイベント・タイプの作成に使用されます。
-
状態およびイベント・センサーの説明は適用されず、適用される場所はありません。
-
フェーズ・センサーの説明がJFRイベント・タイプに適用されます。
動的に導出されたプロデューサおよびイベントの例
表5-13は、「動的に導出されたJFRイベント・タイプ - 名前、値および説明」で説明されているルールの例を示しています。
表5-13 動的に導出されたプロデューサおよびイベントの例
| DMS | Javaフライト・レコーダ(JFR) |
|---|---|
|
ナウン・タイプ:
ナウン・パス:
センサー:
説明:
|
プロデューサ名: JDBC プロデューサ名は、ナウン・パスの先頭のコンポーネントに基づいています。 イベント・タイプ1 イベント・タイプ名:
イベント・タイプ・パス:
フィールド:
|
|
- |
プロデューサ名: JDBC イベント・タイプ2 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
|
- |
プロデューサ名: JDBC イベント・タイプ3 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
|
- |
プロデューサ名: JDBC
イベント・タイプ4 イベント・タイプ名: イベント・タイプ・パス:
フィールド:
|
ログ・メッセージのDMSイベント・フォーマットの理解
表5-14は、DMSイベントを構成するフィールドを示しています。フィールド要素は:で区切られますが、いくつかの例外があります。実際のイベント文字列のフィールドの位置を示すため、サンプルのイベントが用意されています。
表5-14 イベント・フォーマットの説明
| 適用可能なイベント | フィールド番号 | 名前 | 説明 |
|---|---|---|---|
|
すべて |
1 |
バージョン番号 |
イベント形式のバージョン番号 たとえば:
|
|
すべて |
2 |
イベント時間 |
イベントが発生した時間 たとえば:
|
|
すべて |
3 |
ソース・オブジェクト・タイプ |
次の項目を含むイベントを生成するためにアクションが実行されたオブジェクトのタイプ
たとえば:
|
|
すべて |
4 |
アクション・タイプ |
このイベントを生成したアクションのタイプ。特定のソース・オブジェクト・タイプは、次の各アクション・タイプのイベントを生成しない場合があります。
たとえば: v1 |
|
ナウン |
5 |
ナウン・タイプ |
ナウン・タイプの名前 たとえば:
|
|
6 |
ナウン・パス |
センサーが属するナウンを識別するフルパス たとえば:
|
|
|
すべてのセンサー・タイプ |
5 |
ナウン・タイプ |
このセンサーが属するナウン・タイプの名前 たとえば: v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086 |
|
6 |
センサー名 |
センサーの名前 たとえば:
|
|
|
7 |
ナウン・パス |
センサーが属するナウンを識別するフルパス たとえば:
|
|
|
フェーズ・センサー・タイプ |
8 |
開始トークン |
フェーズの開始トークン。 たとえば:
|
|
9 |
停止トークン |
フェーズの終了トークン。 たとえば:
|
|
|
状態センサー・タイプ |
8 |
状態値タイプ |
次の項目を含む状態センサーで保持される値のタイプ
たとえば:
|
|
9 |
状態値 |
文字列形式で表される状態の値。 たとえば:
|
|
|
リクエスト |
5 |
URI |
Uniform Resource Identifier (URI)は、リクエストを適用するリソースを識別します。 たとえば:
|
|
実行コンテキスト |
5 |
ECID、RID |
カンマで区切られたECIDおよびRIDで構成されるコンテキスト識別子。 実行コンテキスト・イベントでは、4番目のイベント・フィールド・セパレータ(:)の後の最初の文字から始まる完全な部分文字列にECIDおよびRID識別子を記録します。コンテキスト識別子に:が含まれる可能性があるので、イベント・フィールド・セパレータとして解釈しないようにしてください。 たとえば:
|
親トピック: DMSトレースおよびイベント
DMSイベント・アクションの理解
表5-15は、ソース・オブジェクト・タイプで実行できるアクション・タイプを示しています。
表5-15 ソース・オブジェクト・タイプで実行されるアクション
| オブジェクト・タイプ | 作成 | 更新 | 削除 | 開始 | 停止 | 中断 |
|---|---|---|---|---|---|---|
|
ナウン |
はい |
- |
はい |
- |
- |
- |
|
イベント・センサー |
はい |
はい |
はい |
- |
- |
- |
|
フェーズ・センサー |
はい |
- |
はい |
はい |
はい |
はい |
|
状態センサー |
はい |
はい |
はい |
- |
- |
- |
|
実行コンテキスト |
- |
- |
- |
はい |
はい |
- |
|
リクエスト |
- |
- |
- |
はい |
はい |
- |
親トピック: DMSトレースおよびイベント
DMSのベスト・プラクティス
DMSメトリックを使用する際には、次のベスト・プラクティスを実施します。
DMSメトリックを使用すると、アプリケーションのパフォーマンスに影響を与える可能性があります。メトリックを追加する場合、次の内容を検討してください。
-
高分解能クロックを使用したDMSの精度の向上
デフォルトでは、DMSは
PhaseEvent中に時間間隔を測定する際、システム・クロックを使用します。デフォルト・クロックのレポート精度は、ApacheなどのCプロセスではマイクロ秒、Javaプロセスではミリ秒です。パフォーマンス測定の精度向上のために、DMSはオプションで高分解能クロックをサポートしており、時間間隔をレポートする際の値をユーザーが選択できます。デフォルト・クロックを使用する場合よりも正確にPhaseEventの時間を測定する場合、またはシステムのデフォルト・クロックが分解能の要件に満たない場合は、高分解能クロックを使用します。システム・クロックは、必ずしも精度が示すほど正確である必要はありません。たとえば、ミリ秒で時間を報告するシステム・クロックは、ミリ秒単位で動作(変化)しない場合があります。かわりに、次の例のように最大15ミリ秒要する場合があります。
表5-16 デフォルトのシステム・クロック時間と実際の時間(ミリ秒)
実際の時間 システム時間 12:00:00.000
12:00:00.000
12:00:00.001
12:00:00.000
12:00:00.002
12:00:00.000
[...]
12:00:00.014
12:00:00.000
12:00:00.015
12:00:00.015
12:00:00.016
12:00:00.015
表5-16は、実際の時間12:00:00.002から12:00:00.014に実行される12ミリ秒の期間のフェーズがゼロのシステム時間で計算されることを示しています。同様に、12:00:00.014から12:00:00.016に実行される2ミリ秒の期間のフェーズは、15ミリ秒の期間のシステム時間で報告されます。
ノート:
これらの動作は、一部のオペレーティング・システムでより明白になります。システム・クロックの動作期間より短い個々の期間の分析に注意してください。DMSを構成して高分解能クロックを使用すると、DMSに高分解能のフェーズ・センサーのアクティブ化が記録されますが、正確性は基盤システムによって制限されます。
-
Javaの時間を報告するDMSクロックの構成
高分解能クロックを選択すると、クロックを変更したサーバーで実行されているすべてのアプリケーションに対してクロックが変更されます。プロセスの起動オプションを制御する
oracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを使用して、DMSクロックおよびレポートの値をグローバルに設定します。たとえば、デフォルトの値で高分解能クロックを使用するには、Javaコマンド行で次のプロパティを設定します。
-Doracle.dms.clock=highres
注意:
高分解能クロックを使用する場合、デフォルトの値はFusion Middleware Controlが予期している値(ミリ秒)と異なります。高分解能クロックを使用しているときに、Fusion Middleware Controlを正しく表示する必要がある場合は、単位のプロパティを次のように設定します。
-Doracle.dms.clock.units=msecs
表5-17に、
oracle.dms.clockプロパティでサポートされる値を示します。表5-17 oracle.dms.clockプロパティの値
値 説明 DEFAULTDMSがデフォルト・クロックを使用することを指定します。デフォルト・クロックの場合、DMSはJavaコール
java.lang.System.currentTimeMillisを使用してPhaseEventの時間を取得します。デフォルト・クロックの単位のデフォルト値は、
MSECSです。HIGHRESJava Highresクロックは
System.nanoTime()を使用します(JNIは不要です)。表5-18に、
oracle.dms.unitsプロパティでサポートされる値を示します。表5-18 oracle.dms.clock.unitsプロパティの値
値 説明 MSECS時間がミリ秒に変換され、msecsとしてレポートされる必要あることを指定します。ミリ秒は10-3秒です。
ノート: これはデフォルト・クロックのデフォルト値です。
USECS時間がマイクロ秒に変換され、
usecsとしてレポートされる必要があることを指定します。マイクロ秒は10-6秒です。NSECS時間がナノ秒に変換され、
nsecsとしてレポートされる必要があることを指定します。ナノ秒は10-9秒です。ノート: これは高分解能クロックのデフォルト値です。
高分解能のDMSクロックを使用するときは、次の点に注意してください。
-
oracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを設定する際には、大文字と小文字を自由に組み合せて、選択した値を指定することができます(大/小文字の区別はありません)。たとえば、高分解能クロックを選択する場合、highres、HIGHRES、HighResのどれも有効です。 -
DMSは、起動時にプロパティ値をチェックします。表5-17に示されていない値でクロック・プロパティを設定すると、デフォルト・クロックが使用されます。
oracle.dms.clockプロパティを設定していない場合も、デフォルト・クロックが使用されます。 -
クロック単位のプロパティが表5-18に示されていない値に設定されている場合、指定したクロックのデフォルトの単位が使用されます。
-