JP2006031109A - 管理システム及び管理方法 - Google Patents

Abstract

【課題】様々な装置やシステムにおいて障害原因を特定可能な管理システムを提供する。
【解決手段】管理システム１００は、イベント監視部１と、依存関係抽出部２と、格納部３と、データベース４と、原因特定部５と、障害検出部６と、更新部７ａと、契機検出部７ｂと、更新規則記憶部８とを備える。管理システム１００は、管理対象である装置やシステムに発生したイベントを検出し、イベントに関する依存関係を抽出して、イベントと依存関係に基づいて障害原因を特定する。
【選択図】図１

Description

本発明は、システムや装置を管理する管理システム及び管理方法に関する。特に、本発明は、システムや装置に発生した障害原因の特定に好適な管理システム及び管理方法に関する。

近年、携帯電話端末等の装置やシステムの高機能化に伴い、ソフトウェアやハードウェアの構成要素が増加し、装置やシステムは複雑化の一途を辿っている。一般に、高度化し、複雑化した装置やシステムにおいて、バグや脆弱性を根絶することは困難であり、障害発生は不可避である。更に、構成要素の増加に伴って要素間の相互依存の数は自乗で増加するため、障害発生時にその根本原因を特定することは困難な傾向にある。

一方、例えば、携帯電話端末やネットワーク等は、緊急通報等を行う通信インフラとして特に高い信頼性が要求される。そのため、脆弱性を利用した攻撃やソフトウェアのバグによって携帯電話端末やネットワーク等に障害が発生した場合であっても、迅速にその原因を除去し、その機能を復旧することが要求される。従って、障害原因を効率的に特定する機能が求められている。

従来、障害原因の特定を容易にする装置として、ある構成要素の障害が他の構成要素に影響し、障害が伝搬するようなネットワークにおいて、ある構成要素に障害が発生した際に、その構成要素に依存する構成要素で発生した障害に抑止フラグを設定することで、同一障害に起因する冗長な警告の発生を抑止し、根本原因の追跡を容易にするネットワーク管理装置がある（例えば、特許文献１参照）。

又、障害イベント間の伝搬モデルとネットワーク構成情報とに基づいて、入力される複数の障害イベントの原因を推論するシステムも提案されている（例えば、特許文献２参照）。この技術では、各障害原因が伝搬モデル上で引き起こすと考えられる障害イベントの個数の上限値が予め既知であることを前提に、障害原因毎にインデックスを付与し、メモリ利用量の少ない原因推定手法を提案している。更に、障害イベントの履歴から障害イベント間の相互相関を計算して記述漏れのあった障害伝搬ルールを検出し、伝搬モデルを更新するフィードバック手段も開示されている。

更に、計算機のオペレーションシステム（基本ソフト）上で発生するイベントのログから、オペレーションシステムが管理するオブジェクト間の依存モデルを構築する手法も提案されている（例えば、非特許文献１参照）。この技術では、障害イベント発生後にイベントログを解析することにより、障害イベントを基点とした依存モデルを生成、表示し、原因解析を支援する。
特開２００１−１２５８５４号公報 特開平１１−３０８２２１号公報 S.King, P.Chen, "Backtracking Intrusions", ACM SOSP 2003

しかしながら、特許文献１に開示されているネットワーク管理装置は、多数の構成要素が起こす障害イベントの中から根本原因となっている障害イベントを特定するものであり、原因となり得る障害イベントは事前に選別されていることを前提としている。即ち、このネットワーク管理装置が追跡可能な原因は、事前に識別可能な障害イベントに限られてしまう。このため、根本原因となるイベントが事前に識別不可能な場合、これを追跡することはできない。しかし、障害の根本原因となるイベントには様々なものがあり、障害イベント発生時に原因となるか否かを判定することは困難である。

又、特許文献２に開示されているシステムは、障害イベントの個数の上限値が予め既知であるという前提が必要である。この前提は、妥当な伝搬モデルが事前に構築されている場合にのみ成立する。そのため、簡単なネットワークのようにシステム構成が管理者に既知であり、障害原因及びそれに起因する障害イベントを予測可能な場合には適用できたとしても、複雑なネットワークやユーザがソフトウェアやハードウェアの構成要素を自由に拡張できる装置には適用できない。又、この技術では、記述漏れのあった障害伝搬ルールを検出し、伝搬モデルを更新することができるが、あくまでも記述漏れを補足する程度であり、障害伝搬ルールが全く存在しない状態から精度の高い伝搬モデルを構築することはできない。

更に、非特許文献１に開示の手法では、オペレーションシステムが記録したイベントログからオブジェクト間の依存モデルを構築するため、障害原因に関する事前知識は不要となる。しかし、動作中に全てのイベントログを蓄積する必要があるため、必要な記憶容量が実行に伴い増加してしまう。

即ち、いずれの従来技術においても、前提条件や記憶容量等の制約があり、前提条件を満たさない場合や、記憶容量が不十分な場合には、適切に障害原因を特定することができなかった。

そこで、本発明は、様々な装置やシステムにおいて障害原因を特定可能な管理システム及び管理方法を提供することを目的とする。

本発明に係る管理システムは、発生したイベントを検出するイベント監視部と、イベントに関する依存関係を抽出する依存関係抽出部と、イベント及び依存関係を保持する保持部と、更新規則に従って保持部を更新する更新部と、イベントと依存関係に基づいて発生した障害原因を特定する原因特定部とを備えることを特徴とする。

