分析プログラム、分析方法及び分析装置
【課題】システムのサービス提供機能に手を加えずにトランザクションを分析できるようにする。
【解決手段】メッセージ観測手段１ａは、ネットワーク２を介して受け渡されるメッセージ５を収集する。するとメッセージ解析手段１ｂにより、収集したメッセージ５の内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別される。判別された情報はプロトコルログ記憶手段１ｃに格納される。その後、モデル生成手段１ｄにより、処理間の呼出関係に基づきトランザクションモデルが生成される。
【解決手段】メッセージ観測手段１ａは、ネットワーク２を介して受け渡されるメッセージ５を収集する。するとメッセージ解析手段１ｂにより、収集したメッセージ５の内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別される。判別された情報はプロトコルログ記憶手段１ｃに格納される。その後、モデル生成手段１ｄにより、処理間の呼出関係に基づきトランザクションモデルが生成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はトランザクションを分析するための分析プログラム、分析方法及び分析装置に関する。
【背景技術】
【０００２】
最近のＩＴ（情報通信技術）を利用したコンピュータシステムは大規模かつ複雑な構成であることが多い。例えば、オンラインバンキングの入金や振込み処理など、各種業務サービスがＷｅｂサーバ／アプリケーションサーバ／データベース（ＤＢ）サーバからなるＷｅｂ３階層システムにて提供される例が増えている。こういったシステムは、業務の効率化やセキュリティ対策などの理由から大規模で複雑な構成である。また、即時性を要求される業務サービスが多く、サービス停止やレスポンス悪化は大きな問題である。そのため、大規模システムに対する運用状況の詳細な把握や性能問題の迅速な解決が必須である。
【０００３】
しかも、複数のアプリケーションが連携して動作する複雑なシステム（Ｗｅｂ３階層システムなど）で、性能劣化や障害の原因を突き止めるためには、サーバそれぞれの挙動だけでなくシステム全体としての性能を観測・分析することが必要である。例えば、Ｗｅｂ３階層システムにおいては、Ｗｅｂサーバへの処理要求に伴ってアプリケーションサーバへの処理要求が発生する場合がある。アプリケーションサーバ・ＤＢサーバ間についても同様である。こういったアプリケーション間における処理の呼出関係は、性能問題のシステム内への波及を調べる上で必須である。
【０００４】
そこで、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡する機能が望まれている。このような追跡が可能となれば、システムに存在する問題の分析が容易となる。
【０００５】
サーバ間の処理の受け渡しを追跡する技術としては、例えば、各サーバにエージェントを実装し、そのエージェントに個々のサーバの運用状況を解析及びレポートさせる技術がある（例えば、非特許文献１参照）。
【０００６】
エージェントによって運用状態を把握し、その結果をレポートする技術は実用化されている（例えば、非特許文献２，３参照）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Technical Standard Application Response Measurement(ARM) Issue4.0-C Binding」THE OPEN GROUP、２００３年１０月、Figure 2
【非特許文献２】「IBM Tivoli Monitoring for Transaction Performance helps maximize performance of your applications.」,"IBM Corporation Software Group",２００３年９月
【非特許文献３】「IBM Tivoli Monitoring for Transaction Performance, Version 5.2」,"IBM Corporation Software Group"、２００３年９月
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来の技術では、アプリケーション単位の詳細な情報を取得する場合には、各サーバに対してエージェント等の何らかのアプリケーションを組み込んで対応する必要がある。そのため、既存システムの性能分析が困難である。特に最近のシステムでは、アプリケーション毎に異なる企業によって作成されている。従って、全てのアプリケーションについて、エージェントとの間の情報の受け渡しを行うように改良することは困難である。
【０００９】
本発明はこのような点に鑑みてなされたものであり、システムのサービス提供機能に手を加えずにトランザクションを分析できる分析プログラム、分析方法及び分析装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明では上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、コンピュータに、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、を実行させるための分析プログラムが提供される。
【００１１】
また、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、を有する分析装置が提供される。
【００１２】
さらに、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、コンピュータが、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、分析方法が提供される。
【発明の効果】
【００１３】
本発明では、メッセージ集合からのトランザクションモデルの生成が可能となる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態に適用される発明の概念図である。
【図２】第１の実施の形態に係るシステム構成を示す図である。
【図３】システム分析装置のハードウェア構成例を示す図である。
【図４】システム分析装置の機能ブロックを示す図である。
【図５】システム分析処理の手順を示すフローチャートである。
【図６】メッセージ観測状況を示す概念図である。
【図７】パケットデータ記憶部のデータ構造例を示す図である。
【図８】パケットに含まれる情報を示す図である。
【図９】ＩＰヘッダの詳細を示す図である。
【図１０】ＴＣＰヘッダの詳細を示す図である。
【図１１】メッセージ解析部の機能を示すブロック図である。
【図１２】再構成したセッションの例である。
【図１３】メッセージ再構成例を示す第１の図である。
【図１４】リクエストへのレスポンスメッセージの対応付けの例を示す図である。
【図１５】オブジェクト名の割り当て例を示す図である。
【図１６】１つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。
【図１７】プロトコルログの例を示す図である。
【図１８】プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。
【図１９】トランザクションモデル生成処理を示すフローチャートである。
【図２０】選択されるモデル生成用メッセージを示す図である。
【図２１】「残高確認」トランザクションのモデル生成例を示す図である。
【図２２】「入金」トランザクションのモデル生成例を示す図である。
【図２３】分析処理の手順を示すフローチャートである。
【図２４】分析部へ入力されるメッセージの例を示す図である。
【図２５】メッセージ分析例を示す第１の図である。
【図２６】メッセージ分析例を示す第２の図である。
【図２７】メッセージ分析例を示す第３の図である。
【図２８】メッセージ分析例を示す第４の図である。
【図２９】メッセージ分析例を示す第５の図である。
【図３０】メッセージ分析例を示す第６の図である。
【図３１】メッセージ分析例を示す第７の図である。
【図３２】メッセージ分析例を示す第８の図である。
【図３３】メッセージ分析例を示す第９の図である。
【図３４】メッセージ分析例を示す第１０の図である。
【図３５】サーバの平均処理時間の表示例を示す図である。
【図３６】トランザクション別処理時間及び内訳の表示例を示す図である。
【図３７】処理時間ヒストグラムの表示例を示す図である。
【図３８】複数の情報を同時に表示した場合の画面例を示す図である。
【図３９】表示対象要素間の連携の様子を示す図である。
【図４０】分析部へ入力されるメッセージの例を示す図である。
【図４１】モデル生成部に入力されたメッセージから認識される処理を示す図である。
【図４２】制約を満たす処理間の呼出関係を示す図である。
【図４３】呼出回数行列の例を示す図である。
【図４４】呼び出し候補の確率を求めた結果を示す図である。
【図４５】更新後の呼出回数行列を示す図である。
【図４６】２回目の処理で呼び出し候補の確率を求めた結果を示す図である。
【図４７】２回目の更新後の呼出回数行列を示す図である。
【図４８】最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。
【図４９】第２の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【図５０】処理種別Ａからの呼出パターンとその確率を示す第１の図である。
【図５１】処理種別Ｂからの呼出パターンとその確率を示す第１の図である。
【図５２】処理種別Ａからの呼出パターンとその確率を示す第２の図である。
【図５３】処理種別Ｂからの呼出パターンとその確率を示す第２の図である。
【図５４】モデル生成結果を示す図である。
【図５５】第３の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【００１６】
図１は、実施の形態に適用される発明の概念図である。システム分析装置１は、ネットワーク２を介してクライアント３ａ，３ｂ，・・・やサーバ４ａ，４ｂ，・・・に接続されている。サーバ４ａ，４ｂ，・・・は、クライアント３ａ，３ｂ，・・・からの要求に応じてサービスを提供する。サービスの提供は、複数のサーバ４ａ，４ｂ，・・・によって互いに連携して実行される。このときシステム分析装置１は、ネットワーク２を介して送受信されるメッセージ５を取得し、ネットワーク２の運用形態を分析する。分析を行うために、システム分析装置１は、図１に示す各機能を有している。
【００１７】
メッセージ観測手段１ａは、ネットワーク２を介して受け渡されるメッセージ５を収集する。収集したメッセージ５は、メッセージ解析手段１ｂに渡される。
メッセージ解析手段１ｂは、収集したメッセージの内容を解析して、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージか（メッセージの方向）を判別する。処理種別は、例えば、メッセージに適用されているプロトコルがＨＴＴＰ（HyperText Transfer Protocol）であれば、処理要求で指定されたＵＲＬ（Uniform Resource Locator）によって判別できる。そして、メッセージ解析手段１ｂは、判別された情報をプロトコルログとしてプロトコルログ記憶手段１ｃに格納する。
【００１８】
モデル生成手段１ｄは、モデル生成指示が入力されると、プロトコルログ記憶手段１ｃに格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を認識する。そして、モデル生成手段１ｄは、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成する。モデル生成手段１ｄは、生成したトランザクションモデルをトランザクションモデル記憶手段１ｅに格納する。
【００１９】
なお、選択基準としては、例えば、処理時間帯が他のトランザクションと重複しない非多重トランザクションの時間帯内のメッセージの集合を選択することが定められる。また、制約条件は、例えば、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件である。
【００２０】
分析手段１ｆは、分析指示が入力されると、トランザクションモデル記憶手段１ｅに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログをプロトコルログ記憶手段１ｃから抽出し、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する。例えば、トランザクション内での各サーバでの処理時間が分析される。
【００２１】
出力手段１ｇは、分析手段１ｆによる分析結果を、グラフ等の視覚的に認識しやすい統計情報としてモニタ等に出力する。
このようなシステム分析装置１であれば、メッセージ観測手段１ａにより、ネットワーク２を介して受け渡されるメッセージ５が収集される。すると、メッセージ解析手段１ｂにより、収集したメッセージの内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別され、判別された情報がプロトコルログとしてプロトコルログ記憶手段１ｃに格納される。
【００２２】
このとき、モデル生成指示が入力されると、モデル生成手段１ｄにより、プロトコルログ記憶手段に格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理が認識される。そして、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、制約条件を満たすトランザクションモデルが生成される。そして、生成されたトランザクションモデルがトランザクションモデル記憶手段１ｅに格納される。
【００２３】
また、分析指示が入力されると、分析手段１ｆにより、トランザクションモデル記憶手段１ｅに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログがプロトコルログ記憶手段１ｃから抽出され、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態が分析される。分析結果は、出力手段１ｇによって出力され、ユーザに対して提示される。
【００２４】
このように、ネットワーク２を介して受け渡されるメッセージ５から、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合からトランザクションモデルを生成するようにした。すなわち、処理間の呼出関係として生起確率が高い関係を選択し、その関係によって成立するトランザクションをモデル化している。このようにして生成したトランザクションモデルと合致するメッセージをプロトコルログから検出することで、サーバ４ａ，４ｂに対して機能追加を行わずに、共通のトランザクションを構成するメッセージ集合を特定し、処理状態の解析が可能となる。
【００２５】
以下、本発明の実施の形態について詳細に説明する。
［第１の実施の形態］
第１の実施の形態では、インターネットバンキングの業務サービスを提供するＷｅｂ３階層システムにおいて、「残高確認」と「入金」との２つのサービスを提供する場合の例である。
【００２６】
なお、第１の実施の形態では、管理対象となる要素として「セッション」、「メッセージ」、「オブジェクト」、及び「トランザクション」がある。
「セッション」は、送受信側のＩＰ（Internet Protocol）アドレスとポート番号によって定まる通信路上で送受信されるデータの集合である。
【００２７】
「メッセージ」は、ＴＣＰ（Transmission Control Protocol）セッション上で複数の機器がやりとりするデータの最小単位である。例えば、ＨＴＴＰでのリクエストやそれに対するレスポンスが、メッセージに該当する。
【００２８】
「オブジェクト」は、サーバがメッセージを受信してからレスポンスを送信するまでに行う単一又は複数の処理や入力されるデータを仮想的に単一のものとしてまとめたものである。ここで言う処理とは、ＣＰＵ(Central Processing Unit)での計算、データの入出力とそれぞれに対する待ち時間などが含まれる。
【００２９】
「トランザクション」は、システムに対する要求によって発生するオブジェクト処理の集合である。
図２は、第１の実施の形態に係るシステム構成を示す図である。図２の例では、スイッチ１０を介して、クライアント２１，２２，２３、Ｗｅｂサーバ３１、アプリケーションサーバ３２、データベース（ＤＢ）サーバ３３、及びシステム分析装置１００が接続されている。Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３は、クライアント２１，２２，２３からの要求に応じて、サービスを提供する。
【００３０】
サービスを提供する為のトランザクションにおいて、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３間で、スイッチ１０を介してメッセージの送受信が行われる場合がある。このスイッチ１０を介して送受信されるメッセージをシステム分析装置１００が監視することで、システムの動作状態の分析を行うことができる。
【００３１】
図３は、システム分析装置のハードウェア構成例を示す図である。システム分析装置１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ(Random Access Memory)１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。
【００３２】
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
【００３３】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
【００３４】
通信インタフェース１０６は、スイッチ１０に接続されている。通信インタフェース１０６は、スイッチ１０を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、システム分析装置１００のハードウェア構成例を示したが、クライアント２１，２２，２３、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３も同様のハードウェア構成で実現することができる。
【００３５】
図４は、システム分析装置の機能ブロックを示す図である。システム分析装置１００は、パケットデータ記憶部１１１、プロトコルログ記憶部１１２、モデル記憶部１１３、分析結果記憶部１１４、メッセージ観測部１２０、メッセージ解析部１３０、モデル生成部１４０、分析部１５０、及び出力部１６０を有している。
【００３６】
パケットデータ記憶部１１１は、スイッチ１０を介して送受信されたメッセージを構成するパケット記憶するための記憶装置である。プロトコルログ記憶部１１２は、パケットを解析することにより取得したメッセージの情報を記憶するための記憶装置である。モデル記憶部１１３は、トランザクションを完了するまでに送受信されるメッセージのリスト（トランザクションモデル）を記憶する記憶装置である。分析結果記憶部１１４は、メッセージの分析結果を記憶する記憶装置である。
【００３７】
メッセージ観測部１２０は、スイッチ１０を介して送受信されるメッセージを観測し、そのメッセージを構成するパケットをパケットデータ記憶部１１１に格納する。
メッセージ解析部１３０は、パケットデータ記憶部１１１に格納されたパケットの内容を解析し、解析結果をプロトコルログ記憶部１１２に格納する。
【００３８】
モデル生成部１４０は、プロトコルログ記憶部１１２に格納された情報に基づいてトランザクションモデルを生成し、モデル記憶部１１３に格納する。
分析部１５０は、プロトコルログ記憶部１１２に格納された情報と、モデル記憶部１１３に格納されたトランザクションモデルとを比較して、各トランザクションの処理時間等の統計情報を分析する。そして、分析部１５０は、分析結果を分析結果記憶部１１４に格納する。
【００３９】
出力部１６０は、分析結果記憶部１１４に格納されている分析結果を、グラフ等でモニタ１１等に出力する。
このような構成のシステム分析装置１００で、次のようなシステム分析処理が実行される。
【００４０】
図５は、システム分析処理の手順を示すフローチャートである。以下、図５に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］メッセージ観測部１２０は、スイッチ１０を流れるメッセージを観測し、パケットデータ記憶部１１１に格納する。
【００４１】
［ステップＳ１２］メッセージ解析部１３０は、パケットデータ記憶部１１１に格納されたメッセージを解析する。
［ステップＳ１３］その後、モデル生成部１４０により、モデル生成指示が入力されているか否かが判断されるとともに、分析部１５０により、分析指示が入力されているかが判断される。モデル生成指示や分析指示は、例えば、システム分析装置１００の管理者によるキーボード１２等を用いた操作入力によって与えられる。モデル生成指示が入力されている場合、処理がステップＳ１４に進められる。分析指示が入力されている場合、処理がステップＳ１５に進められる。
【００４２】
［ステップＳ１４］モデル生成指示が入力されている場合、モデル生成部１４０は、プロトコルログ記憶部１１２に格納されている情報を参照し、トランザクションモデルを生成する。そして、モデル生成部１４０は、生成したトランザクションモデルをモデル記憶部１１３に格納する。その後、処理が終了する。
【００４３】
［ステップＳ１５］分析指示が入力されている場合、分析部１５０は、モデル記憶部１１３に格納されているトランザクションモデルとプロトコルログ記憶部１１２に格納されている情報とを参照し、実行されているトランザクションに関する情報を分析する。そして、分析部１５０は、分析結果を分析結果記憶部１１４に格納する。
【００４４】
［ステップＳ１６］出力部１６０は、分析結果記憶部１１４に格納された分析結果に基づいて、統計情報等をモニタ１１に出力する。その後、処理が終了する。
このような手順でシステム分析が行われる。以下、図５に示す各ステップの処理を、詳細に説明する。
【００４５】
まず、メッセージ観測処理について説明する。
図６は、メッセージ観測状況を示す概念図である。この例では、Ｗｅｂサーバ３１、アプリケーションサーバ３２、ＤＢサーバ３３が監視対象となっている。各サーバは、スイッチ１０の個別のポート１１，１２，１３に接続されている。また、システム管理装置１００は、スイッチ１０のポート１４に接続されている。
【００４６】
スイッチ１０は、自身を通過するデータをミラーリングする機能を有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。
【００４７】
図６の例では、Ｗｅｂサーバ３１が接続されたポート１１、アプリケーションサーバ３２が接続されたポート１２、及びＤＢサーバ３３が接続されたポート１３のミラーリング先として、システム分析装置１００が接続されたポート１４が指定されている。これにより、各サーバ宛のパケットは宛先となるサーバに入力されるとともに、システム分析装置１００にも入力される。
【００４８】
例えば、クライアント２１からの要求に応じて、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３が連動してサービスを提供する場合を想定する。この場合、まず、クライアント２１からＷｅｂサーバ３１に対してパケット４１（例えば、ＨＴＴＰのパケット）が送信される。このとき、パケット４１と同じ内容のパケット５１がシステム分析装置１００に入力される。次に、Ｗｅｂサーバ３１からアプリケーションサーバ３２へパケット４２（例えば、ＩＩＯＰ（Internet Inter-ORB Protocol）のパケット）が送信されると、パケット４２と同じ内容のパケット５２がシステム分析装置１００に入力される。さらに、アプリケーションサーバ３２からＤＢサーバ３３へ、パケット４３（例えば、ＤＢアクセスのパケット）が送信されると、パケット４３と同じ内容のパケット５３がシステム分析装置１００に入力される。
【００４９】
システム分析装置１００に入力されたパケット５１，５２，５３は、スイッチ１０に直接接続されたメッセージ観測部１２０で取得され、パケットデータ記憶部１１１に格納される。具体的には、メッセージ観測部１２０は、スイッチ１０から送られたパケット５１，５２，５３をキャプチャし、受信時刻とともにパケットデータ記憶部１１１に格納する。
【００５０】
なお、メッセージ観測部１２０は、キャプチャしたパケット５１，５２，５３を蓄積せずに、観測と同時にメッセージ解析部１３０に送ってもよい。また、メッセージ観測部１２０は、メッセージ観測手段において必要なパケットのみをキャプチャすることもできる。さらに、スイッチ１０において必要なデータのみを選択してミラーリングすることもできる。
【００５１】
図７は、パケットデータ記憶部のデータ構造例を示す図である。パケットデータ記憶部１１１には、複数のパケット５５１〜５５８が格納されている。また、パケットデータ記憶部１１１には、各パケットデータ５５１〜５５８の受信時刻を示す時刻情報６１〜６８が格納されている。
【００５２】
図８は、パケットに含まれる情報を示す図である。時刻情報６１とともに格納されているパケット５５１は、イーサネットヘッダ（Etherヘッダ）（イーサネット：登録商標）５５１ａ、ＩＰヘッダ５５１ｂ、ＴＣＰヘッダ５５１ｃ、及びＴＣＰデータ５５１ｄで構成される。
【００５３】
図９は、ＩＰヘッダの詳細を示す図である。ＩＰヘッダ５５１ｂは、バージョン情報（version）、ヘッダ長、サービスタイプ（Type of Service）、データ長、識別子（ＩＤ）、フラグ（Flag）、フラグメントオフセット（Fragment Offset）、生存時間（Time Of Live）、プロトコル（Protocol）、ヘッダチェックサム（Header Checksum）、送信側ＩＰアドレス、受信側ＩＰアドレス、オプション（Option）、及びパディング（Padding）で構成されている。
【００５４】
図１０は、ＴＣＰヘッダの詳細を示す図である。ＴＣＰヘッダ５５１ｃは、送信側ポート、受信側ポート、送信用シーケンス番号（Sequence Number）、応答確認番号（Acknowledge Number）、ヘッダ長、リザーブ（Reserved）、フラグ、ウィンドウ（Window）、チェックサム（Checksum）、緊急ポインタ（Urgent Pointer）、及びオプション（Option）で構成される。フラグは、さらに、ＵＲＧ（Urgent Flag）、ＡＣＫ（Acknowledgement Flag）、ＰＳＨ（Push Flag）、ＲＳＴ（Reset Flag）、ＳＹＮ（Synchronize Flag)、ＦＩＮ（Fin Flag）で構成される。
【００５５】
メッセージ観測部１２０で取得したパケットは、メッセージ解析部１３０で解析される。
図１１は、メッセージ解析部の機能を示すブロック図である。メッセージ解析部１３０は、ＴＣＰ／ＵＤＰ（User Datagram Protocol）セッション再構成部１３１、メッセージ再構成部１３２、オブジェクト名割り当て部１３３、及びログ出力部１３４を有している。
【００５６】
ＴＣＰ／ＵＤＰセッション再構成部１３１は、パケット５５１〜５５８を、そのパケット５５１〜５５８が属するセッション７１〜７３毎に振り分ける。メッセージ再構成部１３２は、セッション７１〜７３に振り分けられたパケット５５１〜５５８の中から所定のデータを抽出し、メッセージ対８１〜８３を再構成する。オブジェクト名割り当て部１３３は、メッセージ対８１〜８３に対応するオブジェクト名を決定する。ログ出力部１３４は、処理結果をプロトコルログ記憶部１１２に出力する。
【００５７】
メッセージ観測部１２０からメッセージ解析部１３０にパケット５５１〜５５８が入力されると、ＴＣＰ／ＵＤＰセッション再構成部１３１、メッセージ再構成部１３２、オブジェクト名割り当て部１３３、ログ出力部１３４の順番で、処理が実行される。なお、メッセージ観測部１２０から渡されるパケット５５１〜５５８は、パケットデータ記憶部１１１に予め格納されたパケットが渡される場合と、メッセージ観測部１２０によって観測されたパケットが転送される場合とがある。
【００５８】
以下、メッセージ解析部１３０内の各要素が実行する処理を、詳細に説明する。
メッセージ解析部１３０に渡されたパケット５５１〜５５８は、まず、ＴＣＰ／ＵＤＰセッション再構成部１３１に入力される。ＴＣＰ／ＵＤＰセッション再構成部１３１は、入力されたパケット５５１〜５５８のセッション別の振り分けを行う。
【００５９】
具体的には、ＴＣＰ／ＵＤＰセッション再構成部１３１は、まずパケット５５１のＩＰヘッダ５５１ｂから、送受信側ＩＰアドレス（図９参照）を取得する。次に、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＴＣＰヘッダ５５１ｃから送信側ポート番号と受信側ポート番号とを取得する（図１０参照）。そして、ＴＣＰ／ＵＤＰセッション再構成部１３１は、取得した４つの値の組をセッションの識別子とする。このとき、識別子に一意な番号を割り当てることもできる。
【００６０】
ＴＣＰ／ＵＤＰセッション再構成部１３１は、各パケット５５１〜５５８の識別子を生成し、同じ識別子を持つパケットを、同じセッションで送られたパケットであるとして振り分ける。
【００６１】
次に、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＴＣＰの場合、ＴＣＰヘッダ５５１ｃに含まれるフラグを読み取って、開始・確立・切断などのセッション状態を取得する（図１０参照）。例えば、ＳＹＮ「１」のパケットの検出によってセッションの開始を認識し、そのパケットに対するＡＣＫ「１」の応答によってセッションの確立を認識し、セッション確立状態でデータ伝送とそれに対するＡＣＫ「１」の応答が繰り返し行われ、最後にＦＩＮ「１」パケットの検出によってセッションの切断を認識する。
【００６２】
また、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＩＰヘッダ５５１ｂ・ＴＣＰヘッダ５５１ｃに含まれるデータ長とヘッダ長を取得して、データ長から各ヘッダ長を引くことでデータ部の長さ（データサイズ）を取得する。
【００６３】
さらに、ＴＣＰ／ＵＤＰセッション再構成部１３１に対して、事前に各サーバのＩＰアドレスを与えておくことで、ＩＰアドレスの組から各パケットの送信方向を決定することもできる。
【００６４】
また、ＴＣＰ／ＵＤＰセッション再構成部１３１は、例えば、パケットのＩＰヘッダから、サーバアドレスが送信アドレスにあれば送信側ポート番号を、サーバアドレスが宛て先アドレスにあれば受信側ポート番号を読み取る。そして、ＴＣＰ／ＵＤＰセッション再構成部１３１は、そのポート番号を識別子とすることでどのサービスに関するセッションであるかを調べることができる。例えば、サーバ側のポートが８０番である場合、Ｗｅｂサーバとの通信（ＨＴＴＰ）であると判定する。
【００６５】
図１２は、再構成したセッションの例である。ＴＣＰ／ＵＤＰセッション再構成部１３１によって、パケット５５１〜５５８からＴＣＰのセッション７１〜７３が再構成される。図１２では、縦軸が時間軸を表している（図中、上から下に時間が進行する）。
【００６６】
各軸の上の数字が、各機器のＩＰアドレスを表している。ＩＰアドレスの組によってパケットが振り分けられている。図１２では、各パケットから取得したフラグもしくはデータサイズとともに時系列のシーケンスで表示されている。
【００６７】
このように、セッション７１〜７３毎に振り分けられたパケットがメッセージ再構成部１３２に渡される。
メッセージ再構成部１３２は、セッション７１〜７３毎に振り分けられたパケットのデータ部からメッセージを再構成する。メッセージ再構成部１３２では、まず同一のセッション７１〜７３で送受信されるパケットの集まりからデータ部分を抜き出して並べる。そして、メッセージ再構成部１３２は、並べられたデータ部分の列を、プロトコルのフォーマットに従ってメッセージのサイズを取得してメッセージを分割する。このとき、メッセージが複数に分割送信されていた場合には、複数のデータ部分を連結してひとつのメッセージを切り出してよい。もしくは、連結された複数のメッセージが送信されていた場合には、単一のデータ部から複数のメッセージを切り出してよい。また、各メッセージにはセッション上で一意な番号を割り振ってよい。
【００６８】
図１３は、メッセージ再構成例を示す第１の図である。図１３は、送信側ＩＰアドレスが１０．２５．２１４．１０、受信側ＩＰアドレスが１０．２５．２１４．１０５、送信側ポート番号が３４４９、受信側ポート番号が８０である識別子を持つセッション７１上のメッセージを解析する例である。
【００６９】
メッセージ再構成部１３２は、パケット５５４の属するセッションの受信側ポート番号が８０番であることから、パケット５５４のデータ部をＨＴＴＰによるクライアント２１からＷｅｂサーバ３１へのリクエストであると判定し、ＨＴＴＰメッセージとして切り分ける。
【００７０】
ＨＴＴＰの場合、メッセージ再構成部１３２は、データから特定のオクテットの組み合わせ(0x0D0A0D0A=\r\n\r\n)を検索し、その位置までをヘッダ部（ＨＴＴＰヘッダ）とする。次に、データ部（ＨＴＴＰデータ）が存在する場合には、ヘッダ部に含まれるContent-Lengthフィールドからデータ部の長さを取得し、メッセージを切り出すとともに、メッセージを構成する最初のパケット５５４の受信時刻「００．００．００：１００」をそのメッセージの受信時刻とする。そして、メッセージ再構成部１３２は、メッセージ種別や要求されたＵＲＬ、応答結果データを取得する。
【００７１】
例えばＨＴＴＰメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・ＵＲＬ・個別のパラメータなどがある。また、例えばＩＩＯＰメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・メソッド名・個別のパラメータなどがある。さらに、例えばＤＢメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・ＳＱＬ（Structured Query Language）文・ＳＱＬ文のパラメータなどがある。
【００７２】
図１３の例では、ＨＴＴＰリクエストメッセージのヘッダの先頭がＰＯＳＴであり、その直後が/corba/servlet/Balanceであることからメッセージ種別はＰＯＳＴ、オブジェクトを表すＵＲＬは/corba/servlet/Balanceであることが分かる。また、Content-Lengthフィールドの値が２９であることからデータ部の長さは２９バイトあることが分かる。したがって、メッセージ再構成部１３２は、ヘッダ終端から２９バイトまでをメッセージとして切り出す。
【００７３】
また、メッセージ再構成部１３２では、実行主体に対するリクエストメッセージとその返答であるレスポンスメッセージを対応付け、応答までにかかった時間を算出する。例えばＨＴＴＰの場合、リクエストメッセージを、同一のセッション上で直後に現れるレスポンスメッセージと対応付ける。また、レスポンスメッセージの受信時刻からリクエストメッセージの受信時刻を差し引き、このメッセージ対の応答時間とする。また、このとき、対応付けたメッセージ対に一意な番号を割り当ててもよい。
【００７４】
図１４は、リクエストへのレスポンスメッセージの対応付けの例を示す図である。図１４の例では、ＨＴＴＰレスポンスメッセージとＨＴＴＰリクエストメッセージとを対応付ける場合を示している。
【００７５】
図１３のパケット５５４から取得したメッセージと、図１４のパケット５５６から取得したメッセージは、送信側ＩＰアドレス１０．２５．２１４．１０５、受信側ＩＰアドレス１０．２５．２１４．１０、送信側ポート番号８０、受信側ポート番号３４４９のセッション上でやりとりされたメッセージであることから、図１４のパケット５５６から取得したメッセージは、図１３のパケット５５４から取得したメッセージと同一セッション上で連続して送信されたメッセージであると判定する。また、２つのメッセージの送信方向が反対であることから、これら２つのメッセージを対応付けて、メッセージ対が生成される。メッセージ再構成部１３２は、メッセージ対の応答時間を算出し、これら二つのメッセージに共通の識別番号１を割り当てる。
【００７６】
このようにして、メッセージ対がオブジェクト名割り当て部１３３に渡される。そして、オブジェクト名割り当て部１３３では、メッセージ対に対応するオブジェクト名が決定される。
【００７７】
なお、オブジェクト名は、以降の装置で分析したい内容に応じて変更してよい。また、異なるメッセージに対して同じオブジェクト名を割り当ててもよく、単一のメッセージに対して複数のオブジェクト名を割り当ててもよい。また、取得できる全ての情報を仮のオブジェクト名として割り当てておき、以降の装置においてオブジェクト名を再び決定してもよい。
【００７８】
例えばＨＴＴＰメッセージ対にオブジェクト名としてＵＲＬを割り当てる。これは、実行する処理とメッセージを関連付けるための情報がＵＲＬ中に含まれることによる。
また、例えばＩＩＯＰメッセージ対にオブジェクト名としてメソッド名を割り当てる。これは、ＩＩＯＰのメソッド名がサーバ上における単一の処理を表すためである。
【００７９】
また、例えばＤＢメッセージ対にオブジェクト名としてSelect・Insert・Update・FetchなどのＳＱＬオペレータ種別とデータベーステーブル名の組を割り当てる。これは、データベース操作による書き込みの有無や、操作する対象となるデータベーステーブルのサイズなどによって異なる処理の量や時間を区別するためである。
【００８０】
図１５は、オブジェクト名の割り当てとメッセージの解析結果を示す図である。この例ではＨＴＴＰの図１４で対応付けたメッセージ対８１に対してオブジェクト名８１ｃを割り当てている。このオブジェクト名８１ｃは、リクエストメッセージで指定されたＵＲＬである。メッセージ８１ａは図１３のパケット５５４から再構成したＨＴＴＰリクエストメッセージであり、メッセージ８１ｂは図１４のパケット５５６から再構成したＨＴＴＰレスポンスメッセージであり、メッセージ対８１はこれらのメッセージを対応付けたものである。
【００８１】
図１６は、１つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。この例では、ＨＴＴＰプロトコルのメッセージと同様に、ＩＩＯＰやＤＢなど他のプロトコルについてもメッセージを再構成し、オブジェクト名を割り当てている。
【００８２】
したがって、図１３、図１４、図１５で対応付けたＨＴＴＰのメッセージ８１ａ，８１ｂ（ＨＴＴＰのセッション上での識別番号１）、ＩＩＯＰのセッション上で識別番号１を持つリクエストのメッセージ８２ａ（オブジェクト名：Mbalance）と対応するレスポンスのメッセージ８２ｂ、及びＤＢのセッション上で識別番号１を持つリクエストのメッセージ８３ａ（オブジェクト名：Fetch Account）と対応するレスポンスのメッセージ８３ｂが再構成されている。これらのメッセージが、抽出したオブジェクト名とともにシーケンス図として表示されている。
【００８３】
メッセージ８１ａのオブジェクト名は、/corba/servlet/Balanceである。メッセージ８２ａのオブジェクト名は、Mbalanceである。メッセージ８３ａのオブジェクト名は、Fetch Accountである。
【００８４】
このような、オブジェクト名が割り当てられたメッセージ対８１〜８３が、ログ出力部１３４に入力される（図１１参照）。すると、ログ出力部１３４は、ＴＣＰ／ＵＤＰセッション再構成部１３１と、メッセージ再構成部１３２と、オブジェクト名割り当て部１３３で得られた情報を、プロトコルログとして出力する。このとき、出力されるプロトコルログはテキスト形式であってもよく、バイナリ形式であってもよい。
【００８５】
図１７は、プロトコルログの例を示す図である。この例では、テキスト形式で出力したプロトコルログ１１２ａ〜１１２ｆが示されている。
プロトコルログ１１２ａ〜１１２ｆには、メッセージ毎に、時刻（メッセージの受信時刻）、識別番号、プロトコル（プロトコルの名称）、方向（リクエストかレスポンスか）、及びオブジェクト／応答時間（リクエストについてはオブジェクト名、レスポンスに対しては応答時間）が設定されている。
【００８６】
例えば、ＨＴＴＰのセッションの場合、リクエストのメッセージを示すプロトコルログ１１２ａには、受信時刻「００．００．００．１００」、識別番号「１」、オブジェクト名「/corba/servlet/Balance」が設定されている。そして、レスポンスのメッセージを示すプロトコルログ１１２ｆには、受信時刻「００．００．００．２９０」、識別番号「１」、応答時間「０．１９０（秒）」が設定されている。
【００８７】
このような、クライアント２１，２２，２３に対してサービスが提供される毎に、図１７に示すようなプロトコルログ１１２ａ〜１１２ｆが、メッセージ解析部１３０によってプロトコルログ記憶部１１２内に逐次蓄積される。その結果、プロトコルログ記憶部１１２内には、複数のトランザクションに関係するプロトコルログが混在して格納される。
【００８８】
図１８は、プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。プロトコルログ記憶部１１２には、異なるトランザクションに関連するメッセージのプロトコルログが時系列に格納されている。図１８には、インターネットバンキングサービスでの「残高確認」トランザクションと「入金」トランザクション処理時に発生するメッセージに基づくプロトコルログが示されている。
【００８９】
プロトコルログ記憶部１１２に格納されたプロトコルログは、モデル生成指示が入力されている場合、モデル生成部１４０に入力される。すると、モデル生成部１４０によって、トランザクションモデルが生成される。
【００９０】
モデル生成部１４０は、プロトコルログ記憶部１１２に格納されたプロトコルログに基づいて、トランザクションモデルを獲得する。なお、図１８に示したようなプロトコルログは、ＨＴＴＰプロトコル、ＩＩＯＰプロトコル、そしてＤＢプロトコルのメッセージが複雑に混ざり合っている。なお、各プロトコルのリクエストとそれに対応するレスポンスのメッセージは、メッセージ再構成部１３２によって生成された同じ識別番号を持つ。
【００９１】
そこで、第１の実施の形態では、モデル生成部１４０は、処理間の呼出関係の確からしさに基づく選択基準として、次のような基準を採用する。すなわち、各トランザクションが他のトランザクション（クライアントのリクエストからレスポンスまで）とオーバラップすることのない部分（すなわち非多重（多重度１）の部分）のみを抜き出して、モデルを獲得する。非多重のトランザクションであれば、そのトランザクションが実行されている時間帯内の各処理間には、呼出関係が確実に存在する（確からしさが高い）。
【００９２】
そこで、モデル生成部１４０は、まず、同じ識別番号を持つＨＴＴＰプロトコルのリクエスト・レスポンスのペア群を検出する。次に、モデル生成部１４０は、ＨＴＴＰプロトコルのメッセージペアの間に、他の識別番号を持つＨＴＴＰのメッセージが存在するかどうかをチェックする。存在しない場合、モデル生成部１４０は、ＨＴＴＰプロトコルのリクエスト・レスポンスのペア、及びその間の全てのリクエストを選択する。つまり、横断関係にないトランザクションが抽出される。
【００９３】
詳細には、以下のような処理が行われる。
図１９は、トランザクションモデル生成処理を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
【００９４】
［ステップＳ２１］モデル生成部１４０は、パラメータの初期化を行う。具体的には、多重度＝０、重複フラグ＝０とする。
［ステップＳ２２］モデル生成部１４０は、プロトコルログ記憶部１１２からメッセージを読み込む。
【００９５】
［ステップＳ２３］モデル生成部１４０は、メッセージがあるか否かを判断する。メッセージがあれば、処理がステップＳ２４に進められる。メッセージがなければ処理が終了する。
【００９６】
［ステップＳ２４］モデル生成部１４０は、読み込んだメッセージのプロトコルがＨＴＴＰか否かを判断する。ＨＴＴＰであれば処理がステップＳ２５に進められる。ＨＴＴＰでなければ、処理がステップＳ２２に進められる。
【００９７】
［ステップＳ２５］モデル生成部１４０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージであれば、処理がステップＳ２６に進められる。レスポンスのメッセージであれば、処理がステップＳ３０に進められる。
【００９８】
［ステップＳ２６］モデル生成部１４０は、多重度＝０か否かを判断する。多重度が０であれば、処理がステップＳ２７に進められる。多重度が０でなければ、処理がステップＳ２９に進められる。
【００９９】
［ステップＳ２７］モデル生成部１４０は、多重度をインクリメント（１加算）する。
［ステップＳ２８］モデル生成部１４０は、開始位置を保存する。具体的には、処理したメッセージの位置を特定する情報（例えば、該当するプロトコルログを示すポインタ等）を格納する。その後、処理がステップＳ２２に進められる。
【０１００】
［ステップＳ２９］モデル生成部１４０は、多重度をインクリメント（１加算）し、さらに重複フラグの値を１に設定する。その後、処理がステップＳ２２に進められる。
［ステップＳ３０］ステップＳ２５でレスポンスのメッセージであると判断されると、モデル生成部１４０は、多重度＝１か否かを判断する。多重度が１であれば、処理がステップＳ３１に進められる。多重度が１以外であれば、処理がステップＳ２２に進められる。
【０１０１】
［ステップＳ３１］モデル生成部１４０は、重複フラグ＝０か否かを判断する。重複フラグが０であれば、処理がステップＳ３２に進められる。重複フラグが１であれば、処理がステップＳ３３に進められる。
【０１０２】
［ステップＳ３２］モデル生成部１４０は、開始位置から現在位置のメッセージをモデル生成用メッセージとして選択する。その後、処理がステップＳ３４に進められる。
［ステップＳ３３］モデル生成部１４０は、重複フラグの値を０に設定する。
【０１０３】
［ステップＳ３４］モデル生成部１４０は、多重度をデクリメント（１減算）する。その後、処理がステップＳ２２に進められる。
このようにして、他のトランザクションと重複しないトランザクションを構成するメッセージを特定し、モデル生成用メッセージとして選択することができる。
【０１０４】
図２０は、選択されるモデル生成用メッセージを示す図である。図２０には、図１８に示すようなプロトコルログからモデル生成に抽出されるメッセージの集合が示されている。
【０１０５】
例えば、図２０のプロトコルログからＨＴＴＰのリクエスト・レスポンスのペアを探すと、識別番号＝１のＨＴＴＰのリクエスト・レスポンスのペア９１、識別番号＝２のＨＴＴＰのリクエスト・レスポンスのペア９２、識別番号＝３のＨＴＴＰのリクエスト・レスポンスのペア９３、そして識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９４がまず検出される。しかし、識別番号＝２のＨＴＴＰプロトコルのリクエスト・レスポンスのペア９２の間に、識別番号＝３のＨＴＴＰリクエストメッセージが存在する。そのため、４つのＨＴＴＰのリクエスト・レスポンスのペア９１〜９４のうち、最終的には識別番号＝１と識別番号＝４のペアのみが抽出される。すなわち、識別番号＝１と識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９１，９４の間のメッセージがモデル生成に用いられることになる。
【０１０６】
図２１は、「残高確認」トランザクションのモデル生成例を示す図である。図２１には、図２０における識別番号＝１のＨＴＴＰのリクエスト・レスポンスのペア９１の間のメッセージ集合２０１から生成される「残高確認」トランザクションモデル２０３が示されている。
【０１０７】
モデル生成部１４０では、上位（利用者側の）の処理が下位の処理を呼び出すが、逆はないという制約を用いる。この制約は、階層的な構成のシステムでは一般的な制約である。具体的には、クライアント２１からＷｅｂサーバ３１の処理が呼び出され、Ｗｅｂサーバ３１からアプリケーションサーバ３２の処理が呼び出され、そこからＤＢサーバ３３の処理が呼び出される。
【０１０８】
モデル生成部１４０は、メッセージ集合２０１を規定の制約に沿って解析し、処理シーケンス２０２を作成する。具体的には、モデル生成部１４０は、メッセージ集合２０１内の各メッセージの内容を、時系列に沿って解析する。メッセージ集合２０１内の各メッセージの内容は、以下の通りである。
【０１０９】
まず、識別番号＝１のＨＴＴＰプロトコルのリクエストメッセージは、クライアント２１からＷｅｂサーバ３１への処理要求を示す。この場合、/corba/servlet/Balanceのオブジェクト処理が請求される。次に、識別番号＝１のＩＩＯＰプロトコルのリクエストメッセージはＷｅｂサーバ３１からアプリケーションサーバ３２へのMbalanceメソッドの処理を要求する。さらに、識別番号＝１のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountという操作処理を要求する。その後、ＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１から、それぞれＤＢ、ＩＩＯＰ、ＨＴＴＰプロトコルのレスポンスのメッセージが送信される。この内容に沿った処理シーケンス２０２が生成される。
【０１１０】
処理シーケンス２０２には、各セッションでの応答時間が含まれる。セッションの時間は、レスポンスメッセージに示されている。図２１の例では、ＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１のリクエストからレスポンスまでの応答時間がそれぞれ１０msec、９０msec、１９０msecである。
【０１１１】
また、「残高確認」の処理シーケンス２０２では、Ｗｅｂサーバ３１で/corba/servlet/Balanceのオブジェクトが処理され、アプリケーションサーバ３２でMbalanceオブジェクトが処理され、ＤＢサーバ３３でFetch Accountオブジェクトが処理されている。そこで、モデル生成部１４０は、各サーバにおけるオブジェクトの処理時間を算出する。
【０１１２】
ＤＢサーバ３３の処理時間は、ＤＢリクエストからレスポンスまでのＤＢの応答時間の１０msecである。アプリケーションサーバ３２の処理時間は、ＩＩＯＰリクエストからレスポンスの応答時間の９０msecからＤＢサーバ３３の応答時間を除いた８０msec（＝９０−１０）である。そしてＷｅｂサーバ３１の処理時間は、ＨＴＴＰリクエストからレスポンスの応答時間１９０msecからアプリケーションサーバの応答時間を除いた１００msec（＝１９０−９０）である。
【０１１３】
そして、モデル生成部１４０は、オブジェクトの処理の呼出関係及び各オブジェクトの処理時間を定義したトランザクションモデル２０３を生成する。
図２２は、「入金」トランザクションのモデル生成例を示す図である。図２２には、図２０における識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９４の間のメッセージ集合２１１から生成される「入金」トランザクションモデル２１３が示されている。
【０１１４】
図２１の処理と同様に、モデル生成部１４０は、メッセージ集合２１１を所定の制約に沿って解析し、処理シーケンス２１２を作成する。メッセージ集合２１１内の各メッセージの内容は、以下の通りである。
【０１１５】
まず、識別番号＝４のＨＴＴＰプロトコルのリクエストメッセージは、クライアント２１からＷｅｂサーバ３１への処理を要求する。この場合、ＵＲＬは/corba/servlet/Depositである。次に、識別番号＝４のＩＩＯＰプロトコルのリクエストメッセージはＷｅｂサーバ３１からアプリケーションサーバ３２へのMdepositメソッドの処理を要求する。次に、識別番号＝５のＤＢプロトコルのリクエストメッセージはアプリケーションサーバ３２からＤＢサーバ３３へのFetch Accountという操作処理を要求する。このＤＢリクエストに対応する識別番号＝５のＤＢレスポンスの応答メッセージから分かるように、Fetch Accountの処理はＤＢサーバ３３で１０msecかかった。
【０１１６】
その後に、さらに識別番号＝６のＤＢプロトコルのリクエストメッセージとしてアプリケーションサーバ３２からＤＢサーバ３３へのUpdate Accountという操作処理が要求される。その後、識別番号＝６のＤＢプロトコルのレスポンス、識別番号＝４のＩＩＯＰプロトコルのレスポンス、そして識別番号＝４のＨＴＴＰプロトコルのレスポンスメッセージがＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１から送信される。
【０１１７】
このようなメッセージの流れからトランザクションモデル２１３が生成され、モデル記憶部１１３に格納される。また、レスポンスメッセージから、リクエストからレスポンスまでのそれぞれの応答時間が２０msec、１２０msec、２４０msecであったと分かる。この応答時間も、トランザクションモデル２１３に設定される。
【０１１８】
「入金」のトランザクションモデル２１３では、Ｗｅｂサーバ３１で/corba/servlet/Depositのオブジェクトが処理され、アプリケーションサーバ３２でMdepositオブジェクトが処理され、ＤＢサーバ３３でFetch AccountとUpdate Accountオブジェクトが処理されている。そこで、モデル生成部１４０は、各サーバにおけるオブジェクトの処理時間情報を算出する。それぞれの処理時間は、ＤＢサーバ３３では１０msecと２０msec、アプリケーションサーバ３２では９０msec（＝１２０−（１０＋２０））、そしてＷｅｂサーバ３１では１２０msec（＝２４０−１２０）である。
【０１１９】
そして、モデル生成部１４０は、オブジェクトの処理の呼出関係及び各サーバにおけるオブジェクトの処理時間を定義したトランザクションモデル２１３を生成する。
なお、メッセージ解析部１３０から、再度「残高確認」や「入金」トランザクション処理時のメッセージがモデル生成部１４０に入力され、これらが多重度１である場合があり得る。この場合、それらのメッセージを無視してもよい。また、同様にモデル生成を行い、すでに生成されている同じ種類のトランザクションの各サーバの処理時間に反映（例えば、平均時間などを利用して）することもできる。
【０１２０】
また、分析部１５０で実行される既存のトランザクションモデルとメッセージのマッチング法を用いて、多重度１のモデルを基に、多重度１以上のトランザクションのメッセージ集合を抽出し、それぞれの多重度でのアプリケーション処理時間を求めてモデルを生成することもできる。
【０１２１】
次に、分析部１５０で実行される処理を詳細に説明する。分析部１５０は、プロトコルログ記憶部１１２に格納されたプロトコルログを、モデル記憶部１１３に格納されるトランザクションモデルと比較することで、各トランザクションを構成するメッセージを識別する。そして、分析部１５０は、トランザクション毎のメッセージの処理時間によって、システムの状態を分析する。具体的には、以下の処理が行われる。
【０１２２】
図２３は、分析処理の手順を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ５１］分析部１５０は、プロトコルログ記憶部１１２から未処理のプロトコルログを読み込む。
【０１２３】
［ステップＳ５２］分析部１５０は、未処理のプロトコルログがあるか否かを判断する。未処理のプロトコルログがある場合、処理がステップＳ５３に進められる。未処理のプロトコルログが無い場合、処理が終了する。
【０１２４】
［ステップＳ５３］分析部１５０は、読み込んだプロトコルログに示されるメッセージのプロトコルを判断する。プロトコルがＨＴＴＰであれば、処理がステップＳ５４に進められる。プロトコルがＩＩＯＰであれば、処理がステップＳ５９に進められる。プロトコルがＤＢであれば、処理がステップＳ６２に進められる。
【０１２５】
［ステップＳ５４］プロトコルがＨＴＴＰの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ５５に進められる。レスポンスのメッセージの場合、処理がステップＳ５７に進められる。
【０１２６】
［ステップＳ５５］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（ＵＲＬ）に対応するトランザクションモデルをモデル記憶部１１３から検出する。そして、ＨＴＴＰリクエストによって発生した該当トランザクションの内容を認識する。
【０１２７】
［ステップＳ５６］分析部１５０は、処理中テーブルに新しいトランザクション及びＨＴＴＰ識別番号を登録する。その後、処理がステップＳ５１に進められる。
［ステップＳ５７］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて、処理中テーブルから対応トランザクション及びＨＴＴＰを検索し、Ｗｅｂサーバ３１における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。
【０１２８】
［ステップＳ５８］分析部１５０は、終了トランザクション情報を出力部１６０に出力し、処理中テーブルから削除する。その後、処理がステップＳ５１に進められる。
［ステップＳ５９］プロトコルがＩＩＯＰの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ６０に進められる。レスポンスのメッセージの場合、処理がステップＳ６１に進められる。
【０１２９】
［ステップＳ６０］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（メソッド）を用いて、処置中テーブルから対応トランザクションを検索し、ＩＩＯＰ識別番号を登録する。その後、処理がステップＳ５１に進められる。
【０１３０】
［ステップＳ６１］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、アプリケーションサーバ３２における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップＳ５１に進められる。
【０１３１】
［ステップＳ６２］プロトコルがＤＢの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ６３に進められる。レスポンスのメッセージの場合、処理がステップＳ６４に進められる。
【０１３２】
［ステップＳ６３］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（コマンド＋テーブル名）を用いて、処置中テーブルから対応トランザクションを検索し、ＤＢ識別番号を登録する。その後、処理がステップＳ５１に進められる。
【０１３３】
［ステップＳ６４］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、ＤＢサーバ３３における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップＳ５１に進められる。
【０１３４】
このような処理を行うことで、トランザクションの種別毎に、各サーバにおける処理時間等を記録することができる。
図２４は、分析部へ入力されるメッセージの例を示す図である。ユーザからの操作入力等により分析指示が出された後、メッセージ解析装置から出力されプロトコルログ記憶部１１２に格納されたプロトコルログ２２１〜２４２が、順次分析部１５０に入力される。
【０１３５】
分析部１５０ではこれらのプロトコルログ２２１〜２４２をモデル生成部１４０で得られた「残高確認」と「入金」のトランザクションモデル（図２１、図２２に示す）とマッチングする。そして、分析部１５０は、トランザクションモデルに合致するトランザクションを抽出する。以下、図２５〜図３４を参照して、図２４に示すプロトコルログ２２１〜２４２の分析例を説明する。なお、図２５〜図３４には、プロトコルログ２２１〜２４２を先頭から順に分析することで確認できるトランザクションの状態遷移が示されている。図２５〜図３４では、発生が確認されたトランザクションのうち、処理が開始されたオブジェクトを実線の楕円で示し、処理が開始されていないオブジェクトを破線の楕円で示している。
【０１３６】
図２５は、メッセージ分析例を示す第１の図である。まず、最初のプロトコルログ２２１で示されるメッセージは、識別番号＝１００のＨＴＴＰプロトコルであり、クライアント２１からＷｅｂサーバ３１への/corba/servlet/Balanceオブジェクト処理のリクエストメッセージである。このメッセージは第１の状態（ＳＴ１）で示すように、図２１に示すトランザクションモデル２０３（「残高確認」トランザクション）のＷｅｂサーバ３１処理への呼び出しと合致する。これは、Ｗｅｂサーバ３１での処理開始を意味する。
【０１３７】
次のプロトコルログ２２２で示されるメッセージは、識別番号＝２００のＩＩＯＰプロトコルの、アプリケーションサーバ３２へのMbalanceオブジェクト処理のリクエストメッセージである。このメッセージは第２の状態（ＳＴ２）で示すように、「残高確認」のトランザクションモデル２０３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１３８】
次のプロトコルログ２２３で示される識別番号＝１０１のＨＴＴＰリクエストメッセージは、Ｗｅｂサーバ３１への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第３の状態（ＳＴ３）で示すように、図２２に示す「入金」のトランザクションモデル２１３のＷｅｂサーバ３１処理への呼び出しと合致する。これは、Ｗｅｂサーバ３１での処理開始を意味する。
【０１３９】
次のプロトコルログ２２４で示される識別番号＝５００のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第４の状態（ＳＴ４）で示すように、「残高確認」トランザクションモデル２０３のＤＢサーバ３３処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４０】
図２６は、メッセージ分析例を示す第２の図である。次のプロトコルログ２２５で示される識別番号＝２０１のＩＩＯＰのリクエストメッセージは、アプリケーションサーバ３２へのMdepositの処理要求である。このメッセージは第５の状態（ＳＴ５）で示すように、「入金」トランザクションモデル２１３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１４１】
次のプロトコルログ２２６で示される識別番号＝１０２のＨＴＴＰリクエストメッセージは、Ｗｅｂサーバ３１への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第６の状態（ＳＴ６）で示すように、「入金」トランザクションモデル２１３のＷｅｂサーバ３１処理への呼び出しと合致する。これは、新たなＷｅｂサーバ３１での処理開始を意味する。
【０１４２】
図２７は、メッセージ分析例を示す第３の図である。次のプロトコルログ２２７で示される識別番号＝５００のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第７の状態（ＳＴ７）で示すように、「残高確認」トランザクションのＤＢサーバ３３での処理に２０msec要したことを意味する。図２１の「残高確認」トランザクションモデル２０３では、ＤＢサーバ３３でのFetch Accountコマンドの処理時間は１０msecとなっている。そのため、モデルとの差は１０msecである。
【０１４３】
次のプロトコルログ２２８で示される識別番号＝５０１のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第８の状態（ＳＴ８）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３の処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４４】
図２８は、メッセージ分析例を示す第４の図である。次のプロトコルログ２２９で示される識別番号＝５０１のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第９の状態（ＳＴ９）で示すように、「入金」トランザクションのＤＢサーバ３３での処理に２０msec要したことを意味する。図２２の「入金」トランザクションモデル２１３でのＤＢサーバ３３のFetch Accountコマンドの処理時間は１０msecとなっているため、モデルとの差は１０msecである。
【０１４５】
次のプロトコルログ２３０で示される識別番号＝５０２のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へUpdate Accountというコマンドの処理要求である。このメッセージは第１０の状態で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３の処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４６】
図２９は、メッセージ分析例を示す第５の図である。次のプロトコルログ２３１で示される識別番号＝２０２のＩＩＯＰのリクエストメッセージは、アプリケーションサーバ３２へのMdepositの処理要求である。このメッセージは第１１の状態（ＳＴ１１）で示すように、「入金」トランザクションモデル２１３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１４７】
次のプロトコルログ２３２で示される識別番号＝２００のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第１２の状態（ＳＴ１２）で示すように、「残高確認」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、ＩＩＯＰリクエストからレスポンスまでの応答時間は１００msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での処理(２０msec)を除いた８０msecになる。この値は、図２１の「残高確認」トランザクションモデル２０３でのアプリケーションサーバ３２の処理時間と同じである。
【０１４８】
図３０は、メッセージ分析例を示す第６の図である。次のプロトコルログ２３３で示される識別番号＝５０２のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第１３の状態（ＳＴ１３）で示すように、「入金」トランザクションのＤＢサーバ３３での処理が５０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのUpdate Accountコマンドの処理時間は２０msecとなっているため、モデルとの差は３０msecである。
【０１４９】
次のプロトコルログ２３４で示される識別番号＝５０３のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第１４の状態（ＳＴ１４）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３での処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１５０】
図３１は、メッセージ分析例を示す第７の図である。次のプロトコルログ２３５で示される識別番号＝１００のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第１５の状態（ＳＴ１５）で示すように、「残高確認」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は１９０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答処理（１００msec）を除いた９０msecになる。図２１の「残高確認」トランザクションモデル２０３では、Ｗｅｂサーバ３１での処理時間は１００msecとなっているため、モデルより１０msec早く終了していることになる。この時点で、１つの「残高確認」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５１】
次のプロトコルログ２３６で示される識別番号＝５０３のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第１６の状態（ＳＴ１６）で示すように、「入金」トランザクションのＤＢサーバ３３での処理が２０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのFetch Accountコマンドの処理時間は１０msecとなっているため、モデルとの差は１０msecである。
【０１５２】
図３２は、メッセージ分析例を示す第８の図である。次のプロトコルログ２３７で示される識別番号＝５０４のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へUpdate Accountというコマンドの処理要求である。このメッセージは第１７の状態（ＳＴ１７）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１５３】
次のプロトコルログ２３８で示される識別番号＝２０１のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第１８の状態（ＳＴ１８）で示すように、「入金」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は１８０msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での２つのコマンドの処理時間（７０msec＝２０msec＋５０msec）を除いた１１０msecになる。図２２の「入金」トランザクションモデル２１３では、アプリケーションサーバ３２での処理時間は９０msecとなっているため、モデルとの差は２０msecである。
【０１５４】
図３３は、メッセージ分析例を示す第９の図である。次のプロトコルログ２３９で示される識別番号＝１０１のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第１９の状態（ＳＴ１９）で示すように、「入金」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は３１０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答時間（１８０msec）を除いた１３０msecになる。図２２の「入金」トランザクションモデル２１３では、Ｗｅｂサーバ３１での処理時間は１２０msecとなっているため、モデルとの差は１０msecである。この時点で、１つの「入金」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５５】
次のプロトコルログ２４０で示される識別番号＝５０４のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第２０の状態（ＳＴ２０）で示すように、「入金」トランザクションのＤＢサーバ３３処理が２３０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのUpdate Accountコマンドの処理時間は２０msecとなっているため、モデルとの差は２１０msecであり、大きく増加していることで、ＤＢサーバ３３でなんらかの問題が起きていることが分かる。
【０１５６】
図３４は、メッセージ分析例を示す第１０の図である。次のプロトコルログ２４１で示される識別番号＝２０２のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第２１の状態（ＳＴ２１）で示すように、「入金」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は３５０msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での２つのコマンドの処理時間（２５０msec＝２０msec＋２３０msec）を除いた１００msecになる。図２２の「入金」トランザクションモデル２１３では、アプリケーションサーバ３２での処理時間は９０msecとなっている。そのため、モデルとの差は１０msecである。
【０１５７】
ここで注意したいのは、アプリケーションサーバ３２での応答時間が３５０msecであるにもかかわらず、実際のアプリケーションサーバ３２での処理時間はわずか１００msecに過ぎず、モデルとほぼ一致していることで、アプリケーションサーバ３２自身には性能問題がないということが分かる。
【０１５８】
次のプロトコルログ２４２で示される識別番号＝１０２のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第２２の状態（ＳＴ２２）で示すように、「入金」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は４７０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答時間（３５０msec）を除いた１２０msecになる。この時点で、最後の「入金」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５９】
図２２の「入金」トランザクションモデル２１３では、Ｗｅｂサーバ３１での処理時間は１２０msecとなっているため、モデルと一致する。アプリケーションサーバ３２と同様に、Ｗｅｂサーバ３１での応答時間が４７０msecであるにもかかわらず、実際のＷｅｂサーバ３１での処理時間はモデルと一致していることで、Ｗｅｂサーバ３１自身には性能問題がないということが分かる。以上のような分析結果は、分析結果記憶部１１４に格納される。
【０１６０】
次に、出力部１６０で行われる処理を詳細に説明する。
出力部１６０は、分析部１５０から分析結果記憶部１１４に格納されたトランザクションの情報をさまざまな形でモニタ１１に出力する。以下、出力部１６０によるトランザクション情報の出力例を示す。
【０１６１】
図３５は、サーバの平均処理時間の表示例を示す図である。図３５で示すように、出力部１６０は、サーバごとの平均処理時間を求めて、モニタ１１に平均処理時間を示す画面３０１を表示する。なお、各サーバの処理時間を示すグラフには、トランザクションモデルにおける処理時間を示す線が表示されている。なお、出力部１６０は、モデルとの処理時間との差が非常に大きい場合には、それらの処理をリストアップして、モニタ１１に表示することもできる。
【０１６２】
図３６は、トランザクション別処理時間及び内訳の表示例を示す図である。この画面３０２では、ある期間のトランザクションがすべて集計され、サーバごとの処理時間が表示されている。
【０１６３】
図３７は、処理時間ヒストグラムの表示例を示す図である。この画面３０３では、トランザクション処理時間、及び各サーバでの処理時間に関するヒストグラム（処理時間毎の発生頻度）が表示されている。
【０１６４】
また、ヒストグラム等の各種情報を画面に同時に表示することで、処理遅延原因の解析を容易にすることができる。
図３８は、複数の情報を同時に表示した場合の画面例を示す図である。この画面３１０には、トランザクション処理時間のヒストグラム表示部３１１、トランザクションの多重度表示部３１２、トランザクションの時間推移表示部３１３（Ｗｅｂサーバ３１、アプリケーションサーバ３２、ＤＢサーバ３３での内訳）とトランザクションメッセージのシーケンス表示部３１４が表示されている。出力部１６０は、各表示対象要素の表示内容を、互いに連携させて表示する。
【０１６５】
図３９は、表示対象要素間の連携の様子を示す図である。図３９に示すように、ヒストグラム表示部３１１には、処理遅延判別用の閾値を示すバー３１１ａが表示されている。このバー３１１ａは、ユーザからの操作入力に応じて左右に移動させることができる。バー３１１ａが表示されている位置の処理時間の値が閾値となる。閾値以上に処理時間を要したトランザクションが、注目処理と判断される。
【０１６６】
図３９の例では、３００msecの位置にバー３１１ａが表示されている。したがって、３００msec以上要したトランザクションが、注目処理となる。
多重度表示部３１２では、ヒストグラム表示部３１１上で注目処理と分類されたトランザクションの処理時間帯が、強調表示される。また、多重度表示部３１２の横には、スクロールバー３１２ａが設けられている。スクロールバー３１２ａで示された時間帯のトランザクションの詳細が、時間推移表示部３１３に表示される。
【０１６７】
時間推移表示部３１３には、プロトコル間のメッセージの受け渡しが、サーバ間のシーケンスで示される。時間推移表示部３１３の横には、スクロールバー３１３ａが設けられている。スクロールバー３１３ａで示された時間帯のメッセージの内容が、シーケンス表示部３１４に表示される。シーケンス表示部３１４では、注目処理に関するメッセージが強調表示される。
【０１６８】
このように、ユーザがヒストグラム表示部３１１から所定の時間以上かかるトランザクションを選択すれば、そのようなトランザクションがどこで起きるかをトランザクションの多重度表示部３１２、トランザクションの時間推移表示部３１３、そしてメッセージのシーケンス表示部３１４で確認できる。
【０１６９】
以上説明したように、第１の実施の形態では、トランザクションモデルを生成し、スイッチ１０を介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出するようにした。これにより、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。
【０１７０】
すなわち、システム分析装置１００において、ネットワークからキャプチャしたＴＣＰパケットのデータ部を解析することで、サーバで実行されるアプリケーション間での通信を再構成する。そして、システム分析装置１００は、再構成されたプロトコルログから、処理間の呼出関係が確実に存在するメッセージ集合を選択し、ユーザのリクエストに対する一連の処理の結びつきであるトランザクションが抽出できる。そして、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することにより、性能問題やボトルネックを迅速に把握することが可能となる。
【０１７１】
しかも、第１の実施の形態は、外部観測によってトランザクションを抽出している。そのため、既存システムへの機能追加を行う必要がなく、サーバ内のアプリケーションへの改変等を行わずに済む。
【０１７２】
［第２の実施の形態］
第２の実施の形態は、処理時間帯が他のトランザクションと重なるようなトランザクションであっても、そのトランザクションを構成するメッセージを抽出し、トランザクションモデルを生成できるようにしたものである。
【０１７３】
すなわち、第１の実施の形態では、各処理が他の処理（リクエストからレスポンスまで）とオーバラップすることない（すなわち多重度１である）部分のみを抜き出して、トランザクションモデルを獲得していた。この処理は、例えば対象システムの運用を一時停止し、モデル獲得のためにのみ動作させることが可能な場合には有効である。
【０１７４】
ところが、２４時間サービスを行っているため運用停止ができず、かつほとんどの場合に複数の処理を同時並行的に処理しているシステムの場合、第１の実施の形態を適用するのは困難となる。また、処理の多重度が低くシステムへの負荷が軽い場合と、多重度が高く負荷も重い場合とで挙動が異なる場合には、多重度１の場合からだけトランザクションモデルを生成したのでは不十分である。そのため、対象システムによっては多重度が高い部分も利用してトランザクションモデルを生成することも必要になる。以下でその動作例を示す。
【０１７５】
なお、第２の実施の形態におけるシステム分析装置の機能ブロックは、図４に示した第１の実施の形態と同様である。そこで、図４に示した各要素を用いて、第２の実施の形態の処理を説明する。また、第１の実施の形態と第２の形態とは、モデル生成部１４０の処理のみが相違し、他の要素の処理は同じである。さらに、説明を簡単にするため、アプリケーションサーバ３２とＤＢサーバ３３とで完結するトランザクションの例を用いて、第２の実施の形態を説明する。すなわち、ＩＩＯＰのメッセージとＤＢのメッセージとの関係から、トランザクションモデルとして生成する。
【０１７６】
図４０は、分析部へ入力されるメッセージの例を示す図である。プロトコルログ記憶部１１２に格納されたプロトコルログ４０１〜４２０が、モデル生成部１４０に入力される。
【０１７７】
モデル生成部１４０は、所定の制約条件に従って、プロトコルログに示されるメッセージを解析する。
図４１は、モデル生成部に入力されたメッセージから認識される処理を示す図である。すなわち、モデル生成部１４０は、図４０のプロトコルログ４０１〜４２０で示されるメッセージから各処理の開始と終了を抽出し、その処理期間を時系列に並べる。その結果が、図４１に示されている。
【０１７８】
処理Ｐ１は、プロトコルログ４０１，４１０で示される識別番号＝１のＩＩＯＰのメッセージから認識される処理である。処理Ｐ２は、プロトコルログ４０３，４１３で示される識別番号＝２のＩＩＯＰのメッセージから認識される処理である。処理Ｐ３は、プロトコルログ４０７，４１９で示される識別番号＝３のＩＩＯＰのメッセージから認識される処理である。処理Ｐ４は、プロトコルログ４１１，４２０で示される識別番号＝４のＩＩＯＰのメッセージから認識される処理である。
【０１７９】
処理Ｐ５は、プロトコルログ４０２，４０５で示される識別番号＝１のＤＢのメッセージから認識される処理である。処理Ｐ６は、プロトコルログ４０４，４０６で示される識別番号＝２のＤＢのメッセージから認識される処理である。処理Ｐ７は、プロトコルログ４０９，４１２で示される識別番号＝４のＤＢのメッセージから認識される処理である。処理Ｐ８は、プロトコルログ４０８，４１４で示される識別番号＝３のＤＢのメッセージから認識される処理である。処理Ｐ９は、プロトコルログ４１５，４１７で示される識別番号＝５のＤＢのメッセージから認識される処理である。処理Ｐ１０は、プロトコルログ４１６，４１８で示される識別番号＝６のＤＢのメッセージから認識される処理である。
【０１８０】
なお、この例ではＩＩＯＰで２種類、ＤＢで２種類の処理が現れるが、以下では記述を簡単にするために以下のように略すこととする。
ＩＩＯＰによるMbalance：種別Ａ
ＩＩＯＰによるMdeposit：種別Ｂ
ＤＢによるFetch->Account：種別ａ
ＤＢによるUpdate->Account：種別ｂ
また、モデル中の各処理種別毎の処理時間の求め方は第１の実施の形態と同じなので、ここではモデル中の処理種別間の呼出関係のみに着目し、処理時間に関する説明は省くものとする。
【０１８１】
第２の実施の形態における制約条件は、以下の通りである。
第１の制約：ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。
【０１８２】
第２の制約：ＩＩＯＰの処理は、直接システム外部（例えば、クライアント２１）から呼び出される。
第３の制約：ＤＢの処理は、必ずＩＩＯＰから呼び出される。
【０１８３】
第１の制約は、呼出関係に関する基本的な制約で処理Ｘが処理Ｙを呼び出した場合には、ＹはＸより後に開始されＸより前に終了しなければならないことを要求している。なお、場合によってはＸの開始（終了）とＹの開始（終了）時刻の差の上限値や下限値を与える場合もある。多くのシステムではこのような制約が成立しており、これを利用することで呼出関係の候補を減らすことができる。
【０１８４】
第２の制約は、階層的な構成のシステムでは一般的な制約で、上位（利用者側の）の処理が下位の処理を呼び出すが、逆はないことを表す。この場合には、監視対象のシステムの外部からＩＩＯＰの処理が呼び出され、そこからＤＢの処理が呼び出されることを表している。これ以外の呼び出し、例えばＩＩＯＰの処理が他のＩＩＯＰの処理を呼び出したり、ＤＢの処理がＩＩＯＰの処理を呼び出したりすることはない。
【０１８５】
このほかにも、例えばあるＩＩＯＰの処理はＤＢの処理を最低１回呼び出す、というような処理種別やそのグループ間の呼出回数やその順序に関する制約等、監視をする側が持つシステムに関する知識を制約として入力する。
【０１８６】
図４２は、制約を満たす処理間の呼出関係を示す図である。第１〜第３の制約を使うと、ある処理から呼び出し可能な他の処理が限定される。すなわち、どのＩＩＯＰ処理からどのＤＢ処理が呼び出され得るかが示されている（これ以外の呼び出しは制約を満足しない）。
【０１８７】
例えばＤＢによる処理Ｐ５を呼び出し得るのは、第１の制約から処理期間が処理Ｐ５のそれを含む処理でなければならず、この例ではＩＩＯＰによる処理Ｐ１のみである。一方処理Ｐ７の呼び出し元については、第１の制約を満足する処理は、処理Ｐ２，Ｐ３，Ｐ８の３個ある。このうち処理Ｐ８はＤＢの処理であり、第２の制約および第３の制約から同じＤＢの処理である処理Ｐ７を呼び出すことはありえないことが分かる。よって、処理Ｐ８を呼び出している候補は処理Ｐ２と処理Ｐ３の２つになる。
【０１８８】
次に、これらの呼出関係の候補から、処理種別毎に、他の種別の呼出回数を計算する。以下では処理種別ｉから処理種別ｊの呼出回数をＭ（ｉ，ｊ）と記述し、Ｍを呼出回数行列と呼ぶ。
【０１８９】
まず初めに、モデル生成部１４０は、呼出回数行列を初期化する。初期化は、呼出関係の制約を満足する要素を１、それ以外を０とする。
図４３は、呼出回数行列の例を示す図である。この例では、４種類の処理があるため、呼出回数行列は１６の要素をもつが、ＩＩＯＰからＤＢへの呼び出しだけが制約で許されるので１、それ以外の１２個は０となる。これは、制約上許される呼び出しは、他の情報がない限り、同じだけの頻度（確率）で起こるとみなすことを意味する。
【０１９０】
次に呼出回数行列を使って、図４２中の呼び出し候補の確率を計算する。例えば、処理Ｐ５の呼び出し元の可能性は処理Ｐ１しかないので、処理Ｐ１から処理Ｐ５への呼び出しの確率は１である。
【０１９１】
一方処理Ｐ６（種別ａ）への呼び出しは、処理Ｐ１（種別Ａ）からの呼び出しと処理Ｐ２（種別Ｂ）からの呼び出しの２つの可能性が考えられる。そのような場合には、呼び出し元（の候補）の処理種別から呼び出し先（この場合は処理Ｐ６）の種別への呼出回数行列要素の値に比例した確率を割り当てる。この場合は、処理Ｐ１が属する種別Ａの処理からの、処理Ｐ６が属する種別ａの処理への回数は１回（図４３参照）、処理Ｐ２が属する種別Ｂからの呼出回数も１回であるので、それぞれの呼び出し候補の確率は共に１／２となる。
【０１９２】
以下、モデル生成部１４０は、同様に各呼び出し候補の確率を求める。
図４４は、呼び出し候補の確率を求めた結果を示す図である。図４３に示す呼出回数行列では、制約を満足する呼出関係を示す各要素の値は、全て１である。そのため、複数の呼び出し可能性を持つ場合、それぞれの呼び出し可能性は等しくなる（確率が１／２）。
【０１９３】
次に、モデル生成部１４０は、上記の確率を使って、呼出回数行列の値を更新する。すなわち、処理種別ＸからＹへの呼出回数は、図４３中の呼び出し候補のなかで、ＸからＹへの呼び出し候補の確率の和を、処理種別Ｘの発生回数で割ったものとして計算できる。
【０１９４】
例えば種別Ａから種別ａへの呼び出し候補は、処理Ｐ１から処理Ｐ５、処理Ｐ１から処理Ｐ６、処理Ｐ４から処理Ｐ１０の３個あり、その確率はそれぞれ、１、１／２、１／２である。このことと、種別Ａの処理が、処理Ｐ１および処理Ｐ４の２個であることから、呼出回数行列の要素Ｍ（Ａ，ａ）の値は、
（１＋１／２＋１／２）／２＝１
となる。同様に、モデル生成部１４０は、他の行列要素も計算する。
【０１９５】
図４５は、更新後の呼出回数行列を示す図である。ただし呼び出し行列のうち、制約上ゆるされない要素の値は常に０であるので、制約上許される要素、すなわちＩＩＯＰの処理種別からＤＢの処理種別への呼び出しに対応する要素のみを示す。
【０１９６】
以上の、呼出回数行列を使った呼び出し候補の確率計算と、それに基づく呼出回数行列の更新を、所定の終了条件を満足するまで繰り返す。所定の終了条件とは、例えば、更新回数が予め設定された回数に達することである。また、別の終了条件としては、更新前後の行列要素の変化量が、予め設定された上限値以下となることである。
【０１９７】
本実施の形態では、終了条件が、更新回数２回であるものとする。すなわち、モデル生成部１４０は、図４４に示した状態からもう一度呼出回数のカウントと行列要素の計算を行う。２回目以降の処理においても、各呼び出し候補の確率計算の方法は１回目の処理と同じである。ただし、確率計算のもとになる呼出回数行列は図４５で示す内容であり、上で求めた図４３とは異なるので、計算される確率も異なる。
【０１９８】
例えば、処理Ｐ９（種別ｂ）に対する呼び出し候補は、処理Ｐ３（種別Ｂ）からの呼び出しと処理Ｐ４（種別Ａ）からの２つがある。図４５に示す呼出回数行列では、種別Ｂから種別ｂへの呼出回数は３／４回、種別Ａから種別ｂへの呼び出しは１／４回である。これに比例するように確率を割り振ると、処理Ｐ３から処理Ｐ９への呼び出しの確率は３／４、処理Ｐ４から処理Ｐ９への呼び出しの確率は１／４となる（処理Ｐ９は処理Ｐ３か処理Ｐ４のいずれか一方から呼び出されるので、２つの確率の和は１になることに注意）。
【０１９９】
以下、モデル生成部１４０は、同様に各呼び出し候補の確率を求める。
図４６は、２回目の処理で呼び出し候補の確率を求めた結果を示す図である。このように、複数の呼び出し可能性を持つ場合には、呼出回数の予測値を重みとして確率が計算される。このような呼び出し候補の確率に基づいて、呼出回数行列が更新される。
【０２００】
図４７は、２回目の更新後の呼出回数行列を示す図である。呼出回数の計算方法は、１回目と同じである。これで呼出回数行列の更新は２回行われたので、確率計算／更新処理が終了して次のステップに進む。
【０２０１】
次に、呼出回数行列の要素のなかで整数以外の部分を四捨五入などにより整数にまるめる。図４７では種別Ａから種別ｂへの呼出回数が１／８回なのでこれを０とし、種別Ｂから種別ｂへの呼出回数は７／８なので、これを１回とする。これら以外は値が整数なので変更されない。
【０２０２】
図４８は、最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。モデル生成部１４０は、図４８に示すように整数化された呼出回数行列から、処理種別間の呼出関係を表すトランザクションモデルを獲得する。すなわち、呼出回数行列から、ＩＩＯＰ処理種別Ａは、ＤＢの処理種別ａを１回呼び出し、ＩＩＯＰの種別ＢはＤＢの処理種別ａと処理種別ｂとをそれぞれ１回ずつ呼び出すことが分かる。
【０２０３】
すなわち、呼出回数行列で１と設定されている呼出関係が、生起確率の高い関係である。そこで、モデル生成部１４０は、呼出回数行列で１が設定されている呼出関係から認識されるトランザクションモデル４３１，４３２を生成し、モデル記憶部１１３に格納する。
【０２０４】
以上の処理手順を整理すると以下のようになる。
図４９は、第２の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図４９に示す処理をステップ番号に沿って説明する。
【０２０５】
［ステップＳ７１］モデル生成部１４０は、プロトコルログから各処理の開始と終了のペアを抽出する。
［ステップＳ７２］モデル生成部１４０は、呼出回数行列を初期化する。この際、制約を満足しない呼出関係は、０に初期化される。
【０２０６】
［ステップＳ７３］モデル生成部１４０は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
［ステップＳ７４］モデル生成部１４０は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップＳ７７に進められる。終了条件を満足していない場合、処理がステップＳ７５に進められる。
【０２０７】
［ステップＳ７５］モデル生成部１４０は、呼出関係候補それぞれの生起確率を、呼出回数行列の値に比例するように計算する。
［ステップＳ７６］モデル生成部１４０は、各呼出関係候補の確率を呼び出し元と呼び出し先との処理種別毎に平均をとり、呼出回数行列を更新する。その後、処理がステップＳ７４に進められる。
【０２０８】
［ステップＳ７７］終了条件を満足した場合、モデル生成部１４０は、呼出回数行列を整数で近似する。
［ステップＳ７８］モデル生成部１４０は、呼出回数行列のゼロ以外の成分を処理種別毎の呼出回数とするトランザクションモデルを出力する。
【０２０９】
以上のように、第２の実施の形態では、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合して、処理間の呼出関係の可能性を算出するようにした。これにより、複数のトランザクションが同時に処理されている場合であっても、モデルを生成することができる。しかも、比較的少ない計算量でモデルを生成できる。
【０２１０】
［第３の実施の形態］
上記第２の実施の形態に示す方法では、処理種別間の呼出回数の平均を使っている。そのため、例えば確率１／２で２回呼び出している状況と確率１で１回呼び出している状況を区別できず、結果として正しいトランザクションモデルを学習できない場合もあり得る。このような状況は、例えば、ある処理種別からの呼出パターンが複数ある場合に発生し得る。これを解決するためには、呼出関係の候補として個々の処理種別間の関係を求めるのではなく、ある処理種別が呼び出す全ての処理の集合や集合内の順序を対象に確率を求めればよい。以下では、この考え方に基づくモデル生成方法を第３の実施の形態として説明する。
【０２１１】
なお、第３の実施の形態におけるシステム分析装置の機能ブロックは、図４に示した第１の実施の形態と同様である。そこで、図４に示した各要素を用いて、第３の実施の形態の処理を説明する。また、第１の実施の形態と第３の形態とは、モデル生成部１４０の処理のみが相違し、他の要素の処理は同じである。
【０２１２】
モデル生成部１４０の入力は、同じく図４０のメッセージ列および制約であるとする。
モデル生成部１４０は、まず初めに、第２の実施の形態と同様に各処理間で可能な呼出関係を求める。結果は図４２に示す通りである。
【０２１３】
次に、図４２に示した可能な呼出関係を元に、各処理が呼び出している処理の集合とそのなかでの順序の候補を求める。例えば、処理Ｐ１が呼び出している処理の順序付きの集合の候補（以下処理集合候補と呼ぶ）は次のように求める。
【０２１４】
図４２に示す呼出関係を解析すると、集合Ｕに含まれる（すなわち処理Ｐ１から呼び出されている）可能性があるのは、処理Ｐ５と処理Ｐ６の２つの処理である。このうち処理Ｐ５は、他に呼び出し元の候補はないので、かならず集合Ｕ含まれる。一方処理Ｐ６は、処理Ｐ２から呼び出されている可能性があるので、集合Ｕに含まれる可能性と含まれない可能性の両方が考えられる。処理Ｐ５と処理Ｐ６では処理Ｐ５のほうが早く開始しているので、集合Ｕの候補は次の２つである。
Ｕ１１：｛処理Ｐ５｝
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝
なお、集合及び処理集合候補の記述では、呼び出されるのが早い処理から順に左から記述するものとする。この段階では、この２つの候補のどちらが信頼できるかに関する判断材料が全くないため、信頼度は両者同じ、すなわち、１／２とする。
【０２１５】
次に、処理集合候補Ｕ１１，Ｕ１２を処理種別による記述に変換し、処理Ｐ１から呼び出される処理のパターン、すなわち呼び出される処理種別の順序付き集合の候補を生成する。処理Ｐ５および処理Ｐ６の処理種別はどちらもａであるので、以下のようになる。
Ｕ１１：パターン｛ａ｝
Ｕ１２：パターン｛ａ，ａ｝
後者の処理集合候補Ｕ１２は、処理Ｐ１が同じ処理種別の処理を２回連続して呼び出している可能性を表している。
【０２１６】
次に、パターンの信頼度を、そのパターンの元になった処理集合の信頼度から計算する。この場合は処理集合候補Ｕ１１、処理集合候補Ｕ１２から異なるパターンが生成されているので、各パターンの信頼度は処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度をそのまま用いる。すなわち１／２とする。
【０２１７】
以上から、処理Ｐ１が呼び出しているパターンの候補とその信頼度は次のようになる。
パターン｛ａ｝：信頼度１／２
パターン｛ａ，ａ｝：信頼度１／２
２番目のパターンは種別ａの処理が２回呼び出されるパターンを示している。モデル生成部１４０は、他の処理についても、その処理が呼び出している処理種別のパターンの候補と信頼度を同様にして求める。
【０２１８】
処理Ｐ２から呼び出される可能性があるのは処理Ｐ６と処理Ｐ７の２つであり、この両者とも他の処理から呼び出されている可能性があるので、処理Ｐ２から呼び出されている処理集合候補は次の４通りである。処理Ｐ１の場合と同様、この段階ではこれら全ての信頼度が同じ、すなわち１／４であるとする。
Ｕ２１：｛｝
Ｕ２２：｛処理Ｐ６｝
Ｕ２３：｛処理Ｐ７｝
Ｕ２４：｛処理Ｐ６，処理Ｐ７｝
処理Ｐ６および７の種別はそれぞれａとｂであるから、処理Ｐ２が呼び出している処理種別のパターンの候補とその信頼度は次のようになる。
パターン｛｝：信頼度１／４
パターン｛ａ｝：信頼度１／４
パターン｛ｂ｝：信頼度１／４
パターン｛ａ，ｂ｝：信頼度１／４
最後のパターンは、ａとｂがこの順序で、すなわち最初に種別ａの処理が呼び出され、その後にｂの処理が呼び出されるパターンを表している。なお、順序を考慮せず、呼び出される処理種別毎の回数をパターンとすることもできる。
【０２１９】
処理Ｐ３に関しては注意が必要である。処理Ｐ３からかならず呼び出されているのは処理Ｐ８、処理Ｐ３から呼び出されている可能性はあるが、他の処理から呼び出されている可能性もある処理が、処理Ｐ７、処理Ｐ９、処理Ｐ１０の３個であるから、処理Ｐ３が呼び出している処理集合候補は、
｛処理Ｐ８｝
｛処理Ｐ８，処理Ｐ７｝
｛処理Ｐ８，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝
の８個で、それぞれの信頼度は１／８となる。ここからパターンとその信頼度が計算される。
【０２２０】
ところが、処理Ｐ７と処理Ｐ９が共に種別ｂの処理であることから、｛処理Ｐ８，処理Ｐ７｝と｛処理Ｐ８，処理Ｐ９｝からは同一のパターン｛ａ，ｂ｝が生成される。同様に｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝と｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝からはパターン｛ａ，ｂ，ａ｝が生成される。このような場合には、これらのパターンの信頼度は、対応する処理集合候補の信頼度の和をとることで計算する。よって結果は次のようになる。
パターン｛ａ｝：信頼度１／８
パターン｛ａ，ｂ｝：信頼度１／４
パターン｛ａ，ａ｝：信頼度１／８
パターン｛ａ，ｂ，ｂ｝：信頼度１／８
パターン｛ａ，ｂ，ａ｝：信頼度１／４
パターン｛ａ，ｂ，ｂ，ａ｝：信頼度１／８
処理Ｐ４についてもパターンとその信頼度を求めると次のようになる。
パターン｛｝：信頼度１／４
パターン｛ｂ｝：信頼度１／４
パターン｛ａ｝：信頼度１／４
パターン｛ｂ，ａ｝：信頼度１／４
次に、上で求めた各処理から呼び出される処理種別のパターンとその信頼度を、呼び出し元の処理種別毎に平均をとることで、処理種別毎に、それから呼び出されるパターンとその確率を計算する。
【０２２１】
まず、処理種別Ａに属するのは処理Ｐ１と処理Ｐ４であるから、これらの処理から呼び出されているパターン候補の信頼度の平均を計算する。例えばパターン｛ａ｝は、処理Ｐ１では信頼度１／２、処理Ｐ４では信頼度１／４であるので、処理種別Aからこのパターンが呼び出される確率は、その平均、すなわち３／８となる。一方パターン｛ａ，ａ｝は、処理Ｐ１では信頼度１／２であるが、処理Ｐ４ではパターン候補中に存在しない、すなわち信頼度０であるので、確率は１／４になる。
【０２２２】
図５０は、処理種別Ａからの呼出パターンとその確率を示す第１の図である。図５０に示すように、パターンＡ１｛｝の確率は、（０＋１／４）／２＝１／８である。パターンＡ２｛ｂ｝の確率は（０＋１／４）／２＝１／８である。パターンＡ３｛ａ｝の確率は、（１／２＋１／４）／２＝３／８である。パターンＡ４｛ａ，ａ｝の確率は、（１／２＋０）／２＝１／４である。パターンＡ５｛ｂ，ａ｝の確率は（０＋１／４）／２＝１／８である。
【０２２３】
同様に処理種別Ｂに属する処理、すなわち処理Ｐ２および処理Ｐ３の平均をとると、処理種別Ｂから呼び出されるパターンとその確率を以下のように計算される。
図５１は、処理種別Ｂからの呼出パターンとその確率を示す第１の図である。図５１に示すように、パターンＢ１｛｝の確率は、（１／４＋０）／２＝１／８である。パターンＢ２｛ａ｝の確率は、（１／４＋１／８）／２＝３／１６である。パターンＢ３｛ｂ｝の確率は、（１／４＋０）／２＝１／８である。パターンＢ４｛ａ，ｂ｝の確率は、（１／４＋１／４）／２＝１／４である。パターンＢ５｛ａ，ａ｝の確率は、（０＋１／８）／２＝１／１６である。パターンＢ６｛ａ，ｂ，ｂ｝の確率は、（０＋１／８）／２＝１／１６である。パターンＢ７｛ａ，ｂ，ａ｝の確率は、（０＋１／４）／２＝１／８である。パターンＢ８｛ａ，ｂ，ｂ，ａ｝の確率は、（０＋１／８）／２＝１／１６である。
【０２２４】
次にこれの処理種別毎の呼び出されるパターンとその確率を使って、もう一度各処理から呼び出される処理の集合の候補（処理集合候補）とその信頼度を計算しなおす。
まず、処理Ｐ１について考える。
処理Ｐ１で可能な呼び出し処理集合候補が
Ｕ１１：｛処理Ｐ５｝
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝
であるのは同じである。ただし前回はどちらがよりもっともらしいかを判断する材料がなかったため信頼度を同じにしたが、今回は判断材料として図５０および図５１に示した処理種別毎の呼出パターンの信頼度を使うことができる。
【０２２５】
ただし、処理集合候補Ｕ１１と処理集合候補Ｕ１２の信頼度は、処理Ｐ１からの呼出パターンの確率だけではなく、このどちらかを選択するかによって呼び出し候補が影響される他の処理も考慮する必要がある。
【０２２６】
処理集合候補Ｕ１１と処理集合候補Ｕ１２の差は処理Ｐ６が処理Ｐ１からよびだされているかどうかである。処理Ｐ６は処理Ｐ１または処理Ｐ２から呼び出されているから、例えば処理集合候補Ｕ１１を選択するということは、単に処理Ｐ１から処理Ｐ６が呼び出されないことだけの選択ではなく、処理Ｐ２から処理Ｐ６が呼び出されている、という選択でもある。よって処理集合候補Ｕ１１の信頼度を計算する際には、それによって処理Ｐ２からの呼び出しの選択がどれだけ制限されるかを考慮する必要がある。
【０２２７】
処理集合候補Ｕ１１となる場合、処理Ｐ１（種別Ａ）からの呼出パターンはＡ３であり、このパターンの確率は３／８である。一方、処理集合候補Ｕ１２の場合はパターンＡ４であるから確率は１／４である。ただし処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度はこれらの確率をそのまま使うのではなく、それによって他の処理からの呼出パターンがどのように制限されるかを考慮する。
【０２２８】
すなわち、例えば処理Ｐ１からの呼び出しが処理集合候補Ｕ１１の場合、処理Ｐ６は処理Ｐ１から呼ばれないことになる。そのため、他の候補、すなわち処理Ｐ２からかならず呼ばれることになる。よって処理Ｐ２から呼び出される処理の集合は｛処理Ｐ６｝または｛処理Ｐ６，処理Ｐ７｝でなければならない。
【０２２９】
処理Ｐ６および処理Ｐ７の種別はａおよびｂであるから、処理種別のパターンでいうとＢ２またはＢ４であり、確率はそれぞれ３／１６および１／４である。よって処理集合候補Ｕ１１の信頼度は、処理Ｐ２側の確率はこれらの確率の和、すなわち７／１６と見積もることができる。これを使って、処理集合候補Ｕ１１の信頼度は、処理Ｐ１側で処理集合候補Ｕ１１が呼び出される確率３／８と処理Ｐ２側の制限からくる確率７／１６の積、すなわち２１／１２８とする。
【０２３０】
一方、処理集合候補Ｕ１２の場合には、処理Ｐ６は処理Ｐ１から呼び出されているので、処理Ｐ２側の呼び出される処理の集合の候補は｛｝または｛処理Ｐ７｝のいずれか、処理種別のパターンではＢ１またはＢ３である。これらの確率は共に１／８であるので、処理集合候補Ｕ１２の信頼度は１／４×（１／８＋１／８）＝１／１６＝８／１２８となる。
【０２３１】
処理集合候補Ｕ１１および処理集合候補Ｕ１２のいずれかはかならず正しいので、両者の信頼度の和が１になるように正規化を行い、最終的に処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度を
Ｕ１１：｛処理Ｐ５｝信頼度２１／２９
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝ 信頼度８／２９
とする。すなわち処理集合候補Ｕ１１のほうがもっともらしいと判断される。
【０２３２】
次にこれを上と同様に処理種別のパターンとその信頼度に変換する。
パターン｛ａ｝：信頼度２１／２９
パターン｛ａ，ａ｝：信頼度８／２９
処理Ｐ２、処理Ｐ３、処理Ｐ４についても処理Ｐ１の場合と全く同様にして可能な呼び出し処理集合の候補の信頼度を計算し、そこから呼び出し種別のパターン毎の信頼度を計算する。以下にその結果を示す。
【０２３３】
処理Ｐ２については、以下の通りである。
パターン｛｝：信頼度４／３３
パターン｛ａ｝：信頼度９／３３
パターン｛ｂ｝：信頼度５／３３
パターン｛ａ，ｂ｝：信頼度１５／３３
処理Ｐ３については、以下の通りである。
パターン｛ａ｝：信頼度１８／１０１
パターン｛ａ，ｂ｝：信頼度４６／１０１
パターン｛ａ，ａ｝：信頼度６／１０１
パターン｛ａ，ｂ，ｂ｝：信頼度１５／１０１
パターン｛ａ，ｂ，ａ｝：信頼度１１／１０１
パターン｛ａ，ｂ，ｂ，ａ｝：信頼度５／１０１
処理Ｐ４については、以下の通りである。
パターン｛｝：信頼度３／２８
パターン｛ｂ｝：信頼度３／２８
パターン｛ａ｝：信頼度１５／２８
パターン｛ｂ，ａ｝：信頼度７／２８
次に、前と同様にこれらの呼び出し元の処理毎の呼出パターンの信頼度から、処理種別毎の呼出パターンとその確率を、呼び出し元の処理種別毎に平均をとることで求める。
【０２３４】
図５２は、処理種別Ａからの呼出パターンとその確率を示す第２の図である。図５２に示すように、パターンＡ１：｛｝の確率は８７／１６２４＝０．０５４である。パターンＡ２：｛ｂ｝の確率８７／１６２４＝０．０５４である。パターンＡ３：｛ａ｝の確率は１０２３／１６２４＝０．６３０である。パターンＡ４：｛ａ，ａ｝の確率は２２４／１６２４＝０．１３８である。パターンＡ５：｛ｂ，ａ｝の確率は２０３／１６２４＝０．１２５である。
【０２３５】
同様に処理種別Ｂに属する処理、すなわち処理Ｐ２および処理Ｐ３の平均をとると、処理種別Ｂから呼び出されるパターンとその確率を以下のように計算される。
図５３は、処理種別Ｂからの呼出パターンとその確率を示す第２の図である。図５３に示すように、パターンＢ１：｛｝の確率は４０４／６６６６＝０．０６１である。パターンＢ２：｛ａ｝の確率は１５０３／６６６６＝０．２２５である。パターンＢ３：｛ｂ｝の確率は５０５／６６６６＝０．０７６である。パターンＢ４：｛ａ，ｂ｝の確率は３０３３／６６６６＝０．４５５である。パターンＢ５：｛ａ，ａ｝の確率は１９８／６６６６＝０．０３０である。パターンＢ６：｛ａ，ｂ，ｂ｝の確率は４９５／６６６６＝０．０７４である。パターンＢ７：｛ａ，ｂ，ａ｝の確率は３６３／６６６６＝０．０５４である。パターンＢ８：｛ａ，ｂ，ｂ，ａ｝の確率は１６５／６６６６＝０．０２５である。
【０２３６】
この処理毎の呼び出す処理の集合とその信頼度の計算およびそれから処理種別毎の呼出パターンやその確率の計算を適当な終了条件が満足するまで行う。終了条件は、第２の実施の形態と同様、繰り返し回数や、パターン毎の確率の変化量の上限等で行う。
【０２３７】
図５２、図５３に示した状態で終了条件が満足されると、モデル生成部１４０は、図５２および図５３の呼出パターンとその確率から、モデルを生成する。このとき、あまり確率の小さいモデルは信頼性にかける。そのため、呼び出し元の処理種別毎に、可能なパターンの中から確率の高い順に、選択数の上限および確率の下限を使ってモデルとして採用するパターンを選択する。
【０２３８】
例えば選択数の上限を２、確率の下限を０．１とすると、呼出元の処理種別Ａに対してはパターンＡ３とパターンＡ４が、処理種別Ｂに対してはパターンＢ４とＢ２がモデルとして選択される。最終的なモデルは、選択されたパターンのみを使って確率の和が１となるように正規化しなおして生成される。
【０２３９】
図５４は、モデル生成結果を示す図である。ＩＩＯＰの種別Ａに対しては、２つのトランザクションモデル４４１，４４２が生成されている。トランザクションモデル４４１の確率は、０．８２（＝０．６３０／（０．６３０＋０．１３８））であり、トランザクションモデル４４２の確率は、０．１８（＝０．１３８／（０．６３０＋０．１３８））である。
【０２４０】
ＩＩＯＰの種別Ｂに対しては、２つのトランザクションモデル４４３，４４４が生成されている。トランザクションモデル４４３の確率は、０．８０（＝０．５７４／（０．５７４＋０．１４２））であり、トランザクションモデル４４４の確率は、０．２０（＝０．１４２／（０．５７４＋０．１４２））である。
【０２４１】
以上の処理手順を整理すると以下のようになる。
図５５は、第３の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図５５に示す処理をステップ番号に沿って説明する。
【０２４２】
［ステップＳ８１］モデル生成部１４０は、プロトコルログから各処理の開始と終了のペアを抽出する。
［ステップＳ８２］モデル生成部１４０は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
【０２４３】
［ステップＳ８３］モデル生成部１４０は、処理毎に、それを呼び出し元とする呼出関係の候補から、呼び出されている処理の集合（呼出先処理集合）の候補を生成する。
［ステップＳ８４］モデル生成部１４０は、呼出先処理集合の生起確率を初期化する（呼出元の処理毎に均等に確率を割り当てる）。
【０２４４】
［ステップＳ８５］モデル生成部１４０は、呼出先処理集合とその確率から、処理種別による呼出パターンとその確率を計算する。
［ステップＳ８６］モデル生成部１４０は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップＳ８８に進められる。終了条件を満足していない場合、処理がステップＳ８７に進められる。
【０２４５】
［ステップＳ８７］モデル生成部１４０は、呼出先処理集合の候補それぞれの生起確率を、処理種別毎の呼出パターンとその確率から再計算する。その後、処理がステップＳ８５に進められる。
【０２４６】
［ステップＳ８８］終了条件を満足した場合、モデル生成部１４０は、処理種別毎の呼出パターンのうち、所定の条件を満たしたもの（例えば、所定の値より確率の高いもの）をトランザクションモデルとして選択する。
【０２４７】
［ステップＳ８９］モデル生成部１４０は、呼出元の種別毎に、選択されたモデルの確率を正規化する。その後、処理が終了する。
このように第３の実施の形態では、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、発生パターン毎に生起確率を計算する。そして、生起確率が上位の発生パターンを所定の個数選択し、選択された発生パターンに基づいて、トランザクションモデルを生成するようにした。これにより、ある呼出元の処理種別について可能な処理パターンが複数ある場合でも、そのモデルを正しく生成することができる。
【０２４８】
なお、この方法では、多重度が高い場合、処理量が非常に増大する。そこで、以下のような方法で、処理量の軽減を図ることもできる。
第３の実施の形態では処理種別毎に呼び出すパターンとその確率を何度か更新していくことでトランザクションモデルを生成している。そして、最終的に得られたパターンから可能性の低いパターンを除去している。このとき、パターンとその確率の更新の際に、その都度可能性の低いパターンを除去することも可能である。一度除去した呼出パターンは、以後のモデル生成処理中に可能性として考慮する必要がないため、モデル生成の早期に除去することで、モデル生成に要する時間を短縮することができる。
【０２４９】
例えば、図５０および図５１が生成された段階で、すなわち最初に可能なパターンとその確率が生成された段階で、確率が閾値以下となるパターンを削除する。閾値が０．１である場合、図５０に示された処理種別Ａからの呼出パターンの確率は１／８以上であるので削除されない。一方図５１に示された処理種別Ｂからの場合には、パターンＢ５、パターンＢ６、パターンＢ８の３パターンの確率が１／１６で閾値以下となるので、消去することができる。消去されたパターンは、実際の処理からこれらのパターンで処理が呼び出されることはないことを示す。
【０２５０】
これにより、以後再び可能なパターンの確率を求める際に、消去されたパターンは考慮する必要がないことを意味する。例えば種別Ｂの処理Ｐ３からの呼び出される処理の集合は上の例でも記したように
｛処理Ｐ８｝
｛処理Ｐ８，処理Ｐ７｝
｛処理Ｐ８，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝
である。処理Ｐ８と処理Ｐ１０の種別がａ、処理Ｐ７と処理Ｐ９の種別がｂであることから、これらのうち｛処理Ｐ８，処理Ｐ１０｝がパターンＢ５、｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝がパターンＢ６、｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝がパターンＢ８に属する。すなわち、これらの呼び出しは起こり得ない。よって以後の処理でこれらの呼び出しの発生を考慮する必要がなくなる。起こり得ないパターンを判断対象から除外することで、以降の処理量を軽減することができる。
【０２５１】
［その他の応用例］
上記各実施の形態では、スイッチ１０のミラーポートからメッセージを構成するパケットを収集しているが、各サーバ３１，３２，３３において、メッセージのダンプデータを記録しておき、そのメッセージ観測部１２０が各サーバ３１，３２，３３からダンプデータを収集してもよい。
【０２５２】
また、分析部１５０によって分析された内容に応じて、トランザクションモデルを更新することもできる。例えば、任意の種別のトランザクション内の各サーバでの処理時間が分析部１５０で求められると、種別毎の処理時間の平均を求め、対応するトランザクションモデルの処理時間とすることができる。
【０２５３】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム分析装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０２５４】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０２５５】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０２５６】
（付記１） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムにおいて、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラム。
【０２５７】
（付記２） 前記メッセージ観測手段は、前記ネットワーク内に設けられたスイッチのミラーポートを介して、前記メッセージの収集を行うことを特徴とする付記１記載のシステム分析プログラム。
【０２５８】
（付記３） 前記メッセージ観測手段は、前記サーバに保持されたメッセージのダンプデータから前記メッセージを収集することを特徴とする付記１記載のシステム分析プログラム。
【０２５９】
（付記４） 前記モデル生成手段は、前記制約条件として、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件が定義されていることを特徴とする付記１記載のシステム分析プログラム。
【０２６０】
（付記５） 前記モデル生成手段は、制約条件として、サーバ間の呼び出し方向が定義されていることを特徴とする付記１記載のシステム分析プログラム。
（付記６） 前記モデル生成手段は、同一トランザクション内の各処理種別のリクエストメッセージからレスポンスメッセージまでの時間に基づいて、各プロトコルに対応する処理の前記サーバでの所要時間を計算し、前記トランザクションモデルに設定することを特徴とする付記１記載のシステム分析プログラム。
【０２６１】
（付記７） 前記モデル生成手段は、クライアントから最初に呼び出されるリクエストメッセージと、当該リクエストメッセージに対応するレスポンスメッセージとから、各トランザクションの処理時間帯を判定し、他のトランザクションとの間で処理時間帯が重複しない非多重トランザクションを検出し、検出された前記非多重トランザクションの処理時間帯内に発生した前記プロトコルログに基づいて前記トランザクションモデルを生成することを特徴とする付記１記載のシステム分析プログラム。
【０２６２】
（付記８） 前記モデル生成手段は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合し、処理間の呼出関係の可能性を算出することを特徴とする付記１記載のシステム分析プログラム。
【０２６３】
（付記９） 前記モデル生成手段は、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、前記発生パターン毎に生起確率を計算し、前記生起確率が上位の前記発生パターンの所定の個数選択し、選択された前記発生パターンに基づいて、前記トランザクションモデルを生成することを特徴とする付記１記載のシステム分析プログラム。
【０２６４】
（付記１０） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析方法において、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
ことを特徴とするシステム分析方法。
【０２６５】
（付記１１） 複数のサーバが接続されたネットワークの運用形態を分析するためのシステム分析装置において、
前記ネットワークを介して受け渡されるメッセージを収集するメッセージ観測手段と、
収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納するメッセージ解析手段と、
モデル生成指示が入力されると、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納するモデル生成手段と、
分析指示が入力されると、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する分析手段と、
を有することを特徴とするシステム分析装置。
【０２６６】
（付記１２） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体。
【符号の説明】
【０２６７】
１ システム分析装置
１ａ メッセージ観測手段
１ｂ メッセージ解析手段
１ｃ プロトコルログ記憶手段
１ｄ モデル生成手段
１ｅ トランザクションモデル記憶手段
１ｆ 分析手段
１ｇ 出力手段
２ ネットワーク
３ａ，３ｂ，・・・ クライアント
４ａ，４ｂ，・・・ サーバ
５ メッセージ
【技術分野】
【０００１】
本発明はトランザクションを分析するための分析プログラム、分析方法及び分析装置に関する。
【背景技術】
【０００２】
最近のＩＴ（情報通信技術）を利用したコンピュータシステムは大規模かつ複雑な構成であることが多い。例えば、オンラインバンキングの入金や振込み処理など、各種業務サービスがＷｅｂサーバ／アプリケーションサーバ／データベース（ＤＢ）サーバからなるＷｅｂ３階層システムにて提供される例が増えている。こういったシステムは、業務の効率化やセキュリティ対策などの理由から大規模で複雑な構成である。また、即時性を要求される業務サービスが多く、サービス停止やレスポンス悪化は大きな問題である。そのため、大規模システムに対する運用状況の詳細な把握や性能問題の迅速な解決が必須である。
【０００３】
しかも、複数のアプリケーションが連携して動作する複雑なシステム（Ｗｅｂ３階層システムなど）で、性能劣化や障害の原因を突き止めるためには、サーバそれぞれの挙動だけでなくシステム全体としての性能を観測・分析することが必要である。例えば、Ｗｅｂ３階層システムにおいては、Ｗｅｂサーバへの処理要求に伴ってアプリケーションサーバへの処理要求が発生する場合がある。アプリケーションサーバ・ＤＢサーバ間についても同様である。こういったアプリケーション間における処理の呼出関係は、性能問題のシステム内への波及を調べる上で必須である。
【０００４】
そこで、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡する機能が望まれている。このような追跡が可能となれば、システムに存在する問題の分析が容易となる。
【０００５】
サーバ間の処理の受け渡しを追跡する技術としては、例えば、各サーバにエージェントを実装し、そのエージェントに個々のサーバの運用状況を解析及びレポートさせる技術がある（例えば、非特許文献１参照）。
【０００６】
エージェントによって運用状態を把握し、その結果をレポートする技術は実用化されている（例えば、非特許文献２，３参照）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Technical Standard Application Response Measurement(ARM) Issue4.0-C Binding」THE OPEN GROUP、２００３年１０月、Figure 2
【非特許文献２】「IBM Tivoli Monitoring for Transaction Performance helps maximize performance of your applications.」,"IBM Corporation Software Group",２００３年９月
【非特許文献３】「IBM Tivoli Monitoring for Transaction Performance, Version 5.2」,"IBM Corporation Software Group"、２００３年９月
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、従来の技術では、アプリケーション単位の詳細な情報を取得する場合には、各サーバに対してエージェント等の何らかのアプリケーションを組み込んで対応する必要がある。そのため、既存システムの性能分析が困難である。特に最近のシステムでは、アプリケーション毎に異なる企業によって作成されている。従って、全てのアプリケーションについて、エージェントとの間の情報の受け渡しを行うように改良することは困難である。
【０００９】
本発明はこのような点に鑑みてなされたものであり、システムのサービス提供機能に手を加えずにトランザクションを分析できる分析プログラム、分析方法及び分析装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明では上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、コンピュータに、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、を実行させるための分析プログラムが提供される。
【００１１】
また、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、を有する分析装置が提供される。
【００１２】
さらに、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、コンピュータが、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、分析方法が提供される。
【発明の効果】
【００１３】
本発明では、メッセージ集合からのトランザクションモデルの生成が可能となる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態に適用される発明の概念図である。
【図２】第１の実施の形態に係るシステム構成を示す図である。
【図３】システム分析装置のハードウェア構成例を示す図である。
【図４】システム分析装置の機能ブロックを示す図である。
【図５】システム分析処理の手順を示すフローチャートである。
【図６】メッセージ観測状況を示す概念図である。
【図７】パケットデータ記憶部のデータ構造例を示す図である。
【図８】パケットに含まれる情報を示す図である。
【図９】ＩＰヘッダの詳細を示す図である。
【図１０】ＴＣＰヘッダの詳細を示す図である。
【図１１】メッセージ解析部の機能を示すブロック図である。
【図１２】再構成したセッションの例である。
【図１３】メッセージ再構成例を示す第１の図である。
【図１４】リクエストへのレスポンスメッセージの対応付けの例を示す図である。
【図１５】オブジェクト名の割り当て例を示す図である。
【図１６】１つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。
【図１７】プロトコルログの例を示す図である。
【図１８】プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。
【図１９】トランザクションモデル生成処理を示すフローチャートである。
【図２０】選択されるモデル生成用メッセージを示す図である。
【図２１】「残高確認」トランザクションのモデル生成例を示す図である。
【図２２】「入金」トランザクションのモデル生成例を示す図である。
【図２３】分析処理の手順を示すフローチャートである。
【図２４】分析部へ入力されるメッセージの例を示す図である。
【図２５】メッセージ分析例を示す第１の図である。
【図２６】メッセージ分析例を示す第２の図である。
【図２７】メッセージ分析例を示す第３の図である。
【図２８】メッセージ分析例を示す第４の図である。
【図２９】メッセージ分析例を示す第５の図である。
【図３０】メッセージ分析例を示す第６の図である。
【図３１】メッセージ分析例を示す第７の図である。
【図３２】メッセージ分析例を示す第８の図である。
【図３３】メッセージ分析例を示す第９の図である。
【図３４】メッセージ分析例を示す第１０の図である。
【図３５】サーバの平均処理時間の表示例を示す図である。
【図３６】トランザクション別処理時間及び内訳の表示例を示す図である。
【図３７】処理時間ヒストグラムの表示例を示す図である。
【図３８】複数の情報を同時に表示した場合の画面例を示す図である。
【図３９】表示対象要素間の連携の様子を示す図である。
【図４０】分析部へ入力されるメッセージの例を示す図である。
【図４１】モデル生成部に入力されたメッセージから認識される処理を示す図である。
【図４２】制約を満たす処理間の呼出関係を示す図である。
【図４３】呼出回数行列の例を示す図である。
【図４４】呼び出し候補の確率を求めた結果を示す図である。
【図４５】更新後の呼出回数行列を示す図である。
【図４６】２回目の処理で呼び出し候補の確率を求めた結果を示す図である。
【図４７】２回目の更新後の呼出回数行列を示す図である。
【図４８】最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。
【図４９】第２の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【図５０】処理種別Ａからの呼出パターンとその確率を示す第１の図である。
【図５１】処理種別Ｂからの呼出パターンとその確率を示す第１の図である。
【図５２】処理種別Ａからの呼出パターンとその確率を示す第２の図である。
【図５３】処理種別Ｂからの呼出パターンとその確率を示す第２の図である。
【図５４】モデル生成結果を示す図である。
【図５５】第３の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【００１６】
図１は、実施の形態に適用される発明の概念図である。システム分析装置１は、ネットワーク２を介してクライアント３ａ，３ｂ，・・・やサーバ４ａ，４ｂ，・・・に接続されている。サーバ４ａ，４ｂ，・・・は、クライアント３ａ，３ｂ，・・・からの要求に応じてサービスを提供する。サービスの提供は、複数のサーバ４ａ，４ｂ，・・・によって互いに連携して実行される。このときシステム分析装置１は、ネットワーク２を介して送受信されるメッセージ５を取得し、ネットワーク２の運用形態を分析する。分析を行うために、システム分析装置１は、図１に示す各機能を有している。
【００１７】
メッセージ観測手段１ａは、ネットワーク２を介して受け渡されるメッセージ５を収集する。収集したメッセージ５は、メッセージ解析手段１ｂに渡される。
メッセージ解析手段１ｂは、収集したメッセージの内容を解析して、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージか（メッセージの方向）を判別する。処理種別は、例えば、メッセージに適用されているプロトコルがＨＴＴＰ（HyperText Transfer Protocol）であれば、処理要求で指定されたＵＲＬ（Uniform Resource Locator）によって判別できる。そして、メッセージ解析手段１ｂは、判別された情報をプロトコルログとしてプロトコルログ記憶手段１ｃに格納する。
【００１８】
モデル生成手段１ｄは、モデル生成指示が入力されると、プロトコルログ記憶手段１ｃに格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を認識する。そして、モデル生成手段１ｄは、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成する。モデル生成手段１ｄは、生成したトランザクションモデルをトランザクションモデル記憶手段１ｅに格納する。
【００１９】
なお、選択基準としては、例えば、処理時間帯が他のトランザクションと重複しない非多重トランザクションの時間帯内のメッセージの集合を選択することが定められる。また、制約条件は、例えば、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件である。
【００２０】
分析手段１ｆは、分析指示が入力されると、トランザクションモデル記憶手段１ｅに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログをプロトコルログ記憶手段１ｃから抽出し、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する。例えば、トランザクション内での各サーバでの処理時間が分析される。
【００２１】
出力手段１ｇは、分析手段１ｆによる分析結果を、グラフ等の視覚的に認識しやすい統計情報としてモニタ等に出力する。
このようなシステム分析装置１であれば、メッセージ観測手段１ａにより、ネットワーク２を介して受け渡されるメッセージ５が収集される。すると、メッセージ解析手段１ｂにより、収集したメッセージの内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別され、判別された情報がプロトコルログとしてプロトコルログ記憶手段１ｃに格納される。
【００２２】
このとき、モデル生成指示が入力されると、モデル生成手段１ｄにより、プロトコルログ記憶手段に格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理が認識される。そして、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、制約条件を満たすトランザクションモデルが生成される。そして、生成されたトランザクションモデルがトランザクションモデル記憶手段１ｅに格納される。
【００２３】
また、分析指示が入力されると、分析手段１ｆにより、トランザクションモデル記憶手段１ｅに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログがプロトコルログ記憶手段１ｃから抽出され、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態が分析される。分析結果は、出力手段１ｇによって出力され、ユーザに対して提示される。
【００２４】
このように、ネットワーク２を介して受け渡されるメッセージ５から、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合からトランザクションモデルを生成するようにした。すなわち、処理間の呼出関係として生起確率が高い関係を選択し、その関係によって成立するトランザクションをモデル化している。このようにして生成したトランザクションモデルと合致するメッセージをプロトコルログから検出することで、サーバ４ａ，４ｂに対して機能追加を行わずに、共通のトランザクションを構成するメッセージ集合を特定し、処理状態の解析が可能となる。
【００２５】
以下、本発明の実施の形態について詳細に説明する。
［第１の実施の形態］
第１の実施の形態では、インターネットバンキングの業務サービスを提供するＷｅｂ３階層システムにおいて、「残高確認」と「入金」との２つのサービスを提供する場合の例である。
【００２６】
なお、第１の実施の形態では、管理対象となる要素として「セッション」、「メッセージ」、「オブジェクト」、及び「トランザクション」がある。
「セッション」は、送受信側のＩＰ（Internet Protocol）アドレスとポート番号によって定まる通信路上で送受信されるデータの集合である。
【００２７】
「メッセージ」は、ＴＣＰ（Transmission Control Protocol）セッション上で複数の機器がやりとりするデータの最小単位である。例えば、ＨＴＴＰでのリクエストやそれに対するレスポンスが、メッセージに該当する。
【００２８】
「オブジェクト」は、サーバがメッセージを受信してからレスポンスを送信するまでに行う単一又は複数の処理や入力されるデータを仮想的に単一のものとしてまとめたものである。ここで言う処理とは、ＣＰＵ(Central Processing Unit)での計算、データの入出力とそれぞれに対する待ち時間などが含まれる。
【００２９】
「トランザクション」は、システムに対する要求によって発生するオブジェクト処理の集合である。
図２は、第１の実施の形態に係るシステム構成を示す図である。図２の例では、スイッチ１０を介して、クライアント２１，２２，２３、Ｗｅｂサーバ３１、アプリケーションサーバ３２、データベース（ＤＢ）サーバ３３、及びシステム分析装置１００が接続されている。Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３は、クライアント２１，２２，２３からの要求に応じて、サービスを提供する。
【００３０】
サービスを提供する為のトランザクションにおいて、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３間で、スイッチ１０を介してメッセージの送受信が行われる場合がある。このスイッチ１０を介して送受信されるメッセージをシステム分析装置１００が監視することで、システムの動作状態の分析を行うことができる。
【００３１】
図３は、システム分析装置のハードウェア構成例を示す図である。システム分析装置１００は、ＣＰＵ１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ(Random Access Memory)１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。
【００３２】
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
【００３３】
グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
【００３４】
通信インタフェース１０６は、スイッチ１０に接続されている。通信インタフェース１０６は、スイッチ１０を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、システム分析装置１００のハードウェア構成例を示したが、クライアント２１，２２，２３、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３も同様のハードウェア構成で実現することができる。
【００３５】
図４は、システム分析装置の機能ブロックを示す図である。システム分析装置１００は、パケットデータ記憶部１１１、プロトコルログ記憶部１１２、モデル記憶部１１３、分析結果記憶部１１４、メッセージ観測部１２０、メッセージ解析部１３０、モデル生成部１４０、分析部１５０、及び出力部１６０を有している。
【００３６】
パケットデータ記憶部１１１は、スイッチ１０を介して送受信されたメッセージを構成するパケット記憶するための記憶装置である。プロトコルログ記憶部１１２は、パケットを解析することにより取得したメッセージの情報を記憶するための記憶装置である。モデル記憶部１１３は、トランザクションを完了するまでに送受信されるメッセージのリスト（トランザクションモデル）を記憶する記憶装置である。分析結果記憶部１１４は、メッセージの分析結果を記憶する記憶装置である。
【００３７】
メッセージ観測部１２０は、スイッチ１０を介して送受信されるメッセージを観測し、そのメッセージを構成するパケットをパケットデータ記憶部１１１に格納する。
メッセージ解析部１３０は、パケットデータ記憶部１１１に格納されたパケットの内容を解析し、解析結果をプロトコルログ記憶部１１２に格納する。
【００３８】
モデル生成部１４０は、プロトコルログ記憶部１１２に格納された情報に基づいてトランザクションモデルを生成し、モデル記憶部１１３に格納する。
分析部１５０は、プロトコルログ記憶部１１２に格納された情報と、モデル記憶部１１３に格納されたトランザクションモデルとを比較して、各トランザクションの処理時間等の統計情報を分析する。そして、分析部１５０は、分析結果を分析結果記憶部１１４に格納する。
【００３９】
出力部１６０は、分析結果記憶部１１４に格納されている分析結果を、グラフ等でモニタ１１等に出力する。
このような構成のシステム分析装置１００で、次のようなシステム分析処理が実行される。
【００４０】
図５は、システム分析処理の手順を示すフローチャートである。以下、図５に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］メッセージ観測部１２０は、スイッチ１０を流れるメッセージを観測し、パケットデータ記憶部１１１に格納する。
【００４１】
［ステップＳ１２］メッセージ解析部１３０は、パケットデータ記憶部１１１に格納されたメッセージを解析する。
［ステップＳ１３］その後、モデル生成部１４０により、モデル生成指示が入力されているか否かが判断されるとともに、分析部１５０により、分析指示が入力されているかが判断される。モデル生成指示や分析指示は、例えば、システム分析装置１００の管理者によるキーボード１２等を用いた操作入力によって与えられる。モデル生成指示が入力されている場合、処理がステップＳ１４に進められる。分析指示が入力されている場合、処理がステップＳ１５に進められる。
【００４２】
［ステップＳ１４］モデル生成指示が入力されている場合、モデル生成部１４０は、プロトコルログ記憶部１１２に格納されている情報を参照し、トランザクションモデルを生成する。そして、モデル生成部１４０は、生成したトランザクションモデルをモデル記憶部１１３に格納する。その後、処理が終了する。
【００４３】
［ステップＳ１５］分析指示が入力されている場合、分析部１５０は、モデル記憶部１１３に格納されているトランザクションモデルとプロトコルログ記憶部１１２に格納されている情報とを参照し、実行されているトランザクションに関する情報を分析する。そして、分析部１５０は、分析結果を分析結果記憶部１１４に格納する。
【００４４】
［ステップＳ１６］出力部１６０は、分析結果記憶部１１４に格納された分析結果に基づいて、統計情報等をモニタ１１に出力する。その後、処理が終了する。
このような手順でシステム分析が行われる。以下、図５に示す各ステップの処理を、詳細に説明する。
【００４５】
まず、メッセージ観測処理について説明する。
図６は、メッセージ観測状況を示す概念図である。この例では、Ｗｅｂサーバ３１、アプリケーションサーバ３２、ＤＢサーバ３３が監視対象となっている。各サーバは、スイッチ１０の個別のポート１１，１２，１３に接続されている。また、システム管理装置１００は、スイッチ１０のポート１４に接続されている。
【００４６】
スイッチ１０は、自身を通過するデータをミラーリングする機能を有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。
【００４７】
図６の例では、Ｗｅｂサーバ３１が接続されたポート１１、アプリケーションサーバ３２が接続されたポート１２、及びＤＢサーバ３３が接続されたポート１３のミラーリング先として、システム分析装置１００が接続されたポート１４が指定されている。これにより、各サーバ宛のパケットは宛先となるサーバに入力されるとともに、システム分析装置１００にも入力される。
【００４８】
例えば、クライアント２１からの要求に応じて、Ｗｅｂサーバ３１、アプリケーションサーバ３２、及びＤＢサーバ３３が連動してサービスを提供する場合を想定する。この場合、まず、クライアント２１からＷｅｂサーバ３１に対してパケット４１（例えば、ＨＴＴＰのパケット）が送信される。このとき、パケット４１と同じ内容のパケット５１がシステム分析装置１００に入力される。次に、Ｗｅｂサーバ３１からアプリケーションサーバ３２へパケット４２（例えば、ＩＩＯＰ（Internet Inter-ORB Protocol）のパケット）が送信されると、パケット４２と同じ内容のパケット５２がシステム分析装置１００に入力される。さらに、アプリケーションサーバ３２からＤＢサーバ３３へ、パケット４３（例えば、ＤＢアクセスのパケット）が送信されると、パケット４３と同じ内容のパケット５３がシステム分析装置１００に入力される。
【００４９】
システム分析装置１００に入力されたパケット５１，５２，５３は、スイッチ１０に直接接続されたメッセージ観測部１２０で取得され、パケットデータ記憶部１１１に格納される。具体的には、メッセージ観測部１２０は、スイッチ１０から送られたパケット５１，５２，５３をキャプチャし、受信時刻とともにパケットデータ記憶部１１１に格納する。
【００５０】
なお、メッセージ観測部１２０は、キャプチャしたパケット５１，５２，５３を蓄積せずに、観測と同時にメッセージ解析部１３０に送ってもよい。また、メッセージ観測部１２０は、メッセージ観測手段において必要なパケットのみをキャプチャすることもできる。さらに、スイッチ１０において必要なデータのみを選択してミラーリングすることもできる。
【００５１】
図７は、パケットデータ記憶部のデータ構造例を示す図である。パケットデータ記憶部１１１には、複数のパケット５５１〜５５８が格納されている。また、パケットデータ記憶部１１１には、各パケットデータ５５１〜５５８の受信時刻を示す時刻情報６１〜６８が格納されている。
【００５２】
図８は、パケットに含まれる情報を示す図である。時刻情報６１とともに格納されているパケット５５１は、イーサネットヘッダ（Etherヘッダ）（イーサネット：登録商標）５５１ａ、ＩＰヘッダ５５１ｂ、ＴＣＰヘッダ５５１ｃ、及びＴＣＰデータ５５１ｄで構成される。
【００５３】
図９は、ＩＰヘッダの詳細を示す図である。ＩＰヘッダ５５１ｂは、バージョン情報（version）、ヘッダ長、サービスタイプ（Type of Service）、データ長、識別子（ＩＤ）、フラグ（Flag）、フラグメントオフセット（Fragment Offset）、生存時間（Time Of Live）、プロトコル（Protocol）、ヘッダチェックサム（Header Checksum）、送信側ＩＰアドレス、受信側ＩＰアドレス、オプション（Option）、及びパディング（Padding）で構成されている。
【００５４】
図１０は、ＴＣＰヘッダの詳細を示す図である。ＴＣＰヘッダ５５１ｃは、送信側ポート、受信側ポート、送信用シーケンス番号（Sequence Number）、応答確認番号（Acknowledge Number）、ヘッダ長、リザーブ（Reserved）、フラグ、ウィンドウ（Window）、チェックサム（Checksum）、緊急ポインタ（Urgent Pointer）、及びオプション（Option）で構成される。フラグは、さらに、ＵＲＧ（Urgent Flag）、ＡＣＫ（Acknowledgement Flag）、ＰＳＨ（Push Flag）、ＲＳＴ（Reset Flag）、ＳＹＮ（Synchronize Flag)、ＦＩＮ（Fin Flag）で構成される。
【００５５】
メッセージ観測部１２０で取得したパケットは、メッセージ解析部１３０で解析される。
図１１は、メッセージ解析部の機能を示すブロック図である。メッセージ解析部１３０は、ＴＣＰ／ＵＤＰ（User Datagram Protocol）セッション再構成部１３１、メッセージ再構成部１３２、オブジェクト名割り当て部１３３、及びログ出力部１３４を有している。
【００５６】
ＴＣＰ／ＵＤＰセッション再構成部１３１は、パケット５５１〜５５８を、そのパケット５５１〜５５８が属するセッション７１〜７３毎に振り分ける。メッセージ再構成部１３２は、セッション７１〜７３に振り分けられたパケット５５１〜５５８の中から所定のデータを抽出し、メッセージ対８１〜８３を再構成する。オブジェクト名割り当て部１３３は、メッセージ対８１〜８３に対応するオブジェクト名を決定する。ログ出力部１３４は、処理結果をプロトコルログ記憶部１１２に出力する。
【００５７】
メッセージ観測部１２０からメッセージ解析部１３０にパケット５５１〜５５８が入力されると、ＴＣＰ／ＵＤＰセッション再構成部１３１、メッセージ再構成部１３２、オブジェクト名割り当て部１３３、ログ出力部１３４の順番で、処理が実行される。なお、メッセージ観測部１２０から渡されるパケット５５１〜５５８は、パケットデータ記憶部１１１に予め格納されたパケットが渡される場合と、メッセージ観測部１２０によって観測されたパケットが転送される場合とがある。
【００５８】
以下、メッセージ解析部１３０内の各要素が実行する処理を、詳細に説明する。
メッセージ解析部１３０に渡されたパケット５５１〜５５８は、まず、ＴＣＰ／ＵＤＰセッション再構成部１３１に入力される。ＴＣＰ／ＵＤＰセッション再構成部１３１は、入力されたパケット５５１〜５５８のセッション別の振り分けを行う。
【００５９】
具体的には、ＴＣＰ／ＵＤＰセッション再構成部１３１は、まずパケット５５１のＩＰヘッダ５５１ｂから、送受信側ＩＰアドレス（図９参照）を取得する。次に、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＴＣＰヘッダ５５１ｃから送信側ポート番号と受信側ポート番号とを取得する（図１０参照）。そして、ＴＣＰ／ＵＤＰセッション再構成部１３１は、取得した４つの値の組をセッションの識別子とする。このとき、識別子に一意な番号を割り当てることもできる。
【００６０】
ＴＣＰ／ＵＤＰセッション再構成部１３１は、各パケット５５１〜５５８の識別子を生成し、同じ識別子を持つパケットを、同じセッションで送られたパケットであるとして振り分ける。
【００６１】
次に、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＴＣＰの場合、ＴＣＰヘッダ５５１ｃに含まれるフラグを読み取って、開始・確立・切断などのセッション状態を取得する（図１０参照）。例えば、ＳＹＮ「１」のパケットの検出によってセッションの開始を認識し、そのパケットに対するＡＣＫ「１」の応答によってセッションの確立を認識し、セッション確立状態でデータ伝送とそれに対するＡＣＫ「１」の応答が繰り返し行われ、最後にＦＩＮ「１」パケットの検出によってセッションの切断を認識する。
【００６２】
また、ＴＣＰ／ＵＤＰセッション再構成部１３１は、ＩＰヘッダ５５１ｂ・ＴＣＰヘッダ５５１ｃに含まれるデータ長とヘッダ長を取得して、データ長から各ヘッダ長を引くことでデータ部の長さ（データサイズ）を取得する。
【００６３】
さらに、ＴＣＰ／ＵＤＰセッション再構成部１３１に対して、事前に各サーバのＩＰアドレスを与えておくことで、ＩＰアドレスの組から各パケットの送信方向を決定することもできる。
【００６４】
また、ＴＣＰ／ＵＤＰセッション再構成部１３１は、例えば、パケットのＩＰヘッダから、サーバアドレスが送信アドレスにあれば送信側ポート番号を、サーバアドレスが宛て先アドレスにあれば受信側ポート番号を読み取る。そして、ＴＣＰ／ＵＤＰセッション再構成部１３１は、そのポート番号を識別子とすることでどのサービスに関するセッションであるかを調べることができる。例えば、サーバ側のポートが８０番である場合、Ｗｅｂサーバとの通信（ＨＴＴＰ）であると判定する。
【００６５】
図１２は、再構成したセッションの例である。ＴＣＰ／ＵＤＰセッション再構成部１３１によって、パケット５５１〜５５８からＴＣＰのセッション７１〜７３が再構成される。図１２では、縦軸が時間軸を表している（図中、上から下に時間が進行する）。
【００６６】
各軸の上の数字が、各機器のＩＰアドレスを表している。ＩＰアドレスの組によってパケットが振り分けられている。図１２では、各パケットから取得したフラグもしくはデータサイズとともに時系列のシーケンスで表示されている。
【００６７】
このように、セッション７１〜７３毎に振り分けられたパケットがメッセージ再構成部１３２に渡される。
メッセージ再構成部１３２は、セッション７１〜７３毎に振り分けられたパケットのデータ部からメッセージを再構成する。メッセージ再構成部１３２では、まず同一のセッション７１〜７３で送受信されるパケットの集まりからデータ部分を抜き出して並べる。そして、メッセージ再構成部１３２は、並べられたデータ部分の列を、プロトコルのフォーマットに従ってメッセージのサイズを取得してメッセージを分割する。このとき、メッセージが複数に分割送信されていた場合には、複数のデータ部分を連結してひとつのメッセージを切り出してよい。もしくは、連結された複数のメッセージが送信されていた場合には、単一のデータ部から複数のメッセージを切り出してよい。また、各メッセージにはセッション上で一意な番号を割り振ってよい。
【００６８】
図１３は、メッセージ再構成例を示す第１の図である。図１３は、送信側ＩＰアドレスが１０．２５．２１４．１０、受信側ＩＰアドレスが１０．２５．２１４．１０５、送信側ポート番号が３４４９、受信側ポート番号が８０である識別子を持つセッション７１上のメッセージを解析する例である。
【００６９】
メッセージ再構成部１３２は、パケット５５４の属するセッションの受信側ポート番号が８０番であることから、パケット５５４のデータ部をＨＴＴＰによるクライアント２１からＷｅｂサーバ３１へのリクエストであると判定し、ＨＴＴＰメッセージとして切り分ける。
【００７０】
ＨＴＴＰの場合、メッセージ再構成部１３２は、データから特定のオクテットの組み合わせ(0x0D0A0D0A=\r\n\r\n)を検索し、その位置までをヘッダ部（ＨＴＴＰヘッダ）とする。次に、データ部（ＨＴＴＰデータ）が存在する場合には、ヘッダ部に含まれるContent-Lengthフィールドからデータ部の長さを取得し、メッセージを切り出すとともに、メッセージを構成する最初のパケット５５４の受信時刻「００．００．００：１００」をそのメッセージの受信時刻とする。そして、メッセージ再構成部１３２は、メッセージ種別や要求されたＵＲＬ、応答結果データを取得する。
【００７１】
例えばＨＴＴＰメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・ＵＲＬ・個別のパラメータなどがある。また、例えばＩＩＯＰメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・メソッド名・個別のパラメータなどがある。さらに、例えばＤＢメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・ＳＱＬ（Structured Query Language）文・ＳＱＬ文のパラメータなどがある。
【００７２】
図１３の例では、ＨＴＴＰリクエストメッセージのヘッダの先頭がＰＯＳＴであり、その直後が/corba/servlet/Balanceであることからメッセージ種別はＰＯＳＴ、オブジェクトを表すＵＲＬは/corba/servlet/Balanceであることが分かる。また、Content-Lengthフィールドの値が２９であることからデータ部の長さは２９バイトあることが分かる。したがって、メッセージ再構成部１３２は、ヘッダ終端から２９バイトまでをメッセージとして切り出す。
【００７３】
また、メッセージ再構成部１３２では、実行主体に対するリクエストメッセージとその返答であるレスポンスメッセージを対応付け、応答までにかかった時間を算出する。例えばＨＴＴＰの場合、リクエストメッセージを、同一のセッション上で直後に現れるレスポンスメッセージと対応付ける。また、レスポンスメッセージの受信時刻からリクエストメッセージの受信時刻を差し引き、このメッセージ対の応答時間とする。また、このとき、対応付けたメッセージ対に一意な番号を割り当ててもよい。
【００７４】
図１４は、リクエストへのレスポンスメッセージの対応付けの例を示す図である。図１４の例では、ＨＴＴＰレスポンスメッセージとＨＴＴＰリクエストメッセージとを対応付ける場合を示している。
【００７５】
図１３のパケット５５４から取得したメッセージと、図１４のパケット５５６から取得したメッセージは、送信側ＩＰアドレス１０．２５．２１４．１０５、受信側ＩＰアドレス１０．２５．２１４．１０、送信側ポート番号８０、受信側ポート番号３４４９のセッション上でやりとりされたメッセージであることから、図１４のパケット５５６から取得したメッセージは、図１３のパケット５５４から取得したメッセージと同一セッション上で連続して送信されたメッセージであると判定する。また、２つのメッセージの送信方向が反対であることから、これら２つのメッセージを対応付けて、メッセージ対が生成される。メッセージ再構成部１３２は、メッセージ対の応答時間を算出し、これら二つのメッセージに共通の識別番号１を割り当てる。
【００７６】
このようにして、メッセージ対がオブジェクト名割り当て部１３３に渡される。そして、オブジェクト名割り当て部１３３では、メッセージ対に対応するオブジェクト名が決定される。
【００７７】
なお、オブジェクト名は、以降の装置で分析したい内容に応じて変更してよい。また、異なるメッセージに対して同じオブジェクト名を割り当ててもよく、単一のメッセージに対して複数のオブジェクト名を割り当ててもよい。また、取得できる全ての情報を仮のオブジェクト名として割り当てておき、以降の装置においてオブジェクト名を再び決定してもよい。
【００７８】
例えばＨＴＴＰメッセージ対にオブジェクト名としてＵＲＬを割り当てる。これは、実行する処理とメッセージを関連付けるための情報がＵＲＬ中に含まれることによる。
また、例えばＩＩＯＰメッセージ対にオブジェクト名としてメソッド名を割り当てる。これは、ＩＩＯＰのメソッド名がサーバ上における単一の処理を表すためである。
【００７９】
また、例えばＤＢメッセージ対にオブジェクト名としてSelect・Insert・Update・FetchなどのＳＱＬオペレータ種別とデータベーステーブル名の組を割り当てる。これは、データベース操作による書き込みの有無や、操作する対象となるデータベーステーブルのサイズなどによって異なる処理の量や時間を区別するためである。
【００８０】
図１５は、オブジェクト名の割り当てとメッセージの解析結果を示す図である。この例ではＨＴＴＰの図１４で対応付けたメッセージ対８１に対してオブジェクト名８１ｃを割り当てている。このオブジェクト名８１ｃは、リクエストメッセージで指定されたＵＲＬである。メッセージ８１ａは図１３のパケット５５４から再構成したＨＴＴＰリクエストメッセージであり、メッセージ８１ｂは図１４のパケット５５６から再構成したＨＴＴＰレスポンスメッセージであり、メッセージ対８１はこれらのメッセージを対応付けたものである。
【００８１】
図１６は、１つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。この例では、ＨＴＴＰプロトコルのメッセージと同様に、ＩＩＯＰやＤＢなど他のプロトコルについてもメッセージを再構成し、オブジェクト名を割り当てている。
【００８２】
したがって、図１３、図１４、図１５で対応付けたＨＴＴＰのメッセージ８１ａ，８１ｂ（ＨＴＴＰのセッション上での識別番号１）、ＩＩＯＰのセッション上で識別番号１を持つリクエストのメッセージ８２ａ（オブジェクト名：Mbalance）と対応するレスポンスのメッセージ８２ｂ、及びＤＢのセッション上で識別番号１を持つリクエストのメッセージ８３ａ（オブジェクト名：Fetch Account）と対応するレスポンスのメッセージ８３ｂが再構成されている。これらのメッセージが、抽出したオブジェクト名とともにシーケンス図として表示されている。
【００８３】
メッセージ８１ａのオブジェクト名は、/corba/servlet/Balanceである。メッセージ８２ａのオブジェクト名は、Mbalanceである。メッセージ８３ａのオブジェクト名は、Fetch Accountである。
【００８４】
このような、オブジェクト名が割り当てられたメッセージ対８１〜８３が、ログ出力部１３４に入力される（図１１参照）。すると、ログ出力部１３４は、ＴＣＰ／ＵＤＰセッション再構成部１３１と、メッセージ再構成部１３２と、オブジェクト名割り当て部１３３で得られた情報を、プロトコルログとして出力する。このとき、出力されるプロトコルログはテキスト形式であってもよく、バイナリ形式であってもよい。
【００８５】
図１７は、プロトコルログの例を示す図である。この例では、テキスト形式で出力したプロトコルログ１１２ａ〜１１２ｆが示されている。
プロトコルログ１１２ａ〜１１２ｆには、メッセージ毎に、時刻（メッセージの受信時刻）、識別番号、プロトコル（プロトコルの名称）、方向（リクエストかレスポンスか）、及びオブジェクト／応答時間（リクエストについてはオブジェクト名、レスポンスに対しては応答時間）が設定されている。
【００８６】
例えば、ＨＴＴＰのセッションの場合、リクエストのメッセージを示すプロトコルログ１１２ａには、受信時刻「００．００．００．１００」、識別番号「１」、オブジェクト名「/corba/servlet/Balance」が設定されている。そして、レスポンスのメッセージを示すプロトコルログ１１２ｆには、受信時刻「００．００．００．２９０」、識別番号「１」、応答時間「０．１９０（秒）」が設定されている。
【００８７】
このような、クライアント２１，２２，２３に対してサービスが提供される毎に、図１７に示すようなプロトコルログ１１２ａ〜１１２ｆが、メッセージ解析部１３０によってプロトコルログ記憶部１１２内に逐次蓄積される。その結果、プロトコルログ記憶部１１２内には、複数のトランザクションに関係するプロトコルログが混在して格納される。
【００８８】
図１８は、プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。プロトコルログ記憶部１１２には、異なるトランザクションに関連するメッセージのプロトコルログが時系列に格納されている。図１８には、インターネットバンキングサービスでの「残高確認」トランザクションと「入金」トランザクション処理時に発生するメッセージに基づくプロトコルログが示されている。
【００８９】
プロトコルログ記憶部１１２に格納されたプロトコルログは、モデル生成指示が入力されている場合、モデル生成部１４０に入力される。すると、モデル生成部１４０によって、トランザクションモデルが生成される。
【００９０】
モデル生成部１４０は、プロトコルログ記憶部１１２に格納されたプロトコルログに基づいて、トランザクションモデルを獲得する。なお、図１８に示したようなプロトコルログは、ＨＴＴＰプロトコル、ＩＩＯＰプロトコル、そしてＤＢプロトコルのメッセージが複雑に混ざり合っている。なお、各プロトコルのリクエストとそれに対応するレスポンスのメッセージは、メッセージ再構成部１３２によって生成された同じ識別番号を持つ。
【００９１】
そこで、第１の実施の形態では、モデル生成部１４０は、処理間の呼出関係の確からしさに基づく選択基準として、次のような基準を採用する。すなわち、各トランザクションが他のトランザクション（クライアントのリクエストからレスポンスまで）とオーバラップすることのない部分（すなわち非多重（多重度１）の部分）のみを抜き出して、モデルを獲得する。非多重のトランザクションであれば、そのトランザクションが実行されている時間帯内の各処理間には、呼出関係が確実に存在する（確からしさが高い）。
【００９２】
そこで、モデル生成部１４０は、まず、同じ識別番号を持つＨＴＴＰプロトコルのリクエスト・レスポンスのペア群を検出する。次に、モデル生成部１４０は、ＨＴＴＰプロトコルのメッセージペアの間に、他の識別番号を持つＨＴＴＰのメッセージが存在するかどうかをチェックする。存在しない場合、モデル生成部１４０は、ＨＴＴＰプロトコルのリクエスト・レスポンスのペア、及びその間の全てのリクエストを選択する。つまり、横断関係にないトランザクションが抽出される。
【００９３】
詳細には、以下のような処理が行われる。
図１９は、トランザクションモデル生成処理を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
【００９４】
［ステップＳ２１］モデル生成部１４０は、パラメータの初期化を行う。具体的には、多重度＝０、重複フラグ＝０とする。
［ステップＳ２２］モデル生成部１４０は、プロトコルログ記憶部１１２からメッセージを読み込む。
【００９５】
［ステップＳ２３］モデル生成部１４０は、メッセージがあるか否かを判断する。メッセージがあれば、処理がステップＳ２４に進められる。メッセージがなければ処理が終了する。
【００９６】
［ステップＳ２４］モデル生成部１４０は、読み込んだメッセージのプロトコルがＨＴＴＰか否かを判断する。ＨＴＴＰであれば処理がステップＳ２５に進められる。ＨＴＴＰでなければ、処理がステップＳ２２に進められる。
【００９７】
［ステップＳ２５］モデル生成部１４０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージであれば、処理がステップＳ２６に進められる。レスポンスのメッセージであれば、処理がステップＳ３０に進められる。
【００９８】
［ステップＳ２６］モデル生成部１４０は、多重度＝０か否かを判断する。多重度が０であれば、処理がステップＳ２７に進められる。多重度が０でなければ、処理がステップＳ２９に進められる。
【００９９】
［ステップＳ２７］モデル生成部１４０は、多重度をインクリメント（１加算）する。
［ステップＳ２８］モデル生成部１４０は、開始位置を保存する。具体的には、処理したメッセージの位置を特定する情報（例えば、該当するプロトコルログを示すポインタ等）を格納する。その後、処理がステップＳ２２に進められる。
【０１００】
［ステップＳ２９］モデル生成部１４０は、多重度をインクリメント（１加算）し、さらに重複フラグの値を１に設定する。その後、処理がステップＳ２２に進められる。
［ステップＳ３０］ステップＳ２５でレスポンスのメッセージであると判断されると、モデル生成部１４０は、多重度＝１か否かを判断する。多重度が１であれば、処理がステップＳ３１に進められる。多重度が１以外であれば、処理がステップＳ２２に進められる。
【０１０１】
［ステップＳ３１］モデル生成部１４０は、重複フラグ＝０か否かを判断する。重複フラグが０であれば、処理がステップＳ３２に進められる。重複フラグが１であれば、処理がステップＳ３３に進められる。
【０１０２】
［ステップＳ３２］モデル生成部１４０は、開始位置から現在位置のメッセージをモデル生成用メッセージとして選択する。その後、処理がステップＳ３４に進められる。
［ステップＳ３３］モデル生成部１４０は、重複フラグの値を０に設定する。
【０１０３】
［ステップＳ３４］モデル生成部１４０は、多重度をデクリメント（１減算）する。その後、処理がステップＳ２２に進められる。
このようにして、他のトランザクションと重複しないトランザクションを構成するメッセージを特定し、モデル生成用メッセージとして選択することができる。
【０１０４】
図２０は、選択されるモデル生成用メッセージを示す図である。図２０には、図１８に示すようなプロトコルログからモデル生成に抽出されるメッセージの集合が示されている。
【０１０５】
例えば、図２０のプロトコルログからＨＴＴＰのリクエスト・レスポンスのペアを探すと、識別番号＝１のＨＴＴＰのリクエスト・レスポンスのペア９１、識別番号＝２のＨＴＴＰのリクエスト・レスポンスのペア９２、識別番号＝３のＨＴＴＰのリクエスト・レスポンスのペア９３、そして識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９４がまず検出される。しかし、識別番号＝２のＨＴＴＰプロトコルのリクエスト・レスポンスのペア９２の間に、識別番号＝３のＨＴＴＰリクエストメッセージが存在する。そのため、４つのＨＴＴＰのリクエスト・レスポンスのペア９１〜９４のうち、最終的には識別番号＝１と識別番号＝４のペアのみが抽出される。すなわち、識別番号＝１と識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９１，９４の間のメッセージがモデル生成に用いられることになる。
【０１０６】
図２１は、「残高確認」トランザクションのモデル生成例を示す図である。図２１には、図２０における識別番号＝１のＨＴＴＰのリクエスト・レスポンスのペア９１の間のメッセージ集合２０１から生成される「残高確認」トランザクションモデル２０３が示されている。
【０１０７】
モデル生成部１４０では、上位（利用者側の）の処理が下位の処理を呼び出すが、逆はないという制約を用いる。この制約は、階層的な構成のシステムでは一般的な制約である。具体的には、クライアント２１からＷｅｂサーバ３１の処理が呼び出され、Ｗｅｂサーバ３１からアプリケーションサーバ３２の処理が呼び出され、そこからＤＢサーバ３３の処理が呼び出される。
【０１０８】
モデル生成部１４０は、メッセージ集合２０１を規定の制約に沿って解析し、処理シーケンス２０２を作成する。具体的には、モデル生成部１４０は、メッセージ集合２０１内の各メッセージの内容を、時系列に沿って解析する。メッセージ集合２０１内の各メッセージの内容は、以下の通りである。
【０１０９】
まず、識別番号＝１のＨＴＴＰプロトコルのリクエストメッセージは、クライアント２１からＷｅｂサーバ３１への処理要求を示す。この場合、/corba/servlet/Balanceのオブジェクト処理が請求される。次に、識別番号＝１のＩＩＯＰプロトコルのリクエストメッセージはＷｅｂサーバ３１からアプリケーションサーバ３２へのMbalanceメソッドの処理を要求する。さらに、識別番号＝１のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountという操作処理を要求する。その後、ＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１から、それぞれＤＢ、ＩＩＯＰ、ＨＴＴＰプロトコルのレスポンスのメッセージが送信される。この内容に沿った処理シーケンス２０２が生成される。
【０１１０】
処理シーケンス２０２には、各セッションでの応答時間が含まれる。セッションの時間は、レスポンスメッセージに示されている。図２１の例では、ＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１のリクエストからレスポンスまでの応答時間がそれぞれ１０msec、９０msec、１９０msecである。
【０１１１】
また、「残高確認」の処理シーケンス２０２では、Ｗｅｂサーバ３１で/corba/servlet/Balanceのオブジェクトが処理され、アプリケーションサーバ３２でMbalanceオブジェクトが処理され、ＤＢサーバ３３でFetch Accountオブジェクトが処理されている。そこで、モデル生成部１４０は、各サーバにおけるオブジェクトの処理時間を算出する。
【０１１２】
ＤＢサーバ３３の処理時間は、ＤＢリクエストからレスポンスまでのＤＢの応答時間の１０msecである。アプリケーションサーバ３２の処理時間は、ＩＩＯＰリクエストからレスポンスの応答時間の９０msecからＤＢサーバ３３の応答時間を除いた８０msec（＝９０−１０）である。そしてＷｅｂサーバ３１の処理時間は、ＨＴＴＰリクエストからレスポンスの応答時間１９０msecからアプリケーションサーバの応答時間を除いた１００msec（＝１９０−９０）である。
【０１１３】
そして、モデル生成部１４０は、オブジェクトの処理の呼出関係及び各オブジェクトの処理時間を定義したトランザクションモデル２０３を生成する。
図２２は、「入金」トランザクションのモデル生成例を示す図である。図２２には、図２０における識別番号＝４のＨＴＴＰのリクエスト・レスポンスのペア９４の間のメッセージ集合２１１から生成される「入金」トランザクションモデル２１３が示されている。
【０１１４】
図２１の処理と同様に、モデル生成部１４０は、メッセージ集合２１１を所定の制約に沿って解析し、処理シーケンス２１２を作成する。メッセージ集合２１１内の各メッセージの内容は、以下の通りである。
【０１１５】
まず、識別番号＝４のＨＴＴＰプロトコルのリクエストメッセージは、クライアント２１からＷｅｂサーバ３１への処理を要求する。この場合、ＵＲＬは/corba/servlet/Depositである。次に、識別番号＝４のＩＩＯＰプロトコルのリクエストメッセージはＷｅｂサーバ３１からアプリケーションサーバ３２へのMdepositメソッドの処理を要求する。次に、識別番号＝５のＤＢプロトコルのリクエストメッセージはアプリケーションサーバ３２からＤＢサーバ３３へのFetch Accountという操作処理を要求する。このＤＢリクエストに対応する識別番号＝５のＤＢレスポンスの応答メッセージから分かるように、Fetch Accountの処理はＤＢサーバ３３で１０msecかかった。
【０１１６】
その後に、さらに識別番号＝６のＤＢプロトコルのリクエストメッセージとしてアプリケーションサーバ３２からＤＢサーバ３３へのUpdate Accountという操作処理が要求される。その後、識別番号＝６のＤＢプロトコルのレスポンス、識別番号＝４のＩＩＯＰプロトコルのレスポンス、そして識別番号＝４のＨＴＴＰプロトコルのレスポンスメッセージがＤＢサーバ３３、アプリケーションサーバ３２、Ｗｅｂサーバ３１から送信される。
【０１１７】
このようなメッセージの流れからトランザクションモデル２１３が生成され、モデル記憶部１１３に格納される。また、レスポンスメッセージから、リクエストからレスポンスまでのそれぞれの応答時間が２０msec、１２０msec、２４０msecであったと分かる。この応答時間も、トランザクションモデル２１３に設定される。
【０１１８】
「入金」のトランザクションモデル２１３では、Ｗｅｂサーバ３１で/corba/servlet/Depositのオブジェクトが処理され、アプリケーションサーバ３２でMdepositオブジェクトが処理され、ＤＢサーバ３３でFetch AccountとUpdate Accountオブジェクトが処理されている。そこで、モデル生成部１４０は、各サーバにおけるオブジェクトの処理時間情報を算出する。それぞれの処理時間は、ＤＢサーバ３３では１０msecと２０msec、アプリケーションサーバ３２では９０msec（＝１２０−（１０＋２０））、そしてＷｅｂサーバ３１では１２０msec（＝２４０−１２０）である。
【０１１９】
そして、モデル生成部１４０は、オブジェクトの処理の呼出関係及び各サーバにおけるオブジェクトの処理時間を定義したトランザクションモデル２１３を生成する。
なお、メッセージ解析部１３０から、再度「残高確認」や「入金」トランザクション処理時のメッセージがモデル生成部１４０に入力され、これらが多重度１である場合があり得る。この場合、それらのメッセージを無視してもよい。また、同様にモデル生成を行い、すでに生成されている同じ種類のトランザクションの各サーバの処理時間に反映（例えば、平均時間などを利用して）することもできる。
【０１２０】
また、分析部１５０で実行される既存のトランザクションモデルとメッセージのマッチング法を用いて、多重度１のモデルを基に、多重度１以上のトランザクションのメッセージ集合を抽出し、それぞれの多重度でのアプリケーション処理時間を求めてモデルを生成することもできる。
【０１２１】
次に、分析部１５０で実行される処理を詳細に説明する。分析部１５０は、プロトコルログ記憶部１１２に格納されたプロトコルログを、モデル記憶部１１３に格納されるトランザクションモデルと比較することで、各トランザクションを構成するメッセージを識別する。そして、分析部１５０は、トランザクション毎のメッセージの処理時間によって、システムの状態を分析する。具体的には、以下の処理が行われる。
【０１２２】
図２３は、分析処理の手順を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ５１］分析部１５０は、プロトコルログ記憶部１１２から未処理のプロトコルログを読み込む。
【０１２３】
［ステップＳ５２］分析部１５０は、未処理のプロトコルログがあるか否かを判断する。未処理のプロトコルログがある場合、処理がステップＳ５３に進められる。未処理のプロトコルログが無い場合、処理が終了する。
【０１２４】
［ステップＳ５３］分析部１５０は、読み込んだプロトコルログに示されるメッセージのプロトコルを判断する。プロトコルがＨＴＴＰであれば、処理がステップＳ５４に進められる。プロトコルがＩＩＯＰであれば、処理がステップＳ５９に進められる。プロトコルがＤＢであれば、処理がステップＳ６２に進められる。
【０１２５】
［ステップＳ５４］プロトコルがＨＴＴＰの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ５５に進められる。レスポンスのメッセージの場合、処理がステップＳ５７に進められる。
【０１２６】
［ステップＳ５５］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（ＵＲＬ）に対応するトランザクションモデルをモデル記憶部１１３から検出する。そして、ＨＴＴＰリクエストによって発生した該当トランザクションの内容を認識する。
【０１２７】
［ステップＳ５６］分析部１５０は、処理中テーブルに新しいトランザクション及びＨＴＴＰ識別番号を登録する。その後、処理がステップＳ５１に進められる。
［ステップＳ５７］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて、処理中テーブルから対応トランザクション及びＨＴＴＰを検索し、Ｗｅｂサーバ３１における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。
【０１２８】
［ステップＳ５８］分析部１５０は、終了トランザクション情報を出力部１６０に出力し、処理中テーブルから削除する。その後、処理がステップＳ５１に進められる。
［ステップＳ５９］プロトコルがＩＩＯＰの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ６０に進められる。レスポンスのメッセージの場合、処理がステップＳ６１に進められる。
【０１２９】
［ステップＳ６０］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（メソッド）を用いて、処置中テーブルから対応トランザクションを検索し、ＩＩＯＰ識別番号を登録する。その後、処理がステップＳ５１に進められる。
【０１３０】
［ステップＳ６１］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、アプリケーションサーバ３２における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップＳ５１に進められる。
【０１３１】
［ステップＳ６２］プロトコルがＤＢの場合、分析部１５０は、メッセージの方向（リクエストかレスポンスか）を判断する。リクエストのメッセージの場合、処理がステップＳ６３に進められる。レスポンスのメッセージの場合、処理がステップＳ６４に進められる。
【０１３２】
［ステップＳ６３］リクエストのメッセージの場合、分析部１５０は、メッセージのオブジェクト（コマンド＋テーブル名）を用いて、処置中テーブルから対応トランザクションを検索し、ＤＢ識別番号を登録する。その後、処理がステップＳ５１に進められる。
【０１３３】
［ステップＳ６４］レスポンスのメッセージの場合、分析部１５０は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、ＤＢサーバ３３における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップＳ５１に進められる。
【０１３４】
このような処理を行うことで、トランザクションの種別毎に、各サーバにおける処理時間等を記録することができる。
図２４は、分析部へ入力されるメッセージの例を示す図である。ユーザからの操作入力等により分析指示が出された後、メッセージ解析装置から出力されプロトコルログ記憶部１１２に格納されたプロトコルログ２２１〜２４２が、順次分析部１５０に入力される。
【０１３５】
分析部１５０ではこれらのプロトコルログ２２１〜２４２をモデル生成部１４０で得られた「残高確認」と「入金」のトランザクションモデル（図２１、図２２に示す）とマッチングする。そして、分析部１５０は、トランザクションモデルに合致するトランザクションを抽出する。以下、図２５〜図３４を参照して、図２４に示すプロトコルログ２２１〜２４２の分析例を説明する。なお、図２５〜図３４には、プロトコルログ２２１〜２４２を先頭から順に分析することで確認できるトランザクションの状態遷移が示されている。図２５〜図３４では、発生が確認されたトランザクションのうち、処理が開始されたオブジェクトを実線の楕円で示し、処理が開始されていないオブジェクトを破線の楕円で示している。
【０１３６】
図２５は、メッセージ分析例を示す第１の図である。まず、最初のプロトコルログ２２１で示されるメッセージは、識別番号＝１００のＨＴＴＰプロトコルであり、クライアント２１からＷｅｂサーバ３１への/corba/servlet/Balanceオブジェクト処理のリクエストメッセージである。このメッセージは第１の状態（ＳＴ１）で示すように、図２１に示すトランザクションモデル２０３（「残高確認」トランザクション）のＷｅｂサーバ３１処理への呼び出しと合致する。これは、Ｗｅｂサーバ３１での処理開始を意味する。
【０１３７】
次のプロトコルログ２２２で示されるメッセージは、識別番号＝２００のＩＩＯＰプロトコルの、アプリケーションサーバ３２へのMbalanceオブジェクト処理のリクエストメッセージである。このメッセージは第２の状態（ＳＴ２）で示すように、「残高確認」のトランザクションモデル２０３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１３８】
次のプロトコルログ２２３で示される識別番号＝１０１のＨＴＴＰリクエストメッセージは、Ｗｅｂサーバ３１への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第３の状態（ＳＴ３）で示すように、図２２に示す「入金」のトランザクションモデル２１３のＷｅｂサーバ３１処理への呼び出しと合致する。これは、Ｗｅｂサーバ３１での処理開始を意味する。
【０１３９】
次のプロトコルログ２２４で示される識別番号＝５００のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第４の状態（ＳＴ４）で示すように、「残高確認」トランザクションモデル２０３のＤＢサーバ３３処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４０】
図２６は、メッセージ分析例を示す第２の図である。次のプロトコルログ２２５で示される識別番号＝２０１のＩＩＯＰのリクエストメッセージは、アプリケーションサーバ３２へのMdepositの処理要求である。このメッセージは第５の状態（ＳＴ５）で示すように、「入金」トランザクションモデル２１３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１４１】
次のプロトコルログ２２６で示される識別番号＝１０２のＨＴＴＰリクエストメッセージは、Ｗｅｂサーバ３１への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第６の状態（ＳＴ６）で示すように、「入金」トランザクションモデル２１３のＷｅｂサーバ３１処理への呼び出しと合致する。これは、新たなＷｅｂサーバ３１での処理開始を意味する。
【０１４２】
図２７は、メッセージ分析例を示す第３の図である。次のプロトコルログ２２７で示される識別番号＝５００のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第７の状態（ＳＴ７）で示すように、「残高確認」トランザクションのＤＢサーバ３３での処理に２０msec要したことを意味する。図２１の「残高確認」トランザクションモデル２０３では、ＤＢサーバ３３でのFetch Accountコマンドの処理時間は１０msecとなっている。そのため、モデルとの差は１０msecである。
【０１４３】
次のプロトコルログ２２８で示される識別番号＝５０１のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第８の状態（ＳＴ８）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３の処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４４】
図２８は、メッセージ分析例を示す第４の図である。次のプロトコルログ２２９で示される識別番号＝５０１のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第９の状態（ＳＴ９）で示すように、「入金」トランザクションのＤＢサーバ３３での処理に２０msec要したことを意味する。図２２の「入金」トランザクションモデル２１３でのＤＢサーバ３３のFetch Accountコマンドの処理時間は１０msecとなっているため、モデルとの差は１０msecである。
【０１４５】
次のプロトコルログ２３０で示される識別番号＝５０２のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へUpdate Accountというコマンドの処理要求である。このメッセージは第１０の状態で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３の処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１４６】
図２９は、メッセージ分析例を示す第５の図である。次のプロトコルログ２３１で示される識別番号＝２０２のＩＩＯＰのリクエストメッセージは、アプリケーションサーバ３２へのMdepositの処理要求である。このメッセージは第１１の状態（ＳＴ１１）で示すように、「入金」トランザクションモデル２１３のアプリケーションサーバ３２処理への呼び出しと合致する。これは、アプリケーションサーバ３２での処理開始を意味する。
【０１４７】
次のプロトコルログ２３２で示される識別番号＝２００のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第１２の状態（ＳＴ１２）で示すように、「残高確認」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、ＩＩＯＰリクエストからレスポンスまでの応答時間は１００msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での処理(２０msec)を除いた８０msecになる。この値は、図２１の「残高確認」トランザクションモデル２０３でのアプリケーションサーバ３２の処理時間と同じである。
【０１４８】
図３０は、メッセージ分析例を示す第６の図である。次のプロトコルログ２３３で示される識別番号＝５０２のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第１３の状態（ＳＴ１３）で示すように、「入金」トランザクションのＤＢサーバ３３での処理が５０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのUpdate Accountコマンドの処理時間は２０msecとなっているため、モデルとの差は３０msecである。
【０１４９】
次のプロトコルログ２３４で示される識別番号＝５０３のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へFetch Accountというコマンドの処理要求である。このメッセージは第１４の状態（ＳＴ１４）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３での処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１５０】
図３１は、メッセージ分析例を示す第７の図である。次のプロトコルログ２３５で示される識別番号＝１００のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第１５の状態（ＳＴ１５）で示すように、「残高確認」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は１９０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答処理（１００msec）を除いた９０msecになる。図２１の「残高確認」トランザクションモデル２０３では、Ｗｅｂサーバ３１での処理時間は１００msecとなっているため、モデルより１０msec早く終了していることになる。この時点で、１つの「残高確認」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５１】
次のプロトコルログ２３６で示される識別番号＝５０３のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第１６の状態（ＳＴ１６）で示すように、「入金」トランザクションのＤＢサーバ３３での処理が２０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのFetch Accountコマンドの処理時間は１０msecとなっているため、モデルとの差は１０msecである。
【０１５２】
図３２は、メッセージ分析例を示す第８の図である。次のプロトコルログ２３７で示される識別番号＝５０４のＤＢプロトコルのリクエストメッセージは、アプリケーションサーバ３２からＤＢサーバ３３へUpdate Accountというコマンドの処理要求である。このメッセージは第１７の状態（ＳＴ１７）で示すように、「入金」トランザクションモデル２１３のＤＢサーバ３３処理への呼び出しと合致する。これは、ＤＢサーバ３３での処理開始を意味する。
【０１５３】
次のプロトコルログ２３８で示される識別番号＝２０１のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第１８の状態（ＳＴ１８）で示すように、「入金」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は１８０msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での２つのコマンドの処理時間（７０msec＝２０msec＋５０msec）を除いた１１０msecになる。図２２の「入金」トランザクションモデル２１３では、アプリケーションサーバ３２での処理時間は９０msecとなっているため、モデルとの差は２０msecである。
【０１５４】
図３３は、メッセージ分析例を示す第９の図である。次のプロトコルログ２３９で示される識別番号＝１０１のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第１９の状態（ＳＴ１９）で示すように、「入金」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は３１０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答時間（１８０msec）を除いた１３０msecになる。図２２の「入金」トランザクションモデル２１３では、Ｗｅｂサーバ３１での処理時間は１２０msecとなっているため、モデルとの差は１０msecである。この時点で、１つの「入金」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５５】
次のプロトコルログ２４０で示される識別番号＝５０４のＤＢプロトコルのレスポンスメッセージは、ＤＢサーバ３３からアプリケーションサーバ３２への応答メッセージである。このメッセージは第２０の状態（ＳＴ２０）で示すように、「入金」トランザクションのＤＢサーバ３３処理が２３０msecかかって終了したことを意味する。図２２の「入金」トランザクションモデル２１３では、ＤＢサーバ３３でのUpdate Accountコマンドの処理時間は２０msecとなっているため、モデルとの差は２１０msecであり、大きく増加していることで、ＤＢサーバ３３でなんらかの問題が起きていることが分かる。
【０１５６】
図３４は、メッセージ分析例を示す第１０の図である。次のプロトコルログ２４１で示される識別番号＝２０２のＩＩＯＰプロトコルのレスポンスは、アプリケーションサーバ３２からＷｅｂサーバ３１への応答メッセージである。このメッセージは第２１の状態（ＳＴ２１）で示すように、「入金」トランザクションのアプリケーションサーバ３２での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は３５０msecであるが、アプリケーションサーバ３２での実際の処理時間を考える場合、その間のＤＢサーバ３３での２つのコマンドの処理時間（２５０msec＝２０msec＋２３０msec）を除いた１００msecになる。図２２の「入金」トランザクションモデル２１３では、アプリケーションサーバ３２での処理時間は９０msecとなっている。そのため、モデルとの差は１０msecである。
【０１５７】
ここで注意したいのは、アプリケーションサーバ３２での応答時間が３５０msecであるにもかかわらず、実際のアプリケーションサーバ３２での処理時間はわずか１００msecに過ぎず、モデルとほぼ一致していることで、アプリケーションサーバ３２自身には性能問題がないということが分かる。
【０１５８】
次のプロトコルログ２４２で示される識別番号＝１０２のＨＴＴＰプロトコルのレスポンスメッセージは、Ｗｅｂサーバ３１からクライアントへの応答メッセージである。このメッセージは第２２の状態（ＳＴ２２）で示すように、「入金」トランザクションのＷｅｂサーバ３１での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は４７０msecであるが、Ｗｅｂサーバ３１での実際の処理時間を考える場合、その間のアプリケーションサーバ３２の応答時間（３５０msec）を除いた１２０msecになる。この時点で、最後の「入金」トランザクションのすべての処理が終了し、出力部１６０に出力される。
【０１５９】
図２２の「入金」トランザクションモデル２１３では、Ｗｅｂサーバ３１での処理時間は１２０msecとなっているため、モデルと一致する。アプリケーションサーバ３２と同様に、Ｗｅｂサーバ３１での応答時間が４７０msecであるにもかかわらず、実際のＷｅｂサーバ３１での処理時間はモデルと一致していることで、Ｗｅｂサーバ３１自身には性能問題がないということが分かる。以上のような分析結果は、分析結果記憶部１１４に格納される。
【０１６０】
次に、出力部１６０で行われる処理を詳細に説明する。
出力部１６０は、分析部１５０から分析結果記憶部１１４に格納されたトランザクションの情報をさまざまな形でモニタ１１に出力する。以下、出力部１６０によるトランザクション情報の出力例を示す。
【０１６１】
図３５は、サーバの平均処理時間の表示例を示す図である。図３５で示すように、出力部１６０は、サーバごとの平均処理時間を求めて、モニタ１１に平均処理時間を示す画面３０１を表示する。なお、各サーバの処理時間を示すグラフには、トランザクションモデルにおける処理時間を示す線が表示されている。なお、出力部１６０は、モデルとの処理時間との差が非常に大きい場合には、それらの処理をリストアップして、モニタ１１に表示することもできる。
【０１６２】
図３６は、トランザクション別処理時間及び内訳の表示例を示す図である。この画面３０２では、ある期間のトランザクションがすべて集計され、サーバごとの処理時間が表示されている。
【０１６３】
図３７は、処理時間ヒストグラムの表示例を示す図である。この画面３０３では、トランザクション処理時間、及び各サーバでの処理時間に関するヒストグラム（処理時間毎の発生頻度）が表示されている。
【０１６４】
また、ヒストグラム等の各種情報を画面に同時に表示することで、処理遅延原因の解析を容易にすることができる。
図３８は、複数の情報を同時に表示した場合の画面例を示す図である。この画面３１０には、トランザクション処理時間のヒストグラム表示部３１１、トランザクションの多重度表示部３１２、トランザクションの時間推移表示部３１３（Ｗｅｂサーバ３１、アプリケーションサーバ３２、ＤＢサーバ３３での内訳）とトランザクションメッセージのシーケンス表示部３１４が表示されている。出力部１６０は、各表示対象要素の表示内容を、互いに連携させて表示する。
【０１６５】
図３９は、表示対象要素間の連携の様子を示す図である。図３９に示すように、ヒストグラム表示部３１１には、処理遅延判別用の閾値を示すバー３１１ａが表示されている。このバー３１１ａは、ユーザからの操作入力に応じて左右に移動させることができる。バー３１１ａが表示されている位置の処理時間の値が閾値となる。閾値以上に処理時間を要したトランザクションが、注目処理と判断される。
【０１６６】
図３９の例では、３００msecの位置にバー３１１ａが表示されている。したがって、３００msec以上要したトランザクションが、注目処理となる。
多重度表示部３１２では、ヒストグラム表示部３１１上で注目処理と分類されたトランザクションの処理時間帯が、強調表示される。また、多重度表示部３１２の横には、スクロールバー３１２ａが設けられている。スクロールバー３１２ａで示された時間帯のトランザクションの詳細が、時間推移表示部３１３に表示される。
【０１６７】
時間推移表示部３１３には、プロトコル間のメッセージの受け渡しが、サーバ間のシーケンスで示される。時間推移表示部３１３の横には、スクロールバー３１３ａが設けられている。スクロールバー３１３ａで示された時間帯のメッセージの内容が、シーケンス表示部３１４に表示される。シーケンス表示部３１４では、注目処理に関するメッセージが強調表示される。
【０１６８】
このように、ユーザがヒストグラム表示部３１１から所定の時間以上かかるトランザクションを選択すれば、そのようなトランザクションがどこで起きるかをトランザクションの多重度表示部３１２、トランザクションの時間推移表示部３１３、そしてメッセージのシーケンス表示部３１４で確認できる。
【０１６９】
以上説明したように、第１の実施の形態では、トランザクションモデルを生成し、スイッチ１０を介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出するようにした。これにより、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。
【０１７０】
すなわち、システム分析装置１００において、ネットワークからキャプチャしたＴＣＰパケットのデータ部を解析することで、サーバで実行されるアプリケーション間での通信を再構成する。そして、システム分析装置１００は、再構成されたプロトコルログから、処理間の呼出関係が確実に存在するメッセージ集合を選択し、ユーザのリクエストに対する一連の処理の結びつきであるトランザクションが抽出できる。そして、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することにより、性能問題やボトルネックを迅速に把握することが可能となる。
【０１７１】
しかも、第１の実施の形態は、外部観測によってトランザクションを抽出している。そのため、既存システムへの機能追加を行う必要がなく、サーバ内のアプリケーションへの改変等を行わずに済む。
【０１７２】
［第２の実施の形態］
第２の実施の形態は、処理時間帯が他のトランザクションと重なるようなトランザクションであっても、そのトランザクションを構成するメッセージを抽出し、トランザクションモデルを生成できるようにしたものである。
【０１７３】
すなわち、第１の実施の形態では、各処理が他の処理（リクエストからレスポンスまで）とオーバラップすることない（すなわち多重度１である）部分のみを抜き出して、トランザクションモデルを獲得していた。この処理は、例えば対象システムの運用を一時停止し、モデル獲得のためにのみ動作させることが可能な場合には有効である。
【０１７４】
ところが、２４時間サービスを行っているため運用停止ができず、かつほとんどの場合に複数の処理を同時並行的に処理しているシステムの場合、第１の実施の形態を適用するのは困難となる。また、処理の多重度が低くシステムへの負荷が軽い場合と、多重度が高く負荷も重い場合とで挙動が異なる場合には、多重度１の場合からだけトランザクションモデルを生成したのでは不十分である。そのため、対象システムによっては多重度が高い部分も利用してトランザクションモデルを生成することも必要になる。以下でその動作例を示す。
【０１７５】
なお、第２の実施の形態におけるシステム分析装置の機能ブロックは、図４に示した第１の実施の形態と同様である。そこで、図４に示した各要素を用いて、第２の実施の形態の処理を説明する。また、第１の実施の形態と第２の形態とは、モデル生成部１４０の処理のみが相違し、他の要素の処理は同じである。さらに、説明を簡単にするため、アプリケーションサーバ３２とＤＢサーバ３３とで完結するトランザクションの例を用いて、第２の実施の形態を説明する。すなわち、ＩＩＯＰのメッセージとＤＢのメッセージとの関係から、トランザクションモデルとして生成する。
【０１７６】
図４０は、分析部へ入力されるメッセージの例を示す図である。プロトコルログ記憶部１１２に格納されたプロトコルログ４０１〜４２０が、モデル生成部１４０に入力される。
【０１７７】
モデル生成部１４０は、所定の制約条件に従って、プロトコルログに示されるメッセージを解析する。
図４１は、モデル生成部に入力されたメッセージから認識される処理を示す図である。すなわち、モデル生成部１４０は、図４０のプロトコルログ４０１〜４２０で示されるメッセージから各処理の開始と終了を抽出し、その処理期間を時系列に並べる。その結果が、図４１に示されている。
【０１７８】
処理Ｐ１は、プロトコルログ４０１，４１０で示される識別番号＝１のＩＩＯＰのメッセージから認識される処理である。処理Ｐ２は、プロトコルログ４０３，４１３で示される識別番号＝２のＩＩＯＰのメッセージから認識される処理である。処理Ｐ３は、プロトコルログ４０７，４１９で示される識別番号＝３のＩＩＯＰのメッセージから認識される処理である。処理Ｐ４は、プロトコルログ４１１，４２０で示される識別番号＝４のＩＩＯＰのメッセージから認識される処理である。
【０１７９】
処理Ｐ５は、プロトコルログ４０２，４０５で示される識別番号＝１のＤＢのメッセージから認識される処理である。処理Ｐ６は、プロトコルログ４０４，４０６で示される識別番号＝２のＤＢのメッセージから認識される処理である。処理Ｐ７は、プロトコルログ４０９，４１２で示される識別番号＝４のＤＢのメッセージから認識される処理である。処理Ｐ８は、プロトコルログ４０８，４１４で示される識別番号＝３のＤＢのメッセージから認識される処理である。処理Ｐ９は、プロトコルログ４１５，４１７で示される識別番号＝５のＤＢのメッセージから認識される処理である。処理Ｐ１０は、プロトコルログ４１６，４１８で示される識別番号＝６のＤＢのメッセージから認識される処理である。
【０１８０】
なお、この例ではＩＩＯＰで２種類、ＤＢで２種類の処理が現れるが、以下では記述を簡単にするために以下のように略すこととする。
ＩＩＯＰによるMbalance：種別Ａ
ＩＩＯＰによるMdeposit：種別Ｂ
ＤＢによるFetch->Account：種別ａ
ＤＢによるUpdate->Account：種別ｂ
また、モデル中の各処理種別毎の処理時間の求め方は第１の実施の形態と同じなので、ここではモデル中の処理種別間の呼出関係のみに着目し、処理時間に関する説明は省くものとする。
【０１８１】
第２の実施の形態における制約条件は、以下の通りである。
第１の制約：ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。
【０１８２】
第２の制約：ＩＩＯＰの処理は、直接システム外部（例えば、クライアント２１）から呼び出される。
第３の制約：ＤＢの処理は、必ずＩＩＯＰから呼び出される。
【０１８３】
第１の制約は、呼出関係に関する基本的な制約で処理Ｘが処理Ｙを呼び出した場合には、ＹはＸより後に開始されＸより前に終了しなければならないことを要求している。なお、場合によってはＸの開始（終了）とＹの開始（終了）時刻の差の上限値や下限値を与える場合もある。多くのシステムではこのような制約が成立しており、これを利用することで呼出関係の候補を減らすことができる。
【０１８４】
第２の制約は、階層的な構成のシステムでは一般的な制約で、上位（利用者側の）の処理が下位の処理を呼び出すが、逆はないことを表す。この場合には、監視対象のシステムの外部からＩＩＯＰの処理が呼び出され、そこからＤＢの処理が呼び出されることを表している。これ以外の呼び出し、例えばＩＩＯＰの処理が他のＩＩＯＰの処理を呼び出したり、ＤＢの処理がＩＩＯＰの処理を呼び出したりすることはない。
【０１８５】
このほかにも、例えばあるＩＩＯＰの処理はＤＢの処理を最低１回呼び出す、というような処理種別やそのグループ間の呼出回数やその順序に関する制約等、監視をする側が持つシステムに関する知識を制約として入力する。
【０１８６】
図４２は、制約を満たす処理間の呼出関係を示す図である。第１〜第３の制約を使うと、ある処理から呼び出し可能な他の処理が限定される。すなわち、どのＩＩＯＰ処理からどのＤＢ処理が呼び出され得るかが示されている（これ以外の呼び出しは制約を満足しない）。
【０１８７】
例えばＤＢによる処理Ｐ５を呼び出し得るのは、第１の制約から処理期間が処理Ｐ５のそれを含む処理でなければならず、この例ではＩＩＯＰによる処理Ｐ１のみである。一方処理Ｐ７の呼び出し元については、第１の制約を満足する処理は、処理Ｐ２，Ｐ３，Ｐ８の３個ある。このうち処理Ｐ８はＤＢの処理であり、第２の制約および第３の制約から同じＤＢの処理である処理Ｐ７を呼び出すことはありえないことが分かる。よって、処理Ｐ８を呼び出している候補は処理Ｐ２と処理Ｐ３の２つになる。
【０１８８】
次に、これらの呼出関係の候補から、処理種別毎に、他の種別の呼出回数を計算する。以下では処理種別ｉから処理種別ｊの呼出回数をＭ（ｉ，ｊ）と記述し、Ｍを呼出回数行列と呼ぶ。
【０１８９】
まず初めに、モデル生成部１４０は、呼出回数行列を初期化する。初期化は、呼出関係の制約を満足する要素を１、それ以外を０とする。
図４３は、呼出回数行列の例を示す図である。この例では、４種類の処理があるため、呼出回数行列は１６の要素をもつが、ＩＩＯＰからＤＢへの呼び出しだけが制約で許されるので１、それ以外の１２個は０となる。これは、制約上許される呼び出しは、他の情報がない限り、同じだけの頻度（確率）で起こるとみなすことを意味する。
【０１９０】
次に呼出回数行列を使って、図４２中の呼び出し候補の確率を計算する。例えば、処理Ｐ５の呼び出し元の可能性は処理Ｐ１しかないので、処理Ｐ１から処理Ｐ５への呼び出しの確率は１である。
【０１９１】
一方処理Ｐ６（種別ａ）への呼び出しは、処理Ｐ１（種別Ａ）からの呼び出しと処理Ｐ２（種別Ｂ）からの呼び出しの２つの可能性が考えられる。そのような場合には、呼び出し元（の候補）の処理種別から呼び出し先（この場合は処理Ｐ６）の種別への呼出回数行列要素の値に比例した確率を割り当てる。この場合は、処理Ｐ１が属する種別Ａの処理からの、処理Ｐ６が属する種別ａの処理への回数は１回（図４３参照）、処理Ｐ２が属する種別Ｂからの呼出回数も１回であるので、それぞれの呼び出し候補の確率は共に１／２となる。
【０１９２】
以下、モデル生成部１４０は、同様に各呼び出し候補の確率を求める。
図４４は、呼び出し候補の確率を求めた結果を示す図である。図４３に示す呼出回数行列では、制約を満足する呼出関係を示す各要素の値は、全て１である。そのため、複数の呼び出し可能性を持つ場合、それぞれの呼び出し可能性は等しくなる（確率が１／２）。
【０１９３】
次に、モデル生成部１４０は、上記の確率を使って、呼出回数行列の値を更新する。すなわち、処理種別ＸからＹへの呼出回数は、図４３中の呼び出し候補のなかで、ＸからＹへの呼び出し候補の確率の和を、処理種別Ｘの発生回数で割ったものとして計算できる。
【０１９４】
例えば種別Ａから種別ａへの呼び出し候補は、処理Ｐ１から処理Ｐ５、処理Ｐ１から処理Ｐ６、処理Ｐ４から処理Ｐ１０の３個あり、その確率はそれぞれ、１、１／２、１／２である。このことと、種別Ａの処理が、処理Ｐ１および処理Ｐ４の２個であることから、呼出回数行列の要素Ｍ（Ａ，ａ）の値は、
（１＋１／２＋１／２）／２＝１
となる。同様に、モデル生成部１４０は、他の行列要素も計算する。
【０１９５】
図４５は、更新後の呼出回数行列を示す図である。ただし呼び出し行列のうち、制約上ゆるされない要素の値は常に０であるので、制約上許される要素、すなわちＩＩＯＰの処理種別からＤＢの処理種別への呼び出しに対応する要素のみを示す。
【０１９６】
以上の、呼出回数行列を使った呼び出し候補の確率計算と、それに基づく呼出回数行列の更新を、所定の終了条件を満足するまで繰り返す。所定の終了条件とは、例えば、更新回数が予め設定された回数に達することである。また、別の終了条件としては、更新前後の行列要素の変化量が、予め設定された上限値以下となることである。
【０１９７】
本実施の形態では、終了条件が、更新回数２回であるものとする。すなわち、モデル生成部１４０は、図４４に示した状態からもう一度呼出回数のカウントと行列要素の計算を行う。２回目以降の処理においても、各呼び出し候補の確率計算の方法は１回目の処理と同じである。ただし、確率計算のもとになる呼出回数行列は図４５で示す内容であり、上で求めた図４３とは異なるので、計算される確率も異なる。
【０１９８】
例えば、処理Ｐ９（種別ｂ）に対する呼び出し候補は、処理Ｐ３（種別Ｂ）からの呼び出しと処理Ｐ４（種別Ａ）からの２つがある。図４５に示す呼出回数行列では、種別Ｂから種別ｂへの呼出回数は３／４回、種別Ａから種別ｂへの呼び出しは１／４回である。これに比例するように確率を割り振ると、処理Ｐ３から処理Ｐ９への呼び出しの確率は３／４、処理Ｐ４から処理Ｐ９への呼び出しの確率は１／４となる（処理Ｐ９は処理Ｐ３か処理Ｐ４のいずれか一方から呼び出されるので、２つの確率の和は１になることに注意）。
【０１９９】
以下、モデル生成部１４０は、同様に各呼び出し候補の確率を求める。
図４６は、２回目の処理で呼び出し候補の確率を求めた結果を示す図である。このように、複数の呼び出し可能性を持つ場合には、呼出回数の予測値を重みとして確率が計算される。このような呼び出し候補の確率に基づいて、呼出回数行列が更新される。
【０２００】
図４７は、２回目の更新後の呼出回数行列を示す図である。呼出回数の計算方法は、１回目と同じである。これで呼出回数行列の更新は２回行われたので、確率計算／更新処理が終了して次のステップに進む。
【０２０１】
次に、呼出回数行列の要素のなかで整数以外の部分を四捨五入などにより整数にまるめる。図４７では種別Ａから種別ｂへの呼出回数が１／８回なのでこれを０とし、種別Ｂから種別ｂへの呼出回数は７／８なので、これを１回とする。これら以外は値が整数なので変更されない。
【０２０２】
図４８は、最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。モデル生成部１４０は、図４８に示すように整数化された呼出回数行列から、処理種別間の呼出関係を表すトランザクションモデルを獲得する。すなわち、呼出回数行列から、ＩＩＯＰ処理種別Ａは、ＤＢの処理種別ａを１回呼び出し、ＩＩＯＰの種別ＢはＤＢの処理種別ａと処理種別ｂとをそれぞれ１回ずつ呼び出すことが分かる。
【０２０３】
すなわち、呼出回数行列で１と設定されている呼出関係が、生起確率の高い関係である。そこで、モデル生成部１４０は、呼出回数行列で１が設定されている呼出関係から認識されるトランザクションモデル４３１，４３２を生成し、モデル記憶部１１３に格納する。
【０２０４】
以上の処理手順を整理すると以下のようになる。
図４９は、第２の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図４９に示す処理をステップ番号に沿って説明する。
【０２０５】
［ステップＳ７１］モデル生成部１４０は、プロトコルログから各処理の開始と終了のペアを抽出する。
［ステップＳ７２］モデル生成部１４０は、呼出回数行列を初期化する。この際、制約を満足しない呼出関係は、０に初期化される。
【０２０６】
［ステップＳ７３］モデル生成部１４０は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
［ステップＳ７４］モデル生成部１４０は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップＳ７７に進められる。終了条件を満足していない場合、処理がステップＳ７５に進められる。
【０２０７】
［ステップＳ７５］モデル生成部１４０は、呼出関係候補それぞれの生起確率を、呼出回数行列の値に比例するように計算する。
［ステップＳ７６］モデル生成部１４０は、各呼出関係候補の確率を呼び出し元と呼び出し先との処理種別毎に平均をとり、呼出回数行列を更新する。その後、処理がステップＳ７４に進められる。
【０２０８】
［ステップＳ７７］終了条件を満足した場合、モデル生成部１４０は、呼出回数行列を整数で近似する。
［ステップＳ７８］モデル生成部１４０は、呼出回数行列のゼロ以外の成分を処理種別毎の呼出回数とするトランザクションモデルを出力する。
【０２０９】
以上のように、第２の実施の形態では、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合して、処理間の呼出関係の可能性を算出するようにした。これにより、複数のトランザクションが同時に処理されている場合であっても、モデルを生成することができる。しかも、比較的少ない計算量でモデルを生成できる。
【０２１０】
［第３の実施の形態］
上記第２の実施の形態に示す方法では、処理種別間の呼出回数の平均を使っている。そのため、例えば確率１／２で２回呼び出している状況と確率１で１回呼び出している状況を区別できず、結果として正しいトランザクションモデルを学習できない場合もあり得る。このような状況は、例えば、ある処理種別からの呼出パターンが複数ある場合に発生し得る。これを解決するためには、呼出関係の候補として個々の処理種別間の関係を求めるのではなく、ある処理種別が呼び出す全ての処理の集合や集合内の順序を対象に確率を求めればよい。以下では、この考え方に基づくモデル生成方法を第３の実施の形態として説明する。
【０２１１】
なお、第３の実施の形態におけるシステム分析装置の機能ブロックは、図４に示した第１の実施の形態と同様である。そこで、図４に示した各要素を用いて、第３の実施の形態の処理を説明する。また、第１の実施の形態と第３の形態とは、モデル生成部１４０の処理のみが相違し、他の要素の処理は同じである。
【０２１２】
モデル生成部１４０の入力は、同じく図４０のメッセージ列および制約であるとする。
モデル生成部１４０は、まず初めに、第２の実施の形態と同様に各処理間で可能な呼出関係を求める。結果は図４２に示す通りである。
【０２１３】
次に、図４２に示した可能な呼出関係を元に、各処理が呼び出している処理の集合とそのなかでの順序の候補を求める。例えば、処理Ｐ１が呼び出している処理の順序付きの集合の候補（以下処理集合候補と呼ぶ）は次のように求める。
【０２１４】
図４２に示す呼出関係を解析すると、集合Ｕに含まれる（すなわち処理Ｐ１から呼び出されている）可能性があるのは、処理Ｐ５と処理Ｐ６の２つの処理である。このうち処理Ｐ５は、他に呼び出し元の候補はないので、かならず集合Ｕ含まれる。一方処理Ｐ６は、処理Ｐ２から呼び出されている可能性があるので、集合Ｕに含まれる可能性と含まれない可能性の両方が考えられる。処理Ｐ５と処理Ｐ６では処理Ｐ５のほうが早く開始しているので、集合Ｕの候補は次の２つである。
Ｕ１１：｛処理Ｐ５｝
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝
なお、集合及び処理集合候補の記述では、呼び出されるのが早い処理から順に左から記述するものとする。この段階では、この２つの候補のどちらが信頼できるかに関する判断材料が全くないため、信頼度は両者同じ、すなわち、１／２とする。
【０２１５】
次に、処理集合候補Ｕ１１，Ｕ１２を処理種別による記述に変換し、処理Ｐ１から呼び出される処理のパターン、すなわち呼び出される処理種別の順序付き集合の候補を生成する。処理Ｐ５および処理Ｐ６の処理種別はどちらもａであるので、以下のようになる。
Ｕ１１：パターン｛ａ｝
Ｕ１２：パターン｛ａ，ａ｝
後者の処理集合候補Ｕ１２は、処理Ｐ１が同じ処理種別の処理を２回連続して呼び出している可能性を表している。
【０２１６】
次に、パターンの信頼度を、そのパターンの元になった処理集合の信頼度から計算する。この場合は処理集合候補Ｕ１１、処理集合候補Ｕ１２から異なるパターンが生成されているので、各パターンの信頼度は処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度をそのまま用いる。すなわち１／２とする。
【０２１７】
以上から、処理Ｐ１が呼び出しているパターンの候補とその信頼度は次のようになる。
パターン｛ａ｝：信頼度１／２
パターン｛ａ，ａ｝：信頼度１／２
２番目のパターンは種別ａの処理が２回呼び出されるパターンを示している。モデル生成部１４０は、他の処理についても、その処理が呼び出している処理種別のパターンの候補と信頼度を同様にして求める。
【０２１８】
処理Ｐ２から呼び出される可能性があるのは処理Ｐ６と処理Ｐ７の２つであり、この両者とも他の処理から呼び出されている可能性があるので、処理Ｐ２から呼び出されている処理集合候補は次の４通りである。処理Ｐ１の場合と同様、この段階ではこれら全ての信頼度が同じ、すなわち１／４であるとする。
Ｕ２１：｛｝
Ｕ２２：｛処理Ｐ６｝
Ｕ２３：｛処理Ｐ７｝
Ｕ２４：｛処理Ｐ６，処理Ｐ７｝
処理Ｐ６および７の種別はそれぞれａとｂであるから、処理Ｐ２が呼び出している処理種別のパターンの候補とその信頼度は次のようになる。
パターン｛｝：信頼度１／４
パターン｛ａ｝：信頼度１／４
パターン｛ｂ｝：信頼度１／４
パターン｛ａ，ｂ｝：信頼度１／４
最後のパターンは、ａとｂがこの順序で、すなわち最初に種別ａの処理が呼び出され、その後にｂの処理が呼び出されるパターンを表している。なお、順序を考慮せず、呼び出される処理種別毎の回数をパターンとすることもできる。
【０２１９】
処理Ｐ３に関しては注意が必要である。処理Ｐ３からかならず呼び出されているのは処理Ｐ８、処理Ｐ３から呼び出されている可能性はあるが、他の処理から呼び出されている可能性もある処理が、処理Ｐ７、処理Ｐ９、処理Ｐ１０の３個であるから、処理Ｐ３が呼び出している処理集合候補は、
｛処理Ｐ８｝
｛処理Ｐ８，処理Ｐ７｝
｛処理Ｐ８，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝
の８個で、それぞれの信頼度は１／８となる。ここからパターンとその信頼度が計算される。
【０２２０】
ところが、処理Ｐ７と処理Ｐ９が共に種別ｂの処理であることから、｛処理Ｐ８，処理Ｐ７｝と｛処理Ｐ８，処理Ｐ９｝からは同一のパターン｛ａ，ｂ｝が生成される。同様に｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝と｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝からはパターン｛ａ，ｂ，ａ｝が生成される。このような場合には、これらのパターンの信頼度は、対応する処理集合候補の信頼度の和をとることで計算する。よって結果は次のようになる。
パターン｛ａ｝：信頼度１／８
パターン｛ａ，ｂ｝：信頼度１／４
パターン｛ａ，ａ｝：信頼度１／８
パターン｛ａ，ｂ，ｂ｝：信頼度１／８
パターン｛ａ，ｂ，ａ｝：信頼度１／４
パターン｛ａ，ｂ，ｂ，ａ｝：信頼度１／８
処理Ｐ４についてもパターンとその信頼度を求めると次のようになる。
パターン｛｝：信頼度１／４
パターン｛ｂ｝：信頼度１／４
パターン｛ａ｝：信頼度１／４
パターン｛ｂ，ａ｝：信頼度１／４
次に、上で求めた各処理から呼び出される処理種別のパターンとその信頼度を、呼び出し元の処理種別毎に平均をとることで、処理種別毎に、それから呼び出されるパターンとその確率を計算する。
【０２２１】
まず、処理種別Ａに属するのは処理Ｐ１と処理Ｐ４であるから、これらの処理から呼び出されているパターン候補の信頼度の平均を計算する。例えばパターン｛ａ｝は、処理Ｐ１では信頼度１／２、処理Ｐ４では信頼度１／４であるので、処理種別Aからこのパターンが呼び出される確率は、その平均、すなわち３／８となる。一方パターン｛ａ，ａ｝は、処理Ｐ１では信頼度１／２であるが、処理Ｐ４ではパターン候補中に存在しない、すなわち信頼度０であるので、確率は１／４になる。
【０２２２】
図５０は、処理種別Ａからの呼出パターンとその確率を示す第１の図である。図５０に示すように、パターンＡ１｛｝の確率は、（０＋１／４）／２＝１／８である。パターンＡ２｛ｂ｝の確率は（０＋１／４）／２＝１／８である。パターンＡ３｛ａ｝の確率は、（１／２＋１／４）／２＝３／８である。パターンＡ４｛ａ，ａ｝の確率は、（１／２＋０）／２＝１／４である。パターンＡ５｛ｂ，ａ｝の確率は（０＋１／４）／２＝１／８である。
【０２２３】
同様に処理種別Ｂに属する処理、すなわち処理Ｐ２および処理Ｐ３の平均をとると、処理種別Ｂから呼び出されるパターンとその確率を以下のように計算される。
図５１は、処理種別Ｂからの呼出パターンとその確率を示す第１の図である。図５１に示すように、パターンＢ１｛｝の確率は、（１／４＋０）／２＝１／８である。パターンＢ２｛ａ｝の確率は、（１／４＋１／８）／２＝３／１６である。パターンＢ３｛ｂ｝の確率は、（１／４＋０）／２＝１／８である。パターンＢ４｛ａ，ｂ｝の確率は、（１／４＋１／４）／２＝１／４である。パターンＢ５｛ａ，ａ｝の確率は、（０＋１／８）／２＝１／１６である。パターンＢ６｛ａ，ｂ，ｂ｝の確率は、（０＋１／８）／２＝１／１６である。パターンＢ７｛ａ，ｂ，ａ｝の確率は、（０＋１／４）／２＝１／８である。パターンＢ８｛ａ，ｂ，ｂ，ａ｝の確率は、（０＋１／８）／２＝１／１６である。
【０２２４】
次にこれの処理種別毎の呼び出されるパターンとその確率を使って、もう一度各処理から呼び出される処理の集合の候補（処理集合候補）とその信頼度を計算しなおす。
まず、処理Ｐ１について考える。
処理Ｐ１で可能な呼び出し処理集合候補が
Ｕ１１：｛処理Ｐ５｝
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝
であるのは同じである。ただし前回はどちらがよりもっともらしいかを判断する材料がなかったため信頼度を同じにしたが、今回は判断材料として図５０および図５１に示した処理種別毎の呼出パターンの信頼度を使うことができる。
【０２２５】
ただし、処理集合候補Ｕ１１と処理集合候補Ｕ１２の信頼度は、処理Ｐ１からの呼出パターンの確率だけではなく、このどちらかを選択するかによって呼び出し候補が影響される他の処理も考慮する必要がある。
【０２２６】
処理集合候補Ｕ１１と処理集合候補Ｕ１２の差は処理Ｐ６が処理Ｐ１からよびだされているかどうかである。処理Ｐ６は処理Ｐ１または処理Ｐ２から呼び出されているから、例えば処理集合候補Ｕ１１を選択するということは、単に処理Ｐ１から処理Ｐ６が呼び出されないことだけの選択ではなく、処理Ｐ２から処理Ｐ６が呼び出されている、という選択でもある。よって処理集合候補Ｕ１１の信頼度を計算する際には、それによって処理Ｐ２からの呼び出しの選択がどれだけ制限されるかを考慮する必要がある。
【０２２７】
処理集合候補Ｕ１１となる場合、処理Ｐ１（種別Ａ）からの呼出パターンはＡ３であり、このパターンの確率は３／８である。一方、処理集合候補Ｕ１２の場合はパターンＡ４であるから確率は１／４である。ただし処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度はこれらの確率をそのまま使うのではなく、それによって他の処理からの呼出パターンがどのように制限されるかを考慮する。
【０２２８】
すなわち、例えば処理Ｐ１からの呼び出しが処理集合候補Ｕ１１の場合、処理Ｐ６は処理Ｐ１から呼ばれないことになる。そのため、他の候補、すなわち処理Ｐ２からかならず呼ばれることになる。よって処理Ｐ２から呼び出される処理の集合は｛処理Ｐ６｝または｛処理Ｐ６，処理Ｐ７｝でなければならない。
【０２２９】
処理Ｐ６および処理Ｐ７の種別はａおよびｂであるから、処理種別のパターンでいうとＢ２またはＢ４であり、確率はそれぞれ３／１６および１／４である。よって処理集合候補Ｕ１１の信頼度は、処理Ｐ２側の確率はこれらの確率の和、すなわち７／１６と見積もることができる。これを使って、処理集合候補Ｕ１１の信頼度は、処理Ｐ１側で処理集合候補Ｕ１１が呼び出される確率３／８と処理Ｐ２側の制限からくる確率７／１６の積、すなわち２１／１２８とする。
【０２３０】
一方、処理集合候補Ｕ１２の場合には、処理Ｐ６は処理Ｐ１から呼び出されているので、処理Ｐ２側の呼び出される処理の集合の候補は｛｝または｛処理Ｐ７｝のいずれか、処理種別のパターンではＢ１またはＢ３である。これらの確率は共に１／８であるので、処理集合候補Ｕ１２の信頼度は１／４×（１／８＋１／８）＝１／１６＝８／１２８となる。
【０２３１】
処理集合候補Ｕ１１および処理集合候補Ｕ１２のいずれかはかならず正しいので、両者の信頼度の和が１になるように正規化を行い、最終的に処理集合候補Ｕ１１および処理集合候補Ｕ１２の信頼度を
Ｕ１１：｛処理Ｐ５｝信頼度２１／２９
Ｕ１２：｛処理Ｐ５，処理Ｐ６｝ 信頼度８／２９
とする。すなわち処理集合候補Ｕ１１のほうがもっともらしいと判断される。
【０２３２】
次にこれを上と同様に処理種別のパターンとその信頼度に変換する。
パターン｛ａ｝：信頼度２１／２９
パターン｛ａ，ａ｝：信頼度８／２９
処理Ｐ２、処理Ｐ３、処理Ｐ４についても処理Ｐ１の場合と全く同様にして可能な呼び出し処理集合の候補の信頼度を計算し、そこから呼び出し種別のパターン毎の信頼度を計算する。以下にその結果を示す。
【０２３３】
処理Ｐ２については、以下の通りである。
パターン｛｝：信頼度４／３３
パターン｛ａ｝：信頼度９／３３
パターン｛ｂ｝：信頼度５／３３
パターン｛ａ，ｂ｝：信頼度１５／３３
処理Ｐ３については、以下の通りである。
パターン｛ａ｝：信頼度１８／１０１
パターン｛ａ，ｂ｝：信頼度４６／１０１
パターン｛ａ，ａ｝：信頼度６／１０１
パターン｛ａ，ｂ，ｂ｝：信頼度１５／１０１
パターン｛ａ，ｂ，ａ｝：信頼度１１／１０１
パターン｛ａ，ｂ，ｂ，ａ｝：信頼度５／１０１
処理Ｐ４については、以下の通りである。
パターン｛｝：信頼度３／２８
パターン｛ｂ｝：信頼度３／２８
パターン｛ａ｝：信頼度１５／２８
パターン｛ｂ，ａ｝：信頼度７／２８
次に、前と同様にこれらの呼び出し元の処理毎の呼出パターンの信頼度から、処理種別毎の呼出パターンとその確率を、呼び出し元の処理種別毎に平均をとることで求める。
【０２３４】
図５２は、処理種別Ａからの呼出パターンとその確率を示す第２の図である。図５２に示すように、パターンＡ１：｛｝の確率は８７／１６２４＝０．０５４である。パターンＡ２：｛ｂ｝の確率８７／１６２４＝０．０５４である。パターンＡ３：｛ａ｝の確率は１０２３／１６２４＝０．６３０である。パターンＡ４：｛ａ，ａ｝の確率は２２４／１６２４＝０．１３８である。パターンＡ５：｛ｂ，ａ｝の確率は２０３／１６２４＝０．１２５である。
【０２３５】
同様に処理種別Ｂに属する処理、すなわち処理Ｐ２および処理Ｐ３の平均をとると、処理種別Ｂから呼び出されるパターンとその確率を以下のように計算される。
図５３は、処理種別Ｂからの呼出パターンとその確率を示す第２の図である。図５３に示すように、パターンＢ１：｛｝の確率は４０４／６６６６＝０．０６１である。パターンＢ２：｛ａ｝の確率は１５０３／６６６６＝０．２２５である。パターンＢ３：｛ｂ｝の確率は５０５／６６６６＝０．０７６である。パターンＢ４：｛ａ，ｂ｝の確率は３０３３／６６６６＝０．４５５である。パターンＢ５：｛ａ，ａ｝の確率は１９８／６６６６＝０．０３０である。パターンＢ６：｛ａ，ｂ，ｂ｝の確率は４９５／６６６６＝０．０７４である。パターンＢ７：｛ａ，ｂ，ａ｝の確率は３６３／６６６６＝０．０５４である。パターンＢ８：｛ａ，ｂ，ｂ，ａ｝の確率は１６５／６６６６＝０．０２５である。
【０２３６】
この処理毎の呼び出す処理の集合とその信頼度の計算およびそれから処理種別毎の呼出パターンやその確率の計算を適当な終了条件が満足するまで行う。終了条件は、第２の実施の形態と同様、繰り返し回数や、パターン毎の確率の変化量の上限等で行う。
【０２３７】
図５２、図５３に示した状態で終了条件が満足されると、モデル生成部１４０は、図５２および図５３の呼出パターンとその確率から、モデルを生成する。このとき、あまり確率の小さいモデルは信頼性にかける。そのため、呼び出し元の処理種別毎に、可能なパターンの中から確率の高い順に、選択数の上限および確率の下限を使ってモデルとして採用するパターンを選択する。
【０２３８】
例えば選択数の上限を２、確率の下限を０．１とすると、呼出元の処理種別Ａに対してはパターンＡ３とパターンＡ４が、処理種別Ｂに対してはパターンＢ４とＢ２がモデルとして選択される。最終的なモデルは、選択されたパターンのみを使って確率の和が１となるように正規化しなおして生成される。
【０２３９】
図５４は、モデル生成結果を示す図である。ＩＩＯＰの種別Ａに対しては、２つのトランザクションモデル４４１，４４２が生成されている。トランザクションモデル４４１の確率は、０．８２（＝０．６３０／（０．６３０＋０．１３８））であり、トランザクションモデル４４２の確率は、０．１８（＝０．１３８／（０．６３０＋０．１３８））である。
【０２４０】
ＩＩＯＰの種別Ｂに対しては、２つのトランザクションモデル４４３，４４４が生成されている。トランザクションモデル４４３の確率は、０．８０（＝０．５７４／（０．５７４＋０．１４２））であり、トランザクションモデル４４４の確率は、０．２０（＝０．１４２／（０．５７４＋０．１４２））である。
【０２４１】
以上の処理手順を整理すると以下のようになる。
図５５は、第３の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図５５に示す処理をステップ番号に沿って説明する。
【０２４２】
［ステップＳ８１］モデル生成部１４０は、プロトコルログから各処理の開始と終了のペアを抽出する。
［ステップＳ８２］モデル生成部１４０は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
【０２４３】
［ステップＳ８３］モデル生成部１４０は、処理毎に、それを呼び出し元とする呼出関係の候補から、呼び出されている処理の集合（呼出先処理集合）の候補を生成する。
［ステップＳ８４］モデル生成部１４０は、呼出先処理集合の生起確率を初期化する（呼出元の処理毎に均等に確率を割り当てる）。
【０２４４】
［ステップＳ８５］モデル生成部１４０は、呼出先処理集合とその確率から、処理種別による呼出パターンとその確率を計算する。
［ステップＳ８６］モデル生成部１４０は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップＳ８８に進められる。終了条件を満足していない場合、処理がステップＳ８７に進められる。
【０２４５】
［ステップＳ８７］モデル生成部１４０は、呼出先処理集合の候補それぞれの生起確率を、処理種別毎の呼出パターンとその確率から再計算する。その後、処理がステップＳ８５に進められる。
【０２４６】
［ステップＳ８８］終了条件を満足した場合、モデル生成部１４０は、処理種別毎の呼出パターンのうち、所定の条件を満たしたもの（例えば、所定の値より確率の高いもの）をトランザクションモデルとして選択する。
【０２４７】
［ステップＳ８９］モデル生成部１４０は、呼出元の種別毎に、選択されたモデルの確率を正規化する。その後、処理が終了する。
このように第３の実施の形態では、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、発生パターン毎に生起確率を計算する。そして、生起確率が上位の発生パターンを所定の個数選択し、選択された発生パターンに基づいて、トランザクションモデルを生成するようにした。これにより、ある呼出元の処理種別について可能な処理パターンが複数ある場合でも、そのモデルを正しく生成することができる。
【０２４８】
なお、この方法では、多重度が高い場合、処理量が非常に増大する。そこで、以下のような方法で、処理量の軽減を図ることもできる。
第３の実施の形態では処理種別毎に呼び出すパターンとその確率を何度か更新していくことでトランザクションモデルを生成している。そして、最終的に得られたパターンから可能性の低いパターンを除去している。このとき、パターンとその確率の更新の際に、その都度可能性の低いパターンを除去することも可能である。一度除去した呼出パターンは、以後のモデル生成処理中に可能性として考慮する必要がないため、モデル生成の早期に除去することで、モデル生成に要する時間を短縮することができる。
【０２４９】
例えば、図５０および図５１が生成された段階で、すなわち最初に可能なパターンとその確率が生成された段階で、確率が閾値以下となるパターンを削除する。閾値が０．１である場合、図５０に示された処理種別Ａからの呼出パターンの確率は１／８以上であるので削除されない。一方図５１に示された処理種別Ｂからの場合には、パターンＢ５、パターンＢ６、パターンＢ８の３パターンの確率が１／１６で閾値以下となるので、消去することができる。消去されたパターンは、実際の処理からこれらのパターンで処理が呼び出されることはないことを示す。
【０２５０】
これにより、以後再び可能なパターンの確率を求める際に、消去されたパターンは考慮する必要がないことを意味する。例えば種別Ｂの処理Ｐ３からの呼び出される処理の集合は上の例でも記したように
｛処理Ｐ８｝
｛処理Ｐ８，処理Ｐ７｝
｛処理Ｐ８，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ９，処理Ｐ１０｝
｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝
である。処理Ｐ８と処理Ｐ１０の種別がａ、処理Ｐ７と処理Ｐ９の種別がｂであることから、これらのうち｛処理Ｐ８，処理Ｐ１０｝がパターンＢ５、｛処理Ｐ８，処理Ｐ７，処理Ｐ９｝がパターンＢ６、｛処理Ｐ８，処理Ｐ７，処理Ｐ９，処理Ｐ１０｝がパターンＢ８に属する。すなわち、これらの呼び出しは起こり得ない。よって以後の処理でこれらの呼び出しの発生を考慮する必要がなくなる。起こり得ないパターンを判断対象から除外することで、以降の処理量を軽減することができる。
【０２５１】
［その他の応用例］
上記各実施の形態では、スイッチ１０のミラーポートからメッセージを構成するパケットを収集しているが、各サーバ３１，３２，３３において、メッセージのダンプデータを記録しておき、そのメッセージ観測部１２０が各サーバ３１，３２，３３からダンプデータを収集してもよい。
【０２５２】
また、分析部１５０によって分析された内容に応じて、トランザクションモデルを更新することもできる。例えば、任意の種別のトランザクション内の各サーバでの処理時間が分析部１５０で求められると、種別毎の処理時間の平均を求め、対応するトランザクションモデルの処理時間とすることができる。
【０２５３】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム分析装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
【０２５４】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０２５５】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０２５６】
（付記１） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムにおいて、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラム。
【０２５７】
（付記２） 前記メッセージ観測手段は、前記ネットワーク内に設けられたスイッチのミラーポートを介して、前記メッセージの収集を行うことを特徴とする付記１記載のシステム分析プログラム。
【０２５８】
（付記３） 前記メッセージ観測手段は、前記サーバに保持されたメッセージのダンプデータから前記メッセージを収集することを特徴とする付記１記載のシステム分析プログラム。
【０２５９】
（付記４） 前記モデル生成手段は、前記制約条件として、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件が定義されていることを特徴とする付記１記載のシステム分析プログラム。
【０２６０】
（付記５） 前記モデル生成手段は、制約条件として、サーバ間の呼び出し方向が定義されていることを特徴とする付記１記載のシステム分析プログラム。
（付記６） 前記モデル生成手段は、同一トランザクション内の各処理種別のリクエストメッセージからレスポンスメッセージまでの時間に基づいて、各プロトコルに対応する処理の前記サーバでの所要時間を計算し、前記トランザクションモデルに設定することを特徴とする付記１記載のシステム分析プログラム。
【０２６１】
（付記７） 前記モデル生成手段は、クライアントから最初に呼び出されるリクエストメッセージと、当該リクエストメッセージに対応するレスポンスメッセージとから、各トランザクションの処理時間帯を判定し、他のトランザクションとの間で処理時間帯が重複しない非多重トランザクションを検出し、検出された前記非多重トランザクションの処理時間帯内に発生した前記プロトコルログに基づいて前記トランザクションモデルを生成することを特徴とする付記１記載のシステム分析プログラム。
【０２６２】
（付記８） 前記モデル生成手段は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合し、処理間の呼出関係の可能性を算出することを特徴とする付記１記載のシステム分析プログラム。
【０２６３】
（付記９） 前記モデル生成手段は、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、前記発生パターン毎に生起確率を計算し、前記生起確率が上位の前記発生パターンの所定の個数選択し、選択された前記発生パターンに基づいて、前記トランザクションモデルを生成することを特徴とする付記１記載のシステム分析プログラム。
【０２６４】
（付記１０） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析方法において、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
ことを特徴とするシステム分析方法。
【０２６５】
（付記１１） 複数のサーバが接続されたネットワークの運用形態を分析するためのシステム分析装置において、
前記ネットワークを介して受け渡されるメッセージを収集するメッセージ観測手段と、
収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納するメッセージ解析手段と、
モデル生成指示が入力されると、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納するモデル生成手段と、
分析指示が入力されると、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する分析手段と、
を有することを特徴とするシステム分析装置。
【０２６６】
（付記１２） 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体。
【符号の説明】
【０２６７】
１ システム分析装置
１ａ メッセージ観測手段
１ｂ メッセージ解析手段
１ｃ プロトコルログ記憶手段
１ｄ モデル生成手段
１ｅ トランザクションモデル記憶手段
１ｆ 分析手段
１ｇ 出力手段
２ ネットワーク
３ａ，３ｂ，・・・ クライアント
４ａ，４ｂ，・・・ サーバ
５ メッセージ
【特許請求の範囲】
【請求項１】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、
コンピュータに、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、
前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、
を実行させるための分析プログラム。
【請求項２】
前記コンピュータに、
前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションを分析する分析手順、
を実行させるための請求項１記載の分析プログラム。
【請求項３】
前記複数のサーバは階層的に配置され、
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理されるメッセージ対の間に、階層が上位のサーバで処理され他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成し、
前記分析手順は、前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションの処理時間を分析する、
請求項２記載の分析プログラム。
【請求項４】
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子と、該メッセージで要求されている処理種別との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理される処理種別のメッセージ対の間に、階層が上位のサーバで処理される処理種別であって他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から該処理種別に対応する処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成する、
請求項１から３の何れかに記載の分析プログラム。
【請求項５】
前記モデル生成手順は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理種別毎に統合し、処理間の呼出関係の可能性を算出する、
請求項４に記載の分析プログラム。
【請求項６】
前記モデル生成手順は、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、該発生パターン毎に生起確率を計算し、該生起確率が上位の該発生パターンを所定の個数選択し、選択された該発生パターンに基づいて、前記トランザクションモデルを生成する、
請求項４または５記載の分析プログラム。
【請求項７】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、
を有する分析装置。
【請求項８】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、
コンピュータが、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、
分析方法。
【請求項１】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、
コンピュータに、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、
前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、
を実行させるための分析プログラム。
【請求項２】
前記コンピュータに、
前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションを分析する分析手順、
を実行させるための請求項１記載の分析プログラム。
【請求項３】
前記複数のサーバは階層的に配置され、
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理されるメッセージ対の間に、階層が上位のサーバで処理され他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成し、
前記分析手順は、前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションの処理時間を分析する、
請求項２記載の分析プログラム。
【請求項４】
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子と、該メッセージで要求されている処理種別との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理される処理種別のメッセージ対の間に、階層が上位のサーバで処理される処理種別であって他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から該処理種別に対応する処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成する、
請求項１から３の何れかに記載の分析プログラム。
【請求項５】
前記モデル生成手順は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理種別毎に統合し、処理間の呼出関係の可能性を算出する、
請求項４に記載の分析プログラム。
【請求項６】
前記モデル生成手順は、処理種別毎に、呼び出し可能な処理の組み合わせを示す１以上の発生パターンを生成し、該発生パターン毎に生起確率を計算し、該生起確率が上位の該発生パターンを所定の個数選択し、選択された該発生パターンに基づいて、前記トランザクションモデルを生成する、
請求項４または５記載の分析プログラム。
【請求項７】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、
を有する分析装置。
【請求項８】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、
コンピュータが、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、
分析方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図５５】
【公開番号】特開２０１０−１５２８９９（Ｐ２０１０−１５２８９９Ａ）
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願番号】特願２００９−２９８７３５（Ｐ２００９−２９８７３５）
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【分割の表示】特願２００４−１８５９０９（Ｐ２００４−１８５９０９）の分割
【原出願日】平成１６年６月２４日（２００４．６．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願日】平成２１年１２月２８日（２００９．１２．２８）
【分割の表示】特願２００４−１８５９０９（Ｐ２００４−１８５９０９）の分割
【原出願日】平成１６年６月２４日（２００４．６．２４）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]