JP6305258B2 - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Description

本発明は、監視対象システム内の障害発生箇所を推定する技術に関する。

ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）サービスプロバイダでは、顧客が構築したシステムに対する運用監視サービスを提供している場合がある。
運用監視サービスでは、監視対象となるネットワーク機器またはサーバを監視装置で監視し、そこから通知されるアラームに基づいて顧客へ通知を行ったり、障害対応を行ったりする。
このようなＩＴサービスでは、ＩＴＩＬ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｌｉｂｒａｒｙ）やＩＳＯ／ＩＥＣ２００００（ＩＴＳＭＳ：Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）等の標準を導入するケースが多い。
このような標準を使用して、運用監視サービスの標準化、自動化を行う場合、監視対象となるネットワーク機器またはサーバの構成情報を格納する構成管理データベース（ＣＭＤＢ：Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａｂａｓｅ）を整備することでアラーム対応を効率化することができる。

アラーム対応は、次のような流れで行われる。
まず、運用監視センターにて、アラーム発生時にアラームの内容を確認する。
次に、アラームが発生したネットワーク機器またはサーバの構成情報を確認し、どの機器で障害が発生しているかを推定する。
その後、障害対応の手順書に従って障害の解析、対応等を行う。
運用監視センターで対応できない場合は、障害が発生しているネットワーク機器またはサーバを管理している部門または客先等の予め決められた連絡先へアラームを通知する。
障害箇所の推定に時間がかかった場合、運用監視サービスの品質は低下してしまう。
アラーム対応において、構成情報を確認し、効率的に障害箇所を推定する従来技術として、大きく２種類の方法が挙げられる。

１つめは、相関ルールによる障害箇所の推定である（例えば、特許文献１）。
例えば、構成の接続条件、指標とその状態、何が原因か等を相関ルールとして定義し、それらを決められた時間内に発生している複数アラームに対して適用することで、障害箇所を推定する。

２つめは、隣接行列を用いた障害箇所の推定である（例えば、特許文献２）。
例えば、複数の階層からなるシステムの統合的な監視を行う場合において、機器間の接続関係を表す隣接行列を生成し、行列演算を行うことによって監視を行う。

国際公開ＷＯ２０１１／０３９８２５号 特開２０１２−２２２３７１号公報

図３１は、監視対象システムの構成例とアラーム発生箇所を示す。
図３１において、四角形はシステムの構成要素（ＣＩ：Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｉｔｅｍ）、矢印はＣＩ間の依存関係、稲妻は発生したアラーム、ａ〜ｋはＣＩの識別子である。
図３１中のＣＩと依存関係は、監視対象システムの構成について、顧客である「Ａ社」が「メールサービス」を利用しており、「メールサービス」は「メールシステム」で構成されており、「メールシステム」は「サーバ１」〜「サーバ７」で構成されており、「サーバ１」〜「サーバ７」は「ＦＷ（ファイアウォール）」に影響されていることを示している。
また、アラームは、「サーバ１」〜「サーバ７」、「ＦＷ」で発生していることを示している。
アラームを発生させたＣＩは、アラーム発生ＣＩ又はアラーム発生システム構成要素ともいう。
図３１の例では、「ＦＷ」（識別子：ｋ）で障害が発生し、「サーバ１」〜「サーバ７」がリンクダウンによって疎通確認が出来なくなったというアラームを発生したことを想定している。
図３１において複数発生しているアラームの根本原因は、構成情報の依存関係を辿ることにより、依存関係先（矢印の先）にある「ＦＷ」（識別子：ｋ）であると推定することができる。

図３１で示した例に対し、前述した従来技術を活用することも可能である。
１つめの従来技術のように、ＦＷ障害が原因で他サーバに疎通アラームが発生する、という相関ルールを定義しておくことにより、根本原因を推定することも可能である。
また、２つめの従来技術のように、ＣＩ間の依存関係から隣接行列を作成して距離行列を求め、最上位にあるＣＩ（図３１では「Ａ社」）から、アラームが発生しているＣＩの中で最も距離の遠いＣＩを根本原因として推定することも可能である。
図３２は、図３１を元に作成した距離行列に対してアラーム発生箇所をマッピングした例である。
図３２のａ〜ｋは、図３１に示すＣＩの識別子であるａ〜ｋを表している。
距離行列の列は距離を求める際の始点となるＣＩ名、行は距離を求めるＣＩ名である。
例えば、ａ列のｂ行の「１」は、ａからｂまでの距離が１であることを意味する。
この例では、表中の反転表示部分がアラーム発生ＣＩ（図３１で稲妻が表示されているＣＩ）を示している。
最上位ＣＩであるａ「Ａ社」から、アラーム発生ＣＩの中で最も距離の遠いｋ「ＦＷ」を根本原因として推定する。

相関ルールによって根本原因を推定する方式の場合、発生し得るアラームの種類、発生箇所ごとにルールを設定する必要があり、ルールの作成、メンテナンスのコストが膨大となる。

また、監視対象システムの一部または全てが自社の管理下でない等、詳細な構成情報を利用することができない場合、従来技術によって障害箇所を推定出来ないことがある。
詳細な構成情報や現在の接続状態の取得は、ＣＭＤＢ製品に付属しているオートディスカバリ機能等を利用することによっても実現できる。
自社システムの運用監視においては、オートディスカバリ機能等は問題なく利用できる場合が多い。
しかし、例えば、ＩＴサービスプロバイダが、ハウジングサービスによって顧客資産のシステムをデータセンター内に預かっている場合や、仮想サーバの貸し出しサービスによって顧客がどのように仮想サーバを利用しているか関知していない場合においては、顧客の同意なくオートディスカバリ機能等を利用することができない。
顧客から開示される構成情報のみでは、従来技術を適用するためには不十分である場合が多い。
このような状況で従来技術を適用すると、サーバ間の依存関係、アプリケーション情報等の詳細な情報が不十分であり、根本原因を推定することができない。

