JP6788178B2

JP6788178B2 - 設定支援プログラム、設定支援方法及び設定支援装置

Info

Publication number: JP6788178B2
Application number: JP2016092970A
Authority: JP
Inventors: 正規古橋; 真一郎山口; 和成藤田; 一彰小澤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2016-05-06
Filing date: 2016-05-06
Publication date: 2020-11-25
Anticipated expiration: 2036-05-06
Also published as: US20170322826A1; JP2017201470A; US10635473B2

Description

本発明は，設定支援プログラム、設定支援方法及び設定支援装置に関する。

コンピュータによる業務システムの運用業務は、一般的に、業務システムの安定稼働を目的として、業務システムを構成するコンピュータ機器やコンピュータで実行されるソフトウエアの状態を監視する運用監視業務を有する。

通常、運用監視では、監視対象や監視方法について設計し、設計した監視対象や監視方法に基づいて監視サーバが運用監視を行い、業務システムが正しく稼働していることの確認と、異常発生の検知を行う。また、業務システムのアプリケーション開発と単体テストが終了後に業務システムをリリースする際、業務システムの本番稼働に入る前に、運用管理者は、テスト環境において、業務システムの動作テストと共に、運用監視のテストを行って運用監視の定義の妥当性を評価する。動作テストと運用監視テストの結果が良好であれば、本番環境に運用監視の定義を適用する。

一方、クラウドコンピューティングにおいて、クラウド事業者は、複数の物理マシンとストレージ及びネットワークを有するサーバセンタを配備し、一方、クラウドコンピューティングサービス（以下簡単にクラウドサービスと称する。）を受ける顧客は、サーバセンタ内の物理マシンに仮想マシンを生成し所望のサービスシステムを構築する。かかるクラウドサービスでは、顧客の業務システムの運用監視は、クラウド事業者がサービスとして行うことが主流になりつつある。

したがって、業務システムをリリースする段階で、クラウド事業者は、運用監視テストを実施し、業務システムに適した監視定義を策定することが必要になる。

運用監視のうち物理的なコンピュータなどのハードウエアや、オペレーティングシステム（Operating System）や基本的なミドルウエア（Middle Wear）などのインフラレイヤの運用監視については、特定の監視定義（監視定義パターン）の標準化がされている。したがって、インフラレイヤの運用監視においては、複数の監視定義パターンを準備しておき、顧客の要求に応じて選択すればよいので、監視定義の設計とそれに基づく運用監視を自動化することが可能である。

運用監視については、以下の特許文献に記載されている。

特開２０１０−１１３３８１号公報特開２０１３−１６４７３４号公報特開２００８−２９９３８７号公報

しかしながら、アプリケーションレイヤの運用監視においては、顧客ごとに及び業務ごとにアプリケーションの構造が異なり、さらにアプリケーションの詳細な監視を行うか否かの監視ポリシーも様々である。したがって、現状では、アプリケーションの監視定義を標準化または自動化することは困難である。その結果、運用管理者は、アプリケーションが出力するエラーメッセージのみ監視するのか（以下アプリ簡易監視と称する。）、またはアプリケーションの稼働時間やハードウエアリソースの使用状態について詳細に監視するのか（以下アプリ詳細監視と称する。）を、人手で判断し、運用監視テストにより監視定義を決定する。

クラウドサービスにおいて、クラウド事業者が、運用監視テストを行って監視定義の検証を行う場合、監視対象の業務システムのテスト環境を配備し、テスト環境で運用監視テストを行い、監視定義の検証を行う必要がある。そのようなテスト環境の配備の工数と監視定義の検証の工数は、一般に多くの工数を要し、短サイクルで業務システムを本番稼働させたい顧客は、運用監視テストを短時間で完了することを要求する。

そこで，一つの側面では，本発明は、システムリリース時の作業を軽減することができる設定支援システム、設定支援方法及び設定支援装置を提供することを目的とする。

１つの態様では、第1のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と所定の類似関係を有する第２の構成要素群に対応する前記第２のシステムの監視に関する設定情報を特定し、特定した前記設定情報を前記第１のシステムの設定情報として出力する、処理をコンピュータに実行させるシステムの監視に関する設定支援プログラムを用いる。

第１の側面によれば，システムリリース時の作業を軽減することができる。

クラウドサービスにおける顧客環境とクラウド事業者環境における運用監視テストを説明する図である。クラウドサービスにおける顧客環境とクラウド事業者環境における運用監視テストを説明する図である。本実施の形態におけるクラウドサービス環境のハードウエアリソースの一例を示す図である。本実施の形態における監視サーバが実行するプログラム群を示す図である。クラウドサービスにおける新業務システムの配備工程全体を示すフローチャート図である。シミュレーションシステムの配備プログラムの処理を示すフローチャート図である。、シミュレーションシステム配備プログラムにおける工程S14_2,S32,S36の詳細処理を示すフローチャート図である。アプリ詳細監視要否指標パターンの各指標（構成要素）とその概要を示す図表である。指標（構成要素）を取得する方法例を示す図表である。既存業務システムのアプリ詳細監視要否指標パターンの一覧の例を示す図である。新業務システムの指標パターンの３つの例を示す図である。シミュレーションシステム配備プログラムが管理するシミュレーションシステム配備管理テーブル例を示す図である。アプリ監視定義の作成工程のフローチャート図である。監視サーバ２２でのアプリ監視定義の設定画面例を示す図である。監視サーバ２２でのアプリ監視定義の設定画面例を示す図である。工程S30におけるアプリ詳細監視要否の補正工程での処理を示すフローチャート図である。

図１、図２は、クラウドサービスにおける顧客環境とクラウド事業者環境における運用監視テストを説明する図である。図１、２において、サーバセンタには、クラウドサービスを提供するクラウド事業者環境２０と、クラウドサービスを受ける顧客Ｘ社環境１０とが配備されている。顧客Ｘ社環境１０には、物理マシン、ストレージ、ネットワークなどのハードウエアのリソースプール１４が配備され、例えば、業務システム１(SYS1)や業務システム２（SYS2）を複数の仮想マシンVMにより生成し、それらの業務システムが所望のサービスを提供する。

一方、クラウド事業者環境２０にも、物理マシン、ストレージ、ネットワークなどのハードウエアのリソースプール２４が配備され、顧客Ｘ社環境１０内の業務システムの生成を管理する管理サーバ２１や、業務システムの運用を監視する監視サーバ２２が、物理マシンや物理マシンに生成した仮想マシンなどにより構築される。

