特許 6040894 ログ生成装置、及びログ生成方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6040894

(24)【登録日】2016年11月18日

(45)【発行日】2016年12月7日

(54)【発明の名称】ログ生成装置、及びログ生成方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20161128BHJP

   G06F 9/46 20060101ALI20161128BHJP

【ＦＩ】

   G06F11/34 176

   G06F9/46 350

【請求項の数】7

【全頁数】14

(21)【出願番号】特願2013-180873(P2013-180873)

(22)【出願日】2013年9月2日

(65)【公開番号】特開2015-49705(P2015-49705A)

(43)【公開日】2015年3月16日

【審査請求日】2015年12月16日

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】100112210

【弁理士】

【氏名又は名称】稲葉 忠彦

(74)【代理人】

【識別番号】100108431

【弁理士】

【氏名又は名称】村上 加奈子

(74)【代理人】

【識別番号】100153176

【弁理士】

【氏名又は名称】松井 重明

(74)【代理人】

【識別番号】100109612

【弁理士】

【氏名又は名称】倉谷 泰孝

(72)【発明者】

【氏名】井邊 研吾

【審査官】 多賀 実

(56)【参考文献】

【文献】 国際公開第２００１／０２０４５６（ＷＯ，Ａ１）

【文献】 特開２００６−０１８７０１（ＪＰ，Ａ）

【文献】 特開２００６−２８５８７５（ＪＰ，Ａ）

【文献】 特開２００９−０４２８１５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ９／４６

Ｇ０６Ｆ１１／３０−１１／３４

(57)【特許請求の範囲】

【請求項1】

ゲストＯＳのログを一意に識別する識別子を生成する識別子生成部と、
前記識別子生成部により生成された前記識別子をゲストＯＳのログと対応付けてゲストＯＳログに記録するゲストＯＳログ生成部と、
前記識別子生成部により生成された前記識別子を通知する識別子通知部と、
前記識別子通知部により通知された前記識別子をホストＯＳログに記録するホストＯＳログ生成部と、
前記ホストＯＳログ生成部により前記ホストＯＳログに記録された前記識別子に対応するログを前記ゲストＯＳログ生成部により記録された前記ゲストＯＳログから抽出して前記識別子と置換するマージ部と
を備えたログ生成装置。

【請求項2】

前記識別子生成部は、ゲストＯＳでイベントが発生する毎に前記識別子を生成する請求項１記載のログ生成装置。

【請求項3】

前記識別子生成部は、一定周期毎に前記識別子を生成する請求項１記載のログ生成装置。

【請求項4】

ゲストＯＳでイベントが発生する毎に第１の識別子を生成する第１の識別子生成部と、
一定周期毎に第２の識別子を生成する第２の識別子生成部と、
前記イベントの発生頻度に応じて、前記第１の識別子または前記第２の識別子のどちらを通知するかを決定する識別子調停部と
を備えた請求項１記載のログ生成装置。

【請求項5】

ゲストＯＳでイベントが発生する毎に第１の識別子を生成する第１の識別子生成部と、
一定周期毎に第２の識別子を生成する第２の識別子生成部と、
前記イベントの種類に応じて、前記第１の識別子または前記第２の識別子のどちらを通知するかを決定する識別子調停部と
を備えた請求項１記載のログ生成装置。

【請求項6】

複数のゲストＯＳを備え、
前記識別子生成部は、前記複数のゲストＯＳのログを一意に識別する識別子を生成する請求項１記載のログ生成装置。

【請求項7】

識別子生成部によりゲストＯＳのログを一意に識別する識別子を生成する識別子生成ステップと、
ゲストＯＳログ生成部により前記識別子生成ステップにより生成された前記識別子をゲストＯＳのログと対応付けてゲストＯＳログに記録するゲストＯＳログ生成ステップと、
識別子通知部により前記識別子生成ステップにより生成された前記識別子を通知する識別子通知ステップと、
ホストＯＳログ生成部により前記識別子通知ステップにより通知された前記識別子をホストＯＳログに記録するホストＯＳログ生成ステップと、
マージ部により前記ホストＯＳログ生成ステップにより前記ホストＯＳログに記録された前記識別子に対応するログを前記ゲストＯＳログ生成ステップにより記録された前記ゲストＯＳログから抽出して前記識別子と置換するマージステップと
を備えたログ生成方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークシステムやプログラムの処理中に発生したイベントを、ログとして生成するログ生成装置に関するものである。

