(57)【要約】【課題】監視システムでの監視条件情報および監視結果情報の送受において、再送によるネットワークの負荷を分散させ、かつ、より細かな間隔で送受されるべき情報を優先的に送信する。【解決手段】監視システムを構成するサーバは、情報を送信する送信すべき時を制御する手段を備え、情報の送信に失敗した場合に、あらかじめ決められた待機時間の間、情報の送信を停止し、待機時間経過後の最初の送信すべき時に、情報を送信する。【選択図】  図１
2005038070.tif 000002
【特許請求の範囲】
【請求項１】
監視対象サーバとなる、ネットワークを介してサービスを提供するサーバから性能情報を収集する１つ以上の計測サーバと、収集された前記性能情報を前記計測サーバから集める１つ以上の監視サーバと、から構成される監視システムにおいて、
前記計測サーバは、
監視条件に基づいて計測の実行を制御し、収集した前記性能情報の送信を一定の間隔で繰り返し試みる計測制御部と、
前記計測制御部の指示に従って、性能情報を取得し、前記計測制御部に通知する計測実行部とを備え、
前記計測制御部は、前記監視サーバへの前記性能情報の送信に失敗した場合に、上記一定の間隔が経過後の送信すべき時に到達しても、あらかじめ決められた待機時間の間であれば、収集した性能情報の送信を行わず、
前記待機時間経過後に最初に到達した、前記一定の間隔経過後の送信すべき時に、前記性能情報を監視サーバへ送信する。
【請求項２】
前記性能情報の送信を停止している前記待機時間の間であっても、前記計測実行部から送信される前記収集された性能情報を受け付け、
前記待機時間経過後に最初に到達した、前記一定の間隔経過後の送信すべき時に、未だ前記監視サーバへ送信していない前記性能情報を送信する。
【請求項３】
請求項１記載の監視システムにおいて、
前記計測サーバは、前記監視サーバから監視条件を取得し、
前記計測制御手段は、取得した前記監視条件に基づいた計測の実行を制御する。
【請求項４】
請求項１記載の監視システムにおいて、
前記計測制御手段は、前記計測実行手段が計測を行い、性能情報を取得した時を送信すべき時として、前記送信手段に、前記監視サーバへの前記性能情報の送信を指示する。
【請求項５】
請求項１記載の監視システムにおいて、
前記計測サーバは、前記監視条件の一部を取得する監視条件取得手段を備え、
前記計測制御手段は、前記監視サーバから取得した監視条件と、前記監視条件取得手段が取得した監視条件の一部とをからなる情報を、前記計測実行手段に渡し、
前記計測実行手段は当該情報に基づいて、計測を実行する。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークによって接続される複数のコンピュータやネットワーク機器から構成されるシステムを対象とした性能監視システムに関する。
【０００２】
【従来の技術】
インターネットサービスが、企業の業務システム等の信頼性を必要とする用途に利用されるようになり、性能の監視に対する要求が高まっている。この要求に対して、サービスの応答性能や、サーバ装置のメモリ使用率などの性能情報を収集する監視システムがある。監視システムを用いることにより、サービスの応答性能を２４時間３６５日体制で監視でき、性能低下を早期発見し対策を行うことができる。
【０００３】
一般的に、監視システムは、監視対象システムの性能情報を取得する計測サーバと、計測サーバが取得した性能情報を収集する監視サーバ装置（以下、監視サーバという）とに分かれる。監視システムを利用するシステム管理者は、監視サーバに対して監視対象を指定する監視対象情報を登録し、監視サーバは監視対象情報を受け取り、計測サーバに渡す。計測サーバは、監視対象情報に基づいて計測を行い、結果を監視サーバに送信する。監視サーバは複数の計測サーバから取得した性能情報をファイルに出力したり、画面表示したりすることで、システム管理者に性能情報を提供する。
【０００４】
このような構成にすることで、複数の計測サーバが収集した性能情報を一元的に管理したり、遠隔地に設置した計測サーバが収集した性能情報を参照したりすることができる。特に、計測サーバがサービスの応答時間を計測する場合には、計測サーバはサービスの利用者の環境、またはそれに近い環境に置くことで、実際に利用者が体感する応答時間に近い値を取得することができるため、計測サーバは監視対象に応じた場所に配置されることが多い。
【０００５】
監視システムでは、監視条件と監視結果をネットワーク経由でやりとりするため、ネットワーク障害発生時には、監視条件の送受、および監視結果の送受が不能になる。この場合、従来の監視システムでは、計測サーバが送信できなかった監視結果を保持し、あらかじめ決められた待機時間が経過した後に再接続を試みる。再接続に失敗した場合には、再度待機時間の経過を待ち、同様の処理を繰り返す。そして、再接続が成功すると保持していた監視結果を送信する。
【０００６】
上記のように、待機時間を設けて一定の間隔を置いて再接続の要求を発行することで、要求が過剰に発行されることを防ぐことができる。しかし、計測サーバが複数存在する場合には、複数の計測サーバが同時に保持していた監視結果を送信するため、ネットワークおよび監視サーバの負荷が問題になる。このような障害回復時の問題を解決するために、たとえば、特許文献１に記載のように、リトライの間隔を乱数によって決定することで、複数の計測サーバが同時に再接続に成功しないようにする方法がある。
【０００７】
【特許文献１】
特開平１０−７９７５３号公報
【０００８】
【発明が解決しようとする課題】
上記技術は、監視サーバに負荷をかけることなく、再接続を行い、ネットワーク障害中に得られた計測結果を監視サーバに送信することを可能とするが、次のような課題を持つ。
【０００９】
計測サーバは、システム管理者が指定した計測間隔で計測を行っている。計測間隔が短い場合には、より頻繁に計測を行う。
【００１０】
すなわち、計測間隔に関わらず乱数によって待機時間が決定されるため、細かな計測間隔で計測を行っている計測サーバに与えられる待機時間が、より大きい計測間隔で計測を行っている計測サーバに与えられる待機時間よりも大きくなることがある。この場合には、より大きい計測間隔で計測を行っている計測サーバの監視結果が先に監視サーバへ送信される確率が高い。
【００１１】
細かな計測間隔で監視を行う場合は、計測結果をより早く監視サーバへ届ける必要があるが、乱数によって待機時間を決定すると、監視結果は計測間隔に関係なく監視サーバへ送られる。このため、より早く監視サーバに届けるべき監視結果が後まわしになり、正確な監視ができなくなる。たとえば、１分ごとに計測を行うリアルタイム監視の計測結果が１０分後に送られ、３時間に１回行われる監視の計測結果が５分後に送られることが起こりうるので、こうなると１０分間の間、上記リアルタイム監視ができなくなる。
【００１２】
したがって、行われた計測結果は、できるだけ早く監視サーバへ送信される必要がある。
【００１３】
【課題を解決するための手段】
本発明による監視システムは、  上記監視システムは、インターネットサービスを提供するサーバから、応答時間やＣＰＵ利用率などの性能情報を収集する１つ以上の計測サーバと、上記性能情報を計測サーバから集める監視サーバとから構成され、
上記監視サーバは、監視対象となるサーバや性能情報を取得する間隔を示す監視条件を取得する監視条件登録手段と、上記監視条件および監視結果を保持する情報記録手段と、上記計測サーバに上記監視条件を送信し、応答時間やＣＰＵ利用率などの性能情報を受信する通信手段と、ユーザに監視結果を提供する監視結果表示手段とを備え、
上記計測サーバは、上記監視サーバから上記監視条件を取得し、上記性能情報を送信する通信手段と、計測を実行すべき時の決定および上記性能情報の送信待機を制御する計測制御手段と、監視対象情報に基づいて実際に性能情報を取得する計測実行手段と、上記計測制御手段と計測実行手段との上記監視条件および上記監視結果のやり取りを実現する内部通信手段とを備える。
【００１４】
これにより、計測間隔に応じたリトライ送信を行うことが可能になる。
【００１５】
【発明の実施の形態】
図１は本発明の一実施例の機能構成図である。本実施例の機能構成は、１つの監視サーバ装置（以下、監視サーバという）（１１０）、１つの監視クライアント装置（以下、監視クライアントという）（１００）、１つ以上の計測サーバ装置（以下、計測サーバという）（１２０）、１つ以上の監視対象サーバ装置（以下、監視対象サーバという）（１３０）から成る。監視サーバ（１１０）および、監視クライアント（１００）および、計測サーバ（１２０）は、ＩＰネットワーク（１４１，１４２）により接続されている。さらに、計測サーバ（１２０）は、監視対象サーバ（１３０）とＩＰネットワーク（１４３）により接続されている。
【００１６】
監視クライアント（１００）は、コンピュータ上でソフトウェアプログラムが動作することにより実現されるものであり、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）と、ユーザが監視対象サーバや監視間隔を示す監視条件を入力する監視条件設定部（１０１）と、ユーザが監視結果を参照する監視結果表示部（１０２）と、を実現する。図８に監視条件設定部（１０１）のＧＵＩである監視条件登録画面（７００）、監視結果表示部（１０２）のＧＵＩである監視結果表示画面（７２０）を示す。
【００１７】
監視サーバ（１１０）は、コンピュータ上でソフトウェアプログラムが動作することにより実現されるものであり、監視条件を取得する監視条件登録部（１１１）と、監視条件を、性能情報を計測する計測サーバに送信し、計測サーバから計測結果を取得する通信部（１１２）と、監視条件（３００）と、当該監視システムを構成する計測サーバの情報である計測サーバ情報（３２０）と、計測結果（４００）とを保持するデータベース（１１４）と、計測サーバ情報を格納した構成定義ファイル（１１５）と、監視クライアントからの要求に応じてデータベースから監視結果を取得し、監視クライアントに渡す監視結果検索部（１１３）と、を実現する。
【００１８】
計測サーバ（１２０）は、コンピュータ上でソフトウェアプログラムが動作することにより実現されるものであり、監視サーバから監視条件を受信し、受信した監視条件に基づいて計測を実行し得られる性能情報を、監視サーバに送信する通信部（１２１）と、監視条件に基づいた計測の実行を制御する計測制御部（１２２）と、実際に監視対象サーバにアクセスして、性能情報を得る計測実行部（１２４）と、計測制御部と計測実行部との通信を制御する内部通信部（１２３）と監視条件を保持するデータベース（１２５）と、監視条件の一部であるパスワードを取得してデータベースに格納するパスワードユーティリティ（１２６）と、から成る。なお、計測制御部（１２２）は、監視条件に基づいて、一定の間隔おきに性能情報を取得するよう、計測実行部が行う計測処理の実行時刻を決定する。計測実行部（１２４）は、ＷｅｂサーバにＨＴＴＰリクエストを出して、レスポンスを得るまでの応答時間を求めたりする機能を持つ。パスワードユーティリティ（１２６）は、インターネットサービスの種類を表すサービス名と、サーバ名やＵＲＬである監視対象と、監視対象にアクセスするユーザ名と、ユーザ名に対応するパスワードとからなるアカウント情報を、標準入力から受け取り、データベース（１２５）に登録する。なお、監視対象サーバ（１３０）は、メールサーバやＷｅｂサーバなどのインターネットサービスを提供するサーバ装置である。
【００１９】
図２は、本実施形態のシステム構成図である。本実施例のシステムは、監視クライアント（１００）と、監視サーバ（１１０）と、計測サーバ（１２０）に相当する３台の計測サーバ１（２２１）、計測サーバ２（２２２）、計測サーバ３（２２３）と、計測対象サーバ（１３０）に相当する３台の監視対象サーバ（２１１，２１２，２１３）とから構成される。
【００２０】
監視クライアント（１００）と、監視サーバ（１１０）と、監視対象サーバ群（２１１，２１２，２１３）はデータセンタ（２００）に設置されている。一方、計測サーバ群（２２１，２２２，２２３）はユーザサイトからの監視対象サーバ群（２１１，２１２，２１３）に対する応答性能を測るため、それぞれユーザサイト（２０１，２０２，２０３）に一つ設置されている。データセンタ（２００）とユーザサイト（２０１，２０２，２０３）は、ＩＰネットワーク（２１０）によって接続されている。
【００２１】
監視クライアント（１００）と、監視サーバ（１１０）は、同一の装置として実現されても良いし、それぞれネットワークによって接続された別の装置として実現されても良い。本実施例では、監視クライアント（１００）と、監視サーバ（１１０）は同一の装置として実現するものとする。
【００２２】
上記各サーバ装置とクライアント装置は、少なくともＣＰＵとメモリを備えたコンピュータにおいて、各処理部が行う処理を記述したプログラムをＣＰＵが実行し、フローチャートに沿って、以下に説明する処理を行うことにより実現される。また、各プログラムは、予め各装置のメモリに格納されていても良いし、必要に応じて、当該装置が利用可能な、着脱可能な記憶媒体や通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を介して、他の装置から導入されても良い。
【００２３】
図３は本実施形態において、監視サーバ上のデータベース（１１４）に格納される監視条件リスト（３００）および計測サーバリスト（３２０）を示す図である。
【００２４】
監視条件リスト（３００）は、複数の監視条件（３０１，３０２，３０３）から成る。監視条件（３０１，３０２，３０３）は、取得すべき性能情報の取得方法を示すものであり、一意な識別子であるターゲットＩＤ（３０４）と、監視対象サーバのＵＲＬ（３０５）、性能情報の取得間隔（３０６）、性能情報取得処理の計測タイムアウト（３０７）、アカウント認証が必要な場合に利用するユーザ名（３０８）、アカウント認証が必要な場合に利用するパスワード（３０９）、計測サーバ上のデータベース（１２５）内に存在するアカウントリスト（６００）を使用するかを判断するユーティリティフラグ（３１０）、性能情報を取得する計測サーバの識別子である計測サーバＩＤ（３１１）から成る。なお、性能情報取得間隔（３０６）の値の単位、および性能情報取得処理の計測タイムアウト（３０７）の値の単位は秒である。また、ユーティリティフラグは、アカウント認証が必要ないときには「Ｎｏｎｅ」、アカウント認証が必要であるが、計測サーバ上に存在するアカウントリスト（６００）を使用しないときは、「Ｆａｌｓｅ」、アカウントリスト（６００）を使用するときは「Ｔｒｕｅ」と設定される。
【００２５】
例えば、監視条件１（３０１）はターゲットＩＤが「１」であり、性能情報としてＵＲＬが「ｗｗｗ．ｈｉｔａｃｈｉ．ｃｏｍ」であるホームページの取得に要する時間を測る。性能情報を取得する間隔は、１分であり、性能情報取得処理のタイムアウトは１０秒である。性能情報を取得する計測サーバは、計測サーバリスト（３２０）により計測サーバＩＤが「１００１」である計測サーバ１であることを表す。また、この性能情報取得では、アカウント認証をしないことを表している。
【００２６】
計測サーバリスト（３２０）は、複数の計測サーバ情報（３２１，３２２，３２３）から成る。計測サーバ情報は、計測サーバを一意に識別する識別子である計測サーバＩＤ（３２４）と、計測サーバが動作するマシンのＩＰアドレス（３２５）から成る。
監視サーバ（１１０）は、起動時に、構成定義ファイル（１１５）を読み込み、計測サーバリスト（３２０）をデータベース（１２４）に格納する。
【００２７】
図４は本実施形態において、監視サーバ（１１０）上のデータベース（１１４）に格納される計測結果リスト（４００）を示す図である。計測結果リスト（４００）は、複数の計測結果（４０５，４０６）から成る。計測結果は、ターゲットＩＤ（４０１）と、計測時刻（４０２）と、性能情報（４０３）から成る。ターゲットＩＤ（４０１）は、当該性能情報に対応する監視条件の識別子であり、計測条件リスト（３００）内の該当する監視条件のターゲットＩＤと一致する。計測時刻（４０２）は当該性能情報を取得した時刻であり、ＵＴＣ（Ｕｎｉｖｅｒｓａｌ  Ｃｏｏｒｄｉｎａｔｅｄ  Ｔｉｍｅ）で表される。性能情報（４０３）は取得した性能情報の値である。
【００２８】
計測サーバ（１２０）から、監視サーバ（１１０）へ送信される計測結果の情報は、計測結果（４００）に格納される情報を含む。
【００２９】
図５は本実施形態において、計測制御部（１２２）が持つタスクリスト（５００）を示す図である。タスクリストは、複数のタスク（５０１，５０２）から成る。タスクは、実行すべき計測処理を示すものであり、監視条件に以下に説明する次回実行時刻を追加することで生成される。タスクは、一意な識別子であるターゲットＩＤ（５０３）と、監視対象のＵＲＬ（５０４）と、性能情報の取得間隔（５０５）と、性能情報取得処理のタイムアウト（５０６）と、アカウント認証に必要とするユーザ名（５０７）、アカウント認証に必要とするパスワード（５０８）次に当該性能情報を取得すべき時刻である次回実行時刻（５０９）から成る。
【００３０】
図６は、本実施形態において、計測サーバ（１２０）上のデータベース（１２５）に格納されるアカウントリスト（６００）を示す図である。アカウントリスト（６００）は、複数のアカウント情報（６０１，６０２）で構成される。アカウント情報は、アカウントリストから対応するパスワードを取得する検索キー（６０３）と対象となるパスワード（６０４）で構成される。この情報内の検索キーは、監視条件を基に作成されており、次のフォーマットとなる。
“サービス名”｜“監視対象”｜“ユーザ名”
本実施例では監視対象は監視条件のＵＲＬとなる。図８中の監視条件１（６０１）に対する検索キーは、サービスとして「ｈｔｔｐサービス」、監視対象としては、ＵＲＬの「ｗｗｗ．ｈｏｇｅ．ｃｏｍ」であり、ＵＲＬにアクセスするためのユーザ名が「ｈｏｇｅ」であることを示す。
【００３１】
図７は本実施形態における監視クライアントが備える監視条件登録画面（７００）、監視結果表示画面（７１０）を示す図である。
【００３２】
まず、監視条件登録画面（７００）について説明する。ユーザは、監視条件登録画面（７００）において、ターゲットＩＤをターゲットＩＤ指定テキストボックス（７０１）に、監視対象のＵＲＬをＵＲＬ指定テキストボックス（７０２）に、計測の間隔を間隔指定テキストボックス（７０３）に、性能情報収集処理の計測タイムアウト値をタイムアウト指定テキストボックス（７０４）に、当該監視対象を計測する計測サーバＩＤを計測サーバＩＤ指定テキストボックス（７０５）に指定し、登録実行ボタン（７０６）を押下することで監視条件の登録を行う。
【００３３】
監視条件の登録において、監視対象のＵＲＬでアカウント認証が必要な場合は、オプションのチェックボタン（７０７）を指定し、アカウント指定テキストボックス（７０８）にアカウントを、パスワード指定テキストボックス（７０９）にパスワードを指定する。パスワードの指定については、あらかじめパスワードユーティリティ（１２６）を用いて、データベース（１２５）のアカウントリスト（６００）にアカウント情報を登録し、パスワードユーティリティを使用するセレクションボタン（７１０）を指定すれば、計測サーバ上のアカウントリストを使ってパスワードを導き出すことを示しておりパスワードを入力する必要はない。
【００３４】
次に、監視結果表示画面（７２０）について説明する。ユーザは、監視クライアントの監視結果表示画面（７２０）において、監視対象のターゲットＩＤを、ターゲットＩＤ指定テキストボックス（７２１）に指定し、表示ボタン（７２２）を押下し、監視サーバに監視結果の表示を指示する。監視サーバ（１１０）は、データベース（１１４）から指定されたターゲットＩＤを持つ監視条件の監視結果を取得し、監視クライアント（１１０）に送信する。監視クライアント（１１０）は、監視結果を監視結果グラフエリア（７２３）に表示する。
【００３５】
例えば、当該監視結果表示画面（７１０）では、ターゲットＩＤが１であるＷｅｂサーバの応答性能がわかる。
【００３６】
図８は本実施形態における、計測サーバ（１２０）の詳細な構成を示す図である。
本実施形態では、計測サーバ（１２０）はメインスレッド（８００）と３つの計測スレッド（８０１，８０２，８０３）から成る４つのスレッドを持つ、１つのプロセスで実現される。メインスレッド（８００）は、計測制御部（１２２）、通信部（１２１）を実行し、３つの計測スレッド（８０１，８０２，８０３）ではそれぞれ計測実行部（１２４）が実行される。内部通信部（１２３）は、メインスレッドと各計測スレッドから共通に利用され、メインスレッドと各計測スレッドとの情報のやり取りを実現する。
【００３７】
内部通信部（１２３）は、１対３のパイプであり、メインスレッド（８００）から計測スレッド１（８０１）、計測スレッド２（８０２）、計測スレッド３（８０３）へタスクを送信するタスクパイプ（８１０）と、計測スレッド１、計測スレッド２、計測スレッド３からメインスレッドに計測結果を送信する監視結果パイプ（８１１）とに分かれる。メインスレッド（８００）は、タスクリスト（５００）の一つであるタスクをタスクパイプ（８１０）に書き込む。その一方で、各計測スレッドは、タスクパイプにタスクが到着するのを待っており、タスクが到着すれば、タスクを取得し、取得したタスクに基づいて計測を行う。そして、各計測スレッドは、計測して得た監視結果を監視結果パイプ（８１１）に書き込み、タスクパイプに新たなタスクが到着するのを待つ。
【００３８】
メインスレッド（８００）は、監視結果パイプ（８１１）に監視結果が到着すると、監視結果を取得し、通信部（１２１）を用いて監視サーバ（１１０）に送信する。
【００３９】
図９は本実施形態における監視サーバと計測サーバの処理シーケンスを示す図である。
【００４０】
まず、監視クライアント（１００）の監視条件設定部（１０１）は、ＧＵＩを用いて監視条件を取得し、監視サーバに通知する（９００）。監視サーバ（１１０）の監視条件登録部（１１１）は、監視クライアント（１００）から図３に示す監視条件を取得し（９０１）、データベース（１１４）に保存し、当該監視条件を計測サーバ（１２０）に送信する（９０２）。
【００４１】
例えば、監視条件２（３０２）に従い、アカウント認証が必要なＵＲＬ（ｗｗｗ．ｈｏｇｅ．ｃｏｍ）を監視対象とするならば、ユーザ名とアカウントリストを使用するという監視条件２（３０２）を、アカウントのパスワードなしで計測サーバに送信する。
【００４２】
計測サーバのメインスレッドで実行する計測制御部（１２２）は、通信部（１２１）を介して監視条件２（３０２）を受信すると、監視条件２（３０２）でパスワードユーティリティを使用するかをチェックし、使用する場合には、計測サーバ（１２０）上のデータベース（１２５）に存在するアカウントリスト（６００）を利用して、該当するパスワードを求める。例えば、監視条件２においては、監視サーバ（３００）上の監視条件リスト（３００）に存在する監視条件２（３０２）においてパスワード（３０）は記されていないが、この時点でアカウントリスト（６００）の条件１（６０１）からパスワード“８７４ｈｇｙｊｎ”が求められる。
【００４３】
このように、パスワードを、監視条件のＩＤでなく、ＵＲＬとアカウントをキーとして登録することで、複数の監視条件から参照可能にしているため、監視条件とパスワードは多対１にすることができる。
【００４４】
この後、監視条件をタスクリスト（５００）に追加すると、監視サーバに対して監視条件通知応答を行う（９０３）。その後、メインスレッド内の計測制御部（１２２）は、計測スレッド（８０１，８０２，８０３）で実行する計測実行部にタスクを通知する（９０４）。計測実行部（１２４）は、当該タスクに基づいて、計測を実行し、得た監視結果を計測制御部に通知する（９０５）。その後、計測制御部（１２２）は、通信部（１２１）を介して、監視サーバ（１１０）に当該監視結果の送信を試みる（９０６）。
【００４５】
この時、計測制御部（１２２）は、計測スレッドから送られてきた監視結果の送信に失敗する（９０７）と、待機時間（９０８）だけ待つ。そして、待機時間（９０８）が経過した後、次に監視結果を送信すべき時に到達（９１０）したら、送信に失敗（９０７）した監視結果と待機時間（９０８）中に得られた監視結果（９０９）をあわせて送信を試みる（９１１）。再度失敗した場合、これらのデータは保持され、待機時間（９１２）だけ待つ。そして待機時間（９１２）が経過した後、次に監視結果を送信すべき時に到達（９１４）したら、これまでに保持された結果と再送までに得られた監視結果（９１３）も含めて監視サーバ（１１０）に通知する（９１５）。なお、本実施例では、待機時間は固定であり、例えば、１８０秒とする。この待機時間（８３０）は計測サーバ上のデータベース（１２５）に起動時に格納されている。
【００４６】
また、計測制御部（１２２）は、監視サーバと計測サーバとのコネクションの状態を管理するフラグである接続状態フラグ（８２０）を持つ。接続状態がオンである場合、コネクションが確立していることを示す。接続状態がオフである場合、コネクションが切断されていることを示す。計測制御部は、コネクションが切断されている場合、最後に切断された時刻を切断時刻（８２１）として記録する。切断時刻は、ＵＴＣで表される。
【００４７】
図１０は本実施形態における計測サーバ（１２０）上での計測制御部（１２２）のフローチャートを示す図である。
【００４８】
はじめに、計測制御部（１２２）はタスクリストに含まれる各タスクについてスケジューリングを行う（１００１）。スケジューリングとは、タスクリストに含まれる各タスクについて、次回実行時刻と現在時刻を比較し、次回実行時刻が現在時刻と同じ、または超過しているタスクについて、内部通信部（１２４）のタスクパイプ（８１０）に書き込み、当該タスクの次回実行時刻を更新することである。次回実行時刻は、現在の次回実行時刻に間隔を加算して求められ、これをもとにイベント待ちタイムアウト時間が算出される。
【００４９】
次に通信部および内部通信部に到着する通信イベントを待つ（１００２）。ここで、待ち時間の上限はイベント待ちタイムアウト時間である。タイムアウトが発生した場合には、通信イベントは無く、次にタスクを処理すべき時刻が来たことを意味するため、スケジューリングに戻る（１００３，１００１）。タイムアウトの前に、監視条件登録要求を受信すると、受信した監視条件をタスクに変換し、タスクリストに登録する（１００４，１００５）。この時、第１回目の計測として、タスクを計測パイプに書き込み、次回実行時刻として、現在時刻に間隔を加算した値を設定する。内部通信イベントを検出すると、監視結果の送信を行う（１００６，１００７）。監視結果送信処理の詳細は図１１で説明する。
【００５０】
上記以外のイベントを検出した場合には、終了要求であるとみなし、計測スレッドに終了を通知するなどの終了処理を行い、計測サーバを終了する。
【００５１】
図１１は本実施形態における計測制御部の監視結果送信処理のフローチャートを示す図である。
【００５２】
計測制御部（１２２）は、監視サーバ（１１０）と計測サーバ（１２０）との通信コネクションの状態を示す接続状態フラグ（８２０）を参照し、接続状態を確認する（１１０１）。通信コネクションが接続状態であれば、監視結果送信を行う（１１０６）。接続状態でなければ、切断時刻からの経過時間と待機時間を比較し、経過時間が大きくなっているか判断する（１１０２）。もし大きければ、再度コネクションの接続を試みる（１１０３）。接続が成功すれば、接続状態フラグをオンに変更し（１１０４，１１０５）、監視結果送信を行う（１１０８）。接続に失敗すれば、送信できなかった監視結果を保存する（１１０４，１１０６）。その後、接続状態フラグをオフに変更し、切断時刻を更新し（１１０９）、図１０のスケジューリング（１００１）に戻る。
【００５３】
また、監視結果を送信し、送信に失敗すると、送信できなかった監視結果を保存する（１１０７，１１０８）。その後、接続状態フラグをオフに変更し、切断時刻を更新する（１１０９）。送信に成功すると図１０のスケジューリング（１００１）に戻る。
【００５４】
図１２は本実施形態における監視サーバ（１１０）と計測サーバ１（２２１）、計測サーバ２（２２２）、計測サーバ３（２２３）とのリトライシーケンスを示す図である。監視サーバ（１１０）が障害で停止し、再起動した後、計測サーバ１（２２１）、計測サーバ２（２２２）、計測サーバ３（２２３）が再接続するタイミングを、図１２を用いて説明する。ここでは、計測サーバ１（２２１）は監視条件リスト（３００）中の監視条件１（３０１）を、計測サーバ２（２２２）は監視条件リスト中の監視条件２（３０２）を、計測サーバ３（２２３）は監視条件リスト中の監視条件３（３０３）を実行する。縦軸は時間の経過を示す。
【００５５】
まず、監視サーバ（１１０）は時刻１２：０５：３０（１２０１）に停止し、１２：１１：５０（１２０２）に再起動したものとすると、計測サーバ１（２２１）による、１２：０５：００（１２０３）の監視結果送信は成功するが、１２：０６：００（１２０４）の監視結果送信に失敗する。その後、計測サーバ１（２２１）は、待機時間（１２０５）である１８０秒の間は監視結果の送信を行わない。そして、計測サーバ１（２２１）は、１２：０９：００（１２０６）に監視サーバとの再接続を試みるが、監視サーバはまだ再起動していないため、再接続は失敗する。計測サーバは、再接続に失敗した１２：０９：００から、再度１８０秒間待ち、１２：１２：００（１２０７）に再接続する。このとき、再接続に成功するため、これまで蓄積されてきた計測結果も監視サーバに通知する。
【００５６】
同じ様に、計測サーバ２（２２２）は、１２：０５：１５（１２１０）の監視結果は送信できるが、１２：０７：１５（１２１１）の監視結果に関しては失敗する。その後、待機時間（１２１２）である１８０秒の間は監視結果の送信を行わない。そして、１２：１０：１５（１２１３）には、再送時間になったとしても直ちに再接続を試みない。１２：１１：１５（１２１４）の計測結果を監視サーバ（１１０）に送信する時に、再接続を試みる。しかしながら監視サーバ（１１０）はまだ再起動していないため，再接続は失敗する。これにより、計測サーバ２（２２２）は、再接続を失敗した１２：１１：１５から、再度１８０秒まつ。この結果１２：１４：１５（１２１５）となったとしても、前回と同じように、直ちに再接続をしないで、１２：１５：１５（１２１６）の計測結果を送信するときに再接続を試みる。この時には、監視サーバ（１１０）と計測サーバ２（２２２）との再接続が成功し、計測サーバ２（２２２）は、送信が出来なくなった間に生成された４つの監視結果と１２：１５：１５のときの監視結果を送信する。
【００５７】
同様に、計測サーバ３（２２３）は、１２：０５：４５（１２２０）の計測結果の送信に失敗したとする。このとき、待機時間（１２２１）である１８０秒の間は監視結果の送信を行わない。そして、１２：０８：４５（１２２２）には、再送時間になったとしても直ちに再接続を試みない。１２：１０：４５（１２２３）になると、その計測結果を監視サーバに送信する時に、再接続を試みる。しかしながら監視サーバはまだ再起動していないため，再接続は失敗する。これにより、計測サーバ３（２２３）は、再接続を失敗した１２：１０：４５から、再度１８０秒待つ。この結果１２：１３：４５（１２２４）となったとしても、前回と同じように、直ちに再接続をしないで、１２：１５：４５（１２２５）の計測結果を送信するときに再接続を試みる。この場合、監視サーバと計測サーバ３との再接続が成功し、計測サーバ３は、送信が出来なくなった間に生成された２つの監視結果と１２：１５：４５のときの監視結果を監視サーバに送信する。
【００５８】
以上説明したように、本実施形態によると、計測間隔に応じたリトライ接続を行うことが可能になる。
【００５９】
【発明の効果】
本発明によれば、リトライ接続の実行タイミングが分散し、監視サーバおよびネットワークの負荷が分散される。
【図面の簡単な説明】
【図１】実施例の機能構成図である。
【図２】実施例のシステム構成図である。
【図３】実施例における監視条件リストおよび計測サーバリストを示す図である。
【図４】実施例における計測結果リストを示す図である。
【図５】実施例におけるタスクリストを示す図である。
【図６】実施例におけるパスワードリストを示す図である。
【図７】実施例における監視クライアントのＧＵＩを示す図である。
【図８】実施例における計測サーバの構成を示す図である。
【図９】実施例における計測制御部のシーケンスを示す図である。
【図１０】実施例における計測制御部のフローチャートを示す図である。
【図１１】実施例における計測制御部の監視結果送信処理のフローチャートを示す図である。
【図１２】実施例におけるリトライシーケンスを示す図である。
【符号の説明】
１００…監視クライアント、１１０…監視サーバ、１２０…計測サーバ、１０１…監視条件設定部、１０２…監視結果表示部、１１１…監視条件登録部、１１２…監視サーバ上の通信部、１１３…監視結果検索部、１１４…監視サーバ上のデータベース、１１５…構成定義ファイル、１２１…計測サーバ上の通信部、１２２…計測制御部、１２３…内部通信部、１２４…計測実行部、１２５…計測サーバ上のデータベース。
【図１】
2005038070.tif 000003
【図２】
2005038070.tif 000004
【図３】
2005038070.tif 000005
【図４】
2005038070.tif 000006
【図５】
2005038070.tif 000007
【図６】
2005038070.tif 000008
【図７】
2005038070.tif 000009
【図８】
2005038070.tif 000010
【図９】
2005038070.tif 000011
【図１０】
2005038070.tif 000012
【図１１】
2005038070.tif 000013
【図１２】
2005038070.tif 000014