JP2007183904A - イベント処理システム、イベント処理方法、イベント処理装置、及び、イベント処理プログラム - Google Patents

Abstract

【課題】イベントメッセージに対応した処理を確実に実行することができると共に、イベントメッセージの処理効率を向上させることができるイベント処理システム２３を提供する。
【解決手段】本発明のイベント処理システム２３は、ＩＴ業務システム４０の状態の遷移に応じて受信したイベントメッセージを、その発行順にイベントメッセージ保持部２３３内に保持し、イベントメッセージ保持部２３３内のイベントメッセージの中から、イベントメッセージが発行された後のＩＴ業務システム４０の状態が、イベントメッセージ保持部２３３内の最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態と一致するイベントメッセージを検索し、当該イベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージをイベントメッセージ保持部２３３から削除する。
【選択図】 図６

Description

本発明は、監視対象の状態の遷移に応じて出力されるイベントメッセージを処理するシステムおよび方法に関する。

近年のＩＴシステムは、複数のＩＴ機器から構成される等、大規模化・複雑化が進み、その運用管理には、イベントドリブンのＩＴ管理システムを用いることが多い。イベントドリブンのＩＴ管理システムでは、複数の監視システムが、管理対象となるＩＴ機器等の障害情報や性能情報、状態遷移等の動的管理情報を監視し、管理情報に有意な変化があれば、それをイベントとして捕らえ、イベントメッセージを自身もしくは別のＩＴ管理システムに通知する。イベントメッセージを受信したＩＴ管理システムでは、受信したイベントメッセージに応じた適切な対処をすることで、運用管理業務を円滑に遂行するような処理がなされるのが通常である。
例えば、大規模な計算センターにおいては、Ｗｅｂサービスプログラムなどの複数の業務アプリケーションのそれぞれを、少なくとも一つのコンピュータで稼動させ、ある業務アプリケーションに対するリクエストを、その業務アプリケーションが稼動しているコンピュータに振り分けて処理するシステムが構築されている。
このようなシステムでは、リソース量（コンピュータ資源）の増減により、処理要求の多い業務アプリケーションを、円滑に処理している。つまり、業務アプリケーションが割り当てられていないコンピュータを待機させ、処理要求の多い業務アプリケーションに対して、待機していたコンピュータを割り当て、そのコンピュータで業務アプリケーションを稼動させることにより、処理要求に対応させている。
特許文献２には、あるサービス（業務アプリケーション）を稼働させている計算機リソースを、別のサービスに割り当て直すための技術が開示されている。ここでは、待機系計算機リソースは、アプリケーションがインストールされていないデッドスタンバイ状態を持ち、このデッドスタンバイ状態の計算機リソースを複数サービス又は複数ユーザで共有することで、遊休計算機リソースの使用率の向上およびサーバ統合を実現し、計算機リソース維持に必要なコストを削減している。また、個々のサービスに関し過去の稼動履歴を用いて負荷予測を行い、予測結果に応じて、余剰の出るサービスから、当該サービスが保有していた遊休計算機リソースを、他のサービスへ再配置する。
このようにすることで、処理要求の多い業務アプリケーションのサービスレベルの低下を防止している。ここで、サービスレベルとは、サービス提供者からサービス利用者に対して提供されるサービスのレベルのことである。例えば、サービス利用者の端末がリクエストを送信してから、該リクエストに対する結果を該端末が受信するまでの時間で表される。
上述の大規模なＩＴシステムを管理する場合でも、イベントドリブンのＩＴ管理手法が用いられる。上述の例では、処理要求の多い業務アプリケーションを特定するため、業務アプリケーションが稼動している、一以上のコンピュータに、性能監視プログラムを配備し、そのコンピュータ資源、そこで稼動する業務アプリケーションの性能・状況を監視する。性能監視プログラムは、監視対象の計測値（処理要求、サービスレベル、負荷など）が、予め設定した閾値を越えると、ＩＴ管理システムにイベントメッセージにより通知する。こうして、業務アプリケーションに対して割り当てるリソース量（計算機資源）を増減することで、処理要求の多い業務アプリケーションを円滑に処理できる。

このようなイベントドリブンのＩＴ管理システムでは、イベントメッセージの数量が膨大になった場合に、管理システムの処理能力に不足が生じてしまい、処理に遅延が生じる場合がある。

このような問題を解決するための技術として、例えば特許文献１には、イベントキューに滞留するイベントメッセージのタイムスタンプを比較し、予め定められた時間間隔を超過して通知されたイベントメッセージのみをイベント処理部における対処処理の対象とすることによって、短期間に連続して到着するイベントメッセージに対する処理を省略してイベントメッセージの処理を高速化する技術が開示されている。

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

しかし、特許文献１に記載されたイベント制御装置は、イベントの内容に関わらず、イベントのタイムスタンプのみに基づいて一律にイベントを破棄することにより、短期間に連続して到着するイベントメッセージに対する処理を省略してイベントメッセージの処理を高速化している。そのため、当該イベント制御装置は、処理が必要なイベントであっても破棄する場合があり、システム全体が正しく動作できない場合がある。
つまり、サービスレベルに応じて、業務アプリケーションに対して割り当てる計算機リソースを動的に変更するようなＩＴ管理システムにおいては、計算機リソースの増減処理に要する時間に比べて、リソースの増減を指示するイベントメッセージが短期間に頻発する場合が有る。このようなシステムの現象に特許文献１のイベント制御を行うと、システムに必要な計算機リソースの増減が為されない可能性が有る。
イベントメッセージが短期間に頻発することは、監視対象の計測値に関する閾値の設定が不適切であった場合、監視項目が多岐にわたっている場合、計測値に関する閾値の設定が適切であっても、Ｗｅｂサービスのように負荷の想定が困難である業務アプリケーションを運用している場合などに起こり得る。かかる場合に通知されるイベントメッセージは、サービスレベルの変化に伴い、監視項目の種別によって様々な内容となるため、短期間に複数の種類のイベントメッセージが通知され得る。
更に、計算機リソースの変更に、数十分（分単位）から数時間（時間単位）の移行時間を要する場合に、その間に通知される複数のイベントメッセージの中で、相反する動作を計算機システムに要求するものがあったときは、変更動作が不安定となるなど、短期間に集中したイベントメッセージのみを扱う特許文献１記載の従来技術では、かかる事態に対応しきれない。

本発明は上記事情を鑑みてなされたものであり、本発明の目的は、イベントメッセージに対応した処理を確実に実行すると共に、イベントメッセージの処理効率を向上させることができるようにすることにある。

上記課題を解決するために、本発明のイベント処理システムは、監視対象システムの状態の遷移に応じて発行されたイベントメッセージを、イベントメッセージ保持手段内に保持し、イベントメッセージ保持手段に保持されているイベントメッセージの中から、イベントメッセージが発行された後の監視対象システムの状態が、イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の監視対象システムの状態と一致するイベントメッセージを検索し、当該イベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージを、イベントメッセージ保持手段から削除する。
つまり、例えば、「ＣＰＵ使用率：高」のイベントメッセージの後に、「ＣＰＵ使用率：中」、「ＣＰＵ使用率：低」、「ＣＰＵ使用率：中」、「ＣＰＵ使用率：高」、「ＣＰＵ使用率：中」、…のイベントメッセージが通知される場合（図５）に、最初の「ＣＰＵ使用率：高」のイベントメッセージの後、はじめて「ＣＰＵ使用率：高」のイベントメッセージが出現するまでの、イベントメッセージを無視する機能を設け、不要な計算機リソースの変更動作を抑止する。

