JP7286995B2 - 監視システム、監視方法および監視プログラム - Google Patents

Description

本発明は、監視システム、監視方法および監視プログラムに関する。

クラウドコンピューティング、DevOps、コンテナ型仮想化技術等の普及により、大規模なサービスや業務システムのバージョンであっても、ユーザの需要が取り込まれた新しいバージョンが容易にリリースされている。すなわち、上記の技術が普及する前よりも、サービス等のバージョンが高頻度で更新されている。

サービスの提供者には、ユーザの需要を迅速に取り込むことが求められる。よって、アプリケーションの性能情報を監視することを目的とするソフトウェアにも、監視対象の業務システム等のバージョンが更新される早さに対応することが求められる。

バージョンの更新頻度が上記の技術が普及する前よりも高くなかった時期において、ソフトウェアの開発者は、バージョンが更新される度にどのような情報を監視するかを改めて検討し、定義するという対応をとることができた。

上記の技術が普及し、ユーザが意識しないうちにバージョンが更新されることが多い現在であっても、ソフトウェアが継続して監視できるような対応をとることが、ソフトウェアの開発者には求められる。

例えば、高頻度でバージョンが更新されるサービスを提供する情報システムの性能をソフトウェアで監視する場合、運用管理者は、バージョンが更新される度に逐一監視の内容を設定する。バージョンが更新される度に逐一監視の内容を設定する方法がとられると、総合的には監視の内容の設定に多くの時間がかかる。

情報システムの監視では通常、収集対象の性能情報に対して閾値を設定し、性能情報の閾値の超過を性能の異常として検知する方法が採用される。しかし、閾値を設定せずに情報システムを監視する方法も存在する。

閾値を設定せずに情報システムを監視する方法として、例えば、特許文献１に記載されているベースライン監視方法がある。特許文献１に記載されているベースライン監視方法は、情報システムにかかる負荷に周期性が存在することに着目する方法である。

具体的には、特許文献１に記載されているベースライン監視方法は、所定期間の性能情報を基にベースラインを生成し、生成されたベースラインを閾値の代わりに用いる。ベースラインによる監視において、運用管理者には、バージョンが更新される度に監視における閾値を逐一設定することが求められない。

また、特許文献２には、ベースライン生成の期間を短縮することに着目した管理計算機が記載されている。特許文献２に記載されている管理計算機は、同一のオートスケーリンググループに属する複数の仮想演算部の性能情報をベースラインの生成に利用する。特許文献２に記載されている管理計算機は、複数の性能情報をベースラインの生成に利用するという、ベースラインの学習期間が短くてもベースラインが生成できる方法を提案している。

また、特許文献３には、バージョンの更新前後に渡る監視の継続性に着目したアプリケーション管理システムが記載されている。特許文献３に記載されているアプリケーション管理システムは、バージョンが更新される前のアプリケーションの性能情報と、バージョンが更新された後のアプリケーションの性能情報とを比較することによって、性能に変化が生じたと思われる項目をユーザに提示する。

特開２００４－１６４６３７号公報 国際公開第２０１７／１６８４８４号 国際公開第２０１８／０３７５６１号

特許文献１に記載されているベースライン監視方法が使用された場合、ベースラインの再生成には時間がかかるという課題がある。高頻度でバージョンが更新されるようなシステムの運用で採用されても、特許文献１に記載されているベースライン監視方法がバージョンの更新の早さと同じ早さでベースラインを再生成することは困難である。

また、特許文献２に記載されている管理計算機は、バージョンの更新を想定していない。一般的に、バージョンが更新されると、情報システムの性能の傾向や負荷状況に変化が生じる可能性が高い。よって、旧バージョンのベースラインがそのまま利用されて監視が行われると、性能の傾向の変化が誤って異常と検知されてしまう恐れがある。

通常、ベースラインの算出方式は、性能情報の平均値と分散を用いる方式である。バージョンが更新される前のベースラインで状態が安定している個所では、分散の幅が小さい。性能の傾向の変化が誤って異常と検知されてしまう理由は、バージョンが更新されて負荷状況が変わった個所の値が旧バージョンのベースラインの範囲を超過し、異常として検知されてしまうリスクが増加するためである。

上記の問題により、精度が高い監視を継続して行うためには、学習期間が短い特許文献２に記載されている方法が使用される場合であっても、ベースラインを再生成することが求められるという課題がある。すなわち、特許文献２に記載されている方法が使用されても、バージョンの更新の早さと同じ早さでベースラインを再生成することは困難であるという課題は解消されない。

また、特許文献３に記載されているアプリケーション管理システムが使用される場合、ユーザには、新バージョンと旧バージョンとの差異を基に再度監視の設定を行うことが求められる。ユーザが監視の設定を行う場合、操作の誤りの発生や再設定にかかる時間が、例えばDevOpsによる開発を遅らせる要因になる可能性がある。

そこで、本発明は、上述した課題を解決する、バージョンが更新される情報システムの監視用の閾値を利用者が再設定する手間を省くことができる監視システム、監視方法および監視プログラムを提供することを目的とする。

本発明による監視システムは、複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると所定の監視項目が異常であると判断される範囲を、複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると１つ以上の監視対象装置の各性能値を基に更新する更新部を含み、複数の監視対象装置は、いずれもコンテナインスタンスであることを特徴とする。

本発明による監視方法は、複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると所定の監視項目が異常であると判断される範囲を、複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると１つ以上の監視対象装置の各性能値を基に更新し、複数の監視対象装置は、いずれもコンテナインスタンスであることを特徴とする。

本発明による監視プログラムは、コンピュータに、複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると所定の監視項目が異常であると判断される範囲を、複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると１つ以上の監視対象装置の各性能値を基に更新する更新処理を実行させるための監視プログラムであって、複数の監視対象装置は、いずれもコンテナインスタンスであることを特徴とする。

本発明によれば、バージョンが更新される情報システムの監視用の閾値を利用者が再設定する手間を省くことができる。

