JP2010238200A - 状態変化通知プログラム、情報処理装置および状態変化通知方法 - Google Patents

Abstract

【課題】エージェントで発生する状態変化をリアルタイムに検出することを課題とする。
【解決手段】情報処理装置は、当該情報処理装置が有する構成要素の状態変化の検出によってＭＩＢ「Ａ」、ＭＩＢ「Ｂ」およびＭＩＢ「Ｃ」を変更し、変更されたＭＩＢそれぞれを取得して、監視装置へのＴＲＡＰの送信タイミングに基づいて、取得されたＭＩＢそれぞれを下位のＭＩＢとして包含する最小単位での上位のＭＩＢ「Ｄ」をｓｕｂｔｒｅｅとしてｓｕｂｔｒｅｅテーブルに格納するとともに、当該ｓｕｂｔｒｅｅを含んだＴＲＡＰを監視装置に対して送信する。
【選択図】図１

Description

本発明は、状態変化通知プログラム、情報処理装置および状態変化通知方法に関する。

従来より、通信機器やサーバなどの装置をネットワーク経由で監視するために、ＳＮＭＰ（Simple Network Management Protocol）プロトコルが利用されている。ＳＮＭＰプロトコルを利用した監視システムは、例えば、監視装置であるマネージャと、被監視装置であるエージェントとを有する。

そして、マネージャは、一種のデータベースであるＭＩＢ（Management Information Base）に格納された状態値の問合せをエージェントに対して行なう。一方、エージェントは、マネージャにより問い合わせのあった状態値をマネージャに応答する。これらによって、マネージャは、各エージェントの状態を監視する。

一般的に、ＳＮＭＰで利用されるＭＩＢは、ＡＳＮ．１（Abstract Syntax Notation One）形式の定義ファイルにより定義される。具体的には、汎用的なＭＩＢは、ＲＦＣ（Request For Comment）によって発行され、ベンダや装置固有のＭＩＢは、ベンダ毎に作成される。

ここで、図６−１および図６−２を用いて、ＭＩＢについて説明する。図６−１は、ＭＩＢの構造を説明するための図であり、図６−２は、ＭＩＢの関連性を説明するための図である。

例えば、図６−１に示すように、ＭＩＢは、オブジェクトＩＤと呼ばれる数値の並びによって指定され、当該オブジェクトＩＤの並びによるツリー構造を有する。そして、図６−１において四角で示したＭＩＢは、「１．３．６．１．２．１．５」と表される。また、一般的に、関連性のあるＭＩＢ同士は、当該ＭＩＢの定義上、特定の部分木（以下、「ｓｕｂｔｒｅｅ」と言う）配下に固まる場合が多い。

例えば、図６−２に示すように、「・・・．１」は、所定装置のＭＩＢが格納されるｓｕｂｔｒｅｅであり、「・・・．１．２」は、所定装置のＩ／Ｆ群のＭＩＢが格納されるｓｕｂｔｒｅｅである。また、例えば、「・・・．１．２．１」は、所定装置の特定のＩ／ＦのＭＩＢが格納されるｓｕｂｔｒｅｅであり、「・・・．１．２．１．１」は、所定装置の特定のＩ／Ｆの特定のプロトコルに関するＭＩＢが格納されるｓｕｂｔｒｅｅである。

次に、図７を用いて、従来技術に係る監視システムの構成を説明する。図７は、従来技術に係る監視システムの構成例を説明するための図である。

例えば、図７に示すように、従来技術に係る監視システムは、監視装置であるマネージャと、被監視装置であるエージェントとを有する。そして、被監視装置は、ＭＩＢと、状態変化検出部と、状態値変更部と、状態変化通知部とを有する。このうち、状態変化検出部は、少なくとも一つの状態変化検出部を有し、例えば、状態変化検出部Ａと状態変化検出部Ｂとを有する。

状態変化検出部は、例えば、関連性のあるＭＩＢ同士が特定のｓｕｂｔｒｅｅ配下に固まるということと連動して、装置内において関連性のある構成要素別に状態を監視するために、複数の状態変化検出部を有する。