例えば、本発明は、監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理システムであって、監視システムによって発行されたイベントメッセージを保持して、発行された順に出力するイベントメッセージ保持手段と、イベントメッセージ保持手段から出力されたイベントメッセージを処理することにより、監視対象システムを制御するイベント処理手段と、イベントメッセージ保持手段内のイベントメッセージの中で、処理が必要なイベントメッセージを選択してイベント処理手段へ供給するイベントフィルタリング手段とを備え、イベントフィルタリング手段は、イベントメッセージ保持手段に保持されているイベントメッセージの中から、イベントメッセージが発行された後の監視対象システムの状態が、イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の監視対象システムの状態と一致するイベントメッセージを検索し、当該イベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージを、イベントメッセージ保持手段から削除するフィルタリング処理を実行することを特徴とするイベント処理システムを提供する。

本発明のイベント処理システムによれば、イベントメッセージに対応した処理を確実に実行することができると共に、イベントメッセージの処理効率を向上させることができる。

以下に、本発明の実施の形態について説明する。

図１は、本発明の一実施形態に係るサービス提供システム１０の構成を示す。サービス提供システム１０は、監視対象制御システム２０、監視システム３０、および複数のＩＴ業務システム４０ａ〜ｃを備える。
図１２は、監視対象制御システム２０、監視システム３０、又は、ＩＴ業務システム４０におけるサーバ、これら各々のハードウェア構成例を示す図である。各システム等は、ＣＰＵ１２０１と、メモリ１２０２と、ＨＤＤ等の外部記憶装置１２０３と、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭやＩＣカードなどの記憶媒体からデータを読み取る読取装置１２０４と、キーボードやマウスなどの入力装置１２０６と、モニタやプリンタなどの出力装置１２０７と、管理ネットワーク１１や業務ネットワーク１２に接続するための通信装置１２０８と、これらの各装置を接続するバス１２０９と、を備えた一般的なコンピュータにおいて、ＣＰＵ１２０１がメモリ１２０２上にロードされたプログラムを実行することで実現される。かかるプログラムは、読取装置１２０４を介して記憶媒体から、あるいは、通信装置１２０８を介して管理ネットワーク１１や業務ネットワーク１２から、外部記憶装置１２０３にダウンロードされ、それから、メモリ１２０２上にロードされてＣＰＵ１２０１により実行されるようにしてもよい。あるいは外部記憶装置１２０３を経由せずに、メモリ１２０２上に直接ロードされ、ＣＰＵ１２０１により実行されるようにしてもよい。

それぞれのＩＴ業務システム４０は、ロードバランサ４１、ＤＢサーバ４４、および複数のＷｅｂサーバ４２、４３を有し、業務ネットワーク１２を介して顧客等の情報通信機器１３に接続されている。ＩＴ業務システム４０は業務アプリケーションを稼動させており、情報通信機器１３からのリクエストに対してレスポンスを返すことにより、例えばオンラインでのチケット販売等のサービスを情報通信機器１３のユーザに提供する。また、それぞれのＩＴ業務システム４０は、管理ネットワーク１１を介して、監視対象制御システム２０および監視システム３０に接続されている。

なお、それぞれのＩＴ業務システム４０は、本図に示した構成に限定されるものではなく、業務ネットワーク１２を介して顧客等の情報通信機器１３へサービスを提供するものであればどのような構成であってもよい。また、それぞれのＩＴ業務システム４０は、１台の装置であってもよく、複数の装置を組み合わせたシステムであってもよい。また、情報通信機器１３は、情報通信端末に限られず、サーバ等であってもよい。また、管理ネットワーク１１と業務ネットワーク１２とは、物理的に異なるネットワークとして構成されてもよく、物理的に同一のネットワークを、論理的に異なるネットワークとして構成されてもよい。

監視システム３０は、レスポンスタイム監視部３１、ＣＰＵ使用率監視部３２、およびディスク使用率監視部３３等を有し、管理ネットワーク１１を介して監視対象制御システム２０およびそれぞれのＩＴ業務システム４０に接続されている。監視システム３０は、それぞれのＩＴ業務システム４０の状態を監視し、ＩＴ業務システム４０の状態に有意な変化がある都度、その変化の内容を示すイベントメッセージを、管理ネットワーク１１を介して監視対象制御システム２０へ送信する。

レスポンスタイム監視部３１は、それぞれのＩＴ業務システム４０のレスポンスタイムを常に監視しており、情報通信機器１３からのリクエストに対して、予め定められた期間（例えば１０秒）以内にレスポンスがあるか否かを監視する。そして、情報通信機器１３からのリクエストが多くなってＩＴ業務システム４０にかかる処理負荷が大きくなり、ＩＴ業務システム４０が予め定められた期間以内にレスポンスを返すことができなくなった場合に、レスポンスタイム監視部３１は、ＩＴ業務システム４０の状態が、レスポンスタイムが１０秒未満の状態から１０秒以上かかる状態へ遷移した旨を示すイベントメッセージを、管理ネットワーク１１を介して監視対象制御システム２０へ送信する。その後、ＩＴ業務システム４０が予め定められた期間以内にレスポンスを返すことがでるようになった場合には、レスポンスタイム監視部３１は、レスポンスタイムが１０秒以上かかる状態から１０秒未満の状態へ遷移した旨を示すイベントメッセージを管理ネットワーク１１を介して監視対象制御システム２０へ送る。

ＣＰＵ使用率監視部３２やディスク使用率監視部３３も、レスポンスタイム監視部３１と同様に、ＣＰＵ使用率やディスク使用率等のＩＴ業務システム４０の状態を示すそれぞれのパラメータを監視する。そして、ＩＴ業務システム４０の状態が、予め設定された閾値を上回った場合または下回った場合に、ＣＰＵ使用率監視部３２やディスク使用率監視部３３は、ＩＴ業務システム４０の状態が遷移した旨を示すイベントメッセージを管理ネットワーク１１を介して監視対象制御システム２０へ送る。

なお、監視システム３０の監視項目は、レスポンスタイムやＣＰＵ使用率、ディスク使用率等に限られず、単位時間あたりの処理件数等であってもよい。また、本実施形態では、監視システム３０は、それぞれのＩＴ業務システム４０と別個の装置として表現しているが、本発明はこれに限られず、それぞれのＩＴ業務システム４０内の機能の一部として実現されていてもよい。これら監視システム３０のその他の機能は、ＩＴ管理システムにおける一般的な監視システムと同様であり、その詳細は省略する。

