JP2017158081A - ネットワーク機器監視装置 - Google Patents

Abstract

【課題】物理ポートの生存を確認するだけでなく、特定のポート番号のサービスが正常に動作していることを確認し、ネットワーク機器監視装置１００に異常検出時の処理でそのサービスが動作するサーバの再稼働処理を可能にする手段を提供する。【解決手段】ネットワーク装置は、ＣＰＵ１０１、リレーコントローラ３０３、１又は２以上のリレー３１１、３１２、３１３及びコンセント３２１、３２２、３２３を含む。ネットワーク機器監視装置１００のＣＰＵ１０１がトランスポート層の１のサービスに異常を検出した際には、リレーコントローラ３０３中のあるレジスタに書き込むことで対応するリレーのＯＮ／ＯＦＦを行う。これにより電源からの対応するコンセントへの電力供給がＯＮ／ＯＦＦされ、該コンセントにつながるネットワーク機器の再起動が可能になる。【選択図】図１

Description

本発明は、ネットワークに接続された機器の監視装置、特に自動電源再起動機能を保持するものに関する。

ネットワーク及びインターネットに接続されたネットワーク通信機器（以下ネットワーク機器）の数は日々増大する一方である。ネットワークに接続された機器にフレキシブルな接続性を提供するためのＤＨＣＰ、ネットワークに接続する不特定多数に情報の提供を行うためのＨＴＴＰ、ネットワーク機器の監視に用いるＳＮＭＰ、ＴＣＰに対してセキュリティを付加するＳＳＬなどサービスの提供に供されるアプリケーションは日々増えるばかりである。

これらのサービスはネットワーク機器の物理ポート（物理層）に接続され、提供される。そしてこれらの物理ポートにはＭＡＣアドレス（データリンク層）及びＩＰアドレス（ネットワーク層）が付与される。そして、各サービス（アプリケーション）にはそれぞれポート番号（トランスポート層）が付与され、そのＭＡＣアドレス、ＩＰアドレス、ポート番号宛にリクエストなどが送信されることでサービスが提供される。もっとも有名なポート番号はＨＴＴＰサーバに割り当てられた「８０」であろう。

昔はこれらのサービスを提供するためにそれぞれにサーバ１台が割り当てられていることが多かった。このような状態であれば、物理ポート一つに対してポート番号は一つであり、サービスの提供が滞りなく行われているかを見るのにネットワーク層に当たるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＰＩＮＧコマンドを用いて返答が返ってくるかを見ればよかった。そして現在においてもネットワーク機器の監視にはＰＩＮＧコマンドを用いることが多い。

このＰＩＮＧコマンドについては、ＩＰｖ４のＩＣＭＰプロトコルはＲＦＣ７９２（非特許文献１）で、ＩＰｖ６のＩＣＭＰプロトコルはＲＦＣ４４４３（非特許文献２）で規定されている。

ＲＦＣ７９２ ＲＦＣ４４４３

しかし、サーバの処理能力が増大することで、単一のサーバに複数のサービスが実装されることは今や当たり前になっている。このような場合だと、例え物理ポートが開いていたとしても、特定のポート番号に対応したプログラムが落ちていた場合には再稼働処理を行うか判断が必要な場合がある。

すなわち、特定のポート番号に対応したプログラムが動作していたとしても、そのサービスの提供の前段階で用いるサービスがダウンしていた場合には、ダウンしていたサービスを再稼働すべく再稼働処理を行う必要がある場合も考えられる。

本発明の目的は、物理ポートの生存を確認するだけでなく、特定のポート番号のサービスが正常に動作していることを確認し、異常検出時の処理でそのサービスが動作するサーバの再稼働処理を可能にする手段を提供することにある。
また本発明の別の目的は、ポート番号により再稼働処理を行うか否かを決める手段を提供することにある。

本発明のさらに他の目的および利点は、以下の説明から明らかになろう。

本発明に関わるネットワーク機器監視装置は、ネットワーク層及びトランスポート層のプロトコルに従ってネットワーク機器を監視するものであって、ネットワーク層での異常検出時の処理とトランスポート層での異常検出時の処理が異なることを特徴とする。

このネットワーク機器監視装置において、該ネットワーク機器監視装置はＣＰＵ、リレーコントローラ及びリレーコントローラに制御されるリレーを含み、トランスポート層での異常検出時の処理として、ＣＰＵがリレーを制御するようリレーコントローラに指示することを特徴としても良い。

このネットワーク機器監視装置において、リレーが電源供給を制御することを特徴としても良い。

このネットワーク機器監視装置において、リレーがネットワーク機器への電源供給を制御することを特徴としても良い。

これらのネットワーク機器監視装置において、前記異常検出時の処理をユーザが変更可能な手段を持つことを特徴としても良い。

本発明に関わる別のネットワーク機器監視装置は、ネットワーク層及びトランスポート層のプロトコルに従ってネットワーク機器を監視するネットワーク機器監視装置であって、
該ネットワーク機器監視装置は１のネットワーク層を利用しかつ異なるトランスポート層を利用する２以上のアプリケーションの異常を別個独立に監視することが可能なことを特徴とする。

