ナビゲーションをスキップ

WebLogic 診断フレームワークのコンフィグレーションと使い方

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

用語

診断およびモニタに関するマニュアルで扱う主な用語は以下のとおりです。

アーティファクト

WebLogic 診断フレームワークで生成され、ディスクに保存された、物理的なエンティティまたはデータ。後で診断を分析するために使用できます。たとえば、サーバで障害が発生したときに作成される診断イメージ ファイルはアーティファクトです。この診断イメージ アーティファクトは、サーバの障害の原因を判断するための分析を行うサポート担当者用に提供されます。WebLogic 診断フレームワークでは、多様なアーティファクトが数多く作成されます。

コンテキスト作成

診断モニタ機能が有効になっている場合、システムに要求が届いたときに WebLogic Server によって診断コンテキストが作成され、初期化されて設定されます。WebLogic Server では、要求が届いたときにその要求に診断コンテキストが付属しているかどうかが判断されます。付属している場合、要求はその所定のコンテキストと共に伝播されます。付属していない場合、新しいコンテキストが特定の名前 (weblogic.management.DiagnosticContext) で作成されます。診断コンテキストのコンテキスト データは、診断コンテキスト ペイロードに格納されます。したがって、要求が実行中である間は必ず診断コンテキストがあることになります。

コンテキスト ペイロード

診断コンテキストの実際のコンテキスト データの格納先。「コンテキスト作成」、「診断コンテキスト」、および「要求の仕分け」も参照してください。

データ ストア

表形式で表されたデータ (レコード) の集合。表の各レコードがデータを表します。テーブルのカラムにはデータのいろいろな特性が記述されます。さまざまなデータ ストアに多様なカラムがあり得ますが、データ項目が収集された時間など、ほとんどのデータ ストアで共有されるカラムもあります。

WebLogic Server では、WebLogic 診断フレームワークでキャプチャした情報は複数の論理データ ストアに分類されて格納されます。論理データ ストアは診断データのタイプ別に分かれています。たとえば、サーバ ログ、HTTP ログ、収集されたメトリックはそれぞれ別のデータ ストアにキャプチャされます。

診断アクション

ポイントカットで定義されているジョインポイントに到達したときに実行される、ビジネス ロジックまたは診断コード。診断アクションは特定のポイントカットに関連付けられます。診断アクションにはジョインポイントで実行するコードが指定されます。別の言い方で言うと、ポイントカットでは場所が宣言され、診断アクションではそのポイントカットが特定する場所で何が実行されるかが宣言されます。

診断アクションを使用すると、実行中のサーバおよびアプリケーションの状態を認識できます。診断アクションによって、その場所 (ポイントカット) で行われる診断アクティビティが指定されます。ポイントカットは、そのポイントカットが実装されているモニタで定義されます。診断モニタはアクションが定義されていて初めて実用に役立ちます。

診断アクションの機能によっては、指定された作業をするために特定の環境が必要なことがあります。そうした環境は必ず、その診断アクションが関連付けられているモニタで提供されます。したがって、診断アクションは対応するモニタとのみ使用できます。そのため、診断アクションはタイプ別に分類されていて、対応するモニタを判断できるようになっています。

有用な診断モニタを簡単に実装できるようにするため、WebLogic Server 製品には適切な診断アクションのライブラリが用意されています。

診断コンテキスト

WebLogic 診断フレームワークですべての要求についてシステムに届いたときに付加されるコンテキスト情報。このコンテキスト情報が診断コンテキストと呼ばれ、これを使用してトランザクション イベントを再構築したり、発生の時期や論理的な関係に基づいてイベントを相互に関連付けたりできます。診断コンテキストを使用すると、要求から応答までの実行の流れを再構築したりつなぎ合わせたりできます。

診断コンテキストは、ロギング サービスや診断モニタなどのさまざまな診断コンポーネントで、生成されたデータ イベントへのタグ付けに使用されます。WebLogic 診断フレームワークやサード パーティのツールでこのタグを使用して、診断データの照合、フィルタ処理、相互の関連付けができます。

また診断コンテキストでは、診断コンテキスト内のコンテキスト情報が一定の基準を満たしている場合にのみ、診断情報が生成されるようにもできます。この機能により、生成される情報量を管理可能なレベルに保つことで、そのような情報生成のオーバーヘッドを比較的低く抑えておけます。「コンテキスト作成」、「コンテキスト ペイロード」、および「要求の仕分け」も参照してください。

診断イメージ

サーバのインスタンスから得られた主要な状態を格納するアーティファクト。重大な障害の診断目的でサーバ レベルの状態ダンプとして利用するために作成されます。このアーティファクトを使用すると、サーバの電源をいったん切って入れなおした後にも問題を診断して分析できます。各診断イメージには概要を表すアーティファクトがあります。このアーティファクトには少なくとも以下のような要素が含まれます。

