JP2011154491A - 情報管理プログラム、情報管理装置、および情報管理方法 - Google Patents

Abstract

【課題】情報の保存量を効率的に削減すること。
【解決手段】組み合わせ｛ＶＭ＃１，Ｘ＿Ｗｅｂ｝において、ＶＭ＃１では時刻Ｔ１でイベントＥ１が発生し、Ｘ＿Ｗｅｂでは時刻Ｔ２でイベントＥ２が発生したものとする。（Ａ）では、差分｜Ｔ２−Ｔ１｜≦Ｔｓとなるため、イベントＥ１，Ｅ２は障害の依存関係ありと判定される。（Ｂ）では、差分｜Ｔ２−Ｔ１｜＞Ｔｓとなるため、イベントＥ１，Ｅ２は障害の依存関係なしと判定される。
【選択図】図１０

Description

本発明は、情報を管理する情報管理プログラム、情報管理装置、および情報管理方法に関する。

従来、分散コンピュータ環境を集中管理するシステムにおいて、障害情報を含むネットワークに関する情報を収集して、統合管理し、各々の情報を関連付けて統合情報を生成する技術が開示されている（たとえば、下記特許文献１を参照。）。また、収集したログ情報の重要度を判定し、重要度が高い情報は全情報が保存され、重要度が低い情報は、編集し、統計情報ログとして別ファイルに格納する技術が開示されている（たとえば、下記特許文献２を参照。）。

特開平８−１３７８１０号公報 特開平１０−２７５０９８号公報

しかしながら、上述した従来技術では、何を基準にして重要度を判定しているかが不明であるため、人手により重要度を判定せざるを得ない。このため、重要度が高いログ情報のうち、どのログ情報が障害の基点であるかを判定するのが困難であるという問題があった。したがって、重要度が高くても、基点となる障害が原因で連鎖的に障害が発生した情報についても保存してしまうこととなり、依然として保存すべき情報量が多く、リソース不足に陥るという問題があった。

本発明は、上述した従来技術による問題点を解消するため、情報の保存量を効率的に削減することができる情報管理プログラム、情報管理装置、および情報管理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本情報管理プログラム、情報管理装置、および情報管理方法は、依存関係がある管理対象群で発生したイベント群の中から、依存元管理対象で発生した第１のイベントと前記依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせを抽出し、抽出された組み合わせごとに、前記第１のイベントの発生時刻と前記第２のイベントの発生時刻との差分により、前記第１のイベントと前記第２のイベントとの依存関係の有無を判定し、判定された判定結果に基づいて、前記イベント群のうち、前記依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定し、決定された保存対象イベントに関する情報をデータベースに保存することを要件とする。

本発明によれば、情報の保存量を効率的に削減することができるという効果を奏する。

本実施の形態にかかる情報管理システムの一例を示す説明図である。 管理対象から発生するイベントのデータ構造の一例を示す説明図である。 実施の形態で用いられるコンピュータのハードウェア構成を示すブロック図である。 情報管理装置の機能的構成を示すブロック図である。 プロセス割当テーブルの記憶内容の一例を示す説明図である。 ＣＰＵ＃１を障害の基点とした場合の依存関係情報を示す説明図である。 ＣＰＵ＃２を障害の基点とした場合の依存関係情報を示す説明図である。 ＶＭを障害の基点とした場合の依存関係情報を示す説明図である。 業務プロセスを障害の基点とした場合の依存関係情報を示す説明図である。 判定部による判定処理の具体例（その１）を示す説明図である。 判定部による判定処理の具体例（その２）を示す説明図である。 判定部による判定処理の具体例（その３）を示す説明図である。 判定部による判定処理の具体例（その４）を示す説明図である。 判定部による判定処理の具体例（その５）を示す説明図である。 統合管理ＤＢの記憶内容の一例を示す説明図である。 本実施の形態にかかる情報管理装置による情報管理処理手順を示すフローチャートである。 図１６に示した依存関係判定処理（ステップＳ１６０６）の詳細な処理手順を示すフローチャートである。 図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その１）である。 図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その２）である。 図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その３）である。

以下に添付図面を参照して、本発明にかかる情報管理プログラム、情報管理装置、および情報管理方法の実施の形態を詳細に説明する。

（情報管理システムの一例）
図１は、本実施の形態にかかる情報管理システム１００の一例を示す説明図である。情報管理システム１００は、管理対象装置１０１と管理対象装置１０１を管理する管理機能１０２と統合管理データベース（ＤＢ）１０３を備える。情報管理システム１００は、１台のコンピュータでもよく、複数台のコンピュータで構成してもよい。

まず、管理対象装置１０１について説明する。管理対象装置１０１は、複数種類の管理対象群の集合である。たとえば、管理対象装置１０１をクラウドコンピューティングに適用する場合、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：仮想計算機）と業務プロセスの３種類を管理対象とすることができる。

図１では、たとえば、ＣＰＵ１１１としてＣＰＵ＃１、ＣＰＵ＃２、ＶＭ１１２としてＶＭ＃１〜ＶＭ＃６）、業務プロセス１１３として業務Ｘ用プロセス１１３Ｘ（Ｘ＿Ｗｅｂ，Ｘ＿ＡＰ，Ｘ＿ＤＢ），業務Ｙ用プロセス１１３Ｙ（Ｙ＿Ｗｅｂ，Ｙ＿ＡＰ，Ｙ＿ＤＢ）を管理対象とする。なお、Ｘ＿Ｗｅｂ，Ｙ＿ＷｅｂはＷｅｂサーバとして機能するプログラムである。また、Ｘ＿ＡＰ，Ｙ＿ＡＰはアプリケーションサーバとして機能するプログラムである。Ｘ＿ＤＢ，Ｙ＿ＤＢはデータベースサーバとして機能するプログラムである。

また、図１の例では、ＣＰＵ＃１がＶＭ＃１，ＶＭ＃２，ＶＭ＃４，ＶＭ＃５を制御し、ＣＰＵ＃２がＶＭ＃３，ＶＭ＃６を制御する。また、ＶＭ＃１がＸ＿Ｗｅｂを制御する。また、ＶＭ＃２がＸ＿ＡＰを制御する。また、ＶＭ＃３がＸ＿ＤＢを制御する。また、ＶＭ＃４がＹ＿Ｗｅｂを制御する。また、ＶＭ＃５がＹ＿ＡＰを制御する。また、ＶＭ＃６がＹ＿ＤＢを制御する。

