特開 2024-168360 ログ管理装置、ログ管理方法、およびログ管理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024168360

(43)【公開日】2024-12-05

(54)【発明の名称】ログ管理装置、ログ管理方法、およびログ管理プログラム

(51)【国際特許分類】

   G06F 11/30 20060101AFI20241128BHJP

【ＦＩ】

G06F11/30 175

G06F11/30 140A

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2023084935

(22)【出願日】2023-05-23

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100104190

【弁理士】

【氏名又は名称】酒井 昭徳

(72)【発明者】

【氏名】中川 修一

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042MA05

5B042MA08

5B042MA09

5B042MA16

5B042MC15

5B042MC40

(57)【要約】

【課題】マイクロサービスについての観測情報の格納先となるデータベースへの格納量を調整可能にすること。
【解決手段】ログ管理装置１０１は、複数のマイクロサービスの各マイクロサービスから収集された観測情報（例えば、観測情報集合１２０）のうち、同一のリクエストＩＤを含む観測情報群（例えば、観測情報群１２１～１２３）を取得する。観測情報は、各マイクロサービスにおいて実行された処理に関する情報である。リクエストＩＤは、リクエストに応じて実行される一連の処理を識別する識別子である。ログ管理装置１０１は、取得した観測情報群から、エラー情報および警告情報を検索する。エラー情報は、エラーの発生を示す情報である。警告情報は、エラーの要因となり得る事象の発生を示す情報である。ログ管理装置１０１は、検索した検索結果に応じて、観測情報群のうちの一部または全部の情報をデータベース１１０に格納する。
【選択図】図１

【特許請求の範囲】

【請求項1】

複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群のうちの一部または全部の情報を格納先となるデータベースに格納する、
制御部を有することを特徴とするログ管理装置。

【請求項2】

前記観測情報群は、異なるデータ種の観測情報を含み、
前記制御部は、
前記観測情報群それぞれのデータ種を参照して、前記観測情報群から、あらかじめ決められた一部の情報を抽出することにより、抽出した前記一部の情報を含む、フォーマット化されたログ情報を作成し、
前記観測情報群から前記エラー情報および前記警告情報が検索されなかった場合、前記観測情報群について、作成した前記フォーマット化されたログ情報のみを前記データベースに格納する、
ことを特徴とする請求項１に記載のログ管理装置。

【請求項3】

前記制御部は、
前記観測情報群から、前記エラー情報が検索されず、かつ、前記警告情報が検索された場合には、前記観測情報群から前記警告情報を含む観測情報と同一のデータ種の観測情報を特定し、
前記観測情報群について、前記フォーマット化されたログ情報とともに、特定した前記観測情報を前記データベースに格納する、
ことを特徴とする請求項２に記載のログ管理装置。

【請求項4】

前記制御部は、
前記観測情報群から前記エラー情報が検索された場合、前記フォーマット化されたログ情報とともに、前記観測情報群を前記データベースに格納する、
ことを特徴とする請求項２に記載のログ管理装置。

【請求項5】

前記観測情報群は、イベント、メトリクス、ログおよびトレースの少なくともいずれかのデータ種の観測情報を含み、
前記一部の情報は、前記観測情報群のうちのイベントの観測情報から抽出される、前記リクエストに応じた動作の起点となる処理の情報および前記リクエストＩＤを含む、
ことを特徴とする請求項２～４のいずれか一つに記載のログ管理装置。

【請求項6】

前記一部の情報は、前記観測情報群のうちのログおよびトレースの観測情報から抽出される、前記リクエストに応じて動作したマイクロサービスの遷移を表す情報を含む、
ことを特徴とする請求項５に記載のログ管理装置。

【請求項7】

複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群のうちの一部または全部の情報を格納先となるデータベースに格納する、
処理をコンピュータが実行することを特徴とするログ管理方法。

【請求項8】

複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群のうちの一部または全部の情報を格納先となるデータベースに格納する、
処理をコンピュータに実行させることを特徴とするログ管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ログ管理装置、ログ管理方法、およびログ管理プログラムに関する。

【背景技術】

【0002】

マイクロサービスは、独立して開発されて稼働するソフトウェアコンポーネントを複数組み合わせることで、一つのサービスを構成するソフトウェアの構造となっている。マイクロサービスのアプリケーションプログラムの稼働状態を監視するために、マイクロサービスの観測情報が収集される場合がある。マイクロサービスの観測情報は、例えば、システムの運用を停止することなく収集され、システムの性能評価に用いられる。

【0003】

先行技術としては、エージェント装置が、処理部から逐次監視値を取得し、監視値からノイズを除去して生成した除去済み監視値を、マネージャ装置に送信し、マネージャ装置が、エージェント装置から取得した除去済み監視値を参照して、エージェント装置から監視値を取得する監視間隔を決定する監視システムがある。また、マイクロサービスの実行に関する通知を管理するための技術がある。また、テレメトリ技術を利用してデータを定期的に配信する複数の業務装置を管理するための技術がある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】国際公開第２０２１／０９５１１４号

【特許文献2】米国特許出願公開第２０２２／０２４５０１７号明細書

【特許文献3】特開２０２０－２８００５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、従来技術では、システムの性能評価などのために収集される、マイクロサービスについての観測情報の格納先となるデータベースへの格納量を調整することができないという問題がある。

【0006】

一つの側面では、本発明は、マイクロサービスについての観測情報の格納先となるデータベースへの格納量を調整可能にすることを目的とする。

【課題を解決するための手段】

【0007】

１つの実施態様では、複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、検索した検索結果に応じて、前記観測情報群のうちの一部または全部の情報を格納先となるデータベースに格納する、ログ管理装置が提供される。

【発明の効果】

【0008】

本発明の一側面によれば、マイクロサービスについての観測情報の格納先となるデータベースへの格納量を調整可能にすることができるという効果を奏する。

【図面の簡単な説明】

【0009】

【図1】図１は、実施の形態にかかるログ管理方法の一実施例を示す説明図である。

【図2】図２は、情報処理システム２００のシステム構成例を示す説明図である。

【図3】図３は、ログ管理サーバ２０１のハードウェア構成例を示すブロック図である。

【図4】図４は、ログ管理サーバ２０１の機能的構成例を示すブロック図である。

【図5】図５は、情報処理システム２００の動作例を示す説明図である。

【図6】図６は、アプリケーションの第１の動作例を示す説明図である。

【図7A】図７Ａは、テレメトリーデータの第１のサンプル例を示す説明図（その１）である。

【図7B】図７Ｂは、テレメトリーデータの第１のサンプル例を示す説明図（その２）である。

【図7C】図７Ｃは、テレメトリーデータの第１のサンプル例を示す説明図（その３）である。

【図7D】図７Ｄは、テレメトリーデータの第１のサンプル例を示す説明図（その４）である。

【図7E】図７Ｅは、テレメトリーデータの第１のサンプル例を示す説明図（その５）である。

【図7F】図７Ｆは、テレメトリーデータの第１のサンプル例を示す説明図（その６）である。

【図8A】図８Ａは、フォーマット化ログの第１の作成例を示す説明図（その１）である。

【図8B】図８Ｂは、フォーマット化ログの第１の作成例を示す説明図（その２）である。

【図9】図９は、構造化ログの第１の格納例を示す説明図である。

【図10A】図１０Ａは、フォーマット化ログの第２の作成例を示す説明図（その１）である。

【図10B】図１０Ｂは、フォーマット化ログの第２の作成例を示す説明図（その２）である。

【図11】図１１は、構造化ログの第２の格納例を示す説明図である。

【図12】図１２は、アプリケーションの第２の動作例を示す説明図である。

【図13A】図１３Ａは、テレメトリーデータの第２のサンプル例を示す説明図（その１）である。

【図13B】図１３Ｂは、テレメトリーデータの第２のサンプル例を示す説明図（その２）である。

【図13C】図１３Ｃは、テレメトリーデータの第２のサンプル例を示す説明図（その３）である。

【図14A】図１４Ａは、フォーマット化ログの第２の作成例を示す説明図（その１）である。

【図14B】図１４Ｂは、フォーマット化ログの第２の作成例を示す説明図（その２）である。

【図15】図１５は、構造化ログの第３の格納例を示す説明図である。

【図16】図１６は、アプリケーションの第３の動作例を示す説明図である。

【図17A】図１７Ａは、テレメトリーデータの第２のサンプル例を示す説明図（その１）である。

