JP2010009555A - 情報処理装置及びプログラム - Google Patents

Abstract

【課題】アプリケーションのログとクラスタソフトウェアのログをと、一意の情報でつき合わせることを可能とする。
【解決手段】ログ管理マネージャ５０に含まれるログ対応情報テーブルは、機能単位を表す機能単位情報及びログが出力されるログファイル８０を示すログファイル情報を対応付けて保持する。ログ管理マネージャ５０は、機能単位の状態を取得する。ログ管理マネージャ５０は、取得された機能単位の状態を、機能単位情報に対応付けてログ対応情報テーブルに保持させる。ジャケットライブラリ４０は、ログ及びログファイル情報をフックする。ログ管理マネージャ５０は、フックされたログファイル情報がログ対応情報テーブルに保持されていると判定された場合、当該ログファイル情報に対応付けられている機能単位情報をログに付加して、複製ログファイル９０に書き込む。
【選択図】 図２

Description

本発明は、アプリケーションのログを記録する情報処理装置及びプログラムに関する。

近年、複数のコンピュータ（情報処理装置）から構成されるクラスタシステムが知られている。このクラスタシステムにおいては、当該クラスタシステムを構成する複数のコンピュータが連携して動作することで、クライアントコンピュータに対してあたかも１台のコンピュータで機能を提供しているように見せることができる。また、クラスタシステムには、例えば高可用性（High Availability）クラスタシステム（以下、ＨＡクラスタシステムと表記）と呼ばれるものがある。

ＨＡクラスタシステムでは、冗長な待機系コンピュータを用意し、稼働系コンピュータで障害が発生した場合に当該稼働系コンピュータで提供していた機能を待機系コンピュータに引き継ぐことでシステムの運用を継続させる。このようにして、ＨＡクラスタシステムでは、提供される機能の可用性を向上させることが可能となる。

上記したＨＡクラスタシステムでは、当該ＨＡクラスタシステムを構成する複数のコンピュータのうち、どのコンピュータでもシステムが提供する機能を稼働できるようにする必要がある。このため、ＨＡクラスタシステムにおいて提供される機能を処理するアプリケーション（プログラム）は、当該システムを構成する複数のコンピュータ上に存在する。

ところで、例えば複数のコンピュータ上に存在するアプリケーションが動作した場合、当該アプリケーションの動作の履歴情報であるログ情報（以下、アプリケーションのログと表記）が例えばログファイルに記録される。この場合、アプリケーションのログ（動作ログ）は、それぞれのコンピュータ上にあるアプリケーション自身のログファイルに記録される場合が多い。

また、ＨＡクラスタシステムを構成する複数のコンピュータ上に存在するアプリケーションの動作は、ＨＡクラスタシステムを構成する複数のコンピュータ上に存在するクラスタソフトウェアによって監視・制御される。このクラスタソフトウェアは、ＨＡクラスタシステムを管理する機能を有する。

上記したアプリケーションと同様に、複数のコンピュータ上に存在するクラスタソフトウェアが動作した場合、当該クラスタソフトウェアのアプリケーションに対する監視・制御の履歴情報であるログ情報（以下、クラスタソフトウェアのログと表記）が例えばログファイルに記録される。この場合、クラスタソフトウェアのログ（監視・制御ログ）は、アプリケーションのログとは別のクラスタソフトウェア自身のログファイルに記録される。

上記したようにそれぞれ異なるログファイルに記録されたアプリケーションのログ及びクラスタソフトウェアのログは、例えばＨＡクラスタシステムが提供する機能に障害が発生した場合に当該障害を解析するために用いられる。

この障害解析の際には、複数のコンピュータ上に存在するアプリケーションのログ及びクラスタソフトウェアのログを例えば障害解析を行うユーザ自身でつき合わせる（関連付ける）必要がある。

例えばアプリケーションの稼働場所が複数のコンピュータのどのコンピュータに移動しても、分散しているログファイルを一元的に参照できる技術（以下、先行技術と表記）が開示されている（例えば、特許文献１を参照）。この先行技術によれば、ログ管理マネージャがログファイルの場所をログ管理エージェントのＩＤのリストとして記憶しているため、複数の場所に分散しているログファイルを一元的に参照できる。また、先行技術によれば、ログ管理マネージャがログファイルの生成順序を時系列順に管理するように構成されているため、分散しているログファイルを時系列順に参照することができる。
特開２００７−１０８９２９号公報

上記した複数のコンピュータ上のアプリケーションのログとクラスタソフトウェアのログをつき合わせることは、以下の理由によって困難な作業となる。

まず、アプリケーションのログは多種多様であり、クラスタソフトウェアの制御に対応するログはアプリケーションによって異なる。このため、アプリケーションのログとクラスタソフトウェアのログを付き合わせるための一意の情報が存在しない。

また、アプリケーションのログは、稼動系でないときも出力される可能性があり、クラスタソフトウェアの制御によって開始されている状態のログのみを切り出すための一意の情報が存在しない。

更に、アプリケーションのログはクラスタ化される（つまり、例えばＨＡクラスタシステムにおいて用いられる）ことを想定していない場合があり、例えば複数のコンピュータ上のログ間でつき合わせるために必要な情報を有していない場合が多い。

上記したような理由によって、ＨＡクラスタシステムにおける障害解析においては、高いスキルと時間を要する場合がある。更には、上記した理由から、アプリケーションのログとクラスタソフトウェアのログとのつき合わせができないことも有り得るため、障害解析自体を行うことができない場合がある。

一方、上記した先行技術では、複数のコンピュータ間で移動（動作）するアプリケーションのログを同時に見ることが可能である。

しかしながら、先行技術では、例えば移動する原因となるログ（ＨＡクラスタシステムの場合においてはクラスタソフトウェアのログ）との上記したようなつき合わせについては適用できない。また、先行技術では、稼動系（コンピュータ）でないときにログを出力するアプリケーションの場合に稼働系時／待機系時のログを一意の情報で区別することはできない。

更には、例えば同じコンピュータで再度アプリケーションが動作した際にはログ出力順と表示順が入れ替わる場合がある。この場合、先行技術においてはログファイルを作成した順で統合するため、ログの順序付けを行うことができない場合がある。このような場合、ログの順序付けにはアプリケーションのログ自身の情報（例えば、時刻情報）が必要となる。

そこで、本発明の目的は、アプリケーションのログとクラスタソフトウェアのログとを、一意の情報でつき合わせることを可能とする情報処理装置及びプログラムを提供することにある。

本発明の１つの態様によれば、一の機能単位をなす一つ又は複数のアプリケーションのログが、当該アプリケーション毎に異なる第１のログファイルに出力される情報処理装置が提供される。この情報処理装置は、前記機能単位を表す機能単位情報及び当該アプリケーションのログが出力される第１のログファイルを示すログファイル情報を対応付けて保持するテーブルと、前記機能単位の状態を取得する状態取得手段と、前記状態取得手段によって取得された機能単位の状態を、当該機能単位を表す機能単位情報に対応付けて前記テーブルに保持させるログ対応情報管理手段と、前記ログ及び当該ログが出力される第１のログファイルを示すログファイル情報を取得するログ取得手段と、前記ログ取得手段によって取得されたログファイル情報が前記テーブルに保持されているかを判定する判定手段と、前記ログファイル情報が前記テーブルに保持されていると判定された場合、当該ログファイル情報に対応付けて保持されている機能単位の状態に応じて、当該ログファイル情報に対応付けて当該テーブルに保持されている機能単位情報を前記ログ取得手段によって取得されたログに付加して、前記第１のログファイルとは異なる第２のログファイルに書き込む書込処理手段とを具備する。

本発明によれば、アプリケーションのログとクラスタソフトウェアのログとを、一意の情報でつき合わせることを可能とする。

以下、図面を参照して、本発明の各実施形態について説明する。

［第１の実施形態］
図１は、本発明の第１の実施形態に係る情報処理装置（以下、コンピュータと表記）を備えるクラスタシステムのハードウェア構成を示すブロック図である。

図１に示すように、クラスタシステムは、複数のコンピュータ１０を備える。複数のコンピュータ１０には、例えば稼動系コンピュータ及び複数の待機系コンピュータが含まれる。

複数のコンピュータ１０は、例えばネットワークを介して互いに通信可能に接続されている。

このクラスタシステムは、当該クラスタシステムを構成する複数のコンピュータ１０のうち、例えば稼動系コンピュータとして動作するコンピュータ（稼動系コンピュータ）１０で障害が発生した場合に、当該稼動系コンピュータ１０の処理が待機系コンピュータとして動作するコンピュータ（待機系コンピュータ）１０に引き継がれる高可用性（High Availability）クラスタシステム（ＨＡクラスタシステム）である。これにより、クラスタシステムにおいては、例えば稼働系コンピュータ１０において障害が発生した場合であっても待機系コンピュータ１０において運用を継続することが可能となる。

図２は、図１に示す複数のコンピュータ１０の各々（以下、単にコンピュータ１０と表記）の主として機能構成を示すブロック図である。

図２に示すように、コンピュータ１０上では、クラスタソフトウェア２０、アプリケーションプログラム３０、ジャケットライブラリ４０、ログ管理マネージャ５０及びオペレーティングシステム（ＯＳ：Operating System）６０が動作する。なお、コンピュータ１０上では、例えば複数のアプリケーションプログラム３０が動作するものとする。

また、コンピュータ１０は、クラスタソフトウェアログファイル７０、アプリケーションログファイル（第１のログファイル）８０及び複製アプリケーションログファイル（第２のログファイル）９０を有する。

なお、コンピュータ１０は、各機能を実現するためのハードウェア構成、またはハードウェアとソフトウェアとの組み合わせ構成として実現されている。ソフトウェアは、予め記憶媒体又はネットワークからインストールされ、その機能を実現させるためのプログラムからなる。ソフトウェアで実現可能な要素としては、例えば、クラスタソフトウェア２０、アプリケーションプログラム３０、ジャケットライブラリ４０、ログ管理マネージャ５０及びオペレーティングシステム６０が挙げられる。

また、クラスタソフトウェアログファイル７０、アプリケーションログファイル８０及び複製アプリケーションログファイル９０は、例えばハードディスクドライブ（ＨＤＤ：Hard Disk Drive）のような記憶装置にその領域が確保されている。

クラスタソフトウェア２０は、例えばクラスタシステムを構成する他のコンピュータ１０（のクラスタソフトウェア２０）と連携して当該クラスタシステムを管理及び運用する。これにより、クラスタシステム全体として各種機能が提供される。

