監視装置及び監視方法
【課題】ネットワークを介して監視対象に関するメッセージを受信する監視システムにおいて、障害発生に対処する際の効率を向上させる。
【解決手段】監視装置内の連続抑止ユニット３０は、メッセージの提示を抑止する抑止条件と、メッセージの提示の抑止を開始する開始条件と、メッセージの提示の抑止を解除する解除条件とを格納する定義ポリシーデータベース３４と、解除条件を格納する解除条件データベース３６と、連続抑止中の定義ポリシーを格納する連続抑止中データベース３８と、メッセージを提示するか否かを判定する連続抑止判定部３２を備える。連続抑止判定部３２は、メッセージの提示の抑止を開始してから解除するまでの間に、抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止することにより、重要ではないメッセージが提示されるのを抑止する。
【解決手段】監視装置内の連続抑止ユニット３０は、メッセージの提示を抑止する抑止条件と、メッセージの提示の抑止を開始する開始条件と、メッセージの提示の抑止を解除する解除条件とを格納する定義ポリシーデータベース３４と、解除条件を格納する解除条件データベース３６と、連続抑止中の定義ポリシーを格納する連続抑止中データベース３８と、メッセージを提示するか否かを判定する連続抑止判定部３２を備える。連続抑止判定部３２は、メッセージの提示の抑止を開始してから解除するまでの間に、抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止することにより、重要ではないメッセージが提示されるのを抑止する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視技術に関し、特に、ネットワークを介してコンピュータなどの装置を監視する監視装置及び監視方法に関する。
【背景技術】
【０００２】
近年、コンピュータのソフトウェアの多様化及びハードウェアの性能向上に伴い、システムの運用要件が複雑化してきている。このため、コンピュータシステムの運用監視を行う監視装置は、各ソフトウェア及びハードウェアからより多くの情報、例えば情報メッセージ及び障害メッセージなどを取得しなければならなくなっている。そのため、これらのメッセージを統括的に取り扱うために、ソフトウェア及びハードウェアごとに個別に運用される管理ツールを統合的に監視するツール（統合監視システム）が提案されている（例えば、非特許文献１参照）。
【非特許文献１】http://www-6.ibm.com/jp/software/tivoli/products/systems_mgr.html
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このような監視システムにおいては、処理しなければならないメッセージ数が膨大であるため、監視装置の処理速度の低下、あるいは、運用オペレータの負担が増大することによるメッセージ見落としなどの問題が生じる恐れがある。例えば、ログファイルの出力を監視する管理ツールなどにおいて、１度の障害発生で大量のエラーメッセージが出力されて、監視装置に発信されることがあるが、メッセージの内容がそれぞれ少しずつ異なっているような場合もあり、障害を特定して適切な対応を講じることを困難にしている。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、障害発生に対処する際の効率を向上させる技術を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、監視装置に関する。この監視装置は、ネットワークを介して監視対象に関するメッセージを受信する受信部と、前記メッセージを提示する提示部と、前記メッセージの提示を抑止する抑止条件と、前記メッセージの提示の抑止を開始する開始条件と、前記メッセージの提示の抑止を解除する解除条件とを格納したデータベースと、前記データベースを参照して、前記メッセージを前記提示部に提示するか否かを判定する判定部と、を備え、前記判定部は、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする。
【０００６】
監視対象は、例えば、サーバ装置、パーソナルコンピュータなどの端末装置、それらの装置で動作するプロセスなどであってもよい。開始条件と抑止条件は同一であってもよく、この場合、いずれか一方のみがデータベースに格納されてもよい。オペレータに提示する必要のないメッセージの提示を抑止する機能を設けることにより、オペレータの負荷を軽減し、障害への対処の効率を向上させることができる。また、メッセージの提示を抑止する機能を開始する条件と、解除する条件を設定可能とすることにより、より柔軟に条件を設定することができるので、より的確に重要なメッセージを抽出して提示することができる。また、個々のメッセージを独立的に取捨選択するのではなく、一定期間に連続的に発信されたメッセージを集合として抑止することができるので、大量の障害通知をより効果的に処理することができる。
【０００７】
前記開始条件は、前記メッセージに関する条件であってもよい。すなわち、所定の条件に合致したメッセージを受信したことを契機として、メッセージの提示の抑止機能を発現させてもよい。前記データベースは、前記開始条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納してもよく、前記判定部は、前記データベースを参照して、前記開始条件に合致したメッセージを提示するか否かを判定してもよい。すなわち、メッセージの提示の抑止機能を発現させる契機となるメッセージ自身を提示するか否かを設定可能としてもよい。
【０００８】
前記解除条件は、前記メッセージの提示の抑止を開始してからの時間、前記メッセージの提示を抑止した回数、又は前記メッセージに関する条件であってもよい。例えば、メッセージの提示の抑止を開始してから所定の時間が経過するまでの間、メッセージの提示の抑止機能を継続させてもよい。また、メッセージの提示を所定の回数抑止するまでの間、メッセージの提示の抑止機能を継続させてもよい。また、所定の条件に合致したメッセージを受信したことを契機として、メッセージの提示の抑止機能を解除してもよい。前記データベースは、前記解除条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納してもよく、前記判定部は、前記データベースを参照して、前記解除条件に合致したメッセージを提示するか否かを判定してもよい。すなわち、メッセージの提示の抑止機能を解除させる契機となるメッセージ自身を提示するか否かを設定可能としてもよい。
【０００９】
本発明の別の態様は、監視方法に関する。この監視方法は、ネットワークを介して監視対象に関するメッセージを受信するステップと、前記メッセージの提示を抑止する抑止条件を格納したデータベースを参照して、提示の許否を判定するステップと、前記メッセージを提示すると判定されたときに、前記メッセージを提示するステップと、前記メッセージの提示の抑止を開始する開始条件に合致する状態になったときに、前記メッセージの提示の抑止を開始するステップと、前記メッセージの提示の抑止を解除する解除条件に合致する状態になったときに、前記メッセージの提示の抑止を解除するステップと、を含み、前記判定するステップは、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、監視対象に障害が発生したときに効率良く対処する技術を提供することができる。
【発明を実施するための最良の形態】
【００１１】
図１は、監視装置２０の構成を示す。監視装置２０は、監視対象となる端末装置１４ｂやサーバ装置１４ｂなど（以下、「監視対象装置」という）が設けられたネットワークシステム１２ａ、１２ｂ、・・・、を含む監視対象システム１０を監視する。監視対象システム１０において、監視対象装置の異常を検知してメッセージを発信する監視プログラム等が設けられており、そのプログラムに設定された条件に合致する状態が発生すると、監視装置２０にメッセージが送信される。監視装置２０は、監視対象システム１０から発信されたメッセージを取得し、取得したメッセージを記録するとともに、オペレータにメッセージを提示し、障害の発生を通知する。オペレータは、提示されたメッセージの内容を見て、障害に対してなすべき対応の内容を判断する。
【００１２】
障害対応の必要がないような状態であってもメッセージが発信される場合があるし、１つの障害発生で同様のメッセージが大量に発信される場合もある。例えば、ウェブサーバがダウンした場合、そのウェブサーバにアクセス要求が発生するたびにエラーメッセージが発信されることになり、ときには何千何万ものメッセージが短期間に連続して発信されることもある。オペレータは、これらのメッセージの全てを見る必要はなく、障害への対応に必要な情報のみを取得できれば十分である。このように、受信したメッセージを全て通知すると、重要でないメッセージにもオペレータが反応しなければならず、障害対応の効率を下げる恐れがある。また、重要でないメッセージの中に重要なメッセージが埋もれてしまい、見落とされる恐れがある。
【００１３】
また、複数のソフトウェアやハードウェアを監視するときに、１つの障害発生に起因するメッセージが複数の監視対象から発信される場合がある。例えば、ある装置がダウンすると、その装置を監視していたツールがノードダウンを示すメッセージを発信し、その装置で実行されていたプロセスを監視していたツールが、プロセスがダウンした旨のメッセージを発信する。従来、これらのメッセージが、いずれも装置がダウンしたことに起因していることは、オペレータが判断しなければならなかった。
【００１４】
そこで、本実施の形態では、所定の条件に基づいてメッセージを取捨選択し、重要ではないメッセージが連続的に提示／通知されるのを抑止するとともに、メッセージを発生要因などに応じて集約して提示する技術を提案する。以下、前者を「連続抑止機能」、後者を「メッセージ集約機能」と呼ぶ。
【００１５】
監視装置２０は、メッセージ受信部２２、連続抑止ユニット３０、メッセージ集約ユニット４０、メッセージ登録部５０、アラート通知部５６、障害メッセージデータベース５２、及び無視メッセージデータベース５４を含む。これらの構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
メッセージ受信部２２は、監視対象システム１０から発信されたメッセージを受信する。連続抑止ユニット３０は、所定の条件にしたがってメッセージを取捨選択し、不要なメッセージの提示を抑止する。メッセージ集約ユニット４０は、メッセージを発生要因などに応じて集約する。連続抑止ユニット３０により提示が抑止されたメッセージは、メッセージ集約ユニット４０を経由せずにメッセージ登録部５０へ送られてもよい。メッセージ登録部５０は、受信したメッセージを障害メッセージデータベース５２又は無視メッセージデータベース５４に登録する。連続抑止ユニット３０により提示が抑止されたメッセージは無視メッセージデータベース５４に、抑止されずに提示されるメッセージは障害メッセージデータベース５２に登録される。アラート通知部５６は、提示すべきメッセージを受信したときに、メッセージを受信したことをパトランプや音声などにより通知するとともに、メッセージの内容を提示する。
【００１７】
図２は、監視装置２０における処理の流れを概略的に示す。メッセージ受信部２２が監視対象のシステムから障害メッセージを受信すると（Ｓ１０）、連続抑止ユニット３０が、所定の条件にしたがって、メッセージを提示するか否かを判断する（Ｓ１２）。提示すると判断されたメッセージは、さらにメッセージ集約ユニット４０により、発生要因などに応じて集約される（Ｓ１４）。メッセージ登録部５０は、メッセージを障害メッセージデータベース５２又は無視メッセージデータベース５４に登録し（Ｓ１６）、アラート通知部５６は、連続抑止ユニット３０により提示すると判断されたメッセージを通知／提示する（Ｓ１８）。
【００１８】
図３は、連続抑止ユニット３０の内部構成を示す。連続抑止ユニット３０は、連続抑止判定部３２、定義ポリシーデータベース３４、解除条件データベース３６、及び連続抑止中データベース３８を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
【００１９】
定義ポリシーデータベース３４は、受信したメッセージの提示を抑止するか否かを判定するための条件を定義した定義ポリシーを格納する。図４は、定義ポリシーデータベース３４の内部データの例を示す。定義ポリシーデータベース３４には、定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５、及び解除条件番号欄７６が設けられている。定義番号欄７１には、定義ポリシーを一意に識別するための番号が格納される。ＦＲＯＭ欄７２にはメッセージの提示の抑止を開始する開始条件が、ＢＯＤＹ欄７３にはメッセージの提示の抑止を実行する抑止条件が、ＴＯ欄７４にはメッセージの提示の抑止を終了する解除条件が格納され、それぞれに、システムＩＤ欄７７ａ、７７ｂ、及び７７ｃ、メッセージＩＤ欄７８ａ、７８ｂ、及び７８ｃ、ノードＩＤ欄７９ａ、７９ｂ、及び７９ｃ、ノード名欄８０ａ、８０ｂ、及び８０ｃ、曜日欄８１ａ、８１ｂ、及び８１ｃ、時間帯欄８２ａ、８２ｂ、及び８２ｃ、本文（内容）欄８３ａ、８３ｂ、及び８３ｃが設けられている。
【００２０】
システムＩＤ欄７７ａ、７７ｂ、及び７７ｃは、監視対象のシステムを識別するためのＩＤを格納する。メッセージＩＤ欄７８ａ、７８ｂ、及び７８ｃは、メッセージの種類を示すＩＤを格納する。ノードＩＤ欄７９ａ、７９ｂ、及び７９ｃは、監視対象のノードを識別するためのＩＤを格納する。ノード名欄８０ａ、８０ｂ、及び８０ｃは、監視対象のノードの名称を格納する。曜日欄８１ａ、８１ｂ、及び８１ｃは、メッセージが発信された日の曜日に関する条件を格納する。時間帯欄８２ａ、８２ｂ、及び８２ｃは、メッセージが発信された時間帯に関する条件を格納する。本文（内容）欄８３ａ、８３ｂ、及び８３ｃは、メッセージの本文、すなわち内容に関する条件を格納する。
【００２１】
連続抑止判定部３２は、受信したメッセージがこれらの条件に合致するか否かを判定する。ＦＲＯＭ欄７２に合致したメッセージを受信したときは、その定義ポリシーを連続抑止中データベース３８に登録して連続抑止機能を開始させる。ＢＯＤＹ欄７３に合致したメッセージを受信したときは、その定義ポリシーが連続抑止中データベース３８に登録されていれば、すなわち連続抑止中であれば、そのメッセージの提示を抑止する。ＴＯ欄７４に合致したメッセージを受信したときには、その定義ポリシーが連続抑止中データベース３８に登録されていれば、その定義ポリシーを連続抑止中データベース３８から削除し、連続抑止機能を解除する。
【００２２】
通知条件欄７５は、ＦＲＯＭ欄８４、ＢＯＤＹ欄８５、ＴＯ欄８６を含み、それぞれ、ＦＲＯＭ欄７２の開始条件、ＢＯＤＹ欄７３の抑止条件、ＴＯ欄７４の解除条件に合致したメッセージを提示／通知するか否かを格納する。解除条件番号欄７６は、連続抑止処理を解除する条件を示す番号を格納する。解除条件番号に対応する解除条件の内容は、図５に示す解除条件データベース３６に格納される。
【００２３】
解除条件データベース３６は、連続抑止処理を解除する条件を格納する。図５は、解除条件データベース３６の内部データの例を示す。解除条件データベース３６には、解除条件番号欄８７、タイムアウト時間欄８８、最大抑止回数欄８９、及びＴＯ到達欄９０が設けられている。解除条件番号欄８７には、解除条件を一意に識別するための番号が格納される。タイムアウト時間欄８８には、連続抑止処理が開始された後、解除するまでの時間が格納される。最大抑止回数欄８９には、メッセージの提示を抑止する最大の回数が格納される。ＴＯ到達欄９０には、定義ポリシーデータベース３４のＴＯ欄７４に格納された解除条件を適用するか否かが格納される。
【００２４】
連続抑止判定部３２は、連続抑止を開始してからタイムアウト時間欄８８に格納されたタイムアウト時間が経過するか、メッセージの抑止回数が最大抑止回数欄８９に格納された回数に到達するか、ＴＯ欄７４に格納された解除条件に合致するメッセージを受信したときに、連続抑止中データベース３８から該当する定義ポリシーを削除して、連続抑止機能を解除する。
【００２５】
連続抑止中データベース３８は、連続抑止を実行中の定義ポリシーを格納する。図６は、連続抑止中データベース３８の内部データの例を示す。連続抑止中データベース３８には、抑止番号欄９１、定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５、タイムアウト時間欄８８、最大抑止回数欄８９、抑止開始日時欄９２、及び抑止回数欄９３が設けられている。抑止番号欄９１には、連続抑止中の定義ポリシーを識別するための番号が格納される。定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５には、連続抑止が開始された定義ポリシーが、定義ポリシーデータベース３４からコピーされる。タイムアウト時間欄８８、最大抑止回数欄８９には、定義ポリシーデータベース３４の解除条件番号欄７６に設定された解除条件の内容が、解除条件データベース３６からコピーされる。抑止開始日時欄９２には、連続抑止が開始された日時が格納される。抑止回数欄９３は、メッセージの提示が抑止された回数が格納される。
【００２６】
図７は、連続抑止方法の手順を示すフローチャートである。連続抑止判定部３２は、まず、受信したメッセージと定義ポリシーデータベース３４に格納された定義ポリシーをマッチングする（Ｓ２０）。受信したメッセージが、いずれの定義ポリシーとも一致しない場合は（Ｓ２２のＮ）、そのメッセージは抑止されずに提示される（Ｓ４２）。実際には、メッセージ集約ユニット４０により集約されてから提示されることになる。受信したメッセージが、定義ポリシーデータベース３４のＦＲＯＭ欄７２に定義された開始条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みか否かをマッチングし（Ｓ２４）、連続抑止中でなければ（Ｓ２６のＮ）、連続抑止中データベース３８にその定義ポリシーを登録して連続抑止機能を開始する（Ｓ２８）。また、このメッセージを通知するか否かを、定義ポリシーデータベース３４の通知条件欄７５のＦＲＯＭ欄８４を参照して判定し（Ｓ３０）、通知「有」であれば（Ｓ３０のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば（Ｓ３０のＮ）、このメッセージは通知されない。
【００２７】
受信したメッセージが、定義ポリシーデータベース３４のＢＯＤＹ欄７３に定義された抑止条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みであれば（Ｓ２６のＹ）、連続抑止の解除条件が判定され（Ｓ３２）、連続抑止を解除しない場合は（Ｓ３４のＮ）、このメッセージの提示は抑止され、連続抑止中データベース３８の該当する定義ポリシーの抑止回数欄９３がインクリメントされる（Ｓ４０）。連続抑止の解除条件に合致する場合、例えば、タイムアウト時間が経過した場合や最大抑止回数に達した場合は（Ｓ３４のＹ）、連続抑止中データベース３８の該当する定義ポリシーを初期化する（Ｓ３６）。また、このメッセージを提示するか否かを、定義ポリシーデータベース３４又は連続抑止中データベース３８の通知条件欄７５のＴＯ欄８６を参照して判定し（Ｓ３８）、通知「有」であれば（Ｓ３８のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば、このメッセージは通知されない。
【００２８】
受信したメッセージが、定義ポリシーデータベース３４のＴＯ欄７４に定義された解除条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みであれば（Ｓ２６のＹ）、解除条件判定処理（Ｓ３２）において解除条件に合致すると判定されるので、連続抑止が解除され（Ｓ３４のＹ）、連続抑止中データベース３８の該当する定義ポリシーが初期化される（Ｓ３６）。また、このメッセージを提示するか否かを、定義ポリシーデータベース３４又は連続抑止中データベース３８の通知条件欄７５のＴＯ欄８６を参照して判定し（Ｓ３８）、通知「有」であれば（Ｓ３８のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば、このメッセージは通知されない。以上の処理が、定義ポリシーデータベースに格納された全ての定義ポリシーのマッチングが終了する（Ｓ４４のＹ）まで繰り返される。
【００２９】
連続抑止機能の具体的な使用例をいくつか述べる。まず、第１の例として、サーバ装置や端末装置などを自動的に再起動するときの定義ポリシーの例を説明する。サーバや端末などの装置を定期的に再起動させる場合があるが、装置にリブートがかけられてから起動が終了するまでの間、その装置で実行されているべきプロセス等がダウンしているために、プロセスなどを監視しているツールからエラーメッセージが発信される可能性がある。このエラーメッセージは、装置の再起動に起因するものであり、実質的な障害ではないから、オペレータに通知する必要はない。そのため、定義ポリシーデータベース３４のＦＲＯＭ欄７２に、再起動が開始されたときに発信されるメッセージを登録しておき、通知条件欄７５のＦＲＯＭ欄８４を「有」に設定する。また、再起動中に発信される可能性のあるエラーメッセージをＢＯＤＹ欄７３に登録しておく。また、再起動が完了したときに発信されるメッセージをＴＯ欄７４に登録し、通知条件欄７５のＴＯ欄８６を「有」に設定する。これにより、再起動が開始されたことがオペレータに通知され、それ以降、再起動に起因するエラーメッセージの通知が抑止される。また、再起動が完了すると、その旨がオペレータに通知され、連続抑止処理が解除される。
【００３０】
第２の例として、サーバや端末などの装置のＣＰＵに高負荷がかかったときの定義ポリシーの例を説明する。ＣＰＵに継続的に高い負荷がかかっている場合は障害が発生している可能性が高いが、重いプロセスが走った場合など、瞬間的に高い負荷がかかることがある。後者の場合、継続的な高負荷でなければ、とくに問題はないので、オペレータに通知する必要はない。したがって、ＣＰＵの高負荷を示すメッセージを連続的に受信した場合にだけオペレータに通知するような定義ポリシーを設定しておけばよい。定義ポリシーデータベース３４のＦＲＯＭ欄７２及びＢＯＤＹ欄７３に、ＣＰＵの高負荷を示すメッセージを登録し、通知条件欄７５のＦＲＯＭ欄８４に「無」、ＢＯＤＹ欄８５に「無」、ＴＯ欄８６に「有」を設定する。ＴＯ欄７４には何も設定せず、解除条件データベース３６の最大抑止回数欄８９に、例えば「７回」を設定し、タイムアウト時間欄８８に、例えば「５６０秒」を設定する。これにより、ＣＰＵの高負荷を示すメッセージを受信すると、初回はそれを提示せず、同じメッセージを７回受信するまで、メッセージは提示されずに抑止される。最初のメッセージを受信してから５６０秒が経過するまでに、同じメッセージを８回受信すると、そのメッセージがオペレータに提示されるとともに、連続抑止機能が解除される。
【００３１】
第３の例として、ＡＳＰなどで提供されるオンラインプログラムを監視するときの定義ポリシーの例を説明する。インターネットを介してユーザからのアクセスを受け付けるプログラムを監視するツールは、監視するプログラムがダウンすると、そのプログラムにアクセスがあるたびにエラーメッセージを発信する。しかし、オペレータには最初の１回だけメッセージを通知すれば十分である。したがって、定義ポリシーデータベース３４のＦＲＯＭ欄７２及びＢＯＤＹ欄７３に、プログラムがダウンした旨を示すエラーメッセージを登録し、通知条件欄７５のＦＲＯＭ欄８４に「有」、ＢＯＤＹ欄８５に「無」、ＴＯ欄８６に「無」を設定する。ＴＯ欄７４には何も設定せず、解除条件データベース３６のタイムアウト時間欄８８に、十分大きな値、例えば「３６００秒」を設定し、最大抑止回数欄８９には何も設定しない。これにより、プログラムがダウンしたとき、初回のメッセージのみが提示され、以降は全て抑止される。
【００３２】
このように、オペレータにとって必要なメッセージのみを提示し、不要なメッセージの提示を抑止することにより、障害対応の効率を向上させることができる。また、重要なメッセージが見落とされる可能性を低減し、監視の信頼性を向上させることができる。また、開始条件と解除条件を設定可能とすることにより、より柔軟な抑止の形態を設定することができ、提示すべきメッセージを的確に抽出することができる。また、抑止機能の開始と終了を定義し、その間に受信したメッセージを集合として抑止することにより、短期に大量に発信される不要なメッセージを効果的に抑止することができる。
【００３３】
図８は、メッセージ集約ユニット４０の内部構成を示す。メッセージ集約ユニット４０は、障害番号カウンタ４１、メッセージ集約部４２、監視設定データベース４３、監視設定関連付けデータベース４４、ジョブ登録データベース４５、ジョブ登録関連付けデータベース４６、監視設定登録部４７、及びジョブ登録部４８を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
【００３４】
監視設定データベース４３は、監視装置２０が監視する対象に関する情報が格納される。図９は、監視設定データベース４３の内部データの例を示す。監視設定データベース４３には、監視設定番号欄１０１、メッセージＩＤ欄１０２、ノードＩＤ欄１０３、ノード名欄１０４、監視種類欄１０５、監視対象欄１０６、及びその他条件欄１０７が設けられている。監視設定番号欄１０１には、監視設定を識別するための番号が格納される。メッセージＩＤ欄１０２には、メッセージの種別を識別するためにメッセージに付加されるＩＤが格納される。ノードＩＤ欄１０３には、監視対象となるノードを識別するためのＩＤが格納される。ノード名欄１０４には、監視対象となるノードの名称が格納される。監視種類欄１０５には、監視内容の種類が格納される。例えば、「ノード」であればノードダウンが監視され、「プロセス」であればプロセスダウンが監視され、「ログ」であればログ出力の内容が監視される。監視対象欄１０６には、監視対象を具体的に特定するための情報が格納される。例えば、プロセスの監視であればプロセスの名称が、ログの監視であればログの名称が格納される。その他条件欄１０７には、異常と判断するためのしきい値などの情報を格納する。例えば、監視設定番号「３」及び「４」では、ログに「ｅｒｒｏｒ」を含む文字列が出力されるとメッセージが発信される。この文字列には正規表現を指定してもよい。監視設定番号「５」では「Ｃ」ドライブの使用量が「９０％」を超えるとメッセージが発信される。
【００３５】
ジョブ登録データベース４５は、監視対象装置において実行されるジョブの情報を格納する。図１０は、ジョブ登録データベース４５の内部データの例を示す。ジョブ登録データベース４５には、ジョブ登録番号欄１１１、動作環境欄１１２、フレーム欄１１３、ネット欄１１４、ジョブ欄１１５、プログラム欄１１６、スケジュール欄１１７が設けられている。ジョブ登録番号欄１１１には、ジョブ登録を識別するための番号が格納される。動作環境欄１１２は、動作環境を示す情報が格納される。フレーム欄１１３、ネット欄１１４、ジョブ欄１１５には、フレーム、ネット、ジョブに関する情報がそれぞれ格納される。プログラム欄１１６には、実行されるプログラムのファイル名が格納される。スケジュール欄１１７には、ジョブを実行するスケジュールを示す情報が格納される。
【００３６】
監視設定関連付けデータベース４４は、監視設定にしたがって発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図１１は、監視設定関連付けデータベース４４の内部データの例を示す。監視設定関連付けデータベース４４には、監視設定番号欄１２１、関連監視設定番号欄１２２、関連ジョブ登録番号欄１２３、及び時間欄１２４が設けられている。監視設定番号欄１２１には、監視設定データベース４３に登録された監視設定の番号が格納される。関連監視設定番号欄１２２には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄１２３には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、監視設定番号「１」の監視設定、すなわち、ノードＩＤ「ＡＰ１」の「ＡＰサーバ１」がノードダウンしたときに発信されるメッセージＩＤ「ＡＡＡ」のメッセージは、既に受信していた監視設定番号「２、３」のメッセージ及びジョブ登録番号「１」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、所定の条件にしたがって、いずれのメッセージに関連付けられるかが選択されてもよい。この選択のための条件を監視設定関連付けデータベース４４に設定可能としてもよい。例えば、関連付けのための条件に合致した複数のメッセージのうち、最も古いメッセージに関連付けてもよいし、最も新しいメッセージに関連付けてもよいし、優先順位を設定しておいてもよい。時間欄１２４には、メッセージを関連付ける期間が格納される。例えば、監視設定番号「１」に関するメッセージは、それよりも「３００秒」前までに受信していた監視設定番号「２、３」及びジョブ登録番号「１」のメッセージに関連付けられる。３００秒以上前に受信していたメッセージには関連付けられない。
【００３７】
ジョブ登録関連付けデータベース４６は、登録されたジョブを監視するツールから発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図１２は、ジョブ登録関連付けデータベース４６の内部データの例を示す。ジョブ登録関連付けデータベース４６には、ジョブ登録番号欄１３１、関連監視設定番号欄１３２、関連ジョブ登録番号欄１３３、及び時間欄１３４が設けられている。ジョブ登録番号欄１３１には、ジョブ登録データベース４５に登録されたジョブ登録番号が格納される。関連監視設定番号欄１３２には、そのジョブに関するメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄１３３には、そのジョブに関するメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、ジョブ登録番号「１」のジョブ、すなわち、動作環境「ＡＢＣ」、フレーム「ｆｒ００１」、ネット「ｎｔ００１」、ジョブ「ｊｂ００１」、プログラム「/home/apl/bt/jb001.cah」、スケジュール「ｓｊ００１」に関するメッセージは、既に受信していた監視設定番号「１」のメッセージ及びジョブ登録番号「２」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、上述したように、所定の条件にしたがっていずれのメッセージに関連付けられるかが選択されてもよい。時間欄１３４には、メッセージを関連付ける期間が格納される。例えば、ジョブ登録番号「１」に関するメッセージは、それよりも「３００秒」前までに受信していた監視設定番号「１」及びジョブ登録番号「２」のメッセージに関連付けられる。３００秒以上前に受信していたメッセージには関連付けられない。
【００３８】
監視設定登録部４７は、監視設定データベース４３に設定する監視内容を受け付け、監視設定データベース４３に登録する。また、監視設定データベース４３に登録された監視設定に関連する監視設定及びジョブを監視設定関連付けデータベース４４に設定する。ジョブ登録部４８は、ジョブ登録データベース４５に設定するジョブの内容を受け付け、ジョブ登録データベース４５に登録する。また、ジョブ登録データベース４５に登録されたジョブに関連するジョブ及び監視設定をジョブ登録関連付けデータベース４６に設定する。
【００３９】
メッセージ集約部４２は、監視設定関連付けデータベース４４、ジョブ登録関連付けデータベース４６を参照して、受信したメッセージに関連付けるべきメッセージが以前に受信されていたか否かを判定し、受信されていれば、関連のあるメッセージを集約して表示させるために、障害番号カウンタ４１により、既に受信されていたメッセージと同じ障害番号を今回受信したメッセージに付与する。受信されていなければ、障害番号カウンタ４１により新たな障害番号を採番して割り当てる。アラート通知部５６は、メッセージを提示する際に、障害番号とともに提示する。これにより、関連のあるメッセージをオペレータが識別することができる。
【００４０】
図１３は、メッセージ集約方法の手順を示すフローチャートである。メッセージ集約部４２は、取得したメッセージが監視設定に関するものかジョブに関するものかを判断し（Ｓ５０）、監視設定に関するものであれば（Ｓ５０のＹ）、監視設定データベース４３と監視設定関連付けデータベース４４を参照して、該当する監視設定のメッセージに関連付けるべきメッセージの情報を検索する（Ｓ５２）。取得したメッセージがジョブに関するものであれば（Ｓ５０のＮ）、ジョブ登録データベース４５とジョブ登録関連付けデータベース４６を参照して、該当するジョブのメッセージに関連付けるべきメッセージの情報を検索する（Ｓ５４）。関連付けに関する情報が取得できなかった場合（Ｓ５６のＮ）、受信したメッセージに関連付けるべきメッセージはないので、今回受信したメッセージの障害番号を障害番号カウンタ４１により新たに採番してメッセージに付与する（Ｓ６４）。
【００４１】
関連付けに関する情報が取得できた場合（Ｓ５６のＹ）、既に受信していたメッセージに該当するメッセージがあるか否かをマッチングする（Ｓ５８）。該当するメッセージが障害メッセージデータベース５２に登録されていなければ（Ｓ６０のＮ）、今回受信したメッセージの障害番号を障害番号カウンタ４１により新たに採番してメッセージに付与する（Ｓ６４）。該当する障害メッセージが障害メッセージデータベース５２に登録されていれば（Ｓ６０のＹ）、今回受信したメッセージの障害番号を、既に受信していた関連するメッセージの障害番号と同一にする（Ｓ６２）。こうして集約されたメッセージは、メッセージ登録部５０により障害メッセージデータベース５２に登録され、アラート通知部５６により提示／通知される。
【００４２】
図１４（ａ）（ｂ）は、アラート通知部５６により提示されたメッセージ提示画面の例を示す。図１４（ａ）は、メッセージ集約ユニット４０によりメッセージが集約される前の画面例を示す。ここでは、連続抑止ユニット３０により提示が抑止されたメッセージは提示されない。図１４（ｂ）は、メッセージ集約ユニット４０によりメッセージが集約された後の画面例を示す。図１４（ａ）では、メッセージＩＤ「ＢＢＡ」のメッセージには障害番号「００２」が、メッセージＩＤ「ＤＤＤ」には障害番号「００３」が付与されているが、メッセージ集約ユニット４０により、これらのメッセージが関連付けられた結果、同一の障害番号「００２」が付与されて提示されている。これにより、オペレータは、これらのメッセージが同一の障害に起因するものであると推定することができるので、効率よく対応することができる。また、障害の発生要因の特定を支援し、オペレータがより適切な対策を講じることができるようにすることができる。
【００４３】
上述した連続抑止機能とメッセージ集約機能を組み合わせることにより、必要なメッセージを的確に抽出し、発生要因別に集約して提示することができるので、さらに監視業務の効率化を図ることができる。実施の形態では、連続抑止ユニット３０がメッセージを提示するか否かを判断した後、メッセージ集約ユニット４０が関連のあるメッセージを集約したが、これらの順序は逆であってもよいし、同時に並行して行われてもよい。
【００４４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００４５】
【図１】実施の形態に係る監視装置の構成を示す図である。
【図２】監視装置における処理の流れを概略的に示す図である。
【図３】連続抑止ユニットの内部構成を示す図である。
【図４】定義ポリシーデータベースの内部データの例を示す図である。
【図５】解除条件データベースの内部データの例を示す図である。
【図６】連続抑止中データベースの内部データの例を示す図である。
【図７】連続抑止方法の手順を示すフローチャートである。
【図８】メッセージ集約ユニットの内部構成を示す図である。
【図９】監視設定データベースの内部データの例を示す図である。
【図１０】ジョブ登録データベースの内部データの例を示す図である。
【図１１】監視設定関連付けデータベースの内部データの例を示す図である。
【図１２】ジョブ登録関連付けデータベースの内部データの例を示す図である。
【図１３】メッセージ集約方法の手順を示すフローチャートである。
【図１４】図１４（ａ）（ｂ）は、メッセージを提示する画面の例を示す図である。
【符号の説明】
【００４６】
１０ 監視対象システム、２０ 監視装置、２２ メッセージ受信部、３０ 連続抑止ユニット、３２ 連続抑止判定部、３４ 定義ポリシーデータベース、３６ 解除条件データベース、３８ 連続抑止中データベース、４０ メッセージ集約ユニット、４１ 障害番号カウンタ、４２ メッセージ集約部、４３ 監視設定データベース、４４ 監視設定関連付けデータベース、４５ ジョブ登録データベース、４６ ジョブ登録関連付けデータベース、４７ 監視設定登録部、４８ ジョブ登録部、５０ メッセージ登録部、５２ 障害メッセージデータベース、５４ 無視メッセージデータベース、５６ アラート通知部。
【技術分野】
【０００１】
本発明は、監視技術に関し、特に、ネットワークを介してコンピュータなどの装置を監視する監視装置及び監視方法に関する。
【背景技術】
【０００２】
近年、コンピュータのソフトウェアの多様化及びハードウェアの性能向上に伴い、システムの運用要件が複雑化してきている。このため、コンピュータシステムの運用監視を行う監視装置は、各ソフトウェア及びハードウェアからより多くの情報、例えば情報メッセージ及び障害メッセージなどを取得しなければならなくなっている。そのため、これらのメッセージを統括的に取り扱うために、ソフトウェア及びハードウェアごとに個別に運用される管理ツールを統合的に監視するツール（統合監視システム）が提案されている（例えば、非特許文献１参照）。
【非特許文献１】http://www-6.ibm.com/jp/software/tivoli/products/systems_mgr.html
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このような監視システムにおいては、処理しなければならないメッセージ数が膨大であるため、監視装置の処理速度の低下、あるいは、運用オペレータの負担が増大することによるメッセージ見落としなどの問題が生じる恐れがある。例えば、ログファイルの出力を監視する管理ツールなどにおいて、１度の障害発生で大量のエラーメッセージが出力されて、監視装置に発信されることがあるが、メッセージの内容がそれぞれ少しずつ異なっているような場合もあり、障害を特定して適切な対応を講じることを困難にしている。
【０００４】
本発明はこうした状況に鑑みてなされたものであり、その目的は、障害発生に対処する際の効率を向上させる技術を提供することにある。
【課題を解決するための手段】
【０００５】
本発明のある態様は、監視装置に関する。この監視装置は、ネットワークを介して監視対象に関するメッセージを受信する受信部と、前記メッセージを提示する提示部と、前記メッセージの提示を抑止する抑止条件と、前記メッセージの提示の抑止を開始する開始条件と、前記メッセージの提示の抑止を解除する解除条件とを格納したデータベースと、前記データベースを参照して、前記メッセージを前記提示部に提示するか否かを判定する判定部と、を備え、前記判定部は、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする。
【０００６】
監視対象は、例えば、サーバ装置、パーソナルコンピュータなどの端末装置、それらの装置で動作するプロセスなどであってもよい。開始条件と抑止条件は同一であってもよく、この場合、いずれか一方のみがデータベースに格納されてもよい。オペレータに提示する必要のないメッセージの提示を抑止する機能を設けることにより、オペレータの負荷を軽減し、障害への対処の効率を向上させることができる。また、メッセージの提示を抑止する機能を開始する条件と、解除する条件を設定可能とすることにより、より柔軟に条件を設定することができるので、より的確に重要なメッセージを抽出して提示することができる。また、個々のメッセージを独立的に取捨選択するのではなく、一定期間に連続的に発信されたメッセージを集合として抑止することができるので、大量の障害通知をより効果的に処理することができる。
【０００７】
前記開始条件は、前記メッセージに関する条件であってもよい。すなわち、所定の条件に合致したメッセージを受信したことを契機として、メッセージの提示の抑止機能を発現させてもよい。前記データベースは、前記開始条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納してもよく、前記判定部は、前記データベースを参照して、前記開始条件に合致したメッセージを提示するか否かを判定してもよい。すなわち、メッセージの提示の抑止機能を発現させる契機となるメッセージ自身を提示するか否かを設定可能としてもよい。
【０００８】
前記解除条件は、前記メッセージの提示の抑止を開始してからの時間、前記メッセージの提示を抑止した回数、又は前記メッセージに関する条件であってもよい。例えば、メッセージの提示の抑止を開始してから所定の時間が経過するまでの間、メッセージの提示の抑止機能を継続させてもよい。また、メッセージの提示を所定の回数抑止するまでの間、メッセージの提示の抑止機能を継続させてもよい。また、所定の条件に合致したメッセージを受信したことを契機として、メッセージの提示の抑止機能を解除してもよい。前記データベースは、前記解除条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納してもよく、前記判定部は、前記データベースを参照して、前記解除条件に合致したメッセージを提示するか否かを判定してもよい。すなわち、メッセージの提示の抑止機能を解除させる契機となるメッセージ自身を提示するか否かを設定可能としてもよい。
【０００９】
本発明の別の態様は、監視方法に関する。この監視方法は、ネットワークを介して監視対象に関するメッセージを受信するステップと、前記メッセージの提示を抑止する抑止条件を格納したデータベースを参照して、提示の許否を判定するステップと、前記メッセージを提示すると判定されたときに、前記メッセージを提示するステップと、前記メッセージの提示の抑止を開始する開始条件に合致する状態になったときに、前記メッセージの提示の抑止を開始するステップと、前記メッセージの提示の抑止を解除する解除条件に合致する状態になったときに、前記メッセージの提示の抑止を解除するステップと、を含み、前記判定するステップは、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、監視対象に障害が発生したときに効率良く対処する技術を提供することができる。
【発明を実施するための最良の形態】
【００１１】
図１は、監視装置２０の構成を示す。監視装置２０は、監視対象となる端末装置１４ｂやサーバ装置１４ｂなど（以下、「監視対象装置」という）が設けられたネットワークシステム１２ａ、１２ｂ、・・・、を含む監視対象システム１０を監視する。監視対象システム１０において、監視対象装置の異常を検知してメッセージを発信する監視プログラム等が設けられており、そのプログラムに設定された条件に合致する状態が発生すると、監視装置２０にメッセージが送信される。監視装置２０は、監視対象システム１０から発信されたメッセージを取得し、取得したメッセージを記録するとともに、オペレータにメッセージを提示し、障害の発生を通知する。オペレータは、提示されたメッセージの内容を見て、障害に対してなすべき対応の内容を判断する。
【００１２】
障害対応の必要がないような状態であってもメッセージが発信される場合があるし、１つの障害発生で同様のメッセージが大量に発信される場合もある。例えば、ウェブサーバがダウンした場合、そのウェブサーバにアクセス要求が発生するたびにエラーメッセージが発信されることになり、ときには何千何万ものメッセージが短期間に連続して発信されることもある。オペレータは、これらのメッセージの全てを見る必要はなく、障害への対応に必要な情報のみを取得できれば十分である。このように、受信したメッセージを全て通知すると、重要でないメッセージにもオペレータが反応しなければならず、障害対応の効率を下げる恐れがある。また、重要でないメッセージの中に重要なメッセージが埋もれてしまい、見落とされる恐れがある。
【００１３】
また、複数のソフトウェアやハードウェアを監視するときに、１つの障害発生に起因するメッセージが複数の監視対象から発信される場合がある。例えば、ある装置がダウンすると、その装置を監視していたツールがノードダウンを示すメッセージを発信し、その装置で実行されていたプロセスを監視していたツールが、プロセスがダウンした旨のメッセージを発信する。従来、これらのメッセージが、いずれも装置がダウンしたことに起因していることは、オペレータが判断しなければならなかった。
【００１４】
そこで、本実施の形態では、所定の条件に基づいてメッセージを取捨選択し、重要ではないメッセージが連続的に提示／通知されるのを抑止するとともに、メッセージを発生要因などに応じて集約して提示する技術を提案する。以下、前者を「連続抑止機能」、後者を「メッセージ集約機能」と呼ぶ。
【００１５】
監視装置２０は、メッセージ受信部２２、連続抑止ユニット３０、メッセージ集約ユニット４０、メッセージ登録部５０、アラート通知部５６、障害メッセージデータベース５２、及び無視メッセージデータベース５４を含む。これらの構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
メッセージ受信部２２は、監視対象システム１０から発信されたメッセージを受信する。連続抑止ユニット３０は、所定の条件にしたがってメッセージを取捨選択し、不要なメッセージの提示を抑止する。メッセージ集約ユニット４０は、メッセージを発生要因などに応じて集約する。連続抑止ユニット３０により提示が抑止されたメッセージは、メッセージ集約ユニット４０を経由せずにメッセージ登録部５０へ送られてもよい。メッセージ登録部５０は、受信したメッセージを障害メッセージデータベース５２又は無視メッセージデータベース５４に登録する。連続抑止ユニット３０により提示が抑止されたメッセージは無視メッセージデータベース５４に、抑止されずに提示されるメッセージは障害メッセージデータベース５２に登録される。アラート通知部５６は、提示すべきメッセージを受信したときに、メッセージを受信したことをパトランプや音声などにより通知するとともに、メッセージの内容を提示する。
【００１７】
図２は、監視装置２０における処理の流れを概略的に示す。メッセージ受信部２２が監視対象のシステムから障害メッセージを受信すると（Ｓ１０）、連続抑止ユニット３０が、所定の条件にしたがって、メッセージを提示するか否かを判断する（Ｓ１２）。提示すると判断されたメッセージは、さらにメッセージ集約ユニット４０により、発生要因などに応じて集約される（Ｓ１４）。メッセージ登録部５０は、メッセージを障害メッセージデータベース５２又は無視メッセージデータベース５４に登録し（Ｓ１６）、アラート通知部５６は、連続抑止ユニット３０により提示すると判断されたメッセージを通知／提示する（Ｓ１８）。
【００１８】
図３は、連続抑止ユニット３０の内部構成を示す。連続抑止ユニット３０は、連続抑止判定部３２、定義ポリシーデータベース３４、解除条件データベース３６、及び連続抑止中データベース３８を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
【００１９】
定義ポリシーデータベース３４は、受信したメッセージの提示を抑止するか否かを判定するための条件を定義した定義ポリシーを格納する。図４は、定義ポリシーデータベース３４の内部データの例を示す。定義ポリシーデータベース３４には、定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５、及び解除条件番号欄７６が設けられている。定義番号欄７１には、定義ポリシーを一意に識別するための番号が格納される。ＦＲＯＭ欄７２にはメッセージの提示の抑止を開始する開始条件が、ＢＯＤＹ欄７３にはメッセージの提示の抑止を実行する抑止条件が、ＴＯ欄７４にはメッセージの提示の抑止を終了する解除条件が格納され、それぞれに、システムＩＤ欄７７ａ、７７ｂ、及び７７ｃ、メッセージＩＤ欄７８ａ、７８ｂ、及び７８ｃ、ノードＩＤ欄７９ａ、７９ｂ、及び７９ｃ、ノード名欄８０ａ、８０ｂ、及び８０ｃ、曜日欄８１ａ、８１ｂ、及び８１ｃ、時間帯欄８２ａ、８２ｂ、及び８２ｃ、本文（内容）欄８３ａ、８３ｂ、及び８３ｃが設けられている。
【００２０】
システムＩＤ欄７７ａ、７７ｂ、及び７７ｃは、監視対象のシステムを識別するためのＩＤを格納する。メッセージＩＤ欄７８ａ、７８ｂ、及び７８ｃは、メッセージの種類を示すＩＤを格納する。ノードＩＤ欄７９ａ、７９ｂ、及び７９ｃは、監視対象のノードを識別するためのＩＤを格納する。ノード名欄８０ａ、８０ｂ、及び８０ｃは、監視対象のノードの名称を格納する。曜日欄８１ａ、８１ｂ、及び８１ｃは、メッセージが発信された日の曜日に関する条件を格納する。時間帯欄８２ａ、８２ｂ、及び８２ｃは、メッセージが発信された時間帯に関する条件を格納する。本文（内容）欄８３ａ、８３ｂ、及び８３ｃは、メッセージの本文、すなわち内容に関する条件を格納する。
【００２１】
連続抑止判定部３２は、受信したメッセージがこれらの条件に合致するか否かを判定する。ＦＲＯＭ欄７２に合致したメッセージを受信したときは、その定義ポリシーを連続抑止中データベース３８に登録して連続抑止機能を開始させる。ＢＯＤＹ欄７３に合致したメッセージを受信したときは、その定義ポリシーが連続抑止中データベース３８に登録されていれば、すなわち連続抑止中であれば、そのメッセージの提示を抑止する。ＴＯ欄７４に合致したメッセージを受信したときには、その定義ポリシーが連続抑止中データベース３８に登録されていれば、その定義ポリシーを連続抑止中データベース３８から削除し、連続抑止機能を解除する。
【００２２】
通知条件欄７５は、ＦＲＯＭ欄８４、ＢＯＤＹ欄８５、ＴＯ欄８６を含み、それぞれ、ＦＲＯＭ欄７２の開始条件、ＢＯＤＹ欄７３の抑止条件、ＴＯ欄７４の解除条件に合致したメッセージを提示／通知するか否かを格納する。解除条件番号欄７６は、連続抑止処理を解除する条件を示す番号を格納する。解除条件番号に対応する解除条件の内容は、図５に示す解除条件データベース３６に格納される。
【００２３】
解除条件データベース３６は、連続抑止処理を解除する条件を格納する。図５は、解除条件データベース３６の内部データの例を示す。解除条件データベース３６には、解除条件番号欄８７、タイムアウト時間欄８８、最大抑止回数欄８９、及びＴＯ到達欄９０が設けられている。解除条件番号欄８７には、解除条件を一意に識別するための番号が格納される。タイムアウト時間欄８８には、連続抑止処理が開始された後、解除するまでの時間が格納される。最大抑止回数欄８９には、メッセージの提示を抑止する最大の回数が格納される。ＴＯ到達欄９０には、定義ポリシーデータベース３４のＴＯ欄７４に格納された解除条件を適用するか否かが格納される。
【００２４】
連続抑止判定部３２は、連続抑止を開始してからタイムアウト時間欄８８に格納されたタイムアウト時間が経過するか、メッセージの抑止回数が最大抑止回数欄８９に格納された回数に到達するか、ＴＯ欄７４に格納された解除条件に合致するメッセージを受信したときに、連続抑止中データベース３８から該当する定義ポリシーを削除して、連続抑止機能を解除する。
【００２５】
連続抑止中データベース３８は、連続抑止を実行中の定義ポリシーを格納する。図６は、連続抑止中データベース３８の内部データの例を示す。連続抑止中データベース３８には、抑止番号欄９１、定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５、タイムアウト時間欄８８、最大抑止回数欄８９、抑止開始日時欄９２、及び抑止回数欄９３が設けられている。抑止番号欄９１には、連続抑止中の定義ポリシーを識別するための番号が格納される。定義番号欄７１、ＦＲＯＭ欄７２、ＢＯＤＹ欄７３、ＴＯ欄７４、通知条件欄７５には、連続抑止が開始された定義ポリシーが、定義ポリシーデータベース３４からコピーされる。タイムアウト時間欄８８、最大抑止回数欄８９には、定義ポリシーデータベース３４の解除条件番号欄７６に設定された解除条件の内容が、解除条件データベース３６からコピーされる。抑止開始日時欄９２には、連続抑止が開始された日時が格納される。抑止回数欄９３は、メッセージの提示が抑止された回数が格納される。
【００２６】
図７は、連続抑止方法の手順を示すフローチャートである。連続抑止判定部３２は、まず、受信したメッセージと定義ポリシーデータベース３４に格納された定義ポリシーをマッチングする（Ｓ２０）。受信したメッセージが、いずれの定義ポリシーとも一致しない場合は（Ｓ２２のＮ）、そのメッセージは抑止されずに提示される（Ｓ４２）。実際には、メッセージ集約ユニット４０により集約されてから提示されることになる。受信したメッセージが、定義ポリシーデータベース３４のＦＲＯＭ欄７２に定義された開始条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みか否かをマッチングし（Ｓ２４）、連続抑止中でなければ（Ｓ２６のＮ）、連続抑止中データベース３８にその定義ポリシーを登録して連続抑止機能を開始する（Ｓ２８）。また、このメッセージを通知するか否かを、定義ポリシーデータベース３４の通知条件欄７５のＦＲＯＭ欄８４を参照して判定し（Ｓ３０）、通知「有」であれば（Ｓ３０のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば（Ｓ３０のＮ）、このメッセージは通知されない。
【００２７】
受信したメッセージが、定義ポリシーデータベース３４のＢＯＤＹ欄７３に定義された抑止条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みであれば（Ｓ２６のＹ）、連続抑止の解除条件が判定され（Ｓ３２）、連続抑止を解除しない場合は（Ｓ３４のＮ）、このメッセージの提示は抑止され、連続抑止中データベース３８の該当する定義ポリシーの抑止回数欄９３がインクリメントされる（Ｓ４０）。連続抑止の解除条件に合致する場合、例えば、タイムアウト時間が経過した場合や最大抑止回数に達した場合は（Ｓ３４のＹ）、連続抑止中データベース３８の該当する定義ポリシーを初期化する（Ｓ３６）。また、このメッセージを提示するか否かを、定義ポリシーデータベース３４又は連続抑止中データベース３８の通知条件欄７５のＴＯ欄８６を参照して判定し（Ｓ３８）、通知「有」であれば（Ｓ３８のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば、このメッセージは通知されない。
【００２８】
受信したメッセージが、定義ポリシーデータベース３４のＴＯ欄７４に定義された解除条件に一致する場合（Ｓ２２のＹ）、その定義ポリシーが連続抑止中データベース３８に登録済みであれば（Ｓ２６のＹ）、解除条件判定処理（Ｓ３２）において解除条件に合致すると判定されるので、連続抑止が解除され（Ｓ３４のＹ）、連続抑止中データベース３８の該当する定義ポリシーが初期化される（Ｓ３６）。また、このメッセージを提示するか否かを、定義ポリシーデータベース３４又は連続抑止中データベース３８の通知条件欄７５のＴＯ欄８６を参照して判定し（Ｓ３８）、通知「有」であれば（Ｓ３８のＹ）、メッセージを通知する（Ｓ４２）。通知「無」であれば、このメッセージは通知されない。以上の処理が、定義ポリシーデータベースに格納された全ての定義ポリシーのマッチングが終了する（Ｓ４４のＹ）まで繰り返される。
【００２９】
連続抑止機能の具体的な使用例をいくつか述べる。まず、第１の例として、サーバ装置や端末装置などを自動的に再起動するときの定義ポリシーの例を説明する。サーバや端末などの装置を定期的に再起動させる場合があるが、装置にリブートがかけられてから起動が終了するまでの間、その装置で実行されているべきプロセス等がダウンしているために、プロセスなどを監視しているツールからエラーメッセージが発信される可能性がある。このエラーメッセージは、装置の再起動に起因するものであり、実質的な障害ではないから、オペレータに通知する必要はない。そのため、定義ポリシーデータベース３４のＦＲＯＭ欄７２に、再起動が開始されたときに発信されるメッセージを登録しておき、通知条件欄７５のＦＲＯＭ欄８４を「有」に設定する。また、再起動中に発信される可能性のあるエラーメッセージをＢＯＤＹ欄７３に登録しておく。また、再起動が完了したときに発信されるメッセージをＴＯ欄７４に登録し、通知条件欄７５のＴＯ欄８６を「有」に設定する。これにより、再起動が開始されたことがオペレータに通知され、それ以降、再起動に起因するエラーメッセージの通知が抑止される。また、再起動が完了すると、その旨がオペレータに通知され、連続抑止処理が解除される。
【００３０】
第２の例として、サーバや端末などの装置のＣＰＵに高負荷がかかったときの定義ポリシーの例を説明する。ＣＰＵに継続的に高い負荷がかかっている場合は障害が発生している可能性が高いが、重いプロセスが走った場合など、瞬間的に高い負荷がかかることがある。後者の場合、継続的な高負荷でなければ、とくに問題はないので、オペレータに通知する必要はない。したがって、ＣＰＵの高負荷を示すメッセージを連続的に受信した場合にだけオペレータに通知するような定義ポリシーを設定しておけばよい。定義ポリシーデータベース３４のＦＲＯＭ欄７２及びＢＯＤＹ欄７３に、ＣＰＵの高負荷を示すメッセージを登録し、通知条件欄７５のＦＲＯＭ欄８４に「無」、ＢＯＤＹ欄８５に「無」、ＴＯ欄８６に「有」を設定する。ＴＯ欄７４には何も設定せず、解除条件データベース３６の最大抑止回数欄８９に、例えば「７回」を設定し、タイムアウト時間欄８８に、例えば「５６０秒」を設定する。これにより、ＣＰＵの高負荷を示すメッセージを受信すると、初回はそれを提示せず、同じメッセージを７回受信するまで、メッセージは提示されずに抑止される。最初のメッセージを受信してから５６０秒が経過するまでに、同じメッセージを８回受信すると、そのメッセージがオペレータに提示されるとともに、連続抑止機能が解除される。
【００３１】
第３の例として、ＡＳＰなどで提供されるオンラインプログラムを監視するときの定義ポリシーの例を説明する。インターネットを介してユーザからのアクセスを受け付けるプログラムを監視するツールは、監視するプログラムがダウンすると、そのプログラムにアクセスがあるたびにエラーメッセージを発信する。しかし、オペレータには最初の１回だけメッセージを通知すれば十分である。したがって、定義ポリシーデータベース３４のＦＲＯＭ欄７２及びＢＯＤＹ欄７３に、プログラムがダウンした旨を示すエラーメッセージを登録し、通知条件欄７５のＦＲＯＭ欄８４に「有」、ＢＯＤＹ欄８５に「無」、ＴＯ欄８６に「無」を設定する。ＴＯ欄７４には何も設定せず、解除条件データベース３６のタイムアウト時間欄８８に、十分大きな値、例えば「３６００秒」を設定し、最大抑止回数欄８９には何も設定しない。これにより、プログラムがダウンしたとき、初回のメッセージのみが提示され、以降は全て抑止される。
【００３２】
このように、オペレータにとって必要なメッセージのみを提示し、不要なメッセージの提示を抑止することにより、障害対応の効率を向上させることができる。また、重要なメッセージが見落とされる可能性を低減し、監視の信頼性を向上させることができる。また、開始条件と解除条件を設定可能とすることにより、より柔軟な抑止の形態を設定することができ、提示すべきメッセージを的確に抽出することができる。また、抑止機能の開始と終了を定義し、その間に受信したメッセージを集合として抑止することにより、短期に大量に発信される不要なメッセージを効果的に抑止することができる。
【００３３】
図８は、メッセージ集約ユニット４０の内部構成を示す。メッセージ集約ユニット４０は、障害番号カウンタ４１、メッセージ集約部４２、監視設定データベース４３、監視設定関連付けデータベース４４、ジョブ登録データベース４５、ジョブ登録関連付けデータベース４６、監視設定登録部４７、及びジョブ登録部４８を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
【００３４】
監視設定データベース４３は、監視装置２０が監視する対象に関する情報が格納される。図９は、監視設定データベース４３の内部データの例を示す。監視設定データベース４３には、監視設定番号欄１０１、メッセージＩＤ欄１０２、ノードＩＤ欄１０３、ノード名欄１０４、監視種類欄１０５、監視対象欄１０６、及びその他条件欄１０７が設けられている。監視設定番号欄１０１には、監視設定を識別するための番号が格納される。メッセージＩＤ欄１０２には、メッセージの種別を識別するためにメッセージに付加されるＩＤが格納される。ノードＩＤ欄１０３には、監視対象となるノードを識別するためのＩＤが格納される。ノード名欄１０４には、監視対象となるノードの名称が格納される。監視種類欄１０５には、監視内容の種類が格納される。例えば、「ノード」であればノードダウンが監視され、「プロセス」であればプロセスダウンが監視され、「ログ」であればログ出力の内容が監視される。監視対象欄１０６には、監視対象を具体的に特定するための情報が格納される。例えば、プロセスの監視であればプロセスの名称が、ログの監視であればログの名称が格納される。その他条件欄１０７には、異常と判断するためのしきい値などの情報を格納する。例えば、監視設定番号「３」及び「４」では、ログに「ｅｒｒｏｒ」を含む文字列が出力されるとメッセージが発信される。この文字列には正規表現を指定してもよい。監視設定番号「５」では「Ｃ」ドライブの使用量が「９０％」を超えるとメッセージが発信される。
【００３５】
ジョブ登録データベース４５は、監視対象装置において実行されるジョブの情報を格納する。図１０は、ジョブ登録データベース４５の内部データの例を示す。ジョブ登録データベース４５には、ジョブ登録番号欄１１１、動作環境欄１１２、フレーム欄１１３、ネット欄１１４、ジョブ欄１１５、プログラム欄１１６、スケジュール欄１１７が設けられている。ジョブ登録番号欄１１１には、ジョブ登録を識別するための番号が格納される。動作環境欄１１２は、動作環境を示す情報が格納される。フレーム欄１１３、ネット欄１１４、ジョブ欄１１５には、フレーム、ネット、ジョブに関する情報がそれぞれ格納される。プログラム欄１１６には、実行されるプログラムのファイル名が格納される。スケジュール欄１１７には、ジョブを実行するスケジュールを示す情報が格納される。
【００３６】
監視設定関連付けデータベース４４は、監視設定にしたがって発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図１１は、監視設定関連付けデータベース４４の内部データの例を示す。監視設定関連付けデータベース４４には、監視設定番号欄１２１、関連監視設定番号欄１２２、関連ジョブ登録番号欄１２３、及び時間欄１２４が設けられている。監視設定番号欄１２１には、監視設定データベース４３に登録された監視設定の番号が格納される。関連監視設定番号欄１２２には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄１２３には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、監視設定番号「１」の監視設定、すなわち、ノードＩＤ「ＡＰ１」の「ＡＰサーバ１」がノードダウンしたときに発信されるメッセージＩＤ「ＡＡＡ」のメッセージは、既に受信していた監視設定番号「２、３」のメッセージ及びジョブ登録番号「１」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、所定の条件にしたがって、いずれのメッセージに関連付けられるかが選択されてもよい。この選択のための条件を監視設定関連付けデータベース４４に設定可能としてもよい。例えば、関連付けのための条件に合致した複数のメッセージのうち、最も古いメッセージに関連付けてもよいし、最も新しいメッセージに関連付けてもよいし、優先順位を設定しておいてもよい。時間欄１２４には、メッセージを関連付ける期間が格納される。例えば、監視設定番号「１」に関するメッセージは、それよりも「３００秒」前までに受信していた監視設定番号「２、３」及びジョブ登録番号「１」のメッセージに関連付けられる。３００秒以上前に受信していたメッセージには関連付けられない。
【００３７】
ジョブ登録関連付けデータベース４６は、登録されたジョブを監視するツールから発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図１２は、ジョブ登録関連付けデータベース４６の内部データの例を示す。ジョブ登録関連付けデータベース４６には、ジョブ登録番号欄１３１、関連監視設定番号欄１３２、関連ジョブ登録番号欄１３３、及び時間欄１３４が設けられている。ジョブ登録番号欄１３１には、ジョブ登録データベース４５に登録されたジョブ登録番号が格納される。関連監視設定番号欄１３２には、そのジョブに関するメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄１３３には、そのジョブに関するメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、ジョブ登録番号「１」のジョブ、すなわち、動作環境「ＡＢＣ」、フレーム「ｆｒ００１」、ネット「ｎｔ００１」、ジョブ「ｊｂ００１」、プログラム「/home/apl/bt/jb001.cah」、スケジュール「ｓｊ００１」に関するメッセージは、既に受信していた監視設定番号「１」のメッセージ及びジョブ登録番号「２」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、上述したように、所定の条件にしたがっていずれのメッセージに関連付けられるかが選択されてもよい。時間欄１３４には、メッセージを関連付ける期間が格納される。例えば、ジョブ登録番号「１」に関するメッセージは、それよりも「３００秒」前までに受信していた監視設定番号「１」及びジョブ登録番号「２」のメッセージに関連付けられる。３００秒以上前に受信していたメッセージには関連付けられない。
【００３８】
監視設定登録部４７は、監視設定データベース４３に設定する監視内容を受け付け、監視設定データベース４３に登録する。また、監視設定データベース４３に登録された監視設定に関連する監視設定及びジョブを監視設定関連付けデータベース４４に設定する。ジョブ登録部４８は、ジョブ登録データベース４５に設定するジョブの内容を受け付け、ジョブ登録データベース４５に登録する。また、ジョブ登録データベース４５に登録されたジョブに関連するジョブ及び監視設定をジョブ登録関連付けデータベース４６に設定する。
【００３９】
メッセージ集約部４２は、監視設定関連付けデータベース４４、ジョブ登録関連付けデータベース４６を参照して、受信したメッセージに関連付けるべきメッセージが以前に受信されていたか否かを判定し、受信されていれば、関連のあるメッセージを集約して表示させるために、障害番号カウンタ４１により、既に受信されていたメッセージと同じ障害番号を今回受信したメッセージに付与する。受信されていなければ、障害番号カウンタ４１により新たな障害番号を採番して割り当てる。アラート通知部５６は、メッセージを提示する際に、障害番号とともに提示する。これにより、関連のあるメッセージをオペレータが識別することができる。
【００４０】
図１３は、メッセージ集約方法の手順を示すフローチャートである。メッセージ集約部４２は、取得したメッセージが監視設定に関するものかジョブに関するものかを判断し（Ｓ５０）、監視設定に関するものであれば（Ｓ５０のＹ）、監視設定データベース４３と監視設定関連付けデータベース４４を参照して、該当する監視設定のメッセージに関連付けるべきメッセージの情報を検索する（Ｓ５２）。取得したメッセージがジョブに関するものであれば（Ｓ５０のＮ）、ジョブ登録データベース４５とジョブ登録関連付けデータベース４６を参照して、該当するジョブのメッセージに関連付けるべきメッセージの情報を検索する（Ｓ５４）。関連付けに関する情報が取得できなかった場合（Ｓ５６のＮ）、受信したメッセージに関連付けるべきメッセージはないので、今回受信したメッセージの障害番号を障害番号カウンタ４１により新たに採番してメッセージに付与する（Ｓ６４）。
【００４１】
関連付けに関する情報が取得できた場合（Ｓ５６のＹ）、既に受信していたメッセージに該当するメッセージがあるか否かをマッチングする（Ｓ５８）。該当するメッセージが障害メッセージデータベース５２に登録されていなければ（Ｓ６０のＮ）、今回受信したメッセージの障害番号を障害番号カウンタ４１により新たに採番してメッセージに付与する（Ｓ６４）。該当する障害メッセージが障害メッセージデータベース５２に登録されていれば（Ｓ６０のＹ）、今回受信したメッセージの障害番号を、既に受信していた関連するメッセージの障害番号と同一にする（Ｓ６２）。こうして集約されたメッセージは、メッセージ登録部５０により障害メッセージデータベース５２に登録され、アラート通知部５６により提示／通知される。
【００４２】
図１４（ａ）（ｂ）は、アラート通知部５６により提示されたメッセージ提示画面の例を示す。図１４（ａ）は、メッセージ集約ユニット４０によりメッセージが集約される前の画面例を示す。ここでは、連続抑止ユニット３０により提示が抑止されたメッセージは提示されない。図１４（ｂ）は、メッセージ集約ユニット４０によりメッセージが集約された後の画面例を示す。図１４（ａ）では、メッセージＩＤ「ＢＢＡ」のメッセージには障害番号「００２」が、メッセージＩＤ「ＤＤＤ」には障害番号「００３」が付与されているが、メッセージ集約ユニット４０により、これらのメッセージが関連付けられた結果、同一の障害番号「００２」が付与されて提示されている。これにより、オペレータは、これらのメッセージが同一の障害に起因するものであると推定することができるので、効率よく対応することができる。また、障害の発生要因の特定を支援し、オペレータがより適切な対策を講じることができるようにすることができる。
【００４３】
上述した連続抑止機能とメッセージ集約機能を組み合わせることにより、必要なメッセージを的確に抽出し、発生要因別に集約して提示することができるので、さらに監視業務の効率化を図ることができる。実施の形態では、連続抑止ユニット３０がメッセージを提示するか否かを判断した後、メッセージ集約ユニット４０が関連のあるメッセージを集約したが、これらの順序は逆であってもよいし、同時に並行して行われてもよい。
【００４４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【図面の簡単な説明】
【００４５】
【図１】実施の形態に係る監視装置の構成を示す図である。
【図２】監視装置における処理の流れを概略的に示す図である。
【図３】連続抑止ユニットの内部構成を示す図である。
【図４】定義ポリシーデータベースの内部データの例を示す図である。
【図５】解除条件データベースの内部データの例を示す図である。
【図６】連続抑止中データベースの内部データの例を示す図である。
【図７】連続抑止方法の手順を示すフローチャートである。
【図８】メッセージ集約ユニットの内部構成を示す図である。
【図９】監視設定データベースの内部データの例を示す図である。
【図１０】ジョブ登録データベースの内部データの例を示す図である。
【図１１】監視設定関連付けデータベースの内部データの例を示す図である。
【図１２】ジョブ登録関連付けデータベースの内部データの例を示す図である。
【図１３】メッセージ集約方法の手順を示すフローチャートである。
【図１４】図１４（ａ）（ｂ）は、メッセージを提示する画面の例を示す図である。
【符号の説明】
【００４６】
１０ 監視対象システム、２０ 監視装置、２２ メッセージ受信部、３０ 連続抑止ユニット、３２ 連続抑止判定部、３４ 定義ポリシーデータベース、３６ 解除条件データベース、３８ 連続抑止中データベース、４０ メッセージ集約ユニット、４１ 障害番号カウンタ、４２ メッセージ集約部、４３ 監視設定データベース、４４ 監視設定関連付けデータベース、４５ ジョブ登録データベース、４６ ジョブ登録関連付けデータベース、４７ 監視設定登録部、４８ ジョブ登録部、５０ メッセージ登録部、５２ 障害メッセージデータベース、５４ 無視メッセージデータベース、５６ アラート通知部。
【特許請求の範囲】
【請求項１】
ネットワークを介して監視対象に関するメッセージを受信する受信部と、
前記メッセージを提示する提示部と、
前記メッセージの提示を抑止する抑止条件と、前記メッセージの提示の抑止を開始する開始条件と、前記メッセージの提示の抑止を解除する解除条件とを格納したデータベースと、
前記データベースを参照して、前記メッセージを前記提示部に提示するか否かを判定する判定部と、を備え、
前記判定部は、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする監視装置。
【請求項２】
前記開始条件は、前記メッセージに関する条件であることを特徴とする請求項１に記載の監視装置。
【請求項３】
前記データベースは、前記開始条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納し、
前記判定部は、前記データベースを参照して、前記開始条件に合致したメッセージを提示するか否かを判定することを特徴とする請求項２に記載の監視装置。
【請求項４】
前記解除条件は、前記メッセージの提示の抑止を開始してからの時間、前記メッセージの提示を抑止した回数、又は前記メッセージに関する条件であることを特徴とする請求項１から３のいずれかに記載の監視装置。
【請求項５】
前記データベースは、前記解除条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納し、
前記判定部は、前記データベースを参照して、前記解除条件に合致したメッセージを提示するか否かを判定することを特徴とする請求項４に記載の監視装置。
【請求項６】
ネットワークを介して監視対象に関するメッセージを受信するステップと、
前記メッセージの提示を抑止する抑止条件を格納したデータベースを参照して、提示の許否を判定するステップと、
前記メッセージを提示すると判定されたときに、前記メッセージを提示するステップと、
前記メッセージの提示の抑止を開始する開始条件に合致する状態になったときに、前記メッセージの提示の抑止を開始するステップと、
前記メッセージの提示の抑止を解除する解除条件に合致する状態になったときに、前記メッセージの提示の抑止を解除するステップと、を含み、
前記判定するステップは、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする監視方法。
【請求項１】
ネットワークを介して監視対象に関するメッセージを受信する受信部と、
前記メッセージを提示する提示部と、
前記メッセージの提示を抑止する抑止条件と、前記メッセージの提示の抑止を開始する開始条件と、前記メッセージの提示の抑止を解除する解除条件とを格納したデータベースと、
前記データベースを参照して、前記メッセージを前記提示部に提示するか否かを判定する判定部と、を備え、
前記判定部は、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする監視装置。
【請求項２】
前記開始条件は、前記メッセージに関する条件であることを特徴とする請求項１に記載の監視装置。
【請求項３】
前記データベースは、前記開始条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納し、
前記判定部は、前記データベースを参照して、前記開始条件に合致したメッセージを提示するか否かを判定することを特徴とする請求項２に記載の監視装置。
【請求項４】
前記解除条件は、前記メッセージの提示の抑止を開始してからの時間、前記メッセージの提示を抑止した回数、又は前記メッセージに関する条件であることを特徴とする請求項１から３のいずれかに記載の監視装置。
【請求項５】
前記データベースは、前記解除条件に合致したメッセージの提示を抑止するか否かを示す情報を更に格納し、
前記判定部は、前記データベースを参照して、前記解除条件に合致したメッセージを提示するか否かを判定することを特徴とする請求項４に記載の監視装置。
【請求項６】
ネットワークを介して監視対象に関するメッセージを受信するステップと、
前記メッセージの提示を抑止する抑止条件を格納したデータベースを参照して、提示の許否を判定するステップと、
前記メッセージを提示すると判定されたときに、前記メッセージを提示するステップと、
前記メッセージの提示の抑止を開始する開始条件に合致する状態になったときに、前記メッセージの提示の抑止を開始するステップと、
前記メッセージの提示の抑止を解除する解除条件に合致する状態になったときに、前記メッセージの提示の抑止を解除するステップと、を含み、
前記判定するステップは、前記メッセージの提示の抑止を開始してから解除するまでの間に、前記抑止条件に合致したメッセージを受信したときに、そのメッセージの提示を抑止すると判定することを特徴とする監視方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００６−２５２４６０（Ｐ２００６−２５２４６０Ａ）
【公開日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願番号】特願２００５−７１６５９（Ｐ２００５−７１６５９）
【出願日】平成１７年３月１４日（２００５．３．１４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１８年９月２１日（２００６．９．２１）
【国際特許分類】
【出願日】平成１７年３月１４日（２００５．３．１４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]