(57)【要約】      （修正有）【課題】コンピュータシステムアプリケーションの監視およびアラートのための機構を提供する。【解決手段】アプリケーションチェーンの１つまたは複数のアプリケーションのパフォーマンスの低下の期間中に消費量プローブによりアプリケーションの資源の使用レベルを測定し、アプリケーションチェーンのアプリケーション別および期間別に、少なくとも１つのメモリ２１、２２、２３において、資源別およびアプリケーション別に、測定リポジトリ１の使用レベルの許容可能パフォーマンスの閾値を定義し記憶することによって使用リポジトリ２を確立する。測定リポジトリと使用リポジトリに応じてパフォーマンス問題のカテゴリ化モジュール３を構成し、監視機構がアプリケーションチェーンにおける１つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合に、アラート機構４を実現する。【選択図】図１
2018109973.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するための、少なくとも１つのコンピュータマシンとマシンによって実行可能なソフトウェアまたはコードとを含むシステムであって、一方では、アプリケーションチェーンの１つまたは複数のアプリケーションのパフォーマンスの低下の期間中にアプリケーションの資源の使用レベルを測定するために資源上にインストールされた消費量プローブによる測定のためと、他方では、アプリケーションチェーンのアプリケーション別および期間別に、メモリ（１１）においてこれらの使用レベルを測定リポジトリ（１）に記憶するために、測定リポジトリ（１）を形成するコンピュータハードウェアおよびソフトウェア構成を含み、システムのハードウェアおよびソフトウェア構成は、
少なくとも１つのメモリ（２１、２２、２３）において資源別およびアプリケーション別に、使用レベルの許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）を定義し、記憶することによって、測定リポジトリのデータの使用リポジトリ（２）を確立し、
測定リポジトリ（１）と使用リポジトリ（２）に応じてパフォーマンス問題のカテゴリ化モジュール（３）を構成し、
監視機構がアプリケーションチェーンにおける１つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合に、アラート機構（４）を実現するようにさらに動作可能であることを特徴とする、システム。
【請求項２】
使用レベルの許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）が、トリップレットを形成して最小閾値（Ｓｍｉｎ）と最大閾値（Ｓｍａｘ）と中間閾値（Ｓｉｎｔ）とからなる３つの許容可能閾値を含み、閾値のこのトリップレット（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）は資源ごとおよびアプリケーションチェーンのアプリケーションごとに記憶されることを特徴とする、請求項１に記載のシステム。
【請求項３】
使用リポジトリ（２）が、メモリ（２４）において、測定リポジトリ（１）の使用レベルの測定値に基づいて定義された許容可能消費量区間（Ｉｎ）を確立し、記憶する少なくとも１つのハードウェアおよびソフトウェア構成（２０）を含むことを特徴とする、請求項１または２に記載のシステム。
【請求項４】
監視機構が、測定されて測定リポジトリ（１）に記憶された資源の使用レベルを、閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）および／またはアプリケーション別に使用リポジトリ（２）に確立された消費量区間（Ｉｎ）と比較することができることを特徴とする、請求項１から３のいずれか一項に記載のシステム。
【請求項５】
使用リポジトリ（２）が、資源ごとの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）別の実際の使用レベル（２１）と理論上の使用レベル（２２）とをメモリに確立し、記憶するための少なくとも１つのハードウェアおよびソフトウェア構成（２０）を含むことを特徴とする、請求項１から４のいずれか一項に記載のシステム。
【請求項６】
アプリケーションの資源消費量の異なるレベルを特徴づけるために、アプリケーションの資源の使用レベルが数回測定されることを特徴とする、請求項１から５のいずれか一項に記載のシステム。
【請求項７】
アプリケーションの資源の使用レベルの測定が生産前環境または認定環境において行われることを特徴とする、請求項１から６のいずれか一項に記載のシステム。
【請求項８】
必要であれば使用レベルの許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）および／または資源ごとおよびアプリケーション別の消費量区間（Ｉｎ）を精緻化するために、アプリケーションの資源の使用レベルの測定が生産環境においても行われることを特徴とする、請求項３から７のいずれか一項に記載のシステム。
【請求項９】
測定リポジトリ（１）が、資源別およびアプリケーション別の使用レベルの許容可能パフォーマンスの「季節的」閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）を確立し記憶するために、強い季節的使用変動を有する資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリ（２３）に記憶するハードウェアおよびソフトウェア構成を含むことを特徴とする、請求項１から７のいずれか一項に記載のシステム。
【請求項１０】
パフォーマンス問題のカテゴリ化モジュール（３）が、
メモリ（３１）に記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成、または
測定された使用レベルが資源の最大閾値（Ｓｍａｘ）を上回る場合に、メモリ（３２）に記憶される「ハードウェア異常」カテゴリを作成するための、測定リポジトリ内（１）の利用可能な資源の測定された使用レベルと、使用リポジトリ（２）において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値（Ｓｍａｘ）との比較、または
測定された使用レベルが資源の許容可能消費量区間（Ｉｎ）外である場合に、メモリ（３３）に記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するための、測定リポジトリ（１）において利用可能な資源の測定された使用レベルと、使用リポジトリ（２）のメモリ（２４）において利用可能なアプリケーションの資源ごとの使用レベルの許容可能消費量区間（Ｉｎ）との比較、または
アプリケーションの資源のニーズの季節性の規則とメモリ（３４）に記憶される測定リポジトリ（１）において利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源別およびアプリケーション別の将来のパフォーマンス低下消費量の計算、または
資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合に、メモリ（３５）に記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するための、資源の将来の消費量の計算結果と、使用リポジトリ（２）において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
上記の動作のうちの少なくとも２つの組合せ
の動作によってカテゴリ化を確立することを特徴とする、請求項３から９のいずれか一項に記載のシステム。
【請求項１１】
アラート機構（４）が少なくとも１つのメモリ（４１、４２、４３）に、
測定リポジトリ（１）において利用可能なアプリケーションの資源の使用レベルが使用リポジトリ（２）において利用可能な前記資源の許容可能パフォーマンスの最大閾値（Ｓｍａｘ）を上回る場合の「ハードウェア異常」アラートと、
測定リポジトリ（１）において利用可能なアプリケーションの資源の使用レベルが使用リポジトリ（２）において利用可能な前記資源の許容可能消費量区間（Ｉｎ）外である場合の「アプリケーションパフォーマンス低下」アラートと、
カテゴリ化モジュール（３）のメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリ（２）において利用可能な前記資源の許容可能パフォーマンスの最大閾値（Ｓｍａｘ）を上回る場合の「予防アプリケーションパフォーマンス」アラートと、
のうちの少なくとも１つまたは複数のアラートを作成し記憶することを特徴とする、請求項３から１０のいずれか一項に記載のシステム。
【請求項１２】
システムが、アプリケーションチェーンの１つまたは複数のアプリケーション上の異常、または、アプリケーションの重要資源の過剰消費ないし将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができることを特徴とする、請求項１から１１のいずれか一項に記載のシステム。
【請求項１３】
アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、請求項２から１２のいずれか一項によるシステムを制御する方法であって、
資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップを含み、
方法が、
アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
測定された資源ごとおよびアプリケーションごとの最小閾値（Ｓｍｉｎ）と最大閾値（Ｓｍａｘ）と中間閾値（Ｓｉｎｔ）とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて使用リポジトリ（２）を構築するステップと、
使用リポジトリ（２）と、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて１つまたは複数の資源のパフォーマンス問題をカテゴリ化して記憶するステップと、
測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）と比較するステップと、
アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップにおいて取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、をさらに含むことを特徴とする方法。
【請求項１４】
測定された使用レベルを許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）と比較するステップが、アプリケーションチェーンのアプリケーションを連続的に監視し、アラートするために連続的に反復されることを特徴とする、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＴインフラストラクチャの監視の分野に関し、より具体的には、企業コンピュータシステムのアプリケーションの監視およびアラートの分野に関する。
【背景技術】
【０００２】
最高情報責任者（Ｃｈｉｅｆ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｏｆｆｉｃｅｒ：ＣＩＯ）の活動範囲において、アプリケーションのサービス品質の順守が臨界閾値を上回る場合、またはアプリケーションが機能しない場合、介入が必要となる。一般に、この状況は、ソリューションを運営するインフラストラクチャに対して監視が整備されていない、および／または、アラートにおけるバックアップがなされないかあるいは遅すぎるという事実によって説明される。この場合、一般に、問題の分析に必要なデータが利用できないかまたは利用できなくなっているため、問題の原因を突き止めて問題を是正することはきわめて困難である。
【０００３】
ＩＴインフラストラクチャの監視のためのソリューションは、従来技術から知られている。これらのソリューションは、サーバ上の競合の問題を診断するが、情報システムの資源の飽和とアプリケーションとを関連させることができない。これらのソリューションは、問題を解決するためにのみ技術的介入を開始するが、アプリケーションチェーンのアプリケーションまたはサーバのサービス品質の適正な順守および適正なパフォーマンスを確保するためにＣＩＯ（最高情報責任者）がその業務部門に対して保証するべき「サービスレベル合意書（ＳＬＡ）」の水準に対応することができない。
【０００４】
このような状況において、コンピュータシステムのアプリケーションのパフォーマンスの問題を是正することによって従来技術の短所を解消するソリューションを提案することは注目される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、アプリケーションのパフォーマンスの問題を是正および／または予防するためのソリューションを提案することによって、従来技術のいくつかの短所を解消することである。
【課題を解決するための手段】
【０００６】
この目的のため、本発明は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するための、少なくとも１つのコンピュータマシンとマシンによって実行可能なソフトウェアまたはコードとを含むシステムであって、一方では、アプリケーションチェーンの１つまたは複数のアプリケーションのパフォーマンスの低下の期間中にアプリケーションの資源の使用レベルを測定するために資源上にインストールされた消費量プローブによる測定のためと、他方では、アプリケーションチェーンのアプリケーション別および期間別に、メモリ（１１）においてこれらの使用レベルを測定リポジトリ（１）に記憶するために、測定リポジトリ（１）を形成するコンピュータハードウェアおよびソフトウェア構成を含み、システムのハードウェアおよびソフトウェア構成は、
少なくとも１つのメモリ（２１、２２、２３）において資源別およびアプリケーション別に、使用レベルの許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）を定義し、記憶することによって、測定リポジトリのデータの使用リポジトリ（２）を確立し、
測定リポジトリ（１）と使用リポジトリ（２）に応じてパフォーマンス問題のカテゴリ化モジュール（３）を構成し、
監視機構がアプリケーションチェーンにおける１つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合にアラート機構（４）を実現するようにさらに動作可能であることを特徴とするシステムに関する。
【０００７】
したがって、本発明は、アプリケーションが異常な動作を示す時または競合の発生より前に、アラート時にアプリケーションチェーンのアプリケーションの資源消費量と、アプリケーションの漸進的変化とを監視し、上記の問題を解決する。
【０００８】
別の特定の特徴によれば、使用レベルの許容可能パフォーマンスの閾値は、トリップレットを形成して最小閾値と最大閾値と中間閾値とからなる３つの許容可能閾値を含み、閾値のこのトリップレットは資源ごとおよびアプリケーションチェーンのアプリケーションごとに記憶される。
【０００９】
別の特定の特徴によれば、使用リポジトリは、測定リポジトリの使用レベルの測定値に基づいて定義された許容可能消費量区間をメモリに確立し、記憶する少なくとも１つのハードウェアおよびソフトウェア構成を含む。
【００１０】
別の特徴によれば、監視機構は、測定されて測定リポジトリに記憶された資源の使用レベルを、閾値および／またはアプリケーション別に使用リポジトリに確立された消費量区間と比較することができる。
【００１１】
別の特定の特徴によれば、使用リポジトリ（２）は、資源ごとの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）別の実際の使用レベル（２１）と理論上の使用レベル（２２）とをメモリに確立し、記憶するための少なくとも１つのハードウェアおよびソフトウェア構成（２０）を含む。
【００１２】
別の特徴によれば、アプリケーションの資源消費量の異なるレベルを特徴づけるために、アプリケーションの資源の使用レベルが数回測定される。
【００１３】
別の特定の特徴によれば、アプリケーションの資源の使用レベルの測定は生産前環境または認定環境において行われる。
【００１４】
別の特定の特徴によれば、必要であれば使用レベルの許容可能パフォーマンスの閾値および／または資源ごとおよびアプリケーション別の消費量区間を精緻化するために、アプリケーションの資源の使用レベルの測定が生産環境においても行われる。
【００１５】
別の特定の特徴によれば、測定リポジトリは、資源別およびアプリケーション別の使用レベルの許容可能パフォーマンスの「季節的」閾値を確立し記憶するために、強い季節的使用変動を有する資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリに記憶するハードウェアおよびソフトウェア構成を含む。
【００１６】
別の特定の特徴によれば、パフォーマンス問題のカテゴリ化モジュールは、
メモリに記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成、または
測定された使用レベルが資源の最大閾値を上回る場合に、メモリに記憶される「ハードウェア異常」カテゴリを作成するための、測定リポジトリ内の利用可能な資源の測定された使用レベルと、使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
測定された使用レベルが資源の許容可能消費量区間外である場合に、メモリに記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するための、測定リポジトリにおいて利用可能な資源の測定された使用レベルと、使用リポジトリのメモリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能消費量区間との比較、または
アプリケーションの資源のニーズの季節性の規則とメモリに記憶される測定リポジトリにおいて利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源別およびアプリケーション別の将来のパフォーマンス低下消費量の計算、または
資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合に、メモリに記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するための、資源の将来の消費量の計算結果と、使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
上記の動作のうちの少なくとも２つの組合せの動作によってカテゴリ化を確立する。
【００１７】
別の特定の特徴によれば、アラート機構は少なくとも１つのメモリに、
測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「ハードウェア異常」アラートと、
測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリにおいて利用可能な前記資源の許容可能消費量区間外である場合の「アプリケーションパフォーマンス低下」アラートと、
カテゴリ化モジュールのメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「予防アプリケーションパフォーマンス」アラートと、のうちの少なくとも１つまたは複数のアラートを作成し記憶する。
【００１８】
別の特定の特徴によれば、システムは、アプリケーションチェーンの１つまたは複数のアプリケーション上の異常、または、アプリケーションの重要資源の過剰消費ないし将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができる。
【００１９】
他の目的は、これらのパフォーマンスの低下事象時に、アプリケーションチェーンのアプリケーション上で観察される徴候の監視およびアラート機構に関する従来技術の１つまたは複数の短所を是正することである。
【００２０】
この目的は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、本発明の特定の特徴のいずれか１つによるシステムを制御する方法であって、
資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップを含み、
方法は、
アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
測定された資源ごとおよびアプリケーションごとの最小閾値と最大閾値と中間閾値とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて使用リポジトリを構築するステップと、
使用リポジトリと、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて１つまたは複数の資源のパフォーマンス問題をカテゴリ化して記憶するステップと、
測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値と比較するステップと、
アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップにおいて取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、をさらに含む。
【００２１】
別の特定の特徴によれば、測定された使用レベルを許容可能パフォーマンスの閾値と比較するステップは、アプリケーションチェーンのアプリケーションを連続的に監視し、アラートするために連続的に反復される。
【００２２】
本発明のその他の特徴および利点は、以下の説明で詳述される。
【００２３】
本発明のその他の特定の特徴および利点は、添付図面を参照しながら以下の説明を読めばより明確にわかるであろう。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態によるアプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するためのシステムの要素を概略的に示す図である。
【図２】本発明の一実施形態によるアプリケーションチェーンのアプリケーションのパフォーマンスの監視とアラートを行う方法を概略的に示す図である。
【発明を実施するための形態】
【００２５】
以下において、コンピュータプローブとは、例えば、ある特定の変動があった後で、または周期的に、特にネットワークフローの品質またはサービス品質（ＱｏＳ）を通知することを意図した測定値を自動的に測定し、管理し、監視装置にフィードバックする装置（例えばセンサ）に関連付けられたソフトウェアである。したがって、ネットワークを乱雑にするだけの反復的なコマンドをユーザ側で送る必要がなく、情報のフィードバックは、プローブによって自動的に行われる。
【００２６】
一実施形態では、プローブのサンプリング周波数は、アプリケーションチェーンを構成する異なる物理サーバおよび／または仮想サーバ間の測定値を互いに関係づけることができるように、一定かつ同期していなければならない。
【００２７】
本発明は、少なくとも１つのコンピュータシステムと、マシンによって実行可能なソフトウェアまたはコードとを含み、特にアプリケーションチェーンのアプリケーションのパフォーマンスの低下時に、アプリケーションチェーンのアプリケーション（またはサーバ）のパフォーマンスを監視するための機構を実現するために、アプリケーションチェーンの他のハードウェアまたはソフトウェアと通信するシステムに関する。アプリケーションチェーンのアプリケーションのパフォーマンスの低下は、アプリケーションチェーンのうちの１つまたは複数のアプリケーション（またはサーバ）上でのあらゆる種類の異常動作またはあらゆる種類の起こり得る競合である場合があり、例えばアプリケーションの資源の飽和またはアプリケーションの資源消費量であるが、これらには限定されない。アプリケーションチェーンは、全部または一部が複数のアプリケーションまたはサーバ（Ａ１、．．．、Ａｊ、．．．、Ａｍ）によって使用される１組の資源（Ｒ１、．．．，Ｒｉ、．．．Ｒｎ）を含み、したがって、アプリケーションチェーンの構造は、メモリ内で各アプリケーションＡｊに関連付けられた資源の識別子Ｌｒｉのリストによって表される。
【００２８】
一実施形態では、システムは、測定リポジトリ（１）を記憶するための少なくとも１つのハードウェアおよびソフトウェア構成を含む。測定リポジトリ（１）は、消費量プローブによって、パフォーマンス低下期間Ｐｄｐｊ中にアプリケーションチェーンを構成するすべてのアプリケーション（Ａ１、．．．，Ａｊ、．．．Ａｍ）のアプリケーションＡｊのそれぞれ１つにおける資源Ｒｉの使用レベルＮｕｒｉを測定し、次に、これらのレベルＮｕｒｉを期間Ｐｄｐｊに関連付けて測定リポジトリ（１）のメモリ（１１）に記憶して情報ダブレット（Ｎｕｒｉ，Ｐｄｐｊ）を構成するための、少なくとも１つのハードウェアおよびソフトウェアコンピュータ構成（１０）を含む。
【００２９】
消費量プローブは、資源の使用レベル（Ｎｕｒ）を表す測定値またはメトリクスに関する情報をフィードバックするために各資源に関連付けられる。各資源について、消費量プローブは、その資源名の識別子Ｌｒと使用レベルＮｕとを定義する。各資源の使用レベルＮｕｒｉは、情報ダブレット（Ｌｒ，Ｎｕｉ）に対応する。同じ処理が、トリップレット（Ｌｒ，Ｎｕｉ，Ｐｄｐｊ）を記憶するためにパフォーマンス問題のない期間についても行われる。
【００３０】
したがって、測定リポジトリのメモリ（１１）は、トリプレット（Ｌｒ，Ｎｕｉ，Ｐｄｐｊ）または（Ｌｒ，Ｎｕｊ，Ｐｎｄｐｊ）を記憶し、これはプローブによって送信される情報の数および量を低減して、上述の知られているソリューションと比較してネットワークの大きさを低減するとともに、精度を向上させる効果がある。
【００３１】
実施形態によっては、プローブされる資源は、プロセッサ、入出力およびメモリに加えて、クラスタの各インスタンス、各アプリケーションキャッシュ、ＪＭＳ／ＪＤＢＣアプリケーンのプログラミングインターフェースメッセージのファイルの各サイズであり得る。ＪＭＳ（ｊａｖａ  ｍｅｓｓａｇｉｎｇ  ｓｅｒｖｉｃｅ）アプリプログラミングインターフェース（ＡＰＩ）は、アプリケーション間でメッセージを送受信するためのプログラミングインターフェースであり、ＪＤＢＣ（ｊａｖａ  ｄａｔａｂａｓｅ  ｃｏｎｎｅｃｔｉｖｉｔｙ）は、データベースへのアクセスを可能にするＡＰＩである。
【００３２】
例えば、資源（プロセッサ（中央演算処理装置（ＣＰＵ）とも定義される）、メモリなど）の占有率（％）として算出される各サーバに加わる負荷、ディスクの入出力に加わる負荷、またはネットワークの速度に加わる負荷（接続パケット（伝送制御プロトコル（ＴＣＰ）とも定義される）およびカウントオクテット）などの情報が、消費量プローブによってフィードバックされ得るが、これらには限定されない。
【００３３】
負荷、資源占有率（％）、応答時間、処理時間、ＣＰＵ使用レベル、ディスク読み取りレベル、ディスク書き込みレベルなどの一般的要素が、プローブにより測定され得るが、ファイル数またはオープンポート数、ＪＤＢＣ（Ｊａｖａ（登録商標）プログラムがデータベースにアクセスできるようにするプログラミングインターフェースであるＪａｖａ  ＤａｔａＢａｓｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ）メッセージファイル数、または、ＪＭＳ（アプリケーション間でのメッセージの送受信のためのプログラミングインターフェースであるＪａｖａ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）メッセージファイル数、ファイルシステムの占有率、Ｊ２ＥＥアプリケーション（Ｊａｖａ  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ、Ｊ２ＥＥは分散アプリケーションの開発および実行のためのサーバ指向プラットフォームである）のためのガベージコレクタまたはメモリリトリーバの稼働率など、より具体的な要素または事象も測定され得る。
【００３４】
コンピュータハードウェアアーキテクチャのファイルシステムとは、例えば前記コンピュータアーキテクチャのファイルがそれに従って体系化され、扱われる一組の原則および規則を意味する。
【００３５】
実施形態によっては、システムは、構成リポジトリ（２）を含むハードウェアおよびソフトウェアコンピュータ構成（２０）も含む。実際には、システムのハードウェアおよびソフトウェア構成は、少なくとも１つのメモリ（２１、２２、２３）に、資源ごとおよびアプリケーションチェーンのアプリケーションごとの使用レベルの許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）を定義し、記憶する、使用リポジトリを確立する。
【００３６】
プローブ消費量による資源の使用レベルの測定は、ＣＩＯ（最高情報責任者）に、アプリケーションチェーンの任意のアプリケーションの資源消費量の現在のレベルと（計算による）予想レベルとに関する情報を与える。実施形態によっては、資源の消費量または使用の異なるレベルを正確かつ確実に特徴づけることができるように、使用レベルは数回、例えば３回以上測定されるが、これには限定されない。資源の使用レベルの反復測定は、一方では、許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）、すなわち、そこからアプリケーションの資源のパフォーマンスが低下する閾値を確立し、他方では、アプリケーションの各資源の許容可能消費量区間（Ｉｎ）、すなわち、アプリケーションの資源のパフォーマンスが低下せず、適正に機能する区間を確立する。実施形態によっては、使用レベルのパフォーマンス閾値は、資源ごとおよびアプリケーションチェーンのアプリケーションごとに最小閾値（Ｓｍｉｎ）と中間閾値（Ｓｉｎｔ）と最大閾値（Ｓｍａｘ）とからなるトリプレットを形成する３つの許容可能閾値を含む。この閾値のトリプレット（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）は、アプリケーションチェーンの任意のアプリケーションの資源ごとに使用リポジトリ（２）の少なくとも１つのメモリ（２１、２２、２３）に記憶される。これらの異なる閾値は、信頼性のある指標または情報を定義し、確立しやすく、ＣＩＯによるアプリケーションのパフォーマンスの状態の認識に寄与するという利点を有する。実施形態によっては、消費量区間（Ｉｎ）は、測定リポジトリ（１）の使用レベルの測定値に基づいて確立され、資源ごとおよびアプリケーションチェーンのアプリケーション別に使用リポジトリ（２）のメモリ（２４）に記憶される。この区間は、例えば事前に行われた測定リポジトリ（１）の使用レベルの測定値に基づいて計算することができる。実際には、これらの事前測定により、アプリケーションの使用または消費量の季節性、したがって各物理または仮想アプリケーション上の資源の使用レベルの季節性を確立する。消費量区間は、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）に基づいて計算することもできる。この場合には、消費量区間は最小パフォーマンス閾値と中間閾値との間、中間閾値と最大閾値との間、または最小閾値と最大閾値との間とすることができる。
【００３７】
実施形態によっては、監視機構は測定されて測定リポジトリ（１）に記憶されている資源の使用レベルを、資源ごとおよびアプリケーションごとに使用リポジトリ（２）内に事前に確立されている、閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）および／または消費量区間（Ｉｎ）と比較する。測定された使用レベルと事前設定され使用リポジトリに記憶されている閾値および／または区間とのこの比較は、システムがアプリケーションチェーンの１つまたは複数のアプリケーションにおいて潜在的競合および／または異常動作を検出した場合、またはその問題が解決された場合に、以下で詳述するアラート機構（４）を作動させる。したがって、従来技術の解決策とは異なり、本発明のシステムは、資源のパフォーマンスの低下とその影響を受けることになる情報システムのアプリケーションとを関係付けるという利点を有する。したがって、本発明の実施形態によれば、情報システムのアプリケーションの監視およびアラートを設定することによって、生産インシデントを是正および予防する。
【００３８】
実施形態によっては、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）および／または消費量区間（Ｉｎ）を確立し、記憶するための使用レベルの測定は、生産前コンピュータ環境（アプリケーションのプログラムが部分的に実行される環境）または認定環境（アプリケーションのプログラムが試験される環境）において事前に行うことができる。したがって、この工程は、資源ごとおよびアプリケーション別の上流許容可能パフォーマンス閾値および／または消費量区間（Ｉｎ）を測定および確立して、コンピュータ生産段階に最も近いパフォーマンス閾値および消費量区間を生成し、アプリケーションパフォーマンスの低下の最適な検出を確実にする。
【００３９】
実施形態によっては、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）および／または消費量区間（Ｉｎ）を確立し、記憶するための使用レベルの測定は、事前設定されて使用リポジトリに記憶されているこれらの異なるパフォーマンス閾値および消費量区間を再定義および精緻化するために、コンピュータ生産環境において行うこともできる。この工程は、アプリケーションパフォーマンスが低下しているか否かの漸進的変化に応じて是正措置を実施することができるように、アプリケーションチェーンのアプリケーションの資源ごとのパフォーマンス閾値の漸進的変化を監視し、資源ごとおよびアプリケーションごとのパフォーマンス閾値および消費量区間の最適較正を得るための再測定および確立を再び行う。
【００４０】
図１の例について示すように、実施形態によっては、使用リポジトリ（２）は、少なくとも１つのメモリに、資源ごとの異なる閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）別の実際の使用レベル（２１）と理論使用レベル（２２）とを確立し、記憶するための少なくとも１つのハードウェアおよびソフトウェア構成を含む。この場合、相互作用ＬｒＲｐＳｉのトリプレット（Ｎｕｊ，Ａｉ，Ｒｐ）またはダブレット（Ｎｕｊ，Ｎｕｒｐ）は、
−  メモリ（２１）に、各資源Ｒｊの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）ごとの実際の使用レベルＮｕｍｒＲｊのリスト；
−  メモリ（２２）に、各資源Ｒｑの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）ごとの理論使用レベルＮｕｍｔＲｑのリストを記憶する。
【００４１】
各資源の理論上の使用レベルは、例えば、類似のインフラストラクチャ上のアバカス（例えばネットワークまたはディスクスループット）に応じて取得されるが、これには限定されない。各資源の実際の使用レベルについては、例えば異なる期間にわたる異なるプローブの結果を分析することによって取得されるが、これには限定されない。
【００４２】
実施形態によっては、測定リポジトリ（１）は、資源別およびアプリケーション別の使用リポジトリ（２）のメモリ（２３）に、使用レベルの許容可能パフォーマンスの「季節的」閾値（Ｓｍｉｎ、Ｓｍｉｎ、Ｓｍａｘ）を確立し記憶するために、使用変動の大きい資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリ（１１）に記憶するためのハードウェアおよびソフトウェア構成を含む。この場合、相互作用ＬｒＲｐＳｉのためにトリプレット（Ｎｕｊ，Ａｉ，Ｒｐ）またはダブレット（Ｎｕｊ，Ｎｕｒｐ）は、
−  メモリ（２１）に、各資源Ｒｊの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）ごとの実際の使用レベルＮｕｍｒＲｊのリスト；
−  メモリ（２２）に、各資源Ｒｑの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）ごとの理論使用レベルＮｕｍｔＲｑのリスト；
−  メモリ（２３）に、各資源Ｒｏの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）ごとの実際の使用レベルＮｕｍｓＲｏのリストを記憶する。
【００４３】
資源ごとの季節的使用レベルは、例えば各アプリケーションの資源ごとの全使用周期中（例えば資源またはアプリケーションの使用の変動性に応じて１ヶ月間、３ヶ月間または１年間）に異なるプローブを分析することによって取得されるが、これには限定されない。
【００４４】
これらのパラメータのリストは、資源、アプリケーション、および使用の種類（実際の使用、理論上の使用および／または季節的使用）に応じた、アプリケーションチェーンを構成するアプリケーション（またはサーバ）上の資源の測定された使用レベルと使用リポジトリ（２）の許容可能パフォーマンスの閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）との比較を可能にすることができる。この比較は、パフォーマンス問題のない期間Ｐｎｄｐｊとの間で、パフォーマンス問題が発生する期間Ｐｄｐｊにわたって行われる。その目的は、アプリケーションチェーンのアプリケーションの資源の異常動作を是正することができるように、資源が使用レベルまたは異常消費量または最大レベル付近に達したことを検証し、アプリケーションの資源のこの使用レベルについてアラート機構を設定することである。アプリケーションパフォーマンスのこれらの比較分析を行うことによって、生産中のインシデントの時間が自動的に低減する。
【００４５】
実施形態によっては、システムは、測定リポジトリ（１）および使用リポジトリ（２）とに応じたパフォーマンス問題のカテゴリ化モジュール（３）も含む。
【００４６】
パフォーマンス問題のカテゴリ化モジュール（３）は、以下の動作によりカテゴリ化を構成するための少なくとも１つのハードウェアおよびソフトウェア構成（３０）を含む。
−  メモリ（３１）に記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成；または
−  測定された使用レベルが資源の最大閾値を上回る場合にメモリ（３２）内に記憶される「ハードウェア異常」カテゴリを作成するために、測定リポジトリにおいて利用可能な資源の測定された使用レベルと使用リポジトリにおいて利用可能なアプリケーションの各資源の使用レベルの許容可能パフォーマンスの最大閾値との比較；または
−  測定された使用レベルが資源の許容可能消費量区間（Ｉｎ）外である場合にメモリ（３３）に記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するために、許容可能消費量区間（Ｉｎ）における測定リポジトリにおいて利用可能な資源の測定された使用レベルを使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルと比較；または
−  アプリケーションの資源のニーズの季節性の規則とメモリ（３４）に記憶された測定リポジトリにおいて利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源ごとおよびアプリケーションごとのパフォーマンス低下の「将来の消費量」の計算；
−  資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合にメモリ（３５）に記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するために、資源の将来の消費量の計算結果を使用リポジトリ内において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値と比較、または上記の動作のうちの少なくとも２つの動作の組合せ。
【００４７】
メモリ（３１）（例えばＩＯネットワークまたはディスク）内の「資源消費量」カテゴリの作成は、その使用レベルＮｕｒｊがアプリケーションチェーンを構成する異なるアプリケーション（Ａｋ、Ａｌ、．．．）上で識別される任意の資源Ｒｊを、「資源消費量」にカテゴリ化または分類することからなる規則を使用することによって実現され、前記資源Ｒｊの識別子は「資源消費量」専用のメモリ（３１）に記憶される。この作成は、資源ごとおよびアプリケーションごとに前記資源Ｒｊの総合使用レベルＮｕＧｒｊを作成するために、測定リポジトリ（１）のメモリにおいて利用可能なアプリケーションの資源間の相互作用を使用して行われる。総合使用レベルＮｕＧｒｊは、各アプリケーションＡｉ上で使用される資源のすべてのレベルＮｕｒｊの合計ΣＮｕｒＡｉをとることによって求められ、アプリケーションチェーンの任意のアプリケーション上の資源Ｒｊの合計測定消費量を表す。
【００４８】
メモリ（３２）内の「ハードウェア異常」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルＮｕｒｊが、使用リポジトリ（２）において利用可能な各資源Ｒｊの実際の使用レベルＮｕｍｒＲｊおよび／または理論使用レベルＮｕｍｔＲｊおよび／または季節的使用レベルＮｕｍｓＲｊの許容可能パフォーマンスの最大閾値に達したかまたは超えた場合、システムは、例えばアプリケーションチェーンのアプリケーションの資源の飽和後の異常を作成する。
【００４９】
メモリ（３３）における「アプリケーションパフォーマンス低下」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルＮｕｒｊが、使用リポジトリ（２）において利用可能な各資源Ｒｊの使用レベルの消費量区間外の場合。これは、例えばアプリケーションチェーンのアプリケーションの資源の異常動作時（例えば使われていないアプリケーションまたは、ＳＬＡの低下を引き起こすクラスタインスタンス上の問題など）の場合である。
【００５０】
メモリ（３４）における「将来の消費量」カテゴリの作成は、「季節性」と呼ばれる規則と資源の現在の使用レベルとに基づいて行われる。資源またはアプリケーションの使用レベルは時間（例えば１日、１週間、１ヶ月または１年の１つまたは複数の時）にわたり変動する可能性があり、それによってアプリケーションチェーンを構成する異なるアプリケーションにわたって資源の使用レベルが変動することは明らかであろう。例えば、一部のアプリケーションは水曜日に需要がより少ない場合があり、これはパートタイマーの標準的な週日休暇によって説明され得る。別の非限定的な例として、金融アプリケーションは一般に、月次決算または四半期決算期間中に使用レベルが高くなる。このように、アプリケーションの使用のあらゆる漸進的変化は、（特にアプリケーションのユーザおよび事業活動の挙動により）アプリケーションによって異なるとともに時間とともに漸進的に変化する季節的規則によって定義され得る。これにより、情報システムのアプリケーションパフォーマンスの問題を自動的かつ連続的に監視し、アラートするためのシステムを採用する必要性の説明がつく。
【００５１】
メモリ（３５）における「アプリケーションパフォーマンス予防」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルＮｕｒｊに基づく将来の消費量の計算の結果が、アプリケーションの飽和のリスクを示している場合。例えば、これに限定されるものではないが、ＣＰＵなどの資源の季節性規則が、期間Ｐ０＋６０ｍ（ｍは任意の存続期間を定義する）にその資源の使用レベル（すなわち将来の消費量）がその期間Ｐ０の３．２倍になると規定している場合である。このため、期間Ｐ０に、ＣＰＵの資源の測定された使用レベルがＣＰＵの合計サイズの２６％となる場合である。測定された使用レベルに季節性規則の予測を乗じて得られるこの資源の将来の消費量の結果（日付Ｄｔ＝Ｐ０＋６０ｍの季節性の規則によれば、使用レベルの２６％に３．２を乗じてＣＰＵの合計サイズの８３．２％という結果が得られる）が、飽和リスクを示す上で重要となり、このＣＰＵの飽和問題を（例えばＣＰＵメモリを増強することによって）是正するようにアラートが設定される。
【００５２】
実施形態によっては、システムは、監視機構がアプリケーションチェーン内の１つまたは複数のアプリケーションのパフォーマンス問題を検出すると、またはその問題が解決されると、アラート機構（４）を実行するためのハードウェアおよびソフトウェアコンピュータ構成（４０）も含む。
【００５３】
アラート機構は、少なくとも１つのメモリ（４１、４２、４３）に以下のアラートのうちの少なくとも１つまたは複数を作成し、記憶する。
−  測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「ハードウェア異常」アラート；
−  測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリ内で利用可能な前記資源の許容可能消費量区間（Ｉｎ）外にある場合の「アプリケーションパフォーマンス低下」アラート；
−  カテゴリ化モジュールのメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「予防アプリケーションパフォーマンス」アラート。
【００５４】
「ハードウェア異常」アラートは、生産中の使用レベルが異常な場合に是正措置を設定するためにメモリ（４１）に記憶される。この是正措置は、一般に、例えば、これに限定されるものではないが、メモリまたはプロセッサの増強や（スペースを追加するかファイルを削除するなどによる）ディスク上のスペースの開放など、仮想または物理コンピュータシステムのハードウェアまたはソフトウェア構成を変更する。
【００５５】
「アプリケーションパフォーマンス低下」アラートは、アプリケーションチェーン上でパフォーマンスの低下が検出された場合に適切な是正措置を設定するためにメモリ（４２）に記憶される。この是正措置は、一般に、アプリケーションを監視して、例えば、これに限定されるものではないが、アプリケーションの非稼働、ＳＬＡの低下を引き起こすクラスタインスタンス上の問題などの問題の原因を決定する。このアラートは、資源の測定された使用レベルが、システムの使用リポジトリに記憶されているその事前設定資源の許容可能消費量区間（Ｉｎ）外にある場合に設定される。この区間は、アプリケーションの資源ごとの使用レベルの事前の測定値に基づいて、または資源別およびアプリケーション別のレベルの許容可能消費量の区間に基づいて設定可能である。
【００５６】
「予防アプリケーションパフォーマンス」アラートは、システムの目的が将来の問題の予防と予測である場合に、該当資源についてパフォーマンスの漸進的変化の推奨事項を設定するために、メモリ（４３）に記憶される。したがって、アプリケーションの将来の資源消費量の予測に関して、最終期限に是正プログラムが確立される。したがって、この構成は、アプリケーションパフォーマンスの問題を制限し是正することになる最適是正プログラムを設定することができるように、時間を得る。
【００５７】
実施形態によっては、システムは、是正プログラム（５）を含むハードウェアおよびソフトウェア構成を含む。実際には、例えば図１および図２に示すように、システムによって検出されたアラートに従って適切な是正プログラム（５）を設定することができるように、異なる種類のアラートが処理プログラムによって分析される。
【００５８】
実施形態によっては、システムは、アプリケーションチェーンの１つまたは複数のアプリケーションの異常、またはアプリケーションの重要資源の過剰消費または将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができる。
【００５９】
図２の例について示すように、この監視機構は、各資源およびアプリケーション別の使用レベルの測定値を収集し、これらは、パフォーマンス問題を識別するために、カテゴリ化モジュール（３）のメモリ（３１）において以下のようにしてカテゴリ化され記憶されることになる。
−  資源ごとおよびアプリケーションごとに事前に確立されたパフォーマンス閾値（Ｓｍｉｎ、Ｓｉｎｔ、Ｓｍａｘ）との比較により、特に最大パフォーマンス閾値に達している資源が、システムによりカテゴリ化され、カテゴリ化モジュール（３）のメモリ（３２）に記憶される；
−  資源ごとおよびアプリケーションごとに事前確立された消費量区間（Ｉｎ）との比較により、特に、許容可能消費量区間から外れる資源がシステムによってカテゴリ化されてカテゴリ化モジュール（３）のメモリ（３３）に記憶される；
−  資源ごとおよびアプリケーションごとの将来の消費量を計算することにより、特にパフォーマンス問題のリスクを有することになる資源がシステムによってカテゴリ化され、カテゴリ化モジュール（３）のメモリ（３４）に記憶される。
【００６０】
使用レベルが異常な場合、システムは自動的かつ継続的アラートによって改善策を設定する。したがって、検出されたパフォーマンス問題に応じて、システムはアラート機構（４）と適合する是正プログラム（５）とを設定する。例えば、カテゴリ化モジュール（３）が資源の測定された使用レベルがその許容可能パフォーマンスの最大閾値に達したことを示す場合、アラート機構は、その資源に対して適合する是正プログラムを設定するために、「ハードウェア異常」アラートをメモリ（４１）に確立する。カテゴリ化モジュール（３）が資源の使用レベルが許容可能消費量の区間外にあることを示す場合、アラート機構は、前記資源に対して適合する是正プログラムを設定するために「アプリケーションパフォーマンス低下」アラートをメモリ（４２）に確立する。最後に、カテゴリ化モジュール（３）が、資源の使用レベルが低下のリスク、例えば資源の飽和を呈していることを示す場合、アラート機構は、その資源に対して適合する是正プログラムを設定するために「予防アプリケーションパフォーマンス」アラートをメモリ（４３）に確立する。
【００６１】
本発明は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、本願の実施形態のうちの１つによるシステムを制御する方法にも関する。この方法は、
資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップと、
アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
測定された各資源および各アプリケーションの最小閾値（Ｓｍｉｎ）と最大閾値（Ｓｍａｘ）と中間閾値（Ｓｉｎｔ）とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップで取得されたデータに基づいて、使用リポジトリ（２）を構築するステップと、
使用リポジトリ（２）と、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて、、１つまたは複数の資源のパフォーマンス問題をカテゴリ化し、記憶するステップと、
測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値と比較するステップと、
アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップで取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、を含む。
【００６２】
実施形態によっては、アプリケーションチェーンのアプリケーションを連続して監視し、アラートするために、測定された使用レベルを許容可能パフォーマンス閾値と比較するステップが連続的に反復される。
【００６３】
図２の例について示すように、測定リポジトリ（１）のアプリケーションチェーンの資源ごとのアプリケーション別および季節性別の使用レベルの測定値は、カテゴリ化され、カテゴリ化モジュール（３）のメモリ（３１）に記憶される。アプリケーションチェーン上のアプリケーションパフォーマンスの問題を監視し、ＣＩＯにアラートするために、これらの測定値は、許容可能パフォーマンス閾値と、または資源ごとにアプリケーション別に事前設定されている許容可能消費量の事前設定区間と比較される。測定リポジトリ（１）の使用レベルのこれらの測定値は、以下の３つの異なるステップで比較される。
−  まず、測定されたレベルが使用リポジトリ（２）の最大パフォーマンス閾値（Ｓｍａｘ）と比較され、使用レベルがその最大パフォーマンス閾値に達している場合、システムによって異常適用アラート（４１）が設定される第１のステップ；
−  次に、第１のステップが異常を示さない場合、第２のステップにおいて、使用レベルが使用リポジトリ（２）の消費量区間（Ｉｎ）と比較され、使用レベルがその消費量区間外にある場合、システムによって「アプリケーションパフォーマンス低下」アラート（４２）が設定され；
−  次に、第２のステップがパフォーマンスの低下を示さない場合、第３のステップにおいて、測定された使用レベルに基づいて将来の消費量の計算が行われ、使用レベルの測定が資源飽和のリスクを示す場合、システムによって「予防アプリケーションパフォーマンス」アラート（４３）が設定され；
−  最後に、第３のステップが資源飽和のリスクを示さない場合、自動的かつ定期的に監視してアプリケーションチェーンにおいてパフォーマンス問題が発生した場合にアラートするために、使用レベルの新たな測定が行われる。
【００６４】
したがって、この方法のこれらの異なるステップは、コンピュータシステムにおけるパフォーマンス問題を制限することにより、またはそのような問題なしにコンピュータの動作の制御を最適化することができるように、連続的かつ自動的に行われる。本発明のアプリケーションパフォーマンス監視方法は、アプリケーションパフォーマンスの低下を迅速かつ自動的に識別し、企業コンピュータシステムのアプリケーションごとに連続的かつ適合した改善のための計画を設定するという利点を有する。
【００６５】
本願は、様々な技術的特徴および利点について図面および／または様々な実施形態を参照しながら説明している。当業者は、明示的に別様に記載されているか、または技術的特徴が相容れないか、または本願に記載の技術的問題のうちの少なくとも１つの解決策を提供しない場合を除き、ある実施形態の技術的特徴を実際には別の実施形態の特徴と組み合わせることが可能であることがわかるであろう。また、明示的に別様に記載されていない限り、ある実施形態において記載されている技術的特徴はその態様のその他の特徴とは分離され得る。
【００６６】
本発明が、特許される本発明の適用範囲から逸脱することなく他の多くの特定の形態の実施形態も可能にすることが、当業者には明かであるはずである。したがって、開示の実施形態は例示的なものとみなされるべきであり、特許請求の範囲によって定義されている範囲において変更されることができ、本発明は上述の詳細に限定されてはならない。
【符号の説明】
【００６７】
１  測定リポジトリ
２  使用リポジトリ
３  カテゴリ化モジュール
４  アラート機構
５  是正プログラム
１０、２０、４０  ハードウェアおよびソフトウェアコンピュータ構成
１１、２１、２２、２３、２４、３１、３２、３３、３４、３５、４１、４２、４３  メモリ
【図１】
2018109973.tif 000003
【図２】
2018109973.tif 000004
【外国語明細書】
2018109973000001.pdf