本発明に関わるネットワーク機器監視装置によって、ネットワーク層及びトランスポート層ごとに異常検出時の処理を変えることが可能になる。より具体的には、ネットワーク層で異常が検出された場合には、ネットワーク機器監視装置の適切なリレーをＯＮ／ＯＦＦすることで、検出対象のネットワーク機器の再起動を行い、トランスポート層で異常を検出した際には、サービス単位での是正を図ることなどが考えられる。
また本発明に関わるネットワーク機器監視装置によって、ネットワーク層及びトランスポート層での異常検出時の処理をユーザが任意に変更することが可能となる。

本発明に関わるネットワーク機器監視装置の物理的電気的構成を表す概念図である。 第１の実施の形態に関わるネットワーク機器監視装置の動作環境の一例を表す接続図である。 ネットワーク機器監視装置上でＣＰＵが処理する監視モジュールの動作の概略を説明するフローチャートである。 ネットワーク機器監視装置が自身の設定情報及び現在の監視対象の状況をユーザに開示する為の処理の流れを表すフローチャートである。 第１の実施の形態での図４の処理を行った後に開示要求（Ｒｅｑｕｅｓｔ）の送信元に送られてきた出力データを端末のブラウザ上で表示させた結果である。 ネットワーク機器監視装置が自身の設定情報の変更を反映する為の処理の流れを表すフローチャートである。 第１の実施の形態での監視用画面を表す図である。 第２の実施の形態に関わるネットワーク機器監視装置の動作環境の一例を表す接続図である。 第２の実施の形態での開示要求（Ｒｅｑｕｅｓｔ）の送信元に送られてきた出力データを端末のブラウザ上で表示させた結果である。

以下本発明の実施の形態を図に基いて説明する。

（第1の実施の形態）
（ハードウェアの説明）
図１は、本発明の第１の実施の形態にかかわるネットワーク機器監視装置の物理的電気的構成を表す概念図である。

本発明に関わるネットワーク機器監視装置１００はＣＰＵ１０１、バスコントローラ１０２、メモリ２０１、周辺用バスコントローラ２０２、ＬＡＮ Ｉ／Ｆ３０１、ＬＥＤコントローラ３０２、リレーコントローラ３０３、リレー３１１、３１２，３１３、コンセント３２１、３２２、３２３を含んで構成される。

ＣＰＵ１０１は、メモリ２０１中に記録されたプログラムに従い処理を行う中央制御装置である。本明細書ではＣＰＵとしているが、ＭＰＵでも問題はない。またいわゆるＣＰＵ１０１内のＣＰＵコアの数は拘泥しないが、時分割による疑似的なマルチタスクには対応していることが好ましい。

バスコントローラ１０２は、ＣＰＵ１０１がメモリ２０１等にアクセスする際に経由するチップセットである。

その性質上バスコントローラ１０２は、内部バスａ及び外部バスｂに接続されており、ＣＰＵ１０１から外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信を制御する。

市場ではＣＰＵ１０１の種類に対応してバスコントローラ１０２は製品（専用品）が用意されているが、ＣＰＵ１０１と外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信ができれば良い。

メモリ２０１は、ＣＰＵ１０１が実行するプログラム及び処理の対象となるデータ（ネットワーク機器監視装置の設定など）を記録するためのメモリである。通常だとＤＲＡＭのような揮発性記憶素子と電源を切っても保持されるＮＶＲＡＭのような不揮発的な記憶素子、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に分けて考えられるが、本明細書では全てを包含してメモリ２０１とする。

周辺用バスコントローラ２０２は、ＣＰＵ１０１等が外部バスｂから周辺用バスｃ上にあるコントローラを制御する際に経由するチップセットである。
バスコントローラ１０２同様、周辺用バスコントローラ２０２も外部バスｂ及び周辺用バスｃに接続されている。周辺用バスコントローラ２０２は、ＣＰＵ１０１から外部バスｂ及び周辺用バスｂに存在するコントローラ等との通信を制御する。
市場ではＣＰＵ１０１の種類に対応して周辺用バスコントローラ２０２も製品（専用品）が用意されるが、本実施の形態ではＣＰＵ１０１と周辺用バスに存在するコントローラ等との通信ができれば良い。

ＬＡＮ Ｉ／Ｆ３０１は、ＨＵＢ５００に接続する為のコネクタ（物理層）及びチップ（データリンク層、ネットワーク層）などを含むインターフェイス群である。このＬＡＮ Ｉ／Ｆ３０１を経由して他のネットワーク機器との通信を行う。このＬＡＮ Ｉ／Ｆ３０１は、ＨＵＢ５００と接続可能なものでなければならないことは言うまでもない。

このＬＡＮ Ｉ／Ｆ３０１が複数ある場合には、ＬＡＮ Ｉ／ＦごとにＩＰアドレスが割り振られる。従って、ネットワーク機器監視装置１００が無線ＬＡＮと有線ＬＡＮの二つのポートを有する場合には、其々にＩＰアドレスが割り振られることに注意する。

ＬＥＤコントローラ３０２は、ネットワーク機器監視装置１００の状態をユーザに伝達する為のＬＥＤを制御するためのコントローラである。本図では省略しているが、ＬＥＤコントローラ３０２は図示しないＬＥＤが接続され、これを点灯、点滅させることでユーザにネットワーク機器監視装置１００の状態を伝える。

