(57)【要約】  リクエストをプロファイリングする方法及びシステムは、収集されたカーネルイベントに基づいて完全リクエストユニット及び半オープンリクエストユニットを含むリクエストユニットを生成すること（２０２）を含む。生成されたリクエストユニットは、カーネルイベント間の因果関係を記述する因果関係セットに基づいて配列される（２０４）。
2018538613.tif 000002
【特許請求の範囲】
【請求項１】
リクエストをプロファイリングする方法であって、
プロセッサを使用して、収集されたカーネルイベントに基づいて完全リクエストユニット及び半オープンリクエストユニットを含むリクエストユニットを生成すること（２０２）と、
カーネルイベント間の因果関係を記述する因果関係セットに基づいて前記生成されたリクエストユニットを配列すること（２０４）と、
を有する方法。
【請求項２】
リクエストユニットを生成することは、開始イベント及び終了イベントに基づいて半オープンリクエストユニットを生成することを含む、請求項１に記載の方法。
【請求項３】
リクエストユニットを生成することは、それぞれの開始イベントに一致する終了イベントに基づいて完全リクエストユニットを作成することをさらに含む、請求項２に記載の方法。
【請求項４】
リクエストユニットを生成することは、カーネルイベント間の因果関係を特徴付ける因果グラフに基づいて仮想完全リクエストユニットを生成することをさらに含む、請求項２に記載の方法。
【請求項５】
リクエストユニットを生成することは、前記因果グラフにおける、第１の半オープンリクエストユニット内の開始イベントと、第２の半オープンリクエストユニット内の終了イベントとの間の最短経路を検索することをさらに含む、請求項４に記載の方法。
【請求項６】
リクエストユニットを生成することは、前記開始イベント及び前記終了イベントが１つまたは複数の関連性規則に合致することを判定することをさらに含む、請求項５に記載の方法。
【請求項７】
前記因果関係セットは、少なくとも結果イベントタイプ及び原因イベントタイプを確立するイベント関連性規則を含む、請求項１に記載の方法。
【請求項８】
各イベント関連性規則は、結果イベントタイプ、原因イベントタイプ、時間規則、所有者規則及びイベントデータ規則を含む５タプルである、請求項７に記載の方法。
【請求項９】
前記配列されたリクエストユニットに応答して管理措置をとることをさらに有する、請求項１に記載の方法。
【請求項１０】
リクエストをプロファイリングするシステムであって、
収集されたカーネルイベントに基づいて完全リクエストユニット及び半オープンリクエストユニットを含むリクエストユニットを生成するように構成されたプロセッサを含むリクエストユニット生成モジュール（８０６）と、
カーネルイベント間の因果関係を記述する因果関係セットに基づいて前記生成されたリクエストユニットを配列するように構成されたリクエストユニット配列モジュール（８０８）と、
を有するシステム。
【請求項１１】
前記リクエストユニット生成モジュールは、開始イベント及び終了イベントに基づいて半オープンリクエストユニットを生成するようにさらに構成された、請求項１０に記載のシステム。
【請求項１２】
前記リクエストユニット生成モジュールは、それぞれの開始イベントに一致する終了イベントに基づいて完全リクエストユニットを作成するようにさらに構成された、請求項１１に記載のシステム。
【請求項１３】
前記リクエストユニット生成モジュールは、カーネルイベント間の因果関係を特徴付ける因果グラフに基づいて仮想完全リクエストユニットを生成するようにさらに構成された、請求項１１に記載のシステム。
【請求項１４】
前記リクエストユニット生成モジュールは、前記因果グラフ内の、第１の半オープンリクエストユニット内の開始イベントと、第２の半オープンリクエストユニット内の終了イベントとの間の最短経路を検索するようにさらに構成された、請求項１３に記載のシステム。
【請求項１５】
前記リクエストユニット生成モジュールは、前記開始イベント及び前記終了イベントが１つまたは複数の関連性規則に合致することを判定するようにさらに構成された、請求項１４に記載のシステム。
【請求項１６】
前記因果関係セットは、少なくとも結果イベントタイプ及び原因イベントタイプを確立するイベント関連性規則を含む、請求項１０に記載のシステム。
【請求項１７】
各イベント関連性規則は、結果イベントタイプ、原因イベントタイプ、時間規則、所有者規則及びイベントデータ規則を含む５タプルである、請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、２０１５年１１月９日に出願された米国特許仮出願第６２／２５２６９２号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【０００２】
本発明は、マルチスレッドリクエストプロファイリングに関し、特に低レベルカーネルイベントに基づいてリクエストトレースを構築するエンドツーエンドリクエストプロファイリングの使用に関する。
【背景技術】
【０００３】
ソフトウェアがますます複雑になるにつれて、全ての関連構成要素の内部状態を予測することは、予期せぬ問題が発生したときにますます困難になる。実行フローの履歴を遡って調べることは煩雑であり、種々のハードウェアとソフトウェアとの組み合わせ、種々の作業負荷特性、並びに種々のエンドユーザの使用パターンの数が多すぎることが、問題をさらに複雑にしている。
【０００４】
リクエスト処理経路を発見する既存のシステムでは、例えばシステムの構成要素のスレッド及び通信動作を監視することで、様々な手法を用いている。既存のシステムは、ターゲットシステム内に存在する特定のシステムの実現及び特定のソフトウェアに依存することが多い。
【発明の概要】
【０００５】
リクエストをプロファイリングする方法は、プロセッサを使用して、収集されたカーネルイベントに基づいて完全リクエストユニット（complete request unit）及び半オープンリクエストユニット（half-open request unit）を含むリクエストユニットを生成することを含む。生成されたリクエストユニットは、カーネルイベント間の因果関係を記述する因果関係セット（causality relationship）に基づいて配列される。
【０００６】
リクエストをプロファイリングするシステムは、収集されたカーネルイベントに基づいて完全リクエストユニット及び半オープンリクエストユニットを含むリクエストユニットを生成するように構成されたプロセッサを含むリクエストユニット生成モジュール（request unit generating module）を含む。リクエストユニット配列モジュール（request unit sequencing module）は、カーネルイベント間の因果関係を記述する因果関係セットに基づいて生成されたリクエストユニットを配列するように構成されている。
【０００７】
これら及び他の特徴並びに利点は、以下の典型的な実施形態の詳細な説明を添付の図面と併せて読むことで明らかになるであろう。
【図面の簡単な説明】
【０００８】
本開示では、後述するように、以下の図面を参照しながら好ましい実施形態について詳細に説明する。
【０００９】
【図１】図１は、本発明の実施形態によるリクエストプロファイリングの方法のブロック／フロー図である。
【００１０】
【図２】図２は、本発明の実施形態によるリクエストユニット生成の方法のブロック／フロー図である。
【００１１】
【図３】図３は、本発明の実施形態によるリクエストユニットスライシングの方法のブロック／フロー図である。
【００１２】
【図４】図４は、本発明の実施形態による、仮想完全リクエストユニット（virtual complete request unit）を検索する方法のブロック／フロー図である。
【００１３】
【図５】図５は、本発明の実施形態によるリクエストユニット配列の方法のブロック／フロー図である。
【００１４】
【図６】図６は、本発明の実施形態によるリクエストユニット配列の方法のブロック／フロー図である。
【００１５】
【図８】図８は、本発明の実施形態によるリクエストプロファイリングシステムのブロック図である。
【００１６】
【図９】図９は、本発明の実施形態による処理システムのブロック図である。
【発明を実施するための形態】
【００１７】
本発明の原理の実施形態では、正確なリクエスト処理経路の発見を提供する。本発明の実施形態では分散アプリケーションについて論じるが、本発明の原理は任意の適切な処理システムに適用されもよいことが理解されよう。与えられたリクエストユニットは、複数のマシンにわたって分散されたサービスプロセス、同じデバイス上に存在するプロセスまたは単一のプロセス内の複数のスレッドに属する場合がある。本発明の実施形態では、システムレベルのオペレーティングシステムコールを含むコアカーネル関数（core kernel function）を計装することでサービスシステムにおけるリクエストのカーネル実行トレースを再構築する。
【００１８】
２つのタイプのリクエストユニットが設定可能なマーキングイベントセットに基づいて定義される。収集されたカーネルイベントトレースはスライスされ、イベントトレースはイベントセットに基づいて複数のスレッド毎のリクエストユニットに変換される。グラフ検索によって、仮想リクエストユニットがそれらのスレッド毎のリクエストユニットに基づいてスレッドプール内の複数のスレッドにわたって構築される。同じリクエストによって呼び出される全てのリクエストユニットがイベント因果関係に基づいて共にグループ化される。このような方法により、本発明の実施形態では小さいオーバヘッドを目的とし、エンドツーエンドのトレーシングが分散サービスシステムの構成要素内及び複数の構成要素にわたる個々のリクエストのフロー（経路及びタイミングを含む）を捕捉する。
【００１９】
次に、同じ数字が同一または同様の要素を表す図面として、まず図１を詳細に参照すると、図１には、リクエスト分析の方法が示されている。ブロック１０２は、ターゲットシステムからカーネルイベントトレースを収集する、カーネルイベント収集を実施する。カーネルイベントトレースは、他のルートによってシステムレベルのオペレーティングシステムコールも含む、コアカーネル関数を計装することで個々のサービスマシンから取得できる。
【００２０】
ブロック１０４は、ブロック１０２によって収集されたカーネルイベントトレースを分析することでエンドツーエンドのリクエストプロファイリングを実施する。ブロック１０４は、複数のマシンにわたって分散したサービスプロセス、単一のデバイス上に存在するプロセスまたは単一のプロセス内の複数のスレッド（例えば、単一のリクエストを協働的かつ集約的に実行するスレッドのプールの場合）に属するカーネルイベントを含む、エンドツーエンドリクエストトレースを構築する。
【００２１】
用語「協働的」及び「集約的」は、システムにおけるスレッドのグループ動作特性を指す。協働的動作とは、リクエストが２つ以上のスレッドによって協働的に処理されることを指す。協働的動作において、ワーカースレッドがパケットの送信及び受信を処理している間、１つのスレッドは、例えばコネクションを受け入れることができる。集約的動作とは、スレッド／プロセスのグループが、プール内のリクエストの処理において、同様の役割を果たし、順に交代することを指す。与えられたリクエストは非決定性の方法における多重スレッドを含んでいてもよい。
【００２２】
ブロック１０６は、ブロック１０４から出力されたリクエストトレースを分類する。トレースは、例えばブロック１０４で使用されるマーキングカーネルイベントに基づくグループ化リクエストによって分類できる。他の分類プロセスは、例えば分類を学習するためにデータマイニングクラスタリングを使用してもよい。
【００２３】
分散システムの複数の構成要素にわたる個々のリクエストのフロー（すなわち、経路及びタイミング）を捕捉するエンドツーエンドリクエストトレースの出力は、多くの異なる目的に用いることができる。そのような目的の１つは、ソフトウェアの開発中及び開発後のデバッグであり、その場合、リクエストトレースはバグの発生箇所及びバグの対処方法を決定することを可能にする。リクエストトレースのもう１つの可能性のある用途は、性能ボトルネックが発生している箇所を決定するボトルネック分析である。リクエストトレースは、また与えられたリクエストの処理に、与えられたデバイスが含まれているか否か、並びに各構成要素に費やされた時間を決定するために使用できる。リクエストトレースによる異常を検出するために、機械学習及びデータマイニングを用いてもよく、異常な活動が発生するときが認識される。
【００２４】
加えて、リクエストトレースに基づく自動システム管理を実施することが可能であり、リクエストトレースに基づいて管理措置がとられる。典型的な管理措置は、例えばリクエストユニットの処理に起因してシステム負荷が高いデバイスに追加の計算リソースを提供するシステムリソース配分、例えばセキュリティレベルを上昇させ、異常な活動が検出されたときにセキュリティ警告を発行する等のセキュリティ緩和措置、並びに、例えば特定のデバイスの負荷が重いときに冷却を増大する、または冷却材の流量配分を変更する環境制御措置を含む。
【００２５】
次に、図２を参照すると、図２にはブロック１０４のエンドツーエンドリクエストプロファイリングに関するさらなる詳細が示されている。具体的には、ブロック２０２は設定可能なマーキングイベントセットに基づいて収集されたカーネルイベントから２つのタイプのリクエストユニットを生成する。ブロック２０２は、また仮想リクエストユニットをそれらのスレッド毎のリクエストユニットに基づいて、スレッドプール内の複数のスレッドにわたって構築する。ブロック２０４は、リクエストユニット間のマーキングイベントセット及び時間的関係で定義される因果関係に基づき、関連リクエストユニットを構成することでフル経路リクエストトレースを構築する。
【００２６】
次に、図３を参照すると、図３にはブロック２０２のリクエストユニット生成に関するさらなる詳細が示されている。具体的には、ブロック３０２は収集されたカーネルイベントを前処理する。カーネルイベントは、カーネルイベントが発生する時刻によって順序付けされた、それらのスレッド毎のイベントシーケンスによって編成される。これは、スレッドまたはプロセスがプロセッサ上で作動する時刻を伝達するコンテキストスイッチカーネルイベントに基づいて達成できる。オリジナルのカーネルイベントは、カーネルイベントが発生したときの情報とカーネルイベントが発生するプロセッサに関する情報とを含む。前処理後、各カーネルイベントを提示するために５タプル（tuple）のイベントレコードが生成される。典型的な５タプルフォーマットは、＜ｏｗｎｅｒ  ＩＤ，ｔｉｍｅ＿ｂｅｇｉｎ，ｔｉｍｅ＿ｅｎｄ，ｅｖｅｎｔ  ｔｙｐｅ，ｅｖｅｎｔ  ｄａｔａ＞である。
【００２７】
用語「ｏｗｎｅｒ  ＩＤ」は、イベント所有者の識別情報を指し、マシン名（例えば、マシンのＭＡＣまたはＩＰアドレス）、プロセスＩＤ（例えば、イベントがスレッドによって生成される場合はスレッド識別子）及び任意のプロセス名を含んでいてもよい。この識別子は、いずれのマシンでイベントが生成されたか、及びいずれのプロセスでイベントが生成されたかを記述する。
【００２８】
用語「ｔｉｍｅ＿ｂｅｇｉｎ」は、カーネルイベントが開始する時刻を指す。
【００２９】
用語「ｔｉｍｅ＿ｅｎｄ」は、カーネルイベントが終了する時刻を指す。
【００３０】
用語「ｅｖｅｎｔ  ｔｙｐｅ」は、カーネルイベントタイプを指す。カーネルイベントタイプの例は、限定されるものではないが、ネットワークイベント（例えば、ＴＣＰ＿ＳＥＮＤ及びＴＣＰ＿ＲＥＣＶ）、プロセスイベント（例えば、ＰＲＯＣＥＳＳ＿ＣＲＥＡＴＥ）及びシステムコールイベントを含む。アプリケーション関数の開始または終了のようなアプリケーションプログラム実行イベントも特定のロギングツールを通してカーネルイベントとして収集できる。ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＮＴＥＲ及びＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＸＩＴのような特別なイベントタイプを、それらのアプリケーションイベントのために定義できる。
【００３１】
用語「ｅｖｅｎｔ  ｄａｔａ」は、カーネルイベントタイプと関連付けられる任意の追加の情報を指す。ｅｖｅｎｔ  ｄａｔａの例は、限定されるものではないが、ネットワークイベントデータ（例えば、宛先ＩＰアドレス、発信元ＩＰポート、宛先ＩＰポート、パケットサイズ等のようなＴＣＰ＿ＳＥＮＤ及びＴＣＰ＿ＲＥＣＶのためのネットワークフローデータ）、プロセス間通信イベントデータ（例えば、ＰＩＰＥ＿ＷＲＩＴＥ及びＰＩＰＥ＿ＲＥＡＤのための＜ＩＤ，ｓｉｚｅ＞）、プロセスイベントデータ（例えば、ＰＲＯＣＥＳＳ＿ＣＲＥＡＴＥのための子プロセス識別情報）、システムコールイベントデータ（例えば、ｒｅａｄ及びｗｒｉｔｅのようなシステムコール関数名）、並びにアプリケーションイベントデータ（例えば、ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＮＴＥＲ及びＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＸＩＴの関数識別子）を含む。
【００３２】
ブロック３０２の出力は、所有者ＩＤによって記述されたスレッドのセットであり、各スレッドは時間で順序付けされているイベントレコードシーケンスを有し、イベントレコードはスレッドと同じ所有者ＩＤを有している。
【００３３】
ブロック３０４は、４タプルレコード＜ｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅ，ｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅ，ｏｗｎｅｒ＿ｆｉｌｔｅｒ，ｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒ＞で表現されるリクエストユニットマークを含む、マーキングイベントセットを定義する。
【００３４】
用語「ｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅ」は、リクエストユニットの最初のイベントが厳密に一致しなければならないイベントタイプを指す。ｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅの例は、限定されるものではないが、ネットワークイベントタイプ（例えば、ＴＣＰ＿ＲＥＣＶ）、プロセス間通信イベントタイプ（例えば、ＰＩＰＥ＿ＷＲＩＴＥ）、プロセスイベントタイプ（例えば、ＰＲＯＣＥＳＳ＿ＣＲＥＡＴＥ）、システムコールイベントタイプ（例えば、ＫＷＡＫＥＵＰ）、並びにアプリケーションイベントタイプ（例えば、ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＮＴＥＲ）を含む。
【００３５】
用語「ｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅ」は、リクエストユニットの最後のイベントが厳密に一致しなければならないイベントタイプを指す。ｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅと同様に、ｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅの例は、限定されるものではないが、ネットワークイベントタイプ、プロセス間通信イベントタイプ、プロセスイベントタイプ、システムコールイベントタイプ及びアプリケーションイベントタイプを含む。
【００３６】
用語「ｏｗｎｅｒ＿ｆｉｌｔｅｒ」は、リクエストユニットの最初のイベント及び最後のイベントが部分的にまたは厳密に一致しなければならない所有者ＩＤを指す。ｏｗｎｅｒ＿ｆｉｌｔｅｒの例は、限定されるものではないが、特定のスレッド名（例えば、ｈｔｔｐｄ）、特定のスレッドＩＤ番号またはワイルドカード（例えば、いずれの所有者ＩＤにも一致する「＊」）を含む。
【００３７】
用語「ｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒ」は、リクエストユニットの最初のイベント及び最後のイベントが部分的にまたは厳密に一致しなければならないイベントデータを指す。ｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒの例は、限定されるものではないが、ネットワークイベントデータ（例えば、ＴＣＰ＿ＳＥＮＤまたはＴＣＰ＿ＲＥＣＶの［ｓｏｕｒｃｅ  ＩＰ  ｐｏｒｔ＝８０］）、プロセス間通信イベントデータ（例えば、ＰＩＰＥ＿ＷＲＩＴＥまたはＰＩＰＥ＿ＲＥＡＤのワイルドカード）、並びにアプリケーションイベントデータ（例えば、ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＮＴＥＲ及びＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＸＩＴの［Ｆｕｎｃｔｉｏｎ  ＩＤ＝１０００］）を含む。このフィールド内のワイルドカードはいずれのイベントデータとも一致する。イベントデータフィルタは、最初のイベントと最後のイベントとで異なっていてもよい。
【００３８】
ブロック３０４の出力は、ブロック３０２からのイベントレコードシーケンス内のリクエストユニットの始まり及び終わりを検出するために使用されるリクエストユニットマークのセットである。
【００３９】
ブロック３０６はリクエストユニットをスライスする。１つのリクエストユニットは、時間的に順序付けされているイベントシーケンスデータ構造＜Ｓ＞を通じて定義される。Ｓは１つのスレッドのイベントレコードサブシーケンスである。スライシングは、始まりまたは終わりのいずれかが検出されており、両方が検出されていない半オープンリクエストユニットと、始まりと終わりの両方が検出されている完全リクエストユニットの、２つのタイプのリクエストユニットの経過を追う。ブロック３０６は、スレッドのイベントシーケンス内のイベントを次々にスキャンし、開始イベントタイプ及び終了イベントタイプのイベントマークを有するイベントをチェックし、その最初の開始または終了イベントが検出されると、新たな半オープンリクエストユニットを作成し、開始イベントのみを有するオープンリクエストユニットの終了イベントが検出されると、オープンリクエストユニットを完全リクエストユニットとしてクローズする。リクエストユニットスライシングのさらなる詳細は下記で提供される。ブロック３０６は、２つの検出されたタイプのリクエストユニットを出力する。
【００４０】
ブロック３０８は、仮想完全リクエストユニットを、ブロック３０６によって供給されるスレッド毎の半オープンリクエストユニットに基づき、与えられたマシンにおける複数のスレッドにわたって構築する。ブロック３０８は、まずリクエストユニットの対を、それらの開始または終了イベントレコードに基づいて発見する。各対に関して、ブロック３０８は、カーネルイベント及びリクエストユニットからの２つのイベントに基づいて因果グラフ（causality graph）を構築する。ブロック３０８は、２つのリクエストユニットの開始イベントから終了イベントまで因果グラフにおける経路を検索する（デフォルトの検索経路はトラバースされるリンク内の最短経路であってもよい）。そのような経路が存在する場合、ブロック３０８は発見された経路に対応する仮想完全リクエストユニットを構築する。
【００４１】
次に、図４を参照すると、図４にはブロック３０６のリクエストユニットのスライシングに関するさらなる詳細が示されている。ブロック４０２は、スレッド内の先頭イベントを選択する。この初期化された空のリクエストユニットは、ＲＵｇｌｏｂａｌＣｏｍｐｌｅｔｅ及びＲＵｇｌｏｂａｌＨａｌｆＯｐｅｎを設定し、スレッドｐのイベントレコードシーケンスＥｐから最初のイベントレコードｅｃを選択する。ブロック３０４からのマーキングイベントセットＭにおける各リクエストユニットマークＭｉに関して、ブロック４０４は、Ｍｉのｏｗｎｅｒ＿ｆｉｌｔｅｒがｐの所有者ＩＤと一致するか否かをチェックし、一致する場合はＭｉのｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅがｅｃのイベントタイプに一致するか否かをチェックし、かつＭｉにおけるｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒがｅｃのイベントデータに一致するか否かをチェックすることで、イベントレコードｅｃをマーキングイベントセットと比較する。
【００４２】
両方が一致する場合、これは新たなリクエストユニットではなく、ブロック４１４は、ＲＵｈａｌｆＯｐｅｎにおける任意のリクエストユニットＲが、そのイベントレコードシーケンスＳにおいて、Ｍｉ内のｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅ及びｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒに一致する開始イベントレコードを有するか否かをチェックする。そのようなリクエストユニットＲが存在する場合、ブロック４１４は、ＲがそのイベントレコードシーケンスＳにおいて、Ｍｉ内のｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅ及びｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒに一致する何らかのイベントレコードを有するか否かをチェックする。有する場合、イベントレコードｅＲが、最後のそのようなイベントレコードとなるように割り当てられる。ｔｉｍｅ＿ｂｅｇｉｎ（ｅｃ）−ｔｉｍｅ＿ｂｅｇｉｎ（ｅＲ）＞Δ（設定可能な時間閾値）である場合、ブロック４１６は、ＲをＲＵｈａｌｆＯｐｅｎからＲＵｃｏｍｐｌｅｔｅへと移動させて完全リクエストユニットを作成し、ブロック４１８においてＲＵｈａｌｆＯｐｅｎ内に新たなリクエストユニットＮが作成され、ｅｃが開始イベントレコードとしてＮのイベントレコードシーケンス内に挿入され、Ｍｉが開始マークとしてＮのリクエストユニットマークセット内に挿入される。ブロック４１０は、スレッド内にさらなるイベントが存在するか否かを判定する。存在する場合、処理はスレッドｐのイベントシーケンスにおける次のイベントと共にブロック４０４に戻る。
【００４３】
ブロック４０６が代わりに新たなリクエストユニットを検出した場合、ブロック４０８は、Ｍｉ内のｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅがｅｃのイベントタイプに一致するか否かをチェックし、かつＭｉ内のｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒがｅｃのイベントデータに一致するか否かをチェックする。両方が一致する場合、並びにＲＵｈａｌｆＯｐｅｎ内の任意のリクエストユニットＲがそのイベントレコードシーケンスＳにおけるＭｉ内のｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅ及びｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒに一致する開始イベントレコードを有する場合、ブロック４０６は、シーケンス内に重複コピーを有しない場合はｅｃをＮのイベントレコードシーケンスにおける終了イベントレコードとして更新し、Ｍｉを終了マークとしてＮのリクエストユニットマークセットに挿入する。そうでない場合、ブロック４０６はＲＵｈａｌｆＯｐｅｎにおける新たなリクエストユニットＮを作成する。ここで、ｅｃはＮのイベントレコードシーケンスＳにおける終了イベントレコードとしてマークされ、ブロック４０６はＭｉを終了マークとしてＮのリクエストユニットマークセットに挿入する。ブロック４１０は、スレッドｐ内にまだイベントが存在するか否かを判定し、存在する場合、処理はブロック４０４に戻り、新たなイベントが選択される。
【００４４】
ＲＵｈａｌｆＯｐｅｎにおける開始イベントレコードと終了イベントレコードの両方を有する任意のリクエストユニットは、ＲＵｇｌｏｂａｌＣｏｍｐｌｅｔｅに移動させられる。リクエストユニットを移動することは、対応するスレッドのイベントレコードシーケンスから開始イベントレコードと終了イベントレコードとの間の中間イベントを補うことを含む。ＲＵｈａｌｆＯｐｅｎにおける任意の残りのリクエストユニットがＲＵｇｌｏｂａｌＨａｌｆＯｐｅｎに移動させられる。
【００４５】
スレッドにおける全てのイベントが処理されると、ブロック４１２は処理すべきさらなるスレッドが存在するか否かを判定する。存在する場合、新たなスレッドｐが選択されて、処理がブロック４０２に戻る。存在しない場合、２つのタイプのリクエストユニットが出力され、ＲＵｇｌｏｂａｌＣｏｍｐｌｅｔｅにおけるリクエストユニットが検出された完全リクエストユニットとして出力され、ＲＵｇｌｏｂａｌＨａｌｆＯｐｅｎにおけるリクエストユニットが開始イベントレコードまたは終了イベントレコードのいずれか一方が検出されているが両方は検出されていない、検出された半オープンリクエストユニットとして出力される。
【００４６】
次に、図５を参照すると、図５にはブロック３０８の仮想完全リクエストユニットの検索に関するさらなる詳細が示されている。ブロック５０２は、開始レコードのみを有するリクエストユニットＲＵｂｅｇｉｎのセットから半オープンリクエストユニットＲｉを選択することで開始する。そのような各半オープンリクエストユニットに関して、ブロック５０４は終了イベントレコードのみを有するリクエストユニットのセットから、一致するリクエストユニットＲｊが存在するか否かを判定する。ブロック５０４は、２つのイベントが同じデバイスの２つの異なるスレッドに属する場合、リクエストユニットマークＭｉのｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅがＲｉの開始イベントタイプに一致する場合、Ｍｉ内のｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒがＲｊの開始イベントデータに一致する場合、Ｍｉ内のｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅがＲｊの終了イベントタイプに一致する場合、かつＭｉ内のｅｖｅｎｔ＿ｄａｔａ＿ｆｉｌｔｅｒがＲｊの終了イベントデータに一致する場合、ＲｉがＲｊに一致すると判定する。一致が存在しない場合、ブロック５０９はＲＵｂｅｇｉｎからＲｉを除去する。
【００４７】
ブロック５０４が一致を検出した場合、ブロック５０６はＲｉとＲｊとを接続する因果グラフを構築する。イベントｅｂｅｉｎｇがＲｉの開始イベントレコードとして割り当てられ、イベントｅｅｎｄがＲｊの終了イベントレコードとして割り当てられる。因果グラフＧ＝（Ｖ，Ｅ）は、収集されたカーネルイベントトレースＥに基づいて構築される。Ｒｉと同じマシンにおける各スレッドに関して、スレッドのサブグラフは各イベントｅｃがｔｉｍｅ＿ｂｅｇｉｎ（ｅｃ）≧ｔｉｍｅ＿ｂｅｇｉｎ（ｅｂｅｇｉｎ）及びｔｉｍｅ＿ｅｎｄ（ｅｃ）≦ｔｉｍｅ＿ｅｎｄ（ｅｅｎｄ）を満たすイベントノード（すなわち、開始イベントと終了イベントとの間に発生する各イベント）から形成される。ｅｃは、ｅｂｅｇｉｎ、ｅｅｎｄ、プロセス間通信イベント、プロセスイベント、またはコンテキストスイッチイベントのうちの１つである。有向リンクは、サブグラフ内の各イベントノードを時系列順に次のイベントノードと接続する。
【００４８】
２つのスレッドのサブグラフの間に、ブロック５０６は、プロセス間通信イベントから、一致する通信パラメータを有する、該プロセス間通信イベントと時系列順で最も近いカウンターパートイベントへの有向リンクを形成する。有向リンクは、プロセスイベントから該プロセスイベントと最も近いイベントに対して形成される。有向リンクは、コンテキストスイッチイベントから、一致するパラメータを備えた、該コンテキストスイッチイベントと時系列順で最も近いカウンターパートイベントに対して形成される。
【００４９】
構築された因果グラフＧに基づいて、ブロック５０８は、ＲｉからＲｊへの経路を見つけるように試行する。トラバースされるリンクにおける最短経路を見つけるために、ダイクストラアルゴリズム（Dijkstra’s algorithm）のような任意の適切な方法を使用してもよい。そのような経路が発見された場合、ブロック５１０は、完全リクエストユニットを作成し、開始イベントがｅｂｅｇｉｎであり、終了イベントがｅｅｎｄであり、中間イベントが発見された経路のイベントである、そのリクエストユニットをＲＵｇｌｏｂａｌＣｏｍｐｌｅｔｅに追加する。その後、ブロック５０９は経路が発見されているか否かにかかわらずＲＵｂｅｇｉｎからＲｉを除去する。ＲＵｂｅｇｉｎにまだリクエストユニットが存在する場合、新たなＲｉが選択されて処理がブロック５０２に戻る。存在しない場合、ブロック５１２は、ＲＵｇｌｏｂａｌＣｏｍｐｌｅｔｅを検出されている完全リクエストユニットのセットとして出力する。
【００５０】
次に、図６を参照すると、図６にはブロック２０４のリクエストユニット配列に関するさらなる詳細が示されている。ブロック６０２は、各々が５タプルレコード＜ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅ，ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅ，ｔｉｍｅ＿ｒｕｌｅ，ｏｗｎｅｒ＿ｒｕｌｅ，ｅｖｅｎｔ＿ｄａｔａ＿ｒｕｌｅ＞として提示されるイベント関連性規則を含む因果関係セットを定義する。因果関係は、専門知識を通じて提供され得るイベント関連性規則を通じて定義される。
【００５１】
用語「ｃａｓｕｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅ」は、他のイベントを発生させることができるイベントのタイプを指す。ｃａｓｕｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅの例は、限定されるものではないが、ネットワークイベントタイプ（例えば、ＴＣＰ＿ＳＥＮＣＶ）、プロセス間通信イベントタイプ（例えば、ＰＩＰＥ＿ＷＲＩＴＥ）、プロセスイベントタイプ（例えば、ＰＲＯＣＥＳＳ＿ＣＲＥＡＴＥ）、システムコールイベントタイプ（例えば、ＫＷＡＫＥＵＰ）、並びにアプリケーションイベントタイプ（例えば、ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＮＴＥＲ）を含む。
【００５２】
用語「ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅ」は、他のイベントによって発生させられるイベントのタイプを指す。ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅの例は、限定されるものではないが、ネットワークイベントタイプ（例えば、ＴＣＰ＿ＲＥＣＶ）、プロセス間通信イベントタイプ（例えば、ＰＩＰＥ＿ＲＥＡＤ）、システムコールイベントタイプ（例えば、ＫＳＬＥＥＰ）、並びにアプリケーションイベントタイプ（例えば、ＡＰ＿ＦＵＮＣＴＩＯＮ＿ＥＸＩＴ）を含む。
【００５３】
用語「ｔｉｍｅ＿ｒｕｌｅ」は、ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅイベントとｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅイベントとを関係付けることができる時間的関係を指す。ｔｉｍｅ＿ｒｕｌｅの例は、限定されるものではないが、重複する時間的関係（例えば、ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ）＜ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｅｄ＿ｅｖｅｎｔ）及びｔｉｍｅ＿ｅｎｄ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ）＞ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｅｄ＿ｅｖｅｎｔ））、入れ子状の時間的関係（例えば、ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ）＜ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｅｄ＿ｅｖｅｎｔ）及びｔｉｍｅ＿ｅｎｄ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ）＞ｔｉｍｅ＿ｅｎｄ（ｃａｕｓｅｄ＿ｅｖｅｎｔ））、並びに分離した時間的関係（例えば、ｔｉｍｅ＿ｅｎｄ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ）＜ｔｉｍｅ＿ｂｅｇｉｎ（ｃａｕｓｅｄ＿ｅｖｅｎｔ））を含む。
【００５４】
用語「ｏｗｎｅｒ＿ｒｕｌｅ」は、所有者ＩＤに基づくｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅ及びｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅの関連性を指す。ｏｗｎｅｒ＿ｒｕｌｅの例は、限定されるものではないが、特定のマシン名（例えば、ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｏｗｎｅｒ＿ｍａｃｈｉｎｅＮａｍｅ＝ｓｒｃＩＰａｄｄｒｅｓｓ（ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｄａｔａ））、特定のスレッド名（例えば、ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｏｗｎｅｒ＿ｐｒｏｃｅｓｓＮａｍｅ＝ｈｔｔｐｄ）、特定のスレッドＩＤ（例えば、ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｏｗｎｅｒ＿ｔｈｒｅａｄＩＤ＝ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｏｗｎｅｒ＿ｔｈｒｅａｄＩＤ）、またはワイルドカード（いずれの所有者ＩＤにも一致する＊）を含む。
【００５５】
用語「ｅｖｅｎｔ＿ｄａｔａ＿ｒｕｌｅ」は、ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅイベントとｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅイベントとの間の、それらのイベントデータに基づく関連性を指す。ｅｖｅｎｔ＿ｄａｔａ＿ｒｕｌｅの例は、限定されるものではないが、ネットワークイベントデータ（例えば、ｄｓｔＩＰｐｏｒｔ（ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｄａｔａ）＝ｓｒｃＩＰｐｏｒｔ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿＿ｄａｔａ））、プロセス間通信イベントデータ（例えば、ＰＩＰＥ＿ＩＤ（ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｄａｔａ）＝ＰＩＰＥ＿ＩＤ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｄａｔａ））、並びにアプリケーションイベントデータ（例えば、Ｆｕｎｃｔｉｏｎ＿ＩＤ（ｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｄａｔａ）＝Ｆｕｎｃｔｉｏｎ＿ＩＤ（ｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｄａｔａ））を含む。このフィールドにおけるワイルドカードはいずれのイベントデータとも一致する。
【００５６】
ｏｗｎｅｒ＿ｒｕｌｅが原因（causing）及び結果（caused）リクエストユニットの両方が同じスレッドまたはスレッドプール（スレッドのプールをトラバースする仮想完全リクエストユニットの場合）からのものである必要があり、それらの因果関係がｔｉｍｅ＿ｒｕｌｅによって決定される場合、規則は時間因果規則と呼ばれる。複数の異なるプロセスのリクエストユニットと一致する規則は、イベント因果規則と呼ばれる。
【００５７】
各リクエストユニットマークＭに関して、Ｍ内のｂｅｇｉｎ＿ｅｖｅｎｔ＿ｔｙｐｅがＣＲｂｅｇｉｎを用いて他のリクエストユニットにおける関連するイベントを見つけ、Ｍ内のｅｎｄ＿ｅｖｅｎｔ＿ｔｙｐｅがＣＲｅｎｄを用いて他のリクエストユニットにおける関連するイベントを見つけるように、規則対ＣＲＰ：（ＣＲｂｅｇｉｎ，ＣＲｅｎｄ）が定義される。いずれか一方の規則は空であり得る。ブロック６０２は、関連するリクエストユニットのセットを検出し、フル経路リクエストを構成するために用いられるイベント関連性規則対のセットを出力する。イベント関連性規則は、デフォルトのセットとして予め定義することができる、またはユーザリクエストに応じて動的に構成することができる。
【００５８】
ブロック６０４はリクエストユニットを配列する。１つのリクエストＲが２項目データ構造＜Ｅ，Ｃ＞を用いて定義される。ここで、Ｅはリクエストユニットのセットであり、ＣはＥ内のリクエストユニット間の因果を記述する関係のセットである。配列は２つの主な手順を含む。すなわち、各リクエストユニットに関して、そのリクエストユニットの原因となるリクエストユニットが見つけられ、その検索の後、原因リクエストユニットを持たない各リクエストユニットのフル経路トランザクションが構築される。トランザクションは、そのリクエストユニットをルート（root）とし、１つのホップまたは複数のホップにおいてそのルートに起因する全てのリクエストユニットにわたって拡張される。リクエストユニット配列は以下で詳細に説明する。ブロック６０６は配列されたリクエストを出力する。
【００５９】
次に、図７を参照すると、図７にはブロック６０４のリクエストユニット配列に関するさらなる詳細が示されている。空のリクエストセットＲＳｇｌｏｂａｌが初期化されると、ブロック７０２は、ブロック３０６によって出力されるリクエストユニットセットＵから新たなリクエストユニットｕｉを選択する。各リクエストユニットｕｉについて、２つの空のリクエストユニットセットＲＵｉｐａｒｅｎｔ及びＲＵｉｃｈｉｌｄが初期化される。
【００６０】
ブロック７０４は、他のプロセスに属するｕｉの親（parent）リクエストユニットを見つける。ｕｉのイベントレコードシーケンスの開始イベントレコードｅｉｆに関して、ブロック７０４は、ブロック６０２によって出力されるイベント関連性規則対セットにおける規則対ｐｘ毎に、ｅｉｆのイベントタイプがｐｘにおける規則ＣＲｂｅｇｉｎのｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅであるか否かをチェックする。ＣＲｂｅｇｉｎが時間因果規則である場合、ブロック７０４は、ＣＲｂｅｇｉｎをテストすることで、ｕｉと所有者が同じであり、ｅｉｆと関連付けることができる開始イベントレコードｅｊｆを有する任意のリクエストユニットｕｊがＵ内に存在するか否かをチェックする。ｕｉ及びｕｊの所有者が同じであるということは、それら２つのリクエストユニットが同じプロセスからのものであることを示している。ｅｉｆ及びｅｊｆの時間がＣＲｂｅｇｉｎ内のｔｉｍｅ＿ｒｕｌｅに関して「真（Ｔｒｕｅ）」を得ることができる場合、ブロック７０４は一致をもたらす。
【００６１】
ｅｉｆのイベントタイプがｐｘ内の規則ＣＲｂｅｇｉｎのｃａｕｓｅｄ＿ｅｖｅｎｔ＿ｔｙｐｅであり、ＣＲｂｅｇｉｎが時間因果規則でない場合、ブロック７０４は、両方のイベントレコードについて規則ＣＲｂｅｇｉｎをテストすることで、ｅｉｆと関連付けることができる最初のイベントレコードｅｊｆを有する任意のリクエストユニットｕｊが存在するか否かをチェックする。ｅｉｆのイベントタイプがＣＲｂｅｇｉｎのｃａｕｓｉｎｇ＿ｅｖｅｎｔ＿ｔｙｐｅであり、ｅｉｆ及びｅｊｆの時間、所有者ＩＤ及びイベントデータが、規則ｔｉｍｅ＿ｒｕｌｅ、ｏｗｎｅｒ＿ｒｕｌｅ及びｅｖｅｎｔ＿ｄａｔａ＿ｒｕｌｅについて「真」である場合、ブロック７０４もまた一致をもたらす。
【００６２】
ブロック７０４が一致をもたらし、それによってＣＲｂｅｇｉｎが満たされる場合、ブロック７０４は、両方の最後のイベントレコードについて規則ＣＲｅｎｄをテストすることで、ｕｉにおける最後のイベントレコードｅｉｌを、ｕｉにおける最後のイベントレコードｅｊｌと関連付けることができるか否かをチェックする。これら２つの最後のイベントレコードがＣＲｅｎｄに基づいて関連付けることができる場合、ｕｊはｕｉに関する原因イベントユニットであり、ＲＵｉｐａｒｅｎｔに追加され、さらにｕｉはＲＵｊｃｈｉｌｄに追加される。このプロセスは全てのリクエストユニットについて繰り返され、ブロック７０８はさらなるリクエストユニットが存在するか否かを判定する。存在する場合、ブロック７０２は新たなリクエストユニットを選択する。存在しない場合、ブロック７１０は親なしリクエストユニットを選択する。
【００６３】
各親なしリクエストユニットｕｉについて、ブロック７１２は、全ての子（child）リクエストユニットを検索する。新たなリクエストＲｘが＜Ｅｘ，Ｃｘ＞として作成され、ｕｉがＥｘに挿入され、関連性「ＮＵＬＬ−＞ｐａｒｅｎｔ（ｕｉ）」がＣｘに挿入される。ＲＵｉｃｈｉｌｄ内の各リクエストユニットｕｊについて、ｕｉとｕｊの両方のイベントシーケンスにイベントが１つしかない場合、ブロック７１４は、ｕｊと同じ所有者に属し、ｕｉの単一のイベントのｔｉｍｅ＿ｂｅｇｉｎ値よりもｔｉｍｅ＿ｂｅｇｉｎ値が大きく、ｕｊの単一のイベントの値よりもｔｉｍｅ＿ｂｅｇｉｎ値が小さい全てのイベントをｕｊに挿入する。ブロック７１４は、ＵｊをＥｘに挿入し、関連性「ｕｉ−＞ｐａｒｅｎｔ（ｕｊ）」をＣｘに挿入する。ＲＵｊｃｈｉｌｄ内の各リクエストユニットｕｋがＲＵｉｃｈｉｌｄに挿入され、関連性「ｕｊ＞ｐａｒｅｎｔ（ｕｋ）」がＣｘに追加される。リクエストユニットｕｊはＲＵｉｃｈｉｌｄから除去され、新たなリクエストがＲＳｇｌｏｂａｌに追加される。ブロック７１６は、さらなるリクエストユニットが存在するか否かを判定し、存在する場合は別の親なしリクエストユニットが選択されて、処理がブロック７１０に戻る。存在しない場合、処理を終了してＲＳｇｌｏｂａｌにおけるリクエストが出力される。
【００６４】
本明細書に記載した実施形態は、全体的にハードウェアであってもよく、全体的にソフトウェアであってもよく、ハードウェアとソフトウェアの両方の要素を含んでいてもよい。好ましい実施形態において、本発明は、ファームウェア、常駐ソフトウェア、マイクロコード等を含むが、これらに限定されないソフトウェアでも実現可能である。
【００６５】
実施形態には、コンピュータもしくは任意の命令実行システムによって使用される、または関連して使用されるプログラムコードを提供する、コンピュータで利用可能な、またはコンピュータで読み取り可能な媒体からアクセスできる、コンピュータプログラム製品を含んでもよい。コンピュータで利用可能な、またはコンピュータで読み取り可能な媒体には、命令実行システム、機器、もしくは装置によって使用される、または関連して使用されるプログラムを格納、伝達、伝搬または転送する任意の機器を含んでもよい。該媒体は、磁気媒体、光学媒体、電子媒体、電磁気媒体、赤外線媒体、または半導体システム（または機器もしくは装置）、あるいは伝搬媒体であってよい。該媒体には、半導体または固体メモリ、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク及び光ディスク等のコンピュータで読み取り可能な媒体を含んでもよい。
【００６６】
各コンピュータプログラムは、汎用または特殊用途のプログラム可能なコンピュータで読み取ることができる、機械で読み取り可能なストレージメディアまたは装置（例えば、プログラムメモリまたは磁気ディスク）に格納される。該コンピュータプログラムは、ストレージメディアまたは装置から本明細書に記載された手順を実行するコンピュータで読み出される、該コンピュータの設定及び制御動作のためのものである。本発明のシステムには、本明細書に記載された機能を実行する、特定の及び事前に定義された方法でコンピュータに動作させるように構成されたコンピュータプログラムを含む、コンピュータで読み取り可能に具現化されたストレージメディアも考慮される。
【００６７】
プログラムコードを保存及び／または実行するのに適したデータ処理システムは、システムバスを介してメモリ要素に直接または間接的に接続された少なくとも１つのプロセッサを備えていてもよい。このメモリ要素には、処理の実行中にコードがバルク記憶装置から検索される回数を減らすために、プログラムコードの実際の実行中に用いられるローカルメモリ、バルク記憶装置及び少なくともいくつかのプログラムコードを一時的に記憶するキャッシュメモリを備えていてもよい。入出力またはＩ／Ｏ装置（限定されるものではないが、キーボード、ディスプレイ、ポインティングデバイス等を含む）は、直接またはＩ／Ｏコントローラを介してシステムに接続されていてもよい。
【００６８】
ネットワークアダプタは、データ処理システムが、プライベートネットワークまたは公衆ネットワークを介して、他のデータ処理システムまたは遠隔プリンタもしくは記憶装置と接続できるように、上記システムと接続されていてもよい。モデム、ケーブルモデム及びイーサネット（登録商標）カードは、現在利用可能なネットワークアダプタのほんの一握りのタイプである。
【００６９】
次に、図８を参照すると、図８にはプロファイリングシステム８００が示されている。プロファイリングシステム８００は、ハードウェアプロセッサ８０２とメモリ８０４とを含む。さらに、プロファイリングシステム８００は、１つまたは複数の機能モジュールをも含んでいる。いくつかの実施形態において、機能モジュールは、メモリ８０４に記憶されており、ハードウェアプロセッサ８０２によって実行されるソフトウェアとして実装されてもよい。代替的な実施形態において、機能モジュールは、例えば特定用途向けの集積チップまたはフィールドプログラマブルゲートアレイの形式で、１つまたは複数の個別ハードウェア構成要素として実装されていてもよい。
【００７０】
カーネルリクエストモジュール８０５は、オペレーティングシステムコールを含むカーネルイベントトレースを収集する。リクエストユニット生成モジュール８０６は、収集されたカーネルイベントから２つのタイプのリクエストユニット、すなわち半オープンリクエストユニット及び完全リクエストユニットを生成する。リクエストユニット配列モジュール８０８は、その後、リクエストユニット間の因果関係セットに基づいてリクエストユニットを構成することでフル経路リクエストトレースを構築する。それにより、プロファイリングシステム８００は、小さいオーバヘッドで複数のスレッドにわたるフル経路トレースを取得する。
【００７１】
次に、図９を参照すると、図９には送信デバイス１００または受信デバイス１２０を表す典型的な処理システム９００が示されている。処理システム９００は、システムバス９０２を介して他の構成要素と動作可能に接続された、少なくとも１つのプロセッサ（ＣＰＵ）９０４を含む。システムバス９０２には、キャッシュ９０６、リードオンリーメモリ（ＲＯＭ）９０８、ランダムアクセスメモリ（ＲＡＭ）９１０、入力／出力（Ｉ／Ｏ）アダプタ９２０、サウンドアダプタ９３０、ネットワークアダプタ９４０、ユーザインタフェースアダプタ９５０及び表示アダプタ９６０が動作可能に接続されている。
【００７２】
第１の記憶装置９２２及び第２の記憶装置９２４は、Ｉ／Ｏアダプタ９２０によってシステムバス９０２に動作可能に接続されている。記憶装置９２２及び９２４は、ディスク記憶装置（例えば、磁気記憶デバイスまたは光学ディスク記憶デバイス）、固体磁気デバイス等のいずれであってもよい。記憶装置９２２及び９２４は、同じタイプの記憶装置であってもよく、異なるタイプの記憶装置であってもよい。
【００７３】
スピーカ９３２は、サウンドアダプタ９３０によってシステムバス９０２に動作可能に接続されている。送受信器９４２は、ネットワークアダプタ９４０によってシステムバス９０２に動作可能に接続されている。表示デバイス９６２は、表示アダプタ９６０によってシステムバス９０２に動作可能に接続されている。
【００７４】
第１のユーザ入力デバイス９５２、第２のユーザ入力デバイス９５４及び第３のユーザ入力デバイス９５６は、ユーザインタフェースアダプタ９５０によってシステムバス９０２と動作可能に接続されている。ユーザ入力デバイス９５２、９５４及び９５６は、キーボード、マウス、キーパッド、イメージキャプチャデバイス、モーション感知デバイス、マイクロフォンあるいはこれらのデバイスのうちの少なくとも２つのデバイスの機能が組み込まれたデバイス等のいずれであってもよい。もちろん、本原理の趣旨を維持する限りにおいて、他のタイプの入力デバイスを使用してもよい。ユーザ入力デバイス９５２、９５４及び９５６は、同じタイプのユーザ入力デバイスであってもよく、異なるタイプのユーザ入力デバイスであってもよい。ユーザ入力デバイス９５２、９５４及び９５６は、システム９００に情報を入力し、システム９００から情報を出力するために使用される。
【００７５】
もちろん、処理システム９００は、当業者であれば容易に思いつくような他の要素（不図示）を含んでいてもよく、特定の要素を除いてもよい。例えば、当業者であれば容易に理解できるが、処理システム９００には、その詳細な実装に応じて他の様々な入力デバイス及び／または出力デバイスを含むことができる。例えば、無線及び／または有線による種々の入力デバイス及び／または出力デバイスを使用できる。さらに、当業者であれば容易に理解できるが、様々な構成において追加のプロセッサ、コントローラ、メモリ等を用いることも可能である。処理システム９００の上記及び他の変形例は、本明細書で提供される本原理の教示によって当業者であれば容易に考えられるであろう。
【００７６】
上記は、あらゆる観点において例示的（illustrative）かつ典型的（exemplary）であって限定的でないものと理解されるべきであり、本明細書で開示する本発明の範囲は、詳細な説明から決定されるべきではなく、特許法で認められた最大限の広さに基づいて解釈される特許請求の範囲から決定されるべきである。本明細書中に図示及び記載されている実施形態は、本発明の原理を説明するものにすぎず、当業者であれば、本発明の範囲及び主旨から逸脱することなく、様々な変更を実施することができることを理解されたい。当業者は、本発明の範囲及び精神から逸脱することなく、様々な他の特徴の組み合わせを実施できる。以上、本発明の態様について、特許法でリクエストされる詳細及び特殊性と共に説明したが、特許証で保護されることを求める特許請求の範囲は、添付の特許請求の範囲に示されている。
【図１】
2018538613.tif 000003
【図２】
2018538613.tif 000004
【図３】
2018538613.tif 000005
【図４】
2018538613.tif 000006
【図５】
2018538613.tif 000007
【図６】
2018538613.tif 000008
【図７】
2018538613.tif 000009
【図８】
2018538613.tif 000010
【図９】
2018538613.tif 000011
【国際調査報告】
2018538613.tif 000012
2018538613.tif 000013