JP5686001B2 - 情報処理装置、メッセージ切分け方法およびメッセージ切分けプログラム - Google Patents

Description

本発明は、情報処理装置、メッセージ切分け方法およびメッセージ切分けプログラムに関する。

従来、インターネットを介してユーザにサービスを提供するＷｅｂアプリケーションの運用管理などでは、ユーザの処理要求の遅延などを監視するために、Ｗｅｂアプリケーションの性能測定が行われる。

性能を測定するには、ユーザからの処理要求を一連のメッセージ群から検出し、最初のリクエストからユーザへのレスポンスまでのＨＴＴＰ（HyperText Transfer Protocol）リクエスト処理やＤＢ（Data Base）アクセス処理を監視することが有効である。すなわち、Ｗｅｂアプリケーションが実行した各トランザクションを検出することが有効である。

このようなＷｅｂアプリケーションの性能を測定する手法としては、プロファイリングやネットワークモニタリングなどが一般的に利用されている。例えば、プロファイリングは、プロファイル対象サーバで動作するアプリケーション内部で実行された各処理の実行状況を監視する。また、ネットワークモニタリングは、対象のサーバが送受信したパケットをキャプチャリングして、対象のサーバと外部サーバとの通信を監視する。

また、トランザクションの開始を契機として、トランザクションを識別するトランザクションＩＤを生成する。そして、生成したトランザクションＩＤを用いてトランザクションを識別し、１つのトランザクションを連携して実行するサーバ間の処理順序を生成することも行われている。

特開２００９−２７７１１９号公報 特開２０１０−１４６１４６号公報 特表２００８−５０２０４４号公報 特開２０１０−４４７４２号公報

しかしながら、従来の技術では、一連のトランザクションを関連付けることができないという問題があった。

例えば、プロファイリングでは、アプリケーション内部の処理を監視することができても、外部機器との通信情報を監視できない。また、ネットワークモニタリングでは、外部との通信を監視できても、アプリケーション内部の処理を監視できない。つまり、これらの技術では、トランザクション全体を監視することができないので、アプリケーションサーバやデータベースサーバで実行されたトランザクションを関連付けることができない。なお、トランザクションＩＤを用いる技術の場合も、各トランザクションが実行されたサーバの順番を特定しているだけであり、データベースシステムに対して実行されたトランザクションを監視できない。

一例を挙げると、ＷｅｂアプリケーションがＤＢドライバにリクエストを送信する場合は、１つのＤＢドライバへのリクエストがＤＢサーバに対して複数のリクエストとして送信されて、複数のレスポンスとして受信することがある。この場合、従来技術では、ＤＢドライバとサーバ間の通信をトランザクションに対応付ける情報がなく、対応付けができない。

１つの側面では、一連のトランザクションを関連付けることができる情報処理装置、メッセージ切分け方法およびメッセージ切分けプログラムを提供することを目的とする。

第１の案では、情報処理装置は、トランザクションを識別するトランザクション識別子を有するメッセージの出現パターンを記憶する第１記憶部を有する。情報処理装置は、第１のサーバによって前記トランザクション識別子を有するトランザクションが第２のサーバに実行され、前記第１のサーバと前記第２のサーバとの間で発生したメッセージを記憶する第２記憶部を有する。情報処理装置は、前記第１記憶部に記憶されるメッセージの出現パターンに基づいて、前記第２記憶部に記憶されているメッセージを前記トランザクションごとに分類する分類部を有する。

一連のトランザクションを関連付けることができる。

図１は、実施例１に係るシステムの全体構成を示す図である。 図２は、実施例２に係るアプリケーションサーバの構成を示すブロック図である。 図３は、ＩＤ情報テーブルに記憶される情報の例を示す図である。 図４は、ロギング対象テーブルに記憶される情報の例を示す図である。 図５は、ＤＢ命令置換対象テーブルに記憶される情報の例を示す図である。 図６は、実施例２に係る紐付けサーバの構成を示すブロック図である。 図７は、アプリログテーブルに記憶される情報の例を示す図である。 図８は、ＤＢキャプチャテーブルに記憶される情報の例を示す図である。 図９は、アプリメソッド分類テーブルに記憶される情報の例を示す図である。 図１０は、ＤＢ分類テーブルに記憶される情報の例を示す図である。 図１１は、トランザクションＩＤテーブルに記憶される情報の例を示す図である。 図１２は、学習テーブルに記憶される情報の例を示す図である。 図１３は、メッセージ分類テーブルに記憶される情報の例を示す図である。 図１４は、アプリメソッド分類テーブルで表されるログメッセージの関係例を示す図である。 図１５は、ＤＢ分類テーブルで表されるキャプチャメッセージの関係例を示す図である。 図１６は、アプリケーションサーバが実行する処理の流れを示すフローチャートである。 図１７は、紐付けサーバが実行する紐付け処理の流れを示すフローチャートである。 図１８は、紐付けサーバが実行する学習処理の流れを示すフローチャートである。 図１９は、メッセージ切分けプログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に、本願の開示する情報処理装置、メッセージ切分け方法およびメッセージ切分けプログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

図１は、実施例１に係るシステムの全体構成を示す図である。図１に示すように、このシステムは、Ｗｅｂサーバ１と、アプリケーションサーバ２と、ＤＢ（DataBase）サーバ３と、スイッチ４と、紐付けサーバ５とを有する。なお、これらの装置は、ＬＡＮ（Local Area Network）やインターネットなどのネットワークを介して接続される。

Ｗｅｂサーバ１は、ＨＴＭＬ（HyperText Markup Language）文書や画像などの情報を蓄積し、Ｗｅｂブラウザなどを介してクライアントから受信した要求に応じて、ＨＴＭＬ文書や画像を応答するサーバ装置である。このＷｅｂサーバ１は、トランザクションの実行結果をログとして保持する。例えば、Ｗｅｂサーバ１は、アプリケーションサーバ２によって実行されたアプリケーションから応答を受信し、Ｗｅｂブラウザなどからの要求に応じた情報を応答する。

アプリケーションサーバ２は、クライアントやＷｅｂサーバ１から要求を受け付けてアプリケーションを実行し、Ｗｅｂサーバ１やＤＢサーバ３へトランザクションを実行するサーバ装置であり、アプリケーションの実行結果をログとして保持する。このアプリケーションサーバ２は、ＩＤ生成部２ａとＩＤ付加部２ｂとを有する。

ＩＤ生成部２ａは、アプリケーションの実行を要求したクライアントごとに一意な識別子であり、当該アプリケーションが実行するトランザクションを識別するトランザクションＩＤ（以下、TranIDと表記する）を生成する。ＩＤ付加部２ｂは、ＩＤ生成部２ａにより生成されたTranIDをトランザクションに付加してトランザクションを実行する。例えばクライアントから要求を受信したＷｅｂサーバ１が、Ｗｅｂサーバ１内へのトランザクション、アプリケーションサーバ２へのトランザクション、ＤＢサーバ３へのトランザクションを実行したとする。すると、ＩＤ生成部２ａは、トランザクション各々に対してTranIDを生成する。その後、ＩＤ付加部２ｂは、TranIDを付加したトランザクションを該当サーバに実行する。

ＤＢサーバ３は、データを記憶するＤＢを有し、アプリケーションサーバ２から受信したトランザクションに応じて、データの書き込みやデータの読み出しを実行するサーバ装置である。このＤＢサーバ３は、トランザクションの実行結果をログとして保持する。このＤＢサーバ３が有するＤＢは、関係データベースであってもよく、オブジェクトデータベースであってもよく、ＫＶＳ（キーバリューストア）などであってもよい。

スイッチ４は、ネットワーク内の経路情報を保持し、各サーバ間の通信をスイッチングするＬ２スイッチ（レイヤ２スイッチ））やスイッチングハブなどの中継装置である。例えば、スイッチ４は、紐付けサーバ５とＷｅｂサーバ１との間、紐付けサーバ５とアプリケーションサーバ２との間、紐付けサーバ５とＤＢサーバ３との間の通信を中継する。なお、スイッチ４は、ルータやＬ３スイッチ（レイヤ３スイッチ）などであってもよい。

紐付けサーバ５は、第１記憶部５ａ、第２記憶部５ｂ、分類部５ｃを有し、各サーバで実行されたトランザクションを紐付けするサーバ装置である。第１記憶部５ａは、トランザクションを識別するトランザクション識別子を有するメッセージの出現パターンを記憶する。第２記憶部５ｂは、アプリケーションサーバ２によってTranIDを有するトランザクションＤＢサーバ３に実行され、アプリケーションサーバ２とＤＢサーバ３との間で発生したメッセージを記憶する。分類部５ｃは、第１記憶部５ａに記憶されるメッセージの出現パターンに基づいて、第２記憶部５ｂに記憶されているメッセージをトランザクションごとに分類する。

