JP5237034B2 - イベント情報取得外のｉｔ装置を対象とする根本原因解析方法、装置、プログラム。 - Google Patents

Description

本願明細書に開示される技術は、サーバコンピュータ、ネットワーク装置、ストレージ装置を含む情報処理システムの運用を管理する運用管理方法、装置、システム、プログラム、プログラムを含む媒体及びプログラムの配布装置に関する。

近年、ＩＴシステム（ＩＴはＩｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙの略。なお、以後はＩＴシステムを情報処理システムと呼ぶことがある）はネットワークを介して様々なＩＴ装置（以後、情報処理装置と呼ぶことがある）が接続することで複雑化・大規模化し、障害はネットワークを介して様々なＩＴ装置に影響を与えている。これらの障害の箇所と原因を特定する根本原因解析技術として、特許文献１にはＩＴ装置から障害内容を通知されるイベント情報を用いて障害箇所と原因を解析するイベント相関技術が開示されている。また、イベント相関技術は、障害時に計算機から送信されるイベントの相関を利用して、根本原因を推測する技術とも言える。

また、非特許文献２では、当該技術と障害時のイベントの組み合わせと推測される根本原因を対にしてルール化することで、エキスパートシステムをベースとした推論エンジンを用いて根本原因を迅速に突き止める技術が開示されている。

米国特許第６，２４９，７５５号明細書 "Ｒｅｔｅ： Ａ Ｆａｓｔ Ａｌｇｏｒｉｔｈｍ ｆｏｒ ｔｈｅ Ｍａｎｙ Ｐａｔｔｅｒｎ／Ｍａｎｙ Ｏｂｊｅｃｔ Ｐａｔｔｅｒｎ Ｍａｔｃｈ Ｐｒｏｂｌｅｍ"， ＡＲＴＩＦＩＣＩＡＬ ＩＮＴＥＬＬＩＧＥＮＣＥ， Ｖｏｌ． １９， ｎｏ． １， １９８２， ｐｐ． １７−３７

運用管理に必要な処理を行う運用管理サーバはネットワークに接続された全てのＩＴ装置のイベントを採取することはできないため、運用管理サーバはイベント情報を受信（または取得）するＩＴ装置を限定し、根本原因解析技術を用いて解析結果を表示する。

しかし、当該解析技術はネットワークに接続された全てのＩＴ装置からイベント情報の取得ができることを前提としている。その結果、運用管理サーバがイベント情報を取得しないＩＴ装置でイベント（例えば障害）が発生し、イベント情報を取得しているＩＴ装置がこの障害の影響を受けた場合に、障害発生ＩＴ装置が解析対象外であるためにルールが適用されず、障害の根本原因を突き止められない。

本発明は、複数の情報処理装置と画面出力装置とプロセッサとメモリを有する運用管理サーバとから構成される情報処理システムの、前記複数の情報処理装置で発生するイベントの解析に関する装置、システム、方法、プログラム、記憶メディアを提供する。
本発明の一実施例によると、前記運用管理サーバについて、前記複数の情報処理装置の各々が、クライアントとしてネットワークサービスを用いるためにアクセス対象とする前記複数の情報処理装置の一部であるサーバ装置の識別情報を、前記メモリが有する構成情報に格納し、前記複数の情報処理装置の一部であって、前記運用管理サーバがイベント情報を取得する対象である複数のイベント取得対象装置を前記メモリが有する構成情報に登録し、前記複数の情報処理装置で発生する前記ネットワークサービスに関連した第一のイベント種別を含むイベントと、前記ネットワークサービスに関連した前記第一のイベント種別とは異なる第二のイベント種別を含むイベントと、を検知した場合に、前記第二のイベント種別に対応するイベントの発生が原因で前記第一のイベント種別に対応するイベントが発生し得ることを示す相関解析ルール情報を前記メモリに格納し、前記複数のイベント取得対象装置から収集した複数の前記イベント情報を前記メモリに格納し、前記相関解析ルール情報を元に、前記メモリに格納した複数の前記イベント情報から、前記第一のイベント種別を含む第一のイベント情報を特定し、前記構成情報を元に、前記第一のイベント情報を送信したイベント取得対象装置の一つである第一イベント取得対象装置と、前記第一のイベント種別に対応する前記ネットワークサービスにおける前記第一イベント取得対象装置のサーバ装置である障害要因装置とを特定し、前記相関解析ルール情報と前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置でない場合に、前記第一イベント取得対象装置と前記第一のイベント種別と前記障害要因装置と前記第二のイベント種別とを特定する情報を前記画面出力装置へ送信することで、前記第一イベント取得対象装置で発生した前記第一のイベント情報に対応したイベントが、前記障害要因装置で前記第二のイベント種別のイベントが発生したことが要因と推定されることを前記画面出力装置へ表示させる。

なお、前記相関解析ルール情報は、前記第一のイベント種別が発生した前記複数の情報処理装置の一つである第一情報処理装置と、前記第二のイベント種別が発生した前記複数の情報処理装置の一つである第二情報処理装置と、の間のトポロジ条件を示すトポロジ条件情報を含み、前記要因特定ステップは、前記トポロジ条件情報に基づいて前記障害要因装置を特定してもよい。

また、前記相関解析ルール情報と前記構成情報に基づいて、前記複数のイベント取得対象装置のサーバ装置であって、前記複数のイベント取得対象装置に含まれない、前記複数の情報処理装置の一部であるイベント関連情報処理装置を特定し、前記イベント関連情報処理装置からイベント情報の取得が可能か調査し、前記調査の結果を元に、前記イベント関連情報処理装置からイベント情報の取得が可能な場合は前記イベント関連情報処理装置を特定する情報を前記画面出力装置へ送信することで、前記イベント関連情報処理装置からイベント情報の取得が可能であることを前記画面出力装置へ表示させてもよい。

また、前記イベント情報取得可否調査は、前記複数の情報処理装置であって予め調査範囲として設定されたＩＰアドレスの範囲に含まれるＩＰアドレスを有する情報処理装置に対して、前記運用管理サーバが所定の手順に基づくアクセスを行った結果に基づいてもよい。

また、前記障害要因装置はコントローラを有し、論理ボリュームを提供するストレージ装置であって、前記ネットワークサービスは前記論理ボリュームをブロックアクセス形式のプロトコルによって提供するサービスであって、前記第一のイベント種別が前記コントローラの障害発生であり、前記第一のイベント種別が前記論理ボリュームへのアクセス失敗であってもよい。
また、前記相関解析ルール情報と前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置の一つの場合に、複数の前記イベント情報から前記第二のイベント種別を含み、前記障害要因装置が取得元である第二のイベント情報を特定し、前記第一イベント取得対象装置と前記第一のイベント情報と前記障害要因装置と前記第二のイベント情報とを特定する情報を前記画面出力装置へ送信することで、前記第一イベント取得対象装置で発生した前記第一のイベント情報に対応したイベントが、前記障害要因装置で発生した前記第二のイベント情報に対応したイベントが発生したことが要因であることを前記画面出力装置へ表示させてもよい。
また、本発明の別な一実施例によると、運用管理サーバにて、イベント情報取得対象の情報処理装置をイベント取得対象装置として構成情報に登録し、運用管理サーバに格納した複数のイベント情報から、予め格納したルールに適合するイベント情報を特定し、当該イベント情報が関連するネットワークサービスのサーバ装置を特定し、イベント情報を生成したクライアント情報処理装置で発生した当該イベントの要因がサーバ装置で発生したネットワークサービスに関するイベントと推定されることを表示する。

本発明によれば、イベント情報を取得しないＩＴ装置にてイベントが発生した場合も解析結果を表示することができる。

以下に、本発明の実施の形態を説明する。

図１は、本発明を実施するため情報処理システムの１つの構成を示した概観図である。情報処理システムは運用管理システムと、運用管理サーバから構成される。運用管理システムは、ＩＴシステムを構成する計算機、ネットワークスイッチ（ＮＷスイッチ）、及びストレージ装置を管理対象として、運用管理サーバＮ０でこれらを監視・管理している。本発明の運用管理サーバＮ０は、管理対象のＩＴ装置における状態変化、障害情報、通知情報などのイベント情報を受信するイベント受信部Ｃ０と、受信したイベント情報にもとづき、予め定義されたルールＲ０にもとづいて障害解析を行うルールエンジンＣ１と、管理対象のＩＴ装置の構成情報を管理する構成管理Ｃ３と、これらの運用管理するために必要となる情報を画面に出力するための画面表示部Ｃ２が備わっている。

また、運用管理システムには、画面表示部の制御と出力データに基づいて、運用管理のための情報を画面に表示するための装置である画面出力装置Ｍ１があり、運用管理サーバＮ０と接続している。なお、画面出力装置Ｍ１としては第一に運用管理サーバに接続されたディスプレイ装置であることが考えられるが、運用管理システムの管理者に解析結果情報を表示することができれば他の装置で代替してもよい。画面出力装置Ｍ１のそのほかの例としては、画面出力装置として運用管理サーバＮ０が送信する電子メールを受信し、表示可能な携帯端末であったり、運用管理サーバＮ０が送信する解析結果情報を元に管理者に情報提供し、また管理者からの入力を受け付けて運用管理サーバＮ０に送信するディスプレイ付計算機がある。

ルールエンジンＣ１は、さらにイベントの相関解析のための解析ルール情報Ｒ０（以後、相関解析ルール情報と呼ぶことがある）を読みこみ、構成管理Ｃ３から構成情報Ｔ０を取得して、ルールをＩＴシステムのＩＴ装置に適用するための処理を行うルール適用部Ｃ１１と、ルール適用部においてルールをＩＴ装置に適用するための情報である適用情報を管理するルール適用先管理テーブルＣ１３０を管理し、ルールの解析処理を行うためのワーキングメモリであるルールメモリＣ１３と、イベント受信部Ｃ０で受信したイベント情報を受け取り、イベントの相関解析を行う、イベント解析処理部Ｃ１２から成る。なお、ルール適用先管理テーブルＣ１３０はルールメモリＣ１３内に存在しなくても、運用管理サーバＮ０のメモリに格納されればよい。

なお、相関解析ルール情報は運用管理サーバＮ０の管理者によって作成・格納されてもよく、後述する本発明のプログラムに相関解析ルール情報を含めることでメモリに格納してもよく、または本発明のプログラムの初期化処理によって相関解析ルール情報をメモリに格納してもよい。

なお、運用管理サーバＮ０を構成するハードウェアとしては、プロセッサ、メモリ（半導体メモリ及びＨＤＤに代表される二次記憶装置を含む）、ネットワークポートがある。それぞれのハードウェアはバス等の内部ネットワークによって接続される。なお、イベント受信部Ｃ０、ルートエンジンＣ１、画面表示部Ｃ２、構成管理Ｃ３は運用管理サーバＮ０のメモリに格納され、プロセッサによって実行されるプログラムとして実現されることが第一に考えられるが、これら機能の一部または全てをハードウェアで実現してもよい。なお、以後の説明ではイベント受信部Ｃ０、ルートエンジンＣ１、画面表示部Ｃ２、構成管理Ｃ３を含むプログラムをイベント解析プログラムと呼ぶ。

