JP2016200961A - サーバー障害監視システム - Google Patents

Abstract

【課題】サーバー障害とネットワーク障害を切り分け、被監視サーバーの管理者へ障害発生通知及び／又は復旧を良好に実現可能とするサーバー障害監視システムを提供する。【解決手段】サーバー障害監視システム１は、複数の被監視サーバー（３ａ〜３ｄ）と、被監視サーバーの障害を監視する監視サーバー２と、複数の被監視サーバー（３ａ〜３ｄ）及び監視サーバー２を接続するネットワーク４より構成され、被監視サーバーは自己のサーバープロセスの障害を検知する監視エージェント（３０ａ〜３０ｄ）を備え、監視サーバー２は、各監視エージェントからサーバープロセスの障害情報を含む監視データを取得すると共に、ネットワークの障害発生有無を検知し、ネットワーク障害の場合、サーバープロセス障害が発生した被監視サーバーの管理者への障害発生通知を停止する監視マネージャー２０を有する。【選択図】 図２

Description

本発明は、監視対象である複数のサーバー（以下、被監視サーバーと称す）の障害を監視し、被監視サーバーの管理者へ障害発生通知及び／又は復旧を可能とするサーバー障害監視システムに関する。

複数のサーバーの障害を監視するシステムとして、例えば、特許文献１に記載されるシステムが提案されている。

特許文献１では、監視サーバーが、自己監視サーバー、リモート監視サーバー及び補助サーバーを備え、ＬＡＮ又はインターネット網に接続される他のサーバー（被監視サーバー）の障害の発生を検知する。リモート監視サーバーは、被監視サーバーの障害を検知すると、予めデータベースに登録されている当該障害が発生したサーバーの管理者へ、サーバーが接続されるＬＡＮ又はインターネット網とは異なる公衆回線あるいは携帯電話網を介してサーバーの管理者の携帯電話等の携帯端末に、障害情報を含む電子メールを送信する。障害情報を含む電子メールを受信したサーバーの管理者は、障害が発生しているサーバーが接続されるＬＡＮ又はインターネット網を介して、サーバー管理者の携帯端末から再起動指令を送信し、障害が発生しているサーバーに再起動をかけることにより復旧する。

特開２００２−２２９８７０号公報

しかしながら、上記特許文献１の構成では、仮に、障害が発生しているサーバーが接続されるＬＡＮ又はインターネット網等のネットワークに障害が発生している場合、サーバー管理者から再起動指令を送信しても、障害発生サーバーに再起動指令が到達することはなく、再起動によるサーバーの復旧はできない。更にまた、サーバー管理者の携帯電話へ障害情報を含む電子メールを送信する方式では、自然災害あるいは他の要因により、携帯電話網自体が機能不全にある場合には、障害発生の通知すらサーバー管理者へ届くことは無く、サーバー障害監視システムとして機能不全に陥る恐れがある。

一方、仮に、サーバー管理者の携帯電話へ障害情報を含む電子メールの送信に替えて、障害発生サーバーに接続されるＰＣへ電子メールを送信する構成とした場合であっても、上記ネットワーク障害が発生している場合には、その電子メールがＰＣに到達することは無い。また、ネットワーク障害が回復した時点で、それまでリモート監視サーバーより送信されていた大量の電子メール（障害発生通知）が、ＰＣに届くという状況を招く。

そこで本発明の目的は、サーバー障害とネットワーク障害を切り分け、被監視サーバーの管理者へ障害発生通知及び／又は復旧を良好に実現可能とするサーバー障害監視システムを提供することにある。

上記課題を解決するため、本発明のサーバー障害監視システムは、被監視サーバーと、前記被監視サーバーの障害を監視する監視サーバーと、前記被監視サーバー及び監視サーバーを接続するネットワークより構成されるサーバー障害監視システムであって、前記被監視サーバーは、自装置の監視結果である監視データを管理する監視データ管理部を備え、前記監視サーバーは、前記被監視サーバーから監視データを取得し前記被監視サーバーに障害が発生しているか否かを判別する被監視サーバー障害判定部と、該被監視サーバー障害判定部によって障害が生じていると判定された被監視サーバーの管理者宛てに障害発生の通知を行う障害発生通知部と、ネットワークに障害が発生してるか否かを判別するネットワーク障害判定部と、を備え、前記監視サーバーの前記被監視サーバー障害判定部による前記被監視サーバーの監視データの取得の際、前記ネットワーク障害判定部によりネットワーク障害の有無を判定し、ネットワーク障害と判定された場合、前記障害通知処理部の動作を一時的に停止することを特徴とする。