管理対象装置１０１では、ＣＰＵ１１１がＶＭ１１２を制御し、ＶＭ１１２が業務プロセス１１３を制御する。このため、制御主体となる管理対象において障害が発生すると、その障害が原因となって制御対象となる管理対象にも障害が発生する。たとえば、ＣＰＵ＃１で障害が発生すると、ＶＭ＃１，ＶＭ＃２，ＶＭ＃４，ＶＭ＃５にも障害が発生する。同様に、ＶＭ＃１で障害が発生すると、その障害が原因となってＸ＿Ｗｅｂにも障害が発生する。

このように、障害発生に関して、制御対象となる管理対象は、制御主体となる管理対象に依存しているため、制御主体となる管理対象を以後、「依存元管理対象」と称す。また、制御対象となる管理対象を「依存先管理対象」と称す。図１では、ＣＰＵ１１１は、ＶＭ１１２に対して依存元管理対象となり、ＶＭ１１２はＣＰＵ１１１に対して依存先管理対象となる。同様に、ＶＭ１１２は、業務プロセス１１３に対して依存元管理対象となり、業務プロセス１１３はＶＭ１１２に対して依存先管理対象となる。このように、依存元管理対象と依存先管理対象との関わりを、依存関係と称す。

このように、ＣＰＵ１１１は、依存元管理対象にはなるが依存先管理対象にはならず、業務プロセス１１３は、依存先管理対象にはなるが依存元管理対象にはならない。また、ＶＭ１１２は、依存元管理対象にも依存先管理対象にもなり得る。

つぎに、管理機能１０２について説明する。管理機能１０２は、管理対象の種類ごとに管理機能１０２を有する。たとえば、ＣＰＵ１１１に対してはＣＰＵ管理機能１２１、ＶＭ１１２に対してはＶＭ管理機能１２２、業務プロセス１１３に対しては業務管理機能１２３を有する。

ＣＰＵ管理機能１２１は、管理対象装置１０１内のＣＰＵ１１１を管理するソフトウェアである。ＶＭ管理機能１２２は、管理対象装置１０１内のＶＭ１１２を管理するソフトウェアである。業務管理機能１２３は、管理対象装置１０１内の業務プロセス１１３を管理するソフトウェアである。各管理機能１２１〜１２３は、それぞれＤＢ１２４〜１２６を有し、各々の管理対象から障害や故障、通信状態の監視状態の変化が起こったときに通知されるイベントを収集し、ログとして保存する。

また、管理機能１０２は、統合管理機能１２７を有する。統合管理機能１２７は、管理対象の種類ごとに分散して保存されたイベントを収集して、ログとして統合管理ＤＢ１０３に保存する。本実施の形態では、各管理機能１２１〜１２３のＤＢ１２４〜１２６に保存されたイベントとの重複保存の低減化を図るため、統合管理ＤＢ１０３に保存するイベントを絞り込む。

具体的には、たとえば、管理者や統合管理機能１２７から見れば、複数のイベントの中から障害が発生している基点から通知される障害イベントが重要である。したがって、ＤＢ１２４〜１２６から収集された障害イベントのうち障害箇所となる管理対象を特定するのに必要なイベントをログとして統合管理ＤＢ１０３に保存する。それ以外のイベントは、統合管理ＤＢ１０３に保存しなくても、ＤＢ１２４〜１２６に保存されているため、統合管理ＤＢ１０３に保存しなくても、統合管理ＤＢ１０３に保存したイベントを手がかりにして、必要に応じて読み出せばよい。

（イベントのデータ構造の一例）
つぎに、上述した管理対象から発生するイベントのデータ構造について説明する。

図２は、管理対象から発生するイベントのデータ構造の一例を示す説明図である。イベントは、番号項目２０１、タイムスタンプ項目２０２、イベント種類項目２０３、発生箇所項目２０４、警報種類項目２０５、予備項目２０６といった項目を有する。番号項目２０１には、イベントフレームに付けられるシリアル番号が記述される。タイムスタンプ項目２０２には、イベントの発生時刻（たとえば、２００９＿０９＿０５＿１７:５８:２３）が記述される。

イベント種類項目２０３には、イベント種類を識別するフラグ（たとえば、「０」が警報イベント、「１」が品質監視イベント）が記述される。発生箇所項目２０４には、イベントの発生箇所となる管理対象の識別情報（たとえば、ＣＰＵ＃１、ＶＭ＃２、Ｗｅｂ＃１など）が記述される。警報種類項目２０５には、警報の種類に関する識別情報（装置関連、ＶＭ１１２関連、アプリ関連、通信関連、品質関連などの識別情報）が記述される。予備項目２０６には、必要に応じて設定された情報が記述される。

（コンピュータのハードウェア構成）
図３は、実施の形態で用いられるコンピュータのハードウェア構成を示すブロック図である。図３において、コンピュータは、ＣＰＵ３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、ディスプレイ３０８と、Ｉ＿Ｆ（Ｉｎｔｅｒｆａｃｅ）３０９と、キーボード３１０と、マウス３１１と、スキャナ３１２と、プリンタ３１３と、を備えている。また、各構成部はバス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、コンピュータの全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。磁気ディスクドライブ３０４は、ＣＰＵ３０１の制御にしたがって磁気ディスク３０５に対するデータのリード＿ライトを制御する。磁気ディスク３０５は、磁気ディスクドライブ３０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ３０６は、ＣＰＵ３０１の制御にしたがって光ディスク３０７に対するデータのリード＿ライトを制御する。光ディスク３０７は、光ディスクドライブ３０６の制御で書き込まれたデータを記憶したり、光ディスク３０７に記憶されたデータをコンピュータに読み取らせたりする。

ディスプレイ３０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ３０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

インターフェース（以下、「Ｉ＿Ｆ」と略する。）３０９は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワーク３１４に接続され、このネットワーク３１４を介して他の装置に接続される。そして、Ｉ＿Ｆ３０９は、ネットワーク３１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ＿Ｆ３０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード３１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス３１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ３１２は、画像を光学的に読み取り、コンピュータ内に画像データを取り込む。なお、スキャナ３１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ３１３は、画像データや文書データを印刷する。プリンタ３１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（情報管理装置４００の機能的構成）
つぎに、情報管理装置４００の機能的構成について説明する。図４は、情報管理装置４００の機能的構成を示すブロック図である。情報管理装置４００は、図１に示した統合管理機能１２７に相当する。情報管理装置４００は、取得部４０１と、特定部４０２と、抽出部４０３と、判定部４０４と、決定部４０５と、算出部４０６と、保存部４０７と、を備える。取得部４０１〜保存部４０７は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、Ｉ＿Ｆ３０９により、その機能を実現する。