【背景技術】

【0002】

ネットワークシステムやプログラムのイベントトレース等において、処理中に発生したイベントをログとして生成・取得することは、処理状況の確認や障害解析等のために一般的に利用されている。ログは、複数の計算機の環境上で個別の時間管理のもと生成される場合もあり、処理状況の確認や障害解析等のために複数の環境で発生したイベントの関係性を把握する必要がある。この場合、複数の環境で生成されたログを、イベントの発生順を維持しつつ、一つのログにまとめる必要がある。しかし、複数の環境で計測される時刻は、個々の環境毎に異なっていることから、単純に時刻をもとにログをまとめたとしても、実際に発生したイベント順にログが並んでいないという課題がある。

【0003】

上記の課題に対して、イベント発生順にログをまとめる方法が開示されており、例えば、特許文献１、特許文献２では、同期する処理により、複数の環境で生成されたログの時刻を補正し、補正した時刻をもとにログをまとめている。また、特許文献３では、複数の環境で生成されたログに対して、全ての環境で統一したシーケンス番号を割り当て、このシーケンス番号をもとにログを並べ替え、ログをまとめている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１１−１５４４８９号公報

【特許文献2】特開２０１２−２１６０４０号公報

【特許文献3】特開２００６−１８７０１号公報

【発明の概要】

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

【0005】

従来のログ生成装置は、複数の環境で生成されたログをまとめる際に、特許文献１、特許文献２では、異なる環境で生成したログを転送する必要があった。また、転送したログの時刻補正をする必要があった。このため、ログの発生間隔が短くなるとログの転送の負荷が大きく、また、時刻補正の精度の問題から、イベントのログが発生順に並ばないという課題があった。特許文献３では、ログのソートなどの処理が必要であり、ソートするデータ数が多くなると負荷が大きくなるという課題があった。

【0006】

本発明は、上記のような課題を解決するためになされたもので、複数の環境で生成されたログをまとめる処理の負荷を抑えつつ、イベントのログを発生順に並べることを目的とする。

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

【0007】

上記で述べた課題を解決するため、本発明のログ生成装置は、ゲストＯＳのログを一意に識別する識別子を生成する識別子生成部と、前記識別子生成部により生成された前記識別子をゲストＯＳのログと対応付けてゲストＯＳログに記録するゲストＯＳログ生成部と、前記識別子生成部により生成された前記識別子を通知する識別子通知部と、前記識別子通知部により通知された前記識別子をホストＯＳログに記録するホストＯＳログ生成部と、前記ホストＯＳログ生成部により前記ホストＯＳログに記録された前記識別子に対応するログを前記ゲストＯＳログ生成部により記録された前記ゲストＯＳログから抽出して前記識別子と置換するマージ部とを備えることとしたものである。

【0008】

また、本発明のログ生成方法は、識別子生成部によりゲストＯＳのログを一意に識別する識別子を生成する識別子生成ステップと、ゲストＯＳログ生成部により前記識別子生成ステップにより生成された前記識別子をゲストＯＳのログと対応付けてゲストＯＳログに記録するゲストＯＳログ生成ステップと、識別子通知部により前記識別子生成ステップにより生成された前記識別子を通知する識別子通知ステップと、ホストＯＳログ生成部により前記識別子通知ステップにより通知された前記識別子をホストＯＳログに記録するホストＯＳログ生成ステップと、マージ部により前記ホストＯＳログ生成ステップにより前記ホストＯＳログに記録された前記識別子に対応するログを前記ゲストＯＳログ生成ステップにより記録された前記ゲストＯＳログから抽出して前記識別子と置換するマージステップとを備えることとしたものである。

【発明の効果】

【0009】

本発明によれば、マージ部で、ホストＯＳログに記録された識別子をもとに、ゲストＯＳログを参照するのみで、イベントのログを発生順に並べて、まとめ上げることができる。これにより、ログのデータの転送の負荷を軽減して、ログをまとめ上げる際にもソートなどの処理が不要になり、複数の環境で生成されたログをまとめる処理の負荷を抑えつつ、イベントのログを発生順に並べることができるようになるという効果がある。

【図面の簡単な説明】

【0010】

【図1】実施の形態１に係るログ生成装置の一実施例を示す情報処理装置の構成図である。

