監視対象の装置とSNMPメッセージを送受信する監視装置であって、前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、を有する監視装置。請求項1記載の監視装置において、前記制御部は、前記監視対象の装置とping通信を行うために、前記要求メッセージとともにpingリクエストを該監視対象の装置に送信し、前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ping通信が正常であるか否かを判定し、該ping通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視装置。監視対象の装置とSNMPメッセージを送受信する監視装置による監視方法であって、前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する、監視方法。請求項3記載の監視方法において、前記監視対象の装置とping通信を行うために、前記要求メッセージとともにpingリクエストを該監視対象の装置に送信し、前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ping通信が正常であるか否かを判定し、該ping通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する、監視方法。監視対象の装置とSNMPメッセージを送受信するコンピュータに実行させるためのプログラムであって、前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。請求項5記載のプログラムにおいて、前記監視対象の装置とping通信を行うために、前記要求メッセージとともにpingリクエストを該監視対象の装置に送信し、前記要求メッセージを送信してから前記返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、前記ping通信が正常であるか否かを判定し、該ping通信が正常であると、前記返答メッセージの受信を待って前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるためのプログラム。監視装置とSNMPメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるためのプログラム。監視対象の装置にハードウェアの故障やWindows登録商標のOSOperatingSystemパニックのような障害が発生した場合、エージェントは、監視対象の装置に障害が発生したことを検知することが可能である。しかし、Linux系OSのように、パニック発生後も継続して動作可能なOSの場合や、監視対象の装置に異常が発生してもOSがメモリ上で継続して動作可能な場合、エージェントが取得した状態情報が正常であることを示すままで異常に更新されず、その結果、監視装置が異常を検出できず、監視対象の装置が正常に稼働していると誤って判断されるケースがある。また、pingではICMPInternetControlMessageProtocolにしたがって通信が行われるため、pingを用いた状態判定では、OSレベルでの障害が発生しても、通信が正常に行われてしまい、装置の異常を検出できない可能性がある。特許文献1に開示された方法では、ping応答およびMIB情報のいずれもが正常な場合、監視装置はオペレータ端末に何も通知しないため、OSレベルにおける異常を検出できないという問題がある。本発明は上述したような技術が有する問題点を解決するためになされたものであり、監視対象の装置が異常であるか否かの状態判定の精度を向上させた監視装置、監視方法、およびコンピュータに実行させるためのプログラムを提供することを目的とする。上記目的を達成するための本発明の監視装置は、監視対象の装置とSNMPメッセージを送受信する監視装置であって、前記監視対象の装置に対して状態情報を要求する旨の要求メッセージの返答として、該監視対象の装置から受信する返答メッセージに書き込まれ、該返答メッセージの送信順序を示す情報である順序情報のうち、前記監視対象の装置から最後に受信した返答メッセージの順序情報を記憶する記憶部と、前記監視対象の装置に前記要求メッセージを定期的に送信し、該監視対象の装置から前記返答メッセージを受信すると、該返答メッセージから読み出した順序情報と前記記憶部に最後に記憶させた順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する制御部と、を有する構成である。また、本発明の監視方法は、監視対象の装置とSNMPメッセージを送受信する監視装置による監視方法であって、前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定するものである。また、本発明のプログラムは、監視対象の装置とSNMPメッセージを送受信するコンピュータに実行させるためのプログラムであって、前記監視対象の装置に状態情報を要求する旨の要求メッセージを定期的に送信し、前記要求メッセージの返答として、前記監視対象の装置から返答メッセージを受信すると、該返答メッセージから返答メッセージの送信順序を示す情報である順序情報を読み出し、読み出した順序情報と前回受信した返答メッセージの順序情報とを比較し、これらの順序情報が一致している場合、前記監視対象の装置が異常であると判定し、これらの順序情報が異なる場合、受信した返答メッセージに含まれる状態情報に基づいて前記監視対象の装置の状態を判定する処理を前記コンピュータに実行させるものである。さらに、本発明のプログラムは、監視装置とSNMPメッセージを送受信する、監視対象のコンピュータに実行させるためのプログラムであって、状態情報を要求する旨の要求メッセージを前記監視装置から受信すると、自装置の状態に関する状態情報を取得し、前記状態情報を返答メッセージに書き込み、返答メッセージの送信順序を示す情報である順序情報を該返答メッセージに書き込み、前記状態情報および前記順序情報を書き込んだ返答メッセージを前記監視装置に送信する処理を前記コンピュータに実行させるものである。本発明によれば、監視対象の装置が監視装置へSNMPメッセージを返信し、見かけ上正常でも、監視対象の装置に発生した不具合を検出することができ、監視対象の装置の状態判定の精度を向上させることができる。本実施形態の監視装置の構成を説明する。本実施形態の監視装置は、サーバ装置やパーソナルコンピュータなどの情報処理装置である。監視対象の装置は、ルータおよびゲートウェイなどのネットワーク機器であってもよく、サーバ装置であってもよい。本実施形態では、監視対象の装置がサーバ装置の場合で説明する。本実施形態の監視装置は、監視対象の装置とSNMPメッセージをやり取りすることで、監視対象の装置の状態を判定する。監視装置をマネージャと称し、監視対象のサーバ装置に設けられ、サーバ装置の状態を監視するための機能部をエージェントと称する。図1は本実施形態の監視装置を含む通信システムの一構成例を示すブロック図である。図1に示すように、本実施形態の監視装置に相当するマネージャ2と、監視対象のサーバ装置6とがネットワーク7を介して接続されている。サーバ装置6には、マネージャ2とSNMPメッセージを送受信するエージェント5が設けられている。エージェント5は、サーバ装置6内でプログラムがCPUCentralProcessingUnitで実行されることで仮想的に構成される。なお、本実施形態に限らず、後述の実施例および実施形態では、説明を簡単にするために、エージェント5が1つの場合で説明するが、マネージャ2が複数のエージェント5と順にSNMPメッセージをやり取りすることで、複数のサーバ装置6の状態を監視してもよい。エージェント5は、状態情報を要求する旨の要求メッセージをマネージャ2から受信すると、サーバ装置6の現在の状態に関する状態情報を取得し、取得した状態情報と、返答メッセージの送信順序を示す情報である順序情報とを返答メッセージに書き込んでマネージャ2に送信する。エージェント5は、送信した返答メッセージをメモリ不図示に一定期間保存し、次の返答メッセージを作成する際に、保存した返答メッセージの順序情報を参照する。順序情報として、例えば、シーケンス番号がある。状態情報には、例えば、正常、異常、警告、不明などがある。マネージャ2は、記憶部3および制御部4を有する。制御部4には、プログラムにしたがって処理を実行するCPU不図示と、プログラムを格納するためのメモリ不図示とが設けられている。CPUがプログラムを実行することで、制御部4がマネージャ2に仮想的に構成される。記憶部3は、サーバ装置6から受信する返答メッセージに書き込まれた順序情報のうち、サーバ装置6から最後に受信した返答メッセージの順序情報を記憶する。制御部4は、要求メッセージをサーバ装置6に定期的に送信し、サーバ装置6から返答メッセージを受信すると、返答メッセージから読み出した順序情報と記憶部3に最後に記憶させた順序情報とを比較する。そして、これらの順序情報が一致している場合、制御部4は、サーバ装置6が異常であると判定し、これらの順序情報が異なる場合、制御部4は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置6の状態を判定する。次に、本実施形態の監視装置が実行する監視方法を説明する。図2は本実施形態の監視装置が実行する監視方法の手順を示すフローチャートである。マネージャ2がサーバ装置6に要求メッセージを送信しステップ101、エージェント5から返答メッセージを受信すると、受信した返答メッセージから順序情報を読み出すステップ102。続いて、マネージャ2は、読み出した順序情報と最後に記憶部3に記憶させた順序情報とを比較し、これらの順序情報が一致するか否かを判定するステップ103。ここで、サーバ装置6にOSレベルの障害が発生している場合、エージェント5は新たな返答メッセージを作成できないが、通信は正常なため、最後に送信したものと同じ返答メッセージをマネージャ2に送信することになる。その反対に、サーバ装置6に何も障害が発生していない場合、エージェント5は、最後に送信した返答メッセージの次の返答メッセージを示す順序情報を、返答メッセージに書き込んでマネージャ2に送信する。ステップ103において、読み出した順序情報と最後に記憶部3に記憶させた順序情報とが一致する場合、マネージャ2はサーバ装置6が異常であると判定するステップ104。一方、ステップ103において、読み出した順序情報と最後に記憶部3に記憶させた順序情報とが異なる場合、マネージャ2は、受信した返答メッセージに含まれる状態情報に基づいてサーバ装置の状態を判定するステップ105。ステップ105の後、マネージャ2は、記憶部3に記憶させた順序情報を、最新の返答メッセージに書き込まれた順序情報に更新するステップ106。なお、マネージャ2は、サーバ装置6が正常でないと判定した場合、状態情報を文字メッセージにして表示部不図示に表示してもよく、状態情報を音声メッセージにしてスピーカ不図示から出力してもよく、サーバ装置6が正常でないことを管理者に通知する方法については限定されない。本実施形態では、エージェントはサーバの現在の状態を示す状態情報を返信する際、順序情報をキー情報として返答メッセージに埋め込み、マネージャは前回取得した返答メッセージのキー情報と比較し、キー情報が前回と同じ値であった場合、サーバに不具合が発生したと判定する。これにより、サーバに不具合が起きても、OSが継続的に稼働し続け、見かけ上サーバが正常で、返答される状態情報が正常値のままで更新されず、その結果、装置異常を検出できないような状況を回避することが可能となる。そのため、サーバの稼働状況の判定精度が向上する。さらに、監視対象の装置がサーバである場合、サーバに実装されるメモリの大容量化も進んでおり、今後はメモリ上のみでOSや各ソフトウェアが動作し続けるケースが多く発生すると推測される。本実施形態の監視方法では、見かけ上正常なサーバに不具合が発生していることを検出することが可能となる。以下に、本実施形態の実施例を説明する。本実施例においても、監視対象をサーバ装置とし、エージェントがサーバ装置に含まれるものとし、監視装置をマネージャと称する。また、本実施例では、サーバ装置の状態判定の精度向上を目的として、マネージャとサーバ装置とのやり取りにpingの通信処理を追加した場合を説明する。また、本実施例では、順序情報がシーケンス番号の場合である。SNMPメッセージのパケットをSNMPパケットと称する。図3は本実施例の監視装置を含む通信システムの一構成例を示すブロック図である。図3に示すように、通信システムは、状態情報の要求を行うマネージャ10と、リクエストに対して結果を返すエージェント20を含むサーバ30とを有する。サーバ30が監視対象の装置に相当する。マネージャ10およびサーバ30の間には通信可能なネットワーク環境が構築されている。マネージャ10は、表示部11と、記憶部16と、データ収集部17と、パケット処理部12と、SNMPパケットを作成するパケット作成部15と、通信部18とを有する。通信部18は、SNMPパケットの送信およびpingの送信を行うリクエスト送信部14と、SNMPパケットの受信およびpingの受信を行うレスポンス受信部13とを有する。サーバ30は、エージェント20およびping送受信部25を有する。エージェント20は、SNMPレスポンス送信部21およびSNMPリクエスト受信部22を含む通信部26と、パケット作成部23と、要求処理部24とを有する。図3に示した、マネージャ10について詳しく説明する。データ収集部17は、メモリ不図示に登録されたエージェント20のステータス情報取得のためにポーリングで、要求メッセージGetRequestをエージェント20に発行し、pingコマンドの1つとしてpingリクエストをサーバ装置30のping送受信部25に発行する指示をパケット作成部15に通知する。データ収集部17はパケット処理部12から受け取る状態情報とシーケンス番号を記憶部16に格納する。サーバ30に不具合が発生している場合には、データ収集部17はアラートを記憶部16に登録する。パケット作成部15は、データ収集部17から要求メッセージおよびpingリクエストの発行の指示を受けると、要求メッセージおよびpingリクエストを作成してリクエスト送信部14に渡す。リクエスト送信部14は、要求メッセージをエージェント20宛にネットワークを介して送信し、pingリクエストをサーバ30宛にネットワークを介して送信する。レスポンス受信部13は、エージェント20から受信する返答メッセージをパケット処理部12に渡し、サーバ30から受信するpingリプライをパケット処理部12に渡す。パケット処理部12は、pingリクエストおよびpingリプライによるping通信の結果と返答メッセージのデータを解析して、サーバ装置30の状態を判定する。具体的には、パケット処理部12は、今回受け取った返答メッセージと前回の返答メッセージのそれぞれのシーケンス番号を比較し、これらのシーケンス番号が一致している場合、サーバ30が異常であると判定し、これらのシーケンス番号が一致していない場合、返答メッセージに含まれる状態情報でサーバ30の状態を判定する。また、要求メッセージを送信してから返答メッセージを受信するまでの時間が予め設定された閾値を越える場合、パケット処理部12は、タイムアウトと判断し、ping通信の結果を参照する。ping通信の結果が、pingリプライを受信していないものであったり、pingリクエスト送信からpingリプライの受信までの時間が基準値よりオーバーしていたりする場合、パケット処理部12は、サーバ30が異常であると判定するが、ping通信の結果が正常である場合、タイムアウト後に受信する返答メッセージに対して上述の処理を行う。このようにして、本実施例のマネージャ10はpingの通信結果と返答メッセージの状態情報とを合わせてサーバ30の状態判定を行う。SNMPメッセージだけでなく、pingの通信結果を用いて状態判定を行うことで、エージェント側のシステム負荷が高い場合や、採取するデータが多く、エージェントの情報収集に時間がかかり、返答メッセージが遅れている場合でも、pingによる通信が可能な場合はサーバダウンとみなさずに、正常稼働と判断することが可能となる。パケット処理部12は、返答メッセージから読み出した状態情報とシーケンス番号をデータ収集部17に渡す。パケット処理部12は、サーバ30が正常でないと判定した場合、状態情報から正常でないことを認識できれば、状態情報を文字メッセージにして表示部11に表示し、状態情報から正常でないことを認識できれば、サーバ30が異常である旨のメッセージを表示部11に表示させる。これにより、サーバ30が正常でないことが管理者に通知される。次に、サーバ30側の構成について説明する。エージェント20のSNMPリクエスト受信部22は、マネージャ10からネットワークを介して要求メッセージを受信すると、要求メッセージを要求処理部24に渡す。SNMPレスポンス送信部21は、パケット作成部23から返答メッセージを受け取ると、ネットワークを介してマネージャ10に返答メッセージを送信する。エージェント20の要求処理部24は、SNMPリクエスト受信部22から要求メッセージを受け取ると、サーバ30の状態情報を取得し、取得した状態情報をパケット作成部23に渡す。パケット作成部23は、要求処理部24から渡された状態情報のデータとキー情報となるシーケンス番号を書き込んだ返答メッセージを作成してSNMPレスポンス送信部21に渡す。サーバ30のping送受信部25は、マネージャ10からpingリクエストを受信すると、マネージャ10宛にpingリプライを送信する。このとき、pingリクエストおよびpingリプライは、SNMPの要求メッセージおよび返答メッセージとは、異なる通信経路で伝送される場合がある。ここで、エージェント20からマネージャ10に送信される返答メッセージの構成について説明する。図4から図6はMIB定義ファイルの一例である。図4は返答メッセージの一構成例であり、MIB定義によるOpStatusServerを示す図である。図4に示すSYNTAXServerOpStatusに、指定されたオブジェクトの状態情報が書き込まれる。図5は、図4に示したSYNTAXServerOpStatusに相当し、MIB定義によるServerOpStatusを示す図である。図5に示すように、本実施例のServerOpStatusには、状態情報が書き込まれるOpStatusの他に、シーケンス番号sequentialnumberも定義されている。図6は、図5に示したOpStatusの欄に書き込まれる情報に相当し、MIB定義によるOpStatusを示す図である。パケット作成部23は、要求処理部24から装置の状態情報を受け取ると、状態情報に対応して図6に示したother~fatalからいずれか1つを選択し、選択した状態情報とシーケンス番号を図5の定義にしたがって、図4に示す返答メッセージの構成に書き込む。これらの定義にしたがって、マネージャ10は、返答メッセージのSYNTAXServerOpStatusからシーケンス番号と状態情報を読み出す。次に、本実施例のマネージャ10が実行するサーバ状態判定方法を説明する。図7は本実施例のサーバ状態判定方法の手順を示すフローチャートである。マネージャ10は、リクエスト送信部14からサーバ30宛のpingリクエストを発行しステップA1、続いて、エージェント20に対して要求メッセージのSNMPパケットを送信するステップA2。マネージャ10は、ステップA2で送信したSNMPパケットに対するレスポンスを待つ。pingリクエストおよびSNMPパケットはネットワークを介してサーバ30に送信される。SNMPパケットはSNMPリクエスト受信部22で受信され、pingリクエストはping送受信部25で受信される。なお、ステップA1およびステップA2の処理は、いずれが先でも、同時でもよい。ping送受信部25はpingリクエストを受信すると、pingリクエストをpingリプライとしてレスポンス受信部13に返信する。SNMPリクエスト受信部22で受信されたSNMPパケットは、処理待ちキューリストに一旦格納された後、順番に要求処理部24で処理され、パケット作成部23に渡される。パケット作成部23は、状態情報およびシーケンス番号を書き込んだ返答メッセージのSNMPパケットを作成してSNMPレスポンス送信部21に渡す。返答メッセージのSNMPパケットは、レスポンス送信部21からマネージャ10に送信され、レスポンス受信部13で受信される。一方、サーバ30に不具合が発生し、エージェント20の要求処理部24の動作に影響を及ぼすと、パケット作成部23は、新たな状態情報を要求処理部24から受け取れず、前回作成した返答メッセージをそのままマネージャ10に送信する。マネージャ10は、所定の時間までにエージェント20からSNMPパケットを受信した場合、ステップA5の処理に移行し、SNMPパケットを受信しなかった場合、ステップA4の処理に移行する。ステップA4では、マネージャ10は、エージェント20が存在するサーバ30とのping通信の判定を行い、pingリプライを受信するまでの時間が基準値を越えてタイムアウトした場合、サーバ30が異常と判断する。ステップA4で、pingリプライを基準以内に受信し、pingによる通信が正常である場合、マネージャ10は、エージェント20側のSNMPパケット処理に時間がかかっている判断し、ステップA3へ戻る。ステップA5では、マネージャ10は、エージェント20から返答メッセージのSNMPパケットを受信すると、返答メッセージからシーケンス番号を読み出し、読み出したシーケンス番号と前回の返答メッセージのシーケンス番号とを比較し、これらのシーケンス番号が一致するか否かを判定する。これらのシーケンス番号が同じ場合、マネージャ10は、サーバ30に不具合が発生したことによりエージェント20の動作に影響が出たと判断し、サーバ30が異常と判断し、アラートを登録して表示部11を介して管理者に通知する。一方、ステップA5で、比較対象の2つのシーケンス番号が異なる場合、マネージャ10は、エージェント20によるサーバ監視が正常に行われていると判断し、返答メッセージのOpStatusの値に基づいて、サーバ30の状態判定を行うステップA6。OpStatusがnormalであれば、マネージャ10はサーバ30が正常であると判定し、OpStatusがnormal以外であれば、マネージャ10は、サーバ30の状態情報を管理者に通知する。本実施例によれば、エージェントから返送される返答メッセージにキー情報を含めることで、見かけ上、正常稼働しているサーバの異常を検出できる。その理由は、返答メッセージにキー情報を埋め込むことで、マネージャは受け取った状態情報が最新の情報であるか前回の情報であるかを判定することで、エージェントから最新の状態情報が返答されない場合は、サーバに何らかの不具合が発生したことを判断できるためである。そのため、エージェントが存在するサーバの稼働状況の判定精度が向上する。また、ping通信を利用することにより、次のような効果が得られる。エージェントはマネージャからの要求を受けてから、サーバの状態情報を収集するため、エージェントがインストールされたサーバの負荷が高い場合や情報取得先からレスポンスが遅い場合はタイムアウトするまで待ち、全ての情報を収集してから、マネージャへSNMPメッセージを返却する。その結果、SNMPメッセージの発行から一定時間内にレスポンスが返却されないケースがあり、この場合、マネージャはサーバがダウンしたと誤検出してしまうおそれがある。これに対して、本実施例では、マネージャおよびエージェント間のやり取りにpingの通信を行い、返答メッセージを受け取るのが遅くタイムアウトになっても、ping通信が可能な場合は、サーバダウンとみなさず、返答メッセージを待って状態判定を行う。その理由は、エージェント側がシステム負荷により要求処理に時間がかかっている場合や収集データが多く時間がかかっている場合、マネージャ側はエージェント側の状況を認識することができないため、サーバ側に異常が発生したと誤判断してしまうが、マネージャがSNMPメッセージとは異なる通信経路で送受信されるping通信でサーバに異常がないことを確認することで、誤検出を防ぐことができるからである。そのため、エージェントが存在するサーバの稼働状況の判定精度をより向上させることが可能となる。特許文献1に開示された方法では、ping通信を用いているが、タイムアウトによりMIB情報が異常と判定された場合、ping応答が正常であっても、監視装置はMIB情報の異常をオペレータ端末に通知するので、サーバがダウンしたと誤検出されるおそれがある。なお、上記の実施例1では、返答メッセージの送信順序を示す順序情報として、シーケンス番号を用いたが、シーケンス番号に限らない。順序情報として、日時の情報を用いてもよい。図8はServerOpStatusの別の例を示す図である。図8に示すServerOpStatusのMIB定義では、図5に示したシーケンス番号の代わりに、日時DateTimeの情報が定義されている。ここで、日時DateTimeは、予め定義しておけば、エージェント20における、どの処理の日時であってもよい。日時DateTimeは、例えば、返答メッセージの送信日時である。図9は、順序情報が送信日時の情報である場合のサーバ状態判定方法の手順を示すフローチャートである。図9に示すフローチャートでは、図7に示したステップA5がステップB5に示す処理に代わっている。ステップB5において、マネージャ10は、エージェント20から返答メッセージのSNMPパケットを受信すると、返答メッセージから送信日時の情報を読み出し、読み出した送信日時と前回の返答メッセージの送信日時とを比較し、これらの送信日時が一致するか否かを判定する。これらの送信日時が一致する場合、マネージャ10は、サーバ30が異常であると判断する。一方、ステップB5で、2つの送信日時が異なる場合、マネージャ10は、エージェント20によるサーバ監視が正常に行われていると判断し、ステップA6に移行する。なお、ステップB5を除く処理については、図7で説明した処理と同様なため、詳細な説明を省略する。このようにして、順序情報として、返答メッセージ毎に異なる情報を返答メッセージに追加することでサーバ障害検出時の分解能を向上させることが可能となる。本発明を、サーバに監視用エージェントを常駐させ、管理端末のマネージャからサーバ監視を行う通信システムにおいて、エージェントおよびマネージャのそれぞれのソフトウェアプログラムに対して適用することが可能である。