顧客Ｘ社端末１５は、顧客Ｘ社環境１０の外側または内側に配備され、管理サーバ２１が提供するクラウドサービスサイトにアクセスし、業務システムを構成する仮想マシンを顧客Ｘ社環境内に配備することや削除することを、管理サーバ２１に要求する。管理サーバ２１は、その要求に応じて、顧客Ｘ社が要求する業務システムの仮想マシンの配備や削除を実行する。具体的には、管理サーバ２１は、顧客Ｘ社環境内のリソースプール１４の物理マシンの仮想化ソフトウエア（ハイパーバイザ）に仮想マシンの生成と削除を要求するコマンドを送信して、仮想マシンの配備や削除を実行する。

監視サーバ２２は、複数のインフラ監視定義パターン２５から選択されたパターンで業務システム１（SYS1）、２（SYS2）のインフラレベルの監視を行う。また、監視サーバ２２は、カスタマイズされたアプリ監視定義２６に基づいてアプリケーションレベルの監視が必要と判断された業務システムを、アプリ簡易監視またはアプリ詳細監視を行う。

顧客Ｘ社環境１０では、顧客Ｘ社の新たな業務システム３を配備する場合、顧客Ｘは、端末１５から管理サーバ２１に業務システム３のアプリ開発及びテスト環境１１の配備を依頼し、配備されたアプリ開発及びテスト環境１１の仮想マシンによるシステムで、アプリケーションの開発と単体でのテストを行う。そして、アプリ開発とテストが終了すると、顧客Ｘは、端末１５から監理サーバ２１に業務システム３の実行環境１２の配備を依頼し、配備された実行環境１２での最終テストを行う。この業務システムの実行環境１２の配備の段階を、本明細書ではアプリケーションのリリースと称する。

このリリースの段階以降で、業務システム３が本格稼働する前に、クラウド事業者は、顧客Ｘから新業務システム３のアプリ詳細監視を要求される場合がある。その場合、クラウド事業者は、短時間で、実行環境１２の業務システム３のアプリ監視定義を設計し評価することが求められる。そのため、クラウド事業者は、管理サーバ２１を介して、業務システム３の実行環境１２の仮想マシンVMを複写して業務システム３のテスト環境１３を配備し、監視サーバ２２が、テスト環境１３のシミュレーションシステムに対して、予め設計したアプリ監視定義に基づく監視をシミュレーションする。そして、クラウド事業者は、監視結果に基づいてアプリ監視定義の妥当性を評価する。開発されたアプリケーションが属する業務システム３の構成は、構成情報取得コマンドにより管理サーバ２１が取得可能であり、取得した構成情報に基づいて、監理サーバはシミュレーションシステム１３を配備可能である。または、管理サーバ２１が、業務システム３の本番環境１２のイメージファイルを取得できる場合は、そのイメージファイルの複写の仮想マシンを起動してシミュレーションシステム１３を配備可能である。

シミュレーションシステム１３は、図１のように顧客Ｘ社環境１０内のリソースプール１４を使用して配備される場合もあれば、図２のようにクラウド事業者環境２０内のリソースプール２４を使用して配備される場合もある。

そして、リリース後の業務システム３の実行環境１２での最終テストが完了し、シミュレーションシステム１３でのアプリ監視定義の評価結果がパスすると、業務システム３は実行環境１２で本番稼働に移る。本番稼働では、監視サーバ２２が、インフラ監視パターン２５の所定の組み合わせのパターンでインフラレベルの監視を行うとともに、カスタマイズしたアプリ監視定義２６によるアプリ監視を行う。

一般に、顧客は、業務システムの運用監視ポリシーを本番稼働の直前に決定する。したがって、顧客は、アプリケーションをリリースした段階では業務システムに対してアプリ詳細監視を行うか否かを未だ決定していないことが多い。一方、業務システムの本番環境１２での最終テストが終了してから本番稼働までの期間はできるだけ短くする必要がある。

したがって、運用監視を行うクラウド事業者は、アプリケーションがリリースされた段階で、業務システムの本番環境１２の仮想マシンを複写してシミュレーションシステム１３を配備することで、顧客からアプリケーションレイヤに対する監視リクエストを受けたら、即座にアプリ監視定義をシミュレーションシステム１３で設計しテストし評価することができ、短期間で高品質なアプリ監視定義の作成を完了することができる。

しかしながら、IaaS（Infrastructure as a Service）やPaaS(Platform as a Service)などのクラウドサービス環境では、様々な顧客の様々な業務システムでアプリケーションのリリースが頻繁に行われるので、多くのシミュレーションシステムを配備し保持する必要がある。その結果、監視サービスのために潤沢なハードウエアリソースが必要となり、コストの高いサービスとなる。

アプリケーションレイヤまで監視するケースは、業務システムの重要度が高いケースが一般的である。そこで、業務システムのリソース消費量のような単一の指標で業務システムの重要度を判定し、重要度が高いと判定された業務システムについてのみアプリケーションのリリース段階でシミュレーションシステムを配備することで、監視サービスのためのリソース使用量を大幅に節約できる。

しかし、クラウドサービス環境では、様々の顧客の様々の業務システムが稼働しており、業務システムの重要度の評価指標は千差万別であり、リソース消費量の単一指標による業務システムのアプリ詳細監視の要否判定は精度が低い。その結果、アプリ詳細監視が不要な業務システムだがリソース消費量が大きいためシミュレーションシステムを配備して無駄なリソースを消費したり、逆に、アプリ詳細監視が必要な業務システムだがリソース消費量が小さいためシミュレーションシステムを配備せず、アプリ監視定義の策定に長い時間を要するケースが頻発する。

［第１の実施の形態］
図３は、本実施の形態におけるクラウドサービス環境のハードウエアリソースの一例を示す図である。図３は、ハードウエアリソースのうち物理マシン上に構築された仮想マシン環境と物理マシン環境とを示す。物理マシンを構成する実ハードウエアR_HWは、CPU（Central processing unit）、メインメモリMEM、ネットワークインタフェースNICと、HDDやSDDなどの大容量の補助記憶装置３４を有する。

補助記憶装置３４には、ホストOSや仮想化ソフトウエアであるハイパーバイザHPVなどが記憶され、メインメモリMEMに展開されてCPUにより実行される。物理マシン環境３２では、ホストOS(H_OS)とアプリケーションAPL_3がCPUにより実行される。一方、仮想マシン環境３０では、ハイパーバイザHPVがCPUにより実行されて、図示しない仮想マシン構成情報に基づいて実ハードウエアR_HWを仮想化し、仮想ハードウエアV_HW_1、V_HW_2を各仮想マシンVM_1、VM_2に割り当てる。そして、仮想マシンVM_1では、仮想ハードウエアV_HW_1上でゲストOS（G_OS_1）とアプリケーションAPL_1が実行され、仮想マシンVM_2では、仮想ハードウエアV_HW_2上でゲストOS（G_OS_2）とアプリケーションAPL_2が実行される。

