(57)【要約】  様々な実施形態は、システムエンティティがその一部をなす特定のシステムの全体的な構成の知識を必ずしも要求しないという点でシステムエンティティの因果関係を表現するために使用される因果関係モデルを提供する。この因果関係モデルは、モデルベースのマネージメント技術と関連して使用され、特定のシステムエンティティが他のシステムエンティティと有する関係に関する因果関係の表現を可能にすることができる。これらの他のシステムエンティティは、因果関係が表現されるエンティティと直接的な関係、またはより一般的には間接的な関係を共有するエンティティであり得る。
2009540465.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数のコンピュータ読み取り可能媒体と、
前記１つまたは複数のコンピュータ読み取り可能媒体に具体化された１つまたは複数のマネージメントパックであって、個々のマネージメントパックは、前記マネージメントパックが一部をなすシステムのインスタンスについての具体的な知識を必要としない方法で因果関係を表現する因果関係モデルを備えた１つまたは複数のマネージメントパックと
を備えたことを特徴とするシステム。
【請求項２】
請求項１記載のシステムであって、前記因果関係モデルは、他のマネージメントパックに関する依存関係を宣言することができることを特徴とするシステム。
【請求項３】
請求項１記載のシステムであって、前記マネージメントパックは、前記マネージメントパックに関連する１つまたは複数のエンティティの状態を記述する１つまたは複数の状態マシンを含み、前記因果関係モデルは、前記状態マシンによって開発された状態情報を使用して因果関係処理を行うように構成されたことを特徴とするシステム。
【請求項４】
請求項１記載のシステムであって、前記因果関係モデルは、因果関係をＸＭＬで表現したことを特徴とするシステム。
【請求項５】
請求項１記載のシステムであって、前記因果関係モデルは、クラスモデルに関して因果関係を表現し、前記因果関係モデルは、発見された具象モデルに対して推論することによって因果関係を計算するために使用することができることを特徴とするシステム。
【請求項６】
請求項１記載のシステムであって、前記因果関係モデルは、特定の観察可能な障害に対する複数の異なる理由を表現することができることを特徴とするシステム。
【請求項７】
請求項６記載のシステムであって、少なくとも１つの理由は、因果関係が表現される同じエンティティと関連し得ることを特徴とするシステム。
【請求項８】
請求項６記載のシステムであって、少なくとも１つの理由は、因果関係が表現されるエンティティとは異なるエンティティと関連し得ることを特徴とするシステム。
【請求項９】
請求項６記載のシステムであって、少なくとも１つの理由は、因果関係が表現されるエンティティとは異なるマネージメントパックの異なるエンティティと関連し得ることを特徴とするシステム。
【請求項１０】
モデル宣言及び前記モデル宣言と関連し、因果関係を計算するために使用することができる因果関係モデルを含むマネージメントパックを提供することと、
前記マネージメントパックにおいて、クラス、関係及びモニターに関して因果関係を表現することと、
を備えることを特徴とする方法。
【請求項１１】
請求項１０記載の方法であって、個々のマネージメントパックは、宣言するクラスの個々のインスタンスに適用するモニタリングポリシーを提供すること特徴とする方法。
【請求項１２】
請求項１０記載の方法であって、前記表現するアクトは、異なるマネージメントパックに関する依存関係を表現することを備えることを特徴とする方法。
【請求項１３】
請求項１０記載の方法であって、モニターは、前記マネージメントパックの一部をなすクラスのインスタンスであるエンティティの特定の状態をモニターする状態マシンであることを特徴とする方法。
【請求項１４】
請求項１０記載の方法であって、前記表現するアクトは、ＸＭＬ表現を用いて因果関係を表現することを備えることを特徴とする方法。
【請求項１５】
請求項１４記載の方法であって、前記表現するアクトは、複数の異なる理由に関して因果関係を表現することができることを特徴とする方法。
【請求項１６】
請求項１５に記載の方法であって、少なくともいくつかの理由は、前記因果関係が表現されるエンティティと関連し得ることを特徴とする方法。
【請求項１７】
請求項１５記載の方法であって、少なくともいくつかの理由は、モデル化された関係に関して１以上のホップとし得るエンティティと関連し得ることを特徴とする方法。
【請求項１８】
請求項１５記載の方法であって、因果関係は、タイプ特有であることを特徴とする方法。
【請求項１９】
請求項１５記載の方法であって、少なくともいくつかの理由は、前記因果関係が表現される前記エンティティと同じクラスとは異なるエンティティと関連し得ることを特徴とする方法。
【請求項２０】
請求項１５記載の方法であって、少なくともいくつかの理由は、因果関係が表現される前記エンティティに関連する前記マネージメントパックとは異なるマネージメントパックとは異なるエンティティと関連し得ることを特徴とする方法。
【発明の詳細な説明】
【背景技術】
【０００１】
今日のネットワーク化された世界におけるシステムは、高度に分散され、相互依存している。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
このことは、（コンピュータデバイス上の特定のコンポーネントなど）単一の根本をなす不具合がネットワークにわたって現実のかつ知覚される多くの不具合を生じ得ることを意味する。このことをさらに複雑にしているのは、どの時点においても、可視性の問題から生じる多くの未知のコンポーネント状態に加えて、システムにアクティブな多くの現実の問題も存在し得るという概念である。
【課題を解決するための手段】
【０００３】
様々な実施形態は、モデルベースのマネージメントシステムのコンテキストにおいて採用されている。少なくともいくつかの実施形態において、因果関係モデル（causality model）は、システムエンティティ（system entity）がその一部をなす特定のシステムの全体的な構成の知識を必ずしも要求しないという点でシステムエンティティの因果関係を表現するために使用される。因果関係モデルは、特定のシステムエンティティが他のシステムエンティティとの間で有する関係に関して因果関係の表現を可能にすることができる。これらの他のシステムエンティティは、因果関係が表現されるエンティティと直接的な関係、またはより一般的には間接的な関係を共有するエンティティであり得る。
【０００４】
さらに、少なくともいくつかの実施形態において、因果関係表現は、因果関係データを分析するために使用され得る根本原因分析アルゴリズムから、ある意味、切り離されている。それ故、知識があり、特定のシステムについてそのような因果関係表現を構築する者は、因果関係分析を行うために使用されることになる分析アルゴリズムを必ずしも知っている必要はない。そのため論理的には、これにより様々な異なるタイプの根本原因分析アルゴリズムに因果関係モデルによって開発されたデータを消費させることができる。
【発明を実施するための最良の形態】
【０００５】
概要
様々な実施形態は、モデルベースのマネージメントシステムのコンテキストにおいて採用されている。少なくともいくつかの実施形態において、因果関係モデルは、システムエンティティがその一部をなす特定のシステムの全体的な構成の知識を必ずしも要求しないという点でシステムエンティティの因果関係を表現するために使用される。因果関係モデルは、特定のシステムエンティティが他のシステムエンティティとの間で有する関係に関して因果関係の表現を可能にすることができる。これらの他のシステムエンティティは、因果関係が表現されるエンティティと直接的な関係、またはより一般的には間接的な関係を共有するエンティティであり得る。
【０００６】
さらに、少なくともいくつかの実施形態において、因果関係表現は、因果関係データを分析するために使用され得る根本原因分析アルゴリズムから、ある意味、切り離されている。それ故、知識があり、特定のシステムについてそのような因果関係表現を構築する者は、因果関係分析を行うために使用されることになる分析アルゴリズムを必ずしも知っている必要はない。そのため論理的には、これにより様々な異なるタイプの根本原因分析アルゴリズムに因果関係モデルによって開発されたデータを消費させることができる。
【０００７】
以下の議論において、「モデルベースのマネージメント」と題されたセクションが提供され、本発明の実施形態を採用することができる１つのタイプのモデルベースのマネージメントの態様について説明する。その後に、「因果関係モデルの実装例」と題されたセクションが提供され、一実施形態による因果関係モデルの態様について説明する。
【０００８】
モデルベースのマネージメント
図１は、本発明の実施形態を使用することができる例示的なシステムを全体的に１００として示している。この例において、システム１００はオペレーションマネージャ１０２及び管理された環境１０４を含む。通常は、オペレーションマネージャ１０２は、ソフトウェアとして具体化され、環境１０４を構成するいくつかの異なるマシンまたはコンピュータデバイスを監督し、管理するように構成されている。
【０００９】
環境１０４は、１つまたは複数のコンピュータデバイスが存在する任意の適当なタイプの環境を含み得る。例えば、このような環境は、高度に分散され、相互依存し得るイントラネットのようなネットワーク化された環境を含み得る。
【００１０】
図示され、説明された実施例において、オペレーションマネージャ１０２はモデルベースのマネージメントシステムを用いて、環境１０４を管理し、監督する。任意の適当なタイプのモデルベースの管理システムは、後述されている１つの具体的であるが限定的でない例と共に使用され得る。以下で明らかになるように、本発明のモデルベースのマネージメントシステムは、人が管理された環境にわたって因果関係を表現できるように設計された因果関係モデルを利用する。因果関係表現に使用されるアプローチは、堅牢で柔軟であり、システムの特定のインスタンス化について知っていることを必ずしも要求とせずに、精通した技術者がシステムにわたって因果関係を表現することを可能にすることができる。
【００１１】
図２は、オペレーションマネージャ１０２の具体的なインスタンスを含むシステムを全体的に２００として示している。ここで、このオペレーションマネージャは、コンピューティングデバイス１０２ａ及び記憶装置１０２ｂを含むか、さもなければ利用するように示されている。この特定の例において、オペレーションマネージャ１０２は、そのモデルベースのマネージメント活動のために使用されるコンポーネントを個々に含む１つまたは複数のマネージメントパック２０２を受信したり、インポートしたりすることができる。この特定の例において、個別のマネージメントパック群は、例示であって限定するものではないが、サーバ、クライアント及び／またはこれらのシステムのサブコンポーネント、分散型のディレクトリ構成、分散型のファイル複製（replication）サービス、バックアップサービス並びにネットワークアクセスプロテクションサービスなどの様々な上位レベルのサービスのような任意のタイプのシステムのために設計することができる。言うまでもなく、当業者には明らかなように、マネージメントパックを設計することができるシステムの数及びタイプは、単純にリストするには多すぎる。実際、マネージメントパックは、他の第三者によって設計されたマネージメントパックの具体的なインスタンス化について必ずしも知らないかもしれない様々な第三者によって設計することができる。
【００１２】
図示された例において、個別のマネージメントパック２０４が図示され、モデル宣言（declaration）モジュール２０６、ディスカバリルールモジュール２０８、ポリシーモニタリング（monitoring policy）モジュール２１０及び因果関係モデルモジュール２１２を含み、各々は以下で説明される。
【００１３】
モデル宣言モジュール２０６は、マネージメントパックのコンポーネントをそれらのプロパティとともに記述し、如何にそれらが関連しているかを記述する抽象化、すなわち抽象モデルを表している。以下の議論において、モデル宣言によって記述されるマネージメントパックの個別のコンポーネントは、「オブジェクト」と考えることができ、それらのオブジェクトの個別のインスタンスは、「エンティティ」と称される。例えば、マネージメントパックは、フロントエンド「Ｆ」オブジェクト、１つまたは複数のビジネスロジックレイヤ「Ｂ」オブジェクト及び保存オブジェクトを記述するかもしれない。
【００１４】
ディスカバリルールモジュール２０８は、宣言されたモデルをどのように「有形化（tangibilize）」し、個別のエンティティを有する具象モデル（concrete model）を生成するかの命令を含む。具体的には、このディスカバリルールモジュールは、特定の物理的環境においてどのようにエンティティを見つけるか、及びこれらのエンティティが他のエンティティと有する関係を記述する。この具体的な例において、抽象モデルからのフロントエンド「Ｆ」は、第１のビジネスロジックレイヤＢ１と通信する特定の記述されたマシン上のウェブサイト「ＷＳ」から成ることができる。他のビジネスロジックレイヤＢ２は、第１ビジネスロジックレイヤと通信することができ、各ビジネスロジックレイヤは、図示したように２つの異なる記憶装置の各々と通信することができる。
【００１５】
モニタリングポリシーモジュール２１０は「ヘルスモデル（health model）」として知られているもの、及び知識ルールを提供する。この知識ルールは、モデル宣言から作成された具象モデルの構成要素である個々のエンティティの状態及び様々な状態間の遷移を記述する状態マシンを本質的に提供している。この例において、ウェブサイト及びビジネスロジックエンティティは各々、当業者には認識されるように、各エンティティが想定し得る状態、及び様々な状態間の遷移を生じるイベントを表す状態マシンを含んでいる。モニタリングポリシーモジュール、関連するヘルスモデル及びその知識ルールを使用して、例えばあるエンティティが望ましくないか、障害の状態に入ると、具象モデルの構成要素エンティティの状態をいつでも計算することができ、適当な通知を生成することができる。
【００１６】
因果関係モデルモジュール２１２、または単純に「因果関係モデル」は、モニタリングポリシー及びディスカバリルール（及びそのエンティティ間の関係の表現）を利用して、マネージメントパックの特定のシステムにわたる因果関係を表現する。因果関係の表現は、現在マネージメントパックの一部であるエンティティだけではなく、異なるマネージメントパックの一部であるエンティティも含み得る。因果関係をこのように表現することによって、根本原因分析エンジンまたは相関エンジンは、特定の障害の根本原因の発見を（問題の障害が異なるマネージメントパック内のエンティティによって生じたときでも）容易にするように因果関係モデルによって生成されたデータにアクセスし、利用できるように設計される。
【００１７】
図２の例において、ビジネスロジックレイヤＢ１が、記億装置の１つにおけるグルーミング（grooming）状態によって生じ得るクリティカル状態を有する場合、ルールまたは因果関係表現は、ビジネスロジックレイヤＢ１がその状態に入ると、１つの理由が特定の記憶装置のグルーミング状態である可能性があるという考えを表現するように設計することができる。従って、特定のマネージメントパック及びそのオブジェクトについての知識がある者は、彼らのマネージメントパックから生じる潜在的な原因だけではなく、他のマネージメントパックから生じる潜在的な原因を記述する因果関係モデルを定式化することができる。
【００１８】
以下の議論において、因果関係モデルの１つの具体的な例が説明される。以下の説明は、特許を請求する主題の応用を、説明される具体的なアプローチに限定することを意図するものでないことが認識され、理解されるべきである。むしろ、他のアプローチを、特許を請求する主題の趣旨及び範囲から逸脱することなく使用することができる。
【００１９】
因果関係モデルの実装例
具体的な因果関係モデルについて説明する前に、因果関係モデルを設計するときに人が直面する以下のチャレンジについて検討する。
【００２０】
第１に、特定の原因は、観察されている兆候から遠く隔たっている可能性がある。例えば、特定の問題の根本原因が他のシステム上にあったり、例えばネットワークやストレージ領域のような別の問題領域さえあるかもしれないことは、当業者によって一般に知られている。しかし、うまくモデル化されたシステムにおいて、原因及び結果（cause and effect）が存在する管理されたエンティティは、何らかの方法で関連している。従って、以下で明らかになるように、本発明の因果関係モデルは、これらの関係を活用して因果関係を表現する。
【００２１】
第２に、因果関係の知識は、具象モデルの不在におけるいくつかのシステム内で定義される傾向がある。すなわち、多くのシステムにおいて、原因及び結果は効果的にシステム内にハードコード化される（hard-coded）。このことは、望ましくない程度の非柔軟性に通じる。本発明のアプローチは、以下で明らかになるように、因果関係モデルをクラスモデルに関して表現することによって、及び発見された具象モデルにわたって推論することで因果関係を計算することによってこの問題を回避する。
【００２２】
さらに、観察可能な障害に対する複数の同時的な原因が通常は存在し得る。すなわち、同じ時に１以上の条件が特定の問題を引き起こす可能性がある。本発明のアプローチは、因果関係分析が１つまたは複数の起こり得る理由に基づいて１つまたは複数の結果を返すことができることを保障することによって、この問題に対処する。
【００２３】
加えて、原因はダイナミックグループ（dynamic group）の１つまたは複数のメンバーに属し得る。例として、以下を考える。負荷バランシング、フェイルオーバー（failover）、冗長（redundancy）及びコンポジション（composition）が採用される多くの状況において、因果関係ロジック、動的に変化し得るグループの１つまたは複数のメンバーを通常は相手にしなくてはならないだろう。本発明のアプローチは、グループをモデル化することによって、及び、例えば「任意の」、「全ての」、「少なくとも」など、集約ロジックを可能にするロールアップアルゴリズムによって表されるエンティティの各々の寄与によってこの状況に対処する。それで、例えば、Ａ点からＢ点までの単一ルート上のネットワークＩＰホップのセットは、「ルート」と呼ばれるグループのメンバーとしてモデル化されるであろう。そして、Ａ点からＢ点の全ての「ルート群」は「ネットワークアクセス」グループのメンバーとしてモデル化されるであろう。
【００２４】
我々は、本質的にＮ二乗問題を有している故、「プロバイダ」機構を利用して、発見されたモデルからこのグループの要求されるインスタンスを動的に表面化させる。例えば、上記の例において、１００のノードを有するネットワーク内では、１０，０００の可能なネットワークアクセスグループがあり、各々が３または４の代替ルートから成り、それらは各４から５のホップから構成される。本発明のアプローチにおいて、我々はこれらの全てを事前に計算し、保存インスタンスとして表わす必要はない。
【００２５】
さらに、他のチャレンジが未知の状態によって引き起こされ得る。特に、いつでも、エージェントからのハートビートが死んでいたり、合成トランザクション（synthetic transaction）がタイムアウトしていたりするなど、いくつかのエンティティの現在のヘルス（current health）にアクセスできないであろうことが予期され得る。因果関係の表現は、部分的なデータにもかかわらず合理的な結果を提供できるべきである。
【００２６】
上記のチャレンジを前提として、以下のコンセプトが、因果関係の知識を定義するための構造を構築する役に立つように利用される。
【００２７】
「管理エンティティ」は、マネージメントパック内のモデルにおいて記述されるエンティティであり、ソフトウェア、ハードウェア及びファームウェアコンポーネントとして存在し得る。
【００２８】
「影響を受けた管理エンティティ（ＩＭＥ）」は、例えばウェブサイトまたはデータベースなど、調査検討中の非正常な状態にある管理エンティティである。
【００２９】
「影響を受けた状態」は、ＩＭＥに関するヘルスモデルにおけるある特定の状態の定義であって、例えば「最初のバイトに対する遅い応答」など、因果関係ロジックが表現されているものである。
【００３０】
「理由」は、影響を受けた状態の原因に関係している。１つの影響を受けた状態を生じる１つまたは複数のタイプの理由を有する可能性があり、各理由は独立して表現され得る。
【００３１】
「プリミティブアサーション」は、ME.State=Constantというタイプである。結果は、真／偽または不明である。例えばプリミティブアサーションは、以下の場合がある。
PrinterX.OnlineState=Offline
または
ClusterY.RollupHealthState=Red
【００３２】
「抽象プリミティブアサーション（ＡＰＡ）」：抽象プリミティブアサーションは、具象インスタンスではなく、クラスモデルに関して表現され、常にＩＭＥをパラメータとして使用して表現される。これは以下のタイプである。
XPath expression(IME).State=Constant
【００３３】
一例は次の通り：IME: Websiteclass.Computer.CPU.Load=Busy
ＩＭＥの所定の状態に対する「理由セット」は、名前付きのＡＰＡのセットである。例として以下を考える。
<ReasonSet>
<Reason>IPConnectivity<Reason/>
<Expression>APA1  <Expression/>（さらに複雑なモデルにおいて、これはブール表現となり得る）
</ReasonSet>
【００３４】
任意の理由の任意のインスタンスはＩＭＥの状態についてそのままにする原因となり得る。
【００３５】
「因果関係結果セット」：稼働しているシステムにおいて、ＩＭＥがある特定の状態にあるとき、因果関係に基づいた分析は、以下のタイプの結果セットを返すであろう。
Reason=ReasonType;RCA ME=MEInstance;State=StateValue;
Confirmed/Guessed;Rollup/Leaf
【００３６】
この結果セットは、ロールアップされた状態からのドリルダウン（drill down）に基づいて同じタイプの行（row）を再帰的に含み得る行を有することができる。メンバーは、XQueryによって返された疑わしい要素に基づくことができる。
【００３７】
RCA ME State自体が他の下流のＭＥがある特定の状態にあるという事実に起因する可能性がある場合にも同じフォーマットが使用される。
【００３８】
実装例
以下の例において、データベース、データベースファイルグループ、データベースファイル及び２つの別個のディスク上の２つのデータファイルにまたがるデータベースの論理ディスクを含むエンティティを有するシステムが使用される。第１に、このシステムが記述され、その後にシステムのクラス、関係及びモニターの表現の記述が続く。これに続いて、データベース上の特定のモニターされた状態の因果関係が、マネージメントパックにおいてどのように表現され得るかの例が提供される。
【００３９】
図３は、データベース３０２、データベースファイルグループ（DB File Group）３０４、２つのデータベースファイル（DB File）３０６及び２つの論理ディスク３０８のエンティティから構成される例示的システム３００を図示している。この例において、データベース３０２はＳＱＬサーバデータベース（SQL Server Database）であるとし、データベース３０２、ＤＢファイルグループ（DBFile Group）３０４及びＤＢファイル（DB File）３０６はＳＱＬサーバマネージメントパック内のクラスのインスタンスであり、そのマネージメントパックにおけるルールに従って発見され、モニターされるとし、論理ディスク３０８は、異なるマネージメントパック、すなわちウィンドウズ（登録商標）サーバマネージメントパック内のクラスのインスタンスであり、そのマネージメントパックにおけるルールに従って発見され、モニターされるとする。
【００４０】
図示され、説明された実施形態において、マネージメントパックは、強く型付けられ、クラスＩＤ及び固有の関係ＩＤを含む。表現された関係も強く型付けられている。
【００４１】
上記の例において、ＳＱＬサーバマネージメントパック及びウィンドウズ（登録商標）サーバマネージメントパックは、それらそれぞれのクラス、関係及びモニターを宣言する。ＳＱＬサーバマネージメントパックは、自身が宣言したクラスのヘルスをモニターする責任を負い、ウィンドウズ（登録商標）サーバマネージメントパックは、自身が宣言したクラスのヘルスをモニターする責任を負う。しかし、特定のクラスのヘルスは、以下で明らかになるように、他のマネージメントパックからのエンティティのヘルスに依存することがある。上記の例におけるマネージメントパック（ＭＰ）の宣言は以下のとおりである。
【００４２】
【表１】
2009540465.tif 000003
【００４３】
ここで、クラス宣言として、４つのクラス宣言がある。最初の３つのクラス宣言は、ＳＱＬサーバマネージメントパック内のクラス、すなわちDatabase、DBFileGroup及びDBFileに関係する。最後のクラス宣言は、他のマネージメントパックからのエンティティ（ウィンドウズ（登録商標）サーバマネージメントパック及びそのロジカルディスククラス）に関係する。
【００４４】
関係宣言は、エンティティが互いに如何に関係しているかを記述する。例えば、データベース（Database）は、ＤＢファイルグループ（DBFileGroup）とホスティング関係を有する（すなわち「DatabaseHostsDBFileGroup」）。同様に、DBFileGroupは、DBFileとホスティング関係を有する（すなわち「DBFileGroupHostsDBFile」）。同様に、DBFileは、LogicalDiskと「生存（lives on）」の関係を有する（すなわち「DBFileLivesOnLogicalDisk」）。
【００４５】
宣言されたモニター群（Monitors）は、それらに関連するエンティティの特定の状態をモニターする状態マシンである。この実施例においては、５つのモニターがあり、そのうちの４つはＳＱＬサーバマネージメントパック内で宣言され、そのうちの１つはウィンドウズ（登録商標）サーバマネージメントパック内で宣言される。
【００４６】
ＳＱＬサーバモニター群に関して、−３つはデータベースクラスについて宣言される−例えばデータベース応答（DBResponce）、バックアップ状態（BackUpState）及びフリースペースの割合（DBPercentFreeSpace）。１つのモニターは、−ファイルグループクラス（DBFileGroupClass）について宣言される−例えばヘルス書込（WriteHealth）。
【００４７】
ウィンドウズ（登録商標）サーバモニター群に関して、１つのモニターは、−ロジカルディスククラス（LogicalDisk）について宣言される−例えばディスクキュー長（DiskQueueLength）。
【００４８】
互いに独立して、各モニターは、それらの特定のクラスに影響を及ぼす態様をモニターする。モニターされた状態は、維持され、オペレーションマネージャ（図１）は、因果関係モデルを通して、特定の問題が存在し得る理由を確かめることができる。
【００４９】
モニターMicrosoft.SQLserver.2005.Database.Database.DBResponseは、データベースの一部で遅い応答に関連した「DBResponseSlow」と呼ばれる動作上の状態を有することをここで検討する。この状態の根本原因は、システム内の他のいくつかのモニターであり得る。例えば、この動作上の状態の原因は、以下の１つまたは複数であり得る。
・BackUpInProgress状態のMicrosoft.SQLServer.2005.Database.BackupStateモニター；
・CriticalSpaceまたはWarningSpace状態のMicrosoft.SQLServer.2005.Database.DBPercentFreeSpaceモニター；
・DiskWriteDegraded状態のMicrosoft.SQLServer.2005.DBFileGroup.WriteHealthモニター；及び／または
・DiskWriteDelayed状態のMicrosoft.Windows（登録商標）.Server.LogicalDisk.DiskQueueLengthモニター。
【００５０】
これらの４つの因果関係群は、スキーマで表現することができ、その例を以下に示す。
【００５１】
【表２】
2009540465.tif 000004
【００５２】
この例において、因果関係表現は、モニターされた動作状態DBResponseSlow状態についてであり、この動作状態について４つの異なった理由（<Reason>タグによって区切られる）を定義している。原因または理由は、「BackupRunning」、「DBLowOnSpace」、「DiskWritePerformance」または「DiskQueueHigh」である可能性がある。表現における最初の２つの理由は、エンティティ自体、すなわちデータベースクラスに関して発生する事象に関連する。その次の理由は、エンティティが依存するDBFileGroupを参照する。従って、ＸＭＬは、関係タイプを横断してDBFileGroupクラスをポイントする。ここで、このクラスに関するモニターは問題を生じるかもしれない。最後の理由は、論理ディスクに関連する。ここで、ＸＭＬは、関係を横断する複数の「ホップ群」を定義して、可能性のある原因に到達する。
【００５３】
ＸＭＬ因果関係表現をもう少し詳細に調べて、以下を検討する。マネージメントパック内のエンティティが固有のＩＤを使用することを思い出そう。このことはネームスペースと多少似ている。上述のＸＭＬ表現において、<Causality>タグは、強く型付けされたクラス、すなわちデータベース、及びモニター、すなわちDBResponseを識別する。加えて、ＸＭＬは、因果関係表現が定義されている状態を識別し、ここでは、Databaseクラスに関するDBResponseSlowの動作状態である。
【００５４】
従って、<Causality>タグは本質的に、因果関係の関係がＸＭＬ表現の下の方で表現されるクラス及びモニターをポイントしている。
【００５５】
いま、上述の説明から明らかなように、特定の障害または問題のある状態についての多くの異なる理由が存在し得る。図示され、説明される実施形態において、各理由（その対応する<Reason>タグ内の）は、理由に関連するＩＤ及びターゲットクラスが付与される。このターゲットクラスは、理由が発せられるエンティティに関係する。さらに、各理由は、因果関係表現の対象である問題または障害の可能性のある原因となるために、モニターが存在すべき状態だけでなく、問題の潜在的原因になり得るクラスとも関連するモニターも参照する。
【００５６】
第１にリストされた理由を例として取り上げる。ここで、DBReponseの状態がDBResponseSlowであることについての１つの可能な理由は、バックアップが稼働していることである可能性がある。バックアップ稼動状態は、Databaseクラスから発し、BackUpStateモニターによってモニターされる。BackUpStateモニターが、「真」とマークされたBackUpInProgressの動作状態を有する場合、この理由はDBResponseの状態がDBResponseSlowであることの潜在的原因としてマークされ得る。BackUpInProgressが「偽」とマークされる場合、この潜在的原因または理由は除外（ruled out）される。
【００５７】
引き続いて、第２にリストされた理由（DBLowOnSpace）は、同じDatabaseクラス上の他のモニターをポイントし、遅いデータベース応答の可能な原因たり得るいずれかの状態を定義する。具体的には、DBPercentFreeSpaceモニターが、「真」とマークされたCriticalSpace状態またはWarningSpace状態のいずれかを有する場合、それぞれマークされた状態はDBResponse状態がDBResponseSlowであることの可能な原因たり得る。
【００５８】
第３にリストされた理由（DiskWritePerformance）は、他のクラス（すなわちDBFileGroupクラス）及びそのクラスに関連したモニター、すなわちWriteHealthをターゲットとしている。ここで、WriteHealthモニターは、「真」としてマークされたDiskWriteDegradedの自身の動作状態を有する場合、このことはDBResponse状態がDBResponseSlowであることの潜在的な原因としてリストされ得る。加えて、この理由が異なるクラスをポイントしているので、これも<Path>タグを用いてこのクラスへのパスを指定する。<Path>タグは、関係のタイプ及びパスの最後のクラスを定義する。この宣言は、この関係のタイプを横断する「ホップ」を効果的に定義し、DBFileGroupの任意のインスタンスが見つけられるべきこと及びそのモニターの指定された状態が調べられるべきことを指定する。
【００５９】
第４にリストされた理由（DiskQueueHigh）の表現は、複数の定義された「ホップ」があることを除いて、第３にリストされた理由と同様である。しかし、これにおいては、異なるマネージメントパックが参照される。具体的には、ターゲットフィールドにおいて、例えば「Windows（登録商標）!」を使用して、宣言がストリング内でさらに指定される異なるマネージメントパック（すなわちウィンドウズ（登録商標）サーバ）に関係することを示す。加えて、モニターは、動作状態または問題の状態に影響し得る状態とともに上述の例のように指定される。この例において、ロジカルディスクのディスクキュー長のモニターが指定され、「DiskWriteDelayed」のその動作状態が「真」とマークされる場合、この理由はDBResponse状態がDBResponseSlowであることの潜在的な原因としてリストされ得る。
【００６０】
加えて、この理由が異なるマネージメントパックに関係するので、<Path>宣言は上述のものとは若干異なる。具体的には、ここで、指定されたタイプ（DatabaseHostsDBFileGroup）の全ての関係のタイプを横断するホップを効果的に定義して、全ての指定されたクラスのインスタンス（DBFileGroup）を効果的に見つけ、そして次の関係のタイプ（DBFileGroupHostsDBFile）を横断するホップを定義して、全てのクラスのインスタンス（DBFile）を見つけ、そして次の関係のタイプ（DBFileLivesOnLogicalDisk）を横断するホップを定義して、指定されたクラス（LogicalDisk）の全てのインスタンスを見つけるネスト化されたパス関係が存在する。
【００６１】
上述の柔軟性のある因果関係表現を使用して、以下のことが非常に容易に成し遂げることができる。第１に、アプリケーションタイプモデルに関して因果関係を宣言的に記述する能力を有することができ、この因果関係モデルは以下のことを成し遂げることができる。この因果関係モデルは、同じエンティティ上の２つの問題を原因結果（cause-effect）としてリンクすることができる。この一例は、上述の最初の２つのリストされた理由において起こる。因果関係モデルは、直接的に関係するエンティティ上で２つの問題を原因結果としてリンクすることができる。この一例は、第３のリストされた理由である。この因果関係モデルは、間接的に関連しているエンティティ上で２つの問題を原因結果としてリンクすることができる。この一例は、上述の第４のリストされた理由である。
【００６２】
加えて、この因果関係モデルは、関係が「包含（containment）」でない場合でも、問題をリンクすることができる。すなわち、関係は「ホスティング」、「クライアントサーバ」、「コピー（copy-of）」または任意の他の考えられ得る関係であり得る。さらに、因果関係モデルは、多くの原因を同じ結果に対してリンクすることができる。このことは、４つの異なる理由が因果関係表現において定義された特定の障害の原因となり得る上述の例において行われている。さらに、この因果関係モデルは、特定のタイプの関係に基づいて問題をリンクすることができる。
【００６３】
加えて、この因果関係モデルは、モデルの構成可能性を利用して因果関係モデルを構成し得る。具体的には、上述の例において、各個々のマネージメントパックは、それ自身のエンティティに関係するそれ自身の特定の因果関係表現を有している。上で見たように、これらの因果関係表現は、異なるマネージメントパック及びこれらのパックによって定義される因果関係モデルを横断して到達でき、従ってそれらを利用することができる。
【００６４】
さらに、本発明の因果関係モデルは、使用される根本原因分析アルゴリズム／エンジンから切り離すことができる。これにより、異なる根本原因分析アルゴリズムまたはエンジンに、この因果関係モデルによって開発された因果関係情報を利用させることができる。根本原因分析アルゴリズムのこのような例の１つは以下で提供される。
【００６５】
動作において、任意の適当なタイプのシステムは、因果関係モデルを利用して任意の適当なタイプの根本原因分析を用いて根本原因分析を行うように設計することができる。このようなシステムの一例として、例示的システムを全体的に４００として図示している図４を考慮されたい。
【００６６】
ここでは、システム４００は、上で説明された環境１０４を管理するオペレーションマネージャ１０２を含む。このオペレーションマネージャは、複数の異なるマネージメントパック２０２を受け取り、処理することができ、その各々は、上で説明された構成要素の部分を含み得る。具体的には、関連するエンティティ及びそれらの互いとの関係を記述するいくつかのタイプのモデル、並びに上で説明したような因果関係モデルである。加えて、相関エンジン４０２が提供され、オペレーションマネージャ１０２と動作可能に結合されている。この例において、オペレーションマネージャ１０２は、相関エンジン４０２によって呼び出されるアプリケーションプログラムインタフェース（ＡＰＩ）を公開して、因果関係モデルを用いて開発されたデータにアクセスする。実際上、相関エンジンは、具象モデル及び状態を読み出し、根本原因を計算し、根本原因をオペレーションマネージャに書き戻す。そして、オペレーションマネージャは、コンソール４０４を用いてトポロジカル（topological）状態ダイアグラムのコンテキストで根本原因を表示する。コンソールを用いて、システム管理者のようなユーザは、根本原因またはユーザのシステムが経験している特定の障害の原因を素早く識別することができる。
【００６７】
相関エンジンに関しては、任意の適当なアルゴリズムを使用して、因果関係モデルによって開発されたデータを分析することができる。このようなアルゴリズムのいくつかの特徴は、例あって限定するものではないが、モデル及び検出された状態に対して推論する能力を含むことができ、管理されたエンティティタイプに関し理由表現（Reason Expressions）のセットを使用して因果関係結果セット（Causality Result Set）を生成することができる。
【００６８】
根本原因分析アルゴリズムが因果関係モデルによって生成されたデータを如何に処理するかについての簡単な例として、以下の計算を考える。以下の説明において、可視性及び構成可能性のような問題は無視する。
【００６９】
あらゆる管理されたエンティティの各状態について、その状態が現在「真」であるかを確認するようにチェックが行われる。現在の状態が「真」でない場合、そのアルゴリズムは終了するかまたは次の状態を処理する。現在の状態が「真」である場合、その状態が「良好」かどうかを確認するように次のチェックが行われる。「良好」である場合、そのアルゴリズムは終了するかまたは次の状態を処理する。
【００７０】
次に、「良好」ではない状態に対しては、その状態に割り当てられた何らかの理由があるかどうかを確認するようにチェックが行われる。割り当てられた理由がない場合、その状態は根本原因としてマークされる。
【００７１】
割り当てられた理由がある場合、その理由は追跡され、その理由のアサーションが少なくとも１つの理由に対して「真」であるかを確認するようにチェックが行われる。理由のいずれかが「真」である場合、調査中の状態は単にどこかの原因の結果であると結論付けることができる。この場合において、因果関係は（矢印のように）適宜マークすることができる。
【００７２】
しかし、理由アサーションのいずれもが「真」でない場合、管理されたエンティティのその態様は根本原因としてマークすることができる。
【００７３】
このことが管理されたエンティティの全てに対して行われたとき、黒円でマークされた根本原因と不良な状態から根本原因へ導く一連の矢印で、全体のトポロジを表示することができる。
【００７４】
いま、もう一つ複雑なレベルのものを考える。いくつかのエンティティ群が構成されたエンティティ群（クラスタなど）であるとする。この場合、上で説明したアルゴリズムを行う前に、ロールアップ状態が計算される。
【００７５】
いま、いくつかの管理されたエンティティが「ブラインド」になったとする、すなわちそれらの状態が不明であるとする。この状況においては、最初に因果関係を逆順に追跡し得る。具体的には、このアルゴリズムは、既知の全ての「結果」状態を見つけることができる。管理されたエンティティのこの態様に対して、このアルゴリズムは、「真」であるべきであるが不明な全ての「理由」を見つけて、任意の真ではない状態をもたらすことができる。全てのこれら不明なものは偽である。すなわち、それらが真である場合、観察可能な状態は違っているであろう。このようにして、上で説明したアルゴリズムを始める前に、最大数の不明なものを除去することができる。
【００７６】
しかし、「非難（blame）」を計算するアルゴリズムは、統計的なアプローチにシフトしている。すなわち、不明なものによってある状態内にあると説明され得る既知の状態が増えるほど、真であるという蓋然性が高くなる。
【００７７】
上述のアルゴリズムにおいて、全ての推論（不明な状態を判定すること、「非難」を判定すること、または「非難」の蓋然性を判定すること）は何の非難の値にも依存しないことに注意すべきである。それは、純粋に現在の状態の値に基づいている。結果として、管理されたエンティティの状態が変化するとき、それは因果関係に基づいてその動揺を通じて外の方へ波及する（ripple）ことができる。言い換えれば、ローカルの計算で足り、すべての関係の組織構造（fabric）を通して計算する必要はない。
【００７８】
結論
上で説明した様々な実施形態は、システムエンティティがその一部をなす特定のシステムの全体的な構成の知識を必ずしも要求しないという点でシステムエンティティの因果関係を表現するために使用される因果関係モデルを提供することができる。モデルベースマネージメント技術に関連して用いられる因果関係モデルは、特定のシステムエンティティが他のシステムエンティティと有する関係に関して因果関係の表現を可能にする。これらの他のシステムエンティティは、因果関係が表現されるエンティティとの直接的な関係、またはより一般的には間接的な関係を共有するエンティティであり得る。少なくともいくつかの実施形態は、因果関係表現を因果関係データを分析するために使用され得る様々な根本原因分析アルゴリズムから分離する。このように、知識があり、特定のシステムのためにこのような因果関係表現を構築する者は、因果関係分析を行うために使用されるべき分析アルゴリズムを知っている必要は必ずしもない。そして論理的には、これにより、異なるタイプの様々な根本原因分析アルゴリズムに因果関係モデルによって開発されたデータを消費させることを可能にする。
【００７９】
本発明は、構造的な特徴及び／または方法ステップに特有な言葉で説明されているが、添付の特許請求の範囲で画定される本発明は、必ずしも説明された特定の特徴またはステップに限定されるものではないと理解されるべきである。むしろ、特定の特徴及びステップは、本願発明を実装する好ましい形態として開示されている。
【図面の簡単な説明】
【００８０】
【図１】一実施形態による本発明の実施形態を使用することができる例示的システムの図である。
【図２】一実施形態によるオペレーションマネージャの特定のインスタンスを含むシステムの図である。
【図３】一実施形態による例示的システムの図である。
【図４】一実施形態による例示的システムの図である。
【図１】
2009540465.tif 000005
【図２】
2009540465.tif 000006
【図３】
2009540465.tif 000007
【図４】
2009540465.tif 000008
【国際調査報告】
2009540465.tif 000009
2009540465.tif 000010