JP6577455B2 - スレッド強度分析を用いた季節的傾向把握および予測によるクラウドサービスにおけるｓｌａ違反の予測的診断 - Google Patents

Description

優先権主張
本願はまた、２０１３年４月１１日に提出され、「スレッド強度分析を用いた季節的傾向把握および予測によるクラウドサービスにおけるＳＬＡ違反についての予測的診断（PREDICTIVE DIAGNOSIS OF SLA VIOLATIONS IN CLOUD SERVICES BY SEASONAL TRENDING AND FORECASTING WITH THREAD INTENSITY ANALYTICS）」と題され、その内容が引用によりこの明細書中に援用されている米国仮特許出願連続番号第６１／８１１，１０６号と、２０１３年１２月１７日に提出され、「スレッド強度分析を用いた季節的傾向把握および予測によるクラウドサービスにおけるＳＬＡ違反についての予測的診断（PREDICTIVE DIAGNOSIS OF SLA VIOLATIONS IN CLOUD SERVICES BY SEASONAL TRENDING AND FORECASTING WITH THREAD INTENSITY ANALYTICS）」と題され、その内容が引用によりこの明細書中に援用されている米国特許出願連続番号第１４／１０９，５７８号とについての優先権を米国特許法第１１９条（ｅ）に従って主張する。本願は、２０１３年４月１１日に提出され、「Ｊａｖａ（登録商標）ヒープ使用量の季節的傾向把握、予想、異常検出、およびエンドポイント予測（SEASONAL TRENDING, FORECASTING, ANOMALY DETECTION, AND ENDPOINT PREDICTION OF JAVA HEAP USAGE）」と題され、その内容が引用によりこの明細書中に援用されている米国仮特許出願連続番号第６１／８１１，１０２号と、２０１３年１２月１７日に提出され、「Ｊａｖａヒープ使用量の季節的傾向把握、予想、異常検出、およびエンドポイント予測（SEASONAL TRENDING，FORECASTING，ANOMALY DETECTION，AND ENDPOINT PREDICTION OF JAVA HEAP USAGE）」と題され、その内容が引用によりこの明細書中に援用されている米国特許出願連続番号第１４／１０９，５４６号とについての優先権を米国特許法第１１９条（ｅ）に従って主張する。本願は、２０１３年１０月１日に提出され、「データ駆動型ビジネスプロセスおよびケースマネジメント（DATA DRIVEN BUSINESS PROCESS AND CASE MANAGEMENT）」と題され、その内容が引用によりこの明細書中に援用されている米国仮特許出願連続番号第６１／８８５，４２４号と、２０１３年１２月１７日に提出され、「ビジネスプロセスおよびケースマネジメントのための知識集約型データマネジメントシステム（KNOWLEDGE INTENSIVE DATA MANAGEMENT SYSTEM FOR BUSINESS PROCESS AND CASE MANAGEMENT」と題され、その内容が引用によりこの明細書中に援用されている米国特許出願連続番号第１４／１０９，６５１号とについての優先権を米国特許法第１１９条（ｅ）に従って主張する。

背景
個々人および組織はデータ量の急速な増大に直面している。このようなデータは、複雑さおよび緊急性が急速に高くなる可能性がある。個々人および組織は、データに適切かつ適時に反応するために、しばしば、これらのデータを分析する必要がある。いくつかの分野においては、個々人および組織が行う行為は、規則によって管理されているが、これら規則もますます複雑になる傾向がある。たとえば、規則は、何らかの問題が起こるはずであるイベントに対する監査の影響を受け易い綿密な履歴記録をメンテナンスすることを必要とするかもしれない。代替的には、ビジネス組織間で締結されるサービスレベル合意（ＳＬＡ：service level agreement）は、ＳＬＡ違反を回避するために、かつ合意が満たされたかどうかを判断するために、データを系統的に分析すること、および、データ中の訴因となる情報に先を見越して対処することを必要とするかもしれない。規則、サービスレベル合意および他の要件に従うことは非常に面倒であるかもしれず、時間の経過とともにますます面倒になる可能性がある。

規制要件およびＳＬＡ要件が極めて複雑になってしまっているので、コンピュータソフトウェアは、それ自体が、要件に従おうと努力している個々人および組織を支援するのに適している。しかしながら、規則およびＳＬＡは徐々に進化する傾向があるので、コンピュータソフトウェア自体もこれらに合わせて徐々に進化する必要がある。残念ながら、コンピュータソフトウェアを開発および更新するために用いられる従来のプロセスは遅々として進まず、しかも扱いにくい。ソフトウェア開発サイクルは通常長期にわたる。コンピュータソフトウェアの開発をはばむこれらの問題点は、部分的には、データがしばしば手順ソフトウェアコード内に隠されていることに起因する可能性がある。データは、しばしば、当該データに適用することができる情報から分離される。

本発明の実施形態に従った、スレッドまたはスタックセグメントの強度分析を適用するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドまたはスタックセグメントの強度分析を適用するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スタックフレーム統計を更新するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スタックフレーム統計を更新するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドおよびこれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。 本発明の実施形態に従った、季節的傾向把握フィルタを適用するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スタックフレームの前または後の分岐点におけるスタックセグメントを分割するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スタックフレームの前または後の分岐点におけるスタックセグメントを分割するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スタックフレームの前または後の分岐点におけるスタックセグメントを分割するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドのスタックセグメントを一体化する（coalescing）ための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドのスタックセグメントを一体化するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドのスタックセグメントを一体化するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドのスタックセグメントを一体化するための技術の一例を示すフロー図である。 本発明の実施形態に従った、スレッドのスタックセグメントを一体化するための技術の一例を示すフロー図である。 本発明の実施形態に従った、指定されたスタックトレースおよび一体化されたセグメントの指定されたセットについてのスレッド分類項目を登録するための技術の一例を示すフロー図である。 本発明の実施形態に従った、指定されたスタックトレースおよび一体化されたセグメントの指定されたセットについてのスレッド分類項目を登録するための技術の一例を示すフロー図である。 本発明の実施形態に従った、指定されたスレッド分類情報項目についてのスレッド分類統計を更新するための技術の一例を示すフロー図である。 本発明の実施形態に従った、指定されたセグメント情報項目についてのスタックセグメント統計を更新するための技術の一例を示すフロー図である。 本発明の実施形態に従って用いられ得るシステム環境のコンポーネントを示す簡略ブロック図である。 本発明の実施形態に従って用いられ得るコンピュータシステムの簡略ブロック図である。 本発明の実施形態に従った、さまざまな機能を用いてデータのさまざまな状態を変換するフレームワークを示すブロック図である。 本発明の実施形態に従った傾向を示す図である。 本発明の実施形態に従った、自動的に分類されたデータポイントのセットの例を示す図である。

詳細な説明
概要
データは、事実、情報、仮説および指令に分類することができる。知識を適用することによって他のカテゴリのデータに基づいてデータのいくつかのカテゴリを生成するアクティビティは、分類、査定、解決および規定（Enactments）に分類することができる。これらの分類は、たとえば履歴記録を維持することなどによって診断システムを強化するのに用いることができる。このような診断システムは、仮想マシンによってスレッドまたはスタックセグメントの強度およびメモリヒープ使用量などのシステムバイタルサインに知識を適用することに基づいて、コンピューティングシステムの故障を予測するシステムを含み得る。これらのバイタルサインは、実際には、メモリリーク、スタックした（stuck）スレッド、デッドロック、輻輳または他の問題などの情報を生成するように分類することができる。分類は、クラスの自動生成や、期間が不規則なサンプル間隔を用いた時系列データの傾向把握（trending）を含み得る。

データとアクティビティとの関係の維持
本発明の実施形態に従うと、アクティビティとそれらのアクティビティの動機づけとなったデータとの間の形式関係を維持するための技術が開示される。より具体的には、事実として形式的に認識されるデータは、形式的には、それらの事実に基づいた情報を導き出す分類アクティビティと関連付けることができるか、またはこの分類アクティビティにマップすることができる。このような情報はまた、一般的な意味のデータであるが、事実とは異なり、形式的に情報として認識することができる。査定アクティビティは、このような情報に基づいて仮説を導き出すものであるが、形式的にはその仮説に関連付けることができるかまたはその仮説にマップすることができる。解決アクティビティは、このような情報および仮説に基づいて指令を導き出すものであるが、形式的には、その指令と関連付けることができるかまたはその指令にマップすることができる。指令はまたデータであるが、事実および情報とは異なり、形式的に指令として認識することができる。規定（Enactment）アクティビティは、このような指令に基づいてさらに別の事実を導き出すものであるが、形式的には、さらに別の事実に関連付けることができるかまたはマップすることができる。

このように、本発明の実施形態においては、データの各項目は、事実として、情報として、仮説として、または指令として区別することができる。各々のアクティビティは、分類、査定、解決または規定として区別することができる。外部ソースからセンサなどのシステムに受信された生データは、概して、定性的ではなくむしろ定量的な事実として区別することができる。このような事実に適用される知識ベースの自動プロセスまたは人の判断は、分類として区別することができる。分類に起因するデータは、情報として区別することができる。情報は、概して、事実が定性的に意味すると判断または決定されたものを示す。このような情報に適用される知識ベースの自動化プロセスまたは人の判断は、査定として区別することができる。査定に起因するデータは仮説として区別することができる。同様に、このような仮説に適用される知識ベースの自動化プロセスまたは人の判断は、解決として区別することができる。解決に起因するデータは指令として区別することができる。指令は、概して、情報によって指定される状態を補修するかまたは改善しようとする作業に適しているとみなされる動作を規定する。このような指令に適用される知識ベースの自動化プロセスまたは人の動作は、規定として区別することができる。規定は、概して、指令によって規定される動作を実行する。規定に起因するデータは、規定によってもたらされた状態に対してなされた測定によって得られてもよく、事実として区別することもできる。さらなる分類はこれらの事実に関して行うことができるので、上述のシーケンスを反復して繰り返すことができる。繰り返しのたびに、付加的な事実、情報および指令を確認することができる。繰り返しのたびに、付加的な分類、査定、解決および規定を実行することができる。このように、本発明の実施形態は、情報を生成する事実、仮説を生成する情報の査定、指令を生成する情報の解決、およびさらなる事実を生成する指令の規定を周期的に分類することを含み得る。この周期は、ＣＡＲＥ（Classification-Assessment-Resolution-Enactment：分類・査定・解決・規定）ループと称される。

本発明の一実施形態においては、システムにおいて行なわれる分類のたびに、その分類とその分類の動機づけとなった事実との間のマッピングを生成および格納することができる。システムにおいてなされる査定のたびに、その査定とその査定の動機づけとなった情報との間のマッピングを生成および格納することができる。システムにおいてなされる解決のたびに、その解決とその解決の動機づけとなった情報との間のマッピングを生成および格納することができる。システムにおいて実行される規定のたびに、その規定とその規定の動機づけとなった指令との間のマッピングを生成および格納することができる。加えて、各々の分類とその分類に起因する情報との間のマッピングを生成および格納することができる。加えて、各々の査定とその査定に起因する仮説との間のマッピングを生成および格納することができる。加えて、各々の解決とその解決に起因する指令との間のマッピングを生成および格納することができる。加えて、各々の規定とその規定に起因する事実との間のマッピングを生成および格納することができる。

本発明の一実施形態においては、事実、分類、情報、査定、仮説、解決、指令および規定のインスタンスを分類するために、オブジェクト指向クラスのセットが確立される。これらのクラスの各々のドメイン特有サブクラスはこれらのクラスから導き出すことができる。たとえば、特定のドメイン（たとえば、データセンタ健全性の監視、診断および管理）のために、事実クラスのドメイン特有サブクラスは事実クラスから導き出すことができ、分類クラスのドメイン特有サブクラスは分類クラスから導き出すことができ、査定クラスのドメイン特有サブクラスは査定クラスから導き出すことができ、仮説クラスのドメイン特有サブクラスは仮説クラスから導き出すことができ、解決クラスのドメイン特有サブクラスは解決クラスから導き出すことができ、指令クラスのドメイン特有サブクラスは指令クラスから導き出すことができ、規定クラスのドメイン特有サブクラスは規定クラスから導き出すことができる。これらのドメイン特有サブクラスの各々には、これらを適用することのできるドメインに適したラベルおよび属性を与えることができる。たとえば、データセンタ健全性管理、診断および管理ドメインにおいては、事実クラスのドメイン特有サブクラスはスレッドダンプクラスであってもよい。別の例の場合、情報クラスのドメイン特有サブクラスはスタックした（stuck）スレッドクラスであってもよい。別の例の場合、指令クラスのドメイン特有サブクラスはロードバランシングクラスであってもよい。

本発明の一実施形態においては、事実であるデータ項目ごとに、事実クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのデータ項目に関係する属性の値を格納することができる。情報であるデータ項目ごとに、情報クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのデータ項目に関係する属性の値を格納することができる。指令であるデータ項目ごとに、指令クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのデータ項目に関係する属性の値を格納することができる。

本発明の一実施形態においては、分類であるアクティビティごとに、分類クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのアクティビティに関係する属性の値を格納することができる。査定であるアクティビティごとに、査定クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのアクティビティに関係する属性の値を格納することができる。解決であるアクティビティごとに、解決クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのアクティビティに関係する属性の値を格納することができる。規定であるアクティビティごとに、規定クラスのドメイン特有サブクラスのインスタンスであるオブジェクトがインスタンス化されて、そのアクティビティに関係する属性の値を格納することができる。

本発明の一実施形態においては、これらのオブジェクト間のマッピングを生成および格納することができる。このようなマッピングは、場合よっては、このようなマッピングを格納することができるデータベースに対してクエリを実行することによって、後でリコールすることができる。

分類・査定・解決・規定ループ
本発明の一実施形態においては、４つの別個のクラスのデータ、すなわち事実、情報、仮説および指令、が規定される。一実施形態においては、４つの別個のクラスの知識、すなわち分類、査定、解決および規定が規定される。情報インスタンスは、分類プロセスによって事実から抽出された観察および／または予測および／またはノルマおよび／または目標を含み得る。仮説インスタンスは、査定プロセスによってなされた観察および／または予測から導き出すことができる。指令インスタンスは、解決プロセスによってなされた仮説から導き出すことができる。規定プロセスは新しい事実を生成することができる。

一実施形態においては、事実（システムへの生入力）は、分類知識を適用することによって観察および／または予測および／またはノルマに分解することができる。事実は、観察についての確立された用語を表わす別個のタグ特性にマッピングすることができる。観察は、仮説を導き出すために査定を実行するのに用いることができる。このような仮説は確率、規模および反応緊急性を有し得る。観察、予測、ノルマおよび／または仮説を用いて、状況に対処するための指令（アクションプラン）を決定することができる。指令は、規定知識を適用することによって実行することができる。指令が規定されると、新しく現われた事実が分類され得る。さらなる査定を実行することにより、状況が解決されたかどうか、または、さらなる指令が確認されるべきであるかどうかを判断することができる。

この明細書中に開示される技術を用いてアプリケーションを開発することができる。この明細書中に開示される知識、情報、プロセスおよび社会的相互関係モデルを用いて、データ駆動型アプリケーションを開発することができる。セマンティクスは、データを事実、情報、仮説および指令に分類することによってデータに関連付けることができる。このように区別されたこれらのデータは、ＣＡＲＥループを用いて、分類、査定、解決および規定の知識と相互に関連付けることができる。データベース技術を用いて、この明細書中に開示される技術を実現し、かつ、この明細書中に開示されるモデルを実現することができる。

知識、情報、プロセスおよび社会的相互関係モデル
この明細書中に開示されるモデルを一般的な設計パターンとして用いて、進化的アプリケーションを発展させることができる。このようなアプリケーションは符号化された知識プロセスを徐々に投入することによって発展させることができる。このような符号化された知識プロセスを用いることにより、手動プロセスを自動化することができる。指令クラスは、指令を実行するために必要な暗黙知のプロファイルに関連付けることができる。アクタークラスは暗黙知プロファイルに関連付けることができる。アクターの指令および暗黙知プロファイルについての暗黙知要件を適合させることによって、最適な人的資源を選択し、各々のタスクに割当てることができる。ＣＡＲＥループは、動的な反応システムを構築するためにエンジンとして用いることができる。

知識、データおよびアクター
本発明の一実施形態においては、３つのオブジェクト指向クラス、すなわちデータクラス、知識クラスおよびアクタークラス、を規定することができる。オブジェクトはこれらのクラスからインスタンス化することができる。これらのオブジェクトはアプリケーション用のデータベースに格納することができる。複数のバージョンの各オブジェクトを仮データベースにおいて維持することができるため、必要に応じて各オブジェクトの履歴を得ることができる。

データオブジェクト（データクラスのインスタンス）は、事実、イベントストリーム、関係、拡張マークアップ言語（ＸＭＬ：Extensible Markup Language）ドキュメント、テキストなどの構造化された生のコンテンツ、半構造化された生のコンテンツ、および構造化されていない生のコンテンツを表わし得る。データオブジェクトはまた、カテゴリ、タグ、関係およびコンテナなどのメタデータを表わし得る。データオブジェクトはまた、ユーザインターフェイス形式、規定形式および通知テンプレートなどの獲得プロセスによって取り込まれたコンテンツを表わし得る。

知識オブジェクト（知識クラスのインスタンス）は、アルゴリズム、スクリプト、プロセス、クエリ、リソース記述フレームワーク（ＲＤＦ：Resource Description Framework）原理、プロダクションルール、デシジョンツリー、サポートベクトルマシン、ニューラルネットワーク、ベイズ（Bayesian）ネットワーク、隠れマルコフモデル、ホップフィールドモデル、人の暗黙知などを表わし得る。データオブジェクトが追加、変更または削除されると、知識をこれらのデータオブジェクトに適用することができる。知識オブジェクトが更新されると、結果として、その知識オブジェクトにおける知識が既に適用されているデータオブジェクトが遡求的に処理される可能性がある。知識オブジェクト内の知識は、それらの知識オブジェクトが配置されると直ちに、適用することができる。

アクターオブジェクト（アクタークラスのインスタンス）は、個々人、個々人のグループ、または組織を表わし得る。アクターオブジェクトは、組織的コンテキスト、スキルプロファイル、知識プロファイル、利害関係プロファイルおよび優先度プロファイルなどの属性を有し得る。このような知識プロファイルは、アクターオブジェクトが有する暗黙知であって、システムが符号化された状態では所有し得ない暗黙知を示し得る。アクターオブジェクトが個々人を表わす場合、アクターオブジェクトは、オブジェクトによって表わされるアクターについてのリアルタイムの存在を指定することができる。アクターオブジェクトが個々人を表わす場合、アクターオブジェクトはオブジェクトによって表わされるアクターについてのリアルタイムのアクティビティを指定することができる。アクターオブジェクトは、それらのアクターオブジェクトの属性に基づいて、最適に、ペンディング中の指令に割当てることができる。

本発明の一実施形態においては、データクラス、知識クラスおよびアクタークラスはすべて同じベースクラスから導き出すことができる。

事実、情報、仮説および指令
本発明の一実施形態においては、３つの別個のオブジェクト指向クラスを上述のデータクラス、すなわち事実クラス、情報クラス、仮説クラスおよび指令クラス、から導き出すことができる。オブジェクトはこれらのクラスからインスタンス化することができる。オブジェクトは、利用できるようにデータベースに格納することができる。

事実オブジェクト（事実クラスのインスタンス）は、システムへの入力を表わし得る。このような入力は、たとえば、ＪＶＭにおけるガーベッジコレクタからのデータストリーム、周期的なスレッドダンプからのスタックトレース、メモリヒープダンプ、データベースＡＷＲレポートなどを含み得る。事実オブジェクトは、デバイスから集められた非構造化された会話、形式入力または定量的測定を表わし得る。

情報オブジェクト（情報クラスのインスタンス）は、事実から得られる観察または予測の定性的解釈を表わし得る。本発明の一実施形態においては、３つの別個のオブジェクト指向のクラス、すなわち観察クラス、予測クラス、ノルマクラスおよび目標クラス（Objective class）、を情報クラスから導き出すことができる。各々のクラスのオブジェクトはインスタンス化することができる。観察オブジェクトは、離散値への事実の個別化を表わし得る。たとえば、データベース接続の事実についてブロックするスレッドの強度（数）が、正常、保護済み、厳密または重大などの定性値を有する観察オブジェクトに個別化されてもよい。予測オブジェクトは、変化する条件から予測される定性値を表わし得る。予測オブジェクトは、場合によってはシミュレーションによって、観察のモデルによって補間または外挿される定性値を表わし得る。ノルマオブジェクトは、履歴ベースラインの定性値を表わし得る。目標オブジェクトは目標定性値を表わし得るが、この目標定性値は、全体的な目標および解決を達成するために、観察オブジェクトおよび予測オブジェクトを得るよう要求されるべきものである。目標とおよび観察との差を分類することができる。目標と観察との差の程度は、指令の決定に影響を及ぼす可能性がある。

仮説オブジェクト（仮説クラスのインスタンス）は、観察および／または予測の診断または原因を表わし得る。たとえば、ロードバランサの障害は、２つのサーバのクラスタにおいて、スレッドのクラスのスレッド強度を第１のサーバでは（強度がノルマよりも著しく高い）ハイパーテンション状態として分類され、第２のサーバでは（強度がノルマよりも著しい低い）ハイポテンション状態として分類されるものであるが、仮説のドメイン特有例である。

指令オブジェクト（指令クラスのインスタンス）は、実行されるべきアクティビティを表わし得る。ヒープダンプを採用するかまたはメモリ管理ポリシーを構成するための命令は、指令のドメイン特有例である。

分類、査定、解決および規定
本発明の一実施形態においては、４つの別個のオブジェクト指向クラス、すなわち分類クラス、査定クラス、解決クラスおよび規定クラス、を上述の知識クラスから導き出すことができる。オブジェクトはこれらのクラスからインスタンス化することができる。オブジェクトは、利用できるようにデータベースに格納することができる。これらのオブジェクトは、制度上の知識の抽象的概念を集約的に表わすことができる。このような知識は、たとえば自動化ソフトウェアプログラムにおいて符号化することができるか、または、このような知識は人の知識であってもよい。知識は、アルゴリズム、技術、プロセスまたは方法の形を採ることもできる。知識は、他の種類のデータを導き出すためにデータに適用することができる。

分類オブジェクト（分類クラスのインスタンス）は、定量的な事実を定性的な観察に変換するための技術を表わし得る。分類技術を適用することにより、事実のプールから得られる重要な事実をコンパクトに表現することができる。

査定オブジェクト（査定クラスのインスタンス）は、観察の原因についての仮説を生成するための技術を表わし得る。これらの技術は、手動であっても、コンピュータ誘導型であっても、または完全に自動化されてもよい。

解決オブジェクト（解決クラスのインスタンス）は、仮説を処理するために指令のセットを生成するための技術を表わし得る。これらの技術は、手動であっても、コンピュータ誘導型であっても、または完全に自動化されてもよい。解決は、観察または予測がノルマからどれくらい逸脱しているかに基づいて指令を展開させようとし得る。

規定オブジェクト（規定クラスのインスタンス）は、指令の意図を解釈し、その意図を実行するための技術を表わし得る。規定は、仮説に応答することを要求し得る。規定は、付加的な事実を獲得することを要求し得る。

アクター
アクターオブジェクト（アクタークラスのインスタンス）は、人々、グループ、コミュニティおよび自動化エージェントを表わし得る。アクターオブジェクトは、プロファイルおよび存在コンテキストなどの属性を所有し得る。人はシステムと対話する個々人であり得る。人のプロファイルはその人の規律、役割および責任を表わし得る。人の暗黙知プロファイルは、その人によって投稿されたかまたは書かれたメッセージ、レポートおよび刊行物から自動的に抽出することができる。グループは個々のチームであり得る。グループのプロファイルは、そのグループの規律、役割および責任を表わし得る。グループの暗黙知プロファイルは、グループのメンバーによって投稿されたかまたは書かれたメッセージ、レポート、および刊行物から自動的に抽出することができる。コミュニティは組織、フォーラム、会議、ジャーナルなどであり得る。コミュニティの暗黙知プロファイルは、コミュニティの対話に基づいて自動的に生成することができる。自動化エージェントは、数例を挙げると、ワークフロー、シミュレーション、サポートベクトルマシン、ニューラルネットワークおよびベイズネットワークなどのアルゴリズム的プロセスをカプセル化するソフトウェアであってもよい。自動化エージェントは、そのエージェントの能力を示すプロファイルを所有することができる。

一実施形態においては、分類オブジェクト、査定オブジェクト、解決オブジェクトおよび規定オブジェクトによって表わされるような知識アクティビティは、アクターオブジェクトに、そのアクターオブジェクトが有する属性に少なくとも部分的に基づいて、割当てることができる。こうして、実行されるべきアクティビティは各々、大抵の場合、そのアクティビティを最も効率的に実行することができるアクターに割当てることができる。

一実施形態においては、アクターオブジェクトの少なくともいくつかの属性は、直接的または間接的に取り込むことができる。これらの属性はプロファイルを含み得る。アクターオブジェクトは優先度を所有し得る。自然言語処理を用いると、専門知識発見ツールは、メッセージ、レポートおよび刊行物などのアクターの投稿からそのアクターの専門知識および関心事項を抽出することができる。このような専門知識および関心事項は名詞およびトピックによって示すことができる。ツールは、各々の名詞句またはトピックを専門知識、関心事項、好き嫌い、推薦などと分類することができる。一実施形態においては、イベントサブスクリプションは、それらのアクターのプロファイルに基づいてアクターのために自動的に作成することができる。

一実施形態においては、アクターのプロファイルは時間とともに変化し得る。時間の経過に応じたさまざまなバージョンのこれらのプロファイルは各アクターごとに維持することができる。アクターの投稿を再評価することにより、そのアクターの専門知識を時間の経過とともに変化させることができる。アクターのプロファイルの履歴はバイテンポラル・データベースに格納され、照会することができる。

一実施形態においては、アクターについてのプロファイルは、そのアクターが従事したソーシャルインタラクションのコンテンツに基づいて自動的に構成することができる。これらのソーシャルインタラクションは、たとえば、対話形スレッドを含み得る。ソーシャルインタラクションはコンテナオブジェクトとして表わすことができる。このようなソーシャルインタラクションコンテナオブジェクトは会議、チャットルーム、電子メール受信ボックス、電子メール送信ボックス、カレンダー、タスクリストおよびフォーラムを表わし得る。これらのコンテナオブジェクトにおけるアクターのコンテンツ投稿はコンテキストにおいてプロファイリングすることができる。分類、査定、解決および規定などの知識関数（knowledge function）は、組織の制約を観察しつつ、パラメータを、各アクターの専門知識、優先度および社会的ネットワークプロファイルに可能な限りパーソナライズすることができるように、パラメータ化することができる。いくつかの実施形態においては、アクターは、状況、自身の優先度および制限的な組織的要因に基づいて、最良のチームメンバーを選択することができる。

アプリケーション進化
本発明の一実施形態に従うと、アプリケーションは、ユーザインターフェイスアプリケーションから知識を分離することで、絶えず進化し得る。一実施形態においては、知識は個別に維持することができ、実行エンジンは知識を適切に適用することができる。人が所有する暗黙知などのいくつかの種類の知識は、演算システム内では事前に知られてはいない。一実施形態においては、これらの種類の知識を獲得できるようにするために、システムはユーザ環境を提示することができるが、このユーザ環境は、このような種類の知識を表わすようにその環境のユーザを促進したり動機づけたりするものである。システムはまた、ユーザ環境を提示することができるが、このユーザ環境は、このような種類の知識を表わすためのその環境のユーザに報酬を与えるものである。システムは、さらに、たとえば分類、査定、解決および規定する目的で監視型機械学習のための知識を取り込んで用いることができる。

本発明の一実施形態に従うと、ユーザインターフェイスが提供される。このユーザインターフェイスを介して人のユーザがデータを入力することができる。このデータは、それらのユーザが判断を下した理由を記述するために用いることができる。システムは、このような記述を、ユーザが実行するかまたは実行させられるアクションを示すデータに関連付けて格納することができる。その後、格納された記録は、いかなるアクションの場合でも、それらのアクションが実行された理由を確認するために照会することができる。付加的には、このような記録は、アクションを実行するようにとの決定がなされた時点における事実を反映させることができる。こうして、システムにおいてプロセスを文書化することができる。

いくつかの分類アクティビティは、自動化プロセスによってではなく、人によって実行することができる。本発明の一実施形態においては、人の分類アクティビティが実行されたことに応じて、システムは、アクティビティが実行されている状況を記述するように人に依頼することができる。次いで、システムは、この記述を、分類アクティビティを表わす分類オブジェクトに関連付けて格納することができる。一実施形態においては、システムは、場合によっては誘導型のソーシャルタギングによって語彙のレパートリーを用いて注釈を規定するように人に依頼することができる。次いで、システムは、これらの注釈を分類オブジェクトに関連付けて格納することができる。本発明の一実施形態においては、システムは、分類アクティビティがベースとなった最少セットの事実を識別するようにユーザに依頼することができる。次いで、システムは、この事実のセットを分類オブジェクトに関連付けて格納することができる。

いくつかの査定アクティビティは、自動化プロセスによってではなく、人によって実行することができる。本発明の一実施形態においては、人の査定アクティビティが実行されたことに応じて、システムは、仮説に到達するために分類に基づいて行なわれるであろう査定を公表するように人に依頼することができる。システムは、誘導型ソーシャルタギングによって語彙のレパートリーを用いて査定に注釈を付けるように人に依頼することができる。システムは、分類のセットのうちどの観察、予測、ノルマおよび目標が査定に関連しているのかを、場合によっては誘導型ソーシャルタギングによって示すように人に依頼することができる。システムは、語彙のレパートリーを提供することによって査定結果を仮説の形式で、場合によっては誘導型ソーシャルタギングを用いて公表するように人に依頼することができる。システムは、仮説の査定に基づいて行なわれるであろう解決を公表するように人に依頼することができる。システムは、語彙のレパートリーを用いて、誘導型ソーシャルタギングによって解決に注釈を付けるように、人に依頼することができる。システムは、アクションプランを１つ以上の指令の形式で特定するように人に依頼することができる。システムは、全体としてアクションプランと、アクションプラン内の各々の指令とに注釈を付けるように人に依頼することができる。システムは、入力を、査定オブジェクトおよび解決オブジェクトに関連付けて、注釈とともに格納することができる。

本発明の一実施形態においては、システムが人に注釈を提供するように依頼する場合、システムは、人のアクターオブジェクトに関連付けられたプロファイルに少なくとも部分的に基づいて、人に語彙のレパートリーを推薦することができる。本発明の一実施形態においては、システムは、人に関連付けられるアクターオブジェクトが属する同じコミュニティに属するアクターオブジェクトに関連付けられた知識項目の類似性に基づいて、人にタグを推薦することができる。本発明の一実施形態においては、システムは、アクターのコミュニティにおける他のアクターによるそれらのタグの使用頻度に基づいて、人にタグを推薦することができる。いくつかの実施形態においては、システムは、普及しているソーシャルネットワーキング経験と同様の誘導型ソーシャルタギング経験を用いることができる。誘導型ソーシャルタギングにより、規格化された語彙を増やし、事例がより識別可能となり、プロセスがより反復可能となり得る。これにより、プロセスを、特別にその場限りで実施されるものから、より適切に規定および最適化して実施されるもの（たとえば、注意義務の実施）へと進化させる。さらに、ユーザ注釈は、アプリケーションを自動的に進化させることを可能にするために、パターン認識アルゴリズムのためのパターンとして、かつ、監視型機械学習アルゴリズムのための正例および負例として、用いることができる。

特定ドメインに対するデータ駆動型フレームワークの適用
健全性を監視するためのアプリケーションや、大規模データセンタのさまざまな箇所における問題に対応するアプリケーションなどのいくつかのアプリケーションドメインにおいては、所望のアプリケーション挙動は、事前には完全に規定、設計およびプログラミングされない可能性がある。これらのシステムの場合、アプリケーション挙動は、データおよび知識を集中的に進化させること応じてタイムリーに実現される必要がある。アプリケーションが実現された後、アプリケーション挙動は、データおよび知識において表わされる情報の変更に連続的に適合させる必要がある。このようなドメインにおいては、アプリケーション開発プロセスはデータ駆動型でなければならず、この場合、アプリケーション挙動は、データから導き出される知識をカプセル化する機能エレメントで構成されている。データおよび知識を変更しながら当該アプリケーションを有効に進化させるために、知識エレメントは、その由来（provenance）のトラッキングをサポートするシステム内の他のタイプのデータとともにデータの形として管理される必要がある。その由来がサポートされていれば、事実が変化した場合に、システムは、事実から導き出される知識を再度特徴付けることができ、知識が変化した場合に、システムは、事実内の情報を再査定することができる。この明細書中に開示される本発明の一実施形態においては、知識エレメントは、分類タイプ、査定タイプ、解決タイプおよび規定タイプによって分類される。知識エレメントのすべてが、自動化された機能または自動化されたプロセスとして符号化されるとは限らない。アクターの暗黙知によるインタラクションも、分類知識、査定知識、解決知識および規定知識の適用例として由来データベースに取り込まれる。データ駆動型のプロセス制御により、由来データベースにおいてトリプル（事実、分類、情報）として、符号化された知識またはアクターの暗黙知のいずれかによって実行される各分類アクションが追跡される。符号化された知識またはアクターの暗黙知のいずれかによって実行される査定アクションは各々、トリプル（情報、査定、仮説）として取り込まれる。符号化された知識またはアクターの暗黙知のいずれかによって実行される解決アクションは各々、トリプル（仮説、解決、指令）として取り込まれる。同様に、符号化された知識またはアクターの暗黙知のいずれかによって実行される規定アクションは各々、トリプル（指令、規定、事実）として取り込まれる。本発明のいくつかの実施形態においては、トリプルのこれらのインスタンスは、データベースにおけるリソース記述フレームワーク（ＲＤＦ：Resource Description Framework）および具体化（Reification）トリプルとして表わされる。

本発明の一実施形態においては、システムは、エンジンを駆動する４タイプのアクティビティにちなんで命名された分類・査定・解決・規定（ＣＡＲＥ：Classification-Assessment-Resolution-Enactment）プロセス制御エンジンとしての役割を果たす。エンジンは、アクターと、自動化された分類プロセス、査定プロセス、解決プロセスおよび規定プロセスとの間のインタラクションを積極的に開始する。エンジンは、プロセスサイクルの各段階で事実データ、情報データ、仮説データおよび指令データを生成するために分類段階、査定段階、解決段階および規定段階を循環する。一実施形態においては、分類、査定、解決、規定などの機能はプロセス局面を提供し、事実、情報、仮説および指令はデータ局面を提供する。機能は本質的に変形可能である。ある実施形態においては、ＣＡＲＥ制御エンジンは、事実データ、情報データ、仮説データ、指令データ、および由来データを生成して維持するように完全に制御する権限が与えられている。これを行う場合、ＣＡＲＥ制御エンジンは、どのデータがいつ使用可能であるのかを予想することができる。エンジンはまた、いずれかの知識カテゴリの正確な知識機能を適用するために十分なデータが使用可能になる時間を予想することができる。エンジンはデッドラインを施行することができる。