具体的に説明すると、状態変化検出部Ａは、図７の（１）に示すように、被監視装置が有する構成要素の状態変化を検出し、状態変化が検出された構成要素に該当するＭＩＢの変更要求を状態値変更部に対して行なう。そして、状態変化検出部ＡからＭＩＢの変更要求を受け付けた状態値変更部は、図７の（２）に示すように、該当するＭＩＢの状態値を変更する。

続いて、状態変化検出部Ａは、図７の（３）に示すように、状態変化が検出されたことを状態変化通知部に対して通知する。その後、状態変化通知部は、図７の（４）に示すように、状態変化が検出されたことを示すＴＲＡＰを監視装置に対して送信する。

また、被監視装置からＴＲＡＰを受信した監視装置は、図７の（５）に示すように、被監視装置が有する全てのＭＩＢの状態値を収集する。そして、監視装置は、当該監視装置で予め保持されるＭＩＢの状態値と、収集されたＭＩＢの状態値とを比較して状態変化のあったＭＩＢ、すなわち状態変化のあった構成要素を特定する。なお、上記処理は、状態変化検出部Ｂによって状態変化が検出された場合でも同様に実施される。

次に、図８を用いて、従来技術に係る監視システムにおける状態変化通知処理を説明する。図８は、従来技術に係る監視システムにおける状態変化通知処理を説明するためのシーケンス図である。

例えば、図８に示すように、被監視装置は、当該被監視装置内の構成要素における状態変化を検出する（ステップＳ１１）。そして、被監視装置は、状態変化が検出された構成要素に対応するＭＩＢの状態値を変更する（ステップＳ１２）。続いて、被監視装置は、状態変化があったことを示すＴＲＡＰを監視装置に対して送信する（ステップＳ１３）。

その後、監視装置は、ＭＩＢの状態値の問い合わせおよび応答メッセージであるＧｅｔＲｅｑｕｅｓｔとＧｅｔＲｅｓｐｏｎｓｅとのメッセージを被監視装置と送受信することにより、当該被監視装置が有する全てのＭＩＢの状態値を収集する（ステップＳ１４）。そして、被監視装置は、予め保持されるＭＩＢの状態値と、収集されたＭＩＢの状態値とを比較して状態変化のあったＭＩＢを特定することにより、状態変化のあった構成要素を特定する。なお、従来技術に係る監視システムでは、状態変化が検出される度に上記処理が実施される。

特開２００３−１５０４６６号公報

しかしながら、上述した従来技術では、エージェントで発生する状態変化をリアルタイムに検出することができないという課題がある。具体的には、ＭＩＢは、ルータやスイッチなどのネットワーク機器だけでなく、サーバ装置の監視や制御などにも用いられているため、上述した従来技術では、ＭＩＢの増大によって各ＭＩＢの取得や状態変化の検出などの処理負荷が増大する。

つまり、上述した従来技術では、ＭＩＢの増大に起因した処理負荷の増大によって処理遅延が発生し、エージェント側での状態変化の発生からマネージャ側での状態変化の検出においてタイムラグが発生する。さらには、マネージャ側で状態変化が検出される前に、エージェント側での状態が元に戻ってしまうことも考えられる。そして、これらのことは、状態変化のあったＭＩＢを含んだＴＲＡＰを一つ一つ個別にマネージャに送信する場合でも同様に発生する。

そこで、本願に開示する技術は、上記に鑑みてなされたものであって、エージェントで発生する状態変化をリアルタイムに検出することが可能である状態変化通知プログラム、情報処理装置および状態変化通知方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本願に開示する状態変化通知プログラムは、監視対象である被監視装置に含まれる構成要素それぞれの状態情報が階層化されている状態情報データベースにおいて、前記構成要素の状態変化の検出によって前記状態情報が変更された場合に、変更された状態情報を取得する取得手順と、前記被監視装置を監視する監視装置に対して、所定イベントを送信する時機を通知する通知手順と、前記通知手順によって前記所定イベントを送信する時機が通知された場合に、前記取得手順によって取得された前記状態情報を下位の状態情報として包含する最小単位での上位の状態情報の送信を指示する送信指示手順と、前記送信指示手順によって前記上位の状態情報の送信指示を受け付けた場合に、前記上位の状態情報を含んだ前記所定イベントを前記監視装置に対して送信する送信手順と、を実行させる。

