JP5909140B2 - Ｊｖｍおよびクロスｊｖｍ呼び出しスタックの可視化 - Google Patents

Description

本発明は、コンピューティング環境におけるソフトウェアを監視する技術に関する。

背景

インターネットの存在が増長するにつれて、イントラネット、エクストラネットなどの他のコンピュータネットワークと同様に、電子商取引、教育、他の分野において多くの新しいアプリケーションをもたらした。組織は、ビジネスやその他目的を行うのにそのようなアプリケーションへの依存を深めており、期待通りの成果を確実に得るために相当の資源を投入している。このような状況のもと、様々なアプリケーションの管理技術が開発されている。

１つのアプローチとして、アプリケーションで呼び出される個々のソフトウェアコンポーネントに関するアプリケーションの実行データを集めることにより、アプリケーションの基礎構造を監視することが挙げられる。このアプローチでは、監視されるシステムに元来、存在するエージェントを用いることができる。例えば、ソフトウェアによる計測を用いることによって、呼び出される個々のコンポーネントを特定するためや、個々のコンポーネントの実行時間のような実行データを得るために、スレッドまたはプロセスがトレースされ得る。コンピュータプログラムが実行するステップの詳細なレコード、またはトレースを得ることをトレーシングという。トレースのタイプの１つにスタックトレースがある。トレースはデバッグにおける補助の役目を果たし得る。

しかし、問題の診断は依然として難しく時間がかかっている。例えば、トランザクションまたはアプリケーションに障害が生じている場合、プロバイダは起きつつある故障とその原因を正確に知りたい。改善された診断技術が必要とされている。

本発明はコンピューティングシステムのアプリケーションまたは他のサブシステムを介してフローを可視化することによってコンピュータシステムにおけるパフォーマンス問題を診断する方法を提供する。

一実施形態において、少なくとも第１のアプリケーションのフローを可視化するための方法を実行するように少なくとも１つのプロセッサをプログラミングするための、コンピュータで読み取り可能なソフトウェアを有している有体の一時的でないコンピュータで読み取り可能な記憶装置が具現化されて提供される。実行される方法は、第１のアプリケーションに関するデータにアクセスするためにデータストアにアクセスすることを有する。ここで、データは、第１のアプリケーションの複数のインスタンスを表すものであり、第１のアプリケーションにインストールされた計測を用いて第１のアプリケーションに関連付けられたエージェントから取得される。実行される方法は、ユーザインタフェース上に依存グラフを表示することをさらに含む。依存グラフは、（ａ）第１のアプリケーションの複数のインスタンスを表す第１のノード、（ｂ）第１のアプリケーションが依存する１つのサブシステムを表す第２のノード、および、（ｃ）第１のアプリケーションの１つのサブシステムへの依存を表す少なくとも１つの辺、を図形によって表す。

別の実施形態では、それぞれのアプリケーションのフローを可視化するための方法を実行するように少なくとも１つのプロセッサをプログラミングするために、コンピュータで読み取り可能なソフトウェアを有している有体の一時的でないコンピュータで読み取り可能な記憶装置が具現化されて提供される。実行される方法は、それぞれのアプリケーションに関連付けられたそれぞれのエージェントから取得されるデータにアクセスするためにデータストアにアクセスすることを含む。ここで、データは、それぞれのアプリケーションの複数のインスタンスを表すものであり、それぞれのエージェントは、それぞれのアプリケーションにインストールされた計測を用いてデータを提供する。実行される方法は、ユーザインタフェース上に依存グラフを表示することをさらに含む。依存グラフは、（ａ）１つのアプリケーションの複数のインスタンスを表す第１のノード、（ｂ）別のアプリケーションの複数のインスタンスを表す第２のノード、および（ｃ）別のアプリケーションに対する１つのアプリケーションの依存を表す少なくとも１つの辺、を図形によって表す。

別の実施形態では、それぞれのアプリケーションのフローを可視化するための方法を実行するように少なくとも１つのプロセッサをプログラミングするために、コンピュータで読み取り可能なソフトウェアを有している有体の一時的でないコンピュータで読み取り可能な記憶装置が具現化されて提供される。実行される方法は、それぞれのアプリケーションに関連付けられたそれぞれのエージェントから取得されるデータにアクセスするためにデータストアにアクセスすることを含む。ここで、データは、複数のアプリケーションのそれぞれにおける複数のインスタンスを表し、それぞれのエージェントは、それぞれのアプリケーションにインストールされた計測を用いてデータを提供する。実行される方法は、ユーザインタフェース上に依存グラフを表示することをさらに含む。依存グラフは、（ａ）第１のアプリケーションが呼び出される第１の業務トランザクションを表す第１の識別子、（ｂ）第１のアプリケーションの複数のインスタンスを表すノード、（ｃ）第１の業務トランザクションに関連して第１のアプリケーションが依存する１つのサブシステムを表すノード、および（ｄ）第１の業務トランザクションに関連して第１のアプリケーションの１つのサブシステムへの依存を表す少なくとも１つの辺、を図示的に示す。

方法に対応して、実行時に、本明細書で提供される方法を実行する命令がエンコードされた記憶媒体を含むシステムおよびコンピュータもしくはプロセッサで読み取り可能な記憶装置が提供される。

管理されたアプリケーションを含むシステムを示す。 トランザクショントレースを開始するためのプロセス［処理］の一実施形態を説明するフローチャートである。 トランザクショントレースを終了するためのプロセス［処理］の一実施形態を説明するフローチャートである。 図１のネットワークのコンピューティングデバイスを示す。 図１のアプリケーションサーバ１０６を含むトランザクショントレースの第１の例を示す。 図１のアプリケーションサーバ１０６を含むトランザクショントレースの第２の例を示す。 図１のアプリケーションサーバ１１０を含むトランザクショントレースの第１の例を示す。 図４Ａから図４Ｃのトランザクショントレースに基づくアプリケーションの配置図を示す。 図４Ａから図４Ｃのトランザクショントレースに基づく依存性のダイグラフにおけるパスを示す。 図４Ａのトランザクショントレースに基づく単一のＪＶＭトランザクションの呼び出しスタックを示す。 図４Ｆの呼び出しスタックのための依存性のダイグラフの枝刈り前を示す。 図４Ｆの呼び出しスタックのための依存性のダイグラフの枝刈り後を示す。 図４Ｂおよび図４Ｃのトランザクショントレースに基づくクロスＪＶＭトランザクションの呼び出しスタックを示す。 図４Ｉの呼び出しスタックのための依存性のダイグラフの枝刈り前を示す。 図４Ｉの呼び出しスタックのための依存性のダイグラフの枝刈り後を示す。 図４Ｈおよび図４Ｋの枝刈りされた依存性のダイグラフに基づく、アプリケーションＡの細部を記した依存性のグラフを示す。 図４Ｈおよび図４Ｋの枝刈りされた依存性のダイグラフに基づく、アプリケーションＡおよびアプリケーションＢの細部を記した依存性のグラフを示す。 図４Ｈおよび図４Ｋの枝刈りされた依存性のダイグラフに基づく、業務サービスの概要表示を提供するユーザインタフェースを示す。 業務トランザクションＢＴＡ１が選択された後の図６Ａのユーザインタフェースを示す。 業務トランザクションＢＴＡ２が選択された後の図６Ａのユーザインタフェースを示す。 業務トランザクションＢＴＢ１が選択された後の図６Ａのユーザインタフェースを示す。 アプリケーションＡがフロントエンドの表示において選択される場合の、図４Ｈおよび図４Ｋの枝刈りされた依存ダイグラフに基づく概要表示を提供するユーザインタフェースを示す。 図７Ａ１のユーザインタフェースに適用される経時変化処理を示す。 図７Ａ１のユーザインタフェースに適用される経時変化処理の別の例を示す。 図７Ａ１のユーザインタフェースに適用される経時変化処理のさらなる例を示す。 詳細表示における図７Ａのユーザインタフェースを示す。 アプリケーションＢがフロントエンドの表示において選択される場合の、図４Ｋの枝刈りされた依存性のダイグラフに基づく概要表示を提供するユーザインタフェースを示す。 詳細表示における図７Ｃのユーザインタフェースを示す。 図７Ａまたは図７Ｂのユーザインタフェースに基づくアプリケーションＡのための正常性メトリックを提供するユーザインタフェースを示す。 １以上のアプリケーションの操作を示す際に用いられる階層を示す。 取引の業務サービスがユーザによって選択された場合の、図８Ａの階層と一致するユーザインタフェースのさらなる例を示す。 発注の業務トランザクションがユーザによって選択された場合の、図８Ｂのユーザインタフェースを示す。 オプション取引の業務トランザクションがユーザによって選択された場合の、図８Ｂのユーザインタフェースを示す。 ユーザインタフェースを提供する方法を示す。

本発明は、コンピュータシステムの、アプリケーションまたは他のサブシステムのフローを可視化することによってコンピュータシステムにおける問題を診断するための方法を提供する。

ツールは、アプリケーションのそれぞれのエージェントを用いてアプリケーションのメトリックを収集することにより、アプリケーションのパフォーマンスを監視するために提供される。収集されるメトリックのデータは、監視されるすべてのアプリケーション（同じアプリケーションの複数のインスタンスを含む）のエージェントを中心とした表示を提供する。さらに、このツールは、アプリケーションまたは業務プロセスとその論理的基盤のコンポーネントと間の依存関係を示す、グラフィカルな依存性のグラフもしくはアプリケーショングラフを提供することによって、業務中心の関係で関与することを業務ユーザにとってより簡単にさせる。

図１は、複数の異なるコンピューティングデバイスがマネージャにデータを提供するネットワーク１００を示す。コンピューティングデバイス１０６、１１０および１１４の例は、アプリケーションサーバまたは必要な機能を実現するためのコードを実行するプロセッサを有するコンピューティングデバイスの他の種類を含む。コンピューティングデバイスは、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、コンピューティングデバイス１０６、１１０および１１４は、ローカルのマネージャコンピュータ１２０と通信する。マネージャコンピュータ１２０は、代わりにコンピューティングデバイス１０６、１１０および１１４から離れることが可能で、そのような場合の通信はネットワーククラウド１０４を介して行われる。

例えば、ウェブベースの電子商取引アプリケーションなどの企業のアプリケーションを実行している会社は、負荷分散のために１つの場所で複数のアプリケーションサーバを使用する。例えば、ユーザのウェブブラウザ１０２からのようなユーザからのリクエストは、インターネットのようなネットワーククラウド１０４を介して受信され、任意のコンピューティングデバイス１０６、１１０および１１４に送られる。ウェブブラウザ１０２は、図示していないインターネットサービスプロバイダを介してネットワーククラウド１０４に、通常、アクセスする。コンピューティングデバイス１０６、１１０および１１４上で実行するエージェントソフトウェアは、エージェントＡ１（１０８）、エージェントＡ２（１１２）およびエージェントＡ３（１１６）によってそれぞれ表され、ある可能なアプローチとして、それぞれのコンピューティングデバイス１０６、１１０および１１４上で実行されている、アプリケーション、ミドルウェアまたはその他のソフトウェアから、情報を収集する。そのような情報は、計測を用いることによって得ることができ、その一例はバイトコードの計測である。しかしながら、集められたデータは他の方法でも得ることができる。エージェントは、監視するコンピューティングデバイスに元来存在してデータの取得ポイントを提供する。エージェントは、マネージャ１２０と通信してデータをまとめ最適化する。一実装では、アプリケーションＡのインスタンスがコンピューティングデバイス１０６において、アプリケーションＢのインスタンスがコンピューティングデバイス１１０において実行する。

マネージャ１２０は、エージェントから受信したデータに基づく情報を表示するため、例えばモニタなどのユーザインタフェース１２２と通信するワークステーションのような分離したコンピューティングデバイス上に提供され得る。マネージャは、またエージェントから受信したデータを格納するためデータベース１１８にアクセスする。提示された例では、コンピューティングデバイスは、ネットワーククラウド１０４にアクセスすることなく、マネージャ１２０と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ１２０は、ネットワーククラウド１０４を介して複数のコンピューティングデバイスのエージェントからデータを受信する。例えば、大きな組織は、セントラルネットワークオペレーションセンタを運用する。そこでは、１以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、ウェブベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払いを処理するサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ１２０およびユーザインタフェースディスプレィ１２２は、企業の本社の場所で提供され得る。必ずしも、ウェブベースまたは小売、もしくはその他の販売に関する必要はなく、他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用する。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数コンピュータのデバイスアレンジに加えて、１以上のエージェントによって単一のコンピュータデバイスが同様に監視されることがある。

監視を実行するソフトウェアを計測するのに、様々なアプローチが知られている。例えば、最初に述べたように、トレーシングはソフトウェアの実行を追跡するために用いることができる。トレーシングの例が、”Transaction Tracer”と題する米国特許出願公開番号２００４／００７８６９１（２００４年４月２２日公開）に記載されている。その内容は参照により本明細書に組み込まれる。その中で述べられているアプローチにおいては、監視すべきアプリケーションのオブジェクトコードまたはバイトコードが計測され、例えばプローブにより変更される。アプリケーションのジョブまたは他のロジックを変更することなくアプリケーションについての特定の情報をプローブが測定する。一旦、プローブがアプリケーションのバイトコードにインストールされると、管理されたアプリケーションと称される。エージェントソフトウェアは、プローブからの情報を受信し、その情報を、例えばマネージャ１２０において、別のプロセスに伝達することがある。また、情報が異常状況を示すか否かを判定するなど、情報をローカルで処理する。エージェントは、このようにプローブから受信した情報を収集し要約する。指示ファイルによって定義されるように、プローブは、情報を収集する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始や停止の回数、またはトランザクション／実行フロー内の個々のコンポーネントの開始や停止の回数を示す場合がある。この情報は、それが範囲内にあるかどうかを判定するために予め決められた基準と比較される。もし情報が範囲内にない場合には、エージェントは適切なトラブルシューティングが実行できるようにこの事実をマネージャに報告する。エージェント１０８、１１２および１１６は、それぞれが関連付けられているローカルコンピューティングデバイス１０６、１１０および１１４上でソフトウェアが実行中であることを通常認識している。