リレーコントローラ３０３は、リレー３１１，３１２、３１３を制御するためのコントローラである。ネットワーク機器監視装置１００の製品仕様に応じて、制御するリレーの最低必要数が決定される。そしてそのリレーの数に応じてリレーコントローラ３０３はレジスタを持つ。ＣＰＵ１０１はリレーコントローラ３０３中の該当するレジスタに１／０を書き込むことで、該当するリレーをＯｎ／Ｏｆｆし、対応するコンセントへの電源供給を制御する構造になっている。但しこれに拘るものでなく、いかなる方法であってもリレーを制御できる手段を提供できれば、リレーコントローラ３０３の役割を果たすことが可能である。

リレー３１１、３１２，３１３は、電源からコンセントへの電力供給を制御するための継電器である。リレー３１１、３１２，３１３は、リレーコントローラ３０３からの制御信号によってそれぞれ独立して対応するコンセントへの電力供給が制御可能なように構成されている。

コンセント３２１、３２２、３２３は、ネットワーク機器監視装置１００から監視対象のネットワーク機器に電力を供給するためのコンセントである。各コンセントは対応するリレーに接続されることで、ＣＰＵ１０１による制御が可能になっている。

なお、監視対象のネットワーク機器とコンセントの接続を適切に行わないと、該ネットワーク機器に異常が発生し電源を切断するときに異なるネットワーク機器の電源を切断することになるため、ユーザは注意を払って接続及びネットワーク機器監視装置１００の設定を行うべきである。

次に図２を用いて、ネットワーク機器監視装置１００の接続方法について説明する。
図２は、本発明の第１の実施の形態にかかわるネットワーク機器監視装置１００の動作環境の一例を表す接続図である。

本図ではＨＵＢ５００に、ネットワーク機器監視装置１００、ルータ５０１、ＨＴＴＰサーバ５０２、決済サーバ５０３、モニタ用ＰＣ５０４が接続され、それぞれがネットワーク層のレベルで通信可能なように構成される。

また、ルータ５０１、ＨＴＴＰサーバ５０２、決済サーバ５０３の電源ケーブルはネットワーク機器監視装置１００のコンセント３２１、３２２、３２３にそれぞれ接続され、ここから機器が動作するための電力が供給される。

ルータ５０１は、インターネットへの情報の送信もしくはインターネットからの情報の受信を中継するネットワーク機器である。通常、ルータ５０１はＯＳＩの７層モデルのネットワーク層までの接続を管理するが、本実施の形態においてはより上層のサービスを提供するものであっても良い。

ＨＴＴＰサーバ５０２は、インターネット上に存在する不特定の端末にホームページの情報（主にＨＴＭＬ形式で書かれたもの）を送信する。通常ＨＴＴＰサーバ５０２が送信するホームページの情報から誘導されて、決済サーバ５０３へユーザが誘導されることとなる。

決済サーバ５０３は、インターネットから商品の提供を行う際にクレジットカード情報を通信し、管理する為の支払い決済を行うためのサーバである。

モニタ用ＰＣ５０４は、ネットワーク機器監視装置１００の状況をモニタするためのＰＣである。このＰＣ上ではブラウザが動作可能であることを想定する。また、このモニタ用ＰＣ５０４で動作するブラウザで表示可能なデータ（後述する図５や図7）をネットワーク機器監視装置１００は生成し、出力しなければならない。

通常、ユーザは、ＨＴＭＬ形式で記載されたホームページから誘導されて決済サーバ５０３のサービスを提供される受けることになる。このため、ＨＴＴＰサーバ５０２がダウンしているときには、ユーザは決済サーバ５０３の利用ができないことがほとんどである。よって決済サーバ５０３のみがアクティブで、他のルータ５０１、ＨＴＴＰサーバ５０２がダウンしている状態では決済サーバ５０３の動作の意義は低下する。

（ソフトウェアの説明）
（ネットワーク機器の監視）
以下、これらの図１、図２の構成を念頭に置いたうえで、ネットワーク機器監視装置１００上で動作するソフトウェアの動作を説明する。

図３は、ネットワーク機器監視装置１００上でＣＰＵ１０１が処理するソフトウェアで構成された監視モジュールの動作の概略を説明するフローチャートである。この監視モジュールはＣＰＵ１０１上で動作する。本実施の形態におけるネットワーク機器監視装置１００によるネットワーク機器の監視はいわゆるポーリングを行うことで実現される。

ネットワーク機器監視装置１００の起動もしくはリセットが行われると、ネットワーク機器監視装置上のＯＳは種々の事前処理を行った後に、監視モジュールを起動させる（ステップＳ１０）。

監視モジュールが起動すると、初期化処理（ステップＳ１１）を行う。初期化処理は必要なメモリ量の確保や監視対象のＩＰアドレスやポート番号の特定、後述するステップＳ１４の待機時間（ポーリング周期）の設定などが行われるが、必ずしもこれだけに拘るものではない。

