分析プログラム、分析方法及び分析装置
【課題】システムのサービス提供機能に手を加えずにトランザクションを分析できるようにする。
【解決手段】メッセージ観測手段1aは、ネットワーク2を介して受け渡されるメッセージ5を収集する。するとメッセージ解析手段1bにより、収集したメッセージ5の内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別される。判別された情報はプロトコルログ記憶手段1cに格納される。その後、モデル生成手段1dにより、処理間の呼出関係に基づきトランザクションモデルが生成される。
【解決手段】メッセージ観測手段1aは、ネットワーク2を介して受け渡されるメッセージ5を収集する。するとメッセージ解析手段1bにより、収集したメッセージ5の内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別される。判別された情報はプロトコルログ記憶手段1cに格納される。その後、モデル生成手段1dにより、処理間の呼出関係に基づきトランザクションモデルが生成される。
【発明の詳細な説明】
【技術分野】
【0001】
本発明はトランザクションを分析するための分析プログラム、分析方法及び分析装置に関する。
【背景技術】
【0002】
最近のIT(情報通信技術)を利用したコンピュータシステムは大規模かつ複雑な構成であることが多い。例えば、オンラインバンキングの入金や振込み処理など、各種業務サービスがWebサーバ/アプリケーションサーバ/データベース(DB)サーバからなるWeb3階層システムにて提供される例が増えている。こういったシステムは、業務の効率化やセキュリティ対策などの理由から大規模で複雑な構成である。また、即時性を要求される業務サービスが多く、サービス停止やレスポンス悪化は大きな問題である。そのため、大規模システムに対する運用状況の詳細な把握や性能問題の迅速な解決が必須である。
【0003】
しかも、複数のアプリケーションが連携して動作する複雑なシステム(Web3階層システムなど)で、性能劣化や障害の原因を突き止めるためには、サーバそれぞれの挙動だけでなくシステム全体としての性能を観測・分析することが必要である。例えば、Web3階層システムにおいては、Webサーバへの処理要求に伴ってアプリケーションサーバへの処理要求が発生する場合がある。アプリケーションサーバ・DBサーバ間についても同様である。こういったアプリケーション間における処理の呼出関係は、性能問題のシステム内への波及を調べる上で必須である。
【0004】
そこで、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡する機能が望まれている。このような追跡が可能となれば、システムに存在する問題の分析が容易となる。
【0005】
サーバ間の処理の受け渡しを追跡する技術としては、例えば、各サーバにエージェントを実装し、そのエージェントに個々のサーバの運用状況を解析及びレポートさせる技術がある(例えば、非特許文献1参照)。
【0006】
エージェントによって運用状態を把握し、その結果をレポートする技術は実用化されている(例えば、非特許文献2,3参照)。
【先行技術文献】
【非特許文献】
【0007】
【非特許文献1】「Technical Standard Application Response Measurement(ARM) Issue4.0-C Binding」THE OPEN GROUP、2003年10月、Figure 2
【非特許文献2】「IBM Tivoli Monitoring for Transaction Performance helps maximize performance of your applications.」,"IBM Corporation Software Group",2003年9月
【非特許文献3】「IBM Tivoli Monitoring for Transaction Performance, Version 5.2」,"IBM Corporation Software Group"、2003年9月
【発明の概要】
【発明が解決しようとする課題】
【0008】
しかし、従来の技術では、アプリケーション単位の詳細な情報を取得する場合には、各サーバに対してエージェント等の何らかのアプリケーションを組み込んで対応する必要がある。そのため、既存システムの性能分析が困難である。特に最近のシステムでは、アプリケーション毎に異なる企業によって作成されている。従って、全てのアプリケーションについて、エージェントとの間の情報の受け渡しを行うように改良することは困難である。
【0009】
本発明はこのような点に鑑みてなされたものであり、システムのサービス提供機能に手を加えずにトランザクションを分析できる分析プログラム、分析方法及び分析装置を提供することを目的とする。
【課題を解決するための手段】
【0010】
本発明では上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、コンピュータに、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、を実行させるための分析プログラムが提供される。
【0011】
また、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、を有する分析装置が提供される。
【0012】
さらに、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、コンピュータが、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、分析方法が提供される。
【発明の効果】
【0013】
本発明では、メッセージ集合からのトランザクションモデルの生成が可能となる。
【図面の簡単な説明】
【0014】
【図1】実施の形態に適用される発明の概念図である。
【図2】第1の実施の形態に係るシステム構成を示す図である。
【図3】システム分析装置のハードウェア構成例を示す図である。
【図4】システム分析装置の機能ブロックを示す図である。
【図5】システム分析処理の手順を示すフローチャートである。
【図6】メッセージ観測状況を示す概念図である。
【図7】パケットデータ記憶部のデータ構造例を示す図である。
【図8】パケットに含まれる情報を示す図である。
【図9】IPヘッダの詳細を示す図である。
【図10】TCPヘッダの詳細を示す図である。
【図11】メッセージ解析部の機能を示すブロック図である。
【図12】再構成したセッションの例である。
【図13】メッセージ再構成例を示す第1の図である。
【図14】リクエストへのレスポンスメッセージの対応付けの例を示す図である。
【図15】オブジェクト名の割り当て例を示す図である。
【図16】1つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。
【図17】プロトコルログの例を示す図である。
【図18】プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。
【図19】トランザクションモデル生成処理を示すフローチャートである。
【図20】選択されるモデル生成用メッセージを示す図である。
【図21】「残高確認」トランザクションのモデル生成例を示す図である。
【図22】「入金」トランザクションのモデル生成例を示す図である。
【図23】分析処理の手順を示すフローチャートである。
【図24】分析部へ入力されるメッセージの例を示す図である。
【図25】メッセージ分析例を示す第1の図である。
【図26】メッセージ分析例を示す第2の図である。
【図27】メッセージ分析例を示す第3の図である。
【図28】メッセージ分析例を示す第4の図である。
【図29】メッセージ分析例を示す第5の図である。
【図30】メッセージ分析例を示す第6の図である。
【図31】メッセージ分析例を示す第7の図である。
【図32】メッセージ分析例を示す第8の図である。
【図33】メッセージ分析例を示す第9の図である。
【図34】メッセージ分析例を示す第10の図である。
【図35】サーバの平均処理時間の表示例を示す図である。
【図36】トランザクション別処理時間及び内訳の表示例を示す図である。
【図37】処理時間ヒストグラムの表示例を示す図である。
【図38】複数の情報を同時に表示した場合の画面例を示す図である。
【図39】表示対象要素間の連携の様子を示す図である。
【図40】分析部へ入力されるメッセージの例を示す図である。
【図41】モデル生成部に入力されたメッセージから認識される処理を示す図である。
【図42】制約を満たす処理間の呼出関係を示す図である。
【図43】呼出回数行列の例を示す図である。
【図44】呼び出し候補の確率を求めた結果を示す図である。
【図45】更新後の呼出回数行列を示す図である。
【図46】2回目の処理で呼び出し候補の確率を求めた結果を示す図である。
【図47】2回目の更新後の呼出回数行列を示す図である。
【図48】最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。
【図49】第2の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【図50】処理種別Aからの呼出パターンとその確率を示す第1の図である。
【図51】処理種別Bからの呼出パターンとその確率を示す第1の図である。
【図52】処理種別Aからの呼出パターンとその確率を示す第2の図である。
【図53】処理種別Bからの呼出パターンとその確率を示す第2の図である。
【図54】モデル生成結果を示す図である。
【図55】第3の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【発明を実施するための形態】
【0015】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【0016】
図1は、実施の形態に適用される発明の概念図である。システム分析装置1は、ネットワーク2を介してクライアント3a,3b,・・・やサーバ4a,4b,・・・に接続されている。サーバ4a,4b,・・・は、クライアント3a,3b,・・・からの要求に応じてサービスを提供する。サービスの提供は、複数のサーバ4a,4b,・・・によって互いに連携して実行される。このときシステム分析装置1は、ネットワーク2を介して送受信されるメッセージ5を取得し、ネットワーク2の運用形態を分析する。分析を行うために、システム分析装置1は、図1に示す各機能を有している。
【0017】
メッセージ観測手段1aは、ネットワーク2を介して受け渡されるメッセージ5を収集する。収集したメッセージ5は、メッセージ解析手段1bに渡される。
メッセージ解析手段1bは、収集したメッセージの内容を解析して、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージか(メッセージの方向)を判別する。処理種別は、例えば、メッセージに適用されているプロトコルがHTTP(HyperText Transfer Protocol)であれば、処理要求で指定されたURL(Uniform Resource Locator)によって判別できる。そして、メッセージ解析手段1bは、判別された情報をプロトコルログとしてプロトコルログ記憶手段1cに格納する。
【0018】
モデル生成手段1dは、モデル生成指示が入力されると、プロトコルログ記憶手段1cに格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を認識する。そして、モデル生成手段1dは、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成する。モデル生成手段1dは、生成したトランザクションモデルをトランザクションモデル記憶手段1eに格納する。
【0019】
なお、選択基準としては、例えば、処理時間帯が他のトランザクションと重複しない非多重トランザクションの時間帯内のメッセージの集合を選択することが定められる。また、制約条件は、例えば、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件である。
【0020】
分析手段1fは、分析指示が入力されると、トランザクションモデル記憶手段1eに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログをプロトコルログ記憶手段1cから抽出し、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する。例えば、トランザクション内での各サーバでの処理時間が分析される。
【0021】
出力手段1gは、分析手段1fによる分析結果を、グラフ等の視覚的に認識しやすい統計情報としてモニタ等に出力する。
このようなシステム分析装置1であれば、メッセージ観測手段1aにより、ネットワーク2を介して受け渡されるメッセージ5が収集される。すると、メッセージ解析手段1bにより、収集したメッセージの内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別され、判別された情報がプロトコルログとしてプロトコルログ記憶手段1cに格納される。
【0022】
このとき、モデル生成指示が入力されると、モデル生成手段1dにより、プロトコルログ記憶手段に格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理が認識される。そして、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、制約条件を満たすトランザクションモデルが生成される。そして、生成されたトランザクションモデルがトランザクションモデル記憶手段1eに格納される。
【0023】
また、分析指示が入力されると、分析手段1fにより、トランザクションモデル記憶手段1eに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログがプロトコルログ記憶手段1cから抽出され、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態が分析される。分析結果は、出力手段1gによって出力され、ユーザに対して提示される。
【0024】
このように、ネットワーク2を介して受け渡されるメッセージ5から、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合からトランザクションモデルを生成するようにした。すなわち、処理間の呼出関係として生起確率が高い関係を選択し、その関係によって成立するトランザクションをモデル化している。このようにして生成したトランザクションモデルと合致するメッセージをプロトコルログから検出することで、サーバ4a,4bに対して機能追加を行わずに、共通のトランザクションを構成するメッセージ集合を特定し、処理状態の解析が可能となる。
【0025】
以下、本発明の実施の形態について詳細に説明する。
[第1の実施の形態]
第1の実施の形態では、インターネットバンキングの業務サービスを提供するWeb3階層システムにおいて、「残高確認」と「入金」との2つのサービスを提供する場合の例である。
【0026】
なお、第1の実施の形態では、管理対象となる要素として「セッション」、「メッセージ」、「オブジェクト」、及び「トランザクション」がある。
「セッション」は、送受信側のIP(Internet Protocol)アドレスとポート番号によって定まる通信路上で送受信されるデータの集合である。
【0027】
「メッセージ」は、TCP(Transmission Control Protocol)セッション上で複数の機器がやりとりするデータの最小単位である。例えば、HTTPでのリクエストやそれに対するレスポンスが、メッセージに該当する。
【0028】
「オブジェクト」は、サーバがメッセージを受信してからレスポンスを送信するまでに行う単一又は複数の処理や入力されるデータを仮想的に単一のものとしてまとめたものである。ここで言う処理とは、CPU(Central Processing Unit)での計算、データの入出力とそれぞれに対する待ち時間などが含まれる。
【0029】
「トランザクション」は、システムに対する要求によって発生するオブジェクト処理の集合である。
図2は、第1の実施の形態に係るシステム構成を示す図である。図2の例では、スイッチ10を介して、クライアント21,22,23、Webサーバ31、アプリケーションサーバ32、データベース(DB)サーバ33、及びシステム分析装置100が接続されている。Webサーバ31、アプリケーションサーバ32、及びDBサーバ33は、クライアント21,22,23からの要求に応じて、サービスを提供する。
【0030】
サービスを提供する為のトランザクションにおいて、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33間で、スイッチ10を介してメッセージの送受信が行われる場合がある。このスイッチ10を介して送受信されるメッセージをシステム分析装置100が監視することで、システムの動作状態の分析を行うことができる。
【0031】
図3は、システム分析装置のハードウェア構成例を示す図である。システム分析装置100は、CPU101によって装置全体が制御されている。CPU101には、バス107を介してRAM(Random Access Memory)102、ハードディスクドライブ(HDD:Hard Disk Drive)103、グラフィック処理装置104、入力インタフェース105、および通信インタフェース106が接続されている。
【0032】
RAM102には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM102には、CPU101による処理に必要な各種データが格納される。HDD103には、OSやアプリケーションプログラムが格納される。
【0033】
グラフィック処理装置104には、モニタ11が接続されている。グラフィック処理装置104は、CPU101からの命令に従って、画像をモニタ11の画面に表示させる。入力インタフェース105には、キーボード12とマウス13とが接続されている。入力インタフェース105は、キーボード12やマウス13から送られてくる信号を、バス107を介してCPU101に送信する。
【0034】
通信インタフェース106は、スイッチ10に接続されている。通信インタフェース106は、スイッチ10を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図3には、システム分析装置100のハードウェア構成例を示したが、クライアント21,22,23、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33も同様のハードウェア構成で実現することができる。
【0035】
図4は、システム分析装置の機能ブロックを示す図である。システム分析装置100は、パケットデータ記憶部111、プロトコルログ記憶部112、モデル記憶部113、分析結果記憶部114、メッセージ観測部120、メッセージ解析部130、モデル生成部140、分析部150、及び出力部160を有している。
【0036】
パケットデータ記憶部111は、スイッチ10を介して送受信されたメッセージを構成するパケット記憶するための記憶装置である。プロトコルログ記憶部112は、パケットを解析することにより取得したメッセージの情報を記憶するための記憶装置である。モデル記憶部113は、トランザクションを完了するまでに送受信されるメッセージのリスト(トランザクションモデル)を記憶する記憶装置である。分析結果記憶部114は、メッセージの分析結果を記憶する記憶装置である。
【0037】
メッセージ観測部120は、スイッチ10を介して送受信されるメッセージを観測し、そのメッセージを構成するパケットをパケットデータ記憶部111に格納する。
メッセージ解析部130は、パケットデータ記憶部111に格納されたパケットの内容を解析し、解析結果をプロトコルログ記憶部112に格納する。
【0038】
モデル生成部140は、プロトコルログ記憶部112に格納された情報に基づいてトランザクションモデルを生成し、モデル記憶部113に格納する。
分析部150は、プロトコルログ記憶部112に格納された情報と、モデル記憶部113に格納されたトランザクションモデルとを比較して、各トランザクションの処理時間等の統計情報を分析する。そして、分析部150は、分析結果を分析結果記憶部114に格納する。
【0039】
出力部160は、分析結果記憶部114に格納されている分析結果を、グラフ等でモニタ11等に出力する。
このような構成のシステム分析装置100で、次のようなシステム分析処理が実行される。
【0040】
図5は、システム分析処理の手順を示すフローチャートである。以下、図5に示す処理をステップ番号に沿って説明する。
[ステップS11]メッセージ観測部120は、スイッチ10を流れるメッセージを観測し、パケットデータ記憶部111に格納する。
【0041】
[ステップS12]メッセージ解析部130は、パケットデータ記憶部111に格納されたメッセージを解析する。
[ステップS13]その後、モデル生成部140により、モデル生成指示が入力されているか否かが判断されるとともに、分析部150により、分析指示が入力されているかが判断される。モデル生成指示や分析指示は、例えば、システム分析装置100の管理者によるキーボード12等を用いた操作入力によって与えられる。モデル生成指示が入力されている場合、処理がステップS14に進められる。分析指示が入力されている場合、処理がステップS15に進められる。
【0042】
[ステップS14]モデル生成指示が入力されている場合、モデル生成部140は、プロトコルログ記憶部112に格納されている情報を参照し、トランザクションモデルを生成する。そして、モデル生成部140は、生成したトランザクションモデルをモデル記憶部113に格納する。その後、処理が終了する。
【0043】
[ステップS15]分析指示が入力されている場合、分析部150は、モデル記憶部113に格納されているトランザクションモデルとプロトコルログ記憶部112に格納されている情報とを参照し、実行されているトランザクションに関する情報を分析する。そして、分析部150は、分析結果を分析結果記憶部114に格納する。
【0044】
[ステップS16]出力部160は、分析結果記憶部114に格納された分析結果に基づいて、統計情報等をモニタ11に出力する。その後、処理が終了する。
このような手順でシステム分析が行われる。以下、図5に示す各ステップの処理を、詳細に説明する。
【0045】
まず、メッセージ観測処理について説明する。
図6は、メッセージ観測状況を示す概念図である。この例では、Webサーバ31、アプリケーションサーバ32、DBサーバ33が監視対象となっている。各サーバは、スイッチ10の個別のポート11,12,13に接続されている。また、システム管理装置100は、スイッチ10のポート14に接続されている。
【0046】
スイッチ10は、自身を通過するデータをミラーリングする機能を有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。
【0047】
図6の例では、Webサーバ31が接続されたポート11、アプリケーションサーバ32が接続されたポート12、及びDBサーバ33が接続されたポート13のミラーリング先として、システム分析装置100が接続されたポート14が指定されている。これにより、各サーバ宛のパケットは宛先となるサーバに入力されるとともに、システム分析装置100にも入力される。
【0048】
例えば、クライアント21からの要求に応じて、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33が連動してサービスを提供する場合を想定する。この場合、まず、クライアント21からWebサーバ31に対してパケット41(例えば、HTTPのパケット)が送信される。このとき、パケット41と同じ内容のパケット51がシステム分析装置100に入力される。次に、Webサーバ31からアプリケーションサーバ32へパケット42(例えば、IIOP(Internet Inter-ORB Protocol)のパケット)が送信されると、パケット42と同じ内容のパケット52がシステム分析装置100に入力される。さらに、アプリケーションサーバ32からDBサーバ33へ、パケット43(例えば、DBアクセスのパケット)が送信されると、パケット43と同じ内容のパケット53がシステム分析装置100に入力される。
【0049】
システム分析装置100に入力されたパケット51,52,53は、スイッチ10に直接接続されたメッセージ観測部120で取得され、パケットデータ記憶部111に格納される。具体的には、メッセージ観測部120は、スイッチ10から送られたパケット51,52,53をキャプチャし、受信時刻とともにパケットデータ記憶部111に格納する。
【0050】
なお、メッセージ観測部120は、キャプチャしたパケット51,52,53を蓄積せずに、観測と同時にメッセージ解析部130に送ってもよい。また、メッセージ観測部120は、メッセージ観測手段において必要なパケットのみをキャプチャすることもできる。さらに、スイッチ10において必要なデータのみを選択してミラーリングすることもできる。
【0051】
図7は、パケットデータ記憶部のデータ構造例を示す図である。パケットデータ記憶部111には、複数のパケット551〜558が格納されている。また、パケットデータ記憶部111には、各パケットデータ551〜558の受信時刻を示す時刻情報61〜68が格納されている。
【0052】
図8は、パケットに含まれる情報を示す図である。時刻情報61とともに格納されているパケット551は、イーサネットヘッダ(Etherヘッダ)(イーサネット:登録商標)551a、IPヘッダ551b、TCPヘッダ551c、及びTCPデータ551dで構成される。
【0053】
図9は、IPヘッダの詳細を示す図である。IPヘッダ551bは、バージョン情報(version)、ヘッダ長、サービスタイプ(Type of Service)、データ長、識別子(ID)、フラグ(Flag)、フラグメントオフセット(Fragment Offset)、生存時間(Time Of Live)、プロトコル(Protocol)、ヘッダチェックサム(Header Checksum)、送信側IPアドレス、受信側IPアドレス、オプション(Option)、及びパディング(Padding)で構成されている。
【0054】
図10は、TCPヘッダの詳細を示す図である。TCPヘッダ551cは、送信側ポート、受信側ポート、送信用シーケンス番号(Sequence Number)、応答確認番号(Acknowledge Number)、ヘッダ長、リザーブ(Reserved)、フラグ、ウィンドウ(Window)、チェックサム(Checksum)、緊急ポインタ(Urgent Pointer)、及びオプション(Option)で構成される。フラグは、さらに、URG(Urgent Flag)、ACK(Acknowledgement Flag)、PSH(Push Flag)、RST(Reset Flag)、SYN(Synchronize Flag)、FIN(Fin Flag)で構成される。
【0055】
メッセージ観測部120で取得したパケットは、メッセージ解析部130で解析される。
図11は、メッセージ解析部の機能を示すブロック図である。メッセージ解析部130は、TCP/UDP(User Datagram Protocol)セッション再構成部131、メッセージ再構成部132、オブジェクト名割り当て部133、及びログ出力部134を有している。
【0056】
TCP/UDPセッション再構成部131は、パケット551〜558を、そのパケット551〜558が属するセッション71〜73毎に振り分ける。メッセージ再構成部132は、セッション71〜73に振り分けられたパケット551〜558の中から所定のデータを抽出し、メッセージ対81〜83を再構成する。オブジェクト名割り当て部133は、メッセージ対81〜83に対応するオブジェクト名を決定する。ログ出力部134は、処理結果をプロトコルログ記憶部112に出力する。
【0057】
メッセージ観測部120からメッセージ解析部130にパケット551〜558が入力されると、TCP/UDPセッション再構成部131、メッセージ再構成部132、オブジェクト名割り当て部133、ログ出力部134の順番で、処理が実行される。なお、メッセージ観測部120から渡されるパケット551〜558は、パケットデータ記憶部111に予め格納されたパケットが渡される場合と、メッセージ観測部120によって観測されたパケットが転送される場合とがある。
【0058】
以下、メッセージ解析部130内の各要素が実行する処理を、詳細に説明する。
メッセージ解析部130に渡されたパケット551〜558は、まず、TCP/UDPセッション再構成部131に入力される。TCP/UDPセッション再構成部131は、入力されたパケット551〜558のセッション別の振り分けを行う。
【0059】
具体的には、TCP/UDPセッション再構成部131は、まずパケット551のIPヘッダ551bから、送受信側IPアドレス(図9参照)を取得する。次に、TCP/UDPセッション再構成部131は、TCPヘッダ551cから送信側ポート番号と受信側ポート番号とを取得する(図10参照)。そして、TCP/UDPセッション再構成部131は、取得した4つの値の組をセッションの識別子とする。このとき、識別子に一意な番号を割り当てることもできる。
【0060】
TCP/UDPセッション再構成部131は、各パケット551〜558の識別子を生成し、同じ識別子を持つパケットを、同じセッションで送られたパケットであるとして振り分ける。
【0061】
次に、TCP/UDPセッション再構成部131は、TCPの場合、TCPヘッダ551cに含まれるフラグを読み取って、開始・確立・切断などのセッション状態を取得する(図10参照)。例えば、SYN「1」のパケットの検出によってセッションの開始を認識し、そのパケットに対するACK「1」の応答によってセッションの確立を認識し、セッション確立状態でデータ伝送とそれに対するACK「1」の応答が繰り返し行われ、最後にFIN「1」パケットの検出によってセッションの切断を認識する。
【0062】
また、TCP/UDPセッション再構成部131は、IPヘッダ551b・TCPヘッダ551cに含まれるデータ長とヘッダ長を取得して、データ長から各ヘッダ長を引くことでデータ部の長さ(データサイズ)を取得する。
【0063】
さらに、TCP/UDPセッション再構成部131に対して、事前に各サーバのIPアドレスを与えておくことで、IPアドレスの組から各パケットの送信方向を決定することもできる。
【0064】
また、TCP/UDPセッション再構成部131は、例えば、パケットのIPヘッダから、サーバアドレスが送信アドレスにあれば送信側ポート番号を、サーバアドレスが宛て先アドレスにあれば受信側ポート番号を読み取る。そして、TCP/UDPセッション再構成部131は、そのポート番号を識別子とすることでどのサービスに関するセッションであるかを調べることができる。例えば、サーバ側のポートが80番である場合、Webサーバとの通信(HTTP)であると判定する。
【0065】
図12は、再構成したセッションの例である。TCP/UDPセッション再構成部131によって、パケット551〜558からTCPのセッション71〜73が再構成される。図12では、縦軸が時間軸を表している(図中、上から下に時間が進行する)。
【0066】
各軸の上の数字が、各機器のIPアドレスを表している。IPアドレスの組によってパケットが振り分けられている。図12では、各パケットから取得したフラグもしくはデータサイズとともに時系列のシーケンスで表示されている。
【0067】
このように、セッション71〜73毎に振り分けられたパケットがメッセージ再構成部132に渡される。
メッセージ再構成部132は、セッション71〜73毎に振り分けられたパケットのデータ部からメッセージを再構成する。メッセージ再構成部132では、まず同一のセッション71〜73で送受信されるパケットの集まりからデータ部分を抜き出して並べる。そして、メッセージ再構成部132は、並べられたデータ部分の列を、プロトコルのフォーマットに従ってメッセージのサイズを取得してメッセージを分割する。このとき、メッセージが複数に分割送信されていた場合には、複数のデータ部分を連結してひとつのメッセージを切り出してよい。もしくは、連結された複数のメッセージが送信されていた場合には、単一のデータ部から複数のメッセージを切り出してよい。また、各メッセージにはセッション上で一意な番号を割り振ってよい。
【0068】
図13は、メッセージ再構成例を示す第1の図である。図13は、送信側IPアドレスが10.25.214.10、受信側IPアドレスが10.25.214.105、送信側ポート番号が3449、受信側ポート番号が80である識別子を持つセッション71上のメッセージを解析する例である。
【0069】
メッセージ再構成部132は、パケット554の属するセッションの受信側ポート番号が80番であることから、パケット554のデータ部をHTTPによるクライアント21からWebサーバ31へのリクエストであると判定し、HTTPメッセージとして切り分ける。
【0070】
HTTPの場合、メッセージ再構成部132は、データから特定のオクテットの組み合わせ(0x0D0A0D0A=\r\n\r\n)を検索し、その位置までをヘッダ部(HTTPヘッダ)とする。次に、データ部(HTTPデータ)が存在する場合には、ヘッダ部に含まれるContent-Lengthフィールドからデータ部の長さを取得し、メッセージを切り出すとともに、メッセージを構成する最初のパケット554の受信時刻「00.00.00:100」をそのメッセージの受信時刻とする。そして、メッセージ再構成部132は、メッセージ種別や要求されたURL、応答結果データを取得する。
【0071】
例えばHTTPメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・URL・個別のパラメータなどがある。また、例えばIIOPメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・メソッド名・個別のパラメータなどがある。さらに、例えばDBメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・SQL(Structured Query Language)文・SQL文のパラメータなどがある。
【0072】
図13の例では、HTTPリクエストメッセージのヘッダの先頭がPOSTであり、その直後が/corba/servlet/Balanceであることからメッセージ種別はPOST、オブジェクトを表すURLは/corba/servlet/Balanceであることが分かる。また、Content-Lengthフィールドの値が29であることからデータ部の長さは29バイトあることが分かる。したがって、メッセージ再構成部132は、ヘッダ終端から29バイトまでをメッセージとして切り出す。
【0073】
また、メッセージ再構成部132では、実行主体に対するリクエストメッセージとその返答であるレスポンスメッセージを対応付け、応答までにかかった時間を算出する。例えばHTTPの場合、リクエストメッセージを、同一のセッション上で直後に現れるレスポンスメッセージと対応付ける。また、レスポンスメッセージの受信時刻からリクエストメッセージの受信時刻を差し引き、このメッセージ対の応答時間とする。また、このとき、対応付けたメッセージ対に一意な番号を割り当ててもよい。
【0074】
図14は、リクエストへのレスポンスメッセージの対応付けの例を示す図である。図14の例では、HTTPレスポンスメッセージとHTTPリクエストメッセージとを対応付ける場合を示している。
【0075】
図13のパケット554から取得したメッセージと、図14のパケット556から取得したメッセージは、送信側IPアドレス10.25.214.105、受信側IPアドレス10.25.214.10、送信側ポート番号80、受信側ポート番号3449のセッション上でやりとりされたメッセージであることから、図14のパケット556から取得したメッセージは、図13のパケット554から取得したメッセージと同一セッション上で連続して送信されたメッセージであると判定する。また、2つのメッセージの送信方向が反対であることから、これら2つのメッセージを対応付けて、メッセージ対が生成される。メッセージ再構成部132は、メッセージ対の応答時間を算出し、これら二つのメッセージに共通の識別番号1を割り当てる。
【0076】
このようにして、メッセージ対がオブジェクト名割り当て部133に渡される。そして、オブジェクト名割り当て部133では、メッセージ対に対応するオブジェクト名が決定される。
【0077】
なお、オブジェクト名は、以降の装置で分析したい内容に応じて変更してよい。また、異なるメッセージに対して同じオブジェクト名を割り当ててもよく、単一のメッセージに対して複数のオブジェクト名を割り当ててもよい。また、取得できる全ての情報を仮のオブジェクト名として割り当てておき、以降の装置においてオブジェクト名を再び決定してもよい。
【0078】
例えばHTTPメッセージ対にオブジェクト名としてURLを割り当てる。これは、実行する処理とメッセージを関連付けるための情報がURL中に含まれることによる。
また、例えばIIOPメッセージ対にオブジェクト名としてメソッド名を割り当てる。これは、IIOPのメソッド名がサーバ上における単一の処理を表すためである。
【0079】
また、例えばDBメッセージ対にオブジェクト名としてSelect・Insert・Update・FetchなどのSQLオペレータ種別とデータベーステーブル名の組を割り当てる。これは、データベース操作による書き込みの有無や、操作する対象となるデータベーステーブルのサイズなどによって異なる処理の量や時間を区別するためである。
【0080】
図15は、オブジェクト名の割り当てとメッセージの解析結果を示す図である。この例ではHTTPの図14で対応付けたメッセージ対81に対してオブジェクト名81cを割り当てている。このオブジェクト名81cは、リクエストメッセージで指定されたURLである。メッセージ81aは図13のパケット554から再構成したHTTPリクエストメッセージであり、メッセージ81bは図14のパケット556から再構成したHTTPレスポンスメッセージであり、メッセージ対81はこれらのメッセージを対応付けたものである。
【0081】
図16は、1つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。この例では、HTTPプロトコルのメッセージと同様に、IIOPやDBなど他のプロトコルについてもメッセージを再構成し、オブジェクト名を割り当てている。
【0082】
したがって、図13、図14、図15で対応付けたHTTPのメッセージ81a,81b(HTTPのセッション上での識別番号1)、IIOPのセッション上で識別番号1を持つリクエストのメッセージ82a(オブジェクト名:Mbalance)と対応するレスポンスのメッセージ82b、及びDBのセッション上で識別番号1を持つリクエストのメッセージ83a(オブジェクト名:Fetch Account)と対応するレスポンスのメッセージ83bが再構成されている。これらのメッセージが、抽出したオブジェクト名とともにシーケンス図として表示されている。
【0083】
メッセージ81aのオブジェクト名は、/corba/servlet/Balanceである。メッセージ82aのオブジェクト名は、Mbalanceである。メッセージ83aのオブジェクト名は、Fetch Accountである。
【0084】
このような、オブジェクト名が割り当てられたメッセージ対81〜83が、ログ出力部134に入力される(図11参照)。すると、ログ出力部134は、TCP/UDPセッション再構成部131と、メッセージ再構成部132と、オブジェクト名割り当て部133で得られた情報を、プロトコルログとして出力する。このとき、出力されるプロトコルログはテキスト形式であってもよく、バイナリ形式であってもよい。
【0085】
図17は、プロトコルログの例を示す図である。この例では、テキスト形式で出力したプロトコルログ112a〜112fが示されている。
プロトコルログ112a〜112fには、メッセージ毎に、時刻(メッセージの受信時刻)、識別番号、プロトコル(プロトコルの名称)、方向(リクエストかレスポンスか)、及びオブジェクト/応答時間(リクエストについてはオブジェクト名、レスポンスに対しては応答時間)が設定されている。
【0086】
例えば、HTTPのセッションの場合、リクエストのメッセージを示すプロトコルログ112aには、受信時刻「00.00.00.100」、識別番号「1」、オブジェクト名「/corba/servlet/Balance」が設定されている。そして、レスポンスのメッセージを示すプロトコルログ112fには、受信時刻「00.00.00.290」、識別番号「1」、応答時間「0.190(秒)」が設定されている。
【0087】
このような、クライアント21,22,23に対してサービスが提供される毎に、図17に示すようなプロトコルログ112a〜112fが、メッセージ解析部130によってプロトコルログ記憶部112内に逐次蓄積される。その結果、プロトコルログ記憶部112内には、複数のトランザクションに関係するプロトコルログが混在して格納される。
【0088】
図18は、プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。プロトコルログ記憶部112には、異なるトランザクションに関連するメッセージのプロトコルログが時系列に格納されている。図18には、インターネットバンキングサービスでの「残高確認」トランザクションと「入金」トランザクション処理時に発生するメッセージに基づくプロトコルログが示されている。
【0089】
プロトコルログ記憶部112に格納されたプロトコルログは、モデル生成指示が入力されている場合、モデル生成部140に入力される。すると、モデル生成部140によって、トランザクションモデルが生成される。
【0090】
モデル生成部140は、プロトコルログ記憶部112に格納されたプロトコルログに基づいて、トランザクションモデルを獲得する。なお、図18に示したようなプロトコルログは、HTTPプロトコル、IIOPプロトコル、そしてDBプロトコルのメッセージが複雑に混ざり合っている。なお、各プロトコルのリクエストとそれに対応するレスポンスのメッセージは、メッセージ再構成部132によって生成された同じ識別番号を持つ。
【0091】
そこで、第1の実施の形態では、モデル生成部140は、処理間の呼出関係の確からしさに基づく選択基準として、次のような基準を採用する。すなわち、各トランザクションが他のトランザクション(クライアントのリクエストからレスポンスまで)とオーバラップすることのない部分(すなわち非多重(多重度1)の部分)のみを抜き出して、モデルを獲得する。非多重のトランザクションであれば、そのトランザクションが実行されている時間帯内の各処理間には、呼出関係が確実に存在する(確からしさが高い)。
【0092】
そこで、モデル生成部140は、まず、同じ識別番号を持つHTTPプロトコルのリクエスト・レスポンスのペア群を検出する。次に、モデル生成部140は、HTTPプロトコルのメッセージペアの間に、他の識別番号を持つHTTPのメッセージが存在するかどうかをチェックする。存在しない場合、モデル生成部140は、HTTPプロトコルのリクエスト・レスポンスのペア、及びその間の全てのリクエストを選択する。つまり、横断関係にないトランザクションが抽出される。
【0093】
詳細には、以下のような処理が行われる。
図19は、トランザクションモデル生成処理を示すフローチャートである。以下、図19に示す処理をステップ番号に沿って説明する。
【0094】
[ステップS21]モデル生成部140は、パラメータの初期化を行う。具体的には、多重度=0、重複フラグ=0とする。
[ステップS22]モデル生成部140は、プロトコルログ記憶部112からメッセージを読み込む。
【0095】
[ステップS23]モデル生成部140は、メッセージがあるか否かを判断する。メッセージがあれば、処理がステップS24に進められる。メッセージがなければ処理が終了する。
【0096】
[ステップS24]モデル生成部140は、読み込んだメッセージのプロトコルがHTTPか否かを判断する。HTTPであれば処理がステップS25に進められる。HTTPでなければ、処理がステップS22に進められる。
【0097】
[ステップS25]モデル生成部140は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージであれば、処理がステップS26に進められる。レスポンスのメッセージであれば、処理がステップS30に進められる。
【0098】
[ステップS26]モデル生成部140は、多重度=0か否かを判断する。多重度が0であれば、処理がステップS27に進められる。多重度が0でなければ、処理がステップS29に進められる。
【0099】
[ステップS27]モデル生成部140は、多重度をインクリメント(1加算)する。
[ステップS28]モデル生成部140は、開始位置を保存する。具体的には、処理したメッセージの位置を特定する情報(例えば、該当するプロトコルログを示すポインタ等)を格納する。その後、処理がステップS22に進められる。
【0100】
[ステップS29]モデル生成部140は、多重度をインクリメント(1加算)し、さらに重複フラグの値を1に設定する。その後、処理がステップS22に進められる。
[ステップS30]ステップS25でレスポンスのメッセージであると判断されると、モデル生成部140は、多重度=1か否かを判断する。多重度が1であれば、処理がステップS31に進められる。多重度が1以外であれば、処理がステップS22に進められる。
【0101】
[ステップS31]モデル生成部140は、重複フラグ=0か否かを判断する。重複フラグが0であれば、処理がステップS32に進められる。重複フラグが1であれば、処理がステップS33に進められる。
【0102】
[ステップS32]モデル生成部140は、開始位置から現在位置のメッセージをモデル生成用メッセージとして選択する。その後、処理がステップS34に進められる。
[ステップS33]モデル生成部140は、重複フラグの値を0に設定する。
【0103】
[ステップS34]モデル生成部140は、多重度をデクリメント(1減算)する。その後、処理がステップS22に進められる。
このようにして、他のトランザクションと重複しないトランザクションを構成するメッセージを特定し、モデル生成用メッセージとして選択することができる。
【0104】
図20は、選択されるモデル生成用メッセージを示す図である。図20には、図18に示すようなプロトコルログからモデル生成に抽出されるメッセージの集合が示されている。
【0105】
例えば、図20のプロトコルログからHTTPのリクエスト・レスポンスのペアを探すと、識別番号=1のHTTPのリクエスト・レスポンスのペア91、識別番号=2のHTTPのリクエスト・レスポンスのペア92、識別番号=3のHTTPのリクエスト・レスポンスのペア93、そして識別番号=4のHTTPのリクエスト・レスポンスのペア94がまず検出される。しかし、識別番号=2のHTTPプロトコルのリクエスト・レスポンスのペア92の間に、識別番号=3のHTTPリクエストメッセージが存在する。そのため、4つのHTTPのリクエスト・レスポンスのペア91〜94のうち、最終的には識別番号=1と識別番号=4のペアのみが抽出される。すなわち、識別番号=1と識別番号=4のHTTPのリクエスト・レスポンスのペア91,94の間のメッセージがモデル生成に用いられることになる。
【0106】
図21は、「残高確認」トランザクションのモデル生成例を示す図である。図21には、図20における識別番号=1のHTTPのリクエスト・レスポンスのペア91の間のメッセージ集合201から生成される「残高確認」トランザクションモデル203が示されている。
【0107】
モデル生成部140では、上位(利用者側の)の処理が下位の処理を呼び出すが、逆はないという制約を用いる。この制約は、階層的な構成のシステムでは一般的な制約である。具体的には、クライアント21からWebサーバ31の処理が呼び出され、Webサーバ31からアプリケーションサーバ32の処理が呼び出され、そこからDBサーバ33の処理が呼び出される。
【0108】
モデル生成部140は、メッセージ集合201を規定の制約に沿って解析し、処理シーケンス202を作成する。具体的には、モデル生成部140は、メッセージ集合201内の各メッセージの内容を、時系列に沿って解析する。メッセージ集合201内の各メッセージの内容は、以下の通りである。
【0109】
まず、識別番号=1のHTTPプロトコルのリクエストメッセージは、クライアント21からWebサーバ31への処理要求を示す。この場合、/corba/servlet/Balanceのオブジェクト処理が請求される。次に、識別番号=1のIIOPプロトコルのリクエストメッセージはWebサーバ31からアプリケーションサーバ32へのMbalanceメソッドの処理を要求する。さらに、識別番号=1のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountという操作処理を要求する。その後、DBサーバ33、アプリケーションサーバ32、Webサーバ31から、それぞれDB、IIOP、HTTPプロトコルのレスポンスのメッセージが送信される。この内容に沿った処理シーケンス202が生成される。
【0110】
処理シーケンス202には、各セッションでの応答時間が含まれる。セッションの時間は、レスポンスメッセージに示されている。図21の例では、DBサーバ33、アプリケーションサーバ32、Webサーバ31のリクエストからレスポンスまでの応答時間がそれぞれ10msec、90msec、190msecである。
【0111】
また、「残高確認」の処理シーケンス202では、Webサーバ31で/corba/servlet/Balanceのオブジェクトが処理され、アプリケーションサーバ32でMbalanceオブジェクトが処理され、DBサーバ33でFetch Accountオブジェクトが処理されている。そこで、モデル生成部140は、各サーバにおけるオブジェクトの処理時間を算出する。
【0112】
DBサーバ33の処理時間は、DBリクエストからレスポンスまでのDBの応答時間の10msecである。アプリケーションサーバ32の処理時間は、IIOPリクエストからレスポンスの応答時間の90msecからDBサーバ33の応答時間を除いた80msec(=90−10)である。そしてWebサーバ31の処理時間は、HTTPリクエストからレスポンスの応答時間190msecからアプリケーションサーバの応答時間を除いた100msec(=190−90)である。
【0113】
そして、モデル生成部140は、オブジェクトの処理の呼出関係及び各オブジェクトの処理時間を定義したトランザクションモデル203を生成する。
図22は、「入金」トランザクションのモデル生成例を示す図である。図22には、図20における識別番号=4のHTTPのリクエスト・レスポンスのペア94の間のメッセージ集合211から生成される「入金」トランザクションモデル213が示されている。
【0114】
図21の処理と同様に、モデル生成部140は、メッセージ集合211を所定の制約に沿って解析し、処理シーケンス212を作成する。メッセージ集合211内の各メッセージの内容は、以下の通りである。
【0115】
まず、識別番号=4のHTTPプロトコルのリクエストメッセージは、クライアント21からWebサーバ31への処理を要求する。この場合、URLは/corba/servlet/Depositである。次に、識別番号=4のIIOPプロトコルのリクエストメッセージはWebサーバ31からアプリケーションサーバ32へのMdepositメソッドの処理を要求する。次に、識別番号=5のDBプロトコルのリクエストメッセージはアプリケーションサーバ32からDBサーバ33へのFetch Accountという操作処理を要求する。このDBリクエストに対応する識別番号=5のDBレスポンスの応答メッセージから分かるように、Fetch Accountの処理はDBサーバ33で10msecかかった。
【0116】
その後に、さらに識別番号=6のDBプロトコルのリクエストメッセージとしてアプリケーションサーバ32からDBサーバ33へのUpdate Accountという操作処理が要求される。その後、識別番号=6のDBプロトコルのレスポンス、識別番号=4のIIOPプロトコルのレスポンス、そして識別番号=4のHTTPプロトコルのレスポンスメッセージがDBサーバ33、アプリケーションサーバ32、Webサーバ31から送信される。
【0117】
このようなメッセージの流れからトランザクションモデル213が生成され、モデル記憶部113に格納される。また、レスポンスメッセージから、リクエストからレスポンスまでのそれぞれの応答時間が20msec、120msec、240msecであったと分かる。この応答時間も、トランザクションモデル213に設定される。
【0118】
「入金」のトランザクションモデル213では、Webサーバ31で/corba/servlet/Depositのオブジェクトが処理され、アプリケーションサーバ32でMdepositオブジェクトが処理され、DBサーバ33でFetch AccountとUpdate Accountオブジェクトが処理されている。そこで、モデル生成部140は、各サーバにおけるオブジェクトの処理時間情報を算出する。それぞれの処理時間は、DBサーバ33では10msecと20msec、アプリケーションサーバ32では90msec(=120−(10+20))、そしてWebサーバ31では120msec(=240−120)である。
【0119】
そして、モデル生成部140は、オブジェクトの処理の呼出関係及び各サーバにおけるオブジェクトの処理時間を定義したトランザクションモデル213を生成する。
なお、メッセージ解析部130から、再度「残高確認」や「入金」トランザクション処理時のメッセージがモデル生成部140に入力され、これらが多重度1である場合があり得る。この場合、それらのメッセージを無視してもよい。また、同様にモデル生成を行い、すでに生成されている同じ種類のトランザクションの各サーバの処理時間に反映(例えば、平均時間などを利用して)することもできる。
【0120】
また、分析部150で実行される既存のトランザクションモデルとメッセージのマッチング法を用いて、多重度1のモデルを基に、多重度1以上のトランザクションのメッセージ集合を抽出し、それぞれの多重度でのアプリケーション処理時間を求めてモデルを生成することもできる。
【0121】
次に、分析部150で実行される処理を詳細に説明する。分析部150は、プロトコルログ記憶部112に格納されたプロトコルログを、モデル記憶部113に格納されるトランザクションモデルと比較することで、各トランザクションを構成するメッセージを識別する。そして、分析部150は、トランザクション毎のメッセージの処理時間によって、システムの状態を分析する。具体的には、以下の処理が行われる。
【0122】
図23は、分析処理の手順を示すフローチャートである。以下、図23に示す処理をステップ番号に沿って説明する。
[ステップS51]分析部150は、プロトコルログ記憶部112から未処理のプロトコルログを読み込む。
【0123】
[ステップS52]分析部150は、未処理のプロトコルログがあるか否かを判断する。未処理のプロトコルログがある場合、処理がステップS53に進められる。未処理のプロトコルログが無い場合、処理が終了する。
【0124】
[ステップS53]分析部150は、読み込んだプロトコルログに示されるメッセージのプロトコルを判断する。プロトコルがHTTPであれば、処理がステップS54に進められる。プロトコルがIIOPであれば、処理がステップS59に進められる。プロトコルがDBであれば、処理がステップS62に進められる。
【0125】
[ステップS54]プロトコルがHTTPの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS55に進められる。レスポンスのメッセージの場合、処理がステップS57に進められる。
【0126】
[ステップS55]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(URL)に対応するトランザクションモデルをモデル記憶部113から検出する。そして、HTTPリクエストによって発生した該当トランザクションの内容を認識する。
【0127】
[ステップS56]分析部150は、処理中テーブルに新しいトランザクション及びHTTP識別番号を登録する。その後、処理がステップS51に進められる。
[ステップS57]レスポンスのメッセージの場合、分析部150は、識別番号を用いて、処理中テーブルから対応トランザクション及びHTTPを検索し、Webサーバ31における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。
【0128】
[ステップS58]分析部150は、終了トランザクション情報を出力部160に出力し、処理中テーブルから削除する。その後、処理がステップS51に進められる。
[ステップS59]プロトコルがIIOPの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS60に進められる。レスポンスのメッセージの場合、処理がステップS61に進められる。
【0129】
[ステップS60]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(メソッド)を用いて、処置中テーブルから対応トランザクションを検索し、IIOP識別番号を登録する。その後、処理がステップS51に進められる。
【0130】
[ステップS61]レスポンスのメッセージの場合、分析部150は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、アプリケーションサーバ32における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップS51に進められる。
【0131】
[ステップS62]プロトコルがDBの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS63に進められる。レスポンスのメッセージの場合、処理がステップS64に進められる。
【0132】
[ステップS63]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(コマンド+テーブル名)を用いて、処置中テーブルから対応トランザクションを検索し、DB識別番号を登録する。その後、処理がステップS51に進められる。
【0133】
[ステップS64]レスポンスのメッセージの場合、分析部150は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、DBサーバ33における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップS51に進められる。
【0134】
このような処理を行うことで、トランザクションの種別毎に、各サーバにおける処理時間等を記録することができる。
図24は、分析部へ入力されるメッセージの例を示す図である。ユーザからの操作入力等により分析指示が出された後、メッセージ解析装置から出力されプロトコルログ記憶部112に格納されたプロトコルログ221〜242が、順次分析部150に入力される。
【0135】
分析部150ではこれらのプロトコルログ221〜242をモデル生成部140で得られた「残高確認」と「入金」のトランザクションモデル(図21、図22に示す)とマッチングする。そして、分析部150は、トランザクションモデルに合致するトランザクションを抽出する。以下、図25〜図34を参照して、図24に示すプロトコルログ221〜242の分析例を説明する。なお、図25〜図34には、プロトコルログ221〜242を先頭から順に分析することで確認できるトランザクションの状態遷移が示されている。図25〜図34では、発生が確認されたトランザクションのうち、処理が開始されたオブジェクトを実線の楕円で示し、処理が開始されていないオブジェクトを破線の楕円で示している。
【0136】
図25は、メッセージ分析例を示す第1の図である。まず、最初のプロトコルログ221で示されるメッセージは、識別番号=100のHTTPプロトコルであり、クライアント21からWebサーバ31への/corba/servlet/Balanceオブジェクト処理のリクエストメッセージである。このメッセージは第1の状態(ST1)で示すように、図21に示すトランザクションモデル203(「残高確認」トランザクション)のWebサーバ31処理への呼び出しと合致する。これは、Webサーバ31での処理開始を意味する。
【0137】
次のプロトコルログ222で示されるメッセージは、識別番号=200のIIOPプロトコルの、アプリケーションサーバ32へのMbalanceオブジェクト処理のリクエストメッセージである。このメッセージは第2の状態(ST2)で示すように、「残高確認」のトランザクションモデル203のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0138】
次のプロトコルログ223で示される識別番号=101のHTTPリクエストメッセージは、Webサーバ31への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第3の状態(ST3)で示すように、図22に示す「入金」のトランザクションモデル213のWebサーバ31処理への呼び出しと合致する。これは、Webサーバ31での処理開始を意味する。
【0139】
次のプロトコルログ224で示される識別番号=500のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第4の状態(ST4)で示すように、「残高確認」トランザクションモデル203のDBサーバ33処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0140】
図26は、メッセージ分析例を示す第2の図である。次のプロトコルログ225で示される識別番号=201のIIOPのリクエストメッセージは、アプリケーションサーバ32へのMdepositの処理要求である。このメッセージは第5の状態(ST5)で示すように、「入金」トランザクションモデル213のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0141】
次のプロトコルログ226で示される識別番号=102のHTTPリクエストメッセージは、Webサーバ31への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第6の状態(ST6)で示すように、「入金」トランザクションモデル213のWebサーバ31処理への呼び出しと合致する。これは、新たなWebサーバ31での処理開始を意味する。
【0142】
図27は、メッセージ分析例を示す第3の図である。次のプロトコルログ227で示される識別番号=500のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第7の状態(ST7)で示すように、「残高確認」トランザクションのDBサーバ33での処理に20msec要したことを意味する。図21の「残高確認」トランザクションモデル203では、DBサーバ33でのFetch Accountコマンドの処理時間は10msecとなっている。そのため、モデルとの差は10msecである。
【0143】
次のプロトコルログ228で示される識別番号=501のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第8の状態(ST8)で示すように、「入金」トランザクションモデル213のDBサーバ33の処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0144】
図28は、メッセージ分析例を示す第4の図である。次のプロトコルログ229で示される識別番号=501のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第9の状態(ST9)で示すように、「入金」トランザクションのDBサーバ33での処理に20msec要したことを意味する。図22の「入金」トランザクションモデル213でのDBサーバ33のFetch Accountコマンドの処理時間は10msecとなっているため、モデルとの差は10msecである。
【0145】
次のプロトコルログ230で示される識別番号=502のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へUpdate Accountというコマンドの処理要求である。このメッセージは第10の状態で示すように、「入金」トランザクションモデル213のDBサーバ33の処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0146】
図29は、メッセージ分析例を示す第5の図である。次のプロトコルログ231で示される識別番号=202のIIOPのリクエストメッセージは、アプリケーションサーバ32へのMdepositの処理要求である。このメッセージは第11の状態(ST11)で示すように、「入金」トランザクションモデル213のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0147】
次のプロトコルログ232で示される識別番号=200のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第12の状態(ST12)で示すように、「残高確認」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、IIOPリクエストからレスポンスまでの応答時間は100msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での処理(20msec)を除いた80msecになる。この値は、図21の「残高確認」トランザクションモデル203でのアプリケーションサーバ32の処理時間と同じである。
【0148】
図30は、メッセージ分析例を示す第6の図である。次のプロトコルログ233で示される識別番号=502のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第13の状態(ST13)で示すように、「入金」トランザクションのDBサーバ33での処理が50msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのUpdate Accountコマンドの処理時間は20msecとなっているため、モデルとの差は30msecである。
【0149】
次のプロトコルログ234で示される識別番号=503のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第14の状態(ST14)で示すように、「入金」トランザクションモデル213のDBサーバ33での処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0150】
図31は、メッセージ分析例を示す第7の図である。次のプロトコルログ235で示される識別番号=100のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第15の状態(ST15)で示すように、「残高確認」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は190msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答処理(100msec)を除いた90msecになる。図21の「残高確認」トランザクションモデル203では、Webサーバ31での処理時間は100msecとなっているため、モデルより10msec早く終了していることになる。この時点で、1つの「残高確認」トランザクションのすべての処理が終了し、出力部160に出力される。
【0151】
次のプロトコルログ236で示される識別番号=503のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第16の状態(ST16)で示すように、「入金」トランザクションのDBサーバ33での処理が20msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのFetch Accountコマンドの処理時間は10msecとなっているため、モデルとの差は10msecである。
【0152】
図32は、メッセージ分析例を示す第8の図である。次のプロトコルログ237で示される識別番号=504のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へUpdate Accountというコマンドの処理要求である。このメッセージは第17の状態(ST17)で示すように、「入金」トランザクションモデル213のDBサーバ33処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0153】
次のプロトコルログ238で示される識別番号=201のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第18の状態(ST18)で示すように、「入金」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は180msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での2つのコマンドの処理時間(70msec=20msec+50msec)を除いた110msecになる。図22の「入金」トランザクションモデル213では、アプリケーションサーバ32での処理時間は90msecとなっているため、モデルとの差は20msecである。
【0154】
図33は、メッセージ分析例を示す第9の図である。次のプロトコルログ239で示される識別番号=101のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第19の状態(ST19)で示すように、「入金」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は310msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答時間(180msec)を除いた130msecになる。図22の「入金」トランザクションモデル213では、Webサーバ31での処理時間は120msecとなっているため、モデルとの差は10msecである。この時点で、1つの「入金」トランザクションのすべての処理が終了し、出力部160に出力される。
【0155】
次のプロトコルログ240で示される識別番号=504のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第20の状態(ST20)で示すように、「入金」トランザクションのDBサーバ33処理が230msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのUpdate Accountコマンドの処理時間は20msecとなっているため、モデルとの差は210msecであり、大きく増加していることで、DBサーバ33でなんらかの問題が起きていることが分かる。
【0156】
図34は、メッセージ分析例を示す第10の図である。次のプロトコルログ241で示される識別番号=202のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第21の状態(ST21)で示すように、「入金」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は350msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での2つのコマンドの処理時間(250msec=20msec+230msec)を除いた100msecになる。図22の「入金」トランザクションモデル213では、アプリケーションサーバ32での処理時間は90msecとなっている。そのため、モデルとの差は10msecである。
【0157】
ここで注意したいのは、アプリケーションサーバ32での応答時間が350msecであるにもかかわらず、実際のアプリケーションサーバ32での処理時間はわずか100msecに過ぎず、モデルとほぼ一致していることで、アプリケーションサーバ32自身には性能問題がないということが分かる。
【0158】
次のプロトコルログ242で示される識別番号=102のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第22の状態(ST22)で示すように、「入金」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は470msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答時間(350msec)を除いた120msecになる。この時点で、最後の「入金」トランザクションのすべての処理が終了し、出力部160に出力される。
【0159】
図22の「入金」トランザクションモデル213では、Webサーバ31での処理時間は120msecとなっているため、モデルと一致する。アプリケーションサーバ32と同様に、Webサーバ31での応答時間が470msecであるにもかかわらず、実際のWebサーバ31での処理時間はモデルと一致していることで、Webサーバ31自身には性能問題がないということが分かる。以上のような分析結果は、分析結果記憶部114に格納される。
【0160】
次に、出力部160で行われる処理を詳細に説明する。
出力部160は、分析部150から分析結果記憶部114に格納されたトランザクションの情報をさまざまな形でモニタ11に出力する。以下、出力部160によるトランザクション情報の出力例を示す。
【0161】
図35は、サーバの平均処理時間の表示例を示す図である。図35で示すように、出力部160は、サーバごとの平均処理時間を求めて、モニタ11に平均処理時間を示す画面301を表示する。なお、各サーバの処理時間を示すグラフには、トランザクションモデルにおける処理時間を示す線が表示されている。なお、出力部160は、モデルとの処理時間との差が非常に大きい場合には、それらの処理をリストアップして、モニタ11に表示することもできる。
【0162】
図36は、トランザクション別処理時間及び内訳の表示例を示す図である。この画面302では、ある期間のトランザクションがすべて集計され、サーバごとの処理時間が表示されている。
【0163】
図37は、処理時間ヒストグラムの表示例を示す図である。この画面303では、トランザクション処理時間、及び各サーバでの処理時間に関するヒストグラム(処理時間毎の発生頻度)が表示されている。
【0164】
また、ヒストグラム等の各種情報を画面に同時に表示することで、処理遅延原因の解析を容易にすることができる。
図38は、複数の情報を同時に表示した場合の画面例を示す図である。この画面310には、トランザクション処理時間のヒストグラム表示部311、トランザクションの多重度表示部312、トランザクションの時間推移表示部313(Webサーバ31、アプリケーションサーバ32、DBサーバ33での内訳)とトランザクションメッセージのシーケンス表示部314が表示されている。出力部160は、各表示対象要素の表示内容を、互いに連携させて表示する。
【0165】
図39は、表示対象要素間の連携の様子を示す図である。図39に示すように、ヒストグラム表示部311には、処理遅延判別用の閾値を示すバー311aが表示されている。このバー311aは、ユーザからの操作入力に応じて左右に移動させることができる。バー311aが表示されている位置の処理時間の値が閾値となる。閾値以上に処理時間を要したトランザクションが、注目処理と判断される。
【0166】
図39の例では、300msecの位置にバー311aが表示されている。したがって、300msec以上要したトランザクションが、注目処理となる。
多重度表示部312では、ヒストグラム表示部311上で注目処理と分類されたトランザクションの処理時間帯が、強調表示される。また、多重度表示部312の横には、スクロールバー312aが設けられている。スクロールバー312aで示された時間帯のトランザクションの詳細が、時間推移表示部313に表示される。
【0167】
時間推移表示部313には、プロトコル間のメッセージの受け渡しが、サーバ間のシーケンスで示される。時間推移表示部313の横には、スクロールバー313aが設けられている。スクロールバー313aで示された時間帯のメッセージの内容が、シーケンス表示部314に表示される。シーケンス表示部314では、注目処理に関するメッセージが強調表示される。
【0168】
このように、ユーザがヒストグラム表示部311から所定の時間以上かかるトランザクションを選択すれば、そのようなトランザクションがどこで起きるかをトランザクションの多重度表示部312、トランザクションの時間推移表示部313、そしてメッセージのシーケンス表示部314で確認できる。
【0169】
以上説明したように、第1の実施の形態では、トランザクションモデルを生成し、スイッチ10を介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出するようにした。これにより、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。
【0170】
すなわち、システム分析装置100において、ネットワークからキャプチャしたTCPパケットのデータ部を解析することで、サーバで実行されるアプリケーション間での通信を再構成する。そして、システム分析装置100は、再構成されたプロトコルログから、処理間の呼出関係が確実に存在するメッセージ集合を選択し、ユーザのリクエストに対する一連の処理の結びつきであるトランザクションが抽出できる。そして、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することにより、性能問題やボトルネックを迅速に把握することが可能となる。
【0171】
しかも、第1の実施の形態は、外部観測によってトランザクションを抽出している。そのため、既存システムへの機能追加を行う必要がなく、サーバ内のアプリケーションへの改変等を行わずに済む。
【0172】
[第2の実施の形態]
第2の実施の形態は、処理時間帯が他のトランザクションと重なるようなトランザクションであっても、そのトランザクションを構成するメッセージを抽出し、トランザクションモデルを生成できるようにしたものである。
【0173】
すなわち、第1の実施の形態では、各処理が他の処理(リクエストからレスポンスまで)とオーバラップすることない(すなわち多重度1である)部分のみを抜き出して、トランザクションモデルを獲得していた。この処理は、例えば対象システムの運用を一時停止し、モデル獲得のためにのみ動作させることが可能な場合には有効である。
【0174】
ところが、24時間サービスを行っているため運用停止ができず、かつほとんどの場合に複数の処理を同時並行的に処理しているシステムの場合、第1の実施の形態を適用するのは困難となる。また、処理の多重度が低くシステムへの負荷が軽い場合と、多重度が高く負荷も重い場合とで挙動が異なる場合には、多重度1の場合からだけトランザクションモデルを生成したのでは不十分である。そのため、対象システムによっては多重度が高い部分も利用してトランザクションモデルを生成することも必要になる。以下でその動作例を示す。
【0175】
なお、第2の実施の形態におけるシステム分析装置の機能ブロックは、図4に示した第1の実施の形態と同様である。そこで、図4に示した各要素を用いて、第2の実施の形態の処理を説明する。また、第1の実施の形態と第2の形態とは、モデル生成部140の処理のみが相違し、他の要素の処理は同じである。さらに、説明を簡単にするため、アプリケーションサーバ32とDBサーバ33とで完結するトランザクションの例を用いて、第2の実施の形態を説明する。すなわち、IIOPのメッセージとDBのメッセージとの関係から、トランザクションモデルとして生成する。
【0176】
図40は、分析部へ入力されるメッセージの例を示す図である。プロトコルログ記憶部112に格納されたプロトコルログ401〜420が、モデル生成部140に入力される。
【0177】
モデル生成部140は、所定の制約条件に従って、プロトコルログに示されるメッセージを解析する。
図41は、モデル生成部に入力されたメッセージから認識される処理を示す図である。すなわち、モデル生成部140は、図40のプロトコルログ401〜420で示されるメッセージから各処理の開始と終了を抽出し、その処理期間を時系列に並べる。その結果が、図41に示されている。
【0178】
処理P1は、プロトコルログ401,410で示される識別番号=1のIIOPのメッセージから認識される処理である。処理P2は、プロトコルログ403,413で示される識別番号=2のIIOPのメッセージから認識される処理である。処理P3は、プロトコルログ407,419で示される識別番号=3のIIOPのメッセージから認識される処理である。処理P4は、プロトコルログ411,420で示される識別番号=4のIIOPのメッセージから認識される処理である。
【0179】
処理P5は、プロトコルログ402,405で示される識別番号=1のDBのメッセージから認識される処理である。処理P6は、プロトコルログ404,406で示される識別番号=2のDBのメッセージから認識される処理である。処理P7は、プロトコルログ409,412で示される識別番号=4のDBのメッセージから認識される処理である。処理P8は、プロトコルログ408,414で示される識別番号=3のDBのメッセージから認識される処理である。処理P9は、プロトコルログ415,417で示される識別番号=5のDBのメッセージから認識される処理である。処理P10は、プロトコルログ416,418で示される識別番号=6のDBのメッセージから認識される処理である。
【0180】
なお、この例ではIIOPで2種類、DBで2種類の処理が現れるが、以下では記述を簡単にするために以下のように略すこととする。
IIOPによるMbalance:種別A
IIOPによるMdeposit:種別B
DBによるFetch->Account:種別a
DBによるUpdate->Account:種別b
また、モデル中の各処理種別毎の処理時間の求め方は第1の実施の形態と同じなので、ここではモデル中の処理種別間の呼出関係のみに着目し、処理時間に関する説明は省くものとする。
【0181】
第2の実施の形態における制約条件は、以下の通りである。
第1の制約:ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。
【0182】
第2の制約:IIOPの処理は、直接システム外部(例えば、クライアント21)から呼び出される。
第3の制約:DBの処理は、必ずIIOPから呼び出される。
【0183】
第1の制約は、呼出関係に関する基本的な制約で処理Xが処理Yを呼び出した場合には、YはXより後に開始されXより前に終了しなければならないことを要求している。なお、場合によってはXの開始(終了)とYの開始(終了)時刻の差の上限値や下限値を与える場合もある。多くのシステムではこのような制約が成立しており、これを利用することで呼出関係の候補を減らすことができる。
【0184】
第2の制約は、階層的な構成のシステムでは一般的な制約で、上位(利用者側の)の処理が下位の処理を呼び出すが、逆はないことを表す。この場合には、監視対象のシステムの外部からIIOPの処理が呼び出され、そこからDBの処理が呼び出されることを表している。これ以外の呼び出し、例えばIIOPの処理が他のIIOPの処理を呼び出したり、DBの処理がIIOPの処理を呼び出したりすることはない。
【0185】
このほかにも、例えばあるIIOPの処理はDBの処理を最低1回呼び出す、というような処理種別やそのグループ間の呼出回数やその順序に関する制約等、監視をする側が持つシステムに関する知識を制約として入力する。
【0186】
図42は、制約を満たす処理間の呼出関係を示す図である。第1〜第3の制約を使うと、ある処理から呼び出し可能な他の処理が限定される。すなわち、どのIIOP処理からどのDB処理が呼び出され得るかが示されている(これ以外の呼び出しは制約を満足しない)。
【0187】
例えばDBによる処理P5を呼び出し得るのは、第1の制約から処理期間が処理P5のそれを含む処理でなければならず、この例ではIIOPによる処理P1のみである。一方処理P7の呼び出し元については、第1の制約を満足する処理は、処理P2,P3,P8の3個ある。このうち処理P8はDBの処理であり、第2の制約および第3の制約から同じDBの処理である処理P7を呼び出すことはありえないことが分かる。よって、処理P8を呼び出している候補は処理P2と処理P3の2つになる。
【0188】
次に、これらの呼出関係の候補から、処理種別毎に、他の種別の呼出回数を計算する。以下では処理種別iから処理種別jの呼出回数をM(i,j)と記述し、Mを呼出回数行列と呼ぶ。
【0189】
まず初めに、モデル生成部140は、呼出回数行列を初期化する。初期化は、呼出関係の制約を満足する要素を1、それ以外を0とする。
図43は、呼出回数行列の例を示す図である。この例では、4種類の処理があるため、呼出回数行列は16の要素をもつが、IIOPからDBへの呼び出しだけが制約で許されるので1、それ以外の12個は0となる。これは、制約上許される呼び出しは、他の情報がない限り、同じだけの頻度(確率)で起こるとみなすことを意味する。
【0190】
次に呼出回数行列を使って、図42中の呼び出し候補の確率を計算する。例えば、処理P5の呼び出し元の可能性は処理P1しかないので、処理P1から処理P5への呼び出しの確率は1である。
【0191】
一方処理P6(種別a)への呼び出しは、処理P1(種別A)からの呼び出しと処理P2(種別B)からの呼び出しの2つの可能性が考えられる。そのような場合には、呼び出し元(の候補)の処理種別から呼び出し先(この場合は処理P6)の種別への呼出回数行列要素の値に比例した確率を割り当てる。この場合は、処理P1が属する種別Aの処理からの、処理P6が属する種別aの処理への回数は1回(図43参照)、処理P2が属する種別Bからの呼出回数も1回であるので、それぞれの呼び出し候補の確率は共に1/2となる。
【0192】
以下、モデル生成部140は、同様に各呼び出し候補の確率を求める。
図44は、呼び出し候補の確率を求めた結果を示す図である。図43に示す呼出回数行列では、制約を満足する呼出関係を示す各要素の値は、全て1である。そのため、複数の呼び出し可能性を持つ場合、それぞれの呼び出し可能性は等しくなる(確率が1/2)。
【0193】
次に、モデル生成部140は、上記の確率を使って、呼出回数行列の値を更新する。すなわち、処理種別XからYへの呼出回数は、図43中の呼び出し候補のなかで、XからYへの呼び出し候補の確率の和を、処理種別Xの発生回数で割ったものとして計算できる。
【0194】
例えば種別Aから種別aへの呼び出し候補は、処理P1から処理P5、処理P1から処理P6、処理P4から処理P10の3個あり、その確率はそれぞれ、1、1/2、1/2である。このことと、種別Aの処理が、処理P1および処理P4の2個であることから、呼出回数行列の要素M(A,a)の値は、
(1+1/2+1/2)/2=1
となる。同様に、モデル生成部140は、他の行列要素も計算する。
【0195】
図45は、更新後の呼出回数行列を示す図である。ただし呼び出し行列のうち、制約上ゆるされない要素の値は常に0であるので、制約上許される要素、すなわちIIOPの処理種別からDBの処理種別への呼び出しに対応する要素のみを示す。
【0196】
以上の、呼出回数行列を使った呼び出し候補の確率計算と、それに基づく呼出回数行列の更新を、所定の終了条件を満足するまで繰り返す。所定の終了条件とは、例えば、更新回数が予め設定された回数に達することである。また、別の終了条件としては、更新前後の行列要素の変化量が、予め設定された上限値以下となることである。
【0197】
本実施の形態では、終了条件が、更新回数2回であるものとする。すなわち、モデル生成部140は、図44に示した状態からもう一度呼出回数のカウントと行列要素の計算を行う。2回目以降の処理においても、各呼び出し候補の確率計算の方法は1回目の処理と同じである。ただし、確率計算のもとになる呼出回数行列は図45で示す内容であり、上で求めた図43とは異なるので、計算される確率も異なる。
【0198】
例えば、処理P9(種別b)に対する呼び出し候補は、処理P3(種別B)からの呼び出しと処理P4(種別A)からの2つがある。図45に示す呼出回数行列では、種別Bから種別bへの呼出回数は3/4回、種別Aから種別bへの呼び出しは1/4回である。これに比例するように確率を割り振ると、処理P3から処理P9への呼び出しの確率は3/4、処理P4から処理P9への呼び出しの確率は1/4となる(処理P9は処理P3か処理P4のいずれか一方から呼び出されるので、2つの確率の和は1になることに注意)。
【0199】
以下、モデル生成部140は、同様に各呼び出し候補の確率を求める。
図46は、2回目の処理で呼び出し候補の確率を求めた結果を示す図である。このように、複数の呼び出し可能性を持つ場合には、呼出回数の予測値を重みとして確率が計算される。このような呼び出し候補の確率に基づいて、呼出回数行列が更新される。
【0200】
図47は、2回目の更新後の呼出回数行列を示す図である。呼出回数の計算方法は、1回目と同じである。これで呼出回数行列の更新は2回行われたので、確率計算/更新処理が終了して次のステップに進む。
【0201】
次に、呼出回数行列の要素のなかで整数以外の部分を四捨五入などにより整数にまるめる。図47では種別Aから種別bへの呼出回数が1/8回なのでこれを0とし、種別Bから種別bへの呼出回数は7/8なので、これを1回とする。これら以外は値が整数なので変更されない。
【0202】
図48は、最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。モデル生成部140は、図48に示すように整数化された呼出回数行列から、処理種別間の呼出関係を表すトランザクションモデルを獲得する。すなわち、呼出回数行列から、IIOP処理種別Aは、DBの処理種別aを1回呼び出し、IIOPの種別BはDBの処理種別aと処理種別bとをそれぞれ1回ずつ呼び出すことが分かる。
【0203】
すなわち、呼出回数行列で1と設定されている呼出関係が、生起確率の高い関係である。そこで、モデル生成部140は、呼出回数行列で1が設定されている呼出関係から認識されるトランザクションモデル431,432を生成し、モデル記憶部113に格納する。
【0204】
以上の処理手順を整理すると以下のようになる。
図49は、第2の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図49に示す処理をステップ番号に沿って説明する。
【0205】
[ステップS71]モデル生成部140は、プロトコルログから各処理の開始と終了のペアを抽出する。
[ステップS72]モデル生成部140は、呼出回数行列を初期化する。この際、制約を満足しない呼出関係は、0に初期化される。
【0206】
[ステップS73]モデル生成部140は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
[ステップS74]モデル生成部140は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップS77に進められる。終了条件を満足していない場合、処理がステップS75に進められる。
【0207】
[ステップS75]モデル生成部140は、呼出関係候補それぞれの生起確率を、呼出回数行列の値に比例するように計算する。
[ステップS76]モデル生成部140は、各呼出関係候補の確率を呼び出し元と呼び出し先との処理種別毎に平均をとり、呼出回数行列を更新する。その後、処理がステップS74に進められる。
【0208】
[ステップS77]終了条件を満足した場合、モデル生成部140は、呼出回数行列を整数で近似する。
[ステップS78]モデル生成部140は、呼出回数行列のゼロ以外の成分を処理種別毎の呼出回数とするトランザクションモデルを出力する。
【0209】
以上のように、第2の実施の形態では、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合して、処理間の呼出関係の可能性を算出するようにした。これにより、複数のトランザクションが同時に処理されている場合であっても、モデルを生成することができる。しかも、比較的少ない計算量でモデルを生成できる。
【0210】
[第3の実施の形態]
上記第2の実施の形態に示す方法では、処理種別間の呼出回数の平均を使っている。そのため、例えば確率1/2で2回呼び出している状況と確率1で1回呼び出している状況を区別できず、結果として正しいトランザクションモデルを学習できない場合もあり得る。このような状況は、例えば、ある処理種別からの呼出パターンが複数ある場合に発生し得る。これを解決するためには、呼出関係の候補として個々の処理種別間の関係を求めるのではなく、ある処理種別が呼び出す全ての処理の集合や集合内の順序を対象に確率を求めればよい。以下では、この考え方に基づくモデル生成方法を第3の実施の形態として説明する。
【0211】
なお、第3の実施の形態におけるシステム分析装置の機能ブロックは、図4に示した第1の実施の形態と同様である。そこで、図4に示した各要素を用いて、第3の実施の形態の処理を説明する。また、第1の実施の形態と第3の形態とは、モデル生成部140の処理のみが相違し、他の要素の処理は同じである。
【0212】
モデル生成部140の入力は、同じく図40のメッセージ列および制約であるとする。
モデル生成部140は、まず初めに、第2の実施の形態と同様に各処理間で可能な呼出関係を求める。結果は図42に示す通りである。
【0213】
次に、図42に示した可能な呼出関係を元に、各処理が呼び出している処理の集合とそのなかでの順序の候補を求める。例えば、処理P1が呼び出している処理の順序付きの集合の候補(以下処理集合候補と呼ぶ)は次のように求める。
【0214】
図42に示す呼出関係を解析すると、集合Uに含まれる(すなわち処理P1から呼び出されている)可能性があるのは、処理P5と処理P6の2つの処理である。このうち処理P5は、他に呼び出し元の候補はないので、かならず集合U含まれる。一方処理P6は、処理P2から呼び出されている可能性があるので、集合Uに含まれる可能性と含まれない可能性の両方が考えられる。処理P5と処理P6では処理P5のほうが早く開始しているので、集合Uの候補は次の2つである。
U11:{処理P5}
U12:{処理P5,処理P6}
なお、集合及び処理集合候補の記述では、呼び出されるのが早い処理から順に左から記述するものとする。この段階では、この2つの候補のどちらが信頼できるかに関する判断材料が全くないため、信頼度は両者同じ、すなわち、1/2とする。
【0215】
次に、処理集合候補U11,U12を処理種別による記述に変換し、処理P1から呼び出される処理のパターン、すなわち呼び出される処理種別の順序付き集合の候補を生成する。処理P5および処理P6の処理種別はどちらもaであるので、以下のようになる。
U11:パターン{a}
U12:パターン{a,a}
後者の処理集合候補U12は、処理P1が同じ処理種別の処理を2回連続して呼び出している可能性を表している。
【0216】
次に、パターンの信頼度を、そのパターンの元になった処理集合の信頼度から計算する。この場合は処理集合候補U11、処理集合候補U12から異なるパターンが生成されているので、各パターンの信頼度は処理集合候補U11および処理集合候補U12の信頼度をそのまま用いる。すなわち1/2とする。
【0217】
以上から、処理P1が呼び出しているパターンの候補とその信頼度は次のようになる。
パターン{a}:信頼度1/2
パターン{a,a}:信頼度1/2
2番目のパターンは種別aの処理が2回呼び出されるパターンを示している。モデル生成部140は、他の処理についても、その処理が呼び出している処理種別のパターンの候補と信頼度を同様にして求める。
【0218】
処理P2から呼び出される可能性があるのは処理P6と処理P7の2つであり、この両者とも他の処理から呼び出されている可能性があるので、処理P2から呼び出されている処理集合候補は次の4通りである。処理P1の場合と同様、この段階ではこれら全ての信頼度が同じ、すなわち1/4であるとする。
U21:{}
U22:{処理P6}
U23:{処理P7}
U24:{処理P6,処理P7}
処理P6および7の種別はそれぞれaとbであるから、処理P2が呼び出している処理種別のパターンの候補とその信頼度は次のようになる。
パターン{}:信頼度1/4
パターン{a}:信頼度1/4
パターン{b}:信頼度1/4
パターン{a,b}:信頼度1/4
最後のパターンは、aとbがこの順序で、すなわち最初に種別aの処理が呼び出され、その後にbの処理が呼び出されるパターンを表している。なお、順序を考慮せず、呼び出される処理種別毎の回数をパターンとすることもできる。
【0219】
処理P3に関しては注意が必要である。処理P3からかならず呼び出されているのは処理P8、処理P3から呼び出されている可能性はあるが、他の処理から呼び出されている可能性もある処理が、処理P7、処理P9、処理P10の3個であるから、処理P3が呼び出している処理集合候補は、
{処理P8}
{処理P8,処理P7}
{処理P8,処理P9}
{処理P8,処理P10}
{処理P8,処理P7,処理P9}
{処理P8,処理P7,処理P10}
{処理P8,処理P9,処理P10}
{処理P8,処理P7,処理P9,処理P10}
の8個で、それぞれの信頼度は1/8となる。ここからパターンとその信頼度が計算される。
【0220】
ところが、処理P7と処理P9が共に種別bの処理であることから、{処理P8,処理P7}と{処理P8,処理P9}からは同一のパターン{a,b}が生成される。同様に{処理P8,処理P7,処理P10}と{処理P8,処理P9,処理P10}からはパターン{a,b,a}が生成される。このような場合には、これらのパターンの信頼度は、対応する処理集合候補の信頼度の和をとることで計算する。よって結果は次のようになる。
パターン{a}:信頼度1/8
パターン{a,b}:信頼度1/4
パターン{a,a}:信頼度1/8
パターン{a,b,b}:信頼度1/8
パターン{a,b,a}:信頼度1/4
パターン{a,b,b,a}:信頼度1/8
処理P4についてもパターンとその信頼度を求めると次のようになる。
パターン{}:信頼度1/4
パターン{b}:信頼度1/4
パターン{a}:信頼度1/4
パターン{b,a}:信頼度1/4
次に、上で求めた各処理から呼び出される処理種別のパターンとその信頼度を、呼び出し元の処理種別毎に平均をとることで、処理種別毎に、それから呼び出されるパターンとその確率を計算する。
【0221】
まず、処理種別Aに属するのは処理P1と処理P4であるから、これらの処理から呼び出されているパターン候補の信頼度の平均を計算する。例えばパターン{a}は、処理P1では信頼度1/2、処理P4では信頼度1/4であるので、処理種別Aからこのパターンが呼び出される確率は、その平均、すなわち3/8となる。一方パターン{a,a}は、処理P1では信頼度1/2であるが、処理P4ではパターン候補中に存在しない、すなわち信頼度0であるので、確率は1/4になる。
【0222】
図50は、処理種別Aからの呼出パターンとその確率を示す第1の図である。図50に示すように、パターンA1{}の確率は、(0+1/4)/2=1/8である。パターンA2{b}の確率は(0+1/4)/2=1/8である。パターンA3{a}の確率は、(1/2+1/4)/2=3/8である。パターンA4{a,a}の確率は、(1/2+0)/2=1/4である。パターンA5{b,a}の確率は(0+1/4)/2=1/8である。
【0223】
同様に処理種別Bに属する処理、すなわち処理P2および処理P3の平均をとると、処理種別Bから呼び出されるパターンとその確率を以下のように計算される。
図51は、処理種別Bからの呼出パターンとその確率を示す第1の図である。図51に示すように、パターンB1{}の確率は、(1/4+0)/2=1/8である。パターンB2{a}の確率は、(1/4+1/8)/2=3/16である。パターンB3{b}の確率は、(1/4+0)/2=1/8である。パターンB4{a,b}の確率は、(1/4+1/4)/2=1/4である。パターンB5{a,a}の確率は、(0+1/8)/2=1/16である。パターンB6{a,b,b}の確率は、(0+1/8)/2=1/16である。パターンB7{a,b,a}の確率は、(0+1/4)/2=1/8である。パターンB8{a,b,b,a}の確率は、(0+1/8)/2=1/16である。
【0224】
次にこれの処理種別毎の呼び出されるパターンとその確率を使って、もう一度各処理から呼び出される処理の集合の候補(処理集合候補)とその信頼度を計算しなおす。
まず、処理P1について考える。
処理P1で可能な呼び出し処理集合候補が
U11:{処理P5}
U12:{処理P5,処理P6}
であるのは同じである。ただし前回はどちらがよりもっともらしいかを判断する材料がなかったため信頼度を同じにしたが、今回は判断材料として図50および図51に示した処理種別毎の呼出パターンの信頼度を使うことができる。
【0225】
ただし、処理集合候補U11と処理集合候補U12の信頼度は、処理P1からの呼出パターンの確率だけではなく、このどちらかを選択するかによって呼び出し候補が影響される他の処理も考慮する必要がある。
【0226】
処理集合候補U11と処理集合候補U12の差は処理P6が処理P1からよびだされているかどうかである。処理P6は処理P1または処理P2から呼び出されているから、例えば処理集合候補U11を選択するということは、単に処理P1から処理P6が呼び出されないことだけの選択ではなく、処理P2から処理P6が呼び出されている、という選択でもある。よって処理集合候補U11の信頼度を計算する際には、それによって処理P2からの呼び出しの選択がどれだけ制限されるかを考慮する必要がある。
【0227】
処理集合候補U11となる場合、処理P1(種別A)からの呼出パターンはA3であり、このパターンの確率は3/8である。一方、処理集合候補U12の場合はパターンA4であるから確率は1/4である。ただし処理集合候補U11および処理集合候補U12の信頼度はこれらの確率をそのまま使うのではなく、それによって他の処理からの呼出パターンがどのように制限されるかを考慮する。
【0228】
すなわち、例えば処理P1からの呼び出しが処理集合候補U11の場合、処理P6は処理P1から呼ばれないことになる。そのため、他の候補、すなわち処理P2からかならず呼ばれることになる。よって処理P2から呼び出される処理の集合は{処理P6}または{処理P6,処理P7}でなければならない。
【0229】
処理P6および処理P7の種別はaおよびbであるから、処理種別のパターンでいうとB2またはB4であり、確率はそれぞれ3/16および1/4である。よって処理集合候補U11の信頼度は、処理P2側の確率はこれらの確率の和、すなわち7/16と見積もることができる。これを使って、処理集合候補U11の信頼度は、処理P1側で処理集合候補U11が呼び出される確率3/8と処理P2側の制限からくる確率7/16の積、すなわち21/128とする。
【0230】
一方、処理集合候補U12の場合には、処理P6は処理P1から呼び出されているので、処理P2側の呼び出される処理の集合の候補は{}または{処理P7}のいずれか、処理種別のパターンではB1またはB3である。これらの確率は共に1/8であるので、処理集合候補U12の信頼度は1/4×(1/8+1/8)=1/16=8/128となる。
【0231】
処理集合候補U11および処理集合候補U12のいずれかはかならず正しいので、両者の信頼度の和が1になるように正規化を行い、最終的に処理集合候補U11および処理集合候補U12の信頼度を
U11:{処理P5}信頼度21/29
U12:{処理P5,処理P6} 信頼度8/29
とする。すなわち処理集合候補U11のほうがもっともらしいと判断される。
【0232】
次にこれを上と同様に処理種別のパターンとその信頼度に変換する。
パターン{a}:信頼度21/29
パターン{a,a}:信頼度8/29
処理P2、処理P3、処理P4についても処理P1の場合と全く同様にして可能な呼び出し処理集合の候補の信頼度を計算し、そこから呼び出し種別のパターン毎の信頼度を計算する。以下にその結果を示す。
【0233】
処理P2については、以下の通りである。
パターン{}:信頼度4/33
パターン{a}:信頼度9/33
パターン{b}:信頼度5/33
パターン{a,b}:信頼度15/33
処理P3については、以下の通りである。
パターン{a}:信頼度18/101
パターン{a,b}:信頼度46/101
パターン{a,a}:信頼度6/101
パターン{a,b,b}:信頼度15/101
パターン{a,b,a}:信頼度11/101
パターン{a,b,b,a}:信頼度5/101
処理P4については、以下の通りである。
パターン{}:信頼度3/28
パターン{b}:信頼度3/28
パターン{a}:信頼度15/28
パターン{b,a}:信頼度7/28
次に、前と同様にこれらの呼び出し元の処理毎の呼出パターンの信頼度から、処理種別毎の呼出パターンとその確率を、呼び出し元の処理種別毎に平均をとることで求める。
【0234】
図52は、処理種別Aからの呼出パターンとその確率を示す第2の図である。図52に示すように、パターンA1:{}の確率は87/1624=0.054である。パターンA2:{b}の確率87/1624=0.054である。パターンA3:{a}の確率は1023/1624=0.630である。パターンA4:{a,a}の確率は224/1624=0.138である。パターンA5:{b,a}の確率は203/1624=0.125である。
【0235】
同様に処理種別Bに属する処理、すなわち処理P2および処理P3の平均をとると、処理種別Bから呼び出されるパターンとその確率を以下のように計算される。
図53は、処理種別Bからの呼出パターンとその確率を示す第2の図である。図53に示すように、パターンB1:{}の確率は404/6666=0.061である。パターンB2:{a}の確率は1503/6666=0.225である。パターンB3:{b}の確率は505/6666=0.076である。パターンB4:{a,b}の確率は3033/6666=0.455である。パターンB5:{a,a}の確率は198/6666=0.030である。パターンB6:{a,b,b}の確率は495/6666=0.074である。パターンB7:{a,b,a}の確率は363/6666=0.054である。パターンB8:{a,b,b,a}の確率は165/6666=0.025である。
【0236】
この処理毎の呼び出す処理の集合とその信頼度の計算およびそれから処理種別毎の呼出パターンやその確率の計算を適当な終了条件が満足するまで行う。終了条件は、第2の実施の形態と同様、繰り返し回数や、パターン毎の確率の変化量の上限等で行う。
【0237】
図52、図53に示した状態で終了条件が満足されると、モデル生成部140は、図52および図53の呼出パターンとその確率から、モデルを生成する。このとき、あまり確率の小さいモデルは信頼性にかける。そのため、呼び出し元の処理種別毎に、可能なパターンの中から確率の高い順に、選択数の上限および確率の下限を使ってモデルとして採用するパターンを選択する。
【0238】
例えば選択数の上限を2、確率の下限を0.1とすると、呼出元の処理種別Aに対してはパターンA3とパターンA4が、処理種別Bに対してはパターンB4とB2がモデルとして選択される。最終的なモデルは、選択されたパターンのみを使って確率の和が1となるように正規化しなおして生成される。
【0239】
図54は、モデル生成結果を示す図である。IIOPの種別Aに対しては、2つのトランザクションモデル441,442が生成されている。トランザクションモデル441の確率は、0.82(=0.630/(0.630+0.138))であり、トランザクションモデル442の確率は、0.18(=0.138/(0.630+0.138))である。
【0240】
IIOPの種別Bに対しては、2つのトランザクションモデル443,444が生成されている。トランザクションモデル443の確率は、0.80(=0.574/(0.574+0.142))であり、トランザクションモデル444の確率は、0.20(=0.142/(0.574+0.142))である。
【0241】
以上の処理手順を整理すると以下のようになる。
図55は、第3の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図55に示す処理をステップ番号に沿って説明する。
【0242】
[ステップS81]モデル生成部140は、プロトコルログから各処理の開始と終了のペアを抽出する。
[ステップS82]モデル生成部140は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
【0243】
[ステップS83]モデル生成部140は、処理毎に、それを呼び出し元とする呼出関係の候補から、呼び出されている処理の集合(呼出先処理集合)の候補を生成する。
[ステップS84]モデル生成部140は、呼出先処理集合の生起確率を初期化する(呼出元の処理毎に均等に確率を割り当てる)。
【0244】
[ステップS85]モデル生成部140は、呼出先処理集合とその確率から、処理種別による呼出パターンとその確率を計算する。
[ステップS86]モデル生成部140は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップS88に進められる。終了条件を満足していない場合、処理がステップS87に進められる。
【0245】
[ステップS87]モデル生成部140は、呼出先処理集合の候補それぞれの生起確率を、処理種別毎の呼出パターンとその確率から再計算する。その後、処理がステップS85に進められる。
【0246】
[ステップS88]終了条件を満足した場合、モデル生成部140は、処理種別毎の呼出パターンのうち、所定の条件を満たしたもの(例えば、所定の値より確率の高いもの)をトランザクションモデルとして選択する。
【0247】
[ステップS89]モデル生成部140は、呼出元の種別毎に、選択されたモデルの確率を正規化する。その後、処理が終了する。
このように第3の実施の形態では、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、発生パターン毎に生起確率を計算する。そして、生起確率が上位の発生パターンを所定の個数選択し、選択された発生パターンに基づいて、トランザクションモデルを生成するようにした。これにより、ある呼出元の処理種別について可能な処理パターンが複数ある場合でも、そのモデルを正しく生成することができる。
【0248】
なお、この方法では、多重度が高い場合、処理量が非常に増大する。そこで、以下のような方法で、処理量の軽減を図ることもできる。
第3の実施の形態では処理種別毎に呼び出すパターンとその確率を何度か更新していくことでトランザクションモデルを生成している。そして、最終的に得られたパターンから可能性の低いパターンを除去している。このとき、パターンとその確率の更新の際に、その都度可能性の低いパターンを除去することも可能である。一度除去した呼出パターンは、以後のモデル生成処理中に可能性として考慮する必要がないため、モデル生成の早期に除去することで、モデル生成に要する時間を短縮することができる。
【0249】
例えば、図50および図51が生成された段階で、すなわち最初に可能なパターンとその確率が生成された段階で、確率が閾値以下となるパターンを削除する。閾値が0.1である場合、図50に示された処理種別Aからの呼出パターンの確率は1/8以上であるので削除されない。一方図51に示された処理種別Bからの場合には、パターンB5、パターンB6、パターンB8の3パターンの確率が1/16で閾値以下となるので、消去することができる。消去されたパターンは、実際の処理からこれらのパターンで処理が呼び出されることはないことを示す。
【0250】
これにより、以後再び可能なパターンの確率を求める際に、消去されたパターンは考慮する必要がないことを意味する。例えば種別Bの処理P3からの呼び出される処理の集合は上の例でも記したように
{処理P8}
{処理P8,処理P7}
{処理P8,処理P9}
{処理P8,処理P10}
{処理P8,処理P7,処理P9}
{処理P8,処理P7,処理P10}
{処理P8,処理P9,処理P10}
{処理P8,処理P7,処理P9,処理P10}
である。処理P8と処理P10の種別がa、処理P7と処理P9の種別がbであることから、これらのうち{処理P8,処理P10}がパターンB5、{処理P8,処理P7,処理P9}がパターンB6、{処理P8,処理P7,処理P9,処理P10}がパターンB8に属する。すなわち、これらの呼び出しは起こり得ない。よって以後の処理でこれらの呼び出しの発生を考慮する必要がなくなる。起こり得ないパターンを判断対象から除外することで、以降の処理量を軽減することができる。
【0251】
[その他の応用例]
上記各実施の形態では、スイッチ10のミラーポートからメッセージを構成するパケットを収集しているが、各サーバ31,32,33において、メッセージのダンプデータを記録しておき、そのメッセージ観測部120が各サーバ31,32,33からダンプデータを収集してもよい。
【0252】
また、分析部150によって分析された内容に応じて、トランザクションモデルを更新することもできる。例えば、任意の種別のトランザクション内の各サーバでの処理時間が分析部150で求められると、種別毎の処理時間の平均を求め、対応するトランザクションモデルの処理時間とすることができる。
【0253】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム分析装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープなどがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM(Random Access Memory)、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録媒体には、MO(Magneto-Optical disk)などがある。
【0254】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROMなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【0255】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【0256】
(付記1) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムにおいて、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラム。
【0257】
(付記2) 前記メッセージ観測手段は、前記ネットワーク内に設けられたスイッチのミラーポートを介して、前記メッセージの収集を行うことを特徴とする付記1記載のシステム分析プログラム。
【0258】
(付記3) 前記メッセージ観測手段は、前記サーバに保持されたメッセージのダンプデータから前記メッセージを収集することを特徴とする付記1記載のシステム分析プログラム。
【0259】
(付記4) 前記モデル生成手段は、前記制約条件として、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件が定義されていることを特徴とする付記1記載のシステム分析プログラム。
【0260】
(付記5) 前記モデル生成手段は、制約条件として、サーバ間の呼び出し方向が定義されていることを特徴とする付記1記載のシステム分析プログラム。
(付記6) 前記モデル生成手段は、同一トランザクション内の各処理種別のリクエストメッセージからレスポンスメッセージまでの時間に基づいて、各プロトコルに対応する処理の前記サーバでの所要時間を計算し、前記トランザクションモデルに設定することを特徴とする付記1記載のシステム分析プログラム。
【0261】
(付記7) 前記モデル生成手段は、クライアントから最初に呼び出されるリクエストメッセージと、当該リクエストメッセージに対応するレスポンスメッセージとから、各トランザクションの処理時間帯を判定し、他のトランザクションとの間で処理時間帯が重複しない非多重トランザクションを検出し、検出された前記非多重トランザクションの処理時間帯内に発生した前記プロトコルログに基づいて前記トランザクションモデルを生成することを特徴とする付記1記載のシステム分析プログラム。
【0262】
(付記8) 前記モデル生成手段は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合し、処理間の呼出関係の可能性を算出することを特徴とする付記1記載のシステム分析プログラム。
【0263】
(付記9) 前記モデル生成手段は、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、前記発生パターン毎に生起確率を計算し、前記生起確率が上位の前記発生パターンの所定の個数選択し、選択された前記発生パターンに基づいて、前記トランザクションモデルを生成することを特徴とする付記1記載のシステム分析プログラム。
【0264】
(付記10) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析方法において、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
ことを特徴とするシステム分析方法。
【0265】
(付記11) 複数のサーバが接続されたネットワークの運用形態を分析するためのシステム分析装置において、
前記ネットワークを介して受け渡されるメッセージを収集するメッセージ観測手段と、
収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納するメッセージ解析手段と、
モデル生成指示が入力されると、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納するモデル生成手段と、
分析指示が入力されると、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する分析手段と、
を有することを特徴とするシステム分析装置。
【0266】
(付記12) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体。
【符号の説明】
【0267】
1 システム分析装置
1a メッセージ観測手段
1b メッセージ解析手段
1c プロトコルログ記憶手段
1d モデル生成手段
1e トランザクションモデル記憶手段
1f 分析手段
1g 出力手段
2 ネットワーク
3a,3b,・・・ クライアント
4a,4b,・・・ サーバ
5 メッセージ
【技術分野】
【0001】
本発明はトランザクションを分析するための分析プログラム、分析方法及び分析装置に関する。
【背景技術】
【0002】
最近のIT(情報通信技術)を利用したコンピュータシステムは大規模かつ複雑な構成であることが多い。例えば、オンラインバンキングの入金や振込み処理など、各種業務サービスがWebサーバ/アプリケーションサーバ/データベース(DB)サーバからなるWeb3階層システムにて提供される例が増えている。こういったシステムは、業務の効率化やセキュリティ対策などの理由から大規模で複雑な構成である。また、即時性を要求される業務サービスが多く、サービス停止やレスポンス悪化は大きな問題である。そのため、大規模システムに対する運用状況の詳細な把握や性能問題の迅速な解決が必須である。
【0003】
しかも、複数のアプリケーションが連携して動作する複雑なシステム(Web3階層システムなど)で、性能劣化や障害の原因を突き止めるためには、サーバそれぞれの挙動だけでなくシステム全体としての性能を観測・分析することが必要である。例えば、Web3階層システムにおいては、Webサーバへの処理要求に伴ってアプリケーションサーバへの処理要求が発生する場合がある。アプリケーションサーバ・DBサーバ間についても同様である。こういったアプリケーション間における処理の呼出関係は、性能問題のシステム内への波及を調べる上で必須である。
【0004】
そこで、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡する機能が望まれている。このような追跡が可能となれば、システムに存在する問題の分析が容易となる。
【0005】
サーバ間の処理の受け渡しを追跡する技術としては、例えば、各サーバにエージェントを実装し、そのエージェントに個々のサーバの運用状況を解析及びレポートさせる技術がある(例えば、非特許文献1参照)。
【0006】
エージェントによって運用状態を把握し、その結果をレポートする技術は実用化されている(例えば、非特許文献2,3参照)。
【先行技術文献】
【非特許文献】
【0007】
【非特許文献1】「Technical Standard Application Response Measurement(ARM) Issue4.0-C Binding」THE OPEN GROUP、2003年10月、Figure 2
【非特許文献2】「IBM Tivoli Monitoring for Transaction Performance helps maximize performance of your applications.」,"IBM Corporation Software Group",2003年9月
【非特許文献3】「IBM Tivoli Monitoring for Transaction Performance, Version 5.2」,"IBM Corporation Software Group"、2003年9月
【発明の概要】
【発明が解決しようとする課題】
【0008】
しかし、従来の技術では、アプリケーション単位の詳細な情報を取得する場合には、各サーバに対してエージェント等の何らかのアプリケーションを組み込んで対応する必要がある。そのため、既存システムの性能分析が困難である。特に最近のシステムでは、アプリケーション毎に異なる企業によって作成されている。従って、全てのアプリケーションについて、エージェントとの間の情報の受け渡しを行うように改良することは困難である。
【0009】
本発明はこのような点に鑑みてなされたものであり、システムのサービス提供機能に手を加えずにトランザクションを分析できる分析プログラム、分析方法及び分析装置を提供することを目的とする。
【課題を解決するための手段】
【0010】
本発明では上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、コンピュータに、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、を実行させるための分析プログラムが提供される。
【0011】
また、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、を有する分析装置が提供される。
【0012】
さらに、上記課題を解決するために、複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、コンピュータが、前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、分析方法が提供される。
【発明の効果】
【0013】
本発明では、メッセージ集合からのトランザクションモデルの生成が可能となる。
【図面の簡単な説明】
【0014】
【図1】実施の形態に適用される発明の概念図である。
【図2】第1の実施の形態に係るシステム構成を示す図である。
【図3】システム分析装置のハードウェア構成例を示す図である。
【図4】システム分析装置の機能ブロックを示す図である。
【図5】システム分析処理の手順を示すフローチャートである。
【図6】メッセージ観測状況を示す概念図である。
【図7】パケットデータ記憶部のデータ構造例を示す図である。
【図8】パケットに含まれる情報を示す図である。
【図9】IPヘッダの詳細を示す図である。
【図10】TCPヘッダの詳細を示す図である。
【図11】メッセージ解析部の機能を示すブロック図である。
【図12】再構成したセッションの例である。
【図13】メッセージ再構成例を示す第1の図である。
【図14】リクエストへのレスポンスメッセージの対応付けの例を示す図である。
【図15】オブジェクト名の割り当て例を示す図である。
【図16】1つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。
【図17】プロトコルログの例を示す図である。
【図18】プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。
【図19】トランザクションモデル生成処理を示すフローチャートである。
【図20】選択されるモデル生成用メッセージを示す図である。
【図21】「残高確認」トランザクションのモデル生成例を示す図である。
【図22】「入金」トランザクションのモデル生成例を示す図である。
【図23】分析処理の手順を示すフローチャートである。
【図24】分析部へ入力されるメッセージの例を示す図である。
【図25】メッセージ分析例を示す第1の図である。
【図26】メッセージ分析例を示す第2の図である。
【図27】メッセージ分析例を示す第3の図である。
【図28】メッセージ分析例を示す第4の図である。
【図29】メッセージ分析例を示す第5の図である。
【図30】メッセージ分析例を示す第6の図である。
【図31】メッセージ分析例を示す第7の図である。
【図32】メッセージ分析例を示す第8の図である。
【図33】メッセージ分析例を示す第9の図である。
【図34】メッセージ分析例を示す第10の図である。
【図35】サーバの平均処理時間の表示例を示す図である。
【図36】トランザクション別処理時間及び内訳の表示例を示す図である。
【図37】処理時間ヒストグラムの表示例を示す図である。
【図38】複数の情報を同時に表示した場合の画面例を示す図である。
【図39】表示対象要素間の連携の様子を示す図である。
【図40】分析部へ入力されるメッセージの例を示す図である。
【図41】モデル生成部に入力されたメッセージから認識される処理を示す図である。
【図42】制約を満たす処理間の呼出関係を示す図である。
【図43】呼出回数行列の例を示す図である。
【図44】呼び出し候補の確率を求めた結果を示す図である。
【図45】更新後の呼出回数行列を示す図である。
【図46】2回目の処理で呼び出し候補の確率を求めた結果を示す図である。
【図47】2回目の更新後の呼出回数行列を示す図である。
【図48】最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。
【図49】第2の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【図50】処理種別Aからの呼出パターンとその確率を示す第1の図である。
【図51】処理種別Bからの呼出パターンとその確率を示す第1の図である。
【図52】処理種別Aからの呼出パターンとその確率を示す第2の図である。
【図53】処理種別Bからの呼出パターンとその確率を示す第2の図である。
【図54】モデル生成結果を示す図である。
【図55】第3の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。
【発明を実施するための形態】
【0015】
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
【0016】
図1は、実施の形態に適用される発明の概念図である。システム分析装置1は、ネットワーク2を介してクライアント3a,3b,・・・やサーバ4a,4b,・・・に接続されている。サーバ4a,4b,・・・は、クライアント3a,3b,・・・からの要求に応じてサービスを提供する。サービスの提供は、複数のサーバ4a,4b,・・・によって互いに連携して実行される。このときシステム分析装置1は、ネットワーク2を介して送受信されるメッセージ5を取得し、ネットワーク2の運用形態を分析する。分析を行うために、システム分析装置1は、図1に示す各機能を有している。
【0017】
メッセージ観測手段1aは、ネットワーク2を介して受け渡されるメッセージ5を収集する。収集したメッセージ5は、メッセージ解析手段1bに渡される。
メッセージ解析手段1bは、収集したメッセージの内容を解析して、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージか(メッセージの方向)を判別する。処理種別は、例えば、メッセージに適用されているプロトコルがHTTP(HyperText Transfer Protocol)であれば、処理要求で指定されたURL(Uniform Resource Locator)によって判別できる。そして、メッセージ解析手段1bは、判別された情報をプロトコルログとしてプロトコルログ記憶手段1cに格納する。
【0018】
モデル生成手段1dは、モデル生成指示が入力されると、プロトコルログ記憶手段1cに格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を認識する。そして、モデル生成手段1dは、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成する。モデル生成手段1dは、生成したトランザクションモデルをトランザクションモデル記憶手段1eに格納する。
【0019】
なお、選択基準としては、例えば、処理時間帯が他のトランザクションと重複しない非多重トランザクションの時間帯内のメッセージの集合を選択することが定められる。また、制約条件は、例えば、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件である。
【0020】
分析手段1fは、分析指示が入力されると、トランザクションモデル記憶手段1eに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログをプロトコルログ記憶手段1cから抽出し、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する。例えば、トランザクション内での各サーバでの処理時間が分析される。
【0021】
出力手段1gは、分析手段1fによる分析結果を、グラフ等の視覚的に認識しやすい統計情報としてモニタ等に出力する。
このようなシステム分析装置1であれば、メッセージ観測手段1aにより、ネットワーク2を介して受け渡されるメッセージ5が収集される。すると、メッセージ解析手段1bにより、収集したメッセージの内容が解析され、メッセージの発生時刻、メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかが判別され、判別された情報がプロトコルログとしてプロトコルログ記憶手段1cに格納される。
【0022】
このとき、モデル生成指示が入力されると、モデル生成手段1dにより、プロトコルログ記憶手段に格納されたプロトコルログにおける処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理が認識される。そして、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、制約条件を満たすトランザクションモデルが生成される。そして、生成されたトランザクションモデルがトランザクションモデル記憶手段1eに格納される。
【0023】
また、分析指示が入力されると、分析手段1fにより、トランザクションモデル記憶手段1eに格納されたトランザクションモデルで示される呼出関係に合致するプロトコルログがプロトコルログ記憶手段1cから抽出され、抽出されたプロトコルログに示されるメッセージで構成されるトランザクションの処理状態が分析される。分析結果は、出力手段1gによって出力され、ユーザに対して提示される。
【0024】
このように、ネットワーク2を介して受け渡されるメッセージ5から、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合からトランザクションモデルを生成するようにした。すなわち、処理間の呼出関係として生起確率が高い関係を選択し、その関係によって成立するトランザクションをモデル化している。このようにして生成したトランザクションモデルと合致するメッセージをプロトコルログから検出することで、サーバ4a,4bに対して機能追加を行わずに、共通のトランザクションを構成するメッセージ集合を特定し、処理状態の解析が可能となる。
【0025】
以下、本発明の実施の形態について詳細に説明する。
[第1の実施の形態]
第1の実施の形態では、インターネットバンキングの業務サービスを提供するWeb3階層システムにおいて、「残高確認」と「入金」との2つのサービスを提供する場合の例である。
【0026】
なお、第1の実施の形態では、管理対象となる要素として「セッション」、「メッセージ」、「オブジェクト」、及び「トランザクション」がある。
「セッション」は、送受信側のIP(Internet Protocol)アドレスとポート番号によって定まる通信路上で送受信されるデータの集合である。
【0027】
「メッセージ」は、TCP(Transmission Control Protocol)セッション上で複数の機器がやりとりするデータの最小単位である。例えば、HTTPでのリクエストやそれに対するレスポンスが、メッセージに該当する。
【0028】
「オブジェクト」は、サーバがメッセージを受信してからレスポンスを送信するまでに行う単一又は複数の処理や入力されるデータを仮想的に単一のものとしてまとめたものである。ここで言う処理とは、CPU(Central Processing Unit)での計算、データの入出力とそれぞれに対する待ち時間などが含まれる。
【0029】
「トランザクション」は、システムに対する要求によって発生するオブジェクト処理の集合である。
図2は、第1の実施の形態に係るシステム構成を示す図である。図2の例では、スイッチ10を介して、クライアント21,22,23、Webサーバ31、アプリケーションサーバ32、データベース(DB)サーバ33、及びシステム分析装置100が接続されている。Webサーバ31、アプリケーションサーバ32、及びDBサーバ33は、クライアント21,22,23からの要求に応じて、サービスを提供する。
【0030】
サービスを提供する為のトランザクションにおいて、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33間で、スイッチ10を介してメッセージの送受信が行われる場合がある。このスイッチ10を介して送受信されるメッセージをシステム分析装置100が監視することで、システムの動作状態の分析を行うことができる。
【0031】
図3は、システム分析装置のハードウェア構成例を示す図である。システム分析装置100は、CPU101によって装置全体が制御されている。CPU101には、バス107を介してRAM(Random Access Memory)102、ハードディスクドライブ(HDD:Hard Disk Drive)103、グラフィック処理装置104、入力インタフェース105、および通信インタフェース106が接続されている。
【0032】
RAM102には、CPU101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、RAM102には、CPU101による処理に必要な各種データが格納される。HDD103には、OSやアプリケーションプログラムが格納される。
【0033】
グラフィック処理装置104には、モニタ11が接続されている。グラフィック処理装置104は、CPU101からの命令に従って、画像をモニタ11の画面に表示させる。入力インタフェース105には、キーボード12とマウス13とが接続されている。入力インタフェース105は、キーボード12やマウス13から送られてくる信号を、バス107を介してCPU101に送信する。
【0034】
通信インタフェース106は、スイッチ10に接続されている。通信インタフェース106は、スイッチ10を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図3には、システム分析装置100のハードウェア構成例を示したが、クライアント21,22,23、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33も同様のハードウェア構成で実現することができる。
【0035】
図4は、システム分析装置の機能ブロックを示す図である。システム分析装置100は、パケットデータ記憶部111、プロトコルログ記憶部112、モデル記憶部113、分析結果記憶部114、メッセージ観測部120、メッセージ解析部130、モデル生成部140、分析部150、及び出力部160を有している。
【0036】
パケットデータ記憶部111は、スイッチ10を介して送受信されたメッセージを構成するパケット記憶するための記憶装置である。プロトコルログ記憶部112は、パケットを解析することにより取得したメッセージの情報を記憶するための記憶装置である。モデル記憶部113は、トランザクションを完了するまでに送受信されるメッセージのリスト(トランザクションモデル)を記憶する記憶装置である。分析結果記憶部114は、メッセージの分析結果を記憶する記憶装置である。
【0037】
メッセージ観測部120は、スイッチ10を介して送受信されるメッセージを観測し、そのメッセージを構成するパケットをパケットデータ記憶部111に格納する。
メッセージ解析部130は、パケットデータ記憶部111に格納されたパケットの内容を解析し、解析結果をプロトコルログ記憶部112に格納する。
【0038】
モデル生成部140は、プロトコルログ記憶部112に格納された情報に基づいてトランザクションモデルを生成し、モデル記憶部113に格納する。
分析部150は、プロトコルログ記憶部112に格納された情報と、モデル記憶部113に格納されたトランザクションモデルとを比較して、各トランザクションの処理時間等の統計情報を分析する。そして、分析部150は、分析結果を分析結果記憶部114に格納する。
【0039】
出力部160は、分析結果記憶部114に格納されている分析結果を、グラフ等でモニタ11等に出力する。
このような構成のシステム分析装置100で、次のようなシステム分析処理が実行される。
【0040】
図5は、システム分析処理の手順を示すフローチャートである。以下、図5に示す処理をステップ番号に沿って説明する。
[ステップS11]メッセージ観測部120は、スイッチ10を流れるメッセージを観測し、パケットデータ記憶部111に格納する。
【0041】
[ステップS12]メッセージ解析部130は、パケットデータ記憶部111に格納されたメッセージを解析する。
[ステップS13]その後、モデル生成部140により、モデル生成指示が入力されているか否かが判断されるとともに、分析部150により、分析指示が入力されているかが判断される。モデル生成指示や分析指示は、例えば、システム分析装置100の管理者によるキーボード12等を用いた操作入力によって与えられる。モデル生成指示が入力されている場合、処理がステップS14に進められる。分析指示が入力されている場合、処理がステップS15に進められる。
【0042】
[ステップS14]モデル生成指示が入力されている場合、モデル生成部140は、プロトコルログ記憶部112に格納されている情報を参照し、トランザクションモデルを生成する。そして、モデル生成部140は、生成したトランザクションモデルをモデル記憶部113に格納する。その後、処理が終了する。
【0043】
[ステップS15]分析指示が入力されている場合、分析部150は、モデル記憶部113に格納されているトランザクションモデルとプロトコルログ記憶部112に格納されている情報とを参照し、実行されているトランザクションに関する情報を分析する。そして、分析部150は、分析結果を分析結果記憶部114に格納する。
【0044】
[ステップS16]出力部160は、分析結果記憶部114に格納された分析結果に基づいて、統計情報等をモニタ11に出力する。その後、処理が終了する。
このような手順でシステム分析が行われる。以下、図5に示す各ステップの処理を、詳細に説明する。
【0045】
まず、メッセージ観測処理について説明する。
図6は、メッセージ観測状況を示す概念図である。この例では、Webサーバ31、アプリケーションサーバ32、DBサーバ33が監視対象となっている。各サーバは、スイッチ10の個別のポート11,12,13に接続されている。また、システム管理装置100は、スイッチ10のポート14に接続されている。
【0046】
スイッチ10は、自身を通過するデータをミラーリングする機能を有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。
【0047】
図6の例では、Webサーバ31が接続されたポート11、アプリケーションサーバ32が接続されたポート12、及びDBサーバ33が接続されたポート13のミラーリング先として、システム分析装置100が接続されたポート14が指定されている。これにより、各サーバ宛のパケットは宛先となるサーバに入力されるとともに、システム分析装置100にも入力される。
【0048】
例えば、クライアント21からの要求に応じて、Webサーバ31、アプリケーションサーバ32、及びDBサーバ33が連動してサービスを提供する場合を想定する。この場合、まず、クライアント21からWebサーバ31に対してパケット41(例えば、HTTPのパケット)が送信される。このとき、パケット41と同じ内容のパケット51がシステム分析装置100に入力される。次に、Webサーバ31からアプリケーションサーバ32へパケット42(例えば、IIOP(Internet Inter-ORB Protocol)のパケット)が送信されると、パケット42と同じ内容のパケット52がシステム分析装置100に入力される。さらに、アプリケーションサーバ32からDBサーバ33へ、パケット43(例えば、DBアクセスのパケット)が送信されると、パケット43と同じ内容のパケット53がシステム分析装置100に入力される。
【0049】
システム分析装置100に入力されたパケット51,52,53は、スイッチ10に直接接続されたメッセージ観測部120で取得され、パケットデータ記憶部111に格納される。具体的には、メッセージ観測部120は、スイッチ10から送られたパケット51,52,53をキャプチャし、受信時刻とともにパケットデータ記憶部111に格納する。
【0050】
なお、メッセージ観測部120は、キャプチャしたパケット51,52,53を蓄積せずに、観測と同時にメッセージ解析部130に送ってもよい。また、メッセージ観測部120は、メッセージ観測手段において必要なパケットのみをキャプチャすることもできる。さらに、スイッチ10において必要なデータのみを選択してミラーリングすることもできる。
【0051】
図7は、パケットデータ記憶部のデータ構造例を示す図である。パケットデータ記憶部111には、複数のパケット551〜558が格納されている。また、パケットデータ記憶部111には、各パケットデータ551〜558の受信時刻を示す時刻情報61〜68が格納されている。
【0052】
図8は、パケットに含まれる情報を示す図である。時刻情報61とともに格納されているパケット551は、イーサネットヘッダ(Etherヘッダ)(イーサネット:登録商標)551a、IPヘッダ551b、TCPヘッダ551c、及びTCPデータ551dで構成される。
【0053】
図9は、IPヘッダの詳細を示す図である。IPヘッダ551bは、バージョン情報(version)、ヘッダ長、サービスタイプ(Type of Service)、データ長、識別子(ID)、フラグ(Flag)、フラグメントオフセット(Fragment Offset)、生存時間(Time Of Live)、プロトコル(Protocol)、ヘッダチェックサム(Header Checksum)、送信側IPアドレス、受信側IPアドレス、オプション(Option)、及びパディング(Padding)で構成されている。
【0054】
図10は、TCPヘッダの詳細を示す図である。TCPヘッダ551cは、送信側ポート、受信側ポート、送信用シーケンス番号(Sequence Number)、応答確認番号(Acknowledge Number)、ヘッダ長、リザーブ(Reserved)、フラグ、ウィンドウ(Window)、チェックサム(Checksum)、緊急ポインタ(Urgent Pointer)、及びオプション(Option)で構成される。フラグは、さらに、URG(Urgent Flag)、ACK(Acknowledgement Flag)、PSH(Push Flag)、RST(Reset Flag)、SYN(Synchronize Flag)、FIN(Fin Flag)で構成される。
【0055】
メッセージ観測部120で取得したパケットは、メッセージ解析部130で解析される。
図11は、メッセージ解析部の機能を示すブロック図である。メッセージ解析部130は、TCP/UDP(User Datagram Protocol)セッション再構成部131、メッセージ再構成部132、オブジェクト名割り当て部133、及びログ出力部134を有している。
【0056】
TCP/UDPセッション再構成部131は、パケット551〜558を、そのパケット551〜558が属するセッション71〜73毎に振り分ける。メッセージ再構成部132は、セッション71〜73に振り分けられたパケット551〜558の中から所定のデータを抽出し、メッセージ対81〜83を再構成する。オブジェクト名割り当て部133は、メッセージ対81〜83に対応するオブジェクト名を決定する。ログ出力部134は、処理結果をプロトコルログ記憶部112に出力する。
【0057】
メッセージ観測部120からメッセージ解析部130にパケット551〜558が入力されると、TCP/UDPセッション再構成部131、メッセージ再構成部132、オブジェクト名割り当て部133、ログ出力部134の順番で、処理が実行される。なお、メッセージ観測部120から渡されるパケット551〜558は、パケットデータ記憶部111に予め格納されたパケットが渡される場合と、メッセージ観測部120によって観測されたパケットが転送される場合とがある。
【0058】
以下、メッセージ解析部130内の各要素が実行する処理を、詳細に説明する。
メッセージ解析部130に渡されたパケット551〜558は、まず、TCP/UDPセッション再構成部131に入力される。TCP/UDPセッション再構成部131は、入力されたパケット551〜558のセッション別の振り分けを行う。
【0059】
具体的には、TCP/UDPセッション再構成部131は、まずパケット551のIPヘッダ551bから、送受信側IPアドレス(図9参照)を取得する。次に、TCP/UDPセッション再構成部131は、TCPヘッダ551cから送信側ポート番号と受信側ポート番号とを取得する(図10参照)。そして、TCP/UDPセッション再構成部131は、取得した4つの値の組をセッションの識別子とする。このとき、識別子に一意な番号を割り当てることもできる。
【0060】
TCP/UDPセッション再構成部131は、各パケット551〜558の識別子を生成し、同じ識別子を持つパケットを、同じセッションで送られたパケットであるとして振り分ける。
【0061】
次に、TCP/UDPセッション再構成部131は、TCPの場合、TCPヘッダ551cに含まれるフラグを読み取って、開始・確立・切断などのセッション状態を取得する(図10参照)。例えば、SYN「1」のパケットの検出によってセッションの開始を認識し、そのパケットに対するACK「1」の応答によってセッションの確立を認識し、セッション確立状態でデータ伝送とそれに対するACK「1」の応答が繰り返し行われ、最後にFIN「1」パケットの検出によってセッションの切断を認識する。
【0062】
また、TCP/UDPセッション再構成部131は、IPヘッダ551b・TCPヘッダ551cに含まれるデータ長とヘッダ長を取得して、データ長から各ヘッダ長を引くことでデータ部の長さ(データサイズ)を取得する。
【0063】
さらに、TCP/UDPセッション再構成部131に対して、事前に各サーバのIPアドレスを与えておくことで、IPアドレスの組から各パケットの送信方向を決定することもできる。
【0064】
また、TCP/UDPセッション再構成部131は、例えば、パケットのIPヘッダから、サーバアドレスが送信アドレスにあれば送信側ポート番号を、サーバアドレスが宛て先アドレスにあれば受信側ポート番号を読み取る。そして、TCP/UDPセッション再構成部131は、そのポート番号を識別子とすることでどのサービスに関するセッションであるかを調べることができる。例えば、サーバ側のポートが80番である場合、Webサーバとの通信(HTTP)であると判定する。
【0065】
図12は、再構成したセッションの例である。TCP/UDPセッション再構成部131によって、パケット551〜558からTCPのセッション71〜73が再構成される。図12では、縦軸が時間軸を表している(図中、上から下に時間が進行する)。
【0066】
各軸の上の数字が、各機器のIPアドレスを表している。IPアドレスの組によってパケットが振り分けられている。図12では、各パケットから取得したフラグもしくはデータサイズとともに時系列のシーケンスで表示されている。
【0067】
このように、セッション71〜73毎に振り分けられたパケットがメッセージ再構成部132に渡される。
メッセージ再構成部132は、セッション71〜73毎に振り分けられたパケットのデータ部からメッセージを再構成する。メッセージ再構成部132では、まず同一のセッション71〜73で送受信されるパケットの集まりからデータ部分を抜き出して並べる。そして、メッセージ再構成部132は、並べられたデータ部分の列を、プロトコルのフォーマットに従ってメッセージのサイズを取得してメッセージを分割する。このとき、メッセージが複数に分割送信されていた場合には、複数のデータ部分を連結してひとつのメッセージを切り出してよい。もしくは、連結された複数のメッセージが送信されていた場合には、単一のデータ部から複数のメッセージを切り出してよい。また、各メッセージにはセッション上で一意な番号を割り振ってよい。
【0068】
図13は、メッセージ再構成例を示す第1の図である。図13は、送信側IPアドレスが10.25.214.10、受信側IPアドレスが10.25.214.105、送信側ポート番号が3449、受信側ポート番号が80である識別子を持つセッション71上のメッセージを解析する例である。
【0069】
メッセージ再構成部132は、パケット554の属するセッションの受信側ポート番号が80番であることから、パケット554のデータ部をHTTPによるクライアント21からWebサーバ31へのリクエストであると判定し、HTTPメッセージとして切り分ける。
【0070】
HTTPの場合、メッセージ再構成部132は、データから特定のオクテットの組み合わせ(0x0D0A0D0A=\r\n\r\n)を検索し、その位置までをヘッダ部(HTTPヘッダ)とする。次に、データ部(HTTPデータ)が存在する場合には、ヘッダ部に含まれるContent-Lengthフィールドからデータ部の長さを取得し、メッセージを切り出すとともに、メッセージを構成する最初のパケット554の受信時刻「00.00.00:100」をそのメッセージの受信時刻とする。そして、メッセージ再構成部132は、メッセージ種別や要求されたURL、応答結果データを取得する。
【0071】
例えばHTTPメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・URL・個別のパラメータなどがある。また、例えばIIOPメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・メソッド名・個別のパラメータなどがある。さらに、例えばDBメッセージから取得する情報としては、ヘッダ長・データ長・メッセージ種別・SQL(Structured Query Language)文・SQL文のパラメータなどがある。
【0072】
図13の例では、HTTPリクエストメッセージのヘッダの先頭がPOSTであり、その直後が/corba/servlet/Balanceであることからメッセージ種別はPOST、オブジェクトを表すURLは/corba/servlet/Balanceであることが分かる。また、Content-Lengthフィールドの値が29であることからデータ部の長さは29バイトあることが分かる。したがって、メッセージ再構成部132は、ヘッダ終端から29バイトまでをメッセージとして切り出す。
【0073】
また、メッセージ再構成部132では、実行主体に対するリクエストメッセージとその返答であるレスポンスメッセージを対応付け、応答までにかかった時間を算出する。例えばHTTPの場合、リクエストメッセージを、同一のセッション上で直後に現れるレスポンスメッセージと対応付ける。また、レスポンスメッセージの受信時刻からリクエストメッセージの受信時刻を差し引き、このメッセージ対の応答時間とする。また、このとき、対応付けたメッセージ対に一意な番号を割り当ててもよい。
【0074】
図14は、リクエストへのレスポンスメッセージの対応付けの例を示す図である。図14の例では、HTTPレスポンスメッセージとHTTPリクエストメッセージとを対応付ける場合を示している。
【0075】
図13のパケット554から取得したメッセージと、図14のパケット556から取得したメッセージは、送信側IPアドレス10.25.214.105、受信側IPアドレス10.25.214.10、送信側ポート番号80、受信側ポート番号3449のセッション上でやりとりされたメッセージであることから、図14のパケット556から取得したメッセージは、図13のパケット554から取得したメッセージと同一セッション上で連続して送信されたメッセージであると判定する。また、2つのメッセージの送信方向が反対であることから、これら2つのメッセージを対応付けて、メッセージ対が生成される。メッセージ再構成部132は、メッセージ対の応答時間を算出し、これら二つのメッセージに共通の識別番号1を割り当てる。
【0076】
このようにして、メッセージ対がオブジェクト名割り当て部133に渡される。そして、オブジェクト名割り当て部133では、メッセージ対に対応するオブジェクト名が決定される。
【0077】
なお、オブジェクト名は、以降の装置で分析したい内容に応じて変更してよい。また、異なるメッセージに対して同じオブジェクト名を割り当ててもよく、単一のメッセージに対して複数のオブジェクト名を割り当ててもよい。また、取得できる全ての情報を仮のオブジェクト名として割り当てておき、以降の装置においてオブジェクト名を再び決定してもよい。
【0078】
例えばHTTPメッセージ対にオブジェクト名としてURLを割り当てる。これは、実行する処理とメッセージを関連付けるための情報がURL中に含まれることによる。
また、例えばIIOPメッセージ対にオブジェクト名としてメソッド名を割り当てる。これは、IIOPのメソッド名がサーバ上における単一の処理を表すためである。
【0079】
また、例えばDBメッセージ対にオブジェクト名としてSelect・Insert・Update・FetchなどのSQLオペレータ種別とデータベーステーブル名の組を割り当てる。これは、データベース操作による書き込みの有無や、操作する対象となるデータベーステーブルのサイズなどによって異なる処理の量や時間を区別するためである。
【0080】
図15は、オブジェクト名の割り当てとメッセージの解析結果を示す図である。この例ではHTTPの図14で対応付けたメッセージ対81に対してオブジェクト名81cを割り当てている。このオブジェクト名81cは、リクエストメッセージで指定されたURLである。メッセージ81aは図13のパケット554から再構成したHTTPリクエストメッセージであり、メッセージ81bは図14のパケット556から再構成したHTTPレスポンスメッセージであり、メッセージ対81はこれらのメッセージを対応付けたものである。
【0081】
図16は、1つのトランザクションを構成する各メッセージのオブジェクト名の割り当てとメッセージ解析結果を示す図である。この例では、HTTPプロトコルのメッセージと同様に、IIOPやDBなど他のプロトコルについてもメッセージを再構成し、オブジェクト名を割り当てている。
【0082】
したがって、図13、図14、図15で対応付けたHTTPのメッセージ81a,81b(HTTPのセッション上での識別番号1)、IIOPのセッション上で識別番号1を持つリクエストのメッセージ82a(オブジェクト名:Mbalance)と対応するレスポンスのメッセージ82b、及びDBのセッション上で識別番号1を持つリクエストのメッセージ83a(オブジェクト名:Fetch Account)と対応するレスポンスのメッセージ83bが再構成されている。これらのメッセージが、抽出したオブジェクト名とともにシーケンス図として表示されている。
【0083】
メッセージ81aのオブジェクト名は、/corba/servlet/Balanceである。メッセージ82aのオブジェクト名は、Mbalanceである。メッセージ83aのオブジェクト名は、Fetch Accountである。
【0084】
このような、オブジェクト名が割り当てられたメッセージ対81〜83が、ログ出力部134に入力される(図11参照)。すると、ログ出力部134は、TCP/UDPセッション再構成部131と、メッセージ再構成部132と、オブジェクト名割り当て部133で得られた情報を、プロトコルログとして出力する。このとき、出力されるプロトコルログはテキスト形式であってもよく、バイナリ形式であってもよい。
【0085】
図17は、プロトコルログの例を示す図である。この例では、テキスト形式で出力したプロトコルログ112a〜112fが示されている。
プロトコルログ112a〜112fには、メッセージ毎に、時刻(メッセージの受信時刻)、識別番号、プロトコル(プロトコルの名称)、方向(リクエストかレスポンスか)、及びオブジェクト/応答時間(リクエストについてはオブジェクト名、レスポンスに対しては応答時間)が設定されている。
【0086】
例えば、HTTPのセッションの場合、リクエストのメッセージを示すプロトコルログ112aには、受信時刻「00.00.00.100」、識別番号「1」、オブジェクト名「/corba/servlet/Balance」が設定されている。そして、レスポンスのメッセージを示すプロトコルログ112fには、受信時刻「00.00.00.290」、識別番号「1」、応答時間「0.190(秒)」が設定されている。
【0087】
このような、クライアント21,22,23に対してサービスが提供される毎に、図17に示すようなプロトコルログ112a〜112fが、メッセージ解析部130によってプロトコルログ記憶部112内に逐次蓄積される。その結果、プロトコルログ記憶部112内には、複数のトランザクションに関係するプロトコルログが混在して格納される。
【0088】
図18は、プロトコルログ記憶部に格納されたプロトコルログの例を示す図である。プロトコルログ記憶部112には、異なるトランザクションに関連するメッセージのプロトコルログが時系列に格納されている。図18には、インターネットバンキングサービスでの「残高確認」トランザクションと「入金」トランザクション処理時に発生するメッセージに基づくプロトコルログが示されている。
【0089】
プロトコルログ記憶部112に格納されたプロトコルログは、モデル生成指示が入力されている場合、モデル生成部140に入力される。すると、モデル生成部140によって、トランザクションモデルが生成される。
【0090】
モデル生成部140は、プロトコルログ記憶部112に格納されたプロトコルログに基づいて、トランザクションモデルを獲得する。なお、図18に示したようなプロトコルログは、HTTPプロトコル、IIOPプロトコル、そしてDBプロトコルのメッセージが複雑に混ざり合っている。なお、各プロトコルのリクエストとそれに対応するレスポンスのメッセージは、メッセージ再構成部132によって生成された同じ識別番号を持つ。
【0091】
そこで、第1の実施の形態では、モデル生成部140は、処理間の呼出関係の確からしさに基づく選択基準として、次のような基準を採用する。すなわち、各トランザクションが他のトランザクション(クライアントのリクエストからレスポンスまで)とオーバラップすることのない部分(すなわち非多重(多重度1)の部分)のみを抜き出して、モデルを獲得する。非多重のトランザクションであれば、そのトランザクションが実行されている時間帯内の各処理間には、呼出関係が確実に存在する(確からしさが高い)。
【0092】
そこで、モデル生成部140は、まず、同じ識別番号を持つHTTPプロトコルのリクエスト・レスポンスのペア群を検出する。次に、モデル生成部140は、HTTPプロトコルのメッセージペアの間に、他の識別番号を持つHTTPのメッセージが存在するかどうかをチェックする。存在しない場合、モデル生成部140は、HTTPプロトコルのリクエスト・レスポンスのペア、及びその間の全てのリクエストを選択する。つまり、横断関係にないトランザクションが抽出される。
【0093】
詳細には、以下のような処理が行われる。
図19は、トランザクションモデル生成処理を示すフローチャートである。以下、図19に示す処理をステップ番号に沿って説明する。
【0094】
[ステップS21]モデル生成部140は、パラメータの初期化を行う。具体的には、多重度=0、重複フラグ=0とする。
[ステップS22]モデル生成部140は、プロトコルログ記憶部112からメッセージを読み込む。
【0095】
[ステップS23]モデル生成部140は、メッセージがあるか否かを判断する。メッセージがあれば、処理がステップS24に進められる。メッセージがなければ処理が終了する。
【0096】
[ステップS24]モデル生成部140は、読み込んだメッセージのプロトコルがHTTPか否かを判断する。HTTPであれば処理がステップS25に進められる。HTTPでなければ、処理がステップS22に進められる。
【0097】
[ステップS25]モデル生成部140は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージであれば、処理がステップS26に進められる。レスポンスのメッセージであれば、処理がステップS30に進められる。
【0098】
[ステップS26]モデル生成部140は、多重度=0か否かを判断する。多重度が0であれば、処理がステップS27に進められる。多重度が0でなければ、処理がステップS29に進められる。
【0099】
[ステップS27]モデル生成部140は、多重度をインクリメント(1加算)する。
[ステップS28]モデル生成部140は、開始位置を保存する。具体的には、処理したメッセージの位置を特定する情報(例えば、該当するプロトコルログを示すポインタ等)を格納する。その後、処理がステップS22に進められる。
【0100】
[ステップS29]モデル生成部140は、多重度をインクリメント(1加算)し、さらに重複フラグの値を1に設定する。その後、処理がステップS22に進められる。
[ステップS30]ステップS25でレスポンスのメッセージであると判断されると、モデル生成部140は、多重度=1か否かを判断する。多重度が1であれば、処理がステップS31に進められる。多重度が1以外であれば、処理がステップS22に進められる。
【0101】
[ステップS31]モデル生成部140は、重複フラグ=0か否かを判断する。重複フラグが0であれば、処理がステップS32に進められる。重複フラグが1であれば、処理がステップS33に進められる。
【0102】
[ステップS32]モデル生成部140は、開始位置から現在位置のメッセージをモデル生成用メッセージとして選択する。その後、処理がステップS34に進められる。
[ステップS33]モデル生成部140は、重複フラグの値を0に設定する。
【0103】
[ステップS34]モデル生成部140は、多重度をデクリメント(1減算)する。その後、処理がステップS22に進められる。
このようにして、他のトランザクションと重複しないトランザクションを構成するメッセージを特定し、モデル生成用メッセージとして選択することができる。
【0104】
図20は、選択されるモデル生成用メッセージを示す図である。図20には、図18に示すようなプロトコルログからモデル生成に抽出されるメッセージの集合が示されている。
【0105】
例えば、図20のプロトコルログからHTTPのリクエスト・レスポンスのペアを探すと、識別番号=1のHTTPのリクエスト・レスポンスのペア91、識別番号=2のHTTPのリクエスト・レスポンスのペア92、識別番号=3のHTTPのリクエスト・レスポンスのペア93、そして識別番号=4のHTTPのリクエスト・レスポンスのペア94がまず検出される。しかし、識別番号=2のHTTPプロトコルのリクエスト・レスポンスのペア92の間に、識別番号=3のHTTPリクエストメッセージが存在する。そのため、4つのHTTPのリクエスト・レスポンスのペア91〜94のうち、最終的には識別番号=1と識別番号=4のペアのみが抽出される。すなわち、識別番号=1と識別番号=4のHTTPのリクエスト・レスポンスのペア91,94の間のメッセージがモデル生成に用いられることになる。
【0106】
図21は、「残高確認」トランザクションのモデル生成例を示す図である。図21には、図20における識別番号=1のHTTPのリクエスト・レスポンスのペア91の間のメッセージ集合201から生成される「残高確認」トランザクションモデル203が示されている。
【0107】
モデル生成部140では、上位(利用者側の)の処理が下位の処理を呼び出すが、逆はないという制約を用いる。この制約は、階層的な構成のシステムでは一般的な制約である。具体的には、クライアント21からWebサーバ31の処理が呼び出され、Webサーバ31からアプリケーションサーバ32の処理が呼び出され、そこからDBサーバ33の処理が呼び出される。
【0108】
モデル生成部140は、メッセージ集合201を規定の制約に沿って解析し、処理シーケンス202を作成する。具体的には、モデル生成部140は、メッセージ集合201内の各メッセージの内容を、時系列に沿って解析する。メッセージ集合201内の各メッセージの内容は、以下の通りである。
【0109】
まず、識別番号=1のHTTPプロトコルのリクエストメッセージは、クライアント21からWebサーバ31への処理要求を示す。この場合、/corba/servlet/Balanceのオブジェクト処理が請求される。次に、識別番号=1のIIOPプロトコルのリクエストメッセージはWebサーバ31からアプリケーションサーバ32へのMbalanceメソッドの処理を要求する。さらに、識別番号=1のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountという操作処理を要求する。その後、DBサーバ33、アプリケーションサーバ32、Webサーバ31から、それぞれDB、IIOP、HTTPプロトコルのレスポンスのメッセージが送信される。この内容に沿った処理シーケンス202が生成される。
【0110】
処理シーケンス202には、各セッションでの応答時間が含まれる。セッションの時間は、レスポンスメッセージに示されている。図21の例では、DBサーバ33、アプリケーションサーバ32、Webサーバ31のリクエストからレスポンスまでの応答時間がそれぞれ10msec、90msec、190msecである。
【0111】
また、「残高確認」の処理シーケンス202では、Webサーバ31で/corba/servlet/Balanceのオブジェクトが処理され、アプリケーションサーバ32でMbalanceオブジェクトが処理され、DBサーバ33でFetch Accountオブジェクトが処理されている。そこで、モデル生成部140は、各サーバにおけるオブジェクトの処理時間を算出する。
【0112】
DBサーバ33の処理時間は、DBリクエストからレスポンスまでのDBの応答時間の10msecである。アプリケーションサーバ32の処理時間は、IIOPリクエストからレスポンスの応答時間の90msecからDBサーバ33の応答時間を除いた80msec(=90−10)である。そしてWebサーバ31の処理時間は、HTTPリクエストからレスポンスの応答時間190msecからアプリケーションサーバの応答時間を除いた100msec(=190−90)である。
【0113】
そして、モデル生成部140は、オブジェクトの処理の呼出関係及び各オブジェクトの処理時間を定義したトランザクションモデル203を生成する。
図22は、「入金」トランザクションのモデル生成例を示す図である。図22には、図20における識別番号=4のHTTPのリクエスト・レスポンスのペア94の間のメッセージ集合211から生成される「入金」トランザクションモデル213が示されている。
【0114】
図21の処理と同様に、モデル生成部140は、メッセージ集合211を所定の制約に沿って解析し、処理シーケンス212を作成する。メッセージ集合211内の各メッセージの内容は、以下の通りである。
【0115】
まず、識別番号=4のHTTPプロトコルのリクエストメッセージは、クライアント21からWebサーバ31への処理を要求する。この場合、URLは/corba/servlet/Depositである。次に、識別番号=4のIIOPプロトコルのリクエストメッセージはWebサーバ31からアプリケーションサーバ32へのMdepositメソッドの処理を要求する。次に、識別番号=5のDBプロトコルのリクエストメッセージはアプリケーションサーバ32からDBサーバ33へのFetch Accountという操作処理を要求する。このDBリクエストに対応する識別番号=5のDBレスポンスの応答メッセージから分かるように、Fetch Accountの処理はDBサーバ33で10msecかかった。
【0116】
その後に、さらに識別番号=6のDBプロトコルのリクエストメッセージとしてアプリケーションサーバ32からDBサーバ33へのUpdate Accountという操作処理が要求される。その後、識別番号=6のDBプロトコルのレスポンス、識別番号=4のIIOPプロトコルのレスポンス、そして識別番号=4のHTTPプロトコルのレスポンスメッセージがDBサーバ33、アプリケーションサーバ32、Webサーバ31から送信される。
【0117】
このようなメッセージの流れからトランザクションモデル213が生成され、モデル記憶部113に格納される。また、レスポンスメッセージから、リクエストからレスポンスまでのそれぞれの応答時間が20msec、120msec、240msecであったと分かる。この応答時間も、トランザクションモデル213に設定される。
【0118】
「入金」のトランザクションモデル213では、Webサーバ31で/corba/servlet/Depositのオブジェクトが処理され、アプリケーションサーバ32でMdepositオブジェクトが処理され、DBサーバ33でFetch AccountとUpdate Accountオブジェクトが処理されている。そこで、モデル生成部140は、各サーバにおけるオブジェクトの処理時間情報を算出する。それぞれの処理時間は、DBサーバ33では10msecと20msec、アプリケーションサーバ32では90msec(=120−(10+20))、そしてWebサーバ31では120msec(=240−120)である。
【0119】
そして、モデル生成部140は、オブジェクトの処理の呼出関係及び各サーバにおけるオブジェクトの処理時間を定義したトランザクションモデル213を生成する。
なお、メッセージ解析部130から、再度「残高確認」や「入金」トランザクション処理時のメッセージがモデル生成部140に入力され、これらが多重度1である場合があり得る。この場合、それらのメッセージを無視してもよい。また、同様にモデル生成を行い、すでに生成されている同じ種類のトランザクションの各サーバの処理時間に反映(例えば、平均時間などを利用して)することもできる。
【0120】
また、分析部150で実行される既存のトランザクションモデルとメッセージのマッチング法を用いて、多重度1のモデルを基に、多重度1以上のトランザクションのメッセージ集合を抽出し、それぞれの多重度でのアプリケーション処理時間を求めてモデルを生成することもできる。
【0121】
次に、分析部150で実行される処理を詳細に説明する。分析部150は、プロトコルログ記憶部112に格納されたプロトコルログを、モデル記憶部113に格納されるトランザクションモデルと比較することで、各トランザクションを構成するメッセージを識別する。そして、分析部150は、トランザクション毎のメッセージの処理時間によって、システムの状態を分析する。具体的には、以下の処理が行われる。
【0122】
図23は、分析処理の手順を示すフローチャートである。以下、図23に示す処理をステップ番号に沿って説明する。
[ステップS51]分析部150は、プロトコルログ記憶部112から未処理のプロトコルログを読み込む。
【0123】
[ステップS52]分析部150は、未処理のプロトコルログがあるか否かを判断する。未処理のプロトコルログがある場合、処理がステップS53に進められる。未処理のプロトコルログが無い場合、処理が終了する。
【0124】
[ステップS53]分析部150は、読み込んだプロトコルログに示されるメッセージのプロトコルを判断する。プロトコルがHTTPであれば、処理がステップS54に進められる。プロトコルがIIOPであれば、処理がステップS59に進められる。プロトコルがDBであれば、処理がステップS62に進められる。
【0125】
[ステップS54]プロトコルがHTTPの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS55に進められる。レスポンスのメッセージの場合、処理がステップS57に進められる。
【0126】
[ステップS55]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(URL)に対応するトランザクションモデルをモデル記憶部113から検出する。そして、HTTPリクエストによって発生した該当トランザクションの内容を認識する。
【0127】
[ステップS56]分析部150は、処理中テーブルに新しいトランザクション及びHTTP識別番号を登録する。その後、処理がステップS51に進められる。
[ステップS57]レスポンスのメッセージの場合、分析部150は、識別番号を用いて、処理中テーブルから対応トランザクション及びHTTPを検索し、Webサーバ31における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。
【0128】
[ステップS58]分析部150は、終了トランザクション情報を出力部160に出力し、処理中テーブルから削除する。その後、処理がステップS51に進められる。
[ステップS59]プロトコルがIIOPの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS60に進められる。レスポンスのメッセージの場合、処理がステップS61に進められる。
【0129】
[ステップS60]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(メソッド)を用いて、処置中テーブルから対応トランザクションを検索し、IIOP識別番号を登録する。その後、処理がステップS51に進められる。
【0130】
[ステップS61]レスポンスのメッセージの場合、分析部150は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、アプリケーションサーバ32における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップS51に進められる。
【0131】
[ステップS62]プロトコルがDBの場合、分析部150は、メッセージの方向(リクエストかレスポンスか)を判断する。リクエストのメッセージの場合、処理がステップS63に進められる。レスポンスのメッセージの場合、処理がステップS64に進められる。
【0132】
[ステップS63]リクエストのメッセージの場合、分析部150は、メッセージのオブジェクト(コマンド+テーブル名)を用いて、処置中テーブルから対応トランザクションを検索し、DB識別番号を登録する。その後、処理がステップS51に進められる。
【0133】
[ステップS64]レスポンスのメッセージの場合、分析部150は、識別番号を用いて処理中テーブルから対応トランザクションを検索し、DBサーバ33における処理時間を計算する。算出された処理時間は、処理中テーブル内の対応トランザクションに関連付けて登録される。その後、処理がステップS51に進められる。
【0134】
このような処理を行うことで、トランザクションの種別毎に、各サーバにおける処理時間等を記録することができる。
図24は、分析部へ入力されるメッセージの例を示す図である。ユーザからの操作入力等により分析指示が出された後、メッセージ解析装置から出力されプロトコルログ記憶部112に格納されたプロトコルログ221〜242が、順次分析部150に入力される。
【0135】
分析部150ではこれらのプロトコルログ221〜242をモデル生成部140で得られた「残高確認」と「入金」のトランザクションモデル(図21、図22に示す)とマッチングする。そして、分析部150は、トランザクションモデルに合致するトランザクションを抽出する。以下、図25〜図34を参照して、図24に示すプロトコルログ221〜242の分析例を説明する。なお、図25〜図34には、プロトコルログ221〜242を先頭から順に分析することで確認できるトランザクションの状態遷移が示されている。図25〜図34では、発生が確認されたトランザクションのうち、処理が開始されたオブジェクトを実線の楕円で示し、処理が開始されていないオブジェクトを破線の楕円で示している。
【0136】
図25は、メッセージ分析例を示す第1の図である。まず、最初のプロトコルログ221で示されるメッセージは、識別番号=100のHTTPプロトコルであり、クライアント21からWebサーバ31への/corba/servlet/Balanceオブジェクト処理のリクエストメッセージである。このメッセージは第1の状態(ST1)で示すように、図21に示すトランザクションモデル203(「残高確認」トランザクション)のWebサーバ31処理への呼び出しと合致する。これは、Webサーバ31での処理開始を意味する。
【0137】
次のプロトコルログ222で示されるメッセージは、識別番号=200のIIOPプロトコルの、アプリケーションサーバ32へのMbalanceオブジェクト処理のリクエストメッセージである。このメッセージは第2の状態(ST2)で示すように、「残高確認」のトランザクションモデル203のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0138】
次のプロトコルログ223で示される識別番号=101のHTTPリクエストメッセージは、Webサーバ31への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第3の状態(ST3)で示すように、図22に示す「入金」のトランザクションモデル213のWebサーバ31処理への呼び出しと合致する。これは、Webサーバ31での処理開始を意味する。
【0139】
次のプロトコルログ224で示される識別番号=500のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第4の状態(ST4)で示すように、「残高確認」トランザクションモデル203のDBサーバ33処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0140】
図26は、メッセージ分析例を示す第2の図である。次のプロトコルログ225で示される識別番号=201のIIOPのリクエストメッセージは、アプリケーションサーバ32へのMdepositの処理要求である。このメッセージは第5の状態(ST5)で示すように、「入金」トランザクションモデル213のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0141】
次のプロトコルログ226で示される識別番号=102のHTTPリクエストメッセージは、Webサーバ31への/corba/servlet/Depositオブジェクトの処理請求である。このメッセージは第6の状態(ST6)で示すように、「入金」トランザクションモデル213のWebサーバ31処理への呼び出しと合致する。これは、新たなWebサーバ31での処理開始を意味する。
【0142】
図27は、メッセージ分析例を示す第3の図である。次のプロトコルログ227で示される識別番号=500のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第7の状態(ST7)で示すように、「残高確認」トランザクションのDBサーバ33での処理に20msec要したことを意味する。図21の「残高確認」トランザクションモデル203では、DBサーバ33でのFetch Accountコマンドの処理時間は10msecとなっている。そのため、モデルとの差は10msecである。
【0143】
次のプロトコルログ228で示される識別番号=501のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第8の状態(ST8)で示すように、「入金」トランザクションモデル213のDBサーバ33の処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0144】
図28は、メッセージ分析例を示す第4の図である。次のプロトコルログ229で示される識別番号=501のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第9の状態(ST9)で示すように、「入金」トランザクションのDBサーバ33での処理に20msec要したことを意味する。図22の「入金」トランザクションモデル213でのDBサーバ33のFetch Accountコマンドの処理時間は10msecとなっているため、モデルとの差は10msecである。
【0145】
次のプロトコルログ230で示される識別番号=502のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へUpdate Accountというコマンドの処理要求である。このメッセージは第10の状態で示すように、「入金」トランザクションモデル213のDBサーバ33の処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0146】
図29は、メッセージ分析例を示す第5の図である。次のプロトコルログ231で示される識別番号=202のIIOPのリクエストメッセージは、アプリケーションサーバ32へのMdepositの処理要求である。このメッセージは第11の状態(ST11)で示すように、「入金」トランザクションモデル213のアプリケーションサーバ32処理への呼び出しと合致する。これは、アプリケーションサーバ32での処理開始を意味する。
【0147】
次のプロトコルログ232で示される識別番号=200のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第12の状態(ST12)で示すように、「残高確認」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、IIOPリクエストからレスポンスまでの応答時間は100msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での処理(20msec)を除いた80msecになる。この値は、図21の「残高確認」トランザクションモデル203でのアプリケーションサーバ32の処理時間と同じである。
【0148】
図30は、メッセージ分析例を示す第6の図である。次のプロトコルログ233で示される識別番号=502のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第13の状態(ST13)で示すように、「入金」トランザクションのDBサーバ33での処理が50msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのUpdate Accountコマンドの処理時間は20msecとなっているため、モデルとの差は30msecである。
【0149】
次のプロトコルログ234で示される識別番号=503のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へFetch Accountというコマンドの処理要求である。このメッセージは第14の状態(ST14)で示すように、「入金」トランザクションモデル213のDBサーバ33での処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0150】
図31は、メッセージ分析例を示す第7の図である。次のプロトコルログ235で示される識別番号=100のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第15の状態(ST15)で示すように、「残高確認」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は190msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答処理(100msec)を除いた90msecになる。図21の「残高確認」トランザクションモデル203では、Webサーバ31での処理時間は100msecとなっているため、モデルより10msec早く終了していることになる。この時点で、1つの「残高確認」トランザクションのすべての処理が終了し、出力部160に出力される。
【0151】
次のプロトコルログ236で示される識別番号=503のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第16の状態(ST16)で示すように、「入金」トランザクションのDBサーバ33での処理が20msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのFetch Accountコマンドの処理時間は10msecとなっているため、モデルとの差は10msecである。
【0152】
図32は、メッセージ分析例を示す第8の図である。次のプロトコルログ237で示される識別番号=504のDBプロトコルのリクエストメッセージは、アプリケーションサーバ32からDBサーバ33へUpdate Accountというコマンドの処理要求である。このメッセージは第17の状態(ST17)で示すように、「入金」トランザクションモデル213のDBサーバ33処理への呼び出しと合致する。これは、DBサーバ33での処理開始を意味する。
【0153】
次のプロトコルログ238で示される識別番号=201のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第18の状態(ST18)で示すように、「入金」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は180msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での2つのコマンドの処理時間(70msec=20msec+50msec)を除いた110msecになる。図22の「入金」トランザクションモデル213では、アプリケーションサーバ32での処理時間は90msecとなっているため、モデルとの差は20msecである。
【0154】
図33は、メッセージ分析例を示す第9の図である。次のプロトコルログ239で示される識別番号=101のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第19の状態(ST19)で示すように、「入金」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は310msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答時間(180msec)を除いた130msecになる。図22の「入金」トランザクションモデル213では、Webサーバ31での処理時間は120msecとなっているため、モデルとの差は10msecである。この時点で、1つの「入金」トランザクションのすべての処理が終了し、出力部160に出力される。
【0155】
次のプロトコルログ240で示される識別番号=504のDBプロトコルのレスポンスメッセージは、DBサーバ33からアプリケーションサーバ32への応答メッセージである。このメッセージは第20の状態(ST20)で示すように、「入金」トランザクションのDBサーバ33処理が230msecかかって終了したことを意味する。図22の「入金」トランザクションモデル213では、DBサーバ33でのUpdate Accountコマンドの処理時間は20msecとなっているため、モデルとの差は210msecであり、大きく増加していることで、DBサーバ33でなんらかの問題が起きていることが分かる。
【0156】
図34は、メッセージ分析例を示す第10の図である。次のプロトコルログ241で示される識別番号=202のIIOPプロトコルのレスポンスは、アプリケーションサーバ32からWebサーバ31への応答メッセージである。このメッセージは第21の状態(ST21)で示すように、「入金」トランザクションのアプリケーションサーバ32での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は350msecであるが、アプリケーションサーバ32での実際の処理時間を考える場合、その間のDBサーバ33での2つのコマンドの処理時間(250msec=20msec+230msec)を除いた100msecになる。図22の「入金」トランザクションモデル213では、アプリケーションサーバ32での処理時間は90msecとなっている。そのため、モデルとの差は10msecである。
【0157】
ここで注意したいのは、アプリケーションサーバ32での応答時間が350msecであるにもかかわらず、実際のアプリケーションサーバ32での処理時間はわずか100msecに過ぎず、モデルとほぼ一致していることで、アプリケーションサーバ32自身には性能問題がないということが分かる。
【0158】
次のプロトコルログ242で示される識別番号=102のHTTPプロトコルのレスポンスメッセージは、Webサーバ31からクライアントへの応答メッセージである。このメッセージは第22の状態(ST22)で示すように、「入金」トランザクションのWebサーバ31での処理終了を意味する。レスポンスメッセージにあるように、リクエストからレスポンスまでの応答時間は470msecであるが、Webサーバ31での実際の処理時間を考える場合、その間のアプリケーションサーバ32の応答時間(350msec)を除いた120msecになる。この時点で、最後の「入金」トランザクションのすべての処理が終了し、出力部160に出力される。
【0159】
図22の「入金」トランザクションモデル213では、Webサーバ31での処理時間は120msecとなっているため、モデルと一致する。アプリケーションサーバ32と同様に、Webサーバ31での応答時間が470msecであるにもかかわらず、実際のWebサーバ31での処理時間はモデルと一致していることで、Webサーバ31自身には性能問題がないということが分かる。以上のような分析結果は、分析結果記憶部114に格納される。
【0160】
次に、出力部160で行われる処理を詳細に説明する。
出力部160は、分析部150から分析結果記憶部114に格納されたトランザクションの情報をさまざまな形でモニタ11に出力する。以下、出力部160によるトランザクション情報の出力例を示す。
【0161】
図35は、サーバの平均処理時間の表示例を示す図である。図35で示すように、出力部160は、サーバごとの平均処理時間を求めて、モニタ11に平均処理時間を示す画面301を表示する。なお、各サーバの処理時間を示すグラフには、トランザクションモデルにおける処理時間を示す線が表示されている。なお、出力部160は、モデルとの処理時間との差が非常に大きい場合には、それらの処理をリストアップして、モニタ11に表示することもできる。
【0162】
図36は、トランザクション別処理時間及び内訳の表示例を示す図である。この画面302では、ある期間のトランザクションがすべて集計され、サーバごとの処理時間が表示されている。
【0163】
図37は、処理時間ヒストグラムの表示例を示す図である。この画面303では、トランザクション処理時間、及び各サーバでの処理時間に関するヒストグラム(処理時間毎の発生頻度)が表示されている。
【0164】
また、ヒストグラム等の各種情報を画面に同時に表示することで、処理遅延原因の解析を容易にすることができる。
図38は、複数の情報を同時に表示した場合の画面例を示す図である。この画面310には、トランザクション処理時間のヒストグラム表示部311、トランザクションの多重度表示部312、トランザクションの時間推移表示部313(Webサーバ31、アプリケーションサーバ32、DBサーバ33での内訳)とトランザクションメッセージのシーケンス表示部314が表示されている。出力部160は、各表示対象要素の表示内容を、互いに連携させて表示する。
【0165】
図39は、表示対象要素間の連携の様子を示す図である。図39に示すように、ヒストグラム表示部311には、処理遅延判別用の閾値を示すバー311aが表示されている。このバー311aは、ユーザからの操作入力に応じて左右に移動させることができる。バー311aが表示されている位置の処理時間の値が閾値となる。閾値以上に処理時間を要したトランザクションが、注目処理と判断される。
【0166】
図39の例では、300msecの位置にバー311aが表示されている。したがって、300msec以上要したトランザクションが、注目処理となる。
多重度表示部312では、ヒストグラム表示部311上で注目処理と分類されたトランザクションの処理時間帯が、強調表示される。また、多重度表示部312の横には、スクロールバー312aが設けられている。スクロールバー312aで示された時間帯のトランザクションの詳細が、時間推移表示部313に表示される。
【0167】
時間推移表示部313には、プロトコル間のメッセージの受け渡しが、サーバ間のシーケンスで示される。時間推移表示部313の横には、スクロールバー313aが設けられている。スクロールバー313aで示された時間帯のメッセージの内容が、シーケンス表示部314に表示される。シーケンス表示部314では、注目処理に関するメッセージが強調表示される。
【0168】
このように、ユーザがヒストグラム表示部311から所定の時間以上かかるトランザクションを選択すれば、そのようなトランザクションがどこで起きるかをトランザクションの多重度表示部312、トランザクションの時間推移表示部313、そしてメッセージのシーケンス表示部314で確認できる。
【0169】
以上説明したように、第1の実施の形態では、トランザクションモデルを生成し、スイッチ10を介して送受信されたメッセージからトランザクションモデルに沿って進行するメッセージの受け渡しを検出するようにした。これにより、任意のトランザクションを構成するメッセージの集合を特定し、そのトランザクションの解析が可能となる。
【0170】
すなわち、システム分析装置100において、ネットワークからキャプチャしたTCPパケットのデータ部を解析することで、サーバで実行されるアプリケーション間での通信を再構成する。そして、システム分析装置100は、再構成されたプロトコルログから、処理間の呼出関係が確実に存在するメッセージ集合を選択し、ユーザのリクエストに対する一連の処理の結びつきであるトランザクションが抽出できる。そして、ユーザのリクエストからレスポンスまでの各アプリケーションの処理を追跡することにより、性能問題やボトルネックを迅速に把握することが可能となる。
【0171】
しかも、第1の実施の形態は、外部観測によってトランザクションを抽出している。そのため、既存システムへの機能追加を行う必要がなく、サーバ内のアプリケーションへの改変等を行わずに済む。
【0172】
[第2の実施の形態]
第2の実施の形態は、処理時間帯が他のトランザクションと重なるようなトランザクションであっても、そのトランザクションを構成するメッセージを抽出し、トランザクションモデルを生成できるようにしたものである。
【0173】
すなわち、第1の実施の形態では、各処理が他の処理(リクエストからレスポンスまで)とオーバラップすることない(すなわち多重度1である)部分のみを抜き出して、トランザクションモデルを獲得していた。この処理は、例えば対象システムの運用を一時停止し、モデル獲得のためにのみ動作させることが可能な場合には有効である。
【0174】
ところが、24時間サービスを行っているため運用停止ができず、かつほとんどの場合に複数の処理を同時並行的に処理しているシステムの場合、第1の実施の形態を適用するのは困難となる。また、処理の多重度が低くシステムへの負荷が軽い場合と、多重度が高く負荷も重い場合とで挙動が異なる場合には、多重度1の場合からだけトランザクションモデルを生成したのでは不十分である。そのため、対象システムによっては多重度が高い部分も利用してトランザクションモデルを生成することも必要になる。以下でその動作例を示す。
【0175】
なお、第2の実施の形態におけるシステム分析装置の機能ブロックは、図4に示した第1の実施の形態と同様である。そこで、図4に示した各要素を用いて、第2の実施の形態の処理を説明する。また、第1の実施の形態と第2の形態とは、モデル生成部140の処理のみが相違し、他の要素の処理は同じである。さらに、説明を簡単にするため、アプリケーションサーバ32とDBサーバ33とで完結するトランザクションの例を用いて、第2の実施の形態を説明する。すなわち、IIOPのメッセージとDBのメッセージとの関係から、トランザクションモデルとして生成する。
【0176】
図40は、分析部へ入力されるメッセージの例を示す図である。プロトコルログ記憶部112に格納されたプロトコルログ401〜420が、モデル生成部140に入力される。
【0177】
モデル生成部140は、所定の制約条件に従って、プロトコルログに示されるメッセージを解析する。
図41は、モデル生成部に入力されたメッセージから認識される処理を示す図である。すなわち、モデル生成部140は、図40のプロトコルログ401〜420で示されるメッセージから各処理の開始と終了を抽出し、その処理期間を時系列に並べる。その結果が、図41に示されている。
【0178】
処理P1は、プロトコルログ401,410で示される識別番号=1のIIOPのメッセージから認識される処理である。処理P2は、プロトコルログ403,413で示される識別番号=2のIIOPのメッセージから認識される処理である。処理P3は、プロトコルログ407,419で示される識別番号=3のIIOPのメッセージから認識される処理である。処理P4は、プロトコルログ411,420で示される識別番号=4のIIOPのメッセージから認識される処理である。
【0179】
処理P5は、プロトコルログ402,405で示される識別番号=1のDBのメッセージから認識される処理である。処理P6は、プロトコルログ404,406で示される識別番号=2のDBのメッセージから認識される処理である。処理P7は、プロトコルログ409,412で示される識別番号=4のDBのメッセージから認識される処理である。処理P8は、プロトコルログ408,414で示される識別番号=3のDBのメッセージから認識される処理である。処理P9は、プロトコルログ415,417で示される識別番号=5のDBのメッセージから認識される処理である。処理P10は、プロトコルログ416,418で示される識別番号=6のDBのメッセージから認識される処理である。
【0180】
なお、この例ではIIOPで2種類、DBで2種類の処理が現れるが、以下では記述を簡単にするために以下のように略すこととする。
IIOPによるMbalance:種別A
IIOPによるMdeposit:種別B
DBによるFetch->Account:種別a
DBによるUpdate->Account:種別b
また、モデル中の各処理種別毎の処理時間の求め方は第1の実施の形態と同じなので、ここではモデル中の処理種別間の呼出関係のみに着目し、処理時間に関する説明は省くものとする。
【0181】
第2の実施の形態における制約条件は、以下の通りである。
第1の制約:ある処理から呼び出された処理の開始時刻は、呼び出し元の処理開始時刻以降で、且つ終了時刻は呼び出し元の処理終了時刻以前である。
【0182】
第2の制約:IIOPの処理は、直接システム外部(例えば、クライアント21)から呼び出される。
第3の制約:DBの処理は、必ずIIOPから呼び出される。
【0183】
第1の制約は、呼出関係に関する基本的な制約で処理Xが処理Yを呼び出した場合には、YはXより後に開始されXより前に終了しなければならないことを要求している。なお、場合によってはXの開始(終了)とYの開始(終了)時刻の差の上限値や下限値を与える場合もある。多くのシステムではこのような制約が成立しており、これを利用することで呼出関係の候補を減らすことができる。
【0184】
第2の制約は、階層的な構成のシステムでは一般的な制約で、上位(利用者側の)の処理が下位の処理を呼び出すが、逆はないことを表す。この場合には、監視対象のシステムの外部からIIOPの処理が呼び出され、そこからDBの処理が呼び出されることを表している。これ以外の呼び出し、例えばIIOPの処理が他のIIOPの処理を呼び出したり、DBの処理がIIOPの処理を呼び出したりすることはない。
【0185】
このほかにも、例えばあるIIOPの処理はDBの処理を最低1回呼び出す、というような処理種別やそのグループ間の呼出回数やその順序に関する制約等、監視をする側が持つシステムに関する知識を制約として入力する。
【0186】
図42は、制約を満たす処理間の呼出関係を示す図である。第1〜第3の制約を使うと、ある処理から呼び出し可能な他の処理が限定される。すなわち、どのIIOP処理からどのDB処理が呼び出され得るかが示されている(これ以外の呼び出しは制約を満足しない)。
【0187】
例えばDBによる処理P5を呼び出し得るのは、第1の制約から処理期間が処理P5のそれを含む処理でなければならず、この例ではIIOPによる処理P1のみである。一方処理P7の呼び出し元については、第1の制約を満足する処理は、処理P2,P3,P8の3個ある。このうち処理P8はDBの処理であり、第2の制約および第3の制約から同じDBの処理である処理P7を呼び出すことはありえないことが分かる。よって、処理P8を呼び出している候補は処理P2と処理P3の2つになる。
【0188】
次に、これらの呼出関係の候補から、処理種別毎に、他の種別の呼出回数を計算する。以下では処理種別iから処理種別jの呼出回数をM(i,j)と記述し、Mを呼出回数行列と呼ぶ。
【0189】
まず初めに、モデル生成部140は、呼出回数行列を初期化する。初期化は、呼出関係の制約を満足する要素を1、それ以外を0とする。
図43は、呼出回数行列の例を示す図である。この例では、4種類の処理があるため、呼出回数行列は16の要素をもつが、IIOPからDBへの呼び出しだけが制約で許されるので1、それ以外の12個は0となる。これは、制約上許される呼び出しは、他の情報がない限り、同じだけの頻度(確率)で起こるとみなすことを意味する。
【0190】
次に呼出回数行列を使って、図42中の呼び出し候補の確率を計算する。例えば、処理P5の呼び出し元の可能性は処理P1しかないので、処理P1から処理P5への呼び出しの確率は1である。
【0191】
一方処理P6(種別a)への呼び出しは、処理P1(種別A)からの呼び出しと処理P2(種別B)からの呼び出しの2つの可能性が考えられる。そのような場合には、呼び出し元(の候補)の処理種別から呼び出し先(この場合は処理P6)の種別への呼出回数行列要素の値に比例した確率を割り当てる。この場合は、処理P1が属する種別Aの処理からの、処理P6が属する種別aの処理への回数は1回(図43参照)、処理P2が属する種別Bからの呼出回数も1回であるので、それぞれの呼び出し候補の確率は共に1/2となる。
【0192】
以下、モデル生成部140は、同様に各呼び出し候補の確率を求める。
図44は、呼び出し候補の確率を求めた結果を示す図である。図43に示す呼出回数行列では、制約を満足する呼出関係を示す各要素の値は、全て1である。そのため、複数の呼び出し可能性を持つ場合、それぞれの呼び出し可能性は等しくなる(確率が1/2)。
【0193】
次に、モデル生成部140は、上記の確率を使って、呼出回数行列の値を更新する。すなわち、処理種別XからYへの呼出回数は、図43中の呼び出し候補のなかで、XからYへの呼び出し候補の確率の和を、処理種別Xの発生回数で割ったものとして計算できる。
【0194】
例えば種別Aから種別aへの呼び出し候補は、処理P1から処理P5、処理P1から処理P6、処理P4から処理P10の3個あり、その確率はそれぞれ、1、1/2、1/2である。このことと、種別Aの処理が、処理P1および処理P4の2個であることから、呼出回数行列の要素M(A,a)の値は、
(1+1/2+1/2)/2=1
となる。同様に、モデル生成部140は、他の行列要素も計算する。
【0195】
図45は、更新後の呼出回数行列を示す図である。ただし呼び出し行列のうち、制約上ゆるされない要素の値は常に0であるので、制約上許される要素、すなわちIIOPの処理種別からDBの処理種別への呼び出しに対応する要素のみを示す。
【0196】
以上の、呼出回数行列を使った呼び出し候補の確率計算と、それに基づく呼出回数行列の更新を、所定の終了条件を満足するまで繰り返す。所定の終了条件とは、例えば、更新回数が予め設定された回数に達することである。また、別の終了条件としては、更新前後の行列要素の変化量が、予め設定された上限値以下となることである。
【0197】
本実施の形態では、終了条件が、更新回数2回であるものとする。すなわち、モデル生成部140は、図44に示した状態からもう一度呼出回数のカウントと行列要素の計算を行う。2回目以降の処理においても、各呼び出し候補の確率計算の方法は1回目の処理と同じである。ただし、確率計算のもとになる呼出回数行列は図45で示す内容であり、上で求めた図43とは異なるので、計算される確率も異なる。
【0198】
例えば、処理P9(種別b)に対する呼び出し候補は、処理P3(種別B)からの呼び出しと処理P4(種別A)からの2つがある。図45に示す呼出回数行列では、種別Bから種別bへの呼出回数は3/4回、種別Aから種別bへの呼び出しは1/4回である。これに比例するように確率を割り振ると、処理P3から処理P9への呼び出しの確率は3/4、処理P4から処理P9への呼び出しの確率は1/4となる(処理P9は処理P3か処理P4のいずれか一方から呼び出されるので、2つの確率の和は1になることに注意)。
【0199】
以下、モデル生成部140は、同様に各呼び出し候補の確率を求める。
図46は、2回目の処理で呼び出し候補の確率を求めた結果を示す図である。このように、複数の呼び出し可能性を持つ場合には、呼出回数の予測値を重みとして確率が計算される。このような呼び出し候補の確率に基づいて、呼出回数行列が更新される。
【0200】
図47は、2回目の更新後の呼出回数行列を示す図である。呼出回数の計算方法は、1回目と同じである。これで呼出回数行列の更新は2回行われたので、確率計算/更新処理が終了して次のステップに進む。
【0201】
次に、呼出回数行列の要素のなかで整数以外の部分を四捨五入などにより整数にまるめる。図47では種別Aから種別bへの呼出回数が1/8回なのでこれを0とし、種別Bから種別bへの呼出回数は7/8なので、これを1回とする。これら以外は値が整数なので変更されない。
【0202】
図48は、最終的に得られた呼出回数行列及び生成されるトランザクションモデルを示す図である。モデル生成部140は、図48に示すように整数化された呼出回数行列から、処理種別間の呼出関係を表すトランザクションモデルを獲得する。すなわち、呼出回数行列から、IIOP処理種別Aは、DBの処理種別aを1回呼び出し、IIOPの種別BはDBの処理種別aと処理種別bとをそれぞれ1回ずつ呼び出すことが分かる。
【0203】
すなわち、呼出回数行列で1と設定されている呼出関係が、生起確率の高い関係である。そこで、モデル生成部140は、呼出回数行列で1が設定されている呼出関係から認識されるトランザクションモデル431,432を生成し、モデル記憶部113に格納する。
【0204】
以上の処理手順を整理すると以下のようになる。
図49は、第2の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図49に示す処理をステップ番号に沿って説明する。
【0205】
[ステップS71]モデル生成部140は、プロトコルログから各処理の開始と終了のペアを抽出する。
[ステップS72]モデル生成部140は、呼出回数行列を初期化する。この際、制約を満足しない呼出関係は、0に初期化される。
【0206】
[ステップS73]モデル生成部140は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
[ステップS74]モデル生成部140は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップS77に進められる。終了条件を満足していない場合、処理がステップS75に進められる。
【0207】
[ステップS75]モデル生成部140は、呼出関係候補それぞれの生起確率を、呼出回数行列の値に比例するように計算する。
[ステップS76]モデル生成部140は、各呼出関係候補の確率を呼び出し元と呼び出し先との処理種別毎に平均をとり、呼出回数行列を更新する。その後、処理がステップS74に進められる。
【0208】
[ステップS77]終了条件を満足した場合、モデル生成部140は、呼出回数行列を整数で近似する。
[ステップS78]モデル生成部140は、呼出回数行列のゼロ以外の成分を処理種別毎の呼出回数とするトランザクションモデルを出力する。
【0209】
以上のように、第2の実施の形態では、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合して、処理間の呼出関係の可能性を算出するようにした。これにより、複数のトランザクションが同時に処理されている場合であっても、モデルを生成することができる。しかも、比較的少ない計算量でモデルを生成できる。
【0210】
[第3の実施の形態]
上記第2の実施の形態に示す方法では、処理種別間の呼出回数の平均を使っている。そのため、例えば確率1/2で2回呼び出している状況と確率1で1回呼び出している状況を区別できず、結果として正しいトランザクションモデルを学習できない場合もあり得る。このような状況は、例えば、ある処理種別からの呼出パターンが複数ある場合に発生し得る。これを解決するためには、呼出関係の候補として個々の処理種別間の関係を求めるのではなく、ある処理種別が呼び出す全ての処理の集合や集合内の順序を対象に確率を求めればよい。以下では、この考え方に基づくモデル生成方法を第3の実施の形態として説明する。
【0211】
なお、第3の実施の形態におけるシステム分析装置の機能ブロックは、図4に示した第1の実施の形態と同様である。そこで、図4に示した各要素を用いて、第3の実施の形態の処理を説明する。また、第1の実施の形態と第3の形態とは、モデル生成部140の処理のみが相違し、他の要素の処理は同じである。
【0212】
モデル生成部140の入力は、同じく図40のメッセージ列および制約であるとする。
モデル生成部140は、まず初めに、第2の実施の形態と同様に各処理間で可能な呼出関係を求める。結果は図42に示す通りである。
【0213】
次に、図42に示した可能な呼出関係を元に、各処理が呼び出している処理の集合とそのなかでの順序の候補を求める。例えば、処理P1が呼び出している処理の順序付きの集合の候補(以下処理集合候補と呼ぶ)は次のように求める。
【0214】
図42に示す呼出関係を解析すると、集合Uに含まれる(すなわち処理P1から呼び出されている)可能性があるのは、処理P5と処理P6の2つの処理である。このうち処理P5は、他に呼び出し元の候補はないので、かならず集合U含まれる。一方処理P6は、処理P2から呼び出されている可能性があるので、集合Uに含まれる可能性と含まれない可能性の両方が考えられる。処理P5と処理P6では処理P5のほうが早く開始しているので、集合Uの候補は次の2つである。
U11:{処理P5}
U12:{処理P5,処理P6}
なお、集合及び処理集合候補の記述では、呼び出されるのが早い処理から順に左から記述するものとする。この段階では、この2つの候補のどちらが信頼できるかに関する判断材料が全くないため、信頼度は両者同じ、すなわち、1/2とする。
【0215】
次に、処理集合候補U11,U12を処理種別による記述に変換し、処理P1から呼び出される処理のパターン、すなわち呼び出される処理種別の順序付き集合の候補を生成する。処理P5および処理P6の処理種別はどちらもaであるので、以下のようになる。
U11:パターン{a}
U12:パターン{a,a}
後者の処理集合候補U12は、処理P1が同じ処理種別の処理を2回連続して呼び出している可能性を表している。
【0216】
次に、パターンの信頼度を、そのパターンの元になった処理集合の信頼度から計算する。この場合は処理集合候補U11、処理集合候補U12から異なるパターンが生成されているので、各パターンの信頼度は処理集合候補U11および処理集合候補U12の信頼度をそのまま用いる。すなわち1/2とする。
【0217】
以上から、処理P1が呼び出しているパターンの候補とその信頼度は次のようになる。
パターン{a}:信頼度1/2
パターン{a,a}:信頼度1/2
2番目のパターンは種別aの処理が2回呼び出されるパターンを示している。モデル生成部140は、他の処理についても、その処理が呼び出している処理種別のパターンの候補と信頼度を同様にして求める。
【0218】
処理P2から呼び出される可能性があるのは処理P6と処理P7の2つであり、この両者とも他の処理から呼び出されている可能性があるので、処理P2から呼び出されている処理集合候補は次の4通りである。処理P1の場合と同様、この段階ではこれら全ての信頼度が同じ、すなわち1/4であるとする。
U21:{}
U22:{処理P6}
U23:{処理P7}
U24:{処理P6,処理P7}
処理P6および7の種別はそれぞれaとbであるから、処理P2が呼び出している処理種別のパターンの候補とその信頼度は次のようになる。
パターン{}:信頼度1/4
パターン{a}:信頼度1/4
パターン{b}:信頼度1/4
パターン{a,b}:信頼度1/4
最後のパターンは、aとbがこの順序で、すなわち最初に種別aの処理が呼び出され、その後にbの処理が呼び出されるパターンを表している。なお、順序を考慮せず、呼び出される処理種別毎の回数をパターンとすることもできる。
【0219】
処理P3に関しては注意が必要である。処理P3からかならず呼び出されているのは処理P8、処理P3から呼び出されている可能性はあるが、他の処理から呼び出されている可能性もある処理が、処理P7、処理P9、処理P10の3個であるから、処理P3が呼び出している処理集合候補は、
{処理P8}
{処理P8,処理P7}
{処理P8,処理P9}
{処理P8,処理P10}
{処理P8,処理P7,処理P9}
{処理P8,処理P7,処理P10}
{処理P8,処理P9,処理P10}
{処理P8,処理P7,処理P9,処理P10}
の8個で、それぞれの信頼度は1/8となる。ここからパターンとその信頼度が計算される。
【0220】
ところが、処理P7と処理P9が共に種別bの処理であることから、{処理P8,処理P7}と{処理P8,処理P9}からは同一のパターン{a,b}が生成される。同様に{処理P8,処理P7,処理P10}と{処理P8,処理P9,処理P10}からはパターン{a,b,a}が生成される。このような場合には、これらのパターンの信頼度は、対応する処理集合候補の信頼度の和をとることで計算する。よって結果は次のようになる。
パターン{a}:信頼度1/8
パターン{a,b}:信頼度1/4
パターン{a,a}:信頼度1/8
パターン{a,b,b}:信頼度1/8
パターン{a,b,a}:信頼度1/4
パターン{a,b,b,a}:信頼度1/8
処理P4についてもパターンとその信頼度を求めると次のようになる。
パターン{}:信頼度1/4
パターン{b}:信頼度1/4
パターン{a}:信頼度1/4
パターン{b,a}:信頼度1/4
次に、上で求めた各処理から呼び出される処理種別のパターンとその信頼度を、呼び出し元の処理種別毎に平均をとることで、処理種別毎に、それから呼び出されるパターンとその確率を計算する。
【0221】
まず、処理種別Aに属するのは処理P1と処理P4であるから、これらの処理から呼び出されているパターン候補の信頼度の平均を計算する。例えばパターン{a}は、処理P1では信頼度1/2、処理P4では信頼度1/4であるので、処理種別Aからこのパターンが呼び出される確率は、その平均、すなわち3/8となる。一方パターン{a,a}は、処理P1では信頼度1/2であるが、処理P4ではパターン候補中に存在しない、すなわち信頼度0であるので、確率は1/4になる。
【0222】
図50は、処理種別Aからの呼出パターンとその確率を示す第1の図である。図50に示すように、パターンA1{}の確率は、(0+1/4)/2=1/8である。パターンA2{b}の確率は(0+1/4)/2=1/8である。パターンA3{a}の確率は、(1/2+1/4)/2=3/8である。パターンA4{a,a}の確率は、(1/2+0)/2=1/4である。パターンA5{b,a}の確率は(0+1/4)/2=1/8である。
【0223】
同様に処理種別Bに属する処理、すなわち処理P2および処理P3の平均をとると、処理種別Bから呼び出されるパターンとその確率を以下のように計算される。
図51は、処理種別Bからの呼出パターンとその確率を示す第1の図である。図51に示すように、パターンB1{}の確率は、(1/4+0)/2=1/8である。パターンB2{a}の確率は、(1/4+1/8)/2=3/16である。パターンB3{b}の確率は、(1/4+0)/2=1/8である。パターンB4{a,b}の確率は、(1/4+1/4)/2=1/4である。パターンB5{a,a}の確率は、(0+1/8)/2=1/16である。パターンB6{a,b,b}の確率は、(0+1/8)/2=1/16である。パターンB7{a,b,a}の確率は、(0+1/4)/2=1/8である。パターンB8{a,b,b,a}の確率は、(0+1/8)/2=1/16である。
【0224】
次にこれの処理種別毎の呼び出されるパターンとその確率を使って、もう一度各処理から呼び出される処理の集合の候補(処理集合候補)とその信頼度を計算しなおす。
まず、処理P1について考える。
処理P1で可能な呼び出し処理集合候補が
U11:{処理P5}
U12:{処理P5,処理P6}
であるのは同じである。ただし前回はどちらがよりもっともらしいかを判断する材料がなかったため信頼度を同じにしたが、今回は判断材料として図50および図51に示した処理種別毎の呼出パターンの信頼度を使うことができる。
【0225】
ただし、処理集合候補U11と処理集合候補U12の信頼度は、処理P1からの呼出パターンの確率だけではなく、このどちらかを選択するかによって呼び出し候補が影響される他の処理も考慮する必要がある。
【0226】
処理集合候補U11と処理集合候補U12の差は処理P6が処理P1からよびだされているかどうかである。処理P6は処理P1または処理P2から呼び出されているから、例えば処理集合候補U11を選択するということは、単に処理P1から処理P6が呼び出されないことだけの選択ではなく、処理P2から処理P6が呼び出されている、という選択でもある。よって処理集合候補U11の信頼度を計算する際には、それによって処理P2からの呼び出しの選択がどれだけ制限されるかを考慮する必要がある。
【0227】
処理集合候補U11となる場合、処理P1(種別A)からの呼出パターンはA3であり、このパターンの確率は3/8である。一方、処理集合候補U12の場合はパターンA4であるから確率は1/4である。ただし処理集合候補U11および処理集合候補U12の信頼度はこれらの確率をそのまま使うのではなく、それによって他の処理からの呼出パターンがどのように制限されるかを考慮する。
【0228】
すなわち、例えば処理P1からの呼び出しが処理集合候補U11の場合、処理P6は処理P1から呼ばれないことになる。そのため、他の候補、すなわち処理P2からかならず呼ばれることになる。よって処理P2から呼び出される処理の集合は{処理P6}または{処理P6,処理P7}でなければならない。
【0229】
処理P6および処理P7の種別はaおよびbであるから、処理種別のパターンでいうとB2またはB4であり、確率はそれぞれ3/16および1/4である。よって処理集合候補U11の信頼度は、処理P2側の確率はこれらの確率の和、すなわち7/16と見積もることができる。これを使って、処理集合候補U11の信頼度は、処理P1側で処理集合候補U11が呼び出される確率3/8と処理P2側の制限からくる確率7/16の積、すなわち21/128とする。
【0230】
一方、処理集合候補U12の場合には、処理P6は処理P1から呼び出されているので、処理P2側の呼び出される処理の集合の候補は{}または{処理P7}のいずれか、処理種別のパターンではB1またはB3である。これらの確率は共に1/8であるので、処理集合候補U12の信頼度は1/4×(1/8+1/8)=1/16=8/128となる。
【0231】
処理集合候補U11および処理集合候補U12のいずれかはかならず正しいので、両者の信頼度の和が1になるように正規化を行い、最終的に処理集合候補U11および処理集合候補U12の信頼度を
U11:{処理P5}信頼度21/29
U12:{処理P5,処理P6} 信頼度8/29
とする。すなわち処理集合候補U11のほうがもっともらしいと判断される。
【0232】
次にこれを上と同様に処理種別のパターンとその信頼度に変換する。
パターン{a}:信頼度21/29
パターン{a,a}:信頼度8/29
処理P2、処理P3、処理P4についても処理P1の場合と全く同様にして可能な呼び出し処理集合の候補の信頼度を計算し、そこから呼び出し種別のパターン毎の信頼度を計算する。以下にその結果を示す。
【0233】
処理P2については、以下の通りである。
パターン{}:信頼度4/33
パターン{a}:信頼度9/33
パターン{b}:信頼度5/33
パターン{a,b}:信頼度15/33
処理P3については、以下の通りである。
パターン{a}:信頼度18/101
パターン{a,b}:信頼度46/101
パターン{a,a}:信頼度6/101
パターン{a,b,b}:信頼度15/101
パターン{a,b,a}:信頼度11/101
パターン{a,b,b,a}:信頼度5/101
処理P4については、以下の通りである。
パターン{}:信頼度3/28
パターン{b}:信頼度3/28
パターン{a}:信頼度15/28
パターン{b,a}:信頼度7/28
次に、前と同様にこれらの呼び出し元の処理毎の呼出パターンの信頼度から、処理種別毎の呼出パターンとその確率を、呼び出し元の処理種別毎に平均をとることで求める。
【0234】
図52は、処理種別Aからの呼出パターンとその確率を示す第2の図である。図52に示すように、パターンA1:{}の確率は87/1624=0.054である。パターンA2:{b}の確率87/1624=0.054である。パターンA3:{a}の確率は1023/1624=0.630である。パターンA4:{a,a}の確率は224/1624=0.138である。パターンA5:{b,a}の確率は203/1624=0.125である。
【0235】
同様に処理種別Bに属する処理、すなわち処理P2および処理P3の平均をとると、処理種別Bから呼び出されるパターンとその確率を以下のように計算される。
図53は、処理種別Bからの呼出パターンとその確率を示す第2の図である。図53に示すように、パターンB1:{}の確率は404/6666=0.061である。パターンB2:{a}の確率は1503/6666=0.225である。パターンB3:{b}の確率は505/6666=0.076である。パターンB4:{a,b}の確率は3033/6666=0.455である。パターンB5:{a,a}の確率は198/6666=0.030である。パターンB6:{a,b,b}の確率は495/6666=0.074である。パターンB7:{a,b,a}の確率は363/6666=0.054である。パターンB8:{a,b,b,a}の確率は165/6666=0.025である。
【0236】
この処理毎の呼び出す処理の集合とその信頼度の計算およびそれから処理種別毎の呼出パターンやその確率の計算を適当な終了条件が満足するまで行う。終了条件は、第2の実施の形態と同様、繰り返し回数や、パターン毎の確率の変化量の上限等で行う。
【0237】
図52、図53に示した状態で終了条件が満足されると、モデル生成部140は、図52および図53の呼出パターンとその確率から、モデルを生成する。このとき、あまり確率の小さいモデルは信頼性にかける。そのため、呼び出し元の処理種別毎に、可能なパターンの中から確率の高い順に、選択数の上限および確率の下限を使ってモデルとして採用するパターンを選択する。
【0238】
例えば選択数の上限を2、確率の下限を0.1とすると、呼出元の処理種別Aに対してはパターンA3とパターンA4が、処理種別Bに対してはパターンB4とB2がモデルとして選択される。最終的なモデルは、選択されたパターンのみを使って確率の和が1となるように正規化しなおして生成される。
【0239】
図54は、モデル生成結果を示す図である。IIOPの種別Aに対しては、2つのトランザクションモデル441,442が生成されている。トランザクションモデル441の確率は、0.82(=0.630/(0.630+0.138))であり、トランザクションモデル442の確率は、0.18(=0.138/(0.630+0.138))である。
【0240】
IIOPの種別Bに対しては、2つのトランザクションモデル443,444が生成されている。トランザクションモデル443の確率は、0.80(=0.574/(0.574+0.142))であり、トランザクションモデル444の確率は、0.20(=0.142/(0.574+0.142))である。
【0241】
以上の処理手順を整理すると以下のようになる。
図55は、第3の実施の形態におけるトランザクションモデル生成手順を示すフローチャートである。以下、図55に示す処理をステップ番号に沿って説明する。
【0242】
[ステップS81]モデル生成部140は、プロトコルログから各処理の開始と終了のペアを抽出する。
[ステップS82]モデル生成部140は、処理間の呼出関係で、制約を満足するものを呼出関係の候補として抽出する。
【0243】
[ステップS83]モデル生成部140は、処理毎に、それを呼び出し元とする呼出関係の候補から、呼び出されている処理の集合(呼出先処理集合)の候補を生成する。
[ステップS84]モデル生成部140は、呼出先処理集合の生起確率を初期化する(呼出元の処理毎に均等に確率を割り当てる)。
【0244】
[ステップS85]モデル生成部140は、呼出先処理集合とその確率から、処理種別による呼出パターンとその確率を計算する。
[ステップS86]モデル生成部140は、終了条件を満足したか否かを判断する。終了条件を満足した場合、処理がステップS88に進められる。終了条件を満足していない場合、処理がステップS87に進められる。
【0245】
[ステップS87]モデル生成部140は、呼出先処理集合の候補それぞれの生起確率を、処理種別毎の呼出パターンとその確率から再計算する。その後、処理がステップS85に進められる。
【0246】
[ステップS88]終了条件を満足した場合、モデル生成部140は、処理種別毎の呼出パターンのうち、所定の条件を満たしたもの(例えば、所定の値より確率の高いもの)をトランザクションモデルとして選択する。
【0247】
[ステップS89]モデル生成部140は、呼出元の種別毎に、選択されたモデルの確率を正規化する。その後、処理が終了する。
このように第3の実施の形態では、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、発生パターン毎に生起確率を計算する。そして、生起確率が上位の発生パターンを所定の個数選択し、選択された発生パターンに基づいて、トランザクションモデルを生成するようにした。これにより、ある呼出元の処理種別について可能な処理パターンが複数ある場合でも、そのモデルを正しく生成することができる。
【0248】
なお、この方法では、多重度が高い場合、処理量が非常に増大する。そこで、以下のような方法で、処理量の軽減を図ることもできる。
第3の実施の形態では処理種別毎に呼び出すパターンとその確率を何度か更新していくことでトランザクションモデルを生成している。そして、最終的に得られたパターンから可能性の低いパターンを除去している。このとき、パターンとその確率の更新の際に、その都度可能性の低いパターンを除去することも可能である。一度除去した呼出パターンは、以後のモデル生成処理中に可能性として考慮する必要がないため、モデル生成の早期に除去することで、モデル生成に要する時間を短縮することができる。
【0249】
例えば、図50および図51が生成された段階で、すなわち最初に可能なパターンとその確率が生成された段階で、確率が閾値以下となるパターンを削除する。閾値が0.1である場合、図50に示された処理種別Aからの呼出パターンの確率は1/8以上であるので削除されない。一方図51に示された処理種別Bからの場合には、パターンB5、パターンB6、パターンB8の3パターンの確率が1/16で閾値以下となるので、消去することができる。消去されたパターンは、実際の処理からこれらのパターンで処理が呼び出されることはないことを示す。
【0250】
これにより、以後再び可能なパターンの確率を求める際に、消去されたパターンは考慮する必要がないことを意味する。例えば種別Bの処理P3からの呼び出される処理の集合は上の例でも記したように
{処理P8}
{処理P8,処理P7}
{処理P8,処理P9}
{処理P8,処理P10}
{処理P8,処理P7,処理P9}
{処理P8,処理P7,処理P10}
{処理P8,処理P9,処理P10}
{処理P8,処理P7,処理P9,処理P10}
である。処理P8と処理P10の種別がa、処理P7と処理P9の種別がbであることから、これらのうち{処理P8,処理P10}がパターンB5、{処理P8,処理P7,処理P9}がパターンB6、{処理P8,処理P7,処理P9,処理P10}がパターンB8に属する。すなわち、これらの呼び出しは起こり得ない。よって以後の処理でこれらの呼び出しの発生を考慮する必要がなくなる。起こり得ないパターンを判断対象から除外することで、以降の処理量を軽減することができる。
【0251】
[その他の応用例]
上記各実施の形態では、スイッチ10のミラーポートからメッセージを構成するパケットを収集しているが、各サーバ31,32,33において、メッセージのダンプデータを記録しておき、そのメッセージ観測部120が各サーバ31,32,33からダンプデータを収集してもよい。
【0252】
また、分析部150によって分析された内容に応じて、トランザクションモデルを更新することもできる。例えば、任意の種別のトランザクション内の各サーバでの処理時間が分析部150で求められると、種別毎の処理時間の平均を求め、対応するトランザクションモデルの処理時間とすることができる。
【0253】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、システム分析装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープなどがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM(Random Access Memory)、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録媒体には、MO(Magneto-Optical disk)などがある。
【0254】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROMなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【0255】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
【0256】
(付記1) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムにおいて、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラム。
【0257】
(付記2) 前記メッセージ観測手段は、前記ネットワーク内に設けられたスイッチのミラーポートを介して、前記メッセージの収集を行うことを特徴とする付記1記載のシステム分析プログラム。
【0258】
(付記3) 前記メッセージ観測手段は、前記サーバに保持されたメッセージのダンプデータから前記メッセージを収集することを特徴とする付記1記載のシステム分析プログラム。
【0259】
(付記4) 前記モデル生成手段は、前記制約条件として、呼出元の処理時間帯は呼出先の処理時間帯を包含するという条件が定義されていることを特徴とする付記1記載のシステム分析プログラム。
【0260】
(付記5) 前記モデル生成手段は、制約条件として、サーバ間の呼び出し方向が定義されていることを特徴とする付記1記載のシステム分析プログラム。
(付記6) 前記モデル生成手段は、同一トランザクション内の各処理種別のリクエストメッセージからレスポンスメッセージまでの時間に基づいて、各プロトコルに対応する処理の前記サーバでの所要時間を計算し、前記トランザクションモデルに設定することを特徴とする付記1記載のシステム分析プログラム。
【0261】
(付記7) 前記モデル生成手段は、クライアントから最初に呼び出されるリクエストメッセージと、当該リクエストメッセージに対応するレスポンスメッセージとから、各トランザクションの処理時間帯を判定し、他のトランザクションとの間で処理時間帯が重複しない非多重トランザクションを検出し、検出された前記非多重トランザクションの処理時間帯内に発生した前記プロトコルログに基づいて前記トランザクションモデルを生成することを特徴とする付記1記載のシステム分析プログラム。
【0262】
(付記8) 前記モデル生成手段は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理の種別毎に統合し、処理間の呼出関係の可能性を算出することを特徴とする付記1記載のシステム分析プログラム。
【0263】
(付記9) 前記モデル生成手段は、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、前記発生パターン毎に生起確率を計算し、前記生起確率が上位の前記発生パターンの所定の個数選択し、選択された前記発生パターンに基づいて、前記トランザクションモデルを生成することを特徴とする付記1記載のシステム分析プログラム。
【0264】
(付記10) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析方法において、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
ことを特徴とするシステム分析方法。
【0265】
(付記11) 複数のサーバが接続されたネットワークの運用形態を分析するためのシステム分析装置において、
前記ネットワークを介して受け渡されるメッセージを収集するメッセージ観測手段と、
収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納するメッセージ解析手段と、
モデル生成指示が入力されると、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納するモデル生成手段と、
分析指示が入力されると、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する分析手段と、
を有することを特徴とするシステム分析装置。
【0266】
(付記12) 複数のサーバが接続されたネットワークの運用形態をコンピュータで分析するためのシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体において、
前記コンピュータに、
メッセージ観測手段が、前記ネットワークを介して受け渡されるメッセージを収集し、
メッセージ解析手段が、収集した前記メッセージの内容を解析して、前記メッセージで要求されている処理種別、及びリクエストメッセージかレスポンスメッセージかを判別し、判別された情報をプロトコルログとしてプロトコルログ記憶手段に格納し、
モデル生成指示が入力されると、モデル生成手段が、前記プロトコルログ記憶手段に格納された前記プロトコルログにおける前記処理種別毎のリクエストメッセージとレスポンスメッセージとの対応関係により、処理種別に対応する各処理を識別し、処理間の呼出関係の確からしさに基づく選択基準に従って選択されたメッセージ集合に基づき、処理間の呼出関係に関する制約条件を満たすトランザクションモデルを生成し、生成した前記トランザクションモデルをトランザクションモデル記憶手段に格納し、
分析指示が入力されると、分析手段が、前記トランザクションモデル記憶手段に格納された前記トランザクションモデルで示される呼出関係に合致する前記プロトコルログを前記プロトコルログ記憶手段から抽出し、抽出された前記プロトコルログに示されるメッセージで構成されるトランザクションの処理状態を分析する、
処理を実行させることを特徴とするシステム分析プログラムを記録したコンピュータ読み取り可能な記録媒体。
【符号の説明】
【0267】
1 システム分析装置
1a メッセージ観測手段
1b メッセージ解析手段
1c プロトコルログ記憶手段
1d モデル生成手段
1e トランザクションモデル記憶手段
1f 分析手段
1g 出力手段
2 ネットワーク
3a,3b,・・・ クライアント
4a,4b,・・・ サーバ
5 メッセージ
【特許請求の範囲】
【請求項1】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、
コンピュータに、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、
前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、
を実行させるための分析プログラム。
【請求項2】
前記コンピュータに、
前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションを分析する分析手順、
を実行させるための請求項1記載の分析プログラム。
【請求項3】
前記複数のサーバは階層的に配置され、
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理されるメッセージ対の間に、階層が上位のサーバで処理され他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成し、
前記分析手順は、前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションの処理時間を分析する、
請求項2記載の分析プログラム。
【請求項4】
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子と、該メッセージで要求されている処理種別との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理される処理種別のメッセージ対の間に、階層が上位のサーバで処理される処理種別であって他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から該処理種別に対応する処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成する、
請求項1から3の何れかに記載の分析プログラム。
【請求項5】
前記モデル生成手順は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理種別毎に統合し、処理間の呼出関係の可能性を算出する、
請求項4に記載の分析プログラム。
【請求項6】
前記モデル生成手順は、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、該発生パターン毎に生起確率を計算し、該生起確率が上位の該発生パターンを所定の個数選択し、選択された該発生パターンに基づいて、前記トランザクションモデルを生成する、
請求項4または5記載の分析プログラム。
【請求項7】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、
を有する分析装置。
【請求項8】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、
コンピュータが、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、
分析方法。
【請求項1】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析プログラムにおいて、
コンピュータに、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手順、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手順、
前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手順、
を実行させるための分析プログラム。
【請求項2】
前記コンピュータに、
前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションを分析する分析手順、
を実行させるための請求項1記載の分析プログラム。
【請求項3】
前記複数のサーバは階層的に配置され、
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理されるメッセージ対の間に、階層が上位のサーバで処理され他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成し、
前記分析手順は、前記トランザクションモデルで示される呼出関係に合致する前記情報を前記記憶手段から抽出し、抽出された前記情報に示されるメッセージ対で構成されるトランザクションの処理時間を分析する、
請求項2記載の分析プログラム。
【請求項4】
前記格納手順は、収集した前記メッセージの内容を解析して、該メッセージの収集時の時刻と、リクエストメッセージとレスポンスメッセージとのメッセージ対を示す識別子と、該メッセージで要求されている処理種別との組を複数有する前記情報を、記憶手段に格納し、
前記モデル生成手順は、前記記憶手段から前記情報を読み出し、
階層が上位のサーバで処理される処理種別のメッセージ対の間に、階層が上位のサーバで処理される処理種別であって他の識別子を有するメッセージ対が存在しないことを、前記時刻から判断し、
存在しない場合、該メッセージ対の間にあるメッセージ対も一つのトランザクションに係るメッセージ対と決定して呼出関係を求め、リクエストメッセージの該時刻とレスポンスメッセージの該時間から該処理種別に対応する処理に要した処理時間を求め、求めた該呼出関係と求めた該処理時間とを有するトランザクションモデルを生成する、
請求項1から3の何れかに記載の分析プログラム。
【請求項5】
前記モデル生成手順は、呼出先となる処理に対し呼び出し可能な処理が複数ある場合、各処理からの呼び出し確率を均等に定め、呼び出し元となる処理から他の処理の呼び出し確率を、処理種別毎に統合し、処理間の呼出関係の可能性を算出する、
請求項4に記載の分析プログラム。
【請求項6】
前記モデル生成手順は、処理種別毎に、呼び出し可能な処理の組み合わせを示す1以上の発生パターンを生成し、該発生パターン毎に生起確率を計算し、該生起確率が上位の該発生パターンを所定の個数選択し、選択された該発生パターンに基づいて、前記トランザクションモデルを生成する、
請求項4または5記載の分析プログラム。
【請求項7】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析装置において、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集する手段、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納する格納手段、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成するモデル生成手段、
を有する分析装置。
【請求項8】
複数のサーバが配置されるシステムにおいて実行されるトランザクションを分析するための分析方法において、
コンピュータが、
前記複数のサーバ間を繋ぐネットワークを介して受け渡されるメッセージを収集し、
収集した前記メッセージの内容を解析して、リクエストメッセージとレスポンスメッセージとのメッセージ対に関する情報を記憶手段に格納し、
モデル生成指示が入力されると、前記記憶手段から前記情報を読み出し、呼出関係を求め、求めた該呼出関係を有するトランザクションモデルを生成する、
分析方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】
【図48】
【図49】
【図50】
【図51】
【図52】
【図53】
【図54】
【図55】
【公開番号】特開2010−152899(P2010−152899A)
【公開日】平成22年7月8日(2010.7.8)
【国際特許分類】
【出願番号】特願2009−298735(P2009−298735)
【出願日】平成21年12月28日(2009.12.28)
【分割の表示】特願2004−185909(P2004−185909)の分割
【原出願日】平成16年6月24日(2004.6.24)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成22年7月8日(2010.7.8)
【国際特許分類】
【出願日】平成21年12月28日(2009.12.28)
【分割の表示】特願2004−185909(P2004−185909)の分割
【原出願日】平成16年6月24日(2004.6.24)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]