JP5691723B2 - 監視方法、情報処理装置および監視プログラム - Google Patents

Description

本発明は、１またはそれ以上の装置を監視する監視方法、情報処理装置および監視プログラムに関する。

情報処理システムを運用する場合、サーバ装置、ストレージ装置、通信装置などの装置に異常がないか、システム管理者が確認し、異常があれば対応措置を行うことがある。例えば、ハードウェアの故障が発見されたときは、装置を停止させてハードウェアを交換することがある。また、ソフトウェアの実行状態の異常が発見されたときは、ソフトウェアのプロセスを停止させて、異常原因を調査することがある。また、装置の過剰負荷が発見されたときは、情報処理のためのリソースを追加することがある。

一方で、情報処理システムの有する装置が多数になると、システム管理者の監視作業の負担が大きくなる。そこで、運用管理用の情報処理装置が、監視対象の装置から情報を収集し、収集した情報を検査することで、装置の異常な状態（または、異常の兆候）を自動的に検出することが考えられる。異常を検出した情報処理装置は、システム管理者に対する警告を発行することもできるし、予め定義された処理手順に従って対応措置を行う（例えば、異常な状態の装置に対して停止命令を送信する）こともできる。

なお、予め定義されたワークフローに従って自律的に計算機の運用管理を行う運用管理システムにおいて、管理対象の計算機から情報を収集し、収集した情報と停止判断ルールとを照合して、自律制御を継続するか停止するか判断する方法が提案されている。

特開２００７−４３３７号公報（段落［００２８］，［００３０］）

しかし、情報を収集して検査すべき項目が増えると、監視の負荷が増大するという問題がある。例えば、サーバ装置毎に、ＨＤＤ（Hard Disk Drive）の状態、メモリの状態、当該サーバ装置が実行しているトランザクションの数など、具体的な項目の情報を継続的に検査すると、検査を行う情報処理装置の負荷が増大する。

一側面では、本発明は、複数の項目の情報を用いた監視の負荷を軽減できる監視方法、情報処理装置および監視プログラムを提供することを目的とする。

一実施態様では、１またはそれ以上の装置から取得される複数の項目の情報に基づいて、１またはそれ以上の装置を監視する情報処理システムが行う監視方法が提供される。第１の項目、第２の項目、および、取得される情報が第１および第２の項目の情報と関連する第３の項目のうち、第３の項目の情報を検査する。第３の項目の情報の検査で異常が検出されなかった場合、第１および第２の項目の情報の検査を省略する。第３の項目の情報の検査で異常が検出された場合、第１および第２の項目の情報をそれぞれ検査する。

また、一実施態様では、１またはそれ以上の装置から取得される複数の項目の情報に基づいて、１またはそれ以上の装置を監視する情報処理装置が提供される。情報処理装置は、記憶部と検査部とを有する。記憶部は、検査対象として、第１の項目と、第２の項目と、取得される情報が第１および第２の項目の情報と関連する第３の項目とを示す検査情報を記憶する。検査部は、検査情報が示す検査対象の項目の情報を検査する。検査部は、第３の項目の情報を検査し、第３の項目の情報の検査で異常が検出されなかった場合、第１および第２の項目の情報の検査を省略し、第３の項目の情報の検査で異常が検出された場合、第１および第２の項目の情報を検査する。

また、一実施態様では、１またはそれ以上の装置から取得される複数の項目の情報に基づいて、１またはそれ以上の装置を監視するための監視プログラムが提供される。監視プログラムは、コンピュータに以下の処理を実行させる。第１の項目、第２の項目、および、取得される情報が第１および第２の項目の情報と関連する第３の項目のうち、第３の項目の情報を検査する。第３の項目の情報の検査で異常が検出されなかった場合、第１および第２の項目の情報の検査を省略する。第３の項目の情報の検査で異常が検出された場合、第１および第２の項目の情報をそれぞれ検査する。

一実施態様によれば、複数の項目の情報を用いた監視の負荷を軽減できる。

第１の実施の形態の情報処理装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 端末装置のハードウェア例を示すブロック図である。 情報処理システムのソフトウェア例を示すブロック図である。 構成情報の項目例を示す図である。 構成情報の記述例を示す図である。 異常の波及関係の例を示す図である。 波及関係テーブルの例を示す図である。 ルール定義テーブルの例を示す図である。 リアクション定義テーブルの例を示す図である。 ルール登録処理を示すフローチャートである。 ルール登録処理を示すフローチャート（続き）である。 ルール編集画面の例を示す図である。 ルール変換の例を示す図である。 ワークフローの例を示す図である。 フロー情報の記述例を示す図である。 フロー登録処理を示すフローチャートである。 ルール検査処理を示すフローチャートである。 ワークフローの実行手順の例を示す第１のシーケンス図である。 ワークフローの実行手順の例を示す第２のシーケンス図である。 ワークフローの実行手順の例を示す第３のシーケンス図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。第１の実施の形態の情報処理装置１０は、装置２１〜２３から取得される複数の項目の情報に基づいて、装置２１〜２３を監視する情報処理システムに用いられる。当該情報処理システムは、ワークフロー定義に従って自動的にソフトウェアの更新などの処理を行っている間、異常の有無を監視して、異常があれば処理を停止させるものであってもよい。装置２１〜２３は、例えば、サーバ装置、通信装置、ストレージ装置などの電子機器である。

情報処理装置１０は、検査部１２を有する。検査部１２は、ＣＰＵ（Central Processing Unit）およびＲＡＭ（Random Access Memory）を用いて実行されるプログラムとして実装してもよい。検査部１２は、記憶部１１に記憶された検査情報１１ａが示す検査対象の項目の情報を検査する。検査情報１１ａは、検査対象の項目毎に、正常（または異常）と判断する基準（判断ルール）を示す情報を含んでいてもよい。記憶部１１は、情報処理装置１０が備えていてもよいし、他の情報処理装置が備える記憶装置でもよい。

検査情報１１ａにおいて、装置２１〜２３から情報を取得可能な複数の項目のうち、検査対象の項目として、項目＃１，＃２，＃３が指定されているとする。項目＃３は、取得される情報が、項目＃１の情報と項目＃２の情報の両方と関連する。例えば、項目＃３の情報は、項目＃１が示す装置状態と項目＃２が示す装置状態の両方から影響を受けるものである場合が考えられる。この場合、項目＃１の情報と項目＃２の情報の少なくとも一方が異常を示していれば、項目＃３の情報も異常を示すことが想定される。

検査部１２は、装置２１〜２３から取得された項目＃３の情報を検査する。項目＃３の情報の検査で異常が検出されない場合、検査部１２は、項目＃１，＃２の情報の検査を省略する。一方、項目＃３の情報の検査で異常が検出された場合、検査部１２は、装置２１〜２３から取得された項目＃１，＃２の情報を更に検査する。なお、検査部１２は、項目＃３の情報が更新されたときに、項目＃３の情報を検査するようにしてもよい。項目＃３の情報が更新されたか否かは、装置２１〜２３から情報を収集するデータベース装置に監視させてもよい。また、項目＃１，＃２の情報は、項目＃３の情報の検査で異常が検出された後に、装置２１〜２３から取得するようにしてもよい。