監視モジュールの起動処理が行われると、監視モジュールによる監視対象への監視が開始される。監視モジュールはＩＣＭＰのＰＩＮＧコマンド（ステップＳ１２）及びＴＥＬＮＥＴで特定のポートを指定してコマンド（以下ＴＥＬＮＥＴコマンド）を送出する（ステップＳ１３）。この場合、ＰＩＮＧコマンドで異常終了したら、ＴＥＬＮＥＴコマンドの送出を行わなくても良いし、ＰＩＮＧコマンドの終了状態にかかわらず、ＴＥＬＮＥＴコマンドを送出しても良い。これらは設計事項である。

ステップＳ１２及びＳ１３で異常終了した場合には、其々に応じた割り込み処理が呼び出される。割り込みであるため、割り込み処理が終了すれば、割り込み処理が生じたところまで戻って監視モジュールの処理が再開される。

ここで、割り込み処理の一として、ＣＰＵ１０１が監視対象の電源供給を制御するリレーコントローラ３０３の適切なレジスタへ１／０を書き込むことがあげられる。これにより、対応するコンセントへの電源の供給を再開（接続）／切断することができる。結果として、監視対象のネットワーク機器の電源のＯｎ／Ｏｆｆを行うことが可能になる。

また、自身が特定のリレーのＯｎ／Ｏｆｆを行った旨ＣＰＵ１０１がログを記録することも考えられる。ログはトラブル解析の為ユーザに必須の情報だからである。

ここで、ステップＳ１２での割り込み処理とステップＳ１３での割り込み処理との処理内容を変えても良い。たとえば、ステップＳ１２で異常終了した場合には、各サーバの再起動をする必要性が高い。しかし、ステップＳ１３で異常終了した場合には、必ずしも監視対象のハードウェア機能（物理層やデータリンク層）がだめになっているわけではない。従ってこのような場合には、該サーバに該当するポートに関わるサービスのみを再起動するよう通信するような処理にしても良い。

そして、ＰＩＮＧコマンド及びＴＥＬＮＥＴコマンドの送出が終了したら、初期化処理（ステップＳ１１）で設定した待機時間だけ待機する（ステップＳ１４）。

なお、この待機時間は後述する図５の「待機秒数」をそのまま使うことを想定するが、ステップＳ１２及びステップＳ１３の処理時間を引いてステップＳ１２からステップＳ１４までの処理一巡の総時間数として取り扱っても良い。

その後、処理はステップＳ１２まで戻り、ネットワーク機器監視装置１００の電源が切断またはリセットされるまで、ステップＳ１２乃至ステップＳ１４の処理が繰り返し行われる。
（ネットワーク機器の設定の変更）

次に上記初期化処理（ステップＳ１１）で読み出される設定の変更ついて説明する。

まず、ネットワーク機器監視装置は現在の設定がどのようになっているかをユーザに開示する必要がある。そもそも現状が分からなければ、設定の変更の要否を決定できない為である。その情報の開示処理について図４を用いて説明する。

図４は、ネットワーク機器監視装置１００が自身の設定情報及び現在の監視対象の状況をユーザに開示する為の処理の流れを表すフローチャートである。又、図５は、第１の実施の形態での図４の処理を行った後に開示要求（Ｒｅｑｕｅｓｔ）の送信元に送られてきた出力データを端末のブラウザ上で表示させた結果である。

なお、本実施の形態ではＨＴＭＬ形式のデータをモニタ用ＰＣ５０４上のブラウザが出力することを想定している。従って、別段の記載がなければＨＴＭＬ形式のデータをネットワーク機器監視装置１００は生成しているものと考える。

まず、モニタ用ＰＣ５０４からネットワーク機器監視装置１００に対して、設定情報の開示要求（Ｒｅｑｕｅｓｔ）が送信される（ステップＳ２０）。この開示要求はネットワーク機器監視装置１００に割り当てられたＩＰアドレスに対して必要なパラメータ（たとえばどの監視対象の設定を変更するか等）を付加してＨＴＴＰ要求を掛ける方法が考えられるが、必ずしもこれに拘るものではない。

なお、本図の出力データは、モニタ用ＰＣ５０４の開示要求が図２のＨＵＢ５００から図１のＬＡＮ Ｉ／Ｆ３０１を通って送信されているものとする。

ステップＳ２０における開示要求を受信したネットワーク機器監視装置１００のＣＰＵ１０１は、メモリ２０１上の不揮発性領域から自身の設定（監視対象のＩＰアドレスやポート番号、待機秒数など）を読みだす（ステップＳ２１）。

またＣＰＵ１０１は、監視対象の現状を表示すべくステップＳ２１で読みだした設定に基づき、必要があれば監視対象のネットワーク機器の現状に関する情報を収集する（ステップＳ２２）。この際、図３ステップＳ１２及びステップＳ１３で行ったようなＰＩＮＧコマンド及びＴＥＬＮＥＴのコマンドだけでなく、ＳＮＭＰを用いたデータ収集を行っても良い。

このステップＳ２１で求めた設定情報及びステップＳ２２で求めた監視対象の現状をまとめた出力データをＣＰＵ１０１は生成する（ステップＳ２３）。端末側に専用アプリケーションを用意し、そのアプリケーション上で表示するのであれば、ステップＳ２３で生成するのは該アプリケーション専用のデータとなる。

なお、図５では監視対象の状態を表示する項目がないため、ステップＳ２２の結果はデータには反映されていない。