このような管理システムによれば、装置やシステムに発生したイベントを検出し、イベントに関する依存関係を抽出して、イベントと依存関係に基づいて障害原因を特定できる。そのため、管理システムは、予めイベントや依存関係、障害原因に関する情報が既知でなければならないといった前提条件を必要としない。更に、管理システムは、更新規則に従って保持部が保持するイベントや依存関係を更新できる。よって、管理システムは、予め情報を保持しておく必要がないだけでなく、検出したイベントや抽出した依存関係を適宜更新し、必要な情報のみを保持できる。そのため、管理システムは、必要とする記憶容量や情報の処理量を削減できる。以上のことから、管理システムは、前提条件や記憶容量の面からの制約を受けないため、様々な装置やシステムにおいて障害原因を特定できる。特に、管理システムは、記憶容量や演算能力に制約がある装置やシステムにおいても障害原因を特定できる利点がある。

管理システムは、更に、更新規則を適用する更新契機を検出し、その検出した更新契機を更新部に通知する契機検出部を備えることができる。そして、更新部は、契機検出部から通知された更新契機により適用する更新規則に従って保持部を更新することができる。これによれば、更新規則に従った更新を実行する更新契機を明示的に指定することが可能となる。

更に、保持部は、イベント又は依存関係の属性情報として、更新規則に関する情報を保持し、更新部は、更新規則に関する情報に基づいて保持部を更新することが好ましい。これによれば、イベントや依存関係毎に更新を制御でき、より柔軟な制御ができる。

属性情報は、例えば、更新規則を識別する識別子を用いることができ、更新部は、識別子により特定される更新規則に従って保持部を更新することができる。これによれば、各イベントや依存関係に適用する更新規則を明示的に指定することができる。

更に、イベント監視部はイベントに尤度を付与し、保持部は尤度をイベントと対応付けて保持し、原因特定部は、尤度に基づいて障害原因を特定することが好ましい。これによれば、管理システムは、尤度に基づいて可能性の高い障害原因を選択することができ、障害原因特定の精度を向上できる。

このとき、イベント監視部は、イベントの種別、又は、イベントに依存するイベントの尤度の少なくとも１つに基づいて付与する尤度を決定することが好ましい。これによれば、管理システムは、イベントの種別に応じた尤度を付与することや、依存関係に基づいてイベントの尤度を依存するイベントに伝播させることができる。よって、管理システムはより適切に尤度を付与し、障害原因特定の精度を更に向上できる。

又、保持部は、第１保持部と第２保持部を備え、更新部は、第１保持部からイベント及び依存関係を取得して更新し、更新後のイベント及び依存関係を第２保持部に格納するようにしてもよい。これによれば、管理システムは、第１保持部に一時的に情報を保持し、必要な情報だけを第２保持部に保持しておくことができる。しかも、第２保持部が保持する情報量を削減できる。

本発明に係る管理方法は、発生したイベントを検出するステップと、イベントに関する依存関係を抽出するステップと、更新規則に従ってイベント及び依存関係を保持する保持部を更新するステップと、イベントと依存関係に基づいて発生した障害原因を特定するステップとを有することを特徴とする。

以上説明したように、本発明によれば、様々な装置やシステムにおいて障害原因を特定可能な管理システム及び管理方法を提供することができる。

〔第１の実施形態〕
図１に示すように管理システム１００は、イベント監視部１と、依存関係抽出部２と、格納部３と、データベース４と、原因特定部５と、障害検出部６と、更新部７ａと、契機検出部７ｂと、更新規則記憶部８とを備える。

イベント監視部１は、管理システム１００の管理対象であるシステムや装置において発生したイベントを検出する。例えば、イベント監視部１は、オペレーティングシステム（ＯＳ）上で実行されるプロセスが発するシステムコールやシステム設定ファイルの書き込み等をイベントとして監視し、検出する。

更に、イベント監視部１は、更新規則記憶部８からルールＩＤを取得する。更新規則記憶部８は、管理システム１００が保持する情報の更新に関する更新規則を記憶する。更新規則には、更新規則を識別するための識別子としてルールＩＤが付与されている。イベント監視部１は、検出したイベントに基づいて、そのイベントに適用する更新規則を選択する。例えば、イベント監視部１は、イベントの重要度等に応じて更新規則を選択できる。そして、イベント監視部１は、選択した更新規則に付与されているルールＩＤを取得する。イベント監視部１は、検出したイベント、そのイベント発生時間、ルールＩＤを格納部３に入力する。更に、イベント監視部１は、検出したイベントを依存関係抽出部２に入力する。例えば、イベント監視部１は、オペレーティングシステム（ＯＳ）内のモジュールとして実装できる。

依存関係抽出部２は、イベントに関する依存関係を抽出する。依存関係抽出部２は、イベント監視部１から検出されたイベントを取得する。依存関係抽出部２は、管理対象であるシステムや装置に含まれる構成要素、システムや装置が行うプロセス、検出されたイベントに基づいて依存関係を抽出する。依存関係には、イベント間の依存関係、イベントにおける構成要素間の依存関係、イベントにおけるプロセス間の依存関係、イベントと構成要素の依存関係、イベントとプロセスの依存関係等がある。構成要素には、メモリやファイル等がある。構成要素は、例えば、オペレーティングシステム（ＯＳ）上で実行されるプロセス等が利用する。

