JP5684946B2 - イベントの根本原因の解析を支援する方法及びシステム - Google Patents

Description

本発明は、管理対象装置において発生した事象（障害等に関わる事象であり、以下「イベント」という）の根本原因の解析に関する。

計算機システムを管理する場合、例えば特許文献１に示されるように、システム内で検知した複数の障害もしくはその兆候の中から、原因となる事象（イベント）を検出することが行われている。具体的には、特許文献１では、管理ソフトウェアを用いて、管理対象装置における性能値の閾値超過をイベントの発生とみなし、イベントＤＢ（データベース）にイベントの発生情報を蓄積する技術が開示されている。また、この管理ソフトウェアは、管理対象装置において発生した複数のイベントの因果関係を解析するための解析エンジンを持っている。この解析エンジンは、管理対象装置のインベントリ情報を持つ構成ＤＢにアクセスして、Ｉ／Ｏ（入出力）経路上のパス上にある機器内構成要素を認識し、ホスト上の論理ボリュームの性能に影響を与えうる構成要素を「トポロジ」と呼ばれる一グループとして認識する。そして、解析エンジンは、イベントが発生すると各トポロジに対し、事前に定められた条件文と解析結果からなる解析ルールを適用して展開ルールを構築する。この展開ルールには、根本原因となり得る結論イベントと、結論イベントが発生した場合にそれによって引き起こされる条件イベント群が含まれる。具体的には、ルールのＴＨＥＮ部に記載されているイベントが根本原因となり得る結論イベント、ＩＦ部に記載されているイベントが条件イベントである。

米国特許第７１０７１８５号明細書 特開２０１０−１９１９１４号公報

特許文献１に開示された障害解析システムでは、管理対象装置で発生し得るイベントの組み合わせ（条件イベント群）と、障害の原因候補（結論イベント）との対応関係をＩＦ−ＴＨＥＮ形式のルールとして記述しておく。障害解析システムは、ルールのＩＦ部に記載された条件イベントの発生割合を計算することで、ＴＨＥＮ部に記載された原因候補の確信度を算出する。算出した確信度と原因候補とは、ユーザの求めに応じＧＵＩ（Graphical User Interface）を介して表示される。これにより、ユーザは受信したイベントがどの障害に起因して発生しているものかを、知ることができる。

しかしながら、このような従来の障害解析システムにおいては、あらかじめ障害解析のためのＩＦ−ＴＨＥＮ形式のルールが存在しないと、ユーザにとって適切な解析結果を表示できない。すなわち、受信したイベントに対応するルールをあらかじめ用意していないと、解析が正しく実施されないことになる。このため、障害解析機能を有効に利用するためには、障害解析機能を利用しようと計画している計算機システムにおいて発生すると考えられる障害と、その障害を原因として発生すると考えられるイベントとをあらかじめ想定する必要がある。しかし、この作業は困難であり、ユーザである運用管理者のタスクを増加させることになる。

特許文献１に開示された障害解析システムでは、あらかじめルールを作成した上で障害解析を実施している。言い換えれば、事前に想定している障害についてのみしか解析を実施しない。これは発生する障害をユーザが事前にある程度想定できていることを表しており、通常は過去のイベント発生状況から運用管理者がルールを作成することになる。しかし、上述したように運用管理者の作業タスクが増加する上、ルール作成時に人為的な間違えが生じる可能性がある。

特許文献２に開示されたパターン抽出装置は、少なくとも１つのアイテムを含む集合を受け取り、その中に含まれるアイテムのパターンに特徴的な特徴パターンを抽出する。

この方法で、過去のイベントの受信状況を解析し、ルール化できるイベントの発生パターンを抽出することを考えると、まず、障害解析システムにおける障害発生を対象に分析を実施していないため、イベント発生の発生パターンを抽出しても障害解析のためのルールとしてルール化できない。また、特許文献２の方法では、パターン抽出の際に過去に抽出したパターンを利用しない。つまり、特許文献２の方法では、障害解析システムが事前に備えるべきルールを、過去の障害発生状況から自動的に作成できない。

計算機は、複数の管理対象装置のいずれかで発生し得る１以上のイベントに対応した１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す、記憶デバイス内の１以上のルールに基づいて、複数の管理対象装置のいずれかで発生したイベントの根本原因を解析する。計算機は、発生したイベントの内容及び発生日時を含むイベント発生履歴に基づいて、同一の原因によって発生していると推定される複数のイベントである第１のイベント群を決定し、第１のイベント群の複数のイベントを条件イベントとし、第１のイベント群の一のイベントを結論イベントとする新規ルールを作成し、作成した新規ルールを上記記憶デバイスに記憶する。イベント発生履歴も、上記記憶デバイスに格納されていて良い。

図１は、実施例１に係る計算機システムの構成例を示す図である。 図２は、実施例１に係るホスト計算機の構成例を示す図である。 図３は、実施例１に係るストレージ装置の構成例を示す図である。 図４は、実施例１に係る管理サーバの構成例を示す図である。 図５は、実施例１に係る装置性能管理表の構成例を示す図である。 図６は、実施例１に係るボリュームトポロジ管理表の構成例を示す図である。 図７は、実施例１に係るイベント管理表の構成例を示す図である。 図８は、実施例１に係る汎用ルールの構成例を示す図である。 図９Ａは、実施例１に係る展開ルールの第１の構成例を示す図である。 図９Ｂは、実施例１に係る展開ルールの第２の構成例を示す図である。 図９Ｃは、実施例１に係る展開ルールの第３の構成例を示す図である。 図９Ｄは、実施例１に係る展開ルールの第４の構成例を示す図である。 図１０は、実施例１に係る解析結果管理表の構成例を示す図である。 図１１は、実施例１に係る性能情報取得処理のフローチャートである。 図１２は、実施例１に係る障害原因解析処理のフローチャートである。 図１３は、実施例１に係るルール生成処理のフローチャートである。 図１４は、実施例１に係るルール登録処理のフローチャートである。 図１５は、実施例１に係るルール選択処理のフローチャートである。 図１６は、実施例１に係る生成ルール表示画面の構成例を示す図である。 図１７は、実施例２に係るルール生成処理のフローチャートである。 図１８は、実施例２に係るルール登録処理のフローチャートである。 図１９は、実施例２に係る生成ルール表示画面の構成例を示す図である。

実施例は、計算機システムの障害解消のための障害の原因解析とそのための解析ルールの生成に関するものである。

幾つかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。

なお、以後の説明では「ａａａ表」等の表現にて本発明の情報を説明するが、これら情報はテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「ａａａ表」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

さらに、以後の説明では、「プログラム」や「モジュール」を動作主体として説明を行う場合があるが、プログラムやモジュールは、プロセッサによって実行されることで、定められた処理をメモリ及び通信ポート（Ｉ／Ｏポート等）を用いながら行うため、プロセッサを動作主体とした説明としても良い。また、プログラムやモジュールを主語として開示された処理は、管理サーバ等の計算機が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされても良い。

また、本明細書で記載する実施例においては、管理対象とするシステムの規模については言及しない。しかし、管理対象のシステムが大規模になればなるほど、管理対象のシステムを小規模な単位に分割して管理をした上で障害解析を行う機会が増大する。そのため、大規模システムに本実施例を適用した場合には、本実施例の効果をより享受できる。

実施例１は、管理ソフトウェア（例えば、管理サーバに含まれる）による障害原因候補表示処理に関するものである。

＜システム構成＞

図１は、実施例１に係る計算機システムの構成例を示す図である。

計算機システムは、１以上のストレージ装置２００００と、１以上のホスト計算機１００００と、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００と、１以上のＩＰスイッチ４００００とを有し、それらが、ＬＡＮ（Local Area Network）等の通信ネットワーク（以下、単に「ネットワーク」という）４５０００によって接続される構成となっている。計算機システムは、例えば、ＮＡＳ（Network Attached Storage）、ファイルサーバ、プリンタ等を有していても良い。

ホスト計算機１００００は、例えば、接続された図示しないクライアントコンピュータからファイルのＩ／Ｏ要求を受信し、受信したＩ／Ｏ要求に基づいてストレージ装置２００００へのアクセスを行う。また、管理サーバ３００００は、計算機システム全体の運用を管理する。

ＷＥＢブラウザ起動サーバ３５０００は、ネットワーク４５０００を介して、管理サーバ３００００の後述するＧＵＩ表示処理モジュール３２４００（図４参照）と通信し、ＷＥＢブラウザの画面上に各種情報を表示する。ユーザは、ＷＥＢブラウザ起動サーバ３５０００上のＷＥＢブラウザの画面に表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ３００００が、ＷＥＢブラウザ起動サーバ３５０００の機能を有していてもよい。

以下、計算機システムを構成する装置（ホスト計算機１００００、ストレージ装置２００００、ＩＰスイッチ４００００等）を「ノード装置」と呼ぶ場合がある。以下、管理サーバ３００００が管理の対象とするノード装置を「管理対象装置」と呼ぶ場合がある。

＜ホスト計算機の内部構成＞

図２は、実施例１に係るホスト計算機の構成例を示す図である。

ホスト計算機１００００は、ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。ホスト計算機１００００は、ディスク装置を備えるようにしても良い。

メモリ１３０００には、業務アプリケーション１３１００と、オペレーティングシステム１３２００とが格納されている。

業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータの入出力（Ｉ／Ｏ）を行う。

オペレーティングシステム１３２００は、ネットワーク４５０００を介して接続されたストレージ装置２００００上のボリューム２４１００を記憶領域として業務アプリケーション１３１００に認識させるための処理を実行する。

ポート１１０００は、ストレージ装置２００００とｉＳＣＳＩ（Internet Small Computer System Interface）により通信を行うためのＩ／Ｏポートと、管理サーバ３００００がホスト計算機１００００内の管理情報を取得するための管理ポートを含む。Ｉ／Ｏポート及び管理ポートは、別個のデバイスであっても良い。