また、本発明のサーバー障害監視システムは、前記監視サーバーは、前記ネットワーク障害が回復した後、前記障害通知処理部を再稼働させることを特徴とする。

また、本発明のサーバー障害監視システムは、前記被監視サーバーは複数の前記被監視サーバーからなり、前記監視サーバーの前記被監視サーバー障害判定部による前記被監視サーバーの監視データの取得は、夫々の前記被監視サーバー毎に行われることを特徴とする。

また、本発明のサーバー障害監視システムは、前記ネットワーク障害判定部は、前記複数の被監視サーバーへ前記ネットワークを介して応答要求を行い、所定の時間内に前記複数の被監視サーバーより応答がなかった場合、その被監視サーバーと前記監視サーバーを接続するネットワークに障害が発生したと判定することを特徴とする。

また、本発明のサーバー障害監視システムは、前記ネットワーク障害判定部は、稼働率の高いサーバーへの応答要求を行い、所定の時間内に前記稼働率の高いサーバーより応答がなかった場合、ネットワーク障害発生と判定することを特徴とする。

本発明によれば、サーバー障害とネットワーク障害を切り分け、被監視サーバーの管理者へ障害発生通知及び／又は復旧を良好に実現可能とするサーバー障害監視システムを提供することが可能となる。

本発明の一実施例に係るサーバー障害監視システムの概略構成図である。 図１に示すサーバー障害監視システムの概略機能ブロック図である。 図２に示す監視サーバーの機能ブロック図である。 図２に示す被監視サーバーの機能ブロック図である。 障害情報ＤＢ（データベース）の格納情報を示す図である。 監視データ管理ＤＢ（データベース）の格納情報を示す図である。 被監視サーバー管理ＤＢの格納情報を示す図である。 監視データ記憶部の格納情報を示す図である。 サーバー障害監視システムの監視処理を説明するフローチャートである。 サーバー障害監視システムのネットワーク障害判定処理を説明するフローチャートである。 本発明の他の実施例に係るサーバー監視システムのネットワーク障害判定処理を説明するフローチャートである。

以下、図面を用いて本発明の実施例について説明する。

図１に、本発明の一実施例に係るサーバー障害監視システムの概略構成図を示す。サーバー障害監視システム１は、監視サーバー２、被監視サーバー３ａ〜３ｄ、及びこれらを相互に接続可能とするネットワーク４より構成される。ネットワーク４は、例えば、インターネット網であり、図１に示すように、被監視サーバー３ｃ及び被監視サーバー３ｄは、スイッチ６及びルータ５を介してネットワーク４に接続されている。ルータ５とスイッチ６との間、スイッチ６と被監視サーバー３ｃ，３ｄとの間は、例えば、専用回線、シリアルケーブル等の通信線にて接続されている。なお、被監視サーバーの台数は、４台に限られず、それ以上の台数が接続されるものも含まれる。また、これら複数の被監視サーバー３ａ〜３ｄと監視サーバー２との接続形態は、図１に示す形態に限られず、例えば、インターネット網を、ルータ５を介して他のインターネット網に接続するブリッジを形成する接続形態であっても良い。

図２に、図１に示すサーバー障害監視システムの概略機能ブロック図を示す。監視サーバー２は、監視マネージャー２０、ＣＰＵ２１、通信インターフェース２２、障害情報ＤＢ（データベース）２４、及びこれらを相互に接続する内部バス２３を備える。また、被監視サーバー３ａは、監視エージェント３０ａ、ＣＰＵ３１ａ、通信インターフェース３２ａ、監視データ管理部３４ａ、及びこれらを相互に接続する内部バス３３ａを備える。監視データ管理部３４ａは、内部バス３３ａを介して、監視データ記憶部３５ａと監視エージェント３０ａあるいはＣＰＵ３１ａとアクセス可能に構成されている。また、被監視サーバー３ｂ〜３ｄも被監視サーバー３ａと同様の構成を有する。被監視サーバー３ｃは、通信インターフェース３２ｃにより、スイッチ６及びルータ５を介してネットワーク４に接続され、被監視サーバー３ｄは、通信インターフェース３２ｄにより、スイッチ６及びルータ５を介してネットワーク４に接続されている。
ここで、監視サーバー２の構成について説明する。図３は、監視サーバーの機能ブロック図である。監視サーバー２は、上述のＣＰＵ２１、通信インターフェース２２、内部バス２３及び障害情報ＤＢ２４に加え、ネットワーク障害判定部２０１、被監視サーバー障害判定部２０２、障害発生通知部２０３、被監視サーバーＤＢ及び被監視サーバー管理者ＤＢを備える。これら、ネットワーク障害判定部２０１、被監視サーバー障害判定部２０２、及び障害発生通知部２０３にて監視マネージャー２０が構成される。ネットワーク障害判定部２０１、被監視サーバー障害判定部２０２及び障害発生通知部２０３は、例えば、監視サーバー２内の記憶領域中の所定の領域に格納されるプログラムとして実装され、ＣＰＵ２１がこれらプログラムを、内部バス２３を介して読み出し実行することで、詳細後述する機能を実現する。