また、また、相関解析ルール情報Ｒ０、構成情報Ｔ０、ルール適用先管理テーブルＣ１３０は、運用管理サーバＮ０のメモリに格納されている。さらに、構成情報Ｔ０は後ほど説明する、ＩＰ−ＳＡＮストレージ装置の接続情報（図８）、ＩＰ−ＳＡＮストレージに関する情報（図９）、ＦＣ−ＳＡＮストレージ装置の接続情報（図１３）、ＦＣ−ＳＡＮストレージに関する情報（図１４）、ファイルサーバに関する識別情報と公開名（図１５）の少なくとも一つが含まれる。また、後ほど説明する管理外ＩＴ装置管理テーブル（図１１）についても構成情報に含まれるものとして説明するが、運用管理サーバＮ０のメモリに格納されていれば構成情報Ｔ０以外の情報として格納されていてもよい。

さらに、相関解析ルール情報Ｒ０、構成情報Ｔ０、ルール適用先管理テーブルＣ１３０、ＩＰ−ＳＡＮストレージ装置の接続情報、ＩＰ−ＳＡＮストレージに関する情報、ＦＣ−ＳＡＮストレージ装置の接続情報、ＦＣ−ＳＡＮストレージに関する情報、ファイルサーバに関する識別情報と公開名、管理外ＩＴ装置管理テーブルについてはテキストファイルやテーブル、キュー構造など特定のフォーマット、データ構造である必要はなく、後ほど説明する情報が含まれていればよい。以後の説明及び請求項にてより一般的な情報であることを明記するため、相関解析ルール情報Ｒ０、構成情報Ｔ０、ルール適用先管理テーブルＣ１３０、ＩＰ−ＳＡＮストレージ装置の接続情報、ＦＣ−ＳＡＮストレージ装置の接続情報、ＩＰ−ＳＡＮストレージに関する情報、ＦＣ−ＳＡＮストレージに関する情報、ファイルサーバに関する識別情報と公開名、管理外ＩＴ装置管理テーブルを、それぞれ相関解析ルール情報情報、構成情報、ルール適用先管理情報、ＩＰ−ＳＡＮストレージ装置の接続情報、ＦＣ−ＳＡＮストレージ装置の接続情報、ＩＰ−ＳＡＮストレージに関する情報、ＦＣ−ＳＡＮストレージに関する情報、ファイルサーバに関する識別及び公開名情報、管理外ＩＴ装置管理情報と呼ぶことがある。

なお、図示はしていないが、運用管理サーバは管理対象の様々なＩＴ装置から受信するイベント情報をイベントエントリとしてメモリ内に定義したイベントデータベースに格納する。なお、イベントデータベースは一つ以上のイベントエントリが含まれていればどのようなデータ構造であっても良い。

なお、イベント情報はイベント内容が含まれるが、イベント発生時間を含んでもよい。さらにイベントデータベースは過去のイベント情報を定められた条件に従って履歴として残しても良い。また、イベントデータベースに含め、メモリに格納する場合は、運用管理サーバのプログラム（特に構成管理Ｃ３）はイベント情報取得対象のＩＴ装置の識別情報と、運用管理サーバによるイベント情報受信時間と関連付け、共に含めるようにしてもよい。なお、イベント内容は少なくともイベントの種別が含まれ、場合によっては当該イベントが発生ＩＴ装置内のハードウェア及びソフトウェアを特体する情報が含まれてもよい。

またイベントの種別としては例えば以下が考えれれるが、これ以外の種別が存在してもよい。
（Ａ）当該ＩＴ装置のの稼動状態が予め定められた状態となったこと（例えばハードウェア障害や、ソフトウェア障害の発生がこれに含まれる）
（Ｂ）ヘルスチェック結果が予め定められた結果となったこと。（例えば一定時間ヘルスチェック応答が無かった場合がこれに含まれる）
（Ｃ）処理速度やＩＴ装置を構成するコンポーネントであるプロセッサやメモリ、ＨＤＤなどの消費リソース量が予め定められた条件に適合したこと（例えばＨＤＤの残り容量が１０％を下回った場合がこれに含まれる）
（Ｄ）ＩＴ装置が予め定められた条件を満たすネットワークアクセスを受信したこと（例えば、ＩＴ装置が受信したリクエストが所定の回数を超えた場合や、リクエストされたＤｏＳ攻撃と識別されるネットワークパケットを所定回数受信した場合や、定められたＩＴ装置以外のＩＴ装置からリクエストを受信した場合がこれに含まれる）
なお、イベント解析プログラムのメモリへの格納は当該プログラムを記憶したＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等の媒体からのインストールやコピーによる方法や、運用管理サーバＮ０と通信可能なプログラム配布サーバからの当該プログラム（または当該プログラムをメモリ上で生成可能な情報）を受信する方法が考えられるが、これ以外の方法であってもよい。また、運用管理サーバＮ０へのプログラム格納を予め格納した後で運用管理サーバＮ０を流通させる形態であってもよい。

以上説明した運用管理サーバＮ０によって情報処理システムの障害の根本原因を解析する。

なお、運用管理システムでは、予め管理する対象のＩＴ装置を指定し、イベント情報を相関解析による解析対象として当該ＩＴ装置から必要な情報を受信する。このように運用管理システムにおいて、受信するＩＴ装置を定めるのは、ネットワークに接続されたＩＴ装置を全て管理することは、管理するために必要となる管理サーバのプロセッサ、メモリ、ハードディスクなどの記憶装置などの消費量が膨大となり、実用的な監視が困難であるため、管理する対象を絞ることでこれを回避するためである。また、管理ツールが商用のものである場合には、管理するＩＴ装置の種類や台数などによりライセンス数に制限がある場合がほとんどである。このためＩＴシステムにおいては、イベント情報解析のために、運用管理サーバＮ０がイベント情報を取得するまたは取得を許可されているＩＴ装置（以後、監視されるＩＴ装置、又は管理されるＩＴ装置又は管理ＩＴ装置又は管理内ＩＴ装置又はイベント取得対象装置と表現することがある。なお同様の表現はＩＴ装置の実態である計算機、スイッチ、ルータ、ストレージ装置に対しても適用する）と、運用管理サーバＮ０がイベント情報取得を取得しない又は取得を抑止されているＩＴ装置（以後、監視されないＩＴ装置、又は管理されないＩＴ装置又は管理外のＩＴ装置又は管理外ＩＴ装置又はイベント関連情報処理装置と表現することがある。なお同様の表現はＩＴ装置の実態である計算機、スイッチ、ルータ、ストレージ装置に対しても適用する）が存在する。

運用管理サーバＮ０において監視・管理されないＩＴ装置については、さらに、一度でも運用管理サーバＮ０において存在を発見、又は確認、又は管理されたことがあるＩＴ装置と、一度も運用管理サーバＮ０において、その存在を発見、又は確認、又は管理されたことがないものに分類される。運用管理サーバＮ０によっては、一度でも管理したことがあるＩＴ装置、又は発見、又は確認したことがあるＩＴ装置については、監視・管理されているＩＴ装置と同等とはいわないまでも、当該発見または確認によって取得した構成情報、例えばＩＴ装置のＩＰアドレス、又はホスト名、又はＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）などを内部に保持して管理するものもある。本発明では、対応する構成情報を運用管理サーバＮ０が持たない管理対象外のＩＴ装置と、対応する構成情報の一部又は全てを運用管理サーバＮ０に格納済みの管理対象外のＩＴ装置とを含めて、管理対象外のＩＴ装置として定義する。

運用管理システムの管理対象外であるケースとしては、ＤＮＳサーバのようにグローバルに提供されたサービスを管理対象内のＩＴ装置が利用している場合や、ファイアーウォール、アクセス権の問題、ネットワーク構成、アクセス手段の不備などの事情により、運用管理システムが管理するための情報収集を十分に行えない場合などがある。

なお、本発明はネットワーク上に存在する複数のＩＴ装置同士の相関解析を対象としている。しかし、本来相関のある複数装置である要因によるイベントが同時発生したとしても個々の装置のクロックにはずれが生じ、さらにイベント情報転送のタイミングにもずれが生じるため、運用管理サーバＮ０が解析対象とするイベント情報はプログラム開発者が予め定めたられた時間幅（期間）または管理者が定めた期間内に発生または受信したイベント情報を解析する。また、ある要因が発生したとしても当該要因に関係するイベントの発生はずれが生じることがあるため（例えば、ＷｅｂサービスやＤＮＳサービス等、サーバ計算機からキャッシング処理を介在させて所定のネットワークサービスを受ける場合）、特定の時間ではなくて期間を対象とした解析が必要となる。

なお、イベントとして好適なものはある程度動的に発生する事項であることが好ましい。さらには、所定の要因が発生して要因となるＩＴ装置でのイベントが発生（または運用管理サーバが受信）する時間と、当該要因を受けて別なＩＴ装置でのイベントが発生（または運用管理サーバが受信）する時間の差が、前記期間内であるイベントの要因であることがより好適である。

一方の構成情報として考えられる情報は、ＩＴ装置を構成するハードウェアの種類及び個数や、当該装置と通信するために必要な通信識別情報や名前といったものが好適であり、一部ＩＴ装置の管理者によって変更は可能であるが準静的な情報が好適である。

図２は、上記の構成にもとづく本発明における実施形態の１つの大まかな処理の流れを示したものである。

Ｓ１においてルールエンジンＣ１は、予め相関解析ルール情報Ｒ０を読み込み、構成管理Ｃ３から管理対象の構成情報Ｔ０を取得して、ルール群Ｒ０の適用先のＩＴ装置の識別情報をＴ０から検索して、ルール適用先管理テーブルＣ１３０に格納しておく。Ｓ１の処理は、この後に行うイベントによる障害解析処理のための準備であり、解析処理の前までに行えばよい。実施形態の１つである第一実施形態では、解析処理を運用開始前に行い、予めルール適用先管理テーブルＣ１３０をルールメモリＣ１３内に保持しているものとする。

Ｓ２においては、イベント受信部Ｃ０にて、運用管理システム内の管理対象のＩＴ装置から上げられるイベントの受信待ちうけを行う。

Ｓ３では、運用管理システムの運用操作に関するものであり、停止処理が指示されたかどうかを確認するためのステップであり、運用の停止を行うためのものである。

Ｓ４においては、イベント受信部Ｃ０でイベントを受信したかどうかの判断を行う。受信した場合には、Ｓ５においてイベント受信部Ｃ０より受信したイベントをイベント解析処理部Ｃ１２に入力して、ルール適用先管理テーブルＣ１３０にもとづいて該当するルールを求めて、該ルールに従い障害原因を特定する。

Ｓ５においては、特定した障害原因を画面表示部Ｃ１４に出力する。画面表示部Ｃ１４は、受け取った解析結果出力データを元に解析情報を送信することで、画面出力装置Ｍ１に運用管理に必要な画面を出力・表示する。

なお、Ｓ２及びＳ４の処理の代替として受信したイベント情報を一旦イベントデータベースに格納してもよい。

この大まかな処理の流れにおいて、ルール適用部の処理に手を加えることで、構成やその後の処理の流れを大幅に変えることなく、管理対象でないＩＴ装置の障害の原因解析を行えることが本発明の効果の１つである。