また、情報処理装置１０または他の情報処理装置は、検査対象の項目として項目＃１，＃２が指定されたときに、自動的に項目＃３を検査対象に追加するようにしてもよい。例えば、複数の項目の間の関係（例えば、一の項目の情報が他の項目の情報に影響を与える関係）を示す関係情報を記憶した記憶装置を参照して、項目＃１，＃２の両方と関連する項目＃３を検索することが考えられる。情報処理装置１０または他の情報処理装置は、検索された項目＃３を、優先的に検査を行う項目に指定すればよい。検査情報１１ａは、項目＃１〜＃３と対応付けて、検査の優先度を示す情報を含んでいてもよい。

第１の実施の形態の情報処理装置１０によれば、項目＃１、項目＃２、および、取得される情報が項目＃１，＃２の情報と関連する項目＃３のうち、項目＃３の情報が検査される。項目＃３の情報の検査で異常が検出されなかった場合、項目＃１，＃２の情報の検査が省略される。項目＃３の情報の検査で異常が検出された場合、項目＃１，＃２の情報がそれぞれ検査される。これにより、装置２１〜２３に異常がなければ、項目＃１，＃２の情報の検査を省略でき、継続的に検査対象とする項目を絞り込むことができ、複数の項目の情報を用いた監視の負荷を軽減できる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、ワークフロー定義に従って、修正プログラムの適用などの運用管理をシステムリソース４０に対して実行する。運用管理の自動化は、ＲＢＡ（Runbook Automation）と呼ばれることがある。この情報処理システムは、端末装置１００、フローコントローラ２００、フローエンジン３００、ルールエンジン４００および構成管理データベース（ＣＭＤＢ：Configuration Management Database）サーバ５００を含む。情報処理システムの各装置は、ネットワーク５０に接続されている。この情報処理システムは、例えば、データセンター内に設置することができる。

システムリソース４０は、情報処理で利用される各種の電子機器を含む。例えば、システムリソース４０は、サーバ装置４１、スイッチなどの通信装置４２およびストレージ装置４３を含む。サーバ装置４１は、ＣＰＵ、ＲＡＭ、ＨＤＤなどのリソースを用いて、アプリケーションソフトウェアを実行する。通信装置４２は、装置間（例えば、サーバ装置４１とストレージ装置４３の間）でデータを転送する。ストレージ装置４３は、情報処理に使用されるデータを、ＨＤＤなどの不揮発性の記憶装置に保存する。

端末装置１００は、ユーザ（例えば、情報処理システムの管理者）が操作するコンピュータである。端末装置１００は、ユーザの操作に基づいて、システムリソース４０の運用管理のワークフローを示すフロー情報を生成し、フローコントローラ２００に送信する。また、ワークフローの実行中にシステムリソース４０に異常がないか検査するためのルールを示すルール情報を生成し、フローコントローラ２００に送信する。また、端末装置１００は、ルール違反が発生したときの対処方法（リアクション）を示すリアクション情報を生成し、フローコントローラ２００に登録しておく。

フローコントローラ２００は、ワークフローの実行を制御するコンピュータである。フローコントローラ２００は、フロー情報をフローエンジン３００に登録し、フロー情報で定義された処理をフローエンジン３００に実行させる。また、ルール情報をルールエンジン４００に登録し、ルール違反が発生していないかルールエンジン４００に検査させる。ルール違反が検出された場合、リアクション情報で定義された処理をフローエンジン３００に実行させて、ワークフローを停止させる。フローコントローラ２００は、ワークフローの実行結果を、端末装置１００に報告する。

フローエンジン３００は、フローコントローラ２００からの指示に応じて、フロー情報で定義された処理をシステムリソース４０に対して実行するコンピュータである。例えば、フローエンジン３００は、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース４０の装置に対して送信する。

ルールエンジン４００は、フローエンジン３００がワークフローを実行している間、ルール違反がないか（システムリソース４０に異常がないか）を検査するコンピュータである。ルールエンジン４００は、ＣＭＤＢサーバ５００からシステムリソース４０の構成情報を取得し、構成情報とルール情報とを照合してルール検査を行う。ルール違反が検出された場合、フローコントローラ２００にルール違反を報告する。

ＣＭＤＢサーバ５００は、システムリソース４０から構成情報を収集するデータベースサーバとしてのコンピュータである。構成情報は、システムリソース４０の各装置が備えるハードウェア、各装置で実行されているソフトウェア、ハードウェアやソフトウェアの状態などを示す情報を含む。ＣＭＤＢサーバ５００が各装置に定期的にアクセスすることで構成情報を収集してもよいし、各装置が定期または不定期（例えば、構成情報が更新されたとき）にＣＭＤＢサーバ５００に構成情報を送信するようにしてもよい。ＣＭＤＢサーバ５００は、ルール検査に用いられる構成情報をルールエンジン４００に提供する。ＣＭＤＢサーバ５００は、ルール検査に用いられない構成情報を収集しなくてもよい。

なお、端末装置１００、フローコントローラ２００、フローエンジン３００、ルールエンジン４００およびＣＭＤＢサーバ５００のうちの複数のコンピュータの機能を、１台のコンピュータにまとめることも可能である。例えば、フローコントローラ２００、フローエンジン３００およびルールエンジン４００を、１台のコンピュータにまとめてもよい。

図３は、端末装置のハードウェア例を示すブロック図である。端末装置１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、ディスクドライブ１０６および通信部１０７を有する。上記ユニットは、端末装置１００内でバスに接続されている。なお、サーバ装置４１などのシステムリソース４０の装置、フローコントローラ２００、フローエンジン３００、ルールエンジン４００およびＣＭＤＢサーバ５００も、端末装置１００と同様のハードウェアにより実現できる。

ＣＰＵ１０１は、端末装置１００における情報処理を制御する演算装置である。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部を読み出し、ＲＡＭ１０２に展開してプログラムを実行する。なお、端末装置１００は、複数の演算装置を備えて、情報処理を分散して実行してもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が扱うプログラムやデータを一時的に記憶しておく揮発性メモリである。なお、端末装置１００は、ＲＡＭ以外の種類のメモリを備えていてもよく、複数個のメモリを備えていてもよい。

ＨＤＤ１０３は、ＯＳプログラムやアプリケーションプログラムなどのプログラム、および、情報処理に用いられるデータを記憶する不揮発性の記憶装置である。ＨＤＤ１０３は、ＣＰＵ１０１の命令に従って、内蔵の磁気ディスクに対する読み書きを行う。なお、端末装置１００は、ＨＤＤ以外の種類の不揮発性の記憶装置（例えば、ＳＳＤ（Solid State Drive））を備えていてもよく、複数の記憶装置を備えていてもよい。