クラスタソフトウェア２０は、クラスタシステムにおいて提供される機能単位を管理し、当該機能単位の状態、例えば開始及び停止等を制御する機能を有する。この機能単位は、例えば１つまたは複数のアプリケーションプログラム３０からなり、システムが提供する役割の単位である。

クラスタソフトウェア２０は、上記したクラスタシステムにおいて提供される機能単位を表す機能単位情報及び当該機能単位の状態等の情報をログ管理マネージャ５０に対して通知する。

また、クラスタソフトウェア２０は、当該クラスタソフトウェア２０による管理及び制御に応じたログ情報（クラスタソフトウェア２０のログ）を、例えばオペレーティングシステム６０に対して出力する。このクラスタソフトウェア２０のログは、クラスタシステムによって提供される（クラスタソフトウェア２０によって管理される）機能単位で出力される。クラスタソフトウェア２０のログは、例えばクラスタシステムにおける障害解析等に用いられる。クラスタソフトウェア２０のログには、例えばクラスタソフトウェア２０によって管理される機能単位を表す情報（以下、機能単位情報と表記）及び当該機能単位でのログが出力された時刻を示す時刻情報が付加される。

アプリケーションプログラム３０は、クラスタシステムにおいて提供される機能を実現するためのプログラムである。アプリケーションプログラム３０は、当該アプリケーションプログラム３０のログ（アプリケーションプログラム３０の動作に関するログ）をオペレーティングシステム６０に出力する機能を有する。これにより、上記した一の機能単位をなす一つまたは複数のアプリケーションプログラム３０のログ（動作ログ）が例えばアプリケーションログファイル８０に出力される。このアプリケーションプログラム３０の動作ログは、上記したクラスタソフトウェア２０のログと同様に、例えばクラスタシステムにおける障害解析等に用いられる。

ジャケットライブラリ４０は、アプリケーションプログラム３０から出力された動作ログをフック（取得）する。これにより、ジャケットライブラリ４０は、アプリケーションプログラム３０によって出力された動作ログの書き込みを検出する。ジャケットライブラリ４０は、フックされた動作ログをログ管理マネージャ５０に出力する。また、ジャケットライブラリ４０は、フックされた動作ログをオペレーティングシステム６０に対して出力する。

ログ管理マネージャ５０は、ジャケットライブラリ４０によって出力されたアプリケーションプログラム３０の動作ログに、当該アプリケーションプログラム３０からなる機能単位を表す機能単位情報を付加してアプリケーションログファイル８０とは異なる複製アプリケーションログファイル９０に書き込む機能を有する。このとき、ログ管理マネージャ５０は、上記したクラスタソフトウェア２０から通知された情報に応じて書き込み処理を実行する。ログ管理マネージャ５０は、機能単位情報が付加されたログをオペレーティングシステム６０に対して出力することによって、当該ログを複製アプリケーションログファイル９０に書き込む。

オペレーティングシステム６０は、クラスタソフトウェア２０によって出力されたクラスタソフトウェア２０のログをクラスタソフトウェアログファイル７０に書き込む処理を実行する。

オペレーティングシステム６０は、ジャケットライブラリ４０によって出力されたアプリケーションプログラム３０の動作ログをアプリケーションログファイル８０に書き込む処理を実行する。

また、オペレーティングシステム６０は、例えばログ管理マネージャ５０によって出力された機能単位情報が付加された当該機能単位情報によって表される機能単位をなすアプリケーションプログラム３０の動作ログを複製アプリケーションログファイル９０に書き込む処理を実行する。

ここで、図３を参照して、前述したクラスタシステムにおいて提供される機能単位について説明する。

図３に示すように、例えばクラスタシステムにおいて提供される機能単位として機能単位α（単にＦｎαと表記）、機能単位β（単にＦｎβと表記）及び機能単位γ（単にＦｎγと表記）が存在するものとする。また、コンピュータ１０上では、例えばアプリケーション１〜３が動作するものとする。また、コンピュータ１０は、ログファイルＡ〜Ｄを有するものとする。

ここでは、Ｆｎαは、アプリケーションプログラム１及び２からなるものとする。Ｆｎβは、アプリケーションプログラム３からなるものとする。また、Ｆｎγは、アプリケーションプログラム３からなるものとする。

このように、Ｆｎ（機能単位）は、複数のアプリケーションプログラムからなることがある。また、複数のＦｎが１つのアプリケーションプログラムを共有することがある。換言すれば、Ｆｎ及びアプリケーションプログラムは、１：Ｎ（Ｎは１以上の整数）の関係にある。

また、アプリケーションプログラム１は、Ｆｎαのログ（α）をログファイルＡ及びＢに出力する。つまり、アプリケーションプログラム１は、当該アプリケーションプログラム１からなるＦｎαのログ（α）を出力する。

アプリケーションプログラム２は、Ｆｎαのログ（α）をログファイルＣに出力する。また、アプリケーションプログラム３は、Ｆｎβのログ（β）及びＦｎγのログ（γ）をログファイルＤに出力する。

このように、１つのアプリケーションプログラムは、複数のログファイルにログを出力することがある。また、複数のアプリケーションプログラムは、１つのログファイルにログを出力することはない。つまり、複数のアプリケーションプログラムは、１つのログファイルを共有しない。以上から、アプリケーションプログラム及びログファイルは、１：Ｍ（Ｍは１以上の整数）の関係にある。

上記したように、例えば図２に示すアプリケーションログファイル８０は、複数のログファイルを含む構成であっても構わない。

図４は、図２に示すクラスタソフトウェア２０の主として機能構成を示すブロック図である。図２に示すように、クラスタソフトウェア２０は、ＨＡクラスタ制御部２１、ログ対応情報登録部２２及び制御情報送信部２３を含む。換言すれば、クラスタソフトウェア２０は、ＨＡクラスタ制御部２１、ログ対応情報登録部２２及び制御情報送信部２３というモジュールで構成される。

ＨＡクラスタ制御部２１は、例えばクラスタシステムにおいて提供される機能単位の情報を有し、当該機能単位で機能を実現するソフトウェアやハードウェアの制御及び監視を行う。これにより、クラスタシステムにおいて提供される機能単位の高可用性が実現される。ＨＡクラスタ制御部２１は、アプリケーションプログラム３０からなる機能単位の開始及び停止等の制御を実行する。

ログ対応情報登録部２２は、例えばクラスタシステムの運用を開始する前のＨＡクラスタ制御部２１から呼ばれ、当該クラスタシステムによって提供される機能単位を表す機能単位情報及び当該機能単位をなすアプリケーションプログラム３０の動作ログが出力されるログファイルを示す情報（以下、ログファイル情報と表記）を含むログ対応情報をログ管理マネージャ５０に出力（送信）する。

ここで、図５は、ログ対応情報登録部２２によって出力されるログ対応情報のデータ構造の一例を示す。図５に示すように、ログ対応情報登録部２２によって出力されるログ対応情報には、機能単位情報及びログファイル情報（ログファイル名）が含まれる。

図５に示す例では、ログ対応情報には、例えば機能単位情報「機能単位１」及びログファイル情報「ログファイルＡ」（を含むペア情報）が含まれる。また、ログ対応情報には、例えば機能単位情報「機能単位１」及びログファイル情報「ログファイルＢ」が含まれる。また、ログ対応情報には、例えば機能単位情報「機能単位２」及びログファイル情報「ログファイルＣ」が含まれる。

再び図４に戻ると、制御情報送信部２３は、例えばＨＡクラスタ制御部２１によってコンピュータ１０上で機能単位が制御される際に、当該機能単位を表す機能単位情報及び当該機能単位の制御された内容（制御内容）を含む制御情報をログ管理マネージャ５０に出力する。また、制御情報送信部２３は、例えばクラスタソフトウェア２０が再起動された場合には、その旨を示す情報（再起動情報）をログ管理マネージャ５０に出力する。

ここで、図６は、制御情報送信部２３によって出力される制御情報及び再起動情報のデータ構造の一例を示す。図６に示すように、制御情報送信部２３によって出力される制御情報には、機能単位情報及び制御内容が含まれる。なお、制御内容には、例えば開始及び停止が含まれる。

図６に示す例では、制御情報には、例えば機能単位情報「機能単位１」及び制御内容「開始」が含まれる。また、制御情報には、例えば機能単位情報「機能単位１」及び制御内容「停止」が含まれる。

また、図６に示すように、例えばクラスタソフトウェア２０が再起動されたときには、その旨を示す再起動情報がログ管理マネージャ５０に対して出力される。

次に、図７は、図２に示すジャケットライブラリ４０の主として機能構成を示すブロック図である。

図７に示すように、ジャケットライブラリ４０は、openフック部４１、ファイル名対応テーブル４２、writeフック部４３及びwrite情報送信部４４を含む。換言すれば、ジャケットライブラリ４０は、openフック部４１、writeフック部４３及びwrite情報送信部４４というモジュールと、ファイル名対応テーブル４２というデータから構成される。

openフック部４１は、アプリケーションプログラム３０からのopen要求をフックする。このopen要求は、例えばアプリケーションプログラム３０の動作ログがアプリケーションログファイル８０に出力される際に、当該アプリケーションログファイル８０を開くための初期動作として、アプリケーションプログラム３０から出力される。open要求には、当該open要求の対象となるアプリケーションログファイル８０のファイル名が含まれる。openフック部４１は、フックされたopen要求に含まれるファイル名を取得する。openフック部４１は、ファイル名が取得されると、フックされたopen要求をオペレーティングシステム６０に対して出力する。

ここで、オペレーティングシステム６０は、openシステムコール（図示せず）を含む。openシステムコールは、ジャケットライブラリ４０からのopen要求を受けると、当該open要求に応じて上記したアプリケーションログファイル８０を開く処理を実行する。また、openシステムコールは、open要求に応じた処理が実行されると、当該open要求に対する応答をアプリケーションプログラム３０に返す。

また、openフック部４１は、オペレーティングシステム６０からのopen要求に対する応答をフックする。この応答には、open要求の対象となるアプリケーションログファイル８０を識別するためのファイル識別子が含まれる。openフック部４１は、フックされた応答に含まれるファイル識別子を取得する。

openフック部４１は、取得されたファイル名及びファイル識別子を対応付けてファイル名対応テーブル４２に追加（登録）する。なお、このファイル名対応テーブル４２は、例えば記憶装置にその領域が確保される。

