13 問題の診断

Oracle Fusion Middleware診断フレームワークを使用すると、問題を解決したり、解決のためにOracleサポートに送信できるように問題に関する情報を収集および管理することが容易になります。

内容は次のとおりです。

診断フレームワークについて

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 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

ディレクトリが存在しない場合は、次のいずれかのステップを実行します。

自動診断リポジトリ

自動診断リポジトリ(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ホームのディレクトリ階層を示しています。

図13-1 Oracle Fusion MiddlewareのADRディレクトリ構造

図13-1の説明が続きます
「図13-1 Oracle Fusion MiddlewareのADRディレクトリ構造」の説明

ADRホームのサブディレクトリには、次の情報が含まれています。

  • alert: XML形式のアラート・ログ。

  • incident: 複数のサブディレクトリを格納できるディレクトリ。それぞれのサブディレクトリには、当該のインシデントの名前が付けられます。サブディレクトリの名前はincdir_nで、このnはインシデントの番号を表しています。それぞれのサブディレクトリには、そのインシデントのみに関する情報および診断ダンプが格納されます。

  • (others): ADRホームのその他のサブディレクトリ。インシデント・パッケージなどの情報が格納されます。

注意:

ADRでは、インシデントをパッケージ化する際に、製品IDとしてドメイン名を使用し、インスタンスIDとしてサーバー名を使用します。ただし、いずれかの名前が30文字を超える場合は、ADRは名前の一部を切り捨てます。また、ドル記号($)と空白文字はアンダースコアに置き換えられます。

診断ダンプ

診断ダンプは、特定の診断情報を取得およびダンプします。この処理は、インシデントが作成された時点では自動で、管理者が要求した時点では手動で行われます。インシデント作成の一環として実行される場合、ダンプは一連のインシデント診断データに含まれます。診断ダンプには、JVMスレッド・ダンプ、JVMクラス・ヒストグラム・ダンプ、DMSメトリック・ダンプなどがあります。診断ダンプのリストについては、表13-7を参照してください。

診断フレームワーク管理MBean

診断フレームワークには、診断フレームワークの構成に使用できるMBeanが用意されています。たとえば、フラッド制御を有効化または無効化したり、指定された期間内に問題キーが同じインシデントが何回発生できるかを構成できます。管理MBeanを使用して診断フレームワークを構成する方法の詳細は、「診断フレームワークの構成」を参照してください。

また、MBeanを使用すると、インシデントの問合せおよび作成を行ったり、使用可能な診断ダンプ・タイプのリストを検索したり、個々の診断ダンプを実行することができます。

診断フレームワーク用WLSTコマンド

診断フレームワークには、問題およびインシデントに関する情報の表示、インシデントの作成、特定のダンプの実行および一連の診断ダンプ・タイプの問合せに使用できるWLSTコマンドが用意されています。

ADRCIコマンド行ユーティリティ

ADRコマンド・インタプリタ(ADRCI)は、問題を調査し、初期障害診断データをパッケージ化してOracleサポートにアップロードするという処理を、コマンド行環境ですべて実行できるユーティリティです。またADRCIを使用して、ADR内のダンプ・ファイルの名前を表示したり、コンテンツ・フィルタを指定して(または未指定で)XMLタグが取り除かれた状態でアラート・ログを表示することもできます。

ADRCIは次のディレクトリにインストールされています。

(UNIX) ORACLE_HOME/oracle_common/adr 
(Windows) ORACLE_HOME\oracle_common\adr

ADRCIコマンド行ユーティリティの使用の詳細は、次の各項を参照してください。

関連項目:

診断フレームワークの動作

診断フレームワークは、それぞれのサーバーでアクティブであり、構成された事前定義のルールに基づいてエラーを自動的に検出します。Oracle Fusion Middlewareのコンポーネントおよびアプリケーションは、常に監視対象となるため、自動的に診断フレームワークの恩恵を受けることになります。

インシデントは、次の2つの方法で自動的に検出されます。

  • インシデント検出ログ・フィルタ。クリティカル・エラーを検出するように自動的に構成されます。

  • WLDFポリシーおよびアクション・コンポーネント。診断フレームワークでは、事前定義された通知タイプをリスニングし、そのような通知を受信したときにインシデントを作成します。

    WLDFポリシーおよびアクションの構成の詳細は、「診断フレームワーク用のWLDFポリシーおよびアクションの構成」を参照してください。

  • プログラムによるインシデント作成。一部のコンポーネントでは、インシデントを直接作成します。

図13-2は、インシデント・ログ検出でインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント・ログ検出でインシデントが検出されたときの、インシデント・ログ検出、WLDF診断イメージMBean、ADR、およびコンポーネントまたはアプリケーションのダンプの間のやり取りを示しています。

図13-2 インシデント・ログ検出で生成されるインシデント作成

図13-2の説明が続きます
図13-2「インシデント・ログ検出で生成されるインシデント作成」の説明

図13-2で示されているステップは、次のとおりです。

  1. インシデント検出ログ・フィルタは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

  2. アプリケーションまたはコンポーネントは、java.util.logging APIを使用して、メッセージをログに記録します。

  3. ODLログ・ハンドラは、メッセージをインシデント検出ログ・フィルタに渡します。

  4. インシデント・ログ検出フィルタは、ログ・メッセージを検証し、コンポーネントの診断ルールに基づいて、インシデントを作成するかどうかを判断します。診断ルールによりインシデントを作成する必要があると示された場合、ADRにインシデントが作成されます。

  5. ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をアプリケーションに戻します。

    インシデントが作成されると、次のようなメッセージがログ・ファイルに書き込まれます。

    [2017-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 2017 errorMessage=MDS-50500 executionContextId=null]
    
  6. 診断フレームワークは、コンポーネントの診断ルールで示される診断ダンプを実行します。

  7. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

  8. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

  9. WLDFは、ADRに診断イメージを書き込みます。

図13-3は、WLDFポリシーおよびアクション・システムでインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント通知リスナー、WLDFポリシーおよびアクション・システム、WLDF診断イメージMBeanの間の情報のやり取りを示しています。

図13-3 WLDFポリシーおよびアクションによって生成されるインシデント作成

図13-3の説明が続きます
「図13-3 WLDFポリシーおよびアクションによって生成されるインシデント作成」の説明

図13-3で示されているステップは、次のとおりです。

  1. インシデント通知リスナーは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

  2. Oracle Fusion Middleware診断フレームワークは、WLDFにJMX通知リスナーを登録します。リスナーは、WLDFポリシーおよびアクション・システムからのイベントをリスニングします。ここで処理される通知は、oracle.dfw.wldfnotificationタイプのみです。

  3. システム内のなんらかが原因となって、構成されたWLDFポリシーがトリガーされ、インシデント通知リスナーに通知が送信されます。通知には、ポリシーをトリガーする原因となったデータについて記述したイベント情報が含まれます。

  4. 診断フレームワークにより、ADRにインシデントが作成されます。

  5. 診断フレームワークは、診断ルールで示される診断ダンプを実行します。

  6. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

  7. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

  8. 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

フラッド制御を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

フラッド制御は、手動で作成されたインシデントには適用されません。

floodControlIncidentCount

フラッド制御で制御されるまでに、floodControlIncidentTimeoutPeriodで指定された期間内に作成できる、問題キーが同じインシデントの数を設定します。デフォルトは5です。

フラッド制御が有効になっていて、同じ問題キーのインシデントの数がこのカウントを超えると、インシデントが作成されなくなります。ただし、診断フレームワークは、WARNINGレベルのメッセージをログ・ファイルに書き込みます。

floodControlIncidentTimeoutPeriod

フラッド制御で制御されるまでに、floodControlIncidentCountで指定された数の、問題キーが同じインシデントを作成できる期間を設定します。デフォルトは60分です。

incidentCreationEnabled

インシデント作成を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

logDetectionEnabled

ログ・ファイルを使用したインシデントの検出を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

maxTotalIncidentSize

すべてのインシデントに割り当てられる最大合計サイズを設定します。この制限に達すると、すべてのインシデントで使用される領域がこのパラメータで指定される量より小さくなるまで、最も古いインシデントから順にパージされます。

デフォルトは500MBです。インシデントの作成時にこの制限を超えた場合は、インシデントの作成が完了したときに、最も古いインシデントからパージされていきます。

reservedMemoryKB

OutOfMemoryErrorが検出されたときに解放される予約済メモリーの量。

診断フレームワークの起動時に、プライベートで使用されるメモリーが512 KB割り当てられます。診断フレームワークにより、サーバーにOutOfMemoryErrorが発生したことが検出されると、そのメモリーのブロックを解放して、インシデントの作成に進みます。

デフォルトは512KBです。

uncaughtExceptionDetectionEnabled

Javaベースの捕えられていない例外ハンドラを有効にします。これが有効のときに捕えられていない例外が検出されると、インシデントが作成されます。有効化する場合はtrue、無効化する場合はfalseと指定します。

デフォルトはtrueです。

useExternalCommands

スレッド・ダンプの実行に外部JVMコマンドを使用するかどうかを示します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

次の例は、Fusion Middleware ControlシステムMBeanブラウザを使用してこれらの設定を構成する方法を示しています。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. 「アプリケーション定義のBean」「oracle.dfw」「Domain.domain_name「dfw.jmx.DiagnosticsConfigMBean」を開きます。
  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
  4. 「アプリケーション定義のMBean」ペインで「MBean情報の表示」を開くと、サーバー名が表示されます。

    次に、「システムMBeanブラウザ」ページを示します。

  5. 表13-1に一覧表示されている属性の値を変更するには、「値」フィールドで値を入力または選択します。
  6. 「適用」をクリックします。

カスタム診断ルールの構成

ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム診断ルールを構成できます。

カスタム診断ルールは、特定の形式の.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。

コンポーネント

コンポーネント名。(ODLログ・ファイル用のCOMPONENT_IDフィールド。)たとえば、oracle.mdsのように指定します。

モジュール

メッセージを生成したモジュールの名前。(ODLログ・ファイル用のMODULE_IDフィールド。)

ODLログ・ファイル・フィールドの説明は、表12-1を参照してください。

表13-3に、<defaultActions>要素に対して使用できるオプションの引数を示します。

表13-3 defaultActions要素に対するオプションの引数

引数 説明

名前

引数の名前。

引数の値。

タイプ

引数のタイプ。有効な値は次のとおりです。

  • literal: このタイプを指定した場合は、引数のリテラル値が使用されます。これはデフォルトです。

  • fact: このタイプを指定した場合は、値はINCIDENT_TIMEまたはECIDである必要があります。

  • context: このタイプを指定した場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』DMS実行コンテキストに関する項を参照してください。

表13-4に、<ruleCondition>要素属性を示します。

表13-4 ruleCondition要素の属性

要素 説明

名前

属性の名前を指定します。有効な値はvalueTypeに依存します。

  • valueTypeがfactの場合は、有効な値はCOMPONENT_ID、MODULE_IDまたはMESSAGE_IDです。

  • valueTypeがcontextの場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』DMS実行コンテキストに関する項を参照してください。

operator

演算子。有効な値は、EQ、EQNoCase、NE、Contains、StartsWith、EndsWith、LT、GT、LE、GEです。デフォルトはEQです。

値では大/小文字が区別されます。

比較するリテラル値。

datatype

データ型。有効な値はStringまたはIntegerです。デフォルトはStringです。

値では大/小文字が区別されます。

valueType

引数のタイプ。

  • fact

  • context

カスタム診断ルールを作成してロードする手順は次のとおりです。

  1. カスタム・ルールを含むファイルを作成します。

    サンプル・カスタム・ルール・ファイルを次に示します。

    <?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"/> 
               // detect all message logged at level INCIDENT_ERROR
          <condition messageSeverity="ERROR" component="jrfServer_admin"/> 
              // detect all "jrfServer_admin" component messages logged at level ERROR
          <condition messageSeverity="ERROR" module="test.servletA"/> 
              // detect all "test.servlet" module messages logged at level ERROR
          <condition messageId="FMW-40300"/> 
              // detect message "FMW-40300"
        </logDetectionConditions>
        
        <defaultActions>
          <dumpAction name="odl.logs">
            <argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
          </dumpAction>
          <dumpAction name="dms.metrics"/>
        </defaultActions>
     
        <processingRules>
          <rule name="OOME">
            <ruleCondition>
              <condition name="MESSAGE_ID" value="DFW-99997"/>
            </ruleCondition>
            <ruleActions>
              <dumpAction name="jvm.classhistogram"/>
            </ruleActions>
          </rule>
        </processingRules>
     
    </diagnosticRules>
    
  2. 拡張子.xmlを含む名前を付けて、ファイルを保存します。ルールがアプリケーションに適用される場合は、ファイル名の前にapp_name#を付けます。ファイルを次のいずれかの場所に保存します。
    DOMAIN_HOME/config/fmwconfig/dfw
    DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw
    
  3. WLSTコマンドreloadCustomRulesを使用して、ルールをロードします。次の例は、myAppアプリケーションに適用されるcustomrules.xmlルールをロードします。
    reloadCustomRules(name='myApp#customrules.xml')
    

    ドメイン内のすべてのルール、または特定のサーバーに関連するすべてのルールを再ロードできます。次の例は、wls_server1サーバーに対するすべてのルールを再ロードします。

    reloadCustomRules(server='wls_server1')
    

    reloadCustomRulesコマンドの詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』reloadCustomRulesに関する項を参照してください。

問題抑制の構成

一定の状況では、特定の問題キーに基づいてインシデントの作成を抑制する必要がある場合があります。たとえば、開発環境で、サーブレットを開発しているときに、コードを調整すると捕えられていない例外が多数生成されることがあります。これにより、不要なインシデントが作成されます。

診断フレームワークによって、フィルタ条件と一致する問題でインシデントが作成されないように問題抑制フィルタを構成できます。

問題抑制フィルタを構成する場合は、マッチするパターンを表す正規表現を使用します。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)