画像信号処理部１０４は、ＣＰＵ１０１の命令に従って、端末装置１００に接続されたディスプレイ３１に画像を出力する。ディスプレイ３１として、例えば、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０５は、端末装置１００に接続された入力デバイス３２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス３２として、例えば、マウスやタッチパネルなどのポインティングデバイスや、キーボードなどを用いることができる。

ディスクドライブ１０６は、記録媒体３３に記録されたプログラムやデータを読み取る駆動装置である。記録媒体３３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。ディスクドライブ１０６は、例えば、ＣＰＵ１０１の命令に従って、記録媒体３３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信部１０７は、ネットワーク５０に接続して通信を行う通信インタフェースである。ネットワーク５０への接続方法は、有線でも無線でもよい。すなわち、通信部１０７は、有線通信インタフェースでも無線通信インタフェースでもよい。

図４は、情報処理システムのソフトウェア例を示すブロック図である。各ブロックは、例えば、ＣＰＵとＲＡＭを用いて実行されるプログラムのモジュールとして実装できる。
端末装置１００は、構成情報取得部１１０、ルール編集部１２０およびフロー編集部１３０を有する。フローコントローラ２００は、リアクション情報記憶部２１０とフロー制御部２２０とを有する。フローエンジン３００は、フロー情報記憶部３１０とフロー実行部３２０とを有する。ルールエンジン４００は、ルール情報記憶部４１０、ルール変換部４２０およびルール検査部４３０を有する。ＣＭＤＢサーバ５００は、構成情報記憶部５１０、関係情報記憶部５２０、構成情報収集部５３０および更新監視部５４０を有する。

構成情報取得部１１０は、ＣＭＤＢサーバ５００から構成情報を取得する。
ルール編集部１２０は、構成情報取得部１１０が取得した構成情報に基づいて、ルールを編集するための画面をディスプレイに表示する。そして、画面に対するユーザの入力からルール情報を生成し、フローコントローラ２００に送信する。また、ルール編集部１２０は、リアクションを編集するための画面をディスプレイに表示し、ユーザの入力からリアクション情報を生成してフローコントローラ２００に送信する。

フロー編集部１３０は、ワークフローを編集するための画面をディスプレイに表示し、ユーザの入力からフロー情報を生成してフローコントローラ２００に送信する。
リアクション情報記憶部２１０は、リアクション情報を記憶する。

フロー制御部２２０は、端末装置１００からルール情報を受信し、ルールエンジン４００に転送する。また、端末装置１００からリアクション情報を受信し、リアクション情報記憶部２１０に格納する。また、端末装置１００からフロー情報を受信し、ワークフローの実行中にルール違反が検出されたときリアクション情報の示すリアクションが実行されるよう、フロー情報を修正する。そして、修正したフロー情報をフローエンジン３００に送信する。また、フロー制御部２２０は、ワークフローの実行中、ルール検査をルールエンジン４００に指示し、検査結果に基づいてワークフローの続行や停止をフローエンジン３００に指示する。また、ワークフローの実行結果を端末装置１００に報告する。

フロー情報記憶部３１０は、フロー情報を記憶する。
フロー実行部３２０は、フローコントローラ２００からフロー情報を受信し、フロー情報記憶部３１０に格納する。また、フロー実行部３２０は、フローコントローラ２００からの指示に基づいて、フロー情報記憶部３１０に記憶されたフロー情報が示す１またはそれ以上のステップの処理（タスク）を実行する。例えば、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース４０に対して送信する。フロー実行部３２０は、タスクの実行のためにＣＭＤＢサーバ５００が保持する構成情報を参照することがあり、タスクの実行結果に基づいて構成情報を更新することがある。

ルール情報記憶部４１０は、ルール情報を記憶する。
ルール変換部４２０は、フローコントローラ２００からルール情報を受信し、ＣＭＤＢサーバ５００が保持する構成情報や波及関係情報を参照してルール情報を修正し、修正したルール情報をルール情報記憶部４１０に格納する。構成情報の項目（ＣＩ：Configuration Item）に代えて項目の種別がルール情報に記載されている場合、ルール変換部４２０は、ＣＭＤＢサーバ５００から構成情報の少なくとも一部を取得し、項目の種別を実在する項目に展開する。また、複数のルールがルール情報に含まれる場合、ＣＭＤＢサーバ５００から波及関係情報を取得し、継続的に検査する項目（監視する項目）が少なくなるようにルールを変換する。波及関係およびルール変換の詳細は後述する。

ルール検査部４３０は、フローコントローラ２００からの指示を受けて、ＣＭＤＢサーバ５００から構成情報の少なくとも一部を取得し、構成情報がルール情報記憶部４１０に記憶されたルール情報のルールに違反していないか検査する。そして、検査結果をフローコントローラ２００に報告する。また、ルール検査部４３０は、フローコントローラから自動検査の指示があると、構成情報の項目のうち監視する項目をＣＭＤＢサーバ５００に登録する。そして、登録した項目の情報が更新された旨をＣＭＤＢサーバ５００から通知されると、当該項目の情報をＣＭＤＢサーバ５００から取得して検査する。

構成情報記憶部５１０は、システムリソース４０から収集された構成情報を記憶する。
関係情報記憶部５２０は、構成情報の項目の間の波及関係を示す波及関係情報を記憶する。波及関係は、ＨＤＤの項目で異常が検出されるときは当該ＨＤＤを備えるサーバ装置の項目でも異常が検出されるといった、異常が項目間で波及する関係を含む。

構成情報収集部５３０は、システムリソース４０から構成情報を収集し、構成情報記憶部５１０に格納する。また、構成情報収集部５３０は、端末装置１００、フローエンジン３００およびルールエンジン４００からの要求に応じて、構成情報記憶部５１０に記憶された構成情報の少なくとも一部を要求元に送信する。なお、構成情報収集部５３０は、ルールエンジン４００が監視する項目以外の項目の情報を、継続的に収集しなくてもよい。その場合、構成情報収集部５３０は、収集していない項目の情報が要求されたとき、システムリソース４０から当該項目の情報を収集して、要求元に送信する。

更新監視部５４０は、ルールエンジン４００からの要求に応じて、関係情報記憶部５２０に記憶された波及関係情報をルールエンジン４００に送信する。また、更新監視部５４０は、ルールエンジン４００から監視する項目が通知されると、少なくとも通知された項目の情報を収集するよう、構成情報収集部５３０に指示する。そして、構成情報記憶部５１０に記憶された当該項目の情報を監視し、情報が更新されたことを検出すると、構成情報の更新が検出された旨をルールエンジン４００に通知する。

図５は、構成情報の項目例を示す図である。図５の構成情報の例は、種別がサービスである１つの項目（ｓｅｒｖｉｃｅＡ）と、種別がサーバである２つの項目（ｓｖｒ１，ｓｖｒ２）と、種別がアプリケーションである２つの項目（ａｐｐ１，ａｐｐ２）を含む。また、種別がＣＰＵである４つの項目（ｓｖｒ１＿ｃ１，ｓｖｒ１＿ｃ２，ｓｖｒ２＿ｃ１，ｓｖｒ２＿ｃ２）と、種別がメモリである２つの項目（ｓｖｒ１＿ｍ１，ｓｖｒ２＿ｍ１）と、種別がＨＤＤである２つの項目（ｓｖｒ１＿ｈ１，ｓｖｒ２＿ｈ１）を含む。