openフック部４１は、ファイル名対応テーブル４２に対してファイル名及びファイル識別子を追加した後、フックされた応答をアプリケーションプログラム３０に返す。

writeフック部４３は、アプリケーションプログラム３０からのwrite要求をフックする。アプリケーションプログラム３０は、このwrite要求により、例えばアプリケーションプログラム３０の動作ログ（書込みデータ）をアプリケーションログファイル８０に書き込む（出力する）ことをオペレーティングシステム６０に対して要求する。このwrite要求には、アプリケーションプログラム３０の動作ログ（の内容）及び当該動作ログが出力される（書き込まれる）アプリケーションログファイル８０を識別するためのファイル識別子が含まれる。また、write要求には、例えばアプリケーションプログラム３０の動作ログを書き込む物理的な位置を示すアドレス情報等が含まれる。

writeフック部４３は、フックされたwrite要求に含まれるアプリケーションプログラム３０の動作ログ及びファイル識別子を取得する。writeフック部４３は、取得された動作ログ及びファイル識別子を含む情報送信要求をwrite情報送信部４４に出力する。

writeフック部４３は、情報送信要求をwrite情報送信部４４に出力した後、フックされたwrite要求をオペレーティングシステム６０に出力する。

ここで、オペレーティングシステム６０は、writeシステムコール（図示せず）を含む。writeシステムコールは、ジャケットライブラリ４０からのwrite要求を受けると、当該write要求に含まれるアプリケーションプログラム３０の動作ログを、当該write要求に含まれるファイル識別子によって識別されるアプリケーションログファイル８０に書き込む処理を実行する。writeシステムコールは、write要求に応じた処理が実行されると、当該write要求に対する応答をアプリケーションプログラム３０に返す。

writeフック部４３は、オペレーティングシステム６０からのwrite要求に対する応答をフックし、アプリケーションプログラム３０に返す。

write情報送信部４４は、アプリケーションプログラム３０のwrite要求実行時にwriteフック部４３から呼ばれる。write情報送信部４４は、writeフック部４３からの情報送信要求を受けると、例えばオペレーティングシステム６０から現在時刻を示す時刻情報を取得する。換言すれば、この時刻情報は、例えばジャケットライブラリ４０（に含まれるwriteフック部４３）によってwrite要求がフック（アプリケーションプログラム３０の動作ログ及びファイル識別子が取得）された時刻を示す。

また、write情報送信部４４は、情報送信要求に含まれるファイル識別子に対応付けてファイル名対応テーブル４２に登録されているファイル名を取得する。これにより、write情報送信部４４は、ファイル識別子からのファイル名変換を行う。

write情報送信部４４は、取得されたファイル名（書込み先ログファイル情報）、情報送信要求に含まれるアプリケーションプログラム３０の動作ログ（書込みデータ）及び取得された時刻情報を、ログ管理マネージャ５０に対して送信（出力）する。以下、write情報送信部４４によって送信される情報（書込み先ログファイル情報、書込みデータ及び時刻情報）をまとめてwrite情報と称する。

ここで、図８は、図７に示すファイル名対応テーブル４２のデータ構造の一例を示す。図８に示すように、ファイル名対応テーブル４２には、ファイル識別子及び当該ファイル識別子によって識別されるアプリケーションログファイル８０のファイル名が対応付けて保持（登録）されている。

図８に示す例では、ファイル名対応テーブル４２には、ファイル識別子「識別子α」及びファイル名「ログファイルＡ」が対応付けて保持されている。これによれば、「識別子α」によって識別されるアプリケーションログファイル８０のファイル名が「ログファイルＡ」であることが示される。

また、ファイル名対応テーブル４２には、ファイル識別子「識別子β」及びファイル名「ログファイルＢ」、ファイル識別子「識別子θ」及びファイル名「ログファイルＣ」が対応付けて保持されている。

図９は、write情報送信部４４によって送信されるwrite情報のデータ構造の一例を示す。

図９に示すように、write情報には、書込み先ログファイル情報、書込みデータ及び時刻情報が対応付けて含まれる。書込み先ログファイル情報は、アプリケーションプログラム３０の動作ログが出力されるアプリケーションログファイル８０のファイル名である。書込みデータは、アプリケーションプログラム３０の動作ログ（の内容）を示す。また、時刻情報は、上記したようにwriteフック部４３からの情報送信要求を受けた際にオペレーティングシステム６０から取得される。

図１０は、図２に示すログ管理マネージャ５０の主として機能構成を示すブロック図である。図１０に示すように、ログ管理マネージャ５０は、ログ対応情報受信部５１、制御情報受信部５２、ログ対応情報管理部５３、ログ対応情報テーブル５４、write情報受信部５５、書込判定部５６及び書込処理部５７を含む。換言すれば、ログ管理マネージャ５０は、ログ対応情報受信部５１、制御情報受信部５２、ログ対応情報管理部５３、write情報受信部５５、書込判定部５６及び書込処理部５７というモジュールと、ログ対応情報テーブル５４というデータから構成される。

ログ対応情報受信部５１は、クラスタソフトウェア２０に含まれるログ対応情報登録部２２によって出力（送信）されたログ対応情報を取得（受信）する。このログ対応情報には、機能単位を表す機能単位情報及び当該機能単位をなすアプリケーションプログラム３０の動作ログが出力されるログファイルを示すログファイル情報が含まれる。ログ対応情報受信部５１は、取得されたログ対応情報をログ対応情報管理部５３に渡す。

制御情報受信部５２は、クラスタソフトウェア２０に含まれる制御情報送信部２３によって出力（送信）された制御情報を取得（受信）する。この制御情報には、機能単位情報及び当該機能単位情報によって表される機能単位の制御内容が含まれる。この制御内容には、例えば機能単位の開始及び停止が含まれる。これにより、制御情報受信部５２は、制御情報に含まれる機能単位情報によって表される機能単位の状態（を示す情報）を取得する。

また、制御情報受信部５２は、制御情報送信部２３によって出力された再起動情報を取得する。

制御情報受信部５２は、取得された制御情報及び再起動情報をログ対応情報管理部５３に渡す。

ログ対応情報管理部５３は、ログ対応情報受信部５１から渡されたログ対応情報を取得する。ログ対応情報管理部５３は、取得されたログ対応情報に応じてログ対応情報テーブル５４を更新する。

ここで、ログ対応情報テーブル５４には、機能単位情報、ログファイル情報及び状態が保持される。機能単位情報は、クラスタシステムにおいて提供される機能単位を表す。ログファイル情報は、機能単位情報によって表される機能単位をなすアプリケーションプログラム３０の動作ログ（アプリケーションプログラム３０によって出力される動作ログ）が出力されるアプリケーションログファイル８０を示す。また、状態は、機能単位情報によって表される機能単位の状態、例えば開始（状態）及び停止（状態）を示す。開始は機能単位が開始したことを示し、停止は機能単位が停止したことを示す。なお、ログ対応情報テーブル５４は、例えば記憶装置にその領域が確保されている。

ログ対応情報管理部５３は、取得されたログ対応情報に含まれる機能単位情報及びログファイル情報を対応付けてログ対応情報テーブル５４に登録する。このとき、ログ対応情報テーブル５４において、登録された機能単位情報及びログファイル情報に対応付けられている状態は停止とする。

ログ対応情報管理部５３は、制御情報受信部５２から渡された制御情報及び再起動情報を取得する。ログ対応情報管理部５３は、取得された制御情報及び再起動情報に応じてログ対応情報テーブル５４を更新する。

ログ対応情報管理部５３は、取得された制御情報に含まれる制御内容が開始である場合、当該制御情報に含まれる機能単位情報に対応付けて開始を、ログ対応情報テーブル５４に保持させる（登録する）。また、ログ対応情報管理部５３は、取得された制御情報に含まれる制御内容が停止である場合、当該制御情報に含まれる機能単位情報に対応付けて停止を、ログ対応情報テーブル５４に保持させる。

また、ログ対応情報管理部５３は、再起動情報が取得された場合、ログ対応情報テーブル５４において、全ての機能単位情報に対応付けられている状態を停止に更新する。

write情報受信部５５は、ジャケットライブラリ４０に含まれるwrite情報送信部４４によって出力（送信）されたwrite情報を取得（受信）する。このwrite情報には、上記したように書込み先ログファイル情報（ファイル名）、書込みデータ（アプリケーションプログラム３０の動作ログ）及び時刻情報が含まれる。write情報受信部５５は、取得されたwrite情報を書込判定部５６に渡す。

書込判定部５６は、write情報受信部５５から渡されたwrite情報を取得する。書込判定部５６は、取得されたwrite情報に基づいて、当該write情報に含まれる書込みデータを複製アプリケーションログファイル９０に書き込むか否かを判定する。このとき、書込判定部５６は、ログ対応情報テーブル５４を参照して判定処理を実行する。

書込判定部５６は、取得されたwrite情報に含まれる書込み先ログファイル情報（ログファイル情報）に対応付けてログ対応情報テーブル５４に保持されている状態が開始であれば、当該書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている機能単位情報及び当該write情報に含まれる時刻情報を、当該write情報に含まれる書込みデータに付加する。

また、書込判定部５６は、取得されたwrite情報に含まれる書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている状態が停止であれば、当該write情報に含まれる時刻情報のみを、当該write情報に含まれる書込みデータに付加する。

書込判定部５６は、取得されたwrite情報に含まれている書込みデータを書込み処理部５７に渡す。

書込処理部５７は、書込判定部５６から渡された書込みデータを取得する。この書込みデータには、上記したように機能単位情報及び時刻情報（または時刻情報のみ）が付加されている。書込処理部５７は、取得された書込みデータをオペレーティングシステム６０に対して出力することにより、当該書込みデータを複製アプリケーションログファイル９０に書き込む処理を実行する。オペレーティングシステム６０に含まれるwriteシステムコールは、書込処理部５７によって出力された書込みデータを複製アプリケーションログファイル９０に書き込む。このとき、例えば複製アプリケーションログファイル９０が存在しない（つまり、作成されていない）場合には、当該複製アプリケーションログファイル９０が作成される。

つまり、複製アプリケーションログファイル９０には、例えば機能単位情報及び時刻情報（または時刻情報のみ）が付加されたアプリケーションプログラム３０の動作ログ（書込みデータ）が書き込まれる。