ハイパーバイザHPVが仮想マシンVM_1を最初に起動した際にゲストOS（G_OS_1）とアプリケーションAPL_1を初期化すると、補助記憶装置３４内に仮想マシンVM_1のイメージファイルVM_1_IMGが生成される。仮想マシンVM_2を最初に起動した場合も同様に補助記憶装置３４内に仮想マシンVM_2のイメージファイルVM_2_IMGが生成される。

図１、２で示した顧客Ｘ社環境１０内の業務システムSYS1,SYS2,12、アプリ開発及びテスト環境１１、シミュレーションシステム１３を構成する仮想マシンVMは、図３で示した仮想マシンVM_1, VM_2などに対応する。同様に、クラウド事業者環境２０内の管理サーバ２１や監視サーバ２２も、図３の仮想マシンVM_1,VM_2などにより構成される。

したがって、業務システムのアプリケーションプログラムや、開発中のアプリケーションまたシミュレーションシステムのアプリケーションは、仮想マシンVM_1,VM_2内のアプリケーションAPL_1,APL_2に対応する。また、管理サーバ２１の管理用アプリケーションや監視サーバ２２の監視用アプリケーションも、仮想マシンVM_1,VM_2内のアプリケーションAPL_1,APL_2に対応する。

図４は、本実施の形態における監視サーバが実行するプログラム群を示す図である。図４では、シミュレーションシステム１３、２３が顧客Ｘ社環境１０またはクラウド事業者環境２０内のハードウエアのソースプールにより構築される。

クラウド事業者環境２０内に配備されている監視サーバ２２は、既存の業務システムの内アプリ詳細監視が必要と判断された業務システムについて、予め定めたアプリ監視定義に基づいてアプリ監視を行うアプリケーション監視プログラムPRG1を実行する。さらに、監視サーバ２２は、リリース検知プログラムPRG2を実行して、顧客Ｘ社が新たな業務システム３の開発中または改良中のアプリケーションのリリースを検出する。

リリースの通知に応答して、監視サーバ２２は、シミュレーションシステム配備プログラムPRG3を実行して、リリースされた新業務システム３のアプリ詳細監視が要求されるか否かを判定する。この判定方法については後で詳述するが、概略を述べると、既存業務システムの所定の構成要素の有無と、CPUやメモリなど構成要素の性能因子とを含む構成要素群と、同じく既存業務システムのアプリ詳細監視要否との対応付けに基づいて、新業務システムの構成要素群と類似する構成要素群を有する既存業務システムのアプリ詳細監視要否を特定し、特定したアプリ詳細監視要否を新業務システムのアプリ詳細監視要否として利用する。

そして、シミュレーションシステム配備プログラムPRG3は、アプリ詳細監視要と判定した場合、リソースプールのハードウエアを使用してリリースしたアプリケーションの新業務システム３を複写したシミュレーションシステム１３、２３を配備する。このシミュレーションシステムの配備は、業務システム３のイメージファイルを取得できる場合はイメージファイルを複写して起動することにより行うことができる。または、業務システム３の仮想マシンの構成情報（CPUのクロック数、メモリ容量、HDD容量、通信帯域、ゲストOS、アプリケーションなどの情報）を取得できる場合は、その構成情報に基づいてシミュレーションシステムを起動、生成することができる。

クラウド事業者は、開発したアプリケーションをシミュレーションシステムで実行しながら、設計したアプリ監視定義に基づいてアプリ監視をアプリケーション監視プログラムPRG1により実行する。アプリ監視定義は、例えば、監視する稼働時間帯、ウエブアクセスに割り当てるプロセス数の上限値及び下限値、CPU使用率の上限値及び下限値、仮想メモリ容量の上限値及び下限値などである。これらの監視定義に基づいて、例えば設定した監視時間帯で、プロセス数、CPU使用率、仮想メモリの容量が上限値と下限値を超えて想定範囲外になった時に警告を出力するなどのアプリ詳細監視が行われる。アプリ監視定義の作成ツールPRG4は、例えば、アプリケーション監視プログラムPRG1に属するツールの一つである。

そして、アプリ監視定義の検証結果が良好の場合は、アプリケーション監視プログラムでのアプリ監視定義の作成終了となるので、監視サーバ２２は、シミュレーション完了検知プログラムPRG5を実行して、アプリ監視定義が確定したことを検知する。

次に、本実施の形態について、クラウドサービスにおける新業務システムの配備工程全体を説明し、シミュレーションシステムの配備プログラムの処理と、アプリ監視定義について説明する。

［新業務システムの配備工程］
図５は、クラウドサービスにおける新業務システムの配備工程全体を示すフローチャート図である。図１、２で説明した通り、クラウドシステムの顧客は、顧客環境１０内の開発環境１１でアプリケーションを開発し、アプリケーション単体の動作テストを行う（S10）。アプリケーションの開発と単体動作テストが完了すると、顧客は、顧客環境１０内に新業務システム３の本番環境１２を配備する（S11）。この新業務システム３には、開発した新アプリケーションが仮想マシンにより実行される。これにより、アプリケーションはリリースされ（S12）、本番環境１２の新業務システムの最終テストに入る（S13）。

本実施の形態では、監視サーバ２２が、リリース検知プログラムPRG2を実行して上記のアプリケーションのリリースを検出し、アプリリリースの通知に応答して、シミュレーションシステム配備プログラムPRG3を実行して、新業務システムの新アプリケーションについてアプリ詳細監視要否を自動判定する（S14）。アプリ詳細監視要否の自動判別により、アプリ詳細監視が必要と判別すると（S15のYES）、監視サーバ２２が、シミュレーションシステム配備プログラムPRG3を実行して、新業務システム３のシミュレーションシステム１３、２３を配備する（S16）。

上記の通り、監視サーバが上記のアプリ詳細監視要否の自動判定工程S14を行い、高精度にアプリ詳細監視が必要か否かを予測し、アプリ詳細監視要と判定された新業務システムについて、顧客環境１０またはクラウド事業者環境２０内のリソースプールを利用してシミュレーションシステムを配備する。これらの工程S14,S15,S16については、後述するシミュレーションシステムの配備プログラムの処理で詳述する。

