[SOA/BPM, Support] Overview of SOA Diagnostics in 11.1.1.6

原文はこちら。
https://blogs.oracle.com/soaproactive/entry/overview_of_soa_diagnostics_in

SOA Suite 11gで問題があったときの診断ツールにはどんなのがあるの？

色々なツールがありますが、どのツールをどんなときに使えばいいのか、ツール間の関係などがわかりづらいかもしれません。このエントリではそのあたりをご紹介します。まず、使えるツールを列挙してみます。
このエントリはこれらのツールの使用方法に関する包括的なガイドではありませんが、豊富な参考資料に詳細情報が纏まっています。また、これらのツール全ては概ねFusion Middlewareで利用できますが、特定の製品ではこれらのツールを使う機能を実装していたりしなかったりします。

ツールの中にはWebLogic Scripting Toolを使っていたり、WLSTインターフェースをもっていたりするものがあります。WLSTは事前構成済みの関数やカスタムスクリプトをドメインに対して実行できるコマンドインターフェースです。WLSTチュートリアルの詳細はこのエントリの対象外ですが、一般的な情報は以下のリンクからどうぞ。以下のセクションでは特定のリソースについて記載しています。
Oracle® Fusion Middleware Oracle WebLogic Scripting Tool 11g Release 1 (10.3.6)
http://docs.oracle.com/cd/E25178_01/web.1111/e13715/toc.htm
このエントリでEnterprise ManagerもしくはEMと表記している場合、Enterprise Manager Fusion Middleware Controlのことを指します。

RDA (Remote Diagnostic Agent)

RDAはスタンドアロンのツールです。静的構成情報と動的なランタイム情報をSOA環境から収集します。RDAは一般に人の手によりコマンドラインからドメインや単一サーバに対して実行します。新しくService Requestを作成する際に、RDAの収集した情報を含めると、弊社サポートチームからのログや設定情報の収集を要求するやりとりが劇的に減ります。

RDAをインストールしたら、SOA Suiteモジュールを使うように参考資料の通り設定してください。SOAモジュールは、環境の関連情報を全て収集するため、Oracle WebLogic Server (WLS)モジュールをデフォルトで含んでいます。この基本構成に加えて、詳細モードがあり、コレクションのスレッドダンプの個数、ログ·ファイル、インシデントなどを設定できます。

使うタイミングは？
サービスリクエストを作成する場合。または、Oracleのリソースを使って問題に対応したり、環境のスナップショットをキャプチャして構成のベースラインにしたり、自分で問題を診断する場合。

他のツールとの関係は？
RDAは、デフォルトではサーバーから最新の10インシデントを収集するという点で、DFWと関連しています。同様に、RDAは、診断ログの収集を通じて、ODLと関連しています。これらの収集する情報には Selective Tracing セッションからの情報が含まれている場合があります。

現在収集できる情報（詳細はリソースのリンクをご覧下さい）
  • 診断ログ (ODL)
  • 診断フレームワークのインシデント情報（DFW）
  • SOA MDSのDeployment Descriptors
  • SOAリポジトリの統計情報サマリ
  • スレッドダンプ
  • 完全なドメイン構成
RDAのリソース

DFW (Diagnostic Framework)

DFW（診断フレームワーク）は問題発生時にその問題に関する具体的な情報を収集する機能を提供します。DFWはSOA Suiteのインストールメディアに含まれており、ドメインにデプロイされています。DFWのコンポーネントを見ていきましょう。
  • Diagnostic Dump（診断ダンプ）: システムレベルや製品レベルで定義した診断情報。例えば、診断ログやスレッドダンプなどです。
  • Incident: 特定の問題に関連する診断ダンプの集合体。
  • Log Conditions: DFWを構成したときのOracle Diagnostic Logging（ODL）イベント。このイベントを認識した場合インシデントを作成する。
  • WLDF Watch: WebLogic Diagnostic Framework (WLDF) はDFWのコンポーネントではないが、'Watch'の利用を通じてDFWインシデントの作成のソースとなることができる。
  • WLDF Notification: NotificationはWLDFのコンポーネントでWatchとDFW間を紐づける。WLDFの複数のNotificationタイプを構成し、Watchに関連づけることができる。'FMWDFW-notification'（FMWDFW通知）は標準でWatch実行のDFW通知を利用できる。
  • ルール: 診断ダンプと関連付けたいWLDF WatchやLog Conditionを定義する。ルールが呼び出されると、特定のダンプを収集し、インシデントに追加する。
  • Rule Action: 特定のルールに従って収集する具体的な診断ダンプを定義する。
  • ADR: Automatic Diagnostics Repository; ドメインの各サーバごとに定義するインシデントの格納場所。