図１１は、図１０に示すログ対応情報テーブル５４のデータ構造の一例を示す。図１１に示すように、ログ対応情報テーブル５４には、機能単位情報、ログファイル情報及び状態が保持される。上記したように、ログ対応情報テーブル５４は、ログ対応情報受信部５１によって取得（受信）されたログ対応情報、制御情報受信部５２によって取得（受信）された制御情報及び再起動情報に応じて更新される。

図１１に示す例では、ログ対応情報テーブル５４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＡ」及び状態「開始」が保持されている。これによれば、「機能単位１」によって表される機能単位をなすアプリケーションプログラム３０の動作ログが出力されるアプリケーションログファイル８０は「ログファイルＡ」であり、当該機能単位の状態が「開始状態」（つまり、開始されている）ことが示される。

また、ログ対応情報テーブル５４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＢ」及び状態「開始」が保持されている。同様に、ログ対応情報テーブル５４には、機能単位情報「機能単位２」、ログファイル情報「ログファイルＣ」及び状態「停止」が保持されている。

次に、図１２のフローチャートを参照して、コンピュータ１０のアプリケーションプログラム３０が動作ログを出力する際の処理手順について説明する。

なお、ジャケットライブラリ４０に含まれるファイル名対応テーブル４２には、上記したようにopenフック部４１によってファイル識別子及びファイル名が既に登録されているものとする。

また、ログ管理マネージャ５０に含まれるログ対応情報テーブル５４は、上記したようにログ対応情報管理部５３によって更新されている（つまり、機能単位情報、ログファイル情報及び状態が保持されている）ものとする。

まず、アプリケーションプログラム３０は、動作ログ（書込みデータ）を出力するために、オペレーティングシステム６０のwriteシステムコールを実行する（ステップＳ１）。

アプリケーションプログラム３０は、writeシステムコールが実行されると、書込みデータ及び当該書込みデータが出力される（書き込まれる）アプリケーションログファイル８０を識別するためのファイル識別子を含むwrite要求をオペレーティングシステム６０に対して出力する（ステップＳ２）。

次に、ジャケットライブラリ４０に含まれるwriteフック部４３は、アプリケーションプログラム３０から出力されたwrite要求をフックする（ステップＳ３）。

write情報送信部４４は、write要求フック部４３によってフックされたwrite要求に含まれるファイル識別子に対応付けてファイル名対応テーブル４２に保持されているファイル名を取得する。また、write情報送信部４４は、現在時刻を示す時刻情報をオペレーティングシステム６０に対して要求することにより、当該時刻情報を取得する。

write情報送信部４４は、取得されたファイル名（書込み先ログファイル情報）、writeフック部４３によってフックされたwrite要求に含まれるアプリケーションプログラム３０の動作ログ（書込みデータ）及び取得された時刻情報を含むwrite情報をログ管理マネージャ５０に対して出力（送信）する（ステップＳ４）。

ログ管理マネージャ５０に含まれるwrite情報受信部５５は、ジャケットライブラリ４０（に含まれるwrite情報送信部４４）によって出力されたwrite情報を取得（受信）する。

書込判定部５６は、write情報受信部５５によって取得されたwrite情報に基づいて、当該write情報に含まれる書込みデータを複製アプリケーションログファイル９０に書き込むか否かの判定処理を実行する（ステップＳ５）。このとき、書込判定部５６は、ログ対応情報テーブル５４を参照して判定処理を実行する。この書込判定部５６の処理の詳細については後述する。

書込判定部５６は、書込みデータを複製アプリケーションログファイル９０に書き込むと判定された場合、write情報受信部５５によって取得されたwrite情報に含まれる書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている状態に応じて機能単位情報及び時刻情報（または時刻情報のみ）を当該書込みデータに付加する。

書込処理部５７は、書込判定部５６によって機能単位情報及び時刻情報（または時刻情報のみ）が付加された書込みデータを、オペレーティングシステム６０（に含まれるwriteシステムコール）を介して複製アプリケーションログファイル９０に書き込む（ステップＳ６）。

次に、図１３のフローチャートを参照して、上記したログ管理マネージャ５０に含まれる書込判定部５６の処理手順について説明する。

まず、書込判定部５６は、write情報受信部５５から渡されたwrite情報を取得する（ステップＳ１１）。このwrite情報には、書込み先ログファイル情報、書込みデータ及び時刻情報が含まれる。

次に、書込判定部５６は、取得されたwrite情報に含まれる書込み先ログファイル情報がログ対応情報テーブル５４に保持されているか否かを判定する（ステップＳ１２）。

書込み先ログファイル情報がログ対応情報テーブル５４に保持されていると判定された場合（ステップＳ１２のＹＥＳ）、書込判定部５６は、当該書込み先ログファイル情報に対応付けて当該ログ対応情報テーブル５４に保持されている状態が「開始」であるか否かを判定する（ステップＳ１３）。

書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている状態が「開始」であると判定された場合（ステップＳ１３のＹＥＳ）、書込判定部５６は、取得されたwrite情報に含まれる書込みデータに、当該書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている機能単位情報及び取得されたwrite情報に含まれる時刻情報を付加する（ステップＳ１４）。

書込判定部５６は、ステップＳ１４において機能単位情報及び時刻情報が付加された書込みデータを書込処理部５７に渡す（ステップＳ１５）。

これにより、書込処理部５７は、オペレーティングシステム６０（に含まれるwriteシステムコール）を介して、機能単位情報及び時刻情報が付加された書込みデータを複製アプリケーションログファイル９０に書き込む。

一方、ステップＳ１２において書込み先ログファイル情報がログ対応情報テーブル５４に保持されていないと判定された場合、処理は終了される。

また、ステップＳ１３において書込み先ログファイル情報に対応付けてログ対応情報テーブル５４に保持されている状態が「開始」でない、つまり、「停止」であると判定された場合、書込判定部５６は、取得されたwrite情報に含まれる書込みデータに、当該write情報に含まれる時刻情報を付加する（ステップＳ１６）。

この場合、書込判定部５６は、ステップＳ１６において時刻情報が付加された書込みデータを書込処理部５７に渡す（ステップＳ１５）。これにより、書込処理部５７は、オペレーティングシステム６０（に含まれるwriteシステムコール）を介して、時刻情報のみが付加された書込みデータを複製アプリケーションログファイル９０に書き込む。

ここで、図１４は、例えばクラスタソフトウェアログファイル７０に書き込まれたくラスタソフトウェア２０のログ及び複製アプリケーションログファイル９０に書き込まれた書込みデータ（つまり、アプリケーションプログラム３０の動作ログ）のつき合わせのイメージの一例を示す。

上述したように、クラスタソフトウェアログファイル７０に書き込まれているクラスタソフトウェア２０のログには、クラスタソフトウェア２０によって管理される機能単位を表す機能単位情報及び当該クラスタソフトウェア２０のログ（当該機能単位で出力されたログ）が出力された時刻（を示す時刻情報）が付加されている。

また、上記したように、複製アプリケーションログファイル９０に書き込まれた書込みデータには、機能単位を表す機能単位情報及び時刻情報が付加されている。なお、複製アプリケーションログファイル９０においては、例えば停止状態であるアプリケーションプログラム３０の動作ログ（書込みデータ）には時刻情報のみが付加されている。

図１４に示す例では、例えば複数のコンピュータ１０に含まれるコンピュータ１において機能単位情報「機能単位１」によって表される機能単位が提供されており、当該コンピュータ１において障害が検出されたことにより、当該機能単位がコンピュータ２において提供された場合の書込みデータ、つまり、機能単位をなすアプリケーションプログラム３０の動作ログが示されている。

図１４に示すように、コンピュータ１及びコンピュータ２の複製アプリケーションログファイル９０とクラスタソフトウェアログファイル７０に書き込まれているログには、機能単位を表す機能単位情報（例えば、機能単位１）が付加されている。

これにより、この機能単位情報（一意の情報）を用いることで、例えばアプリケーションプログラム３０によって出力されるログとクラスタソフトウェ２０によって出力されるログを容易につき合わせることができる。同様に、機能単位情報を用いることで、クラスタシステムにおける複数のコンピュータ１０（ここでは、コンピュータ１及び２）にまたがったログ（書込みデータ）を容易につき合わせることが可能となる。更に、時刻情報を用いることで、出力された順でのログの参照が可能になる。

上記したように本実施形態においては、アプリケーションプログラム３０のログ（動作ログ）がアプリケーションログファイル８０に出力される際に、当該ログにクラスタシステムによって提供される機能単位を表す機能単位情報を付加して複製アプリケーションログファイル９０に書き込む。つまり、クラスタソフトウェアログファイル７０に書き込まれているログ及び複製アプリケーションログファイル９０に書き込まれているログには、一意の情報（機能単位情報）が付加されているため、当該クラスタソフトウェアログファイル７０及び複製アプリケーションログファイル９０を参照することで、アプリケーションプログラム３０のログとクラスタソフトウェア２０のログとのつき合わせが容易にできる。これにより、例えばクラスタシステムにおいて障害が発生した際に、当該クラスタシステムにおいて提供される機能単位でのログ解析（障害解析）が容易になる。

また、本実施形態においては、上記したように機能単位情報が付加されたアプリケーションプログラム３０のログが複製アプリケーションログファイル９０に書き込まれるため、例えばクラスタシステムを構成する複数のコンピュータ１０上のアプリケーションプログラム３０のログ（つまり、複製アプリケーションログファイル９０に書き込まれている書込みデータ）を容易につき合わせることができる。これにより、クラスタシステムにおいて提供される機能単位でのログ解析が容易になる。

また、本実施形態においては、アプリケーションプログラム３０のログに時刻情報を付加することで、例えばどのようなアプリケーションプログラム３０のログであっても時間での順序付けができる。したがって、クラスタシステムにおいて提供される機能単位でのログ解析が容易になる。

［第２の実施形態］
次に、図１５を参照して、本発明の第２の実施形態について説明する。図１５は、本実施形態に係るコンピュータの主として機能構成を示すブロック図である。なお、前述した図２と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図２と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。

図１５に示すように、コンピュータ１００上では、ログ管理マネージャ５００が動作する。本実施形態においては、前述した第１の実施形態におけるジャケットライブラリ４０のようにアプリケーションプログラム３０によって出力される動作ログの書き込み（つまり、アプリケーションログファイル８０の更新）を当該書き込み時に検出するのではなく、ログ管理マネージャ５００が定期的にアプリケーションログファイル８０の更新を監視（確認）することで当該ログの書き込みを検出する点が、前述した第１の実施形態とは異なる。つまり、本実施形態においては、アプリケーションプログラム３０の動作ログがアプリケーションログファイル８０に書き込まれた後に、当該動作ログの書き込みが検出される。