本発明による監視システムの第１の実施形態の使用例を示す説明図である。 第１の実施形態の監視システム１００の構成例を示すブロック図である。 性能情報記憶部１０９に記憶される性能情報の例を示す説明図である。 グループ情報記憶部１１０に記憶されるグループ情報の例を示す説明図である。 ベースライン記憶部１１２に記憶されるベースライン情報の例を示す説明図である。 構成変更情報記憶部１１１に記憶される構成変更情報の例を示す説明図である。 ローリングアップデート時のコンテナインスタンス数の変化の例を示す説明図である。 第１の実施形態の監視システム１００による通常時の性能異常検知処理の動作を示すフローチャートである。 第１の実施形態の監視システム１００によるベースライン更新処理の動作を示すフローチャートである。 第１の実施形態の監視システム１００によるバージョン更新時の性能異常検知処理の動作を示すフローチャートである。 本発明による監視システムのハードウェア構成例を示す説明図である。 本発明による監視システムの概要を示すブロック図である。

実施形態１．
［構成の説明］
以下、本発明の実施形態を、図面を参照して説明する。図１は、本発明による監視システムの第１の実施形態の使用例を示す説明図である。

図１は、本発明による監視システムと外部のコンポーネントとの関係の概要を示す。図１に示すように、本実施形態の監視システム１００は、端末２００と、コンテナ管理システム３００と、コンテナインスタンス４００～コンテナインスタンス４０Ｎ（Ｎは１以上の整数）とそれぞれ通信可能に接続されている。

また、図１に示すように、コンテナ管理システム３００は、コンテナインスタンス４００～コンテナインスタンス４０Ｎとそれぞれ通信可能に接続されている。以下、図１に示す各コンポーネントが有する役割を説明する。

上記の課題を解決するために、本実施形態では、高頻度でバージョンが更新される情報システムに対して、ベースラインによる監視を行う監視システム１００が使用される。ベースラインは、既知の技術と同様に、同一のオートスケーリンググループに属するコンテナインスタンスの性能情報の平均と分散が利用されて生成される。

本実施形態では高頻度にバージョンが更新される環境としてコンテナ型仮想化技術が利用された情報システムが想定されているため、性能情報の取得対象をコンテナインスタンスとして説明する。

なお、コンテナ型仮想化技術に依存しない場合、既知の技術と同様に、性能情報の取得対象を仮想演算部としてもよい。本実施形態の監視対象は、コンテナ型の仮想化環境に限らず、物理計算機環境、またはハイパーバイザ型の仮想化環境でもよい。

また、本実施形態の監視システム１００は、バージョンの更新前後に渡って、ベースラインを再生成せずに継続して監視を実行できることを特徴とする。バージョンの更新は、通常コンテナインスタンスで用いられるローリングアップデートによる更新である。

監視システム１００は、ローリングアップデート時に１つずつ起動する新しいバージョンのコンテナインスタンスの性能情報を利用して、旧バージョンのコンテナインスタンスの性能情報を基に生成されたベースラインを逐次更新する。

監視システム１００は、バージョンの更新中およびバージョンの更新完了後、逐次更新されたベースラインを使用してコンテナインスタンスを監視することによって、バージョンの更新に合わせてベースラインを再生成せずに済む。

他にも、本実施形態の監視システム１００は、監視対象の情報システムから性能情報を定期的に収集して蓄積する機能と、蓄積された性能情報を基にベースラインを生成する機能と、生成されたベースラインを用いて性能劣化を検知し、運用管理者へ通知する機能とを有する。また、監視システム１００は、監視対象の情報システムのバージョンの更新状況を把握するために、構成情報を収集および管理する機能を有する。

端末２００は、監視システム１００が提供するコンポーネントの１つである。図１に示すように、端末２００は、監視システム１００の外部に配置される。

運用管理者等の監視システム１００の利用者は、端末２００を介して監視システム１００に対する操作、監視システム１００が収集した性能情報の参照、および監視システム１００が検知した性能劣化の通知の受信等を実行できる。端末２００は、監視システム１００に対して一般的に利用者から求められる機能を備える。

コンテナインスタンス４００～コンテナインスタンス４０Ｎは、監視システム１００の監視対象である、１つまたは複数の仮想演算装置である。本実施形態ではコンテナ型仮想化技術の利用が想定されているため、監視対象をコンテナインスタンスとする。

各コンテナインスタンスにおいて、任意のアプリケーションまたはプログラムが稼働する。監視システム１００は、コンテナインスタンス４００～コンテナインスタンス４０Ｎの各性能情報をそれぞれ収集する。

コンテナ管理システム３００は、各コンテナインスタンスの起動、停止、またはオートスケーリング等を実行することによって、各コンテナインスタンスを管理する機能を有する。一般的に、コンテナインスタンスを管理する装置は、オーケストレータ等と呼ばれる。

本実施形態では、コンテナインスタンスを管理する装置を、コンテナ管理システム３００とする。コンテナ管理システム３００は、各コンテナインスタンスとオートスケーリンググループとをそれぞれ対応付ける情報を有する。

コンテナ管理システム３００は、可用性や負荷分散を目的として、所定の機能を有するコンテナインスタンスを複数生成し、生成された数のコンテナインスタンスを維持する機能を有する。また、コンテナ管理システム３００は、負荷状況に応じて自動でコンテナインスタンスを増減させるオートスケーリングを行う機能を有する。

コンテナ管理システム３００は、オートスケーリングをオートスケーリンググループごとに行う。本実施形態では、各コンテナインスタンスのバージョンの更新は、オートスケーリンググループごとに行われる。また、ベースラインも、オートスケーリンググループに属する全てのコンテナインスタンスの各性能情報が利用されて生成される。

コンテナ管理システム３００は、各コンテナインスタンスに対するバージョンの更新要求を受け付け、ローリングアップデートで各コンテナインスタンスのバージョンを更新する。

監視システム１００は、コンテナ管理システム３００から同一オートスケーリンググループに属するコンテナインスタンスの情報や、コンテナインスタンスの起動状況等を示す情報を収集する。監視システム１００は、収集された情報をベースラインの生成や更新に利用する。

上述した通り、本実施形態ではコンテナ型仮想化技術が利用された場合を例に説明する。しかし、監視システム１００が情報を収集でき、バージョンの更新がローリングアップデートで行われ、また監視対象の仮想演算部の構成情報が監視システム１００から取得できれば、監視対象の演算装置は、物理マシンでもよいし、ハイパーバイザ型仮想化技術で生成された仮想マシンでもよい。なお、仮想演算部の構成情報は、バージョンの更新状況を示す情報やオートスケーリンググループの情報である。

