| Oracle® Fusion Middleware Oracle Fusion Middlewareの管理 12c (12.2.1.2) E82709-01 |
|
 前 |
 次 |
トピック:
Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが組み込まれています。特に対象としている問題は、コードのbug、メタデータの破損、顧客データの破損、スレッドのデッドロック、一貫性のない状態に起因する障害などのクリティカル・エラーです。
クリティカル・エラーが発生すると、診断フレームワークにより、そのエラーにインシデント番号が割り当てられ、エラーの診断データ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。
診断フレームワークの目標は、次のとおりです。
初期障害の診断
問題が検出された後の損害および中断の抑制
問題の診断時間の短縮
問題の解決時間の短縮
顧客とOracleサポートのやり取りの簡略化
診断フレームワークに組み込まれているテクノロジは次のとおりです。
初期障害時の診断データの自動取得: クリティカルなエラーの場合、初期障害の段階でエラー情報を取得できると、問題が早期に解決され停止時間が短縮される可能性が大幅に増加します。診断フレームワークでは、スレッド・ダンプ、DMSメトリック・ダンプ、WebLogic診断フレームワーク(WLDF)のサーバー・イメージ・ダンプなどの診断情報を自動的に収集します。このような診断データは、飛行機のフライト・レコーダ「ブラック・ボックス」で収集されるデータに似ています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。データはファイルベース・リポジトリに格納され、コマンド行ユーティリティでアクセスできます。
標準化されたログ形式: Oracle Fusion Middlewareの全コンポーネントで(ODLログ・ファイル形式を使用して)ログ形式が標準化されていると、管理者およびOracleサポートのスタッフが、問題を分析するためのツールの単一セットを使用できます。問題の診断はさらに容易となり、停止時間は短縮されます。
診断ルール: それぞれのコンポーネントでは、特定のログ・メッセージによりインシデントを作成するかどうか、およびどのダンプを実行するかを評価する際に使用する診断ルールを定義します。診断ルールでは、個々のダンプの作成を同期で行うか非同期で行うかということも示します。
また、ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム・ルールを定義できます。
インシデント検出ログ・フィルタ: インシデント検出ログ・フィルタには、java.util.loggingフィルタが実装されています。これにより、それぞれのログ・メッセージを検証し、コンポーネントおよびアプリケーションの診断ルールに基づいて、インシデントを作成するかどうかを判断します。
インシデント・パッケージ化サービス(IPS)およびインシデント・パッケージ: IPSを使用すると、対応するインシデントのあるクリティカル・エラーに関する診断データ(ログ・ファイル、ダンプ、レポートなど)を自動的かつ容易に収集し、それらのデータをzipファイルにパッケージ化してOracleサポートに転送できます。診断フレームワークで検出されたクリティカル・エラーに関連する診断データはすべて、インシデントとして取得され、ADRに格納されます。インシデント・パッケージ化サービスでは、必要なファイルを自動的に特定してzipファイルに追加します。
zipファイルを作成する前に、IPSはまず、インシデント・パッケージという中間論理構造に診断データを収集します。パッケージは自動診断リポジトリに格納されます。必要に応じて、この中間論理構造にアクセスして、その内容を表示および修正したり、詳細な診断データをいつでも追加または削除できます。さらに、準備ができたらパッケージからzipファイルを作成し、Oracleサポートにアップロードできます。
WebLogic診断フレームワーク(WLDF)との統合: Oracle Fusion Middleware診断フレームワークでは、クリティカル・エラー検出時にWebLogic Serverのイメージを取得するなど、WebLogic診断フレームワーク(WLDF)の一部の機能と統合しています。WLDFは、モニタリングと診断を行うフレームワークであり、WebLogic Serverプロセス内で稼働してサーバーの標準的なライフサイクルの一部となる一連のサービスを定義および実装します。WLDFを使用して、稼働中のサーバー、およびコンテナ内にデプロイされたアプリケーションで生成された診断データを作成、収集、分析、アーカイブし、そのデータにアクセスできます。このデータにより、サーバーおよびアプリケーションの実行時のパフォーマンスに関する指標が提供され、障害発生時に失敗を隔離して診断することができます。
Oracle Fusion Middleware診断フレームワークは、次のようなWLDFのコンポーネントと統合しています。
WLDFポリシーおよびアクション。指定された条件の特定のログおよびメトリックを監視し、条件が満たされると通知を送信します。通知には、JMX通知や診断イメージを作成する通知など、いくつかの種類があります。Oracle Fusion Middleware診断フレームワークは、WLDFポリシーおよびアクション・コンポーネントと統合してインシデントを作成します。
診断イメージ・キャプチャ。問題の診断に使用される、サーバーの主要な状態の最も一般的なソースを収集します。これは、その状態を単一のアーティファクト、診断イメージにパッケージ化します。Oracle Fusion Middleware診断フレームワークにより、アーティファクトはADRに書き込まれます。
WLDFの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用』のWebLogic診断フレームワークとはに関する項を参照してください。
クリティカル・エラーを円滑に診断および解決するために、診断フレームワークには、問題とインシデントという、Oracle Fusion Middlewareの2つの概念が導入されています。
問題とは、クリティカル・エラーです。クリティカル・エラーは、内部エラーなどのサーバー・エラーとして発生します。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(XXX-nnnnnという形式)と、場合によってはエラー固有の他の値が含まれます。
インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。それぞれのインシデントは数字のインシデントIDで識別されます。このインシデントIDは、ADRホーム内で一意です。インシデントが発生すると、診断フレームワークでは次の処理を実行します。
インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。
そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。
インシデント・ダンプをインシデントとともにADRに登録します。
問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。そのため、診断フレームワークでは、特定のしきい値に達したときにインシデントの生成に対してフラッド制御を適用します。フラッド制御インシデントは、ADRに記録されないインシデントです。かわりに、診断フレームワークによって、WARNINGレベルのメッセージがログ・ファイルに書き込まれ、oracle.dfw.incident.Incidentオブジェクトが返されます。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。
デフォルトでは、問題キーが同じインシデントが60分以内に6件以上発生すると、それ以降、問題キーが同じインシデントはフラッド制御されます。この値は、MBeanを使用して変更できます(「診断フレームワークの構成」を参照)。
次の各項目で、診断フレームワークの主要コンポーネントについて説明します。
注意:
診断フレームワーク、特に自動診断リポジトリを使用するには、管理対象サーバーにOracle JRFが適用されている必要があります。Oracle JRFが適用されていれば、各管理対象サーバーに対して次のディレクトリが存在します。
DOMAIN_HOME/SERVERS/server_name/adr
ディレクトリが存在しない場合は、次のいずれかの手順を実行します。
「管理対象サーバーまたはクラスタへのOracle JRFテンプレートの適用」の説明に従って、Oracle JRFを適用します。
Oracle JRFが適用されている場合は、「管理対象サーバーを起動するためのノード・マネージャの構成」で説明しているように、ノード・マネージャのプロパティstartScriptEnabledがtrueに設定されていることを確認して、サーバーを再起動します。
自動診断リポジトリ(ADR)は、トレースやダンプなどのOracle Fusion Middleware診断データ用のファイルベースの階層リポジトリです。Oracle Fusion Middlewareのコンポーネントでは、インシデント・データはすべてADRに格納されます。それぞれのOracle WebLogic Serverでは、ADR内の自身のホーム・ディレクトリのサブディレクトリに診断データが格納されます。たとえば、それぞれの管理対象サーバーおよび管理サーバーにはADRホーム・ディレクトリがあります。
ADRのルート・ディレクトリは、ADRベースと呼ばれています。デフォルトでは、ADRベースは次のディレクトリにあります。
DOMAIN_HOME/servers/server_name/adr
ADRベースの中に複数のADRホームが存在できますが、その場合、それぞれのADRホームは、Oracle WebLogic Serverの特定のインスタンスに対し、すべてのインシデント・データのルート・ディレクトリになります。次のパスは、ADRホームの場所を示します。
ADR_BASE/diag/ofm/domain_name/server_name
図13-1は、Oracle WebLogic ServerインスタンスのADRホームのディレクトリ階層を示しています。
ADRホームのサブディレクトリには、次の情報が含まれています。
alert: XML形式のアラート・ログ。
incident: 複数のサブディレクトリを格納できるディレクトリ。それぞれのサブディレクトリには、当該のインシデントの名前が付けられます。サブディレクトリの名前はincdir_nで、このnはインシデントの番号を表しています。それぞれのサブディレクトリには、そのインシデントのみに関する情報および診断ダンプが格納されます。
(others): ADRホームのその他のサブディレクトリ。インシデント・パッケージなどの情報が格納されます。
注意:
ADRでは、インシデントをパッケージ化する際に、製品IDとしてドメイン名を使用し、インスタンスIDとしてサーバー名を使用します。ただし、いずれかの名前が30文字を超える場合は、ADRは名前の一部を切り捨てます。また、ドル記号($)と空白文字はアンダースコアに置き換えられます。
診断ダンプは、特定の診断情報を取得およびダンプします。この処理は、インシデントが作成された時点では自動で、管理者が要求した時点では手動で行われます。インシデント作成の一環として実行される場合、ダンプは一連のインシデント診断データに含まれます。診断ダンプには、JVMスレッド・ダンプ、JVMクラス・ヒストグラム・ダンプ、DMSメトリック・ダンプなどがあります。診断ダンプのリストについては、表13-7を参照してください。
診断フレームワークには、診断フレームワークの構成に使用できるMBeanが用意されています。たとえば、フラッド制御を有効化または無効化したり、指定された期間内に問題キーが同じインシデントが何回発生できるかを構成できます。管理MBeanを使用して診断フレームワークを構成する方法の詳細は、「診断フレームワークの構成」を参照してください。
また、MBeanを使用すると、インシデントの問合せおよび作成を行ったり、使用可能な診断ダンプ・タイプのリストを検索したり、個々の診断ダンプを実行することができます。
診断フレームワークには、問題およびインシデントに関する情報の表示、インシデントの作成、特定のダンプの実行および一連の診断ダンプ・タイプの問合せに使用できるWLSTコマンドが用意されています。詳細は、次を参照してください。
『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』の「診断フレームワークのカスタムWLSTコマンド」
ADRコマンド・インタプリタ(ADRCI)は、問題を調査し、初期障害診断データをパッケージ化してOracleサポートにアップロードするという処理を、コマンド行環境ですべて実行できるユーティリティです。またADRCIを使用して、ADR内のダンプ・ファイルの名前を表示したり、コンテンツ・フィルタを指定して(または未指定で)XMLタグが取り除かれた状態でアラート・ログを表示することもできます。
ADRCIは次のディレクトリにインストールされています。
(UNIX) ORACLE_HOME/oracle_common/adr (Windows) ORACLE_HOME\oracle_common\adr
ADRCIコマンド行ユーティリティの使用の詳細は、次の各項を参照してください。
インシデントのパッケージ化の詳細は、「インシデントのパッケージ化」を参照してください。
インシデントのパージの詳細は、「インシデントのパージ」を参照してください。
関連項目:
『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」
『Oracle Database管理者ガイド』の「診断データの管理」
診断フレームワークは、それぞれのサーバーでアクティブであり、構成された事前定義のルールに基づいてエラーを自動的に検出します。Oracle Fusion Middlewareのコンポーネントおよびアプリケーションは、常に監視対象となるため、自動的に診断フレームワークの恩恵を受けることになります。
インシデントは、次の2つの方法で自動的に検出されます。
インシデント検出ログ・フィルタ。クリティカル・エラーを検出するように自動的に構成されます。
WLDFポリシーおよびアクション・コンポーネント。診断フレームワークでは、事前定義された通知タイプをリスニングし、そのような通知を受信したときにインシデントを作成します。
WLDFポリシーおよびアクションの構成の詳細は、「診断フレームワーク用のWLDFポリシーおよびアクションの構成」を参照してください。
プログラムによるインシデント作成。一部のコンポーネントでは、インシデントを直接作成します。
図13-2は、インシデント・ログ検出でインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント・ログ検出でインシデントが検出されたときの、インシデント・ログ検出、WLDF診断イメージMBean、ADR、およびコンポーネントまたはアプリケーションのダンプの間のやり取りを示しています。
図13-2で示されている手順は、次のとおりです。
インシデント検出ログ・フィルタは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。
アプリケーションまたはコンポーネントは、java.util.logging APIを使用して、メッセージをログに記録します。
ODLログ・ハンドラは、メッセージをインシデント検出ログ・フィルタに渡します。
インシデント・ログ検出フィルタは、ログ・メッセージを検証し、コンポーネントの診断ルールに基づいて、インシデントを作成するかどうかを判断します。診断ルールによりインシデントを作成する必要があると示された場合、ADRにインシデントが作成されます。
ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をアプリケーションに戻します。
インシデントが作成されると、次のようなメッセージがログ・ファイルに書き込まれます。
[2015-03-28T11:05:34.603-07:00] [wls_server_1] [NOTIFICATION] [DFW-40101] [oracle.dfw.incident] [tid: [ACTIVE].ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-000e093f,0] An incident has been signalled with the incident facts: [problemKey=MDS-50500 [MANUAL] incidentSource=MANUAL incidentTime=Fri March 28 11:05:34 PDT 2015 errorMessage=MDS-50500 executionContextId=null]
診断フレームワークは、コンポーネントの診断ルールで示される診断ダンプを実行します。
診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。
診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。
WLDFは、ADRに診断イメージを書き込みます。
図13-3は、WLDFポリシーおよびアクション・システムでインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント通知リスナー、WLDFポリシーおよびアクション・システム、WLDF診断イメージMBeanの間の情報のやり取りを示しています。
図13-3で示されている手順は、次のとおりです。
インシデント通知リスナーは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。
Oracle Fusion Middleware診断フレームワークは、WLDFにJMX通知リスナーを登録します。リスナーは、WLDFポリシーおよびアクション・システムからのイベントをリスニングします。ここで処理される通知は、oracle.dfw.wldfnotificationタイプのみです。
システム内のなんらかが原因となって、構成されたWLDFポリシーがトリガーされ、インシデント通知リスナーに通知が送信されます。通知には、ポリシーをトリガーする原因となったデータについて記述したイベント情報が含まれます。
診断フレームワークにより、ADRにインシデントが作成されます。
診断フレームワークは、診断ルールで示される診断ダンプを実行します。
診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。
診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。
WLDFは、ADRに診断イメージを書き込みます。
カスタム診断ルールや問題抑制など、診断フレームワークの一部の設定を構成できます。また、WLDFポリシーおよびアクションを構成してインシデントを作成することもできます。
次の各項目で、診断フレームワークを構成する方法を説明します。
次の設定を構成できます。
ログ・ファイルを使用したインシデントの検出の有効化または無効化
フラッド制御およびフラッド制御のパラメータ設定の有効化または無効化
これらの設定を構成するには、診断フレームワークMBean DiagnosticConfigを使用します。次に、MBeanのObjectNameを示します。
oracle.dfw:type=oracle.dfw.jmx.DiagnosticsConfigMBean,name=DiagnosticsConfig
表13-1は、DiagnosticConfig MBeanの属性と各パラメータの説明を示しています。
表13-1 診断フレームワークのDiagnosticConfig MBeanの属性
| 属性 | 説明 |
|---|---|
DumpSamplingIdleWhenHealthy |
システムが健全な場合にダンプ・サンプリングを有効にするかどうかを決定します。デフォルトで、これはtrueに設定されています(インシデントが発生するまで、ダンプ・サンプリングは有効ではありません)。 |
DumpSamplingMinimumHealthyPeriod |
インシデントが発生した後、ダンプ・サンプリングが有効になるまでの時間(秒数)。デフォルトは259200秒(72時間)です。 |
floodControlEnabled |
フラッド制御を有効化または無効化します。有効化する場合は フラッド制御は、手動で作成されたインシデントには適用されません。 |
floodControlIncidentCount |
フラッド制御で制御されるまでに、floodControlIncidentTimeoutPeriodで指定された期間内に作成できる、問題キーが同じインシデントの数を設定します。デフォルトは5です。 フラッド制御が有効になっていて、同じ問題キーのインシデントの数がこのカウントを超えると、インシデントが作成されなくなります。ただし、診断フレームワークは、WARNINGレベルのメッセージをログ・ファイルに書き込みます。 |
floodControlIncidentTimeoutPeriod |
フラッド制御で制御されるまでに、floodControlIncidentCountで指定された数の、問題キーが同じインシデントを作成できる期間を設定します。デフォルトは60分です。 |
incidentCreationEnabled |
インシデント作成を有効化または無効化します。有効化する場合は |
logDetectionEnabled |
ログ・ファイルを使用したインシデントの検出を有効化または無効化します。有効化する場合は |
maxTotalIncidentSize |
すべてのインシデントに割り当てられる最大合計サイズを設定します。この制限に達すると、すべてのインシデントで使用される領域がこのパラメータで指定される量より小さくなるまで、最も古いインシデントから順にパージされます。 デフォルトは500MBです。インシデントの作成時にこの制限を超えた場合は、インシデントの作成が完了したときに、最も古いインシデントからパージされていきます。 |
reservedMemoryKB |
OutOfMemoryErrorが検出されたときに解放される予約済メモリーの量。 診断フレームワークの起動時に、プライベートで使用されるメモリーが512 KB割り当てられます。診断フレームワークにより、サーバーにOutOfMemoryErrorが発生したことが検出されると、そのメモリーのブロックを解放して、インシデントの作成に進みます。 デフォルトは512KBです。 |
uncaughtExceptionDetectionEnabled |
Javaベースの捕えられていない例外ハンドラを有効にします。これが有効のときに捕えられていない例外が検出されると、インシデントが作成されます。有効化する場合は デフォルトは |
useExternalCommands |
スレッド・ダンプの実行に外部JVMコマンドを使用するかどうかを示します。有効化する場合は |
次の例は、Fusion Middleware ControlシステムMBeanブラウザを使用してこれらの設定を構成する方法を示しています。
次に、「システムMBeanブラウザ」ページを示します。
ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム診断ルールを構成できます。
カスタム診断ルールは、特定の形式の.xmlファイル(この項の後半の例を参照)を作成することにより作成します。ファイルは次のいずれかの場所に保存する必要があります。
ドメイン全体に適用されるルールの場合
DOMAIN_HOME/config/fmwconfig/dfw
特定のサーバーに適用されるルールの場合
DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw
ファイル名には次の形式を使用する必要があります。
name.xml appname#name.xml
この形式では、appnameは、ルールが適用されるアプリケーションの名前です。appnameは、デプロイされたアプリケーションの正確な名前である必要があります。nameは、指定するルールの名前です。appnameを指定しないと、ルールはサーバー全体に適用されます。たとえば、次のルールはmyAppアプリケーションに適用されます。
myApp#custom_rule.xml
カスタム診断ルール・ファイルには、ルールを定義するために次のような要素を含めることができます。
ログ検出条件(オプション)
ルールが登録されているサーバーまたは指定されたアプリケーションに適用される診断ログ内でチェックする条件のセットを、logDetectionConditions要素内に定義できます。条件に一致するログ・メッセージが検出されると、インシデントが作成され、問題の特定に役立つ診断情報が取得されます。デフォルトでは、すべてのINCIDENT_ERRORメッセージが検出され、それらに対してインシデントが作成されます。また、特定のコンポーネントに対して、特定のメッセージを検出するルールを構成することもできます。
次の例は、4つのログ検出条件を定義するカスタム診断ルール・ファイルの一部を示しています。1つ以上の条件がtrueの場合、インシデントが作成されます。
<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
<logDetectionConditions>
<condition messageSeverity="INCIDENT_ERROR"/>
<condition messageSeverity="ERROR" component="jrfServer_admin"/>
<condition messageSeverity="ERROR" module="test.servletA"/>
<condition messageId="FMW-40300"/>
</logDetectionConditions>
使用できる条件の説明は、表13-2を参照してください。
処理ルール
インシデントの作成にサーバー・ルールまたはアプリケーション・ルールが関わっている場合に評価される処理ルールを定義できます。たとえば、インシデントの作成にMyAppアプリケーションが関わっている場合、MyAppアプリケーションに関連付けられたすべてのルールが評価されます。どの場合にも、アプリケーションにかかわらず、サーバー全体に対するルールは常に評価されます。
処理ルールは次の2つの部分から構成されます。
デフォルト・アクション(オプション)。指定されている場合は、インシデントの作成中に常に実行されます。アクションとは、実行する診断ダンプとオプションの引数のリストです。
次に、デフォルト・アクション・セットの例を示します。
<defaultActions>
<dumpAction name="odl.logs">
<argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
</dumpAction>
<dumpAction name="dms.metrics"/>
</defaultActions>
使用できるオプションの引数の説明は、表13-3を参照してください。
条件ベースのアクション。これは、条件がtrueと評価された場合にのみ実行されます。各<rule>要素は、名前属性および子<ruleCondition>要素と子<ruleActions>要素から構成されます。<ruleActions>要素には、1つ以上のdumpAction要素が含まれます。<ruleCondition>要素属性のリストは、表13-4を参照してください。
1つの<rule>要素内に複数の<condition>要素が指定されている場合、すべての条件がtrueに評価される場合にのみdumpActionが実行されます。
次に、条件ベースのアクション・ルールの例を示します。MESSAGE_IDがDFW-99997の場合、条件がtrueと評価され、jvm.classhistogramダンプが実行されます。
<processingRules>
<rule name="OOME">
<ruleCondition>
<condition name="MESSAGE_ID" value="DFW-99997"/>
</ruleCondition>
<ruleActions>
<dumpAction name="jvm.classhistogram"/>
</ruleActions>
</rule>
</processingRules>
表13-2に、ログ検出条件を作成するために使用できる属性を示します。
表13-2 LogDetectionConditions要素の条件
| 条件 | 説明 |
|---|---|
messageSeverity |
メッセージが記録されたログ・レベル。(ODLログ・ファイル用のMESSAGE_LEVELフィールド。)例: INCIDENT_ERROR、ERROR |
messageId |
メッセージのID。(ODLログ・ファイル用のMESSAGE_IDフィールド。)例: DFW-99997。 |
component |
コンポーネント名。(ODLログ・ファイル用のCOMPONENT_IDフィールド。)例: |
module |
メッセージを生成したモジュールの名前。(ODLログ・ファイル用のMODULE_IDフィールド。) |
ODLログ・ファイル・フィールドの説明は、表12-1を参照してください。
表13-3に、<defaultActions>要素に対して使用できるオプションの引数を示します。
表13-3 defaultActions要素に対するオプションの引数
| 引数 | 説明 |
|---|---|
name |
引数の名前。 |
value |
引数の値。 |
type |
引数のタイプ。有効な値は、次のとおりです。
|
表13-4に、<ruleCondition>要素属性を示します。
表13-4 ruleCondition要素の属性
| 要素 | 説明 |
|---|---|
name |
属性の名前を指定します。有効な値はvalueTypeに依存します。
|
operator |
演算子。有効な値は、EQ、EQNoCase、NE、Contains、StartsWith、EndsWith、LT、GT、LE、GEです。デフォルトはEQです。 値では大/小文字が区別されます。 |
value |
比較するリテラル値。 |
datatype |
データ型。有効な値はStringまたはIntegerです。デフォルトはStringです。 値では大/小文字が区別されます。 |
valueType |
引数のタイプ。
|
カスタム診断ルールを作成してロードする手順は次のとおりです。
一定の状況では、特定の問題キーに基づいてインシデントの作成を抑制する必要がある場合があります。たとえば、開発環境で、サーブレットを開発しているときに、コードを調整すると捕えられていない例外が多数生成されることがあります。これにより、不要なインシデントが作成されます。
診断フレームワークによって、フィルタ条件と一致する問題でインシデントが作成されないように問題抑制フィルタを構成できます。
問題抑制フィルタを構成する場合は、マッチするパターンを表す正規表現を使用します。java.util.regexクラスを使用して、正規表現とのマッチが行われます。次に例を示します。
次の正規表現では、インシデントがMDS-5000で始まる問題キーとマッチされます。
MDS-5000.*
次の正規表現は、テキストOutOfMemoryを含む問題とマッチします。正規表現では大/小文字が区別されるため、テキストoutofmemoryを含む問題とはマッチしません。
.*OutOfMemory.*
DiagnosticConfig MBeanを使用すると、フィルタを追加および削除したり、フィルタ・リストまたは1つのフィルタの詳細を取得できます。
表13-5は、構成中の問題抑制フィルタの操作および属性とそれぞれの説明を示しています。
表13-5 問題抑制フィルタのDiagnosticConfig MBeanの操作および属性
| 操作および属性 | 説明 |
|---|---|
操作: addProblemKeyFilter(filter_pattern) |
新しい問題抑制フィルタを追加します。マッチするパターンを表す正規表現に渡します。次に例を示します。 addProblemKeyFilter(".*OutOfMemory.*)
|
属性: getProblemKeyFilters() |
構成済の問題抑制フィルタのリストを返します。次に例を示します。 getProblemKeyFilters() |
操作: getProblemKeyFilter(filterID) |
特定IDに関連するフィルタ・パターンを返します。次に例を示します。 getProblemKeyFilter(id)
IDを検索するには、getProblemKeyFilters()操作を使用します。 |
操作: removeProblemKeyFilter(filterID) |
任意のフィルタIDに関連するフィルタ・パターンを削除します。次に例を示します。 removeProblemKeyFilter(id)
|
問題抑制フィルタを構成する手順は次のとおりです。
removeProblemKeyFilter操作を使用すると、フィルタを削除できます。
getProblemKeyFilter操作にフィルタIDを渡すと、特定のフィルタを取得できます。
また、次のようにgetProblemKeyFilters属性を使用すると、フィルタのリストを取得できます。
Oracle Fusion Middlewareでは、特定の一連のクリティカル・エラーを検出し、そのようなエラーが発生するたびにインシデントを作成するための一連のポリシーおよびアクションのルール(以前はウォッチおよび通知のルールと呼ばれていました)が含まれているWLDF診断モジュールを構成します。そのようなポリシーを構成してインシデントを作成できます。
WLDF診断モジュールはModule-FMWDFWと呼ばれ、次の一連のポリシー条件が含まれます。
| 名前 | 説明 |
|---|---|
Deadlock |
複数のJavaスレッドで、Java Monitorオブジェクトを使用する際に循環ロック・チェーンがあります。 |
StuckThread |
Oracle WebLogic ServerのExecuteThread。Oracle WebLogic ServerのStuckThreadMaxTimeパラメータで指定された時間より長い期間、ブロックされているかビジー状態です。 |
UncheckedException |
このカテゴリには、未チェックの例外、RuntimeException、およびNullPointerException、StackOverflowError、OutOfMemoryErrorなどのOracle WebLogic ServerのExecuteThreadで捕捉されたエラーがすべて含まれます。 |
診断モジュールには、oracle.dfw.wldfnotificationタイプの、構成されたWLDF JMX通知FMWDFW-notificationも含まれます。このWLDF JMX通知は、インシデントを作成するために、独自のWLDFポリシー条件で再利用することもできます。
「Oracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイド」の説明に従って、Fusion Middleware Controlを表示します。
「WebLogicドメイン」メニューから、「診断」を展開し、「診断モジュール」を選択します。
「診断モジュール」ページが表示されます。
「Module-FMWDFW」をクリックします。
「Module-FMWDFWの設定」ページが表示されます。
「構成」タブ、「ポリシーとアクション」タブの順に選択します。次の図は、「ポリシー」セクションを示しています。
「ポリシー」タブを選択し、「作成」をクリックします。
「診断ポリシーの作成」ページが表示されます。
「ポリシー名」にポリシーの名前を入力します。
任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージIDが使用されるようにすることができます。
message-id#[application_name]#any_text
メッセージIDは、1から6文字の接頭辞と1から6桁の数字で構成されます。アプリケーション名はオプションです。次に例を示します。
WLS-40500#My_Policy_Name
次の例では、アプリケーション名testappを使用します。
WLS-40501#testapp#My_Policy_Name
診断フレームワークでは、インシデント問題キーの構成時にメッセージIDをインシデント・メッセージIDとして使用します。
「ルール・タイプ」で、「サーバー・ログ」や「スマート・ルール」などの基になるタイプを選択します。これは、「クラスタ平均スループット(下限)」などの事前構成済ルールです。
「次へ」をクリックします。
次のページは、ポリシーのタイプによって異なります。
スマート・ルール:
ルールを選択して「次へ」をクリックします。
パラメータ値を入力して「次へ」をクリックします。
「開始時間」で、「時」、「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。
「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。
「頻度」に値を入力します。たとえば5と入力します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
カレンダ・ベース:
「開始時間」で、「時」、「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。
「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。
「頻度」に値を入力します。たとえば5と入力します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。
動的クラスタがある場合、「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
収集対象メトリック:
「スマート・ルール」または「式」を選択します。「次へ」をクリックします。
「スマート・ルール」を選択した場合は、パラメータの値を指定します。
「式」を選択した場合は、式を入力します。
「次へ」をクリックします。
「開始時間」で、「時」、「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。
「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。
「頻度」に値を入力します。たとえば5と入力します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
サーバー・ログ:
ポリシーのルールを作成するための式を追加します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成します。次に、「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
動的クラスタがある場合、「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
ドメイン・ログ:
ポリシーのルールを作成するための式を追加します。次に、「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
動的クラスタがある場合、「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
イベント・データ:
ポリシーのルールを作成するための式を追加します。次に、「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
動的クラスタがある場合、「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。
「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。
「作成」をクリックします。
ポリシーの作成の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュール用のポリシーの作成に関する項を参照してください。
WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent (RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決できます。
初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。
一般的に、問題の調査、報告および解決は、クリティカル・エラーの発生から始まります。この項では、そのワークフローの概要について説明します。
図13-4は、問題を調査、報告および解決するためのタスクを示しています。
次に、図13-4に示しているワークフローについて説明します。
システム、コンポーネントまたはアプリケーションが想定どおりに機能していないことがわかります。たとえば、パフォーマンスに問題があることがわかったり、アクセスしようとしているアプリケーションでエラーが報告されているとユーザーから報告があった場合などです。
観察された症状に関連する可能性のある問題およびインシデントが作成されているかどうかを確認します。
一連の問題を確認するには、「問題の確認」の説明に従って、WLSTのlistProblemsコマンドを使用します。
問題が作成されている場合、「インシデントの確認」の説明に従って、listIncidentsコマンドを使用して、特定の問題に関連するインシデントを一覧表示します。
問題に関連しているインシデントを確認できない場合は、createIncidentコマンドを使用してインシデントを手動で作成し、問題の診断情報を取得することができます。
ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要がある場合は、インシデントを作成することを検討してください。ログ・ファイルとその中のメッセージを表示できます。直面している問題に関連すると思われるメッセージがあったら、createIncidentコマンドでそのメッセージIDを使用できます。
インシデントの作成の詳細は、「インシデントの手動作成」を参照してください。
特定のインシデントの詳細を確認するには、「インシデントの確認」の説明に従って、showIncidentコマンドを使用します。このコマンドを実行すると、関連するメッセージID、インシデントの時刻、ECID、インシデントで生成されたファイルなど、インシデントに関する情報が一覧表示されます。
「インシデントの確認」の説明に従って、getIncidentFileコマンドを使用して、インシデントのファイルの内容を確認します。その内容には、問題の原因を導き出し、その解決に役立つ情報が含まれる可能性があります。
インシデントのファイルの内容が問題の解決に役立たなかった場合、追加のダンプを実行して詳細な診断情報を確認できます。たとえば、パフォーマンスの問題に直面した場合は、dms.metricsダンプを実行します。使用可能なダンプおよびその実行方法の詳細は、「診断ダンプの処理」を参照してください。
それでも問題が解決できない場合は、RDAレポートとともにインシデントをパッケージ化して、Oracleサポートにお送りください。インシデントのパッケージ化およびRDAレポートの生成の詳細は、「インシデントのパッケージ化」および「RDAレポートの生成」を参照してください。
次の各項で説明するように、WLSTコマンド行ユーティリティを使用して、一連の問題、インシデントのリスト、および特定のインシデントの詳細を確認できます。
一連の問題を確認するには、次の形式でWLSTのlistProblemsコマンドを実行します。
listProblems([adrHome] [,server])
listProblemsコマンドを実行すると、ADRホームの問題が一覧表示されます。それぞれの問題では、IDが一意です。
listProblems()
Problem Id Problem Key
1 BEA-101020 [HTTP]
次の形式でWLSTのlistIncidentsコマンドを実行して、すべての使用可能なインシデントまたは特定の問題に関連するインシデントをリストできます。
listIncidents([id], [ADRHome])
たとえば、すべてのインシデントのリストを表示するには、次のコマンドを使用します。
listIncidents()
Incident Id Incident Time Problem Key
2 Fri Mar 28 11:05:59 PDT 2015 MDS-50500 [MANUAL]
1 Fri Mar 28 11:02:22 PDT 2015 MDS-50500 [MANUAL]
特定の問題に関連するインシデントを確認するには、次のコマンドを使用します。
listIncidents(id='1')
Incident Id Incident Time Problem Key
2 Fri Mar 28 11:05:59 PDT 2015 MDS-50500 [MANUAL]
1 Fri Mar 28 11:02:22 PDT 2015 MDS-50500 [MANUAL]
特定のインシデントの詳細を確認するには、次の形式でWLSTのshowIncidentコマンドを使用します。
showIncident(id, [adrHome] [,server])
たとえば、インシデント1の詳細を確認するには、次のコマンドを使用します。
showIncident(id='1') Incident Id: 1 Problem Id: 1 Problem Key: MDS-50500 [MANUAL] Incident Time:Fri Mar 28 11:02:22 PDT 2015 Error Message Id: MDS-50500 Execution Context: Flood Controlled: false Dump Files : readme.txt jvm_threads10_i1.txt dms_metrics11_i1.txt dfw_samplingArchive13_i1.JVMThreadDump.txt dfw_samplingArchive13_i1.readme.txt odl_logs14_i1.txt
インシデントのファイルの内容を確認するには、次の形式でWLSTのgetIncidentFileコマンドを使用します。
getIncidentFile(id, name [,outputFile] [,adrHome] [,server])
たとえば、ファイルodl_logs4_i1.dmpの内容を確認するには、次のコマンドを使用します。
getIncidentFile(id='1', name='odl_logs14_i1.txt',outputFile='/tmp/odl_logs4_i1_dmp.output')
このコマンドは、出力をファイルodl_logs4_i1_dmp.outputに書き込みます。
listIncidentsコマンドでは特定の問題IDまたは特定のサーバーに関連するインシデントが表示されますが、リストをそれ以上絞り込むことはできません。WLSTのqueryIncidentsコマンドは、ドメイン内の1つ以上のサーバー、またはすべてのサーバーに渡って、特定の属性の値を問い合せることができます。たとえば、インシデント作成時やECIDで問い合されます。
式には、インシデント属性、演算子および文字列が次の書式で含まれます。
attribute operator "string"
問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。
次のインシデント属性がサポートされています。
TIMESTAMP: インシデント作成時間。fromおよびto演算子を使用して時間範囲を指定できます。日付書式はYYYY-MM-DD HH:MMです。
ECID: 実行コンテキストID
PROBLEM_KEY: 問題キー
MSG_FACILITY: エラー・メッセージ機能(ORA、OHSなど)
MSG_NUMBER: エラー・メッセージID (600など)
カスタム・インシデント属性もサポートされています。たとえば、TRACEID、APP、URIおよびDSIDがサポートされています。さらに、インシデントのreadme.txtファイルに示されるコンテキスト値がサポートされています。たとえば、DFW_APP_NAMEおよびDFW_USER_NAMEがサポートされています。
サポートされている演算子は次のとおりです。
equals
notEqual
startsWith
endsWith
contains
isNull
notNull
たとえば、ドメイン内のすべてのサーバーのすべてのインシデントに対して、ECID f19wAgN000001を問い合せることができます。
queryIncidents(query="ECID equals f19wAgN000001")
次の例では、2015年3月1日と2015年3月15日の間に発生したすべてのインシデントに対して、サーバーwls_server_1を問い合せています。
queryIncidents(query="TIMESTAMP from '2015-03-01 00:00'AND TIMESTAMP to '2015-03-15 00:00'", servers=["wls_server_1"])
このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のqueryIncidentsに関する項を参照してください。
診断フレームワークは、未処理の例外について明確に定義された一連の問題キーを提供します。これらの例外は、既存のWLDFポリシーのUncheckedException、または診断フレームワークのjava.lang.Thread.UncaughtExceptionHandlerハンドラのいずれかによって検出されます。これまで、診断フレームワークは、同一タイプの問題に様々な形式で問題キーを生成していました。表13-6は、これらの問題キーとそれらを使用して問題を調査する方法について説明しています。
表13-6 捕えられていない例外の問題キー
| 例外 | 問題キー | 説明 |
|---|---|---|
java.lang.OutOfMemoryError |
DFW-99997 [java.lang.OutOfMemoryError] |
すべてのjava.lang.OUtOfMemoryErrorインシデントで使用されます。このタイプの各インシデントによって、jvm.classhistogramダンプが実行されます。ダンプは、ロードされたクラスのインスタンスと関連オブジェクトの数に関する統計を取得します。 このダンプの内容を確認し、JVMメモリーに何がロードされたかを理解するための効率的な手がかりとなる情報を見つけてください。また、dms.metricsダンプは、全体的なJVMメモリーに関する統計を記録します。 |
java.sql.SQLException |
DFW-99996 [ora-code|java.sql.SQLException]][package.class.method][app-name] |
サブクラスを含むjava.sql.SQLExceptionタイプのすべての例外に使用されます。診断フレームワークは、例外エラー・メッセージからOracleエラー・コードの抽出を試み、成功した場合はそのコードを問題キーに使用します。失敗した場合は、例外名を使用します。 例外に関連するテキストを確認し、データベースで実行されなかった操作などの詳細を取得します。さらに、SQLエラー・コードの詳細で追加情報を確認できます。 |
その他すべて |
DFW-99998 [exception-name][package.class.name][app-name] |
固有の方法では処理されないその他すべての例外タイプ(java.lang.NullPointerException、java.io.IOException、java.lang.StringIndexOutOfBoundsExceptionなど)で使用されます。 例外に関連付けられたテキストを確認し、障害の理由などの詳細を取得します。問題キーのソース行で障害の場所が示されている可能性があります。 |
問題が疑われる場合、組込みの診断ダンプを利用して、問題の診断に役立つ詳細な診断結果を報告できます。診断ダンプは、Oracle Fusion Middlewareのコンポーネント、アプリケーションおよびインフラストラクチャに関する問題を診断する際に有益な情報として使用できる診断データを出力および記録する手段となります。これらのダンプからの出力は、Oracle Fusion Middlewareに関する問題を診断するために、顧客およびOracleサポートが使用することを想定しています。
診断ダンプは、次のように実行します。
手動。次の各項で説明するように、WLSTコマンドを使用します。
たとえば、Java EEアプリケーションがハングしてデッドロックが疑われる場合には、jvm.threadsダンプを使用して一連のスレッドを取得できます。
自動。診断フレームワークがクリティカル・エラーを検出してインシデントを作成した場合、または管理者がインシデントを作成した場合。
管理対象サーバーで使用可能な診断ダンプのリストを検索するには、次の形式でWLSTのlistDumpsコマンドを実行します。
listDumps([appName] [,server])
たとえば、wls_server1で使用可能なダンプを一覧表示するには、次のコマンドを使用します。
listDumps(server='wls_server1') Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. For more help, use help(domainRuntime) dfw.samplingArchive dms.configuration dms.ecidctx dms.metrics http.requests jvm.classhistogram jvm.threads mds.MDSInstancesDump odl.activeLogConfig odl.logs odl.quicktrace opss.diagTest opss.identityStoreUserRoleApiConfig opss.securityContext wls.image Use the command describeDump(name=<dumpName>) for help on a specific dump.
表13-7は、Oracle Fusion Middlewareで定義される診断ダンプ操作とその説明をまとめたものです。
表13-7 診断ダンプ操作
| ダンプ操作 | 説明 |
|---|---|
dms.ecidctx |
特定の実行コンテキストID (ECID)が指定されている場合は、それに関連付けられたデータ。そうでない場合は、使用可能なすべてのECIDに関連付けられたデータ。 |
dms.metrics |
ダイナミック・モニタリング・サービス(DMS)メトリック。これらのメトリックの詳細は、Oracle Fusion Middlewareパフォーマンスのチューニングのダイナミック・モニタリング・サービス(DMS)に関する項を参照してください。 |
http.requests |
現在アクティブなHTTPリクエストのサマリー。 |
jvm.classhistogram |
JVMクラス・ヒストグラム。その出力内容は、JVMベンダーによって異なります。 |
jvm.flightRecording |
アクティブなJRockitフライト・レコーダの記録。 |
jvm.threads |
JVMで実行中のスレッド、および完全なスレッド・ダンプを実行中のスレッドに関する統計サマリー。 |
mds.MDSInstancesDump |
現在のJVMの各MDSインスタンスに関する情報。 |
odl.activeLogConfig |
アクティブなJavaロギング構成。 |
odl.logs |
ECIDまたは時間範囲で関連付けられる診断ログの内容。 |
odl.quicktrace |
クイック・トレース・メッセージ。 |
wls.image |
WLDFサーバー・イメージ・ダンプ。 |
また、Oracle SOA Suiteでは、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「SOAコンポジット・アプリケーションを使用した問題の診断」で説明しているように、診断ダンプが提供されます。
WLSTのdescribeDumpコマンドを使用して、ダンプを実行する際の構文など、特定のダンプの説明を表示できます。目的のダンプの名前を指定します。たとえば、dms.metricsダンプの説明を表示するには、次のコマンドを使用します。
describeDump(name='dms.metrics')
Name: dms.metrics
Description: Dumps DMS (Dynamic Monitoring Service) metrics.
Run Mode: asynchronous
Mandatory Arguments:
Optional Arguments:
Name Type Description
dump STRING How much to dump
servers STRING Server names
names STRING Name of DMS noun or metric
format STRING Format of the dump output; raw or xml
nountypes STRING Type of DMS noun
問題を検出して追加の診断データを収集する場合、指定したダンプに対してexecuteDumpコマンドを起動します。それぞれのダンプには、必須またはオプション、あるいはその両方の引数があります。特定のダンプの引数やその指定方法を確認するには、「診断ダンプの説明の表示」の説明に従って、describeDumpコマンドを使用します。
次の例では、名前がdms.metricsでインシデントIDが1のダンプを実行し、それをファイルdumpout.txtに書き込んでいます。
executeDump(name='dms.metrics', outputFile='/tmp/dumpout.txt', id='1') Dump file dms_metrics1_i1.dmp added to incident 1
このコマンドは、ダンプ出力をインシデント1に関する情報に書き込みます。インシデント1に対してshowIncidentコマンドを実行すると、出力結果にはdms_metrics1_i1.dmpが含まれます。
診断ダンプ・サンプリングは、指定された間隔で診断ダンプの出力を取得します。定期的な間隔でサンプルを取得する診断ダンプ・サンプリングにより、低速なWebリクエストなどの問題や、これらのリクエストのどこで処理が実行されているなどを特定できます。
この項では、次の項目について説明します。
すべての診断ダンプ・サンプリングは、指定した間隔で、バックグラウンドで実行されます。デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプがサンプリング用に構成されています。ただし、インシデントが生成されるまでこれらはアクティブではありません。インシデントが生成されると、デフォルトで72時間、アクティブになります。
デフォルト・ダンプ・サンプリングに対する設定を変更し、また表13-7に示したダンプ操作およびアプリケーション固有のダンプに対して新しいサンプリング定義を作成できます。サンプリング間隔やサーバーなどについて異なる設定を指定して、同じ診断ダンプに対して複数のサンプリング定義を構成できます。
各診断ダンプ・サンプリングに対して、診断フレームワークにより、指定された数のサンプルが保存されます。上限に達すると、最も古いサンプルからパージされます。サーバーの停止時にはすべてのサンプルがパージされます。
表13-8に、デフォルトで構成されているダンプ・サンプリングの設定を示します。
表13-8 デフォルトの診断ダンプ・サンプリング構成
| ダンプ名 | サンプリング間隔 | 保存される最大サンプル数 |
|---|---|---|
jvm.threads |
60秒 |
10 |
jvm.classhistogram |
30分 |
5 |
診断フレームワークにより、インシデントが作成されるたびに(エラー検出またはインシデントの手動作成により)、ダンプ・サンプルの取得がトリガーされます。また、ダンプ・サンプルの内容を取得することもできます(「ダンプ・サンプリング出力の取得」を参照)。
ダンプ・サンプル・アーカイブは、テキストまたはzipファイルとして取得できます。
テキスト: デフォルトでは、診断ダンプ・サンプルはテキスト形式で1つのアーカイブ・ファイルに連結されます。アーカイブ・ファイル内では、各サンプルはASCIIヘッダーとフッターによりラップされます。ヘッダーには、サンプルを生成した診断ダンプのタイムスタンプと名前が含まれます。ヘッダーとフッターの両方に、アーカイブ内のサンプルの数と、その特定のサンプルの番号が含まれます。次に例を示します。
$$$=== BEGIN OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$ Fri Sep 07 07:00:00 PDT 2013 <text of dump sampling> $$$=== END OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$
Zip: 連結ファイルのかわりにzipファイルを返すように、診断ダンプ・サンプリングを構成できます。zipファイルには、使用可能なすべてのダンプ・サンプル・ファイルが含まれます。この形式では、出力が連結に適していないバイナリ形式である診断ダンプや、テキスト形式で出力を生成するダンプがサポートされます。またこの形式では、サンプルを含むアーカイブのサイズも縮小できます。
次の例は、zipファイルの内容を示しています。
unzip -l jvm_dump.zip
Archive: jvm_dump.zip
Length Date Time Name
-------- ---- ---- ----
508780 08-21-13 07:25 dfw_samplingArchive1065570966467923683.JVMThreadDump.dmp
840 08-21-13 07:25 dfw_samplingArchive7749640004639161119.readme.txt
-------- -------
509620 2 files
ダンプ・サンプルの取得時には、テキストまたはzipファイルに加え、診断フレームワークによりREADMEファイルが生成されます。READMEファイルには、アーカイブ内の各ダンプ・サンプルの行番号(テキスト形式の場合)または個々のファイル名(zip形式の場合)のリストが含まれます。また、各サンプルのタイムスタンプおよびアーカイブに対する索引も含まれます。
ダンプ・サンプル・ファイルには次の形式で名前が付けられます。
dfw_dumpArchivennn.Sampling_Name.{txt]|zip}
ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。
たとえば、次はJVMThreadDumpに対するダンプ・サンプル・ファイルの例です。
dfw_dumpArchive17394218037.JVMThreadDump.txt
READMEファイルには次の形式で名前が付けられます。
dfw_dumpArchivennn.readme.txt
ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。
すべてのサンプリングは、頻度に対応する、次の間隔で開始するようにスケジュールされます。たとえば、サンプリングが午後12:05:13に構成され、頻度が5秒の場合、サンプルは午後12:05:15に収集されます。これにより、同じ頻度の一連のサンプリングが同時に実行されるようになります。また、システム・クロックが同期化されていれば、異なるマシン上でもすべてのサンプルが同時に取得されます。
注意:
WLSTダンプ・サンプリング・コマンドを実行するには、管理サーバーに接続している必要があります。
次の各項で説明しているように、追加のダンプ・サンプリングを作成し、既存のダンプ・サンプリングを更新し、ダンプ・サンプリングを削除し、ダンプ・サンプリングを有効化または無効化できます。
デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプは、インシデントが発生するまでアクティブではありません。インシデントが発生すると、デフォルトで72時間、アクティブになります。
MBean DumpSamplingIdleWhenHealthyをfalseに設定することにより、インシデントが発生しなくてもダンプがアクティブになるように、動作を変更できます。
システムのヘルスを判定するために費やす時間を変更するには、DumpSamplingMinimumHealthyPeriod MBeanの値を変更します。
診断フレームワークMBeanの値の変更の詳細は、「診断フレームワークの設定の構成」を参照してください。
表13-7に示したダンプおよびアプリケーション固有のダンプに対して、ダンプ・サンプリングを作成できます。ダンプ・サンプリングを作成するには、WLSTコマンドaddDumpSampleを使用します。addDumpSampleコマンドでは、次の構文を使用します。
addDumpSample(sampleName="sample_name", diagnosticDumpName="dump_name",
[appName="application_name",] samplingInterval=num_seconds,
rotationCount=num_samples, [dumpedImplicitly={true|false},]
[toAppend={true|false},] [args={"arg_name" : "value"},]
[server="server_name"])
たとえば、wls_server1サーバーに対して、http.requestsダンプに対するダンプ・サンプリングを作成し、サンプリング間隔を300秒、繰返し回数を10サンプルに設定するには、次のように指定します。
addDumpSample(sampleName="HTTPSampling", diagnosticDumpName="http.requests", samplingInterval=300, rotationCount=10, server="wls_server1") HTTPSampling is added
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のaddDumpSampleに関する項を参照してください。
WLSTコマンドupdateDumpSampleを使用することにより、既存のダンプ・サンプリングの設定を変更できます。updateDumpSampleコマンドでは、次の構文を使用します。
updateDumpSample(sampleName="sample_name", [appName="application_name",] samplingInterval=num_seconds, rotationCount=num_samplings, [dumpedImplicitly={true|false},] [toAppend={true|false},] [args={"arg_name" : "value"},] [server="server_name"])
たとえば、サンプリング間隔を200に、繰返し回数を5に変更して、ダンプ・サンプリングHTTPSamplingを変更するには、次のように指定します。
updateDumpSample(sampleName="HTTPSampling", samplingInterval=200,
rotationCount=5, server="wls_server1")
HTTPSampling is updated
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のupdateDumpSampleに関する項を参照してください。
WLSTコマンドremoveDumpSampleを使用することにより、既存のダンプ・サンプリングを削除できます。removeDumpSampleコマンドでは、次の構文を使用します。
removeDumpSample(sampleName="sample_name", [server="server_name"])
たとえば、ダンプ・サンプリングHTTPSamplingを削除するには、次のように指定します。
removeDumpSample(sampleName="HTTPSampling", server="wls_server1")
Removed HTTPSampling
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のremoveDumpSampleに関する項を参照してください。
WLSTコマンドenableDumpSamplingを使用することにより、すべてのダンプ・サンプリングを有効化または無効化できます。このコマンドは構成済のすべてのダンプ・サンプリングに影響します。enableDumpSamplingコマンドでは、次の構文を使用します。
enableDumpSampling(enable={true|false}, [server="server_name"])
serverパラメータは、管理サーバーに接続している場合にのみ有効です。serverパラメータを指定しないと、管理サーバーに対してダンプ・サンプリングが無効化されます。
たとえば、管理サーバーに対してダンプ・サンプリングを無効化するには、次のように指定します。
enableDumpSampling(enable=false) Dump sampling disabled
ダンプ・サンプリングが有効化されているのかどうかを確認するには、WLSTコマンドisDumpSamplingEnabledを使用します。isDumpSamplingEnabledコマンドでは、次の構文を使用します。
isDumpSamplingEnabled([server="server_name"])
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のenableDumpSamplingに関する項およびisDumpSamplingEnabledに関する項を参照してください。
WLSTコマンドlistDumpSamplesを使用することにより、ダンプ・サンプリングをリストできます。すべてのダンプ・サンプリング、指定したダンプ・サンプリングまたは特定のサーバーに関連付けられているすべてのダンプ・サンプリングをリストできます。listDumpSamplesコマンドでは、次の構文を使用します。
listDumpSample([sampleName="sample_name",] [server="server_name"])
たとえば、wls_server1サーバーに関連付けられているすべてのダンプ・サンプリングをリストするには、次のように指定します。
listDumpSamples(server="wls_server1") Name : JVMThreadDump Dump Name : jvm.threads Application Name : Sampling Interval : 30 Rotation Count : 20 Dump Implicitly : true Append Samples : true Dump Arguments : context=true, timing=true, progressive=true, depth=20, threshold=30000 Name : JavaClassHistogram Dump Name : jvm.classhistogram Application Name : Sampling Interval : 1800 Rotation Count : 5 Dump Implicitly : false Append Samples : true Dump Arguments :
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のlistDumpSampleに関する項を参照してください。
ダンプ・サンプルの出力を取得するには、次の各項で説明するように、WLSTコマンドexecuteDumpまたはgetSamplingArchivesを使用します。
WLSTコマンドexecuteDumpを使用し、dfw.samplingArchiveダンプを指定することにより、ダンプ・サンプルを取得できます。このコマンドは、すべてのデフォルト・サンプル・アーカイブ、および一時的な場所にあり、dumpImplicitly=trueパラメータが指定されているダンプ・サンプルを収集し、1つのファイルに連結します。このコマンドは、ダンプ・サンプルの詳細を含むREADMEファイルも返します。
executeDumpコマンドでは、次の構文を使用します。
executeDump(name="dfw.samplingArchive",outputFile="filename"
outputFileパラメータに対しては、テキスト・ファイルまたはzipファイルを指定できます。zipファイルを指定する場合は、引数zipOutput=trueを使用する必要があります。
dumpImplicitly=falseパラメータが構成されているダンプ・サンプリングについては、その内容を収集するには、オプションのdfw.samplingArchive引数sampleNameを指定する必要があります。次に例を示します。
executeDump(name='dfw.samplingArchive', args={'sampleName' : 'JavaClassHistogram'})
詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のexecuteDumpに関する項を参照してください。
WLSTコマンドgetSamplingArchivesを使用することにより、ダンプ・サンプリングを取得できます。このコマンドはすべてのダンプ・サンプルを、個々のダンプ・サンプル・ファイルとREADMEファイルを含むzipファイルに収集します。この方法は、バイナリ形式のダンプを扱う場合に特に有用です。
getSamplingArchivesコマンドでは、次の構文を使用します。
getSamplingArchives([sampleName="sample_name"] [,outputFile="filename" [,server="server_name"])
たとえば、サンプリングJavaClassHistogramに対するダンプ・サンプルを取得するには、次のコマンドを使用します。
getSamplingArchives(sampleName="JavaClassHistogram", outputFile="/tmp/sampling.zip")
zipファイルの内容を次に示します。
unzip -l /tmp/sampling.zip
Archive: /tmp/sampling.zip
Length Date Time Name
-------- ---- ---- ----
6241768 04-27-13 11:19 dfw_samplingArchive8680976839106379444.JavaClassHistogram.dmp
552 04-27-13 11:19 dfw_samplingArchive7861027727509995202.readme.txt
-------- -------
6242320 2 files
完全な構文については、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のgetSamplingArchivesに関する項を参照してください。
診断フレームワークでは、自動で作成されるか手動で作成されるかに関係なくインシデントが格納されますが、Oracle Fusion Middlewareには、インシデント・レポートの処理に役立ち、それらのインシデントをパッケージ化してOracleサポートに送信するツールが用意されています。次の項目について説明します。
システムで生成された問題(内部で生成されたクリティカル・エラー)は、自動診断リポジトリ(ADR)に自動的に追加されます。それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできます。また場合によっては問題を解決することもでき、これらはすべて、「問題の調査、報告および解決」で説明されているワークフローに記載されています。
ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要があるものの、診断フレームワークでインシデントが自動的に作成されていない場合は、インシデントを手動で作成することを検討してください。
インシデントを手動で作成するには、WLSTコマンドのcreateIncidentを使用します。インシデントは、時間、メッセージID、影響領域またはECIDを基準に指定できます。ここで、インシデントの内容を調べたり、Oracleサポートに送信してさらなる分析を依頼することができます。
たとえば、メッセージIDに基づいてインシデントを手動で作成する手順は、次のとおりです。
複数のインシデントがあり、それを1つのインシデントにまとめる場合は、WLSTのcreateAggregatedIncidentコマンドを使用できます。たとえば、選択的なトレースを使用した場合、トレース・データが含まれている結果のインシデントは複数のサーバーで生成される可能性があります。createAggregatedIncidentコマンドによって、指定する基準を満たす集計インシデントを生成できます。元のインシデントはそのままです。つまり、集計インシデントには問合せられたインシデントの複数のインシデント・ファイルのコピーが含まれています。
集計インシデントは管理サーバーのホストで作成されますが、これはドメイン内の1つ以上のサーバーまたはすべてのサーバーのインシデントを含むことができます。
インシデント属性、演算子、文字列が次の形式で含まれる式を使用して、問合せを作成できます。
attribute operator "string"
問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。
サポートされている属性と演算子の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のcreateAggregatedIncidentに関する項を参照してください。
各集計インシデントには、問合せから戻された各インシデントのzipファイルと、使用された問合せの詳細な説明テキストおよび各インシデントの詳細が含まれます。
たとえば、wls_server1サーバーでODL_TRACE_IDが123456を含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。
createAggregatedIncident(query="ORDL_TRACE_ID equals 123456", servers="wls_server1") Incident 55 created, containing the following incidents: Server wls_server1 Incident Id Problem Key Incident Time 15 TRACE [123456] [MANUAL] Mon Apr 15 11:22:12 EDT 2015
ドメイン内のすべてのサーバー上で、123456であるODL_TRACE_IDを含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。
createAggregatedIncident(query="ORDL_TRACE_ID equals 123456") Incident 55 created, containing the following incidents: Server wls_server1, wls_server2 Incident Id Problem Key Incident Time 15 TRACE [123456] [MANUAL] Mon Apr 15 11:22:12 EDT 2015
インシデントをパッケージ化して、その情報を容易にOracleサポートに送信できるようにするには、ADRコマンド・インタプリタ(ADRCI)を使用します。ADRCIユーティリティを使用すると、コマンド行環境で問題を調査および報告できます。ADRCIにより、インシデントおよび問題の情報をzipファイルにパッケージ化して、Oracleサポートに送信できます。
ADRCIコマンド行ユーティリティは次のディレクトリにあります。
(UNIX) ORACLE_HOME/oracle_common/adr (Windows) ORACLE_HOME\oracle_common\adr
インシデントのパッケージ化は、次の3つのプロセスに分かれています。
論理パッケージを作成します。
このパッケージは、ADRではメタデータとしてのみ存在するため、論理的なものと示されます。インシデント・パッケージは、論理パッケージから物理パッケージを生成するまではコンテンツが含まれません。論理パッケージにはパッケージ番号が割り当てられますので、以降のコマンドではこの番号を使用してパッケージを参照します。
論理パッケージは空のパッケージとして作成することも、インシデント番号、問題番号、問題キーまたは時間間隔に基づいたパッケージとして作成することもできます。パッケージを空のパッケージとして作成する場合は、手順2でパッケージに診断情報を追加できます。
インシデントを基準にパッケージを作成すると、ダンプなど、そのインシデントの診断データが含まれることになります。問題番号または問題キーに基づいてパッケージを作成する場合は、パッケージにその問題番号または問題キーを参照するインシデントの診断データが含まれます。時間間隔に基づいてパッケージを作成する場合は、その時間間隔内で発生したインシデントに関する診断データが含まれます。
診断情報をパッケージに追加します。
インシデント番号、問題番号、問題キーまたは時間間隔に基づいて論理パッケージを作成した場合、この手順はオプションとなります。パッケージにインシデントを追加したり、ADR内のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用してパッケージにインシデントまたはファイルを追加する必要があります。
物理パッケージを生成します。
コマンドを送信して物理パッケージを生成するときに、ADRCIは必要なすべての診断ファイルを収集して、指定したディレクトリ内のZIPファイルに追加します。完全なZIPファイルまたは増分ZIPファイルを生成できます。増分ファイルには、同じ論理パッケージに対してZIPファイルが最後に作成されて以降に追加または変更された診断ファイルすべてが含まれます。増分ファイルは完全ファイルを作成した後にのみ作成でき、必要な数だけ作成できます。各ZIPファイルには順序番号が割り当てられるため、ファイルを正しい順序で分析できます。
zipファイルは、次の形式に従って名前が付けられます。
packageName_mode_sequence.zip
この形式の各項目について説明します。
packageNameは、問題キーの一部にタイムスタンプが続きます。
modeは、COM(完全)またはINC(増分)です。
sequenceは整数です。
たとえば、インシデントをパッケージ化するには、次の手順を実行します。
デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、「診断フレームワークの設定の構成」で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。
ADRCIコマンドを使用して、インシデントを手動でパージできます。パージは、IDまたはIDの範囲、インシデントの経過時間、またはインシデントのタイプを基準にして行えます。たとえば、経過時間が60分を超えたインシデントをパージするには、次のコマンドを使用します。
purge -age 60
『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。
コマンド行診断ツールのRemote Diagnostic Agent (RDA)を使用して、ご使用の環境の全体像を把握することができます。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。
RDAは、エンジンにより実行される、Perlプログラミング言語で作成される一連のコマンド行診断スクリプトです。RDAはOracle環境に関する詳細情報の収集に使用され、収集されたデータは次に問題診断の支援に使用されます。また、その出力は全体的なシステム構成を確認するのに役立ちます。
RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。
RDAは次の領域の問題のトラブルシューティングに役立つ情報を収集します。
インストールと構成
パフォーマンス
ORA-600エラー、ORA-7445エラー、ORA-3113エラーおよびORA-4031エラー
アップグレード、移行およびリンク
Oracle Database
Oracle Fusion Middleware
RDAを実行するには、次のコマンドを実行します。
(UNIX) ORACLE_HOME/oracle_common/rda/rda.sh (Windows) ORACLE_HOME\oracle_common\rda\rda.cmd
次に、出力の一部を示します。
./rda.sh ------------------------------------------------------------------------------- S000INI: Initializes the Data Collection ------------------------------------------------------------------------------- RDA uses the output file prefix to identify all files belonging to the same data collection. The prefix must start with a letter and must contain only alphanumeric characters. Enter the prefix to be used for all the generated files Hit 'Return' to accept the default (RDA) > Enter the directory used for all the files to be generated Hit 'Return' to accept the default (/scratch/oracle1/Oracle/Middleware/Oracle_Home/oracle_common/rda/output) > Do you want to keep report packages from previous runs (Y/N)? Hit 'Return' to accept the default (N) > Enter the Oracle home to be used for data analysis Hit 'Return' to accept the default (/scratch/oracle1/Oracle/Middleware/Oracle_Home )
RDAの詳細は、次の場所にあるreadmeファイルを参照してください。
(UNIX) ORACLE_HOME/oracle_common/rda/README_Unix.txt (Windows) ORACLE_HOME\oracle_common\rda\README_Windows.txt
Oracle Fusion Middlewareでは、ヘルス・テスト・フレームワークが提供されており、これには、Oracle Fusion Middlewareおよびそのアプリケーションが正しく動作しているかどうかを判断し、問題があれば特定して解決するために、それらの特定の部分を動作させるように設計された診断テストが組み込まれています。
この項では、次の項目について説明します。
ヘルス・テスト・フレームワークでは、診断テストを実行し、結果を収集して、詳細な診断レポートを生成できます。診断テストは、Oracle Fusion Middlewareのインストールまたはパッチ適用時にインストールされます。
ヘルス・テスト・フレームワークを使用して、通常のシステム・ヘルスをチェックし、システムの問題をトラブルシューティングできます。ヘルス・テスト・フレームワークのコマンド行インタフェースを使用して診断テストを実行するように、Oracle Fusion Middleware環境を構成できます。
診断テストを特定のエラー・メッセージと関連付けることができます。Oracle Fusion Middlewareアプリケーションが特定のエラーを、インシデントの作成をトリガーするような方法で処理する場合、そのインシデントに対するエラー・メッセージに関連付けられている診断テストが自動的に実行されます。テスト結果はインシデントに関連付けられ、エラー・メッセージを受信したユーザーが誰であるかが記録されます。診断テストは、「ヘルス・テスト・フレームワークのファイル・リポジトリについて」で説明するように、ファイルベースのリポジトリに保存されます。
ヘルス・テスト・フレームワークは、テストおよびテスト結果をファイルベースのリポジトリに保存します。リポジトリには次の2つのプライマリ・ストアがあります。
TestDef: テスト定義、テスト・メタデータ、テスト・パラメータに関連するデータ、言語データファイルおよび索引ファイルが含まれます。
TestRun: テスト・ランと実行、レポート・ファイルおよび索引ファイルに関連するデータが含まれます。
索引ファイルは、検索および問合せ速度を向上させるために使用されます。
リポジトリは、テストの登録または実行時に指定した場所にリポジトリが存在しない場合に作成されます。
リポジトリの場所は、構成プロパティ・ファイルdiagfsconfig.propertiesで指定できます。このファイルは次の場所にあります。
ORACLE_HOME/diagbase/dtf_filestore
デフォルトでは、ファイル・ストアは次の場所にあります。
ORACLE_HOME/diagbase/dtf_filestore/testdef ORACLE_HOME/diagbase/dtf_filestore/testrun
次の各項で説明するように、ヘルス・テスト・フレームワークには、管理コマンド用のdfwhealthtestadminctl.shと、実行コマンド用のdfwhealthtestctl.shという2つのコマンド行インタフェースがあります。
ヘルス・テスト・フレームワークには、ヘルス・テストを管理するためのdfwhealthtestadminctl.shコマンド行があります。これを使用して、テストを登録し、索引を再構築できます。
dfwhealthtestadmin.ctlコマンドを実行する前に、次の環境変数を設定する必要があります。
ORACLE_HOME: Oracleホーム
JAVA_HOME: Javaホーム
dtf_fs_diagbase: リポジトリの場所
dfwhealthtestadminctl.shコマンド行は次の場所にあります。
ORACLE_HOME/oracle_common/common/bin
コマンド行インタフェースの構文は、次のとおりです。
/dfwhealthtestadminctl.sh command [options]
表13-9に、ヘルス・テスト・フレームワークの管理コマンドを示します。
コマンドのヘルプを表示します。
構文は次のとおりです。
help command
次の表に、helpコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
command |
コマンドの名前。 |
1つ以上のテストをリポジトリに登録します。
構文は次のとおりです。
register testfile=test_xml_files | dir=test_dirs [validateonly={Y|N]] testjar=jar_file_location
次の表に、registerコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
testfile |
登録する1つ以上のXMLテスト・ファイル。ファイルへのパスを指定します。複数のファイルを指定する場合は、カンマ区切りリストを使用します。 |
dir |
登録する1つ以上のディレクトリ。ディレクトリへのパスを指定します。複数のディレクトリを指定する場合は、カンマ区切りリストを使用します。このオプションは、同じディレクトリからの複数のテストを登録する場合に使用します。 |
validateonly |
オプション。テストを検証するだけなのか、またはテストをリポジトリにアップロードするのかを指定するブール値。有効な値は、 |
testjar |
テストjarファイルの場所。 |
ヘルス・テスト・フレームワークには、ヘルス・テストを実行するためのdfwhealthtestctl.shコマンド行があります。このコマンド行では、テストの実行、ランとテストのリスト、テストの説明の表示、テストのステータスの取得、およびテストまたはテスト・ランのレポートの取得を行えます。
dfwhealthtestctl.shコマンド行は次の場所にあります。
ORACLE_HOME/oracle_common/common/bin
コマンド行インタフェースの構文は、次のとおりです。
/dfwhealthtestctl.sh command [options]
表13-10に、ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンドを示します。
指定されたテストの詳細な説明を表示します。
構文は次のとおりです。
desctest {testid=testid | testname=testname}]
[showparam={Y|N}]
次の表に、desctestコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
testid |
テストのID。IDを取得するには、listtestコマンドを使用します。このパラメータまたは |
testname |
テストの名前。このパラメータまたは |
showparam |
オプション。テストのパラメータを取得するかどうかを指定するブール値。有効な値は |
コマンドのヘルプを表示します。
構文は次のとおりです。
help command
次の表に、helpコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
command |
コマンドの名前。 |
テスト・ランに対するサマリー情報を取得します。ラン名、ラン・ステータス、開始時間またはテスト名に基づいて情報を取得できます。
構文は次のとおりです。
listrun { runname=runname | testname=testname | status=status | lasthours=hours }
[showexec={Y|N]]
次の表に、listrunコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
runname |
結果を取得するランの名前。runnameを取得するには、パラメータを指定せずにlistrunコマンドを実行します。 |
testname |
結果を取得するテストの名前。 |
status |
結果を取得するランのステータス。有効な値は、running、warningおよびsuccessです。 |
lasthours |
結果を取得する時間数。 |
showexec |
オプション。テストの実行を取得するかどうかを指定するブール値。有効な値は |
1つ以上のテストをリストします。ワイルドカードを使用してテストの名前を指定できます。
構文は次のとおりです。
listtest [testname=testname] [productcode=productcode
次の表に、helpコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
testname |
1つ以上のテストの名前のカンマ区切りリスト。ワイルドカードを使用してテストの名前に一致するパターンを指定できます。 |
productcode |
製品の名前。ワイルドカードを使用して製品の名前に一致するパターンを指定できます。 |
特定のテスト・ランまたは実行に対するテスト・レポートを抽出します。
構文は次のとおりです。
report { runname=runname | runid=run_id | execid=execution_id }
[destdir=destination_directory}
[format=HTML | XML]
[translate={Y | N}
次の表に、reportコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
runname |
ランの名前。名前を取得するには、listrunコマンドを使用します。このパラメータ、 |
runid |
ランのID。IDを取得するには、listrunコマンドを使用します。このパラメータ、 |
execid |
ランの実行ID。IDを取得するには、listrunコマンドを使用します。このパラメータ、 |
destdir |
オプション。レポート・ファイルが書き込まれる宛先ディレクトリ。指定しないと、レポート・ファイルはjava.io.tmpdir/user.name/diagfwkディレクトリに抽出されます。ここで、java.io.tmpdirとuser.nameはJavaシステム・プロパティです。 |
format |
生成されるレポートの形式。有効な値は |
translate |
レポートを翻訳するかどうかを指定するブール値。有効な値は |
指定されたテストを実行します。
run {test=testnames | productcode=codes }
[runname=name
[runoption=asynch]
[input:param1=value1 param2=value2 ...
[inputfile=filename]
[contextfile=context_file]
[moninterval=monitoring_interval]
[nthreads=number_of_threads]
[reportshowparam=show_param]
次の表に、runコマンドのパラメータを示します。
| パラメータ | 説明 |
|---|---|
test |
1つ以上のテストの名前のカンマ区切りリスト。 単一のテスト名を指定する場合は、inputパラメータを使用して1つ以上の入力パラメータ名および値も指定できます。 このパラメータまたはproductcodeパラメータのいずれかを指定する必要があります。 |
productcode |
実行するテストを含む1つ以上の製品に対するコード。複数の製品コードを指定するには、カンマ区切りリストを使用します。 |
runname |
オプション。現在のランの名前。指定しないと、コマンドによりデフォルトのラン名が生成されます。 |
moninterval |
ランのステータスがテスト・リポジトリにアップロードされる間隔(秒単位)。デフォルト値は30秒です。 |
nthreads |
このラン内のテストを実行するために生成するパラレル・スレッドの数。デフォルト値は5です。このパラメータに対して値1を指定すると、テストはシリアルに実行されます。 |
runoption |
オプション。テストを実行するためのオプション。有効な値は |
input |
オプション。このパラメータを使用する場合は、1つ以上のパラメータ名/値ペアを指定します。次に例を示します。 domainhome=/scratch/oracle/domains/basedomain このパラメータは、1つのテストだけを実行する場合にのみ使用できます。 |
inputfile |
入力パラメータを含むファイルへのパス。各入力名/値ペアを、ファイル内の別々の行に指定します。各行の形式は次のとおりです。 input_param_name:input_param_value |
contextfile |
実行時に使用するユーザー・システム・プロパティを含むファイルへのパス。 |
reportshowparam |
入力および出力パラメータの表示を設定します。デフォルトでは、すべてのパラメータは実行時には表示されません。パラメータを表示することを指定するには、 reportshowparam=input,output |
次の各項で説明するように、テストを登録し、索引を再構築できます。
リポジトリを作成するには、dfwhealthtestadminctl.sh registerコマンドを使用してテストを登録します。コマンドによりリポジトリが作成され、1つ以上のテストがリポジトリに登録されます。
リポジトリを作成してテストを登録する手順は次のとおりです。
testfileまたはdirパラメータを使用することにより、一度に複数のテストを登録することもできます。
testfileパラメータを使用して複数のテストを登録するには、カンマ区切りリストまたはワイルドカードを使用できます。
次の例は、カンマ区切りリストを使用して、2つのテストを登録します。
dfwhealthtestadminctl.sh register testfile=/scratch/tests/sampleTest.xml,
/scratch/moretests/sampleTest.xml
testjar=/scratch/tests/testjar
次の例は、ワイルドカードを使用して、複数のテストを登録します。
dfwhealthtestadminctl.sh register testfile=/scratch/tests/%Test.xml,
testjar=/scratch/tests/testjar
dirパラメータを使用して複数のテストを登録するには、カンマ区切りリストで1つ以上のディレクトリを指定します。
次の例は、指定されたディレクトリ内のすべてのテストを登録します。
dfwhealthtestadminctl.sh register dir=/scratch/dtf_tests
索引により、ヘルス・テスト・フレームワーク・リポジトリでの検索および問合せの速度が向上します。テスト定義に関連する索引は、testdefファイル・ストアに格納されています。テスト・ランおよび実行に関連する索引は、testrunファイル・ストアに格納されています。
状況によっては、索引のリフレッシュが必要になることがあります。この場合、testdefまたはtestrunファイル・ストアを指定して、dfwhealthtestadminctl.sh indexコマンドを実行します。次の例は、testdefファイル・ストアをリフレッシュします。
dfwhealthtestadminctl.sh index refresh=testdef
ヘルス・テスト・フレームワークの診断テストは、次の場所にあるdfwhealthtestctl.shコマンド行インタフェースを使用して実行します。
ORACLE_HOME/oracle_common/common/bin
テストを実行するには、「run」で説明している形式で、runコマンドを使用します。たとえば、SampleTestテストを実行するには、次のコマンドを使用します。
./dfwhealthtestctl.sh command [testfile=SampleTest.xml]
一度に1つまたは複数のテストを実行できます。
カンマ区切りリストでテスト名を指定して1つ以上のテストを実行する例
./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest2 Processing "run" command ... Executing run ID "1340125981427" with name "TestRun_1340125981427" ... sampleTest2 sleep for a while.... sampleTest2 done Run ID "1340125981427" with name "TestRun_1340125981427" started at 3/21/2015 10:13:01 AM and completed at 3/21/2015 10:13:04 AM. No diagnostic issues were detected.
テスト名にワイルドカードを使用して1つ以上のテストを実行する例
./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest*
特定の製品に関連付けられているすべてのテストを実行する例
./dfwhealthtestctl.sh run productcode=idm
1つのテストのみを実行する場合は、コマンド行または入力ファイルのいずれかで入力オプションを指定できます。
コマンド行で入力オプションを指定するには、input:パラメータを使用します。
./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest,oracle.dfw.healthtest.test.sample.SampleTest2
input:userid=11 input:roleid=22
入力ファイルで入力オプションを指定するには、ファイルを作成し、inputfileパラメータを使用して、コマンド行でそのファイルを指定します。入力ファイルの形式は次のとおりです。
input_parameter1:parameter_value1 input_parameter2:parameter_value2
次に例を示します。
userid:11 roleid:22
次に、コマンド行でファイルを指定します。
./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest
inputfile=/tmp/inputfile
dfwhealthtestctl.sh listtestコマンドを使用することにより、テストまたはランを検索できます。オプションで、テストの名前または製品コードを指定できます。
すべてのテストを検索するには、次のように指定します。
./dfwhealthtestctl.sh listtest
SampleTestという名前のテストを検索するには、次のように指定します。
./dfwhealthtestctl.sh listtest testname=SampleTest
ワイルドカードを使用して複数のテストを検索するには、次のように入力します。
./dfwhealthtestctl.sh listtest testname="S*"
特定の製品に関連するすべてのテストを検索するには、次のように入力します。
dfwhealthtestctl.sh listtest productcode=idm
dfwhealthtestctl.sh listtestコマンドを使用することにより、指定したテストの説明を取得できます。たとえば、SampleTestテストの説明とそのパラメータを取得するには、次のコマンドを使用します。
./dfwhealthtestctl.sh desctest testname="SampleTest" showparam=Y
dfwhealthtestctl.sh listrunコマンドを使用することにより、テスト名、ラン名、ステータスまたは時間に基づいて、テスト・ランの結果を問い合せることができます。
テスト名を指定してテスト・ランの結果を問い合せるには、次のように指定します。
./dfwhealthtestctl.sh listrun testname="SampleTest"
ラン名を指定してテスト・ランの結果を問い合せるには、次のように指定します。
./dfwhealthtestctl.sh listrun runname="run_1"
ステータスを指定してテスト・ランの結果を問い合せることができます。たとえば、ステータスがrunningであるすべてのテストの結果を取得するには、次のように指定します。
./dfwhealthtestctl.sh listrun status=r
過去2時間に開始されたテスト・ランの結果を問い合せるには、次のように指定します。
./dfwhealthtestctl.sh listrun lasthours=2