＜ストレージ装置の内部構成＞

図３は、実施例１に係るストレージ装置の構成例を示す図である。

ストレージ装置２００００は、ネットワーク４５０００を介してホスト計算機１００００に接続するための１以上のＩ／Ｏポート２１０００と、ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、データを格納するための１以上のＲＡＩＤ（Redundant Arrays of Inexpensive Disks）グループ２４０００と、データや管理メモリ２３０００内の管理情報を制御するための１以上のコントローラ２５０００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、ＲＡＩＤグループ２４０００が接続されているとは、より正確にはＲＡＩＤグループ２４０００を構成する複数の記憶デバイス（本実施例では、磁気ディスク２４２００）が他の構成物と接続されていることを指す。

管理メモリ２３０００には、ストレージ装置２００００を管理するための管理プログラム２３１００が格納される。管理プログラム２３１００は、管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバ３００００に対しストレージ装置２００００の構成管理情報を提供する。

ＲＡＩＤグループ２４０００は、１つまたは複数の磁気ディスク２４２００によって構成されている。ＲＡＩＤグループ２４０００が複数の磁気ディスク２４２００によって構成されている場合、それらの磁気ディスク２４２００は、ＲＡＩＤ構成を組んでいても良い。また、ＲＡＩＤグループ２４０００は、論理的に複数のボリューム２４１００に分割されている。

なお、ボリューム２４１００は、１つ以上の磁気ディスク２４２００の記憶領域を用いて構成されるのであれば、ＲＡＩＤ構成を組まなくても良い。さらに、ボリューム２４１００に対応する記憶領域を提供する記憶デバイスとして、磁気ディスク２４２００の代わりにフラッシュメモリなど他の記憶媒体を用いても良い。

コントローラ２５０００は、その内部に、ストレージ装置２００００の制御を行うプロセッサや、ホスト計算機１００００との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、コントローラ２５０００は、Ｉ／Ｏポート２１０００とＲＡＩＤグループ２４０００との間に介在し、両者の間でデータの受け渡しを行う。

なお、ストレージ装置２００００は、何れかのホスト計算機１００００に対してボリューム２４１００を提供し、アクセス要求（Ｉ／Ｏ要求）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うコントローラ２５０００と、記憶領域を提供する記憶デバイスとを含めば、本実施例以外の構成でも良く、例えば、コントローラ２５０００と記憶領域を提供する記憶デバイスとが別な筐体に格納されていても良い。また、図３の例では管理メモリ２３０００とコントローラ２５０００とが別個の構成として設けられているが、それらが一体となった構成としても良い。また、本実施例において、コントローラ２５０００及び記憶デバイスが同じ筐体に存在する場合とそれぞれが別の筐体に存在する場合とを含む表現として、ストレージ装置２００００をストレージシステムと呼び変えても良い。

＜管理サーバの内部構成＞

図４は、実施例１に係る管理サーバの構成例を示す図である。

管理サーバ３００００は、管理対象装置を管理し、管理対象装置で発生したイベントの根本原因を解析する計算機である。管理サーバ３００００は、ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、キャッシュメモリ等のメモリ３２０００と、ＨＤＤ（ハードディスクドライブ）等の二次記憶装置（二次記憶領域）３３０００と、処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。

メモリ３２０００には、プログラム制御モジュール３２１００と、構成管理情報取得モジュール３２２００と、装置性能取得モジュール３２３００と、ＧＵＩ表示処理モジュール３２４００と、イベント解析処理モジュール３２５００と、ルール展開モジュール３２６００と、ルール生成モジュール３２７００とが格納される。なお、本実施例において、各モジュール３２１００〜３２７００は、ソフトウェアモジュールとして提供されているが、ハードウェアモジュールとして提供されても良い。また、各モジュール３２１００〜３２７００が行う処理が一つ以上のプログラムコードとして提供されても良く、モジュール３２１００〜３２７００間の明確な境界が存在しなくても良い。モジュールをプログラムと読み替えることができる。

二次記憶領域３３０００には、装置性能管理表３３１００と、ボリュームトポロジ管理表３３２００と、イベント管理表３３３００と、汎用ルールリポジトリ３３４００と、展開ルールリポジトリ３３５００と、解析結果管理表３３６００とが格納される。なお、二次記憶領域３３０００は、例えば、半導体メモリまたは磁気ディスクのいずれか、もしくは半導体メモリおよび磁気ディスク両方から構成される。汎用ルールリポジトリ３３４００は、１以上の汎用ルールを含み、展開ルールリポジトリ３３５００は、１以上の展開ルールを含む。

ＧＵＩ表示処理モジュール３２４００は、入力デバイス３１３００を介して管理者から受け付けた要求に応じ種々の処理を行い、処理の結果や構成管理情報等を出力デバイス３１２００を介して表示する。なお、入力デバイス３１３００と出力デバイス３１２００は別々なデバイスでもよく、一つ以上のまとまったデバイスでも良い。

なお、管理サーバ３００００は、例えば、入力デバイス３１３００としてキーボード、ポインタデバイス等、出力デバイス３１２００としてディスプレイ、プリンタ等とを有しているが、これら以外の装置であってもよい。また、入力デバイス３１２００および出力デバイス３１３００の代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ、キーボード、ポインタデバイス等を有する表示用計算機を接続し、表示用情報を表示用計算機に送信し、入力用情報を表示用計算機から受信することで、表示用計算機において表示を行い、また入力を受け付けることで入力デバイス３１２００および出力デバイス３１３００の機能を代替してもよい。

本実施例では、計算機システムを管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバ３００００が表示用情報を表示する場合は、管理サーバ３００００が管理システムであり、また、表示用計算機（例えば、ＷＥＢブラウザ起動サーバ３５０００）が表示用情報を表示する場合は、管理サーバ３００００と表示用計算機の組み合わせが管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバ３００００と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

＜装置性能管理表の構成＞

図５は、実施例１に係る装置性能管理表の構成例を示す図である。

装置性能管理表３３１００は、管理対象装置の識別子である装置ＩＤを格納するフィールド３３１１０と、管理対象装置内部のデバイス（物理的又は論理的なデバイス、例えば、コントローラ２５０００、ボリューム２４１００、ホスト計算機１００００の論理ボリューム等であり、以下「管理対象デバイス」という）の識別子であるデバイスＩＤを格納するフィールド３３１２０と、管理対象デバイスの性能の測定基準が何であるかを示すデータ（以下「メトリック名称」という）を格納するフィールド３３１３０と、管理対象装置に搭載されているＯＳ（Operating System）の種別を格納するフィールド３３１４０と、管理対象デバイスの性能値を該当装置から取得して格納するフィールド３３１５０と、管理対象デバイスの性能値の正常範囲の上限もしくは下限である閾値（以下「アラート実行閾値」という）を、ユーザからの入力を受けて格納するフィールド３３１６０と、アラート実行閾値が正常値の上限であるのか下限であるのかを示す閾値種別を格納するためのフィールド３３１７０と、管理対象デバイスのステータス、すなわち、性能値が正常値であるか異常値であるかを示すデータを格納するためのフィールド３３１８０と、を構成項目として含んでいる。

例えば、図５の第１行目（１つ目のエントリ）からは、装置ＩＤが「ＳＹＳ１」であるストレージ装置２００００内の、デバイスＩＤが「ＣＴＬ１」であるコントローラ２５０００について、プロセッサの稼働率が現時点で４０％であり、アラート実行閾値が２０％、すなわち、稼働率が２０％を超えた場合に過負荷（異常）と判断されることを示し、異常が発生していること状態であることが分かる。本実施例では、例えば、管理対象デバイスのステータスが変わること、すなわち、性能値がアラート実行閾値を超えて異常値となること又は性能値が正常値に戻ることが、イベントの発生に相当する。なお、例えば、性能値がアラート実行閾値を超えて異常値となることだけをイベントの発生としてもよい。

なお、ここでは管理サーバ３００００が管理対象デバイスの性能の測定基準として単位時間当たりのＩ／Ｏ量、稼働率、レスポンスタイムを例として挙げたが、これら以外の測定基準を採用しても良い。

＜ボリュームトポロジ管理表の構成＞

図６は、実施例１に係るボリュームトポロジ管理表の構成例を示す図である。

ボリュームトポロジ管理表３３２００は、ストレージ装置２００００の装置ＩＤを格納するフィールド３３２１０と、ストレージ装置２００００が有するボリューム２４１００の識別子であるボリュームＩＤを格納するフィールド３３２２０と、ホスト計算機１００００がボリューム２４１００にアクセスする際に使用する、ボリューム２４１００の識別子であるＬＵ（論理ユニット）番号を格納するフィールド３３２３０と、ボリューム２４１００にアクセスする際に使用するコントローラ２５０００のＩＤを格納するフィールド３２３４０と、ボリューム２４１００に接続される、すなわちボリューム２４１００にアクセス可能なホスト計算機１００００の識別子を格納するフィールド３３２５０と、ボリューム２４１００が実体となるホスト計算機１００００の論理ボリュームのドライブ名を格納するフィールド３３２６０と、を構成項目として含んでいる。つまり、ボリュームトポロジ管理表３３２００は、ホスト計算機１００００とストレージ装置２００００との接続関係、より詳細には、ホスト計算機１００００の論理ボリュームと、ストレージ装置２００００のコントローラ２５０００及びボリューム２４１００との接続関係を示している。