【図2】実施の形態１に係るログ生成装置の一構成例を示す図である。

【図3】ゲストＯＳログ１２、ホストＯＳログ１３、マージログ１４の一例を示す図である。

【図4】実施の形態１におけるゲストＯＳ３側の処理の流れを示すフローチャートである。

【図5】実施の形態１におけるホストＯＳ２側の処理の流れを示すフローチャートである。

【図6】実施の形態２に係るログ生成装置の一構成例を示す図である。

【図7】実施の形態２におけるゲストＯＳ３側の処理の流れを示すフローチャートである。

【図8】実施の形態３に係るログ生成装置の一構成例を示す図である。

【図9】実施の形態３におけるゲストＯＳ３側の処理の流れを示すフローチャートである。

【図10】実施の形態４に係るログ生成装置の一実施例を示す情報処理装置の構成図である。

【図11】実施の形態４に係るログ生成装置の一構成例を示す図である。

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

【0011】

実施の形態１．
図１は、実施の形態１に係るログ生成装置の一実施例を示す情報処理装置の構成図である。
図１において、情報処理装置は、計算機１上でホストＯＳ２が動作し、ゲストＯＳ３、仮想マシンモニタ（ＶＭＭ： Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）４、ホストＯＳログ生成部５がホストＯＳ２上で動作し、ゲストＯＳログ生成部７がゲストＯＳ３上で動作する構成とする。また、仮想マシンモニタ（ＶＭＭ）４は、ホストＯＳ２上で動作するイベント生成部８を備え、さらに、ホストＯＳ２には、マージ部６を備えている。

【0012】

ホストＯＳ２は、計算機上に別の計算機環境を構築する仮想マシンにおいて、仮想マシンのプログラムを動作させている基盤となるＯＳである。また、ゲストＯＳ３は、ホストＯＳ２上で動作している仮想マシンのＯＳである。ゲストＯＳ３は、仮想マシンを実現するソフトウェアである仮想マシンモニタ（ＶＭＭ）４により動作している。ホストＯＳ２、ゲストＯＳ３共に、実行経路や各処理のイベントを追跡してログを生成するホストＯＳログ生成部５, ゲストＯＳログ生成部７を備えている。なお、ここで言うイベントは、ホストＯＳ２、ゲストＯＳ３で発生した処理を示しており、ホストＯＳログ生成部５、ゲストＯＳログ生成部７によって出力する。また、ホストＯＳログ生成部２, ゲストＯＳログ生成部７は、各ＯＳで発生した処理についてのみ追跡することができる。つまり、ホストＯＳ２上のホストＯＳログ生成部５により、ゲストＯＳ３内で発生した処理について追跡することができない。

【0013】

図２は、実施の形態１に係るログ生成装置の一構成例を示す図である。
図２において、ゲストＯＳログ生成部７は、発生したログに対して識別子を生成して付与する識別子生成部１０と、仮想マシンモニタ（ＶＭＭ）４に識別子を通知するための識別子通知部１１を備えている。また、ゲストＯＳログ生成部７は、識別子が付与されたログをゲストＯＳログ１２に記録する。

【0014】

仮想マシンモニタ（ＶＭＭ）４は、イベント生成部８を備えており、ゲストＯＳログ生成部７の識別子通知部１１により識別子の通知を受けた際、イベント生成部８を用いて、ホストＯＳログ生成部５に、識別子付きのイベント通知を行なう。

【0015】

ホストＯＳログ生成部５は、ホストＯＳ２上で発生するイベントを、ホストＯＳログ１３に記録する。また、ホストＯＳログ生成部５は、仮想マシンモニタ（ＶＭＭ）４のイベント生成部８からの識別子付きイベント通知をもとに、識別子を埋め込んだログを、ホストＯＳログ１３に記録する。

【0016】

マージ部６は、ホストＯＳログ１３に埋め込まれた識別子に対応するログを、ゲストＯＳログ１２から抽出し、ホストＯＳログ１３に埋め込まれた識別子を、ゲストＯＳログ１２から抽出したログに置換し、ゲストＯＳ３とホストＯＳ２のログがマージされたマージログ１４を生成する。

【0017】

