(57)【要約】【課題】人手により複雑な依存関係を定義しなくても、障害の根源的な原因を推定できる障害原因推定システムを提供する。【課題を解決するための手段】初期モデル生成手段４０は、基本モデル定義２０に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成する。Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、初期障害発生モデルと、学習用イベント列１００とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習する。Ｖｉｔｅｒｂｉ計算手段６０は、学習後の障害発生モデルで、障害原因発見用イベント列１１０が観察される確率が最も高いと考えられる状態遷移列を求める。フィルタリングモジュールは、状態遷移列から、監視対象装置で発生した障害の根源的な原因を推定する。【選択図】図１
2007257184.tif 000002
【特許請求の範囲】
【請求項１】
監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶する初期モデル生成手段と、
前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶する障害発生モデル学習手段と、
イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶する状態遷移列計算手段と、
前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するフィルタリングモジュールとを備えることを特徴とする障害原因推定システム。
【請求項２】
前記障害発生モデル学習手段が、Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムにより、前記原因間の状態遷移確率と、各原因でのイベント発生確率とを学習する、請求項１に記載の障害原因推定システム。
【請求項３】
前記状態遷移列計算手段が、Ｖｉｔｅｒｂｉアルゴリズムにより、前記状態遷移列を求める、請求項１に記載の障害原因推定システム。
【請求項４】
前記初期障害発生モデルが、前記発生し得るイベントの集合Σと、前記障害原因の集合Ｓに正常状態ｓ０を加えた状態の集合と、各状態について、当該状態から各状態に遷移する確率を示す条件付確率Ｐｒ(sj｜si)si，sj∈Sと、各状態について、開始時に当該状態にいる初期確率｛Ｐ0si｝si∈Sと、各状態について、当該状態で前記イベントが発生する確率を示すＰｒ(ej｜si)}si∈Ｓ，ej∈Σとを含む、請求項１に記載の障害原因推定システム。
【請求項５】
前記フィルタリングモジュールは、前記状態遷移列計算手段が求めた状態遷移列を｛ｓ（０）、ｓ（１）、・・・、ｓ（ｎ）｝とするとき、状態ｓ（ｉ）（０≦ｉ＜ｎ）から次状態ｓ（ｉ＋１）への前記条件付確率Ｐｒ(s（ｉ＋１）｜s（ｉ）)が、所定の確率よりも低いと、前期状態遷移列を、｛ｓ（０）、ｓ（１）、・・・、ｓ（ｉ）｝と、｛ｓ（ｉ＋１）、・・・、ｓ（ｎ）｝とに分割する、請求項４に記載の障害原因推定システム。
【請求項６】
前記フィルタリングモジュールは、前記分割された各状態遷移列の先頭の状態を、障害の根源的原因と推定する、請求項５に記載の障害原因推定システム。
【請求項７】
前記学習用イベント列が、前記監視対象装置を試運転した際にモニタされたイベント列である、請求項１に記載の障害原因推定システム。
【請求項８】
前記学習用イベント列が、前記監視対象装置の運用時にモニタされたイベント列であって、障害の発生原因が解析済みのイベント列である、請求項１に記載の障害原因推定システム。
【請求項９】
前記障害原因発見用イベント列が、前記監視対象装置の運用時にモニタされたイベント列である、請求項１に記載の障害原因推定システム。
【請求項１０】
前記学習用イベント列及び前記障害原因発見用イベント列のそれぞれにおける隣接する２つのイベントの発生時間間隔が所定の値以下である、請求項１に記載の障害原因推定システム。
【請求項１１】
前記フィルタリングモジュールは、前記状態遷移列計算手段が求めた状態遷移列を原因推定結果データベースに記憶すると共に、前記障害原因発見用イベント列のうちで、前記状態遷移列に含まれる各状態を発生原因とするイベントを、各状態に対応付けて記憶する、請求項１に記載の障害原因推定システム。
【請求項１２】
コンピュータを用いて、監視対象装置で発生した障害の根源的な原因を推定する方法であって、
前記コンピュータが、前記監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶するステップと、
前記コンピュータが、前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶するステップと、
前記コンピュータが、イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶するステップと、
前記コンピュータが、前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するステップとを有することを特徴とする方法。
【請求項１３】
前記初期障害発生モデルを学習するステップでは、前記コンピュータは、Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムにより、前記原因間の状態遷移確率と、各原因でのイベント発生確率とを学習する、請求項１２に記載の方法。
【請求項１４】
前記状態遷移列を計算するステップでは、前記コンピュータは、Ｖｉｔｅｒｂｉアルゴリズムにより、前記状態遷移列を求める、請求項１２に記載の方法。
【請求項１５】
前記初期障害発生モデルが、前記発生し得るイベントの集合Σと、前記障害原因の集合Ｓに正常状態ｓ０を加えた状態の集合と、各状態について、当該状態から各状態に遷移する確率を示す条件付確率Ｐｒ(sj｜si)si，sj∈Sと、各状態について、開始時に当該状態にいる初期確率｛Ｐ0si｝si∈Sと、各状態について、当該状態で前記イベントが発生する確率を示すＰｒ(ej｜si)}si∈Ｓ，ej∈Σとを含む、請求項１２に記載の方法。
【請求項１６】
前記障害の根源的原因を推定するステップは、
前記コンピュータが、前記状態遷移列を計算するステップで求めた状態遷移列を｛ｓ（０）、ｓ（１）、・・・、ｓ（ｎ）｝とするとき、状態ｓ（ｉ）（０≦ｉ＜ｎ）から次状態ｓ（ｉ＋１）への前記条件付確率Ｐｒ(s（ｉ＋１）｜s（ｉ）)が、所定の確率よりも低いと、前期状態遷移列を、｛ｓ（０）、ｓ（１）、・・・、ｓ（ｉ）｝と、｛ｓ（ｉ＋１）、・・・、ｓ（ｎ）｝とに分割するステップと、
前記コンピュータが、前記分割された各状態遷移列の先頭の状態を、障害の根源的原因と推定するステップとを含む、請求項１５に記載の方法。
【請求項１７】
前記コンピュータが、前記状態遷移列を計算するステップで求めた状態遷移列を原因推定結果データベースに記憶すると共に、前記障害原因発見用イベント列のうちで、前記状態遷移列に含まれる各状態を発生原因とするイベントを、各状態に対応付けて記憶するステップを更に有する、請求項１２に記載の方法。
【請求項１８】
コンピュータに、監視対象装置で発生した障害の根源的な原因を推定する方法を実行させるプログラムであって、前記コンピュータに、
前記監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶するステップと、
前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶するステップと、
イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶するステップと、
前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するステップとを実行させることを特徴とするプログラム。
【請求項１９】
前記初期障害発生モデルを学習するステップでは、Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムにより、前記原因間の状態遷移確率と、各原因でのイベント発生確率とを学習する、請求項１８に記載のプログラム。
【請求項２０】
前記状態遷移列を計算するステップでは、Ｖｉｔｅｒｂｉアルゴリズムにより、前記状態遷移列を求める、請求項１８に記載のプログラム。
【請求項２１】
前記初期障害発生モデルが、前記発生し得るイベントの集合Σと、前記障害原因の集合Ｓに正常状態ｓ０を加えた状態の集合と、各状態について、当該状態から各状態に遷移する確率を示す条件付確率Ｐｒ(sj｜si)si，sj∈Sと、各状態について、開始時に当該状態にいる初期確率｛Ｐ0si｝si∈Sと、各状態について、当該状態で前記イベントが発生する確率を示すＰｒ(ej｜si)}si∈Ｓ，ej∈Σとを含む、請求項１８に記載のプログラム。
【請求項２２】
前記障害の根源的原因を推定するステップは、
前記状態遷移列を計算するステップで求めた状態遷移列を｛ｓ（０）、ｓ（１）、・・・、ｓ（ｎ）｝とするとき、状態ｓ（ｉ）（０≦ｉ＜ｎ）から次状態ｓ（ｉ＋１）への前記条件付確率Ｐｒ(s（ｉ＋１）｜s（ｉ）)が、所定の確率よりも低いと、前期状態遷移列を、｛ｓ（０）、ｓ（１）、・・・、ｓ（ｉ）｝と、｛ｓ（ｉ＋１）、・・・、ｓ（ｎ）｝とに分割するステップと、
前記分割された各状態遷移列の先頭の状態を、障害の根源的原因と推定するステップとを含む、請求項２１に記載のプログラム。
【請求項２３】
前記コンピュータに、前記状態遷移列を計算するステップで求めた状態遷移列を原因推定結果データベースに記憶すると共に、前記障害原因発見用イベント列のうちで、前記状態遷移列に含まれる各状態を発生原因とするイベントを、各状態に対応付けて記憶するステップを更に実行させる、請求項１８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害原因推定システム、方法、及び、プログラムに関し、更に詳しくは、監視対象装置で発生した障害の原因を推定する障害原因推定システム、方法、及び、プログラムに関する。
【背景技術】
【０００２】
コンピュータ等の管理対象機器を監視し、管理対象機器に障害が発生した際に、その障害の原因を推定するシステムがある。図７は、特許文献１に記載された障害原因発見装置の構成を示している。この従来の障害原因発見装置２００では、プロセス情報獲得部２０１は、計算機システム上で実行されているプロセス情報を獲得し、環境ファイル情報獲得部２０２は、システム環境ファイル情報を獲得する。また、デバイス情報獲得部２０３は、計算機システムに組み込まれているデバイスドライバの情報を獲得する。
【０００３】
基準環境情報獲得部２０４は、計算機システムが正常動作しているときに、プロセス情報獲得部２０１、環境ファイル情報獲得部２０２、及び、デバイス情報獲得部２０３が獲得した各情報を収集し、これを基準環境情報記憶部２０５に記憶する。検査環境情報獲得部２０６は、計算機システムに異常が発生したか否かを検出する際に、プロセス情報獲得部２０１、環境ファイル情報獲得部２０２、及び、デバイス情報獲得部２０３が獲得した各情報を収集し、これを検査環境情報記憶部２０７に記憶する。
【０００４】
環境情報比較判定部２０９は、基準環境情報記憶部２０５の内容と検査環境情報記憶部２０７の内容とを比較し、状態内容変化を見つけ出す。環境情報比較判定部２０９は、状態変化内容が、状態内容変化の許容値を記憶する許容範囲情報記憶部２０８を参照して、見つけ出した状態内容変化が、許容される範囲を超えるか否かを判断する。異常原因特定部２１１は、環境情報比較判定部２０９が許容される範囲を超えると判断すると、状態変化内容から、計算機システムの異常発生原因を特定する。
【０００５】
例えば、基準環境情報記憶部２０５には、「実行中のプロセスは、ｎｆｓが1個」が記憶される。また、許容範囲情報記憶部２０８には、マウントデバイスの追加が許可される状況に対応して、プロセス“ｎｆｓ”について、実行中のプロセスの最大値が“８個”である旨を記憶している。この場合に、検査環境情報獲得部２０６によって、マウントデバイスの追加が許可された状況で、「実行中のプロセスは、ｎｆｓが１１個」という状態が検出されると、環境情報比較判定部２０９は、許容された範囲を超えると判定し、異常を検出する。異常原因特定部２１１は、計算機システムで異常が検出された原因を、プロセス“ｎｆｓ”が許容プロセス数を超えたためと特定する。
【０００６】
従来の障害原因を推定するシステムの別の例としては、特許文献２に記載されたものがある。図８は、特許文献２に記載された障害原因推定システムに用いられる因果システムモデル構築装置の構成を示している。この特許文献２では、因果関係をあらわすデータベースである因果データ生成記憶部３１１と、その逆マッピングである果因データ生成記憶部３１２と、複数の事象を一つの事象グループに対応させ、或いは、複数の原因を一つの原因グループに対応させる関係を記録する同一結果データ集合生成部３１３とを用い、部分因果システムモデル構成部３１４により、原因グループと事象グループとの関係をマッピングする因果システムモデル構築装置３００を構築する。
【０００７】
図９は、特許文献２に記載された障害原因推定システムに用いられる原因推定装置の構成を示している。因果システムモデル記憶部３２４には、因果システムモデル構築装置３００（図８）によって構築された因果システムモデルが格納される。原因推定装置３２０は、観測データ認識部３２１で認識した事象から、因果システムモデル記憶部３２４に格納した因果システムモデルの事象から原因のマッピングを適用し、障害の原因を求める。更に、原因から事象へのマッピングを適用することで、その原因から発生しうる事象を求める。このように、事象から原因へのマッピング、及び、原因から事象へのマッピングを推移的に適用し、推移的閉包を求めることで、起こりうる根源原因を含む原因を推移的に求める。
【０００８】
また、システムのトラブルシューティングを行う自動トラブルシュート機構に関する技術として、特許文献３に記載された技術がある。特許文献３では、変数を表すノードと変数間の依存関係を表すアークからなる方向を持った非環式グラフであるベイジアンネットワークで、システムの故障を引き起こすシステムコンポーネントをモデル化し、このモデルを用いて、プリンタシステムの自動診断を行う。
【０００９】
【特許文献１】特開平８−２５５０９３号公報（段落００１３〜００３１、図１）
【特許文献２】特開２００４−１２６６４１号公報
【特許文献３】特開２００１−７５８０８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
特許文献１では、状態内容変化を検出し、検出した状態内容変化が、許容される範囲を超えるときには、状態変化内容から、計算機システムの異常発生原因を特定している。しかし、特許文献１で特定できるのは、直接の状態のみであり、ある障害が発生したことに起因して異常状態となったような場合には、その根源となる障害を特定することはできない。
【００１１】
例えば、「マウントデバイスの追加が許可される」状況におけるｎｆｓプロセスの最大値（許容値）が「１２」で、「マウントデバイスの追加が許可されない」状況におけるｎｆｓプロセスの最大値が「８」であるとする。現在、システムが、「マウントデバイスの追加が許可される」状況にあり、ｎｆｓプロセス数が１１個であったとすると、ｎｆｓプロセス数は、最大値「１２」を超えない状態であるため、正常であると判断される。
【００１２】
その後、「ＳＣＳＩボートの故障」に起因して、「マウントデバイスの追加が許可されない」状況になったとする。ｎｆｓプロセス数が変化せずに、１２個のままであったとすると、「マウントデバイスの追加が許可されない」状況におけるｎｆｓプロセスの最大値は「８」であるため、ｎｆｓプロセス数は最大値を超える。従って、特許文献１では、ｎｆｓプロセス数が許容値を超えたことを、障害原因として特定する。
【００１３】
しかしながら、上記の場合、本来の故障原因は、「ＳＣＳＩボードの故障」であり、ｎｆｓプロセスの数が正常値を逸脱しているということの原因が、「ＳＣＳＩボードの故障」であると認識して対応しないと、正しい障害対応はできない。特許文献１では、推移的におきる障害、例えば、障害Ａにより状態Ｂに移行し、状態Ｂを直接原因に起きる障害Ｃに対しては、直接の障害Ｃしか特定することができず、根源原因である障害Ａを特定することができないという問題がある。
【００１４】
また、特許文献２では、原因と障害との対応関係を事前に登録する必要があるが、一般事象の関係は複雑であるため、障害や状態の種類が多いと、その対応関係を記述することは困難であり、根源的な障害原因を求めるための規則を入力することが困難であるという問題がある。特許文献２には、このような記述の困難性を軽減するため、障害原因をグループ化し、その間のマッピングを記載している。しかし、グループごとにマッピングを定義する場合であっても、マッピングの定義は必要であり、グループを定義するのに手間がかかるのに加えて、上手にグループ化しないと、原因と障害のマッピングの精度が落ちる可能性があるという問題が残る。
【００１５】
図１０は、因果関係をモデル化して示している。例えば、特許文献２には、同図に示す事例が記載されている。同図では、矢印は、因果関係を示している。例えば、新たな事象ｙ’を定義し、ｙ’がｘ２の原因であるとする。この関係は、
ｙ’→ｘ２
と書ける。特許文献２では、マッピングの定義を容易にするため、ｙ’→ｘ２、かつ、ｘ２∈Ｘ１ならば、
ｈ（Ｘ１）＝ｙ’
という果因関係を抽象化したマッピングｈを設ける。これにより、ｈは、Ｘ１をｘ２，ｘ３と細かく見ないことで、果因関係を簡単に記述できる。しかし、「細かく見ない」ために、ｘ３∈Ｘ１のとき、ｈ（ｘ３）＝ｙ’となる。すなわち、ｘ３の原因として、本来、因果関係のない、ｙ’が原因とみなされる危険性があるという問題がある。
【００１６】
特許文献３では、障害のモデル化に、ＤＡＧ（ループのないグラフ）を用いている。障害の発生では、同一障害からイベントが繰り返し発生する場合も多いが、特許文献３では、ＤＡＧを用いているので、繰り返し発生するイベントには対応できないという問題がある。
【００１７】
本発明は、上記従来技術の問題点を解消し、人手により複雑な依存関係を定義しなくても、障害の根源的な原因を推定できる障害原因推定システム、方法、及び、プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
上記目的を達成するために、本発明の障害原因推定システムは、監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶する初期モデル生成手段と、前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶する障害発生モデル学習手段と、イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶する状態遷移列計算手段と、前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するフィルタリングモジュールとを備えることを特徴とする。
【００１９】
本発明の障害原因推定方法は、コンピュータを用いて、監視対象装置で発生した障害の根源的な原因を推定する方法であって、前記コンピュータが、前記監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶するステップと、前記コンピュータが、前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶するステップと、前記コンピュータが、イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶するステップと、前記コンピュータが、前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するステップとを有することを特徴とする。
【００２０】
本発明のプログラムは、コンピュータに、監視対象装置で発生した障害の根源的な原因を推定する方法を実行させるプログラムであって、前記コンピュータに、前記監視対象装置で発生し得るイベントと、該イベントを引き起こす障害原因とを定義した基本モデル定義を読み出し、該読み出した基本モデル定義に基づいて、イベントとその発生原因との対応関係及び発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベースに記憶するステップと、前記初期障害発生モデルと、イベント列データベースに記憶された学習用イベント列とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、該学習の結果を反映させた障害発生モデルをモデル格納データベースに記憶するステップと、イベント列データベースから障害原因発見用イベント列を読み出し、前記学習後の障害発生モデルで、前記読み出した障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、原因推定結果データベースに記憶するステップと、前記状態遷移列計算手段が求めた状態遷移列と、前記学習後の障害発生モデルとに基づいて、監視対象装置で発生した障害の根源的な原因を推定するステップとを実行させることを特徴とする。
【００２１】
本発明の障害原因推定システム、方法、及び、プログラムでは、基本定義モデルに基づいて作成された初期障害発生モデルを、学習用イベント列を用いて学習し、学習によってえられた障害発生モデルから、障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、その状態遷移列に基づいて、監視対象装置で発生した障害の根源的な原因を推定する。本発明では、人手で定義が必要なのは、発生し得るイベントと、イベントを引き起こす障害原因と、その対応関係とであり、これらは、人手で容易に定義できる。従って、複雑な原因、結果間の依存関係を定義しなくても、障害の根源的な原因を推定できる。
【００２２】
本発明の障害原因推定システム、方法、及び、プログラムでは、Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムにより、前記原因間の状態遷移確率と、各原因でのイベント発生確率とを学習する構成を採用できる。学習のアルゴリズムとしては、出力記号列からパラメータを推定するＢａｕｍ−Ｗｅｌｃｈアルゴリズムを用いることができる。
【００２３】
本発明の障害原因推定システム、方法、及び、プログラムでは、Ｖｉｔｅｒｂｉアルゴリズムにより、前記状態遷移列を求める構成を採用できる。学習後の障害発生モデルから状態連に列を求める際に用いるアルゴリズムとしては、出力記号列から状態列を推定するＶｉｔｅｒｂｉアルゴリズムを用いることができる。
【００２４】
本発明の障害原因推定システム、方法、及び、プログラムでは、前記初期障害発生モデルが、前記発生し得るイベントの集合Σと、前記障害原因の集合Ｓに正常状態ｓ０を加えた状態の集合と、各状態について、当該状態から各状態に遷移する確率を示す条件付確率Ｐｒ(sj｜si)si，sj∈Sと、各状態について、開始時に当該状態にいる初期確率｛Ｐ0si｝si∈Sと、各状態について、当該状態で前記イベントが発生する確率を示すＰｒ(ej｜si)}si∈Ｓ，ej∈Σとを含む構成を採用できる。
【００２５】
本発明の障害原因推定システム、方法、及び、プログラムでは、前記フィルタリングモジュールは、求めた状態遷移列を｛ｓ（０）、ｓ（１）、・・・、ｓ（ｎ）｝とするとき、状態ｓ（ｉ）（０≦ｉ＜ｎ）から次状態ｓ（ｉ＋１）への前記条件付確率Ｐｒ(s（ｉ＋１）｜s（ｉ）)が、所定の確率よりも低いと、前期状態遷移列を、｛ｓ（０）、ｓ（１）、・・・、ｓ（ｉ）｝と、｛ｓ（ｉ＋１）、・・・、ｓ（ｎ）｝とに分割する構成を採用できる。この場合、前記フィルタリングモジュールは、前記分割された各状態遷移列の先頭の状態を、障害の根源的原因と推定することができる。このように分割することで、異なる根源原因による２つの状態列（シーケンス）が、たまたま確率的に最大値であるために１つのシーケンスとしてみなされている場合に、そのシーケンスを、根源原因ごとのシーケンスに分割でき、各シーケンスの先頭の状態を、根源原因と推定できる。
【００２６】
本発明の障害原因推定システムでは、前記学習用イベント列が、前記監視対象装置を試運転した際にモニタされたイベント列である構成を採用できる。或いは、前記学習用イベント列が、前記監視対象装置の運用時にモニタされたイベント列であって、障害の発生原因が解析済みのイベント列である構成を採用できる。
【００２７】
本発明の障害原因推定システムでは、前記障害原因発見用イベント列が、前記監視対象装置の運用時にモニタされたイベント列である構成を採用できる。この場合、運用中の監視対象装置で発生した障害の根源的原因を推定することができる。
【００２８】
本発明の障害原因推定システムでは、前記学習用イベント列及び前記障害原因発見用イベント列のそれぞれにおける隣接する２つのイベントの発生時間間隔が所定の値以下である構成を採用できる。この場合、ある障害原因に対して、互いに関連性のあるイベントの列学習用イベント列及び障害原因発見用イベント列とすることができる。
【００２９】
本発明の障害原因推定システム、方法、及び、プログラムでは、求められた状態遷移列を原因推定結果データベースに記憶すると共に、前記障害原因発見用イベント列のうちで、前記状態遷移列に含まれる各状態を発生原因とするイベントを、各状態に対応付けて記憶する構成を採用できる。このようにして記憶された原因推定結果データベースを参照することで、管理者等は、障害の根源的な原因や、それに付随して発生した原因等を解析することができる。
【発明の効果】
【００３０】
本発明の障害原因推定システム、方法、及び、プログラムでは、基本定義モデルに基づいて作成された初期障害発生モデルを、学習用イベント列を用いて学習し、学習によって得られた障害発生モデルから、障害原因発見用イベント列が観察される確率が最も高いと考えられる状態遷移列を求め、その状態遷移列に基づいて、監視対象装置で発生した障害の根源的な原因を推定する。本発明では、人手で定義が必要なのは、発生し得るイベントと、イベントを引き起こす障害原因と、その対応関係とであり、これらは、人手で容易に定義できる。従って、複雑な原因、結果間の依存関係を定義しなくても、障害の根源的な原因を推定できる。
【発明を実施するための最良の形態】
【００３１】
以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の一実施形態の障害原因推定装置の構成を示している。障害原因推定装置１０は、初期モデルパーザ３０、初期モデル生成手段４０、Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０、Ｖｉｔｅｒｂｉ計算手段６０、フィルタリングモジュール７０、モデル格納データベース１２０、イベント列パーザ１３０、イベント列データベース１４０、原因推定結果データベース１５０を備える。障害原因推定装置１０は、例えばワークステーション等のコンピュータシステムで構成され、所定のプログラムを動作させることで、各部の機能が実現される。
【００３２】
初期モデルパーザ３０は、装置開発者が記述した基本モデル定義２０を読み込み、それを構文解釈して構文情報を生成し、初期モデル生成手段４０に受け渡す。基本モデル定義２０は、監視対象装置８０で発生し得るイベントと、それを引き起こす障害原因とを定義したものである。初期モデル生成手段４０は、初期モデルパーザ３０が生成した構文情報に基づいて、イベントとその発生原因の対応関係、及び、発生原因間の遷移を有限オートマトンでモデル化した初期障害発生モデルを生成し、モデル格納データベース１２０に格納する。
【００３３】
イベントモニタ９０は、監視対象装置８０で発生するイベントをモニタし、学習用イベント列１００と、障害原因発見用イベント列１１０とを生成する。イベント列パーザ１３０は、これら学習用イベント列１００及び障害原因発見用イベント列１１０を構文解釈して、イベントデータを生成し、イベント列データベース１４０に記憶する。Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、モデル格納データベース１２０に格納された初期障害発生モデルと、イベント列データベース１４０に格納された学習用イベント列１００に対応するイベントデータ（以下、単に学習用イベント列１００とも呼ぶ）とに基づいて、原因に対応する有限オートマトンの状態がどの確率で推移したかを学習し、その学習結果を反映した障害発生モデルをモデル格納データベース１２０に格納する。
【００３４】
Ｖｉｔｅｒｂｉ計算手段６０は、モデル格納データベース１２０に格納された障害発生モデルと、イベント列データベース１４０に格納された障害原因発見用イベント列１１０に対応するイベントデータ（以下、単に障害発見用イベント列とも呼ぶ）とを用いて、最も発生確率が高い障害発生モデルの状態遷移列を求め、フィルタリングモジュール７０に出力する。その際、Ｖｉｔｅｒｂｉ計算手段６０は、状態遷移列を求める元となった障害原因発見用イベント列１１０を、あわせて出力する。
【００３５】
フィルタリングモジュール７０は、Ｖｉｔｅｒｂｉ計算手段６０が求めた、最も発生したと推測される状態遷移列（障害原因の列）のうちで、確率的に低い遷移を切り捨て、もっともらしい遷移列を発見して、その遷移列の開始状態を根源的な原因と推定する。フィルタリングモジュール７０は、推定した根源的な原因と、それに連なる派生原因とを含む原因列を、原因推定結果データベース１５０に格納する。また、その際、障害原因発見用イベント列１１０のうちで、根源的な原因及び派生原因を発生原因とするイベントを、各原因に対応付けて原因推定結果データベース１５０に格納する。管理者は、原因推定結果データベース１５０を参照することで、障害の発生原因等の解析を行う。
【００３６】
図２は、障害発生モデルを生成する際の障害原因推定装置１０の動作手順を示している。初期モデルパーザ３０は、装置開発者によって記述された基本モデル定義２０を読み込み、読み込んだ基本モデル定義２０を、初期モデル生成手段４０が解釈可能な構文情報に変換する（ステップＡ１）。基本モデル定義２０は、イベントの集合Σと、障害原因の集合Ｓと、関数ｆ：Σ→Ｓで定義される。基本的に、関数ｆは全域関数であるが、部分関数でもよい。
【００３７】
図３は、基本モデル定義２０の記述例を示している。基本モデル定義２０は、例えば同図に示すようなテキストファイルで記述される。この例では、ＯＳにＷｉｎｄｏｗｓ（登録商標）を想定している、［ｓｔａｔｅｓ］で始まる段落は、障害原因の集合Ｓを定義する。同図の例では、“Print”や“Application Popup”など、９つの原因を定義している。［ｏｂｓｅｒｖａｔｉｏｎｓ］で始まる段落は、イベントの集合Σを定義している。Ｗｉｎｄｏｗｓ（登録商標）のイベントモニタツール「event viewer」では、イベントの種別は“３”，“４”，“１６”などの数字のＩＤで与えられており、イベントの集合Σの定義には、そのＩＤを用いる。
【００３８】
［ｏｂｓｅｒｖａｔｉｏｎｓ］で、イベントの種類（ＩＤ）と“，”で区切られた部分は、イベントに対して想定される原因を表す。この部分が、障害から原因への関数（マッピング）ｆ：Σ→Ｓを定義する。例えば、イベント“３”は“Print”関係の状態を発生原因としており、ｆ（“３”）＝“Ｐｒｉｎｔ”と定義される。初期モデルパーザ３０は、このようなテキストファイルを読み込んで、記述された基本モデル定義２０に相当する構文情報を初期モデル生成手段４０に受け渡す。
【００３９】
図２に戻り、初期モデル生成手段４０は、基本モデル定義２０に相当する構文情報に基づいて、初期障害発生モデルを生成する（ステップＡ２）。障害発生モデルＭを次式で定義する。
Ｍ＝{Σ，Ｓ∪{ｓ０}，{Ｐｒ(sj｜si)}si，sj∈S，{Ｐ0i}si∈S，{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σ｝
Ｐｒ（ａ｜ｂ）は、条件付確率であり、ｂという条件下でａが発生する確率を示す。また、Ｐ０ｉは、障害発生モデルＭが状態Ｓｉから開始する確率を示す。ｓ０は、監視対象装置８０が正常である状態を示す。上記障害発生モデルＭにおいて、「Ｓ∪{ｓ０}，{Ｐｒ(sj｜si)}si，sj∈S，{Ｐ0i}si，sj∈S」は、有限状態オートマトンを表し、これは、次の状態ｓ∈Ｓ∪｛ｓ０｝は、直前の状態Ｓ’∈Ｓ∪{ｓ０}のみで定まり、固定の確率Ｐｒ（ｓ｜ｓ’)で遷移することを表している。
【００４０】
初期モデル生成手段４０が生成する初期障害発生モデルＭ０について詳細に説明する。初期障害発生モデルＭ０で扱うイベントの集合Σは、基本モデル定義２０で定義したΣと同一である。また、初期障害発生モデルＭ０で扱う原因の集合Ｓ∪{ｓ０}は、基本モデル定義２０で定義したＳに、正常状態ｓ０を加えた集合である。{Ｐｒ(sj｜si)}si，sj∈Sは、原因間の遷移確率を示しており、この遷移確率は、等確率とする。具体的には、｜Ｓ｜を原因の集合Ｓの個数として、Ｐｒ(sj｜si)＝１／（｜Ｓ｜＋１）とする。この確率を等確率にせずに、自身へ遷移する確率Ｐｒ(si｜si)のみを大きくするなどして、定常状態になる確率を高く設定してもよい。{Ｐ0i}si∈Sは、Ｐ００＝１、Ｐ０ｉ＝０（ｉ≠０)とする。これは、初期障害発生モデルＭ０が正常状態ｓ０から開始することを意味する。
【００４１】
{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σは、イベントと原因との対応関係を示しており、状態Ｓｉでイベントｅｊが発生する確率を示す。{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σは、
Ｐｒ(e｜s)＝ｋ×ｐ    （ｆ（ｅ）＝ｓのとき）
Ｐｒ(e｜s)＝ｐ        （ｆ（ｅ）≠ｓのとき）
と定義する。ただし、ｋは１以上の定数である。また、全てのｓ∈Ｓ∪｛ｓ０｝について、Σ｛ｅ｜ｆ（ｅ）＝ｓ｝ｋ×ｐ＋Σ｛ｅ｜ｆ（ｅ）≠ｓ｝ｐ≦１である。上記定義は、基本モデル定義２０で定義されたｆ（ｅ）＝ｓ、すなわち、イベントｅの発生原因ｓについては、ｓからｅが発生する確率を、ｆ（ｅ）≠ｓの場合確率ｐのｋ倍に設定することを示している。関数ｆが部分関数で、ｆ（ｅ）が定義されていないｅの場合には、上記定義に従って、ｆ（ｅ｜ｓ）には、確率ｐを与える。
【００４２】
管理者は、オンライン又はオフラインで、学習用イベント列１００を障害原因推定装置１０に与える（ステップＡ３）。管理者は、例えば監視対象装置８０を試運転した際にイベントモニタ９０がモニタしたイベント列を、オフラインで、学習用イベント列１００として与える。または、監視対象装置８０の運用中にイベントモニタ９０がモニタしたイベント列のうちで、障害原因解析が既に行われたイベント列を、オンラインで、学習用イベント列１００として与える。
【００４３】
イベント列パーザ１３０は、与えられた学習用イベント列１００から、他のモジュールで解釈可能なイベントデータを生成し、イベント列データベース１４０に格納する。イベント列パーザ１３０は、イベントデータを生成する際に、学習用イベント列１００を、所定の条件で、複数のイベントの列に分割する。図４は、イベント列の分割の様子を示している。イベント列パーザ１３０は、イベントの発生間隔が所定のしきい値Ｔよりも大きいと、イベント列を分割する。具体的には、例えば、イベント列（ｅ（０），…，ｅ（ｎ））があるとき、イベントｅ（ｉ）の発生時刻と、ｅ（ｉ＋１）の発生時刻との間の時間がしきい値Ｔよりも長いと、イベント列（ｅ（０），…，ｅ（ｎ））を、イベントリージョンＲ０：（ｅ（０），…，ｅ（ｉ））と、イベントリージョンＲ１：（ｅ（ｉ＋１），…，ｅ（ｎ））とに分割する。このことは、イベントリージョン内では、イベント発生間隔がしきい値Ｔ以下であり、イベントリージョン間のイベント発生間隔はしきい値Ｔよりも大きいことを意味している。なお、ここでのイベントｅ（ｉ）は、イベントタイプ（イベントの種別）ではなくイベントそのものである。
【００４４】
再び図２に戻り、Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムにより、イベント列パーザ１３０から入力した学習用イベント列１００のイベントリージョンを用いて、初期モデル生成手段４０が生成した初期障害発生モデルＭ０の学習を行う。Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、与えられた学習対象のイベント列（イベントリージョン）に対して、最も確率を高くするモデルＭ＝{Σ，Ｓ∪{ｓ０}，{Ｐｒ(sj｜si)}si，sj∈S，{Ｐ0i}si，sj∈S，{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σ｝の遷移確率{Ｐｒ(sj｜si)}si，sj∈Sと、イベントの発生確率{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σとを求める。ただし、最適な値を求めるのではなく、初期モデルＭ０に対して、そこから局所解を求める最尤法である。Ｂａｕｍ−Ｗｅｌｃｈアルゴリズムは、例えば「“Statistical Methods for Speech Recognition (Language, Speech, and Communication)” (Frederick Jelinek著) 9.3節」にも記載されるようによく知られたアルゴリズムであり、その詳細な説明は省略する。
【００４５】
Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、初期障害発生モデルＭ０の遷移確率{Ｐｒ(sj｜si)}si，sj∈S及びイベントの発生確率{Ｐｒ(ej｜si)}si∈Ｓ，ej∈Σを、それぞれ学習により求めた遷移確率及びイベントの発生確率に置き換えた障害発生モデルＭ’を生成し、モデル格納データベース１２０に格納する（ステップＡ４）。ここまでが、障害発生モデル生成フェーズである。以降、このようにして得た障害発生モデルＭ’を使用して、障害の根源的な原因を推定する。
【００４６】
図５は、障害原因を推定する際の障害原因推定装置１０の動作手順を示している。管理者は、オンラインで、イベントモニタ９０が監視対象装置８０で観察したイベント列を、障害原因発見用イベント列１１０として障害原因推定装置１０に与える（ステップＢ１）。イベント列パーザ１３０は、与えられた障害原因発見用イベント列１１０を、複数のイベントリージョン（図４）に分割し、イベント列データベース１４０を介して、Ｖｉｔｅｒｂｉ計算手段６０に受け渡す。
【００４７】
Ｖｉｔｅｒｂｉ計算手段６０は、Ｖｉｔｅｒｂｉアルゴリズムにより、モデル格納データベース１２０に格納された、図２に示す手順で学習された障害発生モデルＭ’に対して、入力された障害原因発見用イベント１１０（イベントリージョン）を実現する可能性（尤度）が最も高い原因の順序列（ｓ（０），ｓ（１），ｓ（２），．．，ｓ（ｎ））を求める（ステップＢ２）。原因順序列中のｓ（ｉ）は、原因の種類を示すのではなく、原因の状態遷移列を時間順に示したものであり、括弧内の数字は時間順に割り当てたものである。Ｖｉｔｅｒｂｉアルゴリズムは、例えば、「“Statistical Methods for Speech Recognition (Language, Speech, and Communication)” (Frederick Jelinek著) 5章」などにも記述されているように、一般によく知られたアルゴリズムであり、ここでは、その詳細な説明は省略する。
【００４８】
フィルタリングモジュール７０は、Ｖｉｔｅｒｂｉ計算手段６０が求めた原因の順序列（ｓ（０），ｓ（１），ｓ（２），．．，ｓ（ｎ））を、この順序列の隣接する２つの状態間の状態遷移確率Ｐｒ(sｉ＋１｜sｉ)に基づいて、複数のグループに分割する（ステップＢ３）。例えば、Ｐｒ(s（ｑ＋１）｜s（ｑ）)＜Ｌであれば、（ｓ（０），ｓ（１）・・・，ｓ（ｑ））と（ｓ（ｑ＋１），・・・，ｓ（ｎ））とに分割する。分割の判断となる確率Ｌは、０〜１までの間のしきい値であり、比較的小さい確率値である。このように分割するのは、異なる根源原因による２つのシーケンスがある場合に、たまたま確率的に最大値であるために１つのシーケンスとしてみなされている可能性があるからである。そこで、フィルタリングモジュール７０により、遷移確率がしきい値Ｌよりも低いシーケンスは、確率的にシーケンスではなく、たまたま時系列的に重なっているものとみなして、分割する。
【００４９】
フィルタリングモジュール７０は、分割されたシーケンス（原因の順序列）を、原因推定結果データベース１５０に格納する。また、分割されたシーケンスのうちの先頭を、根源的な原因として推定する。フィルタリングモジュール７０は、原因推定結果データベース１５０に、原因の順序列を格納する際に、各原因に対応するイベントを、各原因に対応付けて、原因推定結果データベース１５０に格納する。例えば、根源的な原因がＳｉであった場合には、障害原因発見用イベント列１１０（ｅ（０），ｅ（１），・・・，ｅ（ｎ））のうちで、基本モデル定義２０で障害原因Ｓｉに対応付けられているイベントを、障害原因Ｓｉに対応付けて原因推定結果データベース１５０に格納する。
【００５０】
以下、具体例を用いて説明する。基本モデル定義２０としては、図３に示したものを考える。初期モデル生成手段４０が生成する初期障害発生モデルＭ０で扱うイベントの集合Σは、
Σ＝｛３，４，１６，１７，１８，１９，２０｝
＝＞｛ｅ０，ｅ１，ｅ２，ｅ３，ｅ４，ｅ５，ｅ６｝
である。状態の集合は、
Ｓ∪｛ｓ０｝＝｛ｓ０，“Print”,“Windows Update Agent”,“W32Time”,“Application Popup”,“i8042prt”,“Windows Installer”,“DHCP”,“Browser”,“Tcpip”｝
＝＞｛ｓ０，ｓ１，ｓ２，ｓ３，ｓ４，ｓ５，ｓ６，ｓ７，ｓ８，ｓ９，ｓ１０｝
である。原因間の遷移確率{Ｐｒ(sj｜si)}si，sj∈Sは、状態数が計１０個であるため、
Ｐｒ(sj｜si)＝１／１０
である。初期確率は、Ｐ００＝１、Ｐ０ｉ＝０（ｉ≠０)である。図３では、イベントの種類が７種類あるとする。この場合、イベント発生確率は、
Ｐｒ(e｜s)＝２／８  （ｆ（ｅ）＝ｓのとき）
Ｐｒ(e｜s)＝１／８  （ｆ（ｅ）≠ｓのとき）
である。
【００５１】
学習用イベント列１００を、{ｅ（０）, .., ｅ（ｎ）}とする。このｅ（ｉ）は、イベントタイプではなく、イベントそのものであり、発生時刻が記録されている。このイベント列では、e（ｉ）とe（ｉ＋１）の発生時刻の差が２秒であり、他のイベントの発生時刻の差は全て１秒以下とする。イベント列パーザ１３０がイベント列を複数のリージョンに分割する際のしきい値Ｔを１秒とすると、学習用イベント列１００は、Ｒ１＝｛ｅ（０）、・・・、ｅ（ｉ）｝と、Ｒ２＝｛ｅ（ｉ＋１）、・・・、ｅ（ｎ）｝とに分割される。Ｂａｕｍ−Ｗｅｌｃｈ計算手段５０は、Ｒ１、Ｒ２を含む多くのイベントリージョンを与えられることで、初期障害発生モデルＭ０から、遷移確率Ｐｒ（ｓｊ｜ｓｉ）とイベント発生確率Ｐｒ(e｜s)とに関して、与えられたイベントリージョンを最も発生する確率を学習し、障害発生モデルＭ’を得る。
【００５２】
Ｖｉｔｅｒｂｉ計算手段６０は、学習された障害発生モデルＭ’に対して、障害原因発見用イベント列１１０のイベントリージョンを実現する可能性が最も高い原因の順序列（シーケンス）を求める。フィルタリングモジュール７０は、Ｖｉｔｅｒｂｉ計算手段６０が求めた原因の順序列を、障害発生モデルＭ’の原因間の状態遷移確率に基づいて分割し、分割された各順序列を、原因推定結果データベース１５０に格納する。その際、障害原因発見用イベント列１１０のうちで、各原因に対応するイベントを、障害原因に対応付けて、原因推定結果データベース１５０に格納する。管理者は、原因推定結果データベース１５０に格納された情報を参照することで、根源的な原因が何かを推定する。
【００５３】
図６は、原因推定結果データベース１５０に格納された情報の具体例を示す。同図では、ｓｔａｔｅで示される部分が原因に対応している。また、ｓｔａｔｅの｛  ｝内が、その原因に対応するイベントを示している。この例では、原因の順序列は、下から上へと遷移しており、Ｔｃｐｉｐが根源的な原因であると推定される。管理者は、原因推定結果データベース１５０に格納された情報を参照することで、ＴＣＰ／ＩＰプロトコルスタックエラーが、 “Browser”、“Dhcp”、“Windows Installer 3.1”などの障害原因を引き起こしていることを知ることができる。
【００５４】
本実施形態では、イベントとその原因との対応関係を与えて障害発生モデルを生成し、その障害発生モデルに、監視対象装置８０で観察されたイベント列を与えて、イベント列の遷移から、原因の順序列を求める。このようにして求めた原因の順序列を、原因間の遷移確率に基づいて分割することで、原因の遷移の元となる、障害の根源的な原因を推定することができる。また、本実施形態では、障害発生原因間の関係は、学習用イベント列１００を初期障害発生モデルに与えることで得られ、人手で、原因間の依存関係を定義する必要がない。本実施形態では、初期障害発生モデルの生成に際して、イベントとその発生原因とを定義すればよく、イベントとその発生原因との関係は、比較的記述が容易であるため、簡易に、障害の根源的な原因を推定することができる。
【００５５】
以上、本発明をその好適な実施形態に基づいて説明したが、本発明の障害原因推定システム、方法、及び、プログラムは、上記実施形態例にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。
【産業上の利用可能性】
【００５６】
本発明は、ネットワークやコンピュータシステムの障害監視システムの用途に適用できる。また、組み込みシステムの障害発見系の用途にも適用できる。
【図面の簡単な説明】
【００５７】
【図１】本発明の一実施形態の障害原因推定装置の構成を示すブロック図。
【図２】障害発生モデルを生成する際の障害原因推定装置の動作手順を示すフローチャート。
【図３】基本モデル定義の記述例を示す図。
【図４】イベント列の分割の様子を示す模式図。
【図５】障害原因を推定する際の障害原因推定装置の動作手順を示すフローチャート。
【図６】原因推定結果データベースに格納された情報の具体例を示す図。
【図７】特許文献１に記載された障害原因発見装置の構成を示すブロック図。
【図８】特許文献２に記載された障害原因推定システムに用いられる因果システムモデル構築装置の構成を示すブロック図。
【図９】特許文献２に記載された障害原因推定システムに用いられる原因推定装置の構成を示すブロック図。
【図１０】因果関係をモデル化して示すモデル図。
【符号の説明】
【００５８】
１０：障害原因推定装置
２０：基本モデル定義
３０：初期モデルパーザ
４０：初期モデル生成手段
５０：Ｂａｕｍ−Ｗｅｌｃｈ計算手段
６０：Ｖｉｔｅｒｂｉ計算手段
７０：フィルタリングモジュール
８０：監視対象装置
９０：イベントモニタ
１００：学習用イベント列
１１０：障害原因発見用イベント列
１２０：モデル格納データベース
１３０：イベント列パーザ
１４０：イベント列データベース
１５０：原因推定結果データベース
【図１】
2007257184.tif 000003
【図２】
2007257184.tif 000004
【図３】
2007257184.tif 000005
【図４】
2007257184.tif 000006
【図５】
2007257184.tif 000007
【図６】
2007257184.tif 000008
【図７】
2007257184.tif 000009
【図８】
2007257184.tif 000010
【図９】
2007257184.tif 000011
【図１０】
2007257184.tif 000012