管理装置及び管理方法
【課題】
一定サイズのワーキングメモリにて、効率良く解析処理を実行し得る管理装置及び管理方法を提案する。
【解決手段】
予め定義された１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られたルールセグメントを２次記憶装置に保存し、情報処理装置からのイベント通知を受信したときに、関連する１又は複数のルールセグメントを選択し、選択した１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除するようにした。
一定サイズのワーキングメモリにて、効率良く解析処理を実行し得る管理装置及び管理方法を提案する。
【解決手段】
予め定義された１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られたルールセグメントを２次記憶装置に保存し、情報処理装置からのイベント通知を受信したときに、関連する１又は複数のルールセグメントを選択し、選択した１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除するようにした。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置及び管理方法に関し、例えば情報処理装置から送信される障害内容を表すイベント通知を用いて障害箇所及び原因を解析する障害解析機能が搭載された管理サーバに適用して好適なものである。
【背景技術】
【０００２】
近年、計算機システムは、計算機ネットワーク（以下、これを単にネットワークと呼ぶ）を介して様々な情報処理装置を相互に接続することで複雑化・大規模化してきている。これに伴いいずれかの情報処理装置に発生した障害がネットワークを介して様々な情報処理装置に影響を与えるようになってきた。
【０００３】
従来、このような障害の箇所と原因を特定する根本原因解析技術として、情報処理装置から送信される障害内容を表すイベントを用いて障害箇所及び原因を解析するイベント・コリレーション技術がある（例えば、特許文献１）。イベント・コリレーション技術は、障害時に管理サーバに上げられるイベントの相関を利用して根本原因を推測するもので、古くからネットワークシステムの障害の診断に用いられている技術である。
【０００４】
また、非特許文献１には、当該技術と障害時のイベントの組み合わせと推測される根本原因を対にしてルール化することで、エキスパートシステムをベースとした推論エンジンを用いて根本原因を迅速に突き止める技術が開示されている。
【０００５】
このエキスパートシステムをベースとするイベント・コリレーションにおいては、障害解析の対象とするＩＴシステムの規模が多くなったり、ルールが多くなったりすると、特許文献２における推論エンジンのパターンマッチングに用いるルール間の関係を接続したルール解析網に必要となるワーキングメモリのサイズが大きくなる。このルール解析網の一つとして、コードブックと呼ばれる、障害時にあげられるイベントと考えられる根本原因の関係をマトリックスと呼ばれる行列形式に表し、このマトリックスを最適化して分割・最小化する技術が特許文献２にて開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第６２４９７５５号
【特許文献２】米国特許第６８６８３６７号
【非特許文献】
【０００７】
【非特許文献１】“Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”，ARTIFICIAL INTELLIGENCE，Vol．19，no．1，1982，pp．17-37
【発明の概要】
【発明が解決しようとする課題】
【０００８】
イベント・コリレーション技術は、障害時に障害が発生した装置から管理サーバに通知されるイベントの組み合わせパターンから障害の原因候補を絞り込む有効な技術であるが、組み合わせるべきイベントの数及び根本原因の数が多くなると、これらの組み合わせパターンが膨大となり、実際に発生したイベント群と、ルールとして定義されたイベントとの組み合わせのパターンマッチングを行うための検索空間が膨大なものとなる。この結果、解析結果を導くのに時間を要してしまうだけでなく、検索空間が膨大になることに起因してプロセッサが解析の実行時に参照するメモリ（ワーキングメモリ）のサイズが肥大化する問題があった。
【０００９】
このような問題に対して、例えば特許文献２には、イベントの組み合わせと根本原因との関係をマトリックス表にし、このマトリックス表を最適化して小さくすることが開示されている。しかしながら、かかる最適化は定義イベントの数やルールの数に対するマトリックス表の肥大化に対する解決策ではなく、イベントの組み合わせと根本原因との冗長な関係を省くものであり、最適化の対象が異なる。また、ルール解析網の構造、対象システムの規模、すなわち取り扱うイベントの数やルールの数に、解析処理時のワーキングメモリのサイズが依存しないことが望ましい。
【００１０】
本発明は以上の点を考慮してなされたもので、対象システムの定義イベントの数やルールの数によらず、一定のワーキングメモリサイズを保ちながら、少ない解析時間で解析処理を実行し得る管理装置及び管理方法を提案しようとするものである。
【課題を解決するための手段】
【００１１】
かかる課題を解決するため本発明においては、１又は複数の情報処理装置を管理する管理装置において、前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する２次記憶装置と、前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信するネットワークインタフェースと、前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断するプロセッサと、前記プロセッサのワークメモリとして利用されるメモリとを有し、前記プロセッサは、予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除することを特徴とする。
【００１２】
また本発明においては、１又は複数の情報処理装置を管理する管理方法において、前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する第１のステップと、前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信する第２のステップと、前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断する第３のステップとを有し、前記第１のステップでは、予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、前記第３のステップでは、前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、障害解析を行う対象の情報処理システムの装置・構成要素が大規模化したり、取り扱うルールの数が増えたりした場合においても、受信したイベントと事前に定義されたルールの条件に示されたイベントとの組み合わせのパターンマッチングにもとづく解析処理の実行において、一定サイズのワーキングメモリにて、効率良く実現できる。
【図面の簡単な説明】
【００１４】
【図１】図１は、本実施の形態による情報処理システムの全体構成を模式的に示すブロック図である。
【図２】図２は、管理対象装置群の構成例を示すブロック図である。
【図３】図３は、イベント通知の構成例を示す概念図である。
【図４】図４は、ルール情報の構成例を示す概念図である。
【図５】図５は、ルール情報の具体的な構成例を示す概念図である。
【図６】図６は、ルール情報の具体的な構成例を示す概念図である。
【図７】図７は、ルール解析網の一部構成例を示す概念図である。
【図８】図８は、イベントオブジェクトの構成例を示す概念図である。
【図９】図９は、条件オブジェクトの構成例を示す概念図である。
【図１０】図１０は、ルールオブジェクトの構成例を示す概念図である。
【図１１】図１１は、結論オブジェクトの構成例を示す概念図である。
【図１２】図１２は、ルールセグメントの構成例を示す概念図である。
【図１３】図１３は、本実施の形態による条件オブジェクトの構成例を示す概念図である。
【図１４】図１４は、イベント索引情報の説明に供する概念図である。
【図１５】図１５は、イベント索引情報の構成例を示す概念図である。
【図１６】図１６は、セグメント参照情報の構成例を示す概念図である。
【図１７】図１７は、セグメント結合情報の構成例を示す概念図である。
【図１８】図１８は、セグメント参照履歴情報の構成例を示す概念図である。
【図１９】障害原因解析処理の処理手順を示すフローチャートである。
【図２０】前処理の処理手順を示すフローチャートである。
【図２１】第１の関連情報テーブルの構成例を示す概念図である。
【図２２】第２の関連情報テーブルの構成例を示す概念図である。
【図２３】関連情報テーブル作成処理の処理手順を示すフローチャートである。
【図２４】ルール実行リスト作成処理の処理手順を示すフローチャートである。
【図２５】ルール情報依存関係管理テーブルの構成例を示す概念図である。
【図２６】ルール情報依存関係管理テーブル作成処理の処理手順を示すフローチャートである。
【図２７】ルールセグメント等作成処理の処理手順を示すフローチャートである。
【図２８】解析処理の処理手順を示すフローチャートである。
【図２９】ルールセグメントの状態遷移の説明に供する概念図である。
【発明を実施するための最良の形態】
【００１５】
以下図面について、本発明の一実施の形態を詳述する。
【００１６】
なお、以下においては、例えばサーバ装置、ストレージサブシステム、プリンタ、スキャナ、パソコン、ＰＤＡ及び又は携帯電話などのネットワーク通信を行う通信機能が搭載された装置と、ルータ、プロキシーサーバ及び又はスイッチなどのネットワーク通信を中継する機能が搭載された装置とを包括的に情報処理装置と呼ぶものとする。またサーバ装置としては、例えばＷｅｂサーバ、ファイルサーバ、ネームサーバ、ディレクトリサーバ又は認証サーバ等が考えられるが、何らかのサービスを提供する装置であればすべて本明細書におけるサーバ装置に含まれる。
【００１７】
また以下においては、「ＡＡＡテーブル」、「ＡＡＡリスト」、「ＡＡＡＤＢ」又は「ＡＡＡキュー」等の表現にて各種情報を説明するが、これら情報はテーブル、リスト、ＤＢ又はキュー等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ＡＡＡテーブル」、「ＡＡＡリスト」、「ＡＡＡＤＢ」及び「ＡＡＡキュー」等を「ＡＡＡ情報」と呼ぶことがある。
【００１８】
また各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」及び「番号」という表現を用いるが、これらの表現は装置や部品などの物理的な存在に限らず、論理的な存在についても区別をつけるために割り当てられているものであるため、お互いに置換が可能である。
【００１９】
さらに以下においては、各種処理の処理主体を「プログラム」として説明するが、実際上は、そのプログラムに基づいてその処理をプロセッサが実行することは言うまでもない。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。さらにプログラムの一部または全ては専用ハードウェアによって実現されてもよい。さらに各種プログラムは、プログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００２０】
（１）本実施の形態による情報処理システムの構成
図１において、１は全体として本実施の形態による情報処理システムを示す。図中『」』のマークは、対応部位が複数存在することを意味する。情報処理システム１は、管理サーバ２と、１又は複数の情報処理装置４からなる管理対象装置群３とを備えて構成される。
【００２１】
管理サーバ２は、管理対象装置群３を構成する各情報処理装置４を管理及び監視するサーバ装置であり、プログラム及び制御情報などの電子データを記憶するための記憶領域を提供するメモリ１０と、メモリ１０の記憶容量の不足を補助するための２次記憶装置１１と、メモリ１０上に存在する電子データを用いて管理対象装置群３において発生した障害の解析処理を行うプロセッサ１２と、管理対象装置群３と管理用ネットワーク５を介して電子データの送受信を行うためのネットワークインタフェース１３（以下、インタフェースはＩ／Ｆと略す場合がある）とを備えて構成される。
【００２２】
メモリ１０は、例えば半導体メモリ、又は磁気を用いてデータを格納する磁気メモリから構成され、各種プログラム及び各種制御情報を保持するために用いられる。後述する部分ルール解析網２０、イベント索引情報２１、管理プログラム２２及びイベントキュー２３もこのメモリ１０に格納されて保持される。
【００２３】
２次記憶装置１１は、例えばハードディスク装置等の磁気ディスク装置や、外付けのストレージサブシステム、又は、磁気ディスク装置及び外付けのストレージサブシステムの両方から構成され、各種プログラムや各種制御情報を永続的に保持するために用いられる。後述するルール情報３０、管理対象構成情報３１、ルールセグメントレポジトリ３２、セグメント結合情報３３、イベントオブジェクトテーブル３４及びセグメント参照履歴情報３５もこの２次記憶装置１１に格納されて保持される。
【００２４】
プロセッサ１２は、管理サーバ２全体の動作を制御する機能を有するもので、メモリ１０や２次記憶装置１１に格納された電子データに基づいて各種の演算処理や制御処理を実行する。またネットワークインタフェース１３は、管理用ネットワーク５に対するインタフェースであり、例えばＮＩＣ（Network Interface Card）やＬＡＮ（Local Area Network）ボードなどから構成される。
【００２５】
なお、管理サーバ２は、図示しない入出力装置をも有する。入出力装置の例としては、ディスプレイ、キーボード及びポインタデバイスが考えられるが、これ以外の装置であっても良い。また、入出力装置の代替としてシリアルインタフェースやイーサネット（登録商標）インタフェースを入出力とし、当該インタフェースにディスプレイ、キーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替しても良い。
【００２６】
管理対象装置群３は、上述のように１又は複数の情報処理装置４から構成される。図２は、管理対象装置群３の一構成例を示す。この例では、管理対象装置群３は、複数のサーバ４０（「SERVER1」、「SERVER」、……）と、ネットワーク４１と、１つのストレージ装置４２（「STORAGE1」）とから構成されている。そしてこの図２では、ストレージ装置４２のボリュームがサーバ４０の「ISCSI INITIATOR01」というＨＡＢ（Host Bus Adapter）４０Ａを介してＩＳＣＳＩ（Internet Small Computer System Interface）プロトコルにてＳＣＳＩディスク４０Ｂ（「SCSIDISK01」、「SCSIDISK03」）として提供されている場合を例示している。なお図２において、ストレージ装置４２の「Controller01」は、ストレージ装置４２を制御するプロセッサであり、ＩＳＣＳＩポートを備えている。
【００２７】
管理用ネットワーク５は、ＬＡＮ（Local Area Network）、インターネット又は専用回線などから構成される。管理用ネットワーク５は、情報処理装置４間の通信を行うためのネットワークと別なネットワークであってもよく、また部分的又は完全に同一なネットワークであっても良い。
【００２８】
以下、管理対象装置群３を管理し、本願実施の形態における表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバ２が表示用情報を表示する場合は管理サーバ２が管理システムであり、管理サーバ２と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバ２と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含める）が管理システムである。
【００２９】
（２）本実施の形態による障害原因解析機能
次に、管理サーバ２に搭載された障害原因解析機能について説明する。これに際して、まず、イベント通知、ルール情報及びルール解析網について説明する。
【００３０】
（２−１）イベント通知、ルール情報及びルール解析網
図３は、管理サーバ２が管理・監視の対象とする情報処理装置（以下、これを管理対象装置とも呼ぶ）４に障害が発生したときに、当該管理対象装置４から管理サーバ２に送信されるイベント通知５０の概略構成を示す。この図３からも明らかなように、イベント通知５０は、イベントＩＤ５０Ａ、イベント検知時刻５０Ｂ、発生元装置ＩＤ５０Ｃ、発生元部位ＩＤ５０Ｄ及びイベント内容５０Ｅと、詳細情報５０Ｆとを含んで構成される。
【００３１】
このうちイベントＩＤ５０Ａは、そのとき発生したイベントに対して予め付与されているＩＤを表し、イベント検知時刻５０Ｂは、そのイベントが発生した時刻を表す。また発生元装置ＩＤ５０Ｃは、そのイベントが発生した情報処理装置４に対して予め付与されていた識別子であり、発生元部位ＩＤ５０Ｄは、その情報処理装置４におけるそのイベントが発生した部位に対して予め付与されていた識別子を表す。さらにイベント内容５０Ｅは、そのイベントの内容を表す。詳細情報５０Ｆは、そのイベントに関する詳細な情報を表す。この詳細情報５０Ｆには、イベントに関する上述の情報以外の情報（例えばメッセージ）などが含まれる。
【００３２】
従って図３の例の場合、図２の環境において、「SERVER1」というサーバ４０の「SCSIDISK01」という部位の状態がエラーに変化した（「Status Change To ERROR」）ことが「2000-1-1 00:00:00」にそのサーバ４０又はその管理装置（図示せず）により検出され、かかるイベントのイベントＩＤが「010000020」であることが示されている。
【００３３】
一方、図４は、ルール情報３０の構成を示す。ルール情報３０は、イベントの組み合わせを条件とし、この組み合わせに対する根本原因を推論の結論とするルールに関する情報であり、予めシステム管理者などにより複数作成されて管理サーバ２に登録される。後述のように、管理サーバ２は、障害発生時に障害が発生した管理対象装置４又はその管理装置等から送信されるイベント通知５０（図３）と、このルール情報３０とに基づいて、障害の根本原因を推論する。
【００３４】
ルール情報３０は、例えば図４に示すように、ルール識別情報６１、条件部６２及び結論部６３から構成される。このうちルール識別情報６１は、ルールを一意に識別するための識別子であり、ルール情報３０ごとに異なる値が付与される。
【００３５】
条件部６２は、１又は複数の条件６４から構成される。また各条件６４は、それぞれイベント情報６５及び条件演算子６６から構成される。条件６４のイベント情報６５は、イベントに関する情報であり、対応するイベントのイベントＩＤ６５Ａと、そのイベントが発生する部位を表す装置部位情報６５Ｂと、イベント内容６５Ｃとを含む。
【００３６】
イベントＩＤ６５Ａ及びイベント内容６５Ｃは、イベント通知５０（図３）において使用されるものと同じものが使用され、装置部位情報６５Ｂは、イベント通知５０において使用される発生元装置ＩＤ５０Ｃ及び発生元部位ＩＤ５０Ｄを組み合わせたものが使用される。
【００３７】
また条件演算子６６は、対応するイベント情報６５に対する演算を指定する演算子であり、「受信しないこと」を条件とする場合の「NOT」等の演算子を含む。条件演算子６６は省略可能であり、省略された場合には、イベント情報６５を「受信すること」を条件とすることを表す。
【００３８】
結論部６３は、「if-then」形式のルールの結論を示すイベント情報６７と、条件部６２に対する評価の算出の仕方を指定する結論演算子６８とから構成される。複数のルールで共通の結論を導くことも可能であるため、複数のルール情報３０において共通の結論部６３が用いられることがある。結論演算子６８は、そのような複数ルール間で共有される結論部６３である場合に、それらのルールにおけるマッチング度をどのように共通の結論部６３に対するマッチング度として反映させるかを指定する演算子である。例えば、複数ルールの中でマッチング度が最大のものをその結論のマッチング度としたり、複数ルールのマッチング度を均等に重み付けして、全ルールの条件におけるマッチング度という形で評価する演算がある。なおこの結論演算子６８の種類は、本実施の形態に制限を与えるものではない。
【００３９】
結論部６３のイベント情報６７は、イベントＩＤ６７Ａ、装置部位情報６７Ｂ及びイベント内容６７Ｃを含む。これらイベントＩＤ６７Ａ、装置部位情報６７Ｂ及びイベント内容６７Ｃは、条件部６２のイベント情報６５におけるイベントＩＤ６５Ａ、装置部位情報６５Ｂ及びイベント内容６５Ｃと同様のものであるため、その詳細については説明を省略する。
【００４０】
ルール情報３０の具体例を図５に示す。図５は、図２の環境において、「STORAGE1」というストレージ装置４２が「SERVER1」というサーバ４０に提供している「SCSIDISK01」というボリュームの状態がエラーに変化した場合に、その状態変化の根本原因が「SERVER1」のＩＳＣＳＩ通信エラーであると推論するよう規定したルールについての具体例である。すなわち図５のルール情報３０では、以下の事項が指定されている。
【００４１】
（ａ）条件部６２では、イベントＩＤが「010000020」のイベントであって、「SERVER1」の「SCSIDISK01」において「状態がエラーに変化した（「Status Change To UNKNOWN」）」というイベントが発生したことを知らせるイベント通知５０を受信した場合のルールであることが規定されている（条件６４のイベント情報６５を参照）。なお、エラー状態は少なくとも装置又は部位が使えない状態であることを含むほか、一般的にエラーとされる状態を含めても良い。以後で説明する他のケースについても特に記載しない限りエラー状態は前述の意味であるものとする。
【００４２】
（ｂ）結論部６３では、かかるイベント通知５０を受信した場合、イベントＩＤが「910000020」のイベントであって、「SERVER1」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０Ａにおける「ＩＳＣＳＩ通信エラー（「RC_COM_ERROR」）」というイベントが原因であると推測するよう規定されている（結論部６３のイベント情報６７を参照）。
【００４３】
またルール情報３０の他の具体例を図６に示す。図６は、図２の環境において、「SERVER1」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０ＡにおいてＩＳＣＳＩ通信エラーが発生し、「SERVER2」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０ＡにおいてＩＳＣＳＩ通信エラーが発生し、さらに「STORAGE1」というストレージ装置４２の「CONTROLLER01」というコントローラ４２Ａの状態がエラーに変化した発生し場合に、これらの状態変化の根本原因が「STORAGE1」の「CONTROLLER01」の障害であると推論するよう規定されたルールについての具体例である。すなわち図６のルール情報３０では、以下の事項が指定されている。
【００４４】
（ａ）条件部６２では、イベントＩＤが「910000020」のイベントであって、「SERVER1」の「ISCSIINITIATOR01」において「ＩＳＣＳＩ通信エラー（Status Change To COM_ERROR）」というイベントが発生したというイベント通知５０と、イベントＩＤが「910000020」のイベントであって、「SERVER2」の「ISCSIINITIATOR01」において「ＩＳＣＳＩ通信エラー（Status Change To COM_ERROR）」というイベントが発生したというイベント通知５０と、イベントＩＤが「040000020」のイベントであって、「STORAGE1」の「CONTROLLER01」において「エラー（Status Change To ERROR）」というイベントが発生したというイベント通知５０とを受信した場合のルールであることが規定されている（条件部６２の各条件６４のイベント情報６５を参照）。
【００４５】
なお、このイベント情報６５のイベントＩＤは、図５のルール情報３０における結論部６３のイベント情報６７と同一であり、他のルール情報３０の結論部６３にて定義されるイベント情報６７は、管理対象装置群３より送信されるイベント通知５０とは異なり、管理サーバ２内部のみで作成、利用される。このような図５の結論部６３にて指定されるイベント情報６７を、管理対象装置群３より送信されるイベント通知５０と特に区別して内部イベント情報と呼ぶ。
【００４６】
（ｂ）結論部６３では、上述のようなイベント通知５０を受信した場合、イベントＩＤが「940003020」のイベントであって、「STORAGE1」の「CONTROLLER01」における「エラー（RC_ERROR）」というイベントが原因であると推測するよう規定されている（結論部６３のイベント情報６７を参照）。
【００４７】
他方、図７は、ルール解析網７０の構成例を示す。以下においては、管理対象装置群３に含まれるいずれかの管理対象装置４から管理サーバ２に送信されるイベント通知５０を元に、管理サーバ２の管理プログラム２２が推論を行い、現在発生している事象を推論する管理システムにおいて、管理プログラム２２が推論処理において参照する複数のルール情報３０間の関係（ルールＡ及びルールＢの結論が同じ場合には、結論を介してルールＡ及びルールＢが結合されるなどの関係）を結びつけたルール結合ネットワークをルール解析網７０と呼ぶものとする。
【００４８】
図７は、後述のように２次記憶装置１１に格納されたすべてのルール情報３０に基づいて、関連するイベント情報６５，６７を互いに結合させて構築されたルール解析網７０を模式的に示したものである。図中の双方向の矢印は互いに参照関係を有しており、どちらの方向からも接続先のオブジェクト７１（７１Ａ〜７１Ｄ）を辿ることができることを示している。このようなルール解析網７０を構成するオブジェクト７１としては、イベントオブジェクト７１Ａ、条件オブジェクト７１Ｂ、ルールオブジェクト７１Ｃ及び結論オブジェクト７１Ｄが存在する。
【００４９】
イベントオブジェクト７１Ａは、ルール情報３０の条件部６２の条件６４に含まれるイベント情報６５（図４）、又は、結論部６３に含まれるイベント情報６７に基づいて生成されるオブジェクトであり、図８に示すように、イベントＩＤ７１ＡＡ、装置部位情報７１ＡＢ及びイベント内容７１ＡＣをそれぞれ含む。このうちイベントＩＤ７１ＡＡは、対応するイベント情報６５，６７のイベントＩＤ６５Ａ，６７Ａをコピーしたものである。また装置部位情報７１ＡＢは、そのイベント情報６５，６７の装置部位情報６５Ｂ，６７Ｂにより認識されるイベントの発生元装置及びその発生元部位をそれぞれ表すコードを組み合わせた情報である。さらにイベント内容７１ＡＣは、そのイベント情報６５，６７のイベント内容６５Ｃ，６７Ｃをコピーしたものである。ただし、これ以外の情報を含んでいても。
【００５０】
また条件オブジェクト７１Ｂは、ルール情報３０の条件部６２を構成する各条件６４（図４）に基づいてそれぞれ生成されるオブジェクトであり、図９に示すように、条件ＩＤ７１ＢＡ及び条件演算子７１ＢＢを含む。このうち条件ＩＤ７１ＢＡは、対応する条件６４を識別するための識別情報である。また条件演算子７１ＢＢは、対応する条件６４に含まれる条件演算子６６（図４）をコピーしたものである。
【００５１】
ルールオブジェクト７１Ｃは、ルール情報３０そのものに対応するオブジェクトであり、図７に示すように、条件オブジェクト７１Ｂと結論オブジェクト７１Ｄとの関係を結びつけるオブジェクトとして存在する。ルールオブジェクト７１Ｃは、図１０に示すように、ルール識別情報７１ＣＡを含む。このルール識別情報７１ＣＡは、対応するルール情報３０のルール識別情報６１（図４）をコピーしたものである。
【００５２】
さらに結論オブジェクト７１Ｄは、ルール情報３０の結論部６３（図４）に基づいて生成されるオブジェクトであり、図１１に示すように、結論ＩＤ７１ＤＡ及び結論評価演算子７１ＤＢを含む。このうち結論ＩＤ７１ＤＡは、対応する結論部６３を識別するための識別情報である。また結論評価演算子７１ＤＢは、結論を共有する複数ルールにおけるマッチング度の評価の仕方を指定するための演算子である。
【００５３】
ルール情報３０に基づく推論導出の解析処理は、通常、解析時のルールとのパターンマッチングを高速化するために、すべてのルール情報３０に基づいて図７に示すルール解析網７０を構築し、受信したイベント通知５０に基づき認識されるイベントに対応するイベントオブジェクト７１Ａを検索して関連するルールオブジェクト７１Ｃを辿り、該当の結論オブジェクト７１Ｄのマッチング度をそれぞれ評価することで行われる。
【００５４】
ただし、すべてのルール情報３０に基づくルール解析網７０をメモリに載せてワーキングメモリとして参照すると、メモリサイズを逼迫して、かかる処理を実行する計算機のリソースを大量消費して装置を不安定にする要因になる。そこで、本実施の形態においては、ルール解析網７０を幾つかに分断した以下に説明するような部分ルール解析網を構築し、必要な部分ルール解析網のみをメモリ１０上に載せて解析処理を実行する。
【００５５】
図１２は、ルール解析網７０を１つのルール情報３０に相当する単位に分割したセグメント（以下、これをルールセグメントと呼ぶ）７２のオブジェクト構成を模式的に示したものである。ルールセグメント７２は、１つのルールオブジェクト７２Ｃをもち、ルールオブジェクト７２Ｃに対応するルール情報３０に従って条件部６２がもつ１つ以上の条件６４に対応する条件オブジェクト７２Ｂと双方向の関連をもち、条件オブジェクト７２Ｂはそれぞれが保持するイベントオブジェクト７２Ａとの双方向の関連をもつ。
【００５６】
また、ルールセグメント７２は、ルール情報３０の結論部６３に対応する結論オブジェクト７２Ｄと双方向の関連をもち、結論オブジェクト７２Ｄは結論の内容を表すイベントオブジェクト７２Ａとの双方向の関連をもつ。このようにルールセグメント７２の構成において、条件オブジェクト７２Ｂとして少なくとも１つ以上の任意の数の条件（ただし、そのルールオブジェクト７２が持つ条件数を超えない）を保持するため、１つのルール情報３０に対して条件部６２の条件６４が複数のルールセグメント７２に分割されていても構わないし、一つのルールセグメント７２にルール情報３０がもつ条件部６２の条件６４がすべて含まれていても構わない。ルールセグメント７２を構成するイベントオブジェクト７２Ａ、結論オブジェクト７２Ｄ及びルールオブジェクト７２Ｃはルール解析網７０を構成するイベントオブジェクト７１Ａ、結論オブジェクト７１Ｄ及びルールオブジェクト７１Ｃとそれぞれ同一のものである。
【００５７】
図１３は、本実施の形態による条件オブジェクト７２Ｂの構成を示す。この条件オブジェクト７１Ｂは、図９について上述した条件オブジェクト７１Ｂに代えて本実施の形態において使用されるオブジェクトであり、条件ＩＤ７２ＢＡ、条件演算子７２ＢＢ、ロード状態７２ＢＣ及びイベントＩＤ７２ＢＤの各情報を含んで構成される。
【００５８】
このうち条件ＩＤ７２ＢＡ及び条件演算子７２ＢＢは、図９について上述した条件オブジェクト７１Ｂの条件ＩＤ７１ＢＡ及び条件演算子７１ＢＢと同様ものである。またロード状態７２ＢＣは、その条件オブジェクト７２Ｂがメモリ上に読み込まれているかどうかを表す情報である。さらにイベントＩＤ７２ＢＤは、接続先のイベントオブジェクト７２ＡのイベントＩＤを表す。このイベントＩＤ７２ＢＤは、イベントオブジェクト７２Ａと条件オブジェクト７２Ｂの相互参照関連を作成するときに使用する。
【００５９】
（２−２）本実施の形態による障害原因解析機能
次に、管理サーバ２に搭載された本実施の形態による障害原因解析機能について説明する。本実施の形態の場合、管理サーバ２には、予め与えられた１つ以上のルール情報３０に基づいて、ルール情報３０に記述された条件と、管理対象装置群３において発生したイベントとの組み合わせのパターンマッチングを行い、どれだけパターンが一致しているかを評価する障害原因解析機能が搭載されている。そして本実施の形態による障害原因解析機能は、解析処理時に使用されるワーキングメモリのサイズを一定サイズ以下に抑える手法として、以下の手順で障害原因の解析機処理を行う点を特徴の１つとしている。
【００６０】
（ａ）情報処理システム１を運用管理する前に、登録されているすべてのルール情報３０を読み込み、ルール間の依存関係を調べた上で、依存関係に基づいたルール情報３０の順番でルールセグメント７２を作成する。またルール（ルールセグメント７２）間の関係を表す情報をセグメント結合情報として作成すると共に、受信するイベント通知５０（図３）に対する索引情報としてイベント索引情報を作成する。
【００６１】
（ｂ）情報処理システム１の運用管理している間に障害が発生した場合に、その障害が発生した管理対象装置４等から送信されるイベント通知５０に基づき、（ａ）にて生成したイベント索引情報を元に、必要なルールセグメント７２と、このルールセグメント７２と関連するルールセグメント７２をメモリ１０（図１）読み込み、これらのルールセグメント７２を（ａ）にて生成したセグメント結合情報を元に、ルールセグメント７２間を結合した、受信イベントに対する解析網である部分ルール解析網を構築する。また構築した部分ルール解析網を用いて、受信したイベント通知５０により認識されるイベントと、ルールの条件に示されたイベントとの組み合わせとのパターンマッチングによる解析処理を実行する。この際、参照されたルールセグメント７２に関する参照履歴情報を作成する。
【００６２】
（ｃ）上記（ｂ）で構築した部分ルール解析網が占めるメモリサイズがある一定のサイズよりも大きくなった場合に、（ｂ）で作成されたルールセグメント７２の参照履歴情報を元に、参照頻度が少ないルールセグメント７２を選択し、これをメモリ１０上から掃き出すことによりメモリ１０内の記憶領域を解放して、ワーキングメモリのサイズを一定サイズ以下に保つ。
【００６３】
以上のような本実施の形態による障害原因解析機能を実現するための手段として、管理サーバ２のメモリ１０には、図１に示すように、部分ルール解析網２０、イベント索引情報２１、管理プログラム２２及びイベントキュー２３が格納されて保持され、２次記憶装置１１には、ルール情報３０、管理対象構成情報３１、ルールセグメントレポジトリ３２、セグメント結合情報３３、イベントオブジェクトテーブル３４及びセグメント参照履歴情報３５もこの２次記憶装置に格納されて保持される。
【００６４】
このうち部分ルール解析網２０は、管理プログラム２２が障害の解析処理を行うときに参照するルールの関係情報を持つルール解析網である。この部分ルール解析網２０は、障害が発生したときに管理対象装置４から与えられるイベント通知５０（図３）に基づいて、その障害に関連するルールセグメント７２（図１２）を組み合わせることにより構築される。
【００６５】
またイベント索引情報２１は、図１４に示すように、管理対象装置４からのイベント通知５０を受信したときに、解析処理を実行する際に使用すべきルールセグメント７２を検索するための情報（イベントとこれに関連するルールセグメント７２との関係を表す情報）であり、管理プログラム２２がルール情報３０を入力としてルールセグメント７２を作成した場合に一緒に生成される。なおメモリ１０には、異なる複数のイベント索引情報２１を格納することができる。
【００６６】
このイベント索引情報２１は、図１５に示すように、イベントＩＤ２１Ａ、セグメントＩＤ２１Ｂ及び読込み状態２１Ｃの各情報を含む。このうちイベントＩＤ２１Ａは、各種イベントにそれぞれ付与された識別子を表し、イベント通知５０において使用されるイベントＩＤと同じものが適用される。またセグメントＩＤ２１Ｂは、対応するイベントＩＤを含むイベント通知５０を受信したときの解析処理に使用すべきルールセグメント７２の識別子（セグメントＩＤ）を表す。
【００６７】
さらに読込み状態２１Ｃは、そのイベントＩＤ２１Ａが付与されたルールセグメント７２がメモリ１０に読み込まれているか否かを表す。例えばそのオブジェクトがメモリ１０に読み込まれている場合、読込み状態が「LOADED」に設定され、そのオブジェクトがメモリに読み込まれていない場合、読込み状態が「NOT」に設定される。
【００６８】
従って、図１４の例では、例えば「Z1-1_ID」というイベントＩＤのイベントが発生したことを知らせるイベント通知５０を受信した場合には、「X1-10a_seg」というセグメントＩＤのルールセグメント７２を用いて解析処理を行うべきことが規定されており、そのルールセグメント７２は既にメモリ１０に読込み済みであることが示されている。
【００６９】
管理プログラム２２は、いずれかの管理対象装置４からのイベント通知５０の受信や、管理対象装置４からの情報収集によるイベントの検知に基づき、検知したイベントを入力として管理対象装置４で発生した事象を解析するプログラムである。
【００７０】
管理プログラム２２は、以下に説明する各種の処理に加えて、各管理対象装置４の状態（例えば、障害発生の有無、その管理対象装置４で行われた設定変更の有無、その管理対象装置４の性能に関する状態）を管理する。
【００７１】
具体的に、管理プログラム２２は、ネットワークインタフェース１３を介して管理対象装置４から障害発生の有無や、その管理対象装置４の設定情報、及び性能情報などの管理情報を受信する。そして管理プログラム２２は、受信した管理情報に基づいて各管理対象装置４の状態を判断し、その判断結果や各管理対象装置４の状態を、ディスプレイ装置等へ表示し又は予め設定されたユーザに電子メールにて通知する。なお、管理プログラム２２が、管理サーバ２が受信した管理対象装置４への設定要求を受信し、当該要求に基づいて対応する管理対象装置４への設定を行うようにしても良い。
【００７２】
イベントキュー２３は、管理対象装置４又はその管理装置から与えられるイベント通知５０を順番に格納するためのキューである。管理プログラム２２は、このイベントキュー２３に格納されたイベント通知５０に応じた処理を、当該イベントキュー２３に格納された順番で処理する。
【００７３】
一方、ルール情報３０は、図４〜図６について上述したように、管理対象装置４においてどのようなイベントが発生したときにどのような障害が発生したと推理すべきかといった、発生した障害の根本原因解析を行うためのルールに関する情報である。２次記憶装置１１には、このようなルール情報３０が予め複数格納される。
【００７４】
管理対象構成情報３１は、管理対象装置群３に含まれる各管理対象装置４の識別子と、管理用ネットワーク５上でその管理対象装置４にアクセスするために使用されるＩＰアドレス等の識別情報及び認証情報と、その管理対象装置４の管理用ネットワーク５における接続状態及び論理的な関係情報（例えば接続関係や、サーバ・クライアントの関係、包含関係）と、その管理対象装置４の構成に関する情報とを含む。
【００７５】
具体的には、管理対象構成情報３１は、以下の情報を含む。
（ａ）各管理対象装置４の識別子。これら識別子は、管理対象装置４と通信するための識別子、例えばＩＰアドレス、ＦＱＤＮ（Fully Qualified Domain Name）、又はホスト名等が考えられる。
（ｂ）管理対象装置４の種別（例えば、ストレージサブシステム、スイッチ装置、サーバ装置等）と、当該管理対象装置４を構成する部位の種別。
（ｃ）管理対象装置４を構成する部位の情報及び装置と部位、または部位と部位の包含関係。
（ｄ）ネットワーク通信を行うための部位については、接続相手となる部位。
（ｅ）管理対象装置４の設定。
【００７６】
なお、管理対象構成情報３１は以下の処理により生成又は更新されることが考えられるが、他の処理から生成されたものであってもよい。
（ａ）管理プログラム２２が、管理対象装置４から受信したその管理対象装置４についての構成情報及び設定情報に基づいて管理対象構成情報３１を生成又は更新する。
（ｂ）管理プログラム２２が管理対象装置４の設定を行える場合は、管理プログラム２２が管理サーバ２の入力装置を介して受信した装置設定情報を装置に設定すると共に、管理対象構成情報３１を生成又は更新する。
【００７７】
また本実施の形態においては、管理対象構成情報３１が２次記憶装置１１に格納されているものとして説明するが、２次記憶装置１１以外の例えばメモリ１０に格納されていても構わない。
【００７８】
ルールセグメントレポジトリ２３は、管理プログラム２２に基づきルール情報３０を元に作成された１つ以上のルールセグメント７２を格納して管理するためのレポジトリである。このルールセグメントレポジトリ２３には、管理対象装置群３において発生したイベントに応じてメモリ１０上に読込んだ際の参照履歴情報であるセグメント参照情報７３も格納される。
【００７９】
セグメント参照情報７３は、管理サーバ２が各ルールセグメント７２の格納位置を管理するための情報であり、例えば図１６に示すように、セグメントＩＤ７３Ａ、格納場所７３Ｂ及びルール識別情報７３Ｃの各情報から構成される。
【００８０】
このうちセグメントＩＤ７３Ａは、対応するルールセグメント７２に対して付与された識別子（以下、これをセグメントＩＤと呼ぶ）であり、格納場所７３Ｂは、ルールセグメントレポジトリ３２における対応するルールセグメント７２の格納場所を表す。このルールセグメント７２の格納場所７３Ｂは、ファイル名などのリソースの位置を特定可能なＵＲＮ（Universal Resource Name）と、そのリソース内での格納位置（論理アドレス、物理アドレスなど）との組み合わせで表現される。
【００８１】
またルール識別情報７３Ｃは、そのルールセグメント７２に対応するルール情報３０の識別情報（以下、これをルール情報識別子と呼ぶ）を表す。従って、図１６の例では、「X1-10a_seg」というセグメントＩＤのルールセグメント７２は、「file://C:\ :\seg_repo01」というファイル内の「1af00...」というアドレス位置に格納されており、このルールセグメントが含んでいるルール情報３０の識別子は「X1」であることが示されている。
【００８２】
なお、ルールセグメント７２の格納場所は、ファイルシステム上のファイルであっても、データベースシステムのデータベースであっても、ネットワーク上のリソース（ファイルシステム、ブロックストレージ）であっても良く、その格納形態については問わない。ただし、格納場所７３Ｂが特定するのに十分な情報が使用されることが要件である。
【００８３】
セグメント結合情報３３は、ルールセグメント７２の管理サーバの２次記憶装置１１内の各ルール情報３０に基づき形成された各オブジェクト（イベントオブジェクト７２Ａ、条件オブジェクト７２Ｂ、ルールオブジェクト７２Ｃ及び結論オブジェクト７２Ｄ）がどのルールセグメント７２のどのオブジェクトに結合されるかなどを管理するための情報であり、図１７に示すように、オブジェクト種別３３Ａ、識別情報３３Ｂ、結合先セグメントＩＤ３３Ｃ、結合先オブジェクトＩＤ３３Ｄ及び読込み状態３３Ｅの各情報から構成される。
【００８４】
このうちオブジェクト種別３３Ａは、対応するオブジェクトの種別（「イベント」、「条件」、「ルール」又は「結論」）を表し、識別情報３３Ｂは、そのオブジェクトの識別子（以下、これをオブジェクトＩＤと呼ぶ）を表す。また結合先セグメントＩＤ３３Ｃは、そのオブジェクトが属するルールセグメント７２のセグメントＩＤを表し、結合先オブジェクトＩＤ３３Ｄは、そのルールセグメント７２においてそのオブジェクトが結合されるオブジェクトのオブジェクトＩＤを表す。
【００８５】
さらに読込み状態３３Ｅは、そのオブジェクトが、現在、メモリ１０に読み込まれているか否かを表す。例えばそのオブジェクトがメモリ１０に読み込まれている場合、読込み状態が「LOADED」に設定され、そのオブジェクトがメモリに読み込まれていない場合、読込み状態が「NOT」に設定される。
【００８６】
従って、図１７の場合、図７を前提として、例えば「Y1」という結論オブジェクト７２Ｄ（図１２）については、「X1」というルールオブジェクト７２Ｃ（図１２）を含む「X1-10a-seg」というルールセグメント７２と関連を持ち、このルールセグメント７２内部の「X1_ID」というルールオブジェクト７２Ｃと結合すること、及び、このルールセグメント７２は既にメモリ１０に読込み済み（「LOADED」）であることが示されている。
【００８７】
なお、図１７において、「X1」というルールオブジェクト７２Ｃに対応する行が複数存在するが、これはルール情報３０の条件部６２の条件６４（図４）が複数のルールセグメント７２に分割されている場合の例であり、部分ルール解析網２０を構築する際に１つのルールオブジェクト７２Ｃに結合される。
【００８８】
イベントオブジェクトテーブル３４は、管理プログラム２２がルール情報３０からルールセグメント７２を作成する際に、最終的なイベントオブジェクト７２Ａを格納するテーブルである。このイベントオブジェクトテーブル３４の詳細については省略する。
【００８９】
他方、セグメント参照履歴情報３５は、管理プログラム２２から参照されにくいルールセグメント７２を判断及び選択するための情報であり、図１８に示すように、セグメントＩＤ３５Ａ、ルール識別情報３５Ｂ、ロック状態３５Ｃ、カウンタ３５Ｄ、平均読込み間隔３５Ｅ及び最終参照時刻３５Ｆの各情報から構成される。
【００９０】
このうちセグメントＩＤ３５Ａは、対応するルールセグメント７２のセグメントＩＤを表し、ルール識別情報３５Ｂは、そのルールセグメント７２に属するルールオブジェクト７２ＣのオブジェクトＩＤを表す。またロック状態３５Ｃは、そのルールセグメント７２Ｃの状態を表す。なお、「ルールセグメントの状態」については、後述する。
【００９１】
さらにカウンタ３５Ｄは、図示しないカウンタによりカウントされた、対応するルールセグメント７２が参照されていない期間を表し、平均読込み間隔３５Ｅは、管理プログラム２２が定義する一定の期間を１単位とするそのルールセグメント７２の平均的な参照間隔を表す。さらに最終参照時刻３５Ｆは、そのルールセグメント７２が最後に参照された時刻を表す。なお、セグメント参照履歴情報３５がこれ以外の参照履歴に関する情報を含んでいても構わない。
【００９２】
従って、例えば図１８の例では、「X1-10a_seg」というルールセグメント７２は、「X1」というルール情報３０に基づいて生成され、現在の状態は「locked」、カウンタの値は「０」、平均参照間隔は「15.0」、最終参照時刻は「2009:11…」であることが示されている。
【００９３】
なお、セグメント参照履歴情報３５における平均読込み間隔３５Ｅや最終参照時刻３５Ｆの値は、ロック状態３５Ｃが同じルールセグメント７２同士において、どちらかを追い出す場合の選択基準として利用される。例えば追い出しの対象として、平均読込み間隔３５Ｅが大きいものを選択したり、最終参照時刻３５Ｆが古いものを選択したりする。
【００９４】
（２−３）管理サーバのプロセッサにより実行される各種処理
次に、本実施の形態による障害原因解析機能に関連して管理サーバ２の管理プログラム２２により実行される各種処理について説明する。
【００９５】
（２−３−１）障害原因解析処理
図１９は、本実施の形態による障害原因解析機能に関連して管理プログラム２２により実行される障害原因解析処理の処理手順を示す。
【００９６】
管理プログラム２２は、管理サーバ２が起動されると、この図１９に示す障害原因解析処理を開始し、まず、２次記憶装置１１（図１）からルール情報３０を読み込み、読み込んだルール情報３０に基づいてルールセグメント７２、セグメント結合情報３３（図１）及びイベント索引情報２１（図１）を作成する（ＳＰ１）。この際、イベント索引情報２１は２次記憶装置１１上に作成され、その後、メモリ１０上に読込まれる。
【００９７】
続いて管理プログラム２２は、管理対象装置群３に対する監視・管理を開始し、管理対象装置群３に含まれるいずれかの管理対象装置４からイベント通知５０が送信されてくるのを待ち受ける（ＳＰ２）。
【００９８】
そして管理プログラム２２は、やがていずれかの管理対象装置４からイベント通知５０が送信されてくると、このイベント通知５０と、２次記憶装置１１内のルールセグメントレポジトリ３２に格納されたルールセグメント７２に関する情報とに基づいて、かかるイベント通知５０の内容を解析する（ＳＰ３）。
【００９９】
具体的に、管理プログラム２２は、関連するルールセグメント７２をメモリ１０上に読込み、セグメント結合情報３３を参照して、部分ルール解析網２０（図１）をメモリ１０上に構築する。また管理プログラム２２は、構築した部分ルール解析網２０を用いて、検知したイベントの解析処理を行う。この処理により読み込みをしたルールセグメント７２についての参照履歴情報をセグメント参照情報７３として登録又は更新する。なお、セグメント結合情報３３は、この処理においてメモリ１０上に読込まれていても構わない。
【０１００】
そして管理プログラム２２は、ステップＳＰ２に戻って、この後、以上のステップＳＰ２及びステップＳＰ３の処理を繰り返す。
【０１０１】
（２−３−２）前処理
図２０は、以上の障害原因解析処理（図１）のステップＳＰ１において管理プログラム２２により実行される処理（以下、これを前処理と呼ぶ）の具体的な処理手順を示す。管理プログラム２２は、この図２０に示す処理手順に従って、２次記憶装置１１に格納されている各ルール情報３０に基づいて１又は複数のルールセグメント７２、セグメント結合情報３３及びイベント索引情報２１等を作成する。
【０１０２】
すなわち管理プログラム２２は、障害原因解析処理のステップＳＰ１に進むと、この前処理理を開始し、まず、２次記憶装置１１に格納された１又は複数のルール情報３０の中から１つのルール情報を選択し（ＳＰ１０）、選択したルール情報３０を２次記憶装置１１からメモリ１０に読み込む（ＳＰ１１）。
【０１０３】
続いて管理プログラム２２は、ステップＳＰ１１においてメモリ１０に読み込んだルール情報３０について、そのルール情報３０の条件部６２（図４）の各条件６４（図４）のイベント情報６５（図４）に含まれるそのイベントのイベントＩＤ６５Ａ（図４）と、そのルール情報３０のルール識別情報６１（図４）とをそれぞれ図２１に示す第１の関連情報テーブル８０のイベントＩＤ欄８０Ａ及びルール識別情報欄８０Ｂに登録する（ＳＰ１２）。
【０１０４】
また管理プログラム２２は、ステップＳＰ１１においてメモリ１０に読み込んだルール情報３０について、結論部６３（図４）のイベント情報６７（図４）に含まれるそのイベントのイベントＩＤ６７Ａ（図４）と、そのルール情報３０のルール識別情報６１（図４）とをそれぞれ図２２に示す第２の関連情報テーブル８１のイベントＩＤ欄８１Ａ及びルール識別情報欄８１Ｂに登録する（ＳＰ１２）。
【０１０５】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１２の処理を実行し終えたか否かを判断する（ＳＰ１３）。そして管理プログラム２２は、この判断において否定結果を得ると、ステップＳＰ１０に戻り、この後、ステップＳＰ１０において順次他のルール情報３０を選択しながらステップＳＰ１０〜ステップＳＰ１３の処理を繰り返す。
【０１０６】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１２の処理を実行し終えることによりステップＳＰ１３において肯定結果を得ると、ステップＳＰ１２において作成した第１及び第２の関連情報テーブ８０，８１に基づいて、後述するステップＳＰ１５〜ステップＳＰ１７の処理を実行するルール情報３０の順番を定めたルール実行リストを作成する（ＳＰ１４）。
【０１０７】
このルール実行リストは、ルール情報３０間の依存関係を調べ、依存があるルール間の実行順序を制御するためのリストである。ルール情報３０間の依存関係とは、ある第１のルール情報３０の結論部６３が保持するイベントが、他の第２のルール情報３０の条件部６２の条件６４が保持するイベントとなっている関係をいう。以下においては、かかる場合に第１のルール情報３０を第２のルール情報３０の「子」と呼び、第２のルール情報３０を第１のルール情報３０の「親」と呼ぶものとする。
【０１０８】
続いて管理プログラム２２は、２次記憶装置１１に格納された１又は複数のルール情報３０の中から１つのルール情報３０を選択し（ＳＰ１５）、選択したルール情報３０に基づいてルールセグメント７２を構築する。また管理プログラム２２は、この際、セグメント結合情報３３（図１）、イベント索引情報２１（図１）及びイベントオブジェクトテーブル３４（図１）を作成する（ＳＰ１６）。
【０１０９】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１６の処理を実行し終えたか否かを判断する（ＳＰ１７）。そして管理プログラム２２は、この判断において否定結果を得ると、ステップＳＰ１５に戻り、この後、ステップＳＰ１５において順次他のルール情報３０を選択しながら、ステップＳＰ１５〜ステップＳＰ１７の処理を繰り返す。
【０１１０】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１６の処理を実行し終えることによりステップＳＰ１７において肯定結果を得ると、ステップＳＰ１５〜ステップＳＰ１７の処理により作成された最終的なイベントオブジェクトテーブル３４を２次記憶装置１１に出力する（ＳＰ１８）。かくしてこのイベントオブジェクトテーブル３４は、この後、２次記憶装置１１に永続的に記憶され、後の解析処理時（図１９のステップＳＰ３）に利用される。
【０１１１】
（２−３−３）関連情報テーブル作成処理
図２３は、図１９について上述した前処理のステップＳＰ１２における管理プログラム２２の具体的な処理内容を示す。管理プログラム２２は、この図２３に示す処理手順に従って、第１及び第２の関連情報テーブル８０，８１を作成する。
【０１１２】
すなわち管理プログラム８０は、前処理のステップＳＰ１２に進むと、この図２３に示す関連情報テーブル作成処理を開始し、まず、前処理のステップＳＰ１１において読み込んだ図４に示すルール情報３０の条件部６２に含まれる条件６４を１つ選択する（ＳＰ２０）。
【０１１３】
続いて管理プログラム２２は、そのとき選択した条件６４に含まれるイベント情報６５のイベントＩＤ６５Ａのエントリが第１の関連情報テーブル８０に存在するか否かを判断し（ＳＰ２１）、肯定結果を得るとステップＳＰ２３に進む。
【０１１４】
これに対して管理プログラム２２は、ステップＳＰ２１の判断において否定結果を得ると、第１の関連情報テーブル８０にそのイベントＩＤ６５Ａのエントリを作成し（ＳＰ２２）、そのエントリのルール識別情報欄８０Ｂ（図２１）に、前処理（図２０）のステップＳＰ１１において読み込んだルール情報３０のルール識別情報６１（図４）を格納する（ＳＰ２３）。
【０１１５】
次いで管理プログラム２２は、前処理のステップＳＰ１１において読み込んだルール情報３０に含まれるすべての条件６４についてステップＳＰ２１〜ステップＳＰ２３の処理を実行し終えたか否かを判断する（ＳＰ２４）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ２０に戻り、この後、ステップＳＰ２４において肯定結果を得るまで、ステップＳＰ２０において順次他の条件を選択しながらステップＳＰ２０〜ステップＳＰ２４の処理を繰り返す。
【０１１６】
そして管理プログラム２２は、やがて前処理のステップＳＰ１１において読み込んだルール情報３０に含まれるすべての条件６４についてステップＳＰ２１〜ステップＳＰ２３の処理を実行し終えることによりステップＳＰ２４において肯定結果を得ると、かかるルール情報３０の結論部６３に含まれるイベント情報６７（図４）のイベントＩＤ６７Ａのエントリが第２の関連情報テーブル８１に存在するか否かを判断する（ＳＰ２５）。
【０１１７】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ２７に進む。これに対して管理プログラム２２は、ステップＳＰ２５の判断において否定結果を得ると、第２の関連情報テーブル８１にそのイベントＩＤ６７Ａのエントリを作成し（ＳＰ２６）、そのエントリのルール識別情報欄８１Ｂに、前処理のステップＳＰ１１において読み込んだルール情報３０のルール識別情報６１を格納する（ＳＰ２７）。
【０１１８】
そして管理プログラム２２は、この後、この関連テーブル作成処理を終了して、前処理のステップＳＰ１３に進む。
【０１１９】
（２−３−４）ルール実行リスト作成処理
一方、図２４は、前処理（図２０）のステップＳＰ１４において管理プログラム２２により実行されるルール実行リスト作成処理の具体的な処理手順を示す。管理プログラム２２は、この図２４に示す処理手順に従って、第１及び第２の関連情報テーブル８０，８１に基づき、ルール実行リストを作成する。なお、ルール実行リストは、イベントＩＤが順番に登録されたリストである。
【０１２０】
すなわち管理プログラム２２は、前処理のステップＳＰ１４に進むと、このルール実行リスト作成処理を開始し、まず、第１及び第２の関連情報テーブル８０，８１を参照して、図２５に示すルール情報依存関係管理テーブル８２を作成する（ＳＰ３０）。
【０１２１】
このルール情報依存関係管理テーブル８２は、ルール情報３０間の親子関係を管理するためのテーブルであり、図２５に示すように、親ルール列８２Ａ及び子ルール列８２Ｂから構成される。そして管理プログラム２２は、親ルール列８２Ａには、親子関係を有する２つのルール情報３０のうちの「親」となるルール情報３０のルール識別情報６１（図４）を格納し、子ルール列８２Ｂには、かかるルール情報３０の「子」となるルール情報３０のルール識別情報６１を格納する。
【０１２２】
続いて管理プログラム２２は、ルール情報依存関係管理テーブル８２にエントリ（行）が存在するか否かを判断し（ＳＰ３１）、否定結果を得ると、このルール実行リスト作成処理を終了する。
【０１２３】
これに対して管理プログラム２２は、かかるステップＳＰ３１の判断において肯定結果を得ると、１つのエントリを選択し（ＳＰ３２）、選択したエントリの親ルール列８２Ａに格納されているルール識別情報がルール実行リストに既に登録されているか否かを判断する（ＳＰ３３）。
【０１２４】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３６に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの親ルール列８２Ａに格納されたルール識別情報６１がルール情報依存関係管理テーブル８２のいずれかのエントリの子ルール列８２Ｂに格納されているか否かを判断する（ＳＰ３４）。
【０１２５】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３２に戻り、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの親ルール列８２Ａに格納されたルール識別情報をルール実行リストに追加する（ＳＰ３５）。
【０１２６】
続いて管理プログラム２２は、ルール情報依存関係管理テーブルにおけるそのとき対象としているエントリの子ルール列８２Ｂは空（ルール識別情報が格納されていない、つまり子ルールが存在しない）であるか否かを判断する（ＳＰ３６）。
【０１２７】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３９に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの子ルール列８２Ｂに格納されたルール識別情報が同じエントリ以外のいずれかのエントリの子ルール列８２Ｂに格納されているか否かを判断する（ＳＰ３７）。
【０１２８】
そして管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３９に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの子ルール列８２Ｂに格納されているルール識別情報をルール実行リストに追加する（ＳＰ３８）。
【０１２９】
この後、管理プログラム２２は、ステップＳＰ３２において選択したエントリをルール情報依存関係管理テーブル８２から削除し（ＳＰ３９）、ルール情報依存関係管理テーブル８２のすべてのエントリについてステップＳ３２Ｐ〜ステップＳＰ３９の処理を実行し終えたか否かを判断する（ＳＰ４０）。
【０１３０】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ３２に戻り、この後、ステップＳＰ３２において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ３２〜ステップＳＰ４０の処理を繰り返す。
【０１３１】
そして管理プログラム２２は、やがてルール情報依存関係管理テーブル８２のすべてのエントリについてステップＳＰ３２〜ステップＳＰ４０の処理を実行し終えることによりステップＳＰ４０において肯定結果を得ると、このルール実行リスト作成処理を終了して前処理（図２０）のステップＳＰ１５に進む。
【０１３２】
（２−３−５）ルール情報依存関係管理テーブル作成処理
他方、図２６は、ルール実行リスト作成処理（図２４）のステップＳＰ３０において管理プログラム２２により実行されるルール情報依存関係管理テーブル作成処理の具体的な処理手順を示す。管理プログラム２２は、この図２６に示す処理手順に従って、ルール情報依存関係管理テーブル８２を作成する。
【０１３３】
すなわち管理プログラム２２は、ルール実行リスト作成処理のステップＳＰ３０に進むと、このルール情報依存関係管理テーブル作成処理を開始し、まず、第１の関連情報テーブル８０（図２１）の未処理のエントリを１つ選択する（ＳＰ５０）。
【０１３４】
続いて管理プログラム２２は、第２の関連情報テーブル８１（図２２）の未処理のエントリを１つ選択し（ＳＰ５１）、この後、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのイベントＩＤ欄８０Ａに格納されているイベントＩＤと、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのイベントＩＤ欄８１Ａに格納されているイベントＩＤとが同じであるか否かを判断する（ＳＰ５２）。
【０１３５】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５５に進む。これに対して管理プログラム２２は、この判断において肯定結果を得ると、ルール情報依存関係管理テーブル８２のエントリの中に、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのルール識別情報欄８０Ｂに格納されたルール識別情報が親ルール列８２Ａに格納され、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのルール識別情報欄８１Ｂに格納されたルール識別情報を子ルール列８２Ｂに格納したエントリが存在するか否かを判断する（ＳＰ５３）。
【０１３６】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５５に進む。これに対して管理プログラム２２は、この判断において肯定結果を得ると、ルール情報依存関係管理テーブル８２に新たなエントリを作成し、そのエントリの親ルール列８２Ａに、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのルール識別情報欄８０Ｂに格納されたルール識別情報を格納すると共に、かかるエントリの子ルール列８２Ｂに、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのルール識別情報欄８１Ｂに格納されたルール識別情報を格納する（ＳＰ５４）。
【０１３７】
続いて管理プログラム２２は、第２の関連情報テーブル８１のすべてのエントリについてステップＳＰ５１〜ステップＳＰ５４の処理を実行し終えたか否かを判断する（ＳＰ５５）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５１に戻り、この後、ステップＳＰ５１において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ５１〜ステップＳＰ５５の処理を繰り返す。
【０１３８】
そして管理プログラム２２は、やがて第２の関連情報テーブル８１のすべてのエントリについてステップＳＰ５１〜ステップＳＰ５５の処理を実行し終えることによりステップＳＰにおいて肯定結果を得ると、第１の関連情報テーブル８０のすべてのエントリについてステップＳＰ５０〜ステップＳＰ５５の処理を実行し終えたか否かを判断する（ＳＰ５６）。
【０１３９】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５０に戻り、この後、ステップＳＰ５０において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ５０〜ステップＳＰ５６の処理を繰り返す。
【０１４０】
そして管理プログラム２２は、やがて第１の関連情報テーブル８１のすべてのエントリについてステップＳＰ５０〜ステップＳＰ５６の処理を実行し終えることによりステップＳＰ５６において肯定結果を得ると、２次記憶装置１１に格納されているルール情報３０の中から１つのルール情報３０を選択する（ＳＰ５７）。
【０１４１】
続いて管理プログラム２２は、ルール情報依存関係管理テーブル８２の親ルール列８２Ａ及び子ルール列８２Ｂのいずれか一方にステップＳＰ５７において選択したルール情報３０のルール情報識別子が格納されているエントリが存在しないか否かを判断する（ＳＰ５８）。
【０１４２】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ６０に進み、これに対して否定結果を得ると、ステップＳＰ５７において選択したルール情報３０のルール情報識別子が親ルール列８２Ａに格納され、かつ、子ルール列８２Ｂが空のエントリをルール情報依存関係管理テーブル８２に追加する（ＳＰ５９）。
【０１４３】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ５７〜ステップＳＰ６０の処理を実行し終えたか否かを判断する（ＳＰ６０）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５７に戻り、この後、ステップＳＰ５７において順次他のルール情報３０を選択しながらステップＳＰ５７〜ステップＳＰ６０の処理を繰り返す。
【０１４４】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ５７〜ステップＳＰ６０の処理を実行し終えることによりステップＳＰ６０において肯定結果を得ると、このルール情報依存関係管理テーブル作成処理を終了する。
【０１４５】
（２−３−６）ルールセグメント等作成処理
図２７は、図２０について上述した前処理のステップＳＰ１６において管理プログラム２２により実行されるルールセグメント等作成処理の処理手順を示す。管理プログラム２２は、この図２０に示す処理手順に従ってルールセグメント７２（図１２）、イベント索引情報２１（図１５）、セグメント結合情報３３（図１７）及びイベントオブジェクトテーブル３４をそれぞれ作成する。
【０１４６】
なお、この図２７に示すルールセグメント等作成処理の処理実行過程において、管理サーバ２のメモリ１０中に複数のルールオブジェクト７２Ｃ（図１２）を格納するデータ構造としてのルールオブジェクトテーブル（図示せず）と、複数の結論オブジェクト７２Ｄ（図１２）を格納するデータ構造としての結論オブジェクトテーブル（図示せず）と、複数のイベントオブジェクト７２Ａ（図１２）を格納するデータ構造としてのイベントオブジェクトテーブル（図示せず）とが作成される。これらルールオブジェクトテーブル、結論オブジェクトテーブル及びイベントオブジェクトテーブルのそれぞれは、初期状態では中身が空であるものとする。
【０１４７】
管理プログラム２２は、前処理のステップＳＰ１６に進むと、このルールセグメント等作成処理を開始し、まず、ステップＳＰ１５において選択したルール情報３０のルール識別情報６１（図４）に対応するルールオブジェクト７２Ｃがルールオブジェクトテーブルに登録されているか否かを判断する（ＳＰ７０）。
【０１４８】
管理プログラム２２は、この判断において肯定結果を得るとステップＳ７３に進み、これに対して否定結果を得ると、そのルールオブジェクト７２Ｃを作成し、作成したルールオブジェクト７２Ｃをルールオブジェクトテーブルに登録する（ＳＰ７１）。
【０１４９】
続いて、管理プログラム２２は、前処理のステップＳＰ１５において選択したルール情報３０の結論部６３（図４）に対応する結論オブジェクト７２Ｄを作成すると共に、その結論部６３に含まれるイベント情報６７（図４）に対応するイベントオブジェクト７２Ａを作成し、これら作成した結論オブジェクト７２Ｄ及びイベントオブジェクト７２Ａを関連付ける（ＳＰ７２）。
【０１５０】
次いで、管理プログラム２２は、ステップＳＰ７１において作成したルールオブジェクト７２Ｃと、ステップＳＰ７２において作成した結論オブジェクト７２Ｄとを関連付け（ＳＰ７３）、この後、ステップＳＰ７２において作成した結論オブジェクト７２Ｄを結論オブジェクトテーブルに登録し、又は既に結論オブジェクトテーブルに登録されている対応する結論オブジェクトを更新する（ＳＰ７４）。
【０１５１】
さらに管理プログラム２２は、かかる結論オブジェクト７２Ｄに関する必要な情報をセグメント結合情報３３（図１７）に登録し、又は既にセグメント結合情報３３に登録されている対応する結論オブジェクト７２Ｄを更新し（ＳＰ７５）、この後、前処理のステップＳＰ１５において選択したルール情報３０に、対応する条件オブジェクト７２Ｂ（図１３）が作成されていない条件６４（図４）が存在するか否かを判断する（ＳＰ７６）。
【０１５２】
管理プログラム２２は、この判断において肯定結果を得ると、かかるルール情報３０の条件部６２（図４）に含まれる条件６４の中から未処理の条件６４を１つ選択する（ＳＰ７７）。そして管理プログラム２２は、その条件６４に対応する条件オブジェクト７２Ｂを作成し、その条件オブジェクト７２Ｂと、ステップＳＰ７１において作成したルールオブジェクト７２Ｃとを関連付ける（ＳＰ７８）。
【０１５３】
続いて管理プログラム２２は、ステップＳＰ７７において選択した条件６４のイベント情報６５（図４）に含まれるイベントＩＤ６５Ａ（図４）をステップＳＰ７８において作成した条件オブジェクト７２ＢのイベントＩＤ７２ＢＤ（図１３）として格納する（ＳＰ７９）。さらに管理プログラム２２は、ステップＳＰ７６に戻り、この後ステップＳＰ７６において肯定結果を得るまでステップＳＰ７６〜ステップＳＰ７９の処理を繰り返す。
【０１５４】
そして管理プログラム２２は、前処理のステップＳＰ１５において選択したルール情報３０の条件部６２に含まれるすべての条件６４について、対応する条件オブジェクト７２Ｂを作成し終えることによりステップＳＰ７６において否定結果を得ると、前処理のステップＳＰ１５において選択したルール情報３０に対応するルールオブジェクト７２Ｃと、当該ルールオブジェクト７２Ｃに関連付けられた条件オブジェクト７２Ｂ及び結論オブジェクト７２Ｄと、イベントオブジェクト７２Ａとで構成されるルールセグメント７２とを２次記憶装置１１上のルールセグメントレポジトリ３２（図１）に格納する。また管理プログラム２２は、作成したルールセグメント７２にセグメントＩＤを付与し、そのルールセグメント７２のセグメントＩＤ、格納場所及び対応するルール情報３０のルール識別情報からなるルールセグメント７２の参照情報を作成する（ＳＰ８０）。この参照情報は、この後、図１６のセグメント参照情報７３に取り込まれる。
【０１５５】
加えて、管理プログラム２２は、そのルールセグメント７２を構成する条件オブジェクト７２Ｂが保持するイベントＩＤ７２ＢＤ（図１３）と、そのルールセグメント７２のセグメントＩＤとの対応関係を表すイベント索引情報とを作成する（ＳＰ８０）。このイベント索引情報は、この後、図１５のイベント索引情報２１（図１５）に取り込まれる。
【０１５６】
以上の処理により、ルールセグメント７２、セグメント結合情報３３及びイベント索引情報２１が作成される。
【０１５７】
（２−３−７）解析処理
他方、図２８は、図１９について上述した障害原因解析処理のステップＳＰ３において管理プログラム２２により実行される解析処理の具体的な処理手順を示す。
【０１５８】
管理プログラム２２は、障害原因解析処理のステップＳＰ３に進むと、この図２８に示す解析処理を開始し、まず、それまでに受信したイベント通知５０（図３）をイベントキュー２３（図１）から１つ取り出し（ＳＰ９０）、取り出したイベント通知５０に含まれるイベントＩＤ５０Ａ（図３）をキーとして、関連するルールセグメント７２のセグメントＩＤをイベント索引情報２１（図１５）から取得すると共に、イベントオブジェクトテーブル３４（図１）からイベントオブジェクト７２Ａ（図１２）を取得する（ＳＰ９１）。
【０１５９】
続いて管理プログラム２２は、関連するルールセグメント７２が２次記憶装置１１からメモリ１０に読み込み済みであるか否かをイベント索引情報２１（図１５）に含まれる読込み状態２１Ｃに基づいて判断し（ＳＰ９２）、肯定結果を得ると、ステップＳＰ９６に進む。
【０１６０】
これに対して管理プログラム２２は、ステップＳＰ９２の判断において否定結果を得ると、そのときメモリ１０に読み出されているすべてのルールセグメント７２により構成される部分ルール解析網２０（図１）の使用メモリ容量を取得し、その使用メモリ容量が予め設定された閾値以上であるか否かを判断する（ＳＰ９３）。
【０１６１】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ９５に進み、これに対して肯定結果を得ると、メモリ１０上のかかる部分ルール解析網２０を構成する一部のルールセグメント７２をメモリ１０から掃き出す（ＳＰ９４）。
【０１６２】
なお掃出し対象のルールセグメント７２の選択方法は、様々な方法が考えられるが、本実施の形態では、ルールセグメント７２の参照状況に基づいて状態を定義し、定義された状態や、参照された回数及び又は頻度などの情報を元に掃出し対象のルールセグメント７２を決定する。ルールセグメント７２の掃き出しは、そのルールセグメント７２に対する参照を全て削除することにより行ったり、メモリ管理を直接制御できる場合には、そのルールセグメント７２の読込みアドレスを直接解放したりすることにより行う。
【０１６３】
続いて管理プログラム２２は、ステップＳＰ９２において判断の対象としたルールセグメント７２を２次記憶装置１１上のルールセグメントレポジトリ３２（図１）からメモリ１０に読み出す（ＳＰ９５）。この際、管理プログラム２２は、セグメントＩＤをキーとしてルールセグメントレポジトリ３２内のセグメント参照情報７３（図１６）から対応するルールセグメント７２の格納位置を取得して読み出しを行う。またかかるルールセグメント７２の読み出し後に、イベント索引情報２１（図１５）と、ステップＳＰ９１において作成したイベントオブジェクト７２Ａとの相互参照を作成し、イベント索引情報２１とイベントオブジェクト７２Ａ、そして読み出したルールセグメント７２を相互参照及び結合させる。
【０１６４】
次いで管理プログラム２２は、セグメント参照履歴情報３５（図１８）におけるそのルールセグメント７２に対応する最終参照時刻３５Ｆ（図１８）及びロック状態３５Ｃ（図１８）を更新する（ＳＰ９６）。ロック状態３５Ｃは、現在、解析処理プログラムで解析中であることを示す「evaluated」に設定する。このロック状態３５Ｃは、実際に管理プログラム２２が実行対象として該ルールセグメント７２をスコープ内に入れた場合に「locked」に変更される。これらの状態遷移の詳細については図２９を用いて後ほど説明する。
【０１６５】
続いて管理プログラム２２は、そのとき対象としているイベント通知５０（ステップＳＰ９０においてイベントキュー２３から読み出したイベント通知５０）により報告されたイベントに関連するすべてのルールセグメント９２を２次記憶装置１１から読み出し終えたか否かを判断する（ＳＰ９７）。この判断は、管理プログラム２２は、ステップＳＰ95
において読み出したルールセグメント内のオブジェクトに関して、セグメント結合情報３３（図１７）において読込み状態３３Ｅが「NOT」となっているか否かにより行われる。
【０１６６】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ９０に戻り、この後、参照していない関連するルールセグメント７２についてステップＳＰ９０〜ステップＳＰ９７の処理を実行する（ＳＰ９７）。
【０１６７】
そして管理プログラム２２は、やがてステップＳＰ９０においてイベントキュー２３から取り出したイベント通知５０により報告されたイベントに関連するすべてのルールセグメント７２についてステップＳＰ９０〜ステップＳＰ９７の処理を実行し終えることによりステップＳＰ９７において否定結果を得ると、以上の処理により構築された部分ルール解析網２０（図１）を用いて解析を行う。また管理プログラム２２は、この解析結果を管理サーバ２に表示させ、又は、メールにより管理者に通知する（ＳＰ９８）。そして管理プログラム２２は、この後、この解析処理を終了する。
【０１６８】
（２−４）ルールセグメントの状態遷移
図２９は、ルールセグメント７２の状態遷移について定義した一例である。この図２９に示すように、ルールセグメント７２の状態としては、「INITIAL」、「evaluated」、「locked」、「weak locked」及び「released」の５つがある。
【０１６９】
このうち「INITIAL」は、ルールセグメント７２の初期の状態を表し、「evaluated」は、そのルールセグメント７２が評価対象に入った状態、「locked」は、そのルールセグメント７２がロックされた状態をそれぞれ表す。また「weak locked」は、そのルールセグメント７２が弱くロックされた状態を表し、「released」はそのルールセグメント７２が解放対象となっている状態を表す。
【０１７０】
ルールセグメント７２の状態は、初期時には「INITIAL」であり、そのルールセグメント７２に関連するイベントを知らせるイベント通知５０を受信した段階で「evaluated」に遷移する。また、この後、そのルールセグメント７２が管理プログラム２２の実行スコープに入ると、そのルールセグメント７２の状態が「locked」に遷移し、そのルールセグメント７２が属している部分ルール解析網２０を用いた解析処理が終了すると、そのルールセグメント７２の状態が「evaluated」から「weak locked」に遷移する。
【０１７１】
さらに「weak locked」という状態になってから一定期間、関連するイベントを受信しなかった場合に、そのルールセグメント７２の状態が「released」に遷移する。さらに、ルールセグメント７２が「weak locked」又は「released」の状態にある場合においても、そのルールセグメント７２が関連するイベントについてのイベント通知５０を受信した場合、状態が「evaluated」に遷移する。
【０１７２】
「INITIAL」、「evaluated」、「locked」、「weak locked」及び「released」のうち、掃き出しの対象とならないものは、「INITIAL」を除くと「locked」のみであり、それ以外の状態については、「released」、「weak locked」、「evaluated」の順で追い出される対象となる。
【０１７３】
また、「released」、「weak locked」及び「evaluated」のうち、無条件で追い出し可能なものは「released」のみで、「weak locked」は、他に「released」状態のルールセグメントが存在しない場合に追い出し対象となり、「evaluated」についても他に「weak locked」状態のルールセグメントが存在しない場合のみ追い出し対象となる。
【０１７４】
（３）本実施の形態の効果
以上のように本実施の形態による情報処理システム１によれば、管理サーバ２において、ルールを条件６４及び結論からなる１つ以上のルールセグメント７２に分割し、管理対象装置４からのイベント通知５０を受信したときに、関連する１又は複数のルールセグメント７２により部分ルール解析網２０をメモリ１０上に構築し、構築した部分ルール解析網２０に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメント７２をメモリ１０上から削除するため、推論導出時に必要とするワークメモリのメモリ容量を削減し、かつ推論導出に要するメモリ容量を一定に保つことができる。またルール情報３０に基づくルールセグメント７２を事前に容易しておき、管理対象装置４からのイベント通知５０を受信したときに必要なルールセグメント７２を結合することにより部分ルール解析網２０を構築するようにしているため、かかる推論導出までの時間を短時間化することができる。かくするにつき、対象システムの定義イベントの数やルールの数によらず、一定のワーキングメモリサイズを保ちながら、少ない解析時間で解析処理を実行することができる。
【産業上の利用可能性】
【０１７５】
本発明は、１又は複数の情報処理装置を管理し、管理対象の情報処理装置から送信されるイベント通知に基づいて解析処理を行う管理装置に広く適用することができる。
【符号の説明】
【０１７６】
１……情報処理装置、２……管理サーバ、３……管理対象装置群、４……管理対象装置、１０……メモリ、１１……２次記憶装置、１２……プロセッサ、２０……部分ルール解析網、２１……イベント索引情報、２２……管理プログラム、２３……イベントキュー、３０……ルール情報、３１……管理対象構成情報、３２……ルールセグメントレポジトリ、３３……セグメント結合情報、３４……イベントオブジェクトテーブル、３５……セグメント参照履歴情報、５０……イベント情報、７２……ルールセグメント、７３……セグメント参照情報。
【技術分野】
【０００１】
本発明は、管理装置及び管理方法に関し、例えば情報処理装置から送信される障害内容を表すイベント通知を用いて障害箇所及び原因を解析する障害解析機能が搭載された管理サーバに適用して好適なものである。
【背景技術】
【０００２】
近年、計算機システムは、計算機ネットワーク（以下、これを単にネットワークと呼ぶ）を介して様々な情報処理装置を相互に接続することで複雑化・大規模化してきている。これに伴いいずれかの情報処理装置に発生した障害がネットワークを介して様々な情報処理装置に影響を与えるようになってきた。
【０００３】
従来、このような障害の箇所と原因を特定する根本原因解析技術として、情報処理装置から送信される障害内容を表すイベントを用いて障害箇所及び原因を解析するイベント・コリレーション技術がある（例えば、特許文献１）。イベント・コリレーション技術は、障害時に管理サーバに上げられるイベントの相関を利用して根本原因を推測するもので、古くからネットワークシステムの障害の診断に用いられている技術である。
【０００４】
また、非特許文献１には、当該技術と障害時のイベントの組み合わせと推測される根本原因を対にしてルール化することで、エキスパートシステムをベースとした推論エンジンを用いて根本原因を迅速に突き止める技術が開示されている。
【０００５】
このエキスパートシステムをベースとするイベント・コリレーションにおいては、障害解析の対象とするＩＴシステムの規模が多くなったり、ルールが多くなったりすると、特許文献２における推論エンジンのパターンマッチングに用いるルール間の関係を接続したルール解析網に必要となるワーキングメモリのサイズが大きくなる。このルール解析網の一つとして、コードブックと呼ばれる、障害時にあげられるイベントと考えられる根本原因の関係をマトリックスと呼ばれる行列形式に表し、このマトリックスを最適化して分割・最小化する技術が特許文献２にて開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】米国特許第６２４９７５５号
【特許文献２】米国特許第６８６８３６７号
【非特許文献】
【０００７】
【非特許文献１】“Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”，ARTIFICIAL INTELLIGENCE，Vol．19，no．1，1982，pp．17-37
【発明の概要】
【発明が解決しようとする課題】
【０００８】
イベント・コリレーション技術は、障害時に障害が発生した装置から管理サーバに通知されるイベントの組み合わせパターンから障害の原因候補を絞り込む有効な技術であるが、組み合わせるべきイベントの数及び根本原因の数が多くなると、これらの組み合わせパターンが膨大となり、実際に発生したイベント群と、ルールとして定義されたイベントとの組み合わせのパターンマッチングを行うための検索空間が膨大なものとなる。この結果、解析結果を導くのに時間を要してしまうだけでなく、検索空間が膨大になることに起因してプロセッサが解析の実行時に参照するメモリ（ワーキングメモリ）のサイズが肥大化する問題があった。
【０００９】
このような問題に対して、例えば特許文献２には、イベントの組み合わせと根本原因との関係をマトリックス表にし、このマトリックス表を最適化して小さくすることが開示されている。しかしながら、かかる最適化は定義イベントの数やルールの数に対するマトリックス表の肥大化に対する解決策ではなく、イベントの組み合わせと根本原因との冗長な関係を省くものであり、最適化の対象が異なる。また、ルール解析網の構造、対象システムの規模、すなわち取り扱うイベントの数やルールの数に、解析処理時のワーキングメモリのサイズが依存しないことが望ましい。
【００１０】
本発明は以上の点を考慮してなされたもので、対象システムの定義イベントの数やルールの数によらず、一定のワーキングメモリサイズを保ちながら、少ない解析時間で解析処理を実行し得る管理装置及び管理方法を提案しようとするものである。
【課題を解決するための手段】
【００１１】
かかる課題を解決するため本発明においては、１又は複数の情報処理装置を管理する管理装置において、前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する２次記憶装置と、前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信するネットワークインタフェースと、前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断するプロセッサと、前記プロセッサのワークメモリとして利用されるメモリとを有し、前記プロセッサは、予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除することを特徴とする。
【００１２】
また本発明においては、１又は複数の情報処理装置を管理する管理方法において、前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する第１のステップと、前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信する第２のステップと、前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断する第３のステップとを有し、前記第１のステップでは、予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、前記第３のステップでは、前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、障害解析を行う対象の情報処理システムの装置・構成要素が大規模化したり、取り扱うルールの数が増えたりした場合においても、受信したイベントと事前に定義されたルールの条件に示されたイベントとの組み合わせのパターンマッチングにもとづく解析処理の実行において、一定サイズのワーキングメモリにて、効率良く実現できる。
【図面の簡単な説明】
【００１４】
【図１】図１は、本実施の形態による情報処理システムの全体構成を模式的に示すブロック図である。
【図２】図２は、管理対象装置群の構成例を示すブロック図である。
【図３】図３は、イベント通知の構成例を示す概念図である。
【図４】図４は、ルール情報の構成例を示す概念図である。
【図５】図５は、ルール情報の具体的な構成例を示す概念図である。
【図６】図６は、ルール情報の具体的な構成例を示す概念図である。
【図７】図７は、ルール解析網の一部構成例を示す概念図である。
【図８】図８は、イベントオブジェクトの構成例を示す概念図である。
【図９】図９は、条件オブジェクトの構成例を示す概念図である。
【図１０】図１０は、ルールオブジェクトの構成例を示す概念図である。
【図１１】図１１は、結論オブジェクトの構成例を示す概念図である。
【図１２】図１２は、ルールセグメントの構成例を示す概念図である。
【図１３】図１３は、本実施の形態による条件オブジェクトの構成例を示す概念図である。
【図１４】図１４は、イベント索引情報の説明に供する概念図である。
【図１５】図１５は、イベント索引情報の構成例を示す概念図である。
【図１６】図１６は、セグメント参照情報の構成例を示す概念図である。
【図１７】図１７は、セグメント結合情報の構成例を示す概念図である。
【図１８】図１８は、セグメント参照履歴情報の構成例を示す概念図である。
【図１９】障害原因解析処理の処理手順を示すフローチャートである。
【図２０】前処理の処理手順を示すフローチャートである。
【図２１】第１の関連情報テーブルの構成例を示す概念図である。
【図２２】第２の関連情報テーブルの構成例を示す概念図である。
【図２３】関連情報テーブル作成処理の処理手順を示すフローチャートである。
【図２４】ルール実行リスト作成処理の処理手順を示すフローチャートである。
【図２５】ルール情報依存関係管理テーブルの構成例を示す概念図である。
【図２６】ルール情報依存関係管理テーブル作成処理の処理手順を示すフローチャートである。
【図２７】ルールセグメント等作成処理の処理手順を示すフローチャートである。
【図２８】解析処理の処理手順を示すフローチャートである。
【図２９】ルールセグメントの状態遷移の説明に供する概念図である。
【発明を実施するための最良の形態】
【００１５】
以下図面について、本発明の一実施の形態を詳述する。
【００１６】
なお、以下においては、例えばサーバ装置、ストレージサブシステム、プリンタ、スキャナ、パソコン、ＰＤＡ及び又は携帯電話などのネットワーク通信を行う通信機能が搭載された装置と、ルータ、プロキシーサーバ及び又はスイッチなどのネットワーク通信を中継する機能が搭載された装置とを包括的に情報処理装置と呼ぶものとする。またサーバ装置としては、例えばＷｅｂサーバ、ファイルサーバ、ネームサーバ、ディレクトリサーバ又は認証サーバ等が考えられるが、何らかのサービスを提供する装置であればすべて本明細書におけるサーバ装置に含まれる。
【００１７】
また以下においては、「ＡＡＡテーブル」、「ＡＡＡリスト」、「ＡＡＡＤＢ」又は「ＡＡＡキュー」等の表現にて各種情報を説明するが、これら情報はテーブル、リスト、ＤＢ又はキュー等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ＡＡＡテーブル」、「ＡＡＡリスト」、「ＡＡＡＤＢ」及び「ＡＡＡキュー」等を「ＡＡＡ情報」と呼ぶことがある。
【００１８】
また各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」及び「番号」という表現を用いるが、これらの表現は装置や部品などの物理的な存在に限らず、論理的な存在についても区別をつけるために割り当てられているものであるため、お互いに置換が可能である。
【００１９】
さらに以下においては、各種処理の処理主体を「プログラム」として説明するが、実際上は、そのプログラムに基づいてその処理をプロセッサが実行することは言うまでもない。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。さらにプログラムの一部または全ては専用ハードウェアによって実現されてもよい。さらに各種プログラムは、プログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００２０】
（１）本実施の形態による情報処理システムの構成
図１において、１は全体として本実施の形態による情報処理システムを示す。図中『」』のマークは、対応部位が複数存在することを意味する。情報処理システム１は、管理サーバ２と、１又は複数の情報処理装置４からなる管理対象装置群３とを備えて構成される。
【００２１】
管理サーバ２は、管理対象装置群３を構成する各情報処理装置４を管理及び監視するサーバ装置であり、プログラム及び制御情報などの電子データを記憶するための記憶領域を提供するメモリ１０と、メモリ１０の記憶容量の不足を補助するための２次記憶装置１１と、メモリ１０上に存在する電子データを用いて管理対象装置群３において発生した障害の解析処理を行うプロセッサ１２と、管理対象装置群３と管理用ネットワーク５を介して電子データの送受信を行うためのネットワークインタフェース１３（以下、インタフェースはＩ／Ｆと略す場合がある）とを備えて構成される。
【００２２】
メモリ１０は、例えば半導体メモリ、又は磁気を用いてデータを格納する磁気メモリから構成され、各種プログラム及び各種制御情報を保持するために用いられる。後述する部分ルール解析網２０、イベント索引情報２１、管理プログラム２２及びイベントキュー２３もこのメモリ１０に格納されて保持される。
【００２３】
２次記憶装置１１は、例えばハードディスク装置等の磁気ディスク装置や、外付けのストレージサブシステム、又は、磁気ディスク装置及び外付けのストレージサブシステムの両方から構成され、各種プログラムや各種制御情報を永続的に保持するために用いられる。後述するルール情報３０、管理対象構成情報３１、ルールセグメントレポジトリ３２、セグメント結合情報３３、イベントオブジェクトテーブル３４及びセグメント参照履歴情報３５もこの２次記憶装置１１に格納されて保持される。
【００２４】
プロセッサ１２は、管理サーバ２全体の動作を制御する機能を有するもので、メモリ１０や２次記憶装置１１に格納された電子データに基づいて各種の演算処理や制御処理を実行する。またネットワークインタフェース１３は、管理用ネットワーク５に対するインタフェースであり、例えばＮＩＣ（Network Interface Card）やＬＡＮ（Local Area Network）ボードなどから構成される。
【００２５】
なお、管理サーバ２は、図示しない入出力装置をも有する。入出力装置の例としては、ディスプレイ、キーボード及びポインタデバイスが考えられるが、これ以外の装置であっても良い。また、入出力装置の代替としてシリアルインタフェースやイーサネット（登録商標）インタフェースを入出力とし、当該インタフェースにディスプレイ、キーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替しても良い。
【００２６】
管理対象装置群３は、上述のように１又は複数の情報処理装置４から構成される。図２は、管理対象装置群３の一構成例を示す。この例では、管理対象装置群３は、複数のサーバ４０（「SERVER1」、「SERVER」、……）と、ネットワーク４１と、１つのストレージ装置４２（「STORAGE1」）とから構成されている。そしてこの図２では、ストレージ装置４２のボリュームがサーバ４０の「ISCSI INITIATOR01」というＨＡＢ（Host Bus Adapter）４０Ａを介してＩＳＣＳＩ（Internet Small Computer System Interface）プロトコルにてＳＣＳＩディスク４０Ｂ（「SCSIDISK01」、「SCSIDISK03」）として提供されている場合を例示している。なお図２において、ストレージ装置４２の「Controller01」は、ストレージ装置４２を制御するプロセッサであり、ＩＳＣＳＩポートを備えている。
【００２７】
管理用ネットワーク５は、ＬＡＮ（Local Area Network）、インターネット又は専用回線などから構成される。管理用ネットワーク５は、情報処理装置４間の通信を行うためのネットワークと別なネットワークであってもよく、また部分的又は完全に同一なネットワークであっても良い。
【００２８】
以下、管理対象装置群３を管理し、本願実施の形態における表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバ２が表示用情報を表示する場合は管理サーバ２が管理システムであり、管理サーバ２と表示用計算機の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバ２と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含める）が管理システムである。
【００２９】
（２）本実施の形態による障害原因解析機能
次に、管理サーバ２に搭載された障害原因解析機能について説明する。これに際して、まず、イベント通知、ルール情報及びルール解析網について説明する。
【００３０】
（２−１）イベント通知、ルール情報及びルール解析網
図３は、管理サーバ２が管理・監視の対象とする情報処理装置（以下、これを管理対象装置とも呼ぶ）４に障害が発生したときに、当該管理対象装置４から管理サーバ２に送信されるイベント通知５０の概略構成を示す。この図３からも明らかなように、イベント通知５０は、イベントＩＤ５０Ａ、イベント検知時刻５０Ｂ、発生元装置ＩＤ５０Ｃ、発生元部位ＩＤ５０Ｄ及びイベント内容５０Ｅと、詳細情報５０Ｆとを含んで構成される。
【００３１】
このうちイベントＩＤ５０Ａは、そのとき発生したイベントに対して予め付与されているＩＤを表し、イベント検知時刻５０Ｂは、そのイベントが発生した時刻を表す。また発生元装置ＩＤ５０Ｃは、そのイベントが発生した情報処理装置４に対して予め付与されていた識別子であり、発生元部位ＩＤ５０Ｄは、その情報処理装置４におけるそのイベントが発生した部位に対して予め付与されていた識別子を表す。さらにイベント内容５０Ｅは、そのイベントの内容を表す。詳細情報５０Ｆは、そのイベントに関する詳細な情報を表す。この詳細情報５０Ｆには、イベントに関する上述の情報以外の情報（例えばメッセージ）などが含まれる。
【００３２】
従って図３の例の場合、図２の環境において、「SERVER1」というサーバ４０の「SCSIDISK01」という部位の状態がエラーに変化した（「Status Change To ERROR」）ことが「2000-1-1 00:00:00」にそのサーバ４０又はその管理装置（図示せず）により検出され、かかるイベントのイベントＩＤが「010000020」であることが示されている。
【００３３】
一方、図４は、ルール情報３０の構成を示す。ルール情報３０は、イベントの組み合わせを条件とし、この組み合わせに対する根本原因を推論の結論とするルールに関する情報であり、予めシステム管理者などにより複数作成されて管理サーバ２に登録される。後述のように、管理サーバ２は、障害発生時に障害が発生した管理対象装置４又はその管理装置等から送信されるイベント通知５０（図３）と、このルール情報３０とに基づいて、障害の根本原因を推論する。
【００３４】
ルール情報３０は、例えば図４に示すように、ルール識別情報６１、条件部６２及び結論部６３から構成される。このうちルール識別情報６１は、ルールを一意に識別するための識別子であり、ルール情報３０ごとに異なる値が付与される。
【００３５】
条件部６２は、１又は複数の条件６４から構成される。また各条件６４は、それぞれイベント情報６５及び条件演算子６６から構成される。条件６４のイベント情報６５は、イベントに関する情報であり、対応するイベントのイベントＩＤ６５Ａと、そのイベントが発生する部位を表す装置部位情報６５Ｂと、イベント内容６５Ｃとを含む。
【００３６】
イベントＩＤ６５Ａ及びイベント内容６５Ｃは、イベント通知５０（図３）において使用されるものと同じものが使用され、装置部位情報６５Ｂは、イベント通知５０において使用される発生元装置ＩＤ５０Ｃ及び発生元部位ＩＤ５０Ｄを組み合わせたものが使用される。
【００３７】
また条件演算子６６は、対応するイベント情報６５に対する演算を指定する演算子であり、「受信しないこと」を条件とする場合の「NOT」等の演算子を含む。条件演算子６６は省略可能であり、省略された場合には、イベント情報６５を「受信すること」を条件とすることを表す。
【００３８】
結論部６３は、「if-then」形式のルールの結論を示すイベント情報６７と、条件部６２に対する評価の算出の仕方を指定する結論演算子６８とから構成される。複数のルールで共通の結論を導くことも可能であるため、複数のルール情報３０において共通の結論部６３が用いられることがある。結論演算子６８は、そのような複数ルール間で共有される結論部６３である場合に、それらのルールにおけるマッチング度をどのように共通の結論部６３に対するマッチング度として反映させるかを指定する演算子である。例えば、複数ルールの中でマッチング度が最大のものをその結論のマッチング度としたり、複数ルールのマッチング度を均等に重み付けして、全ルールの条件におけるマッチング度という形で評価する演算がある。なおこの結論演算子６８の種類は、本実施の形態に制限を与えるものではない。
【００３９】
結論部６３のイベント情報６７は、イベントＩＤ６７Ａ、装置部位情報６７Ｂ及びイベント内容６７Ｃを含む。これらイベントＩＤ６７Ａ、装置部位情報６７Ｂ及びイベント内容６７Ｃは、条件部６２のイベント情報６５におけるイベントＩＤ６５Ａ、装置部位情報６５Ｂ及びイベント内容６５Ｃと同様のものであるため、その詳細については説明を省略する。
【００４０】
ルール情報３０の具体例を図５に示す。図５は、図２の環境において、「STORAGE1」というストレージ装置４２が「SERVER1」というサーバ４０に提供している「SCSIDISK01」というボリュームの状態がエラーに変化した場合に、その状態変化の根本原因が「SERVER1」のＩＳＣＳＩ通信エラーであると推論するよう規定したルールについての具体例である。すなわち図５のルール情報３０では、以下の事項が指定されている。
【００４１】
（ａ）条件部６２では、イベントＩＤが「010000020」のイベントであって、「SERVER1」の「SCSIDISK01」において「状態がエラーに変化した（「Status Change To UNKNOWN」）」というイベントが発生したことを知らせるイベント通知５０を受信した場合のルールであることが規定されている（条件６４のイベント情報６５を参照）。なお、エラー状態は少なくとも装置又は部位が使えない状態であることを含むほか、一般的にエラーとされる状態を含めても良い。以後で説明する他のケースについても特に記載しない限りエラー状態は前述の意味であるものとする。
【００４２】
（ｂ）結論部６３では、かかるイベント通知５０を受信した場合、イベントＩＤが「910000020」のイベントであって、「SERVER1」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０Ａにおける「ＩＳＣＳＩ通信エラー（「RC_COM_ERROR」）」というイベントが原因であると推測するよう規定されている（結論部６３のイベント情報６７を参照）。
【００４３】
またルール情報３０の他の具体例を図６に示す。図６は、図２の環境において、「SERVER1」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０ＡにおいてＩＳＣＳＩ通信エラーが発生し、「SERVER2」というサーバ４０の「ISCSIINITIATOR01」というＨＡＢ４０ＡにおいてＩＳＣＳＩ通信エラーが発生し、さらに「STORAGE1」というストレージ装置４２の「CONTROLLER01」というコントローラ４２Ａの状態がエラーに変化した発生し場合に、これらの状態変化の根本原因が「STORAGE1」の「CONTROLLER01」の障害であると推論するよう規定されたルールについての具体例である。すなわち図６のルール情報３０では、以下の事項が指定されている。
【００４４】
（ａ）条件部６２では、イベントＩＤが「910000020」のイベントであって、「SERVER1」の「ISCSIINITIATOR01」において「ＩＳＣＳＩ通信エラー（Status Change To COM_ERROR）」というイベントが発生したというイベント通知５０と、イベントＩＤが「910000020」のイベントであって、「SERVER2」の「ISCSIINITIATOR01」において「ＩＳＣＳＩ通信エラー（Status Change To COM_ERROR）」というイベントが発生したというイベント通知５０と、イベントＩＤが「040000020」のイベントであって、「STORAGE1」の「CONTROLLER01」において「エラー（Status Change To ERROR）」というイベントが発生したというイベント通知５０とを受信した場合のルールであることが規定されている（条件部６２の各条件６４のイベント情報６５を参照）。
【００４５】
なお、このイベント情報６５のイベントＩＤは、図５のルール情報３０における結論部６３のイベント情報６７と同一であり、他のルール情報３０の結論部６３にて定義されるイベント情報６７は、管理対象装置群３より送信されるイベント通知５０とは異なり、管理サーバ２内部のみで作成、利用される。このような図５の結論部６３にて指定されるイベント情報６７を、管理対象装置群３より送信されるイベント通知５０と特に区別して内部イベント情報と呼ぶ。
【００４６】
（ｂ）結論部６３では、上述のようなイベント通知５０を受信した場合、イベントＩＤが「940003020」のイベントであって、「STORAGE1」の「CONTROLLER01」における「エラー（RC_ERROR）」というイベントが原因であると推測するよう規定されている（結論部６３のイベント情報６７を参照）。
【００４７】
他方、図７は、ルール解析網７０の構成例を示す。以下においては、管理対象装置群３に含まれるいずれかの管理対象装置４から管理サーバ２に送信されるイベント通知５０を元に、管理サーバ２の管理プログラム２２が推論を行い、現在発生している事象を推論する管理システムにおいて、管理プログラム２２が推論処理において参照する複数のルール情報３０間の関係（ルールＡ及びルールＢの結論が同じ場合には、結論を介してルールＡ及びルールＢが結合されるなどの関係）を結びつけたルール結合ネットワークをルール解析網７０と呼ぶものとする。
【００４８】
図７は、後述のように２次記憶装置１１に格納されたすべてのルール情報３０に基づいて、関連するイベント情報６５，６７を互いに結合させて構築されたルール解析網７０を模式的に示したものである。図中の双方向の矢印は互いに参照関係を有しており、どちらの方向からも接続先のオブジェクト７１（７１Ａ〜７１Ｄ）を辿ることができることを示している。このようなルール解析網７０を構成するオブジェクト７１としては、イベントオブジェクト７１Ａ、条件オブジェクト７１Ｂ、ルールオブジェクト７１Ｃ及び結論オブジェクト７１Ｄが存在する。
【００４９】
イベントオブジェクト７１Ａは、ルール情報３０の条件部６２の条件６４に含まれるイベント情報６５（図４）、又は、結論部６３に含まれるイベント情報６７に基づいて生成されるオブジェクトであり、図８に示すように、イベントＩＤ７１ＡＡ、装置部位情報７１ＡＢ及びイベント内容７１ＡＣをそれぞれ含む。このうちイベントＩＤ７１ＡＡは、対応するイベント情報６５，６７のイベントＩＤ６５Ａ，６７Ａをコピーしたものである。また装置部位情報７１ＡＢは、そのイベント情報６５，６７の装置部位情報６５Ｂ，６７Ｂにより認識されるイベントの発生元装置及びその発生元部位をそれぞれ表すコードを組み合わせた情報である。さらにイベント内容７１ＡＣは、そのイベント情報６５，６７のイベント内容６５Ｃ，６７Ｃをコピーしたものである。ただし、これ以外の情報を含んでいても。
【００５０】
また条件オブジェクト７１Ｂは、ルール情報３０の条件部６２を構成する各条件６４（図４）に基づいてそれぞれ生成されるオブジェクトであり、図９に示すように、条件ＩＤ７１ＢＡ及び条件演算子７１ＢＢを含む。このうち条件ＩＤ７１ＢＡは、対応する条件６４を識別するための識別情報である。また条件演算子７１ＢＢは、対応する条件６４に含まれる条件演算子６６（図４）をコピーしたものである。
【００５１】
ルールオブジェクト７１Ｃは、ルール情報３０そのものに対応するオブジェクトであり、図７に示すように、条件オブジェクト７１Ｂと結論オブジェクト７１Ｄとの関係を結びつけるオブジェクトとして存在する。ルールオブジェクト７１Ｃは、図１０に示すように、ルール識別情報７１ＣＡを含む。このルール識別情報７１ＣＡは、対応するルール情報３０のルール識別情報６１（図４）をコピーしたものである。
【００５２】
さらに結論オブジェクト７１Ｄは、ルール情報３０の結論部６３（図４）に基づいて生成されるオブジェクトであり、図１１に示すように、結論ＩＤ７１ＤＡ及び結論評価演算子７１ＤＢを含む。このうち結論ＩＤ７１ＤＡは、対応する結論部６３を識別するための識別情報である。また結論評価演算子７１ＤＢは、結論を共有する複数ルールにおけるマッチング度の評価の仕方を指定するための演算子である。
【００５３】
ルール情報３０に基づく推論導出の解析処理は、通常、解析時のルールとのパターンマッチングを高速化するために、すべてのルール情報３０に基づいて図７に示すルール解析網７０を構築し、受信したイベント通知５０に基づき認識されるイベントに対応するイベントオブジェクト７１Ａを検索して関連するルールオブジェクト７１Ｃを辿り、該当の結論オブジェクト７１Ｄのマッチング度をそれぞれ評価することで行われる。
【００５４】
ただし、すべてのルール情報３０に基づくルール解析網７０をメモリに載せてワーキングメモリとして参照すると、メモリサイズを逼迫して、かかる処理を実行する計算機のリソースを大量消費して装置を不安定にする要因になる。そこで、本実施の形態においては、ルール解析網７０を幾つかに分断した以下に説明するような部分ルール解析網を構築し、必要な部分ルール解析網のみをメモリ１０上に載せて解析処理を実行する。
【００５５】
図１２は、ルール解析網７０を１つのルール情報３０に相当する単位に分割したセグメント（以下、これをルールセグメントと呼ぶ）７２のオブジェクト構成を模式的に示したものである。ルールセグメント７２は、１つのルールオブジェクト７２Ｃをもち、ルールオブジェクト７２Ｃに対応するルール情報３０に従って条件部６２がもつ１つ以上の条件６４に対応する条件オブジェクト７２Ｂと双方向の関連をもち、条件オブジェクト７２Ｂはそれぞれが保持するイベントオブジェクト７２Ａとの双方向の関連をもつ。
【００５６】
また、ルールセグメント７２は、ルール情報３０の結論部６３に対応する結論オブジェクト７２Ｄと双方向の関連をもち、結論オブジェクト７２Ｄは結論の内容を表すイベントオブジェクト７２Ａとの双方向の関連をもつ。このようにルールセグメント７２の構成において、条件オブジェクト７２Ｂとして少なくとも１つ以上の任意の数の条件（ただし、そのルールオブジェクト７２が持つ条件数を超えない）を保持するため、１つのルール情報３０に対して条件部６２の条件６４が複数のルールセグメント７２に分割されていても構わないし、一つのルールセグメント７２にルール情報３０がもつ条件部６２の条件６４がすべて含まれていても構わない。ルールセグメント７２を構成するイベントオブジェクト７２Ａ、結論オブジェクト７２Ｄ及びルールオブジェクト７２Ｃはルール解析網７０を構成するイベントオブジェクト７１Ａ、結論オブジェクト７１Ｄ及びルールオブジェクト７１Ｃとそれぞれ同一のものである。
【００５７】
図１３は、本実施の形態による条件オブジェクト７２Ｂの構成を示す。この条件オブジェクト７１Ｂは、図９について上述した条件オブジェクト７１Ｂに代えて本実施の形態において使用されるオブジェクトであり、条件ＩＤ７２ＢＡ、条件演算子７２ＢＢ、ロード状態７２ＢＣ及びイベントＩＤ７２ＢＤの各情報を含んで構成される。
【００５８】
このうち条件ＩＤ７２ＢＡ及び条件演算子７２ＢＢは、図９について上述した条件オブジェクト７１Ｂの条件ＩＤ７１ＢＡ及び条件演算子７１ＢＢと同様ものである。またロード状態７２ＢＣは、その条件オブジェクト７２Ｂがメモリ上に読み込まれているかどうかを表す情報である。さらにイベントＩＤ７２ＢＤは、接続先のイベントオブジェクト７２ＡのイベントＩＤを表す。このイベントＩＤ７２ＢＤは、イベントオブジェクト７２Ａと条件オブジェクト７２Ｂの相互参照関連を作成するときに使用する。
【００５９】
（２−２）本実施の形態による障害原因解析機能
次に、管理サーバ２に搭載された本実施の形態による障害原因解析機能について説明する。本実施の形態の場合、管理サーバ２には、予め与えられた１つ以上のルール情報３０に基づいて、ルール情報３０に記述された条件と、管理対象装置群３において発生したイベントとの組み合わせのパターンマッチングを行い、どれだけパターンが一致しているかを評価する障害原因解析機能が搭載されている。そして本実施の形態による障害原因解析機能は、解析処理時に使用されるワーキングメモリのサイズを一定サイズ以下に抑える手法として、以下の手順で障害原因の解析機処理を行う点を特徴の１つとしている。
【００６０】
（ａ）情報処理システム１を運用管理する前に、登録されているすべてのルール情報３０を読み込み、ルール間の依存関係を調べた上で、依存関係に基づいたルール情報３０の順番でルールセグメント７２を作成する。またルール（ルールセグメント７２）間の関係を表す情報をセグメント結合情報として作成すると共に、受信するイベント通知５０（図３）に対する索引情報としてイベント索引情報を作成する。
【００６１】
（ｂ）情報処理システム１の運用管理している間に障害が発生した場合に、その障害が発生した管理対象装置４等から送信されるイベント通知５０に基づき、（ａ）にて生成したイベント索引情報を元に、必要なルールセグメント７２と、このルールセグメント７２と関連するルールセグメント７２をメモリ１０（図１）読み込み、これらのルールセグメント７２を（ａ）にて生成したセグメント結合情報を元に、ルールセグメント７２間を結合した、受信イベントに対する解析網である部分ルール解析網を構築する。また構築した部分ルール解析網を用いて、受信したイベント通知５０により認識されるイベントと、ルールの条件に示されたイベントとの組み合わせとのパターンマッチングによる解析処理を実行する。この際、参照されたルールセグメント７２に関する参照履歴情報を作成する。
【００６２】
（ｃ）上記（ｂ）で構築した部分ルール解析網が占めるメモリサイズがある一定のサイズよりも大きくなった場合に、（ｂ）で作成されたルールセグメント７２の参照履歴情報を元に、参照頻度が少ないルールセグメント７２を選択し、これをメモリ１０上から掃き出すことによりメモリ１０内の記憶領域を解放して、ワーキングメモリのサイズを一定サイズ以下に保つ。
【００６３】
以上のような本実施の形態による障害原因解析機能を実現するための手段として、管理サーバ２のメモリ１０には、図１に示すように、部分ルール解析網２０、イベント索引情報２１、管理プログラム２２及びイベントキュー２３が格納されて保持され、２次記憶装置１１には、ルール情報３０、管理対象構成情報３１、ルールセグメントレポジトリ３２、セグメント結合情報３３、イベントオブジェクトテーブル３４及びセグメント参照履歴情報３５もこの２次記憶装置に格納されて保持される。
【００６４】
このうち部分ルール解析網２０は、管理プログラム２２が障害の解析処理を行うときに参照するルールの関係情報を持つルール解析網である。この部分ルール解析網２０は、障害が発生したときに管理対象装置４から与えられるイベント通知５０（図３）に基づいて、その障害に関連するルールセグメント７２（図１２）を組み合わせることにより構築される。
【００６５】
またイベント索引情報２１は、図１４に示すように、管理対象装置４からのイベント通知５０を受信したときに、解析処理を実行する際に使用すべきルールセグメント７２を検索するための情報（イベントとこれに関連するルールセグメント７２との関係を表す情報）であり、管理プログラム２２がルール情報３０を入力としてルールセグメント７２を作成した場合に一緒に生成される。なおメモリ１０には、異なる複数のイベント索引情報２１を格納することができる。
【００６６】
このイベント索引情報２１は、図１５に示すように、イベントＩＤ２１Ａ、セグメントＩＤ２１Ｂ及び読込み状態２１Ｃの各情報を含む。このうちイベントＩＤ２１Ａは、各種イベントにそれぞれ付与された識別子を表し、イベント通知５０において使用されるイベントＩＤと同じものが適用される。またセグメントＩＤ２１Ｂは、対応するイベントＩＤを含むイベント通知５０を受信したときの解析処理に使用すべきルールセグメント７２の識別子（セグメントＩＤ）を表す。
【００６７】
さらに読込み状態２１Ｃは、そのイベントＩＤ２１Ａが付与されたルールセグメント７２がメモリ１０に読み込まれているか否かを表す。例えばそのオブジェクトがメモリ１０に読み込まれている場合、読込み状態が「LOADED」に設定され、そのオブジェクトがメモリに読み込まれていない場合、読込み状態が「NOT」に設定される。
【００６８】
従って、図１４の例では、例えば「Z1-1_ID」というイベントＩＤのイベントが発生したことを知らせるイベント通知５０を受信した場合には、「X1-10a_seg」というセグメントＩＤのルールセグメント７２を用いて解析処理を行うべきことが規定されており、そのルールセグメント７２は既にメモリ１０に読込み済みであることが示されている。
【００６９】
管理プログラム２２は、いずれかの管理対象装置４からのイベント通知５０の受信や、管理対象装置４からの情報収集によるイベントの検知に基づき、検知したイベントを入力として管理対象装置４で発生した事象を解析するプログラムである。
【００７０】
管理プログラム２２は、以下に説明する各種の処理に加えて、各管理対象装置４の状態（例えば、障害発生の有無、その管理対象装置４で行われた設定変更の有無、その管理対象装置４の性能に関する状態）を管理する。
【００７１】
具体的に、管理プログラム２２は、ネットワークインタフェース１３を介して管理対象装置４から障害発生の有無や、その管理対象装置４の設定情報、及び性能情報などの管理情報を受信する。そして管理プログラム２２は、受信した管理情報に基づいて各管理対象装置４の状態を判断し、その判断結果や各管理対象装置４の状態を、ディスプレイ装置等へ表示し又は予め設定されたユーザに電子メールにて通知する。なお、管理プログラム２２が、管理サーバ２が受信した管理対象装置４への設定要求を受信し、当該要求に基づいて対応する管理対象装置４への設定を行うようにしても良い。
【００７２】
イベントキュー２３は、管理対象装置４又はその管理装置から与えられるイベント通知５０を順番に格納するためのキューである。管理プログラム２２は、このイベントキュー２３に格納されたイベント通知５０に応じた処理を、当該イベントキュー２３に格納された順番で処理する。
【００７３】
一方、ルール情報３０は、図４〜図６について上述したように、管理対象装置４においてどのようなイベントが発生したときにどのような障害が発生したと推理すべきかといった、発生した障害の根本原因解析を行うためのルールに関する情報である。２次記憶装置１１には、このようなルール情報３０が予め複数格納される。
【００７４】
管理対象構成情報３１は、管理対象装置群３に含まれる各管理対象装置４の識別子と、管理用ネットワーク５上でその管理対象装置４にアクセスするために使用されるＩＰアドレス等の識別情報及び認証情報と、その管理対象装置４の管理用ネットワーク５における接続状態及び論理的な関係情報（例えば接続関係や、サーバ・クライアントの関係、包含関係）と、その管理対象装置４の構成に関する情報とを含む。
【００７５】
具体的には、管理対象構成情報３１は、以下の情報を含む。
（ａ）各管理対象装置４の識別子。これら識別子は、管理対象装置４と通信するための識別子、例えばＩＰアドレス、ＦＱＤＮ（Fully Qualified Domain Name）、又はホスト名等が考えられる。
（ｂ）管理対象装置４の種別（例えば、ストレージサブシステム、スイッチ装置、サーバ装置等）と、当該管理対象装置４を構成する部位の種別。
（ｃ）管理対象装置４を構成する部位の情報及び装置と部位、または部位と部位の包含関係。
（ｄ）ネットワーク通信を行うための部位については、接続相手となる部位。
（ｅ）管理対象装置４の設定。
【００７６】
なお、管理対象構成情報３１は以下の処理により生成又は更新されることが考えられるが、他の処理から生成されたものであってもよい。
（ａ）管理プログラム２２が、管理対象装置４から受信したその管理対象装置４についての構成情報及び設定情報に基づいて管理対象構成情報３１を生成又は更新する。
（ｂ）管理プログラム２２が管理対象装置４の設定を行える場合は、管理プログラム２２が管理サーバ２の入力装置を介して受信した装置設定情報を装置に設定すると共に、管理対象構成情報３１を生成又は更新する。
【００７７】
また本実施の形態においては、管理対象構成情報３１が２次記憶装置１１に格納されているものとして説明するが、２次記憶装置１１以外の例えばメモリ１０に格納されていても構わない。
【００７８】
ルールセグメントレポジトリ２３は、管理プログラム２２に基づきルール情報３０を元に作成された１つ以上のルールセグメント７２を格納して管理するためのレポジトリである。このルールセグメントレポジトリ２３には、管理対象装置群３において発生したイベントに応じてメモリ１０上に読込んだ際の参照履歴情報であるセグメント参照情報７３も格納される。
【００７９】
セグメント参照情報７３は、管理サーバ２が各ルールセグメント７２の格納位置を管理するための情報であり、例えば図１６に示すように、セグメントＩＤ７３Ａ、格納場所７３Ｂ及びルール識別情報７３Ｃの各情報から構成される。
【００８０】
このうちセグメントＩＤ７３Ａは、対応するルールセグメント７２に対して付与された識別子（以下、これをセグメントＩＤと呼ぶ）であり、格納場所７３Ｂは、ルールセグメントレポジトリ３２における対応するルールセグメント７２の格納場所を表す。このルールセグメント７２の格納場所７３Ｂは、ファイル名などのリソースの位置を特定可能なＵＲＮ（Universal Resource Name）と、そのリソース内での格納位置（論理アドレス、物理アドレスなど）との組み合わせで表現される。
【００８１】
またルール識別情報７３Ｃは、そのルールセグメント７２に対応するルール情報３０の識別情報（以下、これをルール情報識別子と呼ぶ）を表す。従って、図１６の例では、「X1-10a_seg」というセグメントＩＤのルールセグメント７２は、「file://C:\ :\seg_repo01」というファイル内の「1af00...」というアドレス位置に格納されており、このルールセグメントが含んでいるルール情報３０の識別子は「X1」であることが示されている。
【００８２】
なお、ルールセグメント７２の格納場所は、ファイルシステム上のファイルであっても、データベースシステムのデータベースであっても、ネットワーク上のリソース（ファイルシステム、ブロックストレージ）であっても良く、その格納形態については問わない。ただし、格納場所７３Ｂが特定するのに十分な情報が使用されることが要件である。
【００８３】
セグメント結合情報３３は、ルールセグメント７２の管理サーバの２次記憶装置１１内の各ルール情報３０に基づき形成された各オブジェクト（イベントオブジェクト７２Ａ、条件オブジェクト７２Ｂ、ルールオブジェクト７２Ｃ及び結論オブジェクト７２Ｄ）がどのルールセグメント７２のどのオブジェクトに結合されるかなどを管理するための情報であり、図１７に示すように、オブジェクト種別３３Ａ、識別情報３３Ｂ、結合先セグメントＩＤ３３Ｃ、結合先オブジェクトＩＤ３３Ｄ及び読込み状態３３Ｅの各情報から構成される。
【００８４】
このうちオブジェクト種別３３Ａは、対応するオブジェクトの種別（「イベント」、「条件」、「ルール」又は「結論」）を表し、識別情報３３Ｂは、そのオブジェクトの識別子（以下、これをオブジェクトＩＤと呼ぶ）を表す。また結合先セグメントＩＤ３３Ｃは、そのオブジェクトが属するルールセグメント７２のセグメントＩＤを表し、結合先オブジェクトＩＤ３３Ｄは、そのルールセグメント７２においてそのオブジェクトが結合されるオブジェクトのオブジェクトＩＤを表す。
【００８５】
さらに読込み状態３３Ｅは、そのオブジェクトが、現在、メモリ１０に読み込まれているか否かを表す。例えばそのオブジェクトがメモリ１０に読み込まれている場合、読込み状態が「LOADED」に設定され、そのオブジェクトがメモリに読み込まれていない場合、読込み状態が「NOT」に設定される。
【００８６】
従って、図１７の場合、図７を前提として、例えば「Y1」という結論オブジェクト７２Ｄ（図１２）については、「X1」というルールオブジェクト７２Ｃ（図１２）を含む「X1-10a-seg」というルールセグメント７２と関連を持ち、このルールセグメント７２内部の「X1_ID」というルールオブジェクト７２Ｃと結合すること、及び、このルールセグメント７２は既にメモリ１０に読込み済み（「LOADED」）であることが示されている。
【００８７】
なお、図１７において、「X1」というルールオブジェクト７２Ｃに対応する行が複数存在するが、これはルール情報３０の条件部６２の条件６４（図４）が複数のルールセグメント７２に分割されている場合の例であり、部分ルール解析網２０を構築する際に１つのルールオブジェクト７２Ｃに結合される。
【００８８】
イベントオブジェクトテーブル３４は、管理プログラム２２がルール情報３０からルールセグメント７２を作成する際に、最終的なイベントオブジェクト７２Ａを格納するテーブルである。このイベントオブジェクトテーブル３４の詳細については省略する。
【００８９】
他方、セグメント参照履歴情報３５は、管理プログラム２２から参照されにくいルールセグメント７２を判断及び選択するための情報であり、図１８に示すように、セグメントＩＤ３５Ａ、ルール識別情報３５Ｂ、ロック状態３５Ｃ、カウンタ３５Ｄ、平均読込み間隔３５Ｅ及び最終参照時刻３５Ｆの各情報から構成される。
【００９０】
このうちセグメントＩＤ３５Ａは、対応するルールセグメント７２のセグメントＩＤを表し、ルール識別情報３５Ｂは、そのルールセグメント７２に属するルールオブジェクト７２ＣのオブジェクトＩＤを表す。またロック状態３５Ｃは、そのルールセグメント７２Ｃの状態を表す。なお、「ルールセグメントの状態」については、後述する。
【００９１】
さらにカウンタ３５Ｄは、図示しないカウンタによりカウントされた、対応するルールセグメント７２が参照されていない期間を表し、平均読込み間隔３５Ｅは、管理プログラム２２が定義する一定の期間を１単位とするそのルールセグメント７２の平均的な参照間隔を表す。さらに最終参照時刻３５Ｆは、そのルールセグメント７２が最後に参照された時刻を表す。なお、セグメント参照履歴情報３５がこれ以外の参照履歴に関する情報を含んでいても構わない。
【００９２】
従って、例えば図１８の例では、「X1-10a_seg」というルールセグメント７２は、「X1」というルール情報３０に基づいて生成され、現在の状態は「locked」、カウンタの値は「０」、平均参照間隔は「15.0」、最終参照時刻は「2009:11…」であることが示されている。
【００９３】
なお、セグメント参照履歴情報３５における平均読込み間隔３５Ｅや最終参照時刻３５Ｆの値は、ロック状態３５Ｃが同じルールセグメント７２同士において、どちらかを追い出す場合の選択基準として利用される。例えば追い出しの対象として、平均読込み間隔３５Ｅが大きいものを選択したり、最終参照時刻３５Ｆが古いものを選択したりする。
【００９４】
（２−３）管理サーバのプロセッサにより実行される各種処理
次に、本実施の形態による障害原因解析機能に関連して管理サーバ２の管理プログラム２２により実行される各種処理について説明する。
【００９５】
（２−３−１）障害原因解析処理
図１９は、本実施の形態による障害原因解析機能に関連して管理プログラム２２により実行される障害原因解析処理の処理手順を示す。
【００９６】
管理プログラム２２は、管理サーバ２が起動されると、この図１９に示す障害原因解析処理を開始し、まず、２次記憶装置１１（図１）からルール情報３０を読み込み、読み込んだルール情報３０に基づいてルールセグメント７２、セグメント結合情報３３（図１）及びイベント索引情報２１（図１）を作成する（ＳＰ１）。この際、イベント索引情報２１は２次記憶装置１１上に作成され、その後、メモリ１０上に読込まれる。
【００９７】
続いて管理プログラム２２は、管理対象装置群３に対する監視・管理を開始し、管理対象装置群３に含まれるいずれかの管理対象装置４からイベント通知５０が送信されてくるのを待ち受ける（ＳＰ２）。
【００９８】
そして管理プログラム２２は、やがていずれかの管理対象装置４からイベント通知５０が送信されてくると、このイベント通知５０と、２次記憶装置１１内のルールセグメントレポジトリ３２に格納されたルールセグメント７２に関する情報とに基づいて、かかるイベント通知５０の内容を解析する（ＳＰ３）。
【００９９】
具体的に、管理プログラム２２は、関連するルールセグメント７２をメモリ１０上に読込み、セグメント結合情報３３を参照して、部分ルール解析網２０（図１）をメモリ１０上に構築する。また管理プログラム２２は、構築した部分ルール解析網２０を用いて、検知したイベントの解析処理を行う。この処理により読み込みをしたルールセグメント７２についての参照履歴情報をセグメント参照情報７３として登録又は更新する。なお、セグメント結合情報３３は、この処理においてメモリ１０上に読込まれていても構わない。
【０１００】
そして管理プログラム２２は、ステップＳＰ２に戻って、この後、以上のステップＳＰ２及びステップＳＰ３の処理を繰り返す。
【０１０１】
（２−３−２）前処理
図２０は、以上の障害原因解析処理（図１）のステップＳＰ１において管理プログラム２２により実行される処理（以下、これを前処理と呼ぶ）の具体的な処理手順を示す。管理プログラム２２は、この図２０に示す処理手順に従って、２次記憶装置１１に格納されている各ルール情報３０に基づいて１又は複数のルールセグメント７２、セグメント結合情報３３及びイベント索引情報２１等を作成する。
【０１０２】
すなわち管理プログラム２２は、障害原因解析処理のステップＳＰ１に進むと、この前処理理を開始し、まず、２次記憶装置１１に格納された１又は複数のルール情報３０の中から１つのルール情報を選択し（ＳＰ１０）、選択したルール情報３０を２次記憶装置１１からメモリ１０に読み込む（ＳＰ１１）。
【０１０３】
続いて管理プログラム２２は、ステップＳＰ１１においてメモリ１０に読み込んだルール情報３０について、そのルール情報３０の条件部６２（図４）の各条件６４（図４）のイベント情報６５（図４）に含まれるそのイベントのイベントＩＤ６５Ａ（図４）と、そのルール情報３０のルール識別情報６１（図４）とをそれぞれ図２１に示す第１の関連情報テーブル８０のイベントＩＤ欄８０Ａ及びルール識別情報欄８０Ｂに登録する（ＳＰ１２）。
【０１０４】
また管理プログラム２２は、ステップＳＰ１１においてメモリ１０に読み込んだルール情報３０について、結論部６３（図４）のイベント情報６７（図４）に含まれるそのイベントのイベントＩＤ６７Ａ（図４）と、そのルール情報３０のルール識別情報６１（図４）とをそれぞれ図２２に示す第２の関連情報テーブル８１のイベントＩＤ欄８１Ａ及びルール識別情報欄８１Ｂに登録する（ＳＰ１２）。
【０１０５】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１２の処理を実行し終えたか否かを判断する（ＳＰ１３）。そして管理プログラム２２は、この判断において否定結果を得ると、ステップＳＰ１０に戻り、この後、ステップＳＰ１０において順次他のルール情報３０を選択しながらステップＳＰ１０〜ステップＳＰ１３の処理を繰り返す。
【０１０６】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１２の処理を実行し終えることによりステップＳＰ１３において肯定結果を得ると、ステップＳＰ１２において作成した第１及び第２の関連情報テーブ８０，８１に基づいて、後述するステップＳＰ１５〜ステップＳＰ１７の処理を実行するルール情報３０の順番を定めたルール実行リストを作成する（ＳＰ１４）。
【０１０７】
このルール実行リストは、ルール情報３０間の依存関係を調べ、依存があるルール間の実行順序を制御するためのリストである。ルール情報３０間の依存関係とは、ある第１のルール情報３０の結論部６３が保持するイベントが、他の第２のルール情報３０の条件部６２の条件６４が保持するイベントとなっている関係をいう。以下においては、かかる場合に第１のルール情報３０を第２のルール情報３０の「子」と呼び、第２のルール情報３０を第１のルール情報３０の「親」と呼ぶものとする。
【０１０８】
続いて管理プログラム２２は、２次記憶装置１１に格納された１又は複数のルール情報３０の中から１つのルール情報３０を選択し（ＳＰ１５）、選択したルール情報３０に基づいてルールセグメント７２を構築する。また管理プログラム２２は、この際、セグメント結合情報３３（図１）、イベント索引情報２１（図１）及びイベントオブジェクトテーブル３４（図１）を作成する（ＳＰ１６）。
【０１０９】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１６の処理を実行し終えたか否かを判断する（ＳＰ１７）。そして管理プログラム２２は、この判断において否定結果を得ると、ステップＳＰ１５に戻り、この後、ステップＳＰ１５において順次他のルール情報３０を選択しながら、ステップＳＰ１５〜ステップＳＰ１７の処理を繰り返す。
【０１１０】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ１６の処理を実行し終えることによりステップＳＰ１７において肯定結果を得ると、ステップＳＰ１５〜ステップＳＰ１７の処理により作成された最終的なイベントオブジェクトテーブル３４を２次記憶装置１１に出力する（ＳＰ１８）。かくしてこのイベントオブジェクトテーブル３４は、この後、２次記憶装置１１に永続的に記憶され、後の解析処理時（図１９のステップＳＰ３）に利用される。
【０１１１】
（２−３−３）関連情報テーブル作成処理
図２３は、図１９について上述した前処理のステップＳＰ１２における管理プログラム２２の具体的な処理内容を示す。管理プログラム２２は、この図２３に示す処理手順に従って、第１及び第２の関連情報テーブル８０，８１を作成する。
【０１１２】
すなわち管理プログラム８０は、前処理のステップＳＰ１２に進むと、この図２３に示す関連情報テーブル作成処理を開始し、まず、前処理のステップＳＰ１１において読み込んだ図４に示すルール情報３０の条件部６２に含まれる条件６４を１つ選択する（ＳＰ２０）。
【０１１３】
続いて管理プログラム２２は、そのとき選択した条件６４に含まれるイベント情報６５のイベントＩＤ６５Ａのエントリが第１の関連情報テーブル８０に存在するか否かを判断し（ＳＰ２１）、肯定結果を得るとステップＳＰ２３に進む。
【０１１４】
これに対して管理プログラム２２は、ステップＳＰ２１の判断において否定結果を得ると、第１の関連情報テーブル８０にそのイベントＩＤ６５Ａのエントリを作成し（ＳＰ２２）、そのエントリのルール識別情報欄８０Ｂ（図２１）に、前処理（図２０）のステップＳＰ１１において読み込んだルール情報３０のルール識別情報６１（図４）を格納する（ＳＰ２３）。
【０１１５】
次いで管理プログラム２２は、前処理のステップＳＰ１１において読み込んだルール情報３０に含まれるすべての条件６４についてステップＳＰ２１〜ステップＳＰ２３の処理を実行し終えたか否かを判断する（ＳＰ２４）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ２０に戻り、この後、ステップＳＰ２４において肯定結果を得るまで、ステップＳＰ２０において順次他の条件を選択しながらステップＳＰ２０〜ステップＳＰ２４の処理を繰り返す。
【０１１６】
そして管理プログラム２２は、やがて前処理のステップＳＰ１１において読み込んだルール情報３０に含まれるすべての条件６４についてステップＳＰ２１〜ステップＳＰ２３の処理を実行し終えることによりステップＳＰ２４において肯定結果を得ると、かかるルール情報３０の結論部６３に含まれるイベント情報６７（図４）のイベントＩＤ６７Ａのエントリが第２の関連情報テーブル８１に存在するか否かを判断する（ＳＰ２５）。
【０１１７】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ２７に進む。これに対して管理プログラム２２は、ステップＳＰ２５の判断において否定結果を得ると、第２の関連情報テーブル８１にそのイベントＩＤ６７Ａのエントリを作成し（ＳＰ２６）、そのエントリのルール識別情報欄８１Ｂに、前処理のステップＳＰ１１において読み込んだルール情報３０のルール識別情報６１を格納する（ＳＰ２７）。
【０１１８】
そして管理プログラム２２は、この後、この関連テーブル作成処理を終了して、前処理のステップＳＰ１３に進む。
【０１１９】
（２−３−４）ルール実行リスト作成処理
一方、図２４は、前処理（図２０）のステップＳＰ１４において管理プログラム２２により実行されるルール実行リスト作成処理の具体的な処理手順を示す。管理プログラム２２は、この図２４に示す処理手順に従って、第１及び第２の関連情報テーブル８０，８１に基づき、ルール実行リストを作成する。なお、ルール実行リストは、イベントＩＤが順番に登録されたリストである。
【０１２０】
すなわち管理プログラム２２は、前処理のステップＳＰ１４に進むと、このルール実行リスト作成処理を開始し、まず、第１及び第２の関連情報テーブル８０，８１を参照して、図２５に示すルール情報依存関係管理テーブル８２を作成する（ＳＰ３０）。
【０１２１】
このルール情報依存関係管理テーブル８２は、ルール情報３０間の親子関係を管理するためのテーブルであり、図２５に示すように、親ルール列８２Ａ及び子ルール列８２Ｂから構成される。そして管理プログラム２２は、親ルール列８２Ａには、親子関係を有する２つのルール情報３０のうちの「親」となるルール情報３０のルール識別情報６１（図４）を格納し、子ルール列８２Ｂには、かかるルール情報３０の「子」となるルール情報３０のルール識別情報６１を格納する。
【０１２２】
続いて管理プログラム２２は、ルール情報依存関係管理テーブル８２にエントリ（行）が存在するか否かを判断し（ＳＰ３１）、否定結果を得ると、このルール実行リスト作成処理を終了する。
【０１２３】
これに対して管理プログラム２２は、かかるステップＳＰ３１の判断において肯定結果を得ると、１つのエントリを選択し（ＳＰ３２）、選択したエントリの親ルール列８２Ａに格納されているルール識別情報がルール実行リストに既に登録されているか否かを判断する（ＳＰ３３）。
【０１２４】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３６に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの親ルール列８２Ａに格納されたルール識別情報６１がルール情報依存関係管理テーブル８２のいずれかのエントリの子ルール列８２Ｂに格納されているか否かを判断する（ＳＰ３４）。
【０１２５】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３２に戻り、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの親ルール列８２Ａに格納されたルール識別情報をルール実行リストに追加する（ＳＰ３５）。
【０１２６】
続いて管理プログラム２２は、ルール情報依存関係管理テーブルにおけるそのとき対象としているエントリの子ルール列８２Ｂは空（ルール識別情報が格納されていない、つまり子ルールが存在しない）であるか否かを判断する（ＳＰ３６）。
【０１２７】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３９に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの子ルール列８２Ｂに格納されたルール識別情報が同じエントリ以外のいずれかのエントリの子ルール列８２Ｂに格納されているか否かを判断する（ＳＰ３７）。
【０１２８】
そして管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ３９に進み、これに対して否定結果を得ると、ステップＳＰ３２において選択したエントリの子ルール列８２Ｂに格納されているルール識別情報をルール実行リストに追加する（ＳＰ３８）。
【０１２９】
この後、管理プログラム２２は、ステップＳＰ３２において選択したエントリをルール情報依存関係管理テーブル８２から削除し（ＳＰ３９）、ルール情報依存関係管理テーブル８２のすべてのエントリについてステップＳ３２Ｐ〜ステップＳＰ３９の処理を実行し終えたか否かを判断する（ＳＰ４０）。
【０１３０】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ３２に戻り、この後、ステップＳＰ３２において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ３２〜ステップＳＰ４０の処理を繰り返す。
【０１３１】
そして管理プログラム２２は、やがてルール情報依存関係管理テーブル８２のすべてのエントリについてステップＳＰ３２〜ステップＳＰ４０の処理を実行し終えることによりステップＳＰ４０において肯定結果を得ると、このルール実行リスト作成処理を終了して前処理（図２０）のステップＳＰ１５に進む。
【０１３２】
（２−３−５）ルール情報依存関係管理テーブル作成処理
他方、図２６は、ルール実行リスト作成処理（図２４）のステップＳＰ３０において管理プログラム２２により実行されるルール情報依存関係管理テーブル作成処理の具体的な処理手順を示す。管理プログラム２２は、この図２６に示す処理手順に従って、ルール情報依存関係管理テーブル８２を作成する。
【０１３３】
すなわち管理プログラム２２は、ルール実行リスト作成処理のステップＳＰ３０に進むと、このルール情報依存関係管理テーブル作成処理を開始し、まず、第１の関連情報テーブル８０（図２１）の未処理のエントリを１つ選択する（ＳＰ５０）。
【０１３４】
続いて管理プログラム２２は、第２の関連情報テーブル８１（図２２）の未処理のエントリを１つ選択し（ＳＰ５１）、この後、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのイベントＩＤ欄８０Ａに格納されているイベントＩＤと、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのイベントＩＤ欄８１Ａに格納されているイベントＩＤとが同じであるか否かを判断する（ＳＰ５２）。
【０１３５】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５５に進む。これに対して管理プログラム２２は、この判断において肯定結果を得ると、ルール情報依存関係管理テーブル８２のエントリの中に、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのルール識別情報欄８０Ｂに格納されたルール識別情報が親ルール列８２Ａに格納され、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのルール識別情報欄８１Ｂに格納されたルール識別情報を子ルール列８２Ｂに格納したエントリが存在するか否かを判断する（ＳＰ５３）。
【０１３６】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５５に進む。これに対して管理プログラム２２は、この判断において肯定結果を得ると、ルール情報依存関係管理テーブル８２に新たなエントリを作成し、そのエントリの親ルール列８２Ａに、ステップＳＰ５０において選択した第１の関連情報テーブル８０のエントリのルール識別情報欄８０Ｂに格納されたルール識別情報を格納すると共に、かかるエントリの子ルール列８２Ｂに、ステップＳＰ５１において選択した第２の関連情報テーブル８１のエントリのルール識別情報欄８１Ｂに格納されたルール識別情報を格納する（ＳＰ５４）。
【０１３７】
続いて管理プログラム２２は、第２の関連情報テーブル８１のすべてのエントリについてステップＳＰ５１〜ステップＳＰ５４の処理を実行し終えたか否かを判断する（ＳＰ５５）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５１に戻り、この後、ステップＳＰ５１において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ５１〜ステップＳＰ５５の処理を繰り返す。
【０１３８】
そして管理プログラム２２は、やがて第２の関連情報テーブル８１のすべてのエントリについてステップＳＰ５１〜ステップＳＰ５５の処理を実行し終えることによりステップＳＰにおいて肯定結果を得ると、第１の関連情報テーブル８０のすべてのエントリについてステップＳＰ５０〜ステップＳＰ５５の処理を実行し終えたか否かを判断する（ＳＰ５６）。
【０１３９】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５０に戻り、この後、ステップＳＰ５０において選択するエントリを順次他のエントリに切り替えながら、ステップＳＰ５０〜ステップＳＰ５６の処理を繰り返す。
【０１４０】
そして管理プログラム２２は、やがて第１の関連情報テーブル８１のすべてのエントリについてステップＳＰ５０〜ステップＳＰ５６の処理を実行し終えることによりステップＳＰ５６において肯定結果を得ると、２次記憶装置１１に格納されているルール情報３０の中から１つのルール情報３０を選択する（ＳＰ５７）。
【０１４１】
続いて管理プログラム２２は、ルール情報依存関係管理テーブル８２の親ルール列８２Ａ及び子ルール列８２Ｂのいずれか一方にステップＳＰ５７において選択したルール情報３０のルール情報識別子が格納されているエントリが存在しないか否かを判断する（ＳＰ５８）。
【０１４２】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ６０に進み、これに対して否定結果を得ると、ステップＳＰ５７において選択したルール情報３０のルール情報識別子が親ルール列８２Ａに格納され、かつ、子ルール列８２Ｂが空のエントリをルール情報依存関係管理テーブル８２に追加する（ＳＰ５９）。
【０１４３】
次いで管理プログラム２２は、２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ５７〜ステップＳＰ６０の処理を実行し終えたか否かを判断する（ＳＰ６０）。そして管理プログラム２２は、この判断において否定結果を得るとステップＳＰ５７に戻り、この後、ステップＳＰ５７において順次他のルール情報３０を選択しながらステップＳＰ５７〜ステップＳＰ６０の処理を繰り返す。
【０１４４】
そして管理プログラム２２は、やがて２次記憶装置１１に格納されているすべてのルール情報３０についてステップＳＰ５７〜ステップＳＰ６０の処理を実行し終えることによりステップＳＰ６０において肯定結果を得ると、このルール情報依存関係管理テーブル作成処理を終了する。
【０１４５】
（２−３−６）ルールセグメント等作成処理
図２７は、図２０について上述した前処理のステップＳＰ１６において管理プログラム２２により実行されるルールセグメント等作成処理の処理手順を示す。管理プログラム２２は、この図２０に示す処理手順に従ってルールセグメント７２（図１２）、イベント索引情報２１（図１５）、セグメント結合情報３３（図１７）及びイベントオブジェクトテーブル３４をそれぞれ作成する。
【０１４６】
なお、この図２７に示すルールセグメント等作成処理の処理実行過程において、管理サーバ２のメモリ１０中に複数のルールオブジェクト７２Ｃ（図１２）を格納するデータ構造としてのルールオブジェクトテーブル（図示せず）と、複数の結論オブジェクト７２Ｄ（図１２）を格納するデータ構造としての結論オブジェクトテーブル（図示せず）と、複数のイベントオブジェクト７２Ａ（図１２）を格納するデータ構造としてのイベントオブジェクトテーブル（図示せず）とが作成される。これらルールオブジェクトテーブル、結論オブジェクトテーブル及びイベントオブジェクトテーブルのそれぞれは、初期状態では中身が空であるものとする。
【０１４７】
管理プログラム２２は、前処理のステップＳＰ１６に進むと、このルールセグメント等作成処理を開始し、まず、ステップＳＰ１５において選択したルール情報３０のルール識別情報６１（図４）に対応するルールオブジェクト７２Ｃがルールオブジェクトテーブルに登録されているか否かを判断する（ＳＰ７０）。
【０１４８】
管理プログラム２２は、この判断において肯定結果を得るとステップＳ７３に進み、これに対して否定結果を得ると、そのルールオブジェクト７２Ｃを作成し、作成したルールオブジェクト７２Ｃをルールオブジェクトテーブルに登録する（ＳＰ７１）。
【０１４９】
続いて、管理プログラム２２は、前処理のステップＳＰ１５において選択したルール情報３０の結論部６３（図４）に対応する結論オブジェクト７２Ｄを作成すると共に、その結論部６３に含まれるイベント情報６７（図４）に対応するイベントオブジェクト７２Ａを作成し、これら作成した結論オブジェクト７２Ｄ及びイベントオブジェクト７２Ａを関連付ける（ＳＰ７２）。
【０１５０】
次いで、管理プログラム２２は、ステップＳＰ７１において作成したルールオブジェクト７２Ｃと、ステップＳＰ７２において作成した結論オブジェクト７２Ｄとを関連付け（ＳＰ７３）、この後、ステップＳＰ７２において作成した結論オブジェクト７２Ｄを結論オブジェクトテーブルに登録し、又は既に結論オブジェクトテーブルに登録されている対応する結論オブジェクトを更新する（ＳＰ７４）。
【０１５１】
さらに管理プログラム２２は、かかる結論オブジェクト７２Ｄに関する必要な情報をセグメント結合情報３３（図１７）に登録し、又は既にセグメント結合情報３３に登録されている対応する結論オブジェクト７２Ｄを更新し（ＳＰ７５）、この後、前処理のステップＳＰ１５において選択したルール情報３０に、対応する条件オブジェクト７２Ｂ（図１３）が作成されていない条件６４（図４）が存在するか否かを判断する（ＳＰ７６）。
【０１５２】
管理プログラム２２は、この判断において肯定結果を得ると、かかるルール情報３０の条件部６２（図４）に含まれる条件６４の中から未処理の条件６４を１つ選択する（ＳＰ７７）。そして管理プログラム２２は、その条件６４に対応する条件オブジェクト７２Ｂを作成し、その条件オブジェクト７２Ｂと、ステップＳＰ７１において作成したルールオブジェクト７２Ｃとを関連付ける（ＳＰ７８）。
【０１５３】
続いて管理プログラム２２は、ステップＳＰ７７において選択した条件６４のイベント情報６５（図４）に含まれるイベントＩＤ６５Ａ（図４）をステップＳＰ７８において作成した条件オブジェクト７２ＢのイベントＩＤ７２ＢＤ（図１３）として格納する（ＳＰ７９）。さらに管理プログラム２２は、ステップＳＰ７６に戻り、この後ステップＳＰ７６において肯定結果を得るまでステップＳＰ７６〜ステップＳＰ７９の処理を繰り返す。
【０１５４】
そして管理プログラム２２は、前処理のステップＳＰ１５において選択したルール情報３０の条件部６２に含まれるすべての条件６４について、対応する条件オブジェクト７２Ｂを作成し終えることによりステップＳＰ７６において否定結果を得ると、前処理のステップＳＰ１５において選択したルール情報３０に対応するルールオブジェクト７２Ｃと、当該ルールオブジェクト７２Ｃに関連付けられた条件オブジェクト７２Ｂ及び結論オブジェクト７２Ｄと、イベントオブジェクト７２Ａとで構成されるルールセグメント７２とを２次記憶装置１１上のルールセグメントレポジトリ３２（図１）に格納する。また管理プログラム２２は、作成したルールセグメント７２にセグメントＩＤを付与し、そのルールセグメント７２のセグメントＩＤ、格納場所及び対応するルール情報３０のルール識別情報からなるルールセグメント７２の参照情報を作成する（ＳＰ８０）。この参照情報は、この後、図１６のセグメント参照情報７３に取り込まれる。
【０１５５】
加えて、管理プログラム２２は、そのルールセグメント７２を構成する条件オブジェクト７２Ｂが保持するイベントＩＤ７２ＢＤ（図１３）と、そのルールセグメント７２のセグメントＩＤとの対応関係を表すイベント索引情報とを作成する（ＳＰ８０）。このイベント索引情報は、この後、図１５のイベント索引情報２１（図１５）に取り込まれる。
【０１５６】
以上の処理により、ルールセグメント７２、セグメント結合情報３３及びイベント索引情報２１が作成される。
【０１５７】
（２−３−７）解析処理
他方、図２８は、図１９について上述した障害原因解析処理のステップＳＰ３において管理プログラム２２により実行される解析処理の具体的な処理手順を示す。
【０１５８】
管理プログラム２２は、障害原因解析処理のステップＳＰ３に進むと、この図２８に示す解析処理を開始し、まず、それまでに受信したイベント通知５０（図３）をイベントキュー２３（図１）から１つ取り出し（ＳＰ９０）、取り出したイベント通知５０に含まれるイベントＩＤ５０Ａ（図３）をキーとして、関連するルールセグメント７２のセグメントＩＤをイベント索引情報２１（図１５）から取得すると共に、イベントオブジェクトテーブル３４（図１）からイベントオブジェクト７２Ａ（図１２）を取得する（ＳＰ９１）。
【０１５９】
続いて管理プログラム２２は、関連するルールセグメント７２が２次記憶装置１１からメモリ１０に読み込み済みであるか否かをイベント索引情報２１（図１５）に含まれる読込み状態２１Ｃに基づいて判断し（ＳＰ９２）、肯定結果を得ると、ステップＳＰ９６に進む。
【０１６０】
これに対して管理プログラム２２は、ステップＳＰ９２の判断において否定結果を得ると、そのときメモリ１０に読み出されているすべてのルールセグメント７２により構成される部分ルール解析網２０（図１）の使用メモリ容量を取得し、その使用メモリ容量が予め設定された閾値以上であるか否かを判断する（ＳＰ９３）。
【０１６１】
管理プログラム２２は、この判断において否定結果を得るとステップＳＰ９５に進み、これに対して肯定結果を得ると、メモリ１０上のかかる部分ルール解析網２０を構成する一部のルールセグメント７２をメモリ１０から掃き出す（ＳＰ９４）。
【０１６２】
なお掃出し対象のルールセグメント７２の選択方法は、様々な方法が考えられるが、本実施の形態では、ルールセグメント７２の参照状況に基づいて状態を定義し、定義された状態や、参照された回数及び又は頻度などの情報を元に掃出し対象のルールセグメント７２を決定する。ルールセグメント７２の掃き出しは、そのルールセグメント７２に対する参照を全て削除することにより行ったり、メモリ管理を直接制御できる場合には、そのルールセグメント７２の読込みアドレスを直接解放したりすることにより行う。
【０１６３】
続いて管理プログラム２２は、ステップＳＰ９２において判断の対象としたルールセグメント７２を２次記憶装置１１上のルールセグメントレポジトリ３２（図１）からメモリ１０に読み出す（ＳＰ９５）。この際、管理プログラム２２は、セグメントＩＤをキーとしてルールセグメントレポジトリ３２内のセグメント参照情報７３（図１６）から対応するルールセグメント７２の格納位置を取得して読み出しを行う。またかかるルールセグメント７２の読み出し後に、イベント索引情報２１（図１５）と、ステップＳＰ９１において作成したイベントオブジェクト７２Ａとの相互参照を作成し、イベント索引情報２１とイベントオブジェクト７２Ａ、そして読み出したルールセグメント７２を相互参照及び結合させる。
【０１６４】
次いで管理プログラム２２は、セグメント参照履歴情報３５（図１８）におけるそのルールセグメント７２に対応する最終参照時刻３５Ｆ（図１８）及びロック状態３５Ｃ（図１８）を更新する（ＳＰ９６）。ロック状態３５Ｃは、現在、解析処理プログラムで解析中であることを示す「evaluated」に設定する。このロック状態３５Ｃは、実際に管理プログラム２２が実行対象として該ルールセグメント７２をスコープ内に入れた場合に「locked」に変更される。これらの状態遷移の詳細については図２９を用いて後ほど説明する。
【０１６５】
続いて管理プログラム２２は、そのとき対象としているイベント通知５０（ステップＳＰ９０においてイベントキュー２３から読み出したイベント通知５０）により報告されたイベントに関連するすべてのルールセグメント９２を２次記憶装置１１から読み出し終えたか否かを判断する（ＳＰ９７）。この判断は、管理プログラム２２は、ステップＳＰ95
において読み出したルールセグメント内のオブジェクトに関して、セグメント結合情報３３（図１７）において読込み状態３３Ｅが「NOT」となっているか否かにより行われる。
【０１６６】
管理プログラム２２は、この判断において肯定結果を得るとステップＳＰ９０に戻り、この後、参照していない関連するルールセグメント７２についてステップＳＰ９０〜ステップＳＰ９７の処理を実行する（ＳＰ９７）。
【０１６７】
そして管理プログラム２２は、やがてステップＳＰ９０においてイベントキュー２３から取り出したイベント通知５０により報告されたイベントに関連するすべてのルールセグメント７２についてステップＳＰ９０〜ステップＳＰ９７の処理を実行し終えることによりステップＳＰ９７において否定結果を得ると、以上の処理により構築された部分ルール解析網２０（図１）を用いて解析を行う。また管理プログラム２２は、この解析結果を管理サーバ２に表示させ、又は、メールにより管理者に通知する（ＳＰ９８）。そして管理プログラム２２は、この後、この解析処理を終了する。
【０１６８】
（２−４）ルールセグメントの状態遷移
図２９は、ルールセグメント７２の状態遷移について定義した一例である。この図２９に示すように、ルールセグメント７２の状態としては、「INITIAL」、「evaluated」、「locked」、「weak locked」及び「released」の５つがある。
【０１６９】
このうち「INITIAL」は、ルールセグメント７２の初期の状態を表し、「evaluated」は、そのルールセグメント７２が評価対象に入った状態、「locked」は、そのルールセグメント７２がロックされた状態をそれぞれ表す。また「weak locked」は、そのルールセグメント７２が弱くロックされた状態を表し、「released」はそのルールセグメント７２が解放対象となっている状態を表す。
【０１７０】
ルールセグメント７２の状態は、初期時には「INITIAL」であり、そのルールセグメント７２に関連するイベントを知らせるイベント通知５０を受信した段階で「evaluated」に遷移する。また、この後、そのルールセグメント７２が管理プログラム２２の実行スコープに入ると、そのルールセグメント７２の状態が「locked」に遷移し、そのルールセグメント７２が属している部分ルール解析網２０を用いた解析処理が終了すると、そのルールセグメント７２の状態が「evaluated」から「weak locked」に遷移する。
【０１７１】
さらに「weak locked」という状態になってから一定期間、関連するイベントを受信しなかった場合に、そのルールセグメント７２の状態が「released」に遷移する。さらに、ルールセグメント７２が「weak locked」又は「released」の状態にある場合においても、そのルールセグメント７２が関連するイベントについてのイベント通知５０を受信した場合、状態が「evaluated」に遷移する。
【０１７２】
「INITIAL」、「evaluated」、「locked」、「weak locked」及び「released」のうち、掃き出しの対象とならないものは、「INITIAL」を除くと「locked」のみであり、それ以外の状態については、「released」、「weak locked」、「evaluated」の順で追い出される対象となる。
【０１７３】
また、「released」、「weak locked」及び「evaluated」のうち、無条件で追い出し可能なものは「released」のみで、「weak locked」は、他に「released」状態のルールセグメントが存在しない場合に追い出し対象となり、「evaluated」についても他に「weak locked」状態のルールセグメントが存在しない場合のみ追い出し対象となる。
【０１７４】
（３）本実施の形態の効果
以上のように本実施の形態による情報処理システム１によれば、管理サーバ２において、ルールを条件６４及び結論からなる１つ以上のルールセグメント７２に分割し、管理対象装置４からのイベント通知５０を受信したときに、関連する１又は複数のルールセグメント７２により部分ルール解析網２０をメモリ１０上に構築し、構築した部分ルール解析網２０に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメント７２をメモリ１０上から削除するため、推論導出時に必要とするワークメモリのメモリ容量を削減し、かつ推論導出に要するメモリ容量を一定に保つことができる。またルール情報３０に基づくルールセグメント７２を事前に容易しておき、管理対象装置４からのイベント通知５０を受信したときに必要なルールセグメント７２を結合することにより部分ルール解析網２０を構築するようにしているため、かかる推論導出までの時間を短時間化することができる。かくするにつき、対象システムの定義イベントの数やルールの数によらず、一定のワーキングメモリサイズを保ちながら、少ない解析時間で解析処理を実行することができる。
【産業上の利用可能性】
【０１７５】
本発明は、１又は複数の情報処理装置を管理し、管理対象の情報処理装置から送信されるイベント通知に基づいて解析処理を行う管理装置に広く適用することができる。
【符号の説明】
【０１７６】
１……情報処理装置、２……管理サーバ、３……管理対象装置群、４……管理対象装置、１０……メモリ、１１……２次記憶装置、１２……プロセッサ、２０……部分ルール解析網、２１……イベント索引情報、２２……管理プログラム、２３……イベントキュー、３０……ルール情報、３１……管理対象構成情報、３２……ルールセグメントレポジトリ、３３……セグメント結合情報、３４……イベントオブジェクトテーブル、３５……セグメント参照履歴情報、５０……イベント情報、７２……ルールセグメント、７３……セグメント参照情報。
【特許請求の範囲】
【請求項１】
１又は複数の情報処理装置を管理する管理装置において、
前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する２次記憶装置と、
前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信するネットワークインタフェースと、
前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断するプロセッサと、
前記プロセッサのワークメモリとして利用されるメモリと
を有し、
前記プロセッサは、
予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、
前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除する
ことを特徴とする管理装置。
【請求項２】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記プロセッサは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出する
ことを特徴とする請求項１に記載の管理装置。
【請求項３】
前記プロセッサは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する
ことを特徴とする請求項１に記載の管理装置。
【請求項４】
前記プロセッサは、
前記メモリに読み込まれた前記ルールセグメントごとの参照履歴をセグメント参照履歴情報として管理し、当該セグメント参照履歴情報に基づいて、推論の導出に利用され難い前記ルールセグメントを判断する
ことを特徴とする請求項１に記載の管理装置。
【請求項５】
前記セグメント参照履歴情報は、
最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とに関する情報を含み、
前記プロセッサは、
前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴する請求項４に記載の管理装置。
【請求項６】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記プロセッサは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出すると共に、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、前記情報処理装置からのイベント通知を受信したときに、当該イベント索引情報を利用して、前記情報処理装置から送信された前記イベント通知により認識されるイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する一方、
前記メモリに読み込まれた前記ルールセグメントごとに、最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とをセグメント参照履歴情報として管理し、当該セグメント参照履歴情報に基づいて、前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴とする請求項１に記載の管理装置。
【請求項７】
１又は複数の情報処理装置を管理する管理方法において、
前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する第１のステップと、
前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信する第２のステップと、
前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断する第３のステップと
を有し、
前記第１のステップでは、
予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、
前記第３のステップでは、
前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除する
ことを特徴とする管理方法。
【請求項８】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記第３のステップでは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出する
ことを特徴とする請求項７に記載の管理方法。
【請求項９】
前記第１のステップでは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記第３のステップでは、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する
ことを特徴とする請求項７に記載の管理方法。
【請求項１０】
前記メモリに読み込んだ前記ルールセグメントごとの参照履歴をセグメント参照履歴情報として管理し、
前記第３のステップでは、
当該セグメント参照履歴情報に基づいて、推論の導出に利用され難い前記ルールセグメントを判断する
ことを特徴とする請求項７に記載の管理方法。
【請求項１１】
前記セグメント参照履歴情報は、
最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とに関する情報を含み、
前記第３のステップでは、
前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴する請求項１０に記載の管理方法。
【請求項１２】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記第３のステップでは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出すると共に、
前記第１のステップでは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記第３のステップでは、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する一方、
前記メモリに読み込んだ前記ルールセグメントごとに、最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とをセグメント参照履歴情報として管理し、
前記第３のステップでは、
当該セグメント参照履歴情報に基づいて、推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴とする請求項７に記載の管理方法。
【請求項１】
１又は複数の情報処理装置を管理する管理装置において、
前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する２次記憶装置と、
前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信するネットワークインタフェースと、
前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断するプロセッサと、
前記プロセッサのワークメモリとして利用されるメモリと
を有し、
前記プロセッサは、
予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、
前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除する
ことを特徴とする管理装置。
【請求項２】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記プロセッサは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出する
ことを特徴とする請求項１に記載の管理装置。
【請求項３】
前記プロセッサは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する
ことを特徴とする請求項１に記載の管理装置。
【請求項４】
前記プロセッサは、
前記メモリに読み込まれた前記ルールセグメントごとの参照履歴をセグメント参照履歴情報として管理し、当該セグメント参照履歴情報に基づいて、推論の導出に利用され難い前記ルールセグメントを判断する
ことを特徴とする請求項１に記載の管理装置。
【請求項５】
前記セグメント参照履歴情報は、
最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とに関する情報を含み、
前記プロセッサは、
前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴する請求項４に記載の管理装置。
【請求項６】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記プロセッサは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出すると共に、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、前記情報処理装置からのイベント通知を受信したときに、当該イベント索引情報を利用して、前記情報処理装置から送信された前記イベント通知により認識されるイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する一方、
前記メモリに読み込まれた前記ルールセグメントごとに、最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とをセグメント参照履歴情報として管理し、当該セグメント参照履歴情報に基づいて、前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴とする請求項１に記載の管理装置。
【請求項７】
１又は複数の情報処理装置を管理する管理方法において、
前記情報処理装置に発生するイベントの組み合わせを条件とし、前記イベントの組み合わせに対して想定される事柄を推論の結論とする、予め定義された１又は複数のルールを記憶する第１のステップと、
前記情報処理装置にイベントが発生したときに、当該情報処理装置から送信される当該イベントの内容に応じたイベント通知を受信する第２のステップと、
前記イベント通知及び対応する前記ルールに基づいて前記情報処理装置の状態を判断する第３のステップと
を有し、
前記第１のステップでは、
予め定義された前記１又は複数のルールを、それぞれ当該ルールを構成する条件及び結論からなる１つ以上のルールセグメントに分割し、分割により得られた前記ルールセグメントを前記２次記憶装置に保存し、
前記第３のステップでは、
前記情報処理装置からのイベント通知を受信したときに、関連する１又は複数の前記ルールセグメントを選択し、選択した前記１又は複数のルールセグメントをメモリ上において必要に応じて結合することにより、当該メモリ上にルール間の関係を示すルール解析網を構築し、構築したルール解析網に基づいて推論を導出すると共に、推論の導出に利用され難いルールセグメントをメモリ上から削除する
ことを特徴とする管理方法。
【請求項８】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記第３のステップでは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出する
ことを特徴とする請求項７に記載の管理方法。
【請求項９】
前記第１のステップでは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記第３のステップでは、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する
ことを特徴とする請求項７に記載の管理方法。
【請求項１０】
前記メモリに読み込んだ前記ルールセグメントごとの参照履歴をセグメント参照履歴情報として管理し、
前記第３のステップでは、
当該セグメント参照履歴情報に基づいて、推論の導出に利用され難い前記ルールセグメントを判断する
ことを特徴とする請求項７に記載の管理方法。
【請求項１１】
前記セグメント参照履歴情報は、
最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とに関する情報を含み、
前記第３のステップでは、
前記ルールセグメントが推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴する請求項１０に記載の管理方法。
【請求項１２】
前記ルールは、
予め定義された障害時に検知する前記情報処理装置の状態の変更をイベントとし、当該イベントの組み合わせを条件とし、当該イベントの組み合わせに対して想定される障害原因候補の事象を結論とし、
前記第３のステップでは、
前記イベント通知及び対応する前記ルールに基づいて障害原因の推論を導出すると共に、
前記第１のステップでは、
前記ルールを前記ルールセグメントに分割する際、当該ルールセグメント間の結合に関する情報でなるセグメント結合情報と、前記情報処理装置において発生するイベントに関連するルールセグメントを検索するためのイベント索引情報とを作成し、
前記第３のステップでは、
前記イベント索引情報を利用して、前記情報処理装置から送信されたイベント通知により認識される当該情報処理装置に発生したイベントに関連する前記１又は複数のルールセグメントを選択し、選択した前記１又は複数のルールセグメントを前記メモリ上において前記セグメント結合情報を用いて結合することにより、当該メモリ上に当該イベントに関連するルール解析網を構築する一方、
前記メモリに読み込んだ前記ルールセグメントごとに、最後に参照された時刻である最終参照時刻と、前記ルールセグメントが前記メモリに読み込まれる平均的な時間間隔である平均読込み間隔と、対応する前記ルールセグメントの状態とをセグメント参照履歴情報として管理し、
前記第３のステップでは、
当該セグメント参照履歴情報に基づいて、推論の導出に利用され難いか否かを、前記ルールセグメントの状態により判断し、状態が同じルールセグメントについては、当該ルールセグメントの平均読込み間隔及び最終参照時刻のいずれか一方又は両方により判断する
ことを特徴とする請求項７に記載の管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【公開番号】特開２０１１−１７５３５７（Ｐ２０１１−１７５３５７Ａ）
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願番号】特願２０１０−３７３６９（Ｐ２０１０−３７３６９）
【出願日】平成２２年２月２３日（２０１０．２．２３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年９月８日（２０１１．９．８）
【国際特許分類】
【出願日】平成２２年２月２３日（２０１０．２．２３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]