図３は、ゲストＯＳログ１２、ホストＯＳログ１３、マージログ１４の一例を示す図である。
図３において、ゲストＯＳログ１２は、各イベントを一意に識別するための識別子と、イベントが発生した時刻、及びイベントの情報が記録されている。なお、本例では、識別子として、イベント発生毎に数字をインクリメントするようなシーケンス番号の数字を用いているが、一意に識別できるものであれば何でもよく、例えば、識別子に文字列を用いてもよい。ただし、この識別子は、ゲストＯＳ３からホストＯＳ２へ通知を行なうため、識別子の長さが短く、データ量が少ないことが望ましい。また、ホストＯＳログ１３には、イベントが発生した時刻と、イベント、または仮想マシンモニタ（ＶＭＭ）４のイベント生成部８から通知された識別子が記録されている。これらのゲストＯＳログ１２とホストＯＳログ１３がマージされて、マージログが生成される。

【0018】

次に、実施の形態１におけるログ生成装置の動作について、図４、図５を参照して説明する。
図４は、実施の形態１におけるゲストＯＳ３側の処理の流れを示すフローチャートである。
図５は、実施の形態１におけるホストＯＳ２側の処理の流れを示すフローチャートである。

【0019】

以下、図４を用いて、ゲストＯＳ３側の処理の流れを説明する。
まず、ステップＳ１０１において、ゲストＯＳログ生成部７は、ログ生成の準備をする。ログ生成の準備では、ログの取得条件の設定を行なう。例えば、ログの取得対象として、どのＣＰＵコアを指定するか、あるいは、ログを取得する処理単位として、イベント単位とするか、関数単位とするかなどを設定する。さらにオプション機能として、関数呼び出し関係をトレースできる表示形式で出力するように指定することもできる。
次に、ステップＳ１０２において、ゲストＯＳログ生成部７は、ログを発生するイベントが来るまで待機し、ログを発生するイベントが発生したときに、Ｓ１０３の分岐に進む。
次に、ステップＳ１０３において、ゲストＯＳログ生成部７は、識別子生成部１０により、発生したログに対して識別子を付与するとともに、その識別子を、ホストＯＳ２上で動作する仮想マシンモニタ（ＶＭＭ）４に通知する。
次に、ステップＳ１０４において、ゲストＯＳログ生成部７は、識別子が付与されたログをゲストＯＳログ１２に出力する。ゲストＯＳログ１２への出力書式例は、図３に示す通りである。
次に、ステップＳ１０５において、ゲストＯＳログ生成部７は、ログの生成の終了条件を満たすまで、ステップＳ１０２からステップＳ１０５までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。

【0020】

次に、図５を用いて、ホストＯＳ２側の処理の流れを説明する。
まず、ステップＳ２０１において、ホストＯＳログ生成部５は、ログ生成の準備をする。ログ生成の準備は、ゲストＯＳ３側のステップＳ１０１の処理と同様に、ログの取得条件の設定を行なう。
次に、ステップＳ２０２において、ホストＯＳログ生成部５は、ログを発生するイベントか、仮想マシンモニタ（ＶＭＭ）４からの識別子付きイベント通知が発生するまで待機する。仮想マシンモニタ（ＶＭＭ）４からの識別子付きイベント通知の処理は、ゲストＯＳログ生成部７から仮想マシンモニタ（ＶＭＭ）４に識別子が通知されると、仮想マシンモニタ（ＶＭＭ）４のイベント生成部８により識別子付きイベントが生成され、ホストＯＳログ生成部５に通知される。ホストＯＳログ生成部５は、上記のように待機し、ログを発生するイベントが発生した場合、ステップＳ２０３の分岐に進み、識別子付きイベント通知が発生した場合、ステップＳ２０４の分岐に進む。
次に、ステップＳ２０２でログを発生するイベントが発生した場合、ステップＳ２０３において、ホストＯＳログ生成部５は、発生したログをホストＯＳログ１３に出力する。ホストＯＳログ１３への出力書式例は、図３に示す通りである。
一方、ステップＳ２０２で識別子付きイベント通知が発生した場合は、ステップＳ２０４において、ホストＯＳログ生成部５は、識別子をホストＯＳログ１３に出力する。識別子は、重複なく一意に識別可能なものであればよく、例えばイベント発生毎に数字をインクリメントするようなシーケンス番号でもよい。
次に、ステップＳ２０５において、ホストＯＳログ生成部５は、ログの生成の終了条件を満たすまで、ステップＳ２０２からステップＳ２０５までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。
次に、ステップＳ２０６において、マージ部６は、ゲストＯＳ３のゲストＯＳログ１２と、ホストＯＳ２のホストＯＳログ１３を収集する。
最後に、ステップＳ２０６において、マージ部６は、
ホストＯＳログ１３に挿入されている識別子に対応するログを、ホストＯＳログ１３に埋め込まれた識別子に対応するログを、ゲストＯＳログ１２から抽出し、ホストＯＳログ１３に埋め込まれた識別子を、ゲストＯＳログ１２から抽出したログに置換し、ゲストＯＳ３とホストＯＳ２のログがマージされたマージログ１４を生成する。