図３３及び図３４は、管理している構成情報によって、障害箇所を推定できないアラームが発生した場合の例である。
図３３は、「サーバ１」と「サーバ２」でアラームが発生していることを示している。
図３４は、図３３を元に作成した距離行列に対してアラーム発生箇所をマッピングした例である。
この例では、最上位ＣＩ「Ａ社」から「サーバ１」、「サーバ２」までの距離が同じであり、どちらが根本原因か推定することができない。

更に、構成情報を格納するＣＭＤＢのデータ構造を容易に変更できないという課題もある。
ＣＭＤＢのデータ構造は、運用監視システムの設計時に決定し、システム運用中には変更しないことが通常である。
監視対象システムの変更が発生した場合は、データ構造の変更は行わず、個々の構成情報を更新することによって対応する。
そのため、例えば、ある顧客の運用監視においてのみ、ＣＭＤＢのデータ構造に無い新たな構成情報を管理したいという状況が発生した場合、それらの情報をＣＭＤＢに格納することができず、その情報を運用監視に活かしにくい。

本発明は上記のような課題を解決することを主な目的とし、構成情報が不十分な場合、または、構成情報の変更が難しい場合でも、精度よく障害発生箇所を推定できるようにすることを主な目的とする。

本発明に係る情報処理装置は、
監視対象システムのシステム構成を既定のデータ構造で定義する構成情報のコピーから、前記既定のデータ構造とは異なる障害発生箇所推定用のデータ構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成部と、
前記監視対象システムで障害が発生した際に、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、前記監視対象システム内の障害発生箇所を推定する解析推定部とを有することを特徴とする。

本発明によれば、構成情報が不十分な場合、または、構成情報の変更が難しい場合でも、構成情報のコピーに対して障害発生箇所推定用のデータ構造を適用して障害発生箇所推定用構成情報を生成し、構成情報を維持したまま、障害発生箇所推定用構成情報を用いて、精度よく障害発生箇所を推定することができる。

実施の形態１及び２に係るシステム構成例を示す図。 構成管理モデルの例を示す図。 構成管理モデルの例を示す図。 ＣＭＤＢで管理されている構成情報の例を示す図。 ＣＭＤＢで管理されている構成情報の例を示す図。 ＣＭＤＢで管理されている構成情報の例を示す図。 構成情報変形ルールの例を示す図。 属性追加の例を示す図。 構成情報変形ルールによって構成情報を変形した例を示す図。 構成情報変形ルールによって構成情報を変形した例を示す図。 構成情報変形ルールによって構成情報を変形した例を示す図。 実施の形態１に係る監視システムの動作の流れを示すフローチャート図。 実施の形態１に係る構成情報変形ルール適用部の動作の流れを示すフローチャート図。 実施の形態１に係る距離情報生成部の動作の流れを示すフローチャート図。 実施の形態１に係る距離情報の例を示す図。 実施の形態１に係る距離情報の例を示す図。 実施の形態１に係る距離情報の例を示す図。 実施の形態１に係る距離情報の例を示す図。 実施の形態１に係る障害箇所推定部の動作の流れを示すフローチャート図。 実施の形態２に係る距離情報生成部の動作の流れを示すフローチャート図。 実施の形態２に係る距離ごとのＣＩリストの例を示す図。 実施の形態２に係る障害箇所推定部の動作の流れを示すフローチャート図。 実施の形態３及び４に係るシステム構成例を示す図。 実施の形態３に係る障害箇所推定部の動作の流れを示すフローチャート図。 実施の形態３に係る構成情報のグラフを辿る例を示す図。 実施の形態４に係る障害箇所推定部の動作の流れを示すフローチャート図。 実施の形態４に係る依存関係の重みづけの例を示す図。 実施の形態５に係るシステム構成例を示す図。 実施の形態５に係る構成情報変形ルールの例を示す図。 実施の形態１〜５に係る監視システムのハードウェア構成例を示す図。 構成情報とアラーム発生の例を示す図。 構成情報とアラーム発生の例を示す図。 障害箇所を推定できないアラーム発生の例を示す図。 障害箇所を推定できないアラーム発生の例を示す図。

実施の形態１．
本実施の形態及び以降の実施の形態では、構成情報が不十分な場合、または、ＣＭＤＢのデータ構造の変更が難しい場合において、障害箇所推定の精度を向上させることが可能であり、また、メンテナンスコストを削減することが可能な構成を説明する。

より具体的には、ＣＭＤＢに格納されている不十分な構成情報に対し、構成情報を変形させるルールによってＣＭＤＢの外部で構成情報を変形させ、変形後の構成情報を元にＣＩ間の距離情報を求めることにより、障害箇所推定の精度を向上させる構成を説明する。