一般的に、アプリケーションサーバ２は、アプリケーションサーバ２内のトランザクション、Ｗｅｂサーバ１へのトランザクション、ＤＢサーバ３へのＳＱＬ分などのトランザクションにはTranIDを付加することができる。したがって、これらのトランザクションの実行により発生したログメッセージや通信メッセージには、TranIDが含まれる。ところが、アプリケーションサーバ２は、ＤＢサーバ３が実行するトランザクションに関係ないコネクション確立などの処理についてはTranIDを付加できない。このような場合、アプリケーションサーバ２から実行されたトランザクションと、ＤＢサーバ３から発生したメッセージとを対応付けることができない。

そこで、実施例１に係る紐付けサーバ５は、ＤＢサーバ３との間で発生したメッセージにおいて、TranIDを有するメッセージが何番目に出現されるのかを示す出現位置を学習して記憶しておく。この結果、紐付けサーバ５は、アプリケーションへの処理要求から始まる一連のトランザクションを、ＤＢアクセスに至るまで関連付けることができる。

実施例２では、図１に示した各装置の一例として、機能ブロック、処理の流れ、効果等について説明する。なお、Ｗｅｂサーバ１は、一般的なＷｅｂサーバと同様の機能を有し、ＤＢサーバ３は、一般的なＤＢサーバ等と同様の機能を有し、スイッチ４は、一般的なスイッチと同様の機能を有するので、ここでは詳細な説明は省略する。

［アプリケーションサーバの構成］
図２は、実施例２に係るアプリケーションサーバの構成を示すブロック図である。図２に示すように、アプリケーションサーバ１０は、通信部１１、アプリテーブル１２、ＩＤ情報テーブル１３、ロギング対象テーブル１４、ＤＢ命令置換対象テーブル１５、ログテーブル１６、制御部１７を有する。また、各テーブルは、例えば半導体メモリ素子やハードディスクなどの記憶装置に設けられる。また、各テーブルに記憶される情報は例示するものではなく、任意に設定変更できる。

通信部１１は、他の装置との間の通信を制御するインタフェースである。例えば、通信部１１は、アプリケーションサーバ１０と他サーバとの間で通信メッセージを送受信したり、アプリケーションサーバ１０から他のサーバにトランザクションを送信したりする。また、この通信部１１は、ＤＢドライバとしての機能を有する。例えば、通信部１１は、後述するアプリ実行部１７ａによって実行されたトランザクションによるリクエストをＤＢサーバ３へ発行し、ＤＢサーバ３からレスポンスを受信する。

アプリテーブル１２は、アプリケーションサーバ１０が実行するアプリケーションのプログラムを記憶する。例えば、アプリテーブル１２は、Ｊａｖａ（登録商標）で記述されたプログラムを記憶する。アプリケーションサーバ１０は、クライアントから受信した要求に対応するアプリケーションのプログラムをアプリテーブル１２から特定して実行することで、各種サービスを提供する。

ＩＤ情報テーブル１３は、後述するＩＤ生成部１７ｂによって生成されたTranIDと、当該TranIDが与えられたアプリケーション情報を記憶する。図３は、ＩＤ情報テーブルに記憶される情報の例を示す図である。図３に示すように、ＩＤ情報テーブル１３は、「クラス名、メソッド名、TranID」として「org.hibernate.foo、createQuery、tid−123」などを記憶する。

ここで記憶される「クラス名」は、Ｊａｖａ（登録商標）で記述されたプログラム内のクラスを示す情報であり、「メソッド名」は、クラス名で特定されるクラス内のメソッドを示す情報であり、「TranID」は、生成されたトランザクションＩＤである。図３の例は、「org.hibernate.foo」クラス内の「createQuery」には、「tid−123」が付与されたことを示す。

ロギング対象テーブル１４は、ログメッセージ出力対象となるアプリケーションの情報を記憶する。図４は、ロギング対象テーブルに記憶される情報の例を示す図である。図４に示すように、ロギング対象テーブル１４は、「クラス名、メソッド名」として「java.foo.ClassA、*（*：アスタリスク）」や「org.hibernate.*、*」、「myApp.*、*」などを記憶する。

ここで記憶される「クラス名」や「メソッド名」は、図３と同様の情報を示すので、説明を省略する。図４の例は、「java.foo.ClassA」内の各メソッドがロギング対象であり、「org.hibernate」で始まるクラス内の各メソッドがロギング対象であり、「myApp」で始まるクラス内の各メソッドがロギング対象であることを示す。

ＤＢ命令置換対象テーブル１５は、アプリケーションによって読み出されたＤＢ命令が置換対象であるか否かを示す情報を記憶する。図５は、ＤＢ命令置換対象テーブルに記憶される情報の例を示す図である。図５に示すように、ＤＢ命令置換対象テーブル１５は、「クラス名、メソッド名」として「org.hibernate.foo、createQuery」などを記憶する。

ここで記憶される「クラス名」や「メソッド名」は、図３と同様の情報を示すので、説明を省略する。図５の例は、「org.hibernate.foo」クラス内の「createQuery」メソッドは置換対象であることを示す。

ログテーブル１６は、アプリケーションすなわちクラスやメソッドが実行されることで発生したログを記憶する。また、ログテーブル１６は、アプリケーションが各装置に実行されることで発生した通信メッセージ等を記憶する。つまり、ログテーブル１６は、アプリケーションサーバ１０が実行したトランザクションによって発生したログや通信メッセージなどのログメッセージを記憶する。ログテーブル１６が記憶する情報としては、上述したTranID、クラス名、メソッド名に加えて、ログが発生した時刻、正常終了や異常終了などの情報を示す処理結果などがある。

制御部１７は、アプリ実行部１７ａとＩＤ生成部１７ｂとＩＤ付加部１７ｃとを有し、アプリケーションを実行する処理部である。この制御部１７は、例えば、ＣＰＵ（Central Processing Unit）などの電子回路やＡＳＩＣ（Application Specific Integrated Circuit）などの集積回路で実行される。

アプリ実行部１７ａは、クライアントの要求に応じてアプリケーションを実行する。例えば、アプリ実行部１７ａは、クライアントの要求に対応したアプリケーションをアプリテーブル１２から特定して、特定したアプリケーション内のメソッドを読み出して実行する。

ＩＤ生成部１７ｂは、アプリケーションの実行を要求したクライアントごとに一意な識別子であり、当該アプリケーションが実行するトランザクションを識別するTranIDを生成する。例えば、ＩＤ生成部１７ｂは、アプリケーションのクラス内から読み出されたメソッドをフックし、ＩＤ情報テーブル１３を参照して、当該メソッドにＩＤが付与されているか否かを判定する。

そして、ＩＤ生成部１７ｂは、フックしたメソッドにＩＤが付与されていると判定した場合、当該メソッドをそのままＩＤ付加部１７ｃに出力する。一方、ＩＤ生成部１７ｂは、フックしたメソッドにＩＤが付与されていないと判定した場合、当該メソッドに対して一意なTranIDを生成する。その後、ＩＤ生成部１７ｂは、生成したTranIDと、メソッドを有するクラス名と、読み出されたメソッド名とを対応付けてＩＤ情報テーブル１３に格納する。また、ＩＤ生成部１７ｂは、フックしたメソッドをＩＤ付加部１７ｃに出力する。

別の手法としては、ＩＤ生成部１７ｂは、処理スレッドごとにTranIDを生成することもできる。なお、処理スレッドには、一意なＩＤであるスレッドＩＤが割り振られており、ＷｅｂサーバからセッションＩＤをもって入力される。また、アプリケーションサーバ１０が、スレッドＩＤとセッションＩＤとの対応付けを管理する。