次に、被監視サーバー３ａの構成について説明する。図４は、被監視サーバー３ａの機能ブロック図である。なお、被監視サーバー３ｂ〜３ｄについても同様である。図４に示すように、被監視サーバー３ａは、上述のＣＰＵ３１ａ、通信インターフェース３２ａ、内部バス３３ａ及び監視データ管理部３４ａに加え、監視エージェント３０を備える。監視エージェント３０は、サーバー監視部３０１ａ、監視データ送信部３０２ａ及び起動部３０３ａから構成される。サーバー監視部３０１ａ、監視データ送信部３０２ａ及び起動部３０３ａは、例えば、被監視サーバー３ａ内の図示しない記憶領域中の所定の領域に格納されるプログラムとして実装され、ＣＰＵ３１ａがこれらプログラムを、内部バス３３ａを介して読み出し実行することで実現される。

ここで、詳細は後述するが、起動部３０３ａは、自装置たる被監視サーバー３ａの起動と、監視サーバー２からの障害通知によりサーバー管理者による再起動指令により自装置たる被監視サーバー３ａの再起動を行う機能を有する。サーバー監視部３０１ａは、自装置の各種サーバープロセス、例えば、電子メールの配信を管理するメールサーバープロセス、ファイル転送プロセス、あるいはウェブサーバープロセス等が正常に動作しているかを監視する。そしてサーバー監視部３０１ａは、各種プロセスのタイムアウト等の何らかの異常を検出した場合、自装置たる被監視サーバー３ａに障害が発生したものとして、障害が発生したとされるプロセスを一意に特定するためのプロセスＩＤと、プロセスの状態を示すプロセスステータスを取得する。その一方で、稼動情報取得部３０４ａに対し、異常を検出した時点における被監視サーバー３ａの「ＣＰＵ稼働率」、「メモリ容量」、「ディスク残量」等のハードウェアの稼働情報を取得するよう指示、取得を行う。異常を発生したプロセスのプロセスＩＤとプロセスステータス、及び稼動情報取得部３０４ａにより取得した稼動情報とを統合して監視データを生成する。生成した監視データは監視データ管理部３４ａによって監視データ記憶部３５ａに蓄積される。

次に、各種ＤＢに格納される情報について説明する。図５は、監視サーバー２を構成する障害情報ＤＢ２４の格納情報を示す図である。監視サーバー２は被監視サーバー３ａ〜３ｄから取得した監視データを格納するものである。図５に示すように、障害情報ＤＢ２４は、少なくとも、「サーバーＩＤ」、「被監視サーバー名」、障害発生時刻を示す「日時」、及び発生した障害の度合を示す「サーバーステータス」を格納する。例えば、「サーバーＩＤ」が“０００１”、「被監視サーバー名」が“Ｓｅｒｖ−ａ”の被監視サーバー３ａにて、「日時」“２０１４／１１／１６ ０１：２１：２０”に障害が発生したことが示されており、その障害の度合いである「サーバーステータス」が“Ｅｒｒｏｒ”であることが示されている。また、「サーバーＩＤ」が“０００２”、「被監視サーバー名」が“Ｓｅｒｖ−ｂ”の被監視サーバー３ｂにて、「日時」“２０１４／１１／１６ ０２：１１：１０”に障害が発生し、その「サーバーステータス」が“Ｃｒｉｔｉｃａｌ”であったことが示されている。ここで、“Ｃｒｉｔｉｃａｌ”とは、例えば、“Ｅｒｒｏｒ”まで達していないものの、サーバーの負荷が増大し障害の通知対象となるレベルに相当する。

また、図６は、監視サーバー２を構成する監視データ管理ＤＢ２０４に格納される監視データの格納情報を示す図である。図６に示すように、監視データ管理ＤＢ２０４は、サーバーＩＤと日時をキーとして、被監視サーバー３ａ〜３ｄから取得した監視データを管理するものであり、少なくとも、取得した監視データの対象となる被監視サーバーを一意に特定するための「サーバーＩＤ」、さらに被監視サーバーから送られた監視データである「プロセスＩＤ」、「プロセスステータス」、「ＣＰＵ稼働率」、「使用メモリー」、「ディスク残量」、及び「発生時刻」を管理する。