まず、構成について説明する。
図１は、本実施の形態に係るシステム構成例を示す。
本実施の形態に係るシステムは、クライアント装置１０、監視システム２０及び監視対象システム３０から構成される。
監視対象システム３０は、監視システム２０が監視を行うシステムの一例であり、ネットワーク機器（ＦＷ：ファイアウォール、ＳＷ：スイッチ）、サーバ等から構成される。 監視システム２０は、監視対象システム３０をインターネットまたはイントラネットを経由して監視する。
クライアント装置１０は、監視を行うオペレータが使用する端末装置である。
オペレータは、監視システム２０が表示する情報を、クライアント装置１０から確認する。
監視システム２０は、監視対象システム３０に対して監視を行い、障害を検知する。
また、検知した障害から、障害原因箇所を推定し、オペレータに対して推定結果を表示する。
監視システム２０は、情報処理装置の例に相当する。

監視システム２０において、画面表示部２０１は、オペレータが監視システム２０を利用する際に、クライアント装置１０へ表示する画面を生成する。
オペレータは、クライアント装置１０を通して、画面表示部２０１が表示する画面を利用し、発生した障害の確認等を行う。

障害箇所推定部２０２は、監視対象システム３０で発生した障害情報と、監視対象システム３０の構成情報を用いて障害原因箇所の推定を行う。
より具体的には、障害箇所推定部２０２は、最上位のＣＩからの距離が最も遠いアラーム発生ＣＩ（アラーム発生システム構成要素）を障害発生箇所として推定する。
つまり、障害箇所推定部２０２は、最上位階層のＣＩからの階層差数が最も多いアラーム発生ＣＩを、障害を発生させたＣＩと推定する。
障害箇所推定部２０２は、後述する距離情報生成部２０４とともに解析推定部の例に相当する。

障害情報収集部２０３は、監視対象システム３０を監視し、発生した障害情報を収集し、障害情報ＤＢ２１１に格納する。
障害情報をオペレータへ表示する場合には、障害情報収集部２０３は、障害情報ＤＢ２１１より障害情報を取得する。
障害情報収集部２０３は、一般的な監視システムで用いられている監視機能と同様の機能である。

距離情報生成部２０４は、構成情報変形ルール適用部２０５から渡される構成情報を元に、ＣＩ間の距離情報を生成し、距離情報ＤＢ２１２に格納する。
距離情報生成部２０４は、前述の障害箇所推定部２０２とともに解析推定部の例に相当する。

構成情報変形ルール適用部２０５は、ＣＭＤＢ２１３に格納されている構成情報、予め定義しておいた構成情報変形ルール２１４を元に、構成情報を補完し、変形する。
より具体的には、ＣＭＤＢ２１３に格納されている構成情報のコピーを変形して、障害発生箇所の推定用の新たな構成情報（障害発生箇所推定用構成情報）を生成する。
変形後の新たな構成情報は、距離情報生成部２０４に渡され、距離情報が生成される。
構成情報変形ルール適用部２０５は、推定用構成情報生成部の例に相当する。

なお、図１の監視システム２０では、発生した障害の確認に必要最低限の機能のみを記載しているが、例えば、障害対応状況の記録機能や、従来技術として前述した相関ルールによる障害箇所の推定機能が含まれてもよい。

次に、監視システム２０内の情報記憶装置について説明する。
障害情報ＤＢ２１１は、障害情報収集部２０３が収集した障害情報を保持する。
距離情報ＤＢ２１２は、距離情報生成部２０４が作成したＣＩ間の距離情報を保持する。
距離情報の形式は、距離行列、リスト等、形式は問わない。
ＣＭＤＢ２１３は、構成管理モデルに定義されたデータ構造を持つ構成管理データベースである。
構成管理モデル、格納される構成情報の例は後述する。
構成情報変形ルール２１４は、ＣＭＤＢ２１３に格納された構成情報を補完し、変形させるためのルールである。
構成情報変形ルール２１４の例は後述する。

次に、ＣＭＤＢ２１３の構成管理モデル、格納される構成情報の例を説明する。

図２及び図３は、構成管理モデルの一例である。
図２は、構成管理モデルとして定義するＣＩ型の例である。
ここで定義したＣＩ型の例を説明する。
「顧客」は、サービスを利用する顧客の属性を格納するＣＩ型であり、例えば、顧客名、略称等の属性を持つ。
顧客情報をＣＭＤＢ２１３に格納する場合、顧客ＣＩ型を用いてＣＩを作成する。
図３は、図２で定義したＣＩ型間の依存関係の例である。
図中の矢印が依存関係を表す。
この例では、「顧客」は「サービス」に依存し、「サービス」は「システム」に依存し、「システム」は「ノード」に依存し、「ノード」は「ハードウェア」と「アプリケーション」に依存する。
ＣＩを格納する際には、モデルで定義された依存関係の位置に、ＣＩ間の依存関係を定義することができる。
本明細書では、矢印の元を依存関係元、矢印の先を依存関係先と呼ぶこととする。

図４及び図５及び図６は、ＣＭＤＢ２１３で管理される構成情報の例である。
ここでは図２及び図３で示した構成管理モデルが定義されている前提とする。
図４は、ＣＩ名とＣＩ型名の対応の例であり、ＣＩとして作成された構成情報とその型名の関係を示している。
ａは、ＣＩ型名が「顧客」の「Ａ社」というＣＩをＣＭＤＢ２１３で管理していることを意味する。
ｂは、ＣＩ型名が「サービス」の「メールサービス」というＣＩをＣＭＤＢ２１３で管理していることを意味する。
それ以降についても同様である。
図５は、図４で示したＣＩ間の依存関係の例である。
この例では、「Ａ社」は「メールサービス」を利用しており、「メールサービス」は「メールシステム」で構成されており、「メールシステム」は「サーバ１」〜「サーバ７」で構成されており、「サーバ１」〜「サーバ７」はＦＷに影響されていることを示している。
図６は、図４及び図５の情報を可視化したＣＩの関係図である。