取得部４０１は、管理対象の種類ごとのイベントが格納された管理対象の種類ごとのデータベース群から所定期間内に発生したイベント群を取得する機能を有する。具体的には、たとえば、ＤＢ１２４〜１２６に保存されているイベントのタイムスタンプを参照することにより、所定期間内に発生したイベント群を読み出す。

特定部４０２は、取得部４０１によって取得されたイベント群内の各イベントに記述されている発生元の管理対象に関する情報に基づいて、依存関係がある管理対象群を特定する機能を有する。具体的には、たとえば、取得部４０１によって取得された各イベントの発生箇所項目２０４には、発生元の管理対象の識別情報が記述されている。この識別情報を手がかりとして、依存関係がある管理対象群を特定する。

たとえば、取得された各イベントの発生箇所項目２０４に、「ＣＰＵ＃２」、「ＶＭ＃３」、「ＶＭ＃６」、「Ｘ＿ＤＢ」、「Ｙ＿ＤＢ」が記述されている場合、「ＣＰＵ＃２」、「ＶＭ＃３」、「ＶＭ＃６」、「Ｘ＿ＤＢ」、「Ｙ＿ＤＢ」を依存関係のある管理対象群として特定する。このような特定部４０２による特定では、プロセス割当テーブルを用いることができる。

図５は、プロセス割当テーブルの記憶内容の一例を示す説明図である。プロセス割当テーブル５００は、番号項目５０１と管理対象項目５０２とを有する。番号項目５０１には、レコード順に昇順の番号が記憶されている。管理対象項目５０２は、管理対象の種類別に分けられている。図５では、ＣＰＵ項目とＶＭ項目と業務プロセス項目に分けられている。このように、プロセス割当テーブル５００は、管理対象装置１０１内部において、ＣＰＵ１１１、ＶＭ１１２、業務プロセス１１３のそれぞれがどのように割り当てられているかを示している。

たとえば、番号１のレコードでは、ＣＰＵ＃１、ＶＭ＃１、Ｘ＿Ｗｅｂが記憶されている。番号１のレコードは、業務プロセス１１３であるＸ＿ＷｅｂはＶＭ＃１に割り当てられており、ＶＭ＃１はＣＰＵ＃１に割り当てられていることを意味する。なお、プロセス割当テーブル５００はあらかじめ管理者によって設定されているものとする。

なお、プロセス割当テーブル５００は、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置により、その機能を実現する。

図６〜図９は、依存関係情報を示す説明図である。依存関係情報とは、ある管理対象で発生した障害がどの範囲まで影響するのかを表現した情報である。障害は、依存元管理対象から依存先管理対象に伝搬するため、依存元管理対象ごとに、依存関係情報が設定される。なお、図６〜図９中、楕円は管理対象を示すノードであり、ノード間のリンクは依存関係を示している。すなわち、リンクで結ばれている左側のノードが依存元管理対象であり、右側のノードが依存先管理対象である。したがって、依存関係情報において、左端のノードが障害の基点となる管理対象を示している。

図６および図７は、ＣＰＵ１１１を障害の基点とした場合の依存関係情報を示す説明図である。特に図６は、ＣＰＵ＃１を障害の基点とした場合の依存関係情報６００である。図７は、ＣＰＵ＃２を障害の基点とした場合の依存関係情報７００である。

図８は、ＶＭ１１２を障害の基点とした場合の依存関係情報を示す説明図である。（Ａ）は、ＶＭ＃１を障害の基点とした場合の依存関係情報８０１である。（Ｂ）は、ＶＭ＃２を障害の基点とした場合の依存関係情報８０２である。（Ｃ）は、ＶＭ＃３を障害の基点とした場合の依存関係情報８０３である。

（Ｄ）は、ＶＭ＃４を障害の基点とした場合の依存関係情報８０４である。（Ｅ）は、ＶＭ＃５を障害の基点とした場合の依存関係情報８０５である。（Ｆ）は、ＶＭ＃６を障害の基点とした場合の依存関係情報８０６である。

図９は、業務プロセス１１３を障害の基点とした場合の依存関係情報を示す説明図である。（Ａ）は、Ｘ＿Ｗｅｂを障害の基点とした場合の依存関係情報９０１である。（Ｂ）は、Ｘ＿ＡＰを障害の基点とした場合の依存関係情報９０２である。（Ｃ）は、Ｘ＿ＤＢを障害の基点とした場合の依存関係情報９０３である。

（Ｄ）は、Ｙ＿Ｗｅｂを障害の基点とした場合の依存関係情報９０４である。（Ｅ）は、Ｙ＿ＡＰを障害の基点とした場合の依存関係情報９０５である。（Ｆ）は、Ｙ＿ＤＢを障害の基点とした場合の依存関係情報９０６である。

また、基点となる管理対象（左端のノード）から末端の管理対象（右端のノード）までの経路をパスと称す。たとえば、図６の依存関係情報６００は、｛ＣＰＵ＃１→ＶＭ＃１→Ｘ＿Ｗｅｂ｝、｛ＣＰＵ＃１→ＶＭ＃２→Ｘ＿ＡＰ｝、｛ＣＰＵ＃１→ＶＭ＃４→Ｙ＿Ｗｅｂ｝、｛ＣＰＵ＃１→ＶＭ＃５→Ｙ＿ＡＰ｝の４本のパスを有する。

依存関係情報は、プロセス割当テーブル５００と同様、あらかじめ管理者によって設定されているものとしてもよい。ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式の場合、依存関係情報をツリー構造で表現することができる。このように、あらかじめ設定されている場合、特定部４０２では、取得部４０１によって取得された各イベントの発生箇所項目２０４に記述されている発生元の管理対象の識別情報を手がかりとして、依存関係がある管理対象群としての依存関係情報を特定する。

たとえば、取得したイベント群の発生箇所項目２０４にＣＰＵ１１１に属する識別情報（たとえば、ＣＰＵ＃１）が記述されている場合、依存関係情報の中から図６の依存関係情報６００を特定する。

また、取得したイベント群の発生箇所項目２０４にＶＭ１１２に属する識別情報（たとえば、ＶＭ＃２）が記述されており、かつ、ＣＰＵ１１１に属する識別情報が記述されていない場合、依存関係情報の中から図８の（Ｂ）の依存関係情報８０２を特定する。