- 診断イメージの作成日および作成時間

- キャプチャ要求のソース

- 診断イメージに含まれる各イメージ ソースの名前と処理にかかった時間

- Java 仮想マシン (Java Virtual Machine : JVM) およびオペレーティング システムの情報 (入手可能な場合)

- コマンドライン引数 (入手可能な場合)

- ネットワークのマルチプレクサのバージョン (入手可能な場合)

- WebLogic Server のバージョン (パッチおよびビルド番号情報を含む)

診断モジュール

WebLogic 診断フレームワークに適用されるコンフィグレーション設定の定義。このコンフィグレーション設定により、収集して処理するデータ、そのデータの分析方法とアーカイブ方法、発生させる通知と警告、および診断イメージ キャプチャ コンポーネントの操作パラメータが決まります。診断モジュールは定義 (コンフィグレーション) した後に、収集されるデータのある実行中のサーバに配布できます。

通常、モニタされるシステムの複雑さに応じて、多数のソースから診断データが収集されます。すべてのソースから常にデータを収集すると大量のデータが収集されることになりかねず、収集するためにかなりのシステム リソースが必要になり、またその評価にもたくさんの人時が必要になります。そのような方法の代わりに、ソースの一部をモニタするよう定義する機能を利用して、システムと人的資源を節約できます。さらに、診断モジュールの定義機能によって、収集するデータをシステムとその使用される環境の両方のニーズを満たすように設計することが可能になります。診断モジュールの定義機能を用いると、保守性と生産性にはっきりと良い影響が現れることがあります。

WebLogic Server では、1 つの診断モジュールを定義してから、それを 1 つまたは複数の個別サーバやサーバのクラスタに割り当てられます。1 つのサーバに同時に割り当てられる診断モジュールは 1 つのみです。

診断モニタ

1) プログラム内で診断コードが追加される場所と 2) その場所で実行される診断アクションを定義するひとまとまりの診断コード。

WebLogic Server には、有用な診断モニタのライブラリが用意されています。それらのモニタをサーバ クラスやアプリケーション クラスに統合できます。統合した後には、サーバ クラスについてはサーバの起動時、アプリケーション クラスについてはアプリケーションのデプロイメントまたは再デプロイメント時に、モニタが有効になります。

診断通知

監視ルールの評価に合格した結果として発生するアクション。WebLogic 診断フレームワークでは、次の 4 種類の診断通知がサポートされています。Java Management Extensions (JMX)、Java Message Service (JMS)、Simple Mail Transfer Protocol (SMTP)、および Simple Network Management Protocol (SNMP)。

仕分けフィルタ

仕分けマスクを確認し、診断モニタでデータ イベントを生成するためにアクションを実行すべきかどうかを決定するプロセス。仕分けフィルタは仕分けマスクに依存しています。仕分けフィルタ処理を行うには、仕分けマスクを定義する必要があります。「仕分けマスク」および「要求の仕分け」も参照してください。

仕分けマスク

データ イベントを生成するかしないかを決定するために仕分けフィルタで使用する、あらかじめ定義された一連の条件を格納するエンティティ。仕分けマスクをコンフィグレーションするには、システム リソースの記述子を使用します。「仕分けフィルタ」および「要求の仕分け」も参照してください。

収集可能エンティティ

ハーベスタを介してデータの消費に利用できる任意のエンティティ。エンティティが収集可能なリソースとして識別されると、ハーベスタでそのエンティティをデータ収集のプロセスに関与させられるようになります。

収集可能エンティティでは、次の情報へのアクセスが提供されます。収集可能な属性、収集可能な属性の値、収集可能な属性のメタデータ、および収集可能エンティティの名前。「収集可能データ」、「収集対象データ」、「ハーベスタ コンフィグレーション データ セット」、および「MBean 型検出」も参照してください。

収集可能データ

収集されるようにコンフィグレーションされた場合に、収集される可能性のあるデータ (型、インスタンス、属性) のセット。したがって、収集可能データのセットは、どのデータが収集されるようにコンフィグレーションされているか、またどのデータ サンプルが取得されるかという指定とは無関係に存在します。

WLDFHarvesterRuntimeMBean で、ユーザ向けに収集可能データのセットが提供されます。この MBean で提供される収集可能データの詳細については、『WebLogic Server MBean リファレンス』で weblogic.management.runtime.WLDFHarvesterRuntimeMBean に関する説明を参照してください。

WebLogic 診断フレームワークでは、MBean が単に収集可能になり得る状態として提供されます。MBean を収集可能な状態にするには、その MBean がローカルの WebLogic Server 実行時 MBean サーバに登録されている必要があります。「収集可能エンティティ」、「収集対象データ」、「ハーベスタ コンフィグレーション データ セット」、および「MBean 型検出」も参照してください。

収集対象データ