例えば、図６の第１行目（１つ目のエントリ）からは、装置ＩＤが「ＳＹＳ１」のストレージ装置が、ボリュームＩＤ「ＶＯＬ１」のボリュームを、論理ユニット「ＬＵ１」として、接続先ホストＩＤが「ＨＯＳＴ１」のホスト計算機に提供し、当該ボリュームが、コントローラ名が「ＣＴＬ１」のコントローラを介してホスト計算機「ＨＯＳＴ１」と接続され、ホスト計算機「ＨＯＳＴ１」上での当該論理ボリュームのドライブ名が「／ｖａｒ」として認識されていることが分かる。

＜イベント管理表の構成＞

図７は、実施例１に係るイベント管理表の構成例を示す図である。

イベント管理表３３３００は、後述する障害原因解析処理、ルール生成処理において適宜参照される。イベント管理表３３３００は、イベント自身の識別子であるイベントＩＤを格納するフィールド３３３１０と、イベントの発生元の管理対象装置の装置ＩＤを格納するフィールド３３３２０と、イベントの発生元の管理対象デバイス（装置部位）の識別子を格納するフィールド３３３３０と、イベント（閾値異常）に関係するメトリック名称を格納するフィールド３３３４０と、イベントの発生元の管理対象装置に搭載されているＯＳの種別を格納するフィールド３３３５０と、イベントの発生元の管理対象デバイスのイベント発生時の状態を格納するフィールド３３３６０と、イベントがイベント解析処理モジュール３２５００によって解析済みかどうかを示すデータ（以下「解析済フラグ」という）を格納するフィールド３３３７０と、イベントが発生した日時を格納するフィールド３３３８０と、を構成項目として含んでいる。なお、解析済フラグは、例えば、イベントがイベント解析処理モジュール３２５００によって解析済みの場合に「Ｙｅｓ」とされ、未だ解析されていない場合に「Ｎｏ」とされる。

例えば、図７の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、「ＳＹＳ１」のストレージ装置における「ＣＴＬ１」で示されるコントローラにおけるプロセッサ稼働率の閾値異常、つまりイベントが「2010-01-01 15:05:00」に検知され、そのイベントＩＤは「ＥＶ１」であり、当該イベントに対して解析済みではないことが分かる。

＜汎用ルールの構成＞

図８は、実施例１に係る汎用ルールの構成例を示す図である。

汎用ルール（後述の展開ルールも同様）は、計算機システムを構成するノード装置で発生し得る１つ以上のイベント（条件イベント）と、その１以上の条件イベントが発生した場合に原因となるイベント（結論イベント）との対応関係を示すものである。

一般的に、障害解析において原因を特定するためのイベント伝播モデルは、或る障害の結果、発生することが予想されるイベントの組み合わせと、その原因とを“ＩＦ−ＴＨＥＮ”形式で記載するものとなっている。なお、汎用ルールは、図８に示したものに限られず、異なる形式のルールであっても構わない。

汎用ルールは、汎用ルールの識別子である汎用ルールＩＤを格納するフィールド３３４３０と、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＩＦ部に相当する観測事象、すなわち、条件イベントに関する情報を格納するフィールド３３４１０と、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＴＨＥＮ部に相当する原因事象、すなわち、結論イベントに関する情報を格納するためのフィールド３３４２０と、汎用ルールを実際の計算機システムの構成に対応させて展開して展開ルールを生成する際に利用するトポロジを管理するデータの名称を格納するためのフィールド３３４４０と、を構成項目として含んでいる。条件部３３４１０のイベント（条件イベント）が検知された場合、結論部３３４２０のイベント（結論イベント）が障害の原因となる。従って、結論部３３４２０のステータスが正常になれば、条件部３３４１０の問題も解決することが見込まれる。図８の例では、条件部３３４１０には２つのイベントが記述されているが、イベント数は、１であっても良い、３以上であっても良い。

例えば、図８の汎用ルール「Ｒｕｌｅ１」は、観測事象として“ホスト計算機１００００上の論理ボリュームのレスポンスタイムの閾値異常”と、“ストレージ装置２００００におけるボリューム２４１００（図面では“ＬＵ”と表記）の単位時間のＩ／Ｏ量の閾値異常”とが検知されたときに、“ストレージ装置２００００におけるボリューム２４１００の単位時間のＩ／Ｏ量のボトルネック（閾値異常）”が原因と結論付けられることを示している。また、汎用ルール「Ｒｕｌｅ１」について展開ルールを生成する際には、ボリュームトポロジ管理表３３２００からトポロジ情報が利用される。なお、観測事象に含まれるイベントとして、ある条件が正常であることを定義してもよい。

＜展開ルールの構成＞
図９Ａは、実施例１に係る展開ルールの第１の構成例を示す図である。図９Ｂは、実施例１に係る展開ルールの第２の構成例を示す図である。図９Ｃは、実施例１に係る展開ルールの第３の構成例を示す図である。図９Ｄは、実施例１に係る展開ルールの第４の構成例を示す図である。

展開ルールは、汎用ルールを計算機システムの実構成に依存する形式に展開した情報である。図９Ａ〜図９Ｄに示す展開ルールは、図８に示す汎用ルールにボリュームトポロジ管理表３３２００の各エントリの項目を挿入することによって生成される。

展開ルールは、展開ルールの識別子である展開ルールＩＤを格納するフィールド３３５３０と、展開ルールの基となった汎用ルールの汎用ルールＩＤを格納するフィールド３３５４０と、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＩＦ部に相当する観測事象、すなわち、条件イベントに関する情報を格納するフィールド３３５１０と、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＴＨＥＮ部に相当する原因事象、すなわち、結論イベントに関する情報を格納するためのフィールド３３５２０と、を構成項目として含んでいる。

展開ルールは、計算機システムの実構成（例えば、ボリュームトポロジ管理表３３２００が示す接続関係等）を考慮して、汎用ルールの条件イベント及び結論イベントの装置種別及び装置部位種別を、特定の管理対象装置及び管理対象デバイスに具体化することで生成される。例えば、図９Ａの展開ルール「ＥｘＲｕｌｅ１−１」は、汎用ルール「Ｒｕｌｅ１」における装置種別及び装置部位種別に、図６のボリュームトポロジ管理表３３２００の一番上のエントリによって接続関係が示されているホスト計算機「ＨＯＳＴ１」の論理ボリューム「／ｖａｒ」及びストレージ装置「ＳＹＳ１」のボリューム「ＬＵ１」を特定する情報（フィールド３３２４０のコントローラ名、フィールド３３２５０のホストＩＤ、フィールド３３２６０の接続先ドライブ名、フィールド３３２３０のＬＵ番号）を挿入することによって生成される。図９Ａから分かるように、展開ルール「ＥｘＲｕｌｅ１−１」は、汎用ルール「Ｒｕｌｅ１」を基に展開され、観測事象として“ホスト計算機「ＨＯＳＴ１」上の論理ボリューム「／ｖａｒ」のレスポンスタイムの閾値異常”と、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間のＩ／Ｏ量の閾値異常”とを検知したとき、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間のＩ／Ｏ量のボトルネック”が原因と結論付けられることを示している。

一方、図９Ｂの展開ルール「ＥｘＲｕｌｅ１−２」は、汎用ルール「Ｒｕｌｅ１」における装置種別及び装置部位種別に、図６のボリュームトポロジ管理表３３２００の上から２番目のエントリによって接続関係が示されているホスト計算機「ＨＯＳＴ１」の論理ボリューム「／ｏｐｔ」及びストレージ装置「ＳＹＳ１」のボリューム「ＬＵ１」を特定する情報を挿入することによって生成される。図９Ｂから分かるように、展開ルール「ＥｘＲｕｌｅ１−２」は、“ホスト計算機「ＨＯＳＴ１」上の論理ボリューム「／ｏｐｔ」のレスポンスタイムの閾値異常”と、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間のＩ／Ｏ量の閾値異常”とを検知したとき、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間のＩ／Ｏ量のボトルネック”が原因と結論付けられることを示している。また、図９Ｃの展開ルール「ＥｘＲｕｌｅ１−３」は、汎用ルール「Ｒｕｌｅ１」における装置種別及び装置部位種別に、図６のボリュームトポロジ管理表３３２００の上から３番目のエントリによって接続関係が示されているホスト計算機「ＨＯＳＴ２」の論理ボリューム「Ｅ：」及びストレージ装置「ＳＹＳ１」のボリューム「ＬＵ２」を特定する情報を挿入することによって生成される。図９Ｃから分かるように、展開ルール「ＥｘＲｕｌｅ１−３」は、“ホスト計算機「ＨＯＳＴ２」上の論理ボリューム「Ｅ：」のレスポンスタイムの閾値異常”と、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ２」の単位時間のＩ／Ｏ量の閾値異常”とを検知したとき、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ２」の単位時間のＩ／Ｏ量のボトルネック”が原因と結論付けられることを示している。また、図９Ｄの展開ルール「ＥｘＲｕｌｅ１−４」は、汎用ルール「Ｒｕｌｅ１」における装置種別及び装置部位種別に、図６のボリュームトポロジ管理表３３２００の上から４番目のエントリによって接続関係が示されているホスト計算機「ＨＯＳＴ３」の論理ボリューム「Ｅ：」及びストレージ装置「ＳＹＳ１」のボリューム「ＬＵ３」を特定する情報を挿入することによって生成される。図９Ｄから分かるように、展開ルール「ＥｘＲｕｌｅ１−４」は、“ホスト計算機「ＨＯＳＴ３」上の論理ボリューム「Ｅ：」のレスポンスタイムの閾値異常”と、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ３」の単位時間のＩ／Ｏ量の閾値異常”とを検知したとき、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ３」の単位時間のＩ／Ｏ量のボトルネック”が原因と結論付けられることを示している。

＜解析結果管理表の構成＞

図１０は、実施例１に係る解析結果管理表の構成例を示す図である。

