JP4120371B2

JP4120371B2 - 運用管理システム、管理計算機、監視対象計算機、運用管理方法及びプログラム

Info

Publication number: JP4120371B2
Application number: JP2002344811A
Authority: JP
Inventors: 裕教江丸; 平田　　俊明
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-11-28
Filing date: 2002-11-28
Publication date: 2008-07-16
Anticipated expiration: 2022-11-28
Also published as: US7680921B2; US20040107278A1; JP2004178336A

Description

【０００１】
【発明の属する技術分野】
本発明は、運用管理システムにおいて稼動データを採取し、障害解析を実施する技術に関する。特に、発生するイベントに応じて、障害解析に必要な稼動データを特定する技術に関する。
【０００２】
【従来の技術】
一般に、運用管理ツールが扱うデータには、稼動データと、イベントとがある。
【０００３】
稼動データとは、採取する監視ポイント、監視する時間などを決めて、監視対象から採取するデータをいい、イベントとは、監視対象において障害が発生、性能が低下などの事象が発生したときに、その事象の発生を管理装置へ通知するために使用されるデータをいう。
【０００４】
従来技術では、採取した稼動データは、テキストやデータベースといった形式で永続的な２次記憶装置に保存することにより、稼動情報を時系列に集約して蓄積する技術がある（例えば、特許文献１）。また、イベントが発生したことをあらかじめ登録しておいたメールアドレスにメールすることにより、イベントの発生に伴い、自動的にあらかじめ登録しておいた処理を行う技術もある（例えば、特許文献２）。
【０００５】
【特許文献１】
特開平５−１３４９０２号公報
【特許文献２】
特開平１１−４５１９５号公報
【０００６】
【発明が解決しようとする課題】
従来技術では、稼動データとイベントとが別々に保存されるものである。従って、どの時刻に障害が発生したかを知るためには、個々にイベントのログを見なければならなかった。また、そのイベントが稼動データにどのように現れているのかのマッピングをとるのが困難であった。さらに、障害解析を行う場合、稼動データの大部分は定常時のデータであるが故に、大量の稼動データから少数の障害時のデータを抽出する作業を行わなくてはならなかった。
【０００７】
一方、稼動データは、定期的に採取しておかなくてはならないため、それらを格納しておくために大容量のファイル装置を必要としていた。
【０００８】
本発明の目的は、運用管理システムにおいて、必要な記憶装置容量の資源を抑えつつ、障害解析に必要なデータを効率的に抽出することである。
【０００９】
【課題を解決するための手段】
本発明の一実施形態の運用管理システムは、管理計算機と、管理計算機により管理される監視対象計算機とを有する。ここで、管理計算機は、監視対象計算機内部の監視対象の稼動データを受信する通信装置と、稼動データと前記監視対象の障害発生又は性能低下を示すためのイベントに関する情報とに基づいて、障害解析に必要な前記稼動データを特定し、障害解析を実施するプロセッサとを有する。
【００１０】
また、上述した実施形態において、監視対象計算機は、装置内部の監視対象から稼動データを取得し、稼動データが所定の基準を満たすことを示すためのイベントに関する情報を発生させるプロセッサと、稼動データと前記イベントに関する情報とに基づいて、障害解析に必要な前記稼動データを特定し、特定した稼動データを前記管理計算機へ送信する通信装置とを有するようにしてもよい。
【００１１】
また、上記実施形態において、イベントに関する情報には、イベントの発生の有無を示す情報、イベントを発生させた監視対象計算機が前記稼動データを採取した計算機かどうかを示すホスト情報、イベントの発生時刻を示す情報のうち少なくとも１つを含むようにしてもよい。
【００１２】
また、上記実施形態において、管理計算機は、さらに、格納バッファと、データ格納部とを有してもよい。ここで、管理計算機のプロセッサは、監視対象計算機からの稼動データを前記格納バッファに格納し、イベントに関する情報を受けたときに、格納バッファに、イベントに関する情報の全部あるいは一部を格納バッファに格納された稼動データに関連付けて格納し、稼動データとイベントに関する情報とを、格納バッファから前記データ格納部へ書き込むようにしてもよい。ここで、管理計算機のプロセッサは、別の実施例として、イベントに関する情報に基づいて、格納バッファからデータ格納部へ書き込む稼動データを決定し、特定された稼動データを前記データ格納部へ書き込み、稼動データに基づいて障害解析を実施するようにしてもよい。
【００１３】
【発明の実施の形態】
（１）第１の実施形態
図１は、本実施形態の稼動データ収集方法を実現する計算機システムの構成図である。
【００１４】
本計算機システムは、収集した稼動データ及びイベントの処理ならびに２次記憶装置への永続化を行うプログラムである計算モジュール１１０１を搭載する計算機１２０３、稼動データ、イベントを取得する対象である監視対象を実行する計算機１２０１、１２０２、及び計算機間を接続するＬＡＮ１２１０からなる。
【００１５】
計算機１２０１は、監視対象を含む対象計算機であって、記憶装置１５０１、ＣＰＵ１５０２、メモリ１５０３、表示装置１５０４、キーボード、マウスなどの入力装置１５０５及びLAN１２１０に接続するための通信装置１５０６を有する。これら構成はバスによって接続される。
【００１６】
記憶装置には、監視対象であるプログラム１００１、１００２とイベント発生モジュールとして機能するプログラム１１０２および稼動データ採取モジュールとして機能するプログラム１１０４が格納されている。ＣＰＵは、記憶装置からメモリにロードしたプログラムを実行する。表示部は、監視対象のプログラムの実行結果を表示する。入力装置は、監視対象のプログラムに対して指示するための入力データを受付ける。
【００１７】
本実施形態では、監視の対象となる計算機は２台であるが、その台数に制限はない。
【００１８】
イベント発生モジュール１１０２、１１０３は、監視対象を監視し、定められた条件にしたがってイベントを発生させ、ＬＡＮ１２１０を介して計算モジュール１１０１へと転送するプログラムである。イベント発生条件の例として、監視対象における障害の発生や、レスポンス時間、メモリ量など監視している値の閾値のオーバなどが挙げられる。
【００１９】
稼動データ採取モジュール１１０４、１１０５は、監視対象を監視し、計算モジュール１１０１から指示を受け、必要に応じて稼動データの採取を行い、採取した稼動データをＬＡＮ１２１０を介して計算モジュール１１０１へと転送するプログラムである。
【００２０】
監視対象１００１〜１００３は、障害の発生や、レスポンス時間、メモリ量などを監視される対象をいう。なお、本実施形態の図では、監視対象としてプログラムの例であるが、メモリ、入力装置、通信装置、ＣＰＵ、表示装置等の計算機を構成するハードウェアも監視対象とすることが可能である。
【００２１】
また、計算機１２０１の代わりに記憶装置（たとえば、ＲＡＩＤ装置等）をネットワーク（ＳＡＮ）を介して計算機１２０３により管理する場合、記憶装置の特性（たとえば、記憶領域の性能特性等）を本実施形態の稼動データとしてもよい。ＲＡＩＤ装置１２０４はこの例であって、記憶装置１８０１、ＲＡＩＤコントローラ１０８２、ＲＯＭ１８１０及びＳＡＮ１２２０に接続するための通信装置１８０６を有する。これら構成はバスによって接続される。ＲＯＭ１８１０には、イベント発生モジュールとして機能するプログラム１１０９および稼動データ採取モジュールとして機能するプログラム１１０８が格納されている。ＲＡＩＤコントローラ１８０２は、記憶装置からメモリにロードしたプログラムの実行及びＲＡＩＤ装置の制御を行う。なお、稼動データ取得手段１１０８及びイベント発生手段１１０９は記憶装置１８０１に配置されていても本発明の実施は可能である。
【００２２】
計算機１２０３は、対象計算機１２０１、１２０２を監視する監視計算機であって、記憶装置１７０１、ＣＰＵ１７０２、メモリ１７０３、表示装置１７０４、キーボード、マウスなどの入力装置１７０５及びＬＡＮ１２１０に接続するための通信装置１７０６を有する。これら構成はバスによって接続される。
【００２３】
記憶装置には、計算モジュールとして機能するプログラム１１０１およびデータ格納領域１７１０が格納されている。ＣＰＵは、記憶部からメモリにロードした計算モジュール１１０１を実行する。格納バッファ１７０６及びデータ格納領域１７１０には、ＣＰＵにより稼動データが保存される。メモリの格納バッファには、一定個数の稼動データを一時的に時系列順にバッファリングした後、一定個数ごとに記憶装置のデータ格納領域に格納される。表示装置１３０１は、障害解析を行うために必要な情報を出力する。記憶装置１７０１は、障害解析に必要な稼動データを格納する。入力装置は、計算モジュールに対する指示を行うために、管理者からの入力値を受付ける。
【００２５】
また、計算モジュール１１０１、イベント発生モジュール１１０２、１１０３、及び稼動データ採取モジュール１１０４、１１０５は、計算機１２０１、１２０２、１２０３により読み取り可能なプログラムとして格納する記憶媒体を作成してもよい。各々の計算機に配置されるプログラム部分である計算モジュール１１０１、イベント発生モジュール１１０２、１１０３、及び稼動データ採取モジュール１１０４、１１０５は、他の計算機等からネットワークを経由して計算機１２０１、１２０２、１２０３の記憶装置へ転送し、その計算機のメモリにロードしてその計算機のＣＰＵによって実行することが出来る。
【００２６】
図２は、第１の実施形態の計算モジュール１１０１の処理の概略手順を示す図である。
【００２７】
ステップ２１０５において、計算モジュール１１０１は、稼動データ採取モジュールから稼動データを取得する。
【００２８】
ステップ２１１０において、取得した稼動データを、格納バッファに１１０６に格納する。
【００２９】
ステップ２１１５において、計算モジュール１１０１は、イベント発生モジュールからのイベントの到着の有無をチェックする。
【００３０】
ステップ２１２０において、ステップ２１１５においてイベントが到着していない場合、計算機モジュール１１０１は、格納バッファが全て稼動データで満たされているかをチェックする。
【００３１】
格納バッファに空きがある場合、ステップ２１２０において、ステップ２１０５に戻る。
【００３２】
格納バッファが全て稼動データで満たされている場合、ステップ２１２５において、計算モジュール１１０１は、格納バッファ内に格納されている全ての稼動データを記憶装置１７０１のデータ格納領域１７１０に格納する。
【００３３】
ステップ２１１５においてイベントが到着している場合、ステップ２１３０において、計算モジュール１１０１は、格納バッファ内に格納されている稼動データにイベント種別の付与を行う。ここで、イベント種別を付与する稼動データは、格納バッファに格納されている全ての稼動データであってもよいが、障害解析を行うために必要な範囲であればよい。
【００３４】
ステップ２１３５において、計算モジュール１１０１は、イベント種別の付与した稼動データを記憶装置１７０１のデータ格納領域１７１０に格納する。
【００３５】
ステップ２１４０において、計算モジュール１１０１は、ステップ２１２５、２１３５において稼動データを記憶装置に格納した後、格納バッファに格納されている稼動データを消去することにより、格納バッファの初期化を行う。ここで、格納バッファから消去する格納データは、全部であってもよいし、後述するようにその一部であってもよい。
【００３６】
ステップ２１４５において、計算モジュール１１０１は、入力装置からの稼動データ収集停止指示があるか否かをチェックする。停止指示があれば終了し、なければステップ２１０５に戻る。
【００３７】
図３は、計算機１２０３のメモリ上の稼動データを格納するためのバッファの構成図である。
【００３８】
格納バッファ３１００は、３００１から３００６までの６つの稼動データフィールドから構成される。計算モジュールは、稼動データ採取モジュールから取得した稼動データを、稼動データフィールドに格納する。なお、図３では格納バッファを構成する稼動データフィールドの数は６個であるが、この個数は６個に限定されない。
【００３９】
図４は、格納バッファ３１００を構成する稼動データフィールドの構成図である。
【００４０】
稼動データフィールド４１００は、時刻フィールド４００１、ホストフィールド４００２、稼動データ送出元フィールド４００３、性能データフィールド４００４、およびイベントフィールド４００５とを有する。
【００４１】
時刻フィールド４００１には、取得した稼動データの取得時刻が格納される。
【００４２】
ホストフィールド４００２には、取得した稼動データを発生させたホスト計算機１２０１、１２０２のＩＤが格納される。なお、ホストフィールド４００２には、監視対象単位、プロセス単位でそのＩＤを格納してもよい。
【００４３】
稼動データ送出元フィールド４００３には、取得した稼動データがどこから得られたものであるかを表す値が格納される。例えば、稼動データがプロセスより得られたものである場合、このフィールドにはプロセス名もしくはプロセスＩＤが格納される。
【００４４】
性能データフィールド４００４には、稼動データ採取モジュールから取得した稼動データが格納される。ここで、稼動データとは、「システムの使われ方」「システムの特性」「プログラムの特性」などを複合的に反映したデータであって、たとえばメモリ使用量、ＣＰＵ使用時間、レスポンスタイムといった稼動情報を表す値がある。従って、複数の稼動データに基づいて、監視対象の特性が明らかになる場合もある。たとえば、監視対象をプログラムとした場合、リクエストをスレッドが処理するアプリケーションサーバでは、リクエストごとにスレッドを生成していたのではコストがかかるため、一般にスレッドをプールして利用する。ここで、1) レスポンスタイムと 2) スレッドの生成/消失を稼動データとして採取することにより、レスポンスタイムが遅く、かつリクエストごとにスレッドの生成/消失が行われているようであれば、そのプログラムはコネクションプーリングを使用していないことから、コネクションの生成効率の悪いプログラムであるといったとプログラムの特性が明らかになる。
【００４５】
イベントフィールド４００５には、計算モジュール１１０１がイベント発生モジュールから受け取ったイベントの種別を格納する。即ち、図２のステップ２１３５において説明したように、計算モジュール１１０１は、稼動データ格納バッファに格納されている稼動データのイベントフィールドに、イベント発生モジュールから受け取ったイベントのイベント種別を書き込んだ後に、稼動データの記憶装置への格納を行う。ここで、イベントとは、メモリ使用量、ＣＰＵ使用時間、レスポンスタイム等の稼動データが所定の基準を満たした場合に、発生する情報であって、たとえば、障害発生、ＣＰＵの性能低下、メモリ不足等がある。
【００４６】
なお、本実施形態では、イベントフィールドは、必ずしも格納バッファ上に配置しなくてもよい。この場合、稼動データが記憶装置に格納されるときに、イベントフィールドにイベントの種別を付与するようにしてもよい。即ち、図２のステップ２１２５および２１３５において、計算モジュールは、稼動データを記憶装置に格納するときに、データ格納領域に稼動データフィールドを設け、ステップ２１３５において、稼動データに対応するイベントフィールドにイベントの種類を付与する。ステップ２１２５もしくはステップ２１３５の処理により、記憶装置１７０１には、イベントが発生時に稼動データ格納バッファに格納されていた稼動データのイベントフィールドに、稼動データに対応するイベント種別が格納される。
【００４７】
また、計算モジュール１１０１は、イベント発生後の一定期間の稼動データのみを稼動データ採取モジュールから取得し、格納バッファに格納するようにしてもよい。
【００４８】
以上本実施形態により、記憶装置１７０１に格納されている稼動データを利用して障害解析を行う場合、以下のような効果が得られる。
【００４９】
解析すべき稼動データは、稼動データの中からイベントフィールドにイベント種別が書き込まれたものに限定することができるため、障害解析のオーバヘッドが軽減することができる。また、解析すべき稼動データを、特定のイベントの種別に対応するものに限定することにより、更に、障害解析のオーバヘッドが軽減することができる。
（２）第２の実施形態
第１の実施形態では、１つのイベントに対してイベント種別が付与される稼動データの数が、０から格納バッファの個数の間で可変であり、その個数はイベント発生モジュールがイベントを発生させるタイミングによって決定される。したがって、稼動データを記憶装置に格納した直後にイベントが発生すると、そのイベント種別が付与される稼動データは１つしかないことになる。このように実施の形態１には、イベント種別が付与される稼動データの数が１から格納バッファの個数の間で可変であり、その数がタイミング次第であるという問題点がある。
【００５０】
本実施形態では、その欠点を補うため、稼動データ格納バッファを論理的に２分割することにより、イベント種別が付与される稼動データの数が一定個数以上になるようにする。以下に、図１で示される計算機システムにおける実施の形態から、図２に示される計算モジュールの処理の概略手順を用いて、本発明の特徴を説明する。
【００５１】
ステップ２１１５までは実施の形態１と同様である。
【００５２】
ステップ２１２５において、ステップ２１２０において格納バッファが全て稼動データで満たされている場合、計算モジュール１１０１は、稼動データを記憶装置へと格納するが、この際、全ての稼動データを記憶装置へと格納するのではなく、格納バッファの一部の稼動データのみを記憶装置へと格納し、残りの稼動データはメモリに保持したままとする。なお、実施の形態１で述べたとおり、格納バッファには時系列に稼動データが収められるものとし、古い稼動データから順に記憶装置へと格納し、メモリに残すデータは新しいものから順に残るようにする。
【００５３】
引き続いて実行されるステップ２１４０において、計算モジュール１１０１は、記憶装置に格納された稼動データを消去し、それ以外のメモリ上に残された稼動データを配置し直す。
【００５４】
ステップ２１１５において、イベントがあった場合の処理は、上記した実施形態１と同様であり、ステップ２１４０において、全ての稼動データをメモリ上から消去する。
【００５５】
図５は、本実施形態における計算機１２０３のメモリ上に確保された稼動データ格納バッファを表す図である。
【００５６】
格納バッファ５１００は、５００１から５００６までの６つの稼動データフィールドから構成される。稼動データ採取モジュールから取得した１つの稼動データが、１つの稼動データフィールドに収められる。なお、図５では格納バッファを構成する稼動データフィールドの数は６個であるが、この個数は６個に限定されない。
【００５７】
ここで、稼動データ格納バッファを３つずつに２分割する。５００１から５００３までの３つの稼動データ格納フィールド５２００を格納対象フィールドと呼ぶ。なお、稼動データ格納フィールドを、２分割３つを１グループとして格納対象フィールドとしているが、格納対象フィールドを構成する稼動データ格納フィールドの数及び分割数はこれらに限定されない。
【００５８】
図５のケースでは、格納バッファ５１００の全てのバッファに稼動データが入っているため、ステップ２１２５において稼動データの記憶装置への格納を行うが、格納対象フィールドである５００１から５００３まで３つの稼動データのみを記憶装置に格納し、残りの５００４から５００６に格納されている稼動データは、ステップ２１４０において格納バッファ５００１から５００３までに配置しなおす。該処理を行った後の稼動データフィールドが図６の６１００である。こうすることにより、イベントが発生した際に格納バッファ内に最低でも４つの稼動データが入っていることになる。
【００５９】
なお、本実施の形態を持ってしても、イベントが連続して発生するようなケースでは、２回目以降のイベントに対しは一定個数以上のデータにイベント種別が付与されることは保証されない。その場合には、格納バッファをＮ分割することによって、連続するＮ回までのイベントに対応することが可能である。ただし、同時に多イベントが発生する場合、一般にそれらのイベントは同一の障害に基づくものと考えられるため、格納バッファを２分割することで実用上は充分であろう。
（３）第３の実施形態
第１の実施形態、第２の実施形態では、イベントの発生有無に関わらず全ての稼動データが記憶装置に格納される。収集した稼動データの用途として、障害解析やキャパシティプランニングなどが考えられるが、稼動データの用途が障害解析だけにある場合、イベントと関連付けられない稼動データは不要である。そこで、本実施の形態では、障害解析には必要のない稼動データを記憶装置に格納しないことにより、障害解析の効率向上と、記憶装置容量の削減を実現する。
【００６０】
図７は、本実施形態における計算モジュールの処理の概略手順を説明する。
【００６１】
図７に示される計算モジュールの処理の概略手順７００１と、図２に示される計算モジュールの処理の概略手順２００１との違いは、格納バッファがすべて稼動データで満たされているときに、それらの稼動データを記憶装置へ格納するステップ２１２５の有無のみである。すなわち、稼動データ採取モジュールが採取した稼動データは、計算モジュール１１０１によって格納バッファに一時的に収められるが、格納バッファが満たされるまでの間にイベントが発生しなければ、記憶装置１７０１に格納することなく消去する。こうすることにより、記憶装置１７０１に格納される稼動データは、イベントフィールドにイベントが設定されたもののみとなる。なお、特に特定のイベントの種類に関する稼動データのみを格納するようにしてもよい。
【００６２】
本実施形態により、イベントと関連付けられた稼動データのみを、記憶装置に格納することが可能となり、障害解析の効率向上と、記憶装置容量の削減が実現される。
（４）第４の実施形態
第３の実施形態では、イベントが発生した際に、格納バッファに格納されている全ての稼動データのイベントフィールドに該イベントのイベント種別を書き込む。しかし、障害解析を行う際には、イベントの発生元である計算機から収集した稼動データのみが必要であるというケースも少なくない。そこで本実施の形態では、イベント発生時に該イベントのイベント種別を書き込み、記憶装置へと格納する稼動データを、イベントの発生元である計算機から収集した稼動データに限定することによって、障害解析の効率向上を実現する。
【００６３】
図８は、本実施形態における計算モジュールの処理の概略手順を説明する。
【００６４】
図８に示される計算モジュールの処理の概略手順８００１と、図７に示される計算モジュールの処理の概略手順７００１との違いは、計算モジュール１１０１が格納バッファに格納されている稼動データのイベントフィールドへのイベント種別設定を行うステップ８１３０と、計算モジュール１１０１が格納バッファに格納されている稼動データの記憶装置への永続化を行うステップ８１３５である。
【００６５】
ステップ８１３０では、計算モジュール１１０１がイベントの送信元ホストと、格納バッファに格納されている稼動データの稼動データ送出元フィールドとを比較し、この２つが同じであれば、稼動データはイベント送信元ホストと同じホストから収集された稼動データであることがわかるため、稼動データのイベントフィールドに対し、イベントのイベント種別を書き込む。異なるホストであれば、何も行わない。ステップ８１３５では、計算モジュール１１０１が格納バッファに格納されている稼動データの中から、イベントフィールドにイベント種別が書き込まれたもののみを選択し、記憶装置への格納を行う。他のステップにおける処理は図７に示される計算モジュールの処理の概略手順７００１と同様である。
【００６６】
本実施の形態により、記憶装置に格納する稼動データを、イベント発生時にイベントの発生元である計算機から収集した稼動データに限定することが可能となり、障害解析の効率向上と、記憶装置容量の削減が実現される。
【００６７】
なお、本実施の形態で示した、イベント発生時に、イベント種別を書き込む稼動データをイベントの発生元である計算機から収集した稼動データに限定する方法を、実施の形態１に適用することも可能である。この場合、全ての稼動データが記憶装置に格納されるが、その中でイベントフィールドにイベント種別が書き込まれるのは、格納バッファに収められているときに、イベントが発生し、そのイベントのイベント送信元ホストと同じホストから収集された稼動データに限定される。これにより、障害解析の効率向上が実現される。
【００６８】
【発明の効果】
本発明によれば、運用管理システムにおいて、必要な記憶装置容量の資源を抑えつつ、障害解析に必要なデータを効率的に抽出することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１におけるシステムの構成図である。
【図２】本発明の実施の形態１における計算モジュールの全体フロー図である。
【図３】本発明の実施の形態１における稼動データ格納バッファの具体例である。
【図４】本発明の実施の形態１における稼動データフィールドの具体例である。
【図５】本発明の実施の形態２における稼動データ格納バッファの具体例である。
【図６】本発明の実施の形態２における稼動データ格納バッファの具体例である。
【図７】本発明の実施の形態３における計算モジュールの全体フロー図である。
【図８】本発明の実施の形態４における計算モジュールの全体フロー図である。
【符号の説明】
１００１〜１００３…監視対象、１２０１〜１２０３…計算機、１１０１…計算モジュール、１１０２〜１１０３…イベント発生モジュール、１１０４〜１１０５…稼動データ採取モジュール、１２１０…ＬＡＮ