さらに、取得したイベント群の発生箇所項目２０４に業務プロセス１１３に属する識別情報（たとえば、Ｘ＿ＤＢ）が記述されており、かつ、ＣＰＵ１１１およびＶＭ１１２に属する識別情報が記述されていない場合、依存関係情報の中から図９の（Ｃ）の依存関係情報９０３を特定する。

また、依存関係情報をあらかじめ設定しておかず、特定部４０２によりプロセス割当テーブル５００から検索することにより、該当する依存関係情報を特定することとしてもよい。具体的には、たとえば、リレーショナルＤＢの内部にプロセス割当テーブル５００を作成しておき、プロセス割当テーブル５００に対して、予め用意したＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）の検索式を実行する。これにより、得られる結果セット（テーブル形式）を該当する依存関係情報として特定することができる。

プロセス割当テーブル５００から検索して該当する依存関係情報として特定することにより、あらかじめ依存関係情報を作成する負担がない。また、検索する都度、該当する依存関係情報をメモリに書き出せばよいため、すべての依存関係情報を用意する必要がなく、メモリ使用量の削減を図ることができる。

なお、依存関係情報６００，７００，８０１〜８０６，９０１〜９０６は、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置により、その機能を実現する。

また、図４において、抽出部４０３は、依存関係がある管理対象群で発生したイベント群の中から、依存元管理対象で発生した第１のイベントと依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせを抽出する機能を有する。

具体的には、たとえば、該当する依存関係情報内の各リンクの両端のノードの組み合わせを抽出する。たとえば、図６の依存関係情報６００の場合、｛ＣＰＵ＃１，ＶＭ＃１｝,｛ＶＭ＃１，Ｘ＿Ｗｅｂ｝，｛ＣＰＵ＃１，ＶＭ＃２｝,｛ＶＭ＃２，Ｘ＿ＡＰ｝，｛ＣＰＵ＃１，ＶＭ＃４｝,｛ＶＭ＃４，Ｙ＿Ｗｅｂ｝，｛ＣＰＵ＃１，ＶＭ＃５｝,｛ＶＭ＃５，Ｙ＿ＡＰ｝の８個の組み合わせが抽出される。

判定部４０４は、抽出部４０３によって抽出された組み合わせごとに、第１のイベントの発生時刻と第２のイベントの発生時刻との差分により、第１のイベントと第２のイベントとの依存関係の有無を判定する機能を有する。

具体的には、たとえば、抽出部４０３によって抽出された組み合わせの一方の管理対象で発生したイベントの発生時刻をそのタイムスタンプから読み出す。同様に、他方の管理対象で発生したイベントの発生時刻をそのタイムスタンプから読み出す。そして、両タイムスタンプの差分を算出する。

差分は、両タイムスタンプの時間差の絶対値とする。通常、依存元管理対象で発生したイベントが依存先管理対象で発生したイベントよりも先に検出されるが、何らかの原因で依存先管理対象で発生したイベントが先に検出されることもある。このため、両タイムスタンプの時間差の絶対値を差分とする。そして、判定部４０４は、差分がしきい値Ｔｓ以内の場合、両イベント間に障害の依存関係ありと判定する。一方、差分がしきい値Ｔｓ以内ではない場合、両イベント間に障害の依存関係なしと判定する。

図１０は、判定部４０４による判定処理の具体例（その１）を示す説明図である。ここでは、図８の（Ａ）に示した依存関係情報８０１から得られた組み合わせ｛ＶＭ＃１，Ｘ＿Ｗｅｂ｝を例に挙げ、ＶＭ＃１では時刻Ｔ１でイベントＥ１が発生し、Ｘ＿Ｗｅｂでは時刻Ｔ２でイベントＥ２が発生したものとする。

（Ａ）では、差分｜Ｔ２−Ｔ１｜≦Ｔｓとなるため、イベントＥ１，Ｅ２は障害の依存関係ありと判定される。（Ｂ）では、差分｜Ｔ２−Ｔ１｜＞Ｔｓとなるため、イベントＥ１，Ｅ２は障害の依存関係なしと判定される。

図１１は、判定部４０４による判定処理の具体例（その２）を示す説明図である。ここでは、図７に示した依存関係情報７００から得られた４個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝を例に挙げる。また、ＣＰＵ＃２では時刻Ｔ１でイベントＥ１が発生し、ＶＭ＃３では時刻Ｔ２１でイベントＥ２１が発生し、Ｘ＿ＤＢでは時刻Ｔ３１でイベントＥ３１が発生し、ＶＭ＃６では時刻Ｔ２２でイベントＥ２２が発生し、Ｙ＿ＤＢでは時刻Ｔ３２でイベントＥ３２が発生したものとする。

また、ＣＰＵ１１１とＶＭ１１２との間のしきい値ＴｓをＴｓ１とし、ＶＭ１１２と業務プロセス１１３との間のしきい値ＴｓをＴｓ２とする。しきい値Ｔｓ１，Ｔｓ２は、管理者が自由に設定でき、Ｔｓ１＝Ｔｓ２でもよく、Ｔｓ１≠Ｔｓ２でもよい。

本例では、４個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝が抽出されるため、それぞれ差分｜Ｔ２１−Ｔ１｜，｜Ｔ３１−Ｔ２１｜，｜Ｔ２２−Ｔ１｜，｜Ｔ３２−Ｔ２２｜を算出し、対応するしきい値Ｔｓ１，Ｔｓ２以内であるかを判定することとなる。図１１の例では、すべての差分｜Ｔ２１−Ｔ１｜，｜Ｔ３１−Ｔ２１｜，｜Ｔ２２−Ｔ１｜，｜Ｔ３２−Ｔ２２｜が対応するしきい値Ｔｓ１，Ｔｓ２以内である。したがって、イベントＥ１，Ｅ２１，Ｅ３１，Ｅ２２，Ｅ３２は依存関係ありと判定される。

図１２は、判定部４０４による判定処理の具体例（その３）を示す説明図である。図１２では、図１１に示した具体例において、イベントＥ３１が通知されなかった場合の判定処理例である。イベントＥ３１は、発生していたけれども何らかの理由で通知されなかったか、あるいは、元々発生していないため通知されなかったと考えられる。

このような場合、４個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝のうち、組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝について、判定処理を実行する。図１２の例では、差分｜Ｔ２１−Ｔ１｜，｜Ｔ２２−Ｔ１｜，｜Ｔ３２−Ｔ２２｜が、対応するしきい値Ｔｓ１，Ｔｓ２以内である。したがって、イベントＥ１，Ｅ２１，Ｅ２２，Ｅ３２は依存関係ありと判定される。