ＩＤ生成部１７ｂは、処理スレッドごとに最新ＩＤの情報を保持する。そして、ＩＤ生成部１７ｂは、新しいセッション（トランザクション）が開始されると、最新ＩＤを更新する。例えば、セッション（ＩＤ＝ｓｅｓ−１２３）が終了して処理スレッド（処理スレッドＩＤ＝２５６）が解放される。次に、新しいセッション（ＩＤ＝ｓｅｓ−３３０）が開始され、処理スレッドとして（ＩＤ＝２５６）が再利用されたとする。すると、ＩＤ生成部１７ｂは、処理スレッド（ＩＤ＝２５６）の最新ＩＤを更新する。この場合、ＩＤ生成部１７ｂは、トランザクションＩＤとして、例えば「ｓｅｓ−３３０−２５６−７」などを生成する。このようにして生成されたトランザクションＩＤは、メソッド呼び出しを処理する処理スレッドから直接参照することができる。例えば、ＩＤ生成部１７ｂは、処理スレッド（ＩＤ＝２５６）がセッション（ｓｅｓ−３３０）の実行中に呼び出すクラス、メソッドには、TranID「ｓｅｓ−３３０−２５６−７」を付加することになる。

図２に戻り、ＩＤ付加部１７ｃは、ＩＤ生成部２ａにより生成されたTranIDをトランザクションに付加してトランザクションを実行する。例えば、ＩＤ付加部１７ｃは、ＩＤ生成部１７ｂから受信したメソッドの名称をキーにしてＩＤ情報テーブル１３を検索し、TranIDを特定する。そして、ＩＤ付加部１７ｃは、ＩＤ生成部１７ｂから受信したメソッドに、特定したTranIDを付加して、メソッドを実行する。

また、ＩＤ付加部１７ｃは、ロギング対象のメソッドのみにTranIDを付与してもよい。この場合、ＩＤ付与部１７ｃは、受信したメソッドがロギング対象テーブル１４に登録されているメソッドである場合に、TranIDを付与する。また、ＩＤ付加部１７ｃは、受信したメソッドがＤＢ命令置換対象テーブル１５に記憶されている場合、当該メソッド内のコメント分などでTranIDを埋め込むこともできる。

［紐付けサーバの構成］
図６は、実施例２に係る紐付けサーバの構成を示すブロック図である。図６に示すように、紐付けサーバ２０は、通信部２１、アプリログテーブル２２、ＤＢキャプチャテーブル２３、アプリメソッド分類テーブル２４、ＤＢ分類テーブル２５を有する。さらに、紐付けサーバ２０は、トランザクションＩＤテーブル２６、学習テーブル２７、メッセージ分類テーブル２８、制御部３０を有する。また、各テーブルは、例えば半導体メモリ素子やハードディスクなどの記憶装置に設けられる。また、各テーブルに記憶される情報は例示するものに限られず、任意に設定変更できる。

通信部２１は、他の装置の間の通信を制御するインタフェースである。例えば、通信部２１は、スイッチ４を介して、Ｗｅｂサーバ１、アプリケーションサーバ２、ＤＢサーバ３各々からログメッセージを受信する。

アプリログテーブル２２は、アプリケーションサーバ２が出力したログメッセージを記憶する。アプリログテーブル２２には、後述する情報取得部３０ａがアプリケーションサーバ２から取得した情報が格納される。図７は、アプリログテーブルに記憶される情報の例を示す図である。図７に示すように、アプリログテーブル２２は、「timestamp、App−key、開始／終了、TranID、クラス名、メソッド名、次のメッセージ、前のメッセージ」を対応付けて記憶する。

ここで記憶される「timestamp」は、ログメッセージが出力された時刻であり、「App−key」は、アプリケーションサーバが割り与えるログメッセージを識別する識別子である。「開始／終了」は、ログメッセージがトランザクションの開始か終了であるかを示し、「TranID」は、ログメッセージに付加されているトランザクションＩＤを示す。また、「クラス名」は、ログメッセージを出力したクラスの名称を示し、「メソッド名」は、ログメッセージを出力したメソッドの名称を示す。「次のメッセージ」は、次に出力されたログメッセージのApp−keyであり、「前のメッセージ」は、前に出力されたログメッセージのApp−keyである。

図７の場合、「12：33：02」に出力されたログメッセージには、「App-key＝123」が割り与えられている。このログメッセージは、「tid−123」を有するとともにトランザクションの「開始」を示し、「org.hibernate.foo」クラスの「createQuery」メソッドによって出力されたことを示す。また、このログメッセージの次に出力されたログメッセージは、「124」であることを示す。

同様に、「12：37：04」に出力されたログメッセージには、「App-key＝124」が割り与えられている。このログメッセージは、「tid−123」を有するとともにトランザクションの「終了」を示し、「org.hibernate.foo」クラスの「createQuery」メソッドによって出力されたことを示す。また、このログメッセージの前に出力されたログメッセージが「123」であり、次に出力されたログメッセージが「125」であることを示す。

ＤＢキャプチャテーブル２３は、アプリケーションサーバ２とＤＢサーバ３との間で送受信されたキャプチャメッセージを記憶する。ＤＢキャプチャテーブル２３には、後述する情報取得部３０ａがネットワーク内のパケット等をキャプチャすることで生成された情報が格納される。図８は、ＤＢキャプチャテーブルに記憶される情報の例を示す図である。図８に示すように、ＤＢキャプチャテーブル２３は、「timestamp、DB−key、コネクションキー、fromIP、fromPort、toIP、toPort、sqlmsg、TranID、次のメッセージ、前のメッセージ」を対応付けて記憶する。

ここで記憶される「timestamp」は、キャプチャメッセージが出力された時刻であり、「DB−key」は、キャプチャメッセージを識別する識別子であり、例えばＤＢサーバ３によって一意に割り与えられる。「コネクションキー」は、IP（Internet Protocol）アドレスとポートとの組から一意に生成された識別子であり、例えばＤＢサーバ３によって生成される。「fromIP」は、トランザクションが実行されたコネクションで接続されるサーバのうちキャプチャメッセージの発行元サーバのIPアドレスである。「fromPort」は、トランザクションが実行されたコネクションで接続されるサーバのうちキャプチャメッセージの発行元サーバのポート番号である。「toIP」は、トランザクションが実行されたコネクションで接続されるサーバのうちキャプチャメッセージの発行先サーバのIPアドレスである。「toPort」は、トランザクションが実行されたコネクションで接続されるサーバのうちキャプチャメッセージの発行先サーバのポート番号である。

また、「sqlmsg」は、キャプチャメッセージがSQL命令を有する場合にそのSQL命令の内容を示し、「TranID」は、キャプチャメッセージがTranIDを有する場合にそのTranIDを示す。「次のメッセージ」は、次に送受信されたキャプチャメッセージのDB−keyであり、「前のメッセージ」は、前に送受信されたキャプチャメッセージのDB−keyである。

図８の場合、「12：33：03」にキャプチャされたキャプチャメッセージは、IPアドレス「A」のポート「59000」からIPアドレス「B」のポート「3306」に発行された、SQL文「select・・・」を有するメッセージである。このキャプチャメッセージは、TranID「tid−123」、DB−key「132」、コネクションキー「38」が付加されている。また、このキャプチャメッセージの前に出力されたキャプチャメッセージが「131」であり、次に出力されたキャプチャメッセージが「133」である。

アプリメソッド分類テーブル２４は、アプリログテーブル２２に記憶されるログメッセージをTranIDごとに関係付けた情報を記憶する。アプリメソッド分類テーブル２４には、後述する情報生成部３０ｂによって生成された情報が格納される。図９は、アプリメソッド分類テーブルに記憶される情報の例を示す図である。図９に示すように、アプリメソッド分類テーブル２４は、「キー、TranID、最終更新時刻、先頭メッセージ、末尾メッセージ、次の時刻順レコード、前の時刻順レコード」を対応付けて記憶する。

ここで記憶される「キー」は、TranIDごとに生成された識別子すなわちレコードを識別する識別子であり、例えば後述する情報生成部３０ｂによって生成される。「TranID」は、トランザクションを識別するトランザクションＩＤを示す。「最終更新時刻」は、当該TranIDを有するログメッセージのうち最も遅いタイムスタンプ値である。「先頭メッセージ」は、当該TranIDを有するログメッセージのうち最もタイムスタンプ値が早い先頭のログメッセージのAPP−keyである。「末尾メッセージ」は、当該TranIDを有するログメッセージのうち最もタイムスタンプ値が遅い末尾のログメッセージのAPP−keyである。「次の時刻順レコード」は、当該TranIDの次に発生したTranIDのレコードのキーを示し、「前の時刻順レコード」は、当該TranIDの前に発生したTranIDのレコードのキーを示す。