プローブは、ＣＯＲＢＡメソッドタイマ、リモートメソッドインボケーション（ＲＭＩ）メソッドタイマ、スレッドカウンタ、ネットワークバンド幅、ＪＤＢＣ更新およびクエリタイマ、サーブレットタイマ、Java（登録商標）サーバページズ（ＪＳＰ）タイマ、システムログ、ファイルシステム入出力バンド幅メータ、使用可能および使用済メモリ、ならびにＥＢＪ（エンタープライズJava（登録商標）ビーンズ）タイマを含むメトリックの標準セットを報告する。メトリックは、特定のアプリケーションのアクティビティの計測値である。

エージェントは、アプリケーションによってアクセスされるリソースを識別するトランザクションに関する情報を報告する。１つのアプローチでは、トランザクションについて報告する場合における「呼び出された」という語はリソースを指す。このリソースは、消費者が親のコンポーネントであるところのリソース（またはサブリソース）である。例えば、トランザクションで呼び出される最初のコンポーネントがサーブレットＡであると仮定する。消費者のサーブレットＡ（下記参照）の下には、ＥＪＢと称されるサブリソースがある。消費者とリソースは、ツリーのような形でエージェントよって報告される。トランザクションのデータは、またツリーに従って格納される。例えば、もしサーブレット（例えばサーブレットＡ）が、ネットワークのソケット（例えば、ソケットＣ）の消費者であり、かつＥＪＢ（例えば、ＥＪＢ Ｂ）の消費者でもあるとすれば、次にはＪＤＢＣ（例えば、ＪＤＢＣ Ｄ）の消費者であり、ツリーは以下のように見える。

Servlet A（サーブレットＡ）

Data for Servlet A（サーブレットＡのデータ）

Called EJB B（呼び出されたＥＪＢ Ｂ）

Data for EJB B（ＥＪＢ Ｂのデータ）

Called JDBC D（呼び出されたＪＤＢＣ Ｄ）

Data for JDBC D（ＪＤＢＣ Ｄのデータ）

Called Socket C（呼び出されたソケットＣ）

Data for Socket C（ソケットＣのデータ）

一実施形態では、上記ツリーは、ブレイムスタックと称されるスタックにエージェントによって格納される。トランザクションが開始すると、トランザクションはスタックへプッシュされる。トランザクションが完了すると、トランザクションはスタックからポップされる。一実施形態では、スタック上の各トランザクションは、次に続く情報、トランザクションの型、トランザクションのためにシステムで使用される名称、パラメータのハッシュマップまたは辞書、トランザクションがスタックへプッシュされたときのタイムスタンプおよびサブエレメント、が格納されている。サブエレメントは、注目すべきトランザクション内から開始されている他のコンポーネント（例えば、メソッド、プロセス、プロシージャ、関数、スレッド、命令セットなど）のためのブレイムスタックのエントリである。上記の例のようにツリーを使用すると、サーブレットＡのためのブレイムスタックのエントリは２つのサブエレメントを有する。第１サブエレメントは、ＥＪＢ Ｂへのエントリで、第２サブエレメントは、ソケットスペースＣへのエントリである。サブエレメントは特定のトランザクションのためのエントリの一部であるにもかかわらず、サブエレメントはまた独自のブレイムスタックのエントリを有する。上記のツリーに示されるように、ＥＪＢ ＢはサーブレットＡのサブエレメントであり、また独自のエントリを有する。トランザクションに対する一番上（最初）のエントリ（例えばサーブレットＡ）は、ルートコンポーネントと称される。スタック上の各エントリはオブジェクトである。

図２Ａは、トランザクショントレースを開始するための処理の一実施形態を説明するフローチャートである。ステップは適切な（複数の）エージェントにより実行される。ステップ１３０ではトランザクションを開始する。一実施形態では、プロセス［処理］は、メソッド（例えば、"loadTracer"メソッドの呼び出し）の開始によってトリガ（起動）される。ステップ１３２において、エージェントは所望のパラメータ情報を取得する。一実施形態では、ユーザは、構成ファイルまたはＵＩを介して、どのパラメータ情報を取得するかを設定することができる。取得されたパラメータは、ブレイムスタックへプッシュされるオブジェクトの一部であり、ハッシュマップまたは辞書に格納される。他の実施形態では、パラメータの識別は、予め設定されている。格納されるパラメータには様々なものがある。一実施形態では、使用されるパラメータの実際の一覧表は、監視されるアプリケーションに依存している。以下の表は、取得され得るいくつかのパラメータの例を示す。

パラメータは、クエリ、クッキー、ＰＯＳＴ、ＵＲＬおよびセッションの型の名称／値の組を含む。

ステップ１３４では、システムは現在の時刻を示すタイムスタンプを取得する。ステップ１３６ではスタックエントリが作成される。ステップ１３８において、スタックエントリはブレイムスタックへプッシュされる。一実施形態では、タイムスタンプがステップ１３８の一部として付加される。トランザクションが開始されるときにプロセス［処理］が実行される。同様のプロセス［処理］が、トランザクションのサブコンポーネントが開始するときに実行される（例えば、ＥＪＢ ＢはサーブレットＡのサブコンポーネントである−上述したツリーを参照のこと）。

図２Ｂは、トランザクショントレースを終了するためのプロセス［処理］の一実施形態を説明するフローチャートである。トランザクションが終了するときにエージェントによりプロセス［処理］が実行される。ステップ１４０において、プロセス［処理］がトランザクション（例えばメソッド）の終了（例えば、"finishTrace"メソッドの呼び出し）によってトリガされる。ステップ１４２では、システムは現在の時刻を取得する。ステップ１４４では、スタックエントリが削除される。ステップ１４６において、トランザクションの実行時間は、ステップ１４２からのタイムスタンプをスタックエントリに格納されているタイムスタンプと比較することによって算出される。ステップ１４８では、トレースのためのフィルタが適用される。例えば、フィルタには１秒の閾値期間が入る。したがって、ステップ１４８は、ステップ１４６から算出された時間幅が１秒よりも大きいか否かを決定することを含む。閾値を超えない場合（ステップ１５０）、トランザクションのデータは破棄される。一実施形態では、スタックエントリの全体が破棄される。別の実施形態では、パラメータとタイムスタンプだけが破棄される。他の実施形態では、データの様々なサブセットが破棄される。いくつかの実施形態では、閾値の時間幅を超えていない場合には、エージェントにより、データは図１のシステム内の他のコンポーネントに送信されない。時間幅が閾値を超える場合（ステップ１５０）、ステップ１６０においてエージェントがコンポーネントデータを組み立てる。コンポーネントデータは、報告されるトランザクションに関するデータである。一実施形態では、コンポーネントデータは、トランザクションの名称、トランザクションの型、トランザクションの開始時刻、トランザクションの時間幅、パラメータのハッシュマップまたは辞書、およびサブエレメント（エレメントの帰納的なリスト）のすべてを含む。その他の情報もまたコンポーネントデータの一部である。ステップ１６２において、エージェントは、マネージャ１２０にＴＣＰ／ＩＰプロトコルによりコンポーネントデータを送信することによってコンポーネントデータを報告する。

図２Ｂは、トランザクションが終了すると何が起こるかを表している。しかしながら、サブコンポーネントが終了すると、実行されるステップは、タイムスタンプを取得すること、サブコンポーネントのためのスタックエントリを削除することおよび完了したサブエレメントを以前のスタックエントリに加えることを含む。一実施形態では、フィルタおよび判断ロジックは、特定のサブコンポーネントというよりも、トランザクションの開始および終了に適用される。

一実施形態では、トランザクショントレーサがオフになっている場合、システムは依然としてブレイムスタックを使用するが、しかし、パラメータは格納されことなく、コンポーネントデータは作成されないことに注意されたい。いくつかの実施形態では、トレーシング技術をオフにすることによってシステムはトレーシングを開始しない。トレーシングは上述したように、ユーザが要求した後にだけ開始する。

図３は、図１のネットワークのコンピューティングデバイスを示す。コンピューティングデバイス３００は、例えば図１に関連して説明したように、ウェブブラウザ、アプリケーションサーバ、マネージャおよび／またはユーザインタフェースで使用されるシステムを簡略化して表したものである。コンピューティングデバイス３００は、ハードディスクまたはポータブルメディアのような記憶装置３１０、他のコンピューティングデバイスと通信するためのネットワークインタフェース３２０、ソフトウェアの命令を実行するためのプロセッサ３３０、例えば、記憶装置３１０からロードされた後にソフトウェアの命令を格納するためのＲＡＭのような作業メモリ３４０、および１以上のビデオモニタのようなユーザインタフェースディスプレィ３５０を含むものである。ユーザインタフェースは１以上のモニタを提供する。記憶装置３１０は、本明細書で説明した機能を提供するための方法を実行するのにプロセッサ３３０をプログラミングするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサまたはコンピュータで読み取り可能な有体であり一時的でない記憶装置と考えることができる。ユーザインタフェースディスプレィ３５０は、１以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供する。ユーザインタフェースディスプレィ３５０は、グラフィカルまたは表形式のような既知の任意の表示方式を使用する。画面上の表示に加えて、プリンタからのハードコピーなどの出力も提供する。

記憶装置３１０がアプリケーションサーバ、マネージャおよび／またはユーザインタフェースのようなコンピューティングデバイス３００の一部である場合、データベース１１８は記憶装置３１０に含まれる。記憶装置３１０は、１以上のエージェントから受信したデータを格納し、本明細書で説明したようにユーザインタフェースを提供するためにデータを取得するためにアクセスされる、１以上の記憶装置を表し得る。記憶装置３１０は、データストアを表す。

また、本明細書で説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、１以上のプロセッサをプログラミングするために具現化されているプロセッサで読み取り可能なコードを有する、プロセッサで読み取り可能な１以上の一時的でない有体の記憶装置が使用される。プロセッサ読み取り可能な一時的でない有体の記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータで読み取り可能な媒体を含む。例えば、コンピュータにより読み取り可能な一時的でない有体の媒体には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータなどの情報を記憶するために、任意の方法や技術で実装された、揮発性、不揮発性、リムーバブルや非リムーバブルメディアが含まれ得る。コンピュータにより読み取り可能な一時的でない有体の媒体の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタルバーサタイルディスク（ＤＶＤ）、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムＩＣ、ゲートアレイ、ＦＰＧＡ、ＰＬＤや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、１以上の実施形態を実装するソフトウェア（記憶装置に格納されている）は、１以上のプロセッサをプログラムするために用いられる。１以上のプロセッサは、コンピュータにより読み取り可能な有体の媒体／記憶装置、周辺機器および／または通信インタフェースと通信することができる。

図４Ａは、図１のアプリケーションサーバ１０６を含むトランザクショントレースの第１の例を示す。スレッドまたはプロセスのトランザクショントレースは、呼び出される各コンポーネントおよびコンポーネント間の呼び出し関係を識別するために取得される。この例では、トランザクショントレースは、業務トランザクションＢＴＡ１（図４Ｅを参照されたい）の一部であると考えられる。１つのアプローチでは、トランザクショントレースは、呼び出されている第１のアプリケーションのサーブレットＡ１のような少なくとも第１の予め選択されたコンポーネントに基づいて第１の業務トランザクション（ＢＴＡ１）によって呼び出されると考えられるアプリケーションである。

トランザクショントレースにおいて、水平方向は時間を表し、垂直方向は呼び出しスタックの深さや位置を表す。また、呼び出しスタックと称されるトランザクショントレースは、１以上のプログラム、プロセスまたはスレッドの実行中に、呼び出されるかまたは起動される計測されたコンポーネントを特定する。計測されたコンポーネントのトレースデータは、アプリケーションを理解したりデバッグしたりするために依存データとともに使用される。特に、異なるスレッドが異なるトランザクショントレースに分離されるよう、分離したトランザクショントレースが各エージェントに提供される。

ユーザインタフェース上に提供される、および／または、データストア内に格納されるグラフィカルな表現において、外部頂点３６０は、トランザクショントレースの第１のコンポーネントまたはルートコンポーネントである。サーブレットＡ１ ３６２、プレーンオールドJava（登録商標）オブジェクト（ＰＯＪＯ）Ａ１ ３６４、Java（登録商標）データベースコネクティビティ（ＪＤＢＣ）ドライバ呼び出し３６６およびソケット呼び出し３６８は、トランザクショントレースの連続した下位の層にある。ＰＯＪＯは、エンタープライズJava（登録商標）ビーンズ（ＥＪＢ）などの特殊なオブジェクトではないJava（登録商標）オブジェクトである。外部頂点３６０は、アプリケーションＡの外部からアプリケーションＡ内にサーブレットＡ１を呼び出す任意のコンポーネントである。

図４Ｂは、図１のアプリケーションサーバ１０６を含むトランザクショントレースの第２の例を示す。外部頂点３７０（外部頂点３６０とは異なる）は、トランザクショントレースのルートコンポーネントである。サーブレットＡ２ ３７２、ウェブサービスクライアント３７４およびソケット呼び出し３７６は、トランザクショントレースの連続した下位の層にある。外部頂点３７０は、アプリケーションＡの外部からアプリケーションＡ内にサーブレットＡ２を呼び出す任意のコンポーネントである。

図４Ｃは、図１のアプリケーションサーバ１１０を含むトランザクショントレースの第１の例を示す。外部頂点３８０（外部頂点３６０および３７０とは異なる）は、トランザクショントレースのルートコンポーネントである。サーブレットＢ１ ３８２、ＪＤＢＣドライバ呼び出し３８４およびソケット呼び出し３８６は、トランザクショントレースの連続した下位の層にある。外部頂点３８０は、アプリケーションＢの外部からアプリケーションＢ内にサーブレットＢ１を呼び出す任意のコンポーネントである。