本願に開示する状態変化通知プログラム、情報処理装置および状態変化通知方法の一つの様態によれば、エージェントで発生する状態変化をリアルタイムに検出することができるという効果を奏する。

図１は、情報処理装置を含むシステム構成の例について説明するための図である。 図２は、実施例１に係る情報処理装置の構成例を示す図である。 図３−１は、ｓｕｂｔｒｅｅテーブルに記憶される情報の例を示す図である。 図３−２は、ＭＩＢに記憶される情報の例を示す図である。 図４は、実施例１に係る状態変化通知処理の流れを説明するためのシーケンス図である。 図５は、状態変化通知プログラムを実行するコンピュータを示す図である。 図６−１は、ＭＩＢの構造を説明するための図である。 図６−２は、ＭＩＢの関連性を説明するための図である。 図７は、従来技術に係る監視システムの構成例を説明するための図である。 図８は、従来技術に係る監視システムにおける状態変化通知処理を説明するためのシーケンス図である。

以下に添付図面を参照して、本願に開示する状態変化通知プログラム、情報処理装置および状態変化通知方法の実施例を説明する。なお、以下の実施例により本発明が限定されるものではない。

最初に、図１を用いて、本願に開示する情報処理装置を含むシステム構成について説明する。図１は、情報処理装置を含むシステム構成の例について説明するための図である。

本願に開示する情報処理装置は、図１に示すように、例えば、ルータやスイッチなどのネットワーク機器、或いはサーバ装置などであり、当該情報処理装置を監視する監視装置と接続される。そして、情報処理装置は、当該情報処理装置が有する各構成要素の状態情報をＭＩＢとして有する。また、ＭＩＢは、状態情報をデータベース化したものであり、関連性のある構成要素が結び付けられたツリー構造となっている。一方、監視装置は、例えば、ＳＮＭＰプロトコルを利用したＳＮＭＰマネージャである。

上述した構成において、情報処理装置は、図１の（１）に示すように、当該情報処理装置が有する構成要素の状態変化の検出によってＭＩＢが変更された場合に、変更されたＭＩＢを取得する。なお、状態変化のあったＭＩＢは、例えば、ＭＩＢ「Ａ」、ＭＩＢ「Ｂ」およびＭＩＢ「Ｃ」とする。

そして、情報処理装置は、構成要素に状態変化があったことを通知するＴＲＡＰを監視装置に対して送信するタイミングを通知する。続いて、情報処理装置は、取得されたＭＩＢ「Ａ」、ＭＩＢ「Ｂ」およびＭＩＢ「Ｃ」を下位のＭＩＢとして包含する最小単位での上位のＭＩＢ、すなわち、ＭＩＢ「Ｄ」の送信を指示する。

その後、情報処理装置は、図１の（２）に示すように、ＭＩＢ「Ｄ」を含んだＴＲＡＰを監視装置に対して送信する。そして、情報処理装置からＴＲＡＰを受信した監視装置は、図１の（３）に示すように、ＭＩＢ「Ｄ」を最上位とする下位のＭＩＢ、すなわち「Ｅ」に含まれるＭＩＢを探索して、状態変化のあった構成要素を特定する。なお、監視装置は、例えば、特定された構成要素を所定の表示部にアラーム表示する。

つまり、情報処理装置は、状態変化が検出された構成要素に該当するＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢを、状態変化があったことを通知するＴＲＡＰとともに監視装置に送信するので、マネージャが全てのＭＩＢを探索する、或いは一つ一つのＭＩＢをマネージャに送信する従来技術と比較して、エージェントで発生する状態変化をリアルタイムに検出することができる。

［情報処理装置の構成］
次に、図２を用いて、実施例１に係る情報処理装置の構成を説明する。図２は、実施例１に係る情報処理装置の構成例を示す図である。