【図17B】図１７Ｂは、テレメトリーデータの第２のサンプル例を示す説明図（その２）である。

【図17C】図１７Ｃは、テレメトリーデータの第２のサンプル例を示す説明図（その３）である。

【図18A】図１８Ａは、フォーマット化ログの第２の作成例を示す説明図（その１）である。

【図18B】図１８Ｂは、フォーマット化ログの第２の作成例を示す説明図（その２）である。

【図19】図１９は、構造化ログの第４の格納例を示す説明図である。

【図20】図２０は、ログ管理サーバ２０１のログ管理処理手順の一例を示すフローチャート（その１）である。

【図21】図２１は、ログ管理サーバ２０１のログ管理処理手順の一例を示すフローチャート（その２）である。

【図22】図２２は、フォーマット化処理の具体的処理手順の一例を示すフローチャート（その１）である。

【図23】図２３は、フォーマット化処理の具体的処理手順の一例を示すフローチャート（その２）である。

【発明を実施するための形態】

【0010】

以下に図面を参照して、本発明にかかるログ管理装置、ログ管理方法、およびログ管理プログラムの実施の形態を詳細に説明する。

【0011】

（実施の形態）
図１は、実施の形態にかかるログ管理方法の一実施例を示す説明図である。図１において、ログ管理装置１０１は、複数のマイクロサービスの各マイクロサービスから収集される観測情報の格納先となるデータベース１１０への格納量を調整するコンピュータである。マイクロサービスは、１つのサービスを機能ごとに分割したアーキテクチャ、または、１つのサービスを分割した機能それぞれを実現するソフトウェアである。

【0012】

システムをマイクロサービス化することで、機能追加や障害修正を行う場合に個々のマイクロサービスを入れ替えることで対処できるため、システム全体を停止することなく、修正スピードの向上や可用性の向上が見込まれる。各マイクロサービスは、例えば、それぞれ異なるサーバによって実行される。サーバは、例えば、物理サーバや仮想マシンである。また、マイクロサービスは、コンテナによって実行されてもよい。

【0013】

複数のマイクロサービスは、例えば、呼び出し関係のあるマイクロサービスを含む。呼出関係にある複数のマイクロサービスは、システムを実現するためのマイクロサービスの集合であり、複数のマイクロサービスに含まれるマイクロサービスが他のマイクロサービスを呼び出しながら機能を実現する。

【0014】

観測情報は、マイクロサービスにおいて実行された処理に関する情報であり、マイクロサービスの動きを観測するためのものである。観測情報は、ログ情報とも呼ばれる。観測情報には、複数のデータ種の観測情報がある。データ種としては、例えば、イベント、メトリクス、ログ、トレースなどがある。

【0015】

イベントは、ある時刻に発生した個々のリクエストやアクションの記録である。メトリクスは、マイクロサービスの実行に関して、計測、集計等された数値的な情報である。ログは、アプリケーションやプラットフォーム内で個々の動作が実行されたときにシステムが生成する情報（テキストデータ）である。

【0016】

また、トレースは、複数のサービスに跨がってリクエストが処理される際に、どの順番でサービスが呼び出されたのかの遷移を表す情報である。エラーや警告などのメッセージが、メトリクスの数値的な情報とともに出力されたり、ログとして出力されたりする場合がある。

【0017】

複数のマイクロサービスから構成されるシステム（サービス）は、マイクロサービスごとの分散サービスシステムとなる。このため、各マイクロサービスを適切に管理し、効率よく動作するように監視することは重要である。また、マイクロサービスの状態を監視するためのロジックを各マイクロサービスに組み込むには、分散されたマイクロサービスごとにメトリックやライブラリを用意することになり非効率である。

【0018】

このため、各マイクロサービス（アプリケーションプログラム）の稼働状態を監視するための観測情報を収集して、システムの性能評価などを行う場合がある。一方、クラウドに展開しているマイクロサービスアーキテクチャは、複数のマイクロサービスを利用して拡大可能な構成になっている。

【0019】

マイクロサービスアーキテクチャが拡大すると、それに伴ってマイクロサービスから収集される観測情報のデータ量が増え、データの保管に必要なメモリ領域の増大を招く。また、クラウドにおいてデータの保管に必要なメモリ領域を確保するには、収集するデータ量とそれらの転送量に応じた課金となることが多い。

【0020】

従来、複数のマイクロサービスから構成されるシステムにおいて、分散されたマイクロサービスの管理が破綻しないように、網の目状（メッシュ）につながっているサービス間通信を適切に管理するための「サービスメッシュ」という仕組みがある。サービスメッシュでは、各マイクロサービスに不随する軽量なプロキシを設けて、サービスディスカバリ、トラフィックコントロール、可観測性、障害分離、セキュリティなどの管理機能を実現する。

【0021】

サービスディスカバリは、呼び出すマイクロサービスのネットワーク上の位置を特定する仕組みである。トラフィックコントロールは、マイクロサービスへのアクセスの割り振りを設定に基づいて変更したり、マイクロサービスからの戻り値を変更したりして、サービス間の通信を制御する仕組みである。

【0022】

可観測性は、マイクロサービスから出力されるデータから内部状態を確認して、マイクロサービスの正常性を判断する仕組みである。障害分離は、個々のマイクロサービスで障害が発生した際に、その影響範囲をできるだけ最小限に抑えるための仕組みである。セキュリティは、マイクロサービスが他のマイクロサービスを呼び出す際の認証／認可やセキュアな通信を効率よく管理するための仕組みである。

【0023】

ここで、サービスメッシュは、例えば、コントロールプレーンとデータプレーンの２つのコンポーネントを含む。コントロールプレーンは、サービスメッシュの管理を担当し、サービスディスカバリなどの管理に必要な情報を保管したり、構成変更などの管理の命令を発行したりする。データプレーンは、コントロールプレーンからの指示を受けてサービスの通信をコントロールしたり、管理に必要な情報をコントロールプレーンに送信したりする。

【0024】

各マイクロサービスの観測情報は、例えば、コントロールプレーンにおいて、サービスメッシュにおける可観測性の仕組みにより、データプレーンから収集することができる。コントロールプレーンは、例えば、各データプレーンから収集した観測情報をデータベースに格納して、システムの性能評価（システムやアプリケーションの改善や障害個所の特定など）を実施する。

【0025】

しかしながら、従来技術では、マイクロサービスについて収集される観測情報のデータベースへの格納量を調整することができない。例えば、収集される観測情報のデータ量は、種々の条件下において、高密度（データ種：多、集計間隔：短）となれば膨大なデータ量となり、データベースやストレージを圧迫することになる。

【0026】

一方、データベースやストレージの圧迫を避けるような低密度（データ種：少、集計間隔：長）とすれば、障害が発生したときや、システムやアプリケーションの改善を実施する際に、データが不足するという事態になる。従来技術では、観測情報のデータベースへの格納量を、どのような基準で調整すればよいのか判断することができない。

【0027】

そこで、本実施の形態では、マイクロサービスについての観測情報の格納先となるデータベース（例えば、データベース１１０）への格納量を調整可能にするログ管理方法について説明する。ここで、ログ管理装置１０１の処理例（下記（１）～（３）の処理に対応）について説明する。

【0028】

（１）ログ管理装置１０１は、複数のマイクロサービスの各マイクロサービスから収集された観測情報のうち、同一のリクエストＩＤを含む観測情報群を取得する。観測情報は、各マイクロサービスにおいて実行された処理に関する情報である。リクエストＩＤは、リクエストに応じて実行される一連の処理を識別する識別子である。

【0029】

観測情報には、マイクロサービスに跨がるリクエストのつながりを特定するためにリクエストＩＤが含まれる。このリクエストＩＤを一連の処理全体で使い続けることで、収集される膨大な数の観測情報の中から、一連の処理に関する観測情報を抽出することが可能となる。

【0030】

図１の例では、観測情報集合１２０を、複数のマイクロサービスの各マイクロサービスから収集された観測情報の集合とする。この場合、ログ管理装置１０１は、観測情報集合１２０から、同一のリクエストＩＤを含む観測情報群を取得する。ここでは、同一のリクエストＩＤ（図１中、「ＩＤ」）を含む観測情報群１２１～１２３が取得された場合を想定する。

【0031】

