(57)【特許請求の範囲】
【請求項１】
コンピュータに実装される方法であって複数のコンポーネントを有するアプリケーションを計測する方法であり、以下を備える：
前記アプリケーション内のどのコンポーネントの内部に複数のプローブを配置するかを判定するために前記アプリケーションを自動的に静的に解析すること；
前記アプリケーションが実行されていない間に、前記判定されたコンポーネントに複数のプローブを自動的に静的に付加すること；
前記複数のプローブを静的に付加した後に前記アプリケーションを実行すること；
前記アプリケーションが実行されている間に前記静的に付加された複数のプローブからデータを受信すること；
前記データに基づいて第１のコンポーネント内の静的に付加された第１のプローブに対してメトリックを決定すること；当該メトリックは、前記第１のコンポーネントの呼び出し率と実行時間を含む；
前記第１のコンポーネントの呼び出し率が第１閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記第１のコンポーネントに対してコールグラフの上位のコンポーネントへ移動すること；
前記第１のコンポーネントの呼び出し率が、前記第１閾値以下である第２閾値よりも小さい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記コールグラフの下位のコンポーネントへ移動すること；
前記第１のコンポーネントの呼び出し率が前記第１閾値よりも大きくない場合であって前記第１のコンポーネントの実行時間が第３閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記コールグラフの下位のコンポーネントへ移動すること；
前記静的に付加された第１のプローブをコールグラフの上位又は下位へ移動することは、前記アプリケーションが実行されている間に前記静的に付加された第１のプローブを移動することを含む；
静的に付加された追加的なプローブに対して、前記メトリックを決定すること、及び、前記追加的なプローブを前記コールグラフの上位または下位へ移動すること、を繰り返すこと。
【請求項２】
請求項１の方法であって、前記静的に付加された第１のプローブを移動することは、前記アプリケーションが実行されている間に、前記第１のコンポーネントに対してコールグラフの上位又は下位のコンポーネントへプローブを挿入することを含む。
【請求項３】
請求項１の方法であり、さらに以下を含む：
前記アプリケーションの前記複数のコンポーネントの中の第２のコンポーネントの呼び出し率が前記第２閾値よりも小さく、かつ、コールグラフにおいて前記第２のコンポーネントよりも下位にコンポーネントが存在しない場合、前記第２のコンポーネントに静的に付加された第２のプローブを削除すること。
【請求項４】
請求項１の方法であって、
前記メトリックは、前記第１のコンポーネントの現在の呼び出し数を含んでおり、
前記方法は、前記第１のコンポーネントの前記呼び出し数が第４閾値よりも大きい場合、前記静的に付加された第１のプローブを前記コールグラフの下位のコンポーネントへ移動すること、を含む。
【請求項５】
プロセッサに以下の手順を実行させるためのプログラムであり、
複数のコンポーネントを有するアプリケーション内のコンポーネントであってどのコンポーネントの内部に複数のプローブを静的に配置するかを判定するために前記アプリケーションを静的に解析すること；
前記アプリケーションが実行されていない間に、前記アプリケーションの前記判定されたコンポーネントに複数のプローブを静的に付加すること；
前記複数のプローブを静的に付加した後に前記アプリケーションを実行すること；
前記アプリケーションが実行されている間に前記静的に付加された複数のプローブによってデータを集めること；
前記集められたデータに基づいて第１のコンポーネント内に静的に付加された第１のプローブに対してメトリックを決定すること；当該メトリックは前記第１のコンポーネントの呼び出し率と実行時間を含む；
前記第１のコンポーネントの呼び出し率が第１閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記第１のコンポーネントに対してコールグラフの上位のコンポーネントへ移動すること；
前記第１のコンポーネントの呼び出し率が、前記第１閾値以下である第２閾値よりも小さい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記コールグラフの下位のコンポーネントへ移動すること；
前記第１のコンポーネントの呼び出し率が前記第１閾値よりも大きくない場合であって前記第１のコンポーネントの実行時間が第３閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記コールグラフの下位のコンポーネントへ移動すること；
前記静的に付加された第１のプローブをコールグラフの上位又は下位へ移動することは、前記アプリケーションが実行されている間に前記静的に付加された第１のプローブを移動することを含み；
静的に付加された追加的なプローブに対して、前記メトリックを決定すること、及び、前記追加的なプローブを前記コールグラフの上位または下位へ移動すること、を繰り返すこと。
【請求項６】
プロセッサと、
前記プロセッサと連携しているコンピュータ可読媒体であってコンピュータ可読命令を記憶しているコンピュータ可読媒体とを備えるシステムであり、前記コンピュータ可読命令は、前記コンピュータにて実行されると、当該プロセッサに、複数のコンポーネントを有するアプリケーションを計測させるものであり、前記プロセッサは、以下の処理を実行するように構成されている：
ａ）前記アプリケーション内のどのコンポーネントの内部に複数のプローブを静的に配置するかを判定するためにアプリケーションを自動的に静的に解析すること；
ｂ）前記アプリケーションが実行されていない間に、前記判定されたコンポーネントに複数のプローブを自動的に静的に付加すること；
ｃ）前記アプリケーションが実行されている間に前記静的に付加された複数のプローブからデータを受信すること；
ｄ）前記データに基づいて第１のコンポーネント内に静的に付加された第１のプローブに対してメトリックを決定すること；当該メトリックは、前記第１のコンポーネントの呼び出し率と実行時間を含む；
ｅ）前記第１のコンポーネントの呼び出し率が第１閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記第１のコンポーネントに対してコールグラフの上位のコンポーネントへ移動すること；
ｆ）前記第１のコンポーネントの呼び出し率が、前記第１閾値以下である第２閾値よりも小さい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記第１のコンポーネントに対して前記コールグラフの下位のコンポーネントへ移動すること；
ｇ）前記第１のコンポーネントの呼び出し率が前記第１閾値よりも大きくない場合であって前記第１のコンポーネントの実行時間が第３閾値よりも大きい場合、前記静的に付加された第１のプローブを、前記アプリケーション内のコンポーネントであって前記コールグラフの下位のコンポーネントへ移動すること；
前記静的に付加された第１のプローブをコールグラフの上位又は下位へ移動することは、前記アプリケーションが実行されている間に前記静的に付加された第１のプローブを移動することを含み；
ｈ）静的に付加された追加的なプローブに対して、前記ｄ）からｇ）までを繰り返すこと。
【請求項７】
請求項６のシステムであり、
前記静的に付加された複数のプローブからの前記データに基づいて、前記プロセッサは、前記第１のコンポーネントに関連するスレッドの同時並行性が第４閾値よりも大きいか否かを判定し、
前記プロセッサは、前記第１のコンポーネントに関連するスレッドの同時並行性が前記第４閾値よりも大きい場合に、前記第１のコンポーネントに対してコールグラフの下位のコンポーネントへ前記第１のプローブを移動する。
【請求項８】
請求項５のプログラムであり、プロセッサにさらに以下の手順を実行させる：
前記静的に付加された複数のプローブからの前記データに基づいて、前記第１のコンポーネントの同時並行性が第４閾値よりも大きいか否かを判定し、
前記第１のコンポーネントの同時並行性が前記第４閾値よりも大きい場合に、前記第１のプローブを、コールグラフの下位のコンポーネントへ移動すること。
【請求項９】
請求項１の方法であり、前記第２閾値は、前記第１閾値よりも小さい。
【請求項１０】
請求項３の方法であり、さらに以下を含む：
前記第２のコンポーネントの呼び出し率が前記第１閾値よりも大きく、かつ、コールグラフにおいて前記第２のコンポーネントよりも上位にコンポーネントが存在しない場合、前記第２のプローブを前記アプリケーションから削除する。
【請求項１１】
請求項１の方法であり、さらに以下を含む：
前記複数のコンポーネントのなかの第２のコンポーネントの呼び出し率が前記第１閾値よりも大きく、かつ、コールグラフにおいて前記第２のコンポーネントよりも上位にコンポーネントが存在しない場合、前記第２のコンポーネント内の前記静的に付加された第２のプローブを前記アプリケーションから削除すること。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンピューティング環境におけるソフトウェアを監視する技術に関する。
【背景技術】
【０００２】
インターネットの存在が増長するにつれて、エクストラネット、イントラネットなどの他のコンピュータネットワークと同様に、電子商取引、教育、他の分野において多くの新しいアプリケーションをもたらした。組織は、ビジネスやその他目的を行うのにそのようなアプリケーションへの依存を深めており、期待通りの成果を確実に得るために相当の資源を投入している。このような状況のもと、様々なアプリケーションの管理技術が開発されている。
【０００３】
１つのアプローチとして、アプリケーション内で呼び出される個々のソフトウェアコンポーネントに関するアプリケーションの実行データを集めることにより、アプリケーションのインフラストラクチャを監視することが挙げられる。このアプローチでは、監視されるシステムに元々に存在するエージェントを用いることができる。例えば、ソフトウェアによる計測を用いることによって、呼び出される個々のコンポーネントを特定するため、あるいは、個々のコンポーネントの実行時間のような実行データを得るために、スレッドまたはプロセスがトレースされ得る。コンピュータプログラムが実行するステップの詳細な記録またはトレースを得ることをトレーシングという。トレースは、デバッグの補助として使用することができる。
【０００４】
しかし、どのコンポーネントを計測すべきかを決定することが問題となる。包括的過ぎるアプローチは、過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれる可能性がある。包括的でなさ過ぎるアプローチは、重要な情報を収集し損なう可能性がある。場合によっては、問題は、包括的過ぎや包括的でなさ過ぎということではなく、むしろ計測するのに適したコンポーネントの選択にある。例えば、必要な情報は、オーバーヘッドが小さいという結果をもたらす別のコンポーネントを計測することによって得られる。さらに、どのコンポーネントを計測するかを判定するには、時間がかかるとともにシステム管理者などのユーザを当惑させる。
【発明の開示】
【０００５】
本発明は、コンピューティング環境でソフトウェアを監視する技術を提供する。本明細書に開示した一実施形態では、複数のコンポーネントを有するアプリケーションを計測するための方法は、コンピュータに実装される次のステップを含む。ステップは、（ａ）どのコンポーネントの内部に複数のプローブを配置するかを判定するためにアプリケーションを自動的に解析すること；（ｂ）ステップは、判定されたコンポーネントに複数のプローブを自動的に付加することを含み；（ｃ）アプリケーションが実行している間に複数のプローブからデータを受信すること；（ｄ）データに基づいて第１のコンポーネント内の第１のプローブに対して１以上のメトリックを決定すること；（ｅ）第１のプローブの１以上のメトリックに基づいて、第１のプローブを修正するか否かを判定すること；および（ｆ）１以上のメトリックの決定、及び、付加的な複数のプローブに対する修正を行うか否かの判定を繰り返すこと、を含む。
【０００６】
本明細書に開示される技術は、コンピュータプログラムとしても実現され得ることにも留意されたい。本発明の詳しい説明は、次のセクションで明らかにされる。
【図面の簡単な説明】
【０００７】
【図１】管理されたアプリケーションを含むシステムを示す。
【図２】図１のネットワークにおけるコンピュータシステムを示す。
【図３】ネットワークサービスを監視する一実施形態のフローチャートを示す。
【図４】アプリケーションの２パス自動計測のための処理の一実施形態を示すフローチャートである。
【図５】プローブを修正するか否かを判定するためにプローブに関係付けられているメトリックを処理し、動的に適切な修正を行う処理の一実施形態を示すフローチャートである。
【図６】コールグラフの例である。
【図７】Java（登録商標）実行環境を示す。
【図８Ａ】自動計測のための処理フローの例としてJava（登録商標）ベースのものを示す。
【図８Ｂ】自動計測のための処理フローの例として.NETベースのものを示す。
【図９】ソフトウェアを動的に計測するための処理フローの例を示す。
【発明を実施するための形態】
【０００８】
本明細書では、アプリケーションの選択されたコンポーネントにインスツルメンテーション（例えば、プローブ）を自動的に挿入し、プローブを自動で動的に修正するための技術を開示する。例として、プローブは、アプリケーションから動的に削除されるか、またはアプリケーション内の別のコンポーネントに動的に移動される。本明細書に開示される実施形態は、アプリケーションを計測するためにユーザ（例えば、システム管理者）の介入を必要としない。最初に、アプリケーションなどのソフトウェアは、どのコンポーネントがプローブを有するべきかを判定するために、一連の経験則に基づいて自動的に解析される。プローブは、それらに基づいて静的（例えば、アプリケーションが実行されていない間）に挿入され得る。その後、アプリケーションは、コンポーネントがどの程度の時間、実行するかなどのパフォーマンスデータをプローブが収集するように実行される。パフォーマンスデータに基づいて、１以上のメトリックが各プローブに対して決定され得る。メトリックの例としては、コンポーネントの呼出し率、コンポーネントの実行に要する平均時間、コンポーネントに関係付けられたスレッドの同時実行性を含むが、それに限定されるわけではない。各プローブに対するメトリックは、プローブを修正するか否かを判定するために検査され得る。例えば、内部にプローブが存在するコンポーネントが、閾値よりも多く呼び出される場合、プローブはアプリケーションから削除されるか、またはコールグラフの上位のコンポーネントに移動され得る。したがって、一実施形態では、アプリケーションが実行されていないときにアプリケーションを解析しプローブを挿入することによって静的に実行される第１の計測パス、およびアプリケーションをシャットダウンする必要がないように動的に実行される第２の計測パスを含む。
【０００９】
図１は、異なったコンピュータシステムがマネージャにデータを提供するネットワークを示す。コンピュータシステムの例としては、アプリケーションサーバ１１０、または所望の機能を実現するためのコードを実行するのに適したプロセッサを有する他のタイプのコンピュータシステムを含む。アプリケーションサーバ１１０は、異なるアプリケーションを実行でき、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ１１０は、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、アプリケーションサーバ１１０は、マネージャコンピュータ１２０と通信する。マネージャコンピュータ１２０は、アプリケーションサーバ１１０からローカルまたはリモートであり得る。
【００１０】
例えば、Webベースの電子商取引アプリケーションなど企業アプリケーション（enterprise application）を実行している会社は、負荷分散のために１の場所で複数のアプリケーションサーバを使用する。例えば、ユーザのWebブラウザ１０２のようなユーザからのリクエストは、インターネットのようなネットワーク１０４を介して受信され、いずれかのアプリケーションサーバ１１０に送られる。Webブラウザ１０２は、図示していないインターネットサービスプロバイダーを介してネットワーククラウド１０４に、通常、アクセスする。
【００１１】
アプリケーションサーバ１１０は、管理されたアプリケーション１５１を含み、それは、エージェント１１２、例示のプローブ１５３および１５４を含む。プローブの数は任意である。アプリケーション１５１は、Java（登録商標）アプリケーションまたは異なるタイプのアプリケーションである。このように、アプリケーションサーバ１１０で実行されるエージェントソフトウェアは、エージェント１１２によって表され、ある可能なアプローチとして、アプリケーションサーバ１１０上で実行されている、管理されたアプリケーション１５１、ミドルウェアまたはその他のソフトウェアから、情報を収集する。例えば、アプリケーション１５１からの情報は、プローブ１５３および１５４を使用して得られる。実際には、多くのそのようなプローブは、アプリケーション１５１の様々なコンポーネントに関する情報を得るために使用することができる。複数の実施形態では、プローブは、計測を用いることによってアプリケーション１５１に付加され、その一例にはバイトコード計測がある。ただし、収集されたデータは、他の方法でも得ることができる。エージェント１１２は、監視対象となるコンピュータシステムに元来、存在しており、データの取得ポイントを提供する。エージェントは、マネージャ１２０と通信してデータを整理し最適化する。
【００１２】
一実施形態では、プローブ１５３，１５４および付加的なコードを付加するために、プローブビルダー（図１には図示されない）は、アプリケーション１５１のためにバイトコードを計測（例えば修正）する。プローブは、静的（例えば、アプリケーション１５１が実行されない間）に、または動的（例えば、アプリケーション１５１が実行される間）に付加される。プローブは、アプリケーションの業務ロジックを変更することなく、アプリケーション１５１に関する情報の特定部分を測定し得る。あるタイプのプローブは、コンポーネントが実行に費やす時間を測定する。時間には、プローブを有するコンポーネントによって呼び出されたコンポーネントが実行に費やす時間を含めることができるが、これは必須ではない。プローブは、コンポーネントのエントリポイントにおける始点およびコンポーネントの各出口における終点を有する。一実施形態では、始点はタイマーを起動し、終点はタイマーを止める。プローブは、タイミング情報に加えて他の情報を収集する。
【００１３】
プローブビルダは、アプリケーション１５１と同じマシン上に、または別のマシンン上にインストールされるエージェント１１２もまた付加する。一旦、プローブがアプリケーション１５１にインストールされたり、また監視機能が別に提供されたりすると、そのアプリケーションは管理されたアプリケーションと称される。バイトコードを計測することについて、さらなる情報として、Lewis K. Cirneによる“System For Modifying Object Oriented Code”と題する米国特許番号６，２６０，１８７や、２００１年２月２８日に出願された“Adding Functionality To Existing Code At Exits,”と題する米国特許出願番号０９／７９５，９０１があり、それぞれその全体が参照により本明細書に組み込まれる。
【００１４】
管理されたアプリケーション１５１を実行すると、プローブ１５３および１５４はエージェント１１２にデータを送信する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始および停止回数、またはトランザクション／実行フロー内の個々のコンポーネントの開始および停止回数、のようなパフォーマンスデータを示す。一実施形態では、プローブ１５３および１５４は、データを書いたりデータを変更したりそうでなければアプリケーションサーバの状態を変更する原因となったりする他のコードやオブジェクトに実装される。エージェント１１２は、その後、アプリケーション実行データと称されるデータを収集しサマライズしてマネージャ１２０に送信する。それに呼応して、マネージャ１２０は、要求された計算を実行し、アプリケーション実行データをユーザインタフェース１１２で使用可能にして、必要に応じて、後で解析するためにデータベース１１８へアプリケーション実行データを送信する。一実施形態では、マネージャ１２０は、アプリケーション１５１をどのように動的に計測するかを判定するためにアプリケーション実行データを使用する。プローブを用いてアプリケーションを監視することに関するさらなる情報として、２００４年４月２２日に公開された、Lewis K. Cirneによる“User Interface For Viewing Performance Information About Transactions”と題する米国特許出願公開番号２００４／００７５６９０があり、その内容は参照により本明細書に組み込まれる。
【００１５】
マネージャ１２０は、エージェントから受信したデータに基づいて情報を表示するため、例えばモニタのようなユーザインタフェース１２２と通信するワークステーションのような離れたコンピュータシステム上に提供される。マネージャ１２０は、またエージェントから受信したデータを格納するためにデータベース１１８へアクセスする。提示された例では、アプリケーションサーバは、ネットワーク１０４にアクセスすることなくマネージャ１２０と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ１２０は、ネットワーク１０４を介して複数のアプリケーションサーバのエージェントからのデータを受信することができる。例えば、大規模な組織は、セントラルネットワークオペレーションセンタを運用しており、そこでは、１以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払い処理をするサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ１２０およびユーザインタフェースディスプレィ１２２は、企業の本社の場所で提供される。必ずしも、Webベースまたは小売り若しくはその他の販売に関する必要はなく、他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータのシステムアレンジに加えて、１以上のエージェントによって単一のコンピュータシステムが同様に監視されることがある。
【００１６】
図２は、図１のネットワークで使用されるコンピュータシステムの一実施形態を示す。コンピュータシステム２００は、図１に関連して説明したように、Webブラウザ１０２、ホスト（例えばアプリケーションサーバ１１０）、マネージャ１２０および／またはユーザインタフェース１２２で使用されるシステムを簡略化して表したものである。コンピュータシステム２００は、ハードディスクまたはポータブルメディアのような記憶装置２１０、他のコンピュータと通信するためのネットワークインタフェース２２０、ソフトウェアの命令を実行するためのプロセッサ２３０、例えば、記憶装置２１０からロードされた後にソフトウェアの命令を格納するためのＲＡＭのような作業メモリ２４０およびユーザインタフェースディスプレィ２５０を含む。記憶装置２１０は、ここで説明した機能を提供するための方法を実行するのにプロセッサ２３０をプログラムするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ２５０は、１以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ２５０は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。
【００１７】
また、ここで説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、１以上のプロセッサをプログラムするために具現化されているプロセッサの読み取り可能に格納されたコードを有する、１以上のプロセッサにより読み取り可能な記憶装置を使用することができる。プロセッサにより読み取り可能な記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な記憶装置を含むことが可能である。例えば、コンピュータにより読み取り可能な記憶装置には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な記憶装置の例としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタルバーサタイルディスク（ＤＶＤ）、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタム集積回路、ゲートアレイ、ＦＰＧＡ、ＰＬＤや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、１以上の実施形態を実装するソフトウェア（記憶装置に格納されている）は、１以上のプロセッサをプログラムするために用いられる。１以上のプロセッサは、１以上のコンピュータにより読み取り可能な記憶装置、周辺機器および／または通信インタフェースと通信することができる。
【００１８】
いくつかの実施形態では、エージェント１１２は、アプリケーション１５１を監視してアプリケーション実行データをマネージャ１２０に転送し、そこでデータが解析されユーザに報告される。図３は、アプリケーション１５１を監視する処理の一実施形態のフローチャートを示している。当該処理は、図１のシステム１００の例において実行される。アプリケーション１５１は、ステップ３０２でエージェント１５２に監視される。監視は、アプリケーションサーバ１１０のどのトランザクションが処理されるのかを判定し、アプリケーションがクライアントの要求を処理するときにエージェント１１２に呼び出されている間の時間を判定するエージェント１１２を含む。ステップ３０２は、データを収集するために実行されるアプリケーション１５１内のプローブを含む。
【００１９】
アプリケーションの監視に基づくアプリケーション実行データは、ステップ３０４で生成される。生成されたアプリケーション実行データは、リクエストの処理に関わるアプリケーションのコンポーネント、リクエストの処理中に各コンポーネントが消費する時間幅、およびその他の情報を示す。アプリケーション実行データは、プローブの実行により結果として生じるデータに基づいてエージェント１１２により生成され、その後、エージェント１１２が、生成されたアプリケーション実行データをマネージャ１２０に転送する。一般的に、アプリケーション実行データには、平均的なコンポーネント（例えば、メソッド）の実行時間、毎秒または間隔ごとのコンポーネントの呼出し率、コンポーネントの呼出し回数、開始したが終了していない間隔ごとのコンポーネントの呼出し回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのコンポーネントの呼出し回数が特定の閾値を超えたコンポーネントの呼出し回数を示すストール状態のメトリックなどの情報が含まれる。また、アプリケーション実行データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定することができる。アプリケーション実行データは、管理されたアプリケーション１５１によって処理されている特定のトランザクションにリンクされることに留意されたい。
【００２０】
アプリケーション実行データは、データを集約したり、データを格納したり、インタフェースまたは他のユーザインタフェース１１２を介してオペレータにデータを提供するなど、ステップ３０６でマネージャ１２０により処理されて報告される。
【００２１】
図４は、アプリケーションの２パス自動計測のための処理４００の一実施形態を示すフローチャートである。１つのパスは、アプリケーション１５１を自動で静的に計測し、もう１つのパスは、アプリケーションを自動で動的に計測する。処理４００は、管理されたアプリケーション１５１に対して、自動的に計測する（例えば、プローブを付加する）ためにシステム１００で使用される。ステップ４０２では、アプリケーション１５１は、どのコンポーネント内にプローブを配置するかを判定するために自動的に解析される。この解析は、静的に行われる。したがって、アプリケーション１５１は、それが解析されるのに際して実行される必要はない。一実施形態において、一連の経験則がプローブを配置する場所（例えば、コンポーネント）を判定するために使用される。例えば、コンポーネントがループまたはロックを有する場合、コンポーネントがプローブを有するべきであるという判定が行われる。
【００２２】
ステップ４０４では、プローブは、ステップ４０２で判定された場所（例えば、コンポーネント）に自動的に挿入される。プローブは静的に挿入されるが、これはアプリケーション１５１が実行されていない間に、プローブが挿入されることを意味する。ステップ４０２および４０４のさらなる詳細は、図８Ａおよび８Ｂに関連して説明される。
【００２３】
ステップ４０６では、アプリケーション１５１は、プローブが挿入された状態で実行される。例えば、アプリケーション１５１は、Webブラウザ１０２からのリクエストを受信し、それらのリクエストに応じてトランザクションを処理する。リクエストの典型的な例には、Webサイトへのユーザログイン、Webサイトから製品を購入するためのリクエストおよびクレジットカード認証があるが、これらに限定されない。
【００２４】
ステップ４０８では、アプリケーション１５１が実行されている間に、プローブからデータが受信される。例えば、エージェント１１２は、プローブからデータを受信し、マネージャ１２０へデータを送信する。このデータには、コンポーネントが実行する時間の長さなどのパフォーマンスデータが含まれる。
【００２５】
ステップ４１０では、ステップ４０８で受信したデータに基づいて、１以上のメトリックが第１のプローブに対して判定される。説明のために、第１のプローブは、アプリケーション１５１内の第１のコンポーネント（例えばメソッド）に、元々配置されている。メトリックは、第１のプローブによって収集されたパフォーマンスデータに基づいており、また同様に他の複数のプローブによって収集されたパフォーマンスデータにも基づくものでもある。しかし、一般的に、メトリックは、第１のコンポーネントの実行に関与する。あるメトリックは、第１のコンポーネントが呼び出される頻度である。この情報は、アプリケーションからプローブを削除するか、またはアプリケーション内の別のコンポーネントにプローブを移動するか、のどちらを行うかを判定するのに役立つ。別のメトリックは、同時実行性に関与する。例えば、同時実行中のスレッドの数を１つのメトリックと決めることができる。換言すると、第１のコンポーネントに関係付けられている同時実行のスレッド数を決めることが可能となる。あるメトリックは、平均実行時間に関与することがある。例えば、第１のコンポーネントが実行するための平均時間を決めることができる。マネージャ１２０、エージェント１１２の１つまたは別のエンティティが、メトリックを決める。
【００２６】
ステップ４１２では、１以上のメトリックの解析に基づいて第１のプローブが修正されるべきか否かの判定が行われる。一例として、第１のコンポーネントの呼出し率が高すぎる場合には、第１のプローブは修正されるべきである。
【００２７】
第１のプローブが修正されるべきであると判定された場合、ステップ４１４において第１のプローブがいくつかの方法で修正される。修正の例としては、アプリケーション１５１から第１のプローブを削除し、アプリケーション１５１内の別の場所（例えば、コンポーネント）に第１のプローブを移動することを含むが、これに限定されない。異なるタイプまたはレベルの計測を提供することも可能で、例えば、コンポーネントの実行について多くの側面が追跡される高レベルの計測や、コンポーネントの実行についてほんの一部の側面しか追跡されない低レベルの計測などがある。したがって、その修正は、プローブがコンポーネント内でどのように実装されているかを修正するものとなり得る。一例として、プローブがプログラムループ内に命令を持つ場合、それらの命令は削除され得る。いくつかの実施例では、アプリケーション１５１が実行されているときには、修正が動的に行われる。したがって、アプリケーション１５１は、プローブを修正するためにシャットダウンされる必要はない。ステップ４１０〜４１４のさらなる詳細が図５の説明に関連して説明される。
【００２８】
第１のプローブが修正されているか否かに関わらず、ステップ４２０で、付加されたプローブが存在するか否かについての判定が行われることによって処理が継続する。もしそうであれば、処理４００は、次のプローブのために１以上のメトリックを判定するため、ステップ４１０に戻る。すべてのプローブが解析されるまで処理は継続する。あるプローブはアプリケーションから削除され、またあるプローブはアプリケーション内の他のコンポーネントへ移動されて、他のプローブは変更されないという結果となる。他の修正がプローブに行われ得る。
【００２９】
図５は、プローブに修正を行うか否かの判定をするため、プローブに関係付けられているメトリックを処理して、動的に適切な修正を行う処理５００の一実施形態を示すフローチャートである。処理５００は、処理４００のステップ４１０，４１２および４１４の一実施形態である。処理５００は、１つのプローブに対する異なるメトリックの解析を記述し、付加的なプローブのために繰り返される。ステップ５０２では、プローブが存在するコンポーネントの呼出し率は、高い呼出し率が存在するか否かを判定するために閾値と比較される。呼出し率は、プローブがある期間にわたって実行された回数を指す。これは、異なるサーバ上のコンポーネントの類似するインスタンスのためのものであることに留意されたい。例えば、システム１００では、異なるアプリケーションサーバ１１０は、管理されたアプリケーション１５１の別のインスタンスを実行する。したがって、解析されているプローブに対するコンポーネントは、管理されたアプリケーションの各インスタンスにおける別々のインスタンスを有する。このように、呼出し率は、コンポーネントのすべてのインスタンスに対する呼出し回数の合計である。しかし、この方法で呼び出しを測定することは必須ではない。例えば、呼出し率は、管理されたアプリケーションの単一のインスタンス、または管理されたアプリケーションのいずれかのサブセットのインスタンスに基づくものとなり得る。一実施形態では、呼出し率は、ある期間にわたるコンポーネントの呼び出しの合計をカウントすることによって定められる。
【００３０】
ステップ５０２で、この呼出し率は、所定の閾値と比較される。閾値は、固定値とすることも、変数とすることもできる。一実施形態では、ユーザ（例えば、システム管理者）は、閾値を設定することを許可されている。同じ閾値がすべてのプローブに使用される必要はない。前述のように、プローブは、アプリケーションの解析に基づいてアプリケーション１５１に元々挿入されていてもよい。閾値は、また、解析に基づいて設定されてもよい。例えば、どのコンポーネントの内部にプローブを配置するべきであるかを判定するのに使用される一連の経験則もまたプローブのための閾値を示すことがある。具体的な例として、プログラムループが存在したことを理由に挿入されるプローブは、ロックが存在したことを理由に挿入されるプローブとは異なる閾値を有する。
【００３１】
呼出し率が閾値よりも高い場合には、プローブは、アプリケーションから削除されるか、またはそのプローブが内部に存在するコンポーネントよりコールグラフにて上位のコンポーネントに移動される。前述したように、削除や移動は、アプリケーション１５１をシャットダウンすることなく動的に行われる。プローブの削除や移動は、アプリケーション１５１のインスタンスのすべてのまたはいくつかのサブセットに対してであることに留意されたい。一実施形態では、呼出し率が閾値よりも高い場合は、プローブは常に削除される。一実施形態では、可能であれば、呼出し率が閾値よりも高い場合は、プローブはコールグラフにおける上位のコンポーネントに常に移動される。コールグラフにおける上位のコンポーネントにプローブを移動することは、常に可能であるわけではないことに留意されたい。一実施形態では、プローブを削除または移動のいずれを行うかの判定が行われる。プローブを削除または移動のいずれを行うかについての判定は、様々な方法で行われる。一例として、決定は呼出し率そのものに基づいて行われる。例えば、呼出し率は、プローブを移動または削除のいずれを行うかの判定を行うために第２の閾値と比較され得る。他の例として、付加的な情報が検査され得る。削除または移動のいずれを行うかの判定は、プローブを現在含むコンポーネント、またはコールグラフ中の他のコンポーネント（例えば、プローブを移動するための候補のコンポーネント）のコードの解析に基づいて行われ得る。さらに別の例として、プローブを削除や移動するための判定は、他のメトリック（例えば、同時実行性、実行時間など）の解析に基づいて行われ得る。プローブを移動するために他のどんなコンポーネントが決定されるかについて、さらなる詳細が以下で説明される。
【００３２】
プローブが別のコンポーネントに移動される場合、これはプローブが厳密に同じ状態を維持していることを意味しないことに留意されたい。本明細書で使用する「プローブを別のコンポーネントに移動する」または類似のフレーズは、第１のコンポーネントにプローブが存在する、というよりも、プローブが他のコンポーネントに挿入される、ということを意味する。他のコンポーネントは、当然、異なる命令を持っていることから、新しいプローブはその新しいコンポーネントに合うように調整される。例えば、いくつかの実施形態では、プローブはコンポーネントのエントリポイントにおける開始タイマーおよび各出口における終了タイマーを有する。そのため、プローブを移動した後には終了タイマーの数が異なる場合がある。いくつかの実施形態で、プローブは、コンポーネント内のプログラムループの近くに配置された命令を有する。そのため、新しいコンポーネントが異なる数のループを有する場合には、プローブを実装するために使用される命令に影響を与えることがある。
【００３３】
プローブがアプリケーション１５１から削除されるか、または別のコンポーネントに移動される場合、処理５００は終了する。そうでなければ、処理５００は、そのプローブに対する次のメトリックを処理するため、ステップ５０６で継続する。ステップ５０６では、内部にプローブが存在するコンポーネントに関連する同時実行性が閾値と比較される。同時実行性は、内部にプローブが存在するコンポーネントに関連したスレッドにおいてインスタンスがいくつ同時に実行するかに対するものである。この同時実行性は、平均的な同時実行値であり得る。例えば、マネージャ１２０は、異なる時点での特定のスレッドに対する瞬間的な同時実行値を判定する。その後、平均的な同時実行性（例えば、平均値、中央値、最頻値）が判定される。別の例では、ある期間にわたるスレッドの最大同時実行値を判定する。別々の同時実行値は、各サーバ１１０に対して作られ、すべてのサーバ１００からのデータは単一の同時実行値などを判定するために用いられることに留意されたい。多数の他の方法が同時実行値を判定するために使用され得る。
【００３４】
ステップ５０６で、同時実行値が閾値と比較される。閾値は、固定値とすることも、変数とすることもできる。一実施形態では、ユーザ（例えば、システム管理者）は、閾値を設定することを許可されている。同じ閾値がすべてのプローブで使用される必要はない。閾値は、またアプリケーションの解析に基づいて設定されてよい（例えば、プローブが最初に挿入された場合）。
【００３５】
同時実行値が閾値よりも高い場合には、プローブは、ステップ５０８において、そのプローブが内部に存在するコンポーネントよりコールグラフにて下位のコンポーネントに移動され得る。前述したように、移動は、アプリケーション１５１をシャットダウンすることなく動的に行われる。プローブの移動は、アプリケーション１５１のインスタンスのすべてのまたはいくつかのサブセットに対してであることに留意されたい。例えば、コールグラフにおける下位のコンポーネントが存在しない場合には、アプリケーションからプローブを削除するか、またはその場所に保持するかのいずれかの決定が行われる。
【００３６】
ステップ５０８ではプローブが移動される場合、処理５００は終了する。そうでなければ、処理５００は、そのプローブの次のメトリックを処理するため、ステップ５１０で継続する。ステップ５１０では、内部にプローブが存在するコンポーネントに関連する実行時間が閾値と比較される。実行時間は、コンポーネントが実行する時間の長さである。これは、内部にプローブが存在するコンポーネントによって呼び出されるコンポーネントの実行時間を含んでもよいし、含まなくともよい。しかし、実行時間は、内部にプローブが存在するコンポーネントが実行するために必要とされるわけではない。別の例は、コンポーネントによって少なくとも一部が実行されるトランザクションのタイプに対する実行時間のものである。例えば、実行時間は、コンポーネントによって少なくとも一部が実行されるログイントランザクションまたは製品購入トランザクションに対するものである。実行時間は、平均的な（例えば、平均値、中央値、最頻値）実行時間であってよい。アプリケーション１５１の各インスタンスのために別々の実行時間が作られ、すべてのサーバ１００からのデータは単一の（平均）実行時間などを判定するために用いられてよいことに留意されたい。多数の他の方法が実行時間を判定するために使用され得る。
【００３７】
ステップ５１０では、実行時間が閾値と比較される。閾値は、固定値であってもよいし、変数であってもよい。一実施形態では、ユーザ（例えば、システム管理者）は、閾値を設定することを許可されている。同じ閾値がすべてのプローブで使用される必要はない。閾値は、またアプリケーションの解析に基づいて設定されてもよい（例えば、プローブが最初に挿入された場合）。
【００３８】
実行時間が閾値よりも長い場合には、プローブは、ステップ５１２において、そのプローブが内部に存在するコンポーネントよりコールグラフにおいて下位のコンポーネントに移動される。前述したように、移動は、アプリケーション１５１をシャットダウンすることなく動的に行われる。プローブの移動は、アプリケーション１５１の異なるインスタンスにおけるプローブのインスタンスのすべてのまたはいくつかのサブセットに対するものであることに留意されたい。例えば、コールグラフの下位にコンポーネントが存在しない場合には、アプリケーション１５１からプローブを削除するか、またはその場所に保持するかのいずれかの決定が行われる。
【００３９】
ステップ５１２で、プローブが別のコンポーネントに移動された場合、処理５００は終了する。そうでなければ、処理５００は、そのプローブの次のメトリックを処理するため、ステップ５１４で継続する。ステップ５１４では、コンポーネントの呼出し率は、呼出し率が低いか否かを判定するために閾値と比較される。要求はされていないものの、これは同じ呼出し率であることがステップ５０２で説明されている。このように、呼出し率は、コンポーネントがある期間にわたって実行した回数を示す。この呼出し率は、所定の閾値と比較される。この閾値は、ステップ５０２の閾値（高い閾値の可能性がある）とは異なっていてもよい。一方、低い閾値がステップ５１４で使用される。低い閾値は、固定値であってよいし、変数であってもよい。一実施形態では、ユーザ（例えば、システム管理者）は、低い閾値を設定することを許可されている。同じ低い閾値がすべてのプローブで使用される必要はない。
【００４０】
呼出し率が低い閾値よりも低い場合には、プローブは、アプリケーションから削除されるか、またはそのプローブが内部に存在するコンポーネントよりもコールグラフにて下位のコンポーネントに移動される。前述したように、削除や移動は、アプリケーション１５１をシャットダウンすることなく動的に行われる。プローブの削除や移動は、アプリケーション１５１のインスタンスのすべてのまたはいくつかのサブセットに対するものであることに留意されたい。一実施形態では、呼出し率が低い閾値よりも低い場合は、プローブは常に削除される。一実施形態では、可能であれば、呼出し率が低い閾値よりも低い場合、プローブはコールグラフにて下位のコンポーネントに常に移動される。コールグラフの下位のコンポーネントにプローブを移動することは、常に可能であるわけではないことに留意されたい。一実施形態では、プローブを削除または移動のいずれを行うかの判定が行われる。高い呼出し率について、上述したようなファクターが使用されてよい（高い呼び出し率および低い呼出し率に対して異なるファクターが使用され得ることに留意されたい）。
【００４１】
処理５００は、このプローブに対して処理を行うメトリックがそれ以上存在しないときには、終了する。メトリックは、異なる順序で処理されてよいことに留意されたい。一実施形態では、コールグラフにて上位のコンポーネントにプローブを移動することは、コールグラフにて下位のコンポーネントにプローブを移動することよりも好ましい。したがって、メトリックをテストする順番は、この優先度を重視して選択される。処理５００は、コールグラフの上位にプローブを移動させることを優先する一例である。
【００４２】
処理５００で記述したように、一旦、あるメトリックの解析がプローブを削除または移動するような判定の結果となった場合には、そのプローブは、さらなるメトリックを検討することなしに移動や削除される。しかし、複数のメトリックは、どんなアクションを採るかを判定する助けとなるために検査され得る。例えば、高い呼出し率が存在する場合、同時実行性または実行時間がプローブを削除または移動のいずれを行うかを判定するために検査される。
【００４３】
上述のように、処理５００は、他のプローブのために繰り返される。しかし、処理５００の厳密なシーケンスは、すべてのプローブに対して使用されることは必要とされない。例えば、いくつかのプローブのため、同時実行性をテストする以前に、実行時間がテストされ得る。異なるプローブに対してメトリック（例えば、ステップ５０２，５０６，５１０，５１４）が適用される順序を決定するために様々な技術が使用され得る。また、別のメトリックが別のプローブに適用され得ることにも留意されたい。例えば、実行時間メトリック（ステップ５１０）は、特定のプローブを解析するときには使用されずともよい。処理５００に明示的に記載されていない他のメトリックも使用される可能性がある。
【００４４】
図６は、処理５００の側面を説明するために使用されるコールグラフ６００の例示で、同様に他の技術も記載されている。コンポーネントは、図１のアプリケーションサーバ１１０のようなアプリケーションサーバ上で実行されるアプリケーション内に示されている。コンポーネントＡは、コールグラフの最上位のレベルにあり、コンポーネントＢを呼び出し、コンポーネントＢは次にコンポーネントＣを呼び出す。コンポーネントＣは、コンポーネントＤ、ＥおよびＦを呼び出す。コンポーネントＦは、コンポーネントＧを呼び出し、コンポーネントＧはコンポーネントＨを呼び出す。アプリケーションは、計測されるときに、通常、選択されたコンポーネントのみがアプリケーション１５１の解析に基づいて自動的に計測されることに留意されたい。したがって、多くのコンポーネントは、少なくとも当初はアプリケーション内で起動され／呼び出されるが、計測はされない。
【００４５】
コンポーネント指向のプログラムモジュールは、コンポーネントと呼ばれるブロックを組み立ててアプリケーションや他のプログラムをプログラマに組ませるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行することができる。さらに、コンポーネントは、再帰呼び出しによって自分自身を呼び出すことや他のコンポーネントを呼び出すことができ、これによって、コンポーネントのシーケンスがプログラム内に呼び出される。コンポーネントは、プログラムが実行されるときに、消費されるコンピュータシステムの資源、あるいは実行されたワークの例である。コンポーネント指向のプログラミングモデルの一例は、Ｊ２ＥＥであるが、Java（登録商標） Server Page、Enterprise Java（登録商標） Bean、サーブレットおよびJava（登録商標）Database Connectivityコンポーネントといったコンポーネントを用いることができる。しかしながら、その他のコンポーネント指向のプログラミングモデルもまた使用されており、例えば、マイクロソフト（登録商標）社の.NETコンポーネントが使用される。さらに、プログラミングモデルはオブジェクト指向である必要はない。１つのアプローチでは、コンポーネントはメソッドである。
【００４６】
コールグラフ６００の上位レベルに近いコンポーネント（例えばＢ）は、希にしか呼び出されないが、内部コールであるため実行に時間がかかる。コールグラフの下位レベルにあるコンポーネント（例えばＧ，Ｈ）は、頻繁に呼び出される。しかし、そのような下位レベルのコンポーネントが実行されるたびに、短い時間だけ実行され得る。場合によっては、本当に重要な情報は、コールグラフの上位レベルのコンポーネントにプローブを有することによって判定される。場合によっては、本当に重要な情報は、コールグラフの下位レベルのコンポーネントにプローブを有することによって判定される。
【００４７】
説明のために、コンポーネントＢは、内部にロックを有することからプローブ１で自動的に計測され、コンポーネントＥは、ループを有することからプローブ２で自動的に計測され、そして、コンポーネントＨは、ループを有することからプローブ３で自動的に計測される。これは、処理４００のステップ４０４で実行され得たものである。しかし、後述するように、プローブ１は、コールグラフの下位のコンポーネントＣに移動され、プローブ３は、コールグラフの上位のコンポーネントＧに移動される。これは、処理４００のステップ４１４（または処理５００のステップ５０４，５０８，５１２もしくは５１２のうちの１つ）で実行される。
【００４８】
プローブが、コールグラフ６００で上位のコンポーネントに存在する場合には、実行時間は長くなるが、呼出し率は低くなる。この場合、プローブからは十分に情報を得られない。１つの選択肢は、より注目すべき情報を判定するためにコールグラフの下位のコンポーネントにプローブを移動することである。コンポーネントＢのプローブ１が例示のために使用される。実行時に、コンポーネントＢのプローブ１は、呼び出されたコンポーネントＣでどの程度の時間が使われたかに関する情報を収集する。例えば、コンポーネントＣがコンポーネントＢから呼び出された時点でタイマーが存在する。ただし、コンポーネントＢのプローブは、例えば、コンポーネントＤ〜Ｈのような低位のレベルで、どの程度の時間が使われたかを判定できないことがある。この場合、プローブ１をコールグラフの下位のコンポーネントに移動することは、より多くの情報を得るのに役立つ。
【００４９】
処理５００のステップ５１０〜５１２で述べたように、コンポーネントが長い実行時間を有する場合、コンポーネントためのプローブは、コールグラフ６００の下位のコンポーネントに移動される。一例として、コンポーネントＢに自動的に挿入されたプローブ１は、コールグラフ６００内のそれより下位のすべてのコンポーネントが呼び出されていることにより、長い実行時間を有する。したがって、プローブ１は、コンポーネントＣのような下位レベルに、またはコールグラフ６００のさらに下位レベルにある異なるコンポーネントに移動される。コンポーネントＢの呼出し率は、ステップ５０２がプローブ１を削除したりコールグラフ６００の上位に移動させたりすることが起こらないような高い閾値以下でなければならないことに留意されたい（処理５００のステップ５０２〜５０４に示されているように）。
【００５０】
コンポーネントＢのプローブ１は、長い実行時間以外の理由でコールグラフ６００の下位に移動されることがある。例えば、コンポーネントＢのプローブ１は、低い閾値よりも呼出し率が小さいことが原因で移動されることがある。処理５００のステップ５１４〜５１６に示されるように、コンポーネントが低い呼出し率を有する場合には、そのプローブはコールグラフ６００の下位のコンポーネントに移動される。このように、コンポーネントＢに自動的に挿入されるプローブ１は、例えばコンポーネントＣのような下位レベルに移動される。
【００５１】
プローブをコールグラフ６００の下位のコンポーネントに移動する場合、それはコールグラフ６００の下位の任意のコンポーネントに移動され得ることに留意されたい。一実施形態において、プローブは一レベル下位に移動される。アプリケーション１５１の再実行後、プローブは再び下位に移動されることがある。しかし、プローブはさらに下位に移動され得る。例えば、プローブ１は、コンポーネントＢからコンポーネントＦまたはＧへと下げられ得る。
【００５２】
一方、プローブがコールグラフ６００の下位レベルのコンポーネントに存在する場合には、実行時間は短いかもしれないが、呼出し率は高くなる。したがって、１つの選択肢は、コールグラフ６００の上位のコンポーネントにプローブを移動することである。これにより、類似の情報を収集し得るが、低いオーバーヘッドで行われ得る。コンポーネントＨのプローブ３が例として使用される。説明のために、平均して、コンポーネントＨが呼び出される場合、ループは１，０００回実行される。したがって、この例では、プローブ３の少なくともいくつかの命令は、コンポーネントＨ内に位置しているために、１，０００回実行され得る。もちろん、それは、プローブの命令がループの各実行により呼び出されるようにコンポーネントＨ内の位置にプローブ３を配置させることを要件とするものではないが、この例は１つの可能性である。このように、説明のために、処理５００のステップ５０２で説明したように、コンポーネントＨは高い呼出し率を有する。
【００５３】
実行時に、コンポーネントＨのプローブ３は、呼び出されたコンポーネントＨでどの程度の時間が使われたかに関する情報を収集する。コンポーネントＨのループは１，０００回実行することから、これは有用な情報かもしれないが、プローブ３（またはその命令の一部）の実行に関連して、オーバーヘッドが問題となる可能性がある。それは、コンポーネントＨのループ内のプローブ３に関係付けられた命令の実行がコンポーネントＨの実行時間を著しく増加させるということである。
【００５４】
したがって、プローブ３は、コールグラフ６００の上位のコンポーネントＧに移動し得る。コンポーネントＧが呼び出される場合には、プローブ３は、コンポーネントＨが呼び出されるときほど過度にはオーバーヘッドに寄与しない。しかし、有用な情報はまだ得られる。例えば、コンポーネントＧがコンポーネントＨを呼び出すことから、プローブ３はコンポーネントＨの実行にかかる時間を判定することがさらに可能である。また、プローブ３は、コンポーネントＨがどの程度の頻度で実行されるかについても、まだ判定することが可能である。
【００５５】
次に、コンポーネントＥのプローブ２について説明する。説明のために、コンポーネントＥのループは、コンポーネントＥの各呼び出しに対して平均２回のみ実行されるとする。したがって、この例では、プローブ２はループ内に命令を有するとしても、オーバーヘッドには過度に寄与しない。コンポーネントＥは、他にどんなコンポーネントも呼び出さないことから、説明のために、長い実行時間を持たない。また、説明のために、コンポーネントＥの呼出し率は、高い閾値よりも大きくなく、また、低い閾値よりも小さくもないとする。さらに、説明のために、コンポーネントＥのための高い同時実行性は存在しないとする。したがって、処理５００のどのメトリックも、プローブ２が削除または移動される必要があることを示していない。そのため、プローブ２は、コンポーネントＥに存在したままである。
【００５６】
しかし、別の例として、コンポーネントＥの呼出し率が低い場合、プローブ２はアプリケーション１５１から削除され得る（図６に示されている）。この例では、コンポーネントＥよりもコールグラフ６００の下位に別のコンポーネントが存在しないことに留意されたい。そのため、プローブを削除するか、またはコールグラフ６００の下位のコンポーネントに移動するか否かの判定は、コールグラフ６００の下位にコンポーネントが存在するか否かに基づいて行われる。
【００５７】
図７は、Java（登録商標）実行環境を示している。複数の実施形態は、Java（登録商標）実行環境で操作される。Java（登録商標）実行環境７００は、ハードウェア７１６の上に構築されているオペレーティングシステム７１４上に構築されている。Java（登録商標）実行環境は、Java（登録商標） ＡＰＩクラス７０２とＪＶＭ７０４を含むいくつかの仮想部品を含む。ＪＶＭは、レジスタ７０６、オペランドスタック７０８、ヒープ７１０およびメソッド領域７１２を含む。ＪＶＭは、命令のシーケンスとして一連のバイトコードを処理する。ＪＶＭの命令は、操作される上で値が具体化するゼロまたはそれ以上のオペランドを伴う、実行すべき操作を特定するオペコードから構成される。オペランドスタック、ヒープおよびメソッド領域は、アドレス指定可能なメモリ内に存在する。アドレスのサイズは３２ビットで、各メモリロケーションは１バイトを含み、各レジスタは３２ビットアドレスを格納する。メソッド領域は、バイトコードを含んでバイトバウンダリに配置され、オペランドスタックとヒープは、ワード（３２ビット）バウンダリに配置される。
【００５８】
レジスタは、実行すべき命令をメモリ内で追跡するプログラムカウンタ（ＰＣ）を含む。プログラムカウンタは、実行すべき次のバイトコードを特定する。フレームレジスタは、オペランドスタック内のカレントメソッドの実行環境に対するポインタを含む。オペランドトップ（optop）レジスタは、オペランドスタックの先頭へのポインタを含み、算術式を評価するのに用いられる。変数（vars）レジスタは、局所変数へのポインタを含む。
【００５９】
オペランドスタックは、メソッドと操作へパラメータを供給し、それらから結果を得る。すべてのバイトコード命令は、スタックからオペランドを取得してそれらの上で操作して、スタックに結果を戻す。オペランドスタックは、実行中のメソッドのスタックフレームを含む。スタックフレームは、例えば、局所変数、計算の中間結果など、メソッドの特定呼び出しのために、状態を保持する。具体的には、各ＪＶＭスレッドは、同時にスレッドとして生成された、専用のＪＶＭスタックを持っている。ＪＶＭスタックは、フレームを格納し、局所変数と部分的な結果を保持し、メソッド呼び出しと戻り値の役割を果たす。このようにフレームは、動的リンクを実行するため、メソッドのための値を戻したり、例外処理をディスパッチするために使用されるのと同様に、データおよび部分的な結果を格納するため使用される。新しいフレームは、メソッドが呼び出されるたびに生成される。フレームは、メソッドの呼び出しが完了すると、その完了が正常か中途（受け取れない例外処理を投げ出した）かにかかわらず、破棄される。フレームは、フレームを生成するスレッドのＪＶＭスタックから割り当てられる。各フレームは、局所変数の独自の配列、独自のオペランドスタック、および、カレントメソッドのクラスの実行時定数プールへのリファレンスを持っている。
【００６０】
ヒープまたはメモリ割り当てプールは、ガーベジコレクトされる。ヒープは、すべてのクラスのインスタンスに対するメモリと配列がそこから割り当てられる実行データ領域である。ヒープは、起動した仮想マシン上に生成され、オブジェクトのためのヒープ記憶域は、ガーベジコレクタとして知られている自動記憶装置管理システムにより再生される。具体的には、Java（登録商標）実行環境で実行中の各プログラムが、それに割り当てられたガーベジコレクトされたヒープを持っている。また、ヒープ内の各クラスは、それに関連付けられた定数プールを持っている。定数は、変更することはないことから、通常、コンパイル時に生成される。定数プール内のアイテムは、特定のクラス内の任意のメソッドで使用されるすべての名前をエンコードする。クラスは、いくつの定数が存在するかのカウントを含むとともに、クラスの記述内における定数の特定リストの始まりを特定するオフセットを含む。
【００６１】
メソッド領域は、コンパイルされたコード内でメソッドと関連付けられたバイトコード命令、および、動的リンクのために実行環境が必要とするシンボルテーブルを格納する。メソッドと関連付けられる必要があり得るデバッグや付加情報も、またこの領域内に格納される。プログラムカウンタは、常にメソッド領域の数バイトのアドレスを指し示し、例えば、メソッド領域の数バイトのアドレスが入る。プログラムカウンタは、スレッドの実行を追跡するために使用される。バイトコード命令が実行された後、プログラムカウンタは、次に実行する命令のアドレスを含む。
【００６２】
メソッド領域は、すべてのＪＶＭスレッド間で共有され、例えば、実行時定数プール、フィールドおよびメソッドデータならびにメソッドやコンストラクタのためのコード、のようなクラスごとの構造などを格納しており、クラスおよびインスタンスの初期化やインタフェースタイプの初期化で使用される特別のメソッドを含んでいる。メソッド領域は、起動した仮想マシン上に生成される。実行時定数プールは、クラスファイル内の定数プールテーブルのクラスごとの、またはインタフェースごとの実行時表現である。これには、コンパイル時に知られている数値リテラルから実行時に解決されるべきメソッドやフィールドリファレンスに至るまでの範囲で、定数のいくつかの種類が含まれる。各実行時定数プールは、ＪＶＭのメソッド領域から割り当てられる。クラスまたはインタフェースの実行時定数プールは、ＪＶＭによってクラスまたはインタフェースが生成されるときに構築される。
【００６３】
図８Ａは、静的計測のための処理フローの例として、Java（登録商標）ベースのものを示す。静的計測は、それが実行されていない場合、アプリケーションの解析に基づくものである。処理は、ある可能なアプローチでは、図１のエージェント１１２のようなエージェントによって実装される。処理４００のステップ４０２〜４０４で説明されているように、図８Ａの処理は、アプリケーション１５１を解析し、プローブを挿入するための１つの技術である。計測への１つのアプローチは、メソッドなどのどのコンポーネントが計測されるべきかを判定する静的なルール８０５（または経験則）を提供することを含む。ルール８０５は、コンポーネントがアプリケーションにロードされる時にアクセスされる。
【００６４】
複数の実施形態では、少なくともルール８０５のいくつかは、ループ命令文（例えば、while…do, do…while, for…, など）を探す。この理由の１つは、いくつかのコード（例えば、Java（登録商標））を持つ変数のソースがループ命令文であるということである。さらに、ループは、可変性をアプリケーションに導入する外部アプリケーションファクターのための有用なプロキシである（例えば、データセットサイズ）。したがって、ループを有するメソッドは、監視する計測ポイントの有用なセットである。一実施形態では、バイトコード（例えば、Java（登録商標）バイトコード）は、メソッド内で潜在的なループを表すネガティブオフセットを持つジャンプ命令を見つけるべくジャンプ命令（例えば、goto, goto_w, jsr, jsr_w, ret）を識別するために構文解析される。ジャンプ命令にネガティブオフセットが含まれている場合には、メソッドに計測ポイント（例えば、プローブ）が挿入される。例えば、始点および１以上の終点を有するプローブが挿入される。一具体例として、始点はメソッドの入口に挿入され、終点はメソッドのすべての出口に挿入される。
【００６５】
そのようなアプローチでは、クラスローダ８２０は、トランスフォーマ８１５にアプリケーションのバイトコードの生のデータバイトを提供するのに使用され、例えば、生のデータバイトをクラスに変換する。例えば、Java（登録商標）では、これは、クラスのロードに関与するClassLoaderオブジェクトのdefineClassメソッドを使用することを含み得る。ClassLoaderクラスは抽象クラスである。クラスの名前を付与すると、クラスローダは、クラスの定義を構成するデータを検索したり生成したりしようとする。代表的な手順は、名前をファイル名に変換し、ファイルシステムからその名前の「クラスファイル」を読み込むことである。defineClassメソッドは、バイトの配列をClassクラスのインスタンスにコンバートする。Classクラスのインスタンスは、Java（登録商標）アプリケーションを実行中にクラスおよびインタフェースを表す。トランスフォーマ８１５は、したがって、このようにクラスを変換することによって、計測を付加するためにバイトコードを変換することができるソフトウェアである。１つのアプローチでは、トランスフォーマ８１５の最小処理単位をクラスファイルおよびそのバイト配列とすることができる。
【００６６】
判断ブロック８１０において、アプリケーションのバイトコードがルール（指令）８０５に一致する場合、トランスフォーマ８１５はトレーサバイトコードの形式でプローブを付加する。判断ブロック８１０においてアプリケーションのバイトコードがルール８０５に一致しない場合、トランスフォーマ８１５はバイトコードに計測を付加しない。トランスフォーマ８１５と判断ブロック８１０は、プローブビルダ８２５の一部と考えることができる。
【００６７】
この実装では、ルール８０５は、計測すべき管理されたアプリケーションの一部を特定する代表的な静的ルールの規定である。ルールは、最初に仮想マシン内でクラスが定義される場合に実装される。クラスは、一度だけ定義されれば、複数回ロードすることができる。例えば、同じクラスをロードする複数のクラスローダが存在し得る。また、クラスなどのコンポーネントは、特定の方法で名前が付けられるかどうか、特定のインタフェースを実装するかどうか、特定のサブクラスまたはスーパークラスを拡張するかどうか、などに基づいて、計測され得る。そのようなコンポーネントは、有用なそうでなければ興味深いパフォーマンスデータを提供する可能性があると考えられることから、計測すべきものとして選択される。
【００６８】
例えば、ルールは、少なくともいくつかのサーブレットは興味深いデータを提供し得ると考えられているので、すべてのサーブレットを計測すべきであることを示すことがある。この場合、ルール８０５が、Java（登録商標）クラスのHttpServletのサブクラスであるすべてのコンポーネントを計測すべきであることを示す場合がある。HttpServletは、すべてのサーブレットが依存する抽象クラスである。しかしながら、すべてのコンポーネントが計測されるわけではなく、包括的過ぎる計測は過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれる可能性があるという不安がある。その一方で、包括的でなさ過ぎる計測は、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。
【００６９】
図８Ｂは、静的計測のための処理フローの例として.NETベースのものを示す。図８Ｂの処理は、処理４００のステップ４０２〜４０４で説明したように、アプリケーション１５１を解析し、プローブを挿入するための１つの技術である。この可能性のあるアプローチでは、管理されたアプリケーションのコンポーネントは、マイクロソフト社の「.NET」フレームワークにより提供されている。Java（登録商標）とは異なり.NETフレームワークはクラスローダを使用しない。代わりに、.NETは、フレームワーク用に特別に書かれたプログラムの実行を管理する仮想マシンを含む。.NETフレームワークの実行環境は、共通言語ランタイム（ＣＬＲ）として知られている。ＣＬＲは、プログラムを実行する特定のＣＰＵの能力をプログラマが考慮する必要がないように、アプリケーションの仮想マシンの外観を呈している。ＣＬＲは、セキュリティ、メモリ管理および例外処理などの他のサービスの提供もしている。予めコード化されたソリューションのクラスライブラリとＣＬＲは、共に.NETフレームワークを構成している。
【００７０】
また、ＣＬＲは、アプリケーションの開発および実行のための言語に中立的なプラットフォームを提供する共通言語基盤（ＣＬＩ）の実装であり、例外処理、ガーベジコレクション、セキュリティおよび相互運用のための各機能を果たしている。ＣＬＩは、コアクラスライブラリィ、コモンタイプシステムおよび共通中間言語（ＣＩＬ）を含む。Java（登録商標）バイトコードと同様に、ＣＩＬは中間バイトコードの他の例である。Java（登録商標）と.NETは、実装の一例にすぎず、他の実装もまた可能である。
【００７１】
ここでは、ある可能なアプローチとして、処理がエージェント１１２によって実装されることがある。１つの可能性のある状況では、.NETフレームワークは名前によってクラスを参照し、ＣＬＲ８７０がクラスを発見し、トランスフォーマ８６５（もしあれば）にそれを示し、その結果ＣＩＬを使用する、という処理が行われる。特に、判断ブロック８６０でクラスがルール８５５に一致する場合、計測が付加される。判断ブロック８６０でクラスがルール８５５に一致しない場合は、計測は付加されない。トランスフォーマ８６５と判断ブロック８６０は、プローブビルダ８７５の一部であると考えることができる。
【００７２】
図９は、動的にソフトウェアを計測するための処理フローの例を示す。処理フローは、アプリケーションからプローブを削除するため、または他の場所（例えば、コンポーネント）にプローブを移動するために使用され得る。したがって、処理は、処理４００のステップ４１４または処理５００のステップ５０４，５０８，５１２もしくは５１６を実装するときに使用され得る。削除されたプローブを有するコンポーネントのリスト９０８、および付加されたプローブを有するコンポーネントのリスト９０８がある。プローブが移動される場合、あるコンポーネントは削除されたプローブを有し、別のコンポーネントは付加されたプローブを有する。したがって、リスト９０６は、プローブが移動された先のコンポーネントを含む。リスト９０８は、プローブがそこから移動されたコンポーネント、およびプローブがアプリケーションから削除されたコンポーネントを含む。
【００７３】
リスト９０８，９１０はクラスローダ９０２に提供され、クラスローダ９０２は、計測されたバイトコードを提供するためにトランスフォーマ／プローブビルダ９００を使用することによって、バイトコードをロードする。バイトコードは、マシンコードに任意にコンパイルされ得る。例えば、defineClassメソッドは、バイトの配列をClassクラスのインスタンスにコンバートする。
【００７４】
したがって、コンポーネントは、例えば、ある時点において計測を有しない状態から、別の時点において計測を有する状態へ移行するように、再定義することが可能である。また、コンポーネントは、例えば、ある時点において計測を有する状態から、別の時点において計測を有しない状態へ移行するように、再定義することも可能である。
【００７５】
また、計測の異なる種類またはレベル、例えば、コンポーネントの実行について多くの側面が追跡される高いレベルの計測や、コンポーネントの実行についてほんの一部の側面しか追跡されない低いレベルの計測、を提供することも可能である。コンポーネントを再定義することは、このように異なるタイプの計測への移行を含むことがある。
【００７６】
計測は、多くの種類のパフォーマンスメトリクス／データを生成することができ、それらには、コンポーネントの平均実行または応答時間、毎秒または間隔ごとの呼出し率、呼出し回数、開始したが終了していない間隔ごとの呼び出しの回数を示す同時実行のメトリック、呼び出しを開始した間隔ごとのメソッド呼び出しの回数が特定の閾値を超えた呼出し回数を示すストール状態のメトリックが含まれる。また、データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定する。データは、計測されたコンポーネントによってどのコンポーネントが呼ばれたか、または計測されたコンポーネントをどれが呼ぶか、を特定することもできる。例えば、コントローラのアーキテクチャにおいては、コンポーネントを制御するコントローラコンポーネント内の制御フローは、次に実行されて、どの程度の頻度で実行され、どのように実行されるかを知っている。
【００７７】
１つのアプローチにおいては、削除されたプローブを有するコンポーネントのリスト９０８、および付加されたプローブを有するコンポーネントのリスト９０６は、次回システム１００が起動して、同じコンポーネントが計測される／計測されないように持続され得る。
換言すると、再起動しなければ静的解析（図４のステップ４０２〜４０４を参照）によって判定されるであろうコンポーネントは、システムが再起動したとしても、そのすべてが再度静的に計測されることは要求されていない。
【００７８】
コンポーネントは、コンポーネントがアプリケーションの実行時に既に組み込まれているか否かに応じて異なる方法で再定義されることができる。コンポーネントがアプリケーションにまだ組み込まれていない場合には、１つの可能な実装として、クラスローダ９０２によってＪＶＭなどにロードされることで、正常に組み込まれ得る。例えば、.NETフレームワークを使用するような他の実装においては、クラスローダは使用されない。
【００７９】
コンポーネントがロードされると、命令がある場合には、例えば、付加されたプローブを有するコンポーネント（９０６）、および、削除されたプローブを有するコンポーネント（９０８）、に応じて、トランスフォーマ／プローブビルダ９００がコンポーネントを計測する。アプリケーションに既に組み込まれているが未計測のコンポーネントは、計測を含んでアプリケーションに再組み込みされ得る。例えば、コンポーネントは、アプリケーションから削除することができるとともに、仮想マシンを再起動することなく実行中にリロードすることが可能である。これを達成するためには、Java（登録商標）のredefineClassコマンドがコンポーネントによってクラスローダ９０２に提供される。Java（登録商標）開発キット（ＪＤＫ）バージョン１．５またはそれ以降のバージョンがこのコマンドを使用する再定義機能を備えている。このコマンドは、提供されたクラスファイルを使用して提供されたクラスのセットを再定義する。それは、２つ以上のクラスを同時にインターロック変更させるためにセットで動作する。また、再定義されたメソッドがアクティブなスタックフレームを有している場合には、これらのアクティブなフレームが元のメソッドのバイトコードの実行を続行し、再定義されたメソッドが新しい呼び出しで使用される。
【００８０】
コンポーネントを例えばクラスのように再定義することは、クラスだけであるが、仮想マシンを再起動することに類似している。クラスが再定義される場合、もしクラスが既存のメソッドスタックに存在するのであれば、クラスはそこにとどまる。しかし、すべての新しいメソッドが呼び出される場合には、新しいクラスが使用される。つまり、一旦、再定義されると、新しいバージョンがピックアップされる。
【００８１】
トランスフォーマ／プローブビルダ９００は、再定義されたコンポーネントを受信する場合、もしそうするように命令されていたのであれば、コンポーネントを計測する。上述のように、トランスフォーマ／プローブビルダ９００は、コンポーネントの計測を削除することも可能である。トランスフォーマ／プローブビルダ９００は、またコンポーネントに特定の種類の計測を付加することも可能である。
【００８２】
計測の付加および削除は実行時に動的に行われるので、バイトコードを実行している仮想マシンはダウンさせる必要はなく、計測されたコンポーネントからのデータは直ちにアクセスされ得る（計測を追加する場合）。
【００８３】
本明細書に開示される一実施形態は、複数のコンポーネントを有するアプリケーションを計測するためのコンピュータに実装される方法を含む。この方法は、どのコンポーネントの内部に複数のプローブを配置するかを判定するためにアプリケーションを自動的に解析すること；判定されたコンポーネントに自動的に複数のプローブを付加すること；アプリケーションが実行している間に複数のプローブからデータを受信すること；データに基づいて第１のコンポーネント内の第１のプローブに対して１以上のメトリックを決定すること；第１のプローブの１以上のメトリックに基づいて、第１のプローブを修正するか否かを判定すること；１以上のメトリックの決定と付加的なプローブに対する修正を行うか否かの判定とを繰り返す、マシンに実装されたステップを含む。
【００８４】
本明細書に開示される一実施形態では、アプリケーションを計測するための方法を実行する、少なくとも１つのプロセッサをプログラムするためのコンピュータで読み込み可能な格納された命令を有する、コンピュータで読み取り可能な記憶装置を含む。この方法は：複数のプローブを配置するためのアプリケーション内の場所を判定するためアプリケーションを静的に解析すること；アプリケーションの判定された場所にプローブを静的に付加すること；アプリケーションが実行している間にプローブ複数のによってデータを収集すること；データに基づいて第１のプローブの１以上のメトリックを判定すること；第１のプローブの１以上のメトリックに基づいて、アプリケーションから第１のプローブを削除するか否かを判定すること；第１のプローブの１以上のメトリックに基づいて、第１のプローブをアプリケーション内の別の場所に移動するか否かを判定すること；１以上のメトリックの判定、アプリケーションからプローブを削除するか否かの判定および付加的なプローブのためにプローブを別の場所に移動するか否かの判定、を繰り返すること、を含む。
【００８５】
本明細書に開示される一実施形態は、１以上のプロセッサを有するシステム；および１以上のプロセッサに結合されているコンピュータで読み取り可能は記憶装置を含む。コンピュータで読み取り可能な記憶装置は、コンピュータで読み取り可能な格納された命令を有し、１以上のプロセッサ上で実行すると、この１以上のプロセッサに複数のコンポーネントを有するアプリケーションを計測させる。１以上のプロセッサは：ａ）どのコンポーネントの内部に複数のプローブを静的に配置するかを判定するためにアプリケーションを自動的に解析し；ｂ）アプリケーションが実行していない間に、判定されたコンポーネントのアプリケーションに複数のプローブを自動的に付加し；ｃ）アプリケーションが実行されている間に複数のプローブからデータを受信し；ｄ）データに基づいて、第１のコンポーネント内の第１のプローブに対して１以上のメトリックを判定し；ｅ）第１のプローブの１以上のメトリックに基づいて、アプリケーション内の別のコンポーネントに第１のプローブを移動するか否かを判定し；ｆ）前記ｅ）の判定がそのように示す場合、アプリケーションが実行している間にアプリケーション内の別のコンポーネントに第１のプローブを移動し；ｇ）第１のプローブの１以上のメトリックに基づいて、アプリケーションから第１のプローブを削除するか否かを判定し；ｈ）前記ｇ）の判定がそのように示す場合、アプリケーションが実行している間にアプリケーションから第１のプローブを削除し；およびｉ）付加的なプローブのために前記ｄ）から前記ｈ）を繰り返す。
【００８６】
コンピューティング環境でソフトウェアを監視する技術を説明した。本記載は、アプリケーションを計測するための２パス技術を提供する。１つのパスは、アプリケーションが実行されていない間にアプリケーションを解析しプローブを挿入することによって静的に実行される。もう１つのパスは、アプリケーションがプローブのメトリックを導出するために実行している間、プローブにより収集されたデータを解析することによって動的に実行される。各プローブの１以上のメトリックは、プローブを動的に修正するか否かを判定するために解析され得る。プローブは動的に修正されるので、アプリケーションはシャットダウンされる必要はない。プローブを動的に修正することは、例えば、プローブをアプリケーションから削除すること、またはプローブをアプリケーション内の別のコンポーネント（例えば、メソッド）に移動することであり得る。例えば、プローブは、プローブが現在、存在しているコンポーネントよりもコールグラフ上で上位または下位のいずれかのコンポーネントに移動され得る。
【００８７】
以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。
【図１】
0005705084.tif 000002
【図２】
0005705084.tif 000003
【図３】
0005705084.tif 000004
【図４】
0005705084.tif 000005
【図５】
0005705084.tif 000006
【図６】
0005705084.tif 000007
【図７】
0005705084.tif 000008
【図８Ａ】
0005705084.tif 000009
【図８Ｂ】
0005705084.tif 000010
【図９】
0005705084.tif 000011