例えば、依存関係抽出部２は、イベント監視部１からシステム設定ファイル書き込みイベントを取得した場合、システム設定ファイルのファイル名とシステム設定ファイルへのパスを、システム設定ファイル書き込みイベントに依存する「依存元」の構成要素、システム設定ファイル書き込みイベントを発生させたプロセス名をシステム設定ファイル書き込みイベントが依存する依存先のプロセスとして抽出する。依存関係抽出部２は、抽出した依存関係を格納部３に入力する。

尚、依存関係抽出部２が、抽出した依存関係に基づいて、その依存関係に適用する更新規則を選択するようにしてもよい。この場合、例えば、依存関係抽出部２は、依存関係の重要度等に応じて更新規則を選択できる。依存関係抽出部２は、更新規則記憶部８から選択した更新規則に付与されているルールＩＤを取得する。そして、依存関係抽出部２は、抽出した依存関係とあわせてルールＩＤを格納部３に入力する。

格納部３は、イベント監視部１から検出されたイベント、イベント発生時間、ルールＩＤを取得し、依存関係抽出部２から抽出された依存関係を取得する。格納部３は、取得したイベントと、イベント発生時間と、ルールＩＤ、依存関係とを対応付けてデータベース４に格納する。

データベース４は、イベントと依存関係を保持する保持部である。データベース４は、イベント及び依存関係だけでなく、イベント又は依存関係の属性情報を、イベント又は依存関係と対応付けて保持することができる。属性情報には、イベント発生時間や更新規則に関する情報等がある。更新規則に関する情報としては、イベントや依存関係の更新に適用する更新規則を識別する識別子（ルールＩＤ）等がある。更新規則に関する情報は、イベントや依存関係の更新に更新規則を適用する際に参照される。

データベース４は、図２に示すように、イベントＩＤと、イベントと、依存先と、依存元と、イベント発生時間と、更新規則のフィールドを備える。依存関係は依存先と依存元により表される。更新規則のフィールドにはルールＩＤが格納される。適用するルールＩＤがない場合には、更新規則のフィールドにはＮＵＬＬ値が設定される。格納部３は、イベントにイベントの識別子であるイベントＩＤを付与し、イベントＩＤに対応付けてイベント、依存関係、イベント発生時間、ルールＩＤを格納する。

更新部７ａは、更新規則に従ってデータベース４を更新する。更新部７ａは、更新規則記憶部８から更新規則を取得する。更新規則は、重要度の低い情報や一時的な情報の削除、複数のイベントとその依存関係の縮退等を実行する規則を定めることができる。具体的には、更新規則記憶部８は、図３に示すように、更新規則を記憶する更新規則テーブル８１と、更新契機規則を記憶する更新契機規則テーブル８２と備える。更新規則テーブル８１は、ルールＩＤと、適用条件と、更新内容とを対応付けて記憶する。このように更新規則は、更新内容とその更新内容を適用する適用条件とを含み、各更新規則にはルールＩＤが付与されている。

更新契機規則テーブル８２は、更新契機と、その更新契機により適用する更新規則のルールＩＤとを対応付けて保持する。このように更新契機規則は、更新契機とその更新契機により適用する更新規則の識別子とを記述したものを用いることができる。更新契機規則テーブル８２は、１つの更新契機に複数のルールＩＤを対応付けて保持する場合、更新規則の適用順にルールＩＤを保持する。更新契機は、例えば、管理対象であるシステムや装置の様々な契機における負荷やメモリ使用量等に基づいて設定できる。これにより、計算機能力や記憶容量等のリソースに制約のある装置やシステムへの管理システム１００の適用が容易となる。

契機検出部７ｂが、これらの更新規則を適用する更新契機を検出し、その検出した更新契機を更新部７ａに通知する。更新部７ａは、契機検出部７ｂから検出された更新契機の通知を受ける。更新部７ａは、契機検出部７ｂから通知された更新契機により適用する更新規則に従ってデータベース４を更新する。具体的には、更新部７ａは、通知された更新契機に基づいて更新契機規則テーブル８２を検索し、検出された更新契機により適用する更新規則のルールＩＤを取得する。更新部７ａは、取得したルールＩＤに基づいて、更新規則テーブル８１から更新規則として適用条件と更新内容を取得する。そして、更新部７ａは、取得した適用条件と更新内容に従ってデータベース４を更新する。

更に、更新部７ａは、データベース４を参照し、検出された更新契機により適用される更新規則のルールＩＤが対応付けられているイベントや依存関係について、更新規則に従って更新を行う。このように更新部７ａは、イベント又は依存関係の属性情報である更新規則に関する情報に基づいて、データベース４を更新する。具体的には、更新部７ａは、データベース４を参照し、まず、イベントや依存関係に対応付けられているルールＩＤがあり、そのイベントや依存関係に適用する更新規則が存在するか否かを判断する。更新部７ａは、ルールＩＤが対応付けられている場合には、そのルールＩＤにより特定される更新規則に従ってデータベース４を更新する。更新部７ａは、適用する更新規則が存在しない場合には、データベース４を更新しないと判断できる。尚、図２に示すデータベース４では、１つのイベントに対して１つのルールＩＤが対応付けられているが、１つのイベントに対して適用される更新規則の数は限定されない。そのため、データベース４は、１つのイベントに対して複数のルールＩＤを対応付けて保持してもよい。