図４〜図６に示すように、構成情報変形ルール適用部２０５による変形前の構成情報は、既定のデータ構造である既定の階層構造で監視対象システム３０のシステム構成が定義されている。
このような構成情報に対して、構成情報変形ルール適用部２０５は、構成情報変形ルールを適用して、障害発生箇所推定用の新たなデータ構造である新たな階層構造で監視対象システム３０のシステム構成を定義する新たな構成情報（障害発生箇所推定用構成情報）を生成する。

図７は、構成情報変形ルール２１４の例を示す。
Ｎｏはルール番号であり、構成情報変形ルール２１４は構成情報を変形するためのルール定義である。
構成情報変形ルールの記述方法は問わない。
例えば、述語論理でも、表形式でも構わない。
ルールの詳細は、図７、図８、図９と合わせて、構成情報変形ルールによる構成情報の変形方法として後述する。

図８は、ＣＭＤＢ２１３に格納されている構成情報を補完するために追加したい属性の例を示す。
「サーバ１」のＣＩに対して「ＤＢサーバ」、「サーバ２」のＣＩに対して「Ｗｅｂサーバ」という役割の属性を追加したい場合の例を示している。
図８の情報は、例えば、オペレータがクライアント装置１０から監視システム２０に設定する。

図９、図１０、図１１は、構成情報変形ルールによって構成情報を変形した例を示す。
つまり、図９は、図６で示したＣＩの関係図を、図７の構成情報変形ルールによって変形した図である。
また、図１０は、図４で示したＣＩ名とＣＩ型名の対応を、図７の構成情報変形ルールによって変形した図である。
また、図１１は、図５で示したＣＩ間の依存関係を、図７の構成情報変形ルールによって変形した図である。

図７のＮｏ．１のルールは、ノードの属性がＤＢサーバの場合、ＣＩ型がアプリケーションの「ＤＢ」というＣＩを追加し、追加した「ＤＢ」からＤＢサーバの属性を持つノードへの依存関係を追加する、というものである。
このルールに従った構成情報の変更は、図９中の点線の四角で囲んだ「１」の数字に該当する。
つまり、「ＤＢ」というＣＩからサーバ１への依存関係がルールのＮｏ．１によって追加される。
図７のＮｏ．２のルールは、ノードの属性がＷｅｂサーバの場合、ＣＩ型がアプリケーションの「Ｗｅｂ」というＣＩを追加し、追加した「Ｗｅｂ」からＷｅｂサーバの属性を持つノードへの依存関係を追加する、というものである。
このルールに従った構成情報を変更は、図９中の点線の四角で囲んだ「２」の数字に該当する。
つまり、「Ｗｅｂ」というＣＩとサーバ２への依存関係がルールのＮｏ．２によって追加される。
同様に、ルール３〜４についてもＣＩと依存関係を追加する。
このように、構成情報変形ルール適用部２０５は、監視対象システム３０に含まれる複数のシステム構成要素（ＣＩ）に、構成情報変形ルール２１４に記述される特定の属性を有するシステム構成要素（ＣＩ）が含まれるか否かを判断し、そのようなＣＩが含まれる場合は、構成情報変形ルール２１４に従って新たなＣＩと新たな依存関係を追加する。

このようなＣＩ及び依存関係の追加によって、構成情報変形ルール適用部２０５は、もとの構成情報では図６のように定義されていた監視対象システム３０の階層構造を、障害発生箇所の推定に適した図９の階層構造に変化させることができる。
なお、前述したように、構成情報変形ルール適用部２０５は、ＣＭＤＢ２１３に格納されている構成情報のコピーに対して図９〜図１１に例示するようなＣＩ及び依存関係の追加を行う。
このため、ＣＭＤＢ２１３内の構成情報に変更を加えることなく、障害発生箇所の推定用に新たな構成情報を取得することができる。

次に動作について説明する。
図１２は、監視システム２０による障害箇所推定のフローチャートである。

Ｓ０１は、構成情報変形ルール適用部２０５の動作であり、構成情報変形ルール２１４に従って構成情報の変形を行う。
Ｓ０１の詳細フローは、図１３にて説明する。

Ｓ０２は、距離情報生成部２０４の動作であり、Ｓ０１で変形された構成情報、または、構成情報変形ルール２１４が設定されていない場合はＣＭＤＢ２１３に格納されている構成情報を元に、距離情報を生成する。
Ｓ０２の詳細フローは、図１４にて説明する。

Ｓ０３では、現在障害が発生しているかどうかを確認する。
障害が発生している場合は、Ｓ０４に進む。
障害が発生していない場合は、終了する。

Ｓ０４は、障害箇所推定部２０２の動作であり、現在発生している障害情報とＳ０２で求めた距離情報を元に、障害箇所推定を行う。
Ｓ０４の詳細フローは、図１９にて説明する。

Ｓ０５は、画面表示部の動作であり、イベント情報と障害箇所推定の結果を画面に表示する。

図１３は、構成情報変形ルール適用部２０５のフローチャートである。