図７は、監視サーバー２を構成する被監視サーバー管理ＤＢ２０５の格納情報を示す図である。被監視サーバー管理ＤＢ２０５は、被監視サーバー固有の情報を管理するためのものである。図７に示すように、被監視サーバー管理ＤＢ２０５は、少なくとも、「サーバーＩＤ」、「被監視サーバー名」、「ＩＰアドレス」、「管理者ＩＤ」、「管理者名」、「パスワード」、及び「電子メールアドレス」を格納する。例えば、「ＩＤ」が“０００１”、「被監視サーバー名」が“Ｓｅｒｖ−ａ”の被監視サーバー３ａは、「ＩＰアドレス」が“ｎｎｎ．ｎｎｎ．ｎｎｎ．００１”のサーバーであり、「管理者ＩＤ」が“ＡＡＡＡ”の「管理者名」が“ＷＷ ＷＷ”という管理者により管理される被監視サーバーであり、「パスワード」が“●●●●”、管理者の「電子メールアドレス」が“ｗｗ＠ｗｗ.ｃｏｍ”である。また、「サーバーＩＤ」が“０００４”、「被監視サーバー名」が“Ｓｅｒｖ−ｄ”の被監視サーバー３ｄは、「ＩＰアドレス」が“ｎｎｎ．ｎｎｎ．ｎｎｎ．００３”のサーバーであり、「管理者ＩＤ」が“ＤＤＤＤ”の「管理者名」が“ＺＺ ＺＺ”という管理者により管理される被監視サーバーであり、「パスワード」が“●●●●”、管理者の「電子メールアドレス」が“ｚｚ＠ｚｚ.ｃｏ.ｊｐ”であることが分かる。ここで、「電子メールアドレス」は、後述する被監視サーバーの管理者へ、障害通知を行う場合に用いられるものであり、「パスワード」は、障害通知を受けた管理者が登録された管理者であることを認証するために用いられる。なお、システム全体の構築時（初期設定時）あるいは、被監視サーバーが新たに追加される場合は、一意の（ユニークな）サーバーＩＤを割り当て、図７に示すフォーマットをＰＣ等の画面上に表示し、被監視サーバーの管理者に入力させることで、サーバー障害監視システムの構築あるいは被監視サーバーの増設が可能となる。

また、ここで、「ＩＰアドレス」は、一例としてＩＰｖ４を用いた場合を示しているが、これに限らず、例えば、ＩＰｖ６等を用いても良い。なお、システム全体の構築時（初期設定時）あるいは、被監視サーバーが新たに追加される場合は、一意の（ユニークな）ＩＤを割り当て、図６に示すフォーマットをＰＣ等の画面上に表示し、被監視サーバーの管理者に入力させることで、サーバー障害監視システムの構築あるいは被監視サーバーの増設が可能となる。また、監視サーバー２と被監視サーバー３ａ〜３ｄの間を通信可能に接続するネットワークの経路が固有に存在する場合、項目を追加してここで管理してもよい。管理者が複数いるようなケースもあると考えられるが、この場合は管理者を別のデータベースにて管理し、この被監視サーバー管理ＤＢ２０５にて管理するデータと紐付けを行うことで対応可能である。

図８は、被監視サーバー３ａ〜３ｄを構成する、監視データを蓄積する監視データ記憶部３５aの格納情報を示す図である。図８に示すように、監視データ記憶部３５ａは、「プロセスＩＤ」、「プロセスステータス」、「ＣＰＵの稼働率」、「メモリ容量」、「ディスク残量」、「発生時刻」を格納する。
例えば、図８に示す例によると、被監視サーバー３５ａでは、「ファイル転送プロセス（プロセスＩＤを“ｆｔ０１”とする。）」が、「発生時刻」２０１４年１１月１６日 １時２１分２０秒において、「プロセスステータス」が“Ｅｒｒｏｒ”となり、その際の「ＣＰＵ稼働率」は“１００％”、「使用メモリー」が“１０ＧＢ”、「ディスク使用率」は“９０％”であったということが分かる。

尚、監視データ記憶部３５ａにおいて、「プロセスステータス」には該当するプロセスが出力するステータスやエラーコード等をそのまま保存するように構成してもよい。

以上の通り、図５から図８に示すように、監視サーバー２が具備する障害情報ＤＢ２４、監視データ管理ＤＢ２０４、被監視サーバー管理ＤＢ２０５、及び被監視サーバー３ａ〜３ｄが具備する監視データ記憶部３５ａは、各データベースに管理されるデータを主キーによって一意に特定し、相互に紐づけることを可能とするリレーショナルデータベースとして構成されるものである。

