この章では、問題を解決したり、解決のためにOracleサポートに送信したりできるように、Oracle Fusion Middleware診断フレームワークを使用して問題に関する情報の収集および管理をする方法について説明します。
この章の構成は、次のとおりです。
Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが含まれています。特に対象としている問題は、コードのバグ、メタデータの破損、顧客データの破損、スレッドのデッドロック、一貫性のない状態に起因する障害などのクリティカル・エラーです。
クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断ログ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。
診断フレームワークの目標は、次のとおりです。
初期障害の診断
問題が検出された後の損害および中断の抑制
問題の診断時間の短縮
問題の解決時間の短縮
顧客とOracleサポートのやり取りの簡略化
診断フレームワークに組み込まれているテクノロジは次のとおりです。
初期障害時の診断データの自動取得: クリティカルなエラーの場合、初期障害の段階でエラー情報を取得できると、問題が早期に解決され停止時間が短縮される可能性が大幅に増加します。診断フレームワークでは、スレッド・ダンプ、DMSメトリック・ダンプ、WebLogic診断フレームワーク(WLDF)のサーバー・イメージ・ダンプなどの診断情報を自動的に収集します。このような診断データは、飛行機のフライト・レコーダ「ブラック・ボックス」で収集されるデータに似ています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。データはファイルベース・リポジトリに格納され、コマンド行ユーティリティでアクセスできます。
標準化されたログ形式: (ODLログ・ファイル形式を使用して)Oracle Fusion Middlewareのすべてのコンポーネントにわたってログ形式が標準化されていると、管理者および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診断フレームワークの構成と使用』を参照してください。
クリティカル・エラーを円滑に診断および解決するために、診断フレームワークには、問題とインシデントという、Oracle Fusion Middlewareの2つの概念が導入されています。
問題とは、クリティカル・エラーです。クリティカル・エラーは、内部エラーなどのサーバー・エラーとして発生します。問題はADRで追跡されます。それぞれの問題には問題キーがあります。これは、問題を記述したテキスト文字列です。これには、エラー・コード(XXX-nnnnnという形式)と、場合によってはエラー固有の他の値が含まれます。
インシデントとは、1回の問題発生情報です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。それぞれのインシデントは数字のインシデントIDで識別されます。このインシデントIDは、ADRホーム内で一意です。インシデントが発生すると、診断フレームワークでは次の処理を実行します。
インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。
そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。
インシデント・ダンプをインシデントとともにADRに登録します。
問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。そのため、診断フレームワークでは、特定のしきい値に達したときにインシデントの生成に対してフラッド制御を適用します。フラッド制御インシデントは、ADRに記録されないインシデントです。かわりに、診断フレームワークによって、WARNINGレベルのメッセージがログ・ファイルに書き込まれ、oracle.dfw.incident.Incidentオブジェクトが返されます。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。
デフォルトでは、問題キーが同じインシデントが60分以内に6件以上発生すると、それ以降、問題キーが同じインシデントはフラッド制御されます。この値はMBeanを使用して変更できます(第13.3項を参照)。
次の各項目で、診断フレームワークの主要コンポーネントについて説明します。
自動診断リポジトリ(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を使用して診断フレームワークを構成する方法の詳細は、第13.3項を参照してください。
また、MBeanを使用すると、インシデントの問合せおよび作成を行ったり、使用可能な診断ダンプ・タイプのリストを検索したり、個々の診断ダンプを実行することができます。
診断フレームワークには、問題およびインシデントに関する情報の表示、インシデントの作成、特定のダンプの実行および一連の診断ダンプ・タイプの問合せに使用できるWLSTコマンドが用意されています。詳細は、次を参照してください。
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスの診断フレームワークのカスタムWLSTコマンドに関する項
診断フレームワークのカスタムWLSTコマンドを使用するには、Oracle共通ホームからWLSTスクリプトを起動する必要があります。詳細は、第3.5.1.1項を参照してください。
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 Fusion Middlewareのコンポーネントおよびアプリケーションは、常に監視対象となるため、自動的に診断フレームワークの恩恵を受けることになります。
インシデントは、次の2つの方法で自動的に検出されます。
インシデント検出ログ・フィルタ。クリティカル・エラーを検出するように自動的に構成されます。
WLDF監視および通知コンポーネント。診断フレームワークでは、事前定義された通知タイプをリスニングし、そのような通知を受信したときにインシデントを作成します。
WLDF監視および通知の構成の詳細は、第13.3.4項を参照してください。
プログラムによるインシデント作成。一部のコンポーネントでは、インシデントを直接作成します。
図13-2は、インシデント・ログ検出でインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント・ログ検出でインシデントが検出されたときの、インシデント・ログ検出、WLDF診断イメージMBean、ADR、およびコンポーネントまたはアプリケーションのダンプの間のやり取りを示しています。
図13-2で示されている手順は、次のとおりです。
インシデント検出ログ・フィルタは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。
アプリケーションまたはコンポーネント(ここではOracle WebCenter Portal)は、java.util.logging APIを使用して、メッセージをログに記録します。
ODLログ・ハンドラは、メッセージをインシデント検出ログ・フィルタに渡します。
インシデント・ログ検出フィルタは、ログ・メッセージを検証し、コンポーネントの診断ルールに基づいて、インシデントを作成するかどうかを判断します。診断ルールによりインシデントを作成する必要があると示された場合、ADRにインシデントが作成されます。
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: /oracle/config/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 /oracle/config/base_domain/servers/AdminServer/adr/diag/ofm/base_domain/AdminServer/incident/incdir_6
診断フレームワークは、コンポーネントの診断ルールで示される診断ダンプを実行します。
診断フレームワークは、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の属性
次の例は、Fusion Middleware ControlシステムMBeanブラウザを使用してこれらの設定を構成する方法を示しています。
ターゲット・ナビゲーション・ペインで、ファームを開いてから、「WebLogicドメイン」を開きます。
ドメインを選択します。
「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。
アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。
DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
「アプリケーション定義のMBean」ペインで「MBean情報の表示」を開くと、サーバー名が表示されます。
次に、「システムMBeanブラウザ」ページを示します。
表13-1に一覧表示されている属性の値を変更するには、「値」フィールドで値を入力または選択します。
「適用」をクリックします。
ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム診断ルールを構成できます。
カスタム診断ルールは、特定の形式の.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 |
引数のタイプ。
|
カスタム診断ルールを作成してロードする手順は次のとおりです。
カスタム・ルールを含むファイルを作成します。
サンプル・カスタム・ルール・ファイルを次に示します。
<?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>
拡張子.xmlを含む名前を付けて、ファイルを保存します。ルールがアプリケーションに適用される場合は、ファイル名の前にapp_name
#
を付けます。ファイルを次のいずれかの場所に保存します。
DOMAIN_HOME/config/fmwconfig/dfw DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw
WLSTコマンドreloadCustomRulesを使用して、ルールをロードします。次の例は、myAppアプリケーションに適用されるcustomrules.xmlルールをロードします。
reloadCustomRules(name='myApp#customrules.xml')
ドメイン内のすべてのルール、または特定のサーバーに関連するすべてのルールを再ロードできます。次の例は、soa_server1サーバーに対するすべてのルールを再ロードします。
reloadCustomRules(server='soaserver1')
reloadCustomRulesコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「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)
|
問題抑制フィルタを構成する手順は次のとおりです。
Fusion Middleware Controlのターゲット・ナビゲーション・ペインで、ファームを開いてから、「WebLogicドメイン」を開きます。
ドメインを選択します。
「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。
アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。
DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。
addProblemKeyFilterをクリックします。操作: addProblemKeyFilterページが、次の図のように表示されます。
「値」に、マッチするパターンを表す正規表現を入力します。たとえば、開発環境では、java.lang.IllegalStateExceptionというJava例外が報告されたときにインシデントが作成されないようにフィルタを追加する必要がある場合があります。この場合、次のように入力します。
".*[java.lang.IllegalStateException].*"
「起動」をクリックします。
「戻る」をクリックし、「アプリケーション定義のMBean」ページに戻ります。
removeProblemKeyFilter操作を使用すると、フィルタを削除できます。
getProblemKeyFilter操作にフィルタIDを渡すと、特定のフィルタを取得できます。
また、次のようにgetProblemKeyFilters属性を使用すると、フィルタのリストを取得できます。
ターゲット・ナビゲーション・ペインで、ファームを開いてから、「WebLogicドメイン」を開きます。
ドメインを選択します。
「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。
アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。
DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。
「アプリケーション定義のMBean」ペインで、「属性」タブを選択します。
ProblemKeyFiltersをクリックします。
問題抑制フィルタのリストが表示されます。
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監視条件で再利用することもできます。
第3.4.1項の説明に従って、管理コンソールを表示します。
チェンジ・センターで、「ロックして編集」をクリックします。
左ペインで、「診断」を開き、「診断モジュール」を選択します。
「診断モジュールのサマリー」ページが表示されます。
「Module-FMWDFW」をクリックします。
「Module-FMWDFWの設定」ページが表示されます。
次の図に示す「監視と通知」タブを選択します。
「監視」タブを選択し、「新規」をクリックします。
「監視の作成」ページが表示されます。
「名前」に、監視の名前を入力します。
任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージ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として使用します。
「監視のタイプ」で、タイプを選択します(「サーバー・ログ」など)。
「次へ」をクリックします。
「現在の監視ルール」で式を作成します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成する手順は、次のとおりです。
「式の追加」をクリックします。
「メッセージ属性」で、「重大度」を選択します。
「演算子」で、=を選択します。
「値」に、ERRORと入力します。
「OK」をクリックします。
「式の追加」をクリックします。
「メッセージ属性」で、MSGIDを選択します。
「演算子」で、=を選択します。
「値」に、BEA-000337と入力します。
「OK」をクリックします。
「監視の作成」ページで、選択されている演算子がANDであることを確認します。
「OK」をクリックします。
「次へ」をクリックします。
アラーム・タイプを選択して、「次へ」をクリックします。
「通知」で、FMWDFW-notificationを選択し、これを「選択済み」ボックスに移動します。
「終了」をクリックします。
監視の作成の詳細は、管理コンソール・オンライン・ヘルプの監視ルールの式の作成に関する項を参照してください。
この項では、WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent (RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決する方法について説明します。初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。
一般的に、問題の調査、報告および解決は、クリティカル・エラーの発生から始まります。この項では、そのワークフローの概要について説明します。
図13-4は、問題を調査、報告および解決するためのタスクを示しています。
次に、図13-4に示しているワークフローについて説明します。
システム、コンポーネントまたはアプリケーションが想定どおりに機能していないことがわかります。たとえば、パフォーマンスに問題があることがわかったり、アクセスしようとしているアプリケーションでエラーが報告されているとユーザーから報告があった場合などです。
観察された症状に関連する可能性のある問題およびインシデントが作成されているかどうかを確認します。
一連の問題を確認するには、第13.4.2.1項の説明に従って、WLSTのlistProblems
コマンドを使用します。
問題が作成されている場合、第13.4.2.2項の説明に従って、listIncidents
コマンドを使用して、特定の問題に関連するインシデントを一覧表示します。
問題に関連しているインシデントを確認できない場合は、createIncident
コマンドを使用してインシデントを手動で作成し、問題の診断情報を取得することができます。
ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要がある場合は、インシデントを作成することを検討してください。ログ・ファイルとその中のメッセージを表示できます。直面している問題に関連すると思われるメッセージがあったら、createIncident
コマンドでそのメッセージIDを使用できます。
インシデントの作成の詳細は、第13.4.6.1項を参照してください。
特定のインシデントの詳細を確認するには、第13.4.2.2項の説明に従って、showIncident
コマンドを使用します。このコマンドを実行すると、関連するメッセージID、インシデントの時刻、ECID、インシデントで生成されたファイルなど、インシデントに関する情報が一覧表示されます。
第13.4.2.2項の説明に従って、getIncidentFile
コマンドを使用して、インシデントのファイルの内容を表示します。その内容には、問題の原因を導き出し、その解決に役立つ情報が含まれる可能性があります。
インシデントのファイルの内容が問題の解決に役立たなかった場合、追加のダンプを実行して詳細な診断情報を確認できます。たとえば、パフォーマンスの問題に直面した場合は、dms.metricsダンプを実行します。使用可能なダンプおよびその実行方法の詳細は、第13.4.4項を参照してください。
それでも問題が解決できない場合は、RDAレポートとともにインシデントをパッケージ化して、Oracleサポートにお送りください。インシデントのパッケージ化およびRDAレポートの生成の詳細は、第13.4.6.2項および第13.4.7項を参照してください。
次の各項で説明するように、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 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に書き込みます。
診断フレームワークは、未処理の例外について明確に定義された一連の問題キーを提供します。これらの例外は、既存のWLDF監視のUncheckedException、または診断フレームワークのjava.lang.Thread.UncaughtExceptionHandlerという捕えられていない例外ハンドラのいずれかによって検出されます。これまで、診断フレームワークは、同一タイプの問題に様々な形式で問題キーを生成していました。表13-6は、これらの問題キーとそれらを使用して問題を調査する方法について説明しています。
表13-6 捕えられていない例外の問題キー
例外 | 問題キー | 説明 |
---|---|---|
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など)で使用されます。 例外に関連付けられたテキストを確認し、障害の理由などの詳細を取得します。問題キーのソース行で障害の場所が示されている可能性があります。 |
問題が疑われる場合、組込みの診断ダンプを利用して、問題の診断に役立つ詳細な診断結果を報告できます。診断ダンプは、診断データを出力および記録する手段を提供します。診断データは、Oracle Fusion Middlewareのコンポーネント、アプリケーションおよびインフラストラクチャに関する問題を診断する際に有益な情報になります。これらのダンプからの出力は、Oracle Fusion Middlewareに関する問題を診断するために、顧客およびOracleサポートが使用することを想定しています。
診断ダンプは、次のように実行します。
手動。次の各項で説明するように、WLSTコマンドを使用します。
たとえば、Java EEアプリケーションがハングしてデッドロックが疑われる場合には、jvm.threadsダンプを使用して一連のスレッドを取得できます。
自動。診断フレームワークがクリティカル・エラーを検出してインシデントを作成した場合、または管理者がインシデントを作成した場合。
管理対象サーバーで使用可能な診断ダンプのリストを検索するには、次の形式で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-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で実行中のスレッド、および完全なスレッド・ダンプを実行中のスレッドに関する統計サマリー。 |
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. Mandatory Arguments: Optional Arguments: Name Type Description format STRING Format of the dump output; raw or xml
問題を検出して追加の診断データを収集する場合、指定したダンプに対して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が含まれます。
診断ダンプ・サンプリングは、指定された間隔で診断ダンプの出力を取得します。定期的な間隔でサンプルを取得する診断ダンプ・サンプリングにより、低速なWebリクエストなどの問題や、これらのリクエストのどこで処理が実行されているなどを特定できます。
この項の内容は次のとおりです。
すべての診断ダンプ・サンプリングは、指定した間隔で、バックグラウンドで実行されます。デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプがサンプリング用に構成されています。デフォルト・ダンプ・サンプリングに対する設定を変更し、また表13-7に示したダンプ操作およびアプリケーション固有のダンプに対して新しいサンプリング定義を作成できます。サンプリング間隔やサーバーなどについて異なる設定を指定して、同じ診断ダンプに対して複数のサンプリング定義を構成できます。
各診断ダンプ・サンプリングに対して、診断フレームワークにより、指定された数のサンプルが保存されます。上限に達すると、最も古いサンプルからパージされます。サーバーの停止時にはすべてのサンプルがパージされます。
表13-8に、デフォルトで構成されているダンプ・サンプリングの設定を示します。
診断フレームワークにより、インシデントが作成されるたびに(エラー検出またはインシデントの手動作成により)、ダンプ・サンプルの取得がトリガーされます。また、ダンプ・サンプルの内容を取得することもできます(第13.4.5.4項を参照)。
ダンプ・サンプル・アーカイブは、テキストまたはzipファイルとして取得できます。
テキスト: デフォルトでは、診断ダンプ・サンプルはテキスト形式で1つのアーカイブ・ファイルに連結されます。アーカイブ・ファイル内では、各サンプルはASCIIヘッダーとフッターによりラップされます。ヘッダーには、サンプルを生成した診断ダンプのタイムスタンプと名前が含まれます。ヘッダーとフッターの両方に、アーカイブ内のサンプルの数と、その特定のサンプルの番号が含まれます。次に例を示します。
$$$=== BEGIN OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$ Fri Sep 07 07:00:00 PDT 2012 <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-12 07:25 dfw_samplingArchive1065570966467923683.JVMThreadDump.dmp 840 08-21-12 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ダンプ・サンプリング・コマンドを実行するには、管理サーバーに接続している必要があります。 |
次の各項で説明しているように、追加のダンプ・サンプリングを作成し、既存のダンプ・サンプリングを更新し、ダンプ・サンプリングを削除し、ダンプ・サンプリングを有効化または無効化できます。
表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"])
たとえば、soa_server1サーバーに対して、http.requestsダンプに対するダンプ・サンプリングを作成し、サンプリング間隔を300秒、繰返し回数を10サンプルに設定するには、次のように指定します。
addDumpSample(sampleName="HTTPSampling", diagnosticDumpName="http.requests", samplingInterval=300, rotationCount=10, server="soa_server1") HTTPSampling is added
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「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="soa_server1") HTTPSampling is updated
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「updateDumpSample」を参照してください。
WLSTコマンドremoveDumpSampleを使用することにより、既存のダンプ・サンプリングを削除できます。removeDumpSampleコマンドでは、次の構文を使用します。
removeDumpSample(sampleName="sample_name", [server="server_name"])
たとえば、ダンプ・サンプリングHTTPSamplingを削除するには、次のように指定します。
removeDumpSample(sampleName="HTTPSampling", server="soa_server1")
Removed HTTPSampling
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「removeDumpSample」を参照してください。
WLSTコマンドenableDumpSamplingを使用することにより、すべてのダンプ・サンプリングを有効化または無効化できます。このコマンドは、構成済のすべてのダンプ・サンプリングに影響します。enableDumpSamplingコマンドでは、次の構文を使用します。
enableDumpSampling(enable={true|false}, [server="server_name"])
serverパラメータは、管理サーバーに接続している場合にのみ有効です。serverパラメータを指定しないと、管理サーバーに対してダンプ・サンプリングが無効化されます。
たとえば、管理サーバーに対してダンプ・サンプリングを無効化するには、次のように指定します。
enableDumpSampling(enable=false)
ダンプ・サンプリングが有効化されているのかどうかを確認するには、WLSTコマンドisDumpSamplingEnabledを使用します。isDumpSamplingEnabledコマンドでは、次の構文を使用します。
isDumpSamplingEnabled([server="server_name"])
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「enableDumpSampling」および「isDumpSamplingEnabled」を参照してください。
WLSTコマンドlistDumpSamplesを使用することにより、ダンプ・サンプリングをリストできます。すべてのダンプ・サンプリング、指定したダンプ・サンプリングまたは特定のサーバーに関連付けられているすべてのダンプ・サンプリングをリストできます。listDumpSamplesコマンドでは、次の構文を使用します。
listDumpSample([sampleName="sample_name",] [server="server_name"])
たとえば、soa_server1サーバーに関連付けられているすべてのダンプ・サンプリングをリストするには、次のように指定します。
listDumpSamples(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) Name : JavaClassHistogram Dump Name : jvm.classhistogram Application Name : Sampling Interval : 1800 Rotation Count : 5 Dump Implicitly : false Append Samples : true Dump Arguments : Name : JVMThreadDump Dump Name : jvm.threads Application Name : Sampling Interval : 60 Rotation Count : 10 Dump Implicitly : true Append Samples : true Dump Arguments : context=true, timing=true
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のlistDumpSamplesに関する項を参照してください。
ダンプ・サンプルの出力を取得するには、次の各項で説明するように、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 WebLogic Scripting Toolコマンド・リファレンス』の「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 07-27-12 11:19 dfw_samplingArchive8680976839106379444.JavaClassHistogram.dmp 552 07-27-12 11:19 dfw_samplingArchive7861027727509995202.readme.txt -------- ------- 6242320 2 files
完全な構文は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「getSamplingArchives」を参照してください。
診断フレームワークでは、自動で作成されるか手動で作成されるかに関係なく、インシデントが格納されます。Oracle Fusion Middlewareには、インシデントのレポートの処理に役立ち、それらのインシデントをパッケージ化してOracleサポートに送信するツールが用意されています。各項目で説明する内容は次のとおりです。
システムで生成された問題(内部で生成されたクリティカル・エラー)は、自動診断リポジトリ(ADR)に自動的に追加されます。それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできます。また場合によっては、問題を解決することもできます。これらはすべて、第13.4項で説明されているワークフローに記載されています。
ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要があるものの、診断フレームワークでインシデントが自動的に作成されていない場合は、インシデントを手動で作成することを検討してください。
インシデントを手動で作成するには、WLSTコマンドのcreateIncident
を使用します。インシデントは、時間、メッセージID、影響領域またはECIDを基準に指定できます。ここで、インシデントの内容を調べたり、Oracleサポートに送信してさらなる分析を依頼することができます。
次に、メッセージIDを基準としてインシデントを手動で作成する方法について説明します。
第12.3.2項の説明に従って、ログ・ファイルを検索します。直面している問題に関連すると疑われるメッセージがあったら、インシデントを作成するときにそのメッセージIDを使用できます。
次のコマンドを使用してWLSTを起動し、管理対象サーバーに接続して、管理対象サーバー・インスタンスにナビゲートします。
java weblogic.WLST connect('username', 'password', 'localhost:7001') cd('servers/server_name')
次の形式で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項で説明するように、ダンプに情報を表示できます。
インシデントをパッケージ化して、その情報を容易に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つのプロセスに分かれています。
論理パッケージを作成します。
このパッケージは、ADRではメタデータとしてのみ存在するため、論理的なものと示されます。論理パッケージから物理パッケージを生成するまで、その中身はありません。論理パッケージにはパッケージ番号が割り当てられ、以降のコマンドではその番号でそのパッケージを参照します。
論理パッケージは、空のパッケージとして、あるいはインシデント番号、問題番号、問題キーまたは時間間隔を基準としたパッケージとして作成することができます。空のパッケージとしてパッケージを作成した場合は、ステップ2で診断情報を追加できます。
インシデントを基準にパッケージを作成すると、ダンプなど、そのインシデントの診断データが含まれることになります。問題番号または問題キーを基準にパッケージを作成すると、その問題番号または問題キーを参照するインシデントのパッケージ診断データが含まれることになります。時間間隔を基準にパッケージを作成すると、その時間間隔内に発生したインシデントの診断データが含まれることになります。
診断情報をパッケージに追加します。
インシデント番号、問題番号、問題キーまたは時間間隔を基準として論理パッケージを作成した場合は、この手順は省略できます。追加のインシデントをパッケージに追加したり、ADR内の任意のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用して、インシデントまたはファイルをパッケージに追加する必要があります。
物理パッケージを生成します。
物理パッケージを生成するコマンドを発行すると、ADRCIでは必要な診断ファイルをすべて収集し、目的のディレクトリ内のzipファイルに追加します。完全なzipファイルまたは増分zipファイルを生成できます。増分ファイルには、同じ論理パッケージでzipファイルが前回作成されてから追加または変更された診断ファイルがすべて含まれます。増分ファイルは、完全ファイルを作成した後にのみ作成可能で、いくつでも作成できます。それぞれのzipファイルには、正しい順序で分析できるように、順序番号が割り当てられます。
zipファイルは、次の形式に従って名前が付けられます。
packageName_mode_sequence.zip
この形式の各項目について説明します。
packageName
は、問題キーの一部にタイムスタンプが続きます。
mode
は、COM
(完全)またはINC
(増分)です。
sequence
は整数です。
たとえば、インシデントをパッケージ化するには、次の手順を実行します。
次の例に示すように、ORACLE_HOMEおよびLD_LIBRARY_PATH環境変数を設定します。
ORACLE_HOME=MW_HOME/oracle_common LD_LIBRARY_PATH=MW_HOME/wlserver_10.3/server/adr
ADRCIを起動します。次に例を示します。
MW_HOME/wlserver_10.3/server/adr/adrci
SET BASEコマンドを使用してADRベースを指定し、SET HOMEPATHコマンドを使用してインシデントを含むADRホームを指定します。HOMEPATHのパスは、ADRベースを基準に指定します。
SET BASE /scratch/oracle/config/domains/soa_domain/servers/soa_server1/adr SET HOMEPATH diag/ofm/soa_domain/soa_server1
論理パッケージを生成します。
IPS CREATE PACKAGE INCIDENT incident_number
たとえば、次のコマンドを実行すると、インシデント1を基準にパッケージが作成されます。
IPS CREATE PACKAGE INCIDENT 1 Created package 1 based on incident id 1, correlation level typical
ADRCIにより、論理パッケージに番号が割り当てられます。
オプションで、論理パッケージに診断情報を追加できます。次のタイプの情報を追加できます。
特定のインシデントのすべての診断情報。たとえば、次のコマンドを使用して、パッケージ化したインシデントに関連すると思われる別のインシデントを追加できます。
IPS ADD INCIDENT incident_number PACKAGE package_number
ADR内にある、名前が付けられたファイル。たとえば、インシデントがアプリケーションに関連する場合、そのアプリケーションに対する.earファイルを追加できます。また、ユーザーがOracleサポートに通知するメモを記したreadmeファイルを追加することもできます。たとえば、パッケージにファイルを追加するには、次のコマンドを使用します。
IPS ADD FILE filespec PACKAGE package_number
次のコマンドを使用して、物理パッケージを生成します。
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コマンド・インタプリタ」 |
デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、第13.3.1項で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。
ADRCIコマンドを使用して、インシデントを手動でパージできます。パージは、IDまたはIDの範囲、インシデントの経過時間、またはインシデントのタイプを基準にして行えます。たとえば、経過時間が60分を超えたインシデントをパージするには、次のコマンドを使用します。
purge -age 60
『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。
コマンド行診断ツールのRemote Diagnostic Agent (RDA)を使用して、ご使用の環境の全体像を把握することができます。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。
RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。
RDAの詳細は、次の場所にあるreadmeファイルを参照してください。
(UNIX) ORACLE_HOME/rda/README_Unix.txt (Windows) ORACLE_HOME\rda\README_Windows.txt