図３は、本発明の実施形態で想定するＩＴシステムの構成の１つを示した概観図である。図３のＩＴシステムは、管理サーバＮ０が運用管理する計算機Ｎ１０、計算機Ｎ１１、計算機Ｎ１２と、ネットワークスイッチであるＩＰスイッチＮ２１とＦＣスイッチＮ３１、ストレージ装置Ｎ４０とストレージ装置 Ｎ４１で構成される運用管理対象である運用管理システムと、管理サーバＮ０が管理しない管理対象外のＩＴ装置としてストレージ装置Ｕ２と計算機Ｕ５と、ルータＮ２０を介してネットワークＧ０に接続されるストレージ装置Ｕ１と、計算機Ｕ３と計算機Ｕ４と、から構成される。なお、個々で記した計算機、スイッチ、ルータ、ストレージ装置等のＩＴ装置の個数は一例であり、少なくともネットワークサービスを提供するサーバの役目を持ったＩＴ装置と、当該ネットワークサービスの提供を受けるクライアントの役目を持ったＩＴ装置が運用管理システムに含まれていればよい。

管理対象外のＩＴ装置のストレージ装置Ｕ１はＩＰ−ＳＡＮのインタフェースを備えるストレージ装置であり、管理対象の計算機Ｎ１０に対して論理ボリュームを提供している。また、管理対象外のＩＴ装置のストレージ装置Ｕ２はＦＣ−ＳＡＮのインタフェースを備えるストレージ装置であり、管理対象のＦＣスイッチＮ３１を介して管理対象の計算機Ｎ１３に対して論理ボリュームを提供している。管理対象外のＩＴ装置の計算機Ｕ３又は計算機Ｕ５はファイルサーバであり、それぞれ管理対象の計算機Ｎ１０、Ｎ１１の両方にファイルシステムを公開しているが、計算機Ｕ３は運用管理システムとは違うネットワークセグメントに属しており、計算機Ｕ３に関する詳細な情報はネットワーク上から取得できないようになっている。

一方で、計算機Ｕ５のファイルサーバは、運用管理システムと同一のネットワークセグメントに属しており、運用管理システムにより自動で存在を発見することができる計算機で、運用時に発見されたが、管理対象とはされなかったＩＴ装置である。また、管理対象外のＩＴ装置の計算機Ｕ４はＤＮＳサーバであり、図３のＩＴシステムの全てのＩＴ装置に対して名前解決機能を適用している。

ここでは理解のために第一実施形態について述べる前に、管理対象のＩＴ装置に対し、イベント相関技術のルールをどのように適用するかについて説明する。

図４は、図１で示したＩＴシステムに対して、ストレージ装置のコントローラの障害が根本原因であることを示唆するルールの例である。こうした障害解析の根本原因を特定するルールは、イベント相関に基づき、発生すると予測されるイベントの組み合わせと、根本原因となる障害のペアをｉｆ−ｔｈｅｎ形式で示すことが多い。ｉｆ−ｔｈｅｎ形式のルール表現においては、“もしｉｆ に記述された条件が成立するならば、ｔｈｅｎ部分が真である”のような意味のルールを表記する。

実施例では、エキスパートシステムなどの一般的なルールと同様にｉｆ−ｔｈｅｎの形式でルールが記述されているものとし、ルールの適用対象となるＩＴ装置に関する情報がｉｆの条件部分に予め定義されているものとする。なお、ルールの記述形式自体はｉｆ−ｔｈｅｎ形式でなくても良く、ルールを適用する対象となるＩＴ装置が特定できる何かしらの接続・関係情報としてトポロジが予め定義されていればよい。

なお、それぞれのルールを実際に格納する情報はルールエントリである。相関解析ルール情報は一つ以上のルールエントリを含む。なお、より抽象化すると当該ルールエントリは以下の情報が含まれると言っても良い。
（Ａ）当該ルールが適合するイベントの種別を含んだ条件を示す条件エントリ。上記の通り、この条件エントリにはトポロジを条件として含めてもよい。
（Ｂ）当該条件が適合した場合に原因となるイベントと、当該イベントが関係するＩＴ装置又はＩＴ装置のハードウェア・ソフトウェアの箇所を表す原因エントリ。

第１実施例として、ｉＳＣＳＩを利用したＩＰ−ＳＡＮのストレージ装置のコントローラ障害を根本原因とするルールＲ１と、Ｆｉｂｒｅ Ｃｈａｎｎｅｌを利用したＦＣ−ＳＡＮのストレージ装置のコントローラ障害を根本原因とするルールＲ２と、ファイルサーバの障害を根本原因とするルールＲ３と、ＤＮＳサーバへのネットワーク不到達を根本原因とするルールＲ４が図４に示すように予め定義されているものとする。また、図６には、ルールに対して、該ルールを適用するＩＴ装置を保持する情報である、ルール適用先管理テーブルを示した。ルール適用先管理テーブルは、ルールを指し示す識別情報のカラムＣ１０１とそのルールを適用させる対象のＩＴ装置の識別情報を格納する適用先ＩＴ装置のリストのカラムＣ１０２から成る情報であり、データベース上のテーブルである必要はない。なお、本テーブル状のデータ構造は、テーブルを正規化することにより、複数のテーブル状のデータ構造に分割して管理されていてもよい。

図３で示したルールＲ１乃至Ｒ４ に対して、それぞれのルールを適用させるトポロジのパターンを図５に示した。図５の（１）は、ルールＲ１のＩＦ部が示唆する接続・関係情報のトポロジを示しており、計算機を示すＣｏｍｐｕｔｅｒが、ｉＳｃｓｉＩｎｉｔｉａｔｏｒを持ち、ＩＰスイッチを示すＩｐＳｗｉｔｃｈを介して、ストレージ装置を示すＳｔｏｒａｇｅのｉＳｃｓｉＴａｒｇｅｔと接続されていることを示す。ｉＳｃｓｉＴａｒｇｅｔは、ｉＳｃｓｉＩｎｉｔｉａｔｏｒの接続先を識別するためのｉＳＣＳＩ名であり、計算機が持つ接続先のｉＳｃｓｉＴａｒｇｅｔと、ストレージ装置が持つｉＳｃｓｉのポートのｉＳＣＳＩ名が一致する計算機とストレージ装置の組み合わせに対してルールＲ１が適用される。図３で示されるＩＴシステムにおいては、ルールＲ１の適用先のＩＴ装置は図６のＬ１０１とＬ１０２の行のようになる。

また、図５の（２）についても同様に、ルールＲ２のＩＦ部が示唆するように、計算機がＦｃＨｂａを備え、ＦｃＨｂａがＦｃＳｗｉｔｃｈを介して、ストレージ装置のＦｃＰｏｒｔに繋がっていることを示す。このとき、ＦｃＨｂａが持つ接続先ポートＷＷＮ（ＷＷＮ： Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）と、ストレージ装置のＦｉｂｒｅ ＣｈａｎｎｅｌのポートであるＦｃＰｏｒｔのＷＷＮであるＦｃＰｏｒｔＷＷＮは一致しているものを接続関係があるものとしてルールＲ２の適用対象とする。図３のＩＴシステムにおいて、これらの計算機とストレージ装置の組み合わせとしてルールＲ２の適用先のＩＴ装置は図６のＬ１０３の行になる。

図５の（３）については、ルールＲ３のＩＦ部がファイルサーバ−クライアントのトポロジを示している。ファイルサーバのファイルシステムをマウントしていることを示す情報ＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅを持つコンピュータＴ３１と、外部にファイルシステムを公開していることを示す情報ＥｘｐｏｒｔｅｄＦｉｌｅＳｈａｒｅを持つコンピュータＴ３３は、ＩＰスイッチＴ３２を介してそれぞれクライアント−ファイルサーバの関係である。このとき、ＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅ Ｔ３１１にはマウント元のファイルサーバに関する情報として、ファイルサーバの識別情報（ＩＰアドレスやＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）など）と、公開しているファイルシステムの公開名を持ち、ＥｘｐｏｒｔｅｄＦｉｌｅＳｈａｒｅ Ｔ３３１には、公開しているファイルシステムの場所と公開名（共有名とも呼ばれる）を持つ。

ＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅが指しているファイルサーバの識別情報で示されるコンピュータで、なおかつそのコンピュータがＥｘｐｏｒｔｅｄＦｉｌｅＳｈａｒｅの情報を持ち、ＥｘｐｏｒｔｅｄＦｉｌｅＳｈａｒｅの公開名がコンピュータＴ３１のＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅが指している公開名と一致するコンピュータのペアをファイルクライアント−ファイルサーバのトポロジとしてルールＲ３を適用する。したがって、図３のＩＴシステムにおいては、これを満たす組み合わせとしてルールＲ３の適用先のＩＴ装置は図６のＬ１０４の行になる。

図５の（４）については、ルールＲ４が示唆するＤＮＳサーバとクライアントのトポロジであり、名前解決サービスを提供しているＤＮＳサーバであるコンピュータＴ４２と、ＤＮＳサーバによりＩＰアドレスとＦＱＤＮの名前を解決しているクライアントのコンピュータＴ４１がペアとなって、図６に示す適用先管理テーブルに格納される。

こうしたルールに記述された接続や関係に関するトポロジ情報に対する構成は、予めシステムで定義されているものとし、ルールの記述によって一意に定められる。

ルールに対する適用先のＩＴ装置に関しては図６の適用先管理テーブルを持つことにより、イベント発生時にこのテーブルを参照することで、イベントがどのルールに関連するものなのかを判断し、適用すべきルールを選択することができる。以上が、管理対象のＩＴ装置に対するルールの適用方法である。

図７及び図２１及び図２１は、図２のルール適用部Ｃ１１におけるステップＳ１について、本発明の実施形態の１つを詳細化したものである。この処理フローに従い、図３のＩＴシステムと、図４のルールＲ１乃至Ｒ４を想定して第一実施形態を説明する。なお、図７及び図２１及び図２１の処理は、全てルール適用部において行われるものである。また、予め運用管理システムは、一度発見したことがあるＩＴ装置について記憶しており、発見済みのＩＴ装置であると判断できることを前提とする。あるいは、運用管理システムが、ＩＴシステム内のＩＴ装置を自動で発見する機能を持たない場合、又は自動で発見する機能を持っていても、発見したＩＴ装置について記憶する機能がない場合には、発見済みのＩＴ装置は存在しないものとして図７及び図２１の処理を行う。

（一般的なフローの説明及びルールＲ１を適用した場合について）
Ｓ１０１において、相関解析ルール情報情報Ｒ０に読み込むルール、すなわち読み込み済みでないルールが存在するかを判断する。判断の結果、読み込むルールが存在する（ＹＥＳの）場合には、Ｓ１０２に移る。そうでなければ（ＮＯの場合）終了する。読み込むルールはＲ１乃至Ｒ４と存在するので、ここではＹＥＳとなりＳ１０２に移る。

Ｓ１０２においては、ルールを１つ読み込み、読み込み済みとわかるように、例えばしるしをつけたり、読み込み済みのルールとして記憶したりする。実施形態では、ルールのＲ１を読み込み、ルールＲ１を読み込み済みルールとして記憶してＳ１０３に移る。