問題抑制フィルタを構成する手順は次のとおりです。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. 「アプリケーション定義のBean」「oracle.dfw」「domain.domain_name「dfw.jmx.DiagnosticsConfigMBean」を開きます。
  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
  4. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。
  5. 「addProblemKeyFilter」をクリックします。操作: addProblemKeyFilterページが、次の図のように表示されます。
  6. 「値」に、マッチするパターンを表す正規表現を入力します。たとえば、開発環境では、java.lang.IllegalStateExceptionというJava例外が報告されたときにインシデントが作成されないようにフィルタを追加する必要がある場合があります。この場合、次のように入力します。
    ".*[java.lang.IllegalStateException].*"
    
  7. 「呼出し」をクリックします。
  8. 「戻る」をクリックし、「アプリケーション定義のMBean」ページに戻ります。

removeProblemKeyFilter操作を使用すると、フィルタを削除できます。

問題キー・フィルタの取得

getProblemKeyFilter操作にフィルタIDを渡すと、特定のフィルタを取得できます。

また、次のようにgetProblemKeyFilters属性を使用すると、フィルタのリストを取得できます。

  1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。

    「システムMBeanブラウザ」ページが表示されます。

  2. 「アプリケーション定義のBean」「oracle.dfw」「domain.domain_name「dfw.jmx.DiagnosticsConfigMBean」を開きます。
  3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
  4. 「アプリケーション定義のMBean」ペインで、「属性」タブを選択します。
  5. 「ProblemKeyFilters」をクリックします。

    問題抑制フィルタのリストが表示されます。