また、イベントＥ３１が欠落しているため、イベントＥ１，Ｅ２１，Ｅ２２，Ｅ３２は依存関係なしと判定してもよい。また、差分の計算に先立って、イベントＥ３１の欠落がわかるため、差分の計算を実行せずに、イベントＥ１，Ｅ２１，Ｅ２２，Ｅ３２は依存関係なしと判定してもよい。これにより、計算負荷の低減を図ることができる。

図１３は、判定部４０４による判定処理の具体例（その４）を示す説明図である。図１３では、図１１に示した具体例において、何らかの原因でイベントＥ２１が通知されなかった場合の判定処理例である。イベントＥ２１は、発生していたけれども何らかの理由で通知されなかったか、あるいは、元々発生していないため通知されなかったと考えられる。

このような場合、４個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝のうち、組み合わせ｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝について、判定処理を実行する。図１３の例では、差分｜Ｔ２２−Ｔ１｜，｜Ｔ３２−Ｔ２２｜が、対応するしきい値Ｔｓ１，Ｔｓ２以内である。したがって、イベントＥ１，Ｅ３１，Ｅ２２，Ｅ３２は依存関係ありと判定される。

また、イベントＥ２１が欠落しているため、イベントＥ１，Ｅ３１，Ｅ２２，Ｅ３２は依存関係なしと判定してもよい。また、差分の計算に先立って、イベントＥ２１の欠落がわかるため、差分の計算を実行せずに、イベントＥ１，Ｅ３１，Ｅ２２，Ｅ３２は依存関係なしと判定してもよい。これにより、計算負荷の低減を図ることができる。

図１４は、判定部４０４による判定処理の具体例（その５）を示す説明図である。図１４では、図１１に示した具体例において、イベントＥ２１，Ｅ２２が通知されなかった場合の判定処理例である。イベントＥ２１，Ｅ２２は、発生していたけれども何らかの理由で通知されなかったか、あるいは、元々発生していないため通知されなかったと考えられる。

このような場合、４個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝のいずれも差分が計算不能である。したがって、イベントＥ１，Ｅ３１，Ｅ３２は依存関係なしと判定される。

また、図４に戻って、決定部４０５は、判定部４０４によって判定された判定結果に基づいて、イベント群のうち、依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定する機能を有する。

具体的には、判定部４０４によって組み合わせのすべてにおいて依存関係有りと判定された場合、依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定する。たとえば、依存関係情報において左端のノードとなる管理対象は、依存先管理対象にならない依存元管理対象であるため、依存関係情報において左端のノードとなる管理対象が障害の基点となる。したがって、依存関係情報において左端のノードとなる管理対象で発生したイベントを保存対象イベントに決定する。

たとえば、図１０の（Ａ）に示した例では、ＶＭ＃１で発生したイベントＥ１が保存対象イベントに決定される。したがって、従来では、２個のイベントＥ１，Ｅ２を保存対象イベントとしていたところ、決定部４０５によりイベントＥ１が保存対象イベントとなるため、５０％の削減効果が得られることとなる。

また、図１１に示した例では、ＣＰＵ＃２で発生したイベントＥ１が保存対象イベントに決定される。したがって、従来では、５個のイベントＥ１，Ｅ２１，Ｅ３１，Ｅ２２，Ｅ３２を保存対象イベントとしていたところ、決定部４０５によりイベントＥ１が保存対象イベントとなるため、８０％の削減効果が得られることとなる。

また、図１２および図１３に示した例において、依存関係ありと判定された場合、ＣＰＵ＃２で発生したイベントＥ１が保存対象イベントに決定される。したがって、従来では、４個のイベントＥ１，Ｅ２１／Ｅ３１，Ｅ２２，Ｅ３２を保存対象イベントとしていたところ、決定部４０５によりイベントＥ１が保存対象イベントとなるため、７５％の削減効果が得られることとなる。

なお、決定部４０５は、判定部４０４によって依存関係なしと判定された場合、依存関係なしと判定されたイベント群を保存対象イベントに決定することとなる。たとえば、図１０の（Ｂ）では、イベントＥ１，Ｅ２とは依存関係なしと判定されたため、イベントＥ１，Ｅ２を保存対象イベントに決定することとなる。

また、算出部４０６は、組み合わせの総数と第１のイベントおよび第２のイベントが抽出された組み合わせの数に基づいて、保存対象イベントに関する信頼度を算出する機能を有する。ここで、信頼度とは、判定部４０４による依存関係ありと判定された判定結果の信頼性を評価する指標値である。たとえば、組み合わせの総数を分母とし、第１のイベントおよび第２のイベントが抽出された組み合わせの数を分子とした値を信頼度とする。

たとえば、図１０の（Ａ）の場合は、組み合わせは｛ＶＭ＃１，Ｘ＿Ｗｅｂ｝の１個であるため、組み合わせの総数は１である。また、ＶＭ＃１で発生したイベントＥ１およびＸ＿Ｗｅｂで発生したイベントＥ２が抽出されるため、第１のイベントおよび第２のイベントが抽出された組み合わせの数は１である。したがって、信頼度は１／１となる。同様に、図１１の場合も、信頼度は４／４である。

図１２の場合、組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＶＭ＃３，Ｘ＿ＤＢ｝，｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝の４個であるため、組み合わせの総数は４である。また、３個の組み合わせ｛ＣＰＵ＃２，ＶＭ＃３｝,｛ＣＰＵ＃２，ＶＭ＃６｝,｛ＶＭ＃６，Ｙ＿ＤＢ｝について、第１のイベントおよび第２のイベントが抽出されているため、第１のイベントおよび第２のイベントが抽出された組み合わせの数は３である。したがって、信頼度は３／４となる。同様に、図１３の場合は、信頼度は２／４であり、図１４の場合は、０／４となる。

また、決定部４０５は、算出部４０６によって算出された信頼度に基づいて、保存対象イベントを決定することとしてもよい。たとえば、しきい値となる所定信頼度Ｐを設定しておく。所定信頼度Ｐは管理者が自由に設定することができる。

そして、算出部４０６で算出された信頼度が所定信頼度Ｐ以上である場合は、判定部４０４で依存関係ありと判定されたイベント群のうち依存先管理対象にならない依存元管理対象で発生したイベント（障害の基点となるイベント）を保存対象イベントに決定する。一方、算出部４０６で算出された信頼度が所定信頼度Ｐ未満である場合は、判定部４０４で依存関係ありと判定されたイベント群を保存対象イベントに決定する。