図４Ａから図４Ｃのトランザクショントレースは、図４Ｄから図７Ｅの詳解に基づいて提供される。

図４Ｄは、図４Ａから図４Ｃのトランザクショントレースに基づくアプリケーションの配置図を示す。この例では、アプリケーションＡはアプリケーションサーバ１０６に展開され、アプリケーションＢはアプリケーションサーバ１１０に展開される。アプリケーションＡのJava（登録商標）仮想マシン（ＪＶＭ）４００は、サーブレットＡ１ ４０２、サーブレットＡ２ ４０４およびＰＯＪＯＡ１ ４０６を実行し、エージェントＡ ４０８は実行を監視する。アプリケーションサーバ１１０において、アプリケーションＢのJava（登録商標）仮想マシン（ＪＶＭ）４２０は、ウェブサービスとして見えるようにされているサーブレットＢ１ ４１２を実行し、その間エージェントＢ ４１４がその実行を監視する。

依存性のグラフは、この例に基づいて提供される（図５Ａから図７Ｄを参照されたい）。依存グラフは、アプリケーションまたは業務トランザクションの、様々なソフトウェアコンポーネント間の依存関係（マップ）を有向グラフ（ダイグラフ）として表示する。ソフトウェアコンポーネントは、サーブレット、ＥＪＢ、データベース、メッセージキュー（ＭＱ）等々である。

具体的には、グラフＧ＝（Ｖ，Ｅ）は、頂点の集合Ｖ（ノードとも呼ばれる）および辺の集合Ｅを含む。各辺は、頂点の順序付けられた組を表す。有向グラフ内の辺は、順序付けられたペアである。即ち、辺が接続する２つの頂点は順序付けられている。有向グラフの辺は、１つの頂点（ソース）から別の頂点（ターゲット）までを指し示す矢印として描かれる。したがって、矢印の頭部はターゲットの頂点にあり、矢印の尾部はソースの頂点にある。さらに、ｖ１からｖｋへの単純なパスは、辺（ｖ１，ｖ２）、（ｖ２，ｖ３）...（ｖｋ−１，ｖｋ）によって接続される頂点ｖ１、ｖ２...ｖｋのシーケンスである。アプリケーションが有向グラフで表されている場合、業務トランザクションはそのグラフを介した単純なパスと考えられる。グラフＧのサブグラフＳは、その頂点と辺がグラフＧの頂点と辺のサブセットであるグラフである。サブグラフＳ１は、それがグラフＧの辺のサブセットで構成されている場合、［グラフ］Ｇのサブグラフを誘導する呼び出された辺である。業務サービスは、そのグラフの辺が誘導するサブグラフと考えられる。依存グラフの論理的表示は、エージェント全体に亘る様々なコンポーネント間のすべて物理的な依存の結合である。潜在的に、アプリケーションの依存グラフは、複数の業務トランザクションを示す。

図４Ｅは、図４Ａから図４Ｃのトランザクショントレースに基づく依存ダイグラフにおけるパスを示す。アプリケーションＡにおいて、サーブレットＡ１ ４０２はＰＯＪＯＡ１ ４０６を呼び出し、ＰＯＪＯＡ１ ４０６は次にデータベースＸ ４０１を呼び出す。サーブレットＡ２ ４０４は、サーブレットＢ１がデータベースＹ ４３１を呼び出すのに応答して、ネットワーククラウド１０４を介してアプリケーションＢのサーブレットＢ１ ４１２へのウェブサービス呼び出し４０３を行う。業務トランザクションＢＴＡ１は、サーブレットＡ１からＰＯＪＯＡ１へ、そしてデータベースＸへの実行フロー（一連の呼び出されたコンポーネント／サブシステム）として定義され、業務トランザクションＢＴＡ２はサーブレットＡ２からウェブサービスへそしてサーブレットＢ１へのフローとして定義される。また、トランザクションＢＴＡ２は、アプリケーションＢに関する業務トランザクションＢＴＢ１を生成する。ＢＴＢ１は、サーブレットＢ１からデータベースＹへのフローとして定義される。

一般的に、エージェントは、アプリケーション／ウェブサーバを通過するあらゆるトランザクションのコンポーネントを追跡することができる。トランザクションに関与するソフトウェアコンポーネント（例えばクラスメソッドの組のような）は、それらが呼び出される順序で呼び出しスタックの内部でプッシュされる。制御フローがコンポーネントに戻る場合、コンポーネントは呼び出しスタックからポップされる。しかしながら、トランザクションの呼び出しスタックは、ユーザよって関心のあるまたは関心のない複数のコンポーネントを含む。不必要に複雑な依存グラフを防ぐため、エージェントは、単に関心のあるノード間の依存を収集するだけである。呼び出しスタックにおいて最初に関心を引くエレメントであるコンポーネント、またはそれ自身のＪＶＭ（Java（登録商標）仮想マシン）呼び出しの外部呼び出しを行うコンポーネントは、依存グラフのためのものであると考えられる。

呼び出しスタックにおいてプッシュされた最初のコンポーネントは、必ずしも関心を引くコンポーネントであるわけではない。呼び出しスタックにおいて最初に関心を引くコンポーネントは、フロントエンドとしてマークされる。ＪＶＭの外部呼び出しは、通常、ソケットを含む。トランザクション内の最後のコンポーネントとして現れるソケットは、ユーザとって必ずしも関心を引くものではない。ソケット呼び出し以前に任意のコンポーネントを関心のあるコンポーネントとしてマークするためのメカニズムを提供する。ソケット呼び出し以前で、ソケット呼び出しに最も近い関心を引くコンポーネントがバックエンドとしてマークされる。基準値の構成における、例えば、サーブレット、ＥＪＢ、ＪＤＢＣ／データベース、等々のいくつかの事前に定義された関心を引くコンポーネントの種類を提供することができる。ユーザは、トレーサの拡張機能によって関心を引く種類を拡張することができる。

さらに、依存グラフにおいて、ソースとターゲットの頂点から構成される辺、および開始辺は、外部頂点とフロントエンドのコンポーネントとの間にある。開始頂点は、通常、クラウドまたは外部のコンポーネントのいずれかによって表される。

図４Ｆは、図４Ａのトランザクショントレースに基づく単一のＪＶＭトランザクションの呼び出しスタックを示す。ＢＴＡ１は、単一のＪＶＭトランザクションの例で、呼び出しアプリケーションのＪＶＭ内に限定されるものである。ＢＴＡ１は、アプリケーションＡのＪＶＭ内に制限されている。一つの可能な実装において、外部頂点４０５は、入ってくるＨＴＴＰリクエストによって提供されるが、ＨＴＴＰリクエストは、サーブレットＡ１ ４０２を呼び出し、サーブレットＡ１ ４０２は次にＰＯＪＯＡ１ ４０６を呼び出す。ＰＯＪＯＡ１は、次にデータベースＸを呼び出す。データベースへの呼び出しは、データベースコネクティビティをJava（登録商標）アプリケーションに提供するソフトウェアコンポーネントであるＪＤＢＣドライバ４０８を介して送られる。ＪＤＢＣドライバ４０８から実際の物理的なデータベース、即ちデータベースＸへのプロセス間の通信フローは、ソケット４１０を介して通過する。

ＢＴＡ１ ４２２のための呼び出しスタックは、サーブレットＡ１のスタックエレメント４２０、ＰＯＪＯＡ１のスタックエレメント４１６、ＪＤＢＣドライバのスタックエレメント４１４およびソケットのスタックエレメント４１２を含む。これらのスタックエレメントに基づいて、エレメント間の辺は、依存グラフの作成における使用のために定義される。これらは、サーブレットＡ１がＰＯＪＯＡ１に依存していることを示す辺４７２、ＰＯＪＯＡ１がＪＤＢＣドライバに依存していることを示す辺４７１、およびＪＤＢＣドライバがソケット呼び出しに依存していることを示す辺４７０を含む。

図４Ｇおよび図４Ｈは、図４Ｆの呼び出しスタックのための依存ダイグラフの枝刈り前および枝刈り後を、それぞれ示す。前述したように、いくつかのコンポーネントは、関心を引くとは考えられないため、依存グラフを準備する前に枝刈りされる。例えば、ＰＯＪＯＡ１には関心がないと仮定すると、サーブレットＡ１とＰＯＪＯＡ１間の辺４７２は、破棄される。代わりに、辺４７３は、サーブレットＡ１とＪＤＢＣドライバ間で延長される。同様に、ＪＤＢＣドライバとソケット間の辺４７０は、ＪＤＢＣドライバがバックエンドとしてマークされるため、重要なものとして扱われないと仮定する。この例では、図４Ｇの呼び出しシーケンスは、図４Ｈの呼び出しシーケンスを取得するために、ＰＯＪＯＡ１ ４０６およびソケット４１０を除去することによって枝刈りされる。

図４Ｉは、図４Ｂおよび図４Ｃのトランザクショントレースに基づくクロスＪＶＭトランザクションの呼び出しスタックを示す。クロスＪＶＭトランザクションは、複数のＪＶＭおよびトランザクションの呼び出しスタックを含む。ＢＴＡ２は、クロスＪＶＭ業務トランザクションの例である。１つの可能な実装では、外部頂点４４０は、入ってくるＨＴＴＰリクエストによって提供されるが、ＨＴＴＰリクエストは、サーブレットＡ２ ４０２を呼び出し、サーブレットＡ２ ４０２は次にウェブサービスクライアント４４２を呼び出す。即ち、サーブレットＡ２からサーブレットＢ１ ４１２へのウェブサービス呼び出しは、プロセス間のソケット４４４を介して送られる。この呼び出しは、クロスＪＶＭ呼び出し４９０である。ＢＴＡ２ ４５２のための呼び出しスタックは、サーブレットＡ２のスタックエレメント４５０、ウェブサービスクライアントのスタックエレメント４４８およびソケットのスタックエレメント４４６を含む。これらのスタックエレメントに基づいて、エレメント間の辺は、依存グラフの作成における使用のために定義される。これらは、サーブレットＡ２がウェブサービスクライアントに依存していることを示す辺４８１、およびウェブサービスクライアントがソケット呼び出しに依存していることを示す辺４８０を含む。

ＢＴＢ１については、外部頂点４６０は、アプリケーションＡから入ってくる呼び出しを表す。これは、サーブレットＢ ４１２を呼び出し、サーブレットＢ１ ４１２は、次にＪＤＢＣドライバ４６２を呼び出す。ＪＤＢＣドライバ４６２は、ソケット４６４を介してデータベースＹへの呼び出しを行う。ＢＴＢ１ ４９１のための呼び出しスタックは、サーブレットＢ１のスタックエレメント４７０、ＪＤＢＣドライバのスタックエレメント４６８およびソケットのスタックエレメント４６６を含む。これらのスタックエレメントに基づいて、エレメント間の辺は、依存グラフの作成における使用のために定義される。これらは、サーブレットＢ１がＪＤＢＣドライバに依存していることを示す辺４８３、およびＪＤＢＣドライバがソケット呼び出しに依存していることを示す辺４８２を含む。サーブレットＢ１からデータベースＹへのデータベース呼び出しは、単一のＪＶＭ業務トランザクションＢＴＢ１の一部だけではなく、クロスＪＶＭ業務トランザクションＢＴＡ２の一部でもあることに注意されたい。したがって、与えられたコンポーネント／サブシステムは、１以上の業務トランザクションの一部である。

一例において、業務トランザクションＢＴＡ２およびＢＴＢ１の両方のソケットに対する辺は、それらのソケットの前におけるバックエンドマーカの出現により重要であるとは考えられない。このケースでは、辺４８０および４８２は、辺４８１および４８３を残して枝刈りする。

図４Ｊおよび図４Ｋは、図４Ｉの呼び出しスタックのための依存ダイグラフの枝刈り前および枝刈り後を、それぞれ示す。上記の例では、図４Ｊの呼び出しシーケンスは、ソケット４４４および４６４を削除することによって枝刈りされる。外部頂点４６０は、ウェブサービスクライアント４４２によって実質的に置き換えられるため、同様に枝刈りされる。

図５Ａは、図４Ｈおよび図４Ｋの枝刈りされた依存ダイグラフに基づく、アプリケーションＡの細部を記した依存グラフを示す。業務トランザクションＢＴＡ１およびＢＴＡ２は、アプリケーションＡの依存グラフの一部である。ＢＴＡ１およびＢＴＡ２は、アプリケーションＡの１つの依存グラフまたはマップを形成するために結合される。ＢＴＡ１で呼び出されたＪＤＢＣドライバは、呼び出しの物理的データベース、即ちデータベースＸの名称によってラベル付けされている。サーブレットＡ１ ４０２およびサーブレットＡ２ ４０４は、別のインスタンスにおけるアプリケーションＡのためのフロントエンドであるため、アプリケーションＡと名付けられた頂点またはノード５０２の内部で共にグループ化される。

アプリケーションの、詳細な依存グラフの表示は、すべての呼び出されたバックエンドとのすべてのその関係／辺を示し、例えば、アプリケーションＢのノード５０４によって示されるような他のアプリケーションとの任意のクロスＪＶＭ関係などを含んでいる。サーブレットＡ１ ４０２とデータベースＸ ４０１の間の辺５２５、サーブレットＡ２ ４０４とウェブサービスクライアント４４２の間の辺５２３、ウェブサービスクライアント４４２とアプリケーションＢ ５０４の間の辺５２４、などの辺もまた表示される。アプリケーションＡに焦点が当てられているため、１つのオプションにおいては、サーブレットＢ１およびデータベースＹのための頂点ならびにサーブレットＢ１とデータベースＹの間の辺は、デフォルトとして示されない。必要に応じて、これらの項目は、例えば、図５Ｂに示されるように、ユーザコマンドに基づいて表示される。共通の一般化された外部頂点５００は、アプリケーションＡおよびアプリケーションＢのために示され、サーブレットＡ１に対する辺５２０、サーブレットＡ２ ４０４に対する辺５２１、およびアプリケーションＢ ５０４に対する辺５２２を表す。