診断フレームワーク用のWLDFポリシーおよびアクションの構成

Oracle Fusion Middlewareでは、特定の一連のクリティカル・エラーを検出し、そのようなエラーが発生するたびにインシデントを作成するための一連のポリシーおよびアクションのルール(以前はウォッチおよび通知のルールと呼ばれていました)が含まれているWLDF診断モジュールを構成します。そのようなポリシーを構成してインシデントを作成できます。

WLDF診断モジュールはModule-FMWDFWと呼ばれ、次の一連のポリシー条件が含まれます。

Name 説明

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ポリシー条件で再利用することもできます。

  1. Fusion Middleware Controlの「WebLogicドメイン」メニューから、「診断」を展開して、「診断モジュール」を選択します。

    「診断モジュール」ページが表示されます。

  2. 「Module-FMWDFW」をクリックします。

    「Module-FMWDFW」ページが表示されます。

  3. 「構成」タブ、「ポリシーとアクション」タブの順に選択します。次の図は、「ポリシー」セクションを示しています。

  4. 「ポリシー」タブを選択し、「作成」をクリックします。

    「診断ポリシーの作成」ページが表示されます。

  5. 「ポリシー名」にポリシーの名前を入力します。

    任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージ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として使用します。

  6. 「ルール・タイプ」で、「サーバー・ログ」や「スマート・ルール」などの基になるタイプを選択します。これは、「クラスタ平均スループット(下限)」などの事前構成済ルールです。

  7. 「次へ」をクリックします。

  8. 次のページは、ポリシーのタイプによって異なります。

    • スマート・ルール・ベース:

      1. ルールを選択して「次へ」をクリックします。

      2. パラメータ値を入力して「次へ」をクリックします。

      3. ポリシーを週または月の特定の日にスケジュールする場合、「開始時間」に、「時」「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。

        このオプションは、「繰返し」フィールドから、「特定の曜日」または「月の特定の日付」を選択したときにのみ使用されます。

      4. 「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。

      5. ポリシーを指定した間隔で実行する(5分間隔など)ようにスケジュールする場合、「頻度」に、5などの値を指定します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。

      6. アラーム・タイプを選択して、「次へ」をクリックします。

      7. 「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      8. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

    • カレンダ・ベースの場合:

      1. ポリシーを週または月の特定の日にスケジュールする場合、「開始時間」に、「時」「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。

        このオプションは、「繰返し」フィールドから、「特定の曜日」または「月の特定の日付」を選択したときにのみ使用されます。

      2. 「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。

      3. ポリシーを指定した間隔で実行する(5分間隔など)ようにスケジュールする場合、「頻度」に、5などの値を指定します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。

      4. 動的クラスタがある場合、「スケーリング・アクション」「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      5. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

    • 収集対象メトリックの場合:

      1. 「スマート・ルール」または「式」を選択します。「次へ」をクリックします。

        「スマート・ルール」を選択した場合は、パラメータの値を指定します。

        「式」を選択した場合は、式を入力します。

      2. 「次へ」をクリックします。

      3. ポリシーを週または月の特定の日にスケジュールする場合、「開始時間」に、「時」「分」および「秒」の値を指定します。次に、「AM」または「PM」を選択します。

        このオプションは、「繰返し」フィールドから、「特定の曜日」または「月の特定の日付」を選択したときにのみ使用されます。

      4. 「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、「N分ごと」を選択します。

      5. ポリシーを指定した間隔で実行する(5分間隔など)ようにスケジュールする場合、「頻度」に、5などの値を指定します。「繰返し」で「N分ごと」を選択した場合、スケジュールは5分ごとになります。「次へ」をクリックします。

      6. アラーム・タイプを選択して、「次へ」をクリックします。

      7. 「スケーリング・アクション」で「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      8. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

    • ドメイン・ログの場合:

      1. ポリシーのルールを作成するための式を追加します。その後、「次へ」をクリックします。

      2. アラーム・タイプを選択して、「次へ」をクリックします。

      3. 動的クラスタがある場合、「スケーリング・アクション」「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      4. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

    • イベント・データの場合:

      1. ポリシーのルールを作成するための式を追加します。その後、「次へ」をクリックします。

      2. アラーム・タイプを選択して、「次へ」をクリックします。

      3. 動的クラスタがある場合、「スケーリング・アクション」「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      4. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

    • サーバー・ログの場合:

      1. ポリシーのルールを作成するための式を追加します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成します。その後、「次へ」をクリックします。

      2. アラーム・タイプを選択して、「次へ」をクリックします。

      3. 動的クラスタがある場合、「スケーリング・アクション」「アクションのスケール・アップ」または「アクションのスケール・ダウン」のいずれかを選択します。

      4. 「診断アクション」でアクションを「使用可能」列から「選択済」列に移動します。

  9. 「作成」をクリックします。