解析結果管理表３３６００は、障害原因解析処理において障害の原因と判断されたイベントの発生元の管理対象装置の装置ＩＤを格納するフィールド３３６１０と、イベントの発生元の管理対象デバイスの識別子を格納するフィールド３３６２０と、イベント（閾値異常）に関係するメトリック名称を格納するフィールド３３６３０と、解析結果の確からしさを示す指標値（以下「確信度」という。本実施例では、条件イベントの発生割合である。）を格納するフィールド３３６４０と、イベントを障害の原因と判断した根拠となる展開ルールの展開ルールＩＤを格納するフィールド３３６５０と、展開ルールの条件イベントのうち、実際に受信したイベントのＩＤを格納するフィールド３３６６０と、該解析結果を基にユーザである管理者が実際に障害対応を行ったかどうかを示す対応済みフラグを格納するフィールド３３６７０と、イベント発生に伴う障害解析処理を開始した日時（解析実行日時）を格納するフィールド３３６８０と、を構成項目として含んでいる。

例えば、図１０の第１段目（１つ目のエントリ）からは、展開ルール「ＥｘＲｕｌｅ１−１」に基づき、管理サーバ３００００が“ストレージ装置「ＳＹＳ１」のボリューム「ＬＵ１」における単位時間Ｉ／Ｏ量”の閾値異常を障害原因として判断し、その根拠としてイベント「ＥＶ３」および「ＥＶ６」を受信し、条件イベントの確信度（発生割合）が「２／２」であり、解析を実行した日時が「2010-01-01 15:05:00」であることが分かる。

次に、本実施例に係る計算機システムにおける処理を説明する。

＜構成管理情報の取得処理及び、ボリュームトポロジ管理表の更新処理＞

管理サーバ３００００のプログラム制御モジュール３２１００は、例えばポーリング処理によって、構成管理情報取得モジュール３２２００に対し、計算機システム内の管理対象装置（本実施例では、ストレージ装置２００００、ホスト計算機１００００およびＩＰスイッチ４００００）から、構成管理情報を定期的に取得するよう指示する。なお、構成管理情報とは、管理対象装置の構成を示す情報であり、具体的には、管理対象装置がどんなデバイスを有しているか、どの管理対象装置又はどのデバイスと接続関係を有しているか等を示す情報である。

構成管理情報取得モジュール３２２００は、管理対象装置（本実施例では、ストレージ装置２００００およびホスト計算機１００００およびＩＰスイッチ４００００）から構成管理情報を取得し、ボリュームトポロジ管理表３３２００を更新する。

＜装置性能情報取得処理及びイベント解析処理＞

図１１は、実施例１に係る装置性能情報取得処理のフローチャートである。

管理サーバ３００００のプログラム制御モジュール３２１００は、プログラムの起動時、もしくは前回の装置性能情報取得処理から一定時間経過するたびに、装置性能取得モジュール３２３００に対し、装置性能情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。

装置性能情報取得モジュール３２３００は、管理対象装置に対し、以下の一連の処理を繰り返す。

装置性能情報取得モジュール３２３００は、まず、管理対象装置に対し、管理対象デバイスの性能値（装置性能管理表３３１００のメトリック３３１３０に対応した性能値）を示す情報（以下「装置性能情報」という）を送信するよう指示する（ステップ６１０１０）。この指示を受け取った、各管理対象装置は、自身における管理対象デバイスの装置性能情報を応答として管理サーバ３００００に送信することとなる。

装置性能情報取得モジュール３２３００は、管理対象装置から応答があったか否か、すなわち装置性能情報を受信したか否かを判断し（ステップ６１０２０）、管理対象装置からの応答があれば（ステップ６１０２０でＹｅｓ）、受信した装置性能情報に基づいて装置性能管理表３３１００のフィールド３３１５０の値（性能値）を更新し（ステップ６１０３０）、処理をステップ６１０４０に進める。一方、管理対象装置から応答がなかった場合（ステップ６１０２０でＮｏの場合）、装置性能情報取得モジュール３２３００は、装置性能情報取得処理を終了する。

ステップ６１０４０に進むと、装置性能取得モジュール３２３００は、装置性能管理表３３１００のフィールド３３１５０を参照し、各管理対象デバイスの性能値に対してステップ６１０５０からステップ６１０７０の処理を繰り返す。すなわち、装置性能取得モジュール３２３００は、性能値がアラート実行閾値を超過しているかを確認し、装置性能管理表３３１００のフィールド３３１８０の値（ステータス）を更新する（ステップ６１０５０）。そして、装置性能取得モジュール３２３００は、ステータスが正常から閾値異常に、或いは閾値異常から正常に変化したか否か判断し（ステップ６１０６０）、ステータスが変化した場合（ステップ６１０６０でＹｅｓ）、イベント管理表３３７００にイベントを登録する（ステップ６１０７０）。ステータスが変化していない場合（ステップ６１０６０でＮｏ）、全ての管理対象デバイスの性能値に対するステータス確認処理が終わっていなければ、装置性能取得モジュール３２３００は、処理をステップ６１０４０に進める。

全ての管理対象デバイスの性能値に対する上記の処理（ステップ６１０４０からステップ６１０７０）が終了した後、装置性能取得モジュール３２３００は、新規に登録した追加イベントがあるか否か判断し（ステップ６１０８０）、追加イベントがあれば（例えば、処理中に新たな異常が発生したような場合）（ステップ６１０８０）、イベント解析処理モジュール３２５００に対し、障害原因解析処理（図１２参照）を行なうよう指示する（ステップ６１０９０）。一方、追加イベントがない場合（ステップＳ６１０８０でＮＯ）、装置性能情報取得処理を終了する。 以上が、装置性能取得モジュール３２３００が実施する装置性能情報取得処理である。

＜障害原因解析処理（ステップ６１０９０）の詳細＞

図１２は、実施例１に係る障害原因解析処理のフローチャートである。

管理サーバ３００００のイベント解析処理モジュール３２５００は、イベント管理表３３３００より、解析処理済みでないイベント、すなわち、解析済フラグが「Ｎｏ」のイベントを取得する（ステップ６２０１０）。

次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールに対し、ステップ６２０２０からステップ６２０４０の間の処理を繰り返す。すなわち、イベント解析処理モジュール３２５００は、展開ルールに記載された条件イベントのうち、過去一定期間内に発生した条件イベントの数（条件イベントの発生件数）を集計する（ステップ６２０３０）。

そして、展開ルールリポジトリ３３５００内の全ての展開ルールに対する処理が終了した後に、イベント解析処理モジュール３２５００は、条件イベントの発生割合、すなわち、展開ルールのすべての条件イベントの数に対する、ステップ６２０３０で集計した条件イベントの発生件数の割合が、一定の比率を超過したか否か判断し、超過している場合にはＧＵＩ表示処理モジュール３２４００に対し、障害の原因になるイベント、すなわち、展開ルールの結論イベントの内容を、条件イベントの発生割合と共に表示するよう指示する（ステップ６２０５０）。その後、イベント管理表３３３００における、ステップ６２０１０で取得したイベントに関するフィールド３３３７０の値（解析済フラグ）を「Ｙｅｓ」に設定する（ステップ６２０６０）。

その後、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールのうち、確信度（すなわち、条件イベントの発生割合）が０でない展開ルールに関する解析結果を解析結果管理表３３６００に書き出す（ステップ６２０７０）。

ここで、障害原因解析処理を具体的な例を挙げて説明する。例えば、図９Ａに示す展開ルール「ＥｘＲｕｌｅ１−１」には、条件部に“ホスト計算機「ＨＯＳＴ１」における論理ボリューム「／ｖａｒ」のレスポンスタイムの閾値異常”と、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間Ｉ／Ｏ量の閾値異常”が定義されている。

そして、図７に示すイベント管理表３３３００に、“ストレージ装置「ＳＹＳ１」におけるボリューム「ＬＵ１」の単位時間Ｉ／Ｏ量の閾値異常”（発生日時：２０１０−０１−０１ １５：０５：００）が登録されると、イベント解析処理モジュール３２５００は、一定時間待機した後にイベント管理表３３３００を参照し、過去一定期間に発生したイベントを取得する（ステップ６２０１０）。

次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００の展開ルール「ＥｘＲｕｌｅ１−１」に記載された条件イベントの過去一定期間内の発生件数を算出する（ステップ６２０３０）。その結果、“ホスト計算機「ＨＯＳＴ１」における論理ボリューム「／ｖａｒ」のレスポンスタイムの閾値異常”も過去一定期間に発生していることから、展開ルール「ＥｘＲｕｌｅ１−１」に記載された条件イベントの過去一定期間の発生件数が２となり、条件イベントの発生割合は２／２となる。

以上のようにして算出された条件イベントの発生割合が一定値を超過した場合、イベント解析処理モジュール３２５００は、ＧＵＩ表示処理モジュール３２４００に対し、障害原因となるイベントを、条件イベント発生割合と共に表示するよう指示する（ステップ６２０５０）。ここでいう一定値を例えば３０％とした場合、展開ルール「ＥｘＲｕｌｅ１−１」の条件イベントの発生割合が２／２、すなわち１００％であるので、解析結果がＧＵＩを介して表示されることになる。

イベント解析処理モジュール３２５００は、上記の処理を、展開ルールリポジトリ３３５００に定義された全ての展開ルールに対し実行する。

以上が、イベント解析処理モジュール３２５００が実施する障害原因解析処理である。