監視対象制御システム２０は、管理ネットワーク１１を介して監視システム３０およびＩＴ業務システム４０に接続されており、監視システム３０からのイベントメッセージを受信し、受信したイベントメッセージに応じて、それぞれのＩＴ業務システム４０を制御する。ここで、監視対象制御システム２０によって実行される、イベントメセージに応じた制御とは、例えば、Ｗｅｂサーバ４２ａのＣＰＵ使用率が予め定められた閾値を超えた旨を示すイベントメッセージを監視システム３０から受信した場合に、Ｗｅｂサーバ４３ａのＣＰＵ使用率に余裕があれば、ロードバランサ４１ａを制御して、負荷分散比率を変更する、もしくはどのＷｅｂサーバのＣＰＵ利用率にも余裕が無ければ、新たにＷｅｂサーバを追加して負荷分散を拡張し、負荷の低減を図る等である。イベントメセージに応じた制御には、顧客に提供するサービスレベルを改善するための対処処理や、業務アプリケーションが使用するリソース量を節約するための対処処理などがある。これらはＩＴ管理システムで実行可能な一般的な制御であるので、その詳細は省略する。

監視対象制御システム２０は、イベントメッセージ供給部２１、イベントメッセージキュー２２、イベントログ収集部２４、および複数のイベント処理システム２３ａ〜ｃを有する。イベント処理システム２３ａ〜ｃのそれぞれは、イベントメッセージに対応した処理を実行する。例えば、イベント処理システム２３ａは、レスポンスタイムの悪化を示すイベントメセージに対して、予備系のＷｅｂサーバを新たに稼動させることにより、レスポンスタイムの改善を図る処理を実行し、イベント処理システム２３ｂは、Ｗｅｂサーバ４２ａのＣＰＵ使用率が予め定められた閾値を超えた旨を示すイベントメッセージに対して、Ｗｅｂサーバ４３ａのＣＰＵ使用率に余裕があれば、ロードバランサ４１ａを制御して、負荷分散比率を変更する処理を実行する。もし、どのＷｅｂサーバのＣＰＵ利用率にも余裕が無ければ、新たにＷｅｂサーバを追加し、ロードバランサ４１ａの設定を変更して負荷分散先を追加する。

イベントメッセージキュー２２は、監視システム３０から発行されたイベントメッセージを格納し、格納したイベントメッセージを、発行された順番でイベントメッセージ供給部２１へ出力する。イベントメッセージ供給部２１は、イベントメッセージキュー２２から取得したイベントメッセージを、イベントログ収集部２４およびそれぞれのイベントメッセージを処理するイベント処理システム２３に供給する。イベントログ収集部２４は、イベントメッセージキュー２２に格納されたイベントメッセージを、発行された順番で全てログとして記録する。イベントログ収集部２４は、イベントドリブンのＩＴ管理システムにおける、イベントログを保存する一般的な機能と同様であり、その詳細は省略する。
なお、イベントメッセージキュー２２は、既存の一般的なイベントドリブンのＩＴ管理システムにおいて、イベントメッセージを受信する機能が一般的に持つ機能である。イベントメッセージキュー２２が受信したイベントメッセージの保持方法や、図示しない他の機能部がイベントメッセージキュー２２からイベントメッセージを取得する方法について、イベントメッセージキュー２２は何ら制限を課すものではない。イベントメッセージキュー２２は、受信したイベントメッセージを、メモリその他の一般的な記憶装置に、単に任意の並び順序で一時的に保存する。イベントメッセージキュー２２は、他の機能部がイベントメッセージキュー２２からイベントメッセージを取得する際には、少なくともイベントメッセージが発行された順番で取得することができるよう機能する。
本実施例では、イベントメッセージキュー２２は、図１に示したように監視対象制御システム２０において、管理ネットワーク１１を介して通知されたイベントメッセージの受け口に配置される。イベントメッセージキュー２２は、イベント処理システム２３ａ〜cの内部に配置することも可能である。より具体的には、後述する図３におけるイベントメッセージ保持部２３３ａの機能の一部として実現することも可能である。

監視システム３０から供給されるイベントメセージには、少なくとも、図２に示すように、それぞれのイベントメッセージを識別するイベントＩＤ５０が含まれている。図２では、一般的なイベントメッセージが保持する情報の例として、イベントＩＤ５０の他にイベント発行時刻５１及び状態遷移機器ＩＤ５２を示した。イベント発行時刻５１、状態遷移機器ＩＤ５２は、イベントＩＤ５０の一部として表現してもよい。また、イベント発行時刻５１の代わりに、イベントメッセージ発行順の通し番号であってもよい。さらに、付加的情報として、監視対象のＩＴ業務システム４０で動作している業務アプリケーションの識別子や、業務アプリケーションのイベントメッセージを発行するに至った原因となる処理の識別子を含んでもよい。イベントメッセージの形式は、既存の監視システム３０の実装により決定される。
イベントメッセージの例として、ＣＰＵ使用率監視イベントメッセージ、ディスク使用率監視イベントメッセージ、レスポンスタイム監視イベントメッセージその他監視システム３０の機能に応じたイベントメッセージが存在する。イベントＩＤ５０は、少なくともＣＰＵ使用率その他監視項目と、これに対応する上限７０％などの閾値その他監視対象値の組を、監視対象制御システム２０において一意に識別するものである。
イベントメッセージ供給部２１は、イベント処理システム２３ａ〜ｃのそれぞれに供給すべきイベントメッセージのＩＤを特定するためのテーブル（図８）を格納しており、当該テーブルに基づいて、イベントメッセージキュー２２から取得したイベントメッセージを、イベント処理システム２３ａ〜ｃのそれぞれに供給する。
図８は、イベントメッセージとイベント処理システム２３の対応を示す、イベントメッセージ供給部２１が保持しているイベントメッセージ供給テーブルの例である。イベント処理システム識別子８０１は、監視対象制御システム２０が備える複数のイベント処理システム２３を、監視対象制御システム２０内で識別するための識別子である。それらのイベント処理システム２３は、それぞれ監視対象に対する制御内容が異なるため、処理対象とするイベントＩＤが異なり、その対応を示すのが処理対象イベントＩＤ８０２である。例えば、イベント処理システム２３ａについては、処理対象イベントＩＤ８０２として、Ｍ−００１＿Ｏ、Ｍ−００１＿Ｒ、Ｍ−００２＿Ｏ、Ｍ−００２＿Ｒがあることがわかる。これに基づきイベントメッセージ供給部２１はイベントメッセージキュー２２内にあるイベントメッセージを対応するイベント処理システム２３ａに供給することができる。
これらイベントメッセージとイベント処理システム２３の対応を示す情報は、監視対象制御システム２０の利用者が、又は、外部の別のＩＴ管理システムが、規定する。監視対象制御システム２０が起動される前に、イベントメッセージ供給部２１に与えられればよい。なお、イベント処理システム２３とイベントＩＤの対応関係は、様々な場合があり得る。例えば、一つのイベントＩＤが複数のイベント処理システム２３の処理対象である場合も考えられる。その場合は、イベントメッセージ供給部２１にてイベントメッセージを複製し、それぞれのイベント処理システム２３に供給する。
図１２は監視対象制御システム２０のハードウェア構成例を示す図である。図示するように、本実施形態の監視対象制御システム２０は、ＣＰＵ１２０１と、メモリ１２０２と、ＨＤＤ等の外部記憶装置１２０３と、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭやＩＣカードなどの記憶媒体からデータを読み取る読取装置１２０４と、キーボードやマウスなどの入力装置１２０６と、モニタやプリンタなどの出力装置１２０７と、管理用ネットワーク１１に接続するための通信装置１２０８と、これらの各装置を接続するバス１２０９と、を備えた一般的なコンピュータにおいて、ＣＰＵ１２０１がメモリ１２０２上にロードされたプログラムを実行することで実現できる。このプログラムは、読取装置１２０４を介して記憶媒体から、あるいは、通信装置１２０８を介して管理用ネットワーク１１から、外部記憶装置１２０３にダウンロードされ、それから、メモリ１２０２上にロードされてＣＰＵ１２０１により実行されるようにしてもよい。あるいは外部記憶装置１２０３を経由せずに、メモリ１２０２上に直接ロードされ、ＣＰＵ１２０１により実行されるようにしてもよい。