ポリシーの作成の詳細は、『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』診断システム・モジュール用のポリシーの作成に関する項を参照してください。

問題の調査、報告および解決

WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent (RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決できます。

初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。

問題の調査、レポートおよび解決のロードマップ

一般的に、問題の調査、報告および解決は、クリティカル・エラーの発生から始まります。この項では、そのワークフローの概要について説明します。

図13-4は、問題を調査、報告および解決するためのタスクを示しています。

図13-4 問題調査のフロー

図13-4の説明が続きます
「図13-4 問題調査のフロー」の説明

次に、図13-4に示しているワークフローについて説明します。

  1. システム、コンポーネントまたはアプリケーションが想定どおりに機能していないことがわかります。たとえば、パフォーマンスに問題があることがわかったり、アクセスしようとしているアプリケーションでエラーが報告されているとユーザーから報告があった場合などです。

  2. 観察された症状に関連する可能性のある問題およびインシデントが作成されているかどうかを確認します。

    1. 一連の問題を確認するには、「問題の確認」の説明に従って、WLSTのlistProblemsコマンドを使用します。

    2. 問題が作成されている場合、「インシデントの確認」の説明に従って、listIncidentsコマンドを使用して、特定の問題に関連するインシデントを一覧表示します。

  3. インシデントが作成されていない場合は、ステップ4に進みます。インシデントが作成されている場合は、ステップ5に進みます。

  4. 問題に関連しているインシデントを確認できない場合は、createIncidentコマンドを使用してインシデントを手動で作成し、問題の診断情報を取得することができます。

    ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要がある場合は、インシデントを作成することを検討してください。ログ・ファイルとその中のメッセージを表示できます。直面している問題に関連すると思われるメッセージがあったら、createIncidentコマンドでそのメッセージIDを使用できます。

    インシデントの作成の詳細は、「インシデントの手動作成」を参照してください。

  5. 特定のインシデントの詳細を確認するには、「インシデントの確認」の説明に従って、showIncidentコマンドを使用します。このコマンドを実行すると、関連するメッセージID、インシデントの時刻、ECID、インシデントで生成されたファイルなど、インシデントに関する情報が一覧表示されます。

  6. 「インシデントの確認」の説明に従って、getIncidentFileコマンドを使用して、インシデントのファイルの内容を確認します。その内容には、問題の原因を導き出し、その解決に役立つ情報が含まれる可能性があります。

  7. インシデントのファイルの内容が問題の解決に役立たなかった場合、追加のダンプを実行して詳細な診断情報を確認できます。たとえば、パフォーマンスの問題に直面した場合は、dms.metricsダンプを実行します。使用可能なダンプおよびその実行方法の詳細は、「診断ダンプの処理」を参照してください。

  8. それでも問題が解決できない場合は、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 Apr 28 11:05:59 PDT 2017    MDS-50500 [MANUAL]
        1       Fri Apr 28 11:02:22 PDT 2017    MDS-50500 [MANUAL]

特定の問題に関連するインシデントを確認するには、次のコマンドを使用します。

listIncidents(id='1')
Incident Id     Incident Time                   Problem Key
        2       Fri Apr 28 11:05:59 PDT 2017    MDS-50500 [MANUAL]
        1       Fri Apr 28 11:02:22 PDT 2017    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 Apr 28 11:02:22 PDT 2017
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")

次の例では、2017年3月1日と2017年3月15日の間に発生したすべてのインシデントに対して、サーバーwls_server_1を問い合せています。

 queryIncidents(query="TIMESTAMP from '2017-03-01 00:00'AND TIMESTAMP to '2017-03-15 00:00'", 
servers=["wls_server_1"])

このコマンドの完全な構文については、『インフラストラクチャ・コンポーネント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)メトリック。これらのメトリックについては、『パフォーマンスのチューニング』ダイナミック・モニタリング・サービス(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 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 Apr 28:00:00 PDT 2017
    
    <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  04-28-17 07:25   dfw_samplingArchive1065570966467923683.JVMThreadDump.dmp
          840  04-28-17 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

完全な構文については、『インフラストラクチャ・コンポーネント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

完全な構文については、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』updateDumpSampleに関する項を参照してください。

ダンプ・サンプリングの削除

WLSTコマンドremoveDumpSampleを使用することにより、既存のダンプ・サンプリングを削除できます。removeDumpSampleコマンドでは、次の構文を使用します。

removeDumpSample(sampleName="sample_name", [server="server_name"])

たとえば、ダンプ・サンプリングHTTPSamplingを削除するには、次のように指定します。

removeDumpSample(sampleName="HTTPSampling", server="wls_server1")

Removed HTTPSampling

完全な構文については、『インフラストラクチャ・コンポーネント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"])

完全な構文については、『インフラストラクチャ・コンポーネント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    : 

完全な構文については、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』listDumpSampleに関する項を参照してください。

ダンプ・サンプリング出力の取得

ダンプ・サンプルの出力を取得するには、次の各項で説明するように、WLSTコマンドexecuteDumpまたはgetSamplingArchivesを使用します。

executeDumpコマンドを使用したダンプ・サンプルの取得

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'})

このコマンドの完全な構文については、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』executeDumpに関する項を参照してください。

getSamplingArchivesコマンドを使用したダンプ・サンプルの取得

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-28-17 11:19   dfw_samplingArchive8680976839106379444.JavaClassHistogram.dmp
      552  04-28-17 11:19   dfw_samplingArchive7861027727509995202.readme.txt
 --------                   -------
  6242320                   2 files

完全な構文については、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』getSamplingArchivesに関する項を参照してください。

インシデントの管理

診断フレームワークでは、自動で作成されるか手動で作成されるかに関係なくインシデントが格納されますが、Oracle Fusion Middlewareには、インシデント・レポートの処理に役立ち、それらのインシデントをパッケージ化してOracleサポートに送信するツールが用意されています。次の項目について説明します。

インシデントの手動作成

システムで生成された問題(内部で生成されたクリティカル・エラー)は、自動診断リポジトリ(ADR)に自動的に追加されます。それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできます。また場合によっては問題を解決することもでき、これらはすべて、「問題の調査、報告および解決」で説明されているワークフローに記載されています。

ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要があるものの、診断フレームワークでインシデントが自動的に作成されていない場合は、インシデントを手動で作成することを検討してください。

インシデントを手動で作成するには、WLSTコマンドのcreateIncidentを使用します。インシデントは、時間、メッセージID、影響領域またはECIDを基準に指定できます。ここで、インシデントの内容を調べたり、Oracleサポートに送信してさらなる分析を依頼することができます。

たとえば、メッセージIDに基づいてインシデントを手動で作成する手順は、次のとおりです。

  1. 「ログ・ファイルの検索」の説明に従って、ログ・ファイルを検索します。直面している問題に関連すると疑われるメッセージがあったら、インシデントを作成するときにそのメッセージIDを使用できます。
  2. 次のコマンドを使用してWLSTを起動し、管理対象サーバーに接続して、管理対象サーバー・インスタンスにナビゲートします。
    java weblogic.WLST
    connect('username', 'password', 'localhost:7001')
    cd('servers/server_name')
    
  3. 次の形式でcreateIncidentコマンドを使用して、インシデントを作成します。
    createIncident([adrHome] [,incidentTime] [,messageId] [,ecid] [,appName]
      [,description] [,server])
    

    たとえば、メッセージIDがMDS-50500のエラーを基準としてインシデントを作成するには、次のコマンドを使用してメッセージIDを指定し、ユーザーおよびOracleサポートがインシデントを追跡しやすいように、インシデントの説明を入力します。

    createIncident(messageId='MDS-50500', description='sample incident')
    Incident Id: 1
    Problem Id: 1
    Problem Key: MDS-50500 [MANUAL]
    Incident Time:Fri Apr 28 11:02:22 PDT 2017
    Error Message Id: MDS-50500
    Execution Context:null
    Flood Controlled: false
    Dump Files :
       jvm_threads10_i1.txt
       dms_metrics11_i1.txt
       dfw_samplingArchive13_i1.JVMThreadDump.txt
       dfw_samplingArchive13_i1.readme.txt
       odl_logs14_i1.txt
    

    サーバーを指定しないと、インシデントは接続されているサーバーから情報を収集します。サーバーを指定するには、次の例に示すようにserverオプションを使用します。

    createIncident(messageId='MDS-50500', description='sample incident', server='wls_server1')
    )

    adrHomeオプションを指定しないと、インシデントは接続されているサーバーに作成されます。たとえば、管理サーバーに接続している場合、インシデントは管理サーバーのadrHomeに作成されます。

    診断フレームワークはコマンドを評価して、適切な診断ダンプを起動します。インシデントおよび診断ダンプはADRに書き込まれます。それぞれの診断ダンプは、その出力結果をインシデントに書き込みます。

    「インシデントの確認」で説明するように、インシデントに関する情報を確認できます。

    「診断ダンプの処理」で説明するように、ダンプに情報を表示できます。