ログ管理マネージャ５００は、アプリケーションログファイル８０の更新を定期的に監視する。ログ管理マネージャ５００は、アプリケーションログファイル８０が更新されている場合、当該アプリケーションログファイル８０において更新されたアプリケーションプログラム３０の動作ログに必要な情報を付加し、当該ログを複製アプリケーションログファイル９０に書き込む機能を有する。

図１６は、図１５に示すログ管理マネージャ５００の主として機能構成を示すブロック図である。なお、前述した図１０と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１０と異なる部分について主に述べる。以下の各実施形態についても同様にして重複した説明を省略する。

図１６に示すように、ログ管理マネージャ５００は、更新情報取得部５０１を含む。更新情報取得部５０１は、上記したように定期的にアプリケーションログファイル８０を監視する。これにより、更新情報取得部５０１は、アプリケーションログファイル８０の更新を検出する。

この場合、更新情報取得部５０１は、例えばアプリケーションログファイル８０のサイズを記憶しておき、当該サイズの増加によって当該アプリケーションログファイル８０の更新を検出する。

更新情報取得部５０１は、アプリケーションログファイル８０の更新が検出された場合、当該更新された部分の更新データ（差分データ）を当該アプリケーションログファイル８０から取得する。この更新データは、アプリケーションログファイル８０の更新の際に、当該アプリケーションログファイル８０に書き込まれたアプリケーションプログラム３０の動作ログである。

また、更新情報取得部５０１は、アプリケーションログファイル８０の更新が検出された場合、例えばオペレーティングシステム６０から現在時刻を示す時刻情報を取得する。

更新情報取得部５０１は、更新が検出されたアプリケーションログファイル８０（監視対象のアプリケーションログファイル８０）のファイル名、取得された更新データ（アプリケーションプログラム３０の動作ログ）及び取得された時刻情報を含む情報を書込判定部５６に渡す。

なお、書込判定部５６に渡されたファイル名、更新データ及び時刻情報を含む情報は、前述した第１の実施形態におけるwrite情報に相当する。

上記した点以外については、前述した第１の実施形態と同様であるため、その詳しい説明を省略する。

上記したように本実施形態においては、前述した第１の実施形態と比較して、アプリケーションプログラム３０から出力されるwrite要求をフックする必要がないため、当該アプリケーションプログラム３０の動作に全く影響を与えることがない。つまり、本実施形態においては、例えばwrite要求をフックすることによるアプリケーションプログラム３０の処理遅延を解消することが可能となる。

［第３の実施形態］
次に、図１７を参照して、本発明の第３の実施形態について説明する。図１７は、本実施形態に係るコンピュータの主として機能構成を示すブロック図である。なお、本実施形態におけるログ管理マネージャ５００の構成は、前述した図１６と同様であるため、適宜図１６を用いて説明する。ここでは、前述した第２の実施形態におけるログ管理マネージャ５００と動作が異なる部分について主に説明する。

図１７に示すように、コンピュータ１１０上では、ログ構造ファイルシステム４１０及びログ管理マネージャ５００が動作する。

ログ構造ファイルシステム４１０は、オペレーティングシステム６０が有する機能の１つとして提供するものであり、アプリケーションログファイル８０内のデータ（アプリケーションログファイル８０に書き込まれるアプリケーションプログラム３０の動作ログ）を管理する機能を有する。

本実施形態においては、アプリケーションログファイル８０の更新の確認をアプリケーションログファイル８０自体ではなく、ログ構造ファイルシステム４１０に対して行う点が、前述した第２の実施形態とは異なる。また、本実施形態においては、アプリケーションログファイル８０が、例えば当該アプリケーションログファイル８０の更新された部分の更新データの情報（アプリケーションログファイル８０に書き込まれたアプリケーションプログラム３０の動作ログ及び更新時刻を示す時刻情報）をログとして持つログ構造ファイルシステム上にあることが、前述した第２の実施形態とは異なる。

ログ管理マネージャ５００に含まれる更新情報取得部５０１は、ログ構造ファイルシステム４１０に対して定期的にアプリケーションログファイル８０の更新の確認を行う。これにより、更新情報取得部５０１は、アプリケーションログファイル８０の更新が検出された場合には、当該更新された部分の更新データ（アプリケーションプログラム３０の動作ログ）及び当該更新された時刻（更新時刻）を示す時刻情報をログ構造ファイルシステム４１０から取得する。

上記した点以外については、前述した第２の実施形態と同様であるため、その詳しい説明を省略する。

上記したように本実施形態においては、前述した第２の実施形態と同様に、アプリケーションプログラム３０から出力されるwrite要求をフックする必要がないため、当該アプリケーションプログラム３０の処理遅延を解消することができる。

ここで、前述した第２の実施形態においては、例えばログ管理マネージャ５００がアプリケーションログファイル８０の更新を検出した後に時刻情報が取得されるため、実際の更新時刻（アプリケーションプログラム３０によって出力された動作ログがアプリケーションログファイル８０に書き込まれた時刻）と取得された時刻情報によって示される時刻とが、更新確認の時間間隔分ずれる可能性がある。

これに対して、本実施形態においては、前述した第２の実施形態と比較して、ログ構造ファイルシステム４１０がアプリケーションログファイル８０における更新データの情報（アプリケーションプログラム３０の動作ログ及び更新時刻を示す時刻情報）を保持しているため、アプリケーションプログラム３０から出力された動作ログ（複製アプリケーションログファイル９０に書き込まれる書込みデータ）に付加される時刻情報が実際の更新時刻と異なることを解消できる。

［第４の実施形態］
次に、図１８を参照して、本発明の第４の実施形態について説明する。図１８は、本実施形態に係るコンピュータの主として機能構成を示すブロック図である。なお、本実施形態におけるログ管理マネージャ５００の構成は、前述した図１６と同様であるため、適宜図１６を用いて説明する。ここでは、前述した第２の実施形態におけるログ管理マネージャ５００と動作が異なる部分について主に説明する。

図１８に示すように、コンピュータ１２０上では、デバイスドライバ４２０及びログ管理マネージャ５００が動作する。また、本実施形態においては、アプリケーションログファイル８０は、例えばハードディスクドライブ（ＨＤＤ）８００のような記憶装置に格納されているものとする。

デバイスドライバ４２０は、例えばアプリケーションログファイル８０が格納されているＨＤＤ８００を動作させるためのソフトウェアである。このデバイスドライバ４２０は、オペレーティングシステム６０に組み込まれる。

ログ管理マネージャ５００に含まれる更新情報取得部５０１は、デバイスドライバ４２０に対して定期的にアプリケーションログファイル８０の更新の確認を行う。このとき、更新情報取得部５０１は、更新確認要求をデバイスドライバ４２０に対して出力する。

ここで、図１９は、図１８に示すデバイスドライバ４２０の主として機能構成を示すブロック図である。

図１９に示すように、デバイスドライバ４２０は、更新検出部４２１、更新処理部４２２、更新情報管理部４２３、更新情報格納部４２４及び更新確認要求応答部４２５を含む。換言すれば、デバイスドライバ４２０は、更新検出部４２１、更新処理部４２２、更新情報管理部４２３及び更新確認要求応答部４２５というモジュールと、更新情報というデータから構成される。

更新検出部４２１は、例えばアプリケーションプログラム３０によって出力されたwrite要求を取得する。更新検出部４２１は、例えばオペレーティングシステム６０（に含まれるwriteシステムコール）を介してwrite要求を取得する。このwrite要求には、例えばアプリケーションプログラム３０の動作ログ（書込みデータ）及び当該書込みデータが書き込まれる物理的な位置を示すＨＤＤ８００のアドレス（アドレス情報）が含まれる。

更新検出部４２１は、write要求が取得されると、ＨＤＤ８００（に格納されるアプリケーションログファイル８０）に対する書き込み（つまり、アプリケーションログファイル８０の更新）を検出する。更新検出部４２１は、ＨＤＤ８００への書き込みが検出された場合、オペレーティングシステム６０から現在時刻を示す時刻情報を取得する。

更新検出部４２１は、取得されたwrite要求に含まれる書込みデータ、アドレス情報及び取得された時刻情報を含む追加要求を更新情報管理部４２３に出力する。

更新検出部４２１は、追加要求（書込みデータ、アドレス情報及び時刻情報）が更新情報管理部４２３に出力された後、取得されたwrite要求（に含まれる書込みデータ及びアドレス情報）を更新処理部４２２に渡す。

更新処理部４２２は、更新検出部４２１から渡されたwrite要求を取得する。更新処理部４２２は、取得されたwrite要求に含まれるアドレス情報に基づいて、書込みデータをＨＤＤ８００に格納されているアプリケーションログファイル８０に書き込む。これにより、更新処理部４２２は、アプリケーションログファイル８０を更新する。

更新情報管理部４２３は、更新検出部４２１からの追加要求を取得する。更新情報管理部４２３は、取得された追加要求に応じて、更新情報格納部４２４に更新情報を追加（格納）する。更新情報管理部４２３は、取得された追加要求に含まれる書込みデータ、アドレス情報及び時刻情報を更新情報として更新情報格納部４２４に追加する。

更新確認要求応答部４２５は、ログ管理マネージャ５００（に含まれる更新情報取得部５０１）からの更新確認要求を取得する。更新確認要求応答部４２５は、取得された更新確認要求を更新情報管理部４２３に渡す。

ここで、更新確認要求応答部４２５から更新確認要求を受けると、更新情報管理部４２３は、更新情報格納部４２４に格納されている更新情報を全て更新確認要求応答部４２５に返す。このとき、更新情報管理部４２３は、更新情報格納部４２４に格納されている更新情報を削除（クリア）する。

更新確認要求応答部４２５は、更新確認要求に対する応答として、更新情報管理部４２３からの更新情報をログ管理マネージャ５００に対して出力する。

このように、更新確認要求応答部４２５から更新情報が出力された場合、ログ管理マネージャ５００に含まれる更新情報取得部５０１は、当該更新情報を取得する。更新情報取得部５０１は、取得された更新情報に含まれるアドレス情報をもとにファイルシステムを解析する。これにより、更新情報取得部５０１は、取得された更新情報に含まれるアドレス情報をファイル名に変換する機能を有する。