ＣＡＲＥ制御エンジンは、アクターの暗黙知プロファイル、ならびに、符号化された分類機能、査定機能、解決機能および規定機能の能力プロファイルを生成および維持するように完全に制御する権限が与えられている。ＣＡＲＥ制御エンジンは、アクターの暗黙知および優先度をプロファイリングし、各々の指令に関して最も資質のあるアクターを選択し、選択されたアクターにタスクを割当てるための権限が与えられている。このような実施モデルは、決定サポート自動化システムの進化的開発に適用可能である。いくつかの実施形態においては、由来データベース内の関連付けられた入力事実および出力情報でアクターによって実行される分類アクションの具体化は、自動分類についてサポートベクトルマシンまたはニューラルネットワークの監視型学習についてのトレーニングサンプルとして用いることができる。システムにおいて実行される査定アクションの具体化は、ベイズネットワークにおける条件付き確率を導き出すための事例として、かつ、自動査定のためのベイズネットワークを拡張するために新しいアソシエーションおよび因果的依存性を特定するための事例として、用いることができる。

この明細書中において開示されるフレームワークにおいては、事実の分類は、アクターもしくは分類マシンによって実行することができるか、または互いに関連付けて実行することができるいくつかの動作のうちの１つである。事実から分類された情報は、生データの概要であって、傾向、予測、ノルマ、目標および状態のベクトルを含み得る。分類に加えて、フレームワークは査定を含んでもよい。査定は、分類と同様に、事実から導き出される情報に対する知識の適用の一種である。査定は、アクターもしくは査定マシンによって、または互いにに関連付けて実行することができる。フレームワークは、分類および査定に加えて、解決を含んでもよい。解決は、分類および査定と同様に、情報から導き出される仮説への知識の適用の一種である。解決は、アクターもしくは解決マシンによって、または互いに関連付けて実行することができる。フレームワークは、分類、査定および解決に加えて、規定を含んでもよい。規定は、分類、査定および解決と同様に、指令に応じた知識の適用の一種である。規定は、アクターもしくは規定マシンによって、または互いに関連付けて実行することができる。

図１２は、本発明の実施形態に従った、さまざまな機能を用いてデータのさまざまな状態を変換するフレームワークのブロック図である。フレームワーク１２００は、事実データ１２０２、情報データ１２０４、仮説データ１２０６および指令データ１２０８を含む。フレームワーク１２００はまた、事実データ１２０２を情報データ１２０４に変換する分類機能１２１０と、情報データ１２０４を仮説データ１２０６に変換する査定機能１２１２と、仮説データ１２０６を指令データ１２０８に変換する解決機能と、指令データ１２０８を事実データ１２０２に変換する規定機能とを含む。

健全性を監視してコンピュータシステムの健全性の問題に対応するための技術は、システムの「バイタルサイン」を規定することを必要とする。これらの技術は、時系列データ内のバイタルサインの監視を含み得る。時系列データはさまざまなセンサから生じ得る。時系列データ内に含まれる情報は特殊タイプの事実である。このようなバイタルサインは、たとえば、メモリ使用量、スレッドまたはスタックセグメントの強度を含み得る。季節的傾向把握技術では、コンピュータシステムの「バイタルサイン」についての時系列データを利用して傾向の分類を実行することができる。

季節的傾向把握、ならびにヒープ使用量の分類およびスレッドまたはスタックセグメントの強度は、この明細書中に開示されるフレームワークの実現可能な多くのさまざまな適用例のうちのいくつかに過ぎない。フレームワークを用いると、高レベルの情報を低レベルの事実から導き出すことができる。このような低レベルの事実は、たとえば、ＪＶＭの冗長なＧＣログおよびスタックトレースなどの生データであり得る。生データは、ますます高レベルになる分類情報を抽出するために変換することができる。たとえば、スタックトレースにおけるスレッドセグメントはより簡潔な情報に分類することができる。スタックセグメントおよびスレッドを分類した後、当該技術は、スレッドのクラス間の依存関係（dependency relations）を抽出することができ、分類情報のより高度な形式であるスレッドとスタックセグメントとの合成をドリルダウンすることができる。周期的なスレッドダンプについての時系列データは、スレッドおよびスタックセグメントの各クラスについての傾向把握情報を含む。季節的傾向把握は、時系列データをより高度な形式の情報、たとえば、周期的な季節サイクル、線形傾向、分散変動（variance change）、レベル変化、レベルドリフト、アウトライアおよびエンドポイント予測などに変換する。傾向データは、大量の時系列データをより簡潔なシーケンスのイベントへと変換することができる。この場合、イベントの数は、観察の時間窓にわたる本質的な傾向変化の回数に比例する。

一実施形態においては、システム状態は、傾向データから抽出された特徴のベクトルによって識別することができ、システム状態変化は、傾向における本質的な変化を表わすイベントによって区別することができる。ある実施形態においては、特徴ベクトルは、季節因子（seasonal factor）、線形傾向、分散変動、レベル変化、レベルドリフト、アウトライアおよびエンドポイント予測を含む傾向情報の各々の定性的状態で構成されるだろう。定量的データタイプの各タイプは、低レベル、通常レベルまたは高レベルなどの２または３ほどのわずかな別個のレベルに分類することができる。たとえば、スレッドまたはスタックセグメントのクラスの強度は、それが季節に応じて調整される予想強度の１シグマバンド内にあれば、正常と考えられるだろう。この例においては、観察の時間窓に関する高値または低値は、このクラスのスレッドのハイパーテンション状態またはハイポテンション状態についての定性的情報を提供する。別の例においては、季節因子は、週末から平日までの変化または平日から週末までの変化が不連続になる可能性がある。各季節内の（単調なパターンなどの）季節因子における傾向の形状と、異なる季節をつなぐ（鋸歯状パターンなどの）不連続度とは、特徴ベクトルで定性的な形式で記述することができる。

特徴ベクトルサブスペース（線形傾向、レベルドリフト、分散変動、エンドポイント予測）における特徴ベクトル、たとえば（高線形傾向、高レベルドリフト、高い分散変動、エンドポイント付近）は、ＪＶＭの冗長なＧＣログファイル内の時系列データから抽出することができる。一実施形態においては、一定の時間窓にわたるＪＶＭにおいて持続する特徴ベクトル（高線形傾向、高レベルドリフト、高い分散変動、エンドポイント付近）を観察することによって、ＪＶＭのメモリ状態をメモリリークとして分類することができる。状態は、特徴ベクトルがＪＶＭにおいて持続する場合に時間窓の開始時間ｔ１および終了時間ｔ２によって区別される一定の時間間隔の間だけ有効である。ＪＶＭの特徴ベクトルは、メモリリークサイトがいつ識別および修正されるかを変更してもよい。バグフィックスを適用することにより、後で観察されたＪＶＭの状態は、たとえば、開始時間ｔ２から終了時間ｔ３までの期間にわたって持続し得る正規メモリ状態として分類される新しい特徴ベクトル、たとえば（低線形傾向、低レベルドリフト、低い分散変動、エンドポイント無）によって記述される可能性がある。したがって、情報は、システム健全性がメモリリーク状態から正規メモリ状態にまで進んだことを示す可能性がある。一実施形態においては、この状態変化は改善傾向として分類することができる。代替的には、メモリリークが修正された後、メモリ管理問題は、特徴ベクトルにおける大きな分散変動として現われる可能性がある（低線形傾向、低レベルドリフト、高い分散変動、エンドポイント無）。これは、解決すべき１つ以上のＣＡＲＥ制御サイクルを含んでいてもよく、この期間中、システムは、メモリリーク状態からメモリ管理問題状態を経て正常なメモリ状態に至る状態遷移を経験する可能性がある。代わりに、観察された特徴ベクトルが正常なメモリ状態からメモリリーク状態に変化した場合、一実施形態においては、ＣＡＲＥ制御は、回帰傾向として情報を分類し、回帰の査定のためのアクターを呼出すことができる。メモリ特徴空間の状態を、スレッドまたはスタックセグメントの強度傾向などの他の特徴空間の状態と結合して、ＪＶＭの合成状態（正常なメモリ状態、正常なスレッド強度状態）を形成することができる。ある実施形態においては、特徴ベクトル状態の有効時間は、（バイテンポラル・データベーススキーマとしても公知である）マルチテンポラルデータベーススキーマの有効時間カラムを用いて、管理することができる。

一実施形態においては、第１のＣＡＲＥ制御サイクルは、シナリオ例における情報変化に応じて、メモリリーク状態を分類し、仮説を導き出す査定動作を呼び出し得る。情報変化の連鎖反応に応じて、第１のＣＡＲＥ制御サイクルは、ダンプ間における指定された時間経過に応じてターゲットＪＶＭから２つのヒープダンプを集めるよう指令を発行する解決を呼び出し得る。この指令はアクターによって実行され、結果として、新しい事実の中に２つのヒープダンプファイルを発生させることができる。第２のＣＡＲＥ制御サイクルは、２つのヒープダンプにおけるオブジェクトのヒストグラムを比較することによってメモリリークサイトを識別するために分類動作を呼び出してもよい。コードバグについての仮説は、メモリリークサイトの査定後に発行されてもよい。バグを修正してパッチするようにとの指令はコードバグの解決後に発行されてもよい。バグを修正しパッチするようにとの指令の規定後、第３のＣＡＲＥ制御サイクルは、新しい事実をメモリ管理問題状態として分類し、査定動作を呼び出してもよい。次いで、アクターによる査定により、結果として、メモリ管理ポリシー（たとえば、ソフト基準ＬＲＵポリシー）の不良コンフィギュレーションについての仮説が得られるかもしれない。第３のＣＡＲＥ制御サイクルは、解決動作を呼び出すことにより、結果として、ソフト基準ＬＲＵポリシーを調整するようにとの指令が得られる可能性がある。メモリ管理ポリシーを調整するようにとのこの指令はアクターによって規定（enacted）されてもよい。第４のＣＡＲＥ制御サイクルは、最後の規定によって集められた新しい事実に基づいて正常なメモリ状態を分類し得る。次いで、第４のＣＡＲＥ制御サイクルは、メモリリーク状態からメモリ管理問題状態を経て正常なメモリ状態に至る状態変化を観察することによって、改善傾向を分類してもよい。

一実施形態においては、ＣＡＲＥ制御は、ＪＶＭにおいてメモリ不足が起こるたびに、アクターを呼び出して、特徴ベクトル空間、たとえば、サブスペース（線形傾向、レベルドリフト、分散変動、エンドポイント予測）におけるすべての新しい事実を分類するだろう。十分な数のポジティブサンプルおよびネガティブサンプルが集められると、ＣＡＲＥ制御は、監視型学習を適用して、サポートベクトルマシンを構築することにより、メモリリーク問題を分類することができる。たとえば、特徴ベクトル（高線形傾向、高レベルドリフト、高い分散変動、エンドポイント付近）は、サポートベクトルマシンによってメモリリークとして分類することができる。

一実施形態においては、ＣＡＲＥ制御は、すべてがデータとして表わされている事実および情報エレメントにおける情報の変化についてのクエリをデータベースに登録することができる。事実の変化は規定によって引起こすことができる。事実における情報の変化は、情報を抽出または解釈する情報エレメントにおける規定および変化によって、引起こすことができる。知識エレメントの変化は、いくつかの実施形態においては、規定プロセスとしてモデル化されるオンラインまたはオフラインの機械学習プロセスによって引起こすことができる。ＣＡＲＥ制御は、データの変化に応じて分類アクション、査定アクション、解決アクションおよび規定アクションを開始することができる。いくつかの実施形態においては、ＣＡＲＥ制御エンジンは、バイテンポラル・データベースの上において、データベーストリガー、リアルタイムジャーナル分析および登録済みクエリを用いて実現することができる。いくつかの実施形態においては、ＣＡＲＥ制御エンジンは、オブジェクト変更通知またはクエリ結果変更通知についてのクエリをデータベースに登録することができる。登録されたクエリによって参照されるオブジェクトは登録済みオブジェクトである。したがって、事実データ、情報データ、仮説データおよび指令データ中の各オブジェクトは、登録済みオブジェクトであり得る。同様に、分類エレメント、査定エレメント、解決エレメントおよび規定知識エレメント中の各オブジェクトは、登録済みオブジェクトであり得る。

フレームワークは、分類、査定、解決および規定のようなアクションを実行するのに用いることができる特化されたアルゴリズムの進化を可能にし得る。特化されたアルゴリズムは必ずしも一緒に直接的に機能しないかもしれない。スレッドまたはスタックセグメントの強度における季節的傾向を監視するアルゴリズムは、必ずしも、ヒープ使用量傾向の決定を含むアルゴリズムとともに直接的に作用するわけではない。ＣＡＲＥ制御は、これらのさまざまなアルゴリズムを独立して発展させること、および、共通のアプリケーションとして進化可能な単一のシステムに一体化することを可能にするが、これは、正規化された事実、情報、仮説、および指令のデータモデルを介して相互作用する分類コンポーネント、査定コンポーネント、解決コンポーネントおよび規定コンポーネントとして、これらのアルゴリズムをカプセル化することによるものである。システムに新しいアルゴリズムを追加することにより、相加効果をもたらすことができる。システム内のアルゴリズムは互いに補完し合いかつ補強し合うことができる。アルゴリズムは、より優れた診断を実現するために互いに相互に関連し得る。ＣＡＲＥ制御実行モデルは、連続的にデータの変化について照会を行い、依存（dependent）コンポーネントの実行を開始することによって、対話を駆動する。これらのコンポーネントのうちのいくつかは、人のアクターと対話するユーザインターフェイスおよびメッセージ通信システムを含んでもよい。

さまざまなバイタルサインに基づいて季節的傾向把握などのドメインに加えられるドメイン特有のアルゴリズムは、初めは、フレームワーク内における分類エレメントとして特徴付けることができる。しかしながら、フレームワークを用いると、このようなアルゴリズムをさらに改良し理解することができる。このように改良および理解を高めることにより、適用される特定の環境のためにさらにより特化され得るパターンを取り込む能力を導き出すことができる。これはさらに高い段階の分類である。このさらに高い段階の分類は、情報のさまざまな項目を互いに関連付けることによって生じる。たとえば、特定のドメインにおいては、スレッドまたはスタックセグメントの強度情報はメモリ使用量情報に関連付けることができる。このような情報は、システム内において発行された指令に関連付けることができる。システムはこのような発行済み指令を取り込んで、これら指令を情報項目に形式的に関連付けることにより、それらの間のつながりを示すことができる。これらの関係がシステム内において構築されると、関係のパターンが認識可能になり得る。システムが認識することのできるパターンの種類は時間の経過とともに進化する可能性がある。

ＣＡＲＥ制御はまた、監視されているターゲットシステムのデータ、情報および状態の進化を視覚化するためのモデルとしての役割を果たす。たとえば、ＪＡＶＡ仮想マシン（ＪＶＭ）のヒープ使用量に関する生データは経時的に監視することができる。このような生データは、フレームワークにおいては、知識を適用することによって分類することができる事実である。知識は、数例を挙げると、季節的傾向把握アルゴリズム、信号処理アルゴリズム、サポートベクトルマシン、ニューラルネットワークおよびベイズネットワークの形を採り得る。情報は生データから導き出すことができ、特徴ベクトルで表わすことができる。より高レベルの情報は、サポートベクトルマシンによって特徴ベクトルの分類で識別される状態の形を採ることができる。このような分類情報は、システムの局面が状態に関して永続的に観察されるときの時間間隔を示してもよい。このような状態情報は、たとえば、ある状態から別の状態に変化するシステムの局面が監視される時点、たとえば、バグフィックスがＪＶＭ上に適用される時点、を示すように構成されてもよい。これらの時点は、情報のパターンが変化する時系列プロットにおける時点を決定することによって明らかになり得る。しばしば、情報変化が生データにおいて明らかにはならない（肉眼では見ることができない）時点は、生データから情報を抽出するかまたは信号を検出することによってのみ明らかにされる。例示的なシナリオにおいては、時系列の生データまたは傾向情報は、第１の時間間隔中に、ヒープ使用量に高い変動が存在する場合でも、ベースラインＪＶＭヒープ使用量が絶えずより高くドリフトすることを示し得る。ＪＶＭヒープ使用量におけるこのような安定したレベルドリフトはメモリリークの結果として起こり得る。次いで、生データは、連続的な第２の時間間隔中に、大きな変動が絶えず存在している際にベースラインＪＶＭヒープ使用量が平らになったことを示し得る。第１の間隔と第２の間隔との間における時点での生データの情報変化は、メモリリークがシステムに対してなされたいくつかの変更によって修正されたことを示し得る。第２の間隔中、ヒープ使用量における大きな変動が継続するかもしれない。次いで、第２の間隔の後に生データの情報変化が起こっている第３の間隔中、ヒープ使用量の変動が著しく減少するかもしれず、これは、さらに別の変更が第２の時間間隔と第３の時間間隔との間にシステムに対してなされたことを示し得る。第２の間隔と第３の間隔との間における変更は、メモリＬＲＵポリシーに対する調整動作に関連付けることができる。

この例においては、情報の複数の項目は生データから導き出すことができる。まず、ベースラインヒープ使用量におけるドリフトについての情報を導き出すことができる。第二に、ヒープ使用量の変動の変化についての情報を導き出すことができる。アルゴリズムはこのような情報を生データから導き出すことができる。生データをフィルタリングおよび変換することにより、対象となる情報だけを残しつつ、ノイズおよび外部の無関係な情報を生データから除去することができる。フィルタリングは、たとえば、データ中の季節的傾向の除去を含み得る。このようなフィルタリングされたデータ内では、パターンは、このようなパターンを発見しようと試みる自動システムにとってより明確になり得る。予測も、そこから導き出されるデータおよび情報に基づいて実行されてもよい。たとえば、データおよび導き出された情報に基づいて、システムが、メモリリークの作用を打ち消すシステム再始動のなされていない状態では、将来、特定の日付および時間にメモリ不足になりクラッシュするであろうという予測を行うことができる。このような予測は、データに生じる季節的（たとえば、日ごと、週ごと、３か月ごとの）傾向に合わせて調整することができる。

生データがシステムの変化を示すたびに、上述の特徴的な第１の間隔、第２の間隔、および第３の間隔を生成するが、その変化は、解決アクションの出力である何らかの指令を発行した結果、起こり得るものである。この明細書中に開示されるＣＡＲＥ制御フレームワークを適用することによっても、査定アクションを呼び出すことなく指令を生成することができる。時系列での季節的傾向把握に関連付けられる情報は、季節的傾向および非季節化された線形傾向および非線形傾向に基づいたものであって、この情報は、ＪＶＭのための同じシナリオ例を用いて、システムがその時間の終了前に再開されなければターゲットＪＶＭがその時点から既知の期間内にクラッシュするであろうことを、一定の信頼水準で予測することができる。このような予測は、システム管理者が、予測されたクラッシュが起こるであろう瞬間よりも前の何らかの都合のよい時間（たとえば週末）中にＪＶＭの再始動を含むシステムメンテナンスを実行するべきであることを、このシステム管理者に対して示唆してもよい。ＣＡＲＥ制御は、短期毎に予想されるエンドポイントを分類した後、ＪＶＭを再開するなどの緊急のステアリング指令を発行してもよい。メモリリーク条件でＪＶＭを作動させる第１の間隔内に傾向を監視する数日または数週間後に、ＣＡＲＥ制御は、メモリリークサイトを識別しバグフィックスを査定するために、ヒープダンプを集めるようアクターに指令を課すこととなる査定および解決を呼び出すことができる。メモリリークのためのバグフィックスの規定は数週かかる可能性がある。バグフィックスをターゲットＪＶＭに適用する準備ができるまでの平均時間内に、ＪＶＭはメモリリーク条件で動作してもよい。ＣＡＲＥ制御は、バグフィックスについてのペンディング指令が実行されている間、動作範囲内でＪＶＭのメモリ状態を操作するために、必要に応じて再始動指令を発行し続けるだろう。これらの短期的な操作指令は、エンドポイント予測についての情報を用いる分類によって発行されるものであって、査定アクションを含まない可能性がある。このような再始動が規定されると、これらの再始動がヒープ使用量に対してもたらした影響を示すことが可能になる前後に集められた生データの情報が変化する。ＪＶＭ再始動によって引起こされる情報の変化は、短期的な傾向として監視することができ、システムに対して長期的な影響をもたらさない操作指令のインスタンスとしてＣＡＲＥ制御モデルにおいて、形式的に区別することができる。たとえば、ＪＶＭが毎週再始動されるにもかかわらず、上述の特徴ベクトルが、メモリリーク状態として識別される（高い線形傾向、高レベルドリフト、高い分散変動、エンドポイント付近）で持続するだろう。対照的に、メモリリークバグのための修正を適用する指令は、第１の間隔におけるメモリリーク状態から第２の間隔におけるメモリ管理問題状態までの変化によって示される永続的作用を有するだろう。同様に、上述のメモリＬＲＵポリシーを調整するようにとの指令は、第２の間隔におけるメモリ管理問題状態から第３の間隔における正常なメモリ状態までの変化によって示される永続的作用を有するだろう。

以下の形式上の表記では、ｎタプルＡは関数Ｆとみなすことができ、そのドメインはエレメントインデックスＸのタプルの内在セットであり、そのコドメインＹは、エレメントのタプルのセットである。形式的には、ｎタプル（ａ_１，ａ_２，…，ａ_ｎ）はシステム（Ｘ，Ｙ，Ｆ）であり、この場合、Ｘ＝｛１，２，…，ｎ｝，Ｙ＝｛ａ_１，ａ_２，…，ａ_ｎ｝，およびＦ＝｛（１，ａ_１），（２，ａ_２），…，（ｎ，ａ_ｎ）｝である。順序対は２タプルであり、３つ組は３タプルである。π_ｉで示されるｎタプルの予測は、関数π_ｉ（（ａ_１，ａ_２，…，ａ_ｎ）＝Ｆ（ｉ）＝ａ_ｉである。

Ｎ項関係Ｒはｎタプルのセットである。関係の属性は、関数Ｇのコドメインがその関係の属性のセットとなるように、システム（Ｘ，Ｚ，Ｇ）、Ｘ＝｛１，２，…，ｎ｝、Ｚ＝｛α_１，α_２，…，α_ｎ｝、およびＧ＝｛（１，α_１），（２，α_２），…，（ｎ，α_ｎ）｝であるｎタプル（α_１，α_２，…，α_ｎ）内の原子である。π_αｉによって示されるｎタプルの予測は、関数π_αｉ（（ａ_１，ａ_２，…，ａ_ｎ））＝Ｆ（Ｇ^−１（α_ｉ））＝ａ_ｉである。Ｎ項関係Ｒの予測π_αｉ（Ｒ）は、Ｒ内のすべてのタプルを属性α_ｉに制限することによって得られるセットである。たとえば、π_{FeatureVector}: FeatureVector × ValidTime × FigureOfMerit → FeatureVectorとなる。予測π_{FeatureVector}（Observation）は、Observation内のすべてのタプルを属性FeatureVectorに制限することによって得られるセットである。Ｎ項関係における各々のｎタプルは、ｎタプルが持続するかまたは回復可能になるトランザクション時間を表わすシステム変更回数（ＳＣＮ：system change number）に暗黙的に関連付けられる。予測関数π_ＳＣＮが存在し、そのドメインはｎタプルのセットであり、そのコドメインは、システム変更回数（ＳＣＮ）のセットである。ＳＣＮのためのDateTimeを計算する関数：SCN→DateTimeが存在する。

選択σ_proposition（Ｒ）（Ｒは関係であり、proposition（命題）はブール式である）は、命題を満たすＲにおけるタプルを選択する。たとえば、AssessmentInputがFeatureType × Assessmentの関係であると想定すると、選択σ_{FeatureType=MemoryState}（AssessmentInput）は、MemoryStateと合致するFeatureTypeを有するAssessmentInput関係にあるタプルのセットである。クエリπ_Assessment（σ_{FeatureType＝MemoryState}（AssessmentInput））は、入力としてMemoryState特徴を採用するAssessment関数のセットである。

本発明の一実施形態においては、ＫＩＤＳシステムは、Actor（アクター）、Agent（エージェント）、Entity（エンティティ）、CARE、Metadata（メタデータ）、およびReification（具体化）の６タプルである。

ＫＩＤＳ＝（Actor，Agent，Entity，CARE，Metadata，Reification）
Actorは、分類アクション、査定アクション、解決アクションおよび規定アクションを実行するようシステムと対話することができるアクターのセットである。

TacitKnowledgeProfile、SocialNetworkProfile、およびPreferenceProfileは、３つの異なる関数であって、その各々が、ActorのメンバーをProfileVectorにマッピングする。

TacitKnowledgeProfile: Actor → ProfileVector
SocialNetworkProfile: Actor → ProfileVector
PreferenceProfile: Actor → ProfileVector
ProfileVectorは、ｎタプル（ｎ＝１，２，３，…）のプロファイルのセットである。

ProfileVector = Profileⁿ
Profileは、ValueとValidTimeとFigureOfMeritとProfileTypeとの間の関係である。

Profile = Value × ValidTime × FigureOfMerit × ProfileType
Personalization（パーソナル化）は、パーソナル化された関数を生成するようにパラメータ化された関数テンプレートにプロファイルベクトルを適用するカレー演算である：
Personalization : FunctionTemplate × ProfileVector → Function
たとえば、Classification関数、Assessment関数、Resolution関数およびEnactment関数などの知識関数は、アクターの暗黙知または優先度プロファイルから得られるProfileVectorを適用することによってパーソナル化することができる。

Personalization(ClassificationTemplate)(ProfileVector) = Classification
Personalization(AssessmentTemplate)(ProfileVector) = Assessment
Personalization(ResolutionTemplate)(ProfileVector) = Resolution
Personalization(EnactmentTemplate)(ProfileVector)= Enactment
Agentは、Userのために機能するコンピュータプログラムまたはハードウェアデバイスのセットである。

Entityは監視されているエンティティのセットである。Entityは、Ｊａｖａ ＶＭ、Ｏｒａｃｌｅ ＶＭ、データベース、サーバ、サーバクラスタ、ドメイン、ポッド、ネットワークスイッチ、ファイアウォール、サーバにおける個々のクラスのスレッドおよびスレッドセグメントなどを含み得る。

CAREは、Data（データ）およびKnowledge（知識）の順序対である。
CARE = (Data, Knowledge)
Dataは、４タプルのFact（事実）、Information（情報）、Hypothesis（仮説）、およびDirective（指令）である。

Data = (Fact, Information, Hypothesis, Directive)
FactはFSDおよびFeature（特徴）の順序対である。

Fact = (FSD, Feature)
ＦＳＤ（Flexible Schema Data：フレキシブルスキーマデータ）は、ｎタプルのValue（値）とValidTimeとEntity（エンティティ）とFSDTypeとの間の関係である。

FSD = Valueⁿ × ValidTime × Entity × FSDType
ＦＳＤオブジェクトの一例として、ＸＹＺポッドにおけるＣＲＭドメイン内のセールスサーバから一連のスレッドダンプを含むスレッド・ダンプ・ファイルがある。この場合、セールスサーバ、ＣＲＭドメインおよびＸＹＺポッドは、Entityのメンバーであり、スレッド・ダンプ・ファイルはFSDTypeのメンバーである。

Featureは、ValueとValidTimeとFigureOfMeritとEntityとFeatureTypeとの間の関係である。Featureは、データの一連の観察の際に低、正常、高などの分類値を表わす。

Feature = Value × ValidTime × FigureOfMerit × Entity × FeatureType
Featureオブジェクトの一例として、ＸＹＺポッドにおけるＣＲＭドメイン内のOrderCaptureサーバにおけるサブミット・オーダ・スレッドのハイパーテンション状態が挙げられる。この場合、サブミット・オーダ・スレッド、OrderCaptureサーバ、ＣＲＭドメインおよびＸＹＺポッドはEntityのメンバーであり、ハイパーテンション状態は、スレッド・強度またはスタック・セグメント・強度のFeatureTypeによって指定される範囲の値である。

FeatureVectorは、ｎタプル（ｎ＝１，２，３，…）のFeatureのセットである。
FeatureVector = Featureⁿ
一実施形態においては、FeatureVectorは、共通のValidTimeを有する一連のFeaturesである。

ValidTimeは、DateTimeの順序対のセットである。［ｔ１、ｔ２）によって表わされる時間間隔は、セット｛ｔ｜ｔ１＜ｔ２およびｔ＞＝ｔ１およびｔ＜ｔ２（t, t1, t2 εDateTime）}である。たとえば、２つのValidTimeの[2013-08-31 12:00 AM PST, 2013-09-01 9:00 AM PST)および[2013-09-01 9:00 AM PST, ∞)は、１つのValidTime[2013-08-31 12:00 AM PST, ∞)に結合することができる。時間インスタンスｔ１は［ｔ１，ＮＡ）によって表わすことができる。

ValidTime = [DateTime, DateTime ∪ {∞. NA})
FigureOfMeritは、信頼レベル、信頼間隔、確率、スコア、２乗平均平方根誤差などを表わす定量値または定性値である。FigureOfMeritは、図１３に関連付けてさらに以下に説明される。

Information（情報）は、４タプルのObservation（観察）、Prediction（予測）、Norm（ノルマ）およびObjective（目標）である．
Information = (Observation, Prediction, Norm, Objective)
Observationは、FeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Observation = FeatureVector × ValidTime × FigureOfMerit
Predictionは、FeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Prediction = FeatureVector × ValidTime × FigureOfMerit
Normは、FeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Norm = FeatureVector × ValidTime × FigureOfMerit
Objectiveは、目標関数を最適化するFeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Objective = FeatureVector × ValidTime × FigureOfMerit
Hypothesis（仮説）は、FeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Hypothesis = FeatureVector × ValidTime × FigureOfMerit
Directive（指令）は、FeatureVectorとValidTimeとFigureOfMeritとの間の関係である。

Directive = FeatureVector × ValidTime × FigureOfMerit
Knowledge（知識）は、４タプルのClassification（分類）、Assessment（査定）、Resolution（解決）およびEnactment（規定）である。

Knowledge = (Classification, Assessment, Resolution, Enactment)
Classificationは関数のセットであり、その各々が、ｎタプルのＦＳＤまたはｍタプルのFeatureVectorをObservation、Prediction、NormまたはObjectiveにマッピングする。

Classification = {f|f:(FSDⁿ ∪FeatureVector^m) → (Observation ∪ Prediction ∪ Norm ∪ Objective)（nおよびmは何らかの整数）}
Assessmentは関数のセットであり、その各々が、FeatureVectorをHypothesisにマッピングする。

Assessment = {f|f: FeatureVector → Hypothesis}
Resolutionは関数のセットであり、その各々がFeatureVectorをDirectiveにマッピングする。

Resolution = {f|f: FeatureVector → Directive}
SymptomResolutionはResolution関数のサブセットであり、そのドメインは、FactまたはInformation中のFeatureVectorに制限される。