図９の１行目は、TranID「tid−123」を有するログメッセージ群であり、このログメッセージ群には、キー「15」が割り与えられている。このログメッセージ群の先頭のログメッセージはApp−key「123」のメッセージであり、末尾のログメッセージは「12：34：05」に発行されたApp−key「127」のメッセージである。すなわち、このログメッセージ群には、App−key「123」から「127」までのログメッセージが含まれている。また、このレコードの前のレコードは、キー「14」が割り与えられたレコードであり、次のレコードは、キー「18」が割り与えられたレコードであることを示している。

ＤＢ分類テーブル２５は、ＤＢキャプチャテーブル２３に記憶されるキャプチャメッセージをコネクションキーごとに関連付けた情報である。ＤＢ分類テーブル２５には、後述する情報生成部３０ｂによって生成された情報が格納される。図１０は、ＤＢ分類テーブルに記憶される情報の例を示す図である。図１０に示すように、ＤＢ分類テーブル２５は、「コネクションキー、最終更新時刻、先頭メッセージ、末尾メッセージ、先頭TranID情報、末尾TranID情報」を対応付けて記憶する。

ここで記憶される「コネクションキー」は、IPアドレスとポートとの組から一意に生成された識別子であり、レコードを識別する。「最終更新時刻」は、当該コネクションキーを有するキャプチャメッセージのうち最も遅いタイムスタンプの値である。「先頭メッセージ」は、当該コネクションキーを有するキャプチャメッセージのうち最もタイムスタンプ値が早い先頭のキャプチャメッセージのDB−keyである。「末尾メッセージ」は、当該コネクションキーを有するキャプチャメッセージのうち最もタイムスタンプ値が遅い末尾のキャプチャメッセージのDB−keyである。「先頭TranID情報」は、当該コネクションキーを有するキャプチャメッセージにおいて、はじめに登場するTranIDのレコードを特定する識別子であり、トランザクションＩＤテーブル２６で用いられている識別子である。「末尾TranID情報」は、当該コネクションキーを有するキャプチャメッセージにおいて、最後に登場するTranIDのレコードを特定する識別子であり、トランザクションＩＤテーブル２６で用いられている識別子である。

図１０の１行目は、コネクションキー「38」を有するキャプチャメッセージ群であり、このキャプチャメッセージ群には、DB−key「132」のメッセージから、時刻「12：34：06」に発行されたDB−key「144」までのキャプチャメッセージが含まれる。また、このキャプチャメッセージ群には、最初にTranID情報「512」が与えられたTranIDが登場し、最後にTranID情報「517」が与えられたTranIDが登場する。

トランザクションＩＤテーブル２６は、情報生成部３０ｂ等によって生成された情報であって、TranIDに関する情報を記憶する。図１１は、トランザクションＩＤテーブルに記憶される情報の例を示す図である。図１１に示すように、トランザクションＩＤテーブル２６は、「TranID情報、TranID、メッセージ、次のTranID情報、ＤＢ分類表情報」を対応付けて記憶する。

ここで記憶される「TranID情報」は、TranIDに割り与えられた識別子であって、レコードを識別する識別子であり、例えば情報生成部３０ｂによって生成される。「TranID」は、上述したトランザクション識別子である。「メッセージ」は、TranIDを保持するキャプチャメッセージのDB−keyである。「次のTranID情報」は、同一コネクション中の次のTranID情報への参照情報である。「ＤＢ分類表情報」は、当該レコードを保持するコネクションへの参照情報であり、コネクションキーが格納される。

図１１の場合、１行目のレコードには、TranID情報「512」が与えられている。このレコードは、コネクションキー「38」内のキャプチャメッセージのうち、DB−key「133」のキャプチャメッセージにTranID「tid−123」が保持されていることを示す。また、コネクションキー「38」では、このレコードの次に、TranID情報「513」のレコードのTranIDが出現することが示されている。

学習テーブル２７は、後述する学習部３１が学習した情報であり、トランザクションを識別するTranIDを有するメッセージの出現パターンを記憶する。図１２は、学習テーブルに記憶される情報の例を示す図である。図１２に示すように、学習テーブル２７は、「種別、先メッセージ数、全メッセージ数、信頼度」を対応付けて記憶する。

ここで記憶される「種別」は、学習されたトランザクションの種別を示す。「先メッセージ数」は、TranIDを有するキャプチャメッセージよりも前に出力されるキャプチャメッセージの数を示す。「全メッセージ数」は、学習されたトランザクションで出力されるキャプチャメッセージの総数を示す。「信頼度」は、学習された情報の信頼度を示し、例えば５を１番高くする５段階などで示される。

図１２の場合、データベースにテーブル等を作成する「Create」関連のトランザクションでは、全部で「4」つのキャプチャメッセージが出力され、そのうち「2」番目にTranIDを保持するキャプチャメッセージが出現することが示されている。また、この学習情報の信頼度が「5」であることが示されている。

メッセージ分類テーブル２８は、学習テーブル２７の学習情報を用いて、ＤＢ分類テーブル２５に記憶されるキャプチャメッセージをトランザクションごとに分類した結果を記憶する。メッセージ分類テーブル２８には、後述する分類部３２によって生成された情報が格納される。図１３は、メッセージ分類テーブル２８に記憶される情報の例を示す図である。図１３に示すように、メッセージ分類テーブル２８は、「TranID、種別、コネクションキー、メッセージ数、先頭メッセージ、末尾メッセージ、処理時間、結果」が対応付けて記憶される。

ここで記憶される「TranID」は、トランザクション識別子であり、「種別」は、トランザクションの種別を示し、「コネクションキー」は、ＤＢ分類テーブル２５のコネクションキーである。「メッセージ数」は、同じトランザクションが出力したメッセージであるとして分類されたメッセージ数である。「先頭メッセージ」は、分類されたキャプチャメッセージのうち先頭のキャプチャメッセージのDB−keyを示し、「末尾メッセージ」は、分類されたキャプチャメッセージのうち末尾のキャプチャメッセージのDB−keyを示す。「処理時間」は、トランザクションのＤＢアクセス時間を示し、先頭メッセージから末尾メッセージ終了までの時間である。「結果」は、正常にメッセージが分類できた場合には「正常」が格納され、正常にメッセージが分類できなかった場合には「異常」が格納される。

図１３の場合、コネクションキー「38」で実行された、「Create」を実行するトランザクション「tid−123」は、DB−key「132」のキャプチャメッセージからDB−key「134」のキャプチャメッセージまでの「4」つのキャプチャメッセージが出現する。そして、処理時間が「2s」であることが示されている。この「tid−123」のメッセージ分類は、「正常」に終了し、アプリケーションサーバ２から実行されたトランザクションとＤＢサーバ３のメッセージとが関連付けられたことを示す。

制御部３０は、メッセージの出現パターンを学習したり、キャプチャメッセージの分類を実行する処理部であり、例えばＣＰＵ（Central Processing Unit）などの電子回路やＡＳＩＣ（Application Specific Integrated Circuit）などの集積回路である。この制御部３０は、情報取得部３０ａ、情報生成部３０ｂ、学習部３１、分類部３２、結果処理部３３を有する。

情報取得部３０ａは、各サーバのログメッセージ情報を所定の間隔で取得する。例えば、情報取得部３０ａは、６０秒に１回など予め指定された間隔で、アプリケーションサーバ２が保持するログメッセージを取得して、アプリログテーブル２２に格納する。また、ソケット通信などを用いて、リアルタイムにデータを取得することもできる。

また、情報取得部３０ａは、ネットワーク内のパケットをキャプチャリングする。例えば、情報取得部３０ａは、アプリケーションサーバ２とＤＢサーバ３との間でやり取りされたパケットをキャプチャリングして、ＤＢキャプチャテーブル２３に格納する。なお、キャプチャリングの手法は、公知の様々な手法を用いることができるので、詳細な説明は省略する。また、情報取得部３０ａは、ＤＢキャプチャテーブル２３にキャプチャデータを格納する際に、ＤＢサーバ３からログメッセージを取得し、キャプチャデータに加えてＤＢキャプチャテーブル２３に格納することもできる。

情報生成部３０ｂは、アプリログテーブル２２やＤＢキャプチャテーブル２３などに記憶される情報から各種情報を生成して、アプリメソッド分類テーブル２４、ＤＢ分類テーブル２５、トランザクションＩＤテーブル２６に格納する。

まず、情報生成部３０ｂが実行するアプリメソッド分類テーブル２４の作成例について説明する。例えば、情報生成部３０ｂは、アプリログテーブル２２に記憶される「TranID」のうち、最も時間が早い「TranID」を１つ選択し、選択した「TranID」を有するログメッセージを抽出する。続いて、情報生成部３０ｂは、選択した「TranID」に「キー」を割り与え、「キー」と「TranID」の組を有する情報を格納するレコードをアプリメソッド分類テーブル２４に生成する。その後、情報生成部３０ｂは、抽出したログメッセージの「timestamp」にしたがって、ログメッセージを並び替える。