図９は、被監視サーバー３ａ〜３ｄに備えた監視エージェント３０a〜３０ｄを介した監視サーバー２による監視動作を示すフローチャートである。

図９に示すように、先ず、監視エージェント３０aを構成する起動部３０３aは、被監視サーバー３aを起動する（ステップＳ３１）。起動後、監視エージェント３０ａを構成するサーバー監視部３０１ａは、所定周期（１０秒〜３０秒間隔）にて、各種サーバープロセスの状態を監視する（ステップＳ３２）。サーバー監視部３０１ａは、所定周期で収集した、各種サーバープロセスの状態に、稼動情報取得部３０４ａによって取得した稼働情報（ＣＰＵの稼働率、メモリ容量及びディスク残量等）を紐付けて監視データを生成し、内部バス３３ａ及び監視データ管理部３４ａを介して、監視データ記憶部３５ａに格納又は更新する（ステップＳ３３）。

ステップＳ３４に進み、監視サーバー２からの要求に応じて、サーバー監視部３０１ａは、監視データ管理部３４ａを介して監視データ記憶部３５ａを参照し、監視データを取得する

ステップＳ３５では、サーバー監視部３０１ａは、取得した監視データに少なくとも、自装置を一意に示す「サーバーＩＤ」を加えて、これらを統合してパケットに搭載し、監視データ送信部３０２ａから通信インターフェース３２ａを介して、監視サーバー２へ送信する。

なお、本実施例では、ステップＳ３５にて、被監視サーバーのサーバー監視部３０１ａが監視データを監視サーバー２へ送信する構成としたが、これに限らず、被監視サーバー３ａ〜３ｄに監視サーバー２からのアクセスを許可するようアクセス権を設定し、監視サーバー２が、監視データ記憶部３５ａに直接アクセスして監視データを取得する構成としても良い。更に、本実施例では被監視サーバーに監視エージェント３０ａを具備する構成として説明したが、これに限定せず、監視エージェント３０ａを設けずに被監視サーバー３ａ等に自装置の監視データを取得し記憶する機能を具備し、監視サーバー２による当該監視データのアクセスを可能とするよう構成してもよい。その際、監視サーバー２から被監視サーバー３ａ〜３ｄにアクセスできない場合、当該アクセスできない被監視サーバーまでの経路の何れに障害が生じているものとして、障害発生と判定し、監視サーバー２側にて監視データを作成する必要がある。

次に、監視サーバー２を構成する監視マネージャー２０の処理動作について説明する。図１０に、監視マネージャーの処理を説明するフローチャートを示す。

図１０に示すように、監視マネージャー２０を構成する被監視サーバー障害判定部２０２は、被監視サーバー３ａから、通信インターフェース２２及び内部バス２３を介して監視データを取得する（ステップＳ２１）。被監視サーバー障害判定部２０は、取得した監視データを、監視データ管理ＤＢ２４へ格納する。格納した監視データのプロセスステータスから被監視サーバー３ａの状態を判定し、これをサーバーステータスとして、障害情報ＤＢ２４を更新する。具体的には、取得した監視データに対応する被監視サーバーのＩＤを「サーバーＩＤ」へ、被監視サーバーの名称を「サーバー名」へ、監視データ内の「発生時刻」を「日時」に、プロセスステータスから判定された被監視サーバーの状態を「サーバーステータス」へ格納する（ステップＳ２２）。
尚、ここでいうサーバーステータスとは、被監視サーバー障害判定部２０がプロセスステータスと稼動情報（ＣＰＵの稼働率、メモリ容量及びディスク残量等）から現在当該被監視サーバーがどのような状態か、再起動が必要であるのか、プロセスの強制終了が必要なのかなどを判定したものである。

次に、監視マネージャー２０を構成するネットワーク障害判定部２０１は、内部バス２３及び通信インターフェース２２を介して、被監視サーバーの全てへ応答要求コマンド（自動再送要求：ＡＲＱ）を送信する（ステップＳ２３）。なお、応答要求コマンド（ＡＲＱ）の送信に際し、ネットワーク障害判定部２０１は、図６に示す被監視サーバー管理ＤＢ２０５を参照し、各被監視サーバー３ａ〜３ｄの「ＩＰアドレス」を取得し、応答用要求コマンド（ＡＲＱ）を送信する。