SymptomResolution = {f|f: FeatureVector → Directiveであり、このため、FeatureVector = π_{FeatureVector}(codomain(g))となる（関数ｇはEnactmentまたはClassificationのメンバーである）｝
ClassificationResolutionはResolution関数のサブセットであり、そのドメインは、InformationにおけるObservation、Prediction、NormおよびObjective中のFeatureVectorに制限される。

ClassificationResolution = {f|f: FeatureVector → Directiveであり、このため、FeatureVector = π_{FeatureVector}(codomain(g))となる（関数gはClassificationのメンバーである）}
AssessmentResolutionは、Resolution関数のサブセットであり、そのドメインは、Hypothesis中のFeatureVectorに制限される。

AssessmentResolution = {f|f: FeatureVector → Directiveであり、このため、FeatureVector = π_{FeatureVector}(codomain(g))となる（関数gはAssessmentのメンバーである）}
ExpertResolutionは、Classification関数、Assessment関数およびResolution関数の合成であるResolution関数のサブセットである：
ExpertResolution = Classification ・ Assessment ・ Resolution
ExpertResolution : (FSD ∪ FeatureVector) →(Observation ∪ Prediction ∪ Norm) × Hypothesis × Directive
Enactmentは関数のセットであり、その各々は、DirectiveをFSDの集合またはFeatureVectorの集合にマッピングする。

Enactment = {f|f: Directive → (FSDⁿ ∪ FeatureVector^m )（nおよびmは何らかの整数）}
MetaDataは、４タプルのProfileType、FSDType、FeatureTypeおよびInfluenceである。

MetaData = (ProfileType, FSDType, FeatureType, Influence)
ProfileTypeはオブジェクトのセットであり、その各々は、Name、データTypeおよびProfileについての値のRangeを規定する。ProfileTypeは、「役割」などのNameと、（現場監督、監督者、指導管理者、マネージャ）などの値のRangeを規定することができる。別の例においては、ProfileTypeは、「責任」などのNameと、（WebLogic管理、データベース管理、Ｌｉｎｕｘ管理、ネットワーク管理）などの値のRangeとを規定することができる。別の例として、「メモリ調整専門知識」というNameを有するProfileTypeに関して、Rangeは、「上級者」、「中級者」および「初心者」などの定性値を含み得る。別の例として、「アプリケーションソースコード知識」というNameを有するProfileTypeに関して、Rangeは、「デベロッパ」、「アーキテクト」および「テスタ」などの定性値を含み得る。このような値はProfileを規定するのに用いることができる。

ProfileType = Name × Type × Range × DefaultValue
FSDTypeは、冗長なＧＣログ、周期的なスレッドダンプ、ヒープダンプ、ＯＳウォッチャーログ、データベースＡＷＲスナップショット、データベーストレースファイル、クリックストリーム、ＲＥＵＩレコード、アクセスログ等々、さらには、季節因子、レベルドリフト、レベルシフト、レベルスパイク、分散変動、アウトライア、エンドポイント予測、再始動、メモリ不足イベント、スタックした（stuck）スレッドイベントなどの集合体にフィルタリングされた規則的または不規則的な時系列データ等々、のファイルのタイプを規定する分類値で構成されたセットである。

FSDType = Name × {Binary, Text} × Encoding × Language
FeatureTypeはオブジェクトのセットであり、その各々は、Name、データTypeおよびFeatureのための値のRangeを規定する。FeatureTypeは、「メモリ状態」などのNameと、（メモリリーク、メモリ管理問題、正常メモリ）などの値Rangeを規定することができる。別の例においては、FeatureTypeは、「スレッド強度状態」などのName、および（ハイパーテンション、ハイポテンション、コンボイ効果）などの値Rangeを規定することができる。別の例として、Name「変動」を有するFeatureTypeに関して、Rangeは、「高」、「正常」、「低」などの定性値を含み得る。別の例として、Name「エンドポイント」を有するFeatureTypeに関して、Rangeは、「近い」「遠い」、および「エンドポイント無」などの定性値を含み得る。このような値はFeatureを規定するために用いることができる。

FeatureType = Name × Type × Range × DefaultValue
Featureはデータから抽出することができる。Typeは定量的ではなく分類的であり得る。FeatureおよびFeatureTypeはともに、１セットの許容値に制限することができる名前−値の対を規定する。これらの値がデータから抽出されると、これらの値についての有効時間はFeatureとともに伝搬させることができる。有効時間についての説明を以下に記載する。

図１３は、本発明の実施形態に従った傾向を示す図である。この明細書中に記載される技術を用いると、傾向に基づいて、エンドポイント１３０２は一定の時間および日に予測することができる。有効時間１３０４は、エンドポイント１３０２を予測するのに用いられた傾向データに関連付けられる。この場合、エンドポイントは、有効時間１３０４の数時間内に起こると予測される。エンドポイント１３０２を予測するのに用いられるデータは、有効時間１３０４の一部である。このようなデータは、たとえば、エンドポイント１３０２に達する前にＪＶＭを再開させるために用いられてもよい。

一実施形態においては、有効時間１３０６は複数の間隔にわたり得る。この場合、各々の間隔の境界は、ＪＶＭの再開などの何らかのイベントによって規定される。各々の時間間隔またはセグメントは、それが何らかのエンドポイントに一時的に接近していることを示すことができる。エンドポイントへの接近は特徴の一例である。この場合、有効時間は、ＪＶＭのライフサイクルによって範囲が定められてもよい。別の例においては、有効時間はデータベースのライフサイクルによって範囲が定められてもよい。図１３に示されるような繰返しパターンの後、何らかの状態が変化し得ると予想される。たとえば、バグフィックスは状態を変化させる可能性がある。このようなイベントの後に続く有効時間１３０８中には、傾向は上昇しないかもしれない。

上述のとおり、性能指数は、信頼間隔または確率を表わし得る。たとえば、性能指数が図１３における信頼間隔１３１０を表わす場合、性能指数は、エンドポイント１３０２の予測用の信頼間隔１３１０がプラス５時間またはマイナス５時間であることを示し得る。いくつかの実施形態においては、性能指数を定量的に表わすことができるが、他の実施形態においては、性能指数は定性的に表わすことができる。たとえば、プラス５時間またはマイナス５時間などの定量的基準である信頼間隔１３１０ではなく、信頼間隔１３１０は、「かなり正確」などの定性的基準であってもよい。このような定性的基準は、客観的な概念ではなく、主観的な概念であってもよい。

複数の統計パラメータが同じマシンから観察されてもよい。安定した傾向に加えて、安定した傾向に近似する大きな変動分散が観察される可能性がある。大きな変動分散を表わす特徴は、エンドポイントを表わす特徴タイプとは異なる特徴タイプによって表わされてもよい。分散についての特徴タイプは、たとえば、「高」、「正常」または「低」などの一連の定性値を含み得る。しかしながら、特徴についての有効時間は部分的に重なる可能性がある。特徴は、同じシステムのさまざまな局面を表わし得る。各々の特徴についての有効時間はその特徴とともにシステム内に伝搬されてもよい。一実施形態においては、複数の特徴を含む特徴ベクトルについての有効時間は、それらの特徴すべてについての有効時間の交差である。

事実データの観察により、複数の異なる特徴が相関関係にあることが明らかになり得る。このような相関関係は、たとえば、特徴の有効時間が部分的に重なっているスパンがデータセット全体の有効時間よりも小さい場合に、明らかにされる可能性がある。

Influence（影響）は、FSDTypeとFeatureTypeとknowledgeのエレメントとの間の８タプルの入出力関係である。

Influence = (ClassificationInput, ClassificationOutput, AssessmentInput,
AssessmentOutput, ResolutionInput, ResolutionOutput, EnactmentInput,
EnactmentOutput)
ClassificationInputは、FSDTypeまたはFeatureTypeとClassificationとの間の関係である。

ClassificationInput = (FSDType ∪ FeatureType) × Classification × Mandatory
ClassificationOutputは、ClassificationとFeatureTypeとの間の関係である。

ClassificationOutput = Classification × FeatureType
AssessmentInputは、FeatureTypeとAssessmentとの間の関係である。

AssessmentInput = FeatureType × Assessment × Mandatory
AssessmentOutputは、AssessmentとFeatureTypeとの間の関係である。

AssessmentOutput = Assessment × FeatureType
ResolutionInputは、FeatureTypeとResolutionとの間の関係である。

ResolutionInput = FeatureType × Resolution × Mandatory
ResolutionOutputは、ResolutionとFeatureTypeとの間の関係である。

ResolutionOutput = Resolution × FeatureType
EnactmentInputは、FeatureTypeとEnactmentとの間の関係である。

EnactmentInput = FeatureType × Enactment × Mandatory
EnactmentOutputは、EnactmentとFSDTypeまたはFeatureTypeとの間の関係である。

EnactmentOutput = Enactment × (FSDType ∪ FeatureType)
Mandatoryは、入力されたFeatureTypeが関数を呼び出すのに必須であるかどうかを示すブール値である。

Reification（具体化）は、５タプルの（CARELoop，Classified（分類済み），Assessed（査定済み），Resolved（解決済み），Enacted（規定済み））である。

CARELoop = Classified × Assessed × Resolved × Enacted
Classified = (FSD ∪ FeatureVector) × Classification × (Observation ∪ Prediction ∪ Norm) × (Actor ∪ Agent) × TransactionTime
Assessed = FeatureVector × Assessment × Hypothesis × (Actor ∪ Agent) × TransactionTime
Resolved = SymptomResolved ∪ ClassificationResolved ∪ AssessmentResolved ∪ ExpertResolved
SymptomResolved = FeatureVector × SymptomResolution × Directive × (Actor ∪ Agent) × TransactionTime
ClassificationResolved = FeatureVector × ClassificationResolution × Directive × (Actor ∪Agent) × TransactionTime
AssessmentResolved = FeatureVector × AssessmentResolution × Directive × (Actor ∪ Agent) × TransactionTime
ExpertResolved = FeatureVector × ExpertResolution × Observation × Prediction × Norm × Hypothesis × Directive × (Actor ∪ Agent) × TransactionTime
Enacted = Directive × Enactment × (FSD ∪ FeatureVector) × (Actor ∪ Agent) × TransactionTime
TransactionTimeは、順序対のDateTimeのセットである。［ｔ１、ｔ２）によって表わされる時間間隔は、セット｛ｔ｜ｔ１＜ｔ２およびｔ＞＝ｔ１およびｔ＜ｔ２（t, t1, t2 εDateTime）}である。たとえば、２つのTransactionTimeの[2013-08-31 12:00 AM PST, 2013-09-01 9:00 AM PST)および[2013-09-01 9:00 AM PST, ∞)は、１つのTransactionTime[2013-08-31 12:00 AM PST, ∞)に結合することができる。時間インスタンスｔ１は［ｔ１、ＮＡ）によって表わすことができる。TransactionTimeは、情報が持続するかまたは回復可能になり、他の回復可能なトランザクションにとって認識できるようになる期間を記録する。

TransactionTime = [DateTime, DateTime ∪ {∞. NA})
たとえば、ＪＶＭについてのＧＣログが更新されたときにＦＳＤに変化があると、ＣＡＲＥ制御はFSDTypeを決定することができる。ＣＡＲＥ制御はFSDTypeを用いて、ClassificationInput関係の中からそのFSDTypeのＦＳＤによって影響を受けたClassification関数を選択することができる。ＣＡＲＥ制御はまた、Classification関数についての入力を含むFeatureTypeのクロージャに照会を行うことができる。次いで、ＣＡＲＥ制御は、Classificationを呼び出すために必要なＦＳＤおよびFeatureVectorを構成することができる。Classification関数が季節フィルタ、決定ルール、サポートベクトルマシンなどによって表わされる場合、ＣＡＲＥ制御は、関数の実行を開始するだろう。Classification関数が暗黙知プロファイルによって表わされる場合、ＣＡＲＥ制御は、Classification関数の暗黙知プロファイルに最適に適合した暗黙知プロファイルを有する１つ以上のアクターを識別し、さらに、分類アクションを実行するためにアクターと対話を開始するだろう。マシンおよび暗黙知分類の両方の場合、このClassification関数の結果はObservation、PredictionまたはNormとなる。このステップの後、ＣＡＲＥ制御は、入力されたＦＳＤの集合、入力されたFeatureVectorの集合、Classification関数、およびObservationまたはPredictionまたはNormの間の関係を具体化することができる。ＣＡＲＥ制御は、具体化の際に、任意の数のActor、任意の数のEntity、Classification関数を実現するプログラムのバージョン、Classification関数に適用されるパラメータ、および他の文脈情報を含み得る。

いくつかの実施形態においては、ＦＳＤのValidTimeは、時系列データのセグメントのValidTimeから導き出すことができる。同様に、FeatureVectorのValidTimeは、FeatureVectorにおけるFeatureの各々のValidTimeの共通部分（intersection）から導き出すことができる。Classification関数を呼出した後、情報変更通知を引起こす新しいFeatureVectorが生成されるだろう。ＣＡＲＥ制御は、ClassificationInput、AssessmentInputおよびResolutionInputの関係の中から、新しいFeatureVectorにおけるFeatureのいずれかによって影響されるClassification関数、Assessment関数およびResolution関数のいずれかを選択することができる。Classification関数、Assessment関数およびResolution関数に影響を及ぼすFeatureTypeに対応する必要なすべてのFeatureのクロージャを獲得した後、ＣＡＲＥ制御は、これらの選択された関数を順々にまたは並行に呼び出すことができる。例示的シナリオにおいては、新しいFeatureVector、たとえば（高レベルドリフト、高い分散変動、エンドポイント付近の予測）の変更通知がなされると、ＣＡＲＥ制御は、このFeatureVectorを分類するようにより高レベルのClassification関数を選択することができる。サポートベクトルマシンなどのより高レベルのClassification関数は、メモリリーク、メモリ管理問題、正常メモリ、ハイパーテンション、ハイポテンション、コンボイ効果、デッドロックなどの分類的Featureに対して、Feature空間におけるFeatureVector（季節因子、レベルドリフト、レベルシフト、分散変動、アウトライア、エンドポイント予測、再始動、メモリ不足イベント）をマッピングすることができる。メモリリーク状態を分類した後、ＣＡＲＥ制御は、情報変更についての別の通知を受信することができる。

サポートベクトルマシンを学習する監視型学習技術などの機械学習技術は、分類が関連付けられている１セットの特徴ベクトルを入力として受信することができ、その中の新しいデータポイントを別個の明確な分類に属するものとして分類することを自動的に学習することができる。図１４は、本発明の実施形態に従った、自動的に分類されたデータポイントのセットの例を示す図である。クラスデバイダ１４０２の一方側のポイントはクラス１４０４に属するとみなされ、クラスデバイダ１４０２の反対側のポイントはクラス１４０６に属するとみなされる。たとえば、クラス１４０４は、「真」であるデータ項目を含んでいてもよく、クラス１４０６は、「偽」であるデータ項目を含んでいてもよい。この例においては、分類は２進数である。本発明のさまざまな実施形態においては、分類はＮ式であり得る。この場合、Ｎはクラスの数である。このため、サポートベクトルマシンは、特徴ベクトルを受取ることができ、そして、１セットの分類されたサンプルデータから監督下で事前に学習されたクラスデバイダ１４０２などの１つ以上のクラスデバイダを用いて、その特徴ベクトル内に含まれるデータに基づいて特徴ベクトルのクラスを決定することができる。一方のクラスにおけるデータポイントは、メモリリークがシステムに存在することを示す可能性があり、他方のクラスにおけるデータポイントは、メモリリークがシステムにないことを示す可能性がある。

Classification関数を呼出した後、ＣＡＲＥ制御がResolution関数を選択した場合、このＣＡＲＥ制御は、Directiveを生成するようResolution関数を実行することができる。Assessment関数なしでClassification関数の後に生成されたこのようなDirectiveを用いて、所望の軌道に沿ってシステムを操作することにより、Factの新しいコンポーネントを集めるかまたは破滅的な故障を迅速に回避することができる。たとえば、ＪＶＭがメモリ不足になりそうであることをFeatureベクトルが示す場合、週末にＪＶＭを再開するようDirectiveが発行されて、以降の平日における季節に応じたピーク時間中にクラッシュすることを回避することができる。発明の実施形態においては、ＣＡＲＥプロセスサイクルは、Directiveを発行することによってNormまたはObjectiveについての何らかの許容範囲内ですべてのObservationおよびPredictionを維持するように繰り返すことができる。

別の例示的シナリオにおいては、ＣＡＲＥ制御は、新しいFeatureVectorにおける新しいFeatureのセットによって影響を受けるAssessment関数を選択することができる。ＣＡＲＥ制御は、AssessmentInput関係の中からAssessment関数に影響を及ぼす所要のFeatureTypeに照会を行うことができる。次いで、ＣＡＲＥ制御は、Assessment関数を満たすのに必要なFeatureのクロージャに照会を行うことができる。ある状況においては、Assessment関数は、Assessment関数の専門知識プロファイルに合致する暗黙知プロファイルを有するActorに割当てられてもよい。別の状況においては、Assessment関数はベイズネットワークによって表わすことができる。ＣＡＲＥ制御は、ベイズネットワークを満たすのに必要なFeature空間にわたってFeatureVectorを構成することができる。ベイズネットワークについての入力FeatureVectorのValidTimeは、上述のとおりコンポーネントFeatureの各々のValidTimeから導き出すことができる。次いで、ＣＡＲＥ制御は、ベイズネットワークの実行を開始することができる。ベイズネットワークの実行後、ＣＡＲＥ制御は、FeatureVectorと、Assessment関数を表わすベイズネットワークと、Hypothesisとの間の関係を具体化することができる。

ベイズネットワークのHypothesisに関連付けられた新しいFeatureVectorの変更通知がなされると、ＣＡＲＥ制御は、ResolutionInput関係の中から新しいFeatureVector内のFeatureによって影響を受けるいかなるResolution関数をも選択することができる。Resolution関数のために必要なFeatureTypeに対応するFeatureのクロージャを獲得した後、ＣＡＲＥ制御は、Directiveを生成するためにResolution関数を呼び出すことができる。Resolution関数が暗黙知プロファイルによって表わされる場合、ＣＡＲＥ制御は、Resolution関数の暗黙知プロファイルに最適に合致する暗黙知プロファイルを有する１つ以上のアクターを識別し、解決アクションを実行するためにアクターとの対話を開始するだろう。ＣＡＲＥ制御は、FeatureVectorとResolution関数とDirectiveとの間の関係を具体化することができる。

いくつかの実施形態においては、ＣＡＲＥ制御プロセスは、Enactment関数またはClassification関数によって生成される新しいFeatureVectorの変更通知がなされると、SymptomResolution関数またはClassificationResolution関数を選択することができる。ＣＡＲＥ制御プロセスは、Hypothesisを作成することを目的とするAssessmentResolution関数で、選択されたSymptomResolution関数またはClassificationResolution関数をラップすることができる。このように選択されたSymptomResolution関数またはClassificationResolution関数が暗黙知プロファイルに関連付けられる場合、ＣＡＲＥ制御プロセスは、SymptomResolution関数またはClassificationResolution関数に関連付けられた暗黙知プロファイルに合致する暗黙知プロファイルを有する１つ以上のActorを選択するだろう。ＣＡＲＥ制御プロセスは、（［００４９］および［００５０］において誘導型ソーシャルタギングとして記載された）適切なHypothesisを構成するための語彙を供給するAssessmentResolution関数を選択するだろう。ＣＡＲＥ制御は、場合によっては誘導型ソーシャルタギングを用いて、語彙のレパートリーを供給することによってHypothesisを公表するようにActorに依頼することができる。ＣＡＲＥ制御は、FeatureVectorと、SymptomResolution関数またはClassificationResolution関数と、Hypothesisと、Directiveとの間の関係を具体化することができる。ＣＡＲＥ制御は、具体化する際にActorおよびAssessmentResolution関数を含み得る。FeatureVectorとHypothesisとの間、およびHypothesisとDirectiveとの間のこの具体化関係は、機械学習技術によって、自動Assessment関数およびAssessmentResolution関数を開発するためのサンプルケースとして用いることができる。

いくつかの実施形態においては、ＣＡＲＥ制御プロセスは、Enactment関数によって生成された新しいFeatureVectorの変更通知がなされると、ExpertResolution関数を選択することができる。ExpertResolution関数は、典型的には、暗黙知プロファイルに関連付けられる。ＣＡＲＥ制御は、ExpertResolution関数に関連付けられた暗黙知プロファイルに合致する暗黙知プロファイルを有する１つ以上のActorを選択するだろう。ＣＡＲＥ制御は、ExpertResolution関数を実行するようにActorを割当てるだろう。Actorは、場合によっては誘導型ソーシャルタギングを用いて、Observation、Prediction、Norm、Objective、Hypothesis、およびDirectiveを含むExpertResolution関数の必要な出力をすべて供給することができる。次いで、ＣＡＲＥ制御は、FeatureVectorと、ExpertResolution関数と、Observationと、Predictionと、Normと、Objectiveと、Hypothesisと、Directiveとの間の関係を具体化することができる。ＣＡＲＥ制御は、具体化する際に１つ以上のActorを含み得る。このシナリオにおいては、Actorは、単一のステップで、Classification、AssessmentおよびResolutionの役割を果たすことができる。

Resolution関数に伴って新しいDirectiveの変更通知がなされると、ＣＡＲＥ制御は、新しいDirectiveのFeatureVectorにおける新しいFeatureのセットによって影響を受けるEnactment関数を選択することができる。ＣＡＲＥ制御は、EnactmentInput関係の中から、Enactment関数に影響を及ぼす所要のFeatureTypeに照会を行うことができる。次いで、ＣＡＲＥ制御は、Enactment関数を満たすのに必要なFeatureのクロージャに照会を行うことができる。次いで、ＣＡＲＥ制御は、Directiveによって影響を受けたEnactment関数を呼び出すことができる。ターゲットＪＶＭのヒープダンプを集めるための命令などのDirectiveは、ＪＶＭ専門知識を含むプロファイルを有するActorに割当てることができる。

カスタマサービスの要求、バグレポートまたはオンラインヘルプフォーラムをサポートするシステムは、典型的には、ユーザに自然言語テキストで問題を書込ませて、当該問題に関連するファイルのセットを提出させる。自然言語テキストおよびログファイルを含むこれらの非体系的なデータは、ＣＡＲＥにおける、FactデータおよびInformationデータの一部を含み得る。典型的には、分析者または他の参加者は、ユーザの書込みに対して自然言語テキストで応答することによって問題解決を示唆するだろう。いくつかの実施形態においては、自然言語処理（ＮＬＰ：Natural Language Processing）ツールは、ユーザの問題記述テキストにおけるFeatureVectorと、分析者の応答テキストにおけるDirectiveとを抽出するために用いることができる。本発明の一実施形態においては、ＣＡＲＥ制御は、外部リポジトリにおける非体系的な内容から抽出されたFeatureVectorおよびDirectiveを具体化する目的で、SymptomResolution関数を指定することができる。ＣＡＲＥ制御は、サービス要求、バグレポートまたはオンラインヘルプフォーラムにおいて、各々の事例に応じたFeatureVectorとSymptomResolution関数とDirectiveとの間の関係を具体化することによって、外部バグレポート、サービス要求、ヘルプフォーラムリポジトリからサンプルケースをインポートすることができる。ＣＡＲＥ制御は、システムにおけるClassification関数、Assessment関数およびResolution関数を呼び出すことによって、CARELoopをシミュレートするために、外部リポジトリにおける事例から抽出されたＦＳＤおよびFeatureVectorを用いることができる。

例示的シナリオにおけるいくつかのＣＡＲＥ制御サイクルの後、Reificationは、（１）ＧＣログのためのＦＳＤのセットを含む。このＧＣログのためのＦＳＤのセットは、（２）ヒープ傾向についての規則的な時系列データで構成されたＦＳＤに関連し、このＦＳＤは、（３）Classification関数に関連し、このClassification関数は、（４）季節因子、レベルドリフト、レベルシフト、レベルスパイク、分散変動、アウトライアなどの集合体から導き出されるFeatureVectorに関連し、このFeatureVectorは、（５）別のClassification関数に関連し、この別のClassification関数は、（６）メモリリーク状態を表わすFeatureVectorに関連し、このFeatureVectorは、（７）ベイズネットワークによって表わされるAssessment関数に関連し、このAssessment関数は、（８）Hypothesisの一部としてメモリリークコードバグを表わすFeatureVectorに関連し、このFeatureVectorは、（９）Resolution関数に関連し、このResolution関数は、（１０）ヒープダンプを利用するDirectiveに関連し、このDirectiveは、（１１）Actorを含むEnactment関数に関連し、このEnactment関数は、（１２）ターゲットＪＶＭのヒープダンプのためのＦＳＤのセットに関連し、このＦＳＤのセットは、（１３）Classification関数に関連し、このClassification関数は、（１４）ヒープにおけるオブジェクトのヒストグラムから導き出されるFeatureVectorに関連し、このFeatureVectorは、（１５）Actorを含むAssessment関数に関連し、このAssessment関数は、（１６）メモリリークを引起こすコードのサイトを表わすHypothesis FeatureVectorに関連する。季節的傾向把握フィルタ（seasonal trend filter）のバージョンおよびフィルタパラメータも、直接的または間接的に関連付けることができる。これらの関係は、永続的になるかまたは回復可能になって、他の回復可能なトランザクションにとって認識可能となり、バイテンポラルなValidTimeクエリおよびTransactionTimeクエリを用いて後でリコールされたときに、TransactionTimeが刻印された時間となり得る。これらのReification関係に基づき、ユーザは、２つの間隔の間に起こった情報変更などのデータに現われるいずれのイベントについても、その変更の原因が何であったかを判断することができる。関係は、たとえば、特定の間隔中のFactがメモリリークとして分類されたことと、バグフィックスがメモリリークを修復するための指令として発行されたこととを示し得る。一実施形態においては、データの変更がなぜ起こったのかを理解するために、ユーザは、発行されたすべてのDirectiveを示すようにシステムに命令することができる。

開示されたフレームワークは、項目が持続的になるかまたは回復可能になって、他の回復可能なトランザクションにとって認識可能となったときに、各々のInformation項目のValidTimeおよびTransactionTimeを追跡する。ValidTimeおよびTransactionTimeはともに、Directiveおよびそれらの理由が十分に文書化されることを可能にし得る。Directiveごとに、そのDirectiveの基となったInformationは、そのDirectiveに形式的に関連させることができる。結果として、ユーザは、Directiveが発行された瞬間に利用可能となったInformationを、Directiveごとに、遡及的に決定することができる。時間が経過するのに応じて、新しいInformationは、場合によっては事前にDirectiveが発行された結果、利用可能になるかもしれず、さらには、Informationが利用可能になった（たとえば、回復可能になって、他の回復可能なトランザクションにとって認識可能となった）ときに、さまざまなTransactionTimeで、過去におけるValidTimeの時点の状態に遡及的に適用されてもよい。しかしながら、Directiveの発行後に起こるInformationの変更は、Directiveにとって非因果的なものとして明確に分離され、TransactionTimeの変化を用いて詳細に描写されるので、これらの変更は、そのDirectiveに形式的に関連するValidTime属性の時点で遡及的に適用されてもよい。Directiveの選択に影響を及ぼした可能性のある後に取得されるInformationは、そのInformationが利用可能であった場合には、Directiveにとって非因果的なものとして明確に識別することができ、TransactionTimeを用いてビューからフィルタリングすることができるので、ユーザは、場合によっては別のDirectiveを発行させるべきであったInformationによって混乱させられることはない。いかなるときでも、システムは、いずれかの新しいInformationが後のTransactionTimeにおいて修正される前に、以前のTransactionTimeの時点での情報をリコールすることによって、特定のDirectiveがなぜ発行されるのかと、その特定のDirectiveの選択をサポートするためにそのDirectiveのValidTimeにおいて利用可能になった情報とを、ユーザに通知することができる。いくつかの実施形態においては、このバイテンポラルな由来特定性能（provenance capability）を用いることにより、一定の規制要件が満たされる。

バイタルサインのシステム傾向把握および予測
上述のフレームワークは、傾向を決定し、演算システムの「バイタルサイン」についての将来の挙動を予測するための技術において用いることができる。このようなバイタルサインは、たとえば、ＪＡＶＡ仮想マシン（ＪＶＭ：JAVA virtual machine）のメモリヒープ使用量、およびプログラムのスレッドまたはスタックセグメントの強度を含み得る。これらのバイタルサインの傾向を決定することによって、演算システムがクラッシュする可能性があるかどうかを判断することができる。このような傾向に基づき、演算システムがいつクラッシュするかについて予測することができる。このような予測に応じて、システム管理者は、クラッシュを回避することができるように、予測されたクラッシュよりも前にシステムの再始動またはメンテナンスを予定することができる。

傾向を決定するタスクは、情報を生成するために事実の分類として概念化することができる。上述のフレームワークは、このような分類関数を系統的にサポートすることができる。この特定のドメインにおいては、事実は、ＪＶＭがさまざまな時点でどれだけのメモリを使用するのかについての事実、および／または、プログラムコードのさまざまなブロックが実行されるのに用いれられる強度についての事実を含み得る。分類において適用され得る自動化プロセスは、これらの事実を採用し、そして、メモリリークが明らかに存在するという情報、または、プログラムコードの特定のブロックが過度の「ホットスポット」であるという情報などの決定的な情報を生成する。

サービスレベルアグリーメント（ＳＬＡ：service level agreement）に適合させるために性能メトリックを連続的に監視することは、クラウドサービスプロバイダのための重大な運用要件のうちの１つである。これは、差し迫ったＳＬＡ違反を検出してオペレーションにおいて大抵のＳＬＡ違反を回避できるようにするために、かつ、顧客が被る影響を最小限にする目的で、違反が起こったときに問題をより迅速に解決できるようにするために、予測的な診断能力を必要とする。予測的診断解決策の有効な手掛かりは、システムの比較的高レベルの状態空間モデルで表わされており、これは、低レベルのイベントおよび測定から状態を推定および更新するのに適用可能なものであり、重要な性能指標の軌道を有効に予測することができる。システム状態変数は、システム機能のバイタルサインを構成するさまざまなシステム統計の測定値（measurements）を含むはずである。患者の年齢、活動度および環境情況に応じた測定値の正常範囲および異常範囲によって特徴付けられる基本的な身体機能のバイタルサインを表わす心拍数、血圧、体温および呼吸数などのさまざまな生理学的統計の測定値との類似性を得ることができる。

クラウドサービス機能についてのバイタルサインは、規則的な時間間隔で得られる一連のスレッドダンプサンプルからのさまざまなクラスのスレッドおよびスタックセグメントについての強度統計の測定値に基づいて、規定することができる。このバイタルサインについての説明は、ポアソン過程および待合せ理論の数学的フレームワークにおいて策定されるスレッドまたはスタックセグメントの強度統計の分析的モデルによって通知することができる。強度駆動型の分類技術を適用することにより、スレッドおよびスタックセグメントを漸増的に分類することができる。システムの状態モデルは、ホルト・ウィンタース指数移動平均フィルタを用いて、スレッドおよびスレッドセグメントの各クラスの強度についての季節的傾向、線形傾向および一次非線形傾向に関して表わすことができる。状態モデルは、測定アウトライアを検出するためにベースラインを形成するシステムの通常の動作範囲を特徴とする。アウトライアのクラスタは、システム障害と相互に関連する可能性があり、ＳＬＡ違反として顧客によって観察可能となる可能性のあるシステムのハイパーテンション状態またはハイポテンション状態を表わし得る。モデルは、スレッドセグメントの動的な分類と、分類階層をドリルダウンする能力とをサポートして、スレッドセグメントの特定のサブクラスの強度を観察することにより、ＳＬＡ問題の先行指標である軽微な性能グリッチについての観測可能性および感度を向上させる。モデルはまた、季節変動調整型の長期性能傾向予測をサポートする。スレッドまたはスタックセグメントの強度は、システム関数のバイタルサインとして用いることができる。システム関数についてのバイタルサインの観測可能性、感度および予測はすべて、有効な予測的診断能力を可能にする。さらに、モデルは、スレッドのクラス間における依存情報をサポートして、スレッド間の通信とスレッド間におけるプロセス間通信とを把握して、スレッド間の通信チャンネルまたはリソースプールにおける待ち行列のトラフィック強度に対して観測可能性を提供する。

オラクル・パブリック・クラウドにおけるフュージョンアプリケーションの中間層におけるＷｅｂＬｏｇｉｃサーバからのスレッドダンプは、中間層、オペレーティングシステム（ＯＳ：operating system）、ネットワークおよびデータベースにおけるシステム障害と相互に関連するパターンを示すことができる。ＷｅｂＬｏｇｉｃサーバは、デフォルトで１０分とされる規定時間よりも長くスタックしているスレッドを検出するために装備され得る。本発明の実施形態は、スレッド強度についての長期にわたる季節的傾向の状態モデルを用いることができる。この状態モデルは、予想される応答時間よりも長くスタックしているスレッドを検出するための適応性のある方法を提供する。スタックしたスレッドからなる大きなクラスタは、バックエンドサーバおよびデータベースに向かって下流において輻輳が起こったことに起因するシステムのハイパーテンション状態を示す。モデルはまた、システムの上流で輻輳が起こって多くのスレッドがアイドルになることに起因するシステムのハイポテンション状態を検出することができる。高強度のアイドル状態のスレッドは、高強度のスタックしたスレッドを逆にしたものである。

スレッドセグメント分類シグネチャは、クラウドにわたるすべての顧客ポッドから集められたスレッドダンプアーカイブと、スレッドの各クラスの強度を増幅することができるストレステストシステムからのスレッドダンプアーカイブとから、学習することができる。スレッド分類シグネチャは、Ｈａｄｏｏｐ分散型ファイルシステム（ＨＤＦＳ：Hadoop Distributed File System）クラスタに格納された大量のスレッドダンプからＭａｐＲｅｄｕｃｅアルゴリズムによって抽出することができる。これらの分類シグネチャは、製造システムにおける予測診断モニタ上にブートストラップすることができる。

スレッド強度またはスタックセグメント強度
スレッドまたはスタックセグメントの強度は、システム関数における性能ホットスポットの「熱さ（hotness）」の統計基準（statistical measure）を提供する。コードブロックの熱さは、コードブロックの呼出し回数×コードブロックの実行時間によって定量化することができる。ツールは、命令ポインタにおける命令の実行、方法、システムコール、同期の待機、ハードウェアカウンタオーバフローなどの、低レベルイベントの呼出しカウントおよび応答時間を測定することができる。イベントの正確な測定値を集めるためにアプリケーションプログラムを装備することができるが、このようなアプローチにおいては、この装備が測定に影響を及ぼす可能性がある。この問題は、方法についての測定コード（instrumentation code）の実行時間が方法自体の実行時間を特徴付けている場合には、呼出しカウントが増えるのに応じて、より顕著になり得る。イベントの統計的サンプリングによる熱さ基準の推定は、この点で、正確な測定よりも有効である。オラクル（Oracle）、インテル（Intel）およびＡＭＤを含むＣＰＵベンダーによって提供される性能分析ツールは、イベントをサンプリングするためにＣＰＵに提供されるハードウェアカウンタを利用する。これらのツールは、イベントについての時間ベースまたはイベントベースの統計的サンプリングを提供する。時間ベースのサンプリングにおいては、ツールは、各々のタイマ割込イベントごとに、タイムスタンプ、命令ポインタ、カーネルミクロ状態、スレッドｉｄ、プロセスｉｄ、ＣＰＵコアｉｄ、およびコールスタックなどのイベント属性を記録する。イベントベースのサンプリングにおいては、ツールは、ハードウェアカウンタオーバフローイベントにおいて、イベント属性の類似集合を記録する。オラクル、インテルおよびＡＭＤのＣＰＵは、Ｌ１／Ｌ２キャッシュミス、分岐の誤予測、浮動小数点演算などをサンプリングするためにハードウェアカウンタのセットを提供する。プログラムにおける命令ポインタのサンプルカウントについてのヒストグラムは、典型的には、プログラムにおけるホットスポットの定性的プロファイルを伝える。ＧＮＵｇｐｒｏｆは、サブルーチンの実行時間をサンプリングするが、呼出し回数を測定するためにコード測定（code instrumentation）を用いる。サンプリング誤差は、通常、２つ以上のサンプリング周期である。サブルーチンの予想される実行時間がｎサンプリング周期である場合、実行時間推定値の予想誤差はｎサンプリング周期の二乗根である。

プログラムのうちさまざまな部分のホットスポットプロファイルは、コールグラフ、コールツリーおよびコールスタックの観点で示すことができる。各々の観点では、呼出し回数統計を基本的な実行時間統計と組み合わせることにより、ロールアップおよびドリルダウンの観点から、発呼者および呼出し方法に起因して実行時間を設定することができる。プログラムにおける命令ポインタのサンプルカウントについてのヒストグラムは、典型的には、プログラムにおけるホットスポットの定性的プロファイルを表わす。

スレッドまたはスタックセグメントの強度統計の分析モデルから分かるように、サイトについての時間ベースおよびイベントベースのサンプリングは、命令ポインタであれ、スタックトレースであれ、計測技術によって測定されるような実行回数の正確なカウントの近似値として解釈されるべきではないカウンタを提供する。統計的サンプリングによって得られるカウンタ値は、サイトの実行頻度およびサイトの実行の応答時間の両方を考慮に入れている。サイトの実行回数の正確なカウントは、実行時間を考慮に入れていない。所与の命令ポインタサイトにおける命令の実行時間は、命令が必要とするＣＰＵクロックサイクルの数に左右される。統計的サンプリング技術が原因としてもたらす余分な要因は、正確な実行カウントと命令ポインタサイトの統計的サンプリングとの間における、正規化された自乗平均値平方根の誤差、サンプルカバレッジおよびオーダー偏差メトリクスについての、観察された誤差の有意な要因となる。サイトの統計的サンプリングは、分析モデルにおける強度基準として処理することができる。

これらの分析技術を拡張すると、本発明の実施形態は、コールスタックの自動分類のために、かつ、システムバイタルサインの季節的傾向、線形傾向および一次非線形傾向を整列させる状態空間表現ベースのために、強度統計を用いることができる。本発明の実施形態は、スレッド間通信とプロセス間通信とのスレッドのクラス間における依存性を把握するために、単一クラスのスレッドのコールスタックモデルを拡張させることができる。このモデルは、遠隔メソッド呼出し（ＲＭＩ：remote method invocation）、ウェブサービス、ＪＡＶＡデータベースコネクティビティ（ＪＤＢＣ：JAVA Database Connectivity）接続、ＪＡＶＡ命名およびディレクトリインターフェイス（ＪＮＤＩ：JAVA Naming and Directory Interface）接続などを介して、クライアント・サーバ呼出しに関与する一連のコールスタックを表わし得る。これはまた、クリティカルな区域に入るために、または（ＪＤＢＣ接続プールなどの）リソースプールからリソースを得るために、２つ以上のコールスタックスレッド同士のインタラクションを表わし得る。２つの相互作用するコールスタックの強度統計間に差異がある場合、これは、それらの間の通信チャネルまたはリソースプールに輻輳があることを明らかにし得る。さらに、コールスタック依存モデルは、オペレータが複数のサーバから入ってくるレポートを相互に関連させることを可能にする。可診断性フレームワークによって呼出しチェーンに沿って伝搬される実行コンテキストＩＤ（ＥＣＩＤ：Execution Context ID）を用いて、ミドルウェアおよびデータベースの層にわたって例外トレースを相互に関連付けることにより、個々の実行コンテキストにおける問題の根本原因分析を支援することができる。スレッドまたはスタックセグメントの強度統計などのシステムバイタルサインを用いて体系的な問題を診断するために、スレッドまたはスタックセグメントのクラス間の依存情報を用いて、ミドルウェア層およびデータベース層にわたってインシデンスを相互に関連させることにより、根本原因分析を支援することができる。