次に、監視システム１００が内部および外部に有するコンポーネント、および各コンポーネントが有する役割を、図２を参照して説明する。図２は、第１の実施形態の監視システム１００の構成例を示すブロック図である。

図２に示すように、監視システム１００は、性能情報受付部１０１と、性能情報処理部１０２と、性能異常検知部１０３と、管理情報受付部１０４と、構成変更管理部１０５と、グループ情報管理部１０６と、ベースライン生成部１０７と、操作受付部１０８と、性能情報記憶部１０９と、グループ情報記憶部１１０と、構成変更情報記憶部１１１と、ベースライン記憶部１１２とを含む。

性能情報受付部１０１は、性能情報収集部４１０～性能情報収集部４１Ｎがそれぞれ収集した、コンテナインスタンス４００～コンテナインスタンス４０Ｎの各性能情報を受け付ける機能を有する。性能情報受付部１０１は、受け付けられた各性能情報を性能情報処理部１０２に渡す。

性能情報処理部１０２は、性能情報受付部１０１から性能情報を受け取り、受け取られた性能情報を所定の第１形式に整形してから性能情報記憶部１０９に格納する機能を有する。

性能情報記憶部１０９は、監視対象の性能情報を、例えばファイルやデータベースで記憶する機能を有する。性能情報記憶部１０９は、性能情報を後述する図３に示す形式で保持する。また、提供の要求を受けた場合、性能情報記憶部１０９は、要求対象の性能情報を要求元に提供する。

性能異常検知部１０３は、任意のコンテナインスタンスに対して、コンテナインスタンスの性能情報とベースラインの情報とを取得し、コンテナインスタンスの性能値がベースラインの範囲を超過する場合に「性能に異常あり」として端末２００へ通知する機能を有する。

また、性能異常検知部１０３は、ベースラインの範囲（閾値）を超えた値をユーザに通知する。通知されたユーザが異常か否かを判断しやすいように、性能異常検知部１０３は、ローリングアップデート等が行われるバージョン更新時に、新バージョンのベースラインの範囲と旧バージョンのベースラインの範囲とを合わせてユーザに通知してもよい。

性能異常検知部１０３は、例えば以下のように性能に異常があるか否かを判断する。変化の度合いが小さい場合、例えば新バージョンの性能情報の傾向は、旧バージョンの性能情報の傾向に類似する。よって、性能値が閾値を超えたら、異常である可能性が高い。

しかし、変化の度合いが大きい場合、新バージョンの性能情報の傾向が旧バージョンの性能情報の傾向から変化した可能性があるため、異常か否かの判断が困難になる。よって、例えばコンテナインスタンスで閾値を超えた性能値が他にもあるか否かが考慮される。他にも閾値を超えた性能値がある場合、異常である可能性が高い。

閾値を超えた性能値が他にない場合、異常か否かを判断することが困難であるため、性能異常検知部１０３は、例えばローリングアップデートが完了するまで待機する。

管理情報受付部１０４は、管理情報収集部３１０が収集した構成情報を受け付ける機能を有する。管理情報受付部１０４は、バージョン更新等の構成変更の情報を構成変更管理部１０５へ渡す。また、管理情報受付部１０４は、稼働中のコンテナインスタンスが属するオートスケーリンググループを示す情報をグループ情報管理部１０６へ渡す。

構成変更管理部１０５は、管理情報受付部１０４から渡された構成変更情報を所定の第２形式に整形してから構成変更情報記憶部１１１に格納する機能を有する。

構成変更情報記憶部１１１は、構成変更情報を、例えばファイルやデータベースで記憶する機能を有する。構成変更情報記憶部１１１は、構成変更情報を後述する図６に示す形式で保持する。また、提供の要求を受けた場合、構成変更情報記憶部１１１は、要求対象の構成変更情報を要求元に提供する。

グループ情報管理部１０６は、管理情報受付部１０４から渡されたオートスケーリンググループとコンテナインスタンスとを対応付ける情報であるグループ情報をグループ情報記憶部１１０に格納する機能を有する。

グループ情報記憶部１１０は、グループ情報を、例えばファイルやデータベースで記憶する機能を有する。グループ情報記憶部１１０は、グループ情報を後述する図４に示す形式で保持する。また、提供の要求を受けた場合、グループ情報記憶部１１０は、要求対象のグループ情報を要求元に提供する。

ベースライン生成部１０７は、性能情報に基づいて、オートスケーリンググループごとにベースラインの内容を示すベースライン情報を生成する機能を有する。ベースライン生成部１０７は、生成されたベースライン情報をベースライン記憶部１１２に格納する。

ベースライン記憶部１１２は、ベースライン情報を所定の第３形式で記憶する機能を有する。

操作受付部１０８は、端末２００から操作を受け付ける機能を有する。受け付けられた操作に従って、操作受付部１０８は、ベースラインの再生成や閾値の変更等を、監視システム１００内の各コンポーネントに指示する。

また、図２に示すように、監視システム１００の外部に配置されるコンポーネントとして、端末２００、管理情報収集部３１０、および性能情報収集部４１０～性能情報収集部４１Ｎがある。端末２００、管理情報収集部３１０、および性能情報収集部４１０～性能情報収集部４１Ｎは、いずれも監視システム１００が提供するコンポーネントである。

端末２００は、運用管理者等の監視システム１００の利用者がアクセス可能な端末である。端末２００は、性能異常検知部１０３からの通知を受信し、受信された通知の内容を参照する機能と、監視システム１００を操作する機能とを有する。

端末２００が受信した通知を参照した監視システム１００の利用者は、コンテナインスタンスにおける性能の異常に対して、コンテナ管理システム３００にスケールアウトを実行させる指示を出すという対応をとることができる。

または、監視システム１００の利用者は、監視システム１００にベースラインを変更させる、アプリケーションを修正させる等の指示を出すという対応をとることができる。よって、利用者は、アプリケーションの性能劣化や異常による影響を抑止できる。

管理情報収集部３１０は、コンテナ管理システム３００が保持するコンテナインスタンスの情報を収集する機能を有する。