たとえば、所定信頼度ＰをＰ＝７０％とした場合、図１０の（Ａ）の例の信頼度１／１は、所定信頼度Ｐ以上となるため、イベントＥ１が保存対象イベントに決定される。また、図１１の例の信頼度４／４は、所定信頼度Ｐ以上となるため、イベントＥ１が保存対象イベントに決定される。

図１２の例の信頼度３／４は、所定信頼度Ｐ以上となるため、イベントＥ１が保存対象イベントに決定される。また、図１３の例の信頼度２／４は、所定信頼度Ｐ未満となるため、イベントＥ１，Ｅ３１，Ｅ２２，Ｅ３２が保存対象イベントに決定される。また、図１４の例の信頼度０／４は、所定信頼度Ｐ未満となるため、イベントＥ１，Ｅ３１，Ｅ３２が保存対象イベントに決定される。

図４に戻って、保存部４０７は、決定部４０５によって決定された保存対象イベントに関する情報をＤＢ４０８に保存する機能を有する。具体的には、たとえば、保存対象イベントに記述されている番号、タイムスタンプ、イベント種類、発生箇所、警報種類、予備といった情報をレコードとして統合管理ＤＢ１０３に保存する。

図１５は、統合管理ＤＢ１０３の記憶内容の一例を示す説明図である。なお、保存部４０７は、保存対象イベントに記述されている情報をすべて保存することとしてもよいが、少なくとも番号と発生箇所が保存されていればよい。番号と発生箇所が保存されていれば、ＤＢ１２４〜１２６から検索可能である。

また、保存部４０７は、算出部４０６によって算出された信頼度も保存することとしてもよい。この場合、信頼度は、統合管理ＤＢ１０３の予備項目２０６に保存することができる。これにより、たとえば、図１２のような場合に、イベントＥ３１の非通知によりＶＭ＃３とＸ＿ＤＢ間の依存関係が不明であっても、イベントＥ１とともに信頼度３／４が関連付けられて保存される。したがって、管理者は、統合管理ＤＢ１０３の保存内容の確認の際に参考にすることで、イベントＥ１の発生源であるＣＰＵ＃２だけを確認すべきか、他の管理対象（ＶＭ＃３，ＶＭ＃６，Ｙ＿ＤＢ）も確認すべきかといった判断基準として用いることができる。

（情報管理処理手順）
つぎに、本実施の形態にかかる情報管理装置４００による情報管理処理手順について説明する。

図１６は、本実施の形態にかかる情報管理装置４００による情報管理処理手順を示すフローチャートである。まず、情報管理装置４００は、初期設定として対象期間を指定し（ステップＳ１６０１）、対象期間内で開始区間となる対象区間を設定する（ステップＳ１６０２）。そして、情報管理装置４００は、対象区間内にイベントがあるか否かをＤＢ１２４〜１２６を参照することで判断する（ステップＳ１６０３）。

対象区間内にイベントがある場合（ステップＳ１６０３：Ｙｅｓ）、情報管理装置４００は、取得部４０１により、対象区間内のイベントをＤＢ１２４〜１２６から取得する（ステップＳ１６０４）。そして、特定部４０２により、取得イベントに該当する依存関係情報を特定する（ステップＳ１６０５）。

つぎに、判定部４０４による依存関係判定処理（ステップＳ１６０６）および決定部４０５による保存対象イベント決定処理（ステップＳ１６０７）を実行する。そして、保存対象イベント決定処理（ステップＳ１６０７）で決定された保存対象イベントをＤＢ４０８（統合管理ＤＢ１０３）に保存する（ステップＳ１６０８）。

このあと、対象期間が終了したか否かを判断する（ステップＳ１６０９）。対象期間が終了していない場合（ステップＳ１６０９：Ｎｏ）、対象区間をシフトして（ステップＳ１６１０）、次区間を対象区間とし、ステップＳ１６０３に戻る。現区間と次区間との間でイベントが通知される場合もあるため、次区間は、現区間と一部重複して設定することとしてもよい。

また、ステップＳ１６０３において、対象区間内にイベントがない場合（ステップＳ１６０３：Ｎｏ）、ステップＳ１６０９に移行する。また、ステップＳ１６０９において、対象期間が終了した場合（ステップＳ１６０９：Ｙｅｓ）、一連の情報管理処理を終了する。

図１７は、図１６に示した依存関係判定処理（ステップＳ１６０６）の詳細な処理手順を示すフローチャートである。まず、情報管理装置４００は、ステップＳ１６０５において特定された依存関係情報の中に、依存関係判定が未処理のパスがあるか否かを判断する（ステップＳ１７０１）。未処理のパスがない場合（ステップＳ１７０１：Ｎｏ）、ステップＳ１６０７に移行する。

一方、未処理のパスがある場合（ステップＳ１７０１：Ｙｅｓ）、情報管理装置４００は、未処理のパスを選択する（ステップＳ１７０２）。たとえば、図７の依存関係情報７００の場合、｛ＣＰＵ＃２→ＶＭ＃３→Ｘ＿ＤＢ｝、｛ＣＰＵ＃２→ＶＭ＃６→Ｙ＿ＤＢ｝の２本のパスから未処理のパスを選択することとなる。

そして、情報管理装置４００は、選択パスの中に未処理の連結ノードの組み合わせがあるか否かを判断する（ステップＳ１７０３）。連結ノードの組み合わせとは、依存関係がある管理対象群で発生したイベント群の中から、依存元管理対象で発生した第１のイベントと依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせである。すなわち、リンクによって連結しあうノードの組み合わせである。未処理の連結ノードの組み合わせがない場合（ステップＳ１７０３：Ｎｏ）、ステップＳ１７０１に移行する。

一方、未処理の連結ノードの組み合わせがある場合（ステップＳ１７０３：Ｙｅｓ）、情報管理装置４００は、未処理の連結ノードの組み合わせを選択する（ステップＳ１７０４）。たとえば、図６の依存関係情報６００の場合、８個の組み合わせ｛ＣＰＵ＃１，ＶＭ＃１｝,｛ＶＭ＃１，Ｘ＿Ｗｅｂ｝，｛ＣＰＵ＃１，ＶＭ＃２｝,｛ＶＭ＃２，Ｘ＿ＡＰ｝，｛ＣＰＵ＃１，ＶＭ＃４｝,｛ＶＭ＃４，Ｙ＿Ｗｅｂ｝，｛ＣＰＵ＃１，ＶＭ＃５｝,｛ＶＭ＃５，Ｙ＿ＡＰ｝の中から未処理の連結ノードの組み合わせを選択することとなる。