（２）ログ管理装置１０１は、取得した観測情報群から、エラー情報および警告情報を検索する。ここで、エラー情報は、エラーの発生を示す情報である。警告情報は、エラーの要因となり得る事象の発生を示す情報である。エラーの要因となり得る事象は、例えば、「処理時間が長い」、「応答が遅い」、「ある情報がない」などである。

【0032】

エラー情報や警告情報は、観測情報に含まれる場合がある。観測情報におけるエラー情報は、例えば、「ＥＲＲＯＲ」、「エラー」などの文字列によって特定される。また、観測情報における警告情報は、例えば、「ＷＡＲＮ」、「警告」などの文字列によって特定される。

【0033】

（３）ログ管理装置１０１は、検索した検索結果に応じて、観測情報群のうちの一部または全部の情報をデータベース１１０に格納する。データベース１１０は、観測情報の格納先となるデータベースである。データベース１１０は、ログ管理装置１０１が有していてもよく、また、ログ管理装置１０１からアクセス可能な他のコンピュータが有していてもよい。

【0034】

ここで、観測情報群からエラー情報および警告情報が検索されなかった場合、システムが正常に稼働して一連の処理が完了したケースであり、観測情報群の全てを格納する必要性は低いといえる。このため、ログ管理装置１０１は、例えば、観測情報群のうちのあらかじめ決められた一部の情報のみを格納するようにして、データベース１１０への格納量を減らす。

【0035】

一部の情報は、例えば、リクエストに応じた動作の起点となる処理の情報（イベント）やリクエストＩＤを含む。また、一部の情報は、リクエストに応じて動作したマイクロサービスの遷移を表す情報を含むものであってもよい。また、一部の情報は、リクエストに応じた動作が終了したときのメトリクスの情報やステータスコードを含むものであってもよい。

【0036】

また、観測情報群から、エラー情報が検索されず、かつ、警告情報が検索された場合、一連の処理の中でエラーは発生していないものの、エラーの要因となり得る事象が発生したケースである。この場合、その事象についての分析を行って、さらなる調査が必要なのかどうかを判断すべきであるといえる。

【0037】

このため、ログ管理装置１０１は、例えば、観測情報群のうち、警告情報を含む観測情報と同一のデータ種の観測情報のみをデータベース１１０に格納してもよい。警告情報を含む観測情報と同一のデータ種の観測情報は、エラーの要因となり得る事象の分析に有用な情報といえる。

【0038】

また、ログ管理装置１０１は、観測情報群のうち、警告情報を含む観測情報のみをデータベース１１０に格納してもよい。これにより、ログ管理装置１０１は、観測情報群の全てを格納する場合に比べて、データベース１１０への格納量を減らす。ただし、ログ管理装置１０１は、警告情報が検索された場合に、観測情報群の全てをデータベース１１０に格納してもよい。

【0039】

また、観測情報群からエラー情報が検索された場合、一連の処理の中で何らかのエラーが発生したケースであり、障害箇所の特定や原因を究明して対応すべき状況であるといえる。このため、ログ管理装置１０１は、例えば、観測情報群の全てをデータベース１１０に格納する。

【0040】

図１の例では、まず、観測情報群１２１～１２３からエラー情報および警告情報が検索されなかったとする。この場合、ログ管理装置１０１は、例えば、観測情報群１２１～１２３から、あらかじめ決められた一部の情報１３０を抽出する。そして、ログ管理装置１０１は、観測情報群１２１～１２３について、抽出した一部の情報１３０のみをデータベース１１０に格納してもよい。

【0041】

また、観測情報群１２１～１２３から、エラー情報が検索されず、かつ、警告情報が検索されたとする。この場合、ログ管理装置１０１は、例えば、観測情報群１２１～１２３から、警告情報を含む観測情報を抽出する。ここでは、警告情報を含む観測情報１２１，１２２が抽出されたとする。この場合、ログ管理装置１０１は、観測情報群１２１～１２３について、抽出した観測情報１２１，１２２をデータベース１１０に格納してもよい。この際、ログ管理装置１０１は、抽出した観測情報１２１，１２２を、一部の情報１３０とともにデータベース１１０に格納してもよい。

【0042】

また、観測情報群１２１～１２３から、エラー情報が検索されたとする。この場合、ログ管理装置１０１は、例えば、観測情報群１２１～１２３をデータベース１１０に格納してもよい。この際、ログ管理装置１０１は、観測情報群１２１～１２３を、一部の情報１３０とともにデータベース１１０に格納してもよい。

【0043】

このように、ログ管理装置１０１によれば、マイクロサービスについての観測情報の格納先となるデータベース１１０への格納量を調整することができる。例えば、ログ管理装置１０１は、同一のリクエストＩＤに紐付いた観測情報群単位で、エラー情報や警告情報が含まれるかどうかによって、観測情報群のうちの一部の情報のみを格納するのか、全部の情報を格納するのかを調整することができる。このため、ログ管理装置１０１は、システムの性能評価などに有用な情報を残しつつ、データベース１１０における観測情報の保管に使用する記憶容量を削減することができる。

【0044】

（情報処理システム２００のシステム構成例）
つぎに、図１に示したログ管理装置１０１を含む情報処理システム２００のシステム構成例について説明する。ここでは、図１に示したログ管理装置１０１を、情報処理システム２００内のログ管理サーバ２０１に適用した場合を例に挙げて説明する。情報処理システム２００は、例えば、マイクロサービスアーキテクチャを利用してウェブサービスを提供するコンピュータシステムに適用される。

【0045】

図２は、情報処理システム２００のシステム構成例を示す説明図である。図２において、情報処理システム２００は、ログ管理サーバ２０１と、処理装置Ｍ１～Ｍｍ（ｍ：２以上の自然数）とを含む。情報処理システム２００において、ログ管理サーバ２０１および処理装置Ｍ１～Ｍｍは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などである。

【0046】

ここで、ログ管理サーバ２０１は、データベース２２０へのテレメトリーデータの格納量を調整するコンピュータである。データベース２２０は、テレメトリーデータの格納先となるデータベースである。テレメトリーデータは、複数のマイクロサービスの各マイクロサービスから出力される観測情報に対応する。

【0047】

データベース２２０は、データベースＬｖ１、データベースＬｖ２およびデータベースＬｖ３を含む。データベースＬｖ１、データベースＬｖ２およびデータベースＬｖ３は、データベース２２０内の区分けされた異なる記憶領域（第１の記憶領域、第２の記憶領域、第３の記憶領域）に相当する。図１に示したデータベース１１０は、例えば、データベース２２０に対応する。

【0048】

ここでは、ログ管理サーバ２０１がデータベース２２０を有する場合について説明する。ただし、データベース２２０は、ログ管理サーバ２０１からアクセス可能な他のコンピュータ（例えば、データベースサーバ）が有していてもよい。

【0049】

また、ログ管理サーバ２０１は、コントロールプレーンＣを有する。コントロールプレーンＣは、サービスメッシュを構成するコンポーネントの一つであり、サービスメッシュの管理を担当する。コントロールプレーンＣは、サービスメッシュで接続されているマイクロサービスの管理に必要な情報を保管したり、構成変更などの管理の命令を発行したりする。例えば、コントロールプレーンＣは、データプレーンに管理の指示を送信することにより、サービスにかかる通信を制御して、マイクロサービスの管理を行う。

【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】

また、ログ構造化部４０２は、テレメトリーデータ群からエラー情報が検索された場合、検索されたエラー情報をフォーマット化ログに追加してもよい。また、ログ構造化部４０２は、テレメトリーデータ群から警告情報が検索された場合、検索された警告情報をフォーマット化ログに追加してもよい。

【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】

つぎに、コントロールプレーンＣは、テレメトリーデータ群７２０のＴｙｐｅ「ＭＥＴＲＩＣ」のテレメトリーデータから、リクエストに応じた動作が終了したときの情報を抽出する。ここでは、（２Ｇ）動作の完了フラグのタイムスタンプ、メトリックデータ（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）およびステータスコードの情報が抽出される。

【0147】

また、コントロールプレーンＣは、テレメトリーデータ群７２０のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、その他の情報として、リクエストユーザのＩＤを抽出する。ここでは、（２Ｈ）「ｒｅｑｕｅｓｔ ｕｓｅｒ＿ｉｄ ７５２．２５４．２１１．３８」が抽出される。

【0148】

また、コントロールプレーンＣは、テレメトリーデータ群７２０から、エラー情報および警告情報を検索する。ここでは、テレメトリーデータ群７２０からエラー情報および警告情報は検索されない。

