(57)【要約】【課題】  周期的又はその他の形式のプロセスの間の異常を自動的に検知する。【解決手段】  本発明のモニタリングシステムには、プロセスを表すシグネチャを生成するシグネチャ生成モジュール２２、生成されたシグネチャを継続的に更新するシグネチャ更新モジュール２４、更新されたシグネチャからの偏差に基づいて異常を検知する異常検知モジュール２６を備える。【選択図】  図２
2004348740.tif 000002
【特許請求の範囲】
【請求項１】
プロセスをモニターする方法において、
前記プロセスを表すシグネチャを生成するステップと、
前記生成されたシグネチャを継続的に更新するステップと、
前記継続的に更新されるシグネチャに基づいて異常を検知するステップと
を備えることを特徴とする方法。
【請求項２】
前記シグネチャを生成するステップは、平均と標準偏差を計算することを特徴とする請求項１記載の方法。
【請求項３】
前記シグネチャを生成するステップは、学習反応性比率を次第に増加させることにより学習を加速させることを特徴とする請求項２記載の方法。
【請求項４】
前記シグネチャを生成するステップは、最初に、移動平均と標準偏差を複数の間隔を通して繰り返すことを特徴とする請求項２記載の方法。
【請求項５】
前記シグネチャを更新するステップは、重み係数を用いて、新しく記録されたデータがそれよりも前に記録されたデータよりも大きなインパクトを有することを保証することを特徴とする請求項１記載の方法。
【請求項６】
前記生成されたシグネチャを更新するステップは、所定時間の移動平均を利用することにより、予期しない時に発生するイベントを明らかにすることを特徴とする請求項１記載の方法。
【請求項７】
前記異常を検出するステップは、測定値が上位のスレシホールドを上回るか、または、下位のスレシホールドを下回るかどうかを判断することを特徴とする請求項１記載の方法。
【請求項８】
ジッターオフセットに基づいて上位のスレシホールド境界と下位のスレシホールド境界を計算するステップを更に備えることを特徴とする請求項１記載の方法。
【請求項９】
請求項１記載の方法を実行するコンピュータが実行可能な命令を有することを特徴とするコンピュータにより読み取り可能な記録媒体。
【請求項１０】
プロセスを表す継続的に更新されるシグネチャに基づいて、プロセスの間に起きる異常を検出する方法において、
システムパラメータを継続的にモニターするステップと、
前記継続的に更新されるシグネチャに基づいて前記システムパラメータの数値の正常範囲を計算するステップと、
前記モニターされるシステムパラメータが前記正常範囲内にあるかどうかを判定するステップと、
前記モニターされたシステムパラメータが前記正常範囲外である場合には異常があることを知らせるステップと
を備えることを特徴とする方法。
【請求項１１】
平均と標準偏差を計算することによってシグネチャを生成するステップを更に備えることを特徴とする請求項１０記載の方法。
【請求項１２】
前記シグネチャを生成するステップは、学習反応比率を次第に増加させることにより学習を加速させることを特徴とする請求項１１記載の方法。
【請求項１３】
前記シグネチャを生成するステップは、最初に、移動平均と標準偏差を複数の間隔の間繰り返すことを特徴とする請求項１１記載の方法。
【請求項１４】
前記数値の正常範囲を計算するステップは、重み付け係数を用いることにより、新しく記録されたデータがそれよりも前に記録されたデータよりも大きなインパクトを有することを保証することを特徴とする請求項１０記載の方法。
【請求項１５】
前記数値の正常範囲を計算するステップは、所定時間の移動平均を利用することにより、予期しない時に発生するイベントを明らかにすることを特徴とする請求項１０記載の方法。
【請求項１６】
前記モニターされるシステムパラメータが数値の正常範囲内にあるかどうかを判定するステップは、モニターされるシステムパラメータが上位のスレシホールドを上回るか又は下位のスレシホールドを下回るかどうかを判断することを特徴とする請求項１０記載の方法。
【請求項１７】
ジッターオフセットに基づいて上位と下位のスレシホールド境界を計算するステップを更に備えることを特徴とする請求項１６記載の方法。
【請求項１８】
請求項１０記載の方法を実行するコンピュータが実行可能な命令を有することを特徴とするコンピュータにより読み取り可能な記録媒体。
【請求項１９】
コンピューティングシステム環境の異常を検出するのに役立つシグネチャを生成する方法において、
学習反応性比率を設定するステップと、
システムパラメータをモニターするステップと、
所望の値に達するまで固定間隔で前記学習反応性比率を調整するステップと、
各間隔の平均と標準偏差を計算するステップと、
前記平均と前記標準偏差と前記学習反応性比率とを用いて前記シグネチャを生成するステップと
を備えることを特徴とする方法。
【請求項２０】
生成されたシグネチャを継続的に更新するステップを更に備えることを特徴とする請求項１９記載の方法。
【請求項２１】
更新されたシグネチャに基づいて異常を検出するステップを更に備えることを特徴とする請求項２０記載の方法。
【請求項２２】
シグネチャを生成するステップは、最初に、移動平均と標準偏差を複数の間隔を通して繰り返すことを特徴とする請求項１９記載の方法。
【請求項２３】
前記シグネチャを更新するステップは、重み付け係数を用いて新しく記録されたデータがそれよりも前に記録されたデータよりも大きなインパクトを有することを保証することを特徴とする請求項２０記載の方法。
【請求項２４】
前記生成されたシグネチャを更新するステップは、所定時間の移動平均を利用することにより、予期しない時に発生するイベントを明らかにすることを特徴とする請求項２０記載の方法。
【請求項２５】
前記異常を検出するステップは、測定値が上位のスレシホールドを上回るか又は下位のスレシホールドを下回るかどうかを判断することを特徴とする請求項２１記載の方法。
【請求項２６】
ジッターオフセットに基づいて上位及び下位のスレシホールド境界を計算するステップを更に備えることを特徴とする請求項２１記載の方法。
【請求項２７】
請求項１９記載の方法を実行するコンピュータが実行可能な命令を有することを特徴とするコンピュータにより読み取り可能な記録媒体。
【請求項２８】
コンピュータ化された環境で異常活動を検出するシステムにおいて、
継続的にシステムパラメータをモニターするモニタリング手段と、
前記システムパラメータの正常値を表す継続的に更新されるシグネチャと、
前記継続的に更新されるシグネチャに基づいて計算され、前記システムパラメータの正常値の範囲を含む異常インディケータと
を備えることを特徴とするシステム。
【請求項２９】
前記継続的に更新されるシグネチャは、平均と標準偏差とを備えることを特徴とする請求項２８記載のシステム。
【請求項３０】
前記継続的に更新されるシグネチャは、重み付け係数を備えることにより、新しく記録されるデータはそれよりも前に記録されたデータよりも大きなインパクトを有することを保証することを特徴とする請求項２８記載のシステム。
【請求項３１】
前記継続的に更新されるシグネチャは、所定期間の移動平均を備え、予期しない時に発生するイベントを明らかにすることを特徴とする請求項２８記載のシステム。
【請求項３２】
前記異常インディケータは、モニターされるシステムパラメータが数値の正常範囲内にあるかどうか、及び、モニターされるシステムパラメータが上位のスレシホールドを上回るか又は下位のスレシホールドを下回るかどうかを判断することを特徴とする請求項２８記載のシステム。
【請求項３３】
前記異常インディケータは、ジッターオフセットに基づいて上位及び下位のスレシホールド境界を計算することを特徴とする請求項２８記載のシステム。
【請求項３４】
プロセスをモニターするモニタリングシステムにおいて、
プロセスを表すシグネチャを生成するシグネチャ生成モジュールと、
前記生成されたシグネチャを継続的に更新するシグネチャ更新モジュールと、
前記更新されたシグネチャからの偏差に基づいて異常を検出する異常検出モジュールと
を備えることを特徴とするシステム。
【請求項３５】
前記シグネチャ生成モジュールは、平均と標準偏差を計算する手段を含むことを特徴とする請求項３４記載のシステム。
【請求項３６】
前記シグネチャ生成モジュールは、学習反応性比率を次第に増加させることにより加速学習を実行する手段を備えることを特徴とする請求項３５記載のシステム。
【請求項３７】
前記シグネチャの生成は、最初に、移動平均と標準偏差を複数の間隔を通して繰り返すことを特徴とする請求項３５記載のシステム。
【請求項３８】
前記シグネチャ更新モジュールは、重み付け係数を備えることにより、新しく記録されるデータはそれよりも前に記録されたデータよりも大きなインパクトを有することを保証することを特徴とする請求項３４記載のシステム。
【請求項３９】
前記シグネチャ更新モジュールは、所定時間の移動平均を計算することにより、予期しない時に発生するイベントを明らかにする手段を備えることを特徴とする請求項３４記載のシステム。
【請求項４０】
前記異常検出モジュールは、モニターされるシステムパラメータが上位のスレシホールドを上回るか又は下位のスレシホールドを下回るかどうかを判断することを特徴とする請求項３４記載のシステム。
【請求項４１】
前記異常検出モジュールは、ジッターオフセットに基づいて上位及び下位のスレシホールド境界を計算するメカニズムを含むことを特徴とする請求項３４記載のシステム。
【請求項４２】
プロセスの間の正常動作と異常動作を区別する方法において、
システムパラメータをモニターするステップと、
前記モニターされたシステムパラメータを表す数値データストリームをプロセスの状態に変換するステップと、
前記状態に基づいて正常動作と異常動作とを区別するステップと
を備えることを特徴とする方法。
【請求項４３】
前記数値データストリームを多重サブステートに変換するステップを更に備えることを特徴とする請求項４２記載の方法。
【請求項４４】
前記状態に基づいて異常の根本的原因を判断するステップを更に備えることを特徴とする請求項４２記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、システム管理を容易にするために、周期的(cyclical)なプロセス又はその他の種類のプロセスの間に、異常を検知する自動化の技術に関する。より詳細には、本発明の実施形態は、コンピュータ化されたシステム又はプロセスの動作の異常を検出することに関し、ビジネスの主要業績評価指標（キー・パフォーマンス・インディケータ）を追跡記録するのに向いている。
【背景技術】
【０００２】
ネットワーク化されたコンピューティング装置やシステムを利用することが増えるにつれ、これらの問題が広く影響力のあるインパクトを有するため、問題に対してこれらのシステムを監視することが必要となってきている。従来の方式を用い手動でこれらのシステムを監視することは、非実用的であり、また、多くの場合において、不可能である。
【０００３】
経験豊かなエキスパートは、工場内のエンジン又は何百もの機械の“ハム”(hum)を聞きとることができ、機械が正常に動作しているかどうかを判断できる。この技術は、サーバー又はデータセンターの場合は、効果的に利用することができない。サーバー又はデータセンターを分析するには、ビジネスサイクルの通常の変動(normal  ebb  and  tide)と、結論を出す前に何百もの測定をエキスパートに行わせることを可能とする該当のサーバー上の明確な効果に精通したサブジェクトマターエキスパート(subject  matter  expert)が必要である。データセンター内又は企業のいたるところにある何百ものサーバーに関する分析を手動で実行することは、あまりにも負担が重く、おそらく不可能であろう。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、技術は、異常に備えてコンピューティングシステムを監視するために発展している。一つの技術は、サンプリングのパラメータを識別し、サンプル結果と一定のスレシホールドとを比較する。その一定のスレシホールドを超える場合には、その技術は、異常を識別する。この技術は、しばしば誤った結果を得る。二つのシステムが同一の構成(configuration)、コンディション、利用法(usage)パターンを備える可能性は低いため、スレシホールドを決めるのは難しい。高すぎるスレシホールドを設定すると、異常の大半は検出されず、低すぎるスレシホールドを設定すると、この技術は、正常状態において過剰の数の警報を引き起こす。したがって、コストや複雑性にもかかわらず、この技術は、ある場所においては過大報告(over-reporting)を引き起こし、その他の場所において過少報告(under-reporting)を引き起こし、また、これらの場所は、たった一日の間に変わる。
【０００５】
現在のところ、エージェントから収集したデータの中で重要な部分は、数値データである。追跡記録される変数(variables)の数や必要な分解能(resolution)が増大するにつれて、その部分は、１０倍から１００倍あるいはもっと大きな倍数で増えていく可能性がある。
【０００６】
データは、究極的には、集合体(aggregation)、傾向(trending)、キャパシティプランニング・リポーティング(capacity  planning and reporting)のために用いられる。大抵の場合、収集された生データは、使用されることはない。このデータ収集が負荷となり、拡張性(scalability)は、著しく制限される。
【０００７】
これらの問題は、スレシホールドの微調整(fine-tuning)に関するコンサルティングサービスの顧客要求を招く。さらに、顧客は、環境をつくりだす知識に対する要求を増やすことにより管理者がカスタムチェンジを行うことができるようにし、さらに、顧客は、グループでの競合解消ポリシー(conflict  resolution  policies)とサーバーレベルを含んだルールに優先する規定(provision)に対する要求を増やしている。さらに、顧客は、事例(instance)レベル毎の独自化（personalization）のための条件(attributes)の大幅な開示に対する要求を増やしている。
【０００８】
残念ながら、これらの要求を満たすことは困難である。大抵の管理者は、これらのシステムの中に包含される変数を理解しておらず、そのうえ、スレシホールドを思慮深くセットするための彼ら独自の設定(installation)を十分良く理解しない。その上、多数のサーバーに対する独自化は、エキスパートですら仕事が大きすぎる。単にシステムパラメータに基づいたコンサルティングでは、周期的(cyclic)なビジネスリズムをとらえることができず、異常の大部分を見落としやすい。最後に、たとえ、コンサルタントが、当初、ある特定のシステムのニーズを処理できても、ビジネスサイクルと構成が変化するにつれて、スレシホールドは急速に陳腐化する。
【０００９】
コンサルティングエージェントを用いた現存のテクニックは、大量のデータ収集と記憶を伴う。時間をかけて変数が追跡記録されるにつれて、データ量は急速に増えていく可能性がある。収集されたデータの多くは使用されず、過剰なデータを保持することによってシステムの拡張性(scalability)は制限される。
【００１０】
前述の問題を回避しつつ、自動的に異常検出を提供する技術が求められる。この技術は、過剰のデータを保持することを避けなければならず、多様な環境やプロセス内部の機能に適応しなければならない。
【課題を解決するための手段】
【００１１】
一の態様において、本発明は、プロセスを監視する方法に関する。その方法は、プロセスを表すシグネチャ(signature)を生成すること、生成されたシグネチャを継続的に更新すること、継続的に更新されたシグネチャに基づいて異常を検知することを備える。
【００１２】
更なる態様においては、本発明は、プロセスを表す継続的に更新されるシグネチャに基づいて、プロセスの間に起きる異常を検出する方法を含む。その方法は、システムパラメータを継続的に監視すること、継続的に更新されるシグネチャに基づいて、システムパラメータの正常な数値範囲を計算すること、モニターするシステムパラメータが正常範囲内にあるかどうかを判定すること、モニターするシステムパラメータが正常範囲外にある場合には、異常が存在していることを知らせることを備える。
【００１３】
別の態様においては、本発明は、コンピューティングシステム環境の異常を検出するのに役立つシグネチャを生成する方法を含む。その方法は、学習反応性定数(learning  responsiveness  constant)を設定すること、システムパラメータをモニターすること、所望の値に達するまで、一定間隔で学習反応性定数を調節することを備える。その方法は、更に、各間隔での平均値と標準偏差を計算すること、平均値と標準偏差と学習反応性定数を使用してシグネチャを生成することを備える。
【００１４】
更なる態様においては、本発明は、コンピュータ化された環境の異常活動を検出するシステムを含む。そのシステムは、継続的にシステムパラメータをモニターする監視手段、システムパラメータの正常値を表す継続的に更新されるシグネチャ、継続的に更新されるシグネチャに基づいて計算される異常インジケータ(abnormality  indicator)を備え、その異常インジケータは、システムパラメータの正常値の範囲を含む。
【００１５】
さらに別の態様においては、本発明は、プロセスを監視するモニタリングシステムを備える。そのモニタリングシステムには、プロセスを表すシグネチャを生成するシグネチャ生成モジュール、生成されたシグネチャを継続的に更新するシグネチャ更新モジュール、更新されたシグネチャとの偏差に基づいて異常を検知する異常検知モジュールを備える。
【発明を実施するための最良の形態】
【００１６】
本発明の実施形態は、コンピュータ化されたシステム又はビジネスプロセスの内部の異常を検出するシステム及び方法に関する。本発明の実施形態は、コンピュータ化されたシステム又はビジネスプロセスを継続的に監視する機能、システム又はプロセスを記述するシグネチャを生成及び継続的に更新する機能、及び、更新されたシグネチャに基づいてコンピュータ化されたシステム又はビジネスプロセスで起こった異常を検出する機能を備える。
【００１７】
本発明のシステム及び方法は、あるビジネスサイクルにしたがって時間的に変化する信号のシグネチャを組み立て、そして、継続的に更新する。このシグネチャは、少なくとも２つの目的、すなわち、（１）異常が発生したときに、それを識別すること、（２）先のビジネスサイクル(the  last  business  cycle)からのサンプルから更新シグネチャを計算すること、を有する。本システムは、ヒストリカル(historical)な生データを保存する必要性を予め避ける。
【００１８】
本発明の概要を簡単に提供して、本発明の実施形態を図１から図９を参照しながら論ずる。本発明のオペレーティング環境の例を以下に説明する。
【００１９】
（実行環境の例）
図１は、本発明を実行することができる適切なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用又は機能の範囲に関して如何なる限定を示唆するつもりはない。コンピューティングシステム環境１００は、代表的なコンピューティングシステム環境１００の中に図示されている構成要素のいずれか１つ或いは構成要素の組み合わせに関係する如何なる依存も必要条件をも有するものとして解釈すべきではない。
【００２０】
本発明は、コンピュータにより実行可能なプログラムモジュール等のコンピュータ実行可能な命令の一般的な文脈により記述することができる。一般的に、プログラムモジュールは、特有なタスクを実行するか又は特有な抽象データ型を実装するルーティン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに、当業者であれば、ハンドヘルド装置、マルチプロセッサ、マルチプロセッサベース又はプログラマブルのコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータ等の他のコンピュータシステム構成を用いて本発明を実現しても構わないことを理解するであろう。  
タスクが通信ネットワークを介して連結されるリモートプロセッシングユニットにより実行される分散コンピューティング環境上でも本発明を実行できる。分散コンピューティング環境においては、プログラムモジュールは、メモリ記憶装置を含んだローカルとリモートの両コンピュータ記憶媒体の中に置かれることがある。
【００２１】
図１を参照すると、本発明を実装する代表的なシステム１００は、プロセッシングユニット１２０と、システムメモリ１３０と、システムメモリを含んだ様々なシステム構成要素をプロセッシングユニット１２０につなぐシステムバス１２１とを備えるコンピュータ１１０形式の汎用コンピューティング装置を含む。
【００２２】
コンピュータ１１０は一般的にコンピュータにより読み取り可能な多種類の媒体を含んでいる。例として、コンピュータにより読み取り可能な媒体は、コンピュータ記憶媒体と通信媒体とから構成されるが、これらに限定されない。
【００２３】
システムメモリ１３０は、リードオンリーメモリ（ROM）１３１及びランダムアクセスメモリ(RAM)１３２等の揮発性及び／又は不揮発性メモリの形式のコンピュータ記憶媒体を備える。起動中のように、コンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーティンを含む基本入出力システム（BIOS）１３３は、一般的に、ROM１３１に記憶されている。RAM１３２は、一般的に、直ちにプロセッシングユニット１２０にアクセスされ、及び／又はやがてプロセッシングユニット１２０により操作されるデータ及び／又はプログラムモジュールを備える。例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、とプログラムデータ１３７を示すが、これらに限定されない。
【００２４】
コンピュータ１１０は、他の取り外し式／取り外し不能式、揮発性／不揮発性コンピュータ記憶媒体もまた含んでもよい。唯一の例として、図１は、取り外し不可で不揮発性の磁気媒体との間で読み取り又は書き込みを行うハードディスクドライブ１４１と、取り外し式で不揮発の磁気ディスク１５２との間で読み取り又は書き込みを行う磁気ディスクドライブ１５１と、例えばＣＤ−ROM又は他の光メディア等の取り外し式で不揮発性の光ディスク１５６との間で読み取り又は書き込みを行う光ディスクドライブ１５５を示す。代表的なオペレーティング環境で使用することができる他の取り外し式／不揮発性、揮発性／不揮発性のコンピュータ記憶メディアには、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、ディジタルビデオテープ、ソリッドステートRAM(solid  state  RAM)、ソリッドステートROM(solid  state  ROM)等が含まれるが、これらに限定されない。ハードディスクドライブ１４１は、一般的に、インタフェース１４０等の取り外し不能式メモリインタフェースを通してシステムバスに接続され、また、磁気ディスクドライブ１５１と光ディスクドライブ１５５は、一般的に、インタフェース１５０等の取り外し式メモリインタフェースによってシステムバス１２１に接続される。
【００２５】
上述し、かつ、図1に示されたドライブとそれらと関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ読み取り可能な命令、データ構造、プログラムモジュールおよびその他のデータの記憶を提供する。図１において、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７を記憶するものとして示される。尚、これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６及びプログラムデータ１３７と同じであっても、異なっていてもよい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６及びプログラムデータ１４７には、最小限、それらが異なるコピーであることを示すために、ここでは異なる番号が付与される。ユーザは、キーボード１６２や、一般にはマウス、トラックボール又はタッチパッド(touch  pad)と呼ばれるポインティングデバイス１６１等の入力装置を使ってコンピュータ１１０にコマンドや情報を入力してもよい。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、サテライトディシュ(satellite  dish)、スキャナ等が含まれてもよい。これら又は他の入力装置は、システムバス１２１につながれるユーザ入力インンターフェース１６０を介してプロセッシングユニット１２０と接続されることが多いが、パラレルポート、ゲームポート又はユニバーサルシリアルバス（USB）等の他のインタフェースやバス構造によって接続されてもよい。モニター１９１或いは他の種類のディスプレイ装置は、ビデオインタフェース１９０等のインタフェースを介してシステムバス１２１にも接続される。加えて、モニター、コンピュータは、スピーカ１９７やプリンタ１９６等の、出力周辺インタフェース１９５を通して接続されるかもしれない他の周辺出力装置をまた含んでもよい。
【００２６】
コンピュータ１１０は、リモートコンピュータ１８０等の１つ又はより多くのリモートコンピュータへの論理コネクションを用いて、ネットワーク環境の中で機能してもよい。リモートコンピュータ１８０は、メモリ記憶装置１８１だけが図１に示されているが、パーソナルコンピュータでよく、一般的には、コンピュータ１１０に関連する上述した構成要素の多く又は全てを含む。図１に示されたロジカルコネクションは、ローカルエリアネットワーク（LAN）１７１と広域エリアネットワーク（WAN）１７３を含むが、他のネットワークを含んでもよい。
【００２７】
LANネットワーキング環境において使用する場合には、コンピュータ１１０は、ネットワークインタフェース又はアダプター１７０を介してLAN１７１に接続される。WANネットワーキング環境において使用する場合、コンピュータ１１０は、一般的には、モデム１７２或いはインターネット等のWAN１７３上で通信を確立する他の手段を備える。モデム１７２は、内部或いは外部にあっても良いが、ユーザ入力インタフェース１６０を介して、又は、他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境においては、コンピュータ１１０に関連して描かれるプログラムモジュール又はそれの一部分をリモートメモリ記憶装置の中に格納しても良い。例として、図１は、メモリ装置１８１に存するリモートアプリケーションプログラム１８５を示すが、これに限定されない。上記のネットワークコネクションは例であり、コンピュータ間の通信リンクを確立する他の手段を用いてもよいことが理解されるであろう。コンピュータ１１０の他の多くの内部の構成要素は図示されていないが、当業者であれば、そのような構成要素や相互接続が周知であることを理解するであろう。したがって、コンピュータ１１０の内部構成に関する詳細を本発明に関連させてさらに開示する必要はない。
【００２８】
（本システムの実施形態）
図２は、本発明の一実施形態のシステムの構成要素を示すブロック図である。モニタリングシステム１０は、選択されたパラメータを監視するシステム４０に接続される。モニタリングシステム１０は、プロセッサ１２、ネットワークインタフェース１４、オペレータインタフェース１６、メモリ２０を含むことができる。プロセッサ１２、ネットワークインタフェース１４、メモリ２０は、実質的には、図１を参照して上述したものと類似してもよい。メモリ２０は、シグネチャ生成モジュール２２、シグネチャ更新モジュール、異常検出モジュール２６を含むことができる。
【００２９】
上記の構成要素は、機能して、システムに関連する複数の変数を測定する。これら変数の幾つかは、時間的に変化する数値変数である。測定される可能性がある１つの変数は、同時に起きるセッション又はトランザクションの数を測定するための使用(usage)変数である。使用変数は、コンシューマーがシステムに加えたストレスの表示を提供する。使用変数の例としては、（１）同時にログオンしているユーザ数、（２）１秒当たりのトランザクションリクエストの数、（３）リクエスト到達のレート、（４）１秒あたりの受信パケット、（５）１秒当たりのウェブヒット(web  hits)が挙げられる。たいていの製造環境においては、使用法(usage)は、ビジネスアワーにおける上昇及びノンビジネスアワーやウイークエンド等における下降に基づいたビジネスサイクルパターンに追随する。ウイークリーサイクルは、通常、一貫性のあるパターンを有する。一般的には、正常値を大きく上回るか又は下回る使用測度(usage  measure)は、トラブル又は異常を指し示すものである。
【００３０】
システム変数の別のセットは、稼働率(utilization)と関係する。これらの変数は、ストレスが加えられたことによるシステム内の負荷を表す。これらの変数の例としては、（１）CPU稼働率、（２）待ち行列の長さ(queue  lengths)、（３）１秒当たりのタスク切り替え、（４）メモリ稼働率、等がある。稼働率は、一般的に、使用の関数であり、したがって、上述したビジネスサイクルに追随する。しかしながら、これらの変数をあらゆる点で完全に同じものとして扱うことはできない。例えば、キュー長の合計又はクラスター内の全てのノードの全域でのCPU稼働率は、意味をもたない。通常、正常値を大きく上回るか又は下回る稼働率は、トラブル又は異常を指し示すものである。
【００３１】
システム変数の別のセットには、エラーと警告が含まれる。大抵のケースにおいて、これらのエラー又は警告は、故障又は設定ミスに起因する。エラーや警告の例には、（１）不正な形式のリクエスト、（２）パリティエラー、（３）４０４エラー、（４）クリティカルイベント、（５）ログオンエラー、等が含まれる。いくつかのエラーは、“正常（ノーマル）”である。“正常”エラーの例には、（１）過負荷の場合に設計にしたがってパケットをドロップするルータ、（２）WANの許容ビットエラーレート、（３）ウェブコンテンツが絶え間なく変化させることに起因して４０４エラーを生じさせるページ、（４）人々の一部は、ログオンするときに、ユーザ名／パスワードをミスタイプするであろうこと、が含まれる。その結果、たとえエラーであっても“ノーマル”パターンを有する。
【００３２】
上述の変数は、サービスリクエストのターンアラウンドタイムの測度であってもよい。そのようなサービス及びリクエストの例には、（１）接続試験用パケット(ping)のレスポンスタイム、（２）トランザクションレスポンスタイム、（３）ディスク書き込みレスポンスタイム、等がある。カスタマーは、サービスプロバイダーとオペレーションレベルアグリーメント(Operation  Level  Agreements,  OLAs)を締結することにより許容レベルでターンアラウンドタイムを維持する。レスポンスタイムは使用法(usage)と関連するが、その関連性は、非線形である。レスポンスタイムは、エラーレートとともに急激に増大する。
【００３３】
図３は、本発明の実施形態に従った方法を示すフローチャートである。手続きAで、モニタリングシステム１０は、署名を生成する。手続きBで、モニタリングシステム１０は、署名を更新する。手続きＣで、モニタリングシステム１０は、異常を検出し、報告する。
【００３４】
上述の署名は、既に知られたスレシホールド技術よりも異常検出のメカニズムを正確にさせる構成要素を含む。シグネチャの構成要素の一つは、“平均”値である。平均値を用いる技術の一つは、関係のある全ての変数のサンプルを単純に取得することと、それらの移動平均(running  average)を保持することを備えることができる。新しいサンプルがこの平均値の“適切な範囲(reasonable  range)“内にない場合には、新しいサンプルは、異常を明らかにするであろう。しかしながら、ピーク利用時の平均値とオフアワー(off  hours)での平均値に大きな隔たりがあるため、本システムは、所望の精度を得るために、より洗練された平均値の概念を用いる。
【００３５】
したがって、シグネチャは、時間を単位とした(by  time)平均値の概念を利用する。時間を単位とした平均値の概念には、周期的に変数をサンプリングすることと、さまざまな間隔で平均値を計算することが含まれる。例えば、モニタリングシステムは、３分間毎に変数をサンプルし、１週間の間、１５分間隔で平均値を算出することがあり得る。本システムは、その情報を保存し、シグネチャの中でそれを用いることになるであろう。
【００３６】
システムは、新しいサンプルを取得しながら、１５分間の平均値を算出し、それと“シグネチャ”とを比較する。この比較によりシステムは異常をフラグ(flag)で知らせることができる。時間に対する感度が良い平均化(time  sensitive  averaging)により、ビジネスサイクルにおける変動(variability)が明らかになる。しかしながら、システムは、その上に、異常が発生したと判断されないような平均値近辺の適切な範囲を決定しなければならない。
【００３７】
たとえ、定数を“適切な範囲”のために使用しても、定数値を使用することにより、問題が生ずるかもしれない。例えば、銀行は、日々、午後７時に閉店するかもしれない。銀行員は、会社を出る前に、毎晩、処理手続きを行う。他の日と比べてたくさんの残務を伴う日があるかもしれない。したがって、７時３０分から８時の間の処理手続きレートはまったく予測できない。適切な範囲として定数を使用することにより、これらの不規則な時間に多数の警告が発生するかもしれない。そして、その数が上昇すると、ほかのどこかの正規な不一致(legitimate  discrepancies)が失われるという影響がでる。平均値近辺の定数包絡線(constant  envelope)は、これらの状況に対しては的確ではない。
【００３８】
したがって、シグネチャは、標準偏差を用いて、適切な範囲を測定する。シグネチャは、全ての間隔の標準偏差を用い、倍数(multiple)として、包絡線又は適切な範囲を表現する。したがって、包絡線又は適切な範囲は、ウィークリービジネスサイクルの間の騒然とした時間帯(turbulent  times)ではより寛容(forgive)であり、通常の時間帯ではより厳しい(tighter)。標準偏差は以下のように表すことができる。
（１）  Sigma２＝  1/N(Summation  of  (Xi-Xavg)2  …  式１
ただし、Nはサンプル数、Xiは現在の平均値、Xavgは、算出された平均値。
【００３９】
この場合、シグネチャは、ビジネスサイクルのすべての時間間隔での平均と標準偏差の配列として表現される。包絡線は、以下のように表すことができる。
（２）Envelope  =  Xavg  +  /-  F*Sigma2  …  式２
ただし、  Fは許容差(tolerance)である。
【００４０】
（本方法の実施形態）
図４Ａと図４Ｂは、図３の手続きＡで実行されるシグネチャの生成を示す。シグネチャの生成は、同時に適用される２つの方法を用いて実行される。その２つの方法には、アクサレーティドラーニングコンポーネント(accelerated  learning  component)と、フェークリピートコンポーネント(fake  repeats  component)が含まれる。図４Ａは、アクサレーティドラーニングコンポーネントを示し、図４Ｂは、フェークリピートコンポーネントを示す。
【００４１】
図４Ａは、本発明の実施形態によるシグネチャを生成する方法の構成要素を示すフローチャートである。ステップＡ１０において、モニタリングシステム１０は、学習反応性比率を設定する。ステップＡ１２において、学習反応性比率は予め設定された間隔で増やされる。ステップＡ１４において、学習反応性比率が所望の値に達すると、処理は終了する。所望の値に達しない場合には、ステップＡ１２において、学習反応性比率は設定された間隔で再び増やされる。学習反応性比率が所望の値に達するとプロセスは終了する。例えば、最初の学習週間において、モニタリングシステムは、“１／学習反応性定数”に０をセットする。翌週には、モニタリングレスポンシブネスシステムは、比率に１をセットし、次に２をセットする等、所望のセットレートに到達するまで行う。このプロセスは、不十分は履歴が存在する場合には、学習を速める。十分な履歴が作られると、比率は、自動的に所望の目標に適合する。
【００４２】
図４Ｂは、本発明の実施形態に従ってシグネチャを生成する方法にて必要とされる手続きを示すフローチャートである。ステップＡ２０において、モニタリングシステム１０のシグネチャ生成モジュール２２は、データを選択し、設定間隔の平均データ値を計算する。ステップＡ２２において、シグネチャ生成モジュール２２は、設定間隔の標準偏差を計算する。ステップＡ２４において、シグネチャ生成モジュール２２は、計算された平均値と標準偏差を用いてシグネチャを生成する。ステップＡ２６において、シグネチャ生成モジュール２２は、学習期間について生成されたシグネチャを使用する。
【００４３】
最初は、移動平均と偏差が、一日のシグネチャを通して繰り返され、最初の日の後は、一日のシグネチャが週を通して繰り返され、それ以降、通常のシグネチャ更新が続く。最初の週には、シグネチャは、日の直線帯域に近づくように見え、２日目は日々繰り返される包絡線、週の最後には典型的なシグネチャの形をとるであろう。
初期のシグネチャは、幾つかの誤った正数(positives)をもたらすが、シグネチャが進化するにつれて、より正確な情報を提供するであろう。
【００４４】
図５は、本発明の実施形態に従ってシグネチャを更新する方法を示すフローチャートである。ステップＢ０２において、シグネチャ更新モジュール２４は、設定間隔で、選択された変数をサンプルする。ステップＢ０４において、シグネチャ更新モジュール２４は、設定間隔の平均値を計算する。ステップＢ０６において、シグネチャ更新モジュール２４は、設定間隔の標準偏差を計算する。ステップＢ０８において、シグネチャ更新モジュール２４は、古いシグネチャ、計算された平均値、標準偏差に基づいて新しいシグネチャを生成する。
【００４５】
長い時間をかけて学習する上述のプロセスは、長期にわたる営業実績の変化を考慮する。しかしながら、ある状況においては、ある時間に対して他よりも重みを与えることができることを保証する必要がある。例えば、証券仲買業(security  brokerage)は、３ヶ月毎に金曜日に起きる“トリプル・ウィッチング・アワー”（triple  witching  hour）として知られる時間帯に、大きな売買高(volume)を経験する。他の例としては、最近開店した店は、低い営業実績で始まる。しかしながら、最初の年にうわさが広まるにつれて、その店はより多くのビジネスを行う。シグネチャは、最新のデータが早めのデータよりも強いインパクトを有することを保証しなければならない。したがって、システムは、長期間にわたって、学習し、自らを自動的に調整しなければならない。
【００４６】
システムは、現在データ(current  data)とシグネチャ内の値の間の重み付け平均値を用いることによってこの目的を達成する。もし、水曜日の４時〜４時１５分の間の平均値と標準偏差とが各々XCavgとSigmaSであり、水曜日の４時〜４時１５分のシグネチャがXSavgとSigmaSならば、新しいシグネチャ値は、以下のように表すことができる。
（３）  New  XSavg  =  W1*(XSavg)  +  W2*(XCavg)  …  式３
（４）  New  SigmaS2  =  W1*(SigmaS2  +  XSavg2)  +  W2(SigmaC2  +  XCavg2)    (New  XSavg2)  …  式４
【００４７】
このモデルは、W1  +  W2  =  1  をセットし、ここで、W1はシグネチャの重みであり、W2は現在データの重みである。W2/W1は、上述した学習反応性定数比率である。その値が大きいほど、学習は早く起こり、さらに、過去の記憶がおぼろげになる。例えば、W1  =  2/3  、W2  =  1/3の場合は、今日のデータのインパクトは、今日には1/3rd、来週には2/9th、再来週には4/27th  等となる。
【００４８】
上述の技術は、コンピュータ的には非常に効率が良い。その理由は、現在のデータだけを使ってシグネチャの更新ができるからである。このシステムは、大量の古いデータを保持することを必要としない。
【００４９】
図６は、本発明の実施形態に従ってシグネチャ構成要素を取得する上述の方法を示すフローチャートである。ステップＢ１０において、モニタリングシステム１０は、シグネチャ平均に第一の重み係数を乗算する。ステップＢ１２において、モニタリングシステムは、新たに計算した平均に第２の重み係数を乗算する。ステップＢ１４において、モニタリングシステム１０は、ステップＢ１２で得られた計算結果とステップＢ１０で得られた計算結果を加算する。
【００５０】
図７は、本発明の実施形態に従って別のシグネチャ構成要素を取得する方法を示すフローチャートである。ステップＢ２０において、モニタリングシステムは、自乗シグネチャ平均(squared  signature  average)と自乗標準偏差(squared  standard  deviation)とを足す。ステップＢ２２において、モニタリングシステム１０は、ステップＢ２０による合計に第１の重み係数を乗算する。ステップＢ２４において、モニタリングシステム１０は、現自乗平均(current  squared  average)と現自乗標準偏差(current  squared  standard  deviation)とを加算する。ステップＢ２６において、モニタリングシステムは、Ｂ２４による合計に第２の重み係数を乗算する。ステップＢ２８において、モニタリングシステムは、Ｂ２４からの係数とシグネチャ係数を加算する。ステップＢ３０において、モニタリングシステムは新しいシグネチャ平均の自乗を減算する。
【００５１】
上述の係数は、振幅の変化からなるシグネチャを微調整するのに役立つ。その他の特徴は、発生時刻(occurrence  times)での変化を正確に反映できることを保証するために提供される。イベントは、予想されるよりも早くか又は遅く起きることが多い。例えば、吹雪が全ての到着を３０分ずつ遅らせるならば、過度の数の警告が登録されるかもしれない。システムは、ある時間間隔にわたって、移動平均と偏差を計算し、そして、現在の間隔(current  interval)をまたがるさらに広い間隔にわたって計算されたシグネチャ上の同一のものと比較することによりこの問題を解決する。
【００５２】
例えば、システムが３分毎にデータをサンプリングするならば、４時１５分には、それは過去の１０サンプル（３時４５分から４時１５分）の移動平均を計算することができ、そして、４時３０分に２０サンプル（３時３０分から４時３０まで計算されている）にわたって計算されたシグネチャ値と比較する。この方法では、存在し持続している不一致だけがフラグをたてるであろう。一方、その間隔内で時刻を前後にシフトさせることは誤った正数を与えない。２つの定数であるジッタースプレッド(jitter  spread)とジッターオフセット(jitter  offset)は、調整つまみ(control)として導入される。この場合、スプレッド(spread)は３０分であり、オフセットは１５分である。この場合の時間許容差(time tolerance)は、１時間（ジッタースプレッド＋オフセットの２倍）として選択できる。したがって、シグネチャによる予想よりも３０分早く又は遅く生じる大きなスパイク(spike)は、誤った正数異常(false  positive  abnormality)を引き起こさない。厳格に組織化されたビジネスにおいては、時間許容差に余裕がない。
【００５３】
図８は、本発明の実施形態に従って異常を検出する方法を示すフローチャートである。ステップＣ１０において、異常検出モジュール２６は、正常値の範囲を計算する。ステップＣ１２おいて、異常検出モジュール２６は、計算された範囲と移動平均とを比較する。ステップＣ１４において、異常検出モジュールは、移動平均が正常範囲外かどうかを判定する。ステップＣ１４において、平均が正常範囲外である場合は、異常検出モジュール２６は異常のフラグを立て、処理を繰り返す。ステップＣ１４において、平均が正常範囲外でない場合は、処理を繰り返す。
【００５４】
正常及び異常は主観的である。カスタマーは、カスタマーが処理できるレベルまで異常値をフラグで知らせる減衰制御(attenuation  control)を望む。前向きで学問的な監視が成功すると、カスタマーは、管理上のリソースを、存在する異常を訂正することからプロアクティブ監視に転用する。
【００５５】
本発明のシステム及び方法は、カスタマーに彼らが長期間欲する警報を統計的に約束する。例えば、１０００台のコンピュータ、１５分毎にサンプルされる１００台のカウンターを使ったインストールは、一日に、大体１０，０００，０００（一千万）の警報の機会を有する。もしカスタマーが、警報を１００回／１日に制限したいのであれば、カスタマーは、それに応じて許容差Ｆを設定する必要がある。
【００５６】
カスタマーの中には、例えば情報の、警告、クリティカル等の異なる包絡線に対するＦ１、Ｆ２、Ｆ３を用いた多重包絡線を好む者がいるかもしれない。その他の者の中には、異なるオーバーシュート(overshoot)とアンダーシュート(undershoot)の包絡線をもつことを選択するかもしれない。
【００５７】
たいていの機器類によりつくられる生の変数は、特異性(idiosyncrasy)をもつ。特異性は、以下の３つのカテゴリーで整列される。
（１）  ロールオーバー(rollover)を有する走行カウンター(running  counter)
（２）  爆発的(bursty)なサンプルデータ
（３）  単調に増減する絶対データ(absolute  data)
【００５８】
最初のケースであるロールオーバーをともなう走行カウンターにおいては、カウンターは、走行カウントを提供するだけであろう。データのコンシューマーは、長期間にわたり２つのスナップショット(snapshots)をとると予想され、差異とレートを計算する。カウンターが最大数からゼロにロールオーバーできるため、計算はビットコンプレックス(bit  complex)を得る。
【００５９】
２番目のケースである爆発的なサンプルデータにおいては、収集データは、極端にスパイキー(spiky)である。そのデータを用いる唯一の方法は、固定期間にカーブの下のエリアを計算することである。
【００６０】
単調に絶対データを増減させるケースにおいては、いくつかの変数は、絶え間なく増減する傾向にあり、そのため、ウィークリービジネスサイクルが意味を失う。このケースの場合、例えば暴走したプログラム(runaway  program)が、突然、ディスクスペースをぎっしり埋めているかどうかを検知するために、前処理は、長期間の変化率をリポートしなければならない。
【００６１】
前述の変数及び方法に基づいて、シグネチャは方程式（５）と（６）により記述される。
（５）    NewXS(t)  =  (L/1+L)*XS(t)  +  (1/1+L)*(XCmovingavg  (  t  ,  Time  Tolerance))  …  式５
（６）    (New  SigmaS(t))2  =  (L/1+L)*(SigmaS(t)2  +  XS(t)2)  +  (1/1+L)*((SigmaC(t,  Time  Tolerance))2  +  (XCmovingavg(t,  TimeTolerance))2)-NewXS(t)2  …  式６
【００６２】
上述のシグネチャにおいては、XC(t)は、時間的に変化する数値変数である。XS(t)とSigmaS(t)は、変数XC(t)の予測(precomputed)シグネチャの２つの構成要素である。XCmovingavg(t,  deltaT)は、t-deltaTとtの区間を占めるXC(t)の移動平均である。SigmaC(t,deltaT)は、t-deltaT  とt  の区間におけるXC(t)の標準偏差である。1/Lは、上述したように、学習反応性比率である。
【００６３】
異常は、シグネチャと関係する以下の式に基づいて計算される。以下の場合、XC(t)は異常である。
（７）  XCmovingavg(  t,  jitterspread)  <  (  XS(  t  +  jitteroffset)    F*SigmaS(  t  +  jitteroffset))  …  式７
または、
（８）XCmovingavg(  t,  jitterspread)  >  (XS(  t  +  jitteroffset)  +  F*SigmaS(  t  +  jitteroffset))  …  式８
【００６４】
式（７）により記述された第一のバイオレーション(violation)は、アンダーシュートと呼ばれ、式（８）により記述された第２のバイオレーションは、オーバーシュートと呼ばれる。jitterspreadとは、上述されたようにジッタのスプレッドであり、jitteroffsetとは、上述されたようにジッタのオフセットである。時間許容差は、(2*jitteroffset+jitterspread)と等しく、Fは、許容差である。
【００６５】
図９Ａは、シグネチャ更新プロセスの説明図である。図９Ａは、サンプル測定値(sample  readings)２を含む。サンプル測定値２は、サンプル値XC(t)を表すカーブ２０２を含む。図９Ａは、シグネチャ４を含む。中間のカーブ２０４はXS(t)、すなわち、平均シグネチャ値を表す。上位のカーブ２０６は、最高の正常値を表し、下位のカーブ２０８は、最低の正常値を表す。図９Ａは、更新シグネチャ６を含む。更新シグネチャ６は、サンプル値XS(t)と、カーブ２１２により表される上位の正常リミットと、カーブ２１４により表される下位の正常リミットとを考慮した後のXS(t)を表すカーブ２１０を含む。
【００６６】
図９Ｂは、サンプル信号２１８と比較される予め計算された信号２１６を示す。サンプル信号２１８は、２箇所で上位の正常リミット２２６を超え、１箇所で下位の正常リミット２２２を超える。比較は、オーバーシュートとアンダーシュートを識別するのに役立つ。
【００６７】
（異常の原因の判定）
上述したように、本発明の方法及びシステムの実施形態は、異常にそなえて、システムパラメータを監視する。本システム及び方法は、数値データストリームを、プロセスの正常動作又は異常動作のいずれかを表す状態に変換する。加えて、以下の表１に示すように、４つのサブステート(substates)が、追跡記録されるプロセス変数の種類に依存していることがわかる。
【００６８】
監視方法は、根本的原因の分析を容易にすることにより、異常が検出されたときに、異常が、根本的原因(root  cause)の割り出しと是正によって除去されるようにする。根本的原因の分析は  システム又はサブシステムから他のサブシステム及びシステムへのフォールト(fault)／アブノーマル(abnormal)モニターの連鎖を追跡調査することに依存する。根本的原因の分析は、次の種類のルールを有する。
（１）種類１のシステムでの種類Ｆ１の異常は、同じシステムの種類Ｆ２の異常によって引き起こされ得る。（２）種類１のシステムでの種類Ｆ１の異常は、システム１とシステム２が種類Ｒ１の関係を有する場合には、種類２のシステムで種類Ｆ２の異常によって引き起こされ得る。
【００６９】
根本的原因の分析は、どのシステムのどの態様が異常であるかを認識することに依存する。特に、システム内部では、異常を検知するシステムが、特定の状態での、使用法、稼動率、エラー、応答を含んだパラメータを検知した場合には、純粋な知識ルールが根本的原因を解明することができる。これらの純粋なルールを表１に示す。
【００７０】
【表１−１】
2004348740.tif 000003
【００７１】
【表１−２】
2004348740.tif 000004
【００７２】
本発明の格別の実施例はここに図解及び詳細に記述されているが、本発明の範囲及び意図するところから逸脱しない限り本発明に対して様々な変更及び変形をほどこしても構わないことが理解されるべきである。ここに記述された実施例は、あらゆる点で、制限的ではなく説明用として意図されている。代わりの実施例は、その範囲を逸脱することなく本発明が属する技術分野の当業者にとって明白になるであろう。
【００７３】
上述のことから、本システムと方法にとって明白かつ内在する他の利点と一緒になって、上記の予定された全ての目標、目的を達成するために採用されたものであることが理解されるであろう。ある特徴とサブコンビネーションは役に立ち、他の特徴やサブコンビネーションを参考にしないで用いることできることが理解されるであろう。これは、意図され、添付のクレームの範囲内である。
【図面の簡単な説明】
【００７４】
【図１】本発明を実施することができるコンピューティング環境の一例を示すブロック図である。
【図２】本発明の実施形態のシステムの構成要素を示すブロック図である。
【図３】本発明の実施形態による方法を示すフローチャートである。
【図４Ａ】本発明の実施形態によってシグネチャを生成する方法の一部を示すフローチャートである。
【図４Ｂ】本発明の実施形態によってシグネチャを生成する方法に含まれる更なる手続きを示すフローチャートである。
【図５】本発明の実施形態によってシグネチャを更新する方法を示すフローチャートである。
【図６】本発明の実施形態によってシグネチャ構成要素を取得する方法を示すフローチャートである。
【図７】本発明の実施形態によって別のシグネチャ構成要素を取得する方法を示すフローチャートである。
【図８】本発明の実施形態によって異常を検出する方法を示すフローチャートである。
【図９Ａ】シグネチャ更新プロセスを示す図である。
【図９Ｂ】サンプル信号と比較される予め計算されたシグネチャを示す図である。
【符号の説明】
【００７５】
１０  モニタリングシステム
１２  プロセッサ
１４  ネットワークインタフェース
１６  オペレータインタフェース
２０  メモリ
２２  シグネチャ生成モジュール
２４  シグネチャ更新モジュール
２６  異常検出モジュール
４０  モニターされるシステム
【図１】
2004348740.tif 000005
【図２】
2004348740.tif 000006
【図３】
2004348740.tif 000007
【図４Ａ】
2004348740.tif 000008
【図４Ｂ】
2004348740.tif 000009
【図５】
2004348740.tif 000010
【図６】
2004348740.tif 000011
【図７】
2004348740.tif 000012
【図８】
2004348740.tif 000013
【図９Ａ】
2004348740.tif 000014
【図９Ｂ】
2004348740.tif 000015