アプリリリース後の新業務システムの最終テスト中または終了時に、新業務システムの顧客からアプリ詳細監視の指示があると（S17のYES）、クラウド事業者は、あらかじめ配備済みのシミュレーションシステムでアプリ監視定義を作成し、監視サーバ２２のアプリケーション監視プログラムを実行して、作成したアプリ監視定義に基づきアプリ詳細監視テストを行う（S18）。具体的にはシミュレーションシステムが新アプリケーションを実行し、監視サーバがアプリ監視定義に基づいてアプリ詳細監視を行う。そして、監視結果を新業務システムの顧客と共に評価し、作成した監視定義の妥当性を確認する(S19)。監視結果が妥当でない場合、アプリ監視定義を再作成し、上記のアプリ詳細監視テストS18と監視定義の妥当性の確認S19とを繰り返す。

監視定義が承認されると（S19のYES）、監視サーバのアプリケーション監視プログラムPRG1の設定画面でクラウド事業者によるアプリ監視定義設定操作がなされ、シミュレーション完了検知プログラムPRG5がシミュレーション完了を検知する（S20）。その結果、承認されたアプリ監視定義が新業務システムのアプリ監視定義として監視サーバ２２に設定され、監視サーバ２２によるアプリ詳細監視が開始される（S21）。

上記のアプリ監視定義の作成と承認工程S18,S19については、後で詳述する。

アプリリリース（S12）後に、またはアプリ監視を開始するときに、監視サーバ２２に自動でまたは人手で選択されたインフラ監視定義が設定され、監視サーバ２２はそのインフラ監視定義に基づくインフラ監視を開始する（S22）。また、監視サーバによる監視開始（S21,S22）と同時に、新業務システム３の本番稼働が開始され業務が開始される（S23）。そして、シミュレーションシステム配備プログラムが、シミュレーションシステムを削除する（S24）。

［シミュレーションシステムの配備プログラムの処理］
図６は、シミュレーションシステムの配備プログラムの処理を示すフローチャート図である。シミュレーションシステム配備プログラムPRG3は、図６の工程S14,S15,S16の処理を実行する。

監視サーバ２２は、シミュレーションシステム配備プログラムPRG3を実行して、以下の処理を実行する。まず、監視サーバ２２は、予め、既存業務システムのアプリ詳細監視要否指標パターンを自動抽出する（S30）。アプリ詳細監視要否指標パターンは、業務システムの所定の構成要素群（構成要素及び構成要素の機能因子）の組み合わせである。

上記のアプリ詳細監視要否指標パターンの抽出は、（１）各既存業務システムがアプリ詳細監視要否指標パターンの各指標（構成要素）に該当するか否かを判定し、（２）各既存業務システムがアプリ詳細監視をしているか否かを、運用管理の内部データベースから抽出し、（３）各既存業務システムの該当する指標パターン（構成要素群）とアプリ詳細監視の要否とを関連付けたアプリ詳細監視要否指標パターンを生成し、監視サーバ２２を構成する物理マシンのメモリMEM内に記憶する、ことで行われる。

図８は、アプリ詳細監視要否指標パターンの各指標（構成要素）とその概要を示す図表である。図８には、指標（構成要素）ａ〜ｋの合計１１個の例が示される。但し、これらの指標（構成要素）は一例であり、これらに限定されることなく、各顧客毎に異なる組み合わせであっても良い。

まず指標（構成要素）ａ〜ｅは、指標の構成的因子であり、所定の構成要素の有無を示す。構成要素ａは、業務システムのウエブサーバのフロント位置に負荷分散装置を有する構成である。すなわち、クラウドサービスを利用する業務システムは、一般に、業務システムにアクセスするためにインターネットやイントラネットなどのネットワークを介してアクセスの要求を受け付ける複数のウエブサーバを有する。そして、ウエブサーバは、外部から受信した要求を、業務サービスを構成する仮想サーバに依頼する。ウエブサーバのレスポンス性能を上げるために、ウエブサーバの前段に設けたＳＬＢ（サーバレベルバランサー）が複数のウエブサーバに受信要求を適切に分配する。したがって、構成要素ａは、ウエブサーバのフロントに設けられる負荷分散装置である。

構成要素ｂは、ウエブサーバのフロントにファイアウオールを有する構成である。前述のとおりウエブサーバは、外部から受信した要求を業務サービスシステムを構成する仮想サーバに依頼する。そして、業務サービスの仮想サーバを外部からのアクセスから保護するために、ファイアウオールサーバが配置される。したがって、構成要素ｂは、ウエブサーバのフロントに設けられるファイアウオールである。

構成要素ｃは、業務サービスシステムに設けられるデータベースサーバに対して読み出しと書き込みの両方が行われる構成である。データベースサーバは、業務システムが基幹業務の場合、読み出しと書き込みが頻繁に行われる。一方、基幹業務でない場合、例えば月次処理で情報収集のためにデータの参照だけが行われ、データベースサーバはもっぱら読み出しだけが行われ書き込み頻度が低い。

構成要素ｄは、災害対策オプションの構成である。たとえば、業務システムが、災害発生時には別の環境で業務サービスを継続する機能を有する場合、災害対策オプションの構成を有する。したがって、構成要素ｄは、災害発生時に業務サービスの継続が可能な機能を有することである。

構成要素ｅは、業務システムがクラスタ構成により二重化されていることである。業務システムを構成する仮想サーバ群がクラスタ構成により二重化されている場合、一方のクラスタによる業務システムが停止しても、もう一方のクラスタによる業務システムが業務を継続できる。したがって、構成要素ｅは、業務システムが二重化され何らかのエラー発生時に業務継続が可能な機能を有することである。

次に、指標（構成要素）ｆ〜ｋは、指標の性能的因子であり、構成要素の通常状態での性能を示す。構成要素ｆは、ＣＰＵ使用率（例えば単位時間あたりの使用クロック数）がその顧客のアプリ詳細監視している業務システムの最低値より高い構成である。

構成要素ｇは、総メモリ量であり、業務システムに割り当てているメモリ量（容量）が、その顧客のアプリ詳細監視している業務システムの最低値より高い構成である。

構成要素ｈは、通信回線の帯域サイズであり、通信回線の帯域サイズが、その顧客のアプリ詳細監視している業務システムの最低値より高いという構成である。

構成要素ｉは、ストレージの使用量、使用率であり、ストレージの使用量（容量）、使用率（単位時間当たりの総アクセス時間の比率）が、その顧客のアプリ詳細監視している業務システムの最低値より高いという構成である。

構成要素ｊは、ネットワークインタフェース数であり、業務システムに設定されているネットワークインタフェース、例えば仮想ＮＩＣ（Network Interface Card）の個数が、その顧客のアプリ詳細監視している業務システムの最低値より大きいという構成である。

最後に、構成要素ｋは、ウエブサーバの要求を受け付けるプロセス数であり、稼働中に要求を受け付けたプロセス数が想定範囲外に変動するという構成上の指標である。