ｓｅｒｖｉｃｅＡは、２つのサーバ（ｓｖｒ１，ｓｖｒ２）によって提供される。ｓｖｒ１は、２つのＣＰＵ（ｓｖｒ１＿ｃ１，ｓｖｒ１＿ｃ２）と１つのメモリ（ｓｖｒ１＿ｍ１）と１つＨＤＤ（ｓｖｒ１＿ｈ１）を備える。ｓｖｒ２は、同様に、２つのＣＰＵ（ｓｖｒ２＿ｃ１，ｓｖｒ２＿ｃ２）と１つのメモリ（ｓｖｒ２＿ｍ１）と１つＨＤＤ（ｓｖｒ２＿ｈ１）を備える。ａｐｐ１はｓｖｒ１上で実行され、ａｐｐ２はｓｖｒ２上で実行されている。例えば、ａｐｐ１はＷｅｂアプリケーションであり、ａｐｐ２はデータベース管理システム（ＤＢＭＳ：Database Management System）である。

サービスの情報、サーバの情報、アプリケーションの情報、ＣＰＵの情報、メモリの情報およびＨＤＤの情報は、それぞれ、状態（ｓｔａｔｕｓ）の情報を含む。アプリケーションの情報は、更に、キャッシュサイズの情報、設定ファイルのパスの情報、トランザクション数の情報を含むことがある。構成情報は、上記以外の情報を含んでもよい。

図６は、構成情報の記述例を示す図である。図６に示す構成情報５１１は、図５に示した項目を、ＸＭＬ（Extensible Markup Language）によって記述したものである。構成情報５１１は、構成情報記憶部５１０に記憶される。構成情報５１１は、項目タグ（＜ｉｔｅｍ＞）と関係タグ（＜ｒｅｌａｔｉｏｎｓｈｉｐ＞）を含む。

項目タグは、構成情報の項目を示す。項目タグは、サーバタグ（＜Ｓｅｒｖｅｒ＞）またはアプリケーションタグ（＜Ａｐｐｌｉｃａｔｉｏｎ＞）を含む。サーバタグは、ＣＰＵタグ（＜Ｃｐｕ＞）、メモリタグ（＜Ｍｅｍｏｒｙ＞）およびＨＤＤタグ（＜Ｈｄｄ＞）を含む。サーバタグ、アプリケーションタグ、ＣＰＵタグ、メモリタグおよびＨＤＤタグは、それぞれ図５に示した何れかの項目に対応し、属性として状態（ｓｔａｔｕｓ）を示す値を含む。また、アプリケーションタグは、キャッシュサイズや設定ファイルのパスなどのパラメータを示すパラメータタグ（＜ｐａｒａｍ＞）を含む。パラメータタグは、属性として当該パラメータの値を含む。

関係タグは、項目タグが示す項目の間の関係を示す。関係タグは、属性として関係の種別（タイプ）を示す値を含む。また、関係タグは、ソース項目タグ（＜ｓｏｕｒｃｅＩｔｅｍ＞）とターゲット項目タグ（＜ｔａｒｇｅｔＩｔｅｍ＞）を含む。例えば、ソース項目がサービス、ターゲット項目がサーバ、タイプが“ｃｏｎｓｉｓｔＯｆ”である関係タグは、サービスがサーバを用いて実現される関係を示す。また、ソース項目がアプリケーション、ターゲット項目がサーバ、タイプが“ｉｎｓｔａｌｌｅｄＯｎ”である関係タグは、アプリケーションがサーバ上で実行される関係を示す。

図７は、異常の波及関係の例を示す図である。波及関係は、異常が構成情報の項目間で波及する関係であり、波及する方向をもつ。例えば、ＨＤＤ故障およびメモリエラーは、それぞれサーバ故障の原因となる。設定エラーおよび高負荷は、アプリケーション異常の原因となる。サーバ故障およびアプリケーション異常は、サービス異常の原因となる。よって、構成情報において、ＨＤＤの項目の状態（ｓｔａｔｕｓ）がエラーを示すとき、サーバの項目の状態もエラーを示すことが想定される。また、サーバの項目の状態がエラーを示すとき、サービスの項目の状態もエラーを示すことが想定される。このように、上位の項目の状態は、下位の項目の状態の影響を受ける。

図８は、波及関係テーブルの例を示す図である。図８の波及関係テーブルの例は、図７の波及関係に対応している。波及関係テーブル５２１は、関係情報記憶部５２０に記憶される。波及関係テーブル５２１は、ＩＤ、異常、親異常および条件の項目を含む。

ＩＤは、異常を識別するための識別情報である。異常の項目は、サービス異常などの異常の要因を示す。親異常は、当該異常から直接影響を受ける他の異常を示す。例えば、ＨＤＤ故障の親異常はサーバ故障であり、サーバ故障の親異常はサービス異常である。条件は、状態異常が生じているか否かを構成情報から判断するための式の雛形であり、項目の種別名（Ｓｅｒｖｉｃｅなど）を用いて記述される。図８の例では、異常でないとき（正常のとき）に真となる論理式の雛形を条件として記述しているが、異常であるときに真となる論理式の雛形を記述してもよい。なお、図８において、［ＡＴＴＲ］は任意のパラメータ名を示し、［ＯＰ］は任意の演算子を示し、［ＶＡＬ］は任意の固定値を示す。

図９は、ルール定義テーブルの例を示す図である。ルール定義テーブル４１１は、ルール変換部４２０によって生成され、ルール情報記憶部４１０に記憶される。ルール定義テーブル４１１は、ＩＤ、ルールおよび親ルールの項目を含む。

ＩＤは、ルールを識別するための識別情報である。ルールは、異常が生じているか否かを構成情報から判断するための式として記述され、項目名（ｓｅｒｖｉｃｅＡなど）を用いて記述される。図９の例では、異常でないとき（正常のとき）に真となる論理式をルールとして記述しているが、異常であるときに真となる論理式を記述してもよい。親ルールは、当該ルールに基づいて異常が検出された（ルール違反が生じた）ときに、同様にルール違反が生じると考えられる他のルールを示す。

例えば、図９の例では、ルールＲ１，Ｒ２の親ルールはルールＲ４である。ルールＲ１，Ｒ２の少なくとも一方の違反が生じると、ルールＲ４の違反も生じると考えられる。一方、ルールＲ４の違反が生じていない場合、ルールＲ１，Ｒ２の違反も生じていないと考えられ、ルールＲ１，Ｒ２の検査は省略できる。なお、後述するように、端末装置１００のユーザは、ルールＲ１，Ｒ２，Ｒ３を定義すればよい。ルールＲ４は、ルールＲ１，Ｒ２に基づいて、ルール変換部４２０によって自動的に追加される。