図２に示すように、情報処理装置１００は、記憶部１１０と、制御部１２０とを有する。そして、この情報処理装置１００は、例えば、ルータやスイッチなどのネットワーク機器、或いはサーバ装置などであり、監視対象である情報処理装置１００（エージェント）を監視する監視装置（マネージャ）などと接続される。なお、監視装置は、例えば、ＳＮＭＰプロトコルを利用した装置である。

記憶部１１０は、制御部１２０による各種処理に必要なデータや、制御部１２０による各種処理結果を記憶し、特に、ＭＩＢ１１１を有する。また、記憶部１１０は、例えば、図３−１に示すように、ｓｕｂｔｒｅｅテーブルを有する。

記憶部１１０に記憶されるｓｕｂｔｒｅｅテーブルは、後述する状態情報取得部１２３によって作成され、接続される監視装置に対して送信されたｓｕｂｔｒｅｅの情報を時系列に記憶する。このｓｕｂｔｒｅｅテーブルは、例えば、「１．３．６．１．１．１．１」や「１．３．６．１．１」などを記憶する。なお、図３−１は、ｓｕｂｔｒｅｅテーブルに記憶される情報の例を示す図である。

ＭＩＢ１１１は、例えば、図３−２に示すように、情報処理装置１００が有する構成要素に対応する状態情報、すなわちＭＩＢを記憶する。ＭＩＢは、情報処理装置１００が有する構成要素に対応した状態情報をデータベース化したものであり、関連性のある構成要素が結び付けられたツリー構造となっている。なお、図３−２は、ＭＩＢ１１１に記憶される情報の例を示す図である。

制御部１２０は、制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、特に、状態変化検出部１２１と、状態値変更部１２２と、状態情報取得部１２３と、状態変化通知部１２４とを有する。

状態変化検出部１２１は、状態変化検出部１２１ａや状態変化検出部１２１ｂなどの複数の状態変化検出部を有し、監視対象である被監視装置が有する構成要素の状態変化を検出し、状態変化が検出された構成要素に該当する状態情報の変更要求を状態値変更部１２２に対して行なう。

具体的に説明すると、状態変化検出部１２１ａは、監視対象である情報処理装置１００が有する構成要素であるＩ／Ｆの特定のプロトコルに関する状態変化を検出し、状態変化が検出された構成要素に該当するＭＩＢの変更要求を状態値変更部１２２に対して行なう。なお、状態変化検出部１２１ａは、当該状態変化検出部１２１ａの管理下にある構成要素群について状態変化があるか否かを監視する。

また、状態変化検出部１２１は、監視対象である被監視装置を監視する監視装置に対して、所定イベントを送信する時機を通知する。

上述した例で具体的に説明すると、状態変化検出部１２１ａは、当該状態変化検出部１２１ａの管理下にある構成要素群について、所定の状態変化が検出された場合に、情報処理装置１００を監視する監視装置に対するＴＲＡＰの送信タイミングを状態情報取得部１２３に通知する。また、状態変化検出部１２１ａや状態変化検出部１２１ｂなどは、関連性のあるＭＩＢ同士が特定のｓｕｂｔｒｅｅ配下に固まるということと連動して、情報処理装置１００内において関連性のある構成要素別に状態を監視する。

要するに、状態変化検出部１２１ａによって検出される所定の状態変化とは、関連性のある構成要素群において検出される状態変化のことを指す。換言すると、状態変化検出部１２１ａは、関連性のある構成要素群において予測し得る所定数、所定箇所および所定時間などで状態変化が検出された時点を、ＴＲＡＰを送信するタイミングであるとしている。なお、状態変化検出部１２１ｂによる処理については、状態変化検出部１２１ａとは異なる構成要素群を監視しているものの、当該状態変化検出部１２１ａと同様であるためその説明を省略する。