Ｓ０１１では、構成情報変形ルール適用部２０５が構成情報変形ルール２１４を取得する。
Ｓ０１２では、構成情報変形ルール適用部２０５は、取得した構成情報変形ルール２１４を確認し、構成情報変形ルール２１４によって変形された構成情報から距離情報が生成されていないルールがあるかどうかを確認する。
つまり、変更（新規／修正／削除）されたルールや、変更されていないが距離情報の生成が行われていないルールの有無を確認する。
例えば、ルールが変更された際に、ルールに対して変更内容（新規／修正／削除）を表すフラグを付けたり、距離情報の生成が行われた際に、ルールに対して距離情報生成済であることを表すフラグを付ける仕組みにしておくことにより、判断することができる。
距離情報が生成されていない場合は、Ｓ０１３に進む。
距離情報が生成されていない構成情報変形ルールがない場合は、終了する。
Ｓ０１３では、構成情報変形ルール適用部２０５は、ＣＭＤＢ２１３に格納されている構成情報のコピーを取得する。
Ｓ０１４では、取得した構成情報のコピーを構成情報変形ルール２１４を元に変形し、変形された構成情報を一時的に作成する。
変形の方法については、図９〜図１１で示した通りである。

図１４は、距離情報生成部２０４のフローチャートである。

Ｓ０２１では、距離情報生成部２０４は、生成したい距離行列が既に生成済で距離情報ＤＢ２１２に格納されているかどうかを判断する。
生成済の場合は、終了する。
生成済でない場合は、Ｓ０２２に進む。

Ｓ０２２では、距離情報生成部２０４は、距離を求めたい構成情報を取得する。
ここでの構成情報とは、構成情報変形ルール２１４が定義されている場合には、構成情報変形ルール適用部２０５にて変形された構成情報、ない場合には、ＣＭＤＢ２１３より取得された変形されていない構成情報を意味する。

Ｓ０２３では、距離情報生成部２０４は、取得した構成情報を元に、探索経路の異なる距離行列を生成する。
図１５、図１６、図１７、図１８は、図９の構成情報を元に生成した距離行列の例である。
図１５は、通常（ａからの最短経路の距離）の距離行列である。
図１６は、ａ→ｂ→ｃ→ｍ→ｅ→ｋの経路を通る場合の距離行列である。
図１７は、ａ→ｂ→ｃ→ｌ→ｄ→ｋの経路を通る場合の距離行列である。
図１８は、ａ→ｂ→ｃ→ｍ→ｌ→ｄ→ｋの経路を通る場合の距離行列である。
図中のアルファベットは、図９の識別子と対応する。
通常は図１５の距離行列であるが、複数経路がある場合には、各経路に沿った距離を距離行列に反映させる。
図１６の場合、経路はａ→ｂ→ｃ→ｍ→ｅ→ｋであるため、図１５と比較すると、ｅとｋの距離が異なっている。
図１６、図１７、図１８では、経路に関係ないＣＩについては、図１５と同様に最短距離の値としている。

Ｓ０２４では、距離情報生成部２０４は、生成した距離行列を距離情報ＤＢ２１２へ格納する。

図１９は、障害箇所推定部２０２のフローチャートである。

Ｓ０３１では、障害箇所推定部２０２は、障害情報ＤＢ２１１から、現在発生している障害情報を取得する。
Ｓ０３２では、障害箇所推定部２０２は、距離情報ＤＢ２１２から、距離情報を取得する。
Ｓ０３３では、障害箇所推定部２０２は、複数の距離行列から、アラームが発生していて、かつ、最も距離の遠いＣＩを障害箇所として推定する。

図１５、図１６、図１７、図１８を用いて説明を行う。
例えば、ｌとｍでアラームが発生したとする。
図１５の通常の距離行列ではｌとｍの距離が同じになり、どちらが障害箇所かを推定することが出来ない。
図１６、図１７、図１８の各経路を通る場合の距離行列を確認すると、図１６及び図１７は図１５と同様であるが、図１８の場合、ｌの距離が４、ｍの距離が３となる。
これより、障害箇所推定部２０２は、アラームが発生していて、かつ、距離の遠いｌが障害箇所であると推定することができる。

このように、障害箇所推定部２０２は、障害箇所を推定する際に、複数経路の距離行列を作成することにより、障害箇所を推定することができる。

以上のように、本実施の形態に係る監視システム２０は、ＣＭＤＢ２１３に格納されていない情報を運用監視に活用することを可能とする。
そのため、ＣＭＤＢ２１３に格納されている構成情報のみよりも、精度の高い障害箇所推定を行うことができる。
また、ＣＭＤＢ２１３外部で構成情報を変形させるため、ＣＭＤＢ２１３の構造を変更する必要がない。
構成情報の変形ルールは、従来技術の相関ルールよりも設定数が少なくて済むと考えられるため、ルールのメンテナンスコストを抑えることも可能である。

以上、本実施の形態では、既にＣＭＤＢ等で管理されている構成情報に対し、ＣＭＤＢのデータ構造や管理されている構成情報を変更することなく、構成情報変形ルールによって、ＣＭＤＢの外側で構成情報を変形させることにより、障害箇所推定の精度を上げることが可能な監視システムを説明した。

また、本実施の形態では、構成情報から経路が異なる複数の距離行列を生成し、アラーム発生ＣＩの中で、最上位ＣＩから最も遠く、一意になったＣＩを障害箇所と推定する監視システムを説明した。

実施の形態２．
本実施の形態に係るシステム構成は、図１に示す通りであり、実施の形態１と同様である。
動作については、距離情報生成部２０４、障害箇所推定部２０２が実施の形態１と異なるため、差分のみを説明する。