図１０は、リアクション定義テーブルの例を示す図である。リアクション定義テーブル２１１は、リアクション情報記憶部２１０に記憶される。リアクション定義テーブル２１１は、ＩＤ、条件およびリアクションの項目を含む。

ＩＤは、リアクションを識別するための識別情報である。条件は、リアクションが実行されるときの条件を示す。例えば、“Ｒ１ ＯＲ Ｒ３”は、上記のルールＲ１，Ｒ３の少なくとも一方のルール違反が検出されたという条件を示す。また、“Ｒ２ ＡＮＤ Ｒ３”は、上記のルールＲ２，Ｒ３の両方のルール違反が検出されたという条件を示す。リアクションの項目は、リアクションの内容を示す。例えば、サービスの提供に用いるサーバ装置を追加する、サービスを停止させる、などのリアクションを定義しておく。

次に、ルールを情報処理システムに登録する処理を説明する。
図１１は、ルール登録処理を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。

（ステップＳ１１）端末装置１００の構成情報取得部１１０は、ＣＭＤＢサーバ５００にアクセスして構成情報５１１を取得する。
（ステップＳ１２）端末装置１００のルール編集部１２０は、ステップＳ１１で取得された構成情報５１１に基づいて、実在する項目または項目の種別を選択してルールを入力できるようにするルール編集画面を生成し、ディスプレイに表示する。そして、ルール編集部１２０は、ユーザが入力したルールを示すルール情報を生成し、フローコントローラ２００に送信する。フローコントローラ２００のフロー制御部２２０は、端末装置１００から受信したルール情報をルールエンジン４００に転送する。

（ステップＳ１３）ルールエンジン４００のルール変換部４２０は、フローコントローラ２００から受信したルール情報に、項目の種別を用いて記述されたルールが含まれるか判断する。ルールに項目の種別が含まれているか否かは、ＣＭＤＢサーバ５００が有する構成情報５１１を参照して判断してもよい。含まれる場合、処理をステップＳ１４に進める。含まれない場合、処理をステップＳ１５に進める。

（ステップＳ１４）ルール変換部４２０は、ＣＭＤＢサーバ５００にアクセスして構成情報５１１を取得する。そして、ルール変換部４２０は、構成情報５１１に基づいて、ルール情報に含まれる項目の種別を実在する項目に展開する。

（ステップＳ１５）ルール変換部４２０は、ＣＭＤＢサーバ５００にアクセスして波及関係テーブル５２１を取得する。
（ステップＳ１６）ルール変換部４２０は、ステップＳ１２でフローコントローラ２００から受信したルール情報に含まれるルールを１つ選択する。

（ステップＳ１７）ルール変換部４２０は、ステップＳ１６で選択したルールが、ステップＳ１５で取得した波及関係テーブル５２１に記載された何れかの条件に合致するか判断する。判断の際には、ルールに含まれる項目を種別に置換して、条件と比較する。項目から種別への置換は、構成情報５１１を参照し行ってもよい。合致する場合、処理をステップＳ１８に進める。合致しない場合、処理をステップＳ２０に進める。

（ステップＳ１８）ルール変換部４２０は、波及関係テーブル５２１で定義される木（図７に示したような木）の部分木を生成する。生成する部分木は、ステップＳ１７で合致した条件に対応するノードとルートノードとの間の経路を含む。例えば、ステップＳ１６で選択したルールがサーバ故障（Ｓ２）の条件に合致した場合、サービス異常（Ｓ１）に対応するノードとサーバ故障（Ｓ２）に対応するノードを含む部分木が生成される。

（ステップＳ１９）ルール変換部４２０は、構成情報５１１を参照して、ステップＳ１８で生成した部分木の各ノードに対して項目を対応付ける。例えば、ステップＳ１６で選択したルールがサーバの項目ｓｖｒ１を含む場合、サーバ故障（Ｓ２）のノードにサーバの項目ｓｖｒ１を対応付け、サービス異常（Ｓ１）のノードにサービスの項目ｓｅｒｖｉｃｅＡを対応付ける。そして、処理をステップＳ２１に進める。

（ステップＳ２０）ルール変換部４２０は、ステップＳ１６で選択したルールを監視対象のルール（親ルールをもたないルール）に指定する。
（ステップＳ２１）ルール変換部４２０は、ステップＳ１６でルール情報に含まれる全てのルールを選択したか判断する。全てのルールを選択した場合、処理をステップＳ２２に進める。未選択のルールがある場合、処理をステップＳ１６に進める。

図１２は、ルール登録処理を示すフローチャート（続き）である。
（ステップＳ２２）ルール変換部４２０は、生成された部分木の中に、異常要因と項目の両方が同じであるノードを含む２以上の部分木が存在するか検索し、検索された当該２以上の部分木を、１つの部分木にマージする。

（ステップＳ２３）ルール変換部４２０は、ステップＳ２２でマージが行われた後の部分木の集合の中から、部分木を１つ選択する。
（ステップＳ２４）ルール変換部４２０は、ステップＳ２３で選択した部分木に分岐が存在するか（複数の葉ノードを含むか）判断する。分岐が存在する（複数の葉ノードを含む）場合、処理をステップＳ２５に進める。分岐が存在しない（１つの葉ノードのみを含む）場合、処理をステップＳ２７に進める。

（ステップＳ２５）ルール変換部４２０は、ステップＳ２３で選択した部分木から、分岐元のノードのうち最上位に位置するもの（全ての葉ノードをカバーできるノードのうち最下位に位置するもの）を選択する。

（ステップＳ２６）ルール変換部４２０は、ステップＳ１５で取得した波及関係テーブル５２１から、ステップＳ２５で選択したノードに対応する条件を取得する。そして、条件に含まれる項目の種別を、選択したノードに対応付けられた項目に置換することで、上位のルールを生成する。ルール変換部４２０は、生成したルールを監視対象のルールに指定する。その後、処理をステップＳ２８に進める。

（ステップＳ２７）ルール変換部４２０は、ステップＳ２３で選択した部分木の葉ノードに対応するルール（フローコントローラ２００から受信したルール情報に含まれていた元のルール）を、監視対象のルールに指定する。

（ステップＳ２８）ルール変換部４２０は、ステップＳ２３で全ての部分木を選択したか判断する。全ての部分木を選択した場合、監視対象に指定したルールおよび元のルールを含むルール定義テーブル４１１をルール情報記憶部４１０に格納し、処理を終了する。未選択の部分木がある場合、処理をステップＳ２３に進める。

図１３は、ルール編集画面の例を示す図である。端末装置１００は、ＣＭＤＢサーバ５００が有する構成情報に基づいて、ルール作成を支援するためのルール編集画面１２１を生成する。ルール編集画面１２１は、例えば、ディスプレイ３１に表示される。ルール編集画面１２１は、種別、項目、属性およびルールの欄を含む。