図５Ｂは、図４Ｈおよび図４Ｋの枝刈りされた依存ダイグラフに基づく、アプリケーションＡおよびアプリケーションＢの細部を記した依存グラフを示す。このオプションにおいて、サーブレットＢ１ならびにデータベースＹのための頂点またはノード４１２および４３１は、サーブレットＢ１ ４１２とデータベースＹ ４３１の間の出ていく辺５２６とともに、それぞれ示される。診断のもとでの１以上の業務トランザクションに関するそれ以上の詳細を表示するため、ユーザはこのオプションを選択し得る。この例では、アプリケーションＢが呼び出され、業務トランザクションＢＴＢ１の一部である。サーブレットＢ１は、アプリケーションＢの唯一のフロントエンドであり、アプリケーションＢと名付けられたノード５０４内に表示される。一般的に、ユーザは、依存グラフ内のアプリケーションの概要表示または詳細表示を選択することができる。

図６Ａは、図４Ｈおよび図４Ｋの枝刈りされた依存ダイグラフに基づく、業務サービスの概要表示を提供するユーザインタフェース（ＵＩ）を示す。ＵＩ６００は、ユーザが拡張するまたは折り畳む、および、選択する、ことができる、ラベル付きのノードと一緒にツリー領域６０２を含む。ツリーは、業務サービスの表示を提供するために選択されるノード、ここでは業務サービス１の例示のサブノードが提供されている、および、フロントエンドの表示を提供するために提供されるノードを含む。業務サービス１は、太字、下線、イタリック体の文字列で示されるように、ユーザによって選択され、依存グラフ６０１の現在の表示はこの選択に基づいている。ボタン６０４は、依存グラフ６０１の概要表示を提供するために選択され、一方、ボタン６０６は、これに代えて詳細表示を提供するために選択される。

業務サービスは、株式取引のウェブサイトのために株式の取引を実行する、書籍購入のウェブサイトのために書籍を購入する、または企業の福利厚生制度のために福利厚生に登録する、など一般的な共有された目的を達成するため、協働する複数の業務トランザクションを含む。この例では、ＢＴＡ１およびＢＴＡ２は、同じ業務サービス（業務サービス１）の一部である業務トランザクションである。業務サービスの概要は、ＢＴＡ１およびＢＴＡ２に含まれるすべての頂点および辺の結合を提供する依存グラフによって定義される。また、付加されたプレースホルダのノード６０８および６１２は、ＢＴＡ１およびＢＴ２をそれぞれ表現するために提供される。この表示では、辺およびノードに特別な強調表示はされていない。

依存グラフは、第１および第２レベルのトリアージャと連動することができる。トリアージャの役割は、アプリケーション／トランザクションを監視すること、および、もし何らかの問題が特定のアプリケーション／トランザクションによって発生した場合に適切な業務およびＩＴオーナに通知することを含む。これらの目的のためには、アプリケーションのコンポーネントを特定することなくアプリケーションを識別できれば十分である。アプリケーションの詳細表示は、アプリケーションおよび関心を引くソフトウェアコンポーネントの数の増加に伴って複雑になることから、アプリケーションの依存グラフの概要表示は、下位レベルの詳細をユーザから隠すことによって複雑さを軽減することができるので、有用である。

概要表示において、アプリケーションのすべてのフロントエンドのコンポーネントは、アプリケーションのノードにおいて非表示である。アプリケーションからそのバックエンドのコンポーネントへ出ていく辺は、クロスＪＶＭの辺に加えて表示される。さらに、アプリケーションのノードは、アプリケーションのメトリックによって修飾され、辺（例えば、アプリケーションとそのバックエンドの間、およびアプリケーションとクロスＪＶＭアプリケーションの間）は、バックエンドの関係メトリックによって修飾される。アプリケーションのノードと特定のバックエンドの型（例えば、ウェブサービスおよびＥＪＢバックエンド）との間の辺は、依存グラフの概要表示の複雑さを軽減するため、共にグループ化される。ユーザは、アプリケーションの正常性とそのバックエンドとのその関係を監視するために、これらのノードおよび辺についての警告を作成することを許容されている。警告が性能メトリックに設定されている場合、頂点または辺のための警告アイコンが表示される。警告アイコンは、アプリケーションの性能指標であり、ユーザがアプリケーションおよびそのバックエンドの正常性を監視したり、診断したりするのに役立つ。１つのアプローチでは、警告アイコンは、いくつかの状態、即ち、正常（緑）、注意（黄色）または危険（赤）のいずれか１つを表示する色分けされた円である。わかり易くすると、ここでは、暗色の円は危険または異常の状態を示し、白丸は通常の状態を示す。

例えば、アプリケーションＢのノード５０４は、アプリケーションＢのメトリックについて正常な状態を示す警告アイコン６１３を有する。アプリケーションＡのノード５０２は、アプリケーションＡのメトリックについて危険な状態を示す警告アイコン６１１を有する。その結果、ＢＴＡ１のノード６０８およびＢＴＡ２のノード６１２も、また警告アイコン６０８および６０９を有し、これらの業務トランザクションについて、全体として危険な状態にあることを示す。警告アイコン６１１は、例えば平均応答時間など、アプリケーションＡの複数のインスタンスに亘って集約メトリックに基づいて設定される。同様に、警告アイコン６１３は、アプリケーションＢの複数のインスタンスに亘っての集約的なメトリックに基づいて設定される。

メトリックもまた、ノード内またはノードに隣接して表示される。例として、図８Ｃおよび図８Ｄを参照されたい。

図６Ｂから図６Ｄに関連して説明したように、ユーザは、業務トランザクションの１つを選択することができ、これによって、選択された業務トランザクションに特有の情報を提供するよう依存グラフを変更させることができる。この選択は、ノード６０８および６１２の１つの上にまたは領域６０２のツリーを介して、置かれたマウスのようなポインティングデバイスを使用することなどにより行われる。

依存グラフ６０１は、（ａ）第１のアプリケーション（例えばアプリケーションＡ）の複数のインスタンスを表す第１のノード（例えばノード５０２）、（ｂ）第１のアプリケーションが依存する（例えば、それぞれ、アプリケーションＢ、データベースＸまたはデータベースＹ）１つのサブシステムを表す第２のノード（例えばノード５０４、４０１または４３１）、および、（ｃ）第１のアプリケーションの１つのサブシステムへの依存を表す少なくとも１つの辺／矢印を、グラフィカルに（図形を使って）表す。例えば、辺５２３および５２５は、アプリケーションＡのアプリケーションＢへの依存を表し、辺５２５は、アプリケーションＡのデータベースＸへの依存を表し、辺５２３、５２４および５２６は、アプリケーションＢのデータベースＹへの依存を表す。１つのサブシステムは、１つのサブシステムが別のサブシステムを呼び出すような場合には直接的に、または１つのサブシステムが別のサブシステムを呼び出す中間のサブシステムを呼び出す（または中間のサブシステムが別のサブシステム等々を呼び出す別の中間のサブシステムを呼び出す）ような場合には間接的に、別のサブシステムに依存している。一般的に、対象のサブシステムは、呼び出されたリソースの実行フローまたはシーケンスにおける任意の下流のサブシステムに依存していると言える。

第１のノードは、異なる複数のフロントエンドのコンポーネントを有する第１のアプリケーションの異なる複数のインスタンスを表し得る。例えば、アプリケーションＡの１つのインスタンスは、フロントエンドのコンポーネントのサーブレットＡ１を有し、アプリケーションＡの別のインスタンスは、フロントエンドのコンポーネントのサーブレットＡ２を有する（図４Ｅを参照されたい）。

第１のノードは、異なる複数の業務トランザクション内で呼び出された第１のアプリケーションの異なる複数のインスタンスを表し得る。例えば、アプリケーションＡの１つのインスタンスは、ＢＴＡ１（しかしＢＴＡ２ではない）で呼び出され、アプリケーションＡの別のインスタンスは、ＢＴＡ２（しかしＢＴＡ１ではない）で呼び出される（図４Ｅを参照されたい）。

第１のノードは、異なる複数の外部コンポーネントによって呼び出される第１のアプリケーションの異なる複数のインスタンスを表し得る。例えば、アプリケーションＡの１つのインスタンスは、外部頂点３６０によって呼び出され（図４Ａ）、アプリケーションＡの別のインスタンスは、外部頂点３７０によって呼び出される（図４Ｂ）。

第１のノードは、１つのサブシステムに依存する第１のアプリケーションの１つのインスタンスと、その１つのサブシステムに依存しないそれぞれのアプリケーションのうちの１つの別のインスタンスを表し得る。例えば、アプリケーションＡの１つのインスタンスは、データベースＸに依存し、アプリケーションＡの別のインスタンスは、例えば、エラーまたはネットワーク障害または可用性のためにデータベースＸにアクセスしない。

依存グラフは、また、（ｄ）別のサブシステムを表す第３のノード、および、（ｅ）第１のアプリケーションの別のサブシステムへの依存を表す少なくとも１つの辺を、グラフィカルに表す。例えば、アプリケーションＡを第１のアプリケーションとし、そのノード５０２を第１のノードとし、アプリケーションＢをアプリケーションＡが依存する１つのサブシステムとし、そのノード５０４を第２のノードとし、データベースＸをアプリケーションＡが依存する別のサブシステムとし、そのノード４０１を第３のノードとして、仮定する。辺５２５は、アプリケーションＡのデータベースＸ ４０１への依存を表す。アプリケーションＡの１つのインスタンスは、データベースＸへは依存しないが、アプリケーションＢには依存することが可能であり、アプリケーションＡの別のインスタンスは、アプリケーションＢには依存しないが、データベースＸには依存することが可能である。

さらに、依存グラフは、（ａ）複数の個別のアプリケーションのうちの１つのアプリケーション（例えばアプリケーションＡ）の複数のインスタンスまたはデプロイメントを示す第１のノード（例えばノード５０２）、（ｂ）複数のアプリケーションのうちの別のアプリケーション（例えばアプリケーションＢ）の複数のインスタンスを表す第２のノード（例えばノード５０４）、および（ｃ）上記の１つのアプリケーションの、上記の別のアプリケーションへの依存を表す少なくとも１つの辺（例えば５２３、５２４）を、グラフィカルに表す。

複数のアプリケーションの１つの少なくとも１つのインスタンスは、ウェブサービス（例えば、ウェブサービスクライアント４４２）を介して複数のアプリケーションの別の１つのアプリケーションの少なくとも１つのインスタンスを呼び出すことができ、依存グラフは、そのウェブサービスをグラフィカルに表す。

複数のアプリケーションのうちの１つの少なくとも１つのインスタンスは、クロスＪＶＭ呼び出しを介して複数のアプリケーションの別の１つの少なくとも１つのインスタンスを呼び出すことができる（例えば、アプリケーションＡからアプリケーションＢへの呼び出しはクロスＪＶＭ呼び出しである−図４Ｉを参照されたい）。

第１のノードは、複数のアプリケーション（例えばアプリケーションＢ）の別の１つを呼び出す複数のアプリケーション（例えばアプリケーションＡ）の１つの、少なくとも１つのインスタンスを表し、複数のアプリケーションの別の１つを呼び出さない複数のアプリケーションの１つの、別のインスタンスを表す。例えば、前述のように、エラーまたはネットワークの可用性のため、１つのサブシステムは別のサブシステムを異なる時間に呼び出したり呼び出さなかったりする。

依存グラフ６０１は、与えられた期間で呼び出されるすべてのパスおよびサブシステムの表示を提供するために、ＢＴＡ１およびＢＴＡ２の複数のインスタンスを有利に集約する。

図６Ｂは、業務トランザクションＢＴＡ１が選択された後の図６Ａのユーザインタフェースを示す。ＢＴＡ１のノードがツリーの領域６０２において強調表示されることに注意されたい。業務トランザクションの概要表示は、アプリケーションの概要表示に関してトランザクションのフローを表示する。フロントエンドから呼び出されたすべてのノードは、たとえそれらが業務トランザクションの一部ではないとしても、表示に含まれる。しかしながら、１つのアプローチにおいて、業務トランザクションの一部であるノードおよび辺だけが強調表示される。これは、ノード６０８、５０２および４０１ならびにそれらの間にある辺６７２および５２５を含む。アプリケーションに入ってくる辺が業務トランザクションの一部ではない場合、その入ってくる辺は含まれない。ここで、ＵＩ６１０において、業務トランザクションＢＴＡ１の概要表示が依存グラフ６０３によって提供される。アプリケーションＡ ５０２とウェブサービス４４２の間の辺５２３、およびウェブサービス４４２とアプリケーションＢ ５０４の間の辺５２４は、ＢＴＡ１の一部ではないにもかかわらず、それらは依然として表示されるが、強調表示はされない。ＢＴＡ１の一部である辺（６２７および５２５）は、それらがＢＴＡ１の一部であるために強調表示される。１つのアプローチでは、アプリケーションＢはＢＴＡ１の一部ではないため、アプリケーションＢ ５０４とデータベースＸ ４３１の間の辺は表示されない。

強調表示は、異なる色、より太いノードの枠やより太い辺（ここで行われているように）などの様々な可視化技術を用いて実現される。

依存グラフ６０３は、ＢＴＡ１のために与えられた期間で呼び出されるすべてのパスおよびサブシステムの表示を提供するために、ＢＴＡ１の複数のインスタンスを有利に集約する。

選択された業務トランザクションに特有の依存グラフにおいて、選択された業務トランザクションと同様に、特有の警告アイコンおよびメトリックが提供される。例えば、アプリケーションＡのための、メトリックまたは警告アイコンは、ＢＴＡ１に関連して呼び出されるアプリケーションＡのインスタンスに関して集約されるが、ＢＴＡ２のような別の業務トランザクションに接続して呼び出されるアプリケーションＡのインスタンスに関することはない。