例えば、契機検出部７ｂがデータベース４への新規イベントの格納を検出し、更新部７ａに通知する。通知を受けた更新部７ａは、更新契機規則テーブル８２を参照し、更新契機「新規イベント追加」に対応付けられたルールＩＤ「０ｘ０２」の更新規則を実行すると判断する。そして、更新部７ａは、データベース４においてルールＩＤ「０ｘ０２」が属性情報として対応付けられているイベントや依存関係を、更新規則テーブル８１が記憶する適用条件と更新内容に従って更新する。この場合、データベース４においてルールＩＤ「０ｘ０２」が付与されているイベントが更新対象イベントとなり、新規イベントが比較イベントとなる。

更新部７ａは、適用条件「更新対象イベントのイベント発生時間が比較イベントのイベント発生時間よりも早く、かつ、更新対象イベントの依存元が比較イベントの依存先と等しい」を満たす場合に、更新内容「更新対象イベントに関する情報を比較イベントに関する情報に置き換える」を行う。これにより、例えば、更新部７ａは、共有メモリを介したプロセス間通信についてデータベース４に格納する場合に、共有メモリへの書き込みイベントを共有メモリからの読み出しイベントに置き換えることができる。そのため、冗長な依存関係を削除することができる。

障害検出部６は、管理対象である装置やシステムに発生した障害を検出する。例えば、障害検出部６は、カーネルによるプロセス異常終了の通知や、ユーザによる通知等を取得することにより障害を検出する。障害検出部６は、障害検出を原因特定部５に通知する。障害検出部６は、障害が発生した構成要素やプロセス名（以下「障害発生要素」という）と、障害発生時間を通知する。例えば、障害検出部６は、障害検出シグナルを原因特定部５に送出する。

原因特定部５は、イベントと依存関係に基づいて発生した障害原因を特定する。原因特定部５は、障害検出部６から障害検出の通知を受けると、原因特定処理を開始する。原因特定部５は、データベース４を参照し、イベントや依存関係等を解析することにより原因を特定する。図４に、原因特定部５による障害原因の探索手順の概念図を示す。図４では、複数の円がイベントを示す。「Ｎ」〜「Ｎ−１２」はイベント名である。そして、依存元のイベントから依存先のイベントに向けて矢印を示す。又、図４の上方から下方に向けて時間の経過を示す。

原因特定部５は、障害検出部６から通知された障害発生要素、例えば、障害発生プロセスを起点に依存関係を遡る。原因特定部５は、通知された障害発生時間から、時間の経過と逆方向に、障害発生プロセスを起点に依存関係を遡る。これにより、原因特定部５は、障害発生プロセスが直接的又は間接的に依存しているイベントを探索し、障害原因の候補として特定する。図４の場合、原因特定部５は、イベント「Ｎ」、「Ｎ−２」、「Ｎ−３」、「Ｎ−５」、「Ｎ−６」、「Ｎ−７」、「Ｎ−１０」、「Ｎ−１２」を障害原因の候補として特定する。原因特定部５は、特定した障害原因の候補を、管理対象の装置やシステムの制御部や表示部等に出力する。

障害原因には、例えば、システム設定ファイルの修正ミス、バグを含むアプリケーションやデバイスドライバのインストール、ウィルス等の悪意あるプログラムによるシステム改変等がある。

このような管理システム１００は、管理対象である装置やシステムの一部として設けることができる。又、管理システム１００は、管理対象である装置やシステムに接続して設けてもよい。このような管理システムは、コンピュータに、発生したイベントを検出するイベント監視部と、イベントに関する依存関係を抽出する依存関係抽出部と、イベント及び依存関係を保持する保持部と、更新規則に従って保持部を更新する更新部と、イベントと依存関係に基づいて発生した障害原因を特定する原因特定部として機能させるためのプログラムを実行させることにより実現できる。

次に、図１に示す管理システム１００が行う管理方法の手順を、図５〜７を用いて説明する。図５にイベントと依存関係の管理方法を示す。管理システム１００は、管理対象の装置やシステムに発生したイベントを検出する（Ｓ１０１）。管理システム１００は、検出したイベントに関する更新規則（ルールＩＤ）を選択する（Ｓ１０２）。管理システム１００は、発生したイベントに関する依存関係を抽出する（Ｓ１０３）。管理システム１００は、イベント、依存関係、ルールＩＤ等をデータベース４に格納する（Ｓ１０４）。管理システム１００は、更新契機を検出する（Ｓ１０５）。管理システム１００は、検出した更新契機により適用する更新規則を更新規則記憶部８から取得する（Ｓ１０６）。管理システム１００は、取得した更新規則に従ってデータベース４を更新する（Ｓ１０７）。

図６に原因特定部５の処理手順を示す。原因特定部５は、障害検出部６から障害発生要素と障害発生時間を取得する。原因特定部５は、鍵（ｋｅｙ）に障害発生要素を代入し、時間（ｔｉｍｅ）に障害発生時間を代入する（Ｓ２０１）。原因特定部５は、障害発生要素を鍵（ｋｅｙ）に、障害発生時間（ｔｉｍｅ）も用いて障害原因の候補を特定する（Ｓ２０２）。原因特定部５は、特定した障害原因の候補を出力する（Ｓ２０３）。

図７に、障害原因の特定手順、即ち、図６に示したステップ（Ｓ２０２）のより詳細な手順を示す。原因特定部５は、取得した障害発生時間（ｔｉｍｅ）に基づいてデータベース４を検索し、障害発生時間の直前のイベントを特定する。更に、原因特定部５は、直前のイベントのイベント発生時間を時間（ｔｉｍｅ）に代入する（Ｓ３０１）。原因特定部５は、直前のイベントの依存元が、取得した障害発生要素（ｋｅｙ）と一致するか否かを判定する（Ｓ３０２）。一致する場合、原因特定部５は、直前のイベントに障害発生要素が依存していると判断し、直前のイベントを障害原因の候補として特定し、記憶する（Ｓ３０３）。