集計インシデントの作成

複数のインシデントがあり、それを1つのインシデントにまとめる場合は、WLSTのcreateAggregatedIncidentコマンドを使用できます。たとえば、選択的なトレースを使用した場合、トレース・データが含まれている結果のインシデントは複数のサーバーで生成される可能性があります。createAggregatedIncidentコマンドによって、指定する基準を満たす集計インシデントを生成できます。元のインシデントはそのままです。つまり、集計インシデントには問合せられたインシデントの複数のインシデント・ファイルのコピーが含まれています。

集計インシデントは管理サーバーのホストで作成されますが、これはドメイン内の1つ以上のサーバーまたはすべてのサーバーのインシデントを含むことができます。

インシデント属性、演算子、文字列が次の形式で含まれる式を使用して、問合せを作成できます。

attribute operator "string"

問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。

サポートされている属性と演算子の詳細は、『インフラストラクチャ・コンポーネント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 17 11:22:12 EDT 2017

ドメイン内のすべてのサーバー上で、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 17 11:22:12 EDT 2017
インシデントのパッケージ化

インシデントをパッケージ化して、その情報を容易にOracleサポートに送信できるようにするには、ADRコマンド・インタプリタ(ADRCI)を使用します。ADRCIユーティリティを使用すると、コマンド行環境で問題を調査および報告できます。ADRCIにより、インシデントおよび問題の情報をzipファイルにパッケージ化して、Oracleサポートに送信できます。

