|
|
BEA AquaLogic Service Bus では、システム処理の実行時情報をモニタおよび収集できます。AquaLogic Service Bus で集約された実行時統計は、カスタマイズ可能なダッシュボードに表示できます。ダッシュボードでは、システムのヘルス状態をモニタし、メッセージング サービスの問題があった場合にアラートを受けることができます。この情報を使用すると、時間をかけずに簡単に、発生した問題を特定し、診断できます。
以下の節では、AquaLogic Service Bus Console でメッセージおよびシステムの処理をモニタする際に使用できるツールと機能について説明します。内容は次のとおりです。
AquaLogic Service Bus Console の [ダッシュボード] ページでは、すべてのサーバとモニタされたサービスの状態を即座に表示できます。ダッシュボードには、2 つの円グラフ、1 つのテーブル、およびいくつかのリンクが表示されます。[サービス概要] 円グラフには、すべてのサービスの重大度に従って、直前の 30 分間に発行されたアラートの割合が示されます。[サーバ概要] 円グラフには、AquaLogic Service Bus ドメインにあるすべてのサーバの現在の状態が示されます。また、[サーバ概要] パネルから、重大度に従ってグループ化されたドメイン ログを表示することもできます。
円グラフに加え、これらの概要には最もアクティブなサービスと重大度が最も高いサーバのリストが表示されます。リストには、アラート数の最も多いものから順に最大 10 個のサービスが完全修飾サービス名で表示されます。重大度が最も高いサーバのリストには、重大度が最も高いサーバが 10 個まで表示されます。これは、WebLogic 診断サービスでの定義に従い、実行中のサーバのヘルス状態に基づいて表示されます。WebLogic 診断サービスの詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』を参照してください。
このページの各概要で、円グラフの特定の領域をクリックするか、リンクのいずれかをクリックすると、さらに詳細な情報を表示できます。
[アラート概要] テーブルには、直前の 30 分間に発行されたアラートのリストが表示されます。このテーブルには、以下のフィールドが含まれます。
AquaLogic Service Bus Console にログインすると、ダッシュボードにアラートのリストが表示されます。このリストは動的に更新されます。これらのアラートは、SLA 違反またはパイプライン アラートの結果として生成されます。サービス レベル アグリーメント (SLA) は、AquaLogic Service Bus のビジネス サービスとプロキシ サービスで想定される正確なサービス レベルを定義するアグリーメントです。
テーブルの各行には、重大度、タイムスタンプ、関連サービスなど、コンフィグレーションした情報が表示されます。重大度のリンクをクリックすると、アラートの原因の分析に役立つアラートの詳細情報が表示されます。
アラートには、コンソール、電子メール、JMS、レポート、SNMP トラップなど、さまざまなアラート送り先をコンフィグレーションできます。たとえば、アラート通知の送り先として電子メールや JMS を追加したり、送り先をこれらに変更したりできます。
モニタ統計により、特定のサービスで正常に処理されたメッセージと処理に失敗したメッセージの数を把握できます。この情報を調べるには、ダッシュボードで [サービスのモニタの概要] ページにアクセスし、表示をフィルタして該当するサービスを検索します。正常に処理されたメッセージまたは処理に失敗したメッセージの数を表示するだけでなく、サービスが属するプロジェクト、メッセージ処理の平均実行時間、およびサービスに関連するアラートの数を表示することもできます。現在の集約間隔のモニタ統計を表示できます。また、このサービスの統計を最後にリセットした時点、またはすべてのサービスの統計を最後にリセットした時点以降の期間のモニタ統計を表示できます。
統計をリセットするには、AquaLogic Service Bus Console の [システムの管理] モジュールにある [グローバル設定] ページを使用します。これを行うときは、WebLogic Server Administration Console の WebLogic セッション内で作業していないことを確認してください。
サービスの名前をクリックすると、そのサービスの [サービスのモニタの詳細] ページが表示されます。このページには、最小/最大応答時間およびサービスでのメッセージの実行にかかる全体の平均時間、成功と失敗の割合、セキュリティまたは検証のエラーのために失敗したメッセージの数、プロキシ サービス コンポーネント (パイプラインとルート ノード) に関連するメッセージの数などの情報が表示されます。サービスに関連付けられている特定のオペレーションの情報を表示できます。前述の場合と同様に、現在の集約間隔でのこれらの統計を表示できます。また、このサービスの統計を最後にリセットした時点、もしくは、すべてのサービスの統計を最後にリセットした時点からの期間の統計を表示できます。
サービス レベル アグリーメントを検証するには、以下の使用例を考慮してください。
特定のプロキシ サービスで、応答時間の低下が原因で SLA 違反の多数のアラートが生成されているとします。この問題をさらに調査するには、AquaLogic Service Bus Console にログインし、このプロキシ サービスの詳しい統計を調べる必要があります。このレベルで、パイプラインにおけるサードパーティの Web サービス呼び出しステージに非常に時間がかかっており、これが実際のボトルネックになっていることを特定できます。サードパーティの Web サービス プロバイダとのサービスレベル特性の再ネゴシエーションに成功したら、この Web サービス プロバイダが新しいアグリーメント条件に準拠しているかどうかを追跡するアラート メトリックをコンフィグレーションします。このように、サービス レベル アグリーメントのネゴシエーションの基盤としてアラートを使用できます。
アラート アクションを使用して、パイプラインのステージ内でアラートを生成することもできます。これを行うには、[アクション] メニューの [レポート] カテゴリにある [アラート] アクションを使用します。
XQuery エディタなどのパイプライン エディタで使用できる条件構文や if-then-else 構文を使用して、パイプライン アラートをトリガする条件を定義します。アラート アクションで [アラート送り先] リソースを使用すると、アラートの送り先を定義できます。パイプラインを含むアラート本文とコンテキスト変数を完全に制御できるようになります。また、メッセージの一部を抽出することもできます。
AquaLogic Service Bus Console の [ダッシュボード] ページに、サービスで生成されたすべてのアラートをまとめて表示できます。
| 注意 : | ステージでのアラート アクションの追加方法の詳細については、『AquaLogic Service Bus Console の使い方』のプロキシ サービス : アクション - アラートを参照してください。 |
以下のアラート送り先のいずれかを使用してアラートを表示できます。
ダッシュボードには、AquaLogic Service Bus の全般的なヘルス関連の情報が表示されます。サーバ、サービス、およびアラートで構成されたシステムの状態の概要が示されます。
モニタを有効にした後、AquaLogic Service Bus Console の [サービスのモニタの概要] ページには、収集された各サービスの統計が表示されます。SLA 違反によって生成されたアラート、またはパイプラインにコンフィグレーションされたアラート アクションの結果として生成されたアラートの情報が示されます。
前に説明したように、SLA は AquaLogic Service Bus のビジネス サービスとプロキシ サービスで想定される正確なサービス レベルを定義するアグリーメントです。ユーザは SLA マネージャで AquaLogic サービス コンフィグレーション モジュールを利用して、SLA ルールの条件とアクションをコンフィグレーションできます。SLA マネージャでは、集約機能で提供されるデータを使用して SLA 違反をモニタし、アラート ルール アクションのコンフィグレーションに従って通知を送信します。SLA マネージャは常に集約機能と共にデプロイされ、クラスタ内の 1 つの管理対象サーバに置かれます。SLA マネージャは、アラートをアラート ログに送信してアラート ストアに格納します。
電子メールは、アラートの送り先の 1 つです。このアラート送り先をコンフィグレーションするには、まず SMTP グローバル リソースをコンフィグレーションする必要があります。このリソースは、電子メール送り先に対応する SMTP サーバのアドレス、ポート番号、および必要に応じて認証資格を取り込みます。この認証資格は、サービス アカウントとして格納されるのではなく、インラインで格納されます。アラート アクションは、SMTP リソースを利用して発信電子メール メッセージを送信します。SMTP リソースを使用してパイプライン アラートと SLA アラートの両方を送信することもできます。アラートが電子メールで配信されるときに、アラートの詳細で構成されるメタデータが、コンフィグレーションされたペイロードにプレフィックスされます。
| 注意 : | SMTP サーバ リソースの詳細については、『AquaLogic Service Bus Console の使い方』の「SMTP サーバの概要」を参照してください。 |
簡易ネットワーク管理プロトコル (SNMP) トラップにより、サードパーティ製ソフトウェアを AquaLogic Service Bus でのサービス レベル アグリーメント (SLA) のモニタに結びつけることができます。SNMP を使用してアラートの通知を有効にすることで、Web サービス管理 (WSM) ツールおよび ESM (Enterprise Service Management) ツールは、アラート通知をモニタして SLA 違反をモニタできます。
簡易ネットワーク管理プロトコル (SNMP) は、リソースの管理に関する情報をネットワーク上で交換できるようにするアプリケーション層プロトコルです。SNMP により、リソースをモニタし、必要に応じて、リソースから取得したデータに基づいてリソースを修正できます。AquaLogic Service Bus のこのバージョンでは、SNMP version 1 と SNMP version 2 の両方がサポートされています。SNMP は、以下のコンポーネントで構成されます。
これは、モニタされているリソースです。リソースとその属性が管理情報ベース (MIB)
管理情報ベース (MIB) は、モニタ対象のすべてのリソースを階層的に格納する階層データ構造です。また、MIB はモニタされるリソースの属性も格納します。各リソースには、オブジェクト識別子 (OID) と呼ばれるユニークな識別子が割り当てられます。SNMP コマンドを使用してリソースの管理に関する情報を取得できます。次の節では、WebLogic Server MIB について説明します。
Weblogic Server インストーラは、以下の場所に MIB のコピーを作成します。
<BEA_HOME>/weblogic92/server/lib/BEA-WEBLOGIC-MIB.asn1
ここで、<BEA_HOME> は WebLogic Server のインストール先のディレクトリです。WebLogic Server は、その管理システムに非常に多くのデータ ポイントをエクスポーズします。WebLogic Server では、このデータを整理するために、階層データ モデルを使用して、ドメイン内で使用できるサービスとリソースの集合を表します。図 3-1 は、MIB 内のオブジェクトの階層を示しています。
たとえば、ドメイン内に MS1 および MS2 という 2 つの管理対象サーバを作成した場合、MIB には、1 つの serverTable オブジェクトが含まれ、このオブジェクトに 1 つの serverName オブジェクトが含まれます。さらに、serverName オブジェクトには、値 MS1 と MS2 をそれぞれ格納する 2 つのインスタンスが含まれます。MIB は、各管理対象オブジェクトにオブジェクト識別子 (OID) と呼ばれるユニークな番号を割り当てます。OID は一度割り当てられると変更できません。各 OID は一連の整数から構成されています。この整数の配列は、MIB ツリー内でのオブジェクトの場所を定義しています。パスの各ノードは、番号とそれ県連付けられた名前を持っています。
WebLogic Server MIB の詳細については、『 WebLogic Server® 9.2 MIB Reference』にある WebLogic Server のドキュメントを参照してください。
各管理対象リソースは、SNMP エージェントを使用して MIB 内の関連情報を更新します。これを行うには、管理対象リソース内で特定の条件を検出し、SNMP マネージャにトラップ通知 (レポート) を送信するように SNMP エージェントをコンフィグレーションする必要があります。以下のいずれかの方法でトラップを生成するように、SNMP エージェントをコンフィグレーションできます。
SNMP マネージャは SNMP エージェントを管理します。また、SNMP マネージャは、ネットワーク管理システムへのプライマリ インタフェースでもあります。
ネットワーク管理システムは、ユーザとのインタフェースを形成します。ネットワーク管理システムは、SNMP マネージャを使用してデータを収集し、ユーザに示します。
Java Messaging Service (JMS) は、パイプライン アラートおよび SLA アラートのもう 1 つの送り先です。アラートの JMS 送り先には JNDI URL を使用します。アラート ルールをコンフィグレーションして JMS 送り先にメッセージをポストする場合、JMS 接続ファクトリおよびキューまたはトピックを作成し、WebLogic Server Administration Console の該当する JMS サーバを対象に設定する必要があります。この方法については、『Weblogic JMS のコンフィグレーションと管理』の JMS システム リソースのコンフィグレーションにある「JMS 接続ファクトリのコンフィグレーション」および「ドメインの相互運用性を実現するための JMS リソースの命名規則」を参照してください。JMS アラート送り先を定義するときは、送り先キューまたは送り先トピックを使用できます。メッセージのタイプは、バイトまたはテキストのいずれかです。JMS アラート送り先のコンフィグレーション方法の詳細については、『AquaLogic Service Bus Console の使い方』の「アラート送り先」を参照してください。
パイプライン アラートと SLA アラートの両方をモニタおよび分析するもう 1 つのプロセスです。このモニタのプロセスは、「レポート」で詳しく説明されています。
AquaLogic Service Bus では、モニタ サブシステムは集約間隔中にメッセージ数や実行時間などの統計情報を収集します。集約間隔とは、統計データが収集され、AquaLogic Service Bus Console に表示されるまでの時間です。
発注書を処理するためのプロキシ サービスをコンフィグレーションし、10 分の集約間隔でモニタを有効にしたとします。ユーザがプロキシ サービスを介して最初のメッセージを送信すると、モニタが開始されます。最初の 10 分が経過するまで、[サービス概要] ページには部分的に計算されたデータが表示されます。この時点で、システムに 10 分間のデータはありません。集約間隔の最初の 10 分が経過した後は、常に直前 10 分間のデータが表示されます。たとえば、14 分経過した時点で、ダッシュボードには 4 ～ 14 分のデータが表示されます。15 分以降メッセージが処理されていない場合、25 分経過した時点でデータは表示されなくなります。集約間隔がモニタ情報の表示に与える影響の詳細については、「アラート ルール」を参照してください。
作成したビジネス サービスまたはプロキシ サービスのモニタは明示的に有効にする必要があります。デフォルトでは、モニタは無効になります。モニタを有効にし、個々のサービスの集約間隔を設定した後、[システムの管理] モジュールの [グローバル設定] ページからこれらすべてのサービスのモニタを有効または無効にできます。詳細については、「サービスのモニタ」を参照してください。
SLA アラートは、サービス レベル アグリーメント (SLA) の違反または発生に対する応答を自動化したものであり、ダッシュボードに表示されます。ビジネスおよびパフォーマンスの要件に従い、許容できないサービス パフォーマンスを指定するアラート ルールを定義します。アラート ルールをコンフィグレーションするときに、アラート ルールごとにそのルールの集約間隔を指定できます。この集約間隔は、サービスに設定された集約間隔の影響を受けません。アラート ルールにより、違反に関するトピックにコンフィグレーションされたアラート送り先に通知を送信できます。アラート ルールの定義については、『AquaLogic Service Bus Console の使い方』の「アラート ルールの作成」を参照してください。
次の図に、AquaLogic Service Bus モニタのアーキテクチャを示します。
統計コンフィグレーション マネージャでは、操作リソースごとの統計コンフィグレーションを保存し、管理します。操作リソースは、モニタ サブシステムにより統計情報を収集できる単位として定義されます。操作リソースには、プロキシ サービス、サービス操作、およびパイプラインがあります。パイプラインの追加、更新、削除などのサービス定義の変更は、統計コンフィグレーション マネージャに通知されます。
クラスタ内の管理対象サーバがそれぞれ統計コレクタをホストします。統計コレクタは、統計コンフィグレーション マネージャの指示に従って、操作リソースの統計を収集します。また、集約間隔の時間が経過するまで、収集した統計のサンプル履歴も保持します。システム定義のチェックポイント間隔ごとに、統計コレクタは回復の目的で現在の統計のスナップショットを永続ストアに格納し、情報を統計集約機能に送信します。
クラスタ内の管理対象サーバの 1 つはクラスタ全体の統計の集約機能に指定され、「集約サーバ」または「アグリゲータ」と呼ばれます。システム定義のチェックポイント間隔ごとに、クラスタの各管理対象サーバは統計のチェックポイント スナップショットを集約機能に送信します。次に、集約機能はこの情報を結合し、クラスタ全体の統計を統計取得 API によりクライアントに提供します。集約機能のクライアントはダッシュボード、SLA マネージャ、およびサービス モニタ モジュールです。
システムにデータ ポイントを提供するために、ランタイム プロキシ サービス パイプライン などのシステムの操作リソースが統計コレクタのメソッドを呼び出し、そのリソース自体、統計、およびデータ ポイントを示します。
ビジネス サービスまたはプロキシ サービスを作成した場合、そのサービスのモニタはデフォルトでは無効です。モニタを有効にする方法は以下のとおりです。
| 注意 : | [モニタを有効化] オプションを使用すると、個々にモニタを有効にしたすべてのサービスのモニタを有効または無効にできます。特定のサービスのモニタを有効にしていない場合、システムがそのサービスの統計の収集を開始する前に、[モニタの管理] ページでモニタを有効にし、集約間隔を設定しておく必要があります。 |
アラート ルールを作成する場合、ルールを作成する前にモニタを有効にする必要があります。詳細については、「アラート ルール」、および『AquaLogic Service Bus Console の使い方』の「モニタ」にある「アラート ルールの作成」を参照してください。
実行時の [ダッシュボード] ページのデフォルトの更新間隔は 1 分です。ただし、情報がダッシュボードに表示されるまでに最大 3 分かかることがあります。このような遅延が発生するのは、プロキシ サービスがメッセージを処理した時間、メトリックが収集された時間、およびダッシュボードの更新間隔に時間のずれがあるためです。システムは次のように動作します。
たとえば、図 3-3 に示すように、プロキシ サービスが T1 でデータの送信を開始します。T2 (2 分目) で、統計コレクタがデータを集約機能に送信します。しかし、集約機能は、集約サイクルをすでに開始している場合は次の集約サイクルまでこのデータを結合しません。次のサイクルは、前の集約サイクルから 1 分後または最大 2 分後に始まります。データが結合されたら、AquaLogic Service Bus Console に表示できるようになります。コンソールは 1 分ごとに更新されるため、更新サイクルが直前に始まっていた場合、最大 3 分が経過するまでアラートはコンソールに表示されません。
ダッシュボードのポーリング間隔は、AquaLogic Service Bus Console の [システムの管理] モジュールで変更できます。この方法については、『AquaLogic Service Bus Console の使い方』の「システムの管理」にある「ダッシュボードを更新するポーリング間隔の設定」を参照してください。
AquaLogic Service Bus Console にログオンすると、ダッシュボードが自動的に表示されます。ダッシュボードには、直前 30 分間のモニタ情報が表示されます。次の図に示すように、サーバ、サービス、およびアラートで構成されるシステムの状態の概要が表示されます。
この図に示すように、ダッシュボードには以下の情報が表示されます。
ダッシュボードから、サービスの平均実行時間、アラートの発生日時、サーバの実行時間など、システム固有の詳細な情報を容易に取得できます。
ダッシュボードとモニタは、AquaLogic Service Bus Console でコンフィグレーションします。詳細については、『AquaLogic Service Bus Console の使い方』の「モニタ」および「システムの管理」にある各節を参照してください。
[サービス概要] パネルには、サービスの状態の概要が表示されます。[サービス概要] 円グラフには、アラートが定義され、直前の 30 分間モニタが有効になっていたすべてのサービスの重大度に従って、アラートの割合が示されます。アラートの重大度レベルはユーザがコンフィグレーションでき、絶対的な意味はありません。重大度のタイプには、致命的、重大、重要、軽度、警告、通常などがあります。次の図に示すように、最も多くのアラートを発生させたサービスが円グラフの下に表示されます。アラートの最も多いサービスから順に最大 10 個のサービスが表示されます。
![[サービス概要] ペイン](wwimages/service_summary_pane.gif)
[サービス概要] パネルから、以下の部分をクリックして、アラートに関する詳細情報にアクセスできます。
| 警告 : | サービス (またはパイプライン ノードなどのコンポーネント) の名前を変更するか場所を移動すると、統計データは失われます。 |
詳細なアラート情報へのアクセス方法については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「ダッシュボードの統計の表示」を参照してください。
次の 2 つの図に示すように、[サービスのモニタの概要] ページには、サービスのモニタ統計の 2 つのビューが表示されます。
1 つ目は、各サービスで収集された統計データの動的ビューです。このビューは、[次のメトリックの表示] フィールドで [現在の集約間隔] を選択すると表示されます。このビューに表示される集約間隔によって、表示される統計が決まります。たとえば、特定のサービスの集約間隔が 20 分である場合、そのサービスの行には直前 20 分間に収集されたデータが表示されます。
![[サービスのモニタの概要] ページ - 現在の集約間隔](wwimages/service_summary_currentaggregationinterval.gif)
2 つ目のビューはメトリックの集計カウントです。このビューは、[次のメトリックの表示] フィールドで [最後のリセット以降] を選択すると表示されます。各行に表示される統計は、個々のサービスの統計を最後にリセットした時点、または [システムの管理] モジュールにある [グローバル設定] ページで、すべてのサービスの統計を最後にリセットした時点以降の統計です。
![[サービスのモニタの概要] ページ - 最後のリセット以降](wwimages/service_summary_sincelastreset.gif)
この図に示すように、情報の表示はページ上部で以下の条件を使用してフィルタできます。
[サービスのモニタの概要] テーブルには、以下の情報が表示されます。
| 注意 : | [次のメトリックの表示] フィールドで [最後のリセット以降] を選択すると、[アクション] カラムが表示されます。このカラムでは、特定のサービスについて [統計のリセット] アイコンをクリックし、そのサービスの統計をリセットすることができます。リセットを確定すると、[統計のリセット] アイコンを最後にクリックした時点、または [グローバル設定] ページで [統計のリセット] を最後にクリックした時点以降に収集された、そのサービスのすべてのモニタ統計が削除されます。ただし、サービスの現在の集約間隔において収集中の統計は削除されません。[統計のリセット] アイコンをクリックすると、サービスのモニタ統計の収集が即座に再び開始されます。 |
次の 2 つの図に示すように、[サービスのモニタの詳細] ページには、特定のサービスに関する詳細情報の 2 つのビューが表示されます。
1 つ目は、サービスで収集された統計データの動的ビューです。このビューは、[次のメトリックの表示] フィールドで [現在の集約間隔] を選択すると表示されます。このビューに表示される集約間隔によって、表示される統計が決まります。たとえば、このサービスの集約間隔が 20 分である場合、このビューには直前 20 分間に収集されたデータが表示されます。
![[サービスのモニタの詳細] ページ - 現在の集約間隔](wwimages/service_detail_currentaggregationinterval.gif)
2 つ目のビューはメトリックの集計カウントです。このビューは、[次のメトリックの表示] フィールドで [最後のリセット以降] を選択すると表示されます。表示される統計は、[システムの管理] モジュールにある [グローバル設定] ページでこの特定のサービスの統計またはすべてのサービスの統計を最後にリセットした時点からのものです。
![[サービスのモニタの詳細] ページ - 最後のリセット以降](wwimages/service_detail_sincelastreset.gif)
[サービスのモニタの詳細] ページには、以下の一連の情報が表示されます。
[サーバ概要] パネルには、サーバの状態の概要が表示されます。円グラフには、ドメインの各サーバの状態が示されます。各サーバの状態は WebLogic 診断サービス (『WebLogic 診断フレームワークのコンフィグレーションと使い方』を参照) から派生します。図 3-10 に示すように、重大度が最も高い 5 個のサーバが表示されます。
![[サーバ概要] ペイン](wwimages/server_summary_pane.gif)
RuntimeMBean を確認してください。RuntimeMBean を確認してください。
AquaLogic Service Bus Console で WebLogic Server のドメイン ログを表示できます。ドメイン ログ ファイルは、ドメイン全体のステータスを確認するための中心となるファイルです。各サーバ インスタンスでは、メッセージのサブセットをドメイン全体のログ ファイルに転送します。デフォルトでは、重大度が NOTICE 以上のメッセージのみが転送されます。転送されるメッセージの集合を変更できます。詳細については、『ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic ロギング サービスについて」を参照してください。
パイプラインにロギング アクションをコンフィグレーションした場合、ログはサーバ ログに転送されます。これらのメッセージをドメイン ログに転送するよう WebLogic Server をコンフィグレーションしていない限り、AquaLogic Service Bus Console からこのログは表示できません。この方法については、WebLogic Server Administration Console オンライン ヘルプの「ログ フィルタの作成」を参照してください。
システムで現在発生したメッセージの数を調べるには、[サーバ概要] パネルの [ログ概要の表示] リンクをクリックします。次の図のように、重大度別に分類されたメッセージ数を示すテーブルが表示されます。
これは、WebLogic 診断サービスでの定義に従い、実行中のサーバのヘルス状態に基づいて表示されます。WebLogic 診断サービスの詳細については、『WebLogic 診断フレームワークのコンフィグレーションと使い方』を参照してください。
特定のタイプのメッセージのドメイン ログを表示するには、そのメッセージのタイプに対応している数字をクリックします。次の図は、AquaLogic Service Bus Console に表示されるドメイン ログ ファイルの例です。
詳細については、『ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic ロギング サービスについて」にある「メッセージの属性」参照してください。
ページにある 1 つのログ ファイルの詳細を表示するには、該当するログのラジオ ボタンを選択し、[表示] ボタンを選択します。
次の図に示すように、[サーバ概要] ページには、サーバのカスタマイズ可能なテーブルが表示されます。
![[サーバ概要] ページ](wwimages/server_summary_table.gif)
図 3-13 に示すように、[サーバ概要] ページの上部には、システムで現在発生しているメッセージの数が表示されます。それぞれのタイプの状態メッセージについては、「ログ概要」を参照してください。
テーブルのこの情報を円グラフまたは棒グラフで表示するには、[グラフで表示] をクリックします。
サーバの表示をフィルタするには、サーバ テーブルの上の [テーブルのカスタマイズ] をクリックします。利用可能なフィルタを次の図に示します。
サーバ概要テーブル フィルタの使用方法については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「サーバ概要の表示のカスタマイズ」を参照してください。
サーバの詳細表示ページにアクセスするには、[重大度が最も高いサーバ] の下のサーバ名をクリックするか、[サーバ概要] ページでサーバ名をクリックします。
サーバの詳細表示ページを使用すると、次の図に示すように、サーバ モニタの詳細を表示できます。
![サーバの詳細ページ - [全般] タブ](wwimages/server_details.gif)
このページに表示される情報は、WebLogic Server Administration Console のサーバの設定ページの [モニタ] タブのサブセットです。以下の詳細情報が表示されます。
詳細については、WebLogic Server Administration Console オンライン ヘルプを参照してください。
AquaLogic Service Bus には、2 つのタイプのアラートを発生させることができます。次の 2 タイプです。
パイプラインにコンフィグレーションされたアラート アクションの実行時にトリガされるアラートは、パイプライン アラートと呼ばれます。レポート カテゴリにグループ化されたアクションを使用できます。レポート カテゴリで使用できるアクションは次のとおりです。
詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。アラートは、アラート送り先を使用してモニタされます。
サービス レベル アグリーメント (SLA) アラートは、サービスがサービス レベル アグリーメントまたは事前定義された条件に違反した場合に生成されます。[アラート概要] パネルには、システムにおける違反またはイベントの発生に関する情報を表示するカスタマイズ可能なテーブルがあります。これらの違反と発生は SLA に基づいています。AquaLogic Service Bus には、プロキシ サービスおよびビジネス サービスをモニタするためにコンフィグレーションできるさまざまな SLA モニタが用意されています。SLA モニタの例としては、最大実行時間、認可の失敗があります。これらのモニタをコンフィグレーションするには、アラート ルールを作成します。ルールが true に評価されると、アラートが発生します。このアラートは、コンソール、SNMP トラップ、レポート ストリーム、電子メール受信者、または JMS キュー/トピックに送信できます。アラートのこれらの送り先は、アラート送り先リソースを使用してコンフィグレーションします。
| 注意 : |
AquaLogic Service Bus Console には、重大度順、サービス順など、アラートを表示し、検索するいくつかの方法が用意されています。また、アラートをグラフィカルに表示することもできます。この方法については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「アラートの表示と検索」および「アラートのグラフの表示」を参照してください。
![[アラート概要リストの表示]](wwimages/alert_summary_pane.gif)
[アラート概要] パネルには直前 30 分間のアラートが表示されます。以下の詳細情報が表示されます。
| 注意 : | [アラート ルール名] の内容がリンクとして機能するのは、(ルール コンフィグレーション情報を保持する) SLA アラートの場合のみです。パイプライン アラートでは機能しません。 |
アラートのリストを表示するには、[アラート概要リストの表示] をクリックしてください。「システム アラート履歴」を参照してください。
[アラート概要] パネルに表示される情報をカスタマイズするには、概要テーブルの上の [テーブルのカスタマイズ] をクリックします。利用可能なフィルタを次の図に示します。
表示するアラートのソート順序をカスタマイズするには、カラム ヘッダの横のソート アイコンをクリックします。
[カスタマイズされたシステム アラート履歴] ページにアクセスするには、[アラート概要] ページで [アラート概要リストの表示] をクリックします。[カスタマイズされたシステム アラート履歴] ページでは、テーブルをスクロールするか (図 3-18 を参照)、またはアラートの表示をフィルタする (図 3-19 を参照) ことで、すべてのアラートを表示できます。
図 3-18 に示すテーブルをカスタマイズし、次の詳細情報を表示できます。
| 注意 : | [アラート ルール名] の内容がリンクとして機能するのは、アラート ルールでコンフィグレーションされた SLA アラートの場合のみです。パイプライン アラートでは機能しません。 |
アラートの円グラフまたは棒グラフを表示するには、テーブルの [グラフを表示] をクリックします。
特定のアラートを検索するには、[カスタマイズされたシステム アラート履歴] テーブルで [テーブルのカスタマイズ] をクリックしてアラートの表示をフィルタできます。次の図に、利用可能なフィルタ オプションを示します。
アラート テーブル フィルタの使用方法については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「アラートの表示のカスタマイズ」を参照してください。
| 注意 : | コンフィグレーションでアラートが発生すると、次の場所にあるドメイン ログにメッセージが送信されます。 |
| 注意 : | <BEA_HOME>\servers\server_name\logs\domain_name.log |
| 注意 : | ここで、 |
| 注意 : | メッセージはアラートとしてログに記録され、BEA-394015 というメッセージ ID が付いています。 |
| 注意 : | メッセージ本文は、以下の詳細情報で構成された文字列です。 |
システム アラートの詳細ページには、アラートに関する詳しい情報が表示されます。次の図に示すように、アラートにアノテーションを追加できます。
ダッシュボードからこのページにアクセスするには、[アラート概要] テーブルの [アラート重大度] をクリックします。このページでは、アラートを削除することもできます。
[アラート ルールの詳細の表示] ページには、次の図に示すように、特定のアラート ルールに関する詳細情報が表示されます。
![[アラート ルールの詳細の表示] ページ](wwimages/alert_rules_details.gif)
| 注意 : | アラート送り先が設定されていない場合でも、アラートは検出されカウントされますが、アラートの重大度は決定できないため、ダッシュボードには反映されません。 |
アラート ルールの定義方法については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「アラート ルールの作成」を参照してください。
すでに説明したように、アラートは SLA 違反に対する応答を自動化したものであり、ダッシュボードに表示されます。ビジネスおよびパフォーマンスの要件に従い、許容できないサービス パフォーマンスを指定するアラート ルールを定義します。アラート ルールをコンフィグレーションするときに、アラート ルールごとにそのルールの集約間隔を指定できます。アラートの集約間隔は、サービスに設定された集約間隔の影響を受けません。
[アラート ルール] ページで [アラート間隔] を [毎回] に設定した場合、アラート ルールが true に評価されるたびに通知が発行されます。[アラート間隔] を [条件を満たす場合に 1 度] に設定した場合、ルールが初めて true に評価されたときに通知が発行されます。それ以降は、条件がリセットされ、もう一度 true に評価されるまで、通知は生成されません。
[アラート間隔] を [毎回] に設定した場合、アラート ルールの発生回数は、集約間隔およびそのルールに関連付けられたサンプル間隔によって異なります。たとえば、集約間隔が 5 分に設定されている場合は、サンプル間隔が 1 分になります。5 つのデータ サンプルが利用可能になると、ルールが評価されます。したがって、ルールは作成されてから約 5 分後に初めて評価され、それ以降は 1 分ごとに評価されます。
[アラート間隔] を [条件を満たす場合に 1 度] に設定した場合、集約間隔で初めてアラートが発生した後は、同じ集約間隔でアラートが再び発生することはありません。
アラート ルールを作成するには、以下の 3 つの定義を行います。
| 注意 : | ルールは、モニタが有効なサービスに対してのみ作成できます。 |
アラート ルールの作成方法の詳細については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「アラート ルールの作成」を参照してください。
質問 1 : 以下の条件式を持つアラート ルールを使用してサービスを作成しました。
集約間隔 : 0 時間 1 分
メッセージ数 = 0
回答 : メッセージ数やエラー数など、サービスに関連する各統計属性のモニタ統計収集は、その統計の値が変化したときに始まります。メッセージ数属性のデータ収集は、最初のメッセージがサービスによって処理され、メッセージ数属性の値が増えたときに始まります。同様に、エラー数統計のデータ収集は、サービスで最初のエラーが発生し、エラー数属性の値が増えたときに始まります。サービスがアイドル状態にあると、そのサービスのモニタ情報は収集されず、その結果アラート ルールはトリガされません。最初のメッセージが処理された後は、サービスがそれ以降要求を受信しなくても、そのサービスのモニタ データは続けて収集されます。サービスが要求を受信したかどうかを調べてください。
質問 2 : これまでは存在しなかった集約間隔で新しいアラート ルールを定義しましたが、そのルールはアラートをまったく発生させていないようです。それより前に作成した他のすべてのルールは正しく動作しています。
回答 : 原因は質問 1 の場合と同じです。新しい集約間隔を使用してルールを作成した後、そのアラート ルールをトリガするには、サービスで少なくとも 1 つの要求を処理する必要があります。異なる集約間隔値で定義された他のルールは、このアラート ルールには影響されません。
質問 3 : サーバを再起動し、サービスでは要求を処理していません。なぜアラートが生成されるのでしょうか。
回答 : モニタ サブシステムでサービスのデータ収集を開始すると、サーバを停止し再起動しても収集プロセスは中断されません。収集されたデータは保持され、統計収集は中断された箇所から再開されます。
質問 4 : 以下のように定義されたアラート ルールがあります。
集約間隔 : 0 時間 5 分
成功率 < 80%
[サービスのモニタの概要] ページには、以下の値が示されています。
この場合、なぜアラートが発生したのでしょうか。この場合の成功率は 80% ではないでしょうか。
回答 : いいえ。表示されたメッセージ数の値は、エラーが発生したメッセージを含め、サービスで処理されたメッセージの総数です。したがって、この場合の成功率は 75% です。
質問 5 : JMS メッセージを送信する集約間隔 10 分のサービスを作成しました。[サービスのモニタの概要] ページにメッセージ数が表示されていましたが、一定時間の経過後、このサービスのメッセージ数が 0 と表示されます。
回答 : [サービスのモニタの概要] ページには、動的な統計が表示されます。この場合、直前 10 分間のメッセージ数が表示されます。直前 10 分間にシステムでメッセージが処理されていなかったため、メッセージ数は 0 と表示されました。
質問 6 : サービスの集約間隔を 10 分から 5 分に変更しました。[サービスのモニタの概要] ページには、すべての統計が 0 と表示されます。このサーバのアラートの 1 つは 2 分の集約間隔を持つ統計要素にコンフィグレーションされていましたが、さらに 1 分経過しても発動しませんでした。
回答 : 1 つのサービスの集約間隔を変更すると、すべてのサービスの統計情報およびそのサービスに関連付けられたアラートが削除されます。アラートは再度初期化され、集約間隔が終了した時点でトリガされます。
質問 7 : ビジネス サービスの 1 つには複数のエンドポイントがあり、フェイルオーバ数 > 0 と定義されたアラート ルールがあります。エンドポイントの 1 つがダウンしたとき、アラートがトリガされました。しかし、サービスに 1 つのエンドポイントしかない場合、このサービスのフェイルオーバ数は増分されず、代わりに、エラーが発生します。
回答 : 再試行回数を 0 より大きい数に設定してください。再試行回数の設定については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」にある「ビジネス サービスの追加」を参照してください。
質問 8 : ダッシュボードにはアラートが生成されたことが示されていますが、[サービスのモニタの詳細] ページの [現在の集約間隔のアラート] フィールドの値は 0 になっています。
回答 : アラート ルールは間隔の完了後に評価されます。これは、チェックポイントの完了後に発生します。ルールが true に評価されると、ルールのアクションがトリガされ、ログが生成されて、間隔数統計属性 ([現在の集約間隔のアラート]) の値が増加されます。このカウンタの更新値は 60 秒後の次のチェックポイントで処理されます。[サービスのモニタの詳細] ページには、アラート生成の約 1 分後の更新された数が表示されます。
質問 9 : 午前 0 時にまたがるルールのアクティブな時間はどのようになりますか。
回答 : ルールのアクティブな時間が 22:00 - 09:00 と指定されている場合を考えてみましょう。
特定の日 (たとえば 6 月 7 日) に、ルールは以下のようにアクティブおよび非アクティブになります。
6 月 6 日午後 10 時 00 分から 6 月 7 日午前 9 時 00 分 - アクティブ
6 月 7 日午前 9 時 01 分から 6 月 7 日午後 9 時 59 分 - 非アクティブ
6 月 7 日午後 10 時 00 分から 6 月 8 日午前 9 時 00 分 - アクティブ
ServerStatistics はダッシュボードに送信されます。ServerStatistics は、その時点のモニタの実行時データを表します。つまり、有効になっているサービスの統計情報が含まれています。
システムが 1 分ごとに受信するデータを集約するのをモニタすることにより、統計取得サブシステムがデータを使用できるようになります。統計コレクタのチェックポイント スレッドに対して、集約機能のスレッドは 15 秒の遅れがあります。
ドメインのモニタを無効にすると、そのドメインの統計の収集が無効になります。次の集約間隔以降はモニタ データは収集されません。つまり、データを取得しようとしても返されるデータがありません。ドメインのモニタを有効にした場合も同様です。最初はデータがまったく表示されませんが、最大 2 分後には、[サービス概要] ページにモニタの結果が表示されます。
次の節では、以下に関連付けられているさまざまな統計について説明します。
サービスには、AquaLogic Service Bus のサービス ディレクトリに登録された着信エンドポイントまたは発信エンドポイントがあります。このようなサービスは、WSDL などのその他のリソースやセキュリティ設定に関連付けられています。表 3-1 に、このリソースのタイプについてレポートされる統計を示します。また、統計のタイプも示しています。
パイプラインペア ノードとルート ノードという 2 つのタイプの FLOW_COMPONENT の統計が収集されます。パイプラインペア ノードとルート ノードの詳細については、「AquaLogic Service Bus でのメッセージ フローの作成」の表 2-1 を参照してください。表 3-2 に FLOW_COMPONENT についてレポートされる統計を示します。
WSDL などの WEBSERVICE_OPERATION に関する統計が収集され、ランタイム XML ファイルに格納されます。表 3-3 に、このリソースのタイプについてレポートされる統計を示します。
監査により AquaLogic Service Bus (ALSB) のコンフィグレーションでの変更を追跡できます。ここでは、実行できる次の 3 つのタイプの監査について簡単に説明します。
AquaLogic Service Bus Console でコンフィグレーションの変更を実行すると、追跡記録が作成され、コンフィグレーションの変更の履歴が保持されます。以前のオブジェクトのイメージのみが保持されます。コンソールを介してセッション中に変更されたコンフィグレーションの変更の履歴とリソースのリストを表示したり、これらにアクセスしたりできます。ただし、コンフィグレーションのすべての情報にアクセスするには、セッションをアクティブ化する必要があります。
実行中にメッセージ フローのパイプライン全体を監査するのは面倒です。ただし、レポート アクションを使用すると、実行中のメッセージ フローのパイプラインの監査を選択して実行できます。メッセージ フローのパイプラインの必要なポイントにレポート アクションを挿入し、必要な情報を抽出します。抽出された情報は、データベースに格納するか、監査レポートを作成するためにレポート ストリームに送信することができます。
メッセージがプロキシ サービスに送信され、転送レベルの認証または Web サービスのセキュリティの違反があった場合、WebLogic Server は監査トレイルを生成します。この監査トレイルを生成するには、WebLogic Server をコンフィグレーションする必要があります。これにより、メッセージ フローのパイプラインで発生するすべてのセキュリティ違反を監査できます。また、ユーザを認証するたびに監査トレイルが生成されます。セキュリティ監査の詳細については、AquaLogic Service Bus のセキュリティ ガイドの「WebLogic Security フレームワークのコンフィグレーション : 主な手順」を参照してください。
  
|