更に、原因特定部５は、障害原因の候補として特定したイベント（以下「特定済みイベント」という）が依存している他のイベントを探索するために、鍵（ｋｅｙ）に特定済みイベントの依存先を代入し、図４に示した障害原因の探索手順に従う処理を再起的に呼び出す（Ｓ３０４）。そして、原因特定部５は、特定済みイベントの依存先（ｋｅｙ）及びイベント発生時間（ｔｉｍｅ）に基づいてデータベース４を検索する（Ｓ３０５）。

原因特定部５は、ステップ（Ｓ３０５）に続いて、あるいは、ステップ（Ｓ３０２）において、直前のイベントの依存元が障害発生要素（ｋｅｙ）と一致しない場合に、特定済みイベントの直前のイベントの特定を試みる。更に、原因特定部５は、特定済みイベントの直前のイベントのイベント発生時間を時間（ｔｉｍｅ）に代入する（Ｓ３０６）。原因特定部５は、ステップ（Ｓ３０６）において直前のイベントを特定できるか否かを判断する（Ｓ３０７）。即ち、原因特定部５は、直前のイベントが存在するか、存在しないか（ＮＵＬＬ）を判断する。

原因特定部５は、直前のイベントが存在する場合には、そのイベントを障害原因の候補として特定する。そして、直前のイベントが存在する限り、ステップ（Ｓ３０２）に戻り、ステップ（Ｓ３０２）〜（Ｓ３０７）を繰り返し実行する。一方、原因特定部５は、直前のイベントが存在しない（ＮＵＬＬ）場合、処理を終了する。

このような管理システム１００及び管理方法によれば、管理対象である装置やシステムに発生したイベントを検出し、イベントに関する依存関係を抽出して、イベントと依存関係に基づいて障害原因を特定できる。そのため、管理システム１００は、予めイベントや依存関係、障害原因に関する情報が既知でなければならないといった前提条件を必要としない。更に、管理システム１００は、更新規則に従って保持部が保持するイベントや依存関係を更新できる。よって、管理システム１００は、予め情報を保持しておく必要がないだけでなく、検出したイベントや抽出した依存関係を適宜更新し、必要な情報のみを保持できる。そのため、管理システム１００は、必要とする記憶容量や情報の処理量を削減できる。

以上のことから、管理システム１００は、前提条件や記憶容量の面からの制約を受けないため、様々な装置やシステムにおいて障害原因を特定できる。更に、情報の処理量を削減できることから、障害原因の特定が容易になり、障害からの復旧に要する時間を削減できる。

例えば、管理システム１００では、全てのイベントに関する情報を保持し、管理する必要がないため、多数の構成要素を含む複雑な装置やシステムにおいて保持する情報量が膨大になってしまうことを防止できる。又、障害原因の発生から実際に障害が発生するまでの時間間隔の増加に伴って、保存すべき情報量や解析に要する処理量が増加し、蓄積容量や演算能力に制約のある装置やシステムにおける障害原因特定が困難になることも防止できる。よって、管理システム１００は、記憶容量や演算能力に制約がある携帯電話端末のような装置や、システムにおいても障害原因を特定できる。

更に、管理システム１００では、契機検出部７ｂが更新規則を適用する更新契機を検出し、その検出した更新契機を更新部７ａに通知する。そして、更新部７ａが、契機検出部７ｂから通知された更新契機により適用する更新規則に従ってデータベース４を更新することができる。そのため、管理システム１００では、更新規則に従った更新を実行する更新契機を明示的に指定することが可能となる。

又、データベース４は、イベント又は依存関係の属性情報として、更新規則に関する情報を保持し、更新部７ａは、更新規則に関する情報に基づいてデータベース４を更新できる。そのため、管理システム１００は、イベントや依存関係毎に更新を制御でき、より柔軟な制御ができる。例えば、管理システム１００は、イベントや依存関係毎に適用する更新規則を制御することができ、イベントや依存関係の重要度等に応じて、柔軟に更新を制御することができる。

特に、管理システム１００では、属性情報としてルールＩＤを用いることができ、更新部７ａは、ルールＩＤにより特定される更新規則に従ってデータベース４を更新することができる。そのため、管理システム１００では、各イベントや依存関係に適用する更新規則を明示的に指定することができる。

〔第２の実施形態〕
図８に示すように、管理システム２００は、イベント監視部２０１と、依存関係抽出部２と、格納部２０３と、データベース２０４と、原因特定部２０５と、障害検出部６と、更新部２０７ａと、契機検出部７ｂと、更新規則記憶部８と、尤度決定規則記憶部９を備える。図８では、図１に示した管理システム１００と実質的に同一の構成には同一の符号を付して説明を省略する。

イベント監視部２０１は、検出したイベントに尤度を付与する。イベント監視部２０１は、イベントの種別、又は、イベントに依存するイベントの尤度の少なくとも１つに基づいて付与する尤度を決定することが好ましい。具体的には、イベント監視部２０１は、尤度決定規則に基づいて付与する尤度を決定する。尤度決定規則は、尤度決定規則記憶部９が記憶する。尤度決定規則には、例えば、イベントの種別と尤度の対応付けや、イベントに依存するイベントの尤度に基づいて尤度を決定するといった決定規則等が含まれる。イベントの種別に基づく尤度は、例えば、管理対象である装置やシステムに与える影響の大きさに従って設定することができる。例えば、システム設定ファイルの変更イベント等には高い尤度を設定することができる。