生成された出力データは、開示要求（Ｒｅｑｕｅｓｔ）の送信元（＝モニタ用ＰＣ５０４）に返送される（ステップＳ２４）。この出力データに基づき、開示要求（Ｒｅｑｕｅｓｔ）の送信元であるモニタ用ＰＣ５０４はブラウザなどで出力データを表示する。

なお図１及び図２に従えば、ＣＰＵ１０１が生成した出力データは図１のＬＡＮ Ｉ／Ｆ３０１から図２のＨＵＢ５００を経由してモニタ用ＰＣ５０４に返送される。

次に実際表示される出力データの書式について説明する。
既に述べた通り、図５は第１の実施の形態での図４の処理を行った後に開示要求（Ｒｅｑｕｅｓｔ）の送信元に送られてきた出力データをモニタ用ＰＣ５０４のブラウザ上で表示させた結果である。すなわち、この図面に表示されている項目がネットワーク機器監視装置１００の設定変更可能な項目となる。

図５の表示画面は大きく分けると、監視対象指定コラム４１０、監視有効設定コラム４２０、詳細設定コラム４３０、設定保存ボタン４４０を含んで構成される。

監視対象指定コラム４１０は、ネットワーク機器監視装置１００がもつ監視対象のどれを設定するかを指定する欄である。ネットワーク機器監視装置１００の製品仕様によって監視対象の数には上限がある。そしてこれらの監視対象は一意的にナンバリングされることで管理される。すなわち本図の画面に表示されている「監視対象１」以外にも「監視対象２」、「監視対象３」「監視対象ｎ」（ｎ＝監視対象数の上限値）が存在する。

監視対象指定コラム４１０はこの監視対象を指定するプルダウンメニューである。

監視有効設定コラム４２０は、その監視を有効にするか否かを規定する欄である。ＣＰＵ１０１の処理能力が高ければ高いほど、ネットワーク機器監視装置１００の製品価格に跳ね返ってくる。また、監視対象が多ければ多いほどネットワーク上に流れるデータの数（＝パケット数）も増える。しかし、無駄な処理をカットすれば高価な製品を購入しなくても良いし、ネットワーク上に監視の為に流れるパケットの数を減らすことが可能になる。
また、ＨＴＴＰサーバ５０２や決済サーバ５０３の再起動時など明らかにステップＳ１２及びステップＳ１３の応答が異常になる場合も想定される。このような場合には、電源のＯＮ／ＯＦＦを繰り返すことで再起動を繰り返してしまい、これらのサーバが正常に動作しなくなる。

これらのような場合に、監視有効設定コラム４２０のダイアログボックスをチェックすることで一時的に監視を無効にし、システムの円滑な活用を図ることが可能になる。

詳細設定コラム４３０は、当該監視対象のＩＰアドレスやポート番号と言った実際の監視対象機器の詳細を設定する為の欄である。

監視条件設定欄４３１は、監視対象や動作条件を決めるための必須事項が入力可能なテキストエリアやチェックボックスが複数設けられている。

監視条件設定欄４３１内の「ＩＰアドレス」テキストボックスは、監視対象のＩＰアドレスを定義する為の欄である。また「ポート番号」テキストボックスは、監視対象のポート番号を定義する為の欄である。少なくともこの二つが特定できなければ、トランスポート層の監視を行うことはできない為必須の項目である。

監視条件設定欄４３１内の「待機秒数」テキストボックスは、図３のステップＳ１４の待機時間を決定するための欄である。この待機時間が短ければよりリアルタイムな監視を行うことができるが、監視頻度が高ければネットワーク上に関連するパケットを多く出すことになる。このバランスをユーザに定義させるにはこの欄は必要になる。逆を言えば、待機秒数をユーザに定義させない場合には、この欄は不要である。

監視条件設定欄４３１内の「ポートチェックのみ」チェックボックスは、図３のステップＳ１２を省略するか否かを決定する欄である。他の監視対象でＰＩＮＧコマンドを出力している場合、ステップＳ１２は重複する処理となる。従って、当該監視対象においてステップＳ１２を省略する場合にはこの欄にチェックを入れる。

名称欄４３２は、当該監視対象がユーザに分かりやすいように表示するためのテキストボックスである。またメモ欄４３３は、当該監視対象についてユーザがコメントを残すためのテキストボックスである。これらは必須の項目ではないが、あれば日常の運用で便利になる為、本実施の形態でも採用している。

設定保存ボタン４４０は、本ボタン押下時の各欄記載の事項を出力データ送信元であるネットワーク機器監視装置１００に送信するためのボタンである。

本実施の形態ではこの出力結果をブラウザで表示されるべくＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記載されることを想定している。従って、データの主要な個所を＜ＦＯＲＭ＞＜／ＦＯＲＭ＞タグで囲われるようデータを生成する。そして、これらのタグの間に＜ＩＮＰＵＴ＞＜ＳＥＬＥＣＴ＞＜ＴＥＸＴＡＲＥＡ＞等のタグを使って入力欄を設けていく。

図５の監視対象指定コラム４１０で、プルダウンタグ（＜ＳＥＬＥＣＴ＞＜ＯＰＴＩＯＮ＞タグ）が用いられるが、これらはステップＳ２３でＣＰＵ１０１が生成するようプログラミングされていなければならない。

