(57)【要約】【課題】  １つまたは複数の処理デバイス上で動作するコンポーネントベースソフトウェアシステムの監視方法および装置を提供する。【解決手段】  この方法は、第１のソフトウェアコンポーネントの実行内部からの第２のソフトウェアコンポーネントの起動を開始するステップを含む。第２のソフトウェアコンポーネントの起動前に、スタブ開始ログデータが、インスツルメントされたスタブで記録される。第２のソフトウェアコンポーネントの起動からの応答が受信された後に、スタブ終了ログデータが、インスツルメントされたスタブで記録される。これらのスタブ開始ログデータおよびスタブ終了ログデータは、コンポーネントベースソフトウェアシステム内の第２のソフトウェアコンポーネントの実行に関するランタイム情報を収集する。
2005527008.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数の処理デバイス上で動作するコンポーネントベースソフトウェアシステムの監視方法であって、
第１のソフトウェアコンポーネントの実行内部から第２のソフトウェアコンポーネントの起動を開始するステップと、
前記第２のソフトウェアコンポーネントの前記起動前にインスツルメントされたスタブのスタブ開始ログデータを記録するステップと、
前記第２のソフトウェアコンポーネントの前記起動から応答を受信した後に、前記インスツルメントされたスタブのスタブ終了ログデータを記録するステップと、
を含み、
前記スタブ開始ログデータおよび前記スタブ終了ログデータは、前記コンポーネントベースソフトウェアシステム内の前記第２のソフトウェアコンポーネントの実行に関するランタイム情報を収集する
監視方法。
【請求項２】
インスツルメントされたスケルトンの実行内部から前記第２のソフトウェアコンポーネントの前記起動を開始するステップと、
前記インスツルメントされたスケルトンが前記第２のソフトウェアコンポーネントを起動する前にスケルトン開始ログデータを記録するステップと、
前記第２のソフトウェアコンポーネントの前記起動から応答を受信した後に、前記インスツルメントされたスケルトンにスケルトン終了ログデータを記録するステップと
をさらに含む請求項１に記載の監視方法。
【請求項３】
特定のインスツルメントされたスタブは、対応するインスツルメントされたスケルトンのデータログ記録機能を有効および無効にできる
請求項２に記載の監視方法。
【請求項４】
前記スタブ開始ログデータ、前記スタブ終了ログデータ、前記スケルトン開始ログデータおよび前記スケルトン終了ログデータは、前記第１のソフトウェアコンポーネントと前記第２のソフトウェアコンポーネントとの間の因果関係データを捕捉する
請求項２に記載の監視方法。
【請求項５】
前記スタブ開始ログデータ、前記スタブ終了ログデータ、前記スケルトン開始ログデータおよび前記スケルトン終了ログデータは、複数のスレッドの因果関係データを求めるために使用される
請求項２に記載の監視方法。
【請求項６】
前記スケルトン開始ログデータおよび前記スケルトン終了ログデータに含まれるログデータの内容を選択する予備ステップをさらに含み、該選択するステップは、タイミング待ち時間データ、共有資源使用量データ、および因果関係データの１つ以上のものをログ記録するか、または、いずれもログ記録しない
請求項２に記載の監視方法。
【請求項７】
前記監視方法は、前記インスツルメントされたスタブの前記スタブ開始ログデータの少なくとも一部を前記インスツルメントされたスケルトンに搬送することを含む
請求項２に記載の監視方法。
【請求項８】
動的メモリ割り当て要求および割り当て解除要求を傍受して、該要求からヒープメモリ使用量データをログ記録するステップ
をさらに含む請求項２に記載の監視方法。
【請求項９】
コンポーネントベースソフトウェアアプリケーションの監視に適合したコンピュータシステムであって、
該コンピュータシステムに存在する少なくとも１つの処理デバイスと、
前記少なくとも１つの処理デバイスに存在し、該コンピュータシステム内で実行可能な１つまたは複数ソフトウェアコンポーネントと、
前記１つまたは複数のソフトウェアコンポーネントの１つまたは複数のインスツルメントされたスタブであって、第１のソフトウェアコンポーネントにおいて該インスツルメントされたスタブの実行起動時にスタブ開始ログデータを記録でき、かつ、該インスツルメントされたスタブの実行終了時にスタブ終了ログデータを記録できる、１つまたは複数のインスツルメントされたスタブと
を備えるコンピュータシステム。
【請求項１０】
１つまたは複数のインスツルメントされたスケルトンであって、第２のソフトウェアコンポーネントにおいて該インスツルメントされたスケルトンの実行起動時にスケルトン開始ログデータを記録でき、該インスツルメントされたスケルトンの実行終了時にスケルトン終了ログデータを記録できる１つまたは複数のインスツルメントされたスケルトン
をさらに備える請求項９に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
［発明の分野］
本発明は、包括的には、分散コンピュータシステムのランタイム監視に関し、詳細には、コンポーネントベース分散システムのランタイム監視に関する。
【背景技術】
【０００２】
［発明の背景］
ソフトウェアコード開発の重要な部分は、デバッガおよびプロファイリングツールを使用して、ソフトウェアシステムが実行していることを理解することである。
通常、デバッガ（例えば、Microsoft Corporationが提供しているＭｉｃｒｏｓｏｆｔ  Ｖｉｓｕａｌ  Ｓｔｕｄｉｏまたはフリーソフトウェア財団が提供しているｇｄｂ）は、プログラムを異常な結果に至らせたプログラム内の論理的欠陥を診断するのに使用される。
例えば、因果トレースおよび呼び出しスタックは、プログラムデバッガから導き出される値の本質的部分である。
プロファイリングツール（例えばｇｐｒｏｆ（共通のＵｎｉｘ（登録商標）ツール）、Ｐｕｒｉｆｙ（Rational Corporationが提供）、およびＱｕａｎｔｉｆｙ（同じくRational Corporationが提供））は、プログラムがそのタスクをどのように完了したか（例えば、どれだけのメモリ量を使用したか、時間のほとんどをプログラムのどこで費やしたか、またはシステム／ネットワークリソースをどのように使用したか）についての詳細を捕捉するのに使用される。
プログラムのタイミング挙動およびリソースの利用の統計的分析は、プログラムプロファイリングツールの重要な要素である。
このように、デバッグツールは、一般に、プロファイリングツールが性能メトリックをチェックするために使用されている間の機能の正しさおよび原因の診断をチェックするために使用される。
【０００３】
最近まで、ほとんどのプログラムは、シングルスレッド・シングルプロセス実行（１つだけの実行スレッドがアプリケーション内で実行され、そのアプリケーションはシングルプロセッサで実行されることを意味する）として知られているプログラミングモデルで記述されていた。
１９８０年代中ごろには、分散システムとして知られている新しいクラスのプログラムが現れた。
これらのシステムは、複数の制御スレッドを有し、複数のプロセッサ／コンピュータ間で実行される傾向があるので、デバッグおよび理解が難しいことで有名であった。
既存のデバッガよびプロファイラは、この分散マルチスレッドプログラミングモデルには適していなかった。
【０００４】
１９８０年代のこの新しいクラスのプログラムの後押しで、新しいツールが、分散デバッガおよび分散システムプロファイラの分野に現れ始めた。
これらのツールは、アプリケーションレベルログ記録ツール、バイナリ書き換えツール（binary rewriting tools）、スレッド単位デバッガツール（debugger-per-thread tools）、ネットワーク／ＯＳメッセージログ記録ツール、およびインスツルメントされた仮想マシンツール（instrumented virtual-machine tools）として分類することができる。
【０００５】
アプリケーションレベルログ記録ツールは、基本的には、ｐｒｉｎｔｆ（）ログを生成するアプリケーションコードに組み込まれたマクロを使用することであった。
これらのツールの主な不都合は、ログ記録を意図してソースコードを記述しなければならないということであった（すなわち、開発者は、重要なイベントでログを意識的に追加しなければならない）。
アプリケーションレベルログ記録技法を変形したものが、バイナリ書き換え技法である。
Ｑｕａｎｔｉｆｙ（Rational Corporationが提供）は、バイナリ書き換えツールの一種である。
このツールは、バイナリプログラムの基本ブロック（基本ブロックは、非分岐コードのユニットである）の命令をカウントすることを挿入することにより、アプリケーションコードを書き換える。
Ｑｕａｎｔｉｆｙは、マルチプロセスアプリケーション上では動作せず、プロセス／スレッド間の因果の連関を発見することができない。
Ｐａｒａｄｙｎツール（マディソンのウィスコン大学が提供）は、バイナリ書き換えシステムではあるが、ログメッセージの選択除去も自動的にできないし、分散システムのプロセス間（またはスレッド間）の因果関係の追跡も自動的にできないという不都合を有する。
ＡＩＭＳ（NASA Ames Research Centerが提供するＡｕｔｏｍａｔｅｄ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ  ａｎｄ  Ｍｏｎｉｔｏｒｉｎｇ  Ｓｙｓｔｅｍ）は、ログエントリポイントを挿入するソース書き換えシステムである。
しかしながら、ＡＩＭＳも、スレッド間でイベントを関連付けないし、プロセス間の因果の連関（すなわち、イベントがなぜ発生したか）も提供しない。
【０００６】
スレッド単位デバッグツールは、分散システムにおいてプロセスあたりのデバッグウィンドウを提供する。
これらのツールには、２つの重要な不都合が存在する。
第１の不都合は、どの大規模システムにもスクリーンの場所（screen real-estate）が取られるということであり、第２の不都合は、プロセス間を関連付けることができないということである（すなわち、あるプロセスを特定の状態にしたものを見分けることもできないし、誰がメッセージを送ったかを見分けることもできない）。
【０００７】
ネットワーク／ＯＳメッセージログ記録ツールは、ネットワークパケット（およびオペレーティングシステムのイベント）を傍受することにより、ネットワークトラフィックを監視するものである。
このようなツールの例としては、Sun MicrosystemのＴＨＲＥＡＤＭＯＮおよびHewlett-PackardのＤＥＳＫＴＯＰ  ＭＡＮＡＧＥＭＥＮＴ  ＩＮＴＥＲＦＡＣＥがある。
これらのツールは、特に、プロセスが消費する帯域幅の問題またはＣＰＵの量を特定するのに役立つ。
しかしながら、これらのツールは、ネットワークパケット（またはオペレーティングシステム呼び出し）をアプリケーションに意味のあるイベントに変えることが非常に困難である（すなわち、通常、パケットのバイトを得るだけであり、そのパケットのバイトが送信された理由を解釈する容易な方法も、そのパケットが引き起こそうとしていることを解釈する容易な方法も得られない）。
【０００８】
最後に、インスツルメントされた仮想マシン手法では、複数のＪａｖａ（登録商標）仮想マシンにまたがるアプリケーションを監視するためのＪＡＶＡＶＩＺ（ＪＡＶＩＺとも呼ばれ、ミネソタ大学が提供）のようなシステムがある。
この手法の主な不都合は、Ｊａｖａ仮想マシンに拘束されることであり、複数の言語も複数のプラットフォームも混合できないということである。
【０００９】
上記手法のすべてについて、主な不都合は、スレッドおよびプロセス間の因果チェーンを追跡できないこと、その手法が押し入ること（すなわち、ソースコードへの変更が必要となること）、およびアプリケーションに意味のあるイベントに対して資源の利用（例えば、ＣＰＵ、メモリ、帯域幅、時間）を追跡できないことである。
【００１０】
既存のプログラム開発環境は、マルチスレッドマルチプロセスの分散システムのデバッグ、監視、および特徴付けを行うには十分ではない。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
したがって、当技術分野には、分散ソフトウェアアプリケーションのランタイム監視を改良する必要が残されている。
【課題を解決するための手段】
【００１２】
［発明の概要］
本方法は、インスツルメントされたソフトウェアアプリケーションのＩＤＬインターフェースに基づくインスツルメントされたスタブおよびスケルトンを使用する。
したがって、本方法は、スタブの開始時、スタブの終了時、スケルトンの開始時、およびスケルトンの終了時にデータを収集する。
また、本方法は、メモリの割り当て／割り当て解除に関するデータ、ならびに、スレッドの生成および破壊に関するデータも収集する。
したがって、本発明による監視方法は、１つまたは複数の呼び出し側／被呼び出し側の境界に意味的にまたがるスレッドの集まりのグローバル因果識別子を生成することができる。
これには、スレッドの関係の追跡を可能にし、さらに、その関係を追跡するために収集データの順序付けを可能にするローカルイベント番号をインクリメントすることが含まれ得る。
さらに、スレッドの親および子の関係が、その関連付けられたローカルスレッド識別子を対にすることによって捕捉される。
グローバル因果識別子、イベント番号、親および子のスレッド識別子の対、ならびにインスツルメントされたスタブプローブおよびスケルトンプローブが、本発明により使用されて、システム全体の因果チェーンが算出され、コンポーネントベースソフトウェアシステム内で実行されるソフトウェアコンポーネントのエンドツーエンドの待ち時間、ＣＰＵ使用量、および全メモリ使用量が算出される。
【００１３】
１つまたは複数の処理デバイス上で動作するコンポーネントベースソフトウェアシステムの監視方法が、本発明の一実施の形態に従って提供される。
この方法は、第１のソフトウェアコンポーネントの実行内部からの第２のソフトウェアコンポーネントの起動を開始するステップを含む。
第２のソフトウェアコンポーネントの起動前に、スタブ開始ログデータが、インスツルメントされたスタブで記録される。
第２のソフトウェアコンポーネントの起動からの応答が受信された後に、スタブ終了ログデータが、インスツルメントされたスタブで記録される。
これらのスタブ開始ログデータおよびスタブ終了ログデータは、コンポーネントベースソフトウェアシステム内の第２のソフトウェアコンポーネントの実行に関するランタイム情報を収集する。
本監視は、複数のスレッドの全体にわたるログデータ、複数のプロセスの全体にわたるログデータ、および複数のプロセッサの全体にわたるログデータを収集することができる。
これらのログデータを検索および分析して、タイミング待ち時間情報、共有資源使用量情報、アプリケーションセマンティックス情報、および因果関係情報を生成することができる。
【発明を実施するための最良の形態】
【００１４】
［詳細な説明］
＜定義＞
分散システムは、１つまたは複数のネットワークもしくはネットワークリンクによって相互接続されるコンピュータまたはコンピュータデバイスの緩やかな構成である。
分散システムは、互いに遠隔にあるデバイスを備えることができる。
分散システム上のデバイスは、当該デバイス間でデータを転送することができ、他のデバイス上のアプリケーションを呼び出して実行することができる。
これは、コンポーネントベースソフトウェアに特に当てはまる。
このコンポーネントベースソフトウェアでは、ソフトウェアアプリケーションは、各コンポーネントが、特定のタスクを実行し、かつ、明確なインターフェースに従って動作する複数のコンポーネントからなる。
【００１５】
コンポーネントベースソフトウェアシステムは、対話するソフトウェアコンポーネントの組からなる構成物であり、それらのソフトウェアコンポーネントのそれぞれは、他のソフトウェアコンポーネントからのサービスを提供し、要求する。
各コンポーネントは、明確なインターフェースを有し、このインターフェースによって、コンポーネントは、そのインターフェースを他のコンポーネントにエクスポーズする。
したがって、コンポーネントのインターフェースは、他のコンポーネントにサービスを提供するのに使用でき、サービスを得るために他のコンポーネントによって使用される。
コンポーネントベースシステムでは、ユーザ定義のソフトウェアアプリケーションが、サービスをエクスポートするために、そのコンポーネントを実施する方法を定義し、また、他のコンポーネントが提供するサービスを受け取って使用する方法も定義する。
分散システムが、オブジェクト指向形式で実施されている場合、ソフトウェアコンポーネントは、オブジェクトとして作成され、このようなサービスの提供および要求は、そのソフトウェアコンポーネントに関連付けられたオブジェクトメソッドの起動を通じて行われる。
したがって、関連したコンポーネントを組み立てることによりアプリケーションを作成することができる。
【００１６】
コンポーネントベースシステムは、基礎となるリモートプロシージャ呼び出しモデル上に構築される（すなわち、リモートコンポーネントの起動が、あたかもローカルなライブラリまたはオブジェクトに対するものであるかのように見える）。
この抽象レイヤは、呼び出し側ではスタブオブジェクト／ルーチンを使用し、呼び出される側ではスケルトンオブジェクト／ルーチンを使用することにより実現される。
スタブは、起動を、リモートのスレッド（またはプロセス）へのメッセージに変換する一方、スケルトンは、メッセージを、最初に対象にされたコンポーネントに対するローカルな起動に変換する。
スタブおよびスケルトンは、多くの異なる方法を使用して作成することができるが、これらの要素は、コンポーネントのインターフェースの形式的記述から作成することが一般的である。
この形式的記述は、インターフェース定義言語（ＩＤＬ（Interface Definition Language））で指定される。
ＩＤＬインターフェースは、オペレーション、例外、および属性の組を宣言する。
各オペレーションは、少なくともその名前、そのパラメータ、その結果、およびその例外を定義するシグネチャを有する。
【００１７】
例外は、アプリケーションの実行中に発生する操作上のエラー（すなわち、ランタイム実行エラー）である。
例外は、一般的に、データ処理が、ある方法で処理パラメータに違反したことを示す。
典型的な例外は、例えば指定された値の範囲に整合しない関数の起動の入力の場合である。
【００１８】
ソフトウェアアプリケーションを分散システム上で呼び出して実行することができる。
このアプリケーションは、あるコンピュータデバイス上に存在することができ、そのデバイスが呼び出して実行することもできるし、分散ネットワーク上の他のデバイスが呼び出して実行することもできる。
ソフトウェアアプリケーションは、複数の異なるソフトウェアコンポーネントに対する複数の関数呼び出しを生成することができ、さまざまな型のデータを処理することができる。
【００１９】
オブジェクトは、オペレーションおよびデータをモジューラユニットに計算上グループ化したものである。
オブジェクトは、自身が他のオブジェクトに提示するインターフェースと、そのインターフェースのオペレーションが起動される時の自身の挙動と、自身の状態とによって定義される。
オブジェクトは、通常、分散アプリケーション内のサブシステムが、同じ分散アプリケーションの他のサブシステムとシームレスに動作する方法を記述するために使用される。
オブジェクトのこの目的により、分散アプリケーションをオブジェクト指向形式で設計することが可能になる。
【００２０】
スレッドは、プロセス内のプログラムコードの独立した実行シーケンスである。
スレッドは、実行エンティティであり、この実行エンティティを通じて、関数の起動が実行される。
１つまたは複数のスレッドが、関数呼び出しによって引き起こされ、関数呼び出しに関係付けられる。
スレッドは、他のスレッドを発生させることができ、複数のスレッドが、分散システム上に同時に発生することができる。
【００２１】
この発明では、関数は、コンポーネントＩＤＬ仕様、すなわち、ソフトウェアコンポーネントの境界にまたがった呼び出しで定義されるオペレーションである。
関数は、実行されると、特定のデータ操作を実行する。
例えば、印刷を行うには、印刷関数を呼び出して、この印刷関数にデータを与えることができる。
この印刷関数は、データを処理して、データを適切な形式にすることができ、また、特定のプリンタドライバを選択することができる。
呼び出し側および被呼び出し側は、同じプロセスに位置することもできるし、分散システムの別のプロセスに位置することもできる。
関数の呼び出し側および被呼び出し側が、同じプロセスに位置しない場合には、その対応する関数の起動は、リモート起動と呼ばれる。
ソフトウェアコンポーネントは、関数の組からなり、関数のそれぞれは、定義された関数インターフェースを有する。
【００２２】
アプリケーションセマンティックスは、ソフトウェアアプリケーションのランタイム動作の挙動を記述する用語である。
アプリケーションセマンティックスは、ランタイム情報、例えば、どの関数が他のどの関数を呼び出したか、関数の起動の事前状況および事後状況は何であるか、例外が関数実行中になぜ発生したかなどを含むことができる。
【００２３】
共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ（Common Object Request Broker Architecture））は、オブジェクト管理グループ（Object Management Group）（共同利用できるエンタープライズアプリケーション用のコンピュータ産業仕様を提供し、保守するオープンメンバーシップの非営利団体）によって作成された分散オブジェクト通信の標準である。
ＣＯＲＢＡは、複数のベンダが提供するオペレーティングシステムプラットフォームを接続するための最も広く使用されている分散オブジェクトの標準である。
ＣＯＲＢＡ仕様は、インターフェース定義言語（ＩＤＬ）を含む。
このインターフェース定義言語は、分散アプリケーションとしての実施に向けてオブジェクト間の規約を生成する、言語から独立した手段である。
【００２４】
リモートメソッド起動（ＲＭＩ（Remote Method Invocation））は、別のアドレス空間に存在するオブジェクトのメソッドの起動を可能にするメカニズムである。
この別のアドレス空間は、同じコンピュータデバイス上に存在してもよいし、別のコンピュータデバイス上に存在してもよい。
ＲＭＩメカニズムは、ＣＯＲＢＡと同様のオブジェクト指向メカニズムである。
【００２５】
Ｍｉｃｒｏｓｏｆｔ  ＣＯＭ／ＤＣＯＭクライアント（コンポーネントオブジェクトモデル／分散コンポーネントオブジェクトモデル）は、ネットワーク内のシステム全体にわたってＣＯＭオブジェクトを分散させて使用するためのMicrosoftの仕様である。
ＣＯＭ／ＤＣＯＭクライアントを使用すると、サーバに要求を行うことができる。
ＣＯＭ／ＤＣＯＭクライアントは、ビジュアルベーシック、Ｃ＋＋、Ｐｅｒｌ、またはＷＩＮＤＯＷＳ（登録商標）環境の他の言語で記述することができる。
【００２６】
＜説明の本体＞
図１は、本発明の一実施の形態による分散コンピュータシステム１００の図である。
この分散システム１００は、監視オペレーション下にあるマルチスレッドソフトウェアシステムである。
分散システム１００上で実行されるアプリケーションは、複数のプロセスに分割して、異なるマシンに配置し、異なるオペレーティングシステム（例えば、Ｗｉｎｄｏｗｓ  ＮＴ、ＨＰ  Ｕｎｉｘ、ＶｘＷｏｒｋｓなど）によってサポートすることができる。
分散システム１００は、プロセス１０１、１０２、および１０３といった複数のプロセスを含む。
これらのさまざまなプロセスは、１つまたは複数のネットワークまたは他のリンクによってリンクされる。
各プロセスは、ログファイル、例えばログ記憶ファイル１１３、１１４、および１１５にランタイム情報を記憶することができる。
監視情報が、フロントエンドプレゼンテーションインターフェース１１９によってユーザに表示される。
【００２７】
１つまたは複数のコンピュータデバイスが、例えばプロセス１０１、１０２、および１０３といった複数のプロセスのホストとなって、これらのプロセスを実行することができる。
これらのプロセスは、分散システム１００内で実行されるソフトウェアアプリケーションによって生成することができる。
各プロセスは、１つまたは複数のスレッドを生成することができる。
さらに、個々のプロセス／スレッドは、別のプロセス／スレッドを追加して生成することができる。
特定のログデータが、各関数呼び出し起動のために作成される。
【００２８】
図２は、本発明の一実施の形態による監視方法のフローチャート２００である。
ステップ２０２で、（第１のソフトウェアコンポーネントの）ソフトウェア関数呼び出し起動が、監視されるアプリケーションで行われる。
監視されるアプリケーションは、コンポーネント技術（例えば、ＣＯＲＢＡ、ＲＭＩ、ＣＯＭ／ＤＣＯＭなど）を使用して構築されて、分散システム１００内で実行される任意のタイプのオブジェクトベースソフトウェアアプリケーションとすることができる。
【００２９】
ステップ２０７で、第１のソフトウェアコンポーネントは、第２のソフトウェアコンポーネントを始動することができる。
すなわち、分散システム１００上で実行されるソフトウェアコンポーネントは、他のソフトウェアコンポーネントを呼び出して始動することができる。
呼び出しは、兄弟型呼び出しであってもよい。
この兄弟型呼び出しでは、第１のソフトウェアコンポーネントが、第２のソフトウェアコンポーネントへの関数呼び出しを起動して、関数の復帰を待ち、次いで、別の関数呼び出しを、第２のソフトウェアコンポーネントに再び発行するか、または、システム内の他のソフトウェアコンポーネントに発行する。
あるいは、この呼び出し起動は、子関数へのネスト呼び出しであってもよい。
このネスト呼び出しでは、第１のソフトウェアコンポーネントが、第２のソフトウェアコンポーネントへの関数呼び出しＦを起動し、次に、第２のソフトウェアコンポーネントが、Ｆの実行を行っている間に他のソフトウェアコンポーネントへの１つ（または２つ以上）の関数呼び出しを起動する。
その結果、ネスト呼び出しの状況では、第１のソフトウェアコンポーネントが完了して復帰する前に、第２のソフトウェアコンポーネントの起動、完了（すなわち実行）、および復帰を行うことができる。
【００３０】
第１のソフトウェアコンポーネントは、必ずしも他のソフトウェアコンポーネントを起動しなくてもよいことが理解されるべきである。
しかしながら、後続するソフトウェアコンポーネントが起動されると、本発明による監視方法は、コンポーネント間の因果関係を追跡してログに記録することができ、分散システム１００内のソフトウェアコンポーネントの実行の完全な描写を可能にする。
【００３１】
プロセスのあらゆる関数呼び出しをログに記録するのとは異なり、本発明の好ましい実施の形態は、そのコンポーネントのＩＤＬ記述レベルで、アプリケーションに意味のあるイベントをインスツルメントする。
このように、過度のログ記録のオーバーヘッドなしに、コンポーネント間の因果関係を特定することができる。
別の実施の形態では、コンポーネントの動作の挙動に対して内部の他のイベントが、ログに記録され、ＩＤＬで宣言されたインターフェースレイヤでログに記録されて関連付けられたイベントと共に関連付けられる。
【００３２】
ステップ２３１では、スタブ開始（第１の）ログデータが、インスツルメントされたスタブによって記録される。
このスタブ開始ログデータは、インスツルメントされたスタブによって発行された第１のソフトウェアプローブ（すなわちプローブ１）から得られる。
インスツルメントされたスタブは、第２のソフトウェアコンポーネントのＩＤＬインターフェース記述から生成される。
これは、基礎となるインフラストラクチャから独立し、かつ、基礎となる通信プロトコルから独立した方法で第１のソフトウェアコンポーネントと第２のソフトウェアコンポーネントとの間でデータを搬送できるように行われる。
インスツルメントされたスタブは、第２のソフトウェアコンポーネントのＩＤＬコンパイル中に生成することができる。
スタブ開始ログデータは、インスツルメントされたスタブが、第２のソフトウェアコンポーネントにメッセージを送信する前、すなわち、インスツルメントされたスタブが、インスツルメントされたスケルトンを起動する前に、記録される。
スタブ開始ログデータは、図３と共に以下に説明するいくつかの異なるデータ型を記録することができる。
【００３３】
ステップ２３６では、スケルトン開始（第３の）ログデータが、インスツルメントされたスケルトンによって記録される。
このスケルトン開始ログデータは、第３のソフトウェアプローブ（すなわちプローブ３）から得られる。
インスツルメントされたスケルトンは同様に、第２のソフトウェアコンポーネントのＩＤＬインターフェース記述から生成される（図３を再度参照）。
【００３４】
ステップ２４０で、スケルトン終了（第４の）ログデータが記録される。
このスケルトン終了ログデータは、第４のソフトウェアプローブ（すなわち、プローブ４）から得られる。
スケルトン終了ログデータは、インスツルメントされたスケルトンの実行終了時に、インスツルメントされたスケルトンによって生成される。
このステップでは、スケルトン終了ログデータは、ほぼ実行終了時であって、インスツルメントされたスタブに復帰する時に記録される。
この復帰は、インスツルメントされたスタブへの関数の結果の復帰値を含むことがある。
第１のソフトウェアコンポーネントから起動される関数の実施は、第２のソフトウェアコンポーネントの境界内に含まれる。
【００３５】
ステップ２４５では、スタブ終了（第２の）ログデータが、インスツルメントされたスタブによって記録される。
このスタブ終了ログデータは、第２のソフトウェアプローブ（すなわち、プローブ２）から得られる。
スタブ終了ログデータは、第２のソフトウェアコンポーネントから応答が受信された後に記録される。
【００３６】
フローチャート２００は、第２のソフトウェアコンポーネントの始動があらゆるデータのログ記録前に行われる場合を示しているが、別法では、スタブ開始ログデータ／プローブ１の記録後に第２のソフトウェアコンポーネントを始動できることが理解されるべきである。
【００３７】
この図は、４つのログデータ項目の捕捉および記録を示しているが、これよりも少ない個数を使用できることに留意すべきである。
例えば、本発明による監視は、インスツルメントされたスタブのみを使用することもできるし、スタブ開始ログデータおよびスタブ終了ログデータのみを記録することもできるし、さらにデータのログ記録を行わないこともできる。
これは、いくつかの理由から行われることがある。
この理由には、ログ記録されるデータ量の削減、および、因果関係を十分に捕捉する必要がないログ記録シナリオが含まれる。
【００３８】
好ましい実施の形態では、ログイベントは、次のデータ型、すなわちタイミング待ち時間データ、アプリケーションセマンティック挙動データ、共有資源使用量データ、および因果関係データの１つ以上をログ記録することもできるし、いずれも記録しないこともできる。
個々のデータ型は、図３にと共に以下に解説する。
【００３９】
本発明の監視方法は、インスツルメントされたスタブおよびインスツルメントされたスケルトンをＩＤＬ記述から生成するのに好都合である。
したがって、本発明は、ＩＤＬ／インターフェースレイヤで監視を実行する（すなわち、本発明は、システム内で発生するすべての関数呼び出しを記録するとは限らず、逆に、コンポーネントの境界で発生する関数呼び出しのみを記録する）。
好ましい実施の形態では、すべてのログが、ＩＤＬレイヤに存在するものである。
別の実施の形態では、付加的なログエントリを追加でき、ＩＤＬレイヤでログ記録された原因のイベントと関連付けることができる。
本発明は、セマンティックス上意味のあるイベント（すなわち、ＩＤＬ関数名）のログ記録と、その呼び出しのログパラメータ化（メッセージベースシステムで行うのは非常に困難）のログ記録とを行うことができ、かつ、因果関係を追跡できるように、ＩＤＬレイヤを活用する。
これは、プロセス間で送信される最低レベルのメッセージをログ記録して、分析するワイヤログ記録メカニズム（wire-logging-mechanisms）を上回る重要な利点である。
【００４０】
本発明のデータ収集は、応答されないメッセージの傍受または資源要求の傍受に基づくことができる従来技術の監視手法とは異なる（これらの従来技術の手法の双方は、再考の余地があり、プロセスの完了も、そのプロセスが原因で発生したプロセスの完了も追跡できない）。
したがって、本発明は、従来技術と異なり、分散システム１００内のソフトウェアアプリケーションの動作を十分に特徴付けることができる。
インスツルメントされたスタブおよびインスツルメントされたスケルトンは、そのスタブおよびスケルトンの開始イベントおよび停止イベントのログ記録を実行し、したがって、関数の起動および実行の開始ならびに終了を捕捉する。
これは、タイミング待ち時間データを個々のソフトウェアコンポーネントに提供することができる。
インスツルメントされたスケルトンを使用することにより、原因となるリンクされたあらゆるソフトウェアアプリケーションおよび関数のタイミング待ち時間も捕捉することができる。
【００４１】
分散システム１００は、インスツルメントされたソフトウェアコンポーネントおよびアプリケーションならびにインスツルメントされていないソフトウェアコンポーネントおよびアプリケーションの双方を含むことができるが、監視は、インスツルメントされたソフトウェアコンポーネントに対してのみ実行される。
【００４２】
さらに、本発明は、ログデータの内容のカスタム化を可能にするのに好都合である。
ログデータの内容には、例えば、アプリケーションセマンティック（application semantic）挙動データ、タイミング待ち時間データ、共有資源使用量データ、および因果関係データが含まれ得る（明細書に添付した図３を参照）。
本発明による監視により、ログデータの内容のカスタム化が可能になり、さらに、各ソフトウェアプローブのログデータの内容を独立に選択することが可能になる。
したがって、プローブ１によって記録されたログデータの内容は、例えばプローブ２によって記録されたログデータの内容と異なることがある。
その上、インスツルメントされたスタブおよびインスツルメントされたスケルトンの個々のソフトウェアは、必要に応じて、空にすることができ、ログデータを生成しないこともできる。
【００４３】
さらに、特定のインスツルメントされたスタブは、対応するインスツルメントされたスケルトンのデータログ記録機能の有効および無効を可能にすることができる。
この機能により、メモリ使用量データのログ記録およびスレッド因果関係データのログ記録に対する制御が可能になる。
【００４４】
特定のソフトウェアアプリケーションのコンパイル中に、ログデータの内容を選択／指定することができる。
加えて、分散システム１００の通常動作中に、ログデータの内容を変更することができる。
これは、ＩＤＬインターフェースから独立した、ユーザ指定の正規表現によって行うことができる。
この正規表現は、コンパイル中の特定のソフトウェアコンポーネントに挿入することもできるし、あるいは、監視されるシステムが実行されている時に、ユーザによって提供することもできる。
正規表現が、実行中のイベントの変数によって照合されると、ログデータの内容は、変更可能となる。
【００４５】
一例として、この特定のソフトウェアコンポーネントは、関数呼び出しチェーンの特定のパターンを表す正規表現を含むことができる。
したがって、この特定の関数呼び出しチェーンが発生すると、正規表現が照合し、より深いログ記録をトリガすることができる。
このより深いログ記録は、例えば、タイミング待ち時間データおよび共有資源使用量データのログ記録からだけでなく、アプリケーションセマンティック挙動データおよび因果関係データのログ記録からのソフトウェアプローブも変更することを含むことができる。
したがって、あらかじめ定められた１つのイベントまたは複数のイベントが発生するまで、最小限のデータログ記録を実行することができ、あらかじめ定められたイベントの発生時に、より高いレベルのログ記録が始動される。
【００４６】
本発明の方法により、ユーザ定義のソフトウェアコンポーネントによって始動された因果チェーンを特徴付けることが可能になる。
これは、スタブとスケルトンとの間のグローバル因果識別子（Global Causal Identifier）を伝搬し、かつ、スタブイベントおよびスケルトンイベントのローカルな順序付けを、イベントシーケンスの番号付けと組み合わせて使用して、呼び出しチェーンの全体的な順序付けを与えることにより行われる。
したがって、ログデータを分析および記憶して、特定の因果チェーンの個々の特徴付けデータを提供することができる。
この特徴付けデータは、各スレッドの起動および実行に関するデータをさらに含むことができる。
その結果、監視は、スレッドを捕捉して特徴付けることができる。
さらに、監視方法は、クロスプロセス因果トレースを実現する。
このトレースでは、複数の処理デバイス上でプロセス全体にわたってスレッドをトレースすることができる。
その上、監視は、コードの再入実行を捕捉して関連付けることができる（すなわち、コードの単一の複製が複数のスレッドによって同時に実行される）。
加えて、インスツルメンテーションは、ローカルバイパス機能をサポートすることができる。
ローカルバイパスは、関数の呼び出し側および関数の被呼び出し側が同じアドレス空間（すなわち、同じプロセス内）に位置する場合に見られる性能向上を目標にしてユーザにより指定されるオプションである。
好ましい実施の形態では、すべての呼び出しは、対象がリモートであろうとローカルであろうと、それにかかわらず、スタブ／スケルトンの対を通って転送される。
ローカルバイパスの最適化は、（対象がローカルであるとき）スタブがすべてのログプローブを提供する場合に実行される。
これは、空のスケルトンを有するのと等価であるとみなすことができる。
これは、縮退した状態とみなすことができ、被呼び出し側の関数の起動は、スタブにおいて直接実行される。
インスツルメンテーションについて、縮退したインスツルメンテーションスタブにおける被呼び出し側の関数の起動の前および後で、元の第３のプローブ（スケルトンの開始に対応する）および第４のプローブ（スケルトンの終了に対応する）を配備することができる。
【００４７】
本発明の別の利点は、基礎となるコンポーネントベースシステムのランタイム発生スレッドを捕捉して特徴付けることなく、スレッドの因果関係を捕捉して特徴付けることができることである。
したがって、データログ記録は、ユーザ定義のソフトウェアアプリケーションのために生成されたスレッドと、分散システム１００の基礎となるコンポーネントベースシステムのランタイムインフラストラクチャのために生成されたスレッドとを区別する。
スレッドを対象のオペレーションへ実行のために渡す前に、スケルトンは、（そのスレッド特有の記憶装置またはグローバルテーブルを使用して）マーカを現在のスレッドに加える。
スレッドが、対象のオペレーションの間に明示的に生成されると、このマーカは、それらの子スレッドに伝搬されることになる。
したがって、マーカは、スレッドが、インフラストラクチャスレッドであるのか、アプリケーションスレッドであるのかを示す。
【００４８】
別の有利な特徴において、この監視方法は、分散システム１００内のメモリ資源使用量を傍受することができる。
したがって、インスツルメントされたスタブまたはスケルトンは、動的な（ヒープ）メモリ使用量を追跡するために、メモリ割り当て要求およびメモリ割り当て解除要求をグローバルに傍受して、これらの要求をログ記録することができる。
このグローバルなメモリトレースは、有効および無効にすることができ、このグローバルなメモリトレースによって、分散システム１００全体にわたったトレースが可能になる。
【００４９】
本発明の監視方法のさらに固有の特徴は、因果情報、および、より一般的には任意のインスツルメンテーションデータを、インスツルメントされたスタブからインスツルメントされたスケルトンに渡すことができるということである。
これは、関数呼び出しの追加パラメータとして行うことができる。
したがって、監視中の関数があたかも追加パラメータを有するように、ＩＤＬ記述を取り扱うことができる。
その結果、インスツルメントされたスタブは、インスツルメントされたスケルトンのログ記録を制御することができる。
その上、インスツルメントされたスタブは、上述したように、インスツルメントされたスケルトンのログ記録を有効または無効にすることができる。
【００５０】
さらなる利点では、インスツルメントされたスタブおよびインスツルメントされたスケルトンからの個々のデータログを、ローカルにバッファリングすることができ、永続的記憶装置に蓄積することができる。
この蓄積されたデータは、分散システム１００の挙動の特徴、または、分散システム１００内の特定のソフトウェアコンポーネントの挙動の特徴を決定するために、いつでも検査して関連付けることができる。
したがって、分散システム１００内の正常な挙動および異常な挙動を捕捉するために、進行中のデータのログ記録を後に処理して、ある順序にし、検査することができる。
【００５１】
図１を再び参照して、ログデータは、インスツルメントされたソフトウェアアプリケーションの実行中に生成され、ログ記憶ファイルに直接ログ記録することができる。
各プロセスは、（そのプロセスがソフトウェアプローブを含む場合には）結果として生成されるログデータをログ記憶装置１１３、１１４、および１１５にローカルにログ記録する。
あるいは、ログデータは、メモリ内のプロセス単位のバッファにバッファリングされてもよい。
このバッファリングされたデータは、あらかじめ定められたある時点、例えば、バッファがいっぱいになった時、または、プロセスが終了する時にログ記憶装置に転送することができる。
ログ記憶装置は、例えばファイルシステムとすることができる。
【００５２】
中央レポジトリ１０５は、分散システム１００上のログデータを受信して、当該データを蓄積することができる任意の記憶デバイスとすることができ、例えばデータベースとすることができる。
関係データベースは、リモートのログ記録機能を容易にし、かつ、さまざまなコンピュータデバイスに位置するさまざまなプロセスから生成されたさまざまな型のデータ間のセマンティックス上の関係も保持するので、関係データベースを中央レポジトリ１０５として使用することができる。
１つまたは複数のログ記憶装置からのログデータは、中央レポジトリ１０５に搬送されて記憶される。
この転送は、一定周期で行うこともできるし、アナライザ１１０による要求時または中央レポジトリ１０５による要求時に行うこともできるし、ローカルなログ記憶装置を空にする必要がある時に行うこともできる。
中央レポジトリ１０５は、複数のログ記憶装置からのデータを記憶することができ、分散システム１００のさまざまなプロセスによって生成された複数のスレッドをログ記録することができる。
【００５３】
アナライザ１１０は、分散システム１００内のどの場所にも配置することができ、必ずしも、ログ記憶装置１１３、１１４、および１１５の１つを生成するマシン上に配置される必要はない。
アナライザ１１０は、ログデータを検索して、そのログデータを意味のある結果に操作することができる。
このログデータは、レポート形式にすることができ、遠隔の場所に転送することができ、オペレータに表示することができ、ハードコピーで印刷することができる。
データおよび結果は、フロントエンドプレゼンテーション１１９に表示することができる。
【００５４】
アナライザは、自動インスツルメンテーションプローブインサータ（図示せず）を含むことができる。
ランタイムシステム挙動を監視して特徴付けるために、プローブインサータは、ソフトウェアプローブを既存のソフトウェアシステムのソースコードの実施に挿入して、システムの監視および必要な監視データの収集を行うことができる。
このようなプローブ挿入は、現在のコンパイラ技術を使用して自動的に行われる。
【００５５】
プローブインサータが、元のシステム内にプローブを静的に挿入した後、その結果生成されるコードの実施は、いくつかの必要なインスツルメンテーションライブラリと再リンクされる。
コンパイルおよびリンクにより、新しいバイナリ実行可能イメージが生成される。
この実行可能イメージは、ユーザ定義の環境設定に基づいて、分散システム１００内に配備される。
システムが実行されると、プローブは、関連したログデータを生成する。
【００５６】
監視は、２つの柔軟性のある方法で分散システム内に導入することができる。
第１のものは、ＩＤＬコンパイラの起動段階の期間中に、ユーザが、どの型のプローブを、アプリケーションのどのコンポーネントに含めるかを指定することができるものである。
あるいは、ランタイム段階において、分散システム１００が、すでに配備されたソフトウェアプローブを有する場合、ユーザが、実行中に、そのプローブをオンおよびオフすることができるものである（図１０および図１１と共に以下に解説する）。
【００５７】
アナライザは、監視データローダをさらに含むことができる。
ソフトウェアプローブは、システムの実行時に、スレッドのログデータを生成する。
真の分散ソフトウェアシステムの場合、その結果生成されるログデータは、異なるマシンに位置する異なるログファイルに分散することがある。
このデータローダは、これらのすべてのログデータを収集して、収集したデータを中央レポジトリ１０５に記憶する役割を有する。
【００５８】
アナライザ１１０は、いくつかの型のシステム挙動の特徴付けを行う。
システム挙動の特徴付け分析は、動的呼び出しグラフ（dynamic call graph）の形でユーザに提示することができる。
動的呼び出しグラフは、全システムの実行を２次元で表現したものであり、アプリケーションのコンポーネントがノードとして示され、コンポーネント間の相互作用が直線または弧として示される。
したがって、動的呼び出しグラフは、アプリケーションの実行を表現するものであり、アプリケーションコンポーネントの相対的な実行回数、消費メモリ、および実際の関数の入出力パラメータ、ならびにそれらの呼び出しの階層を示すことができる。
動的呼び出しグラフは、監視されるシステムの実行時の関数の起動の組および動的に生成されたアプリケーションレベルのスレッドの組をさらに示すことができる。
これらの組は、関数の呼び出し側／被呼び出し側の関係およびスレッドの親／子関係によって因果関係としてリンクされる。
【００５９】
アナライザ１１０は、分散システム１００の関数の挙動を理解するために使用できるいくつかの情報を構築することができる。
１つは、関数の呼び出し側／被呼び出し側の関係を示す動的呼び出しグラフである。
同一のグローバル因果識別子（ＧＣＩＤ）を共有するすべての関数起動は、増加するイベント番号に基づいて順序付けられる（各関数起動は、スタブおよびスケルトンを含む）。
動的呼び出しグラフは、順序付けられ、収集されたログデータから作成される。
この作成は、順序付けられた関数起動が、そのセマンティックスが状態マシン（後述）によって定義可能な言語表現であることから可能である。
呼び出しグラフは、（Ｃコンパイラが、入力されたＣファイルを構文解析して、抽象構文木を作成するのと同様に）順序付けられた関数起動内に組み込まれたイベントチェーンから１つずつイベント（すなわち、スタブ開始イベント、スタブ終了イベント、スケルトン開始イベント、およびスケルトン終了イベント）を消費することにより作成することができる。
【００６０】
スレッドの親／子関係（および、場合によってはこのような関係の推移）も同様に、そのスレッドに関係したログデータを通じて明らかにすることができる。
関数起動ノードおよびスレッドノードを、関数の呼び出し側／被呼び出し側の関係のログデータおよびスレッドの親／子関係のログデータによってリンクすることにより、分散システム１００で実行される各プロセスについて、完全な動的呼び出しグラフを構築することができる。
【００６１】
本発明による監視は、通信プロトコルから独立し、かつ、ネットワーク構成から独立している。
本発明による監視は、複数のスレッドを追跡することができる。
この複数のスレッドには、単一のプロセスによって生成された複数のスレッドが含まれる。
さらに、グローバルに同期したタイマは必要とされない。
タイミングに関連したすべての監視は、それぞれの個々のコンピュータデバイスのタイマに基づき、これらのタイマは、必ずしも同期する必要はない。
【００６２】
したがって、分散システム１００は、マルチスレッド分散システムの挙動の監視および特徴付けを行う。
この監視および特徴付けは、アプリケーションセマンティック挙動、エンドツーエンドのタイミング待ち時間の挙動、および共有資源使用量の挙動（例えばＣＰＵおよびヒープメモリの使用量）を記録することができる。
本発明の監視によって、ユーザは、分散システム１００がどのように挙動するかを理解することが可能となり、変更の影響が、セマンティックス上の因果の連関に従い、システム全体を通じてどのように伝搬するかの評価が可能となる。
加えて、本発明の監視により、ユーザは、資源の使用量（budget）をシステムレベルで指定することが可能となる。
【００６３】
図３は、本発明の一実施の形態によるスタブおよびスケルトンの設計図である。
例えば、ＣＯＲＢＡ、ＣＯＭ／ＤＣＯＭ、またはＲＭＩといったコンポーネント技術は、間接レイヤを生成して、関数の呼び出し側および被呼び出し側を異なるスレッドに（または異なるプロセスにも）分割する。
この間接レイヤは、スタブおよびスケルトンという２つの主要な部分を含む。
コンパイルの間、これらのスタブおよびスケルトンは、ＩＤＬコンパイラによって自動的に生成することができる。
通常動作の間、スタブおよびスケルトンは、クライアントからの関数呼び出しの一部として発行される。
コンポーネントオブジェクトは、被呼び出し側にアクセス可能であり、被呼び出し側にローカルなものである（すなわち、このコンポーネントオブジェクトは、同じプロセス内に存在する）。
関数の実施ｆ（ｘ，ｙ，ｚ）は、被呼び出し側のコンポーネントオブジェクト内で定義される。
【００６４】
この図は、従来の逐次プログラムで行われるローカルな関数起動と同様の分散起動形式の関数起動ｆ（ｘ，ｙ，ｚ）を示している。
本発明の自動プローブ挿入メカニズムは、この自動生成を利用して、スタブおよびスケルトンに配置されるソフトウェアプローブを生成する。
これを実現するために、監視および特徴付けに適した関数は、その関数のインターフェース定義が、システムの実施の一部としてＩＤＬで指定される関数である。
【００６５】
本発明によるスタブおよびスケルトン３００は、間接レイヤに４つのソフトウェアプローブを備える。
プローブ１は、起動クライアントによる関数呼び出し時にデータを記録する。
プローブ３は、その関数呼び出しが関連付けられる被呼び出し側のオブジェクトによる受信時にデータを記録する。
プローブ４は、被呼び出し側オブジェクトによる関数呼び出しの完了時（すなわち、その関数に関連付けられた出力または結果の生成時）にデータを記録する。
プローブ２は、クライアントが関数の結果の復帰値を受信した時にデータを記録する（クライアントと間接レイヤとの間の通信は双方向である）。
【００６６】
プローブの位置は、さまざまな方法で指定することができる。
デフォルトの状況では、すべての関数がプローブを受け取ることができる。
一方、ユーザは、インスツルメントされる一定のＩＤＬインターフェースを選択的に指定することもできる（各ＩＤＬインターフェースは、関数のインターフェース定義の組を含む）。
【００６７】
本発明によって実現される監視には、４つの型がある。
したがって、ソフトウェアプローブから蓄積されるログデータには、４つの型がある。
これら４つの監視およびログデータの型は、タイミング待ち時間監視、共有資源使用量監視、アプリケーションセマンティック監視、および因果関係監視である。
因果関係監視により、異なる関数間、および、監視中の分散アプリケーションによって生成される異なるスレッド間で、他の３つの型の監視データをリンクさせることが可能になる。
【００６８】
＜タイミング待ち時間監視＞
タイミング待ち時間監視の場合、各プローブは、そのプローブの始動時に、ローカルマシンからタイムスタンプを取得し、そのプローブの終了時にも、再びタイムスタンプを取得する。
４つのすべてのプローブが、タイミング待ち時間ログデータを収集する。
プローブ２の終了時のタイムスタンプと、プローブ１の始動時のタイムスタンプとの間の差は、その関数のエンドツーエンドのタイミング待ち時間を表す。
このタイミング待ち時間データは、各インターフェース関数に関連付けられたテーブル形式で提示することもできるし、関連付けられた動的呼び出しグラフに直接注釈として付けることもできる。
【００６９】
一例として、関数「ｆｏｏ（狛犬）」がアプリケーションに存在するものと仮定する。
その実施では、この関数「ｆｏｏ」は、まず、関数「ｔｉｍｅｓ（回数）」を起動して、関数「ｓａｙ＿ｉｔ（それを示す）」の次の起動を何回繰り返さなければならないかを問い合わせる。
次いで、関数「ｆｏｏ」は、第２の関数「ｗｈａｔ＿ｔｏ＿ｓａｙ（示すべきもの）」を起動して、関数「ｓａｙ＿ｉｔ」の次の起動が使用する予定の文字列情報を問い合わせる。
次いで、関数「ｆｏｏ」は、関数「ｆｏｏ」で指定された回数、関数「ｓａｙ＿ｉｔ」を起動する。
関連したコードを以下の例に示す。
【００７０】
void Class A::foo() {
….
//obj1, obj2, and obj3 are three remote objects identified already.（ｏｂｊ１、ｏｂｊ２、およびｏｂｊ３は、すでに識別されている３つのリモートオブジェクトである）
int counter = obj1→times();
String content = obj2->what_to_say();
for (int i=0; i<counter; i++) {
obj3->say_it(content);
}
….
}
String ClassA::what_to_say() {
….
Thread*thread_1 = new Thread((Thread_Start_Function)f1);
Thread*thread_2 = new Thread((Thread_Start_Function)f2);
….
}
【００７１】
関数「ｓａｙ＿ｉｔ」の３回の起動は、完了するのに、それぞれ３．２ミリ秒、３．４ミリ秒、および３．６ミリ秒を要し、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」は、完了するのに４．１ミリ秒を要し、関数「ｔｉｍｅｓ」は、完了するのに２．７ミリ秒を要し、関数「ｆｏｏ」は、完了するのに２０．０ミリ秒を要したものと仮定する。
関数「ｔｉｍｅｓ」、関数「ｓａｙ＿ｉｔ」、および関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」と関連付けられる統計情報（平均、標準偏差、最小値および最大値）のテーブルを作成することができる。
動的呼び出しグラフが構築されると、全２０．０ミリ秒のタイミング待ち時間のうち、２．７ミリ秒（１４％）が、関数「ｔｉｍｅｓ」で費やされ、４．１ミリ秒（２１％）が関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」で費やされ、３．２ミリ秒（１６％）、３．４ミリ秒（１７％）および３．６ミリ秒（１８％）が、３回の「ｓａｙ＿ｉｔ」関数の起動の各々でそれぞれ費やされたことが分かる。
まだ１４％の経過時間が残っており、したがって、この時間は、関数「ｆｏｏ」自体のローカルな計算で費やされた部分であることに留意されたい。
【００７２】
＜共有資源使用量監視＞
例えばＣＰＵの使用量またはヒープメモリの使用量といった共有資源使用量監視の場合、プローブは、タイミング待ち時間監視の構成と同様に構成される。
４つのすべてのプローブは、プローブが開始される時に共有資源使用量情報を収集し、プローブが終了する時も再び共有資源使用量情報を収集する。
【００７３】
ＣＰＵおよびメモリの使用量に関して、さまざまなオペレーティングシステムが、このような使用量情報の検索に対して異なる程度のアクセス性を提供する。
いくつかのオペレーティングシステムでは、当該基礎となるオペレーティングシステムから情報を収集して変換するのに、追加ライブラリが必要とされる可能性が高い。
【００７４】
共有資源の１つの型は、動的メモリ割り当て（すなわち、ヒープメモリ）であり、これは、ユーザアプリケーションおよびコンポーネントベースシステムのランタイムインフラストラクチャ（例えば、ＣＯＲＢＡでは、オブジェクト要求ブローカ（Object Request Broker）、すなわちＯＲＢと呼ばれる）の双方によって要求されるものである。
この動的メモリ割り当ては、例えば、「ｍａｌｌｏｃ／ｆｒｅｅ（メモリ割り当て／解放）」（Ｃ言語）または「ｏｐｅｒａｔｏｒ  ｎｅｗ／ｄｅｌｅｔｅ（演算子  新規／消去）」（Ｃ＋＋）のライブラリ呼び出しが起動されると行うことができる。
コンポーネントベースシステムのランタイムインフラストラクチャとオペレーティングシステムとの間に、メモリ管理サブシステムを配置することができる。
このメモリ管理サブシステムは、各メモリ要求を傍受して、その要求をオペレーティングシステムに転送するために、インターセプタを使用することができる（後に解説）。
メモリ管理サブシステムは、メモリ要求を受信すると、スレッド単位のメモリ使用量情報を収集することができる。
この情報は、スタブおよびスケルトンのプローブにエクスポートすることができる。
【００７５】
現在のオペレーティングシステムの１つの大きな欠点は、ヒープメモリ使用量情報（すなわち動的メモリ割り当て）を直接検索することを可能にしていないことである。
本発明の監視は、メモリ割り当て要求インターセプタの使用を通じて、このような機能を提供する。
【００７６】
本発明のメモリ使用インターセプタは、メモリ要求オペレーションに挿入されるインターセプタ関数によって実現される（本明細書では、インターセプタという用語は、ＣＯＲＢＡのインターセプタのいずれとも関係しない）。
インターセプタは、ユーザ定義のアプリケーションおよびコンポーネントベースシステムのランタイムインフラストラクチャの双方からの動的メモリ割り当て要求および割り当て解除要求を傍受する（これらの要求は、基礎となるオペレーティングシステムに送られる）。
インターセプタは、対応するメモリトランザクションの監視も行いながら、これらのメモリ要求を中継する。
その結果、スレッド単位の動的メモリ使用量の統計情報を、インターセプタにおいて収集し、インスツルメントされたスタブおよびスケルトンに配置されたインスツルメンテーションプローブにエクスポートすることができる。
【００７７】
動的メモリ割り当て／割り当て解除は、それぞれのプログラミング言語において、限られた個数の事前に定義された標準ライブラリ呼び出しを通じて実行される。
Ｃプログラミング言語では、標準Ｃライブラリ関数「ｍａｌｌｏｃ」および「ｃａｌｌｏｃ」が、基礎となるオペレーティングシステムからメモリの一部を要求することができ、「ｆｒｅｅ」と呼ばれる標準Ｃライブラリ関数が、メモリの一部の割り当て解除を要求することができる。
Ｃ＋＋プログラミング言語では、サポートされている上記Ｃ標準ライブラリ関数呼び出しに加えて、演算子「ｎｅｗ」を使用してメモリの一部を要求し、新しく構築されたオブジェクトを収容することができる。
その要求されたオブジェクトが破壊された後は、演算子「ｄｅｌｅｔｅ」を使用して、メモリの一部の割り当て解除を要求することができる。
【００７８】
インターセプタを有効にすることは、マクロ再定義と呼ばれる既知のコンパイル前処理技法を使用することにより行うことができる。
この技法は、ヘッダファイルを使用する。
このヘッダファイルでは、例えば「ＰＨ＿ｍａｌｌｏｃ」および「ＰＨ＿ｆｒｅｅ」といった新しく定義された２つのインターセプタ関数呼び出しを通じて動的メモリ要求を運ぶために、標準ライブラリ関数呼び出しが再定義されている。
例えば「ｎｅｗ」および「ｄｅｌｅｔｅ」といったＣ＋＋インターセプタ演算子の場合、グローバル演算子再定義と呼ばれるＣ＋＋言語機能を使用することができる。
この機能により、「ｎｅｗ」および「ｄｅｌｅｔｅ」を通じた動的メモリ使用要求は、インターセプタ関数「ＰＨ＿ｍａｌｌｏｃ」および「ＰＨ＿ｆｒｅｅ」に転送される。
「ＰＨ＿ｍａｌｌｏｃ」および「ＰＨ＿ｆｒｅｅ」の役割は、スレッド単位のメモリ使用要求情報を収集して、スレッド単位の統計情報を更新することである。
スレッド単位の統計情報には、例えば、最小使用量、最大使用量、および平均使用量が含まれ得る。
再定義されたインターセプタ演算子（すなわち、この例では「ＰＨ＿ｍａｌｌｏｃ」および「ＰＨ＿ｆｒｅｅ」）は、メモリ使用要求を、元のインスツルメントされていないＣ標準ライブラリ呼び出し（すなわち、「ｍａｌｌｏｃ」および「ｆｒｅｅ」）に転送する。
【００７９】
インターセプタは、メモリ使用要求がどこからのものであるかを識別する固有の機能を備え、その結果、ユーザ定義のソフトウェアアプリケーションからのメモリ使用要求を、コンポーネントベースシステムのランタイムインフラストラクチャからのメモリ使用要求と区別することができる。
これは、ライブラリのマーク付けを通じて行われる。
コンポーネント技術のランタイムインフラストラクチャは、１つまたは複数のライブラリから構成される。
１つの整数が、１つのライブラリまたは複数のライブラリにマークを付けるために確保される。
マーク付けは、メモリ割り当ておよび割り当て解除に必要とされる通常のパラメータに加えて、「マーカ」パラメータを「ＰＨ＿ｍａｌｌｏｃ」および「ＰＨ＿ｆｒｅｅ」関数インターフェースに導入することにより行われる。
ライブラリの構築中、コンパイルを受けているすべてのソースコードファイルは、マクロ再定義プロセスおよび／またはグローバル演算子再定義プロセスを通過しなければならない。
このプロセスにおいて、１つのライブラリまたは複数のライブラリに対して指定されたマーカが、それぞれの「ＰＨ＿ｍａｌｌｏｃ」呼び出しインスタンスまたは「ＰＨ＿ｆｒｅｅ」呼び出しインスタンスに提供される。
同様に、別の整数が、ユーザ定義のアプリケーションコードに対応するライブラリにマークを付けるために確保される。
これらのマーカにより、アプリケーション全体が実行中の場合、メモリ使用インターセプタは、要求がどこから来たものであるかを知り、コンポーネントベースシステムのランタイムインフラストラクチャからの動的メモリ要求と、ユーザ定義のソフトウェアアプリケーションからの動的メモリ要求とを区別することができる。
【００８０】
アナライザ１１０は、ＣＰＵ使用量のレポートを生成することができる。
関数の実行が、唯一のプロセッサで行われる逐次オペレーションと異なり、分散した関数呼び出しは、複数のプロセスおよび複数のプロセッサを通じて生成され得る。
したがって、ＣＰＵ使用量は、ベクトル形式＜Ｃ１，Ｃ２，…，ＣＮ＞で表現することができる。
ここで、Ｃｉは、プロセッサＰｉのＣＰＵ使用量を表し、システム内のプロセッサの総数はＮである。
【００８１】
ＣＰＵ消費量は、さまざまな方法で特徴付けることができる。
第１の実施の形態では、ＣＰＵ消費量は、個々の関数のみが引き起こす消費量を追跡し、セマンティックス上リンクした関数およびスレッドによるＣＰＵ消費量を追跡しない。
したがって、関数消費量は、常に、スタブおよびスケルトンという２つの部分から取得される。
スタブおよびスケルトンは、同じプロセス内で実行中であってもよいし、２つの異なるプロセス内で実行中であってもよい（場合によっては、２つの異なる処理デバイスに位置する）。
【００８２】
より高機能の第２の実施の形態では、ＣＰＵ消費量は、伝搬アクティビティとみなされる。
したがって、定義された因果関係（関数の呼び出し側／被呼び出し側の関係およびスレッドの親／子関係の双方を含む）に従うことにより、関連した子関数呼び出しによるＣＰＵ消費量に加えて、これらの関数の起動中に動的に生成されるスレッドによるＣＰＵ消費量のすべてが、その関数の消費量に変更される。
この変更は、その関数が、関数の起動および生成されるスレッドの結果として生成されるチェーンのイニシエータであることから、行うことができる。
【００８３】
アナライザ１１０は、ＣＰＵ使用量のレポートを、タイミング待ち時間分析に関連したテーブルと同様のテーブル表現で作成することもできるし、動的呼び出しグラフのスレッドノードおよび関数ノードの双方に注釈として付けることもできる。
【００８４】
上記タイミング待ち時間の節で与えたコード例に再び戻って、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」は、当該関数の実行中に２つのスレッド（すなわち、スレッド１およびスレッド２）を生成する。
システム構成の点から、関数「ｆｏｏ」の実行がプロセッサＡで行われ、関数「ｔｉｍｅｓ」の実行がプロセッサＢで行われ、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」の実行（これに加えてスレッド１およびスレッド２の実行も。
これらのスレッドは、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」によって生成される）がプロセッサＣで行われ、関数「ｓａｙ＿ｉｔ」の実行がプロセッサＤで行われると仮定する。
【００８５】
この例について、過度に単純化した観点から、関数の実施本体で費やされるＣＰＵ消費量のみが、分析に考慮されるものと仮定する。
この例では、測定によって、関数「ｆｏｏ」がプロセッサＡで３．２ミリ秒の処理時間を消費し、関数「ｔｉｍｅｓ」がプロセッサＢで２．７ミリ秒の処理時間を消費し、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」がプロセッサＣで３．０ミリ秒の処理時間を消費し、関数「ｓａｙ＿ｉｔ」の各起動がプロセッサＤで２．６ミリ秒、２．６ミリ秒、および２．６ミリ秒の処理時間をそれぞれ消費することが判明したということが与えられる。
スレッド１は、プロセッサＣで１．８ミリ秒の処理時間を消費し、スレッド２は、プロセッサＣで２．２ミリ秒の処理時間を消費する。
【００８６】
タイミング待ち時間の特徴付けと同様に、ＣＰＵの特徴付け（平均消費量、標準偏差、最大ＣＰＵ消費量および最小ＣＰＵ消費量）を、各関数について求めることができ、テーブル形式で表すことができる。
関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」の動的呼び出しグラフを復元する際に、生成された２つのスレッド１および２の実行が考慮されるべきである。
したがって、関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」の全ＣＰＵ消費量は、３．０ミリ秒（自身）プラス１．８ミリ秒（スレッド１による）プラス２．２ミリ秒（スレッド２による）の合計７．０ミリ秒となるべきである。
同様に、関数「ｆｏｏ」の全ＣＰＵ消費量は、＜３．２，０，０，０＞ミリ秒（関数「ｆｏｏ」の起動について）プラス＜０，２．７，０，０＞ミリ秒（関数「ｔｉｍｅｓ」の起動による）プラス＜０，０，７．０，０＞ミリ秒（上記計算した関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」の結果から）プラス＜０，０，０，２．６＞ミリ秒（関数「ｓａｙ＿ｉｔ」の１回目の起動による）プラス＜０，０，０，２．６＞ミリ秒（関数「ｓａｙ＿ｉｔ」の２回目の起動による）プラス＜０，０，０，２．６＞ミリ秒（関数「ｓａｙ＿ｉｔ」の３回目の起動による）、すなわち＜３．２，２．７，７．０，７．８＞ミリ秒となり、合計２０．７ミリ秒となる。
この結果は、関数「ｆｏｏ」を実行するのに、分散システム全体が、関数「ｆｏｏ」の起動のために、プロセッサＡで３．２ミリ秒、プロセッサＢで２．７ミリ秒、プロセッサＣで７．０ミリ秒、プロセッサＤで７．８ミリ秒をそれぞれ費やしたことを示している。
本発明によって捕捉された因果関係なしに、例えばＣＰＵ消費量といった資源の伝搬の識別および測定を行うことはできないことに留意すべきである。
【００８７】
プロセッサＡ、Ｂ、Ｃ、およびＤが同一である場合、各関数の起動で費やされたＣＰＵ処理時間の割合を計算することができる。
この例では、処理時間の１５．５％が関数「ｆｏｏ」で費やされ、１３．０％が関数「ｔｉｍｅｓ」で費やされ、３３．８％が関数「ｗｈａｔ＿ｔｏ＿ｓａｙ」で費やされ、１２．６％が関数「ｓａｙ＿ｉｔ」の各起動で費やされることが分かる。
【００８８】
＜アプリケーションセマンティック監視＞
アプリケーションセマンティック監視は、関数呼び出し内のデータを捕捉する。
すなわち、この監視は、関数名、関連したインターフェース名、および入出力パラメータ、関数の復帰結果、例外などを捕捉する。
プローブ１は、関数の入力パラメータを記録する。
プローブ２は、関数の出力パラメータおよび関数の復帰値に加えて、発生したあらゆる例外を記録する。
プローブ３および４は、いずれのアプリケーションセマンティック監視データも記録しない。
プローブ１およびプローブ２のいずれか一方のみが、関数名および関連したインターフェース名の記録に必要とされる。
【００８９】
アナライザ１１０は、中央レポジトリ１０５に記憶されたアプリケーションセマンティック情報、タイミング情報、および共有資源ログデータ情報のすべてにアクセスすることができるので、ＳＱＬ（構造化照会言語）の照会を使用して、多くの分析を実施することができる。
例えば、アナライザ１１０は、特定のユーザ定義の例外が、実行中に発生したかどうかを判断することができる。
例外が発生した場合には、アナライザ１１０は、その関連した関数を求めることができる。
例えば、アナライザ１１０は、いずれかのランタイムプロセスが、最大ヒープメモリ使用量を越えたかどうかを判断し、そのオーバした量を求めることができる。
さらに、アナライザ１１０は、このような異常を反映するいずれかの関数起動インスタンスを、それらインスタンスの入出力パラメータを含めて求めることができる。
その上、アナライザ１１０は、特定の関数に関連した特定の入出力パラメータが、あらかじめ定められた述語、例えば「ａ＞０」、「ａ＜０」、または「ａ＝０」と常に整合するかどうかを判断することができる。
加えて、アナライザ１１０は、特定の例外が、特定の関数によって引き起こされる頻度を求めることができる。
【００９０】
＜因果関係監視＞
本発明による監視は、マルチスレッドアプリケーションにおいても、関数の呼び出し側／被呼び出し側の関係の監視を可能にする因果関係トレースも捕捉する。
この因果関係トレースにより、スレッドの親／子関係の監視も可能になる。
プローブは、スタブまたはスケルトンにおけるローカルな挙動のみを記録するので、このようなローカルなログ記録情報は、その情報が、分散システム１００全体で因果関係によりリンクされる場合にのみ役立つ。
因果関係トレースを実現するために、本発明は、４つのすべてのプローブにおいて、次の情報、すなわちグローバル因果識別子（ＧＣＩＤ）、ローカル関数識別子、イベント、イベント番号、およびスレッド識別子、ならびにマーカを記録する。
【００９１】
ＧＣＩＤは、汎用一意識別子（Universally Unique Identifier）である。
この一意性は、空間および時間の双方に及ぶ。
監視オペレーション中、関数Ｆに関連付けられたＧＣＩＤは、ＦのスタブからＦのスケルトンに運ばれ、さらに、Ｆから直接または間接に起動される関数に運ばれる。
グローバル因果識別子（ＧＣＩＤ）は、Ｆの実施において生成され得る子スレッド、または、Ｆから直接もしくは間接に起動される関数の実施において生成され得る子スレッドには伝搬されない。
【００９２】
ローカル関数識別子は、それぞれのプロセスにローカルなスタブ／スケルトンの一連の起動を識別する連続番号であり、それぞれの個々のプロセスについて０から開始する。
【００９３】
イベントは、どのプローブが行われているかを識別し、スタブ開始、スタブ終了、スケルトン開始、またはスケルトン終了とすることができる。
【００９４】
イベント番号は、それぞれのイベントに、その関数呼び出しチェーンにおいて一意の番号を与える。
イベント番号は、０から開始し、イベント（スタブ開始、スタブ終了、スケルトン開始、およびスケルトン終了）に遭遇するごとに順次増加される。
その結果、このイベントカウンタは、関数呼び出しチェーンにおける各プローブでインクリメントされる。
【００９５】
スレッド識別子は、１つのプロセスにおいて各スレッドに割り当てられる一意の番号である（子スレッドは、親スレッドのスレッド識別子と異なるスレッド識別子を有することになる）。
どの論理スレッドが、この関数の計算担体（computational carrier）であるかを示すために、それぞれの個々のプロセスのスレッド識別子は、スレッドライブラリのスレッドコンストラクタによって順次増加される。
マーカは、現在実行中の関数本体が、ユーザ定義のアプリケーションコードからのものであるかどうかを示すブールラベルである。
「真」のマーカは、現在の関数が、ユーザ定義のアプリケーションコードからのものであることを示し、「偽」は、そうでないことを示している。
【００９６】
上記情報項目は、関数の呼び出し側／被呼び出し側の因果関係を導出するために収集される。
しかしながら、スレッドの親／子関係を推論するには、スレッド識別子だけでは十分ではない。
どのスレッドが、どの関数の実行のために動的に生成されるかを追跡するために、次の追加データ項目が収集される。
すなわち、自己スレッド識別子、親スレッド識別子、および関数コンテナ識別子が収集される。
これら３つのデータ項目は、動的に生成された各スレッドＴのデータを記録するために、スレッドコンストラクタの実行中にログ記録される。
これらの追加ログ記録プロセスによって生成されたデータ項目は、その後、それぞれの個々のプロセスに関連付けられたスレッドテーブルに別々に記録される。
【００９７】
自己スレッド識別子は、１つのプロセスにおいて一意の連続番号である。
自己スレッド識別子は、監視中のスレッドごとに生成され、スレッドコンストラクタ内の順次増加するカウンタ（０から開始する）から取り出される。
【００９８】
親スレッド識別子は、子スレッドに含まれるものであり、親スレッドを識別する。
スレッドテーブルにおいて、スレッドＴの親スレッド識別子は、スレッドＴを動的に生成したスレッドの自己スレッド識別子である。
【００９９】
関数コンテナ識別子は、１つのプロセスにおける１つの関数についての０より大きな一意の数字を生成する。
スレッドＴが、関数Ｆから生成される場合、この関数コンテナ識別子は、関数Ｆのローカル関数識別子の複製となる。
関数コンテナ識別子は、スケルトン、すなわちプローブ３およびプローブ４によってのみ注目される。
この理由は、Ｆの実施が、プローブ３の後に起動されるからであり、それが、Ｆの実施の内部で生成されるスレッドであって、ユーザ定義で、かつ、対象となっているスレッドであるからである。
【０１００】
インスツルメンテーションプローブは、主として、スタブおよびスケルトンにおいて割り当てられるが、スレッドの親／子の因果関係トレースは、上記３つのデータ項目が、上記で解説したプローブ以外で取得されることを必要とする（関数コンテナ識別子を除く）。
したがって、必要な追加データ項目は、インスツルメントされたスレッドライブラリを通じて取得される。
このスレッドライブラリは、スレッドの構築、スレッドの操作、およびスレッドの調整のための抽象的なインターフェースを提供する。
また、このスレッドライブラリは、基礎となるオペレーティングシステムから独立した上位レイヤ（すなわち、コンポーネントベースシステムのランタイムインフラストラクチャおよびユーザレベルアプリケーションの双方）に他の同期プリミティブも提供することができる。
スレッドライブラリ、例えばスレッドコンストラクタにプローブを挿入することにより、スレッドの寿命期間を求めることができる。
加えて、スレッドに関連した資源使用量および親子関係も求めることができる。
【０１０１】
＜追加監視＞
プロセスの構成、すなわち、どの関数が、どのマシンに存在するどのプロセスで実行されるかを明らかにするために、本発明は、次のプロセス情報、すなわち、ホスト名、プロセスＩＤ、およびプロセス汎用一意識別子（プロセスＵＵＩＤ）を独立に記録する。
ホスト名は、そのプロセスが位置するマシンまたはコンピュータデバイスの名前である。
プロセスＩＤは、そのプロセスが位置するホストマシンに関する一意の連続番号を識別するものであり、通常、オペレーティングシステムによって割り当てられる。
このプロセス識別子は、システム実行中に、それぞれの個々のマシンにおいて一意である。
プロセスＵＵＩＤは、インターネット全体にわたるプロセスの汎用識別子である。
このような全プロセスのログ記録情報が、それぞれの個々のプローブに関連付けられたログデータから別々にログ記録される。
【０１０２】
図４は、単一の関数起動に対する監視プロセスの時系列ステップを示している。
イベント１は、スタブ開始であり、イベント３は、スケルトン開始であり、イベント４は、スケルトン終了であり、イベント２は、スタブ終了である。
イベント１および３は、関数の起動後で、かつ、関数の完了前に発生する。
イベント４および２は、関数の完了後に発生する。
したがって、この図は、単一の関数呼び出しのスタブおよびスケルトンの作動シーケンスを示している。
【０１０３】
これらの４つのイベントは、第２のソフトウェアコンポーネントに関連した関数の起動および実行において発生する。
第２のソフトウェアコンポーネントは、第１のソフトウェアコンポーネント内から起動することができる。
第２のソフトウェアコンポーネントの起動は、図示した４つのイベントに関する任意の時点で起こり得る。
【０１０４】
図５は、本発明の別の実施の形態による因果トレースのための関数の呼び出し側／被呼び出し側の関係を搬送するプロセス図である。
クライアント５０５は、関数呼び出しを発行する任意のコンポーネントベースソフトウェアアプリケーションとすることができ、スタブ開始プローブ１  ５０８を生成する。
このスタブ開始プローブ１  ５０８は、通常の関数呼び出しデータと共に、関数呼び出しログデータの一部をスケルトン開始プローブ３  ５１３に渡す。
この関数呼び出しログデータの一部は、関数搬送可能ログデータ（function-transportable log data）と呼ばれる。
関数搬送可能ログデータは、グローバル因果識別子（ＧＣＩＤ）およびイベント番号を含むことができる。
この渡すことは、スタブ（プローブ１  ５０８）とスケルトン（プローブ３  ５１３）との間の通信チャネルを通じて行われる。
【０１０５】
図の矢印は、一方向のみのデータの搬送を示しているが、データは、関数の復帰として逆方向にも搬送できることが理解されるべきである。
例えば、プローブ４（この図には図示せず）は、プローブ３  ５１３に対応するものである。
プローブ４は、更新された関数搬送可能ログデータをその関数の復帰パラメータと共にプローブ２（この図には図示せず）に搬送して戻す（プローブ２はプローブ１  ５０８に対応するものである）。
【０１０６】
実際のデータ搬送は、ＩＤＬインターフェースに仮想的に追加される追加搬送パラメータによって行われる。
この搬送パラメータは、インスツルメントされたスタブとインスツルメントされたスケルトンとの間で渡される。
これは、ユーザ定義のアプリケーションコードを変更することなく行われる。
この搬送は、関数の実施５１６に関連付けられたユーザ定義コードの変更を回避するために行うことができる。
したがって、プライベートな通信チャネル（コンポーネントシステムのランタイムインフラストラクチャによって使用されて、スタブとスケルトンとの間で通常の関数データを搬送する）とスレッド特有の記憶装置５３５とを結合して、このようなプライベートな通信チャネル、および、場合によっては、別の通信チャネルを橋渡しすることにより、全関数呼び出しチェーンに沿って関数呼び出しログデータ（例えばグローバル因果識別子）をシームレスに搬送することができる。
【０１０７】
スタブとスケルトンとの間のデータ搬送は、関数搬送可能ログデータを通じて関数の呼び出し側／被呼び出し側の関係トレースを実現するために行うことができる。
このデータ搬送には、グローバル因果識別子（ＧＣＩＤ）およびプローブ１  ５０８のイベント番号の搬送が含まれ得る。
【０１０８】
関数の実施５１６の内部では、別の関数呼び出しを起動することができ、その結果、子関数プローブ１  ５２２が生成される。
関数の実施５１６および子プローブ１  ５２２は、同じスレッドに常に位置するので、関数呼び出しログデータの一部（すなわちスケルトン開始ログデータ）をプローブ３  ５１３から子プローブ１  ５２２へさらに搬送することが、共有記憶メカニズムを通じて行われる。
この関数呼び出しログデータの一部は、スレッド搬送可能ログデータと呼ばれる。
共有記憶メカニズムは、スレッド特有の記憶装置５３５によって実施することができる。
搬送された関数呼び出しログデータの一部（すなわち、関数搬送可能ログデータ）が、プローブ３  ５１３によって受信された後、このスケルトン開始ログデータの少なくとも一部は、スレッド特有の記憶装置５３５に記憶される。
子関数のプローブ１  ５２２は、後に、このスケルトン開始ログデータの少なくとも一部を検索することができる。
スケルトン開始ログデータの少なくとも一部は、スレッド特有の記憶装置５３５に記憶される前に更新されてもよい。
この更新には、記憶前にイベント番号をインクリメントすることが含まれ得る。
【０１０９】
関数の制御が、関数呼び出しチェーンに沿って伝搬を続けるにつれて、子関数プローブ５２２は、スレッド特有の記憶装置５３５からログデータを検索し、当該ログデータを更新し、次いで、インスツルメントされたスタブからインスツルメントされたスケルトンへの搬送プロセス（上述）の開始を繰り返す。
【０１１０】
図６は、関数の呼び出し側／被呼び出し側の関係を追跡する実行シーケンス方法のフローチャート６００である。
このフローチャート６００は、例えば図５の示すようなシームレスな関数呼び出しログデータの搬送を実現する実行シーケンスを示している。
ステップ６０３で、スタブへの関数呼び出しが行われる。
【０１１１】
ステップ６０６では、上述したように、プローブ１が発行され、関数呼び出しデータが記録される。
【０１１２】
ステップ６１０では、ログデータの特定の部分（すなわち、関数搬送可能ログデータ）が、スタブからスケルトンへ、すなわち、プローブ１からプローブ３へ搬送される。
したがって、このログデータは、通常の関数呼び出しデータと共に搬送される。
【０１１３】
ステップ６１５では、特定のログ番号をインクリメントして、現在のプローブおよびイベントを反映することができる。
例えば、関数搬送可能ログデータからのイベント番号が、発行されたそれぞれのプローブでインクリメントされることになる。
さらに、ローカル関数識別子およびスレッド識別子を変更することができる。
【０１１４】
ステップ６２６では、上述したように、プローブ１  ５０８からプローブ３  ５１３に搬送され、更新された関数搬送可能ログデータも、スレッド特有の記憶装置５３５に記憶される。
【０１１５】
ステップ６３５では、関数の実施が起動される。
すなわち、関数は、データを受信して、実行を開始する。
【０１１６】
ステップ６４０では、現在の関数の実施内において、いずれかの子関数が起動されるかどうかが判断される。
起動されない場合、この方法は、ステップ６４３に進み、起動される場合、この方法は、ステップ６４１に分岐する。
【０１１７】
ステップ６４１では、フロー制御が、子関数のスタブに転送され、この方法は、子関数を処理するためにステップ６０３に分岐する。
【０１１８】
ステップ６４３では、関数搬送可能ログデータが、更新され、搬送を行うためにプローブ４でパッケージされる。
この更新には、イベント番号をインクリメントすることが含まれ得る。
パッケージは、通信ニュートラル搬送データ（communication-neutral transport data）を追加すること、または、関数搬送可能ログデータを通信ニュートラルフォーマット（communication-neutral format）に変換することを含むことができる。
関数搬送可能ログデータが、（スケルトンからのあらゆる関数起動応答と共に）インスツルメントされたスタブのプローブ２によって受信されると、プローブ２は、あらゆる必要な更新をさらに行う。
次いで、プローブ２は、更新された情報をそのスレッド特有の記憶装置に記憶して、後続の関数起動のさらなる因果トレースに対して準備を行う。
【０１１９】
ステップ６４８では、子関数が起動されないので、関数のフロー制御は、関数の呼び出し側に戻る。
関数呼び出しの実施が、複数のカスケードした子関数呼び出しをその実施本体に含む場合、上述した搬送可能ログデータは、上記プライベートな通信チャネルおよびスレッド特有の記憶メカニズムを使用することにより、このような子関数呼び出し間でまだ搬送可能であることに留意されたい。
その結果、少なくともいくつかのデータは、搬送のために、更新されてパッケージされることが必要とされることがある。
【０１２０】
したがって、この方法は、スレッド特有の記憶装置を使用して、ステップ６１０で定義されたログ関数のデータを渡すアクティビティを橋渡しする。
同時に、シームレスなログデータ搬送メカニズムが形成される。
さらに、この図は、関数呼び出しチェーンのすべての態様をトレースするために、ログ番号、例えばイベント番号などが、監視プロセス中にどのようにインクリメントされるかを示している。
【０１２１】
図７は、本発明の一実施の形態による親スレッドから子スレッドへログデータを搬送する方法のフローチャート７００である。
これは、スレッドの親／子関係をトレースするために行うことができる。
ステップ７０２で、親スレッドからのスレッド搬送可能ログデータが、スレッド特有の記憶装置から検索される。
このスレッド搬送可能な親ログデータは、通常、関数呼び出し中にプローブ３によって生成され、スレッド識別子、ローカル関数識別子、およびマーカを含むことができる。
マーカは、ユーザアプリケーションが生成したスレッドを、分散システム１００の基礎となるコンポーネントベースシステムのランタイムによって直接生成されたスレッドと区別するために使用することができる。
スレッド識別子によって区別可能な場合、または、システムスレッドをログ記録して特徴付けることが望まれる場合には、マーカを除くことができる。
子スレッドは、親スレッドから渡されたいくつかの（元の）関数パラメータにより生成されると仮定される。
【０１２２】
ステップ７０６では、スレッド搬送可能ログデータが、新しく生成されるスレッドのエントリポイントとなる関数の実際の関数パラメータと共にパッケージされる。
【０１２３】
ステップ７３０では、子スレッドがオペレーティングシステムによって生成されると、親スレッドのパッケージされたデータが、その子スレッドに搬送される。
この搬送は、オペレーティングシステムによって実行される。
【０１２４】
スレッド７４２では、搬送されたデータが、現在の子スレッドに関連付けられたスレッド情報と共に、その子スレッドのスレッドテーブルに記録される。
この記録を行うことは、搬送されたデータのパッケージを解くことを含むことができる。
さらに、例えばスレッド識別子に関連付けられたプロセス全体のシーケンス番号などの適用可能なログ値を更新することができる。
【０１２５】
マルチスレッドアプリケーションには、２つの型の構成関係（composition relationship）が存在する。
つまり、関数実行中にスレッドを起動できること（すなわち、スレッド起動関数関係）、および、関数実行中にスレッドを生成できること（すなわち、関数生成スレッド関係）が存在する。
これらの２つの型の関係の監視は、関数の呼び出し側／被呼び出し側の決定および親／子スレッドの決定を行う際の副次的なものとして行われる。
これら２つの型のクロスリンク関係の復元は、ログ記録されたデータを使用することにより行われる。
関数Ｆ１が、スレッドＴ６を生成した場合、スレッドＴ６の関数コンテナ識別子は、関数Ｆ１のローカル関数識別子と同一となる。
スレッドＴ１の自己スレッド識別子が、関数Ｆ９のスレッド識別子と同一である場合、スレッドＴ１が、関数Ｆ９を起動したことが分かる。
【０１２６】
関数の呼び出し側／被呼び出し側の関係の決定と異なり、スレッドの関係の復元は、比較的簡単に行われる。
スレッドＴ１の自己スレッド識別子が、スレッドＴ２の親スレッド識別子と同一である場合、スレッドＴ１は、スレッドＴ２の親である。
【０１２７】
図８は、関数の呼び出し側／被呼び出し側の関係の判断を示す状態遷移図である。
この図は、アナライザ１１０が、親／子関係（関数呼び出しのネストによって引き起こされる）と、兄弟関係（関数呼び出しのカスケードによって引き起こされる）とをどのようにして区別できるかを示している。
予備ステップ（図示せず）では、一意のグローバル因果識別子の組Ｆ'が、（ログ記憶装置１０５内で）特定される。
この組Ｆ'がデータを含む場合、特定のグローバル因果識別子ｘｙを使用して、適用可能なすべての関数ログ記録が検索される。
検索された関数ログ記録は、イベント番号の昇順にソートされる。
【０１２８】
アナライザ１１０は、ソートされた関数ログ記録の配列を走査して、ログ記録に関連付けられた状態を特定する。
各状態は、関数名、スタブまたはスケルトン、および開始／終了イベントによって表される。
【０１２９】
ある状態から別の状態への遷移を使用して、構文解析の決定（parsing decision）を生成することができる。
２つの状態間の決定が「進行中」である場合、その決定は、２つの隣接するログ記録が、関数呼び出しの通常の実行から得られることを示し、その実行シーケンスは、図４に定義される。
「子関数開始」の決定は、後続のログ記録が、現在のログ記録関数の子関数から得られることを示している。
「子関数復帰」の決定は、後続のログ記録が、現在のログ記録の親関数から得られることを示している。
「兄弟関数による継続」の決定は、次のログ記録が、現在のログ記録に関連付けられた関数の復帰直後の関数から得られることを示している。
【０１３０】
関数呼び出しの実施には、２つの一般的な関数呼び出しパターンが存在する。
第１のパターンは、兄弟関数関係である。
兄弟関係では、関数Ｆは、カスケード形式で他の複数の関数Ｇ１、Ｇ２を呼び出すことができる。
関数Ｇ１、Ｇ２などは、関数Ｆを実施するために、関数Ｆによって順次呼び出される（すなわち、関数Ｆは、関数Ｇ１を呼び出し、関数Ｇ１が完了して復帰した後に、関数Ｆは関数Ｇ２を呼び出す）。
このＧ１、Ｇ２などの関数呼び出しチェーンは、兄弟関数関係を形成する。
この第１のパターンは、もっぱら「兄弟関数による継続」イベントによって決定される。
【０１３１】
第２のパターンは、親子関数関係である。
親子関数関係では、関数Ｆが、関数Ｇを呼び出し、続いて、関数Ｇが、関数Ｈを呼び出す。
関数Ｇは、関数Ｈが完了して復帰した後になるまで、完了および復帰をしない。
したがって、この関数呼び出しは、ネストしていると言われる。
この第２のパターンは、「子関数開始」イベントおよび「子関数復帰」イベントによって決定される。
【０１３２】
この図は、例えばクラッシュといったランタイム実行障害がシステムにない場合に、関数の呼び出し側／被呼び出し側の関係をどのように決定するかを示しているにすぎない。
２つの隣接するログ関数記録が、状態遷移図に示す遷移パターンのいずれにも従わない場合に呼び出される付加的な「異常な」遷移状態（図示せず）が存在し得る。
その異常な遷移状態が生じると、分析は、障害を示し、分析は、次のログ記録から再開される。
【０１３３】
図９は、本発明の一実施の形態によるデータの蓄積および記憶のプロセス図である。
したがって、この図は、ログデータをどのようにしてローカルに蓄積できるかを示している。
各ログファイルは、プロセスに関連付けられる。
プロセス９０３では、クライアント９０６（すなわちアプリケーション）が、第１のオブジェクト９１２に関連付けられた関数呼び出しＦを起動する。
この第１のオブジェクト９１２は、第２のオブジェクト９０９に関連付けられた呼び出しをさらに起動することがある（すなわち、子関数が起動される）。
この第２のオブジェクト９０９は、プロセス９０３の外部ではあるが、関数Ｆの実施内に存在することがある。
いずれか一方のオブジェクトまたは双方のオブジェクトは、第３のオブジェクト９１８に関連付けられたメソッド（関数）呼び出しをさらに起動することがある。
オブジェクト９１２および９１８の関数起動からのログデータは、まず、例えばメモリ内の有限キューといったログ記憶装置９２２に搬送され、ログ記憶装置９２２で、このログデータは、一時的に記憶される。
第２のオブジェクト９０９は、プロセス９０３（第１のオブジェクト９１２および第３のオブジェクト９１８を含む）とは別のプロセスに位置するので、ログ記憶装置９２２は、第１のオブジェクト９１２および第３のオブジェクト９１８のみからログデータを受け取り、第２のオブジェクト９０９のログデータは受け取らない。
【０１３４】
データログ記録は、プロセス単位の動作として実行することができる。
システムの実行が終了すると、ローカルなログ９２２の内容は、長期記憶用のファイルシステム９２９にフラッシュすることができる。
このフラッシュは、ログ記憶装置９２２がいっぱいになった時に行うこともできるし、アプリケーション（クライアント９０６によって始動される）が終了した時に行うこともできる。
これらのファイルは、例えばＦＴＰといったデータ搬送プロトコルを通じて特定のマシンの特定のディレクトリに転送されてもよい。
このディレクトリから、ログデータは、例えば（Ｊａｖａの実施に適した）ＪＤＢＣまたは（Ｃ＋＋の実施に適した）ＯＤＢＣといったデータベースアクセスプロトコルを通じて、リモートデータベースに記憶されてもよい。
【０１３５】
ログデータは、さまざまなマシンに位置するさまざまなプロセスに分散しているので、データプロバイダおよびデータコレクタは、必ずしも同一のマシンプラットフォーム上で実行されている必要はない。
その結果、ログデータは、マシンニュートラルフォーマット（machine-neutral format）で提供されるべきである。
例えば、第１のマシンで生成されたログデータは、第２のマシンで復元可能であるべきである。
このようなデータの中立性は、この技術において既知であるので、それを使用して、データをバイナリでニュートラルなフォーマットでパッケージして、搬送することができる。
【０１３６】
データ記憶プロセスは、以下のステップを含むことができる。
第１に、ログデータに関連付けられたデータ構造が、ＩＤＬ仕様で定義される。
第２に、ＩＤＬコンパイラを実行して、ログデータのマーシャルおよびデマーシャルを行うメソッドを有するクラスの組を生成することができる。
マーシャル可能なオブジェクトは、他のフォーマットに変換可能で、かつ、それ以外に転送用に処理可能なオブジェクトである。
第３に、メモリ内バッファがいっぱいになると、記憶されたログデータをマーシャル可能なオブジェクトに変換することができる。
マーシャル可能とは、オブジェクト情報を、情報の歪みなくバイナリでニュートラルな方法で、インターネットまたはファイルシステムを通じて送受信できるように、データを他の一時的なフォーマットに変換できることをいう。
その後、この一時的なフォーマットから元のオブジェクトを復元することができる。
第４に、変換されたオブジェクトのマーシャルメソッドを起動することにより、ログデータを、ニュートラルバイナリフォーマットで処理して操作することができる。
このようなバイナリデータは、中央レポジトリ１０５に記憶されてもよい。
第５に、このログデータファイルが、中央データコレクタにフェッチされると、変換されたオブジェクトに関連付けられたデマーシャルを、続いて起動し、元のオブジェクトの復元を行うことができる。
【０１３７】
中央レポジトリ１０５は、最終的なログデータ記憶サイトである。
中央レポジトリ１０５のデータベースの実施の形態では、このデータベースを使用して、さまざまなコンピュータデバイスに位置するさまざまなプロセスからのログデータを有利に構造化することができる。
これは、さまざまな型のセマンティックス上の関係に従うことによってデータベース内で行うことができる。
さらに、ＳＱＬデータベース言語をデータ操作およびデータ分析用に使用することもできる。
ＳＱＬデータベース言語は、システムの特徴付けの段階、および、分析終了時の結果提示段階の双方で、記憶されたログデータの検索および操作を行う汎用で効率的なＡＰＩ（アプリケーションプログラムインターフェース）を提供することができる。
【０１３８】
図１０は、選択的な監視フレームワークの監視の実施の形態のプロセス図１０００である。
この実施の形態では、収集されるデータ量を削減するために、最小限のデータログ記録を行うことができる。
一定のプローブ構成を使用するシステム監視は、かなりの量のログデータを収集することができる。
これは、監視中のシステムの性能および挙動に影響を与えることがある。
さらに、同時監視プローブは、潜在的に互いに干渉し合う可能性があり、したがって、監視結果の正確度に影響を与える可能性がある。
例えば、アプリケーションセマンティック監視プローブは、ＣＰＵ監視およびタイミング待ち時間監視の双方に監視のオーバーヘッドを不可避的に導入する。
したがって、プローブにより生成されるデータを、基本的な監視に重要な部分のみに削減することが望ましい場合がある。
加えて、プローブを有効または無効にすることを、実行中の監視に基づいて動的に可能にすることにより、監視をさらに合理化してもよい。
【０１３９】
監視プロセス１０００は、監視コーディネータ１００４を含む。
この監視コーディネータ１００４は、あらゆるユーザ（クライアント）プロセスおよびサーバプロセスが生成される前に開始され、常時、実行されている。
監視コーディネータ１００４は、イベントチャネル１０１１を生成する。
次いで、監視コーディネータ１００４は、イベントサプライヤスレッド１００７を生成する。
イベントサプライヤスレッド１００７は、入力インターフェース（例えばキーボード）からユーザコマンドを受け取ることができ、そのイベントをイベントチャネル１０１１にプッシュすることができる。
監視コーディネータ１００４の生成後、ユーザのクライアントプロセスおよびサーバプロセスが開始される。
サーバプロセスまたはクライアントプロセスは、イベントコンシューマスレッド１０２１または１０２９を生成することができる。
このイベントコンシューマスレッドは、イベントチャネル１０１１からイベントを引き出し、その後の動作を実行する。
【０１４０】
例えば、このプロセス図では、イベントチャネル１０１１が、最初に生成され、次に、イベントサプライヤスレッド１００７が、アプリケーション呼び出しによって生成される。
イベントが、イベントチャネル１０１１に発行され、発行後、クライアントプロセス１０２７およびサーバプロセス１０１４は、それぞれ、イベントコンシューマスレッド１０２９および１０２１を生成することができる。
イベントコンシューマスレッド１０２９および１０２１は、同時に生成されてもよいし、異なる時刻に生成されてもよい。
各コンシューマスレッドは、イベントチャネルを常時リスンし、イベントがイベントチャネル１０１１に発行されると、そのイベントを引き出す。
次いで、各プロセスは、コンシューマスレッドが受け取ったイベントに基づいて、対応するプローブをオン／オフする。
【０１４１】
図１１は、選択的な監視フレームワークの状態遷移図１１００である。
この図は、４つの異なる監視の型（アプリケーションセマンティック、メモリ使用量、ＣＰＵ使用量、およびタイミング待ち時間）を示している。
各監視の型は、柔軟にオンまたはオフにすることができる。
８つの異なる監視イベントが存在する。
すなわち、ＡｐｐｌｉｃａｔｉｏｎＳｅｍ＿ＯＮ（アプリケーションセマンティックオン）、ＡｐｐｌｉｃａｔｉｏｎＳｅｍ＿ＯＦＦ（アプリケーションセマンティックオフ）、Ｌａｔｅｎｃｙ＿ＯＮ（待ち時間オン）、Ｌａｔｅｎｃｙ＿ＯＦＦ（待ち時間オフ）、ＣＰＵ＿ＯＮ（ＣＰＵオン）、ＣＰＵ＿ＯＦＦ（ＣＰＵオフ）、Ｍｅｍｏｒｙ＿ＯＮ（メモリオン）、およびＭｅｍｏｒｙ＿ＯＦＦ（メモリオフ）が存在する。
開始状態では、監視コーディネータ１００４が開始する。
図１１に示す状態遷移図は、この開始状態から開始して、監視の型を選択するための状態プロトコルを記述している。
【０１４２】
「Ｌａｔｅｎｃｙ＿ＯＮ」コマンドが、監視コーディネータ１００４によって発行され、各コンシューマスレッドによってサブスクライブされると、監視システムは、待ち時間の測定を選択する。
また、このことは、「ＣＰＵ＿ＯＮ」および「Ｍｅｍｏｒｙ＿ＯＮ」に対しても当てはまる。
選択的な監視フレームワークでは、各監視セッションに対して単一の監視の型を選択することができる。
監視セッションは、「開始」から「通常」への遷移の時間間隔、または、「通常」から「通常」に戻る遷移の時間間隔として定義される。
監視コーディネータ１００４が、「Ｌａｔｅｎｃｙ＿ＯＦＦ」、「ＣＰＵ＿ＯＦＦ」、または「Ｍｅｍｏｒｙ＿ＯＦＦ」という監視オフイベントを発行した後に、その監視の型は終了し、システムは、有限時間内に通常状態１１３７に移行する。
システムは、通常状態１１３７から、他の任意の型の監視に遷移することができるが、通常状態１１３７に戻らないわけではない。
各イベントレシーバが、監視フラグをオンまたはオフにグローバルに設定し、その結果、このフラグは、指定された対応する監視の型に関するプロセス全体から見ることができる。
【０１４３】
その結果、タイミング待ち時間監視、共有資源使用量監視、アプリケーションセマンティック監視、および因果関係監視を選択的に有効および無効にすることができる。
さらに、スタブ開始プローブ、スケルトン開始プローブ、スケルトン終了プローブ、およびスタブ終了プローブを選択的に有効および無効にすることができる。
【０１４４】
通常動作では、クライアントプロセスまたはサーバプロセスが「オフ」イベントを受け取る直前に、関数の起動が行われる場合もあり得る。
この関数の起動は、後続する一連の関数起動をトリガすることがあり、したがって、分散システム１００全体にわたって動的に生成される一連のスレッドの発行を引き起こすことがある。
その結果、分散システム１００の「通常」状態の範囲または持続期間を決定することが、不可能ではないが、困難になる。
たとえ「オフ」イベントの実行が可能とされており、「オフ」イベントが設定されていても、これらの関数およびスレッドの実行および監視は避けられない。
したがって、場合によっては、「オフ」イベントが設定された後、「通常」状態にすぐに達するべきではない。
【０１４５】
「通常」状態の範囲をまったく決定できないということに対処するために、監視およびアナライザ１１０は、監視結果が一貫性のあることを保証できるように設計されるか、または、「通常」状態に達することができないことを検出してユーザに報告するように設計される。
「通常」状態に達することができないことが報告されると、監視が「通常」状態に達するまで待つことにより、システム監視の次の実行において、矛盾を回避することができる。
【０１４６】
一貫性は、２つの基準によって定義される。
基準１は、必要な監視が状態遷移によって中断されないことであり、基準２は、必要な監視が、状態遷移により干渉されないことである。
【０１４７】
基準１は、因果オーバライディング（causal overriding）と呼ばれる技法によって常に保証される。
関数が、別の関数によって起動されるか、または、スレッドが、別のスレッドによって生成されると、因果関係が、その関数の呼び出し側／被呼び出し側の関係およびそのスレッドの親／子関係を含めて、連続的に追跡される。
「オフ」イベントを受け取った後、関数が、監視の作動を必要とする別のアクティブな関数からまだ呼び出されている場合、または、関数が、スレッドの親スレッドが監視の作動を必要とする当該スレッドに含まれる場合には、この関数は、それぞれの監視をローカルにオンにする。
この基準は、アプリケーションイベントまたはデバッガフックを介して設定することができる。
【０１４８】
監視フレームワークプロセスのインスツルメンテーションプローブが、元のアプリケーションと共有資源を得るために競合すると、干渉が発生する。
アプリケーションセマンティックス監視の場合、共有資源使用量は関係しないので、基準２は自動的に満たされる。
共有資源使用量（例えばＣＰＵ使用量およびヒープメモリ使用量）の監視の型は、スレッドベースであるので、基準２は、共有資源使用量の監視によって補償することができる。
共有資源使用量監視の場合、監視が、２つの異なるスレッドで同時に行われると、スレッド間の干渉は発生し得ない。
残るは、スレッド内部の干渉のみである。
スレッド内部の実行は、常に逐次的であるので、プローブ（すなわち干渉）で費やされるリソースは、ログ記録に記録することができ、アナライザ１１０によって後に控除することができる。
【０１４９】
タイミング待ち時間の監視の場合、同じプロセッサ上で同時に実行され、異なるグローバル因果識別子を有する複数の関数が存在すると、干渉を容易に測定して補償することはできない。
タイミング待ち時間の干渉は、スレッド、プロセス、およびプロセッサの境界にまたがっていることから、この困難さが存在する。
その結果、タイミング待ち時間の干渉は、システム全体に及ぶことがある。
この場合、ログデータが、スタブおよびスケルトンの双方で関数起動の開始および終了を捕捉すると、特定の関数が、別の関数の起動によりインターリーブされるかどうかを判断することができる。
インターリーブが発生すると、そのインターリーブは、ユーザに提示される報告の一部となり、ユーザは、実行中のオン／オフプローブを使用することにより、干渉を低減または除去する動作を取ることができる。
【０１５０】
したがって、本発明のこの実施の形態によると、システムへの影響を最小にして、ユーザが真に所望する程度にだけ監視フレームワークを制限するために、ユーザまたはアプリケーションは、さまざまな監視の型、例えば実行時間およびタイミング待ち時間を制御することができる。
例えば、ユーザは、多くの処理時間が必要とされる場合に、時に、監視機能の１つまたは複数のものをオフにしたいことがある。
これは、アプリケーションを実行するホストコンピュータデバイスの影響を低減するために行うことができる。
同様に、時に、ユーザが、アプリケーションのランタイム実行に関するより多くの情報を所望する場合には、ユーザは、データを追加して収集するために、監視の型のより多くのものをオンにすることができる。
例えば、システムが、多くの例外に遭遇している場合、ユーザは、より多くの監視を有効にすることを選択して、その根本的原因を理解することができる。
【０１５１】
スレッドライブラリのインスツルメンテーションプローブおよびメモリ管理サブシステムのインスツルメンテーションプローブは、常設されるように構成することができる。
一方で、それらのプローブは、スタブおよびスケルトンの内部のプローブに対処するため、したがって、監視のオーバーヘッドおよび干渉を最小にするために、ある程度はオンまたはオフにできるように実施することもできる。
【０１５２】
図１１の監視フレームワークは、選択的なコンポーネント監視を行うために使用することもできる。
その場合、ユーザは、あるソフトウェアコンポーネントに対して監視オペレーションをオンまたはオフにすることを指定することができる。
選択的なコンポーネント監視の場合、イベントは、［ホスト，インターフェース，関数，オン］または［ホスト，インターフェース，関数，オフ］として符号化することができる。
このインターフェースフィールドおよび関数フィールドは、監視する関数および関連付けられたインターフェースを指定する。
ホストフィールドは、その特定のコンピュータデバイスから起動された関数のみが監視されることを示す。
最初の３つのフィールドのいずか１つを不在にして、ワイルドカード演算子（例えば「＊」）に置き換えることができる。
このワイルドカード演算子は、あらゆるホスト、あらゆるインターフェース、またはあらゆる関数と解釈することができる。
このようなイベントが、このフレームワークを通じてシステム全体にブロードキャストされると、監視システムは、特定の関数を有効または無効にすることができる。
【０１５３】
図１１は、選択的なコンポーネント監視に適用することができ、対応するイベントは、この場合、［ホスト，インターフェース，関数，オン］および［ホスト，インターフェース，関数，オフ］となる。
因果オーバライディングは、基準１を満たすために依然として適用される。
一般的に、基準２は、上述したタイミング待ち時間監視に対する提言した取り扱いと同様に、アナライザのフィードバックを通じた干渉回避により満たすことができる。
その上、コンポーネント監視（例えばコンポーネントＡ）およびデータ型監視（例えばＣＰＵ使用量）を重ね合わせて、包括的な選択的監視フレームワークを形成することができる。
その結果、ユーザは、監視オペレーションを自身のニーズに合わせるために、双方の監視態様を制御することができる。
【０１５４】
本発明の監視および特徴付けは、いくつかの主要な利点をもたらす。
１つの利点は、統合フレームワークにおいて、アプリケーション中心で、かつ、スレッドベースの多次元の挙動監視および特徴付けを行うことである。
この監視／特徴付けシステムは、ユーザ定義の関数呼び出しに基づいている。
監視は、因果関係の復元に加えて、システムの挙動の特徴付けを行うことを含み、このシステム挙動の特徴付けには、１）アプリケーションセマンティックス（すなわち、関数の入出力パラメータ、ランタイム実行中に発生する例外など）、２）関数実行のエンドツーエンドのタイミング待ち時間、ならびに３）関数呼び出しごとのＣＰＵ消費量、ヒープメモリ使用量、および他の共有資源の消費量が含まれる。
【０１５５】
別の利点は、スレッド化されたアプリケーションの因果追跡のために、資源の消費量およびタイミング伝搬をシステム全体で捕捉することである。
追跡される２つの型の因果関係は、関数の呼び出し側／被呼び出し側の関係およびスレッドの親子関係である。
分散システム１００のこのような因果関係を特定することにより、分散システム１００のタイミング待ち時間の伝搬および資源消費量を捕捉して記録することができる。
【０１５６】
本発明のさらに別の利点は、本発明による監視が、ハードウェアプラットフォームから独立しており、オペレーティングシステムから独立しており、通信プロトコルから独立しており、かつ、ネットワークに設けられたグローバルな同期クロックを必要としないことである。
したがって、本発明により、ネットワークの全プロセスのランタイム監視が可能になり、マルチスレッドでマルチプロセスのマルチプロセッサ化された関数であっても、ランタイム監視が可能になる。
【０１５７】
さらに別の利点は、ＩＤＬコンパイラにより自動的にプローブが挿入されること、および、プローブの作動／作動停止が柔軟に行われることである。
ＩＤＬコンパイラは、ソフトウェアプローブをシステムコード基盤に自動的に挿入することができる。
柔軟なプローブの作動／作動停止は、コンパイル時またはランタイム時に行うことができる。
インターフェースを特定でき、インターフェース関数を特定でき、監視の型（アプリケーションセマンティック監視、タイミング待ち時間監視、ＣＰＵ消費量／ヒープメモリ使用量の監視、またはこれらのある組み合わせ）を特定できる。
その上、ログデータの情報量を制御するために、システムの実行中にプローブをオンまたはオフにできるように、プローブを設計することができる。
【０１５８】
さらに別の利点は、例えばＣＯＲＢＡ、ＣＯＭ／ＤＣＯＭおよびＲＭＩといったコンポーネント技術を利用することにより、本発明が、真に分散したアプリケーションシステムを取り扱うことができることである。
その結果、アプリケーションシステムは、マルチスレッド化可能であり、さまざまなプロセスに分割可能であり、さまざまなプロセッサ上で実行可能であり、さまざまなオペレーティングシステムによるスケジューリングおよび管理が可能である。
【図面の簡単な説明】
【０１５９】
【図１】本発明の一実施の形態による分散コンピュータシステムの図である。
【図２】本発明の一実施の形態による監視方法のフローチャートである。
【図３】スタブおよびスケルトンの設計図である。
【図４】単一のスレッドの監視プロセスの時系列ステップを示す。
【図５】因果トレースの関係搬送のプロセス図である。
【図６】関数の呼び出し側／被呼び出し側の関係を追跡する実行シーケンス方法のフローチャートである。
【図７】親スレッドから子スレッドへログデータを搬送する方法のフローチャートである。
【図８】関数の呼び出し側／被呼び出し側の関係の判断を示す状態遷移図である。
【図９】データの蓄積および記憶のプロセス図である。
【図１０】収集されるデータ量を削減するために、最小限のデータログ記録を行うことができる選択的な監視フレームワークの監視の実施の形態のプロセス図である。
【図１１】選択的な監視フレームワークの状態遷移図である。
【符号の説明】
【０１６０】
１００・・・分散コンピュータシステム、
１０１〜１０３・・・プロセス、
１０５・・・ログ記憶装置、
１１０・・・アナライザ、
１１３〜１１５・・・ログ記憶ファイル、
１１９・・・フロントエンドプレゼンテーションインターフェース、
３００・・・スタブおよびスケルトン、
５０５・・・クライアント、
５０８・・・スタブ開始プローブ１、
５１３・・・スケルトン開始プローブ３、
５１６・・・関数の実施、
５２２・・・子関数プローブ１、
５３５・・・記憶装置、
９０３・・・プロセス、
９０６・・・クライアント、
９０９・・・第２のオブジェクト、
９１２・・・第１のオブジェクト、
９１８・・・第３のオブジェクト、
９２２・・・ログ記憶装置、
【図１】
2005527008.tif 000003
【図２】
2005527008.tif 000004
【図３】
2005527008.tif 000005
【図４】
2005527008.tif 000006
【図５】
2005527008.tif 000007
【図６】
2005527008.tif 000008
【図７】
2005527008.tif 000009
【図８】
2005527008.tif 000010
【図９】
2005527008.tif 000011
【図１０】
2005527008.tif 000012
【図１１】
2005527008.tif 000013
【国際調査報告】
2005527008.tif 000014
2005527008.tif 000015
2005527008.tif 000016