根本原因分析を実行する方法および装置
【課題】巨大且つ複雑なＩＴシステムにおける問題発生に対する根本原因分析を実行する方法を提供する。
【解決手段】根本原因分析エンジンが、イベントの持続期間およびイベントの段階的な削除を用いて分析精度を向上させると共に必要な計算回数を減らす。イベントの通知を受信する都度、関連するルールのマッチング率が再計算される。計算結果は分析エンジン内のルールメモリに保存される。各イベントは有効期間を有し、持続期間が満了した場合、当該イベントがルールメモリから削除される。ルールメモリに保存されたイベントは、ルールメモリに保存された他のイベントに影響を及ぼすことなく削除できる。分析エンジンは次いで、削除されたイベントに関係して影響を受けたルールに関してのみ再計算を実行することにより、各ルールのマッチング率を再計算することができる。
【解決手段】根本原因分析エンジンが、イベントの持続期間およびイベントの段階的な削除を用いて分析精度を向上させると共に必要な計算回数を減らす。イベントの通知を受信する都度、関連するルールのマッチング率が再計算される。計算結果は分析エンジン内のルールメモリに保存される。各イベントは有効期間を有し、持続期間が満了した場合、当該イベントがルールメモリから削除される。ルールメモリに保存されたイベントは、ルールメモリに保存された他のイベントに影響を及ぼすことなく削除できる。分析エンジンは次いで、削除されたイベントに関係して影響を受けたルールに関してのみ再計算を実行することにより、各ルールのマッチング率を再計算することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
最近の傾向として、企業の情報技術（ＩＴ）システムは益々巨大且つ複雑になっている。例えば、いくつかの企業において、ＩＴシステムはもはや単なる企業インフラではなく、当該企業と共同で企業の価値および競争力を高めるべく動作することが必要である。更に、ＩＴシステムの急激な成長は大企業に限らず、今や中規模の企業でも数百台のサーバを保有することができる。また、サーバの仮想化技術の急激な発展がこの傾向を加速させている。
【背景技術】
【０００２】
データセンタおよびその他のＩＴシステムの大規模な成長の最近の傾向にもかかわらず、ＩＴ組織の管理者は依然として、巨大且つ複雑なＩＴシステムを適切に動作させ続けるために、これらを効率的に管理することが求められている。問題が生じた場合、管理者は問題があると認識して、問題を分析し、次いで可能な限り早く問題を解決する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
通常、ＩＴシステムの健全性の監視、および発生し得る問題の分析は、何らかの形式の可用性および性能管理ソフトウェアを用いて実行される。このソフトウェアは通常、ＩＴシステム内の装置を発見し、それらの接続を識別して、時には問題が起きている場所を識別する能力も含んでいる。そのような管理ソフトウェアの使用を通じて、管理者は、以前は手動で実行しなければならなかった多くの退屈なオペレーション作業から解放される。しかし、上述のように、ＩＴシステム自体が急速に発展している一方で、ＩＴ予算は通常、より制約される傾向にある。この結果、各々の管理者がＩＴシステムの非常に大きな領域を管理する責任を負うことになり、これらのシステムの規模では、発生する恐れのある問題の実際の場所および「根本原因」の特定が困難になる場合がある。例えば、いくつかのベンダーが根本原因分析用の製品を提供しているが、これらの製品は、分析エンジンに入力すべきイベントの時間範囲を決定するための何らの機構も提供できていない。これは、計算コストが非効率である上に分析の精度が不十分であることを意味する。従って、ＩＴシステム環境における故障、欠陥その他の事象の根本原因を管理者が発見することを支援するソリューションに対するニーズが依然として存在する。
【０００４】
根本原因分析は、情報システム環境におけるエラーの根本原因である情報システムのノードの位置を特定する技術である。例えば、サーバ、スイッチ、ストレージ等、多くの異なるノードからなるトポロジを有する情報システムにおいて、それらのノードの１つがシステムにおける故障、エラーその他の事象を引き起こした場合、故障はシステムトポロジ内の当該ノードに接続している他のあらゆるノードに影響を及ぼし、ＩＴシステム内の異なる多くのノードからエラーイベントメッセージが管理者へ発行されることがある。従ってある場合には、システム内のどのノードがエラーの実際の根本原因であるかを管理者が判定することが極めて困難になり得る。
【０００５】
根本原因分析エンジンは、複数のエラーイベントメッセージおよびそれらの相互関係を分析し、次いで分析の結果として計算根本原因を出力する。現在、広範に用いられている２種類の公知の根本原因分析技術がある。一つはスマーツコードブック相関技術として知られており、もう一方はルール推論エンジンとも呼ばれるエキスパートシステムによる分析を利用する技術であって、例えばＲｅｔｅアルゴリズムおよび日立社のＥＳ／カーネルが含まれる。
【０００６】
スマーツコードブック相関技術（ＣＣＴ）
ＣＣＴは、行動モデルおよびトポロジに基づいて自動的にコードブックを生成する。一群のイベントを兆候としてコードブックに入力することにより問題を容易に出力できる。しかし、ＣＣＴは、コードブックに入力されるイベントの時間範囲を決定する何らの機構も提供できない。従って、生成されたイベントの時系列上の正しい位置を判定する手段が無い。イベントの入力範囲が不正確な場合、得られた結果もまた不正確であり得る。例えば、一日前にエラーが発生し、次いで今日別のエラーが発生したならば、２つのエラーは無関係であると結論付けることが現実的である場合が多い。しかし、ＣＣＴ分析は通常、イベントが発生する都度、先行イベントを含めて実行され、従って同一イベントを繰り返し処理する必要があるため、分析の精度に影響を及ぼすとともにイベントの根本原因を計算するコストが大幅に増大する。
【０００７】
従来のエキスパートシステム
「Ｒｅｔｅマッチングアルゴリズム」は、従来のエキスパートシステムの一例である。この種のエキスパートシステムは、ルールベースのマッチングアルゴリズムとして機能する。本明細書で以下に引用する「Ｒｅｔｅマッチングアルゴリズム」においてＢ．Ｓｃｈｎｅｉｅｒが議論するように、Ｒｅｔｅアルゴリズムはパターンマッチングにおける比較の速度を向上させるべく１９７０年代後半に開発された。Ｒｅｔｅアルゴリズム以前は、旧来システムではパターンマッチングの実行に自身の時間の９０％も費やしていたことが研究により示された。これらのシステムはパターンマッチング処理全体を反復し、各々のルールを順に採用して、データメモリを見渡して特定のルールの条件が満たされるか否かを判定してから次のルールへ進む。その後、効率を上げるべくデータ要素およびルール条件に索引付けを行なう方法が発見されていて、プログラムの実行速度を向上させるものの、依然として一連のルールおよびデータ要素全体に渡る反復を必要とする。Ｒｅｔｅアルゴリズムは、この反復ステップの大部分を除外するため、競合するアルゴリズムに比べて大幅に改良されている。
【０００８】
Ｒｅｔｅマッチングアルゴリズムは、競合集合の現在の内容をメモリに保存して、データ要素がメモリに追加および削除されたときのみ競合集合から項目を追加および削除することによりデータ要素全体にわたる反復を回避する。例えば、従来の反復的なパターンマッチングシステムにおいて、２つのほぼ同一のルールを追加する場合、各々のルールに対して反復処理全体が実行される。しかし、Ｒｅｔｅアルゴリズムでは、ほぼ同一のルールは、Ｒｅｔｅの木構造ソーティングネットワークによって冗長であると扱うことができる。Ｒｅｔｅパターンコンパイラは、個々の副条件のネットワークを構築する。これは最初に、プロダクションルールの各要素に個別に注目して、各属性を個別にテストするノードの連鎖を構築する。次いで、要素同士の比較に注目して、ノードの連鎖を新規ノードに接続する。最後に、ターミネータノードを追加して、プロダクションルールの全ての条件が満たされた旨の信号を送る。追加的なプロダクションルールは、同一ネットワークに接合される。それらに共通のテストが存在しない場合、相互に全く作用しない。
【０００９】
関連技術にはＭａｓｕｉ他による米国特許第４，７２７，４８７号明細書「Ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｍｅｔｈｏｄ ｉｎ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ」、Ｔａｎｏ他による米国特許第４，７６１，７４６号明細書「Ｄｙｎａｍｉｃ ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ ｍｅｔｈｏｄ ｆｏｒ ｄｉｓｃｒｉｍｉｎａｔｉｏｎ ｎｅｔｗｏｒｋ」、Ｍａｓｕｉ他による米国特許第４，８６８，７６３号明細書「Ｋｎｏｗｌｅｄｇｅ−ｂａｓｅｄ ｓｙｓｔｅｍ ｈａｖｉｎｇ ｐｌｕｒａｌ ｐｒｏｃｅｓｓｏｒｓ」、Ｔａｎｏ他による米国特許第５，１４６，５３７号明細書「Ｍｅｔｈｏｄ ｆｏｒ ｊｕｄｇｉｎｇ ｗｈｅｔｈｅｒ ｃｏｎｄｉｔｉｏｎｓ ａｒｅ ｓａｔｉｓｆｉｅｄ ｂｙ ｕｓｉｎｇ ａ ｎｅｔｗｏｒｋ ｈａｖｉｎｇ ａ ｐｌｕｒａｌｉｔｙ ｏｆ ｎｏｄｅｓ ｒｅｐｒｅｓｅｎｔｉｎｇ ｔｈｅ ｃｏｎｄｉｔｉｏｎｓ」、Ｔａｎｏ他による米国特許第５，３５３，３８５号明細書「Ｉｎｆｅｒｅｎｃｅ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｕｓｅ ｗｉｔｈ ｋｎｏｗｌｅｄｇｅ ｂａｓｅ ｓｙｓｔｅｍ ａｎｄ ｋｎｏｗｌｅｄｇｅ ｂａｓｅ ｓｙｓｔｅｍ ｓｕｐｐｏｒｔ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｕｓｉｎｇ ｔｈｅ ｉｎｆｅｒｅｎｃｅ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ」、Ｙｅｍｉｎｉ他による米国特許第７，１０７，１８５号明細書「Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｅｖｅｎｔ ｃｏｒｒｅｌａｔｉｏｎ ａｎｄ ｐｒｏｂｌｅｍ ｒｅｐｏｒｔｉｎｇ」、Ｏｈｓｉｅ他による米国特許第７，２５４，５１５号明細書「Ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｓｙｓｔｅｍ ｍａｎａｇｅｍｅｎｔ ｕｓｉｎｇ ｃｏｄｅｂｏｏｋ ｃｏｒｒｅｌａｔｉｏｎ ｗｉｔｈ ｓｙｍｐｔｏｍ ｅｘｃｌｕｓｉｏｎ」、Ｓｃｈｎｅｉｅｒ，Ｂ．による「Ｔｈｅ Ｒｅｔｅ Ｍａｔｃｈｉｎｇ Ａｌｇｏｒｉｔｈｍ」（Ｄｒ． Ｄｏｂｂ’ｓ Ｊｏｕｒｎａｌ，Ｄｅｃ．５，２００２）、および、Ｆｏｒｇｙ，Ｃ．Ｌ．による「Ｒｅｔｅ: Ａ ｆａｓｔ ａｌｇｏｒｉｔｈｍ ｆｏｒ ｔｈｅ ｍａｎｙ ｐａｔｔｅｒｎ／ｍａｎｙ ｏｂｊｅｃｔ ｐａｔｔｅｒｎ ｍａｔｃｈｉｎｇ ｐｒｏｂｌｅｍ」（ＡＲＴＩＦＩＣＩＡＬ ＩＮＴＥＬＬＩＧＥＮＣＥ， Ｖｏｌ．１９，ｎｏ．１，１９８２，ｐｐ．１７−３７）が含まれ、これらの開示内容を全て本明細書に引用している。
【課題を解決するための手段】
【００１０】
本発明の例示的な実施形態は、根本原因分析に伴う計算の精度を向上させコストを減らすソリューションを提供する。本発明の上記および他の特徴並びに効果は、以下の好適な実施形態の詳細な説明から当業者には明らかになろう。
【００１１】
添付の図面は、上述した一般的な説明および以下の好適な実施形態の詳細な説明と合わせて、現在考察されている本発明の最良の形態の好適な実施形態の原理の例示および説明に有用である。
【図面の簡単な説明】
【００１２】
【図１】本発明の方法および装置が適用できるハードウェアおよび論理構成の一例を示す。
【図２】情報システムにおける機能関係の一例を示す。
【図３】ルールリポジトリの一例を示す。
【図４】ルールメモリ関連付けの一例を示す。
【図５】イベントメッセージの例示的なデータ構造を示す。
【図６】イベントキューテーブルの例示的なデータ構造を示す。
【図７】イベント消去設定テーブルの例示的なデータ構造を示す。
【図８】イベント消去タスクテーブルの例示的なデータ構造を示す。
【図９】マッチング率監視設定テーブルの例示的なデータ構造を示す。
【図１０】イベント消去に続く減衰の例のグラフ表現を示す。
【図１１】ルール決定の例の概念図を示す。
【図１２】ルールローダープログラムの処理例を示す。
【図１３】イベント受信プログラムおよびイベント書込プログラムの処理例を示す。
【図１４】マッチング率評価プログラムの処理例を示す。
【図１５】マッチング率監視プログラムの処理例を示す。
【図１６】イベント消去プログラムの処理例を示す。
【発明を実施するための形態】
【００１３】
本発明の以下の詳細な説明において、開示の一部をなす添付図面を参照するが、これらは本発明を実施できる例示的な実施形態を示すものであって本発明を限定するものではない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。更に、詳細な説明は各種の例示的な実施形態を提供するが、以下に記述および図示するように、本発明は本明細書に記述および図示する実施形態に限定されるものではなく、当業者には公知または将来公知となる他の実施形態に拡張できる点に注意されたい。本明細書において「一実施形態」または「本実施形態」に言及する場合、当該実施形態との関連で記述されている特定の特徴、構造または特性は、本発明の少なくとも１つの実施形態に含まれることを意味しており、本明細書の各所でこれらの語句が出現しても必ずしも全て同一の実施形態を指している訳ではない。また、以下の詳細な説明において、本発明を完全に理解されるよう多くの具体的な詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するためにこれらの具体的な詳細事項の全てが必要な訳ではない。他の状況において、本発明を無用に分かり難くしないよう、公知の構造、材料、回路、処理およびインタフェースについては詳細に記述せず、および／またはブロック図の形式で示す場合がある。
【００１４】
更に、以下の詳細な説明のある部分は、コンピュータ内部の動作のアルゴリズムおよび記号的表現として示す。これらのアルゴリズム的記述および記号表現は、データ処理技術に精通した当業者が自身の発明の本質を他の当業者に最も効果的に伝達すべく用いる手段である。アルゴリズムとは、所望の最終状態または結果に達する一連の定義されたステップである。本発明において、実行されるステップは、有形の結果を実現するための有形の量を物理的に操作することを要求する。通常、但し必須ではないが、これらの量は、保存、転送、結合、比較、および他の操作が可能な電気または磁気信号の形式をなす。原理的に共通に利用できるとの理由で、これらの信号をビット、値、要素、記号、文字、項目、数、命令等と称することが往々にして便利であることがわかっている。しかし、これらの全ておよび同様の項目は、適切な物理量に関連付けられるべきものであり、これら物理量に付けられた便宜的なラベルに過ぎないことに留意すべきである。特に別途明言しない限り、以下の記述から明らかなように、本明細書の記述を通じて、「処理する」、「計算する」、「算出する」、「判定する」、「表示する」等の用語を用いた説明は、コンピュータシステムまたは当該コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表現されたデータを操作して、当該コンピュータシステムのメモリまたはレジスタまたは他の情報記憶、伝送または表示装置内の物理量として同様に表現された他のデータに変換する他の情報処理装置の動作および処理を含んでいてよい。
【００１５】
本発明はまた、本明細書における動作を実行する装置に関する。この装置は、必要な目的のために特別に構築されていても、または、１つ以上のコンピュータプログラムにより選択的に起動または再設定される１つ以上の汎用コンピュータを含んでいてもよい。そのようなコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出し専用メモリ、ランダムアクセスメモリ、固体装置およびドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。本明細書に示すアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたは他の装置にも本質的には関係していない。各種の汎用システムを、本明細書の教示によるプログラムおよびモジュールと共に用いてもよいが、所望の方法ステップを実行するためのより特化した装置を構築した方が便利なことが分かる場合がある。これら各種のシステムの構造は以下に開示する説明で明らかになる。本発明はまた、いかなる特定のプログラミング言語も前提としては記述していない。以下に記述するように、本発明の教示を実行するために各種のプログラミング言語を用いてもよいことが理解されよう。プログラム言語の命令は、１つ以上の処理装置、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラにより実行できる。
【００１６】
以下でより詳しく述べるように、本発明の例示的な実施形態は、より高い精度およびより高い計算費用対効果を有する、根本原因分析を実行する装置、方法、およびコンピュータプログラムを提供する。例示的な実施形態によれば、分析エンジンは各々のイベントを受け取った各時点でのルールのマッチング率を計算し、計算の結果が分析エンジンのルールメモリに保存される。マッチング率は、特定の根本原因分析の結果を判定するために、どのルールの結論が根本理由を正確に識別する可能性が最も高いかを判定するために用いる確率または計算された比率（すなわち、確度）である。これらの実施形態でルールメモリに保存される各イベントは、ルールメモリに保存される他のイベントに影響を及ぼすことなくルールメモリから削除することが可能である。更に、各イベントには当該イベントの生存時間である有効期間が与えられており、有効期間が満了すると、分析エンジンはルールメモリから当該イベントを削除する。従って、本発明の例示的な実施形態において、分析エンジンは、イベントが削除された際に影響を受けるルールのマッチング率を再計算するだけでマッチング率を再計算することが可能である。従って、本発明の例示的な実施形態において、分析エンジンが必要に応じて増加分または減少分のイベントを処理するため、根本原因分析を実行するための計算コストが減少する。更に、古いイベントを削除して根本原因分析計算に対するそれらの影響を排除できるため、精度を向上させながら同時に全体的な計算要件を減らすことができる。
【実施例】
【００１７】
ハードウェアおよび論理構成
図１に、本発明の実施形態を実装可能な情報システムの例示的なハードウェアアーキテクチャおよび論理構成を示す。図１のシステムは、監視コンピュータ１０１、１つ以上のサーバまたは他のコンピュータ１０２、１つ以上のネットワークスイッチまたは他のネットワーク装置１０３、およびＬＡＮ（ローカルエリアネットワーク）１０５等のネットワークを介して通信すべく接続する１つ以上のストレージ１０４を含む。
【００１８】
監視コンピュータ１０１は、ＣＰＵ１１１、メモリ１１２、ハードディスクドライブ（ＨＤＤ）１１３等の記憶媒体、ビデオインターフェース１１４、およびシステムバス１１６を介して接続するネットワークインターフェース１１５（Ｉ／Ｆ）を含む汎用コンピュータであってよい。監視コンピュータ１０１の論理モジュールおよびデータ構造は、ルールメモリ１２１、ルールローダープログラム１２２、イベント受信プログラム１２３、イベント書込プログラム１２４、マッチング率評価プログラム１２５、マッチング率監視プログラム１２６、イベント消去プログラム１２７、外部モジュール１２８、ルールリポジトリ１３１、イベントキューテーブル１３２、イベント消去設定テーブル１３３、イベント消去タスクテーブル１３４、およびマッチング率監視設定テーブル１３５を含む。ルールメモリ１２１は、イベントの状態および根本原因分析の結果として導かれたルールを表すオブジェクトモデルを保存する。ルールローダープログラム１２２、イベント受信プログラム１２３、イベント書込プログラム１２４、マッチング率評価プログラム１２５、マッチング率監視プログラム１２６、イベント消去プログラム１２７、および外部モジュール１２８は、メモリ１１２または他の計算機可読媒体に保存され、ＣＰＵ１１１により実行される。以下に記述するルールリポジトリ１３１、イベントキューテーブル１３２、イベント消去設定テーブル１３３、イベント消去タスクテーブル１３４、マッチング率監視設定テーブルのデータ構造は、ディスク１１３または他の適当な計算機可読媒体に保存されていてよい。
【００１９】
監視コンピュータ１０１は、ＬＡＮ１０５と通信すべく接続されて、サーバ１０２、ネットワークスイッチ１０３、およびストレージ１０４等、監視対象である動作ノードからイベントメッセージを受信するために用いるネットワークインターフェース１１５を有する。ディスプレイ１１７はビデオインターフェース１１４に接続されていて、外部モジュール１２８からの根本原因分析の結果および他の情報を管理者に提示するために用いられる。
【００２０】
各サーバ１０２は、当技術分野で公知のようにアプリケーション等を実行させている監視対象ノードであってよい。サーバ１０２は、ＣＰＵ１４６、メモリ／ストレージ１４７、およびネットワークインターフェース１４２を含む汎用コンピュータであってよい。各サーバ１０２は、特定の状態変化が検出された場合にＬＡＮ１０５を介して監視コンピュータ１０１にイベントメッセージを送る監視エージェント１４１を含んでいてよい。例示する実施形態において、各サーバ１０２はまた、本発明の行動を説明する一例としてｉＳＣＳＩ（インターネット小型計算機システムインターフェース）イニシエータ１４３を有する。例えば、サーバ１０２はｉＳＣＳＩディスク１５１を仮想的にローカルＨＤＤのように利用できるが、これはｉＳＣＳＩイニシエータ１４３およびストレージ１０４の記憶容量により実現される。更に、代替的な実施形態において、ｉＳＣＳＩの代わりにまたはこれに加えて、他の通信および記憶プロトコルを用いてもよい。
【００２１】
各ストレージ１０４は、同様に当該技術分野で公知であるように、サーバ１０２上で動作するアプリケーション用の記憶容量を提供するための、または他の目的のための監視対象ノードであってよい。ストレージ１０４はストレージコントローラ１６１、ネットワークインターフェース１６３、および記憶媒体１６２を含み、記憶媒体１６２は本実施形態ではＨＤＤであってよいが、固体記憶媒体、光記憶媒体等、他の種類の記憶媒体であってよい。これらの実施形態において、ストレージ１０４は、サーバ１０４に対しｉＳＣＳＩ論理ボリュームを記憶容量として提供すべく構成される。従って、例示する実施形態において、３台のサーバ１０２ａ〜ｃがネットワークスイッチ１０３を介してストレージ１０４に接続されていて、ストレージ１０４が各サーバ１０２ａ〜ｃに対してｉＳＣＳＩボリュームを提供する。また、ストレージ１０４は、ストレージ１０４の状態を監視して監視コンピュータ１０１にイベントを報告できる監視エージェント１６６を含んでいてよい。あるいは、サーバ１０２の１台上の監視エージェント１４１が、ストレージ１０４およびネットワークスイッチ１０３の状態を監視することができる。更に、ある場合には、ネットワークスイッチ１０３は自身の監視エージェントを有していてよい。
【００２２】
機能関係ブロック図
図２に、例示的な実施形態による情報システム内における例示的な機能関係を表すブロック図を示す。図２において、監視コンピュータ１０１のモジュールおよびデータ構造を含む監視システム２０１は、サーバ１０２、ネットワークスイッチ１０３、およびストレージ１０４等の複数の監視対象ノード２０２を監視すべく構成される。監視システム２０１において、ルールローダープログラム１２２は、ルールリポジトリ１３１からのルールを読み、それらをルールメモリ１２１にロードする。イベント受信プログラム１２３は、監視対象ノード２０２を含む情報システムの監視対象部分からイベントメッセージを受信して、これらのイベントメッセージをイベントキューテーブル１３２に保存すべく構成される。例えば、サーバ１０２、スイッチ１０３、およびストレージ１０４上の監視エージェントは、イベントが生起するとイベントメッセージをイベント受信プログラム１２３に送ることができる。イベント書込プログラム１２４は、イベントキューテーブル１３２からイベントメッセージを取得して、取得したイベントメッセージをルールメモリ１２１に書き込む。イベント書込プログラム１２４はまた、イベント消去設定テーブル１３３の設定に従い、イベント消去タスクテーブル１３４内にイベント消去タスクを生成する。イベント書込プログラム１２４は、自身のプロセス終了時にマッチング率評価プログラム１２５を起動する。マッチング率の値は新規イベントにより変化する可能性があるため、マッチング率評価プログラム１２５はイベントの入力に関連する各ルールについてのマッチング率を評価する。マッチング率評価プログラム１２５は、自身のプロセス終了時にマッチング率監視プログラム１２６を起動する。マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５の条件に従いマッチング率の値を調べる。マッチング率が条件を満たす場合、マッチング率監視プログラム１２６は１つ以上の外部モジュール１２８を起動する。外部モジュール１２８の一例として、システム管理者に根本原因に関する通知を送るモジュールがある。イベント消去プログラム１２７はタイマーにより起動されて、イベント消去タスクテーブル１３４に基づいて周期的にタスクを実行する。イベント消去プログラム１２７は、以前に生起したイベントを当該イベントから経過した時間数に基づいて消去する。
【００２３】
ルールリポジトリおよびルール
一般ルールは、システムトポロジから独立した形式で記述される条件およびアクションの組である。拡張ルールは、一般ルールおよび特定のトポロジから伝播されて生成されるルールである。各々の顧客に応じて監視対象環境が情報システム毎に大幅に変化し得るため、システムトポロジに基づいて一般ルールを拡張ルールに拡張する処理が最初に必要となる。
【００２４】
図３に、ルールリポジトリ１３１に常駐し、図１に示す情報システムのために伝播される拡張ルールであるルール３０１〜３０５の例を示す。一般に、ルールは２つの部分、すなわち「ＩＦ」部３１１と呼ばれる第１の部分３１１および「ＴＨＥＮ」部３１２と呼ばれる第２の部分３１２に分けることができる。ＩＦ部３１１は、１つ以上の条件要素を含んでいてよい。例えば、ルール３０１は、ＩＦ部３１１に４つの条件、すなわち「＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＡのｉＳＣＳＩ通信エラー）＞」、「＜ＳｅｒｖｅｒＢ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＢのｉＳＣＳＩ通信エラー）＞」、「＜ＳｅｒｖｅｒＣ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＣのｉＳＣＳＩ通信エラー）＞」、および「＜Ｓｔｏｒａｇｅ１ Ｃｏｎｔｒｏｌｌｅｒ＿Ｅｒｒ（ストレージ１のコントローラエラー）＞」を有する。従って、「ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ」のようなエラーイベントが「サーバＡ」から受信された場合に、条件「＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞」は真になる。ＩＦ部３１１の全ての条件が真ならば、特定のルールに従いＴＨＥＮ部３１２の結論要素は真であると推定される。例えば、ルール３１１は結論要素「＜Ｓｔｏｒａｇｅ１ Ｃｏｎｔｒｏｌｌｅｒ＿Ｅｒｒ＞」を有する。従って、ルール３０１によれば、サーバＡ、サーバＢ、およびサーバＣは通信エラーを報告し、ストレージ１はコントローラエラーを報告し、ルール３０１は根本原因がストレージ１におけるコントローラエラーであることを示す。また、ルールが複数の結論を有する（すなわち、ＴＨＥＮ部が複数のノードにおける事象を指摘する等）ケースが起こり得る。例えば、各々のＩＦ部に同じ条件を有するが各々のＴＨＥＮ部には異なる結論を有する複数のルールを定義することが好ましい場合にルールのＴＨＥＮ部が複数の結論を有していてよい。例えば、「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｘ（Ａ Ｂ ＣならばＸ）」および「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｙ（Ａ Ｂ ＣならばＹ）」のような２つのルールがある場合、これらのルールを結合して１つのルール「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｘ Ｙ（Ａ Ｂ ＣならばＸおよびＹ）」として定義できる。
【００２５】
ルールメモリ
図４に、ルールメモリ１２１に保存されたオブジェクトモデルのルールメモリ関連付けの例示的な構成図を示す。図４において、３種類のオブジェクト、すなわち、条件オブジェクト４０１、演算子オブジェクト４０２および結論オブジェクト４０３）がある。これらのオブジェクトおよびその接続は、ルールローダープログラム１２２により生成される。条件オブジェクト４０１は、４種の属性、すなわちノードの名前である「ノード名」、イベントの種別である「イベント種別」、イベントが受信された日時である「受信日時」、および条件に割り当てられた重み値である「重み」を含む。演算子オブジェクト４０２は「Ｎｏｔ」属性を有し、真または偽の値をとり得る。例えば、ルールに書かれた条件要素が「＜ＮＯＴ Ｓｔｏｒａｇｅ１ Ｖｏｌｕｍｅ＿Ｅｒｒ（ストレージ１のボリュームエラーではない）＞」等の指定された「ＮＯＴ」単項演算子である場合、この属性の値は「真」に設定され、さもなければ値は「偽」に設定される。結論オブジェクト４０３は４種の属性、すなわち特定のルールの識別子を指定する「ルール名」、ルールが適用されるノードを指定する「ノード名」、エラーの原因を識別する「原因」、および正確さの確率を示す「マッチング率」（ＭＲ）を有し、換言すれば、ＭＲ値はこの結論がイベントの根本原因である確度を示す。このオブジェクトモデルは条件要素の重複なしに形成される。ルールローダープログラム１２２は、ルールに規定された条件要素に従い条件オブジェクト４０１を生成する際に重複を除外する。これにより、イベント書込プログラム１２４は、受信した１つのイベントに対してイベントを何回も書く必要が無い。ルールは、結論オブジェクト４０３と演算子オブジェクト４０２を接続することにより表される。例えば、結論オブジェクト４０３ａは、演算子オブジェクト４０２ａ、４０２ｂ、４０２ｃ、４０２ｄとの４つの接続を有する。各演算子オブジェクト４０２は、ちょうど１つの条件オブジェクト４０１に接続している。従って、「ルール１」のＩＦ部は４つの条件からなる。結論オブジェクト４０３ｂもまた、演算子オブジェクト４０２ａ、４０２ｂ、４０２ｃ、４０２ｄとの４つの接続を有する。演算子オブジェクト４０２ａは、結論オブジェクト４０３ａ、４０３ｂ、４０３ｃにより共有される。
【００２６】
本発明の例示的な実施形態における「マッチング率」は、ルールの条件要素の総数を構成する要素のうちどの要素が真になるかに従う率で計算される確度である。マッチング率を計算する公式は以下のように表すことができる。
ＭＲ＝真の条件要素数／条件要素の総数
【００２７】
図４において、条件要素４０１ａ〜４０１ｄは真であり、ルール１の条件要素の総数は４である。従って、分析エンジンは４つ中の４つ（４／４）＝１．０という率を計算する。ルール２に関して、条件要素の総数は４であり、真の条件要素の数は３つしかないため、ルール２のオブジェクト結論４０３ｂのマッチング率について結果的に得られる率は３／４＝０．７５である。従って、マッチング率を設定することにより、分析エンジンは、ノードのうちの１つに関するイベントメッセージが分析エンジンに送られない場合に生じ得るように、たとえ１つの条件要素が真で無い場合でも、最も確率が高い結論を決定できる。これは例えば、ノードが監視システム２０１にエラーイベントメッセージを送信せずに故障した状況で生じる場合がある。
【００２８】
イベントメッセージ
図５に、イベント受信プログラム１２３が監視対象ノードの１つにある監視エージェント等から受信したイベントメッセージ５０５の例示的なデータ構造を示す。イベントメッセージ５０５は３種の情報、すなわち、「ノード種別」５０１、「ノード名」５０２、および「イベント種別」５０３を含む。ノード種別５０１は、サーバ、ネットワークスイッチまたはストレージ等、イベントメッセージが関係するノードの種別である。ノード名５０２は、情報システム環境において特定のＩＴノードを識別できる一意な名前である。イベント種別５０３は生起したイベントの種別を示す。
【００２９】
イベントキューテーブル
図６に、監視コンピュータ１０１に常駐するイベントキューテーブル１３２の例示的なデータ構造を示す。イベント受信プログラム１２３は、監視対象ノード２０２からイベントメッセージ５０５を受信したならば、イベント情報をこのテーブルに入れる。イベントキューテーブル１３２は、報告されたイベントのキューのリストを生成するため、イベントの入力−出力順序は先入れ先出し（ＦＩＦＯ）原則に従う。イベントキューテーブル１３２は、４つのカラム、すなわち、イベントを生成したノードの種別のリストを生成するノード種別６０１、対応するノードの内部名を示すノード名６０２、生起したイベントを示すイベント種別６０３、およびイベントメッセージが受信された日時を示す受信日時６０４を含む。ノード種別６０１、ノード名６０２、およびイベント種別６０３は、受信されたイベントメッセージ５０５から取得される。受信日時６０４は、イベント受信プログラム１２３がイベントメッセージを受信した日時である。イベントキューテーブル１３２は、イベント書込プログラム１２４のバッファとして機能する。イベント書込プログラム１２４は、イベントキューテーブル１３２からイベント情報を取得し、当該イベント情報をルールメモリ１２１に書き込む。
【００３０】
イベント消去設定テーブル
図７に、監視コンピュータ１０１に常駐するイベント消去設定テーブル１３３の例示的なデータ構造を示す。イベント消去設定テーブル１３３は、有効期間（生存時間）および各種のイベントの減衰率を指定するイベント消去プログラム１２７の設定情報を含む。イベント消去設定テーブル１３３は、受信されたイベントの各々に対して指定する有効期間および減衰率を決定すべくイベント書込プログラム１２４により使用される。イベント消去設定テーブル１３３において、ノード種別７０１は、イベントメッセージが生成されたノードの種別、イベント種別７０２はイベントの種別、有効期間７０３はイベントが考慮対象であり続ける時間（すなわちイベントの有効期間）、および減衰率７０４はイベントの重要性が時間の経過につれて減少する量である。有効期間７０３および減衰率７０４は、ノードの種別とイベント種別の組合せの各々に対して定義される。有効期間７０３は、イベントメッセージを受信した時点から、ルールメモリ１２１からのイベントの減衰が始まる時点までの期間である。減衰率７０４は、条件オブジェクト４０１の重み値（重み値）が減少する１分当たりの率である。例えば、有効期間が１０分で減衰率が毎分０．２ポイントである場合、イベントが受信された１０分後に、対応する条件オブジェクト４０１内の重み値が減少し始める。例えば、減衰率が毎分０．２であるため、１１分経過した時点で重み値は０．８になり、１２分経過した時点で重み値は０．６になって、重みが０．０または負値になるまで重み値は毎分減少し続ける。
【００３１】
イベント消去タスクテーブル
図８に、監視コンピュータ１０１に常駐するイベント消去タスクテーブル１３４の例示的なデータ構造を示す。イベント消去タスクテーブル１３４を用いて、各々の受信されたイベントの有効期間を管理する。イベント消去タスクテーブル１３４は、イベントが受信されるとイベント書込プログラム１２４により書き込まれて、イベントの消去を開始する時点を決定すべくイベント消去プログラム１２７により使用されるものであり、開始時刻８０１、ノード名８０２、イベント種別８０３、および減衰率８０４を含む。開始時刻８０１はイベント消去タスクを開始すべき日時である。開始時刻８０１は、公式「受信日時６０４＋有効期間７０３」により計算される。ノード名８０２は内部ノード名、イベント種別８０３はイベントメッセージを生起させたイベントの種別である。イベント消去プログラム１２７は、これら２つの値（ノード名８０２およびイベント種別８０３）により対象とする条件オブジェクト４０１を識別する。従って、ノード名８０２およびイベント種別８０３はイベントキューテーブル１３２内のノード名６０２およびイベント種別６０３から転記される。減衰率８０４はイベント消去設定テーブル１３３から転記される。
【００３２】
マッチング率監視設定テーブル
図９に、監視コンピュータ１０１に常駐するマッチング率監視設定テーブル１３５を示す。マッチング率監視設定テーブル１３５は、条件９０１およびアクション９０２を含む。条件９０１は、マッチング率監視プログラム１２６が調べる条件である。アクション９０２は、対応する条件が満たされた場合に外部モジュール１２８が実行すべきアクションである。例えば、エントリ９１１において条件ＭＲが０．８未満である場合、管理者に電子メールを送る必要がある。
【００３３】
重み値の減衰
図１０に、イベント書込からイベント消去までの条件オブジェクト４０１の重みの変化を説明するため、イベント消去の時刻に達した後の減衰の例を表すグラフを示す。条件オブジェクト４０１の最大重み値は１．０である。図１０に示すように、時刻１００１において、イベント書込プログラム１２４は新規イベント情報をルールメモリ１２１に書き込む際に、対応する条件オブジェクト４０１の重みが１．０に設定される。開始時刻１００１から第１の満了時刻１００２までの有効期間中、特定の条件オブジェクトの重み値は１．０に保たれる。次いで、１００３に示すように、有効期間が第１の満了時刻１００２に達すると、最終満了時刻１００４に至るまで当該条件オブジェクトに割り当てられた減衰率７０４に従いイベント消去プログラム１２７により重み値が１．０から０に減らされる。
【００３４】
結論オブジェクトのマッチング率値変動
図１１に、イベント書込からイベント削除に至る結論オブジェクト４０３のマッチング率（ＭＲ）値の変動を説明するグラフを示す。図１１において、ルール１（１１０１）、ルール２（１１０２）、およびルール３（１１０３）を説明用のルールの例として示す。更に、太い矢印１１２１はイベントの初期書込のタイミングを示し、細い矢印１１２３はイベント消去（減衰）が開始されるタイミングを示し、各々の対応する太い矢印１１２１と細い矢印１１２３の間で伸びているリボン１１２２は、対応するイベントの有効期間を示す。
【００３５】
イベント書込プログラム１２４が新規または更新されたイベント情報をルールメモリ１２１に書込んだ場合、各々のルールについてマッチング率（ＭＲ）値が再計算される。例えば、イベントＡ〜Ｇが追加または削除されるにつれて、破線１１１１は時間経過に伴うルール１（１１０１）のＭＲ値の変化を示し、実線１１１２は時間経過に伴うルール２のＭＲ値の変化を示し、点線１１１３は時間経過に伴うルール３のＭＲ値の変化を示す。例えば、イベント書込プログラム１２４が１１３０のタイミングでイベントＡを書込んだ場合、ルール１およびルール２の両方が自身のＩＦ部３１１にイベントＡを有するため、ＭＲ値はルール１に対して０．２５（１／４）およびルール２に対して０．３３（１／３）として計算される。
【００３６】
次に、イベント書込プログラム１２４が１１３１のタイミングでイベントＢを書込んだ場合、ルール１について４つのＩＦ条件のうち２つが満たされるため、ルール１に対してＭＲ値は０．５（２／４）として再計算される。ルール２およびルール３は共に自身のＩＦ部にイベントＢを有していないため、ルール２およびルール３のＭＲ値は変化しない。同様に、タイミング１１３２でイベントＣが追加された場合、ルール１のＭＲ値は０．７５（３／４）まで上がり、ルール２のＭＲ値は０．６６の（２／３）まで上がる。タイミング１１３３でイベントＤが生起した場合、ＩＦ部内の全ての条件が満たされるためルール１のＭＲ値は１（４／４）まで上がる。更に、Ｄがルール３のＩＦ部の条件の１つであるためルール３のＭＲ値は０．５（１／２）まで上がる。ルール２はイベントＤの影響を受けない。
【００３７】
イベントＡの生存期間が１１４１のタイミングで終了した場合、ＭＲ値はルール１について０．７５（３／４）、ルール２について０．３３（２／３）として再計算される。従って、情報システムの管理者は、図１１に示す例のような一連のＭＲ値計算を通じて、たとえルールのＭＲ値が１．０に等しい場合でも、イベントの最も可能性の高い根本原因を特定できる。
【００３８】
ルールローディングの処理
図１２に、監視コンピュータ１０１内でルールローダープログラム１２２により実行されるルールローディングの処理例のフローチャートを示す。ルールローダープログラム１２２は、監視コンピュータが起動されるとこの処理を開始すべく構成されていてよい。
【００３９】
ステップ１２００において、ルールローダープログラム１２２は、情報システムのシステムトポロジに基づいて一般ルールから拡張ルールを生成し、上述のように拡張ルールをルールリポジトリ１３１に保存する。
【００４０】
ステップ１２０１において、ルールローダープログラム１２２は、ルールリポジトリ１３１からルールを取得し、取得したルールを構文解析する。
【００４１】
ステップ１２０２において、ルールローダープログラム１２２は、ステップ１２０１で取得したルールのＩＦ部３１１から条件要素を取得する。
【００４２】
ステップ１２０３において、ルールローダープログラム１２２は、特定の条件要素に対応する条件オブジェクト４０１がルールメモリ１２１内に存在するか否かを調べる。
【００４３】
ステップ１２０４において、ルールローダープログラム１２２が対応する条件オブジェクト４０１を見つけられなかった場合、処理はステップ１２０５へ進む。一方、条件オブジェクト４０１が見つかった場合、処理はステップ１２０６へ進む。
【００４４】
条件オブジェクトが見つからなかった場合、ステップ１２０５において、ルールローダープログラム１２２は特定の条件要素のための条件オブジェクト４０１および演算子オブジェクト４０２をルールメモリ１２１内に生成し、次いで新たに生成された条件オブジェクト４０１と演算子オブジェクト４０２を互いに接続する。
【００４５】
ステップ１２０６において、ルールローダープログラム１２２は、ＩＦ部３１１内の全ての条件要素が処理されたか否かを調べる。全て処理済みならば、処理はステップ１２０７へ進み、さもなければ処理はステップ１２０２に戻る。
【００４６】
ステップ１２０７において、ルールローダープログラム１２２は、ステップ１２０１で選択されたルールのＴＨＥＮ部３１２から結論要素を取得する。
【００４７】
ステップ１２０８において、ルールローダープログラム１２２は、ルールメモリ１２１内に結論オブジェクト４０３を生成し、次いで生成された結論オブジェクト４０３と全ての関連する演算子オブジェクト４０２を接続する。
【００４８】
更に、２つ以上の結論要素をステップ１２０７で取得した（すなわち、特定のルールが上述のように２つ以上の結論を有する）場合、ルールローダープログラム１２２は対応する結論オブジェクト４０３をルールメモリ１２１内に生成し、次いで各々の生成された結論オブジェクト４０３と全ての関連する演算子オブジェクト４０２をステップ１２０８で接続する。
【００４９】
例えば、図４に示すように、ルール１の条件オブジェクト４０１は、４０１ａ、４０１ｂ、４０１ｃ、および４０１ｄである。これらの条件オブジェクト４０１ａ〜ｄは各々演算子オブジェクト４０２ａ〜４０２ｄに接続している。ルール１の結論オブジェクト４０３は４０３ａである。従って、接続４０３ａ〜４０２ａ〜４０１ａ、４０３ａ〜４０２ｂ〜４０１ｂ、４０３ａ〜４０２ｃ〜４０１ｃ、および４０３ａ〜４０２ｄ〜４０１ｄが、ルール１のために生成されなければならない。同様に、ルール２の条件オブジェクト４０１は、４０１ａ、４０１ｂ、４０１ｃ、および４０１ｅである。従って、条件オブジェクト４０１ａ、４０１ｂ、および４０１ｃは、ルール１のものと重なっている。この場合、結論オブジェクト４０３ａと結論オブジェクト４０３ｂは、対応する演算子オブジェクト４０２ａ〜ｃおよび条件オブジェクト４０１ａ〜ｃを共有する。
【００５０】
ステップ１２０９において、ルールローダープログラム１２２は、ルールリポジトリ１３１内の全てのルールファイルが処理されたか否かを調べる。全て処理済みならば処理を終了し、さもなければ処理はステップ１２０１に戻ってルールリポジトリ１３１内の次のルールを処理する。
【００５１】
イベント受信およびイベント書込の処理
図１３に、監視コンピュータ１０１内でイベント受信プログラム１２３およびイベント書込プログラム１２４により実行されるイベント受信およびイベント書込の処理例のフローチャートを示す。イベント受信プログラム１２３は、監視対象ノード２０２の１つからイベントメッセージを受信することにより処理を開始する。
【００５２】
ステップ１３０１において、イベント受信プログラム１２３は、監視対象ノード２０２からイベントメッセージ５０５を受信する。
【００５３】
ステップ１３０２において、イベント受信プログラム１２３は、このイベントメッセージ５０１を、ノード種別６０１、ノード名６０２、イベント種別６０３、および受信日時６０４を含む図６に示す情報と共にイベントキューテーブル１３２内の新規レコードに入れて、処理を終了する。
【００５４】
ステップ１３１１において、イベント書込プログラム１２４は、処理のためイベントキューテーブル１３２から１つのエントリを取得する。
【００５５】
ステップ１３１２において、イベント書込プログラム１２４は、ステップ１３１１で取得したエントリのノード種別６０１、ノード名６０２、およびイベント種別６０３を取得する。
【００５６】
ステップ１３１３において、イベント書込プログラム１２４は、ルールメモリ１２１内に同一ノード名およびイベント種別を有する条件オブジェクト４０１を決定する。
【００５７】
ステップ１３１４において、イベント書込プログラム１２４は、現在の日時をステップ１３１３で決定された条件オブジェクト４０１の「受信日時」属性に設定する。
【００５８】
ステップ１３１５において、イベント書込プログラム１２４は、ステップ１３１３で取得した条件オブジェクト４０１の「重み」属性に「１．０」を設定する。
【００５９】
ステップ１３１６において、イベント書込プログラム１２４は、ステップ１３１１でイベントキューテーブル１３２から取得したエントリのノード種別およびイベント種別を設定して、対応する有効期間７０３および減衰率７０４を決定することによりイベント消去設定テーブル１３３から対応するイベント消去設定を取得する。
【００６０】
ステップ１３１７において、イベント書込プログラム１２４は、イベント消去タスクテーブル１３４にタスクエントリを生成することにより、イベント消去設定テーブル１３３に指定された時刻にイベント消去プログラムがイベント消去タスクを実行できる。例えば、イベントキューテーブル１３２内の処理されるエントリが図６のエントリ６１１である場合、ノード種別はサーバであり、イベント種別はｉＳＣＳＩ通信エラーである。次に、ｉＳＣＳＩ通信エラーが生じているサーバについて、エントリ７１１においてイベント消去設定テーブル１３３を参照することにより、有効期間７０１は１０分であって、減衰率７０４は毎分０．３である。従って、本例においてステップ１３１７でイベント消去タスクテーブル１３４内に生成されたタスクエントリは、開始時刻８０１＝「現在の日時」＋１０分；ノード名８０２＝「サーバＡ」；イベント種別８０３＝「ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ」、および減衰率８０５＝０．３となろう。
【００６１】
ステップ１３１８において、イベント書込プログラム１２４は、マッチング率評価プログラム１２５を起動し、ステップ１３１３で決定された条件オブジェクト４０１をパラメータとして渡す。処理されるエントリが図６のエントリ６１１である上述の例では、パラメータは図４の条件オブジェクト４０１ａとなる。これに続いて、イベント書込プログラム１２４が処理を終了させる。
【００６２】
マッチング率評価の処理
図１４に、監視コンピュータ１０１内でマッチング率評価プログラム１２５により実行されるマッチング率評価を実行する処理例のフローチャートを示す。マッチング率評価プログラム１２５は、イベント書込プログラム１２３またはイベント消去プログラム１２７からの起動により処理を開始する。
【００６３】
ステップ１４０１において、マッチング率評価プログラム１２５は、イベント書込プログラム１２３またはイベント消去プログラム１２７により起動されると特定の条件オブジェクト４０１をパラメータとして受信する。
【００６４】
ステップ１４０２において、マッチング率評価プログラム１２５は、パラメータとして渡された特定の条件オブジェクト４０１に接続する演算子オブジェクト４０２を取得する。
【００６５】
ステップ１４０３において、マッチング率評価プログラム１２５は、ステップ１４０２で取りだされた特定の演算子オブジェクト４０２に接続する結論オブジェクト４０３を取得する。
【００６６】
ステップ１４０４において、マッチング率評価プログラム１２５は、特定の結論オブジェクト４０３から任意の演算子オブジェクト４０２まで、次いで任意の演算子オブジェクト４０２から他の任意の条件オブジェクト４０１まで接続を辿ることにより、ステップ１４０３で取得した特定の結論オブジェクト４０３と合わせて、全ての条件オブジェクト４０１を取得する。
【００６７】
ステップ１４０５において、マッチング率評価プログラム１２５は、特定された条件オブジェクト４０１の重み値の合計を計算する。例えば、図４に示す例において、結論オブジェクト４０３ａは演算子オブジェクト４０２ａ〜４０２ｄに接続している。演算子オブジェクト４０２ａ〜４０２ｄは各々条件オブジェクト４０１ａ〜４０１ｄに接続している。条件オブジェクト４０１ａ〜４０１ｄの各々は１．０の重み値を有し、従って本例で重みの合計は４．０に等しくなる。
【００６８】
ステップ１４０６において、マッチング率評価プログラム１２５は、公式「重みの合計／条件オブジェクトの数」に従いマッチング率（ＭＲ）の値を計算して、その結果を、対応する結論オブジェクト４０３のＭＲ属性に設定する。例えば、図４に示すように、結論オブジェクト４０３ａのＭＲは１．０（すなわち４．０／４）に等しくなる。
【００６９】
ステップ１４０７において、マッチング率評価プログラム１２５は、この演算子オブジェクト４０２に接続する全ての結論オブジェクト４０３が処理されたか否かを調べる。特定の演算子オブジェクト４０２に接続する全ての結論オブジェクト４０３が処理済みである場合、処理はステップ１４０８へ進み、さもなければ処理は次の結論オブジェクト４０３を処理すべくステップ１４０３に戻る。例えば、図４に示す例において、結論オブジェクト４０３ｂおよび４０３ｃもまた、演算子オブジェクト４０２ａに接続している。従って、結論オブジェクト４０３ｂおよび４０３ｃに対してもまた、それらの結論オブジェクトに関してマッチング率を決定すべくステップ１４０３〜１４０６が実行される。
【００７０】
ステップ１４０８において、マッチング率評価プログラム１２５は、元の条件オブジェクト４０１に接続する全ての演算子オブジェクト４０２が処理されたか否かを調べる。全て処理済みならば処理はステップ１４０９へ進み、さもなければ処理は次の演算子オブジェクト４０２を処理すべくステップ１４０２に戻る。例えば、図４に示す例では元の条件オブジェクト４０１ａに接続している追加的な演算子オブジェクト４０２が存在しない。
【００７１】
ステップ１４０９において、マッチング率評価プログラム１２５は、マッチング率がパラメータとして計算された結論オブジェクト４０３を渡すことによりマッチング率監視プログラム１２６を起動して、処理を終了させる。
【００７２】
マッチング率監視の処理
図１５に、監視コンピュータ１０１内でマッチング率監視プログラム１２６により実行されるマッチング率監視を実行する処理例のフローチャートを示す。マッチング率監視プログラム１２６は、当該処理をマッチング率評価プログラム１２５から起動することにより開始する。
【００７３】
ステップ１５０１において、マッチング率監視プログラム１２６は、マッチング率評価プログラム１２５からパラメータとして１つ以上の結論オブジェクト４０３を受信して、そのうち１つを処理すべく選択する。
【００７４】
ステップ１５０２において、マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５から１つのエントリを取得する。
【００７５】
ステップ１５０３において、マッチング率監視プログラム１２６は、選択された結論オブジェクト４０３のマッチング率（ＭＲ）がステップ１５０２で取得したエントリの条件を満たすか否かを調べる。条件を満たす場合、処理はステップ１５０４へ進み、さもなければ処理はステップ１５０５へ進む。
【００７６】
ステップ１５０４において、マッチング率監視プログラム１２６は、外部モジュール１２８を起動する。外部モジュール１２８の例として、管理者に通知を送って根本原因分析の結論として得られた結果を知らせ、後で分析すべくデータベースに根本原因分析の結論として得られた結果を保存するモジュールがある。
【００７７】
ステップ１５０５において、マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５の全てのエントリが処理されたか否かを調べる。全て処理済みならば処理はステップ１５０６へ進み、さもなければ処理はマッチング率監視設定テーブル１３５の次のエントリを処理すべくステップ１５０２に戻る。
【００７８】
ステップ１５０６において、マッチング率監視プログラム１２６は、全ての結論オブジェクト４０３が処理されたか否かを調べる。全て処理済みならば処理を終了し、さもなければ処理は次の結論オブジェクト４０３を処理すべくステップ１５０１に戻る。
【００７９】
イベント消去の処理
図１６に、監視コンピュータ１０１内でイベント消去プログラム１２７により実行されるイベント消去を実行する処理例のフローチャートを示す。イベント消去プログラム１２７はこの処理を周期的に、例えば所定の間隔で開始する。
【００８０】
ステップ１６０１において、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４を参照して、開始時刻８０１が最も早い１つのタスクエントリを選択する。
【００８１】
ステップ１６０２において、イベント消去プログラム１２７は、当該タスクエントリの開始時刻８０１が現在の日時と同一であるか、または現在の日時より以前であるか否かを調べる。現在の日時と同一またはより以前である場合、処理はステップ１６０３へ進む。一方、イベント消去タスクテーブル１３４に現在の日時と同一またはより以前のエントリが存在しない場合、この時点および処理でイベントを消去する必要がない。
【００８２】
ステップ１６０３において、イベント消去プログラム１２７は、当該エントリのノード名８０２、イベント種別８０３、有効期間８０４、および減衰率８０５を取得する。
【００８３】
ステップ１６０４において、イベント消去プログラム１２７は、ルールメモリ１２１を参照して、ステップ１６０３で決定されたノード名８０２およびイベント種別８０３に対応する条件オブジェクト４０１を取得する。
【００８４】
ステップ１６０５において、イベント消去プログラム１２７は、ステップ１６０４で取得した条件オブジェクト４０１から重み値を取得して、取得した条件オブジェクト４０１の重み値を「重みマイナス減衰率」の結果に設定する。例えば、重み値が１．０に等しく、且つ減衰率が毎分０．３ポイントに等しい場合、条件オブジェクト４０１の新しい重み値は、次の１分間にわたり行なわれたどのマッチング率計算についても０．７に等しくなる。重み値は１分経過後に、これに続く１分間に計算されるマッチング率のために再び０．３ポイント下げられて０．４になる。
【００８５】
ステップ１６０６において、イベント消去プログラム１２７は、重み値がゼロ以下であるか否かを調べる。ゼロ以下ならば処理はステップ１６０８へ進み、さもなければ処理はステップ１６０７へ進む。
【００８６】
ステップ１６０７において、重み値が依然としてゼロより大きいため、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４の当該タスクエントリの開始時刻８０１を「開始時刻８０１＋１分」に更新する。
【００８７】
一方、ステップ１６０８において、重み値がゼロ以下である場合、イベント消去プログラム１２７は、選択された条件オブジェクト４０１の重み属性を０．０に等しく設定する。
【００８８】
ステップ１６０９において、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４から特定のタスクエントリを削除する。
【００８９】
ステップ１６１０において、イベント消去プログラム１２７は、全ての結論オブジェクト４０３をパラメータとして渡すことによりマッチング率評価プログラム１２５を起動する。従って、イベント消去プログラム１２７が減衰率に応じて条件オブジェクト４０１の重み値を徐々に下げて行くことにより、対応する結論オブジェクト４０３のマッチング率を下げることがわかる。
【００９０】
上の開示から明らかなように、本発明の例示的な実施形態では分析エンジンが増加分または減少分のイベントを処理するため、根本原因分析の実行に必要な計算コストを減らすことができる。例えば、分析エンジンは、たとえ１つ以上の条件要素が真でないと判定されたとしても最も可能性の高い結論を決定できる。これは、たとえルールを真にするために必要な１つ以上のイベントが分析エンジンに通知されなかったとしても分析エンジンがルールのマッチング率を計算できるためである。更に、イベントの有効期間を設定し、且つ減衰により段階的な削除を行なうことにより、分析精度を向上させることができる。従って、本発明の実施形態は、根本原因分析の精度を向上させると共に計算コストを減らす。例えば、本発明によれば、計算コストを減らすべく、増加分および減少分の根本原因分析に用いられるイベントを追加および削除することが可能である。
【００９１】
根本原因分析の計算コストを減らすべく、本発明の実施形態はオブジェクトモデルを構築する分析エンジンを含む。このオブジェクトモデルは、重複除外の概念に基づいていてよい。拡張ルールの中で反復する条件要素がいくつかある。例えば、条件要素＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞がルール１、ルール２およびルール３に出現する場合、オブジェクトモデルにおいて＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞に対応する条件オブジェクトの数は１である。イベントが受信されると、分析エンジンは対応する条件オブジェクトの状態を更新することができる。更に、この状態変化は、各々の関連するルールオブジェクトへの接続を介して伝播する。このオブジェクトモデルによれば、分析エンジンは、受信されたイベントに関係しないオブジェクトにアクセスする必要がない。従って、分析エンジンに伴う計算コストが減少する。
【００９２】
更に、例示的な実施形態において、分析エンジンは２つ以上のイベントから原因を分析することができる。分析エンジンが１つのイベントを受信する都度、増加分の分析処理を実行する。昨日生起したような古いイベントを現在のイベントと同一の分析に含めることで誤った結論が導かれる恐れがあるため、分析エンジンは所定のタイミングで古いイベントを削除することができる。例示的な実施形態において、古くなったイベントを削除するために、分析エンジンは、条件オブジェクトの状態を変更して、削除されたイベントに関係していて影響を受けるルールだけを再計算することにより、各ルールのマッチング率を再計算する。
【００９３】
また、図１６に関して上述したように、本発明の実施形態はイベント消去コンポーネントを含み、所定の時間（有効期間）および予定される削除タスクに基づいてイベントを削除する。本発明の例示的な実施形態において、イベントの有効期間はイベントの種別に基づいてよいため、分析の精度を向上させることができる。例えば、イベントの発生元がネットワークスイッチまたはストレージ等の共用リソースである場合、共用リソースは他の多くの原始リソースと関係するため、イベントの有効期間は長くなる筈である。一方、各種のコンピュータノードに最適な有効期間は、使用環境に応じて変動し得る。従って、イベント種別および／またはリソースタイプに応じて有効期間を規定する本発明のイベント消去設定テーブル１３３が、各イベント種別に最適な有効期間を可能にすべく提供される。
【００９４】
上述のように、本発明の分析エンジンは２つ以上のイベントから原因を分析することができるが、昨日のイベントを現在のイベントと同一の分析に含めることは誤った結論を導く恐れがあるため、分析エンジンは何らかのタイミングで古いイベントを削除する必要がある。しかし、先行イベントが現在のイベントに関係している可能性もあるため、本発明の実施形態は、減衰率を設定することにより、ルールメモリ内にイベント状態をオールオアナッシング、すなわち１．０か０．０か（存在するか存在しないか）とは別の何らかの方法で表すことに利点があることを考慮に入れている。従って、この実装により、ルールメモリ内のイベントが段階的に消滅すると共に、重要度も段階的に下げられる。従って、減衰率を含めることにより、たとえイベントの影響が小さくても、分析エンジンは当該イベントを分析オブジェクトに含めることができる。また、イベントの影響が小さいため、当該イベントは他のルールの評価に悪影響を及ぼさず、従って、分析エンジンは実際の現実世界の状態に基づいて根本原因を特定できる。
【００９５】
上述のように、分析エンジンが根本原因を計算し終えた際に、ディスプレイ１１７上で結果を管理者に提示することができる。追加または代替的に、計算された原因およびマッチしている率を含む結果を、後で分析すべくデータベースに保存できる。更に、分析エンジンは、特定のルールを満たすために必要な条件のうちどの条件が満たされていないかを判定することができ、これらの条件を管理者に提示したり、あるいはこの情報をデータベース等に保存したりできる。例えば、分析エンジンは、計算された生起原因および特定のルールを満たすために必要な条件のうち満たされなかった条件を管理者に見せるためにディスプレイに表示できる上に、また追加または代替的に、原因、計算されたマッチング率、および特定のルールを満たすために必要な条件のうち満たされなかった条件を、後で分析すべくデータベースに保存できる。また、上述の減衰方法を用いるのではなく、タイマーまたは管理者の手操作により１つ以上のイベントを無効にできるように分析エンジンを構成できる。
【００９６】
無論、図１および２に示すシステム構成は単に本発明を実装することが可能な情報システムの例に過ぎず、本発明は特定のハードウェアまたは論理構成に限定されない。本発明を実装するコンピュータおよびストレージシステムはまた、上述の発明の実装に用いるモジュール、プログラム、およびデータ構造の保存および読み出しが可能な公知の入出力装置（例：ＣＤおよびＤＶＤドライブ、フロッピーディスクドライブ、ハードディスクドライブ等）を備えていてよい。これらのモジュール、プログラム、およびデータ構造はそのようなコンピュータ可読媒体上で符号化されていてよい。例えば、本発明のデータ構造は、本発明で使用するプログラムが常駐する１つ以上のコンピュータ可読媒体とは独立に、コンピュータ可読媒体に保存されていてよい。本システムの構成要素は、任意の形式または媒体のデジタルデータ通信、例えば通信回路ネットワーク、により相互接続されていてよい。通信回路ネットワークの例として、ローカルエリアネットワーク、ワイドエリアネットワーク、例：インターネット、無線ネットワーク、ストレージエリアネットワーク等が含まれる。
【００９７】
上の記述において、本発明の完全な理解を得るべく、説明目的で多くの詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するためにこれらの具体的な詳細事項の全てが必要な訳ではない。また、本発明が多くの場合フローチャート、フロー図、構造図、またはブロック図として表された処理として記述できる点に注意されたい。フローチャートは動作を逐次的な処理として記述できるが、多くの動作が並行してまたは同時に実行できる。また、動作の順序を並べ替えてもよい。
【００９８】
当該技術分野で公知のように、上述の動作はハードウェア、ソフトウェア、またはソフトウェアとハードウェアの何らかの組合せにより実行できる。本発明の実施形態の各種の態様は、回路および論理装置（ハードウェア）を用いて実装できるが、プロセッサにより実行された場合に本発明の実施形態を実行する方法をプロセッサに実行させる機械可読媒体（ソフトウェア）に保存された命令を用いて他の態様を実装できる。更に、本発明のいくつかの実施形態はハードウェアだけで実行できるのに対し、他の実施形態はソフトウェアだけで実行できる。更に、本明細書に記載する各種の機能は、単一のユニットで実行することも、あるいは多くの構成要素にまたがって何通りもの仕方で実行することもできる。ソフトウェアで実行する場合、本方法はコンピュータ可読媒体に保存された命令に基づいて汎用コンピュータ等のプロセッサにより実行できる。必要ならば、命令は圧縮および／または暗号化形式で媒体に保存できる。
【００９９】
上の記述から、本発明が、根本原因分析の精度を向上させると共に計算コストを減らす方法、装置、およびコンピュータ可読媒体に保存されたプログラムを提供することは明らかであろう。また、本明細書で特定の実施形態を例示および記述しているが、当業者には開示された特定の実施形態を同じ目的を達成すべく計算された任意の構成で置換できることが理解されよう。本開示は、本発明の任意のおよびあらゆる適用または変型を包含することを目的としており、以下の請求項で使用する用語は、本発明を本明細書で開示した特定の実施形態に限定するものと解釈してはならない。むしろ、本発明の範囲は以下の請求項により完全に定義され、そのような請求項の等価物の全範囲と合わせて、請求項解釈の確立された原則に従って解釈されるべきである。
【技術分野】
【０００１】
最近の傾向として、企業の情報技術（ＩＴ）システムは益々巨大且つ複雑になっている。例えば、いくつかの企業において、ＩＴシステムはもはや単なる企業インフラではなく、当該企業と共同で企業の価値および競争力を高めるべく動作することが必要である。更に、ＩＴシステムの急激な成長は大企業に限らず、今や中規模の企業でも数百台のサーバを保有することができる。また、サーバの仮想化技術の急激な発展がこの傾向を加速させている。
【背景技術】
【０００２】
データセンタおよびその他のＩＴシステムの大規模な成長の最近の傾向にもかかわらず、ＩＴ組織の管理者は依然として、巨大且つ複雑なＩＴシステムを適切に動作させ続けるために、これらを効率的に管理することが求められている。問題が生じた場合、管理者は問題があると認識して、問題を分析し、次いで可能な限り早く問題を解決する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
通常、ＩＴシステムの健全性の監視、および発生し得る問題の分析は、何らかの形式の可用性および性能管理ソフトウェアを用いて実行される。このソフトウェアは通常、ＩＴシステム内の装置を発見し、それらの接続を識別して、時には問題が起きている場所を識別する能力も含んでいる。そのような管理ソフトウェアの使用を通じて、管理者は、以前は手動で実行しなければならなかった多くの退屈なオペレーション作業から解放される。しかし、上述のように、ＩＴシステム自体が急速に発展している一方で、ＩＴ予算は通常、より制約される傾向にある。この結果、各々の管理者がＩＴシステムの非常に大きな領域を管理する責任を負うことになり、これらのシステムの規模では、発生する恐れのある問題の実際の場所および「根本原因」の特定が困難になる場合がある。例えば、いくつかのベンダーが根本原因分析用の製品を提供しているが、これらの製品は、分析エンジンに入力すべきイベントの時間範囲を決定するための何らの機構も提供できていない。これは、計算コストが非効率である上に分析の精度が不十分であることを意味する。従って、ＩＴシステム環境における故障、欠陥その他の事象の根本原因を管理者が発見することを支援するソリューションに対するニーズが依然として存在する。
【０００４】
根本原因分析は、情報システム環境におけるエラーの根本原因である情報システムのノードの位置を特定する技術である。例えば、サーバ、スイッチ、ストレージ等、多くの異なるノードからなるトポロジを有する情報システムにおいて、それらのノードの１つがシステムにおける故障、エラーその他の事象を引き起こした場合、故障はシステムトポロジ内の当該ノードに接続している他のあらゆるノードに影響を及ぼし、ＩＴシステム内の異なる多くのノードからエラーイベントメッセージが管理者へ発行されることがある。従ってある場合には、システム内のどのノードがエラーの実際の根本原因であるかを管理者が判定することが極めて困難になり得る。
【０００５】
根本原因分析エンジンは、複数のエラーイベントメッセージおよびそれらの相互関係を分析し、次いで分析の結果として計算根本原因を出力する。現在、広範に用いられている２種類の公知の根本原因分析技術がある。一つはスマーツコードブック相関技術として知られており、もう一方はルール推論エンジンとも呼ばれるエキスパートシステムによる分析を利用する技術であって、例えばＲｅｔｅアルゴリズムおよび日立社のＥＳ／カーネルが含まれる。
【０００６】
スマーツコードブック相関技術（ＣＣＴ）
ＣＣＴは、行動モデルおよびトポロジに基づいて自動的にコードブックを生成する。一群のイベントを兆候としてコードブックに入力することにより問題を容易に出力できる。しかし、ＣＣＴは、コードブックに入力されるイベントの時間範囲を決定する何らの機構も提供できない。従って、生成されたイベントの時系列上の正しい位置を判定する手段が無い。イベントの入力範囲が不正確な場合、得られた結果もまた不正確であり得る。例えば、一日前にエラーが発生し、次いで今日別のエラーが発生したならば、２つのエラーは無関係であると結論付けることが現実的である場合が多い。しかし、ＣＣＴ分析は通常、イベントが発生する都度、先行イベントを含めて実行され、従って同一イベントを繰り返し処理する必要があるため、分析の精度に影響を及ぼすとともにイベントの根本原因を計算するコストが大幅に増大する。
【０００７】
従来のエキスパートシステム
「Ｒｅｔｅマッチングアルゴリズム」は、従来のエキスパートシステムの一例である。この種のエキスパートシステムは、ルールベースのマッチングアルゴリズムとして機能する。本明細書で以下に引用する「Ｒｅｔｅマッチングアルゴリズム」においてＢ．Ｓｃｈｎｅｉｅｒが議論するように、Ｒｅｔｅアルゴリズムはパターンマッチングにおける比較の速度を向上させるべく１９７０年代後半に開発された。Ｒｅｔｅアルゴリズム以前は、旧来システムではパターンマッチングの実行に自身の時間の９０％も費やしていたことが研究により示された。これらのシステムはパターンマッチング処理全体を反復し、各々のルールを順に採用して、データメモリを見渡して特定のルールの条件が満たされるか否かを判定してから次のルールへ進む。その後、効率を上げるべくデータ要素およびルール条件に索引付けを行なう方法が発見されていて、プログラムの実行速度を向上させるものの、依然として一連のルールおよびデータ要素全体に渡る反復を必要とする。Ｒｅｔｅアルゴリズムは、この反復ステップの大部分を除外するため、競合するアルゴリズムに比べて大幅に改良されている。
【０００８】
Ｒｅｔｅマッチングアルゴリズムは、競合集合の現在の内容をメモリに保存して、データ要素がメモリに追加および削除されたときのみ競合集合から項目を追加および削除することによりデータ要素全体にわたる反復を回避する。例えば、従来の反復的なパターンマッチングシステムにおいて、２つのほぼ同一のルールを追加する場合、各々のルールに対して反復処理全体が実行される。しかし、Ｒｅｔｅアルゴリズムでは、ほぼ同一のルールは、Ｒｅｔｅの木構造ソーティングネットワークによって冗長であると扱うことができる。Ｒｅｔｅパターンコンパイラは、個々の副条件のネットワークを構築する。これは最初に、プロダクションルールの各要素に個別に注目して、各属性を個別にテストするノードの連鎖を構築する。次いで、要素同士の比較に注目して、ノードの連鎖を新規ノードに接続する。最後に、ターミネータノードを追加して、プロダクションルールの全ての条件が満たされた旨の信号を送る。追加的なプロダクションルールは、同一ネットワークに接合される。それらに共通のテストが存在しない場合、相互に全く作用しない。
【０００９】
関連技術にはＭａｓｕｉ他による米国特許第４，７２７，４８７号明細書「Ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｍｅｔｈｏｄ ｉｎ ａ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ」、Ｔａｎｏ他による米国特許第４，７６１，７４６号明細書「Ｄｙｎａｍｉｃ ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ ｍｅｔｈｏｄ ｆｏｒ ｄｉｓｃｒｉｍｉｎａｔｉｏｎ ｎｅｔｗｏｒｋ」、Ｍａｓｕｉ他による米国特許第４，８６８，７６３号明細書「Ｋｎｏｗｌｅｄｇｅ−ｂａｓｅｄ ｓｙｓｔｅｍ ｈａｖｉｎｇ ｐｌｕｒａｌ ｐｒｏｃｅｓｓｏｒｓ」、Ｔａｎｏ他による米国特許第５，１４６，５３７号明細書「Ｍｅｔｈｏｄ ｆｏｒ ｊｕｄｇｉｎｇ ｗｈｅｔｈｅｒ ｃｏｎｄｉｔｉｏｎｓ ａｒｅ ｓａｔｉｓｆｉｅｄ ｂｙ ｕｓｉｎｇ ａ ｎｅｔｗｏｒｋ ｈａｖｉｎｇ ａ ｐｌｕｒａｌｉｔｙ ｏｆ ｎｏｄｅｓ ｒｅｐｒｅｓｅｎｔｉｎｇ ｔｈｅ ｃｏｎｄｉｔｉｏｎｓ」、Ｔａｎｏ他による米国特許第５，３５３，３８５号明細書「Ｉｎｆｅｒｅｎｃｅ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｕｓｅ ｗｉｔｈ ｋｎｏｗｌｅｄｇｅ ｂａｓｅ ｓｙｓｔｅｍ ａｎｄ ｋｎｏｗｌｅｄｇｅ ｂａｓｅ ｓｙｓｔｅｍ ｓｕｐｐｏｒｔ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｕｓｉｎｇ ｔｈｅ ｉｎｆｅｒｅｎｃｅ ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ」、Ｙｅｍｉｎｉ他による米国特許第７，１０７，１８５号明細書「Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｅｖｅｎｔ ｃｏｒｒｅｌａｔｉｏｎ ａｎｄ ｐｒｏｂｌｅｍ ｒｅｐｏｒｔｉｎｇ」、Ｏｈｓｉｅ他による米国特許第７，２５４，５１５号明細書「Ｍｅｔｈｏｄ ａｎｄ ａｐｐａｒａｔｕｓ ｆｏｒ ｓｙｓｔｅｍ ｍａｎａｇｅｍｅｎｔ ｕｓｉｎｇ ｃｏｄｅｂｏｏｋ ｃｏｒｒｅｌａｔｉｏｎ ｗｉｔｈ ｓｙｍｐｔｏｍ ｅｘｃｌｕｓｉｏｎ」、Ｓｃｈｎｅｉｅｒ，Ｂ．による「Ｔｈｅ Ｒｅｔｅ Ｍａｔｃｈｉｎｇ Ａｌｇｏｒｉｔｈｍ」（Ｄｒ． Ｄｏｂｂ’ｓ Ｊｏｕｒｎａｌ，Ｄｅｃ．５，２００２）、および、Ｆｏｒｇｙ，Ｃ．Ｌ．による「Ｒｅｔｅ: Ａ ｆａｓｔ ａｌｇｏｒｉｔｈｍ ｆｏｒ ｔｈｅ ｍａｎｙ ｐａｔｔｅｒｎ／ｍａｎｙ ｏｂｊｅｃｔ ｐａｔｔｅｒｎ ｍａｔｃｈｉｎｇ ｐｒｏｂｌｅｍ」（ＡＲＴＩＦＩＣＩＡＬ ＩＮＴＥＬＬＩＧＥＮＣＥ， Ｖｏｌ．１９，ｎｏ．１，１９８２，ｐｐ．１７−３７）が含まれ、これらの開示内容を全て本明細書に引用している。
【課題を解決するための手段】
【００１０】
本発明の例示的な実施形態は、根本原因分析に伴う計算の精度を向上させコストを減らすソリューションを提供する。本発明の上記および他の特徴並びに効果は、以下の好適な実施形態の詳細な説明から当業者には明らかになろう。
【００１１】
添付の図面は、上述した一般的な説明および以下の好適な実施形態の詳細な説明と合わせて、現在考察されている本発明の最良の形態の好適な実施形態の原理の例示および説明に有用である。
【図面の簡単な説明】
【００１２】
【図１】本発明の方法および装置が適用できるハードウェアおよび論理構成の一例を示す。
【図２】情報システムにおける機能関係の一例を示す。
【図３】ルールリポジトリの一例を示す。
【図４】ルールメモリ関連付けの一例を示す。
【図５】イベントメッセージの例示的なデータ構造を示す。
【図６】イベントキューテーブルの例示的なデータ構造を示す。
【図７】イベント消去設定テーブルの例示的なデータ構造を示す。
【図８】イベント消去タスクテーブルの例示的なデータ構造を示す。
【図９】マッチング率監視設定テーブルの例示的なデータ構造を示す。
【図１０】イベント消去に続く減衰の例のグラフ表現を示す。
【図１１】ルール決定の例の概念図を示す。
【図１２】ルールローダープログラムの処理例を示す。
【図１３】イベント受信プログラムおよびイベント書込プログラムの処理例を示す。
【図１４】マッチング率評価プログラムの処理例を示す。
【図１５】マッチング率監視プログラムの処理例を示す。
【図１６】イベント消去プログラムの処理例を示す。
【発明を実施するための形態】
【００１３】
本発明の以下の詳細な説明において、開示の一部をなす添付図面を参照するが、これらは本発明を実施できる例示的な実施形態を示すものであって本発明を限定するものではない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。更に、詳細な説明は各種の例示的な実施形態を提供するが、以下に記述および図示するように、本発明は本明細書に記述および図示する実施形態に限定されるものではなく、当業者には公知または将来公知となる他の実施形態に拡張できる点に注意されたい。本明細書において「一実施形態」または「本実施形態」に言及する場合、当該実施形態との関連で記述されている特定の特徴、構造または特性は、本発明の少なくとも１つの実施形態に含まれることを意味しており、本明細書の各所でこれらの語句が出現しても必ずしも全て同一の実施形態を指している訳ではない。また、以下の詳細な説明において、本発明を完全に理解されるよう多くの具体的な詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するためにこれらの具体的な詳細事項の全てが必要な訳ではない。他の状況において、本発明を無用に分かり難くしないよう、公知の構造、材料、回路、処理およびインタフェースについては詳細に記述せず、および／またはブロック図の形式で示す場合がある。
【００１４】
更に、以下の詳細な説明のある部分は、コンピュータ内部の動作のアルゴリズムおよび記号的表現として示す。これらのアルゴリズム的記述および記号表現は、データ処理技術に精通した当業者が自身の発明の本質を他の当業者に最も効果的に伝達すべく用いる手段である。アルゴリズムとは、所望の最終状態または結果に達する一連の定義されたステップである。本発明において、実行されるステップは、有形の結果を実現するための有形の量を物理的に操作することを要求する。通常、但し必須ではないが、これらの量は、保存、転送、結合、比較、および他の操作が可能な電気または磁気信号の形式をなす。原理的に共通に利用できるとの理由で、これらの信号をビット、値、要素、記号、文字、項目、数、命令等と称することが往々にして便利であることがわかっている。しかし、これらの全ておよび同様の項目は、適切な物理量に関連付けられるべきものであり、これら物理量に付けられた便宜的なラベルに過ぎないことに留意すべきである。特に別途明言しない限り、以下の記述から明らかなように、本明細書の記述を通じて、「処理する」、「計算する」、「算出する」、「判定する」、「表示する」等の用語を用いた説明は、コンピュータシステムまたは当該コンピュータシステムのレジスタおよびメモリ内の物理的（電子的）な量として表現されたデータを操作して、当該コンピュータシステムのメモリまたはレジスタまたは他の情報記憶、伝送または表示装置内の物理量として同様に表現された他のデータに変換する他の情報処理装置の動作および処理を含んでいてよい。
【００１５】
本発明はまた、本明細書における動作を実行する装置に関する。この装置は、必要な目的のために特別に構築されていても、または、１つ以上のコンピュータプログラムにより選択的に起動または再設定される１つ以上の汎用コンピュータを含んでいてもよい。そのようなコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出し専用メモリ、ランダムアクセスメモリ、固体装置およびドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。本明細書に示すアルゴリズムおよびディスプレイは、いかなる特定のコンピュータまたは他の装置にも本質的には関係していない。各種の汎用システムを、本明細書の教示によるプログラムおよびモジュールと共に用いてもよいが、所望の方法ステップを実行するためのより特化した装置を構築した方が便利なことが分かる場合がある。これら各種のシステムの構造は以下に開示する説明で明らかになる。本発明はまた、いかなる特定のプログラミング言語も前提としては記述していない。以下に記述するように、本発明の教示を実行するために各種のプログラミング言語を用いてもよいことが理解されよう。プログラム言語の命令は、１つ以上の処理装置、例えば中央処理装置（ＣＰＵ）、プロセッサ、またはコントローラにより実行できる。
【００１６】
以下でより詳しく述べるように、本発明の例示的な実施形態は、より高い精度およびより高い計算費用対効果を有する、根本原因分析を実行する装置、方法、およびコンピュータプログラムを提供する。例示的な実施形態によれば、分析エンジンは各々のイベントを受け取った各時点でのルールのマッチング率を計算し、計算の結果が分析エンジンのルールメモリに保存される。マッチング率は、特定の根本原因分析の結果を判定するために、どのルールの結論が根本理由を正確に識別する可能性が最も高いかを判定するために用いる確率または計算された比率（すなわち、確度）である。これらの実施形態でルールメモリに保存される各イベントは、ルールメモリに保存される他のイベントに影響を及ぼすことなくルールメモリから削除することが可能である。更に、各イベントには当該イベントの生存時間である有効期間が与えられており、有効期間が満了すると、分析エンジンはルールメモリから当該イベントを削除する。従って、本発明の例示的な実施形態において、分析エンジンは、イベントが削除された際に影響を受けるルールのマッチング率を再計算するだけでマッチング率を再計算することが可能である。従って、本発明の例示的な実施形態において、分析エンジンが必要に応じて増加分または減少分のイベントを処理するため、根本原因分析を実行するための計算コストが減少する。更に、古いイベントを削除して根本原因分析計算に対するそれらの影響を排除できるため、精度を向上させながら同時に全体的な計算要件を減らすことができる。
【実施例】
【００１７】
ハードウェアおよび論理構成
図１に、本発明の実施形態を実装可能な情報システムの例示的なハードウェアアーキテクチャおよび論理構成を示す。図１のシステムは、監視コンピュータ１０１、１つ以上のサーバまたは他のコンピュータ１０２、１つ以上のネットワークスイッチまたは他のネットワーク装置１０３、およびＬＡＮ（ローカルエリアネットワーク）１０５等のネットワークを介して通信すべく接続する１つ以上のストレージ１０４を含む。
【００１８】
監視コンピュータ１０１は、ＣＰＵ１１１、メモリ１１２、ハードディスクドライブ（ＨＤＤ）１１３等の記憶媒体、ビデオインターフェース１１４、およびシステムバス１１６を介して接続するネットワークインターフェース１１５（Ｉ／Ｆ）を含む汎用コンピュータであってよい。監視コンピュータ１０１の論理モジュールおよびデータ構造は、ルールメモリ１２１、ルールローダープログラム１２２、イベント受信プログラム１２３、イベント書込プログラム１２４、マッチング率評価プログラム１２５、マッチング率監視プログラム１２６、イベント消去プログラム１２７、外部モジュール１２８、ルールリポジトリ１３１、イベントキューテーブル１３２、イベント消去設定テーブル１３３、イベント消去タスクテーブル１３４、およびマッチング率監視設定テーブル１３５を含む。ルールメモリ１２１は、イベントの状態および根本原因分析の結果として導かれたルールを表すオブジェクトモデルを保存する。ルールローダープログラム１２２、イベント受信プログラム１２３、イベント書込プログラム１２４、マッチング率評価プログラム１２５、マッチング率監視プログラム１２６、イベント消去プログラム１２７、および外部モジュール１２８は、メモリ１１２または他の計算機可読媒体に保存され、ＣＰＵ１１１により実行される。以下に記述するルールリポジトリ１３１、イベントキューテーブル１３２、イベント消去設定テーブル１３３、イベント消去タスクテーブル１３４、マッチング率監視設定テーブルのデータ構造は、ディスク１１３または他の適当な計算機可読媒体に保存されていてよい。
【００１９】
監視コンピュータ１０１は、ＬＡＮ１０５と通信すべく接続されて、サーバ１０２、ネットワークスイッチ１０３、およびストレージ１０４等、監視対象である動作ノードからイベントメッセージを受信するために用いるネットワークインターフェース１１５を有する。ディスプレイ１１７はビデオインターフェース１１４に接続されていて、外部モジュール１２８からの根本原因分析の結果および他の情報を管理者に提示するために用いられる。
【００２０】
各サーバ１０２は、当技術分野で公知のようにアプリケーション等を実行させている監視対象ノードであってよい。サーバ１０２は、ＣＰＵ１４６、メモリ／ストレージ１４７、およびネットワークインターフェース１４２を含む汎用コンピュータであってよい。各サーバ１０２は、特定の状態変化が検出された場合にＬＡＮ１０５を介して監視コンピュータ１０１にイベントメッセージを送る監視エージェント１４１を含んでいてよい。例示する実施形態において、各サーバ１０２はまた、本発明の行動を説明する一例としてｉＳＣＳＩ（インターネット小型計算機システムインターフェース）イニシエータ１４３を有する。例えば、サーバ１０２はｉＳＣＳＩディスク１５１を仮想的にローカルＨＤＤのように利用できるが、これはｉＳＣＳＩイニシエータ１４３およびストレージ１０４の記憶容量により実現される。更に、代替的な実施形態において、ｉＳＣＳＩの代わりにまたはこれに加えて、他の通信および記憶プロトコルを用いてもよい。
【００２１】
各ストレージ１０４は、同様に当該技術分野で公知であるように、サーバ１０２上で動作するアプリケーション用の記憶容量を提供するための、または他の目的のための監視対象ノードであってよい。ストレージ１０４はストレージコントローラ１６１、ネットワークインターフェース１６３、および記憶媒体１６２を含み、記憶媒体１６２は本実施形態ではＨＤＤであってよいが、固体記憶媒体、光記憶媒体等、他の種類の記憶媒体であってよい。これらの実施形態において、ストレージ１０４は、サーバ１０４に対しｉＳＣＳＩ論理ボリュームを記憶容量として提供すべく構成される。従って、例示する実施形態において、３台のサーバ１０２ａ〜ｃがネットワークスイッチ１０３を介してストレージ１０４に接続されていて、ストレージ１０４が各サーバ１０２ａ〜ｃに対してｉＳＣＳＩボリュームを提供する。また、ストレージ１０４は、ストレージ１０４の状態を監視して監視コンピュータ１０１にイベントを報告できる監視エージェント１６６を含んでいてよい。あるいは、サーバ１０２の１台上の監視エージェント１４１が、ストレージ１０４およびネットワークスイッチ１０３の状態を監視することができる。更に、ある場合には、ネットワークスイッチ１０３は自身の監視エージェントを有していてよい。
【００２２】
機能関係ブロック図
図２に、例示的な実施形態による情報システム内における例示的な機能関係を表すブロック図を示す。図２において、監視コンピュータ１０１のモジュールおよびデータ構造を含む監視システム２０１は、サーバ１０２、ネットワークスイッチ１０３、およびストレージ１０４等の複数の監視対象ノード２０２を監視すべく構成される。監視システム２０１において、ルールローダープログラム１２２は、ルールリポジトリ１３１からのルールを読み、それらをルールメモリ１２１にロードする。イベント受信プログラム１２３は、監視対象ノード２０２を含む情報システムの監視対象部分からイベントメッセージを受信して、これらのイベントメッセージをイベントキューテーブル１３２に保存すべく構成される。例えば、サーバ１０２、スイッチ１０３、およびストレージ１０４上の監視エージェントは、イベントが生起するとイベントメッセージをイベント受信プログラム１２３に送ることができる。イベント書込プログラム１２４は、イベントキューテーブル１３２からイベントメッセージを取得して、取得したイベントメッセージをルールメモリ１２１に書き込む。イベント書込プログラム１２４はまた、イベント消去設定テーブル１３３の設定に従い、イベント消去タスクテーブル１３４内にイベント消去タスクを生成する。イベント書込プログラム１２４は、自身のプロセス終了時にマッチング率評価プログラム１２５を起動する。マッチング率の値は新規イベントにより変化する可能性があるため、マッチング率評価プログラム１２５はイベントの入力に関連する各ルールについてのマッチング率を評価する。マッチング率評価プログラム１２５は、自身のプロセス終了時にマッチング率監視プログラム１２６を起動する。マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５の条件に従いマッチング率の値を調べる。マッチング率が条件を満たす場合、マッチング率監視プログラム１２６は１つ以上の外部モジュール１２８を起動する。外部モジュール１２８の一例として、システム管理者に根本原因に関する通知を送るモジュールがある。イベント消去プログラム１２７はタイマーにより起動されて、イベント消去タスクテーブル１３４に基づいて周期的にタスクを実行する。イベント消去プログラム１２７は、以前に生起したイベントを当該イベントから経過した時間数に基づいて消去する。
【００２３】
ルールリポジトリおよびルール
一般ルールは、システムトポロジから独立した形式で記述される条件およびアクションの組である。拡張ルールは、一般ルールおよび特定のトポロジから伝播されて生成されるルールである。各々の顧客に応じて監視対象環境が情報システム毎に大幅に変化し得るため、システムトポロジに基づいて一般ルールを拡張ルールに拡張する処理が最初に必要となる。
【００２４】
図３に、ルールリポジトリ１３１に常駐し、図１に示す情報システムのために伝播される拡張ルールであるルール３０１〜３０５の例を示す。一般に、ルールは２つの部分、すなわち「ＩＦ」部３１１と呼ばれる第１の部分３１１および「ＴＨＥＮ」部３１２と呼ばれる第２の部分３１２に分けることができる。ＩＦ部３１１は、１つ以上の条件要素を含んでいてよい。例えば、ルール３０１は、ＩＦ部３１１に４つの条件、すなわち「＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＡのｉＳＣＳＩ通信エラー）＞」、「＜ＳｅｒｖｅｒＢ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＢのｉＳＣＳＩ通信エラー）＞」、「＜ＳｅｒｖｅｒＣ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ（サーバＣのｉＳＣＳＩ通信エラー）＞」、および「＜Ｓｔｏｒａｇｅ１ Ｃｏｎｔｒｏｌｌｅｒ＿Ｅｒｒ（ストレージ１のコントローラエラー）＞」を有する。従って、「ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ」のようなエラーイベントが「サーバＡ」から受信された場合に、条件「＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞」は真になる。ＩＦ部３１１の全ての条件が真ならば、特定のルールに従いＴＨＥＮ部３１２の結論要素は真であると推定される。例えば、ルール３１１は結論要素「＜Ｓｔｏｒａｇｅ１ Ｃｏｎｔｒｏｌｌｅｒ＿Ｅｒｒ＞」を有する。従って、ルール３０１によれば、サーバＡ、サーバＢ、およびサーバＣは通信エラーを報告し、ストレージ１はコントローラエラーを報告し、ルール３０１は根本原因がストレージ１におけるコントローラエラーであることを示す。また、ルールが複数の結論を有する（すなわち、ＴＨＥＮ部が複数のノードにおける事象を指摘する等）ケースが起こり得る。例えば、各々のＩＦ部に同じ条件を有するが各々のＴＨＥＮ部には異なる結論を有する複数のルールを定義することが好ましい場合にルールのＴＨＥＮ部が複数の結論を有していてよい。例えば、「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｘ（Ａ Ｂ ＣならばＸ）」および「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｙ（Ａ Ｂ ＣならばＹ）」のような２つのルールがある場合、これらのルールを結合して１つのルール「ＩＦ Ａ Ｂ Ｃ ＴＨＥＮ Ｘ Ｙ（Ａ Ｂ ＣならばＸおよびＹ）」として定義できる。
【００２５】
ルールメモリ
図４に、ルールメモリ１２１に保存されたオブジェクトモデルのルールメモリ関連付けの例示的な構成図を示す。図４において、３種類のオブジェクト、すなわち、条件オブジェクト４０１、演算子オブジェクト４０２および結論オブジェクト４０３）がある。これらのオブジェクトおよびその接続は、ルールローダープログラム１２２により生成される。条件オブジェクト４０１は、４種の属性、すなわちノードの名前である「ノード名」、イベントの種別である「イベント種別」、イベントが受信された日時である「受信日時」、および条件に割り当てられた重み値である「重み」を含む。演算子オブジェクト４０２は「Ｎｏｔ」属性を有し、真または偽の値をとり得る。例えば、ルールに書かれた条件要素が「＜ＮＯＴ Ｓｔｏｒａｇｅ１ Ｖｏｌｕｍｅ＿Ｅｒｒ（ストレージ１のボリュームエラーではない）＞」等の指定された「ＮＯＴ」単項演算子である場合、この属性の値は「真」に設定され、さもなければ値は「偽」に設定される。結論オブジェクト４０３は４種の属性、すなわち特定のルールの識別子を指定する「ルール名」、ルールが適用されるノードを指定する「ノード名」、エラーの原因を識別する「原因」、および正確さの確率を示す「マッチング率」（ＭＲ）を有し、換言すれば、ＭＲ値はこの結論がイベントの根本原因である確度を示す。このオブジェクトモデルは条件要素の重複なしに形成される。ルールローダープログラム１２２は、ルールに規定された条件要素に従い条件オブジェクト４０１を生成する際に重複を除外する。これにより、イベント書込プログラム１２４は、受信した１つのイベントに対してイベントを何回も書く必要が無い。ルールは、結論オブジェクト４０３と演算子オブジェクト４０２を接続することにより表される。例えば、結論オブジェクト４０３ａは、演算子オブジェクト４０２ａ、４０２ｂ、４０２ｃ、４０２ｄとの４つの接続を有する。各演算子オブジェクト４０２は、ちょうど１つの条件オブジェクト４０１に接続している。従って、「ルール１」のＩＦ部は４つの条件からなる。結論オブジェクト４０３ｂもまた、演算子オブジェクト４０２ａ、４０２ｂ、４０２ｃ、４０２ｄとの４つの接続を有する。演算子オブジェクト４０２ａは、結論オブジェクト４０３ａ、４０３ｂ、４０３ｃにより共有される。
【００２６】
本発明の例示的な実施形態における「マッチング率」は、ルールの条件要素の総数を構成する要素のうちどの要素が真になるかに従う率で計算される確度である。マッチング率を計算する公式は以下のように表すことができる。
ＭＲ＝真の条件要素数／条件要素の総数
【００２７】
図４において、条件要素４０１ａ〜４０１ｄは真であり、ルール１の条件要素の総数は４である。従って、分析エンジンは４つ中の４つ（４／４）＝１．０という率を計算する。ルール２に関して、条件要素の総数は４であり、真の条件要素の数は３つしかないため、ルール２のオブジェクト結論４０３ｂのマッチング率について結果的に得られる率は３／４＝０．７５である。従って、マッチング率を設定することにより、分析エンジンは、ノードのうちの１つに関するイベントメッセージが分析エンジンに送られない場合に生じ得るように、たとえ１つの条件要素が真で無い場合でも、最も確率が高い結論を決定できる。これは例えば、ノードが監視システム２０１にエラーイベントメッセージを送信せずに故障した状況で生じる場合がある。
【００２８】
イベントメッセージ
図５に、イベント受信プログラム１２３が監視対象ノードの１つにある監視エージェント等から受信したイベントメッセージ５０５の例示的なデータ構造を示す。イベントメッセージ５０５は３種の情報、すなわち、「ノード種別」５０１、「ノード名」５０２、および「イベント種別」５０３を含む。ノード種別５０１は、サーバ、ネットワークスイッチまたはストレージ等、イベントメッセージが関係するノードの種別である。ノード名５０２は、情報システム環境において特定のＩＴノードを識別できる一意な名前である。イベント種別５０３は生起したイベントの種別を示す。
【００２９】
イベントキューテーブル
図６に、監視コンピュータ１０１に常駐するイベントキューテーブル１３２の例示的なデータ構造を示す。イベント受信プログラム１２３は、監視対象ノード２０２からイベントメッセージ５０５を受信したならば、イベント情報をこのテーブルに入れる。イベントキューテーブル１３２は、報告されたイベントのキューのリストを生成するため、イベントの入力−出力順序は先入れ先出し（ＦＩＦＯ）原則に従う。イベントキューテーブル１３２は、４つのカラム、すなわち、イベントを生成したノードの種別のリストを生成するノード種別６０１、対応するノードの内部名を示すノード名６０２、生起したイベントを示すイベント種別６０３、およびイベントメッセージが受信された日時を示す受信日時６０４を含む。ノード種別６０１、ノード名６０２、およびイベント種別６０３は、受信されたイベントメッセージ５０５から取得される。受信日時６０４は、イベント受信プログラム１２３がイベントメッセージを受信した日時である。イベントキューテーブル１３２は、イベント書込プログラム１２４のバッファとして機能する。イベント書込プログラム１２４は、イベントキューテーブル１３２からイベント情報を取得し、当該イベント情報をルールメモリ１２１に書き込む。
【００３０】
イベント消去設定テーブル
図７に、監視コンピュータ１０１に常駐するイベント消去設定テーブル１３３の例示的なデータ構造を示す。イベント消去設定テーブル１３３は、有効期間（生存時間）および各種のイベントの減衰率を指定するイベント消去プログラム１２７の設定情報を含む。イベント消去設定テーブル１３３は、受信されたイベントの各々に対して指定する有効期間および減衰率を決定すべくイベント書込プログラム１２４により使用される。イベント消去設定テーブル１３３において、ノード種別７０１は、イベントメッセージが生成されたノードの種別、イベント種別７０２はイベントの種別、有効期間７０３はイベントが考慮対象であり続ける時間（すなわちイベントの有効期間）、および減衰率７０４はイベントの重要性が時間の経過につれて減少する量である。有効期間７０３および減衰率７０４は、ノードの種別とイベント種別の組合せの各々に対して定義される。有効期間７０３は、イベントメッセージを受信した時点から、ルールメモリ１２１からのイベントの減衰が始まる時点までの期間である。減衰率７０４は、条件オブジェクト４０１の重み値（重み値）が減少する１分当たりの率である。例えば、有効期間が１０分で減衰率が毎分０．２ポイントである場合、イベントが受信された１０分後に、対応する条件オブジェクト４０１内の重み値が減少し始める。例えば、減衰率が毎分０．２であるため、１１分経過した時点で重み値は０．８になり、１２分経過した時点で重み値は０．６になって、重みが０．０または負値になるまで重み値は毎分減少し続ける。
【００３１】
イベント消去タスクテーブル
図８に、監視コンピュータ１０１に常駐するイベント消去タスクテーブル１３４の例示的なデータ構造を示す。イベント消去タスクテーブル１３４を用いて、各々の受信されたイベントの有効期間を管理する。イベント消去タスクテーブル１３４は、イベントが受信されるとイベント書込プログラム１２４により書き込まれて、イベントの消去を開始する時点を決定すべくイベント消去プログラム１２７により使用されるものであり、開始時刻８０１、ノード名８０２、イベント種別８０３、および減衰率８０４を含む。開始時刻８０１はイベント消去タスクを開始すべき日時である。開始時刻８０１は、公式「受信日時６０４＋有効期間７０３」により計算される。ノード名８０２は内部ノード名、イベント種別８０３はイベントメッセージを生起させたイベントの種別である。イベント消去プログラム１２７は、これら２つの値（ノード名８０２およびイベント種別８０３）により対象とする条件オブジェクト４０１を識別する。従って、ノード名８０２およびイベント種別８０３はイベントキューテーブル１３２内のノード名６０２およびイベント種別６０３から転記される。減衰率８０４はイベント消去設定テーブル１３３から転記される。
【００３２】
マッチング率監視設定テーブル
図９に、監視コンピュータ１０１に常駐するマッチング率監視設定テーブル１３５を示す。マッチング率監視設定テーブル１３５は、条件９０１およびアクション９０２を含む。条件９０１は、マッチング率監視プログラム１２６が調べる条件である。アクション９０２は、対応する条件が満たされた場合に外部モジュール１２８が実行すべきアクションである。例えば、エントリ９１１において条件ＭＲが０．８未満である場合、管理者に電子メールを送る必要がある。
【００３３】
重み値の減衰
図１０に、イベント書込からイベント消去までの条件オブジェクト４０１の重みの変化を説明するため、イベント消去の時刻に達した後の減衰の例を表すグラフを示す。条件オブジェクト４０１の最大重み値は１．０である。図１０に示すように、時刻１００１において、イベント書込プログラム１２４は新規イベント情報をルールメモリ１２１に書き込む際に、対応する条件オブジェクト４０１の重みが１．０に設定される。開始時刻１００１から第１の満了時刻１００２までの有効期間中、特定の条件オブジェクトの重み値は１．０に保たれる。次いで、１００３に示すように、有効期間が第１の満了時刻１００２に達すると、最終満了時刻１００４に至るまで当該条件オブジェクトに割り当てられた減衰率７０４に従いイベント消去プログラム１２７により重み値が１．０から０に減らされる。
【００３４】
結論オブジェクトのマッチング率値変動
図１１に、イベント書込からイベント削除に至る結論オブジェクト４０３のマッチング率（ＭＲ）値の変動を説明するグラフを示す。図１１において、ルール１（１１０１）、ルール２（１１０２）、およびルール３（１１０３）を説明用のルールの例として示す。更に、太い矢印１１２１はイベントの初期書込のタイミングを示し、細い矢印１１２３はイベント消去（減衰）が開始されるタイミングを示し、各々の対応する太い矢印１１２１と細い矢印１１２３の間で伸びているリボン１１２２は、対応するイベントの有効期間を示す。
【００３５】
イベント書込プログラム１２４が新規または更新されたイベント情報をルールメモリ１２１に書込んだ場合、各々のルールについてマッチング率（ＭＲ）値が再計算される。例えば、イベントＡ〜Ｇが追加または削除されるにつれて、破線１１１１は時間経過に伴うルール１（１１０１）のＭＲ値の変化を示し、実線１１１２は時間経過に伴うルール２のＭＲ値の変化を示し、点線１１１３は時間経過に伴うルール３のＭＲ値の変化を示す。例えば、イベント書込プログラム１２４が１１３０のタイミングでイベントＡを書込んだ場合、ルール１およびルール２の両方が自身のＩＦ部３１１にイベントＡを有するため、ＭＲ値はルール１に対して０．２５（１／４）およびルール２に対して０．３３（１／３）として計算される。
【００３６】
次に、イベント書込プログラム１２４が１１３１のタイミングでイベントＢを書込んだ場合、ルール１について４つのＩＦ条件のうち２つが満たされるため、ルール１に対してＭＲ値は０．５（２／４）として再計算される。ルール２およびルール３は共に自身のＩＦ部にイベントＢを有していないため、ルール２およびルール３のＭＲ値は変化しない。同様に、タイミング１１３２でイベントＣが追加された場合、ルール１のＭＲ値は０．７５（３／４）まで上がり、ルール２のＭＲ値は０．６６の（２／３）まで上がる。タイミング１１３３でイベントＤが生起した場合、ＩＦ部内の全ての条件が満たされるためルール１のＭＲ値は１（４／４）まで上がる。更に、Ｄがルール３のＩＦ部の条件の１つであるためルール３のＭＲ値は０．５（１／２）まで上がる。ルール２はイベントＤの影響を受けない。
【００３７】
イベントＡの生存期間が１１４１のタイミングで終了した場合、ＭＲ値はルール１について０．７５（３／４）、ルール２について０．３３（２／３）として再計算される。従って、情報システムの管理者は、図１１に示す例のような一連のＭＲ値計算を通じて、たとえルールのＭＲ値が１．０に等しい場合でも、イベントの最も可能性の高い根本原因を特定できる。
【００３８】
ルールローディングの処理
図１２に、監視コンピュータ１０１内でルールローダープログラム１２２により実行されるルールローディングの処理例のフローチャートを示す。ルールローダープログラム１２２は、監視コンピュータが起動されるとこの処理を開始すべく構成されていてよい。
【００３９】
ステップ１２００において、ルールローダープログラム１２２は、情報システムのシステムトポロジに基づいて一般ルールから拡張ルールを生成し、上述のように拡張ルールをルールリポジトリ１３１に保存する。
【００４０】
ステップ１２０１において、ルールローダープログラム１２２は、ルールリポジトリ１３１からルールを取得し、取得したルールを構文解析する。
【００４１】
ステップ１２０２において、ルールローダープログラム１２２は、ステップ１２０１で取得したルールのＩＦ部３１１から条件要素を取得する。
【００４２】
ステップ１２０３において、ルールローダープログラム１２２は、特定の条件要素に対応する条件オブジェクト４０１がルールメモリ１２１内に存在するか否かを調べる。
【００４３】
ステップ１２０４において、ルールローダープログラム１２２が対応する条件オブジェクト４０１を見つけられなかった場合、処理はステップ１２０５へ進む。一方、条件オブジェクト４０１が見つかった場合、処理はステップ１２０６へ進む。
【００４４】
条件オブジェクトが見つからなかった場合、ステップ１２０５において、ルールローダープログラム１２２は特定の条件要素のための条件オブジェクト４０１および演算子オブジェクト４０２をルールメモリ１２１内に生成し、次いで新たに生成された条件オブジェクト４０１と演算子オブジェクト４０２を互いに接続する。
【００４５】
ステップ１２０６において、ルールローダープログラム１２２は、ＩＦ部３１１内の全ての条件要素が処理されたか否かを調べる。全て処理済みならば、処理はステップ１２０７へ進み、さもなければ処理はステップ１２０２に戻る。
【００４６】
ステップ１２０７において、ルールローダープログラム１２２は、ステップ１２０１で選択されたルールのＴＨＥＮ部３１２から結論要素を取得する。
【００４７】
ステップ１２０８において、ルールローダープログラム１２２は、ルールメモリ１２１内に結論オブジェクト４０３を生成し、次いで生成された結論オブジェクト４０３と全ての関連する演算子オブジェクト４０２を接続する。
【００４８】
更に、２つ以上の結論要素をステップ１２０７で取得した（すなわち、特定のルールが上述のように２つ以上の結論を有する）場合、ルールローダープログラム１２２は対応する結論オブジェクト４０３をルールメモリ１２１内に生成し、次いで各々の生成された結論オブジェクト４０３と全ての関連する演算子オブジェクト４０２をステップ１２０８で接続する。
【００４９】
例えば、図４に示すように、ルール１の条件オブジェクト４０１は、４０１ａ、４０１ｂ、４０１ｃ、および４０１ｄである。これらの条件オブジェクト４０１ａ〜ｄは各々演算子オブジェクト４０２ａ〜４０２ｄに接続している。ルール１の結論オブジェクト４０３は４０３ａである。従って、接続４０３ａ〜４０２ａ〜４０１ａ、４０３ａ〜４０２ｂ〜４０１ｂ、４０３ａ〜４０２ｃ〜４０１ｃ、および４０３ａ〜４０２ｄ〜４０１ｄが、ルール１のために生成されなければならない。同様に、ルール２の条件オブジェクト４０１は、４０１ａ、４０１ｂ、４０１ｃ、および４０１ｅである。従って、条件オブジェクト４０１ａ、４０１ｂ、および４０１ｃは、ルール１のものと重なっている。この場合、結論オブジェクト４０３ａと結論オブジェクト４０３ｂは、対応する演算子オブジェクト４０２ａ〜ｃおよび条件オブジェクト４０１ａ〜ｃを共有する。
【００５０】
ステップ１２０９において、ルールローダープログラム１２２は、ルールリポジトリ１３１内の全てのルールファイルが処理されたか否かを調べる。全て処理済みならば処理を終了し、さもなければ処理はステップ１２０１に戻ってルールリポジトリ１３１内の次のルールを処理する。
【００５１】
イベント受信およびイベント書込の処理
図１３に、監視コンピュータ１０１内でイベント受信プログラム１２３およびイベント書込プログラム１２４により実行されるイベント受信およびイベント書込の処理例のフローチャートを示す。イベント受信プログラム１２３は、監視対象ノード２０２の１つからイベントメッセージを受信することにより処理を開始する。
【００５２】
ステップ１３０１において、イベント受信プログラム１２３は、監視対象ノード２０２からイベントメッセージ５０５を受信する。
【００５３】
ステップ１３０２において、イベント受信プログラム１２３は、このイベントメッセージ５０１を、ノード種別６０１、ノード名６０２、イベント種別６０３、および受信日時６０４を含む図６に示す情報と共にイベントキューテーブル１３２内の新規レコードに入れて、処理を終了する。
【００５４】
ステップ１３１１において、イベント書込プログラム１２４は、処理のためイベントキューテーブル１３２から１つのエントリを取得する。
【００５５】
ステップ１３１２において、イベント書込プログラム１２４は、ステップ１３１１で取得したエントリのノード種別６０１、ノード名６０２、およびイベント種別６０３を取得する。
【００５６】
ステップ１３１３において、イベント書込プログラム１２４は、ルールメモリ１２１内に同一ノード名およびイベント種別を有する条件オブジェクト４０１を決定する。
【００５７】
ステップ１３１４において、イベント書込プログラム１２４は、現在の日時をステップ１３１３で決定された条件オブジェクト４０１の「受信日時」属性に設定する。
【００５８】
ステップ１３１５において、イベント書込プログラム１２４は、ステップ１３１３で取得した条件オブジェクト４０１の「重み」属性に「１．０」を設定する。
【００５９】
ステップ１３１６において、イベント書込プログラム１２４は、ステップ１３１１でイベントキューテーブル１３２から取得したエントリのノード種別およびイベント種別を設定して、対応する有効期間７０３および減衰率７０４を決定することによりイベント消去設定テーブル１３３から対応するイベント消去設定を取得する。
【００６０】
ステップ１３１７において、イベント書込プログラム１２４は、イベント消去タスクテーブル１３４にタスクエントリを生成することにより、イベント消去設定テーブル１３３に指定された時刻にイベント消去プログラムがイベント消去タスクを実行できる。例えば、イベントキューテーブル１３２内の処理されるエントリが図６のエントリ６１１である場合、ノード種別はサーバであり、イベント種別はｉＳＣＳＩ通信エラーである。次に、ｉＳＣＳＩ通信エラーが生じているサーバについて、エントリ７１１においてイベント消去設定テーブル１３３を参照することにより、有効期間７０１は１０分であって、減衰率７０４は毎分０．３である。従って、本例においてステップ１３１７でイベント消去タスクテーブル１３４内に生成されたタスクエントリは、開始時刻８０１＝「現在の日時」＋１０分；ノード名８０２＝「サーバＡ」；イベント種別８０３＝「ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ」、および減衰率８０５＝０．３となろう。
【００６１】
ステップ１３１８において、イベント書込プログラム１２４は、マッチング率評価プログラム１２５を起動し、ステップ１３１３で決定された条件オブジェクト４０１をパラメータとして渡す。処理されるエントリが図６のエントリ６１１である上述の例では、パラメータは図４の条件オブジェクト４０１ａとなる。これに続いて、イベント書込プログラム１２４が処理を終了させる。
【００６２】
マッチング率評価の処理
図１４に、監視コンピュータ１０１内でマッチング率評価プログラム１２５により実行されるマッチング率評価を実行する処理例のフローチャートを示す。マッチング率評価プログラム１２５は、イベント書込プログラム１２３またはイベント消去プログラム１２７からの起動により処理を開始する。
【００６３】
ステップ１４０１において、マッチング率評価プログラム１２５は、イベント書込プログラム１２３またはイベント消去プログラム１２７により起動されると特定の条件オブジェクト４０１をパラメータとして受信する。
【００６４】
ステップ１４０２において、マッチング率評価プログラム１２５は、パラメータとして渡された特定の条件オブジェクト４０１に接続する演算子オブジェクト４０２を取得する。
【００６５】
ステップ１４０３において、マッチング率評価プログラム１２５は、ステップ１４０２で取りだされた特定の演算子オブジェクト４０２に接続する結論オブジェクト４０３を取得する。
【００６６】
ステップ１４０４において、マッチング率評価プログラム１２５は、特定の結論オブジェクト４０３から任意の演算子オブジェクト４０２まで、次いで任意の演算子オブジェクト４０２から他の任意の条件オブジェクト４０１まで接続を辿ることにより、ステップ１４０３で取得した特定の結論オブジェクト４０３と合わせて、全ての条件オブジェクト４０１を取得する。
【００６７】
ステップ１４０５において、マッチング率評価プログラム１２５は、特定された条件オブジェクト４０１の重み値の合計を計算する。例えば、図４に示す例において、結論オブジェクト４０３ａは演算子オブジェクト４０２ａ〜４０２ｄに接続している。演算子オブジェクト４０２ａ〜４０２ｄは各々条件オブジェクト４０１ａ〜４０１ｄに接続している。条件オブジェクト４０１ａ〜４０１ｄの各々は１．０の重み値を有し、従って本例で重みの合計は４．０に等しくなる。
【００６８】
ステップ１４０６において、マッチング率評価プログラム１２５は、公式「重みの合計／条件オブジェクトの数」に従いマッチング率（ＭＲ）の値を計算して、その結果を、対応する結論オブジェクト４０３のＭＲ属性に設定する。例えば、図４に示すように、結論オブジェクト４０３ａのＭＲは１．０（すなわち４．０／４）に等しくなる。
【００６９】
ステップ１４０７において、マッチング率評価プログラム１２５は、この演算子オブジェクト４０２に接続する全ての結論オブジェクト４０３が処理されたか否かを調べる。特定の演算子オブジェクト４０２に接続する全ての結論オブジェクト４０３が処理済みである場合、処理はステップ１４０８へ進み、さもなければ処理は次の結論オブジェクト４０３を処理すべくステップ１４０３に戻る。例えば、図４に示す例において、結論オブジェクト４０３ｂおよび４０３ｃもまた、演算子オブジェクト４０２ａに接続している。従って、結論オブジェクト４０３ｂおよび４０３ｃに対してもまた、それらの結論オブジェクトに関してマッチング率を決定すべくステップ１４０３〜１４０６が実行される。
【００７０】
ステップ１４０８において、マッチング率評価プログラム１２５は、元の条件オブジェクト４０１に接続する全ての演算子オブジェクト４０２が処理されたか否かを調べる。全て処理済みならば処理はステップ１４０９へ進み、さもなければ処理は次の演算子オブジェクト４０２を処理すべくステップ１４０２に戻る。例えば、図４に示す例では元の条件オブジェクト４０１ａに接続している追加的な演算子オブジェクト４０２が存在しない。
【００７１】
ステップ１４０９において、マッチング率評価プログラム１２５は、マッチング率がパラメータとして計算された結論オブジェクト４０３を渡すことによりマッチング率監視プログラム１２６を起動して、処理を終了させる。
【００７２】
マッチング率監視の処理
図１５に、監視コンピュータ１０１内でマッチング率監視プログラム１２６により実行されるマッチング率監視を実行する処理例のフローチャートを示す。マッチング率監視プログラム１２６は、当該処理をマッチング率評価プログラム１２５から起動することにより開始する。
【００７３】
ステップ１５０１において、マッチング率監視プログラム１２６は、マッチング率評価プログラム１２５からパラメータとして１つ以上の結論オブジェクト４０３を受信して、そのうち１つを処理すべく選択する。
【００７４】
ステップ１５０２において、マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５から１つのエントリを取得する。
【００７５】
ステップ１５０３において、マッチング率監視プログラム１２６は、選択された結論オブジェクト４０３のマッチング率（ＭＲ）がステップ１５０２で取得したエントリの条件を満たすか否かを調べる。条件を満たす場合、処理はステップ１５０４へ進み、さもなければ処理はステップ１５０５へ進む。
【００７６】
ステップ１５０４において、マッチング率監視プログラム１２６は、外部モジュール１２８を起動する。外部モジュール１２８の例として、管理者に通知を送って根本原因分析の結論として得られた結果を知らせ、後で分析すべくデータベースに根本原因分析の結論として得られた結果を保存するモジュールがある。
【００７７】
ステップ１５０５において、マッチング率監視プログラム１２６は、マッチング率監視設定テーブル１３５の全てのエントリが処理されたか否かを調べる。全て処理済みならば処理はステップ１５０６へ進み、さもなければ処理はマッチング率監視設定テーブル１３５の次のエントリを処理すべくステップ１５０２に戻る。
【００７８】
ステップ１５０６において、マッチング率監視プログラム１２６は、全ての結論オブジェクト４０３が処理されたか否かを調べる。全て処理済みならば処理を終了し、さもなければ処理は次の結論オブジェクト４０３を処理すべくステップ１５０１に戻る。
【００７９】
イベント消去の処理
図１６に、監視コンピュータ１０１内でイベント消去プログラム１２７により実行されるイベント消去を実行する処理例のフローチャートを示す。イベント消去プログラム１２７はこの処理を周期的に、例えば所定の間隔で開始する。
【００８０】
ステップ１６０１において、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４を参照して、開始時刻８０１が最も早い１つのタスクエントリを選択する。
【００８１】
ステップ１６０２において、イベント消去プログラム１２７は、当該タスクエントリの開始時刻８０１が現在の日時と同一であるか、または現在の日時より以前であるか否かを調べる。現在の日時と同一またはより以前である場合、処理はステップ１６０３へ進む。一方、イベント消去タスクテーブル１３４に現在の日時と同一またはより以前のエントリが存在しない場合、この時点および処理でイベントを消去する必要がない。
【００８２】
ステップ１６０３において、イベント消去プログラム１２７は、当該エントリのノード名８０２、イベント種別８０３、有効期間８０４、および減衰率８０５を取得する。
【００８３】
ステップ１６０４において、イベント消去プログラム１２７は、ルールメモリ１２１を参照して、ステップ１６０３で決定されたノード名８０２およびイベント種別８０３に対応する条件オブジェクト４０１を取得する。
【００８４】
ステップ１６０５において、イベント消去プログラム１２７は、ステップ１６０４で取得した条件オブジェクト４０１から重み値を取得して、取得した条件オブジェクト４０１の重み値を「重みマイナス減衰率」の結果に設定する。例えば、重み値が１．０に等しく、且つ減衰率が毎分０．３ポイントに等しい場合、条件オブジェクト４０１の新しい重み値は、次の１分間にわたり行なわれたどのマッチング率計算についても０．７に等しくなる。重み値は１分経過後に、これに続く１分間に計算されるマッチング率のために再び０．３ポイント下げられて０．４になる。
【００８５】
ステップ１６０６において、イベント消去プログラム１２７は、重み値がゼロ以下であるか否かを調べる。ゼロ以下ならば処理はステップ１６０８へ進み、さもなければ処理はステップ１６０７へ進む。
【００８６】
ステップ１６０７において、重み値が依然としてゼロより大きいため、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４の当該タスクエントリの開始時刻８０１を「開始時刻８０１＋１分」に更新する。
【００８７】
一方、ステップ１６０８において、重み値がゼロ以下である場合、イベント消去プログラム１２７は、選択された条件オブジェクト４０１の重み属性を０．０に等しく設定する。
【００８８】
ステップ１６０９において、イベント消去プログラム１２７は、イベント消去タスクテーブル１３４から特定のタスクエントリを削除する。
【００８９】
ステップ１６１０において、イベント消去プログラム１２７は、全ての結論オブジェクト４０３をパラメータとして渡すことによりマッチング率評価プログラム１２５を起動する。従って、イベント消去プログラム１２７が減衰率に応じて条件オブジェクト４０１の重み値を徐々に下げて行くことにより、対応する結論オブジェクト４０３のマッチング率を下げることがわかる。
【００９０】
上の開示から明らかなように、本発明の例示的な実施形態では分析エンジンが増加分または減少分のイベントを処理するため、根本原因分析の実行に必要な計算コストを減らすことができる。例えば、分析エンジンは、たとえ１つ以上の条件要素が真でないと判定されたとしても最も可能性の高い結論を決定できる。これは、たとえルールを真にするために必要な１つ以上のイベントが分析エンジンに通知されなかったとしても分析エンジンがルールのマッチング率を計算できるためである。更に、イベントの有効期間を設定し、且つ減衰により段階的な削除を行なうことにより、分析精度を向上させることができる。従って、本発明の実施形態は、根本原因分析の精度を向上させると共に計算コストを減らす。例えば、本発明によれば、計算コストを減らすべく、増加分および減少分の根本原因分析に用いられるイベントを追加および削除することが可能である。
【００９１】
根本原因分析の計算コストを減らすべく、本発明の実施形態はオブジェクトモデルを構築する分析エンジンを含む。このオブジェクトモデルは、重複除外の概念に基づいていてよい。拡張ルールの中で反復する条件要素がいくつかある。例えば、条件要素＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞がルール１、ルール２およびルール３に出現する場合、オブジェクトモデルにおいて＜ＳｅｒｖｅｒＡ ｉＳＣＳＩ＿Ｃｏｍｍ＿Ｅｒｒ＞に対応する条件オブジェクトの数は１である。イベントが受信されると、分析エンジンは対応する条件オブジェクトの状態を更新することができる。更に、この状態変化は、各々の関連するルールオブジェクトへの接続を介して伝播する。このオブジェクトモデルによれば、分析エンジンは、受信されたイベントに関係しないオブジェクトにアクセスする必要がない。従って、分析エンジンに伴う計算コストが減少する。
【００９２】
更に、例示的な実施形態において、分析エンジンは２つ以上のイベントから原因を分析することができる。分析エンジンが１つのイベントを受信する都度、増加分の分析処理を実行する。昨日生起したような古いイベントを現在のイベントと同一の分析に含めることで誤った結論が導かれる恐れがあるため、分析エンジンは所定のタイミングで古いイベントを削除することができる。例示的な実施形態において、古くなったイベントを削除するために、分析エンジンは、条件オブジェクトの状態を変更して、削除されたイベントに関係していて影響を受けるルールだけを再計算することにより、各ルールのマッチング率を再計算する。
【００９３】
また、図１６に関して上述したように、本発明の実施形態はイベント消去コンポーネントを含み、所定の時間（有効期間）および予定される削除タスクに基づいてイベントを削除する。本発明の例示的な実施形態において、イベントの有効期間はイベントの種別に基づいてよいため、分析の精度を向上させることができる。例えば、イベントの発生元がネットワークスイッチまたはストレージ等の共用リソースである場合、共用リソースは他の多くの原始リソースと関係するため、イベントの有効期間は長くなる筈である。一方、各種のコンピュータノードに最適な有効期間は、使用環境に応じて変動し得る。従って、イベント種別および／またはリソースタイプに応じて有効期間を規定する本発明のイベント消去設定テーブル１３３が、各イベント種別に最適な有効期間を可能にすべく提供される。
【００９４】
上述のように、本発明の分析エンジンは２つ以上のイベントから原因を分析することができるが、昨日のイベントを現在のイベントと同一の分析に含めることは誤った結論を導く恐れがあるため、分析エンジンは何らかのタイミングで古いイベントを削除する必要がある。しかし、先行イベントが現在のイベントに関係している可能性もあるため、本発明の実施形態は、減衰率を設定することにより、ルールメモリ内にイベント状態をオールオアナッシング、すなわち１．０か０．０か（存在するか存在しないか）とは別の何らかの方法で表すことに利点があることを考慮に入れている。従って、この実装により、ルールメモリ内のイベントが段階的に消滅すると共に、重要度も段階的に下げられる。従って、減衰率を含めることにより、たとえイベントの影響が小さくても、分析エンジンは当該イベントを分析オブジェクトに含めることができる。また、イベントの影響が小さいため、当該イベントは他のルールの評価に悪影響を及ぼさず、従って、分析エンジンは実際の現実世界の状態に基づいて根本原因を特定できる。
【００９５】
上述のように、分析エンジンが根本原因を計算し終えた際に、ディスプレイ１１７上で結果を管理者に提示することができる。追加または代替的に、計算された原因およびマッチしている率を含む結果を、後で分析すべくデータベースに保存できる。更に、分析エンジンは、特定のルールを満たすために必要な条件のうちどの条件が満たされていないかを判定することができ、これらの条件を管理者に提示したり、あるいはこの情報をデータベース等に保存したりできる。例えば、分析エンジンは、計算された生起原因および特定のルールを満たすために必要な条件のうち満たされなかった条件を管理者に見せるためにディスプレイに表示できる上に、また追加または代替的に、原因、計算されたマッチング率、および特定のルールを満たすために必要な条件のうち満たされなかった条件を、後で分析すべくデータベースに保存できる。また、上述の減衰方法を用いるのではなく、タイマーまたは管理者の手操作により１つ以上のイベントを無効にできるように分析エンジンを構成できる。
【００９６】
無論、図１および２に示すシステム構成は単に本発明を実装することが可能な情報システムの例に過ぎず、本発明は特定のハードウェアまたは論理構成に限定されない。本発明を実装するコンピュータおよびストレージシステムはまた、上述の発明の実装に用いるモジュール、プログラム、およびデータ構造の保存および読み出しが可能な公知の入出力装置（例：ＣＤおよびＤＶＤドライブ、フロッピーディスクドライブ、ハードディスクドライブ等）を備えていてよい。これらのモジュール、プログラム、およびデータ構造はそのようなコンピュータ可読媒体上で符号化されていてよい。例えば、本発明のデータ構造は、本発明で使用するプログラムが常駐する１つ以上のコンピュータ可読媒体とは独立に、コンピュータ可読媒体に保存されていてよい。本システムの構成要素は、任意の形式または媒体のデジタルデータ通信、例えば通信回路ネットワーク、により相互接続されていてよい。通信回路ネットワークの例として、ローカルエリアネットワーク、ワイドエリアネットワーク、例：インターネット、無線ネットワーク、ストレージエリアネットワーク等が含まれる。
【００９７】
上の記述において、本発明の完全な理解を得るべく、説明目的で多くの詳細事項を開示している。しかし、当業者には明らかなように、本発明を実施するためにこれらの具体的な詳細事項の全てが必要な訳ではない。また、本発明が多くの場合フローチャート、フロー図、構造図、またはブロック図として表された処理として記述できる点に注意されたい。フローチャートは動作を逐次的な処理として記述できるが、多くの動作が並行してまたは同時に実行できる。また、動作の順序を並べ替えてもよい。
【００９８】
当該技術分野で公知のように、上述の動作はハードウェア、ソフトウェア、またはソフトウェアとハードウェアの何らかの組合せにより実行できる。本発明の実施形態の各種の態様は、回路および論理装置（ハードウェア）を用いて実装できるが、プロセッサにより実行された場合に本発明の実施形態を実行する方法をプロセッサに実行させる機械可読媒体（ソフトウェア）に保存された命令を用いて他の態様を実装できる。更に、本発明のいくつかの実施形態はハードウェアだけで実行できるのに対し、他の実施形態はソフトウェアだけで実行できる。更に、本明細書に記載する各種の機能は、単一のユニットで実行することも、あるいは多くの構成要素にまたがって何通りもの仕方で実行することもできる。ソフトウェアで実行する場合、本方法はコンピュータ可読媒体に保存された命令に基づいて汎用コンピュータ等のプロセッサにより実行できる。必要ならば、命令は圧縮および／または暗号化形式で媒体に保存できる。
【００９９】
上の記述から、本発明が、根本原因分析の精度を向上させると共に計算コストを減らす方法、装置、およびコンピュータ可読媒体に保存されたプログラムを提供することは明らかであろう。また、本明細書で特定の実施形態を例示および記述しているが、当業者には開示された特定の実施形態を同じ目的を達成すべく計算された任意の構成で置換できることが理解されよう。本開示は、本発明の任意のおよびあらゆる適用または変型を包含することを目的としており、以下の請求項で使用する用語は、本発明を本明細書で開示した特定の実施形態に限定するものと解釈してはならない。むしろ、本発明の範囲は以下の請求項により完全に定義され、そのような請求項の等価物の全範囲と合わせて、請求項解釈の確立された原則に従って解釈されるべきである。
【特許請求の範囲】
【請求項１】
複数の監視対象ノードからなる情報システムにおける事象の原因を特定する方法であって、
各々が特定の事象の特定の原因を示すために満たすべき１つ以上の条件を明記している複数のルールを保存するステップと、
前記ノードの１つに関係する第１のイベントに関する第１のイベントメッセージを受信するステップと、
前記第１のイベントに有効期間を割り当てるステップと、
前記ルールのいずれが前記第１のイベントに対応する条件を有するかを判定するステップと、
前記第１のイベントに対応する条件を有する任意のルールに対してマッチング率を計算するステップと、
条件のマッチング状態を保存するステップと、
前記ルールの計算されたマッチング率に基づいて前記事象の原因を指定するステップと
を含む方法。
【請求項２】
前記有効期間が最終満了時点に達すると、前記第１のイベントを無効にするステップ、
を更に含む、請求項１に記載の方法。
【請求項３】
前記第１のイベントメッセージを受信する前に、複数の先行イベントに関する複数の先行イベントメッセージを受信するステップ、
を更に含み、
前記先行イベントの各々には先行有効期間が割り当てられていて、
前記マッチング率を計算するステップは、前記先行イベントが前記第１のイベントと同一のルール内の条件に対応する場合に、前記マッチング率の計算に前記先行イベントを含めることにより実行される、
請求項２に記載の方法。
【請求項４】
前記マッチング率を計算するステップに続いて、且つ前記第１のイベントに関して２つ以上のルールのマッチング率が計算されると、前記２つ以上のルールの計算されたマッチング率の中で、最高の計算されたマッチング率を有するルールから導かれた結論に基づいて、前記事象の原因を識別するステップ、
を更に含む、請求項１に記載の方法。
【請求項５】
前記マッチング率が、
特定のルールの条件に対応し且つ有効期間が最終的に満了していないイベントの数と、
前記特定のルールを満たすために必要な条件の総数と
の関数として計算され、
前記計算されたマッチング率が、前記特定のルールの結論が前記事象の原因を識別する確率を示す、
請求項１に記載の方法。
【請求項６】
第１のディスプレイを有し、情報システム内の複数の監視対象ノードとネットワークを介して通信状態にある第１のコンピュータと、
前記第１のコンピュータからアクセス可能であって、各々が前記監視対象ノードの１つ以上において事象が生起した場合に原因を示すために満たすべき１つ以上の条件を明記している複数のルールと
を含む情報システムであって、
前記第１のコンピュータが、１つ以上の前記監視対象ノードにおける事象に関係するイベントに関するイベントメッセージを受信して、各イベントに有効期間を割り当てるべく構成され、
前記第１のコンピュータが、前記ルールのいずれが前記イベントに対応する条件を有するかを判定し、受信したイベントに対応する条件を有する任意のルールに対してマッチング率を計算して、条件のマッチング状態を保存すべく構成され、
前記第１のコンピュータが、前記ルールの計算されたマッチング率に基づいて前記事象の原因を特定すべく構成される
情報システム。
【請求項７】
前記第１のコンピュータが、前記有効期間が最終満了時点に達すると前記第１のイベントを無効にすべく構成される、
請求項６に記載のシステム。
【請求項８】
前記第１のコンピュータが、前記第１のイベントメッセージを受信する前に、先行イベントの各々に先行有効期間が割り当てられている複数の先行イベントに関する複数の先行イベントメッセージを受信すると、第１のコンピュータが、前記先行イベントが前記第１のイベントと同一のルール内の条件に対応する場合に、前記マッチング率の計算に前記先行イベントを含めることにより、前記マッチング率を計算すべく構成される、
請求項７に記載のシステム。
【請求項９】
前記先行イベントの特定の１つの特定の先行有効期間が第１の満了時点に達すると、第１のコンピュータが、マッチング率計算で用いる重み値に減衰値を割り当てるべく構成され、前記特定のイベントに関わる前記マッチング率計算において前記特定の先行イベントの重要性が前記最終満了時点に達するまで段階的に低下することにより、前記イベントがもはや前記マッチング率計算に含まれず、前記システムが更に、
前記第１のコンピュータからアクセス可能である保存された減衰設定情報を含み、前記第１のコンピュータが、異なる種別のイベントまたは異なる種別のノードが所定の異なる減衰値を有するように、イベントの種別または前記イベントに関連付けられたノードの種別に基づいて減衰値を設定すべく構成される、
請求項８に記載のシステム。
【請求項１０】
２つ以上のルールのマッチング率が前記第１のイベントに関して計算される場合、前記第１のコンピュータが、前記２つ以上のルールの計算されたマッチング率の中で、最高の計算されたマッチング率を有するルールから導かれた結論に基づいて、前記事象の原因を識別すべく構成される、
請求項６に記載のシステム。
【請求項１１】
前記第１のコンピュータからアクセス可能である保存された有効期間設定情報を更に含み、前記第１のコンピュータが、異なる種別のイベントまたは異なる種別のノードが所定の異なる有効期間長を有するように、イベントの種別またはイベントに関連付けられたノードの種別に基づいて有効期間の長さを設定すべく構成される、
請求項６に記載のシステム。
【請求項１２】
前記第１のコンピュータが、前記マッチング率を、
特定のルールの条件に対応し且つ有効期間が最終的に満了していないイベントの数と、
前記特定のルールを満たすために必要な条件の総数と
の関数として計算すべく構成され、
前記計算されたマッチング率が、前記特定のルールの結論が前記事象の原因を識別する確率を示す、
請求項６に記載のシステム。
【請求項１３】
前記第１のコンピュータが、特定のルールを満たすために必要な条件のうちどの条件が満たされていないかを判定すべく構成される、
請求項６に記載のシステム。
【請求項１４】
複数の監視対象ノードからなる情報システムにおける事象の原因を特定する方法であって、
各々が１つ以上の条件および１つの結論を明記している複数のルールを保存するステップと、
前記ルールおよび前記情報システムの監視対象部分のトポロジに基づいて拡張ルールを生成して、前記拡張ルールの各条件が、前記情報システムの前記監視対象部分で生起し得るイベントに対応させるステップと、
メモリ内で条件オブジェクトが反復しないように複数の前記拡張ルールの複数の条件をインスタンス化するステップと、
前記メモリ内に結論オブジェクトとして複数の前記拡張ルールの複数の結論をインスタンス化するステップと、
前記拡張ルールの構造に基づいて、複数の前記条件オブジェクトに前記メモリ内の複数の前記結論オブジェクトを関連付けるステップと、
１つ以上の条件オブジェクトの充足に影響を及ぼすイベントが生起した場合に１つ以上の前記条件オブジェクトを有効または無効にすることにより前記事象の原因を特定する処理を実行するステップと
を含む方法。
【請求項１５】
ネットワークを介して情報システム内の複数の監視対象ノードと通信状態にある第１のコンピュータと、
前記第１のコンピュータからアクセス可能であって、各々が１つ以上の条件および１つの結論を明記している複数のルールと
を含む情報システムであって、
前記第１のコンピュータが、前記ルールおよび前記情報システムの監視対象部分のトポロジに基づいて拡張ルールを生成して、前記拡張ルールの各条件が前記情報システムの前記監視対象部分で生起し得るイベントに対応させるべく構成され、
前記第１のコンピュータが、メモリ内で条件オブジェクトが反復しないように複数の前記拡張ルールの複数の条件をインスタンス化すべく構成され、
前記第１のコンピュータが、前記メモリ内に結論オブジェクトとして複数の前記拡張ルールの複数の結論をインスタンス化すべく構成され、
前記第１のコンピュータが、前記拡張ルールの構造に基づいて、複数の前記条件オブジェクトに前記メモリ内の複数の前記結論オブジェクトを関連付けるべく構成され、
前記第１のコンピュータが、１つ以上の条件オブジェクトの充足に影響を及ぼすイベントが生起した場合に、１つ以上の前記条件オブジェクトを有効または無効にすることにより前記事象の原因を特定する処理を実行すべく構成される
情報システム。
【請求項１】
複数の監視対象ノードからなる情報システムにおける事象の原因を特定する方法であって、
各々が特定の事象の特定の原因を示すために満たすべき１つ以上の条件を明記している複数のルールを保存するステップと、
前記ノードの１つに関係する第１のイベントに関する第１のイベントメッセージを受信するステップと、
前記第１のイベントに有効期間を割り当てるステップと、
前記ルールのいずれが前記第１のイベントに対応する条件を有するかを判定するステップと、
前記第１のイベントに対応する条件を有する任意のルールに対してマッチング率を計算するステップと、
条件のマッチング状態を保存するステップと、
前記ルールの計算されたマッチング率に基づいて前記事象の原因を指定するステップと
を含む方法。
【請求項２】
前記有効期間が最終満了時点に達すると、前記第１のイベントを無効にするステップ、
を更に含む、請求項１に記載の方法。
【請求項３】
前記第１のイベントメッセージを受信する前に、複数の先行イベントに関する複数の先行イベントメッセージを受信するステップ、
を更に含み、
前記先行イベントの各々には先行有効期間が割り当てられていて、
前記マッチング率を計算するステップは、前記先行イベントが前記第１のイベントと同一のルール内の条件に対応する場合に、前記マッチング率の計算に前記先行イベントを含めることにより実行される、
請求項２に記載の方法。
【請求項４】
前記マッチング率を計算するステップに続いて、且つ前記第１のイベントに関して２つ以上のルールのマッチング率が計算されると、前記２つ以上のルールの計算されたマッチング率の中で、最高の計算されたマッチング率を有するルールから導かれた結論に基づいて、前記事象の原因を識別するステップ、
を更に含む、請求項１に記載の方法。
【請求項５】
前記マッチング率が、
特定のルールの条件に対応し且つ有効期間が最終的に満了していないイベントの数と、
前記特定のルールを満たすために必要な条件の総数と
の関数として計算され、
前記計算されたマッチング率が、前記特定のルールの結論が前記事象の原因を識別する確率を示す、
請求項１に記載の方法。
【請求項６】
第１のディスプレイを有し、情報システム内の複数の監視対象ノードとネットワークを介して通信状態にある第１のコンピュータと、
前記第１のコンピュータからアクセス可能であって、各々が前記監視対象ノードの１つ以上において事象が生起した場合に原因を示すために満たすべき１つ以上の条件を明記している複数のルールと
を含む情報システムであって、
前記第１のコンピュータが、１つ以上の前記監視対象ノードにおける事象に関係するイベントに関するイベントメッセージを受信して、各イベントに有効期間を割り当てるべく構成され、
前記第１のコンピュータが、前記ルールのいずれが前記イベントに対応する条件を有するかを判定し、受信したイベントに対応する条件を有する任意のルールに対してマッチング率を計算して、条件のマッチング状態を保存すべく構成され、
前記第１のコンピュータが、前記ルールの計算されたマッチング率に基づいて前記事象の原因を特定すべく構成される
情報システム。
【請求項７】
前記第１のコンピュータが、前記有効期間が最終満了時点に達すると前記第１のイベントを無効にすべく構成される、
請求項６に記載のシステム。
【請求項８】
前記第１のコンピュータが、前記第１のイベントメッセージを受信する前に、先行イベントの各々に先行有効期間が割り当てられている複数の先行イベントに関する複数の先行イベントメッセージを受信すると、第１のコンピュータが、前記先行イベントが前記第１のイベントと同一のルール内の条件に対応する場合に、前記マッチング率の計算に前記先行イベントを含めることにより、前記マッチング率を計算すべく構成される、
請求項７に記載のシステム。
【請求項９】
前記先行イベントの特定の１つの特定の先行有効期間が第１の満了時点に達すると、第１のコンピュータが、マッチング率計算で用いる重み値に減衰値を割り当てるべく構成され、前記特定のイベントに関わる前記マッチング率計算において前記特定の先行イベントの重要性が前記最終満了時点に達するまで段階的に低下することにより、前記イベントがもはや前記マッチング率計算に含まれず、前記システムが更に、
前記第１のコンピュータからアクセス可能である保存された減衰設定情報を含み、前記第１のコンピュータが、異なる種別のイベントまたは異なる種別のノードが所定の異なる減衰値を有するように、イベントの種別または前記イベントに関連付けられたノードの種別に基づいて減衰値を設定すべく構成される、
請求項８に記載のシステム。
【請求項１０】
２つ以上のルールのマッチング率が前記第１のイベントに関して計算される場合、前記第１のコンピュータが、前記２つ以上のルールの計算されたマッチング率の中で、最高の計算されたマッチング率を有するルールから導かれた結論に基づいて、前記事象の原因を識別すべく構成される、
請求項６に記載のシステム。
【請求項１１】
前記第１のコンピュータからアクセス可能である保存された有効期間設定情報を更に含み、前記第１のコンピュータが、異なる種別のイベントまたは異なる種別のノードが所定の異なる有効期間長を有するように、イベントの種別またはイベントに関連付けられたノードの種別に基づいて有効期間の長さを設定すべく構成される、
請求項６に記載のシステム。
【請求項１２】
前記第１のコンピュータが、前記マッチング率を、
特定のルールの条件に対応し且つ有効期間が最終的に満了していないイベントの数と、
前記特定のルールを満たすために必要な条件の総数と
の関数として計算すべく構成され、
前記計算されたマッチング率が、前記特定のルールの結論が前記事象の原因を識別する確率を示す、
請求項６に記載のシステム。
【請求項１３】
前記第１のコンピュータが、特定のルールを満たすために必要な条件のうちどの条件が満たされていないかを判定すべく構成される、
請求項６に記載のシステム。
【請求項１４】
複数の監視対象ノードからなる情報システムにおける事象の原因を特定する方法であって、
各々が１つ以上の条件および１つの結論を明記している複数のルールを保存するステップと、
前記ルールおよび前記情報システムの監視対象部分のトポロジに基づいて拡張ルールを生成して、前記拡張ルールの各条件が、前記情報システムの前記監視対象部分で生起し得るイベントに対応させるステップと、
メモリ内で条件オブジェクトが反復しないように複数の前記拡張ルールの複数の条件をインスタンス化するステップと、
前記メモリ内に結論オブジェクトとして複数の前記拡張ルールの複数の結論をインスタンス化するステップと、
前記拡張ルールの構造に基づいて、複数の前記条件オブジェクトに前記メモリ内の複数の前記結論オブジェクトを関連付けるステップと、
１つ以上の条件オブジェクトの充足に影響を及ぼすイベントが生起した場合に１つ以上の前記条件オブジェクトを有効または無効にすることにより前記事象の原因を特定する処理を実行するステップと
を含む方法。
【請求項１５】
ネットワークを介して情報システム内の複数の監視対象ノードと通信状態にある第１のコンピュータと、
前記第１のコンピュータからアクセス可能であって、各々が１つ以上の条件および１つの結論を明記している複数のルールと
を含む情報システムであって、
前記第１のコンピュータが、前記ルールおよび前記情報システムの監視対象部分のトポロジに基づいて拡張ルールを生成して、前記拡張ルールの各条件が前記情報システムの前記監視対象部分で生起し得るイベントに対応させるべく構成され、
前記第１のコンピュータが、メモリ内で条件オブジェクトが反復しないように複数の前記拡張ルールの複数の条件をインスタンス化すべく構成され、
前記第１のコンピュータが、前記メモリ内に結論オブジェクトとして複数の前記拡張ルールの複数の結論をインスタンス化すべく構成され、
前記第１のコンピュータが、前記拡張ルールの構造に基づいて、複数の前記条件オブジェクトに前記メモリ内の複数の前記結論オブジェクトを関連付けるべく構成され、
前記第１のコンピュータが、１つ以上の条件オブジェクトの充足に影響を及ぼすイベントが生起した場合に、１つ以上の前記条件オブジェクトを有効または無効にすることにより前記事象の原因を特定する処理を実行すべく構成される
情報システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１２−２５６３５５（Ｐ２０１２−２５６３５５Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１８０１５６（Ｐ２０１２−１８０１５６）
【出願日】平成２４年８月１５日（２０１２．８．１５）
【分割の表示】特願２０１０−５３１３５８（Ｐ２０１０−５３１３５８）の分割
【原出願日】平成２１年２月１６日（２００９．２．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１２−１８０１５６（Ｐ２０１２−１８０１５６）
【出願日】平成２４年８月１５日（２０１２．８．１５）
【分割の表示】特願２０１０−５３１３５８（Ｐ２０１０−５３１３５８）の分割
【原出願日】平成２１年２月１６日（２００９．２．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]