現在収集されている型、インスタンス、または属性。この定義の基準に合致するデータは、1) 収集されるようにコンフィグレーションされていて、2) これに該当する場合には必ず検出されていて、3) 収集されている間に例外が送出されない必要があります。

コンフィグレーションがロードされる場合、収集対象の項目のセットは、WebLogic Server MBean タイプのコンフィグレーション済みの項目のセットと同じです。コンフィグレーション済みのカスタム定義のデータは、そのデータが検出されたときに追加されます。そのため、WebLogic Server タイプとカスタム定義タイプの両方の収集対象インスタンスのリストは、MBean が追加されるにつれて増大する場合があります。また、カスタム定義のデータに関しては、新しいインスタンスの導入によって収集対象の型および属性のリストも増大する場合があります。ただし、ハーベスタで特定の項目を収集できないことが検出された場合、その項目は削除されるのでリストは縮小します。ハーベスタのコンフィグレーションが変更されると、収集対象データのセットは再計算されます。

WLDFHarvesterRuntimeMBean で、ユーザ向けに収集対象データのセットが提供されます。この MBean から返される情報は、変更の可能性もある状態のスナップショットと見なす必要があります。この MBean で提供される収集対象データの詳細については、『WebLogic Server MBean リファレンス』で weblogic.management.runtime.WLDFHarvesterRuntimeMBean に関する説明を参照してください。「収集可能エンティティ」、「収集可能データ」、「ハーベスタ コンフィグレーション データ セット」、および「MBean 型検出」も参照してください。

ハーベスタ コンフィグレーション データ セット

ハーベスタのコンフィグレーションに定義されているとおりに収集されるデータのセット。コンフィグレーションされるデータのセットには、収集可能でない項目や現在収集されていない項目も含められます。

収集可能な MBean のセットは、収集可能なインスタンスのセットから構成されます。このセットは、MBean サーバに対する MBean の登録や削除に従って増大したり縮小したりするので、動的です。そのため一部のデータが適正な動作として、あるときには収集可能、別のときには収集不可能になる場合もあります。また、このセットが動的であることから、コンフィグレーションが適正であってもそのコンフィグレーションどおりにデータが利用できない状況になることもあります。ハーベスタによる検証は、このような動的な状況に対応できるように設計されています。

Administration Console を使用すると、収集可能な型、収集可能な型のインスタンス、収集可能な型の収集可能な属性などの、コンフィグレーションできる収集可能データのリストが表示され、それを利用して簡単にコンフィグレーション プロセスを進められます。WebLogic Server MBean データについては常に完全な情報がリストされますが、カスタム MBean については動的に検出された情報が表示されます。「収集可能エンティティ」、「収集可能データ」、「収集対象データ」、および「ハーベスタ コンフィグレーション データ セット」も参照してください。

ジョインポイント

プログラム フロー中に明確に定義された、診断コードを追加できる場所。インスツルメンテーション コンポーネントでは、このような診断ジョインポイントを一般的な式で表して識別できます。

ポイントカット

明確に定義されたジョインポイントのセット。通常、一般的な式で識別されます。ポイントカットにより、ジョインポイントが識別されます。ジョインポイントは、メソッド呼び出しやデータ変数へのアクセスなどの実行フロー中の明確なポイントです。インスツルメンテーション コンポーネントのメカニズムを使用すると、このようなポイントカットで特定の診断コードを実行できます。そうした診断コードは、インスツルメンテーション コンポーネントによってサーバ コードやアプリケーション コードに追加されます。

MBean (管理対象 Bean)

基底のリソースの管理インタフェースを提供する Java オブジェクト。MBean は Java Management Extensions (JMX) の一部です。

WebLogic 診断フレームワークでは、MBean クラスを使用してサービスをコンフィグレーションし、サービスの実行時状態をモニタします。MBean は、WebLogic Server の内部で稼動する MBean サーバに登録されます。MBean は、標準 MBean として実装されます。つまり、各クラスに独自の MBean インタフェースが実装されます。

MBean 型検出

WebLogic Server エンティティについては、収集可能な型のセットはシステムの起動時に明らかですが、収集可能なインスタンスの完全なセットは不明です。一方、カスタム定義の MBean については、実行時に MBean が増えると、型のセットも動的に増大します。新しい MBean の登録に基づいて新しい型を検出するプロセスを、型検出と呼びます。MBean 型検出は、カスタム MBean にのみ適用されます。

MBean 型のメタデータ

型 (またはその型のインスタンス) において収集可能な属性のセットは、その型のメタデータで定義されます。WebLogic Server モデルが MBean であるため、このメタデータは MBeanInfo を通じて提供されます。WebLogic 型の情報は常に利用できるので、WebLogic Server 型 (および既存のインスタンスと将来作成されるインスタンス) の収集可能な属性のセットも常に利用できます。一方、カスタム定義の型では、その型が存在するかどうかによって収集可能な属性のセットが認識されるかどうかが決まります。型が存在するようになるのは、少なくとも 1 つのインスタンスが作成されたときからです。そのため、ユーザ定義の型の収集可能な属性のリストは、その型のインスタンスが少なくとも 1 つ登録されるまでは不明です。