データベース層スレッドをドリルダウンするために、システムは、データベースサーバＯＳ処理の低レベルスレッドダンプに加え、ＳＱＬ自動作業負荷責任（ＡＷＲ：Automatic Workload Responsibility）レポートなどの高レベルの構造化参照言語（ＳＱＬ：Structured Query Language）ステートメント実行状態レポートについての統計を集めることができる。データベース動作のためにＪＤＢＣ接続を介してブロックしている各々のスレッドクラスは、データベースサーバにおけるＳＱＬステートメント実行プランと相互に関連付けることができる。２つのＳＱＬ ＡＷＲスナップショット間の間隔におけるＳＱＬステートメント実行プランの実行カウントおよび実行時間などの統計は、定期的にサンプリングすることができる。ＳＱＬステートメント実行プランの実行強度は、実行カウントと平均実行時間との積として導き出すことができる。一実施形態では、問題を診断するために、中間層における高強度データベース動作スレッドから、データベース層における高強度ＳＱＬステートメントにまでドリルダウンすることができる。たとえば、準最適な実行プランは、不適切なデータベーススキーマ設計にまでドリルダウンすることができるか、または述語評価のための適切なインデックスが無くなるまでドリルダウンすることができる。こうして、スレッド依存情報モデルにより、モニタが、中間層スレッドとデータベース層スレッドとの強度を相互に関連付けて、完全なエンド・ツー・エンド画像を提供することを可能にする。

ミドルウェアおよびデータベースサービスの分類
フュージョンアプリケーション（ＦＡ：Fusion Application）は、財務管理、顧客関係管理（ＣＲＭ：Customer Relationship Management）、人的資本管理（ＨＣＭ：Human Capital Management）、サプライチェーン管理（ＳＣＭ：Supply Chain Management）、プロジェクトポートフォリオ管理（ＰＰＭ：Project Portfolio Management）、プロキュアメント、および管理リスクコンプライアンスを含む。フュージョンアプリケーションは、フュージョンアプリケーションのサブセットを表わす論理ピラーに編成される。たとえば、テナントシステムは、３つのピラーで構成することができる。３つのピラーとは、すなわち、金融サービス、ＳＣＭサービス、ＰＰＭサービスおよびプロキュアメントサービスを含む第１のピラーと、ＨＣＭサービスを含む第２のピラーと、ＣＲＭサービスを含む第３のピラーとを含む。ピラー構造は、大規模システムのグラニュラー・メンテナンス、パッチおよびアップグレードを可能にする。ピラーは、同じＦＡデータベースを共有し得るが、アプリケーションおよびデータスキーマのグラニュラー・メンテナンス、パッチおよびアップグレードを可能にし得る。各々のピラーは、データベース間にテーブルレプリケーションを有する別個のデータベースを有するはずである。オラクルデータインテグレータ（ＯＤＩ：Oracle Data Integrator）は、さまざまなバージョンのテーブルを用いている場合、２つ以上のピラーのためにデータベース間でデータ変換を実行することができる。オラクル・パブリック・クラウド（ＯＰＣ：Oracle Public Cloud）におけるＦＡテナントポッドは、ピラーを含むＦＡサービスのファミリーのセットによって分類される。たとえば、上述の例における３つのＦＡポッドは、それぞれ、（金融、ＳＣＭ、ＰＰＭおよびプロキュアメントピラー）クラス、（ＨＣＭピラー）クラス、および（ＣＲＭピラー）クラスによって分類されるだろう。

オラクルフュージョンアプリケーションアーキテクチャは、（オラクルバーチャルアセンブリビルダによって作成されるアセンブリを編集することによって）いくつかの実現可能なオラクル仮想マシン（ＯＶＭ：Oracle Virtual Machine）トポロジーにマッピングすることができるかまたは複数のポストにわたって分散される物理トポロジにマッピングすることができるサーバおよびドメインの論理トポロジへとアプリケーションを編成することによって、アプリケーションサービスの高利用可能性およびロードバランシングをサポートするフュージョンミドルウェアアーキテクチャの上において規定される。サーバは、アプリケーションサービスを実行するＷｅｂＬｏｇｉｃサーバのインスタンスである。ドメインは、ＷｅｂＬｏｇｉｃサーバの１つ以上のインスタンスを含むＷｅｂＬｏｇｉｃサーバドメインである。財務管理のための｛総勘定元帳、受取勘定、支払勘定｝などのＦＡサービスのファミリーは、金融ドメインにおけるサーバのセットに編成することができる。ＦＡサービスは、たとえば、（金融ドメイン、管理サーバ）（金融ドメイン、総勘定元帳サーバ）、（金融ドメイン、受取勘定サーバ）、（金融ドメイン、支払勘定サーバ）、（ＣＲＭドメイン、管理サーバ）、（ＣＲＭドメイン、顧客サーバ）、（ＣＲＭドメイン、セールスサーバ）、（ＣＲＭドメイン、オーダキャプチャサーバ）などの、ドメイン×サーバのディメンションに沿って分類される。ＦＡサービスの各クラスは、ロードバランシングおよび高利用可能性を得るためにクラスタにおいてデプロイすることができる。

ドメインおよびサーバクラスタ構造は、ポッドにおける適切なＯＶＭトポロジにマッピングすることができる。たとえば、（ＣＲＭドメイン、管理サーバ）、（ＳＣＭドメイン、管理サーバ）、（ＨＣＭドメイン、管理サーバ）、（金融ドメイン、管理サーバ）などを含むフュージョンアプリケーションポッドにおけるすべてのドメインにわたる管理サービスは、同じ管理ＯＶＭにマッピングすることができる。ＣＲＭテナントの場合、２クラスのサービス（ＣＲＭドメイン、顧客サーバ）および（ＣＲＭドメイン、セールスサーバ）は、他のサービスよりも多くのＣＰＵリソースおよびメモリリソースを要求するものであって、クラスタにおいて１対の一次ＯＶＭにマッピングすることができ、（ＣＲＭドメイン、…）クラス、（ＳＣＭドメイン、…）クラス、（ＨＣＭドメイン、…）クラス、（金融ドメイン、…）クラス、（プロキュアメントドメイン、…）クラス、および（プロジェクトドメイン、…）クラス間におけるサポートサービスは、別の対の二次ＯＶＭにおけるクラスタに統合することができる。ＯＤＩ（Oracle Data Integrator：オラクルデータインテグレータ）サーバ、ＳＯＡ（フュージョンミドルウェアＳＯＡ）サーバおよびＥＳＳ（Enterprise Scheduler Service：エンタープライズ・スケジューラ・サービス）サーバなどのいくつかのフュージョンミドルウェアサービスは、作業負荷を分割するために各々のドメインにおいて再現することができる。

フュージョンアプリケーションポッドは、ＲＡＣデータベースサーバのいくつかの異なるトポロジにマッピングすることができる３つの論理データベースサービス、すなわち、（オラクルアクセスマネージャのための）ＯＡＭ ＤＢ、（オラクルアイデンティティ管理および承認ポリシーマネージャのための）ＯＩＭ−ＡＰＭ ＤＢおよび（アプリケーションスキーマのための）フュージョンＤＢ、を含む。ＯＡＭリポジトリは、認証、シングルサインオン（ＳＳＯ：Single-Sign-On）およびアイデンティティ表明のためのポリシーを含む。ＯＩＭリポジトリは、ユーザプロファイルを含み、メンバーシップをグループ化する。ＡＰＭリポジトリは、ＲＢＡＣ承認ポリシーを含む。フュージョンＤＢは、ＦＡ、ＭＤＳ、ＳＯＡ、ＢＩ、ＵＣＭおよびＷｅｂＣｅｎｔｅｒのためのさまざまなリポジトリを含む。オラクルアクセスマネージャ（ＯＡＭ：Oracle Access Manager）および承認ポリシーマネージャ（ＡＰＭ：Authorization Policy Manager）は、ＷｅｂＬｏｇｉｃセキュリティサービスプロバイダインターフェイスを用いて、Ｊａｖａ承認および認証サービス（ＪＡＡＳ：Java Authorization and Authentication Services）ならびにコンテナ用認証契約（ＪＡＣＣ：Authorization Contract for Containers）のためのサービスを提供する。ＷｅｂＬｏｇｉｃサーバにおけるＯＡＭ ＷｅｂＧａｔｅコンポーネント、ＡｃｃｅｓｓＧａｔｅコンポーネントおよびウェブサービス・マネージャ（ＯＷＳＭ：Web Services Manager）コンポーネントは、ＯＡＭリポジトリにおける認証ポリシーにアクセスする。ＷｅｂＬｏｇｉｃサーバにおけるオラクル・プラットフォーム・セキュリティ・サービス（ＯＰＳＳ：Oracle Platform Security Services）フレームワークは、ＯＩＭリポジトリにおけるユーザのグループメンバーシップ情報にアクセスし、この情報を用いて、ＡＰＭリポジトリにおけるＲＢＡＣ承認ポリシーにアクセスする。

ＦＡサーバにおけるデータアクセスオペレーションは、それらが依存するデータベースサービス（データベース，ＯＡＭ ＤＢ）、（データベース，ＯＩＭ−ＡＰＭ ＤＢ）および（データベース，フュージョンＤＢ）によって識別することができる。以下のデータベース依存情報はモデルに組込むことができる：
ＦＡサーバにおけるＯＡＭ接続はアクセスサーバおよびＯＡＭ ＤＢに依存し、
ＦＡサーバにおけるＪＮＤＩ接続はオラクルインターネットディレクトリサーバおよびＯＩＭ−ＡＰＭ ＤＢに依存し、
ＦＡサーバにおけるＯＰＳＳフレームワークからのＪＤＢＣ接続はＯＩＭ−ＡＰＭ ＤＢに依存し、
ＦＡサーバにおけるＡＤＦビジネス・コンポーネント（ＡＤＦ−ＢＣ）およびメタデータ・サービス（ＭＤＳ）からのＪＤＢＣ接続はフュージョンＤＢに依存し、
ＳＯＡサーバおよびＢＩサーバにおけるＢＰＭ、ＷｅｂＣｅｎｔｅｒ、ＵＣＭおよびＢＩからのＪＤＢＣ接続は、フュージョンＤＢに依存する。

ＳＱＬステートメントの分類
クラウド顧客の（テナントの）ＦＡサービスは、サーバについての複数のピラー／ポッド、ドメインおよびクラスタにわたって分散させることができる。分散型サーバは、データベース接続をＪＤＢＣ接続プールへと有効に分割する。サービス品質（ＱｏＳ：quality of service）要件に応じて、システムは、さまざまな数のＪＤＢＣ接続を各々のプールに割当てることができる。たとえば、セールスサーバ、オーダキャプチャサーバ、マーケティングサーバ、分析的なサーバなどにおける接続プールは、ＱｏＳを制御するためにさまざまな数のＪＤＢＣ接続に割当てることができる。接続プールのサイジングは、ＪＤＢＣ接続プールにおける接続を待ってデータベース動作を実行する中間層データベース動作スレッドクラスと、アクティブなＳＱＬステートメントクラスとを合致させるインピーダンスおよび季節的強度傾向によって誘導することができる。中間層接続プールによるデータベース接続の分割は、ＳＱＬステートメントの分類を支援し、問題を切離すことを可能にする。これにより、低優先アプリケーションでの調整不十分なＳＱＬステートメントが、高強度の中間層スレッドのための高性能ＳＱＬステートメントをブロックしてしまうことを防止することができる。

スタックトレースによるスレッドおよびスレッド依存関係の分類
スタックしたスレッドのためのスタックトレースは、スレッドをブロックする動作を明らかにし得る。たとえば、以下のスタックトレースの冒頭付近におけるスタックフレーム「oracle jdbc driver OracleStatement doExecuteWithTimeout」により、干渉を引起すことができる。この場合、スレッドがデータベース動作のためにブロックされている。

oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:991)
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1285)
…
oracle.mds.core.MetadataObject.getBaseMO(MetadataObject.java:1048)
oracle.mds.core.MDSSession.getBaseMO(MDSSession.java:2769)
oracle.mds.core.MDSSession.getMetadataObject(MDSSession.java:1188)
…
oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:150)
…
oracle.apps.setup.taskListManager.ui.customization.CustomizationFilter.doFilter(CustomizationFilter.java:46)
…
weblogic.servlet.internal.WebAppservletContext.securedExecute(WebAppservletContext.java:2209)
weblogic.servlet.internal.servletRequestImpl.run(servlet RequestImpl.java:1457)
…
weblogic.work.ExecuteThread.execute(ExecuteThread.java:250)
weblogic.work.ExecuteThread.run(ExecuteThread.java:213)
上述のスタックトレースにおいては、ＪＤＢＣドライバスタックよりも下のスタックフレーム「oracle mds core MetadataObject getBaseMO」は、ＭＤＳライブラリがＪＤＢＣ動作を発生させることを示す。ＭＤＳライブラリスタックよりも下のスタックフレーム「oracle adf model servlet ADFBindingFilter doFilter」は、ＭＤＳが、ハイパーテキスト転送プロトコル（ＨＴＴＰ：Hypertext Transfer Protocol）サーブレット要求によって呼び出されるＡＤＦアプリケーションによって呼び出されることを示す。このスレッドがＣＲＭドメインにおける顧客サーバＷｅｂｌｏｇｉｃインスタンスにおいて観察されるので、スタックしたスレッドは、（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ，ＤＡＴＡＢＡＳＥオペレーション）として分類することができる。このスレッドは、（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）によって分類されたデータベースサーバスレッドに依存する。

以下は、別のスタックしたスレッドについてのスタックトレースである。
com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2640)
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:48)
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:637)
javax.naming.InitialContext.init(InitialContext.java:219)
…
atoracle.adf.controller.internal.security.AuthorizationEnforcer.checkPermission
(AuthorizationEnforcer.java:114)
…
oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:150)
…
oracle.apps.setup.taskListManager.ui.customization.CustomizationFilter.doF ilter(CustomizationFilter.java:46)
…
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2209)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1457)
…
weblogic.work.ExecuteThread.execute(ExecuteThread.java:250)
weblogic.work.ExecuteThread.run(ExecuteThread.java:213)
このスタックしたスレッドは、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：Lightweight Directory Access Protocol）接続によってブロックされる。ＪＮＤＩスタックよりも下のスタックフレーム「oracle adfinternal controller state ControllerState checkPermission」は、ＡＤＦコントローラが、場合によっては承認チェックのためにＬＤＡＰサーバから許可オブジェクトをロードするためにＬＤＡＰ接続を用いていることを示す。第２のスレッドは、第１のスレッドとして、スタックフレーム「oracle adf model servlet ADFBindingFilter doFilter」よりも下にある同じスタックトレースを有する。したがって、これは、第１のスレッドと共通の分類（ＨＴＴＰサーブレット，ＡＤＦアプリケーション）を共有する。第２のスレッドはまた、ＣＲＭドメインにおける顧客サーバＷｅｂｌｏｇｉｃインスタンスにおいて観察される場合、（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション，ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＬＤＡＰオペレーション）として分類されることとなる。第２のスレッドは、（ＤＡＴＡＢＡＳＥ，ＯＩＭ−ＡＰＭ ＤＢ）によって分類されるデータベースサーバスレッドに依存する（ＯＩＤ）によって分類されるＯＩＤスレッドに依存する。

スレッド分類情報モデルは、１クラスのスレッドの互いに対する依存性を取り込む。たとえば、以下の依存性は、サブクラスの依存性を一般化するためにスーパークラスのスレッドに関して規定される：
（ＡＤＦ ウェブサービス呼出し）→（ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）
（ＡＤＦ−ＢＣ， ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）
（ＡＤＦ−ＭＤＳ， ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）
（ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ（ＯＩＭ−ＡＰＭ ＤＢ）
（ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＬＤＡＰオペレーション）→（ＯＩＤ）→（ＤＡＴＡＢＡＳＥ（ＯＩＭ−ＡＰＭ ＤＢ）
（ＳＯＡ−ＢＰＥＬ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）
（ＥＳＳ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）
依存関係（ＡＤＦウェブサービス呼出し）→（ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）は一般化されたものであって、ＡＤＦサービス間における多くのサブクラスの依存関係を含む。この依存関係のサブクラスのうち１つは、（ＣＲＭドメイン，セールスサーバ，ＡＤＦアプリケーション，ＡＤＦウェブサービス呼出し）→（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）である。この関係のうちクライアント側およびサーバ側の両方におけるスレッドセグメントはドリルダウンすることができる。たとえば、依存関係のクライアント側（ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）は、高強度関係（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）にまでドリルダウンすることができる。サーバ側と同様に、データベースにおける（ＳＱＬ実行プランおよび実行トレースを含む）コールグラフ、コールツリーまたはコールスタックモデルは、高強度サブクラスの（ＤＡＴＡＢＡＳＥ、フュージョンＤＢ）スレッドにまでドリルダウンすることができる。

サブサンプション階層
分類スキームのサブサンプション階層はタプル予測によって導き出される。たとえば、タプル（顧客サーバ，ＡＤＦアプリケーション）がタプル（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）の予測であるとすれば、分類（ＣＲＭドメイン、顧客サーバ、ＨＴＴＰサーブレット、ＡＤＦアプリケーション）は、分類（顧客サーバ，ＡＤＦアプリケーション）の下に組込まれる。分類（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ，ＤＡＴＡＢＡＳＥオペレーション）および（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション，ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＬＤＡＰオペレーション）が、分類（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）の下に組込まれるので、上にあるサンプルスレッドがともに、（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）のいずれかの予測の下に組込まれる。したがって、２つのサンプルスレッドの統計が集められて、（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）およびそのスーパークラスの統計にされる。

ＡＤＦアプリケーションは、ＨＴＴＰサーブレットに加えて、Ｏｕｔｌｏｏｋコネクタおよびウェブサービスによって呼び出すことができる。追加の分類は（チャネル×アプリケーション）ディメンションで規定することができる：
（ＨＴＴＰサーブレット，ＡＤＦアプリケーション）
（Ｏｕｔｌｏｏｋコネクタ，ＡＤＦアプリケーション）
（ウェブサービス，ＡＤＦアプリケーション）
ＡＤＦアプリケーションは、さまざまなドメインにおけるさまざまなサーバにおいてデプロイされる。クロス積（ドメイン×サーバ×チャネル×アプリケーション）を採用することにより、それらを分類することができる。たとえば、分類（ＣＲＭドメイン，顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）、（ＣＲＭドメイン，顧客サーバ，Ｏｕｔｌｏｏｋコネクタ，ＡＤＦアプリケーション）および（ＣＲＭドメイン，顧客サーバ，ウェブサービス，ＡＤＦアプリケーション）は、最も共通性の低いスーパークラス（ＣＲＭドメイン，顧客サーバ，ＡＤＦアプリケーション）を有する。

オペレーションディメンションは、数例を挙げると、分類データベース・オペレーション、ＬＤＡＰオペレーション、ウェブサービス呼出しを含む。データアクセスライブラリは、数例を挙げると、分類ＡＤＦ−ＭＤＳ、ＡＤＦ−ＳＥＣＵＲＩＴＹ、ＡＤＦ−ＢＣ、ＡＱ−ＪＭＳを含む別のディメンションである。クラス階層は、クロス積（ドメイン×サーバ×チャネル×アプリケーション×ライブラリ×オペレーション）を採用することにより、ドリルダウンすることができる。

タプルは、ＬＩＳＰ表現において、reverse(cdr(reverse(tuple))))から(tuple)へと状態が有効に変化しているスレッドの状態として処理することができる。この場合、car(reverse(tuple))は、スタックトレースの上にスタックフレームを与える。たとえば、状態（ＨＴＴＰサーブレット，ＡＤＦアプリケーション）におけるスレッドは、ＡＤＦアプリケーションがＡＤＦ−ＢＣを呼び出すと、状態（ＨＴＴＰサーブレット，ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）に移行することができる。

この明細書中に開示される強度駆動型の分類技術は、時間が経過するのに応じて各々のスタックフレームの強度を追跡し、スタックフレームの強度によって引起こされるスタックフレーム間の同等関係によってスタックトレースにおけるスタックセグメントの境界を定める。これにより、同じ強度を有する同じスタックセグメントにおいて発生するスタックフレームに同じ分類が与えられる。この分類技術により、セグメントにおける個々のスタックフレームの強度が時間に経つにつれて分岐するのに応じて、スタックセグメントが、絶えず、より小さなスタックセグメントに分割される。スタックセグメントが構成セグメントに分割されるたびに、この技術によって、構成セグメントごとに新しい分類が作成される。たとえば、当該技術は、（ＡＤＦ−ＢＣ）セグメントの強度が（ＡＤＦアプリケーション）セグメントの強度から分岐したときに、（ＡＤＦアプリケーション）および（ＡＤＦ−ＢＣ）に分割され得るスタックセグメントのための分類（ＡＤＦアプリケーション・ビジネス・コンポーネント）から始まってもよい。分類（ＡＤＦアプリケーション・ビジネス・コンポーネント）は、新しい分類（ＡＤＦアプリケーション）および（ＡＤＦ−ＢＣ）の下に組込まれる（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）のエイリアスである。

当該技術により、スタックセグメントを分類するために新しい分類が作成されるたびにグローバル一意識別子（ＧＵＩＤ：globally unique identifier）が生成される。スタックセグメントが構成セグメントに分割され、それら構成セグメントの各々に新しい分類が割当てられると、アルゴリズムは、一体化セグメントの分類の識別子から新しい分類の識別子を導き出し得る。たとえば、一体化セグメントの識別子は５４６３７２８１９であってもよい。このセグメントが２つの構成要素セグメントに分割される場合、当該技術により、識別子５４６３７２８１９−１および５４６３７２８１９−２を構成セグメントに割当てることができる。セグメント５４６３７２８１９−１が２つの構成要素セグメントに再び分割される場合、当該技術では、識別子５４６３７２８１９−１−１および５４６３７２８１９−１−２を構成セグメントに割当てることができる。

暗黙知を適用することにより、（ＡＤＦ−ＢＣ）、（ＡＤＦ−ＭＤＳ）または（ＡＤＦ−ＶＩＥＷ）などの有意な名前を分類に割当てることができる。暗黙知はまた、分類を編成するために、チャネル、アプリケーションまたはオペレーションなどのディメンションを割当てることができる。分類およびディメンションの知識ベースを規定することにより、自動分類技術をブートストラップすることができる。後に構成セグメントに分割されるスタックセグメントの分類のために、知識ベースが名前、たとえば（ＡＤＦ−ＶＩＥＷ）、を指定する場合、当該技術により、一体化セグメントの名前（ＡＤＦ−ＶＩＥＷ）から構成セグメントのための分類名、たとえば（ＡＤＦ−ＶＩＥＷ−１）、（ＡＤＦ−ＶＩＥＷ−２）、（ＡＤＦ−ＶＩＥＷ−１−１）など、を導き出すことができる。

暗黙知は、根本的原因の分析を支援するために、問題のあるサービスおよびサーバにわたって発生率を相互に関連付けるのに用いられるスレッド依存関係の知識ベースを作成および維持するのを支援することができる。［（ＡＤＦ ウェブサービス呼出し，ＨＴＴＰクライアント）→（ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）］および［（ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）→（データベース，フュージョンＤＢ）］などのスレッド依存関係が、暗黙知によって割当てられるスタックセグメント名の観点から規定される。

スレッドまたはスタックセグメントの強度統計のロールアップおよびドリルダウン
この分類スキームは、ロールアップおよびドリルダウン統計分析のために多くのディメンションを供給する。興味ある１統計として、スレッドまたはスタックセグメントのクラスの強度が挙げられる。到着に関するポアソン分布の場合、予想される強度ρ（予想される応答時間τに対応する、時間間隔中に予想される到着数）は、リトルの公式によって、予想される応答時間τおよび到着率λに関連付けられる。

ρ＝λ・τ
スレッドまたはスタックセグメントのクラスの平均強度は、規則的に、たとえば１分ごとに、得られる一連のスレッドダンプサンプルから測定することができる。一定の到着率λを想定すると、スレッドまたはスタックセグメントρの平均強度は、スレッドまたはスタックセグメントの平均応答時間τに比例する。到着率は、季節指数については、短い時間間隔、たとえば１５分の時間間隔、では変化しないように想定され得る。ホルト・ウィンタース予測および季節的傾向把握フィルタは、多くの季節サイクルにわたって季節指数ごとに季節因子を追跡することができる。季節指数に合わせて季節因子によって調整されるサンプルの強度は、平均強度を越えて急上昇する場合、スレッドが平均応答時間よりも長くスタックしていることを示す。アウトライアフィルタはこれを異常として検出することができる。

各々のスレッドダンプにおける（あるオペレーションを呼び出す）スレッドまたはスタックセグメントのクラスの強度は、サンプル時間窓の予想長さの範囲内におけるオペレーションの到着の数の基準であり得る。強度は、サンプル時間窓の予想長さの間接的測定値をもたらす。

スレッドまたはスタックセグメントの強度統計は、システムが、高い到着率と長い応答時間との組合せを有するスレッドまたはスタックセグメントについてのスタックトレースを確認する傾向があるだろうことを示唆する。１よりも小さい（０．０５などの小数値の）強度を有するスレッドまたはスタックセグメントは、十分な数のスレッドダンプにわたって対応するスタックトレースの発生をカウントすることによって検出することができる。たとえば、到着率が毎秒０．５であり予想される応答時間が０．１秒であるスレッドまたはスタックセグメントのクラスは、予想されるスレッドまたはスタックセグメントの強度がスレッドダンプごとに０．０５となるだろう。スレッドダンプごとに０．０５の強度とは、このクラスのスレッドまたはスタックセグメントについてのスタックトレースの発生を、２０のスレッドダンプにおいて平均して１回、検出できるはずであることを意味する。各々のスレッドダンプが予想長さτ＝０．１秒のサンプル時間窓を表わす場合、２０個のスレッドダンプでは、合計すると、予想長さ２０・τ＝２秒となる。これにより、このクラススレッドまたはスタックセグメントについての２秒窓での予想される発生回数が、２０・γ・τ＝１によって与えられる。

ポアソン過程の場合、サンプル時間窓が部分的に重なっていない限り、上述の推論は有効である。サンプル時間窓が部分的に重ならないことを確実にするために、サンプリング間隔は、所与のスレッドのクラスの予想応答時間τよりも著しく大きくなるはずである。この明細書中に開示されるアンチエイリアシング法は、システムが現在のサンプル時間窓内に到達するスレッドだけをカウントすることを確実にするために、先行のサンプル時間窓において既にカウントされているスタックしたスレッドを検出するものである。これにより、サンプル時間窓が部分的に重なっていない状態で維持される。スレッドがスタックしていない場合、依然として、残存するスレッド（lingering thread）が、連続的なスレッドダンプにおいてさまざまなサブクラスとして現われることが可能となる。たとえば、ＡＤＦアプリケーションスレッドは、あるスレッドダンプにおいては（ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ）として、別のスレッドダンプにおいては（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）として複数回カウントされる可能性もある。本発明の実施形態は、サンプル時間窓を確実に独立させるために、残存するスレッドを二回以上カウントすることを回避する。残存するスレッドは、スレッドの実行コンテキストを設定するサーブレットフィルタなどのルートクラス中のアプリケーションがスレッド名にエポックカウンタを追加する場合に、アンチエイリアシングについて検出することができる。エポックカウンタは、スレッドの実行コンテキストのＥＣＩＤに相互に関連付けることができる。

スレッドまたはスタックセグメントの強度統計のネスト化
ネスト化されたサブクラスは、ステートマシンでの状態として表わすことができる。たとえば、例示的なクラス（ＡＤＦアプリケーション）は、例示的なサブクラス（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ，データベース・オペレーション）を含み得る例示的なサブクラス（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）を含み得る。これらのネスト化された３つのサブクラスの各々はステートマシンの状態として表わすことができる。

サブクラスの各々におけるスレッドは、さまざまな強度を有することができる。以下に説明する目的で、ρ（ＡＤＦ）は、（ＡＤＦアプリケーション）スレッドの強度を表わし、ρ（ＡＤＦ−ＢＣ）は、（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）スレッドの強度を表わし、ρ（ＡＤＦ−ＢＣ−ＪＤＢＣ）は、（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ，データベース・オペレーション）スレッドの強度を表わす。（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ，データベース・オペレーション）スレッドの強度は、（ＡＤＦアプリケーション）スレッドの強度に含まれる（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）スレッドの強度に含まれる。

（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ，データベース・オペレーション）スレッドの強度は、間隔τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）内におけるデータベース・オペレーションの到着数を表わす。これらのデータベース・オペレーションの到着は、それらの出発前に得られたスレッドダンプにおけるＪＤＢＣスタックフレームとして観察することができる。データベース・オペレーションの到着および出発は、ステートマシンにおける「データベース・オペレーションを開始」および「データベース・オペレーションを終了」するための状態遷移として表わすことができる。強度、すなわち予想される到着数は、「データベース・オペレーションを開始」する状態と「データベース・オペレーションを終了する」状態との間で、到着点の密度および予想される時間間隔長さに依存する。到着点λの密度および／またはデータベース・オペレーションの予想される応答時間τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）が急上昇する場合、データベース・オペレーションの強度は急上昇するだろう。到着点λの密度が季節指数の範囲内で一定であると想定した場合、強度の急上昇は、データベース・オペレーションが予想されるよりも長くスタックしたままとなることが原因であると考えることができる。スレッドのうち３つのネスト化されたクラスの強度は以下の鎖に沿ってロールアップすることができる：

スレッドまたはスタックセグメントの強度統計の分割
ＡＤＦ−ＢＣライブラリを呼び出すスレッドの一部は、ＪＤＢＣを用いてデータアクセスを実行することを必要とする可能性がある一方で、スレッドの残りはキャッシュにおけるデータにアクセスしてもよい。このシナリオについての状態遷移図は、ポアソン過程を２つのポアソンのサブプロセスに分割することによって表わすことができる。λ（ＡＤＦ−ＢＣ）がＡＤＦ−ＢＣスレッドの到着密度を表わし、λ（ＡＤＦ−ＢＣ−ＪＤＢＣ）がＡＤＦ−ＢＣ−ＪＤＢＣスレッドの密度を表わし、λ（ＡＤＦ−ＢＣ−キャッシュ）がＪＤＢＣオペレーションをスキップするＡＤＦ−ＢＣスレッドの密度を表わす場合、２つのポアソン過程ＡＤＦ−ＢＣ−ＪＤＢＣおよびＡＤＦ−ＢＣ−キャッシュの合計は、
λ（ＡＤＦ−ＢＣ）＝λ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋λ（ＡＤＦ−ＢＣ−キャッシュ）
ρ（ＡＤＦ−ＢＣ）＝ρ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋ρ（ＡＤＦ−ＢＣ−キャッシュ）
によって与えられる密度および強度を有するポアソン過程ＡＤＦ−ＢＣとなる。

仮に、ｐがＪＤＢＣオペレーションを呼び出すλ（ＡＤＦ−ＢＣ）の百分率を表わす場合、以下のとおりである。

λ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＝ｐ・λ（ＡＤＦ−ＢＣ）
λ（ＡＤＦ−ＢＣ−キャッシュ）＝（１−ｐ）・λ（ＡＤＦ−ＢＣ）
対応する予想応答時間がτ（ＡＤＦ−ＢＣ）、τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）およびτ（ＡＤＦ−ＢＣ−キャッシュ）によって表わされる場合、以下のとおりである。

ρ（ＡＤＦ−ＢＣ）＝ρ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋ρ（ＡＤＦ−ＢＣ−キャッシュ）
ρ（ＡＤＦ−ＢＣ）＝λ（ＡＤＦ−ＢＣ−ＪＤＢＣ）・τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋λ（ＡＤＦ−ＢＣ−キャッシュ）・τ（ＡＤＦ−ＢＣ−キャッシュ）
λ（ＡＤＦ−ＢＣ）・τ（ＡＤＦ−ＢＣ）＝ｐ・λ（ＡＤＦ−ＢＣ）・τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋（１−ｐ）・λ（ＡＤＦ−ＢＣ）・τ（ＡＤＦ−ＢＣ−キャッシュ）
τ（ＡＤＦ−ＢＣ）＝ｐ・τ（ＡＤＦ−ＢＣ−ＪＤＢＣ）＋（１−ｐ）τ（ＡＤＦ−ＢＣ−キャッシュ）
スレッドのネスト化されたクラスの強度は、方向付けられた鎖に沿ってロールアップすることができる：

スレッドまたはスタックセグメントの強度統計のマージ
スレッドの２つの例示的クラス（顧客サーバ，ＨＴＴＰサーブレット，ＡＤＦアプリケーション）および（顧客サーバ，Ｏｕｔｌｏｏｋコネクタ，ＡＤＦアプリケーション）は、例示的なスーパークラス（顧客サーバ，ＡＤＦアプリケーション）の下でマージすることができる。ＡＤＦアプリケーションの強度統計はＨＴＴＰサーブレットおよびＯｕｔｌｏｏｋコネクタを介する要求を含む。ＡＤＦアプリケーションの応答時間がＨＴＴＰサーブレットおよびＯｕｔｌｏｏｋコネクタ・チャネルの場合と同じであると想定されてもよい。

τ（ＡＤＦ）＝τ（ＨＴＴＰ−ＡＤＦ）＝τ（Ｏｕｔｌｏｏｋ−ＡＤＦ）
マージされたプロセスの到着率は以下のとおりである。

λ（ＡＤＦ）＝λ（ＨＴＴＰ−ＡＤＦ）＋λ（Ｏｕｔｌｏｏｋ−ＡＤＦ）
マージされたプロセスの強度は以下のとおりある。