図２０は、実施の形態２の距離情報生成部２０４のフローチャートである。
Ｓ０４３では、距離情報生成部２０４は、取得した構成情報を元に、構成情報の最上位のＣＩから最長経路までの距離ごとのＣＩリストを作成する。
図９の例では、最上位のＣＩは「Ａ社」である。
最上位からの最短距離１はｂの「メールサービス」である。
距離２はｃの「メールシステム」である。
ｄの「サーバ１」は、依存関係がａ→ｂ→ｃ→ｄの場合に距離３、ａ→ｂ→ｃ→ｌ→ｄの場合に距離４、ａ→ｂ→ｃ→ｍ→ｌ→ｄの場合に距離５の３パターンがある。
最長距離６はｋの「ＦＷ」である。
Ｓ０２２で作成するＣＩリストの例を図２１に示す。
距離１のＣＩはｂの「メールサービス」、距離６のＣＩはｋの「ＦＷ」である。

図２２は、実施の形態２の障害箇所推定部２０２のフローチャートである。

Ｓ０５３では、障害箇所推定部２０２は、最長経路の距離リストから順にアラーム発生ＣＩと比較し、最初に見つかったアラーム発生ＣＩを障害発生箇所と推定する。
このように、本実施の形態でも、障害箇所推定部２０２は、最上位階層のＣＩからの階層差数が最も多いアラーム発生ＣＩを、障害を発生させたＣＩと推定する。

図２１のＣＩリストを用いて障害箇所推定部２０２の動作の説明を行う。
ｄの「サーバ１」とｅの「サーバ２」でアラームが発生しているとする。
最長経路の６のリストから比較を行った場合、距離５のリストにｄが見つかり、「サーバ１」が障害箇所であると推定できる。
もし最短経路の１のリストから比較を行っていた場合、距離３のリストにｄとｅの両方が見つかり、これ以上、障害箇所を絞り込むことができない。

以上のように、本実施の形態では、障害箇所を推定する際に、距離ごとのＣＩリストを作成し、最長距離からアラーム発生ＣＩを検索することにより、障害箇所を推定することができる。

以上、本実施の形態では、構成情報から距離毎のＣＩリストを作成し、最長距離のＣＩリストからアラーム発生ＣＩを検索し、最も距離が長く、一意になったＣＩを障害箇所と推定する監視システムを説明した。

実施の形態３．
実施の形態１、２では、複数の経路がある場合に距離行列、距離ごとのＣＩリストを作成したが、ルート上でアラームが発生している数が多い経路において距離をカウントする方式も考えられる。
この方式では、距離行列や距離ごとのＣＩリストを使用せず、構成情報のグラフを辿ることにより障害箇所を推定する。

本実施の形態に係るシステム構成例は、図２３に示す通りである。
本実施の形態では、図１に示した距離情報生成部２０４、距離情報ＤＢ２１２が不要である。
動作については、障害箇所推定部２０２が実施の形態１、２と異なるため、差分のみを説明する。

図２４は、実施の形態３の障害箇所推定部２０２のフローチャートである。
Ｓ６２では、障害箇所推定部２０２は、構成情報を辿り、アラーム発生ＣＩ数が多い経路において、最も距離の遠いアラーム発生ＣＩを障害箇所として推定する。

Ｓ６２の動作を、図２５の構成情報のグラフを辿る例を用いて説明する。
この例では、最上位ＣＩのａからアラームが発生しているｌまたはｍまでの経路として次の３つが考えられる。
・ａ→ｂ→ｃ→ｌの経路：距離が３、経路上のアラーム発生ＣＩ数が１
・ａ→ｂ→ｃ→ｍの経路：距離が３、経路上のアラーム発生ＣＩ数が１
・ａ→ｂ→ｃ→ｍ→ｌの経路：距離が４、経路上のアラーム発生ＣＩ数が２
この場合、３番目の経路が最も経路上のアラーム数が多いので、その経路で最も距離の遠いアラーム発生ＣＩであるｌを障害箇所と推定する。

以上のように、実施の形態では、障害箇所を推定する際に、アラーム発生ＣＩ数の多い経路を辿ることにより、障害箇所を推定することができる。

以上、本実施の形態では、構成情報のグラフを辿り、その経路上の発生アラーム数をカウントし、最も発生アラーム数が多い経路で最も遠いアラーム発生ＣＩを障害箇所と推定する監視システムを説明した。

実施の形態４．
依存関係に重みづけをして探索する障害箇所推定の方式も考えられる。
実施の形態１のように距離行列を使用する場合は、最上位のＣＩから対象とするＣＩまでの距離を使用した。
実施の形態４では、ＣＩに距離の値を振るのではなく、依存関係を示す矢印の部分に重みづけを行う。
つまり、本実施の形態でも、障害箇所推定部２０２は、最上位階層のＣＩからの階層差数が最も多いアラーム発生ＣＩを障害を発生させたＣＩと推定するが、本実施の形態では、階層差数として距離ではなく依存関係の重みを用いる。

システム構成については、図２３であり、実施の形態３と同様である。
動作については、障害箇所推定部２０２が実施の形態３と異なるため、差分のみを説明する。
図２６は、実施の形態４における障害箇所推定部２０２のフローチャートである。
図２７は、依存関係の重みづけの例である。

