ログ管理システム、ログ管理方法、アプリケーションサーバ、およびログサーバ
【課題】複数のユーザからの要求に応じて並行して処理を行うシステムにおいて、重複したログの保存を防止し、かつ、ログの記録漏れを避ける。
【解決手段】アプリケーションサーバ１０２は、ログを収集してログサーバに送信する１以上のログデータ収集手段３２２１と、前記１以上のログデータ収集手段を一意に特定するための識別子を生成してログサーバ１０３に提供する提供手段３２２５とを有し、前記ログサーバは、受信したログに対応付けられた前記識別子とすでに記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶する。
【解決手段】アプリケーションサーバ１０２は、ログを収集してログサーバに送信する１以上のログデータ収集手段３２２１と、前記１以上のログデータ収集手段を一意に特定するための識別子を生成してログサーバ１０３に提供する提供手段３２２５とを有し、前記ログサーバは、受信したログに対応付けられた前記識別子とすでに記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶する。
【発明の詳細な説明】
【技術分野】
【０００１】
クラウド環境における、ログの管理を行うログ管理システム、ログ管理方法、アプリケーションサーバ、およびログサーバに関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングシステムと呼ばれる技術が注目を集めている。クラウドコンピューティングシステムにおいて、クラウドサービスベンダーは、インターネット上に、仮想的なサーバ（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）やストレージ、また種々のサービスを提供する。アプリケーション開発者は、クラウドサービスベンダーに利用料を支払い、それらのサービスを使用することで、クラウドアプリケーションの開発が可能となる。
【０００３】
ここで、クラウドコンピューティングシステムにおける、ログの管理方法について考える。クラウドサービスでは、複数のサーバ（ＶＭ）上でサービスが提供されており、それぞれのサービスで、ログが出力される。特許文献１では、サーバ上に実装されたクライアントが、各サーバ上で出力されたログをログ管理サーバに送信する。これにより、ログの一元的な管理が可能となり、ログの集計や、表示、出力といった作業のパフォーマンス、および効率を上げることが出来る。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−０７２９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
クラウドサービスのように、多くのユーザが使用し、かつ、異なる人物が、同じユーザＩＤ（アカウント）等を用いてログイン可能なシステムを考える。このとき、各ユーザが同一のイベント（例えば、プリント等）の処理を行うことが可能であるため、イベントを特定する項目からのみでは、収集したログが、すでに保持管理しているログと重複しているかどうかの判断はできない。
【０００６】
また、あるクライアントがログを送信できない状態に陥っている場合に、サーバがログの集計を行うと、あるクライアントから集めるべきログが収集できないため、その間のログの記録漏れが発生する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本願発明は以下の構成を有する。すなわち、ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムであって、前記アプリケーションサーバは、ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段とを有し、前記ログサーバは、前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理システム。
【発明の効果】
【０００８】
本発明により、複数のユーザからの要求に応じて並行して処理を行うシステムにおいて、処理を行った結果としてのログに対し、重複したログの保存を防止し、かつ、ログの記録漏れを避けることが可能となる。
【図面の簡単な説明】
【０００９】
【図１】システム構成図。
【図２】アプリケーションサーバ１０２のハードウェア構成図。
【図３】機能ブロック図。
【図４】ログ収集部の設定ファイルの記述例を示す図。
【図５】ログフィルタのＩ／ＦおよびＬｏｇＤａｔａクラスの定義例を示す図。
【図６】ＩＤファイルの記述例を示す図。
【図７】レコードを初期登録した際のレコードファイルの記述例を示す図。
【図８】ログＤＢの構成例を示す図。
【図９】ステータスＤＢの構成例を示す図。
【図１０】アーカイブアプリケーションの設定ファイルの記述例を示す図。
【図１１】ログ収集部の起動、およびＩＤファイルの作成に関するフローチャート。
【図１２】ログ収集部のログ収集に関するフローチャート。
【図１３】バッチアプリケーションサーバのログ出力に関するフローチャート。
【図１４】フェールオーバー時のアプリケーションサーバの処理のフローチャート
【発明を実施するための形態】
【００１０】
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。
【００１１】
［システム構成］
図１は、本発明の一実施形態に係るログ管理システムの全体構成を示している。ネットワーク１００を介して、ＰＣ１０１、アプリケーションサーバ１０２、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５が接続されている。アプリケーションサーバ１０２は、ＰＣ１０１からのネットワーク１００を介して送信されるリクエストを受信し、処理を行う。ログサーバ１０３は、アプリケーションサーバ１０２から送信されるログを受信し、ストレージサーバ１０４に保存させる機能、および、バッチアプリケーションサーバ１０５からのログデータの出力要求を受信し、該当の処理を行う機能を備える。ストレージサーバ１０４は、ログサーバ１０３が収集したログを保存する。
【００１２】
ネットワーク１００は、上述の各装置間での情報をやりとりのための通信回線として働き、有線、無線と回線の形態は問わない。また、ネットワーク１００は、インターネットなどの外部ネットワークやＬＡＮなどの内部ネットワークを組み合わせて構成されるものとする。
【００１３】
また、図１において、２台のアプリケーションサーバ１０２を示しているが、これに限定するものではない。同様に各サーバも１台構成に限定するものではなく、複数台の物理的な構成を備えていても構わない。また、本実施形態において、各サーバを機能ごとに別個の装置として示しているが、単一の装置にて実現するようにしても構わない。例えば、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５を１台の装置にて構成するようにしても構わない。また、物理的に１台の装置において複数のＶＭが動作するように構成してもよいし、複数の物理的な装置が協働して複数のＶＭが動作するように構成してもよい。
【００１４】
［ハードウェア構成］
図２は、本発明の一実施形態に係るハードウェア構成を示している。なお、図１に示した各装置も同様の構成を有するものとし、ここではアプリケーションサーバ１０２を例にとって説明する。
【００１５】
アプリケーションサーバ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、直接記憶部２０２、間接記憶部２０３、およびネットワークインタフェース２０４を備える。ＣＰＵ２０１は、各記憶部に格納された所定のプログラムを実行し、アプリケーションサーバ１０２の各種制御を指示するユニットである。直接記憶部２０２は、ＣＰＵ２０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０１が実行するプログラムは直接記憶部２０２にロードされる。直接記憶部２０２は、ＲＡＭ（Ｒａｎｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部２０３は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。
【００１６】
間接記憶部２０３に記憶されている各種プログラムは、ＣＰＵ２０１がプログラムを実行する際に直接記憶部２０２へ読みだされる。間接記憶部２０３は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）、または、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２０１は、マルチプロセッサでも良い。また、アプリケーションサーバ１０２内の各構成要素は、内部バス（不図示）によって互いに通信可能なように接続されている。ネットワークインタフェース２０４は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。ＰＣ１０１、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５も同様のハードウェア構成をしているため、説明は割愛する。また、各装置は、ここに示していない構成要素を備えていても構わず、汎用的なコンピュータにて実現可能である。
【００１７】
［ソフトウェア構成］
図３は、本発明の一実施形態に係るシステムを構成する各装置の機能ブロック図（ソフトウェア構成）を示す。まず、ＰＣ１０１についての説明を行う。ＰＣ１０１は、ネットワーク通信部３１３、ユーザインタフェース３１２、ウェブブラウザ３１１から構成される。ユーザインタフェース３１２は、ユーザが、ＰＣ１０１によって提供される各種アプリケーション（不図示）を使用するためのインタフェースである。これを介して入力されるユーザ操作に従って、ＰＣ１０１は、各種アプリケーションを実行する。アプリケーションの１種であるウェブブラウザ３１１は、ネットワーク１００を介して、ネットワーク通信部３１３から送受信される情報に応じて、各種情報の表示を行う。
【００１８】
ウェブブラウザ３１１は、図２の間接記憶部２０３に保存されているプログラムが、直接記憶部２０２にロードされ、ＣＰＵ２０１により実行されることで実現される。本実施形態では、ＰＣ１０１を操作するユーザが、ユーザインタフェース３１２、ネットワーク通信部３１３を介してアプリケーションサーバ１０２のリクエスト処理部３２１１と通信を行い、データの送受信を行う。
【００１９】
次に、アプリケーションサーバ１０２上に実装されるアプリケーション部３２１に含まれるリクエスト処理部３２１１、ログファイル出力部３２１２、リクエスト処理部状態監視部３２１３に関して説明する。リクエスト処理部３２１１は、ＰＣ１０１からのリクエストを受信し、受信した内容に応じた処理を行う。例えば、アプリケーションサーバ１０２がオンライン上でのプリントサービスを実現しているとする。ユーザは、ＰＣ１０１を用いて印刷をする対象のドキュメントを選択し、また印刷設定などを指定し、アプリケーションサーバ１０２に対して、印刷処理のリクエストを送信する。アプリケーションサーバ１０２は、受信したリクエストに従ってドキュメントを印刷可能な形式に変換し、プリントサーバ（不図示）に送信するといった処理を行う。
【００２０】
ここでは、一例としてプリントシステムの例を述べたが、アプリケーションサーバ１０２にて実現される機能に制限は存在しない。リクエスト処理部３２１１は、一般的なＷｅｂサーバと同等の機能を持ち、同期処理を行うことが可能である。リクエスト処理部３２１１は、ネットワーク１００を介して、別のアプリケーションサーバ１０２と通信することも可能である。また、リクエスト処理部３２１１は、定期的にリクエスト処理部状態監視部３２１３に対して、動作中を表すパケットを送信する。
【００２１】
ログファイル出力部３２１２は、リクエスト処理部３２１１の処理内容に応じて、その処理のログをファイルに出力する。この際、出力されるログには、そのリクエストに対する処理が行われた時間が記録されている必要がある。その他の項目（例えば、ユーザカウントや、処理の内容に関するログ）に関しては、任意の項目を出力してもよい。ログのフォーマットに関する制約は特に存在せず、任意のフォーマット、例えばコンマ区切りやタブ区切り等、種々の形式での出力が可能である。また、処理内容やアプリケーションごとに、異なるファイルにログを出力することができる。
【００２２】
リクエスト処理部状態監視部３２１３は、リクエスト処理部３２１１から定期的にパケットが送信されてくるか否かを監視する。パケットが送信されてこなかった場合には、リクエスト処理部状態監視部３２１３は、リクエスト処理部３２１１が動作継続不能状態になっているものとし、フェールオーバーを行う。フェールオーバーのフローに関しては、図１４を用いて後述する。
【００２３】
次に、アプリケーションサーバ１０２上に実現されるログ収集エージェント部３２２に関して説明する。ログ収集エージェント部３２２は、複数の処理部（ログデータ収集部３２２１、ログデータ送信部３２２２、ステータス送信部３２２３、ログフィルタ部３２２４、およびＩＤ管理部３２２５）から構成される。以下に、各処理部の説明を記載する。
【００２４】
まず、ログデータ収集部３２２１は、ログファイル出力部３２１２がファイルに出力したログファイルから、ログを読み込む。前述したようにログファイル出力部３２１２は、任意のフォーマットで記述されたログをファイルに出力する。ストレージサーバ１０４のログＤＢ部３４１に定義されたスキーマに沿ってログを保存するためには、任意のフォーマットで記載されたログを、スキーマに従った形式に変換する必要がある。そこで、ログフィルタ部３２２４を用いて、ファイルに記載されたログのフォーマットを、スキーマに適する形式に変換する。
【００２５】
ログフィルタ部３２２４は、ログデータ収集部３２２１から渡されたログをスキーマに従った形式に変換し、ログデータ収集部３２２１に返す。ログフィルタ部３２２４が適切な形式に変換することにより、任意のフォーマットへの対応が可能となる。ログフィルタ部３２２４の詳細については図５を用いて説明する。ここで、１つのアプリケーションサーバ１０２には、複数のログ収集エージェント部３２２を動作させることが出来る。ログ収集エージェント部３２２は、設定ファイルを備え、それぞれに対して、収集対象とするログファイルの名前等を定義することが出来る。
【００２６】
また、ログフィルタ部３２２４も、それぞれに対して設定することが出来る。これにより、例えばログファイル出力部３２１２が複数のログファイルを、異なるフォーマットで出力する場合にも、対応することが出来る。
【００２７】
ログデータ収集部３２２１は、ログフィルタ部３２２４によって変換されたログデータを、ログデータ送信部３２２２に渡す。ログデータ送信部３２２２は、ログデータ収集部３２２１から渡された、ログデータをログＤＢリクエスト処理部３３１に送信する。ログＤＢリクエスト処理部３３１は、受信したログデータをログＤＢ部３４１に保存する。ログＤＢ部３４１に保存されるログデータには、時刻やログを発生させる処理を行ったユーザＩＤ、処理の内容等の情報が記載されており、それらの情報を基にユーザに対して、サービスの使用量に応じた請求をすることも可能である。ログＤＢ部３４１のスキーマについては後述する。
【００２８】
また、ログデータ収集部３２２１は、ログデータの送信処理が正常に終了した場合には、ステータス送信部３２２３に対して、ログファイルからログを収集した時刻を通知する。ステータス送信部３２２３は、その時刻をステータスＤＢリクエスト処理部３３３に送信する。この際、ログ収集エージェント部３２２を識別するための情報として、各ログ収集エージェント部に対して割り当てられたＩＤを対応付けて送信する。ステータスＤＢリクエスト処理部３３３は、受信したＩＤと時刻との組を、ストレージサーバ１０４のステータスＤＢ部３４２に保存する。このＩＤと時刻との組をステータスとして扱い、ステータスはステータスに含まれるＩＤを備えるログ収集エージェント部３２２が何時までのログを保存しているかを示す情報となる。
【００２９】
また、ログ収集エージェント部３２２には、ＩＤを発行するための処理部として、ＩＤ管理部３２２５が存在する。ＩＤ管理部３２２５は、ログ収集エージェント部３２２の起動と同時に処理を開始し、当該ログ収集エージェント部に固有のＩＤを発行し、ログデータ収集部３２２１にそのＩＤ情報を通知する。このＩＤは、アプリケーションサーバ１０２上のファイル（ＩＤファイル）として管理される。ＩＤファイルのフォーマット、ファイル名、および保存パス等に関しては図６を用いて後述する。
【００３０】
次に、バッチアプリケーションサーバ１０５に含まれる各処理部を説明する。バッチアプリケーションサーバ１０５上では、ログＤＢ部３４１に格納されたログを出力するためのアプリケーション（アーカイブアプリケーション）が実装されている。まず、取得日時指定部３５１では、ログＤＢ部３４１から取得する時刻の範囲を指定し、その範囲を、ログデータ取得部３５３に対して通知する。
【００３１】
次に、ステータス確認部３５２は、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ステータス取得のリクエストを送信する。また、ステータス確認部３５２は、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、ログＤＢ部３４１に保存されているログの中で、最も古い時刻を持つログの時刻の取得リクエストを送信する。ログＤＢリクエスト処理部３３１はリクエストを受信したら、ログＤＢ部３４１に格納されているログの時刻から、最も古い時刻を取得し、ステータス確認部３５２に送信する。その後、ステータス確認部３５２は、受信した最も古い時刻のログの時刻と、ステータスに記録されている時刻とをログデータ取得部３５３に通知する。
【００３２】
ログデータ取得部３５３は、取得日時指定部３５１、およびステータス確認部３５２から通知された時刻を比較する。比較のロジックに関しては、後述のフローチャートの説明にて詳細に述べる。比較の結果、取得日時指定部３５１より通知された範囲のログデータの取得が可能と判断した場合には、ログＤＢリクエスト処理部３３１に対してログ取得要求のリクエストを送信する。ログＤＢリクエスト処理部３３１は、リクエストを受信したら、ログＤＢ部３４１からログを取得し、ログデータ取得部３５３に送信する。ログデータ取得部３５３は、受信したデータをログデータ出力部３５４に渡す。ログデータ出力部３５４は、受け取ったログデータの形式を整形し、ファイルに出力する。
【００３３】
次に、ログサーバ１０３について説明する。まず、ログＤＢリクエスト処理部３３１は、アプリケーションサーバ１０２、およびバッチアプリケーションサーバ１０５から送信されるストレージサーバ１０４のログＤＢ部３４１に対する処理に関するリクエストを受信する。そして、ログＤＢリクエスト処理部３３１は、受信したリクエストに応じた処理を行う。また、ログＤＢリクエスト処理部３３１は、リクエストを受信した際には、ログＤＢＩ／Ｏ部３３２に対して、処理のリクエストを送信する。ログＤＢＩ／Ｏ部３３２は、ログＤＢリクエスト処理部３３１から受信したリクエストに応じた処理をログＤＢ部３４１に対して実行する。同様に、ステータスＤＢリクエスト処理部３３３は、アプリケーションサーバ１０２、およびバッチアプリケーションサーバ１０５から送信されるステータスＤＢ部３４２に対する処理に関するリクエストを受信する。そして、ステータスＤＢリクエスト処理部３３３は、受信したリクエストに応じた処理を行う。また、ステータスＤＢリクエスト処理部３３３は、リクエストを受信した際には、ステータスＤＢＩ／Ｏ部３３４に対して、処理のリクエストを行う。ステータスＤＢＩ／Ｏ部３３４は、ステータスＤＢリクエスト処理部３３３から受信したリクエストに応じた処理をステータスＤＢ部３４２に対して実行する。
【００３４】
次に、ストレージサーバ１０４について説明する。ログＤＢ部３４１は、ログサーバ１０３を介して収集した各ログを蓄積し、保存する。ステータスＤＢ部３４２は、アプリケーションサーバ１０２が有する各ログ収集エージェント部のステータスとＩＤとを対応付けて保持する。ここでのデータ構造に関しては、図８を用いて後述する。また、各ＤＢ（データベース）部は、ストレージサーバ１０４が備える間接記憶部等によって実現される。
【００３５】
［ログ収集エージェント部の設定ファイル］
図４を用いて、各ログ収集エージェント部が備える設定ファイルに設定可能な項目の説明を行う。まずログフィルタ部３２２４に関する設定項目であるフィルタ名４０１１、およびアセンブリ名４０１２に関して説明する。本実施形態において、アプリケーションサーバ１０２は、ＶＭの技術を利用して物理的な１台の装置において、複数の仮想的に異なるサーバを提供することができる。この場合には、設定ファイルも１台の装置の中に複数保持することとなる。前述したようにログ収集エージェント部３２２はログフィルタ部３２２４を備える。ログフィルタ部３２２４は、収集対象のログファイルのフォーマットによって変わりうるため、ログデータ収集部３２２１を変更することなく、ログフィルタ部３２２４を変更可能なようにすることが望ましい。そこで、実行時にリンクすることが可能な形式（例えば、Ｗｉｎｄｏｗｓ（登録商標）であればｄｌｌ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）ファイル）で、ログフィルタ部３２２４を実装する。
【００３６】
また、設定ファイルに、そのアセンブリパスを記載し、ログデータ収集部３２２１が実行時に、動的に読み込むことが出来るようにすることで、ログフィルタ部３２２４を容易に変更可能とする。ここで、設定ファイル中のｌｏｇＦｉｌｔｅｒタグは複数作成することが出来、複数のログフィルタ部に関する設定を１つの設定ファイルに記述することが出来る。その際、各ｌｏｇＦｉｌｔｅｒタグに割り振られたフィルタ名４０１１は一意となるように設定する必要がある。
【００３７】
次にａｇｅｎｔタグについて説明する。ａｇｅｎｔタグには、ログデータ収集部３２２１に関する設定を記述する。以下に設定項目に関する説明を述べる。Ａｇｅｎｔ名４０１３は、ａｇｅｎｔを一意に識別する名前である。ａｇｅｎｔタグは、複数記述することが出来、各ａｇｅｎｔタグに割り当てられたＡｇｅｎｔ名４０１３はログデータ収集部３２２１を特定するために一意となる必要がある。
【００３８】
次に、ｉｎｔｅｒｖａｌ４０１４には、ａｇｅｎｔ（ログデータ収集部３２２１）の起動間隔を設定する。指定された間隔に応じて、ログデータ収集部３２２１は、各サービスのログファイルからのログの読み込み処理を行う。ｄｉｒ４０１５は、ログデータ収集部３２２１が、収集を行う対象のログファイルが存在するフォルダパスを記述する。また、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７は、収集対象のファイル名の正規表現を記載する。ログデータ収集部３２２１は、ｄｉｒ４０１５に存在し、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致する全てのファイルを収集対象とする。
【００３９】
ｉｎｃｌｕｄｅＳｕｂＤｉｒ４０１６には、ｄｉｒ４０１５以下に存在するサブフォルダに含まれるログも、収集対象とする否かを設定する。ｌｏｇＦｉｌｔｅｒ−ｒｅｆ４０１８には、使用するフィルタ名４０１１を設定する。ここで設定したｌｏｇＦｉｌｔｅｒ名に一致するアセンブリをロードし、ログフィルタ部３２２４を作成する。ｌｏｇＳｅｒｖｅｒ４０１９、およびｓｔａｔｕＳｅｒｖｅｒ４０２０には、ログデータ収集部３２２１が接続するログＤＢリクエスト処理部３３１、およびステータスＤＢリクエスト処理部３３３のアドレスを設定する。ログ収集エージェント部３２２は、その起動時にこの設定ファイルを読み込み、その設定に従って処理を行う。詳細な処理フローに関しては、図１２を用いて後述する。
【００４０】
［ログフィルタＩ／Ｆ］
図５（ａ）に、ログフィルタＩ／Ｆの定義例を示す。ログ収集エージェント部３２２のログフィルタ部３２２４を作成する場合には、ログフィルタＩ／Ｆ５０１を実装したモジュールを作成する必要がある。図５（ａ）に示した例では、プログラミング言語としてＣ＃を選択し、Ｃ＃に基づいたＩ／Ｆ定義の例を記載している。しかしながら、プログラミング言語を限定するものではなく、ログ収集エージェント部３２２がロードできるモジュールの作成が可能であれば、いずれのプログラム言語を用いても構わない。
【００４１】
プログラム言語としてＣ＃を用いた場合、図５（ａ）に示すようにインタフェース定義部分は、クラス５０１１、戻り値５０１２、関数５０１３、引数５０１４から構成される。ログフィルタ部３２２４の作成者は、クラス５０１１を継承したクラスを作成したクラスを作成し、そのクラスで関数５０１３を備える関数を実装する。この関数には、ログ収集エージェント部３２２がログファイルから読みだした１行の文字列が引数５０１４に与えられる。ログフィルタ部３２２４の作成者は、引数５０１４を解析し、図５（ｂ）に示す様なプロパティを備えるクラスを作成し、戻り値５０１２として返す関数を実装する。
【００４２】
図５（ｂ）に、ＬｏｇＤａｔａクラスのプロパティの定義例を示す。本プロパティの定義も同様に、プログラミング言語としてＣ＃を用いた場合の定義例を示している。
【００４３】
以下に、各プロパティの説明を記載する。ＴｉｍｅＳｔａｍｐ５０２１は、ログに記載されている時刻（タイムスタンプ）を設定するためのプロパティである。ＴｅｎａｎｔＩｄ５０２２には、ログを出力するきっかけとなった操作を行ったユーザが所属するテナント（会社、組織）を識別するためのＩＤを設定するためのプロパティである。ＵｓｅｒＩｄ５０２３は、ログを出力する起因となった操作を行ったユーザを識別するためのＩＤを設定するためのプロパティである。ＳｅｒｖｉｃｅＩｄ５０２４は、ユーザが行った操作の内容、例えば、Ｐｒｉｎｔ、Ｓｃａｎといった操作の種類を表すためのＩＤである。最後に、ＯｂｊｅｔｃｔＩＤ５０２５には、処理の対象、例えばプリントの場合であれば、プリントしたドキュメントの名前などを設定するためのプロパティである。
【００４４】
図５（ｂ）における本定義例では、上記５つのプロパティを定義したが、これに限定するものではない。その他の項目をログとして記録したい場合には、ＬｏｇＤａｔａクラス５０２にプロパティを追加し、関数５０１３の実装にて、その項目に値を設定するように、ログフィルタ部３２２４の実装を行う。また、ＴｉｍｅＳｔａｍｐ５０２１以外の項目をログとして記録しない場合には、プロパティをクラスの定義から削除しても構わない。
【００４５】
［ＩＤファイル］
図６を用いて、ＩＤファイルの説明を行う。本実施形態に係るＩＤファイルは図６に示す様なスキーマによって構成される。ＩＤファイルはａｇｅｎｔＩｄ６０１１タグから構成され、その属性であるｉｄには、ログ収集エージェント部３２２を一意に識別するための識別子（ＧＵＩＤ：Ｇｌｏｂａｌ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）を設定する。ＧＵＩＤは、ログ収集エージェント部３２２が起動する際に、ログ収集エージェント部３２２自身で作成する。この作成されるＩＤファイルは、前述したログ収集エージェント部３２２の設定ファイルにおいてｄｉｒ４０１５が示すフォルダに保存される。もし、フォルダが存在しない場合には、ログ収集エージェント部３２２は起動しない。また、ＩＤファイルのファイル名は、設定ファイルのｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７から生成される文字列を使用する。
【００４６】
前述したようにｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７には正規表現が設定されるため、「？」や「￥」等のファイル名には指定出来ない文字列が設定される可能性がある。そのため、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に指定された文字列から、ファイル名に使用できる文字列への変換処理を行う。具体的には、Ｂａｓｅ６４エンコーディングを用いて文字列変換することや、「￥」などの文字列を「ｂｓ」などの文字列に置き換えることがあげられる。ここで、変換の際の条件として、変換前の文字列と変換後の文字列が写像関係になっていることが挙げられる。
【００４７】
なお、本実施形態では、１台の物理的な装置の中に複数のＶＭ（アプリケーションサーバ）を動作させている場合には、各ＶＭそれぞれのログ収集エージェント部３２２ごとにＩＤファイルが生成されることとなる。
【００４８】
［レコードファイル］
前述したように、ログデータ収集部３２２１は、定期的にログファイルを読み込む。そして、ログデータ収集部３２２１は、新規に追加されたログのみに対して、ログフィルタ部３２２４を用いて整形し、ストレージサーバ１０４のログＤＢ部３４１にログデータを格納する。このように新規に追加されたログのみを対象とすることで、パフォーマンスを向上させることが出来る。新規に追加されたログのみを対象とするために、前回の収集時に、ログデータ収集部３２２１が収集を行ったファイルの位置や、収集を行った時間などを記録する必要がある。そのデータを、ログの収集状況を示すレコードファイルと呼ばれるファイルに記載する。ここで、レコードファイルはログ収集エージェント部３２２が存在するフォルダに、動的に作成される。また、レコードファイルのファイル名は、ログ収集エージェント部３２２の設定ファイルにおいて、Ａｇｅｎｔ名４０１３の末尾に「．ｘｍｌ」を追記したファイル名とする。
【００４９】
図７を用いて、本実施形態に係るレコードファイルの説明を行う。レコードファイルは、図７に示す様な形式のファイルである。ｒｅｃｏｒｄタグは、ｆｉｌｅｎａｍｅ７０１１、ｕｐｄａｔｅＴｉｍｅ７０１２、ｏｆｆｓｅｔ７０１３、ｌｉｎｅＮｕｍｂｅｒ７０１４の４つの属性から構成される。ｒｅｃｏｒｄタグは、ログデータ収集部３２２１が収集対象とするファイルの数だけ作成される。ｆｉｌｅｎａｍｅ７０１１は、ログデータ収集部３２２１が収集しているログファイルの名称が設定される。ｕｐｄａｔｅＴｉｍｅ７０１２には、ログデータ収集部３２２１が、前回の収集を行った時間を設定する。ｆｉｌｅｎａｍｅ７０１１が示すファイルに対して、過去に収集処理を行っていない場合には、初期値として“１９７０／０１／０１ ００：００：００”が設定される。
【００５０】
ｏｆｆｓｅｔ７０１３には、ログデータ収集部３２２１が収集が完了した個所への、ファイル先頭からのバイト数（データサイズ）が設定される。最後に、ｌｉｎｅＮｕｍｂｅｒ７０１４には、収集が完了したログの行番号が設定される。ｆｉｌｅｎａｍｅ７０１１が示すファイルに対して、収集処理を行っていない場合には、ｏｆｆｓｅｔ７０１３、およびｌｉｎｅＮｕｍｂｅｒ７０１４には、“０”が設定される。ログデータ収集部３２２１は、前述したｉｎｔｅｒｖａｌ４０１４毎に起動し、レコードファイルを読み込む。その後、ｆｉｌｅｎａｍｅ７０１１の更新時間をチェックし、その時間とｕｐｄａｔｅＴｉｍｅ７０１２とを比較する。ｕｐｄａｔｅＴｉｍｅ７０１２の方が古い場合には、ログデータ収集部３２２１は、ファイル先頭からｏｆｆｓｅｔ７０１３が示すバイト数だけファイルを移動し、ログの収集を開始する。ログの収集が完了した場合には、各項目の更新を行う。このようにすることで、新規に追加されたログのみを収集することが出来る。図７にはＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のフォーマットで各情報が記載されているが、ＸＭＬ形式である必要はなく。コンマ区切り（ＣＳＶ形式）等で、各項目が記載されていても問題はない。
【００５１】
［ログＤＢ］
図８を用いて、本実施形態に係るログＤＢ部３４１にて保持されるログＤＢ８０１の説明をする。まず、ログＤＢ８０１に必要な項目としては、ＴｉｍｅＳｔａｍｐ８０１１、ＡｇｅｎｔＩＤ８０１２、ＦｉｌｅＮａｍｅ８０１３、ＬｉｎｅＮｕｍｂｅｒ８０１４の４つの項目が存在する。ＴｉｍｅＳｔａｍｐ８０１１には、そのログに記録されている事象が発生していた時間が格納される。ＡｇｅｎｔＩＤ８０１２には、そのログを収集したログ収集エージェント部３２２が有する、ＩＤファイルに記載されているＩＤが格納される。ＦｉｌｅＮａｍｅ８０１３には、そのログが記録されていたログファイルのファイルパスが記載される。最後にＬｉｎｅＮｕｍｂｅｒ８０１４には、そのログのログファイルに置ける行番号が格納される。
【００５２】
これらの４つの項目は、ログＤＢ部３４１のログＤＢ８０１への、同じログを２度以上重複して記録すること（以下、２重記録）を防ぐために必要となる。例えば、前述したレコードファイルが、何らかの理由で読み込めなくなった場合、ログデータ収集部３２２１は、収集対象のフォルダに存在する全てのファイルの先頭から、再度収集を行ってしまう。その際、すでに収集したログをログＤＢ部３４１に再度格納するため、その結果として２重記録が発生する。そこで、本実施形態では、上記４つの項目が一意となるようにログＤＢ８０１に制約を張る。例えば、ＲＤＢＭＳ（Ｒｅｌａｔｉｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｅｔ Ｓｙｓｔｅｍ）の場合には、上記４つの項目をＵｎｉｑｕｅとなるように制約を張ることで、２重記録防止の対応が可能となる。また、Ｋｅｙ−Ｖａｌｕｅ Ｓｔｏｒｅの場合には、上記４つの文字列の組み合わせをキーとして定義することで、同じキーを持つデータの格納が出来なくなり、重複した記録を防止する対応が可能となる。
【００５３】
上記４つの項目以外の項目に関しては、ログとして残す必要がある項目に応じて、任意に追加することが可能である。例えば、図８の場合、ＴｅｎａｎｔＩＤ８０１５、ＵｓｅｒＩＤ８０１６、ＳｅｒｖｉｃｅＩＤ８０１７、ＯｂｊｅｃｔＩＤ８０１８がログの項目として列挙されている。ＴｅｎａｎｔＩＤ８０１５には、その処理を行ったユーザが所属する組織（例えば会社等）が記録される。ＵｓｅｒＩＤ８０１６には、その処理を行ったユーザを特定するための情報が記録される。ここで、ＵｓｅｒＩＤのみでそのユーザが特定される必要はなく、例えばＴｅｎａｎｔＩＤとの組み合わせでそのユーザを一意に特定できればよい。
【００５４】
ＳｅｒｖｉｃｅＩＤ８０１７には、そのユーザが使用したサービスのＩＤが記録される。例えばユーザ追加機能や、Ｐｒｉｎｔ、Ｓｃａｎといった機能のサービスＩＤが記録される。最後に、ＯｂｊｅｃｔＩＤ８０１８には、処理を行った対象が記録される。例えばユーザの追加処理（Ａｄｄ Ｕｓｅｒ）であれば、追加されたユーザＩＤが記録される。また、Ｐｒｉｎｔや、Ｓｃａｎであれば、その対象のドキュメント名などが記録される。上記で上げた項目以外を記録した場合には、その項目のカラムなどを追加することで、新しい項目を記録することが可能となる。
【００５５】
なお、本実施形態では、ＴｉｍｅＳｔａｍｐ８０１１、ＡｇｅｎｔＩＤ８０１２、ＦｉｌｅＮａｍｅ８０１３、ＬｉｎｅＮｕｍｂｅｒ８０１４の４つの項目をキーとして、ログを格納するか否かを判定している。しかし、これに限定するものではなく、ＡｇｅｎｔＩＤ８０１２以外の項目については、これらの項目のうちのいずれかであってもよいし、更に別の項目を追加するようにしてもよい。つまり、ＡｇｅｎｔＩＤ８０１２を必須のキー項目とし、更に１以上の他のキー項目の情報を用いて、ログの特定を行うようにすることができる。なお、ここで用いる項目を変更する場合には、図５（ｂ）に示すＬｏｇＤａｔａクラス５０２にて取得する情報も変更する必要が有る。
【００５６】
［ステータスＤＢ］
図９（ａ）、（ｂ）を用いて、本実施形態に係るステータスＤＢ部３４２にて保持されるステータスＤＢの説明を行う。ストレージサーバ１０４のステータスＤＢ部３４２には、ステータスＤＢとしてログ収集エージェント部３２２のＩＤ（ＡｇｅｎｔＩＤ９０１１、９０２１）と、そのログ収集エージェント部３２２がログの収集をした時刻（ＬａｓｔＣｒａｗｌＴｉｍｅ９０１２、９０２２）とが記録される。このＬａｓｔＣｒａｗｌＴｉｍｅに記録されている時刻は、この時刻までにログファイルに出力されていたログは、全てログＤＢ部３４１に格納されている、という事を保証するための値である。
【００５７】
まず図９（ａ）を用いて、初回登録時に、ステータスＤＢ部３４２に登録される内容についての説明を行う。ログ収集エージェント部３２２は、その起動時にＩＤファイルを読み込む（または作成する）。そこで作成したＩＤをステータスＤＢ部３４２に送信することで、自身のＩＤに対応するデータをステータスＤＢ部３４２に登録する。その際、ＬａｓｔＣｒａｗｌＴｉｍｅ９０１２は、初期登録ステータスを表す時刻（１９７０／０１／０１ ００：００：００）が登録される。本実施形態では、初期登録時刻として、“１９７０／０１／０１ ００：００：００”を使用しているが、例えば現在時刻より１年以上過去の値を使っても特に問題はない。ここで用いられる初期登録の値としての条件は、このシステムを使用する日時とは、等しくならないことである。
【００５８】
ログ収集エージェント部３２２は初期登録後、ログデータ収集部３２２１がログの収集処理を行う。ログ収集エージェント部３２２は、ログＤＢ部３４１へのログの格納処理が成功した後に、ステータスＤＢリクエスト処理部３３３に対して、自身のＩＤと、現在時刻を対応付けて送信する。ステータスＤＢリクエスト処理部３３３は、受信したデータからＩＤを取出し、ＩＤと等しいＡｇｅｎｔＩＤ９０１１、９０２１を有するエンティティのＬａｓｔＣｒａｗｌＴｉｍｅ９０２２を受信した時刻で更新する。このように、ログ収集エージェント部３２２はステータスＤＢ部３４２の更新を行う。
【００５９】
［アーカイブアプリケーションの設定ファイル］
図１０を用いて、本実施形態に係るバッチアプリケーションサーバ１０５で動作する、アーカイブアプリケーション（不図示）の設定ファイル１００００の定義を示す。ここで、アーカイブアプリケーションは、ログＤＢ部３４１に格納されているログデータをファイルに出力する機能を備えるアプリケーションである。アーカイブアプリケーションの設定ファイルは、図１０に記載されているように、ＸＭＬ形式で記載される。ここで、設定ファイルのフォーマットは、ＸＭＬ形式のみではなく、例えばコンマ等で各項目が区切られたＣＳＶ形式（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）などでも良い。
【００６０】
アーカイブアプリケーションは、設定ファイル１００００にて、まずａｒｃｈｉｖｅＳｅｔｔｉｎｇタグを有する。このタグは、ｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１、ｌｏｇＤｂＵｒｉ１０００２、ｓｔａｔｕｓＤｂＵｒｉ１０００３、ｓｔａｒｔＤａｔｅ１０００４、およびｅｎｄＤａｔｅ１０００５から構成される。ｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１は、アーカイブアプリケーションが出力するファイルを保存するディレクトリパスを示す。アーカイブアプリケーションは、日付毎にログを取得し、その取得した日付をファイル名としたファイルを作成する。
【００６１】
例えば、２０１１年１月１日のログを、ＤＢから取得した場合には、「２０１１０１０１．ｃｓｖ」の様なファイル名を有するファイルをｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１が示すフォルダに保存する。ｌｏｇＤｂＵｒｉ１０００２には、ログＤＢリクエスト処理部３３１のアドレスを記述する。ｓｔａｔｕｓＤｂＵｒｉ１０００３には、ステータスＤＢリクエスト処理部３３３のアドレスを記載する。ｓｔａｒｔＤａｔｅ１０００４には、ログを保管する期間の開始日を記載する。図１０に示した例の場合、ログＤＢ部３４１に格納されているログのＴｉｍｅＳｔａｍｐ８０１１が「２０１１年１月５日０時０分０秒」以降のログを対象とする。ｅｎｄＤａｔｅ１０００５は、ログを保管する期間の終了日を記載する。図１０に示した例の場合、ログＤＢ部３４１に格納されているログのＴｉｍｅＳｔａｍｐ８０１１が「２０１１年１月２０日０時０分０秒」未満のログを対象とする。
【００６２】
アーカイブアプリケーションを用いて、ログＤＢ部３４１に格納されているログを外部に保管することが出来る。保管されたログはログＤＢ部３４１からの削除が可能となるため、ストレージ容量の確保、およびストレージの仕様に関するコストを削減することが出来る。また、図１０には示されていないが、設定ファイル１００００内に、ＡｇｅｎｔＩＤを指定するようにしても構わない。この場合には、特定のログ収集エージェント部が収集したログのみを出力するようにもできる。
【００６３】
［フローチャート］
図１１乃至図１４を用いて、本発明における、アプリケーションサーバ１０２、ログサーバ１０３、バッチアプリケーションサーバ１０５、ストレージサーバ１０４の処理の流れを詳細に説明する。
【００６４】
［ログ収集エージェント部の起動］
まず、図１１を用いて、ログ収集エージェント部３２２の起動時の処理の流れについて説明する。本処理フローは、本実施形態において、アプリケーションサーバ１０２、およびログサーバ１０３がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００６５】
Ｓ１１０１では、アプリケーションサーバ１０２のＯＳ（不図示）は、ログ収集エージェント部３２２を起動する。
【００６６】
Ｓ１１０２では、ログ収集エージェント部３２２は、図４に示すような設定ファイルを読み込む。設定ファイルの読み込みに失敗した場合には（Ｓ１１０３にてＮＯ）、Ｓ１１２３に遷移する。設定ファイルの読み込みが成功した場合には（Ｓ１１０３にてＹＥＳ）、Ｓ１１０４に遷移する。
【００６７】
Ｓ１１０４では、ログ収集エージェント部３２２は、設定ファイルに記載されたａｇｅｎｔｓタグに含まれる全ａｇｅｎｔタグの設定に基づいて全てのａｇｅｎｔを生成したかどうかをチェックする。つまり、ログ収集エージェント部３２２は、設定ファイルのａｇｅｎｔｓタブに定義された全てのログデータ収集部を生成したか否かを判定する。全てのａｇｅｎｔタグに基づいてａｇｅｎｔを生成した場合には（Ｓ１１０４にてＹＥＳ）、Ｓ１１１８に遷移する。全てのａｇｅｎｔを生成していない場合には（Ｓ１１０４にてＮＯ）、Ｓ１１０５に遷移する。
【００６８】
Ｓ１１０５では、ログ収集エージェント部３２２は、設定ファイルに記載されたｄｉｒ４０１５で示されたａｇｅｎｔ（ログデータ収集部）によるログの収集対象となるフォルダが存在するかどうかをチェックする。フォルダが存在しない場合には（Ｓ１１０５にてＮＯ）、Ｓ１１２３に遷移する。フォルダが存在していない場合には（Ｓ１１０５にてＹＥＳ）、Ｓ１１０６に遷移する。Ｓ１１０６では、ログ収集エージェント部３２２は、存在しているフォルダ内にｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７から生成されるファイル名を有するＩＤファイルが存在しているかチェックする。ＩＤファイルが存在していない場合には（Ｓ１１０６にてＮＯ）、Ｓ１１０９に遷移する。また、ＩＤファイルが存在している場合には（Ｓ１１０６にてＹＥＳ）、Ｓ１１０７に遷移する。
【００６９】
Ｓ１１０９では、ログ収集エージェント部３２２は、ＩＤファイルを作成し、ファイルにＩＤを記載する。このとき、ファイルの作成に失敗した場合には（Ｓ１１１０にてＮＯ）、Ｓ１１２３に遷移する。ファイルの作成に成功した場合には（Ｓ１１１０にてＹＥＳ）、Ｓ１１１１に遷移する。
【００７０】
Ｓ１１０７では、ログ収集エージェント部３２２は、図６に示すようなＩＤファイルから当該ログ収集エージェント部に対応するＩＤの情報を読み込む。このとき、ＩＤファイルの読み込み処理に失敗した場合には（Ｓ１１０８にてＮＯ）、Ｓ１１２３に遷移する。ＩＤファイルの読み込み処理に成功した場合には（Ｓ１１０８にてＹＥＳ）、Ｓ１１１１に遷移する。
【００７１】
Ｓ１１１１では、ログ収集エージェント部３２２は、図４の設定ファイルに記載されているアセンブリ名４０１２が示すモジュールをロードし、図５に示すログフィルタ部３２２４を作成する。
【００７２】
Ｓ１１１２では、ログ収集エージェント部３２２は、ログデータ収集部３２２１を生成する。Ｓ１１１３では、ログ収集エージェント部３２２は、図４の設定ファイルのＡｇｅｎｔ名４０１３の末尾に「．ｘｍｌ」が追記されたファイル、例えば図７に示すようなレコードファイル、が存在するか否かをチェックする。レコードファイルが存在する場合には（Ｓ１１１３にてＹＥＳ）、Ｓ１１１４に遷移する。レコードファイルが存在しない場合には（Ｓ１１１３にてＮＯ）、Ｓ１１１５に遷移する。
【００７３】
Ｓ１１１４では、ログ収集エージェント部３２２は、レコードファイルを読みこむ。Ｓ１１１５では、ログ収集エージェント部３２２は、レコードファイルを作成する。ここで、レコードファイルには、設定ファイルのｄｉｒ４０１５に指定されたフォルダパスに存在し、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致するファイル名を持つ全ログファイルを、レコードファイルに初期登録する。つまり、図７のレコードファイル７０１に示すｒｅｃｏｒｄタブから構成される要素がログファイルの数だけ登録される。
【００７４】
Ｓ１１１６では、ログ収集エージェント部３２２は、図６に示すような自身のエージェントＩＤをログサーバ１０３のステータスＤＢリクエスト処理部３３３に送信する。Ｓ１１１２では、ログサーバ１０３は、受信したステータスＩＤを用いて、ストレージサーバ１０４のステータスＤＢ部３４２に初期登録する。
【００７５】
Ｓ１１１８では、ログ収集エージェント部３２２は、設定ファイルから生成された全てのログデータ収集部３２２１の処理を開始したか否かを確認する。全てログデータ収集部３２２１が処理を開始していない場合には（Ｓ１１１８にてＮＯ）、Ｓ１１１９に遷移する。全てのａｇｅｎｔタグから生成されたログデータ収集部３２２１が処理開始済みである場合には（Ｓ１１１８にてＹＥＳ）、Ｓ１１２３に遷移する。
【００７６】
Ｓ１１１９では、ログ収集エージェント部３２２は、ログデータ収集部３２２１の処理を開始する。Ｓ１１２０では、ログ収集エージェント部３２２は、ログを収集し、ログサーバ１０３に送信する。この処理の詳細に関しては、図１２を用いたフローチャートの説明にて行う。Ｓ１１２１では、ログサーバ１０３は、受信したデータをストレージサーバ１０４のログＤＢ部３４１に格納する。
【００７７】
Ｓ１１２２では、ログ収集エージェント部３２２は、設定ファイルのｉｎｔｅｒｖａｌ４０１４にて設定された秒数後に、ログデータ収集部３２２１が、処理を再開するようにタイマーを設定し、待機する。そして、所定の時間が経過した場合には、ログデータ収集部３２２１は処理を再開する。Ｓ１１２３では、ログ収集エージェント部３２２は、処理中にエラーが発生したものとし、処理を停止する。
【００７８】
［ログデータ収集部の処理の流れ］
図１２を用いて、ログデータ収集部３２２１の処理の流れについて説明する。本処理フローは、本実施形態において、アプリケーションサーバ１０２、およびログサーバ１０３がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００７９】
Ｓ１２０１では、アプリケーションサーバ１０２のＯＳ／タイマーは、ログデータ収集部３２２１の処理の再開命令を発行する。ここで、再開命令を発行する場合とは、図１１の１１２２にて示したように、待機状態にあるログデータ収集部３２２１の処理を再開させる場合が該当する。Ｓ１２０２では、ログデータ収集部３２２１は、ログ収集エージェント部３２２の停止命令の有無をチェックする。停止命令があった場合には（Ｓ１２０２にてＹＥＳ）、Ｓ１２１７に遷移する。また、停止命令がなかった場合は（Ｓ１２０２にてＮＯ）、Ｓ１２０３に遷移する。
【００８０】
Ｓ１２０３では、ログデータ収集部３２２１は、図４に示す設定ファイルのｄｉｒ４０１５に記載のフォルダパスに存在し、かつ、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致するファイル名を有するファイルの一覧を取得する。Ｓ１２０４では、ログデータ収集部３２２１は、Ｓ１２０３で取得したファイルの一覧の中で、レコードファイルに記録されていないファイル名を有するファイルを、レコードファイルに初期登録する。
【００８１】
Ｓ１２０５では、ログデータ収集部３２２１は、レコードファイルに記録された、ｕｐｄａｔｅＴｉｍｅ７０１２と、ファイルの更新時間とを比較し、ｕｐｄａｔｅＴｉｍｅ７０１２が示す時間以降に更新されたファイルの一覧を取得する。Ｓ１２０６では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧の数を確認する。ファイルの数が“０”、つまり更新されたログファイルが存在しない場合には（Ｓ１２０６にてＮＯ）、Ｓ１２１３に遷移する。また、ファイルの数が１以上、つまり更新されたファイルが存在する場合には（Ｓ１２０６にてＹＥＳ）、Ｓ１２０７に遷移する。
【００８２】
Ｓ１２０７では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧に対して、Ｓ１２０８乃至Ｓ１２１１の処理を行ったかどうかを確認する。つまり、ログデータ収集部３２２１は、全ログファイルを収集済みか否かを判定する。Ｓ１２０８乃至Ｓ１２１１の処理を行っていない場合には（Ｓ１２０７にてＮＯ）、Ｓ１２０８に遷移する。ファイルの一覧に含まれる全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理を行った場合には（Ｓ１２０７にてＹＥＳ）、Ｓ１２１２に遷移する。
【００８３】
Ｓ１２０８では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧に含まれる一つのファイルから、ログを読み込む。そして、ログデータ収集部３２２１は、ログフィルタ部３２２４を用いてログを整形し、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、整形したログを送信する。送信の際には、ログフィルタ部３２２４によって整形されたデータに、ログデータ収集部３２２１が読み込んだファイル名、ログの行数、および自身に割り当てられたＩＤを対応付けて送信する。
【００８４】
Ｓ１２０９では、ログサーバ１０３は、Ｓ１２０８にてログデータ収集部３２２１より送信されたログデータを受信し、そのデータをストレージサーバ１０４のログＤＢ部３４１に格納する。そして、ログサーバ１０３は、ログＤＢ部３４１に格納が成功したかどうかをログデータ収集部３２２１に送信する。
【００８５】
Ｓ１２１０では、ログデータ収集部３２２１は、ログサーバ１０３から送信された処理結果を受信し、ログサーバ１０３によるログの格納が成功したか否かを判定する。処理結果が格納が成功した旨を示す正常終了であれば（Ｓ１２１０にてＹＥＳ）、Ｓ１２１１に遷移する。処理結果が異常終了を示すものであれば（Ｓ１２１０にてＮＯ）、Ｓ１２０７に遷移する。
【００８６】
Ｓ１２１１では、ログデータ収集部３２２１は、レコードファイルを更新する。具体的には、ｕｐｄａｔｅＴｉｍｅ７０１２を現在時刻とし、ｏｆｆｓｅｔ７０１３をファイル末尾のバイト数、ｌｉｎｅＮｕｍｂｅｒ７０１４をファイルの最後の行の行番号とする。レコードファイルの更新後、Ｓ１２０７に遷移する。
【００８７】
Ｓ１２１２では、ログデータ収集部３２２１は、Ｓ１２０５で取得した全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が成功したかどうかを確認する。全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が成功した場合には（Ｓ１２１２にてＹＥＳ）、Ｓ１２１３に遷移する。一つ以上のログファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が失敗していた場合には（Ｓ１２１２にてＮＯ）、Ｓ１２１５に遷移する。
【００８８】
Ｓ１２１３では、ログデータ収集部３２２１は、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ＬａｓｔＣｒａｗｌＴｉｍｅを表す時刻と、自身のＩＤとを関連付けたデータを送信する。ここで、送信するＬａｓｔＣｒａｗｌＴｉｍｅを表す時刻は、Ｓ１２０８にてログファイルからログを読み込む前に取得した時刻とする。
【００８９】
Ｓ１２１４では、ログサーバ１０３は、ログデータ収集部３２２１より送信された、ＩＤとＬａｓｔＣｒａｗｌＴｉｍｅとが関連付けられたデータを受信する。受信した後に、ログサーバ１０３は、受信したＩＤと等しいＡｇｅｎｔＩＤを有するステータスＤＢのエンティティに含まれるＬａｓｔＣｒａｗｌＴｉｍｅを、受信したＬａｓｔＣｒａｗｌＴｉｍｅで更新する。
【００９０】
Ｓ１２１５では、ログデータ収集部３２２１は、ログ収集エージェント部３２２の停止命令の有無をチェックする。停止命令があった場合には（Ｓ１２１５にてＹＥＳ）、Ｓ１２１７に遷移する。また、停止命令がなかった場合は（Ｓ１２１５にてＮＯ）、Ｓ１２１６に遷移する。
【００９１】
Ｓ１２１６では、ログデータ収集部３２２１は、設定ファイルのｉｎｔｅｒｖａｌ４０１４に記載されていた秒数後に、Ｓ１２０１の処理が呼び出されるように、タイマーを設定する。Ｓ１２１７では、ログデータ収集部３２２１は、処理を停止する。
【００９２】
［バッチアプリケーションサーバ１０５の処理の流れ］
図１３を用いて、バッチアプリケーションサーバ１０５に存在する、アーカイブアプリケーション（不図示）の処理フローについて説明する。本処理フローは、本実施形態において、ログサーバ１０３、およびバッチアプリケーションサーバ１０５がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００９３】
Ｓ１３０１では、アーカイブアプリケーションは、図１０に示す設定ファイルに記載されているＳｔａｒｔＤａｔｅ１０００４、およびＥｎｄＤａｔｅ１０００５から、ログを保管する期間を取得する。以下の説明においては、ＳｔａｒｔＤａｔｅ１０００４が表す時間を「ログ取得開始日」、ＥｎｄＤａｔｅ１０００５が示す時間を「ログ取得終了日」と記載する。Ｓ１３０２では、アーカイブアプリケーションは、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ログ取得可能範囲の終了日の取得要求を発行する。
【００９４】
Ｓ１３０３では、ログサーバ１０３のステータスＤＢリクエスト処理部３３３は、ストレージサーバ１０４のステータスＤＢ部３４２からＬａｓｔＣｒａｗｌＴｉｍｅ９０２２の一覧を取得する。Ｓ１３０４では、ステータスＤＢリクエスト処理部３３３は、取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧に要素が含まれるかどうかを確認する。取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧に要素が含まれていない場合には（Ｓ１３０４にてＮＯ）、Ｓ１３１６に遷移する。また、要素が含まれている場合には（Ｓ１３０４にてＹＥＳ）、Ｓ１３０５に遷移する。
【００９５】
Ｓ１３０５では、ステータスＤＢリクエスト処理部３３３は、Ｓ１３０３で取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧の中に、初期値（本実施形態では、「１９７０／０１／０１」）が存在するか否かを確認する。一覧の中に初期値が存在する場合には（Ｓ１３０５にてＹＥＳ）、Ｓ１３１６に遷移する。また、一覧の中に初期値が存在しない場合には（Ｓ１３０５にてＮＯ）、Ｓ１３０６に遷移する。
【００９６】
Ｓ１３０６では、ステータスＤＢリクエスト処理部３３３は、Ｓ１３０３で取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧の中で、最も古い時間を取得する。そして、ステータスＤＢリクエスト処理部３３３は、取得した時間を、バッチアプリケーションサーバ１０５のアーカイブアプリケーションに対して送信する。
【００９７】
Ｓ１３０７では、アーカイブアプリケーションは、受信した時間と、ログ取得終了日とを比較する。ここで、Ｓ１３０６で取得した時間が、ログ取得終了日が示す時間よりも新しい場合には（Ｓ１３０８にてＹＥＳ）、Ｓ１３２１に遷移する。また、Ｓ１３０６で取得した時間が、ログ取得終了日が示す時間よりも古い場合には（Ｓ１３０８にてＮＯ）、Ｓ１３０９に遷移する。
【００９８】
Ｓ１３０９では、アーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１に対し、ストレージサーバ１０４のログＤＢ部３４１に存在するログの中で最も古いＴｉｍｅＳｔａｍｐを持つログのＴｉｍｅＳｔａｍｐの取得要求を発行する。
【００９９】
Ｓ１３１０では、ログＤＢリクエスト処理部３３１は、ログＤＢ部３４１の中でも最も古いＴｉｍｅＳｔａｍｐを有するログのＴｉｍｅＳｔａｍｐを取得し、バッチアプリケーションサーバ１０５に対して送信する。
【０１００】
Ｓ１３１１では、アーカイブアプリケーションは、ログサーバ１０３から取得した時間と、ログ取得開始日とを比較する。ここで、ログ取得開始日の方が新しい場合には（ＳＳ１３１２にてＹＥＳ）、Ｓ１３１３に遷移する。また、ログ取得開始日が、取得した時間よりも古い場合には（Ｓ１３１２にてＮＯ）、Ｓ１３２１に遷移する。
【０１０１】
Ｓ１３１３では、アーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、ログ取得開始日からログ取得終了日の間のログの取得要求を発行する。Ｓ１３１４では、ログサーバ１０３のログＤＢリクエスト処理部３３１は、受信したログ取得開始日からログ取得終了日に該当するＴｉｍｅＳｔａｍｐを有するログを、ログＤＢ部３４１から全て取得する。
【０１０２】
Ｓ１３１４では、ログサーバ１０３のログＤＢリクエスト処理部３３１は、終了コードに正常終了を示す値を設定する。ここで、正常終了を示すコードに対する値の制約は特にない。つまり、正常終了を示すものであれば、コードをどのように定義しても構わない。Ｓ１３１６では、ログＤＢリクエスト処理部３３１は、終了コードに異常終了を示すコードを設定する。
【０１０３】
Ｓ１３１７では、ログＤＢリクエスト処理部３３１は、Ｓ１３１４で取得した全ログデータと、Ｓ１３１５、もしくはＳ１３１６で設定した終了コードとの組をバッチアプリケーションサーバ１０５のアーカイブアプリケーションに送信する。
【０１０４】
Ｓ１３１８では、バッチアプリケーションサーバ１０５のアーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１から送信されたログデータの集合と、終了コードとの組を受信する。Ｓ１３１９では、アーカイブアプリケーションは、受信した終了コードがエラーコードであるか、否かを確認する。終了コードが異常終了を示すものである場合には（Ｓ１３１９にてＮＯ）、Ｓ１３２１に遷移する。また、終了コードが正常終了コードである場合は（Ｓ１３１９にてＹＥＳ）、Ｓ１３２０に遷移する。
【０１０５】
Ｓ１３２０では、アーカイブアプリケーションは、受信したログデータを、ＣＳＶ形式に整形して、ファイルに出力する。ここで、出力ファイルのフォーマットはＣＳＶ形式である必要はなく、任意のフォーマットで出力してもよい。Ｓ１３２１にて、アーカイブアプリケーションは、処理を終了する。
【０１０６】
［フェールオーバー時の処理の流れ］
フェールオーバーした際の、アプリケーションサーバ１０２の処理の流れについて説明する。ここで、フェールオーバーとは、一般的にコールドスタンバイや、ホットスタンバイと呼ばれる形式の仕組みを指す。上記の方式では、例えば、あるアプリケーションサーバにおいて処理の継続が不能状態に陥った場合、そのアプリケーションサーバを再起動することで、状態を回復させるのではなく、異なるアプリケーションサーバに処理を移譲する。これにより、システム全体としての処理を継続させ、サービスの提供を復旧させる。
【０１０７】
本システムでは、図９に示すように、ストレージサーバ１０４のステータスＤＢ部３４２に、ＡｇｅｎｔＩＤをキーとし、そのＡｇｅｎｔＩＤと等しいＩＤを有するログ収集エージェント部３２２が記録されている。また、当該ログ収集エージェント部３２２に対応付けて、収集を完了した日時がＬａｓｔＣｒａｗｌＴｉｍｅに記録されている。
【０１０８】
ここで、異なるアプリケーションサーバにて、ログ収集エージェント部３２２が起動したとする。ログ収集エージェント部３２２は、図１１のＳ１１０９にて、新しいＩＤを作成し、Ｓ１１１６にて、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、作成したＩＤを送信し、登録作業を行う。この場合において、図９（ｃ）に示す様に、新しいエンティティ（ＡｇｅｎｔＩＤ「ＣＥ２０９９９７・・・」）がストレージサーバ１０４のステータスＤＢ９０３に登録される。
【０１０９】
ここで、ＡｇｅｎｔＩＤ「ＢＥ２０９９９７・・・」を有するエンティティのＬａｓｔＣｒａｗｌＴｉｍｅ９０３２は、更新されずに古い値を保持したままとなる。バッチアプリケーションサーバ１０５のアーカイブアプリケーションは、ストレージサーバ１０４のステータスＤＢ部３４２に記録されている全てのＬａｓｔＣｒａｗｌＴｉｍｅのうち、最も古い時刻までのＴｉｍｅＳｔａｍｐを持つログを出力可能とする。図９（ｃ）の場合、最も古い時刻は、「２０１１／０１／０３ ０１：００：００」であり、またこの値は更新されないため、永久にアーカイブアプリケーションは「２０１１／０１／０３ ０１：００：００」までのログしか出力できないことになる。
【０１１０】
そこで、本実施形態では、フェールオーバーの際に、異なるアプリケーションサーバに処理が委譲された場合においても、フェールオーバの前後でＩＤが引き継がれ、ＬａｓｔＣｒａｗｌＴｉｍｅが更新されるための、アプリケーションサーバのフローを以下に記述する。つまり、フェールオーバーの際に処理が委譲された場合にも、図９（ｃ）に示すように新たなＡｇｅｎｔＩＤが追加されることなく、図９（ｂ）のように委譲元のＡｇｅｎｔＩＤに対応するＬａｓｔＣｒａｗｌＴｉｍｅが更新されるようにする。また、下記フローにおいて、アプリケーションサーバ１は、動作不能となりフェールオーバーする対象のサーバとし、アプリケーションサーバ２は、処理が移譲されるサーバとする。また、アプリケーションサーバ１と、アプリケーションサーバ２のログ収集エージェント部が有する設定ファイルに記載されるＤｉｒ４０１５とＦｉｌｅｎａｍｅＲｅｇＥｘ４０１７の文字列は、同じものとする。
【０１１１】
なお、本処理フローは、本実施形態において、各アプリケーションサーバが備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【０１１２】
Ｓ１４０１では、アプリケーションサーバ１上のリクエスト処理部状態監視部３２１３は、アプリケーションサーバ１の動作継続不能を検知する。Ｓ１４０２では、アプリケーションサーバ１は、ログファイルを出力していたフォルダに存在する全てのファイルを、アプリケーションサーバ２上の同一フォルダパス上に存在するフォルダにコピーする。ここで、アプリケーションサーバ１に対応するＩＤファイルも同一フォルダ上に存在するため、ＩＤファイルも同様にコピーされる。
【０１１３】
Ｓ１４０３では、アプリケーションサーバ２は、コピーの成否をアプリケーションサーバ１に通知する。Ｓ１４０４では、アプリケーションサーバ１は、アプリケーションサーバ１から通知されたコピーの成否を確認する。そして、コピーが成功していた場合には（Ｓ１４０４にてＹＥＳ）、Ｓ１４０５に遷移する。また、コピーが失敗していた場合には（Ｓ１４０４にてＮｏ）、Ｓ１４０７に遷移し、フェールオーバー失敗とする。
【０１１４】
Ｓ１４０５では、アプリケーションサーバ２は、ログ収集エージェント部３２２を起動する。ログ収集エージェント部３２２が、起動した後のフローは、図１１にて示したフローと同じであるため、説明は割愛する。Ｓ１４０６では、アプリケーションサーバ２は、アプリケーション部３２１を起動する
以上説明したように、図１１乃至図１４に従って処理することにより、アプリケーションサーバとログサーバとが独立して構築され、複数のユーザから依頼を並列して処理するような大規模システムにおいて、ログを重複して記録することを防止することができる。更に、記録しているログのうち、ある期間のログを出力する際に、重複したログの出力を防止することが可能となる。また、フェールオーバーなどによって、異なるアプリケーションサーバに処理が委譲され、別のログ収集エージェント部が動作した場合にも、委譲元に対応するＩＤを用いることで、ログを漏れなく収集、管理することが出来る。
【０１１５】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【技術分野】
【０００１】
クラウド環境における、ログの管理を行うログ管理システム、ログ管理方法、アプリケーションサーバ、およびログサーバに関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングシステムと呼ばれる技術が注目を集めている。クラウドコンピューティングシステムにおいて、クラウドサービスベンダーは、インターネット上に、仮想的なサーバ（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）やストレージ、また種々のサービスを提供する。アプリケーション開発者は、クラウドサービスベンダーに利用料を支払い、それらのサービスを使用することで、クラウドアプリケーションの開発が可能となる。
【０００３】
ここで、クラウドコンピューティングシステムにおける、ログの管理方法について考える。クラウドサービスでは、複数のサーバ（ＶＭ）上でサービスが提供されており、それぞれのサービスで、ログが出力される。特許文献１では、サーバ上に実装されたクライアントが、各サーバ上で出力されたログをログ管理サーバに送信する。これにより、ログの一元的な管理が可能となり、ログの集計や、表示、出力といった作業のパフォーマンス、および効率を上げることが出来る。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−０７２９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
クラウドサービスのように、多くのユーザが使用し、かつ、異なる人物が、同じユーザＩＤ（アカウント）等を用いてログイン可能なシステムを考える。このとき、各ユーザが同一のイベント（例えば、プリント等）の処理を行うことが可能であるため、イベントを特定する項目からのみでは、収集したログが、すでに保持管理しているログと重複しているかどうかの判断はできない。
【０００６】
また、あるクライアントがログを送信できない状態に陥っている場合に、サーバがログの集計を行うと、あるクライアントから集めるべきログが収集できないため、その間のログの記録漏れが発生する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本願発明は以下の構成を有する。すなわち、ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムであって、前記アプリケーションサーバは、ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段とを有し、前記ログサーバは、前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理システム。
【発明の効果】
【０００８】
本発明により、複数のユーザからの要求に応じて並行して処理を行うシステムにおいて、処理を行った結果としてのログに対し、重複したログの保存を防止し、かつ、ログの記録漏れを避けることが可能となる。
【図面の簡単な説明】
【０００９】
【図１】システム構成図。
【図２】アプリケーションサーバ１０２のハードウェア構成図。
【図３】機能ブロック図。
【図４】ログ収集部の設定ファイルの記述例を示す図。
【図５】ログフィルタのＩ／ＦおよびＬｏｇＤａｔａクラスの定義例を示す図。
【図６】ＩＤファイルの記述例を示す図。
【図７】レコードを初期登録した際のレコードファイルの記述例を示す図。
【図８】ログＤＢの構成例を示す図。
【図９】ステータスＤＢの構成例を示す図。
【図１０】アーカイブアプリケーションの設定ファイルの記述例を示す図。
【図１１】ログ収集部の起動、およびＩＤファイルの作成に関するフローチャート。
【図１２】ログ収集部のログ収集に関するフローチャート。
【図１３】バッチアプリケーションサーバのログ出力に関するフローチャート。
【図１４】フェールオーバー時のアプリケーションサーバの処理のフローチャート
【発明を実施するための形態】
【００１０】
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。
【００１１】
［システム構成］
図１は、本発明の一実施形態に係るログ管理システムの全体構成を示している。ネットワーク１００を介して、ＰＣ１０１、アプリケーションサーバ１０２、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５が接続されている。アプリケーションサーバ１０２は、ＰＣ１０１からのネットワーク１００を介して送信されるリクエストを受信し、処理を行う。ログサーバ１０３は、アプリケーションサーバ１０２から送信されるログを受信し、ストレージサーバ１０４に保存させる機能、および、バッチアプリケーションサーバ１０５からのログデータの出力要求を受信し、該当の処理を行う機能を備える。ストレージサーバ１０４は、ログサーバ１０３が収集したログを保存する。
【００１２】
ネットワーク１００は、上述の各装置間での情報をやりとりのための通信回線として働き、有線、無線と回線の形態は問わない。また、ネットワーク１００は、インターネットなどの外部ネットワークやＬＡＮなどの内部ネットワークを組み合わせて構成されるものとする。
【００１３】
また、図１において、２台のアプリケーションサーバ１０２を示しているが、これに限定するものではない。同様に各サーバも１台構成に限定するものではなく、複数台の物理的な構成を備えていても構わない。また、本実施形態において、各サーバを機能ごとに別個の装置として示しているが、単一の装置にて実現するようにしても構わない。例えば、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５を１台の装置にて構成するようにしても構わない。また、物理的に１台の装置において複数のＶＭが動作するように構成してもよいし、複数の物理的な装置が協働して複数のＶＭが動作するように構成してもよい。
【００１４】
［ハードウェア構成］
図２は、本発明の一実施形態に係るハードウェア構成を示している。なお、図１に示した各装置も同様の構成を有するものとし、ここではアプリケーションサーバ１０２を例にとって説明する。
【００１５】
アプリケーションサーバ１０２は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、直接記憶部２０２、間接記憶部２０３、およびネットワークインタフェース２０４を備える。ＣＰＵ２０１は、各記憶部に格納された所定のプログラムを実行し、アプリケーションサーバ１０２の各種制御を指示するユニットである。直接記憶部２０２は、ＣＰＵ２０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０１が実行するプログラムは直接記憶部２０２にロードされる。直接記憶部２０２は、ＲＡＭ（Ｒａｎｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。間接記憶部２０３は、アプリケーションプログラム、およびＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を含む各種プログラムが記憶されている。
【００１６】
間接記憶部２０３に記憶されている各種プログラムは、ＣＰＵ２０１がプログラムを実行する際に直接記憶部２０２へ読みだされる。間接記憶部２０３は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）、または、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）により実現される。なお、ＣＰＵ２０１は、マルチプロセッサでも良い。また、アプリケーションサーバ１０２内の各構成要素は、内部バス（不図示）によって互いに通信可能なように接続されている。ネットワークインタフェース２０４は、ネットワーク１００に接続されており、ネットワーク１００に接続されている他の装置と通信が可能となる。ＰＣ１０１、ログサーバ１０３、ストレージサーバ１０４、およびバッチアプリケーションサーバ１０５も同様のハードウェア構成をしているため、説明は割愛する。また、各装置は、ここに示していない構成要素を備えていても構わず、汎用的なコンピュータにて実現可能である。
【００１７】
［ソフトウェア構成］
図３は、本発明の一実施形態に係るシステムを構成する各装置の機能ブロック図（ソフトウェア構成）を示す。まず、ＰＣ１０１についての説明を行う。ＰＣ１０１は、ネットワーク通信部３１３、ユーザインタフェース３１２、ウェブブラウザ３１１から構成される。ユーザインタフェース３１２は、ユーザが、ＰＣ１０１によって提供される各種アプリケーション（不図示）を使用するためのインタフェースである。これを介して入力されるユーザ操作に従って、ＰＣ１０１は、各種アプリケーションを実行する。アプリケーションの１種であるウェブブラウザ３１１は、ネットワーク１００を介して、ネットワーク通信部３１３から送受信される情報に応じて、各種情報の表示を行う。
【００１８】
ウェブブラウザ３１１は、図２の間接記憶部２０３に保存されているプログラムが、直接記憶部２０２にロードされ、ＣＰＵ２０１により実行されることで実現される。本実施形態では、ＰＣ１０１を操作するユーザが、ユーザインタフェース３１２、ネットワーク通信部３１３を介してアプリケーションサーバ１０２のリクエスト処理部３２１１と通信を行い、データの送受信を行う。
【００１９】
次に、アプリケーションサーバ１０２上に実装されるアプリケーション部３２１に含まれるリクエスト処理部３２１１、ログファイル出力部３２１２、リクエスト処理部状態監視部３２１３に関して説明する。リクエスト処理部３２１１は、ＰＣ１０１からのリクエストを受信し、受信した内容に応じた処理を行う。例えば、アプリケーションサーバ１０２がオンライン上でのプリントサービスを実現しているとする。ユーザは、ＰＣ１０１を用いて印刷をする対象のドキュメントを選択し、また印刷設定などを指定し、アプリケーションサーバ１０２に対して、印刷処理のリクエストを送信する。アプリケーションサーバ１０２は、受信したリクエストに従ってドキュメントを印刷可能な形式に変換し、プリントサーバ（不図示）に送信するといった処理を行う。
【００２０】
ここでは、一例としてプリントシステムの例を述べたが、アプリケーションサーバ１０２にて実現される機能に制限は存在しない。リクエスト処理部３２１１は、一般的なＷｅｂサーバと同等の機能を持ち、同期処理を行うことが可能である。リクエスト処理部３２１１は、ネットワーク１００を介して、別のアプリケーションサーバ１０２と通信することも可能である。また、リクエスト処理部３２１１は、定期的にリクエスト処理部状態監視部３２１３に対して、動作中を表すパケットを送信する。
【００２１】
ログファイル出力部３２１２は、リクエスト処理部３２１１の処理内容に応じて、その処理のログをファイルに出力する。この際、出力されるログには、そのリクエストに対する処理が行われた時間が記録されている必要がある。その他の項目（例えば、ユーザカウントや、処理の内容に関するログ）に関しては、任意の項目を出力してもよい。ログのフォーマットに関する制約は特に存在せず、任意のフォーマット、例えばコンマ区切りやタブ区切り等、種々の形式での出力が可能である。また、処理内容やアプリケーションごとに、異なるファイルにログを出力することができる。
【００２２】
リクエスト処理部状態監視部３２１３は、リクエスト処理部３２１１から定期的にパケットが送信されてくるか否かを監視する。パケットが送信されてこなかった場合には、リクエスト処理部状態監視部３２１３は、リクエスト処理部３２１１が動作継続不能状態になっているものとし、フェールオーバーを行う。フェールオーバーのフローに関しては、図１４を用いて後述する。
【００２３】
次に、アプリケーションサーバ１０２上に実現されるログ収集エージェント部３２２に関して説明する。ログ収集エージェント部３２２は、複数の処理部（ログデータ収集部３２２１、ログデータ送信部３２２２、ステータス送信部３２２３、ログフィルタ部３２２４、およびＩＤ管理部３２２５）から構成される。以下に、各処理部の説明を記載する。
【００２４】
まず、ログデータ収集部３２２１は、ログファイル出力部３２１２がファイルに出力したログファイルから、ログを読み込む。前述したようにログファイル出力部３２１２は、任意のフォーマットで記述されたログをファイルに出力する。ストレージサーバ１０４のログＤＢ部３４１に定義されたスキーマに沿ってログを保存するためには、任意のフォーマットで記載されたログを、スキーマに従った形式に変換する必要がある。そこで、ログフィルタ部３２２４を用いて、ファイルに記載されたログのフォーマットを、スキーマに適する形式に変換する。
【００２５】
ログフィルタ部３２２４は、ログデータ収集部３２２１から渡されたログをスキーマに従った形式に変換し、ログデータ収集部３２２１に返す。ログフィルタ部３２２４が適切な形式に変換することにより、任意のフォーマットへの対応が可能となる。ログフィルタ部３２２４の詳細については図５を用いて説明する。ここで、１つのアプリケーションサーバ１０２には、複数のログ収集エージェント部３２２を動作させることが出来る。ログ収集エージェント部３２２は、設定ファイルを備え、それぞれに対して、収集対象とするログファイルの名前等を定義することが出来る。
【００２６】
また、ログフィルタ部３２２４も、それぞれに対して設定することが出来る。これにより、例えばログファイル出力部３２１２が複数のログファイルを、異なるフォーマットで出力する場合にも、対応することが出来る。
【００２７】
ログデータ収集部３２２１は、ログフィルタ部３２２４によって変換されたログデータを、ログデータ送信部３２２２に渡す。ログデータ送信部３２２２は、ログデータ収集部３２２１から渡された、ログデータをログＤＢリクエスト処理部３３１に送信する。ログＤＢリクエスト処理部３３１は、受信したログデータをログＤＢ部３４１に保存する。ログＤＢ部３４１に保存されるログデータには、時刻やログを発生させる処理を行ったユーザＩＤ、処理の内容等の情報が記載されており、それらの情報を基にユーザに対して、サービスの使用量に応じた請求をすることも可能である。ログＤＢ部３４１のスキーマについては後述する。
【００２８】
また、ログデータ収集部３２２１は、ログデータの送信処理が正常に終了した場合には、ステータス送信部３２２３に対して、ログファイルからログを収集した時刻を通知する。ステータス送信部３２２３は、その時刻をステータスＤＢリクエスト処理部３３３に送信する。この際、ログ収集エージェント部３２２を識別するための情報として、各ログ収集エージェント部に対して割り当てられたＩＤを対応付けて送信する。ステータスＤＢリクエスト処理部３３３は、受信したＩＤと時刻との組を、ストレージサーバ１０４のステータスＤＢ部３４２に保存する。このＩＤと時刻との組をステータスとして扱い、ステータスはステータスに含まれるＩＤを備えるログ収集エージェント部３２２が何時までのログを保存しているかを示す情報となる。
【００２９】
また、ログ収集エージェント部３２２には、ＩＤを発行するための処理部として、ＩＤ管理部３２２５が存在する。ＩＤ管理部３２２５は、ログ収集エージェント部３２２の起動と同時に処理を開始し、当該ログ収集エージェント部に固有のＩＤを発行し、ログデータ収集部３２２１にそのＩＤ情報を通知する。このＩＤは、アプリケーションサーバ１０２上のファイル（ＩＤファイル）として管理される。ＩＤファイルのフォーマット、ファイル名、および保存パス等に関しては図６を用いて後述する。
【００３０】
次に、バッチアプリケーションサーバ１０５に含まれる各処理部を説明する。バッチアプリケーションサーバ１０５上では、ログＤＢ部３４１に格納されたログを出力するためのアプリケーション（アーカイブアプリケーション）が実装されている。まず、取得日時指定部３５１では、ログＤＢ部３４１から取得する時刻の範囲を指定し、その範囲を、ログデータ取得部３５３に対して通知する。
【００３１】
次に、ステータス確認部３５２は、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ステータス取得のリクエストを送信する。また、ステータス確認部３５２は、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、ログＤＢ部３４１に保存されているログの中で、最も古い時刻を持つログの時刻の取得リクエストを送信する。ログＤＢリクエスト処理部３３１はリクエストを受信したら、ログＤＢ部３４１に格納されているログの時刻から、最も古い時刻を取得し、ステータス確認部３５２に送信する。その後、ステータス確認部３５２は、受信した最も古い時刻のログの時刻と、ステータスに記録されている時刻とをログデータ取得部３５３に通知する。
【００３２】
ログデータ取得部３５３は、取得日時指定部３５１、およびステータス確認部３５２から通知された時刻を比較する。比較のロジックに関しては、後述のフローチャートの説明にて詳細に述べる。比較の結果、取得日時指定部３５１より通知された範囲のログデータの取得が可能と判断した場合には、ログＤＢリクエスト処理部３３１に対してログ取得要求のリクエストを送信する。ログＤＢリクエスト処理部３３１は、リクエストを受信したら、ログＤＢ部３４１からログを取得し、ログデータ取得部３５３に送信する。ログデータ取得部３５３は、受信したデータをログデータ出力部３５４に渡す。ログデータ出力部３５４は、受け取ったログデータの形式を整形し、ファイルに出力する。
【００３３】
次に、ログサーバ１０３について説明する。まず、ログＤＢリクエスト処理部３３１は、アプリケーションサーバ１０２、およびバッチアプリケーションサーバ１０５から送信されるストレージサーバ１０４のログＤＢ部３４１に対する処理に関するリクエストを受信する。そして、ログＤＢリクエスト処理部３３１は、受信したリクエストに応じた処理を行う。また、ログＤＢリクエスト処理部３３１は、リクエストを受信した際には、ログＤＢＩ／Ｏ部３３２に対して、処理のリクエストを送信する。ログＤＢＩ／Ｏ部３３２は、ログＤＢリクエスト処理部３３１から受信したリクエストに応じた処理をログＤＢ部３４１に対して実行する。同様に、ステータスＤＢリクエスト処理部３３３は、アプリケーションサーバ１０２、およびバッチアプリケーションサーバ１０５から送信されるステータスＤＢ部３４２に対する処理に関するリクエストを受信する。そして、ステータスＤＢリクエスト処理部３３３は、受信したリクエストに応じた処理を行う。また、ステータスＤＢリクエスト処理部３３３は、リクエストを受信した際には、ステータスＤＢＩ／Ｏ部３３４に対して、処理のリクエストを行う。ステータスＤＢＩ／Ｏ部３３４は、ステータスＤＢリクエスト処理部３３３から受信したリクエストに応じた処理をステータスＤＢ部３４２に対して実行する。
【００３４】
次に、ストレージサーバ１０４について説明する。ログＤＢ部３４１は、ログサーバ１０３を介して収集した各ログを蓄積し、保存する。ステータスＤＢ部３４２は、アプリケーションサーバ１０２が有する各ログ収集エージェント部のステータスとＩＤとを対応付けて保持する。ここでのデータ構造に関しては、図８を用いて後述する。また、各ＤＢ（データベース）部は、ストレージサーバ１０４が備える間接記憶部等によって実現される。
【００３５】
［ログ収集エージェント部の設定ファイル］
図４を用いて、各ログ収集エージェント部が備える設定ファイルに設定可能な項目の説明を行う。まずログフィルタ部３２２４に関する設定項目であるフィルタ名４０１１、およびアセンブリ名４０１２に関して説明する。本実施形態において、アプリケーションサーバ１０２は、ＶＭの技術を利用して物理的な１台の装置において、複数の仮想的に異なるサーバを提供することができる。この場合には、設定ファイルも１台の装置の中に複数保持することとなる。前述したようにログ収集エージェント部３２２はログフィルタ部３２２４を備える。ログフィルタ部３２２４は、収集対象のログファイルのフォーマットによって変わりうるため、ログデータ収集部３２２１を変更することなく、ログフィルタ部３２２４を変更可能なようにすることが望ましい。そこで、実行時にリンクすることが可能な形式（例えば、Ｗｉｎｄｏｗｓ（登録商標）であればｄｌｌ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）ファイル）で、ログフィルタ部３２２４を実装する。
【００３６】
また、設定ファイルに、そのアセンブリパスを記載し、ログデータ収集部３２２１が実行時に、動的に読み込むことが出来るようにすることで、ログフィルタ部３２２４を容易に変更可能とする。ここで、設定ファイル中のｌｏｇＦｉｌｔｅｒタグは複数作成することが出来、複数のログフィルタ部に関する設定を１つの設定ファイルに記述することが出来る。その際、各ｌｏｇＦｉｌｔｅｒタグに割り振られたフィルタ名４０１１は一意となるように設定する必要がある。
【００３７】
次にａｇｅｎｔタグについて説明する。ａｇｅｎｔタグには、ログデータ収集部３２２１に関する設定を記述する。以下に設定項目に関する説明を述べる。Ａｇｅｎｔ名４０１３は、ａｇｅｎｔを一意に識別する名前である。ａｇｅｎｔタグは、複数記述することが出来、各ａｇｅｎｔタグに割り当てられたＡｇｅｎｔ名４０１３はログデータ収集部３２２１を特定するために一意となる必要がある。
【００３８】
次に、ｉｎｔｅｒｖａｌ４０１４には、ａｇｅｎｔ（ログデータ収集部３２２１）の起動間隔を設定する。指定された間隔に応じて、ログデータ収集部３２２１は、各サービスのログファイルからのログの読み込み処理を行う。ｄｉｒ４０１５は、ログデータ収集部３２２１が、収集を行う対象のログファイルが存在するフォルダパスを記述する。また、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７は、収集対象のファイル名の正規表現を記載する。ログデータ収集部３２２１は、ｄｉｒ４０１５に存在し、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致する全てのファイルを収集対象とする。
【００３９】
ｉｎｃｌｕｄｅＳｕｂＤｉｒ４０１６には、ｄｉｒ４０１５以下に存在するサブフォルダに含まれるログも、収集対象とする否かを設定する。ｌｏｇＦｉｌｔｅｒ−ｒｅｆ４０１８には、使用するフィルタ名４０１１を設定する。ここで設定したｌｏｇＦｉｌｔｅｒ名に一致するアセンブリをロードし、ログフィルタ部３２２４を作成する。ｌｏｇＳｅｒｖｅｒ４０１９、およびｓｔａｔｕＳｅｒｖｅｒ４０２０には、ログデータ収集部３２２１が接続するログＤＢリクエスト処理部３３１、およびステータスＤＢリクエスト処理部３３３のアドレスを設定する。ログ収集エージェント部３２２は、その起動時にこの設定ファイルを読み込み、その設定に従って処理を行う。詳細な処理フローに関しては、図１２を用いて後述する。
【００４０】
［ログフィルタＩ／Ｆ］
図５（ａ）に、ログフィルタＩ／Ｆの定義例を示す。ログ収集エージェント部３２２のログフィルタ部３２２４を作成する場合には、ログフィルタＩ／Ｆ５０１を実装したモジュールを作成する必要がある。図５（ａ）に示した例では、プログラミング言語としてＣ＃を選択し、Ｃ＃に基づいたＩ／Ｆ定義の例を記載している。しかしながら、プログラミング言語を限定するものではなく、ログ収集エージェント部３２２がロードできるモジュールの作成が可能であれば、いずれのプログラム言語を用いても構わない。
【００４１】
プログラム言語としてＣ＃を用いた場合、図５（ａ）に示すようにインタフェース定義部分は、クラス５０１１、戻り値５０１２、関数５０１３、引数５０１４から構成される。ログフィルタ部３２２４の作成者は、クラス５０１１を継承したクラスを作成したクラスを作成し、そのクラスで関数５０１３を備える関数を実装する。この関数には、ログ収集エージェント部３２２がログファイルから読みだした１行の文字列が引数５０１４に与えられる。ログフィルタ部３２２４の作成者は、引数５０１４を解析し、図５（ｂ）に示す様なプロパティを備えるクラスを作成し、戻り値５０１２として返す関数を実装する。
【００４２】
図５（ｂ）に、ＬｏｇＤａｔａクラスのプロパティの定義例を示す。本プロパティの定義も同様に、プログラミング言語としてＣ＃を用いた場合の定義例を示している。
【００４３】
以下に、各プロパティの説明を記載する。ＴｉｍｅＳｔａｍｐ５０２１は、ログに記載されている時刻（タイムスタンプ）を設定するためのプロパティである。ＴｅｎａｎｔＩｄ５０２２には、ログを出力するきっかけとなった操作を行ったユーザが所属するテナント（会社、組織）を識別するためのＩＤを設定するためのプロパティである。ＵｓｅｒＩｄ５０２３は、ログを出力する起因となった操作を行ったユーザを識別するためのＩＤを設定するためのプロパティである。ＳｅｒｖｉｃｅＩｄ５０２４は、ユーザが行った操作の内容、例えば、Ｐｒｉｎｔ、Ｓｃａｎといった操作の種類を表すためのＩＤである。最後に、ＯｂｊｅｔｃｔＩＤ５０２５には、処理の対象、例えばプリントの場合であれば、プリントしたドキュメントの名前などを設定するためのプロパティである。
【００４４】
図５（ｂ）における本定義例では、上記５つのプロパティを定義したが、これに限定するものではない。その他の項目をログとして記録したい場合には、ＬｏｇＤａｔａクラス５０２にプロパティを追加し、関数５０１３の実装にて、その項目に値を設定するように、ログフィルタ部３２２４の実装を行う。また、ＴｉｍｅＳｔａｍｐ５０２１以外の項目をログとして記録しない場合には、プロパティをクラスの定義から削除しても構わない。
【００４５】
［ＩＤファイル］
図６を用いて、ＩＤファイルの説明を行う。本実施形態に係るＩＤファイルは図６に示す様なスキーマによって構成される。ＩＤファイルはａｇｅｎｔＩｄ６０１１タグから構成され、その属性であるｉｄには、ログ収集エージェント部３２２を一意に識別するための識別子（ＧＵＩＤ：Ｇｌｏｂａｌ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）を設定する。ＧＵＩＤは、ログ収集エージェント部３２２が起動する際に、ログ収集エージェント部３２２自身で作成する。この作成されるＩＤファイルは、前述したログ収集エージェント部３２２の設定ファイルにおいてｄｉｒ４０１５が示すフォルダに保存される。もし、フォルダが存在しない場合には、ログ収集エージェント部３２２は起動しない。また、ＩＤファイルのファイル名は、設定ファイルのｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７から生成される文字列を使用する。
【００４６】
前述したようにｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７には正規表現が設定されるため、「？」や「￥」等のファイル名には指定出来ない文字列が設定される可能性がある。そのため、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に指定された文字列から、ファイル名に使用できる文字列への変換処理を行う。具体的には、Ｂａｓｅ６４エンコーディングを用いて文字列変換することや、「￥」などの文字列を「ｂｓ」などの文字列に置き換えることがあげられる。ここで、変換の際の条件として、変換前の文字列と変換後の文字列が写像関係になっていることが挙げられる。
【００４７】
なお、本実施形態では、１台の物理的な装置の中に複数のＶＭ（アプリケーションサーバ）を動作させている場合には、各ＶＭそれぞれのログ収集エージェント部３２２ごとにＩＤファイルが生成されることとなる。
【００４８】
［レコードファイル］
前述したように、ログデータ収集部３２２１は、定期的にログファイルを読み込む。そして、ログデータ収集部３２２１は、新規に追加されたログのみに対して、ログフィルタ部３２２４を用いて整形し、ストレージサーバ１０４のログＤＢ部３４１にログデータを格納する。このように新規に追加されたログのみを対象とすることで、パフォーマンスを向上させることが出来る。新規に追加されたログのみを対象とするために、前回の収集時に、ログデータ収集部３２２１が収集を行ったファイルの位置や、収集を行った時間などを記録する必要がある。そのデータを、ログの収集状況を示すレコードファイルと呼ばれるファイルに記載する。ここで、レコードファイルはログ収集エージェント部３２２が存在するフォルダに、動的に作成される。また、レコードファイルのファイル名は、ログ収集エージェント部３２２の設定ファイルにおいて、Ａｇｅｎｔ名４０１３の末尾に「．ｘｍｌ」を追記したファイル名とする。
【００４９】
図７を用いて、本実施形態に係るレコードファイルの説明を行う。レコードファイルは、図７に示す様な形式のファイルである。ｒｅｃｏｒｄタグは、ｆｉｌｅｎａｍｅ７０１１、ｕｐｄａｔｅＴｉｍｅ７０１２、ｏｆｆｓｅｔ７０１３、ｌｉｎｅＮｕｍｂｅｒ７０１４の４つの属性から構成される。ｒｅｃｏｒｄタグは、ログデータ収集部３２２１が収集対象とするファイルの数だけ作成される。ｆｉｌｅｎａｍｅ７０１１は、ログデータ収集部３２２１が収集しているログファイルの名称が設定される。ｕｐｄａｔｅＴｉｍｅ７０１２には、ログデータ収集部３２２１が、前回の収集を行った時間を設定する。ｆｉｌｅｎａｍｅ７０１１が示すファイルに対して、過去に収集処理を行っていない場合には、初期値として“１９７０／０１／０１ ００：００：００”が設定される。
【００５０】
ｏｆｆｓｅｔ７０１３には、ログデータ収集部３２２１が収集が完了した個所への、ファイル先頭からのバイト数（データサイズ）が設定される。最後に、ｌｉｎｅＮｕｍｂｅｒ７０１４には、収集が完了したログの行番号が設定される。ｆｉｌｅｎａｍｅ７０１１が示すファイルに対して、収集処理を行っていない場合には、ｏｆｆｓｅｔ７０１３、およびｌｉｎｅＮｕｍｂｅｒ７０１４には、“０”が設定される。ログデータ収集部３２２１は、前述したｉｎｔｅｒｖａｌ４０１４毎に起動し、レコードファイルを読み込む。その後、ｆｉｌｅｎａｍｅ７０１１の更新時間をチェックし、その時間とｕｐｄａｔｅＴｉｍｅ７０１２とを比較する。ｕｐｄａｔｅＴｉｍｅ７０１２の方が古い場合には、ログデータ収集部３２２１は、ファイル先頭からｏｆｆｓｅｔ７０１３が示すバイト数だけファイルを移動し、ログの収集を開始する。ログの収集が完了した場合には、各項目の更新を行う。このようにすることで、新規に追加されたログのみを収集することが出来る。図７にはＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のフォーマットで各情報が記載されているが、ＸＭＬ形式である必要はなく。コンマ区切り（ＣＳＶ形式）等で、各項目が記載されていても問題はない。
【００５１】
［ログＤＢ］
図８を用いて、本実施形態に係るログＤＢ部３４１にて保持されるログＤＢ８０１の説明をする。まず、ログＤＢ８０１に必要な項目としては、ＴｉｍｅＳｔａｍｐ８０１１、ＡｇｅｎｔＩＤ８０１２、ＦｉｌｅＮａｍｅ８０１３、ＬｉｎｅＮｕｍｂｅｒ８０１４の４つの項目が存在する。ＴｉｍｅＳｔａｍｐ８０１１には、そのログに記録されている事象が発生していた時間が格納される。ＡｇｅｎｔＩＤ８０１２には、そのログを収集したログ収集エージェント部３２２が有する、ＩＤファイルに記載されているＩＤが格納される。ＦｉｌｅＮａｍｅ８０１３には、そのログが記録されていたログファイルのファイルパスが記載される。最後にＬｉｎｅＮｕｍｂｅｒ８０１４には、そのログのログファイルに置ける行番号が格納される。
【００５２】
これらの４つの項目は、ログＤＢ部３４１のログＤＢ８０１への、同じログを２度以上重複して記録すること（以下、２重記録）を防ぐために必要となる。例えば、前述したレコードファイルが、何らかの理由で読み込めなくなった場合、ログデータ収集部３２２１は、収集対象のフォルダに存在する全てのファイルの先頭から、再度収集を行ってしまう。その際、すでに収集したログをログＤＢ部３４１に再度格納するため、その結果として２重記録が発生する。そこで、本実施形態では、上記４つの項目が一意となるようにログＤＢ８０１に制約を張る。例えば、ＲＤＢＭＳ（Ｒｅｌａｔｉｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｅｔ Ｓｙｓｔｅｍ）の場合には、上記４つの項目をＵｎｉｑｕｅとなるように制約を張ることで、２重記録防止の対応が可能となる。また、Ｋｅｙ−Ｖａｌｕｅ Ｓｔｏｒｅの場合には、上記４つの文字列の組み合わせをキーとして定義することで、同じキーを持つデータの格納が出来なくなり、重複した記録を防止する対応が可能となる。
【００５３】
上記４つの項目以外の項目に関しては、ログとして残す必要がある項目に応じて、任意に追加することが可能である。例えば、図８の場合、ＴｅｎａｎｔＩＤ８０１５、ＵｓｅｒＩＤ８０１６、ＳｅｒｖｉｃｅＩＤ８０１７、ＯｂｊｅｃｔＩＤ８０１８がログの項目として列挙されている。ＴｅｎａｎｔＩＤ８０１５には、その処理を行ったユーザが所属する組織（例えば会社等）が記録される。ＵｓｅｒＩＤ８０１６には、その処理を行ったユーザを特定するための情報が記録される。ここで、ＵｓｅｒＩＤのみでそのユーザが特定される必要はなく、例えばＴｅｎａｎｔＩＤとの組み合わせでそのユーザを一意に特定できればよい。
【００５４】
ＳｅｒｖｉｃｅＩＤ８０１７には、そのユーザが使用したサービスのＩＤが記録される。例えばユーザ追加機能や、Ｐｒｉｎｔ、Ｓｃａｎといった機能のサービスＩＤが記録される。最後に、ＯｂｊｅｃｔＩＤ８０１８には、処理を行った対象が記録される。例えばユーザの追加処理（Ａｄｄ Ｕｓｅｒ）であれば、追加されたユーザＩＤが記録される。また、Ｐｒｉｎｔや、Ｓｃａｎであれば、その対象のドキュメント名などが記録される。上記で上げた項目以外を記録した場合には、その項目のカラムなどを追加することで、新しい項目を記録することが可能となる。
【００５５】
なお、本実施形態では、ＴｉｍｅＳｔａｍｐ８０１１、ＡｇｅｎｔＩＤ８０１２、ＦｉｌｅＮａｍｅ８０１３、ＬｉｎｅＮｕｍｂｅｒ８０１４の４つの項目をキーとして、ログを格納するか否かを判定している。しかし、これに限定するものではなく、ＡｇｅｎｔＩＤ８０１２以外の項目については、これらの項目のうちのいずれかであってもよいし、更に別の項目を追加するようにしてもよい。つまり、ＡｇｅｎｔＩＤ８０１２を必須のキー項目とし、更に１以上の他のキー項目の情報を用いて、ログの特定を行うようにすることができる。なお、ここで用いる項目を変更する場合には、図５（ｂ）に示すＬｏｇＤａｔａクラス５０２にて取得する情報も変更する必要が有る。
【００５６】
［ステータスＤＢ］
図９（ａ）、（ｂ）を用いて、本実施形態に係るステータスＤＢ部３４２にて保持されるステータスＤＢの説明を行う。ストレージサーバ１０４のステータスＤＢ部３４２には、ステータスＤＢとしてログ収集エージェント部３２２のＩＤ（ＡｇｅｎｔＩＤ９０１１、９０２１）と、そのログ収集エージェント部３２２がログの収集をした時刻（ＬａｓｔＣｒａｗｌＴｉｍｅ９０１２、９０２２）とが記録される。このＬａｓｔＣｒａｗｌＴｉｍｅに記録されている時刻は、この時刻までにログファイルに出力されていたログは、全てログＤＢ部３４１に格納されている、という事を保証するための値である。
【００５７】
まず図９（ａ）を用いて、初回登録時に、ステータスＤＢ部３４２に登録される内容についての説明を行う。ログ収集エージェント部３２２は、その起動時にＩＤファイルを読み込む（または作成する）。そこで作成したＩＤをステータスＤＢ部３４２に送信することで、自身のＩＤに対応するデータをステータスＤＢ部３４２に登録する。その際、ＬａｓｔＣｒａｗｌＴｉｍｅ９０１２は、初期登録ステータスを表す時刻（１９７０／０１／０１ ００：００：００）が登録される。本実施形態では、初期登録時刻として、“１９７０／０１／０１ ００：００：００”を使用しているが、例えば現在時刻より１年以上過去の値を使っても特に問題はない。ここで用いられる初期登録の値としての条件は、このシステムを使用する日時とは、等しくならないことである。
【００５８】
ログ収集エージェント部３２２は初期登録後、ログデータ収集部３２２１がログの収集処理を行う。ログ収集エージェント部３２２は、ログＤＢ部３４１へのログの格納処理が成功した後に、ステータスＤＢリクエスト処理部３３３に対して、自身のＩＤと、現在時刻を対応付けて送信する。ステータスＤＢリクエスト処理部３３３は、受信したデータからＩＤを取出し、ＩＤと等しいＡｇｅｎｔＩＤ９０１１、９０２１を有するエンティティのＬａｓｔＣｒａｗｌＴｉｍｅ９０２２を受信した時刻で更新する。このように、ログ収集エージェント部３２２はステータスＤＢ部３４２の更新を行う。
【００５９】
［アーカイブアプリケーションの設定ファイル］
図１０を用いて、本実施形態に係るバッチアプリケーションサーバ１０５で動作する、アーカイブアプリケーション（不図示）の設定ファイル１００００の定義を示す。ここで、アーカイブアプリケーションは、ログＤＢ部３４１に格納されているログデータをファイルに出力する機能を備えるアプリケーションである。アーカイブアプリケーションの設定ファイルは、図１０に記載されているように、ＸＭＬ形式で記載される。ここで、設定ファイルのフォーマットは、ＸＭＬ形式のみではなく、例えばコンマ等で各項目が区切られたＣＳＶ形式（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）などでも良い。
【００６０】
アーカイブアプリケーションは、設定ファイル１００００にて、まずａｒｃｈｉｖｅＳｅｔｔｉｎｇタグを有する。このタグは、ｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１、ｌｏｇＤｂＵｒｉ１０００２、ｓｔａｔｕｓＤｂＵｒｉ１０００３、ｓｔａｒｔＤａｔｅ１０００４、およびｅｎｄＤａｔｅ１０００５から構成される。ｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１は、アーカイブアプリケーションが出力するファイルを保存するディレクトリパスを示す。アーカイブアプリケーションは、日付毎にログを取得し、その取得した日付をファイル名としたファイルを作成する。
【００６１】
例えば、２０１１年１月１日のログを、ＤＢから取得した場合には、「２０１１０１０１．ｃｓｖ」の様なファイル名を有するファイルをｓａｖｅＤｉｒｅｃｔｏｒｙ１０００１が示すフォルダに保存する。ｌｏｇＤｂＵｒｉ１０００２には、ログＤＢリクエスト処理部３３１のアドレスを記述する。ｓｔａｔｕｓＤｂＵｒｉ１０００３には、ステータスＤＢリクエスト処理部３３３のアドレスを記載する。ｓｔａｒｔＤａｔｅ１０００４には、ログを保管する期間の開始日を記載する。図１０に示した例の場合、ログＤＢ部３４１に格納されているログのＴｉｍｅＳｔａｍｐ８０１１が「２０１１年１月５日０時０分０秒」以降のログを対象とする。ｅｎｄＤａｔｅ１０００５は、ログを保管する期間の終了日を記載する。図１０に示した例の場合、ログＤＢ部３４１に格納されているログのＴｉｍｅＳｔａｍｐ８０１１が「２０１１年１月２０日０時０分０秒」未満のログを対象とする。
【００６２】
アーカイブアプリケーションを用いて、ログＤＢ部３４１に格納されているログを外部に保管することが出来る。保管されたログはログＤＢ部３４１からの削除が可能となるため、ストレージ容量の確保、およびストレージの仕様に関するコストを削減することが出来る。また、図１０には示されていないが、設定ファイル１００００内に、ＡｇｅｎｔＩＤを指定するようにしても構わない。この場合には、特定のログ収集エージェント部が収集したログのみを出力するようにもできる。
【００６３】
［フローチャート］
図１１乃至図１４を用いて、本発明における、アプリケーションサーバ１０２、ログサーバ１０３、バッチアプリケーションサーバ１０５、ストレージサーバ１０４の処理の流れを詳細に説明する。
【００６４】
［ログ収集エージェント部の起動］
まず、図１１を用いて、ログ収集エージェント部３２２の起動時の処理の流れについて説明する。本処理フローは、本実施形態において、アプリケーションサーバ１０２、およびログサーバ１０３がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００６５】
Ｓ１１０１では、アプリケーションサーバ１０２のＯＳ（不図示）は、ログ収集エージェント部３２２を起動する。
【００６６】
Ｓ１１０２では、ログ収集エージェント部３２２は、図４に示すような設定ファイルを読み込む。設定ファイルの読み込みに失敗した場合には（Ｓ１１０３にてＮＯ）、Ｓ１１２３に遷移する。設定ファイルの読み込みが成功した場合には（Ｓ１１０３にてＹＥＳ）、Ｓ１１０４に遷移する。
【００６７】
Ｓ１１０４では、ログ収集エージェント部３２２は、設定ファイルに記載されたａｇｅｎｔｓタグに含まれる全ａｇｅｎｔタグの設定に基づいて全てのａｇｅｎｔを生成したかどうかをチェックする。つまり、ログ収集エージェント部３２２は、設定ファイルのａｇｅｎｔｓタブに定義された全てのログデータ収集部を生成したか否かを判定する。全てのａｇｅｎｔタグに基づいてａｇｅｎｔを生成した場合には（Ｓ１１０４にてＹＥＳ）、Ｓ１１１８に遷移する。全てのａｇｅｎｔを生成していない場合には（Ｓ１１０４にてＮＯ）、Ｓ１１０５に遷移する。
【００６８】
Ｓ１１０５では、ログ収集エージェント部３２２は、設定ファイルに記載されたｄｉｒ４０１５で示されたａｇｅｎｔ（ログデータ収集部）によるログの収集対象となるフォルダが存在するかどうかをチェックする。フォルダが存在しない場合には（Ｓ１１０５にてＮＯ）、Ｓ１１２３に遷移する。フォルダが存在していない場合には（Ｓ１１０５にてＹＥＳ）、Ｓ１１０６に遷移する。Ｓ１１０６では、ログ収集エージェント部３２２は、存在しているフォルダ内にｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７から生成されるファイル名を有するＩＤファイルが存在しているかチェックする。ＩＤファイルが存在していない場合には（Ｓ１１０６にてＮＯ）、Ｓ１１０９に遷移する。また、ＩＤファイルが存在している場合には（Ｓ１１０６にてＹＥＳ）、Ｓ１１０７に遷移する。
【００６９】
Ｓ１１０９では、ログ収集エージェント部３２２は、ＩＤファイルを作成し、ファイルにＩＤを記載する。このとき、ファイルの作成に失敗した場合には（Ｓ１１１０にてＮＯ）、Ｓ１１２３に遷移する。ファイルの作成に成功した場合には（Ｓ１１１０にてＹＥＳ）、Ｓ１１１１に遷移する。
【００７０】
Ｓ１１０７では、ログ収集エージェント部３２２は、図６に示すようなＩＤファイルから当該ログ収集エージェント部に対応するＩＤの情報を読み込む。このとき、ＩＤファイルの読み込み処理に失敗した場合には（Ｓ１１０８にてＮＯ）、Ｓ１１２３に遷移する。ＩＤファイルの読み込み処理に成功した場合には（Ｓ１１０８にてＹＥＳ）、Ｓ１１１１に遷移する。
【００７１】
Ｓ１１１１では、ログ収集エージェント部３２２は、図４の設定ファイルに記載されているアセンブリ名４０１２が示すモジュールをロードし、図５に示すログフィルタ部３２２４を作成する。
【００７２】
Ｓ１１１２では、ログ収集エージェント部３２２は、ログデータ収集部３２２１を生成する。Ｓ１１１３では、ログ収集エージェント部３２２は、図４の設定ファイルのＡｇｅｎｔ名４０１３の末尾に「．ｘｍｌ」が追記されたファイル、例えば図７に示すようなレコードファイル、が存在するか否かをチェックする。レコードファイルが存在する場合には（Ｓ１１１３にてＹＥＳ）、Ｓ１１１４に遷移する。レコードファイルが存在しない場合には（Ｓ１１１３にてＮＯ）、Ｓ１１１５に遷移する。
【００７３】
Ｓ１１１４では、ログ収集エージェント部３２２は、レコードファイルを読みこむ。Ｓ１１１５では、ログ収集エージェント部３２２は、レコードファイルを作成する。ここで、レコードファイルには、設定ファイルのｄｉｒ４０１５に指定されたフォルダパスに存在し、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致するファイル名を持つ全ログファイルを、レコードファイルに初期登録する。つまり、図７のレコードファイル７０１に示すｒｅｃｏｒｄタブから構成される要素がログファイルの数だけ登録される。
【００７４】
Ｓ１１１６では、ログ収集エージェント部３２２は、図６に示すような自身のエージェントＩＤをログサーバ１０３のステータスＤＢリクエスト処理部３３３に送信する。Ｓ１１１２では、ログサーバ１０３は、受信したステータスＩＤを用いて、ストレージサーバ１０４のステータスＤＢ部３４２に初期登録する。
【００７５】
Ｓ１１１８では、ログ収集エージェント部３２２は、設定ファイルから生成された全てのログデータ収集部３２２１の処理を開始したか否かを確認する。全てログデータ収集部３２２１が処理を開始していない場合には（Ｓ１１１８にてＮＯ）、Ｓ１１１９に遷移する。全てのａｇｅｎｔタグから生成されたログデータ収集部３２２１が処理開始済みである場合には（Ｓ１１１８にてＹＥＳ）、Ｓ１１２３に遷移する。
【００７６】
Ｓ１１１９では、ログ収集エージェント部３２２は、ログデータ収集部３２２１の処理を開始する。Ｓ１１２０では、ログ収集エージェント部３２２は、ログを収集し、ログサーバ１０３に送信する。この処理の詳細に関しては、図１２を用いたフローチャートの説明にて行う。Ｓ１１２１では、ログサーバ１０３は、受信したデータをストレージサーバ１０４のログＤＢ部３４１に格納する。
【００７７】
Ｓ１１２２では、ログ収集エージェント部３２２は、設定ファイルのｉｎｔｅｒｖａｌ４０１４にて設定された秒数後に、ログデータ収集部３２２１が、処理を再開するようにタイマーを設定し、待機する。そして、所定の時間が経過した場合には、ログデータ収集部３２２１は処理を再開する。Ｓ１１２３では、ログ収集エージェント部３２２は、処理中にエラーが発生したものとし、処理を停止する。
【００７８】
［ログデータ収集部の処理の流れ］
図１２を用いて、ログデータ収集部３２２１の処理の流れについて説明する。本処理フローは、本実施形態において、アプリケーションサーバ１０２、およびログサーバ１０３がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００７９】
Ｓ１２０１では、アプリケーションサーバ１０２のＯＳ／タイマーは、ログデータ収集部３２２１の処理の再開命令を発行する。ここで、再開命令を発行する場合とは、図１１の１１２２にて示したように、待機状態にあるログデータ収集部３２２１の処理を再開させる場合が該当する。Ｓ１２０２では、ログデータ収集部３２２１は、ログ収集エージェント部３２２の停止命令の有無をチェックする。停止命令があった場合には（Ｓ１２０２にてＹＥＳ）、Ｓ１２１７に遷移する。また、停止命令がなかった場合は（Ｓ１２０２にてＮＯ）、Ｓ１２０３に遷移する。
【００８０】
Ｓ１２０３では、ログデータ収集部３２２１は、図４に示す設定ファイルのｄｉｒ４０１５に記載のフォルダパスに存在し、かつ、ｆｉｌｅｎａｍｅＲｅｇＥｘ４０１７に一致するファイル名を有するファイルの一覧を取得する。Ｓ１２０４では、ログデータ収集部３２２１は、Ｓ１２０３で取得したファイルの一覧の中で、レコードファイルに記録されていないファイル名を有するファイルを、レコードファイルに初期登録する。
【００８１】
Ｓ１２０５では、ログデータ収集部３２２１は、レコードファイルに記録された、ｕｐｄａｔｅＴｉｍｅ７０１２と、ファイルの更新時間とを比較し、ｕｐｄａｔｅＴｉｍｅ７０１２が示す時間以降に更新されたファイルの一覧を取得する。Ｓ１２０６では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧の数を確認する。ファイルの数が“０”、つまり更新されたログファイルが存在しない場合には（Ｓ１２０６にてＮＯ）、Ｓ１２１３に遷移する。また、ファイルの数が１以上、つまり更新されたファイルが存在する場合には（Ｓ１２０６にてＹＥＳ）、Ｓ１２０７に遷移する。
【００８２】
Ｓ１２０７では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧に対して、Ｓ１２０８乃至Ｓ１２１１の処理を行ったかどうかを確認する。つまり、ログデータ収集部３２２１は、全ログファイルを収集済みか否かを判定する。Ｓ１２０８乃至Ｓ１２１１の処理を行っていない場合には（Ｓ１２０７にてＮＯ）、Ｓ１２０８に遷移する。ファイルの一覧に含まれる全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理を行った場合には（Ｓ１２０７にてＹＥＳ）、Ｓ１２１２に遷移する。
【００８３】
Ｓ１２０８では、ログデータ収集部３２２１は、Ｓ１２０５で取得したファイルの一覧に含まれる一つのファイルから、ログを読み込む。そして、ログデータ収集部３２２１は、ログフィルタ部３２２４を用いてログを整形し、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、整形したログを送信する。送信の際には、ログフィルタ部３２２４によって整形されたデータに、ログデータ収集部３２２１が読み込んだファイル名、ログの行数、および自身に割り当てられたＩＤを対応付けて送信する。
【００８４】
Ｓ１２０９では、ログサーバ１０３は、Ｓ１２０８にてログデータ収集部３２２１より送信されたログデータを受信し、そのデータをストレージサーバ１０４のログＤＢ部３４１に格納する。そして、ログサーバ１０３は、ログＤＢ部３４１に格納が成功したかどうかをログデータ収集部３２２１に送信する。
【００８５】
Ｓ１２１０では、ログデータ収集部３２２１は、ログサーバ１０３から送信された処理結果を受信し、ログサーバ１０３によるログの格納が成功したか否かを判定する。処理結果が格納が成功した旨を示す正常終了であれば（Ｓ１２１０にてＹＥＳ）、Ｓ１２１１に遷移する。処理結果が異常終了を示すものであれば（Ｓ１２１０にてＮＯ）、Ｓ１２０７に遷移する。
【００８６】
Ｓ１２１１では、ログデータ収集部３２２１は、レコードファイルを更新する。具体的には、ｕｐｄａｔｅＴｉｍｅ７０１２を現在時刻とし、ｏｆｆｓｅｔ７０１３をファイル末尾のバイト数、ｌｉｎｅＮｕｍｂｅｒ７０１４をファイルの最後の行の行番号とする。レコードファイルの更新後、Ｓ１２０７に遷移する。
【００８７】
Ｓ１２１２では、ログデータ収集部３２２１は、Ｓ１２０５で取得した全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が成功したかどうかを確認する。全てのファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が成功した場合には（Ｓ１２１２にてＹＥＳ）、Ｓ１２１３に遷移する。一つ以上のログファイルに対して、Ｓ１２０８乃至Ｓ１２１１の処理が失敗していた場合には（Ｓ１２１２にてＮＯ）、Ｓ１２１５に遷移する。
【００８８】
Ｓ１２１３では、ログデータ収集部３２２１は、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ＬａｓｔＣｒａｗｌＴｉｍｅを表す時刻と、自身のＩＤとを関連付けたデータを送信する。ここで、送信するＬａｓｔＣｒａｗｌＴｉｍｅを表す時刻は、Ｓ１２０８にてログファイルからログを読み込む前に取得した時刻とする。
【００８９】
Ｓ１２１４では、ログサーバ１０３は、ログデータ収集部３２２１より送信された、ＩＤとＬａｓｔＣｒａｗｌＴｉｍｅとが関連付けられたデータを受信する。受信した後に、ログサーバ１０３は、受信したＩＤと等しいＡｇｅｎｔＩＤを有するステータスＤＢのエンティティに含まれるＬａｓｔＣｒａｗｌＴｉｍｅを、受信したＬａｓｔＣｒａｗｌＴｉｍｅで更新する。
【００９０】
Ｓ１２１５では、ログデータ収集部３２２１は、ログ収集エージェント部３２２の停止命令の有無をチェックする。停止命令があった場合には（Ｓ１２１５にてＹＥＳ）、Ｓ１２１７に遷移する。また、停止命令がなかった場合は（Ｓ１２１５にてＮＯ）、Ｓ１２１６に遷移する。
【００９１】
Ｓ１２１６では、ログデータ収集部３２２１は、設定ファイルのｉｎｔｅｒｖａｌ４０１４に記載されていた秒数後に、Ｓ１２０１の処理が呼び出されるように、タイマーを設定する。Ｓ１２１７では、ログデータ収集部３２２１は、処理を停止する。
【００９２】
［バッチアプリケーションサーバ１０５の処理の流れ］
図１３を用いて、バッチアプリケーションサーバ１０５に存在する、アーカイブアプリケーション（不図示）の処理フローについて説明する。本処理フローは、本実施形態において、ログサーバ１０３、およびバッチアプリケーションサーバ１０５がそれぞれ備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【００９３】
Ｓ１３０１では、アーカイブアプリケーションは、図１０に示す設定ファイルに記載されているＳｔａｒｔＤａｔｅ１０００４、およびＥｎｄＤａｔｅ１０００５から、ログを保管する期間を取得する。以下の説明においては、ＳｔａｒｔＤａｔｅ１０００４が表す時間を「ログ取得開始日」、ＥｎｄＤａｔｅ１０００５が示す時間を「ログ取得終了日」と記載する。Ｓ１３０２では、アーカイブアプリケーションは、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、ログ取得可能範囲の終了日の取得要求を発行する。
【００９４】
Ｓ１３０３では、ログサーバ１０３のステータスＤＢリクエスト処理部３３３は、ストレージサーバ１０４のステータスＤＢ部３４２からＬａｓｔＣｒａｗｌＴｉｍｅ９０２２の一覧を取得する。Ｓ１３０４では、ステータスＤＢリクエスト処理部３３３は、取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧に要素が含まれるかどうかを確認する。取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧に要素が含まれていない場合には（Ｓ１３０４にてＮＯ）、Ｓ１３１６に遷移する。また、要素が含まれている場合には（Ｓ１３０４にてＹＥＳ）、Ｓ１３０５に遷移する。
【００９５】
Ｓ１３０５では、ステータスＤＢリクエスト処理部３３３は、Ｓ１３０３で取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧の中に、初期値（本実施形態では、「１９７０／０１／０１」）が存在するか否かを確認する。一覧の中に初期値が存在する場合には（Ｓ１３０５にてＹＥＳ）、Ｓ１３１６に遷移する。また、一覧の中に初期値が存在しない場合には（Ｓ１３０５にてＮＯ）、Ｓ１３０６に遷移する。
【００９６】
Ｓ１３０６では、ステータスＤＢリクエスト処理部３３３は、Ｓ１３０３で取得したＬａｓｔＣｒａｗｌＴｉｍｅの一覧の中で、最も古い時間を取得する。そして、ステータスＤＢリクエスト処理部３３３は、取得した時間を、バッチアプリケーションサーバ１０５のアーカイブアプリケーションに対して送信する。
【００９７】
Ｓ１３０７では、アーカイブアプリケーションは、受信した時間と、ログ取得終了日とを比較する。ここで、Ｓ１３０６で取得した時間が、ログ取得終了日が示す時間よりも新しい場合には（Ｓ１３０８にてＹＥＳ）、Ｓ１３２１に遷移する。また、Ｓ１３０６で取得した時間が、ログ取得終了日が示す時間よりも古い場合には（Ｓ１３０８にてＮＯ）、Ｓ１３０９に遷移する。
【００９８】
Ｓ１３０９では、アーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１に対し、ストレージサーバ１０４のログＤＢ部３４１に存在するログの中で最も古いＴｉｍｅＳｔａｍｐを持つログのＴｉｍｅＳｔａｍｐの取得要求を発行する。
【００９９】
Ｓ１３１０では、ログＤＢリクエスト処理部３３１は、ログＤＢ部３４１の中でも最も古いＴｉｍｅＳｔａｍｐを有するログのＴｉｍｅＳｔａｍｐを取得し、バッチアプリケーションサーバ１０５に対して送信する。
【０１００】
Ｓ１３１１では、アーカイブアプリケーションは、ログサーバ１０３から取得した時間と、ログ取得開始日とを比較する。ここで、ログ取得開始日の方が新しい場合には（ＳＳ１３１２にてＹＥＳ）、Ｓ１３１３に遷移する。また、ログ取得開始日が、取得した時間よりも古い場合には（Ｓ１３１２にてＮＯ）、Ｓ１３２１に遷移する。
【０１０１】
Ｓ１３１３では、アーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１に対して、ログ取得開始日からログ取得終了日の間のログの取得要求を発行する。Ｓ１３１４では、ログサーバ１０３のログＤＢリクエスト処理部３３１は、受信したログ取得開始日からログ取得終了日に該当するＴｉｍｅＳｔａｍｐを有するログを、ログＤＢ部３４１から全て取得する。
【０１０２】
Ｓ１３１４では、ログサーバ１０３のログＤＢリクエスト処理部３３１は、終了コードに正常終了を示す値を設定する。ここで、正常終了を示すコードに対する値の制約は特にない。つまり、正常終了を示すものであれば、コードをどのように定義しても構わない。Ｓ１３１６では、ログＤＢリクエスト処理部３３１は、終了コードに異常終了を示すコードを設定する。
【０１０３】
Ｓ１３１７では、ログＤＢリクエスト処理部３３１は、Ｓ１３１４で取得した全ログデータと、Ｓ１３１５、もしくはＳ１３１６で設定した終了コードとの組をバッチアプリケーションサーバ１０５のアーカイブアプリケーションに送信する。
【０１０４】
Ｓ１３１８では、バッチアプリケーションサーバ１０５のアーカイブアプリケーションは、ログサーバ１０３のログＤＢリクエスト処理部３３１から送信されたログデータの集合と、終了コードとの組を受信する。Ｓ１３１９では、アーカイブアプリケーションは、受信した終了コードがエラーコードであるか、否かを確認する。終了コードが異常終了を示すものである場合には（Ｓ１３１９にてＮＯ）、Ｓ１３２１に遷移する。また、終了コードが正常終了コードである場合は（Ｓ１３１９にてＹＥＳ）、Ｓ１３２０に遷移する。
【０１０５】
Ｓ１３２０では、アーカイブアプリケーションは、受信したログデータを、ＣＳＶ形式に整形して、ファイルに出力する。ここで、出力ファイルのフォーマットはＣＳＶ形式である必要はなく、任意のフォーマットで出力してもよい。Ｓ１３２１にて、アーカイブアプリケーションは、処理を終了する。
【０１０６】
［フェールオーバー時の処理の流れ］
フェールオーバーした際の、アプリケーションサーバ１０２の処理の流れについて説明する。ここで、フェールオーバーとは、一般的にコールドスタンバイや、ホットスタンバイと呼ばれる形式の仕組みを指す。上記の方式では、例えば、あるアプリケーションサーバにおいて処理の継続が不能状態に陥った場合、そのアプリケーションサーバを再起動することで、状態を回復させるのではなく、異なるアプリケーションサーバに処理を移譲する。これにより、システム全体としての処理を継続させ、サービスの提供を復旧させる。
【０１０７】
本システムでは、図９に示すように、ストレージサーバ１０４のステータスＤＢ部３４２に、ＡｇｅｎｔＩＤをキーとし、そのＡｇｅｎｔＩＤと等しいＩＤを有するログ収集エージェント部３２２が記録されている。また、当該ログ収集エージェント部３２２に対応付けて、収集を完了した日時がＬａｓｔＣｒａｗｌＴｉｍｅに記録されている。
【０１０８】
ここで、異なるアプリケーションサーバにて、ログ収集エージェント部３２２が起動したとする。ログ収集エージェント部３２２は、図１１のＳ１１０９にて、新しいＩＤを作成し、Ｓ１１１６にて、ログサーバ１０３のステータスＤＢリクエスト処理部３３３に対して、作成したＩＤを送信し、登録作業を行う。この場合において、図９（ｃ）に示す様に、新しいエンティティ（ＡｇｅｎｔＩＤ「ＣＥ２０９９９７・・・」）がストレージサーバ１０４のステータスＤＢ９０３に登録される。
【０１０９】
ここで、ＡｇｅｎｔＩＤ「ＢＥ２０９９９７・・・」を有するエンティティのＬａｓｔＣｒａｗｌＴｉｍｅ９０３２は、更新されずに古い値を保持したままとなる。バッチアプリケーションサーバ１０５のアーカイブアプリケーションは、ストレージサーバ１０４のステータスＤＢ部３４２に記録されている全てのＬａｓｔＣｒａｗｌＴｉｍｅのうち、最も古い時刻までのＴｉｍｅＳｔａｍｐを持つログを出力可能とする。図９（ｃ）の場合、最も古い時刻は、「２０１１／０１／０３ ０１：００：００」であり、またこの値は更新されないため、永久にアーカイブアプリケーションは「２０１１／０１／０３ ０１：００：００」までのログしか出力できないことになる。
【０１１０】
そこで、本実施形態では、フェールオーバーの際に、異なるアプリケーションサーバに処理が委譲された場合においても、フェールオーバの前後でＩＤが引き継がれ、ＬａｓｔＣｒａｗｌＴｉｍｅが更新されるための、アプリケーションサーバのフローを以下に記述する。つまり、フェールオーバーの際に処理が委譲された場合にも、図９（ｃ）に示すように新たなＡｇｅｎｔＩＤが追加されることなく、図９（ｂ）のように委譲元のＡｇｅｎｔＩＤに対応するＬａｓｔＣｒａｗｌＴｉｍｅが更新されるようにする。また、下記フローにおいて、アプリケーションサーバ１は、動作不能となりフェールオーバーする対象のサーバとし、アプリケーションサーバ２は、処理が移譲されるサーバとする。また、アプリケーションサーバ１と、アプリケーションサーバ２のログ収集エージェント部が有する設定ファイルに記載されるＤｉｒ４０１５とＦｉｌｅｎａｍｅＲｅｇＥｘ４０１７の文字列は、同じものとする。
【０１１１】
なお、本処理フローは、本実施形態において、各アプリケーションサーバが備えるＣＰＵが、間接記憶部に記憶されたプログラムを直接記憶部に読み出し、実行することで実現される。
【０１１２】
Ｓ１４０１では、アプリケーションサーバ１上のリクエスト処理部状態監視部３２１３は、アプリケーションサーバ１の動作継続不能を検知する。Ｓ１４０２では、アプリケーションサーバ１は、ログファイルを出力していたフォルダに存在する全てのファイルを、アプリケーションサーバ２上の同一フォルダパス上に存在するフォルダにコピーする。ここで、アプリケーションサーバ１に対応するＩＤファイルも同一フォルダ上に存在するため、ＩＤファイルも同様にコピーされる。
【０１１３】
Ｓ１４０３では、アプリケーションサーバ２は、コピーの成否をアプリケーションサーバ１に通知する。Ｓ１４０４では、アプリケーションサーバ１は、アプリケーションサーバ１から通知されたコピーの成否を確認する。そして、コピーが成功していた場合には（Ｓ１４０４にてＹＥＳ）、Ｓ１４０５に遷移する。また、コピーが失敗していた場合には（Ｓ１４０４にてＮｏ）、Ｓ１４０７に遷移し、フェールオーバー失敗とする。
【０１１４】
Ｓ１４０５では、アプリケーションサーバ２は、ログ収集エージェント部３２２を起動する。ログ収集エージェント部３２２が、起動した後のフローは、図１１にて示したフローと同じであるため、説明は割愛する。Ｓ１４０６では、アプリケーションサーバ２は、アプリケーション部３２１を起動する
以上説明したように、図１１乃至図１４に従って処理することにより、アプリケーションサーバとログサーバとが独立して構築され、複数のユーザから依頼を並列して処理するような大規模システムにおいて、ログを重複して記録することを防止することができる。更に、記録しているログのうち、ある期間のログを出力する際に、重複したログの出力を防止することが可能となる。また、フェールオーバーなどによって、異なるアプリケーションサーバに処理が委譲され、別のログ収集エージェント部が動作した場合にも、委譲元に対応するＩＤを用いることで、ログを漏れなく収集、管理することが出来る。
【０１１５】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項１】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムであって、
前記アプリケーションサーバは、
ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、
前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、
前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段と
を有し、
前記ログサーバは、
前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、
前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理システム。
【請求項２】
当該ログを一意に特定するための他の情報とは、収集対象となったログのファイルの名称、当該ファイルにおいてログが出力された行番号、およびログが出力された際のタイムスタンプのうち少なくとも１つの情報が含まれることを特徴とする請求項１に記載のログ管理システム。
【請求項３】
前記アプリケーションサーバが処理の継続が不能になった際に、他のアプリケーションサーバへフェールオーバーを行う場合、当該他のアプリケーションサーバは、自身が有するログデータ収集手段を動作させ、当該他のアプリケーションサーバが有する提供手段は、当該動作させたログデータ収集手段を一意に特定するための識別子を新たに生成し、当該識別子を前記ログサーバに提供することを特徴とする請求項１に記載のログ管理システム。
【請求項４】
前記ログデータ収集手段は、ログの収集状況の情報を更に有し、当該ログの収集状況の情報に従って、収集が終了していないログを収集することを特徴とする請求項１または２に記載のログ管理システム。
【請求項５】
前記ログデータ収集手段は、収集対象となるログのファイルが格納されているフォルダの位置、当該収集対象となるログのファイルの名称、収集する時間の間隔の情報を、設定ファイルとして保持することを特徴とする請求項１または２に記載のログ管理システム。
【請求項６】
前記提供手段は、前記設定ファイルにて指定される、収集対象となるログのファイルが格納されているフォルダに、生成した前記識別子を指定するデータを格納することを特徴とする請求項５に記載のログ管理システム。
【請求項７】
前記提供手段は、前記設定ファイルにて収集対象となるログのファイルが格納されているフォルダに前記識別子を指定するデータがすでに格納されている場合には、当該データにて指定された識別子を前記ログサーバに提供することを特徴とする請求項６に記載のログ管理システム。
【請求項８】
前記アプリケーションサーバは、処理の継続が不能になった際に、他のアプリケーションサーバへフェールオーバーを行う場合、前記ログデータ収集手段による収集対象となるログのファイルが格納されているフォルダに含まれているデータを、前記提供手段にて格納された識別子を指定するデータと共に、前記他のアプリケーションサーバの同じフォルダの位置にコピーさせるコピー手段をさらに有し、
前記他のアプリケーションサーバの提供手段は、当該コピーされたデータにて指定された識別子を前記ログサーバに提供することを特徴とする請求項７に記載のログ管理システム。
【請求項９】
前記ログの収集状況の情報は、前回のログを収集した時刻、ログのファイルにおける収集が終了した個所までの先頭からのデータサイズ、ログのファイルにおける収集が終了した行番号、を示す情報であることを特徴とする請求項４乃至８のいずれか一項に記載のログ管理システム。
【請求項１０】
前記収集対象となるログのファイルの名称は、正規表現にて指定されることを特徴とする請求項５乃至９のいずれか一項に記載のログ管理システム。
【請求項１１】
前記アプリケーションサーバは、前記ログデータ収集手段の識別子と、当該ログデータ収集手段がログの収集を最後に行った時刻とを対応付けた情報を、前記ログサーバに送信するステータス送信手段を更に有し、
前記記憶手段は更に、前記記憶部に、前記ステータス送信手段から受信した情報を記憶することを特徴とする請求項１乃至１０のいずれか一項に記載のログ管理システム。
【請求項１２】
前記ログ管理システムは、指定された期間における、前記記憶部に記憶されたログを出力する出力手段を更に含み、
前記出力手段は、前記記憶部に記憶された前記ログデータ収集手段がログの収集を最後に行った時刻が、前記指定された期間を経過している場合にログの出力を行うことを特徴とする請求項１１に記載のログ管理システム。
【請求項１３】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムにおけるアプリケーションサーバであって、
ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、
前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、
前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段と
を有し、
前記ログデータ収集手段は、当該ログデータ収集手段の識別子、およびログを一意に特定するための他の情報を当該ログのデータに含めることを特徴とするアプリケーションサーバ。
【請求項１４】
他のアプリケーションサーバが処理の継続が不能になった際に、当該他のアプリケーションサーバからフェールオーバーの依頼を受けた場合、前記ログデータ収集手段を動作させ、前記提供手段は、当該動作させたログデータ収集手段を一意に特定するための識別子を新たに生成し、当該識別子を前記ログサーバに提供することを特徴とする請求項１３に記載のアプリケーションサーバ。
【請求項１５】
ユーザからの要求に応じてサービスを提供した際に実行した処理のログをログサーバに送信する１以上のログデータ収集手段と前記１以上のログデータ収集手段を一意に特定するための識別子を前記ログサーバに提供する提供手段とを有するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積する前記ログサーバとを含むログ管理システムにおけるログサーバであって、
アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、
前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログサーバ。
【請求項１６】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムにおけるログ管理方法であって、
前記アプリケーションサーバにおいて、
ログファイル出力手段が、ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力工程と、
１以上のログデータ収集手段がそれぞれ、前記ログファイル出力手段にてログを出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信するログデータ収集工程と、
提供手段が、前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供工程と
を有し、
前記ログサーバにおいて、
記憶手段が、前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶工程を有し、
前記記憶工程において、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理方法。
ことを特徴とするログ管理方法。
【請求項１】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムであって、
前記アプリケーションサーバは、
ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、
前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、
前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段と
を有し、
前記ログサーバは、
前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、
前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理システム。
【請求項２】
当該ログを一意に特定するための他の情報とは、収集対象となったログのファイルの名称、当該ファイルにおいてログが出力された行番号、およびログが出力された際のタイムスタンプのうち少なくとも１つの情報が含まれることを特徴とする請求項１に記載のログ管理システム。
【請求項３】
前記アプリケーションサーバが処理の継続が不能になった際に、他のアプリケーションサーバへフェールオーバーを行う場合、当該他のアプリケーションサーバは、自身が有するログデータ収集手段を動作させ、当該他のアプリケーションサーバが有する提供手段は、当該動作させたログデータ収集手段を一意に特定するための識別子を新たに生成し、当該識別子を前記ログサーバに提供することを特徴とする請求項１に記載のログ管理システム。
【請求項４】
前記ログデータ収集手段は、ログの収集状況の情報を更に有し、当該ログの収集状況の情報に従って、収集が終了していないログを収集することを特徴とする請求項１または２に記載のログ管理システム。
【請求項５】
前記ログデータ収集手段は、収集対象となるログのファイルが格納されているフォルダの位置、当該収集対象となるログのファイルの名称、収集する時間の間隔の情報を、設定ファイルとして保持することを特徴とする請求項１または２に記載のログ管理システム。
【請求項６】
前記提供手段は、前記設定ファイルにて指定される、収集対象となるログのファイルが格納されているフォルダに、生成した前記識別子を指定するデータを格納することを特徴とする請求項５に記載のログ管理システム。
【請求項７】
前記提供手段は、前記設定ファイルにて収集対象となるログのファイルが格納されているフォルダに前記識別子を指定するデータがすでに格納されている場合には、当該データにて指定された識別子を前記ログサーバに提供することを特徴とする請求項６に記載のログ管理システム。
【請求項８】
前記アプリケーションサーバは、処理の継続が不能になった際に、他のアプリケーションサーバへフェールオーバーを行う場合、前記ログデータ収集手段による収集対象となるログのファイルが格納されているフォルダに含まれているデータを、前記提供手段にて格納された識別子を指定するデータと共に、前記他のアプリケーションサーバの同じフォルダの位置にコピーさせるコピー手段をさらに有し、
前記他のアプリケーションサーバの提供手段は、当該コピーされたデータにて指定された識別子を前記ログサーバに提供することを特徴とする請求項７に記載のログ管理システム。
【請求項９】
前記ログの収集状況の情報は、前回のログを収集した時刻、ログのファイルにおける収集が終了した個所までの先頭からのデータサイズ、ログのファイルにおける収集が終了した行番号、を示す情報であることを特徴とする請求項４乃至８のいずれか一項に記載のログ管理システム。
【請求項１０】
前記収集対象となるログのファイルの名称は、正規表現にて指定されることを特徴とする請求項５乃至９のいずれか一項に記載のログ管理システム。
【請求項１１】
前記アプリケーションサーバは、前記ログデータ収集手段の識別子と、当該ログデータ収集手段がログの収集を最後に行った時刻とを対応付けた情報を、前記ログサーバに送信するステータス送信手段を更に有し、
前記記憶手段は更に、前記記憶部に、前記ステータス送信手段から受信した情報を記憶することを特徴とする請求項１乃至１０のいずれか一項に記載のログ管理システム。
【請求項１２】
前記ログ管理システムは、指定された期間における、前記記憶部に記憶されたログを出力する出力手段を更に含み、
前記出力手段は、前記記憶部に記憶された前記ログデータ収集手段がログの収集を最後に行った時刻が、前記指定された期間を経過している場合にログの出力を行うことを特徴とする請求項１１に記載のログ管理システム。
【請求項１３】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムにおけるアプリケーションサーバであって、
ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力手段と、
前記ログファイル出力手段にてログが出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信する１以上のログデータ収集手段と、
前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供手段と
を有し、
前記ログデータ収集手段は、当該ログデータ収集手段の識別子、およびログを一意に特定するための他の情報を当該ログのデータに含めることを特徴とするアプリケーションサーバ。
【請求項１４】
他のアプリケーションサーバが処理の継続が不能になった際に、当該他のアプリケーションサーバからフェールオーバーの依頼を受けた場合、前記ログデータ収集手段を動作させ、前記提供手段は、当該動作させたログデータ収集手段を一意に特定するための識別子を新たに生成し、当該識別子を前記ログサーバに提供することを特徴とする請求項１３に記載のアプリケーションサーバ。
【請求項１５】
ユーザからの要求に応じてサービスを提供した際に実行した処理のログをログサーバに送信する１以上のログデータ収集手段と前記１以上のログデータ収集手段を一意に特定するための識別子を前記ログサーバに提供する提供手段とを有するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積する前記ログサーバとを含むログ管理システムにおけるログサーバであって、
アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶手段を有し、
前記記憶手段は、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログサーバ。
【請求項１６】
ユーザからの要求に応じてサービスを提供するアプリケーションサーバと、前記アプリケーションサーバが提供したサービスのログを蓄積するログサーバとを含むログ管理システムにおけるログ管理方法であって、
前記アプリケーションサーバにおいて、
ログファイル出力手段が、ユーザからの要求に応じて行った処理のログをファイルに出力するログファイル出力工程と、
１以上のログデータ収集手段がそれぞれ、前記ログファイル出力手段にてログを出力されたファイルのうち、収集対象となるファイルから前記ログを収集して前記ログサーバに送信するログデータ収集工程と、
提供手段が、前記１以上のログデータ収集手段を一意に特定するための識別子を生成し、当該識別子を前記ログサーバに提供する提供工程と
を有し、
前記ログサーバにおいて、
記憶手段が、前記アプリケーションサーバから送信されたログを受信し、記憶部に記憶する記憶工程を有し、
前記記憶工程において、受信したログに対応付けられた前記アプリケーションサーバから提供された識別子とすでに前記記憶部に記憶されているログに対応付けられた識別子とが一致し、かつ受信したログに含まれる当該ログを一意に特定するための他の情報とすでに前記記憶部に記憶されているログに含まれる当該ログを一意に特定するための他の情報とが一致している場合に当該受信したログを記憶させず、それ以外の場合に当該受信したログを記憶することを特徴とするログ管理方法。
ことを特徴とするログ管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１３−３７４０３（Ｐ２０１３−３７４０３Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７０４５０（Ｐ２０１１−１７０４５０）
【出願日】平成２３年８月３日（２０１１．８．３）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月３日（２０１１．８．３）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]