データベース２０４は、尤度をイベントと対応付けて保持する。図９に示すように、データベース２０４は、イベントＩＤと、イベントと、依存先と、依存元と、イベント発生時間と、尤度と、更新規則のフィールドを備える。格納部２０３は、イベントにイベントＩＤを付与し、イベントＩＤに対応付けてイベント、依存関係、イベント発生時間、尤度、ルールＩＤを格納する。更新部２０７ａは、尤度も更新する。

原因特定部２０５は、尤度に基づいて障害原因を特定する。図１０に、原因特定部２０５による障害原因の探索手順の概念図を示す。図１０は、図４と同様にイベント間の関係等を表現している。原因特定部２０５は、図４の場合と同様にして、障害検出部６から通知された障害発生要素（障害発生プロセス等）を起点に依存関係を遡り、障害発生プロセスが直接的又は間接的に依存しているイベントを探索する。

次に、原因特定部２０５は、障害発生プロセスが直接的又は間接的に依存している各イベントの尤度を変数Ｍｉ（ｉはイベント名を示す）に累積加算する。そして、原因特定部２０５は、変数Ｍｉが予め規定された閾値よりも大きくなったイベントだけを障害原因の候補として特定する。図１０では、原因特定部２０５は、閾値を越えた変数「Ｍ_Ｎ−５」、「Ｍ_Ｎ−７」、「Ｍ_Ｎ−１２」を持つイベント「Ｎ−５」、「Ｎ−７」、「Ｎ−１２」を障害原因の候補として特定する。

あるいは、原因特定部２０５は、障害発生プロセスが直接的又は間接的に依存しているイベントの尤度を比較し、尤度が高く障害原因である可能性が高いイベントを障害原因の候補として選択してもよい。例えば、原因特定部２０５は、尤度に基づいてイベントに順番を付け、上位所定数のイベントを障害原因の候補として選択してもよい。イベント監視部２０１、格納部２０３、原因特定部２０５、更新部２０７ａは、これらの点以外は図１に示したイベント監視部１、格納部３、原因特定部５、更新部７ａと実質的に同様である。

次に、図８に示す管理システム２００が行う管理方法の手順を、図１１〜１３を用いて説明する。図１１にイベントと依存関係の管理方法を示す。管理システム２００は、管理対象の装置やシステムに発生したイベントを検出する（Ｓ４０１）。管理システム２００は、検出したイベントに関する更新規則（ルールＩＤ）を選択する。更に、管理システム２００は、検出したイベントの尤度を尤度決定規則に基づいて決定し、イベントに尤度を付与する（Ｓ４０２）。管理システム２００は、発生したイベントに関する依存関係を抽出する（Ｓ４０３）。管理システム２００は、イベント、依存関係、尤度、ルールＩＤ等をデータベース２０４に格納する（Ｓ４０４）。管理システム２００は、更新契機を検出する（Ｓ４０５）。管理システム２００は、検出した更新契機により適用する更新規則を更新規則記憶部８から取得する（Ｓ４０６）。管理システム２００は、取得した更新規則に従ってデータベース２０４を更新する（Ｓ４０７）。

図１２に原因特定部２０５の処理手順を示す。原因特定部２０５は、障害検出部６から障害発生要素（ｋｅｙ）と障害発生時間（ｔｉｍｅ）を取得する。原因特定部２０５は、鍵（ｋｅｙ）に障害発生要素を代入し、時間（ｔｉｍｅ）に障害発生時間を代入する。原因特定部２０５は、変数Ｍｉを用いて障害原因を特定する場合、変数Ｍｉを初期化する（Ｓ５０１）。原因特定部２０５は、障害発生要素を鍵（ｋｅｙ）に、障害発生時間（ｔｉｍｅ）も用いて、尤度に基づいて障害原因の候補を特定する（Ｓ５０２）。原因特定部２０５は、特定した障害原因の候補をその尤度と共に出力する（Ｓ５０３）。

図１２に、障害原因の特定手順、即ち、図１１に示したステップ（Ｓ５０２）の一例のより詳細な手順を示す。原因特定部２０５は、尤度を累積加算していく変数、即ち、尤度の累積値を格納する変数Ｍｉをローカル変数Ｍｉ’に代入する（Ｓ６０１）。原因特定部２０５は、取得した障害発生時間（ｔｉｍｅ）に基づいてデータベース２０４を検索し、障害発生時間の直前のイベントを特定する。更に、原因特定部２０５は、直前のイベントのイベント発生時間を時間（ｔｉｍｅ）に代入する（Ｓ６０２）。

原因特定部２０５は、直前のイベントの依存元が、取得した障害発生要素（ｋｅｙ）と一致するか否かを判定する（Ｓ６０３）。一致する場合、原因特定部２０５は、変数Ｍｉに直前のイベントの尤度を累積加算する（Ｓ６０４）。原因特定部２０５は、累積加算後の変数Ｍｉが閾値よりも大きいか否かを判断する（Ｓ６０５）。原因特定部２０５は、累積加算後の変数Ｍｉが閾値よりも大きいと判断した場合には、直前のイベントを障害原因の候補として特定し、記憶する（Ｓ６０６）。ステップ（Ｓ６０６）に続いてステップ（Ｓ６０７）に進む。又、ステップ（Ｓ６０５）において累積加算後の変数Ｍｉが閾値よりも小さいと判断した場合には、原因特定部２０５は、ステップ（Ｓ６０６）をバイパスし、ステップ（Ｓ６０７）に進む。