続いて、情報生成部３０ｂは、抽出したログメッセージの中から、最も「timestamp」が早いログメッセージの「App−key」を、生成したレコードの「先頭メッセージ」に格納する。同様に、情報生成部３０ｂは、抽出したログメッセージの中から、最も「timestamp」が遅いログメッセージの「App−key」を特定し、生成したレコードの「末尾メッセージ」に書き込む。さらに、情報生成部３０ｂは、最も遅い「timestamp」の値をアプリメソッド分類テーブル２４の「最終更新時刻」に格納する。このようにして、情報生成部３０ｂは、アプリログテーブル２２に記憶されるログメッセージを「TranID」ごとに分類して、分類した結果をアプリメソッド分類テーブル２４に格納する。また、情報生成部３０ｂは、アプリメソッド分類テーブル２４に生成した各レコードやアプリログテーブル２２の「timestamp」から、レコード間の時間順を特定して、「次の時間順レコード」と「前の時間順レコード」に「キー」を格納する。

一例を挙げると、情報生成部３０ｂは、アプリログテーブル２２からTranID「tid−123」を特定し、「tid−123」を保持するログメッセージとして、App−key「123」からApp−key「127」のログメッセージを抽出する。そして、情報生成部３０ｂは、「tid−123」に対してキー「15」を生成し、「tid−123」と「15」とを有するレコードＡをアプリメソッド分類テーブル２４に生成する。その後、情報生成部３０ｂは、App−key「123」からApp−key「127」のログメッセージ各々の「timestamp」を比較して、先頭ログメッセージのApp−keyが「123」、末尾ログメッセージのApp−keyが「127」であると特定する。そして、情報生成部３０ｂは、特定した先頭のApp−key「123」をレコードＡの「先頭メッセージ」に格納して、特定した末尾のApp−key「127」をレコードＡの「末尾メッセージ」に格納する。情報生成部３０ｂは、このような処理を実行することで、TranIDごとに、アプリログテーブル２２に保持されるメッセージを分類する。分類後、情報生成部３０ｂは、各TranID「tid−123」の「次の時間順レコード」としてキー「18」を格納し、「前の時間順レコード」としてキー「14」を格納する。

次に、情報生成部３０ｂが実行するＤＢ分類テーブル２５の作成例について説明する。例えば、情報生成部３０ｂは、ＤＢキャプチャテーブル２３に記憶される「コネクションキー」のうち、最も時間が早い「コネクションキー」を１つ選択し、選択した「コネクションキー」を有するキャプチャメッセージを抽出する。そして、情報生成部３０ｂは、選択した「コネクションキー」を有する情報を格納するレコードをＤＢ分類テーブル２５に生成する。その後、情報生成部３０ｂは、抽出したキャプチャメッセージの「timestamp」にしたがって、キャプチャメッセージを並び替える。

続いて、情報生成部３０ｂは、抽出したキャプチャメッセージの中から、最も「timestamp」が早いキャプチャメッセージの「DB−key」を、生成したレコードの「先頭メッセージ」に格納する。同様に、情報生成部３０ｂは、抽出したキャプチャメッセージの中から、最も「timestamp」が遅いキャプチャメッセージの「DB−key」を特定し、生成したレコードの「末尾メッセージ」に書き込む。さらに、情報生成部３０ｂは、最も遅い「timestamp」の値をＤＢ分類テーブル２５のレコードの「最終更新時刻」に格納する。このようにして、情報生成部３０ｂは、ＤＢキャプチャテーブル２３に記憶されるキャプチャメッセージを「コネクションキー」ごとに分類して、分類した結果をＤＢ分類テーブル２５に格納する。また、情報生成部３０ｂは、トランザクションＩＤテーブル２６を参照して、ＤＢ分類テーブル２５の「先頭メッセージ」から「末尾メッセージ」の間に出現した先頭の「TranID情報」と最後の「TranID情報」を特定する。そして、情報生成部３０ｂは、ＤＢ分類テーブル２５の「先頭TranID情報」と「末尾TranID情報」のそれぞれに、特定した先頭の「TranID情報」と最後の「TranID情報」を格納する。

一例を挙げると、情報生成部３０ｂは、ＤＢキャプチャテーブル２３からコネクションキー「38」を特定し、コネクションキー「38」を保持するキャプチャメッセージとして、DB−key「132」からDB−key「144」までのキャプチャメッセージを抽出する。そして、情報生成部３０ｂは、コネクションキー「38」に対するレコードＤをＤＢ分類テーブル２５に生成する。その後、情報生成部３０ｂは、DB−key「132」からDB−key「144」までのキャプチャメッセージ各々の「timestamp」を比較して、先頭キャプチャメッセージのDB−keyが「132」、末尾キャプチャメッセージのDB−keyが「144」であることを特定する。そして、情報生成部３０ｂは、特定した先頭のDB−key「132」をレコードＤの「先頭メッセージ」に格納して、特定した末尾のDB−key「144」をレコードＤの「末尾メッセージ」に格納する。情報生成部３０ｂは、このような処理を実行することで、コネクションキーごとに、ＤＢキャプチャテーブル２３に保持されるメッセージを分類する。分類後、情報生成部３０ｂは、トランザクションＩＤテーブル２６を参照して、コネクションキー「38」のログメッセージ群で最初に出現したTranIDの「TranID情報」に「512」を格納し、最後に出現したTranIDの「TranID情報」に「517」を格納する。

次に、情報生成部３０ｂが実行するトランザクションＩＤテーブル２６の作成例について説明する。例えば、情報生成部３０ｂは、ＤＢキャプチャテーブル２３から「TranID」を保持するキャプチャメッセージの「DB−key」を特定する。続いて、情報生成部３０ｂは、特定した「DB−key」を有するキャプチャメッセージの「timestamp」を特定するとともに、「DB−key」を有する「コネクションキー」を特定する。そして、情報生成部３０ｂは、特定した「TranID」、「DB−key」、「コネクションキー」に対して「TranID情報」を生成して、これらと「TranID情報」とを対応付けたレコードをトランザクションＩＤテーブル２６に生成する。また、情報生成部３０ｂは、特定した「DB−key」を有するログメッセージの「timestamp」に基づいて、時間順序を特定して「次のTranID情報」を格納する。

一例を挙げると、情報生成部３０ｂは、「tid−123」を保持するDB−key「133」のキャプチャメッセージをＤＢキャプチャテーブル２３から特定する。そして、情報構成部３０ｂは、このメッセージのDB−key「133」をキーにしてＤＢ分類テーブル２５から、コネクションキー「38」を特定する。その後、情報生成部３０ｂは、「tid−123」、DB−key「133」、コネクションキー「38」にTranID情報「512」を付与して、これらを対応付けたレコードをトランザクションＩＤテーブル２６に生成する。そして、情報生成部３０ｂは、トランザクションＩＤテーブル２６にレコードが作成されると、「ＤＢ分類表情報」が同じであるレコードを時間順序で並び替えて、「次のTranID情報」を特定して格納する。

図６に戻り、学習部３１は、特定部３１ａと抽出部３１ｂと格納制御部３１ｃとを有し、これらによってTranIDを有するメッセージの出現位置を学習する。特定部３１ａは、アプリログテーブル２２に記憶されるログメッセージから、アプリケーションサーバ１０がＤＢサーバにリクエストを発行した時刻である開始時刻と、当該リクエストに対するレスポンスを受信した時刻である終了時刻とを特定する。

例えば、特定部３１ａは、アプリメソッド分類テーブル２４から１つのレコードを選択し、当該レコードの先頭メッセージの「App−key」と末尾メッセージの「App−key」とを特定する。そして、特定部３１ａは、アプリログテーブル２２を参照して、特定した先頭メッセージから末尾メッセージまでのログメッセージのうち、「Create〜」、「Update〜」、「delete〜」などテーブル操作を示すメソッドを特定する。そして、特定部３１ａは、特定したメソッドの「開始」を示すログメッセージの「timestamp」を開始時刻、特定したメソッドの「終了」を示すログメッセージの「timestamp」を終了時刻として、抽出部３１ｂに出力する。また、特定部３１ａは、アプリメソッド分類テーブル２４から選択したレコードが保持する「TranID」などについても抽出部３１ｂに出力する。