【0021】

以上のように、本実施の形態１の発明は、ゲストＯＳログ生成部７が識別子生成部１０と識別子通知部１１を備え、識別子通知部１１によって、ゲストＯＳログ１２が生成されたタイミングで、識別子が、仮想マシンモニタ（ＶＭＭ）４を経由して、ホストＯＳログ生成部５に通知され、ホストＯＳログ１３と共に記録されることにより、マージ部６で、ホストＯＳログ１３に記録された識別子をもとに、ゲストＯＳログ１２を参照するのみで、イベントのログを発生順に並べて、まとめ上げることができる。これにより、ログのデータの転送の負荷を軽減して、ログをまとめ上げる際にもソートなどの処理が不要になり、複数の環境で生成されたログをまとめる処理の負荷を抑えつつ、イベントのログを発生順に並べることができるようになる。

【0022】

さらに、識別子のみの通知を行なっているため、ログデータの出力書式が変更された場合でも、出力書式のインタフェース変更を考慮する必要なく動作させることができる。

【0023】

実施の形態２．
以上の実施の形態１では、ゲストＯＳ３のイベントが発生するタイミングごとに識別子を通知し、発生順にイベントが並ぶようにしたものであるが、本実施の形態２では、識別子通知による負荷を下げたい場合に、周期的なタイミングで識別子を通知するようにした実施の形態を示す。以下、図６、図７を用いて、実施の形態２のログ生成装置９の構成と、ログ生成の処理フローについて説明する。

【0024】

図６は、実施の形態２に係るログ生成装置の一構成例を示す図である。
図６において、ホストＯＳ２に関わる構成は、実施の形態1の図２と同様であるが、ゲストＯＳ３に関わる構成が異なり、ゲストＯＳ３に周期タイマ部１５を追加する。また、ゲストＯＳ３に対して周期割込みを通知する周期割込み発生部１８を設ける。さらに、実施の形態１の図１に記載した識別子生成部１０と識別子通知部１１をゲストＯＳログ生成部７に備える代わりに、周期タイマ部１５に識別子生成部１６と識別子通知部１７を備える。

【0025】

周期タイマ部１５は、周期割込み発生部１８からの割込み通知を受け、周期的に、識別子生成部１６と識別子通知部１７を実行する。識別子生成部１６は、実行される度に識別子を生成し、識別子通知部１７が、ゲストＯＳログ生成部７と、ホストＯＳ２上の仮想マシンモニタ（ＶＭＭ）４に識別子を通知する。識別子通知部１７から識別子の通知を受けたゲストＯＳログ生成部７は、その識別子をゲストＯＳログ１２に記録する。一方、識別子通知部１７から識別子の通知を受けたときのホストＯＳ２側の識別子の記録は、実施の形態1の処理と同様である。マージ部６は、ホストＯＳログ１３に記録された識別子から、ゲストＯＳログ１２に記録された識別子を参照し、次の識別子までのログをまとめ上げて、マージログ１４を生成する。

【0026】

本実施の形態２では、ゲストＯＳログ生成部７が、ゲストＯＳログ１２に識別子を記録するようにしたが、周期タイマ部１５の起床タイミングと識別子とが、ログ上で結び付けられればよいため、識別子はゲストＯＳログ１２に記録することに限られない。例えば、タイマの起床タイミングをログとして記録できるゲストＯＳログ生成部７を用いている場合、そのタイマの起床タイミングのログに識別子を記録する方法でも実現可能である。

【0027】

なお、周期割込み発生部１８は、周期的に割込みを発生させることができればよいため、ソフトウェア、または、ハードウェアのどちらで実現してもよい。

【0028】