ρ（ＡＤＦ）＝λ（ＡＤＦ）・τ（ＡＤＦ）
＝（λ（ＨＴＴＰ−ＡＤＦ）＋λ（Ｏｕｔｌｏｏｋ−ＡＤＦ））・τ（ＡＤＦ）
＝λ（ＨＴＴＰ−ＡＤＦ）・τ（ＨＴＴＰ−ＡＤＦ）＋λ（Ｏｕｔｌｏｏｋ−ＡＤＦ）・τ（Ｏｕｔｌｏｏｋ−ＡＤＦ）
＝ρ（ＨＴＴＰ−ＡＤＦ）＋ρ（Ｏｕｔｌｏｏｋ−ＡＤＦ）
スレッドまたはスタックセグメントの強度統計のセグメント化
例示的なスレッドのクラス（ＡＤＦアプリケーション）は、スレッドの３つの例示的なサブクラス、すなわち（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）、（ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ）および（ＡＤＦアプリケーション，ＡＤＦ−ＳＥＣＵＲＩＴＹ）を含み得る。スレッドのこれらの３つのサブクラスは、合成状態によってコンポーネント状態の呼出しのシーケンスを表わす。対応するスレッド強度は以下の態様で表わすことができる。ρ（ＡＤＦ−ＢＣ）は、（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ）スレッドの強度を表わし、ρ（ＡＤＦ−ＭＤＳ）は、（ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ）スレッドの強度を表わし、ρ（ＡＤＦ−ＳＥＣＵＲＩＴＹ）は、（ＡＤＦアプリケーション，ＡＤＦ−ＳＥＣＵＲＩＴＹ）スレッドの強度を表わす。

ＡＤＦアプリケーションの予想応答時間は、ＡＤＦ−ＢＣ呼出し、ＡＤＦ−ＭＤＳ呼出しおよびＡＤＦ−ＳＥＣＵＲＩＴＹ呼出しの応答時間にセグメント化することができる。

ＡＤＦアプリケーションのスレッドまたはスタックセグメントの強度は、コンポーネント応答時間によってセグメント化することができる。

到着密度λ（ＡＤＦ）が３つのすべてのサブクラスに関して同じであるため、スーパークラスのスレッドまたはスタックセグメントの強度は、スレッドまたはスタックセグメントの３つのサブクラスの強度で構成される。

したがって、合成状態の予想される強度は、比例的に、コンポーネント状態の予想強度に起因するものとみなすことができる。

スレッドまたはスタックセグメントの強度統計における到着率の乗算
ＡＤＦ−ＪＡＡＳが、ＡＤＦ−ＢＣ状態、ＡＤＦ−ＭＤＳ状態およびＡＤＦ−ＳＥＣＵＲＩＴＹ状態におけるいずれかのスタックフレームから複数回呼び出され得るアクセス制御チェックを表わすと仮定すると、予測（ＡＤＦアプリケーション，ＡＤＦ−ＪＡＡＳ）は、アクセス制御チェックを実行するスレッドの状態を表わす。これにより、以下の３つのサブクラス（ＡＤＦアプリケーション，ＡＤＦ−ＢＣ，ＡＤＦ−ＪＡＡＳ）、（ＡＤＦアプリケーション，ＡＤＦ−ＭＤＳ，ＡＤＦ−ＪＡＡＳ）、および（ＡＤＦアプリケーション，ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＡＤＦ−ＪＡＡＳ）の強度統計がマージされる。

各々のＡＤＦアプリケーションスレッドがアクセス制御チェックを呼び出し得る予想回数に応じて、状態（ＡＤＦアプリケーション，ＡＤＦ−ＪＡＡＳ）の到着率λ（ＡＤＦ−ＪＡＡＳ）は、ＡＤＦアプリケーションについての到着率λ（ＡＤＦ）の倍数になり得る。以下の式においては、ωは倍数因子を表わす：
λ（ＡＤＦ−ＪＡＡ）＝ω・λ（ＡＤＦ）
ＡＤＦスレッドサンプルの到着過程はポアソン到着過程である。ＡＤＦ−ＪＡＡＳスレッドサンプルの到着過程はポアソン到着過程ではない。なぜなら、ＡＤＦ−ＪＡＡＳスレッドサンプルの複数回の到着が１つのＡＤＦスレッドサンプルの到着に依存し得るからである。しかしながら、依然として、いかなる平均エルゴード到着過程にも適用されるリトルの公式ρ＝λ・τを適用することができる。ＡＤＦ−ＪＡＡＳスレッドサンプルの到着過程が平均エルゴードであることが主張される。なぜなら、いずれかの２つのＡＤＦ−ＪＡＡＳスレッドサンプルの到着も、これらの到着時間の間隔が十分に大きければ、独立したものになるからである。したがって、スレッドまたはスタックセグメント（ＡＤＦアプリケーション，ＡＤＦ−ＪＡＡＳ）の強度が以下によって与えられる。

ρ（ＡＤＦ−ＪＡＡＳ）＝λ（ＡＤＦ−ＪＡＡＳ）・τ（ＡＤＦ−ＪＡＡＳ）
＝ω・λ（ＡＤＦ）・τ（ＡＤＦ−ＪＡＡＳ）
λ（ＡＤＦ）＝ρ（ＡＤＦ）／τ（ＡＤＦ）が代入される場合、以下の式が生成される。

ρ（ＡＤＦ−ＪＡＡＳ）＝ω・［τ（ＡＤＦ−ＪＡＡＳ）／τ（ＡＤＦ）］・ρ（ＡＤＦ）
スレッドまたはスタックセグメント（ＡＤＦアプリケーション，ＡＤＦ−ＪＡＡＳ）の強度は、スレッドまたはスタックセグメント（ＡＤＦアプリケーション）の強度の因子ω・τ（ＡＤＦ−ＪＡＡＳ）／τ（ＡＤＦ）である。たとえば、ＡＤＦアプリケーションへの各々の要求により、５回のアクセス制御チェック（すなわちω＝５）が実行され、ＡＤＦ−ＪＡＡＳの予想される応答時間が、ＡＤＦアプリケーションの予想される応答時間の１０パーセントを構成する場合、すなわちτ（ＡＤＦ）＝１０・τ（ＡＤＦ−ＪＡＡＳ）となる場合、ＡＤＦ−ＪＡＡＳスレッドまたはスタックセグメントの平均強度は、ＡＤＦアプリケーションのスレッドまたはスタックセグメントの強度の５０パーセントを構成することとなる。以下のとおり予想され得る。

したがって、以下のとおりである。
ω・τ（ＡＤＦ−ＪＡＡＳ）／τ（ＡＤＦ）＜１
スレッドまたはスタックセグメントの強度統計によるインピーダンス整合
２ノードＣＲＭドメインセールスサーバクラスタと２ノードＣＲＭドメインオーダキャプチャサーバクラスタとの間に通信チャネルが存在する例が検討されてもよい。これらのチャネルは、セールスサービスにおけるスレッドのクラスとオーダーキャプチャサービスにおけるスレッドのクラスとの間のクライアント・サーバ依存関係をサポートすることができる。

（ＣＲＭドメイン，セールスサーバ，ＡＤＦアプリケーション，ＡＤＦウェブサービス呼出し）→（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）
対応するスレッド強度は次のように表わすことができる：ρ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）は、セールスサーバクラスタにおける（ＣＲＭドメイン，セールスサーバ，ＡＤＦアプリケーション，ＡＤＦウェブサービス呼出し）スレッドの強度を表わし；ρ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ（ｉ））は、セールスサーバノードｉにおける（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）スレッドの強度を表わし；ρ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ）は、オーダキャプチャサーバクラスタにおける（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）スレッドの強度を表わし；ρ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ（ｉ））は、オーダキャプチャサーバノードｉにおける（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）スレッドの強度を表わす。

セールスサーバクラスタおよびオーダキャプチャサーバクラスタにおいてｎ個およびｍ個のノードがあると想定すると、以下のとおりである。

セールスサーバとオーダキャプチャサーバとの間の通信チャネルが、セールスサービスからオーダーキャプチャサービスへのウェブサービス呼出しに対して如何なるインピーダンス不整合も導入しない場合、以下のとおりである。

ρ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）＝ρ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ）
クライアントスレッドおよびサーバスレッドの強度の不一致が確認された場合、これは通信チャネルにおける輻輳に起因するものとみなすことができる。ρ（ｃｈａｎｎｅｌ）がクライアントスレッドとサーバスレッドとの間の通信チャネルにおけるトラフィック強度を表わす場合、以下のとおりである。

ρ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）＝ρ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ）＋ρ（ｃｈａｎｎｅｌ）
到着率および出発率が平衡状態であれば、以下のとおりである。

λ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）＝λ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ）＝λ（ｃｈａｎｎｅｌ）
および
τ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）＝τ（ＷｅｂＳｅｒｖｉｃｅ−ＡＤＦ−ＢＣ）＋τ（ｃｈａｎｎｅｌ）
通信チャネルの容量を増やすことにより、クライアントサービスと、レイテンシτ（channel）をクライアントの応答時間τ（ＡＤＦ−ＨＴＴＰＣｌｉｅｎｔ）に付与するサーバサービスとの間のインピーダンス不整合を小さくすることができる。

強度の飽和
スレッドまたはスタックセグメントの強度は、スレッドダンプにおけるスレッドまたはスタックセグメントのクラスについての予想されるスタックトレース数の基準である。スレッド強度は、スレッドまたはスタックセグメントの所与のクラスの到着率および予想応答時間に応じて増大するだろう。

いくつかのシステムは、所与のクラスのスレッドを実行するのに利用可能なスレッドの最大数に制限を課している。この制限に達すると、たとえ、到着率または応答時間が増加し続ける可能性があったとしても、スレッドまたはスタックセグメントの強度が飽和し（最大限に達し）、統計はもはや関係ρ＝λ・τを反映しなくなるだろう。本発明の実施形態は、いつ飽和点に達するのかを認識することができる。本発明の実施形態は、強度の成長傾向を推定するホルト・ウィンタース三重指数移動平均フィルタを含む。これらの実施形態は、強度が最大値で横ばいになり、予測された成長傾向の追従を中止すると、一連のアウトライアを検出したときにこれら飽和点を認識することができる。

システムが最大強度に制限を課していない場合、スレッドまたはスタックセグメントの強度が、その限界を超えて増大し、システムにおいてメモリ不足のエラーを引起こす可能性がある。この条件は、エンドポイントとしてホルト・ウィンタース三重指数移動平均フィルタによって予測することができる。

アンチエイリアシング
ポアソン・カウント過程は、サンプル窓が部分的に重なっておらず独立していることを必要とする。この場合、スタックしたスレッドおよび残存するスレッドを二回以上カウントする必要はなくなる。システムは、java.lang.management APIにおけるThreadInfo.getThreadId()およびThreadMXBean.getThreadCpuTime(long id)を用いて、各々のスレッドの中央処理装置（ＣＰＵ：central processing unit）時間を監視する。当該技術では、スレッドのＣＰＵ時間が、先行のスレッドダンプから変化していない場合には、スレッドがスタックしていると推論する。この技術では、連続するスレッドダンプの数を追跡するが、この場合、このスレッドはスタックしているものとして検出される。これらの変数は、ThreadAntiAliasingInfoデータ構造において維持することができる。

スレッドが残存するがスタックしていない場合、ＣＰＵ時間は変化するだろう。残存するスレッドを検出するために、アンチエイリアシング技術を、スタックトレースのルートフレーム間のサーブレットフィルタなどのクラスと協働させて、java.lang.ThreadsetNameアプリケーションプログラミングインターフェイス（ＡＰＩ：application programming interface）を用いて、スレッドの名前にエポックカウンタを追加する。スレッド名がThreadAntiAliasingInfoに記録された先行するスレッド名と同じである場合、当該技術では、スレッドが既にカウントされたと推論される。スレッド名におけるエポック情報は、スレッドプールにおける同じスレッドが新しいエポックのための再使用されたときにエイリアスとして観察された場合、アンチエイリアシング解決策を提供する。

スタックしたスレッドまたは残存するスレッドがスレッドのあるクラスに関して一貫して検出される場合、当該技術は、スレッドのこのクラスについてのサンプル時間窓の予想長さが、Ｎ^＊Ｍ（Ｍはサンプリング時間間隔である）分未満となるまで、（ｎ番目ごとのスレッドダンプを用いることによって）サンプリング間隔を適合させることができる。

ハイパーテンション状態およびハイポテンション状態
ＪＶＭは、システムのハイパーテンション状態を表わし得るスタックしたスレッドを検出するために装備され得る。ハイパーテンション状態は、データベースサーバまたはバックエンドサーバに向かう下流経路における輻輳と診断することができる。しかしながら、本発明の実施形態はまた、上流経路に輻輳が起こっているせいで要求がサーバに通じていない場合、ハイポテンション状態（デハイドレーション）を検出することができる。後者の条件は、スタックしたスレッドを検出するための標準的なＪＶＭ計測によっては検出することができない。スレッドまたはスタックセグメントの強度を用いるアウトライア検出は、ハイパーテンション状態およびハイポテンション状態の両方を対称的に検出することができる。

スレッドの最大値がＮであり、予想されるスレッドまたはスタックセグメントの強度がρである場合、ポアソン分布によって飽和の確率が与えられる。

予想されるスレッドまたはスタックセグメントの強度が５であり、スレッドまたはスタックセグメントの最大数が１０である場合、スレッドまたはスタックセグメントの強度を飽和させる確率は０．０３２であり、これは、スレッドダンプの３．２％が１０で飽和した強度を示すであろうことを意味する。予想されるスレッドまたはスタックセグメントの強度が５０であり、スレッドまたはスタックセグメントの最大数が１００であると仮定するならば、１００でのスレッドまたはスタックセグメントの強度を飽和させる確率は、３．２Ｅ−１０である。この確率では、通常原因の飽和が起こる可能性は低く、スレッドまたはスタックセグメントの強度飽和が、サーバの下流における過度の輻輳などの異常原因に起因して発生するはずである。同様に、５．０Ｅ^−１０の確率では、サーバの上流における輻輳のせいでサーバが過度にデハイドレートしていない限り、スレッドまたはスタックセグメントの強度が１４を下回る可能性は低くなるだろう。

スタックフレームの強度駆動型分類
一般に、スレッドダンプがいくらかの期間にわたって十分な回数だけサンプリングされた後、低強度のスレッドまたはスタックセグメントのスタックトレースが検出されることが予想され得る。しばしば、長期にわたるスレッドダンプの後でさえ低すぎて検出できない強度を有するスタックフレームを、ソフトウェアアップグレードのシステムグリッチまたは回帰のおかげで、検出することができる。それにもかかわらず、極めてまれに、スタックフレームが検出も分類もされないままとなる可能性がある。本発明の実施形態では、スタックフレームの新しいトレースは、これらが十分な数のスレッドダンプの後または強度の急上昇をもたらすシステムグリッチの後に検出された場合には、継続して分類することができる。この明細書中に開示される分類スキームは、スタックフレームの強度基準（intensity measures）によって駆動される。

システムは、個々のスタックフレームの強度だけでなく、スタックトレースにおけるスタックフレームに隣接して現われる先行処理スタックフレームおよび後続処理スタックフレームの強度も追跡する。システムは、同じ強度で現われる隣接するスタックフレーム、すなわち、スタックトレースにおいて順序付けられた配列で常に一緒に現われるスタックフレーム、に対して同じ分類を割当てる。たとえば、スキームは、順序付けられた配列で常に一緒に同じ強度で現われる以下のスタックフレームに（ＪＤＢＣ−実行）クラスを割当てるだろう：
oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:991)
oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1285)
oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3449)
oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3550)
oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4693)
oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1086)
上述のとおり、ＡＤＦアプリケーションの強度ρ（ＡＤＦ）は、３つのコンポーネントρ（ＡＤＦ−ＢＣ）、ρ（ＡＤＦ−ＭＤＳ）およびρ（ＡＤＦ−ＳＥＣＵＲＩＴＹ）にセグメント化することによって近似させることができる：

モデルを向上させるために、ＡＤＦ−ＢＣ状態、ＡＤＦ−ＭＤＳ状態およびＡＤＦ−ＳＥＣＵＲＩＴＹ状態から分離された種々雑多なＡＤＦアプリケーション状態の強度は、（ＡＤＦアプリケーション，ＡＤＦ−ｍｉｓｃ）クラスの下でロールアップすることができる。最後の状態の強度であるρ（ＡＤＦ−ｍｉｓｃ）は、３つの主要なコンポーネントの強度と比べて無視できるほど些細なものであるかもしれない。

ρ(ADF)=ρ(ADF-BC)+ρ(ADF-MDS)+ρ(ADF-SECURITY)+ρ(ADF-misc)
（ＡＤＦアプリケーション，ＡＤＦ−ｍｉｓｃ）クラスの下にあるスレッドまたはスタックセグメントのサブクラスの強度がシステムグリッチのせいで急上昇する可能性がある。たとえば、ファイルシステムグリッチは、いくつかのＡＤＦアプリケーションスレッドをファイル書込動作の際にスタックさせてしまう可能性がある。

java.io.FileOutputStream.writeBytes(Native Method)
java.io.FileOutputStream.write(FileOutputStream.java:260)
…
java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:57)
…
org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
…
at oracle.adf.View.process(View.java:632)
このスタックフレームの強度がしきい値を越えて急上昇すると想定した場合、ＡＤＦアプリケーションスレッドの新しい状態（ＡＤＦアプリケーション，ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃ）を分類することができる。急上昇している期間中、ＡＤＦアプリケーションの強度ρ（ＡＤＦ）は４つのコンポーネントに分解することができる：
ρ（ＡＤＦ）＝ρ（ＡＤＦ−ＢＣ）＋ρ（ＡＤＦ−ＭＤＳ）＋ρ（ＡＤＦ−ＳＥＣＵＲＩＴＹ）＋ρ（ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃ）
ファイル書込動作を実行するスタックフレームが、ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃスタックフレームならびにＡＤＦ−ＢＣスタックフレーム、ＡＤＦ−ＭＤＳスタックフレームおよびＡＤＦセキュリティスタックフレームの上で発生する可能性がある。時間が経過するのに応じて、システムは、ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃにおける他のスタックフレームの強度から分岐するファイル書込動作スタックフレームの強度を検出し得る。さまざまなグループのスタックフレームの強度を分離することにより、結果として、新しい分類（ファイル書込動作）が得られ、分類（ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃ）が（ＡＤＦ−Ｖｉｅｗ，ファイル書込動作）にセグメント化されるだろう。先行する分類（ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃ）が新しい（ファイル書込動作）クラスおよび（ＡＤＦ−Ｖｉｅｗ）クラスの下に組込まれる。新しい（ファイル書込動作）クラスはまた、（ＡＤＦ−ＢＣ）クラス、（ＡＤＦ−ＭＤＳ）クラスおよび（ＡＤＦ−セキュリティ）クラスと交差して、新しいサブクラス（ＡＤＦ−ＢＣ，ファイル書込動作）、（ＡＤＦ−ＭＤＳ，ファイル書込動作）および（ＡＤＦ−セキュリティ，ファイル書込動作）を形成する。これらの強度も急上昇している。こうして、強度によって（ファイル書込動作）クラスおよび（ＡＤＦ−Ｖｉｅｗ）クラスの分類が駆動される。

システムは、スタックフレームを分類しこの分類を適切なディメンションに割当てるために、人の暗黙知を要求する可能性がある。本発明のいくつかの実施形態においては、帰納的学習プロセスにより、システムが既に規定したディメンションに新しいクラスを割当てることができる。たとえば、（ＡＤＦ−ＢＣ，ファイル書込動作）スタックトレース、（ＡＤＦ−ＭＤＳ，ファイル書込動作）スタックトレース、（ＡＤＦ−セキュリティ，ファイル書込動作）スタックトレース、および（ＡＤＦ−Ｖｉｅｗ，ファイル書込動作）スタックトレースの強度および近接統計を分析することにより、帰納的学習プロセスでは、以下に示されるように、（ファイル書込動作）クラスをオペレーションディメンションに割当て、（ＡＤＦ−Ｖｉｅｗ）クラスをライブラリディメンションに割当ててもよい：
オペレーション（データベース・オペレーション）｜（ＬＤＡＰオペレーション）｜（ウェブサービス呼出し）｜（ファイル書込動作）
ライブラリ＝（ＡＤＦ−ＢＣ）｜（ＡＤＦ−ＭＤＳ）｜（ＡＤＦ−ＳＥＣＵＲＩＴＹ）｜（ＡＤＦ−ＶＩＥＷ）
スタックトレースにおいて個々のスタックフレームを分類できるようにするために、システムは、StackFrameInfoデータ構造を用いて、現在のスレッドダンプ（numOfOccur）におけるスタックフレームの発生回数、すべてのスレッドダンプ（totalNumOfOccur）における合計発生回数、先行処理（predecessors）のリスト、後続処理（successors）のリスト、および一体化セグメントを維持する。StackFrameInfoデータ構造におけるclassMethodLineNumber変数は、スレッドダンプにおけるスタックフレームを表わす「weblogic.work.ExecuteThread run (ExecuteThread.java:213)」などのストリングを保持する。さらに、numOfOccurは、現在のスレッドダンプにおける「weblogic.work.ExecuteThread run (ExecuteThread.java:213)」の発生回数を保持する。強度基準は、強度＝totalNumOfOccur/totalNumOfDumpsによって与えられる派生変数である。

（ＡＤＦ−Ｖｉｅｗ−ｍｉｓｃ）などの既存の分類が、（ＡＤＦ−Ｖｉｅｗ，ファイル書込動作）などの２つの新しい分類に分割される場合、新しい分類は、元の分類の第１のセグメントおよび第２のセグメントとして維持される。元の分類は、新しい分類の一体化セグメントとして設定される。分類に属するスタックフレームも、分類の際にエレメントとして維持される。分類の名前およびディメンションは任意であり、暗黙知によって規定することができる。一体化セグメント、第１の構成セグメント、第２の構成要素セグメント、およびスタックセグメント分類のエレメントは、StackSegmentInfoデータ構造を用いて維持される。

再帰的プログラム構造のおかげで回数を変えて繰り返すことのできるスタックセグメントも、StackSegmentInfoによって分類される。この再帰的なStackSegmentInfoは、さまざまなコンテキストに現われる可能性がある。すなわち、一体化セグメントまたはスレッドの２つ以上のクラスにおいて発生する可能性がある。RecursiveSegmentInfoデータ構造を用いて、各々のコンテキストにおけるStackSegmentInfoの再帰的な発生を表現し、RecursiveSegmentInfoデータ構造における再帰（numOfRecur）の深さを記録する。RecursiveSegmentInfoはまた、ツリー走査用のビジター設計パターンで相互回帰セグメントを構成することができる。たとえば、単純な相互回帰構造は、（Ａ，Ｂ）^ｎのように見えるだろう。この場合、ＡおよびＢは互いを呼び出している。相互回帰がさまざまなタイプのツリーノード｛Ａ１，Ａ２，Ａ３｝およびさまざまなタイプのビジターノード｛Ｂ１，Ｂ２，Ｂ３｝を含んでいるビジター設計パターンは、（（Ａ１，Ｂ１），（Ａ３，Ｂ３）^２，（Ａ２，Ｂ２），（Ａ３，Ｂ３）^５，…）のように見えるだろう。相互回帰セグメント、たとえばセグメント（Ａ３，Ｂ３）^ｎは、スタックトレースにおけるさまざまな位置で何回も発生し得る。各々の位置はRecursiveSegmentInfoのインスタンスによって表わされる。

当該技術は、スレッドのスタックトレースを一連のリーフレベルスタックセグメントに分割し、さらに、リーフレベルスタックセグメントを、それが一連のトップレベルの一体化されたスタックセグメントになるまで一体化する。これら一連のトップレベルの一体化スタックセグメントは各々、構成セグメントの階層を表現するバイナリツリー構造を含み得る。この表現により、同等クラスのスレッドを分類するためのシグネチャが形成され、幅広いレパートリーのスレッドに対してスレッドをパターンマッチングさせる際の時間複雑性が低減される。スレッド分類情報はThreadClassificationInfoデータ構造を用いて維持される。

本発明の実施形態はまた、スタックフレームの分類のたびに、強度について季節的傾向をフィルタリングする。SeasonalTrendInfoデータ構造は、フィルタ変数のうちのいくつかを含む。SeasonalTrendInfoにおけるrawIntensity変数は、スタックフレーム、スタックセグメントまたはスレッドクラスの強度を現在のスレッドダンプに記録する。スタックセグメントがリーフレベルセグメントである（サブセグメントがない）場合、numOfOccurは、スタックセグメントにおける各々のStackFrameInfoエレメントのnumOfOccurと同じになるだろう。フィルタは、強度の成長傾向を予測するために、平滑化された強度および平滑化された強度成長率を更新する。予測された強度の正規化残差は、測定された強度が予想強度から逸脱している場合に表わすアウトライアを検出するためのフィルタとして用いることができる。この条件は、サービスのハイパーテンション状態またはハイポテンション状態を表現することができる。

強度駆動型分類の例示的シナリオ
システムがスタックトレースにおける一連のスタックフレームを分類したと想定すると、スタックフレームのリストは、スタックセグメント（Ａ）のエレメントを構成することができる。各々のスタックフレームエレメントは、強度、発生回数、先行処理エレメントおよび後続処理エレメントの情報を維持する。このクラスにおけるスタックフレームは、たとえば、１０個のスレッドダンプの後に１．３の同じ強度を有する可能性がある。

１００のスレッドダンプの後、スタックセグメント（Ａ）におけるスタックフレームの強度は、３つのグループに分岐してもよい。この場合、下部の３つのスタックフレームの強度が２．５まで増加し、上部の３つのスタックフレームの強度が１．３３までわずかに増加し、接着フレームとしての役割を果たす中間のスタックフレームの強度が約１．３で留まっている。強度が分岐すると、システムは、スタックセグメント（Ａ）を２つの構成スタックセグメント（Ａ−１）および（Ａ−２）に分割し、再びスタックセグメント（Ａ−２）を（Ａ−２−１）および（Ａ−２−２）に分割する。中間のスタックフレーム（Ａ−２−１）の強度はスタックセグメント（Ａ）の強度を表わす。すなわち、Ａ＝（Ａ−１，Ａ−２−１，Ａ−２−２）となる。（Ａ−１）および（Ａ−２−２）の強度は、これらがスタックトレース（Ａ−１，ＡＣ，Ｃ）および（Ｂ，ＢＡ，Ａ−２−２）において発生するために、分岐する。この場合、（ＡＣ）および（ＢＡ）は、それぞれ、（Ａ−１）を（Ｃ）に接続し、（Ｂ）を（Ａ−２−２）に接続する接着フレームを表わしている。特定のスタックフレームは、複数の後続処理および複数の先行処理を有し得る。

当該技術により、スタックセグメントのスタックフレームの中から強度の相違が検出されると、新しい構成スタックセグメント中のスタックフレームエレメントが分割される。たとえば、構成スタックセグメント（Ａ−１）、（Ａ−２）、（Ａ−２−１）および（Ａ−２−２）は、それら各々が直接的または間接的に一体化セグメントとしてスタックセグメント（Ａ）を参照するものであるが、このような分割から生成することができる。この例においては、スタックセグメント（Ａ）におけるエレメントは、スタックセグメント（Ａ−１）におけるエレメントおよびスタックセグメント（Ａ−２）におけるエレメントに分割することができる。スタックセグメント（Ａ−２）は、次いで、スタックセグメント（Ａ−２−１）におけるエレメントおよびスタックセグメント（Ａ−２−２）におけるエレメントに分割することができる。スタックフレームは、対応するリーフレベル一体化セグメントを参照するために更新される。さまざまなエレメントのための一体化セグメントは、それらのエレメントが属する新しいスタックを反映させるように更新することができる。

構成セグメントが再帰する深さ分だけ異なっているスタックセグメントのばらつきを観察することができる。いくつかのセグメントの強度が同じままである一方で、任意の再帰深さのせいで他のセグメントの強度が異なっていると想定すると、システムは元のセグメントを構成セグメントに分割することができる。元のスタックセグメントのエレメントは、Ａ−２−１によって分類される可変数のスタックセグメントを含み得る。結果として、元のスタックセグメントの構成セグメントは、可変数のセグメントＡ−２−１を含むこととなる。指定されたパターンと適合するいずれのスタックトレースも同じ分類シグネチャによって識別することができる。再帰セグメントは、一体化セグメントＡ−２の第１の構成セグメントの分類としてスタックセグメントＡ−２−１を指すことができる。

システムは、初期のフィルタ状態として用いるために、各々の新しいスタックセグメント（Ａ−１）、（Ａ−２）、（Ａ−２−１）、および（Ａ−２−２）についてスタックセグメント（Ａ）におけるSeasonalTrendInfoデータのコピーを一部作成することができる。続いて、（Ａ−１）、（Ａ−２）、（Ａ−２−１）、および（Ａ−２−２）のためのSeasonalTrendInfoデータを独立して更新することができる。

スレッドクラス依存情報モデル
スレッド分類および強度測定アルゴリズムは、スレッドクラス間において依存情報を提供する知識ベースを用いてブートストラップすることができる。依存情報を用いることにより、スレッドクラス間の通信チャネルにおけるトラフィック強度を推定することができる。これらはまた、根本的原因分析のために、問題のあるコンテナにおけるＦＡサーバのさまざまな部品における２つ以上のスレッドクラスからイベントおよび発生率（incidences）を関連付けることができる。たとえば、スレッドクラス依存性（ＣＲＭドメイン，セールスサーバ，ＡＤＦアプリケーション，ＡＤＦウェブサービス呼出し）→（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）と想定すると、ＦＡポッドおけるセールスサーバおよびオーダキャプチャサーバが、クライアントスレッドのハイポテンション状態およびサーバスレッドのハイパーテンション状態を同時に報告する場合、これらのイベントは発生中に集めることができる。これらのイベントが十分に頻繁に発生する場合、チケットが解放されてオーナーに割当てられて、セールスサーバクラスタとオーダキャプチャサーバクラスタとの間の通信チャネルにおける実現可能なインピーダンス不整合を分析することができる。オーナーは、インピーダンス整合の問題としてこれらの発生率を査定し、サービス要求を提出してもよい。

典型的には、依存情報はスーパークラスレベルで規定される。たとえば、依存性（ＡＤＦウェブサービス呼出し）→（ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）により、ＷｅｂＬｏｇｉｃドメインにわたって分散されるＡＤＦサービスとＦＡポッドにおけるサーバとの間における一般的なパターンのサービス呼出しが取り込まれる。この抽象的な依存性は、依存性（ＣＲＭドメイン，セールスサーバ，ＡＤＦアプリケーション，ＡＤＦウェブサービス呼出し）→（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ）を含む。別の状況においては、抽象的な依存性パターン（ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，フュージョンＤＢ）および（ＡＤＦ−ＳＥＣＵＲＩＴＹ，ＤＡＴＡＢＡＳＥオペレーション）→（ＤＡＴＡＢＡＳＥ，ＯＩＭ−ＡＰＭ ＤＢ）では、ＪＤＢＣスレッドのハイパーテンション問題の区別的診断により、データベースサーバのうちの１つにおける問題を切り離すことが可能となる。

情報モデルはスレッドクラスの間の依存性をマッピングすることができる。ＴhreadClassDependencyInfoは、クライアントスレッドクラスからサーバスレッドクラスへの多数対１のマッピングを表わすことができる。ThreadClassInfoは、スタックセグメントのタプルによってスレッドのクラスを指定することができる。たとえば、（ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）は、スタックセグメント（ＡＤＦ−ＢＣ）および（ＤＡＴＡＢＡＳＥオペレーション）のタプルである。クラス（ＣＲＭドメイン，オーダキャプチャサーバ，ＡＤＦウェブサービス，ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）は、（ＡＤＦ−ＢＣ，ＤＡＴＡＢＡＳＥオペレーション）のサブクラスである。ThreadClassificationInfoは、スレッドを分類するためのシグネチャを表わすスタックセグメントのリストを含む。当該技術は、（スタックフレームの下から上までの）バイナリツリーの深さを最初に１回走査して、訪問されたスタックセグメントオブジェクトのpartOfThreadClasses属性からスレッドクラスオブジェクトを抽出し、分類シグネチャにおけるスタックセグメントに対してThreadClassInfoにおけるスタックセグメントを適合させることができる。スレッドクラスが適合した場合、クライアントまたはサーバスレッドクラスはアラートまたは発生率レポートに含まれる。

スレッドまたはスタックセグメントの強度分析の適用
図１Ａおよび図１Ｂは、本発明の実施形態に従った、スレッドまたはスタックセグメントの強度分析を適用するための技術の一例を示すフロー図である。当該技術は、スタックフレーム情報マップ、スタックセグメント情報マップ、スレッド分類マップおよびアンチエイリアシング情報マップを維持する。スタックフレーム情報マップ、スタックセグメント情報マップおよびスレッド分類マップは、ある一時点までに集められた（サンプリング時間よりも前の一連のサンプリング時間中に集められた）スレッドダンプサンプルから抽出されたスタックフレーム、スタックセグメントおよびスレッド分類から構成される。これらのマップは、任意には、履歴アーカイブにおけるスレッドダンプから抽出されたスタックフレーム、スタックセグメントおよびスレッド分類でブートストラップすることができる。アンチエイリアシング情報マップは、先行のスレッドダンプにおいてサンプリングされるスレッドを表わす。スレッドアンチエイリアシング情報マップを用いて、現在のサンプリング時間のスレッドダンプにあって先行のサンプリング時間のスレッドダンプにおいて既に発生しているスレッドを識別する。サンプリング時間におけるスレッドダンプのスタックトレースは、スタックフレーム情報マップ、スタックセグメント情報マップおよびスレッド分類マップを用いて分類することができる。これらのマップは、図１Ａおよび図１Ｂのフロー図ならびに以降の図によって示されるプロセスについてのコンテキストの一部である。最初に図１Ａを参照すると、ブロック１０２においては、現在のサンプリング時間に到達する。

ブロック１０４においては、現在のサンプリング時間は、サンプリング時間間隔が経過した時点で、次のサンプリング時間に設定される。ブロック１０６においては、現在のサンプリング時間におけるすべてのスレッドのスレッドダンプが得られる。たとえば、現在のサンプリング時間についてのスレッドダンプはjava.lang.management.ThreadMXBeanから得ることができる。ブロック１０８においては、スレッドダンプカウンタがインクリメントされる。

各々のサンプリング時間におけるスレッドダンプのために、スタックフレーム情報マップにおける各々のスタックフレーム情報項目の発生カウンタの数がゼロにリセットされ、これにより、このカウンタを用いて、現在のスレッドダンプにおけるスタックフレームの発生回数をカウントすることができるようになる。これを達成するために、ブロック１１０においては、スタックフレーム情報マップにおける未処理のスタックフレーム情報項目が、まだ処理されないまま残っているかどうかが判断される。そうであれば、制御が次にブロック１１２に進められる。そうでない場合、制御はブロック１１６に進められる。

ブロック１１２においては、現在のスタックフレーム情報項目は、スタックフレーム情報マップにおける次の未処理のスタックフレーム情報項目に設定される。ブロック１１４において、現在のスタックフレーム情報項目についての発生回数がゼロに設定される。制御がブロック１１０に戻される。

各々のサンプル時間におけるスレッドダンプのために、スタックセグメント情報マップにおける各々のスタックセグメント情報項目の発生回数カウンタがゼロに設定され、これにより、カウンタを用いて、現在のスレッドダンプにおけるスタックセグメントの発生回数をカウントすることができるようになる。これを達成するために、ブロック１１６においては、スタックセグメント情報マップにおける未処理のスタックセグメント情報項目がまだ処理されないまま残っているかどうかが判断される。そうであれば、制御が次にブロック１１８に進められる。そうでなければ、制御は図１Ｂのブロック１２２に進められる。