性能情報収集部４１０～性能情報収集部４１Ｎは、各コンテナインスタンスの性能情報をそれぞれ収集する機能を有する。性能情報収集部４１０～性能情報収集部４１Ｎは、各コンテナインスタンスの内部に配置されてもよいし、外部に配置されてもよい。

以下、監視システム１００内の各記憶部が保持する情報を説明する。図３は、性能情報記憶部１０９に記憶される性能情報の例を示す説明図である。図３に示すように、性能情報は、収集時刻と、インスタンス名と、ＣＰＵ（Central Processing Unit）使用率と、メモリ使用量とで少なくとも構成されている。

収集時刻は、監視対象のコンテナインスタンスから性能情報が収集された時刻である。また、インスタンス名は、性能情報が収集されたコンテナインスタンスの名称である。インスタンス名は、監視対象を一意に特定できる情報である。

また、ＣＰＵ使用率（％）およびメモリ使用量（MB）は、監視対象のコンテナインスタンスから収集された性能値である。なお、監視対象の項目は、ＣＰＵ使用率およびメモリ使用量以外の項目でもよい。監視対象の項目は、任意で指定される。

性能値を収集する監視対象の項目は、運用管理者が任意に定義できる。ただし、同じオートスケーリンググループに属するコンテナインスタンスに対して、性能値が収集される監視対象の項目の種類は、統一されている。

例えば、図３に示す性能情報におけるＣＰＵ使用率とメモリ使用量に関して、運用管理者が端末２００を介して「Postgres-v9グループに属するコンテナインスタンスからはメモリ使用量を収集しない」と定義できる。同様に、運用管理者が端末２００を介して「nginxグループに属するコンテナインスタンスからはディスク使用率（％）の情報を追加で収集する」と定義できる。

しかし、運用管理者は、「ＣＰＵ使用率を、Nginx-01からは収集するが、Nginx-02からは収集しない」と定義しない。定義しない理由は、ベースラインの生成にあたり、ベースライン生成部１０７が同一のオートスケーリンググループに属する各コンテナインスタンスの性能情報を利用するためである。

換言すると、同一のオートスケーリンググループに属するコンテナインスタンスから収集される性能情報が異なると、ベースラインの生成に求められる分だけ性能情報が十分に集まらず、ベースラインの生成に時間がかかるリスクがあるためである。

または、特定のコンテナインスタンスから収集された性能情報に偏って生成されたベースラインが利用されると、他のコンテナインスタンスの監視の精度が低下するリスクがあるためである。

図４は、グループ情報記憶部１１０に記憶されるグループ情報の例を示す説明図である。図４に示すように、グループ情報は、グループ名と、インスタンス名とで構成されている。

グループ名は、上述したオートスケーリングが行われるオートスケーリンググループの名称である。グループ名は、オートスケーリンググループを一意に特定する名称である。

また、インスタンス名は、コンテナインスタンスを一意に特定する名称である。図４に示すインスタンス名は、図３に示すインスタンス名と同一である。

図５は、ベースライン記憶部１１２に記憶されるベースライン情報の例を示す説明図である。図５に示すように、ベースライン情報は、ベースライン時刻と、グループ名と、ＣＰＵ使用率と、メモリ使用量とで少なくとも構成されている。

ベースライン情報は、情報システムの負荷状況等には周期性が存在するという前提の下で、所定の期間ごとに生成される。図５に示す例では、負荷状況の周期が１週間と想定されている。

ベースライン時刻は、性能情報の収集時刻とベースラインとを対応させるための時刻である。図５に示す例では、ベースラインが対応する負荷状況の周期が１週間であるため、ベースライン時刻は、曜日と時刻で表示されている。

もしベースラインが対応する負荷状況の周期が１ヶ月であれば、ベースライン時刻は、「○○日 時刻」のように表示される。ベースラインが対応する負荷状況の周期には、任意の周期が指定されてよい。

グループ名は、オートスケーリンググループの名称である。図５に示すグループ名は、図４に示すグループ名と同一である。すなわち、ベースラインは、特許文献２に記載されているベースラインと同様に、同一のオートスケーリンググループに属する各コンテナインスタンスに共有される。

また、CPU使用率およびメモリ使用量は、グループ名が示すオートスケーリンググループに属するコンテナインスタンスに対する、ベースライン時刻におけるベースラインである。ベースラインの計算式は、例えば以下の式である。

式（１）の第２項が、図５に示すσ（標準偏差）である。なお、式（１）におけるx_iは、グループ名が示すオートスケーリンググループに属する任意のコンテナインスタンスの、ベースライン時刻における性能値である。

また、式（１）の第１項は、グループ名が示すオートスケーリンググループに属する全てのコンテナインスタンスの、ベースライン時刻における性能値の平均値である。また、nは、グループ名が示すオートスケーリンググループに属するコンテナインスタンスの数である。

なお、ベースラインの生成対象の項目は、ＣＰＵ使用率およびメモリ使用量以外の項目でもよい。ベースラインは、図３に示す監視対象の項目毎に生成される。

また、バージョン更新時、ベースライン生成部１０７は、以下の式に従ってベースラインを計算する。

なお、式（２）におけるmは、旧バージョンのコンテナインスタンス数と新バージョンのコンテナインスタンス数の和である。また、式（２）におけるm_oldは、旧バージョンのコンテナインスタンス数である。

ベースライン生成部１０７は、グループ情報記憶部１１０から取得された旧バージョンのグループ情報、および新バージョンのグループ情報を基に、稼働しているコンテナインスタンスの情報を取得する。取得した情報を基に、ベースライン生成部１０７は、ベースラインを更新する。

なお、式（２）において式（１）と異なる項である((m+m_old)/m)は、１から２の間の値をとる。((m+m_old)/m)は、旧バージョンのコンテナインスタンスが多く稼働しているほど２に近づき、新バージョンのコンテナインスタンスが多く稼働しているほど１に近づく。

ベースライン生成部１０７には、ローリングアップデートの序盤は、新バージョンのコンテナインスタンスの性能情報が少なく、旧バージョンのコンテナインスタンスの性能情報が多い状態でベースラインを更新することが求められる。

よって、ベースラインの幅（図５に示すσ）を最大２倍にすることによって、ベースライン生成部１０７は、新バージョンの性能情報に対する誤検知を抑制する。しかし、明らかな異常値等は、ベースラインの範囲を超過する。すなわち、監視を継続して実行する性能異常検知部１０３は、性能の異常を検知できる。