Ｓ１０３においては、ルールに記述されたトポロジ情報に対応するＩＴ装置の検索条件を求めてＳ４に移る。実施形態では、ルールＲ１のトポロジ情報として、ｉＳｃｓｉＩｎｉｔｉａｔｏｒを持つ計算機と、ｉＳｃｓｉＴａｒｇｅｔで識別されるｉＳＣＳＩのポートを持つストレージ装置、およびこれらに接続されたＩＰスイッチがルールＲ１を適用するＩＴ装置の検索条件となる。検索条件は、予めルールの記述に対して定義されているものとする。

Ｓ１０４においては、トポロジ情報のうち、クライアント側のＩＴ装置を管理対象のＩＴ装置の構成情報から検索する。なお、構成情報の検索は、構成情報を管理しているものがデータベースであればデータベースに対して行い、ファイルであればファイルに対して行い、検索対象とする記憶メディアやデバイスなどは問わない。実施形態では、ルールＲ１のトポロジにおいてクライアントを示す、ｉＳｃｓｉＩｎｉｔｉａｔｏｒを持つ計算機を構成情報から検索する。本実施例では、計算機Ｎ１０又は計算機Ｎ１１がｉＳｃｓｉＩｎｉｔｉａｔｏｒを持つものとすると、計算機Ｎ１０と計算機Ｎ１１の識別情報が検索により見つかる。

Ｓ１０５においては、Ｓ１０６以降の処理を複数の計算機の場合について実行するため、検索で見つかったＩＴ装置で未選択なＩＴ装置があるかを判断する。本実施例では、計算機Ｎ１０と計算機Ｎ１１が未選択なＩＴ装置であるためＳ１０６に進む。

Ｓ１０６においては、未選択なＩＴ装置から１つを選択し、選択済みとする。本実施例では計算機Ｎ１０を選択し、計算機Ｎ１０を選択済みとしてＳ１０７に進む。

Ｓ１０７においては、Ｓ１０６に於いて選択したＩＴ装置とトポロジ上で対向となるサーバ側のＩＴ装置の情報を取得する。ここでサーバ側のＩＴ装置の情報としては、サーバ側のＩＴ装置を識別する情報（ＩＰアドレス、又はホスト名、ＦＱＤＮなど）や、提供するサービスに関する情報（ファイルサーバにおける公開ファイルシステムの公開名（共有名とも呼ばれる）や、ストレージ装置のディスクボリュームを識別するＬＵＮ番号、あるいは接続先のｉＳＣＳＩ名、またはＦＣ ＰｏｒｔのＷＷＮ）がある。本実施例では、計算機Ｎ１０に対向するサーバ側のストレージ装置の情報として、図８に示す接続先のｉＳＣＳＩ名であるＣｏｎｎｅｃｔｅｄＩｓｃｓｉＴａｒｇｅｔを取得する。

Ｓ１０８においては、Ｓ１０７で取得したサーバ側のＩＴ装置に関する情報のうち、その情報に対応するＩＴ装置を検索していないものが存在するかを判断し、存在する（ＹＥＳ）場合にはＳ１０９に、存在しない（ＮＯ）場合にはＳ１０５に移る。本実施例では、図８に示すように少なくとも３つの未検索の情報が存在する（ＹＥＳ）ため、Ｓ１０９に移る。

なお、ここで図８に含まれる情報を説明すると、当該情報にはＩＴ装置（より具体的には計算機）を示す識別情報と、当該ＩＴ装置が接続先とするストレージ装置のｉＳＣＳＩにおける識別情報を有する。

Ｓ１０９においては、Ｓ１０７で取得したサーバ側のＩＴ装置の情報のうち、未検索のものを１つ選択し、この情報を元にサーバ側のＩＴ装置を管理対象の構成情報から検索する。本実施例では、計算機Ｎ１０より取得した図８に示されるＣｏｎｎｅｃｔｅｄＩｓｃｓｉＴａｒｇｅｔのＬ２０１行で示されるｉＳＣＳＩ名をｉＳｃｓｉＴａｒｇｅｔに持つストレージ装置を管理対象の構成情報から検索する。

Ｓ１１０において、Ｓ１０９の検索の結果、管理対象のＩＴ装置に該当するものが存在しない（ＮＯ）場合には、Ｓ１１１に移る。一方で、管理対象のＩＴ装置に該当するものが存在する（ＹＥＳ）場合には、通常のルール適用処理と同様となり、Ｓ１２１に移る。本実施例では、管理対象のストレージ装置のｉＳｃｓｉＴａｒｇｅｔに関する構成情報は図９に示したものとする。このとき、図８のＬ２０１行のＣｏｎｎｅｃｔｅｄＩｓｃｓｉＴａｒｇｅｔと一致するｉＳｃｓｉＴａｒｇｅｔを持つストレージ装置は図９に示したように管理対象には存在しないため、Ｓ１１１に移る。

なお、ここで図９に含まれる情報を説明すると、当該情報にはストレージ装置を示す識別情報と、当該ストレージ装置が有するｉＳＣＳＩにおける識別情報を有する。

なお、発見済みの一つ以上のＩＴ装置毎に当該装置がイベント取得対象であるかどうか（すなわち当該装置が監視される装置であるかどうか、言い方を代えると当該装置に対するイベント取得を許可しているか抑止しているか）を示すイベント取得可否情報が構成情報Ｔ０に含まれており、当該データを参照することでＳ１１０の判断を行う。

Ｓ１１１においては、運用管理システムにおいて既に発見したことがあるＩＴ装置であるかどうかを判断する。すなわち、運用管理システムにおいて、一度でも存在を発見、又は確認、又は管理されたことがあるＩＴ装置であって、部分的に運用管理システムが静的構成情報を持つようなＩＴ装置であるかどうかをここでは判断する。本実施例では、図８のＬ２０１行のＣｏｎｎｅｃｔｅｄＩｓｃｓｉＴａｒｇｅｔと一致するｉＳｃｓｉＴａｒｇｅｔを持つストレージ装置に関する構成情報は一切なく、発見済みリソースでない（ＮＯ）であるものとしてＳ１１２に進む。

なお、Ｓ１１１の判断は構成情報に当該装置に関する情報（例えばイベント取得可否情報）が存在するかどうかで判別する方法がある。

Ｓ１１２において、図８のＬ２０１行のＣｏｎｎｅｃｔｅｄＩｓｃｓｉＴａｒｇｅｔと一致するｉＳｃｓｉＴａｒｇｅｔを持つストレージ装置を、管理外のＩＴ装置から発見を試みる。Ｓ１１２の管理外ＩＴ装置の有無の検索方法の一例としては、構成情報より取得、又はユーザにより入力された対象となるリソースに対応するＩＰアドレスやＦＱＤＮなどの通信識別子、又は構成情報から取得、又はユーザにより入力された対象となるリソースを含むネットワークセグメントに対応するＩＰアドレスであるネットワークアドレス内のＩＰアドレス、又はＦＱＤＮなどの通信識別子に対して、対象となるリソースに関するサービス提供を求めるリクエストを送信し、その応答の有無を待って対象とするリソースの存在を確認する方法がある。本実施例では、図３に示すＩＴシステムから発見を試みる。

Ｓ１１３においては、Ｓ１１２で試みた発見が成功したかどうかを判断する。成功した（ＹＥＳ）場合にはＳ１４に移る。さもなければ（ＮＯ）Ｓ１１６に移る。本実施例では、図３に示すストレージ装置Ｕ３が該当するストレージ装置として発見されたものとしてＳ１１４に移る。

Ｓ１１４においては、Ｓ１１３に於いて発見したＩＴ装置を、運用管理システムの管理対象とすることができるかどうかを判断する。管理対象とすることができるかどうかの判断は、その運用管理システムが監視・管理するために必要となる情報が、対象のＩＴ装置から取得できるかどうかで判断する。監視・管理するために必要となる情報については、運用管理システムごとに様々であるが、共通的なものとしては、そのＩＴ装置を識別する情報、例えばＩＰアドレス、又はＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）、又は何かしらのユニークな識別情報（番号）、装置名（ホスト名）、ＦＱＤＮなど、少なくとも１つ以上の情報である。

また、そのＩＴ装置を構成するハードウェアの種類または個数に関する一つ以上の情報も、ある程度は取得できるほうが好ましい。本発明では、運用管理サーバＮ０が所定の判断基準を持ち、その判断基準によってこの判断を行うものとする。本実施例では、ストレージ装置Ｕ３に関する情報として、このストレージ装置がｉＳＣＳＩのポートを備え、そのｉＳＣＳＩポートのｉＳＣＳＩ名としてｉＳｃｓｉＴａｒｇｅｔの情報が取得できるものとし、管理対象にすることができると判定されたものとしてＳ１１５に進む。なお、続く処理にて当該装置を管理対象とする場合があるため、本ステップにて当該ＩＴ装置からイベント情報が受信可能であることを確認処理に加え、確認できた場合のみＳ１１５に進むようにしてもよい。

Ｓ１１５においては、Ｓ１１３において発見されたＩＴ装置を管理対象とするかどうかをユーザに提示する。本実施例では、ストレージ装置Ｕ３が計算機Ｎ１のストレージサーバとして発見されたことと、ストレージ装置Ｕ３を管理対象に入れるかどうかを提示する。提示画面は、図１０である。

Ｓ１１６においては、運用管理サーバＮ０（特にルールエンジン）は管理画面出力装置からの入力を受信する。

Ｓ１１７において、ユーザが発見したＩＴ装置を管理対象したかどうかを判断し、管理対象とした（ＹＥＳ）場合にはＳ１１８に進み、そうでなければ（ＮＯ）Ｓ１１９に進む。本実施例においては、ユーザはストレージ装置Ｕ３を管理対象としなかったものとしＳ１１９に進む。

Ｓ１１８においては、ユーザが管理対象に含める判断をしたＩＴ装置に対して情報を取得し、管理対象のＩＴ装置として構成管理に情報を格納する。本実施例では、この時点ではこちらの分岐には来ていない。

Ｓ１１９においては、クライアントと対向となるサーバを、管理外ＩＴ装置として管理外ＩＴ装置管理テーブルに取得可能な情報について格納して管理し、Ｓ１２０に進む。本実施例では、ストレージ装置Ｕ３について、装置を識別する情報としてＦＱＤＮと、ストレージ装置のＩＰポートのｉＳＣＳＩ名であるｉＳｃｓｉＴａｒｇｅｔが取得可能な情報であるものとし、これを図１１の管理外ＩＴ装置管理テーブルＴＬ３に格納する。

なお、ここで図１１の説明を行うと、管理害ＩＴ装置管理テーブルＴＬ３には発見した管理外ＩＴ装置の各々について以下の情報を含む。
（Ａ）管理外ＩＴ装置の識別情報
（Ｂ）管理外ＩＴ装置の種別であるＣ４０１
（Ｃ）管理外ＩＴ装置の通信識別情報であるＣ４０２
（Ｄ）管理外ＩＴ装置のサービスにアクセスするために必要な識別情報であるＣ４０３
Ｓ１２０においては、管理外ＩＴ装置の識別情報を、該ＩＴ装置が管理外であることがわかるような印をつけた上で、図１２に示すようにルール適用先管理テーブルＴＬ１に格納する。本実施例では、ストレージ装置Ｕ３に関する管理外ＩＴ装置管理テーブルの情報を元に識別情報を、ルール適用先管理テーブルＴＬ１に格納する。格納した後、選択したクライアント側のＩＴ装置に対向するサーバ側のＩＴ装置に関する検索情報が存在するかについてＳ８に戻る。