次に、実施の形態２におけるログ生成装置の動作について、図７を参照して説明する。
図７は、実施の形態２におけるゲストＯＳ３側の処理の流れを示すフローチャートである。
なお、ホストＯＳ２側の処理フローは、実施の形態１と同様であるため、説明を省略する。

【0029】

まず、ステップＳ３０１において、周期タイマ部１５は、タイマを設定する。タイマの設定では、ログの取得期間の設定を行なう。
次に、ステップＳ３０２において、周期タイマ部１５は、周期割込み発生部１８により起床させられるまで待機し、起床したとき、ステップＳ３０３の分岐に進む。
次に、ステップＳ３０３において、周期タイマ部１５は、ゲストＯＳログ生成部７と、ホストＯＳ２の仮想マシンモニタ（ＶＭＭ）４に識別子を通知する。
次に、ステップＳ３０４において、周期タイマ部１５は、ログの生成の終了条件を満たすまで、ステップＳ４０２からステップＳ４０３までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。

【0030】

次に、ゲストＯＳログ生成部７の処理の流れを説明する。
まず、ステップＳ４０１において、ゲストＯＳログ生成部７は、ログ生成の準備をする。ログ生成の準備は、実施の形態１と同様の処理である。
次に、ステップＳ４０２において、ゲストＯＳログ生成部７は、ログを発生するイベントか、周期タイマ部１５からの識別子通知が来るまで待機する。ログを発生するイベントが発生した場合、ステップＳ４０３の分岐へ進む。また、周期タイマ部１５から識別子通知を受けた場合、ステップＳ４０４の分岐へ進む。
次に、ステップＳ４０２でログを発生するイベントが発生した場合、ステップＳ４０３において、ゲストＯＳログ生成部７は、発生したログをゲストＯＳログ１２に出力する。ゲストＯＳログ１２への出力書式例は、図３に示す通りである。
次に、ステップＳ４０２で周期タイマ部１５から識別子通知を受けた場合、ステップＳ４０４において、ゲストＯＳログ生成部７は、通知を受けた識別子が付与されたログをゲストＯＳログ１２に出力する。
次に、ステップＳ４０５において、ゲストＯＳログ生成部７は、ログの生成の終了条件を満たすまで、ステップＳ４０２からステップＳ４０５までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。

【0031】

なお、本実施の形態２において、ログのイベント発生順を保証できる精度は、周期タイマ部１５が実行される割込み発生間隔によって異なる。例えば、１秒間隔で周期タイマ部１５を起動するとしたとき、１秒間隔でイベントが発生した前後関係は保証できるが、１秒間隔以内のイベント発生順については保証することができない。この周期間隔をイベントの発生間隔に近づけた場合、実施の形態１とほぼ同様の処理の負荷となり、また、イベント発生順を保証できる精度も実施の形態１とほぼ同様となる。

【0032】

以上のように、本実施の形態２の発明は、イベント発生毎に識別子通知を行なうのではなく、周期タイマによって識別子を通知し、イベント発生毎よりも識別子の通知頻度を下げることにより、識別子の生成・通知・記録の処理の負荷が軽減されるという効果がある。

【0033】

実施の形態３．
以上の実施の形態１、２では、イベント発生毎に識別子を通知するか、一定周期ごとに識別子を通知するか、で異なる実施形態を示したが、本実施の形態３では、実施の形態１、２を併用することで、処理に要する負荷と、イベント発生順を保証する精度との調整が可能となることを示す。例えば、実施の形態１を用いて発生頻度が稀なイベントに対して、イベント発生毎に識別子を通知させた場合、負荷は非常に低くなるが、識別子を通知しないイベントの発生順を保証する精度が低くなる。このイベント発生毎に識別子を通知する設定に加え、実施の形態２を用いて、発生頻度が稀なイベントより短い間隔で識別子を通知することで、発生頻度が稀なイベントが発生していない場合には、一定周期ごとの識別子を元にイベント発生順の精度を保証することができるようになる。

【0034】

また、実施の形態１では、ゲストＯＳ３で発生する全てのログに対して識別子を生成し、割り当て、通知する必要があったが、実施の形態１、２を併用することで、特定のイベントだけを通知するだけでもログの収集が可能であり、イベントの種類別に発生順を保証する精度を変えることができるようになる。例えば、ディスクにアクセスするイベントとネットワーク通信のイベントを取得しているときに、ディスクにアクセスするイベントのみ識別子を割り当て、通知するようにしたとする。この場合、ディスクにアクセスするイベントは、実施の形態１と同様のイベント毎単位の精度でゲストＯＳとのログを発生順に並べることができる。一方、ネットワーク通信のイベントは、実施の形態２と同様の精度で、イベント発生順に並べることができる。これにより、ディスクアクセス時にホストＯＳのログとの時系列を正確に取りつつ、そのときにネットワーク通信が行なわれていたかどうかを判断することができる。