Claims

管理計算機と、前記管理計算機にネットワークを介して接続され、前記管理計算機により管理される監視対象計算機とを有する運用管理システムであって、
前記監視対象計算機は、
前記監視対象計算機内部の監視対象と、
前記監視対象の稼動データを定期的に採取する手段と、
前記稼動データが定められた条件を満足した場合に発生する情報であるイベントを発生する手段と、および、
前記定期的に採取した稼動データと前記発生手段が発生したイベントとを前記管理計算機へ前記ネットワークを介して通信する通信装置と、を有し、
前記管理計算機は、
複数の稼動データを時系列に格納し、且つ２分割されているメモリである格納バッファと、
前記監視対象計算機の通信装置から前記定期的に採取された稼動データを受信し、また、前記発生したイベントを受信する前記管理計算機の通信装置と、
前記管理計算機の通信装置により前記定期的に採取された稼動データを受信した場合、前記受信した前記稼動データを前記格納バッファに格納する手段と、
データを格納する記憶装置と、
前記管理計算機の通信装置により前記発生したイベントを受信した場合、前記格納バッファに格納されている全ての前記稼動データと前記受信したイベントとを対応付けて前記記憶装置に格納し、かつ、前記格納バッファ内の全ての稼動データを削除する手段と、
前記格納バッファが前記稼動データで満杯になった場合に、前記２分割されている格納バッファのうちの時間的に古い分割部分に格納されている稼動データを前記記憶装置に格納し、その後、前記古い分割部分に格納されている稼動データを格納バッファから削除する手段と、
および、
前記記憶装置に格納された前記発生したイベントと対応付けられた稼動データを解析する手段
を有することを特徴とする運用管理システム。
請求項１記載の運用管理システムであって、
前記定められた条件は、前記監視対象の障害発生又は性能低下を示すものであることを特徴とする運用管理システム。