(57)【要約】【課題】監視対象システムにおける特定の事象の前兆を容易に検出する。【解決手段】監視装置３００は、メッセージログ記憶部３１０、解析部３３０、及び、照合部３５０を含む。メッセージログ記憶部３１０は、入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶する。解析部３３０は、ログをもとに、監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成する。照合部３５０は、新たな期間における監視対象システムの入力メッセージの特徴と照合定義とを比較し、監視対象システムにおける所定の事象の前兆の有無を判定する。【選択図】    図１
2015141547.tif 000002
【特許請求の範囲】
【請求項１】
入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶するメッセージログ記憶手段と、
前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成する解析手段と、
新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する照合手段と、
を備えた情報処理装置。
【請求項２】
さらに、前記所定の事象の前兆の検出有無に応じて、前記監視対象システムのリソースの追加、または、削除を行う、リソース制御手段を備える、
請求項１に記載の情報処理装置。
【請求項３】
前記監視対象システムは、複数のサブシステムを含み、前記監視対象システムに入力されたメッセージは、当該複数のサブシステムのいずれかで処理され、
前記リソース制御手段は、前記所定の事象の前兆の検出有無に応じて、前記サブシステムの追加、または、削除を行う、
請求項２に記載の情報処理装置。
【請求項４】
前記監視対象システムの入力メッセージの特徴は、平均メッセージ長、及び、メッセージ内の所定のデータ項目に設定される値の比率のうちの、少なくとも一方を含む、
請求項１乃至３のいずれかに記載の情報処理装置。
【請求項５】
前記解析手段は、前記新たな期間において前記所定の事象の前兆ありと判定されたときに当該新たな期間の後の期間で当該所定の事象が発生しなかった回数が、所定の閾値以上の場合、当該照合定義を削除する、
請求項１乃至４のいずれかに記載の情報処理装置。
【請求項６】
前記所定の事象は、前記監視対象システムが高負荷状態にあることである、請求項１乃至５のいずれかに記載の情報処理装置。
【請求項７】
前記所定の事象は、前記監視対象システムへの所定のメッセージの入力である、請求項１乃至５のいずれかに記載の情報処理装置。
【請求項８】
入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶し、
前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成し、
新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する、
監視方法。
【請求項９】
さらに、前記所定の事象の前兆の検出有無に応じて、前記監視対象システムのリソースの追加、または、削除を行う、
請求項８に記載の監視方法。
【請求項１０】
コンピュータに、
入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶し、
前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成し、
新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する、
処理を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、監視方法、及び、プログラムに関する。
【背景技術】
【０００２】
近年、ＳａａＳ（Software as a Service）やＰａａＳ（Platform as a Service）と呼ばれるクラウドコンピューティングを用いたシステムの構築が広まっている。クラウドコンピューティング環境では、仮想化技術により、ユーザ数やデータ量に応じて仮想マシン等のリソースを増減することで、システムにおける負荷の変動が吸収される。クラウドコンピューティング環境においては、リソース使用に対する課金体系は従量課金となっていることが多い。このため、リソース使用量を最小に保ちながら、負荷の変動に応じて、迅速にリソースを増減することが要求される。
【０００３】
例えば、非特許文献１に開示されているようなサービスバスを介して通信を行う業務システムが、クラウドコンピューティングを用いて構築された場合、サービスバスの負荷に応じて、サービスバスを構成するリソースの増減が行われる。この場合、監視装置等は、サービスバスの負荷を計測、監視し、その結果に応じて、サービスバスに対する要求ＴＡＴや要求スループットを満たすように、リソースの割り当てを行う。しかしながら、単に負荷の増減に応じて、リソースの増減を行う方法では、突発的な負荷の増加に即時に対応することができず、要求ＴＡＴ（Turn Around Time）や要求スループットを満たせなくなる可能性がある。このため、例えば、サービスバスの負荷の増加の前兆を予め検出し、負荷が増加する前にリソースを追加することが要求される。
【０００４】
このように、監視対象のシステムにおける特定の事象の前兆を検出する監視装置の一例が、特許文献１に開示されている。特許文献１に開示された監視装置は、監視対象システムから収集された時系列データの特徴が、障害の前兆として検出すべき選定条件に適合する場合、当該特徴と時系列データとを、過去のメタデータと時系列データとして、関連づけて格納する。そして、監視装置は、現在の時系列データの特徴が選定条件に適合する場合、当該特徴と一致する過去のメタデータに関連づけられた時系列データを参照し、現在の時系列データの今後の変化を予想する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−２８９２２１号公報
【非特許文献】
【０００６】
【非特許文献１】"機能詳細: SOA基盤 WebOTX Enterprise Service Bus"、日本電気株式会社、［online］、［平成26年1月16日検索］、インターネット〈URL：http://www.nec.co.jp/WebOTX/integration/function/index.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載されて技術においては、障害の前兆として検出すべき時系列データの特徴等を、管理者等が、予め選定条件として設定する必要がある。
【０００８】
本発明の目的は、上述の課題を解決し、監視対象システムにおける特定の事象の前兆を検出するための条件を管理者等が設定することなく、容易に、前兆を検出できることである。
【課題を解決するための手段】
【０００９】
本発明の情報処理装置は、入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶するメッセージログ記憶手段と、前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成する解析手段と、新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する照合手段と、を備える。
【００１０】
本発明の監視方法は、入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶し、前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成し、新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する。
【００１１】
本発明のプログラムは、コンピュータに、入力されたメッセージに対して所定の処理を行う監視対象システムの入力メッセージのログを記憶し、前記ログをもとに、前記監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義を生成し、新たな期間における前記監視対象システムの入力メッセージの特徴と前記照合定義とを比較し、前記監視対象システムにおける前記所定の事象の前兆の有無を判定する、処理を実行させる。
【発明の効果】
【００１２】
本発明の効果は、監視対象システムにおける特定の事象の前兆を、容易に検出できることである。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施の形態の特徴的な構成を示すブロック図である。
【図２】本発明の実施の形態における、業務システムの構成を示すブロック図である。
【図３】本発明の実施の形態における、サービスバス２００が受信するメッセージの例を示す図である。
【図４】本発明の実施の形態における、メッセージ処理を示すフローチャートである。
【図５】本発明の実施の形態における、解析処理を示すフローチャートである。
【図６】本発明の実施の形態における、メッセージログの例を示す図である。
【図７】本発明の実施の形態における、解析定義ファイル３２１の例を示す図である。
【図８】本発明の実施の形態における、メッセージログ集合３１１の例を示す図である。
【図９】本発明の実施の形態における、平均ＴＡＴ、及び、スループットの算出結果の例を示す図である。
【図１０】本発明の実施の形態における、特徴情報の算出結果の例を示す図である。
【図１１】本発明の実施の形態における、照合定義ファイル３４１の例を示す図である。
【図１２】本発明の実施の形態における、照合処理を示すフローチャートである。
【図１３】本発明の実施の形態における、メッセージログ集合３１１の他の例を示す図である。
【図１４】本発明の実施の形態における、特徴情報の算出結果の他の例を示す図である。
【図１５】本発明の実施の形態における、メッセージログ集合３１１のさらに他の例を示す図である。
【図１６】本発明の実施の形態における、特徴情報の算出結果のさらに他の例を示す図である。
【図１７】本発明の実施の形態における、照合履歴テーブル３６１の例を示す図である。
【発明を実施するための形態】
【００１４】
次に、本発明の実施の形態について説明する。
【００１５】
はじめに、本発明の実施の形態の構成について説明する。図２は、本発明の実施の形態における、業務システムの構成を示すブロック図である。
【００１６】
図２を参照すると、本発明の実施の形態における業務システムは、１以上のサービスシステム１００、サービスバス２００、監視装置３００、及び、リソース制御装置４００を含む。サービスバス２００は、本発明の監視対象システムの一実施形態である。また、監視装置３００は、本発明の情報処理装置の一実施形態である。
【００１７】
１以上のサービスシステム１００の各々は、業務システムにおける様々なサービスを提供する。サービスシステム１００は、例えば、１以上のコンピュータ上で実行されるプログラムにより実現される。
【００１８】
サービスバス２００は、１以上のサービスシステム１００と接続される。サービスバス２００は、要求元のサービスシステム１００から受信したメッセージを、他のサービスシステム１００に転送し、他のサービスシステム１００による処理結果を応答メッセージとして、当該要求元のサービスシステム１００に返信する。ここで、サービスバス２００は、サービスシステム１００間で、メッセージのプロトコル変換、データ形式の変換等も行う。本発明の実施の形態では、サービスバス２００が受信したメッセージに対して実行する、これらの転送、プロトコル変換、データ形式の変換等を、サービスバス２００の所定の処理と呼ぶ。サービスバス２００は、例えば、１以上の仮想マシン上で実行されるプログラムにより実現される。
【００１９】
サービスバス２００は、マスタ２１０、及び、１以上のスレーブ２２０を含む。マスタ２１０は、サービスシステム１００から受信したメッセージを、１以上のスレーブ２２０のいずれかに振り分けることに、負荷分散を行う。各スレーブ２２０は、上述の所定の処理を行う。各スレーブ２２０は、リソース制御装置４００により、有効化／無効化（追加／削除）される。
【００２０】
図３は、本発明の実施の形態における、サービスバス２００が受信するメッセージの例を示す図である。メッセージは、request要素の配下にmessagetype要素とbodyと要素を含む。
【００２１】
監視装置３００は、サービスバス２００における高負荷状態の前兆を検出する（サービスバス２００が高負荷状態となることを予測する）。監視装置３００は、当該前兆の検出有無に応じて、リソース制御装置４００に、スレーブ２２０の有効化／無効化を指示する。
【００２２】
監視装置３００は、メッセージログ記憶部３１０、解析定義記憶部３２０、解析部３３０、照合定義記憶部３４０、照合部３５０、及び、照合履歴記憶部３６０を含む。
【００２３】
メッセージログ記憶部３１０は、メッセージログ集合３１１を記憶する。メッセージログ集合３１１は、サービスバス２００に対して入出力されるメッセージのログ（メッセージログ）の時系列である。
【００２４】
図６は、本発明の実施の形態における、メッセージログの例を示す図である。メッセージログは、メッセージの受信日時、メッセージ長、送信元、送信先、メッセージ本文、及び、返信日時を含む。ここで、受信日時は、要求元のサービスシステム１００からのメッセージの受信日時を示す。返信日時は、当該要求元のサービスシステム１００への応答メッセージの送信日時を示す。
【００２５】
図８は、本発明の実施の形態における、メッセージログ集合３１１の例を示す図である。メッセージログ集合３１１は、メッセージログの時系列を含む。
【００２６】
解析定義記憶部３２０は、解析定義ファイル３２１を記憶する。解析定義ファイル３２１は、メッセージログ３１１の解析、及び、照合に係る設定を定義する。
【００２７】
図７は、本発明の実施の形態における、解析定義ファイル３２１の例を示す図である。解析定義ファイル３２１は、解析間隔、統計間隔、検査対象、最大許容ＴＡＴ、最小許容スループット、平均メッセージ長マージン、メッセージ比率マージン、及び、予測失敗許容回数を含む。ここで、解析間隔は、後述する解析処理を行う間隔を示す。統計間隔は、後述する照合処理を行う間隔を示す。検査対象は、照合処理において検査する対象である、メッセージ本文中の要素を示す。最大許容ＴＡＴ、最小許容スループットは、サービスバス２００が高負荷状態にあるかどうかを判定するための、ＴＡＴ、スループットの許容範囲を示す。平均メッセージ長マージン、メッセージ比率マージンは、照合処理において、メッセージの特徴情報である、平均メッセージ長、メッセージ比率を比較するときに適用されるマージンを示す。予測失敗許容回数は、予測失敗の回数の許容範囲を示す。予測失敗とは、高負荷状態の前兆の検出（高負荷状態の予測）に対して、実際に高負荷状態が発生しないケースである。
【００２８】
解析部３３０は、メッセージログをもとに、サービスバス２００が高負荷状態にあった統計期間（統計間隔ごとの期間）を検出する。そして、解析部３３０は、当該高負荷状態にあった統計期間の直前の統計期間においてサービスバス２００が受信したメッセージの特徴を定義した照合定義ファイル３４１を生成する。
【００２９】
照合定義記憶部３４０は、照合定義ファイル３４１を記憶する。
【００３０】
図１１は、本発明の実施の形態における、照合定義ファイル３４１の例を示す図である。照合定義ファイル３４１は、照合定義ＩＤ（Identifier）、平均メッセージ長、メッセージ比率を含む。
【００３１】
照合部３５０は、新たな統計期間においてサービスバス２００に入力されたメッセージの特徴と照合定義ファイル３４１とを比較し、サービスバス２００における高負荷状態の前兆の有無を判定する。
【００３２】
照合履歴記憶部３６０は、照合履歴テーブル３６１を記憶する。照合履歴テーブル３６１は、検出された高負荷状態の前兆に係る情報を示す。図１７は、本発明の実施の形態における、照合履歴テーブル３６１の例を示す図である。照合履歴テーブル３６１は、照合定義ＩＤ、照合日時、及び、予測成否を含む。照合定義ＩＤは、高負荷状態の前兆が検出されたときに用いられた、照合定義ファイル３４１の照合定義ＩＤを示す。照合日時は、高負荷状態の前兆が検出された統計期間を示す。予測成否は、高負荷状態の前兆の検出（高負荷状態の予測）に対して、実際に高負荷状態が発生した（予測が成功した）かどうかを、「ＯＫ」または「ＮＧ」で示す。
【００３３】
リソース制御装置４００は、監視装置３００からの指示に従って、スレーブ２２０の有効化／無効化を行う。リソース制御装置４００は、監視装置３００に含まれていてもよい。
【００３４】
なお、監視装置３００はＣＰＵ（Central Processing Unit）とプログラムを記憶した記憶媒体を含み、プログラムに基づく制御によって動作するコンピュータであってもよい。またメッセージログ記憶部３１０、解析定義記憶部３２０、照合定義記憶部３４０、及び、照合履歴記憶部３６０は、それぞれ個別の記憶媒体でも、１つの記憶媒体によって構成されてもよい。
【００３５】
次に、本発明の実施の形態の動作について説明する。
【００３６】
はじめに、本発明の実施の形態における、メッセージ処理について説明する。
【００３７】
図４は、本発明の実施の形態における、メッセージ処理を示すフローチャートである。
【００３８】
要求元のサービスシステム１００は、サービスバス２００へメッセージを送信する（ステップＳ１０１）。
【００３９】
サービスバス２００のマスタ２１０は、受信したメッセージを、有効化されているスレーブ２２０のいずれかへ送信する（ステップＳ１０２）。
【００４０】
メッセージを受信したスレーブ２２０は、当該メッセージに対して所定の処理を行い（ステップＳ１０３）、応答メッセージをマスタ２１０へ返信する（ステップＳ１０４）。
【００４１】
マスタ２１０は、受信した応答メッセージを要求元のサービスシステム１００へ送信する（ステップＳ１０５）。
【００４２】
また、マスタ２１０は、メッセージログを生成し、監視装置３００へ送信する（ステップＳ１０６）。
【００４３】
例えば、マスタ２１０は、図６のようなメッセージログを監視装置３００へ送信する。
【００４４】
次に、本発明の実施の形態における、解析処理について説明する。
【００４５】
ここでは、図７のような解析定義ファイル３２１が、管理者等により設定され、解析定義記憶部３２０に記憶されていると仮定する。また、サービスバス２００から受信したメッセージログをもとに、図８のようなメッセージログ集合３１１が、メッセージログ記憶部３１０に記憶されていると仮定する。さらに、後述する照合処理により生成された、図１７のような照合履歴テーブル３６１（照合日時「9/8 00:50〜01:00」以前）が、照合履歴記憶部３６０に記憶されていると仮定する。
【００４６】
図５は、本発明の実施の形態における、解析処理を示すフローチャートである。
【００４７】
解析処理は、解析定義ファイル３２１に定義された解析間隔で、実行される。
【００４８】
解析部３３０は、解析定義記憶部３２０から解析定義ファイル３２１を取得する（ステップＳ２０１）。
【００４９】
例えば、解析部３３０は、図７のような解析定義ファイル３２１を取得する。
【００５０】
解析部３３０は、メッセージログ記憶部３１０からメッセージログ集合３１１を取得する（ステップＳ２０２）。
【００５１】
例えば、解析部３３０は、図８のようなメッセージログ集合３１１を取得する。
【００５２】
解析部３３０は、ステップＳ２０２で取得したメッセージログ集合３１１に含まれる期間内の、統計期間を１つ選択する（ステップＳ２０３）。ここでは、選択した統計期間を対象解析期間と呼ぶ。
【００５３】
解析部３３０は、対象解析期間におけるメッセージログをもとに、当該対象解析期間において、サービスバス２００が高負荷状態にあったかどうかを判定する（ステップＳ２０４）。
【００５４】
ここで、解析部３３０は、対象解析期間のメッセージについて、サービスバス２００において実行された所定の処理の平均ＴＡＴ、及び、スループットを算出する。解析部３３０は、メッセージログの受信時刻と返信時刻の差により各メッセージの処理のＴＡＴを算出し、当該対象解析期間のメッセージについて平均値を算出する。また、解析部３３０は、対象解析期間に処理されたメッセージ数を統計間隔で割ることにより、スループットを算出する。
【００５５】
そして、解析部３３０は、算出された平均ＴＡＴ、スループットと、解析定義ファイル３２１に定義された最大許容ＴＡＴ、最小許容スループットを用いて、サービスバス２００が対象解析期間において高負荷状態であったかどうかを、以下のように判定する。解析部３３０は、平均ＴＡＴが、最大許容ＴＡＴの許容範囲内で、かつ、スループットが最小許容スループットの許容範囲内の場合、高負荷状態になかったと判定する。一方、解析部３３０は、平均ＴＡＴが、最大許容ＴＡＴの範囲外、あるいは、スループットが最小許容スループットの範囲外の場合、高負荷状態にあったと判定する。
【００５６】
図９は、本発明の実施の形態における、平均ＴＡＴ、及び、スループットの算出結果の例を示す図である。
【００５７】
例えば、対象解析期間が「9/8 00:40〜00:50」の場合、図９の算出結果における平均ＴＡＴ「10ms」は最大許容ＴＡＴ「100ms」の許容範囲内である。また、スループット「10件/sec」は、最小許容スループット「50件/sec」の許容範囲外であるが、受信メッセージ数が「10件/sec」であるため、問題ないとみなす。したがって、この場合、解析部３３０は、高負荷状態になかったと判定する。また、対象解析期間が「9/8 00:50〜01:00」の場合、平均ＴＡＴ「75ms」は最大許容ＴＡＴの許容範囲内であり、スループット「75件/sec」も、最小許容スループットの許容範囲内である。したがって、この場合も、解析部３３０は、高負荷状態になかったと判定する。一方、対象解析期間が「9/8 01:00〜01:10」の場合、平均ＴＡＴ「200ms」は最大許容ＴＡＴの許容範囲外であり、スループット「25件/sec」も最小許容スループットの許容範囲外である。したがって、この場合、解析部３３０は、高負荷状態にあったと判定する。
【００５８】
ステップＳ２０４において、高負荷状態にあったと判定された場合（ステップＳ２０４／Ｙ）、解析部３３０は、対象解析期間の直前の統計期間の入力メッセージの特徴情報を生成する（ステップＳ２０５）。
【００５９】
ここで、解析部３３０は、特徴情報として、平均メッセージ長、及び、メッセージ比率を算出する。解析部３３０は、直前の統計期間にサービスバス２００が受信したメッセージの長さの平均を「平均メッセージ長」として算出する。また、解析部３３０は、直前の統計期間にサービスバス２００が受信したメッセージで用いられた、解析定義ファイル３２１で定義された検査対象の要素の各文字列の比率を「メッセージ比率」として算出する。
【００６０】
図１０は、本発明の実施の形態における、特徴情報の算出結果の例を示す図である。
【００６１】
例えば、対象解析期間が「9/8 01:00〜01:10」の場合、解析部３３０は、直前の統計期間「9/8 00:50〜01:00」について、図１０のような特徴情報を生成する。
【００６２】
解析部３３０は、ステップＳ２０５で生成された、直前の統計期間の入力メッセージの特徴情報をもとに、照合定義ファイル３４１を生成する（ステップＳ２０６）。
【００６３】
ここで、解析部３３０は、特徴情報の平均メッセージ長に、解析定義ファイル３２１に定義されたメッセージ長マージンを乗じた値を、照合定義ファイル３４１における「平均メッセージ長」に設定する。また、解析部３３０は、特徴情報の「メッセージ比率」に、解析定義ファイル３２１に定義されたメッセージ比率マージンを加算／減算した値を、照合定義ファイル３４１における「メッセージ比率」に設定する。なお、マージンを加算した値が100%を超えた場合は、算出結果を「100%」としてもよい。また、マージンを減算した値が0%未満の場合も、算出結果を「0%」としてもよい。
【００６４】
例えば、解析部３３０は、図１０の特徴情報、及び、図７の解析定義ファイル３２１における各マージンをもとに、対象解析期間「9/8 01:00〜01:10」について、図１１のように、照合定義ＩＤ「201309080100」を付与した照合定義ファイル３４１を生成する。
【００６５】
さらに、解析部３３０は、照合履歴テーブル３６１を参照し、事前に実行された、対象解析期間の直前の統計期間における照合処理（後述）で、高負荷状態の前兆が検出済みかどうかを判定する（ステップＳ２０７）。ここで、照合履歴テーブル３６１に、照合日時が直前の統計期間であるレコードが存在する場合は、前兆が検出済みであることを表す。前兆が検出済みの場合（ステップＳ２０７／Ｙ）、解析部３３０は、照合履歴テーブル３６１における、当該前兆に係るレコードの予測成否に「ＯＫ」を設定する（ステップＳ２０８）。
【００６６】
例えば、対象解析期間が「9/8 01:00〜01:10」の場合、図１７の照合履歴テーブル３６１に、照合日時「9/8 00:50〜01:00」のレコードが存在する。解析部３３０は、図１７のように、当該レコードの予測成否に「ＯＫ」を設定する。
【００６７】
解析部３３０は、ステップＳ２１３の処理に進む。
【００６８】
一方、ステップＳ２０４において、高負荷状態になかったと判定された場合（ステップＳ２０４／Ｎ）、解析部３３０は、ステップＳ２０７と同様に、高負荷状態の前兆が検出済みかどうかを判定する（ステップＳ２０９）。前兆が検出済みの場合（ステップＳ２０９／Ｙ）、解析部３３０は、照合履歴テーブル３６１における、当該前兆に係るレコードの予測成否に「ＮＧ」を設定する（ステップＳ２１０）。
【００６９】
さらに、解析部３３０は、照合履歴テーブル３６１において、ステップＳ２１０で予測成否「ＮＧ」が設定されたレコードと同一の照合定義ファイル３４１、及び、予測成否「ＮＧ」が設定されたレコードの数を求める。そして、求めた数が、解析定義ファイル３２１に定義された予測失敗許容回数を超えたか判定する（ステップＳ２１１）。予測失敗許容回数を超えた場合（ステップＳ２１１／Ｙ）、解析部３３０は、当該照合定義ファイル３４１を照合定義記憶部３４０から削除する（ステップＳ２１２）。これにより、不適切な照合定義ファイル３４１は削除され、予測精度の高い照合定義ファイル３４１が残る。また、サービスシステム１００から受信するメッセージのパターンが変化した場合も、古い照合定義ファイル３４１が削除される。したがって、管理者等による設定変更が無くても、照合定義ファイル３４１による予測精度が改善する。
【００７０】
解析部３３０は、ステップＳ２０２で取得したメッセージログ集合３１１に含まれる、全ての統計期間について、ステップＳ２０３からの処理を繰り返す（ステップＳ２１３）。
【００７１】
解析部３３０は、生成された照合定義ファイル３４１を、照合定義記憶部３４０に保存する（ステップＳ２１４）。
【００７２】
なお、解析部３３０は、生成された照合定義ファイル３４１を複製して、外部の記憶装置や他の監視装置へ出力してもよい。この場合、他の監視装置が、出力された照合定義ファイル３４１を用いて、業務システム内の他のサービスバスや、他の業務システムのサービスバスの監視を行ってもよい。
【００７３】
解析部３３０は、解析済みのメッセージログをメッセージログ集合３１１から削除する（ステップＳ２１５）。
【００７４】
次に、本発明の実施の形態における、照合処理について説明する。
【００７５】
ここでは、図７のような解析定義ファイル３２１が、管理者等により設定され、解析定義記憶部３２０に記憶されていると仮定する。また、解析処理により、図１１の照合定義ファイル３４１が、照合定義記憶部３４０に記憶されていると仮定する。さらに、図１７のような照合履歴テーブル３６１（照合日時「9/8 00:50〜01:00」以前）が、照合履歴記憶部３６０に記憶されていると仮定する。
【００７６】
図１２は、本発明の実施の形態における、照合処理を示すフローチャートである。
【００７７】
照合処理は、解析定義ファイル３２１に定義された統計間隔で、実行される。
【００７８】
照合部３５０は、解析定義記憶部３２０から解析定義ファイル３２１を、照合定義記憶部３４０から全ての照合定義ファイル３４１を取得する（ステップＳ３０１）。
【００７９】
照合部３５０は、メッセージログ記憶部３１０のメッセージログ集合３１１から、最新の統計期間のメッセージログを取得する（ステップＳ３０２）。ここでは、最新の統計期間を、対象照合期間と呼ぶ。
【００８０】
照合部３５０は、ステップＳ２０５と同様の方法で、対象照合期間のメッセージの特徴情報を生成する（ステップＳ３０３）。
【００８１】
照合部３５０は、照合定義ファイル３４１を１つ選択する（ステップＳ３０４）。
【００８２】
照合部３５０は、ステップＳ３０３で生成された、対象照合期間のメッセージの特徴情報と、ステップＳ３０４で選択された照合定義ファイル３４１とを比較する。そして、照合部３５０は、サービスバス２００における高負荷状態の前兆があるかどうかを判定する（ステップＳ３０５）。
【００８３】
ここで、照合部３５０は、対象照合期間のメッセージの特徴情報と照合定義ファイル３４１とを用いて、高負荷状態の前兆の有無を、以下のように判定する。照合部３５０は、特徴情報の平均メッセージ長が、照合定義ファイル３４１の平均メッセージ長の範囲内で、かつ、特徴情報のメッセージ比率が照合定義ファイル３４１のメッセージ比率の範囲内の場合、前兆ありと判定する。一方、照合部３５０は、特徴情報の平均メッセージ長が、照合定義ファイル３４１の平均メッセージ長の範囲外、または、特徴情報のメッセージ比率が照合定義ファイル３４１のメッセージ比率の範囲外の場合、前兆なしと判定する。
【００８４】
高負荷状態の前兆がある場合（ステップＳ３０５／Ｙ）、照合部３５０は、照合履歴テーブル３６１に、対象照合期間のレコードを追加する（ステップＳ３０６）。ここで、照合部３５０は、比較に用いた照合定義ファイル３４１の照合定義ＩＤを当該レコードの照合定義ＩＤに設定する。また、照合部３５０は、対象照合期間を当該レコードの照合日時に設定する。レコードにおける予測成否は、解析処理（前述）のステップＳ２０８、Ｓ２１０にて設定される。
【００８５】
図１３は、本発明の実施の形態における、メッセージログ集合３１１の他の例を示す図である。また、図１４は、本発明の実施の形態における、特徴情報の算出結果の他の例を示す図である。
【００８６】
例えば、照合部３５０は、図１３のメッセージログ集合３１１における対象照合期間「9/9 01:40〜01:50」について、図１４のような特徴情報を算出する。
【００８７】
図１４の特徴情報と図１１の照合定義ファイル３４１を比較した場合、特徴情報における平均メッセージ長「1101」は照合定義ファイル３４１における平均メッセージ長「1323〜1617」の範囲外である。また、特徴情報における平均メッセージ比率「TYPE1:60%, TYPE2:40%」も照合定義ファイル３４１におけるメッセージ比率「TYPE1:10%〜30%, TYPE2:70%〜90%」の範囲外である。したがって、この場合、照合部３５０は、高負荷状態の前兆なしと判定する。
【００８８】
図１５は、本発明の実施の形態における、メッセージログ集合３１１のさらに他の例を示す図である。また、図１６は、本発明の実施の形態における、特徴情報の算出結果のさらに他の例を示す図である。
【００８９】
例えば、照合部３５０は、図１５のメッセージログ集合３１１における対象照合期間「9/9 01:50〜02:00」について、図１６のような特徴情報を算出する。
【００９０】
図１６の特徴情報と図１１の照合定義ファイル３４１を比較した場合、特徴情報における平均メッセージ長「1615」は照合定義ファイル３４１における平均メッセージ長の範囲内である。また、特徴情報における平均メッセージ比率「TYPE1:20%, TYPE2:80%」も照合定義ファイル３４１におけるメッセージ比率の範囲内である。したがって、この場合、照合部３５０は、高負荷状態の前兆ありと判定する。そして、照合部３５０は、図１７のように、図１１の照合定義ファイル３４１の識別子「201309080100」、及び、対象照合期間「9/9 01:50〜02:00」が設定されたレコードを、照合履歴テーブル３６１に追加する。
【００９１】
照合部３５０は、全ての照合定義ファイル３４１について、ステップＳ３０４〜Ｓ３０６を繰り返す（ステップＳ３０７）。
【００９２】
ステップＳ３０４〜Ｓ３０７により、いずれかの照合定義ファイル３４１に対して、前兆が検出された場合（ステップＳ３０８／Ｙ）、照合部３５０は、リソース制御装置４００に、スレーブ２２０の有効化を指示する（ステップＳ３０９）。リソース制御装置４００は、例えば、リソースプールにおける仮想マシンを用いて、スレーブ２２０を１つ有効化（追加）する。なお、リソース制御装置４００は、スレーブ２２０の数が所定の上限値に達している場合は、スレーブ２２０の有効化を行わない。
【００９３】
一方、どの照合定義ファイル３４１に対しても、前兆が検出されない場合（ステップＳ３０８／Ｎ）、照合部３５０は、ステップＳ２０４と同様に、当該対象照合期間において、サービスバス２００が高負荷状態にあったかどうかを判定する（ステップＳ３１０）。高負荷状態になかった場合（ステップＳ３１０／Ｎ）、照合部３５０は、リソース制御装置４００に、スレーブ２２０の無効化を指示する（ステップＳ３１１）。リソース制御装置４００は、スレーブ２２０を１つ無効化（削除）する。なお、リソース制御装置４００は、スレーブ２２０の数が所定の下限値に達している場合は、スレーブ２２０の無効化を行わない。
【００９４】
以上により、本発明の実施の形態の動作が完了する。
【００９５】
次に、本発明の実施の形態の特徴的な構成を説明する。図１は、本発明の実施の形態の特徴的な構成を示すブロック図である。
【００９６】
本発明の情報処理装置（監視装置３００）は、メッセージログ記憶部３１０、解析部３３０、及び、照合部３５０を含む。メッセージログ記憶部３１０は、入力されたメッセージに対して所定の処理を行う監視対象システム（サービスバス２００）の入力メッセージのログを記憶する。解析部３３０は、ログをもとに、監視対象システムにおいて所定の事象が発生した期間の前の期間における入力メッセージの特徴を表す照合定義（照合定義ファイル３４１）を生成する。照合部３５０は、新たな期間における監視対象システムの入力メッセージの特徴と照合定義とを比較し、監視対象システムにおける所定の事象の前兆の有無を判定する。
【００９７】
本発明の実施の形態によれば、監視対象システムにおける特定の事象の前兆を容易に検出できる。その理由は、解析部３３０が、所定の事象が発生した期間の前の期間の入力メッセージの特徴を表す照合定義ファイル３４１を生成し、照合部３５０が、新たな期間の入力メッセージの特徴と照合定義ファイル３４１とを比較し、前兆の有無を判定するためである。
【００９８】
また、本発明の実施の形態によれば、監視対象システムにおけるリソースの使用量を必要最小限に抑えることができる。その理由は、リソース制御装置４００が、所定の事象の前兆の検出有無に応じて、監視対象システムのリソースの追加、または、削除を行うためである。
【００９９】
また、本発明の実施の形態によれば、監視対象システムの性能を劣化させることなく、前兆の有無の判定ができる。その理由は、監視対象システムの外部の監視装置３００が、監視対象システムの入力メッセージのログをもとに、照合定義ファイル３４１の生成、及び、生成された照合定義ファイル３４１を用いた前兆の有無の判定を行うためである。
【０１００】
また、本発明の実施の形態によれば、同様の監視対象システムを複数含むような大規模分散環境や、同様の監視対象システムを含む他の類似の環境においても、特定の事象の前兆を効率的に検出できる。その理由は、解析部３３０が、照合定義ファイル３４１を複製して、外部の記憶装置や他の監視装置へ出力するためである。
【０１０１】
また、本発明の実施の形態によれば、監視対象システムのＴＡＴやスループットのみを監視する場合に比べて、特定の事象の発生を、より高精度に予測できる。その理由は、監視装置３００が、平均メッセージ長や、メッセージ比率等、監視対象システムの入力メッセージの特徴の統計量をもとに、特定の事象の前兆の有無を判定するためである。
【０１０２】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１０３】
例えば、本発明の実施の形態においては、前兆の検出対象の事象をサービスバス２００の高負荷状態とし、前兆の検出有無に応じた制御対象を負荷分散のためのリソース（スレーブ２２０）とした。しかしながら、前兆の検出対象の事象や、前兆の検出有無に応じた制御対象は、他の事象や制御対象でもよい。例えば、前兆の検出対象の事象を大きなメッセージ等、所定のメッセージの受信、前兆の検出有無に応じた制御対象を、当該所定のメッセージの処理に必要なハードディスク等のリソースとしてもよい。この場合、解析部３３０は、サービスバス２００が所定のメッセージを受信した統計期間の直前の統計期間における特徴情報をもとに、照合定義ファイル３４１を生成する。そして、照合部３５０は、生成した照合定義ファイル３４１を用いて所定のメッセージの受信の前兆を検出し、ハードディスクを追加する。これにより、例えば、数百ＭＢや数ＧＢといった大きなメッセージの処理に一時的にハードディスクの容量を必要とする場合、当該大きなメッセージの受信の前兆を検出し、予め、ハードディスクの容量を増やすことができる。
【０１０４】
また、本発明の実施の形態においては、監視装置３００は、メッセージの特徴情報として、平均メッセージ長、及び、メッセージ比率を用いた。しかしながら、検出対象の事象の前兆が検出できれば、監視装置３００は、特徴情報として、メッセージに係る他の情報を用いてもよい。例えば、監視装置３００は、特徴情報として、メッセージの送信元や送信先等、メッセージ内の他のデータ項目に設定される各値（テキストを含む）の比率を用いてもよい。
【０１０５】
また、本発明の実施の形態においては、解析部３３０は、検出対象の事象が発生した統計期間の直前の統計期間の特徴情報をもとに照合定義ファイル３４１を生成した。しかしながら、検出対象の事象の前兆が検出できれば、解析部３３０は、例えば、所定時間前の統計期間等、直前の統計期間よりさらに前の統計期間の特徴情報をもとに照合定義ファイル３４１を生成してもよい。
【０１０６】
また、本発明の実施の形態においては、解析部３３０は、検出対象の事象の前兆が検出された統計期間の直後の統計期間で当該検出対象の事象が発生したかどうかにより、予測成否を判定した。しかしながら、解析部３３０は、所定時間後までの各統計期間等、直後の統計期間よりさらに後の統計期間までに当該検出対象の事象が発生したかどうかにより、予測成否を判定してもよい。
【０１０７】
また、本発明の実施の形態においては、監視対象システムをサービスバス２００とした。しかしながら、入出力されるメッセージの特徴から特定の事象の前兆が検出できるシステムであれば、監視対象システムは、サービスバス２００以外の他のシステムでもよい。
【産業上の利用可能性】
【０１０８】
本発明は、例えば、鉄道、航空、区役所に係るシステム等、季節や時間帯などによって処理量が大幅に増減する業務システムに適用できる。
【符号の説明】
【０１０９】
１００    サービスシステム
２００    サービスバス
２１０    マスタ
２２０    スレーブ
３００    監視装置
３１０    メッセージログ記憶部
３１１    メッセージログ集合
３２０    解析定義記憶部
３２１    解析定義ファイル
３３０    解析部
３４０    照合定義記憶部
３４１    照合定義ファイル
３５０    照合部
３６０    照合履歴記憶部
３６１    照合履歴テーブル
４００    リソース制御装置
【図１】
2015141547.tif 000003
【図２】
2015141547.tif 000004
【図３】
2015141547.tif 000005
【図４】
2015141547.tif 000006
【図５】
2015141547.tif 000007
【図６】
2015141547.tif 000008
【図７】
2015141547.tif 000009
【図８】
2015141547.tif 000010
【図９】
2015141547.tif 000011
【図１０】
2015141547.tif 000012
【図１１】
2015141547.tif 000013
【図１２】
2015141547.tif 000014
【図１３】
2015141547.tif 000015
【図１４】
2015141547.tif 000016
【図１５】
2015141547.tif 000017
【図１６】
2015141547.tif 000018
【図１７】
2015141547.tif 000019