【0035】

以下、図８、図９を用いて、実施の形態３のログ生成装置９の構成と、ログ生成の処理フローについて説明する。
図８は、実施の形態３に係るログ生成装置の一構成例を示す図である。
図８において、ホストＯＳ２に関わる構成は、実施の形態1の図２と同様であるが、ゲストＯＳ３に関わる構成が異なり、ゲストＯＳ３に、識別子調停部１９を追加する。

【0036】

識別子調停部１９は、識別子を生成すべきタイミングにおいて、周期タイマ部１５により周期的に識別子を生成・通知するか、または、ゲストＯＳログ生成部７によりイベント発生毎に識別子を生成・通知するかの判断を行なう。例えば、ゲストＯＳログ生成部７が、高頻度で識別子を通知している場合には、識別子調停部１９が周期タイマ部１５で生成した識別子を通知しないようにして、ゲストＯＳログ生成部７によりイベント発生毎に識別子を生成・通知すると判断する。一方、ゲストＯＳログ生成部７が、識別子を通知する頻度が低い場合には、ゲストＯＳログ生成部７で生成した識別子を通知しないようにして、周期タイマ部１５により周期的に生成した識別子を生成・通知すると判断する。

【0037】

次に、本実施の形態３におけるログ生成装置の動作について、図９を参照して説明する。
図９は、実施の形態３におけるゲストＯＳ３側の処理の流れを示すフローチャートである。
なお、ホストＯＳ２側の処理フローは、実施の形態１と同様であるため、説明を省略する。

【0038】

まず、ステップＳ５０１において、周期タイマ部１５は、タイマを設定する。タイマの設定では、ログの取得期間の設定を行なう。
次に、ステップＳ５０２において、周期タイマ部１５は、周期割込み発生部１８により起床させられるまで待機し、起床したとき、ステップＳ５０３の分岐に進む。
次に、ステップＳ５０３において、識別子調停部１９は、周期タイマ部１５により周期的に識別子の通知をするか否かを決定する。周期タイマ部１５により周期的に識別子の通知をする場合は、ステップＳ５０４に進み、周期タイマ部１５により周期的に識別子の通知をしない場合は、ステップＳ５０４をスキップしてステップＳ５０５に進む。
次に、ステップＳ５０４において、周期タイマ部１５は、ゲストＯＳログ生成部７と、ホストＯＳ２の仮想マシンモニタ（ＶＭＭ）４に識別子を通知する。
次に、ステップＳ５０５において、周期タイマ部１５は、ログの生成の終了条件を満たすまで、ステップＳ４０２からステップＳ４０３までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。

【0039】

次に、ゲストＯＳログ生成部７の処理の流れを説明する。
まず、ステップＳ６０１において、ゲストＯＳログ生成部７は、ログ生成の準備をする。ログ生成の準備は、実施の形態１と同様の処理である。
次に、ステップＳ６０２において、ゲストＯＳログ生成部７は、ログを発生するイベントか、周期タイマ部１５からの識別子通知が来るまで待機する。ログを発生するイベントが発生した場合、ステップＳ６０３の分岐へ進む。また、周期タイマ部１５から識別子通知を受けた場合、ステップＳ６０６の分岐へ進む。
次に、ステップＳ６０３において、識別子調停部１９は、ゲストＯＳログ生成部７によりイベント発生毎に識別子を通知するか否かを決定する。ゲストＯＳログ生成部７によりイベント発生毎に識別子を通知する場合は、ステップＳ６０４に進み、ゲストＯＳログ生成部７によりイベント発生毎に識別子を通知しない場合は、ステップＳ６０５に進む。
次に、ステップＳ６０４において、ゲストＯＳログ生成部７は、識別子通知部１１により、イベント毎に生成した識別子を、ホストＯＳ２の仮想マシンモニタ（ＶＭＭ）４に通知する。
次に、ステップＳ６０５において、ゲストＯＳログ生成部７は、ステップＳ６０３で識別子を通知すると決定した場合、通知した識別子とログをゲストＯＳログ１２に出力する。一方、ステップＳ６０３で識別子を通知しないと決定した場合、識別子を付与していないログをゲストＯＳログ１２に出力する。
次に、ステップＳ６０２で周期タイマ部１５から識別子通知を受けた場合、ステップＳ６０６において、ゲストＯＳログ生成部７は、識別子が付与されたログをゲストＯＳログ１２に出力する。
次に、ステップＳ６０７において、ゲストＯＳログ生成部７は、ログの生成の終了条件を満たすまで、ステップＳ６０２からステップＳ６０７までを繰り返す。ログの生成の終了条件は、例えば、予め設定されたログの取得期間を満たした場合や、ログ取得の終了のシグナルが発生した場合などである。