図３は、イベント処理システム２３の詳細な機能構成の一例を示す。それぞれのイベント処理システム２３は、イベント対応表格納部２３０、イベントフィルタリング部２３１、イベント処理部２３２、およびイベントメッセージ保持部２３３を備える。

イベント対応表格納部２３０は、図４に示すように、イベントメッセージが発行される前のＩＴ業務システム４０の状態を識別する情報である発行前状態２３０１、および、イベントメッセージが発行された後のＩＴ業務システム４０の状態を識別する情報である発行後状態２３０２を、イベントメッセージを識別する情報であるイベントＩＤ２３００に対応付けて格納する。
図４の例では、イベントＩＤ２３００がＭ−００１＿Ｒであるイベントメッセージの発行前状態２３０１はＳ−００１、発行後状態２３０２はＳ−００２となっている。これはイベントメッセージＭ−００１＿Ｒを通知した監視システム３０のいずれかの監視部の監視対象について、その状態がＳ−００１からＳ−００２に遷移したことを示している。
これらの監視対象の状態を示す識別子は、図５で後述するように、監視対象の特定の監視項目について、監視閾値を設定することで監視対象の状態を複数、定義でき、それらに機械的に識別子を与えることで決めることができる。これら監視対象の状態を示す識別子も、イベントＩＤと同様、監視対象制御システム２０において一意に識別されるものであれば十分である。かかる識別子は、監視対象制御システム２０の利用者が、又は、外部の別のＩＴ管理システムが規定することができ、監視対象制御システム２０が起動される前にイベント対応表格納部２３０に与えられればよい。

イベントメッセージ保持部２３３は、イベントメッセージ供給部２１から供給されたイベントメッセージを、発行された順番に保持する。イベント処理部２３２は、イベントフィルタリング部２３１から供給されたイベントメッセージを処理することによりＩＴ業務システム４０を制御する。
例えば、イベント処理部２３２ａの機能が、業務アプリケーションが稼動するＷｅｂサーバのＣＰＵ使用率に応じて、負荷を分散するＷｅｂサーバの数を変更する機能であった場合には、ＷｅｂサーバのＣＰＵ使用率が予め定められた閾値を超えた旨を示すイベントメッセージが、イベントフィルタリング部２３１ａを介して、イベント処理部２３２ａに供給される。すると、供給されたイベントメッセージの情報を手がかりに、イベント処理部２３２ａが処理を実行する。
一般に、イベントメッセージには、そのイベントメッセージを発行したＷｅｂサーバや業務アプリケーションに関する情報が含まれるか、それらの情報を管理するデータベースから必要な情報を取得するために必要な識別子などが含まれている。これらの情報に基づき、未使用のＷｅｂサーバを特定し、場合によりそのサーバの追加の必要性を検証し、Ｗｅｂサーバの追加とロードバランサの設定変更を実行する。イベント処理部２３２が必要とする情報や、そこで実行される処理は、一般的なイベント処理機能のものと同様であり、詳細は省略する。

イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内のイベントメッセージおよびイベント対応表格納部２３０を参照し、イベントメッセージ保持部２３３内の最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態をイベント対応表格納部２３０から抽出する。そして、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内の２番目に古いイベントメッセージ以降のそれぞれについて、当該イベントメッセージが発行された後のＩＴ業務システム４０の状態をイベント対応表格納部２３０から抽出する。

そして、イベントフィルタリング部２３１は、イベントメッセージが発行された後のＩＴ業務システム４０の状態が、最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態と一致するイベントメッセージを、イベントメッセージ保持部２３３内で検索する。処理の詳細は、図６を用いて後述する。

イベントメッセージが発行された後のＩＴ業務システム４０の状態が、イベントメッセージ保持部２３３内の最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態と一致するイベントメッセージを検索できなかった場合、イベントフィルタリング部２３１は、当該最も古いイベントメッセージをイベント処理部２３２へ供給するイベントメッセージとして選択するイベント選択処理を実行する。そして、イベントフィルタリング部２３１は、イベント処理部２３２が処理中でない場合に、イベント選択処理において選択したイベントメッセージをイベント処理部２３２に供給する。

一方、イベントメッセージが発行された後のＩＴ業務システム４０の状態が、イベントメッセージ保持部２３３内の最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態と一致するイベントメッセージを検索できた場合、イベントフィルタリング部２３１は、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージをイベントメッセージ保持部２３３から削除する削除処理を実行する。イベントフィルタリング部２３１は、イベントメッセージがイベントメッセージ保持部２３３内に１個以下になるか、または上記のイベント選択処理を実行するまで、上記削除処理を繰り返し実行する。

以下に、図５および図６を参照しながら、イベントフィルタリング部２３１の処理を詳細に説明する。

例えば、図５に示すように、ＩＴ業務システム４０内のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の使用率が予め定められた閾値を上回ったり、下回ったりすることによって、ＩＴ業務システム４０の状態が遷移する場合について説明する。
サービスレベルに応じて業務アプリケーションに対して割り当てるリソース量を動的に制御するようなＩＴ管理システムの場合を考える。
例えば、負荷分散構成を取るＷｅｂサーバのＣＰＵ使用率を監視対象の一つとする。いずれかのＷｅｂサーバで、そのＣＰＵ使用率が上限７０％を超えると、ＩＴ管理システムは、そのＷｅｂサーバが高負荷状態に在ると判断する。そして、別のＷｅｂサーバを追加し、ロードバランサの設定を変更し、負荷を分散させ、当該Ｗｅｂサーバの負荷の低減を図る。逆に、いずれかのＷｅｂサーバで、そのＣＰＵ使用率が下限５０％を下回ると、ＩＴ管理システムは、そのＷｅｂサーバが低負荷状態に在ると判断する。そしてロードバランサの設定を変更し、負荷を縮退させ、余剰のＷｅｂサーバを切り離す。これにより、計算機リソースの有効活用を図ることができる。

図５に示す例では、ＣＰＵ使用率が７０％以上の状態であるＳ−００１から、ＣＰＵ使用率が５０％以上かつ７０％未満の状態であるＳ−００２の状態へ遷移した場合に、監視システム３０は、イベント６０を監視対象制御システム２０へ送信する。その後、ＩＴ業務システム４０の状態が、Ｓ−００２から、ＣＰＵ使用率が５０％未満の状態であるＳ−００３へ遷移した場合、監視システム３０は、イベント６１を監視対象制御システム２０へ送信する。