状態値変更部１２２は、状態変化検出部１２１ａによって要求された状態情報の状態値を変更する。上述した例で具体的に説明すると、状態値変更部１２２は、状態変化検出部１２１ａによるＩ／Ｆの特定のプロトコルに関するＭＩＢの状態値の変更要求を受け付けると、ＭＩＢ１１１に記憶された該当するＭＩＢの状態値を変更する。

状態情報取得部１２３は、監視対象である被監視装置に含まれる構成要素それぞれの状態情報が階層化されている状態情報データベースにおいて、構成要素の状態変化の検出によって状態情報が変更された場合に、変更された状態情報を取得する。

上述した例で具体的に説明すると、状態情報取得部１２３は、状態変化検出部１２１ａによる状態変化の検出をトリガとして、状態値変更部１２２によって変更されたＭＩＢの状態値を取得する。なお、状態情報取得部１２３によるＭＩＢの状態値の取得では、状態変化が検出される度に取得されることとなる。

また、状態情報取得部１２３は、状態変化検出部１２１ａによって所定イベントを送信する時機が通知された場合に、取得された状態情報を下位の状態情報として包含する最小単位での上位の状態情報の送信を指示する。

上述した例で具体的に説明すると、状態情報取得部１２３は、状態変化検出部１２１ａによってＴＲＡＰを送信するタイミングが通知された場合に、当該通知のタイミングまでに取得された少なくとも一つのＭＩＢを下位のＭＩＢとして包含する最小単位で上位のＭＩＢの送信を状態変化通知部１２４に指示する。また、状態情報取得部１２３は、状態変化通知部１２４に送信指示する上位のＭＩＢをｓｕｂｔｒｅｅとして、ｓｕｂｔｒｅｅテーブルに格納する。

ここで、図３−１および図３−２を用いて、状態情報取得部１２３によるｓｕｂｔｒｅｅテーブル生成処理を説明する。なお、以下では、状態変化検出部１２１ａによってＴＲＡＰを送信するタイミングが通知されたこととして説明する。

例えば、状態情報取得部１２３は、状態変化検出部１２１ａによるＴＲＡＰ送信タイミングの通知までに、図３−２の（１）に示したＭＩＢ「１．３．６．１．１．１．１」に状態変化があった場合に、当該ＭＩＢを「ｓｕｂｔｒｅｅ１」としてｓｕｂｔｒｅｅテーブル（図３−１参照）に格納する。そして、状態情報取得部１２３は、ｓｕｂｔｒｅｅテーブルに格納された「１．３．６．１．１．１．１」を含んだＴＲＡＰを監視装置に送信する指示を状態変化通知部１２４に行なう。

次に、状態情報取得部１２３は、状態変化検出部１２１ａによるＴＲＡＰ送信タイミングの通知までに、図３−２の（１）〜（３）に示したＭＩＢ「１．３．６．１．１．１．１」、「１．３．６．１．１．５．１」および「１．３．６．１．１．４．２」に状態変化があった場合に、これらのＭＩＢを包含する最小単位での上位のＭＩＢ、すなわち「１．３．６．１．１」を「ｓｕｂｔｒｅｅ２」としてｓｕｂｔｒｅｅテーブル（図３−１参照）に格納する。そして、状態情報取得部１２３は、ｓｕｂｔｒｅｅテーブルに格納された「１．３．６．１．１」を含んだＴＲＡＰを監視装置に送信する指示を状態変化通知部１２４に行なう。

なお、ｓｕｂｔｒｅｅの決定では、例えば、取得された「１．３．６．１．１．１．１」、「１．３．６．１．１．５．１」および「１．３．６．１．１．４．２」を、左から見て最長の一致部、つまり「１．３．６．１．１」に決定される。

さらに、状態情報取得部１２３は、状態変化検出部１２１ａによるＴＲＡＰ送信タイミングの通知までに、図３−２の（１）〜（４）に示したＭＩＢ「１．３．６．１．１．１．１」、「１．３．６．１．１．５．１」、「１．３．６．１．１．４．２」および「１．３．６．２．１．１．１」に状態変化があった場合に、これらのＭＩＢを包含する最小単位での上位のＭＩＢ、すなわち「１．３．６」を「ｓｕｂｔｒｅｅ３」としてｓｕｂｔｒｅｅテーブル（図３−１参照）に格納する。そして、状態情報取得部１２３は、ｓｕｂｔｒｅｅテーブルに格納された「１．３．６」を含んだＴＲＡＰを監視装置に送信する指示を状態変化通知部１２４に行なう。