ADRCIコマンド行ユーティリティは次のディレクトリにあります。

(UNIX) ORACLE_HOME/oracle_common/adr 
(Windows) ORACLE_HOME\oracle_common\adr

インシデントのパッケージ化は、次の3つのプロセスに分かれています。

  1. 論理パッケージを作成します。

    このパッケージは、ADRではメタデータとしてのみ存在するため、論理的なものと示されます。インシデント・パッケージは、論理パッケージから物理パッケージを生成するまではコンテンツが含まれません。論理パッケージにはパッケージ番号が割り当てられますので、以降のコマンドではこの番号を使用してパッケージを参照します。

    論理パッケージは空のパッケージとして作成することも、インシデント番号、問題番号、問題キーまたは時間間隔に基づいたパッケージとして作成することもできます。パッケージを空のパッケージとして作成する場合は、ステップ2でパッケージに診断情報を追加できます。

    インシデントを基準にパッケージを作成すると、ダンプなど、そのインシデントの診断データが含まれることになります。問題番号または問題キーに基づいてパッケージを作成する場合は、パッケージにその問題番号または問題キーを参照するインシデントの診断データが含まれます。時間間隔に基づいてパッケージを作成する場合は、その時間間隔内で発生したインシデントに関する診断データが含まれます。

  2. 診断情報をパッケージに追加します。

    インシデント番号、問題番号、問題キーまたは時間間隔に基づいて論理パッケージを作成した場合、このステップはオプションとなります。パッケージにインシデントを追加したり、ADR内のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用してパッケージにインシデントまたはファイルを追加する必要があります。

  3. 物理パッケージを生成します。

    コマンドを送信して物理パッケージを生成するときに、ADRCIは必要なすべての診断ファイルを収集して、指定したディレクトリ内のZIPファイルに追加します。完全なZIPファイルまたは増分ZIPファイルを生成できます。増分ファイルには、同じ論理パッケージに対してZIPファイルが最後に作成されて以降に追加または変更された診断ファイルすべてが含まれます。増分ファイルは完全ファイルを作成した後にのみ作成でき、必要な数だけ作成できます。各ZIPファイルには順序番号が割り当てられるため、ファイルを正しい順序で分析できます。

    zipファイルは、次の形式に従って名前が付けられます。

    packageName_mode_sequence.zip
    

    この形式の各項目について説明します。

    • packageNameは、問題キーの一部にタイムスタンプが続きます。

    • modeは、COM(完全)またはINC(増分)です。

    • sequenceは整数です。

