ヘッダーをスキップ
Oracle® Fusion Middleware管理者ガイド
11g リリース1 (11.1.1)
B60984-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

13 問題の診断

この章では、問題を解決したり、解決のためにOracleサポートに送信したりできるように、Oracle Fusion Middleware診断フレームワークを使用して問題に関する情報の収集および管理をする方法について説明します。

この章の項目は次のとおりです。

13.1 診断フレームワークの概要

Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが含まれています。特に対象としている問題は、コードのバグ、メタデータの破損、顧客データの破損、スレッドのデッドロック、一貫性のない状態に起因する障害などのクリティカル・エラーです。

クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断ログ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。

診断フレームワークの目標は、次のとおりです。

診断フレームワークに組み込まれているテクノロジは次のとおりです。

13.1.1 インシデントと問題について

クリティカル・エラーを円滑に診断および解決するために、診断フレームワークには、問題とインシデントという、Oracle Fusion Middlewareの2つの概念が導入されています。

問題とは、クリティカル・エラーです。クリティカル・エラーは、内部エラーなどのサーバー・エラーとして発生します。問題はADRで追跡されます。それぞれの問題には問題キーがあります。これは、問題を記述したテキスト文字列です。これには、エラー・コード(XXX-nnnnnという形式)と、場合によってはエラー固有の他の値が含まれます。

インシデントとは、1回の問題発生情報です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。それぞれのインシデントは数字のインシデントIDで識別されます。このインシデントIDは、ADRホーム内で一意です。インシデントが発生すると、診断フレームワークでは次の処理を実行します。

  • インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。

  • そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。

  • インシデント・ダンプをインシデントとともにADRに登録します。

13.1.1.1 インシデントのフラッド制御

問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。そのため、診断フレームワークでは、特定のしきい値に達したときにインシデントの生成に対してフラッド制御を適用します。フラッド制御インシデントは、ADRに記録されないインシデントです。かわりに、診断フレームワークによって、WARNINGレベルのメッセージがログ・ファイルに書き込まれ、oracle.dfw.incident.Incidentオブジェクトが返されます。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。

デフォルトでは、問題キーが同じインシデントが60分以内に6件以上発生すると、それ以降、問題キーが同じインシデントはフラッド制御されます。この値はMBeanを使用して変更できます(第13.3項を参照)。

13.1.2 診断フレームワークのコンポーネント

次の各項目で、診断フレームワークの主要コンポーネントについて説明します。

13.1.2.1 自動診断リポジトリ