更新情報取得部５０１は、変換されたファイル名、取得された更新情報に含まれる書込みデータ及び時刻情報を含む情報を書込判定部５６に渡す。

上記した点以外については、前述した第２及び第３の実施形態と同様であるためその詳しい説明を省略する。

上記したように本実施形態においては、前述した第３の実施形態と同様に、アプリケーションプログラム３０から出力されるwrite要求をフックする必要がないため、当該アプリケーションプログラム３０の処理遅延を解消することができる。

また、本実施形態においては、デバイスドライバ４２０から時刻情報を含む更新情報を取得するため、アプリケーションプログラム３０から出力された動作ログに付加される時刻情報が実際の更新時刻と異なることを解消できる。

なお、本実施形態においては、ログ管理マネージャ５００が定期的にデバイスドライバ４２０に対してアプリケーションログファイル８０の更新を確認するものとして説明したが、デバイスドライバ４２０に含まれる更新検出部４２１によってアプリケーションログファイル８０の更新が検出された際に、更新情報をログ管理マネージャ５００に対して通知する構成であっても構わない。つまり、アプリケーションログファイル８０の更新（書き込み）を検出する層をドライバ層にすることで、例えば前述した第１の実施形態と比較して、当該更新の検出が下位の層になるためアプリケーションプログラム３０の動作に与える影響を小さくすることができる。

［第５の実施形態］
次に、本発明の第５の実施形態について説明する。本実施形態においては、前述した図２に示すコンピュータ１０上で、クラスタソフトウェア２０に代えてクラスタソフトウェア２００、ジャケットライブラリ４０に代えてジャケットライブラリ４３０、ログ管理マネージャ５０に代えてログ管理マネージャ５１０が動作するものとする。なお、本実施形態においては、これら以外については便宜的に図２を用いて説明する。

ここで、コンピュータ１０上で動作するアプリケーションプログラム３０は、例えば少なくとも１つ以上のプロセスから構成される。例えばアプリケーションプログラム３０からなる機能単位が開始された際には、当該機能単位に対応するプロセスが実行される（立ち上がる）。また、アプリケーションプログラム３０の動作ログは、当該アプリケーションプログラム３０からなる機能単位に対応するプロセス（当該アプリケーションプログラム３０を構成するプロセス）から出力される。アプリケーションプログラム３０の動作ログを出力するプロセスは、当該動作ログをアプリケーションログファイル８０に書き込む（出力する）際には、オペレーティングシステム６０に含まれるwriteシステムコールを実行する。

以下、本実施形態におけるクラスタソフトウェア２００、ジャケットライブラリ４３０及びログ管理マネージャ５１０について説明する。

図２０は、本実施形態に係るコンピュータ１０に含まれるクラスタソフトウェア２００の主として機能構成を示すブロック図である。なお、前述した図４と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図４と異なる部分について主に述べる。以下の実施形態についても同様にして重複した説明を省略する。

クラスタソフトウェア２００は、プロセス識別子取得通知受信部２０１を含む。プロセス識別子取得通知受信部２０１は、後述するプロセス識別子取得通知をログ管理マネージャ５１０から受け取り、ＨＡクラスタ制御部２１にその旨を通知する機能を有する。

なお、本実施形態におけるＨＡクラスタ制御部２１では、アプリケーションプログラム３０（からなる機能単位）を開始した後、プロセス識別子取得通知受信部２０１からの通知を受けるまでは次の機能単位の開始は行わない。

図２１は、本実施形態に係るコンピュータ１０に含まれるジャケットライブラリ４３０の主として機能構成を示すブロック図である。なお、前述した図７と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図７と異なる部分について主に述べる。以下の実施形態についても同様にして重複した説明を省略する。

ジャケットライブラリ４３０は、プロセス識別子送信部４３１及びwrite情報送信部４３２を含む。

プロセス識別子送信部４３１は、アプリケーションプログラム３０を構成するプロセスを識別するためのプロセス識別子を取得する。プロセス識別子送信部４３１は、オペレーティングシステム６０に対して問い合わせることによりプロセス識別子を取得する。

ここで、ジャケットライブラリ４３０は、例えばアプリケーションプログラム３０からなる機能単位が開始された際に実行されるプロセスによってロードされる。プロセス識別子送信部４３１は、ジャケットライブラリ４３０がロードされたときに呼ばれ、ジャケットライブラリ４３０をロードしたプロセスを識別するためのプロセス識別子を取得する。

プロセス識別情報送信部４３１は、取得されたプロセス識別子（情報）をログ管理マネージャ５１０に対して送信する。

write情報送信部４３２は、write情報をログ管理マネージャ５１０に出力（送信）する際、当該アプリケーションプログラム３０の動作ログを出力したプロセス（オペレーティングシステム６０に含まれるwriteシステムコールを実行したプロセス）を識別するためのプロセス識別子を取得する。write情報送信部４３２は、オペレーティングシステム６０に問い合わせることにより、プロセス識別子を取得する。

これにより、write情報送信部４３２は、取得されたプロセス識別子を含むwrite情報をログ管理マネージャ５１０に対して出力（送信）する。

ここで、図２２は、write情報送信部４３２によって出力されるwrite情報のデータ構造の一例を示す。図２２に示すように、write情報送信部４３２によって出力されるwrite情報には、書込み先ファイル情報（ファイル名）、書込みデータ（アプリケーションプログラム３０の動作ログ）、時刻情報及びプロセス識別子（情報）が含まれる。

図２３は、本実施形態に係るコンピュータ１０に含まれるログ管理マネージャ５１０の主として機能構成を示すブロック図である。なお、前述した図１０と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図１０と異なる部分について主に述べる。以下の実施形態についても同様にして重複した説明を省略する。

図２３に示すように、ログ管理マネージャ５１０は、プロセス識別子受信部５１１、通知部５１２、ログ対応情報管理部５１３、ログ対応情報テーブル５１４、write情報受信部５１５及び書込判定部５１６を含む。

プロセス識別子受信部５１１は、上記したジャケットライブラリ４３０（に含まれるプロセス識別子送信部４３１）によって出力されたプロセス識別子（情報）を取得（受信）する。プロセス識別子受信部５１１は、取得されたプロセス識別子をログ対応情報管理部５１３に渡す。

通知部５１２は、プロセス識別子受信部５１１から呼ばれ、当該プロセス識別子受信部５１１がプロセス識別子を取得した旨（前述したプロセス識別子取得通知）をクラスタソフトウェア２００に対して通知する。

ログ対応情報管理部５１３は、プロセス識別子受信部５１１から渡されたプロセス識別子を取得する。ログ対応情報管理部５１３は、プロセス識別子が取得されると、ログ対応情報テーブル５１４を更新する。

ログ対応情報管理部５１３は、ログ対応情報テーブル５１４において、制御情報受信部５２から渡された制御情報に基づいて最後に状態が「開始」に更新された機能単位情報を特定する。ログ対応情報管理部５１３は、特定された機能単位情報に対応付けてプロセス識別子をログ対応情報テーブル５１４に保持させる（登録する）。これにより、ログ対応情報テーブル５１４は更新される。この特定された機能単位情報は、プロセス識別子受信部５１１から渡されたプロセス識別子によって識別されるプロセスに対応する機能単位を表す。

write情報受信部５１５は、ジャケットライブラリ４３０（に含まれるwrite情報送信部４３２）によって出力されたwrite情報を取得（受信）する。上記したように、このwrite情報には、書込み先ログファイル情報（ファイル名）、書込みデータ（アプリケーションプログラム３０の動作ログ）、時刻情報及びプロセス識別子が含まれる。write情報受信部５１５は、取得されたwrite情報を書込判定部５１６に渡す。

書込判定部５１６は、write情報受信部５１５から渡されたwrite情報を取得する。取得されたwrite情報に基づいて、当該write情報に含まれる書込みデータを複製アプリケーションログファイル９０に書き込むか否かを判定する。このとき、書込判定部５１６は、ログ対応情報テーブル５１４を参照して判定処理を実行する。書込判定部５１６は、この処理において書込みデータに機能単位情報及び時刻情報（または時刻情報のみ）を付加する。なお、書込判定部５１６の処理の詳細については後述する。

ここで、上記したようにクラスタソフトウェア２００（に含まれるＨＡクラスタ制御部２１）では、プロセス識別子取得通知を受けるまでは次の機能単位の開始は行わない。つまり、クラスタソフトウェア２００では、ログ対応情報テーブル５１４においてプロセス識別子の対応付けが行われるまで、同時に異なるプロセスが立ち上がらないように管理が行われる。したがって、対応付けの完了を表すプロセス識別子取得通知を受けると、クラスタソフトウェア２００では、次の機能単位が開始される。

図２４は、図２３に示すログ対応情報テーブル５１４のデータ構造の一例を示す。図２４に示すように、ログ対応情報テーブル５１４には、機能単位情報、ログファイル情報、状態及びプロセス識別子が保持される。プロセス識別子は、機能単位情報によって表される機能単位に対応するプロセス（つまり、当該機能単位が開始された際に実行されるプロセス）を識別する識別子である。

図２４に示す例では、ログ対応情報テーブル５１４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＡ」、状態「開始」及びプロセス識別子「１３３」が保持されている。これによれば、「機能単位１」によって表される機能単位に対応するプロセスがプロセス識別子「１３３」によって識別されるプロセスであることが示される。

また、ログ対応情報テーブル５１４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＢ」、状態「開始」及びプロセス識別子「１３３」が保持されている。同様に、ログ対応情報テーブル５１４には、機能単位情報「機能単位２」、ログファイル情報「ログファイルＣ」及び状態「停止」が保持されている。

なお、上記したようにプロセス識別子は、状態が「開始」である機能単位を表す機能単位情報に対応付けて保持されるので、状態が「停止」である場合にはプロセス識別子は保持されない。

また、図２４に示すように、機能単位情報（、ログファイル情報及び状態）に対応付けてログ対応情報テーブル５１４に保持されるプロセス識別子は、複数であっても構わない。

次に、図２５のフローチャートを参照して、本実施形態における書込判定部５１６の処理手順について説明する。

まず、前述した図１３に示すステップＳ１１〜ステップＳ１３に相当するステップＳ２１〜ステップＳ２４の処理が実行される。

ステップＳ２３において書込み先ログファイル情報に対応付けてログ対応情報テーブル５１４に保持されている状態が「開始」であると判定された場合、書込判定部５１６は、ステップＳ２１において取得されたwrite情報に含まれるプロセス識別子が当該書込み先ログファイル情報に対応付けてログ対応情報テーブル５１４に保持されているプロセス識別子と同一であるか否かを判定する（ステップＳ２４）。