本実施例において、Ｓ１０８に戻ると、Ｓ１０７に於いて取得したサーバ側のストレージ装置に関する検索情報で未検索のものが存在するかを判断するが、計算機Ｎ１０に関するサーバ側のストレージに関する検索情報は図８のＬ２０２の行が存在するため、Ｓ１０９に移る。

Ｓ１０９に移ると、Ｌ２０２に対応するストレージ装置を構成管理にて検索する。実施例では図９のように、Ｌ２０２に対応するストレージ装置が存在するため、Ｌ２０２に対するＩＴ装置は管理対象であることがわかるので、Ｓ１１０において管理対象のＩＴ装置であると判断してＳ１２０に移る。Ｓ１２０では、管理対象のＩＴ装置としてストレージ装置Ｎ４０と計算機Ｎ１０のリストをルールＲ１の適用先ＩＴ装置として図１１のルール適用先管理テーブルのＬ１０１に格納する。

以上のステップにより、計算機Ｎ１０に対して論理ボリュームを提供している管理対象外のストレージ装置Ｕ１を含めてルールＲ１を適用できるようになる。

次に図１１のルール適用先管理テーブルを用いて、図２のＳ６の一例、つまり管理外のストレージ装置Ｕ１で障害が発生した場合に、前記ストレージ装置Ｕ１を障害の根本原因として画面表示する処理について説明する。

ストレージ装置Ｕ１からコントローラの障害イベントが発生し、図１のイベント解析処理部Ｃ１２において図１１のルール適用先管理テーブルを元にルールによるイベント相関によって障害の原因箇所を特定されると、解析結果の情報が、画面表示部Ｃ２に送信される。画面表示部Ｃ２では、図１６のフローにもとづき、根本原因のＩＴ装置が管理対象かどうかを判断して、適切な画面を画面表示装置Ｍ１に表示させる。

図１６のステップ６０１から６０３において画面標示部Ｃ２において、図１７に示したルールエンジンにおける障害解析の結果を示す障害解析結果データＤ１をルールエンジンＣ１から取得する。なお、ルールエンジンＣ１（特にイベント処理解析部Ｃ１２）は図２のＳ４及び図４及び図５にて説明した処理を行っている。

障害解析結果データＤ１は、障害原因ＩＴ装置に関する情報である障害原因ＩＴ装置情報と、運用管理システムが受信した管理対象のＩＴ装置のイベントに関する情報である受信イベントリストと、を含むデータから成る。障害原因ＩＴ装置情報Ｄ１１は、障害原因ＩＴ装置を示す情報と、障害箇所の部位に関する情報を含む。障害箇所の部位に関する情報は、管理対象外のＩＴ装置である障害原因ＩＴ装置からどの程度の障害情報を取得できるかによる。全く障害情報を取得できない場合には、図１７のように不明となる。受信イベントリストは、この障害について定義されているルールにおいて、関連がある受信イベントに関する情報である、受信イベントの発信元に関する情報である受信イベント発信元と、イベントの内容に関する情報を示すイベント種別とを含む。

Ｓ６０４において、取得した障害解析結果データＤ１１の障害原因ＩＴ装置の情報から、管理対象か管理対象外かを判断する。本実施例では管理対象外のＩＴ装置であるため、Ｓ６０５に進む。

Ｓ６０５では、障害解析結果データＤ１１の障害原因ＩＴ装置の情報を元に図１１の管理外ＩＴ装置管理テーブルを検索して、該管理外ＩＴ装置に関する情報を取得してＳ６０６に進む。本実施例ではストレージ装置Ｕ１について図１１のＬ４０１から取得する。

Ｓ６０６では、Ｓ６０５にて取得した情報を含めて、発生した障害の根本原因が、管理外のＩＴ装置が原因であることを画面に表示する。その際の画面の構成例は、図１８のように、管理外ＩＴ装置が障害の根本原因であることを伝えるメッセージと、障害の原因について解析した結果である障害解析結果と、発生した障害に関して運用管理システムが検知している障害情報、例えば受信しているイベントなど、とを含んだウィンドウ、又はダイアログなど、画面表示を画面出力装置Ｍ１に出す。本実施例の管理外のＩＴ装置であるストレージＵ１の障害が根本原因であるケースにおける画面表示例は、図１９のようになる。障害原因ＩＴ装置が、管理対象外であることがわかる情報と、そのＩＴ装置の種別が何であるか、例えばＩＰ−ＳＡＮストレージ装置であり、ＩＴ装置の識別情報として例えばＩＰアドレスが１９２．１６８．１００．１５であることを含むような画面表示である。

以上のステップにより、管理対象外ＩＴ装置のストレージ装置Ｕ１に障害があった場合に、ルールＲ１のようなＩＰ−ＳＡＮストレージの障害が管理対象外で起こった場合について適用できるようになり、根本原因が管理対象外のＩＰ−ＳＡＮストレージであることを画面に表示することができる。

（ルールＲ２についての処理フロー）
ルールＲ２について、図３のＩＴシステムを対象とした実施例をもとにフローを説明する。

Ｓ１０１においてルールＲ２があるためＳ１０２に進み、Ｓ１０２では、ルールＲ２を読み込み、Ｒ２に読み込み済みの印をつける。Ｓ１０３において、ルールＲ２に記述されたトポロジ情報として図４の（２）のＦＣ−ＳＡＮトポロジとして、クライアント側にＦｉｂｒｅ ＣｈａｎｎｅｌのＨｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ、すなわちＦｃＨｂａＴ２１１を持つ計算機Ｔ２１、ＦＣスイッチＴ２２を介して、サーバ側にＦｉｂｒｅ ＣｈａｎｎｅｌのポートであるＦｃＰｏｒｔＴ２３１を持つストレージ装置Ｔ２３が接続されているトポロジを検索条件に定める。

Ｓ１０４において、クライアント側のＩＴ装置として、ＦｃＨｂａを持つ計算機である計算機Ｎ１３が見つかったものとする。

Ｓ１０５において、計算機Ｎ１３が未選択なＩＴ装置であるので、Ｓ１０６に進む。

Ｓ１０６において、計算機Ｎ１３を選択して、選択済みとする。

Ｓ１０７において、図１３に示したように計算機Ｎ１３より、接続先のサーバ側のストレージ装置のＦｉｂｒｅ ＣｈａｎｎｅｌのポートであるＦＣ ＰｏｒｔのＷＷＮを示すＣｏｎｎｅｃｔｅｄＦｃＰｏｒｔＷＷＮ Ｃ５０２を収集する。

なお、図１３のＦＣ−ＳＡＮストレージ装置の接続情報について説明すると、個々のＩＴ装置に対応する情報として、接続先のストレージ装置が有するＦｉｂｒｅＣｈａｎｎｅｌの通信識別情報を含む。

Ｓ１０８において、計算機Ｎ１３における接続先のストレージ装置に関する検索情報であるＣｏｎｎｅｃｔｅｄＦｃＰｏｒｔＷＷＮについて、未検索であるためＳ１０９に進む。

Ｓ１０９において、計算機Ｎ１３で取得したＣｏｎｎｅｃｔｅｄＦｃＰｏｒｔＷＷＮとして、Ｌ５０１行目のＣ５０２の値を用いて、構成管理において、このＷＷＮをＦｃＰｏｒｔのＷＷＮに持つストレージ装置を検索する。

Ｓ１１０において、Ｓ１０９で検索の結果、図１３のＬ５０１行目のＣ５０２の値をＦｃＰｏｒｔのＷＷＮとして持つストレージが図１４に示すように管理対象の構成情報には存在しなかったため、Ｓ１１１に進む。

なお、ここで図１４に含まれる情報を説明すると、当該情報にはストレージ装置を示す識別情報と、当該ストレージ装置が有するＦｉｂｒｅＣｈａｎｎｅｌにおける通信識別情報を有する。

Ｓ１１１において、発見済みのストレージ装置の中で、図１３のＬ５０１行目のＣ５０２の値をＦｃＰｏｒｔのＷＷＮとして持つストレージ装置Ｕ２を発見したため、Ｓ１１５に進む。

Ｓ１１５において、発見済みのストレージ装置Ｕ２を管理内に含めるように提案する画面を表示する。図１０は、ルールＲ１における画面表示例であるが、画面表示の構成は基本的に同様であり、メッセージの中身が実際のＩＴ装置のものに置き換わるのみである。

Ｓ１１６にて管理者よりストレージ装置Ｕ２の識別情報と当該装置を管理対象とする指示情報を受信する。

Ｓ１１７において、ユーザが管理対象に含めたかどうかを確認し、本実施例では管理対象に含めたためＳ１１８に進む。

Ｓ１１８において、管理対象として新たに追加したストレージ装置Ｕ２について、管理対象のＩＴ装置として取得が必要な情報を収集する。管理対象として取得する情報は、イベント情報と構成管理情報である。

Ｓ１２１においては、ストレージ装置Ｕ２を管理対象のＩＴ装置として、計算機Ｎ１４とともにルールＲ２の適用先ＩＴ装置としてルール適用先管理テーブルに登録する。本ケースの例では図１２に示したルールのカラムＣ１０１と、そのルールの適用先となるＩＴ装置リストを格納するカラムＣ１０２から成る、テーブル状のデータ構造に登録する。

以上により、ルールＲ２に対して、管理対象外のＩＴ装置であるＦＣ−ＳＡＮストレージ装置の障害解析が従来のルールベースのイベント相関で行えるようになる。
なお、障害解析の結果データを元に、管理対象外のＩＴ装置であるＦＣ−ＳＡＮストレージが障害の根本原因であると画面表示を出す処理については、ルールＲ１の管理対象外のＩＰ−ＳＡＮストレージを障害の根本原因であると画面表示した処理と同様にして図１６のステップで行う。

上記の処理ステップにより、ルールＲ２に対しても、管理対象外ＩＴ装置のストレージ装置Ｕ２に障害があった場合に、ルールＲ２のようなＦＣ−ＳＡＮストレージの障害が管理対象外で起こった場合について適用できるようになり、根本原因が管理対象外のＦＣ−ＳＡＮストレージであることを画面に表示することができる。
（ルールＲ３についての処理フロー）
ルールＲ３について、図３のＩＴシステムを対象とした実施例をもとにフローを説明する。

Ｓ１０１においてルールＲ３があるためＳ１０２に進み、Ｓ１０２では、ルールＲ３を読み込み、Ｒ１０３に読み込み済みの印をつける。Ｓ１０３において、ルールＲ３に記述されたトポロジ情報として図４の（３）のファイルサーバ・クライアントのトポロジとして、クライアント側に公開されているファイルシステムをマウントしていることを示すＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅＴ３１１を持つ計算機Ｔ３１、ＩＰスイッチＴ３２を介して、サーバ側に他の計算機に公開しているファイルシステムを持つことを示すＥｘｐｏｒｔｅｄＦｉｌｅＳｈａｒｅＴ３３１を持つ計算機Ｔ３３が接続されているトポロジを検索条件に定める。

Ｓ１０４において、図４の（３）のトポロジのクライアント側のＩＴ装置として、図３の計算機Ｎ１０が見つかったものとする。

Ｓ１０５において、検索されたクライアント側のＩＴ装置として計算機Ｎ１０があり、未選択であるため、Ｓ１０６に進む。