旧バージョンのコンテナインスタンスが全て停止すると、ベースラインの幅は１倍になる。すなわち、ベースラインの計算式（２）が、通常時の計算式（１）と一致する。旧バージョンのコンテナインスタンスが全て停止した時、新バージョンのコンテナインスタンスの性能情報に基づいたベースラインの更新が完了する。

なお、ローリングアップデート等が行われるバージョン更新時にベースラインの計算に使用される計算式は、式（２）以外の計算式でもよい。

図６は、構成変更情報記憶部１１１に記憶される構成変更情報の例を示す説明図である。図６に示すように、構成変更情報は、最終更新時刻と、変更の種類と、旧バージョングループ名と、新バージョングループ名と、旧バージョンインスタンス数と、新バージョンインスタンス数とで構成されている。

旧バージョングループ名は、構成が変更される前のコンテナインスタンスが属するオートスケーリンググループの名称として定義された名称である。また、新バージョングループ名は、構成変更で新たにリリースされるコンテナインスタンスが属するオートスケーリンググループの名称として定義される名称である。

上述したように、グループ名は、オートスケーリンググループを一意に特定する名称である。すなわち、旧バージョングループ名と新バージョングループ名が異なる場合、旧バージョンのコンテナインスタンスが属するオートスケーリンググループと新バージョンのコンテナインスタンスが属するオートスケーリンググループは異なる。

なお、グループ名でバージョンが区別されないように、構成変更情報が他のバージョンの情報を有してもよい。本実施形態では、図６に示す例のように、グループ名でバージョンが区別される。

また、旧バージョンインスタンス数は、構成変更処理が開始された後、旧バージョングループ名が示すオートスケーリンググループに属し、かつ稼働しているコンテナインスタンスの数である。

また、新バージョンインスタンス数は、構成変更処理が開始された後、新バージョングループ名が示すオートスケーリンググループに属し、かつ稼働しているコンテナインスタンスの数である。

図７は、ローリングアップデート時のコンテナインスタンス数の変化の例を示す説明図である。図７に示す黒色の矩形は、稼働しているコンテナインスタンスを表す。また、図７に示す破線の矩形は、停止しているコンテナインスタンスを表す。

ローリングアップデートは、システムを停止させずにシステムを更新する方法である。具体的には、ローリングアップデートは、新バージョンのコンテナインスタンスを１つずつ起動し、代わりに旧バージョンのコンテナインスタンスを１つずつ停止する。なお、ローリングアップデートが１度に起動または停止させるコンテナインスタンスの数は、１つに限られない。

図７（ａ）は、更新開始直後のコンテナインスタンスを示す。図７（ａ）に示すように、ローリングアップデートは、旧バージョンのコンテナインスタンスを１つ停止させた時、新バージョンのコンテナインスタンスを１つだけ稼働させている。

図７（ｂ）は、更新終了直前のコンテナインスタンスを示す。図７（ｂ）に示すように、ローリングアップデートは、新バージョンのコンテナインスタンスを４つ起動させた時。旧バージョンのコンテナインスタンスを１つだけ稼働させている。

上記のように、図６に示す旧バージョンインスタンス数は、図７に示すバージョン更新中に稼働している旧バージョンのコンテナインスタンスの数である。また、図６に示す新バージョンインスタンス数は、図７に示すバージョン更新中に稼働している新バージョンのコンテナインスタンスの数である。

また、変更の種類は、構成変更の種類である。構成変更の種類には、バージョンの更新の他にもスケールアウト、スケールイン、新規追加、および削除等がある。変更の種類には、いずれの情報も指定可能である。本実施形態では、変更の種類は、主にバージョンの更新を意味する。また、最終更新時刻は、構成変更情報が更新された最終時刻である。

［動作の説明］
以下、本実施形態の監視システム１００の動作を図８～図１０を参照して説明する。

ベースラインを利用した監視システム１００の特徴は、バージョン更新時に通常時と異なる方法でベースラインを生成および更新することである。本実施形態の監視システム１００は、図８に示すベースラインを利用した性能異常検知処理と、図９に示すバージョン更新時のベースライン更新処理が組み合わせられた処理を行う。

また、バージョン更新中に新バージョンのコンテナインスタンスに異常を検出した時の処理は、図８に示す処理と異なる。よって、図８に示す処理と異なる部分のみを、図１０に示すバージョン更新時の性能異常検知処理を参照して説明する。以下、各処理を説明する。

最初に、本実施形態の監視システム１００のベースラインを利用した性能の異常を検知する動作を図８を参照して説明する。図８は、第１の実施形態の監視システム１００による通常時の性能異常検知処理の動作を示すフローチャートである。

最初に、性能情報収集部４１０～性能情報収集部４１Ｎは、監視システム１００で指定された収集間隔ごとに、監視対象の各コンテナインスタンスからそれぞれ性能情報を収集する（ステップS101）。性能情報は、図３に示す情報を少なくとも含む。

性能情報収集部４１０～性能情報収集部４１Ｎは、収集された各性能情報を性能情報受付部１０１に送信する。送信した後、性能情報収集部４１０～性能情報収集部４１Ｎは、次の収集のタイミングまで待機する。図８に示す性能異常検知処理は、性能情報の収集を契機に、定期的に実行される。

次いで、性能情報受付部１０１は、性能情報収集部４１０～性能情報収集部４１Ｎよりそれぞれ受信した各性能情報を、性能情報処理部１０２に入力する（ステップS102）。

次いで、性能情報処理部１０２は、性能情報受付部１０１から入力された各性能情報を性能情報記憶部１０９に格納する（ステップS103）。

各性能情報を性能情報記憶部１０９に格納した後、性能情報処理部１０２は、格納した各性能情報を性能異常検知部１０３に入力する（ステップS104）。

次いで、性能異常検知部１０３は、性能情報処理部１０２から各性能情報が入力されると、入力された性能情報に対応するコンテナインスタンスが属するオートスケーリンググループのグループ名を、インスタンス名を基にグループ情報記憶部１１０に問い合わせる。問い合わせた後、性能異常検知部１０３は、グループ情報記憶部１１０からグループ名を取得する（ステップS105）。