同一であると判定された場合（ステップＳ２４のＹＥＳ）、前述した図１３に示すステップＳ１４及びステップＳ１５の処理に相当するステップＳ２５及びステップＳ２６の処理が実行される。

一方、同一でない、つまり、異なると判定された場合（ステップＳ２４のＮＯ）、前述した図１３に示すステップＳ１６の処理に相当するステップＳ２７の処理が実行される。ステップＳ２７の処理が実行されると、ステップＳ２６の処理が実行される。

本実施形態においては、例えば異なる機能単位に対応する異なるプロセスが同一のアプリケーションログファイル８０に当該機能単位をなすアプリケーションプログラム３０の動作ログを出力する場合を想定している。前述した第１〜第４の実施形態では、このような場合、異なる機能単位をなすアプリケーションプログラム３０動作ログであっても同一の機能単位情報が付加されて複製アプリケーションログファイル９０に書き込まれる場合がある。

これに対して、本実施形態においては、ジャケットライブラリ４３０によって出力されるwrite情報に含まれるプロセス識別子がログ対応情報テーブル５１４に保持されているプロセス識別子と同一である場合にのみ機能単位情報が書込みデータ（アプリケーションプログラム３０の動作ログ）に付加される。これにより、本実施形態においては、上記したような異なる機能単位に対応する異なるプロセスが同一のアプリケーションログファイル８０に当該機能単位をなすアプリケーションプログラム３０の動作ログを書き込む場合であっても、プロセス識別子によってプロセスを区別することで、当該動作ログを出力したプロセスに対応する機能単位を表す機能単位情報を書込みデータに付加することが可能となる。

［第６の実施形態］
次に、本発明の第６の実施形態について説明する。本実施形態に係るコンピュータの構成は、前述した第５の実施形態と同様であるため、適宜、図２０、図２１及び図２３を用いて説明する。

前述した第５の実施形態においてはプロセス識別子によってプロセスを区別したが、本実施形態においては、更に当該プロセスを構成するスレッドをスレッド識別子によって区別する点が当該第５の実施形態とは異なる。

ここで、アプリケーションプログラム３０を構成するプロセスは、１つ以上のスレッドから構成される。例えばアプリケーションプログラム３０からなる機能単位が開始された際には、当該機能単位に対応するスレッドが実行される。また、アプリケーションプログラム３０の動作ログは、当該機能単位に対応するスレッド（当該アプリケーションプログラム３０を構成するスレッド）から出力される。

以下、図２０、図２１及び図２３を用いて本実施形態に係るコンピュータ１０の構成について説明する。

まず、図２０を用いて、本実施形態に係るコンピュータ１０に含まれるクラスタソフトウェア２００について説明する。

クラスタソフトウェア２００に含まれるプロセス識別子取得通知受信部２０１は、後述するスレッド識別子取得通知をログ管理マネージャ５１０から受け取り、ＨＡクラスタ制御部２１にその旨を通知する機能を有する。なお、このスレッド識別子取得通知は、前述した第５の実施形態におけるプロセス識別子取得通知に相当するものであるため、その詳しい説明については省略する。

次に、図２１を用いて、本実施形態に係るコンピュータ１０に含まれるジャケットライブラリ４３０について説明する。

ジャケットライブラリ４３０に含まれるプロセス識別子送信部４３１は、プロセス識別子に加えて、更にスレッド識別子を取得する。プロセス識別子送信部４３１は、オペレーティングシステム６０に対して問い合わせることによりスレッド識別子及びプロセス識別子を取得する。

ここで、ジャケットライブラリ４３０は、例えばアプリケーションプログラム３０からなる機能単位が開始された際に実行されるスレッドによってロードされる。プロセス識別子送信部４３１は、ジャケットライブラリ４３０がロードされたときに呼ばれ、ジャケットライブラリ４３０をロードしたスレッドを識別するためのスレッド識別子及び当該スレッドから構成されるプロセスを識別するためのプロセス識別子を取得する。

プロセス識別子情報送信部４３１は、取得されたスレッド識別子及びプロセス識別子をログ管理マネージャ５１０に対して送信する。

ジャケットライブラリ４３０に含まれるwrite情報送信部４３２は、write情報をログ管理マネージャ５１０に出力（送信）する際、アプリケーションプログラム３０の動作ログを出力したスレッドを識別するためのスレッド識別子及び当該スレッドから構成されるプロセスを識別するためのプロセス識別子を取得する。write情報送信部４３２は、オペレーティングシステム６０に問い合わせることにより、スレッド識別子及びプロセス識別子を取得する。

write情報送信部４３２は、上記した書込み先ログファイル情報、アプリケーションプログラム３０の動作ログ及び時刻情報に加えて、取得されたスレッド識別子及びプロセス識別子を含むwrite情報をログ管理マネージャ５１０に対して出力（送信）する。

次に、図２３を用いて、本実施形態に係るコンピュータ１０に含まれるログ管理マネージャ５１０について説明する。

ログ管理マネージャ５１０に含まれるプロセス識別子受信部５１１は、上記したジャケットライブラリ４３０（に含まれるプロセス識別子送信部４３１）によって出力されたスレッド識別子及びプロセス識別子を取得（受信）する。プロセス識別子受信部５１１は、取得されたスレッド識別子及びプロセス識別子をログ対応情報管理部５１３に渡す。

ログ管理マネージャ５１０に含まれる通知部５１２は、プロセス識別子受信部５１１から呼ばれ、当該プロセス識別子受信部５１１がスレッド識別子（及びプロセス識別子）を取得した旨（前述したスレッド識別子取得通知）をクラスタソフトウェア２００に対して通知する。

ログ管理マネージャ５１０に含まれるログ対応情報管理部５１３は、プロセス識別子受信部５１１から渡されたスレッド識別子及びプロセス識別子を取得する。ログ対応情報管理部５１３は、スレッド識別子及びプロセス識別子が取得されると、ログ対応情報テーブル５１４を更新する。

ログ対応情報管理部５１３は、ログ対応情報テーブル５１４において、制御情報受信部５２から渡された制御情報に基づいて最後に状態が「開始」に更新された機能単位情報を特定する。ログ対応情報管理部５１３は、特定された機能単位情報に対応付けてスレッド識別子及びプロセス識別子をログ対応情報テーブル５１４に保持させる（登録する）。これにより、ログ対応情報テーブル５１４は更新される。この特定された機能単位情報によって表される機能単位は、プロセス識別子受信部５１１から渡されたスレッド識別子によって識別されるスレッドに対応する機能単位である。

ログ管理マネージャ５１０に含まれるwrite情報受信部５１５は、ジャケットライブラリ４３０（に含まれるwrite情報送信部４３２）によって出力されたwrite情報を取得（受信）する。上記したように、このwrite情報には、書込み先ログファイル情報（ファイル名）、書込みデータ（アプリケーションプログラム３０の動作ログ）、時刻情報、スレッド識別子及びプロセス識別子が含まれる。write情報受信部５１５は、取得されたwrite情報を書込判定部５１６に渡す。

ログ管理マネージャ５１０に含まれる書込判定部５１６は、write情報受信部５１５から渡されたwrite情報に基づいて、当該write情報に含まれる書込みデータを複製アプリケーションログファイル９０に書き込むか否かを判定する。このとき、書込み判定部５１６は、ログ対応情報テーブル５１４を参照して判定処理を実行する。書込判定部５１６は、この処理において書込みデータに機能単位情報及び時刻情報（または時刻情報のみ）を付加する。なお、書込判定部５１６の処理の詳細については後述する。

図２６は、本実施形態におけるログ対応情報テーブル５１４のデータ構造の一例を示す。図２６に示すように、ログ対応情報テーブル５１４には、機能単位情報、ログファイル情報、状態、スレッド識別子及びプロセス識別子が保持される。スレッド識別子は、機能単位情報によって表される機能単位に対応するスレッドを識別するための識別子である。プロセス識別子は、スレッド識別子によって識別されるスレッドから構成されるプロセスを識別するための識別子である。

図２６に示す例では、ログ対応情報テーブル５１４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＡ」、状態「開始」、スレッド識別子「３０」及びプロセス識別子「１３３」が保持されている。これによれば、「機能単位１」によって表される機能単位に対応するスレッドがスレッド識別子「３０」によって識別されるスレッドであることが示される。また、スレッド識別子「３０」によって識別されるスレッドから構成されるプロセスがプロセス識別子「１３３」によって識別されるプロセスであることが示される。

また、ログ対応情報テーブル５１４には、機能単位情報「機能単位１」、ログファイル情報「ログファイルＢ」、状態「開始」、スレッド識別子「３０」及びプロセス識別子「１３３」が保持されている。同様に、ログ対応情報テーブル５１４には、機能単位情報「機能単位２」、ログファイル情報「ログファイルＣ」及び状態「停止」が保持されている。

なお、上記したようにスレッド識別子及びプロセス識別子は、状態が「開始」である機能単位を表す機能単位情報に対応付けて保持されるので、状態が「停止」である場合にはスレッド識別子及びプロセス識別子は保持されない。

次に、図２７のフローチャートを参照して、本実施形態における書込判定部５１６の処理手順について説明する。

まず、前述した図２５に示すステップＳ２１〜ステップＳ２４に相当するステップＳ３１〜ステップＳ３４の処理が実行される。

ここで、ステップＳ３１において取得されたwrite情報に含まれるプロセス識別子が当該write情報に含まれる書込み先ログファイル情報に対応付けてログ対応情報テーブル５１４に保持されているプロセス識別子と同一であると判定された場合を想定する（ステップＳ３４のＹＥＳ）。この場合、書込判定部５１６は、取得されたwrite情報に含まれるスレッド識別子が当該write情報に含まれる書込み先ログファイル情報に対応付けてログ対応情報テーブル５１４に保持されているスレッド識別子と同一であるか否かを判定する（ステップＳ３５）。

同一であると判定された場合（ステップＳ３５のＹＥＳ）、前述した図２５に示すステップＳ２５及びステップＳ２６の処理に相当するステップＳ３６及びステップＳ３７の処理が実行される。

一方、同一でない、つまり、異なると判定された場合（ステップＳ３５のＮＯ）、前述した図２５に示すステップＳ２７の処理に相当するステップＳ３８の処理が実行される。ステップＳ３８の処理が実行されると、ステップＳ３７の処理が実行される。