依存グラフは、（ａ）第１のアプリケーション（例えばアプリケーションＡ）が呼び出される第１の業務トランザクション（ＢＴＡ１）を表す第１の識別子（例えばノード６０８のＢＴＡ１）、（ｂ）第１のアプリケーションの複数のインスタンスを表すノード（例えば５０２）、（ｃ）第１の業務トランザクションに関連して第１のアプリケーションが依存する１つのサブシステム（例えばデータベースＸ）を表すノード（例えば４０１）、および（ｄ）第１の業務トランザクションに関連して第１のアプリケーションの１つのサブシステムへの依存を表す少なくとも１つの辺（例えば５２５）を、グラフィカルに表す。アプリケーションＡのインスタンスおよびデータベースＸは、それらが実行フロー内で呼び出されている、より多くの業務トランザクションのコンポーネントの１つに基づいてＢＴＡ１に関連付けられている実行フロー内で呼び出されるため、ＢＴＡ１に接続される（図８Ａも参照されたい）。

第１の識別子は、少なくとも１つの辺（例えば６２７）によって、第１のアプリケーションの複数のインスタンスを表すノード（例えば５０２）に接続されているノード（例えば６０８）によってグラフィカルに表される。

第１のアプリケーションは、また第２の業務トランザクション内でも呼び出される（例えばＢＴＡ２−図６Ｃを参照されたい）。このケースでは、依存グラフは、（ｅ）第２の業務トランザクションを表す第２の識別子（例えばノード６１２のＢＴＡ２）、（ｆ）第２の業務トランザクションに関連して第１のアプリケーションが依存する別のサブシステムを表すノード（例えばアプリケーションＢ）、および（ｇ）第２の業務トランザクションに関連して第１のアプリケーションの別のサブシステムへの依存を表す少なくとも１つの他の辺（例えば、５２３、５２４）を、グラフィカルに表す。

図６Ｂに示すように、第１の業務トランザクション（例えばノード６０８）のユーザの選択に応答して、依存グラフは、第２の識別子に対して、そして、おそらく他の業務トランザクションの識別子に対して第１の識別子を視覚的に区別し、別のサブシステムを表すノードに対して上記の１つのサブシステムを表すノードを視覚的に区別し、少なくとも別の１つ辺に対して上記の少なくとも１つの辺を視覚的に区別する。

第１のアプリケーションは、呼び出されている第１のアプリケーションの、少なくとも１つの第１の予め選択されたコンポーネント（例えばサーブレットＡ１−図４Ｅを参照されたい）に基づいて第１の業務トランザクションによって呼び出され、そして第１のアプリケーションは、呼び出されている第１のアプリケーションの第２の予め選択されたコンポーネント（例えばサーブレットＡ２−図４Ｅを参照されたい）に基づいて第２の業務トランザクションによって同様に呼び出される。

図６Ｃは、業務トランザクションＢＴＡ２が選択された後の図６Ａのユーザインタフェースを示す。ＢＴＡ２のノードは、ツリーの領域６０２において強調表示されていることに注意されたい。ＵＩ６２０の依存グラフ６０５において、ＢＴＡ２の概要表示は、ＢＴＡ２のノード６１２、アプリケーションＡのノード５０２、ウェブサービスクライアントのノード４４２、アプリケーションＢのノード５０４およびデータベースＹのノード４３１、ならびにそれらの間の辺（辺５２７、５２３、５２４および５２６）を強調表示する。強調表示された辺は、アプリケーションＢ ５０４とデータベースＹ ４３１の間の辺５２６を含むが、ＢＴＡ１の概要表示には含まれていない（図６Ｂ）。アプリケーションＡ ５０２とデータベースＸ ４０１間の辺５２５は、それはＢＴＡ２のトランザクションフローには関与しないため、強調表示されない。これは、トリアージャが関連するコンポーネントについて迅速にトラブルシューティングに注力することを許容する。

依存グラフ６０５は、ＢＴＡ２のために与えられた期間で呼び出されるすべてのパスおよびサブシステムの表示を提供するために、ＢＴＡ２の複数のインスタンスを有利に集約する。

図６Ｄは、業務トランザクションＢＴＢ１が選択された後の図６Ａのユーザインタフェースを示す。ＢＴＢ１のノードは、ツリーの領域６０２において強調表示されていることに注意されたい。ＵＩ６３０の依存グラフ６０７において、ＢＴＢ１の概要表示は、ＢＴＢ１のノード６１４、アプリケーションＢのノード５０４およびデータベースＹのノード４３１、ならびにそれらの間の辺を強調表示する。

依存グラフ６０７は、ＢＴＢ１のために与えられた期間で呼び出されるすべてのパスおよびサブシステムの表示を提供するために、ＢＴＢ１の複数のインスタンスを有利に集約する。

図７Ａ１は、図４Ｈおよび図４Ｋの枝刈りされた依存ダイグラフに基づく概要表示を提供するユーザインタフェースを示す。ここでは、アプリケーションＡがフロントエンドの表示において選択されている。この選択は、アプリケーションＡのノード５０２をクリックすることによって、またはツリーの領域６０２を介して行われ、アプリケーションＡのノードの強調表示によってこの選択が示される。ＵＩ７００において、依存グラフ７０１は、業務トランザクションの定義に関係なく、ノードが依存するすべてのノードおよびこれらのノード間の辺を識別することによって、アプリケーションＡのためのフロントエンドの表示を提供する。ＵＩ７００の付加された領域７０２は、ツリーの領域６０２内で選択されたノードのための情報を提供する。例えば、付加された情報は、アプリケーションＡのコンポーネントおよびそれらが呼び出すコンポーネントを含む。具体的には、アプリケーションＡは、データベースＸを呼び出すサーブレットＡ１、およびウェブサービスクライアントを呼び出すサーブレットＡ２を含む。各コンポーネントの名称は、コンポーネントに特有の付加的な情報を取得するためにユーザによって選択されるハイパーリンクである。

図７Ａ２は、図７Ａ１のユーザインタフェースに適用される経時変化処理を示す。経時変化処理は、依存グラフのいずれにも適用し得るものであり、最近呼び出されていないという理由によって関連性が低いとされたコンポーネントを削除する。これによってユーザは、生きているトランザクションの診断に重点的に取り組むことができる。頂点および辺の経時変化は、最後に呼び出された辺の経過時間に基づく。経過時間は、現在の時刻からの、または別の参照時刻からの経過した時間である。ある辺の経過時間が第１の閾値の経過時間よりも古い場合、その辺は、経過時間が第１の閾値の経過時間を超えない基準ケースと比較して、異なる視覚的外観である経時変化した外観を有するように描画（レンダリング）される。その入ったり出たりするすべての辺が経時変化した外観を有する場合、頂点は経時変化した外観によって示される。さらに、経時時間が、第１の閾値の経時時間よりも長い第２の閾値の経時時間を超える場合、その頂点および辺は、依存グラフから完全に削除される。これらの閾値の経時時間は、ユーザによって設定可能である。ＵＩ７０４の依存グラフ７１１において、点線はデータベースＸ ４０１を示し、アプリケーションＡ ５０２からデータベースＸ ４０１への辺５２５は経時変化した外観を示す。したがって、データベースＸのノード４０１および辺５２５は、第１の閾値の経時時間よりも古い。この例では、（アプリケーションＡ、データベースＸの）辺は、その最後に報告された日付が削除時間枠内に収まるため、表示中に依然として含まれる。つまり、辺の経時時間は、第１の閾値の経時時間よりも大きいが、第２の閾値の経時時間には至っていない。

１つの状況として、アプリケーションＡを第１のアプリケーション（第１のノード５０２によって表される）として、およびデータベースＸをアプリケーションＡが依存する１つのサブシステム（第２のノード４０１によって表される）として仮定する。第１のアプリケーション（アプリケーションＡ）が１つのサブシステム（データベースＸ）を呼び出したときからの経過時間が閾値（第１の閾値の経時時間）を超えた場合、依存グラフは、第２のノード（４０１）の経時変化をグラフィカルに表す。また、第１のアプリケーションが１つのサブシステムを呼び出したときからの経過時間が閾値（第２の閾値の経時時間）を超えた場合、依存グラフは更新され、第２のノードが削除される。

図７Ａ３は、図７Ａ１のユーザインタフェースに適用される経時変化処理の別の例を示す。ＵＩ７０６は依存グラフ７０８を提供する。別の状況では、アプリケーションＡを第１のアプリケーション（第１のノード５０２によって表される）として、アプリケーションＢをアプリケーションＡが依存する１つのサブシステム（第２のノード５０４によって表される）として、およびデータベースＹをアプリケーションＢが依存する別のサブシステム（第３のノード４３１によって表される）として仮定する。依存グラフは、（ｄ）別のサブシステムを表す第３のノード（４３１）、および（ｅ）１つのサブシステムの、もう１つのサブシステムへの依存を表す少なくとも別の辺（５２６）を、グラフィカルに表す。第１のアプリケーションが１つのサブシステムを呼び出したときからの経過時間が関連付けられた閾値（第１の閾値の経時時間）を超える場合、および、１つのサブシステムが別のサブシステムを呼び出したときからの経過時間が関連付けられた閾値（第１の閾値の経時時間）を超える場合、依存グラフは、第２のノードの経時変化をグラフィカルに表す。この経時変化は、アプリケーションＢのノード５０４の点線の枠によって示される。

別のアプローチにおいて、第１のアプリケーションが１つのサブシステムを呼び出したときからの経過時間が関連付けられた閾値（第２の閾値の経時時間）を超える場合、および、その１つのサブシステムが別のサブシステムを呼び出したときからの経過時間が関連付けられた閾値（第２の閾値の経時時間）を超える場合、依存グラフは更新され、第２のノードが削除される。これは図７Ａ４によって示される。図７Ａ４は、図７Ａ１のユーザインタフェースに適用される経時変化処理のさらなる例を示す。ＵＩ７１０は依存グラフ７１２を提供する。１つのアプローチにおいて、ノードが経時変化によって削除される場合、下流のノードおよび辺もすべて削除される。さらに、ノードへのウェブサービス呼び出しが削除される。

図７Ｂは、詳細表示における図７Ａのユーザインタフェースを示す。ＵＩ７１０において、詳細表示のためのボタン６０６が選択されると、依存グラフ７０３が各アプリケーションで呼び出されるコンポーネントを特定する。１つのアプローチにおいて、アプリケーションのノードの詳細表示は、アプリケーションに関与する業務トランザクションのためのフロントエンドのコンポーネントを表示する。具体的には、アプリケーションＡのノード５０２内に、サーブレットＡ１ ４０２およびサーブレットＡ２ ４０４のノードが表示され、そしてアプリケーションＢのノード５０４内に、サーブレットＢ１のノード４１２が表示される。辺は、またアプリケーションのノードにではなく、特定のコンポーネントに接続されるように変更される。

依存グラフは、ユーザの選択に基づいて、概要表示または詳細表示のいずれか一方を選択的に提供される。その概要表示においては、第１のノード（例えばノード５０２）は、複数のアプリケーションのうちの１つのアプリケーション（例えばアプリケーションＡ）の複数のインスタンスの呼び出されたコンポーネントを特定することなく、複数のアプリケーションのその１つのアプリケーションの複数のインスタンスを表す。その詳細表示においては、第１のノードは、複数のアプリケーションの１つアプリケーションの複数のインスタンスの呼び出されたコンポーネント（例えばサーブレットＡ１、サーブレットＳ２）を特定するとともに複数のアプリケーションのうちのその１つのアプリケーションの複数のインスタンスを示す。

図７Ｃは、図４Ｋの枝刈りされた依存ダイグラフに基づく概要表示を提供するユーザインタフェースを示す。ここでは、アプリケーションＢがフロントエンドの表示において選択されている。ＵＩ７２０において、依存グラフ７０５は、アプリケーションＢのノード５０４、データベースＹのノード４３１および辺５２６を示す。アプリケーションＢの上流でありアプリケーションＢを呼び出すノードは、表示されない。この表示により、ユーザは特定のアプリケーションおよびそれが呼び出すサブシステムに重点的に取り組むことができる。付加的な領域７０２は、更新され、アプリケーションＢにおけるサーブレットＢ１に関する情報を提供する。

図７Ｄは、詳細表示における図７Ｃのユーザインタフェースを示す。ＵＩ７３０において、詳細表示のためのボタン６０６が選択されると、依存グラフ７０７が各アプリケーションで呼び出されるコンポーネントを特定する。具体的には、アプリケーションＢのノード５０４内にサーブレットＢ１ ４１２が表示される。辺５２６もまた変更され、アプリケーションのノード５０４にではなく、サーブレットＢ１に接続される。

図７Ｅは、図７Ａまたは図７Ｂのユーザインタフェースに基づくアプリケーションＡのための正常性メトリックを提供するユーザインタフェースを示す。特定のアプリケーションなどの、フロントエンドのサブシステムのための正常性または性能メトリックは、ツリーの領域６０２を介してアクセスされ、拡張される。この例では、アプリケーションＡの下のノード、正常性が選択されている。正常性メトリックは、平均応答時間、間隔ごとの応答、同時呼び出し、間隔ごとのエラーおよびストールカウントなどの情報を提供する、グラフ、テーブルまたは他の視覚的表現を含み得る。

応答時間は、時間間隔におけるアプリケーションＡの複数のインスタンスの複数の呼び出しに関する平均である。残りのメトリックは、時間間隔について同様に集約される。

図８Ａは、１以上のアプリケーションの操作を示す際に用いられる階層を示す。証券取引を含む業務サービスに関する特定の例が提示されている。複数の異なるレベルの階層が必要な組織構造に基づいて定義され得る。例えば、階層は、人間が理解し易い用語を含み、その用語は、クライアントの、監視されるアプリケーションとの相互関係の理解を容易にするものである。階層は、相互関係が営利目的の業務の領域にあるか否か、例えば、電子商取引のトランザクションか、教育組織または政府組織のためにあるかなど、アプリケーションとの相互関係の類型を包含する。さらに、１以上の階層は、各ノードが記述名を持つ１以上の階層の複数の異なるレベルにおけるノードを含む。階層は、人間のオペレータにいっそう理解され易い仕方でアプリケーションを実行するやり方についての情報を、体系化する方法を提供する抽象的な構成であると考えられる。