例えば、コンテナインスタンス「Nginx-01」の性能情報が入力された場合、性能異常検知部１０３は、コンテナインスタンス「Nginx-01」が属するオートスケ－リンググループをグループ情報記憶部１１０に問い合わせる。問い合わせた後、性能異常検知部１０３は、グループ「nginx」に属するという通知をグループ情報記憶部１１０から受ける。

次いで、性能異常検知部１０３は、ベースライン記憶部１１２に格納されたベースライン情報を参照し、グループ名と性能情報の収集時刻が適合するベースライン情報を取得する（ステップS106）。

例えば、性能情報に含まれる収集時刻（例えば、水曜２１時３０分）と、グループ情報記憶部１１０から取得されたグループ名「nginx」を基に、性能異常検知部１０３は、ベースライン情報を取得する。

次いで、性能異常検知部１０３は、取得されたベースライン情報のベースラインと、性能情報の対応する監視対象の項目の値とを、各性能情報に渡ってそれぞれ比較する（ステップS107）。比較することによって、性能異常検知部１０３は、各性能情報が示す性能項目に異常があるか否かを判断する（ステップS108）。

具体的には、監視対象の項目の値がベースラインの範囲を超えている場合、性能異常検知部１０３は、監視対象の項目に劣化の兆候や異常があると判断する。例えば、コンテナインスタンス「Nginx-01」のＣＰＵ使用率が対応するベースライン情報のＣＰＵ使用率「60±3σ」の範囲を超えた場合、性能異常検知部１０３は、ＣＰＵ使用率が異常であると判断する。

監視対象の項目に異常がないと判断した場合（ステップS108におけるNo）、監視システム１００は、性能異常検知処理を終了する。

監視対象の項目に異常があると判断した場合（ステップS108におけるYes）、性能異常検知部１０３は、異常があると判断された性能情報を端末２００に送信する（ステップS109）。

次いで、監視システム１００の利用者は、送信された性能情報を参照して、操作受付部１０８に異常を解消するための操作を端末２００を介して入力する（ステップS110）。操作が入力された後、監視システム１００は、性能異常検知処理を終了する。

次に、本実施形態の監視システム１００のバージョン更新時のベースラインを更新する動作を図９を参照して説明する。図９は、第１の実施形態の監視システム１００によるベースライン更新処理の動作を示すフローチャートである。

なお、通常時のベースラインの生成方法は、上述したベースライン生成部１０７が有する機能に基づいた方法である。図９は、バージョン更新時のベースライン更新処理を示す。図９に示す処理は、コンテナ管理システム３００に対するバージョンの更新要求を契機に開始される。

コンテナ管理システム３００において常時稼働している管理情報収集部３１０は、コンテナ管理システム３００がバージョンの更新要求を受け付けたことを検知する。検知した後、管理情報収集部３１０は、バージョン更新による構成の変更内容と現在の構成内容とを管理情報受付部１０４に送信する（ステップS201）。

次いで、管理情報受付部１０４は、受信された情報を構成変更情報とグループ情報に分類する。分類した後、管理情報受付部１０４は、構成変更情報を構成変更管理部１０５に入力する（ステップS202）。また、管理情報受付部１０４は、グループ情報をグループ情報管理部１０６に入力する（ステップS203）。

次いで、構成変更管理部１０５は、入力された構成変更情報を構成変更情報記憶部１１１に格納する（ステップS204）。次いで、グループ情報管理部１０６は、入力されたグループ情報をグループ情報記憶部１１０に格納する（ステップS205）。

例えば、グループ情報管理部１０６は、ローリングアップデートにより起動した新バージョンのコンテナインスタンスのグループ情報をグループ情報記憶部１１０に追加する。また、グループ情報管理部１０６は、停止した旧バージョンのコンテナインスタンスのグループ情報をグループ情報記憶部１１０から削除してもよい。

次いで、構成変更情報記憶部１１１およびグループ情報記憶部１１０は、ベースライン生成部１０７に更新された情報を入力する（ステップS206）。

次いで、ベースライン生成部１０７は、入力された更新された情報を基に、新規で追加されたコンテナインスタンスの性能情報を性能情報記憶部１０９から取得する（ステップS207）。

次いで、ベースライン生成部１０７は、取得された性能情報を基に、式（２）を用いてベースライン情報を更新する（ステップS208）。

次いで、ベースライン生成部１０７は、更新されたベースライン情報をベースライン記憶部１１２に格納する（ステップS209）。格納した後、監視システム１００は、ベースライン更新処理を終了する。

ベースライン記憶部１１２は、更新されたベースライン情報を、新バージョンのオートスケーリンググループのベースライン情報として登録する。なお、旧バージョンのコンテナインスタンスが全て停止した場合、ベースライン記憶部１１２は、旧バージョンのベースライン情報を削除してもよい。

次に、本実施形態の監視システム１００の、図９に示すベースライン更新処理で更新されたバージョン更新時のベースライン情報を利用した、新バージョンのコンテナインスタンスの異常を検知する動作を図１０を参照して説明する。

図１０は、第１の実施形態の監視システム１００によるバージョン更新時の性能異常検知処理の動作を示すフローチャートである。なお、通常時の性能異常検知処理は、図８に示す処理である。

ステップS301～ステップS305の各処理は、図８に示すステップS101～ステップS105の各処理とそれぞれ同様である。

次いで、性能異常検知部１０３は、取得されたグループ名を基に、構成変更情報記憶部１１１から構成変更情報を取得する（ステップS306）。取得された構成変更情報を基に、性能異常検知部１０３は、稼働している新バージョンのコンテナインスタンスの数を確認する（ステップS307）。

新バージョンのコンテナインスタンスが１つしか稼働していない場合、稼働しているコンテナインスタンスが１つ目の新バージョンのコンテナインスタンスである。すなわち、新バージョンのコンテナインスタンスの性能情報で、ベースラインはまだ生成されていない。

よって、新バージョンのコンテナインスタンスが１つしか稼働していない場合（ステップS308におけるNo）、性能異常検知部１０３は、更新されたベースライン情報を取得対象に変更せず、ステップS310の処理に進む。