通常、障害原因解析処理を実施するためには、あらかじめ汎用ルールリポジトリ３３４００内に原因解析を実施したい障害イベントの発生パターンに対応するルールが、汎用ルールとして登録されていないとならない。例えば、上記の障害イベント群（“ホスト計算機１００００における論理ボリュームのレスポンスタイムの閾値異常”と“ストレージ装置２００００におけるボリューム２４１００の単位時間Ｉ／Ｏ量の閾値異常”）が発生した時にその障害原因を解析するためには、図８に示すような汎用ルール「Ｒｕｌｅ１」があらかじめ汎用ルールリポジトリ３３４００内に存在しないとならない。このため、ユーザは導入時に管理対象の計算機システムで発生しそうな障害のパターンをルール化する必要がある。通常は過去のイベント発生状況を参考にすれば発生しそうな障害イベントのパターンと障害原因を推測することができるため、ユーザは過去のイベント発生状況からルールを作成することになる。具体的には、障害解析システムのユーザである運用管理者は、あらかじめイベント管理表３３３００を参照して、ルール化できそうな発生パターンを抽出してルール化し、汎用ルールリポジトリ３３４００に登録する。しかしながら、計算機システムに含まれる各装置は、色々な種類のイベントメッセージを発行する上、管理対象の計算機システムの規模が大きくなるとイベントメッセージの発行元の装置数も多くなるので、ルールの作成は運用管理者にとって大きな作業タスクになる。さらに、ルール作成の作業は、障害解析システムの導入時に多く実施されるはずであるものの、導入時には運用管理者のスキルが高くないことが容易に想像でき、人為的な間違えを生じる可能性が非常に高い。

そこで、実施例１では、イベント管理表３３３００に記録されているイベントの発生履歴と、解析結果管理表３３６００に記録されている解析結果の履歴を利用して、ルール化できそうなイベントの発生パターンを抽出し、解析に利用したルールに対してイベントを追加することで新たなルール（新規ルール）を生成し、生成したルールをユーザに提示して以後の解析に利用するか否かを問い合わせる。

＜ルール生成処理の内容＞

従来技術における課題を解決するため、実施例１では管理サーバ３００００におけるルール生成処理が追加され、それを実施するルール生成モジュール３２７０００を追加している。以下、当該ルール生成処理の詳細について説明する。

＜実施例１に係るルール生成処理の詳細＞

図１３は、実施例１に係るルール生成処理のフローチャートである。

管理サーバ３００００のプログラム制御モジュール３２１００は、管理サーバ３００００のセットアップ時、もしくは前回のルール生成処理から一定時間経過するたびに、ルール生成モジュール３２７００に対し、ルール生成処理を実行するように指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。

ルール生成モジュール３２７００は、イベント管理表３３３００を用いて過去のイベントの発生履歴を検査する。そして、一定回数以上発生していて、解析済みフラグ（フィールド３３３７０の値）が「Ｙｅｓ」になっているイベントを取得する（ステップ６３０１０）。

ルール生成モジュール３２７００は、各イベントに対して、ステップ６３０２０からステップ６３０４０の間の処理を繰り返す。解析結果管理表３３６００を利用して、ステップ６３０１０で取得したイベントに対して、対応する展開ルールＩＤを取得する（ステップ６３０３０）。

そして、すべてのイベントに対して対応する展開ルールＩＤを取得した後、ルール生成モジュール３２７００は、取得した展開ルールＩＤが示す展開ルールのそれぞれに対して、ステップ６３０５０からステップ６３１６０までの間の処理を繰り返し実施する。ここで、ステップ６３０３０で取得した展開ルールＩＤが示す展開ルールのうちの処理対象となる一つを図１３の説明において「対象展開ルール」という。

まず、ルール生成モジュール３２７００は、対象展開ルールに含まれるいずれかの条件イベントの発生の前後一定間隔以内に発生（すなわち、条件イベントと共起）しているイベントのうち、対象展開ルールに含まれないイベント（以下「共起イベント候補」という）を、イベント管理表３３３００から取得する（ステップ６３０６０）。

次に、ルール生成モジュール３２７００は、ステップ６３０６０で取得した各共起イベント候補に対して、ステップ６３０７０からステップ６３０９０の間の処理を繰り返し実行する。ルール生成モジュール３２７００は、共起イベント候補と対象展開ルールの条件イベントとの発生回数及び共起回数に基づいて、対象展開ルールに含まれる条件イベントと共起する確率（以下「共起確率」という）を算出する（ステップ６３０８０）。この際、例えば、対象展開ルールに含まれる条件イベントのうちの少なくとも一つと共起している場合に、共起しているとみなして共起確率の算出を実施する。

そして、ステップ６３０６０で取得したすべての共起イベント候補に対して、ステップ６３０８０の処理を実施した後に、ルール生成モジュール３２７００は、共起イベント候補のうち共起確率が一定値以上のイベントを取得する（ステップ６３１００）。ここで、共起イベント候補のうち共起確率が一定値以上のイベントは、対象展開ルールの条件イベントと同一の原因によって発生していると推定されるイベントであり、以下「共起イベント」という。

次に、ルール生成モジュール３２７００は、取得した１以上の共起イベントに対して、少なくとも一つ以上の共起イベントが含まれる全組み合わせを導出する（ステップ６３１１０）。このステップ６３１１０で導出したイベントの組み合わせは、対象展開ルールに対して共起するイベント群（以下「共起イベント群」という：第２のイベント群）である。例えば、２つの共起イベントＡ、Ｂが得られた場合、共起イベント群は、共起イベントＡだけを含む共起イベント群、共起イベントＢだけを含む共起イベント群、及び、共起イベントＡと共起イベントＢとを含む共起イベント群の３つとなる。ルール生成モジュール３２７００は、導出した共起イベント群のそれぞれに対して、ステップ６３１２０からステップ６３１５０の処理を繰り返し実行する。ここで、導出した共起イベント群のうちの処理対象となる一つを図１３の説明において「対象共起イベント群」という

次に、ルール生成モジュール３２７００は、対象共起イベント群と対象展開ルールに含まれる条件イベント群とが、同一トポロジに含まれる装置、すなわち、相互に接続関係を有する装置から発生したものであるかどうかを、ボリュームトポロジ管理表３３２００を利用して確認する（ステップ６３１３０）。

この結果、同一トポロジに含まれる装置から発生したものである場合（ステップ６３１３０でＹｅｓ）、ルール生成モジュール３２７００は、対象共起イベント群及び対象展開ルールについて、ルール登録処理を実施し、ルールを登録する（ステップ６３１４０）。一方、同一トポロジに含まれる装置から発生したものでない場合（ステップ６３１３０でＮｏ）、ルール生成モジュール３２７００は、何もしないで、ステップＳ６３１５０に処理を進める。

そして、ステップ６３１００で導出した共起イベント群のそれぞれに対して処理（ステップ６３１２０からステップ６３１５０）を終えた後、ルール生成モジュール３２７００は、処理をステップ６３１６０に進める。これにより、ステップ６３０３０で取得した展開ルールＩＤが示す展開ルールのすべてについて処理（ステップ６３０５０から６３１６０）を行っていない場合には、ルール生成モジュール３２７００は、ステップＳ６３０５０に処理を進める。

一方、ステップ６３０３０で取得した展開ルールＩＤが示す展開ルールのすべてについて処理（ステップ６３０５０から６３１６０）を終えた後、ルール生成モジュール３２７００は、ルール生成処理を終了する。

＜ルール登録処理の詳細＞

図１４は、実施例１に係るルール登録処理のフローチャートである。

ルール登録処理は、図１３のステップ６３１４０に対応する処理である。以下、図１４の説明において、ルール登録処理の対象となる共起イベント群を「対象共起イベント群」といい、ルール登録処理の対象となる展開ルールを「対象展開ルール」という。

まず、ルール生成モジュール３２７００は、対象共起イベント群と対象展開ルールに含まれる条件イベント群とのすべてのイベントを含みイベント群（第１のイベント群）の各イベントを条件イベントとする条件部を構築する（ステップ６４０１０）。

次に、ルール生成モジュール３２７００は、ステップ６４０１０で構築した条件部に対して、対象展開ルールの結論部を結合し、新たな展開ルールを導出する（ステップ６４０２０）。

そして、ルール生成モジュール３２７００は、ステップ６４０２０で導出した新たな展開ルールに基づいて、条件イベント及び結論イベントの発生元の管理対象装置及び管理対象デバイスを装置種別及び装置部位種別を用いて抽象化することにより、汎用ルール（第１の新規ルール）を作成する（ステップ６４０３０）。以下、新たな展開ルールから作成した新たな汎用ルールを「新ルール」（新規ルール）と呼ぶことがある。

ルール生成モジュール３２７００は、ステップ６４０３０で作成した新ルールに対して、汎用ルールリポジトリ３３４００に対する既登録の有無のチェックを実施したのちに、新ルールをユーザに提示しユーザの選択に応じて汎用ルールリポジトリ３３４００に登録するルール選択処理を行う（ステップ６４０４０）。

次に、ルール生成モジュール３２７００は、対象共起イベント群に含まれるイベント（共起イベント）のそれぞれに対して、ステップ６４０５０からステップ６４０９０までの処理を繰り返し実行する。ここで、対象共起イベント群に含まれる共起イベントのうちの処理対象の一つを図１４の説明において「対象共起イベント」という。

まず、ルール生成モジュール３２７００は、ステップ６４０１０で構築した条件部に対して、対象共起イベントを結論部に含む新たな展開ルールを導出する（ステップ６４０６０）。

そして、ルール生成モジュール３２７００は、ステップ６４０６０で導出した新たな展開ルールに基づいて、条件イベント及び結論イベントの発生元の管理対象装置及び管理対象デバイスを装置種別及び装置部位種別を用いて抽象化することにより、汎用ルール（第２の新規ルール）を作成する（ステップ６４０７０）。

ルール生成モジュール３２７００は、ステップ６４０７０で作成した新ルールに対して、汎用ルールリポジトリ３３４００に対する既登録の有無のチェックを実施したのちに、新ルールをユーザに提示しユーザの選択に応じて汎用ルールリポジトリ３３４００に登録するルール選択処理を行い（ステップ６４０８０）、対象共起イベント群の全てのイベントに対して処理（ステップ６４０５０からステップ６４０９０）を実行していない場合には、処理をステップ６４０５０に進める。