階層の最上位レベルは、「ドメイン」と名付けられたドメインレベル８００である。階層の次のレベルは、業務サービスレベル８０２である。業務サービスの例は、ウェブサイトを用いた株式やその他の金融商品を扱う取引に関連する。このように「取引」は、階層の業務サービスレベルにおけるノードの名称である。取引業務サービスの特定のインスタンスは、例えば、特定のユーザが取引を実行すると発生する。他の業務サービスの例には、書籍販売のウェブサイトのための「書籍購入」、および福利厚生制度における従業員登録のための「福利厚生に登録」などがある。

階層の次のレベルは、業務トランザクションレベルである。前述したように、業務トランザクションは、ウェブサイトにログインしてアイテムを発注するなどのように、クライアントの観点からタスクを表す。業務サービスは、複数の業務トランザクションで構成され得る。例えば、取引に対しては、業務トランザクションは、ログイン８０４（例えば、ウェブサイトにログイン）、残高８０６（例えば、口座の残高を取得する）、取引概要８０８（例えば、最近の売買活動の報告を取得する）、発注８１０（例えば、オプション以外の株または債権のような証券を売買するために発注する）、およびオプション取引８１２（リサーチおよび／またはオプション取引を行う）を含む。ユーザがアカウントにログインしようとすると、ログインの特定のインスタンスが発生する。

さらに業務トランザクションは、１以上の業務トランザクションコンポーネントに関連付けられる。業務トランザクションコンポーネントは、サーブレットまたはＥＪＢのなどのアプリケーションのコンポーネントの任意の型である。１つのアプローチでは、アプリケーションのコンポーネントの１つは、業務トランザクションのためのトランザクションコンポーネントを識別する、業務トランザクションコンポーネントとして設定される。業務トランザクションコンポーネントが識別するトランザクションに関連付けられている個々のトランザクション。トランザクションは、クライアントに対応するレスポンスを提供するために、クライアントからのリクエストに応答して呼び出されるソフトウェアコンポーネントのシーケンスを表す。例えば、業務トランザクションコンポーネントは、エージェントによって報告されたコンポーネントデータがルールのセットに一致する時期を判定することによって特定される。この定義は、例えば、特定のＵＲＬのホスト名称、ＵＲＬのパラメータ、ＨＴＴＰポストのパラメータ、クッキーおよび／またはセッションマネージャのパラメータなどを含む。加えて、またはその代わりに、定義は、特定のＵＲＬのホスト名称で開始するトランザクションを必要とする。エージェントまたはマネージャは、例えば、業務トランザクションコンポーネントが業務トランザクション内に存在している時期を判定するために、コンポーネントデータとルールのセットを比較する。業務トランザクションコンポーネントが検出される場合、関係付けられた業務トランザクションは特定の型のものである。例えば、業務トランザクションコンポーネント８０５、８０７、８０９、８１１または８１３が検出される場合、関係付けられた業務トランザクションは、それぞれログイン８０４、残高８０６、取引概要８０８、発注８１０またはオプション取引８１２である。

ウェブページに関連付けられているトランザクションのために、業務トランザクションコンポーネントは、画像（例えば、.gifファイル）、カスケーディングスタイルシート（例えば、.cssファイル）、Java（登録商標）スクリプトコードコンポーネント（例えば、.jsファイル）等々のウェブページにおいて使用される下位レベルのコンポーネントに関連して呼び出される。サーブレットに関係付けられているトランザクションのために、業務トランザクションコンポーネントは、セカンダリフレーム内にロードされているJava（登録商標）サーバページズ（ＪＳＰ）に接続して呼び出される。

通常、業務トランザクションの各インスタンスは、１以上のアプリケーションまたは他のサブシステムのシーケンスのコードの実行に関与する。サブシステムは、互いに依存し、例えば、直列または分岐した連鎖で互いに呼び出す。異なる業務トランザクションが共通のサブシステムを使用することもある。サブシステムは、特定のタスクを実行する１以上のソフトウェアコンポーネントを含む。

サブシステムの例には、破線のボックスによって表される計測されたサブシステムがあり、これは、通常、フロントエンドのサブシステムである。同様に、点線のボックスによって表される未計測のサブシステムがあり、これは、通常、バックエンドのサブシステムである。あるフロントエンドのサブシステムは、ウェブサービスの呼び出しなどを介して別のフロントエンドのサブシステムを呼び出す。また、フロントエンドのサブシステムは、バックエンドのサブシステムを呼び出す。性能メトリックの全範囲は、計測されたサブシステムから取得される。限定された情報は、計測されたサブシステムからメソッドに呼び出されて使用されるメソッドから、未計測のサブシステムに着目して得られる。未計測のデータベースの場合、例えば、ＪＤＢＣドライバ（呼び出しフロントエンドと同じJava（登録商標）バーチャルマシン（ＪＶＭ）に位置する）は、データベースの応答性についての見解を与えるメトリックを提供する。未計測のメインフレームの場合、通常、メインフレームの特定のポートにメインフレームを呼び出すメソッドが存在し、その呼び出しにどのくらい時間がかかるか、またはそれがストールするか否かもしくはエラーを報告するか否かを評価できる。

多くの場合、未計測のサブシステムは、メインフレーム、データベース、または他の未計測のコンピューティングデバイスなどのバックエンドのサブシステムである。これらは不明のコンポーネント／宛先である。計測されたサブシステムは、取引サービス８２０、注文エンジン８２６、認証エンジン８２８、報告サービス８２４、認証サービス８２２および報告エンジン８３０を含む。未計測のサブシステムは、注文レコードＳＱＬ８３２、報告レコードＳＱＬ８３８、ポート番号６５４３を経由してアクセスされるシステムのｃａＤＢホスト８３４、ポート番号３４５６を経由してアクセスされるシステムのｃａＳＡＰホスト８２１および顧客レコードＳＱＬ８３６を含む。その名称にＳＱＬを含むサブシステムは、ストラクチャードクエリランゲージ（ＳＱＬ）のデータベースである。「？」は、サブシステム８３４および８２１が不明であることを示す。

コンポーネント指向のプログラミングモデルは、プログラマに、コンポーネントに関係する構成要素からアプリケーションや他のプログラムを構築させるのに役に立つ。
各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行する。さらに、コンポーネントは、コンポーネントのシーケンスがプログラム内で呼び出されるように、他のコンポーネントを呼び出し、同様に、再帰呼び出しでは自分自身を呼び出す。コンポーネント指向のプログラミングモデルの一例は、Ｊ２ＥＥであるが、Java（登録商標）サーバページズ、エンタープライズJava（登録商標）ビーンズ（ＥＪＢ）、サーブレットおよびJava（登録商標）データベースコネクティビティ（ＪＤＢＣ）のコンポーネントといったコンポーネントを用いることができる。ＪＤＢＣは、クライントがいかにデータベースにアクセスするかを定義するJava（登録商標）プログラミング言語のためのアプリケーションプログラミングインタフェース（ＡＰＩ）である。それは、データベース内のデータを照会や更新する方法を提供する。しかしながら、.NETのような他のコンポーネント指向のプログラミングモデルを使用することもできる。また、プログラミングモデルは、オブジェクト指向である必要はない。

１つの可能な実装では、コンポーネントは、クラスメソッド（ＣＭ）の組である。例えば、サーブレットはJava（登録商標）クラスの１つの例である。リクエストを受信し、対応するレスポンスを生成するのはオブジェクトである。クラスメソッドの組は、class.methodの表記により表される。クラスメソッドの組のフォーマットの例は、ServletA1.EnterOrderである。

図８Ｂは、取引の業務サービスがユーザによって選択された場合の、図８Ａの階層と一致するユーザインタフェースのさらなる例を示す。ＵＩ８４０は、ユーザが業務トランザクションまたはフロントエンドに基づいた表示を選択できるようにするためにツリーが提供された領域８４２を含む。取引の業務サービスが選択されている。取引は、前述したように、残高、ログイン、発注、オプション取引および取引概要、の業務トランザクションを含む。

この選択に対応して、多く（１以上）の関連付けられた業務トランザクション、業務トランザクションのサブシステム、および、サブシステム間の依存を示す辺が、依存グラフ８０１に表示される。左側の楕円形の頂点８０４、８０６、８０８、８１０および８１２は、業務トランザクションを特定する。辺は、業務トランザクションのためにどのサブシステムが最初に呼び出されるか、および、続いて呼び出されるサブシステムはどれかを示す。ある場合には、共通のサブシステムが別々の業務トランザクションのインスタンスのために呼び出される。与えられた業務トランザクションのインスタンスに呼び出されたコンポーネントは、コンポーネントが同じサブシステムにあったとしても、一意の識別子を用いて別途追跡することができる。また、コンポーネントまたはアプリケーションとは分離したインスタンスは、別々の業務トランザクションのインスタンスにおいて（単一の）サブシステムで呼び出される可能性もある。これらの独立したインスタンスは、再度、別々に追跡することができる。

また、同じ業務トランザクションから分離した複数のインスタンスは、同じサブシステムを呼び出す必要はないことに注意されたい。例えば、エラーまたはネットワークの障害または可用性が原因で、エラーが生じなかった場合に呼び出される特定のサブシステムを業務トランザクションのインスタンスが呼び出すことはない。また、時刻や使用可能なリソースに起因して、同じ業務トランザクションの分離したインスタンスは、別々のサブシステムを呼び出し得る。様々なバリエーションが可能である。

ノードの枠は、ノードが強調表示されているか否かを示すために使用されており、強調表示の一種になる場合もある。強調表示は、あるノードまたは辺を、他のノードまたは辺からそれぞれ視覚的に区別する方法である。異なる色が使用されることもある。あるアプローチでは、実線が強調を示す一方で、点線または破線の枠は強調を示さない。ノードの強調表示は、領域８４２におけるユーザの選択、およびＵＩにおけるノードそのもののユーザの選択、に反応する。様々な強調表示、色分けおよび他の視覚的な効果が、ユーザに情報を伝達するために提供される。サブシステムのいくつかのノードは、（ａ）フロントエンドまたは集約されたフロントエンド（例えば、同じアプリケーションコンテキストを共有するすべてのサーブレット）を示す２つの重複する画面のような記号、（ｂ）データベースを表す円筒形の記号、または（ｃ）サブシステムの種類を識別するためにソケット呼び出しの宛先である不明の（未計測の）サブシステムを表す記号を、含む。

他の種類の表記には、メトリックと警告がある。警告は、業務トランザクション（関連付けられたコンポーネントデータに基づくもの）のため、フロントエンドの全体的なパフォーマンス（「正常性」）のため、およびフロントエンドによって未計測のバックエンドまたは別のフロントエンドにされるバックエンドの呼び出しのため、に使用可能である。別のフロントエンドに行われる呼び出しは、グラフ上に現われるように、ウェブサービスまたはＥＪＢクライアントを介して行われる。前述のように、これらの警告は、ユーザによって作成および設定される。したがって、ある与えられた業務トランザクション、フロントエンドもしくはバックエンドの呼び出しは、業務トランザクションのために明示された警告を有する、または有しない。

フロントエンドのサブシステムは、ソケットを介してアプリケーションサーバからの呼び出しを行う。これらの呼び出しは、ウェブサービスの呼び出し、ＪＤＢＣドライバの呼び出しまたはその他の呼び出しである。ウェブサービスは、通常、アプリケーションプログラミングインタフェース（ＡＰＩ）またはハイパーテキストトランスファープロトコル（ＨＴＴＰ）を介してアクセスされたウェブＡＰＩであり、リクエストされたサービスをホスティングするリモートシステムにおいて実行される。これらの呼び出し、およびＪＤＢＣドライバの呼び出しのようなその他の呼び出しは、呼び出しを検出して呼び出しに関するメトリックを取得するため、依然としてアプリケーションサーバにあるが、しかしアプリケーションサーバから呼び出すことから、バックエンドコールと称される。これらのバックエンド呼び出しの宛先は、他のフロントエンド（ウェブサービスやいくつかのＥＪＢ呼び出しの場合）または未計測のバックエンドのコンポーネントのいずれかである。これらの未計測のコンポーネントのほとんどは、少なくとも部分的にはバックエンド呼び出しから識別される。例えば、ＪＤＢＣドライバの呼び出しは、その宛先データベースの名称でラベルが付されており、デフォルトのソケット呼び出しは、宛先ホストおよびポートでラベル付けされている。他の場合では、ユーザはカスタム呼び出しを定義しその宛先でラベル付けをする。これらのすべての場合で、ＵＩは、データベースまたはコンポーネントの他の適切な型を示すアイコンで適切にラベル付けされたバックエンドの宛先を表すボックスを提供する。

例えば、ソケットを介して呼び出しがあり、その呼び出しは計測されており、５６ミリ秒かかることがわかるが、その宛先（どのサブシステムをそれが呼び出したか）は不明である場合、バックエンドのノードと並んで「不明のコンポーネント」のアイコンを示し、システムのホスト名称とポートによってラベル付けされた、ＵＩにおける時間メトリックを表示し得る。バックエンド８２１、８３２、８３４、８３６および８３８は、計測されることなく、そのため宛先によって報告された情報がない宛先を表すため、実質的にグラフ内のダミーのノードである。１つのフロントエンドから別のフロントエンドへの呼び出しのために、十分な計測が可能である。その呼び出しは、例えばウェブサービスまたはＥＪＢクライアントを介して行われる。単一のフロントエンドから発しているすべてのウェブサービスの呼び出しは、集約され、単一の「ウェブサービス」のバックエンド呼び出しとして表されている。このように、他の種類の呼び出しとは異なり、ウェブサービスの呼び出しは、２以上の宛先を有する。この場合、バックエンド呼び出しは、グラフ内の二股分岐または枝分岐の矢印として現れる。ウェブサービス８４４および８４６（「Ｗ」で表される）は、同じくウェブサービスの呼び出しであるが、単一の宛先を有するもので、認証サービス８２２と認証エンジン８２８との間の呼び出しの対比として、２つのそのような二股分岐のウェブサービスの呼び出しを示す。