簡単なフローで確認していきましょう。
  1. Oracle Webサービスのエラーメッセージ OWS-04086 (SOAP Fault) が管理対象サーバ1で発生
  2. DFWのOWS-04086のLog ConditionはTRUE
  3. DFWは管理対象サーバ1のADRに新しいインシデントを作成
  4. DFWは診断ダンプを実行し、出力をインシデントに追加
  5. この場合、診断ログとスレッドダンプを取得する。WSDLバインディング情報やSOAの監査証跡を収集したいかもしれない。
使うタイミングは？
トリガーを使用して特定のタイミングで自動的に診断ダンプを収集したい場合、または手作業で情報を収集したい場合。いずれの場合においても、それは容易にサービス·リクエストを介して弊社サポートサービスにアップロードすることができます。

他のツールとの関係は？
DFWは診断ダンプのコレクションであるインシデントを生成します。システムレベルの診断ダンプの一つは、ODLが生成する現在のサーバーの診断ログを収集し、 Selective Tracingセッションからの情報を含めることができます。インシデントは、デフォルトではRDAのコレクションに含まれており、ADRCIは、弊社サポートへアップロードするインシデントをパッケージ化するためのツールです。さらに、 ODLとDMSを使って、DFWを通じてインシデントの作成を起動することができます。

インシデントを生成するための条件やルールが非常に複雑にすることができます。詳細は以下のリソースをどうぞ。少なくとも診断ダンプを活用するシンプルな方法は、以下の操作をするコマンドがあるWLST（WebLogic Sc​​ripting Tool）を使うことです。
  • インシデントの作成
  • 単一の診断ダンプを実行
  • 診断ダンプを記述
  • 利用可能な診断ダンプをリスト
WLSTのオプションは、何をいつ生成するかコントロールすることができます。サポート向けの情報を収集するとき、それは大きな助けになるでしょう。RDAと重複する部分がありますが、DFWは、問題が発生したときに特定のランタイム情報の収集を対象にしているのに対し、既存のインシデントは、RDAが収集します。

SOA Suite 11gのドメインにはデフォルトで設定された3個のWLDF Watch（スタックスレッド、チェックされない例外、デッドロック）があります。これらのWatchはデフォルトで有効となっており、ADRにインシデントを生成します。これらは30秒後に自動でリセットされるようになっていて、条件が一致する場合は複数のインシデントを作成できるようになっています。Watchが生成したインシデントにはシステムレベルの診断ダンプのみを含んでいます。これらの同じシステムレベルの診断ダンプも同様に、任意のアプリケーションスコープのインシデントに含まれます。

11.1.1.6以降では、SOA Suiteは、WLST、またはWLDF WatchやLog Conditionを通して実行できるアプリケーションスコープの診断ダンプの独自のセットを持っています。これらの診断ダンプを、エラーコードOWS-04086を使った先ほどの例のように、インシデントに追加することができます。
  • soa.config：MDS構成ファイル、およびdeployed-composites.xml
  • soa.composite：デプロイしたコンポジットに関連するすべてのアーティファクト
  • soa.wsdl：コンポジット用に構成したエンドポイントの概要
  • soa.edn：EDNの構成の概要（該当する場合）
  • soa.db：SOAリポジトリのDB情報の概要
  • soa.env：Coherenceクラスタの構成の概要
  • soa.composite.trail：実行しているコンポジットの部分的な監査証跡情報
RDAの現在のリリースでは、soa.wsdlとsoa.composite診断ダンプを収集するオプションがあります。DFW自体の機能強化に合わせて、将来のリリースでSOA Suite製品の詳細診断ダンプを収集することが予定されています。

DFWのリソース

Selective Tracing

Selective Tracingは11.1.1.4から利用可能な機能で、これを使用すると、特定のロガーおよび特定のコンテキストのログ出力レベルを上げることができます。これの意味するところは、オーバーヘッドを減らしつつ、診断に必要な本番環境の診断ログ情報を収集できるといううことです。たとえば、ある１つのコンポジットの、1つのロガーのみ、クラスタ内のあるサーバに限定して、所定の期間ログレベルのみを上げて、Selective Tracingセッションを実行することができます。たくさんのコンポジットがデプロイされている環境では、この機能により、関連を犠牲にせず、ログのボリュームとオーバーヘッドを劇的に減らすことができます。
Selective Tracingは、Enterprise ManagerまたはWLSTから実行できます。WLSTの場合、トレースの実行場所の面で少々柔軟に指定できます。