新バージョンのコンテナインスタンスが２つ以上稼働している場合（ステップS308におけるYes）、性能異常検知部１０３は、更新されたベースライン情報を取得対象に変更する（ステップS309）。なお、取得対象に変更されるベースライン情報は、図９に示す処理で更新されたベースライン情報である。

ステップS310～ステップS314の各処理は、図８に示すステップS106～ステップS110の各処理とそれぞれ同様である。

なお、ローリングアップデート中、性能値がベースラインの範囲を超えない場合であっても、旧バージョンのベースラインの範囲を超えるようであれば、性能異常検知部１０３は、異常の可能性があるとしてユーザに通知してもよい。

［効果の説明］
ローリングアップデートによるバージョン更新中等、新バージョンのコンテナインスタンスの性能を監視する際に旧バージョンのコンテナインスタンスの性能情報が利用されて生成されたベースラインが利用される場合がある。

旧バージョンのベースラインが利用される場合、分散の幅が小さい、安定状態にある時間帯の監視では、新バージョンのコンテナインスタンスの性能の傾向の変化により誤った異常が検知される懸念がある。

本実施形態の監視システム１００は、バージョン更新中、通常時のベースラインの計算に使用される計算式を変更し、使用されるベースラインの分散の幅を広げる。分散の幅を広げることによって、監視システム１００は、性能の傾向や負荷状況の変化を誤って検知しないようにする。

また、単純に分散の幅を広げるだけでは誤った検知を防げても、本来検知された異常が見過ごされてしまうリスクがある。よって、監視システム１００は、分散の幅を固定せずに、新バージョンの性能情報がまだ少ない時点や、新バージョンの性能情報が十分集まってきた時点等、ローリングアップデートの進行状況に合わせて更新中のベースラインの分散の幅が動的に変更されるような計算式を用いる。

以上により、高頻度でバージョンが更新されるような情報システムにおいても、運用管理者は、監視システム１００を用いて、バージョンの更新を意識することなくベースラインによる監視を継続して実行できる。かつ、バージョンの更新中であっても、運用管理者は、精度を保ったまま監視を実行できる。

コンテナ型仮想化技術やDevOps等の普及により、大規模なサービスのバージョンであっても、ユーザの需要が取り込まれた新しいバージョンが容易にリリースされている。すなわち、バージョンの更新と、更新されたバージョンのリリースが以前よりも高頻度で行われている。

本実施形態の監視システム１００を利用する運用管理者は、高頻度でバージョンが更新されるような情報システムの監視において、バージョンの更新を契機に監視の再設定を行わずに済む。運用管理者は、異常を誤検知せずに継続して情報システムを監視できる。

具体的には、高頻度でバージョンが更新される情報システムと情報システムにおいて稼働するアプリケーションの性能状況とをベースラインを用いて監視する監視システム１００は、ローリングアップデートによるバージョン更新中にベースラインを自動で更新する。

よって、ユーザは、ベースラインの再生成等、バージョンの更新前またはバージョンの更新後にバージョン更新を契機とする作業を実施することなく、継続して情報システムを監視できる。

特許文献３に記載されているアプリケーション管理システムは、バージョンの更新前のアプリケーションの性能情報とバージョンの更新後のアプリケーションの性能情報とを比較し、バージョン更新により性能に変化が生じているメトリクスを抽出する。

特許文献３に記載されているアプリケーション管理システムは、変化の生じているメトリクスの抽出とユーザへのフィードバックを実行できる。しかし、ユーザには、監視や閾値設定の変更等、実行後に措置をとることが求められる。

本実施形態の監視システム１００も、バージョン更新の前後に渡る性能情報を利用している。しかし、監視システム１００が利用されると、ローリングアップデートによるバージョン更新に伴う性能情報の変化に対する措置をユーザがとらなくても、自動で適切な監視が継続して実行される。

本実施形態の監視システム１００は、ベースラインによる監視が可能な情報システムに対して利用可能である。また、監視システム１００は、バージョンが高頻度で更新されるクラウドコンピューティング、またはコンテナ型仮想化技術等が利用された情報システムに対してより利用可能である。

以下、本実施形態の監視システム１００のハードウェア構成の具体例を説明する。図１１は、本発明による監視システムのハードウェア構成例を示す説明図である。

図１１に示す監視システム１００は、ＣＰＵ１１と、主記憶部１２と、通信部１３と、補助記憶部１４とを備える。また、ユーザが操作するための入力部１５や、ユーザに処理結果または処理内容の経過を提示するための出力部１６を備えてもよい。

監視システム１００は、図１１に示すＣＰＵ１１が各構成要素が有する機能を提供するプログラムを実行することによって、ソフトウェアにより実現される。

すなわち、ＣＰＵ１１が補助記憶部１４に格納されているプログラムを、主記憶部１２にロードして実行し、監視システム１００の動作を制御することによって、各機能がソフトウェアにより実現される。

なお、図１１に示す監視システム１００は、ＣＰＵ１１の代わりにＤＳＰ（Digital Signal Processor）を備えてもよい。または、図１１に示す監視システム１００は、ＣＰＵ１１とＤＳＰとを併せて備えてもよい。

主記憶部１２は、データの作業領域やデータの一時退避領域として用いられる。主記憶部１２は、例えばＲＡＭ（Random Access Memory）である。

通信部１３は、有線のネットワークまたは無線のネットワーク（情報通信ネットワーク）を介して、周辺機器との間でデータを入力および出力する機能を有する。

補助記憶部１４は、一時的でない有形の記憶媒体である。一時的でない有形の記憶媒体として、例えば磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ－ＲＯＭ（Digital Versatile Disk Read Only Memory）、半導体メモリが挙げられる。

入力部１５は、データや処理命令を入力する機能を有する。入力部１５は、例えばキーボードやマウス等の入力デバイスである。

出力部１６は、データを出力する機能を有する。出力部１６は、例えば液晶ディスプレイ装置等の表示装置、またはプリンタ等の印刷装置である。

また、図１１に示すように、監視システム１００において、各構成要素は、システムバス１７に接続されている。

補助記憶部１４は、例えば性能情報受付部１０１、性能情報処理部１０２、性能異常検知部１０３、管理情報受付部１０４、構成変更管理部１０５、グループ情報管理部１０６、ベースライン生成部１０７、および操作受付部１０８を実現するためのプログラムを記憶している。