本実施形態においては、例えば異なる機能単位に対応する異なるスレッドが同一のアプリケーションログファイル８０に当該機能単位をなすアプリケーションプログラム３０の動作ログを出力する場合を想定している。前述した第５の実施形態では、例えば異なるスレッドが同一のアプリケーションログファイル８０にアプリケーションプログラム３０の動作ログを出力した場合であっても、当該異なるスレッドから構成されるプロセスが同一である場合には、異なる機能単位をなすアプリケーションプログラム３０の動作ログであっても同一の機能単位情報が付加されて複製アプリケーションログファイル９０に書き込まれる場合がある。

これに対して、本実施形態においては、ジャケットライブラリ４３０によって出力されるwrite情報に含まれるスレッド識別子がログ対応情報テーブル５１４に保持されているスレッド識別子と同一である場合にのみ機能単位情報が書込みデータ（アプリケーションプログラム３０の動作ログ）に付加される。これにより、本実施形態においては、上記したような異なる機能単位に対応する異なるスレッドが同一のプロセスを構成し、かつ、同一のアプリケーションログファイル８０に当該機能単位をなすアプリケーションプログラム３０の動作ログを書き込む場合であっても、スレッド識別子によってスレッドを区別することで、当該動作ログを出力したスレッドに対応する機能単位を表す機能単位情報を書込みデータに付加することが可能となる。

また、本実施形態においては、プロセス識別子を用いてプロセスも区別するので、例えばプロセスは異なるがスレッド識別子が同一であるような場合であっても、スレッド識別子及びプロセス識別子を用いることでスレッドを区別することが可能となる。

なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、各実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。

本発明の第１の実施形態に係るコンピュータを備えるクラスタシステムのハードウェア構成を示すブロック図。 図１に示すコンピュータ１０の主として機能構成を示すブロック図。 クラスタシステムにおいて提供される機能単位について説明するための図。 図２に示すクラスタソフトウェア２０の主として機能構成を示すブロック図。 ログ対応情報登録部２２によって出力されるログ対応情報のデータ構造の一例を示す図。 制御情報送信部２３によって出力される制御情報のデータ構造の一例を示す図。 図２に示すジャケットライブラリ４０の主として機能構成を示すブロック図。 図７に示すファイル名対応テーブル４２のデータ構造の一例を示す図。 write情報送信部４４によって送信されるwrite情報のデータ構造の一例を示す図。 図２に示すログ管理マネージャ５０の主として機能構成を示すブロック図。 図１０に示すログ対応情報テーブル５４のデータ構造の一例を示す図。 コンピュータ１０のアプリケーションプログラム３０が動作ログを出力する際の処理手順を示すフローチャート。 ログ管理マネージャ５０に含まれる書込判定部５６の処理手順を示すフローチャート。 クラスタソフトウェアログファイル７０及び複製アプリケーションログファイル９０のつき合わせのイメージの一例を示す図。 本発明の第２の実施形態に係るコンピュータの主として機能構成を示すブロック図。 図１５に示すログ管理マネージャ５００の主として機能構成を示すブロック図。 本発明の第３の実施形態に係るコンピュータの主として機能構成を示すブロック図。 本発明の第４の実施形態に係るコンピュータの主として機能構成を示すブロック図。 図１８に示すデバイスドライバ４２０の主として機能構成を示すブロック図。 本発明の第５の実施形態に係るコンピュータに含まれるクラスタソフトウェア２００の主として機能構成を示すブロック図。 本実施形態に係るコンピュータに含まれるジャケットライブラリ４３０の主として機能構成を示すブロック図。 本実施形態におけるwrite情報送信部４３２によって出力されるwrite情報のデータ構造の一例を示す図。 本実施形態に係るコンピュータに含まれるログ管理マネージャ５１０の主として機能構成を示すブロック図。 図２３に示すログ対応情報テーブル５１４のデータ構造の一例を示す図。 本実施形態における書込判定部５１６の処理手順を示すフローチャート。 本発明の第６の実施形態におけるログ対応情報テーブル５１４のデータ構造の一例を示す図。 本実施形態における書込判定部５１６の処理手順を示すフローチャート。

符号の説明

１０，１００，１１０，１２０…コンピュータ、２０…クラスタソフトウェア、２１…ＨＡクラスタ制御部、２２…ログ対応情報登録部、２３…制御情報送信部、３０…アプリケーションプログラム、４０，４３０…ジャケットライブラリ、４１…openフック部、４２…ファイル名対応テーブル、４３…writeフック部、４４，４３２…write情報送信部、５０，５００，５１０…ログ管理マネージャ、５１…ログ対応情報受信部、５２…制御情報受信部、５３，５１３…ログ対応情報管理部、５４，５１４…ログ対応情報テーブル、５５，５１５…write情報受信部、５６，５１６…書込判定部、５７…書込処理部、６０…オペレーティングシステム、７０…クラスタソフトウェアログファイル、８０…アプリケーションログファイル（第１のログファイル）、９０…複製アプリケーションログファイル（第２のログファイル）、２０１…プロセス識別子取得通知受信部、４１０…ログ構造ファイルシステム、４２０…デバイスドライバ、４２１…更新検出部、４２２…更新処理部、４２３…更新情報管理部、４２４…更新情報格納部、４２５…更新確認要求応答部、４３１…プロセス識別子送信部、５０１…更新情報取得部、５１１…プロセス識別子受信部、５１２…通知部、８００…ハードディスクドライブ（ＨＤＤ）。

Claims (5)

1. 一の機能単位をなす一つ又は複数のアプリケーションのログが、当該アプリケーション毎に異なる第１のログファイルに出力される情報処理装置において、
   前記機能単位を表す機能単位情報及び当該機能単位をなすアプリケーションのログが出力される第１のログファイルを示すログファイル情報を対応付けて保持するテーブルと、
   前記機能単位の状態を取得する状態取得手段と、
   前記状態取得手段によって取得された機能単位の状態を、当該機能単位を表す機能単位情報に対応付けて前記テーブルに保持させるログ対応情報管理手段と、
   前記ログ及び当該ログが出力される第１のログファイルを示すログファイル情報を取得するログ取得手段と、
   前記ログ取得手段によって取得されたログファイル情報が前記テーブルに保持されているかを判定する判定手段と、
   前記ログファイル情報が前記テーブルに保持されていると判定された場合、当該ログファイル情報に対応付けて保持されている機能単位の状態に応じて、当該ログファイル情報に対応付けて当該テーブルに保持されている機能単位情報を前記ログ取得手段によって取得されたログに付加して、前記第１のログファイルとは異なる第２のログファイルに書き込む書込手段と
   を具備することを特徴とする情報処理装置。
2. 前記ログ取得手段は、前記ログ及び当該ログが出力される第１のログファイルを示すログファイル情報が取得された時刻を示す時刻情報を更に取得し、
   前記書込処理手段は、前記ログ取得手段によって取得されたログに、当該ログ取得手段によって取得された時刻情報を付加して前記第２のログファイルに書き込む
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記状態取得手段は、前記機能単位の状態として、当該機能単位が開始したことを示す開始状態及び当該機能単位が停止したことを示す停止状態を取得し、
   前記書込処理手段は、
   前記ログファイル情報が前記テーブルに保持されていると判定された場合であって、当該ログファイル情報に対応付けて保持されている機能単位の状態が前記開始状態である場合には、当該ログファイル情報に対応付けて当該テーブルに保持されている機能単位情報及び前記ログ取得手段によって取得された時刻情報を当該ログ取得手段によって取得されたログに付加して前記第２のログファイルに書き込み、
   前記ログファイル情報が前記テーブルに保持されていると判定された場合であって、当該ログファイル情報に対応付けて保持されている機能単位の状態が前記停止状態である場合には、前記ログ取得手段によって取得された時刻情報を当該ログ取得手段によって取得されたログに付加して前記第２のログファイルに書き込む
   ことを特徴とする請求項２記載の情報処理装置。
4. 前記機能単位に対応し、当該アプリケーションを構成するプロセスを識別するためのプロセス識別子を取得するプロセス識別子取得手段を更に具備し、
   前記ログ対応情報管理手段は、前記プロセス識別子取得手段によって取得されたプロセス識別子を、前記状態取得手段によって取得された機能単位の状態、当該機能単位を表す機能単位情報及び当該機能単位をなすアプリケーションのログが出力される第１のログファイルを示すログファイル情報に対応付けて前記テーブルに保持させ、
   前記ログ取得手段は、前記ログ及び当該ログが出力される第１のログファイルを示すログファイル情報に加えて、当該機能単位に対応するプロセスを識別するためのプロセス識別子を更に取得し、
   前記判定手段は、前記ログ取得手段によって取得されたログファイル情報及びプロセス識別子が対応付けて前記テーブルに保持されているかを判定し、
   前記書込処理手段は、前記ログファイル情報及び前記プロセス識別子が対応付けて前記テーブルに保持されていると判定された場合、当該ログファイル情報及び当該プロセス識別子に対応付けて保持されている機能単位の状態に応じて、当該ログファイル情報及び当該プロセス識別子に対応付けて当該テーブルに保持されている機能単位情報を前記ログ取得手段によって取得されたログに付加して、前記第２のログファイルに書き込む
   ことを特徴とする請求項１記載の情報処理装置。
5. 一の機能単位をなす一つ又は複数のアプリケーションのログが、当該アプリケーション毎に異なる第１のログファイルに出力され、前記機能単位を表す機能単位情報及び当該機能単位をなすアプリケーションのログが出力される第１のログファイルを示すログファイル情報を対応付けて保持するテーブルを備える情報処理装置のコンピュータによって実行されるプログラムであって、
   前記コンピュータに、
   前記機能単位の状態を取得するステップと、
   前記取得された機能単位の状態を、当該機能単位を表す機能単位情報に対応付けて前記テーブルに保持させるステップと、
   前記ログ及び当該ログが出力される第１のログファイルを示すログファイル情報を取得するステップと、
   前記取得されたログファイル情報が前記テーブルに保持されているかを判定するステップと、
   前記ログファイル情報が前記テーブルに保持されていると判定された場合、当該ログファイル情報に対応付けて保持されている機能単位の状態に応じて、当該ログファイル情報に対応付けて当該テーブルに保持されている機能単位情報を前記取得されたログに付加して、前記第１のログファイルとは異なる第２のログファイルに書き込むステップと
   を実行させるためのプログラム。

Images