JP5683354B2 - 監視装置、及び監視方法 - Google Patents

監視装置、及び監視方法 Download PDF

Info

Publication number
JP5683354B2
JP5683354B2 JP2011076641A JP2011076641A JP5683354B2 JP 5683354 B2 JP5683354 B2 JP 5683354B2 JP 2011076641 A JP2011076641 A JP 2011076641A JP 2011076641 A JP2011076641 A JP 2011076641A JP 5683354 B2 JP5683354 B2 JP 5683354B2
Authority
JP
Japan
Prior art keywords
image data
failure
unit
monitored device
input image
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2011076641A
Other languages
English (en)
Other versions
JP2012212243A (ja
Inventor
伊藤 雅典
雅典 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Data Corp
Original Assignee
NTT Data Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NTT Data Corp filed Critical NTT Data Corp
Priority to JP2011076641A priority Critical patent/JP5683354B2/ja
Publication of JP2012212243A publication Critical patent/JP2012212243A/ja
Application granted granted Critical
Publication of JP5683354B2 publication Critical patent/JP5683354B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Description

本発明は、監視装置、及び監視方法に関する。
サーバなどの被監視装置のダウンを監視する監視装置は、ネットワークの疎通を確認するプロトコルであるICMP(Internet Control Message Protocol;インターネット制御通知プロトコル)等による生存確認の問い合わせ処理をポーリング(polling)処理によって、被監視装置に対して定期的に行う。そして、監視装置は、被監視装置からの生存確認に対する応答によって、被監視装置の生存状況を判断していた(ポーリング方式)。
また、被監視装置は、主体的に監視装置に対して、予め定められた時間間隔毎に、ネットワークを監視するためのSNMP(Simple Network Management Protocol;シンプル ネットワーク マネージメント プロトコル)によるトラップを発生する等により、生存確認を通知する。そして、監視装置は、この被監視装置からの生存確認を受け取ることにより、被監視装置の生存状況を判断していた(生存通知方式)。
しかしながら、このような ポーリング方式や 生存通知方式では、被監視装置がダウンしていることを検知する確度を上げるために、生存確認する間隔を短くする必要がある。生存確認する間隔を短くすることのトレードオフとして、被監視装置への負荷が増加したり、誤検出のリスクが高まるデメリットもある。
このため、監視装置として、被監視装置が連続的に出力する信号、例えばコンソール画面へのビデオ出力信号の変化を監視し、被監視装置がダウンする時に特有の画像パターンを検出するものがある。被監視装置がダウンする時に特有の画像パターンとは、例えば、被監視装置がダウンして電源リセットし、その後、画面がブラックアウトし、次に被監視装置のベンダのロゴが表示され、その後、BIOS(Basic Input Output System)画面の表示などが行われる画像パターンである。あるいは、OS(Operating System)のパニック時に表示されるstack trace等の表示と、画面更新停止等の画面パターンである。そして、監視装置は、このような画像パターンにより被監視装置のダウンを検出した場合、被監視装置の管理者に、障害への解決手順などの障害報告を送信していた(例えば、特許文献1参照)。
特開2006−65659号公報
ところで、被監視装置のスクリーンセーバーの画像データは、ダウンした時に特有のパターンに似た画像パターンを有しているものもある。
しかしながら、特許文献1に記載の技術では、スクリーンセーバーの画像データの場合、監視装置は、被監視装置がダウンした状態の画像データとして検出してしまう場合がある。このような場合、監視装置は、正常動作している被監視装置に対して再起動等の修復処理を行ってしまうなどの誤動作をする可能性があった。
本発明は、上記の問題点に鑑みてなされたものであって、被監視装置のダウン状態を適切に検出することができる監視装置、及び監視方法を提供することを目的としている。
上記目的を達成するため、本発明に係る監視装置は、被監視装置から受信した1フレーム分の入力画像データを、順次、出力する画像取得部と、前記画像取得部が順次出力する入力画像データから、予め定められている非障害時の画像データであると判別した入力画像データを除去し、非障害時の画像データでないと判別された入力画像データを出力する除去部と、前記除去部が出力した入力画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する判別障害検出部と、を備え、前記除去部は、スクリーンセーバーの画像データと、前記スクリーンセーバーが用いられるオペレーティングシステムの種別を示す情報と、を関連付けて格納するデータベースから情報を読み出し、前記入力画像データが前記スクリーンセーバーの画像データと一致すると判別したときに、当該画像データと前記データベースに関連付けて格納されている情報の示すオペレーティングシステムの種別が前記被監視装置のオペレーティングシステムの種別と一致すると判別した場合に、当該入力画像データを前記非障害時の画像データであると判別することを特徴としている。
また、本発明に係る監視装置において、前記除去部は、予め定められている第1の期間以内に、前記画像取得部が順次出力する入力画像データが切り替わった場合、当該入力画像データを前記非障害時の画像データであると判別するようにしてもよい。
また、本発明に係る監視装置において、前記オペレーティングシステムの種別を示す情報は、当該オペレーティングシステムのバージョンを示す情報を含むようにしてもよい。
上記目的を達成するため、本発明に係る監視方法は、画像取得部が、被監視装置から受信した1フレーム分の入力画像データを、順次、出力する画像取得工程と、除去部が、前記画像取得工程で順次出力された入力画像データから、予め定められている非障害時の画像データであると判別した入力画像データを除去し、非障害時の画像データでないと判別された入力画像データを出力する除去工程と、判別障害検出部が、前記除去工程で出力された入力画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する判別障害検出工程と、を含み、前記除去工程で、前記除去部が、スクリーンセーバーの画像データと、前記スクリーンセーバーが用いられるオペレーティングシステムの種別を示す情報と、を関連付けて格納するデータベースから情報を読み出し、前記入力画像データが前記スクリーンセーバーの画像データと一致すると判別したときに、当該画像データと前記データベースに関連付けて格納されている情報の示すオペレーティングシステムの種別が前記被監視装置のオペレーティングシステムの種別と一致すると判別した場合に、当該入力画像データを前記非障害時の画像データであると判別することを特徴としている。
本発明によれば、監視装置のノイズ除去部が、被監視装置が出力する画像データから非障害時の画像データを除去し、障害検出部が、被監視装置が出力する画像データから非障害時の画像データを除去した画像データに基づき障害を検出する。そして、障害が検出された場合、障害復旧手順実行部が、被監視装置に対して障害復旧処理を行うようにしたので、被監視装置のダウン状態を適切に検出することができる。
第1実施形態に係る監視システム1の概略構成図である。 同実施形態に係るノイズパターンDB230に格納されているデータの一例を説明する図である。 同実施形態に係るパニックパターンDB245に格納されているデータの一例を説明する図である。 同実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。 第2実施形態に係る監視システム1aの概略構成図である。 同実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。 第3実施形態に係る監視システム1bの概略構成図である。 同実施形態に係る被監視装置100の物理レイヤ400の構成の一例を説明する図である。
以下、図面を用いて、本発明の実施形態について説明する。なお、本発明は係る実施形態に限定されず、その技術思想の範囲内で種々の変更が可能である。
[第1の実施形態]
図1は、本実施形態に係る監視システム1の概略構成図である。
図1に示すように、監視システム1は、被監視装置100、監視装置200により構成されている。被監視装置100は、通信部110、ビデオ出力部120、キーボード信号入力部130、制御部140、電源部150を備えている。監視装置200は、ビデオ信号入力部205、画像取得部210、ノイズ除去部225、ノイズパターンDB230、障害検出部240、パニックパターンDB245、障害復旧手順実行部250、障害復旧手順DB255、通信部260、被監視装置属性DB280を備えている。
まず、被監視装置100について説明する。被監視装置100は、例えばサーバである。
通信部110は、ネットワーク・カードやネットワーク・コネクタなどであり、例えばLAN端子を有している。通信部110は、ネットワーク20を介してLANケーブル30で監視装置200と接続されている。通信部110は、制御部140が出力する情報を、ネットワーク20を介して監視装置200に送信する。通信部110は、監視装置200から送信された情報を、ネットワーク20を介して受信し、受信した情報を制御部140に出力する。
ビデオ出力部120は、例えばVGA出力端子を有している。ビデオ出力部120は、制御部140が出力するビデオ信号を出力する。
キーボード信号入力部130は、図示しないキーボードやマウスなどの入力装置からの入力信号が入力される端子を備えている。キーボード信号入力部130は、キーボードやマウスなどの入力装置から入力された信号を制御部140に出力する。
制御部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に保持されているアプリケーションの処理を行う。
電源部150は、外部から入力された電力を被監視装置100の各機能部に供給する。
次に、監視装置200について説明する。監視装置200は、被監視装置100の動作状態を監視する。そして、監視装置200は、被監視装置がダウン状態やパニック状態にあると検査された場合、後述するように故障復旧処理や被監視装置の管理者にメール等で通知する。
ビデオ信号入力部205は、被監視装置100が出力するビデオ信号が入力され、入力されたビデオ信号を画像取得部210に出力する。なお、被監視装置100のビデオ出力部120と、監視装置200のビデオ信号入力部205とは、ビデオケーブル10で接続されている。
画像取得部210は、ビデオ信号入力部205が出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをノイズ除去部225に出力する。
ノイズパターンDB(データベース)230には、例えば、OS毎に各種のスクリーンセーバーによるダウン時の画像パターンを模した画像データや、スクリーンセーバーによるパニック時に表示される画像パターンが、静止画形式または動画形式で格納されている。なお、スクリーンセーバーによるダウン時やパニック時の画像パターンを模した画像データとは、例えば、被監視装置100で動作しているOSまたは被監視装置100で動作しているOSと異なるOSのダウン時やパニック時に表示される画像を模した画像が表示されるスクリーンセーバーの画像データである。これらのスクリーンセーバーは、被監視装置100の管理者がインストールした場合や、OSが標準で備えている場合などがある。なお、スクリーンセーバーによるダウン時やパニック時に表示される画像に似せた特有の画像データを、ノイズパターンという。なお、ノイズパターンDB230に格納されるデータは、予め監視装置200の管理者等により、各種の被監視装置100を接続して取得したノイズパターンに該当する画像データが格納されるようにしてもよい。
図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への格納は必須である。
被監視装置属性DB(データベース)280には、被監視装置100の識別IDと、被監視装置100で起動されているOSの属性(バージョンを含む)が、予め関連づけられて格納されている。
ノイズ除去部225は、画像取得部210が出力する入力画像データが、ノイズパターンDB230に格納されている画像データと一致するか否かを判別する。入力画像データが、ノイズパターンDB230に格納されている画像データと一致する場合、ノイズ除去部225は、さらに、ノイズパターンDB230に格納されている画像データの属性が、被監視装置属性DB(データベース)280から読み出した監視装置100で起動されているOSの種別と一致するか否かを判別する。
画像データの属性とは、ノイズパターンDB230に画像データと関連付けられて記憶されているOSの種別である。すなわち、ノイズ除去部225は、入力画像データが、ノイズパターンDB230に格納されて、さらに属性が被監視装置100のOSの種別と一致する場合、被監視装置100が出力した画像データをスクリーンセーバーの画像データであると判断する。ノイズ除去部225は、属性が一致しない場合、予め定めた期間(第1の期間)、検出した画像データが持続するか否かを判別する。予め定められた期間以内に画像データが切り替わった場合、入力画像データをスクリーンセーバーの画像データであると判別する。ノイズ除去部225は、画像データがスクリーンセーバーの画像データであると判別した場合、その画像データをノイズパターンとして除去する。すなわち、入力画像データは、被監視装置100がダウン状態になった場合やパニック状態になった場合の画像パターンに似せたスクリーンセーバーの画像データである。このため、ノイズ除去部225は、この画像データをノイズパターンとして除去する。一方、ノイズ除去部225は、画像データがスクリーンセーバーの画像データでないと判別した場合、この画像データを、スクリーンセーバー以外の入力画像データである非スクリーンセーバー画像データとして、障害検出部240出力する。
一方、ノイズ除去部225は、入力画像データが、ノイズパターンDB230に格納されていなかった場合、入力画像データをそのまま、非スクリーンセーバー画像データとして、障害検出部240に出力する。
パニックパターンDB(データベース)245には、OS種別、障害時の画像データである障害画像データ、障害名などが関連付けられて格納されている。なお、パニックパターンDB245に格納されるデータは、予め監視装置200の管理者等により、各種の被監視装置100を接続して取得した障害時に該当する画像データが格納されるようにしてもよい。
図3は、本実施形態に係るパニックパターンDB245に格納されているデータの一例を説明する図である。図3に示すように、パニックパターンDB245には、OS種別、障害時の画像データ、障害名が関連づけられて格納されている。画像データは、静止画形式または動画形式の画像データである。
障害検出部240には、ノイズ除去部225が出力する非スクリーンセーバー画像データが入力される。障害検出部240は、入力された非スクリーンセーバー画像データが、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。障害検出部240は、非スクリーンセーバー画像データがパニックパターンDB245に格納されていると判別された場合、被監視装置100がダウン状態またはパニック状態になっていると判断する。障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。なお、画像データに関連付けられて格納されている被監視装置100の状態を示す情報とは、例えば、画像データがダウン時の画像データであればダウン状態、画像データがパニック時の画像データであればパニック状態、などのように、画像データ毎の被監視装置100の障害状態である。
障害復旧手順実行部250は、障害検出部240が出力する被監視装置100の障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害復旧手順実行部250は、読み出した故障復旧手順に従って、被監視装置100に対して故障復旧処理を行う。なお、故障復旧手順とは、後述するように、例えば、被監視装置100に対してポーリングを行い、あるいは、被監視装置100の管理者にメールで通知するなどの処理手順である。
障害復旧手順DB255には、予め監視装置200の管理者により、被監視装置100の障害状況に応じた故障復旧手順が、OS毎、障害毎に格納されている。
通信部260は、ネットワーク・カードやネットワーク・コネクタなどであり、例えばLAN端子を有している。通信部260は、ネットワーク20を介して被監視装置100と接続されている。通信部260は、障害復旧手順実行部250が出力する故障復旧処理を示す情報を、ネットワーク20を介して被監視装置100に送信する。また、通信部260は、被監視装置100から送信された情報を、ネットワーク20を介して受信し、受信した情報を障害復旧手順実行部250に出力する。
次に、ノイズパターンの除去と、パニック時の処理の一例について、図4を用いて説明する。図4は、本実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
(ステップS1)
監視装置200の画像取得部210は、ビデオ信号入力部205を介して、被監視装置100が出力する画像データを受信する。ステップS1終了後、ステップS2に進む。
(ステップS2)
次に、画像取得部210は、画像データを1フレーム分、受信し、受信した1フレーム分の入力画像データを、順次、ノイズ除去部225に出力する。ステップS2終了後、ステップS3に進む。
(ステップS3)
次に、ノイズ除去部225は、パターン検出部215が出力する入力画像データが、イズパターンDB230に格納されている画像データと一致するか否かを判別する。すなわち、ノイズ除去部225は、被監視装置100がダウン状態になった場合やパニック状態になった場合に出力する特有の画像パターンと一致するか否かを判別する。ステップS3終了後、ステップS4に進む。
(ステップS4)
入力画像データがノイズパターンDB230に格納されている画像データと一致すると判別された場合(ステップS4;Yes)、ステップS5に進む。この場合、入力画像データがノイズパターンDB230に格納されている画像データと一致すると判別されたため、入力画像データは、ダウン状態やパニック状態の画像データではなく、スクリーンセーバーの画像データ(ノイズパターン)である可能性がある。
入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別された場合(ステップS4;No)、ステップS8に進む。この場合、入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別されたため、入力画像データは、ノイズ画像データではない可能性がある。
(ステップ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とが一致しないため、ノイズ画像データではない(即ち実際のサーバ障害を示す画像である)可能性が高い。
(ステップS6)
ノイズ除去部225は、入力画像データがノイズパターンDB230に格納されている画像データと一致し且つOSの属性が一致しない場合、予め定めた期間、画像パターンの確認を続ける。この理由は、入力画像データが、被監視装置100で起動しているOSのダウン状態やパニック状態に似せたスクリーンセーバーであるか否かを再判別するためである。ステップS6終了後、ステップS7に進む。
(ステップS7)
スクリーンセーバーの場合、周期的に画像データが変化しながら繰り返される。このため、画像データが変化した場合、ノイズ除去部225は、画像データがスクリーンセーバーの画像データであると判断し(ステップS7;No)、ステップS1に戻る。
一方、予め定めた期間が過ぎても、画像データが変化しない場合(ステップS7;Yes)、被監視装置100がダウン状態かパニック状態になっている可能性が高いため、ノイズ除去部225は、非スクリーンセーバー画像データを 障害検出部240に出力し、ステップS8に進む。
すなわち、ノイズ除去部225は、被監視装置100が出力した入力画像データから、スクリーンセーバーの画像データを除去し、非スクリーンセーバー画像データを障害検出部240に出力する。
(ステップS8)
次に、障害検出部240は、ノイズ除去部225が出力する非スクリーンセーバー画像データを、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。非スクリーンセーバー画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合、障害検出部240は、一致した画像データに基づき、被監視装置100がダウン状態かパニック状態であると判断する。
すなわち、非スクリーンセーバー画像データが、ダウン状態の画像データと一致した場合、障害検出部240は、被監視装置100がダウン状態であると判別する。あるいは、非スクリーンセーバー画像データが、パニック状態の画像データと一致した場合、障害検出部240は、被監視装置100がパニック状態であると判別する。
次に、障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。被監視装置100の障害状態を示す情報とは、被監視装置100がダウン状態を示す情報、または、被監視装置100がパニック状態を示す情報である。ステップS8終了後、ステップS9に進む。
(ステップ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を介してメール等で通知する。
以上のように、監視装置200のノイズ除去部225は、取得した入力画像データからダウン状態やパニック状態の画像データに似せたスクリーンセーバーによるノイズパターンを検出して除去する。そして、障害復旧手順実行部250は、非スクリーンセーバー画像データに基づき、被監視装置100に障害が生じているか判別し、障害が生じている場合に故障復旧手順を実行する。さらに、障害復旧手順実行部250は、被監視装置100の通信部110に対してポーリング処理を行うことで、被監視装置100のビデオ信号出力部120の故障なのか、ダウン状態またはパニック状態なのかを判断する。
この結果、ダウン時やパニック時の画像データに似せたスクリーンセーバーが稼働した場合でも、監視装置200は、被監視装置100が正常に動作していると判別でき、被監視装置100に対して誤って故障復旧処理を行うことを防ぐことができる。また、監視装置200は、被監視装置100が、ダウン状態やパニック状態にあることを適切に検出でき、検出した場合に適切に故障復旧処理を行うことができる。
なお、本実施形態では、ステップS5で、ノイズ除去部225が、被監視装置100で起動しているOSと、画像データのOS種別との属性チェックする例を説明したが、ステップS5の属性チェックは行わなくてもよい。この場合、ステップS4でYesの場合、そのままステップS6に進み、予め定めた期間が経過したか否かの判別(ステップS7)により、スクリーンセーバー動作か否かを判別するようにしてもよい。
また、被監視装置100が出力する画像データが、例えば、刻々と変化するカウンタ値を含むようなパニック状態に似せた画像データのスクリーンセーバーの場合、このカウンタ値が変化する動画形式の画像データをノイズパターンDB230に格納させておき、ノイズ除去部225が、入力画像データと比較して判別するようにしてもよい。このようなスクリーンセーバーの場合、例えば、カウンタ値の前に固定のプレフィックス文字列が含まれている。このため、ノイズ除去部225は、入力画像データから、このカウンタ値の前に含まれる固定のプレフィックス文字列の部分を抽出し、抽出した画像データがノイズパターンDB230に格納されているか否かを判別してノイズ除去するようにしてもよい。
また、被監視装置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)アドレスであってもよい。
[第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実施形態と同じ機能部は、同じ符号を用いて説明を省略する。
まず、被監視装置100aについて説明する。
キーボード信号入力部130aは、図示しないキーボードやマウスなどの入力装置からの入力信号、および、監視装置200aからの入力信号が入力される端子を備えている。キーボード信号入力部130aは、キーボードやマウスなどの入力装置、および、監視装置200aから入力された信号を制御部140に出力する。
電源部150は、電源制御蔵置300から入力された電力を被監視装置100の各機能部に供給する。
次に、監視装置200について説明する。
画像取得部210aは、ビデオ信号入力部205、または、通信部260が出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをパターン検出部215に出力する。
計時部220は、時間を示す情報を生成し、生成した時間を示す情報をパターン検出部215に出力する。
パターン検出部215は、画像取得部210が出力する入力画像データの中から公知の画像認識により、計時部220が出力する時間を示す情報に基づき、予め定められた期間(第2の期間)、黒信号が連続するブラックアウト状態を検出する。パターン検出部215は、例えば、画像認識の手法として、パターンマッチング手法などを用いる。
予め定められた期間、黒信号が連続するブラックアウト状態を検出する理由は、一般的なスクリーンセーバーの場合、一度、表示が黒になった後(この状態をブラックアウトという)、スクリーンセーバーの画像データが出力される。したがって、パターン検出部215は、スクリーンセーバーの動作が開始したことを検出するため、このブラックアウトを検出する。パターン検出部215は、ブラックアウトを検出した場合、ノイズ除去部225にブラックアウト検出後の入力画像データを順次、フレーム毎に出力する。
障害検出部240aには、ノイズ除去部225が出力する非スクリーンセーバー画像データが入力される。障害検出部240は、入力された非スクリーンセーバー画像データが、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。障害検出部240aは、非スクリーンセーバー画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合、被監視装置100がダウン状態またはパニック状態になっていると判断する。障害検出部240は、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100の状態を示す情報を読み出し、読み出した被監視装置100の障害状態を示す情報を障害復旧手順実行部250に出力する。
また、障害検出部240aは、非スクリーンセーバー画像データがパニックパターンDB245に格納されている画像データと一致しない判別された場合、ノイズパターンDB230に格納されていない新たなノイズパターンの画像であるため、非スクリーンセーバー画像データをノイズパターン学習部235に出力する。
ノイズパターン学習部235は、障害検出部240aが出力する画像データを学習してノイズパターンDB230に学習させる。
障害復旧手順実行部250aは、障害検出部240が出力する被監視装置100の障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害復旧手順実行部250aは、読み出した故障復旧手順に従って、電源制御装置300、および、被監視装置100に対して故障復旧処理を行う。
通信部260aは、ネットワーク20を介して被監視装置100と接続されている。通信部260aは、障害復旧手順実行部250が出力する故障復旧処理を示す情報を、ネットワーク20を介して被監視装置100に送信する。また、通信部260aは、被監視装置100から送信された情報を、ネットワーク20を介して受信し、受信した情報が画像データの場合、受信した画像データを画像取得部210aに出力する。
電源制御装置300は、外部からの電力を被監視装置100に供給する装置である。電源制御装置300は、監視装置200からの制御により、被監視装置100に供給する電圧を停止、または供給開始するように制御する。
次に、ノイズパターンの除去と、パニック時の処理の一例について、図6を用いて説明する。図6は、本実施形態に係るノイズパターンの除去と、パニック時の処理のフローチャートである。
(ステップS101、S102)
ステップS101とS102は、第1実施形態のステップS1、S2と同様に行う。ステップS102終了後、ステップS103に進む。
(ステップS103)
次に、パターン検出部215は、計時部220が出力する時間を示す情報に基づき、予め定めた期間以上、画像取得部210aが出力する入力画像データがブラックアウトしたか否かを公知の画像認識により検出する。この処理の理由は、一般的なスクリーンセーバーの場合、入力画像データが、一度ブラックアウトした後、スクリーンセーバーが起動されるためである。ブラックアウトを検出した場合、パターン検出部215は、入力された入力画像データをノイズ除去部225に出力する。ステップS103終了後、ステップS104に進む。
(ステップS104〜S108)
ステップS104〜S108は、ステップS3〜S7と同様に行う。
(ステップS109)
次に、障害検出部240aは、ノイズ除去部225が出力する非スクリーンセーバー画像データを、パニックパターンDB245に格納されている画像データと一致するか否かを判別する。ステップS109終了後、ステップS110に進む。
(ステップS110)
入力画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合(ステップS110;Yes)、ステップS112に進む。この場合、障害検出部240aは、一致した画像データに基づき、被監視装置100aがダウン状態かパニック状態であると判断する。
入力画像データがパニックパターンDB245に格納されている画像データと一致しないと判別された場合(ステップS110;No)、ステップS111に進む。この場合、入力画像データがパニックパターンDB245に格納されている画像データと一致しないと判別されたため、障害検出部240aは、被監視装置100aが正常動作状態であると判別する。次に、障害検出部240aは、入力画像データが、ノイズパターンDB230に、まだ格納されていないと判別する。
(ステップS111)
入力画像データがノイズパターンDB230に格納されている画像データと一致しないと判別された場合(ステップS110;No)、障害検出部240aは、非スクリーンセーバー画像データをノイズパターン学習部235に出力する。
次に、ノイズパターン学習部235は、障害検出部240aが出力する非スクリーンセーバー画像データをノイズパターンDB230に学習させる。ステップS111終了後、ステップS101に戻る。
(ステップS112)
非スクリーンセーバー画像データがパニックパターンDB245に格納されている画像データと一致すると判別された場合(ステップS110;Yes)、障害検出部240aは、一致した画像データに基づき、被監視装置100aがダウン状態かパニック状態であると判断する。
次に、障害検出部240aは、パニックパターンDB245に格納されている画像データに関連付けられて格納されている被監視装置100aの状態を示す情報を読み出し、読み出した被監視装置100aの障害状態を示す情報を障害復旧手順実行部250aに出力する。
次に、障害復旧手順実行部250aは、障害検出部240aが出力する被監視装置100aの障害状態を示す情報に基づき、障害復旧手順DB255から故障復旧手順を読み出す。障害検出部240は、読み出した故障復旧手順に従って、被監視装置100に対して故障復旧処理を行う。例えば、障害復旧手順実行部250aは、ソフトウェア・リセットのキーの組み合わせ以外のいずれかのキーが押された状態を示す信号を生成し、または、マウスを動かした状態を示す信号を生成する。そして、障害復旧手順実行部250aは、生成したいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を、被監視装置100aのキーボード信号入力部130aに送信し、画像データが変化するか否かを確認する。このような処理を行っても、画像データが変化しない場合、障害復旧手順実行部250aは、さらに以下の処理を行う。
障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信する。なお、ソフトウェア・リセットのキーの組み合わせ信号とは、例えば、Ctrl(コントロール)キーとAltキーとDeleteキーを同時に押した場合の信号である。
次に、障害復旧手順実行部250aは、予め定められた時間後、例えば、被監視装置100aの通信部110に対してポーリング処理を行い、ソフトウェア・リセット処理が実行できたか否かを確認する。被監視装置100aから応答が無い場合、障害復旧手順実行部250aは、再度、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信する。なお、予め定められた時間とは、被監視装置100aに対してソフトウェア・リセット処理を行わせ、再起動するまでの時間以上の時間であり、例えば120秒である。
また、被監視装置100aのキーボード信号入力部130へソフトウェア・リセットのキーの組み合わせ信号を送信する前に、障害復旧手順実行部250aは、被監視装置100aの管理者に対して、被監視装置100を再起動することを示す情報を、ネットワーク20を介してメール等で送信する。そして、管理者から了解を得た後に、障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、ソフトウェア・リセットのキーの組み合わせ信号を送信するようにしてもよい。
このように被監視装置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への通電を停止する指示を送信するようにしてもよい。
以上のように、故障復旧手順として、まず、監視装置200aは、被監視装置100aにソフトウェア・リセットのキーの組み合わせ以外のいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を送信する。これにより、被監視装置100aからの入力画像データがスクリーンセーバーによる画像データの場合、これらの処理により、画像データが変化する。この処理により、被監視装置100aの画像データは、スクリーンセーバーの画像データから、通常動作時の画像データに復帰する。この結果、監視装置200aは、被監視装置100aの状態を適切に監視できる。
また、上述の処理を行っても入力画像データが変化しない場合、監視装置200aは、被監視装置100aにソフトウェア・リセットのキーの組み合わせ信号を送信して、被監視装置100aに対してソフトウェア・リセットを行う。この結果、監視装置200aは、被監視装置100aを適切に故障復旧させることができる。
また、被監視装置100aに対してソフトウェア・リセットを行っても被監視装置100aが再起動しない場合、監視装置200aは、電源制御装置300に対して、被監視装置100aへの電力の供給を停止する指示を送信する。そして、電力の供給を停止する指示を送信後、予め定めた時間後に、監視装置200aは、被監視装置100aへの電源供給を再開して再起動するようにした。この結果、監視装置200aは、被監視装置100aを適切に故障復旧させることができる。
また、本実施形態では、ステップS111で、ノイズパターン学習部235が、画像データをノイズパターンDB230に学習させる例を説明したが、画像データ、画像データ形式、画像データ表示計測時間、OS種別などを関連づけて、ノイズパターンDB230に学習させるようにしてもよい。
また、本実施形態では、監視装置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に出力する。
また、本実施形態では、障害復旧手順実行部250aが、まず被監視装置100aにいずれかのキーが押された状態を示す信号、または、マウスを動かした状態を示す信号を送信して、被監視装置100aがダウン状態またはパニック状態になっているか再判断する例を説明した。しかしながら、被監視装置100aがダウン状態またはパニック状態になっているかの再判別は、これに限られない
例えば、障害復旧手順実行部250aは、第1実施形態と同様に、被監視装置100aの通信部110へポーリング処理を行っても被監視装置100aから応答が無い場合、障害復旧手順実行部250aは、被監視装置100aのキーボード信号入力部130aに、例えばソフトウェア・リセットのキーの組み合わせ信号を送信するようにしてもよい。
[第3実施形態]
次に、本実施形態について、図1と図7を用いて説明する。なお、図5の構成を用いても同様の効果が得られる。
本実施形態は、被監視装置100bのホストOS上で、複数の仮想マシン(Virtual Machine)が動作している。なお、仮想マシンとは、OSが動作する実際のコンピュータを仮想的に構築したものである。これにより、1台のコンピュータを仮想マシンに分割することで、複数のOSを並列に実行させることができる。
図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を備えている。
被監視装置100bの制御部140bは、仮想マシンのOSにより生成された画像データをビデオ出力部120−1〜120−nに出力する。
このように、複数のビデオ信号出力部を有する理由120−1〜120−nは、仮想マシンの中には、ホストOSの全画面を使って動作するものもあるからである。このような場合、被監視装置100bから出力される画像データは、一般的には被監視装置100bに接続されている図示しない表示装置に表示されている仮想マシンVMの画像データのみで、他の仮想マシンのVMはバックグランドで動作し、画像データが図示しない表示装置に表示されていない。すなわち、ビデオ出力部が1つのみの場合、図示しない表示装置に表示されている画像データのみが、監視装置200bに出力されることになる。このため、被監視装置100bは、複数のビデオ出力部120−1〜120−nを備えることが好ましい。
監視装置200bのビデオ信号入力部205−1〜205−nは、被監視装置100bが出力するビデオ信号が各々入力され、入力されたビデオ信号を画像取得部210bに出力する。なお、被監視装置100bのビデオ出力部120−1と監視装置200のビデオ信号入力部205−1とは、ビデオケーブル10−1で接続されている。同様に、被監視装置100bのビデオ出力部120−nと監視装置200のビデオ信号入力部205−nとは、ビデオケーブル10−nで接続されている。
画像取得部210bは、ビデオ信号入力部205−1〜205−nが出力するビデオ信号を取得し、取得したビデオ信号の入力画像データをノイズ除去部225に出力する。
被監視装置属性DB280bには、被監視装置100の識別IDと、被監視装置100bで起動されているOSの属性(バージョンを含む)が、予め関連づけられて格納されている。また、被監視装置属性DB280bには、被監視装置100bで起動されている仮想マシン毎の識別IDと、仮想マシン毎のOSの属性が関連づけられて格納されている。
図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である。
例えば、被管理装置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のフローチャートと同様に、各仮想マシンに障害が生じていないか監視する。
図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の管理者に送信する。
なお、本実施形態では、画像データに付けられた識別IDを用いて、仮想マシンを識別する例を説明したが、識別は識別IDを使用しなくても良い。この場合、ホストOS上で動作している仮想マシンのOSの種類やバージョン特有の画像データを正常動作時に監視装置200bの画像取得部210bが検出する。そして、検出した結果に基づき、障害検出部240が、仮想マシンを識別するようにしてもよい。
本実施形態では、被監視装置100が複数のビデオ信号出力部を備える例を説明したが、ビデオ信号出力部は、1つでもよい。この場合、被監視装置100は、仮想マシンVMとVMとの画像データに識別子を付けて、例えば時分割して交互に送信する。
そして、監視装置200bのビデオ信号入力部205bは、このように送信された画像データを取得し、取得した画像データを用いて、各仮想マシンに障害が生じていないかを検出するようにしてもよい。
なお、本実施形態では、被監視装置100、100a、および100bが1台の例を説明したが、被監視装置は複数であってもよい。この場合、監視装置200、200aは、複数の被監視装置が出力する画像データを時分割で受信するか、あるいは、図7に示した監視装置200bのように複数のビデオ信号入力部を備えるようにしてもよい。
なお、上述した実施形態における図1、図5および図7の監視装置200、200a、および、200bの一部をコンピュータで実現するようにしても良い。その場合、この制御機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピュータシステム」とは、監視装置200に内蔵されたコンピュータシステムであって、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
また、上述した実施形態における監視装置、200a、および、200bの一部、または全部を、LSI(Large Scale Integration)等の集積回路として実現しても良い。また、監視装置200の各機能ブロックは個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化しても良い。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現しても良い。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いても良い。
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

Claims (4)

  1. 被監視装置から受信した1フレーム分の入力画像データを、順次、出力する画像取得部と、
    前記画像取得部が順次出力する入力画像データから、予め定められている非障害時の画像データであると判別した入力画像データを除去し、非障害時の画像データでないと判別された入力画像データを出力する除去部と、
    記除去部が出力した入力画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致する判別した場合、前記被監視装置に障害が発生していると判別する判別障害検出部と、
    を備え、
    前記除去部は、
    スクリーンセーバーの画像データと、前記スクリーンセーバーが用いられるオペレーティングシステムの種別を示す情報と、を関連付けて格納するデータベースから情報を読み出し、
    前記入力画像データが前記スクリーンセーバーの画像データと一致すると判別したときに、当該画像データと前記データベースに関連付けて格納されている情報の示すオペレーティングシステムの種別が前記被監視装置のオペレーティングシステムの種別と一致すると判別した場合に、当該入力画像データを前記非障害時の画像データであると判別することを特徴とする監視装置。
  2. 記除去部は、
    予め定められている第1の期間以内に、前記画像取得部が順次出力する入力画像データが切り替わった場合、当該入力画像データを前記非障害時の画像データであると判別することを特徴とする請求項1に記載の監視装置。
  3. 前記オペレーティングシステムの種別を示す情報は、当該オペレーティングシステムのバージョンを示す情報を含むことを特徴とする請求項1又は2に記載の監視装置。
  4. 画像取得部が、被監視装置から受信した1フレーム分の入力画像データを、順次、出力する画像取得工程と、
    除去部が、前記画像取得工程で順次出力された入力画像データから、予め定められている非障害時の画像データであると判別した入力画像データを除去し、非障害時の画像データでないと判別された入力画像データを出力する除去工程と、
    判別障害検出部が、前記除去工程で出力された入力画像データが、予め定められている前記被監視装置の障害時の画像データである障害画像データと一致すると判別した場合、前記被監視装置に障害が発生していると判別する判別障害検出工程と、
    を含み、
    前記除去工程で、
    前記除去部が、
    スクリーンセーバーの画像データと、前記スクリーンセーバーが用いられるオペレーティングシステムの種別を示す情報と、を関連付けて格納するデータベースから情報を読み出し、
    前記入力画像データが前記スクリーンセーバーの画像データと一致すると判別したときに、当該画像データと前記データベースに関連付けて格納されている情報の示すオペレーティングシステムの種別が前記被監視装置のオペレーティングシステムの種別と一致すると判別した場合に、当該入力画像データを前記非障害時の画像データであると判別することを特徴とする監視方法。
JP2011076641A 2011-03-30 2011-03-30 監視装置、及び監視方法 Active JP5683354B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011076641A JP5683354B2 (ja) 2011-03-30 2011-03-30 監視装置、及び監視方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011076641A JP5683354B2 (ja) 2011-03-30 2011-03-30 監視装置、及び監視方法

Publications (2)

Publication Number Publication Date
JP2012212243A JP2012212243A (ja) 2012-11-01
JP5683354B2 true JP5683354B2 (ja) 2015-03-11

Family

ID=47266152

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011076641A Active JP5683354B2 (ja) 2011-03-30 2011-03-30 監視装置、及び監視方法

Country Status (1)

Country Link
JP (1) JP5683354B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6524603B2 (ja) * 2014-02-20 2019-06-05 株式会社リコー 画像表示装置及び画像表示方法
JP7216767B2 (ja) * 2021-05-06 2023-02-01 楽天グループ株式会社 アクセス方法、通信システム、及びプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0816121A (ja) * 1994-06-30 1996-01-19 Canon Inc 表示制御装置及び方法
JPH08286954A (ja) * 1995-04-19 1996-11-01 Oki Electric Ind Co Ltd ネットワーク管理システム
JP3223872B2 (ja) * 1997-12-12 2001-10-29 日本電気株式会社 サーバ群表示監視装置
JP2003162429A (ja) * 2001-11-26 2003-06-06 Nec Fielding Ltd 画像情報伝送による故障解析装置、故障解析システム、故障解析方法、及びプログラム
JP2004295387A (ja) * 2003-03-26 2004-10-21 Sharp Corp 検査装置および検査方法
JP4045447B2 (ja) * 2004-03-02 2008-02-13 日本電気株式会社 システム特定方法およびサーバ監視システム
JP2006065659A (ja) * 2004-08-27 2006-03-09 Fujitsu Ltd コンピュータ動作記録プログラム、コンピュータ動作解決プログラム、コンピュータ、管理装置、および方法
JP4648074B2 (ja) * 2005-04-28 2011-03-09 パナソニック株式会社 携帯サイト監視システム
JP2009093466A (ja) * 2007-10-10 2009-04-30 Nec Corp 管理システム、監視サーバ、管理者サーバ、監視方法および監視プログラム
JP4842917B2 (ja) * 2007-12-07 2011-12-21 富士通株式会社 後続処理の自動処理プログラム,後続処理の自動処理装置および後続処理の自動処理方法
JP4941520B2 (ja) * 2009-08-12 2012-05-30 日本電気株式会社 障害要因通知装置、障害要因通知システム、障害要因通知方法および障害要因通知プログラム
JP5084798B2 (ja) * 2009-08-24 2012-11-28 日本電信電話株式会社 アプリケーション状態認識方法、装置及びプログラム

Also Published As

Publication number Publication date
JP2012212243A (ja) 2012-11-01

Similar Documents

Publication Publication Date Title
EP3232326B1 (en) Keyboard video mouse (kvm) device and method for detecting host failure using the same
CN106293979B (zh) 检测进程无响应的方法和装置
JP5579650B2 (ja) 監視対象プロセスを実行する装置及び方法
WO2018095107A1 (zh) 一种bios程序的异常处理方法及装置
US20080270827A1 (en) Recovering diagnostic data after out-of-band data capture failure
CN111767066A (zh) 用于现场减轻固件故障的方法和设备
CN108292342B (zh) 向固件中的侵入的通知
JP6354901B2 (ja) 仮想マシンの故障検知および回復用管理システム
KR20040047209A (ko) 네트워크 상의 컴퓨터 시스템의 자동 복구 방법 및 이를구현하기 위한 컴퓨터 시스템의 자동 복구 시스템
WO2015034619A1 (en) Rootkit detection in a computer network
JP5683354B2 (ja) 監視装置、及び監視方法
US11922199B2 (en) Associating security tags to continuous data protection checkpoints/snapshots/point-in-time images
WO2024119787A1 (zh) Amd服务器系统安装断电处理方法、装置、设备及介质
JP6128388B2 (ja) 情報処理装置
CN106406963B (zh) 一种Linux系统的初始化方法和装置
CN112069032A (zh) 一种虚拟机的可用性检测方法、系统及相关装置
JP5689783B2 (ja) コンピュータ、コンピュータシステム、および障害情報管理方法
CN109032643A (zh) 软件更新的方法和装置
CN114651240A (zh) 安全检查
CN116701055A (zh) 一种服务器的故障隔离方法、装置、设备及介质
TWI518519B (zh) 伺服器系統與節點替換方法
JP2006268277A (ja) アプリケーションプログラムの復旧方式
CN104657166A (zh) 服务器系统与节点替换方法
JP2005078122A (ja) ロック状態検出装置およびロック状態検出方法ならびにそのプログラム
CN115720202A (zh) 一种云平台存储链路监测方法、装置、介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130328

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20130515

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20130816

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140204

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140314

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140707

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141216

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150113

R150 Certificate of patent or registration of utility model

Ref document number: 5683354

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250