例えば、取引サービスのノード８２０は、複数のマシンにまたがって実行する取引サービスのサブシステムの複数のインスタンスの概要を表す。ウェブサービス８４４は、取引サービス８２０のサブシステムが実行する１以上のコンピューティングデバイス／マシンに関連付けられており、ウェブサービス８４６は、報告サービス８２４のサブシステムが実行する１以上のコンピューティングデバイス／マシンに関連付けられている。ウェブサービス８４４および８４６のメトリックまたは警告のアイコンは、１つのコンピューティングデバイスから次のコンピューティングデバイスへ行われるメソッド呼び出しの性能または正常性を表す。

１つのアプローチでは、警告は、応答時間などの時間メトリックに関連している。警告は、性能メトリックのどんな種類に基づいても設定可能である。例えば、計測は多くの種類の性能メトリックを生成することができ、それらには、コンポーネントの平均実行時間または応答時間、毎秒または間隔ごとの呼び出し率、呼び出し回数、開始したが終了していない間隔ごとの呼び出しの回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのメソッド呼び出しの回数が特定の閾値を超えた呼び出し回数を示すストール状態のメトリックが含まれる。さらに、データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定する。これらはアプリケーションの実行時に取得され、エージェントによって報告されるコンポーネントデータの例である。警告は、どんな種類のアイテムにも提供可能である。

さらに、警告は、業務トランザクションコンポーネントための１以上の性能メトリックに基づいて設定可能である。例えば、警告は、特定の時間幅を超えたサブシステムのコンポーネントの平均応答時間を表す。

警告およびメトリックアイコンに基づいて、ユーザは、ＵＩに示された、業務トランザクション、サブシステムおよび呼び出し、に関するさらなる情報を取得するために様々な手段を得ることができる。１つのアプローチでは、ユーザは、警告およびメトリックアイコンの存在によって案内され、関連付けられた、業務トランザクション、サブシステムおよび呼び出しに関するさらなる情報を、例えば問題を診断するために取得しようとする。

特定の業務トランザクションおよびそのサブシステムについて、ＵＩは、発注８１０、およびオプション取引８１２の両方が、フロントエンドのアプリケーション／サブシステム、即ち取引サービス８２０を呼び出すことを示している。ある設定例では、例えば、株や債権の売買をするため、発注される注文を決めることにより、ユーザは発注８１０を開始する。すべての、ユーザ入力ならびにユーザに与えられる情報もしくは指示が、ウェブページまたは他のＵＩを介して提供される。または、プットオプションやコールオプションのようなオプションに関係する取引を決めることによって、ユーザはオプション取引８１２を開始する。いずれの場合も取引サービスが使用される。取引サービスは、例えば、注文／取引を処理するために付加的な情報を取得するシステムｃａＳＡＰホスト８２１を呼び出す。システムｃａＳＡＰホスト８２１は、計測されていないことからそれについてはあまり知られておらず、そのノードは単なるプレースホルダである。取引サービスのインスタンスにより呼び出されるコンピューティングデバイス８２１のポートが知られており（例えば、ポート３４５６）、この情報がノード８２１を修飾するために使用される。システムｃａＳＡＰホスト８２１は、別のホストまたはリソース（図示せず）を呼び出し得るが、これは図示されていない。

コンピュータネットワークでは、ポートは、通信のエンドポイントとして貢献するアプリケーション固有またはプロセス固有のソフトウェアの構成である。例えば、トランスミッションコントロールプロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）のようなインターネットプロトコルスイートのトランスポート層のプロトコルによって使用される。特定のポートは、一般にポート番号として知られている番号、関連付けられたＩＰアドレス、および通信に使用されるプロトコルによって特定される。ＴＣＰおよびＵＤＰは、パケットのヘッダ内の送信元と宛先のポート番号を特定する。プロセスは、バインディングとして知られるプロセスで、ネットワークを介してデータを送受信するため、その入出力チャンネルのファイル記述子（ソケット）をポート番号およびＩＰアドレスと関連付ける。オペレーティングシステムのネットワーキングソフトウェアは、すべてのアプリケーションのポートからネットワークへの出ていくデータを送信するとともにパケットのＩＰアドレスとポート番号を一致させることによって到着するネットワークパケットをプロセスに転送する、タスクを有する。

プロセスは、ソケットを用いて転送プロトコルのポートとの関連付けを作成する。ソケットは、転送のエンドポイントとして使用されるソフトウェア構造である。プロセスのためにオペレーティングシステムによって作成され、ポート番号とＩＰアドレスの組み合わせで構成されたソケットのアドレスに結び付けられている。ソケットは、一度に一方向に（半二重）または同時に双方向に（全二重）データを送受信するために設定される。

取引サービス８２０は、注文／取引をリクエストするために、１以上のウェブサービス（ウェブサービスのノード８４４に集約されている）を使用する。ウェブサービス８４４は、例えばユーザの認証情報を検証するために、（ａ）注文／取引を処理する注文エンジンサブシステム８２６、および／または、（ｂ）注文／取引を認証する認証エンジンサブシステム８２８、を順々に呼び出す。グラフは、ほぼ同じ時間にまたは異なる時間（例えば、注文レコードＳＱＬデータベースへの呼び出しが行われた後）に、同じ業務トランザクションの一部または異なる業務トランザクションの一部（結局、取引サービスに関連付けられた２つの業務トランザクションが存在する）等として、これらの他サブシステムの両方を取引サービスが呼び出すことを必ずしも示すわけではない。他サブシステムは、同じ業務トランザクションの一部として呼び出されることも可能であるが、それは異なるインスタンス間である。グラフは、特定された期間のあるポイントで、取引サービスがウェブサービス８４４を用いてこれらのフロントエンドの両方を呼び出したことを伝えている。

注文エンジンサブシステム８２６は、ウェブサービス８４４からの１以上の呼び出しを処理するために２つのバックエンド、即ちＳＱＬを用いて注文レコードを格納する注文レコードＳＱＬデータベース８３２およびシステムｃａＤＢホスト８３４を呼び出す。システムｃａＤＢホスト８３４は、注文／取引を処理する付加的な情報を取得するために用いられる。認証エンジンサブシステム８２８は、例えば、ユーザ／顧客が注文／取引を行うことについて認証されていることを確認するため、顧客レコードを格納する顧客レコードＳＱＬデータベース８３６を呼び出す。

ログイン８０４の業務トランザクションは、フロントエンドのサブシステム、即ち認証サービス８２２を含む。設定例では、ログインは、認証サービスサブシステム８２２を呼び出し、認証サービスサブシステム８２２が次に認証エンジンサブシステム８２８を呼び出す。認証エンジンサブシステム８２８は、認証サービスサブシステム８２２と同等のサーバまたは異なるサーバである。認証エンジンサブシステム８２８は、ユーザのログインがパスワードと一致することを確認するための顧客レコードにアクセスするために顧客レコードＳＱＬデータベース８３６を呼び出す。制御フローは、ログイン業務トランザクションのインスタンスが終了するポイントである認証サービスシステム８２２に戻る。

残高８０６および取引概要８０８の両方が、共通のフロントエンドのサブシステム、即ち報告サービス８２４を呼び出す。設定例では、ユーザは、例えば、特定のアカウントでの資金量を知るために口座残高を取得するリクエストを行うことによって、残高を開始する。また、ユーザは、例えば注文／残高、送金などの最近のトランザクションの報告（例えばステートメント）を取得するためにリクエストを行うことによって取引概要８０８を開始する。いずれの場合も、報告サービス８２４はウェブサービス８４６を呼び出すことによって報告のリクエストを処理し、同様に、ウェブサービス８４６は認証エンジンサブシステム８２８を呼び出して、認証エンジンサブシステム８２８は、ユーザ／顧客が報告を取得することを承認されていることを確認するために顧客レコードにアクセスするため、顧客レコードＳＱＬデータベース８３６を呼び出す。

一実施形態では、制御フローは報告サービス８２４に戻り、報告サービスはウェブサービス８４６を介して報告エンジンサブシステム８３０への別の呼び出しをして、報告エンジンサブシステム３３０は報告を提供するために使用されるレコードを取得するため、報告レコードＳＱＬデータベース８３８を呼び出すことによって報告のリクエストを遂行する。ウェブサービス８４６へのこの呼び出しには、必要とされる報告の種類、アカウントの識別子、関連する時間フレームなどを特定する情報を含む。

図８Ｃは、図８Ｂのユーザインタフェースを示す。ここでは、発注の業務トランザクションがユーザによって選択された場合を示している。ＵＩ８５０において、依存グラフ８０３は、発注の１以上のインスタンスに関連付けられているノードおよび辺を強調表示している。強調表示されたノードは、８１０、８２０、８２１、８４４、８２６および８３２で、強調表示された辺は、これらのノードの間の矢印である。例示の時間メトリックもまた、例えば対応するノード上またはノード内に表示される。つまり、ＵＩとそのノードおよび辺は、メトリックによって修飾される。ここで、例示の集約応答時間は、取引サービス８２０に対しては１２００ミリ秒で、および例示の集約応答時間は、取引サービス８２０からバックエンド８２１への辺８５３によって表される呼び出しに対しては２００ミリ秒である。また、警告アイコン８５１および８５２は、それぞれノード８１０および８２０に関連付けられている。警告アイコン８５５は辺８５３に関連付けられている。これらのメトリックは、発注のような業務トランザクションの単一のインスタンスのために存在し、またより一般的には、例えば、特定の時間間隔に関するなど業務トランザクションの複数のインスタンスについての平均である。

辺８５３は、このように少なくとも１つの：集約メトリック「２００ミリ秒」および集約メトリックに基づく警告８５５により修飾されており、そしてノード８２０は、少なくとも１つの集約メトリック「１２００ミリ秒」および集約メトリックに基づく警告８５２によって修飾された第１のノードである。

ノードおよび辺が強調表示されることにより、サブシステムが複数の業務トランザクションに関連付けられているとしても、ユーザは、与えられた業務トランザクションに関連付けられているサブシステムを迅速に識別することができる。さらに、メトリックおよび警告の使用によって、ユーザは、業務トランザクション内の与えられたサブシステムに問題があることを迅速に確認でき、そのサブシステムに関する診断に重点的に取り組むことができる。また、警告の重大度はユーザに指針を示す。ＵＩ上で提供されているメトリックは、特定の時間間隔で管理されたアプリケーションからデータに基づいている。

図８Ｄは、図８Ｂのユーザインタフェースを示す。ここでは、オプション取引の業務トランザクションがユーザによって選択された場合を示している。ＵＩ８６０において、依存グラフ８０７は、オプション取引の１以上のインスタンスに関連付けられたノードおよび辺を強調表示している。強調表示されたノードは、８１２、８２０、８４４、８２６、８３４、８２８および８３６であり、強調表示された辺は、これらのノードの間にある矢印である。例示の集約応答時間は１０００ミリ秒であることが取引サービス８２０に対して示されている。また、警告アイコン８５４および８５２は、それぞれノード８１２および８２０に関連付けられている。これらのメトリックは、発注の単一のインスタンスのために存在し、あるいは、また、より一般的には、例えば、特定の時間間隔を超えた場合など、発注の複数のインスタンスについての平均である。

ノードまたは辺に対しての警告およびメトリックは、選択された業務トランザクションに特有のものであることに注意されたい。

依存グラフを提供するために用いられるデータは、選択された期間のために存在する。１つのアプローチにおいて、ユーザが「現在」ボタン８５２を選択すると、依存グラフを提供するために用いられるデータが時間の経過に応じて常に更新され、依存グラフ自体が基礎となるデータの変化に応じて更新される。例えば、データは、最後の１５分（またはいくつかの他のデフォルトまたはユーザが設定した期間）のローリングウィンドウを表すために選択される。別のアプローチにおいて、ユーザが「過去」ボタン８８０を選択すると、依存グラフを提供するために用いられるデータは、過去の所定の期間のデータに固定され、時間が経過してもそのデータは更新されない。さらに、過去の期間は、時・分・秒をＨＨ：ＭＭ：ＳＳ形式で表すタイムバー８８２上のスライダーツール８８４をドラッグすることによりユーザによって簡単に設定可能である。スライダーツールの現在の設定では、１３：３５：００からほぼ１３：４２：００までの期間が包含される。例えば、ユーザは、全体のスライダーツールをドラッグするために、またはより広い期間を含めるためスライダーツールの右および／または左の辺を延長するために、マウスを使用する。スライダーツールは、例えば、スライダーツールが水平に配置された場合にはその幅によって、スライダーツールが垂直に配置された場合にはその高さによって、過去の期間を識別する。

図９は、ユーザインタフェースを提供する方法を示す。前述のように、管理されたアプリケーションを実行すると、関連するコンポーネントデータは、アプリケーションの計測から取得される。この情報は、エージェントによってセントラルマネージャに報告される。マネージャにおけるデータは、記憶装置３１０（図３）のようなデータベース１１８（図１）に提供される。データは、本明細書で説明された機能を達成するために異なる方法でデータを問い合わせアクセスさせる、様々なデータフィールドを含む。