一例として図７〜図９を用いて説明すると、特定部３１ａは、図９に示した情報からTranID「tid−123」の先頭メッセージがApp−Key「123」であり、末尾メッセージがApp−Key「127」であると特定する。続いて、特定部３１ａは、アプリログテーブル２２を参照して、App−Key「123」から「127」までのログメッセージのうち「createQuery」の「開始」メッセージのApp−Keyが「123」であり、「終了」メッセージのApp−Keyが「124」であることを特定する。その後、特定部３１ａは、App−Keyが「123」であるログメッセージの「timestamp」を開始時刻、App−Keyが「123」であるログメッセージの「timestamp」を終了時刻として抽出部３１ｂに出力するとともに、「tid−123」を抽出部３１ｂに出力する。

抽出部３１ｂは、ＤＢ分類テーブル２５に記憶されるキャプチャメッセージから、特定部３１ａによって特定された開始時刻から終了時刻までに送受信されたキャプチャメッセージを抽出する。例えば、抽出部３１ｂは、特定部３１ａが特定した「TranID」を検索キーにしてトランザクションＩＤテーブル２６を検索し、「TranID」に対応付けられた「コネクションキー」を特定する。その後、抽出部３１ｂは、特定した「コネクションキー」で出力されたキャプチャメッセージをＤＢ分類テーブル２５から特定し、特定したキャプチャメッセージのうち、上記開始時刻から終了時刻までの出現したキャプチャメッセージを抽出する。

上述した例で説明すると、抽出部３１ｂは、図１１に示した情報から、「tid−123」に対応付けられたコネクションキー「38」を特定する。続いて、抽出部３１ｂは、コネクションキー「38」に対応付けられた先頭メッセージ「132」から末尾メッセージ「144」と、特定した「132」から「144」までの各メッセージの「timestamp」を、図８に示したＤＢキャプチャテーブル２５から特定する。このうち、抽出部３１ｂは、抽出部３１ｂから通知された開始時刻と終了時刻の間に収まる、「132」から「135」までのキャプチャメッセージを抽出する。

格納制御部３１ｃは、抽出部３１ｂによって抽出されたキャプチャメッセージにおいて、TranIDを有するキャプチャメッセージの出現パターンを特定して学習テーブル２７に格納する。例えば、格納制御部３１ｃは、抽出部３１ｂが抽出したキャプチャメッセージの総数を「全メッセージ数」として決定する。また、格納制御部３１ｃは、特定部３１ａから通知される「TranID」を保持するキャプチャメッセージの「DB−key」をトランザクションＩＤテーブル２６から特定する。そして、格納制御部３１ｃは、抽出部３１ｂが抽出したキャプチャメッセージのうち、「TranID」を有するキャプチャメッセージが何番目に出現するかを特定する。そして、格納制御部３１ｃは、「TranID」、先メッセージ数、全メッセージ数に対応付けて、特定部３１ａが特定したメソッドの種別を学習テーブル２７に格納する。このとき、例えば、格納制御部３１ｃは、当該メソッドの種別の学習回数が所定回以上や、コネクション内にTranIDが１つしかない状態で実行したか否かによって信頼度を決定して格納する。

上述した例で説明すると、格納制御部３１ｃは、抽出部３１ｂが抽出した「132」から「135」までの「4」つを「全メッセージ数」と決定する。また、格納制御部３１ｃは、「tid−123」を保持するキャプチャメッセージのDB−key「133」を、図８に示したＤＢキャプチャテーブル２３または図１１に示したトランザクションＩＤテーブル２６から特定する。そして、格納制御部３１ｃは、抽出されたDB−key「132」から「135」のうち、「133」が２番目であると検出する。また、特定部３１ａが特定した「createQuery」の「Create」を「種別」に決定する。その後、格納制御部３１ｃは、「全メッセージ数」＝「4」、先メッセージ数＝「1」、「種別」＝「Create」を対応付けて学習テーブル２７に格納する。なお、格納制御部３１ｃは、コネクション内の多重度が１つであるため、「信頼度」＝「5」としてもよい。

図６に戻り、分類部３２は、学習テーブル２７に記憶されるメッセージの出現パターンに基づいて、ＤＢ分類テーブル２５に記憶されているメッセージをトランザクションごとに分類する。上述した各図等を例にして説明すると、分類部３２は、図１０に示したＤＢ分類テーブル２５からコネクションキー「38」のレコードを選択し、当該コネクションで発生したメッセージのDB−keyが「132」から「144」までであることを特定する。

続いて、分類部３２は、コネクションキー「38」を検索キーにして、図１１に示したトランザクションＩＤテーブル２６を検索し、TranID「tid−123」がDB−key「133」に関連して出現していることを特定する。また、分類部３２は、TranID「tid−123」に対応するメソッド名が「CreateQuery」であることを、図７に示したアプリログテーブル２２から特定する。この結果、分類部３２は、TranID「tid−123」の種別を「Create」と特定する。

その後、分類部３２は、「Create」を検索キーにして図１２に示した学習テーブル２７を検索し、全メッセージ数が「4」、先メッセージ数が「1」を特定する。つまり、分類部３２は、TranIDを有するメッセージが2番目に出現することを特定する。このとき、分類部３２は、「Create」に対応する情報が複数ある場合には、最も信頼度が高い情報を用いるようにしてもよい。

そして、分類部３２は、ＤＢ分類テーブル２５のコネクションキー「38」で出現したメッセージのうち、「133」が2番目になることから、DB−key「133」を基準に「132」から「134」まで、TranID「tid−123」で実現したメッセージであると特定する。その後、分類部３２は、上述したTranID「tid−123」、コネクションキー「38」、実際に検出できたメッセージ数＝「4」、先頭メッセージのDB−key「132」、末尾メッセージのDB−key「134」を対応付けてメッセージ分類テーブル２８に格納する。また、分類部３２は、DB−key「132」から「134」まで処理時間を、図８に示したＤＢキャプチャテーブル２３の「timestamp」から特定して、メッセージ分類テーブル２８に格納する。

このとき、分類部３２は、ＤＢ分類テーブル２５のコネクションキー「38」で出現したメッセージのうち、DB−key「133」を基準にした場合に、「132」から「133」までの2メッセージしか存在しなかったとする。その場合、分類部３２は、学習済みデータの全メッセージ数が「4」であるにも関らず、「2」つしか検出できなかったので、「結果」に「異常」を格納する。このような異常状態でない場合には、分類部３２は、「結果」に「正常」を格納する。なお、異常が格納された場合には、分類部３２は、当該学習テーブルの信頼度を下げてもよい。

図６に戻り、結果処理部３３は、メッセージ分類結果に応じて警告等を報知する。例えば、結果処理部３３は、メッセージ分類テーブル２８を参照し、「結果」フィールドに「異常」が格納されている場合には、メッセージ分類結果が異常であると判定する。そして、結果処理部３３は、「異常」に対応付けられたTranIDをディスプレイに表示したり、メールでカスタマーエンジニア（ＣＥ）に報知する。また、結果処理部３３は、メッセージ分類テーブル２８を参照し、処理時間が所定値以上であるTranIDについても、異常が発生したトランザクションであると判定して、報知処理を実行する。

［具体例］
次に、図１４と図１５を用いて、メッセージ出現パターンの学習例およびメッセージ分類例について説明する。図１４は、アプリメソッド分類テーブルで表されるログメッセージの関係例を示す図であり、図１５は、ＤＢ分類テーブルで表されるキャプチャメッセージの関係例を示す図である。

学習部３１の特定部３１ａは、アプリメソッド分類テーブル２４を参照することで、図１４に示すようなアプリケーションサーバ１０で発生したログメッセージの関係性を特定する。具体的には、図１４に示すように、特定部３１ａは、キー「15」が与えられたTranID「tid−123」を保持するログメッセージ群が、App−key「123」のログメッセージからApp−key「127」のログメッセージで形成されることを特定する。同様に、特定部３１ａは、TranID「tid−123」に続くメッセージ群として、キー「18」が与えられたTranID「tid−127」を保持するログメッセージ群が、App−key「185」のログメッセージからApp−key「201」のログメッセージで形成されることを特定する。

特定部３１ａは、App−key「123」のログメッセージからApp−key「127」のログメッセージ各々の「メソッド名」をアプリログテーブル２２から特定する。そして、特定部３１ａは、図１４に示すように、ＤＢアクセスを実行した際のログメッセージの「timestamp」を開始時刻（ｔ０）、ＤＢアクセスが終了した際のログメッセージの「timestamp」を終了時刻（ｔ１）として抽出部３１ｂに通知する。なお、特定部３１ａは、アプリログテーブル２２の「開始／終了」フィールドからＤＢアクセスを開始した際のメソッドと、終了した際のメソッドとを特定できる。