ブロック１１８においては、現在のスタックセグメント情報項目は、スタックセグメント情報マップにおける次の未処理のスタックセグメント情報項目に設定される。ブロック１２０においては、現在のスタックセグメント情報項目についての発生回数がゼロに設定される。制御がブロック１１６に戻される。

各々のサンプル時間におけるスレッドダンプのために、スレッド分類情報マップにおける各々のスレッド分類情報項目の発生回数カウンタがゼロに設定され、これにより、カウンタを用いて、現在のスレッドダンプにおけるスレッドの発生回数をカウントすることができるようになる。これを達成するために、ここで図１Ｂを参照すると、ブロック１２２においては、スレッド分類情報マップにおける未処理のスレッド分類情報項目が、まだ処理されないまま残っている。そうであれば、制御が次にブロック１２４に進められる。そうでない場合、制御はブロック１２８に進められる。

ブロック１２４においては、現在のスレッド分類情報項目が、スレッド分類情報マップにおける次の未処理のスレッド分類情報項目に設定される。ブロック１２６においては、現在のスレッド分類情報項目についての発生回数がゼロに設定される。制御がブロック１２２に戻される。

ブロック１２８においては、現在のサンプリング時間についてのスレッドダンプに関するスタックフレーム統計が更新される。現在の時間間隔にわたるスレッドダンプについてのスタックフレーム統計を更新するための技術が、図２Ａおよび図２Ｂに関連付けて以下に開示される。ブロック１３０においては、スレッドクラスのセットは、現在のサンプリング時間中にスレッドダンプからスレッドおよびスタックセグメントを分類することによって決定される。現在のサンプリング時間中にスレッドダンプからスレッドおよびスタックセグメントを分類するための技術が、図３Ａ〜図３Ｊに関連付けて以下に開示される。

各々のサンプル時間におけるスレッドダンプのために、スレッドアンチエイリアシング情報マップにおける各々のスレッドアンチエイリアシング情報項目中のフラグがチェックされて、分類されたスレッドが現在のスレッドダンプにおいて発生するかどうかが判断される。分類されたスレッドが現在のスレッドダンプにおいて発生していない場合、これは、スレッドアンチエイリアシング情報マップから除去される。これを達成するために、ブロック１３２においては、未処理のスレッドアンチエイリアシング情報項目がスレッドアンチエイリアシング情報マップに残っているかどうかが判断される。そうであれば、制御が次にブロック１３４に進められる。そうでない場合、制御はブロック１４２に進められる。

ブロック１３４においては、現在のスレッドアンチエイリアシング情報項目が、スレッドアンチエイリアシング情報マップにおける次の未処理のスレッドアンチエイリアシング情報項目に設定される。ブロック１３６においては、現在のスレッド情報項目が現在のサンプル時間中にスレッドダンプにおいて発生しているかどうかを示す現在のスレッドアンチエイリアシング情報項目についてのフラグが偽であるかどうかが判断される。そうであれば、制御が次にブロック１３８に進められる。そうでない場合、制御はブロック１４０に進められる。

ブロック１３８においては、現在のスレッドアンチエイリアシング情報項目がスレッドアンチエイリアシング情報マップから除去される。制御がブロック１３２に戻される。

ブロック１４０においては、現在のスレッドアンチエイリアシング情報項目についてのフラグが偽に設定される。制御がブロック１３２に戻される。

ブロック１４２においては、季節的傾向把握フィルタが、現在のサンプル時間についてのスタックセグメント情報マップに対して適用される。季節的傾向把握フィルタを適用するための技術を図４に関連付けて以下に開示する。制御が図１Ａのブロック１０２に戻される。

スタックフレーム統計の更新
図２Ａおよび図２Ｂは、本発明の実施形態に従った、スタックフレーム統計を更新するための技術の一例を示すフロー図である。当該技術は、図１Ａおよび図１Ｂに関連付けて上述されたように、現在のサンプリング時間についてのスレッドダンプに対して実行することができる。まず図２Ａを参照すると、ブロック２０２においては、スレッドダンプにおける未処理のスレッド情報項目がまだ処理されずに残っているかどうかが判断される。そうであれば、制御が次にブロック２０４に進められる。そうでなければ、図２Ａおよび図２Ｂに示される技術が終了する。

ブロック２０４においては、現在のスレッド情報項目は、スレッドダンプにおける次の未処理のスレッド情報項目に設定される。ブロック２０６においては、現在のスタックトレースは、現在のスレッド情報項目におけるスタックトレースに設定される。ブロック２０８においては、スタックトレースエレメントインデックスがリセットされる。たとえば、インデックスは、当該インデックスを−１に設定することによってリセットすることができる。ブロック２１０においては、現在のスタックトレースエレメントは、現在のスタックトレースの一番下にあるスタックトレースエレメントに設定される。

ブロック２１２においては、スタックトレースエレメントインデックスがインクリメントされる。ブロック２１４においては、現在のスタックフレーム情報項目は、キーと適合させることによって、すなわち、現在のスタックトレースエレメントのキーと同じキーを有するスタックフレーム情報項目を得ることによって、現在のスタックトレースエレメントに対応する（スタックフレーム情報マップにあるか、または必要に応じて作成された）スタックフレーム情報項目に設定される。たとえば、キーはソースコードステートメント、行番号、オブジェクトコードアドレスまたはこれらの組合せで構成することができる。

ブロック２１６においては、現在のスタックトレースエレメントが現在のスタックトレースの一番下にあるかどうかが判断される。たとえば、スタックトレースエレメントインデックスがゼロに等しい場合、これは、現在のスタックトレースエレメントが現在のスタックトレースの一番下にあることを示し得る。現在のスタックトレースエレメントが現在のスタックトレースの一番下にある場合、制御はブロック２１８に進められる。そうでない場合、制御はブロック２２０に進められる。

ブロック２１８においては、現在のスタックフレーム情報項目は、スタックフレーム情報マップにおける一番下のフレームとしてマーク付けされる。これは、現在のスタックフレーム情報項目の先行処理リスト属性に「ＦＲＡＭＥ＿ＦＬＯＯＲ」などの何らかのスタックフレーム情報項目を追加することによって達成されてもよい。現在のスタックフレーム情報項目はまた、「ＦＲＡＭＥ＿ＦＬＯＯＲ」の後続処理リスト属性に追加することができる。制御が図２Ｂのブロック２２４に進められる。

ブロック２２０においては、現在のスタックトレースエレメントが現在のスタックトレースの一番上にあるかどうかが判断される。たとえば、スタックトレースエレメントインデックスが現在のスタックトレースのサイズよりも１だけ小さいものに等しい場合、これは、さらに、現在のスタックトレースエレメントが現在のスタックトレースの一番上にあることを示し得る。現在のスタックトレースエレメントが現在のスタックトレースの一番上にある場合、制御はさらにブロック２２２に進められる。そうでなければ、制御は図２Ｂのブロック２２４に進められる。

ブロック２２２においては、現在のスタックフレーム情報項目は、スタックフレーム情報マップにおける一番上のフレームとしてマーク付けされる。これは、現在のスタックフレーム情報項目の先行処理リスト属性に「ＦＲＡＭＥ＿ＣＥＩＬＩＮＧ」などの何らかのスタックフレーム情報項目を追加することによって達成されてもよい。現在のスタックフレーム情報項目も、「ＦＲＡＭＥ＿ＣＥＩＬＩＮＧ」の先行処理リスト属性に追加することができる。制御が図２Ｂのブロック２２４に進められる。

ここで図２Ｂを参照すると、ブロック２２４においては、現在のスタックフレーム情報項目の発生回数の属性がインクリメントされる。現在のスタックフレーム情報項目の合計発生回数の属性もインクリメントすることができる。ブロック２２６においては、先行のスタックフレーム情報項目が、ヌルでなければ、現在のスタックフレーム情報項目の先行処理リスト属性に追加される。ブロック２２８においては、いずれかのスタックトレースエレメントが現在のスタックトレースにおける現在のスタックトレースエレメントの上に存在するかどうかかが判断される。そうであれば、制御が次にブロック２３０に進められる。そうでなければ、制御はブロック２３６に進められる。

ブロック２３０においては、次のスタックトレースエレメントは、現在のスタックトレースエレメントの真上に存在するスタックトレースエレメントに設定される。ブロック２３２においては、次のスタックフレーム情報項目は、次のスタックトレースエレメントのキーと同じキーを有する（スタックフレーム情報マップにおける）スタックフレーム情報項目に設定される。たとえば、キーは、スタックフレームに対応するソースコードステートメント、行番号またはオブジェクトコードアドレスで構成することができる。ブロック２３４においては、次のスタックフレーム情報項目が、現在のスタックフレーム情報項目の後続処理リスト属性に追加される。制御がブロック２３６に進められる。

ブロック２３６においては、先行のスタックフレーム情報項目が、現在のスタックフレーム情報項目に設定される。ブロック２３８においては、いずれかのスタックトレースエレメントが現在のスタックトレースにおける現在のスタックトレースエレメントの上に存在するかどうかかが判断される。そうであれば、制御が次にブロック２４０に進められる。そうでなければ、制御が図２Ａのブロック２０２に戻される。

ブロック２４０においては、現在のスタックトレースエレメントは、現在のスタックトレースにおける現在のスタックトレースエレメントの真上に存在するスタックトレースエレメントに設定される。制御は図２Ａのブロック２１２に戻される。

スレッドおよびそれらのスタックセグメントの分類
図３Ａ〜図３Ｊは、本発明の実施形態に従った、スレッドおよびそれらのスレッドのスタックセグメントを分類するための技術の一例を示すフロー図である。当該技術は、図１Ａおよび図１Ｂに関連付けて上述された、現在のサンプリング時間中に、規定されたスレッドダンプに対して実行することができる。当該技術は、スレッド分類情報項目のセットとして表わされるスレッドクラスのセットを生成することができる。まず図３Ａを参照すると、ブロック３００２においては、スレッド分類情報項目の空のセットが作成され、このスレッド分類情報項目の空のセットは、スレッドダンプにおける各スレッドがセットにおける（潜在的に異なる）スレッド分類項目によって表わすことができるという特性を有しており、スレッドダンプにおける同等のスレッドが同じスレッド分類項目によって表わされるように作成される。これらの特性に従う新しいスレッド分類項目を作成し、以下に記載される動作によって当該セットに追加することができる。ブロック３００４においては、スレッドダンプにおける未処理のスレッド情報項目が処理されずに残っているかどうかが判断される。そうであれば、制御がブロック３００６に進められる。そうでない場合、制御はブロック３１８２に進められる。

ブロック３００６においては、現在のスレッド情報項目は、スレッドダンプにおける次の未処理のスレッド情報項目に設定される。ブロック３００８においては、スレッド名は、現在のスレッド情報項目の名前に設定される。ブロック３０１０においては、現在のスレッド情報項目のためのエイリアスが先行のスレッドダンプにおいて（すなわち先行のサンプリング時間中に）発見されたかどうかを示すフラグが偽に設定される。ブロック３０１２においては、スレッドアンチエイリアシング情報マップにおける未処理のスレッドアンチエイリアシング情報項目が処理されないまま残っているかどうかが判断される。そうであれば、制御が次にブロック３０１４に進められる。そうでなければ、制御は図３Ｂのブロック３０２４に進められる。

ブロック３０１４においては、現在のスレッドアンチエイリアシング情報項目は、スレッドアンチエイリアシング情報マップにおける次の未処理のスレッドアンチエイリアシング情報項目に設定される。ブロック３０１６においては、（ブロック３００８において参照された）スレッド名が現在のスレッドアンチエイリアシング情報項目の名前と同じであるかどうかが判断される。そうであれば、制御が次にブロック３０１８に進められる。そうでなければ、制御はブロック３０１２に戻される。

ブロック３０１８においては、現在のスレッドアンチエイリアシング情報項目のダンプ回数属性がインクリメントされる。ブロック３０２０においては、現在のスレッドアンチエイリアシング情報項目のフラグ属性は、その項目のためのエイリアスが現在のスレッドダンプに（すなわち現在のサンプリング時間中に）発見されるかどうかを示すものであるが、このフラグ属性が真に設定される。ブロック３０２２においては、ブロック３０１０において参照されたフラグは、現在のスレッド情報項目についてのエイリアスが先行のスレッドダンプにおいて発見されたかどうかを示すものであるが、このフラグが真に設定される。制御はブロック３０２４に進められる。

ここで図３Ｂを参照すると、ブロック３０２４においては、ブロック３０１０および３０２２において参照されたフラグが真に等しいかどうかが判断される。そうであれば、制御が図３Ａのブロック３００４に戻される。そうでない場合、制御はブロック３０２６に進められる。

ブロック３０２６においては、現在のスレッド情報項目に対応する新しいスレッドアンチエイリアシング情報項目が作成される。ブロック３０２８においては、新しいスレッドアンチエイリアシング情報項目のフラグ属性は、その項目についてのエイリアスが現在のスレッドダンプにおいて（すなわち現在のサンプリング時間中に）発見されるかどうかを示すものであるが、このフラグ属性が真に設定される。ブロック３０３０においては、新しいスレッドアンチエイリアシング情報項目の名前が、（ブロック３００８において参照された）スレッド名に設定される。ブロック３０３２においては、新しいスレッドアンチエイリアシング情報項目がスレッドアンチエイリアシング情報マップに追加される。ブロック３０３４においては、現在のスレッド情報項目のファイングレインセグメントを追跡するために新しいファイングレインセグメントリストが作成される。ブロック３０３６においては、現在のスタックトレースが、現在のスレッド情報項目のスタックトレースに設定される。ブロック３０３８においては、スタックトレースエレメントインデックスがリセットされる。たとえば、スタックトレースエレメントインデックスはインデックスの値を−１に設定することによってリセットすることができる。ブロック３０４０においては、現在のスタックトレースエレメントは、現在のスタックトレースの一番下にあるスタックトレースエレメントに設定される。

ブロック３０４２においては、スタックトレースエレメントインデックスがインクリメントされる。ブロック３０４４においては、現在のスタックフレーム情報項目は、現在のスタックトレースエレメントのキーと同じキーを有する（スタックフレーム情報マップにおける）スタックフレーム情報項目に設定される。たとえば、キーはスタックフレームに対応するソースコードステートメント、行番号またはオブジェクトコードアドレスから構成され得る。

ブロック３０４６においては、現在のスタックトレースエレメントが現在のスタックトレースの一番下にあるかどうかが判断される。たとえば、スタックトレースエレメントインデックスがゼロに等しい場合、これは、現在のスタックトレースエレメントが現在のスタックトレースの一番下にあることを示し得る。現在のスタックトレースエレメントが現在のスタックトレースの一番下にある場合、制御が図３Ｃのブロック３０４８に進められる。そうでなければ、制御が図３Ｄのブロック３０６６に進められる。

ここで図を３Ｃを参照すると、ブロック３０４８においては、現在のスタックフレーム情報項目が分類されたかどうかが判断される。たとえば、この判断は、現在のスタックフレーム情報項目の一体化セグメント属性がヌルに等しいかどうかを判断することによって行うことができる。この属性がヌルに等しい場合、現在のスタックフレーム情報項目はまだ分類されていない。現在のスタックフレーム情報が分類されていない場合、制御がブロック３０５０に進められる。そうでない場合、制御はブロック３０６２に進められる。

ブロック３０５０においては、新しいスタックセグメント情報項目が作成され、現在のスタックセグメント情報項目の値に割当てられる。ブロック３０５２においては、現在のスタックフレーム情報項目の（ブロック３０４８において参照された）一体化セグメント属性の値は、現在のスタックセグメント情報項目に設定される。ブロック３０５４においては、現在のスタックフレーム情報項目が、現在のスタックセグメント情報項目のエレメントリスト属性に追加される。ブロック３０５６においては、新しい季節的傾向情報項目が生成される。ブロック３０５８においては、現在のスタックセグメント情報項目の傾向属性の値は、新しい季節的傾向情報項目に設定される。ブロック３０６０においては、現在のスタックセグメント情報項目が（ブロック３０３４において参照された）ファイングレインセグメントリストに追加される。制御がブロック３０６４に進められる。

ブロック３０６２においては、現在のスタックセグメント情報項目は、現在のスタックフレーム情報項目の（ブロック３０４８において参照された）一体化セグメント属性の値に設定される。制御がブロック３０６４に進められる。

ブロック３０６４においては、現在のスタックセグメント情報項目は、現在のスタックトレースにおける一番下にあるセグメントとしてマーク付けされる。これは、現在のスタックセグメント情報項目の先行処理リスト属性に「ＳＥＧＭＥＮＴ＿ＦＬＯＯＲ」などの一定のスタックセグメント情報項目を追加することによって達成されてもよい。現在のスタックセグメント情報項目は、「ＳＥＧＭＥＮＴ＿ＦＬＯＯＲ」の後続処理リスト属性に追加することができる。制御が図３Ｊのブロック３１６２に進められる。

ここで図３Ｄを参照すると、ブロック３０６６においては、先行処理スタックトレースエレメントは、現在のスタックトレースエレメントインデックスの値よりも１だけ小さいインデックスを有する（現在のスタックトレースにおける）スタックトレースエレメントに設定される。ブロック３０６８において、先行処理スタックフレーム情報項目は、先行処理スタックトレースエレメントのキーと同じキーを有する（スタックフレーム情報マップにおける）スタックフレーム情報項目に設定される。たとえば、キーはスタックフレームに対応するソースコードステートメント、行番号またはオブジェクトコードアドレスで構成することができる。ブロック３０７０においては、先行処理スタックセグメント情報項目は、先行処理スタックフレーム情報項目の一体化セグメント属性の値に設定される。

ブロック３０７２においては、現在のスタックフレーム情報項目が分類されたかどうかが判断される。たとえば、この判断は、現在のスタックフレーム情報項目の一体化セグメント属性がヌルに等しいかどうかを判断することによって行うことができる。この属性がヌルに等しい場合、現在のスタックフレーム情報項目はまだ分類されていない。現在のスタックフレーム情報項目がまだ分類されていない場合、制御がブロック３０７４に進められる。そうでなければ、制御が図３Ｇのブロック３１２０に進められる。

ブロック３０７４においては、先行処理スタックフレーム情報項目が先行処理スタックセグメント情報項目のエレメントリスト属性における最後のスタックフレーム情報項目であるかどうかが判断される。そうであれば、制御が次にブロック３０７６に進められる。そうでなければ、制御が図３Ｆのブロック３０９８に進められる。

ブロック３０７６においては、先行処理スタックフレーム情報項目の後続処理リスト属性が、現在のスタックフレーム情報項目であるエントリを１つだけ有しているかどうかが判断される。そうであれば、制御が次にブロック３０７８に進められる。そうでない場合、制御はブロック３０８２に進められる。

ブロック３０７８においては、現在のスタックフレーム情報項目の先行処理リスト属性が、先行処理スタックフレーム情報項目であるエントリを１つだけ有しているかどうかが判断される。そうであれば、制御が図３Ｅのブロック３０８０に進められる。そうでない場合、制御はブロック３０８２に進められる。

ここで図３Ｅを参照すると、ブロック３０８０においては、現在のスタックフレーム情報項目の一体化セグメント属性の値が、先行処理スタックセグメント情報項目に設定される。ブロック３０８１においては、現在のスタックフレーム情報項目が先行処理スタックセグメント情報項目のエレメントリスト属性に追加される。制御が図３Ｊのブロック３１６２に進められる。

ブロック３０８２においては、新しいスタックセグメント情報項目が作成され、現在のスタックセグメント情報項目の値に割当てられる。ブロック３０８４においては、現在のスタックフレーム情報項目の（ブロック３０４８において参照された）一体化セグメント属性の値は、現在のスタックセグメント情報項目に設定される。ブロック３０８６においては、現在のスタックフレーム情報項目が、現在のスタックセグメント情報項目のエレメントリスト属性に追加される。ブロック３０８８においては、先行処理スタックセグメント情報項目が、現在のスタックセグメント情報項目の先行処理リスト属性に追加される。ブロック３０９０においては、現在のスタックセグメント情報項目が、先行処理スタックセグメント情報項目の後続処理リスト属性に追加される。ブロック３０９２においては、新しい季節的傾向情報項目が生成される。ブロック３０９４においては、現在のスタックセグメント情報項目の傾向属性の値は、新しい季節的傾向情報項目に設定される。ブロック３０９６においては、現在のスタックセグメント情報項目が（ブロック３０３４において参照された）ファイングレインセグメントリストに追加される。制御が図３Ｊのブロック３１６２に進められる。

ここで図３Ｆを参照すると、ブロック３０９８においては、先行処理スタックセグメント情報項目のトレースセグメントは、先行処理スタックフレーム情報項目が第１の新しいスタックセグメント情報項目の終わりにくるように、先行処理スタックフレーム情報項目のインデックスと後続処理スタックフレーム情報項目のインデックスとの間に発生する別個の第１および第２の新しいスタックセグメント情報項目に分割される。指定されたスタックフレームの前または後に分岐点を追加するためにスタックセグメントを分割するための技術が、図５Ａ〜図５Ｃを参照して以下に開示される。このシナリオにおいては、そのスタックセグメント分割技術は、このシナリオにおいては先行処理スタックセグメント情報項目である指定されたスタックセグメント情報項目の（前ではなく）後に分割を実行するために呼び出すことができる。

ブロック３１００においては、先行処理スタック情報項目は、ブロック３０９８の分割によって作成される第１の新しいスタックセグメント情報項目に設定される。ブロック３１０２においては、新しいスタックセグメント情報項目が作成され、現在のスタックセグメント情報項目の値に割当てられる。ブロック３１０４においては、現在のスタックフレーム情報項目の（ブロック３０４８において参照された）一体化セグメント属性の値は、現在のスタックセグメント情報項目に設定される。ブロック３１０６においては、現在のスタックフレーム情報項目が、現在のスタックセグメント情報項目のエレメントリスト属性に追加される。ブロック３１０８においては、先行処理スタックセグメント情報項目が、現在のスタックセグメント情報項目の先行処理リスト属性に追加される。ブロック３１１０においては、現在のスタックセグメント情報項目が、先行処理スタックセグメント情報項目の後続処理リスト属性に追加される。ブロック３１１２においては、新しい季節的傾向情報項目が生成される。ブロック３１１４においては、現在のスタックセグメント情報項目の傾向属性の値が、新しい季節的傾向情報項目に設定される。ブロック３１１６においては、（ブロック３０３４において参照された）ファイングレインセグメントリストにおける最後の既存エントリの値が、先行処理スタックセグメント情報項目の値と置換えられる。ブロック３１１８においては、現在のスタックセグメント情報項目がファイングレインセグメントリストに追加される。制御が図３Ｊのブロック３１６２に進められる。

ここで図３Ｇを参照すると、ブロック３１２０においては、現在のスタックセグメント情報項目が、現在のスタックフレーム情報項目の一体化セグメント属性の値に設定される。ブロック３１２２においては、現在のスタックセグメント情報項目が先行処理スタックセグメント情報項目に等しいかどうかが判断される。そうであれば、制御が次にブロック３１２４に進められる。そうでなければ、制御が図３Ｉのブロック３１４２に進められる。

ブロック３１２４においては、現在のスタックフレーム情報項目の先行処理属性リストが２つ以上のエントリを有するかどうかが判断される。そうであれば、制御が次にブロック３１２８に進められる。そうでない場合、制御はブロック３１２６に進められる。

ブロック３１２６においては、先行処理スタックフレーム情報項目の後続処理リスト属性が２つ以上のエントリを有するかどうかが判断される。そうであれば、制御が次にブロック３１２８に進められる。そうでなければ、制御が図３Ｊのブロック３１６２に進められる。

ブロック３１２８においては、現在のスタックセグメント情報項目のエレメントリスト属性における第１のエントリが、現在のスタックフレーム情報項目と同じであるかどうかが判断される。そうであれば、制御が次にブロック３１３０に進められる。そうでなければ、制御が図３Ｈのブロック３１３２に進められる。

ブロック３１３０においては、ファイングレインセグメントリストにおける先行処理スタックセグメント情報項目および現在のスタックセグメント情報項目を表わす再帰セグメントが更新される。一実施形態においては、この更新は、最後のセグメントが再帰セグメントである場合には、ファイングレインセグメントリストにおける最後のセグメントの再帰回数属性の値をインクリメントすることを含み得るか、または、最後のセグメントがスタックセグメントである場合には、ファイングレインセグメントリストの終わりに新しい再帰セグメントを追加することを含み得る。これらの変数についてのさらなる情報を図６Ａ〜図６Ｅの説明において以下に記載する。制御は図３Ｊのブロック３１６２に進められる。

ここで図３Ｈを参照すると、ブロック３１３２においては、現在のスタックセグメント情報項目のトレースセグメントは、先行処理スタックフレーム情報項目が第１の新しいスタックセグメント情報項目の終わりにくるように、かつ、現在のスタックフレーム情報項目が第２の新しいスタックセグメント情報項目の初めにくるように、先行処理スタックフレーム情報項目のインデックスと現在のスタックフレーム情報項目のインデックスとの間に発生する別個の第１および第２の新しいスタックセグメント情報項目に分割される。指定されたスタックフレームの前または後の分岐点においてスタックセグメントを分割するための技術は、図５Ａ〜図５Ｃに関連付けて以下に開示される。このシナリオにおいては、そのスタックセグメント分割技術は、このシナリオにおいて現在のスタックセグメント情報項目である指定されたスタックセグメント情報項目の（後ではなく）前に分割を実行するために呼び出すことができる。

ブロック３１３４においては、先行処理スタックセグメント情報項目は、ブロック３１３２の分割によって作成される第１の新しいスタックセグメント情報項目に設定される。ブロック３１３６においては、現在のスタックセグメント情報項目は、ブロック３１３２の分割によって作成される第２の新しいスタックセグメント情報項目に設定される。ブロック３１３８においては、（ブロック３０３４において参照された）ファイングレインセグメントリストにおける最後の既存エントリの値が、先行処理スタックセグメント情報項目の値と置換えられる。ブロック３１４０においては、現在のスタックセグメント情報項目がファイングレインセグメントリストに追加される。制御が図の３Ｊのブロック３１６２に進められる。

ここで図３Ｉを参照すると、ブロック３１４２においては、先行処理スタックセグメント情報項目のエレメントリスト属性の最後のエントリが、先行処理スタックフレーム情報項目と同じであるかどうかが判断される。そうであれば、制御が次にブロック３１５０に進められる。そうでない場合、制御はブロック３１４４に進められる。

ブロック３１４４においては、先行処理スタックセグメント情報項目のトレースセグメントは、先行処理スタックフレーム情報項目が第１の新しいスタックセグメント情報項目の終わりにくるように、先行処理スタックフレーム情報項目のインデックスと後続処理スタックフレーム情報項目のインデックスとの間に発生する別個の第１および第２の新しいスタックセグメント情報項目に分割される。指定されたスタックフレームの前または後における分岐点においてスタックセグメントを分割するための技術は、図５Ａ〜図５Ｃに関連付けて以下に開示される。このシナリオにおいては、そのスタックセグメント分割技術は、このシナリオにおいて先行処理スタックセグメント情報項目である指定されたスタックセグメント情報項目の（前ではなく）後に分割を実行するために呼び出すことができる。

ブロック３１４６においては、先行処理スタックセグメント情報項目は、ブロック３１４４の分割によって作成された第１の新しいスタックセグメント情報項目に設定される。ブロック３１４８においては、（ブロック３０３４において参照された）ファイングレインセグメントリストにおける最後の既存エントリの値が、先行処理スタックセグメント情報項目の値と置換えられる。制御がブロック３１５０に進められる。

ブロック３１５０においては、現在のスタックセグメント情報項目のエレメントリスト属性の最後のエントリが現在のスタックフレーム情報項目と同じであるかどうかが判断される。そうであれば、制御が次にブロック３１５６に進められる。そうでない場合、制御はブロック３１５２に進められる。

ブロック３１５２においては、現在のスタックセグメント情報項目のトレースセグメントは、現在のスタックフレーム情報項目が第２の新しいスタックセグメント情報項目の初めにくるように、先行するスタックフレーム情報項目のインデックスと現在のスタックフレーム情報項目のインデックスとの間に発生する別個の第１および第２の新しいスタックセグメント情報項目に分割される。指定されたスタックフレームの前または後における分岐点においてスタックセグメントを分割するための技術は、図５Ａ〜図５Ｃに関連付けて以下に開示される。このシナリオにおいては、そのスタックセグメント分割技術は、このシナリオにおいて現在のスタックセグメント情報項目である指定されたスタックセグメント情報項目の（後ではなく）前に分割を実行するために呼び出すことができる。

ブロック３１５４においては、現在のスタックセグメント情報項目は、ブロック３１５２の分割によって作成された第２の新しいスタックセグメント情報項目に設定される。制御がブロック３１５６に進められる。

ブロック３１５６においては、現在のスタックセグメント情報項目が（ブロック３０３４において参照された）ファイングレインセグメントリストに追加される。ブロック３１５８においては、先行処理スタックセグメント情報項目が、現在のスタックセグメント情報項目の先行処理リスト属性に追加される。ブロック３１６０においては、現在のスタックセグメント情報項目が、先行処理スタックセグメント情報項目の後続処理リストエレメントに追加される。制御が図３Ｊのブロック３１６２に進められる。

ここで図３Ｊを参照すると、ブロック３１６２においては、現在のスタックトレースエレメントが現在のスタックトレースの一番上にあるかどうかが判断される。この判断は、スタックトレースエレメントインデックスが現在のスタックトレースサイズよりも１だけ小さいものに等しいかどうかを判断することによって行なわれてもよい。スタックトレースエレメントインデックスが現在のスタックトレースサイズよりも１だけ小さいものに等しい場合、現在のスタックトレースエレメントは現在のスタックトレースの初めに位置する。現在のスタックトレースエレメントが現在のスタックトレースの初めに位置する場合、次いで、制御がブロック３１６４に進められる。そうでない場合、制御はブロック３１６６に進められる。

ブロック３１６４においては、現在のスタックセグメント情報項目は、現在のスタックトレースにおいて一番上にあるセグメントとしてマーク付けされる。これは、現在のスタックセグメント情報項目の後続処理リスト属性に「ＳＥＧＭＥＮＴ＿ＣＥＩＬＩＮＧ」などの一定のスタックセグメント情報項目を追加することによって達成されてもよい。現在のスタックセグメント情報項目は、「ＳＥＧＭＥＮＴ＿ＣＥＩＬＩＮＧ」の先行処理リスト属性に追加することができる。制御がブロック３１６６に進められる。

ブロック３１６６においては、いずれかのスタックトレースエレメントが現在のスタックトレースにおける現在のスタックトレースエレメントの上に存在しているかどうかが判断される。そうであれば、制御が次にブロック３１６８に進められる。そうでない場合、制御はブロック３１７０に進められる。

ブロック３１６８においては、現在のスタックトレースエレメントは、現在のスタックトレースにおける現在のスタックトレースエレメントの真上に存在するスタックトレースエレメントに設定される。制御が図３Ｂのブロック３０４２に進められる。

ブロック３１７０においては、現在のスレッド情報項目のファイングレインセグメントが一体化される。指定されたファイングレインセグメントリストにおいて与えられたファイングレインセグメントを一体化するための技術を、図６Ａ〜図６Ｅに関連付けて以下に開示する。図６Ａ〜図６Ｅに関連付けて開示される技術は、一体化されたセグメントのセットを生成する。ブロック３１７２においては、現在のスレッド情報項目のためにこのように作成された一体化されたセグメントにセットが格納される。

ブロック３１７４においては、（ブロック３００２において参照された）スレッド分類情報項目が、現在のスタックトレースおよび（ブロック３１７２において格納された）１一体化されたセグメントのセットに関して登録される。指定されたスタックトレースおよび一体化されたセグメントの指定されたセットについてのスレッド分類項目を登録するための技術は、図７Ａおよび図７Ｂに関連付けて以下に開示される。図７Ａおよび図７Ｂに関連付けて開示された技術によって、スレッド分類情報項目を生成する。ブロック３１７６においては、現在のスタックトレースおよび（ブロック３１７２において格納された）一体化されたセグメントのセットのためにこのように作成されたスレッド分類情報項目が格納される。

ブロック３１７８においては、（ブロック３１７６において格納された）スレッド分類情報項目についてのスレッド分類統計が更新される。指定されたスレッド分類情報項目についてのスレッド分類統計を更新するための技術が、図８に関連付けて以下に開示される。

ブロック３１８０においては、スレッド分類情報項目が（ブロック３００２において参照された）スレッド分類情報項目のセットに追加される。制御が図３Ａのブロック３００４に戻される。

図３Ａを再び参照すると、ブロック３１８２においては、スレッド分類項目のセットが生成されると、図３Ａ〜図３Ｊに例示される技術が完了する。

季節的傾向把握フィルタの適用
図４は、本発明の実施形態に従った、季節的傾向把握フィルタを適用するための技術の一例を示すフロー図である。ブロック４０２においては、スタックセグメント情報マップにおける未処理のスタックセグメント情報項目が処理されないまま残っているかどうかが判断される。そうであれば、制御が次にブロック４０４に進められる。そうでなければ、図４に例示される技術が終了する。

ブロック４０４においては、現在のスタックセグメント情報項目は、スタックセグメント情報マップにおける次の未処理のスタックセグメント情報項目に設定される。ブロック４０６においては、ホルト・ウィンタース三重指数フィルタが、現在のスタックセグメント情報項目の傾向属性の値である季節的傾向情報項目に適用される。ブロック４０８においては、Ｎステップ（この場合、Ｎは１，２，…）の予測が計算される。ブロック４１０においては、予測の正規化残差が計算される。ブロック４１２においては、通常の残差が指定されたカットオフを上回っているかどうかが判断される。そうであれば、制御が次にブロック４１４に進められる。そうでない場合、制御はブロック４２２に進められる。

ブロック４１４においては、測定されたスレッドまたはスタックセグメントの強度が指定されたマージンよりも大きなマージンだけ予測を上回っているかどうかが判断される。そうであれば、制御が次にブロック４１６に進められる。そうでない場合、制御はブロック４１８に進められる。

ブロック４１６においては、ハイパーテンション状態についての警告が発行される。制御がブロック４２２に進められる。

ブロック４１８においては、測定されたスレッドまたはスタックセグメントの強度が指定されたマージンよりも大きなマージンだけ予測を下回っているかどうかが判断される。そうであれば、制御が次にブロック４２０に進められる。そうでない場合、制御はブロック４２２に進められる。

ブロック４２０においては、ハイポテンション状態についての警告が発行される。制御がブロック４２２に進められる。

ブロック４２２においては、非季節化された傾向が計算される。ブロック４２４においては、傾向が季節指数に応じて調整される。ブロック４２６においては、予測された計画対象期間（time horizon）の信頼レベルが計算される。ブロック４２８においては、予測された計画対象期間の信頼レベルが指定されたしきい値を上回っているかどうかが判断される。そうであれば、制御が次にブロック４３０に進められる。そうでなければ、制御がブロック４０２に進められる。