つぎに、情報管理装置４００は、選択組み合わせの総数を計数するカウンタＣａ（初期値はＣａ＝０）をインクリメントする（ステップＳ１７０５）。そして、情報管理装置４００は、選択された連結ノードの組み合わせにおいて、イベントが不足しているか否かを判断する（ステップＳ１７０６）。イベントが不足していない場合（ステップＳ１７０６：Ｎｏ）、情報管理装置４００は、選択された連結ノードの組み合わせ内の各管理対象からのイベントのタイムスタンプを読み出して、差分を算出する（ステップＳ１７０７）。

そして、情報管理装置４００は、差分がしきい値Ｔｓ以内であるか否かを判断し（ステップＳ１７０８）、しきい値Ｔｓ以内である場合（ステップＳ１７０８：Ｙｅｓ）、依存関係が成立したこととなり、ステップＳ１７０３に戻る。一方、しきい値Ｔｓ以内でない場合（ステップＳ１７０８：Ｎｏ）、依存関係が不成立となり、情報管理装置４００は、依存関係の不成立数を計数するカウンタＣｃ（初期値はＣｃ＝０）をインクリメントする（ステップＳ１７０９）。そして、ステップＳ１７０３に戻る。

一方、ステップＳ１７０６において、イベント不足であると判断された場合（ステップＳ１７０６：Ｙｅｓ）、情報管理装置４００は、非通知イベントの存在数を計数するカウンタＣｂ（初期値はＣｂ＝０）をインクリメントし（ステップＳ１７１０）、ステップＳ１７０３に戻る。

つぎに、図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順について図１８〜図２０を用いて説明する。

図１８は、図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その１）である。図１８に示すフローチャートは、対象区間内で、選択された連結ノードの組み合わせのすべてにおいて依存関係が成立する場合に、依存先管理対象にならない依存元管理対象（最上位ノード）で発生したイベントを保存対象イベントに決定する処理手順である。

図１８において、まず、情報管理装置４００は、１−Ｃｃ／Ｃａ＝１であるか否かを判断する（ステップＳ１８０１）。１−Ｃｃ／Ｃａ＝１である場合（ステップＳ１８０１：Ｙｅｓ）、情報管理装置４００は、最上位ノードのイベントを保存対象イベントに決定する（ステップＳ１８０２）。一方、１−Ｃｃ／Ｃａ＝１でない場合（ステップＳ１８０１：Ｎｏ）、情報管理装置４００は、特定された依存関係情報内の全ノードで通知されたイベント群を保存対象イベントに決定する（ステップＳ１８０３）。

そして、ステップＳ１８０２またはＳ１８０３のあと、情報管理装置４００は、カウンタＣａ，Ｃｃをリセットして（ステップＳ１８０４）、ステップＳ１６０８に移行する。これにより、対象区間内で、選択された連結ノードの組み合わせのすべてにおいて依存関係が成立する場合は、依存先管理対象にならない依存元管理対象（最上位ノード）で発生したイベントを保存対象イベントに決定することができ、イベント保存量の削減を図ることができる。

図１９は、図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その２）である。図１９に示すフローチャートは、信頼度（１−Ｃｂ／Ｃａ）に応じて保存対象イベントを決定する処理手順である。

まず、情報管理装置４００は、信頼度（１−Ｃｂ／Ｃａ）が１−Ｃｂ／Ｃａ≧Ｐであるか否かを判断する（ステップＳ１９０１）。１−Ｃｂ／Ｃａ≧Ｐである場合（ステップＳ１９０１：Ｙｅｓ）、組み合わせの総数を示すＣａからＣｂ分を除外するために、情報管理装置４００は、Ｃａ＝Ｃａ−Ｃｂを計算する（ステップＳ１９０２）。そして、情報管理装置４００は、１−Ｃｃ／Ｃａ＝１であるか否かを判断する（ステップＳ１９０３）。１−Ｃｃ／Ｃａ＝１である場合（ステップＳ１９０３：Ｙｅｓ）、情報管理装置４００は、最上位ノードのイベントを保存対象イベントに決定する（ステップＳ１９０４）。

一方、１−Ｃｃ／Ｃａ＝１でない場合（ステップＳ１９０３：Ｎｏ）、情報管理装置４００は、特定された依存関係情報内の全ノードで通知されたイベント群を保存対象イベントに決定する（ステップＳ１９０５）。また、ステップＳ１９０１において、１−Ｃｂ／Ｃａ≧Ｐでない場合（ステップＳ１９０１：Ｎｏ）、ステップＳ１９０５に移行する。そして、ステップＳ１９０４またはＳ１９０５のあと、情報管理装置４００は、カウンタＣａ〜Ｃｃをリセットして（ステップＳ１９０６）、ステップＳ１６０８に移行する。

これにより、信頼度に応じて保存対象イベントを決定することができるため、イベント通知がないような例外的な場合であっても、イベント保存量の削減を図ることができる。また、所定信頼度Ｐの設定しだいで保存対象イベント量を調整することができるため、管理者の人数や能力に応じて柔軟に対応することができる。

図２０は、図１６に示した保存対象イベント決定処理（ステップＳ１６０７）の詳細な処理手順を示すフローチャート（その３）である。図２０に示すフローチャートは、信頼度（１−Ｃｂ／Ｃａ）を保存対象イベントとともに保存させる場合の処理手順である。

まず、情報管理装置４００は、信頼度（１−Ｃｂ／Ｃａ）を算出し（ステップＳ２００１）、組み合わせの総数を示すＣａからＣｂ分を除外するために、Ｃａ＝Ｃａ−Ｃｂを計算する（ステップＳ２００２）。そして、情報管理装置４００は、１−Ｃｃ／Ｃａ＝１であるか否かを判断する（ステップＳ２００３）。１−Ｃｃ／Ｃａ＝１である場合（ステップＳ２００３：Ｙｅｓ）、情報管理装置４００は、最上位ノードのイベントを保存対象イベントに決定する（ステップＳ２００４）。

一方、１−Ｃｃ／Ｃａ＝１でない場合（ステップＳ２００３：Ｎｏ）、情報管理装置４００は、特定された依存関係情報内の全ノードで通知されたイベント群を保存対象イベントに決定する（ステップＳ２００５）。そして、ステップＳ２００４またはＳ２００５のあと、情報管理装置４００は、カウンタＣａ〜Ｃｃをリセットして（ステップＳ２００６）、ステップＳ１６０８に移行する。

これにより、保存対象イベントとともに信頼度も保存されるため、管理者がＤＢ４０８（統合管理ＤＢ１０３）を参照する際に、信頼度に応じて、ＤＢ１２４〜１２６を検索するかしないかの判断指標とすることができる。