原因特定部２０５は、鍵（ｋｅｙ）に特定済みイベントの依存先を代入し、図１０に示した障害原因の探索手順に従う処理を再起的に呼び出す（Ｓ６０７）。そして、原因特定部２０５は、特定済みイベントの依存先（ｋｅｙ）及びイベント発生時間（ｔｉｍｅ）に基づいてデータベース２０４を検索する（Ｓ６０８）。

原因特定部２０５は、ステップ（Ｓ６０８）に続いて、あるいは、ステップ（Ｓ６０３）において、直前のイベントの依存元が障害発生要素（ｋｅｙ）と一致しない場合に、特定済みイベントの直前のイベントの特定を試みる。更に、原因特定部２０５は、特定済みイベントの直前のイベントのイベント発生時間を時間（ｔｉｍｅ）に代入する（Ｓ６０９）。

原因特定部２０５は、ステップ（Ｓ６０９）において直前のイベントを特定できるか否かを判断する（Ｓ６１０）。即ち、原因特定部２０５は、直前のイベントが存在するか、存在しないか（ＮＵＬＬ）を判断する。原因特定部２０５は、直前のイベントが存在する場合には、ステップ（Ｓ６０３）に戻り、直前のイベントが存在する限り、ステップ（Ｓ６０３）〜（Ｓ６１０）を繰り返し実行する。一方、原因特定部２０５は、直前のイベントが存在しない（ＮＵＬＬ）場合、ローカル変数Ｍｉ’を変数Ｍｉに代入し（Ｓ６１１）、処理を終了する。

このような管理システム２００及び管理方法によれば、図１に示した管理システム１００及び図５〜７に示した管理方法によって得られる効果に加えて、以下の効果を得ることができる。管理システム２００は、尤度に基づいて可能性の高い障害原因を選択することができ、障害原因特定の精度を向上できる。更に、管理システム２００によれば、障害発生要素が多数のイベントに依存している場合であっても、尤度に基づく特定により障害原因の候補数の増加を抑制し、障害原因の特定をより容易にできる。しかも、管理システム２００は、イベントの種別に応じた尤度を付与することや、依存関係に基づいてイベントの尤度を依存するイベントに伝播させることができる。よって、管理システム２００はより適切に尤度を付与し、障害原因特定の精度を更に向上できる。

〔第３の実施形態〕
図１４に示すように、管理システム３００は、イベント監視部２０１と、依存関係抽出部２と、格納部３０３と、第１データベース３０４ａと、第２データベース３０４ｂと、原因特定部３０５と、障害検出部６と、更新部３０７ａと、契機検出部７ｂと、更新規則記憶部８と、尤度決定規則記憶部９を備える。図１４では、図１、８に示した管理システム１００，２００と実質的に同一の構成には同一の符号を付して説明を省略する。

管理システム３００は、保持部として第１保持部である第１データベース３０４ａと、第２保持部である第２データベース３０４ｂとを備える。第１データベース３０４ａは、揮発性の記憶媒体を用いることができる。揮発性の記憶媒体は、記録速度が高速ではあるが、記憶容量が限られており、容量単価が高い。例えば、第１データベース３０４ａとして、メインメモリを用いることができる。第２データベース３０４ｂは、不揮発性の記憶媒体を用いることができる。不揮発性の記憶媒体は、記録速度は低速だが、記憶容量が大きく、容量単価が安い。即ち、第２データベース３０４ｂは、大量のデータを低コストで保持可能である。例えば、第２データベース３０４ｂとして、磁気記憶装置やネットワーク上のデータベースサーバを用いることができる。第１データベース３０４ａ、第２データベース３０４ｂは、図９に示したデータベース２０４と同様にして情報を保持する。

格納部３０３は、イベント監視部２０１や依存情報抽出部２から取得したイベント発生時の情報を、第１データベース３０４ａに格納する。第１データベース３０４ａへは高速な情報の格納が可能であるため、管理システム３００は、情報格納に伴うオーバヘッドを低減できる。

更新部３０７ａは、第１データベース３０４ａから情報を取得し、第２データベース３０４ｂに格納する。即ち、更新部３０７ａは、第１データベース３０４ａから第２データベース３０４ｂに情報を転記し、移行する。更新部３０７ａは、例えば、事前に規定されたタイミングで情報を移行する。例えば、更新部３０７ａは、第１データベース３０４ａが保持する情報量が閾値を越えたときや、管理対象である装置やシステムをリブートするときに情報を移行できる。

更に、更新部３０７ａは、第１データベース３０４ａからイベントや依存関係等を取得して更新し、更新後のイベントや依存関係を第２データベース３０４ｂに格納する。即ち、更新部３０７ａは、情報の移行と同時に更新を行う。

例えば、図３に示すように更新契機規則テーブル８２が更新契機「第２データベースへの格納」を保持しておくことにより、更新部３０７ａは、情報の移行時に更新を実行できる。更新部３０７ａは、ルールＩＤ「０ｘ０２」、「０ｘ０４」の順番に更新規則に従った更新を実行する。更新部３０７ａは、ルールＩＤ「０ｘ０２」の更新内容に従って第１データベース３０４ａから取得した情報を更新し、第２データベース３０４ｂに格納した後、ルールＩＤ「０ｘ０４」の更新内容に従って第１データベース３０４ａが保持する情報を消去する。