ブロック４３０においては、計画対象期間における飽和またはエンドポイント状態についての警告が発行される。制御がブロック４０２に進められる。

スタックフレームの前または後における分岐点でのスタックセグメントの分割
図５Ａ〜図５Ｃは、本発明の実施形態に従った、スタックフレームの前または後における分岐点でスタックセグメントを分割するための技術の一例を示すフロー図である。当該技術は、指定されたスタックセグメント情報項目および対応する指定されたスタックフレーム情報項目に対して実行することができる。当該技術は、指定されたスタックフレーム情報項目によって表わされるスタックフレームの前または後に分割を実行するための指示を呼び出すことができる。当該技術は、分割によってもたらされる１対（第１および第２）の新しいスタックセグメント情報項目を生成することができる。まず図５Ａを参照すると、ブロック５０２において、現在のエレメントリストは、指定されたスタックセグメント情報項目のエレメントリスト属性の値に設定される。ブロック５０４においては、スタックフレーム情報インデックスは、現在のエレメントリストの範囲内における指定されたスタックフレーム情報項目のインデックスに設定される。ブロック５０６においては、指定されたスタックフレームの前に分割が実行されるよう指示されているかどうかが判断される。そうであれば、制御がブロック５０８に進められる。そうでない場合、制御はブロック５１２に進められる。

ブロック５０８においては、第１のセグメントは、現在のエレメントリストの初めから、スタックフレーム情報インデックスよりも１だけ小さいインデックスを有するエレメントにまでわたる現在のエレメントリストのサブリストに設定される。ブロック５１０においては、第２のセグメントは、スタックフレーム情報インデックスを有するエレメントから現在のエレメントリストの終わりにまでわたる現在のエレメントリストのサブリストに設定される。制御がブロック５１６に進められる。

ブロック５１２においては、第１のセグメントは、現在のエレメントリストの初めからスタックフレーム情報インデックスを有するエレメントにまでわたる現在のエレメントリストのサブリストに設定される。ブロック５１４においては、第２のセグメントは、スタックフレーム情報インデックスよりも１だけ大きいインデックスを有するエレメントから現在のエレメントリストの終わりにまでわたる現在のエレメントリストのサブリストに設定される。制御がブロック５１６に進められる。

ブロック５１６においては、新しい先行処理スタックセグメント情報項目が作成される。ブロック５１８においては、新しい先行処理スタックセグメント情報項目のエレメントリスト属性は第１のセグメントに設定される。ブロック５２０においては、第１のセグメントにおける先行処理スタックフレーム情報項目ごとに、先行処理スタックフレーム情報項目の一体化セグメント属性が、新しい先行処理スタックセグメント情報項目に設定される。その一体化セグメント属性の値が、分割されている指定されたスタックセグメント情報項目にそのときまで等しくなかった場合、例外とすることができる。制御が図５Ｂのブロック５２２に進められる。

ここで図５Ｂを参照すると、ブロック５２２においては、新しい後続処理スタックセグメント情報項目が作成される。ブロック５２４においては、新しい後続処理スタックセグメント情報項目のエレメントリスト属性が、第２のセグメントに設定される。ブロック５２６においては、第２のセグメントにおける後続処理スタックフレーム情報項目ごとに、後続処理スタックフレーム情報項目の一体化セグメント属性が、新しい後続処理スタックセグメント情報項目に設定される。その一体化セグメント属性の値が、分割されている指定されたスタックセグメント情報項目にそのときまで等しくなかった場合、例外とすることができる。

ブロック５２８においては、分割されている指定されたスタックセグメント情報項目の先行処理リスト属性におけるエレメントのすべてが、先行処理スタックセグメント情報項目の先行処理リスト属性に追加される。ブロック５３０においては、後続処理スタックセグメント情報項目が、先行処理スタックセグメント情報項目の後続処理リスト属性に追加される。ブロック５３２においては、先行処理スタック情報項目が、後続処理スタックセグメント情報項目の先行処理リスト属性に追加される。ブロック５３４においては、分割されている指定されたスタックセグメント情報項目の後続処理リスト属性におけるエレメントのすべてが、後続処理スタックセグメント情報項目の後続処理リスト属性に追加される。

ブロック５３６においては、季節的傾向情報項目は、分割されている指定されたスタックセグメント情報項目の季節的傾向情報属性のクローンに設定される。ブロック５３８においては、先行処理スタックセグメント情報項目の傾向属性は、季節的傾向情報項目のクローンに設定される。ブロック５４０においては、後続処理スタックセグメント情報項目の傾向属性は、季節的傾向情報項目に設定される。制御が図５Ｃのブロック５４２に進められる。

ここで図５Ｃを参照すると、ブロック５４２においては、先行処理スタックセグメント情報項目の発生回数属性は、分割されている指定されたスタックセグメント情報項目の発生回数属性の値に設定される。先行処理スタックセグメント情報項目の合計発生回数属性は、分割されている指定されたスタックセグメント情報項目の合計発生回数属性の値に設定される。ブロック５４４においては、後続処理スタックセグメント情報項目の発生回数属性は、分割されている指定されたスタックセグメント情報項目の発生回数属性の値に設定される。後続処理スタックセグメント情報項目の合計発生回数属性はまた、分割されている指定されたスタックセグメント情報項目の合計発生回数属性の値に設定され得る。

ブロック５４６においては、指定されたスタックセグメント情報項目の第１のセグメント属性は、先行処理スタックセグメント情報項目に設定される。ブロック５４８においては、指定されたスタックセグメント情報項目の第２のセグメント属性は、後続処理スタックセグメント情報項目に設定される。ブロック５５０においては、先行処理スタック情報項目の一体化セグメント属性は、指定されたスタックセグメント情報項目に設定される。ブロック５５２においては、後続処理スタック情報項目の一体化セグメント属性は、指定されたスタックセグメント情報項目に設定される。ブロック５５４においては、先行処理スタックセグメント情報項目および後続処理スタック情報項目が、分割によって生成される新しい第１および第２のスタックセグメント情報項目として生成されていれば、当該技術が終了する。

スレッドのスタックセグメントの一体化
図６Ａ〜図６Ｅは、本発明の実施形態に従った、スレッドのスタックセグメントを一体化するための技術の一例を示すフロー図である。当該技術は、指定されたファイングレインセグメントリストに対して実行することができる。当該技術は、一体化されたセグメントのセットを生成することができる。まず図６Ａを参照すると、ブロック６０２においては、セグメント情報項目の空の一体化されたセグメントリストが作成される。ブロック６０４においては、現在のインデックスの値は、指定されたファイングレインセグメントリストのサイズよりも１だけ小さいものに設定される。ブロック６０６においては、最後のセグメントは、指定されたファイングレインセグメントリストにおける現在のインデックスを有するセグメントに設定される。ブロック６０８においては、現在のインデックスの値がデクリメントされる。ブロック６１０においては、現在のインデックスが０未満であるかどうかが判断される。そうであれば、制御が次にブロック６９２に進められる。そうでない場合、制御はブロック６１２に進められる。

ブロック６１２においては、先行処理セグメントは、指定されたファイングレインセグメントリストにおける現在のインデックスを有するセグメントに設定される。ブロック６１４においては、最後のセグメントが先行処理セグメントと一体化されるかどうかを示すフラグは、真に設定される。ブロック６１６においては、最後のセグメントおよび先行処理セグメントの両方が再帰セグメントであるかどうかが判断される。そうであれば、先行処理再帰セグメントの分類属性が最後の再帰セグメントの分類属性と同じであるかどうかが比較される。再帰セグメントの分類属性はブロック６３４および６７０において参照される。一実施形態においては、この判断は、最後のセグメントおよび先行処理セグメントの両方が再帰セグメント情報クラスのインスタンスであるかどうかを判断することによって達成される。両方のセグメントが再帰セグメントであれば、先行処理再帰セグメントの分類属性を最後の再帰セグメントの分類属性と比較する。両方の属性値が同じであれば、制御がブロック６１８に進められる。そうでなければ、制御は図６Ｂのブロック６２０に進められる。

ブロック６１８においては、最後のセグメントの再帰回数属性の値を、先行処理セグメントの再帰回数属性の値だけ増大させる。制御が図６Ｃのブロック６４６に進められる。

ここで図６Ｂを参照すると、ブロック６２０においては、最後のセグメントが再帰セグメントであるかどうかと、先行処理セグメントがスタックセグメントであるかどうかとが判断される。そうであれば、次に、最後の再帰セグメントの分類属性を先行処理セグメントの値と比較する。再帰セグメントの分類属性は、図６Ｂのブロック６３４および図６Ｄのブロック６７０において参照される。最後のセグメントの分類属性の値が先行処理セグメントの値と同じである場合、制御がブロック６２２に進められる。そうでない場合、制御はブロック６２４に進められる。

ブロック６２２においては、最後のセグメントの再帰回数属性の値がインクリメントされる。制御が図６Ｃのブロック６４６に進められる。

ブロック６２４においては、先行処理セグメントが再帰セグメントであるかどうかと、最後のセグメントがスタックセグメントであるかどうかとが判断される。そうであれば、次いで、先行処理再帰セグメントの分類属性を最後のセグメントの値と比較する。再帰セグメントの分類属性が、図６Ｂのブロック６３４および図６Ｄのブロック６７０において参照される。先行処理セグメントの分類属性の値が最後のセグメントの値と同じである場合、制御がブロック６２６に進められる。そうでない場合、制御はブロック６３０に進められる。

ブロック６２６においては、最後のセグメントは先行処理セグメントに設定される。ブロック６２８においては、最後のセグメントの再帰回数属性の値がインクリメントされる。制御が図６Ｃのブロック６４６に進められる。

ブロック６３０においては、先行処理セグメントが最後のセグメントに等しいかどうかが判断される。そうであれば、制御が次にブロック６３２に進められる。そうでなければ、制御が図６Ｃのブロック６４０に進められる。

ブロック６３２においては、新しい再帰セグメント情報項目が作成される。ブロック６３４においては、新しい再帰セグメント情報項目の分類属性は、最後のセグメントに設定される。いくつかの実施形態においては、この分類属性は、２つの隣接する再帰セグメントが分類属性によって示される同じセグメントの再帰を表わすかどうかについての判断の一環としてチェックすることができ、結果として、隣接する再帰セグメントは、図６Ａのブロック６１６および図６Ｂのブロック６２０および６２４において参照されるように、１つの再帰セグメントに一体化することができる。ブロック６３６においては、新しい再帰セグメント情報項目の再帰回数属性の値が２に設定される。ブロック６３８においては、最後のセグメントが、新しい再帰セグメント情報項目に設定される。制御が図６Ｃのブロック６４６に進められる。

ここで図６Ｃを参照すると、ブロック６４０においては、最後のセグメントおよび先行処理セグメントを一体化することができるかどうかが判断される。一実施形態においては、以下の（１）から（４）のすべてが真であれば、最後のセグメントおよび先行処理セグメントを一体化することができる。（１）各々の一体化セグメント属性の値が同じである；（２）各々の一体化セグメント属性の値が非ヌルである；（３）先行処理セグメントの一体化セグメント属性の第１のセグメント属性の値が先行処理セグメントである；および（４）最後のセグメントの一体化セグメント属性の第２のセグメント属性の値が最後のセグメントである。ある実施形態においては、２つの隣接するセグメントは、それらが図５Ｃのブロック５４６、５４８、５５０および５５２によって同じ一体化セグメントから分割されている場合、一体化することができる。言いかえれば、上述の条件（１）および（２）では、ブロック５５２および５５４の効果をテストし、条件（３）では、ブロック５４６の効果をテストし、条件（４）では、ブロック５４８の効果をテストする。最後のセグメントおよび先行処理セグメントを一体化することができれば、制御がブロック６４２に進められる。そうでない場合、制御はブロック６４４に進められる。

ブロック６４２においては、最後のセグメントは、最後のセグメントの一体化セグメント属性に設定される。制御がブロック６４６に進められる。

ブロック６４４においては、最後のセグメントが先行処理セグメントと一体化されるかどうかを示す（ブロック６１４において参照された）フラグが偽に設定される。制御がブロック６４６に進められる。

ブロック６４６においては、最後のセグメントが先行処理セグメントと一体化されているかどうかを示す（ブロック６１４において参照された）フラグが真であるかどうかが判断される。そうであれば、制御がブロック６４８に進められる。そうでなければ、制御は図６Ｅのブロック６８８に進められる。

ブロック６４８においては、後続処理セグメントは、（ブロック６０２において参照された）一体化されたセグメントリストにおける最後のセグメントの後続処理に設定される。ブロック６５０においては、最後のセグメントが後続処理セグメントと一体化されているかどうか示すフラグが真に設定される。ブロック６５２においては、最後のセグメントおよび後続処理セグメントがともに再帰セグメントであるかどうかが判断される。そうであれば、次いで、後続処理再帰セグメントの分類属性が最後の再帰セグメントの分類属性と同じであるかどうかを比較する。再帰セグメントの分類属性がブロック６３４および６７０において参照される。そうであれば、制御がブロック６５４に進められる。そうでなければ、制御が図６Ｄのブロック６５６に進められる。

ブロック６５４においては、最後のセグメントの再帰回数属性の値を、後続処理セグメントの再帰回数属性の値だけ増大させる。制御が図６Ｅのブロック６８２に進められる。

ここで図６Ｄを参照すると、ブロック６５６においては、最後のセグメントが再帰セグメントであるかどうかと、後続処理セグメントがスタックセグメントであるかどうかとが判断される。そうであれば、次いで、最後の再帰セグメントの分類属性を後続処理セグメントの値と比較する。再帰セグメントの分類属性は、図６Ｂのブロック６３４および図６Ｄのブロック６７０において参照される。最後のセグメントの分類属性の値が後続処理セグメントの値と同じである場合、制御はブロック６５８に進められる。そうでない場合、制御はブロック６６０に進められる。

ブロック６５８においては、最後のセグメントの再帰回数属性の値がインクリメントされる。制御が図６Ｅのブロック６８２に進められる。

ブロック６６０においては、後続処理セグメントが再帰セグメントであるかどうかと、最後のセグメントがスタックセグメントであるかどうかとが判断される。そうであれば、次いで、後続処理再帰セグメントの分類属性を最後のセグメントの値と比較する。再帰セグメントの分類属性は、図６Ｂのブロック６３４および図６Ｄのブロック６７０において参照される。後続処理セグメントの分類属性の値が最後のセグメントの値と同じである場合、制御がブロック６６２に進められる。そうでない場合、制御がブロック６６６に進められる。

ブロック６６２においては、最後のセグメントは後続処理セグメントに設定される。ブロック６６４においては、最後のセグメントの再帰回数属性の値がインクリメントされる。制御が図６Ｅのブロック６８２に進められる。

ブロック６６６においては、後続処理セグメントが最後のセグメントに等しいかどうかが判断される。そうであれば、制御がブロック６６８に進められる。そうでなければ、制御は図６Ｅのブロック６７６に進められる。

ブロック６６８においては、新しい再帰セグメント情報項目が作成される。ブロック６７０においては、新しい再帰セグメント情報項目の分類属性は、最後のセグメントに設定される。いくつかの実施形態においては、この分類属性は、２つの隣接する再帰セグメントが分類属性によって示されるのと同じセグメントの再帰を表わすかどうかを判断する一環としてチェックすることができ、結果として、図６Ａのブロック６１６および図６Ｂのブロック６２０および６２４において参照されるように、隣接する再帰セグメントは１つの再帰セグメントに一体化することができる。ブロック６７２においては、新しい再帰セグメント情報項目の再帰回数属性の値が２に設定される。ブロック６７４においては、最後のセグメントは、新しい再帰セグメント情報項目に設定される。制御は、図６Ｅのブロック６８２に進められる。

ここで図６Ｅを参照すると、ブロック６７６においては、最後のセグメントおよび後続処理セグメントを一体化することができるかどうかが判断される。一実施形態においては、以下の（１）から（４）のすべてが真であれば、最後のセグメントおよび後続処理セグメントを一体化することができる。（１）各々の一体化セグメント属性の値が同じである；（２）各々の一体化セグメント属性の値が非ヌルである；（３）最後のセグメントの一体化セグメント属性の第１のセグメント属性の値が最後のセグメントである；および（４）後続処理セグメントの一体化セグメント属性の第２のセグメント属性の値が後続処理セグメントである。ある実施形態においては、２つの隣接するセグメントは、これらが図５Ｃのブロック５４６、５４８、５５０および５５２よって同じ一体化セグメントから分割されている場合、一体化することができる。言いかえれば、上述の条件（１）および（２）では、ブロック５５２および５５４の効果をテストし、条件（３）では、ブロック５４６の効果をテストし、条件（４）では、ブロック５４８の効果をテストする。最後のセグメントおよび後続処理セグメントを一体化することができれば、制御がさらにブロック６７８に進められる。そうでない場合、制御はブロック６８０に進められる。

ブロック６７８においては、最後のセグメントは、最後のセグメントの一体化セグメント属性の値に設定される。制御が図６Ｅのブロック６８２に進められる。

ブロック６８０においては、最後のセグメントが後続処理セグメントと一体化されるかどうか示す（ブロック６５０において参照された）フラグが偽に設定される。制御がブロック６８２に進められる。

ブロック６８２においては、最後のセグメントが後続処理セグメントと一体化されるかどうかを示す（ブロック６５０において参照された）フラグが真であるかどうかが判断される。そうであれば、制御がブロック６８４に進められる。そうでない場合、制御はブロック６９０に進められる。

ブロック６８４においては、後続処理セグメントが（ブロック６０２において参照された）一体化されたセグメントリストから除去される。ブロック６８６においては、後続処理セグメントは、一体化されたセグメントリストにおける最後のセグメントの後続処理に設定される。制御がブロック６９０に進められる。

ブロック６８８においては、最後のセグメントが（ブロック６０２において参照された）一体化されたセグメントリストの初めに追加される。制御がブロック６９０に進められる。

ブロック６９０においては、現在のインデックスの値がデクリメントされる。制御が図６Ａのブロック６１０に進められる。

再び図６Ａを参照すると、ブロック６９２においては、最後のセグメントが（ブロック６０２において参照された）一体化されたセグメントリストの一番下に追加される。ブロック６９４においては、一体化されたセグメントのセットが一体化されたセグメントリストの形で生成されていれば、当該技術が終了する。

スタックトレースおよびスレッドの一体化されたセグメントについてのスレッド分類シグネチャの登録
図７Ａおよび図７Ｂは、本発明の実施形態に従った、指定されたスタックトレースおよび一体化されたセグメントの指定されたセットについてのスレッド分類項目を登録するための技術の一例を示すフロー図である。当該技術は、指定されたスタックトレースおよび一体化されたセグメントの指定されたセットに対して実行することができる。当該技術ではスレッド分類情報項目を生成することができる。まず図７Ａを参照すると、ブロック７０２において、スタックフレームの数が、指定されたスタックトレースのサイズに設定される。ブロック７０４においては、一体化されたセグメントの数は、一体化されたセグメントの指定されたセットのサイズに設定される。ブロック７０６においては、指定されたスタックトレースに対応するスレッドを表わすためにスレッド分類情報項目が登録されたかどうかを示すフラグが偽に設定される。ブロック７０８においては、いずれかの未処理の登録されたスレッド分類情報項目がスレッド分類情報マップに残っているかどうかが判断される。そうであれば、制御がブロック７１０に進められる。そうでなければ、制御は図７Ｂのブロック７２０に進められる。

ブロック７１０においては、現在の登録されたスレッド分類情報項目は、スレッド分類情報マップにおける次の未処理の登録されたスレッド分類情報項目に設定される。ブロック７１２においては、（１）スタックフレームの数が現在の登録されたスレッド分類情報項目のスタックフレーム属性の数に等しいかどうかと、（２）一体化されたセグメントの数が、現在の登録されたスレッド分類情報項目の一体化されたセグメント属性の数に等しいかどうかとが判断される。そうであれば、制御がブロック７１４に進められる。そうでなければ、制御は図７Ｂのブロック７２０に進められる。

ブロック７１４においては、インデックス値ごとに、そのインデックス値を有する一体化されたセグメントのセグメントが、現在の登録されたスレッド分類情報項目におけるそのインデックス値を有するセグメント属性に等しいかどうかが判断される。そうであれば、制御がブロック７１６に進められる。そうでなければ、制御はブロック７０８に戻される。

ブロック７１６においては、スレッド分類情報項目は、現在の登録されたスレッド分類情報項目に設定される。ブロック７１８においては、指定されたスタックトレースに対応するスレッドを表わすためにスレッド分類情報項目が登録されたかどうかを示す（ブロック７０６において参照された）フラグが真に設定される。制御がブロック７２０に進められる。

ここで図７Ｂを参照すると、ブロック７２０においては、指定されたスタックトレースに対応するスレッドを表わすためにスレッド分類情報項目が登録されたかどうか示す（ブロック７０６において参照された）フラグが真であるかどうかが判断される。そうであれば、制御がブロック７３４に進められる。そうでない場合、制御はブロック７２２に進められる。

ブロック７２２においては、新しいスレッド分類情報項目が作成される。ブロック７２４においては、新しいスレッド分類情報項目のセグメント属性が、一体化されたセグメントの指定されたセットに設定される。ブロック７２６においては、新しいスレッド分類情報項目の傾向属性が新しい季節的傾向情報項目に設定される。ブロック７２８においては、新しいスレッド分類情報項目のスタックフレーム数の属性は、スタックフレームの数に設定される。ブロック７３０においては、新しいスレッド分類情報項目の一体化されたセグメント数の属性は、一体化されたセグメントの数に設定される。ブロック７３２においては、新しいスレッド分類情報項目がスレッド分類情報マップに追加される。この追加により、指定されたスタックトレースに対応するスレッドによって表わされるスレッドの同等クラスについてのシグネチャを表わすために、新しいスレッド分類情報項目が登録される。制御がブロック７３４に進められる。

ブロック７３４においては、スレッド分類情報項目が生成されていれば、当該技術は終了する。

スタック分類統計の更新
図８は、本発明の実施形態に従った、指定されたスレッド分類情報項目についてのスレッド分類統計を更新するための技術の一例を示すフロー図である。当該技術は、指定されたスレッド分類情報項目に対して実行することができる。ブロック８０２においては、指定されたスレッド分類情報項目の発生回数属性の値がインクリメントされる。指定されたスレッド分類情報項目の合計発生回数属性の値もインクリメントすることができる。ブロック８０４においては、いずれかの未処理のセグメント情報項目が指定されたスレッド分類情報項目に残っているかどうかが判断される。そうであれば、制御が次にブロック８０６に進められる。そうでなければ、当該技術は終了する。

ブロック８０６においては、現在のセグメント情報項目は、指定されたスレッド分類情報項目における次の未処理のセグメント情報項目に設定される。ブロック８０８においては、現在のセグメント情報項目についてのスタックセグメント統計が更新される。指定されたセグメント情報項目についてのスタックセグメント統計を更新するための技術が、図９に関連付けて以下に開示される。制御がブロック８０４に戻される。

スタックセグメント統計の更新
図９は、本発明の実施形態に従った、指定されたセグメント情報項目についてのスタックセグメント統計を更新するための技術の一例を示すフロー図である。当該技術は、指定されたセグメント情報項目に対して実行することができる。ブロック９０２においては、指定されたセグメント情報項目の発生回数属性の値がインクリメントされる。指定されたセグメント情報項目の合計発生回数属性の値もインクリメントすることができる。ブロック９０４においては、いずれかの未処理のセグメント情報項目が指定されたセグメント情報項目に残っているかどうかが判断される。そうであれば、制御が次にブロック９０６に進められる。そうでなければ、当該技術が終了する。

ブロック９０６においては、現在のセグメント情報項目は、指定されたセグメント情報項目における次の未処理のセグメント情報項目に設定される。ブロック９０８においては、現在のセグメント情報項目についてのスタックセグメント統計が図９のこの技術を用いて更新される。制御がブロック９０４に進められる。

Ｊａｖａヒープサイズ、スレッド強度およびスタックセグメント強度測定値に基づいた季節的傾向把握および予測
ＪＡＶＡプラットフォームサービスのためのクラウド制御システムは、傾向を推定し、かつメモリ容量要件を予測するために、ＪＡＶＡヒープ割当てについての時系列データを監視することができる。季節的傾向を検出し、メモリ容量要件を予測することによって、システムは、リソース割当ての融通性を可能にするように、共有されるシステムメモリを動的にＪＶＭ間で再割当てることができる。容量要件の予測は、ＪＡＶＡヒープ成長率の推定を含む。Ｊａｖａヒープ割当ては、不規則な時間間隔で実行されるフルガーベッジコレクションサイクルによって測定される。ＪＡＶＡヒープ成長率の推定は、断続的に任意に０付近になる不規則な時間間隔によって複雑になる、ランダム時間間隔による分割を含む。成長率測定中のノイズは２つのガウス分布の比であって、これがコーシー分布をもたらしてフィルタリングを困難にしてしまう可能性がある。コーシー分布の平均および標準偏差は規定されていないが、これは、多数のデータポイントにより、単一のデータポイントの場合よりも正確に平均および標準偏差が推定されるわけではないからである。サンプルのプールを増加させることにより、時間近接間隔による分割に対応する大きな絶対値を有するサンプルポイントに遭遇する可能性が高くなるかもしれない。フルガーベッジコレクションサイクルが不規則なために不規則になってしまうサンプリング間隔を有するＪＡＶＡヒープサイズ測定とは異なり、スレッドまたはスタックセグメントの強度測定値は、時間近接間隔を回避するために一定間隔でサンプリングすることができる。そうであっても、ＪＡＶＡヒープ割当ての傾向把握のためのこの明細書中に記載された同じ技術は、スレッドおよびスタックセグメントの強度測定値についての季節的傾向把握および予測に適用することができる。当該技術は、スレッドのＣＰＵスケジューリングおよびフルＧＣサイクルの干渉により可変レイテンシに合わせて調整することができる。これにより、サンプリングスレッドのレイテンシに付加的なばらつきが加わる。当該技術はまた、スタックセグメントを分類するのに必要な可変計算時間により可変サンプリング間隔に合わせて調整することができる。

１９５７年および１９６０年に公開されたホルト・ウィンタース三重指数フィルタは、季節的傾向把握および予測のために用いることができる。Ｃ．Ｃ．ホルト（Ｃ．Ｃ．Ｈｏｌｔ）による「指数加重平均による傾向および季節の予測（Forecasting Trends and Seasonal by Exponentially Weighted Averages）」（海軍研究事務所の備忘録（Office of Naval Research Memorandum）、第５２号、１９５７年）がこの明細書中に引用によって援用されている。Ｐ．Ｒ．ウィンタース（Ｐ．Ｒ．Ｗｉｎｔｅｒｓ）による「指数加重移動平均による販売予測（Forecasting Sales by Exponentially Weighted Moving Averages）」（マネジメントサイエンス（Management Science）、第６巻、第３号３２４頁〜３４２頁、１９６０年）が、引用によりこの明細書中に援用されている。ライト（Ｗｒｉｇｈｔ）は、不規則な時間間隔をサポートするために１９８６年にホルト・ウィンタース法を拡張させた。Ｄ．Ｊ．ライト（Ｄ．Ｊ．Ｗｒｉｇｈｔ）による「ホルト法の拡張を用いた不規則な時間間隔で公開されたデータの予測（Forecasting data published at irregular time intervals using an extension of Holt's method）」（マネジメントサイエンス；第３２巻；第４号４９９頁〜５１０頁；１９８６年））が引用によりこの明細書中に援用される。２００８年に、ハンザック（Ｈａｎｚａｋ）が時間近接間隔のための調整因子を提案した。Ｔ．Ｈａｎｚａｋは、「不規則な時系列のためのホルト法の改善（Improved Holt Method for Irregular Time Series）」（ＷＤＳ’０８議事録（WDS'08 Proceedings）、第１部、６２頁〜６７頁、２００８年）が引用によりこの明細書中に援用される。

時間近接間隔についての調整因子は、率推定の際にランダムな時間近接間隔に起因するノイズの相対強度の上昇分を補償するよう意図されたものであるが、時間間隔がメモリリークまたはデッドロックによって引起こされた輻輳中に単調に減少する場合、不注意に変化推定率を減衰させることができる。フルガーベッジコレクションアルゴリズムのヒープの合計サイズに対する多項式時間複雑性により、結果として、輻輳が悪化するのに応じて、ＪＶＭ実行時間間隔が短くなり得る。ＪＡＶＡメモリリークの場合、時間間隔が短くなるのに応じて、実行時間が短くなる可能性があるが、測定時間は長くなる可能性がある。なぜなら、ＪＶＭがフルガーベッジコレクションのためにより長く固定され得る（frozen）からである。ＪＶＭがフルガーベッジコレクション中に固定される場合、新しい要求をＪＶＭの外部で列に並べることができ、いくらかの部分が他のＪＶＭに再配分され得る。バックログは、後の実行時間中にヒープ使用量の変化率を加速させることができる。一実施形態においては、時間近接間隔のためのＨａｎｚａｋの調整が、ＪＡＶＡヒープ割当ての傾向把握および予測のために用いられ、加速するヒープ成長率を追跡するために用いられる。

一実施形態においては、指数移動平均を適用して、フルガーベッジコレクションサイクルから時系列データを平滑化することにより、成長率、成長率の加速、季節的傾向、予測の誤差残差および予測の絶対偏差を推定して、ＪＡＶＡメモリヒープ割当てのアウトライア検出および予測を可能にし得る。本発明の実施形態は、輻輳による成長率の加速を追跡することができる。この明細書中に開示される新しい調整因子は、測定時間が長くなると、より多くの重みをより新しいサンプルポイントに与える。これらの調整因子は、測定時間が無視できる些細な定数であり、時間間隔がほとんど実行時間に含まれる場合、Ｈａｎｚａｋの調整因子に変換することができる。本発明の実施形態は、数値安定性のために、すなわち、倍精度浮動小数点表現のアンダフローを回避するために、時間の適応的スケーリングを含み得る。時間間隔は、平均時間間隔が１付近にまでスケーリングされるように、比例的に適応的にスケーリングされ得る。推定は、さまざまな時間スケールで実行される３つ以上の独立したフィルタによって並列に追跡することができる。時間スケールに応じて、これらの平行なフィルタは、季節的傾向、長期的な容量需要、短期のエンドポイント（メモリー不足誤差）などを予測するための複数のポリシーとしての役割を果たすことができる。本発明の実施形態は、季節指標化のための改善された方法を利用して、隣接するインデックスの中から、正規化された誤差残差を最小限にする季節指数を選択する。本発明の実施形態は監視制御ループを適用して、（テナント、アプリケーション、ユーザなどの動作特徴を取り込んだ）ＪＶＭインスタンスごとに非線形回帰によってモデルを適合させて、さまざまなフィルタパラメータおよび季節因子を推定することができる。本発明の実施形態は、（ホットスポットまたはＪＲｏｃｋｉｔが備わったＭＢｅａｎを用いて）各々のＪＶＭに埋め込まれたフィルタを更新するために監視コントローラからフィルタパラメータおよび季節因子を推進することができる。

本発明の一実施形態においては、ホルト・ウィンタース三重指数フィルタに加えて、第４のおよび第５の指数フィルタを用いて、予測誤差残差の平均および偏差の傾向を把握することにより、正規化された誤差残差を計算する。予測誤差残差の平均は、フィルタにおける識別されたモデルのバイアスとして解釈することができる。このようなバイアスは、レベルスパイク、一時的なレベルシフト、永久的なレベルシフトまたはレベルドリフトの存在を示し得る。予測誤差残差のずれは、時系列データにおける分散変動を示し得る。一実施形態においては、分散変動の大きさにより、アウトライアを検出するためのフィルタの許容差が生じる可能性がある。測定値は、その予測誤差残差が予測誤差残留偏差の移動平均の百分率よりも大きい場合には、アウトライアとして検出される。概念的には、アウトライアは、フィルタにおいて識別された傾向モデルによって説明されない測定値であり、このため、アウトライアのクラスタは、何らかの外部からの原因によってのみ説明することができる異常を示すことができる。本発明の実施形態は、測定値における分散変動に応じたアウトライア検出のためにフィルタの許容差を適合させる。この技術は、高い分散変動がシステムに残存したときにアウトライアラートの数を減らすことによって、アラートによる疲労を減少させる。

本発明の一実施形態においては、ホルト・ウィンタース三重指数フィルタは、ＪＶＭメモリ割当て時の融通性を効率的に達成するためにＪＶＭヒープ使用量を季節に応じて傾向を把握し、かつ予測するために適用することができる。標準的なホルト・ウィンタース三重指数フィルタは、規則的な時系列からの予測を要求するために適用することができるものであって、特に、時間近接間隔が不規則であるランダムな時間間隔で機能するよう調整することができる。本発明の実施形態は、ＪＡＶＡヒープ割当ての傾向把握および予測のために、不規則な時間間隔に対してライトの方法と、時間近接間隔に対してＨａｎｚａｋ調整とを適用することができる。ＪＶＭフルガーベッジコレクションにおいて見出されるランダムな時間間隔に適したフィルタの構造の非自明的な選択を実行することができる。ホルト・ウィンタース・ライト・ハンザックフィルタの構造は、ＪＶＭフルガーベッジコレクションサイクルによって生成される時系列と一致させるように、系統的に適合させるための第１の原則から導き出すことができる。ＪＶＭメモリ使用量傾向を予測するのに有用なフィルタの拡張を非自明的に選択することができる。選択された拡張は、たとえば、（輻輳を追跡するために）成長率の加速をフィルタリングするための拡張と、（不規則な時間間隔が季節に対して何らかの相関関係を有するので）さまざまな時間スケールで並列に実行するための拡張と、（ソフト参照によってもたらされる不連続性に反応させるために用いることができる）正規化された誤差残差を最小限にすることによって（ファジイ論理に類似した）季節指数を選択するための拡張と、を含み得る。本発明の実施形態は、埋込まれたフィルタを調整するためにパラメータ推定用の非線形回帰を適用する非自明的な監視コントローラおよびフレームワークを用いて、組込まれたシステムを補完および増強することができる。

季節的傾向把握、予報、異常検出およびエンドポイント予測についてこの明細書中に記載された技術は、上述のＣＡＲＥ制御フレームワークなどの既存の監視制御フレームワークに追加することができる。監視コントローラによるモデル識別は、アウトライアを検出するためにベースラインを提供することができる。アウトライアのクラスタは、システムにおける異常を示すことができる。これらの異常のうちのいくつかは、システム障害および機能停止についての主要なインデックスを表わし得る。重大な異常が検出されるかまたはプロセスエンドポイントが予測されると、システムは、アプリケーション、構成およびシステムグリッチのデバッグを支援するために、スレッドダンプおよびヒープダンプを含む自動診断リポジトリ（ＡＤＲ：automatic diagnostic repository）インシデントレポートを生成することができる。システムはまた、エンタープライズ・マネージャ（ＥＭ：enterprise manager）クラウド制御に重大な警告を報告することができる。