種別の欄には、サーバやＨＤＤなどの種別が記載される。項目の欄には、構成情報に含まれる実在の項目が種別毎に記載される。ユーザは、検査対象の種別または項目を選択することができる。種別を選択した場合、実在する当該種別の項目全てを選択したものとして取り扱われる。例えば、サーバを選択すると、サーバの項目ｓｖｒ１，ｓｖｒ２の両方を選択したものとして取り扱われる。属性の欄には、構成情報に含まれる属性が記載される。ルールの欄には、属性に対する式を入力することができる。ユーザは、選択した種別または項目に対応する１またはそれ以上の属性を指定して式を入力する。

図１４は、ルール変換の例を示す図である。図９に示したルールＲ１，Ｒ２が、端末装置１００で生成されたルール情報に含まれているとする。
ルールエンジン４００は、ルールＲ１から、サーバ故障のノードとサービス異常のノードを含む部分木を生成する。サーバ故障のノードには、項目ｓｖｒ１が対応付けられ、サービス異常のノードには、項目ｓｖｒ１と関連する項目ｓｅｒｖｉｃｅＡが対応付けられる。また、ルールエンジン４００は、ルールＲ２から、高負荷のノードとアプリケーション異常のノードとサービス異常のノードを含む部分木を生成する。高負荷のノードには、項目ａｐｐ２が対応付けられ、アプリケーション異常のノードには、項目ａｐｐ２が対応付けられ、サービス異常のノードには、項目ｓｅｒｖｉｃｅＡが対応付けられる。

ルールエンジン４００は、上記２つの部分木の間で、ルートノードの異常要因（サービス異常）と項目（ｓｅｒｖｉｃｅＡ）が一致するため、上記２つの部分木をマージする。ルールエンジン４００は、マージ後の部分木の中から、最上位の分岐ノードであるサービス異常のノードを選択する。そして、ルールエンジン４００は、サービス異常のノードに対応するルールＲ４を生成し、ルールＲ４を継続的に検査するルールに指定する。この場合、元のルールＲ１，Ｒ２は、継続的に検査するルールに指定されない。

次に、ワークフローを情報処理システムに登録する処理を説明する。
図１５は、ワークフローの例を示す図である。フローコントローラ２００は、端末装置１００から受信したフロー情報を修正して、ワークフローの途中でルール検査が行われるようにする。そして、修正したフロー情報を、フローエンジン３００に登録する。

タスク１とタスク２を逐次的に実行するワークフローを示すフロー情報が、端末装置１００で生成されたとする。フローコントローラ２００は、最初の通常タスク（タスク１）の前に事前検査の検査タスクを挿入し、最後の通常タスク（タスク２）の後に事後検査の検査タスクを挿入する。また、通常タスクの間それぞれ（タスク１とタスク２の間）に、実行中検査の検査タスク（実行中検査１）を挿入する。また、各検査タスクの後に検査結果に応じた分岐を挿入し、ルール違反が検出された場合はワークフローを停止するための通常タスク（キャンセル）に遷移するように、タスク間の遷移を修正する。

図１６は、フロー情報の記述例を示す図である。図１６に示すフロー情報３１１は、図１５に示した修正後のワークフローを、ＸＭＬによって記述したものである。フロー情報３１１は、フローエンジン３００のフロー情報記憶部３１０に記憶される。

フロー情報３１１は、ワークフロー毎に、ワークフロー名の属性を有するタグ（＜ｐｒｏｃｅｓｓ＞）を含む。また、フロー情報３１１は、検査タスク毎に、検査タスク名の属性を有するタグ（＜ｒｅｃｅｉｖｅＴａｓｋ＞）を含み、通常タスク毎に、通常タスク名の属性を有するタグ（＜ｓｃｒｉｐｔＴａｓｋ＞）を含む。また、フロー情報３１１は、分岐に対応するタグ（＜ｅｘｃｌｕｓｉｖｅＧａｔｅｗａｙ＞）と、タスク間の遷移またはタスクと分岐の間の遷移を示すタグ（＜ｓｅｑｕｅｎｃｅＦｌｏｗ＞）を含む。

図１７は、フロー登録処理を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
（ステップＳ３１）端末装置１００のフロー編集部１３０は、ユーザからの入力に応じて、検査タスクを含まないワークフローを示すフロー情報を生成する。そして、フロー編集部１３０は、フロー情報をフローコントローラ２００に送信する。

（ステップＳ３２）フローコントローラ２００のフロー制御部２２０は、端末装置１００から受信したフロー情報が示すワークフローに、事前検査の検査タスクおよび事後検査の検査タスクを追加する。

（ステップＳ３３）フロー制御部２２０は、フロー情報が示すワークフローについて、通常タスクの間に実行中検査の検査タスクを挿入する。
（ステップＳ３４）フロー制御部２２０は、フロー情報が示すワークフローについて、検査タスクの後に分岐を挿入する。

（ステップＳ３５）フロー制御部２２０は、フロー情報が示すワークフローに、検査タスクでルール違反が検出された場合に実行される通常タスクを追加する。また、ステップＳ３４で挿入した分岐から当該通常タスクへの遷移を追加する。

（ステップＳ３６）フロー制御部２２０は、修正したフロー情報をフローエンジン３００に送信する。フローエンジン３００のフロー実行部３２０は、フローコントローラ２００から受信したフロー情報を、フロー情報記憶部３１０に格納する。

次に、ワークフローの実行中に行われるルール検査の処理を説明する。
図１８は、ルール検査処理を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。

（ステップＳ４１）ルールエンジン４００のルール検査部４３０は、ルール情報記憶部４１０に記憶されたルール定義テーブル４１１に登録されているルールから、監視対象のルール（親ルールをもたないルール）を選択する。

（ステップＳ４２）ルール検査部４３０は、ステップＳ４１で選択したルールに現れる項目についての構成情報を、ＣＭＤＢサーバ５００から取得する。
（ステップＳ４３）ルール検査部４３０は、ステップＳ４２で取得した構成情報を用いてルールを評価し、不適合のルールがあるか（例えば、論理式が偽となるか）判断する。不適合のルールが少なくとも１つある場合、処理をステップＳ４４に進める。不適合のルールがない場合、処理をステップＳ４８に進める。

（ステップＳ４４）ルール検査部４３０は、ルール定義テーブル４１１を参照し、不適合のルールの下位のルール（不適合のルールを親ルールとしてもつ他のルール）があるか判断する。下位のルールが少なくとも１つの不適合のルールについて存在する場合、処理をステップＳ４５に進める。下位のルールがない場合、処理をステップＳ４７に進める。

（ステップＳ４５）ルール検査部４３０は、ルール定義テーブル４１１に登録されているルールから、不適合のルールの下位のルールを選択する。
（ステップＳ４６）ルール検査部４３０は、ステップＳ４５で選択したルールに現れる項目についての構成情報を、ＣＭＤＢサーバ５００に要求する。ＣＭＤＢサーバ５００の構成情報収集部５３０は要求された構成情報を、システムリソース４０から収集して、ルールエンジン４００に送信する。なお、構成情報収集部５３０は、要求された構成情報が収集対象となっている場合は、構成情報記憶部５１０に記憶された構成情報を送信する。ルール検査部４３０は、取得した構成情報を用いてルールを評価する。