なお、ｓｕｂｔｒｅｅの決定では、例えば、取得された「１．３．６．１．１．１．１」、「１．３．６．１．１．５．１」、「１．３．６．１．１．４．２」および「１．３．６．２．１．１．１」を、左から見て最長の一致部、つまり「１．３．６」に決定される。

図２の説明に戻り、状態変化通知部１２４は、上位の状態情報の送信指示を受け付けた場合に、上位の状態情報を含んだ所定イベントを監視装置に対して送信する。

上述した例で具体的に説明すると、状態変化通知部１２４は、「ｓｕｂｔｒｅｅ１」、「ｓｕｂｔｒｅｅ２」若しくは「ｓｕｂｔｒｅｅ３」などの送信指示を受け付けた場合に、これらのｓｕｂｔｒｅｅを含んだＴＲＡＰを監視装置に対して送信する。

［状態変化通知処理］
次に、図４を用いて、実施例１に係る状態変化通知処理の流れを説明する。図４は、実施例１に係る状態変化通知処理の流れを説明するためのシーケンス図である。

例えば、図４に示すように、情報処理装置１００は、当該情報処理装置１００が有する構成要素の状態変化を検出する（ステップＳ１０１）。そして、情報処理装置１００は、状態変化が検出された構成要素に該当するＭＩＢの状態値を変更する（ステップＳ１０２）。

続いて、情報処理装置１００は、変更されたＭＩＢの状態値を取得する（ステップＳ１０３）。その後、情報処理装置１００は、監視装置に対するＴＲＡＰの送信タイミングに基づいて、取得されたＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢをｓｕｂｔｒｅｅとして含んだＴＲＡＰの送信を指示する（ステップＳ１０４）。なお、ＴＲＡＰの送信を指示する際には、上位のＭＩＢをｓｕｂｔｒｅｅとして、ｓｕｂｔｒｅｅテーブルに格納する。

そして、情報処理装置１００は、上位のＭＩＢを含んだＴＲＡＰを監視装置に対して送信する（ステップＳ１０５）。また、情報処理装置１００からＴＲＡＰを受信した監視装置は、ＴＲＡＰに含まれるＭＩＢ、すなわちｓｕｂｔｒｅｅ配下の全てのＭＩＢを探索して、状態変化のあったＭＩＢを特定する（ステップＳ１０６）。なお、ＭＩＢの探索については、ＧｅｔＲｅｑｕｅｓｔおよびＧｅｔＲｅｓｐｏｎｓｅなどのメッセージを監視装置と情報処理装置１００との間で送受信することにより実施される。また、本監視システムにおいては、ＴＲＡＰの送信タイミングの通知の度に、上記処理が繰り返し行われることとなる。

なお、ＭＩＢの状態値の問い合わせとしては、上記のＧｅｔＲｅｑｕｅｓｔだけではなく、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔやＧｅｔＢｕｌｋＲｅｑｕｅｓｔなどを利用することとしても良い。

［実施例１による効果］
上述したように、情報処理装置１００は、当該情報処理装置１００が有する構成要素における状態変化によりＭＩＢの状態値が変更された場合に、変更されたＭＩＢを取得し、監視装置に対するＴＲＡＰの送信タイミングに基づいて、取得されたＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢをｓｕｂｔｒｅｅとしてｓｕｂｔｒｅｅテーブルに格納しつつ、当該ｓｕｂｔｒｅｅのオブジェクトＩＤを含んだＴＲＡＰを監視装置に対して送信するので、エージェントで発生する状態変化をリアルタイムに検出することができる。