ステップ９００において、データは、図８Ｄに関連して説明したように、現在の期間または過去の期間に設定された分析のもとで、指定された時間間隔でアクセスされる。データは、例えば、データストアから、１回、または繰り返しアクセスされる。ステップ９０２は、期間内で呼び出されたサブシステムおよびそれらの依存関係を識別する。業務トランザクションへのサブシステムの関連付けは、発生しているトランザクションについての情報を返す報告をする特別のマップトレーサを使用して実現する。トランザクションが業務トランザクションコンポーネントに一致する場合、そのトランザクションは、業務トランザクションコンポーネントの名称でラベルが付けられ、そのトランザクション内で呼び出されるすべての下位レベルのコンポーネントが業務トランザクションコンポーネント（つまりその業務トランザクション）に関連付けられる。これらの下位レベルのコンポーネントは、後に特定のルールに基づいて「サブシステム」に集約される。グラフとツリーに現れる、フロントエンドおよびバックエンドの呼び出しは、そのコンポーネントがトレースされたトランザクションの一部としてヒットされる場合にセグメントに関連付けられて現される特定のメトリックパス（識別子）に関連付けられている。そのため、選択された業務トランザクションコンポーネントまたはフロントエンドの識別子をスレッドの最初のセグメントとして探すことによって、トランザクションを識別する。一旦、サブシステムの識別子がトランザクショントレースで発見されると、そのサブシステムの「内部」に存在することがわかる。トランザクション内でその時点から行われたすべての呼び出しは、次の認識されるサブシステム（フロントエンドまたはバックエンド呼び出し）が呼び出されるまで、同じサブシステム（グラフ内で集約するものにおけるレベルが与えられる）の必要な部分である。

ステップ９０４は、平均応答時間、同時呼び出し、間隔ごとのエラー、間隔ごとの応答およびストールカウントなどの性能メトリックを算出する。メトリックは、それぞれの、業務トランザクション、トランザクションおよびコンポーネント対して算出される。ステップ９０６は、例えば、性能メトリックをそれぞれの警告の閾値と比較するなどして、警告レベルを決定する。ステップ９０８は、ユーザインタフェースを分析対象の時間間隔についての関連する情報で表示すること、または更新することを含む。ステップ９０８はまた、ユーザコマンドに基づいてユーザインタフェースを更新することを含む。

以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。

Claims (22)

1. コンピュータに実装される方法であって第１のアプリケーションのフローを可視化する方法であり：
   第１のアプリケーション（５０２）に関するデータにアクセスするためにデータストア（１１８、３１０）にアクセスすること；そのデータは、第１のアプリケーションの複数のインスタンスを表すものであり、第１のアプリケーションにインストールされた計測を用いて第１のアプリケーションに関連付けられたエージェント（１０８、１１２、１１６）から取得される；
   ユーザインタフェース上に依存グラフを表示すること；前記依存グラフは、ユーザの選択に基づいて、概要表示（６０４）と詳細表示（６０６）のいずれか一方を提供するものであり、
   概要表示では、前記依存グラフは、（ａ）前記第１のアプリケーションの呼び出されたコンポーネントを特定することなく前記第１のアプリケーションの複数のインスタンスを表す第１のノード（５０２、８２０）を図形を使って表し、（ｂ）前記第１のアプリケーションが依存する１つのサブシステムを表す第２のノード（４０１、５０４、８２１、８２６、８２８、８３２、８３４、８３６）を図形を使って表し、（ｃ）前記第１のアプリケーションの前記１つのサブシステムへの依存を表す辺（５２３、５２４、８５３）を図形を使って表し、（ｄ）前記第１のアプリケーションが依存する別のサブシステムを表す第３のノード（４０１、４３１）を図形を使って表し、（ｅ）前記第１のアプリケーションの前記別のサブシステムへの依存を表す１つの辺（５２５、５２６）を図形を使って表し、
   詳細表示では、前記依存グラフは、（ｆ）第１のノードについて前記第１のアプリケーションの第１の呼び出されたコンポーネント（４０２、４０４）と前記第１のアプリケーションの第２の呼び出されたコンポーネント（４０２、４０４）を図形を使って表し、（ｇ）第２のノードについて前記１つのサブシステムの呼び出されたコンポーネント（４１２）を図形を使って表し、（ｈ）前記第１の呼び出されたコンポーネントの前記別のサブシステムへの依存を表す辺を図形を使って表し、（ｉ）前記第２の呼び出されたコンポーネントの前記１つのサブシステムの前記呼び出されたコンポーネントへの依存を表す別の辺を図形を使って表す；
   を有する。
2. コンピュータに実装される請求項１の方法であり：
   第１のアプリケーションの前記１つのサブシステムへの依存は、第１のアプリケーションが呼び出される第１の業務トランザクション（ＢＴＡ１、８０４、８０６、８０８、８１０、８１２）に関連しており；
   前記依存グラフは、第１の業務トランザクションを表す第１の識別子（ＢＴＡ１）を図形を使って表し；第１の識別子は、辺（６２７）によって前記第１のノード（５０２）に接続されるノード（６０８）によって図形を使って表される。
3. コンピュータに実装される請求項２の方法であり；
   第１のアプリケーションは、第２の業務トランザクション（ＢＴＡ２、８０４、８０６、８０８、８１０、８１２）内で呼び出され；
   依存グラフは、（ｄ）第２の業務トランザクションを表す第２の識別子（ＢＴＡ２）、（ｅ）第２の業務トランザクションに関連して第１のアプリケーションが依存する別のサブシステムを表すノード（４３１、４４２、５０４）、および、（ｆ）第２の業務トランザクションに関連して第１のアプリケーションの前記別のサブシステムへの依存を表す別の辺（５２３、５２４、５２６）、を図形を使って表す。
4. コンピュータに実装される請求項３の方法であり：
   ユーザによる第１の業務トランザクションの選択に応答して、前記依存グラフは、第１の識別子を第２の識別子から、前記１つのサブシステムを表すノードを前記別のサブシステムを表すノードから、および、前記第１のアプリケーションの前記別のサブシステムへの依存を表す前記１つの辺を前記別の辺から、視覚的に区別する。
5. コンピュータに実装される請求項４の方法であり：
   第１のアプリケーションは、呼び出されている第１のアプリケーション（５０２）の、第１の予め選択されたコンポーネント（サーブレットＡ１）に基づいて第１の業務トランザクションによって呼び出され；
   第１のアプリケーションは、呼び出されている第１のアプリケーションの、第２の予め選択されたコンポーネント（サーブレットＡ１）に基づいて第２の業務トランザクションによって呼び出される。
6. コンピュータに実装される請求項１から５のいずれか一項の方法であり：
   第１のノードは、異なる複数のフロントエンドコンポーネント（４０２、４０４、４１２）を有する第１のアプリケーションの異なる複数のインスタンスを表す。
7. コンピュータに実装される請求項１から６のいずれか一項の方法であり：
   第１のノードは、異なる複数の業務トランザクション（８０４、８０６、８０８、８１０、８１２）内で呼び出された第１のアプリケーションの異なる複数のインスタンスを表す。
8. コンピュータに実装される請求項１から７のいずれか一項の方法であり：
   第１のノードは、異なる複数の外部コンポーネント（３６０、３７０）によって呼び出された第１のアプリケーションの異なる複数のインスタンスを表す。
9. コンピュータに実装される請求項１から８のいずれか一項の方法であり：
   第１のノードは、前記１つのサブシステムに依存する第１のアプリケーションの１つのインスタンス、および、前記１つのサブシステムに依存しない別のアプリケーションの所定のインスタンスを表す。
10. コンピュータに実装される請求項１から９のいずれか一項の方法であり：
    第１のノードは、前記１つのサブシステムに依存するが前記別のサブシステムには依存しない第１のアプリケーションの１つのインスタンス、および、前記別のサブシステムに依存するが前記１つのサブシステムには依存しない第１のアプリケーションの別のインスタンスを表す。
11. コンピュータに実装される請求項１から１０のいずれか一項の方法であり：
    第１のアプリケーションが前記１つのサブシステムを呼び出したときからの経過時間が閾値を超えた場合、依存グラフは、第２のノードの経時変化を図形を使って表すか、あるいは、第２のノードを削除するように更新される。
12. コンピュータに実装される請求項１から１１のいずれか一項の方法であり：
    前記第１のアプリケーションの前記別のサブシステムへの依存を表す第１のノードの前記１つの辺（８５３）は、集約メトリック、および、集約メトリックに基づく警告の少なくとも１つにより修飾される。
13. コンピュータに実装される請求項１から１２のいずれか一項の方法であり：
    第１のアプリケーションが前記１つのサブシステムを呼び出したときからの経過時間が関連付けられた閾値を超える場合、および、前記１つのサブシステムが前記別のサブシステムを呼び出したときからの経過時間が関連付けられた閾値を超える場合、依存グラフは、第２のノードの経時変化を図形を使って表すか、あるいは、第２のノードを削除するように更新される。
14. コンピュータに実装される請求項１から１３のいずれか一項の方法であり：
    前記データは、スライダーツール（８８４）を介したユーザの選択に応答して、過去の期間に対して選択される。
15. コンピュータに実装される請求項１から１４のいずれか一項の方法であり：
    前記１つのサブシステムは、第１のアプリケーションが依存する別のアプリケーションの複数のインスタンスを有する。
16. コンピュータに実装される請求項１５の方法であり：
    第１のアプリケーションの１つのインスタンスは、ウェブサービス（８４４、８４６）を介して前記別のアプリケーションの１つのインスタンスを呼び出し、依存グラフは、ウェブサービスを図形を使って表す。
17. コンピュータに実装される請求項１５または１６の方法であり：
    第１のアプリケーションの１つのインスタンスは、前記別のアプリケーションの１つのインスタンスをクロスＪＶＭ呼び出し（４９０）を介して呼び出す。
18. コンピュータに実装される請求項１５から１７のいずれか一項の方法であり：
    第１のノードは、前記別のアプリケーションを呼び出す第１のアプリケーションの１つのインスタンス、および、前記別のアプリケーションを呼び出さない第１のアプリケーションの別のインスタンスを表す。
19. アプリケーションのフローを可視化するシステムであり：
    コンピュータで読み取り可能なコードを記憶する記憶装置（３１０、３４０）；
    前記記憶装置と通信するプロセッサ（２３０）；
    を有しており、前記プロセッサは、コンピュータで読み取り可能なコードであって以下の処理を行うためのコードを実行する：
    第１のアプリケーション（５０２）に関するデータにアクセスするためにデータストア（１１８、３１０）にアクセスすること；そのデータは、第１のアプリケーションの複数のインスタンスを表すものであり、第１のアプリケーションにインストールされた計測を用いて第１のアプリケーションに関連付けられたエージェント（１０８、１１２、１１６）から取得される；
    ユーザインタフェース上に依存グラフを表示すること；前記依存グラフは、ユーザの選択に基づいて、概要表示（６０４）と詳細表示（６０６）のいずれか一方を提供するものであり、
    概要表示では、前記依存グラフは、（ａ）前記第１のアプリケーションの呼び出されたコンポーネントを特定することなく前記第１のアプリケーションの複数のインスタンスを表す第１のノード（５０２、８２０を図形を使って表し）、（ｂ）前記第１のアプリケーションが依存する１つのサブシステムを表す第２のノード（４０１、５０４、８２１、８２６、８２８、８３２、８３４、８３６）を図形を使って表し、（ｃ）前記第１のアプリケーションの１つのサブシステムへの依存を表す１つの辺（５２３、５２４、８５３）を図形を使って表し、（ｄ）前記第１のアプリケーションが依存する別のサブシステムを表す第３のノード（４０１、４３１）を図形を使って表し、（ｅ）前記第１のアプリケーションの前記別のサブシステムへの依存を表す１つの辺（５２５、５２６）を図形を使って表し、
    詳細表示では、前記依存グラフは、（ｆ）第１のノードについて前記第１のアプリケーションの第１の呼び出されたコンポーネント（４０２、３０４）と前記第１のアプリケーションの第２の呼び出されたコンポーネント（４０２、４０４）を図形を使って表し、（ｇ）第２のノードについて前記１つのサブシステムの呼び出されたコンポーネント（４１２）を図形を使って表し、（ｈ）前記第１の呼び出されたコンポーネントの前記別のサブシステムへの依存を表す辺を図形を使って表し、（ｉ）前記第２の呼び出されたコンポーネントの前記１つのサブシステムの前記呼び出されたコンポーネントへの依存を表す別の辺を図形を使って表す。
20. 請求項１９のシステムであり：
    第１アプリケーションの前記１つのサブシステムへの依存は、第１のアプリケーションが呼び出される第１の業務トランザクション（ＢＴＡ１、８０４、８０６、８０８、８１０、８１２）に関連しており；
    前記依存グラフは、第１の業務トランザクションを表す第１の識別子（ＢＴＡ１）を図形を使って表す；第１の識別子は、辺（６２７）によって第１のノード（５０２）に接続するノード（６０８）によって図形的に表される；
    第１のアプリケーションは、第２の業務トランザクション（ＢＴＡ２、８０４、８０６、８０８、８１０、８１２）内で呼び出され；
    前記プロセッサは、コンピュータで読み取り可能なコードであって依存グラフに以下を図形を使って表す処理を行うコードを実行する：
    （ｄ）第２の業務トランザクションを表す第２の識別子（ＢＴＡ２）、（ｅ）第２の業務トランザクションに関連して第１のアプリケーションが依存する別のサブシステムを表すノード（４３１、４４２、５０４）、および、（ｆ）第２の業務トランザクションに関連して第１のアプリケーションの別のサブシステムへの依存を表す別の辺（５２３、５２４、５２６）。
21. 請求項２０のシステムであり：
    ユーザによる第１の業務トランザクションの選択に応答して、前記プロセッサは、コンピュータで読み取り可能なコードであって、依存グラフに、第１の識別子を第２の識別子から、前記１つのサブシステムを表すノードを前記別のサブシステムを表す前記第３のノードから、視覚的に区別させるためのコードを実行する。
22. 請求項２０または２１のシステムであり：
    ユーザによる第１の業務トランザクションの選択に応答して、前記プロセッサは、コンピュータで読み取り可能なコードであって、前記依存グラフに、前記別のサブシステムへの前記第１のアプリケーションの依存を表す前記１つの辺を前記別の辺から視覚的に区別させるためのコードを実行する。

Images