（ステップＳ４７）ルール検査部４３０は、ルール違反があると判定し、違反が検出されたルールを特定する。そして、ルール検査部４３０は、違反が検出されたルールをフローコントローラ２００に報告する。その後、処理を終了する。

（ステップＳ４８）ルール検査部４３０は、ルール違反がないと判定する。ルール検査部４３０は、フローコントローラ２００からの指示に基づいてルール検査を開始した場合には、ルール違反がないことをフローコントローラ２００に報告する。

例えば、図９に示したルール定義テーブル４１１がルール情報記憶部４１０に記憶されている場合、ルール検査部４３０は、ルールＲ３，Ｒ４に基づいて項目ｓｅｒｖｉｃｅＡを検査する。ルールＲ３の違反が検出された場合、下位のルールが存在しないため、ルールＲ３単独の違反と判定する。一方、ルールＲ４の違反が検出された場合、ルール検査部４３０は、下位のルールＲ１，Ｒ２に基づいて項目ｓｖｒ１と項目ａｐｐ２を検査する。そして、違反が検出されたルールを、下位のルールも含めて特定する。

次に、ワークフローの実行制御の流れを説明する。
図１９は、ワークフローの実行手順の例を示す第１のシーケンス図である。図１９において、ステップＳ５１〜Ｓ５６は、ワークフローを開始する際に行われる。ステップＳ５７〜Ｓ６１は、ワークフローで定義された検査タスクを実行する際に行われる。

（ステップＳ５１）端末装置１００は、ルール情報およびフロー情報を生成し、フローコントローラ２００に送信する。
（ステップＳ５２）フローコントローラ２００は、端末装置１００から受信したフロー情報を修正して、ルール検査が行われるようにワークフローを変換する。ワークフローの変換の際には、登録されているリアクション情報を参照してもよい。

（ステップＳ５３）フローコントローラ２００は、ステップＳ５２で修正したフロー情報を、フローエンジン３００に送信する。フローエンジン３００は、端末装置１００から受信したフロー情報を保存する。

（ステップＳ５４）フローコントローラ２００は、端末装置１００から受信したルール情報をルールエンジン４００に転送する。
（ステップＳ５５）ルールエンジン４００は、フローコントローラ２００から受信したルール情報に記載されている項目の種別を項目に展開する。また、監視対象のルール（継続的に検査するルール）が少なくなるように、ルールをルール情報に追加する。その際、ルールエンジン４００は、ＣＭＤＢサーバ５００がもつ構成情報や波及関係情報を参照する。そして、修正したルール情報を保存する。

（ステップＳ５６）フローコントローラ２００は、フロー情報およびルール情報の登録が完了したことを確認し、ワークフローの開始をフローエンジン３００に指示する。フローコントローラ２００は、フロー情報に記載されたタスクを逐次的に実行する。

（ステップＳ５７）フローエンジン３００は、次に実行するタスクが検査タスク（事前検査、実行中検査または事後検査のタスク）である場合、ワークフローを中断し、中断したことをフローコントローラ２００に通知する。

（ステップＳ５８）フローコントローラ２００は、ルールエンジン４００に、ルール情報に基づく構成情報の検査を指示する。
（ステップＳ５９）ルールエンジン４００は、ＣＭＤＢサーバ５００から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。

（ステップＳ６０）ルールエンジン４００は、ステップＳ５９の検査結果をフローコントローラ２００に報告する。ルール違反が検出された場合には、違反と判定されたルールの識別情報も、フローコントローラ２００に報告する。

（ステップＳ６１）フローコントローラ２００は、ルールエンジン４００から報告された検査結果に基づいて、フローエンジン３００に次動作を指示する。次動作の指示の際には、登録されているリアクション情報を参照してもよい。例えば、フローコントローラ２００は、ルール違反が検出されなかったときは“ＮＥＸＴ”（フロー継続）を指示し、ルール違反が検出されたときは“ＣＡＮＣＥＬ”（フロー終了）を指示する。フローエンジン３００は、中断しているワークフローを再開し、フローコントローラ２００からの指示に応じて、フロー情報に記載された分岐の方向を判断する。

図２０は、ワークフローの実行手順の例を示す第２のシーケンス図である。図２０において、ステップＳ６２〜Ｓ６５は、検査タスクが実行されるタイミング以外のタイミングでもルール検査を適宜行えるようにする処理であり、事前検査の直後に行われる。ステップＳ６６〜Ｓ６９は、通常タスクを実行する際に行われる。

（ステップＳ６２）フローエンジン３００は、事前検査の検査タスクが終了した後に、ワークフローを中断し、中断したことをフローコントローラ２００に通知する。
（ステップＳ６３）フローコントローラ２００は、ルールエンジン４００に、自動的にルール検査が行われるようにする設定を指示する。

（ステップＳ６４）ルールエンジン４００は、ルール情報から、監視対象のルールに現れる項目を抽出し、ＣＭＤＢサーバ５００に通知する。ＣＭＤＢサーバ５００は、ルールエンジン４００から通知された項目を、監視する項目として登録する。

（ステップＳ６５）フローコントローラ２００は、監視する項目の登録が完了したことを確認し、フローエンジン３００に次動作の指示としてフロー継続を指示する。フローエンジン３００は、中断しているワークフローを再開する。

（ステップＳ６６）フローコントローラ２００は、次に実行するタスクが通常タスクである場合、フロー情報で定義される処理を実行する。フロー情報で定義される処理としては、例えば、システムリソース４０の装置への停止コマンドの送信、修正プログラムをインストールさせるコマンドの送信、再起動コマンドの送信などが考えられる。フローコントローラ２００は、通常タスクの実行の際に、ＣＭＤＢサーバ５００がもつ構成情報を参照することがあり、構成情報を更新することもある。

（ステップＳ６７）ＣＭＤＢサーバ５００は、ステップＳ６４で登録された項目についての構成情報が変更されているか否かを監視する。ＣＭＤＢサーバ５００がもつ構成情報は、フローコントローラ２００によって変更されることがあり、また、システムリソース４０から収集した情報によって変更されることがある。ＣＭＤＢサーバ５００は、構成情報の変更を検出すると、ルールエンジン４００に変更を通知する。

（ステップＳ６８）ルールエンジン４００は、ＣＭＤＢサーバ５００から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。

（ステップＳ６９）ルールエンジン４００は、ステップＳ６８ルール違反を検出した場合、ルール違反が検出された旨および違反と判定されたルールの識別情報を、フローコントローラ２００に報告する。ルール違反を検出しなかった場合は、フローコントローラ２００にその旨を報告しなくてもよい。フローコントローラ２００は、例えば、次にワークフローが中断されたタイミングで、フローエンジン３００にフロー終了を指示する。