その後、ＩＴ業務システム４０の状態が、Ｓ−００２、Ｓ−００１、Ｓ−００２へと遷移する都度、監視システム３０は、イベント６２、イベント６３、イベント６４を監視対象制御システム２０へ送信する。
図９に、このときのイベントメッセージが、図２に示した形式で、イベントメッセージキュー２２に、一時的に保持された状態を示す。イベントメッセージキュー２２内で、イベントメッセージの並び順には、特に制限は無い。ここでは便宜上、イベント発行時刻順に並んでいる状態で示す。イベントメッセージキュー２２には、図５で示したＣＰＵ使用率に関するイベントメッセージに限らず、監視システム３０で監視可能な、複数の監視項目に関する各種イベントメッセージが蓄積されている。イベントメッセージ供給部２１は、図８で示したイベントメッセージ供給テーブルを参照して、このイベントメッセージキュー２２から、各イベント処理システム２３に、イベントメッセージを供給する。
サービスレベルに応じて、業務アプリケーションに対して割り当てる計算機リソース量を、動的に変更するようなＩＴ管理システムの場合で考える。簡単のため、ＣＰＵ利用率に関するイベントメッセージだけで考える。すると本実施例では、イベントメッセージが６０〜６４まで順番に、イベント処理システム２３へ到達することになる。
これらのイベントメッセージを本発明によらないで逐次処理した場合は、ＩＴ管理システムは、イベントメッセージ６０を受けて安定状態と判断した後、イベントメッセージ６１を受けて低負荷状態と判断してＷｅｂサーバを削減し、次いでイベントメッセージ６２を受けて安定状態と判断し、またイベントメッセージ６３を受けて高負荷状態と判断してＷｅｂサーバを追加し、イベントメッセージ６４を受けて安定状態を判断して一連の処理を終了することになる。
このように図５のような例で本発明を適用せずに、イベントメッセージを逐次、処理した場合には、一定の期間にＷｅｂサーバの削除と追加を連続して行う処理が発生し、ＩＴ管理システム全体では、処理の無駄が生じる。実際には、Ｗｅｂサーバの追加削減処理には、相当の移行時間（分単位から時間単位）を要するため、イベントメッセージの受信に、Ｗｅｂサーバの追加削減処理が間に合わず、管理対象（本実施例におけるＩＴ業務システム４０）の実態とＩＴ管理システム（本実施例における監視対象制御システム２０）で把握する状態に不整合が生じてしまうことになる。そこで、次に説明するイベント処理システム２３での処理が重要になる。

イベント処理部２３２が、前回供給されたイベントメッセージ（イベントメッセージ６０の前のイベントメッセージ）を処理している間に、ＩＴ業務システム４０の状態が図５に示したように遷移したと仮定すると、イベントメッセージ保持部２３３内には、例えば図６に示すように、イベント６０〜６４が格納される。図６に示す例では、説明を簡単にするために、それぞれのイベントメッセージは、発行された順でイベントメッセージ保持部２３３内に格納されているものと仮定している。なお、それぞれのイベントメッセージは、番号やタイムスタンプ等が付加されることにより発行された順番がわかるようにイベントメッセージ保持部２３３内に格納されていればよく、必ずしも発行された順番でイベントメッセージ保持部２３３内に格納されている必要はない。

次に、イベントフィルタリング部２３１は、イベント対応表格納部２３０を参照して、イベントメッセージ保持部２３３内の最も古いイベントメッセージ（図６ではイベント６０）の発行前状態６５を取得する。この状態Ｓ−００１は、イベント６０を発行する前の状態であり、図５ではＣＰＵ使用率が７０％を超えていた状態に相当する。つまり、前回供給されたイベントメッセージが到着した後の状態を意味している。そして、イベントフィルタリング部２３１は、イベント対応表格納部２３０を参照して、イベントメッセージ保持部２３３内の２番目に古いイベントメッセージ以降（図６の例ではイベント６１〜６４）について、当該イベントメッセージが発行された後のＩＴ業務システム４０の状態（図６の例では発行後状態６６〜６９）をそれぞれ取得する。

そして、イベントフィルタリング部２３１は、発行前状態６５と発行後状態６６〜６９とをそれぞれ比較する。図６に示す例では、イベントフィルタリング部２３１は、発行前状態６５と発行後状態６８との一致を検出し、発行前状態６５および発行後状態６６〜６８に対応するイベントメッセージ６０〜６３をイベントメッセージ保持部２３３から削除する。
ここで、イベントメッセージ６０〜６３を削除することの意味を、図５を用いて説明する。イベントメッセージ６０〜６３、それぞれの監視対象の状態は、Ｓ−００１からＳ−００２へ、Ｓ−００２からＳ−００３へ、Ｓ−００３からＳ−００２へ、Ｓ−００２からＳ−００１へ、Ｓ−００１からＳ−００２へと遷移する。現状（最終状態）はＳ−００２であることから、ＣＰＵ使用率の状態が、初期状態６５（イベントメッセージ６０発行前）のＳ−００１から最終状態のＳ−００２に、直接、遷移したものとして扱っても、イベント処理上は問題が無い。システムは、計算機リソースの不要な増減処理を行わずに済む。つまり途中の状態であるＳ−００２、Ｓ−００３、Ｓ−００２、Ｓ−００１への対処処理を省略できる。このことは、初期状態６５に続く４つの遷移状態に対応する４つのイベントメッセージ６０〜６３を、イベント処理部の処理対象から削除したことに等しい。
イベントメッセージ６０の発行後の状態は、Ｓ−００２である。これは一致不一致の検証に含めていない（図６）。この状態についての削除の可否は、イベントメッセージ６０を削除できるか否かに関係する。イベントメッセージ６０発行前のシステムの初期状態Ｓ−００１を、別途、検証することにより一義的に決まるため、イベントメッセージ６０を削除できるか否か、図６の検証で行う必要はない。また、イベントメッセージ６０の発行前後で、システムの状態は異なるのが通常であり、図６で、一致不一致の検証をする必要は無い。

その後、図６に示す例では、イベントメッセージ保持部２３３内に残っているイベントメッセージがイベントメッセージ６４の１個になるので、イベントフィルタリング部２３１はこれ以上のイベントメッセージの削除は不要と判断し、この残ったイベントメッセージ６４を、次回イベント処理部２３２へ供給するイベントメッセージとして選択する。なお、イベントメッセージを削除した後に、イベントメッセージ保持部２３３内に複数のイベントメッセージが残っている場合、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内の残りのイベントメッセージについて、イベントメッセージが発行された後のＩＴ業務システム４０の状態が、イベントメッセージ保持部２３３内の最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態と一致するイベントメッセージを検索する処理を再び実行する。

このように、ＩＴ業務システム４０の状態が遷移したことによってイベントメッセージが発行されたものの、そのイベントメッセージに対応する処理を実行するより前に、ＩＴ業務システム４０の状態が、そのイベントメッセージが発行される前の状態に既に遷移してしまった場合に、イベント処理システム２３は、その間に発行されたイベントメッセージに対応する処理を実行しない。これにより、イベント処理システム２３は、短時間に発行された多くのイベントメッセージを迅速に処理できると共に、それぞれのイベントメッセージに対応して実行すべきＩＴ業務システム４０の制御を確実に実行することができる。
サービスレベルに応じて、業務アプリケーションに対して割り当てる計算機リソースを動的に変更するようなＩＴ管理システムにおいては、イベントメッセージ６１やイベントメッセージ６３に対応した、無駄な対処処理を抑制できる。対処処理に長時間を要するＷｅｂサーバの不要な追加・削減処理を排除できる。