【0149】

図１０Ｂにおいて、コントロールプレーンＣは、コンテキスト１０００から、フォーマット化ログ１００１を作成する。コントロールプレーンＣは、テレメトリーデータ群７２０とフォーマット化ログ１００１とをセットにして、構造化ログ（ここでは、「構造化ログＬＧ２」という）とする。

【0150】

つぎに、コントロールプレーンＣは、フォーマット化ログ１００１を参照して、あらかじめ定義された査定方法に従って、構造化ログのレベルを判定する。ここでは、フォーマット化ログ１００１には、エラー情報および警告情報のいずれも含まれない。このため、コントロールプレーンＣは、構造化ログのレベルを「Ｌｖ１」と判定する。そして、コントロールプレーンＣは、判定したレベル「Ｌｖ１」をフォーマット化ログ１００１に設定する（図１０Ｂ中、符号１００２部分）。

【0151】

つぎに、図１１を用いて、構造化ログＬＧ２の格納例について説明する。

【0152】

図１１は、構造化ログの第２の格納例を示す説明図である。図１１において、コントロールプレーンＣは、構造化ログＬＧ２内のテレメトリーデータ群７２０のデータベース２２０への格納量を調整する。具体的には、例えば、コントロールプレーンＣは、フォーマット化ログ１００１内のレベルに応じて、構造化ログＬＧ２に含まれるテレメトリーデータ群７２０を加工する。

【0153】

ここでは、フォーマット化ログ１００１内のレベルが「Ｌｖ１」のため、コントロールプレーンＣは、構造化ログＬＧ２からテレメトリーデータ群７２０を削除する。そして、コントロールプレーンＣは、テレメトリーデータ群７２０が削除された構造化ログＬＧ２を、データベース２２０内のデータベースＬｖ１に格納する。

【0154】

このように、ケース１では、ユーザリクエストによるアプリケーションの稼働が正常に開始され、一連の処理が完了したケースであり、ケース１，２，３（ケース２，３は後述する）の中で、データベース２２０に送出されるデータ量は最小となる。

【0155】

・ケース２：構造化ログのレベル判定例およびＤＢ格納例
つぎに、ケース２の構造化ログのレベル判定例およびＤＢ格納例について説明する。

【0156】

図１２は、アプリケーションの第２の動作例を示す説明図である。図１２において、ケース１と同様に、ユーザからのリクエストに対して処理するサービス＃１と、サービス＃１からリクエストされた動作を実行するサービス２、３とが示されている。サービス＃２，＃３には、情報が格納されているデータベースＤＢ＿２，ＤＢ＿３が接続されている。

【0157】

ケース２では、ユーザから“Ｐ３ ＳＥＴ”の在庫確認を受け付けた場合を想定する。ケース２では、サービス＃１により、“Ｐ３ ＳＥＴ”の在庫情報の確認するために、サービス＃２を呼び出している。各サービス＃１～＃３についてログ出力される情報（テレメトリーデータ）は、テレメトリーデータ１２００として一箇所（コントロールプレーンＣ）に収集される。

【0158】

つぎに、図１３Ａ～図１３Ｃを用いて、テレメトリーデータ１２００について説明する。

【0159】

図１３Ａ～図１３Ｃは、テレメトリーデータの第２のサンプル例を示す説明図である。図１３Ａ～図１３Ｃにおいて、テレメトリーデータ群１３００は、図１２に示したテレメトリーデータ１２００に含まれるテレメトリーデータ群の一例である。

【0160】

テレメトリーデータ群１３００は、”Ｐ３ ＳＥＴ”の在庫確認のリクエストに関する同一のリクエストＩＤ（１９６９０３１７－ｓ５８８８ｙ－１２３４７６）のテレメトリーデータ（ログ情報）を、時系列に並べたものである。コントロールプレーンＣは、テレメトリーデータ群１３００からフォーマット化ログを作成する。

【0161】

図１４Ａおよび図１４Ｂは、フォーマット化ログの第２の作成例を示す説明図である。図１４Ａにおいて、コントロールプレーンＣは、テレメトリーデータ群１３００から、”Ｐ３ ＳＥＴ”の在庫確認というユーザリクエストに対する一意のログフォーマットの形にするためのコンテキスト１４００を作成する。コンテキスト１４００は、フォーマット化ログの内容に対応する。

【0162】

まず、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＥＶＥＮＴ」のテレメトリーデータから、リクエストに応じた動作の起点となる処理の情報を抽出する。ここでは、（３Ａ）ｔｙｐｅ「ＥＶＥＮＴ」のｍｅｔｈｏｄより、“ｄｂ ｑｕｅｒｙ”の「ｇｅｔ ｃｏｎｔｅｎｔｓ ｍｅｔｈｏｄ（在庫確認）」のタイムスタンプとリクエストＩＤ「１９６９０３１７－ｓ５８８８ｙ－１２３４７６」が抽出される。

【0163】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＬＯＧ，ＴＲＡＣＥ」のテレメトリーデータから、リクエストに応じて動作したサービス＃ｉスの遷移を表す情報を抽出する。ここでは、（３Ｂ），（３Ｃ），（３Ｄ）テレメトリーデータ群１３００のｔｙｐｅ「ＬＯＧ」とｔｙｐｅ「ＴＲＡＣＥ」のテレメトリーデータから、動作したサービスの遷移を表す情報「ＳＥＲＶＩＣＥ１，ＳＥＲＶＩＣＥ２，ＳＥＲＶＩＣＥ１」が抽出される。

【0164】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、インプットされた情報を抽出する。ここでは、（３Ｅ）「Ｐ３ ＳＥＴ」が抽出される。つぎに、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、最後に遷移したサービス＃ｉの動作の情報を抽出する。ここでは、（３Ｆ）「０１８１３」の動作の情報が抽出される。

【0165】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＭＥＴＲＩＣ」のテレメトリーデータから、リクエストに応じた動作が終了したときの情報を抽出する。ここでは、（３Ｇ）動作の完了フラグのタイムスタンプおよびメトリックデータ（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）が抽出される。

【0166】

また、コントロールプレーンＣは、テレメトリーデータ群１３００から、エラー情報および警告情報を検索する。ここでは、（３Ｇ）テレメトリーデータ群１３００から警告情報（ｌｅｖｅｌ「ＷＡＲＮ」）が検索され、警告情報を含むテレメトリーデータのステータスコード（ｓｔａｔｕｓ＿ｃｏｄｅ：ｄｅｌａｙ）が抽出される。

【0167】

また、コントロールプレーンＣは、テレメトリーデータ群１３００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、その他の情報として、リクエストユーザのＩＤを抽出する。ここでは、（３Ｈ）「ｒｅｑｕｅｓｔ ｕｓｅｒ＿ｉｄ ７５２．２５４．２１１．３８」が抽出される。

【0168】

図１４Ｂにおいて、コントロールプレーンＣは、コンテキスト１４００から、フォーマット化ログ１４０１を作成する。コントロールプレーンＣは、テレメトリーデータ群１３００とフォーマット化ログ１４０１とをセットにして、構造化ログ（ここでは、「構造化ログＬＧ３」という）とする。

【0169】

つぎに、コントロールプレーンＣは、フォーマット化ログ１４０１を参照して、あらかじめ定義された査定方法に従って、構造化ログＬＧ３のレベルを判定する。ここでは、フォーマット化ログ１４０１に警告情報が含まれる。また、警告情報があるものの、”Ｐ３ ＳＥＴ”の在庫確認のユーザリクエストに対する処理は完了しており、連結されたサービスに影響ある事象ではないといえる。ユーザリクエストに対する処理の完了は、例えば、ステータスコード「ｏｋ」から特定される。

【0170】

このため、コントロールプレーンＣは、構造化ログＬＧ３のレベルを「Ｌｖ２」と判定する。そして、コントロールプレーンＣは、判定したレベル「Ｌｖ２」をフォーマット化ログ１４０１に設定する（図１４Ｂ中、符号１４０２部分）。

【0171】

つぎに、図１５を用いて、構造化ログＬＧ３の格納例について説明する。

【0172】

図１５は、構造化ログの第３の格納例を示す説明図である。図１５において、コントロールプレーンＣは、構造化ログＬＧ３内のテレメトリーデータ群１３００のデータベース２２０への格納量を調整する。具体的には、例えば、コントロールプレーンＣは、フォーマット化ログ１４０１内のレベルに応じて、構造化ログＬＧ３に含まれるテレメトリーデータ群１３００を加工する。