図９は、指標（構成要素）を取得する方法例を示す図表である。監視サーバ２２は、シミュレーションシステム配備プログラムを実行して、図８に示したアプリ詳細監視要否指標パターンの各指標（構成要素）を何らかの方法で取得し、既存の業務システムがそれぞれの指標（構成要素）に該当するか否かを判定する。図９は、その取得方法例を示す。

構成要素ａの負荷分散装置、構成要素ｂのファイアウオールは、顧客の稼働中の業務システムにおいて、インベントリ情報収集コマンド（例えば、snmpwalkコマンド）により業務システムの構成情報（MIB）を取得することができる。構成要素ｃのデータベースサーバへの読み出しと書き込みの実行の有無や頻度については、読み出しと書き込みのログから取得することができる。

また、構成要素ｄの災害対策オプションと、構成要素ｅの業務システムの二重化の有無については、クラウドサービスのＡＰＩ（Application Program Interface）で取得できる顧客の環境設定プロパティを取得し、その環境設定プロパティからオプション情報を取得することができる。

次に、性能的因子である構成要素ｆ（ＣＰＵ使用率）、ｇ（総メモリ量）、ｈ（通信回線の帯域）は、業務システムの仮想マシンのゲストＯＳから取得することができる。また、構成要素ｉ（ストレージの使用率、使用量）は、ストレージから取得できる。そして、構成要素ｊ（ネットワークインタフェース数）は、インベントリ情報収集コマンド（snmpwalkコマンド）で取得できる。さらに、構成要素ｋ（ウエブサーバの要求受付用プロセス数の変動大）については、プロセス数収集コマンドでプロセス数の変動を取得可能である。

監視サーバ２２は、シミュレーションシステム配備プログラムを実行し、前述のとおり各業務システムがアプリ詳細監視要否指標パターンの各指標（構成要素）に該当するか否かを判定し、さらに、各業務システムがアプリ詳細監視をしているか否かを運用管理の内部データベースから抽出する。そして、各業務システムの該当する指標パターン（構成要素群）とアプリ詳細監視の要否とを関連付けたアプリ詳細監視要否指標パターンを生成し、監視サーバの物理マシンのメモリ内に記憶する。

図１０は、既存業務システムのアプリ詳細監視要否指標パターンの一覧の例を示す図である。図１０の一覧５０には、６つの既存業務システムについて指標（構成要素）パターン（図中○が記載された構成要素）と、各業務システムのアプリ詳細監視要否が関連付けられている。したがって、ある顧客の既存業務システムについてのアプリ詳細監視要否指標パターンと監視要否の一覧（集合）５０は、顧客固有のアプリ詳細監視要否判定基準に関する構成要素の特徴を有している。

図１０のアプリ詳細監視要否指標パターンの一覧の顧客は、構成要素ａ，ｅ，ｋ（ウエブサーバの負荷分散装置、業務システムの二重化、ウエブサーバの要求受付用プロセス数の変動大）に該当する業務システム２，３，４全てについてアプリ詳細監視要に設定している。

この顧客の業務システム２，３，４は、構成要素ａに該当するので、ウエブサーバの負荷分散を行ってレスポンスを重視し、業務システムをクラスタによる二重化によりトラブル発生時の堅牢性を高くし、しかし、プロセス数の変動が激しいという構成上の特徴を有する。また、業務システム２，３，４は、構成要素ｆ、ｇ、ｈ、ｉに該当しないのでハードウエアリソースの消費量が少ないという特徴を有する。

したがって、この顧客は、業務システム２，３，４において、ハードウエアリソースの消費量が少ないにもかかわらず、レスポンス重視、堅牢性重視であり、アクセス受付プロセス数の変動が大きいため、アプリ詳細監視を希望している、とみなすことができる。

一方、構成要素ｂ、ｃ（ファイアウオール、データベースサーバへの読み出し／書き込みの両方あり）に該当する業務システム１，５について、業務システム１はアプリ詳細監視要に設定しているが、業務システム５は不要に設定している。そして、構成要素ｇ、ｈ（総メモリ量、通信回線の帯域サイズ）だけに該当する業務システム６にはアプリ詳細監視不要に設定している。

図６に戻り、監視サーバ２２は、シミュレーションシステム配備プログラムを実行して、新業務システムのアプリケーションのリリース通知を受信すると(S31(S12))、アプリ監視要否の自動判定（S14_1,S14_2)を行う。アプリ監視要否の自動判定は、リリースされた新業務システムの指標（構成要素）パターンを抽出する工程（S14_1）と、新業務システムの指標パターンと顧客固有の既存業務システムのアプリ詳細監視要否指標パターンとを比較し、新業務システムの指標パターンと一致する指標パターンの監視要否を抽出する工程（S14_2）とを有する。工程S14_1では、工程S31で説明したのと同じ方法で、新業務システムが各指標（構成要素）に該当するか否かを判定する。一方、工程S14_2については、後で詳述する。

そして、監視サーバは、一致する指標パターンが監視要の場合、新業務システムはアプリ詳細監視要に設定される蓋然性が高いと予測し（S15のYES）、新業務システムのシミュレーションシステムを配備する（S32(S16)）。この予測は、顧客固有のアプリ詳細監視要の指標パターンと一致することに基づいて行われるので、その予測精度は高い。

また、新業務システムのシミュレーションシステムの配備工程は、監視サーバ２２が管理サーバ２１に新業務システムのクローンの仮想マシン群を配備する要求を行うことにより行われる。たとえば、管理サーバ２１は、新業務システムの構成情報ファイルを取得し、それに基づいて新業務システムのクローンの仮想マシン群VMを配備することができる。または、管理サーバ２１は、新業務システムのイメージファイルをコピーし、コピーのイメージファイルの仮想マシン群を起動することで、新業務システムのクローンの仮想マシン群を配備する。

シミュレーションシステムが配備されると、クラウド事業者は、シミュレーションシステムのアプリ監視定義を作成し、監視サーバ２２がアプリ詳細監視を実行し、監視結果を顧客と共に検証する。そして、アプリ監視定義の検証結果が良好の場合、アプリ監視定義の作成工程が終了し、監視サーバ２２は、シミュレーション完了検知プログラムPRG5からシミュレーション完了通知を受信する（S33のYES）。

これに応答して、監視サーバ２２は、シミュレーションシステム配備プログラムの実行により、作成したアプリ監視定義を新業務システムのアプリ監視プログラムに設定する（S34）。この設定により、監視サーバ２２は、新業務システムの本番稼働において、アプリ監視プログラムを実行することで、設定したアプリ監視定義に基づくアプリ詳細監視を実行することができる。