Ｓ１０６において、未選択のクライアント側のＩＴ装置として図３の計算機Ｎ１０を選択し、選択済みとする。

Ｓ１０７において、計算機Ｎ１０と、図４の（３）のトポロジのサーバ側のＩＴ装置として対向する計算機の検索情報として、どのファイルサーバの公開ファイルシステムをマウントしているかを示すＩｍｐｏｒｔｅｄＦｉｌｅＳｈａｒｅの情報を取得する。クライアント側から取得するファイルサーバに関する情報を管理するテーブルとして図１５のようなクライアント側のコンピュータのカラムＣ７０１と、それに対応するファイルサーバに関する識別情報のカラムＣ７０２と、ファイルサーバの公開名に関するカラムＣ７０３を含むデータ構造、例えばテーブルなどで管理する。なお、クライアント側から取得するファイルサーバに関する情報は、予め構成情報として図１５のテーブルで取得済みであっても構わないし、Ｓ７の処理においてクライアント側のＩＴ装置から取得してきても構わない。すなわち取得するタイミングは、Ｓ１０７の処理が完了するまでに行われていればよい。

なお、ここで図１５に含まれる情報を説明すると、当該情報には個々のファイルサーバ毎に以下の情報を含む。
（Ａ）ファイルサーバーのＩＴ装置としての識別情報
（Ｂ）一つ以上のファイルサーバとしての識別情報と公開名
Ｓ１０８において、Ｓ１０７で取得したクライアント側のファイルサーバに関する情報は、図１５のＬ７０１行であり、未検索であるためＳ９に進む。

Ｓ１０９において、図１５のＬ７０１行目のファイルサーバの識別情報のカラムＣ７０２の値、すなわちｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍというＦＱＤＮを持つＩＴ装置を検索する。

Ｓ１１０において、管理対象の構成情報Ｔ０の中にｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍというＦＱＤＮを持つ計算機が存在しないことから、Ｓ１１１に進む。

Ｓ１１１において、発見済みリソースの中にｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍ というＦＱＤＮを持つ計算機が存在しないことから、Ｓ１１２に進む。

Ｓ１１２において、ｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍという計算機の発見を試みる。発見は、ＤＮＳサーバに問い合わせてＩＰアドレスを解決し、そのＩＰアドレスに対してｐｉｎｇによりか存在を確認した上で、ｔｅｌｎｅｔ、又はｓｓｈ、又はＷｉｎｄｏｗｓ（登録商標）のリモート接続などによりアクセスを試みる。本実施例では、ｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍに対するＩＰアドレスに対するｐｉｎｇは成功を返し、存在が確認できるが、そのサーバの認証情報を持たないため、その他のアクセスは失敗してログインできないものとしてＳ１１４に進む。

Ｓ１１４において、発見したｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍの計算機は、ｐｉｎｇでの応答を返すものの、それ以外の情報が取得できず、管理対象とすることができないのでＳ１１９に進む。

Ｓ１１９において、ｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍの計算機を図１１の管理外ＩＴ装置管理テーブルに登録する。具体的には図１０のＬ４０３のように、ファイルサーバ識別情報と、サービス識別情報にクライアント側で取得した情報を格納する。

Ｓ１２０において、クライアント側の計算機Ｎ１０とｅｘｐｏｒｔｆｓ．ｄｏｍａｉｎ２．ｃｏｍの計算機Ｕとのペアに対するルール適用情報を生成する。具体的には、図１２１のＬ１０７のように、ルールＲ３に対して、適用先ＩＴ装置リストに、計算機Ｎ１０と管理外ＩＴ装置である計算機Ｕ３を登録する。

以上により、計算機Ｎ１０のファイルサーバである管理外のＩＴ装置である計算機Ｕ３についても障害解析が行えるようになる。

同様にして、Ｓ１０１からＳ１０４のステップにより、ルールＲ３についてクライアント側のＩＴ装置として計算機Ｎ１１が見つかった場合の実施形態の処理フローを説明する。Ｓ１０５からＳ１０７のステップにより、計算機Ｎ１１に対するファイルサーバとして図１５のＬ７０３の行に示したファイルサーバに関する情報を取得する。Ｓ１０９において管理対象のＩＴ装置に図１５のＬ７０３行で示されたファイルサーバは見つからないため、Ｓ１１１に進む。Ｓ１１１においては、発見済みのリソースの中に図１５のＬ７０３行で示されたＩＰアドレスを持つ計算機Ｕ５が存在するので、Ｓ１１５に進む。

Ｓ１１５において、計算機Ｕ５を管理対象に含めるように提案する画面を表示し、Ｓ１１６にてユーザ入力としてユーザが計算機Ｕ５を管理対象とする指示を受信する。

Ｓ１１７において、Ｓ１１６ユーザが計算機Ｕ５を管理対象とする指示を受信したため、Ｓ１１８に進む。

Ｓ１１８において、計算機Ｕ５を管理対象とするための情報として、発見済みリソースとして保持していたＩＴ装置の識別情報、アクセスのための情報の他に、計算機Ｕ５の接続デバイスの構成情報と、稼動状態と、性能情報とを含む監視情報を取得して、構成管理Ｃ３の管理対象の構成情報Ｔ０に格納する。

Ｓ１２１において、管理内ＩＴ装置として計算機Ｎ１１をクライアント、計算機Ｕ５をファイルサーバとするトポロジに対してルールＲ３を適用できるように、図１２のＬ１０８行目のようなデータ構造としてルールメモリに格納する。

以上により、発見済みのＩＴ装置で、なおかつ管理対象外であったファイルサーバの計算機Ｕ５に対する障害解析が、図２のフローにしたがって行え、画面表示部Ｃ２において図１６のフローに行うことで、画面表示装置Ｍ１に障害原因を出力することができるようになる。

（ルールＲ４についての処理フロー）
ルールＲ４について、図３のＩＴシステムを対象とした実施例をもとにフローを説明する。

Ｓ１０１からＳ１０４のステップにより、ルールＲ４についてクライアント側のＩＴ装置として計算機Ｎ１０を見つける。Ｓ１０５からＳ１０７のステップにより、計算機Ｎ１０に対するＤＮＳサーバの検索情報として、計算機Ｎ１０よりＤＮＳサーバのＩＰアドレス１９２．１６８．１００．１を取得する。 Ｓ１０８からＳ１１０のステップにより、取得したＩＰアドレス１９２．１６８．１００．１を利用して構成管理Ｃ３の管理対象の構成情報Ｔ０にＤＮＳサーバが存在しないことを確認し、Ｓ１１１に進む。Ｓ１１１では、ＤＮＳサーバは発見済みＩＴ装置ではないことを判断して、Ｓ１１２に進み、Ｓ１１２において実ＩＴシステムからＩＰアドレス１９２．１６８．１００．１のノードに対するアクセスを試みる。アクセスの結果、ｐｉｎｇによるネットワーク到達が確認できたものの、認証情報を持たないためログインはできず、Ｓ１１４において管理対象とすることができないと判断してＳ１１９に進む。Ｓ１１９においては、ＩＰアドレス１９２．１６８．１００．１の計算機を管理対象外ＩＴ装置として図１１のＬ４０４に示したようにＤＮＳサーバとして識別情報Ｕ４で情報を格納・管理してＳ１２０に進む。Ｓ１２０において、クライアントの計算機Ｎ１０と、ＤＮＳサーバである管理外のＩＴ装置の計算機Ｕ４をルール４の適用先ＩＴ装置リストとして図１２のＬ１０９行のように格納する。

以上のステップにより、管理外のＤＮＳサーバである計算機Ｕ４の障害解析が、従来のルールによるイベント相関により解析できるようになり、障害原因として管理外のＤＮＳサーバを特定することができるようになる。

図３のそのほかのＩＴ装置に対するルール４の適用についても同様にして、管理外のＤＮＳサーバである計算機Ｕ４に対して適用情報が生成されることで行える。

また、他のルールの実施例と同様にして、図１６のフローを画面表示部Ｃ２にて行うことで、管理外のＩＴ装置であるＤＮＳサーバが障害の根本原因であることを画面に表示することができる。

本発明の第２の実施形態は、第１の実施形態において図２に示した障害解析の全体処理フローの処理手順を、図２０に示したように、ルール適用部Ｃ１１における適用情報を作成するステップＳ４ｂをイベント受信するステップＳ３ｂよりもあとで、なおかつイベント解析部Ｃ１２におけるイベント解析処理のステップＳ５ｂよりも前のステップで行う。この第２実施形態と、第１実施形態の違いは、ルールの適用情報を作成するタイミングのみである。

上記のように、ルールの適用情報のタイミングを変えて本発明を実施しても効果は損なわれず、管理対象外のＩＴ装置を障害の根本原因装置であると画面に表示することは可能である。

以上、本願明細書の実施例１と実施例２による複数の情報処理装置と画面出力装置とに接続され、プロセッサとメモリを有する運用管理サーバにおける前記複数の情報処理装置で発生するイベントの解析を実現するプログラムは以下の処理の一部または全てを有する。
（ａ）前記複数の情報処理装置の各々が、クライアントとしてネットワークサービスを用いるためにアクセス対象とする前記複数の情報処理装置の一部であるサーバ装置の識別情報を、前記メモリが有する構成情報に格納する構成情報格納処理。
（ｂ）前記複数の情報処理装置の一部であって、前記運用管理サーバがイベント情報を取得する対象である複数のイベント取得対象装置を前記メモリが有する構成情報に登録する登録処理。
（ｃ）前記複数の情報処理装置で発生する前記ネットワークサービスに関連した第一のイベント種別を含むイベントと、前記ネットワークサービスに関連した前記第一のイベント種別とは異なる第二のイベント種別を含むイベントと、を検知した場合に、前記第二のイベント種別に対応するイベントの発生が原因で前記第一のイベント種別に対応するイベントが発生し得ることを示す相関解析ルール情報を前記メモリに格納するルール格納処理。
（ｄ）前記複数のイベント取得対象装置から収集した複数の前記イベント情報を前記メモリに格納するイベント格納処理。
（ｅ）前記相関解析ルール情報を元に、前記メモリに格納した複数の前記イベント情報から、前記第一のイベント種別を含む第一のイベント情報を特定するイベント情報特定処理。
（ｆ）前記構成情報を元に、前記第一のイベント情報を送信したイベント取得対象装置の一つである第一イベント取得対象装置と、前記第一のイベント種別に対応する前記ネットワークサービスにおける前記第一イベント取得対象装置のサーバ装置である障害要因装置とを特定する、要因特定処理。
（ｇ）前記相関解析ルール情報と前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置でない場合に、前記第一イベント取得対象装置と前記第一のイベント種別と前記障害要因装置と前記第二のイベント種別とを特定する情報を前記画面出力装置へ送信することで、前記第一イベント取得対象装置で発生した前記第一のイベント情報に対応したイベントが、前記障害要因装置で前記第二のイベント種別のイベントが発生したことが要因と推定されることを前記画面出力装置へ表示させる解析結果送信処理。

さらには、前記相関解析ルール情報は、前記第一のイベント種別が発生した前記複数の情報処理装置の一つである第一情報処理装置と、前記第二のイベント種別が発生した前記複数の情報処理装置の一つである第二情報処理装置と、の間のトポロジ条件を示すトポロジ条件情報を含み、前記要因特定ステップは、前記トポロジ条件情報に基づいて前記障害要因装置を特定してもよい。このような処理によってイベントが発生した情報処理装置が実際に用いている情報処理装置に限定して推定を提示できるため、より運用管理サーバの利用者に利便性の高い。