たとえば、インシデントをパッケージ化するには、次のステップを実行します。

  1. 次の例に示すように、ORACLE_HOMEおよびLD_LIBRARY_PATH環境変数を設定します。
    ORACLE_HOME=ORACLE_HOME/oracle_common
    LD_LIBRARY_PATH=ORACLE_HOME/oracle_common/adr
    
  2. ADRCIを起動します。次に例を示します。
    ORACLE_HOME/oracle_common/adr/adrci
    
  3. SET BASEコマンドを使用してADRベースを指定し、SET HOMEPATHコマンドを使用してインシデントを含むADRホームを指定します。HOMEPATHのパスは、ADRベースを基準に指定します。
    SET BASE /scratch/oracle/config/domains/wls_domain/servers/wls_server1/adr
    SET HOMEPATH diag/ofm/wls_domain/wls_server1
    
  4. 論理パッケージを生成します。
    IPS CREATE PACKAGE INCIDENT incident_number
    

    たとえば、次のコマンドを実行すると、インシデント1を基準にパッケージが作成されます。

    IPS CREATE PACKAGE INCIDENT 1
    Created package 1 based on incident id 1, correlation level typical
    

    ADRCIにより、論理パッケージに番号が割り当てられます。

  5. オプションで、論理パッケージに診断情報を追加できます。次のタイプの情報を追加できます。
    • 特定のインシデントのすべての診断情報。たとえば、次のコマンドを使用して、パッケージ化したインシデントに関連すると思われる別のインシデントを追加できます。

      IPS ADD INCIDENT incident_number PACKAGE package_number
      
    • ADR内にある、名前が付けられたファイル。たとえば、インシデントがアプリケーションに関連する場合、そのアプリケーションに対する.earファイルを追加できます。また、ユーザーがOracleサポートに通知するメモを記したreadmeファイルを追加することもできます。たとえば、パッケージにファイルを追加するには、次のコマンドを使用します。

      IPS ADD FILE filespec PACKAGE package_number
      
  6. 次のコマンドを使用して、物理パッケージを生成します。
    IPS GENERATE PACKAGE package_number IN path
    

    たとえば、番号1のパッケージを生成するには、次のコマンドを使用します。

    IPS GENERATE PACKAGE 1 in /tmp 
    Generated package 1 in file /tmp/BEA337Web_20100223132315_COM_1.zip, mode complete
    

    これは、指定したパスに完全な物理パッケージ(ZIPファイル)を生成します。

    ADRCIの詳細は、『Oracle Databaseユーティリティ』ADRCI: ADRコマンド・インタプリタに関する項を参照してください。

インシデントのパージ

デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、「診断フレームワークの設定の構成」で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。

ADRCIコマンドを使用して、インシデントを手動でパージできます。パージは、IDまたはIDの範囲、インシデントの経過時間、またはインシデントのタイプを基準にして行えます。たとえば、経過時間が60分を超えたインシデントをパージするには、次のコマンドを使用します。

purge -age 60 

『Oracle Databaseユーティリティ』「ADRCI: ADRコマンド・インタプリタ」を参照してください。

RDAレポートの生成

コマンド行診断ツールのRemote Diagnostic Agent (RDA)を使用して、ご使用の環境の全体像を把握することができます。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。

RDAは、エンジンにより実行される、Perlプログラミング言語で作成される一連のコマンド行診断スクリプトです。RDAはOracle環境に関する詳細情報の収集に使用され、収集されたデータは次に問題診断の支援に使用されます。また、その出力は全体的なシステム構成を確認するのに役立ちます。

RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。

RDAは次の領域の問題のトラブルシューティングに役立つ情報を収集します。

  • インストールおよび構成

  • パフォーマンス

  • ORA-600エラー、ORA-7445エラー、ORA-3113エラーおよびORA-4031エラー

  • アップグレード、移行およびリンク

  • Oracleデータベース

  • 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