【0173】

ここでは、フォーマット化ログ１４０１内のレベルが「Ｌｖ２」のため、コントロールプレーンＣは、構造化ログＬＧ３内のテレメトリーデータ群１３００のうち、メトリクスデータ以外を削除する。メトリクスデータは、警告情報を含むテレメトリーデータと同一データ種のテレメトリーデータであり、被疑箇所を確認するための情報となる。この結果、構造化ログＬＧ３内のテレメトリーデータ群１３００のうちメトリクスデータ１５０１～１５０４のみが残る。

【0174】

そして、コントロールプレーンＣは、構造化ログＬＧ３（メトリクスデータ１５０１～１５０４＋フォーマット化ログ１４０１）を、データベース２２０内のデータベースＬｖ２に格納する。

【0175】

ケース２では、ユーザリクエストによるアプリケーションの稼働が正常に開始され、一連の処理が終了したものの、何らかの要因で処理遅延が発生したケースである。ケース２では、データベース２２０に送出されるデータは、遅延箇所の分析に有用となるメトリクスデータ１５０１～１５０４とフォーマット化ログ１４０１とのセットとなる。ケース２では、後述するケース３に比べて、データベース２２０に送出されるデータ量は小さくなる。

【0176】

・ケース３：構造化ログのレベル判定例およびＤＢ格納例
つぎに、ケース３の構造化ログのレベル判定例およびＤＢ格納例について説明する。

【0177】

図１６は、アプリケーションの第３の動作例を示す説明図である。図１６において、ケース１と同様に、ユーザからのリクエストに対して処理するサービス＃１と、サービス＃１からリクエストされた動作を実行するサービス＃２、＃３とが示されている。サービス＃２，＃３には、情報が格納されているデータベースＤＢ＿２，ＤＢ＿３が接続されている。

【0178】

ケース３では、ユーザから“Ｐ８ ＳＥＴ”の在庫確認を受け付けた場合を想定する。ケース２では、サービス＃１により、“Ｐ８ ＳＥＴ”の在庫情報の確認するために、サービス＃３を呼び出している。各サービス＃１～＃３についてログ出力される情報（テレメトリーデータ）は、テレメトリーデータ１６００として一箇所（コントロールプレーンＣ）に収集される。

【0179】

つぎに、図１７Ａ～図１７Ｃを用いて、テレメトリーデータ１６００について説明する。

【0180】

図１７Ａ～図１７Ｃは、テレメトリーデータの第２のサンプル例を示す説明図である。図１７Ａ～図１７Ｃにおいて、テレメトリーデータ群１７００は、図１６に示したテレメトリーデータ１６００に含まれるテレメトリーデータ群の一例である。

【0181】

テレメトリーデータ群１７００は、”Ｐ８ ＳＥＴ”の在庫確認のリクエストに関する同一のリクエストＩＤ（１９６９０３１７－ｓ５８８８ｙ－１２３４８６）のテレメトリーデータ（ログ情報）を、時系列に並べたものである。コントロールプレーンＣは、テレメトリーデータ群１７００からフォーマット化ログを作成する。

【0182】

図１８Ａおよび図１８Ｂは、フォーマット化ログの第２の作成例を示す説明図である。図１８Ａにおいて、コントロールプレーンＣは、テレメトリーデータ群１７００から、”Ｐ８ ＳＥＴ”の在庫確認というユーザリクエストに対する一意のログフォーマットの形にするためのコンテキスト１８００を作成する。コンテキスト１８００は、フォーマット化ログの内容に対応する。

【0183】

まず、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＥＶＥＮＴ」のテレメトリーデータから、リクエストに応じた動作の起点となる処理の情報を抽出する。ここでは、（４Ａ）ｔｙｐｅ「ＥＶＥＮＴ」のｍｅｔｈｏｄより、“ｄｂ ｑｕｅｒｙ”の「ｇｅｔ ｃｏｎｔｅｎｔｓ ｍｅｔｈｏｄ（在庫確認）」のタイムスタンプとリクエストＩＤ「１９６９０３１７－ｓ５８８８ｙ－１２３４８６」が抽出される。

【0184】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＬＯＧ，ＴＲＡＣＥ」のテレメトリーデータから、リクエストに応じて動作したサービス＃ｉスの遷移を表す情報を抽出する。ここでは、（４Ｂ），（４Ｃ），（４Ｄ）テレメトリーデータ群１７００のｔｙｐｅ「ＬＯＧ」とｔｙｐｅ「ＴＲＡＣＥ」のテレメトリーデータから、動作したサービスの遷移を表す情報「ＳＥＲＶＩＣＥ１，ＳＥＲＶＩＣＥ３，ＳＥＲＶＩＣＥ１」が抽出される。

【0185】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、インプットされた情報を抽出する。ここでは、（４Ｅ）「Ｐ３ ＳＥＴ」が抽出される。つぎに、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、最後に遷移したサービス＃ｉの動作の情報を抽出する。ここでは、（４Ｆ）「０１８２３」の動作の情報が抽出される。

【0186】

つぎに、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＭＥＴＲＩＣ」のテレメトリーデータから、リクエストに応じた動作が終了したときの情報を抽出する。ここでは、（４Ｈ）動作の完了フラグのタイムスタンプおよびメトリックデータ（ｔｏｔａｌ ｄｕｒａｔｉｏｎ）が抽出される。

【0187】

また、コントロールプレーンＣは、テレメトリーデータ群１７００のＴｙｐｅ「ＬＯＧ」のテレメトリーデータから、その他の情報として、リクエストユーザのＩＤを抽出する。ここでは、（４Ｉ）「ｒｅｑｕｅｓｔ ｕｓｅｒ＿ｉｄ ７５２．２５４．２１１．３８」が抽出される。

【0188】

また、コントロールプレーンＣは、テレメトリーデータ群１７００から、エラー情報および警告情報を検索する。ここでは、（４Ｇ）テレメトリーデータ群１７００からエラー情報（ｌｅｖｅｌ「ＥＲＲＯＲ」）が検索され、エラー情報を含む全テレメトリーデータの情報（ここでは、ｍｅｔｈｏｄの内容）が抽出される。また、（４Ｈ）テレメトリーデータ群１７００から警告情報（ｌｅｖｅｌ「ＷＡＲＮ」）が検索され、警告情報を含むテレメトリーデータのステータスコード（ｓｔａｔｕｓ＿ｃｏｄｅ：ｔｉｍｅｏｖｅｒ）が抽出される。

【0189】

図１８Ｂにおいて、コントロールプレーンＣは、コンテキスト１８００から、フォーマット化ログ１８０１を作成する。コントロールプレーンＣは、テレメトリーデータ群１７００とフォーマット化ログ１８０１とをセットにして、構造化ログ（ここでは、「構造化ログＬＧ４」という）とする。

【0190】

つぎに、コントロールプレーンＣは、フォーマット化ログ１８０１を参照して、あらかじめ定義された査定方法に従って、構造化ログＬＧ４のレベルを判定する。ここでは、フォーマット化ログ１８０１にエラー情報が含まれる。また、”Ｐ８ ＳＥＴ”の在庫確認のユーザリクエストに対する処理は未完了であり、連結されたサービスに影響ある事象であるといえる。ユーザリクエストに対する処理の未完了は、例えば、ステータスコード「ｔｉｍｅｏｖｅｒ」から特定される。

【0191】

このため、コントロールプレーンＣは、構造化ログＬＧ４のレベルを「Ｌｖ３」と判定する。そして、コントロールプレーンＣは、判定したレベル「Ｌｖ３」をフォーマット化ログ１８０１に設定する（図１８Ｂ中、符号１８０２部分）。

【0192】

つぎに、図１９を用いて、構造化ログＬＧ４の格納例について説明する。

【0193】

図１９は、構造化ログの第４の格納例を示す説明図である。図１９において、コントロールプレーンＣは、構造化ログＬＧ４内のテレメトリーデータ群１７００のデータベース２２０への格納量を調整する。具体的には、例えば、コントロールプレーンＣは、フォーマット化ログ１８０１内のレベルに応じて、構造化ログＬＧ４に含まれるテレメトリーデータ群１７００を加工する。

【0194】