また、性能情報記憶部１０９、グループ情報記憶部１１０、構成変更情報記憶部１１１、およびベースライン記憶部１１２は、例えば主記憶部１２で実現される。また、性能情報受付部１０１、性能異常検知部１０３、管理情報受付部１０４、および操作受付部１０８は、例えば通信部１３で実現される。

なお、監視システム１００は、ハードウェアにより実現されてもよい。例えば、監視システム１００は、内部に図２に示すような機能を実現するＬＳＩ（Large Scale Integration）等のハードウェア部品が含まれる回路が実装されてもよい。

また、各構成要素の一部または全部は、汎用の回路（circuitry）または専用の回路、プロセッサ等やこれらの組み合わせによって実現されてもよい。これらは、単一のチップ（例えば、上記のＬＳＩ）によって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各構成要素の一部または全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

各構成要素の一部または全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

次に、本発明の概要を説明する。図１２は、本発明による監視システムの概要を示すブロック図である。本発明による監視システム２０は、複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲（例えば、ベースライン）であって、性能値が超過すると所定の監視項目が異常であると判断される範囲を、複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると１つ以上の監視対象装置の各性能値を基に更新する更新部２１（例えば、ベースライン生成部１０７）を含む。

そのような構成により、監視システムは、バージョンが更新される情報システムの監視用の閾値を利用者が再設定する手間を省くことができる。

また、監視システム２０は、更新された範囲を用いて、各バージョンがそれぞれ更新された１つ以上の監視対象装置を含む複数の監視対象装置の所定の監視項目をそれぞれ監視する監視部（例えば、性能異常検知部１０３）を含んでもよい。

そのような構成により、監視システムは、高頻度でバージョンが更新される情報システムを、監視の内容を再設定することなく継続して監視できる。

また、監視対象装置は、コンテナインスタンスでもよい。

そのような構成により、監視システムは、コンテナ型の仮想化環境に対応できる。

また、監視部は、同じグループに属する複数のコンテナインスタンスを同一の範囲を用いてそれぞれ監視してもよい。

そのような構成により、監視システムは、オートスケーリングが行われるコンテナインスタンスに対応できる。

また、更新部２１は、同じグループに属する複数のコンテナインスタンスのうち２つ以上のコンテナインスタンスの各バージョンがそれぞれ更新されると範囲を更新し、監視部は、更新された範囲を用いて複数のコンテナインスタンスをそれぞれ監視してもよい。

そのような構成により、監視システムは、バージョンが新しい方のコンテナインスタンスの性能情報を基に監視できる。

また、範囲の上限値は、各性能値の平均値に各性能値の標準偏差が加算された値であり、範囲の下限値は、平均値から標準偏差が減算された値であり、更新部２１は、１以上２以下の値を標準偏差に乗じることによって範囲を更新してもよい。

そのような構成により、監視システムは、バージョンが古い方のコンテナインスタンスの性能の異常も漏れなく検知できる。

１１ ＣＰＵ
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
１５ 入力部
１６ 出力部
１７ システムバス
２０、１００ 監視システム
２１ 更新部
１０１ 性能情報受付部
１０２ 性能情報処理部
１０３ 性能異常検知部
１０４ 管理情報受付部
１０５ 構成変更管理部
１０６ グループ情報管理部
１０７ ベースライン生成部
１０８ 操作受付部
１０９ 性能情報記憶部
１１０ グループ情報記憶部
１１１ 構成変更情報記憶部
１１２ ベースライン記憶部
２００ 端末
３００ コンテナ管理システム
３１０ 管理情報収集部
４００～４０Ｎ コンテナインスタンス
４１０～４１Ｎ 性能情報収集部

Claims (9)

1. 複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると前記所定の監視項目が異常であると判断される範囲を、前記複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると前記１つ以上の監視対象装置の各性能値を基に更新する更新部を含み、
   前記複数の監視対象装置は、
   いずれもコンテナインスタンスである
   ことを特徴とする監視システム。
2. 更新された範囲を用いて、各バージョンがそれぞれ更新された１つ以上のコンテナインスタンスを含む複数のコンテナインスタンスの所定の監視項目をそれぞれ監視する監視部を含む
   請求項１記載の監視システム。
3. 監視部は、同じグループに属する複数のコンテナインスタンスを同一の範囲を用いてそれぞれ監視する
   請求項２記載の監視システム。
4. 更新部は、同じグループに属する複数のコンテナインスタンスのうち２つ以上のコンテナインスタンスの各バージョンがそれぞれ更新されると範囲を更新し、
   監視部は、更新された範囲を用いて前記複数のコンテナインスタンスをそれぞれ監視する
   請求項３記載の監視システム。
5. 範囲の上限値は、各性能値の平均値に前記各性能値の標準偏差が加算された値であり、
   前記範囲の下限値は、前記平均値から前記標準偏差が減算された値であり、
   更新部は、１以上２以下の値を前記標準偏差に乗じることによって前記範囲を更新する
   請求項１から請求項４のうちのいずれか１項に記載の監視システム。
6. 複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると前記所定の監視項目が異常であると判断される範囲を、前記複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると前記１つ以上の監視対象装置の各性能値を基に更新し、
   前記複数の監視対象装置は、
   いずれもコンテナインスタンスである
   ことを特徴とする監視方法。
7. 更新された範囲を用いて、各バージョンがそれぞれ更新された１つ以上のコンテナインスタンスを含む複数のコンテナインスタンスの所定の監視項目をそれぞれ監視する
   請求項６記載の監視方法。
8. コンピュータに、
   複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲であって、性能値が超過すると前記所定の監視項目が異常であると判断される範囲を、前記複数の監視対象装置のうち１つ以上の監視対象装置の各バージョンがそれぞれ更新されると前記１つ以上の監視対象装置の各性能値を基に更新する更新処理を実行させるための監視プログラムであって、
   前記複数の監視対象装置は、
   いずれもコンテナインスタンスである
   監視プログラム。
9. コンピュータに、
   更新された範囲を用いて、各バージョンがそれぞれ更新された１つ以上のコンテナインスタンスを含む複数のコンテナインスタンスの所定の監視項目をそれぞれ監視する監視処理を実行させる
   請求項８記載の監視プログラム。

Images