図７は、監視対象制御システム２０の動作の一例を示すフローチャートである。例えば、監視対象制御システム２０の稼動が開始することにより、監視対象制御システム２０は、本フローチャートに示す処理を開始する。なお、以下では、説明を簡単にするために、イベント処理システム２３が１つの場合について説明する。

まず、イベントメッセージ供給部２１は、イベントメッセージキュー２２内にイベントメセージが格納されているか否かを判定する（Ｓ１００）。イベントメッセージキュー２２内にイベントメッセージが格納されていない場合（Ｓ１００：Ｎｏ）、イベントフィルタリング部２３１は、ステップＳ１０２に示す処理を実行する。

イベントメッセージキュー２２内にイベントメッセージが格納されている場合（Ｓ１００：Ｙｅｓ）、イベントメッセージ供給部２１は、イベントメッセージキュー２２からイベントメッセージを取得し、取得したそれぞれのイベントメッセージのイベントＩＤを参照して、当該イベントメッセージを処理するイベント処理システム２３へ、当該イベントメッセージを、発行された順番に供給する。イベント処理システム２３内のイベントメッセージ保持部２３３は、イベントメッセージ供給部２１から供給されたイベントメッセージを、取得して保持する（Ｓ１０１）。

次に、イベントフィルタリング部２３１は、イベント処理部２３２がイベントメッセージの処理中であるか否かを判定する（Ｓ１０２）。イベント処理部２３２がイベントメッセージの処理中である場合（Ｓ１０２：Ｙｅｓ）、イベントメッセージ供給部２１は、再びステップＳ１００に示した処理を実行する。

イベント処理部２３２がイベントメッセージの処理中でない場合（Ｓ１０２：Ｎｏ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内に未処理のイベントメッセージが存在するか否かを判定する（Ｓ１０３）。未処理のイベントメッセージがイベントメッセージ保持部２３３内に存在しない場合（Ｓ１０３：Ｎｏ）、イベントメッセージ供給部２１は、再びステップＳ１００に示した処理を実行する。
なお、以上のＳ１００〜１０１のステップは、イベントメッセージキュー２２を有する実施例での処理ステップであり、その本質は、監視システム３０からのイベントメッセージの通知待ちの処理である。
イベントメッセージキュー２２を有しない実施例では、監視システム３０から監視対象制御システム２０にイベントメッセージの通知があると、イベントメッセージ供給部２１は、受信したイベントメッセージをイベント処理システム２３に供給し、Ｓ１００〜１０１のステップを省略して、Ｓ１０２のステップ以降を実行する。この方法の詳細は、管理対象制御システム２０がイベントメッセージを受信する処理の実装方法に依存する。
本発明は、イベントメッセージキュー２２の有無に拘わらず適用可能であり、その効果も同様に得られる。

未処理のイベントメッセージがイベントメッセージ保持部２３３内に存在する場合（Ｓ１０３：Ｙｅｓ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内の最も古いイベントメッセージの発行前状態をイベント対応表格納部２３０から取得する（Ｓ１０４）。そして、イベントフィルタリング部２３１は、２番目に古いイベントメッセージを選択し（Ｓ１０５）、選択したイベントメッセージの発行後状態をイベント対応表格納部２３０から取得する（Ｓ１０６）。Ｓ１０４の詳細フローを図１０に、Ｓ１０６の詳細を図１１に示す。
監視対象制御システム２０は、最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態を取得するステップ（図７、Ｓ１０４）で、イベントメッセージ保持部２３３から最も古いイベントメッセージを取得し（図１０、Ｓ１００１）、そのイベントメッセージからイベントＩＤを取得し（Ｓ１００２）、イベント対応表格納部２３０に格納されたイベント対応表（図４）から、取得したイベントＩＤに対応する発行後状態を取得する（Ｓ１００３）。
監視対象制御システム２０は、選択したイベントメッセージが発行された後のＩＴ業務システム４０の状態を取得するステップ（図７、Ｓ１０６）で、選択したイベントメッセージからイベントＩＤを取得し（図１１、Ｓ１１０１）、イベント対応表格納部２３０に格納されたイベント対応表（図４）から、取得したイベントＩＤに対応する発行後状態を取得する（Ｓ１１０２）。
監視対象制御システム２０は、ステップＳ１０４（図７）で、Ｍ−００１＿Ｒに対応するイベントメッセージ６０の発行前状態６５（図６）、つまりＳ−００１を取得し、ステップＳ１０５で、Ｍ−００２＿Ｒに対応する２番目に古いイベントメッセージ６１の発行後状態６６、つまりＳ−００３を取得する。

次に、イベントフィルタリング部２３１は、ステップＳ１０４において取得した発行前状態と、ステップＳ１０６において取得した発行後状態とが一致したか否かを判定する（Ｓ１０７）。ステップＳ１０４において取得した発行前状態と、ステップＳ１０６において取得した発行後状態とが一致した場合（Ｓ１０７：Ｙｅｓ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内の最も古いイベントメッセージ、発行後状態がステップＳ１０４で取得した発行前状態と一致したイベントメッセージ、およびこれらのイベントメセージの間に発行されたイベントメッセージを、イベントメッセージ保持部２３３から削除する（Ｓ１０８）。
ステップＳ１０４で取得したイベントメッセージ６０の発行前状態６５（図６）と、ステップＳ１０６で取得したイベントメッセージ６３の発行後状態６８とが、ステップＳ１０７の３度目の処理で一致し、この結果、ステップＳ１０７がＹｅｓとなり、イベントメッセージ６０〜６３を削除する（ステップＳ１０８）。

次に、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内に２個以上のイベントメッセージが残っているか否かを判定する（Ｓ１０９）。２個以上のイベントメッセーがイベントメッセージ保持部２３３内に残っている場合（Ｓ１０９：Ｙｅｓ）、イベントフィルタリング部２３１は、再びステップＳ１０４に示した処理を実行する。
図６の例では、ステップＳ１０８で、イベントメッセージ６０〜６３が削除され、イベントメッセージ保持部２３３に残存するのは、イベントメッセージ６４のみになった。もし、ステップＳ１０８の削除の結果、２以上のイベントメッセージが残存する場合は、Ｓ１０４からのステップを繰り返すことで、さらに削除できるイベントメッセージがないか、処理を繰り返す（Ｓ１０９）。

２個以上のイベントメッセーがイベントメッセージ保持部２３３内に残っていない場合（Ｓ１０９：Ｎｏ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内にイベントメッセージが残っているか否かを判定する（Ｓ１１０）。イベントメッセージ保持部２３３内にイベントメッセージが残っていない場合（Ｓ１１０：Ｎｏ）、イベントメッセージ供給部２１は、再びステップＳ１００に示した処理を実行する。イベントメッセージ保持部２３３内にイベントメッセージが残っている場合（Ｓ１１０：Ｙｅｓ）、イベントフィルタリング部２３１は、残っているイベントメッセージをイベント処理部２３２に供給し（Ｓ１１１）、イベントメッセージ供給部２１は、再びステップＳ１００に示した処理を実行する。
図６の例では、ステップＳ１０８で、イベントメッセージ６０〜６３が削除され、イベントメッセージ保持部２３３には、イベントメッセージ６４だけが残っている。このため、ステップＳ１０９：ＮｏかつステップＳ１１０：Ｙｅｓとなるので、ステップＳ１１１で、イベントフィルタリング部２３１は、イベントメッセージ６４をイベント処理部２３２に供給する。監視対象制御システム２０は、ステップＳ１１１までには必ずステップＳ１０９の検証を行うので、ステップＳ１１０：Ｙｅｓとなる場合に、イベントメッセージ保持部２３３に残存するイベントメッセージの数は、常に１つとなる。