監視サーバ２２は、新業務システムの本番稼働が開始されると（S35のYES）、シミュレーションシステムを削除する（S36(S24)）。

図７は、シミュレーションシステム配備プログラムにおける工程S14_2,S32,S36の詳細処理を示すフローチャート図である。まず、図６の工程S14_2は、図７の工程S14_2〜S14_5で構成される。すなわち、監視サーバ２２は、図７において、新業務システムの指標パターンと顧客固有の既存業務システムのアプリ詳細監視要否指標パターンとを比較し、一致するか否かの判定を行い（S14_2）、一致する指標パターンがある場合（S14_3のYES）、アプリ詳細監視要のパターンとのみ一致するか（S14_4）、アプリ詳細監視不要のパターンとのみ一致するか（S14_5）を判定する。

図１１は、新業務システムの指標パターンの３つの例を示す図である。図１１に示した業務システム名、業務システム１０１は、構成要素ａとｅが該当する指標パターン５１を有する。この指標パターン５１は、図１０の既存業務システムのアプリ詳細監視要否指標パターンの業務システム２，３，４と一致し、それらの業務システム２，３，４は全て監視要に設定されている。したがって、新業務システム１０１は、図７における新業務システムの指標パターンがアプリ詳細監視要のパターンとのみ一致する場合(S14_4のYES)に該当する。

そこで、図７に示されるとおり、監視サーバ２２は、アプリ詳細監視要否指標パターン（図１０）に、新業務システム１０１の指標パターンを監視要で仮登録する（S32_1）。すなわち、図１１の業務システム１０１の監視要否は監視要に仮登録される。そして、監視サーバ２２は、業務システム１０１のクローンのシミュレーションシステムの仮想マシンを優先度「高」で配備するよう、管理サーバ２１に要求する（S32_2）。この優先度は、限りのあるシミュレーション用のリソースプールを有効に活用するための指標であり、優先度が高い業務システムのクローンは、優先度が低い業務システムのクローンより優先してリソースプール内に保持される。

次に、図１１に示した業務システム名、業務システム１０２は、構成要素ｂとｃが該当する指標パターン５２を有する。この指標パターン５２は、図１０の既存業務システムのアプリ詳細監視要否指標パターンの業務システム１，５と一致し、それらの業務システム１，５は一部監視要に、一部監視不要に設定されている。したがって、新業務システム１０２は、図７における新業務システムの指標パターンがアプリ詳細監視要のパターンとのみ一致する場合でもなく(S14_4のNO)、アプリ詳細監視不要のパターンとのみ一致する場合でもない（S14_5のNO）。そこで、図７に示されるとおり、監視サーバ２２は、アプリ詳細監視要否指標パターン（図１０）に、新業務システム１０２の指標パターンを監視要で仮登録する（S32_4）。そして、監視サーバ２２は、業務システム１０２のクローンのシミュレーションシステムの仮想マシンを優先度「低」で配備するよう、管理サーバ２１に要求する（S32_5）。

さらに、図１１に示した業務システム名、業務システム１０３は、構成要素ｇとｈが該当する指標パターン５３を有する。この指標パターン５３は、図１０の既存業務システムのアプリ詳細監視要否指標パターンの業務６と一致し、業務６は監視不要に設定されている。したがって、新業務システム１０３は、図７におけるアプリ詳細監視不要のパターンとのみ一致する場合である（S14_5のYES）。そこで、図７に示されるとおり、監視サーバ２２は、アプリ詳細監視要否指標パターン（図１０）に、新業務システム１０３の指標パターンを監視不要で仮登録する（S32_3）。そして,監視サーバ２２は、新業務システム１０３のクローンのシミュレーションシステムの仮想マシンを配備することは行わない。

また、図７に示されるとおり、新業務システムの指標パターンが、既存業務システムのアプリ詳細監視指標パターンのいずれとも一致しない場合（S14_3のNO）、監視サーバは、アプリ詳細監視要否指標パターン（図１０）に、新業務システム１０２の指標パターンを監視要で仮登録する（S32_4）。そして、監視サーバ２２は、業務１０２のクローンのシミュレーションシステムの仮想マシンを優先度「低」で配備するよう、管理サーバ２１に要求する（S32_5）。既存業務システムの指標パターンのいずれとも一致しない場合、過去におけるアプリ詳細監視の要否判定を利用することができない。そこで、監視要に仮登録し、優先度「低」でクローンを配備する。

上記の監視要否の仮登録は、現時点では顧客からアプリ詳細監視の要否が確定していないためである。本番稼働までにはアプリ詳細監視の要否が確定するので、その時点で、予測が正しければそのままアプリ詳細監視の要否が本登録され、予測が誤りであれば仮登録のアプリ詳細監視の要否は変更される。

次に、図７において、監視サーバ２２は、シミュレーションシステム配備プログラムを実行して、シミュレーションシステムを配備するリソースプールの限りある容量を有効利用するために、リソースプールが一杯の場合(S32_6のYES)、配備済みのシミュレーションシステムを優先度と配備した日時とに基づいて、削除する（S32_7）。

例えば、シミュレーションシステムを配備するリソースプール内に優先度高の新業務システムと優先度低の新業務システムのクローンが配備されている場合、監視サーバ２２は、優先度低の新業務システムのクローンのうち配備日時が古い順に削除してリソースプールに空きを作成する。リソースプール内に優先度高の新業務システムのクローンだけが配備されている場合、監視サーバ２２は、配備日時が古い順に削除する。

図１２は、シミュレーションシステム配備プログラムが管理するシミュレーションシステム配備管理テーブル例を示す図である。監視サーバ２２は、図１２に示した配備管理テーブルを維持して、シミュレーションシステムの配備を管理する。図１２のシミュレーションシステム配備管理テーブルには、シミュレーションシステムの仮想マシンID（シミュレーション用VM ID）と、本番稼働する業務システムの仮想マシンID(本番VM ID)と、業務システム名と、リリース日時と、配備の優先度とが示されている。そして、前述の業務システム１０１，１０２が優先度高、優先度低でそれぞれ配備管理テーブルに登録され、配備されている。さらに、図１２には、業務システム１０６が新たに優先度高で登録追加されることが示される。

監視サーバ２２は、前述の優先度と配備日時に基づいて配備済みシミュレーションシステムの仮想マシンを削除する場合、この配備管理テーブルから削除し、管理サーバ２１に削除を依頼する。

図７の工程S32_6,S32_7は、工程S14_2の前の段階で行うようにしても良い。