【0040】

以上のように、本実施の形態３の発明は、実施の形態１、２のログ生成装置を単体で用いた場合よりも、識別子調停部１９を用いて実施の形態１、２のログ生成装置を併用することにより、ログ生成処理に要する負荷と、イベント発生順を保証する精度の調整が細かく行なえるようになるという効果がある。

【0041】

実施の形態４．
以上の実施の形態１〜３では、ゲストＯＳ３を１つとしたものであるが、次に、本実施の形態４では、ゲストＯＳ３が複数台ある場合の実施の形態を示す。

【0042】

図１０は、実施の形態４に係るログ生成装置の一実施例を示す情報処理装置の構成図である。
図１０では、実施の形態１に対して、ゲストＯＳ２０と、それを動作させている仮想マシンモニタ（ＶＭＭ）２２を追加で１台、配置する。なお、本実施の形態４では、追加で１台配置した例を示したが、２台以上の複数台を配置することもでき、配置できる最大台数は計算機の性能により異なる。また、本実施の形態４では、実施の形態１をもとに示したが、実施の形態２または３においても、ゲストＯＳと、それを動作させている仮想マシンモニタ（ＶＭＭ）を複数配置することが可能である。さらに、複数のゲストＯＳの種類は、異なる種類を用いていてもよい。

【0043】

図１１は、実施の形態４に係るログ生成装置の一構成例を示す図である。
図１１において、実施の形態４における各構成要素の関係は、ゲストＯＳ３とゲストＯＳ２０の２つが動作していることを除き、実施の形態１とほぼ同様である。実施の形態１との相違点は、２台を同時に動作させるために、識別子生成部２８が、ゲストＯＳ３とゲストＯＳ２０とで重複することなく一意の識別子を生成する必要がある点である。また、ゲストＯＳが、２台に限らず複数台ある場合には、全てのゲストＯＳに対して一意の識別子を生成する必要がある。この複数台で一意の識別子は、例えば、計算機名＋各計算機内の時刻と組み合わせることで生成することができる。

【0044】

マージ部６は、ホストＯＳログ１３に埋め込まれた識別子を参照する際に、ゲストＯＳログ１２と、ゲストＯＳログ２６の２つから識別子を検索する。その他の各ゲストＯＳと仮想マシンモニタ（ＶＭＭ）の個々の動作は、実施の形態１の図４、図５と同様である。

【0045】

以上のように、本実施の形態４の発明は、実施の形態１〜３に加え、識別子が全てのゲストＯＳで一意となるようにすることで、複数台のゲストＯＳと複数台の仮想マシンモニタ（ＶＭＭ）を動作させた場合でも、イベントのログを発生順に並べて、まとめ上げることができるようになる。

【符号の説明】

【0046】

１ 計算機、２ ホストＯＳ、３ ゲストＯＳ、４ 仮想マシンモニタ（ＶＭＭ）、５ ホストＯＳログ生成部、６ マージ部、７ ゲストＯＳログ生成部、８ イベント生成部、９ ログ生成装置、１０ 識別子生成部、１１ 識別子通知部、１２ ゲストＯＳログ、１３ ホストＯＳログ、１４ マージログ、１５ 周期タイマ部、１６ 識別子生成部、１７ 識別子通知部、１８ 周期割込み発生部、１９ 識別子調停部、２０ ゲストＯＳ、２１ ゲストＯＳログ生成部、２２ 仮想マシンモニタ（ＶＭＭ）、２３ イベント生成部、２４ 識別子生成部、２５ 識別子通知部、２６ ゲストＯＳログ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】