図２１は、ワークフローの実行手順の例を示す第３のシーケンス図である。図２１において、ステップＳ７０〜Ｓ７３は、自動検査の設定を解除する処理であり、事後検査の直前に行われる。ステップＳ７４〜Ｓ７７は、ワークフローを終了する際に行われる。

（ステップＳ７０）フローエンジン３００は、事後検査の検査タスクを実行する前に、ワークフローを中断し、中断したことをフローコントローラ２００に通知する。
（ステップＳ７１）フローコントローラ２００は、ルールエンジン４００に、自動的にルール検査が行われるようにする設定の解除を指示する。

（ステップＳ７２）ルールエンジン４００は、ルール情報から、監視対象のルールに現れる項目を抽出し、ＣＭＤＢサーバ５００に通知する。ＣＭＤＢサーバ５００は、ルールエンジン４００から通知された項目の登録を抹消する。

（ステップＳ７３）フローコントローラ２００は、監視する項目の抹消が完了したことを確認し、フローエンジン３００に次動作の指示としてフロー継続を指示する。フローエンジン３００は、中断しているワークフローを再開する。

（ステップＳ７４）フローエンジン３００は、ワークフローが終了する（例えば、事後検査のタスクが終了する）と、終了したことをフローコントローラ２００に通知する。ワークフローの終了には、正常終了と異常終了とが含まれる。

（ステップＳ７５）フローコントローラ２００は、ルール情報の削除をルールエンジン４００に指示する。ルールエンジン４００は、ルール情報を削除する。
（ステップＳ７６）フローコントローラ２００は、フロー情報の削除をフローエンジン３００に指示する。フローエンジン３００は、フロー情報を削除する。

（ステップＳ７７）フローコントローラ２００は、ワークフローの実行結果として正常終了または異常終了を、端末装置１００に報告する。
第２の実施の形態の情報処理システムによれば、項目間の波及関係を考慮して複数のルールを統合し、統合したルールについて継続的に検査することで、ルール検査の回数を削減でき、検査の負荷を軽減することができる。また、上位のルールで違反が検出されたときに、下位の複数のルールについて検査を行うことで、異常原因を把握することが可能となる。また、下位のルールに対応する構成情報を継続的に収集しないようにすることで、構成情報を収集する負荷も軽減することができる。

また、監視する項目をＣＭＤＢサーバ５００に登録しておき、登録した項目の情報が変更されたことを契機として検査を行うことで、ルール検査を効率化することができる。また、ＣＭＤＢサーバ５００がもつ構成情報を参照して、実在する項目を指定してルールを記述できるようにするルール編集画面をユーザに提供することで、実在しない項目を指定した不適切なルールが記述されることを防止できる。また、ユーザが項目の種別を指定してルールを記述できるようにすることで、ルールの記述漏れを抑制できる。

なお、前述のように、第２の実施の形態のワークフロー制御およびルール検査は、コンピュータとしての端末装置１００、フローコントローラ２００、フローエンジン３００、ルールエンジン４００およびＣＭＤＢサーバ５００に、それぞれプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、記録媒体３３）に記録しておくことができる。記録媒体として、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、ＦＤおよびＨＤＤが含まれる。光ディスクには、ＣＤ、ＣＤ−Ｒ（Recordable）／ＲＷ（Rewritable）、ＤＶＤおよびＤＶＤ−Ｒ／ＲＷが含まれる。

プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。また、プログラムを他のコンピュータの記憶装置に格納しておき、ネットワーク５０経由でプログラムを配布することもできる。コンピュータは、例えば、可搬記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを記憶装置（例えば、ＨＤＤ１０３）に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよく、他のコンピュータからネットワーク５０を介して受信したプログラムを直接実行してもよい。

１０ 情報処理装置
１１ 記憶部
１１ａ 検査情報
１２ 検査部
２１〜２３ 装置

Claims (6)

1. １または複数の装置から取得される複数の項目の情報に基づいて、前記１または複数の装置を監視する情報処理システムが行う監視方法であって、
   それぞれが前記複数の項目に含まれる第１の項目、第２の項目および第３の項目より構成される項目群であって、前記第３の項目の情報が前記第１の項目の情報および前記第２の項目の情報から影響を受ける関係にある項目群について、前記第３の項目の情報を検査し、
   前記第３の項目の情報の検査で異常が検出されなかった場合、前記第１の項目の情報および前記第２の項目の情報の検査を省略し、
   前記第３の項目の情報の検査で異常が検出された場合、前記第１の項目の情報および前記第２の項目の情報をそれぞれ検査する、
   監視方法。
2. 検査対象として前記第１の項目および前記第２の項目が指定されたとき、前記複数の項目の間の関係であって、一の項目の情報が他の項目の情報に影響を与える関係を示す関係情報を記憶する記憶装置を参照し、前記第１の項目および前記第２の項目に基づいて前記第３の項目を検索し、
   検索された前記第３の項目を検査対象に追加する、
   請求項１記載の監視方法。
3. 前記１または複数の装置から前記第３の項目の情報を取得し、
   前記第３の項目の情報の検査で異常が検出された後に、前記１または複数の装置から前記第１の項目の情報および前記第２の項目の情報を取得する、
   請求項１記載の監視方法。
4. 前記１または複数の装置から前記複数の項目の情報の少なくとも一部を収集するデータベース装置に、前記第３の項目の情報を収集させ、
   前記データベース装置で前記第３の項目の情報が更新されたことが検出されたとき、更新された前記第３の項目の情報を検査する、
   請求項１記載の監視方法。
5. １または複数の装置から取得される複数の項目の情報に基づいて、前記１または複数の装置を監視する情報処理装置であって、
   検査対象として、それぞれが前記複数の項目に含まれる第１の項目、第２の項目および第３の項目より構成される項目群であって、前記第３の項目の情報が前記第１の項目の情報および前記第２の項目の情報から影響を受ける関係にある項目群を示す検査情報を記憶する記憶部と、
   前記検査情報が示す前記項目群に含まれる前記第３の項目の情報を検査し、前記第３の項目の情報の検査で異常が検出されなかった場合、前記第１の項目の情報および前記第２の項目の情報の検査を省略し、前記第３の項目の情報の検査で異常が検出された場合、前記第１の項目の情報および前記第２の項目の情報を検査する検査部と、
   を有する情報処理装置。
6. １または複数の装置から取得される複数の項目の情報に基づいて、前記１または複数の装置を監視するための監視プログラムであって、コンピュータに、
   それぞれが前記複数の項目に含まれる第１の項目、第２の項目および第３の項目より構成される項目群であって、前記第３の項目の情報が前記第１の項目の情報および前記第２の項目の情報から影響を受ける関係にある項目群について、前記第３の項目の情報を検査し、
   前記第３の項目の情報の検査で異常が検出されなかった場合、前記第１の項目の情報および前記第２の項目の情報の検査を省略し、
   前記第３の項目の情報の検査で異常が検出された場合、前記第１の項目の情報および前記第２の項目の情報をそれぞれ検査する、
   処理を実行させる監視プログラム。
   

Images