また、情報処理装置１００は、監視装置に対してＴＲＡＰを送信する度に、ＴＲＡＰに含まれるｓｕｂｔｒｅｅのオブジェクトＩＤをｓｕｂｔｒｅｅテーブルに格納するので、何らかの原因によりＴＲＡＰが消失した場合であっても、ｓｕｂｔｒｅｅテーブルに格納されたオブジェクトＩＤを送信して、エージェントで発生する状態変化をリアルタイムに検出することができる。

また、情報処理装置１００は、状態変化のあったＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢをｓｕｂｔｒｅｅとして監視装置に送信するので、状態変化のあったＭＩＢを一つ一つ監視装置に送信する、或いは全てのＭＩＢを探索する従来技術と比較して、監視システムにおける処理負荷を軽減することができる。

さて、これまで本願に開示する情報処理装置の実施例について説明したが、上述した実施例以外にも種々の異なる形態にて実施されてよいものである。そこで、（１）構成要素群での同期、（２）情報処理装置の構成、（３）プログラム、において異なる実施例を説明する。

（１）構成要素群での同期
上記実施例１では、各状態変化検出部の管理下にある構成要素群内において状態変化のあったＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢを監視装置に通知する場合を説明したが、各状態変化検出部で同期をとり、複数の構成要素群における上位のＭＩＢをまとめて監視装置に通知することもできる。

例えば、情報処理装置１００は、状態変化検出部１２１ａおよび状態変化検出部１２１ｂにおいて同期をとり、状態変化検出部１２１ａの管理下である構成要素群と、状態変化検出部１２１ｂの管理下である構成要素群とで所定の状態変化が検出された場合に、状態情報取得部１２３に対してＴＲＡＰの送信タイミングを通知する。また、監視装置に対して送信されるＴＲＡＰは、上記２つの状態変化検出部において検出されたＭＩＢを下位のＭＩＢとして包含する最小単位での上位のＭＩＢをｓｕｂｔｒｅｅとして含む。

つまり、情報処理装置１００は、監視装置に対して送信するＴＲＡＰを最小限に抑えることができるので、監視システムにかかる処理負荷をさらに軽減することができる。なお、複数の状態変化検出部による同期は、各状態変化検出部の管理下にある構成要素群がある程度関連性の高い構成要素である方が好ましい。

（２）情報処理装置の構成
また、上記文書中や図面中などで示した処理手順、制御手順、具体的名称、各種のデータやパラメタなどを含む情報（例えば、「状態変化検出部１２１」が有する検出部の数や監視する構成要素など）については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は、機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は、図示のものに限られず、例えば、状態情報取得部１２３と状態変化通知部１２４とを、ＭＩＢの取得と通知とを行なう「状態情報処理部」に統合するなど、その全部または一部を各種の負担や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合することができる。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、或いは、ワイヤードロジックによるハードウェアとして実現され得る。

（３）プログラム
ところで、上記実施例では、ハードウェアロジックによって各種の処理を実現する場合を説明したが、予め用意されたプログラムをコンピュータで実行することによって実現するようにしても良い。そこで、以下では、図５を用いて、上記実施例に示した情報処理装置１００と同様の機能を有する状態変化通知プログラムを実行するコンピュータの一例を説明する。図５は、状態変化通知プログラムを実行するコンピュータを示す図である。

図５に示すように、情報処理装置１００としてのコンピュータ１１は、バス１８で接続されるＨＤＤ１３、ＣＰＵ１４、ＲＯＭ１５およびＲＡＭ１６などを有する。

ＲＯＭ１５には、上記実施例１に示した情報処理装置１００と同様の機能を発揮する状態変化通知プログラム、つまり、図５に示すように、取得プログラム１５ａと、通知プログラム１５ｂと、送信指示プログラム１５ｃと、送信プログラム１５ｄとが、予め記憶されている。なお、これらのプログラム１５ａ〜プログラム１５ｄについては、図２に示した情報処理装置１００の各構成要素と同様、適宜統合または分散しても良い。

