(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023183139
(43)【公開日】2023-12-27
(54)【発明の名称】モデル作成装置、方法及びプログラム
(51)【国際特許分類】
G06F 11/34 20060101AFI20231220BHJP
【ＦＩ】
G06F11/34 147
【審査請求】未請求
【請求項の数】7
【出願形態】ＯＬ
(21)【出願番号】P 2022096609
(22)【出願日】2022-06-15
(71)【出願人】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(74)【代理人】
【識別番号】110001737
【氏名又は名称】弁理士法人スズエ国際特許事務所
(72)【発明者】
【氏名】田中 佑弥
(72)【発明者】
【氏名】山元 和子
(72)【発明者】
【氏名】山下 剛
(72)【発明者】
【氏名】鷲見 毅
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042JJ29
5B042MA08
5B042MA14
5B042MC09
5B042MC22
(57)【要約】
【課題】監視システム検証用モデルを容易に作成することが可能なモデル作成装置、方法及びプログラムを提供することにある。
【解決手段】実施形態に係るモデル作成装置は、第１及び第２変換処理手段と、第１～第３作成手段とを具備する。第１変換処理手段は、監視システムの第１定義ファイルをアラートモデルに変換する。第２変換処理手段は、サーバ装置に関する第２定義ファイル及びアプリケーションプログラムに関する第３定義ファイルをネットワークモデルに変換する。第１作成手段は、第３定義ファイル及び検査式情報に基づいて検査式を作成する。第２作成手段は、状態遷移ルール、アラートモデル及びネットワークモデルに基づいて状態遷移情報を作成する。第３作成手段は、アラートモデル、ネットワークモデル、検査式及び状態遷移情報から構成される監視システム検証用モデルを作成する。
【選択図】図３
【解決手段】実施形態に係るモデル作成装置は、第１及び第２変換処理手段と、第１～第３作成手段とを具備する。第１変換処理手段は、監視システムの第１定義ファイルをアラートモデルに変換する。第２変換処理手段は、サーバ装置に関する第２定義ファイル及びアプリケーションプログラムに関する第３定義ファイルをネットワークモデルに変換する。第１作成手段は、第３定義ファイル及び検査式情報に基づいて検査式を作成する。第２作成手段は、状態遷移ルール、アラートモデル及びネットワークモデルに基づいて状態遷移情報を作成する。第３作成手段は、アラートモデル、ネットワークモデル、検査式及び状態遷移情報から構成される監視システム検証用モデルを作成する。
【選択図】図３
【特許請求の範囲】
【請求項1】
サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行する第１変換処理手段と、
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行する第２変換処理手段と、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成する第１作成手段と、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成する第２作成手段と、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成する第３作成手段と
を具備するモデル作成装置。
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行する第２変換処理手段と、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成する第１作成手段と、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成する第２作成手段と、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成する第３作成手段と
を具備するモデル作成装置。
【請求項2】
前記監視システム検証用モデルは、モデル記述言語で記述される請求項１記載のモデル作成装置。
【請求項3】
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報に基づいて、前記監視システム検証用モデルを検査する検査手段を更に具備する請求項１記載のモデル作成装置。
【請求項4】
前記監視システムの仕様に基づいて前記検査式情報を作成する第４作成手段を更に具備する請求項１記載のモデル作成装置。
【請求項5】
前記監視システムの仕様及び前記検査式情報に基づいて前記状態遷移に関するルールを作成する第５作成手段を更に具備する請求項１記載のモデル作成装置。
【請求項6】
モデル作成装置が実行する方法であって、
サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行するステップと、
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行するステップと、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成するステップと、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成するステップと、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成するステップと
を具備する方法。
サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行するステップと、
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行するステップと、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成するステップと、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成するステップと、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成するステップと
を具備する方法。
【請求項7】
モデル作成装置のコンピュータによって実行されるプログラムであって、
前記コンピュータに、
サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行するステップと、
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行するステップと、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成するステップと、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成するステップと、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成するステップと
を実行させるためのプログラム。
前記コンピュータに、
サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行するステップと、
前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行するステップと、
前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成するステップと、
前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成するステップと、
前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、モデル作成装置、方法及びプログラムに関する。
【背景技術】
【0002】
近年では、例えばサーバ装置上で所定のアプリケーションプログラムが動作することによって様々なサービスを提供することが知られている。
【0003】
この場合、上記したサーバ装置の動作を監視することによって当該サーバ装置を実現するＩＴインフラ（ＩＴ分野におけるインフラストラクチャ）及び当該サーバ装置上で動作するアプリケーションプログラムの障害を発見し、当該障害に関するアラートを出力するように動作する監視システムを運用する場合が多い。なお、ＩＴインフラの障害とは、例えばＩＴインフラ（サーバ装置）のリソースの枯渇やＩＴインフラ自体の不具合等により、プログラムの動作に影響を及ぼすような状態をいう。また、アプリケーションプログラムの障害とは、例えば当該アプリケーションプログラムが想定通りに動作せず、異常な応答をするような状態をいう。
【0004】
ここで、安定したサービスの提供を実現するためには上記した監視システムが適切に動作する必要があるが、当該監視システムの動作は、上記した監視システム、ＩＴインフラ及びアプリケーションプログラム等をモデル化することによって作成される監視システム検証用モデルを検査することによって検証することができる。しかしながら、このような監視システム検証用モデルを作成することは困難である。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特許第５９６６８９０号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
そこで、本発明が解決しようとする課題は、監視システム検証用モデルを容易に作成することが可能なモデル作成装置、方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0007】
実施形態に係るモデル作成装置は、第１変換処理手段と、第２変換処理手段と、第１作成手段と、第２作成手段と、第３作成手段とを具備する。前記第１変換処理手段は、サーバ装置の動作を監視する監視システムの第１定義ファイルを、当該監視システムから出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換する処理を実行する。前記第２変換処理手段は、前記サーバ装置に関する情報が記載された第２定義ファイル及び当該サーバ装置上で動作するアプリケーションプログラムに関する情報が記載された第３定義ファイルを、前記サーバ装置及び前記監視システムを接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理を実行する。前記第１作成手段は、前記第３定義ファイル及び前記監視システムの仕様に基づく検査式情報に基づいて検査式を作成する。前記第２作成手段は、前記監視システムの状態遷移に関するルール、前記アラートモデル及び前記ネットワークモデルに基づいて遷移する前記監視システムの複数の状態を示す状態遷移情報を作成する。前記第３作成手段は、前記アラートモデル、前記ネットワークモデル、前記検査式及び前記状態遷移情報から構成される監視システム検証用モデルを作成する。
【図面の簡単な説明】
【0008】
【図1】監視システムの一例について説明するための図。
【図2】監視システムが配置されるクラウド環境の一例を示す図。
【図3】実施形態に係るモデル作成装置の機能構成の一例を示すブロック図。
【図4】モデル作成装置のハードウェア構成の一例を示す図。
【図5】モデル作成装置の処理手順の一例を示すフローチャート。
【図6】アラートモデル変換処理の処理手順の一例を示すフローチャート。
【図7】第１定義ファイルの一例を示す図。
【図8】第１定義ファイルから取得される情報の一例を示す図。
【図9】アラート条件式の一例を示す図。
【図10】アラート条件式に対して字句解析が行われた結果を示す図。
【図11】アラート条件式が追加されたアラートモデルの一例を示す図。
【図12】メトリックタイプの一例を示す図。
【図13】メトリックタイプが追加されたアラートモデルの一例を示す図。
【図14】サービスが追加されたアラートモデルの一例を示す図。
【図15】閾値が追加されたアラートモデルの一例を示す図。
【図16】比較が追加されたアラートモデルの一例を示す図。
【図17】ネットワークモデル変換処理の処理手順の一例を示すフローチャート。
【図18】第２定義ファイルの一例を示す図。
【図19】第３定義ファイルの一例を示す図。
【図20】ａｗｓ＿ｖｐｃの情報の一例を示す図。
【図21】ａｗｓ＿ｓｕｂｎｅｔの情報の一例を示す図。
【図22】ａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報の一例を示す図。
【図23】ネットワークテーブルの一例を示す図。
【図24】ａｗｓ＿ｎｅｔｗｏｒｋ＿ｉｎｔｅｒｆａｃｅの情報の一例を示す図。
【図25】インスタンスの情報の一例を示す図。
【図26】第３定義ファイルから取得される情報の一例を示す図。
【図27】ｄｏｃｋｅｒの情報の一例を示す図。
【図28】インスタンスの情報から作成されるａｃｌの状態を示す情報の一例を示す図。
【図29】インスタンスのモデルの一例を示す図。
【図30】ネットワークモデルの一例を示す図。
【図31】検査式作成処理の処理手順の一例を示すフローチャート。
【図32】検査式情報格納部のデータ構造の一例を示す図。
【図33】検査式情報格納部から取得される検査式情報の一例を示す図。
【図34】検査式の一例を示す図。
【図35】監視システムが有する状態の要素とプロパティとを示す図。
【図36】第１状態遷移ルールに基づいて遷移する監視システムの状態を示す図。
【図37】第２状態遷移ルールに基づいて遷移する監視システムの状態を示す図。
【図38】第３状態遷移ルールに基づいて遷移する監視システムの状態を示す図。
【図39】状態遷移情報の概要を説明するための図。
【図40】モデル検査の概要を説明するための図。
【図41】モデル検査において発見される反例の一例を示す図。
【発明を実施するための形態】
【0009】
以下、図面を参照して、実施形態について説明する。
本実施形態に係るモデル作成装置は、監視システムの動作を検証するために用いられる監視システム検証用モデルを作成する機能を有する装置である。
本実施形態に係るモデル作成装置は、監視システムの動作を検証するために用いられる監視システム検証用モデルを作成する機能を有する装置である。
【0010】
まず、図１を参照して、監視システムについて説明する。図１に示す監視システム１０は、例えばサーバ装置２０の動作を監視し、当該サーバ装置２０の動作（当該サーバ装置２０を実現するＩＴインフラ及び当該サーバ装置２０上で動作するアプリケーションプログラムの障害等）に関するアラートを出力するように構成されたシステムである。なお、アラートは、例えばメール等によりシステム管理者に通知されてもよい。
【0011】
ここで、監視システム１０は、人手で構築されることも可能であるが、構築自動化ソフトウェアが定義ファイルを元に自動構築されることが一般的である。本実施形態において想定される構築自動ソフトウェアには、インフラ管理ソフトウェア及びコンテナ管理ソフトウェアが含まれる。
【0012】
インフラ管理ソフトウェアは、上記したサーバ装置２０を実現するためのＩＴインフラ（例えば、監視システム１０とサーバ装置２０との間のネットワーク等）を自動構築するソフトウェアである。なお、ＩＴインフラによって実現されるサーバ装置２０は、仮想的に構築されたサーバ装置であってもよい。
【0013】
コンテナ管理ソフトウェアは、コンテナ型仮想化を利用してオペレーティングシステム（ＯＳ）上に構築されるコンテナを管理するソフトウェアである。なお、コンテナ型仮想化とは、コンピュータの仮想化の方式の１つであり、稼働中のオペレーティングシステムの一部を分離して他と隔離された専用のエリアを用意し、当該エリア（コンテナ）上でソフトウェア（アプリケーションプログラム等）を動作させる方式をいう。
【0014】
監視システム１０は、上記したインフラ管理ソフトウェア及びコンテナ管理ソフトウェアによって自動的に構築することが可能である。
【0015】
以下の説明では、インフラ管理ソフトウェアとしてＴｅｒｒａｆｏｒｍ（登録商標）を用い、コンテナ管理ソフトウェアとしてｄｏｃｋｅｒ－ｃｏｍｐｏｓｅを用いる場合を想定している。この場合、インフラ管理ソフトウェア（Ｔｅｒｒａｆｏｒｍ）の定義ファイルはｔｅｒｒａｆｏｒｍ．ｔｆであり、コンテナ管理ソフトウェア（ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅ）の定義ファイルはｄｏｃｋｅｒ－ｃｏｍｐｏｓｅ．ｙｍｌである。ｔｅｒｒａｆｏｒｍ．ｔｆは例えばサーバ装置２０に関する情報が記載された定義ファイルに相当し、ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅ．ｙｍｌは例えばサーバ装置２０上で動作するアプリケーションプログラムに関する情報が記載された定義ファイルに相当する。
【0016】
ここで、サーバ装置２０上にはコンテナ環境が構築されており、当該コンテナ（環境）においては、監視対象のアプリケーションプログラム２１、監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３が動作する。
【0017】
アプリケーションプログラム２１は、サーバ装置２０が所定のサービスを提供するために動作するソフトウェアである。
【0018】
監視エージェントは、統合監視ソフトウェア１２がメトリックスデータを収集できるように、メトリックスデータを公開している。監視エージェントのメトリックスデータは、リソースデータやアプリケーションデータなどがある。監視エージェント２２（コンテナ）は、コンテナアプリケーションのリソース利用状況が公開されている。監視エージェント（サーバ）２３はＥＣ２インスタンスのリソース状況を公開している。アプリケーションも監視エージェント機能を持つ場合、メトリックスデータを公開している。
【0019】
監視エージェント（サーバ）２３は、サーバ装置２０のリソースデータを取集するためのソフトウェア（アプリケーションプログラム）である。また、監視エージェント（サーバ）２３は、リソース監視以外にも、サービス監視も行う場合がある。この場合、監視エージェント（サーバ）２３は、メトリックスデータを公開する。監視エージェント（サーバ）２３によって公開されるメトリックスデータには、リソースデータやサービスの稼働状況等がある。近年では、アプリケーション自体に、メトリックスデータを公開する機能もある。
【0020】
監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３は、監視システム１０による監視を実現するために当該監視システム１０の一部として動作する。
【0021】
一方、監視システム１０上では、サービス監視環境においてサービス監視エージェント１１が動作する。なお、サービス監視エージェント１１は、監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３のような監視エージェントの一種である。サービス監視エージェント１１は、上記したアプリケーションプログラム２１が動作することによって提供されるサービスの稼働状況に関するデータを取集するためのソフトウェア（アプリケーションプログラム）である。
【0022】
更に、監視システム１０による監視を実現するためには、統合監視ソフトウェア１２が必要である。統合監視ソフトウェア１２は、監視システム環境において上記した各監視エージェントを介して得られる監視データの検索及び当該監視データの保管を行う監視データベース１３等と連携して動作する。具体的には、統合監視ソフトウェア１２は、各監視エージェントにアクセスしてデータを取集する機能、時系列データ（監視データ）を管理する機能及びアラートに関するルールを定義する機能等を有する。
【0023】
以下の説明では、統合監視ソフトウェア１２としてＰｒｏｍｅｔｈｅｕｓ（登録商標）を用いる場合を想定している。この場合、統合監視ソフトウェア１２の定義ファイル（監視におけるアラートに関するルールが定義されている定義ファイル）は、ｒｕｌｅｓ．ｙｍｌである。なお、このｒｕｌｅｓ．ｙｍｌは、監視システム１０の定義ファイル（監視システムの監視対象やアラートを出力するための閾値等を定義している形式的なファイル）に相当する。
【0024】
なお、本実施形態においては、例えば図２に示すように、監視システム１０がＡＷＳ（Amazon Web Service）（登録商標）ネットワークのようなクラウド環境に配置されることを想定している。具体的には、図２に示す例では、図１に示すサーバ装置２０がプライベート環境で動作するサーバ装置２０ａ及びパブリック環境で動作するサーバ装置２０ｂを含むような構成を想定している。なお、プライベート環境とは外部ネットワークからアクセスすることができないネットワーク環境を意味し、パブリック環境とは外部ネットワークからアクセスすることができるネットワーク環境を意味する。
【0025】
ところで、上記したような監視システム１０の動作を検証するためには監視システム検証用モデルを作成することが有用であるが、監視システム１０のシステム管理者は、大規模化しているクラウドシステム（監視システム１０、ＩＴインフラ及びアプリケーションプログラム２１等によって実現されるシステム）の構成を把握していない場合が多く、監視システム１０の動作の検証に必要な当該クラウドシステムの構成要素または制約条件等を抽出して監視システム検証用モデルを作成することが困難である。
【0026】
また、監視システム検証用モデルを作成するためにはクラウドシステムの動作を分析する必要があるが、当該分析には時間がかかる。更に、監視システム１０の実運用を通じて不具合が発見された場合には手戻りコストが掛かる。
【0027】
そこで、本実施形態においては、監視システム検証用モデルを自動的に作成することが可能なモデル作成装置を提供する。
【0028】
図３は、本実施形態に係るモデル作成装置の機能構成の一例を示すブロック図である。図３に示すように、アラートモデル変換処理部３１、ネットワークモデル変換処理部３２、検査式情報格納部（検査式情報ＤＢ）３３、検査式作成部３４、状態遷移ルール格納部（状態遷移ルールＤＢ）３５、状態遷移作成部３６、モデル作成部３７、検査式情報登録部３８及び状態遷移ルール登録部３９を含む。
【0029】
アラートモデル変換処理部３１は、監視システム１０（統合監視ソフトウェア１２）の定義ファイルを取得する。監視システム１０の定義ファイルは、例えばＰｒｏｍｅｔｈｅｕｓのｙｍｌファイル（ｒｕｌｅｓ．ｙｍｌ）である。なお、監視システム１０の定義ファイルは、例えばモデル作成装置３０とは異なる外部装置等から取得されるが、モデル作成装置３０内において管理されていてもよい。また、ｒｕｌｅｓ．ｙｍｌはアラートルールを記載したファイルであるが、監視システム１０の定義ファイルには、図１９のような監視システムアプリを記載したファイル及び図１８のような監視システム１０のインフラを記載したファイル等が更に含まれる。
【0030】
アラートモデル変換処理部３１は、取得された監視システム１０の定義ファイルをアラートモデルに変換する処理を実行する。なお、アラートモデルは、例えば監視システム１０から出力されるアラートに関する設定内容がモデル化されることによって作成される。
【0031】
ネットワークモデル変換処理部３２は、上記したインフラ管理ソフトウェアの定義ファイル（サーバ装置２０に関する情報が記載された定義ファイル）及びコンテナ管理ソフトウェアの定義ファイル（サーバ装置２０上で動作するアプリケーションプログラムに関する情報が記載された定義ファイル）を取得する。インフラ管理ソフトウェアの定義ファイルは例えばＴｅｒｒａｆｏｒｍのｔｆファイル（ｔｅｒｒａｆｏｒｍ．ｔｆ）であり、コンテナ管理ソフトウェアの定義ファイルは例えばｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイル（ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅ．ｙｍｌ）である。なお、インフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルは、例えばモデル作成装置３０とは異なる外部装置等から取得されるが、モデル作成装置３０内において管理されていてもよい。
【0032】
ネットワークモデル変換処理部３２は、取得されたインフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルをネットワークモデルに変換する処理を実行する。なお、ネットワークモデルは、例えば監視システム１０とサーバ装置２０（サーバ装置２０ａ及び２０ｂ）とを接続するネットワークに関する設定内容がモデル化されることによって作成される。
【0033】
検査式情報格納部３３には、例えば監視システム１０の仕様書（に記載されている機能要件等の仕様）に基づく検査式情報が格納される。なお、検査式情報格納部３３は、過去の検査式に関する検査式情報を蓄積するように構成されている。
【0034】
検査式作成部３４は、コンテナ管理ソフトウェアの定義ファイルを取得し、当該定義ファイル及び検査式情報格納部３３に格納されている検査式情報に基づいて検査式を作成する。なお、検査式とは、監視システム１０の仕様書からシステムの性質を定義し、論理式で表現したものに相当する。
【0035】
状態遷移ルール格納部３５には、例えば監視システム１０の状態遷移に関するルール（以下、状態遷移ルールと表記）が格納される。なお、上記したように監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３は監視システム１０の一部として動作することから、本実施形態における監視システム１０の状態遷移には、サーバ装置（プライベート環境）２０ａ及びサーバ装置（パブリック環境）２０ｂの状態遷移も含まれる。
【0036】
状態遷移作成部３６は、状態遷移ルール格納部３５に格納されている状態遷移ルール、アラートモデル変換処理部３１によって監視システム１０の定義ファイルから変換されたアラートモデル、ネットワークモデル変換処理部３２によってインフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルから変換されたネットワークモデルに基づいて遷移する監視システム１０の複数の状態を示す状態遷移情報を作成する。
【0037】
モデル作成部３７は、アラートモデル変換処理部３１によって監視システム１０の定義ファイルから変換されたアラートモデル、ネットワークモデル変換処理部３２によってインフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルから変換されたネットワークモデル、検査式作成部３４によって作成された検査式及び状態遷移作成部３６によって作成された状態遷移情報から構成される監視システム検証用モデルを作成する。モデル作成部３７によって作成される監視システム検証用モデルは、形式検証モデルとも称される。
【0038】
なお、モデル作成部３７によって作成された監視システム検証用モデルは、モデル格納部４０に格納される。
【0039】
検査式情報登録部３８は、上記した監視システム１０の仕様書に基づいて検査式情報を作成し、当該作成された検査式情報を検査式情報格納部３３に登録する。
【0040】
状態遷移ルール登録部３９は、例えば監視システム１０の仕様書及び検査式情報格納部３３に格納されている検査式情報に基づいて状態遷移ルールを作成し、当該作成された状態遷移ルールを状態遷移ルール格納部３５に登録する。
【0041】
上記した監視システム１０の仕様書（の情報）は、例えばモデル作成装置３０とは異なる外部装置において管理されていてもよいし、モデル作成装置３０内において管理されていてもよい。
【0042】
なお、上記したようにモデル格納部４０に監視システム検証用モデルが格納されると、モデル検査部５０は、当該監視システム検証用モデルを検査する。なお、監視システム検証用モデルの検査は、モデルの状態を網羅的に検査し、システムの性質を確認するためのモデル検査ツールを用いて実施される。このように監視システム検証用モデルを検査することによって、監視システム１０の動作を検証することができる。モデル検査部５０による検査結果（例えば、監視システム１０の不具合状態等）は、検査結果格納部６０に格納（登録）される。
【0043】
図３においては、例えば検査式情報登録部３８及び状態遷移ルール登録部３９がモデル作成装置３０に含まれるものとして説明したが、当該検査式情報登録部３８及び状態遷移ルール登録部３９の一部または全ては、モデル作成装置３０の外部に配置されていてもよい。また、検査式情報格納部３３がモデル作成装置３０の外部装置に配置されており、検査式作成部３４が当該外部装置から検査式情報を取得する構成であってもよい。同様に、状態遷移ルール格納部３５がモデル作成装置３０の外部装置に配置されており、状態遷移作成部３６が当該外部装置から状態遷移ルールを取得する構成であってもよい。
【0044】
更に、本実施形態においてはモデル格納部４０、モデル検査部５０及び検査結果格納部６０がモデル作成装置３０の外部に配置される場合を想定しているが、当該モデル格納部４０、モデル検査部５０及び検査結果格納部６０の一部または全ては、モデル作成装置３０に含まれていてもよい。
【0045】
【0046】
ＣＰＵ３０１は、モデル作成装置３０内の各コンポーネントの動作を制御するプロセッサである。ＣＰＵ３０１は、ストレージデバイスである不揮発性メモリ３０２から主メモリ３０３にロードされる様々なプログラムを実行する。このプログラムには、オペレーティングシステム及び上記した監視システム検証用モデルを作成するためのプログラム（以下、モデル作成プログラムと表記）等が含まれる。
【0047】
通信デバイス３０４は、例えばモデル作成装置３０とは異なる外部装置との通信を実行するように構成されたデバイスである。
【0048】
図４においては、ＣＰＵ３０１、不揮発性メモリ３０２、主メモリ３０３及び通信デバイス３０４のみが示されているが、モデル作成装置３０は、例えばＨＤＤ（Hard Disk Drive）及びＳＳＤ（Solid State Drive）のような他の記憶装置等を更に備えていてもよいし、他のデバイスを更に備えていてもよい。
【0049】
なお、本実施形態において、モデル作成装置３０に含まれるアラートモデル変換処理部３１、ネットワークモデル変換処理部３２、検査式作成部３４、状態遷移作成部３６、検査式情報登録部３８及び状態遷移ルール登録部３９の一部または全ては、ＣＰＵ３０１（つまり、モデル作成装置３０）がモデル作成プログラムを実行すること、すなわち、ソフトウェアによって実現される。なお、これらの各部３１、３２、３４、３６、３８及び３９の一部または全ては、ＩＣ（Integrated Circuit）等のハードウェアによって実現されてもよいし、ソフトウェア及びハードウェアの組み合わせによって実現されてもよい。
【0050】
また、本実施形態において、モデル作成装置３０に含まれる検査式情報格納部３３及び状態遷移ルール格納部３５は、不揮発性メモリ３０２またはその他の記憶装置等によって実現される。
【0051】
なお、図３に示すモデル検査部５０がモデル作成装置３０に含まれる場合には、当該モデル検査部５０は、ＣＰＵ３０１がモデル作成プログラムを実行することによって実現されればよい。また、図３に示すモデル格納部４０及び検査結果格納部６０がモデル作成装置３０に含まれる場合には、当該モデル格納部４０及び検査結果格納部６０は、不揮発性メモリ３０２またはその他の記憶装置等によって実現されればよい。
【0052】
以下、図５のフローチャートを参照して、本実施形態に係るモデル作成装置３０の処理手順の一例について説明する。
【0053】
まず、監視システム１０を構築する場合、監視システム１０のシステム管理者（開発者）は、当該監視システム１０の設計書を作成する。なお、監視システム１０の設計書とは、例えば監視システム１０のＩＴインフラ・システム構成図等の設計が記載された書類に相当する。
【0054】
一般的には、上記したシステム管理者によって作成された監視システム１０の設計書に基づいて監視システム１０が構築されるが、本実施形態においては、監視システム１０の設計書が作成された後、当該監視システム１０が構築される前に、当該監視システム１０の動作を検証するための監視システム検証用モデルが作成される。
【0055】
この場合、アラートモデル変換処理部３１は、上記した監視システム１０の設計書に基づく当該監視システム１０の定義ファイルを入力し、アラートモデル変換処理を実行する（ステップＳ１）。ステップＳ１の処理が実行されると、アラートモデル変換処理部３１は、アラートモデルを出力する。なお、アラートモデル変換処理の詳細については後述する。
【0056】
また、ネットワークモデル変換処理部３２は、インフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルを入力し、ネットワークモデル変換処理を実行する（ステップＳ２）。ステップＳ２の処理が実行されると、ネットワークモデル変換処理部３２は、ネットワークモデルを出力する。なお、ネットワークモデル変換処理の詳細については後述する。
【0057】
なお、上記したステップＳ１及びＳ２の処理の順番は入れ替えられてもよいし、当該ステップＳ１及びＳ２の処理は並列に実行されてもよい。
【0058】
次に、検査式作成部３４は、コンテナ管理ソフトウェアの定義ファイル及び検査式情報格納部３３に格納されている検査式情報を入力し、検査式作成処理を実行する（ステップＳ３）。ステップＳ３の処理が実行されると、検査式作成部３４は、検査式を出力する。なお、検査式作成処理の詳細については後述する。
【0059】
また、状態遷移作成部３６は、アラートモデル変換処理部３１から出力されたアラートモデル、ネットワークモデル変換処理部３２から出力されたネットワークモデル及び状態遷移ルール格納部３５に格納されている状態遷移ルールを入力し、状態遷移作成処理を実行する（ステップＳ４）。ステップＳ４の処理が実行されると、状態遷移作成部３６は、状態遷移情報を出力する。なお、状態遷移作成処理の詳細については後述する。
【0060】
なお、上記したステップＳ３及びＳ４の処理の順番は入れ替えられてもよいし、当該ステップＳ３及びＳ４の処理は並列に実行されてもよい。
【0061】
次に、モデル作成部３７は、アラートモデル変換処理部３１から出力されたアラートモデル、ネットワークモデル変換処理部３２から出力されたネットワークモデル、検査式作成部３４から出力された検査式及び状態遷移作成部３６から出力された状態遷移情報から構成される監視システム検証用モデルを作成する（ステップＳ５）。なお、ステップＳ５においては、上記したアラートモデル、ネットワークモデル、検査式及び状態遷移情報をモデル記述言語に自動変換する処理が実行される。
【0062】
上記したステップＳ５において作成された監視システム検証用モデルは、監視システム１０の動作を検証するために検査される。本実施形態においては、この監視システム検証用モデルの検査結果に基づいて、監視システム１０の自動構築または監視システム１０の設計書の再作成等が実施される。具体的には、監視システム検証用モデルを検査した結果、監視システム１０が正常に動作することが確認された場合には監視システム１０の自動構築が実施されればよいし、当該監視システム１０が正常に動作しない（不具合が生じる）ことが確認された場合にはシステム管理者による監視システム１０の設計書の再作成が実施されればよい。なお、この監視システム検証用モデルの検査（モデル検査）の詳細については後述する。
【0063】
【0064】
本実施形態におけるアラートモデル変換処理は、監視システム１０の定義ファイルを、監視システム１０から出力されるアラート（警告または通知等）に関する設定内容がモデル化されたアラートモデルに変換する処理である。
【0065】
まず、アラートモデル変換処理部３１は、監視システム１０の定義ファイルとして、Ｐｒｏｍｅｔｈｅｕｓのｙｍｌファイル（ｒｕｌｅ．ｙｍｌ）を入力する（ステップＳ１１）。なお、図７は、ステップＳ１１において入力されたＰｒｏｍｅｔｈｅｕｓのｙｍｌファイルの一例を示す。以下、図７に示すＰｒｏｍｅｔｈｅｕｓのｙｍｌファイルを第１定義ファイルと称する。
【0066】
次に、アラートモデル変換処理部３１は、ステップＳ１１において入力された第１定義ファイルから例えばｒｕｌｅを検索する（ステップＳ１２）。ｒｕｌｅはｙｍｌ形式で定義されているため、「キー：バリュー」という形式で表現するハッシュを用いて、データは入れ子構造データを管理している。この場合、アラートモデル変換処理部３１は、第１定義ファイル中のｒｕｌｅｓをキーとして、当該ｒｕｌｅｓの情報（バリュー）を取得する。なお、図７に示す例によれば第１定義ファイル中には複数のｒｕｌｅｓが存在するが、ここでは例えば図８に示す情報が取得されたものとして説明する。
【0067】
【0068】
アラートモデル変換処理部３１は、ステップＳ１３において取得されたアラート条件式に対して字句解析を行う（ステップＳ１４）。なお、図１０は、ステップＳ１４において字句解析が行われた結果を示す。ステップＳ１４の処理が実行されると、アラート条件式は、複数のトークン（文字列の最小単位）に分けられる。
【0069】
本実施形態におけるアラートモデルは、上記したアラート条件式に対して字句解析が行われた結果に基づいて作成される。この場合、図１１に示すようなアラート条件式が追加されたアラートモデルが用意される。
【0070】
次に、アラートモデル変換処理部３１は、ステップＳ１４において字句解析が行われた結果からメトリックタイプ（が記載されているトークン）を取得する（ステップＳ１５）。メトリックタイプは、例えば監視システム１０による監視によって得られる測定値の種別等に相当する。なお、ステップＳ１５において取得されるメトリックタイプは、例えば図１２に示すように予め定められているものとする。すなわち、ステップＳ１５においては、ステップＳ１４において字句解析が行われた結果から、図１２に示すメトリックタイプと一致するメトリックタイプが取得される。なお、図１２に示す予め定められているメトリックタイプ（の情報）は、モデル作成装置３０内において管理されていてもよいし、モデル作成装置３０とは異なる外部装置から取得されてもよい。
【0071】
ステップＳ１４において取得されたメトリックタイプは、図１１に示すアラートモデルに追加される。メトリックタイプは、エージェントタイプと監視対象の組み合わせで作成されている場合が多い。図１０に示す例によれば、ステップＳ１５においては「ｎｏｄｅ＿ｆｉｌｅｓｙｓｔｅｍ＿ｆｒｅｅ＿ｂｙｔｅｓ」がメトリックタイプとして取得され、当該メトリックタイプが追加された図１３に示すアラートモデルが作成される。ここではメトリックタイプがエージェント名及び監視対象であることを想定しているが、メトリックタイプは監視対象名のみであってもよい。
【0072】
次に、アラートモデル変換処理部３１は、ステップＳ１４において字句解析が行われた結果からサービス（が記載されているトークン）を取得する（ステップＳ１６）。
【0073】
ステップＳ１６において取得されたサービスは、図１３に示すアラートモデルに追加される。図１０に示す例によれば、ステップＳ１６においては「ｇｉｔｌａｂ」がサービスとして取得され、当該サービスが追加された図１４に示すアラートモデルが作成される。なお、上記したようにアプリケーションプログラムが動作することによってサービスが提供されるところ、ステップＳ１６においてはサービスとしてアプリケーションプログラム名が取得されている。
【0074】
また、アラートモデル変換処理部３１は、ステップＳ１４において字句解析が行われた結果から閾値（が記載されているトークン）を取得する（ステップＳ１７）。
【0075】
ステップＳ１７において取得された閾値は、図１４に示すアラートモデルに追加される。図１０に示す例によれば、ステップＳ１４において字句解析が行われた結果から「１０２４＊１０２４＊１０２４＊１．５（＝１．５ＧＢ）」が閾値として取得され、当該閾値が追加された図１５に示すアラートモデルが作成される。
【0076】
更に、アラートモデル変換処理部３１は、ステップＳ１４において字句解析が行われた結果から比較（が記載されているトークン）を取得する（ステップＳ１８）。
【0077】
ステップＳ１８において取得された比較は、図１５に示すアラートモデルに追加される。図１０に示す例によれば、ステップＳ１４において字句解析が行われた結果から「＜」が比較として取得され、当該比較が追加された図１６に示すアラートモデルが作成される。
【0078】
上記したようにステップＳ１４において字句解析が行われた結果に基づいてステップＳ１５～Ｓ１８の処理が実行されることによって図１６に示すアラートモデルが作成される（ステップＳ１９）。
【0079】
ステップＳ１９の処理が実行されると、第１定義ファイル中の全てのｒｕｌｅに対してステップＳ１２以降の処理が実行されたか否かが判定される（ステップＳ２０）。
【0080】
全てのｒｕｌｅについて処理が実行されてないと判定された場合（ステップＳ２０のＮＯ）、ステップＳ１２に戻って処理が繰り返される。この場合、上記した処理が実行されていないｒｕｌｅがステップＳ１２において検索され、ステップＳ１３以降の処理が実行される。
【0081】
一方、全てのｒｕｌｅについて処理が実行されたと判定された場合（ステップＳ２０のＹＥＳ）、アラートモデル変換処理は終了される。
【0082】
【0083】
本実施形態におけるネットワークモデル変換処理は、インフラ管理ソフトウェアの定義ファイル及びコンテナ管理ソフトウェアの定義ファイルを、監視システム１０及びサーバ装置２０を接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換する処理である。
【0084】
まず、ネットワークモデル変換処理部３２は、インフラ管理ソフトウェアの定義ファイルとして、Ｔｅｒｒａｆｏｒｍのｔｆファイル（ｔｅｒｒａｆｏｒｍ．ｔｆ）を入力する（ステップＳ２１）。なお、図１８は、ステップＳ２１において入力されたＴｅｒｒａｆｏｒｍのｔｆファイルの一例を示す。図１８に示すＴｅｒｒａｆｏｒｍのｔｆファイルによれば、ＥＣ２（Amazon Elastic Compute Cloud ）インスタンス定義から、ネットワーク環境、メモリ及びディスク容量等の情報を取得することができる。以下、図１８に示すＴｅｒｒａｆｏｒｍのｔｆファイルを第２定義ファイルと称する。
【0085】
また、ネットワークモデル変換処理部３２は、コンテナ管理ソフトウェアの定義ファイルとして、ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイル（ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅ．ｙｍｌ）を入力する（ステップＳ２２）。なお、図１９は、ステップＳ２２において入力されたｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイルの一例を示す。図１９に示すｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイルによれば、監視システム１０の監視エージェントとしてｃａｄｖｉｄｓｏｒ、ｎｏｄｅ＿ｅｘｐｏｔｅｒ及びｂｌａｃｋｂｏｘ ｅｘｐｏｔｅｒが使用されていることが示されている。以下、図１９に示すｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイルを第３定義ファイルと称する。
【0086】
次に、ネットワークモデル変換処理部３２は、ステップＳ２１において入力された第２定義ファイルからａｗｓ＿ｖｐｃの情報を取得する（ステップＳ２３）。なお、ａｗｓ＿ｖｐｃの情報は、例えば監視システム１０が配置されるＡＷＳネットワーク空間を表す。なお、図１８に示す例によれば、ステップＳ２３においては、例えば図２０に示すａｗｓ＿ｖｐｃの情報が取得される。
【0087】
また、ネットワークモデル変換処理部３２は、ステップＳ２１において入力された第２定義ファイルからａｗｓ＿ｓｕｂｎｅｔの情報を取得する（ステップＳ２４）。なお、ａｗｓ＿ｓｕｂｎｅｔの情報は、上記したＡＷＳネットワーク内の部分的なネットワーク空間（サブネットワーク）を表す。なお、図１８に示す例によれば、ステップＳ２４においては、例えば図２１に示すａｗｓ＿ｓｕｂｎｅｔの情報が取得される。
【0088】
更に、ネットワークモデル変換処理部３２は、ステップＳ２１において入力された第２定義ファイルからａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報を取得する（ステップＳ２５）。なお、ａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報は、ネットワーク空間にアクセス可能なポート（ポート番号）を表している。なお、図１８に示すれによれば、ステップＳ２５においては、例えば図２２に示すａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報が取得される。
【0089】
次に、ネットワークモデル変換処理部３２は、ステップＳ２４において取得されたａｗｓ＿ｓｕｂｎｅｔの情報及びステップＳ２５において取得されたａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報に基づいて、ネットワークテーブルを作成する（ステップＳ２６）。
【0090】
ネットワークテーブルは、サブネットワーク間におけるアクセスが可能であるか否かが定義されたテーブルに相当する。ステップＳ２６においては、ステップＳ２４において取得されたａｗｓ＿ｓｕｂｎｅｔの情報によって表されるサブネットワークの組み合わせ毎にステップＳ２５において取得されたａｗｓ＿ｎｅｔｗｏｒｋ＿ａｃｌの情報を保持するネットワークテーブルが作成される。なお、図２３は、ステップＳ２６において作成されたネットワークテーブルの一例を示す。
【0091】
次に、ネットワークモデル変換処理部３２は、ステップＳ２１において入力された第２定義ファイルからインスタンスの情報を取得する（ステップＳ２７）。
【0092】
ここで、上記した図１８は第２定義ファイル（Ｔｅｒｒａｆｏｒｍのｔｆファイル）の一部を示しており、当該第２定義ファイルは、更に図２４に示すａｗｓ＿ｎｅｔｗｏｒｋ＿ｉｎｔｅｒｆａｃｅの情報を含むものとする。
【0093】
この場合、ネットワークモデル変換処理部３２は、第２定義ファイルから図２４に示すａｗｓ＿ｎｅｔｗｏｒｋ＿ｉｎｔｅｒｆａｃｅの情報を取得して、当該情報の中のａｔｔａｃｈｍｅｎｔのｉｎｓｔａｎｃｅと同じＩＤ（ここでは、ａｗｓ＿ｉｎｓｔａｎｃｅ．ｅｃ２０３．ｉｄ）のａｗｓ＿ｉｎｓｔａｎｃｅの情報を取得する。
【0094】
更に、ネットワークモデル変換処理部３２は、取得されたａｗｓ＿ｉｎｓｔａｎｃｅの情報の中のｖｐｃ＿ｓｅｃｕｒｉｔｙ＿ｇｒｏｕｐ＿ｉｄｓのＩＤ（ここでは、ａｗｓ＿ｓｅｃｕｒｉｔｙ＿ｇｒｏｕｐ．ｇｉｔｌａｂ．ｉｄ）と同じＩＤのセキュリティグループの情報をインスタンスの情報として取得する。なお、図２５は、ステップＳ２７において取得されるインスタンスの情報（セキュリティグループの情報）の一例である。このインスタンスの情報は、第２定義ファイルに含まれていてもよいし、当該第２定義ファイル（つまり、図２４に示すａｗｓ＿ｎｅｔｗｏｒｋ＿ｉｎｔｅｒｆａｃｅの情報）とは別のファイルに含まれる情報であってもよい。なお、インスタンスは例えば仮想ＣＰＵＵやディスク、ＩＰアドレスのような様々な情報を有しているが、本実施形態においては、当該インスタンスが所属しているネットワークとインスタンスのセキュリティグループの情報を利用する。セキュリティグループとは、アクセスと出力先のポートとを制御することができるものである。インスタンスは複数のセキュリティグループを有する場合もある。セキュリティグループは、ファイアウォールに近い概念を有する。
【0095】
次に、ネットワークモデル変換処理部３２は、ステップＳ２２において入力された第３定義ファイルからｄｏｃｋｅｒの情報を取得する（ステップＳ２８）。
【0096】
この場合、ネットワークモデル変換処理部３２は、第３定義ファイルから図２６に示す情報を取得する。図２６に示すように第３定義ファイルから取得された情報の中にｌａｂｅｌｓのｍｏｎｉｔｏｒ．ｓｅｒｖｉｃｅ及びｍｏｎｉｔｏｒ．ｎｅｔｗｏｒｋが存在している場合、ネットワークモデル変換処理部３２は、当該ｍｏｎｉｔｏｒ．ｓｅｒｖｉｃｅの値（ここでは、ｇｉｔｌａｂ）及び当該ｍｏｎｉｔｏｒ．ｎｅｔｗｏｒｋの値（ここでは、ａｗｓ－ｐｕｂｌｉｃ）を監視対象の情報として取得することができる。また、ネットワークモデル変換処理部３２は、第３定義ファイルから取得された情報の中のｌａｂｅｌｓのｍｏｎｉｔｏｒ．ａｇｅｎｔの値を監視エージェントの情報として取得することができる。ここでは、サーバ装置２０のコンテナ環境で動作するｃａｄｖｉｓｏｒ及びｎｏｄｅ＿ｅｘｐｏｒｔｅｒが監視エージェントの情報として取得される。
【0097】
なお、上記した図１９に示す第３定義ファイル（ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイル）にはｌａｂｅｌｓ（の情報）は記載されていないが、ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅはｌａｂｅｌｓを記載（追加）することができる機能を有している。このようなｌａｂｅｌｓを追加しておくことにより、モデル変換（ネットワークモデル変換処理）を容易にすることができる。アプリケーションのｌａｂｅｌｓには、監視エージェントと監視システムの情報が記載されている。監視システムのエージェントには、監視対象と監視システムの情報が記載されている。このため、監視対象と監視システムの紐づけが容易にすることができる。
【0098】
これにより、ネットワークモデル変換処理部３２は、図２７に示すｄｏｃｋｅｒネットワークの状態を示す情報をｄｏｃｋｅｒの情報として取得することができる。このように取得されたｄｏｃｋｅｒの情報は、監視対象の情報（ｇｉｔｌａｂ及びａｗｓ－ｐｕｂｌｉｃ）及び監視エージェントの情報（ｃａｄｖｉｓｏｒ及びｎｏｄｅ＿ｅｘｐｏｒｔｅｒ）を含む。また、ｄｏｃｋｅｒネットワークの状態を示す情報においては、例えば「ｔｏ」の欄に記載されているアプリケーションプログラム（監視対象のアプリケーションプログラム及び監視エージェント）にアクセスするためのポート（番号）が「ｆｒｏｍ」の欄に記載されている。
【0099】
次に、ネットワークモデル変換処理部３２は、ステップＳ２７において取得されたインスタンスの情報（セキュリティグループの情報）及びステップＳ２８において取得されたｄｏｃｋｅｒの情報（ｄｏｃｋｅｒネットワークの状態を示す情報）に基づいて、インスタンスのモデルを作成する（ステップＳ２９）。この場合、ネットワークモデル変換処理部３２は、図２８に示すようにインスタンスの情報からａｃｌの状態を示す情報（ａｃｌの状態の集合）を作成し、当該ａｃｌの状態を示す情報と、上記したｄｏｃｋｅｒネットワークの状態を示す情報（ｄｏｃｋｅｒの情報）とを含むインスタンスのモデルを作成する。なお、インスタンスのモデルには、エキスポーターに関する情報（エキスポーターの集合）が更に含まれる。このエキスポーターに関する情報には、監視エージェント（ｃａｄｖｉｓｏｒ及びｎｏｄｅ＿ｅｘｐｏｒｔｅｒ）、当該監視エージェントに対応するメトリックタイプ及び閾値等が含まれる。
【0100】
なお、図２９は、ステップＳ２９において作成されるインスタンスのモデルの一例を示す。図２９に示すエキスポーターに関する情報には監視エージェント及びメトリックタイプに対応づけてｎｕｌｌが含まれているが、当該ｎｕｌｌは、監視システムが監視エージェントにアクセスできると分かった場合に、当該監視エージェント及びメトリックタイプに対応する閾値に更新される。アクセス可能かどうかは、ネットワークモデルによって判定できる。
【0101】
次に、ネットワークモデル変換処理部３２は、ステップＳ２６において作成されたネットワークテーブル及びステップＳ２９において作成されたインスタンスのモデルを含むネットワークモデル（ＡＷＳネットワークのモデル）を作成する（ステップＳ３０）。
【0102】
ここで、図３０は、ステップＳ３０において作成されるネットワークモデルの一例を示している。なお、ネットワークモデルには、ＥＣ２インスタンス（アプリケーションプログラム）毎に作成されたインスタンスのモデルが含まれる。具体的には、インスタンスのモデルは、コード化されたＥＣ２毎に作成される。
【0103】
【0104】
まず、検査式作成部３４は、コンテナ管理ソフトウェアの定義ファイルとして、ｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイルを入力する（ステップＳ３１）。ここでは、上記した図１９に示すｄｏｃｋｅｒ－ｃｏｍｐｏｓｅのｙｍｌファイルに上記したｌａｂｅｌの情報が追加されたもの（第３定義ファイル）が入力されたものとする。
【0105】
次に、検査式作成部３４は、ステップＳ３１において入力された第３定義ファイルから上記した図２６に示す情報を取得する。検査式作成部３４は、このように第３定義ファイルから取得された情報の中のｍｏｎｉｔｏｒ．ｓｅｒｖｉｃｅの値（ここでは、ｇｉｔｌａｂ）を監視対象の情報として取得し、当該情報の中のｍｏｎｉｔｏｒ．ａｇｅｎｔの値（ｃａｄｖｉｓｏｒ及びｎｏｄｅ＿ｅｘｐｏｒｔｅｒ）を監視エージェントの情報として取得する（ステップＳ３２）。
【0106】
ここで、検査式作成処理においては、検査式情報格納部３３に格納されている検査式情報に基づいて検査式が作成される。検査式情報は監視システム１０の仕様書に基づいて予め作成（登録）されているものとする。
【0107】
なお、本実施形態において監視システム１０の仕様書には、例えばアプリケーションプログラム２１が動作することによって提供されるサービスの稼働状況を把握するためのサービス監視の監視項目（例えば、ポート、ネットワーク経路及びプロセス監視等）やリソースの変化を監視するリソース監視の監視項目（例えば、ＣＰＵ使用率、メモリ使用率、ロードアベレージ、ディスクＩ／Ｏの使用率、ディスク使用率及びネットワーク帯域使用率等）が記述されている。なお、サービス監視の監視項目は、監視されるサービスに依存する。一方、リソース監視の監視項目は、仮想ハードウェアに依存するが、例えば予め決めされている場合も多い。
【0108】
ここで、図３２は、検査式情報格納部３３のデータ構造の一例を示す。図３２に示すように、検査式情報格納部３３には、複数の検査式情報が格納されており、当該複数の検査式情報の各々は、監視対象を分類する監視タイプと、使用される監視エージェントを表すエージェントタイプと、監視対象のアプリケーションプログラム（が動作することによって提供されるサービス）を表すサービスタイプと、監視タイプ及び監視エージェントによって定まるメトリックタイプと、監視対象に依存する閾値及び比較とを含む。
【0109】
再び図３１に戻ると、検査式作成部３４は、ステップＳ３２において取得された監視対象及び監視エージェントの情報に基づいて、検査式情報格納部３３から検査式情報を取得する（ステップＳ３３）。
【0110】
なお、上記した図２６に示す例によれば、ステップＳ３２においては監視対象の情報としてｇｉｔｌａｂ及び監視エージェントの情報としてｃａｄｖｉｓｏｒ及びｎｏｄｅ＿ｅｘｐｏｒｔｅｒが取得されている。検査式作成部３４は、この監視対象の情報及び監視エージェントの情報に基づいて、図３２に示す検査式情報格納部３３から図３３に示す検査式情報を取得する。ここでは、監視システム１０の仕様として、監視タイプがｍｅｍｏｒｙ、ｈｔｔｔ及びｄｉｓｋである検査式情報を取得することが必須である場合を想定している。
【0111】
また、上記した図３３に示す検査式情報が取得された場合、ｃａｄｖｉｓｏｒからはｍｅｍｏｒｙの値を取得することができ、ｎｏｄｅ＿ｅｘｐｏｒｔｅｒからはｍｅｍｏｒｙ及びｄｉｓｋの値を取得することができることがわかる。
【0112】
次に、検査式作成部３４は、ステップＳ３３において取得された検査式情報に基づいて検査式を作成する（ステップＳ３４）。なお、図３４は、上記した図３３に示す検査式情報に基づいて作成された検査式の一例を示す。図３４に示す検査式は、図３３に示す検査式情報を時相論理で表現することによって作成される。
【0113】
【0114】
図３５に示す例では、監視システム１０が有する要素には、監視システム１０上に構築されているサービス監視環境で動作するサービス監視エージェント１１及び当該監視システム１０上に構築されている監視システム環境で動作する統合監視ソフトウェア１２が含まれる。また、監視システム１０が有する要素には、サーバ装置２０（プライベート環境で動作するサーバ装置２０ａまたはパブリック環境で動作するサーバ装置２０ｂ）上に構築されているコンテナ環境において動作する監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３が含まれる。
【0115】
プロパティは監視システム１０の状態に相当し、サービス監視エージェント１１のプロパティには、「閾値ｏｖｅｒ」、「閾値以内」及び「取得不可」が含まれる。取得不可は、監視システムが監視エージェント接続できない状態で、メトリックスの値としてはｎｕｌｌになる。「閾値ｏｖｅｒ」、「閾値以内」は、アラートルールによって、メトリックスの値は決まる。監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３のプロパティについても同様である。一方、統合監視ソフトウェア１２のプロパティには、「アラートあり」及び「アラートなし」が含まれる。
【0116】
ここで、状態遷移作成処理においては、状態遷移ルール格納部３５に格納されている状態遷移ルールに基づいて状態遷移情報が作成される。なお、状態遷移ルール情報は例えば検査式情報格納部３３に格納されている検査式情報及び監査システム１０の仕様書に基づいて予め作成（登録）されているものとする。
【0117】
以下、状態遷移ルールについて説明する。ここでは、第１～第３状態遷移ルールについて説明する。
【0118】
まず、第１状態遷移ルールにおいては、監視システム１０が監視エージェントにアクセスすることができる場合、プロパティ「閾値ｏｖｅｒ」とプロパティ「閾値以内」との間で状態が遷移（推移）することができる。
【0119】
なお、図３６は、第１状態遷移ルールに基づいて遷移する監視システム１０（ここでは、監視エージェント（コンテナ）２２）の状態を示している。
【0120】
具体的には、ステップＳ４１においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値ｏｖｅｒ」に遷移することが示されている。更に、ステップＳ４２においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値ｏｖｅｒ」からプロパティ「閾値ｏｖｅｒ」に遷移することが示されている。また、ステップＳ４３においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値ｏｖｅｒ」からプロパティ「閾値以内」に遷移することが示されている。
【0121】
一方、ステップＳ４４においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値以内」に遷移することが示されている。更に、ステップＳ４５においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値ｏｖｅｒ」に遷移することが示されている。また、ステップＳ４６においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値以内」に遷移することが示されている。
【0122】
次に、第２状態遷移ルールにおいては、監視システム１０が監視エージェントにアクセスすることができない場合、プロパティ「取得不可」からプロパティ「取得不可」に状態が遷移する。
【0123】
なお、図３７は、第２状態遷移ルールに基づいて遷移する監視システム１０（ここでは、監視エージェント（コンテナ）２２）の状態を示している。
【0124】
具体的には、ステップＳ５１においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「取得不可」からプロパティ「取得不可」に遷移することが示されている。
【0125】
また、第３状態遷移ルールにおいては、監視システム１０（統合監視ソフトウェア１２）の状態（アラート）はプロパティ「アラートあり」とプロパティ「アラートなし」との間で遷移（推移）することができる。
【0126】
なお、図３８は、第３状態遷移ルールに基づいて遷移する統合監視ソフトウェア１２の状態を示している。
【0127】
具体的には、ステップＳ６１においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値ｏｖｅｒ」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートなし」からプロパティ「アラートあり」に遷移することが示されている。更に、ステップＳ６２において、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値ｏｖｅｒ」からプロパティ「閾値ｏｖｅｒ」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートあり」からプロパティ「アラートあり」に遷移することが示されている。また、ステップＳ６３においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値ｏｖｅｒ」からプロパティ「閾値以内」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートあり」からプロパティ「アラートなし」に遷移することが示されている。
【0128】
一方、ステップＳ６４においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値以内」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートなし」からプロパティ「アラートなし」に遷移することが示されている。更に、ステップＳ６５において、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値ｏｖｅｒ」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートなし」からプロパティ「アラートあり」に遷移することが示されている。また、ステップＳ６６においては、例えば監視エージェント（コンテナ）２２の状態がプロパティ「閾値以内」からプロパティ「閾値以内」に遷移することによって、統合監視ソフトウェア１２の状態がプロパティ「アラートなし」からプロパティ「アラートなし」に遷移することが示されている。
【0129】
図３６～図３８においては監視システム１０の状態遷移の一例について説明したが、状態遷移作成部３６は、例えば図３９に示すように、上記した第１～第３状態遷移ルールに基づいて遷移する監視システム１０（サービス監視エージェント１１、統合監視ソフトウェア１２、監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３）の様々な状態（当該状態の全てのパターン）を示す状態遷移情報を作成することができる。
【0130】
本実施形態においては、上記したアラートモデル変換処理、ネットワークモデル変換処理、検査式作成処理及び状態遷移作成処理の結果をモデル記述言語に自動変換することにより、アラートモデル、ネットワークモデル、検査式及び状態遷移情報から構成される監視システム検証用モデル（モデル記述言語で記述されたモデル）を作成することができる。
【0131】
なお、本実施形態においては上記したように作成された監視システム検証用モデルを検査することによって監視システム１０の動作を検証することができる。以下、監視システム検証用モデルの検査（モデル検査）の概要について簡単に説明する。
【0132】
モデル検査は監視システム検証用モデルを構成するアラートモデル、ネットワークモデル、検査式及び状態遷移情報に基づいて実施されるが、図４０に示すように、当該モデル検査においては、監視システム１０の仕様書に基づく検査式から求めた状態と監視システム１０の定義ファイル（設計書）に基づくアラートモデル及びネットワークモデルから求めた状態とを状態遷移情報（によって示される各状態）に従って比較する。これによれば、監視システム１０の仕様書と設計書との間で一致していない状態（反例）を発見することができる。
【0133】
なお、監視エージェント（サービス監視エージェント１１、監視エージェント（コンテナ）２２及び監視エージェント（サーバ）２３）にアクセスすることができるか否かは、上記したネットワークモデルに基づいて判定することができる。また、閾値は、上記したアラートモデル及び検査式から定義することができる。更に、統合監視ソフトウェア１２の状態（アラート状態）は、上記したアラートモデルに基づいて判定することができる。
【0134】
ここで、図４１は、モデル検査において発見される反例の一例を示す。図４１に示す例においては、監視システム１０の仕様（検査式）として常に２ＧＢ以上のディスク容量を確保する必要があるところ、当該監視システム１０の定義ファイル（アラートモデル）では１．５ＧＢ未満でアラートが出力される設計となっている（つまり、２ＧＢ未満であってもアラートが出力されない場合がある）ため、反例が発見されたことが示されている。
【0135】
本実施形態においては、このように反例が発見された場合には、当該反例が発見されたこと（つまり、監視システム１０の不具合）がシステム管理者に通知される。この場合、システム管理者は、通知された反例に従って監視システム１０の設計書を再作成することができる。
【0136】
一方、モデル検査において反例が発見されない場合には、例えばシステム管理者の指示に応じて構築自動化ソフトウェア（インフラ管理ソフトウェア及びコンテナ管理ソフトウェア）が起動され、システム管理者によって作成された監視システム１０の設計書に基づいて当該監視システム１０が自動構築される。
【0137】
上記したように本実施形態においては、サーバ装置２０の動作（つまり、アプリケーションプログラム２１）を監視する監視システム１０の定義ファイル（第１定義ファイル）を、当該監視システム１０から出力されるアラートに関する設定内容がモデル化されたアラートモデルに変換するアラートモデル変換処理が実行され、当該サーバ装置２０に関する情報が記載された定義ファイル（第２定義ファイル）及び当該サーバ装置２０上で動作するアプリケーションプログラム（アプリケーションプログラム２１、監視エージェント２２及び２３等）に関する情報が記載された定義ファイル（第３定義ファイル）を、サーバ装置２０及び監視システム１０を接続するネットワークに関する設定内容がモデル化されたネットワークモデルに変換するネットワークモデル変換処理が実行される。また、本実施形態においては、上記した第３定義ファイル及び監視システム１０の仕様に基づく検査式情報に基づいて検査式を作成し、監視システム１０の状態遷移に関する状態遷移ルール、アラートモデル及びネットワークモデルに基づいて遷移する当該監視システム１０の複数の状態を示す状態遷移情報を作成する。本実施形態においては、上記したアラートモデル、ネットワークモデル、検査式及び状態遷移情報から構成される監視システム検証用モデルが自動作成される。なお、監視システム検証用モデルは、例えばモデル記述言語デコーディングする作業によって作成される。
【0138】
本実施形態においては、上記した構成により、監視システム検証用モデルを容易に作成することができる。
【0139】
なお、監視システム検証用モデル（形式検証モデル）は監視システム１０の動作を検証するために有用であるが、一般的に、当該監視システム検証用モデルの作成には属人的な要素がある。換言すれば、思想や対象のシステムによって監視システム検証用モデルは多種多様に作成され、個人が考えた監視システム検証用モデル（及び制約条件）を用いて監視システム１０の動作の検証（ソフトウェア検証）が行われるため、当該検証は個人の能力に依存した状態となる。
【0140】
これに対して、本実施形態においては、システム構成が記載された形式ファイル（定義ファイル）から監視システム検証用モデルを自動作成することができるため、システム管理者（技術者）によらず、共通のモデルを用いた監視システム１０の検証を実現することができる。
【0141】
更に、一般には監視システム検証用モデルを作成するためにクラウドシステムの動作を分析する必要があるが、本実施形態においては、監視システム検証用モデルの自動作成を実現することにより、当該モデルの作成にかかるコスト（例えば、時間的コスト等）を削減することができる。
【0142】
また、本実施形態においては、一般に監視システム１０の検証したい要件には類似点が多い点に着目し、過去の検査式に関する情報（検査式情報格納部３３に格納されている検査式情報）を利用して検査式が自動作成される。これによれば、検査式の作成にかかるコストを削減するとともに、検査式の作成が個人に依存することを回避することができる。
【0143】
なお、本実施形態に係るモデル作成装置３０は、少なくとも監視システム検証用モデルを作成するように構成されていればよいが、上記したアラートモデル、ネットワークモデル、検査式及び状態遷移情報に基づいて監視システム検証用モデルを検査するように構成されていてもよい。これによれば、監視システム検証用モデルを用いて監視システム１０の動作を検証することができる。
【0144】
また、本実施形態に係るモデル作成装置３０は、検査式を作成するために利用される検査式情報を監視システム１０の仕様に基づいて自動作成（登録）するように構成されていてもよいし、監視システム１０の仕様及び検査式情報に基づいて状態遷移ルールを自動作成（登録）するように構成されていてもよい。これによれば、例えばシステム管理者が検査式情報及び状態遷移ルールを用意する必要がないため、更に時間的コスト等を削減することが可能となる。
【0145】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0146】
１０…監視システム、１１…サービス監視エージェント、１２…統合監視ソフトウェア、１３…監視データベース、２０，２０ａ，２０ｂ…サーバ装置、２１…アプリケーションプログラム、２２…監視エージェント（コンテナ）、２３…監視エージェント（サーバ）、３０…モデル作成装置、３１…アラートモデル変換処理部、３２…ネットワークモデル変換処理部、３３…検査式情報格納部、３４…検査式作成部、３５…状態遷移ルール格納部、３６…状態遷移作成部、３７…モデル作成部、３８…検査式情報登録部、３９…状態遷移ルール登録部、４０…モデル格納部、５０…モデル検査部、６０…検査結果格納部。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】