ステップＳ２４では、ネットワーク障害判定部２０１は、応答要求コマンド（ＡＲＱ）を送信した全ての被監視サーバーから応答があったか否かを判定する。応答要求に対して全ての被監視サーバーから応答が無い場合はステップＳ２５へ、全ての被監視サーバーからの応答がある、若しくは一部の被監視サーバーから応答が無い場合、ステップＳ２７へ進む。

ステップＳ２４において、ネットワーク障害判定部２０１は、ネットワーク障害が発生しているか否かを判定しており、具体的には、ネットワーク障害判定部２０１が応答要求コマンド（ＡＲＱ）を送信してから、所定の時間内に、全ての被監視サーバー３ａ〜３ｄからの応答（肯定応答：ＡＣＫ）なかった場合（応答タイムアウト）には、夫々の被監視サーバー３ａ〜３ｄではなく、より上流（即ち監視サーバー２により近い箇所、例えば監視サーバー２に接続するネットワークケーブルの断線等）においてネットワーク障害が発生していると判断する。

なお、一部の被監視サーバーから応答が無いだけで、他の被監視サーバーからの応答が確認された場合は、ネットワーク障害ではなく、応答の無い被監視サーバーと監視サーバー２との間の固有の経路においてネットワーク障害が生じていると認定することができる。応答要求コマンド（ＡＲＱ）に被監視サーバー毎の「サーバーＩＤ」を含め、被監視サーバーからの応答（ＡＣＫ）に当該被監視サーバーの「サーバーＩＤ」を含めることで、どの被監視サーバーに向けた経路にて障害が発生しているか特定することが可能となる。例えば、ネットワーク障害判定部２０１が受信した応答（ＡＣＫ）に、「サーバーＩＤ」である“０００１”及び“０００２”のみが含まれていた場合、被監視サーバー３ａ及び被監視サーバー３ｂから応答を受信できたことが分かり、ネットワーク４自体に障害は発生しておらず、被監視サーバー３ｃ及び３ｄが接続されるルータ５及び／又はスイッチ６を含む専用回線に障害が発生していると特定できる。また、仮に、ネットワーク障害判定部２０１が受信した応答（ＡＣＫ）に、「サーバーＩＤ」である“０００１”、“０００２”及び“０００３”が含まれていた場合、被監視サーバー３ａ〜３ｃから応答を受信できたことが分かり、被監視サーバー３ｄからのみ応答が受信できなかったことが分かる。この場合、ネットワーク４、ルータ５及びスイッチ６自体に障害は発生しておらず、スイッチ６と被監視サーバー３ｄを構成する通信インターフェース３２ｄとを接続する専用回線あるいはシリアルケーブル等に障害が発生していると特定できる。

ステップＳ２４において、全ての被監視サーバー３ａ〜３ｄから応答（ＡＣＫ）があった場合、あるいは、上記のように被監視サーバー３ａ及び３ｂより応答（ＡＣＫ）があった場合には、ネットワークが正常であるとして、ステップＳ２７へ進み、監視サーバー２を構成する被監視サーバー障害判定部２０２は、ステップＳ２１にて取得した監視データに基づいて、発生した障害の対応方法をデータベースから取得し、障害発生通知部２０３によって被監視サーバー（障害発生被監視サーバー）の管理者へ、通信インターフェース２２を介して適宜手段によって障害発生の報知処理を行う。本実施例においては、障害発生通知部２０３は、図７に示す被監視サーバー管理者ＤＢ２０５を参照し、該当する管理者の電子メールアドレス宛てに障害発生通知として電子メールを送信する。

一方、ステップＳ２４において、全ての被監視サーバー３ａ〜３ｄより応答（ＡＣＫ）がなかった場合、障害発生通知部２０３は上流、即ち監視サーバー２に近しい箇所においてネットワークに障害が発生し、監視サーバー２は正常に監視動作を行えない状態であると判定し、監視サーバー２の管理者への障害発生の報知処理を一時停止する（ステップＳ２５）。この処理は、全ての被監視サーバーにて障害が発生したと認定した場合、障害発生の報知処理がネットワーク障害が解消するまで延々と行われるにもかかわらず、ネットワークが不通であることから報知のための電子メールが蓄積され、ネットワーク障害の解消と同時に蓄積した電子メールが一斉に送信されてしまうことを防止するためである。

その後、所定の間隔にて全ての被監視サーバー対して応答要求を行う。何れかの被監視サーバーからの応答が確認され、ネットワーク障害が回復されたと判定された場合、障害発生通知部２０３は、被被監視サーバー３ａ〜３ｄの監視動作及び障害発生の報知処理を再開する。（ステップＳ２６）。ネットワーク障害の発生から回復までの間、即ちステップ２５及びステップ２６の間に新たに監視データが取得された場合であっても、当該障害発生に関する情報のデータベースの記録処理は行うものの、障害発生通知部２０３による被監視サーバーの管理者宛の通知は行わない。