そして、ＣＰＵ１４がこれらのプログラム１５ａ〜プログラム１５ｄをＲＯＭ１５から読み出して実行することで、図５に示すように、プログラム１５ａ〜プログラム１５ｄは、取得プロセス１４ａと、通知プロセス１４ｂと、送信指示プロセス１４ｃと、送信プロセス１４ｄとして機能するようになる。なお、プロセス１４ａ〜プロセス１４ｄは、図２に示した、状態変化検出部１２１と、状態情報取得部１２３と、状態変化通知部１２４とに対応する。

そして、ＣＰＵ１４はＲＡＭ１６に記録されたデータに基づいて状態変化通知プログラムを実行する。

なお、上記各プログラム１５ａ〜プログラム１５ｄについては、必ずしも最初からＲＯＭ１５に記憶させておく必要はなく、例えば、コンピュータ１１に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、またはコンピュータ１１の内外に備えられるＨＤＤなどの「固定用の物理媒体」、さらには公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１１に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ１１がこれから各プログラムを読み出して実行するようにしてもよい。

１００ 情報処理装置
１１０ 記憶部
１１１ ＭＩＢ
１２０ 制御部
１２１、１２１ａ、１２１ｂ 状態変化検出部
１２２ 状態値変更部
１２３ 状態情報取得部
１２４ 状態変化通知部

Claims (5)

1. 監視対象である被監視装置に含まれる構成要素それぞれの状態情報が階層化されている状態情報データベースにおいて、前記構成要素の状態変化の検出によって前記状態情報が変更された場合に、変更された状態情報を取得する取得手順と、
   前記被監視装置を監視する監視装置に対して、所定イベントを送信する時機を通知する通知手順と、
   前記通知手順によって前記所定イベントを送信する時機が通知された場合に、前記取得手順によって取得された前記状態情報を下位の状態情報として包含する最小単位での上位の状態情報の送信を指示する送信指示手順と、
   前記送信指示手順によって前記上位の状態情報の送信指示を受け付けた場合に、前記上位の状態情報を含んだ前記所定イベントを前記監視装置に対して送信する送信手順と、
   をコンピュータに実行させることを特徴とする状態変化通知プログラム。
2. 前記状態変化の検出は、前記構成要素のグループ単位で検出されるものであって、
   前記通知手順は、前記状態情報の送信を前記グループ内に限定して、前記所定イベントを送信する時機を通知することを特徴とする請求項１に記載の状態変化通知プログラム。
3. 前記通知手順は、前記状態情報の送信を前記グループ間で同期をとりつつ、前記所定イベントを送信する時機を通知することを特徴とする請求項２に記載の状態変化通知プログラム。
4. 監視対象である自装置に含まれる構成要素それぞれの状態情報が階層化されている状態情報データベースにおいて、前記構成要素の状態変化の検出によって前記状態情報が変更された場合に、変更された状態情報を取得する取得手段と、
   前記自装置を監視する監視装置に対して、所定イベントを送信する時機を通知する通知手段と、
   前記通知手段によって前記所定イベントを送信する時機が通知された場合に、前記取得手段によって取得された前記状態情報を下位の状態情報として包含する最小単位での上位の状態情報の送信を指示する送信指示手段と、
   前記送信指示手段によって前記上位の状態情報の送信指示を受け付けた場合に、前記上位の状態情報を含んだ前記所定イベントを前記監視装置に対して送信する送信手段と、
   を有することを特徴とする情報処理装置。
5. 監視対象である被監視装置に含まれる構成要素それぞれの状態情報が階層化されている状態情報データベースにおいて、前記構成要素の状態変化の検出によって前記状態情報が変更された場合に、変更された状態情報を取得する取得工程と、
   前記被監視装置を監視する監視装置に対して、所定イベントを送信する時機を通知する通知工程と、
   前記通知工程によって前記所定イベントを送信する時機が通知された場合に、前記取得工程によって取得された前記状態情報を下位の状態情報として包含する最小単位での上位の状態情報の送信を指示する送信指示工程と、
   前記送信指示工程によって前記上位の状態情報の送信指示を受け付けた場合に、前記上位の状態情報を含んだ前記所定イベントを前記監視装置に対して送信する送信工程と、
   を含んだことを特徴とする状態変化通知方法。

Images