カスタム MBean の情報が利用可能になるまでのレイテンシについて留意しておくことは重要です。このレイテンシがあることにより、Administration Console ではハーベスタをコンフィグレーションするためにユーザが選択したリストですべての収集可能データを一覧表示できません。WebLogic Server エンティティの収集可能データのセットは常に完全なものですが、カスタム定義のエンティティの収集可能データのセットは (さらにはエンティティのセット自体も) 不完全な場合があります。

メタデータ

WebLogic 診断フレームワークで収集する情報を説明する情報。このサービスではさまざまなソースから診断情報を収集するため、どの診断情報が収集され利用できるのかをその情報を消費する側で認識する必要があります。このようなニーズを満たすために、このメタデータをプログラム的に取得する機能がデータ アクセサに備わっています。データ アクセサを用いて入手できるメタデータには次のようなものがあります。1) サポートされているデータ ストアのタイプ。たとえば、SERVER_LOGHTTP_LOGHARVESTED_DATA。2) 利用可能なデータ ストアのリスト。3) 各データ ストアのレイアウト (データ ストア内のカラムの情報)。

メトリック

システム処理のモニタや問題の診断は、実行中のシステムから取得したデータに基づいて行われます。メトリックは、システムのパフォーマンスの測定値です。サポート担当者は、こうした測定値からシステムが正常に動作しているのか問題が生じているのかを判断できます。

通常、メトリックは限定された MBean の属性として WebLogic 診断フレームワークに公開されます。WebLogic Server におけるメトリックには、オペレーティング システム、仮想マシン、システム ランタイム、およびサーバで実行中のアプリケーションに関するパフォーマンス測定値があります。

要求の仕分け

要求が重要であることを示すために、その要求を仕分け (特別にマーク) できます。たとえば、実行中のシステムで特別にマークされたテスト要求を送信して、その要求を追跡用のモニタで条件付きで追跡できるようにすることが望ましい場合があります。この仕分け機能を利用すると、特別に焦点を絞った診断情報を作成できます。それによって他の要求の処理が遅くなることもありません。

通常、要求はシステムに届いたときに診断コンテキストでフラグを設定することによりマークされます。診断コンテキストには多数のフラグが用意されています。これらは全部で 64 個で、個別に設定したりリセットしたりできます。

56 ~ 63 の仕分けフラグのみを、アプリケーションで使用できます。他の仕分けフラグはすべて WebLogic 診断フレームワーク コンポーネントおよびライブラリで使用するために予約されています。

DyeInjection モニタを使用すると、こうしたフラグをそのコンフィグレーションと要求のプロパティに基づいて要求がシステムに届いたときにオンにできます。オンにした後には、他の診断モニタでこれらのフラグ (仕分け) を利用して、特定のアクションを条件付きで実行できます。たとえば、要求の発信元が特定のアドレスである場合にのみ診断アクションを実行するように診断モニタをコンフィグレーションする、といったことが可能です。「コンテキスト作成」、「コンテキスト ペイロード」、および「診断コンテキスト」も参照してください。

システム イメージ キャプチャ

システム障害の際には、必ず障害が発生したときのシステム状態の確認が必要になります。そのため、障害の診断には障害発生時のシステム状態をキャプチャする手段が重要な意味を持ちます。その手段がシステム イメージ キャプチャです。システム イメージ キャプチャでは基本的に、重大な障害の診断を目的としてシステムから診断スナップショット (ダンプ) が作成されます。

WebLogic Server では WebLogic 診断フレームワークをコンフィグレーションすることにより、その第一障害通知機能でサーバが異常停止した際に自動的にシステム イメージ キャプチャをトリガできます。また、監視を実装して重大な障害の発生時に自動的に診断イメージ キャプチャをトリガしたり、必要に応じて手動で診断イメージ キャプチャを開始したりできます。

監視

監視ルールに関するすべての情報がカプセル化されたもの。監視には、監視ルール式、監視に対するアラームの設定、および監視ルール式が true と評価されると開始されるさまざまな通知ハンドラが格納されます。

ウィービング時間

サーバ クラスやアプリケーション クラスをロードして、それらの明確な場所に診断バイト コードを挿入するためにかかる時間。診断バイト コードを使用すると WebLogic 診断フレームワークで診断アクションを実行できます。ウィービング時間は、サーバ レベルでインスツルメントされたクラスのロード時間とアプリケーション レベルのクラスのアプリケーション デプロイメント時間の両方に影響します。

 

ページの先頭 前 次