ここでは、フォーマット化ログ１８０１内のレベルが「Ｌｖ３」のため、コントロールプレーンＣは、構造化ログＬＧ３内のテレメトリーデータ群１７００を全て残す。そして、コントロールプレーンＣは、構造化ログＬＧ４（テレメトリーデータ群１７００＋フォーマット化ログ１８０１）を、データベース２２０内のデータベースＬｖ３に格納する。

【0195】

ケース３では、ユーザリクエストによるアプリケーションの稼働が障害により未完了として処理が終わったケースである。ケース３では、何らかの要因で処理未完了が発生したため、データベース２２０に送出されるデータは、障害個所の特定や分析に有用なテレメトリーデータ群１７００の全てとフォーマット化ログ１８０１とのセットとなる。

【0196】

（ログ管理サーバ２０１のログ管理処理手順）
つぎに、図２０および図２１を用いて、ログ管理サーバ２０１のログ管理処理手順について説明する。

【0197】

図２０および図２１は、ログ管理サーバ２０１のログ管理処理手順の一例を示すフローチャートである。図２０のフローチャートにおいて、まず、ログ管理サーバ２０１は、各サービス＃ｉからテレメトリーデータを収集する（ステップＳ２００１）。収集されたテレメトリーデータは、例えば、メモリ３０２上に設けられるバッファプールに一時的に格納される。

【0198】

つぎに、ログ管理サーバ２０１は、収集されたテレメトリーデータのうち、同一のリクエストＩＤを含むテレメトリーデータ群を取得する（ステップＳ２００２）。そして、ログ管理サーバ２０１は、取得したテレメトリーデータ群に対するフォーマット化処理を実行する（ステップＳ２００３）。

【0199】

フォーマット化処理は、テレメトリーデータ群について、フォーマット化されたログ情報（フォーマット化ログ）を作成する処理である。フォーマット化処理の具体的な処理手順については、図２２および図２３を用いて後述する。

【0200】

つぎに、ログ管理サーバ２０１は、フォーマット化ログとテレメトリーデータ群とをセットにした構造化ログを作成する（ステップＳ２００４）。そして、ログ管理サーバ２０１は、構造化ログ内のフォーマット化ログを参照して、エラー情報および警告情報がないかを判断する（ステップＳ２００５）。

【0201】

ここで、エラー情報および警告情報のいずれもない場合（ステップＳ２００５：Ｙｅｓ）、ログ管理サーバ２０１は、構造化ログのレベルを「Ｌｖ１」と判定して（ステップＳ２００６）、ステップＳ２０１０に移行する。

【0202】

一方、エラー情報および警告情報の少なくともいずれかがある場合（ステップＳ２００５：Ｎｏ）、ログ管理サーバ２０１は、トレース間に影響がある事象が発生しているか否かを判断する（ステップＳ２００７）。例えば、ログ管理サーバ２０１は、エラー情報がある場合、トレース間に影響がある事象が発生していると判断する。また、ログ管理サーバ２０１は、警告情報があるものの、エラー情報がない場合には、トレース間に影響がある事象が発生していないと判断する。

【0203】

ここで、トレース間に影響がある事象が発生していない場合（ステップＳ２００７：Ｎｏ）、ログ管理サーバ２０１は、構造化ログのレベルを「Ｌｖ２」と判定して（ステップＳ２００８）、ステップＳ２０１０に移行する。

【0204】

一方、トレース間に影響がある事象が発生している場合（ステップＳ２００７：Ｙｅｓ）、ログ管理サーバ２０１は、構造化ログのレベルを「Ｌｖ３」と判定する（ステップＳ２００９）。そして、ログ管理サーバ２０１は、判定したレベルを示すレベル情報を、構造化ログ内のフォーマット化ログに追加して（ステップＳ２０１０）、図２１に示すステップＳ２１０１に移行する。

【0205】

図２１のフローチャートにおいて、まず、ログ管理サーバ２０１は、構造化ログ内のフォーマット化ログを参照して、構造化ログのレベルが「Ｌｖ１」か否かを判断する（ステップＳ２１０１）。

【0206】

ここで、「Ｌｖ１」の場合（ステップＳ２１０１：Ｙｅｓ）、ログ管理サーバ２０１は、構造化ログからテレメトリーデータ群を削除して、構造化ログＬｖ１セットとする（ステップＳ２１０２）。そして、ログ管理サーバ２０１は、構造化ログＬｖ１セットをデータベース２２０内のデータベースＬｖ１に格納して（ステップＳ２１０３）、本フローチャートによる一連の処理を終了する。

【0207】

また、ステップＳ２１０１において、「Ｌｖ１」ではない場合（ステップＳ２１０１：Ｎｏ）、ログ管理サーバ２０１は、構造化ログ内のフォーマット化ログを参照して、構造化ログのレベルが「Ｌｖ２」か否かを判断する（ステップＳ２１０４）。

【0208】

ここで、「Ｌｖ２」の場合（ステップＳ２１０４：Ｙｅｓ）、ログ管理サーバ２０１は、構造化ログ内のテレメトリーデータ群のうちメトリクスデータ以外のテレメトリーデータを削除して、構造化ログＬｖ２セットとする（ステップＳ２１０５）。そして、ログ管理サーバ２０１は、構造化ログＬｖ２セットをデータベース２２０内のデータベースＬｖ２に格納して（ステップＳ２１０６）、本フローチャートによる一連の処理を終了する。

【0209】

また、ステップＳ２１０４において、「Ｌｖ２」ではない場合（ステップＳ２１０４：Ｎｏ）、ログ管理サーバ２０１は、構造化ログ全体を構造化ログＬｖ３セットとする（ステップＳ２１０７）。そして、ログ管理サーバ２０１は、構造化ログＬｖ３セットをデータベース２２０内のデータベースＬｖ３に格納して（ステップＳ２１０８）、本フローチャートによる一連の処理を終了する。

【0210】

これにより、ログ管理サーバ２０１は、各サービス＃ｉから収集されるテレメトリーデータのデータベース２２０への格納量を調整することができる。なお、ステップＳ２００３以降処理は、例えば、ステップＳ２００２において取得された同一のリクエストＩＤを含むテレメトリーデータ群ごとに実行される。

【0211】

つぎに、図２２および図２３を用いて、ステップＳ２００３のフォーマット化処理の具体的な処理手順について説明する。

【0212】

図２２および図２３は、フォーマット化処理の具体的処理手順の一例を示すフローチャートである。図２２のフローチャートにおいて、まず、ログ管理サーバ２０１は、テレメトリーデータ群のうちのイベントデータから動作の起点情報を抽出する（ステップＳ２２０１）。

【0213】

イベントデータは、ｔｙｐｅ「ＥＶＥＮＴ」のテレメトリーデータである。動作の起点情報は、例えば、リクエストＩＤ、動作の起点となるイベントのタイムスタンプ、メッセージ、メソッドなどを含む。そして、ログ管理サーバ２０１は、動作の起点情報をコンテキストに追加する（ステップＳ２２０２）。

【0214】

つぎに、ログ管理サーバ２０１は、テレメトリーデータ群のうちのログ／トレースデータから動作遷移情報を抽出する（ステップＳ２２０３）。ログ／トレースデータは、ｔｙｐｅ「ＬＯＧ」のテレメトリーデータと、ｔｙｐｅ「ＴＲＡＣＥ」のテレメトリーデータとである。動作遷移情報は、起点となるイベントに応じて動作したマイクロサービスの遷移を表す情報である。

【0215】

そして、ログ管理サーバ２０１は、動作遷移情報をコンテキストに追加する（ステップＳ２２０４）。つぎに、ログ管理サーバ２０１は、テレメトリーデータ群からエラー情報を検索する（ステップＳ２２０５）。例えば、ログ管理サーバ２０１は、ｌｅｖｅｌ「ＥＲＲＯＲ」のログデータを検索する。

【0216】

そして、ログ管理サーバ２０１は、エラー情報が検索されたか否かを判断する（ステップＳ２２０６）。ここで、エラー情報が検索されなかった場合（ステップＳ２２０６：Ｎｏ）、ログ管理サーバ２０１は、ステップＳ２２０８に移行する。

【0217】

一方、エラー情報が検索された場合（ステップＳ２２０６：Ｙｅｓ）、ログ管理サーバ２０１は、検索されたエラー情報をコンテキストに追加する（ステップＳ２２０７）。つぎに、ログ管理サーバ２０１は、テレメトリーデータ群から警告情報を検索する（ステップＳ２２０８）。例えば、ログ管理サーバ２０１は、ｌｅｖｅｌ「ＷＡＲＮ」のメトリクスデータを検索する。メトリクスデータは、ｔｙｐｅ「ＭＥＴＲＩＣ」のテレメトリーデータとである。

