通信装置、通信システムおよび状態監視方法
【課題】サーバ装置の監視を効率よく行うこと。
【解決手段】サーバ装置１１０は、監視端末１２１，１２２および中央監視端末１２３から送信される要求信号に応じて自装置の状態を示す状態情報を監視端末１２１，１２２および中央監視端末１２３へ送信する。リソース管理部１１３は、自装置の負荷状態を示す負荷情報を取得する。制御部１１４は、リソース管理部１１３によって取得された負荷情報に基づいて要求信号の送信方式を決定する。制御部１１４は、決定した送信方式を監視端末１２１，１２２および中央監視端末１２３へ通知する。
【解決手段】サーバ装置１１０は、監視端末１２１，１２２および中央監視端末１２３から送信される要求信号に応じて自装置の状態を示す状態情報を監視端末１２１，１２２および中央監視端末１２３へ送信する。リソース管理部１１３は、自装置の負荷状態を示す負荷情報を取得する。制御部１１４は、リソース管理部１１３によって取得された負荷情報に基づいて要求信号の送信方式を決定する。制御部１１４は、決定した送信方式を監視端末１２１，１２２および中央監視端末１２３へ通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信を行う通信装置、通信システムおよび状態監視方法に関する。
【背景技術】
【０００２】
近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の無線基地局のＯ＆Ｍ（Ｏｐｅｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ：保守監視）機構のように、通信装置の遠隔監視が検討されている。遠隔監視システムには、たとえばシンクライアント（Ｔｈｉｎ ｃｌｉｅｎｔ）方式が採用される。シンクライアント方式では、監視端末であるクライアントに最小限の処理をさせ、監視対象であるサーバにより多くの処理を集中させるため、監視端末のソフトウェアがメンテナンスフリーになり保守性が向上する。
【０００３】
また、近年の無線通信の高速化に伴って、一つの無線基地局でカバーできる範囲が小さくなってきているため、無線基地局の設置台数が増大している。このため、無線基地局を監視する監視端末の数も増大する。このため、無線基地局を監視する監視端末の数も増大する。これに対して、遠隔監視システムにシンクライアント方式を採用することで、多くの無線基地局を低コストで監視することが検討されている。
【０００４】
遠隔監視システムにシンクライアント方式を採用する場合は、クライアントである監視端末の主導によるアクセスとなるため、監視対象のサーバ装置の状態をリアルタイムに監視することができない。また、サーバ装置の状態を監視するためにログインする監視端末の数に比例して、サーバ装置で動作するＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）や処理プロセスにより、サーバ装置のメモリやＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の使用率が大きくなる。
【０００５】
これに対して、監視対象のサーバ装置の状態を監視する方式として、ポーリング（Ｐｏｌｌｉｎｇ）方式、ロングポーリング（Ｌｏｎｇ Ｐｏｌｌｉｎｇ）方式、チャンク（Ｃｈｕｎｋ）方式などがある。ポーリング方式においては、クライアントである監視端末が、監視対象のサーバ装置に障害イベントの有無を定期的に問い合わせる（ポーリング）。
【０００６】
ロングポーリング方式においては、クライアントである監視端末が、障害イベントの問い合わせ（ポーリング）を、サーバ装置が通知するタイミングまで待機する。チャンク方式においては、監視端末からサーバ装置へのリクエスト信号で確立されるコネクションを維持しながら、サーバ装置が監視端末へ障害イベントを通知する。
【０００７】
また、サーバ装置が監視端末の状態情報を入手し、監視端末の処理負荷に応じてレスポンスを送信する周期をスケジューリングする方法が知られている（たとえば、下記特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００６−１５５５０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、サーバ装置の監視における適切な方式は、サーバ装置の監視を行う監視端末の数や監視端末の優先度などによって異なる。このため、上述した従来技術では、監視端末によるサーバ装置の監視を効率よく行うことができないという問題がある。
【００１０】
たとえば、ポーリング方式においては、監視端末による要求信号の送信（ポーリング）の間隔が長いと、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが長くなりリアルタイム性が損なわれる。また、要求信号の送信の間隔が短いと、障害イベントの有無に関係なくサーバ装置やネットワークの負荷が大きくなる。
【００１１】
また、ロングポーリング方式やチャンク方式においては、サーバ装置やネットワークの負荷が大きくなりやすいため、一時的に多数の監視端末がサーバ装置の監視を行うと、サーバ装置が通信不能になることがある。この場合は、たとえば、監視端末においてサーバ装置がダウンしたと判断される場合もある。
【００１２】
開示の通信装置、通信システムおよび状態監視方法は、上述した問題点を解消するものであり、通信装置の監視を効率よく行うことを目的とする。
【課題を解決するための手段】
【００１３】
上述した課題を解決し、目的を達成するため、開示技術は、監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、自装置の負荷状態を示す負荷情報を取得し、取得された負荷情報に基づいて前記要求信号の送信方式を決定し、決定された送信方式を前記監視端末へ通知する。
【発明の効果】
【００１４】
開示の通信装置、通信システムおよび状態監視方法によれば、通信装置の監視を効率よく行うことができる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態にかかる通信システムを示す図である。
【図２】送信方式の決定テーブルの一例を示す図である。
【図３】制御部の動作の一例を示すフローチャートである。
【図４】輻輳状態における送信方式の通知処理の一例を示すフローチャートである。
【図５】非輻輳状態における送信方式の通知処理の一例を示すフローチャートである。
【図６】ポーリング方式による監視動作を示すシーケンス図である。
【図７】ロングポーリング方式による監視動作を示すシーケンス図である。
【図８】チャンク方式による監視動作を示すシーケンス図である。
【図９】通信システムの動作の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１６】
以下に図面を参照して、開示技術の好適な実施の形態を詳細に説明する。開示技術は、監視端末がサーバ装置へ状態情報を要求する要求信号の送信方式をサーバ装置の負荷状態に応じて決定し、決定した送信方式をサーバ装置から監視端末へ通知することで、監視端末によるサーバ装置の監視を効率よく行う。
【００１７】
（実施の形態）
図１は、実施の形態にかかる通信システムを示す図である。図１に示すように、実施の形態にかかる通信システム１００は、サーバ装置１１０と、監視端末１２１，１２２と、中央監視端末１２３と、予備サーバ１３０と、を含んでいる。通信システム１００においては、サーバ装置１１０を監視対象とし、クライアントである監視端末１２１，１２２および中央監視端末１２３によってサーバ装置１１０の状態を監視する。
【００１８】
サーバ装置１１０（通信装置）は、たとえば、移動局との間で無線通信を行う無線基地局である。無線基地局は、たとえばＬＴＥのｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）である。サーバ装置１１０は、自装置をサーバ、監視端末１２１，１２２および中央監視端末１２３をクライアントとして、たとえばＷｅｂサーバ−クライアント方式によるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信を行う。
【００１９】
サーバ装置１１０は、監視端末１２１，１２２および中央監視端末１２３から送信された要求信号に応じて、自装置の状態を示す状態情報を監視端末１２１，１２２および中央監視端末１２３へ送信する。具体的には、サーバ装置１１０は、装置状態管理部１１１と、ユーザ管理部１１２と、リソース管理部１１３と、制御部１１４と、通信インターフェース１１５と、を備えている。
【００２０】
装置状態管理部１１１は、サーバ装置１１０（自装置）の状態を示す状態情報を取得する。ここでは、サーバ装置１１０の状態を示す状態情報として、サーバ装置１１０の障害に関する情報を一例として説明する。具体的には、装置状態管理部１１１は、障害の発生や障害からの復旧などの障害イベントが発生すると、発生した障害イベントを示すイベント情報を制御部１１４へ出力する。
【００２１】
ユーザ管理部１１２は、サーバ装置１１０がサービスを提供しているユーザに関する情報（たとえばユーザの数）を管理する。たとえば、ユーザ管理部１１２は、サーバ装置１１０にログインしている監視端末（たとえば監視端末１２１，１２２および中央監視端末１２３）の情報を管理する。また、ユーザ管理部１１２は、サーバ装置１１０にログインしている監視端末の優先度の情報を管理する。たとえばユーザ管理部１１２は、監視端末のサーバ装置１１０へのログイン時に、監視端末の種別に応じて優先度を設定する。たとえば、中央監視端末１２３は、監視端末１２１，１２２より高い優先度が設定される。
【００２２】
リソース管理部１１３は、サーバ装置１１０の負荷状態を示す負荷情報を取得する負荷取得部である。負荷情報は、たとえば、ソフトウェアによる処理がサーバ装置１１０のＣＰＵを占有している時間の割合を示すＣＰＵ使用率や、サーバ装置１１０において処理待ちになっているイベントの数を示すイベント滞留Ｑ（キュー）数などである。また、負荷情報は、サーバ装置１１０のメモリ使用率や通信量などであってもよい。リソース管理部１１３は、取得した負荷情報を制御部１１４へ出力する。
【００２３】
制御部１１４は、リソース管理部１１３から出力された負荷情報に基づいて、監視端末１２１，１２２および中央監視端末１２３による要求信号の送信方式を決定（スケジューリング）する決定部である。送信方式には、たとえば、次要求起動時間、要求回数、コネクション状態などがパラメータとして含まれる。
【００２４】
次要求起動時間は、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ要求信号を送信する間隔を示すパラメータである。要求回数は、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ要求信号を送信する回数を示すパラメータである。コネクション状態は、要求信号を送信するためのコネクションを、要求信号の送信ごとに切断するか否かを示すパラメータである。
【００２５】
たとえば、サーバ装置１１０のメモリ（記憶部）には、負荷情報と送信方式を対応付ける決定テーブル（たとえば図２参照）が記憶されている。制御部１１４は、サーバ装置１１０のメモリに記憶された決定テーブルと、リソース管理部１１３から出力された負荷情報と、に基づいて送信方式を決定する。または、サーバ装置１１０のメモリ（記憶部）には、負荷情報から送信方式の各パラメータを算出する算出式が記憶されていてもよい。この場合は、制御部１１４は、サーバ装置１１０のメモリに記憶された算出式と、リソース管理部１１３から出力された負荷情報と、に基づいて送信方式を決定する。
【００２６】
また、制御部１１４は、決定した送信方式を監視端末１２１，１２２および中央監視端末１２３へ通知する通知部である。具体的には、制御部１１４は、決定した送信方式を示すクリエイタパケットを、通信インターフェース１１５を介して監視端末１２１，１２２および中央監視端末１２３へ送信する。
【００２７】
また、制御部１１４は、通知した送信方式によって監視端末１２１，１２２および中央監視端末１２３から送信された要求信号を、通信インターフェース１１５を介して受信する受信部である。たとえば、制御部１１４は、ＨＴＴＰリクエストとして送信された要求信号を受信する。また、制御部１１４は、受信した要求信号に応じて、装置状態管理部１１１から出力されたイベント情報を、通信インターフェース１１５を介して監視端末１２１，１２２および中央監視端末１２３へ送信する送信部である。たとえば、制御部１１４は、ＨＴＴＰレスポンスとしてイベント情報を送信する。
【００２８】
制御部１１４は、たとえば、受信した要求信号に対して送信するイベント情報とともに、以降の要求信号の送信方式を示すクリエイタパケットを送信する。または、制御部１１４は、イベント情報とは別にクリエイタパケットを任意のタイミングで送信してもよい。制御部１１４は、クリエイタパケットを監視端末１２１，１２２および中央監視端末１２３へ送信することで、監視端末１２１，１２２および中央監視端末１２３に対して、制御部１１４が決定した送信方法によって要求信号を送信させることができる。
【００２９】
また、制御部１１４は、負荷情報が示す負荷量が閾値を超えた場合（輻輳状態）に、予備サーバ１３０を介してイベント情報を中央監視端末１２３へ送信することで、イベント情報を予備サーバ１３０に記憶させる。これにより、サーバ装置１１０が輻輳状態であっても、中央監視端末１２３に対してはイベント情報を送信し、中央監視端末１２３によるサーバ装置１１０の監視のリアルタイム性を維持することができる。
【００３０】
また、制御部１１４は、負荷情報が示す負荷量が閾値を超えた場合に、非常ビット（ＯＮ）と予備サーバ１３０のアドレスとを含むクリエイタパケットを監視端末１２１，１２２へ送信する。非常ビット（ＯＮ）は、サーバ装置１１０が輻輳状態でありイベント情報の要求先をサーバ装置１１０から予備サーバ１３０へ切り替えることを示す情報である。
【００３１】
これにより、サーバ装置１１０が輻輳状態の場合に、監視端末１２１，１２２からの要求信号に対するイベント情報の送信を予備サーバ１３０に代行させ、サーバ装置１１０の負荷を軽減することができる。
【００３２】
通信インターフェース１１５は、ネットワーク１０を介して、監視端末１２１，１２２、中央監視端末１２３および予備サーバ１３０との間で通信を行うインターフェースである。たとえば、ネットワーク１０は有線のネットワークであり、通信インターフェース１１５は有線による通信を行う。
【００３３】
監視端末１２１，１２２および中央監視端末１２３のそれぞれは、サーバ装置１１０によって通知された送信方式によってサーバ装置１１０へ要求信号を送信する監視端末である。また、監視端末１２１，１２２および中央監視端末１２３のそれぞれは、送信した要求信号に応じてサーバ装置１１０によって送信されたイベント情報を受信する。監視端末１２１，１２２のそれぞれは、受信したイベント情報をユーザへ出力する。
【００３４】
また、監視端末１２１，１２２のそれぞれは、サーバ装置１１０から非常ビット（ＯＮ）および予備サーバ１３０のアドレスを含むクリエイタパケットを受信すると、サーバ装置１１０が輻輳状態である旨をユーザへ表示する。また、監視端末１２１，１２２のそれぞれは、クリエイタパケットに含まれる次要求起動時間が０［ｍｓ］より長い場合は、次要求起動時間が経過するまでサーバ装置１１０に対する要求信号の送信を行わない。
【００３５】
また、監視端末１２１，１２２のそれぞれは、サーバ装置１１０に対する要求信号の送信を行わない期間において、サーバ装置１１０のイベント情報を要求する要求信号を予備サーバ１３０へ送信してもよい。具体的には、監視端末１２１，１２２のそれぞれは、クリエイタパケットに含まれる予備サーバ１３０のアドレスを用いて要求信号を予備サーバ１３０へ送信する。これにより、輻輳状態のサーバ装置１１０に負荷をかけずに、サーバ装置１１０のイベント情報を予備サーバ１３０から受信することができる。
【００３６】
予備サーバ１３０は、中央監視端末１２３を宛先とするイベント情報をサーバ装置１１０から受信すると、受信したイベント情報を中央監視端末１２３へ転送するとともに、受信したイベント情報を記憶する。また、予備サーバ１３０は、サーバ装置１１０のイベント情報を要求する要求信号を監視端末１２１，１２２から受信すると、記憶しておいたイベント情報を監視端末１２１，１２２へ送信する。これにより、予備サーバ１３０は、サーバ装置１１０が輻輳状態の場合に、監視端末１２１，１２２からの要求信号に対するイベント情報の送信を代行することができる。
【００３７】
図２は、送信方式の決定テーブルの一例を示す図である。サーバ装置１１０は、たとえば決定テーブル２００を自装置のメモリ（記憶部）に記憶している。決定テーブル２００においては、サーバ装置１１０の負荷状態を示すＣＰＵ使用率とイベント滞留Ｑ数の組み合わせごとに、要求信号の送信方式が対応付けられている。
【００３８】
ここでは、ＣＰＵ使用率は、「高」「中」「低」の３つの範囲に分けられている。たとえば、制御部１１４は、ＣＰＵ使用率が第一閾値より低ければＣＰＵ使用率を「低」と判断する。また、制御部１１４は、ＣＰＵ使用率が第二閾値（＞第一閾値）より高ければＣＰＵ使用率を「高」と判断する。また、制御部１１４は、ＣＰＵ使用率が第一閾値以上かつ第二閾値以下の範囲であればＣＰＵ使用率を「中」と判断する。
【００３９】
また、イベント滞留Ｑ数は、「多」「中」「少」の各範囲に分けられている。たとえば、制御部１１４は、イベント滞留Ｑ数が第三閾値より低ければイベント滞留Ｑ数を「少」と判断する。また、制御部１１４は、イベント滞留Ｑ数が第四閾値（＞第三閾値）より高ければイベント滞留Ｑ数を「多」と判断する。また、制御部１１４は、イベント滞留Ｑ数が第三閾値以上かつ第四閾値以下の範囲であればイベント滞留Ｑ数を「中」と判断する。
【００４０】
たとえば、決定テーブル２００において、ＣＰＵ使用率「高」とイベント滞留Ｑ数「多」の組み合わせには送信方式１が対応付けられている。送信方式１は、次回要求起動時間Ｔが３０［ｓ］、要求回数ＲＮが１０、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式１はポーリング方式になる。また、送信方式１には、非常ビットと、予備サーバ１３０のアドレスを示すＤＢ−ＩＰと、が対応付けられている。
【００４１】
また、決定テーブル２００において、ＣＰＵ使用率「高」とイベント滞留Ｑ数「少」の組み合わせには送信方式３が対応付けられている。送信方式３は、次回要求起動時間Ｔが３０［ｓ］、要求回数ＲＮが１、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式３はポーリング方式になる。また、送信方式３には、非常ビットと、予備サーバ１３０のアドレスを示すＤＢ−ＩＰと、が対応付けられている。
【００４２】
また、決定テーブル２００において、ＣＰＵ使用率「低」とイベント滞留Ｑ数「多」の組み合わせには送信方式７が対応付けられている。送信方式７は、次回要求起動時間Ｔが０［ｍｓ］、要求回数ＲＮが１０、コネクション状態ＣＳが「継続」である方式である。したがって、送信方式７はチャンク方式になる。
【００４３】
また、決定テーブル２００において、ＣＰＵ使用率「低」とイベント滞留Ｑ数「少」の組み合わせには送信方式９が対応付けられている。送信方式９は、次回要求起動時間Ｔが０［ｍｓ］、要求回数ＲＮが１、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式９はロングポーリング方式になる。
【００４４】
制御部１１４は、ＣＰＵ使用率とイベント滞留Ｑ数をリソース管理部１１３から取得し、取得したＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに対応する送信方式を決定テーブル２００から選択する。これにより、サーバ装置１１０の負荷情報に基づいて送信方式を決定することができる。制御部１１４は、決定した送信方式を示すクリエイタパケットを監視端末１２１，１２２および中央監視端末１２３へ送信する。
【００４５】
また、制御部１１４は、送信方式を決定する対象の監視端末の種別およびサーバ装置１１０の負荷情報に基づいて送信方式を決定してもよい。たとえば、サーバ装置１１０は、送信方式を決定する対象の監視端末の種別ごとに異なる決定テーブル２００をメモリに記憶する。そして、制御部１１４は、取得したＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに対応する送信方式を、送信方式を決定する対象の監視端末の種別に対応する決定テーブル２００から選択する。これにより、送信方式を決定する対象の監視端末の種別およびサーバ装置１１０の負荷情報に基づいて送信方式を決定することができる。
【００４６】
また、制御部１１４は、送信方式を決定する対象の監視端末の種別が特定の種別である場合（たとえば中央監視端末１２３）は、決定テーブル２００によらず、あらかじめ記憶しておいた特定の送信方式を選択するようにしてもよい。たとえば、中央監視端末１２３についてはロングポーリング方式またはチャンク方式を選択することで、中央監視端末１２３によるサーバ装置１１０の監視のリアルタイム性を向上させることができる。
【００４７】
このように、決定テーブル２００においては、大きな負荷量を示す負荷情報ほど、サーバ装置１１０の負荷量が小さい送信方式が対応付けられている。これにより、制御部１１４は、サーバ装置１１０の負荷量が大きいほど、サーバ装置１１０の負荷量が小さい送信方式を選択することができる。このため、サーバ装置１１０の負荷量が大きい場合にサーバ装置１１０の負荷を低減することができる。
【００４８】
一方、決定テーブル２００においては、小さな負荷量を示す負荷情報ほど、監視のリアルタイム性（即時性）が高い送信方式が対応付けられている。これにより、制御部１１４は、サーバ装置１１０の負荷量が小さいほど、監視のリアルタイム性が高い送信方式を選択することができる。このため、サーバ装置１１０の負荷量が小さい場合に監視のリアルタイム性を向上させることができる。
【００４９】
ただし、決定テーブル２００における負荷情報と送信方式の関係はこれに限らず、各方式の特性やサーバ装置１１０の適用先に応じて柔軟に設定することができる。なお、ここではＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに基づいて送信方式を決定する方法について説明したが、送信方式を決定する方法についてはこれに限らない。たとえば、ＣＰＵ使用率またはイベント滞留Ｑ数に基づいて送信方式を決定してもよい。また、ＣＰＵ使用率やイベント滞留Ｑ数の他に、サーバ装置１１０のメモリ使用率や通信量などに基づいて送信方式を決定してもよい。
【００５０】
図３は、制御部の動作の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、たとえば以下の各ステップを実行する。まず、装置状態管理部１１１からの出力に基づいて障害イベントが発生したか否かを判断し（ステップＳ３０１）、障害イベントが発生するまで待つ（ステップＳ３０１：Ｎｏのループ）。障害イベントが発生すると（ステップＳ３０１：Ｙｅｓ）、自装置のＣＰＵ使用率およびイベント滞留Ｑ数をリソース管理部１１３から取得する（ステップＳ３０２）。
【００５１】
つぎに、ステップＳ３０２によって取得されたＣＰＵ使用率が「高」であるか否かを判断する（ステップＳ３０３）。取得されたＣＰＵ使用率が「高」である場合（ステップＳ３０３：Ｙｅｓ）は、輻輳状態における送信方式の通知処理（たとえば図４参照）を実行し（ステップＳ３０４）、一連の動作を終了する。取得されたＣＰＵ使用率が「中」または「低」である場合（ステップＳ３０３：Ｎｏ）は、非輻輳状態における送信方式の通知処理（たとえば図５参照）を実行し（ステップＳ３０５）、一連の動作を終了する。
【００５２】
図４は、輻輳状態における送信方式の通知処理の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、図３のステップＳ３０４に示した輻輳状態における送信方式の通知処理として、サーバ装置１１０にログインしている監視端末ごとに、たとえば以下の各ステップを実行する。なお、サーバ装置１１０にログインしている監視端末は、ここでは監視端末１２１，１２２および中央監視端末１２３であるとする。
【００５３】
まず、対象の監視端末が中央監視端末１２３であるか否かを判断する（ステップＳ４０１）。対象の監視端末が中央監視端末１２３である場合（ステップＳ４０１：Ｙｅｓ）は、図３のステップＳ３０２によって取得されたイベント滞留Ｑ数が「多」であるか否かを判断する（ステップＳ４０２）。イベント滞留Ｑ数が「多」である場合（ステップＳ４０２：Ｙｅｓ）は、決定テーブル２００から送信方式７を選択し（ステップＳ４０３）、ステップＳ４０７へ移行する。
【００５４】
ステップＳ４０２において、イベント滞留Ｑ数が「多」でない場合（ステップＳ４０２：Ｎｏ）は、イベント滞留Ｑ数が「中」であるか否かを判断する（ステップＳ４０４）。イベント滞留Ｑ数が「中」である場合（ステップＳ４０４：Ｙｅｓ）は、決定テーブル２００から送信方式８を選択し（ステップＳ４０５）、ステップＳ４０７へ移行する。
【００５５】
ステップＳ４０４において、イベント滞留Ｑ数が「少」である場合（ステップＳ４０４：Ｎｏ）は、決定テーブル２００から送信方式９を選択する（ステップＳ４０６）。つぎに、イベント情報と、ステップＳ４０３，Ｓ４０５，Ｓ４０６のいずれかによって選択された送信方式を示すクリエイタパケットと、を予備サーバ１３０へ送信し（ステップＳ４０７）、一連の動作を終了する。ステップＳ４０７によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。
【００５６】
ステップＳ４０１において、対象の監視端末が監視端末１２１，１２２のいずれかである場合（ステップＳ４０１：Ｎｏ）は、サーバ装置１１０のメモリに記憶されている非常ビットがＯＮか否かを判断する（ステップＳ４０８）。非常ビットがＯＮである場合（ステップＳ４０８：Ｙｅｓ）は、一連の動作を終了する。これにより、サーバ装置１１０の輻輳状態が継続している場合は、監視端末１２１，１２２に対する応答を行わずにサーバ装置１１０の負荷を軽減することができる。
【００５７】
ステップＳ４０８において非常ビットがＯＦＦである場合（ステップＳ４０８：Ｎｏ）は、非常ビットをＯＮにする（ステップＳ４０９）。つぎに、図３のステップＳ３０２によって取得されたイベント滞留Ｑ数が「多」であるか否かを判断する（ステップＳ４１０）。イベント滞留Ｑ数が「多」である場合（ステップＳ４１０：Ｙｅｓ）は、決定テーブル２００から送信方式１を選択し（ステップＳ４１１）、ステップＳ４１５へ移行する。
【００５８】
ステップＳ４１０において、イベント滞留Ｑ数が「多」でない場合（ステップＳ４１０：Ｎｏ）は、イベント滞留Ｑ数が「中」であるか否かを判断する（ステップＳ４１２）。イベント滞留Ｑ数が「中」である場合（ステップＳ４１２：Ｙｅｓ）は、決定テーブル２００から送信方式２を選択し（ステップＳ４１３）、ステップＳ４１５へ移行する。
【００５９】
ステップＳ４１２において、イベント滞留Ｑ数が「少」である場合（ステップＳ４１２：Ｎｏ）は、決定テーブル２００から送信方式３を選択し（ステップＳ４１４）、ステップＳ４１５へ移行する。つぎに、ステップＳ４１１，Ｓ４１３，Ｓ４１４のいずれかによって選択された送信方式を示すクリエイタパケットを対象の監視端末へ送信し（ステップＳ４１５）、一連の動作を終了する。
【００６０】
ステップＳ４１５によって送信されるクリエイタパケットには、ステップＳ４０９によってＯＮにされた非常ビットおよび予備サーバ１３０のアドレスが含まれる（たとえば図２参照）。これにより、監視端末１２１，１２２に対して、サーバ装置１１０のイベント情報の要求先をサーバ装置１１０から予備サーバ１３０に切り替えさせることができる。
【００６１】
図５は、非輻輳状態における送信方式の通知処理の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、図３のステップＳ３０５に示した非輻輳状態における送信方式の通知処理として、サーバ装置１１０にログインしている監視端末ごとに、たとえば以下の各ステップを実行する。なお、サーバ装置１１０にログインしている監視端末は、たとえば監視端末１２１，１２２および中央監視端末１２３である。
【００６２】
図５に示すステップＳ５０１〜Ｓ５０６は、図４に示したステップＳ４０１〜Ｓ４０６と同様であるため説明を省略する。ステップＳ５０３，Ｓ５０５，Ｓ５０６のいずれかのつぎに、イベント情報とクリエイタパケットを中央監視端末１２３へ送信し（ステップＳ５０７）、一連の動作を終了する。ステップＳ５０７によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。ステップＳ５０７によって送信されるクリエイタパケットは、ステップＳ５０３，Ｓ５０５，Ｓ５０６のいずれかによって選択された送信方式を示すクリエイタパケットである。
【００６３】
ステップＳ５０１において対象の監視端末が監視端末１２１，１２２のいずれかである場合（ステップＳ５０１：Ｎｏ）は、サーバ装置１１０のメモリに記憶されている非常ビットがＯＮであるか否かを判断する（ステップＳ５０８）。非常ビットがＯＦＦである場合（ステップＳ５０８：Ｎｏ）はステップＳ５１０へ移行する。非常ビットがＯＮである場合（ステップＳ５０８：Ｙｅｓ）は非常ビットをＯＦＦにする（ステップＳ５０９）。
【００６４】
図５に示すステップＳ５１０〜Ｓ５１４は、図４に示したステップＳ４１０〜Ｓ４１４と同様であるため説明を省略する。ただし、ステップＳ５１１において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式４を選択し、ＣＰＵ使用率が「低」である場合は送信方式７を選択する。
【００６５】
また、ステップＳ５１３において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式５を選択し、ＣＰＵ使用率が「低」である場合は送信方式８を選択する。また、ステップＳ５１４において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式６を選択し、ＣＰＵ使用率が「低」である場合は送信方式９を選択する。
【００６６】
ステップＳ５１１，Ｓ５１３，Ｓ５１４のいずれかのつぎに、イベント情報とクリエイタパケットを対象の監視端末へ送信し（ステップＳ５１５）、一連の動作を終了する。ステップＳ５１５によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。ステップＳ５１５によって送信されるクリエイタパケットは、ステップＳ５１１，Ｓ５１３，Ｓ５１４のいずれかによって選択された送信方式を示すクリエイタパケットである。
【００６７】
図３〜図５に示した動作を繰り返し実行することで、サーバ装置１１０は、障害イベントが発生するごとに、発生した障害イベントを示すイベント情報を各監視端末へ送信することができる。また、サーバ装置１１０は、イベント情報の送信とともに、自装置の負荷状態に基づいて決定した送信方式を各監視端末へ通知することができる。
【００６８】
また、サーバ装置１１０は、自装置が輻輳状態である場合には、監視端末１２１，１２２からの要求信号に対する応答を予備サーバ１３０に代行させることができる。ただし、サーバ装置１１０は、中央監視端末１２３からの要求信号に対する応答は継続することで、中央監視端末１２３による監視のリアルタイム性を維持することができる。
【００６９】
図６は、ポーリング方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。ポーリング方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ６０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７０】
このとき、サーバ装置１１０の装置状態管理部１１１から制御部１１４へイベント情報１が出力されているとする。サーバ装置１１０の制御部１１４は、ステップＳ６０１によって送信された要求信号に応じて、装置状態管理部１１１から出力されたイベント情報１を監視端末１２１へ送信する（ステップＳ６０２）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７１】
つぎに、監視端末１２１は、ステップＳ６０１によって要求信号を送信してから次回要求起動時間Ｔの経過後に、要求信号をサーバ装置１１０へ送信する（ステップＳ６０３）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７２】
このとき、サーバ装置１１０の装置状態管理部１１１から制御部１１４へイベント情報２が出力されているとする。サーバ装置１１０の制御部１１４は、ステップＳ６０３によって送信された要求信号に応じて、装置状態管理部１１１から出力されたイベント情報２を監視端末１２１へ送信する（ステップＳ６０４）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７３】
このように、ポーリング方式においては、所定のインターバルごとに監視端末１２１からサーバ装置１１０へ要求信号を発行し、監視端末１２１から要求信号が発行されるごとにサーバ装置１１０から監視端末１２１へイベント情報１を送信する。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０［ｍｓ］より大きくしてコネクション状態ＣＳを「切断」とすると、ポーリング方式となる。
【００７４】
ポーリング方式においては、監視端末による要求信号の送信（ポーリング）の間隔が長いと、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが長くなり、リアルタイム性が損なわれる。また、ポーリング方式において、監視端末による要求信号の送信の間隔が短いと、障害イベントの有無に関係なく負荷サーバ装置やネットワークの負荷が大きくなる。
【００７５】
図７は、ロングポーリング方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。ロングポーリング方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ７０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７６】
サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報１が出力されるのを待って、ステップＳ７０１によって送信された要求信号に応じて監視端末１２１へイベント情報１を送信する（ステップＳ７０２）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７７】
つぎに、監視端末１２１は、ステップＳ７０２によってイベント情報１を受信すると、要求信号をサーバ装置１１０へ送信（即時要求）する（ステップＳ７０３）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７８】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報２が出力されるのを待って、ステップＳ７０３によって送信された要求信号に応じて監視端末１２１へイベント情報２を送信する（ステップＳ７０４）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７９】
このように、ロングポーリング方式においては、イベント情報の送信のためのコネクションを確立しておき、イベントが発生したときに、確立しておいたコネクションを用いてイベント情報を送信する。イベント情報を送信すると、コネクションが一旦切断され、監視端末１２１からサーバ装置１１０へ要求信号が再度発行される。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０としてコネクション状態ＣＳを「切断」とすると、ロングポーリング方式となる。
【００８０】
ロングポーリング方式においては、障害イベントが輻輳すると、イベント情報の送信のためのコネクションの接続および切断が頻繁に発生するため、サーバ装置の負荷が大きくなる。また、ロングポーリング方式においては、単位時間あたりの障害イベントに対してのスケーラビリティ（拡張性）が低い。
【００８１】
図８は、チャンク方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。チャンク方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ８０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００８２】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報１が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報１を送信する（ステップＳ８０２）。制御部１１４は、イベント情報１を送信しても、監視端末１２１との間のコネクションを継続する。
【００８３】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報２が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報２を送信する（ステップＳ８０３）。制御部１１４は、イベント情報２を送信しても、監視端末１２１との間のコネクションを継続する。
【００８４】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報３が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報３を送信する（ステップＳ８０４）。制御部１１４は、イベント情報３を送信しても、監視端末１２１との間のコネクションを継続する。
【００８５】
このように、チャンク方式においては、イベント情報の送信のためのコネクションを確立しておき、イベントが発生したときに、確立しておいたコネクションを用いてイベント情報を送信する。また、イベント情報を送信してもコネクションを継続し、監視端末１２１からサーバ装置１１０への要求信号の再度の発行は行わない。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０としてコネクション状態ＣＳを「継続」とすると、チャンク方式となる。
【００８６】
チャンク方式においては、イベント情報を送信するためのコネクションが確立されたままになるため、障害イベントが発生していない場合は無駄な処理が発生する。また、イベント情報を送信するためのコネクションが切断されると、サーバ装置において障害イベントが発生しても監視端末にイベント情報を送信することができない。
【００８７】
図９は、通信システムの動作の一例を示すシーケンス図である。ここでは、期間Ｔ１においてはサーバ装置１１０が低負荷状態（たとえばＣＰＵ使用率が「低」かつイベント滞留Ｑ数が「少」）である。また、期間Ｔ１の後の期間Ｔ２においてはサーバ装置１１０が高負荷状態（たとえばＣＰＵ使用率が「高」かつイベント滞留Ｑ数が「多」）である。
【００８８】
また、期間Ｔ１においては、初期状態として、ロングポーリング方式による監視動作（たとえば図７参照）が行われているとする。まず、監視端末１２１，１２２および中央監視端末１２３が、サーバ装置１１０の状態情報を要求する要求信号（Ｒｅｑｕｅｓｔ）をサーバ装置１１０へ送信する（ステップＳ９０１〜Ｓ９０３）。つぎに、サーバ装置１１０において障害イベントＥ１が発生したとする。
【００８９】
つぎに、サーバ装置１１０が、ステップＳ９０１において中央監視端末１２３からの要求信号を受信しているため、応答信号（Ｒｅｓｐｏｎｓｅ）およびクリエイタパケット（Ｃｒｅａｔｏｒ）を中央監視端末１２３へ送信する（ステップＳ９０４）。ステップＳ９０４によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０４によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９０】
つぎに、中央監視端末１２３が、ステップＳ９０４によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０５）。また、中央監視端末１２３は、ステップＳ９０４によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９１】
つぎに、サーバ装置１１０が、ステップＳ９０２において監視端末１２１からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２１へ送信する（ステップＳ９０６）。ステップＳ９０６によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０６によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９２】
つぎに、監視端末１２１が、ステップＳ９０６によって受信したクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０７）。また、監視端末１２１は、ステップＳ９０６によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９３】
つぎに、サーバ装置１１０が、ステップＳ９０３において監視端末１２２からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２２へ送信する（ステップＳ９０８）。ステップＳ９０８によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０８によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９４】
つぎに、監視端末１２２が、ステップＳ９０８によって受信したクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０９）。また、監視端末１２２は、ステップＳ９０８によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９５】
つぎに、サーバ装置１１０において新たな障害イベントＥ２が発生したとする。つぎに、サーバ装置１１０が、ステップＳ９０５において中央監視端末１２３からの要求信号を受信しているため、応答信号およびクリエイタパケットを送信する（ステップＳ９１０）。ステップＳ９１０によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。ステップＳ９１０によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。また、期間Ｔ２においてはサーバ装置１１０が高負荷状態であり、かつイベント情報の要求元が中央監視端末１２３であるため、ステップＳ９１０において応答信号およびクリエイタパケットは予備サーバ１３０へ送信される。
【００９６】
つぎに、予備サーバ１３０が、ステップＳ９１０によって送信された応答信号およびクリエイタパケットを中央監視端末１２３へ転送する（ステップＳ９１１）。また、予備サーバ１３０は、ステップＳ９１０によって送信された応答信号に含まれるイベント情報を記憶しておく。つぎに、中央監視端末１２３が、ステップＳ９１１によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９１２）。また、中央監視端末１２３は、ステップＳ９１１によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９７】
つぎに、サーバ装置１１０が、ステップＳ９０７において監視端末１２１からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２１へ送信する（ステップＳ９１３）。ステップＳ９１３によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。
【００９８】
また、サーバ装置１１０が高負荷状態であるため、ステップＳ９１３によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：３０［ｓ］）、要求回数（ＲＮ：１）、非常ビット（ＯＮ）および予備サーバ１３０のアドレス（ＤＢ−ＩＰ）が含まれている。監視端末１２１は、ステップＳ９１３によって送信されたクリエイタパケット（Ｔ：３０［ｓ］）に基づいて３０［ｓ］のタイマを設定する。
【００９９】
つぎに、サーバ装置１１０が、ステップＳ９０９において監視端末１２２からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２２へ送信する（ステップＳ９１４）。ステップＳ９１４によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。
【０１００】
また、サーバ装置１１０が高負荷状態であるため、ステップＳ９１４によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：３０［ｓ］）、要求回数（ＲＮ：１）、非常ビット（ＯＮ）および予備サーバ１３０のアドレス（ＤＢ−ＩＰ）が含まれている。監視端末１２２は、ステップＳ９１４によって送信されたクリエイタパケット（Ｔ：３０［ｓ］）に基づいて３０［ｓ］のタイマを設定する。
【０１０１】
つぎに、サーバ装置１１０において新たな障害イベントＥ３が発生したとする。つぎに、サーバ装置１１０が、ステップＳ９１２において中央監視端末１２３からの要求信号を受信しているため、応答信号およびクリエイタパケットを送信する（ステップＳ９１５）。ステップＳ９１５によって送信される応答信号には、障害イベントＥ３を示すイベント情報が含まれている。ステップＳ９１５によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。また、期間Ｔ２においてはサーバ装置１１０が高負荷状態であり、かつイベント情報の要求元が中央監視端末１２３であるため、ステップＳ９１５においてクリエイタパケットは予備サーバ１３０へ送信される。
【０１０２】
つぎに、予備サーバ１３０が、ステップＳ９１５によって送信された応答信号およびクリエイタパケットを中央監視端末１２３へ転送する（ステップＳ９１６）。また、予備サーバ１３０は、ステップＳ９１５によって送信された応答信号に含まれるイベント情報を記憶しておく。つぎに、中央監視端末１２３が、ステップＳ９１６によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９１７）。また、中央監視端末１２３は、ステップＳ９１６によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【０１０３】
つぎに、監視端末１２１が、ステップＳ９１３によって受信したクリエイタパケットに非常ビット（ＯＮ）が含まれているため、クリエイタパケットに含まれるアドレスに基づいて予備サーバ１３０へ要求信号を送信する（ステップＳ９１８）。つぎに、予備サーバ１３０が、ステップＳ９１８によって送信された要求信号に応じて応答信号を監視端末１２１へ送信する（ステップＳ９１９）。ステップＳ９１９によって送信される応答信号には、サーバ装置１１０から受信して記憶しているイベント情報が含まれる。サーバ装置１１０から受信して記憶しているイベント情報には、たとえば障害イベントＥ２，Ｅ３を示すイベント情報が含まれる。
【０１０４】
つぎに、ステップＳ９１３において監視端末１２１が設定した３０［ｓ］のタイマが満了したとする。監視端末１２１は、ステップＳ９１３によって送信されたクリエイタパケットに基づいて、要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９２０）。つぎに、ステップＳ９１４において監視端末１２２が設定した３０［ｓ］のタイマが満了したとする。監視端末１２２は、ステップＳ９１４によって送信されたクリエイタパケットに基づいて、要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９２１）。
【０１０５】
このように、実施の形態にかかる通信システム１００においては、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ状態情報を要求する要求信号の送信方式をサーバ装置１１０の負荷状態に応じて決定する。そして、決定した送信方式をサーバ装置１１０から各監視端末へ通知することで、各監視端末によるサーバ装置１１０の監視を効率よく行うことができる。
【０１０６】
具体的には、サーバ装置１１０の負荷が比較的大きい場合は、たとえば次回要求起動時間Ｔを比較的長く設定したポーリング方式を用いることで、監視によるサーバ装置１１０の負荷を軽減することができる。これにより、たとえばサーバ装置１１０が通信不能と判断されたりして、正確な監視ができなくなることを回避することができる。
【０１０７】
また、サーバ装置１１０の負荷が比較的小さい場合は、たとえばロングポーリング方式やチャンク方式を用いることで、監視のリアルタイム性を向上させることができる。また、サーバ装置１１０の負荷が比較的小さい場合は、次回要求起動時間Ｔを比較的短く設定したポーリング方式を用いてもよい。この場合も、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが短くなり、監視のリアルタイム性を向上させることができる。
【０１０８】
たとえば、サーバ装置１１０を無線基地局に適用すれば、無線基地局の負荷の増大を抑えつつ、無線基地局の状態を遠隔監視することができる。これにより、無線基地局による移動局の呼などの処理に与える影響を抑えつつ、無線基地局の状態を遠隔監視して保守を行うことができる。
【０１０９】
以上説明したように、通信装置、通信システムおよび状態監視方法によれば、通信装置の監視を効率よく行うことができる。上述した実施の形態に関し、さらに以下の付記を開示する。
【０１１０】
（付記１）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、
自装置の負荷状態を示す負荷情報を取得する負荷取得部と、
前記負荷取得部によって取得された負荷情報に基づいて前記要求信号の送信方式を決定する決定部と、
前記決定部によって決定された送信方式を前記監視端末へ通知する通知部と、
を備えることを特徴とする通信装置。
【０１１１】
（付記２）前記通知部によって通知された送信方式によって前記監視端末から送信された前記要求信号を受信する受信部と、
前記受信部によって受信された要求信号に応じて前記状態情報を前記監視端末へ送信する送信部と、
を備えることを特徴とする付記１に記載の通信装置。
【０１１２】
（付記３）前記決定部は、前記監視端末の種別および前記負荷情報に基づいて前記送信方式を決定することを特徴とする付記１または２に記載の通信装置。
【０１１３】
（付記４）前記送信部は、前記負荷情報が示す負荷量が閾値を超えた場合に前記状態情報を他の通信装置へ送信し、
前記通知部は、前記負荷量が閾値を超えた場合に、前記状態情報の要求先を前記他の通信装置に切り替える旨の情報と、前記他の通信装置のアドレスと、を前記監視端末へ通知することを特徴とする付記２に記載の通信装置。
【０１１４】
（付記５）前記負荷情報と前記送信方式とを対応付けるテーブルを記憶する記憶部を備え、
前記決定部は、前記記憶部によって記憶されたテーブルと前記負荷情報とに基づいて前記送信方式を決定することを特徴とする付記１〜４のいずれか一つに記載の通信装置。
【０１１５】
（付記６）前記テーブルは、大きな負荷量を示す負荷情報ほど、自装置の負荷が小さい送信方式を対応付けていることを特徴とする付記５に記載の通信装置。
【０１１６】
（付記７）前記決定部は、自装置へ前記要求信号を送信する間隔を含む前記送信方式を決定することを特徴とする付記１〜６のいずれか一つに記載の通信装置。
【０１１７】
（付記８）前記決定部は、自装置へ前記要求信号を送信するためのコネクションを、前記要求信号の送信ごとに切断するか否かを含む前記送信方式を決定することを特徴とする付記１〜７のいずれか一つに記載の通信装置。
【０１１８】
（付記９）前記決定部は、自装置へ前記要求信号を送信する回数を含む前記送信方式を決定することを特徴とする付記１〜８のいずれか一つに記載の通信装置。
【０１１９】
（付記１０）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置であって、自装置の負荷状態に基づいて前記要求信号の送信方式を決定し、決定した送信方式を前記監視端末へ通知する通信装置と、
前記通信装置によって通知された送信方式によって前記通信装置へ前記要求信号を送信し、送信した要求信号に応じて前記通信装置から送信された前記状態情報を受信する監視端末と、
を含むことを特徴とする通信システム。
【０１２０】
（付記１１）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置が、自装置の負荷状態に基づいて前記要求信号の送信方式を決定する決定工程と、
前記通信装置が、前記決定工程によって決定された送信方式を前記監視端末へ通知する通知工程と、
前記監視端末が、前記通知工程によって通知された送信方式によって前記通信装置へ前記要求信号を送信する第一送信工程と、
前記通信装置が、前記第一送信工程によって送信された要求信号に応じて前記監視端末へ前記状態情報を送信する第二送信工程と、
を含むことを特徴とする状態監視方法。
【符号の説明】
【０１２１】
１０ ネットワーク
１００ 通信システム
１１０ サーバ装置
１２１，１２２ 監視端末
１２３ 中央監視端末
１３０ 予備サーバ
２００ 決定テーブル
Ｅ１〜Ｅ３ 障害イベント
【技術分野】
【０００１】
本発明は、通信を行う通信装置、通信システムおよび状態監視方法に関する。
【背景技術】
【０００２】
近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）の無線基地局のＯ＆Ｍ（Ｏｐｅｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ：保守監視）機構のように、通信装置の遠隔監視が検討されている。遠隔監視システムには、たとえばシンクライアント（Ｔｈｉｎ ｃｌｉｅｎｔ）方式が採用される。シンクライアント方式では、監視端末であるクライアントに最小限の処理をさせ、監視対象であるサーバにより多くの処理を集中させるため、監視端末のソフトウェアがメンテナンスフリーになり保守性が向上する。
【０００３】
また、近年の無線通信の高速化に伴って、一つの無線基地局でカバーできる範囲が小さくなってきているため、無線基地局の設置台数が増大している。このため、無線基地局を監視する監視端末の数も増大する。このため、無線基地局を監視する監視端末の数も増大する。これに対して、遠隔監視システムにシンクライアント方式を採用することで、多くの無線基地局を低コストで監視することが検討されている。
【０００４】
遠隔監視システムにシンクライアント方式を採用する場合は、クライアントである監視端末の主導によるアクセスとなるため、監視対象のサーバ装置の状態をリアルタイムに監視することができない。また、サーバ装置の状態を監視するためにログインする監視端末の数に比例して、サーバ装置で動作するＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）や処理プロセスにより、サーバ装置のメモリやＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の使用率が大きくなる。
【０００５】
これに対して、監視対象のサーバ装置の状態を監視する方式として、ポーリング（Ｐｏｌｌｉｎｇ）方式、ロングポーリング（Ｌｏｎｇ Ｐｏｌｌｉｎｇ）方式、チャンク（Ｃｈｕｎｋ）方式などがある。ポーリング方式においては、クライアントである監視端末が、監視対象のサーバ装置に障害イベントの有無を定期的に問い合わせる（ポーリング）。
【０００６】
ロングポーリング方式においては、クライアントである監視端末が、障害イベントの問い合わせ（ポーリング）を、サーバ装置が通知するタイミングまで待機する。チャンク方式においては、監視端末からサーバ装置へのリクエスト信号で確立されるコネクションを維持しながら、サーバ装置が監視端末へ障害イベントを通知する。
【０００７】
また、サーバ装置が監視端末の状態情報を入手し、監視端末の処理負荷に応じてレスポンスを送信する周期をスケジューリングする方法が知られている（たとえば、下記特許文献１参照。）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００６−１５５５０５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、サーバ装置の監視における適切な方式は、サーバ装置の監視を行う監視端末の数や監視端末の優先度などによって異なる。このため、上述した従来技術では、監視端末によるサーバ装置の監視を効率よく行うことができないという問題がある。
【００１０】
たとえば、ポーリング方式においては、監視端末による要求信号の送信（ポーリング）の間隔が長いと、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが長くなりリアルタイム性が損なわれる。また、要求信号の送信の間隔が短いと、障害イベントの有無に関係なくサーバ装置やネットワークの負荷が大きくなる。
【００１１】
また、ロングポーリング方式やチャンク方式においては、サーバ装置やネットワークの負荷が大きくなりやすいため、一時的に多数の監視端末がサーバ装置の監視を行うと、サーバ装置が通信不能になることがある。この場合は、たとえば、監視端末においてサーバ装置がダウンしたと判断される場合もある。
【００１２】
開示の通信装置、通信システムおよび状態監視方法は、上述した問題点を解消するものであり、通信装置の監視を効率よく行うことを目的とする。
【課題を解決するための手段】
【００１３】
上述した課題を解決し、目的を達成するため、開示技術は、監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、自装置の負荷状態を示す負荷情報を取得し、取得された負荷情報に基づいて前記要求信号の送信方式を決定し、決定された送信方式を前記監視端末へ通知する。
【発明の効果】
【００１４】
開示の通信装置、通信システムおよび状態監視方法によれば、通信装置の監視を効率よく行うことができる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態にかかる通信システムを示す図である。
【図２】送信方式の決定テーブルの一例を示す図である。
【図３】制御部の動作の一例を示すフローチャートである。
【図４】輻輳状態における送信方式の通知処理の一例を示すフローチャートである。
【図５】非輻輳状態における送信方式の通知処理の一例を示すフローチャートである。
【図６】ポーリング方式による監視動作を示すシーケンス図である。
【図７】ロングポーリング方式による監視動作を示すシーケンス図である。
【図８】チャンク方式による監視動作を示すシーケンス図である。
【図９】通信システムの動作の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１６】
以下に図面を参照して、開示技術の好適な実施の形態を詳細に説明する。開示技術は、監視端末がサーバ装置へ状態情報を要求する要求信号の送信方式をサーバ装置の負荷状態に応じて決定し、決定した送信方式をサーバ装置から監視端末へ通知することで、監視端末によるサーバ装置の監視を効率よく行う。
【００１７】
（実施の形態）
図１は、実施の形態にかかる通信システムを示す図である。図１に示すように、実施の形態にかかる通信システム１００は、サーバ装置１１０と、監視端末１２１，１２２と、中央監視端末１２３と、予備サーバ１３０と、を含んでいる。通信システム１００においては、サーバ装置１１０を監視対象とし、クライアントである監視端末１２１，１２２および中央監視端末１２３によってサーバ装置１１０の状態を監視する。
【００１８】
サーバ装置１１０（通信装置）は、たとえば、移動局との間で無線通信を行う無線基地局である。無線基地局は、たとえばＬＴＥのｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）である。サーバ装置１１０は、自装置をサーバ、監視端末１２１，１２２および中央監視端末１２３をクライアントとして、たとえばＷｅｂサーバ−クライアント方式によるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信を行う。
【００１９】
サーバ装置１１０は、監視端末１２１，１２２および中央監視端末１２３から送信された要求信号に応じて、自装置の状態を示す状態情報を監視端末１２１，１２２および中央監視端末１２３へ送信する。具体的には、サーバ装置１１０は、装置状態管理部１１１と、ユーザ管理部１１２と、リソース管理部１１３と、制御部１１４と、通信インターフェース１１５と、を備えている。
【００２０】
装置状態管理部１１１は、サーバ装置１１０（自装置）の状態を示す状態情報を取得する。ここでは、サーバ装置１１０の状態を示す状態情報として、サーバ装置１１０の障害に関する情報を一例として説明する。具体的には、装置状態管理部１１１は、障害の発生や障害からの復旧などの障害イベントが発生すると、発生した障害イベントを示すイベント情報を制御部１１４へ出力する。
【００２１】
ユーザ管理部１１２は、サーバ装置１１０がサービスを提供しているユーザに関する情報（たとえばユーザの数）を管理する。たとえば、ユーザ管理部１１２は、サーバ装置１１０にログインしている監視端末（たとえば監視端末１２１，１２２および中央監視端末１２３）の情報を管理する。また、ユーザ管理部１１２は、サーバ装置１１０にログインしている監視端末の優先度の情報を管理する。たとえばユーザ管理部１１２は、監視端末のサーバ装置１１０へのログイン時に、監視端末の種別に応じて優先度を設定する。たとえば、中央監視端末１２３は、監視端末１２１，１２２より高い優先度が設定される。
【００２２】
リソース管理部１１３は、サーバ装置１１０の負荷状態を示す負荷情報を取得する負荷取得部である。負荷情報は、たとえば、ソフトウェアによる処理がサーバ装置１１０のＣＰＵを占有している時間の割合を示すＣＰＵ使用率や、サーバ装置１１０において処理待ちになっているイベントの数を示すイベント滞留Ｑ（キュー）数などである。また、負荷情報は、サーバ装置１１０のメモリ使用率や通信量などであってもよい。リソース管理部１１３は、取得した負荷情報を制御部１１４へ出力する。
【００２３】
制御部１１４は、リソース管理部１１３から出力された負荷情報に基づいて、監視端末１２１，１２２および中央監視端末１２３による要求信号の送信方式を決定（スケジューリング）する決定部である。送信方式には、たとえば、次要求起動時間、要求回数、コネクション状態などがパラメータとして含まれる。
【００２４】
次要求起動時間は、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ要求信号を送信する間隔を示すパラメータである。要求回数は、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ要求信号を送信する回数を示すパラメータである。コネクション状態は、要求信号を送信するためのコネクションを、要求信号の送信ごとに切断するか否かを示すパラメータである。
【００２５】
たとえば、サーバ装置１１０のメモリ（記憶部）には、負荷情報と送信方式を対応付ける決定テーブル（たとえば図２参照）が記憶されている。制御部１１４は、サーバ装置１１０のメモリに記憶された決定テーブルと、リソース管理部１１３から出力された負荷情報と、に基づいて送信方式を決定する。または、サーバ装置１１０のメモリ（記憶部）には、負荷情報から送信方式の各パラメータを算出する算出式が記憶されていてもよい。この場合は、制御部１１４は、サーバ装置１１０のメモリに記憶された算出式と、リソース管理部１１３から出力された負荷情報と、に基づいて送信方式を決定する。
【００２６】
また、制御部１１４は、決定した送信方式を監視端末１２１，１２２および中央監視端末１２３へ通知する通知部である。具体的には、制御部１１４は、決定した送信方式を示すクリエイタパケットを、通信インターフェース１１５を介して監視端末１２１，１２２および中央監視端末１２３へ送信する。
【００２７】
また、制御部１１４は、通知した送信方式によって監視端末１２１，１２２および中央監視端末１２３から送信された要求信号を、通信インターフェース１１５を介して受信する受信部である。たとえば、制御部１１４は、ＨＴＴＰリクエストとして送信された要求信号を受信する。また、制御部１１４は、受信した要求信号に応じて、装置状態管理部１１１から出力されたイベント情報を、通信インターフェース１１５を介して監視端末１２１，１２２および中央監視端末１２３へ送信する送信部である。たとえば、制御部１１４は、ＨＴＴＰレスポンスとしてイベント情報を送信する。
【００２８】
制御部１１４は、たとえば、受信した要求信号に対して送信するイベント情報とともに、以降の要求信号の送信方式を示すクリエイタパケットを送信する。または、制御部１１４は、イベント情報とは別にクリエイタパケットを任意のタイミングで送信してもよい。制御部１１４は、クリエイタパケットを監視端末１２１，１２２および中央監視端末１２３へ送信することで、監視端末１２１，１２２および中央監視端末１２３に対して、制御部１１４が決定した送信方法によって要求信号を送信させることができる。
【００２９】
また、制御部１１４は、負荷情報が示す負荷量が閾値を超えた場合（輻輳状態）に、予備サーバ１３０を介してイベント情報を中央監視端末１２３へ送信することで、イベント情報を予備サーバ１３０に記憶させる。これにより、サーバ装置１１０が輻輳状態であっても、中央監視端末１２３に対してはイベント情報を送信し、中央監視端末１２３によるサーバ装置１１０の監視のリアルタイム性を維持することができる。
【００３０】
また、制御部１１４は、負荷情報が示す負荷量が閾値を超えた場合に、非常ビット（ＯＮ）と予備サーバ１３０のアドレスとを含むクリエイタパケットを監視端末１２１，１２２へ送信する。非常ビット（ＯＮ）は、サーバ装置１１０が輻輳状態でありイベント情報の要求先をサーバ装置１１０から予備サーバ１３０へ切り替えることを示す情報である。
【００３１】
これにより、サーバ装置１１０が輻輳状態の場合に、監視端末１２１，１２２からの要求信号に対するイベント情報の送信を予備サーバ１３０に代行させ、サーバ装置１１０の負荷を軽減することができる。
【００３２】
通信インターフェース１１５は、ネットワーク１０を介して、監視端末１２１，１２２、中央監視端末１２３および予備サーバ１３０との間で通信を行うインターフェースである。たとえば、ネットワーク１０は有線のネットワークであり、通信インターフェース１１５は有線による通信を行う。
【００３３】
監視端末１２１，１２２および中央監視端末１２３のそれぞれは、サーバ装置１１０によって通知された送信方式によってサーバ装置１１０へ要求信号を送信する監視端末である。また、監視端末１２１，１２２および中央監視端末１２３のそれぞれは、送信した要求信号に応じてサーバ装置１１０によって送信されたイベント情報を受信する。監視端末１２１，１２２のそれぞれは、受信したイベント情報をユーザへ出力する。
【００３４】
また、監視端末１２１，１２２のそれぞれは、サーバ装置１１０から非常ビット（ＯＮ）および予備サーバ１３０のアドレスを含むクリエイタパケットを受信すると、サーバ装置１１０が輻輳状態である旨をユーザへ表示する。また、監視端末１２１，１２２のそれぞれは、クリエイタパケットに含まれる次要求起動時間が０［ｍｓ］より長い場合は、次要求起動時間が経過するまでサーバ装置１１０に対する要求信号の送信を行わない。
【００３５】
また、監視端末１２１，１２２のそれぞれは、サーバ装置１１０に対する要求信号の送信を行わない期間において、サーバ装置１１０のイベント情報を要求する要求信号を予備サーバ１３０へ送信してもよい。具体的には、監視端末１２１，１２２のそれぞれは、クリエイタパケットに含まれる予備サーバ１３０のアドレスを用いて要求信号を予備サーバ１３０へ送信する。これにより、輻輳状態のサーバ装置１１０に負荷をかけずに、サーバ装置１１０のイベント情報を予備サーバ１３０から受信することができる。
【００３６】
予備サーバ１３０は、中央監視端末１２３を宛先とするイベント情報をサーバ装置１１０から受信すると、受信したイベント情報を中央監視端末１２３へ転送するとともに、受信したイベント情報を記憶する。また、予備サーバ１３０は、サーバ装置１１０のイベント情報を要求する要求信号を監視端末１２１，１２２から受信すると、記憶しておいたイベント情報を監視端末１２１，１２２へ送信する。これにより、予備サーバ１３０は、サーバ装置１１０が輻輳状態の場合に、監視端末１２１，１２２からの要求信号に対するイベント情報の送信を代行することができる。
【００３７】
図２は、送信方式の決定テーブルの一例を示す図である。サーバ装置１１０は、たとえば決定テーブル２００を自装置のメモリ（記憶部）に記憶している。決定テーブル２００においては、サーバ装置１１０の負荷状態を示すＣＰＵ使用率とイベント滞留Ｑ数の組み合わせごとに、要求信号の送信方式が対応付けられている。
【００３８】
ここでは、ＣＰＵ使用率は、「高」「中」「低」の３つの範囲に分けられている。たとえば、制御部１１４は、ＣＰＵ使用率が第一閾値より低ければＣＰＵ使用率を「低」と判断する。また、制御部１１４は、ＣＰＵ使用率が第二閾値（＞第一閾値）より高ければＣＰＵ使用率を「高」と判断する。また、制御部１１４は、ＣＰＵ使用率が第一閾値以上かつ第二閾値以下の範囲であればＣＰＵ使用率を「中」と判断する。
【００３９】
また、イベント滞留Ｑ数は、「多」「中」「少」の各範囲に分けられている。たとえば、制御部１１４は、イベント滞留Ｑ数が第三閾値より低ければイベント滞留Ｑ数を「少」と判断する。また、制御部１１４は、イベント滞留Ｑ数が第四閾値（＞第三閾値）より高ければイベント滞留Ｑ数を「多」と判断する。また、制御部１１４は、イベント滞留Ｑ数が第三閾値以上かつ第四閾値以下の範囲であればイベント滞留Ｑ数を「中」と判断する。
【００４０】
たとえば、決定テーブル２００において、ＣＰＵ使用率「高」とイベント滞留Ｑ数「多」の組み合わせには送信方式１が対応付けられている。送信方式１は、次回要求起動時間Ｔが３０［ｓ］、要求回数ＲＮが１０、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式１はポーリング方式になる。また、送信方式１には、非常ビットと、予備サーバ１３０のアドレスを示すＤＢ−ＩＰと、が対応付けられている。
【００４１】
また、決定テーブル２００において、ＣＰＵ使用率「高」とイベント滞留Ｑ数「少」の組み合わせには送信方式３が対応付けられている。送信方式３は、次回要求起動時間Ｔが３０［ｓ］、要求回数ＲＮが１、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式３はポーリング方式になる。また、送信方式３には、非常ビットと、予備サーバ１３０のアドレスを示すＤＢ−ＩＰと、が対応付けられている。
【００４２】
また、決定テーブル２００において、ＣＰＵ使用率「低」とイベント滞留Ｑ数「多」の組み合わせには送信方式７が対応付けられている。送信方式７は、次回要求起動時間Ｔが０［ｍｓ］、要求回数ＲＮが１０、コネクション状態ＣＳが「継続」である方式である。したがって、送信方式７はチャンク方式になる。
【００４３】
また、決定テーブル２００において、ＣＰＵ使用率「低」とイベント滞留Ｑ数「少」の組み合わせには送信方式９が対応付けられている。送信方式９は、次回要求起動時間Ｔが０［ｍｓ］、要求回数ＲＮが１、コネクション状態ＣＳが「切断」である方式である。したがって、送信方式９はロングポーリング方式になる。
【００４４】
制御部１１４は、ＣＰＵ使用率とイベント滞留Ｑ数をリソース管理部１１３から取得し、取得したＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに対応する送信方式を決定テーブル２００から選択する。これにより、サーバ装置１１０の負荷情報に基づいて送信方式を決定することができる。制御部１１４は、決定した送信方式を示すクリエイタパケットを監視端末１２１，１２２および中央監視端末１２３へ送信する。
【００４５】
また、制御部１１４は、送信方式を決定する対象の監視端末の種別およびサーバ装置１１０の負荷情報に基づいて送信方式を決定してもよい。たとえば、サーバ装置１１０は、送信方式を決定する対象の監視端末の種別ごとに異なる決定テーブル２００をメモリに記憶する。そして、制御部１１４は、取得したＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに対応する送信方式を、送信方式を決定する対象の監視端末の種別に対応する決定テーブル２００から選択する。これにより、送信方式を決定する対象の監視端末の種別およびサーバ装置１１０の負荷情報に基づいて送信方式を決定することができる。
【００４６】
また、制御部１１４は、送信方式を決定する対象の監視端末の種別が特定の種別である場合（たとえば中央監視端末１２３）は、決定テーブル２００によらず、あらかじめ記憶しておいた特定の送信方式を選択するようにしてもよい。たとえば、中央監視端末１２３についてはロングポーリング方式またはチャンク方式を選択することで、中央監視端末１２３によるサーバ装置１１０の監視のリアルタイム性を向上させることができる。
【００４７】
このように、決定テーブル２００においては、大きな負荷量を示す負荷情報ほど、サーバ装置１１０の負荷量が小さい送信方式が対応付けられている。これにより、制御部１１４は、サーバ装置１１０の負荷量が大きいほど、サーバ装置１１０の負荷量が小さい送信方式を選択することができる。このため、サーバ装置１１０の負荷量が大きい場合にサーバ装置１１０の負荷を低減することができる。
【００４８】
一方、決定テーブル２００においては、小さな負荷量を示す負荷情報ほど、監視のリアルタイム性（即時性）が高い送信方式が対応付けられている。これにより、制御部１１４は、サーバ装置１１０の負荷量が小さいほど、監視のリアルタイム性が高い送信方式を選択することができる。このため、サーバ装置１１０の負荷量が小さい場合に監視のリアルタイム性を向上させることができる。
【００４９】
ただし、決定テーブル２００における負荷情報と送信方式の関係はこれに限らず、各方式の特性やサーバ装置１１０の適用先に応じて柔軟に設定することができる。なお、ここではＣＰＵ使用率とイベント滞留Ｑ数の組み合わせに基づいて送信方式を決定する方法について説明したが、送信方式を決定する方法についてはこれに限らない。たとえば、ＣＰＵ使用率またはイベント滞留Ｑ数に基づいて送信方式を決定してもよい。また、ＣＰＵ使用率やイベント滞留Ｑ数の他に、サーバ装置１１０のメモリ使用率や通信量などに基づいて送信方式を決定してもよい。
【００５０】
図３は、制御部の動作の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、たとえば以下の各ステップを実行する。まず、装置状態管理部１１１からの出力に基づいて障害イベントが発生したか否かを判断し（ステップＳ３０１）、障害イベントが発生するまで待つ（ステップＳ３０１：Ｎｏのループ）。障害イベントが発生すると（ステップＳ３０１：Ｙｅｓ）、自装置のＣＰＵ使用率およびイベント滞留Ｑ数をリソース管理部１１３から取得する（ステップＳ３０２）。
【００５１】
つぎに、ステップＳ３０２によって取得されたＣＰＵ使用率が「高」であるか否かを判断する（ステップＳ３０３）。取得されたＣＰＵ使用率が「高」である場合（ステップＳ３０３：Ｙｅｓ）は、輻輳状態における送信方式の通知処理（たとえば図４参照）を実行し（ステップＳ３０４）、一連の動作を終了する。取得されたＣＰＵ使用率が「中」または「低」である場合（ステップＳ３０３：Ｎｏ）は、非輻輳状態における送信方式の通知処理（たとえば図５参照）を実行し（ステップＳ３０５）、一連の動作を終了する。
【００５２】
図４は、輻輳状態における送信方式の通知処理の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、図３のステップＳ３０４に示した輻輳状態における送信方式の通知処理として、サーバ装置１１０にログインしている監視端末ごとに、たとえば以下の各ステップを実行する。なお、サーバ装置１１０にログインしている監視端末は、ここでは監視端末１２１，１２２および中央監視端末１２３であるとする。
【００５３】
まず、対象の監視端末が中央監視端末１２３であるか否かを判断する（ステップＳ４０１）。対象の監視端末が中央監視端末１２３である場合（ステップＳ４０１：Ｙｅｓ）は、図３のステップＳ３０２によって取得されたイベント滞留Ｑ数が「多」であるか否かを判断する（ステップＳ４０２）。イベント滞留Ｑ数が「多」である場合（ステップＳ４０２：Ｙｅｓ）は、決定テーブル２００から送信方式７を選択し（ステップＳ４０３）、ステップＳ４０７へ移行する。
【００５４】
ステップＳ４０２において、イベント滞留Ｑ数が「多」でない場合（ステップＳ４０２：Ｎｏ）は、イベント滞留Ｑ数が「中」であるか否かを判断する（ステップＳ４０４）。イベント滞留Ｑ数が「中」である場合（ステップＳ４０４：Ｙｅｓ）は、決定テーブル２００から送信方式８を選択し（ステップＳ４０５）、ステップＳ４０７へ移行する。
【００５５】
ステップＳ４０４において、イベント滞留Ｑ数が「少」である場合（ステップＳ４０４：Ｎｏ）は、決定テーブル２００から送信方式９を選択する（ステップＳ４０６）。つぎに、イベント情報と、ステップＳ４０３，Ｓ４０５，Ｓ４０６のいずれかによって選択された送信方式を示すクリエイタパケットと、を予備サーバ１３０へ送信し（ステップＳ４０７）、一連の動作を終了する。ステップＳ４０７によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。
【００５６】
ステップＳ４０１において、対象の監視端末が監視端末１２１，１２２のいずれかである場合（ステップＳ４０１：Ｎｏ）は、サーバ装置１１０のメモリに記憶されている非常ビットがＯＮか否かを判断する（ステップＳ４０８）。非常ビットがＯＮである場合（ステップＳ４０８：Ｙｅｓ）は、一連の動作を終了する。これにより、サーバ装置１１０の輻輳状態が継続している場合は、監視端末１２１，１２２に対する応答を行わずにサーバ装置１１０の負荷を軽減することができる。
【００５７】
ステップＳ４０８において非常ビットがＯＦＦである場合（ステップＳ４０８：Ｎｏ）は、非常ビットをＯＮにする（ステップＳ４０９）。つぎに、図３のステップＳ３０２によって取得されたイベント滞留Ｑ数が「多」であるか否かを判断する（ステップＳ４１０）。イベント滞留Ｑ数が「多」である場合（ステップＳ４１０：Ｙｅｓ）は、決定テーブル２００から送信方式１を選択し（ステップＳ４１１）、ステップＳ４１５へ移行する。
【００５８】
ステップＳ４１０において、イベント滞留Ｑ数が「多」でない場合（ステップＳ４１０：Ｎｏ）は、イベント滞留Ｑ数が「中」であるか否かを判断する（ステップＳ４１２）。イベント滞留Ｑ数が「中」である場合（ステップＳ４１２：Ｙｅｓ）は、決定テーブル２００から送信方式２を選択し（ステップＳ４１３）、ステップＳ４１５へ移行する。
【００５９】
ステップＳ４１２において、イベント滞留Ｑ数が「少」である場合（ステップＳ４１２：Ｎｏ）は、決定テーブル２００から送信方式３を選択し（ステップＳ４１４）、ステップＳ４１５へ移行する。つぎに、ステップＳ４１１，Ｓ４１３，Ｓ４１４のいずれかによって選択された送信方式を示すクリエイタパケットを対象の監視端末へ送信し（ステップＳ４１５）、一連の動作を終了する。
【００６０】
ステップＳ４１５によって送信されるクリエイタパケットには、ステップＳ４０９によってＯＮにされた非常ビットおよび予備サーバ１３０のアドレスが含まれる（たとえば図２参照）。これにより、監視端末１２１，１２２に対して、サーバ装置１１０のイベント情報の要求先をサーバ装置１１０から予備サーバ１３０に切り替えさせることができる。
【００６１】
図５は、非輻輳状態における送信方式の通知処理の一例を示すフローチャートである。サーバ装置１１０の制御部１１４は、図３のステップＳ３０５に示した非輻輳状態における送信方式の通知処理として、サーバ装置１１０にログインしている監視端末ごとに、たとえば以下の各ステップを実行する。なお、サーバ装置１１０にログインしている監視端末は、たとえば監視端末１２１，１２２および中央監視端末１２３である。
【００６２】
図５に示すステップＳ５０１〜Ｓ５０６は、図４に示したステップＳ４０１〜Ｓ４０６と同様であるため説明を省略する。ステップＳ５０３，Ｓ５０５，Ｓ５０６のいずれかのつぎに、イベント情報とクリエイタパケットを中央監視端末１２３へ送信し（ステップＳ５０７）、一連の動作を終了する。ステップＳ５０７によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。ステップＳ５０７によって送信されるクリエイタパケットは、ステップＳ５０３，Ｓ５０５，Ｓ５０６のいずれかによって選択された送信方式を示すクリエイタパケットである。
【００６３】
ステップＳ５０１において対象の監視端末が監視端末１２１，１２２のいずれかである場合（ステップＳ５０１：Ｎｏ）は、サーバ装置１１０のメモリに記憶されている非常ビットがＯＮであるか否かを判断する（ステップＳ５０８）。非常ビットがＯＦＦである場合（ステップＳ５０８：Ｎｏ）はステップＳ５１０へ移行する。非常ビットがＯＮである場合（ステップＳ５０８：Ｙｅｓ）は非常ビットをＯＦＦにする（ステップＳ５０９）。
【００６４】
図５に示すステップＳ５１０〜Ｓ５１４は、図４に示したステップＳ４１０〜Ｓ４１４と同様であるため説明を省略する。ただし、ステップＳ５１１において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式４を選択し、ＣＰＵ使用率が「低」である場合は送信方式７を選択する。
【００６５】
また、ステップＳ５１３において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式５を選択し、ＣＰＵ使用率が「低」である場合は送信方式８を選択する。また、ステップＳ５１４において、図３のステップＳ３０２により取得されたＣＰＵ使用率が「中」である場合は決定テーブル２００から送信方式６を選択し、ＣＰＵ使用率が「低」である場合は送信方式９を選択する。
【００６６】
ステップＳ５１１，Ｓ５１３，Ｓ５１４のいずれかのつぎに、イベント情報とクリエイタパケットを対象の監視端末へ送信し（ステップＳ５１５）、一連の動作を終了する。ステップＳ５１５によって送信されるイベント情報は、図３のステップＳ３０１において発生した障害イベントを示すイベント情報である。ステップＳ５１５によって送信されるクリエイタパケットは、ステップＳ５１１，Ｓ５１３，Ｓ５１４のいずれかによって選択された送信方式を示すクリエイタパケットである。
【００６７】
図３〜図５に示した動作を繰り返し実行することで、サーバ装置１１０は、障害イベントが発生するごとに、発生した障害イベントを示すイベント情報を各監視端末へ送信することができる。また、サーバ装置１１０は、イベント情報の送信とともに、自装置の負荷状態に基づいて決定した送信方式を各監視端末へ通知することができる。
【００６８】
また、サーバ装置１１０は、自装置が輻輳状態である場合には、監視端末１２１，１２２からの要求信号に対する応答を予備サーバ１３０に代行させることができる。ただし、サーバ装置１１０は、中央監視端末１２３からの要求信号に対する応答は継続することで、中央監視端末１２３による監視のリアルタイム性を維持することができる。
【００６９】
図６は、ポーリング方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。ポーリング方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ６０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７０】
このとき、サーバ装置１１０の装置状態管理部１１１から制御部１１４へイベント情報１が出力されているとする。サーバ装置１１０の制御部１１４は、ステップＳ６０１によって送信された要求信号に応じて、装置状態管理部１１１から出力されたイベント情報１を監視端末１２１へ送信する（ステップＳ６０２）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７１】
つぎに、監視端末１２１は、ステップＳ６０１によって要求信号を送信してから次回要求起動時間Ｔの経過後に、要求信号をサーバ装置１１０へ送信する（ステップＳ６０３）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７２】
このとき、サーバ装置１１０の装置状態管理部１１１から制御部１１４へイベント情報２が出力されているとする。サーバ装置１１０の制御部１１４は、ステップＳ６０３によって送信された要求信号に応じて、装置状態管理部１１１から出力されたイベント情報２を監視端末１２１へ送信する（ステップＳ６０４）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７３】
このように、ポーリング方式においては、所定のインターバルごとに監視端末１２１からサーバ装置１１０へ要求信号を発行し、監視端末１２１から要求信号が発行されるごとにサーバ装置１１０から監視端末１２１へイベント情報１を送信する。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０［ｍｓ］より大きくしてコネクション状態ＣＳを「切断」とすると、ポーリング方式となる。
【００７４】
ポーリング方式においては、監視端末による要求信号の送信（ポーリング）の間隔が長いと、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが長くなり、リアルタイム性が損なわれる。また、ポーリング方式において、監視端末による要求信号の送信の間隔が短いと、障害イベントの有無に関係なく負荷サーバ装置やネットワークの負荷が大きくなる。
【００７５】
図７は、ロングポーリング方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。ロングポーリング方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ７０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７６】
サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報１が出力されるのを待って、ステップＳ７０１によって送信された要求信号に応じて監視端末１２１へイベント情報１を送信する（ステップＳ７０２）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７７】
つぎに、監視端末１２１は、ステップＳ７０２によってイベント情報１を受信すると、要求信号をサーバ装置１１０へ送信（即時要求）する（ステップＳ７０３）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００７８】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報２が出力されるのを待って、ステップＳ７０３によって送信された要求信号に応じて監視端末１２１へイベント情報２を送信する（ステップＳ７０４）。これにより、監視端末１２１とサーバ装置１１０との間に確立されたコネクションが切断される。
【００７９】
このように、ロングポーリング方式においては、イベント情報の送信のためのコネクションを確立しておき、イベントが発生したときに、確立しておいたコネクションを用いてイベント情報を送信する。イベント情報を送信すると、コネクションが一旦切断され、監視端末１２１からサーバ装置１１０へ要求信号が再度発行される。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０としてコネクション状態ＣＳを「切断」とすると、ロングポーリング方式となる。
【００８０】
ロングポーリング方式においては、障害イベントが輻輳すると、イベント情報の送信のためのコネクションの接続および切断が頻繁に発生するため、サーバ装置の負荷が大きくなる。また、ロングポーリング方式においては、単位時間あたりの障害イベントに対してのスケーラビリティ（拡張性）が低い。
【００８１】
図８は、チャンク方式による監視動作を示すシーケンス図である。ここでは、監視端末１２１による監視動作について説明するが、監視端末１２２や中央監視端末１２３による監視動作についても同様である。チャンク方式においては、まず、監視端末１２１が、要求信号をサーバ装置１１０へ送信する（ステップＳ８０１）。これにより、監視端末１２１とサーバ装置１１０との間にコネクションが確立される。
【００８２】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報１が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報１を送信する（ステップＳ８０２）。制御部１１４は、イベント情報１を送信しても、監視端末１２１との間のコネクションを継続する。
【００８３】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報２が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報２を送信する（ステップＳ８０３）。制御部１１４は、イベント情報２を送信しても、監視端末１２１との間のコネクションを継続する。
【００８４】
つぎに、サーバ装置１１０の制御部１１４は、装置状態管理部１１１からイベント情報３が出力されるのを待って、ステップＳ８０１によって確立されたコネクションによって監視端末１２１へイベント情報３を送信する（ステップＳ８０４）。制御部１１４は、イベント情報３を送信しても、監視端末１２１との間のコネクションを継続する。
【００８５】
このように、チャンク方式においては、イベント情報の送信のためのコネクションを確立しておき、イベントが発生したときに、確立しておいたコネクションを用いてイベント情報を送信する。また、イベント情報を送信してもコネクションを継続し、監視端末１２１からサーバ装置１１０への要求信号の再度の発行は行わない。たとえば、サーバ装置１１０が送信するクリエイタパケットにおいて、次回要求起動時間Ｔを０としてコネクション状態ＣＳを「継続」とすると、チャンク方式となる。
【００８６】
チャンク方式においては、イベント情報を送信するためのコネクションが確立されたままになるため、障害イベントが発生していない場合は無駄な処理が発生する。また、イベント情報を送信するためのコネクションが切断されると、サーバ装置において障害イベントが発生しても監視端末にイベント情報を送信することができない。
【００８７】
図９は、通信システムの動作の一例を示すシーケンス図である。ここでは、期間Ｔ１においてはサーバ装置１１０が低負荷状態（たとえばＣＰＵ使用率が「低」かつイベント滞留Ｑ数が「少」）である。また、期間Ｔ１の後の期間Ｔ２においてはサーバ装置１１０が高負荷状態（たとえばＣＰＵ使用率が「高」かつイベント滞留Ｑ数が「多」）である。
【００８８】
また、期間Ｔ１においては、初期状態として、ロングポーリング方式による監視動作（たとえば図７参照）が行われているとする。まず、監視端末１２１，１２２および中央監視端末１２３が、サーバ装置１１０の状態情報を要求する要求信号（Ｒｅｑｕｅｓｔ）をサーバ装置１１０へ送信する（ステップＳ９０１〜Ｓ９０３）。つぎに、サーバ装置１１０において障害イベントＥ１が発生したとする。
【００８９】
つぎに、サーバ装置１１０が、ステップＳ９０１において中央監視端末１２３からの要求信号を受信しているため、応答信号（Ｒｅｓｐｏｎｓｅ）およびクリエイタパケット（Ｃｒｅａｔｏｒ）を中央監視端末１２３へ送信する（ステップＳ９０４）。ステップＳ９０４によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０４によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９０】
つぎに、中央監視端末１２３が、ステップＳ９０４によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０５）。また、中央監視端末１２３は、ステップＳ９０４によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９１】
つぎに、サーバ装置１１０が、ステップＳ９０２において監視端末１２１からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２１へ送信する（ステップＳ９０６）。ステップＳ９０６によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０６によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９２】
つぎに、監視端末１２１が、ステップＳ９０６によって受信したクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０７）。また、監視端末１２１は、ステップＳ９０６によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９３】
つぎに、サーバ装置１１０が、ステップＳ９０３において監視端末１２２からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２２へ送信する（ステップＳ９０８）。ステップＳ９０８によって送信される応答信号には、障害イベントＥ１を示すイベント情報が含まれている。また、期間Ｔ１においてはサーバ装置１１０が低負荷状態であるため、ステップＳ９０８によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。
【００９４】
つぎに、監視端末１２２が、ステップＳ９０８によって受信したクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信（即時要求）する（ステップＳ９０９）。また、監視端末１２２は、ステップＳ９０８によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９５】
つぎに、サーバ装置１１０において新たな障害イベントＥ２が発生したとする。つぎに、サーバ装置１１０が、ステップＳ９０５において中央監視端末１２３からの要求信号を受信しているため、応答信号およびクリエイタパケットを送信する（ステップＳ９１０）。ステップＳ９１０によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。ステップＳ９１０によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。また、期間Ｔ２においてはサーバ装置１１０が高負荷状態であり、かつイベント情報の要求元が中央監視端末１２３であるため、ステップＳ９１０において応答信号およびクリエイタパケットは予備サーバ１３０へ送信される。
【００９６】
つぎに、予備サーバ１３０が、ステップＳ９１０によって送信された応答信号およびクリエイタパケットを中央監視端末１２３へ転送する（ステップＳ９１１）。また、予備サーバ１３０は、ステップＳ９１０によって送信された応答信号に含まれるイベント情報を記憶しておく。つぎに、中央監視端末１２３が、ステップＳ９１１によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９１２）。また、中央監視端末１２３は、ステップＳ９１１によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【００９７】
つぎに、サーバ装置１１０が、ステップＳ９０７において監視端末１２１からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２１へ送信する（ステップＳ９１３）。ステップＳ９１３によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。
【００９８】
また、サーバ装置１１０が高負荷状態であるため、ステップＳ９１３によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：３０［ｓ］）、要求回数（ＲＮ：１）、非常ビット（ＯＮ）および予備サーバ１３０のアドレス（ＤＢ−ＩＰ）が含まれている。監視端末１２１は、ステップＳ９１３によって送信されたクリエイタパケット（Ｔ：３０［ｓ］）に基づいて３０［ｓ］のタイマを設定する。
【００９９】
つぎに、サーバ装置１１０が、ステップＳ９０９において監視端末１２２からの要求信号を受信しているため、応答信号およびクリエイタパケットを監視端末１２２へ送信する（ステップＳ９１４）。ステップＳ９１４によって送信される応答信号には、障害イベントＥ２を示すイベント情報が含まれている。
【０１００】
また、サーバ装置１１０が高負荷状態であるため、ステップＳ９１４によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：３０［ｓ］）、要求回数（ＲＮ：１）、非常ビット（ＯＮ）および予備サーバ１３０のアドレス（ＤＢ−ＩＰ）が含まれている。監視端末１２２は、ステップＳ９１４によって送信されたクリエイタパケット（Ｔ：３０［ｓ］）に基づいて３０［ｓ］のタイマを設定する。
【０１０１】
つぎに、サーバ装置１１０において新たな障害イベントＥ３が発生したとする。つぎに、サーバ装置１１０が、ステップＳ９１２において中央監視端末１２３からの要求信号を受信しているため、応答信号およびクリエイタパケットを送信する（ステップＳ９１５）。ステップＳ９１５によって送信される応答信号には、障害イベントＥ３を示すイベント情報が含まれている。ステップＳ９１５によって送信されるクリエイタパケットには、次要求起動時間（Ｔ：０［ｍｓ］）と要求回数（ＲＮ：１）とが含まれている。また、期間Ｔ２においてはサーバ装置１１０が高負荷状態であり、かつイベント情報の要求元が中央監視端末１２３であるため、ステップＳ９１５においてクリエイタパケットは予備サーバ１３０へ送信される。
【０１０２】
つぎに、予備サーバ１３０が、ステップＳ９１５によって送信された応答信号およびクリエイタパケットを中央監視端末１２３へ転送する（ステップＳ９１６）。また、予備サーバ１３０は、ステップＳ９１５によって送信された応答信号に含まれるイベント情報を記憶しておく。つぎに、中央監視端末１２３が、ステップＳ９１６によって送信されたクリエイタパケットに基づいて、待機時間なしで要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９１７）。また、中央監視端末１２３は、ステップＳ９１６によって送信されたイベント情報の処理（たとえばユーザへの表示）を行う。
【０１０３】
つぎに、監視端末１２１が、ステップＳ９１３によって受信したクリエイタパケットに非常ビット（ＯＮ）が含まれているため、クリエイタパケットに含まれるアドレスに基づいて予備サーバ１３０へ要求信号を送信する（ステップＳ９１８）。つぎに、予備サーバ１３０が、ステップＳ９１８によって送信された要求信号に応じて応答信号を監視端末１２１へ送信する（ステップＳ９１９）。ステップＳ９１９によって送信される応答信号には、サーバ装置１１０から受信して記憶しているイベント情報が含まれる。サーバ装置１１０から受信して記憶しているイベント情報には、たとえば障害イベントＥ２，Ｅ３を示すイベント情報が含まれる。
【０１０４】
つぎに、ステップＳ９１３において監視端末１２１が設定した３０［ｓ］のタイマが満了したとする。監視端末１２１は、ステップＳ９１３によって送信されたクリエイタパケットに基づいて、要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９２０）。つぎに、ステップＳ９１４において監視端末１２２が設定した３０［ｓ］のタイマが満了したとする。監視端末１２２は、ステップＳ９１４によって送信されたクリエイタパケットに基づいて、要求信号を１回、サーバ装置１１０へ送信する（ステップＳ９２１）。
【０１０５】
このように、実施の形態にかかる通信システム１００においては、監視端末１２１，１２２および中央監視端末１２３がサーバ装置１１０へ状態情報を要求する要求信号の送信方式をサーバ装置１１０の負荷状態に応じて決定する。そして、決定した送信方式をサーバ装置１１０から各監視端末へ通知することで、各監視端末によるサーバ装置１１０の監視を効率よく行うことができる。
【０１０６】
具体的には、サーバ装置１１０の負荷が比較的大きい場合は、たとえば次回要求起動時間Ｔを比較的長く設定したポーリング方式を用いることで、監視によるサーバ装置１１０の負荷を軽減することができる。これにより、たとえばサーバ装置１１０が通信不能と判断されたりして、正確な監視ができなくなることを回避することができる。
【０１０７】
また、サーバ装置１１０の負荷が比較的小さい場合は、たとえばロングポーリング方式やチャンク方式を用いることで、監視のリアルタイム性を向上させることができる。また、サーバ装置１１０の負荷が比較的小さい場合は、次回要求起動時間Ｔを比較的短く設定したポーリング方式を用いてもよい。この場合も、障害イベントが発生してからイベント情報が監視端末へ送信されるまでのタイムラグが短くなり、監視のリアルタイム性を向上させることができる。
【０１０８】
たとえば、サーバ装置１１０を無線基地局に適用すれば、無線基地局の負荷の増大を抑えつつ、無線基地局の状態を遠隔監視することができる。これにより、無線基地局による移動局の呼などの処理に与える影響を抑えつつ、無線基地局の状態を遠隔監視して保守を行うことができる。
【０１０９】
以上説明したように、通信装置、通信システムおよび状態監視方法によれば、通信装置の監視を効率よく行うことができる。上述した実施の形態に関し、さらに以下の付記を開示する。
【０１１０】
（付記１）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、
自装置の負荷状態を示す負荷情報を取得する負荷取得部と、
前記負荷取得部によって取得された負荷情報に基づいて前記要求信号の送信方式を決定する決定部と、
前記決定部によって決定された送信方式を前記監視端末へ通知する通知部と、
を備えることを特徴とする通信装置。
【０１１１】
（付記２）前記通知部によって通知された送信方式によって前記監視端末から送信された前記要求信号を受信する受信部と、
前記受信部によって受信された要求信号に応じて前記状態情報を前記監視端末へ送信する送信部と、
を備えることを特徴とする付記１に記載の通信装置。
【０１１２】
（付記３）前記決定部は、前記監視端末の種別および前記負荷情報に基づいて前記送信方式を決定することを特徴とする付記１または２に記載の通信装置。
【０１１３】
（付記４）前記送信部は、前記負荷情報が示す負荷量が閾値を超えた場合に前記状態情報を他の通信装置へ送信し、
前記通知部は、前記負荷量が閾値を超えた場合に、前記状態情報の要求先を前記他の通信装置に切り替える旨の情報と、前記他の通信装置のアドレスと、を前記監視端末へ通知することを特徴とする付記２に記載の通信装置。
【０１１４】
（付記５）前記負荷情報と前記送信方式とを対応付けるテーブルを記憶する記憶部を備え、
前記決定部は、前記記憶部によって記憶されたテーブルと前記負荷情報とに基づいて前記送信方式を決定することを特徴とする付記１〜４のいずれか一つに記載の通信装置。
【０１１５】
（付記６）前記テーブルは、大きな負荷量を示す負荷情報ほど、自装置の負荷が小さい送信方式を対応付けていることを特徴とする付記５に記載の通信装置。
【０１１６】
（付記７）前記決定部は、自装置へ前記要求信号を送信する間隔を含む前記送信方式を決定することを特徴とする付記１〜６のいずれか一つに記載の通信装置。
【０１１７】
（付記８）前記決定部は、自装置へ前記要求信号を送信するためのコネクションを、前記要求信号の送信ごとに切断するか否かを含む前記送信方式を決定することを特徴とする付記１〜７のいずれか一つに記載の通信装置。
【０１１８】
（付記９）前記決定部は、自装置へ前記要求信号を送信する回数を含む前記送信方式を決定することを特徴とする付記１〜８のいずれか一つに記載の通信装置。
【０１１９】
（付記１０）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置であって、自装置の負荷状態に基づいて前記要求信号の送信方式を決定し、決定した送信方式を前記監視端末へ通知する通信装置と、
前記通信装置によって通知された送信方式によって前記通信装置へ前記要求信号を送信し、送信した要求信号に応じて前記通信装置から送信された前記状態情報を受信する監視端末と、
を含むことを特徴とする通信システム。
【０１２０】
（付記１１）監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置が、自装置の負荷状態に基づいて前記要求信号の送信方式を決定する決定工程と、
前記通信装置が、前記決定工程によって決定された送信方式を前記監視端末へ通知する通知工程と、
前記監視端末が、前記通知工程によって通知された送信方式によって前記通信装置へ前記要求信号を送信する第一送信工程と、
前記通信装置が、前記第一送信工程によって送信された要求信号に応じて前記監視端末へ前記状態情報を送信する第二送信工程と、
を含むことを特徴とする状態監視方法。
【符号の説明】
【０１２１】
１０ ネットワーク
１００ 通信システム
１１０ サーバ装置
１２１，１２２ 監視端末
１２３ 中央監視端末
１３０ 予備サーバ
２００ 決定テーブル
Ｅ１〜Ｅ３ 障害イベント
【特許請求の範囲】
【請求項１】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、
自装置の負荷状態を示す負荷情報を取得する負荷取得部と、
前記負荷取得部によって取得された負荷情報に基づいて前記要求信号の送信方式を決定する決定部と、
前記決定部によって決定された送信方式を前記監視端末へ通知する通知部と、
を備えることを特徴とする通信装置。
【請求項２】
前記通知部によって通知された送信方式によって前記監視端末から送信された前記要求信号を受信する受信部と、
前記受信部によって受信された要求信号に応じて前記状態情報を前記監視端末へ送信する送信部と、
を備えることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記決定部は、前記監視端末の種別および前記負荷情報に基づいて前記送信方式を決定することを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記送信部は、前記負荷情報が示す負荷量が閾値を超えた場合に前記状態情報を他の通信装置へ送信し、
前記通知部は、前記負荷量が閾値を超えた場合に、前記状態情報の要求先を前記他の通信装置に切り替える旨の情報と、前記他の通信装置のアドレスと、を前記監視端末へ通知することを特徴とする請求項２に記載の通信装置。
【請求項５】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置であって、自装置の負荷状態に基づいて前記要求信号の送信方式を決定し、決定した送信方式を前記監視端末へ通知する通信装置と、
前記通信装置によって通知された送信方式によって前記通信装置へ前記要求信号を送信し、送信した要求信号に応じて前記通信装置から送信された前記状態情報を受信する監視端末と、
を含むことを特徴とする通信システム。
【請求項６】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置が、自装置の負荷状態に基づいて前記要求信号の送信方式を決定する決定工程と、
前記通信装置が、前記決定工程によって決定された送信方式を前記監視端末へ通知する通知工程と、
前記監視端末が、前記通知工程によって通知された送信方式によって前記通信装置へ前記要求信号を送信する第一送信工程と、
前記通信装置が、前記第一送信工程によって送信された要求信号に応じて前記監視端末へ前記状態情報を送信する第二送信工程と、
を含むことを特徴とする状態監視方法。
【請求項１】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置において、
自装置の負荷状態を示す負荷情報を取得する負荷取得部と、
前記負荷取得部によって取得された負荷情報に基づいて前記要求信号の送信方式を決定する決定部と、
前記決定部によって決定された送信方式を前記監視端末へ通知する通知部と、
を備えることを特徴とする通信装置。
【請求項２】
前記通知部によって通知された送信方式によって前記監視端末から送信された前記要求信号を受信する受信部と、
前記受信部によって受信された要求信号に応じて前記状態情報を前記監視端末へ送信する送信部と、
を備えることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記決定部は、前記監視端末の種別および前記負荷情報に基づいて前記送信方式を決定することを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記送信部は、前記負荷情報が示す負荷量が閾値を超えた場合に前記状態情報を他の通信装置へ送信し、
前記通知部は、前記負荷量が閾値を超えた場合に、前記状態情報の要求先を前記他の通信装置に切り替える旨の情報と、前記他の通信装置のアドレスと、を前記監視端末へ通知することを特徴とする請求項２に記載の通信装置。
【請求項５】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置であって、自装置の負荷状態に基づいて前記要求信号の送信方式を決定し、決定した送信方式を前記監視端末へ通知する通信装置と、
前記通信装置によって通知された送信方式によって前記通信装置へ前記要求信号を送信し、送信した要求信号に応じて前記通信装置から送信された前記状態情報を受信する監視端末と、
を含むことを特徴とする通信システム。
【請求項６】
監視端末から送信される要求信号に応じて自装置の状態を示す状態情報を前記監視端末へ送信する通信装置が、自装置の負荷状態に基づいて前記要求信号の送信方式を決定する決定工程と、
前記通信装置が、前記決定工程によって決定された送信方式を前記監視端末へ通知する通知工程と、
前記監視端末が、前記通知工程によって通知された送信方式によって前記通信装置へ前記要求信号を送信する第一送信工程と、
前記通信装置が、前記第一送信工程によって送信された要求信号に応じて前記監視端末へ前記状態情報を送信する第二送信工程と、
を含むことを特徴とする状態監視方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１１−２１１２５３（Ｐ２０１１−２１１２５３Ａ）
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１０−７３７５３（Ｐ２０１０−７３７５３）
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]