監視装置、監視方法、およびプログラム
【課題】監視対象の装置が異常であるか否かの状態判定の精度を向上させた監視装置を提供する。
【解決手段】監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答メッセージに書き込まれ、返答メッセージの送信順序を示す情報である順序情報のうち、監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、監視対象の装置に要求メッセージを定期的に送信し、監視対象の装置から返答メッセージを受信すると、返答メッセージから読み出した順序情報と記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージの状態情報に基づいて監視対象の装置の状態を判定する制御部と、を有する。
【解決手段】監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答メッセージに書き込まれ、返答メッセージの送信順序を示す情報である順序情報のうち、監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、監視対象の装置に要求メッセージを定期的に送信し、監視対象の装置から返答メッセージを受信すると、返答メッセージから読み出した順序情報と記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージの状態情報に基づいて監視対象の装置の状態を判定する制御部と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象の装置の状態をネットワークを介して監視する監視装置、監視方法、およびコンピュータに実行させるためのプログラムに関する。
【背景技術】
【０００２】
ＳＮＭＰ(Simple Network Management Protocol)で行われる監視方法では、監視対象の装置と監視装置とがＳＮＭＰメッセージをやり取りすることで、監視対象の装置が正常であるか否かを監視装置が判定する。監視装置はＳＮＭＰマネージャと呼ばれている。また、監視対象の装置には、マネージャから要求があると、監視対象の装置の状態をマネージャに報告する機能部が設けられており、この機能部はＳＮＭＰエージェントと呼ばれている。以下では、ＳＮＭＰマネージャを単にマネージャと称し、ＳＮＭＰエージェントを単にエージェントと称する。ここで、ＳＮＭＰメッセージの一例を説明する。
【０００３】
「GetRequest」は、マネージャからエージェントに送信するＳＮＭＰメッセージの１つであり、指定したＯＩＤ（Object Identifier）の情報取得を要求するメッセージである。「GetResponse」は、エージェントからマネージャに送信するＳＮＭＰメッセージの１つであり、マネージャからの要求に対する返答のメッセージである。ＳＮＭＰでは、監視対象の装置の状態に関する情報である状態情報をオブジェクトとして扱い、各オブジェクトに識別子を付与して階層化ツリー構造にして管理している。ＯＩＤはその状態情報の識別子に相当し、状態情報のデータベースはＭＩＢ（Management Information Base）と呼ばれている。
【０００４】
マネージャは、エージェントに対して定期的にポーリングにて、状態情報を要求する旨の要求メッセージとしてGetRequestを発行する。GetRequestを受け取ったエージェントは、監視対象の装置の現在の状態に関する状態情報を収集すると、GetRequestに対する返答メッセージとして、GetResponseをマネージャに送信する。監視対象の装置の状態情報には、例えば、正常、異常、警告、不明などがある。「警告」は「異常」に至る前の段階にあることを意味する。ＳＮＭＰメッセージのやり取りは、通常、ＵＤＰ（User Datagram Protocol）で行われる。
【０００５】
ＳＮＭＰにしたがって所定の動作を行うためのソフトウェアプログラムが監視対象の装置にインストールされ、そのプログラムが装置内で実行されることで、上記のエージェントが仮想的に構成される。また、マネージャとして機能する情報処理装置においても、ＳＮＭＰにしたがって装置の監視を行うためのソフトウェアプログラムが実行される。これらのソフトウェアプログラムには、監視対象の装置の異常を確実に検出することが求められている。
【０００６】
監視対象の装置の状態判定に、ＳＮＭＰメッセージだけに頼らず、ｐｉｎｇ（packet internet groper）応答も利用する方法が、特許文献１に開示されている。この文献に開示された方法では、ｐｉｎｇ応答が正常で、かつＭＩＢ情報が異常である場合、監視装置はＭＩＢ情報の異常をオペレータ端末に通知し、ｐｉｎｇ応答およびＭＩＢ情報のいずれもが正常である場合、監視装置はオペレータ端末に何も通知しない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１７２５７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
監視対象の装置にハードウェアの故障やＷｉｎｄｏｗｓ（登録商標）のＯＳ（Operating System）パニックのような障害が発生した場合、エージェントは、監視対象の装置に障害が発生したことを検知することが可能である。しかし、Ｌｉｎｕｘ系ＯＳのように、パニック発生後も継続して動作可能なＯＳの場合や、監視対象の装置に異常が発生してもＯＳがメモリ上で継続して動作可能な場合、エージェントが取得した状態情報が「正常」であることを示すままで「異常」に更新されず、その結果、監視装置が異常を検出できず、監視対象の装置が正常に稼働していると誤って判断されるケースがある。
【０００９】
また、ｐｉｎｇではＩＣＭＰ（Internet Control Message Protocol）にしたがって通信が行われるため、ｐｉｎｇを用いた状態判定では、ＯＳレベルでの障害が発生しても、通信が正常に行われてしまい、装置の異常を検出できない可能性がある。特許文献１に開示された方法では、ｐｉｎｇ応答およびＭＩＢ情報のいずれもが正常な場合、監視装置はオペレータ端末に何も通知しないため、ＯＳレベルにおける異常を検出できないという問題がある。
【００１０】
本発明は上述したような技術が有する問題点を解決するためになされたものであり、監視対象の装置が異常であるか否かの状態判定の精度を向上させた監視装置、監視方法、およびコンピュータに実行させるためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するための本発明の監視装置は、監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、
前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、
前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、
を有する構成である。
【００１２】
また、本発明の監視方法は、監視対象の装置とＳＮＭＰメッセージを送受信する監視装置による監視方法であって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定するものである。
【００１３】
また、本発明のプログラムは、監視対象の装置とＳＮＭＰメッセージを送受信するコンピュータに実行させるためのプログラムであって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるものである。
【００１４】
さらに、本発明のプログラムは、監視装置とＳＮＭＰメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、
状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、
前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、
前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるものである。
【発明の効果】
【００１５】
本発明によれば、監視対象の装置が監視装置へＳＮＭＰメッセージを返信し、見かけ上正常でも、監視対象の装置に発生した不具合を検出することができ、監視対象の装置の状態判定の精度を向上させることができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態の監視装置を含む通信システムの一構成例を示すブロック図である。
【図２】本実施形態の監視装置が実行する監視方法の手順を示すフローチャートである。
【図３】実施例１の監視装置を含む通信システムの一構成例を示すブロック図である。
【図４】返答メッセージの一構成例を示す図である。
【図５】実施例１で定義されたServerOpStatusの一例を示す図である。
【図６】図５に示したOpStatusの欄に書き込まれる情報の一例を示す図である。
【図７】実施例１のサーバ状態判定方法の手順を示すフローチャートである。
【図８】ServerOpStatusの別の例を示す図である。
【図９】サーバ状態判定方法について他の例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
本実施形態の監視装置の構成を説明する。本実施形態の監視装置は、サーバ装置やパーソナルコンピュータなどの情報処理装置である。監視対象の装置は、ルータおよびゲートウェイなどのネットワーク機器であってもよく、サーバ装置であってもよい。本実施形態では、監視対象の装置がサーバ装置の場合で説明する。
【００１８】
本実施形態の監視装置は、監視対象の装置とＳＮＭＰメッセージをやり取りすることで、監視対象の装置の状態を判定する。監視装置をマネージャと称し、監視対象のサーバ装置に設けられ、サーバ装置の状態を監視するための機能部をエージェントと称する。
【００１９】
図１は本実施形態の監視装置を含む通信システムの一構成例を示すブロック図である。
【００２０】
図１に示すように、本実施形態の監視装置に相当するマネージャ２と、監視対象のサーバ装置６とがネットワーク７を介して接続されている。サーバ装置６には、マネージャ２とＳＮＭＰメッセージを送受信するエージェント５が設けられている。エージェント５は、サーバ装置６内でプログラムがＣＰＵ（Central Processing Unit）で実行されることで仮想的に構成される。
【００２１】
なお、本実施形態に限らず、後述の実施例および実施形態では、説明を簡単にするために、エージェント５が１つの場合で説明するが、マネージャ２が複数のエージェント５と順にＳＮＭＰメッセージをやり取りすることで、複数のサーバ装置６の状態を監視してもよい。
【００２２】
エージェント５は、状態情報を要求する旨の要求メッセージをマネージャ２から受信すると、サーバ装置６の現在の状態に関する状態情報を取得し、取得した状態情報と、返答メッセージの送信順序を示す情報である順序情報とを返答メッセージに書き込んでマネージャ２に送信する。エージェント５は、送信した返答メッセージをメモリ（不図示）に一定期間保存し、次の返答メッセージを作成する際に、保存した返答メッセージの順序情報を参照する。順序情報として、例えば、シーケンス番号がある。状態情報には、例えば、正常、異常、警告、不明などがある。
【００２３】
マネージャ２は、記憶部３および制御部４を有する。制御部４には、プログラムにしたがって処理を実行するＣＰＵ（不図示）と、プログラムを格納するためのメモリ（不図示）とが設けられている。ＣＰＵがプログラムを実行することで、制御部４がマネージャ２に仮想的に構成される。
【００２４】
記憶部３は、サーバ装置６から受信する返答メッセージに書き込まれた順序情報のうち、サーバ装置６から最後に受信した返答メッセージの順序情報を記憶する。
【００２５】
制御部４は、要求メッセージをサーバ装置６に定期的に送信し、サーバ装置６から返答メッセージを受信すると、返答メッセージから読み出した順序情報と記憶部３に最後に記憶させた順序情報とを比較する。そして、これらの順序情報が一致している場合、制御部４は、サーバ装置６が異常であると判定し、これらの順序情報が異なる場合、制御部４は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置６の状態を判定する。
【００２６】
次に、本実施形態の監視装置が実行する監視方法を説明する。
【００２７】
図２は本実施形態の監視装置が実行する監視方法の手順を示すフローチャートである。
【００２８】
マネージャ２がサーバ装置６に要求メッセージを送信し（ステップ１０１）、エージェント５から返答メッセージを受信すると、受信した返答メッセージから順序情報を読み出す（ステップ１０２）。続いて、マネージャ２は、読み出した順序情報と最後に記憶部３に記憶させた順序情報とを比較し、これらの順序情報が一致するか否かを判定する（ステップ１０３）。
【００２９】
ここで、サーバ装置６にＯＳレベルの障害が発生している場合、エージェント５は新たな返答メッセージを作成できないが、通信は正常なため、最後に送信したものと同じ返答メッセージをマネージャ２に送信することになる。その反対に、サーバ装置６に何も障害が発生していない場合、エージェント５は、最後に送信した返答メッセージの次の返答メッセージを示す順序情報を、返答メッセージに書き込んでマネージャ２に送信する。
【００３０】
ステップ１０３において、読み出した順序情報と最後に記憶部３に記憶させた順序情報とが一致する場合、マネージャ２はサーバ装置６が異常であると判定する（ステップ１０４）。一方、ステップ１０３において、読み出した順序情報と最後に記憶部３に記憶させた順序情報とが異なる場合、マネージャ２は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置の状態を判定する（ステップ１０５）。ステップ１０５の後、マネージャ２は、記憶部３に記憶させた順序情報を、最新の返答メッセージに書き込まれた順序情報に更新する（ステップ１０６）。
【００３１】
なお、マネージャ２は、サーバ装置６が正常でないと判定した場合、状態情報を文字メッセージにして表示部（不図示）に表示してもよく、状態情報を音声メッセージにしてスピーカ（不図示）から出力してもよく、サーバ装置６が正常でないことを管理者に通知する方法については限定されない。
【００３２】
本実施形態では、エージェントはサーバの現在の状態を示す状態情報を返信する際、順序情報をキー情報として返答メッセージに埋め込み、マネージャは前回取得した返答メッセージのキー情報と比較し、キー情報が前回と同じ値であった場合、サーバに不具合が発生したと判定する。これにより、サーバに不具合が起きても、ＯＳが継続的に稼働し続け、見かけ上サーバが正常で、返答される状態情報が正常値のままで更新されず、その結果、装置異常を検出できないような状況を回避することが可能となる。そのため、サーバの稼働状況の判定精度が向上する。
【００３３】
さらに、監視対象の装置がサーバである場合、サーバに実装されるメモリの大容量化も進んでおり、今後はメモリ上のみでＯＳや各ソフトウェアが動作し続けるケースが多く発生すると推測される。本実施形態の監視方法では、見かけ上正常なサーバに不具合が発生していることを検出することが可能となる。
【００３４】
以下に、本実施形態の実施例を説明する。
【実施例１】
【００３５】
本実施例においても、監視対象をサーバ装置とし、エージェントがサーバ装置に含まれるものとし、監視装置をマネージャと称する。また、本実施例では、サーバ装置の状態判定の精度向上を目的として、マネージャとサーバ装置とのやり取りにｐｉｎｇの通信処理を追加した場合を説明する。また、本実施例では、順序情報がシーケンス番号の場合である。ＳＮＭＰメッセージのパケットをＳＮＭＰパケットと称する。
【００３６】
図３は本実施例の監視装置を含む通信システムの一構成例を示すブロック図である。図３に示すように、通信システムは、状態情報の要求(リクエスト)を行うマネージャ１０と、リクエストに対して結果(レスポンス)を返すエージェント２０を含むサーバ３０とを有する。サーバ３０が監視対象の装置に相当する。マネージャ１０およびサーバ３０の間には通信可能なネットワーク環境が構築されている。
【００３７】
マネージャ１０は、表示部１１と、記憶部１６と、データ収集部１７と、パケット処理部１２と、ＳＮＭＰパケットを作成するパケット作成部１５と、通信部１８とを有する。通信部１８は、ＳＮＭＰパケットの送信およびｐｉｎｇの送信を行うリクエスト送信部１４と、ＳＮＭＰパケットの受信およびｐｉｎｇの受信を行うレスポンス受信部１３とを有する。
【００３８】
サーバ３０は、エージェント２０およびｐｉｎｇ送受信部２５を有する。エージェント２０は、ＳＮＭＰレスポンス送信部２１およびＳＮＭＰリクエスト受信部２２を含む通信部２６と、パケット作成部２３と、要求処理部２４とを有する。
【００３９】
図３に示した、マネージャ１０について詳しく説明する。
【００４０】
データ収集部１７は、メモリ（不図示）に登録されたエージェント２０のステータス情報取得のためにポーリングで、要求メッセージ（GetRequest）をエージェント２０に発行し、ｐｉｎｇコマンドの１つとしてｐｉｎｇリクエストをサーバ装置３０のｐｉｎｇ送受信部２５に発行する指示をパケット作成部１５に通知する。データ収集部１７はパケット処理部１２から受け取る状態情報とシーケンス番号を記憶部１６に格納する。サーバ３０に不具合が発生している場合には、データ収集部１７はアラートを記憶部１６に登録する。
【００４１】
パケット作成部１５は、データ収集部１７から要求メッセージおよびｐｉｎｇリクエストの発行の指示を受けると、要求メッセージおよびｐｉｎｇリクエストを作成してリクエスト送信部１４に渡す。
【００４２】
リクエスト送信部１４は、要求メッセージをエージェント２０宛にネットワークを介して送信し、ｐｉｎｇリクエストをサーバ３０宛にネットワークを介して送信する。レスポンス受信部１３は、エージェント２０から受信する返答メッセージをパケット処理部１２に渡し、サーバ３０から受信するｐｉｎｇリプライをパケット処理部１２に渡す。
【００４３】
パケット処理部１２は、ｐｉｎｇリクエストおよびｐｉｎｇリプライによるｐｉｎｇ通信の結果と返答メッセージのデータを解析して、サーバ装置３０の状態を判定する。具体的には、パケット処理部１２は、今回受け取った返答メッセージと前回の返答メッセージのそれぞれのシーケンス番号を比較し、これらのシーケンス番号が一致している場合、サーバ３０が異常であると判定し、これらのシーケンス番号が一致していない場合、返答メッセージに含まれる状態情報でサーバ３０の状態を判定する。また、要求メッセージを送信してから返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、パケット処理部１２は、タイムアウトと判断し、ｐｉｎｇ通信の結果を参照する。ｐｉｎｇ通信の結果が、ｐｉｎｇリプライを受信していないものであったり、ｐｉｎｇリクエスト送信からｐｉｎｇリプライの受信までの時間が基準値よりオーバーしていたりする場合、パケット処理部１２は、サーバ３０が異常であると判定するが、ｐｉｎｇ通信の結果が正常である場合、タイムアウト後に受信する返答メッセージに対して上述の処理を行う。このようにして、本実施例のマネージャ１０はｐｉｎｇの通信結果と返答メッセージの状態情報とを合わせてサーバ３０の状態判定を行う。
【００４４】
ＳＮＭＰメッセージだけでなく、ｐｉｎｇの通信結果を用いて状態判定を行うことで、エージェント側のシステム負荷が高い場合や、採取するデータが多く、エージェントの情報収集に時間がかかり、返答メッセージが遅れている場合でも、ｐｉｎｇによる通信が可能な場合はサーバダウンとみなさずに、正常稼働と判断することが可能となる。
【００４５】
パケット処理部１２は、返答メッセージから読み出した状態情報とシーケンス番号をデータ収集部１７に渡す。パケット処理部１２は、サーバ３０が正常でないと判定した場合、状態情報から正常でないことを認識できれば、状態情報を文字メッセージにして表示部１１に表示し、状態情報から正常でないことを認識できれば、サーバ３０が異常である旨のメッセージを表示部１１に表示させる。これにより、サーバ３０が正常でないことが管理者に通知される。
【００４６】
次に、サーバ３０側の構成について説明する。
【００４７】
エージェント２０のＳＮＭＰリクエスト受信部２２は、マネージャ１０からネットワークを介して要求メッセージを受信すると、要求メッセージを要求処理部２４に渡す。ＳＮＭＰレスポンス送信部２１は、パケット作成部２３から返答メッセージを受け取ると、ネットワークを介してマネージャ１０に返答メッセージを送信する。
【００４８】
エージェント２０の要求処理部２４は、ＳＮＭＰリクエスト受信部２２から要求メッセージを受け取ると、サーバ３０の状態情報を取得し、取得した状態情報をパケット作成部２３に渡す。パケット作成部２３は、要求処理部２４から渡された状態情報のデータとキー情報となるシーケンス番号を書き込んだ返答メッセージ(GetResponse)を作成してＳＮＭＰレスポンス送信部２１に渡す。
【００４９】
サーバ３０のｐｉｎｇ送受信部２５は、マネージャ１０からｐｉｎｇリクエストを受信すると、マネージャ１０宛にｐｉｎｇリプライを送信する。このとき、ｐｉｎｇリクエストおよびｐｉｎｇリプライは、ＳＮＭＰの要求メッセージおよび返答メッセージとは、異なる通信経路で伝送される場合がある。
【００５０】
ここで、エージェント２０からマネージャ１０に送信される返答メッセージの構成について説明する。図４から図６はＭＩＢ定義ファイルの一例である。
【００５１】
図４は返答メッセージの一構成例であり、ＭＩＢ定義によるOpStatusServerを示す図である。図４に示すSYNTAX ServerOpStatusに、指定されたオブジェクトの状態情報が書き込まれる。図５は、図４に示したSYNTAX ServerOpStatusに相当し、ＭＩＢ定義によるServerOpStatusを示す図である。図５に示すように、本実施例のServerOpStatusには、状態情報が書き込まれるOpStatusの他に、シーケンス番号（sequential number）も定義されている。
【００５２】
図６は、図５に示したOpStatusの欄に書き込まれる情報に相当し、ＭＩＢ定義によるOpStatusを示す図である。パケット作成部２３は、要求処理部２４から装置の状態情報を受け取ると、状態情報に対応して図６に示したother(1)〜fatal(5)からいずれか１つを選択し、選択した状態情報とシーケンス番号を図５の定義にしたがって、図４に示す返答メッセージの構成に書き込む。これらの定義にしたがって、マネージャ１０は、返答メッセージのSYNTAX ServerOpStatusからシーケンス番号と状態情報を読み出す。
【００５３】
次に、本実施例のマネージャ１０が実行するサーバ状態判定方法を説明する。図７は本実施例のサーバ状態判定方法の手順を示すフローチャートである。
【００５４】
マネージャ１０は、リクエスト送信部１４からサーバ３０宛のｐｉｎｇリクエストを発行し（ステップＡ１）、続いて、エージェント２０に対して要求メッセージのＳＮＭＰパケットを送信する（ステップＡ２)。マネージャ１０は、ステップＡ２で送信したＳＮＭＰパケットに対するレスポンスを待つ(ステップＡ３)。ｐｉｎｇリクエストおよびＳＮＭＰパケットはネットワークを介してサーバ３０に送信される。ＳＮＭＰパケットはＳＮＭＰリクエスト受信部２２で受信され、ｐｉｎｇリクエストはｐｉｎｇ送受信部２５で受信される。なお、ステップＡ１およびステップＡ２の処理は、いずれが先でも、同時でもよい。
【００５５】
ｐｉｎｇ送受信部２５はｐｉｎｇリクエストを受信すると、ｐｉｎｇリクエストをｐｉｎｇリプライとしてレスポンス受信部１３に返信する。ＳＮＭＰリクエスト受信部２２で受信されたＳＮＭＰパケットは、処理待ちキューリストに一旦格納された後、順番に要求処理部２４で処理され、パケット作成部２３に渡される。パケット作成部２３は、状態情報およびシーケンス番号を書き込んだ返答メッセージのＳＮＭＰパケットを作成してＳＮＭＰレスポンス送信部２１に渡す。返答メッセージのＳＮＭＰパケットは、レスポンス送信部２１からマネージャ１０に送信され、レスポンス受信部１３で受信される。
【００５６】
一方、サーバ３０に不具合が発生し、エージェント２０の要求処理部２４の動作に影響を及ぼすと、パケット作成部２３は、新たな状態情報を要求処理部２４から受け取れず、前回作成した返答メッセージをそのままマネージャ１０に送信する。
【００５７】
マネージャ１０は、所定の時間までにエージェント２０からＳＮＭＰパケットを受信した場合、ステップＡ５の処理に移行し、ＳＮＭＰパケットを受信しなかった場合、ステップＡ４の処理に移行する。ステップＡ４では、マネージャ１０は、エージェント２０が存在するサーバ３０とのｐｉｎｇ通信の判定を行い、ｐｉｎｇリプライを受信するまでの時間が基準値を越えてタイムアウトした場合、サーバ３０が異常と判断する。ステップＡ４で、ｐｉｎｇリプライを基準以内に受信し、ｐｉｎｇによる通信が正常である場合、マネージャ１０は、エージェント２０側のＳＮＭＰパケット処理に時間がかかっている判断し、ステップＡ３へ戻る。
【００５８】
ステップＡ５では、マネージャ１０は、エージェント２０から返答メッセージのＳＮＭＰパケットを受信すると、返答メッセージからシーケンス番号を読み出し、読み出したシーケンス番号と前回の返答メッセージのシーケンス番号とを比較し、これらのシーケンス番号が一致するか否かを判定する。これらのシーケンス番号が同じ場合、マネージャ１０は、サーバ３０に不具合が発生したことによりエージェント２０の動作に影響が出たと判断し、サーバ３０が異常と判断し、アラートを登録して表示部１１を介して管理者に通知する。一方、ステップＡ５で、比較対象の２つのシーケンス番号が異なる場合、マネージャ１０は、エージェント２０によるサーバ監視が正常に行われていると判断し、返答メッセージのOpStatusの値に基づいて、サーバ３０の状態判定を行う（ステップＡ６）。OpStatusがnormal(3)であれば、マネージャ１０はサーバ３０が正常であると判定し、OpStatusがnormal(3)以外であれば、マネージャ１０は、サーバ３０の状態情報を管理者に通知する。
【００５９】
本実施例によれば、エージェントから返送される返答メッセージにキー情報を含めることで、見かけ上、正常稼働しているサーバの異常を検出できる。その理由は、返答メッセージにキー情報を埋め込むことで、マネージャは受け取った状態情報が最新の情報であるか前回の情報であるかを判定することで、エージェントから最新の状態情報が返答されない場合は、サーバに何らかの不具合が発生したことを判断できるためである。そのため、エージェントが存在するサーバの稼働状況の判定精度が向上する。
【００６０】
また、ｐｉｎｇ通信を利用することにより、次のような効果が得られる。
【００６１】
エージェントはマネージャからの要求を受けてから、サーバの状態情報を収集するため、エージェントがインストールされたサーバの負荷が高い場合や情報取得先からレスポンスが遅い場合はタイムアウトするまで待ち、全ての情報を収集してから、マネージャへＳＮＭＰメッセージを返却する。その結果、ＳＮＭＰメッセージの発行から一定時間内にレスポンスが返却されないケースがあり、この場合、マネージャはサーバがダウンしたと誤検出してしまうおそれがある。
【００６２】
これに対して、本実施例では、マネージャおよびエージェント間のやり取りにｐｉｎｇの通信を行い、返答メッセージを受け取るのが遅くタイムアウトになっても、ｐｉｎｇ通信が可能な場合は、サーバダウンとみなさず、返答メッセージを待って状態判定を行う。その理由は、エージェント側がシステム負荷により要求処理に時間がかかっている場合や収集データが多く時間がかかっている場合、マネージャ側はエージェント側の状況を認識することができないため、サーバ側に異常が発生したと誤判断してしまうが、マネージャがＳＮＭＰメッセージとは異なる通信経路で送受信されるｐｉｎｇ通信でサーバに異常がないことを確認することで、誤検出を防ぐことができるからである。そのため、エージェントが存在するサーバの稼働状況の判定精度をより向上させることが可能となる。
【００６３】
特許文献１に開示された方法では、ｐｉｎｇ通信を用いているが、タイムアウトによりＭＩＢ情報が異常と判定された場合、ｐｉｎｇ応答が正常であっても、監視装置はＭＩＢ情報の異常をオペレータ端末に通知するので、サーバがダウンしたと誤検出されるおそれがある。
【００６４】
なお、上記の実施例１では、返答メッセージの送信順序を示す順序情報として、シーケンス番号を用いたが、シーケンス番号に限らない。順序情報として、日時の情報を用いてもよい。
【００６５】
図８はServerOpStatusの別の例を示す図である。図８に示すServerOpStatusのＭＩＢ定義では、図５に示したシーケンス番号の代わりに、日時（Date&Time）の情報が定義されている。ここで、日時（Date&Time）は、予め定義しておけば、エージェント２０における、どの処理の日時であってもよい。日時（Date&Time）は、例えば、「返答メッセージの送信日時」である。
【００６６】
図９は、順序情報が送信日時の情報である場合のサーバ状態判定方法の手順を示すフローチャートである。
【００６７】
図９に示すフローチャートでは、図７に示したステップＡ５がステップＢ５に示す処理に代わっている。ステップＢ５において、マネージャ１０は、エージェント２０から返答メッセージのＳＮＭＰパケットを受信すると、返答メッセージから送信日時の情報を読み出し、読み出した送信日時と前回の返答メッセージの送信日時とを比較し、これらの送信日時が一致するか否かを判定する。これらの送信日時が一致する場合、マネージャ１０は、サーバ３０が異常であると判断する。一方、ステップＢ５で、２つの送信日時が異なる場合、マネージャ１０は、エージェント２０によるサーバ監視が正常に行われていると判断し、ステップＡ６に移行する。なお、ステップＢ５を除く処理については、図７で説明した処理と同様なため、詳細な説明を省略する。
【００６８】
このようにして、順序情報として、返答メッセージ毎に異なる情報を返答メッセージに追加することでサーバ障害検出時の分解能を向上させることが可能となる。
【００６９】
本発明を、サーバに監視用エージェントを常駐させ、管理端末のマネージャからサーバ監視を行う通信システムにおいて、エージェントおよびマネージャのそれぞれのソフトウェアプログラムに対して適用することが可能である。
【符号の説明】
【００７０】
２ マネージャ
３ 記憶部
４ 制御部
５ エージェント
６ サーバ装置
７ ネットワーク
【技術分野】
【０００１】
本発明は、監視対象の装置の状態をネットワークを介して監視する監視装置、監視方法、およびコンピュータに実行させるためのプログラムに関する。
【背景技術】
【０００２】
ＳＮＭＰ(Simple Network Management Protocol)で行われる監視方法では、監視対象の装置と監視装置とがＳＮＭＰメッセージをやり取りすることで、監視対象の装置が正常であるか否かを監視装置が判定する。監視装置はＳＮＭＰマネージャと呼ばれている。また、監視対象の装置には、マネージャから要求があると、監視対象の装置の状態をマネージャに報告する機能部が設けられており、この機能部はＳＮＭＰエージェントと呼ばれている。以下では、ＳＮＭＰマネージャを単にマネージャと称し、ＳＮＭＰエージェントを単にエージェントと称する。ここで、ＳＮＭＰメッセージの一例を説明する。
【０００３】
「GetRequest」は、マネージャからエージェントに送信するＳＮＭＰメッセージの１つであり、指定したＯＩＤ（Object Identifier）の情報取得を要求するメッセージである。「GetResponse」は、エージェントからマネージャに送信するＳＮＭＰメッセージの１つであり、マネージャからの要求に対する返答のメッセージである。ＳＮＭＰでは、監視対象の装置の状態に関する情報である状態情報をオブジェクトとして扱い、各オブジェクトに識別子を付与して階層化ツリー構造にして管理している。ＯＩＤはその状態情報の識別子に相当し、状態情報のデータベースはＭＩＢ（Management Information Base）と呼ばれている。
【０００４】
マネージャは、エージェントに対して定期的にポーリングにて、状態情報を要求する旨の要求メッセージとしてGetRequestを発行する。GetRequestを受け取ったエージェントは、監視対象の装置の現在の状態に関する状態情報を収集すると、GetRequestに対する返答メッセージとして、GetResponseをマネージャに送信する。監視対象の装置の状態情報には、例えば、正常、異常、警告、不明などがある。「警告」は「異常」に至る前の段階にあることを意味する。ＳＮＭＰメッセージのやり取りは、通常、ＵＤＰ（User Datagram Protocol）で行われる。
【０００５】
ＳＮＭＰにしたがって所定の動作を行うためのソフトウェアプログラムが監視対象の装置にインストールされ、そのプログラムが装置内で実行されることで、上記のエージェントが仮想的に構成される。また、マネージャとして機能する情報処理装置においても、ＳＮＭＰにしたがって装置の監視を行うためのソフトウェアプログラムが実行される。これらのソフトウェアプログラムには、監視対象の装置の異常を確実に検出することが求められている。
【０００６】
監視対象の装置の状態判定に、ＳＮＭＰメッセージだけに頼らず、ｐｉｎｇ（packet internet groper）応答も利用する方法が、特許文献１に開示されている。この文献に開示された方法では、ｐｉｎｇ応答が正常で、かつＭＩＢ情報が異常である場合、監視装置はＭＩＢ情報の異常をオペレータ端末に通知し、ｐｉｎｇ応答およびＭＩＢ情報のいずれもが正常である場合、監視装置はオペレータ端末に何も通知しない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００８−１７２５７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
監視対象の装置にハードウェアの故障やＷｉｎｄｏｗｓ（登録商標）のＯＳ（Operating System）パニックのような障害が発生した場合、エージェントは、監視対象の装置に障害が発生したことを検知することが可能である。しかし、Ｌｉｎｕｘ系ＯＳのように、パニック発生後も継続して動作可能なＯＳの場合や、監視対象の装置に異常が発生してもＯＳがメモリ上で継続して動作可能な場合、エージェントが取得した状態情報が「正常」であることを示すままで「異常」に更新されず、その結果、監視装置が異常を検出できず、監視対象の装置が正常に稼働していると誤って判断されるケースがある。
【０００９】
また、ｐｉｎｇではＩＣＭＰ（Internet Control Message Protocol）にしたがって通信が行われるため、ｐｉｎｇを用いた状態判定では、ＯＳレベルでの障害が発生しても、通信が正常に行われてしまい、装置の異常を検出できない可能性がある。特許文献１に開示された方法では、ｐｉｎｇ応答およびＭＩＢ情報のいずれもが正常な場合、監視装置はオペレータ端末に何も通知しないため、ＯＳレベルにおける異常を検出できないという問題がある。
【００１０】
本発明は上述したような技術が有する問題点を解決するためになされたものであり、監視対象の装置が異常であるか否かの状態判定の精度を向上させた監視装置、監視方法、およびコンピュータに実行させるためのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するための本発明の監視装置は、監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、
前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、
前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、
を有する構成である。
【００１２】
また、本発明の監視方法は、監視対象の装置とＳＮＭＰメッセージを送受信する監視装置による監視方法であって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定するものである。
【００１３】
また、本発明のプログラムは、監視対象の装置とＳＮＭＰメッセージを送受信するコンピュータに実行させるためのプログラムであって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるものである。
【００１４】
さらに、本発明のプログラムは、監視装置とＳＮＭＰメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、
状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、
前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、
前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるものである。
【発明の効果】
【００１５】
本発明によれば、監視対象の装置が監視装置へＳＮＭＰメッセージを返信し、見かけ上正常でも、監視対象の装置に発生した不具合を検出することができ、監視対象の装置の状態判定の精度を向上させることができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態の監視装置を含む通信システムの一構成例を示すブロック図である。
【図２】本実施形態の監視装置が実行する監視方法の手順を示すフローチャートである。
【図３】実施例１の監視装置を含む通信システムの一構成例を示すブロック図である。
【図４】返答メッセージの一構成例を示す図である。
【図５】実施例１で定義されたServerOpStatusの一例を示す図である。
【図６】図５に示したOpStatusの欄に書き込まれる情報の一例を示す図である。
【図７】実施例１のサーバ状態判定方法の手順を示すフローチャートである。
【図８】ServerOpStatusの別の例を示す図である。
【図９】サーバ状態判定方法について他の例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
本実施形態の監視装置の構成を説明する。本実施形態の監視装置は、サーバ装置やパーソナルコンピュータなどの情報処理装置である。監視対象の装置は、ルータおよびゲートウェイなどのネットワーク機器であってもよく、サーバ装置であってもよい。本実施形態では、監視対象の装置がサーバ装置の場合で説明する。
【００１８】
本実施形態の監視装置は、監視対象の装置とＳＮＭＰメッセージをやり取りすることで、監視対象の装置の状態を判定する。監視装置をマネージャと称し、監視対象のサーバ装置に設けられ、サーバ装置の状態を監視するための機能部をエージェントと称する。
【００１９】
図１は本実施形態の監視装置を含む通信システムの一構成例を示すブロック図である。
【００２０】
図１に示すように、本実施形態の監視装置に相当するマネージャ２と、監視対象のサーバ装置６とがネットワーク７を介して接続されている。サーバ装置６には、マネージャ２とＳＮＭＰメッセージを送受信するエージェント５が設けられている。エージェント５は、サーバ装置６内でプログラムがＣＰＵ（Central Processing Unit）で実行されることで仮想的に構成される。
【００２１】
なお、本実施形態に限らず、後述の実施例および実施形態では、説明を簡単にするために、エージェント５が１つの場合で説明するが、マネージャ２が複数のエージェント５と順にＳＮＭＰメッセージをやり取りすることで、複数のサーバ装置６の状態を監視してもよい。
【００２２】
エージェント５は、状態情報を要求する旨の要求メッセージをマネージャ２から受信すると、サーバ装置６の現在の状態に関する状態情報を取得し、取得した状態情報と、返答メッセージの送信順序を示す情報である順序情報とを返答メッセージに書き込んでマネージャ２に送信する。エージェント５は、送信した返答メッセージをメモリ（不図示）に一定期間保存し、次の返答メッセージを作成する際に、保存した返答メッセージの順序情報を参照する。順序情報として、例えば、シーケンス番号がある。状態情報には、例えば、正常、異常、警告、不明などがある。
【００２３】
マネージャ２は、記憶部３および制御部４を有する。制御部４には、プログラムにしたがって処理を実行するＣＰＵ（不図示）と、プログラムを格納するためのメモリ（不図示）とが設けられている。ＣＰＵがプログラムを実行することで、制御部４がマネージャ２に仮想的に構成される。
【００２４】
記憶部３は、サーバ装置６から受信する返答メッセージに書き込まれた順序情報のうち、サーバ装置６から最後に受信した返答メッセージの順序情報を記憶する。
【００２５】
制御部４は、要求メッセージをサーバ装置６に定期的に送信し、サーバ装置６から返答メッセージを受信すると、返答メッセージから読み出した順序情報と記憶部３に最後に記憶させた順序情報とを比較する。そして、これらの順序情報が一致している場合、制御部４は、サーバ装置６が異常であると判定し、これらの順序情報が異なる場合、制御部４は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置６の状態を判定する。
【００２６】
次に、本実施形態の監視装置が実行する監視方法を説明する。
【００２７】
図２は本実施形態の監視装置が実行する監視方法の手順を示すフローチャートである。
【００２８】
マネージャ２がサーバ装置６に要求メッセージを送信し（ステップ１０１）、エージェント５から返答メッセージを受信すると、受信した返答メッセージから順序情報を読み出す（ステップ１０２）。続いて、マネージャ２は、読み出した順序情報と最後に記憶部３に記憶させた順序情報とを比較し、これらの順序情報が一致するか否かを判定する（ステップ１０３）。
【００２９】
ここで、サーバ装置６にＯＳレベルの障害が発生している場合、エージェント５は新たな返答メッセージを作成できないが、通信は正常なため、最後に送信したものと同じ返答メッセージをマネージャ２に送信することになる。その反対に、サーバ装置６に何も障害が発生していない場合、エージェント５は、最後に送信した返答メッセージの次の返答メッセージを示す順序情報を、返答メッセージに書き込んでマネージャ２に送信する。
【００３０】
ステップ１０３において、読み出した順序情報と最後に記憶部３に記憶させた順序情報とが一致する場合、マネージャ２はサーバ装置６が異常であると判定する（ステップ１０４）。一方、ステップ１０３において、読み出した順序情報と最後に記憶部３に記憶させた順序情報とが異なる場合、マネージャ２は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置の状態を判定する（ステップ１０５）。ステップ１０５の後、マネージャ２は、記憶部３に記憶させた順序情報を、最新の返答メッセージに書き込まれた順序情報に更新する（ステップ１０６）。
【００３１】
なお、マネージャ２は、サーバ装置６が正常でないと判定した場合、状態情報を文字メッセージにして表示部（不図示）に表示してもよく、状態情報を音声メッセージにしてスピーカ（不図示）から出力してもよく、サーバ装置６が正常でないことを管理者に通知する方法については限定されない。
【００３２】
本実施形態では、エージェントはサーバの現在の状態を示す状態情報を返信する際、順序情報をキー情報として返答メッセージに埋め込み、マネージャは前回取得した返答メッセージのキー情報と比較し、キー情報が前回と同じ値であった場合、サーバに不具合が発生したと判定する。これにより、サーバに不具合が起きても、ＯＳが継続的に稼働し続け、見かけ上サーバが正常で、返答される状態情報が正常値のままで更新されず、その結果、装置異常を検出できないような状況を回避することが可能となる。そのため、サーバの稼働状況の判定精度が向上する。
【００３３】
さらに、監視対象の装置がサーバである場合、サーバに実装されるメモリの大容量化も進んでおり、今後はメモリ上のみでＯＳや各ソフトウェアが動作し続けるケースが多く発生すると推測される。本実施形態の監視方法では、見かけ上正常なサーバに不具合が発生していることを検出することが可能となる。
【００３４】
以下に、本実施形態の実施例を説明する。
【実施例１】
【００３５】
本実施例においても、監視対象をサーバ装置とし、エージェントがサーバ装置に含まれるものとし、監視装置をマネージャと称する。また、本実施例では、サーバ装置の状態判定の精度向上を目的として、マネージャとサーバ装置とのやり取りにｐｉｎｇの通信処理を追加した場合を説明する。また、本実施例では、順序情報がシーケンス番号の場合である。ＳＮＭＰメッセージのパケットをＳＮＭＰパケットと称する。
【００３６】
図３は本実施例の監視装置を含む通信システムの一構成例を示すブロック図である。図３に示すように、通信システムは、状態情報の要求(リクエスト)を行うマネージャ１０と、リクエストに対して結果(レスポンス)を返すエージェント２０を含むサーバ３０とを有する。サーバ３０が監視対象の装置に相当する。マネージャ１０およびサーバ３０の間には通信可能なネットワーク環境が構築されている。
【００３７】
マネージャ１０は、表示部１１と、記憶部１６と、データ収集部１７と、パケット処理部１２と、ＳＮＭＰパケットを作成するパケット作成部１５と、通信部１８とを有する。通信部１８は、ＳＮＭＰパケットの送信およびｐｉｎｇの送信を行うリクエスト送信部１４と、ＳＮＭＰパケットの受信およびｐｉｎｇの受信を行うレスポンス受信部１３とを有する。
【００３８】
サーバ３０は、エージェント２０およびｐｉｎｇ送受信部２５を有する。エージェント２０は、ＳＮＭＰレスポンス送信部２１およびＳＮＭＰリクエスト受信部２２を含む通信部２６と、パケット作成部２３と、要求処理部２４とを有する。
【００３９】
図３に示した、マネージャ１０について詳しく説明する。
【００４０】
データ収集部１７は、メモリ（不図示）に登録されたエージェント２０のステータス情報取得のためにポーリングで、要求メッセージ（GetRequest）をエージェント２０に発行し、ｐｉｎｇコマンドの１つとしてｐｉｎｇリクエストをサーバ装置３０のｐｉｎｇ送受信部２５に発行する指示をパケット作成部１５に通知する。データ収集部１７はパケット処理部１２から受け取る状態情報とシーケンス番号を記憶部１６に格納する。サーバ３０に不具合が発生している場合には、データ収集部１７はアラートを記憶部１６に登録する。
【００４１】
パケット作成部１５は、データ収集部１７から要求メッセージおよびｐｉｎｇリクエストの発行の指示を受けると、要求メッセージおよびｐｉｎｇリクエストを作成してリクエスト送信部１４に渡す。
【００４２】
リクエスト送信部１４は、要求メッセージをエージェント２０宛にネットワークを介して送信し、ｐｉｎｇリクエストをサーバ３０宛にネットワークを介して送信する。レスポンス受信部１３は、エージェント２０から受信する返答メッセージをパケット処理部１２に渡し、サーバ３０から受信するｐｉｎｇリプライをパケット処理部１２に渡す。
【００４３】
パケット処理部１２は、ｐｉｎｇリクエストおよびｐｉｎｇリプライによるｐｉｎｇ通信の結果と返答メッセージのデータを解析して、サーバ装置３０の状態を判定する。具体的には、パケット処理部１２は、今回受け取った返答メッセージと前回の返答メッセージのそれぞれのシーケンス番号を比較し、これらのシーケンス番号が一致している場合、サーバ３０が異常であると判定し、これらのシーケンス番号が一致していない場合、返答メッセージに含まれる状態情報でサーバ３０の状態を判定する。また、要求メッセージを送信してから返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、パケット処理部１２は、タイムアウトと判断し、ｐｉｎｇ通信の結果を参照する。ｐｉｎｇ通信の結果が、ｐｉｎｇリプライを受信していないものであったり、ｐｉｎｇリクエスト送信からｐｉｎｇリプライの受信までの時間が基準値よりオーバーしていたりする場合、パケット処理部１２は、サーバ３０が異常であると判定するが、ｐｉｎｇ通信の結果が正常である場合、タイムアウト後に受信する返答メッセージに対して上述の処理を行う。このようにして、本実施例のマネージャ１０はｐｉｎｇの通信結果と返答メッセージの状態情報とを合わせてサーバ３０の状態判定を行う。
【００４４】
ＳＮＭＰメッセージだけでなく、ｐｉｎｇの通信結果を用いて状態判定を行うことで、エージェント側のシステム負荷が高い場合や、採取するデータが多く、エージェントの情報収集に時間がかかり、返答メッセージが遅れている場合でも、ｐｉｎｇによる通信が可能な場合はサーバダウンとみなさずに、正常稼働と判断することが可能となる。
【００４５】
パケット処理部１２は、返答メッセージから読み出した状態情報とシーケンス番号をデータ収集部１７に渡す。パケット処理部１２は、サーバ３０が正常でないと判定した場合、状態情報から正常でないことを認識できれば、状態情報を文字メッセージにして表示部１１に表示し、状態情報から正常でないことを認識できれば、サーバ３０が異常である旨のメッセージを表示部１１に表示させる。これにより、サーバ３０が正常でないことが管理者に通知される。
【００４６】
次に、サーバ３０側の構成について説明する。
【００４７】
エージェント２０のＳＮＭＰリクエスト受信部２２は、マネージャ１０からネットワークを介して要求メッセージを受信すると、要求メッセージを要求処理部２４に渡す。ＳＮＭＰレスポンス送信部２１は、パケット作成部２３から返答メッセージを受け取ると、ネットワークを介してマネージャ１０に返答メッセージを送信する。
【００４８】
エージェント２０の要求処理部２４は、ＳＮＭＰリクエスト受信部２２から要求メッセージを受け取ると、サーバ３０の状態情報を取得し、取得した状態情報をパケット作成部２３に渡す。パケット作成部２３は、要求処理部２４から渡された状態情報のデータとキー情報となるシーケンス番号を書き込んだ返答メッセージ(GetResponse)を作成してＳＮＭＰレスポンス送信部２１に渡す。
【００４９】
サーバ３０のｐｉｎｇ送受信部２５は、マネージャ１０からｐｉｎｇリクエストを受信すると、マネージャ１０宛にｐｉｎｇリプライを送信する。このとき、ｐｉｎｇリクエストおよびｐｉｎｇリプライは、ＳＮＭＰの要求メッセージおよび返答メッセージとは、異なる通信経路で伝送される場合がある。
【００５０】
ここで、エージェント２０からマネージャ１０に送信される返答メッセージの構成について説明する。図４から図６はＭＩＢ定義ファイルの一例である。
【００５１】
図４は返答メッセージの一構成例であり、ＭＩＢ定義によるOpStatusServerを示す図である。図４に示すSYNTAX ServerOpStatusに、指定されたオブジェクトの状態情報が書き込まれる。図５は、図４に示したSYNTAX ServerOpStatusに相当し、ＭＩＢ定義によるServerOpStatusを示す図である。図５に示すように、本実施例のServerOpStatusには、状態情報が書き込まれるOpStatusの他に、シーケンス番号（sequential number）も定義されている。
【００５２】
図６は、図５に示したOpStatusの欄に書き込まれる情報に相当し、ＭＩＢ定義によるOpStatusを示す図である。パケット作成部２３は、要求処理部２４から装置の状態情報を受け取ると、状態情報に対応して図６に示したother(1)〜fatal(5)からいずれか１つを選択し、選択した状態情報とシーケンス番号を図５の定義にしたがって、図４に示す返答メッセージの構成に書き込む。これらの定義にしたがって、マネージャ１０は、返答メッセージのSYNTAX ServerOpStatusからシーケンス番号と状態情報を読み出す。
【００５３】
次に、本実施例のマネージャ１０が実行するサーバ状態判定方法を説明する。図７は本実施例のサーバ状態判定方法の手順を示すフローチャートである。
【００５４】
マネージャ１０は、リクエスト送信部１４からサーバ３０宛のｐｉｎｇリクエストを発行し（ステップＡ１）、続いて、エージェント２０に対して要求メッセージのＳＮＭＰパケットを送信する（ステップＡ２)。マネージャ１０は、ステップＡ２で送信したＳＮＭＰパケットに対するレスポンスを待つ(ステップＡ３)。ｐｉｎｇリクエストおよびＳＮＭＰパケットはネットワークを介してサーバ３０に送信される。ＳＮＭＰパケットはＳＮＭＰリクエスト受信部２２で受信され、ｐｉｎｇリクエストはｐｉｎｇ送受信部２５で受信される。なお、ステップＡ１およびステップＡ２の処理は、いずれが先でも、同時でもよい。
【００５５】
ｐｉｎｇ送受信部２５はｐｉｎｇリクエストを受信すると、ｐｉｎｇリクエストをｐｉｎｇリプライとしてレスポンス受信部１３に返信する。ＳＮＭＰリクエスト受信部２２で受信されたＳＮＭＰパケットは、処理待ちキューリストに一旦格納された後、順番に要求処理部２４で処理され、パケット作成部２３に渡される。パケット作成部２３は、状態情報およびシーケンス番号を書き込んだ返答メッセージのＳＮＭＰパケットを作成してＳＮＭＰレスポンス送信部２１に渡す。返答メッセージのＳＮＭＰパケットは、レスポンス送信部２１からマネージャ１０に送信され、レスポンス受信部１３で受信される。
【００５６】
一方、サーバ３０に不具合が発生し、エージェント２０の要求処理部２４の動作に影響を及ぼすと、パケット作成部２３は、新たな状態情報を要求処理部２４から受け取れず、前回作成した返答メッセージをそのままマネージャ１０に送信する。
【００５７】
マネージャ１０は、所定の時間までにエージェント２０からＳＮＭＰパケットを受信した場合、ステップＡ５の処理に移行し、ＳＮＭＰパケットを受信しなかった場合、ステップＡ４の処理に移行する。ステップＡ４では、マネージャ１０は、エージェント２０が存在するサーバ３０とのｐｉｎｇ通信の判定を行い、ｐｉｎｇリプライを受信するまでの時間が基準値を越えてタイムアウトした場合、サーバ３０が異常と判断する。ステップＡ４で、ｐｉｎｇリプライを基準以内に受信し、ｐｉｎｇによる通信が正常である場合、マネージャ１０は、エージェント２０側のＳＮＭＰパケット処理に時間がかかっている判断し、ステップＡ３へ戻る。
【００５８】
ステップＡ５では、マネージャ１０は、エージェント２０から返答メッセージのＳＮＭＰパケットを受信すると、返答メッセージからシーケンス番号を読み出し、読み出したシーケンス番号と前回の返答メッセージのシーケンス番号とを比較し、これらのシーケンス番号が一致するか否かを判定する。これらのシーケンス番号が同じ場合、マネージャ１０は、サーバ３０に不具合が発生したことによりエージェント２０の動作に影響が出たと判断し、サーバ３０が異常と判断し、アラートを登録して表示部１１を介して管理者に通知する。一方、ステップＡ５で、比較対象の２つのシーケンス番号が異なる場合、マネージャ１０は、エージェント２０によるサーバ監視が正常に行われていると判断し、返答メッセージのOpStatusの値に基づいて、サーバ３０の状態判定を行う（ステップＡ６）。OpStatusがnormal(3)であれば、マネージャ１０はサーバ３０が正常であると判定し、OpStatusがnormal(3)以外であれば、マネージャ１０は、サーバ３０の状態情報を管理者に通知する。
【００５９】
本実施例によれば、エージェントから返送される返答メッセージにキー情報を含めることで、見かけ上、正常稼働しているサーバの異常を検出できる。その理由は、返答メッセージにキー情報を埋め込むことで、マネージャは受け取った状態情報が最新の情報であるか前回の情報であるかを判定することで、エージェントから最新の状態情報が返答されない場合は、サーバに何らかの不具合が発生したことを判断できるためである。そのため、エージェントが存在するサーバの稼働状況の判定精度が向上する。
【００６０】
また、ｐｉｎｇ通信を利用することにより、次のような効果が得られる。
【００６１】
エージェントはマネージャからの要求を受けてから、サーバの状態情報を収集するため、エージェントがインストールされたサーバの負荷が高い場合や情報取得先からレスポンスが遅い場合はタイムアウトするまで待ち、全ての情報を収集してから、マネージャへＳＮＭＰメッセージを返却する。その結果、ＳＮＭＰメッセージの発行から一定時間内にレスポンスが返却されないケースがあり、この場合、マネージャはサーバがダウンしたと誤検出してしまうおそれがある。
【００６２】
これに対して、本実施例では、マネージャおよびエージェント間のやり取りにｐｉｎｇの通信を行い、返答メッセージを受け取るのが遅くタイムアウトになっても、ｐｉｎｇ通信が可能な場合は、サーバダウンとみなさず、返答メッセージを待って状態判定を行う。その理由は、エージェント側がシステム負荷により要求処理に時間がかかっている場合や収集データが多く時間がかかっている場合、マネージャ側はエージェント側の状況を認識することができないため、サーバ側に異常が発生したと誤判断してしまうが、マネージャがＳＮＭＰメッセージとは異なる通信経路で送受信されるｐｉｎｇ通信でサーバに異常がないことを確認することで、誤検出を防ぐことができるからである。そのため、エージェントが存在するサーバの稼働状況の判定精度をより向上させることが可能となる。
【００６３】
特許文献１に開示された方法では、ｐｉｎｇ通信を用いているが、タイムアウトによりＭＩＢ情報が異常と判定された場合、ｐｉｎｇ応答が正常であっても、監視装置はＭＩＢ情報の異常をオペレータ端末に通知するので、サーバがダウンしたと誤検出されるおそれがある。
【００６４】
なお、上記の実施例１では、返答メッセージの送信順序を示す順序情報として、シーケンス番号を用いたが、シーケンス番号に限らない。順序情報として、日時の情報を用いてもよい。
【００６５】
図８はServerOpStatusの別の例を示す図である。図８に示すServerOpStatusのＭＩＢ定義では、図５に示したシーケンス番号の代わりに、日時（Date&Time）の情報が定義されている。ここで、日時（Date&Time）は、予め定義しておけば、エージェント２０における、どの処理の日時であってもよい。日時（Date&Time）は、例えば、「返答メッセージの送信日時」である。
【００６６】
図９は、順序情報が送信日時の情報である場合のサーバ状態判定方法の手順を示すフローチャートである。
【００６７】
図９に示すフローチャートでは、図７に示したステップＡ５がステップＢ５に示す処理に代わっている。ステップＢ５において、マネージャ１０は、エージェント２０から返答メッセージのＳＮＭＰパケットを受信すると、返答メッセージから送信日時の情報を読み出し、読み出した送信日時と前回の返答メッセージの送信日時とを比較し、これらの送信日時が一致するか否かを判定する。これらの送信日時が一致する場合、マネージャ１０は、サーバ３０が異常であると判断する。一方、ステップＢ５で、２つの送信日時が異なる場合、マネージャ１０は、エージェント２０によるサーバ監視が正常に行われていると判断し、ステップＡ６に移行する。なお、ステップＢ５を除く処理については、図７で説明した処理と同様なため、詳細な説明を省略する。
【００６８】
このようにして、順序情報として、返答メッセージ毎に異なる情報を返答メッセージに追加することでサーバ障害検出時の分解能を向上させることが可能となる。
【００６９】
本発明を、サーバに監視用エージェントを常駐させ、管理端末のマネージャからサーバ監視を行う通信システムにおいて、エージェントおよびマネージャのそれぞれのソフトウェアプログラムに対して適用することが可能である。
【符号の説明】
【００７０】
２ マネージャ
３ 記憶部
４ 制御部
５ エージェント
６ サーバ装置
７ ネットワーク
【特許請求の範囲】
【請求項１】
監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、
前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、
前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、
を有する監視装置。
【請求項２】
請求項１記載の監視装置において、
前記制御部は、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視装置。
【請求項３】
監視対象の装置とＳＮＭＰメッセージを送受信する監視装置による監視方法であって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する、監視方法。
【請求項４】
請求項３記載の監視方法において、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、
前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視方法。
【請求項５】
監視対象の装置とＳＮＭＰメッセージを送受信するコンピュータに実行させるためのプログラムであって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。
【請求項６】
請求項５記載のプログラムにおいて、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、
前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。
【請求項７】
監視装置とＳＮＭＰメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、
状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、
前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、
前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるためのプログラム。
【請求項１】
監視対象の装置とＳＮＭＰメッセージを送受信する監視装置であって、
前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、
前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、
を有する監視装置。
【請求項２】
請求項１記載の監視装置において、
前記制御部は、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視装置。
【請求項３】
監視対象の装置とＳＮＭＰメッセージを送受信する監視装置による監視方法であって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する、監視方法。
【請求項４】
請求項３記載の監視方法において、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、
前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視方法。
【請求項５】
監視対象の装置とＳＮＭＰメッセージを送受信するコンピュータに実行させるためのプログラムであって、
前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、
前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、
読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。
【請求項６】
請求項５記載のプログラムにおいて、
前記監視対象の装置とｐｉｎｇ通信を行うために、前記要求メッセージとともにｐｉｎｇリクエストを該監視対象の装置に送信し、
前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ｐｉｎｇ通信が正常であるか否かを判定し、該ｐｉｎｇ通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。
【請求項７】
監視装置とＳＮＭＰメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、
状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、
前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、
前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１７４０２２（Ｐ２０１２−１７４０２２Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３５８３３（Ｐ２０１１−３５８３３）
【出願日】平成２３年２月２２日（２０１１．２．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月２２日（２０１１．２．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]