【0218】

そして、ログ管理サーバ２０１は、警告情報が検索されたか否かを判断する（ステップＳ２２０９）。ここで、警告情報が検索されなかった場合（ステップＳ２２０９：Ｎｏ）、ログ管理サーバ２０１は、図２３に示すステップＳ２３０１に移行する。一方、警告情報が検索された場合（ステップＳ２２０９：Ｙｅｓ）、ログ管理サーバ２０１は、検索された警告情報をコンテキストに追加して（ステップＳ２２１０）、図２３に示すステップＳ２３０１に移行する。

【0219】

図２３のフローチャートにおいて、まず、ログ管理サーバ２０１は、テレメトリーデータ群から、リクエストＩＤに紐付いたインプット情報を抽出する（ステップＳ２３０１）。インプット情報は、例えば、「ｉｎｐｕｔ」という文字列から特定される。そして、ログ管理サーバ２０１は、インプット情報をコンテキストに追加する（ステップＳ２３０２）。

【0220】

つぎに、ログ管理サーバ２０１は、テレメトリーデータ群から、リクエストＩＤに紐付いた最後の動作情報を抽出する（ステップＳ２３０３）。最後の動作情報は、最後に遷移したマイクロサービスの動作の情報である。そして、ログ管理サーバ２０１は、最後の動作情報をコンテキストに追加する（ステップＳ２３０４）。

【0221】

つぎに、ログ管理サーバ２０１は、テレメトリーデータ群から、一連の処理にかかる動作が終了したときのメトリクス情報を抽出する（ステップＳ２３０５）。メトリクス情報は、例えば、一連の処理にかかる動作が終了したときのタイムスタンプ、完了フラグ、メトリクス（数値データ）、ステータスコードなどを含む。そして、ログ管理サーバ２０１は、メトリクス情報をコンテキストに追加する（ステップＳ２３０６）。

【0222】

つぎに、ログ管理サーバ２０１は、テレメトリーデータ群から、その他の情報を抽出する（ステップＳ２３０７）。その他の情報は、例えば、サーバとクライアントのＩＰ（ Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）アドレスや、ユーザＩＤなどである。ログ管理サーバ２０１は、その他の情報をコンテキストに追加する（ステップＳ２３０８）。

【0223】

そして、ログ管理サーバ２０１は、コンテキストを参照して、テレメトリーデータ群についてのフォーマット化ログを生成して（ステップＳ２３０９）、フォーマット化処理を呼び出したステップに戻る。

【0224】

これにより、ログ管理サーバ２０１は、リクエストＩＤが同一のテレメトリーデータ間で一意の情報であるフォーマット化ログを生成することができる。

【0225】

以上説明したように、実施の形態にかかるログ管理サーバ２０１によれば、サービス＃１～＃ｍの各サービス＃ｉから収集されたテレメトリーデータのうち、同一のリクエストＩＤを含むテレメトリーデータ群を取得することができる。テレメトリーデータは、各サービス＃ｉにおいて実行された処理に関する観測情報である。また、ログ管理サーバ２０１によれば、取得したテレメトリーデータ群から、エラー情報および警告情報を検索することができる。エラー情報は、エラーの発生を示す。警告情報は、エラーの要因となり得る事象の発生を示す。そして、ログ管理サーバ２０１によれば、検索した検索結果に応じて、テレメトリーデータ群のうちの一部または全部の情報を格納先となるデータベース２２０に格納することができる。

【0226】

これにより、ログ管理サーバ２０１は、テレメトリーデータの格納先となるデータベース２２０への格納量を調整することができる。例えば、ログ管理サーバ２０１は、同一のリクエストＩＤに紐付いたテレメトリーデータ群単位で、エラー情報や警告情報が含まれるのかどうかによって、テレメトリーデータ群のうちの一部の情報のみを格納するのか、全部の情報を格納するのかを調整することができる。このため、ログ管理サーバ２０１は、アプリケーションの性能評価などに必要となる情報を残しつつ、データベース２２０におけるテレメトリーデータの保管に使用する記憶容量を削減することができる。

【0227】

また、ログ管理サーバ２０１によれば、異なるデータ種のテレメトリーデータを含むテレメトリーデータ群それぞれのデータ種を参照して、テレメトリーデータ群から、あらかじめ決められた一部の情報を抽出することにより、抽出した一部の情報を含むフォーマット化ログ（フォーマット化されたログ情報）を作成することができる。データ種は、例えば、イベント、メトリクス、ログおよびトレースである。そして、ログ管理サーバ２０１によれば、テレメトリーデータ群からエラー情報および警告情報が検索されなかった場合、テレメトリーデータ群について、作成したフォーマット化ログのみをデータベース２２０（例えば、データベースＬｖ１）に格納することができる。

【0228】

これにより、ログ管理サーバ２０１は、システムが正常に稼働して一連の処理が完了したときのテレメトリーデータ群については、リクエストに対して実行された処理を特定するために、分析者にとって必要最低限の情報（あらかじめ決められた一部の情報）のみを格納対象とすることで、データベース２２０の格納量を抑えることができる。

【0229】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群から、エラー情報が検索されず、かつ、警告情報が検索された場合には、テレメトリーデータ群から警告情報を含むテレメトリーデータと同一のデータ種のテレメトリーデータを特定することができる。そして、ログ管理サーバ２０１によれば、テレメトリーデータ群について、フォーマット化ログとともに、特定したテレメトリーデータをデータベース２２０（例えば、データベースＬｖ２）に格納することができる。

【0230】

これにより、ログ管理サーバ２０１は、一連の処理の中でエラーは発生していないものの、エラーの要因となり得る事象が発生したときのテレメトリーデータ群については、その事象の分析に必要となる情報を格納対象とすることで、データベース２２０の格納量を抑えることができる。また、ログ管理サーバ２０１は、フォーマット化ログを合わせて格納することで、リクエストに対して実行された処理の特定を容易にすることができる。

【0231】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群から、エラー情報が検索された場合、フォーマット化ログとともに、テレメトリーデータ群をデータベース２２０（例えば、データベースＬｖ３）に格納することができる。

【0232】

これにより、ログ管理サーバ２０１は、何らかのエラーが発生してシステムが正常に稼働しなかったときのテレメトリーデータ群については、テレメトリーデータ群の全てを格納対象とすることができる。このため、ログ管理サーバ２０１は、重大な障害の発生時などは、障害箇所の特定や原因の究明に用いる情報が不足するといった事態を回避することができる。また、ログ管理サーバ２０１は、フォーマット化ログを合わせて格納することで、リクエストに対して実行された処理の特定を容易にすることができる。

【0233】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群のうちのイベントのテレメトリーデータから、リクエストに応じた動作の起点となる処理の情報およびリクエストＩＤを抽出して、フォーマット化ログを作成することができる。

【0234】

これにより、ログ管理サーバ２０１は、リクエストＩＤやイベントの情報からリクエストに応じて実行された処理を特定可能にすることができる。

【0235】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群のうちのログおよびトレースのテレメトリーデータから、リクエストに応じて動作したマイクロサービスの遷移を表す情報を抽出して、フォーマット化ログを作成することができる。

【0236】

これにより、ログ管理サーバ２０１は、リクエストに応じて動作したマイクロサービスを特定可能にすることができる。

【0237】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群のうちのログのテレメトリーデータから、さらに、最後に遷移したマイクロサービスの動作の情報を抽出して、フォーマット化ログを作成することができる。

【0238】

これにより、ログ管理サーバ２０１は、リクエストに応じて実行された処理の特定にあたり、最後に遷移したマイクロサービスの動作の内容を確認可能にすることができる。

【0239】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群のうちのメトリクスのテレメトリーデータから、さらに、リクエストに応じた動作が終了したときのメトリクスデータを抽出して、フォーマット化ログを作成することができる。

【0240】

これにより、ログ管理サーバ２０１は、リクエストに応じて実行された処理の特定にあたり、リクエストに対する動作が終了したときのメトリクスデータを確認可能にすることができる。

【0241】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群のうちのメトリクスのテレメトリーデータから、さらに、リクエストに応じた動作が終了したときのステータスコードを抽出して、フォーマット化ログを作成することができる。