ステップＳ１０４において取得した発行前状態と、ステップＳ１０６において取得した発行後状態とが一致しなかった場合（Ｓ１０７：Ｎｏ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内において、最も古いイベントメッセージ以外の全てのイベントメッセージについてステップＳ１０７の比較処理を実行したか否かを判定する（Ｓ１１２）。
図６の例では、ステップＳ１０４（図７）で取得した、最古のイベントメッセージ発行前のＩＴ業務システムの状態６５と、ステップＳ１０６で取得した、イベントメッセージ発行後の状態６６〜６７との比較がこれに相当する。最初のステップＳ１０６で取得される、イベントメッセージ６１発行後の状態６６はＳ−００３であり、これと最古のイベントメッセージ発行前の状態６５（Ｓ−００１）を比較すると一致せず、ステップＳ１０７がＮｏとなり、次のステップへと進む。

イベントメッセージ保持部２３３内において、最も古いイベントメッセージ以外の全てのイベントメッセージについてステップＳ１０７の比較処理を実行した場合（Ｓ１１２：Ｙｅｓ）、イベントフィルタリング部２３１は、イベントメッセージ保持部２３３内の最も古いイベントメッセージをイベント処理部２３２へ供給し（Ｓ１１３）、イベントメッセージ供給部２１は、再びステップＳ１００に示した処理を実行する。
つまり、最古のイベントメッセージ発行前の状態６５（図６、Ｓ−００１）と一致する、イベントメッセージ発行後の状態が見つからず（図７、Ｓ１０７、Ｎｏ）、全てのイベントメッセージについての処理が終了した（Ｓ１１２、Ｙｅｓ）ならば、監視対象制御システム２０は、最古のイベントメッセージ６０をイベント処理部２３２に供給する。

イベントメッセージ保持部２３３内において、最も古いイベントメッセージ以外の全てのイベントメッセージについてステップＳ１０７の比較処理を実行していない場合（Ｓ１１２：Ｎｏ）、イベントフィルタリング部２３１は、次のイベントメッセージを選択して（Ｓ１１４）、再びステップＳ１０６に示した処理を実行する。

上記説明から明らかなように、本実施形態のイベント処理システム２３によれば、イベントメッセージに対応した処理を確実に実行することができると共に、イベントメッセージの処理効率を向上させることができる。つまり、本発明をイベントドリブンのＩＴ管理システムに用いることで、管理対象の実態とＩＴ管理システムで把握する状態との間の不整合を防ぎ、不要な対処処理を回避することができる。
特に、サービスレベルに応じて、業務アプリケーションに対して割り当てる計算機リソースを動的に変更するようなＩＴ管理システムにおいては、計算機リソースの追加と削減を連続して実行するような、不要な、かつ、処理に長時間を要する対処処理を省略できる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記した実施の形態に記載の範囲には限定されない。また、上記した実施の形態に、多様な変更または改良を加えることが可能であることが当業者にとって明らかである。さらに、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明の一実施形態に係るサービス提供システム１０の構成を示す。 イベントメッセージに含まれる情報の一例を示す。 イベント処理システム２３の詳細な機能構成の一例を示す。 イベント対応表格納部２３０に格納されるデータの構造の一例を示す。 ＩＴ業務システム４０の状態の遷移により発行されるイベントメッセーの一例を説明するための概念図である。 イベントフィルタリング部２３１によってイベントメッセージが削除される過程を説明するための概念図である。 監視対象制御システム２０の動作の一例を示すフローチャートである。 イベントメッセージ供給部２１に格納されるデータの構造を例示する図である。 イベントメッセージキュー２２に、一時的に保持される情報を例示する図である。 イベントフィルタリング部２３１によってイベントメッセージが削除される過程のうち、最も古いイベントメッセージが発行される前のＩＴ業務システム４０の状態を取得する過程を説明するための概念図である。 イベントフィルタリング部２３１によってイベントメッセージが削除される過程のうち、選択したイベントメッセージが発行された後のＩＴ業務システム４０の状態を取得する過程を説明するための概念図である。 監視対象制御システム２０等のハードウェア構成例を示す図である。

符号の説明

１０・・・サービス提供システム、１１・・・管理ネットワーク、１２・・・業務ネットワーク、１３・・・情報通信機器、２０・・・監視対象制御システム、２１・・・イベントメッセージ供給部、２２・・・イベントメッセージキュー、２３・・・イベント処理システム、２３０・・・イベント対応表格納部、２３００、５０・・・イベントＩＤ、２３０１・・・発行前状態、２３０２・・・発行後状態、２３１・・・イベントフィルタリング部、２３２・・・イベント処理部、２３３・・・イベントメッセージ保持部、２４・・イベントログ収集部、３０・・・監視システム、３１・・・レスポンスタイム監視部、３２・・・ＣＰＵ使用率監視部、３３・・・ディスク使用率監視部、４０・・・ＩＴ業務システム、４１・・・ロードバランサ、４２、４３・・・Ｗｅｂサーバ、４４・・・ＤＢサーバ、５１・・・イベント発行時刻、５２・・・状態遷移機器ＩＤ、６０、６１、６２、６３、６４・・・イベント、６５・・・発行前状態、６６、６７、６８、６９・・・発行後状態。

Claims (15)

1. 監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理システムであって、
   前記監視システムによって発行されたイベントメッセージを保持して、発行された順に出力するイベントメッセージ保持手段と、
   前記イベントメッセージ保持手段から出力されたイベントメッセージを処理することにより、前記監視対象システムを制御するイベント処理手段と、
   前記イベントメッセージ保持手段内のイベントメッセージの中で、処理が必要なイベントメッセージを選択して前記イベント処理手段へ供給するイベントフィルタリング手段とを備え、
   前記イベントフィルタリング手段は、
   前記イベントメッセージ保持手段に保持されているイベントメッセージの中から、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するイベントメッセージを検索し、
   当該イベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージを、前記イベントメッセージ保持手段から削除するフィルタリング処理を実行すること
   を特徴とするイベント処理システム。
2. 請求項１に記載のイベント処理システムであって、
   前記イベントフィルタリング手段は、
   前記イベントメッセージ保持手段に保持されたｎ個のイベントメッセージについて、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するｋ（１＜ｋ≦ｎ）番目のイベントメッセージを検索できた場合、当該最も古いイベントメッセージからｋ番目のイベントメッセージまでを前記イベントメッセージ保持手段から削除し、前記イベントメッセージ保持手段内の残りのイベントメッセージについて、前記フィルタリング処理を再度実行すること
   を特徴とするイベント処理システム。
