説明

監視装置、及び監視方法

【課題】被監視装置のダウン状態を適切に検出することができる監視装置、及び監視方法を提供することを目的としている。
【解決手段】被監視装置100から入力された入力画像データが、予め定められている非障害時の画像データであるノイズ画像データと一致するか否かを判別し、入力画像データがノイズ画像データと一致すると判別した場合、入力画像データからノイズ画像データを除去するノイズ除去部225と、ノイズ除去された画像データが予め定められている被監視装置の障害時の画像データである障害画像データと一致するか否かを判別し、ノイズ除去された画像データが障害画像データと一致すると判別した場合、被監視装置に障害が発生していると判別する障害検出部240と、被監視装置に障害が発生していると判別された場合、予め定められている被監視装置の障害復旧手順を実行する障害復旧手順実行部250とを備える。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、監視装置、及び監視方法に関する。
【背景技術】
【0002】
サーバなどの被監視装置のダウンを監視する監視装置は、ネットワークの疎通を確認するプロトコルであるICMP(Internet Control Message Protocol;インターネット制御通知プロトコル)等による生存確認の問い合わせ処理をポーリング(polling)処理によって、被監視装置に対して定期的に行う。そして、監視装置は、被監視装置からの生存確認に対する応答によって、被監視装置の生存状況を判断していた(ポーリング方式)。
また、被監視装置は、主体的に監視装置に対して、予め定められた時間間隔毎に、ネットワークを監視するためのSNMP(Simple Network Management Protocol;シンプル ネットワーク マネージメント プロトコル)によるトラップを発生する等により、生存確認を通知する。そして、監視装置は、この被監視装置からの生存確認を受け取ることにより、被監視装置の生存状況を判断していた(生存通知方式)。
【0003】
しかしながら、このような ポーリング方式や 生存通知方式では、被監視装置がダウンしていることを検知する確度を上げるために、生存確認する間隔を短くする必要がある。生存確認する間隔を短くすることのトレードオフとして、被監視装置への負荷が増加したり、誤検出のリスクが高まるデメリットもある。
このため、監視装置として、被監視装置が連続的に出力する信号、例えばコンソール画面へのビデオ出力信号の変化を監視し、被監視装置がダウンする時に特有の画像パターンを検出するものがある。被監視装置がダウンする時に特有の画像パターンとは、例えば、被監視装置がダウンして電源リセットし、その後、画面がブラックアウトし、次に被監視装置のベンダのロゴが表示され、その後、BIOS(Basic Input Output System)画面の表示などが行われる画像パターンである。あるいは、OS(Operating System)のパニック時に表示されるstack trace等の表示と、画面更新停止等の画面パターンである。そして、監視装置は、このような画像パターンにより被監視装置のダウンを検出した場合、被監視装置の管理者に、障害への解決手順などの障害報告を送信していた(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2006−65659号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、被監視装置のスクリーンセーバーの画像データは、ダウンした時に特有のパターンに似た画像パターンを有しているものもある。
しかしながら、特許文献1に記載の技術では、スクリーンセーバーの画像データの場合、監視装置は、被監視装置がダウンした状態の画像データとして検出してしまう場合がある。このような場合、監視装置は、正常動作している被監視装置に対して再起動等の修復処理を行ってしまうなどの誤動作をする可能性があった。
【0006】
本発明は、上記の問題点に鑑みてなされたものであって、被監視装置のダウン状態を適切に検出することができる監視装置、及び監視方法を提供することを目的としている。
【課題を解決するための手段】
【0007】
上記目的を達成するため、本発明に係る監視装置は、被監視装置から入力された入力画像データが、予め定められている非障害時の画像データであるノイズ画像データと一致するか否かを判別し、前記入力画像データが前記ノイズ画像データと一致すると判別した場合、前記入力画像データから前記ノイズ画像データを除去するノイズ除去部と、前記ノイズ除去部が出力する前記ノイズ画像データが除去された画像データであるノイズ除去された画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致するか否かを判別し、前記ノイズ除去された画像データが前記障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する障害検出部と、前記障害検出部により前記被監視装置に障害が発生していると判別された場合、予め定められている前記被監視装置の障害復旧手順を実行する障害復旧手順実行部と、を備えることを特徴としている。
【0008】
また、本発明に係る監視装置において、前記ノイズ画像データと、前記ノイズ画像データの属性を示す情報として前記ノイズ画像データが起動されているOSを示す情報とが関連づけられて格納されているノイズパターンのデータベースを備え、前記ノイズ除去部は、前記入力画像データと一致する前記ノイズ画像データが、前記ノイズパターンのデータベースに格納されているか否かを判別し、前記入力画像データと一致する前記ノイズ画像データが前記ノイズパターンのデータベースに格納されていた場合、前記ノイズ画像データと関連づけられて格納されている前記属性を示す情報としての前記被監視装置で起動されているOSを示す情報と、前記被監視装置で起動されているOSの属性とが一致するか否かを判別し、前記格納されている前記被監視装置で起動されているOSの属性と、前記被監視装置で起動されているOSの属性とが一致する場合、前記入力画像データが前記ノイズ画像データと一致すると判別し、前記入力画像データが前記ノイズ画像データと一致する場合、前記入力画像データから前記ノイズ画像データを除去するようにしてもよい。
【0009】
また、本発明に係る監視装置において、前記ノイズ除去部は、前記入力画像データが前記ノイズ画像データではないと判別した場合、予め定められている第1の期間以上、前記入力画像データが変化するか否かを判別し、前記予め設定されている期間以上、前記入力画像データが変化しないと判別した場合、前記入力画像データから前記ノイズ画像データを除去するようにしてもよい。
【0010】
また、本発明に係る監視装置において、前記障害検出部は、前記ノイズ除去部が出力する前記ノイズ除去された画像データが、前記障害画像データであると判別された場合、前記被監視装置に対してポーリング処理を行い、前記被監視装置から前記ポーリング処理に対する応答が無い場合に前記被監視装置に障害が発生していると判別するようにしてもよい。
【0011】
また、本発明に係る監視装置において、前記ノイズ除去部は、前記入力画像データが、前記ノイズ画像データと一致するか否かを判別する前に、前記入力画像データが、予め定められている第2の期間以上、連続して黒画像の画像データであるか否かを判別し、前記入力画像データが、予め定められている第2の期間以上、連続して黒画像の画像データであると判別した場合、前記入力画像データが、前記ノイズ画像データであるか否かの判別を開始するようにしてもよい。
【0012】
また、本発明に係る監視装置において、前記ノイズ除去部は、前記入力画像データを、ネットワークを介して前記被監視装置から取得するようにしてもよい。
【0013】
また、本発明に係る監視装置において、前記障害検出部により前記ノイズ除去された画像データが前記障害画像データであると判別された場合、前記前記ノイズ除去された画像データを非障害時の画像データとして前記ノイズパターンのデータベースに学習させるノイズパターン学習部を備えるようにしてもよい。
【0014】
上記目的を達成するため、本発明に係る監視方法は、ノイズ除去部が、被監視装置から入力された入力画像データが、予め定められている非障害時の画像データであるノイズ画像データと一致するか否かを判別し、前記入力画像データが前記ノイズ画像データと一致すると判別した場合、前記入力画像データから前記ノイズ画像データを除去するノイズ除去工程と、障害検出部が、前記ノイズ除去部が出力する前記ノイズ画像データが除去された画像データであるノイズ除去された画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致するか否かを判別し、前記ノイズ除去された画像データが前記障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する障害検出工程と、障害復旧手順実行部が、前記障害検出部により前記被監視装置に障害が発生していると判別された場合、予め定められている前記被監視装置の障害復旧手順を実行する障害復旧手順実行工程と、を含むことを特徴としている。
【発明の効果】
【0015】
本発明によれば、監視装置のノイズ除去部が、被監視装置が出力する画像データから非障害時の画像データを除去し、障害検出部が、被監視装置が出力する画像データから非障害時の画像データを除去した画像データに基づき障害を検出する。そして、障害が検出された場合、障害復旧手順実行部が、被監視装置に対して障害復旧処理を行うようにしたので、被監視装置のダウン状態を適切に検出することができる。
【図面の簡単な説明】
【0016】
【図1】第1実施形態に係る監視システム1の概略構成図である。
【図2】同実施形態に係るノイズパターンDB230に格納されているデータの一例を説明する図である。
【図3】同実施形態に係るパニックパターンDB245に格納されているデータの一例を説明する図である。
【図4】同実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
【図5】第2実施形態に係る監視システム1aの概略構成図である。
【図6】同実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
【図7】第3実施形態に係る監視システム1bの概略構成図である。
【図8】同実施形態に係る被監視装置100の物理レイヤ400の構成の一例を説明する図である。
【発明を実施するための形態】
【0017】
以下、図面を用いて、本発明の実施形態について説明する。なお、本発明は係る実施形態に限定されず、その技術思想の範囲内で種々の変更が可能である。
【0018】
[第1の実施形態]
図1は、本実施形態に係る監視システム1の概略構成図である。
図1に示すように、監視システム1は、被監視装置100、監視装置200により構成されている。被監視装置100は、通信部110、ビデオ出力部120、キーボード信号入力部130、制御部140、電源部150を備えている。監視装置200は、ビデオ信号入力部205、画像取得部210、ノイズ除去部225、ノイズパターンDB230、障害検出部240、パニックパターンDB245、障害復旧手順実行部250、障害復旧手順DB255、通信部260、被監視装置属性DB280を備えている。
【0019】
まず、被監視装置100について説明する。被監視装置100は、例えばサーバである。
通信部110は、ネットワーク・カードやネットワーク・コネクタなどであり、例えばLAN端子を有している。通信部110は、ネットワーク20を介してLANケーブル30で監視装置200と接続されている。通信部110は、制御部140が出力する情報を、ネットワーク20を介して監視装置200に送信する。通信部110は、監視装置200から送信された情報を、ネットワーク20を介して受信し、受信した情報を制御部140に出力する。
【0020】
ビデオ出力部120は、例えばVGA出力端子を有している。ビデオ出力部120は、制御部140が出力するビデオ信号を出力する。
【0021】
キーボード信号入力部130は、図示しないキーボードやマウスなどの入力装置からの入力信号が入力される端子を備えている。キーボード信号入力部130は、キーボードやマウスなどの入力装置から入力された信号を制御部140に出力する。
【0022】
制御部140は、図示しないCPU(Central Processing Unit;中央演算装置)、RAM(Random Access Memory)、ROM(Read Only Memory)、HDD(Hard Disk Drive)などを備える。制御部140は、図示しないHDDに保持されているOS(Operating System)を読み出し、読み出したOSにより生成された画像データをビデオ出力部120に出力する。また、制御部140は、キーボード信号入力部130が出力する入力信号に基づき、OSやHDDに保持されているアプリケーションの処理を行う。
【0023】
電源部150は、外部から入力された電力を被監視装置100の各機能部に供給する。
【0024】
次に、監視装置200について説明する。監視装置200は、被監視装置100の動作状態を監視する。そして、監視装置200は、被監視装置がダウン状態やパニック状態にあると検査された場合、後述するように故障復旧処理や被監視装置の管理者にメール等で通知する。
ビデオ信号入力部205は、被監視装置100が出力するビデオ信号が入力され、入力されたビデオ信号を画像取得部210に出力する。なお、被監視装置100のビデオ出力部120と、監視装置200のビデオ信号入力部205とは、ビデオケーブル10で接続されている。
【0025】
画像取得部210は、ビデオ信号入力部205が出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをノイズ除去部225に出力する。
【0026】
ノイズパターンDB(データベース)230には、例えば、OS毎に各種のスクリーンセーバーによるダウン時の画像パターンを模した画像データや、スクリーンセーバーによるパニック時に表示される画像パターンが、静止画形式または動画形式で格納されている。なお、スクリーンセーバーによるダウン時やパニック時の画像パターンを模した画像データとは、例えば、被監視装置100で動作しているOSまたは被監視装置100で動作しているOSと異なるOSのダウン時やパニック時に表示される画像を模した画像が表示されるスクリーンセーバーの画像データである。これらのスクリーンセーバーは、被監視装置100の管理者がインストールした場合や、OSが標準で備えている場合などがある。なお、スクリーンセーバーによるダウン時やパニック時に表示される画像に似せた特有の画像データを、ノイズパターンという。なお、ノイズパターンDB230に格納されるデータは、予め監視装置200の管理者等により、各種の被監視装置100を接続して取得したノイズパターンに該当する画像データが格納されるようにしてもよい。
【0027】
図2は、本実施形態に係るノイズパターンDB230に格納されているデータの一例を説明する図である。図2に示すように、ノイズパターンDB230には、項目番号、画像データ、画像データ形式、画像データ表示継続時間、OS種別の項目が関連付けられて格納されている。
項目の項目番号のデータ形式は、整数であり、例えば、通し番号である。項目番号は、ノイズパターンDB230への格納は任意である。
項目の画像データは、スクリーンセーバーによるダウン時やパニック時に表示される画像に似せた特有の画像データ(偽異常画像、または、ノイズ画像データともいう)であり、例えば、静止画データまたは動画データである。また、画像データのデータ形式は、バイナリデータである。画像データのノイズパターンDB230への格納は必須である。
項目の画像データ形式は、例えば、ビットマップ、JPEG(Joint Photographic Experts Group)、MPEG(Moving Picture Expert Group)などである。画像データ形式のデータ形式は、整数、または、文字列である。画像データ形式は、例えば、ビットマップが1、JPEGが2のように予め各形式と整数を対応付けて格納されていてもよい。また、画像データ形式は、例えば拡張子により判別できるため、ノイズパターンDB230への任意である。
項目の画像データ表示継続時間は、ダウン時やパニック時に表示される画像に似せた特有の画像データが表示される期間である。画像データ表示継続時間のデータ形式は、整数である。画像データ表示継続時間の単位は、例えば、秒である。画像データ表示継続時間のノイズパターンDB230への格納は必須である。
項目のOS種別は、スクリーンセーバーが用いられているOSの種別である。OS種別のデータ形式は、文字列であり、例えばOSのバージョンを含むOS名で、OS1、OS2などである。OS種別ノイズパターンDB230への格納は必須である。
【0028】
被監視装置属性DB(データベース)280には、被監視装置100の識別IDと、被監視装置100で起動されているOSの属性(バージョンを含む)が、予め関連づけられて格納されている。
【0029】
ノイズ除去部225は、画像取得部210が出力する入力画像データが、ノイズパターンDB230に格納されている画像データと一致するか否かを判別する。入力画像データが、ノイズパターンDB230に格納されている画像データと一致する場合、ノイズ除去部225は、さらに、ノイズパターンDB230に格納されている画像データの属性が、被監視装置属性DB(データベース)280から読み出した監視装置100で起動されているOSの種別と一致するか否かを判別する。
画像データの属性とは、ノイズパターンDB230に画像データと関連付けられて記憶されているOSの種別である。すなわち、ノイズ除去部225は、入力画像データが、ノイズパターンDB230に格納されて、さらに属性が被監視装置100のOSの種別と一致する場合、被監視装置100が出力した画像データをスクリーンセーバーの画像データであると判断する。ノイズ除去部225は、属性が一致しない場合、予め定めた期間(第1の期間)、検出した画像データが持続するか否かを判別する。予め定められた期間以内に画像データが切り替わった場合、入力画像データをスクリーンセーバーの画像データであると判別する。ノイズ除去部225は、画像データがスクリーンセーバーの画像データであると判別した場合、その画像データをノイズパターンとして除去する。すなわち、入力画像データは、被監視装置100がダウン状態になった場合やパニック状態になった場合の画像パターンに似せたスクリーンセーバーの画像データである。このため、ノイズ除去部225は、この画像データをノイズパターンとして除去し、障害検出部240にノイズ除去した画像データを出力する。
一方、ノイズ除去部225は、入力画像データが、ノイズパターンDB230に格納されていなかった場合、入力画像データをそのまま障害検出部240に出力する。
【0030】
パニックパターンDB(データベース)245には、OS種別、障害時の画像データである障害画像データ、障害名などが関連付けられて格納されている。なお、パニックパターンDB245に格納されるデータは、予め監視装置200の管理者等により、各種の被監視装置100を接続して取得した障害時に該当する画像データが格納されるようにしてもよい。
図3は、本実施形態に係るパニックパターンDB245に格納されているデータの一例を説明する図である。図3に示すように、パニックパターンDB245には、OS種別、障害時の画像データ、障害名が関連づけられて格納されている。画像データは、静止画形式または動画形式の画像データである。
【0031】
障害検出部240には、ノイズ除去部225が出力するノイズ除去された画像データが入力される。障害検出部240は、入力されたノイズ除去された画像データが、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。障害検出部240は、ノイズ除去された画像データがパニックパターンDB245に格納されていると判別された場合、被監視装置100がダウン状態またはパニック状態になっていると判断する。障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。なお、画像データに関連付けられて格納されている被監視装置100の状態を示す情報とは、例えば、画像データがダウン時の画像データであればダウン状態、画像データがパニック時の画像データであればパニック状態、などのように、画像データ毎の被監視装置100の障害状態である。
【0032】
障害復旧手順実行部250は、障害検出部240が出力する被監視装置100の障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害復旧手順実行部250は、読み出した故障復旧手順に従って、被監視装置100に対して故障復旧処理を行う。なお、故障復旧手順とは、後述するように、例えば、被監視装置100に対してポーリングを行い、あるいは、被監視装置100の管理者にメールで通知するなどの処理手順である。
【0033】
障害復旧手順DB255には、予め監視装置200の管理者により、被監視装置100の障害状況に応じた故障復旧手順が、OS毎、障害毎に格納されている。
【0034】
通信部260は、ネットワーク・カードやネットワーク・コネクタなどであり、例えばLAN端子を有している。通信部260は、ネットワーク20を介して被監視装置100と接続されている。通信部260は、障害復旧手順実行部250が出力する故障復旧処理を示す情報を、ネットワーク20を介して被監視装置100に送信する。また、通信部260は、被監視装置100から送信された情報を、ネットワーク20を介して受信し、受信した情報を障害復旧手順実行部250に出力する。
【0035】
次に、ノイズパターンの除去と、パニック時の処理の一例について、図4を用いて説明する。図4は、本実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
【0036】
(ステップS1)
監視装置200の画像取得部210は、ビデオ信号入力部205を介して、被監視装置100が出力する画像データを受信する。ステップS1終了後、ステップS2に進む。
(ステップS2)
次に、画像取得部210は、画像データを1フレーム分、受信し、受信した1フレーム分の入力画像データを、順次、ノイズ除去部225に出力する。ステップS2終了後、ステップS3に進む。
【0037】
(ステップS3)
次に、ノイズ除去部225は、パターン検出部215が出力する入力画像データが、イズパターンDB230に格納されている画像データと一致するか否かを判別する。すなわち、ノイズ除去部225は、被監視装置100がダウン状態になった場合やパニック状態になった場合に出力する特有の画像パターンと一致するか否かを判別する。ステップS3終了後、ステップS4に進む。
【0038】
(ステップS4)
入力画像データがノイズパターンDB230に格納されている画像データと一致すると判別された場合(ステップS4;Yes)、ステップS5に進む。この場合、入力画像データがノイズパターンDB230に格納されている画像データと一致すると判別されたため、入力画像データは、ダウン状態やパニック状態の画像データではなく、スクリーンセーバーの画像データ(ノイズパターン)である可能性がある。
入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別された場合(ステップS4;No)、ステップS8に進む。この場合、入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別されたため、入力画像データは、ノイズ画像データではない可能性がある。
【0039】
(ステップS5)
次に、ノイズ除去部225は、画像データと関連付けられてノイズパターンDB230に格納されている画像データのOSの属性を読み出す。また、ノイズ除去部225は、被監視装置100の識別IDと関連付けられて被監視装置属性DB280に格納されている監視装置100のOSの属性を読み出す。
次に、ノイズ除去部225は、読み出した画像データのOSの属性と、被監視装置100で起動しているOSとが一致するか再判別する。例えば、ノイズ除去部225が検出した画像データのOSの属性をノイズパターンDB230から読み出したところ、該当する画像データの属性情報がOS2であり、被監視装置属性DB280に格納されている被監視装置100のOSの属性がOS2であった場合、OSの属性が一致するため、入力画像データを正常動作によるスクリーンセーバーの画像データが動作していると判断する。このため、ノイズ除去部225は、入力画像データをノイズパターンと判別してノイズ画像データを除去する。ノイズパターン除去後、ステップS1に戻る。
一方、ノイズパターンDB230から読み出した画像データのOSの属性と、被監視装置100で起動しているOSとが一致しない場合、ステップS6に進む。この場合、ノイズパターンDB230から読み出した画像データのOSの属性と、被監視装置100で起動しているOSとが一致しないため、ノイズ画像データではない(即ち実際のサーバ障害を示す画像である)可能性が高い。
【0040】
(ステップS6)
ノイズ除去部225は、入力画像データがノイズパターンDB230に格納されている画像データと一致し且つOSの属性が一致しない場合、予め定めた期間、画像パターンの確認を続ける。この理由は、入力画像データが、被監視装置100で起動しているOSのダウン状態やパニック状態に似せたスクリーンセーバーであるか否かを再判別するためである。ステップS6終了後、ステップS7に進む。
【0041】
(ステップS7)
スクリーンセーバーの場合、周期的に画像データが変化しながら繰り返される。このため、画像データが変化した場合、ノイズ除去部225は、画像データがスクリーンセーバーの画像データであると判断し(ステップS7;No)、ステップS1に戻る。
一方、予め定めた期間が過ぎても、画像データが変化しない場合(ステップS7;Yes)、被監視装置100がダウン状態かパニック状態になっている可能性が高いため、ノイズ除去部225は、ノイズ除去された画像データを 障害検出部240に出力し、ステップS8に進む。すなわち、ノイズ除去部225は、被監視装置100が出力した入力画像データから、ノイズパターンの画像データ及びノイズパターンの可能性がある画像データを除去し、ノイズパターン除去後のノイズ除去された画像データを障害検出部240に出力する。
【0042】
(ステップS8)
次に、障害検出部240は、ノイズ除去部225が出力するノイズ除去された画像データを、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。ノイズ除去された画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合、障害検出部240は、一致した画像データに基づき、被監視装置100がダウン状態かパニック状態であると判断する。すなわち、ノイズ除去された画像データが、ダウン状態の画像データと一致した場合、障害検出部240は、被監視装置100がダウン状態であると判別する。あるいは、ノイズ除去された画像データが、パニック状態の画像データと一致した場合、障害検出部240は、被監視装置100がパニック状態であると判別する。
次に、障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。被監視装置100の障害状態を示す情報とは、被監視装置100がダウン状態を示す情報、または、被監視装置100がパニック状態を示す情報である。ステップS8終了後、ステップS9に進む。
【0043】
(ステップS9)
次に、障害復旧手順実行部250は、障害検出部240が出力する被監視装置100の障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。例えば、障害検出部240が出力する被監視装置100がダウン状態を示す情報の場合、障害復旧手順実行部250は、被監視装置100がダウン状態の障害復旧手順を障害復旧手順DB255から読み出す。あるいは、障害検出部240が出力する被監視装置100がパニック状態を示す情報の場合、障害復旧手順実行部250は、被監視装置100がパニック状態の障害復旧手順を障害復旧手順DB255から読み出す。
次に、障害検出部240は、読み出した故障復旧手順に従って、被監視装置100に対して故障復旧処理を行う。
障害復旧手順実行部250は、読み出した故障復旧手順に従って、被監視装置100の通信部110に対して、例えば、ICMP(Internet Control Message Protocol;インターネット制御通知プロトコル)による生存確認のポーリング処理を、通信部260を介して行う。ポーリング処理とは、例えばping信号などを送信することである。
被監視装置100から生存確認のポーリング処理への応答があった場合、障害復旧手順実行部250は、例えば、被監視装置100のビデオ信号出力部120が故障している可能性があることを示す情報を、被監視装置100の管理者に通信部260を介してメール等で通知する。被監視装置100から生存確認のポーリング処理への応答がなかった場合、障害復旧手順実行部250は、被監視装置100がダウン状態またはパニック状態にあると判断し、判断結果を被監視装置100の管理者に通信部260を介してメール等で通知する。
【0044】
以上のように、監視装置200のノイズ除去部225は、取得した入力画像データからダウン状態やパニック状態の画像データに似せたスクリーンセーバーによるノイズパターンを検出して除去する。そして、障害復旧手順実行部250は、ノイズ除去された画像データに基づき、被監視装置100に障害が生じているか判別し、障害が生じている場合に故障復旧手順を実行する。さらに、障害復旧手順実行部250は、被監視装置100の通信部110に対してポーリング処理を行うことで、被監視装置100のビデオ信号出力部120の故障なのか、ダウン状態またはパニック状態なのかを判断する。
この結果、ダウン時やパニック時の画像データに似せたスクリーンセーバーが稼働した場合でも、監視装置200は、被監視装置100が正常に動作していると判別でき、被監視装置100に対して誤って故障復旧処理を行うことを防ぐことができる。また、監視装置200は、被監視装置100が、ダウン状態やパニック状態にあることを適切に検出でき、検出した場合に適切に故障復旧処理を行うことができる。
【0045】
なお、本実施形態では、ステップS5で、ノイズ除去部225が、被監視装置100で起動しているOSと、画像データのOS種別との属性チェックする例を説明したが、ステップS5の属性チェックは行わなくてもよい。この場合、ステップS4でYesの場合、そのままステップS6に進み、予め定めた期間が経過したか否かの判別(ステップS7)により、スクリーンセーバー動作か否かを判別するようにしてもよい。
【0046】
また、被監視装置100が出力する画像データが、例えば、刻々と変化するカウンタ値を含むようなパニック状態に似せた画像データのスクリーンセーバーの場合、このカウンタ値が変化する動画形式の画像データをノイズパターンDB230に格納させておき、ノイズ除去部225が、入力画像データと比較して判別するようにしてもよい。このようなスクリーンセーバーの場合、例えば、カウンタ値の前に固定のプレフィックス文字列が含まれている。このため、ノイズ除去部225は、入力画像データから、このカウンタ値の前に含まれる固定のプレフィックス文字列の部分を抽出し、抽出した画像データがノイズパターンDB230に格納されているか否かを判別してノイズ除去するようにしてもよい。
【0047】
また、被監視装置100の識別IDは、例えば、予め本実施形態に係る監視システム1を構築する場合に、例えば、入力画像データに重畳された被監視装置100の識別IDを取得し、取得した識別IDに基づき、被監視装置属性DB280から被監視装置100で起動されているOSの属性を読み出すようにしてもよい。この場合、被監視装置100の制御部140は、被監視装置100の識別IDをビデオ信号に重畳して、ビデオ信号出力部120から出力する。または、監視装置200は、被監視装置100の識別IDを、例えば通信部260経由で取得するようにしてもよい。被監視装置100の識別IDは、例えば、被監視装置100の製造番号や、ネットワークのIP(Internet Protocol)アドレスや、MAC(Media Access Control)アドレスであってもよい。
【0048】
[第2実施形態]
図5は、本実施形態に係る監視システム1aの構成図である。
図5に示すように、監視システム1aは、被監視装置100a、監視装置200a、電源制御部300により構成されている。被監視装置100aは、通信部110、ビデオ出力部120、キーボード信号入力部130a、制御部140、電源部150を備えている。監視装置200aは、ビデオ信号入力部205、画像取得部210a、パターン検出部215,計時部220、ノイズ除去部225、ノイズパターンDB230、ノイズパターン学習部235、障害検出部240a、パニックパターンDB245、障害復旧手順実行部250a、障害復旧手順DB255、通信部260a、被監視装置属性DB280を備えている。第1実施形態と同じ機能部は、同じ符号を用いて説明を省略する。
【0049】
まず、被監視装置100aについて説明する。
キーボード信号入力部130aは、図示しないキーボードやマウスなどの入力装置からの入力信号、および、監視装置200aからの入力信号が入力される端子を備えている。キーボード信号入力部130aは、キーボードやマウスなどの入力装置、および、監視装置200aから入力された信号を制御部140に出力する。
【0050】
電源部150は、電源制御蔵置300から入力された電力を被監視装置100の各機能部に供給する。
【0051】
次に、監視装置200について説明する。
【0052】
画像取得部210aは、ビデオ信号入力部205、または、通信部260が出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをパターン検出部215に出力する。
【0053】
計時部220は、時間を示す情報を生成し、生成した時間を示す情報をパターン検出部215に出力する。
【0054】
パターン検出部215は、画像取得部210が出力する入力画像データの中から公知の画像認識により、計時部220が出力する時間を示す情報に基づき、予め定められた期間(第2の期間)、黒信号が連続するブラックアウト状態を検出する。パターン検出部215は、例えば、画像認識の手法として、パターンマッチング手法などを用いる。
予め定められた期間、黒信号が連続するブラックアウト状態を検出する理由は、一般的なスクリーンセーバーの場合、一度、表示が黒になった後(この状態をブラックアウトという)、スクリーンセーバーの画像データが出力される。したがって、パターン検出部215は、スクリーンセーバーの動作が開始したことを検出するため、このブラックアウトを検出する。パターン検出部215は、ブラックアウトを検出した場合、ノイズ除去部225にブラックアウト検出後の入力画像データを順次、フレーム毎に出力する。
【0055】
障害検出部240aには、ノイズ除去部225が出力するノイズ除去された画像データが入力される。障害検出部240は、入力されたノイズ除去された画像データが、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。障害検出部240aは、ノイズ除去された画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合、被監視装置100がダウン状態またはパニック状態になっていると判断する。障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。
また、障害検出部240aは、ノイズ除去された画像データがパニックパターンDB245に格納されている画像データと一致しない判別された場合、ノイズパターンDB230に格納されていない新たなノイズパターンの画像であるため、ノイズ除去された画像データをノイズパターン学習部235に出力する。
【0056】
ノイズパターン学習部235は、障害検出部240aが出力する画像データを学習してノイズパターンDB230に学習させる。
【0057】
障害復旧手順実行部250aは、障害検出部240が出力する被監視装置100の障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害復旧手順実行部250aは、読み出した故障復旧手順に従って、電源制御装置300、および、被監視装置100に対して故障復旧処理を行う。
【0058】
通信部260aは、ネットワーク20を介して被監視装置100と接続されている。通信部260aは、障害復旧手順実行部250が出力する故障復旧処理を示す情報を、ネットワーク20を介して被監視装置100に送信する。また、通信部260aは、被監視装置100から送信された情報を、ネットワーク20を介して受信し、受信した情報が画像データの場合、受信した画像データを画像取得部210aに出力する。
【0059】
電源制御装置300は、外部からの電力を被監視装置100に供給する装置である。電源制御装置300は、監視装置200からの制御により、被監視装置100に供給する電圧を停止、または供給開始するように制御する。
【0060】
次に、ノイズパターンの除去と、パニック時の処理の一例について、図6を用いて説明する。図6は、本実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
【0061】
(ステップS101、S102)
ステップS101とS102は、第1実施形態のステップS1、S2と同様に行う。ステップS102終了後、ステップS103に進む。
【0062】
(ステップS103)
次に、パターン検出部215は、計時部220が出力する時間を示す情報に基づき、予め定めた期間以上、画像取得部210aが出力する入力画像データがブラックアウトしたか否かを公知の画像認識により検出する。この処理の理由は、一般的なスクリーンセーバーの場合、入力画像データが、一度ブラックアウトした後、スクリーンセーバーが起動されるためである。ブラックアウトを検出した場合、パターン検出部215は、入力された入力画像データをノイズ除去部225に出力する。ステップS103終了後、ステップS104に進む。
【0063】
(ステップS104〜S108)
ステップS104〜S108は、ステップS3〜S7と同様に行う。
【0064】
(ステップS109)
次に、障害検出部240aは、ノイズ除去部225が出力するノイズ除去された画像データを、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。ステップS109終了後、ステップS110に進む。
【0065】
(ステップS110)
入力画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合(ステップS110;Yes)、ステップS112に進む。この場合、障害検出部240aは、一致した画像データに基づき、被監視装置100aがダウン状態かパニック状態であると判断する。
入力画像データがパニックパターンDB245に格納されている画像データと一致しないと判別された場合(ステップS110;No)、ステップS111に進む。この場合、入力画像データがパニックパターンDB245に格納されている画像データと一致しないと判別されたため、障害検出部240aは、被監視装置100aが正常動作状態であると判別する。次に、障害検出部240aは、入力画像データが、ノイズパターンDB230に、まだ格納されていないと判別する。
【0066】
(ステップS111)
入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別された場合(ステップS110;No)、障害検出部240aは、ノイズ除去された画像データをノイズパターン学習部235に出力する。
次に、ノイズパターン学習部235は、障害検出部240aが出力するノイズ除去された画像データをノイズパターンDB230に学習させる。ステップS111終了後、ステップS101に戻る。
【0067】
(ステップS112)
ノイズ除去された画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合(ステップS110;Yes)、障害検出部240aは、一致した画像データに基づき、被監視装置100aがダウン状態かパニック状態であると判断する。
次に、障害検出部240aは、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100aの状態を示す情報を読み出し、読み出した被監視装置100aの障害状態を示す情報を障害復旧手順実行部250aに出力する。
【0068】
次に、障害復旧手順実行部250aは、障害検出部240aが出力する被監視装置100aの障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害検出部240は、読み出した故障復旧手順に従って、被監視装置100に対して故障復旧処理を行う。例えば、障害復旧手順実行部250aは、ソフトウェア・リセットのキーの組み合わせ以外のいずれかのキーが押された状態を示す信号を生成し、または、マウスを動かした状態を示す信号を生成する。そして、障害復旧手順実行部250aは、生成したいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を、被監視装置100aのキーボード信号入力部130aに送信し、画像データが変化するか否かを確認する。このような処理を行っても、画像データが変化しない場合、障害復旧手順実行部250aは、さらに以下の処理を行う。
【0069】
障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信する。なお、ソフトウェア・リセットのキーの組み合わせ信号とは、例えば、Ctrl(コントロール)キーとAltキーとDeleteキーを同時に押した場合の信号である。
次に、障害復旧手順実行部250aは、予め定められた時間後、例えば、被監視装置100aの通信部110に対してポーリング処理を行い、ソフトウェア・リセット処理が実行できたか否かを確認する。被監視装置100aから応答が無い場合、障害復旧手順実行部250aは、再度、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信する。なお、予め定められた時間とは、被監視装置100aに対してソフトウェア・リセット処理を行わせ、再起動するまでの時間以上の時間であり、例えば120秒である。
また、被監視装置100aのキーボード信号入力部130へソフトウェア・リセットのキーの組み合わせ信号を送信する前に、障害復旧手順実行部250aは、被監視装置100aの管理者に対して、被監視装置100を再起動することを示す情報を、ネットワーク20を介してメール等で送信する。そして、管理者から了解を得た後に、障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、ソフトウェア・リセットのキーの組み合わせ信号を送信するようにしてもよい。
【0070】
このように被監視装置100aのキーボード信号入力部130へソフトウェア・リセットを行っても被監視装置100aを再起動できない場合、あるいは、ソフトウェア・リセットを行わずに障害復旧手順実行部250aは、以下のような処理を行う。
障害復旧手順実行部250aは、電源制御装置300に対して被監視装置100aへの電力の供給を停止する指示を送信する。この結果、被監視装置100aには、電源制御装置300から電力が供給されなくなる。そして、被監視装置100aは、強制的にシャットダウンする。
次に、障害復旧手順実行部250aは、予め定められた時間後、電源制御装置300に対して被監視装置100aへの電力の供給を開始する指示を送信する。この結果、被監視装置100aは、電力が供給再開されたことにより再起動される。なお、予め定められた時間とは、被監視装置100aへの電力の供給を停止した後、例えば被監視装置100aのHDDの回転が停止した後、起動しても支障が無い時間であり、例えば120秒である。
また、電源制御装置300に対して被監視装置100aへの電力の供給を停止する指示を送信する前に、障害復旧手順実行部250aは、被監視装置100aの管理者に対して、被監視装置100aを再起動することを示す情報を、ネットワーク20を介してメール等で送信する。そして、管理者から了解を得た後に、障害復旧手順実行部250aは、電源制御装置300に対して被監視装置100aへの通電を停止する指示を送信するようにしてもよい。
【0071】
以上のように、故障復旧手順として、まず、監視装置200aは、被監視装置100aにソフトウェア・リセットのキーの組み合わせ以外のいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を送信する。これにより、被監視装置100aからの入力画像データがスクリーンセーバーによる画像データの場合、これらの処理により、画像データが変化する。この処理により、被監視装置100aの画像データは、スクリーンセーバーの画像データから、通常動作時の画像データに復帰する。この結果、監視装置200aは、被監視装置100aの状態を適切に監視できる。
また、上述の処理を行っても入力画像データが変化しない場合、監視装置200aは、被監視装置100aにソフトウェア・リセットのキーの組み合わせ信号を送信して、被監視装置100aに対してソフトウェア・リセットを行う。この結果、監視装置200aは、被監視装置100aを適切に故障復旧させることができる。
また、被監視装置100aに対してソフトウェア・リセットを行っても被監視装置100aが再起動しない場合、監視装置200aは、電源制御装置300に対して、被監視装置100aへの電力の供給を停止する指示を送信する。そして、電力の供給を停止する指示を送信後、予め定めた時間後に、監視装置200aは、被監視装置100aへの電源供給を再開して再起動するようにした。この結果、監視装置200aは、被監視装置100aを適切に故障復旧させることができる。
【0072】
また、本実施形態では、ステップS111で、ノイズパターン学習部235が、画像データをノイズパターンDB230に学習させる例を説明したが、画像データ、画像データ形式、画像データ表示計測時間、OS種別などを関連づけて、ノイズパターンDB230に学習させるようにしてもよい。
【0073】
また、本実施形態では、監視装置200aが、被監視装置100aのビデオ信号出力部120が出力する画像データを取得する例を説明した。画像の取得は、被監視装置100aの他の出力部からでもよく、例えば、通信部110のLAN(Local Area Network)端子経由で取得してもよい。この場合、被監視装置100aの制御部140は、画像データを、通信部110を介して、ネットワーク20に送信する。そして、監視装置200aの通信部260aは、被監視装置100aから送信された画像データを、ネットワーク20を介して受信し、受信した画像データを画像取得部210aに出力する。あるいは、被監視装置100aの制御部140は、画像データを図示しないUSB(Universal Serial Bus)端子を介して、ネットワーク20に送信する。そして、監視装置200aの通信部260aは、被監視装置100aから送信された画像データを、ネットワーク20を介して受信し、受信した画像データを画像取得部210aに出力する。
【0074】
また、本実施形態では、障害復旧手順実行部250aが、まず被監視装置100aにいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を送信して、被監視装置100aがダウン状態またはパニック状態になっているか再判断する例を説明した。しかしながら、被監視装置100aがダウン状態またはパニック状態になっているかの再判別は、これに限られない
例えば、障害復旧手順実行部250aは、第1実施形態と同様に、被監視装置100aの通信部110へポーリング処理を行っても被監視装置100aから応答が無い場合、障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信するようにしてもよい。
【0075】
[第3実施形態]
次に、本実施形態について、図1と図7を用いて説明する。なお、図5の構成を用いても同様の効果が得られる。
本実施形態は、被監視装置100bのホストOS上で、複数の仮想マシン(Virtual Machine)が動作している。なお、仮想マシンとは、OSが動作する実際のコンピュータを仮想的に構築したものである。これにより、1台のコンピュータを仮想マシンに分割することで、複数のOSを並列に実行させることができる。
【0076】
図7は、本実施形態に係る監視システム1bの概略構成図である。
図7に示すように、監視システム1bは、被監視装置100b、監視装置200bにより構成されている。被監視装置100bは、通信部110、ビデオ出力部120−1〜120−n、キーボード信号入力部130、制御部140b、電源部150を備えている。監視装置200bは、ビデオ信号入力部205−1〜205−n、画像取得部210b、ノイズ除去部225、ノイズパターンDB230、障害検出部240、パニックパターンDB245、障害復旧手順実行部250、障害復旧手順DB255、通信部260、被監視装置属性DB280bを備えている。
【0077】
被監視装置100bの制御部140bは、仮想マシンのOSにより生成された画像データをビデオ出力部120−1〜120−nに出力する。
このように、複数のビデオ信号出力部を有する理由120−1〜120−nは、仮想マシンの中には、ホストOSの全画面を使って動作するものもあるからである。このような場合、被監視装置100bから出力される画像データは、一般的には被監視装置100bに接続されている図示しない表示装置に表示されている仮想マシンVMの画像データのみで、他の仮想マシンのVMはバックグランドで動作し、画像データが図示しない表示装置に表示されていない。すなわち、ビデオ出力部が1つのみの場合、図示しない表示装置に表示されている画像データのみが、監視装置200bに出力されることになる。このため、被監視装置100bは、複数のビデオ出力部120−1〜120−nを備えることが好ましい。
【0078】
監視装置200bのビデオ信号入力部205−1〜205−nは、被監視装置100bが出力するビデオ信号が各々入力され、入力されたビデオ信号を画像取得部210bに出力する。なお、被監視装置100bのビデオ出力部120−1と監視装置200のビデオ信号入力部205−1とは、ビデオケーブル10−1で接続されている。同様に、被監視装置100bのビデオ出力部120−nと監視装置200のビデオ信号入力部205−nとは、ビデオケーブル10−nで接続されている。
【0079】
画像取得部210bは、ビデオ信号入力部205−1〜205−nが出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをノイズ除去部225に出力する。
被監視装置属性DB280bには、被監視装置100の識別IDと、被監視装置100bで起動されているOSの属性(バージョンを含む)が、予め関連づけられて格納されている。また、被監視装置属性DB280bには、被監視装置100bで起動されている仮想マシン毎の識別IDと、仮想マシン毎のOSの属性が関連づけられて格納されている。
【0080】
図8は、本実施形態に係る被監視装置100bの物理レイヤ400の構成の一例を説明する図である。図8に示すように、被監視装置100bの物理レイヤ400は、下層レイヤ450、上層レイヤ410により構成されている。
下層レイヤ450は、ホストOSの動作しているレイヤである。
上層レイヤ410は、アプリケーションのレイヤであり、本実施形態では、ホストOS上で、複数の仮想マシンVM(420−1)〜VM(420−n)が動作している。このような仮想マシンにおいては、被監視装置100bは、複数のビデオ信号出力部120−1〜120−nを備えている。例えば、被監視装置100bは、仮想マシンVM(420−1)の画像データをビデオ信号出力部120−1から出力し、仮想マシンVM(420−n)の画像データをビデオ信号出力部120−nから出力する。あるいは、被監視装置100bは、図示しない複数の通信部110−1〜110−nを備えている。被監視装置100bは、仮想マシンVM(420−1)の画像データを図示しない通信部110−1から出力し、仮想マシンVM(420−n)の画像データを図示しない通信部110−nから出力する。
複数の仮想マシンVM(420−1)〜VM(420−n)が動作している場合、どの仮想マシンからの出力かを見分けるため、各仮想マシンVM(420−1)〜VM(420−n)の出力に識別IDを設ける。例えば、仮想マシンVM(420−1)に対する識別IDはV、仮想マシンVM(420−2)に対する識別IDはVである。
【0081】
例えば、被管理装置100上で、2つの仮想マシンVM(420−1)と仮想マシンVM(420−2)が動作しているとして、説明を行う。
被監視装置100のビデオ信号出力部120は、仮想マシンVM(420−1)と仮想マシンVM(420−2)との画像データに識別IDを付けて、監視装置200に出力する。
管理装置200の画像取得部210は、被監視装置100の仮想マシンVM(420−1)と仮想マシンVM(420−2)との各識別IDを含む画像データが入力される。
監視装置200のパターン検出部215、ノイズ除去部225、および、障害検出部240等は、図4のフローチャートと同様に、各仮想マシンに障害が生じていないか監視する。
【0082】
図4のステップS5において、ノイズ除去部225は、ノイズパターンDB230から読み出した画像データのOSの属性と、被監視装置属性DB280bから読み出した仮想マシンで起動しているOSの属性とが一致するか再判別する。ノイズパターンDB230から読み出した画像データのOSの属性と、仮想マシンで起動しているOSとが一致する場合、ノイズ除去部225は、入力画像データをノイズパターンと判別してノイズ画像データを除去する。ノイズパターン除去後、ステップS1に戻る。
一方、ノイズパターンDB230から読み出した画像データのOSの属性と、仮想マシンで起動しているOSとが一致しない場合、ステップS6に進む。
そして、図4のステップS8で、画像データがパニックパターンDB245に格納されている画像データと一致した場合、障害検出部240は、画像データに付けられている識別IDにより、どの仮想マシンに障害が生じているかを判別する。例えば仮想装置VMに障害が生じている場合、障害検出部240は、例えば、通信部260を介して、被監視装置100に、仮想装置VMに対して再起動を行う指示を送信する。あるいは、障害検出部240は、仮想装置VMに障害が生じていることを示す情報を、被監視装置100の管理者に送信する。
【0083】
なお、本実施形態では、画像データに付けられた識別IDを用いて、仮想マシンを識別する例を説明したが、識別は識別IDを使用しなくても良い。この場合、ホストOS上で動作している仮想マシンのOSの種類やバージョン特有の画像データを正常動作時に監視装置200bの画像取得部210bが検出する。そして、検出した結果に基づき、障害検出部240が、仮想マシンを識別するようにしてもよい。
【0084】
本実施形態では、被監視装置100が複数のビデオ信号出力部を備える例を説明したが、ビデオ信号出力部は、1つでもよい。この場合、被監視装置100は、仮想マシンVMとVMとの画像データに識別子を付けて、例えば時分割して交互に送信する。
そして、監視装置200bのビデオ信号入力部205bは、このように送信された画像データを取得し、取得した画像データを用いて、各仮想マシンに障害が生じていないかを検出するようにしてもよい。
【0085】
なお、本実施形態では、被監視装置100、100a、および100bが1台の例を説明したが、被監視装置は複数であってもよい。この場合、監視装置200、200aは、複数の被監視装置が出力する画像データを時分割で受信するか、あるいは、図7に示した監視装置200bのように複数のビデオ信号入力部を備えるようにしてもよい。
【0086】
なお、上述した実施形態における図1、図5および図7の監視装置200、200a、および、200bの一部をコンピュータで実現するようにしても良い。その場合、この制御機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピュータシステム」とは、監視装置200に内蔵されたコンピュータシステムであって、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
また、上述した実施形態における監視装置、200a、および、200bの一部、または全部を、LSI(Large Scale Integration)等の集積回路として実現しても良い。また、監視装置200の各機能ブロックは個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化しても良い。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現しても良い。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いても良い。
【符号の説明】
【0087】
1、1a、1b・・・監視システム1、100・・・被監視装置、
10・・・ビデオケーブル、20・・・ネットワーク、30・・・LANケーブル、
110・・・通信部、120・・・ビデオ信号出力部、
130・・・キーボード信号入力部、140・・・制御部、150・・・電源部、
200・・・監視装置、205・・・ビデオ信号入力部、210・・・画像取得部、
215・・・パターン検出部、220・・・計時部、225・・・ノイズ除去部、
230・・・ノイズパターンDB、235・・・ノイズパターン学習部、
240・・・障害検出部、245・・・パニックパターンDB、
250・・・障害復旧手順実行部、255・・・障害復旧手順DB、260・・・通信部
280・・・被監視装置属性DB

【特許請求の範囲】
【請求項1】
被監視装置から入力された入力画像データが、予め定められている非障害時の画像データであるノイズ画像データと一致するか否かを判別し、前記入力画像データが前記ノイズ画像データと一致すると判別した場合、前記入力画像データから前記ノイズ画像データを除去するノイズ除去部と、
前記ノイズ除去部が出力する前記ノイズ画像データが除去された画像データであるノイズ除去された画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致するか否かを判別し、前記ノイズ除去された画像データが前記障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する障害検出部と、
前記障害検出部により前記被監視装置に障害が発生していると判別された場合、予め定められている前記被監視装置の障害復旧手順を実行する障害復旧手順実行部と、
を備えることを特徴とする監視装置。
【請求項2】
前記ノイズ画像データと、前記ノイズ画像データの属性を示す情報として前記ノイズ画像データが起動されているOSを示す情報とが関連づけられて格納されているノイズパターンのデータベース
を備え、
前記ノイズ除去部は、
前記入力画像データと一致する前記ノイズ画像データが、前記ノイズパターンのデータベースに格納されているか否かを判別し、
前記入力画像データと一致する前記ノイズ画像データが前記ノイズパターンのデータベースに格納されていた場合、前記ノイズ画像データと関連づけられて格納されている前記属性を示す情報としての前記被監視装置で起動されているOSを示す情報と、前記被監視装置で起動されているOSの属性とが一致するか否かを判別し、
前記格納されている前記被監視装置で起動されているOSの属性と、前記被監視装置で起動されているOSの属性とが一致する場合、前記入力画像データが前記ノイズ画像データと一致すると判別し、前記入力画像データが前記ノイズ画像データと一致する場合、前記入力画像データから前記ノイズ画像データを除去する
ことを特徴とする請求項1に記載の監視装置。
【請求項3】
前記ノイズ除去部は、
前記入力画像データが前記ノイズ画像データではないと判別した場合、予め定められている第1の期間以上、前記入力画像データが変化するか否かを判別し、前記予め設定されている期間以上、前記入力画像データが変化しないと判別した場合、前記入力画像データから前記ノイズ画像データを除去する
ことを特徴とする請求項1または請求項2に記載の監視装置。
【請求項4】
前記障害検出部は、
前記ノイズ除去部が出力する前記ノイズ除去された画像データが、前記障害画像データであると判別された場合、前記被監視装置に対してポーリング処理を行い、前記被監視装置から前記ポーリング処理に対する応答が無い場合に前記被監視装置に障害が発生していると判別する
ことを特徴とする請求項1から請求項3のいずれか1項に記載の監視装置。
【請求項5】
前記ノイズ除去部は、
前記入力画像データが、前記ノイズ画像データと一致するか否かを判別する前に、
前記入力画像データが、予め定められている第2の期間以上、連続して黒画像の画像データであるか否かを判別し、
前記入力画像データが、予め定められている第2の期間以上、連続して黒画像の画像データであると判別した場合、前記入力画像データが、前記ノイズ画像データであるか否かの判別を開始する
ことを特徴とする請求項1から請求項4のいずれか1項に記載の監視装置。
【請求項6】
前記ノイズ除去部は、
前記入力画像データを、ネットワークを介して前記被監視装置から取得する
ことを特徴とする請求項1から請求項5のいずれか1項に記載の監視装置。
【請求項7】
前記障害検出部により前記ノイズ除去された画像データが前記障害画像データであると判別された場合、前記前記ノイズ除去された画像データを非障害時の画像データとして前記ノイズパターンのデータベースに学習させるノイズパターン学習部
を備えることを特徴とする請求項2に記載の監視装置。
【請求項8】
ノイズ除去部が、被監視装置から入力された入力画像データが、予め定められている非障害時の画像データであるノイズ画像データと一致するか否かを判別し、前記入力画像データが前記ノイズ画像データと一致すると判別した場合、前記入力画像データから前記ノイズ画像データを除去するノイズ除去工程と、
障害検出部が、前記ノイズ除去部が出力する前記ノイズ画像データが除去された画像データであるノイズ除去された画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致するか否かを判別し、前記ノイズ除去された画像データが前記障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する障害検出工程と、
障害復旧手順実行部が、前記障害検出部により前記被監視装置に障害が発生していると判別された場合、予め定められている前記被監視装置の障害復旧手順を実行する障害復旧手順実行工程と、
を含むことを特徴とする監視方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2012−212243(P2012−212243A)
【公開日】平成24年11月1日(2012.11.1)
【国際特許分類】
【出願番号】特願2011−76641(P2011−76641)
【出願日】平成23年3月30日(2011.3.30)
【国等の委託研究の成果に係る記載事項】(出願人による申告)平成22年度 総務省、情報通信の研究開発「高信頼クラウドサービス制御基盤技術」委託研究、産業技術力強化法第19条の適用を受ける特許出願
【出願人】(000102728)株式会社エヌ・ティ・ティ・データ (438)
【Fターム(参考)】