抽出部３１ｂは、ＤＢ分類テーブル２５を参照することで、図１５に示すようなアプリケーションサーバ２とＤＢサーバ３間で発生したキャプチャメッセージの関係性を特定する。具体的には、図１５に示すように、抽出部３１ｂは、コネクションキー「38」内で発生したキャプチャメッセージ群が、DB−key「132」のメッセージからDB−key「157」のメッセージで形成されることを特定する。同様に、抽出部３１ｂは、コネクションキー「40」内で発生したキャプチャメッセージ群が、DB−key「200」のメッセージからDB−key「203」のメッセージで形成されることを特定する。

抽出部３１ｂは、コネクションキー「38」内の各キャプチャメッセージの「Timestamp」をＤＢキャプチャテーブル２３から特定する。そして、抽出部３１ｂは、図１５に示すように、特定部３１ａから通知された開始時刻（ｔ０）と終了時刻（ｔ１）の間で発生したメッセージとして、DB−key「132」のメッセージからDB−key「138」のメッセージを抽出する。

格納制御部３１ｃは、トランザクションＩＤテーブル２６の「TranID」と「メッセージ」とを参照し、TranID「tid−123」がDB−key「133」に付加されることを特定する。そして、格納制御部３１ｃは、図１５に示すように、抽出部３１ｂによって抽出されたDB−key「132」のメッセージからDB−key「138」のメッセージのうち、TranID「tid−123」が付加されたメッセージの順番が2番目であることを特定する。また、格納制御部３１ｃは、TranID「tid−123」に対応する「メソッド名」をアプリログテーブル２２から特定し、TranID「tid−123」のメソッド名から「種別＝create」を特定する。こうして、格納制御部３１ｃは、「種別＝create」、「先メッセージ数＝1」、「全メッセージ数＝4」を学習テーブル２７に格納する。このようにして、格納制御部３１ｃは、トランザクション「種別」ごとにトランザクション識別子の出現パターンを学習できる。

次に、学習結果を用いてメッセージを分類する例について説明する。なお、ここでは、説明上、学習テーブルが記憶する「種別」と「信頼度」については除外して説明する。例えば、学習テーブル２７が「先メッセージ数、全メッセージ数」として「0、2」を記憶しており、トランザクションＩＤテーブル２６が「TranID、メッセージ」として「tid−100、202」を記憶しているものとする。また、ＤＢ分類テーブル２５が記憶するキャプチャメッセージは、図１５に示す通りとする。

この場合、分類部３２は、「tid−100」を保持するDB−key「202」のメッセージが2つのメッセージの先頭に付加されていることを認識する。したがって、分類部３２は、図１５に示すように、コネクションキー「40」内で発生したキャプチャメッセージ群のうち、DB−key「202」のメッセージを基準に、DB−key「202」とDB−key「203」のメッセージを切り出す。すなわち、分類部３２は、トランザクション「tid−100」で発生したＤＢメッセージがDB−key「202」とDB−key「203」のメッセージであると特定する。

［処理の流れ］
次に、図１６から図１８を用いて、各装置が実行する処理の流れについて説明する。ここでは、アプリケーションサーバ１０が実行する処理の流れ、紐付けサーバ２０が実行する処理の流れについて説明する。

（アプリケーションサーバ１０が実行する処理の流れ）
図１６は、アプリケーションサーバが実行する処理の流れを示すフローチャートである。図１６に示すように、アプリケーションサーバ１０のＩＤ生成部１７ｂは、アプリ実行部１７ａによるアプリのメソッドの呼び出しを検出すると（Ｓ１０１肯定）、呼び出しをフックする（Ｓ１０２）。そして、ＩＤ生成部１７ｂは、当該メソッドが新規スレッドつまりＩＤ情報テーブル１３に記憶されているか否かを判定する（Ｓ１０３）。

続いて、ＩＤ生成部１７ｂは、当該メソッドが新規スレッドである場合（Ｓ１０３肯定）、一意なTranIDを生成し（Ｓ１０４）、ロギング対象テーブル１４を参照して、当該メソッドがロギング対象であるか否かを判定する（Ｓ１０５）。

そして、ＩＤ付加部１７ｃは、当該メソッドがロギング対象である場合（Ｓ１０５肯定）、ＤＢ命令置換対象テーブル１５を参照して、当該メソッドがＤＢ置換対象であるか否かを判定する（Ｓ１０６）。

続いて、ＩＤ付加部１７ｃは、当該メソッドがＤＢ置換対象である場合（Ｓ１０６肯定）、当該メソッドのＤＢ命令を置換して呼び出し情報にTranIDを埋め込む（Ｓ１０７）。一方、ＩＤ付加部１７ｃは、当該メソッドがＤＢ置換対象でない場合（Ｓ１０６否定）、当該メソッドにTranIDを付加する（Ｓ１０８）。

その後、ＩＤ付加部１７ｃは、開始ログをログテーブル１６に格納して（Ｓ１０９）、メソッドを呼び出して実行し（Ｓ１１０）、メソッドが終了すると、終了ログをログテーブル１６に格納する（Ｓ１１１）。

また、Ｓ１０３において、当該メソッドが新規スレッドでない場合（Ｓ１０３否定）、ＩＤ付加部１７ｃは、当該メソッドに対して既に生成されているTranIDをＩＤ情報テーブル１３から取得して付与し（Ｓ１１２）、Ｓ１０９以降の処理を実行する。なお、Ｓ１０５において、ＩＤ付加部１７ｃは、当該メソッドがロギング対象でないと判定した場合（Ｓ１０５否定）、処理を終了する。

（紐付けサーバ２０が実行する紐付け処理の流れ）
図１７は、紐付けサーバが実行する紐付け処理の流れを示すフローチャートである。図１７に示すように、紐付けサーバ２０の情報取得部３０ａは、各サーバまたはネットワーク内からログメッセージやキャプチャメッセージを取得すると（Ｓ２０１肯定）、取得したメッセージのヘッダー等から種別を特定して各テーブルに振り分ける（Ｓ２０２）。

その後、情報生成部３０ｂは、アプリログテーブル２２内に新たなトランザクションの完了を示すメッセージが存在することを検出する（Ｓ２０３肯定）。すると、情報生成部３０ｂは、アプリログテーブル２２やＤＢキャプチャテーブル２３などに記憶される情報から各種情報を生成して、アプリメソッド分類テーブル２４、ＤＢ分類テーブル２５、トランザクションＩＤテーブル２６に格納する（Ｓ２０４）。

そして、分類部３２は、ＤＢ分類テーブル２５に未処理のコネクションが存在することを検出すると（Ｓ２０５肯定）、コネクションを１つ選択する（Ｓ２０６）。続いて、分類部３２は、トランザクションＩＤテーブル２６等からTranIDを有するメッセージを特定するとともに（Ｓ２０７）、特定したメッセージのTranIDに対応する学習情報を学習テーブル２７から取得する（Ｓ２０８）。

そして、分類部３２は、特定したメッセージのTranIDのメッセージ出現パターンが学習テーブル２７に格納されており、学習済みである場合には（Ｓ２０９肯定）、学習結果を用いて、Ｓ２０６で選択されたコネクション内のメッセージを分類する（Ｓ２１０）。その後、分類部３２は、Ｓ２０５に戻って以降の処理を実行する。

一方、分類部３２は、特定したメッセージのTranIDのメッセージ出現パターンが学習テーブル２７に格納されておらず、未学習である場合には（Ｓ２０９否定）、学習処理を実行する（Ｓ２１１）。そして、分類部３２は、学習処理後の学習結果を用いて、Ｓ２０６で選択されたコネクション内のメッセージを分類する（Ｓ２０９とＳ２１０）。その後、分類部３２は、Ｓ２０５に戻って以降の処理を実行する。

また、Ｓ２０５において、分類部３２は、ＤＢ分類テーブル２５に未処理のコネクションが存在しないことを検出すると（Ｓ２０５否定）、処理を終了する。

（紐付けサーバ２０が実行する学習処理の流れ）
図１８は、紐付けサーバが実行する学習処理の流れを示すフローチャートである。図１８に示すように、学習部３１の特定部３１ａは、処理開始契機に到達すると（Ｓ３０１肯定）、アプリログテーブル２２を参照して、ＤＢアクセスの開始時刻と終了時刻とを特定する（Ｓ３０２）。

