(57)【要約】【課題】システムの運用管理（監視を含む）の技術に係わり、対象システムのデータセンタが複数の場合に、問題の早期発見や問題範囲の特定などを実現できる技術を提供する。【解決手段】本統合監視システムでは、サイト等の対象システムを構成する複数のデータセンタ（ＤＣ）２の各々の内部の状態を監視する第１の処理部（ＤＣ内監視サーバ３、統合監視サーバ５）と、ユーザ端末１からのサイトのサービスに対するアクセスの状態を監視する第２の処理部（サービス監視サーバ４）と、上記第１の処理部による第１の監視情報と、第２の処理部による第２の監視情報とを用いて、それらを比較して判断することにより、対象システムの複数のＤＣ２のうち問題箇所または問題範囲を特定しその情報を出力する第３の処理部（統合監視サーバ５）と、を有する。【選択図】図２
2011090429.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークを介してユーザ端末に対しサービスまたはコンテンツを提供するＷｅｂサイトを構成する複数のデータセンタを有する対象システムを監視する情報処理システムであり、
前記複数のデータセンタの各々の内部の状態を監視する第１の処理部と、
前記ユーザ端末からの前記Ｗｅｂサイトのサービスまたはコンテンツに対するアクセスの状態を監視する第２の処理部と、
前記第１の処理部による第１の監視情報と、前記第２の処理部による第２の監視情報とを用いて、それらを比較して総合判断することにより、前記対象システムの複数のデータセンタのうち問題がある箇所またはそれを含む範囲を特定しその情報を出力する第３の処理部と、を有すること、を特徴とする統合監視システム。
【請求項２】
請求項１記載の統合監視システムにおいて、
前記第１の処理部及び第３の処理部を備える、第１の監視サーバと、
前記第２の処理部を備える、第２の監視サーバと、を有すること、を特徴とする統合監視システム。
【請求項３】
請求項１記載の統合監視システムにおいて、
前記第３の処理部により得られた、前記問題がある箇所またはそれを含む範囲の情報を、該当するデータセンタの管理者へ通知する第４の処理部を有すること、を特徴とする統合監視システム。
【請求項４】
請求項１記載の統合監視システムにおいて、
前記第２の処理部は、前記ユーザ端末からの前記ＷｅｂサイトのサービスまたはコンテンツへのアクセスにおけるＵＲＬまたは経路またはアクセス先のデータセンタのアドレスの情報を管理し、前記アクセスの状態として、いずれのＵＲＬまたは経路またはアクセス先のデータセンタで問題が発生したのかを監視すること、を特徴とする統合監視システム。
【請求項５】
請求項１記載の統合監視システムにおいて、
前記第３の処理部は、前記第２の監視情報がＮＧである場合で、前記第１の監視情報のうち、状態がＯＫである第１のデータセンタと、状態がＮＧである第２のデータセンタとがある場合、前記第２のデータセンタに問題有りと判断すること、を特徴とする統合監視システム。
【請求項６】
請求項１記載の統合監視システムにおいて、
前記第１の処理部は、前記複数のデータセンタの各々から、当該データセンタ内部の状態の監視情報の提供を受け、
前記複数のデータセンタは、前記監視情報を前記第１の処理部へ提供するデータセンタと提供しないデータセンタとが存在し、
前記第３の処理部は、前記第２の監視情報がＮＧである場合で、前記第１の監視情報のうち、前記提供するデータセンタの状態がＯＫである場合、前記提供しないデータセンタに問題有りと判断すること、を特徴とする統合監視システム。
【請求項７】
請求項１記載の統合監視システムにおいて、
前記第３の処理部は、前記第２の監視情報がＮＧである場合で、前記第１の監視情報のうち、状態がＯＫである第１のデータセンタと第２のデータセンタとがある場合、前記第１のデータセンタと第２のデータセンタとの間の通信に問題有りと判断すること、を特徴とする統合監視システム。
【請求項８】
請求項１記載の統合監視システムにおいて、
前記第３の処理部は、前記第２の監視情報がＯＫである場合で、前記第１の監視情報のうち、状態がＮＧである第１のデータセンタがある場合、当該第１のデータセンタに、前記サービスまたはコンテンツに対するアクセスの状態とは関係性が無い問題があると判断すること、を特徴とする統合監視システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティング、インターネット（Ｗｅｂ）等の技術に関し、特に、データセンタ（以下適宜「ＤＣ」と略称する）の運用管理や監視の技術に関する。
【背景技術】
【０００２】
インターネット上では、企業などのＷｅｂサイト、即ちユーザ（顧客等）のコンピュータ端末にサービスやコンテンツ等を提供する情報処理システムを多数有するが、これらのサイトは、データセンタにより構成されることも多くなっている。またデータセンタ事業者数も増加している。データセンタでは、高速通信接続環境や、各種セキュリティ・災害対策や、運用管理など、各種サービスや機能が提供され、これらは個別のデータセンタに依っても異なる。
【０００３】
上記データセンタ及びシステムの運用管理（監視を含む）の技術に係わり、現在、１つのデータセンタ内における監視の技術については一般化している。この技術では、監視対象機器（ハードウェアやソフトウェア）の例としては、サーバ、ネットワーク（ネットワーク機器）等がある。また監視対象項目としては、ログ、リソース、エラー・障害、ターンアラウンドタイム（ＴＡＴ）、等がある。この技術では、データセンタ内の監視部（監視サーバ等）から、監視対象機器の監視対象項目を監視し、それによる監視情報を記録し、データセンタの管理者等に対して出力することができる。
【０００４】
一方、昨今のＳａａＳ（Software as a Service）やクラウドコンピューティング（以下適宜「クラウド」と略称する）等の技術の登場・発展により、現状または今後、１社または１サイトが管理または構成するデータセンタが多数に及ぶ。例えば、クラウド環境において１つの企業のサイトを構成するデータセンタとして、自社のデータセンタ及び他社のデータセンタを含む、複数のデータセンタによるシステム（図１、サイトα（１０１））が挙げられる。即ち、サイトのサービスやコンテンツを実現するために複数のデータセンタのサービス処理やデータを並列にまたは連携して用いる形態などである。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
前述のように、１社または１サイトのシステムにおける管理または構成するデータセンタが複数にわたる場合、従来の１データセンタ内単位の監視等の技術では、当該システム全体を対象とした運用管理（監視を含む）に関しては不十分である。特に、対象システム全体のうち、エラーや障害等の問題を早期に、迅速に発見して、当該問題の箇所や範囲（例えばデータセンタ単位）を特定（切り分け）することは、困難である。クラウド環境などに伴い、上記対象システムを構成するデータセンタが多数になるほど上記は困難化する。
【０００６】
上記を鑑み、本発明の主な目的は、Ｗｅｂサイトやデータセンタ等のシステムの運用管理（監視を含む）の技術に係わり、対象システムのデータセンタが複数の場合に、問題の早期発見や問題範囲の特定などを実現できる技術を提供することである。
【課題を解決するための手段】
【０００７】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次の通りである。
【０００８】
（１）本発明のシステム（統合監視システム）では、第１の手段として、サイト（サービス）等の対象システムを構成する複数のデータセンタの各々の状態を監視する処理を行うシステム監視部と、第２の手段として、ユーザ端末（群）による通信ネットワークを介したサイト（サービス）等の対象システムへのアクセスの状態、サービスの状態などを監視する処理を行うサービス監視部と、を有する。
【０００９】
第１の手段は、例えば、各データセンタ（例えばＤＣ内監視部）から、ＤＣ内監視情報を受信または取得することにより、複数の各データセンタの状態を監視する。また、第１の手段は、各データセンタの監視情報またはそれが示す状態（例えばエラーや障害等の有無（ＮＧ／ＯＫ））を比較することにより、対象システムにおける問題の有無やその箇所または範囲（例えばデータセンタ単位）を判断しその結果情報を出力してもよい。これにより、問題の箇所や範囲に該当するデータセンタの管理者等が問題を認識して対応を図ることができる。
【００１０】
（２）更に、第２の手段は、例えば、前記アクセスの状態、サービスの状態を、サービス単位（対応付けられるＵＲＬ単位またはデータセンタへの経路などの単位）などで情報管理及び集計することにより監視する。そして、第２の手段は、その監視情報またはそれが示す状態（エラーや障害等の有無（ＮＧ／ＯＫ））を、第１の手段へ送信する（第１の手段は、第２の手段から当該情報を取得してもよい）。
【００１１】
そして、第１の手段は、第１の手段による前記複数の各データセンタの監視情報／状態、第２の手段による監視情報／状態とを用いて、これらを比較することにより、対象システムにおける問題の有無やその箇所または範囲（例えばデータセンタ単位）を判断しその結果情報を出力する。これにより、問題の箇所や範囲に該当するデータセンタの管理者等が問題を認識して対応を図ることができる。
【００１２】
本システムの形態は、例えば、クラウド環境などにおいてユーザ端末に対しサービスまたはコンテンツ等を提供するサイトを構成する複数のデータセンタを有する対象システムを監視する情報処理システムであり、複数のデータセンタの各々の内部の状態を監視する第１の処理部と、ユーザ端末からのサイトのサービスに対するアクセスの状態を監視する第２の処理部と、第１の処理部による第１の監視情報と、第２の処理部による第２の監視情報とを用いて、それらを比較して判断することにより、対象システムの複数のデータセンタのうち問題がある箇所またはそれを含む範囲を特定しその情報を出力する第３の処理部と、を有する。
【発明の効果】
【００１３】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。本発明によれば、Ｗｅｂサイトやデータセンタ等のシステムの運用管理（監視を含む）の技術に係わり、対象システムのデータセンタが複数の場合に、問題の早期発見や問題範囲の特定などを実現できる。
【図面の簡単な説明】
【００１４】
【図１】前提として、企業、サイト、データセンタ、等の対応関係の構成例を示す図である。
【図２】本発明の一実施の形態のシステム（統合監視システム及びそれを含んで成る情報処理システム）の構成を示す図である。
【図３】本実施の形態のシステムにおける、第１の具体例として、対象システム（他社ＤＣ）の形態がＨａａＳの場合、及び監視情報提供の場合について示す図である。
【図４】本実施の形態のシステムにおける、第２の具体例として、対象システム（他社ＤＣ）の形態がＳａａＳの場合、及び監視情報非提供の場合について示す図である。
【図５】本実施の形態のシステムにおける、第３の具体例として、対象システムのデータセンタ間での通信が存在する場合について示す図である。
【図６】本実施の形態のシステムにおける、その他の具体例について説明するための図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態（統合監視システム）を図面（図１〜図６）に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００１６】
＜対象システム＞
図１において、本実施の形態の前提を確認するために、企業、サイト、ＤＣ等による対象システムの対応関係の構成例について簡単に説明する。複数のＤＣの例として、各社（ＤＣ事業者）Ｘ，Ｙ，Ｚ，……等ごとに運営・管理するＤＣとして、ＤＣ−Ａ１，Ｂ１，Ｃ１，……等がある。また、１社が運営・管理する複数のＤＣが存在する場合もあり、例えば、自社Ｘが運営・管理する複数のＤＣとして、ＤＣ−Ａ１，Ａ２，……等がある。各ＤＣの構成は個別に異なる場合もあるし同様の場合もある。また各ＤＣのＤＣ内監視の技術についても有無や詳細は個別に異なる場合もあるし同様の場合もある。
【００１７】
そして、上記ＤＣ（そのサービス・機能）を用いて、企業などが提供するサイト（Ｗｅｂサイト）を有する。例えば第１のケースとして、サイトα（１０１）は、自社ＸのＤＣ−Ａ１と、他社ＹのＤＣ−Ｂ１と、他社ＺのＤＣ−Ｃ１との３つを含む複数のＤＣにより構成される。複数のＤＣ間で、ＳａａＳやクラウド等の技術を用いることにより、サイトのサービスやコンテンツ等が実現される。また例えば、自社Ｘによるサイトαを構成する主となるＤＣ（例えば基幹システム）を自社ＸのＤＣ−Ａ１とし、それに並列または連携するＤＣを他社ＹのＤＣ−Ｂ１等とした形などが可能である。
【００１８】
また第２のケースとして、サイトβ（１０２）は、自社Ｘの複数のＤＣである、ＤＣ−Ａ１，Ａ２，……等により構成される。また第３のケースとして、１つのＤＣによりサイトが構成される場合も勿論存在し、例えば、自社Ｘによるサイトγ（１０３ａ）は、自社ＸのＤＣ−Ａ１により構成される。あるいは、自社Ｘによるサイトγ（１０３ｂ）は、他社ＹのＤＣ−Ｂ１により構成される。
【００１９】
なお図１中、例えばサイトα内に複数のＤＣを包含するように図示しているが、各ＤＣのサービスや機能等の全部を用いてサイトαが構成されてもよいし、各ＤＣのサービスや機能等の一部の組み合わせにより構成されてもよい。
【００２０】
サイトα，βのようなシステム（１サイトを構成するＤＣが複数に及ぶ場合や、１社が管理するＤＣが複数に及ぶ場合など）を対象とした運用管理の場合、個別のＤＣ内の監視については従来実現されているが、それらシステム（複数のＤＣ）全体を統合監視することは従来実現されていない。
【００２１】
例えば、サイトαのサービス（クラウドによるサービス）の提供においてエラー等が発生した場合、従来では対象システム全体を監視している訳ではないので、関係する各ＤＣ（企業）において特にどのＤＣ（企業）で問題があるのかを特定することは、不十分であった。
【００２２】
また例えば、個別のＤＣに応じて、ＤＣ内の監視をしていても外部にその情報を提供（公開）していないＤＣも存在する。その場合、上記サービスのエラー等に関係するＤＣの問題（例えばサーバ障害）について、該当ＤＣ内では検知等ができたとしても、他（外部）の関係するＤＣ（例えば他社の連携するＤＣ）では、該当ＤＣから情報の提供や問題の連絡等が無い限り、当該問題を検知等することができない。
【００２３】
＜概要＞
図２を用いて、本実施の形態の概要や特徴は以下である。特徴的な要素として、統合監視サーバ５（第１の手段）とサービス監視サーバ４（第２の手段）とを含む、統合監視システムを有する。サービス監視サーバ４及び統合監視サーバ５は、例えばインターネット９０上に設けられる。対象システムとして、例えばサイトα（図１の１０１に相当）を構成する複数のＤＣ２として、第１のＤＣである自社ＸのＤＣ−Ａと、第２のＤＣである他社ＹのＤＣ−Ｂと、を含む場合である。ユーザ端末１（群）は、インターネット９０を通じて、サイトαのサービス等（それを実現するＤＣ）にアクセスする。なお、図２中、それぞれ、実線矢印は通常アクセス、破線矢印は監視（Ｋ０（Ｋ１）やＫ２）、二点鎖線矢印は監視結果通知（Ｋ１情報，Ｋ２情報）、等の流れや経路の例を示す。なお各種監視の種別として、Ｋ０はＤＣ内監視、Ｋ１はＫ０を用いたシステム監視（複数のＤＣの監視）、Ｋ２はサービス監視である。
【００２４】
統合監視サーバ５は、複数のＤＣ２による対象システムを監視（Ｋ１）する。この監視（Ｋ１）では、統合監視サーバ５は、各ＤＣ内監視サーバ３（３Ａ，３Ｂ）によるＤＣ内監視（Ｋ０）による監視結果情報を受信する（例：Ｋ１Ａ，Ｋ１Ｂ）。各ＤＣ内監視サーバ３は、ＤＣ内のネットワーク機器２１やサーバ２２の状態を監視（Ｋ０）し、その監視情報をログ等に記録し外部の統合監視サーバ５へ送信する。
【００２５】
一方、サービス監視サーバ４は、ユーザ端末１（群）によるサイトαのサービス等へのアクセスによる状態を監視（Ｋ２）する（例：Ｋ２Ａ，Ｋ２Ｂ）。サービス監視サーバ４は、そのＫ２結果情報を統合監視サーバ５へ通知（送信）する（Ｋ２Ｓ）。
【００２６】
統合監視サーバ５は、上記各監視（Ｋ１，Ｋ２）による情報（例：Ｋ１Ａ，Ｋ１Ｂ，Ｋ２Ｓ）を、対応する監視結果受信部５１（５１Ａ，５１Ｂ，５１Ｓ）で受信する。監視結果受信部５１は、システム監視部などと言い換えることもできる。
【００２７】
そして、監視結果比較部５２により、それら（Ｋ１，Ｋ２）の情報を比較して総合判断することにより、対象システム及びサービスに関する問題（例えばサービスのエラー等に関係するＤＣの障害等）の箇所またはそれを含む範囲を検知及び特定し、その情報を出力する。例えば問題箇所をＤＣ内のサーバ単位（ハードウェア単位／ソフトウェア単位）で特定し、あるいは、その問題箇所を含む問題範囲をＤＣ単位で特定する。監視結果比較部５２は、総合判断部などと言い換えることもできる。
【００２８】
また、統合監視サーバ５は、図示しない通知部を備えてもよく、上記総合判断結果に基づき、通知部により、問題範囲に該当するＤＣの管理者や関係するＤＣの管理者等へ情報を通知してもよい。これにより該当ＤＣの管理者等はすぐに問題への対応を図ること等ができる。
【００２９】
＜統合監視システム＞
以下詳細を説明する。図２において、ユーザ端末１は、Ｗｅｂブラウザ等を備えるＰＣや携帯電話機などであり、ユーザによる操作に基づき、インターネット９０上、サイトα（サービス）にアクセスする。例えばサービスに応じてアクセス先のＵＲＬ（１つ以上）が対応付けられている。この際、対象サービス（ＵＲＬ）等に応じて、アクセス先となるＤＣ２が決まる。例えば、ＤＣ−Ａの場合（例えば経路ＲＡ）とＤＣ−Ｂの場合（例えば経路ＲＢ）とがある。
【００３０】
各ＤＣ２は、複数のネットワーク機器２１やサーバ２２を有してなる。ＤＣ２内には、個別のＤＣ２にも依るが、ＤＣ内監視部である監視サーバ３（ＤＣ内監視サーバ）を有し、所定の監視対象機器（２１，２２等）や監視対象項目（ログ、リソース、エラー・障害・セキュリティ、ＴＡＴ、等）による所定の監視（Ｋ０）の処理を実施する。
【００３１】
また、複数のＤＣ２間では、インターネット９０以外に、ＤＣ２間を接続する専用線／ＶＰＮ９１などの通信手段があってもよい。例えばＤＣ−ＡとＤＣ−Ｂの間では、クラウドによるサービスの処理の連携の際に、専用線／ＶＰＮ９１（例えば経路ＲＣ）を介して通信する。
【００３２】
サイトαは、例えばクラウドによるサービスやコンテンツを提供する。クラウドによるサービスは、例えば、ＤＣ−Ａによるサービス処理と、ＤＣ−Ｂによるサービス処理と、その他のＤＣによるサービス処理との組み合わせから構成される。
【００３３】
＜ＤＣの形態＞
ＤＣ２の形態として、公知の概念に従い、ＨａａＳ（Hardware as a Service），ＰａａＳ（Platform as a Service），ＳａａＳなどの形態が可能である。例えば、ＨａａＳの形態（ハードウェア貸し）の場合、ＤＣ内のサーバ２２などのハードウェアを単位として、サイト運営者へ提供する。また、ＳａａＳの形態（ソフトウェア貸し）の場合、ＤＣ内のサーバ２２などのハードウェアの上で動作するソフトウェアやそのサービス処理を単位として、サイト運営者へ提供する。
【００３４】
そして、本システムでは、上記ＤＣの形態に応じて、ＤＣ内監視（Ｋ０）、システム監視（Ｋ１）、サービス監視（Ｋ２）、等の詳しい形態（例えば監視情報の詳細内容や有無、本システムが把握・判断可能な状態や情報など）が異なってくる。ＤＣ２から統合監視サーバ５へ提供される情報のレベルも異なってくる。例えばＨａａＳの場合、エラー等の問題をサーバ２２装置単位等で把握可能である。
【００３５】
＜システム監視（Ｋ１）＞
統合監視サーバ５は、システム監視（Ｋ１）の処理を、監視結果受信部５１（５１Ａ，５１Ｂ）により、各ＤＣ２内の監視サーバ３（３Ａ，３Ｂ）からのＫ０結果情報の受信により行う（例：Ｋ１Ａ，Ｋ１Ｂ）。なお統合監視サーバ５では、個別のＤＣ２に応じて監視サーバ３によるＫ０結果情報の提供（公開）が無い場合についても、その情報提供が無いこと（当該ＤＣの状態が不明であること）を情報管理する。
【００３６】
監視結果比較部５２は、各監視結果受信部５１（５１Ａ，５１Ｂ，５１Ｓ）による受信結果の情報、即ち、各ＤＣ２（ＤＣ−Ａ，ＤＣ−Ｂ）の状態、及びサービスの状態を比較して総合判断し、問題範囲を特定してその情報を出力する。状態（監視結果）を示す情報は、例えば少なくともＯＫ（問題無し）／ＮＧ（問題有り）の２種類を有する。総合判断の仕方については後述する。
【００３７】
＜サービス監視（Ｋ２）＞
サービス監視サーバ４は、サービス監視（Ｋ２）の処理を、例えば対象サイトα（その構成ＤＣ２）に定期的にアクセスすることにより行う（例：Ｋ２Ａ，Ｋ２Ｂ）。
【００３８】
サービス監視サーバ４でのサービス監視（Ｋ２）の処理では、少なくとも、サービスに関するアクセス先の可能性がある１つ以上のＤＣ２を把握する。それがわかっていれば、実際のアクセス先のＤＣ２が１つに特定できなくても、統合監視サーバ５での総合判断の処理の際に問題範囲の特定等が可能である。
【００３９】
また、サービス監視サーバ４では、ユーザ端末１（群）からのサイトαのサービスへのアクセスのＵＲＬと、それによるアクセス先となるＤＣ２（そのネットワーク機器２１等）との対応付けの情報を管理してもよい。特に、そのアクセスの経路Ｒ（例：ＲＡ，ＲＢ）またはアクセス先ＤＣ（例：ＤＣ−Ａ，ＤＣ−Ｂ）のアドレス等に関する情報を管理してもよい。この管理情報は、例えばサイト（対象システム）側で定義される情報などを利用して予めサービス監視サーバ４に登録すること等により把握することができる。このようにＵＲＬや経路等の情報を管理する場合は、統合監視サーバ５での総合判断の処理の際に問題範囲の特定等がより詳しく可能である。
【００４０】
また、１つのサービス（ＵＲＬ）に対して、アクセス先の選択候補となる複数のＤＣ２が対応付けられる場合（動的なアクセス先の形態）、例えばそれら複数の選択候補の情報をそのまま管理することで把握可能である。また、上記管理情報は、ＤＣ単位に限らず、より詳しく、ＤＣ内のサーバ２２等の単位で把握できる場合には、その情報を上記同様に管理することにより、より詳しく監視や判断が可能になる。
【００４１】
上記に基づき、サービス監視サーバ４は、サービス監視部４１により、サービス監視（Ｋ２）を実施する。例えばサービスのＵＲＬ単位でサービス応答に関するエラー数などを集計する。そして、サービス監視サーバ４は、例えばエラー発生有りの場合やあるいは定期的なタイミングなどで、そのＫ２結果情報を、監視結果通知部４２により、統合監視サーバ５（監視結果受信部５１Ｓ）へ通知する（Ｋ２Ｓ）。
【００４２】
＜具体例１＞
図３を用いて、第１の具体例として、ＤＣ２の形態がＨａａＳの場合などにおける統合監視の事例について説明する。図３のＤＣ−Ｂは、ＨａａＳの形態であり、ＤＣ−Ａに対してクラウドによるサービスのための連携等を行うＤＣ（クラウド）である。ＤＣ−Ｂでは、ＨａａＳとしてサーバ２２装置単位（例：サーバａ，ｂ，ｃ等）で提供している。またＤＣ内監視（Ｋ０）やサービス監視（Ｋ２）として、ＨａａＳに対応したサーバ２２装置単位での監視情報を得る。
【００４３】
また、ＤＣ−ＡとＤＣ−Ｂの双方が、Ｋ０結果情報を外部へ提供（公開）している場合である。即ち、双方の監視サーバ３（３Ａ，３Ｂ）は、各Ｋ０結果情報を、統合監視サーバ５の対応する処理部（５１Ａ，５１Ｂ）へ送信している（Ｋ１Ａ，Ｋ１Ｂ）。そのため、本例では、エラーや障害等の問題箇所の特定を、ＤＣ内のサーバ２２装置単位等で可能である。
【００４４】
ＤＣ内監視サーバ３は、Ｋ０結果情報として、当該ＤＣ内のエラーや障害等のネガティブな状態（ＮＧ）を検知した時やあるいは定期的なタイミングで、その状態（ＮＧ）を示す情報を、外部の統合監視サーバ５へ送信する。また、監視サーバ３は、Ｋ０情報として、当該ＤＣ内の状態が正常（問題無し）の場合についても、その状態（ＯＫ）を示す情報を外部の統合監視サーバ５へ送信することが望ましい。本実施の形態ではそのＯＫ情報も送信される。なお、例えばＤＣ内監視サーバ３から統合監視サーバ５へのＯＫ情報の送信（例えば定期的な送信）が無い場合、統合監視サーバ５は、当該ＤＣで問題有り（ＮＧ）の可能性が高いと判断できる。
【００４５】
ユーザ端末１からのアクセスにより上記ＨａａＳによるサイトαのサービス（例えばサービスＳＡ、対応するＵＲＬをＵＲＬ１とする）を利用する。その際、例えばＤＣ−Ｂ内のサーバａでエラーや障害等が発生した場合（それが原因でサービスＳＡの応答がエラー等となった場合）の事例について以下である。
【００４６】
（０）  ユーザ端末１（群）は、ＵＲＬ１によりサービスＳＡへアクセスする。
【００４７】
（１）  サービス監視サーバ４は、サービス監視部４１によりサービスＳＡ（ＵＲＬ１）のサービス監視（Ｋ２）を実施しており、サービスＳＡ（ＵＲＬ１）のアクセス先のＤＣ２として例えばＤＣ−Ａ（経路ＲＡ）またはＤＣ−Ｂ（経路ＲＢ）であることがわかっている。更に実際のアクセス先のＤＣ２が１つ（例えばＤＣ−Ｂ（経路ＲＢ））に特定されてもよい。本例では、Ｋ２では１つのアクセス先ＤＣ２に特定できない場合とする。Ｋ２の監視項目情報の例として、ＵＲＬ１（ＲＡ／ＲＢ）において、ＴＡＴ：［５００ｍｓ］、エラー有無：ＮＧ（エラー有り）［５件（全１０００件）］、セキュリティ：［０／１０００パターン］（問題パターン該当率）、等である。
【００４８】
（２）  サービス監視サーバ４は、（１）の結果から、サービスＳＡ（ＵＲＬ１）におけるエラーが発生したため、監視結果通知部４２により統合監視サーバ５（監視結果受信部５１Ｓ）へ、当該Ｋ２結果情報を通知する（Ｋ２Ｓ）。このＫ２Ｓの情報は、例えば、監視項目情報の例として、（１）と同様に、ＵＲＬ１、エラー有無（ＮＧ）、等を含む。
【００４９】
（３）  一方、統合監視サーバ５は、システム監視（Ｋ１）を実施している。即ち、各ＤＣ２のＤＣ内監視サーバ３（３Ａ，３Ｂ）から、対応する各監視結果受信部５１（５１Ａ，５１Ｂ）へ、ＤＣ内監視結果情報を受信する（Ｋ１Ａ，Ｋ１Ｂ）。この情報は、例えば、Ｋ１Ｂの情報では、ＤＣ−Ｂ内のログをもとに、「サーバａで障害等の問題が発生したこと」（ＤＣ−Ｂ，サーバａ，ＮＧ等）が通知される。またその時、Ｋ１Ａの情報では、「ＤＣ−Ａでは問題無し」（ＤＣ−Ａ，ＯＫ等）である。
【００５０】
（４）  統合監視サーバ５は、各監視結果受信部５１での受信情報、即ち、（２）のＫ２結果情報と、（３）のＫ１結果情報とをもとに、監視結果比較部５２により比較し、総合判断することにより、対象システムにおける問題箇所／範囲を特定する処理を行う。これにより、各監視情報は、Ｋ２ＳでＮＧ、Ｋ１ＡでＯＫ、Ｋ１ＢでＮＧであることから、結果情報として、例えばＵＲＬ１（ＲＢ）において、ＤＣ−Ｂ（問題範囲３０２）のサーバａ（問題箇所３０１）でＮＧ（エラーや障害等）であること（サービスＳＡのＮＧに関してＤＣ−Ｂ（サーバａ）のＮＧが関係すること等）が検知、特定される。
【００５１】
（５）  統合監視サーバ５は、上記結果情報を出力する。例えば、問題範囲に該当するＤＣ−Ｂの管理者や、該当しない他のＤＣ−Ａの管理者へ、当該情報を通知する。この情報は、例えば、サービス（ＳＡ）の提供に関してＤＣ−Ｂ（サーバａ）で問題（ＮＧ）がある旨などである。これにより各ＤＣ２では、問題の状況や原因、責任などを確認できる。
【００５２】
上記のように第１の具体例では、各種監視情報（Ｋ１，Ｋ２）のうち、Ｋ１情報のうちのＤＣ２提供情報（特にＫ１Ｂ）をもとに、エラー等の問題箇所３０１及び問題範囲３０２を検知、特定できた場合である。また本例では結果的にＫ１（Ｋ０）情報のみ（Ｋ２情報無し）でも問題箇所・範囲を特定等できている場合である（サービス状態との関係性を考慮しない場合）。しかしながら、後述の例のように、Ｋ１，Ｋ２情報の両方を参照しないと特定等できない場合がある。また、Ｋ１情報にＫ２情報を加えた判断により、サービス状態（サービス応答エラー等）とＤＣ状態（サーバ障害等）との関係性を特定または推定等できる。
【００５３】
＜具体例２＞
図４を用いて、第２の具体例として、ＤＣ２の形態がＳａａＳの場合などにおける統合監視の事例について説明する。図４のＤＣ−Ｂは、ＳａａＳの形態であり、ＤＣ−Ａに対してクラウドによるサービスのための連携等を行うＤＣである。ＤＣ−Ｂでは、ＳａａＳとしてサーバ２２（例：サーバａ，ｂ，ｃ等）のソフトウェア、サービス処理などの単位で提供している。またＤＣ内監視（Ｋ０）やサービス監視（Ｋ２）として、ＳａａＳに対応した上記サーバ２２のサービス処理単位などでの監視情報を得る。
【００５４】
また、ＤＣ−ＡはＫ０結果情報を外部へ提供しているが、ＤＣ−ＢはＫ０結果情報を外部に提供していない場合である（Ｋ１Ｂ情報無し）。即ち、統合監視サーバ５（５１Ｂ）は、ＤＣ−Ｂ内の状態が基本的には不明である。
【００５５】
そのため、本例では、ＤＣ−Ｂ内の詳しい問題箇所（サーバ単位）の特定まではできないが、Ｋ１情報及びＫ２情報を用いた総合判断により、問題箇所を含んだＤＣ単位での問題範囲の特定が可能な場合である。
【００５６】
ユーザ端末１からのアクセスにより上記ＳａａＳによるサイトαのサービス（例えばサービスＳＢ、ＵＲＬ２）を利用する。その際、例えばＤＣ−Ｂ内のサーバａでエラーや障害等が発生した場合（それが原因でサービスＳＢの応答がエラー等となった場合）の事例について以下である。
【００５７】
（０）  ユーザ端末１（群）は、ＵＲＬ２によりサービスＳＢへアクセスする。
【００５８】
（１）  サービス監視サーバ４は、サービス監視部４１によりサービスＳＢ（ＵＲＬ２）のサービス監視（Ｋ２）を実施しており、サービスＳＢ（ＵＲＬ２）のアクセス先のＤＣ２が例えばＤＣ−ＡまたはＤＣ−Ｂであることがわかっている。Ｋ２の監視項目情報の内容は、例えば第１の具体例と同様である（ＵＲＬ２（ＲＡ／ＲＢ），ＮＧ等）。
【００５９】
（２）  サービス監視サーバ４は、（１）の結果から、サービスＳＢ（ＵＲＬ２）におけるエラーが発生したため、監視結果通知部４２により統合監視サーバ５（監視結果受信部５１Ｓ）へ、当該Ｋ２結果情報を通知する（Ｋ２Ｓ）。このＫ２Ｓの情報は、（１）と同様である（ＵＲＬ２，ＮＧ等）。
【００６０】
（３）  一方、統合監視サーバ５は、システム監視（Ｋ１）を実施している。即ち、各ＤＣ２のＤＣ内監視サーバ３（ここでは３Ａのみ）から、対応する各監視結果受信部５１（５１Ａ）へ、Ｋ０結果情報を送信する（Ｋ１Ａ）。例えば、ＤＣ−ＡからのＫ１Ａの情報では、正常な状態であること（ＤＣ−Ａ，ＯＫ等）が通知される。またＤＣ−ＢからはＫ１Ｂの情報が無いため、ＤＣ−Ｂ内の状態は不明である。例えば監視結果受信部５１Ｂは、ＤＣ−Ｂの状態が不明であることを記録する。
【００６１】
（４）  統合監視サーバ５は、Ｋ１（Ｋ１Ａ，Ｋ１Ｂ），Ｋ２（Ｋ２Ｓ）の結果を比較して総合判断する。これにより、各監視情報は、Ｋ２ＳでＮＧ、Ｋ１ＡでＯＫ、Ｋ１Ｂで不明であることから、結果情報として、例えばＵＲＬ２（ＲＢ）において、ＤＣ−Ｂ（問題範囲４０２）でＮＧであること（サービスＳＢのＮＧに関してＤＣ−ＢのＮＧが関係している可能性が高いこと等）が検知、特定される。
【００６２】
（５）  統合監視サーバ５は、第１の具体例と同様に、上記結果情報を出力する。
【００６３】
上記のように第２の具体例では、各種監視情報（Ｋ１，Ｋ２）のうち、Ｋ１情報のうちの一部のＤＣ２（ＤＣ−Ｂ）の提供情報（Ｋ１Ｂ）が無い場合に、当該ＤＣ内の問題箇所の特定まではできないが、総合判断によりＤＣ単位で問題範囲４０２を特定できた場合である。
【００６４】
＜具体例３＞
図５を用いて、第３の具体例として、対象システムの形態として、ＤＣ２間通信（クラウドによるサービス処理のためのＤＣ２間の連携の通信など）が存在する場合について説明する。また例として、ＤＣ−Ａ及びＤＣ−Ｂ共に、外部に対してＫ０結果情報を提供している場合である。
【００６５】
ユーザ端末１からのアクセスによりサイトαのサービス（例えばサービスＳＣ、ＵＲＬ３）を利用する。その際、例えばＤＣ−ＡとＤＣ−Ｂの間の専用線／ＶＰＮ９１でエラーや障害等が発生した場合（それが原因でサービスＳＣの応答がエラー等となった場合）の事例について以下である。
【００６６】
（０）  ユーザ端末１（群）は、ＵＲＬ３によりサービスＳＣへアクセスする。なおＵＲＬ３は、例えば、まずユーザ端末１からＤＣ−Ａへの経路ＲＡに対応付けられ、更に、サービスＳＣの処理の連携のためのＤＣ−ＡからＤＣ−Ｂへの経路ＲＣに対応付けられるとする。サービスＳＣ（ＵＲＬ３）の提供の際、ユーザ端末１から例えば経路ＲＡでアクセス（要求）を受けたＤＣ−Ａのネットワーク機器２１から、ＤＣ−Ｂへの処理の連携のため、専用線／ＶＰＮ９１を介して、経路ＲＣで、ＤＣ−Ｂのネットワーク機器２１へアクセスする。その際、例えば専用線／ＶＰＮ９１での障害などにより、ＤＣ−Ａのネットワーク機器２１では、ＤＣ−Ｂからの正常な応答が得られない（エラー検知：ＵＲＬ３（ＲＣ），ＮＧ等）。その結果、ユーザ端末１へのサービスＳＣの応答がエラー等になったとする。
【００６７】
（１）  サービス監視サーバ４は、サービス監視部４１によりサービスＳＣ（ＵＲＬ３）のサービス監視（Ｋ２）を実施しており、サービスＳＣ（ＵＲＬ３）のアクセス先のＤＣ２が例えばＤＣ−Ａ（ＲＡ）及びＤＣ−Ｂ（ＲＢ）であることがわかっている。また更に、ＤＣ−ＡからＤＣ−Ｂへのアクセス（ＲＣ）があることについてもわかっていた方が望ましいが、わかっていなくても統合監視サーバ５での総合判断は可能である。Ｋ２の監視項目情報の内容は、例えば第１の具体例と同様である（ＵＲＬ３（ＲＡ／ＲＢ／ＲＣ），ＮＧ等）。
【００６８】
（２）  サービス監視サーバ４は、（１）の結果から、サービスＳＣ（ＵＲＬ３）におけるエラーが発生したため、監視結果通知部４２により統合監視サーバ５（監視結果受信部５１Ｓ）へ、当該Ｋ２結果情報を通知する（Ｋ２Ｓ）。
【００６９】
（３）  一方、統合監視サーバ５は、システム監視（Ｋ１）を実施している。即ち、各ＤＣ２のＤＣ内監視サーバ３（３Ａ，３Ｂ）から、対応する各監視結果受信部５１（５１Ａ，５１Ｂ）へ、Ｋ０結果情報を送信する（Ｋ１Ａ，Ｋ１Ｂ）。例えば、ＤＣ−ＡからのＫ１Ａの情報及びＤＣ−ＢからのＫ１Ｂの情報では、それぞれＯＫ等が通知される。なお、このＯＫ情報は、ＤＣとして問題無しの意味である。また例えばＫ１ＡのＯＫ情報では、ＤＣ−Ａ，Ｂ間の経路ＲＣにおける専用線／ＶＰＮ９１を介した通信におけるエラー等の検知情報（ＵＲＬ３（ＲＣ），ＮＧ等）が含まれていてもよいが（ＤＣ−Ａ，ＯＫ（Ａ−Ｂ間ＮＧ）等）、含まれていなくても総合判断は可能である。
【００７０】
（４）  統合監視サーバ５は、Ｋ１（Ｋ１Ａ，Ｋ１Ｂ），Ｋ２（Ｋ２Ｓ）の結果を比較して総合判断する。これにより、本例では、Ｋ２ＳでＮＧ、Ｋ１ＡでＯＫ、Ｋ１ＢでＯＫであることから、結果情報として、例えばＵＲＬ３（ＲＣ）において、ＤＣ−Ａ，Ｂ間の専用線／ＶＰＮ９１（問題範囲）がＮＧであること（サービスＳＣのＮＧに関してＤＣ−Ａ，Ｂ間のＮＧが関係している可能性が高いこと等）が検知、特定される。
【００７１】
（５）  統合監視サーバ５は、第１の具体例と同様に、上記結果情報を出力する。
【００７２】
上記のように第３の具体例では、各種監視情報（Ｋ１，Ｋ２）のうち、Ｋ１情報（各ＤＣ内の状態）には問題が無い場合に、比較により、ＤＣ間通信が問題であると特定または推定等できた場合である。
【００７３】
＜その他の具体例＞
図６を用いて、その他、総合判断に関する例を説明する。前述のように、Ｋ１情報（ＤＣの状態）として、ＯＫ、ＮＧ、不明、等がある。また、Ｋ２情報（サービスの状態）として、ＯＫ、ＮＧ、等がある。また、Ｋ２では、サービス（ＵＲＬ）に対しアクセス先のＤＣが特定できる場合とできない場合とがある。また、ＤＣ２から統合監視サーバ５へのＫ０結果情報の提供（公開）の形態として、提供（○）、非提供（×）、等がある。×の場合とは、詳しくは、該当ＤＣ内ではＤＣ内監視部により監視をしていてＤＣ内状態（問題）を把握しているがその情報を外部へは公開していないので外部からは当該ＤＣ内状態（問題）を把握できない場合や、あるいは、該当ＤＣ内では外部へ提供するためのＤＣ内監視部を持たない場合などが挙げられる。
【００７４】
対象システムの形態などに応じて、上記状態の組み合わせが各種存在する。それらに応じた総合判断の出力例（ＯＫ：問題無し、ＮＧ：問題有り）は以下である。例えば、図６のように、ＤＣ−Ａ（自社Ｘ），ＤＣ−Ｂ（他社Ｙ），ＤＣ−Ｃ（他社Ｚ），ＤＣ−Ｄ（他社）の４つを有するとする。またＫ０結果情報の提供については、例えば、ＤＣ−Ａ，Ｂが○、ＤＣ−Ｃ，Ｄが×、とする。また基本的にはサービス（ＵＲＬ）に対しアクセス先のＤＣが１つには特定できない場合とする。また例えば当該サイトのサービスへのアクセス時に実際にＤＣ内での障害がＤＣ−Ｂ及びＤＣ−Ｄで発生していたとする。
【００７５】
（１）｛Ｋ２＝ＮＧ，Ｋ１Ａ＝ＯＫ，Ｋ１Ｂ＝ＮＧ｝の場合→｛ＤＣ−Ａ：ＯＫ，ＤＣ−Ｂ：ＮＧ，ＤＣ−Ｃ，Ｄ：不明（ＮＧ可能性有り）｝。ＤＣ−Ａには問題が無く、ＤＣ−Ｂには問題が有る。例えばＤＣ−Ｂ内のサーバ障害によりサービス応答エラーとなった場合等である。更に、Ｋ２（サービス監視サーバ４）等により当該サービスのアクセス先のＤＣ等が特定できる場合、より詳しく特定が可能である。例えばアクセス先がＤＣ−Ｂの場合、上記ＤＣ−Ｃ，ＤについてはＯＫの可能性が高い。また例えばアクセス先がＤＣ−Ｂ及びＤの場合、上記ＤＣ−ＣについてはＯＫの可能性が高く、ＤＣ−ＤについてはＮＧの可能性が高い。
【００７６】
（２）｛Ｋ２＝ＮＧ，Ｋ１Ａ＝ＯＫ，Ｋ１Ｂ＝ＯＫ｝の場合→｛ＤＣ−Ａ，Ｂ：ＯＫ，ＤＣ−Ｃ，Ｄ：ＮＧ可能性有り｝。ＤＣ−Ａ，Ｂともに問題が無いため、ＤＣ−Ｃ，Ｄの少なくとも一方に問題がある可能性が高いと判断できる。例えば問題範囲はＤＣ−Ｃ，Ｄとなる。また、前述の第３の具体例のように、ＤＣ−Ａ，Ｂ間に通信がある場合は、それも問題範囲の候補になる。
【００７７】
（３）｛Ｋ２＝ＮＧ，Ｋ１Ａ＝ＮＧ，Ｋ１Ｂ＝ＮＧ｝の場合→｛ＤＣ−Ａ：ＮＧ，ＤＣ−Ｂ：ＮＧ，ＤＣ−Ｃ，Ｄ：不明（ＮＧ可能性有り）｝。ＤＣ−Ａ，Ｂともに問題が有る。更に、Ｋ２等により当該サービスのアクセス先がＤＣ−Ｂと特定できる場合、サービスのエラー等に関してＤＣ−Ｂに一番問題がある可能性が高いと判断できる。また、例えばアクセス先がＤＣ−Ａ及びＤＣ−ＡからＤＣ−Ｂへの連携であるとわかる場合、サービスのエラー等に関してＤＣ−Ａに一番問題がある可能性が高いと判断できる。
【００７８】
（４）｛Ｋ２＝ＯＫ，Ｋ１Ａ＝ＯＫ，Ｋ１Ｂ＝ＮＧ｝の場合→｛ＤＣ−Ａ：ＯＫ，ＤＣ−Ｂ：ＮＧ，ＤＣ−Ｃ，Ｄ：不明（ＮＧ可能性有り）｝。サービスとしてエラー等が無く正常に応答できている場合であるが、ＤＣ２側（ＤＣ−Ｂ）では内部に問題が発生している場合である。即ち、例えばＤＣ−Ｂには当該サービスの処理との関係性が無いサーバ障害等の問題があると判断できる。
【００７９】
＜実施の形態の効果等＞
本実施の形態によれば、Ｗｅｂサイト等の対象システムを構成するデータセンタが複数の場合に、問題（エラー・障害・セキュリティ等）の早期発見や問題範囲の特定などを実現できる。そして通知等により該当ＤＣでの問題への対応などへ進むことができる。例えばサイトのサービスのエラー等の発生の際、問題範囲の特定及び通知等により、該当ＤＣでは、自ＤＣに問題があること及び対応の必要性をすぐに認識することができる。また該当ＤＣ以外のＤＣでは、少なくとも自ＤＣには問題が無いことをすぐに認識することができる。即ち複数のＤＣにおいて問題に対する対応必要性や責任の明確化、切り分けを図ることができる。
【００８０】
また、統合監視サーバ５（第１の手段）による複数のＤＣの監視のみの場合（サービス監視サーバ４（第２の手段）による監視情報が無い場合）でも、相応の効果がある。即ち複数のＤＣの監視情報の比較により問題範囲等が判断、特定できる場合もある。更に、サービス監視サーバ４による監視情報を組み合わせて総合判断することにより、より詳しい判断、特定が可能になる。
【００８１】
また例えば、対象システムによるクラウド的なサービスの提供に関して、所定のＳＬＡ（サービスレベルアグリーメント）が設定される場合においても、本システムによれば、このＳＬＡに関する状態を監視し、ＳＬＡを満たしているかどうか等を確認することができる。
【００８２】
＜変形例＞
本実施の形態（図２）では、監視（Ｋ１，Ｋ２）に基づく総合判断（問題範囲の特定）の処理については、統合監視サーバ５で行っている。これに限らず、当該処理を別の装置（例えば連携するサーバ等）で行う形態や、サービス監視サーバ４と統合監視サーバ５を１つに統合した形態など、いずれも可能である。
【００８３】
また、サービス監視サーバ４は、詳しい形態としては、例えばユーザ端末１にソフトウェアモジュールとして実装する形態や、サイト（ＤＣ２）側に備えるサーバ等の形態や、インターネット９０上に設ける中継サーバ的な形態など、各種が可能である。
【００８４】
また、サービス監視サーバ４では、１サービス（ＵＲＬ）−１サイトについてのサービス監視（Ｋ２）に限らず、複数のサービス（ＵＲＬ）−複数のサイトについての対応関係等の情報を管理してサービス監視（Ｋ２）をしてもよい。
【００８５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【００８６】
本発明は、データセンタ、Ｗｅｂサイト、クラウドコンピューティングシステム等に利用可能である。
【符号の説明】
【００８７】
１…ユーザ端末、２…ＤＣ（データセンタ）、３（３Ａ，３Ｂ）…ＤＣ内監視サーバ、４…サービス監視サーバ、５…統合監視サーバ、２１…ネットワーク機器、２２…サーバ、４１…サービス監視部、４２…監視結果通知部、５１（５１Ａ，５１Ｂ，５１Ｓ）…監視結果受信部、５２…監視結果比較部、９０…インターネット、９１…専用線／ＶＰＮ、１００…統合監視システム、１０１，１０２，１０３…サイト（システム）、３０１…問題箇所、３０２，４０２，５０２…問題範囲。
【図１】
2011090429.tif 000003
【図２】
2011090429.tif 000004
【図３】
2011090429.tif 000005
【図４】
2011090429.tif 000006
【図５】
2011090429.tif 000007
【図６】
2011090429.tif 000008