原因推定部３０５は、第１データベース３０４ａ及び第２データベース３０４ｂを参照し、第１データベース３０４ａ及び第２データベース３０４ｂが保持する情報を用いて障害原因を特定する。格納部３０３、原因特定部３０５、更新部３０７ａは、これらの点以外は図８に示した格納部２０３、原因特定部３０５、更新部２０７ａと実質的に同様である。

このような管理システム３００によれば、図１、８に示した管理システム１００，２００によって得られる効果に加えて以下の効果を得ることができる。管理システム３００では、第１データベース３０４ａに一時的に情報を保持し、必要な更新後の情報だけを第２データベース３０４ｂに保持しておくことができる。しかも、更新後の情報であるため、第２データベース３０４ｂが保持する情報量を削減できる。

更に、管理システム３００は、第１データベース３０４ａ、第２データベース３０４ｂとして特性の異なる２つの記憶媒体を用いる。そして、管理システム３００は、高速な記録が可能な第１データベース３０４ａに一時的に情報を格納しておき、第２データベース３０４ｂに適宜移行することができる。よって、管理システム３００は、情報を収集し、データベース３０４ａに格納する際のオーバヘッドを低減できる。

このような管理システム３００は、特に、記憶容量に制限がある装置やシステムに対して有用である。例えば、携帯電話端末では、記憶容量に対する制約が厳しく、障害原因特定のために必要な情報を保持するために大量のメモリを利用することはあまり現実的ではないが、管理システム３００によればそのような事態を回避できる。

本発明の第１の実施形態に係る管理システムの構成を示すブロック図である。 本発明の第１の実施形態に係るデータベースを示す図である。 本発明の第１の実施形態に係る更新規則記憶部を示す図である。 本発明の第１の実施形態に係る障害原因の探索手順を示す概念図である。 本発明の第１の実施形態に係るイベントと依存関係の管理方法を示すフロー図である。 本発明の第１の実施形態に係る原因特定部の処理手順を示すフロー図である。 本発明の第１の実施形態に係る障害原因の特定手順を示すフロー図である。 本発明の第２の実施形態に係る管理システムの構成を示すブロック図である。 本発明の第２の実施形態に係るデータベースを示す図である。 本発明の第２の実施形態に係る障害原因の探索手順を示す概念図である。 本発明の第２の実施形態に係るイベントと依存関係の管理方法を示すフロー図である。 本発明の第２の実施形態に係る原因特定部の処理手順を示すフロー図である。 本発明の第２の実施形態に係る障害原因の特定手順を示すフロー図である。 本発明の第３の実施形態に係る管理システムの構成を示すブロック図である。

符号の説明

１，２０１ イベント監視部
２ 依存関係抽出部
３，２０３，３０３ 格納部
４，２０４ データベース
５，２０５，３０５ 原因特定部
６ 障害検出部
７ａ，２０７ａ，３０７ａ 更新部
７ｂ 契機検出部
８ 更新規則記憶部
９ 尤度決定規則記憶部
１００，２００，３００ 管理システム
３０４ａ 第１データベース
３０４ｂ 第２データベース

Claims (8)

1. 発生したイベントを検出するイベント監視部と、
   前記イベントに関する依存関係を抽出する依存関係抽出部と、
   前記イベント及び前記依存関係を保持する保持部と、
   更新規則に従って前記保持部を更新する更新部と、
   前記イベントと前記依存関係に基づいて発生した障害原因を特定する原因特定部と
   を備えることを特徴とする管理システム。
2. 前記更新規則を適用する更新契機を検出し、該検出した更新契機を前記更新部に通知する契機検出部を備え、
   前記更新部は、前記契機検出部から通知された前記更新契機により適用する前記更新規則に従って前記保持部を更新することを特徴とする請求項１に記載の管理システム。
3. 前記保持部は、前記イベント又は前記依存関係の属性情報として、前記更新規則に関する情報を保持し、
   前記更新部は、前記更新規則に関する情報に基づいて前記保持部を更新することを特徴とする請求項１又は２に記載の管理システム。
4. 前記属性情報は、前記更新規則を識別する識別子であり、
   前記更新部は、前記識別子により特定される更新規則に従って前記保持部を更新することを特徴とする請求項３に記載の管理システム。
5. 前記イベント監視部は、前記イベントに尤度を付与し、
   前記保持部は、前記尤度を前記イベントと対応付けて保持し、
   前記原因特定部は、前記尤度に基づいて前記障害原因を特定することを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
6. 前記イベント監視部は、前記イベントの種別、又は、前記イベントに依存するイベントの尤度の少なくとも１つに基づいて前記付与する尤度を決定することを特徴とする請求項５に記載の管理システム。
7. 前記保持部は、第１保持部と第２保持部を備え、
   前記更新部は、前記第１保持部から前記イベント及び前記依存関係を取得して更新し、該更新後のイベント及び依存関係を前記第２保持部に格納することを特徴とする請求項１乃至６のいずれか１項に記載の管理システム。
8. 発生したイベントを検出するステップと、
   前記イベントに関する依存関係を抽出するステップと、
   更新規則に従って前記イベント及び前記依存関係を保持する保持部を更新するステップと、
   前記イベントと前記依存関係に基づいて発生した障害原因を特定するステップとを有することを特徴とする管理方法。

Images