"複数のコンポーネントを有するアプリケーションを計測する方法であり、コンピュータに実装される以下のステップ:どのコンポーネントの内部にプローブを配置するかを判定するためにアプリケーションを自動的に解析すること402;判定されたコンポーネントにプローブを自動的に付加すること404;アプリケーションが実行されている間にプローブからデータを受信すること408;前記データに基づいて最初のコンポーネント内の最初のプローブに対する1以上のメトリックを決定すること410;前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定すること414;および1以上のメトリックの決定、及び、付加的なプローブに対する修正を行うか否かの判定を繰り返すこと420、を備える方法。請求項1の方法であり、前記最初のプローブを修正するか否かの判定に基づいて、アプリケーションが実行されている間に前記最初のプローブを修正することをさらに含む。請求項1または2の方法であり、前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定することは、前記最初のコンポーネント内に前記最初のプローブをとどめるか、前記アプリケーションから前記最初のプローブを削除するか、あるいは、前記最初のプローブを前記アプリケーション内の別のコンポーネントへ移動するか、を決定することを含む。請求項1から3のいずれかの方法であり、前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定することは、前記最初のコンポーネントの呼出し率が閾値よりも大きいか否かを判定すること;および前記呼出し率が閾値よりも大きいとの判定に応答して以下のいずれか:前記アプリケーションから前記最初のプローブを削除すること;前記アプリケーション内の別のコンポーネントへ前記最初のプローブを移動すること;または前記最初のコンポーネントよりコールグラフの上位のコンポーネントに前記最初のプローブを移動すること;を実行すること、を含む。請求項1から3のいずれか1項の方法であり、前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定することは、前記最初のコンポーネントの呼出し率が閾値よりも小さいか否かを判定すること;および前記呼出し率が閾値より小さいとの判定に応答して以下のいずれか:前記アプリケーションから前記最初のプローブを削除すること;前記アプリケーション内の別のコンポーネントへ前記最初のプローブを移動すること;または前記最初のコンポーネントよりコールグラフの下位のコンポーネントに前記最初のプローブを移動すること;を実行すること、を含む。請求項1から3のいずれか1項の方法であり、前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定することは、前記最初のコンポーネントに関連したスレッドの同時実行性が閾値よりも大きいか否かを判定すること;および前記最初のコンポーネントに関連したスレッドの同時実行性が閾値よりも大きい場合、前記最初のコンポーネントよりコールグラフの下位のコンポーネントへ前記最初のプローブを移動することを決定すること、を含む。請求項1から3のいずれか1項の方法であり、前記最初のプローブに対する前記1以上のメトリックに基づいて前記最初のプローブを修正するか否かを判定することは、前記最初のコンポーネントの実行時間が閾値よりも大きいか否かを判定すること;および前記最初のコンポーネントの実行時間が閾値よりも大きい場合、前記最初のコンポーネントよりコールグラフの下位のコンポーネントへ前記最初のプローブを移動することを決定すること、を含む。請求項1から7のいずれか1項の方法であり、前記アプリケーションを自動的に解析することは静的に実行され、少なくともいくつかのコンポーネントにプローブを自動的に付加することは、前記アプリケーションが実行されていない間に行われる。複数のコンポーネントを有するアプリケーションを計測する1以上のプロセッサ230を備えるシステムであり、その1以上のプロセッサは:aどのコンポーネントの内部にプローブを静的に配置するかを判定するためにアプリケーションを自動的に解析し;b前記アプリケーションが実行していない間に、判定されたコンポーネントの前記アプリケーションにプローブを自動的に付加し;c前記アプリケーションの実行している間に前記プローブからデータを受信し;d前記データに基づいて最初のコンポーネント内の最初のプローブに対する1以上のメトリックを決定し;e前記最初のプローブに対する前記1以上のメトリックに基づいて前記アプリケーション内の別のコンポーネントへ前記最初のプローブを移動するか否かを判定し;f前記eの判定がそのように示す場合、前記アプリケーションが実行されている間に前記アプリケーション内の別のコンポーネントへ前記最初のプローブを移動し;g前記最初のプローブに対する前記1以上のメトリックに基づいて前記アプリケーションから前記最初のプローブを削除するか否かを判定し;h前記gの判定がそのように示す場合、前記アプリケーションが実行されている間に前記アプリケーションから前記最初のプローブを削除し;およびi付加的なプローブのために前記dから前記hを繰り返す。請求項9のシステムであり、前記1以上のプロセッサは、前記最初のプローブを前記アプリケーション内の別のコンポーネントに移動するか否かの判定の一部として、前記最初のコンポーネントの呼出し率が閾値よりも大きいか否かを判定する。請求項10のシステムであり、前記1以上のプロセッサは、前記最初のコンポーネントの呼出し率が閾値よりも大きい場合、前記最初のコンポーネントよりコールグラフの下位のコンポーネントに前記最初のプローブを移動する。請求項9のシステムであり、前記1以上のプロセッサは、前記最初のプローブを前記アプリケーション内の別のコンポーネントに移動するか否かの判定の一部として、前記最初のコンポーネントの呼出し率が閾値よりも小さいか否かを判定する。請求項12のシステムであり、前記1以上のプロセッサは、前記最初のコンポーネントの呼出し率が閾値よりも小さい場合、前記最初のコンポーネントよりコールグラフの上位のコンポーネントに前記最初のプローブを移動する。請求項9のシステムであり、前記1以上のプロセッサは、前記最初のプローブを前記アプリケーション内の別のコンポーネントに移動するか否かの判定の一部として、前記最初のコンポーネントに関連したスレッドの同時実行性が閾値よりも大きいか否かを判定し、前記1以上のプロセッサは、前記最初のコンポーネントに関連したスレッドの同時実行性が閾値よりも大きい場合、前記最初のコンポーネントよりコールグラフの下位のコンポーネントに前記最初のプローブを移動する。請求項9のシステムであり、前記1以上のプロセッサは、前記最初のプローブを前記アプリケーション内の別のコンポーネントに移動するか否かの判定の一部として、前記最初のコンポーネントの実行時間が閾値よりも大きいか否かを判定し、前記1以上のプロセッサは、前記最初のコンポーネントの実行時間が閾値よりも大きい場合、前記最初のコンポーネントよりコールグラフの下位のコンポーネントに前記最初のプローブを移動する。本明細書では、アプリケーションの選択されたコンポーネントにインスツルメンテーション例えば、プローブを自動的に挿入し、プローブを自動で動的に修正するための技術を開示する。例として、プローブは、アプリケーションから動的に削除されるか、またはアプリケーション内の別のコンポーネントに動的に移動される。本明細書に開示される実施形態は、アプリケーションを計測するためにユーザ例えば、システム管理者の介入を必要としない。最初に、アプリケーションなどのソフトウェアは、どのコンポーネントがプローブを有するべきかを判定するために、一連の経験則に基づいて自動的に解析される。プローブは、それらに基づいて静的例えば、アプリケーションが実行されていない間に挿入され得る。その後、アプリケーションは、コンポーネントがどの程度の時間、実行するかなどのパフォーマンスデータをプローブが収集するように実行される。パフォーマンスデータに基づいて、1以上のメトリックが各プローブに対して決定され得る。メトリックの例としては、コンポーネントの呼出し率、コンポーネントの実行に要する平均時間、コンポーネントに関係付けられたスレッドの同時実行性を含むが、それに限定されるわけではない。各プローブに対するメトリックは、プローブを修正するか否かを判定するために検査され得る。例えば、内部にプローブが存在するコンポーネントが、閾値よりも多く呼び出される場合、プローブはアプリケーションから削除されるか、またはコールグラフの上位のコンポーネントに移動され得る。したがって、一実施形態では、アプリケーションが実行されていないときにアプリケーションを解析しプローブを挿入することによって静的に実行される第1の計測パス、およびアプリケーションをシャットダウンする必要がないように動的に実行される第2の計測パスを含む。図1は、異なったコンピュータシステムがマネージャにデータを提供するネットワークを示す。コンピュータシステムの例としては、アプリケーションサーバ110、または所望の機能を実現するためのコードを実行するのに適したプロセッサを有する他のタイプのコンピュータシステムを含む。アプリケーションサーバ110は、異なるアプリケーションを実行でき、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ110は、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、アプリケーションサーバ110は、マネージャコンピュータ120と通信する。マネージャコンピュータ120は、アプリケーションサーバ110からローカルまたはリモートであり得る。例えば、Webベースの電子商取引アプリケーションなど企業アプリケーションenterpriseapplicationを実行している会社は、負荷分散のために1の場所で複数のアプリケーションサーバを使用する。例えば、ユーザのWebブラウザ102のようなユーザからのリクエストは、インターネットのようなネットワーク104を介して受信され、いずれかのアプリケーションサーバ110に送られる。Webブラウザ102は、図示していないインターネットサービスプロバイダーを介してネットワーククラウド104に、通常、アクセスする。アプリケーションサーバ110は、管理されたアプリケーション151を含み、それは、エージェント112、例示のプローブ153および154を含む。プローブの数は任意である。アプリケーション151は、Javaアプリケーションまたは異なるタイプのアプリケーションである。このように、アプリケーションサーバ110で実行されるエージェントソフトウェアは、エージェント112によって表され、ある可能なアプローチとして、アプリケーションサーバ110上で実行されている、管理されたアプリケーション151、ミドルウェアまたはその他のソフトウェアから、情報を収集する。例えば、アプリケーション151からの情報は、プローブ153および154を使用して得られる。実際には、多くのそのようなプローブは、アプリケーション151の様々なコンポーネントに関する情報を得るために使用することができる。複数の実施形態では、プローブは、計測を用いることによってアプリケーション151に付加され、その一例にはバイトコード計測がある。ただし、収集されたデータは、他の方法でも得ることができる。エージェント112は、監視対象となるコンピュータシステムに元来、存在しており、データの取得ポイントを提供する。エージェントは、マネージャ120と通信してデータを整理し最適化する。一実施形態では、プローブ153,154および付加的なコードを付加するために、プローブビルダー図1には図示されないは、アプリケーション151のためにバイトコードを計測例えば修正する。プローブは、静的例えば、アプリケーション151が実行されない間に、または動的例えば、アプリケーション151が実行される間に付加される。プローブは、アプリケーションの業務ロジックを変更することなく、アプリケーション151に関する情報の特定部分を測定し得る。あるタイプのプローブは、コンポーネントが実行に費やす時間を測定する。時間には、プローブを有するコンポーネントによって呼び出されたコンポーネントが実行に費やす時間を含めることができるが、これは必須ではない。プローブは、コンポーネントのエントリポイントにおける始点およびコンポーネントの各出口における終点を有する。一実施形態では、始点はタイマーを起動し、終点はタイマーを止める。プローブは、タイミング情報に加えて他の情報を収集する。プローブビルダは、アプリケーション151と同じマシン上に、または別のマシンン上にインストールされるエージェント112もまた付加する。一旦、プローブがアプリケーション151にインストールされたり、また監視機能が別に提供されたりすると、そのアプリケーションは管理されたアプリケーションと称される。バイトコードを計測することについて、さらなる情報として、LewisKCirneによるSystemForModifyingObjectOrientedCodeと題する米国特許番号6,260,187や、2001年2月28日に出願されたAddingFunctionalityToExistingCodeAtExitsと題する米国特許出願番号09/795,901があり、それぞれその全体が参照により本明細書に組み込まれる。管理されたアプリケーション151を実行すると、プローブ153および154はエージェント112にデータを送信する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始および停止回数、またはトランザクション/実行フロー内の個々のコンポーネントの開始および停止回数、のようなパフォーマンスデータを示す。一実施形態では、プローブ153および154は、データを書いたりデータを変更したりそうでなければアプリケーションサーバの状態を変更する原因となったりする他のコードやオブジェクトに実装される。エージェント112は、その後、アプリケーション実行データと称されるデータを収集しサマライズしてマネージャ120に送信する。それに呼応して、マネージャ120は、要求された計算を実行し、アプリケーション実行データをユーザインタフェース112で使用可能にして、必要に応じて、後で解析するためにデータベース118へアプリケーション実行データを送信する。一実施形態では、マネージャ120は、アプリケーション151をどのように動的に計測するかを判定するためにアプリケーション実行データを使用する。プローブを用いてアプリケーションを監視することに関するさらなる情報として、2004年4月22日に公開された、LewisKCirneによるUserInterfaceForViewingPerformanceInformationAboutTransactionsと題する米国特許出願公開番号2004/0075690があり、その内容は参照により本明細書に組み込まれる。マネージャ120は、エージェントから受信したデータに基づいて情報を表示するため、例えばモニタのようなユーザインタフェース122と通信するワークステーションのような離れたコンピュータシステム上に提供される。マネージャ120は、またエージェントから受信したデータを格納するためにデータベース118へアクセスする。提示された例では、アプリケーションサーバは、ネットワーク104にアクセスすることなくマネージャ120と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ120は、ネットワーク104を介して複数のアプリケーションサーバのエージェントからのデータを受信することができる。例えば、大規模な組織は、セントラルネットワークオペレーションセンタを運用しており、そこでは、1以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払い処理をするサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ120およびユーザインタフェースディスプレィ122は、企業の本社の場所で提供される。必ずしも、Webベースまたは小売り若しくはその他の販売に関する必要はなく、他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータのシステムアレンジに加えて、1以上のエージェントによって単一のコンピュータシステムが同様に監視されることがある。図2は、図1のネットワークで使用されるコンピュータシステムの一実施形態を示す。コンピュータシステム200は、図1に関連して説明したように、Webブラウザ102、ホスト例えばアプリケーションサーバ110、マネージャ120および/またはユーザインタフェース122で使用されるシステムを簡略化して表したものである。コンピュータシステム200は、ハードディスクまたはポータブルメディアのような記憶装置210、他のコンピュータと通信するためのネットワークインタフェース220、ソフトウェアの命令を実行するためのプロセッサ230、例えば、記憶装置210からロードされた後にソフトウェアの命令を格納するためのRAMのような作業メモリ240およびユーザインタフェースディスプレィ250を含む。記憶装置210は、ここで説明した機能を提供するための方法を実行するのにプロセッサ230をプログラムするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ250は、1以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ250は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。また、ここで説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、1以上のプロセッサをプログラムするために具現化されているプロセッサの読み取り可能に格納されたコードを有する、1以上のプロセッサにより読み取り可能な記憶装置を使用することができる。プロセッサにより読み取り可能な記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な記憶装置を含むことが可能である。例えば、コンピュータにより読み取り可能な記憶装置には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な記憶装置の例としては、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、ディジタルバーサタイルディスクDVD、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタム集積回路、ゲートアレイ、FPGA、PLDや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、1以上の実施形態を実装するソフトウェア記憶装置に格納されているは、1以上のプロセッサをプログラムするために用いられる。1以上のプロセッサは、1以上のコンピュータにより読み取り可能な記憶装置、周辺機器および/または通信インタフェースと通信することができる。いくつかの実施形態では、エージェント112は、アプリケーション151を監視してアプリケーション実行データをマネージャ120に転送し、そこでデータが解析されユーザに報告される。図3は、アプリケーション151を監視する処理の一実施形態のフローチャートを示している。当該処理は、図1のシステム100の例において実行される。アプリケーション151は、ステップ302でエージェント152に監視される。監視は、アプリケーションサーバ110のどのトランザクションが処理されるのかを判定し、アプリケーションがクライアントの要求を処理するときにエージェント112に呼び出されている間の時間を判定するエージェント112を含む。ステップ302は、データを収集するために実行されるアプリケーション151内のプローブを含む。アプリケーションの監視に基づくアプリケーション実行データは、ステップ304で生成される。生成されたアプリケーション実行データは、リクエストの処理に関わるアプリケーションのコンポーネント、リクエストの処理中に各コンポーネントが消費する時間幅、およびその他の情報を示す。アプリケーション実行データは、プローブの実行により結果として生じるデータに基づいてエージェント112により生成され、その後、エージェント112が、生成されたアプリケーション実行データをマネージャ120に転送する。一般的に、アプリケーション実行データには、平均的なコンポーネント例えば、メソッドの実行時間、毎秒または間隔ごとのコンポーネントの呼出し率、コンポーネントの呼出し回数、開始したが終了していない間隔ごとのコンポーネントの呼出し回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのコンポーネントの呼出し回数が特定の閾値を超えたコンポーネントの呼出し回数を示すストール状態のメトリックなどの情報が含まれる。また、アプリケーション実行データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定することができる。アプリケーション実行データは、管理されたアプリケーション151によって処理されている特定のトランザクションにリンクされることに留意されたい。アプリケーション実行データは、データを集約したり、データを格納したり、インタフェースまたは他のユーザインタフェース112を介してオペレータにデータを提供するなど、ステップ306でマネージャ120により処理されて報告される。図4は、アプリケーションの2パス自動計測のための処理400の一実施形態を示すフローチャートである。1つのパスは、アプリケーション151を自動で静的に計測し、もう1つのパスは、アプリケーションを自動で動的に計測する。処理400は、管理されたアプリケーション151に対して、自動的に計測する例えば、プローブを付加するためにシステム100で使用される。ステップ402では、アプリケーション151は、どのコンポーネント内にプローブを配置するかを判定するために自動的に解析される。この解析は、静的に行われる。したがって、アプリケーション151は、それが解析されるのに際して実行される必要はない。一実施形態において、一連の経験則がプローブを配置する場所例えば、コンポーネントを判定するために使用される。例えば、コンポーネントがループまたはロックを有する場合、コンポーネントがプローブを有するべきであるという判定が行われる。ステップ404では、プローブは、ステップ402で判定された場所例えば、コンポーネントに自動的に挿入される。プローブは静的に挿入されるが、これはアプリケーション151が実行されていない間に、プローブが挿入されることを意味する。ステップ402および404のさらなる詳細は、図8Aおよび8Bに関連して説明される。ステップ406では、アプリケーション151は、プローブが挿入された状態で実行される。例えば、アプリケーション151は、Webブラウザ102からのリクエストを受信し、それらのリクエストに応じてトランザクションを処理する。リクエストの典型的な例には、Webサイトへのユーザログイン、Webサイトから製品を購入するためのリクエストおよびクレジットカード認証があるが、これらに限定されない。ステップ408では、アプリケーション151が実行されている間に、プローブからデータが受信される。例えば、エージェント112は、プローブからデータを受信し、マネージャ120へデータを送信する。このデータには、コンポーネントが実行する時間の長さなどのパフォーマンスデータが含まれる。ステップ410では、ステップ408で受信したデータに基づいて、1以上のメトリックが最初のプローブに対して判定される。説明のために、最初のプローブは、アプリケーション151内の最初のコンポーネント例えばメソッドに、元々配置されている。メトリックは、最初のプローブによって収集されたパフォーマンスデータに基づいており、また同様に他のプローブによって収集されたパフォーマンスデータにも基づくものでもある。しかし、一般的に、メトリックは、最初のコンポーネントの実行に関与する。あるメトリックは、最初のコンポーネントが呼び出される頻度である。この情報は、アプリケーションからプローブを削除するか、またはアプリケーション内の別のコンポーネントにプローブを移動するか、のどちらを行うかを判定するのに役立つ。別のメトリックは、同時実行性に関与する。例えば、同時実行中のスレッドの数を1つのメトリックと決めることができる。換言すると、最初のコンポーネントに関係付けられている同時実行のスレッド数を決めることが可能となる。あるメトリックは、平均実行時間に関与することがある。例えば、最初のコンポーネントが実行するための平均時間を決めることができる。マネージャ120、エージェント112の1つまたは別のエンティティが、メトリックを決める。ステップ412では、1以上のメトリックの解析に基づいて最初のプローブが修正されるべきか否かの判定が行われる。一例として、最初のコンポーネントの呼出し率が高すぎる場合には、最初のプローブは修正されるべきである。最初のプローブが修正されるべきであると判定された場合、ステップ414において最初のプローブがいくつかの方法で修正される。修正の例としては、アプリケーション151から最初のプローブを削除し、アプリケーション151内の別の場所例えば、コンポーネントに最初のプローブを移動することを含むが、これに限定されない。異なるタイプまたはレベルの計測を提供することも可能で、例えば、コンポーネントの実行について多くの側面が追跡される高レベルの計測や、コンポーネントの実行についてほんの一部の側面しか追跡されない低レベルの計測などがある。したがって、その修正は、プローブがコンポーネント内でどのように実装されているかを修正するものとなり得る。一例として、プローブがプログラムループ内に命令を持つ場合、それらの命令は削除され得る。いくつかの実施例では、アプリケーション151が実行されているときには、修正が動的に行われる。したがって、アプリケーション151は、プローブを修正するためにシャットダウンされる必要はない。ステップ410~414のさらなる詳細が図5の説明に関連して説明される。最初のプローブが修正されているか否かに関わらず、ステップ420で、付加されたプローブが存在するか否かについての判定が行われることによって処理が継続する。もしそうであれば、処理400は、次のプローブのために1以上のメトリックを判定するため、ステップ410に戻る。すべてのプローブが解析されるまで処理は継続する。あるプローブはアプリケーションから削除され、またあるプローブはアプリケーション内の他のコンポーネントへ移動されて、他のプローブは変更されないという結果となる。他の修正がプローブに行われ得る。図5は、プローブに修正を行うか否かの判定をするため、プローブに関係付けられているメトリックを処理して、動的に適切な修正を行う処理500の一実施形態を示すフローチャートである。処理500は、処理400のステップ410,412および414の一実施形態である。処理500は、1つのプローブに対する異なるメトリックの解析を記述し、付加的なプローブのために繰り返される。ステップ502では、プローブが存在するコンポーネントの呼出し率は、高い呼出し率が存在するか否かを判定するために閾値と比較される。呼出し率は、プローブがある期間にわたって実行された回数を指す。これは、異なるサーバ上のコンポーネントの類似するインスタンスのためのものであることに留意されたい。例えば、システム100では、異なるアプリケーションサーバ110は、管理されたアプリケーション151の別のインスタンスを実行する。したがって、解析されているプローブに対するコンポーネントは、管理されたアプリケーションの各インスタンスにおける別々のインスタンスを有する。このように、呼出し率は、コンポーネントのすべてのインスタンスに対する呼出し回数の合計である。しかし、この方法で呼び出しを測定することは必須ではない。例えば、呼出し率は、管理されたアプリケーションの単一のインスタンス、または管理されたアプリケーションのいずれかのサブセットのインスタンスに基づくものとなり得る。一実施形態では、呼出し率は、ある期間にわたるコンポーネントの呼び出しの合計をカウントすることによって定められる。ステップ502で、この呼出し率は、所定の閾値と比較される。閾値は、固定値とすることも、変数とすることもできる。一実施形態では、ユーザ例えば、システム管理者は、閾値を設定することを許可されている。同じ閾値がすべてのプローブに使用される必要はない。前述のように、プローブは、アプリケーションの解析に基づいてアプリケーション151に元々挿入されていてもよい。閾値は、また、解析に基づいて設定されてもよい。例えば、どのコンポーネントの内部にプローブを配置するべきであるかを判定するのに使用される一連の経験則もまたプローブのための閾値を示すことがある。具体的な例として、プログラムループが存在したことを理由に挿入されるプローブは、ロックが存在したことを理由に挿入されるプローブとは異なる閾値を有する。呼出し率が閾値よりも高い場合には、プローブは、アプリケーションから削除されるか、またはそのプローブが内部に存在するコンポーネントよりコールグラフにて上位のコンポーネントに移動される。前述したように、削除や移動は、アプリケーション151をシャットダウンすることなく動的に行われる。プローブの削除や移動は、アプリケーション151のインスタンスのすべてのまたはいくつかのサブセットに対してであることに留意されたい。一実施形態では、呼出し率が閾値よりも高い場合は、プローブは常に削除される。一実施形態では、可能であれば、呼出し率が閾値よりも高い場合は、プローブはコールグラフにおける上位のコンポーネントに常に移動される。コールグラフにおける上位のコンポーネントにプローブを移動することは、常に可能であるわけではないことに留意されたい。一実施形態では、プローブを削除または移動のいずれを行うかの判定が行われる。プローブを削除または移動のいずれを行うかについての判定は、様々な方法で行われる。一例として、決定は呼出し率そのものに基づいて行われる。例えば、呼出し率は、プローブを移動または削除のいずれを行うかの判定を行うために第2の閾値と比較され得る。他の例として、付加的な情報が検査され得る。削除または移動のいずれを行うかの判定は、プローブを現在含むコンポーネント、またはコールグラフ中の他のコンポーネント例えば、プローブを移動するための候補のコンポーネントのコードの解析に基づいて行われ得る。さらに別の例として、プローブを削除や移動するための判定は、他のメトリック例えば、同時実行性、実行時間などの解析に基づいて行われ得る。プローブを移動するために他のどんなコンポーネントが決定されるかについて、さらなる詳細が以下で説明される。プローブが別のコンポーネントに移動される場合、これはプローブが厳密に同じ状態を維持していることを意味しないことに留意されたい。本明細書で使用するプローブを別のコンポーネントに移動するまたは類似のフレーズは、最初のコンポーネントにプローブが存在する、というよりも、プローブが他のコンポーネントに挿入される、ということを意味する。他のコンポーネントは、当然、異なる命令を持っていることから、新しいプローブはその新しいコンポーネントに合うように調整される。例えば、いくつかの実施形態では、プローブはコンポーネントのエントリポイントにおける開始タイマーおよび各出口における終了タイマーを有する。そのため、プローブを移動した後には終了タイマーの数が異なる場合がある。いくつかの実施形態で、プローブは、コンポーネント内のプログラムループの近くに配置された命令を有する。そのため、新しいコンポーネントが異なる数のループを有する場合には、プローブを実装するために使用される命令に影響を与えることがある。プローブがアプリケーション151から削除されるか、または別のコンポーネントに移動される場合、処理500は終了する。そうでなければ、処理500は、そのプローブに対する次のメトリックを処理するため、ステップ506で継続する。ステップ506では、内部にプローブが存在するコンポーネントに関連する同時実行性が閾値と比較される。同時実行性は、内部にプローブが存在するコンポーネントに関連したスレッドにおいてインスタンスがいくつ同時に実行するかに対するものである。この同時実行性は、平均的な同時実行値であり得る。例えば、マネージャ120は、異なる時点での特定のスレッドに対する瞬間的な同時実行値を判定する。その後、平均的な同時実行性例えば、平均値、中央値、最頻値が判定される。別の例では、ある期間にわたるスレッドの最大同時実行値を判定する。別々の同時実行値は、各サーバ110に対して作られ、すべてのサーバ100からのデータは単一の同時実行値などを判定するために用いられることに留意されたい。多数の他の方法が同時実行値を判定するために使用され得る。ステップ506で、同時実行値が閾値と比較される。閾値は、固定値とすることも、変数とすることもできる。一実施形態では、ユーザ例えば、システム管理者は、閾値を設定することを許可されている。同じ閾値がすべてのプローブで使用される必要はない。閾値は、またアプリケーションの解析に基づいて設定されてよい例えば、プローブが最初に挿入された場合。同時実行値が閾値よりも高い場合には、プローブは、ステップ508において、そのプローブが内部に存在するコンポーネントよりコールグラフにて下位のコンポーネントに移動され得る。前述したように、移動は、アプリケーション151をシャットダウンすることなく動的に行われる。プローブの移動は、アプリケーション151のインスタンスのすべてのまたはいくつかのサブセットに対してであることに留意されたい。例えば、コールグラフにおける下位のコンポーネントが存在しない場合には、アプリケーションからプローブを削除するか、またはその場所に保持するかのいずれかの決定が行われる。ステップ508ではプローブが移動される場合、処理500は終了する。そうでなければ、処理500は、そのプローブの次のメトリックを処理するため、ステップ510で継続する。ステップ510では、内部にプローブが存在するコンポーネントに関連する実行時間が閾値と比較される。実行時間は、コンポーネントが実行する時間の長さである。これは、内部にプローブが存在するコンポーネントによって呼び出されるコンポーネントの実行時間を含んでもよいし、含まなくともよい。しかし、実行時間は、内部にプローブが存在するコンポーネントが実行するために必要とされるわけではない。別の例は、コンポーネントによって少なくとも一部が実行されるトランザクションのタイプに対する実行時間のものである。例えば、実行時間は、コンポーネントによって少なくとも一部が実行されるログイントランザクションまたは製品購入トランザクションに対するものである。実行時間は、平均的な例えば、平均値、中央値、最頻値実行時間であってよい。アプリケーション151の各インスタンスのために別々の実行時間が作られ、すべてのサーバ100からのデータは単一の平均実行時間などを判定するために用いられてよいことに留意されたい。多数の他の方法が実行時間を判定するために使用され得る。ステップ510では、実行時間が閾値と比較される。閾値は、固定値であってもよいし、変数であってもよい。一実施形態では、ユーザ例えば、システム管理者は、閾値を設定することを許可されている。同じ閾値がすべてのプローブで使用される必要はない。閾値は、またアプリケーションの解析に基づいて設定されてもよい例えば、プローブが最初に挿入された場合。実行時間が閾値よりも長い場合には、プローブは、ステップ512において、そのプローブが内部に存在するコンポーネントよりコールグラフにおいて下位のコンポーネントに移動される。前述したように、移動は、アプリケーション151をシャットダウンすることなく動的に行われる。プローブの移動は、アプリケーション151の異なるインスタンスにおけるプローブのインスタンスのすべてのまたはいくつかのサブセットに対するものであることに留意されたい。例えば、コールグラフの下位にコンポーネントが存在しない場合には、アプリケーション151からプローブを削除するか、またはその場所に保持するかのいずれかの決定が行われる。ステップ512で、プローブが別のコンポーネントに移動された場合、処理500は終了する。そうでなければ、処理500は、そのプローブの次のメトリックを処理するため、ステップ514で継続する。ステップ514では、コンポーネントの呼出し率は、呼出し率が低いか否かを判定するために閾値と比較される。要求はされていないものの、これは同じ呼出し率であることがステップ502で説明されている。このように、呼出し率は、コンポーネントがある期間にわたって実行した回数を示す。この呼出し率は、所定の閾値と比較される。この閾値は、ステップ502の閾値高い閾値の可能性があるとは異なっていてもよい。一方、低い閾値がステップ514で使用される。低い閾値は、固定値であってよいし、変数であってもよい。一実施形態では、ユーザ例えば、システム管理者は、低い閾値を設定することを許可されている。同じ低い閾値がすべてのプローブで使用される必要はない。呼出し率が低い閾値よりも低い場合には、プローブは、アプリケーションから削除されるか、またはそのプローブが内部に存在するコンポーネントよりもコールグラフにて下位のコンポーネントに移動される。前述したように、削除や移動は、アプリケーション151をシャットダウンすることなく動的に行われる。プローブの削除や移動は、アプリケーション151のインスタンスのすべてのまたはいくつかのサブセットに対するものであることに留意されたい。一実施形態では、呼出し率が低い閾値よりも低い場合は、プローブは常に削除される。一実施形態では、可能であれば、呼出し率が低い閾値よりも低い場合、プローブはコールグラフにて下位のコンポーネントに常に移動される。コールグラフの下位のコンポーネントにプローブを移動することは、常に可能であるわけではないことに留意されたい。一実施形態では、プローブを削除または移動のいずれを行うかの判定が行われる。高い呼出し率について、上述したようなファクターが使用されてよい高い呼び出し率および低い呼出し率に対して異なるファクターが使用され得ることに留意されたい。処理500は、このプローブに対して処理を行うメトリックがそれ以上存在しないときには、終了する。メトリックは、異なる順序で処理されてよいことに留意されたい。一実施形態では、コールグラフにて上位のコンポーネントにプローブを移動することは、コールグラフにて下位のコンポーネントにプローブを移動することよりも好ましい。したがって、メトリックをテストする順番は、この優先度を重視して選択される。処理500は、コールグラフの上位にプローブを移動させることを優先する一例である。処理500で記述したように、一旦、あるメトリックの解析がプローブを削除または移動するような判定の結果となった場合には、そのプローブは、さらなるメトリックを検討することなしに移動や削除される。しかし、複数のメトリックは、どんなアクションを採るかを判定する助けとなるために検査され得る。例えば、高い呼出し率が存在する場合、同時実行性または実行時間がプローブを削除または移動のいずれを行うかを判定するために検査される。上述のように、処理500は、他のプローブのために繰り返される。しかし、処理500の厳密なシーケンスは、すべてのプローブに対して使用されることは必要とされない。例えば、いくつかのプローブのため、同時実行性をテストする以前に、実行時間がテストされ得る。異なるプローブに対してメトリック例えば、ステップ502,506,510,514が適用される順序を決定するために様々な技術が使用され得る。また、別のメトリックが別のプローブに適用され得ることにも留意されたい。例えば、実行時間メトリックステップ510は、特定のプローブを解析するときには使用されずともよい。処理500に明示的に記載されていない他のメトリックも使用される可能性がある。図6は、処理500の側面を説明するために使用されるコールグラフ600の例示で、同様に他の技術も記載されている。コンポーネントは、図1のアプリケーションサーバ110のようなアプリケーションサーバ上で実行されるアプリケーション内に示されている。コンポーネントAは、コールグラフの最上位のレベルにあり、コンポーネントBを呼び出し、コンポーネントBは次にコンポーネントCを呼び出す。コンポーネントCは、コンポーネントD、EおよびFを呼び出す。コンポーネントFは、コンポーネントGを呼び出し、コンポーネントGはコンポーネントHを呼び出す。アプリケーションは、計測されるときに、通常、選択されたコンポーネントのみがアプリケーション151の解析に基づいて自動的に計測されることに留意されたい。したがって、多くのコンポーネントは、少なくとも当初はアプリケーション内で起動され/呼び出されるが、計測はされない。コンポーネント指向のプログラムモジュールは、コンポーネントと呼ばれるブロックを組み立ててアプリケーションや他のプログラムをプログラマに組ませるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行することができる。さらに、コンポーネントは、再帰呼び出しによって自分自身を呼び出すことや他のコンポーネントを呼び出すことができ、これによって、コンポーネントのシーケンスがプログラム内に呼び出される。コンポーネントは、プログラムが実行されるときに、消費されるコンピュータシステムの資源、あるいは実行されたワークの例である。コンポーネント指向のプログラミングモデルの一例は、J2EEであるが、JavaServerPage、EnterpriseJavaBean、サーブレットおよびJavaDatabaseConnectivityコンポーネントといったコンポーネントを用いることができる。しかしながら、その他のコンポーネント指向のプログラミングモデルもまた使用されており、例えば、マイクロソフト社のNETコンポーネントが使用される。さらに、プログラミングモデルはオブジェクト指向である必要はない。1つのアプローチでは、コンポーネントはメソッドである。コールグラフ600の上位レベルに近いコンポーネント例えばBは、希にしか呼び出されないが、内部コールであるため実行に時間がかかる。コールグラフの下位レベルにあるコンポーネント例えばG,Hは、頻繁に呼び出される。しかし、そのような下位レベルのコンポーネントが実行されるたびに、短い時間だけ実行され得る。場合によっては、本当に重要な情報は、コールグラフの上位レベルのコンポーネントにプローブを有することによって判定される。場合によっては、本当に重要な情報は、コールグラフの下位レベルのコンポーネントにプローブを有することによって判定される。説明のために、コンポーネントBは、内部にロックを有することからプローブ1で自動的に計測され、コンポーネントEは、ループを有することからプローブ2で自動的に計測され、そして、コンポーネントHは、ループを有することからプローブ3で自動的に計測される。これは、処理400のステップ404で実行され得たものである。しかし、後述するように、プローブ1は、コールグラフの下位のコンポーネントCに移動され、プローブ3は、コールグラフの上位のコンポーネントGに移動される。これは、処理400のステップ414または処理500のステップ504,508,512もしくは512のうちの1つで実行される。プローブが、コールグラフ600で上位のコンポーネントに存在する場合には、実行時間は長くなるが、呼出し率は低くなる。この場合、プローブからは十分に情報を得られない。1つの選択肢は、より注目すべき情報を判定するためにコールグラフの下位のコンポーネントにプローブを移動することである。コンポーネントBのプローブ1が例示のために使用される。実行時に、コンポーネントBのプローブ1は、呼び出されたコンポーネントCでどの程度の時間が使われたかに関する情報を収集する。例えば、コンポーネントCがコンポーネントBから呼び出された時点でタイマーが存在する。ただし、コンポーネントBのプローブは、例えば、コンポーネントD~Hのような低位のレベルで、どの程度の時間が使われたかを判定できないことがある。この場合、プローブ1をコールグラフの下位のコンポーネントに移動することは、より多くの情報を得るのに役立つ。処理500のステップ510~512で述べたように、コンポーネントが長い実行時間を有する場合、コンポーネントためのプローブは、コールグラフ600の下位のコンポーネントに移動される。一例として、コンポーネントBに自動的に挿入されたプローブ1は、コールグラフ600内のそれより下位のすべてのコンポーネントが呼び出されていることにより、長い実行時間を有する。したがって、プローブ1は、コンポーネントCのような下位レベルに、またはコールグラフ600のさらに下位レベルにある異なるコンポーネントに移動される。コンポーネントBの呼出し率は、ステップ502がプローブ1を削除したりコールグラフ600の上位に移動させたりすることが起こらないような高い閾値以下でなければならないことに留意されたい処理500のステップ502~504に示されているように。コンポーネントBのプローブ1は、長い実行時間以外の理由でコールグラフ600の下位に移動されることがある。例えば、コンポーネントBのプローブ1は、低い閾値よりも呼出し率が小さいことが原因で移動されることがある。処理500のステップ514~516に示されるように、コンポーネントが低い呼出し率を有する場合には、そのプローブはコールグラフ600の下位のコンポーネントに移動される。このように、コンポーネントBに自動的に挿入されるプローブ1は、例えばコンポーネントCのような下位レベルに移動される。プローブをコールグラフ600の下位のコンポーネントに移動する場合、それはコールグラフ600の下位の任意のコンポーネントに移動され得ることに留意されたい。一実施形態において、プローブは一レベル下位に移動される。アプリケーション151の再実行後、プローブは再び下位に移動されることがある。しかし、プローブはさらに下位に移動され得る。例えば、プローブ1は、コンポーネントBからコンポーネントFまたはGへと下げられ得る。一方、プローブがコールグラフ600の下位レベルのコンポーネントに存在する場合には、実行時間は短いかもしれないが、呼出し率は高くなる。したがって、1つの選択肢は、コールグラフ600の上位のコンポーネントにプローブを移動することである。これにより、類似の情報を収集し得るが、低いオーバーヘッドで行われ得る。コンポーネントHのプローブ3が例として使用される。説明のために、平均して、コンポーネントHが呼び出される場合、ループは1,000回実行される。したがって、この例では、プローブ3の少なくともいくつかの命令は、コンポーネントH内に位置しているために、1,000回実行され得る。もちろん、それは、プローブの命令がループの各実行により呼び出されるようにコンポーネントH内の位置にプローブ3を配置させることを要件とするものではないが、この例は1つの可能性である。このように、説明のために、処理500のステップ502で説明したように、コンポーネントHは高い呼出し率を有する。実行時に、コンポーネントHのプローブ3は、呼び出されたコンポーネントHでどの程度の時間が使われたかに関する情報を収集する。コンポーネントHのループは1,000回実行することから、これは有用な情報かもしれないが、プローブ3またはその命令の一部の実行に関連して、オーバーヘッドが問題となる可能性がある。それは、コンポーネントHのループ内のプローブ3に関係付けられた命令の実行がコンポーネントHの実行時間を著しく増加させるということである。したがって、プローブ3は、コールグラフ600の上位のコンポーネントGに移動し得る。コンポーネントGが呼び出される場合には、プローブ3は、コンポーネントHが呼び出されるときほど過度にはオーバーヘッドに寄与しない。しかし、有用な情報はまだ得られる。例えば、コンポーネントGがコンポーネントHを呼び出すことから、プローブ3はコンポーネントHの実行にかかる時間を判定することがさらに可能である。また、プローブ3は、コンポーネントHがどの程度の頻度で実行されるかについても、まだ判定することが可能である。次に、コンポーネントEのプローブ2について説明する。説明のために、コンポーネントEのループは、コンポーネントEの各呼び出しに対して平均2回のみ実行されるとする。したがって、この例では、プローブ2はループ内に命令を有するとしても、オーバーヘッドには過度に寄与しない。コンポーネントEは、他にどんなコンポーネントも呼び出さないことから、説明のために、長い実行時間を持たない。また、説明のために、コンポーネントEの呼出し率は、高い閾値よりも大きくなく、また、低い閾値よりも小さくもないとする。さらに、説明のために、コンポーネントEのための高い同時実行性は存在しないとする。したがって、処理500のどのメトリックも、プローブ2が削除または移動される必要があることを示していない。そのため、プローブ2は、コンポーネントEに存在したままである。しかし、別の例として、コンポーネントEの呼出し率が低い場合、プローブ2はアプリケーション151から削除され得る図6に示されている。この例では、コンポーネントEよりもコールグラフ600の下位に別のコンポーネントが存在しないことに留意されたい。そのため、プローブを削除するか、またはコールグラフ600の下位のコンポーネントに移動するか否かの判定は、コールグラフ600の下位にコンポーネントが存在するか否かに基づいて行われる。図7は、Java実行環境を示している。複数の実施形態は、Java実行環境で操作される。Java実行環境700は、ハードウェア716の上に構築されているオペレーティングシステム714上に構築されている。Java実行環境は、JavaAPIクラス702とJVM704を含むいくつかの仮想部品を含む。JVMは、レジスタ706、オペランドスタック708、ヒープ710およびメソッド領域712を含む。JVMは、命令のシーケンスとして一連のバイトコードを処理する。JVMの命令は、操作される上で値が具体化するゼロまたはそれ以上のオペランドを伴う、実行すべき操作を特定するオペコードから構成される。オペランドスタック、ヒープおよびメソッド領域は、アドレス指定可能なメモリ内に存在する。アドレスのサイズは32ビットで、各メモリロケーションは1バイトを含み、各レジスタは32ビットアドレスを格納する。メソッド領域は、バイトコードを含んでバイトバウンダリに配置され、オペランドスタックとヒープは、ワード32ビットバウンダリに配置される。レジスタは、実行すべき命令をメモリ内で追跡するプログラムカウンタPCを含む。プログラムカウンタは、実行すべき次のバイトコードを特定する。フレームレジスタは、オペランドスタック内のカレントメソッドの実行環境に対するポインタを含む。オペランドトップoptopレジスタは、オペランドスタックの先頭へのポインタを含み、算術式を評価するのに用いられる。変数varsレジスタは、局所変数へのポインタを含む。オペランドスタックは、メソッドと操作へパラメータを供給し、それらから結果を得る。すべてのバイトコード命令は、スタックからオペランドを取得してそれらの上で操作して、スタックに結果を戻す。オペランドスタックは、実行中のメソッドのスタックフレームを含む。スタックフレームは、例えば、局所変数、計算の中間結果など、メソッドの特定呼び出しのために、状態を保持する。具体的には、各JVMスレッドは、同時にスレッドとして生成された、専用のJVMスタックを持っている。JVMスタックは、フレームを格納し、局所変数と部分的な結果を保持し、メソッド呼び出しと戻り値の役割を果たす。このようにフレームは、動的リンクを実行するため、メソッドのための値を戻したり、例外処理をディスパッチするために使用されるのと同様に、データおよび部分的な結果を格納するため使用される。新しいフレームは、メソッドが呼び出されるたびに生成される。フレームは、メソッドの呼び出しが完了すると、その完了が正常か中途受け取れない例外処理を投げ出したかにかかわらず、破棄される。フレームは、フレームを生成するスレッドのJVMスタックから割り当てられる。各フレームは、局所変数の独自の配列、独自のオペランドスタック、および、カレントメソッドのクラスの実行時定数プールへのリファレンスを持っている。ヒープまたはメモリ割り当てプールは、ガーベジコレクトされる。ヒープは、すべてのクラスのインスタンスに対するメモリと配列がそこから割り当てられる実行データ領域である。ヒープは、起動した仮想マシン上に生成され、オブジェクトのためのヒープ記憶域は、ガーベジコレクタとして知られている自動記憶装置管理システムにより再生される。具体的には、Java実行環境で実行中の各プログラムが、それに割り当てられたガーベジコレクトされたヒープを持っている。また、ヒープ内の各クラスは、それに関連付けられた定数プールを持っている。定数は、変更することはないことから、通常、コンパイル時に生成される。定数プール内のアイテムは、特定のクラス内の任意のメソッドで使用されるすべての名前をエンコードする。クラスは、いくつの定数が存在するかのカウントを含むとともに、クラスの記述内における定数の特定リストの始まりを特定するオフセットを含む。メソッド領域は、コンパイルされたコード内でメソッドと関連付けられたバイトコード命令、および、動的リンクのために実行環境が必要とするシンボルテーブルを格納する。メソッドと関連付けられる必要があり得るデバッグや付加情報も、またこの領域内に格納される。プログラムカウンタは、常にメソッド領域の数バイトのアドレスを指し示し、例えば、メソッド領域の数バイトのアドレスが入る。プログラムカウンタは、スレッドの実行を追跡するために使用される。バイトコード命令が実行された後、プログラムカウンタは、次に実行する命令のアドレスを含む。メソッド領域は、すべてのJVMスレッド間で共有され、例えば、実行時定数プール、フィールドおよびメソッドデータならびにメソッドやコンストラクタのためのコード、のようなクラスごとの構造などを格納しており、クラスおよびインスタンスの初期化やインタフェースタイプの初期化で使用される特別のメソッドを含んでいる。メソッド領域は、起動した仮想マシン上に生成される。実行時定数プールは、クラスファイル内の定数プールテーブルのクラスごとの、またはインタフェースごとの実行時表現である。これには、コンパイル時に知られている数値リテラルから実行時に解決されるべきメソッドやフィールドリファレンスに至るまでの範囲で、定数のいくつかの種類が含まれる。各実行時定数プールは、JVMのメソッド領域から割り当てられる。クラスまたはインタフェースの実行時定数プールは、JVMによってクラスまたはインタフェースが生成されるときに構築される。図8Aは、静的計測のための処理フローの例として、Javaベースのものを示す。静的計測は、それが実行されていない場合、アプリケーションの解析に基づくものである。処理は、ある可能なアプローチでは、図1のエージェント112のようなエージェントによって実装される。処理400のステップ402~404で説明されているように、図8Aの処理は、アプリケーション151を解析し、プローブを挿入するための1つの技術である。計測への1つのアプローチは、メソッドなどのどのコンポーネントが計測されるべきかを判定する静的なルール805または経験則を提供することを含む。ルール805は、コンポーネントがアプリケーションにロードされる時にアクセスされる。複数の実施形態では、少なくともルール805のいくつかは、ループ命令文例えば、while...dodo...whilefor...などを探す。この理由の1つは、いくつかのコード例えば、Javaを持つ変数のソースがループ命令文であるということである。さらに、ループは、可変性をアプリケーションに導入する外部アプリケーションファクターのための有用なプロキシである例えば、データセットサイズ。したがって、ループを有するメソッドは、監視する計測ポイントの有用なセットである。一実施形態では、バイトコード例えば、Javaバイトコードは、メソッド内で潜在的なループを表すネガティブオフセットを持つジャンプ命令を見つけるべくジャンプ命令例えば、gotogotowjsrjsrwretを識別するために構文解析される。ジャンプ命令にネガティブオフセットが含まれている場合には、メソッドに計測ポイント例えば、プローブが挿入される。例えば、始点および1以上の終点を有するプローブが挿入される。一具体例として、始点はメソッドの入口に挿入され、終点はメソッドのすべての出口に挿入される。そのようなアプローチでは、クラスローダ820は、トランスフォーマ815にアプリケーションのバイトコードの生のデータバイトを提供するのに使用され、例えば、生のデータバイトをクラスに変換する。例えば、Javaでは、これは、クラスのロードに関与するClassLoaderオブジェクトのdefineClassメソッドを使用することを含み得る。ClassLoaderクラスは抽象クラスである。クラスの名前を付与すると、クラスローダは、クラスの定義を構成するデータを検索したり生成したりしようとする。代表的な手順は、名前をファイル名に変換し、ファイルシステムからその名前のクラスファイルを読み込むことである。defineClassメソッドは、バイトの配列をClassクラスのインスタンスにコンバートする。Classクラスのインスタンスは、Javaアプリケーションを実行中にクラスおよびインタフェースを表す。トランスフォーマ815は、したがって、このようにクラスを変換することによって、計測を付加するためにバイトコードを変換することができるソフトウェアである。1つのアプローチでは、トランスフォーマ815の最小処理単位をクラスファイルおよびそのバイト配列とすることができる。判断ブロック810において、アプリケーションのバイトコードがルール指令805に一致する場合、トランスフォーマ815はトレーサバイトコードの形式でプローブを付加する。判断ブロック810においてアプリケーションのバイトコードがルール805に一致しない場合、トランスフォーマ815はバイトコードに計測を付加しない。トランスフォーマ815と判断ブロック810は、プローブビルダ825の一部と考えることができる。この実装では、ルール805は、計測すべき管理されたアプリケーションの一部を特定する代表的な静的ルールの規定である。ルールは、最初に仮想マシン内でクラスが定義される場合に実装される。クラスは、一度だけ定義されれば、複数回ロードすることができる。例えば、同じクラスをロードする複数のクラスローダが存在し得る。また、クラスなどのコンポーネントは、特定の方法で名前が付けられるかどうか、特定のインタフェースを実装するかどうか、特定のサブクラスまたはスーパークラスを拡張するかどうか、などに基づいて、計測され得る。そのようなコンポーネントは、有用なそうでなければ興味深いパフォーマンスデータを提供する可能性があると考えられることから、計測すべきものとして選択される。例えば、ルールは、少なくともいくつかのサーブレットは興味深いデータを提供し得ると考えられているので、すべてのサーブレットを計測すべきであることを示すことがある。この場合、ルール805が、JavaクラスのHttpServletのサブクラスであるすべてのコンポーネントを計測すべきであることを示す場合がある。HttpServletは、すべてのサーブレットが依存する抽象クラスである。しかしながら、すべてのコンポーネントが計測されるわけではなく、包括的過ぎる計測は過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれる可能性があるという不安がある。その一方で、包括的でなさ過ぎる計測は、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。図8Bは、静的計測のための処理フローの例としてNETベースのものを示す。図8Bの処理は、処理400のステップ402~404で説明したように、アプリケーション151を解析し、プローブを挿入するための1つの技術である。この可能性のあるアプローチでは、管理されたアプリケーションのコンポーネントは、マイクロソフト社のNETフレームワークにより提供されている。Javaとは異なりNETフレームワークはクラスローダを使用しない。代わりに、NETは、フレームワーク用に特別に書かれたプログラムの実行を管理する仮想マシンを含む。NETフレームワークの実行環境は、共通言語ランタイムCLRとして知られている。CLRは、プログラムを実行する特定のCPUの能力をプログラマが考慮する必要がないように、アプリケーションの仮想マシンの外観を呈している。CLRは、セキュリティ、メモリ管理および例外処理などの他のサービスの提供もしている。予めコード化されたソリューションのクラスライブラリとCLRは、共にNETフレームワークを構成している。また、CLRは、アプリケーションの開発および実行のための言語に中立的なプラットフォームを提供する共通言語基盤CLIの実装であり、例外処理、ガーベジコレクション、セキュリティおよび相互運用のための各機能を果たしている。CLIは、コアクラスライブラリィ、コモンタイプシステムおよび共通中間言語CILを含む。Javaバイトコードと同様に、CILは中間バイトコードの他の例である。JavaとNETは、実装の一例にすぎず、他の実装もまた可能である。ここでは、ある可能なアプローチとして、処理がエージェント112によって実装されることがある。1つの可能性のある状況では、NETフレームワークは名前によってクラスを参照し、CLR870がクラスを発見し、トランスフォーマ865もしあればにそれを示し、その結果CILを使用する、という処理が行われる。特に、判断ブロック860でクラスがルール855に一致する場合、計測が付加される。判断ブロック860でクラスがルール855に一致しない場合は、計測は付加されない。トランスフォーマ865と判断ブロック860は、プローブビルダ875の一部であると考えることができる。図9は、動的にソフトウェアを計測するための処理フローの例を示す。処理フローは、アプリケーションからプローブを削除するため、または他の場所例えば、コンポーネントにプローブを移動するために使用され得る。したがって、処理は、処理400のステップ414または処理500のステップ504,508,512もしくは516を実装するときに使用され得る。削除されたプローブを有するコンポーネントのリスト908、および付加されたプローブを有するコンポーネントのリスト908がある。プローブが移動される場合、あるコンポーネントは削除されたプローブを有し、別のコンポーネントは付加されたプローブを有する。したがって、リスト906は、プローブが移動された先のコンポーネントを含む。リスト908は、プローブがそこから移動されたコンポーネント、およびプローブがアプリケーションから削除されたコンポーネントを含む。リスト908,910はクラスローダ902に提供され、クラスローダ902は、計測されたバイトコードを提供するためにトランスフォーマ/プローブビルダ900を使用することによって、バイトコードをロードする。バイトコードは、マシンコードに任意にコンパイルされ得る。例えば、defineClassメソッドは、バイトの配列をClassクラスのインスタンスにコンバートする。したがって、コンポーネントは、例えば、ある時点において計測を有しない状態から、別の時点において計測を有する状態へ移行するように、再定義することが可能である。また、コンポーネントは、例えば、ある時点において計測を有する状態から、別の時点において計測を有しない状態へ移行するように、再定義することも可能である。また、計測の異なる種類またはレベル、例えば、コンポーネントの実行について多くの側面が追跡される高いレベルの計測や、コンポーネントの実行についてほんの一部の側面しか追跡されない低いレベルの計測、を提供することも可能である。コンポーネントを再定義することは、このように異なるタイプの計測への移行を含むことがある。計測は、多くの種類のパフォーマンスメトリクス/データを生成することができ、それらには、コンポーネントの平均実行または応答時間、毎秒または間隔ごとの呼出し率、呼出し回数、開始したが終了していない間隔ごとの呼び出しの回数を示す同時実行のメトリック、呼び出しを開始した間隔ごとのメソッド呼び出しの回数が特定の閾値を超えた呼出し回数を示すストール状態のメトリックが含まれる。また、データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定する。データは、計測されたコンポーネントによってどのコンポーネントが呼ばれたか、または計測されたコンポーネントをどれが呼ぶか、を特定することもできる。例えば、コントローラのアーキテクチャにおいては、コンポーネントを制御するコントローラコンポーネント内の制御フローは、次に実行されて、どの程度の頻度で実行され、どのように実行されるかを知っている。1つのアプローチにおいては、削除されたプローブを有するコンポーネントのリスト908、および付加されたプローブを有するコンポーネントのリスト906は、次回システム100が起動して、同じコンポーネントが計測される/計測されないように持続され得る。換言すると、再起動しなければ静的解析図4のステップ402~404を参照によって判定されるであろうコンポーネントは、システムが再起動したとしても、そのすべてが再度静的に計測されることは要求されていない。コンポーネントは、コンポーネントがアプリケーションの実行時に既に組み込まれているか否かに応じて異なる方法で再定義されることができる。コンポーネントがアプリケーションにまだ組み込まれていない場合には、1つの可能な実装として、クラスローダ902によってJVMなどにロードされることで、正常に組み込まれ得る。例えば、NETフレームワークを使用するような他の実装においては、クラスローダは使用されない。コンポーネントがロードされると、命令がある場合には、例えば、付加されたプローブを有するコンポーネント906、および、削除されたプローブを有するコンポーネント908、に応じて、トランスフォーマ/プローブビルダ900がコンポーネントを計測する。アプリケーションに既に組み込まれているが未計測のコンポーネントは、計測を含んでアプリケーションに再組み込みされ得る。例えば、コンポーネントは、アプリケーションから削除することができるとともに、仮想マシンを再起動することなく実行中にリロードすることが可能である。これを達成するためには、JavaのredefineClassコマンドがコンポーネントによってクラスローダ902に提供される。Java開発キットJDKバージョン1.5またはそれ以降のバージョンがこのコマンドを使用する再定義機能を備えている。このコマンドは、提供されたクラスファイルを使用して提供されたクラスのセットを再定義する。それは、2つ以上のクラスを同時にインターロック変更させるためにセットで動作する。また、再定義されたメソッドがアクティブなスタックフレームを有している場合には、これらのアクティブなフレームが元のメソッドのバイトコードの実行を続行し、再定義されたメソッドが新しい呼び出しで使用される。コンポーネントを例えばクラスのように再定義することは、クラスだけであるが、仮想マシンを再起動することに類似している。クラスが再定義される場合、もしクラスが既存のメソッドスタックに存在するのであれば、クラスはそこにとどまる。しかし、すべての新しいメソッドが呼び出される場合には、新しいクラスが使用される。つまり、一旦、再定義されると、新しいバージョンがピックアップされる。トランスフォーマ/プローブビルダ900は、再定義されたコンポーネントを受信する場合、もしそうするように命令されていたのであれば、コンポーネントを計測する。上述のように、トランスフォーマ/プローブビルダ900は、コンポーネントの計測を削除することも可能である。トランスフォーマ/プローブビルダ900は、またコンポーネントに特定の種類の計測を付加することも可能である。計測の付加および削除は実行時に動的に行われるので、バイトコードを実行している仮想マシンはダウンさせる必要はなく、計測されたコンポーネントからのデータは直ちにアクセスされ得る計測を追加する場合。本明細書に開示される一実施形態は、複数のコンポーネントを有するアプリケーションを計測するためのコンピュータに実装される方法を含む。この方法は、どのコンポーネントの内部にプローブを配置するかを判定するためにアプリケーションを自動的に解析すること;判定されたコンポーネントに自動的にプローブを付加すること;アプリケーションが実行している間にプローブからデータを受信すること;データに基づいて最初のコンポーネント内の最初のプローブに対して1以上のメトリックを決定すること;最初のプローブの1以上のメトリックに基づいて、最初のプローブを修正するか否かを判定すること;1以上のメトリックの決定と付加的なプローブに対する修正を行うか否かの判定とを繰り返す、マシンに実装されたステップを含む。本明細書に開示される一実施形態では、アプリケーションを計測するための方法を実行する、少なくとも1つのプロセッサをプログラムするためのコンピュータで読み込み可能な格納された命令を有する、コンピュータで読み取り可能な記憶装置を含む。この方法は:プローブを配置するためのアプリケーション内の場所を判定するためアプリケーションを静的に解析すること;アプリケーションの判定された場所にプローブを静的に付加すること;アプリケーションが実行している間にプローブによってデータを収集すること;データに基づいて最初のプローブの1以上のメトリックを判定すること;最初のプローブの1以上のメトリックに基づいて、アプリケーションから最初のプローブを削除するか否かを判定すること;最初のプローブの1以上のメトリックに基づいて、最初のプローブをアプリケーション内の別の場所に移動するか否かを判定すること;1以上のメトリックの判定、アプリケーションからプローブを削除するか否かの判定および付加的なプローブのためにプローブを別の場所に移動するか否かの判定、を繰り返すること、を含む。本明細書に開示される一実施形態は、1以上のプロセッサを有するシステム;および1以上のプロセッサに結合されているコンピュータで読み取り可能は記憶装置を含む。コンピュータで読み取り可能な記憶装置は、コンピュータで読み取り可能な格納された命令を有し、1以上のプロセッサ上で実行すると、この1以上のプロセッサに複数のコンポーネントを有するアプリケーションを計測させる。1以上のプロセッサは:aどのコンポーネントの内部にプローブを静的に配置するかを判定するためにアプリケーションを自動的に解析し;bアプリケーションが実行していない間に、判定されたコンポーネントのアプリケーションにプローブを自動的に付加し;cアプリケーションが実行されている間にプローブからデータを受信し;dデータに基づいて、最初のコンポーネント内の最初のプローブに対して1以上のメトリックを判定し;e最初のプローブの1以上のメトリックに基づいて、アプリケーション内の別のコンポーネントに最初のプローブを移動するか否かを判定し;f前記eの判定がそのように示す場合、アプリケーションが実行している間にアプリケーション内の別のコンポーネントに最初のプローブを移動し;g最初のプローブの1以上のメトリックに基づいて、アプリケーションから最初のプローブを削除するか否かを判定し;h前記gの判定がそのように示す場合、アプリケーションが実行している間にアプリケーションから最初のプローブを削除し;およびi付加的なプローブのために前記dから前記hを繰り返す。コンピューティング環境でソフトウェアを監視する技術を説明した。本記載は、アプリケーションを計測するための2パス技術を提供する。1つのパスは、アプリケーションが実行されていない間にアプリケーションを解析しプローブを挿入することによって静的に実行される。もう1つのパスは、アプリケーションがプローブのメトリックを導出するために実行している間、プローブにより収集されたデータを解析することによって動的に実行される。各プローブの1以上のメトリックは、プローブを動的に修正するか否かを判定するために解析され得る。プローブは動的に修正されるので、アプリケーションはシャットダウンされる必要はない。プローブを動的に修正することは、例えば、プローブをアプリケーションから削除すること、またはプローブをアプリケーション内の別のコンポーネント例えば、メソッドに移動することであり得る。例えば、プローブは、プローブが現在、存在しているコンポーネントよりもコールグラフ上で上位または下位のいずれかのコンポーネントに移動され得る。以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。"