監視方法、情報処理装置および監視プログラム
【課題】複数の項目の情報を用いた監視の負荷を軽減する。
【解決手段】情報処理装置10は、装置21〜23から取得される複数の項目の情報に基づいて、装置21〜23を監視する。項目#3の情報は、項目#1,#2の情報と関連する。情報処理装置10は、項目#3の情報を検査する。情報処理装置10は、項目#3の情報の検査で異常が検出されなかった場合、項目#1,#2の情報の検査を省略する。項目#3の情報の検査で異常が検出された場合、項目#1,#2の情報をそれぞれ検査する。
【解決手段】情報処理装置10は、装置21〜23から取得される複数の項目の情報に基づいて、装置21〜23を監視する。項目#3の情報は、項目#1,#2の情報と関連する。情報処理装置10は、項目#3の情報を検査する。情報処理装置10は、項目#3の情報の検査で異常が検出されなかった場合、項目#1,#2の情報の検査を省略する。項目#3の情報の検査で異常が検出された場合、項目#1,#2の情報をそれぞれ検査する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、1またはそれ以上の装置を監視する監視方法、情報処理装置および監視プログラムに関する。
【背景技術】
【0002】
情報処理システムを運用する場合、サーバ装置、ストレージ装置、通信装置などの装置に異常がないか、システム管理者が確認し、異常があれば対応措置を行うことがある。例えば、ハードウェアの故障が発見されたときは、装置を停止させてハードウェアを交換することがある。また、ソフトウェアの実行状態の異常が発見されたときは、ソフトウェアのプロセスを停止させて、異常原因を調査することがある。また、装置の過剰負荷が発見されたときは、情報処理のためのリソースを追加することがある。
【0003】
一方で、情報処理システムの有する装置が多数になると、システム管理者の監視作業の負担が大きくなる。そこで、運用管理用の情報処理装置が、監視対象の装置から情報を収集し、収集した情報を検査することで、装置の異常な状態(または、異常の兆候)を自動的に検出することが考えられる。異常を検出した情報処理装置は、システム管理者に対する警告を発行することもできるし、予め定義された処理手順に従って対応措置を行う(例えば、異常な状態の装置に対して停止命令を送信する)こともできる。
【0004】
なお、予め定義されたワークフローに従って自律的に計算機の運用管理を行う運用管理システムにおいて、管理対象の計算機から情報を収集し、収集した情報と停止判断ルールとを照合して、自立制御を継続するか停止するか判断する方法が提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2007−4337号公報(段落[0028],[0030])
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかし、情報を収集して検査すべき項目が増えると、監視の負荷が増大するという問題がある。例えば、サーバ装置毎に、HDD(Hard Disk Drive)の状態、メモリの状態、当該サーバ装置が実行しているトランザクションの数など、具体的な項目の情報を継続的に検査すると、検査を行う情報処理装置の負荷が増大する。
【0007】
一側面では、本発明は、複数の項目の情報を用いた監視の負荷を軽減できる監視方法、情報処理装置および監視プログラムを提供することを目的とする。
【課題を解決するための手段】
【0008】
一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視する情報処理システムが行う監視方法が提供される。第1の項目、第2の項目、および、取得される情報が第1および第2の項目の情報と関連する第3の項目のうち、第3の項目の情報を検査する。第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略する。第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報をそれぞれ検査する。
【0009】
また、一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視する情報処理装置が提供される。情報処理装置は、記憶部と検査部とを有する。記憶部は、検査対象として、第1の項目と、第2の項目と、取得される情報が第1および第2の項目の情報と関連する第3の項目とを示す検査情報を記憶する。検査部は、検査情報が示す検査対象の項目の情報を検査する。検査部は、第3の項目の情報を検査し、第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略し、第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報を検査する。
【0010】
また、一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視するための監視プログラムが提供される。監視プログラムは、コンピュータに以下の処理を実行させる。第1の項目、第2の項目、および、取得される情報が第1および第2の項目の情報と関連する第3の項目のうち、第3の項目の情報を検査する。第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略する。第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報をそれぞれ検査する。
【発明の効果】
【0011】
一実施態様によれば、複数の項目の情報を用いた監視の負荷を軽減できる。
【図面の簡単な説明】
【0012】
【図1】第1の実施の形態の情報処理装置を示す図である。
【図2】第2の実施の形態の情報処理システムを示す図である。
【図3】端末装置のハードウェア例を示すブロック図である。
【図4】情報処理システムのソフトウェア例を示すブロック図である。
【図5】構成情報の項目例を示す図である。
【図6】構成情報の記述例を示す図である。
【図7】異常の波及関係の例を示す図である。
【図8】波及関係テーブルの例を示す図である。
【図9】ルール定義テーブルの例を示す図である。
【図10】リアクション定義テーブルの例を示す図である。
【図11】ルール登録処理を示すフローチャートである。
【図12】ルール登録処理を示すフローチャート(続き)である。
【図13】ルール編集画面の例を示す図である。
【図14】ルール変換の例を示す図である。
【図15】ワークフローの例を示す図である。
【図16】フロー情報の記述例を示す図である。
【図17】フロー登録処理を示すフローチャートである。
【図18】ルール検査処理を示すフローチャートである。
【図19】ワークフローの実行手順の例を示す第1のシーケンス図である。
【図20】ワークフローの実行手順の例を示す第2のシーケンス図である。
【図21】ワークフローの実行手順の例を示す第3のシーケンス図である。
【発明を実施するための形態】
【0013】
以下、本実施の形態を図面を参照して説明する。
[第1の実施の形態]
図1は、第1の実施の形態の情報処理装置を示す図である。第1の実施の形態の情報処理装置10は、装置21〜23から取得される複数の項目の情報に基づいて、装置21〜23を監視する情報処理システムに用いられる。当該情報処理システムは、ワークフロー定義に従って自動的にソフトウェアの更新などの処理を行っている間、異常の有無を監視して、異常があれば処理を停止させるものであってもよい。装置21〜23は、例えば、サーバ装置、通信装置、ストレージ装置などの電子機器である。
【0014】
情報処理装置10は、検査部12を有する。検査部12は、CPU(Central Processing Unit)およびRAM(Random Access Memory)を用いて実行されるプログラムとして実装してもよい。検査部12は、記憶部11に記憶された検査情報11aが示す検査対象の項目の情報を検査する。検査情報11aは、検査対象の項目毎に、正常(または異常)と判断する基準(判断ルール)を示す情報を含んでいてもよい。記憶部11は、情報処理装置10が備えていてもよいし、他の情報処理装置が備える記憶装置でもよい。
【0015】
検査情報11aにおいて、装置21〜23から情報を取得可能な複数の項目のうち、検査対象の項目として、項目#1,#2,#3が指定されているとする。項目#3は、取得される情報が、項目#1の情報と項目#2の情報の両方と関連する。例えば、項目#3の情報は、項目#1が示す装置状態と項目#2が示す装置状態の両方から影響を受けるものである場合が考えられる。この場合、項目#1の情報と項目#2の情報の少なくとも一方が異常を示していれば、項目#3の情報も異常を示すことが想定される。
【0016】
検査部12は、装置21〜23から取得された項目#3の情報を検査する。項目#3の情報の検査で異常が検査されない場合、検査部12は、項目#1,#2の情報の検査を省略する。一方、項目#3の情報の検査で異常が検出された場合、検査部12は、装置21〜23から取得された項目#1,#2の情報を更に検査する。なお、検査部12は、項目#3の情報が更新されたときに、項目#3の情報を検査するようにしてもよい。項目#3の情報が更新されたか否かは、装置21〜23から情報を収集するデータベース装置に監視させてもよい。また、項目#1,#2の情報は、項目#3の情報の検査で異常が検出された後に、装置21〜23から取得するようにしてもよい。
【0017】
また、情報処理装置10または他の情報処理装置は、検査対象の項目として項目#1,#2が指定されたときに、自動的に項目#3を検査対象に追加するようにしてもよい。例えば、複数の項目の間の関係(例えば、一の項目の情報が他の項目の情報に影響を与える関係)を示す関係情報を記憶した記憶装置を参照して、項目#1,#2の両方と関連する項目#3を検索することが考えられる。情報処理装置10または他の情報処理装置は、検索された項目#3を、優先的に検査を行う項目に指定すればよい。検査情報11aは、項目#1〜#3と対応付けて、検査の優先度を示す情報を含んでいてもよい。
【0018】
第1の実施の形態の情報処理装置10によれば、項目#1、項目#2、および、取得される情報が項目#1,#2の情報と関連する項目#3のうち、項目#3の情報が検査される。項目#3の情報の検査で異常が検出されなかった場合、項目#1,#2の情報の検査が省略される。項目#3の情報の検査で異常が検出された場合、項目#1,#2の情報がそれぞれ検査される。これにより、装置21〜23に異常がなければ、項目#1,#2の情報の検査を省略でき、継続的に検査対象とする項目を絞り込むことができ、複数の項目の情報を用いた監視の負荷を軽減できる。
【0019】
[第2の実施の形態]
図2は、第2の実施の形態の情報処理システムを示す図である。第2の実施の形態の情報処理システムは、ワークフロー定義に従って、修正プログラムの適用などの運用管理をシステムリソース40に対して実行する。運用管理の自動化は、RBA(Runbook Automation)と呼ばれることがある。この情報処理システムは、端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400および構成管理データベース(CMDB:Configuration Management Database)サーバ500を含む。情報処理システムの各装置は、ネットワーク50に接続されている。この情報処理システムは、例えば、データセンター内に設置することができる。
【0020】
システムリソース40は、情報処理で利用される各種の電子機器を含む。例えば、システムリソース40は、サーバ装置41、スイッチなどの通信装置42およびストレージ装置43を含む。サーバ装置41は、CPU、RAM、HDDなどのリソースを用いて、アプリケーションソフトウェアを実行する。通信装置42は、装置間(例えば、サーバ装置41とストレージ装置43の間)でデータを転送する。ストレージ装置43は、情報処理に使用されるデータを、HDDなどの不揮発性の記憶装置に保存する。
【0021】
端末装置100は、ユーザ(例えば、情報処理システムの管理者)が操作するコンピュータである。端末装置100は、ユーザの操作に基づいて、システムリソース40の運用管理のワークフローを示すフロー情報を生成し、フローコントローラ200に送信する。また、ワークフローの実行中にシステムリソース40に異常がないか検査するためのルールを示すルール情報を生成し、フローコントローラ200に送信する。また、端末装置100は、ルール違反が発生したときの対処方法(リアクション)を示すリアクション情報を生成し、フローコントローラ200に登録しておく。
【0022】
フローコントローラ200は、ワークフローの実行を制御するコンピュータである。フローコントローラ200は、フロー情報をフローエンジン300に登録し、ワークフロー情報で定義された処理をフローエンジン300に実行させる。また、ルール情報をルールエンジン400に登録し、ルール違反が発生していないかルールエンジン400に検査させる。ルール違反が検出された場合、リアクション情報で定義された処理をフローエンジン300に実行させて、ワークフローを停止させる。フローコントローラ200は、ワークフローの実行結果を、端末装置100に報告する。
【0023】
フローエンジン300は、フローコントローラ200からの指示に応じて、ワークフロー情報で定義された処理をシステムリソース40に対して実行するコンピュータである。例えば、フローエンジン300は、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース40の装置に対して送信する。
【0024】
ルールエンジン400は、フローエンジン300がワークフローを実行している間、ルール違反がないか(システムリソース40に異常がないか)を検査するコンピュータである。ルールエンジン400は、CMDBサーバ500からシステムリソース40の構成情報を取得し、構成情報とルール情報とを照合してルール検査を行う。ルール違反が検出された場合、フローコントローラ200にルール違反を報告する。
【0025】
CMDBサーバ500は、システムリソース40から構成情報を収集するデータベースサーバとしてのコンピュータである。構成情報は、システムリソース40の各装置が備えるハードウェア、各装置で実行されているソフトウェア、ハードウェアやソフトウェアの状態などを示す情報を含む。CMDBサーバ500が各装置に定期的にアクセスすることで構成情報を収集してもよいし、各装置が定期または不定期(例えば、構成情報が更新されたとき)にCMDBサーバ500に構成情報を送信するようにしてもよい。CMDBサーバ500は、ルール検査に用いられる構成情報をルールエンジン400に提供する。CMDBサーバ500は、ルール検査に用いられない構成情報を収集しなくてもよい。
【0026】
なお、端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500のうちの複数のコンピュータの機能を、1台のコンピュータにまとめることも可能である。例えば、フローコントローラ200、フローエンジン300およびルールエンジン400を、1台のコンピュータにまとめてもよい。
【0027】
図3は、端末装置のハードウェア例を示すブロック図である。端末装置100は、CPU101、RAM102、HDD103、画像信号処理部104、入力信号処理部105、ディスクドライブ106および通信部107を有する。上記ユニットは、端末装置100内でバスに接続されている。なお、サーバ装置41などのシステムリソース40の装置、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500も、端末装置100と同様のハードウェアにより実現できる。
【0028】
CPU101は、端末装置100における情報処理を制御する演算装置である。CPU101は、HDD103に記憶されたプログラムやデータの少なくとも一部を読み出し、RAM102に展開してプログラムを実行する。なお、端末装置100は、複数の演算装置を備えて、情報処理を分散して実行してもよい。
【0029】
RAM102は、CPU101が扱うプログラムやデータを一時的に記憶しておく揮発性メモリである。なお、端末装置100は、RAM以外の種類のメモリを備えていてもよく、複数個のメモリを備えていてもよい。
【0030】
HDD103は、OSプログラムやアプリケーションプログラムなどのプログラム、および、情報処理に用いられるデータを記憶する不揮発性の記憶装置である。HDD103は、CPU101の命令に従って、内蔵の磁気ディスクに対する読み書きを行う。なお、端末装置100は、HDD以外の種類の不揮発性の記憶装置(例えば、SSD(Solid State Drive))を備えていてもよく、複数の記憶装置を備えていてもよい。
【0031】
画像信号処理部104は、CPU101の命令に従って、端末装置100に接続されたディスプレイ31に画像を出力する。ディスプレイ31として、例えば、CRT(Cathode Ray Tube)ディスプレイや液晶ディスプレイなどを用いることができる。
【0032】
入力信号処理部105は、端末装置100に接続された入力デバイス32から入力信号を取得し、CPU101に出力する。入力デバイス32として、例えば、マウスやタッチパネルなどのポインティングデバイスや、キーボードなどを用いることができる。
【0033】
ディスクドライブ106は、記録媒体33に記録されたプログラムやデータを読み取る駆動装置である。記録媒体33として、例えば、フレキシブルディスク(FD:Flexible Disk)やHDDなどの磁気ディスク、CD(Compact Disc)やDVD(Digital Versatile Disc)などの光ディスク、光磁気ディスク(MO:Magneto-Optical disk)を使用できる。ディスクドライブ106は、例えば、CPU101の命令に従って、記録媒体33から読み取ったプログラムやデータをRAM102またはHDD103に格納する。
【0034】
通信部107は、ネットワーク50に接続して通信を行う通信インタフェースである。ネットワーク50への接続方法は、有線でも無線でもよい。すなわち、通信部107は、有線通信インタフェースでも無線通信インタフェースでもよい。
【0035】
図4は、情報処理システムのソフトウェア例を示すブロック図である。各ブロックは、例えば、CPUとRAMを用いて実行されるプログラムのモジュールとして実装できる。
端末装置100は、構成情報取得部110、ルール編集部120およびフロー編集部130を有する。フローコントローラ200は、リアクション情報記憶部210とフロー制御部220とを有する。フローエンジン300は、フロー情報記憶部310とフロー実行部320とを有する。ルールエンジン400は、ルール情報記憶部410、ルール変換部420およびルール検査部430を有する。CMDBサーバ500は、構成情報記憶部510、関係情報記憶部520、構成情報収集部530および更新監視部540を有する。
【0036】
構成情報取得部110は、CMDBサーバ500から構成情報を取得する。
ルール編集部120は、構成情報取得部110が取得した構成情報に基づいて、ルールを編集するための画面をディスプレイに表示する。そして、画面に対するユーザの入力からルール情報を生成し、フローコントローラ200に送信する。また、ルール編集部120は、リアクションを編集するための画面をディスプレイに表示し、ユーザの入力からリアクション情報を生成してフローコントローラ200に送信する。
【0037】
フロー編集部130は、ワークフローを編集するための画面をディスプレイに表示し、ユーザの入力からフロー情報を生成してフローコントローラ200に送信する。
リアクション情報記憶部210は、リアクション情報を記憶する。
【0038】
フロー制御部220は、端末装置100からルール情報を受信し、ルールエンジン400に転送する。また、端末装置100からリアクション情報を受信し、リアクション情報記憶部210に格納する。また、端末装置100からフロー情報を受信し、ワークフローの実行中にルール違反が検出されたときリアクション情報の示すリアクションが実行されるよう、フロー情報を修正する。そして、修正したフロー情報をフローエンジン300に送信する。また、フロー制御部220は、ワークフローの実行中、ルール検査をルールエンジン400に指示し、検査結果に基づいてワークフローの続行や停止をフローエンジン300に指示する。また、ワークフローの実行結果を端末装置100に報告する。
【0039】
フロー情報記憶部310は、フロー情報を記憶する。
フロー実行部320は、フローコントローラ200からフロー情報を受信し、フロー情報記憶部310に格納する。また、フロー実行部320は、フローコントローラ200からの指示に基づいて、フロー情報記憶部310に記憶されたフロー情報が示す1またはそれ以上のステップの処理(タスク)を実行する。例えば、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース40に対して送信する。フロー実行部320は、タスクの実行のためにCMDBサーバ500が保持する構成情報を参照することがあり、タスクの実行結果に基づいて構成情報を更新することがある。
【0040】
ルール情報記憶部410は、ルール情報を記憶する。
ルール変換部420は、フローコントローラ200からルール情報を受信し、CMDBサーバ500が保持する構成情報や波及関係情報を参照してルール情報を修正し、修正したルール情報をルール情報記憶部410に格納する。構成情報の項目(CI:Configuration Item)に代えて項目の種別がルール情報に記載されている場合、ルール変換部420は、CMDBサーバ500から構成情報の少なくとも一部を取得し、項目の種別を実在する項目に展開する。また、複数のルールがルール情報に含まれる場合、CMDBサーバ500から波及関係情報を取得し、継続的に検査する項目(監視する項目)が少なくなるようにルールを変換する。波及関係およびルール変換の詳細は後述する。
【0041】
ルール検査部430は、フローコントローラ200からの指示を受けて、CMDBサーバ500から構成情報の少なくとも一部を取得し、構成情報がルール情報記憶部410に記憶されたルール情報のルールに違反していないか検査する。そして、検査結果をフローコントローラ200に報告する。また、ルール検査部430は、フローコントローラから自動検査の指示があると、構成情報の項目のうち監視する項目をCMDBサーバ500に登録する。そして、登録した項目の情報が更新された旨をCMDBサーバ500から通知されると、当該項目の情報をCMDBサーバ500から取得して検査する。
【0042】
構成情報記憶部510は、システムリソース40から収集された構成情報を記憶する。
関係情報記憶部520は、構成情報の項目の間の波及関係を示す波及関係情報を記憶する。波及関係は、HDDの項目で異常が検出されるときは当該HDDを備えるサーバ装置の項目でも異常が検出されるといった、異常が項目間で波及する関係を含む。
【0043】
構成情報収集部530は、システムリソース40から構成情報を収集し、構成情報記憶部510に格納する。また、構成情報収集部530は、端末装置100、フローエンジン300およびルールエンジン400からの要求に応じて、構成情報記憶部510に記憶された構成情報の少なくとも一部を要求元に送信する。なお、構成情報収集部530は、ルールエンジン400が監視する項目以外の項目の情報を、継続的に収集しなくてもよい。その場合、構成情報収集部530は、収集していない項目の情報が要求されたとき、システムリソース40から当該項目の情報を収集して、要求元に送信する。
【0044】
更新監視部540は、ルールエンジン400からの要求に応じて、関係情報記憶部520に記憶された波及関係情報をルールエンジン400に送信する。また、更新監視部540は、ルールエンジン400から監視する項目が通知されると、少なくとも通知された項目の情報を収集するよう、構成情報収集部530に指示する。そして、構成情報記憶部510に記憶された当該項目の情報を監視し、情報が更新されたことを検出すると、構成情報の更新が検出された旨をルールエンジン400に通知する。
【0045】
図5は、構成情報の項目例を示す図である。図5の構成情報の例は、種別がサービスである1つの項目(serviceA)と、種別がサーバである2つの項目(svr1,svr2)と、種別がアプリケーションである2つの項目(app1,app2)を含む。また、種別がCPUである4つの項目(svr1_c1,svr1_c2,svr2_c1,svr2_c2)と、種別がメモリである2つの項目(svr1_m1,svr2_m1)と、種別がHDDである2つの項目(svr1_h1,svr2_h1)を含む。
【0046】
serviceAは、2つのサーバ(svr1,svr2)によって提供される。svr1は、2つのCPU(svr1_c1,svr1_c2)と1つのメモリ(svr1_m1)と1つHDD(svr1_h1)を備える。svr2は、同様に、2つのCPU(svr2_c1,svr2_c2)と1つのメモリ(svr2_m1)と1つHDD(svr2_h1)を備える。app1はsvr1上で実行され、app2はsvr2上で実行されている。例えば、app1はWebアプリケーションであり、app2はデータベース管理システム(DBMS:Database Management System)である。
【0047】
サービスの情報、サーバの情報、アプリケーションの情報、CPUの情報、メモリの情報およびHDDの情報は、それぞれ、状態(status)の情報を含む。アプリケーションの情報は、更に、キャッシュサイズの情報、設定ファイルのパスの情報、トランザクション数の情報を含むことがある。構成情報は、上記以外の情報を含んでもよい。
【0048】
図6は、構成情報の記述例を示す図である。図6に示す構成情報511は、図5に示した項目を、XML(Extensible Markup Language)によって記述したものである。構成情報511は、構成情報記憶部510に記憶される。構成情報511は、項目タグ(<item>)と関係タグ(<relationship>)を含む。
【0049】
項目タグは、構成情報の項目を示す。項目タグは、サーバタグ(<Server>)またはアプリケーションタグ(<Application>)を含む。サーバタグは、CPUタグ(<Cpu>)、メモリタグ(<Memory>)およびHDDタグ(<Hdd>)を含む。サーバタグ、アプリケーションタグ、CPUタグ、メモリタグおよびHDDタグは、それぞれ図5に示した何れかの項目に対応し、属性として状態(status)を示す値を含む。また、アプリケーションタグは、キャッシュサイズや設定ファイルのパスなどのパラメータを示すパラメータタグ(<param>)を含む。パラメータタグは、属性として当該パラメータの値を含む。
【0050】
関係タグは、項目タグが示す項目の間の関係を示す。関係タグは、属性として関係の種別(タイプ)を示す値を含む。また、関係タグは、ソース項目タグ(<sourceItem>)とターゲット項目タグ(<targetItem>)を含む。例えば、ソース項目がサービス、ターゲット項目がサーバ、タイプが“consistOf”である関係タグは、サービスがサーバを用いて実現される関係を示す。また、ソース項目がアプリケーション、ターゲット項目がサーバ、タイプが“installedOn”である関係タグは、アプリケーションがサーバ上で実行される関係を示す。
【0051】
図7は、異常の波及関係の例を示す図である。波及関係は、異常が構成情報の項目間で波及する関係であり、波及する方向をもつ。例えば、HDD故障およびメモリエラーは、それぞれサーバ故障の原因となる。設定エラーおよび高負荷は、アプリケーション異常の原因となる。サーバ故障およびアプリケーション異常は、サービス異常の原因となる。よって、構成情報において、HDDの項目の状態(status)がエラーを示すとき、サーバの項目の状態もエラーを示すことが想定される。また、サーバの項目の状態がエラーを示すとき、サービスの項目の状態もエラーを示すことが想定される。このように、上位の項目の状態は、下位の項目の状態の影響を受ける。
【0052】
図8は、波及関係テーブルの例を示す図である。図8の波及関係テーブルの例は、図7の波及関係に対応している。波及関係テーブル521は、関係情報記憶部520に記憶される。波及関係テーブル521は、ID、異常、親異常および条件の項目を含む。
【0053】
IDは、異常を識別するための識別情報である。異常の項目は、サービス異常などの異常の要因を示す。親異常は、当該異常から直接影響を受ける他の異常を示す。例えば、HDD故障の親異常はサーバ故障であり、サーバ故障の親異常はサービス異常である。条件は、状態異常が生じているか否かを構成情報から判断するための式の雛形であり、項目の種別名(Serviceなど)を用いて記述される。図8の例では、異常でないとき(正常のとき)に真となる論理式の雛形を条件として記述しているが、異常であるときに真となる論理式の雛形を記述してもよい。なお、図8において、[ATTR]は任意のパラメータ名を示し、[OP]は任意の演算子を示し、[VAL]は任意の固定値を示す。
【0054】
図9は、ルール定義テーブルの例を示す図である。ルール定義テーブル411は、ルール変換部420によって生成され、ルール情報記憶部410に記憶される。ルール定義テーブル411は、ID、ルールおよび親ルールの項目を含む。
【0055】
IDは、ルールを識別するための識別情報である。ルールは、異常が生じているか否かを構成情報から判断するための式として記述され、項目名(serviceAなど)を用いて記述される。図9の例では、異常でないとき(正常のとき)に真となる論理式をルールとして記述しているが、異常であるときに真となる論理式を記述してもよい。親ルールは、当該ルールに基づいて異常が検出された(ルール違反が生じた)ときに、同様にルール違反が生じると考えられる他のルールを示す。
【0056】
例えば、図9の例では、ルールR1,R2の親ルールはルールR4である。ルールR1,R2の少なくとも一方の違反が生じると、ルールR4の違反も生じると考えられる。一方、ルールR4の違反が生じていない場合、ルールR1,R2の違反も生じていないと考えられ、ルールR1,R2の検査は省略できる。なお、後述するように、端末装置100のユーザは、ルールR1,R2,R3を定義すればよい。ルールR4は、ルールR1,R2に基づいて、ルール変換部420によって自動的に追加される。
【0057】
図10は、リアクション定義テーブルの例を示す図である。リアクション定義テーブル211は、リアクション情報記憶部210に記憶される。リアクション定義テーブル211は、ID、条件およびリアクションの項目を含む。
【0058】
IDは、リアクションを識別するための識別情報である。条件は、リアクションが実行されるときの条件を示す。例えば、“R1 OR R3”は、上記のルールR1,R3の少なくとも一方のルール違反が検出されたという条件を示す。また、“R2 AND R3”は、上記のルールR2,R3の両方のルール違反が検出されたという条件を示す。リアクションの項目は、リアクションの内容を示す。例えば、サービスの提供に用いるサーバ装置を追加する、サービスを停止させる、などのリアクションを定義しておく。
【0059】
次に、ルールを情報処理システムに登録する処理を説明する。
図11は、ルール登録処理を示すフローチャートである。以下、図11に示す処理をステップ番号に沿って説明する。
【0060】
(ステップS11)端末装置100の構成情報取得部110は、CMDBサーバ500にアクセスして構成情報511を取得する。
(ステップS12)端末装置100のルール編集部120は、ステップS11で取得された構成情報511に基づいて、実在する項目または項目の種別を選択してルールを入力できるようにするルール編集画面を生成し、ディスプレイに表示する。そして、ルール編集部120は、ユーザが入力したルールを示すルール情報を生成し、フローコントローラ200に送信する。フローコントローラ200のフロー制御部220は、端末装置100から受信したルール情報をルールエンジン400に転送する。
【0061】
(ステップS13)ルールエンジン400のルール変換部420は、フローコントローラ200から受信したルール情報に、項目の種別を用いて記述されたルールが含まれるか判断する。ルールに項目の種別が含まれているか否かは、CMDBサーバ500が有する構成情報511を参照して判断してもよい。含まれる場合、処理をステップS14に進める。含まれない場合、処理をステップS15に進める。
【0062】
(ステップS14)ルール変換部420は、CMDBサーバ500にアクセスして構成情報511を取得する。そして、ルール変換部420は、構成情報511に基づいて、ルール情報に含まれる項目の種別を実在する項目に展開する。
【0063】
(ステップS15)ルール変換部420は、CMDBサーバ500にアクセスして波及関係テーブル521を取得する。
(ステップS16)ルール変換部420は、ステップS12でフローコントローラ200から受信したルール情報に含まれるルールを1つ選択する。
【0064】
(ステップS17)ルール変換部420は、ステップS16で選択したルールが、ステップS15で取得した波及関係テーブル521に記載された何れかの条件に合致するか判断する。判断の際には、ルールに含まれる項目を種別に置換して、条件と比較する。項目から種別への置換は、構成情報511を参照し行ってもよい。合致する場合、処理をステップS18に進める。合致しない場合、処理をステップS20に進める。
【0065】
(ステップS18)ルール変換部420は、波及関係テーブル521で定義される木(図7に示したような木)の部分木を生成する。生成する部分木は、ステップS17で合致した条件に対応するノードとルートノードとの間の経路を含む。例えば、ステップS16で選択したルールがサーバ故障(S2)の条件に合致した場合、サービス異常(S1)に対応するノードとサーバ故障(S2)に対応するノードを含む部分木が生成される。
【0066】
(ステップS19)ルール変換部420は、構成情報511を参照して、ステップS18で生成した部分木の各ノードに対して項目を対応付ける。例えば、ステップS16で選択したルールがサーバの項目svr1を含む場合、サーバ故障(S2)のノードにサーバの項目svr1を対応付け、サービス異常(S1)のノードにサービスの項目serviceAを対応付ける。そして、処理をステップS21に進める。
【0067】
(ステップS20)ルール変換部420は、ステップS16で選択したルールを監視対象のルール(親ルールをもたないルール)に指定する。
(ステップS21)ルール変換部420は、ステップS16でルール情報に含まれる全てのルールを選択したか判断する。全てのルールを選択した場合、処理をステップS22に進める。未選択のルールがある場合、処理をステップS16に進める。
【0068】
図12は、ルール登録処理を示すフローチャート(続き)である。
(ステップS22)ルール変換部420は、生成された部分木の中に、異常要因と項目の両方が同じであるノードを含む2以上の部分木が存在するか検索し、検索された当該2以上の部分木を、1つの部分木にマージする。
【0069】
(ステップS23)ルール変換部420は、ステップS22でマージが行われた後の部分木の集合の中から、部分木を1つ選択する。
(ステップS24)ルール変換部420は、ステップS23で選択した部分木に分岐が存在するか(複数の葉ノードを含むか)判断する。分岐が存在する(複数の葉ノードを含む)場合、処理をステップS25に進める。分岐が存在しない(1つの葉ノードのみを含む)場合、処理をステップS27に進める。
【0070】
(ステップS25)ルール変換部420は、ステップS23で選択した部分木から、分岐元のノードのうち最上位に位置するもの(全ての葉ノードをカバーできるノードのうち最下位に位置するもの)を選択する。
【0071】
(ステップS26)ルール変換部420は、ステップS15で取得した波及関係テーブル521から、ステップS25で選択したノードに対応する条件を取得する。そして、条件に含まれる項目の種別を、選択したノードに対応付けられた項目に置換することで、上位のルールを生成する。ルール変換部420は、生成したルールを監視対象のルールに指定する。その後、処理をステップS28に進める。
【0072】
(ステップS27)ルール変換部420は、ステップS23で選択した部分木の葉ノードに対応するルール(フローコントローラ200から受信したルール情報に含まれていた元のルール)を、監視対象のルールに指定する。
【0073】
(ステップS28)ルール変換部420は、ステップS23で全ての部分木を選択したか判断する。全ての部分木を選択した場合、監視対象に指定したルールおよび元のルールを含むルール定義テーブル411をルール情報記憶部410に格納し、処理を終了する。未選択の部分木がある場合、処理をステップS23に進める。
【0074】
図13は、ルール編集画面の例を示す図である。端末装置100は、CMDBサーバ500が有する構成情報に基づいて、ルール作成を支援するためのルール編集画面121を生成する。ルール編集画面121は、例えば、ディスプレイ31に表示される。ルール編集画面121は、種別、項目、属性およびルールの欄を含む。
【0075】
種別の欄には、サーバやHDDなどの種別が記載される。項目の欄には、構成情報に含まれる実在の項目が種別毎に記載される。ユーザは、検査対象の種別または項目を選択することができる。種別を選択した場合、実在する当該種別の項目全てを選択したものとして取り扱われる。例えば、サーバを選択すると、サーバの項目svr1,svr2の両方を選択したものとして取り扱われる。属性の欄には、構成情報に含まれる属性が記載される。ルールの欄には、属性に対する式を入力することができる。ユーザは、選択した種別または項目に対応する1またはそれ以上の属性を指定して式を入力する。
【0076】
図14は、ルール変換の例を示す図である。図9に示したルールR1,R2が、端末装置100で生成されたルール情報に含まれているとする。
ルールエンジン400は、ルールR1から、サーバ故障のノードとサービス異常のノードを含む部分木を生成する。サーバ故障のノードには、項目svr1が対応付けられ、サービス異常のノードには、項目svr1と関連する項目serviceAが対応付けられる。また、ルールエンジン400は、ルールR2から、高負荷のノードとアプリケーション異常のノードとサービス異常のノードを含む部分木を生成する。高負荷のノードには、項目app2が対応付けられ、アプリケーション異常のノードには、項目app2が対応付けられ、サービス異常のノードには、項目serviceAが対応付けられる。
【0077】
ルールエンジン400は、上記2つの部分木の間で、ルートノードの異常要因(サービス異常)と項目(serviceA)が一致するため、上記2つの部分木をマージする。ルールエンジン400は、マージ後の部分木の中から、最上位の分岐ノードであるサービス異常のノードを選択する。そして、ルールエンジン400は、サービス異常のノードに対応するルールR4を生成し、ルールR4を継続的に検査するルールに指定する。この場合、元のルールR1,R2は、継続的に検査するルールに指定されない。
【0078】
次に、ワークフローを情報処理システムに登録する処理を説明する。
図15は、ワークフローの例を示す図である。フローコントローラ200は、端末装置100から受信したフロー情報を修正して、ワークフローの途中でルール検査が行われるようにする。そして、修正したフロー情報を、フローエンジン300に登録する。
【0079】
タスク1とタスク2を逐次的に実行するワークフローを示すフロー情報が、端末装置100で生成されたとする。フローコントローラ200は、最初の通常タスク(タスク1)の前に事前検査の検査タスクを挿入し、最後の通常タスク(タスク2)の後に事後検査の検査タスクを挿入する。また、通常タスクの間それぞれ(タスク1とタスク2の間)に、実行中検査の検査タスク(実行中検査1)を挿入する。また、各検査タスクの後に検査結果に応じた分岐を挿入し、ルール違反が検出された場合はワークフローを停止するための通常タスク(キャンセル)に遷移するように、タスク間の遷移を修正する。
【0080】
図16は、フロー情報の記述例を示す図である。図16に示すフロー情報311は、図15に示した修正後のワークフローを、XMLによって記述したものである。フロー情報311は、フローエンジン300のフロー情報記憶部310に記憶される。
【0081】
フロー情報311は、ワークフロー毎に、ワークフロー名の属性を有するタグ(<process>)を含む。また、フロー情報311は、検査タスク毎に、検査タスク名の属性を有するタグ(<receiveTask>)を含み、通常タスク毎に、通常タスク名の属性を有するタグ(<scriptTask>)を含む。また、フロー情報311は、分岐に対応するタグ(<exclusiveGateway>)と、タスク間の遷移またはタスクと分岐の間の遷移を示すタグ(<sequenceFlow>)を含む。
【0082】
図17は、フロー登録処理を示すフローチャートである。以下、図17に示す処理をステップ番号に沿って説明する。
(ステップS31)端末装置100のフロー編集部130は、ユーザからの入力に応じて、検査タスクを含まないワークフローを示すフロー情報を生成する。そして、フロー編集部130は、フロー情報をフローコントローラ200に送信する。
【0083】
(ステップS32)フローコントローラ200のフロー制御部220は、端末装置100から受信したフロー情報が示すワークフローに、事前検査の検査タスクおよび事後検査の検査タスクを追加する。
【0084】
(ステップS33)フロー制御部220は、フロー情報が示すワークフローについて、通常タスクの間に実行中検査の検査タスクを挿入する。
(ステップS34)フロー制御部220は、フロー情報が示すワークフローについて、検査タスクの後に分岐を挿入する。
【0085】
(ステップS35)フロー制御部220は、フロー情報が示すワークフローに、検査タスクでルール違反が検出された場合に実行される通常タスクを追加する。また、ステップS34で挿入した分岐から当該通常タスクへの遷移を追加する。
【0086】
(ステップS36)フロー制御部220は、修正したフロー情報をフローエンジン300に送信する。フローエンジン300のフロー実行部320は、フローコントローラ200から受信したフロー情報を、フロー情報記憶部310に格納する。
【0087】
次に、ワークフローの実行中に行われるルール検査の処理を説明する。
図18は、ルール検査処理を示すフローチャートである。以下、図18に示す処理をステップ番号に沿って説明する。
【0088】
(ステップS41)ルールエンジン400のルール検査部430は、ルール情報記憶部410に記憶されたルール定義テーブル411に登録されているルールから、監視対象のルール(親ルールをもたないルール)を選択する。
【0089】
(ステップS42)ルール検査部430は、ステップS41で選択したルールに現れる項目についての構成情報を、CMDBサーバ500から取得する。
(ステップS43)ルール検査部430は、ステップS42で取得した構成情報を用いてルールを評価し、不適合のルールがあるか(例えば、論理式が偽となるか)判断する。不適合のルールが少なくとも1つある場合、処理をステップS44に進める。不適合のルールがない場合、処理をステップS48に進める。
【0090】
(ステップS44)ルール検査部430は、ルール定義テーブル411を参照し、不適合のルールの下位のルール(不適合のルールを親ルールとしてもつ他のルール)があるか判断する。下位のルールが少なくとも1つの不適合のルールについて存在する場合、処理をステップS45に進める。下位のルールがない場合、処理をステップS47に進める。
【0091】
(ステップS45)ルール検査部430は、ルール定義テーブル411に登録されているルールから、不適合のルールの下位のルールを選択する。
(ステップS46)ルール検査部430は、ステップS45で選択したルールに現れる項目についての構成情報を、CMDBサーバ500に要求する。CMDBサーバ500の構成情報収集部530は要求された構成情報を、システムリソース40から収集して、ルールエンジン400に送信する。なお、構成情報収集部530は、要求された構成情報が収集対象となっている場合は、構成情報記憶部510に記憶された構成情報を送信する。ルール検査部430は、取得した構成情報を用いてルールを評価する。
【0092】
(ステップS47)ルール検査部430は、ルール違反があると判定し、違反が検出されたルールを特定する。そして、ルール検査部430は、違反が検出されたルールをフローコントローラ200に報告する。その後、処理を終了する。
【0093】
(ステップS48)ルール検査部430は、ルール違反がないと判定する。ルール検査部430は、フローコントローラ200からの指示に基づいてルール検査を開始した場合には、ルール違反がないことをフローコントローラ200に報告する。
【0094】
例えば、図9に示したルール定義テーブル411がルール情報記憶部410に記憶されている場合、ルール検査部430は、ルールR3,R4に基づいて項目serviceAを検査する。ルールR3の違反が検出された場合、下位のルールが存在しないため、ルールR3単独の違反と判定する。一方、ルールR4の違反が検出された場合、ルール検査部430は、下位のルールR1,R2に基づいて項目svr1と項目app2を検査する。そして、違反が検出されたルールを、下位のルールも含めて特定する。
【0095】
次に、ワークフローの実行制御の流れを説明する。
図19は、ワークフローの実行手順の例を示す第1のシーケンス図である。図19において、ステップS51〜S56は、ワークフローを開始する際に行われる。ステップS57〜S61は、ワークフローで定義された検査タスクを実行する際に行われる。
【0096】
(ステップS51)端末装置100は、ルール情報およびフロー情報を生成し、フローコントローラ200に送信する。
(ステップS52)フローコントローラ200は、端末装置100から受信したフロー情報を修正して、ルール検査が行われるようにワークフローを変換する。ワークフローの変換の際には、登録されているリアクション情報を参照してもよい。
【0097】
(ステップS53)フローコントローラ200は、ステップS52で修正したフロー情報を、フローエンジン300に送信する。フローエンジン300は、端末装置100から受信したフロー情報を保存する。
【0098】
(ステップS54)フローコントローラ200は、端末装置100から受信したルール情報をルールエンジン400に転送する。
(ステップS55)ルールエンジン400は、フローコントローラ200から受信したルール情報に記載されている項目の種別を項目に展開する。また、監視対象のルール(継続的に検査するルール)が少なくなるように、ルールをルール情報に追加する。その際、フローコントローラ200は、CMDBサーバ500がもつ構成情報や波及関係情報を参照する。そして、修正したフロー情報を保存する。
【0099】
(ステップS56)フローコントローラ200は、フロー情報およびルール情報の登録が完了したことを確認し、ワークフローの開始をフローエンジン300に指示する。フローコントローラ200は、フロー情報に記載されたタスクを逐次的に実行する。
【0100】
(ステップS57)フローエンジン300は、次に実行するタスクが検査タスク(事前検査、実行中検査または事後検査のタスク)である場合、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
【0101】
(ステップS58)フローコントローラ200は、ルールエンジン400に、ルール情報に基づく構成情報の検査を指示する。
(ステップS59)ルールエンジン400は、CMDBサーバ500から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。
【0102】
(ステップS60)ルールエンジン400は、ステップS59の検査結果をフローコントローラ200に報告する。ルール違反が検出された場合には、違反と判定されたルールの識別情報も、フローコントローラ200に報告する。
【0103】
(ステップS61)フローコントローラ200は、ルールエンジン400から報告された検査結果に基づいて、フローエンジン300に次動作を指示する。次動作の指示の際には、登録されているリアクション情報を参照してもよい。例えば、フローコントローラ200は、ルール違反が検出されなかったときは“NEXT”(フロー継続)を指示し、ルール違反が検出されたときは“CANCEL”(フロー終了)を指示する。フローエンジン300は、中断しているワークフローを再開し、フローコントローラ200からの指示に応じて、フロー情報に記載された分岐の方向を判断する。
【0104】
図20は、ワークフローの実行手順の例を示す第2のシーケンス図である。図20において、ステップS62〜S65は、検査タスクが実行されるタイミング以外のタイミングでもルール検査を適宜行えるようにする処理であり、事前検査の直後に行われる。ステップS66〜S69は、通常タスクを実行する際に行われる。
【0105】
(ステップS62)フローエンジン300は、事前検査の検査タスクが終了した後に、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
(ステップS63)フローコントローラ200は、ルールエンジン400に、自動的にルール検査が行われるようにする設定を指示する。
【0106】
(ステップS64)ルールエンジン400は、ルール情報から、監視対象のルールに現れる項目を抽出し、CMDBサーバ500に通知する。CMDBサーバ500は、ルールエンジン400からから通知された項目を、監視する項目として登録する。
【0107】
(ステップS65)フローコントローラ200は、監視する項目の登録が完了したことを確認し、フローエンジン300に次動作の指示としてフロー継続を指示する。フローエンジン300は、中断しているワークフローを再開する。
【0108】
(ステップS66)フローコントローラ200は、次に実行するタスクが通常タスクである場合、フロー情報で定義される処理を実行する。フロー情報で定義される処理としては、例えば、システムリソース40の装置への停止コマンドの送信、修正プログラムをインストールさせるコマンドの送信、再起動コマンドの送信などが考えられる。フローコントローラ200は、通常タスクの実行の際に、CMDBサーバ500がもつ構成情報を参照することがあり、構成情報を更新することもある。
【0109】
(ステップS67)CMDBサーバ500は、ステップS64で登録された項目についての構成情報が変更されているか否かを監視する。CMDBサーバ500がもつ構成情報は、フローコントローラ200によって変更されることがあり、また、システムリソース40から収集した情報によって変更されることがある。CMDBサーバ500は、構成情報の変更を検出すると、ルールエンジン400に変更を通知する。
【0110】
(ステップS68)ルールエンジン400は、ルールエンジン400は、CMDBサーバ500から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。
【0111】
(ステップS69)ルールエンジン400は、ステップS68ルール違反を検出した場合、ルール違反が検出された旨および違反と判定されたルールの識別情報を、フローコントローラ200に報告する。ルール違反を検出しなかった場合は、フローコントローラ200にその旨を報告しなくてもよい。フローコントローラ200は、例えば、次にワークフローが中断されたタイミングで、フローエンジン300にフロー終了を指示する。
【0112】
図21は、ワークフローの実行手順の例を示す第3のシーケンス図である。図21において、ステップS70〜S73は、自動検査の設定を解除する処理であり、事後検査の直前に行われる。ステップS74〜S77は、ワークフローを開始する際に行われる。
【0113】
(ステップS70)フローエンジン300は、事後検査の検査タスクを実行する前に、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
(ステップS71)フローコントローラ200は、ルールエンジン400に、自動的にルール検査が行われるようにする設定の解除を指示する。
【0114】
(ステップS72)ルールエンジン400は、ルール情報から、監視対象のルールに現れる項目を抽出し、CMDBサーバ500に通知する。CMDBサーバ500は、ルールエンジン400から通知された項目の登録を抹消する。
【0115】
(ステップS73)フローコントローラ200は、監視する項目の抹消が完了したことを確認し、フローエンジン300に次動作の指示としてフロー継続を指示する。フローエンジン300は、中断しているワークフローを再開する。
【0116】
(ステップS74)フローエンジン300は、ワークフローが終了する(例えば、事後検査のタスクが終了する)と、終了したことをフローコントローラ200に通知する。ワークフローの終了には、正常終了と異常終了とが含まれる。
【0117】
(ステップS75)フローコントローラ200は、ルール情報の削除をルールエンジン400に指示する。ルールエンジン400は、ルール情報を削除する。
(ステップS76)フローコントローラ200は、フロー情報の削除をフローエンジン300に指示する。フローエンジン300は、フロー情報を削除する。
【0118】
(ステップS77)フローコントローラ200は、ワークフローの実行結果として正常終了または異常終了を、端末装置100に報告する。
第2の実施の形態の情報処理システムによれば、項目間の波及関係を考慮して複数のルールを統合し、統合したルールについて継続的に検査することで、ルール検査の回数を削減でき、検査の負荷を軽減することができる。また、上位のルールで違反が検出されたときに、下位の複数のルールについて検査を行うことで、異常原因を把握することが可能となる。また、下位のルールに対応する構成情報を継続的に収集しないようにすることで、構成情報を収集する負荷も軽減することができる。
【0119】
また、監視する項目をCMDBサーバ500に登録しておき、登録した項目の情報が変更されたことを契機として検査を行うことで、ルール検査を効率化することができる。また、CMDBサーバ500がもつ構成情報を参照して、実在する項目を指定してルールを記述できるようにするルール編集画面をユーザに提供することで、実在しない項目を指定した不適切なルールが記述されることを防止できる。また、ユーザが項目の種別を指定してルールを記述できるようにすることで、ルールの記述漏れを抑制できる。
【0120】
なお、前述のように、第2の実施の形態のワークフロー制御およびルール検査は、コンピュータとしての端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500に、それぞれプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体(例えば、記録媒体33)に記録しておくことができる。記録媒体として、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、FDおよびHDDが含まれる。光ディスクには、CD、CD−R(Recordable)/RW(Rewritable)、DVDおよびDVD−R/RWが含まれる。
【0121】
プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。また、プログラムを他のコンピュータの記憶装置に格納しておき、ネットワーク50経由でプログラムを配布することもできる。コンピュータは、例えば、可搬記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを記憶装置(例えば、HDD103)に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよく、他のコンピュータからネットワーク50を介して受信したプログラムを直接実行してもよい。
【符号の説明】
【0122】
10 情報処理装置
11 記憶部
11a 検査情報
12 検査部
21〜23 装置
【技術分野】
【0001】
本発明は、1またはそれ以上の装置を監視する監視方法、情報処理装置および監視プログラムに関する。
【背景技術】
【0002】
情報処理システムを運用する場合、サーバ装置、ストレージ装置、通信装置などの装置に異常がないか、システム管理者が確認し、異常があれば対応措置を行うことがある。例えば、ハードウェアの故障が発見されたときは、装置を停止させてハードウェアを交換することがある。また、ソフトウェアの実行状態の異常が発見されたときは、ソフトウェアのプロセスを停止させて、異常原因を調査することがある。また、装置の過剰負荷が発見されたときは、情報処理のためのリソースを追加することがある。
【0003】
一方で、情報処理システムの有する装置が多数になると、システム管理者の監視作業の負担が大きくなる。そこで、運用管理用の情報処理装置が、監視対象の装置から情報を収集し、収集した情報を検査することで、装置の異常な状態(または、異常の兆候)を自動的に検出することが考えられる。異常を検出した情報処理装置は、システム管理者に対する警告を発行することもできるし、予め定義された処理手順に従って対応措置を行う(例えば、異常な状態の装置に対して停止命令を送信する)こともできる。
【0004】
なお、予め定義されたワークフローに従って自律的に計算機の運用管理を行う運用管理システムにおいて、管理対象の計算機から情報を収集し、収集した情報と停止判断ルールとを照合して、自立制御を継続するか停止するか判断する方法が提案されている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2007−4337号公報(段落[0028],[0030])
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかし、情報を収集して検査すべき項目が増えると、監視の負荷が増大するという問題がある。例えば、サーバ装置毎に、HDD(Hard Disk Drive)の状態、メモリの状態、当該サーバ装置が実行しているトランザクションの数など、具体的な項目の情報を継続的に検査すると、検査を行う情報処理装置の負荷が増大する。
【0007】
一側面では、本発明は、複数の項目の情報を用いた監視の負荷を軽減できる監視方法、情報処理装置および監視プログラムを提供することを目的とする。
【課題を解決するための手段】
【0008】
一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視する情報処理システムが行う監視方法が提供される。第1の項目、第2の項目、および、取得される情報が第1および第2の項目の情報と関連する第3の項目のうち、第3の項目の情報を検査する。第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略する。第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報をそれぞれ検査する。
【0009】
また、一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視する情報処理装置が提供される。情報処理装置は、記憶部と検査部とを有する。記憶部は、検査対象として、第1の項目と、第2の項目と、取得される情報が第1および第2の項目の情報と関連する第3の項目とを示す検査情報を記憶する。検査部は、検査情報が示す検査対象の項目の情報を検査する。検査部は、第3の項目の情報を検査し、第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略し、第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報を検査する。
【0010】
また、一実施態様では、1またはそれ以上の装置から取得される複数の項目の情報に基づいて、1またはそれ以上の装置を監視するための監視プログラムが提供される。監視プログラムは、コンピュータに以下の処理を実行させる。第1の項目、第2の項目、および、取得される情報が第1および第2の項目の情報と関連する第3の項目のうち、第3の項目の情報を検査する。第3の項目の情報の検査で異常が検出されなかった場合、第1および第2の項目の情報の検査を省略する。第3の項目の情報の検査で異常が検出された場合、第1および第2の項目の情報をそれぞれ検査する。
【発明の効果】
【0011】
一実施態様によれば、複数の項目の情報を用いた監視の負荷を軽減できる。
【図面の簡単な説明】
【0012】
【図1】第1の実施の形態の情報処理装置を示す図である。
【図2】第2の実施の形態の情報処理システムを示す図である。
【図3】端末装置のハードウェア例を示すブロック図である。
【図4】情報処理システムのソフトウェア例を示すブロック図である。
【図5】構成情報の項目例を示す図である。
【図6】構成情報の記述例を示す図である。
【図7】異常の波及関係の例を示す図である。
【図8】波及関係テーブルの例を示す図である。
【図9】ルール定義テーブルの例を示す図である。
【図10】リアクション定義テーブルの例を示す図である。
【図11】ルール登録処理を示すフローチャートである。
【図12】ルール登録処理を示すフローチャート(続き)である。
【図13】ルール編集画面の例を示す図である。
【図14】ルール変換の例を示す図である。
【図15】ワークフローの例を示す図である。
【図16】フロー情報の記述例を示す図である。
【図17】フロー登録処理を示すフローチャートである。
【図18】ルール検査処理を示すフローチャートである。
【図19】ワークフローの実行手順の例を示す第1のシーケンス図である。
【図20】ワークフローの実行手順の例を示す第2のシーケンス図である。
【図21】ワークフローの実行手順の例を示す第3のシーケンス図である。
【発明を実施するための形態】
【0013】
以下、本実施の形態を図面を参照して説明する。
[第1の実施の形態]
図1は、第1の実施の形態の情報処理装置を示す図である。第1の実施の形態の情報処理装置10は、装置21〜23から取得される複数の項目の情報に基づいて、装置21〜23を監視する情報処理システムに用いられる。当該情報処理システムは、ワークフロー定義に従って自動的にソフトウェアの更新などの処理を行っている間、異常の有無を監視して、異常があれば処理を停止させるものであってもよい。装置21〜23は、例えば、サーバ装置、通信装置、ストレージ装置などの電子機器である。
【0014】
情報処理装置10は、検査部12を有する。検査部12は、CPU(Central Processing Unit)およびRAM(Random Access Memory)を用いて実行されるプログラムとして実装してもよい。検査部12は、記憶部11に記憶された検査情報11aが示す検査対象の項目の情報を検査する。検査情報11aは、検査対象の項目毎に、正常(または異常)と判断する基準(判断ルール)を示す情報を含んでいてもよい。記憶部11は、情報処理装置10が備えていてもよいし、他の情報処理装置が備える記憶装置でもよい。
【0015】
検査情報11aにおいて、装置21〜23から情報を取得可能な複数の項目のうち、検査対象の項目として、項目#1,#2,#3が指定されているとする。項目#3は、取得される情報が、項目#1の情報と項目#2の情報の両方と関連する。例えば、項目#3の情報は、項目#1が示す装置状態と項目#2が示す装置状態の両方から影響を受けるものである場合が考えられる。この場合、項目#1の情報と項目#2の情報の少なくとも一方が異常を示していれば、項目#3の情報も異常を示すことが想定される。
【0016】
検査部12は、装置21〜23から取得された項目#3の情報を検査する。項目#3の情報の検査で異常が検査されない場合、検査部12は、項目#1,#2の情報の検査を省略する。一方、項目#3の情報の検査で異常が検出された場合、検査部12は、装置21〜23から取得された項目#1,#2の情報を更に検査する。なお、検査部12は、項目#3の情報が更新されたときに、項目#3の情報を検査するようにしてもよい。項目#3の情報が更新されたか否かは、装置21〜23から情報を収集するデータベース装置に監視させてもよい。また、項目#1,#2の情報は、項目#3の情報の検査で異常が検出された後に、装置21〜23から取得するようにしてもよい。
【0017】
また、情報処理装置10または他の情報処理装置は、検査対象の項目として項目#1,#2が指定されたときに、自動的に項目#3を検査対象に追加するようにしてもよい。例えば、複数の項目の間の関係(例えば、一の項目の情報が他の項目の情報に影響を与える関係)を示す関係情報を記憶した記憶装置を参照して、項目#1,#2の両方と関連する項目#3を検索することが考えられる。情報処理装置10または他の情報処理装置は、検索された項目#3を、優先的に検査を行う項目に指定すればよい。検査情報11aは、項目#1〜#3と対応付けて、検査の優先度を示す情報を含んでいてもよい。
【0018】
第1の実施の形態の情報処理装置10によれば、項目#1、項目#2、および、取得される情報が項目#1,#2の情報と関連する項目#3のうち、項目#3の情報が検査される。項目#3の情報の検査で異常が検出されなかった場合、項目#1,#2の情報の検査が省略される。項目#3の情報の検査で異常が検出された場合、項目#1,#2の情報がそれぞれ検査される。これにより、装置21〜23に異常がなければ、項目#1,#2の情報の検査を省略でき、継続的に検査対象とする項目を絞り込むことができ、複数の項目の情報を用いた監視の負荷を軽減できる。
【0019】
[第2の実施の形態]
図2は、第2の実施の形態の情報処理システムを示す図である。第2の実施の形態の情報処理システムは、ワークフロー定義に従って、修正プログラムの適用などの運用管理をシステムリソース40に対して実行する。運用管理の自動化は、RBA(Runbook Automation)と呼ばれることがある。この情報処理システムは、端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400および構成管理データベース(CMDB:Configuration Management Database)サーバ500を含む。情報処理システムの各装置は、ネットワーク50に接続されている。この情報処理システムは、例えば、データセンター内に設置することができる。
【0020】
システムリソース40は、情報処理で利用される各種の電子機器を含む。例えば、システムリソース40は、サーバ装置41、スイッチなどの通信装置42およびストレージ装置43を含む。サーバ装置41は、CPU、RAM、HDDなどのリソースを用いて、アプリケーションソフトウェアを実行する。通信装置42は、装置間(例えば、サーバ装置41とストレージ装置43の間)でデータを転送する。ストレージ装置43は、情報処理に使用されるデータを、HDDなどの不揮発性の記憶装置に保存する。
【0021】
端末装置100は、ユーザ(例えば、情報処理システムの管理者)が操作するコンピュータである。端末装置100は、ユーザの操作に基づいて、システムリソース40の運用管理のワークフローを示すフロー情報を生成し、フローコントローラ200に送信する。また、ワークフローの実行中にシステムリソース40に異常がないか検査するためのルールを示すルール情報を生成し、フローコントローラ200に送信する。また、端末装置100は、ルール違反が発生したときの対処方法(リアクション)を示すリアクション情報を生成し、フローコントローラ200に登録しておく。
【0022】
フローコントローラ200は、ワークフローの実行を制御するコンピュータである。フローコントローラ200は、フロー情報をフローエンジン300に登録し、ワークフロー情報で定義された処理をフローエンジン300に実行させる。また、ルール情報をルールエンジン400に登録し、ルール違反が発生していないかルールエンジン400に検査させる。ルール違反が検出された場合、リアクション情報で定義された処理をフローエンジン300に実行させて、ワークフローを停止させる。フローコントローラ200は、ワークフローの実行結果を、端末装置100に報告する。
【0023】
フローエンジン300は、フローコントローラ200からの指示に応じて、ワークフロー情報で定義された処理をシステムリソース40に対して実行するコンピュータである。例えば、フローエンジン300は、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース40の装置に対して送信する。
【0024】
ルールエンジン400は、フローエンジン300がワークフローを実行している間、ルール違反がないか(システムリソース40に異常がないか)を検査するコンピュータである。ルールエンジン400は、CMDBサーバ500からシステムリソース40の構成情報を取得し、構成情報とルール情報とを照合してルール検査を行う。ルール違反が検出された場合、フローコントローラ200にルール違反を報告する。
【0025】
CMDBサーバ500は、システムリソース40から構成情報を収集するデータベースサーバとしてのコンピュータである。構成情報は、システムリソース40の各装置が備えるハードウェア、各装置で実行されているソフトウェア、ハードウェアやソフトウェアの状態などを示す情報を含む。CMDBサーバ500が各装置に定期的にアクセスすることで構成情報を収集してもよいし、各装置が定期または不定期(例えば、構成情報が更新されたとき)にCMDBサーバ500に構成情報を送信するようにしてもよい。CMDBサーバ500は、ルール検査に用いられる構成情報をルールエンジン400に提供する。CMDBサーバ500は、ルール検査に用いられない構成情報を収集しなくてもよい。
【0026】
なお、端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500のうちの複数のコンピュータの機能を、1台のコンピュータにまとめることも可能である。例えば、フローコントローラ200、フローエンジン300およびルールエンジン400を、1台のコンピュータにまとめてもよい。
【0027】
図3は、端末装置のハードウェア例を示すブロック図である。端末装置100は、CPU101、RAM102、HDD103、画像信号処理部104、入力信号処理部105、ディスクドライブ106および通信部107を有する。上記ユニットは、端末装置100内でバスに接続されている。なお、サーバ装置41などのシステムリソース40の装置、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500も、端末装置100と同様のハードウェアにより実現できる。
【0028】
CPU101は、端末装置100における情報処理を制御する演算装置である。CPU101は、HDD103に記憶されたプログラムやデータの少なくとも一部を読み出し、RAM102に展開してプログラムを実行する。なお、端末装置100は、複数の演算装置を備えて、情報処理を分散して実行してもよい。
【0029】
RAM102は、CPU101が扱うプログラムやデータを一時的に記憶しておく揮発性メモリである。なお、端末装置100は、RAM以外の種類のメモリを備えていてもよく、複数個のメモリを備えていてもよい。
【0030】
HDD103は、OSプログラムやアプリケーションプログラムなどのプログラム、および、情報処理に用いられるデータを記憶する不揮発性の記憶装置である。HDD103は、CPU101の命令に従って、内蔵の磁気ディスクに対する読み書きを行う。なお、端末装置100は、HDD以外の種類の不揮発性の記憶装置(例えば、SSD(Solid State Drive))を備えていてもよく、複数の記憶装置を備えていてもよい。
【0031】
画像信号処理部104は、CPU101の命令に従って、端末装置100に接続されたディスプレイ31に画像を出力する。ディスプレイ31として、例えば、CRT(Cathode Ray Tube)ディスプレイや液晶ディスプレイなどを用いることができる。
【0032】
入力信号処理部105は、端末装置100に接続された入力デバイス32から入力信号を取得し、CPU101に出力する。入力デバイス32として、例えば、マウスやタッチパネルなどのポインティングデバイスや、キーボードなどを用いることができる。
【0033】
ディスクドライブ106は、記録媒体33に記録されたプログラムやデータを読み取る駆動装置である。記録媒体33として、例えば、フレキシブルディスク(FD:Flexible Disk)やHDDなどの磁気ディスク、CD(Compact Disc)やDVD(Digital Versatile Disc)などの光ディスク、光磁気ディスク(MO:Magneto-Optical disk)を使用できる。ディスクドライブ106は、例えば、CPU101の命令に従って、記録媒体33から読み取ったプログラムやデータをRAM102またはHDD103に格納する。
【0034】
通信部107は、ネットワーク50に接続して通信を行う通信インタフェースである。ネットワーク50への接続方法は、有線でも無線でもよい。すなわち、通信部107は、有線通信インタフェースでも無線通信インタフェースでもよい。
【0035】
図4は、情報処理システムのソフトウェア例を示すブロック図である。各ブロックは、例えば、CPUとRAMを用いて実行されるプログラムのモジュールとして実装できる。
端末装置100は、構成情報取得部110、ルール編集部120およびフロー編集部130を有する。フローコントローラ200は、リアクション情報記憶部210とフロー制御部220とを有する。フローエンジン300は、フロー情報記憶部310とフロー実行部320とを有する。ルールエンジン400は、ルール情報記憶部410、ルール変換部420およびルール検査部430を有する。CMDBサーバ500は、構成情報記憶部510、関係情報記憶部520、構成情報収集部530および更新監視部540を有する。
【0036】
構成情報取得部110は、CMDBサーバ500から構成情報を取得する。
ルール編集部120は、構成情報取得部110が取得した構成情報に基づいて、ルールを編集するための画面をディスプレイに表示する。そして、画面に対するユーザの入力からルール情報を生成し、フローコントローラ200に送信する。また、ルール編集部120は、リアクションを編集するための画面をディスプレイに表示し、ユーザの入力からリアクション情報を生成してフローコントローラ200に送信する。
【0037】
フロー編集部130は、ワークフローを編集するための画面をディスプレイに表示し、ユーザの入力からフロー情報を生成してフローコントローラ200に送信する。
リアクション情報記憶部210は、リアクション情報を記憶する。
【0038】
フロー制御部220は、端末装置100からルール情報を受信し、ルールエンジン400に転送する。また、端末装置100からリアクション情報を受信し、リアクション情報記憶部210に格納する。また、端末装置100からフロー情報を受信し、ワークフローの実行中にルール違反が検出されたときリアクション情報の示すリアクションが実行されるよう、フロー情報を修正する。そして、修正したフロー情報をフローエンジン300に送信する。また、フロー制御部220は、ワークフローの実行中、ルール検査をルールエンジン400に指示し、検査結果に基づいてワークフローの続行や停止をフローエンジン300に指示する。また、ワークフローの実行結果を端末装置100に報告する。
【0039】
フロー情報記憶部310は、フロー情報を記憶する。
フロー実行部320は、フローコントローラ200からフロー情報を受信し、フロー情報記憶部310に格納する。また、フロー実行部320は、フローコントローラ200からの指示に基づいて、フロー情報記憶部310に記憶されたフロー情報が示す1またはそれ以上のステップの処理(タスク)を実行する。例えば、停止の命令、プログラムを更新させる命令、再起動の命令などのコマンドを、システムリソース40に対して送信する。フロー実行部320は、タスクの実行のためにCMDBサーバ500が保持する構成情報を参照することがあり、タスクの実行結果に基づいて構成情報を更新することがある。
【0040】
ルール情報記憶部410は、ルール情報を記憶する。
ルール変換部420は、フローコントローラ200からルール情報を受信し、CMDBサーバ500が保持する構成情報や波及関係情報を参照してルール情報を修正し、修正したルール情報をルール情報記憶部410に格納する。構成情報の項目(CI:Configuration Item)に代えて項目の種別がルール情報に記載されている場合、ルール変換部420は、CMDBサーバ500から構成情報の少なくとも一部を取得し、項目の種別を実在する項目に展開する。また、複数のルールがルール情報に含まれる場合、CMDBサーバ500から波及関係情報を取得し、継続的に検査する項目(監視する項目)が少なくなるようにルールを変換する。波及関係およびルール変換の詳細は後述する。
【0041】
ルール検査部430は、フローコントローラ200からの指示を受けて、CMDBサーバ500から構成情報の少なくとも一部を取得し、構成情報がルール情報記憶部410に記憶されたルール情報のルールに違反していないか検査する。そして、検査結果をフローコントローラ200に報告する。また、ルール検査部430は、フローコントローラから自動検査の指示があると、構成情報の項目のうち監視する項目をCMDBサーバ500に登録する。そして、登録した項目の情報が更新された旨をCMDBサーバ500から通知されると、当該項目の情報をCMDBサーバ500から取得して検査する。
【0042】
構成情報記憶部510は、システムリソース40から収集された構成情報を記憶する。
関係情報記憶部520は、構成情報の項目の間の波及関係を示す波及関係情報を記憶する。波及関係は、HDDの項目で異常が検出されるときは当該HDDを備えるサーバ装置の項目でも異常が検出されるといった、異常が項目間で波及する関係を含む。
【0043】
構成情報収集部530は、システムリソース40から構成情報を収集し、構成情報記憶部510に格納する。また、構成情報収集部530は、端末装置100、フローエンジン300およびルールエンジン400からの要求に応じて、構成情報記憶部510に記憶された構成情報の少なくとも一部を要求元に送信する。なお、構成情報収集部530は、ルールエンジン400が監視する項目以外の項目の情報を、継続的に収集しなくてもよい。その場合、構成情報収集部530は、収集していない項目の情報が要求されたとき、システムリソース40から当該項目の情報を収集して、要求元に送信する。
【0044】
更新監視部540は、ルールエンジン400からの要求に応じて、関係情報記憶部520に記憶された波及関係情報をルールエンジン400に送信する。また、更新監視部540は、ルールエンジン400から監視する項目が通知されると、少なくとも通知された項目の情報を収集するよう、構成情報収集部530に指示する。そして、構成情報記憶部510に記憶された当該項目の情報を監視し、情報が更新されたことを検出すると、構成情報の更新が検出された旨をルールエンジン400に通知する。
【0045】
図5は、構成情報の項目例を示す図である。図5の構成情報の例は、種別がサービスである1つの項目(serviceA)と、種別がサーバである2つの項目(svr1,svr2)と、種別がアプリケーションである2つの項目(app1,app2)を含む。また、種別がCPUである4つの項目(svr1_c1,svr1_c2,svr2_c1,svr2_c2)と、種別がメモリである2つの項目(svr1_m1,svr2_m1)と、種別がHDDである2つの項目(svr1_h1,svr2_h1)を含む。
【0046】
serviceAは、2つのサーバ(svr1,svr2)によって提供される。svr1は、2つのCPU(svr1_c1,svr1_c2)と1つのメモリ(svr1_m1)と1つHDD(svr1_h1)を備える。svr2は、同様に、2つのCPU(svr2_c1,svr2_c2)と1つのメモリ(svr2_m1)と1つHDD(svr2_h1)を備える。app1はsvr1上で実行され、app2はsvr2上で実行されている。例えば、app1はWebアプリケーションであり、app2はデータベース管理システム(DBMS:Database Management System)である。
【0047】
サービスの情報、サーバの情報、アプリケーションの情報、CPUの情報、メモリの情報およびHDDの情報は、それぞれ、状態(status)の情報を含む。アプリケーションの情報は、更に、キャッシュサイズの情報、設定ファイルのパスの情報、トランザクション数の情報を含むことがある。構成情報は、上記以外の情報を含んでもよい。
【0048】
図6は、構成情報の記述例を示す図である。図6に示す構成情報511は、図5に示した項目を、XML(Extensible Markup Language)によって記述したものである。構成情報511は、構成情報記憶部510に記憶される。構成情報511は、項目タグ(<item>)と関係タグ(<relationship>)を含む。
【0049】
項目タグは、構成情報の項目を示す。項目タグは、サーバタグ(<Server>)またはアプリケーションタグ(<Application>)を含む。サーバタグは、CPUタグ(<Cpu>)、メモリタグ(<Memory>)およびHDDタグ(<Hdd>)を含む。サーバタグ、アプリケーションタグ、CPUタグ、メモリタグおよびHDDタグは、それぞれ図5に示した何れかの項目に対応し、属性として状態(status)を示す値を含む。また、アプリケーションタグは、キャッシュサイズや設定ファイルのパスなどのパラメータを示すパラメータタグ(<param>)を含む。パラメータタグは、属性として当該パラメータの値を含む。
【0050】
関係タグは、項目タグが示す項目の間の関係を示す。関係タグは、属性として関係の種別(タイプ)を示す値を含む。また、関係タグは、ソース項目タグ(<sourceItem>)とターゲット項目タグ(<targetItem>)を含む。例えば、ソース項目がサービス、ターゲット項目がサーバ、タイプが“consistOf”である関係タグは、サービスがサーバを用いて実現される関係を示す。また、ソース項目がアプリケーション、ターゲット項目がサーバ、タイプが“installedOn”である関係タグは、アプリケーションがサーバ上で実行される関係を示す。
【0051】
図7は、異常の波及関係の例を示す図である。波及関係は、異常が構成情報の項目間で波及する関係であり、波及する方向をもつ。例えば、HDD故障およびメモリエラーは、それぞれサーバ故障の原因となる。設定エラーおよび高負荷は、アプリケーション異常の原因となる。サーバ故障およびアプリケーション異常は、サービス異常の原因となる。よって、構成情報において、HDDの項目の状態(status)がエラーを示すとき、サーバの項目の状態もエラーを示すことが想定される。また、サーバの項目の状態がエラーを示すとき、サービスの項目の状態もエラーを示すことが想定される。このように、上位の項目の状態は、下位の項目の状態の影響を受ける。
【0052】
図8は、波及関係テーブルの例を示す図である。図8の波及関係テーブルの例は、図7の波及関係に対応している。波及関係テーブル521は、関係情報記憶部520に記憶される。波及関係テーブル521は、ID、異常、親異常および条件の項目を含む。
【0053】
IDは、異常を識別するための識別情報である。異常の項目は、サービス異常などの異常の要因を示す。親異常は、当該異常から直接影響を受ける他の異常を示す。例えば、HDD故障の親異常はサーバ故障であり、サーバ故障の親異常はサービス異常である。条件は、状態異常が生じているか否かを構成情報から判断するための式の雛形であり、項目の種別名(Serviceなど)を用いて記述される。図8の例では、異常でないとき(正常のとき)に真となる論理式の雛形を条件として記述しているが、異常であるときに真となる論理式の雛形を記述してもよい。なお、図8において、[ATTR]は任意のパラメータ名を示し、[OP]は任意の演算子を示し、[VAL]は任意の固定値を示す。
【0054】
図9は、ルール定義テーブルの例を示す図である。ルール定義テーブル411は、ルール変換部420によって生成され、ルール情報記憶部410に記憶される。ルール定義テーブル411は、ID、ルールおよび親ルールの項目を含む。
【0055】
IDは、ルールを識別するための識別情報である。ルールは、異常が生じているか否かを構成情報から判断するための式として記述され、項目名(serviceAなど)を用いて記述される。図9の例では、異常でないとき(正常のとき)に真となる論理式をルールとして記述しているが、異常であるときに真となる論理式を記述してもよい。親ルールは、当該ルールに基づいて異常が検出された(ルール違反が生じた)ときに、同様にルール違反が生じると考えられる他のルールを示す。
【0056】
例えば、図9の例では、ルールR1,R2の親ルールはルールR4である。ルールR1,R2の少なくとも一方の違反が生じると、ルールR4の違反も生じると考えられる。一方、ルールR4の違反が生じていない場合、ルールR1,R2の違反も生じていないと考えられ、ルールR1,R2の検査は省略できる。なお、後述するように、端末装置100のユーザは、ルールR1,R2,R3を定義すればよい。ルールR4は、ルールR1,R2に基づいて、ルール変換部420によって自動的に追加される。
【0057】
図10は、リアクション定義テーブルの例を示す図である。リアクション定義テーブル211は、リアクション情報記憶部210に記憶される。リアクション定義テーブル211は、ID、条件およびリアクションの項目を含む。
【0058】
IDは、リアクションを識別するための識別情報である。条件は、リアクションが実行されるときの条件を示す。例えば、“R1 OR R3”は、上記のルールR1,R3の少なくとも一方のルール違反が検出されたという条件を示す。また、“R2 AND R3”は、上記のルールR2,R3の両方のルール違反が検出されたという条件を示す。リアクションの項目は、リアクションの内容を示す。例えば、サービスの提供に用いるサーバ装置を追加する、サービスを停止させる、などのリアクションを定義しておく。
【0059】
次に、ルールを情報処理システムに登録する処理を説明する。
図11は、ルール登録処理を示すフローチャートである。以下、図11に示す処理をステップ番号に沿って説明する。
【0060】
(ステップS11)端末装置100の構成情報取得部110は、CMDBサーバ500にアクセスして構成情報511を取得する。
(ステップS12)端末装置100のルール編集部120は、ステップS11で取得された構成情報511に基づいて、実在する項目または項目の種別を選択してルールを入力できるようにするルール編集画面を生成し、ディスプレイに表示する。そして、ルール編集部120は、ユーザが入力したルールを示すルール情報を生成し、フローコントローラ200に送信する。フローコントローラ200のフロー制御部220は、端末装置100から受信したルール情報をルールエンジン400に転送する。
【0061】
(ステップS13)ルールエンジン400のルール変換部420は、フローコントローラ200から受信したルール情報に、項目の種別を用いて記述されたルールが含まれるか判断する。ルールに項目の種別が含まれているか否かは、CMDBサーバ500が有する構成情報511を参照して判断してもよい。含まれる場合、処理をステップS14に進める。含まれない場合、処理をステップS15に進める。
【0062】
(ステップS14)ルール変換部420は、CMDBサーバ500にアクセスして構成情報511を取得する。そして、ルール変換部420は、構成情報511に基づいて、ルール情報に含まれる項目の種別を実在する項目に展開する。
【0063】
(ステップS15)ルール変換部420は、CMDBサーバ500にアクセスして波及関係テーブル521を取得する。
(ステップS16)ルール変換部420は、ステップS12でフローコントローラ200から受信したルール情報に含まれるルールを1つ選択する。
【0064】
(ステップS17)ルール変換部420は、ステップS16で選択したルールが、ステップS15で取得した波及関係テーブル521に記載された何れかの条件に合致するか判断する。判断の際には、ルールに含まれる項目を種別に置換して、条件と比較する。項目から種別への置換は、構成情報511を参照し行ってもよい。合致する場合、処理をステップS18に進める。合致しない場合、処理をステップS20に進める。
【0065】
(ステップS18)ルール変換部420は、波及関係テーブル521で定義される木(図7に示したような木)の部分木を生成する。生成する部分木は、ステップS17で合致した条件に対応するノードとルートノードとの間の経路を含む。例えば、ステップS16で選択したルールがサーバ故障(S2)の条件に合致した場合、サービス異常(S1)に対応するノードとサーバ故障(S2)に対応するノードを含む部分木が生成される。
【0066】
(ステップS19)ルール変換部420は、構成情報511を参照して、ステップS18で生成した部分木の各ノードに対して項目を対応付ける。例えば、ステップS16で選択したルールがサーバの項目svr1を含む場合、サーバ故障(S2)のノードにサーバの項目svr1を対応付け、サービス異常(S1)のノードにサービスの項目serviceAを対応付ける。そして、処理をステップS21に進める。
【0067】
(ステップS20)ルール変換部420は、ステップS16で選択したルールを監視対象のルール(親ルールをもたないルール)に指定する。
(ステップS21)ルール変換部420は、ステップS16でルール情報に含まれる全てのルールを選択したか判断する。全てのルールを選択した場合、処理をステップS22に進める。未選択のルールがある場合、処理をステップS16に進める。
【0068】
図12は、ルール登録処理を示すフローチャート(続き)である。
(ステップS22)ルール変換部420は、生成された部分木の中に、異常要因と項目の両方が同じであるノードを含む2以上の部分木が存在するか検索し、検索された当該2以上の部分木を、1つの部分木にマージする。
【0069】
(ステップS23)ルール変換部420は、ステップS22でマージが行われた後の部分木の集合の中から、部分木を1つ選択する。
(ステップS24)ルール変換部420は、ステップS23で選択した部分木に分岐が存在するか(複数の葉ノードを含むか)判断する。分岐が存在する(複数の葉ノードを含む)場合、処理をステップS25に進める。分岐が存在しない(1つの葉ノードのみを含む)場合、処理をステップS27に進める。
【0070】
(ステップS25)ルール変換部420は、ステップS23で選択した部分木から、分岐元のノードのうち最上位に位置するもの(全ての葉ノードをカバーできるノードのうち最下位に位置するもの)を選択する。
【0071】
(ステップS26)ルール変換部420は、ステップS15で取得した波及関係テーブル521から、ステップS25で選択したノードに対応する条件を取得する。そして、条件に含まれる項目の種別を、選択したノードに対応付けられた項目に置換することで、上位のルールを生成する。ルール変換部420は、生成したルールを監視対象のルールに指定する。その後、処理をステップS28に進める。
【0072】
(ステップS27)ルール変換部420は、ステップS23で選択した部分木の葉ノードに対応するルール(フローコントローラ200から受信したルール情報に含まれていた元のルール)を、監視対象のルールに指定する。
【0073】
(ステップS28)ルール変換部420は、ステップS23で全ての部分木を選択したか判断する。全ての部分木を選択した場合、監視対象に指定したルールおよび元のルールを含むルール定義テーブル411をルール情報記憶部410に格納し、処理を終了する。未選択の部分木がある場合、処理をステップS23に進める。
【0074】
図13は、ルール編集画面の例を示す図である。端末装置100は、CMDBサーバ500が有する構成情報に基づいて、ルール作成を支援するためのルール編集画面121を生成する。ルール編集画面121は、例えば、ディスプレイ31に表示される。ルール編集画面121は、種別、項目、属性およびルールの欄を含む。
【0075】
種別の欄には、サーバやHDDなどの種別が記載される。項目の欄には、構成情報に含まれる実在の項目が種別毎に記載される。ユーザは、検査対象の種別または項目を選択することができる。種別を選択した場合、実在する当該種別の項目全てを選択したものとして取り扱われる。例えば、サーバを選択すると、サーバの項目svr1,svr2の両方を選択したものとして取り扱われる。属性の欄には、構成情報に含まれる属性が記載される。ルールの欄には、属性に対する式を入力することができる。ユーザは、選択した種別または項目に対応する1またはそれ以上の属性を指定して式を入力する。
【0076】
図14は、ルール変換の例を示す図である。図9に示したルールR1,R2が、端末装置100で生成されたルール情報に含まれているとする。
ルールエンジン400は、ルールR1から、サーバ故障のノードとサービス異常のノードを含む部分木を生成する。サーバ故障のノードには、項目svr1が対応付けられ、サービス異常のノードには、項目svr1と関連する項目serviceAが対応付けられる。また、ルールエンジン400は、ルールR2から、高負荷のノードとアプリケーション異常のノードとサービス異常のノードを含む部分木を生成する。高負荷のノードには、項目app2が対応付けられ、アプリケーション異常のノードには、項目app2が対応付けられ、サービス異常のノードには、項目serviceAが対応付けられる。
【0077】
ルールエンジン400は、上記2つの部分木の間で、ルートノードの異常要因(サービス異常)と項目(serviceA)が一致するため、上記2つの部分木をマージする。ルールエンジン400は、マージ後の部分木の中から、最上位の分岐ノードであるサービス異常のノードを選択する。そして、ルールエンジン400は、サービス異常のノードに対応するルールR4を生成し、ルールR4を継続的に検査するルールに指定する。この場合、元のルールR1,R2は、継続的に検査するルールに指定されない。
【0078】
次に、ワークフローを情報処理システムに登録する処理を説明する。
図15は、ワークフローの例を示す図である。フローコントローラ200は、端末装置100から受信したフロー情報を修正して、ワークフローの途中でルール検査が行われるようにする。そして、修正したフロー情報を、フローエンジン300に登録する。
【0079】
タスク1とタスク2を逐次的に実行するワークフローを示すフロー情報が、端末装置100で生成されたとする。フローコントローラ200は、最初の通常タスク(タスク1)の前に事前検査の検査タスクを挿入し、最後の通常タスク(タスク2)の後に事後検査の検査タスクを挿入する。また、通常タスクの間それぞれ(タスク1とタスク2の間)に、実行中検査の検査タスク(実行中検査1)を挿入する。また、各検査タスクの後に検査結果に応じた分岐を挿入し、ルール違反が検出された場合はワークフローを停止するための通常タスク(キャンセル)に遷移するように、タスク間の遷移を修正する。
【0080】
図16は、フロー情報の記述例を示す図である。図16に示すフロー情報311は、図15に示した修正後のワークフローを、XMLによって記述したものである。フロー情報311は、フローエンジン300のフロー情報記憶部310に記憶される。
【0081】
フロー情報311は、ワークフロー毎に、ワークフロー名の属性を有するタグ(<process>)を含む。また、フロー情報311は、検査タスク毎に、検査タスク名の属性を有するタグ(<receiveTask>)を含み、通常タスク毎に、通常タスク名の属性を有するタグ(<scriptTask>)を含む。また、フロー情報311は、分岐に対応するタグ(<exclusiveGateway>)と、タスク間の遷移またはタスクと分岐の間の遷移を示すタグ(<sequenceFlow>)を含む。
【0082】
図17は、フロー登録処理を示すフローチャートである。以下、図17に示す処理をステップ番号に沿って説明する。
(ステップS31)端末装置100のフロー編集部130は、ユーザからの入力に応じて、検査タスクを含まないワークフローを示すフロー情報を生成する。そして、フロー編集部130は、フロー情報をフローコントローラ200に送信する。
【0083】
(ステップS32)フローコントローラ200のフロー制御部220は、端末装置100から受信したフロー情報が示すワークフローに、事前検査の検査タスクおよび事後検査の検査タスクを追加する。
【0084】
(ステップS33)フロー制御部220は、フロー情報が示すワークフローについて、通常タスクの間に実行中検査の検査タスクを挿入する。
(ステップS34)フロー制御部220は、フロー情報が示すワークフローについて、検査タスクの後に分岐を挿入する。
【0085】
(ステップS35)フロー制御部220は、フロー情報が示すワークフローに、検査タスクでルール違反が検出された場合に実行される通常タスクを追加する。また、ステップS34で挿入した分岐から当該通常タスクへの遷移を追加する。
【0086】
(ステップS36)フロー制御部220は、修正したフロー情報をフローエンジン300に送信する。フローエンジン300のフロー実行部320は、フローコントローラ200から受信したフロー情報を、フロー情報記憶部310に格納する。
【0087】
次に、ワークフローの実行中に行われるルール検査の処理を説明する。
図18は、ルール検査処理を示すフローチャートである。以下、図18に示す処理をステップ番号に沿って説明する。
【0088】
(ステップS41)ルールエンジン400のルール検査部430は、ルール情報記憶部410に記憶されたルール定義テーブル411に登録されているルールから、監視対象のルール(親ルールをもたないルール)を選択する。
【0089】
(ステップS42)ルール検査部430は、ステップS41で選択したルールに現れる項目についての構成情報を、CMDBサーバ500から取得する。
(ステップS43)ルール検査部430は、ステップS42で取得した構成情報を用いてルールを評価し、不適合のルールがあるか(例えば、論理式が偽となるか)判断する。不適合のルールが少なくとも1つある場合、処理をステップS44に進める。不適合のルールがない場合、処理をステップS48に進める。
【0090】
(ステップS44)ルール検査部430は、ルール定義テーブル411を参照し、不適合のルールの下位のルール(不適合のルールを親ルールとしてもつ他のルール)があるか判断する。下位のルールが少なくとも1つの不適合のルールについて存在する場合、処理をステップS45に進める。下位のルールがない場合、処理をステップS47に進める。
【0091】
(ステップS45)ルール検査部430は、ルール定義テーブル411に登録されているルールから、不適合のルールの下位のルールを選択する。
(ステップS46)ルール検査部430は、ステップS45で選択したルールに現れる項目についての構成情報を、CMDBサーバ500に要求する。CMDBサーバ500の構成情報収集部530は要求された構成情報を、システムリソース40から収集して、ルールエンジン400に送信する。なお、構成情報収集部530は、要求された構成情報が収集対象となっている場合は、構成情報記憶部510に記憶された構成情報を送信する。ルール検査部430は、取得した構成情報を用いてルールを評価する。
【0092】
(ステップS47)ルール検査部430は、ルール違反があると判定し、違反が検出されたルールを特定する。そして、ルール検査部430は、違反が検出されたルールをフローコントローラ200に報告する。その後、処理を終了する。
【0093】
(ステップS48)ルール検査部430は、ルール違反がないと判定する。ルール検査部430は、フローコントローラ200からの指示に基づいてルール検査を開始した場合には、ルール違反がないことをフローコントローラ200に報告する。
【0094】
例えば、図9に示したルール定義テーブル411がルール情報記憶部410に記憶されている場合、ルール検査部430は、ルールR3,R4に基づいて項目serviceAを検査する。ルールR3の違反が検出された場合、下位のルールが存在しないため、ルールR3単独の違反と判定する。一方、ルールR4の違反が検出された場合、ルール検査部430は、下位のルールR1,R2に基づいて項目svr1と項目app2を検査する。そして、違反が検出されたルールを、下位のルールも含めて特定する。
【0095】
次に、ワークフローの実行制御の流れを説明する。
図19は、ワークフローの実行手順の例を示す第1のシーケンス図である。図19において、ステップS51〜S56は、ワークフローを開始する際に行われる。ステップS57〜S61は、ワークフローで定義された検査タスクを実行する際に行われる。
【0096】
(ステップS51)端末装置100は、ルール情報およびフロー情報を生成し、フローコントローラ200に送信する。
(ステップS52)フローコントローラ200は、端末装置100から受信したフロー情報を修正して、ルール検査が行われるようにワークフローを変換する。ワークフローの変換の際には、登録されているリアクション情報を参照してもよい。
【0097】
(ステップS53)フローコントローラ200は、ステップS52で修正したフロー情報を、フローエンジン300に送信する。フローエンジン300は、端末装置100から受信したフロー情報を保存する。
【0098】
(ステップS54)フローコントローラ200は、端末装置100から受信したルール情報をルールエンジン400に転送する。
(ステップS55)ルールエンジン400は、フローコントローラ200から受信したルール情報に記載されている項目の種別を項目に展開する。また、監視対象のルール(継続的に検査するルール)が少なくなるように、ルールをルール情報に追加する。その際、フローコントローラ200は、CMDBサーバ500がもつ構成情報や波及関係情報を参照する。そして、修正したフロー情報を保存する。
【0099】
(ステップS56)フローコントローラ200は、フロー情報およびルール情報の登録が完了したことを確認し、ワークフローの開始をフローエンジン300に指示する。フローコントローラ200は、フロー情報に記載されたタスクを逐次的に実行する。
【0100】
(ステップS57)フローエンジン300は、次に実行するタスクが検査タスク(事前検査、実行中検査または事後検査のタスク)である場合、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
【0101】
(ステップS58)フローコントローラ200は、ルールエンジン400に、ルール情報に基づく構成情報の検査を指示する。
(ステップS59)ルールエンジン400は、CMDBサーバ500から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。
【0102】
(ステップS60)ルールエンジン400は、ステップS59の検査結果をフローコントローラ200に報告する。ルール違反が検出された場合には、違反と判定されたルールの識別情報も、フローコントローラ200に報告する。
【0103】
(ステップS61)フローコントローラ200は、ルールエンジン400から報告された検査結果に基づいて、フローエンジン300に次動作を指示する。次動作の指示の際には、登録されているリアクション情報を参照してもよい。例えば、フローコントローラ200は、ルール違反が検出されなかったときは“NEXT”(フロー継続)を指示し、ルール違反が検出されたときは“CANCEL”(フロー終了)を指示する。フローエンジン300は、中断しているワークフローを再開し、フローコントローラ200からの指示に応じて、フロー情報に記載された分岐の方向を判断する。
【0104】
図20は、ワークフローの実行手順の例を示す第2のシーケンス図である。図20において、ステップS62〜S65は、検査タスクが実行されるタイミング以外のタイミングでもルール検査を適宜行えるようにする処理であり、事前検査の直後に行われる。ステップS66〜S69は、通常タスクを実行する際に行われる。
【0105】
(ステップS62)フローエンジン300は、事前検査の検査タスクが終了した後に、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
(ステップS63)フローコントローラ200は、ルールエンジン400に、自動的にルール検査が行われるようにする設定を指示する。
【0106】
(ステップS64)ルールエンジン400は、ルール情報から、監視対象のルールに現れる項目を抽出し、CMDBサーバ500に通知する。CMDBサーバ500は、ルールエンジン400からから通知された項目を、監視する項目として登録する。
【0107】
(ステップS65)フローコントローラ200は、監視する項目の登録が完了したことを確認し、フローエンジン300に次動作の指示としてフロー継続を指示する。フローエンジン300は、中断しているワークフローを再開する。
【0108】
(ステップS66)フローコントローラ200は、次に実行するタスクが通常タスクである場合、フロー情報で定義される処理を実行する。フロー情報で定義される処理としては、例えば、システムリソース40の装置への停止コマンドの送信、修正プログラムをインストールさせるコマンドの送信、再起動コマンドの送信などが考えられる。フローコントローラ200は、通常タスクの実行の際に、CMDBサーバ500がもつ構成情報を参照することがあり、構成情報を更新することもある。
【0109】
(ステップS67)CMDBサーバ500は、ステップS64で登録された項目についての構成情報が変更されているか否かを監視する。CMDBサーバ500がもつ構成情報は、フローコントローラ200によって変更されることがあり、また、システムリソース40から収集した情報によって変更されることがある。CMDBサーバ500は、構成情報の変更を検出すると、ルールエンジン400に変更を通知する。
【0110】
(ステップS68)ルールエンジン400は、ルールエンジン400は、CMDBサーバ500から構成情報を取得し、構成情報を用いて監視対象のルールを評価する。監視対象のルールの違反が検出された場合、当該ルールの下位のルールも評価する。
【0111】
(ステップS69)ルールエンジン400は、ステップS68ルール違反を検出した場合、ルール違反が検出された旨および違反と判定されたルールの識別情報を、フローコントローラ200に報告する。ルール違反を検出しなかった場合は、フローコントローラ200にその旨を報告しなくてもよい。フローコントローラ200は、例えば、次にワークフローが中断されたタイミングで、フローエンジン300にフロー終了を指示する。
【0112】
図21は、ワークフローの実行手順の例を示す第3のシーケンス図である。図21において、ステップS70〜S73は、自動検査の設定を解除する処理であり、事後検査の直前に行われる。ステップS74〜S77は、ワークフローを開始する際に行われる。
【0113】
(ステップS70)フローエンジン300は、事後検査の検査タスクを実行する前に、ワークフローを中断し、中断したことをフローコントローラ200に通知する。
(ステップS71)フローコントローラ200は、ルールエンジン400に、自動的にルール検査が行われるようにする設定の解除を指示する。
【0114】
(ステップS72)ルールエンジン400は、ルール情報から、監視対象のルールに現れる項目を抽出し、CMDBサーバ500に通知する。CMDBサーバ500は、ルールエンジン400から通知された項目の登録を抹消する。
【0115】
(ステップS73)フローコントローラ200は、監視する項目の抹消が完了したことを確認し、フローエンジン300に次動作の指示としてフロー継続を指示する。フローエンジン300は、中断しているワークフローを再開する。
【0116】
(ステップS74)フローエンジン300は、ワークフローが終了する(例えば、事後検査のタスクが終了する)と、終了したことをフローコントローラ200に通知する。ワークフローの終了には、正常終了と異常終了とが含まれる。
【0117】
(ステップS75)フローコントローラ200は、ルール情報の削除をルールエンジン400に指示する。ルールエンジン400は、ルール情報を削除する。
(ステップS76)フローコントローラ200は、フロー情報の削除をフローエンジン300に指示する。フローエンジン300は、フロー情報を削除する。
【0118】
(ステップS77)フローコントローラ200は、ワークフローの実行結果として正常終了または異常終了を、端末装置100に報告する。
第2の実施の形態の情報処理システムによれば、項目間の波及関係を考慮して複数のルールを統合し、統合したルールについて継続的に検査することで、ルール検査の回数を削減でき、検査の負荷を軽減することができる。また、上位のルールで違反が検出されたときに、下位の複数のルールについて検査を行うことで、異常原因を把握することが可能となる。また、下位のルールに対応する構成情報を継続的に収集しないようにすることで、構成情報を収集する負荷も軽減することができる。
【0119】
また、監視する項目をCMDBサーバ500に登録しておき、登録した項目の情報が変更されたことを契機として検査を行うことで、ルール検査を効率化することができる。また、CMDBサーバ500がもつ構成情報を参照して、実在する項目を指定してルールを記述できるようにするルール編集画面をユーザに提供することで、実在しない項目を指定した不適切なルールが記述されることを防止できる。また、ユーザが項目の種別を指定してルールを記述できるようにすることで、ルールの記述漏れを抑制できる。
【0120】
なお、前述のように、第2の実施の形態のワークフロー制御およびルール検査は、コンピュータとしての端末装置100、フローコントローラ200、フローエンジン300、ルールエンジン400およびCMDBサーバ500に、それぞれプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体(例えば、記録媒体33)に記録しておくことができる。記録媒体として、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどを使用できる。磁気ディスクには、FDおよびHDDが含まれる。光ディスクには、CD、CD−R(Recordable)/RW(Rewritable)、DVDおよびDVD−R/RWが含まれる。
【0121】
プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。また、プログラムを他のコンピュータの記憶装置に格納しておき、ネットワーク50経由でプログラムを配布することもできる。コンピュータは、例えば、可搬記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを記憶装置(例えば、HDD103)に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよく、他のコンピュータからネットワーク50を介して受信したプログラムを直接実行してもよい。
【符号の説明】
【0122】
10 情報処理装置
11 記憶部
11a 検査情報
12 検査部
21〜23 装置
【特許請求の範囲】
【請求項1】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視する情報処理システムが行う監視方法であって、
第1の項目、第2の項目、および、取得される情報が前記第1および第2の項目の情報と関連する第3の項目のうち、前記第3の項目の情報を検査し、
前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、
前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報をそれぞれ検査する、
監視方法。
【請求項2】
検査対象として前記第1および第2の項目が指定されたとき、前記複数の項目の間の関係であって、一の項目の情報が他の項目の情報に影響を与える関係を示す関係情報を記憶する記憶装置を参照し、前記第1および第2の項目に基づいて前記第3の項目を検索し、
検索された前記第3の項目を検査対象に追加する、
請求項1記載の監視方法。
【請求項3】
前記1またはそれ以上の装置から前記第3の項目の情報を取得し、
前記第3の項目の情報の検査で異常が検出された後に、前記1またはそれ以上の装置から前記第1および第2の項目の情報を取得する、
請求項1記載の監視方法。
【請求項4】
前記1またはそれ以上の装置から前記複数の項目の情報の少なくとも一部を収集するデータベース装置に、前記第3の項目の情報を収集させ、
前記データベース装置で前記第3の項目の情報が更新されたことが検出されたとき、更新された前記第3の項目の情報を検査する、
請求項1記載の監視方法。
【請求項5】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視する情報処理装置であって、
検査対象として、第1の項目と、第2の項目と、取得される情報が前記第1および第2の項目の情報と関連する第3の項目とを示す検査情報を記憶する記憶部と、
前記検査情報が示す検査対象の項目の情報を検査する検査部と、を有し、
前記検査部は、前記第3の項目の情報を検査し、前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報を検査する、
情報処理装置。
【請求項6】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視するための監視プログラムであって、コンピュータに、
第1の項目、第2の項目、および、取得される情報が前記第1および第2の項目の情報と関連する第3の項目のうち、前記第3の項目の情報を検査し、
前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、
前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報をそれぞれ検査する、
処理を実行させる監視プログラム。
【請求項1】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視する情報処理システムが行う監視方法であって、
第1の項目、第2の項目、および、取得される情報が前記第1および第2の項目の情報と関連する第3の項目のうち、前記第3の項目の情報を検査し、
前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、
前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報をそれぞれ検査する、
監視方法。
【請求項2】
検査対象として前記第1および第2の項目が指定されたとき、前記複数の項目の間の関係であって、一の項目の情報が他の項目の情報に影響を与える関係を示す関係情報を記憶する記憶装置を参照し、前記第1および第2の項目に基づいて前記第3の項目を検索し、
検索された前記第3の項目を検査対象に追加する、
請求項1記載の監視方法。
【請求項3】
前記1またはそれ以上の装置から前記第3の項目の情報を取得し、
前記第3の項目の情報の検査で異常が検出された後に、前記1またはそれ以上の装置から前記第1および第2の項目の情報を取得する、
請求項1記載の監視方法。
【請求項4】
前記1またはそれ以上の装置から前記複数の項目の情報の少なくとも一部を収集するデータベース装置に、前記第3の項目の情報を収集させ、
前記データベース装置で前記第3の項目の情報が更新されたことが検出されたとき、更新された前記第3の項目の情報を検査する、
請求項1記載の監視方法。
【請求項5】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視する情報処理装置であって、
検査対象として、第1の項目と、第2の項目と、取得される情報が前記第1および第2の項目の情報と関連する第3の項目とを示す検査情報を記憶する記憶部と、
前記検査情報が示す検査対象の項目の情報を検査する検査部と、を有し、
前記検査部は、前記第3の項目の情報を検査し、前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報を検査する、
情報処理装置。
【請求項6】
1またはそれ以上の装置から取得される複数の項目の情報に基づいて、前記1またはそれ以上の装置を監視するための監視プログラムであって、コンピュータに、
第1の項目、第2の項目、および、取得される情報が前記第1および第2の項目の情報と関連する第3の項目のうち、前記第3の項目の情報を検査し、
前記第3の項目の情報の検査で異常が検出されなかった場合、前記第1および第2の項目の情報の検査を省略し、
前記第3の項目の情報の検査で異常が検出された場合、前記第1および第2の項目の情報をそれぞれ検査する、
処理を実行させる監視プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【公開番号】特開2012−203681(P2012−203681A)
【公開日】平成24年10月22日(2012.10.22)
【国際特許分類】
【出願番号】特願2011−68133(P2011−68133)
【出願日】平成23年3月25日(2011.3.25)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成24年10月22日(2012.10.22)
【国際特許分類】
【出願日】平成23年3月25日(2011.3.25)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]