このように構成することで、例えばステップＳ２６にて、監視サーバー２に近しいところでネットワークに障害が発生している場合、被監視サーバーは正常に稼動しているのにもかかわらず、監視サーバー２が被監視サーバー３ａ〜３ｄの夫々に対してネットワーク障害有りとして誤検知をしてしまい、障害発生通知部２０３による障害発生の報知を行うよう動作してしまうが、被監視サーバーの管理者への障害発生通知の送信を一時停止することで、ネットワーク障害回復後に被監視サーバーの管理者宛てに大量の障害発生通知が送信されることを防止することが可能となる。

また、図示しないが、ステップＳ２７により障害発生通知を電子メールにて受信した管理者が、ＰＣにより監視サーバー２にアクセスし、ＰＣ画面上からパスワードを入力の上、図７に示す被監視サーバー管理者ＤＢ２０５に格納されるパスワードとの認証が完了した後、ＰＣより当該障害被監視サーバーの起動部に起動指令を送信するよう構成しても良い。

なお、本実施例では、ステップＳ２４において、ネットワーク障害判定部２０１が応答要求コマンド（ＡＲＱ）を送信してから、所定の時間内に、被監視サーバー３ａ〜３ｄより応答（ＡＣＫ）が受信されなかった場合（応答タイムアウト）には、ネットワーク障害が発生していると判断する構成としたがこれに限られるものではない。例えば、一度の応答タイムアウトによりネットワーク障害と判断することに替えて、所定の回数、応答要求コマンド（ＡＲＱ）を送信するリトライ方式としても良い。この場合、たまたま外乱等の何らかの要因により瞬時的にネットワーク障害が発生し、即時にネットワークが回復するような現象においても、対応することが可能となる。

以上のとおり、本実施例によれは、サーバー障害とネットワーク障害を切り分け、被監視サーバーの管理者へ障害発生通知及び／又は復旧を良好に実現することが可能となる。

本実施例のサーバー障害監視システムは、図１〜図１０に示す実施例１のシステム構成及び各ＤＢと同様であり、監視エージェント及び監視マネージャーの処理が実施例１と異なる。以下では、実施例１と重複するシステム構成及び各ＤＢの構成の説明は省略する。図１１に、監視マネージャーの処理を説明するフローチャートを示す。

実施例２におけるサーバー障害監視システムの動作を図１１に基づいて説明する。監視マネージャー２０を構成するネットワーク障害判定部２０１は、被監視サーバー３ａ〜３ｄの障害発生を検知した場合、被監視サーバーの全てに応答要求コマンドを送信せず、稼働率の高いサーバーへ応答要求コマンド（ＡＲＱ）を送信する点で、実施例２と実施例１は相違する。（ステップＳ２３Ａ）。ここで稼働率の高いサーバーとは、予め被監視サーバーの中から比較的信頼性の高いものを１つを選択してもよいし、稼働率の高いサーバーとして、例えば、Ｇｏｏｇｌｅ（Ｇｏｏｇｌｅ Ｉｎｃ.の登録商標）あるいは、Ｙａｈｏｏ！（ヤフー！インコーポレイテッドの登録商標）等のサーバーから１乃至複数の動作を確認することで、ネットワーク障害発生の有無を判定するよう構成しても良い。稼働率の高いサーバーから応答の有無を判定し（Ｓ２４Ａ）、応答がある場合はプロセス状態及び稼動情報に基づいて被監視サーバーの管理者に向けて障害発生の通知を行い、応答が無い場合は監視サーバー２近傍においてネットワーク障害が発生しているものとして、障害発生通知部２０３の処理を一時停止する。

以上のような実施例２の構成によれば、実施例１の効果に加え、被監視サーバーの全台の障害と、監視サーバー２近傍のネットワーク障害とを切り分けることが可能であり、より正確な障害の切り分けが可能となる。

実施例１及び実施例２では、サーバー障害監視システム１を構成する監視サーバー２を有する例を説明したが、これに限らず複数台の監視サーバーを備える構成としても良い。

本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。例えば、実施例２において稼働率の高いサーバーへの応答を確認するよう構成したが、この稼動率の高いサーバーを複数選択することで、より確実にネットワーク障害を検出するよう構成しても何ら問題ない。また、障害判定を監視サーバ２の被監視サーバー障害判定部２０２にて行うとしたが、これに限定せず、被監視サーバーにて障害判定を行い、障害が発生した場合のみ監視データを監視サーバー２に送信するよう構成してもよいし、監視データではなく被監視サーバーのステータスを直接監視サーバー２へ送信するよう構成してもよい。更に、各種データベースの構造は一例にすぎず、監視システムに要求される機能に応じて適宜変更可能であることは言うまでもない。