使うタイミングは？
下記の利用可能なコンテキスト基準を使ったフィルタリングにうってつけの本番環境や別の環境で問題がある場合、ログレベルを全体的に上げた結果、オーバーヘッドが過大になり無関係な情報まで収集することになる場合。情報はサーバーの診断ログに書き込まれ、Enterprise Managerからエクスポートできます。

他のツールとの関係は？
Selective Tracingの出力はサーバーの診断ログに書き込まれます。DFWやデフォルトのRDAのコレクションを使いシステムレベルの診断ダンプがこのログを収集できます。Selective TracingはODLのフィールドを使って、何をトレースすべきか、特定のトレースセッションの一部である情報にタグ付けすべきかを決定します。

Available Context Criteria:
  • アプリケーション名
  • クライアントのアドレス
  • クライアントのホスト
  • コンポジット名
  • ユーザ名
  • Webサービス名
  • Webサービスのポート
Selective Tracingのリソース

DMS (Dynamic Monitoring Service)

DMSは、監視用にランタイム情報を公開します。この情報を2つの方法で監視できます：
  1. DMSのサーブレットを介して監視
  2. 公開されたMBeanとして
サーブレットは、デフォルトでデプロイされており、http://<host>/<port>/dms/Spyでアクセスできます（アクセスには管理者の資格情報を使用します）。サーブレットのランディングページには、Nounのタイプとして知られているものと同一の列が表示されています。Nounのタイプを選択すると、右側のフレームの表にこのNounのタイプの属性（センサ）と使用可能なインスタンスが表示されます。SOA Suiteは、いくつかのNounタイプを公開しており、これらはSpyサーブレットで閲覧できます。以下のKnowledge Baseの記事でSpyサーブレットのスクリーンショットをご覧頂けます。
How to Monitor Runtime SOA Performance With the Dynamic Monitoring Service (DMS)
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=1368291.1
ランタイム中のすべてのNounインスタンスは、MBeanインスタンスとして公開されます。こうしてMBeanブラウザから利用でき、WLDFから監視できます。WLDF Watchを構成して特定の属性を監視し、閾値を超えた時点で通知を発行することができます。WLDF Watchは標準機能のDFW通知タイプを使って、DFWにインシデント作成を通知することができます。

使うタイミングは？
あなたはメトリックを手動または自動化されたシステムを通じて監視したい場合。DMSを介して公開されるメトリックに基づいてWLDF Watchを起動したい場合。

他のツールとの関係は？
DMSのメトリックをWLDF Watchで監視できます。順にDFWを通知してインシデントを作成できます。

DMSのリソース

ODL (Oracle Diagnostic Logging)

ODLは、何をしているかをログに記録するための、ほとんどのFusion Middlewareアプリケーションにとって主要な機能です。ログレベルをEnterprise Managerから変更するたびに、最終的にODLを介して公開され、サーバーの診断ログに書き込まれます。これの明らかな例外はWebLogic Serverで、独自のログフォーマット/ファイルを使用しています。

ODLは、事前に定義されたフィールドの名前/値のペアを使用して、一貫性のある構造化された方法でエントリをログに記録します。以下はSOA Suiteのエントリの例です。