一方、対象共起イベント群に含まれる共起イベントのすべてについて処理（ステップ６４０５０からステップ６４０９０）を終えた場合には、ルール生成モジュール３２７００は、ルール登録処理を終了する。

図１５は、実施例１に係るルール選択処理のフローチャートである。

ルール選択処理は、図１４のステップ６４０４０、ステップ６４０８０に対応する処理である。ルール選択処理は、新ルールについて既登録の有無をチェックし、新ルールを原因解析に利用するか否かをユーザに選択させる処理である。

まず、ルール生成モジュール３２７００は、新ルールが既に汎用ルールリポジトリ３３４００に存在するかどうかチェックする（ステップ６５０１０）。

まだ登録されていない場合は、ルール生成モジュール３２７００は、新ルールを出力デバイス３１２００又はＷＥＢブラウザ起動サーバ３５０００に表示する。本実施例でのルール生成方式は、イベント間の共起確率に基づいてルール化できる可能性のあるイベントをイベントの発生履歴から取得した上で、取得したイベントの組み合わせに基づいて生成するものであり、結論部に記述したイベントが本当に結論として正しいのかどうかは、実際に運用管理担当者が判断しないとならない。そこで、新ルールの内容と、それを判断するに至った（新ルール作成の根拠となった）実際に発生したイベント群の発生履歴情報とを出力デバイス３１２００又はＷＥＢブラウザ起動サーバ３５０００に表示する（ステップ６５０２０）。ルール生成モジュール３２７００は、例えば、後述する生成ルール表示画面（図１６参照）を出力デバイス３１２００又はＷＥＢブラウザ起動サーバ３５０００に表示する。

ユーザが追加すべきルールとして選択した場合、すなわち、新ルールを以降の原因解析に利用することを示す入力を受け付けた場合には（ステップ６５０３０でＹｅｓ）、ルール生成モジュール３２７００は、新ルールを汎用ルールリポジトリ３３４００に登録する（ステップ６５０４０）。

一方、ユーザが追加すべきルールとして選択しなかった場合、すなわち、新ルールを以降の原因解析に利用しないことを示す入力を受け付けた場合には（ステップ６５０３０でＮｏ）、ルール生成モジュール３２７００は、新ルールを汎用ルールリポジトリ３３４００に登録せずに、ルール選択処理を終了する。

なお、ルール生成モジュール３２７００は、例えば、作成した新ルールについて、その新ルールの内容とその新ルールに対するユーザの選択内容（追加すべきルールとして選択したか否かを示す内容）とを含むユーザ選択の履歴（根本原因の解析に利用しないことを示す情報を含む）を、例えばメモリ３２０００に記憶しても良い。また、ルール生成モジュール３２７００は、例えば、以降、ルール選択処理を行う場合、ユーザ選択の履歴を参照し、作成された新ルール（第４の新規ルール）が、ユーザが以前登録を拒否したルール（第３の新規ルール）であるか否かを判定し、ユーザが以前登録を拒否したルールについては、ステップ６５０２０の表示処理を行わないようにしても良い。このようにすると、以前登録を拒否されたルールが、再度ユーザに表示されることを適切に防止することができ、汎用ルールリポジトリ３３４００に当該ルールを登録しないようにすることができる。

以上が実施例１によるルール生成処理である。

＜生成ルール表示画面の構成＞

図１６は、実施例１に係る生成ルール表示画面の構成例を示す図である。

生成ルール表示画面７１０００は、生成した新ルールの内容と、それを判断するに至った（新ルール作成の根拠となった）実際に発生したイベント群の発生履歴情報とを表示する。

生成ルール表示画面７１０００中の生成ルール表示テーブル７１０１０には、生成した汎用ルール（新ルール）の内容と、共起関係を分析するために利用したイベントの発生履歴情報とが表示される。同図では、もともと汎用ルールリポジトリ３３４００に存在していた図８の汎用ルール「Ｒｕｌｅ１」に対して、汎用ルール「Ｒｕｌｅ１」に含まれる条件イベントと“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”との共起関係をイベント管理表３３３００の解析により抽出し、その共起関係に基づいて作成した新ルールを表示している。作成した新ルールは、“ホスト計算機１００００上の論理ボリュームのレスポンスタイムの閾値異常”と、“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”と、“ストレージ装置２００００におけるボリューム２４１００の単位時間のＩ／Ｏ量の閾値異常”とを検知したときに、“ストレージ装置２００００のコントローラ２５０００のプロセッサ使用率のボトルネック（閾値異常）”が原因となるというルールである。汎用ルール「Ｒｕｌｅ１」に対して“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”が追加されており、そのことが分かるような形態で表示されている。すなわち、本実施例では、追加されたイベントに「（Ｎｅｗ）」と表示されている。そして、生成ルール表示画面７１０００は、ユーザがこの新ルールを汎用ルールリポジトリ３３４００に追加して良いかどうかを判断した上で追加するかどうかを入力するためのインターフェース（本実施例では、ボタン７１０２０およびボタン７１０３０）を有する。

なお、本実施例では図１４で示すように新ルールの作成のたびにルール選択処理を呼び出しており、その結果として図１６に示す生成ルール表示画面７１０００には生成された一つの新ルールのみが表示されている。しかし、図１４のルール登録処理において、新ルールの作成の都度随時ルール選択処理を呼び出すのではなく、作成した新ルールをメモリに保持しておき、一連のルール生成処理の終了ののちにまとめてユーザに作成した新ルール群を表示しても良い。その場合には、図１６に示す生成ルール表示画面７１０００に生成ルール表示テーブル７１０１０を新ルールごとに複数個表示し、それぞれの表示テーブル７１０１０ごとに汎用ルールリポジトリ３３４００に追加する必要があるかどうかを選択できるようなチェックボックスを配置するようにすれば良い。

＜ルール生成処理の効果＞

以上、実施例１によれば、管理サーバ３００００の管理ソフトウェアは、管理ソフトウェアの起動時、または一定時間経過するたびに図１３〜図１５に示すルール生成処理を実施する。実施例１によるルール生成処理では、汎用ルールリポジトリ３３４００に存在し、以前に障害原因解析処理に利用されたルール（既存ルール）に対して、そのルールの条件イベントと同一の原因によって発生すると推測できる共起確率が一定値以上のイベント（共起イベント）を追加した新ルールを、イベント管理表３３３００に記録されたイベントの発生状況より共起イベントを取得した上で構築し、ユーザに提示する。このように、障害発生の履歴と発生した障害に対する障害原因解析の履歴を利用するが、例えば擬似的に障害を発生させて、それに対して原因解析処理を実施した結果を利用してルールを作成しても良い。従来は、ユーザがイベント管理表３３３００に記録されたイベントの発生状況を基に障害原因解析パターンを抽出したり、あるいは実際の運用管理現場でどのように障害が発生しているかを運用管理担当者からヒアリングを実施したりした結果をもとに、ルールを作成する必要があった。これに対して本実施例によれば、ルール作成を自動化することにより、適切なルールを作成することができるとともに、作業工数を減らすことができ、また、人為的なオペレーションミスを軽減できる。

また、実施例１によって作成した新ルール（図１６の生成ルール表示テーブル７１０１０に表示されたルール）は、従来はユーザが気づいていなかった“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”というイベントを結論イベントとして含んでいる。すなわち汎用ルール「Ｒｕｌｅ１」に含まれる障害イベントの原因がこのイベントであるということは、ユーザが容易には発見できなかったが、ユーザの手順を追加することなく自動的に分析して表示している。この例では、ボリューム２４１００に障害が生じてその結果ホスト計算機１００００のドライブに障害が生じていることはルール化されていたが、その原因がストレージ２００００のコントローラ２５０００にあることをユーザは認識していなかった。そのため、ユーザはボリューム２４１００を作成し直すことにより障害に対応し、根本の原因であるコントローラ２５０００の異常を解決できていなかった可能性が高い。このような場合に、今までのいわば「見かけの原因」ではなく、根本の原因であるコントローラ２５０００の異常を、ユーザに提示できる。

さらに、実施例１に係るルール生成処理は、障害原因解析のためのルール作成処理であるが、これを障害原因解析以外に利用しても良い。例えば、発生した障害のグループ化のために利用することにより、障害対応後に以前に発生していた障害に既に対応済みかどうか、一つ一つの障害の発生状況を再確認しなくてもある程度ユーザが推測できるようになる。

このように、本実施例によれば、システム運用管理者がルール作成及び障害対応に要する負荷を軽減することができる。

実施例１では、汎用ルールリポジトリ３３４００に存在し、以前に障害原因解析処理に利用された既存ルールに対して、そのルールの条件イベントと同一の原因によって発生すると推測できる共起確率が一定値以上のイベント（共起イベント）を追加した新ルールを、イベント管理表に記録されたイベントの発生状況より共起イベントを取得した上で構築し、ユーザに提示している。このように実施例１では既存の汎用ルールを基に共起イベントを追加することで新ルールを作成している。実施例２に係るルール生成処理は、そのような既存ルールを利用せずに、イベント管理表に記録されたイベントの発生状況のパターンのみから新ルールを構築する。なお、システム構成や各装置の構成のうち、実施例１と実質的に同じものについては説明を省略する。

＜ルール生成処理の内容＞

実施例２に係る管理サーバ３００００に追加されたルール生成モジュール３２７０００におけるルール生成処理の動作の詳細について説明する。

＜実施例２に係るルール生成処理の詳細＞

図１７は、実施例２に係るルール生成処理のフローチャートである。