【0242】

これにより、ログ管理サーバ２０１は、リクエストに応じて実行された処理の特定にあたり、リクエストに対する動作が終了したときのステータスコードを確認可能にすることができる。

【0243】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群から警告情報が検索された場合、フォーマット化ログに警告情報を追加することができる。

【0244】

これにより、ログ管理サーバ２０１は、フォーマット化ログとともに格納されたテレメトリーデータの内容を確認しなくても、フォーマット化ログから、どのような事象（エラーの要因となり得る事象）が発生したのかを容易に確認可能にすることができる。

【0245】

また、ログ管理サーバ２０１によれば、テレメトリーデータ群からエラー情報が検索された場合、フォーマット化ログにエラー情報を追加することができる。

【0246】

これにより、ログ管理サーバ２０１は、フォーマット化ログとともに格納されたテレメトリーデータの内容を確認しなくても、フォーマット化ログから、どのようなエラーが発生したのかを容易に確認可能にすることができる。

【0247】

これらのことから、ログ管理サーバ２０１によれば、複数のマイクロサービスにより構成されるアプリケーション（システム）の処理が、正常な処理なのか、障害や異常が発生した処理なのかを構造化したログから分析することができる。これにより、ログ管理サーバ２０１は、アプリケーションの処理の正常性を監視するために収集されるテレメトリーデータの中で、より有用なデータのみを格納することによって、テレメトリーデータの保管に使用する記憶容量を削減して、確保すべき記憶領域を削減することができる。

【0248】

また、ログ管理サーバ２０１は、クラウド上でデータベース２２０を構築する場合などに、格納データのデータ転送量やメモリ使用量を抑えることができるため、従来のように全データを格納する場合に比べて、課金量を低減して運用コストを削減することができる。また、ログ管理サーバ２０１は、データベース２２０における格納データの格納先となる記憶領域をレベル（Ｌｖ１，Ｌｖ２，Ｌｖ３）によって使い分けることができる。このため、ログ管理サーバ２０１は、格納データの削除や外部転送を実装するにあたり、容易にデータを呼び出して削除や転送を行うことを可能にする。

【0249】

なお、本実施の形態で説明したログ管理方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本ログ管理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本ログ管理プログラムは、インターネット等のネットワークを介して配布してもよい。

【0250】

また、本実施の形態で説明したログ管理装置１０１（ログ管理サーバ２０１）は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。

【0251】

上述した実施の形態に関し、さらに以下の付記を開示する。

【0252】

（付記１）複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群のうちの一部または全部の情報を格納先となるデータベースに格納する、
制御部を有することを特徴とするログ管理装置。

【0253】

（付記２）前記観測情報群は、異なるデータ種の観測情報を含み、
前記制御部は、
前記観測情報群それぞれのデータ種を参照して、前記観測情報群から、あらかじめ決められた一部の情報を抽出することにより、抽出した前記一部の情報を含む、フォーマット化されたログ情報を作成し、
前記観測情報群から前記エラー情報および前記警告情報が検索されなかった場合、前記観測情報群について、作成した前記フォーマット化されたログ情報のみを前記データベースに格納する、
ことを特徴とする付記１に記載のログ管理装置。

【0254】

（付記３）前記制御部は、
前記観測情報群から、前記エラー情報が検索されず、かつ、前記警告情報が検索された場合には、前記観測情報群から前記警告情報を含む観測情報と同一のデータ種の観測情報を特定し、
前記観測情報群について、前記フォーマット化されたログ情報とともに、特定した前記観測情報を前記データベースに格納する、
ことを特徴とする付記２に記載のログ管理装置。

【0255】

（付記４）前記制御部は、
前記観測情報群から前記エラー情報が検索された場合、前記フォーマット化されたログ情報とともに、前記観測情報群を前記データベースに格納する、
ことを特徴とする付記２または３に記載のログ管理装置。

【0256】

（付記５）前記観測情報群は、イベント、メトリクス、ログおよびトレースの少なくともいずれかのデータ種の観測情報を含み、
前記一部の情報は、前記観測情報群のうちのイベントの観測情報から抽出される、前記リクエストに応じた動作の起点となる処理の情報および前記リクエストＩＤを含む、
ことを特徴とする付記２～４のいずれか一つに記載のログ管理装置。

【0257】

（付記６）前記一部の情報は、前記観測情報群のうちのログおよびトレースの観測情報から抽出される、前記リクエストに応じて動作したマイクロサービスの遷移を表す情報を含む、
ことを特徴とする付記５に記載のログ管理装置。

【0258】

（付記７）前記一部の情報は、前記観測情報群のうちのログの観測情報から抽出される、最後に遷移したマイクロサービスの動作の情報を含む、ことを特徴とする付記６に記載のログ管理装置。

【0259】

（付記８）前記一部の情報は、前記観測情報群のうちのメトリクスの観測情報から抽出される、前記リクエストに応じた動作が終了したときのメトリクスデータを含む、ことを特徴とする付記６または７に記載のログ管理装置。

【0260】

（付記９）前記一部の情報は、前記観測情報群のうちのメトリクスの観測情報から抽出される、前記リクエストに応じた動作が終了したときのステータスコードを含む、ことを特徴とする付記６～８のいずれか一つに記載のログ管理装置。

【0261】

（付記１０）前記制御部は、
前記観測情報群から前記警告情報が検索された場合、前記フォーマット化されたログ情報に前記警告情報を追加する、
ことを特徴とする付記３に記載のログ管理装置。

【0262】

（付記１１）前記制御部は、
前記観測情報群から前記エラー情報が検索された場合、前記フォーマット化されたログ情報に前記エラー情報を追加する、
ことを特徴とする付記４に記載のログ管理装置。

【0263】

（付記１２）前記制御部は、
前記観測情報群について、前記フォーマット化されたログ情報のみを前記データベース内の第１の記憶領域に格納する、ことを特徴とする付記２に記載のログ管理装置。

【0264】

（付記１３）前記制御部は、
前記観測情報群について、前記フォーマット化されたログ情報とともに、特定した前記観測情報を前記データベース内の第２の記憶領域に格納する、ことを特徴とする付記３に記載のログ管理装置。

【0265】

（付記１４）前記制御部は、
前記フォーマット化されたログ情報とともに、前記観測情報群を前記データベース内の第３の記憶領域に格納する、ことを特徴とする付記４に記載のログ管理装置。

【0266】

（付記１５）複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する複数のデータ種の観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群の格納先となるデータベースへの格納量を調整する、
処理をコンピュータが実行することを特徴とするログ管理方法。

【0267】

（付記１６）複数のマイクロサービスの各マイクロサービスから収集された、前記各マイクロサービスにおいて実行された処理に関する複数のデータ種の観測情報のうち、リクエストに応じて実行される一連の処理を識別する同一のリクエストＩＤを含む観測情報群を取得し、
取得した前記観測情報群から、エラーの発生を示すエラー情報、および、エラーの要因となり得る事象の発生を示す警告情報を検索し、
検索した検索結果に応じて、前記観測情報群の格納先となるデータベースへの格納量を調整する、
処理をコンピュータに実行させることを特徴とするログ管理プログラム。

【符号の説明】

【0268】

１０１ ログ管理装置
１１０，２２０ データベース
１２０ 観測情報集合
１２１～１２３ 観測情報群
１３０ 一部の情報
２００ 情報処理システム
２０１ ログ管理サーバ
２１０ ネットワーク
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
４００ 制御部
４０１ 収集部
４０２ ログ構造化部
４０３ 判定部
４０４ 調整部
５０１，５０２，５０３，６００，１２００，１６００ テレメトリーデータ
５６２，７１０，７２０，１３００，１７００ テレメトリーデータ群
５１１，５２１，５３１，５５２，１５０１，１５０２，１５０３，１５０４ メトリクスデータ
５１２，５２２，５３２ ログ
５４１，５５１，５６１，８０１，１００１，１４０１，１８０１ フォーマット化ログ
８００，１０００，１４００，１８００ コンテキスト

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図7E】

【図7F】

【図8A】

【図8B】

【図9】

【図10A】

【図10B】

【図11】

【図12】

【図13A】

【図13B】

【図13C】

【図14A】

【図14B】

【図15】

【図16】

【図17A】

【図17B】

【図17C】

【図18A】

【図18B】

【図19】

【図20】

【図21】

【図22】

【図23】