[2012-04-25T12:49:28.083-06:00] [AdminServer] [ERROR] [] [oracle.soa.bpel.engine] [tid: [ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 0963fdde7e77631c:-31a6431d:136eaa46cda:-8000-00000000000000b4,0] [errid: 41] [WEBSERVICE_PORT.name: BPELProcess2_pt] [APP: soa-infra] [composite_name: TestProject2] [J2EE_MODULE.name: fabric] [WEBSERVICE.name: bpelprocess1_client_ep] [J2EE_APP.name: soa-infra] Error occured while handling a post operation[[

使うタイミングは？
環境の問題を診断・識別したいときはほとんど常にODLを利用することになるでしょう。エントリは、サーバーの診断ログに書き込まれます。

他のツールとの関係は？
サーバーの診断ログはDFWとRDAが収集します。Selective Tracingも同様に診断ログにその情報を書き込みます。さらに、DFWのLog ConditionはODLログイベントによってトリガされます。

ODLのリソース

ADR (Automatic Diagnostics Repository)

ADRは、それ自体ツールではなく、DFWが作成するインシデントを保管する場所です。ドメイン内のすべてのサーバーのADRのロケーションは<SERVER_HOME>/adrで、ADR Baseと呼びます。また、ADRには"Home"として知られる場所があります。例えば
  • "myDomain"と呼ばれるドメインと、"myServer"と呼ばれる関連した管理対象サーバ。管理サーバは"AdminServer"と呼ばれます。
  • ドメインホームディレクトリは"myDomain"と呼ばれ、"servers"ディレクトリを含みます。
  • "servers"ディレクトリには管理対象サーバ"myServer"のためのディレクトリがあり、ここに"adr"ディレクトリがあります。この"adr"ディレクトリがmyServerのADR Baseです。
  • ADR Homeの場所を知る場合、diag/ofm/myDomain/と進んでいきます。
  • SOA Suite 11.1.1.6のドメインでは、2個のディレクトリを確認できるはずです。一つは"myServer"、もう一つは"soa-infra"です。これらがADR Homeです。
  • "myServer"は'system' ADRのホームであり、システムレベルのインシデントがあります。
  • "soa-infra"はSOA SuiteがDFWで登録するために使う名前で、このADRホームにはSOA Suiteに関連するインシデントがあります。
  • 各ADRホームにはディレクトリがあり、そのディレクトリの一つが"incident"と呼ばれるもので、ここにインシデントが格納されています。
［訳注］
ADR Base : <Domain_Home>/servers/<Server>/adr
ADR Home:
<Domain_Home>/servers/<Server>/adr/diag/ofm/<Domain>/<Server>（システムレベル）
<Domain_Home>/servers/<Server>/adr/diag/ofm/<Domain>/soa-infra（SOA Suite関連）

使うタイミングは？
たくさんのインシデントが生成されているかどうか、時々これらの場所をチェックすることをお勧めします。インシデント·ディレクトリを削除するか、ADRCIのツールを使用して削除できます。インシデントがOracleと共に対応している問題で特に重要であることがわかっている場合、圧縮して提供することができます。

他のツールとの関係は？
インシデントが格納されている箇所のため、ADRは、DFWにとって非常に重要です。インシデントには診断ログ（ODL）とDMSメトリックに関連する診断ダンプが含まれています。RDAがデフォルトで直近の10個のインシデント·ディレクトリを収集し、ADRCIはコンテンツ管理を支援するADRの場所に依存しています。

ADRCI (Automatic Diagnostics Repository Command Interpreter)

ADRCIはインシデントをパッケージ、管理するためのコマンドラインツールです。

使うタイミングは？
ADR Homeロケーションからインシデントを削除する場合、もしくは弊社サポートへアップロードするためのオフラインでRDAの収集情報とあわせてインシデントをパッケージングしたい場合

他のツールとの関係は？
ADRCIにはIncident Packaging System（IPS)なるツールが含まれています。これを使い、サービス·リクエストを通じて弊社サポート·サービスへアップロードするためのインシデントをパッケージングします。 11.1.1.6では、IPSは、オフラインでRDA収集情報を集め、インシデント·パッケージとまとめようとします。Perlにパスが通っている場合のみ動作しますが、通っていない場合は、警告が発行され、インシデントファイルのパッケージのみ実施します。

ADRCIのリソース

WLDF (WebLogic Diagnostic Framework)

WLDFはバージョン9以降のWebLogic Serverで使用可能な機能です。 FMW11g以降、リンクはWLDFおよび既存のDFW、WLDF Watch Notification（監視通知）の間に追加されました。流れを詳しく見てみましょう。
  1. SOA Suiteのメッセージ処理のパフォーマンスを監視する必要があるとします。
  2. メッセージの平均処理時間が2秒を超えると起動するようなWLDF WatchをWebLogic Server管理コンソールで作成します。このメトリックをDMSのMBeanインスタンスを介して監視します。
  3. 標準のDFW Notification（このNotificationはFMWDFW Notificationと呼ばれます）をWatchに追加します。実体は、この通知は、JMXの類です。
  4. Watchは、しきい値を超えたときに呼び出され、通知を発行します。
  5. DFWには通知を拾うリスナーがあり、ルールに従い評価します。
自動インシデント作成の場合、WLDFは重要なコンポーネントで、時間をかけて成長していきます。

使うタイミングは？
あなたは、WLSのサーバ・ログや、ある条件のMBeanメトリックを監視したい場合や、監視をトリガしたときに通知を発行したい場合。

他のツールとの関係は？
DFW Notificationを使う DFW を通じて、WLDFを使って自動的にIncident作成を呼び出します。

WLDFのリソース
-
カテゴリ ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)