(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024130818
(43)【公開日】2024-09-30
(54)【発明の名称】コンピュータシステム、モニタ方法およびプログラム
(51)【国際特許分類】
G06F 11/30 20060101AFI20240920BHJP
【FI】
G06F11/30 175
G06F11/30 140C
【審査請求】未請求
【請求項の数】10
【出願形態】OL
(21)【出願番号】P 2023040727
(22)【出願日】2023-03-15
(71)【出願人】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100181135
【弁理士】
【氏名又は名称】橋本 隆史
(72)【発明者】
【氏名】石井 貴光
【テーマコード(参考)】
5B042
【Fターム(参考)】
5B042GA22
5B042MA08
5B042MA10
5B042MA16
5B042MC21
5B042MC22
5B042MC39
(57)【要約】
【課題】一般に、サービスもしくはシステムに関する分析に要する時間と処理の負荷を低減することが好ましい。
【解決手段】例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納し、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示する、ように構成されたシステムが提供され得る。
【選択図】
図10
【特許請求の範囲】
【請求項1】
コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納し、
ユーザの要求に応答して、前記フィルタ済情報に格納された前記コンテナプラットフォームの情報を提示する、
ように構成されたシステム。
【請求項2】
前記コンテナプラットフォームの情報が、所定の時間間隔で前記スナップショット情報として収集/蓄積され、
前記フィルタ・トリガ条件設定情報がトリガ条件とフィルタ情報とを格納し、前記トリガ条件に従って、前記フィルタ情報を参照して、前記フィルタ処理が行われる、
請求項1に記載のシステム。
【請求項3】
前記トリガ条件は、前記フィルタ・トリガ条件設定情報に格納されたフィルタ情報のうちの少なくとも1つを参照して前記フィルタ処理を行うための条件を指定する、
請求項2に記載のシステム。
【請求項4】
前記フィルタ情報は、前記フィルタ処理において、前記コンテナプラットフォームの少なくとも1つの構成要素に関する情報の取得を行うことを示す、
請求項3に記載のシステム。
【請求項5】
前記ユーザの要求に応答して、前記フィルタ・トリガ条件設定情報の更新を行う、
ように更に構成された請求項4に記載のシステム。
【請求項6】
前記フィルタ・トリガ条件設定情報に格納された前記トリガ条件を、所定の時間間隔でチェックする、
ように更に構成された請求項5に記載のシステム。
【請求項7】
前記トリガ条件は、前記フィルタ処理の実行の時間間隔を指定する、請求項6に記載のシステム。
【請求項8】
前記ユーザの要求に応答して提示される情報が、前記フィルタ情報が示す前記コンテナプラットフォームの少なくとも1つの構成要素に着目した情報と、前記少なくとも1つの構成要素に関係する構成要素の情報を含む、
請求項7に記載のシステム。
【請求項9】
コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、
ユーザの要求に応答して、前記フィルタ済情報に格納された前記コンテナプラットフォームの情報を提示することと、
を具備する、前記コンテナプラットフォームのモニタ方法。
【請求項10】
コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、
ユーザの要求に応答して、前記フィルタ済情報に格納された前記コンテナプラットフォームの情報を提示することと、
をコンピュータに実行させる命令を具備する、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
後述の実施の形態は、例えば、コンピュータシステム、モニタ方法およびプログラムに関する。
【背景技術】
【0002】
以下の開示は例示であり、本願や本発明の範囲を限定/制限するものではない。
【0003】
多くの企業や政府機関、公共団体といった組織は、常に変化する社会やビジネスのニーズに対応していく必要性がある。これらの組織は、こうしたニーズへの対応のため、情報処理技術の導入を推進し得る。例えば、情報処理技術の導入、新たなサービスのためのアプリケーションプログラムの開発、および/もしくは情報処理システムの運用等のために、これらに適したプラットフォームが求められ得る。
【0004】
このようなプラットフォームを実現するための技術として、仮想化技術の1つであるコンテナ技術、もしくは、アプリケーションコンテナがあり得る。コンテナとは、貨物輸送に使われる箱型の大型の容器のように、例えば、オペレーティングシステム上に仮想的に複数の別個独立の領域を設け、その領域のなかでアプリケーションプログラムを実行、稼働させるシステムであり得る。
【0005】
例えば、コンテナ中に、アプリケーションプログラム、アプリケーションプログラムの実行に必要な設定ファイルなどの実行環境、アプリケーションプログラムの実行のためのライブラリと呼ばれるコンピュータプログラムの部品(ソフトウェア)、ランタイムと呼ばれるプログラムの動作に必要なソフトウェアなどがひとまとめに格納され得る。それぞれのコンテナに格納されたアプリケーションプログラムが実行される場合、この実行されたアプリケーションプログラムに対応するプロセスが独立して実行・管理され得る。このため、異なるコンテナもしくはアプリケーションプログラムの間の競合や干渉を抑止することが可能となり得る。
【0006】
また、例えば、コンテナごとに第1の業務向け、第2の業務向けといったように、同じアプリケーションプログラムについて異なる設定を行い得る。あるいは、第1のコンテナが製造業務アプリケーション、第2のコンテナが販売業務アプリケーションといったように、1つのオペレーティングシステム上で異なる複数の業務のアプリケーションプログラムを同時に動作させてもよい。従って、ほかのコンテナもしくはアプリケーションプログラムとの間の競合や干渉を意識せずに、システムを導入/開発/運用等することが可能となり得る。
【0007】
上述のようなコンテナは、コンテナ管理ソフトウェアを用いて管理され得る。あるいは、コンテナ、ハードウェア、仮想マシン、などを管理するコンテナプラットフォームを用いて運用、管理が行われ得る。
【0008】
上述の開示は例示であり、本願や本発明の範囲を限定/制限するものではない。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特開2022-171570号公報
【特許文献2】特開2022-130021号公報
【特許文献3】特開2021-111396号公報
【発明の概要】
【発明が解決しようとする課題】
【0010】
以下は例示であり、本願や本発明の範囲を限定/制限するものではない。
【0011】
コンテナプラットフォーム上で実行されるプログラムにより、種々のサービスが提供され得る。これらのサービスの構成要素は、種々の、そして多くの要素から構成され得る。それぞれの要素は、負荷状況などの外部からの影響により、また、時間の経過にともなって、構成が複雑に変化し得る。
【0012】
こうしたサービスを運用管理する場合、そして、サービスのシステムとしての振る舞いをより詳細に把握することが必要な場合、例えば、スナップショット情報を高頻度で収集/蓄積することにより対応が可能となり得る。
【0013】
しかし、サービスの構成要素やその関連情報が多種多量の場合に、高頻度でスナップショット情報を取得すると、総情報量が膨大なものとなり得る。このため、サービスもしくはシステムに関して何らかの観点で分析を行う場合、分析の処理の都度にスナップショット情報の全件に対してフィルタ処理などを行うと、こうした処理のたびに大きな量の計算を行うことが必要となり得る。このため、分析に長時間を要する、コンテナプラットフォーム、コンテナ、アプリケーションプログラムなどの実行を阻害する、などの問題が発生する可能性があり得る。
【0014】
なお、上記の点は、本願や本発明の範囲を限定/制限するものではない。
【課題を解決するための手段】
【0015】
以下の記載は例示であり、本願や本発明の範囲を限定/制限を限定するものではない。
【0016】
後述の実施の形態においては、例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納し、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示する、ように構成されたシステムが提供され得る。
【0017】
後述の実施の形態においては、例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示することと、を具備する、コンテナプラットフォームのモニタ方法が提供され得る。
【0018】
後述の実施の形態においては、例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示することと、をコンピュータに実行させる命令を具備する、コンピュータプログラムが提供され得る。
【0019】
なお、上記の点は、本願や本発明の範囲を限定/制限するものではない。
【発明の効果】
【0020】
後述の実施の形態によれば、例えば、サービスもしくはシステムに関する分析に要する時間と処理の負荷を低減することが可能となり得る。これにより、サービスもしくはシステムに関する分析の実行によってコンテナプラットフォーム、コンテナ、アプリケーションプログラムなどの実行を阻害することを回避し得る。ただし、これは、本願や本発明の範囲を限定/制限するものではない。
【図面の簡単な説明】
【0021】
【
図1】コンテナプラットフォームの概略を示す概要図である。
【
図2】モニタシステムの概略を示す、概要図である。
【
図3】モニタシステムの処理の流れを示すフローチャートである。
【
図4】モニタシステムの処理の流れを示すフローチャートである。
【
図5】モニタシステムの処理の流れを示すフローチャートである。
【
図6】モニタシステムの処理の流れを示すフローチャートである。
【
図7】モニタシステムによって提示され得る画面の例を示す図である。
【
図8】モニタシステムによって提示され得る画面の例を示す図である。
【
図9】モニタシステムによって提示され得る画面の例を示す図である。
【
図10】モニタシステムの概略を示す、概要図である。
【
図11】モニタシステムの処理の流れを示すフローチャートである。
【発明を実施するための形態】
【0022】
以下、図面を参照し、本発明に関する実施形態について説明する。なお、以下の開示は例示である。本願と本発明は、以下の開示のみに限定/制限して解釈されるべきではない。
【0023】
以下において、実施形態の一つを説明する。
図1は、コンテナなどを運用、管理するために用いられるコンテナプラットフォーム100を示す概要図である。コンテナプラットフォーム100は、コンピュータプログラムとして実装され、コンテナなどを運用、管理してもよい。
図1のコンテナプラットフォーム100は、複数のコンテナ、もしくは、アプリケーションコンテナを含み、これらを管理するための管理単位であるポッド(Pod)を含んでもよい。
図1では、説明を容易なものとするため、「PodA」と「PodB」の2個のポッドがコンテナプラットフォーム100によって管理、運用されている。「PodA」や「PodB」は、例えば、動画配信サイト、ネットバンキング、Eコマースなど種々のサービスを提供するためのアプリケーションプログラム、Webサーバ、データベース管理プログラムなどを含んでもよい。
【0024】
図1のコンテナプラットフォーム100は、1つもしくは複数のコンピュータである1つもしくは複数のノード(Node)を含んでもよい。ノードは物理的なコンピュータであってもよく、仮想マシンであってもよい。
図1のコンテナプラットフォーム100は、説明を容易なものとするため、「NodeA」と「NodeB」の2個のノードを含む。「NodeA」は、例えば、管理用のノードであってもよく、コンピュータプログラムとして実装されたコンテナプラットフォーム100が「NodeA」の上で実行されてもよい。「NodeB」はワーカーノードとして、例えば、「PodA」や「PodB」のアプリケーションプログラムを実行するためのノードであってもよい。
【0025】
図1の「ServiceA」、「ServiceB」、「ServiceC」は、コンテナプラットフォーム100上で動作するサービス(Service)の構成要素であって、「PodA」および/もしくは「PodB」のアプリケーションプログラムのエンドポイントを提供するプログラムであってもよい。あるいは、
図1の「ServiceA」、「ServiceB」、「ServiceC」は、「PodA」および/もしくは「PodB」のアプリケーションプログラムのエンドポイントを提供するホームページであってもよい。
【0026】
図1のコンテナプラットフォーム100は、1つもしくは複数のストレージ(PersistentVolumeClaim)を管理してもよい。これらのストレージは、物理的なハードディスクやSSD(slid state drive)を含むコンピュータ、ネットワークストレージ、あるいは、必要な記憶容量を確保するための仮想的なストレージ/オブジェクトであってもよい。
図1のコンテナプラットフォーム100は、説明を容易なものとするため、「PersistentVolumeClaimA」と「PersistentVolumeClaimB」の2つのストレージを含む。「PodA」および/もしくは「PodB」のコンテナのアプリケーションプログラムが使用するデータは、「PersistentVolumeClaimA」および/もしくは「PersistentVolumeClaimB」に格納されてもよい。
【0027】
図1のコンテナプラットフォーム100は、ポッドの稼働状態を管理するための情報を含む、1つもしくは複数のコントローラ(Controller)を備えてもよい。
図1のコンテナプラットフォーム100は、説明を容易なものとするため、「ControllerA」、「ControllerB」の2つのコントローラを備える。「ControllerA」は、例えば、「PodA」のアプリケーションプログラムの起動時間を指定する情報を含んでもよい。「ControllerA」は、例えば、PodAのネットバンキングサービスのアプリケーションプログラムを午前7時に起動するため、「PodA.NetBankApp::wakeup/0700」といったコマンドの記載を含むスクリプトであってもよい。「ControllerA」は、「PodA」のアプリケーションプログラムの運用、管理コマンドを記載したテーブルであてもよい。「ControllerA」は、このようなコマンドを複数含んでもよい。
【0028】
上述のように、
図1のコンテナプラットフォーム100は、種々の構成要素の運用管理を行い得る。それぞれの構成要素は、負荷状況などの外部的な影響により、時間の経過に伴って複雑に変化し得る。例えば、「PodA」および/もしくは「PodB」のアプリケーションプログラムが「NodeB」上で実行されていた時に、「NodeB」に障害が発生した場合に、コンテナプラットフォーム100は、「PodA」および/もしくは「PodB」のアプリケーションプログラムを図示しない他のワーカーノード上で起動してもよい。あるいは、コンテナプラットフォーム100は、「PodA」および/もしくは「PodB」のアプリケーションプログラムを図示しない他のワーカーノード上であらかじめ起動しておき、系切り替えの処理を行ってもよい。また、「PodA」および/もしくは「PodB」のアプリケーションプログラムが「NodeB」上で実行されていた時に、アクセスが集中して「NodeB」の処理負荷が高い状態となった場合に、コンテナプラットフォーム100は、「PodA」および/もしくは「PodB」のアプリケーションプログラムを図示しない他のワーカーノード上で更に起動してもよい(ポッドを他のワーカーノード上にコピーしてアプリケーションプログラムを起動してもよい)。
【0029】
図2は、コンテナプラットフォーム100をモニタするモニタシステム200の概要を示す、概要図である。以下、
図2に示される構成要素の各機能について説明する。
【0030】
図2のモニタシステム200に含まれるスナップショット情報210は、コンテナプラットフォーム100から得られた構成要素の情報と、構成要素間の関係に関する情報を保持する。構成要素の情報は、例えば、コンテナプラットフォーム100の各要素の名称、状態、設定値に関する情報を含んでもよい。構成要素の情報は、例えば、「ServiceA」、「Active」、「All Users」などであり、構成要素である「ServiceA」が稼働中(「Active」)の状態であって、すべてのユーザ(「All Users」)にアクセス可能に設定されていることを表し得る。構成要素がノードであれば、構成要素の情報は、例えば、CPU利用率、GPU利用率、メモリ利用率、ネットワークの利用率などを含んでもよい。構成要素がストレージであれば、構成要素の情報は、例えば、空き容量、空き容量の割合、ファイル数、などを含んでもよい。
【0031】
図2のスナップショット情報210の構成要素間の関係に関する情報は、例えば、あるサービスがいずれのポッドで起動しているか、に関する情報を含んでもよい。また、スナップショット情報210の構成要素間の関係に関する情報は、例えば、あるポッドがどのノードで起動しているか、あるポッドがどのストレージを使用しているか、あるポッドがどのコントローラに従って動作しているか、に関する情報を含んでもよい。構成要素間の関係に関する情報はスクリプトの形式であっても、テーブルの形式であっても、あるいは、他の形式であってもよい。
【0032】
スナップショット情報210の構成要素間の関係に関する情報は、例えば、ポッドの識別子、サービスの識別子、ノードの識別子、ストレージの識別子、コントローラの識別子といった項目から構成されるテーブルであってもよい。それぞれの識別子は、コンテナプラットフォーム100の管理者によって付与されてもよい。それぞれの識別子は、コンテナプラットフォーム100の管理者のコンピュータによって付与されてもよい。スナップショット情報210の構成要素間の関係に関する情報は、例えば、ポッドの識別子と、ポッドの名称との関係を関連付けて格納してもよい(例えば、「PodA, P0001」)。サービスの名称、ノードの名称、ストレージの名称、コントローラの名称についても、サービスの識別子、ノードの識別子、ストレージの識別子、コントローラの識別子と関連付けて格納されてもよい。
【0033】
モニタシステム200はスナップショット情報210を、モニタシステム200のプログラムが実行されるコンピュータの記憶領域もしくはストレージに格納してもよい。モニタシステム200はスナップショット情報210を、外部のコンピュータの記憶領域もしくはストレージに格納してもよい。モニタシステム200はスナップショット情報210を、時系列に追加/蓄積してもよい。この場合、スナップショット情報210には、追加された情報ごとにタイムスタンプが付されてもよい。
【0034】
モニタシステム200は、スナップショット情報210が格納する、コンテナプラットフォーム100から得られた構成要素の情報と、構成要素間の関係に関する情報を、例えば、所定の時間間隔(例えば10分ごと)に取得してもよい。管理者が、クライアント端末300を介してモニタシステム200に、時間間隔などのこれらの情報の取得のタイミングを指定してもよい。あるいは、管理者が、クライアント端末300を介してモニタシステム200に、任意のタイミングでこれらの情報の取得の要求を行ってもよい。スナップショット情報210に格納された情報は、所定の時間間隔(例えば10日)で削除されてもよい。この所定の時間間隔は、管理者によって指定されてもよい。あるいは、モニタシステム200は、スナップショット情報210の大きさが所定のサイズ(例えば10GB)を超えた場合に、古い情報を削除してもよい。この所定のサイズは、管理者によって指定されてもよい。
【0035】
図2のモニタシステム200に含まれるフィルタ・トリガ条件設定情報220は、フィルタ情報と、トリガ条件の情報とを格納し得る。
【0036】
フィルタ・トリガ条件設定情報220のフィルタ情報は、スナップショット情報210に対して情報の絞り込みを行うフィルタを定義し得る。フィルタ情報は、例えば、サービス名を指定するものであり得る。フィルタ情報は、例えば、ノード名を指定するものであり得る。フィルタ情報は、例えば、ポッド名を指定するものであり得る。フィルタ情報は、複数の項目を含んでもよい。例えば、サービス名(「ServiceA」)を指定した「Filter001:Service Name = ServiceA」といった項目と、ノード名(「NodeB」)を指定した「Filter002:Node Name = NodeB」といった項目の両方がフィルタ情報に含まれてもよい。このような指定により2通りの情報がスナップショット情報210から生成され得る。「Filter001」や「Filter002」はフィルタ情報が複数組存在する場合にこれらを識別するために用いられ得る。
【0037】
フィルタ情報は、スナップショット情報の差分の取得を指定するものが含まれてもよい。例えば、フィルタ情報は、サービスに関連する情報の差分を取得することを指定する、
「Filter003:Diff:Service」といったフィルタを含んでもよい。これと後述のトリガ条件とを組み合わせ、例えば、30分ごとにサービスに関連する情報の差分を取得することができ得る。例えば、ある時刻では「ServiceC」が利用可能であったところ、30分後にはこれが削除された場合、スナップショット情報210から現在と30分前のサービスに関連する情報を抽出して差分を取得し得る。例えば、ある時刻には利用ができなかった「ServiceA」が30分後にはこれが利用可能となった場合、スナップショット情報210から現在と30分前のサービスに関連する情報を抽出して差分を取得し得る。
【0038】
フィルタ・トリガ条件設定情報220のトリガ条件の情報は、フィルタ情報を用いたフィルタ処理をどのようなタイミングや頻度で行うかに関する条件であるトリガ条件を格納し得る。トリガ条件は、例えば、30分であってもよい。この指定は、例えば、30分が1800秒であることから、「Trigger001:sec=1800」などといったスクリプトであってもよい。このような指定により、30分ごとにフィルタ情報を用いたフィルタ処理が実行(トリガ)され得る。また、トリガ条件は、例えば、時刻を指定してもよい。この指定は、例えば、毎日12:00に情報を取得する場合、「Trigger001:daytime=1200」などといったスクリプトであってもよい。このような指定により、毎日12時にフィルタ情報を用いたフィルタ処理が実行(トリガ)され得る。また、トリガ条件は、例えば、日付と時刻、曜日、などを指定してもよい。フィルタ・トリガ条件設定情報220のトリガ条件は、複数通りあってもよい。
【0039】
フィルタ情報が複数組存在する場合、トリガ条件は例えば、「Trigger001:sec=1800//Filter001」といった記載であってもよい。このようなトリガ条件により、「Filter001」に対応するフィルタ情報に従って、30分ごとにフィルタ処理が実行され得る。1個のトリガ条件は、2個以上のフィルタ情報を指定してもよい。
【0040】
フィルタ・トリガ条件設定情報220のトリガ条件の情報は、時間以外の条件を含んでもよい。例えば、「NodeA」のCPU利用率が90%を超えた場合(「Trigger002:cpu>90@NodeA//Filter001」)、「PersistentVolumeClaimB」の空き領域が20%を下回った場合(「Trigger003:vacancy<20@PersistentVolumeClaimB//Filter001」)など、種々の条件を設定可能としてもよい。また、フィルタ・トリガ条件設定情報220のトリガ条件の情報は、2以上のトリガ条件を組み合わせたものであってもよい。例えば、「NodeA」のCPU利用率が90%を超えた場合もしくは「NodeB」のCPU利用率が80%を超えた場合、といった組み合わせの条件を含んでもよい(「Trigger004:cpu>90@NodeA:cpu>80@NodeB//Filter001」)。
【0041】
図2のモニタシステム200に含まれるフィルタ済情報230は、スナップショット情報210を参照して、フィルタ・トリガ条件設定情報220に従ってフィルタ処理されて得られた情報である。管理者は、フィルタ済情報230を参照し、さらなるフィルタ処理などを行うことなく所望の項目/内容についてコンテナプラットフォーム100の状態をチェックすることができ得る。
【0042】
クライアント端末300は、コンテナプラットフォーム100の管理者が操作するコンピュータである。クライアント端末300は、管理者の入力した指示を受け取る。クライアント端末300は、例えば、管理者からの指示に従って、画面表示のための情報などを要求するリクエスト信号を、モニタシステム200へ送信する。クライアント端末300は、モニタシステム200とは別のコンピュータであってもよい。クライアント端末300は、モニタシステム200と同じコンピュータであってもよい。
【0043】
モニタシステム200の画面表示部240は、クライアント端末300からのリクエスト信号を受信して、クライアント端末300のスクリーンに表示するための情報を取得し、クライアント端末300へ送信する。この情報は、例えば、コンテナプラットフォーム100のフィルタ済情報230に格納された情報であってもよい。この情報は、例えば、コンテナプラットフォーム100のスナップショット情報210に格納された情報であってもよい。また、画面表示部240は、フィルタ情報やトリガ条件を設定可能としてもよい。フィルタ情報やトリガ条件は、クライアント端末300のスクリーンに表示する情報の取得のために使用され得る。画面表示部240は、種々の情報を、クライアント端末300のスクリーンの一部もしくは全部にウインドウを表示して、管理者に提示してもよい。モニタシステム200は、クライアント端末300のスクリーンとは別のスクリーンを備え、画面表示部240がこの別のスクリーンを介して種々の情報を管理者に提示してもよい。
【0044】
モニタシステム200の構成情報収集・蓄積部250は、コンテナプラットフォーム100へ種々の情報の送信を要求する。構成情報収集・蓄積部250は、例えば、コンテナプラットフォーム100の構成要素の情報、コンテナプラットフォーム100の構成要素の間の関連を表す情報を定期的に要求して収集し、この情報をスナップショット情報210に格納/蓄積し得る。
【0045】
モニタシステム200の構成情報フィルタ処理部260は、上述の画面表示部240を介して設定されたフィルタ情報を参照し、フィルタ済情報を生成する。フィルタ済情報は、スナップショット情報210に基づいて生成され得る。
【0046】
モニタシステム200の構成情報フィルタ処理トリガ部270は、上述の画面表示部240を介して設定されたトリガ条件を参照して、構成情報フィルタ処理部260をトリガする。構成情報フィルタ処理部260は、構成情報フィルタ処理トリガ部270によってトリガされ、トリガ条件によって指定されたフィルタ情報に従い、フィルタ済情報を生成する(フィルタ処理)。
【0047】
図2のコンテナプラットフォーム100は
図1のコンテナプラットフォーム100と同様である。
【0048】
次に、
図2の概要図と、
図3から6のフローチャートとを参照して、モニタシステム200の処理の流れの例について説明する。
【0049】
図3は、フィルタ・トリガ条件設定情報220の設定を行う処理を示すフローチャートである。コンテナプラットフォーム100の管理者は、クライアント端末300にフィルタ・トリガ条件設定情報220の設定のためのモニタシステム200への指示、および/もしくは、フィルタ・トリガ条件設定情報220の設定のためのデータの入力を行う。
【0050】
コンテナプラットフォーム100の管理者は、クライアント端末300を操作して、モニタシステム200の画面表示部240へリクエスト信号を送信する(ステップS301)。例えば、管理者は、クライアント端末300を操作して、モニタシステム200の画面表示部240へフィルタ・トリガ条件設定情報220のフィルタ情報に新たなフィルタの追加を要求する。画面表示部240は、クライアント端末300からの要求を受信して、新たなフィルタである一組のフィルタ情報を生成し、フィルタ・トリガ条件設定情報220に追加、保存する(ステップS302)。
【0051】
例えば、管理者は、クライアント端末300を操作して、新たなフィルタの名称(「Filter001」)とポッド名(「PodA」)とを指定し、フィルタ情報に新たなフィルタの追加を要求する。画面表示部240は、クライアント端末300からの要求を受信して、新たなフィルタに対応する一組のフィルタ情報(「Filter001:Pod Name = PodA」)を生成し、フィルタ・トリガ条件設定情報220に追加、保存する(ステップS302)。
【0052】
また、例えば、管理者は、クライアント端末300を操作して、新たなトリガの名称(「Trigger001」)、起動(トリガ)されるフィルタの名称(「Filter001」)、例えば30分ごとといった起動の条件(「sec=1800」)を指定し、新たなトリガ条件の追加を要求する。画面表示部240は、クライアント端末300からの要求を受信して、新たなトリガ条件に対応する一組のトリガ条件の情報(「Trigger001:sec=1800//Filter001」)を生成し、フィルタ・トリガ条件設定情報220に追加、保存する(ステップS302)。
【0053】
すなわち、管理者は、クライアント端末300を介して画面表示部240に、コンテナプラットフォーム100の分析観点であるフィルタ情報、フィルタ情報に従ったフィルタ処理を行う条件を示すトリガ条件を設定し、フィルタ・トリガ条件設定情報220へ保存することを指示する。
【0054】
図3の処理は、管理者がモニタシステム200の実行されているコンピュータを直接操作することによって、行われてもよい。
【0055】
次に、
図4を参照して、コンテナプラットフォーム100の構成情報の定期的な取得と、スナップショット情報210への保存の処理を説明する。モニタシステム200の構成情報収集・蓄積部250は、コンテナプラットフォーム100から、コンテナプラットフォーム100の各構成要素の情報や状態、各構成要素の間の関係の情報を取得する(ステップS401)。構成情報収集・蓄積部250は、この処理をあらかじめ指定された時間間隔で定期的に行ってもよい。例えば、管理者が、クライアント端末300を介してモニタシステム200に時間間隔(例えば10分)を指定してもよい。モニタシステム200の構成情報収集・蓄積部250は、管理者の指定した時間間隔を、モニタシステム200が実行されているコンピュータの記憶装置に格納してもよい。
【0056】
モニタシステム200の構成情報収集・蓄積部250は、コンテナプラットフォーム100の各構成要素の情報や状態、各構成要素の間の関係に関する情報を、コンテナプラットフォーム100があらかじめ備えるアプリケーション・プログラム・インタフェース(API)を用いて、取得してもよい。
【0057】
また、モニタシステム200の構成情報収集・蓄積部250は、コンテナプラットフォーム100の各構成要素の情報や状態、各構成要素の間の関係に関する情報を、コンテナプラットフォーム100があらかじめ備えるデータを参照して、取得してもよい。このデータは、コンテナプラットフォーム100のプログラムが実行されるコンピュータ上のファイルであってもよい。このデータは、コンテナプラットフォーム100によって随時更新されてもよい。あるいは、このデータは、例えば、コンテナプラットフォーム100のプログラムがコンテナプラットフォーム100の稼働状態を時系列に出力するログであってもよい。
【0058】
モニタシステム200の構成情報収集・蓄積部250は、コンテナプラットフォーム100の各構成要素の情報や状態、各構成要素の間の関係に関する情報を、スナップショット情報として、スナップショット情報210に追加して格納/蓄積してもよい(ステップS402)。構成情報収集・蓄積部250は、コンテナプラットフォーム100のスナップショット情報を、タイムスタンプとともにスナップショット情報210に追加して格納/蓄積してもよい。管理者は、スナップショット情報に有効期限をあらかじめ設定してもよい。例えば、管理者は、スナップ情報の有効期限を72時間と設定してもよい。構成情報収集・蓄積部250は、管理者によってあらかじめ指定された時刻や時間間隔を用いて、指定された有効期限を超えたスナップショット情報を検知して削除してもよい。構成情報収集・蓄積部250は、スナップショット情報の追加/蓄積を行うときに、指定された有効期限を超えたスナップショット情報を検知して削除してもよい。構成情報収集・蓄積部250は、指定された有効期限を超えたスナップショット情報を、外部の記憶装置(大容量のハードディスクや光ディスク、テープデバイスなど)にコピーした後で、スナップショット情報210から削除してもよい。
【0059】
次に、
図5を参照し、スナップショット情報210に対するフィルタ処理および関連する処理の流れを説明する。
【0060】
モニタシステム200の構成情報フィルタ処理トリガ部270は、フィルタ・トリガ条件設定情報220中のトリガ条件を、あらかじめ管理者によって設定された時間間隔でチェックし得る。この処理においては、例えば、構成情報フィルタ処理トリガ部270は、フィルタ・トリガ条件設定情報220中のトリガ条件が更新、追加、削除されていることの検知を試みる。例えば、構成情報フィルタ処理トリガ部270は、フィルタ・トリガ条件設定情報220中のトリガ条件を、15分ごとにチェックする(ステップS501)。
【0061】
モニタシステム200の構成情報フィルタ処理トリガ部270は、例えば、「Trigger001:sec=1800//Filter001」といったトリガ条件がフィルタ・トリガ条件設定情報220に追加されたことを検知した場合、このトリガ条件をモニタシステム200の実行されているコンピュータのメモリ中に格納する。このトリガ条件は、「Trigger001」というトリガの名称であって、「1800」秒ごとに「Filter001」というフィルタ名称のフィルタを参照してフィルタ処理を実行することを示すものであり得る。構成情報フィルタ処理トリガ部270は、このトリガ条件を解析し、別のスレッドもしくはプロセスを起動し、このスレッドもしくはプロセスに「1800」秒間隔で「Filter001」に従ったフィルタ処理を実行させる。
【0062】
構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、「1800」秒間隔でタイマをセットし、「Filter001」に従ったフィルタ処理を実行する(ステップS502)。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、「1800」秒間隔でフィルタ・トリガ条件設定情報220を参照して「Filter001」に対応するフィルタ情報を読み出す(ステップS503)。
【0063】
構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、「Filter001」に対応するフィルタ情報を解析する。「Filter001」が、例えば、サービス名(「ServiceA」)を指定した「Filter001:Service Name = ServiceA」である場合、「Filter001」は、「ServiceA」に関する情報を抽出するフィルタ処理を示すものであり得る。スナップショット情報210は複数組の情報を格納していることがあり得る。ここでは、構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、フィルタ情報に従い、スナップショット情報210に格納された情報の中の最新の一組を読み出し、「ServiceA」に関する情報を抽出する。
【0064】
構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、スナップショット情報210に格納された情報の中の最新の一組に含まれる構成要素の情報から、「ServiceA」に対応する、例えば、状態、設定値に関する情報を抽出する。構成要素の情報は、例えば、「Active」、「All Users」などであり、これは、「ServiceA」が稼働中(「Active」)の状態であって、すべてのユーザ(「All Users」)にアクセス可能に設定されていることを表し得る。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、これらの読み出した情報を、フィルタ済情報230に格納する。
【0065】
更に、構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、スナップショット情報210に格納された情報の中の最新の一組に含まれる構成要素間の関係に関する情報を参照する。例えば、「ServiceA」がいずれのポッドで起動しているか、また、このポッドがどのノードで稼働しているか、このポッドがどのストレージを使用しているか、このポッドがどのコントローラに従って動作しているか、に関する情報を読み出し得る。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、これらの読み出した情報を、フィルタ済情報230に格納する(ステップS504)。
【0066】
フィルタ済情報230に格納される情報は、例えば、「ServiceA」の識別子、ポッドの識別子、ストレージの識別子、コントローラの識別子、「ServiceA」の情報(例えば、「ServiceA」、「Active」、「All Users」)、タイムスタンプ(現在の日時)であってもよい。また、格納される情報は、構成要素間のつながりを示す情報を含んでもよい。例えば、「ServiceA-PodA」、「PodA-NodeA」といった識別子間のつながりを示す情報を含んでもよい。また、格納される情報は、フィルタの名称、トリガ条件を示す情報を含んでもよい。格納される情報は、スクリプトであっても、テーブルであっても、あるいは他の形式であってもよい。
【0067】
上述のような処理により、「Filter001」に対応するフィルタ情報に従って、30分ごと(「1800」秒間隔)にフィルタ処理が実行され得る。
【0068】
フィルタ処理は、例えば、「1800」秒間隔といった時間に基づく条件を含んでもよい。フィルタ処理は、例えば、CPU利用率に基づく条件を含んでもよい。フィルタ処理は、例えば、ストレージの空き容量に基づく条件を含んでもよい。
【0069】
モニタシステム200の構成情報フィルタ処理トリガ部270は、フィルタ・トリガ条件設定情報220中のトリガ条件が、例えば、CPU利用率に基づく条件を含んでもよい。この条件は、例えば、あるノード(「NodeA」)のCPU利用率が90%を超えた場合に「Filter001」に対応するフィルタ情報に従ってフィルタ処理を実行する(「Trigger002:cpu>90@NodeA//Filter001」)といった条件を含み得る。構成情報フィルタ処理トリガ部270は、別のスレッドもしくはプロセスを起動し、このスレッドもしくはプロセスに「NodeA」のCPU利用率に従ったフィルタ処理を実行させ得る。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、「NodeA」上でエージェントなどのプロセスを起動させ、このエージェントが「NodeA」のCPU利用率を監視してもよい。「NodeA」のCPU利用率が90%を超えた場合、このエージェントが、構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスへ、信号を送信してもよい。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、エージェントからの信号を受信した場合に、「Filter001」に対応するフィルタ情報に従ってフィルタ処理を実行し得る。構成情報フィルタ処理トリガ部270によって起動されたスレッドもしくはプロセスは、フィルタ処理により得られた情報を、フィルタ済情報230に格納する。このフィルタ処理により得られた情報は、「NodeA」のCPU利用率、メモリの利用率、ネットワークの利用率などの情報をエージェントから取得して含んでもよい。
【0070】
次に、
図6を参照し、スナップショット情報の表示に関する処理の流れを説明する。コンテナプラットフォーム100の管理者は、クライアント端末300を介してモニタシステム200に、フィルタ情報に合致したスナップショット情報の表示を要求する(ステップS300)。モニタシステム200の画面表示部240は、管理者の要求を受けた場合に、フィルタ情報のリストを表示し、管理者がこのリストから選択してもよい(ステップS300)。
【0071】
モニタシステム200の画面表示部240は、クライアント端末300から、フィルタ情報に合致したスナップショット情報の表示の要求を受信する。画面表示部240は、フィルタ済情報230を参照して、例えば、フィルタ処理により得られた情報のうちの最新の10件について、フィルタ名と情報の取得日時を、クライアント端末300へ送信してもよい。クライアント端末300は、フィルタ名と情報の取得日時を画面表示部240から受信し、クライアント端末300のスクリーンに表示してもよい。
【0072】
管理者は、クライアント端末300のスクリーンに表示されたフィルタ名と情報の取得日時から、所望の情報を指定し得る。クライアント端末300は管理者の指定を受けて、画面表示部240へ管理者の指定した情報を送信するよう要求する(ステップS601)。画面表示部240はクライアント端末300からの要求を受け、管理者の指定した情報をフィルタ済情報230から読み出す。画面表示部240はフィルタ済情報230から読み出した情報から、表示用の情報を生成する。画面表示部240は表示用の情報をクライアント端末300へ送信する。クライアント端末300は、画面表示部240から表示用の情報を受信し、クライアント端末300のスクリーンに表示用の情報を表示する(ステップS602)。
【0073】
画面表示部240はフィルタ済情報230から読み出した情報から、表示用の情報を生成する際に、例えば、構成要素の情報、構成要素間の関係に関する情報を参照する。画面表示部240はフィルタ済情報230から読み出した情報から、例えば、フィルタ情報で指定されたサービスである「ServiceA」、例えば、「ServiceA-PodA」、「PodA-NodeA」といった識別子間のつながりを示す情報を参照して、「ServiceA」に対応するポッドやノードの名称を、画像によって表示してもよい。画面表示部240はフィルタ済情報230から読み出したタイムスタンプ(情報取得時の日時)を画像に含めてもよい。
【0074】
また、例えば、画面表示部240はフィルタ済情報230から読み出したノードのCPU利用率を画像に含めてもよい。画面表示部240は、画像のサムネイルをあらかじめ生成しておき、コンテナプラットフォーム100の管理者がクライアント端末300を介してモニタシステム200にフィルタ情報に合致したスナップショット情報の表示を要求する際に(ステップS601)、このサムネイルのリストを表示して管理者に提示してもよい。
【0075】
次に、画面の表示と分析の例を
図7から9に示す。まず、
図7は、各スナップショットの情報から、サービスに着目した画面の例である。
図7は、トリガ条件として、特定の時刻(11:30)と特定のフィルタ情報を指定した場合を想定する。また、この特定のフィルタ情報は、サービス名(ServiceA)を指定するものである。モニタシステム200はあらかじめ、このトリガ条件とフィルタ情報に従って特定の時刻(11:30)における最新のスナップショット情報にフィルタ処理を行い、フィルタ済情報230にこれを格納する。
図7は、モニタシステム200が格納したフィルタ済情報230から生成した画面である。
【0076】
図7に示すように、管理者は、「ServiceA」がいずれのポッド(「PodA」)で動作しているか、いずれのノード(「NodeA」)で動作しているか、いずれのストレージ(「PersistentVolumeClaimA」、「PersistentVolumeClaimB」)にアクセス可能か、いずれのコントローラ(「ControllerA」)と関連付けられているか、を視覚的に理解し得る。
【0077】
また、
図7と
図1とを比較すると、
図7においては関連のない構成要素が画面から削除されており、管理者にとって「ServiceA」の状態が容易に理解可能となり得る。また、
図7の情報は、管理者の要求を受けたときに、その都度モニタシステム200またはクライアント端末300がスナップショット情報210を参照して生成するものではない。
図7の情報は、すでにフィルタ済情報230に格納されたデータに基づくもので、モニタシステム200もしくはクライアント端末300に対する処理負荷を大幅に削減し得る。管理者も、
図7に示すような所望の情報を瞬時に参照し得る。
【0078】
図8は、各スナップショットの情報から、ノードに着目した画面の例である。
図8は、トリガ条件として、特定の時刻(11:30)と特定のフィルタ情報を指定した場合を想定する。また、この特定のフィルタ情報は、ノード名(NodeA)を指定するものである。モニタシステム200はあらかじめ、このトリガ条件とフィルタ情報に従って特定の時刻(11:30)における最新のスナップショット情報にフィルタ処理を行い、フィルタ済情報230にこれを格納する。
図8は、モニタシステム200が格納したフィルタ済情報230から生成した画面である。
【0079】
図8に示すように、管理者は、「NodeA」においてポッド(「PodA」)が動作しているか、いずれのサービス(「ServiceA」、「ServiceB」)に関連するものか、いずれのストレージ(「PersistentVolumeClaimA」、「PersistentVolumeClaimB」)にアクセス可能か、いずれのコントローラ(「ControllerA」)と関連付けられているか、を視覚的に理解し得る。
【0080】
また、
図8と
図1とを比較すると、
図8においては関連のない構成要素が画面から削除されており、管理者にとって「NodeA」の状態が容易に理解可能となり得る。また、
図8の情報は、管理者の要求を受けたときに、その都度モニタシステム200またはクライアント端末300がスナップショット情報210を参照して生成するものではない。
図8の情報は、すでにフィルタ済情報230に格納されたデータに基づくもので、モニタシステム200もしくはクライアント端末300に対する処理負荷を大幅に削減し得る。管理者も、
図8に示すような所望の情報を瞬時に参照し得る。
【0081】
図9は、各スナップショットの情報から、サービスなどのコンテナプラットフォーム100の構成要素の差分に着目した画面の例である。
図9は、トリガ条件として、特定の時間間隔(例えば30分)と特定のフィルタ情報を指定した場合を想定する。また、この特定のフィルタ情報は、サービスの差分を指定するものである(例えば「Filter003:Diff:Service」)。モニタシステム200はあらかじめ、このトリガ条件とフィルタ情報に従って特定の時間間隔(例えば30分)で最新のスナップショット情報と30分前のスナップショット情報とを用いたフィルタ処理を行う。このフィルタ処理は、スナップショット情報のサービスに関する情報の差分を取得し、フィルタ済情報230にこれを格納するものであり得る。
図9は、モニタシステム200が格納したフィルタ済情報230から生成した画面である。
【0082】
図9に示すように、管理者は、30分前に存在したサービス(「ServiceC」)が既に削除されており、30分前には存在しなかったサービス(「ServiceA」)が追加されたことを理解し得る。
【0083】
図9に示すように、管理者は、削除された「ServiceC」がいずれのポッド(「PodB」)で動作していたか、いずれのノード(「NodeA」)で動作していたか、を視覚的に理解し得る。
図9に示すように、管理者は、追加された「ServiceA」がいずれのポッド(「PodA」)で動作しているか、いずれのノード(「NodeA」)で動作しているか、いずれのストレージ(「PersistentVolumeClaimA」)にアクセス可能か、いずれのコントローラ(「ControllerA」)と関連付けられているか、を視覚的に理解し得る。
【0084】
また、
図9と
図1とを比較すると、
図9においては関連のない構成要素が画面から削除されており、管理者にとって追加された「ServiceA」と削除された「ServiceC」の状態が容易に理解可能となり得る。また、
図9の情報は、管理者の要求を受けたときに、その都度モニタシステム200またはクライアント端末300がスナップショット情報210を参照して生成するものではない。
図9の情報は、すでにフィルタ済情報230に格納されたデータに基づくもので、モニタシステム200もしくはクライアント端末300に対する処理負荷を大幅に削減し得る。管理者も、
図9に示すような所望の情報を瞬時に参照し得る。
【0085】
なお、
図9では例えば「ServiceA」は1個のみ表示されているが、追加もしくは削除されたサービスが複数存在してもよい。
図9では「ServiceA」は1個のみ表示されているが、「ServiceA」が複数存在してもよい。例えば、処理の負荷分散を目的として、「ServiceA」が複数存在し、異なる(あるいは同じ)ノードおよび/もしくはストレージが使用されてもよい。この場合、複数の「ServiceA」が画面表示されてもよい。
【0086】
上述のように、スナップショット情報210を分析し、分析結果を管理者/クライアント端末300に表示するにあたり、管理者の要求に応じてフィルタ済情報230に格納された情報をさらに編集することなく、いわばそのまま提示することが可能となり得る。従って、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度スナップショット情報210のデータを抽出してフィルタ処理を行うことを省略し得る。このため、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度発生していたフィルタ処理に必要となる計算量を大幅に抑制することができ得る。
【0087】
また、副次的な効果として、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度必要であったフィルタ処理を大幅に抑制することができることから、管理者の要求をクライアント端末300が受けてから、所望の情報をクライアント端末300のスクリーンに表示までに要する時間を大きく短縮でき得る。
【0088】
上記の実施形態では、フィルタ済情報230を管理者にそのまま表示している。このフィルタ済情報230を画面表示部240でさらにフィルタ処理してクライアント端末300のスクリーンに表示し、管理者に提示してもよい。例えば、管理者がノードとポッドの情報のみを必要とする場合、管理者は、クライアント端末300を介して画面表示部240にノードとポッドの情報のみを表示するよう要求してもよい。この場合、例えば、
図8の画面表示を行う際にサービス、ストレージ、コントローラの情報を省略して表示してもよい。
【0089】
上記の実施形態では、モニタシステム200がコンテナプラットフォーム100とは別のプラットフォーム上で動作している例を示している。モニタシステム200は、コンテナプラットフォーム100上で他のアプリケーションコンテナと同列に動作する形態であってもよい。
【0090】
上記の実施形態では、モニタシステム200がコンピュータプログラムであって、例えば、クライアント端末300、いずれかのノード(例えば「NodeA」)、あるいは、図示されない他のコンピュータ上で実行されてもよい。また、モニタシステム200がコンピュータプログラムであって、1つのコンピュータで実行されても、もしくは2以上のコンピュータで実行されてもよい。
【0091】
以下では上記の他の実施形態について説明する。
図10は、
図2と同様、コンテナプラットフォーム100(
図1)をモニタするモニタシステム200の概要を示す、概要図である。
図2と同じ符号番号を付した構成要素については、
図2と同様であるので、説明を省略する。なお、
図10において、
図2の構成情報フィルタ処理トリガ部270は構成情報フィルタ処理部260に含まれるものである。
【0092】
図11は、
図10のモニタシステム200の処理の流れを表すフローチャートである。
図11のステップS1101において、コンテナプラットフォームの情報を収集/蓄積(構成情報収集・蓄積部250)したスナップショット情報210に対して、フィルタ・トリガ条件設定情報220を参照してフィルタ処理を行う(構成情報フィルタ処理部260)。
【0093】
図11のステップS1102において、フィルタ処理後の情報がフィルタ済情報230として格納される(構成情報フィルタ処理部260)。
【0094】
図11のステップS1103において、ユーザの要求に応答して、フィルタ済情報230に格納されたコンテナプラットフォームの情報を提示する(画面表示部240)。
【0095】
図10の概要図に示される構成および
図11のフローチャートに示される処理においては、スナップショット情報210を分析し、分析結果を管理者/クライアント端末に表示するにあたり、管理者の要求に応じてフィルタ済情報230に格納された情報をさらに編集することなく、いわばそのまま提示することが可能となり得る。従って、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度スナップショット情報210のデータを抽出してフィルタ処理を行うことを省略し得る。このため、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度発生していたフィルタ処理に必要となる計算量を大幅に抑制することができ得る。
【0096】
また、副次的な効果として、管理者がコンテナプラットフォーム100の状態を確認する場合に、その都度必要であったフィルタ処理を大幅に抑制することができることから、管理者の要求をクライアント端末が受けてから、所望の情報をクライアント端末のスクリーンに表示までに要する時間を大きく短縮でき得る。
【0097】
なお、上記の実施形態の一部又は全部は、以下の付記に記載の側面のようにも記載されうるが、以下には限られない。
【0098】
(付記1)
第1の側面においては、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納し、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示する、ように構成されたシステムが提供され得る。
【0099】
(付記2)
第2の側面においては、上記システムにおいて、コンテナプラットフォームの情報が、所定の時間間隔で前記スナップショット情報として収集/蓄積され、フィルタ・トリガ条件設定情報がトリガ条件とフィルタ情報とを格納し、トリガ条件に従って、フィルタ情報を参照して、フィルタ処理が行われてもよい。
【0100】
(付記3)
第3の側面においては、上記システムにおいて、トリガ条件が、フィルタ・トリガ条件設定情報に格納されたフィルタ情報のうちの少なくとも1つを参照してフィルタ処理を行うための条件を指定してもよい。
【0101】
(付記4)
第4の側面においては、上記システムにおいて、フィルタ情報が、フィルタ処理において、コンテナプラットフォームの少なくとも1つの構成要素に関する情報の取得を行うことを示すものであってもよい。
【0102】
(付記5)
第5の側面において、上記システムは、ユーザの要求に応答して、フィルタ・トリガ条件設定情報の更新を行う、ように更に構成されてもよい。
【0103】
(付記6)
第6の側面では、上記システムが、フィルタ・トリガ条件設定情報に格納されたトリガ条件を、所定の時間間隔でチェックしてもよい。
【0104】
(付記7)
第7の側面では、上記システムにおいて、トリガ条件が、フィルタ処理の実行の時間間隔を指定するものであってもよい。
【0105】
(付記8)
第8の側面では、上記システムにおいて、ユーザの要求に応答して提示される情報が、フィルタ情報が示すコンテナプラットフォームの少なくとも1つの構成要素に着目した情報と、少なくとも1つの構成要素に関係する構成要素の情報を含んでもよい。
【0106】
(付記9)
第9の側面においては、例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示することと、を具備する、コンテナプラットフォームのモニタ方法が提供され得る。
【0107】
(付記10)
第10の側面においては、例えば、コンテナプラットフォームの情報を収集/蓄積したスナップショット情報に対して、フィルタ・トリガ条件設定情報を参照してフィルタ処理を行い、フィルタ処理後の情報をフィルタ済情報として格納することと、ユーザの要求に応答して、フィルタ済情報に格納されたコンテナプラットフォームの情報を提示することと、をコンピュータに実行させる命令を具備する、コンピュータプログラムが提供され得る。
【0108】
上記の実施形態により、例えば、サービスもしくはシステムに関する分析に要する時間と処理の負荷を低減することが可能となり得る。これにより、サービスもしくはシステムに関する分析の実行によってコンテナプラットフォーム、コンテナ、アプリケーションプログラムなどの実行を阻害することを回避し得る。ただし、これは、本願や本発明の範囲を限定/制限するものではない。
【0109】
上記の実施形態において、コンピュータは、プロセッサと、メモリと、ストレージ(ハードディスク、SSD(solid state drive)、光ディスクドライブ、光磁気ディスクドライブなど)と、有線/無線の通信装置を備えてもよい。
【0110】
上記の実施形態は、例えば、コンテナプラットフォーム上で動作するサービスやアプリケーションコンテナを管理する運用管理製品/システムへの適用が考えられ得る。しかし、本願、本発明はこれに限定/制限されるものではない。
【0111】
以上の開示は例である。従って、本願と本発明は、上記の開示のみに限定/制限して解釈されるべきではない。
【符号の説明】
【0112】
100 コンテナプラットフォーム
200 モニタシステム
210 スナップショット情報
220 フィルタ・トリガ条件設定情報
230 フィルタ済情報
240 画面表示部
250 構成情報収集・蓄積部
260 構成情報フィルタ処理部
270 構成情報フィルタ処理トリガ部
300 クライアント端末