続いて、抽出部３１ｂは、特定された開始時刻から終了時刻までに発生したメッセージをＤＢ分類テーブル２５から特定する（Ｓ３０３）。そして、格納制御部３１ｃは、特定したメッセージのうち、TranIDを保持するメッセージが存在する場合には（Ｓ３０４肯定）、TranIDの出現パターンすなわち全体のうち何番目に出現しているかを特定する（Ｓ３０５）。

その後、格納制御部３１ｃは、TranIDを保持するメッセージの出現パターンを学習テーブル２７に格納する（Ｓ３０６）。このとき、格納制御部３１ｃは、トランザクションおよび種別、Ｓ３０５で特定された全メッセージ数、信頼度なども格納する。

そして、格納制御部３１ｃは、他のTranIDを保持するメッセージが存在する場合には（Ｓ３０７肯定）、Ｓ３０５〜Ｓ３０６を繰り返す。また、格納制御部３１ｃは、アプリログテーブル２２も未処理のメッセージが存在する場合には（Ｓ３０８肯定）、Ｓ３０２以降の処理を繰り返す。そして、格納制御部３１ｃは、他のTranIDを保持するメッセージが存在せず（Ｓ３０７否定）、アプリログテーブル２２も未処理のメッセージが存在しない場合には（Ｓ３０８否定）、処理を終了する。また、格納制御部３１ｃは、ステップＳ３０４においてTranIDを保持するメッセージが存在しないと判定された場合には（Ｓ３０４否定）、処理を終了する。

［実施例２による効果］
実施例２に係る紐付けサーバ２０は、Ｗｅｂアプリケーションへの処理要求から始まる一連のトランザクションを、ＤＢアクセスに至るまで全て関連付ける事ができる。これにより、処理経路上の所要時間がアプリ本体から外部の通信に至るまでトランザクション毎に計測できるので、システム性能の監視やボトルネックの検出などを効率よく実施することができる。特に、これまで関連付けることが難しかった、ＤＢアクセスの通信メッセージを関連付けて処理する事ができる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

（サーバへの適用例）
上述した実施例では、アプリケーションサーバが実行したトランザクションと、アプリケーションサーバとＤＢサーバとの間で発生したメッセージとを関連付ける例を説明したが、これに限定されるものではない。例えば、ＤＢサーバのように、アプリケーションサーバからトランザクションから実行された場合に、トランザクションの一部であるものの、リクエスト等とは関係のないメッセージを発生させるサーバについても同様に適用できる。

（信頼度）
例えば、紐付けサーバは、学習結果の信頼度を高める手法として、アプリケーションサーバとＤＢサーバとのコネクション内で１つのトランザクションが実行された場合のキャプチャメッセージ及びログメッセージから学習するようにしてもよい。この場合、複数のトランザクションが実行されている場合に比べて、トランザクションとキャプチャメッセージとの関連度が強い。このため、紐付けサーバは、関連度の強い情報から学習することができるので、学習結果の信頼度を高めることができる。また、学習するタイミングは、任意のタイミングで実行でき、また、アプリログメッセージが所定値以上たまった場合に実行してもよい。

（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、例えば図３〜図５、図７〜図１３等に示した各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

例えば、紐付けサーバ２０が、アプリケーションサーバ１０のＩＤ生成部１７ｂやＩＤ付加部１７ｃを有していてもよい。また、アプリケーションサーバ１０が、紐付けサーバ２０の各制御部や各テーブルを有していてもよい。

（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。

図１９は、メッセージ切分けプログラムを実行するコンピュータのハードウェア構成例を示す図である。図１９に示すように、コンピュータシステム１００は、バス１０１に、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、ＨＤＤ（Hard Disk Drive）１０６、ＲＡＭ（Random Access Memory）１０７が接続される。

入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０６は、メッセージ切分けプログラム１０６ａととともに、図６等に示した各テーブル等に記憶される情報を記憶する。記録媒体の例としてＨＤＤ１０６を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。

ＣＰＵ１０２は、メッセージ切分けプログラム１０６ａを読み出してＲＡＭ１０７に展開することで、図６等で説明した各機能を実行するメッセージ切分けプロセス１０７ａを動作させる。すなわち、メッセージ切分けプロセス１０７ａは、図６に記載した情報取得部３０ａ、情報生成部３０ｂ、学習部３１、分類部３２、結果処理部３３と同様の機能を実行する。このようにコンピュータシステム１００は、プログラムを読み出して実行することでメッセージ切分け方法を実行する情報処理装置として動作する。

１０ アプリケーションサーバ
１１ 通信部
１２ アプリテーブル
１３ ＩＤ情報テーブル
１４ ロギング対象テーブル
１５ ＤＢ命令置換対象テーブル
１６ ログテーブル
１７ 制御部
１７ａ アプリ実行部
１７ｂ ＩＤ生成部
１７ｃ ＩＤ付加部
２０ 紐付けサーバ
２１ 通信部
２２ アプリログテーブル
２３ ＤＢキャプチャテーブル
２４ アプリメソッド分類テーブル
２５ ＤＢ分類テーブル
２６ トランザクションＩＤテーブル
２７ 学習テーブル
２８ メッセージ分類テーブル
３０ 制御部
３０ａ 情報取得部
３０ｂ 情報生成部
３１ 学習部
３１ａ 特定部
３１ｂ 抽出部
３１ｃ 格納制御部
３２ 分類部
３３ 結果処理部

Claims (5)

1. トランザクションを識別するトランザクション識別子を有するメッセージと前記トランザクション識別子を有さないメッセージとを含むメッセージ群における前記トランザクション識別子を有するメッセージの出現位置を記憶する第１記憶部と、
   第１のサーバによって前記トランザクション識別子を有するトランザクションが第２のサーバに実行され、前記第１のサーバと前記第２のサーバとの間で発生したメッセージを記憶する第２記憶部と、
   前記第１記憶部に記憶されるメッセージの出現位置に基づいて、前記第２記憶部に記憶されているメッセージを前記トランザクションごとに分類する分類部と
   を有することを特徴とする情報処理装置。
2. 前記トランザクション識別子ごとに、前記第１のサーバが前記トランザクションを実行した際に発生させたメッセージを記憶する第３記憶部と、
   前記第３記憶部に記憶されるメッセージから、前記第１のサーバが前記第２のサーバにリクエストを発行した時刻である開始時刻と、当該リクエストに対するレスポンスを受信した時刻である終了時刻とを特定する特定部と、
   前記第２記憶部に記憶されるメッセージから、前記特定部によって特定された開始時刻から終了時刻までに送受信されたメッセージを抽出する抽出部と、
   前記抽出部によって抽出されたメッセージから、前記トランザクション識別子を有するメッセージの出現位置を特定して前記第１記憶部に格納する格納制御部と
   をさらに有することを特徴とする請求項１に記載の情報処理装置。
3. 前記抽出部は、前記第２記憶部が記憶するメッセージのうち、前記第１のサーバと前記第２のサーバとのコネクション内で１つのリクエストが処理された場合のメッセージから、前記開始時刻と前記終了時刻とを抽出することを特徴とする請求項２に記載の情報処理装置。
4. コンピュータ実行する制御方法であって、
   トランザクションを識別するトランザクション識別子を有するメッセージと前記トランザクション識別子を有さないメッセージとを含むメッセージ群における前記トランザクション識別子を有するメッセージの出現位置を第１記憶部に格納し、
   第１のサーバによって前記トランザクション識別子を有するトランザクションが第２のサーバに実行され、前記第１のサーバと前記第２のサーバとの間で発生したメッセージを第２記憶部に格納し、
   前記第１記憶部に記憶されるメッセージの出現位置に基づいて、前記第２記憶部に記憶されているメッセージを前記トランザクションごとに分類する
   こと含んだことを特徴とするメッセージ切分け方法。
5. コンピュータに、
   トランザクションを識別するトランザクション識別子を有するメッセージと前記トランザクション識別子を有さないメッセージとを含むメッセージ群における前記トランザクション識別子を有するメッセージの出現位置を第１記憶部に格納し、
   第１のサーバによって前記トランザクション識別子を有するトランザクションが第２のサーバに実行され、前記第１のサーバと前記第２のサーバとの間で発生したメッセージを第２記憶部に格納し、
   前記第１記憶部に記憶されるメッセージの出現位置に基づいて、前記第２記憶部に記憶されているメッセージを前記トランザクションごとに分類する
   処理を実行させることを特徴とするメッセージ切分けプログラム。

Images