(57)【要約】【課題】  クラウドコンピューティングサービスを利用して構築されたシステムの稼働状況の監視に伴うリソースの消費及びリソース利用コストを削減することを目的とする。【解決手段】データセンタのリソースを用いて構築されているシステムの監視サーバは、システムの構成変更を検知すると、構成変更に伴い新たに監視が必要になった部位に対して、その部位を監視するためのエージェントソフトウェアをデプロイし、デプロイしたエージェントソフトウェアから監視情報を収集するための論理ネットワークを開設する。【選択図】  図１
2015161954.tif 000002
【特許請求の範囲】
【請求項１】
１又は２以上のデータセンタにネットワーク回線を介して接続され、前記１又は２以上のデータセンタの１又は２以上の計算機上に構築されたシステムを構成するアプリケーションの稼働状態を監視する監視サーバであって、
前記監視サーバは、前記アプリケーションの稼働数の増加又は配置先の変更を検知すると、アプリケーションの稼働状態を監視するためのエージェントソフトウェアを、変更又は増加された前記アプリケーションが稼働する計算機が設置されたデータセンタの計算機へデプロイし、変更又は増加された前記アプリケーションの稼働状態の監視情報を前記エージェントソフトウェアから受信するために利用する論理ネットワークを前記ネットワーク回線上に開設する。
【請求項２】
請求項１に記載の監視サーバであって、
稼働数の増加又は配置先の変更前の前記アプリケーションを監視するために設置されたソフトウェアエージェントから監視情報を収集するための論理ネットワークが前記ネットワーク回線上に設定されており、
前記監視サーバは、前記アプリケーションの稼働数の増加又は配置先の変更を検知すると、変更又は増加された前記アプリケーションの稼働状態を、設置されていた前記ソフトウェアエージェントで監視可能かを判断し、監視可能と判断した場合、設定されていた前記論理ネットワークの帯域幅を拡大する。
【請求項３】
請求項１に記載の監視サーバであって、
前記アプリケーションの配置先の変更の検知とは、稼働中の前記システムから待機系のシステムへの切り替えの検知である。
【請求項４】
請求項１に記載の監視サーバであって、
前記アプリケーションの配置先の変更の検知とは、稼働中の前記システムのマイグレーションの検知である。
【請求項５】
請求項１に記載の監視サーバであって、
前記アプリケーションの稼働数の増加の検知とは、稼働中の前記システムのスケールアウトの検知である。
【請求項６】
請求項５に記載の監視サーバであって、
配置先が変更される前の前記アプリケーションを監視するためのソフトウェアエージェントが設置されており、
前記監視サーバは、前記アプリケーションの配置先の変更に伴い、変更前の前記アプリケーションが削除された場合、削除された前記アプリケーションを監視するためのエージェントソフトウェアを削除する。
【請求項７】
請求項２に記載の監視サーバであって、
前記監視サーバは、前記エージェントソフトウェアのデプロイに伴い、前記エージェントソフトウェアから収集する前記監視情報を記憶するための記憶領域を確保する。
【請求項８】
１又は２以上のデータセンタにネットワーク回線を介して接続され、前記１又は２以上のデータセンタの１又は２以上の計算機上に構築されたシステムを構成するアプリケーションの稼働状態を監視する監視サーバの制御方法であって、
前記監視サーバは、前記アプリケーションの稼働数の増加又は配置先の変更を検知すると、アプリケーションの稼働状態を監視するためのエージェントソフトウェアを、変更又は増加された前記アプリケーションが稼働する計算機が設置されたデータセンタの計算機へデプロイし、変更又は増加された前記アプリケーションの稼働状態の監視情報を前記エージェントソフトウェアから受信するために利用する論理ネットワークを前記ネットワーク回線上に開設する。
【請求項９】
請求項８に記載の監視サーバの制御方法であって、
稼働数の増加又は配置先の変更前の前記アプリケーションを監視するために設置されたソフトウェアエージェントから監視情報を収集するための論理ネットワークが前記ネットワーク回線上に設定されており、
前記監視サーバは、前記アプリケーションの稼働数の増加又は配置先の変更を検知すると、変更又は増加された前記アプリケーションの稼働状態を、設置されていた前記ソフトウェアエージェントで監視可能かを判断し、監視可能と判断した場合、設定されていた前記論理ネットワークの帯域幅を拡大する。
【請求項１０】
請求項８に記載の監視サーバの制御方法であって、
前記アプリケーションの配置先の変更の検知とは、稼働中の前記システムから待機系のシステムへの切り替えの検知である。
【請求項１１】
請求項８に記載の監視サーバの制御方法であって、
前記アプリケーションの配置先の変更の検知とは、稼働中の前記システムのマイグレーションの検知である。
【請求項１２】
請求項８に記載の監視サーバの制御方法であって、
前記アプリケーションの稼働数の増加の検知とは、稼働中の前記システムのスケールアウトの検知である。
【請求項１３】
請求項１１に記載の監視サーバの制御方法であって、
配置先が変更される前の前記アプリケーションを監視するためのソフトウェアエージェントが設置されており、
前記監視サーバは、前記アプリケーションの配置先の変更に伴い、変更前の前記アプリケーションが削除された場合、削除された前記アプリケーションを監視するためのエージェントソフトウェアを削除する。
【請求項１４】
請求項９に記載の監視サーバの制御方法であって、
前記監視サーバは、前記エージェントソフトウェアのデプロイに伴い、前記エージェントソフトウェアから収集する前記監視情報を記憶するための記憶領域を確保する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティングサービスを利用して構築されたシステムの稼働状態を監視する監視サーバ及び監視サーバの制御方法に関する。
【背景技術】
【０００２】
本技術分野の背景技術として、特開２００１−２９８４５４号公報（特許文献１）がある。特許文献１には、「監視コンピュータを設置するとともに、監視コンピュータと監視センタ用コンピュータとを、ネットワークを介して情報を送受して、監視対象ネットワークの性能や稼働状況等を、離れた監視センタで、迅速かつ的確に把握することが可能なネットワーク監視システム及び監視コンピュータと監視センタ用コンピュータ並びに記録媒体を提供する。」と記載されている。
【０００３】
また、特開２０１２−０１５７６２号公報（特許文献２）がある。特許文献２には、「顧客システム等にエージェントを設置して行うリモート監視システムにおいて、監視対象機器の増大によって発生するエージェントの処理性能不足、及びエージェントと監視対象機器との間に存在するルータやファイアウォールによる通信遮蔽を回避させる方式を提供する。」と記載されている。
【０００４】
また、ＵＳ２０１２／０１５９２３２Ａ１（特許文献３）がある。特許文献３には、「情報処理サービスを提供する情報処理装置をクラスタ化しなくても、障害が発生した情報処理サービスを直ちに復旧することを可能にする。」と記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−２９８４５４号公報
【特許文献２】特開２０１２−０１５７６２号公報
【特許文献３】ＵＳ２０１２／０１５９２３２Ａ１
【発明の概要】
【発明が解決しようとする課題】
【０００６】
システムの稼働状況の監視を行う際には、監視対象となるシステムが構築されている環境に、監視機能を備えたエージェントソフトウェアを導入して設定を行い、機能を有効化する必要がある。
【０００７】
しかしながら、ＣＰＵ（Central Processing Unit）や仮想マシンの利用数でサービス利用コストが生じるクラウドサービスを提供するデータセンタ上に、監視対象となる待機系システムを構築する場合、待機状態の間から監視機能を導入すると、稼働していない状態で監視が不要なシステムのために、監視機能を動かすためのリソース利用コストが発生してしまう。
【０００８】
また、監視対象システムが構築されている環境と、監視ログを収集する統合監視サーバが設置された監視センタとの間のネットワーク回線が共用回線の場合、稼働していない状態で監視が不要なシステムのためにネットワークの回線リソースを確保してしまうと、共用回線の利用効率が悪くなる。
【０００９】
また、監視ログを収集する統合監視サーバを、ストレージの利用量によって課金されるクラウドサービスを提供するデータセンタ上で稼働させる場合、監視対象システムが待機状態にある間から監視機能が稼働し、監視用ネットワークを介して監視ログが通知され、この監視ログを蓄積することになると、稼働していない状態で監視が不要なシステムのために、ストレージ利用コストが余計に発生してしまう。
【００１０】
本発明は、上述のような事情を鑑みてなされてものであり、クラウドコンピューティングサービスを利用して構築されたシステムの稼働状況の監視に伴うリソースの消費及びリソース利用コストを削減することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題に鑑み、本実施例における監視サーバは、データセンタのリソースを用いて構築されているシステムの構成変更を検知すると、構成変更に伴い新たに監視が必要になった部位に対して、その部位を監視するためのエージェントソフトウェアをデプロイし、デプロイしたエージェントソフトウェアから監視情報を収集するための論理ネットワークを開設する。具体的には、１又は２以上のデータセンタにネットワーク回線を介して接続され、前記１又は２以上のデータセンタ内の１又は２以上の計算機上に構築されたシステムを構成するアプリケーションの稼働状態を監視する監視サーバは、アプリケーションの稼働数の増加又は配置先の変更を検知すると、アプリケーションの稼働状態を監視するためのエージェントソフトウェアを、変更又は増加されたアプリケーションが稼働する計算機が設置されたデータセンタ内の計算機へデプロイする。そして、監視サーバは、変更又は増加されたアプリケーションの稼働状態の監視情報をデプロイしたエージェントソフトウェアから受信するために利用する論理ネットワークをネットワーク回線上に開設する。
【発明の効果】
【００１２】
システムの稼働状態の監視に必要となるリソースの利用コスト削減と、リソースの有効活用が可能になる。
【図面の簡単な説明】
【００１３】
【図１】監視システムの構成図の例である。
【図２】監視システムの処理の流れを説明するシーケンス図の例である。
【図３】監視サーバの構成図の例である。
【図４】監視エージェントや構成変更監視機能をデプロイする装置の構成図の例である。
【図５】動的デプロイ機能部の処理を説明するフローチャートの例である。
【図６】監視機能導入部の処理を説明するフローチャートの例である。
【図７】切替システム管理テーブルの例である。
【図８】監視対象管理テーブルの例である。
【図９】監視ネットワーク管理テーブルの例である。
【図１０】実施例２の監視システムの構成例を示す図の例である。
【図１１】実施例２の監視対象管理テーブルの構成例を示す図の例である。
【図１２】実施例２における動的デプロイ機能部の監視エージェント制御処理を示すフローチャートの例である。
【図１３】監視エージェント管理テーブルの構成例を示す図の例である。
【図１４】実施例３における動的デプロイ機能部の処理を説明するフローチャートの例である。
【図１５】構成変更通知メッセージの構成例を示す図の例である。
【発明を実施するための形態】
【００１４】
以下、実施例を図面を用いて説明する。
【実施例１】
【００１５】
本実施例では、ＤＲ（Disaster Recovery）システムやＨＡ（High Availability）システムのように、災害や障害により稼働中のシステムが停止した場合に、待機系のシステムに系切替を行うシステムを監視する例について説明する。
図１は、本実施例の構成変更追従型監視システムの構成図の例、図２は、本実施例の構成変更追従型監視システムの処理の流れを説明するシーケンス図の例である。この例では、稼働中システム６が顧客サイト１の１又は２以上の計算機上に構築され、稼働中システムを監視する顧客サイト１の監視エージェント１０ａは、取得した監視ログを、広域網２を介して、監視センタ３に設置されている統合監視サーバ８に送り、監視ログ収集機能部１１に格納する。監視エージェント１０ａは、顧客サイト１の計算機に配置されていればよく、単一の計算機に配置されても、複数の計算機に配置されてもよい。
【００１６】
一方、待機系システム７は、パブリッククラウドサービスを提供するデータセンタであるパブリッククラウド５の１又は２以上の計算機に構築されている。稼働中システム６の状態および切替契機はパブリッククラウド５の構成変更監視機能１２が監視する。構成変更監視機能１２はＤＲシステムやＨＡシステムの稼働中システム６の系切替契機を監視し（Ｓ２０）、系切替が発生する際には統合監視サーバ８の動的デプロイ機能１３に構成変更通知を送る（Ｓ２１）。この構成変更通知には、どのシステムの構成変更が発生したか判別できるようにするための識別子情報を含む。系切替契機は、構成変更監視機能１２が能動的に監視する形態でも構わないし、ＤＲシステムやＨＡシステムからの通知を監視する受動的な形態でも構わない。構成変更通知を受け取った動的デプロイ機能１３は、待機系システム７を監視するための監視エージェント１０ｂを、待機系システム７が準備されているパブリッククラウド５に導入する（Ｓ２３）。
【００１７】
また、構成変更通知を受け取った動的デプロイ機能１３は、パブリッククラウド５と監視センタ３との間の共用専用線４に、監視用論理ネットワーク１４を開設する（Ｓ２２）。この監視用論理ネットワーク１４は、待機系システム７が待機状態から稼働状態に切り替わり、監視エージェント１０ｂが監視ログを統合監視サーバ８の監視ログ収集機能部１１に送るための通信回線となる。
【００１８】
また、構成変更通知を受け取った動的デプロイ機能１３は、待機状態から稼働状態に切り替わるシステム７の監視ログを蓄積するために、監視ログ収集機能部１１の監視ログ記憶領域を確保する。
【００１９】
なお、上記構成例はあくまで一実施形態であり、上記構成例に限定されるものではなく、様々な変形例が含まれる。例えば、図１では構成変更監視機能１２は顧客サイト１に設置するようにみえるが、監視センタ３側に設置して、監視対象をリモート監視する形態でも構わない。構成変更の契機を把握する方法についても、監視対象システムから通知を貰うＰｕｓｈ型の監視方法でも構わないし、監視対象システムの稼働状態を定期的にポーリング監視するＰｕｌｌ型の監視方法でも構わない。
【００２０】
また、上記構成例では稼働中システム６を顧客サイト１に構築する形態について説明したが、稼働中システム６は、待機系システム７が構築されているパブリッククラウド５とは運営者や地理的場所が異なる別のパブリッククラウド上に構築する形態でも構わない。
【００２１】
図３は、本実施例の統合監視サーバ装置８の構成図の例である。ハードウェア構成は図示していないが、ＣＰＵ（Central Processing Unit）、メモリ、記憶装置といった一般的にサーバ装置が備える構成要素を備え、必要に応じて外部のターミナル装置から接続したり、ディスプレイやキーボード，マウスといった入出力デバイスを直結したりできるハードウェア装置を利用する。統合監視サーバ装置８は、監視ログ収集機能１１と動的デプロイ機能１３を備える。図３の構成例では、両機能が同一のハードウェア装置で稼働する形態を示しているが、物理的に異なるハードウェア装置で稼働する形態でも構わない。また、同一のハードウェア装置で稼働する場合でも、図４に示すようなハイパバイザ４１上の異なるユーザ空間４４の各々で稼働する形態でも構わない。
【００２２】
図４は、監視エージェント１０や構成変更監視機能１２のデプロイ先の装置、すなわち顧客サイト１及びパブリッククラウド５の計算機の構成図の例である。また、前記のように、監視ログ収集機能１１や動的デプロイ機能１３を稼働させる統合管理サーバの構成図の例でもある。本装置は、ハードウェア４０上にハイパバイザ４１を搭載し、ハイパバイザ４１の上で仮想分割した領域に、ドライバ４２、ＯＳ（Operating System）４３を乗せて、ユーザ空間４４を生成する。監視エージェント１０や構成変更監視機能１２、監視ログ収集機能１１や動的デプロイ機能１３を導入する場合も、このユーザ空間４４にそれぞれ導入する形態となる。監視エージェント１０や構成変更監視機能１２のデプロイ先は、稼働中システム６や待機中システム７が構築されている計算機と同一であってもよいし、異なる計算機であってもよい。
【００２３】
図３に戻って、監視ログ収集機能１１について説明する。監視エージェント１０から送られてくる監視ログは、通信インタフェースのような入力インタフェース３０を介して受信し、監視ログ収集機能部３１に送られる。監視ログ収集機能部３１は受け取った監視ログを、監視対象システム毎に分別して監視ログ格納部３３に記録する。監視ログ格納部３３は、データベースやストレージのような記録装置で構成され、物理的には別装置で構成する形態でも構わない。収集した監視ログは、ログ分析機能部３４で、必要に応じて閾値監視などのデータ解析を行った後、出力インタフェース３１を介して外部のターミナル装置や直結したディスプレイ装置に逐次出力する。
【００２４】
次に、動的デプロイ機能１３について、図５および図６のフローチャートや、図７から図９のテーブル構成図を参照しながら説明する。
【００２５】
通信インタフェースのような入力インタフェース３０を介して、構成変更監視機能１２から構成変更通知を受信（Ｓ５０）した実行契機監視部３７は、受信した構成変更通知に含まれる識別子情報７０や、構成変更発生元となる稼働中システム６のアドレス情報７１をもとに、切替システム管理テーブル３００を検索し、新たに監視対象となるシステム（待機系システム７）のアドレス情報７２を識別する（Ｓ５１）。新たな監視対象システムが判ったら、監視ログの収集に必要となる一連の機能導入および設定を実施する（Ｓ５２）。切替システム管理テーブル３００は、統合監視サーバ８の構成要素として実装する形態でも、統合監視サーバ８とは別のデータベース装置に実装する形態でも構わない。
【００２６】
構成変更通知メッセージの構成例を図１５に示す。図１５に示す構成は、通信パケットのボディ部に格納される内容を示しており、ヘッダ部に関する記載は省略している。本実施例のように、系切替に伴う監視対象の変更をいざなう場合は、コマンド１５０として「切替」を指定し、対象システムの識別子７０もしくは稼働中システムのアドレス情報７１を１５１に含めて構成変更通知メッセージを構成する。
【００２７】
監視機能導入部の処理（Ｓ５２）の詳細については、図６を用いて説明する。新たな監視対象となる待機系システム７を監視するための監視エージェント１０ｂの導入手順は次のようになる。監視エージェントデプロイ機能部３９が監視対象管理テーブル３６を参照し（Ｓ６０）、監視ログの通知先となるホスト（本実施例の場合、統合監視サーバ。特に監視ログ収集機能が動作しているサーバ。）のアドレス情報８２や、通知周期８３、アラート通知を行う場合に必要となる閾値情報８１など、監視エージェント１０ｂの設定に必要となる情報を抽出し、監視対象アドレス８０（本実施例の場合、待機系システムのアドレス情報７２と同一）に基づき、監視エージェント１０ｂをデプロイする（Ｓ６１）。
【００２８】
監視用論理ネットワーク１４の開設手順は次のようになる。監視ネットワーク設定機能３８が監視ネットワーク管理テーブル３５を参照し（Ｓ６２）、対象システムの識別子情報７０をもとに、監視用論理ネットワークの開設設定を行う対象となるルータやスイッチなどのネットワーク装置（両端の２装置）のアドレス情報９０、論理ネットワーク（例えばＶＬＡＮ：Virtual Local Area Network）のＩＤ（識別子，Identifier）情報９１、帯域幅の情報９２などを抽出し、前記ネットワーク装置に対して監視用論理ネットワークの設定を行う（Ｓ６３）。
【００２９】
また、監視機能導入処理（Ｓ５２）としては、新たに収集する管理ログを蓄積する記憶領域をストレージ装置に確保する（Ｓ６４）。
【００３０】
監視エージェントの導入処理（Ｓ６０〜Ｓ６１）、監視用論理ネットワークの開設処理（Ｓ６２〜Ｓ６３）、監視ログ収集領域確保処理（Ｓ６４）の順番については、図６のフローチャートに示すように並列実行する方式でも構わないし、図６のフローチャートとは異なりシーケンシャルに実行する方式でも構わない。但し、収集した監視ログを蓄積する領域や、監視ログを統合管理サーバ８に送るための通信回線の導入が完了しなければ、監視エージェントの導入が完了していても、新たな監視対象を統合管理サーバ８で監視することはできない。よって、望ましい監視機能導入手順の１形態は、最初に監視ログ収集領域を確保し（Ｓ６４）、次に監視用論理ネットワークを開設し（Ｓ６２〜Ｓ６３）、その上で監視エージェントの導入（Ｓ６０〜Ｓ６１）を行う形態である。
【００３１】
本実施例では、切替システム管理テーブル３００、監視対象管理テーブル３６、監視ネットワーク管理テーブル３５の情報は、システム構築時に登録しておくことを前提とする。但し、論理ネットワークのＩＤ情報９１に関しては、利用中のＩＤを監視ネットワーク管理テーブル３５で登録管理し、Ｓ６３では未だ利用していないＩＤを１つ抽出して割り当て、Ｓ６３で新たに割り当てたＩＤを監視ネットワーク管理テーブル３５に登録する形態が望ましい。
【００３２】
上記説明では、監視エージェント１０ｂをデプロイする際に設定情報を与える方式を述べたが、図４に示したような仮想化環境で監視エージェント１０ｂを動かす場合には、予め、設定情報を与えた監視エージェント１０ｂを含むイメージファイルを作成しておき、構成変更通知を受信（Ｓ５０）した際の監視機能導入（Ｓ５２）時には、前記イメージファイルを利用可能な状態にする方式でも構わない。この場合は、更に、構成変更通知を受信するまでは、作成したイメージファイルは統合監視サーバ８の監視エージェントデプロイ機能部３９で管理し、構成変更通知を受信（Ｓ５０）した後に、待機系システム７が準備されているパブリッククラウド５に導入（Ｓ２３）する形態をとっても構わない。構成変更通知を受信するまでは、イメージファイルを導入しないことにより、新たに監視対象となるシステムが稼働するまではパブリッククラウド５を使用しないことになるため、リソース使用に応じて発生する課金コストを抑制することができる。
【００３３】
上記実施例はＤＲシステムやＨＡシステムを例にとり説明したが、待機系システムを用意せず、異なるシステム環境にマイグレーションするケースに関しても、同様の効果が得られる。マイグレーションのケースでは、構成変更監視機能１２がマイグレーション契機を監視し、構成変更監視機能１２からの通知に基づき動的デプロイ機能１３が監視機能の導入（Ｓ５２）を行うことで、マイグレーション先でシステムが稼働し始めるタイミングで監視機能を動的に導入することができる。
【００３４】
以上、系切替やマイグレーションに伴う監視対象の切替変更手順について説明したが、系切替やマイグレーションが発生する以前に稼働していたシステムからの監視機能の削除手順は、実施例３で説明する。
【実施例２】
【００３５】
本実施例では、クラウドサービスで提供されるオートスケール機能のように、サーバの負荷が閾値を超えた際に、自動的にサーバが追加もしくは削除される場合にも、サーバの増減に追従して監視を行う、構成変更追従型監視システムの例を説明する。
【００３６】
図１０は、実施例２における構成変更追従型監視システムの構成図の例である。既に説明した図１に示された同一の符号を付された構成と、同一の機能を有する部分については、説明を省略する。
【００３７】
ある１つのゾーンＡ（１０５）でサーバ１０１が稼働している時に、オートスケール機能１０８は、設定された閾値情報に基づき、サーバ１０１の負荷の閾値監視を行う。サーバ１０１の負荷が閾値を超えると、オートスケール機能１０８は新たなサーバを増設する。この時、新たに増設されるサーバは、サーバ１０１と同一のゾーンＡ（１０５）に追加される形態でも、サーバ１０１とは異なるゾーンＢ（１０６）に追加される形態でも構わない。構成変更追従型監視システムは、新たに増設されるサーバ（１０２または１０３）を監視対象として加えるべく、監視機能の導入設定を行う。
【００３８】
サーバ増設に追従して監視機能の導入設定を行うために、構成変更監視機能１２は、オートスケール機能１０８の変化またはオートスケール機能１０８からの通知を監視する。オートスケール機能１０８からサーバの増設などの構成変更契機を得た構成変更監視機能１２は、動的デプロイ機能１３に構成変更通知を送る。構成変更契機の取得に関しては、構成変更監視機能１２がオートスケール機能１０８を定期的にポーリング監視する形態でも、構成変更監視機能１２がオートスケール機能１０８から通知を貰う形態でも構わない。
【００３９】
構成変更通知を受け取った動的デプロイ機能１３は、新たに増設されるサーバを監視するための監視エージェントを導入する。基本的な動作フローは、実施例１で説明した図５の手順と同様である。実施例１と異なるのは、新たな監視対象（実施例２では、オートスケールにより新たに増設されるサーバ）を識別する処理（Ｓ５２）である。実施例１では切替システム管理テーブル３００を検索して、新たな監視対象となる待機系システム７のアドレス情報７２を取得したが、実施例２では切替システム管理テーブル３００は存在しない。実施例２では、新たな監視対象（オートスケールにより新たに増設されるサーバ）のアドレス情報は、構成変更監視機能１２がオートスケール機能１０８から取得する情報に含まれ、構成変更監視機能１２はこのアドレス情報を動的デプロイ機能１３に伝える。
【００４０】
このことを図１５に示す構成変更通知メッセージで示すと、コマンド１５０には「追加」を指定し、新たに増設されるサーバのアドレス（新たに監視対象となるサーバのアドレス）情報を１５１に含める形となる。
【００４１】
実施例２では、監視対象管理テーブル３６の用法も実施例１とは異なる。前述のとおり、実施例２では、監視対象アドレス８０はオートスケール機能１０８から構成変更監視機能１２経由で取得する情報であり、実施例１のようにシステム構築時に登録されるものではない。実施例２の監視対象管理テーブル３６は、図１１に示すような構成になる。動的デプロイ機能１３は、新たな監視対象のアドレス情報をもとに、該アドレスが含まれるアドレスレンジ１１１を検索し、システム構築時などに予め設定されている監視情報の通知に必要となる情報７０，８１〜８３を取得する。実施例２では、識別子情報７０をゾーンの識別子と一致させても良い。
【００４２】
監視エージェントの導入に関しては、２通りのケースがある。１つのケースは、サーバ１０１と同一のネットワークゾーンであるゾーンＡ（１０５）に増設されるサーバ１０２を新たな監視対象とする場合である。この場合、既に導入されている監視エージェント１０ｂがサーバ１０２の監視も同時に許容できるならば、監視エージェントを新たに導入する必要はなく、監視エージェント１０ｂの設定に新たな監視対象となるサーバ１０２のアドレス情報などを追加するだけで良い。逆に、監視エージェント１０ｂがサーバ１０２を新たな監視対象として追加するだけの余力がない場合は、新規に監視エージェントを導入する必要がある。
【００４３】
もう１つのケースは、サーバ１０１とは異なるネットワークゾーンであるゾーンＢ（１０６）に増設されるサーバ１０３を新たな監視対象とする場合である。この場合はゾーンが異なるため、監視エージェント１０ｂとは別の監視エージェント１０ｃがサーバ１０３の監視を担う。この場合も既にゾーンＢ（１０６）に監視エージェント１０ｃが導入済みで、且つ、サーバ１０３を新たな監視対象として追加する余力がある場合は、監視エージェント１０ｃの設定に新たな監視対象となるサーバ１０３のアドレス情報を追加するだけで良い。一方、ゾーンＢ（１０６）には監視エージェントが未導入であったり、導入済みであっても、導入済みの監視エージェントがサーバ１０３を監視対象として追加する余力がない場合は、新規に監視エージェントを導入する。
【００４４】
同一ゾーンに新たな監視対象が増設されるケース、異なるゾーンに新たな監視対象が増設されるケースとも、監視エージェントの導入設定に関する処理手順は共通で、図１２に示すようなフローチャートになる。すなわち、当該ゾーンに監視エージェントが導入済みか確認する（Ｓ１２０）。監視エージェントが導入済みの場合は、既に導入されている監視エージェントで新たな監視対象の監視を許容できるか確認する（Ｓ１２１）。許容できる場合は、既存の監視エージェントに新たな監視対象に関する情報を登録する（Ｓ１２２）。一方、当該ゾーンに監視エージェントが導入されていない場合や、導入済みでも新たな監視対象の監視を許容できない場合は、新たに監視エージェントを導入する（Ｓ１２３）。図１２に示す手順は、図６のＳ６０とＳ６１を置き換えるものである。
【００４５】
監視エージェントが導入済みか否かは、監視対象管理テーブル３６で管理する。具体的には、監視エージェントを導入する際（Ｓ１２３）に、監視対象管理テーブル３６の該当するゾーン７０または該当するアドレスレンジ１１１の項目エリア１１２に、監視エージェントの識別子を登録することで管理する。
【００４６】
また、導入済みの監視エージェントの許容状況に関しては、図１３に示す監視エージェント管理テーブル１３０で管理する。この監視エージェント管理テーブル１３０も、監視対象管理テーブル３６と同様に、動的デプロイ機能部１３が管理する。監視エージェント管理テーブル１３０に関わる処理の流れは次のとおりである。監視エージェントを導入する際（Ｓ１２３）にエージェント毎１３１の情報を記録する領域を作成し、監視対象１３２の情報と共に管理する。既存の監視エージェントに監視対象を追加する際は、該当する監視エージェントの監視対象欄１３２に情報を追加する。既存の監視エージェントに新たな監視対象を追加可能か否かは、追加収容可否欄１３３の情報を参照する。例えば、各監視対象を監視するために要する監視エージェントの負荷は一定である場合は、予め試算した監視対象の許容数を初期値として登録し、監視対象が追加される度にカウントを減じ、カウントがゼロとなったら新たな監視対象の追加は不能と判断する。
【００４７】
監視用論理ネットワーク１４に関しては、監視対象のサーバが増加することに伴う監視トラフィック量の増加に応じて、監視用論理ネットワーク１４の帯域幅を増加させる。この監視用論理ネットワーク１４の帯域幅の増加も、構成変更通知を受け取った動的デプロイ機能１３が実施する。但し、既存の帯域幅が充分に確保されている場合は、必ずしも帯域幅を増加させなくても構わないし、帯域幅を増加させる代わりに、新たな監視用論理ネットワークを開設しても構わない。一つの実施形態の例は、監視エージェント１０を導入する際に、該監視エージェント１０が許容可能な監視対象サーバ数分の監視トラフィック量を包含する帯域幅９２を確保する形態である。この実施形態では、監視サーバの増加に伴う監視用論理ネットワーク１４の帯域幅変更は不要となり、監視用論理ネットワーク１４の制御は新規に監視エージェント１０を導入する際に行えば済む。
【００４８】
また、構成変更通知を受け取った動的デプロイ機能１３は、実施例１と同様に、新たに増設されるサーバの監視ログを蓄積するための監視ログ記憶領域を、監視ログ収集機能部１１に確保する。
【実施例３】
【００４９】
本実施例では、監視対象の停止もしくは削除といった構成変更に伴い、不要となる監視機能を削除する、構成変更追従型監視システムの例について説明する。システム構成および構成要素については、実施例１または実施例２に準じる。すなわち、稼働中システム６の停止や、オートスケール１０８の縮退を構成変更監視機能１２が監視し、構成変更監視機能１２からの通知を契機に動的デプロイ機能１３が処理を行うという流れは共通である。
【００５０】
違いは、構成変更通知（Ｓ２１）で通知される内容が、新たな監視対象のアドレスではなく、監視対象から削除する対象のアドレスという点である。動的デプロイ機能１３の処理手順としては、構成変更監視機能１２から構成変更通知を受信（Ｓ５０）し、受信したメッセージの内容を解析するところまでは図５と同様で、Ｓ５１相当の処理として、受信メッセージの解析結果を監視対象の削除と判定し、Ｓ５２相当の処理として、監視機能の削除処理を行うところが異なる。また、図１５に示す構成変更通知メッセージのコマンド１５０には「削除」を指定し、監視対象から削除する対象のアドレス情報を１５１に含める形となる。
【００５１】
監視機能の削除処理の詳細手順を図１４に示す。構成変更通知（Ｓ２１）として監視対象の削除通知を受信（Ｓ１４０）した動的デプロイ機能１３は、監視対象管理テーブル３６や監視エージェント管理テーブル１３０を確認する。削除すべき監視対象を監視している監視エージェントの監視対象１３２の数が１つ（Ｓ１４１）ならば、本構成変更通知により監視対象を削除すると当該監視エージェントは不要になるため、これを削除する（Ｓ１４２）。監視エージェントと対で監視用論理ネットワークを導入している場合は、この監視用論理ネットワークも不要になる。監視対象管理テーブルを削除する監視対象のアドレスで検索して識別子を特定し、この識別子を用いて監視ネットワーク管理テーブル３６を検索して、削除する管理用論理ネットワークのＩＤ（９１）や対象装置のアドレス（９０）を特定し、この情報を用いて管理用論理ネットワークの削除処理を行う（Ｓ１４３）。
【００５２】
一方、Ｓ１４１の確認処理の結果、削除通知を受けた監視対象を削除しても、監視エージェントが監視する監視対象が残る場合は、監視エージェントの削除は行わず、通知された監視対象を監視エージェントの設定から除く（Ｓ１４４）。具体的には、監視エージェント管理テーブル１３０の監視対象項目１３２から、通知された監視対象を取り除く。監視用論理ネットワークについても削除するのではなく、監視対象１つの監視データを通知する分の帯域幅が不要になるだけなので、不要になる帯域幅を削減する（Ｓ１４５）。この場合も、監視対象管理テーブルを検索して、削除する監視対象に関わる識別子７０を特定し、この識別子情報を元に監視ネットワーク管理テーブルを検索して、帯域幅の設定を変更するネットワーク装置のアドレス（９０）を特定して変更設定を行う。
【００５３】
以上に述べた監視機能の削除処理手順では、監視機能を導入する手順と違い、監視ログ収集領域については処理を行っていないが、これは取得済みの監視データを残しておくためである。不要になった監視データや監視ログ収集領域の削除は、監視対象を削除するタイミングとは異なる契機で処理を行う。
【００５４】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【符号の説明】
【００５５】
３  監視センタ
４  共用専用線
５  パブリッククラウド
８  統合監視サーバ
１０  監視エージェント
１２  構成変更監視機能
１３  動的デプロイ機能
１４  監視用論理ネットワーク
【図１】
2015161954.tif 000003
【図２】
2015161954.tif 000004
【図３】
2015161954.tif 000005
【図４】
2015161954.tif 000006
【図５】
2015161954.tif 000007
【図６】
2015161954.tif 000008
【図７】
2015161954.tif 000009
【図８】
2015161954.tif 000010
【図９】
2015161954.tif 000011
【図１０】
2015161954.tif 000012
【図１１】
2015161954.tif 000013
【図１２】
2015161954.tif 000014
【図１３】
2015161954.tif 000015
【図１４】
2015161954.tif 000016
【図１５】
2015161954.tif 000017