自動診断リポジトリ(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は名前の一部を切り捨てます。また、ドル記号($)と空白文字はアンダースコアに置き換えられます。


13.1.2.2 診断ダンプ

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

13.1.2.3 管理MBean

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

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

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

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

13.1.2.5 ADRCIコマンドライン・ユーティリティ

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

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

(UNIX) MW_HOME/wlserver_10.3/server/adr
(Windows) MW_HOME\wlserver_10.3\server\adr

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


関連項目:

  • Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」

  • Oracle Database管理者ガイド』の「診断データの管理」


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

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

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

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

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

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

図13-2で示されている手順は、次のとおりです。

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

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

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

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

  5. ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をOracle WebCenter Portalに戻します。

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

    [2010-09-16T06:37:59.264-07:00] [dfw] [NOTIFICATION] [DFW-40104] [oracle.dfw]
    [tid: 10] [ecid: 0000IF34gtMC8xT6uBf9EH1AgEck000000,0] [errid: 6] 
    [detailLoc: /middleware/user_projects/base_domain/servers/AdminServer/adr/diag/ofm/base_domain/AdminServer] 
    [probKey: MDS-123456 [testComponent][testModule]] incident 6 created with
     problem key "MDS-123456 [testComponent][testModule]", in directory
     /middleware/user_projects/base_domain/servers/AdminServer/adr/diag/ofm/base_domain/AdminServer/incident/incdir_6
    
  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に診断イメージを書き込みます。

13.3 診断フレームワークの構成

診断フレームワークの一部の設定を構成できます。また、インシデントを作成するようにWLDF監視および通知を構成することもできます。次の各項目で、診断フレームワークを構成する方法を説明します。

13.3.1 診断フレームワークの設定の構成

次の設定を構成できます。

  • ログ・ファイルを使用したインシデントの検出の有効化または無効化

  • フラッド制御およびフラッド制御のパラメータ設定の有効化または無効化

これらの設定を構成するには、診断フレームワークMBean DiagnosticConfigを使用します。次に、MBeanのObjectNameを示します。

oracle.dfw:type=oracle.dfw.jmx.DiagnosticsConfigMBean,name=DiagnosticsConfig 

表13-1は、DiagnosticConfig MBeanの属性と各パラメータの説明を示しています。

表13-1 診断フレームワークのDiagnosticConfig MBeanの属性

属性 説明

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ドメイン」を開きます。

  2. ドメインを選択します。

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

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

  4. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  5. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  6. 「アプリケーション定義のMBean」ペインで「MBean情報の表示」を開くと、サーバー名が表示されます。

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

    dfw_config.gifの説明が続きます
    図dfw_config.gifの説明

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

  8. 適用」をクリックします。

13.3.2 問題抑制の構成

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

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

問題抑制フィルタを構成する場合は、マッチするパターンを表す正規表現を使用します。java.util.regexクラスを使用して、正規表現とのマッチが行われます。次に例を示します。

  • 次の正規表現では、インシデントがMDS-5000で始まる問題キーとマッチされます。

    MDS-5000.*
    
  • 次の正規表現は、テキストOutOfMemoryを含む問題とマッチします。正規表現では大/小文字が区別されるため、テキストoutofmemoryを含む問題とはマッチしません。

    .*OutOfMemory.*
    

DiagnosticConfig MBeanを使用すると、フィルタを追加および削除したり、フィルタ・リストまたは1つのフィルタの詳細を取得できます。

表13-2は、構成中の問題抑制フィルタの操作および属性とそれぞれの説明を示しています。

表13-2 問題抑制フィルタのDiagnosticConfig MBeanの操作および属性

操作および属性 説明

操作:

addProblemKeyFilter(filter_pattern)

新しい問題抑制フィルタを追加します。マッチするパターンを表す正規表現に渡します。次に例を示します。

addProblemKeyFilter(".*OutOfMemory.*)

属性:

getProblemKeyFilters()

構成済されている問題抑制フィルタのリストを返します。次に例を示します。

getProblemKeyFilters()

操作:

getProblemKeyFilter(filterID)

特定IDに関連するフィルタ・パターンを返します。次に例を示します。

getProblemKeyFilter(id)

IDを検索するには、getProblemKeyFilters()操作を使用します。

操作:

removeProblemKeyFilter(filterID)

任意のフィルタIDに関連するフィルタ・パターンを削除します。次に例を示します。

removeProblemKeyFilter(id)

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

  1. Fusion Middleware Controlのターゲット・ナビゲーション・ペインで、ファームを開いてから、「WebLogicドメイン」を開きます。

  2. ドメインを選択します。

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

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

  4. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  5. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  6. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。

  7. addProblemKeyFilterをクリックします。操作: addProblemKeyFilterページが、次の図のように表示されます。

    problemkeyfilter.gifの説明が続きます
    図problemkeyfilter.gifの説明

  8. 「値」に、マッチするパターンを表す正規表現を入力します。たとえば、開発環境では、java.lang.IllegalStateExceptionというJava例外が報告されたときにインシデントが作成されないようにフィルタを追加する必要がある場合があります。この場合、次のように入力します。

    ".*[java.lang.IllegalStateException].*"
    
  9. 起動」をクリックします。

  10. 「戻る」をクリックし、「アプリケーション定義のMBean」ページに戻ります。

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

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

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

  1. ターゲット・ナビゲーション・ペインで、ファームを開いてから、「WebLogicドメイン」を開きます。

  2. ドメインを選択します。

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

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

  4. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

  5. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

  6. 「アプリケーション定義のMBean」ペインで、「属性」タブを選択します。

  7. ProblemKeyFiltersをクリックします。

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

13.3.3 診断フレームワーク用のWLDF監視および通知の構成

Fusion Middlewareでは、監視および通知の一連のルールが含まれているWLDF診断モジュールを構成します。そのルールは、特定の一連のクリティカル・エラーを検出し、それらのエラーが発生するたびにインシデントを作成するためのものです。このモジュールはモジュールFMWDFWと呼ばれ、次の一連の監視条件が含まれます。

名前 説明

Deadlock

複数のJavaスレッドで、Java Monitorオブジェクトを使用する際に循環ロック・チェーンがあります。

StuckThread

Oracle WebLogic ServerのExecuteThread。Oracle WebLogic ServerのStuckThreadMaxTimeパラメータで指定された時間より多くの期間、ブロックされているかビジー状態です。

UncheckedException

このカテゴリには、未チェックの例外、実行時の例外、およびNullPointerException、StackOverflowError、OutOfMemoryErrorなどのOracle WebLogic ServerのExecuteThreadで捕捉されたエラーがすべて含まれます。


診断モジュールには、oracle.dfw.wldfnotificationタイプの、構成されたWLDF JMX通知FMWDFW-notificationも含まれます。このWLDF JMX通知は、インシデントを作成するために、独自のWLDF監視条件で再利用することもできます。

  1. 第3.4.1項の説明に従って、管理コンソールを表示します。

  2. チェンジ・センターで、「ロックして編集」をクリックします。

  3. 左ペインで、「診断」を開き、「診断モジュール」を選択します。

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

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

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

  5. 次の図に示す「監視と通知」タブを選択します。

    dfw_notif.gifの説明が続きます
    図dfw_notif.gifの説明

  6. 「監視」タブを選択し、「新規」をクリックします。

    「監視の作成」ページが表示されます。

  7. 名前」に、監視の名前を入力します。

    任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージIDが使用されるようにすることができます。

    message-id#[application_name]#any_text
    

    メッセージIDは、1から6文字の接頭辞と1から6桁の数字で構成されます。アプリケーション名はオプションです。次に例を示します。

    SOA-40500#My_Watch_Name
    

    次の例では、アプリケーション名soa_infraを使用しています。

    SOA-40501#soa-infra#My_Watch_Name
    

    診断フレームワークでは、インシデント問題キーの構成時にメッセージIDをインシデント・メッセージIDとして使用します。

  8. 「監視のタイプ」で、タイプを選択します(「サーバー・ログ」など)。

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

  10. 現在の監視ルール」で式を作成します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成する手順は、次のとおりです。

    1. 「式の追加」をクリックします。

    2. 「メッセージ属性」で、「重大度」を選択します。

    3. 「演算子」で、=を選択します。

    4. 「値」に、ERRORと入力します。

    5. OK」をクリックします。

    6. 「式の追加」をクリックします。

    7. 「メッセージ属性」で、MSGIDを選択します。

    8. 「演算子」で、=を選択します。

    9. 「値」に、BEA-000337と入力します。

    10. OK」をクリックします。

    11. 「監視の作成」ページで、選択されている演算子がANDであることを確認します。

    12. OK」をクリックします。

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

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

  13. 通知」で、FMWDFW-notificationを選択し、これを「選択済み」ボックスに移動します。

  14. 終了」をクリックします。

監視の作成の詳細は、管理コンソールのオンライン・ヘルプの監視ルールの式の作成に関する項を参照してください。

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

この項では、WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent(RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決する方法について説明します。初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。

13.4.1 ロードマップ—問題の調査、報告および解決

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

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

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

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

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

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

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

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

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

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

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

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

    インシデントの作成の詳細は、第13.4.5.1項を参照してください。

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

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

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

  8. それでも問題が解決できない場合は、RDAレポートとともにインシデントをパッケージ化して、Oracleサポートにお送りください。インシデントのパッケージ化およびRDAレポートの生成の詳細は、第13.4.5.2項および第13.4.6項を参照してください。

13.4.2 問題およびインシデントの確認

次の各項で説明するように、WLSTコマンドライン・ユーティリティを使用して、一連の問題、インシデントのリスト、および特定のインシデントの詳細を確認できます。

13.4.2.1 問題の確認

一連の問題を確認するには、次の形式でWLSTのlistProblemsコマンドを実行します。

listProblems([adrHome] [,server])

listProblemsコマンドを実行すると、ADRホームの問題が一覧表示されます。それぞれの問題では、IDが一意です。

listProblems()
Problem Id      Problem Key
        1       BEA-101020 [HTTP]

13.4.2.2 インシデントの確認

次の形式でWLSTのlistIncidentsコマンドを実行して、すべての使用可能なインシデントまたは特定の問題に関連するインシデントをリストできます。

listIncidents([id], [ADRHome])

たとえば、すべてのインシデントのリストを表示するには、次のコマンドを使用します。

listIncidents()
Incident Id     Problem Key              Incident Time
        2       BEA-101020 [HTTP]        Fri Feb 26 13:42:01 PDT 2010
        1       BEA-101020 [HTTP]        Tue Feb 23 06:17:39 PDT 2010

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

listIncidents(id='1')
Incident Id     Problem Key              Incident Time
        2       BEA-101020 [HTTP]        Fri Feb 26 13:42:01 PDT 2010
        1       BEA-101020 [HTTP]        Tue Feb 23 06:17:39 PDT 2010

特定のインシデントの詳細を確認するには、次の形式でWLSTのshowIncidentコマンドを使用します。

showIncident(id, [adrHome] [,server])

たとえば、インシデント1の詳細を確認するには、次のコマンドを使用します。

showIncident(id='1')
Incident Id: 1
Problem Id: 1
Problem Key: BEA-101020 [HTTP]
Incident Time: Tue  Feb 23 06:17:39 PDT 2010
Error Message Id:  BEA-101020
Execution Context: 0000IExqUvyAhKB5JZ4Eyf1Afdj600009i
Flood Controlled: false
Dump Files :
    dms_ecidctx1_i1.dmp
    jvm_threads2_i1.dmp
    dms_metrics3_i1.dmp
    odl_logs4_i1.dmp
    odl_logs5_i1.dmp
    diagnostic_image_AdminServer_2010_02_23_06_17_42.zip
    readme.txt

インシデントのファイルの内容を確認するには、次の形式でWLSTのgetIncidentFileコマンドを使用します。

getIncidentFile(id, name [,outputFile] [,adrHome] [,server])

たとえば、ファイルodl_logs4_i1.dmpの内容を確認するには、次のコマンドを使用します。

getIncidentFile(id='1', name='odl_logs4_i1.dmp', outputFile='/tmp/odl_logs4_i1_dmp.output')

このコマンドは、出力をファイルodl_logs4_i1_dmp.outputに書き込みます。

13.4.3特定の問題キーの分析

診断フレームワークは、未処理の例外について明確に定義された一連の問題キーを提供します。これらの例外は、既存のWLDF監視のUncheckedException、または診断フレームワークのjava.lang.Thread.UncaughtExceptionHandlerという捕えられていない例外ハンドラのいずれかによって検出されます。これまで、診断フレームワークは、同一タイプの問題に様々な形式で問題キーを生成していました。表13-3は、これらの問題キーとそれらを使用して問題を調査する方法について説明しています。

表13-3 捕えられていない例外の問題キー

例外 問題キー 説明

java.land.OutOfMemoryError

DFW-99997 [java.land.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など)で使用されます。

例外に関連付けられたテキストを確認し、障害の理由などの詳細を取得します。問題キーのソース行で障害の場所が示されている可能性があります。


13.4.4 診断ダンプの処理

問題が疑われる場合、組込みの診断ダンプを利用して、問題の診断に役立つ詳細な診断結果を報告できます。診断ダンプは、診断データを出力および記録する手段を提供します。診断データは、Oracle Fusion Middlewareのコンポーネント、アプリケーションおよびインフラストラクチャに関する問題を診断する際に有益な情報になります。これらのダンプからの出力は、Oracle Fusion Middlewareに関する問題を診断するために、顧客およびOracleサポートが使用することを想定しています。

診断ダンプは、次のように実行します。

  • 手動。次の各項で説明するように、WLSTコマンドを使用します。

    たとえば、Java EEアプリケーションがハングしてデッドロックが疑われる場合には、jvm.threadsダンプを使用して一連のスレッドを取得できます。

  • 自動。診断フレームワークがクリティカル・エラーを検出してインシデントを作成した場合、または管理者がインシデントを作成した場合。

13.4.4.1 診断ダンプの一覧表示

管理対象サーバーで使用可能な診断ダンプのリストを検索するには、次の形式でWLSTのlistDumpsコマンドを実行します。

listDumps([appName] [,server])

たとえば、soa_server1で使用可能なダンプを一覧表示するには、次のコマンドを使用します。

listDumps(server='soa_server1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root. 
For more help, use help(domainRuntime)

odl.activeLogConfig
jvm.classhistogram
dms.ecidctx
wls.image
odl.logs
dms.metrics
odl.quicktrace
http.requests
jvm.threads

Use the command describeDump(name=<dumpName>) for help on a specific dump.

表13-4は、Oracle Fusion Middlewareで定義される診断ダンプ操作とその説明を記載したものです。

表13-4 診断ダンプ操作

ダンプ操作 説明

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で実行中のスレッド、および完全なスレッド・ダンプを実行中のスレッドに関する統計サマリー。

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コンポジット・アプリケーションを使用した問題の診断に関する説明の説明に従って、診断ダンプが提供されます。

13.4.4.2 診断ダンプの説明の表示

WLSTのdescribeDumpコマンドを使用して、ダンプを実行する際の構文など、特定のダンプの説明を表示できます。目的のダンプの名前を指定します。たとえば、dms.metricsダンプの説明を表示するには、次のコマンドを使用します。

describeDump(name='dms.metrics')
Name: dms.metrics
Description: Dumps DMS (Dynamic Monitoring Service) metrics.
Mandatory Arguments: 
Optional Arguments:
    Name        Type     Description
    format      STRING   Format of the dump output; raw or xml

13.4.4.3 ダンプの実行

問題を検出して追加の診断データを収集する場合、指定したダンプに対してexecuteDumpコマンドを起動します。それぞれのダンプには、必須またはオプション、あるいはその両方の引数があります。特定のダンプの引数やその指定方法を確認するには、第13.4.4.2項の説明に従って、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が含まれます。

13.4.5 インシデントの管理

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

13.4.5.1 インシデントの手動作成

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

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

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

次に、メッセージIDを基準としてインシデントを手動で作成する方法について説明します。

  1. 第12.3.2項の説明に従って、ログ・ファイルを検索します。直面している問題に関連すると疑われるメッセージがあったら、インシデントを作成するときにそのメッセージIDを使用できます。

  2. 次のコマンドを使用してWLSTを起動し、管理対象サーバーに接続して、管理対象サーバー・インスタンスにナビゲートします。

    java weblogic.WLST
    connect('weblogic', '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: 55
    Problem Id: 4
    Problem Key: MDS-50500 [MANUAL]
    Incident Time: 23rd February 2010 11:55:45 GMT
    Error Message Id: MDS-50500
    Flood Controlled: false
    

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

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

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

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

    第13.4.2.2項で説明するように、インシデントに関する情報を表示できます。

    第13.4.4項で説明するように、ダンプに情報を表示できます。

13.4.5.2 インシデントのパッケージ化

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

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

(UNIX) MW_HOME/wlserver_10.3/server/adr
(Windows) MW_HOME\wlserver_10.3\server\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を、次のディレクトリを指すように設定します。

    MW_HOME/wlserver_10.3/server/adr
    
  2. ADRCIを起動します。次に例を示します。

    MW_HOME/wlserver_10.3/server/adr/adrci
    
  3. SET BASEコマンドを使用してADRベースを指定し、SET HOMEPATHコマンドを使用してインシデントを含むADRホームを指定します。HOMEPATHのパスは、ADRベースを基準に指定します。

    SET BASE /scratch/oracle1/Oracle/Middleware/user_projects/domains/soa_domain/servers/soa_server1/adr
    SET HOMEPATH diag/ofm/soa_domain/soa_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ファイル)が生成されます。


関連項目:

Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」


13.4.5.3 インシデントのパージ

デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、第13.3.1項で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。

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

purge -age 60 

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

13.4.6 RDAレポートの生成

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

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

RDAの詳細は、次の場所にあるreadmeファイルを参照してください。

(UNIX) ORACLE_HOME/rda/README_Unix.txt
(Windows) ORACLE_HOME\rda\README_Windows.txt