［アプリ監視定義］
次に、図５におけるアプリ監視定義の作成工程S18,S19について具体例を示して説明する。図１３は、アプリ監視定義の作成工程のフローチャート図である。図１４、図１５は、監視サーバ２２でのアプリ監視定義の設定画面例を示す図である。

監視サーバ２２が、アプリ監視定義作成プログラムPRG4(図４参照)を実行し、クラウド事業者がアプリ監視定義画面でアプリ監視定義を設計する（S180）。

図１４の画面例には、アプリケーションの詳細監視の稼働時間帯を設定する画面４０が示される。この画面４０によれば、アプリ詳細監視の稼働時間帯が開始時刻と停止時刻で設定される。開始時刻と停止時刻のペアを複数設定して、例えば昼間の稼働時間帯と夜間の稼働時間帯を個別の設定するようにしてもよい。

図１４の画面例には、アプリ監視の詳細設定の画面４２も示される。この画面４２によれば、プロセス数の監視における上限値の設定と下限値の設定を行うことができる。

図１５の画面例には、CPU使用率とメモリ容量の監視用の閾値を設定する画面４４が示される。この画面４４によれば、CPU使用率のタブを選択した状態で、異常を出力する場合の上限値と下限値の設定及び、警告を出力する場合の上限値と下限値の設定を行うことができる。メモリ容量のタブを選択すると、CPU使用率と同様のメモリ容量の異常または警告を出力する場合の上限値と下限値の設定画面が表示される。

図１３に戻り、監視サーバ２２は、管理サーバ２１にシミュレーションシステムを起動させアプリを実行させるよう要求し、設定したアプリ監視定義でシミュレーションシステムについてアプリ詳細監視を実行する（S181）。このアプリ詳細監視では、アプリ監視定義で設定した警告メッセージや異常メッセージなどが出力される。

このようなアプリ詳細監視による監視結果（メッセージなど）について、顧客と共有して監視結果が良好か否か判定される。この判定は、例えばクラウド事業者と新業務システムの顧客とが共同して行う。そして、監視結果が良好と判定されると（S182のYES）、クラウド事業者はアプリ監視定義画面上でアプリ監視定義終了操作を行う（S184）。この終了操作により、シミュレーション完了検知プログラムPRG5(図４参照)は、シミュレーションが完了したことを検知する。

監視結果が良好と判定されない場合（S182のNO）、クラウド事業者は、顧客と協議して、アプリ監視定義画面上で監視定義の設定を変更する（S183）。そして、監視サーバ２２は、変更されたアプリ監視定義に基づくアプリ詳細監視テストを再度行う（S181）。

以上のとおり、アプリ監視定義画面上で監視定義の設定を変更しながら、アプリ詳細監視のテストを繰り返すことで、適切なアプリ監視定義を作成することができる。

［第２の実施の形態］
第２の実施の形態では、監視サーバ２２は、図６のシミュレーションシステム配備プログラムの実行中、既存業務システムのアプリ詳細監視要否指標パターンを抽出する工程S30にて、抽出した指標パターンの監視要否判定に所定の補正を加える。

既存業務システムのアプリ詳細監視要否指標パターンの補正は、既存業務システムが例外的な理由でアプリ詳細監視要に設定されている場合は、監視不要に変更し、例外的な理由でアプリ詳細監視不要に設定されている場合は、監視要に変更する。このように補正することで、新業務システムのアプリ詳細監視要否指標パターンの監視要否を、例外的な理由を問うことなく、既存業務システムの監視要否に基づいて判定することができる。

図１６は、工程S30におけるアプリ詳細監視要否の補正工程での処理を示すフローチャート図である。既存業務システムについてアプリ詳細監視要と設定されている場合（S301のYES）、アプリケーションの異常終了が頻繁に発生しているか、アプリケーションのリリース回数が多いなどの例外的な理由がある場合（S302のYES）、アプリ詳細監視不要に変更する（S303）。

このような例外的な理由は、アプリケーションの品質が悪く、異常終了が頻繁に発生したり、デバックとリリースを繰り返したりしていることである。このような理由がある場合、業務自体の重要度が低い場合でも、アプリケーションの停止を早期に検知し、再起動操作などが必要になるので、アプリ詳細監視要に設定されていると考えられる。したがって、補正工程でアプリ詳細監視不要に変更する。

また、既存業務システムについてアプリ詳細監視不要と設定されている場合（S304のYES）、アプリの異常終了時に自動復旧（再起動）が行われているなどの例外的な理由がある場合（S305のYES）、アプリ詳細監視要に変更する（S306）。

このような例外的な理由は、業務自体が重要などの理由で本来ならアプリ詳細監視が必要であるが、アプリケーションが異常終了すると自動復旧機能により業務システムが自動的に復旧するので、アプリ詳細監視不要に設定されていると考えられる。したがって、補正工程でアプリ詳細監視要に変更する。

上記のような補正工程を加えることにより、既存業務システムのアプリ詳細監視要と不要の設定が例外的な理由により本来の要否と逆に設定されている場合、本来の要否に修正することができ、その後の新規業務システムのアプリ詳細監視要否判定を適切に行うことができる。

以上の通り、本実施の形態によれば、顧客固有のアプリ詳細監視要否の判定基準に基づいて、新規業務システムのアプリ詳細監視要否の判定を行うことで、判定精度を高くすることができる。したがって、新規業務システムのアプリケーションがリリースされて最終段階のテストに入る際に、新規業務システムのクローンのシミュレーションシステムを予め配備しておき、最終段階のテスト中または本番稼働直前に顧客からアプリ詳細監視の要求がされた場合、短期間で監視定義を作成することができる。また、監視要否の判定精度が高いので、限られたリソースプールを効率的にシミュレーションシステムの配備に利用することができる。

以上の実施の形態をまとめると，次の付記のとおりである。

（付記１）
第1のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と所定の類似関係を有する第２の構成要素群に対応する前記第２のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第１のシステムの設定情報として出力する、
処理をコンピュータに実行させるシステムの監視に関する設定支援プログラム。

（付記２）
前記監視に関する設定情報は、システムが実行するアプリケーションの監視要否を含む、付記１に記載の設定支援プログラム。

（付記３）
さらに、前記処理は、
前記所定の類似関係を有する第２のシステムの監視に関する設定情報が監視要の場合、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを配備する、付記２に記載の設定支援プログラム。

（付記４）
さらに、前記処理は、
作成した監視定義に基づいて、前記シミュレーションシステムのアプリケーションの動作を監視する、付記３に記載の設定支援プログラム。