管理サーバ３００００のプログラム制御モジュール３２１００は、管理サーバ３００００のセットアップ時、もしくは前回のルール生成処理から一定時間経過するたびに、ルール生成モジュール３２７００に対し、ルール生成処理を実行するように指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。

ルール生成モジュール３２７００は、イベント管理表３３３００を用いて過去のイベントの発生履歴を検査する。そして、一定回数以上発生しているイベントを取得する（ステップ６６０１０）。

ルール生成モジュール３２７００は、ステップ６６０１０で取得した各イベントに対して、ステップ６６０２０からステップ６６１３０までの処理を繰り返し実行する。ここでステップ６６０１０で取得したイベントのうちの処理対象の一つを図１７の説明において「対象イベント」という。

まず、ルール生成モジュール３２７００は、イベント管理表３３３００を用いて、対象イベントの発生の前後一定間隔以内に発生（すなわち、対象イベントと共起）しているイベント（以下、実施例２において「共起イベント候補」という）を抽出する（ステップ６６０３０）。

次に、ルール生成モジュール３２７００は、ステップ６６０３０で取得した各共起イベント候補に対して、ステップ６６０４０からステップ６６０６０までの処理を繰り返し実行する。ルール生成モジュール３２７００は、当該共起イベント候補と対象イベントとの発生回数及び共起回数に基づいて、対象イベントとの共起確率を算出する（ステップ６６０５０）。

そして、全ての共起イベント候補に対して処理（ステップ６６０４０からステップ６６０６０）を終了した後に、そして、ルール生成モジュール３２７００は、共起イベント候補のうち共起確率が一定値以上のイベント（以下、実施例２において「共起イベント」という）を取得する（ステップ６６０７０）。

ルール生成モジュール３２７００は、ステップ６６０７０で取得した１以上の共起イベントの全組み合わせを導出する（ステップ６６０８０）。ステップ６６０８０で導出された組合せのそれぞれが、実施例２における共起イベント群である。ルール生成モジュール３２７００は、導出した共起イベント群のそれぞれに対して、ステップ６６０９０からステップ６６１２０の処理を実施する。ここで、導出した共起イベント群のうちの処理対象とする一つを図１７の説明において「対象共起イベント群」という。

ルール生成モジュール３２７００は、対象共起イベント群に含まれるイベントが同一トポロジに含まれる装置、すなわち、相互に接続関係を有する装置から発生したものであるかどうかを、ボリュームトポロジ管理表３３２００を利用して確認する（ステップ６６１００）。

同一トポロジに含まれる装置から発生したものである場合（ステップ６６１００でＹｅｓの場合）、ルール生成モジュール３２７００は、対象共起イベント群について、ルール登録処理を実施し、ルールを登録する（ステップ６６１１０）。一方、同一トポロジに含まれる装置から発生したものでない場合（ステップ６６１００でＮｏ）、ルール生成モジュール３２７００は、何もしないで、ステップＳ６６１２０に処理を進める。これにより、ステップ６６０１０で取得したイベントのすべてについて処理（ステップ６６０２０からステップ６６１３０）を行っていない場合には、ルール生成モジュール３２７００は、ステップＳ６６０２０に処理を進める。

一方、ステップ６６０１０で取得したイベントのすべてに対して処理（ステップ６６０２０からステップ６６１２０）を終えた後、ルール生成モジュール３２７００は、ルール生成処理を終了する。

＜ルール登録処理の詳細＞

図１８は、実施例２に係るルール登録処理のフローチャートである。

ルール登録処理は、ルール生成処理（図１７）のステップ６６１１０に対応する処理である。図１８の説明において、ルール登録処理の対象となる共起イベント群を「対象共起イベント群」という。

まず、ルール生成モジュール３２７００は、対象共起イベント群（第１のイベント群）のすべてを条件イベントとする条件部を構築する（ステップ６７０１０）。

次に、ルール生成モジュール３２７００は、対象共起イベント群に含まれるイベント（共起イベント）のそれぞれに対して、ステップ６７０２０からステップ６７０６０までの処理を繰り返し実行する。ここで、対象共起イベント群に含まれる共起イベントのうちの処理対象の一つを図１８の説明において「対象共起イベント」という。

まず、ルール生成モジュール３２７００は、ステップ６７０１０で構築した条件部に対して、対象共起イベントを結論部に含む新たな展開ルールを導出する（ステップ６７０３０）。

そして、ルール生成モジュール３２７００は、導出した新たな展開ルールに基づいて、条件イベント及び結論イベントの発生元の管理対象装置及び管理対象デバイスを装置種別及び装置部位種別を用いて抽象化することにより、汎用ルール（新規ルール）を作成する（ステップ６７０４０）。

ルール生成モジュール３２７００は、作成した汎用ルール（すなわち、新ルール）に対して、汎用ルールリポジトリ３３４００に対する既登録の有無のチェックを実施したのちに、新ルールをユーザに提示しユーザの選択に応じて汎用ルールリポジトリ３３４００に登録するルール選択処理を行う（ステップ６７０５０）。このステップ６７０５０のルール選択処理は、実施例１における図１５で記載したルール選択処理と実質的に同じである。なお、実施例２においては、図１５のルール選択処理のステップ６５０２０において、図１９に示す生成ルール表示画面が表示される。

以上が実施例２によるルール生成処理である。

＜生成ルール表示画面の構成＞

図１９は、実施例２に係る生成ルール表示画面の構成例を示す図である。

実施例２に係る生成ルール表示画面７２０００は、実施例１に係る生成ルール表示画面７１０００と同様に、生成した新ルールの内容とそれを判断するに至った実際に発生したイベント群の発生履歴情報とを表示する。

生成ルール表示画面７２０００中の生成ルール表示テーブル７２０１０には、生成した汎用ルール（新ルール）の内容と、共起関係を分析するために利用したイベントの発生履歴情報とが表示される。この図では、“ホスト計算機１００００における論理ボリュームのレスポンスタイムの閾値異常”と、“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”と、“ストレージ装置２００００におけるボリューム２４１００の単位時間Ｉ／Ｏ量の閾値異常”との共起関係をイベント管理表３３３００の解析により抽出し、その共起関係に基づいて作成したルールを表示している。作成した新ルールは、“ホスト計算機１００００上の論理ボリュームのレスポンスタイムの閾値異常”と、“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”と、“ストレージ装置２００００におけるボリューム２４１００の単位時間のＩ／Ｏ量の閾値異常”とを検知したときに、“ストレージ装置２００００のコントローラ２５０００のプロセッサ使用率のボトルネック（閾値異常）”が原因となるというルールである。実施例２では、既存の汎用ルールを利用せずにルール生成を行っている。図１６では“ストレージ装置２００００におけるコントローラ２５０００のプロセッサ使用率の閾値異常”を既存のルールに対して追加していることが理解できるような形式で表示を行っていた。実施例２では、既存のルールのイベントと追加したイベントとの差分を表示する必要はないものの、図１９では実施例１での表示とそろえるために、すべてのイベントに対して、既存ルールを利用して導出したイベントではないことを示す情報（すなわち、「（Ｎｅｗ）」という表示）を、表示している。さらに、生成ルール表示画面７２０００は、図１６と同様に、ユーザがこの新ルールを汎用ルールリポジトリ３３４００に追加して良いかどうかを判断した上で追加するかどうかを入力するためのインターフェース（本実施例では、ボタン７２０２０およびボタン７２０３０）を有する。

なお、本実施例でも図１４と同様に、図１８で示すように新ルールの作成のたびにルール選択処理を呼び出しており、その結果として図１９に示す生成ルール表示画面７２０００には生成された一つの新ルールのみが表示されている。しかし、図１８のルール登録処理において、新ルール作成の都度随時ルール選択処理を呼び出すのではなく、作成した新ルールをメモリに保持しておき、一連のルール生成処理の終了ののちにまとめてユーザに作成した新ルール群を表示しても良い。その場合には、図１９に示す生成ルール表示画面７２０００に生成ルール表示テーブル７２０１０を新ルールごとに複数個表示し、それぞれの表示テーブル７２０１０ごとに汎用ルールリポジトリ３３４００に追加する必要があるかどうかを選択できるようなチェックボックスを配置するようにすれば良い。

＜ルール生成処理の効果＞

以上、実施例２によれば、管理サーバ３００００の管理ソフトウェアは、管理ソフトウェアの起動時、または一定時間経過するたびに図１７、図１８および図１５に示すルール生成処理を実施する。実施例２によるルール生成処理では、イベント管理表３３３００を分析し、発生したイベントと共起している別のイベントを追加した新ルールを構築し、ユーザに提示する。このように、障害発生の履歴を利用するが、例えば擬似的に障害を発生させて障害発生の履歴を蓄積し、その障害発生の履歴を利用してルールを作成しても良い。従来は、ユーザがイベント管理表３３３００に記録されたイベントの発生状況を基に障害原因解析パターンを抽出したり、あるいは実際の運用管理現場でどのように障害が発生しているかを運用管理担当者からヒアリングを実施したりした結果をもとに、ルールを作成する必要があった。これに対して、本実施例によれば、ルール作成を自動化することにより、適切なルールを作成することができるとともに、作業工数を減らすことができ、人為的なオペレーションミスを軽減できる。

さらに、実施例２に係るルール生成処理は、障害原因解析のためのルール作成の処理であるが、これを障害原因解析以外に利用してもよい。例えば、発生した障害のグループ化のために利用することにより、障害対応後に以前に発生していた障害に既に対応済みかどうか、一つ一つの障害の発生状況を再確認しなくてもある程度ユーザが推測できるようになる。

このように、本実施例によれば、適切なルールを作成することができ、システム運用管理者がルール作成及び障害対応に要する負荷を軽減することができる。