Ｓ７２では、障害箇所推定部２０２は、構成情報の依存関係に重みづけをする。
最上位ＣＩを始点とする矢印の重みを１とする。
その終点であるＣＩを新たな始点とする矢印の重みは、１を足して２とする。
同様にして、矢印の重みを付けていく。
複数の終点があるＣＩの場合は、重みが大きい方を採用する。
Ｓ７３では、障害箇所推定部２０２は、障害情報を元に各ＣＩにマークを付ける。
Ｓ７４では、障害箇所推定部２０２は、依存関係の矢印の両端にアラーム発生のマークがついており、その中で最も重みの値が大きい矢印の終点にあるＣＩを障害箇所として推定する。
図２７では、塗りつぶされたＣＩが障害箇所と推定される。

以上のように、実施の形態では、障害箇所を推定する際に、依存関係への重みづけを行うことにより、障害箇所を推定することができる。

以上、本実施の形態では、構成情報の依存関係への重みづけ、ＣＩへのアラーム発生のマークづけを行い、依存関係を表す矢印の両端にアラーム発生マークが付いており、その中で最も重みの大きい矢印の終点にあるＣＩを障害箇所と推定する監視システムを説明した。

実施の形態５．
実施の形態１〜４では、ＣＩの役割の属性に応じて構成情報変形ルールを適用していた。
つまり、実施の形態１〜４では、図８の情報により、構成情報変形ルール（図７）で定義されている属性（ＤＢサーバ、Ｗｅｂサーバ）を有するＣＩが特定されていた。
本実施の形態では、監視対象システム３０内のＣＩから上げられたデータ（アラーム、イベント）に応じて、構成情報変形ルールを適用する。

図２８は、実施の形態５に係る構成図である。
以下では、実施の形態１〜４との相違点のみ説明する。
ログ抽出部２２１は、監視対象システム３０から集められた障害情報（イベント情報、アラーム情報など）を障害情報収集部２０３から取得し、構成情報変形ルールを適用するための前提条件となるログを抽出して、構成情報変形ルール適用部２０５にその情報を渡す。

図２９は、構成情報変形ルールの例である。
ルール適用条件は、ログ抽出部２２１がログを抽出する際に使用する、検索条件となる。
ＣＩで生成されたログ、アラームに含まれる文字列がルール適用条件に合致する場合、ＣＩで生成されたログファイルが保存されているフォルダのフォルダ名がルール適用条件に合致する場合に、対応する構成情報変形ルールが適用になる。
なお、図２９では、他の実施の形態と同様に、発生した障害の確認に必要最低限の機能のみを記載しているが、例えば、障害対応状況の記録機能や、従来技術として前述した相関ルールによる障害箇所の推定機能が含まれてもよい。

次に動作について説明する。
以下では、実施の形態１〜４との相違点のみ説明する。
ログ抽出部２２１は、構成情報変形ルール２１４から、ルール適用条件を取得する。
次に、ログ抽出部２２１は、障害情報収集部２０３から障害情報を取得し、ルール適用条件に合致するログがあるかどうかを検索する。
合致するログがあった場合、そのログを出力したＣＩを特定し、構成情報変形ルール適用部２０５にＣＩ情報を渡す。
構成情報変形ルール適用部２０５は、そのＣＩに対して構成情報変形ルールを適用する。
適用の方法については、実施の形態１〜４と同様である。

以上のように、本実施の形態では、障害箇所を推定する際に、監視対象から集められた障害情報の内容によって、適用する構成情報変形ルールを変えることができる。
これにより、ＣＩに対して属性を決定できない場合や、一つのＣＩに対して複数の属性が入る可能性がある場合に、障害情報に応じて動的に適切な構成情報変形ルールを適用し、障害箇所を推定することができる。

以上、本実施の形態では、監視対象システムから上げられたアラーム、イベントなどの情報に応じて、構成情報変形ルールを適用する監視システムを説明した。

また、本実施の形態１〜５では、ＣＩと依存関係を追加するルールの例を説明したが、ＣＩや依存関係を削除するルールを定義してもよい。
その場合、障害情報の内容に応じて、障害箇所の絞り込みを行うことができる。
また、元の構成情報の依存関係が循環参照していた場合に、障害情報に応じた構成情報変形ルールによって依存関係を削除し、循環が無い構成情報としたのち、障害箇所特定を行うことも可能である。

実施の形態１〜５で示したように、構成情報のコピーに対してＣＭＤＢに格納されていない情報を付加することにより、ＣＭＤＢのデータ構造や格納されている構成情報を変更することなく、障害箇所推定の精度を高めることができる。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

最後に、実施の形態１〜５に示した監視システム２０のハードウェア構成例を図３０を参照して説明する。
監視システム２０はコンピュータであり、監視システム２０の各要素をプログラムで実現することができる。
監視システム２０のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。

演算装置９０１は、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。

プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１及び図２３に示す「〜部」の機能を実現するプログラムを実行する。
また、実施の形態１〜５の説明において、「〜の判断」、「〜の判定」、「〜の解析」、「〜の推定」、「〜の生成」、「〜の算出」、「〜の抽出」、「〜の設定」、「〜の変形」、「〜の変更」、「〜の選択」、「〜の比較」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。

なお、図３０の構成は、あくまでも監視システム２０のハードウェア構成の一例を示すものであり、監視システム２０のハードウェア構成は図３０に記載の構成に限らず、他の構成であってもよい。

また、実施の形態１〜４に示す手順により、本発明に係る情報処理方法を実現可能である。

