(57)【要約】【課題】クラスタ構成をとるサーバシステムのログ管理システムにおいて、サーバモジュールの開発生産性を低下させることなく、効率的にデバッグのためのログ解析をおこなえるようにする。【解決手段】サーバシステムが、処理のリクエストに対して、一つのスレッドを生成し、その際に、主記憶装置上に、スレッドで使用されるデータが格納される専用領域であるスレッド局所域を確保する。そして、セッションＩＤやユーザＩＤ、シーケンス番号等の処理の間にログの出力開始からログの出力停止までのログの出力を一意的に識別しうるログ追跡情報を、スレッド局所域に保持しておく。ログ出力時には、ログのデータに対して、ログ追跡情報を付加して、補助記憶装置に出力する。【選択図】  図４
2014081811.tif 000002
【特許請求の範囲】
【請求項１】
中央処理装置と、主記憶装置と、補助記憶装置と、通信装置とを備える計算機と、前記通信装置によりネットワークを介して接続された他の計算機とを有するログ管理システムであって、
前記計算機は、
前記他の計算機からのリクエストに応じて処理を実行するビジネスロジック処理手段と、
処理の記録であるログデータの出力に関する処理を実行するログ出力処理手段とを有し、
前記ログ出力処理手段は、前記ビジネスロジック処理手段からの前記ログデータ出力開始要求を受けると、ログデータの出力開始から出力停止までのログを一意に識別するログ追跡情報を、前記主記憶装置上のスレッド局所域に保持し、
前記ログ出力処理手段は、前記ビジネスロジック処理手段からの前記ログデータ出力要求を受けると、前記ビジネスロジック処理手段の出力したログに、前記スレッド局所域に保持されたログ追跡情報を付加し、前記補助記憶装置に出力することを有することを特徴とするログ管理システム。
【請求項２】
前記計算機は、さらに、
前記他の計算機との通信処理を実行する通信処理手段を備え、
前記通信処理手段は、前記他の計算機からのリクエストを受けると、前記ログ出力処理手段に対し、前記ログデータ出力開始要求をおこない、その後、前記ビジネスロジック処理手段に前記リクエストの処理を依頼し、前記ビジネスロジック処理手段による前記リクエストの処理が終わると、前記通信処理手段は、前記ログ出力処理手段に対し、前記ログデータ出力停止要求をおこなうことを特徴とする請求項１記載のログ管理システム。
【請求項３】
前記計算機は、複数の計算機から構成されて連携して動作するクラスタシステムのクラスタノードであることを特徴とする請求項１記載のログ管理システム。
【請求項４】
前記クラスタシステムは、クラスタノード間で共有されるストレージ領域を有し、
前記計算機は、さらに、ログ収集処理手段を有し、
前記ログ収集処理手段は、前記ログ追跡情報を付加されたログデータの更新状況を定期的に検査し、前記ログ追跡情報を付加されたログデータの更新を検知すると、前記ログ追跡情報を付加されたログデータの更新部分を前記ストレージ領域に保管することを特徴とする請求項３記載のログ管理システム。
【請求項５】
前記ストレージ領域に保管された前記ログ追跡情報を付加されたログデータは、前記ログ追跡情報と、出力されたログのデータを個別のカラムに格納するテーブル構造を有することを特徴とする請求項４記載のログ管理システム。
【請求項６】
前記ログ追跡情報は、
前記利用者を一意に識別するためのユーザＩＤと、
前記クラスタシステム内で、前記ネットワークを介した計算機間の一連の通信セッションを一意的に識別するためのグローバルセッションＩＤと、
前記クラスタシステム内のクラスタノード内での通信セッションを一意的に識別するためのローカルセッションＩＤと、
ログデータの出力順序を数値で表したシーケンス番号と、
ログデータの出力日時との一部または全部によって構成されることを特徴とする請求項３記載のログ管理システム。
【請求項７】
さらに、前記計算機は、前記ログ収集処理手段が、前記ログ追跡情報を付加されたログデータの更新状況を定期的に検査する手段と、
前記ログ追跡情報を付加されたログデータの検査を、即座に実行する手段とを有することを特徴とする請求項４記載のログ管理システム。
【請求項８】
さらに、前記計算機は、
前記補助記憶装置に出力された前記ログ追跡情報を付加されたログデータを検索する手段と、
前記補助記憶装置に出力された前記ログ追跡情報を付加されたログデータを削除する手段とを有することを特徴とする請求項１記載のログ管理システム。
【請求項９】
中央処理装置と、主記憶装置と、補助記憶装置と、通信装置とを有し、前記通信装置によりネットワークを介して他の計算機により接続された計算機上で実行されるログ管理方法であって、
前記中央処理装置が、前記他の計算機より前記通信装置を介して処理のリクエストを受け取るステップと、
前記中央処理装置が、前記処理の記録であるログの出力開始をするステップと、
前記中央処理装置が、前記処理の記録であるログの出力停止をするステップと、
前記中央処理装置が、前記処理のリクエストに対して、一つのスレッドを生成するステップと、
前記中央処理装置が、前記一つのスレッドに対して、前記主記憶装置上に、前記スレッドで使用されるデータが格納される専用領域であるスレッド局所域を確保するステップと、
前記中央処理装置が、前記処理の間にログの出力開始から前記ログの出力停止までのログの出力を一意的に識別しうるログ追跡情報を、前記スレッド局所域に保持するステップと、
前記中央処理装置が、前記出力されたログに対して、前記ログ追跡情報を付加し、前記ログ追跡情報を付加されたログデータを、前記補助記憶装置に出力するステップとを有することを特徴とするログ管理方法。
【請求項１０】
中央処理装置と、主記憶装置と、補助記憶装置と、通信装置とを有し、前記通信装置によりネットワークを介して他の計算機により接続された複数の計算機からなるログ管理システムであって、
前記複数の計算機は、表紙装置を備えるログ管理計算機と、連携して動作するクラスタシステムのクラスタノードを含み、
前記クラスタシステムは、クラスタノード間で共有されるストレージ領域を有し、
前記クラスタノードでの処理の間にログの出力開始から前記ログの出力停止までのログの出力を一意的に識別しうるログ追跡情報を、前記クラスタノードでの処理の出力されたログに付加して、前記ログ追跡情報を個別のカラムに格納するログテーブルとして前記ストレージ領域に保持し、
前記ログ管理計算機の表示装置に、ログ管理画面を表示し、
前記ログ管理画面は、前記ログテーブルのログ追跡情報に関する検索条件を入力する欄と、
検索実行を指示する表示要素と、
検索実行結果を表示する欄とを備え、
前記検索結果を表示する欄に表示された検索結果の表示の各々の項目は、前記入力装置により選択可能であり、当該選択可能な情報をユーザが選択した際に、当該選択された情報にのみ該当する前記ログテーブルのデータを表示する絞込み検索を実行することを特徴とするログ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ログ管理システム、および、ログ管理方法に係り、特に、クラスタシステムにおいて、システム開発者に対してソフトウェア開発の負担をかけることなく、一元的にログ管理が可能になるログ管理システム、および、ログ管理方法に関する。
【背景技術】
【０００２】
一般に、サーバシステムは、複数台のマシンによって構成される。この構成を「クラスタ構成」と呼び、クラスタを構成する各マシンを「クラスタノード」と呼ぶ。サーバシステムは、クラスタ構成をとることにより、処理負荷を分散させたり、一台のクラスタノードが処理途中でダウンした際に他のクラスタノードがその処理を引き継ぐスタンバイ機能を提供することができる。
【０００３】
一方、クラスタ構成をとるサーバシステムでは、不具合発生時に、稼動させているソフトウェアの不具合原因を特定する作業（以下、「デバッグ」という）が困難であるという課題がある。デバッグは、一般的にデバッガと呼ばれる専用のソフトウェアツールを用いておこなわれる。しかしながら、クラスタ構成をとるサーバシステムにおいては、複数台のクラスタノードが連携して処理を実行するという特殊性を有しているため、通常のソフトウェアと同様の方法でデバッグをおこなうことはできない。例えば、数百台のクラスタノードで構成されるサーバシステムに対し、デバッガを用いてデバッグをおこなうためには、当該数百台のクラスタノードに対し、デバッガを走らせてデバッグをおこなわなければならない。これは現実的ではないため、サーバシステムのデバッグは、一般的に、ソフトウェアを実行した記録であるログデータの解析によって実施される。すなわち、不具合が発生したときには、デバッグ作業をおこなう者は、ログデータに含まれる、サーバシステムの挙動に関する詳細な情報を解析することによって、不具合原因を特定する。
【０００４】
しかしながら、一般的に、クラスタ構成をとるサーバシステムにおけるログデータを解析することは容易ではないという問題点がある。というのは、サーバシステムは、複数台のクラスタノードで構成されるため、ログデータは、複数台のクラスタノードに分散して保管される。このように、ログデータが分散されるため、何も対策をとらないサーバシステムでは、デバッグの実行者は、分散したログデータを自ら収集し、それらを個別に解析しなければならない。これはデバッグ作業を困難にし、障害復旧時間を長期化する要因となる。
【０００５】
また、ログデータの出力形式に関して、一般的なシステムにおいては、解析作業をおこないにくいという問題点がある。すなわち、サーバシステムは、一般に複数ユーザからの複数リクエストを同時並行で処理する。よって、ユーザリクエストとの対応を識別可能なログデータの出力形式でなければ、ログデータの解析が困難になり、障害復旧時間を長期化する要因となる。
【０００６】
これらの問題点に対し、分散したログデータを一箇所に収集し、ログデータの解析時間を短縮するための技術が考案されている。例えば、特許文献１では、複数のクラスタノードに存在するログファイルに対して、同一のユーザ識別子を有するログファイルを識別子ファイルとして分割することにより、ログデータの解析を容易化し、解析時間を短縮するログファイル分析方法が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２０１０−５１２５６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上記特許文献１記載のログファイル分析方法は、ユーザ毎のログデータ解析を可能にするものであるが、リクエスト毎または通信セッション毎の詳細な解析を容易化することについては、考慮されていない。例えば、ある障害が発生した際に、その障害が発生するまでの処理シーケンスを追跡するには、ユーザ識別子（以下、「ユーザＩＤ」という）だけでなく、リクエストの識別情報（以下、「セッションＩＤ」という）に基づくログデータの解析が可能でなければならない。
【０００９】
一方、セッションＩＤに基づくログデータの解析を実現するには、リクエスト毎のログデータの追跡が可能な情報（以下、「ログ追跡情報」という）をログデータに含めなければならない。一般的なログ追跡情報として、ユーザＩＤ、セッションＩＤ、シーケンス番号（ログデータの出力順序を表す連番）などが考えられるが、リクエストを一意に特定でき、かつログの出力順序を識別可能な情報であればこれに限らない。
【００１０】
ログ追跡情報は、一般的にログ出力される情報（例えば、日時やログレベル、スレッド名等）と異なり、ログ出力時に取得可能な情報だけでは構築できない。例えば、シーケンス番号は、リクエストの処理シーケンスが異なれば、同じログ出力箇所であっても異なる番号となるため、シーケンス番号の管理が不可欠となる。ユーザＩＤやセッションＩＤは、リクエスト毎に異なる情報であるため、これらの情報をリクエストと関連付けて管理する必要がある。
【００１１】
よって、サーバシステムを構成するソフトウェアモジュール（以下、「サーバモジュール」という）の開発者は、ログ追跡情報をログデータに含めるためのロジックをサーバモジュールに実装しなければならない。しかしながら、これは容易ではなく、一般的には全ての関数やメソッドの引数にログ追跡情報を格納したメモリ領域のポインタを渡すといった対策が必要になる。そのため、ソフトウェア開発者の負担が大きくなり、サーバモジュールに対する開発生産性を低下させ、かつ、サーバモジュールのソフトウェア構成も複雑なものになりかねない。
【００１２】
本発明は、上記問題点を開発するためになされたもので、その目的は、クラスタ構成をとるサーバシステムにおいて、サーバモジュールの開発生産性を低下させることなく、効率的にデバッグのためのログ解析をおこなうことのできるログ管理システムを提供することにある。
【課題を解決するための手段】
【００１３】
本発明のログ管理システムは、中央処理装置と、主記憶装置と、補助記憶装置と、通信装置とを備える計算機と、前記通信装置によりネットワークを介して接続された他の計算機とを有するログ管理システムであり。計算機は、他の計算機からのリクエストに応じて処理を実行するビジネスロジック処理部と、処理の記録であるログデータの出力に関する処理を実行するログ出力処理部とを有している。
【００１４】
ログ出力処理部は、ビジネスロジック処理部からのログデータ出力開始要求を受けると、ログデータの出力開始から出力停止までのログを一意に識別するログ追跡情報を、主記憶装置上のスレッド局所域（以下、ＴＬＳ（Thread Local Storageの略））に保持する。
【００１５】
そして、ログ出力処理部は、ビジネスロジック処理部からのログデータ出力要求を受けると、ビジネスロジック処理部の出力したログに、スレッド局所域に保持されたログ追跡情報を付加し、補助記憶装置に出力する。
【００１６】
このように本発明のログ管理方法では、ユーザからのリクエストを処理するスレッドを単一のスレッドに限定し、ＴＬＳにログ追跡情報を保持するものである。すなわち、ソフトウェアの構造からすると、通信処理をおこなう通信処理部と、その他の処理をおこなうビジネスロジック処理部にサーバシステムの構造を分離し、ユーザからのリクエストを受信した通信処理部が、ＴＬＳにログ追跡情報を保管する。
【００１７】
一方、ビジネスロジック処理部は、専用のログ出力用ライブラリを利用してログデータを出力する。ログ出力用ライブラリの内部では、ＴＬＳに保管されたログ追跡情報を取得し、ログデータにログ追跡情報を付加してファイル等に出力する処理が実行される。同時に、ログ出力用ライブラリの内部では、シーケンス番号の増加といった処理がおこなわれ、ＴＬＳのログ追跡情報が更新される。
【００１８】
通信処理部は、リクエストに対する処理の終了後、ＴＬＳに保管されたログ追跡情報を削除する。この一連の処理により、サーバモジュールの開発生産性を低下させることなく、効率的にログ追跡情報をログデータに含めることが可能となる。
【００１９】
このように、本発明のログ管理方法によれば、障害発生時のログ追跡が容易になり、障害原因特定時間が短縮され、サーバシステムの稼働率が向上する。ここで稼働率とは、平均故障間隔（以下、ＭＴＢＦ（Mean Time Between Failure））の値を、平均回復時間（以下、ＭＴＴＲ（Mean Time To Repair））とＭＴＢＦの和で除算した値である。ＭＴＢＦは障害が発生してから次の障害が発生するまでの平均時間であり、ＭＴＴＲは障害が発生してから障害が復旧するまでの平均時間である。すなわち、障害原因特定時間を短縮することにより、ＭＴＴＲの値が減少し、稼働率が向上することになる。
【００２０】
また、サーバモジュールの開発者は、ログ追跡情報を意識することなく開発を進めることが可能となり、かつサーバモジュールのテスト時にもログ追跡情報を利用したデバッグが可能となることから、サーバモジュールの開発生産性が向上する。
【発明の効果】
【００２１】
本発明によれば、クラスタ構成をとるサーバシステムにおいて、サーバモジュールの開発生産性を低下させることなく、効率的にデバッグのためのログ解析をおこなうことのできるログ管理システムを提供することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施形態に係るログ管理システムの機能構成図である。
【図２】図１におけるサーバマシン、クライアントマシン、ログ管理マシン、ストレージマシンのハードウェア構成図である。
【図３】ログ出力の開始処理および終了処理を表すシーケンス図である。
【図４】ログ出力処理を表すシーケンス図である。
【図５】ログ収集処理を表すフローチャートである。
【図６】ログ追跡情報が付加されたログデータを、データベースのテーブル形式で格納した管理形式を説明する図である。
【図７】ログデータの管理画面を示す図である。
【図８】ログデータの管理画面からユーザがログ検索をおこなうときのシステムの処理を示すシーケンス図である。
【発明を実施するための形態】
【００２３】
以下、本発明に係る一実施形態を、図１ないし図８を用いて説明する。
先ず、図１ないし図２を用いて本発明の一実施形態に係るログ管理システムの構成について説明する。
図１は、本発明の一実施形態に係るログ管理システムの機能構成図である。
図２は、図１におけるサーバマシン、クライアントマシン、ログ管理マシン、ストレージマシンのハードウェア構成図である。
【００２４】
本実施形態のログ管理システムは、図１に示されるように、サーバマシン１０１、ログ管理マシン１０９、ロードバランサ１１１、ストレージマシン１１０が、ＬＡＮ（Local Area Network）１１３によって接続され、ロードバランサ１１１、クライアントマシン１１７が、ＷＡＮ（Wide Area Network）１１２より接続されている。
【００２５】
サーバマシン１０１は、サーバプログラム１０２を実行するコンピュータ装置である。サーバマシン１０１は、一般的なＰＣ（Personal Computer）であってもよく、ブレードサーバのようなサーバ機能に特化した専用マシンであってもよい。サーバマシン１０１は、一台のみの構成で動作することも、複数台を組合わせたクラスタ構成で動作することも可能である。なお、図１においては、複数台を組合わせたクラスタ構成であるものとして図示している。
【００２６】
サーバプログラム１０２は、一般的なサーバ機能を提供するプログラムであり、ログデータを出力するプログラムである。サーバ機能の種類として、例えば、Ｗｅｂサイトを構築するＨＴＴＰサーバや、ＭＤＭ（Mobile Device Managementの略）機能を提供するＭＤＭサーバなどが考えられる。サーバプログラム１０２は、通信処理部１０３、ログ管理機能処理部１０４、ログ出力処理部１０５、ビジネスロジック処理部１０６、ログ収集処理部１０７、および、サーバ基本ミドルウェア１０８により構成される。
【００２７】
サーバ基本ミドルウェア１０８は、サーバシステムに必要な共通の基本機能を提供するミドルウェアである。基本機能の例として、トランザクション管理機能や非同期メッセージ配信機能、スレッドプール管理機能、クラスタ構成管理機能などが挙げられる。これらは、一般的な機能であり、例えば、ＪＢｏｓｓアプリケーションサーバ等が当該機能を備えたミドルウェアとして知られる。通信処理部１０３、ログ管理機能処理部１０４、ログ出力処理部１０５、ビジネスロジック処理部１０６、ログ収集処理部１０７は、サーバ基本ミドルウェア１０８の上で動作するサーバモジュール（例えば、ＥｎｔｅｒｐｒｉｓｅＪａｖａＢｅａｎｓやＳｅｒｖｌｅｔとして知られるモジュール等）として実装することを想定している。ログ出力処理部１０５は、上記のように、サーバモジュールとして実装することも、一般的なライブラリとして実装することも可能である。
【００２８】
サーバ基本ミドルウェア１０８は、ＯＳ上で動作するスレッドのスレッドプールを管理する役割を有しているため、その上で動作するサーバモジュールは、独自にスレッドを生成することは許可されていない。これは、ＪＢｏｓｓ等のアプリケーションサーバでは一般的な仕様である。クライアントからのリクエストを受けたサーバモジュールは、サーバ基本ミドルウェア１０８によって割り当てられたシングルスレッドによって処理を実行する。本実施形態のサーバシステムにおいても、このシングルスレッドによるリクエスト処理を前提とし、一般的なアプリケーションサーバの仕様と同様に、サーバモジュールによる独自スレッドの生成は許されていないものとする。
【００２９】
通信処理部１０３は、ネットワークを介してクライアントマシン１１７、ログ管理マシン１０９およびストレージマシン１１０とデータ通信をおこなうモジュールである。通信プロトコルは、特段のものに限定されず、例えば、ＨＴＴＰ（Hyper Text Transfer Protocolの略）やＣＷＭＰ（Cpe WAN Management Protocolの略）などが通信プロトコルとして想定される。通信処理部１０３は、受信したデータの内容に基づいて、呼び出すサーバモジュールを決定し、当該サーバモジュールに処理を委譲する。
【００３０】
通信処理部１０３が接続するネットワークは、ロードバランサ１１１を境界とし、クライアント側が、ＷＡＮ１１２、サーバ側がＬＡＮ１１３により接続されているものとする。クライアントマシン１１７とサーバマシン１０１間の通信は、ＷＡＮ１１２およびＬＡＮ１１３を介しておこなわれることを想定する。ログ管理マシン１０９およびストレージマシン１１０とサーバマシン１０１間の通信は、ＬＡＮ１１３を介しておこなわれることを想定する。たたし、上記の例では、各マシンが別々の機能を有して、ネットワークを介した通信しているものとしたが、クライアントマシン１１７、ログ管理マシン１０９、ストレージマシン１１０、サーバマシン１０１は、全て同一マシンで構成することも可能である。その場合、通信処理部１０３はプロセス間通信のパイプとして動作し、ロードバランサ１１１は、不要となる。また、サーバマシン１０１が一台構成の場合も、同様にロードバランサ１１１は不要となる。
【００３１】
ログ管理機能処理部１０４は、ログ管理プログラム１１５から入力されたログデータの検索要求や、ログ管理命令を処理するサーバモジュールである。ログ管理命令の種類として、例えば、ログファイルの削除やログデータの収集（クラスタ内に分散したログの収集）、ログデータの収集スケジュールの設定などが考えられる。ログ管理機能処理部１０４は、当該ログ検索要求またはログ管理命令の種類に基づき、ログデータをストレージプログラム１１６から検索したり、クラスタ内に分散したログデータを収集するためにログ収集処理部１０７に処理を委譲したりする。当該ログ管理命令の実行結果は、通信処理部１０３を介して呼び出し元のログ管理プログラム１１５に返される。
【００３２】
ログ出力処理部１０５は、通信処理部１０３からの入力を受けてＴＬＳ（Thread Local Storageの略）にログ追跡情報を保管したり、ビジネスロジック処理部１０６等のサーバモジュールからの入力を受けてログデータを出力したりする機能を提供するモジュールである。出力されたログデータは、サーバプログラム１０２共通のログファイル等に保管される。
【００３３】
ビジネスロジック処理部１０６は、サーバプログラム１０２のビジネスロジック（サーバ固有の処理やルールを記述するロジック）を実装するサーバモジュールである。例えば、サーバプログラム１０２がＭＤＭサーバプログラムであった場合、デバイス管理のために必要なインベントリ管理機能やアプリ配信機能などを処理するサーバモジュールがビジネスロジック処理部１０６に該当する。ビジネスロジック処理部１０６は、通信処理部１０３を介し、クライアントプログラム１１４からのリクエストを受けて処理を実行する。
【００３４】
ログ収集処理部１０７は、クラスタ内に分散したログデータを収集する機能を持ったモジュールである。ログ収集処理部１０７は、ログ出力処理部１０５が保管したログデータの更新有無を定期的にチェックし、更新があればストレージプログラム１１６を利用してログデータを永続化する。ここで、「永続化」とは、データを生成したプログラムが終了してもデータが消失しないようにすることを意味し、具体的には、不揮発性の補助記憶装置（ＨＤＤ、ＳＤＤなど）にデータを格納する。このようにログの出力処理と収集処理を分ける理由は、ストレージプログラム１１６を利用したログデータの永続化処理が、一般に高い処理負荷を要求するためである。
【００３５】
クライアントマシン１１７は、クライアントプログラム１１４を実行する装置である。クライアントマシン１１７として、例えば、ＰＣ、スマートフォン、タブレット端末、カーナビなどのコンシューマ向けデバイスが考えられる。
【００３６】
クライアントプログラム１１４は、サーバプログラム１０２が提供する機能を呼び出すためのロジックを実装するプログラムである。クライアントプログラム１１４は、ＷＡＮ１１２を介したデータ通信によりロードバランサ１１１へリクエスト（サーバ機能を呼び出すためのリクエスト）を送信し、その応答メッセージを受信する。クライアントプログラム１１４として、例えば、ウェブブラウザなどが考えられる。
【００３７】
ログ管理マシン１０９は、ログ管理プログラム１１５を実行する装置である。ログ管理マシン１０９として、例えばＰＣ、スマートフォン、タブレット端末などの企業向けデバイスが考えられる。
【００３８】
ログ管理プログラム１１５は、ユーザ（例えばシステム管理者）からの入力を受けてログ管理命令をログ管理機能処理部１０４に送信し、その実行結果をユーザに提示するプログラムである。ログ管理プログラム１１５は、ログ管理命令をログ管理機能処理部１０４に送信するためのユーザインタフェースを提供し、ユーザからの入力を受付ける。ユーザは、ログ管理プログラム１１５を利用することにより、ログ収集処理部１０７が収集したログデータ（クラスタ内の全てのログデータ）を参照できる。ログ管理プログラム１１５として、例えば、ウェブブラウザなどが考えられる。
【００３９】
ストレージマシン１１０は、ストレージプログラム１１６を実行する装置である。ストレージマシン１１０として、例えば、ＰＣ、ブレードサーバなどのサーバマシンが考えられる。
【００４０】
ストレージプログラム１１６は、ログデータの永続化機能および検索機能を提供するプログラムである。ストレージプログラム１１６として、例えばＰｏｓｔｇｒｅＳＱＬ等のデータベースプログラムや、ＨＢａｓｅなどのＫＶＳ（Key Value Store）プログラムなどが考えられる。ストレージプログラム１１６を利用することにより、ログデータの検索性能を向上させることができる。ログデータの検索性能が問題にならない場合には、ログ出力処理部１０５が出力したログデータをそのまま利用する構成も考えられる。その場合、ログ収集処理部１０７、ストレージマシン１１０およびストレージプログラム１１６は、不要な構成となり、ログ管理機能提供部１０４はログ出力処理部１０５が出力したログデータを利用してログ管理機能を提供する。
【００４１】
ロードバランサ１１１は、クライアントマシン１１７からのリクエストを、各々のサーバマシンの負荷を分散させるために、サーバマシン１０１に振分けて転送する機能を有する装置である。このロードバランサ１１１は、リクエストをラウンドロビン方式で順番にクラスタノードに転送したり、処理負荷が最も低いクラスタノードに転送したりする機能を有する。
【００４２】
図１に記載のシステム構成は一例であり、この構成を限定されるものではなく。特に、本実施形態ではサーバプログラム向けの記述をおこなっているが、サーバプログラム以外のスタンドアローンプログラムにも本発明は適用可能である。
【００４３】
次に、図２を用いて図１におけるサーバマシン１０１、クライアントマシン１１７、ログ管理マシン１０９、ストレージマシン１１０のハードウェア構成について説明する。
【００４４】
この図において、補助記憶装置２０６はプログラム２０７およびログデータ２０８を記憶する不揮発メモリである。
【００４５】
プログラム２０７は、各マシンで実行されるクライアントプログラム１１４、ログ管理プログラム１１５、ストレージプログラム１１６、サーバプログラム１０２であり、実行時には、各々のプログラムが主記憶装置２０５にロードされて、中央処理装置２０１により実行される。
【００４６】
プログラムデータ２０８は、各々のプログラムの実行に必要なデータである。例えば、サーバプログラム１０２がＪＢｏｓｓを利用している場合、プログラムデータ２０８は、ＪＢｏｓｓのルートフォルダに含まれる全てのデータである。
【００４７】
ログデータ２０９は、ビジネスロジック処理部１０６が出力するログのデータに対して、ログ出力処理部１０５が、必要なログ追跡情報を付加したデータである。または、ストレージプログラム１１６が永続化して、テーブル形式を有するデータである。ログデータ２０９は、一般にファイルシステム上のファイルとして格納される。なお、ログ追跡情報を付加したログデータ２０９の構造については、後に、詳説する。
【００４８】
中央処理装置（Central Processing Unit）２０１は、補助記憶装置２０６に保管されたプログラム２０７またはプログラムデータ２０８を主記憶装置２０５にロードし、当該プログラム２０７に含まれる命令を実行したり、プログラムデータ２０８を参照したりするプロセッサである。
【００４９】
主記憶装置２０５は、演算装置２０１によって補助記憶装置２０６からロードされたプログラム２０７またはプログラムデータ２０８を記憶する揮発メモリであり、通常は、半導体記憶装置で実現される。
【００５０】
入力装置２０２は、ユーザからのデータ入力を受付けるための装置であり、例えば、マウス、キーボードなどが挙げられる。
【００５１】
出力装置２０３は、ユーザへのデータ出力をおこなうための装置であり、例えば、液晶ディスプレイなどの表示装置、印刷装置などが挙げられる。
【００５２】
入力装置２０２および出力装置２０３は、ユーザとのインタラクションを必要としない場合は不要である。
【００５３】
通信装置２０４は、ＷＡＮ１１２やＬＡＮ１１３といったネットワークに接続する装置であり、ネットワークを介したデータの送受信をおこなうための装置である。
【００５４】
次に、図３ないし図４を用いて本発明の一実施形態に係るログ管理システムがおこなうログに関する各処理について説明する。
図３は、ログ出力の開始処理および終了処理を表すシーケンス図である。
図４は、ログ出力処理を表すシーケンス図である。
図５は、ログ収集処理を表すフローチャートである。
【００５５】
先ず、図３を用いてログ出力の開始処理および終了処理について説明する。
【００５６】
先ず、初めに、クライアントプログラム１１４は、ロードバランサ１１１に対し、サーバ機能を呼び出すためのリクエストを送信する（シーケンス３０１）。
【００５７】
次に、ロードバランサ１１１は、クライアントプログラム１１４から送信されたリクエストの転送先となるクラスタノードを決定し、当該クラスタノードの通信処理部１０３に当該リクエストを転送する（シーケンス３０２）。
【００５８】
通信処理部１０３は、ロードバランサ１１１によって転送されたリクエストを受信すると、ログ出力処理部１０５に対し、ログ出力の開始を通知すると同時に、利用可能なログ追跡情報を渡す（シーケンス３０３）。
【００５９】
当該シーケンスは、ログ出力処理部１０５に関して当該シーケンスを処理するためのＡＰＩ（Application Interface）が公開されており、通信処理部１０３が当該ＡＰＩを呼び出すことにより処理することを想定する。一般的に利用可能なログ追跡情報として、例えば下記の情報が挙げられる。
・ユーザＩＤ
・セッションＩＤ
・シーケンス番号
これらのログ追跡情報をログデータに含めて出力することにより、クライアントプログラム１１４から送信されたリクエストを一意に識別することができる。これらのログ追跡情報に関しては、例えば、ＨＴＴＰ通信の例では、基本認証やダイジェスト認証の仕組みを利用してユーザＩＤを取得でき、Ｃｏｏｋｉｅの仕組みを利用してセッションＩＤやシーケンス番号を取得することができる。通信処理部１０３は、このように取得したログ追跡情報をシーケンス３０３においてログ出力処理部１０５にパラメタとして渡すようにする。
【００６０】
ログ出力処理部１０５は、通信処理部１０３からログ出力の開始通知とログ追跡情報を受けると、ＴＬＳにログ追跡情報を保管する（シーケンス３０４）。図３では示さなかったが、ＴＬＳへのデータ保管は、実際には、ログ出力処理部１０５が、サーバ基本ミドルウェア１０８に処理を依頼することによりおこなうことができる。例えば、Ｊａｖａ（登録商標）ではjava.lang.ThreadLocalクラスのメソッド呼び出しを利用しておこなう。本実施形態では、クライアントプログラム１１４から送信されたリクエストは、シングルスレッドによって処理されることが前提となっているため、ＴＬＳに保管したログ追跡情報は、当該リクエストの処理中は常に参照可能となる。
【００６１】
ログ出力処理部１０５は、通信処理部１０３から渡されたログ追跡情報の他に、独自に生成したログ追跡情報をＴＬＳに保管できる。例えば、同一クラスタノード内でリクエストを一意に特定可能な独自のセッションＩＤ（以後、「ＬＳＩＤ」と記す。Local Session IDの略）を生成し、ＴＬＳに保管することにより、クラスタシステム内で一意的なセッションＩＤ（上記の通信処理部１０３が、シーケンス３０３でログ追跡情報として渡したセッションＩＤがこれに該当する）（以後、「ＧＳＩＤ」と記す。Global Session IDの略）が設定されない通信において、クラスタノード内のリクエストを識別できるようになる。また、ＧＳＩＤが設定されるリクエストにおいても、ＬＳＩＤにより、特定のクラスタノード内に限定したログデータの追跡が可能になり、利便性が向上する。
【００６２】
次に、通信処理部１０３は、シーケンス３０３の呼び出し処理が完了した後、ビジネスロジック処理部１０６（図３では、図示せず）を呼び出しビジネスロジックを実行する（シーケンス３０５）。通信処理部１０３は、受信したリクエストの内容を基に呼び出すビジネスロジック処理部３０５のサーバモジュールを決定し、リクエストの処理を委譲する。処理を委譲されたサーバモジュールは、内部でログデータを自由に出力できる。
【００６３】
サーバモジュールに委譲した処理が返ると、通信処理部１０３はログ出力処理部１０５が公開するＡＰＩを利用し、ログ出力の終了通知をおこなう（シーケンス３０６）。
【００６４】
ログ出力の終了通知を受けたログ出力処理部１０５は、ＴＬＳ内のログ追跡情報として格納されているデータを破棄する（シーケンス３０７）。ＴＬＳに保管したログ追跡情報は、スレッドが破棄されるか明示的にＴＬＳをクリアしない限り解放されない。よって終了処理をおこなうことにより、不要なメモリの増加を抑制できる。
【００６５】
なお、図３において点線の矢印は、制御がリターンすることを表しており、必要なときには、リターン情報が返される。
【００６６】
次に、図４を用いてログ出力処理について説明する。
【００６７】
先ず、通信処理部１０３がビジネスロジック処理部１０６にロジックを実行することを要求する（シーケンス４０１）。このシーケンス４０１は、図３のシーケンス３０５において、通信処理部１０３がビジネスロジック処理部１０６のＡＰＩを呼び出したことを表わしている。
【００６８】
ビジネスロジック処理部１０６は、ログ出力処理部１０５のログ出力用ＡＰＩを呼ぶことにより、任意のログデータを出力できる（シーケンス４０２）。ログデータの一般例として、ログを一意に識別可能なログＩＤや、ログメッセージ、ログレベルなどが挙げられる。
【００６９】
ログ出力処理部１０５は、ログ出力用ＡＰＩが呼ばれると、図３のシーケンス３０４で保管したログ追跡情報をＴＬＳから読み込む（シーケンス４０３）。
【００７０】
続いて、ログ出力処理部１０５は、シーケンス４０３で読み込んだログ追跡情報と、ログ出力用ＡＰＩを介して渡されたログのデータを組合わせて、ログ追跡情報を付加したログデータを新たに構築する（シーケンス４０４）。新たに構築されたログデータのフォーマットは、実装依存であるが、少なくともログ収集処理部１０７が解析可能なログデータでなければならない。ここで解析可能なログデータとは、ログ追跡情報および変換前のログデータを復元可能なログデータのことである。例えば下記のように、情報の出力順序と出力情報間のセパレータ文字列（下記の例では“：”）が決定したログデータなどが考えられる。
・［日時］：［セッションＩＤ］：［ユーザＩＤ］：［シーケンス番号］：［ログＩＤ］
ここで、［ログＩＤ］は、ビジネスロジック処理部１０６がログ出力用に渡したログのデータを一意的に識別するＩＤである。
【００７１】
続いて、ログ出力処理部１０５は、シーケンス４０４で構築したログデータを補助記憶装置２０６に保管する（シーケンス４０５）。ここではログデータの保管処理を高速化するために同一マシン上の補助記憶装置２０６に保管する一般例を示したが、別のマシンのデータベース等に保管することも可能である。
【００７２】
最後に、ログ出力処理部１０５は、ログ追跡情報に含まれる更新可能なデータを更新する（シーケンス４０６）。例えば、シーケンス番号に１を加えるといった更新処理が考えられる。
【００７３】
シーケンス４０２から４０６の処理は、ビジネスロジック処理部１０６の実装依存で繰り返し実行できる。このシーケンスを繰り返すことで、ログ追跡情報を含んだログデータが蓄積される。ここで、ビジネスロジック処理部１０６の開発者は、ログ追跡情報の追加を意識することなくログデータの出力をおこなうことができ、開発生産性が向上する。
【００７４】
次に、図５を用いてログ収集処理について説明する。
【００７５】
ログ収集処理を開始するタイミングは実装依存であるが、例えば、サーバプログラム１０２の起動時にログ収集処理部１０７のログ収集開始用ＡＰＩを呼ぶことにより、ログ収集を開始するといった処理が考えられる。
【００７６】
先ず、ログ収集をおこなうときに、ログ出力処理部１０５がログファイル等に保管したログデータをログ収集処理部１０７が読み込む（ステップ５０１）。このステップは、収集済の（データベース等に永続化された）ログデータと、未収集のログデータを比較するために実行する。よって、全てのログデータを読み込む必要はなく、最後に出力されたログデータのみを読み込めばよい。
【００７７】
次に、ステップ５０１の説明で述べた収集済のログデータを、ログ収集処理部１０７がストレージプログラム１１６を利用して読み込む（ステップ５０２）。ステップ５０２の処理と同様、全ての収集済ログデータを読み込む必要はなく、最後に収集されたログデータのみを読み込めばよい。  
【００７８】
次に、ステップ５０１およびステップ５０２で読み込んだ、未収集のログデータと収集済ログデータの差分を、ログ収集処理部１０７が抽出する（ステップ５０３）。最後に収集されたログデータの出力日時と、最後に出力された未収集ログデータの出力日時を比較し、差異が認められた場合には、その差分を抽出する。
【００７９】
次に、ステップ５０３で差分データが抽出されたか否かを、ログ収集処理部１０７が判定する（ステップ５０４）。そして、差分データが抽出された場合（すなわち、収集すべきログデータが存在する場合）には、ステップ５０５へ、差分データが抽出されなかった場合（すなわち、収集すべきログデータが存在しない場合）には、ステップ５０６へ進む。
【００８０】
ステップ５０４での判定の結果、差分データが抽出された場合には、ステップ５０６は、ログ収集処理部１０７がストレージプログラム１１６を利用して、ステップ５０４で抽出した差分データをデータベース等のストレージに永続化する（ステップ５０５）。クラスタ内に分散したログデータを、サーバシステム共通のストレージに収集することで、サーバシステム全体のログデータを一元管理できる。
【００８１】
ステップ５０４での判定の結果、差分データが抽出されなかった場合には、次に、ログデータの収集処理を実行する日時をスケジュールする（ステップ５０６）。スケジュール方法は、実装依存だが、例えば、サーバシステムの管理者がログ管理プログラム１１５を利用してスケジュール日時を設定し、ステップ５０７で当該スケジュール日時を読み込んで次の収集日時を決定するといった方法が考えられる。運用上、システム管理者は、一日に一度、ログ収集をするようにするとか、１時間に一度、ログ収集をするようにするとかの検査頻度を設定できるようにしてもよい。
【００８２】
次に、次の収集処理を開始するまでの一定期間、スレッドを停止するなどして待機する（ステップ５０７）。待機時間は実装依存だが、予め決められた期間（例えば、１時間等）待機したり、ステップ５０６で設定したスケジュール日時に達するまで待機したりするといった実装が考えられる。
【００８３】
次に、ステップ５０７で一定期間待機した後、ステップ５０６で設定したスケジュール日時に達したか否かを判定する（ステップ５０７）。当該スケジュール日時に達している場合は、ステップ５０１に戻り、収集処理を開始する。達していない場合はステップ５０７に戻り、再び一定期間待機する。
【００８４】
ステップ５０１から５０８を繰り返すことにより、各クラスタノード内のログデータを、サーバシステム共通のデータベース等に永続化し、一元管理することができる。
【００８５】
次に、図６を用いてログ追跡情報が付加されたログデータを、ストレージプログラム１１６で扱う場合の管理形式について説明する。
図６は、ログ追跡情報が付加されたログデータを、データベースのテーブル形式で格納した管理形式を説明する図である。
【００８６】
上記では、ログ追跡情報が付加されたログデータの各項目をセパレータ文字列で区切った形式を説明したが、実際には、ＳＱＬなどのＲＤＢソフトウェアで扱えるようにしておくのが、検索やデータ加工にとっても便利である。図６は、そのために、ログ収集処理部１０７によって収集され、ストレージプログラム１１６によって永続化されたログ追跡情報が付加されたログデータをログテーブルとして、データを格納する場合の一例を示している。
【００８７】
図６に示す通り、ログテーブルでは、各種情報を個別のテーブルカラムとして定義する。例えば、図では、カラム６０１にログデータの出力日時、カラム６０２にＧＳＩＤ、カラム６０３にＬＳＩＤ、カラム６０４にシーケンス番号（ＳＥＱ：Sequence Numberの略）、カラム６０５にユーザＩＤ、カラム６０６にログＩＤを格納している。このログテーブルの形式において、カラム６０１ないしカラム６０６が、ログ追跡情報を格納するカラムである。
【００８８】
カラム６０１にログデータの出力日時は、ログを出力したときの日時を表す文字列である。カラム６０２のＧＳＩＤは、上で説明したクラスタシステム内で一意的なセッションＩＤであるＧＳＩＤを表す文字列である。カラム６０３のＬＳＩＤは、同一クラスタノード内でリクエストを一意に識別するためのセッションＩＤであるＬＳＩＤを表す文字列である。カラム６０４のシーケンス番号は、ログデータの出力順序を表す連番し、同一スレッドの中では、一意的に付けられる番号である。カラム６０５のユーザＩＤは、クライアントからログオンし、サーバに処理を依頼してユーザを表す文字列である。カラム６０６のログＩＤは、ビジネスロジック処理部１０６がログ出力用に渡したログのデータを一意的に識別するための文字列である。
【００８９】
このように、ログ追跡情報とログデータに含まれる各種情報をテーブル形式で管理し、ＳＱＬ文等を利用することでログデータの検索性能を向上できる。従来のログ出力方式では、ログデータのフォーマットが統一されていないため、当該情報の個別管理は困難であった。当該情報を個別管理するためには、ログデータのどの位置に情報が記述されているかを判定できなければならない。
【００９０】
上記のようにテーブル形式で管理しておくと、ログデータのどの位置にどの情報が格納されているかを判定することが可能であり、当該情報の個別管理が容易となる。
【００９１】
以上、ログ追跡情報が付加されたログデータをテーブル形式で管理する例について述べたが、これは管理形式を限定するものではなく、ログデータの一元管理が可能であれば他の形式でもよい。
【００９２】
次に、図７および図８を用いてログデータの管理画面のユーザインタフェースと、ログ検索時の処理について説明する。
図７は、ログデータの管理画面を示す図である。
図８は、ログデータの管理画面からユーザがログ検索をおこなうときのシステムの処理を示すシーケンス図である。
【００９３】
ログデータの管理画面は、サーバシステムの管理者が、ログデータを追跡する際に利用するものであり、この例では、ログ管理プログラム１１５がログ管理マシン１０９の出力装置２０３に出力した画面であることを想定している。また、ログ管理プログラム１１５は、ウェブブラウザであることを想定している。
【００９４】
エリア７０１は、ログデータの検索条件を入力するための入力欄が設置されている。サーバシステムの管理者が、追跡したいログデータの条件をエリア７０１に入力し、ボタン７０２を押下することで、検索結果がテーブル７０３に表示される。エリア７０１で入力する「表示エントリ数」は、テーブル７０３に表示される最大のログデータ数を表す。図のように「１０００」と入力した場合、テーブル７０３には検索条件に合致する最初の１０００件のログデータが表示される。
【００９５】
このエリアで示されている日時指定、ＧＳＩＤ、ＬＳＩＤ、シーケンス番号、ログＩＤは、図６の所で説明したものと同じである。
【００９６】
テーブル７０３に表示される検索結果の各情報には、ハイパーリンクが設定される（図７では、下線で表示）。このハイパーリンクをクリックすることにより、管理者は、その情報による絞込み検索を実行できる。例えば、「ユーザＩＤ」カラムの「ｕｓｅｒＢ」に設定されたハイパーリングをクリックすることにより、テーブル７０３に表示された検索結果の中から、さらにユーザＩＤが「ｕｓｅｒＢ」である検索結果だけを表示できる。この仕組みをインタフェースに取り入れることで、ログ追跡を容易化できる。
【００９７】
エリア７０４は、ログ管理命令を実行するためのボタン群を配置した欄である。マウスなどのポインティングデバイスによって、「収集開始」ボタンを押下すると、スケジュール日時の設定に関わらず即座にログデータの収集を開始するための管理命令を実行する。「旧データ削除」ボタンを押下すると、収集済の古いログデータを各サーバマシン１０１上から削除するための管理命令を実行する。「スケジュール設定」ボタンを押下することにより、ログ収集処理の開始日時を設定するための管理命令を実行する。なお、スケジュールのための日時を設定するためダイアログボックス等の表示については省略する。
【００９８】
次に、図７に示したログデータの管理画面への入力を受けて、ログ管理プログラム１１５がログ管理機能処理部１０４に検索要求および管理命令を送信する際の処理シーケンスについて説明する。
【００９９】
先ず、ログ管理プログラム１１５が通信処理部１０３に対し、ログデータの検索要求を送信する（シーケンス８０１）。ログ管理プログラム１１５は、図７の「検索」ボタン７０２が押下されると、フィールド７０１に入力された検索条件を通信処理部１０３に送信する。
【０１００】
通信処理部１０３は、ログ管理プログラム１１５から受信した検索条件をログ管理機能処理部１０４に送信する（シーケンス８０２）。
【０１０１】
ログ管理機能処理部１０４は、通信処理部１０３から受信した検索条件に基づいて、ＳＱＬクエリを構築し、ストレージプログラム１１６にＳＱＬクエリを送信する（シーケンス８０３）。
【０１０２】
ログ管理機能処理部１０４は、ストレージプログラム１１６から返されたＳＱＬクエリ実行結果に基づいて、検索結果画面を表すＨＴＭＬを生成する（シーケンス８０４）。
【０１０３】
そして、ログ管理プログラム１１５は、ログ管理機能処理部１０４から返された検索結果をブラウザ画面に表示する（シーケンス８０５）。
【０１０４】
シーケンス８０１から８０５は、検索を実行する毎に繰り返されるシーケンスである。
【０１０５】
一方、図７のエリア７０４に設置された各ボタンが押下されると、ログ管理プログラム１１５は、ボタンの種類に応じた管理命令を通信処理部１０３に送信する（シーケンス８０５）。
【０１０６】
通信処理部１０３は、ログ管理プログラム１１５から受信した管理命令をログ管理機能処理部１０４に送信する（シーケンス８０７）。
【０１０７】
ログ管理機能処理部１０４は、通信処理部１０３から受信した管理命令の種類に応じて、ログ収集の開始命令、古いログデータの削除命令、ログ収集スケジュールの再設定命令などを実行する（シーケンス８０８）。
【０１０８】
ログ管理機能処理部１０４は、ログ管理命令の実行結果に基づいて、実行結果画面を表すＨＴＭＬを生成する（シーケンス８０９）。
【０１０９】
ログ管理プログラム１１５は、ログ管理機能処理部１０４から返された実行結果をブラウザ画面に表示する（シーケンス８１０）。実行結果の画面構成は実装依存である。
【０１１０】
シーケンス８０６から８１０は、ログ管理命令を実行する毎に繰り返されるシーケンスである。
【０１１１】
以上、図７および図８を用いてログデータの管理画面と、ログデータの管理画面からユーザがログ検索をおこなうときのシステムの処理について述べたでは、ウェブベースのログデータの管理画面で、ＨＴＭＬ生成をおこなって画面の表示をおこない、ログデータは、ＲＤＢにより処理する方法について述べたが、専用のプロトコルや管理ソフトウェアを用いて同様の処理をおこなうことも可能である。
【符号の説明】
【０１１２】
１０１…サーバマシン
１０２…サーバプログラム
１０３…通信処理部
１０４…ログ管理機能処理部
１０５…ログ出力処理部
１０６…ビジネスロジック処理部
１０７…ログ収集処理部
１０８…サーバ基本ミドルウェア
１０９…ログ管理マシン
１１５…ログ管理プログラム
１１０…ストレージマシン
１１６…ストレージプログラム
１１１…ロードバランサ
１１７…クライアントマシン
１１４…クライアントプログラム
【図１】
2014081811.tif 000003
【図２】
2014081811.tif 000004
【図３】
2014081811.tif 000005
【図４】
2014081811.tif 000006
【図５】
2014081811.tif 000007
【図６】
2014081811.tif 000008
【図７】
2014081811.tif 000009
【図８】
2014081811.tif 000010