以上、幾つかの実施例について説明したが、上述したように、実施例に係る管理サーバ３００００は、計算機システムで発生したイベントを蓄積しておき、一定時間ごとのイベント発生パターンを解析することにより、ルール化できるイベントの発生パターンを抽出する。そして、抽出した発生パターンに基づいて新ルールを作成し、管理サーバ３００００のユーザに提示する。

特許文献１に開示された障害解析システムでは、障害原因解析時には、管理対象装置で発生し得る条件イベントの組み合わせ（条件イベント群）と、障害の原因候補（結論イベント）との対応関係を示すＩＦ−ＴＨＥＮ形式のルールに、検知したイベントを適用することによって、障害原因を推論する。その際に、それぞれの原因候補に対して確信度を算出する。

本実施例では、障害原因解析の実施有無にかかわらず、計算機システムで発生したイベントを管理サーバ３００００に蓄積しておき、さらに障害原因解析を実施した場合は、解析結果の履歴を蓄積する。さらに、ユーザが障害原因解析により管理システムにより示された原因候補のうちのどの候補を利用してどのように対処したかという操作ログをも蓄積してもよい。そして、或る特定期間内に発生している障害パターンや、それによって管理システムによって示された原因候補の発生に関連性があった場合、それらをルール化できる可能性のあるイベントや原因候補としてグループ化する。そして、グループごとに導出できるＩＦ−ＴＨＥＮ形式のルールを生成して管理システムのユーザに提示する。操作ログを蓄積している場合は、原因候補を提示した後でのユーザの障害回復操作をも、ルールに含めてもよい。

さらに、本実施例における管理サーバ３００００は、上記グループ化処理によって作成した新ルールの表示を行う。この際、既に存在する既存ルールをベースに新ルールを作成した場合は、既存ルールからの距離を基に優先度を合わせて表示する。さらに、グループ化処理の際に操作ログを利用した場合は、新ルールに対してどのような手順で操作を実施したのかの手順を新ルールに含めて表示する。

なお、ルールを作成する際にイベントをどのようにグループ化するかについては、様々な方法が考えられる。本実施例では、一例として、イベントの共起関係を用いてグループ化を行っている。

障害解析においてユーザがイベントの発生状況を基に障害原因解析パターンをルール化する際の手順は、主に管理システム導入時に発生するため、ユーザにとって不慣れな作業である。本実施例によれば、これを自動化することにより、作業工数を減らし、人為的なオペレーションミスを減らすことができる。

実施例１では、計算機システムにおけるイベントの発生と管理ソフトウェアが障害原因を分析した結果を利用して、障害原因分析のための解析ルールを作成し、管理者に提示する。また、実施例２では、計算機システムにおけるイベントの発生状況のみを利用して、障害原因分析のための解析ルールを作成し、管理者に提示する。障害原因を自動分析するためには、管理ソフトウェア導入時に管理者は導入対象の計算機システムで発生しうるイベントとその原因とをあらかじめルール化しておく必要がある。実施例２によれば、ルール作成作業を自動化することができ、ユーザは作成されたルールを障害原因分析のためのルールとして利用して良いかどうかを選択するだけですむようになる。これにより、作業工数を減らし、人為的なオペレーションミスをも軽減でき、障害対応に要する負荷を軽減することができる。

なお、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

また、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

以上、実施例を説明したが、本発明は、この実施例に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１００００…ホスト計算機、２００００…ストレージ装置、３００００…管理サーバ、３５０００…ＷＥＢブラウザ起動サーバ、４００００…ＩＰスイッチ、４５０００…通信ネットワーク

Claims (15)

1. 複数の管理対象装置のいずれかで発生し得る１以上のイベントに対応した１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す、記憶デバイス内の１以上のルールに基づいて、複数の管理対象装置のいずれかで発生したイベントの根本原因の解析を支援する方法であって、
   発生したイベントの内容及び発生日時を含むイベント発生履歴に基づいて、同一の原因によって発生していると推定される複数のイベントである第１のイベント群を決定し、
   前記第１のイベント群の複数のイベントを前記条件イベントとし、前記第１のイベント群の一のイベントを結論イベントとする新規ルールを作成し、
   前記作成した新規ルールを前記記憶デバイスに記憶する
   方法。
2. 前記記憶デバイスは、前記複数の管理対象装置のいずれかで発生し得る１以上のイベントに対応した１以上の条件イベントと当該１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す１以上の既存ルールと、根本原因の解析に利用された既存ルールを特定する情報を含む解析履歴と、を記憶しており、
   前記イベント発生履歴及び前記解析履歴に基づいて、前記根本原因の解析に利用された既存ルールについて、当該既存ルールの条件イベントが発生した場合に発生する可能性が高い、当該既存ルールの条件イベント以外の１以上のイベントである第２のイベント群を決定し、当該既存ルールの１以上の条件イベントのイベントと前記第２のイベント群のイベントとの組み合わせを前記第１のイベント群と決定する
   請求項１に記載の方法。
3. 前記第１のイベント群の各イベントの発生元の管理対象装置が相互に接続関係を有している場合に、前記新規ルールを作成する
   請求項２に記載の方法。
4. 前記新規ルールとして、前記根本原因に利用された前記既存ルールの結論イベントを結論イベントとする第１の新規ルールと、前記第２のイベント群の一のイベントを結論イベントとする第２の新規ルールとを作成する
   請求項３に記載の方法。
5. 作成した前記新規ルールの内容を所定の表示装置に表示し、
   前記新規ルールを根本原因の解析に利用するか否かを示す入力をユーザから受け付け、
   前記新規ルールを根本原因の解析に利用する旨を示す入力を受け付けた場合に、以降において、作成した前記新規ルールを根本原因の解析に利用する
   請求項４に記載の方法。
6. 表示した第３の新規ルールについて、根本原因の解析に利用しない旨を示す入力をユーザから受け付けた場合、前記第３の新規ルールについて根本原因の解析に利用しない旨を示す情報を前記記憶デバイスに記憶し、
   以降において新たに作成した第４の新規ルールが前記第３の新規ルールと同じである場合、前記第４の新規ルールの内容を前記所定の表示装置に表示させないようにする
   請求項５に記載の方法。
7. 前記第１のイベント群の各イベントの発生元の管理対象装置が相互に接続関係を有している場合に、前記新規ルールを作成する
   請求項１に記載の方法。
8. 作成した前記新規ルールの内容を所定の表示装置に表示し、
   前記新規ルールを根本原因の解析に利用するか否かを示す入力をユーザから受け付け、
   前記新規ルールを根本原因の解析に利用する旨を示す入力を受け付けた場合に、以降において、作成した前記新規ルールを根本原因の解析に利用する
   請求項７に記載の方法。
9. 複数の管理対象装置のいずれかで発生し得る１以上のイベントに対応した１以上の条件イベントと前記１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す、記憶デバイス内の１以上のルールに基づいて、複数の管理対象装置のいずれかで発生したイベントの根本原因の解析を支援するシステムであって、
   前記記憶デバイスと、
   前記記憶デバイスに接続された制御デバイスと
   を有し、
   前記記憶デバイスは、発生したイベントの内容及び発生日時を含むイベント発生履歴を記憶し、
   前記制御デバイスは、
   前記イベント発生履歴に基づいて、同一の原因によって発生していると推定される複数のイベントである第１のイベント群を決定し、
   前記第１のイベント群の複数のイベントを前記条件イベントとし、前記第１のイベント群の一のイベントを結論イベントとする新規ルールを作成する、
   システム。
10. 前記記憶デバイスは、前記複数の管理対象装置のいずれかで発生し得る１以上のイベントに対応した１以上の条件イベントと当該１以上の条件イベントが発生した場合に原因となる結論イベントとの関連付けを示す１以上の既存ルールと、根本原因の解析に利用された既存ルールを特定する情報を含む解析履歴と、を記憶し、
    前記制御デバイスは、
    前記イベント発生履歴及び前記解析履歴に基づいて、前記根本原因の解析に利用された既存ルールについて、当該既存ルールの条件イベントが発生した場合に発生する可能性が高い、当該既存ルールの条件イベント以外の１以上のイベントである第２のイベント群を決定し、当該既存ルールの１以上の条件イベントのイベントと前記第２のイベント群のイベントとの組み合わせを前記第１のイベント群と決定する
    請求項９に記載のシステム。
11. 前記制御デバイスは、
    前記第１のイベント群の各イベントの発生元の管理対象装置が相互に接続関係を有している場合に、前記新規ルールを作成する
    請求項１０に記載のシステム。
12. 前記制御デバイスは、
    前記新規ルールとして、前記根本原因に利用された前記既存ルールの結論イベントを結論イベントとする第１の新規ルールと、前記第２のイベント群の一のイベントを結論イベントとする第２の新規ルールとを作成する、
    請求項１１に記載のシステム。
13. 前記制御デバイスは、
    前記作成した新規ルールの内容を所定の表示装置に表示し、
    前記新規ルールを根本原因の解析に利用するか否かを示す入力をユーザから受け付け、
    前記新規ルールを根本原因の解析に利用する旨を示す入力を受け付けた場合に、以降において、作成した前記新規ルールを根本原因の解析に利用する
    請求項１２に記載のシステム。
14. 前記制御デバイスは、
    表示した第３の新規ルールについて、根本原因の解析に利用しない旨を示す入力をユーザから受け付けた場合、前記第３の新規ルールを根本原因の解析に利用しないことを示す情報を前記記憶デバイスに記憶し、
    以降において作成した第４の新規ルールが前記第３の新規ルールと同じである場合、前記第４の新規ルールの内容を表示させないようにする
    請求項１３に記載のシステム。
15. 前記制御デバイスは、
    前記第１のイベント群の各イベントの発生元の管理対象装置が相互に接続関係を有している場合に、前記新規ルールを作成する
    請求項９に記載のシステム。

Images