WebLogic 診断フレームワークについて
|
 |
 |
|
WebLogic 診断フレームワーク (WLDF) は、サーバとそのサーバがホストするアプリケーションに関する診断情報に対する収集、アーカイブ、およびアクセスを行うために共同で動作する、いくつかのコンポーネントで構成されています。フレームワークとコンポーネントについては、以下の節で説明します。
WLDF アーキテクチャは、以下のコンポーネントで構成されています。
データ クリエータは、コレクタによって消費される診断データを生成します。コレクタは、アーカイブとの連携でこのデータを永続化し、監視と通知システムとの連携で自動化されたモニタを提供します。アクセサは、コレクタと対話して現在の診断データを公開し、アーカイブと対話して履歴データを提示します。マネージャは、フレームワークを管理するためのコンフィグレーションおよび制御インタフェースを提供します。最後に、イメージ キャプチャ機能は、主要なサーバの状態の診断スナップショットをキャプチャするためのモデルを提供します。これらのコンポーネント間の関係を、図 2-1 に示します。
すべてのフレームワーク コンポーネントは、サーバ レベルで動作し、サーバのスコープしか認識しません。マネージャ以外のコンポーネントはすべて、完全にサーバのプロセス内にあり、標準的なサーバのライフサイクルに参加しています。フレームワークのアーティファクトはすべて、サーバごとにコンフィグレーションおよび格納されます。
診断データは、いくつかのソースから収集されます。これらのソースは論理的に、現在の値を収集するために一定の間隔でサンプリングされるデータ クリエータであるデータ プロバイダ、または同期的にイベントを生成するデータ クリエータであるデータ パブリッシャのいずれかに分類できます。データ プロバイダとデータ パブリッシャは、複数のコンポーネントにまたがって分散されており、生成されたデータは図 2-2 に示され以下で説明されるように、ロガーやハーベスタによって収集できます。
図 2-2 データ作成コンポーネントとデータ収集コンポーネントの関係
サーバ ロギング インフラストラクチャの呼び出しは、インライン データ パブリッシャとして機能し、生成されたデータは、イベントとして生成されます (ロギング インフラストラクチャは、カタログ インフラストラクチャかデバッグ モデルを通じて、または直接ロガーを通じて呼び出せます)。
インスツルメンテーション システムは、モニタおよびアドバイス (その一部はパブリッシャやプロバイダ) を作成し、それらを実行フローにおける明確に定義された位置に挿入します。パブリッシャは、従来のロギング フレームワークによって消費されるイベントを生成します。プロバイダは、データ ソース インタフェースを使用してハーベスタにデータを公開します。
MBean サーバに登録されたコンポーネントも、ハーベスタに登録することでデータ プロバイダとして認識できるようになります。ハーベスタに登録されたすべてのプロバイダが、その後、管理インタフェースにより動的に制御可能な現在の収集コンフィグレーションに基づき、収集可能になります。収集されたデータは、監視と通知システムに公開されて自動的にモニタされると共に、アーカイブに公開されて永続化されます。
システム内の障害の診断において、過去の状態が重要性を持つことがしばしばあります。そのため、状態をキャプチャして将来アクセスできるようアーカイブし、履歴アーカイブを作成しておくことが必要となります。WLDF ではアーカイブが、いくつかの永続化コンポーネントによってこの要件に対応しています。イベントおよび収集されたメトリックの双方が、永続化されて履歴確認できるようになります。
人間に判読可能であり、サーバ ログに含めることが意図されている、従来のロギング情報は、標準のロギング アペンダによって永続化されます。システムでの消費が意図されている新しいイベント データは、イベント アーカイバを使用してイベント ストア内で永続化されます。メトリック データは、データ アーカイバを使用して、データ ストア内に永続化されます。アーカイブとロガーおよびハーベスタとの関係を、図 2-3 に示します。
アーカイブがアクセス インタフェースを提供するので、アクセサは任意の永続化された履歴データを公開できるようになります。
監視と通知システムは、特定の診断状態を観察する自動化されたモニタを作成し、コンフィグレーションされたルールに基づいて通知を送信するのに使用できます。
監視ルールは、データ パブリッシャからのイベント データか、ハーベスタによって収集されるデータ プロバイダからのメトリック データかの、いずれかをモニタできます。ウォッチャは、いくつかの監視ルールで構成される監視の管理を行うことができます。これらの関係を、図 2-4 に示します。
図 2-4 ロガーおよびハーベスタと、監視と通知システムの関係
1 つまたは複数の通知を、監視による使用に備えてコンフィグレーションできます。デフォルトでは、各監視が、サーバ ログ内にイベントを記録します。加えて、SMTP、SNMP、JMX、および JMS 通知がサポートされています。
アクセサは、イベント、メトリック データなど、WLDF によって収集されたすべてのデータへのアクセスを提供します。アクセサは、ハーベスタと対話して、サーバ内の収集可能な値の現在の状態を取得します。アクセサは、アーカイブと対話して、ログに記録されたイベント データや永続化されたメトリックなど、履歴状態を取得します。
実行中のサーバのデータにアクセスする場合は、JMX ベースのアクセス サービスが使用されます。アクセサは、型、コンポーネント、および属性を基準としたデータ ルックアップに対応しています。時間ベースのフィルタ処理を許可し、またイベントの場合には、重大度、ソース、およびコンテンツごとのフィルタ処理を許可します。
ツールから、現在はアクティブでないサーバによって永続化されたデータへのアクセスが行われることがあります。そのような場合に備えて、オフライン アクセサがあります。これは、現在の状態が存在しないため、履歴データのみへのアクセスをサポートします。
アクセサとハーベスタおよびアーカイブとの関係を、図 2-5 に示します。
図 2-5 オンラインおよびオフラインのアクセサとハーベスタおよびアーカイブとの関係
マネージャは、フレームワーク全体の管理インタフェースを提供します。これは、サーバ固有の最上位診断サービスへのアクセスを提供し、この診断サービスはその後、適切なコンポーネント固有のサービスへの参照を提供します。各サービスは次に、関連サーバのコンテンツ内で実行中の適切なコンフィグレーション コンポーネントと適切な実行時コンポーネントを参照します。
管理インタフェースはすべて JMX ベースであり、サービス指向のインタフェースに著しく依存しています。サービス コンポーネントはすべて、実行時 MBean として定義されます。サービス コンポーネントは管理サーバ内に存在しており、フレームワーク インスタンスと関連付けられたサーバ プロセス内の実行時コンポーネントと対話します。
管理サービスに加えて、診断サービスはフレームワーク自体に関する診断データと、特定サーバのアクセサへの参照を提供します。
マネージャの診断サービスと、コンフィグレーションおよび実行時コンポーネントとの関係を、図 2-6 に示します。
図 2-6 マネージャのサービスとコンフィグレーションおよび実行時コンポーネントとの関係
診断イメージのサポートでは、図 2-7 に示すように、問題やパッケージを診断するのに使用される主要なサーバの状態について、最も一般的な情報を収集し、サポートに使用できる単一のアーティファクトの形で提示します。診断イメージは、本質的に、サーバからの診断スナップショットまたはダンプです。
イメージ キャプチャ サポートには、必要に応じてのキャプチャ処理と、何らかの基本的な障害検出に基づく自動化されたキャプチャの双方が含まれます。
図 2-8 に、WLDF のすべての部分がどのように組み合わせられているかを示します。
|
|
|