また、運用管理サーバは以下の処理を有してもよい。
（ｈ）前記相関解析ルール情報と前記構成情報に基づいて、前記複数のイベント取得対象装置のサーバ装置であって、前記複数のイベント取得対象装置に含まれない、前記複数の情報処理装置の一部であるイベント関連情報処理装置を特定する、関連装置特定処理。
（ｉ）前記イベント関連情報処理装置からイベント情報の取得が可能か調査する、イベント情報取得可否調査処理。
（ｊ）前記調査の結果を元に、前記イベント関連情報処理装置からイベント情報の取得が可能な場合は前記イベント関連情報処理装置を特定する情報を前記画面出力装置へ送信することで、前記イベント関連情報処理装置からイベント情報の取得が可能であることを前記画面出力装置へ表示させる、イベント情報取得対象追加提案処理。

このような処理は、情報処理装置の管理者または管理方法の変更によって新たに運用管理サーバでイベント監視が必要または可能となった時点から迅速に、登録忘れをせずに運用管理サーバへの登録を促進することができる。

さらには、前記イベント情報取得可否調査処理は、前記複数の情報処理装置であって予め調査範囲として設定されたＩＰアドレスの範囲に含まれるＩＰアドレスを有する情報処理装置に対して、前記運用管理サーバが所定の手順に基づくアクセスを行った結果に基づいてもよい。情報処理装置（特にインターネットを介してアクセスするサーバ計算機）には不正アクセスや不正攻撃を防止するために当該装置外部からのアクセスを監視している場合があり、当該調査処理によるアクセスを行った場合もアクセス監視により不正アクセスや不正攻撃と見なされることがある。そのため、明らかにイベント監視の対象としない情報処理装置のＩＰアドレス、またはイベント監視対象になりうる情報処理装置のＩＰアドレスの範囲を特定することで、こうした不正アクセスや不正攻撃と誤認されるような通信を抑止することができる。

さらには、前記障害要因装置はコントローラを有し、論理ボリュームを提供するストレージ装置であって、前記ネットワークサービスは前記論理ボリュームをブロックアクセス形式のプロトコル（例えばＦｉｂｒｅＣｈａｎｎｅｌやｉＳＣＳＩがある）によって提供するサービスであって、前記第一のイベント種別が前記ストレージ装置の障害発生であり、前記第一のイベント種別が前記論理ボリュームへのアクセス失敗であってもよい。

さらには、前記障害要因装置は前記ネットワークサービスとしてＤＮＳを提供する計算機であって、前記第一のイベント種別がＤＮＳ要求失敗であり、前記第一のイベント種別がＤＮＳサーバの通信断絶であってもよい。

さらには、前記障害要因装置は前記複数の情報処理装置の少なくとも一つからデータを受信するＮＩＣを有し、格納したファイルを前記複数の情報処理装置の少なくとも一つに提供するファイルサーバ計算機であって、前記ネットワークサービスは前記ファイルサーバ計算機が格納したファイルを共有するネットワークファイル共有サービスであって、前記第一のイベント種別が前記ファイルサーバの障害発生（例えばＮＩＣの障害発生、ファイルサーバが有するプロセッサが実行するソフトウェアの不具合の発生、その他ファイルサーバの通信機能が停止する障害の発生）であり、前記第一のイベント種別が前記ネットワークファイル共有サービスで提供されたファイルへのアクセス失敗であってもよい。

さらには、前記相関解析ルール情報と前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置の一つの場合に、複数の前記イベント情報から前記第二のイベント種別を含み、前記障害要因装置が取得元である第二のイベント情報を特定し、前記第一イベント取得対象装置と前記第一のイベント情報と前記障害要因装置と前記第二のイベント情報とを特定する情報を前記画面出力装置へ送信することで、前記第一イベント取得対象装置で発生した前記第一のイベント情報に対応したイベントが、前記障害要因装置で発生した前記第二のイベント情報に対応したイベントが発生したことが要因であることを前記画面出力装置へ表示させてもよい。

さらには、前記第一情報処理装置が計算機であり、前記第二情報処理装置がストレージ装置であり、前記トポロジ条件情報は、前記計算機と前記ストレージ装置とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ストレージ装置に対応する通信識別情報との組み合わせを含めても良い。なお、これら通信識別情報としてはｉＳＣＳＩ名と、ＩＰアドレスと、ＦｉｂｒｅＣｈａｎｎｅｌにおけるＷＷＮとの少なくとも一つが考えられる。

さらには、前記第一情報処理装置が計算機であり、前記第二情報処理装置はファイル共有サービスによって格納したファイルを前記複数の情報処理装置へ提供するファイルサーバ計算機であり、前記トポロジ条件情報は、前記計算機と前記ファイルサーバ計算機とが接続するトポロジの接続関係を示す前記計算機に対応する通信識別情報と前記ファイルサーバ計算機に対応する通信識別情報又は前記ファイルを公開するエクスポート名との組み合わせを含めても良い。

さらには、前記第一情報処理装置は計算機であり、前記第二情報処理装置がネットワーク共有サービスとしてＤＮＳを前記複数の情報処理装置に提供するＤＮＳサーバ計算機であり、前記トポロジ条件情報は、前記計算機と前記ＤＮＳサーバ計算機とが接続するトポロジの接続関係を示す前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報との組み合わせを含めても良い。なお、前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報とは、ＩＰアドレス又はＦＱＤＮが考えられる。

さらには、前記運用管理サーバは一つ以上の計算機から構成されてもよい。

本発明の運用管理システムの全体構成図を示したものである。 本発明における実施形態の１つである障害解析の全体処理フローを模式的に示したものである。 本発明が対象とするＩＴシステムの代表的な構成例の一つを模式的に示したものである。 本発明の運用管理システムで用いられる相関解析ルール情報を模式的に示したものである。 図４に示した相関解析ルール情報で適用対象として指定されるトポロジを模式的に示したものである。 ルールの適用先となるＩＴ装置のリストを管理するテーブル状のデータ構造の一例であるルール適用先管理テーブルを模式的に示したものである。 本発明の実施形態の１つである相関解析ルール情報の適用情報の生成処理フローである。 本発明の第一実施形態におけるＩＰ−ＳＡＮのクライアントとなる計算機で取得したＩＰ−ＳＡＮストレージ装置の接続情報を模式的に示したものである。 本発明の第一実施形態における、構成管理で保持する管理対象ＩＴ装置のＩＰ−ＳＡＮストレージに関する構成情報を模式的に示したものである。 本発明の第一実施形態における、管理外ＩＴ装置を管理対象に含めることをユーザに提案する画面表示例である 本発明の第一実施形態における、管理外ＩＴ装置を管理するためのテーブル状のデータ構造の一例である管理外ＩＴ装置管理テーブルを模式的に示したものである。 本発明の第一実施形態における、ルールの適用先ＩＴ装置のリストを保有するルール適用先管理テーブルを模式的に示したものである。 本発明の第一実施形態におけるＦＣ−ＳＡＮのクライアントとなる計算機で取得したＦＣ−ＳＡＮストレージ装置の接続情報を模式的に示したものである。 本発明の第一実施形態における、構成管理で保持する管理対象ＩＴ装置のＦＣ−ＳＡＮストレージに関する情報を模式的に示したものである。 本発明の第一実施形態における、ファイルサーバとなる計算機において取得できるファイルサーバに関する識別情報と公開名を模式的に示したものである。 本発明の第一実施形態における、障害解析結果の画面表示処理フローを模式的に示したものである。 本発明の第一実施形態における、管理外ＩＴ装置が障害の原因である場合の障害解析結果データの一例を模式的に示したものである。 本発明の第一実施形態における、管理外ＩＴ装置が障害の原因である場合の障害解析結果の画面表示の構成例を模式的に示したものである。 本発明の第一実施形態における、管理外ＩＴ装置が障害の原因である場合の障害解析結果の画面表示を模式的に示したものである。 本発明の第二実施形態における、障害解析の全体処理フローを模式的に示したものである。 本発明の実施形態の１つである相関解析ルール情報の適用情報の生成処理フローである。

符号の説明

Ｎ０．．．運用管理サーバ
Ｎ１乃至Ｎ３．．．計算機
Ｎ４．．．ネットワーク（ＮＷ）スイッチ
Ｎ５．．．ストレージ装置
Ｏ１．．．計算機
Ｏ２．．．ＮＷスイッチ
Ｏ３．．．ストレージ装置
Ｍ１．．．画面出力装置

Claims (28)

1. それぞれがイベント情報を取得する対象である複数のイベント取得対象装置と前記複数のイベント取得装置ではない対象外装置の１つでありネットワークサービスを提供するサーバ装置とを含んだ複数の情報処理装置を管理する運用管理サーバで実行されるプログラムであって、
   前記複数のイベント取得対象装置から収集した複数のイベント情報を格納するイベント格納ステップと、
   前記ネットワークサービスに関連した第一のイベント種別とは異なる第二のイベント種別に対応するイベントの発生が原因で前記第一のイベント種別に対応するイベントが発生し得ることを示す相関解析ルール情報を元に、格納済みの前記複数のイベント情報から、前記第一のイベント種別を含む第一のイベント情報を特定するイベント情報特定ステップと、
   情報処理装置と情報処理装置の接続先の関係を表す構成情報を元に、前記第一のイベント情報を送信した第一イベント取得対象装置と、前記第一イベント取得対象装置に接続されているサーバ装置である障害要因装置とを特定する要因特定ステップと、
   前記相関解析ルール情報と、前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置でない装置である対象外装置の場合に、前記第一のイベント情報が表すイベントの要因が前記第二のイベント種別に対応したイベントが前記障害要因装置で発生したことであると推定されることを意味する情報を表示させる第一表示ステップと、
   を前記運用管理サーバに実行させることを特徴としたプログラム。
2. 請求項１記載のプログラムであって、
   前記相関解析ルール情報は、前記第一のイベント種別に対応したイベントが発生した前記情報処理装置の一つである第一情報処理装置と、前記第二のイベント種別に対応したイベントが発生した前記情報処理装置の一つである第二情報処理装置と、の間のトポロジ条件を示すトポロジ条件情報を含み、
   前記要因特定ステップは、前記トポロジ条件情報に基づいて前記障害要因装置を特定する、
   ことを特徴としたプログラム。
3. 請求項２記載のプログラムであって、
   前記相関解析ルール情報と前記構成情報に基づいて、前記対象外装置を特定する対象外装置特定ステップと、
   前記対象外装置からイベント情報の取得が可能か調査する調査ステップと、
   前記対象外装置からイベント情報の取得が可能な場合は、前記対象外装置からイベント情報の取得が可能であることを表示させる追加提案ステップと、
   を前記運用管理サーバに実行させることを特徴としたプログラム。
4. 請求項３記載のプログラムであって、
   前記調査ステップは、予め調査範囲として設定されたＩＰアドレスの範囲に含まれるＩＰアドレスを有する情報処理装置に対して、前記運用管理サーバが所定の手順に基づくアクセスを行った結果に基づく、
   ことを特徴としたプログラム。