（付記５）
前記配備する処理において、
前記所定の類似関係を有する複数の第２のシステムの監視に関する設定情報がすべて監視要の場合、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを、第１の優先度で配備し、
前記所定の類似関係を有する複数の第２のシステムの監視に関する設定情報の一部が監視要の場合、前記仮想マシンを、前記第１の優先度より低い第２の優先度で配備し、
前記配備した仮想マシンを、前記優先度と配備した日時とに基づいて、削除する、付記３に記載の設定支援プログラム。

（付記６）
前記削除する処理において、前記優先度が低く配備した日時が古い仮想マシンから削除する、付記５に記載の設定支援プログラム。

（付記７）
前記設定情報を特定する処理において、前記第１のシステム情報に含まれる前記第１の構成要素群と所定の類似関係を有する第２の構成要素群に対応する前記第２のシステムが見つからない場合、前記第１のシステムの設定情報を監視要の設定情報と特定する、付記２に記載の設定支援プログラム。

（付記８）
さらに、前記処理は、
第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて抽出する処理を有する、付記１に記載の設定支援プログラム。

（付記９）
前記第２のシステムが所定の条件を満たす場合、前記抽出した設定情報を変更する処理を有する、付記８に記載の設定支援プログラム。

（付記１０）
第1のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と所定の類似関係を有する第２の構成要素群に対応する前記第２のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第１のシステムの設定情報として出力する、
処理を有する設定支援方法。

（付記１１）
プロセッサと、
記憶部とを有し、
前記プロセッサは、
第1のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と所定の類似関係を有する第２の構成要素群に対応する前記第２のシステムの監視に関する設定情報を特定し、
特定した前記設定情報を前記第１のシステムの設定情報として出力する、
処理を実行するシステムの監視に関する設定支援装置。

１０：顧客環境
１１：アプリ開発／テスト環境
１２：業務システム３
１３：シミュレーションシステム
１４：リソースプール
１５：顧客端末
SYS1、SYS2：業務システム１，２
２０：クラウド事業者環境
２１：管理サーバ
２２：監視サーバ
２３：シミュレーションシステム
２４：リソースプール
２５：インフラ監視定義、インフラ監視パターン
２６；アプリ監視定義、アプリ監視パターン
PRG1：アプリケーション監視プログラム
PRG2：リリース検知プログラム
PRG3：シミュレーションシステム配備プログラム
PRG4：シミュレーションシステムの監視定義作成工程
PRG5：シミュレーション完了検知プログラム
５０：第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報の一覧
５１−５３：第１のシステムの第１の構成要素群と監視設定情報

Claims

新たに本番稼働を開始される前の第１のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
前記第１のシステムと同じ顧客に属し、既に本番稼働された第２のシステムの第２の構成要素群と前記第２のシステムの監視要否を含む監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と類似する第２の構成要素群に対応する前記第２のシステムの前記監視に関する設定情報を特定し、
特定した前記監視設定情報を前記第１のシステムの監視設定情報として出力し、
前記類似する第２のシステムの前記監視に関する設定情報が監視要の場合、前記顧客から前記第１のシステムの監視指示を受ける前に、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを前記顧客またはクラウド事業者のリソースプールの物理マシンに配備し、
前記シミュレーションシステムで予め作成した監視定義に基づく監視をシミュレーションして前記監視定義の妥当性を評価する、
処理をコンピュータに実行させるシステムの監視に関する設定支援プログラム。
前記監視要否は、システムが実行するアプリケーションの監視要否を含む、請求項１に記載の設定支援プログラム。
前記第１の構成要素群と類似する第２の構成要素群は、前記第１の構成要素群と一致する第２の構成要素群を含む、請求項１に記載の設定支援プログラム。
前記配備する処理において、
前記類似する複数の第２のシステムの監視に関する設定情報がすべて監視要の場合、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを、前記物理マシンに配備し保持する優先度を第１の優先度で前記物理マシンに配備し、
前記類似する複数の第２のシステムの監視に関する設定情報の一部が監視要の場合、前記仮想マシンを、前記第１の優先度より低い第２の優先度で前記物理マシンに配備し、
前記仮想マシンを前記物理マシンに新たに配備する場合、前記物理マシンが一杯の場合、配備済の仮想マシンを、前記仮想マシンの優先度が低い順に、そして前記仮想マシンを配備した日時が古い順に、削除する、請求項１に記載の設定支援プログラム。
前記設定情報を特定する処理において、前記第１のシステム情報に含まれる前記第１の構成要素群と類似する第２の構成要素群に対応する前記第２のシステムが見つからない場合、前記第１のシステムの設定情報を監視要の設定情報と特定する、請求項１に記載の設定支援プログラム。
前記処理は、さらに、
第２のシステムの第２の構成要素群と前記第２のシステムの監視に関する設定情報とを複数の第２のシステムについて抽出する処理を有する、請求項１に記載の設定支援プログラム。
新たに本番稼働を開始される前の第１のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
前記第１のシステムと同じ顧客に属し、既に本番稼働された第２のシステムの第２の構成要素群と前記第２のシステムの監視要否を含む監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と類似する第２の構成要素群に対応する前記第２のシステムの前記監視に関する設定情報を特定し、
特定した前記監視設定情報を前記第１のシステムの監視設定情報として出力し、
前記類似する第２のシステムの前記監視に関する設定情報が監視要の場合、前記顧客から前記第１のシステムの監視指示を受ける前に、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを前記顧客またはクラウド事業者のリソースプールの物理マシンに配備し、
前記シミュレーションシステムで予め作成した監視定義に基づく監視をシミュレーションして前記監視定義の妥当性を評価する、
処理を有する設定支援方法。
プロセッサと、
記憶部とを有し、
前記プロセッサは、
新たに本番稼働を開始される前の第１のシステムの第１の構成要素群を含む第１のシステム情報の入力を受け付け、
前記第１のシステムと同じ顧客に属し、既に本番稼働された第２のシステムの第２の構成要素群と前記第２のシステムの監視要否を含む監視に関する設定情報とを複数の第２のシステムについて記憶する記憶部を参照して、前記第１のシステム情報に含まれる前記第１の構成要素群と類似する第２の構成要素群に対応する前記第２のシステムの前記監視に関する設定情報を特定し、
特定した前記監視設定情報を前記第１のシステムの監視設定情報として出力し、
前記類似する第２のシステムの前記監視に関する設定情報が監視要の場合、前記顧客から前記第１のシステムの監視指示を受ける前に、前記第１のシステムに対応するシミュレーションシステムを構成する仮想マシンを前記顧客またはクラウド事業者のリソースプールの物理マシンに配備し、
前記シミュレーションシステムで予め作成した監視定義に基づく監視をシミュレーションして前記監視定義の妥当性を評価する、
処理を実行するシステムの監視に関する設定支援装置。