3. 請求項１または２に記載のイベント処理システムであって、
   前記イベントフィルタリング手段は、
   前記イベント処理手段による、前回供給されたイベントメッセージの処理が終了した場合に、前記フィルタリング処理を実行すること
   を特徴とするイベント処理システム。
4. 請求項１から３のいずれか１項に記載のイベント処理システムであって、
   前記イベントメッセージには、少なくともそれぞれのイベントメッセージを識別するイベント識別子が含まれ、
   前記イベント処理システムは、
   イベントメッセージが発行される前の前記対象システムの状態である発行前状態およびイベントメッセージが発行された後の前記対象システムの状態である発行後状態を、それぞれのイベントメッセージのイベント識別子に対応付けて格納するイベント対応表格納手段をさらに備え、
   前記イベントフィルタリング手段は、
   前記イベントメッセージ保持手段内のイベントメッセージに含まれるイベント識別子に基づいて前記イベント対応表格納手段を参照して、イベントメッセージが発行される前の前記監視対象システムの状態、および、イベントメッセージが発行された後の前記監視対象システムの状態を取得することを特徴とするイベント処理システム。
5. 監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理システムにおけるイベント処理方法であって、
   前記イベント処理システムが、
   前記監視システムによって発行されたイベントメッセージをイベントメッセージ保持手段に保持するステップと、
   前記イベントメッセージ保持手段に保持されているイベントメッセージの中から、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するイベントメッセージを検索するステップと、
   当該イベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該検索できたイベントメッセージまでの各イベントメッセージを、前記イベントメッセージ保持手段から削除するステップと
   を実行することを特徴とするイベント処理方法。
6. 監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理システムにおけるイベント処理方法であって、
   前記イベント処理システムが、
   前記監視システムによって発行されたイベントメッセージをイベントメッセージ保持手段に保持する第１のステップと、
   前記イベントメッセージ保持手段に保持されたｎ個のイベントメッセージについて、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持手段に格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するｋ（１＜ｋ≦ｎ）番目のイベントメッセージを検索する第２のステップと、
   第２のステップでｋ番目のイベントメッセージを検索できた場合に、前記最も古いイベントメッセージから当該ｋ番目のイベントメッセージまでを、前記イベントメッセージ保持手段から削除する第３のステップと、
   前記イベントメッセージ保持手段内の残りのイベントメッセージについて、前記第１のステップないし第３のステップを繰り返す第４のステップと、
   を実行することを特徴とするイベント処理方法。
7. 請求項６に記載のイベント処理方法あって、
   第３のステップないし第４のステップで、前記最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するイベントメッセージが検索されなかった場合には、前記イベントメッセージ保持手段内の残りのイベントメッセージのうち、最も古いイベントメッセージに応じて、前記監視対象システムを制御する第５のステップと、
   を実行するイベント処理方法。
8. 監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理装置であって、
   前記監視システムによって発行されたイベントメッセージを保持して、発行された順に出力するイベントメッセージ保持部と、
   前記イベントメッセージ保持部から出力されたイベントメッセージを処理することにより、前記監視対象システムを制御するイベント処理部と、
   前記イベントメッセージ保持部のイベントメッセージの中で、処理が必要なイベントメッセージを選択して前記イベント処理部へ供給するイベントフィルタリング部とを備え、
   前記イベントフィルタリング部は、
   前記イベントメッセージ保持部に保持されたｎ個のイベントメッセージについて、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持部に格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するｋ（１＜ｋ≦ｎ）番目のイベントメッセージを検索し、
   当該ｋ番目のイベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該ｋ番目のイベントメッセージまでを前記イベントメッセージ保持部から削除するフィルタリング処理を実行すること
   を特徴とするイベント処理装置。
9. 請求項８に記載のイベント処理装置であって、
   前記イベントフィルタリング部は、
   前回のフィルタリング処理の終了後、前記イベントメッセージ保持部にイベントメッセージが残っている場合、当該残っているイベントメッセージについて、前記フィルタリング処理を繰り返し実行すること
   を特徴とするイベント処理装置。
10. 請求項８に記載のイベント処理装置であって、
    前記イベントフィルタリング部は、
    前記最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するイベントメッセージが検索されなかった場合には、前記フィルタリング処理を終了し、
    前記イベントメッセージ保持部に残っているイベントメッセージのうち、最も古いイベントメッセージを前記イベント処理部に供給すること
    を特徴とするイベント処理装置。
11. 請求項８に記載のイベント処理装置であって、
    前記イベントフィルタリング部は、
    前記イベント処理部により、前回、供給されたイベントメッセージの処理が終了した場合に、前記イベントメッセージ保持部にイベントメッセージが１つ残っているときは、当該残っているイベントメッセージについて、前記フィルタリング処理を実行すること
    を特徴とするイベント処理装置。
12. 監視対象システムの状態が遷移する都度、その遷移内容を特定するイベントメッセージを監視システムから受信し、受信したイベントメッセージに応じて当該監視対象システムを制御するイベント処理装置を動作させる、イベント処理プログラムであって、
    前記監視システムによって発行されたイベントメッセージを保持して、発行された順に出力するイベントメッセージ保持モジュールと、
    前記イベントメッセージ保持モジュールから出力されたイベントメッセージを処理することにより、前記監視対象システムを制御するイベント処理モジュールと、
    前記イベントメッセージ保持モジュールのイベントメッセージの中で、処理が必要なイベントメッセージを選択して前記イベント処理モジュールへ供給するイベントフィルタリングモジュールとを備え、
    前記イベントフィルタリングモジュールは、
    前記イベントメッセージ保持モジュールに保持されたｎ個のイベントメッセージについて、イベントメッセージが発行された後の前記監視対象システムの状態が、前記イベントメッセージ保持モジュールに格納されている、最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するｋ（１＜ｋ≦ｎ）番目のイベントメッセージを検索し、
    当該ｋ番目のイベントメッセージを検索できた場合に、当該最も古いイベントメッセージから当該ｋ番目のイベントメッセージまでを前記イベントメッセージ保持モジュールから削除するフィルタリング処理を実行すること
    を特徴とするイベント処理プログラム。
13. 請求項１２に記載のイベント処理プログラムであって、
    前記イベントフィルタリングモジュールは、
    前回のフィルタリング処理の終了後、前記イベントメッセージ保持モジュールにイベントメッセージが残っている場合、当該残っているイベントメッセージについて、前記フィルタリング処理を繰り返し実行すること
    を特徴とするイベント処理プログラム。
14. 請求項１２に記載のイベント処理プログラムであって、
    前記イベントフィルタリングモジュールは、
    前記最も古いイベントメッセージが発行される前の前記監視対象システムの状態と一致するイベントメッセージが検索されなかった場合には、前記フィルタリング処理を終了し、
    前記イベントメッセージ保持モジュールに残っているイベントメッセージのうち、最も古いイベントメッセージを前記イベント処理モジュールに供給すること
    を特徴とするイベント処理プログラム。
15. 請求項１２に記載のイベント処理プログラムであって、
    前記イベントフィルタリングモジュールは、
    前記イベント処理モジュールにより、前回、供給されたイベントメッセージの処理が終了した場合に、前記イベントメッセージ保持モジュールにイベントメッセージが１つ残っているときは、当該残っているイベントメッセージについて、前記フィルタリング処理を実行すること
    を特徴とするイベント処理プログラム。
    

Images