同様に、監視条件設定欄４３１内の「ＩＰアドレス」テキストボックス、「ポート番号」テキストボックス、「待機秒数」テキストボックスはユーザが入力可能なようにテキストボックス及びその初期値（たとえば図５の「ポート番号」については＜ＩＮＰＵＴ ｔｙｐｅ＝“ｔｅｘｔ” ｖａｌｕｅ＝“５９０１” ｎａｍｅ＝“ｐｏｒｔ”＞タグ）をＣＰＵ１０１の生成時点（ステップＳ２３）で用意する必要がある。これらの初期値はステップＳ２１で読みだした自身の設定から求められる。

また、図５の「ＰＯＲＴチェックのみ」チェックボックスをアクティブにすることで図３のステップＳ１２（ＰＩＮＧコマンド）を省略することができる。このような表示もＣＰＵ１０１がステップＳ２３で表示できるようにしてやる必要がある（たとえば＜ＩＮＰＵＴ ｔｙｐｅ＝“Ｃｈｅｃｋｂｏｘ” ｎａｍｅ＝“ｃｈｅｃｋ”＞タグ）。このデータもステップＳ２１で読みだしたネットワーク機器監視装置１００自身の設定から定義される。

また設定保存ボタン４４０を押すことで、この表示画面でユーザが入力可能なデータをネットワーク機器監視装置１００に送り返すことができるように＜ＦＯＲＭ＞タグで表示データが構成されるべきである。

この際、設定保存ボタン４４０を押下した際に、アクセスするアドレスもＣＰＵ１０１が定義しておく必要がある。このようにすることで、ユーザが間違ったアドレスを入力することなくただ設定保存ボタン４４０を押下するだけでネットワーク機器監視装置１００の設定変更が可能になる。

このように、ネットワーク機器監視装置１００側で表示形式及びデータの修正したものを送信する方法を準備し、その状態で開示要求（Ｒｅｑｕｅｓｔ）の送信元に送り返すことで、入力値に一定の制限を掛けることが可能になる。

もちろん、この送り返された情報に基づき、ネットワーク機器監視装置１００のＣＰＵ１０１が設定の変更を行う必要がある。

図６はネットワーク機器監視装置１００が自身の設定情報の変更を反映する為の処理の流れを表すフローチャートである。

図４と図６を対比しても分かるとおり、設定の変更を伴う場合であっても読み出しの場合と処理に大差はない。相違するのはネットワーク機器監視装置１００に送信されるのがアドレス情報だけでなくデータも対象となること（ステップＳ３０）及びこのデータを反映してＣＰＵ１０１がメモリ２０１上の不揮発性領域に格納された設定値を変更する処理（ステップＳ３１）が入るだけである。

この設定の変更が行われた後は設定変更後のメモリ２０１上の不揮発性領域から自身の設定（監視対象のＩＰアドレスやポート番号、ポーリング周期など）を読みだし（ステップＳ２１）、監視対象のネットワーク機器の現状に関する情報を収集し（ステップＳ２２）、ＣＰＵ１０１が出力データを生成し（ステップＳ２３）、レスポンスを返す（ステップＳ２４）点は同じである。

すなわち、設定の変更を行なえば、ブラウザを閉じる等しない限り、指定された監視対象についてのネットワーク機器監視装置１００の状況を再び端末上に表示することとなる。
（一覧表示）

最後に、自身の監視対象の一覧をモニタ用ＰＣに送信するソフトウェアの動作について説明する。

監視対象の一覧の表示も、基本的には図４の処理と同じである。但し、「監視」であり設定の変更の必要性がないこと、一覧全体を定期的に更新する必要があること、ＨＴＴＰのようなリクエスト−レスポンス形式の通信を行うためにモニタＰＣ５０４側から周期的に要求を出す必要があること、などからＣＰＵ１０１が作成する表示データを変更する必要がある。

図７は、第１の実施の形態での監視用画面を表す図である。

図５の設定画面の出力データではその性質上設定対象しか表示しなかった。しかし通常監視を行う際には全ての監視対象が見渡せることが好ましい。従って、監視用画面は設定の変更機能を除外し、全ての監視対象を見渡せることを主眼に置く。

図７では監視対象ごとにコラム７１０、７２０、７３０を割り当てている。そして各コラムには「名称」欄、「ＩＰ：Ｐｏｒｔ」欄、「状態」欄の項目が存在する。このうち、「名称」と「ＩＰ：Ｐｏｒｔ」は設定を表すものであり、「状態」は監視対象の状態を表すものである。

注意すべきことはＩＰアドレスが同じであっても、ポート番号が異なる場合には別個独立の監視対象としてネットワーク機器監視装置１００を取り扱うということである。これにより同一のＩＰアドレスであってもポート番号が異なるときには別の取り扱いが可能になる。そして、それがユーザにとって便宜を図ることになるが、それは第２の実施の形態で説明する。

「名称」欄は、図５の名称欄４３２で定義されたユーザが該監視対象につけた名称を表示する欄である。当然ユーザで名称を定義できない場合には本欄は省略することになる。

「ＩＰ：Ｐｏｒｔ」欄は、図５の監視条件設定欄４３１で定めたＩＰアドレス及びポート番号を表示する欄である。

