| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Business Transaction Managementオンライン・ヘルプ リリース12.1.0.6 E59455-01 |
|
前 |
次 |
この章では、Business Transaction Managementを使用して、コンテナ、サービスおよび依存性を検出する方法について説明します。この情報を使用すると、分散アプリケーションの動作、パフォーマンスに問題があるコンポーネント、およびより詳細な監視を必要とするコンポーネントを正確に把握できます。内容は、次のとおりです。
Business Transaction Managementでの検出と監視が可能なサービスおよびコンポーネントのタイプの完全かつ最新のリストは、Business Transaction Management動作保証マトリックスを参照してください。このドキュメントは、http://support.oracle.comで「BTM動作保証」を検索すると参照できます。
検出は、コンポジット・アプリケーションを構成するビジネス・コンポーネントを識別し、ビジネス・コンポーネントと他のビジネス・コンポーネントとの関係(依存性)を理解できるようにするプロセスです。この項では、検出プロセスで必要な情報を正確に取得するために理解しておく必要がある概念およびプロセスについて説明します。次の内容について説明します。
多様なコンポーネント・タイプをBusiness Transaction Managementでモデル化する方法
検出プロセスの手順
大量の中間エンドポイントを含むテクノロジに対して検出を制限する方法
自動的に検出できないサービスを手動で登録する方法
JDBCコールをモデル化する方法
検出の問題を解決する方法については、12.7項「検出問題の解決」を参照してください。
Business Transaction Managementでは、次の要素を検出できます。
アプリケーション・コンポーネント: これには、デプロイされたコンポーネント・タイプを指定する論理サービス、エンドポイント(そのサービスのインスタンス)およびエンドポイントで呼び出すことができる各操作が含まれます。
コンテナ。
コンポーネント間の依存性。
Business Transaction Managementでは、多様なコンポーネント・タイプおよびそれらが存在するコンテナを検出できます。コンポーネント・タイプに関係なく、同じモデルを使用して、相互接続されたコンポーネントが示されます。モデルは、リクエストおよびレスポンスのXMLメッセージを送信することによって相互作用するサービスで構成されます。また、モデルでは、各サービスが、サービスの場所およびそのインタフェースを指定するWSDLで記述されていることを想定しています。コンポーネントがWebサービスではないためにこのようなWSDLが存在しない場合、Business Transaction Managementは、コンポーネントを一貫して処理できるように疑似的なWSDLを作成します。次の図に、モデルを示します。
たとえば、JDBCを介してデータベースにアクセスするEJBを呼び出すWebサービスで構成されるコンポジット・アプリケーションがある場合、それは、XMLメッセージを使用して通信する3つのサービスとしてモデル化されます。Business Transaction Managementコンソールを使用して検出されたコンポーネントを表示すると、これらはサービスとしてリストされ、やり取りされるメッセージはこれらのサービスに属する操作としてリストされます。あるメッセージは、1つの操作のリクエスト・フェーズまたはレスポンス・フェーズのいずれかに相当します。
場合によっては、JAX-WSサービスやJAX-RPCサービスなど、監視されたトラフィック・タイプがこのモデルと完全に適合していることがあります。その他の場合には、Business Transaction Managementで、基本モデルと互換性のある方法を使用してコンポーネント・タイプをマップする必要があります。Webサービス以外のコンポーネントを検出および監視する場合は、このマッピングの詳細が重要になることがあります。
Business Transaction Managementでは、1つのコンポーネントから別のコンポーネントに流れるメッセージ・トラフィックを監視することで、コンポーネントを検出します。また、Business Transaction Managementでは、このトラフィックの監視から派生したデータに基づいて、これらのコンポーネントの相互関係を検出し、その依存性マップを描画できます。依存性情報によって、コンポジット・アプリケーションの実際の動作が正確に示されます。これにより、特定のコンポーネントがまったくコールされていないという事実を警告されることがあり、また、ビジネス・トランザクションを定義するための基礎が提供されます。
検出について理解するうえで最も重要な事実は、検出が完全にトラフィックベースであるということです。監視されているエンドポイントをメッセージが流れていない場合、Business Transaction Managementではアプリケーション・コンポーネントを検出できず、これらのコンポーネント間の依存性を検出することもできません。不確かな場合は、トラフィックを送信します。この項では、監視対象の環境で分散アプリケーション・コンポーネントを検出する手順について概要を示します。詳細は、次の各手順からリンクされている項を参照してください。
検出を実行する前に、監視対象の環境にオブザーバをインストールし、オブザーバ通信ポリシーを構成して、オブザーバ間の通信と、オブザーバで検出されたデータをさらに処理するためのモニターまたはモニター・グループを定義する必要があります。
検出は2つのステージで実行されます。始動ステージでは、監視されるトラフィックによってオブザーバがモニターとの通信を開始し、監視ステージでは、オブザーバからモニターに流れるデータに測定ポリシーが適用されます。これはつまり、作業システムの全体図を作成するのに少し時間がかかる可能性があるということです。このことを表す1つの兆候として、100個のメッセージを送信したのにBusiness Transaction Managementでは98個しか監視されていないと報告された場合、不明となっているメッセージは、検出プロセスを始動する役割を果たしたメッセージということになります。
検出では次の手順を実行します。
システムにトラフィックを送信します。
監視されているコンテナを確認します。ロード・バランサが使用されている場合、これらも表示可能にしておく必要があります。(Business Transaction Managementをインストールした後でコンテナを再起動するのみでは表示可能にならず、表示されるようにするにはトラフィックを送信する必要があります。)
サービスを表示し、監視対象のすべてのサービスが検出されていることを確認します。
サービスの「サマリー」または「分析」タブを参照して、測定が行われていることを確認します。メッセージ・トラフィックに関係するすべてのサービスについて、スループット、トラフィック、最大レスポンス時間および平均レスポンス時間を参照できます。測定値が不正確であるか、または見つからない場合は、Business Transaction Managementでトラフィック測定値を計算するのに十分な時間が経過していないか、監視が無効になっていた可能性があります。
「サービス・マップ」で依存性を参照し、トラフィックがどのようにシステムを流れているかを確認します。
必要に応じて調整します。一般に、検出された図が予想したものと一致しない場合に最初に行うことは、さらに多くのトラフィックを実行して、Business Transaction Managementがシステムのすべての部分を確認するのに十分な時間を確保することです。それでも問題が解決されない場合は、次の1つ以上を実行する必要があります。
検出しようとしているオブジェクトに適したプローブを有効にします。
手動でサービスを登録します。4.5項「手動によるサービスの登録」を参照してください。
バージョニング・ポリシーまたはレプリケーションの問題が原因の検出問題を解決します。
テクノロジによっては、クライアントから直接サービスに流れるメッセージもありますが、その他のメッセージは実際の宛先に到達する前に中間エンドポイントのホストを通過します。このような中間エンドポイントは、メッセージ・システム、ジョブ・スケジュール・システム、分散システムなどの実装で構成されている場合があります。中間エンドポイントを使用するテクノロジのプローブをインストールしている場合、Business Transaction Managementを使用すると、このようなシステムのすべてのエンドポイントを監視するか、またはエッジにあるエンドポイントのみを監視するかを指定できます。多くの場合、これらは目的のビジネス・サービスを直接示すエンドポイントです。デフォルトでは、中間エンドポイントの監視はオフになります。これによって、監視のパフォーマンスが向上し、分散アプリケーションの監視に不要なデータが排除されます。
図4-1に、クライアントからサービス(EP5)にメッセージを伝達するエンドポイントを監視している多数のオブザーバを示します。メッセージ・フローのエッジにあるエンドポイントEP1およびエンドポイントEP4に注目してください。また、コンテキスト情報のリレーを示す点線にも注目してください。すべてのエンドポイントの監視を選択した場合、図に示すすべてのエンドポイントがBusiness Transaction Managementによって検出および監視されます。
図4-2に、監視されるエンドポイントの数を制限した場合のメッセージ・フローのモデル化を示します。この場合、クライアント、EPおよびEP5のみが検出および監視されます。コンテキスト情報は、そのまま変わらずクライアントから最終受信者であるEP5に伝達されます。
オブザーバ通信ポリシーによって、SOA、OSBおよびEJBプローブ用の中間エンドポイントの監視を制御するオプションが提供されます。各種テクノロジを監視するオプションは、それぞれ微妙に異なります。たとえば、EJBの監視では、フローのエッジのモデル化(ローカル・リクエスト・フロー内の最初のローカルEJBのみをモデル化)、すべてのモデル化(すべてのローカルEJBをモデル化)、および何もモデル化しない(ローカルEJBなし)のオプションを使用できます。ローカルEJBをモデル化する方法はEJBのモデル化および監視には影響せず、これらは常に監視されます。オブザーバ通信ポリシーの詳細は、12.1.2項「オブザーバおよびモニターの構成」、特に中間エンドポイントの監視を制御するオプションについて説明している12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。
JDBCプローブが有効でインスタンス・ロギングがオンになっている場合、大量のトランザクションまたはボリュームの大きいJDBCによってBTMリソースが制約されることがあります。また、1つの操作をコールすることで、データベースに対する大量のコールが発生する可能性もあります。たとえば、1つのFusion Application操作が何百ものSQL文に変換される可能性があります。このオーバーヘッドを削減し、リソースを解放するために、Business Transaction Managementでこれらのコールを個々に書き留めるのではなく、サマリーを記録するように選択できます。
JDBCサマリー・モードを使用するが、個々のコールも調査する場合は、データベース管理ツールを使用してこれを行うことができます。JDBCサマリー・オプションの背景にある主な考え方は、BTMパフォーマンスをより効率的にすると同時に、遅い、または問題のあるSQL文の情報を取得できるようにすることです。
オブザーバの通信ポリシーの設定で、JDBCサマリー・モードを有効にするかどうかが決定されます。この項では、JDBCサマリーを有効にした場合にBTMによって表示される情報について説明します。通信ポリシーの詳細は、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。
JDBCサマリーを有効にすると、JDBCコールは次の図のように示されます。
JDBCコールに指定された測定で、コールの平均時間およびコールの数が指定されます。図の場合、22個のコールが作成され、平均時間は20msです。サマリー・モードでは、操作名は常にexecuteになります。(JDBCサマリーが無効の場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて個別に検出されます。)
JDBCサマリーが有効な場合、トランザクション・インスタンスおよびメッセージ・ログの表示に、サービス・コールごとのサマリー・カウントおよびフォルト・カウントを示す2つの列が追加されます。(オブザーバ通信ポリシーでタイムアウト値を指定できます。SQLコール時間がこの値を上回る場合、BTMは追加のタイムアウト・サマリー・メッセージを送信します。)
次の図に、JDBCサマリーが有効な場合に示される追加情報を示します。execute文に対するレスポンス時間の報告のされ方に注意してください(表示の一部分のみが示されています)。サマリー情報を含む行にはすべてシグマ記号のマークが付けられます。
JDBCサマリー・モードをサポートするために、メッセージのリクエスト・フェーズに、aggregateCountおよびaggregateFaultCountの2つの追加の組込みプロパティが定義されています。これらのプロパティは検索で使用できます。たとえば、平均フォルト・カウントが100よりも多いexecuteメッセージを検索できます。
JDBCサマリーが有効な場合、BTMはすべてのJDBC操作を個別に記録しますが、メッセージ・コンテンツをロギングしている場合、コール元ごとに1つの要約されたサマリー監視で情報が送信され、オブザーバ通信ポリシー設定で指定した最も遅いSQL文とフォルトの数のペイロード情報のみがここに含まれます。(サマリー・コンテンツのロギングを制御するオプション設定については、12.1.2.11項「詳細設定フィールドのリファレンス」を参照してください。)
サマリー監視のメッセージ・コンテンツを表示すると、xmlリスト(ExecuteSummaryContent)は次のように表示されます。このテキストでは出力のメイン・セクションが太字で示され、その説明が例の後に続いています。
<ExecuteSummaryContent> <ExecuteCount>52</ExecuteCount> <FaultCount>2</FaultCount> <SumResponseTime>77</SumResponseTime> <AvgResponseTime>1.54</AvgResponseTime> <SummaryStartTime>1376876999364</SummaryStartTime> <SummaryEndTime>1376877000390</SummaryEndTime> <Caller> <Service>LogService</Service> <Operation>haveFaults</Operation> </Caller> <CapturedFaults> <Fault> <ArriveTime>1376877000364</ArriveTime> <Content> <![CDATA[select * from noneexisttable]]> </Content> <FaultContent> <![CDATA[ORA-00942: table or view does not exit]]> </FaultContent> </Fault> <Fault> <ArriveTime>1376877000386</ArriveTime> <Content> <![CDATA[select * from noneexisttable]]> </Content> <FaultContent> <![CDATA[ORA-00942: table or view does not exist]]> </FaultContent> </Fault> </CapturedFaults> <TopNSlowestMessages> <TopNMessage> <Content> <![CDATA[INSERT INTO calculationlog (leftoperator,rightoperator,operatortype, result,logdate) VALUES(?,?,?,?,systimestamp)]]> </Content> <ResponseTime>4</ResponseTime> <ArriveTime>1376876999360</ArriveTime> <ExecuteCount>10</ExecuteCount> <AverageTime>2.30</AverageTime> <MinTime>2</MinTime> </TopNMessage> <TopNMessage> <Content> <![CDATA[DELETE FROM calculationlog where id=?]]> </Content> <ResponseTime>4</ResponseTime> <ArriveTime>1376877000150</ArriveTime> <ExecuteCount>10</ExecuteCount> <AverageTime>1.60</AverageTime> <MinTime>1</MinTime> </TopNMessage> <TopNMessage> <Content> <![CDATA[UPDATE calculationlog SET leftOperator = ?, rightOperator = ?, operatorType = ?, result = ?, logDate = systimestamp where id = ?]]> </Content> <ResponseTime>3</ResponseTime> <ArriveTime>1376876999552</ArriveTime> <ExecuteCount>10</ExecuteCount> <AverageTime>1.80</AverageTime> <MinTime>1</MinTime> </TopNMessage> </TopNSlowestMessages> </ExecuteSummaryContent>
ExecuteSummaryContentというタイトルのセクションには、サマリー監視に関する次の情報が示されています。
ExecuteCount: 実行されたJDBCコールの合計数(例外を含む)。
FaultCount: このサマリーで発生したすべてのJDBC例外の数。
SumResponseTime: すべてのSQL文のレスポンス時間の合計。
AvgResponseTime: 合計されたJDBCコールのレスポンス時間の平均。
SummaryStartTime: 次の「注意」を参照してください。
SummaryEndTime: 次の「注意」を参照してください。
サービス・コールおよび操作。
通信ポリシーでは、取得する例外の数も指定できます。このような例外またはフォルトごとに、次の情報がCapturedFaultsというタイトルのセクションに示されます。
ArriveTime: 例外が到着した時間。次の「注意」を参照してください。
Content: 例外が発生したSQL文。
FaultContent: SQL例外のコンテンツの全テキスト。
また、セクションTopNSlowestMessagesには、最も遅いN個のSQL文のそれぞれについて次の情報が示されます。(Nの値は通信ポリシーを使用して指定します。)
Content: SQL文の名前(ただし、これらに渡されるパラメータではない)。
ResponseTime: このSQL文の実行時間(マイクロ秒)。
ArriveTime: 開始時間。次の「注意」を参照してください。
ExecuteCount: このSQL文がコールされた回数。
AverageTime: 記録されたすべてのSQL文の平均時間。
MinTime: 記録されたすべてのSQL文の最小時間。
|
注意: ArriveTime、SummaryStartTimeおよびSummaryEndTimeの時間は、UNIXタイムスタンプを使用して指定されます(1/1/1970からの秒数に基づく)。この値を判別可能な日時に変換するには、インターネットで「UNIX時間変換」を検索して変換ツールを探してください。 |
すでにトランザクションを作成した後でJDBCサマリーの設定を変更する場合、さらに多くのトラフィックを実行してからトランザクション定義を更新する必要があります。これは、BTMがJDBCサマリーの設定に応じて、別の名前の下にあるSQL実行のJDBCサービス操作を検出するためです。
JDBCサマリーが無効の場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて個別に検出されます。
JDBCサマリーが有効な場合、executePrepStmt、executePrepStmtBatch、executeQueryおよびexecuteBatch文はすべて単一のexecute操作に結合されます。
トランザクション定義の作成後にJDBCサマリーの設定を変更する場合は、次の手順を実行します。
再度JDBCサービスでトラフィックを実行して、新しい操作を検出します。
古い操作を削除し、新しく検出された操作を含めることで、JDBCサービスを使用するトランザクションを編集します。
トランザクション定義を更新しない場合、BTMでは新しく検出されたJDBCサービスの操作をトランザクションの一部として認識できず、そのサービスへのトラフィックの測定値を記録できなくなります。
Business Transaction ManagementでSOAタイプのコンポーネントを直接検出できない場合があります。たとえば、監視できないコンテナの中にサービスが存在する場合や、オブザーバがインストールされていないコンテナの中にサービスが存在する場合などです。このような場合、サービスを手動で登録すると、オブジェクトを検索できることがあります。
このような方法でサービスを検出することは可能ですが、通常は、サービスが直接監視されていない状態でそのパフォーマンスを監視することはできません。詳細は、4.5項「手動によるサービスの登録」を参照してください。
検出によって、Business Transaction Managementシステム・サービスをホストしているコンテナ、および監視されているコンポーネントをホストしているコンテナに関する情報が表示されます。この項では、コンテナに関する使用可能な情報について説明します。また、コンテナのプロファイル情報を編集する方法とコンテナの登録を解除する方法についても説明します。
コンテナ情報は、「エクスプローラ」→「コンテナ」ビューから、または「マップ」→「コンテナ・マップ」ビューから表示できます。
コンテナ・マップを表示するには:
ナビゲータで、「マップ」→「コンテナ・マップ」を選択します。
フロートオーバー型のヘルプに、各コンテナのホスト名が示されます。カーソルをコンテナに合わせてヘルプを表示します。
タブ領域を開いてコンテナ・アイコンをクリックすると、コンテナの「プロファイル」および「サービス」タブが表示されます。タブの内容については、次の項を参照してください。
検出されたコンテナとその内容に関するサマリー情報を表示するには:
ナビゲータで、「エクスプローラ」→「コンテナ」ビューを選択します。検出されたコンテナに関する情報がメイン領域に表示されます。デフォルトでは、Business Transaction Managementは認識されたすべてのコンテナに関する情報を表示します。「フィルタ」コントロールを使用して、表示されるコンテナ情報をフィルタ処理します。
コンテナ名のそばにあるプラス・アイコンをクリックして、コンテナの内容を表示します。これで、選択したコンテナでホストされているアプリケーション・コンポーネントを表示できます。
コンポーネント名のそばにあるプラス・アイコンをクリックして、そのコンポーネントを構成している操作を表示します。操作は、ツリー・ビューのコンテナの下に表示されます。
検出されたコンテナに関する詳細情報を表示するには:
メイン領域でコンテナを選択します。
コンテナ名をダブルクリックします。詳細ペインに、「プロファイル」および「サービス」の2つのタブが表示されます。
「プロファイル」タブには、コンテナおよびデプロイされたオブザーバに関する情報が表示されます。次の表に、「プロファイル」タブのフィールドを示します。ユーザー定義フィールドは、プロファイル情報を編集することで入力できます。
「サービス」タブには、このコンテナで実行しているサービスの情報が表示されます。
| フィールド | 説明 |
|---|---|
| 注意 | ユーザー定義フィールド。コンテナの使用または内容の理解に役立つ情報を示します。 |
| ベース・アドレス | このコンテナのhttpベースのアドレス(エントリ・ポイント)。 |
| 別名 | コンテナがスフィアに認識される際のすべてのIPアドレス。ここには、コンテナへのメッセージ・トラフィックを監視することによってBusiness Transaction Managementで検出されたVPNアダプタ・アドレス、ユーザー定義の別名またはその他のアドレスが含まれる場合があります。この情報は、不適切なコンテナ設定を調査する場合に役立ちます。 |
| コンテナ・タイプ | コンテナ・タイプおよびバージョン番号。 |
| OS | オペレーティング・システムおよびバージョン。 |
| ホスト | サーバーが実行しているホスト名。 |
| 識別子 | Business Transaction Managementでのこのオブジェクトの一意の識別子。 |
| 管理UIコンソール | ユーザー定義フィールド: コンテナの管理コンソールのURL。このリンクを使用してコンソールを起動できます。このアドレスの値はBusiness Transaction Managementによって提供されますが、正確でない可能性があり、コンソールを移動する場合には必ず変更する必要があります。この値は、コンテナ・プロファイルを編集することで変更できます。 |
| モニターの詳細 | 指定されたコンテナにデプロイされたオブザーバの情報と、最終の検出、登録、スフィアとの同期およびバージョンの日付。 |
| 連絡先情報 | サーバー管理者またはその他のサポート担当者の連絡先情報を提供するユーザー定義フィールド。 |
| ルーティングの詳細 | コンテナにメッセージをルーティングしている、監視対象のロード・バランサの情報。 |
コンテナの登録を解除すると、コンテナおよびコンテナにデプロイされているすべての検出済サービスがスフィア・レジストリから削除されます。これは、次のいずれかのタスクが完了した後で必要になる場合があります。
別のスフィアへのコンテナの移動
コンテナからのBusiness Transaction Managementオブザーバのアンインストール
システムからのコンテナのアンインストールまたは物理的削除
次のいずれかのタスクを完了した後でのみコンテナの登録を解除する必要があります。そうしないと、何も変更されていない場合には、登録解除されたコンテナによって起動時にそれ自体が登録されます。
Business Transaction Managementによって、検出されたサービス、サービス・エンドポイント、エンドポイントにメッセージ・トラフィックを配布するルーター、およびサービス操作に関する情報が表示されます。
サービスとは、論理サービスを示します。
エンドポイントとは、サービス・インスタンスおよびルーターを示します。
操作は、1つのサービスが別のサービスに送信するリクエストおよびレスポンス・メッセージによって呼び出されます。
Business Transaction Managementを開始した時点では、サービスは表示されません。サービスが検出されるには、次のことが必要です。
オブザーバがインストールされ、適切なプローブがアクティブになっているアプリケーション・サーバーに、サービスがデプロイされている必要があります。
1つのサービスから別のサービスにトラフィックが流れている必要があります(手動でサービスを登録していない場合)。
サービスが検出されると、「サービスからエンドポイントへ」および「サービスから操作へ」ナビゲータ・ビューから、それらの情報にアクセスできます。サービスの依存性は、「マップ」→「サービス・マップ」ビューで表示できます。
Business Transaction Managementは、サービスで最初に検出されたエンドポイントのタイプに基づいて、サービスにタイプを割り当てます。サービス・タイプには、Webアプリケーション、Webサービスおよびデータベースがあります。(Webアプリケーションは、HTMLページ(画面)を介してユーザーとやり取りするコンポーネントです)。サービスにはそれぞれ異なるタイプの複数のエンドポイントがあり、それぞれ異なるオブザーバによって検出される場合があることに注意してください。たとえば、Webサービスでは、それぞれ異なるテクノロジ(JAX-RPC、JAX-WS、WCFなど)を使用して実装された別個のコンテナに、複数のエンドポイントが存在する場合があります。
表示されるサービス情報は、デプロイメントのトポロジによって異なります。実行しているサービスのインスタンスが1つしかない場合、そのサービスの1つのエンドポイントが表示されます。実行しているサービスのインスタンスが複数ある場合は、そのサービスの複数のエンドポイントが表示されます。
複数のサービス・インスタンスが検出される可能性があり、これらを監視する必要がありますが、その理由は様々です。
パフォーマンスまたはフェイルオーバーのためにサービスがレプリケートされている。この場合、レプリケートされたすべてのインスタンスがサービスのエンドポイントとして表示されます。これらのインスタンスにトラフィックを配布しているルーターも表示されます。ルーター名は、エンドポイント名に接尾辞としてRouterを付けた名前になります。
セキュアな(HTTPS)ポートとセキュアではない(HTTP)ポートの両方でサービスがコンテナにデプロイされている。トラフィックがポートに流れている場合にのみ、そのポートごとに1つのエンドポイントが表示されます。
1つのサービスに対する様々なバインディングがWSDLに含まれ、各バインディングによって、様々なエンドポイントで実装可能な様々な操作セットが定義されている。これはまれなケースですが、Business Transaction Managementではこの状態を認識し、エンドポイントを検出します。
ルーターがトラフィックのリダイレクトに使用されているかどうかを判断するのに時間がかかる場合があります。Business Transaction ManagementはHTTPトラフィックのホスト・ヘッダーを使用して、監視されているコンテナとは異なるアドレスにメッセージが最初に送信されたときに、そのことを検出し、依存性グラフの受信者にコール元を接続します。
ホスト・ヘッダーに含まれているホスト名は異なるが、ポートは同じである場合、Business Transaction Managementは最初にコンテナとそのエンドポイントの別名を追加します。実際にリスニングしているコンテナとは異なるポートがホスト・ヘッダーに含まれている場合、または2つ以上のコンテナに送信されたトラフィックで同じホスト・ヘッダーが監視されている場合、Business Transaction Managementはコール元とサービスの間にハードウェア・ロード・バランサが存在することを推察し、必要に応じてスフィア・モデルにルーター・エンドポイントを追加して、依存性グラフでコール元とそのターゲット・エンドポイントを接続します。
ナビゲータから、「サービスからエンドポイントへ」ビューまたは「サービスから操作へ」ビューのいずれかを使用して、サービスを表示できます。
「サービスからエンドポイントへ」を表示するには、ナビゲータからそのビューを選択します。Business Transaction Managementによって、コンソールのメイン領域に情報が表示されます。次の表に、このビューの内容を示します。
「サービスからエンドポイントへ」ビューは、エンドポイントのレプリケートが表示されるという点で役立ちます。レプリケートはアドレスで識別され、メイン領域に表示されます。また、このビューのタブ・セクションに示されるように、個別の定義情報およびパフォーマンス情報も表示されます。
| 列名 | 説明 |
|---|---|
| 名前 | サービスの名前。最上位の論理サービス名を展開して、そこに含まれるエンドポイントを表示します。エンドポイントを展開して、その操作を表示します。 |
| 上矢印/下矢印 | 緑色の矢印は、サービス、エンドポイントまたは操作が実行中であることを示します。赤色の矢印はダウンしていることを示します。黄色は、エンドポイントがサービスに含まれていることを示しますが、実行中のものもあればダウンしているものもあります。 |
| アドレス | サービスのコンテナのアドレス。レプリケートのエンドポイントはそれぞれ異なるアドレスを持ちます。 |
| タイプ | サービスのタイプ。これは、検出された最初のサービス・エンドポイントのタイプに基づきます。 |
| コンテナ・タイプ | サービス・コンテナのタイプおよびバージョン。 |
各サービス、エンドポイントまたは操作の詳細を表示するには、目的の要素をクリックしてタブ領域に詳細情報を表示します。これには、次のデータが含まれます。
| タブ | 説明 |
|---|---|
| サマリー | メイン・ペインで選択したオブジェクトのパフォーマンス測定のサマリーを表示します。 |
| 分析 | 特定の期間にわたるパフォーマンス情報を表示します。 |
| アラート | 選択したオブジェクトのアラートを表示します。 |
| メッセージ・ログ | 指定した操作に対してメッセージ・ロギングが有効になっている場合に、使用可能なメッセージを表示します。 |
| SLA準拠 | 選択したオブジェクトの準拠と、指定したオブジェクトに定義されているサービス・レベル合意を表示します。 |
| プロファイル | 選択したオブジェクトの定義を表示します。「変更」→「プロファイルの編集: object name」を選択することで、この情報の一部を編集できます。 |
| 依存性 | 選択したオブジェクトと関連オブジェクトとの間の依存性を表示します。 |
| ポリシー | 現在選択されているオブジェクトに適用されているポリシーを表示します。 |
| 停止時間 | 選択したオブジェクトにスケジュールされている停止時間を示します。 |
| プロパティ | 選択したオブジェクトに定義されているプロパティを示します。「編集」ボタンを使用して、これらのプロパティを変更、複製または削除します。 |
「サービスから操作へ」を表示するには、ナビゲータから選択します。Business Transaction Management。表示される情報のタイプは、「サービスからエンドポイントへ」ビューと同じです。タブの情報も同じです。
ビジネス・コンポーネントの検出に加えて、Business Transaction Managementでは、1つのコンポーネントから次のコンポーネントに流れるメッセージ・トラフィックを監視することで、コンポーネントが互いにどのように関係または依存しているかを検出できます。依存性情報によって、コンポジット・アプリケーションの実際の動作が正確に示されます。これにより、特定のコンポーネントがコールされていないという事実を警告されることがあり、また、ビジネス・トランザクションを定義するための基礎が提供されます。
サービス、エンドポイント、(サービス・インスタンス)または操作間の依存性を表示できます。各依存性マップによって、選択した要素に適切な情報が提供されます。
また、依存性グラフに最新でない依存性が表示されている場合には、依存性を削除することもできます。
表示されている依存性のタイプに関係なく、依存性ダイアグラムでは選択したオブジェクトをルートとして、その開始点から、およびその開始点につながるすべてのリンクが表示されます。ルート・オブジェクトの直接のアップストリームまたはダウンストリームに存在しない要素は表示されません。これらの追加要素を表示するには、レンチ・アイコンをクリックして「レイアウト」および「関連の表示」コントロールを表示します。
「関連の表示」のデフォルト値は「なし」で、これはルート・オブジェクトに直接リンクされている要素のみが表示されることを意味します。
「1」を選択して、ルート・オブジェクトに間接的にリンクされているその次のレベルのオブジェクトを表示するか、または「すべて」を選択して、ルート・オブジェクトにリンクされているすべてのオブジェクトを表示します。
「OK」をクリックします。
サービスの依存性を表示するには
ナビゲータで、「サービスからエンドポイントへ」ビューまたは「サービスから操作へ」ビューを選択します。
タブ領域がまだ開いていない場合には、目的のサービスをダブルクリックしてタブ領域を開きます。開いている場合は、単に目的のサービスを選択します。
「依存性」タブを選択します。Business Transaction Managementによって、選択したサービスとそのサービスがやり取りしている他のサービスとの間の依存性が表示されます。矢印はトラフィック・フローを示します。その厚みで相対的なスループット・サイズが示されます。
表示されているサービスにカーソルを合わせると、Business Transaction Managementでそのコンポーネント・タイプを表示できます。
ナビゲータで、「サービスからエンドポイントへ」ビューを選択します。
目的のサービスを展開して、対応するエンドポイントを表示します。サービスがレプリケートされた場合や、異なるエンドポイントがセキュアな通信またはセキュアではない通信に使用される場合、(論理)サービスに複数の対応するエンドポイントが存在する場合があります。
目的のエンドポイントをダブルクリックしてタブ領域を開きます。すでに開いている場合は、単に目的のエンドポイントを選択します。
「依存性」タブを選択します。Business Transaction Managementによって、選択したエンドポイントとそのエンドポイントがやり取りしている他のエンドポイントとの間の依存性が表示されます。矢印は、トラフィック・フローの方向と相対的なスループットを示します。エンドポイントごとに、そのエンドポイントが存在するコンテナのホスト名とポートも表示されます。エンドポイントの検出に使用された方法がカッコの中に表示されます。次の表に可能なタイプを示します。
| 検出の方法 | 意味 |
|---|---|
| オブザーバ | エンドポイントはオブザーバによって検出されました。 |
| ルーター | エンドポイントはルーターによって検出されました。(HTTPホスト・ヘッダーと、監視されたコンテナの物理アドレスの間の矛盾に基づいて、ハードウェア・ルーターの存在が推察されました。) |
| 登録済 | エンドポイントは手動で登録されました。 |
| DTA | 監視されているエンドポイントから送信されたアウトバウンド・トラフィックに基づいて、エンドポイントの存在が推察されました。 |
個々のエンドポイントにカーソルを合わせると、ビジネス・トランザクションによってエンドポイント名、コンテナのホストとポート、およびそのエンドポイントがどのサービスおよびコンポーネント・タイプのインスタンスであるかが表示されます。また、コア測定も表示されます。
ナビゲータで、「サービスから操作へ」ビューを選択します。論理的または物理的な操作間の依存性を表示できます。論理的な操作はサービスの直下に表示され、物理的な操作は論理的な操作の下に表示されます。物理的な操作の名前は次の形式になります。
endpointName on containerName
例: checkCredit.CreditServiceSOAP on uitest20:7011
目的の操作をダブルクリックしてタブ領域を開きます。すでに開いている場合は、目的の操作を選択します。
まだ選択されていない場合は、「依存性」タブをクリックします。
操作を含むコール・チェーンが表示されます。
カーソルを操作に合わせて、フロートオーバー型の追加ヘルプを表示します。
通常、サービスが直接監視下にない場合は、検出または監視することができません。ただし、サービスを手動で登録し、表示して、そのサービスに送信されるコールの測定を取得できます。
サービスへの送信コールはあるがサービスのコンテナにオブザーバをインストールできない場合は、サービスを登録する必要があります。サービスを登録すると、メッセージ交換のクライアント側で監視される測定およびログ・メッセージをシステムで記録できるようになります。
サービスを登録した後、registerExternalContainerコマンドを使用すると、そのエンドポイントを外部コンテナにグループ化できます。それ以外の場合、手動で登録したエンドポイントはデフォルトでシステム・コンテナに割り当てられ、「未割当てのエンドポイント」ノードに表示されます。
サービスを登録するには:
メイン・メニューから、「管理」→「登録」→「サービスWSDL」を選択します。
サービスのWSDLのURLを指定し、「次」をクリックします。
サービスをスフィアに登録する際の名前を指定します。デフォルトでは、名前はWSDL定義から抽出されますが、必要に応じて代替名を使用できます。
オプションで、サービスのバージョンを指定します。
「OK」をクリックします。
これで、「サービスからエンドポイントへ」または「サービスから操作へ」ビューのサマリー領域に、サービスが表示されるようになります。
有用な検出構成を作成しようとすると、特にBusiness Transaction Managementを使用する早い段階では何度か繰り返し作業することになる場合があります。プローブを有効にするためのデフォルト設定にあまりにも多くの情報が含まれる場合や、デプロイメントまたはオブザーバ・モニター・トポロジの変更によって情報が冗長になったり誤ったものになる場合があります。システムを再インストールしたり、すべての監視対象エンティティおよび関連するアーティファクトを手動で削除する必要がないようにするために、Business Transaction ManagementにはdeleteAllコマンドが用意されています。このコマンドは、すでに検出されたオブジェクトをトランザクション、プロパティ、登録済サービス、デバイス、コンテナなど関連するアーティファクトとともに削除します。
監視したオブジェクトに関する履歴データなどのデータの不要な損失を防ぐために、このコマンドは慎重に使用してください。このコマンドが最も適しているのは、Business Transaction Managementでの作業を開始し、検出方式を微調整するときです。本番環境では使用しないでください。
詳細は、10.11項「deleteAll」を参照してください。