本発明は、監視サーバー２に被監視サーバーの管理者宛てに障害発生通知が送信される機能を持つ監視システムに適用可能である。例えば、被監視サーバーにＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）エージェントと、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ、管理情報領域）とを備え、監視サーバー２にＳＮＭＰマネージャーを備えた構成の監視システムが、被監視サーバーの管理者宛てに障害通知機能を具備しているケースにおいては、ＳＮＭＰエージェントは上記実施例の監視エージェント３０ａに、ＭＩＢは監視データ記憶部３５ａに、ＳＮＭＰマネージャーは監視マネージャー２０に相当するものであり、本願発明を適用することは十分に可能である。

１・・・サーバー障害監視システム
２・・・監視サーバー
３ａ，３ｂ，３ｃ，３ｄ・・・被監視サーバー
４・・・ネットワーク（インターネット）
５・・・ルータ
６・・・スイッチ
２０・・・監視マネージャー
２１・・・ＣＰＵ
２２・・・通信インターフェース
２３・・・内部バス
２４・・・障害情報ＤＢ
３０ａ，３０ｂ，３０ｃ，３０ｄ・・・監視エージェント
３１ａ，３１ｂ，３１ｃ，３１ｄ・・・ＣＰＵ
３２ａ，３２ｂ，３２ｃ，３２ｄ・・・通信インターフェース
３３ａ，３３ｂ，３３ｃ，３３ｄ・・・内部バス
３４ａ，３４ｂ，３４ｃ，３４ｄ・・・監視データ管理部
３５ａ，３５ｂ，３５ｃ，３５ｄ・・・監視データ記憶部
２０１・・・ネットワーク障害判定部
２０２・・・被監視サーバー障害判定部
２０３・・・障害発生通知部
２０４・・・被監視サーバーＤＢ
２０５・・・被監視サーバー管理者ＤＢ
３０１ａ・・・サーバー監視部
３０２ａ・・・監視データ送信部
３０３ａ・・・起動部
３０４ａ・・・稼働情報取得部

Claims (5)

1. 被監視サーバーと、前記被監視サーバーの障害を監視する監視サーバーと、前記被監視サーバー及び監視サーバーを接続するネットワークより構成されるサーバー障害監視システムであって、
   前記被監視サーバーは、自装置の監視結果である監視データを管理する監視データ管理部を備え、
   前記監視サーバーは、前記被監視サーバーから監視データを取得し前記被監視サーバーに障害が発生しているか否かを判別する被監視サーバー障害判定部と、該被監視サーバー障害判定部によって障害が生じていると判定された被監視サーバーの管理者宛てに障害発生の通知を行う障害発生通知部と、ネットワークに障害が発生してるか否かを判別するネットワーク障害判定部と、を備え、
   前記監視サーバーの前記被監視サーバー障害判定部による前記被監視サーバーの監視データの取得の際、前記ネットワーク障害判定部によりネットワーク障害の有無を判定し、ネットワーク障害と判定された場合、前記障害通知処理部の動作を一時的に停止することを特徴とするサーバー障害監視システム。
2. 請求項１に記載のサーバー障害監視システムにおいて、
   前記監視サーバーは、前記ネットワーク障害が回復した後、前記障害通知処理部を再稼働させることを特徴とするサーバー障害監視システム。
3. 請求項１又は２に記載のサーバー障害監視システムにおいて、
   前記被監視サーバーは複数の前記被監視サーバーからなり、前記監視サーバーの前記被監視サーバー障害判定部による前記被監視サーバーの監視データの取得は、夫々の前記被監視サーバー毎に行われることを特徴とするサーバー障害監視システム。
4. 請求項３に記載のサーバー障害監視システムにおいて、
   前記ネットワーク障害判定部は、前記複数の被監視サーバーへ前記ネットワークを介して応答要求を行い、所定の時間内に前記複数の被監視サーバーより応答がなかった場合、その被監視サーバーと前記監視サーバーを接続するネットワークに障害が発生したと判定することを特徴とするサーバー障害監視システム。
5. 請求項３又は４に記載のサーバー障害監視システムにおいて、
   前記ネットワーク障害判定部は、稼働率の高いサーバーへの応答要求を行い、所定の時間内に前記稼働率の高いサーバーより応答がなかった場合、ネットワーク障害発生と判定することを特徴とするサーバー障害監視システム。

Images