「状態」欄は、監視対象がどのような状態であるかを表す欄である。「状態」欄は大まかに二つに分かれ、ネットワーク機器監視装置１００が定期的に把握する項目でインジケータ的に上段に記載される。また下段にはネットワーク機器監視装置１００が類推する状態を表示する。

「状態」欄上段の「ＯＮ」はネットワーク機器監視装置１００の対応するリレーが接続状態になっているか、すなわち、電源がサーバに接続されているかを表す。これはリレーコントローラ３０３の対応するレジスタを見て判断する。

「ＯＮ」はインジケータ的に表示される。すなわちリレーが導通状態にあれば背景が緑に、非導通であれば背景がグレーに表示される。

「状態」欄上段の「ＰＩ」は図３ステップＳ１２のＰＩＮＧコマンドの処理が正常に行われたかを表す。これは図３ステップＳ１２の処理結果を反映させている。当該監視においてステップＳ１２が省略されている場合（＝図５の監視条件設定欄４３１の「ポートチェックのみ」がチェックされている場合）にはコラム７３０のように通常とは異なる記載にする。但し、「ＰＩ」の不実施時の背景色は失敗と同様の表示にしても良い。

「状態」欄上段の「ＰＯ」は図３ステップＳ１３のＴＥＬＮＥＴコマンドの処理が正常に行われたかを表す。

「ＰＩ」「ＰＯ」はインジケータ的に表示される。すなわち正常に動作していれば背景が緑に、異常終了していれば背景がグレーに、処理自体が省略されている場合には黒く塗りつぶすなど、ユーザに見分けのつくような表示にすることが好ましい。図７ではカラム７３０の「ＰＩ」が塗りつぶされることで表現される。

「状態」欄下段は、現状ネットワーク機器監視装置１００がどのような対応をしているかを表す。ここに表示する事項はどのような物であっても良いが、一定の法則性を持たせそれをユーザに開示すべきであろう。

なお、図７の表示画面の出力の際のＣＰＵ１０１側の処理は図４のフローチャートと流れは同じである。図５の画面を表示するデータを送信するか、図７の画面を表示するデータを送信するかは、図４のステップＳ２０で送られる開示要求に付加されるパラメータで決めるようにすれば良い。

また、送信される出力データに所定の秒数後自動的に再度自身のアドレスを読みだすようにすれば、反復して状態を更新することが可能になる。ＨＴＭＬ形式では＜ＭＥＴＡ＞タグを用いることでこのような機能を実現できる。

このように、ネットワーク機器監視装置１００の設定状態の表示を繰り返すことでユーザの利便性を向上させることが可能になる。

以上のように、ネットワーク層での障害の検出と並行してトランスポート層での障害の検出を行うこと、及びその際異常を感知した後の割り込み処理を異なるものにすることで、より状況に即した異常の復旧を図ることが可能になる。
（第２の実施の形態）

次に本発明の第２の実施の形態について図を用いて説明する。

第１の実施の形態では、割り込み処理についてユーザの意向で定義することはなかった。しかし、ＩＰアドレスやポート番号によっては割り込み処理をプログラマブルに変更できた方がユーザの運用上都合の良いことが多い。特に、同一のサーバで複数のサービスを提供する場合には、そのような利点は顕著である。

すなわちＩＰアドレスは同一サーバ上のサービスすべてで共通して使用する。従って、ネットワーク層で障害が生じたら直ちにサーバ全体の再起動を行うことが好ましい。しかし、あるポート番号で不具合が起きたとしても、別のポート番号のサービスを提供するアプリがアクティブである場合も十分考えられる。このような場合に、いきなり電源切断を行うのは必ずしも適切とは限らない。

そこで本実施の形態では、ＩＰアドレスあるいはポート番号によって、割り込み処理の動作をユーザに設定させることを可能ならしめる手段を提供することを目的とする。

図８は、第２の実施の形態に関わるネットワーク機器監視装置１００の動作環境の一例を表す接続図である。なお、図２と変更がない個所については説明を省略する。

第１の実施の形態と異なり本実施の形態では、単一のサーバ６００にＨＴＴＰアプリ及び決済アプリがインストールされる構成をとる。これに伴いＨＴＴＰサーバ５０２及び決済サーバ５０３は削除されている。近年ではサーバの処理能力が飛躍的に向上している為、このように一つのサーバに複数のトランスポート層〜アプリケーション層の処理を含むアプリケーションを常時実行させることも多々ある。

このような構成をとることで、サーバ６００のネットワーク層までは生きていたとしてもＨＴＴＰアプリまたは決済アプリの何れか１が落ちることも考えられる。この際全ての状況で電源の再起動処理を行うのは適切でない場合もある。

本実施の形態は、ネットワーク機器監視装置１００の割り込み処理（図３参照）の処理内容をユーザに定義させるようにすることを特徴とする。

図９は、第２の実施の形態での開示要求（Ｒｅｑｕｅｓｔ）の送信元に送られてきた出力データをモニタ用ＰＣ５０４のブラウザ上で表示させた結果である。

図９においては図５の表示に加え、アクション８１０及びアクション設定８２０の項目が増えている。