一実施形態においては、指数移動平均のための公式は、メモリヒープ使用量およびスレッドまたはスタックセグメントの強度などのリソース利用基準を監視および予測するために、時系列データ、局所線形傾向、季節的傾向、予測の誤差残差、および予測の絶対偏差を平滑化するために適用される。一実施形態においては、公式は、１９５６年に提案されたブラウン（Brown）の指数フィルタ、１９５７年に提案されたホルトの二重指数フィルタ、１９６０年に提案されたウィンタースの三重指数フィルタ、１９８６年に提案されたライトによる不規則な時間間隔のための拡張、２００８年に提案されたハンザックによる時間近接間隔のための調整因子、ならびに、アウトライア検出およびクリッピングに基づいてもよい。以下の刊行物が引用によりこの明細書中に含まれる：アール・ジー・ブラウン（Ｒ．Ｇ．Ｂｒｏｗｎ）による「需要を予測するための指数平滑化（Exponential Smoothing for Predicting Demand）」（ケンブリッジ（Cambridge）、Arthur D. Little Inc.（１９５６年；１５頁）；シー・シー・ホルト（Ｃ．Ｃ．Ｈｏｌｔ）による「指数加重平均による傾向および季節の予測（Forecasting Trends and Seasonal by Exponentially Weighted Averages）」（海軍研究事務所備忘録、第５２号、１９５７年）；Ｐ．Ｒ．Ｗｉｎｔｅｒｓによる「指数加重移動平均による販売の予測（Forecasting Sales by Exponentially Weighted Moving Averages）」（マネジメントサイエンス、第６巻第３号３２４頁〜３４２頁）；ディー・ジェイ・ライト（Ｄ．Ｊ．Ｗｒｉｇｈｔ）による「ホルト法の拡張を用いて不規則な時間間隔で公開される予測データ（Forecasting data published at irregular time intervals using an extension of Holt's method）」（マネジメントサイエンス、第３２巻、第４号４９９頁〜５１０頁、１９８６年）；Ｔ．Ｈａｎｚａｋによる「不規則な時系列のための改善されたホルト法（Improved Holt Method for Irregular Time Series）」（ＷＤＳ’０８議事録、第Ｉ部、６２〜６７頁、２００８年）；ならびに、Ｓ．Ｍａｕｎｇ、Ｓ．Ｗ．ＢｕｔｌｅｒおよびＳ．Ａ．Ｈｅｎｃｋによる「実際の厚さ測定値に基づいたプロセスエンドポイント予測のための方法および装置（Method and Apparatus for process Endpoint Prediction based on Actual Thickness Measurements）」（米国特許５５０３７０７、１９９６年）。

指数加重移動平均
時系列データは、データポイントの正規化された加重和によって平滑化することができる。この場合、重みは、（自己回帰移動平均モデルにおける）時系列の自己相関、時間間隔の長さおよび他の因子に応じて適切に選択されている。

上述の式は、規則的な時間間隔のためにデータ列の正規化された指数加重和（exponentially weighted sum）を与える。パラメータαは正規化因子であって、ｎ→∞とする：

この列は、連続形式で等しく表わされる：

これは、正規化された指数加重和に等しい連続的な形式を再帰的に拡張することによって示すことができる：

ＷＲＩＧＨＴによる不規則な時間間隔のための拡張
（上述の）Ｗｒｉｇｈｔは、不規則な時間間隔のために正規化された指数加重和についての式を拡張させた：

以下が見いだされ得る。

したがって、以下のとおりである。

連続式が以下のとおり得られる：

以下の式が見いだされ得る。

したがって、以下のとおり連続式を得ることができる：

したがって、以下のとおり連続式が得られる：

時間間隔が平均時間間隔ｑで固定される場合、連続式は固定点に集中する：

シーケンスの固定点は、以下のとおりである：

固定点ｕは初期値として用いることができる：

時間近接間隔のためのハンザックの調整因子

以下の列を拡張させる。

連続式を以下のとおり得ることができる：

同様に、以下の列を拡張させる。

連続式が以下のとおり得られる：

したがって、連続式が以下のとおり得られる：

平均時間間隔ｑが１付近にスケーリングされている初期値が用いられる：

測定時間および実行時間間隔のための調整因子

ヒープ割当てアクティビティが固定されている場合にプロセスが測定時間間隔を除外すると想定される場合、ヒープ使用量基準の変化率は以下のとおり規定されていてもよい。すなわち、分母は測定時間を除いたプロセス実行時間間隔である：

（コーシー分布を回避する）レートフィルタにおける調整因子の使用

Ｗｒｉｇｈｔによる不規則な時間間隔のための拡張は、単独では、場合によっては、周期的パターンを検出するには十分でないかもしれない。Ｈａｎｚａｋによる時間近接間隔のための調整因子は、不規則な時間間隔によって引き起こされるノイズをガウス雑音レベルにまで低減させるために用いることができる。アウトライアのクリッピングは、さらに、単一（成長率のみ）または二重（成長率および加速）フィルタの性能を向上させる。

調整因子
時間近接間隔のための調整因子は、率推定の際にランダムな時間近接間隔に起因するノイズのより高い相対強度を補償するよう意図されたものであって、時間間隔がメモリリークまたはデッドロックによって引き起こされる輻輳中に単調に減少する場合に、意図せずに変化率推定値を減衰させることができる。メモリリークの場合、時間間隔が減少するのに応じて、実行時間が減少するが、測定時間は増大する。なぜなら、ＪＡＶＡ仮想マシン（ＪＶＭ）がフルガーベッジコレクション（ＧＣ）のためにより長く固定されるからである。ＪＶＭがフルＧＣ中に固定される場合、（いくつかの部分が他のＪＶＭに再分配されている）ＪＶＭの外部で新しい要求を列に並べる。バックログは、後続の実行時間中にヒープ使用量の変化率を加速させることができる。

測定時間が単調に減少している場合、以下の調整因子を用いることができる：

ホルト法の適用

平滑化された基準

局所線形傾向

リソース基準の成長率および加速
二重指数移動平均を、リソース基準の一次導関数および二次導関数に適用して、（メモリリークまたはスレッドデッドロックによる）加速するリソース輻輳を監視することができる。

アウトライア検出およびクリッピング

予測されたリソース基準の残余誤差を以下のとおり計算することができる：

正規化残差が以下のとおり与えられる。

これらの条件は以下のように要約される：

バイアスはレベル変化を表わす。バイアスの短期間のスパイクまたはディップは永続的なレベルシフトを表わす。連続的にスパイクおよびディップが起こるバイアスはレベルスパイクまたは一時的なレベルシフトを表わす。永続的な負バイアスは上方へのレベルドリフトを表わし、永続的な正バイアスは下方へのレベルドリフトを表わす。永続的な大きな絶対偏差は高い分散変動を表わす。バイアス、（１シグマおよび２シグマを表わす）絶対偏差ならびにアウトライアは、シューハート（Sewhart）管理図としてプロットすることができる。永続的なレベルドリフト、高い分散変動およびアウトライアのクラスタは、シューハート管理図において明確に視認することができ、単純なルールベースの分類スキームによって検出することができるものであるが、通常、システムにおける異常を表わしている。異常を識別して目立たせることによって、より高レベルの分類および査定スキームによる診断ができるようになる。

季節的傾向

第二に、各々の季節指数についての日ごとの平均でサンプル平均を割る。

多変数回帰
ｈ−ステップ予測の平均二乗誤差（ＭＳＥ：mean square error）残差および平均絶対偏差（ＭＡＤ：mean absolute deviation）は、所望の時系列ｘ_ｔについての独立変数α、β、κ、γ、δ、およびｔｚの関数として規定することができる。パラメータｔｚ、−１２＜ｔｚ＜１２は、東海岸標準時（ＥＳＴ：east coast standard time）からオフセットされたタイムゾーンである。タイムゾーンオフセットによる変更の後、週末の始まりは、土曜の午前１２時に対応し、週末の終わりは月曜の午前１２時に対応するものとする。複数のタイムゾーンにわたる平日アクティビティのピークと底とが重なり、週末中頃のレベルを週末期に集中させる必要がある場合、タイムゾーンオフセットを最適化することができる。

非線形の多変数回帰を適用することにより、連続する９日間以上にわたるデータに関するＭＳＥまたはＭＡＤを最小限にする値α、β、κ、γ、δ、およびｔｚを決定することができる。

すべての式においては、タイムスタンプはｔｚオフセットによってシフトされ、比例的にスケーリングされる。スケーリング因子は、平均時間間隔ｑが１付近にスケーリングされるように決定される。

単純な拡張型ホルト・ウィンタース季節フィルタ

観察された基準についての（先の段落において導き出されたような）第１の指数移動平均について設定された式は以下のとおり与えられる。

時間ｔ_ｎがスケーリング前にオフセットされたｔｚだけシフトされることに留意されたい。仮にｔ_ｎが土曜午前１２時と月曜午前１２時との間にあれば、週末の式が用いられる。

週末の季節因子および平日の季節因子についての第３の指数移動平均のために設定された式は以下のとおりである。

正規化残差がＱよりも大きい場合、アウトライアを検出するための式は以下のとおりである：

サンプルがアウトライアである場合、時間が週末の範囲内に収まるかまたは平日の範囲内に収まるかどうかに応じて、以下の式のうち１つを用いて平均を更新するために、アウトライア値の代わりに、クリッピングされた値が用いられるべきである：

基準の変化の加速を含む拡張型ホルト・ウィンタース季節フィルタ
メモリリークおよびデッドロックなどの輻輳監視のために、（先の段落で導き出された）以下の式のセットを用いることができる。

残余誤差列は以下のとおりである。

生の基準は成長率（一次導関数）である：

測定された成長率についての第１の指数移動平均のために設定された式は、季節的傾向付け因子に依存する。季節的傾向が付与されていない元の式は、以下のとおりである：

（週末および平日のための）２つの季節的傾向が導入される場合、季節ｔ_ｎ−１およびｔ_ｎのうちどちらが範囲内に収まるのかに応じて、非季節化された測定値を用いることができる。

非季節化された生の成長率が以下によって与えられる：

フィルタパラメータは以下の式によって調整される：

季節的傾向把握が用いられない場合、平滑化された成長率の初期値は、以下のとおりである：

成長率の加速についての第２の指数移動平均のために設定された式は、以下のとおりである：

季節的傾向把握が用いられない場合、平滑化された成長加速の初期値は以下のとおりである：

変化率の線形傾向に基づいた非季節化された予測変化率は以下のとおりである：

週末の季節因子および平日の季節因子についての第３の指数移動平均のために設定された式は以下のとおりである。

季節の乗法的因子は週末に更新される：

季節の乗法的因子は平日に更新される：

季節的傾向把握が用いられる場合、時間が週末の範囲内に収まるかどうかまたは平日の範囲内に収まるかどうかに応じて、以下の式のうちの１つを用いる：

ハードウェア概要
図１０は、この発明の一実施形態に従って使用され得るシステム環境１０００のコンポーネントを示す簡略化されたブロック図である。図示されているように、システム環境１０００は１つ以上のクライアントコンピューティング装置１００２、１００４、１００６、１００８を含み、それらは、ネイティブクライアントアプリケーションを含むクライアントアプリケーションや、場合によってはウェブブラウザなどの他のアプリケーションを動作させるように構成されている。さまざまな実施形態では、クライアントコンピューティング装置１００２、１００４、１００６および１００８は、サーバ１０１２とやり取りしてもよい。

クライアントコンピューティング装置１００２、１００４、１００６、１００８は、汎用パーソナルコンピュータ（たとえば、マイクロソフトウィンドウズ（登録商標）および／またはアップルマッキントッシュ（登録商標）オペレーティングシステムのさまざまなバージョンを作動させるパーソナルコンピュータおよび／またはラップトップコンピュータを含む）、携帯電話またはＰＤＡ（マイクロソフトウィンドウズモバイルなどのソフトウェアを作動させ、インターネット、ｅメール、ＳＭＳ、ブラックベリー（登録商標）、または他の通信プロトコルに対応）、および／または、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステムのうちのいずれかを作動させるワークステーションコンピュータ（さまざまなＧＮＵ／Ｌｉｎｕｘ（登録商標）オペレーティングシステムを限定なしで含む）であってもよい。また、これに代えて、クライアントコンピューティング装置１００２、１００４、１００６および１００８は、ネットワーク（たとえば、以下に説明するネットワーク１０１０）を通して通信可能な、シンクライアントコンピュータ、インターネット対応ゲームシステム、および／または個人用メッセージング装置といった任意の他の電子装置であってもよい。例示的なシステム環境１０００は４つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサ付き装置などの他の装置が、サーバ１０１２とやり取りしてもよい。

システム環境１０００は、ネットワーク１０１０を含んでいてもよい。ネットワーク１０１０は、ＴＣＰ／ＩＰ、ＳＮＡ、ＩＰＸ、ＡｐｐｌｅＴａｌｋなどを限定なしで含む商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポート可能な、当業者によく知られているあらゆるタイプのネットワークであってもよい。ほんの一例として、ネットワーク１０１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワークなどのローカルエリアネットワーク（local area network：ＬＡＮ）；ワイドエリアネットワーク；仮想プライベートネットワーク（virtual private network：ＶＰＮ）を限定なしで含む仮想ネットワーク；インターネット；イントラネット；エクストラネット；公衆交換電話網（public switched telephone network：ＰＳＴＮ）；赤外線ネットワーク；無線ネットワーク（たとえば、プロトコルのＩＥＥＥ８０２．１１スイートのいずれか、当該技術分野で公知のＢｌｕｅｔｏｏｔｈ（登録商標）プロトコル、および／または任意の他の無線プロトコルの下で動作するネットワーク）；ならびに／または、これらのおよび／もしくは他のネットワークの組合せであってもよい。

システム環境１０００はまた、１つ以上のサーバコンピュータ１０１２を含み、それは、汎用コンピュータ、特化サーバコンピュータ（たとえば、ＰＣサーバ、ＵＮＩＸサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラック搭載サーバなどを含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであってもよい。さまざまな実施形態では、サーバ１０１２は、１つ以上のサービスまたはソフトウェアアプリケーションを作動させるように適合されてもよい。

サーバ１０１２は、上述のいずれかを含むオペレーティングシステム、および商業的に入手可能なあらゆるサーバオペレーティングシステムを作動させてもよい。サーバ１０１２はまた、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを作動させてもよい。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース（Ｓｙｂａｓｅ）、ＩＢＭなどから商業的に入手可能なものを限定なしで含む。

システム環境１０００はまた、１つ以上のデータベース１０１４、１０１６を含んでいてもよい。データベース１０１４、１０１６は、さまざまな場所に存在していてもよい。たとえば、データベース１０１４、１０１６のうちの１つ以上は、サーバ１０１２にとってローカルな（および／またはサーバ１０１２に常駐する）非一時的な記憶媒体上に存在していてもよい。また、これに代えて、データベース１０１４、１０１６は、サーバ１０１２からリモートであってもよく、ネットワークベースのまたは専用の接続を介してサーバ１０１２と通信していてもよい。一組の実施形態では、データベース１０１４、１０１６は、当業者にはよく知られているストレージエリアネットワーク（storage area network：ＳＡＮ）に存在していてもよい。同様に、サーバ１０１２に起因する機能を行うためのあらゆる必要なファイルが、サーバ１０１２上にローカルにおよび／またはリモートで、適宜格納されてもよい。一組の実施形態では、データベース１０１４、１０１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、検索するように適合された、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでいてもよい。

図１１は、この発明の実施形態に従って使用され得るコンピュータシステム１１００の簡略化されたブロック図である。たとえば、サーバ１０１２またはクライアント１００２、１００４、１００６および１００８は、システム１１００などのシステムを用いて実現されてもよい。コンピュータシステム１１００は、バス１１２４を介して電気的に連結され得るハードウェア要素を含んで図示されている。ハードウェア要素は、１つ以上の中央処理装置（ＣＰＵ）１１０２と、１つ以上の入力装置１１０４（たとえば、マウス、キーボードなど）と、１つ以上の出力装置１１０６（たとえば、表示装置、プリンタなど）とを含んでいてもよい。コンピュータシステム１１００はまた、１つ以上の記憶装置１１０８を含んでいてもよい。たとえば、記憶装置１１０８は、ディスクドライブ、光学記憶装置、ならびに、ランダムアクセスメモリ（random access memory：ＲＡＭ）および／または読出し専用メモリ（read only memory：ＲＯＭ）などのソリッドステート記憶装置などの装置を含んでいてもよく、それらはプログラム可能、フラッシュ更新可能なものなどであってもよい。

コンピュータシステム１１００は加えて、コンピュータ読取可能記憶媒体リーダ１１１２と、通信サブシステム１１１４（たとえば、モデム、ネットワークカード（無線または有線）、赤外線通信装置など）と、上述のようなＲＡＭ装置およびＲＯＭ装置を含み得る作業メモリ１１１８とを含んでいてもよい。いくつかの実施形態では、コンピュータシステム１１００はまた、処理加速ユニット１１１６を含んでいてもよく、それは、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、専用プロセッサなどを含んでいてもよい。

コンピュータ読取可能記憶媒体リーダ１１１２はさらにコンピュータ読取可能記憶媒体１１１０に接続可能であり、コンピュータ読取可能な情報を一時的におよび／またはより永続的に含むためのリモートの、ローカルの、固定された、および／またはリムーバブルの記憶装置プラス記憶媒体を、ともに（および、オプションで記憶装置１１０８と組合されて）包括的に表わす。通信システム１１１４は、データが、システム環境１０００に対して、ネットワークおよび／または上述した任意の他のコンピュータと交換されることを許可してもよい。

コンピュータシステム１１００はまた、オペレーティングシステム１１２０および／またはアプリケーションプログラム（クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、ＲＤＢＭＳなどであってもよい）などの他のコード１１２２を含む、作業メモリ１１１８内に現在位置するものとして図示されたソフトウェア要素を含んでいてもよい。例示的な一実施形態では、作業メモリ１１１８は、上述のように傾向予測のために使用される実行可能コードおよび関連付けられたデータ構造を含んでいてもよい。コンピュータシステム１１００の代替的な実施形態は、上述のものからの多数の変形を有していてもよい、ということが理解されるべきである。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素がハードウェア、ソフトウェア（アプレットなどのポータブルソフトウェアを含む）、またはそれら双方で実現されてもよい。また、ネットワーク入力／出力装置などの他のコンピューティング装置への接続が採用されてもよい。

コードまたはコードの一部を含むための記憶媒体およびコンピュータ読取可能媒体は、当該技術分野で公知のまたは使用されるあらゆる適切な媒体を含んでいてもよく、コンピュータ読取可能な命令、データ構造、プログラムモジュール、もしくは他のデータといった情報の格納および／または送信のための任意の方法あるいは技術で実現される、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含むもののそれらに限定されない記憶媒体および通信媒体を含み、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、データ信号、データ伝送、もしくは所望の情報を格納または送信するために使用可能であり、コンピュータによってアクセス可能な任意の他の媒体を含む。

この発明の特定の実施形態を説明してきたが、さまざまな修正、変更、代替的構成、および同等物もこの発明の範囲内に包含される。この発明の実施形態は、ある特定のデータ処理環境内での演算に制限されず、複数のデータ処理環境内で自由に演算できる。加えて、この発明の実施形態は、ある特定の一連のトランザクションおよびステップを使用して説明されてきたが、この発明の範囲が上述の一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。

また、この発明の実施形態はハードウェアとソフトウェアとのある特定の組合せを用いて説明されてきたが、ハードウェアとソフトウェアとの他の組合せもこの発明の範囲内にあることが認識されるべきである。この発明の実施形態は、ハードウェアのみで、またはソフトウェアのみで、またはそれらの組合せを用いて実現されてもよい。

したがって、明細書および添付の図面は、限定的ではなく例示的な意味であると考えられるべきである。しかしながら、より広い精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がそれに行なわれてもよいことは、明らかであろう。

Claims (24)

1. コンピュータによって実現される方法であって、
   一連の時間間隔における各々の特定の時間間隔中に別個のスレッドダンプを生成することにより、一連のスレッドダンプサンプルを得るステップと、
   前記一連のスレッドダンプサンプルに基づいて、前記スレッドダンプサンプルに示されたスタックセグメント内のスタックフレームの強度の相違に基づいたスタックセグメント分類のセットを自動的に生成するステップと、を含み、
   前記セットにおける各スタックセグメント分類は、同じ強度を有するスタックフレームを含むスタックセグメントの別個のクラスを表し、前記強度は、コードブロックの実行時間を乗じたコードブロックの呼出し回数を統計基準として提供し、
   前記一連のスレッドダンプサンプルにおいて表わされる特定のスレッドごとに、コードブロックの実行時間を乗じた特定のスタックセグメントにおけるコードブロックの呼出し回数に少なくとも部分的に基づいて、前記スタックセグメント分類のセットから、前記特定のスレッドについての特定のスタックセグメント分類を自動的に選択するステップと、
   前記スタックセグメント分類のセットにおける各スタックセグメント分類について、前記強度の変化率を計測することで傾向を決定することにより、傾向のセットを生成するステップと、を含み、
   前記傾向のセットにおける各傾向は、前記強度の変化率を表し、
   前記傾向のセットに少なくとも部分的に基づいて異常のセットを決定するステップと、
   前記異常のセットに少なくとも部分的に基づいて出力を生成するステップとを含む、コンピュータによって実現される方法。
2. 前記スタックセグメント分類のセットを自動的に生成するステップは、
   前記一連のスレッドダンプサンプルにおいて表わされるスタックセグメント内におけるスタックフレームの前記強度が、時間の経過に応じて、指定されたしきい値を超えて逸脱し、
   前記スタックセグメント内における前記スタックフレームの強度が、時間の経過に応じて、前記指定されたしきい値を超えて逸脱するとの判断に応じて、前記スタックセグメントを複数の構成スタックセグメントに自動的に分割するステップと、
   前記複数の構成スタックセグメントの各々のために新しいスタックセグメント分類を生成するステップとを含む、請求項１に記載の方法。
3. 第１のスレッドダンプにおいて表わされるスレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ：ExecutionContextID）または当該スレッドがスタックされたスレッドとして既にカウントされたかを示すエポックカウンタが、それぞれ、第２のスレッドダンプにおいて表わされるスレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）または当該スレッドがスタックされたスレッドとして既にカウントされたかを示すエポックカウンタと同じであるかどうかを判断するステップと、
   前記第１のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタが、それぞれ、前記第２のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタと同じであるとの判断に応じて、前記第２のスレッドダンプにおいて表わされる前記スレッドが、前記第２のスレッドダンプにおけるスレッドの応答時間の統計である強度統計のためにカウントされるのを防止するステップとをさらに含む、請求項１または２に記載の方法。
4. 前記第１のスレッドダンプにおいて表わされる前記スレッドのＣＰＵ時間が前記第２のスレッドダンプにおいて表わされるスレッドのＣＰＵ時間と同じであると判断するステップと、
   前記第１のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタが、それぞれ、前記第２のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタと同じであるとの判断と、前記第１のスレッドダンプにおいて表わされる前記スレッドのＣＰＵ時間が前記第２のスレッドダンプにおいて表わされるスレッドのＣＰＵ時間と同じであるとの判断とに応じて、前記第１のスレッドダンプおよび前記第２のスレッドダンプにおいて表わされる同じスレッドをスタックしたスレッドとして識別するステップとをさらに含む、請求項３に記載の方法。
5. 前記一連のスレッドダンプサンプルにおける別個のスレッドダンプサンプル内にある第１のスレッドの複数のＣＰＵ時間に変化がないことに少なくとも部分的に基づいて、前記第１のスレッドがスタックしていると判断するステップをさらに含む、請求項４に記載の方法。
6. 前記第１のスレッドダンプにおいて表わされるスレッドのＣＰＵ時間が前記第２のスレッドダンプにおいて表わされる前記スレッドのＣＰＵ時間とは異なると判断するステップと、
   前記第１のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタが、それぞれ、前記第２のスレッドダンプにおいて表わされる前記スレッドのスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタと同じであるとの判断と、前記第１のスレッドダンプにおいて表わされる前記スレッドの前記ＣＰＵ時間が前記第２のスレッドダンプにおいて表わされるスレッドのＣＰＵ時間とは異なるとの判断とに応じて、前記第１のスレッドダンプおよび前記第２のスレッドダンプにおいて表わされる同じスレッドを残存するスレッドとして識別するステップとを含む、請求項３または４に記載の方法。
7. 前記一連のスレッドダンプサンプルにおける別個のスレッドダンプサンプル内における第１のスレッドの複数のスレッド名、実行コンテキストＩＤ（ＥＣＩＤ）またはエポックカウンタに変化がないことに少なくとも部分的に基づいて、第１のスレッドが残存していると判断するステップをさらに含む、請求項６に記載の方法。
8. 前記一連のスレッドダンプにおけるスレッドダンプについての第１のサンプリング間隔による当該一連のスレッドダンプにおけるスレッドの応答時間の統計である第１の強度統計を維持するステップと、
   特定のスレッドが、第１のサンプリング間隔および第２のサンプリング間隔にわたってスタックするかまたは残存するように決定されたとの判断に応じて、前記一連のスレッドダンプにおけるスレッドダンプについての第２のサンプリング間隔による当該一連のスレッドダンプにおけるスレッドの応答時間の統計である第２の強度統計を調整するステップとをさらに含み、第２のサンプリング間隔は、スタックしているスレッドまたは残存するスレッドを繰り返しカウントすることを防止する、請求項１〜７のいずれか１項に記載の方法。
9. 前記特定のスレッドのための特定のスタックセグメント分類を前記スタックセグメント分類のセットから選択するステップは、
   特定のスタックトレースにおける特定のスタックフレームについての前記強度を決定するステップと、
   前記特定のスタックトレースにおける前記特定のスタックフレームの直前に発生する先行処理スタックフレームについての前記強度を決定するステップと、
   前記特定のスタックトレースにおける前記特定のスタックフレームの直後に発生する後続処理スタックフレームについての前記強度を決定するステップと、
   前記特定のスタックフレームについての前記強度が前記先行処理スタックフレームについての前記強度と全く同じであるかまたはほぼ同じであるとの判断に応じて、前記特定のスタックフレームおよび前記先行処理スタックフレームの両方に特定の分類を割当てるステップと、
   前記特定のスタックフレームについての前記強度が前記後続処理スタックフレームについての前記強度と同じであるとの判断に応じて、前記特定のスタックフレームおよび前記後続処理スタックフレームの両方に前記特定の分類を割当てるステップとを含む、請求項１〜８のいずれか１項に記載の方法。
10. 新しいスタックセグメント情報項目を作成するステップと、
    現在のスタックセグメント情報項目の値に前記新しいスタックセグメント情報項目を割当てるステップと、
    前記新しいスタックセグメント情報項目の分類に応じて新しい季節的傾向情報項目を生成するステップと、
    前記現在のスタックセグメント情報項目の傾向属性の値を前記新しい季節的傾向情報項目に設定するステップとをさらに含む、請求項１〜９のいずれか１項に記載の方法。
11. 一体化されたスタックセグメントを第１の新しいスタックセグメントおよび第２の新しいスタックセグメントに分割するステップと、
    前記一体化されたスタックセグメントの季節的傾向情報項目の第１のクローンを作成するステップと、
    前記一体化されたスタックセグメントの前記季節的傾向情報項目の第２のクローンを作成するステップと、
    前記第１の新しいスタックセグメントの傾向属性の値を前記第１のクローンに設定するステップと、
    前記第２の新しいスタックセグメントの傾向属性の値を前記第２のクローンに設定するステップとをさらに含む、請求項１〜１０のいずれか１項に記載の方法。
12. スタックセグメント分類のセットを生成するステップと、
    一続きのスタックセグメント分類に少なくとも部分的に基づいてスレッド分類を生成するステップとをさらに含む、請求項１〜１１のいずれか１項に記載の方法。
13. スレッド分類のセットを生成するステップと、
    スレッド間における呼出しチェーン、依存チェーンおよびクライアント・サーバチェーンのうちの１つに少なくとも部分的に基づいて一続きのスレッドの分類を生成するステップとをさらに含む、請求項１２に記載の方法。
14. １つ以上のスタックセグメント分類をいずれかのディメンションに割当てることによって、前記１つ以上のスタックセグメント分類を前記スタックセグメント分類のセットに編成するステップと、
    前記特定のスタックセグメント分類の名前を設定するステップと、
    特定のディメンションの名前を設定するステップとをさらに含む、請求項１〜１３のいずれか１項に記載の方法。
15. 前記特定のスタックセグメント分類が割当てられているディメンションのクロス積を採用することによって、前記特定のスタックセグメント分類のクラス階層にまでドリルダウンするステップをさらに含む、請求項１４に記載の方法。
16. 暗黙知に少なくとも部分的に基づいて前記特定のスタックセグメント分類の名前を設定するステップと、
    前記暗黙知に少なくとも部分的に基づいて特定のディメンションの名前を設定するステップと、
    ディメンションに対する前記１つ以上のスタックセグメント分類を、前記暗黙知に少なくとも部分的に基づいて、ドメインディメンション、サーバディメンション、チャネルディメンション、アプリケーションディメンション、ライブラリディメンションおよびオペレーションディメンションのうち少なくとも１つに割当てるステップと、を含み、
    前記暗黙知に少なくとも部分的に基づいたディメンションへの割当てを、前記ドメインディメンション、前記サーバディメンション、前記チャネルディメンション、前記アプリケーションディメンション、前記ライブラリディメンションおよび前記オペレーションディメンションのうち少なくとも１つに対して行う、請求項１４または１５に記載の方法。
17. 人の暗黙知に基づいて１つ以上のスタックセグメントを分類するステップと、
    前記人の暗黙知に少なくとも部分的に基づいて１つ以上のディメンションに１つ以上の分類を割当てるステップとをさらに含む、請求項１〜１６のいずれか１項に記載の方法。
18. 帰納学習プロセスに少なくとも部分的に基づいて、前記スタックセグメント分類のセットにおける前記スタックセグメント分類の１つ以上を、前記スタックセグメント分類の１つ以上を生成する前に規定された１つ以上のディメンションに割当てるステップをさらに含む、請求項１〜１７のいずれか１項に記載の方法。
19. 各々がクライアント部分およびサーバ部分を含む依存関係の複数のサブクラスを含む一般化された依存関係を格納するステップと、
    特定のサブクラス依存関係の一般化されたクライアント部分を、前記特定のサブクラスの一般化されたサーバ部分よりも依存強度が高いクライアント部分にまでドリルダウンするステップと、
    前記特定のサブクラス依存関係の一般化されたサーバ部分を、前記特定のサブクラスの一般化されたクライアント部分よりも依存強度が高いサーバ部分にまでドリルダウンするステップとをさらに含む、請求項１〜１８のいずれか１項に記載の方法。
20. 暗黙知に少なくとも部分的に基づいてスレッド依存関係の知識ベースを生成するステップと、
    前記スレッド依存関係に少なくとも部分的に基づいて、１対のサービングエンティティにわたる少なくとも１つの発生率を、問題の根本的原因を分析する部分として相互に関連付けるステップとをさらに含み、
    前記１対のサービングエンティティは、１対のクライアントおよびサーバ、１対のサーバまたは１対のクライアントのうち少なくとも１つである、請求項１〜１９のいずれか１項に記載の方法。
21. 前記１対のサービングエンティティ間におけるチャネルに少なくとも部分的に基づいてインピーダンス整合を実行するステップをさらに含み、
    前記チャネルは、前記対における第１のサービングエンティティのためのスタックセグメントのクラスと前記対における第２のサービングエンティティのためのスタックセグメントのクラスとの間のクライアント・サーバ依存関係をサポートする、請求項２０に記載の方法。
22. スタックセグメントのサブ分類のスタックセグメントの応答時間に比例するスタックセグメント強度の合成に基づいて、前記特定のスタックセグメント分類のスタックセグメント強度を決定するステップと、
    前記特定のスタックセグメント分類のスタックセグメントの予想される応答時間を、スタックセグメントの前記サブ分類のスタックセグメントの応答時間にセグメント化するステップとをさらに含み、
    予想される応答時間をセグメント化する前記ステップは、スタックセグメント強度の合成に少なくとも部分的に基づいている、請求項１〜２１のいずれか１項に記載の方法。
23. コンピュータ読取可能プログラムであって、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    一連の時間間隔における各々の特定の時間間隔中に別個のスレッドダンプを生成することにより、一連のスレッドダンプサンプルを得る動作と、
    前記一連のスレッドダンプサンプルに基づいて、前記スレッドダンプサンプルに示されたスタックセグメント内のスタックフレームの強度の相違に基づいたスタックセグメント分類のセットを自動的に生成する動作と、を実行させ、
    前記セットにおける各スタックセグメント分類は、同じ強度を有するスタックフレームを含むスタックセグメントの別個のクラスを表し、前記強度は、コードブロックの実行時間を乗じたコードブロックの呼出し回数を統計基準として提供し、
    前記一連のスレッドダンプサンプルにおいて表わされる特定のスレッドごとに、コードブロックの実行時間を乗じた特定のスタックセグメントにおけるコードブロックの呼出し回数に少なくとも部分的に基づいて、前記スタックセグメント分類のセットから、前記特定のスレッドについての特定のスタックセグメント分類を自動的に選択する動作と、
    前記スタックセグメント分類のセットにおける各スタックセグメント分類について、前記強度の変化率を計測することで傾向を決定することにより、傾向のセットを生成する動作とを実行させ、
    前記傾向のセットにおける各傾向は、前記強度の変化率を表し、
    前記傾向のセットに少なくとも部分的に基づいて異常のセットを決定する動作と、
    前記異常のセットに少なくとも部分的に基づいて出力を生成する動作とを実行させる、コンピュータ読取可能プログラム。
24. 一連の時間間隔における各々の特定の時間間隔中に別個のスレッドダンプを生成することにより、一連のスレッドダンプサンプルを得るための手段と、
    前記一連のスレッドダンプサンプルに基づいて、前記スレッドダンプサンプルに示されたスタックセグメント内のスタックフレームの強度の相違に基づいたスタックセグメント分類のセットを自動的に生成するための手段と、を含み、
    前記セットにおける各スタックセグメント分類は、同じ強度を有するスタックフレームを含むスタックセグメントの別個のクラスを表し、前記強度は、コードブロックの実行時間を乗じたコードブロックの呼出し回数を統計基準として提供し、
    前記一連のスレッドダンプサンプルにおいて表わされる特定のスレッドごとに、コードブロックの実行時間を乗じた特定のスタックセグメントにおけるコードブロックの呼出し回数に少なくとも部分的に基づいて、前記スタックセグメント分類のセットから、前記特定のスレッドについての特定のスタックセグメント分類を自動的に選択する手段と、
    前記スタックセグメント分類のセットにおける各スタックセグメント分類について、前記強度の変化率を計測することで傾向を決定することにより、傾向のセットを生成するための手段と、を含み、
    前記傾向のセットにおける各傾向は、前記強度の変化率を表し、
    前記傾向のセットに少なくとも部分的に基づいて異常のセットを決定するための手段と、
    前記異常のセットに少なくとも部分的に基づいて出力を生成するための手段とを備える、コンピュータシステム。

Images