以上説明したように、情報管理装置、情報管理方法、および情報管理プログラムによれば、障害の基点となるイベントを保存対象イベントに決定するため、たとえ重要なイベントであっても、障害の基点にならないような不要なイベントの保存を抑制することができる。

換言すれば、障害の基点となるイベントさえ保存できていれば、そのイベントが持つ情報をキーにして、依存関係情報を参照して依存関係が伝搬する管理対象からのイベントを、ＤＢ１２４〜１２６から検索すればよい。したがって、保存データ量の削減とイベント検索の効率化を図ることができる。また、障害の基点となるイベントがわかれば、当該イベントを発生した管理対象を容易に特定できるため、メンテナンスの容易化も図ることができる。

また、信頼度に応じて基点となるイベントを保存することができるため、イベント通知がないような例外的な場合であっても、イベント保存量の削減を図ることができる。また、所定信頼度Ｐの設定しだいで保存対象イベント量を調整することができるため、管理者の人数や能力に応じて柔軟に対応することができる。

さらに、保存対象イベントとともに信頼度も保存されるため、管理者がデータベース（統合管理ＤＢ１０３）を参照する際に、信頼度に応じて、ＤＢ１２４〜１２６を検索するかしないかの判断指標とすることができる。

また、本実施の形態では、障害イベントや監視イベントを通知するものであれば管理対象とすることができる。たとえば、クラウドコンピューティングにおいて、ネットワーク構成またはサーバ、クライアント、さらにその中間に存在する論理レイヤを示した管理対象として適用することができる。

この場合、たとえば、クラウドコンピューティング環境で利用されるサーバやクライアント、それらをつなぐネットワークなどを監視するシステムにおいて、膨大なイベントをログとして保存しなければならないストレージを装備するシステムに有効である。

以上のことから、本実施の形態によれば、情報の保存量を効率的に削減することができるという効果を奏する。

なお、本実施の形態で説明した情報管理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報管理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本情報管理プログラムは、インターネット等のネットワークを介して配布してもよい。

１００ 情報管理システム
１０１ 管理対象装置
１０２ 管理機能
１１３ 業務プロセス
１２７ 統合管理機能
４００ 情報管理装置
４０１ 取得部
４０２ 特定部
４０３ 抽出部
４０４ 判定部
４０５ 決定部
４０６ 算出部
４０７ 保存部
５００ プロセス割当テーブル
６００，７００，８０１〜８０６，９０１〜９０６ 依存関係情報
１０３ 統合管理ＤＢ

Claims (7)

1. 依存関係がある管理対象群で発生したイベント群の中から、依存元管理対象で発生した第１のイベントと前記依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせを抽出する抽出工程と、
   前記抽出工程によって抽出された組み合わせごとに、前記第１のイベントの発生時刻と前記第２のイベントの発生時刻との差分により、前記第１のイベントと前記第２のイベントとの依存関係の有無を判定する判定工程と、
   前記判定工程によって判定された判定結果に基づいて、前記イベント群のうち、前記依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定する決定工程と、
   前記決定工程によって決定された保存対象イベントに関する情報をデータベースに保存する保存工程と、
   をコンピュータに実行させることを特徴とする情報管理プログラム。
2. 前記決定工程は、
   前記判定工程によって前記組み合わせのすべてにおいて依存関係有りと判定された場合、前記依存先管理対象にならない依存元管理対象で発生したイベントを前記保存対象イベントに決定する請求項１に記載の情報管理プログラム。
3. 前記組み合わせの総数と前記第１のイベントおよび前記第２のイベントが抽出された組み合わせの数とに基づいて、前記保存対象イベントに関する信頼度を算出する算出工程を前記コンピュータに実行させ、
   前記決定工程は、
   前記算出工程によって算出された信頼度に基づいて、前記依存先管理対象にならない依存元管理対象で発生したイベントを前記保存対象イベントに決定することを特徴とする請求項１または２に記載の情報管理プログラム。
4. 前記組み合わせの総数と前記第１のイベントおよび前記第２のイベントが抽出された組み合わせの数とに基づいて、前記保存対象イベントに関する信頼度を算出する算出工程を前記コンピュータに実行させ、
   前記保存工程は、
   前記保存対象イベントとともに前記算出工程によって算出された信頼度を保存することを特徴とする請求項１または２に記載の情報管理プログラム。
5. 前記管理対象の種類ごとのイベントが格納された前記管理対象の種類ごとのデータベース群から所定期間内に発生したイベント群を取得する取得工程と、
   前記取得工程によって取得されたイベント群内の各イベントに記述されている発生元の管理対象に関する情報に基づいて、前記依存関係がある管理対象群を特定する特定工程と、を前記コンピュータに実行させ、
   前記抽出工程は、
   前記特定工程によって特定された前記依存関係がある管理対象群で発生したイベント群の中から、前記第１のイベントと前記第２のイベントとの組み合わせを抽出することを特徴とする請求項１〜４のいずれか１つに記載の情報管理プログラム。
6. 依存関係がある管理対象群で発生したイベント群の中から、依存元管理対象で発生した第１のイベントと前記依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせを抽出する抽出手段と、
   前記抽出手段によって抽出された組み合わせごとに、前記第１のイベントの発生時刻と前記第２のイベントの発生時刻との差分により、前記第１のイベントと前記第２のイベントとの依存関係の有無を判定する判定手段と、
   前記判定手段によって判定された判定結果に基づいて、前記イベント群のうち、前記依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定する決定手段と、
   前記決定手段によって決定された保存対象イベントに関する情報をデータベースに保存する保存手段と、
   を備えることを特徴とする情報管理装置。
7. コンピュータが、
   依存関係がある管理対象群で発生したイベント群の中から依存元管理対象で発生した第１のイベントと前記依存元管理対象に依存する依存先管理対象で発生した第２のイベントとの組み合わせを抽出する抽出工程と、
   前記抽出工程によって抽出された組み合わせごとに、前記第１のイベントの発生時刻と前記第２のイベントの発生時刻との差分により、前記第１のイベントと前記第２のイベントとの依存関係の有無を判定する判定工程と、
   前記判定工程によって判定された判定結果に基づいて、前記イベント群のうち、前記依存先管理対象にならない依存元管理対象で発生したイベントを保存対象イベントに決定する決定工程と、
   前記決定工程によって決定された保存対象イベントに関する情報をデータベースに保存する保存工程と、
   を実行することを特徴とする情報管理方法。

Images