5. 請求項１記載のプログラムであって、
   前記障害要因装置は、コントローラを有し論理ボリュームを提供するストレージ装置であって、
   前記ネットワークサービスは、前記論理ボリュームをブロックアクセス形式のプロトコルによって提供するサービスであって、
   前記第二のイベント種別に対応するイベントの発生が、前記ストレージ装置の障害発生であり、
   前記第一のイベント種別に対応するイベントが、前記論理ボリュームへのアクセス失敗である、
   ことを特徴としたプログラム。
6. 請求項５記載のプログラムであって、
   前記ブロックアクセス形式のプロトコルは、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ又はｉＳＣＳＩである
   ことを特徴としたプログラム。
7. 請求項１記載のプログラムであって、
   前記障害要因装置は、前記ネットワークサービスとしてＤＮＳを提供する計算機であって、
   前記第一のイベント種別に対応するイベントが、ＤＮＳ要求失敗であり、
   前記第二のイベント種別に対応するイベントが、ＤＮＳサーバの通信断絶である、
   ことを特徴としたプログラム。
8. 請求項１記載のプログラムであって、
   前記障害要因装置は、格納したファイルを前記複数の情報処理装置の少なくとも一つに提供するファイルサーバ計算機であって、
   前記ネットワークサービスは、前記ファイルサーバ計算機が格納したファイルを共有するネットワークファイル共有サービスであって、
   前記第二のイベント種別に対応したイベントが、前記ファイルサーバ計算機の障害発生であり、
   前記第一のイベント種別に対応したイベントが、前記ネットワークファイル共有サービスで提供されたファイルへのアクセス失敗である、
   ことを特徴としたプログラム。
9. 請求項１記載のプログラムであって、
   前記障害要因装置が前記複数のイベント取得対象装置のうちの１つである場合は、前記相関解析ルール情報と前記構成情報とに基づいて、複数の前記イベント情報から前記第二のイベント種別に対応したイベントを表し前記障害要因装置が取得元である第二のイベント情報を特定し、前記第一イベント取得対象装置で発生した前記第一のイベント情報が表すイベントが発生した要因が、前記障害要因装置で発生した前記第二のイベント情報に対応したイベントが発生したことであることを表示させる第二表示ステップ、
   を前記運用管理サーバに実行させることを特徴としたプログラム。
10. 請求項２記載のプログラムであって、
    前記第一情報処理装置が、計算機であり、
    前記第二情報処理装置が、ストレージ装置であり、
    前記トポロジ条件情報は、前記計算機と前記ストレージ装置とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ストレージ装置に対応する通信識別情報との組み合わせ、を含む、
    ことを特徴としたプログラム。
11. 請求項１０記載のプログラムであって、
    前記計算機に対応する計算機通信識別情報と前記ストレージ装置に対応する通信識別情報とは、ｉＳＣＳＩ名と、ＩＰアドレスと、ＦｉｂｒｅＣｈａｎｎｅｌにおけるＷＷＮとの少なくとも一つである
    ことを特徴とするプログラム。
12. 請求項２記載のプログラムであって、
    前記第一情報処理装置が、計算機であり、
    前記第二情報処理装置は、ファイル共有サービスによって格納したファイルを前記複数の情報処理装置へ提供するファイルサーバ計算機であり、
    前記トポロジ条件情報は、前記計算機と前記ファイルサーバ計算機とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ファイルサーバ計算機に対応する通信識別情報又は前記ファイルを公開するエクスポート名との組み合わせ、を含む、
    ことを特徴としたプログラム。
13. 請求項２記載のプログラムであって、
    前記第一情報処理装置は計算機であり、前記第二情報処理装置がネットワーク共有サービスとしてＤＮＳを前記複数の情報処理装置に提供するＤＮＳサーバ計算機であり、
    前記トポロジ条件情報は、前記計算機と前記ＤＮＳサーバ計算機とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報との組み合わせ、を含む、
    ことを特徴としたプログラム。
14. 請求項１３記載のプログラムであって、
    前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報とは、ＩＰアドレス又はＦＱＤＮである、
    ことを特徴としたプログラム。
15. それぞれがイベント情報を取得する対象である複数のイベント取得対象装置と前記複数のイベント取得装置ではない対象外装置の１つでありネットワークサービスを提供するサーバ装置とを含んだ複数の情報処理装置を管理し、プロセッサ及びメモリを有する運用管理サーバであって、
    前記メモリは、
    前記ネットワークサービスに関連した第一のイベント種別とは異なる第二のイベント種別に対応するイベントの発生が原因で前記第一のイベント種別に対応するイベントが発生し得ることを示す相関解析ルール情報と、
    情報処理装置と情報処理装置の接続先との関係を表す構成情報と、
    を記憶し、
    前記プロセッサは、
    （ａ）前記複数のイベント取得対象装置から収集した複数のイベント情報を格納し、
    （ｂ）前記相関解析ルール情報を元に、格納済みの前記複数のイベント情報から、前記第一のイベント種別を含む第一のイベント情報を特定し、
    （ｃ）前記構成情報を元に、前記第一のイベント情報を送信した第一イベント取得対象装置と、前記第一イベント取得対象装置に接続されているサーバ装置である障害要因装置とを特定し、
    （ｄ）前記相関解析ルール情報と、前記構成情報とを元に、前記障害要因装置が前記複数のイベント取得対象装置でない装置である対象外装置の場合に、前記第一のイベント情報が表すイベントの要因が前記第二のイベント種別に対応したイベントが前記障害要因装置で発生したことであると推定されることを意味する情報を表示させる、
    を実行する、
    ことを特徴とした運用管理サーバ。
16. 請求項１５記載の運用管理サーバであって、
    前記相関解析ルール情報は、前記第一のイベント種別に対応したイベントが発生した前記情報処理装置である第一情報処理装置と、前記第二のイベント種別に対応したイベントが発生した前記情報処理装置の一つである第二情報処理装置と、の間のトポロジ条件を示すトポロジ条件情報を含み、
    前記プロセッサは、前記（ｃ）の処理において、前記トポロジ条件情報に基づいて前記障害要因装置を特定する、
    ことを特徴とした運用管理サーバ。
17. 請求項１６記載の運用管理サーバであって、
    前記プロセッサが、
    （ｆ）前記相関解析ルール情報と前記構成情報に基づいて、前記対象外装置を特定し、
    （ｇ）前記対象外装置からイベント情報の取得が可能か調査し、
    （ｈ）前記対象外装置からイベント情報の取得が可能な場合は、前記対象外装置からイベント情報の取得が可能であることを表示させる、
    ことを特徴とした運用管理サーバ。
18. 請求項１７記載の運用管理サーバであって、
    前記（ｈ）の調査は、予め調査範囲として設定されたＩＰアドレスの範囲に含まれるＩＰアドレスを有する情報処理装置に対して、所定の手順に基づくアクセスを行った結果に基づく、
    ことを特徴とした運用管理サーバ。
19. 請求項１５記載の運用管理サーバであって、
    前記障害要因装置は、コントローラを有し、論理ボリュームを提供するストレージ装置であって、
    前記ネットワークサービスは、前記論理ボリュームをブロックアクセス形式のプロトコルによって提供するサービスであって、
    前記第二のイベント種別に対応したイベントが、前記ストレージ装置の障害発生であり、前記第一のイベント種別に対応したイベントが、前記論理ボリュームへのアクセス失敗である、
    ことを特徴とした運用管理サーバ。
20. 請求項１９記載の運用管理サーバであって、
    前記ブロックアクセス形式のプロトコルは、ＦｉｂｒｅＣｈａｎｎｅｌ又はｉＳＣＳＩである
    ことを特徴とした運用管理サーバ。
21. 請求項１５記載の運用管理サーバであって、
    前記障害要因装置は、前記ネットワークサービスとしてＤＮＳを提供する計算機であって、
    前記第一のイベント種別に対応したイベントが、ＤＮＳ要求失敗であり、
    前記第二のイベント種別に対応したイベントが、ＤＮＳサーバの通信断絶である、
    ことを特徴とした運用管理サーバ。
22. 請求項１５記載の運用管理サーバであって、
    前記障害要因装置は、格納したファイルを前記複数の情報処理装置の少なくとも一つに提供するファイルサーバ計算機であって、
    前記ネットワークサービスは、前記ファイルサーバ計算機が格納したファイルを共有するネットワークファイル共有サービスであって、
    前記第二のイベント種別に対応したイベントが、前記ファイルサーバ計算機の障害発生であり、
    前記第一のイベント種別に対応したイベントが、前記ネットワークファイル共有サービスで提供されたファイルへのアクセス失敗である、
    ことを特徴とした運用管理サーバ。
23. 請求項１５記載の運用管理サーバであって、
    前記プロセッサは、
    前記障害要因装置が、前記複数のイベント取得対象装置のうちの１つである場合は、前記相関解析ルール情報と前記構成情報とに基づいて、複数の前記イベント情報から前記第二のイベント種別に対応したイベントを表し前記障害要因装置が取得元である第二のイベント情報を特定し、前記第一イベント取得対象装置で発生した前記第一のイベント情報が表すイベントが発生した要因が、前記障害要因装置で発生した前記第二のイベント情報に対応したイベントが発生したであることを表示させる、
    ことを特徴とした運用管理サーバ。
24. 請求項１６記載の運用管理サーバであって、
    前記第一情報処理装置が、計算機であり、
    前記第二情報処理装置が、ストレージ装置であり、
    前記トポロジ条件情報は、前記計算機と前記ストレージ装置とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ストレージ装置に対応する通信識別情報との組み合わせ、を含む、
    ことを特徴とした運用管理サーバ。
25. 請求項２４記載の運用管理サーバであって、
    前記計算機に対応する計算機通信識別情報と前記ストレージ装置に対応する通信識別情報とは、ｉＳＣＳＩ名と、ＩＰアドレスと、ＦｉｂｒｅＣｈａｎｎｅｌにおけるＷＷＮとの少なくとも一つである
    ことを特徴とする運用管理サーバ。
26. 請求項１６記載の運用管理サーバであって、
    前記第一情報処理装置が、計算機であり、
    前記第二情報処理装置は、ファイル共有サービスによって格納したファイルを前記複数の情報処理装置へ提供するファイルサーバ計算機であり、
    前記トポロジ条件情報は、前記計算機と前記ファイルサーバ計算機とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ファイルサーバ計算機に対応する通信識別情報又は前記ファイルを公開するエクスポート名との組み合わせ、を含む、
    ことを特徴とした運用管理サーバ。
27. 請求項１６記載の運用管理サーバであって、
    前記第一情報処理装置は、計算機であり、
    前記第二情報処理装置が、ネットワーク共有サービスとしてＤＮＳを前記複数の情報処理装置に提供するＤＮＳサーバ計算機であり、
    前記トポロジ条件情報は、前記計算機と前記ＤＮＳサーバ計算機とが接続するトポロジの接続関係を示す、前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報との組み合わせ、を含む、
    ことを特徴とした運用管理サーバ。
28. 請求項２７記載の運用管理サーバであって、
    前記計算機に対応する通信識別情報と前記ＤＮＳサーバ計算機に対応する通信識別情報とは、ＩＰアドレス又はＦＱＤＮである、
    ことを特徴とした運用管理サーバ。
    

Images