１０ クライアント装置、２０ 監視システム、３０ 監視対象システム、２０１ 画面表示部、２０２ 障害箇所推定部、２０３ 障害情報収集部、２０４ 距離情報生成部、２０５ 構成情報変形ルール適用部、２１１ 障害情報ＤＢ、２１２ 距離情報ＤＢ、２１３ ＣＭＤＢ、２１４ 構成情報変形ルール、２２１ ログ抽出部。

Claims (10)

1. 監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成部と、
   前記監視対象システムで障害が発生した際に、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、前記監視対象システム内の障害発生箇所を推定する解析推定部とを有し、
   前記推定用構成情報生成部は、
   前記複数のシステム構成要素に特定の属性を有するシステム構成要素が含まれるか否かを判断し、
   前記複数のシステム構成要素に前記特定の属性を有するシステム構成要素が含まれる場合に、前記障害発生箇所推定用構成情報を生成することを特徴とする情報処理装置。
2. 前記推定用構成情報生成部は、
   前記複数のシステム構成要素で生成されたデータを解析して、前記複数のシステム構成要素に前記特定の属性を有するシステム構成要素が含まれるか否かを判断することを特徴とする請求項１に記載の情報処理装置。
3. 前記推定用構成情報生成部は、
   前記複数のシステム構成要素で生成されたデータに含まれる文字列及び前記複数のシステム構成要素で生成されたデータが保存されているフォルダのフォルダ名の少なくともいずれかを解析して、前記複数のシステム構成要素に前記特定の属性を有するシステム構成要素が含まれるか否かを判断することを特徴とする請求項２に記載の情報処理装置。
4. 監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成部と、
   前記監視対象システムで障害が発生した際に、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、アラームを発生させた複数のアラーム発生システム構成要素について、アラーム発生システム構成要素ごとに、前記複数のシステム構成要素のうちの最上位階層のシステム構成要素からアラーム発生システム構成要素までの階層差数を算出し、算出した階層差数に基づき、前記複数のアラーム発生システム構成要素の中から、前記障害を発生させたアラーム発生システム構成要素を推定する解析推定部とを有する情報処理装置。
5. 前記解析推定部は、
   前記複数のアラーム発生システム構成要素のうち、前記最上位階層のシステム構成要素からの階層差数が最も多いアラーム発生システム構成要素を、前記障害を発生させたアラーム発生システム構成要素と推定することを特徴とする請求項４に記載の情報処理装置。
6. 前記解析推定部は、
   前記最上位階層のシステム構成要素から各アラーム発生システム構成要素までの経路が複数存在する場合に、当該複数の経路のうちアラーム発生システム構成要素が最も多く含まれる経路を抽出し、
   抽出した経路に含まれるアラーム発生システム構成要素のうち、前記最上位階層のシステム構成要素からの階層差数が最も多いアラーム発生システム構成要素を、前記障害を発生させたアラーム発生システム構成要素と推定することを特徴とする請求項４に記載の情報処理装置。
7. コンピュータが、監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成ステップと、
   前記監視対象システムで障害が発生した際に、前記コンピュータが、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、前記監視対象システム内の障害発生箇所を推定する解析推定ステップとを有し、
   前記推定用構成情報生成ステップにおいて、前記コンピュータは、
   前記複数のシステム構成要素に特定の属性を有するシステム構成要素が含まれるか否かを判断し、
   前記複数のシステム構成要素に前記特定の属性を有するシステム構成要素が含まれる場合に、前記障害発生箇所推定用構成情報を生成することを特徴とする情報処理方法。
8. コンピュータが、監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成ステップと、
   前記監視対象システムで障害が発生した際に、前記コンピュータが、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、アラームを発生させた複数のアラーム発生システム構成要素について、アラーム発生システム構成要素ごとに、前記複数のシステム構成要素のうちの最上位階層のシステム構成要素からアラーム発生システム構成要素までの階層差数を算出し、算出した階層差数に基づき、前記複数のアラーム発生システム構成要素の中から、前記障害を発生させたアラーム発生システム構成要素を推定する解析推定ステップとを有する情報処理方法。
9. 監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成ステップと、
   前記監視対象システムで障害が発生した際に、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、前記監視対象システム内の障害発生箇所を推定する解析推定ステップとをコンピュータに実行させるプログラムであって、
   前記推定用構成情報生成ステップにおいて、前記コンピュータに、
   前記複数のシステム構成要素に特定の属性を有するシステム構成要素が含まれるか否かを判断させ、
   前記複数のシステム構成要素に前記特定の属性を有するシステム構成要素が含まれる場合に、前記障害発生箇所推定用構成情報を生成させることを特徴とするプログラム。
10. 監視対象システムに含まれる複数のシステム構成要素が既定の階層構造で記述される構成情報のコピーにシステム構成要素の追加及び削除の少なくともいずれかを行って、前記既定の階層構造とは異なる障害発生箇所推定用の階層構造で前記監視対象システムのシステム構成を定義する障害発生箇所推定用構成情報を生成する推定用構成情報生成ステップと、
    前記監視対象システムで障害が発生した際に、前記障害発生箇所推定用構成情報で定義されているシステム構成を解析して、アラームを発生させた複数のアラーム発生システム構成要素について、アラーム発生システム構成要素ごとに、前記複数のシステム構成要素のうちの最上位階層のシステム構成要素からアラーム発生システム構成要素までの階層差数を算出し、算出した階層差数に基づき、前記複数のアラーム発生システム構成要素の中から、前記障害を発生させたアラーム発生システム構成要素を推定する解析推定ステップとをコンピュータに実行させることを特徴とするプログラム。

Images