アクション８１０で表示されるプルダウンメニューの項目の選択によって、ユーザは大まかな処理を最大４つ自由に選ぶことができる。なお、仕様上４つとしているが、最大幾つユーザに動作の定義を認めるのかはネットワーク機器監視装置１００の設計者の意図にかかっている

図９では、電源ＯＮ（アクション２）と電源ＯＦＦ（アクション１）、「ロギング」（アクション３）の選択肢しか記載されていないが、例えば、「別のモジュールの動作確認を行う」とか「該サーバに該当するポートの再起動を指示する」といったアクション種別を追加することもかんがえられよう。

そして、上記アクション８１０で選んだ項目に応じて、ユーザはアクション設定８２０で細かな動作を選択することが可能になっている。

また、アクションで何も選ばなければ、監視対象のポートに関わるアプリが異常終了していたとしても割り込み処理を一切行わなくすることも可能である。その判断をユーザにゆだねることができるのが本実施の形態の特徴である。

図９のアクション設定８２０では現在アクション１で選択された電源ＯＦＦに対応したサブ設定項目が表示されている。ここでは電源をオフするまでの待機秒数及び電源をオフした後次のアクションを実行するまでの待機秒数が入力可能になっている。

このように第１の実施の形態におけるポート番号（トランスポート層）まで特定して監視すること及び第２の実施の形態のユーザが自由に割り込み処理を定義できることを組み合わせることでサービスの優先順位に応じた割り込み処理の設定が可能になる。

図８の例で説明する。サーバ６００上では決済アプリとＨＴＴＰアプリが同時に動いている。実環境でのＨＴＴＰアプリと決済アプリとの優劣はつけがたいが、ここでは情報を要求があれば即時に送り出す必要があるＨＴＴＰアプリを優位とする。

この場合、ＨＴＴＰアプリがダウンし対応するポート（ウェルノンでは８０番）に対するＴＥＬＮＥＴコマンドが異常終了したら、サーバ６００に対応する電源ケーブルに繋がったコンセント３２１、３２２、３２３のいずれか１に対応するリレー３１１、３１２、３１３のいずれか１をオフ後に再度オンにし再起動する設定をする。

一方、決済アプリのポートに対するＴＥＬＮＥＴコマンドが異常終了したとしても、ＨＴＴＰアプリのポートが生きていれば、ＨＴＴＰアプリでの情報の送信を優先する為、ログの蓄積のみするようにするといったことも今回の例では考えられる。

なお、ネットワーク機器監視装置１００側の処理に関しては、ステップＳ２３（図４参照）でＣＰＵ１０１がアクション関連の変数及び既定値を定義して、ステップＳ３０（図６参照）でＣＰＵ１０１がこの変数の修正値を受け取れるようにすれば（＝処理モジュールを追加すれば）対応できるので、ここでは細かくは述べない。

以上のようにＩＰアドレス、ポートの番号に応じて、処理の方法をユーザの意向で変える手段を提供することで、ユーザにとってより有効な再起動処理を行うことが可能になる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。

本発明はネットワーク機器の監視装置に適用可能である。また、ルータや課金サーバ、ＨＴＴＰサーバだけでなく、他のネットワーク機器を監視対象としても良いことは言うまでもない。

１００ ネットワーク機器監視装置、
１０１ ＣＰＵ、
１０２ バスコントローラ、
２０１ メモリ、
２０２ 周辺用バスコントローラ、
３０１ ＬＡＮ Ｉ／Ｆ、
３０２ ＬＥＤコントローラ、
３０３ リレーコントローラ、
３１１、３１２，３１３ リレー、
３２１、３２２、３２３ コンセント、
５００ ＨＵＢ、
５０１ ルータ、
５０２ ＨＴＴＰサーバ、
５０３ 決済サーバ、
５０４ モニタ用ＰＣ、
６００ サーバ。

Claims (6)

1. ネットワーク層及びトランスポート層のプロトコルに従ってネットワーク機器を監視するネットワーク機器監視装置であって、
   ネットワーク層での異常検出時の処理とトランスポート層での異常検出時の処理が異なることを特徴とするネットワーク機器監視装置。
2. 請求項１記載のネットワーク機器監視装置において、
   該ネットワーク機器監視装置はＣＰＵ、リレーコントローラ及び前記リレーコントローラに制御されるリレーを含み、
   前記トランスポート層での異常検出時の処理として、前記ＣＰＵが前記リレーを制御するようリレーコントローラに指示することを特徴とするネットワーク機器監視装置。
3. 請求項２記載のネットワーク機器監視装置において、前記リレーが電源供給を制御することを特徴とするネットワーク機器監視装置。
4. 請求項３記載のネットワーク機器監視装置において、前記リレーが前記ネットワーク機器への電源供給を制御することを特徴とするネットワーク機器監視装置。
5. 請求項1乃至４のいずれか１に記載のネットワーク機器監視装置において、前記異常検出時の処理をユーザが変更可能な手段を持つことを特徴とするネットワーク機器監視装置。
6. ネットワーク層及びトランスポート層のプロトコルに従ってネットワーク機器を監視するネットワーク機器監視装置であって、
   該ネットワーク機器監視装置は１のネットワーク層に属しかつ異なるトランスポート層を利用する２以上のアプリケーションの異常を別個独立に監視することが可能なことを特徴とするネットワーク機器監視装置。

Images