監視方法、監視装置、プログラム
【課題】監視のためのオーバーヘッドを低減し、障害の原因となる要素を明らかにすること。
【解決手段】本発明の監視方法は、監視対象機器の監視項目間の依存関係を保持する保持し、監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択し、選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、監視対象機器から収集し、選択中の監視項目における監視情報に基づいて、監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行い、障害判定の判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と監視項目間の依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する。
【解決手段】本発明の監視方法は、監視対象機器の監視項目間の依存関係を保持する保持し、監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択し、選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、監視対象機器から収集し、選択中の監視項目における監視情報に基づいて、監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行い、障害判定の判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と監視項目間の依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象機器の状態が正常状態もしくは障害状態のいずれであるかを監視する監視方法、監視装置、プログラムに関する。
【背景技術】
【０００２】
サービスを構成する各機器が正常状態であるか否かを監視し、障害を検知した際にユーザに知らせるための技術である、システム監視技術が広く用いられている。
【０００３】
非特許文献１のように、システム監視技術で広く採用されているプロトコルを用いる場合、複数の監視対象機器の監視項目の情報を定期的に収集するポーリング（Polling）という技術が知られている。
【０００４】
しかし、非特許文献１に記載の技術では、監視対象機器、監視項目、収集間隔の逆数に比例して、監視のためのオーバーヘッドが生じてしまうという課題があった。
【０００５】
また、非特許文献２のように、実際のサービスのリクエストを模擬し、その結果を監視することで複数の監視対象機器、監視項目の情報を取得することなく、サービスとして障害が起きているか否かを判断する技術も知られている。
【０００６】
しかし、非特許文献２に記載の技術では、サービス全体が障害であることは検知できるが、サービスを構成するどの要素が障害の原因となっているかは特定することができないという課題があった。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「RFC1157 Simple Network Management Protocol (SNMP)」、［平成２３年４月５日検索］、インターネット＜http://www.potaroo.net/ietf/rfc/rfc1157.txt＞
【非特許文献２】「Apache JMeter」、［平成２３年４月５日検索］、インターネット＜http://jakarta.apache.org/jmeter/＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したように、システム監視技術においては、非特許文献１に記載の技術のように、監視のためのオーバーヘッドが生じるという課題や、非特許文献２に記載の技術のように、障害の原因となる要素を特定できないという課題がある。
【０００９】
本発明は、上記の課題を鑑みてなされたものであり、その目的とするところは、監視のためのオーバーヘッドを削減しつつ、障害が発生した際には障害の原因となる要素がどこに存在するのかを明らかにすることができる監視方法、監視装置、プログラムを提供するところにある。
【課題を解決するための手段】
【００１０】
本発明の監視方法は、
監視装置が行う監視方法であって、
監視対象機器の監視項目間の依存関係を保持する保持ステップと、
前記監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択する選択ステップと、
選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する収集ステップと、
選択中の監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う判定ステップと、
障害判定の判定結果に基づいて選択中の監視項目の状態を確定する確定ステップと、
確定済の監視項目の状態と前記監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する推論ステップと、
全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する出力ステップと、を備えることを特徴とする。
【００１１】
本発明の監視装置は、
監視対象機器の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する監視情報収集手段と、
前記監視項目間の依存関係を保持する監視項目間依存関係保持手段と、
前記監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う障害判定手段と、
前記監視項目の中から状態が未確定の監視項目を順次選択し、選択中の監視項目における監視情報の収集を前記監視情報収集手段に指示すると共に、選択中の監視項目の障害判定を前記障害判定手段に依頼し、その判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と前記監視項目間依存関係保持手段が保持する依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を出力する障害状態推論手段と、
前記障害状態推論手段が出力した障害箇所情報を、二次記憶装置もしくは出力装置に出力する障害箇所出力手段と、を備えることを特徴とする。
【００１２】
本発明のプログラムは、前記監視方法を前記監視装置に実行させるためのプログラムであることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、監視項目間の依存関係を保持しておき、確定済の監視項目の状態と監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する。
【００１４】
そのため、推論により状態を確定した監視項目については、監視情報の収集を省略できるため、監視のためのオーバーヘッドを低減できるという効果が得られる。
【００１５】
また、本発明によれば、障害状態にある監視項目の一覧を示す障害箇所情報を出力するため、障害が発生した際に、障害の原因となる要素がどこに存在するのかを明らかにすることができるという効果が得られる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態の監視装置の構成を示すブロック図である。
【図２】図１に示した障害状態推論手段の動作を説明するフローチャートである。
【図３】図１に示した監視対象機器のモデルの例を示す図である。
【図４】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作の手順を説明する図である。
【図５】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例１を説明する図である。
【図６】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例２を説明する図である。
【図７】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例２を説明する図である。
【発明を実施するための形態】
【００１７】
以下に、本発明を実施するための形態について図面を参照して説明する。
【００１８】
図１に示すように、本実施形態の監視装置２０は、監視対象機器１０の状態が正常状態もしくは障害状態のいずれであるかを監視する。
【００１９】
ここで、本実施形態の監視装置２０は、監視情報収集手段２１と、障害判定手段２２と、監視項目間依存関係保持手段２３と、障害状態推論手段２４と、障害箇所出力手段２５と、を有している。
【００２０】
監視情報収集手段２１は、障害状態推論手段２４から指示された監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を監視対象機器１０から収集し、収集した監視情報を障害状態推論手段２４に出力する。
【００２１】
障害判定手段２２は、障害状態推論手段２４から判定依頼のあった監視項目の状態が正常状態もしくは障害状態のどちらであるのかの障害判定を、障害状態推論手段２４から渡された監視情報を基に行い、その判定結果を障害状態推論手段２４に返却する。
【００２２】
例えば、障害判定手段２２は、監視項目の稼働状態もしくは性能状態から、その監視項目が正常状態もしくは障害状態のどちらであるかを一意に特定できる対応表を保持しており、障害状態推論手段２４から渡された監視情報が示す稼働状態もしくは性能状態と対応表とを照合することで、上記の障害判定を行う。
【００２３】
監視項目間依存関係保持手段２３は、監視項目間の依存関係を保持している。
【００２４】
ここでいう依存関係とは、例えば、アプリケーションはＯＳに依存しており、ＯＳはコンピュータ等のハードウェア（以降ハードウェア）に依存している、といった関係を指す。
【００２５】
また、監視項目間依存関係保持手段２３は、障害状態推論手段２４からの依存関係の問い合わせに対して、保持している依存関係を論理式に変換した依存関係情報を返却する。例えば、アプリケーションはＯＳに依存している、という関係は、「（アプリケーション）→（ＯＳ）」という論理式に変換されて返却される。
【００２６】
また、監視項目間依存関係保持手段２３は、障害状態推論手段２４からの監視項目の問い合わせに対して、依存関係の上位から順に監視項目を返却する。例えば、アプリケーションはＯＳに依存しており、ＯＳはハードウェアに依存している場合、最初の問い合わせに対して（アプリケーション）を返却し、次の問い合わせに対して（ＯＳ）を返却し、次の問い合わせに対して（ハードウェア）を返却する。
【００２７】
障害状態推論手段２４は、図２に示した動作を行う。なお、図２に示した動作は、設定等に応じて定期的に行われる。
【００２８】
まず、ステップＳ１において、監視項目間依存関係保持手段２３に監視項目間の依存関係の問い合わせを行い、依存関係を論理式に変換した依存関係情報を取得する。
【００２９】
次に、ステップＳ２において、依存関係の上位の監視項目から優先的に、状態が未確定の監視項目を選択して取得する。具体的には、最初に、監視項目間依存関係保持手段２３に最上位の監視項目の問い合わせを行い、最上位の監視項目を取得する。取得した監視項目に対応する命題変数が、論理式の中で真もしくは偽で確定されている場合、次位の監視項目を問い合わせる。このステップＳ２の処理を、対応する命題変数が真にも偽にも確定されていない監視項目が取得できるまで繰り返す。状態が未確定の監視項目が取得できた場合はステップＳ３に進み、状態が未確定の監視項目が存在しなかった場合、すなわち、全ての監視項目の状態が確定している場合はステップＳ７に進む。
【００３０】
ステップＳ３においては、ステップＳ２で取得した監視項目における監視情報の収集を監視情報収集手段２１に指示する。
【００３１】
次に、ステップＳ４において、監視情報収集手段２１から監視項目における監視情報を取得し、取得した監視情報を障害判定手段２２に渡して、その監視項目が正常状態もしくは障害状態のどちらであるかの障害判定を依頼する。
【００３２】
次に、ステップＳ５において、障害判定手段２２から受け取った判定結果が障害状態を示す場合は、ステップＳ２で取得した監視項目に対応する命題変数を偽と確定し、正常状態を示す場合は、ステップＳ２で取得した監視項目に対応する命題変数を真と確定する。
【００３３】
次に、ステップＳ６において、ステップＳ１で取得した論理式を推論により簡略化する。すなわち、真偽値が未確定の命題変数のうち、確定済みの命題変数の真偽値（直前のステップＳ５で確定した命題変数の真偽値を含む）を用いることで推論可能となった命題変数の真偽値を推論により確定させる。
【００３４】
その後、ステップＳ２に戻る。
【００３５】
ステップＳ７においては、ステップＳ１で取得した論理式に含まれる命題変数のうち、偽と確定した命題変数に対応する監視項目の一覧を示す障害箇所情報を作成し、障害箇所出力手段２５に出力する。
【００３６】
以上で、障害状態推論手段２４の動作が完了する。
【００３７】
障害箇所出力手段２５は、障害状態推論手段２４から出力された障害箇所情報を、二次記憶装置、または、画面等を表示する出力装置に出力する。
【００３８】
以下、図２に示した障害状態推論手段２４の動作について、具体例を挙げてさらに詳細に説明する。
【００３９】
ここでは、監視対象機器１０が図３に示したモデルであるとする。
【００４０】
図３において、最上位の監視項目はｓｌａであり、ｓｌａの下位の監視項目はｗｅｂ、ａｐ、ｄｂである。また、ｗｅｂの下位の監視項目はｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１、ｐｒｏｃ＿ｗｅｂで、ａｐの下位の監視項目はｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１、ｐｒｏｃ＿ａｐで、ｄｂの下位の監視項目はｃｐｕ＿ｓ２、ｍｅｍ＿ｓ２、ｐｒｏｃ＿ｄｂである。
【００４１】
ここで、ｓｌａは、システム全体のサービスレベルに対応しており、サービスレベルが悪化した場合、もしくはサービスが正常に受けられなくなった場合が障害状態であり、それ以外の場合が正常状態である監視項目である。
【００４２】
ｗｅｂは、Ｗｅｂサーバ単体での動作状況に対応しており、Ｗｅｂサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４３】
ａｐは、ＡＰサーバ単体での動作状況に対応しており、ＡＰサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４４】
ｄｂは、ＤＢサーバ単体での動作状況に対応しており、ＤＢサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４５】
ｃｐｕ＿ｓ１は、サーバ１のＣＰＵ使用率に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４６】
ｃｐｕ＿ｓ２は、サーバ２のＣＰＵ使用率に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４７】
ｍｅｍ＿ｓ１は、サーバ１のメモリ使用量に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４８】
ｍｅｍ＿ｓ２は、サーバ２のメモリ使用量に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４９】
ｐｒｏｃ＿ｗｅｂは、Ｗｅｂサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５０】
ｐｒｏｃ＿ａｐは、ＡＰサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５１】
ｐｒｏｃ＿ｄｂは、ＤＢサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５２】
障害状態推論手段２４は、図３の命題を充足し得る、各監視項目に対応する命題変数の真偽値を確定する。
【００５３】
このとき、障害状態推論手段２４は、分岐限定法を用いて、図４に示すように、監視項目間の依存関係を分岐木として定義し、上位の監視項目から優先的に選択し、選択中の監視項目に対応する命題変数の真偽値を障害判定結果を基に確定し、続いて、選択中の監視項目の下位の監視項目を特定し、確定済みの命題変数の真偽値を基に、特定した下位の監視項目に対応する命題変数の真偽値を推論により確定する。
【００５４】
そして、障害状態推論手段２４は、図３の命題を充足し得る、各監視項目に対応する命題変数の真偽値が全て確定した時点で処理を終了する。ここで、偽と確定された命題変数に対応する監視項目が障害状態となる。
（Ａ）動作例１
図５に示す動作例１は、最上位の監視項目ｓｌａが正常状態である場合の例である。
【００５５】
この場合、まず、ステップＳ１において、監視項目間の依存関係を論理式に変換した依存関係情報を受け取る。
【００５６】
次に、ステップＳ２〜Ｓ５において、最上位の監視項目ｓｌａを選択し、監視項目ｓｌａに対応する命題変数を真（Ｔ）と確定する。
【００５７】
次に、ステップＳ６において、監視項目ｓｌａに対応する命題変数が真（Ｔ）であることに基づいて、ステップＳ１で取得した論理式を推論により簡略化する。
【００５８】
ここでは、全ての監視項目に対応する命題変数を真（Ｔ）と確定することができるため、全ての監視項目が正常状態となる。この場合、ステップＳ７においては、障害箇所情報を出力しなくても良いし、監視項目の記述がない障害箇所情報を出力しても良い。
【００５９】
したがって、監視情報は、監視項目ｓｌａのみ収集すれば良く、監視のためのオーバーヘッドを低減することができる。
（Ｂ）動作例２
図６および図７に示す動作例２は、最上位の監視項目ｓｌａが障害状態であり、その下位の監視項目のうちａｐのみが障害状態である場合の例である。
【００６０】
この場合、まず、ステップＳ１において、監視項目間の依存関係を論理式に変換した依存関係情報を受け取る。
【００６１】
次に、ステップＳ２〜Ｓ５において、最上位の監視項目ｓｌａを選択し、監視項目ｓｌａに対応する命題変数を偽（Ｆ）と確定する。
【００６２】
次に、ステップＳ６において、監視項目ｓｌａに対応する命題変数が偽（Ｆ）であることに基づいて、ステップＳ１で取得した論理式を推論により簡略化する。
【００６３】
以降、監視項目ｗｅｂ、ａｐ、ｄｂを順次選択し、その都度、ステップＳ２〜Ｓ６を実行して、ステップＳ１で取得した論理式を推論により簡略化する。
【００６４】
そして、監視項目ｐｒｏｃ＿ａｐに対応する命題変数を偽（Ｆ）と確定した時点で、全ての監視項目に対応する命題変数が確定する。
【００６５】
ここでは、監視項目ｓｌａ、ａｐ、ｐｒｏｃ＿ａｐが障害状態であるため、ステップＳ７において、これらの監視項目の一覧を示す障害箇所情報を作成し出力する。
【００６６】
したがって、監視情報は、監視項目ｓｌａ、ｗｅｂ、ａｐ、ｄｂ、ｐｒｏｃ＿ａｐのみを収集すれば良く、監視のためのオーバーヘッドを低減することができる。
【００６７】
ここで、動作例２では、監視項目ｓｌａが障害状態であるため、その下位の監視項目のｗｅｂ、ａｐ、ｄｂについては監視情報を収集する。
【００６８】
ただし、監視項目ａｐの下位の監視項目のうちｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１については監視情報の収集を省略できる。これは、本発明において、論理式を推論により簡略化したことの効果によるものである。
【００６９】
上述したように本実施形態においては、監視項目間の依存関係を保持しておき、確定済の監視項目の状態と監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する。
【００７０】
そのため、推論により状態を確定した監視項目については、監視情報の収集を省略できるため、監視のためのオーバーヘッドを低減できるという効果が得られる。
【００７１】
また、本実施形態においては、障害状態にある監視項目の一覧を示す障害箇所情報を出力するため、障害が発生した際に、障害の原因となる要素がどこに存在するのかを明らかにすることができるという効果が得られる。
【００７２】
なお、本発明の監視装置２０にて行われる方法は、コンピュータに実行させるためのプログラムに適用しても良い。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
【符号の説明】
【００７３】
１０ 監視対象機器
２０ 監視装置
２１ 監視情報収集手段
２２ 障害判定手段
２３ 監視項目間依存関係保持手段
２４ 障害状態推論手段
２５ 障害箇所出力手段
【技術分野】
【０００１】
本発明は、監視対象機器の状態が正常状態もしくは障害状態のいずれであるかを監視する監視方法、監視装置、プログラムに関する。
【背景技術】
【０００２】
サービスを構成する各機器が正常状態であるか否かを監視し、障害を検知した際にユーザに知らせるための技術である、システム監視技術が広く用いられている。
【０００３】
非特許文献１のように、システム監視技術で広く採用されているプロトコルを用いる場合、複数の監視対象機器の監視項目の情報を定期的に収集するポーリング（Polling）という技術が知られている。
【０００４】
しかし、非特許文献１に記載の技術では、監視対象機器、監視項目、収集間隔の逆数に比例して、監視のためのオーバーヘッドが生じてしまうという課題があった。
【０００５】
また、非特許文献２のように、実際のサービスのリクエストを模擬し、その結果を監視することで複数の監視対象機器、監視項目の情報を取得することなく、サービスとして障害が起きているか否かを判断する技術も知られている。
【０００６】
しかし、非特許文献２に記載の技術では、サービス全体が障害であることは検知できるが、サービスを構成するどの要素が障害の原因となっているかは特定することができないという課題があった。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「RFC1157 Simple Network Management Protocol (SNMP)」、［平成２３年４月５日検索］、インターネット＜http://www.potaroo.net/ietf/rfc/rfc1157.txt＞
【非特許文献２】「Apache JMeter」、［平成２３年４月５日検索］、インターネット＜http://jakarta.apache.org/jmeter/＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したように、システム監視技術においては、非特許文献１に記載の技術のように、監視のためのオーバーヘッドが生じるという課題や、非特許文献２に記載の技術のように、障害の原因となる要素を特定できないという課題がある。
【０００９】
本発明は、上記の課題を鑑みてなされたものであり、その目的とするところは、監視のためのオーバーヘッドを削減しつつ、障害が発生した際には障害の原因となる要素がどこに存在するのかを明らかにすることができる監視方法、監視装置、プログラムを提供するところにある。
【課題を解決するための手段】
【００１０】
本発明の監視方法は、
監視装置が行う監視方法であって、
監視対象機器の監視項目間の依存関係を保持する保持ステップと、
前記監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択する選択ステップと、
選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する収集ステップと、
選択中の監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う判定ステップと、
障害判定の判定結果に基づいて選択中の監視項目の状態を確定する確定ステップと、
確定済の監視項目の状態と前記監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する推論ステップと、
全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する出力ステップと、を備えることを特徴とする。
【００１１】
本発明の監視装置は、
監視対象機器の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する監視情報収集手段と、
前記監視項目間の依存関係を保持する監視項目間依存関係保持手段と、
前記監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う障害判定手段と、
前記監視項目の中から状態が未確定の監視項目を順次選択し、選択中の監視項目における監視情報の収集を前記監視情報収集手段に指示すると共に、選択中の監視項目の障害判定を前記障害判定手段に依頼し、その判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と前記監視項目間依存関係保持手段が保持する依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を出力する障害状態推論手段と、
前記障害状態推論手段が出力した障害箇所情報を、二次記憶装置もしくは出力装置に出力する障害箇所出力手段と、を備えることを特徴とする。
【００１２】
本発明のプログラムは、前記監視方法を前記監視装置に実行させるためのプログラムであることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、監視項目間の依存関係を保持しておき、確定済の監視項目の状態と監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する。
【００１４】
そのため、推論により状態を確定した監視項目については、監視情報の収集を省略できるため、監視のためのオーバーヘッドを低減できるという効果が得られる。
【００１５】
また、本発明によれば、障害状態にある監視項目の一覧を示す障害箇所情報を出力するため、障害が発生した際に、障害の原因となる要素がどこに存在するのかを明らかにすることができるという効果が得られる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態の監視装置の構成を示すブロック図である。
【図２】図１に示した障害状態推論手段の動作を説明するフローチャートである。
【図３】図１に示した監視対象機器のモデルの例を示す図である。
【図４】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作の手順を説明する図である。
【図５】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例１を説明する図である。
【図６】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例２を説明する図である。
【図７】図３に示した監視対象機器に対する、図１に示した障害状態推論手段の動作例２を説明する図である。
【発明を実施するための形態】
【００１７】
以下に、本発明を実施するための形態について図面を参照して説明する。
【００１８】
図１に示すように、本実施形態の監視装置２０は、監視対象機器１０の状態が正常状態もしくは障害状態のいずれであるかを監視する。
【００１９】
ここで、本実施形態の監視装置２０は、監視情報収集手段２１と、障害判定手段２２と、監視項目間依存関係保持手段２３と、障害状態推論手段２４と、障害箇所出力手段２５と、を有している。
【００２０】
監視情報収集手段２１は、障害状態推論手段２４から指示された監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を監視対象機器１０から収集し、収集した監視情報を障害状態推論手段２４に出力する。
【００２１】
障害判定手段２２は、障害状態推論手段２４から判定依頼のあった監視項目の状態が正常状態もしくは障害状態のどちらであるのかの障害判定を、障害状態推論手段２４から渡された監視情報を基に行い、その判定結果を障害状態推論手段２４に返却する。
【００２２】
例えば、障害判定手段２２は、監視項目の稼働状態もしくは性能状態から、その監視項目が正常状態もしくは障害状態のどちらであるかを一意に特定できる対応表を保持しており、障害状態推論手段２４から渡された監視情報が示す稼働状態もしくは性能状態と対応表とを照合することで、上記の障害判定を行う。
【００２３】
監視項目間依存関係保持手段２３は、監視項目間の依存関係を保持している。
【００２４】
ここでいう依存関係とは、例えば、アプリケーションはＯＳに依存しており、ＯＳはコンピュータ等のハードウェア（以降ハードウェア）に依存している、といった関係を指す。
【００２５】
また、監視項目間依存関係保持手段２３は、障害状態推論手段２４からの依存関係の問い合わせに対して、保持している依存関係を論理式に変換した依存関係情報を返却する。例えば、アプリケーションはＯＳに依存している、という関係は、「（アプリケーション）→（ＯＳ）」という論理式に変換されて返却される。
【００２６】
また、監視項目間依存関係保持手段２３は、障害状態推論手段２４からの監視項目の問い合わせに対して、依存関係の上位から順に監視項目を返却する。例えば、アプリケーションはＯＳに依存しており、ＯＳはハードウェアに依存している場合、最初の問い合わせに対して（アプリケーション）を返却し、次の問い合わせに対して（ＯＳ）を返却し、次の問い合わせに対して（ハードウェア）を返却する。
【００２７】
障害状態推論手段２４は、図２に示した動作を行う。なお、図２に示した動作は、設定等に応じて定期的に行われる。
【００２８】
まず、ステップＳ１において、監視項目間依存関係保持手段２３に監視項目間の依存関係の問い合わせを行い、依存関係を論理式に変換した依存関係情報を取得する。
【００２９】
次に、ステップＳ２において、依存関係の上位の監視項目から優先的に、状態が未確定の監視項目を選択して取得する。具体的には、最初に、監視項目間依存関係保持手段２３に最上位の監視項目の問い合わせを行い、最上位の監視項目を取得する。取得した監視項目に対応する命題変数が、論理式の中で真もしくは偽で確定されている場合、次位の監視項目を問い合わせる。このステップＳ２の処理を、対応する命題変数が真にも偽にも確定されていない監視項目が取得できるまで繰り返す。状態が未確定の監視項目が取得できた場合はステップＳ３に進み、状態が未確定の監視項目が存在しなかった場合、すなわち、全ての監視項目の状態が確定している場合はステップＳ７に進む。
【００３０】
ステップＳ３においては、ステップＳ２で取得した監視項目における監視情報の収集を監視情報収集手段２１に指示する。
【００３１】
次に、ステップＳ４において、監視情報収集手段２１から監視項目における監視情報を取得し、取得した監視情報を障害判定手段２２に渡して、その監視項目が正常状態もしくは障害状態のどちらであるかの障害判定を依頼する。
【００３２】
次に、ステップＳ５において、障害判定手段２２から受け取った判定結果が障害状態を示す場合は、ステップＳ２で取得した監視項目に対応する命題変数を偽と確定し、正常状態を示す場合は、ステップＳ２で取得した監視項目に対応する命題変数を真と確定する。
【００３３】
次に、ステップＳ６において、ステップＳ１で取得した論理式を推論により簡略化する。すなわち、真偽値が未確定の命題変数のうち、確定済みの命題変数の真偽値（直前のステップＳ５で確定した命題変数の真偽値を含む）を用いることで推論可能となった命題変数の真偽値を推論により確定させる。
【００３４】
その後、ステップＳ２に戻る。
【００３５】
ステップＳ７においては、ステップＳ１で取得した論理式に含まれる命題変数のうち、偽と確定した命題変数に対応する監視項目の一覧を示す障害箇所情報を作成し、障害箇所出力手段２５に出力する。
【００３６】
以上で、障害状態推論手段２４の動作が完了する。
【００３７】
障害箇所出力手段２５は、障害状態推論手段２４から出力された障害箇所情報を、二次記憶装置、または、画面等を表示する出力装置に出力する。
【００３８】
以下、図２に示した障害状態推論手段２４の動作について、具体例を挙げてさらに詳細に説明する。
【００３９】
ここでは、監視対象機器１０が図３に示したモデルであるとする。
【００４０】
図３において、最上位の監視項目はｓｌａであり、ｓｌａの下位の監視項目はｗｅｂ、ａｐ、ｄｂである。また、ｗｅｂの下位の監視項目はｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１、ｐｒｏｃ＿ｗｅｂで、ａｐの下位の監視項目はｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１、ｐｒｏｃ＿ａｐで、ｄｂの下位の監視項目はｃｐｕ＿ｓ２、ｍｅｍ＿ｓ２、ｐｒｏｃ＿ｄｂである。
【００４１】
ここで、ｓｌａは、システム全体のサービスレベルに対応しており、サービスレベルが悪化した場合、もしくはサービスが正常に受けられなくなった場合が障害状態であり、それ以外の場合が正常状態である監視項目である。
【００４２】
ｗｅｂは、Ｗｅｂサーバ単体での動作状況に対応しており、Ｗｅｂサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４３】
ａｐは、ＡＰサーバ単体での動作状況に対応しており、ＡＰサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４４】
ｄｂは、ＤＢサーバ単体での動作状況に対応しており、ＤＢサーバ単体で正常に応答が返せない状態のとき障害状態、そうでない場合は正常状態となる監視項目である。
【００４５】
ｃｐｕ＿ｓ１は、サーバ１のＣＰＵ使用率に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４６】
ｃｐｕ＿ｓ２は、サーバ２のＣＰＵ使用率に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４７】
ｍｅｍ＿ｓ１は、サーバ１のメモリ使用量に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４８】
ｍｅｍ＿ｓ２は、サーバ２のメモリ使用量に対応しており、一定のしきい値を超えた場合に障害状態、そうでない場合は正常状態となる監視項目である。
【００４９】
ｐｒｏｃ＿ｗｅｂは、Ｗｅｂサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５０】
ｐｒｏｃ＿ａｐは、ＡＰサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５１】
ｐｒｏｃ＿ｄｂは、ＤＢサーバのプロセス状態に対応しており、プロセスが停止している場合に障害状態、プロセスが動作している場合に正常状態となる監視項目である。
【００５２】
障害状態推論手段２４は、図３の命題を充足し得る、各監視項目に対応する命題変数の真偽値を確定する。
【００５３】
このとき、障害状態推論手段２４は、分岐限定法を用いて、図４に示すように、監視項目間の依存関係を分岐木として定義し、上位の監視項目から優先的に選択し、選択中の監視項目に対応する命題変数の真偽値を障害判定結果を基に確定し、続いて、選択中の監視項目の下位の監視項目を特定し、確定済みの命題変数の真偽値を基に、特定した下位の監視項目に対応する命題変数の真偽値を推論により確定する。
【００５４】
そして、障害状態推論手段２４は、図３の命題を充足し得る、各監視項目に対応する命題変数の真偽値が全て確定した時点で処理を終了する。ここで、偽と確定された命題変数に対応する監視項目が障害状態となる。
（Ａ）動作例１
図５に示す動作例１は、最上位の監視項目ｓｌａが正常状態である場合の例である。
【００５５】
この場合、まず、ステップＳ１において、監視項目間の依存関係を論理式に変換した依存関係情報を受け取る。
【００５６】
次に、ステップＳ２〜Ｓ５において、最上位の監視項目ｓｌａを選択し、監視項目ｓｌａに対応する命題変数を真（Ｔ）と確定する。
【００５７】
次に、ステップＳ６において、監視項目ｓｌａに対応する命題変数が真（Ｔ）であることに基づいて、ステップＳ１で取得した論理式を推論により簡略化する。
【００５８】
ここでは、全ての監視項目に対応する命題変数を真（Ｔ）と確定することができるため、全ての監視項目が正常状態となる。この場合、ステップＳ７においては、障害箇所情報を出力しなくても良いし、監視項目の記述がない障害箇所情報を出力しても良い。
【００５９】
したがって、監視情報は、監視項目ｓｌａのみ収集すれば良く、監視のためのオーバーヘッドを低減することができる。
（Ｂ）動作例２
図６および図７に示す動作例２は、最上位の監視項目ｓｌａが障害状態であり、その下位の監視項目のうちａｐのみが障害状態である場合の例である。
【００６０】
この場合、まず、ステップＳ１において、監視項目間の依存関係を論理式に変換した依存関係情報を受け取る。
【００６１】
次に、ステップＳ２〜Ｓ５において、最上位の監視項目ｓｌａを選択し、監視項目ｓｌａに対応する命題変数を偽（Ｆ）と確定する。
【００６２】
次に、ステップＳ６において、監視項目ｓｌａに対応する命題変数が偽（Ｆ）であることに基づいて、ステップＳ１で取得した論理式を推論により簡略化する。
【００６３】
以降、監視項目ｗｅｂ、ａｐ、ｄｂを順次選択し、その都度、ステップＳ２〜Ｓ６を実行して、ステップＳ１で取得した論理式を推論により簡略化する。
【００６４】
そして、監視項目ｐｒｏｃ＿ａｐに対応する命題変数を偽（Ｆ）と確定した時点で、全ての監視項目に対応する命題変数が確定する。
【００６５】
ここでは、監視項目ｓｌａ、ａｐ、ｐｒｏｃ＿ａｐが障害状態であるため、ステップＳ７において、これらの監視項目の一覧を示す障害箇所情報を作成し出力する。
【００６６】
したがって、監視情報は、監視項目ｓｌａ、ｗｅｂ、ａｐ、ｄｂ、ｐｒｏｃ＿ａｐのみを収集すれば良く、監視のためのオーバーヘッドを低減することができる。
【００６７】
ここで、動作例２では、監視項目ｓｌａが障害状態であるため、その下位の監視項目のｗｅｂ、ａｐ、ｄｂについては監視情報を収集する。
【００６８】
ただし、監視項目ａｐの下位の監視項目のうちｃｐｕ＿ｓ１、ｍｅｍ＿ｓ１については監視情報の収集を省略できる。これは、本発明において、論理式を推論により簡略化したことの効果によるものである。
【００６９】
上述したように本実施形態においては、監視項目間の依存関係を保持しておき、確定済の監視項目の状態と監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する。
【００７０】
そのため、推論により状態を確定した監視項目については、監視情報の収集を省略できるため、監視のためのオーバーヘッドを低減できるという効果が得られる。
【００７１】
また、本実施形態においては、障害状態にある監視項目の一覧を示す障害箇所情報を出力するため、障害が発生した際に、障害の原因となる要素がどこに存在するのかを明らかにすることができるという効果が得られる。
【００７２】
なお、本発明の監視装置２０にて行われる方法は、コンピュータに実行させるためのプログラムに適用しても良い。また、そのプログラムを記憶媒体に格納することも可能であり、ネットワークを介して外部に提供することも可能である。
【符号の説明】
【００７３】
１０ 監視対象機器
２０ 監視装置
２１ 監視情報収集手段
２２ 障害判定手段
２３ 監視項目間依存関係保持手段
２４ 障害状態推論手段
２５ 障害箇所出力手段
【特許請求の範囲】
【請求項１】
監視装置が行う監視方法であって、
監視対象機器の監視項目間の依存関係を保持する保持ステップと、
前記監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択する選択ステップと、
選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する収集ステップと、
選択中の監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う判定ステップと、
障害判定の判定結果に基づいて選択中の監視項目の状態を確定する確定ステップと、
確定済の監視項目の状態と前記監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する推論ステップと、
全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する出力ステップと、を備えることを特徴とする監視方法。
【請求項２】
請求項１に記載の監視方法であって、
前記推論ステップでは、前記監視項目間の依存関係に基づいて、選択中の監視項目の下位の監視項目を特定し、確定済の監視項目の状態に基づいて、特定した下位の監視項目の状態を推論により確定することを特徴とする監視方法。
【請求項３】
請求項２に記載の監視方法であって、
前記選択ステップでは、前記監視項目間の依存関係の上位の監視項目から順次選択することを特徴とする監視方法。
【請求項４】
監視対象機器の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する監視情報収集手段と、
前記監視項目間の依存関係を保持する監視項目間依存関係保持手段と、
前記監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う障害判定手段と、
前記監視項目の中から状態が未確定の監視項目を順次選択し、選択中の監視項目における監視情報の収集を前記監視情報収集手段に指示すると共に、選択中の監視項目の障害判定を前記障害判定手段に依頼し、その判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と前記監視項目間依存関係保持手段が保持する依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を出力する障害状態推論手段と、
前記障害状態推論手段が出力した障害箇所情報を、二次記憶装置もしくは出力装置に出力する障害箇所出力手段と、を備えることを特徴とする監視装置。
【請求項５】
請求項４に記載の監視装置であって、
前記障害状態推論手段は、前記監視項目間依存関係保持手段が保持する依存関係に基づいて、選択中の監視項目の下位の監視項目を特定し、確定済の監視項目の状態に基づいて、特定した下位の監視項目の状態を推論により確定することを特徴とする監視装置。
【請求項６】
請求項５に記載の監視装置であって、
前記障害状態推論手段は、前記監視項目間依存関係保持手段が保持する依存関係の上位の監視項目から順次選択することを特徴とする監視装置。
【請求項７】
請求項１から３のいずれか１項に記載の監視方法を前記監視装置に実行させるためのプログラム。
【請求項１】
監視装置が行う監視方法であって、
監視対象機器の監視項目間の依存関係を保持する保持ステップと、
前記監視項目の中から、状態が正常状態もしくは障害状態のどちらであるか未確定の監視項目を順次選択する選択ステップと、
選択中の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する収集ステップと、
選択中の監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う判定ステップと、
障害判定の判定結果に基づいて選択中の監視項目の状態を確定する確定ステップと、
確定済の監視項目の状態と前記監視項目間の依存関係とに基づいて、未確定の監視項目の状態を推論により確定する推論ステップと、
全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を、二次記憶装置もしくは出力装置に出力する出力ステップと、を備えることを特徴とする監視方法。
【請求項２】
請求項１に記載の監視方法であって、
前記推論ステップでは、前記監視項目間の依存関係に基づいて、選択中の監視項目の下位の監視項目を特定し、確定済の監視項目の状態に基づいて、特定した下位の監視項目の状態を推論により確定することを特徴とする監視方法。
【請求項３】
請求項２に記載の監視方法であって、
前記選択ステップでは、前記監視項目間の依存関係の上位の監視項目から順次選択することを特徴とする監視方法。
【請求項４】
監視対象機器の監視項目における稼働状態もしくは性能状態のいずれかを示す監視情報を、前記監視対象機器から収集する監視情報収集手段と、
前記監視項目間の依存関係を保持する監視項目間依存関係保持手段と、
前記監視項目における監視情報に基づいて、該監視項目の状態が正常状態もしくは障害状態のどちらであるかの障害判定を行う障害判定手段と、
前記監視項目の中から状態が未確定の監視項目を順次選択し、選択中の監視項目における監視情報の収集を前記監視情報収集手段に指示すると共に、選択中の監視項目の障害判定を前記障害判定手段に依頼し、その判定結果に基づいて選択中の監視項目の状態を確定し、確定済の監視項目の状態と前記監視項目間依存関係保持手段が保持する依存関係とに基づいて未確定の監視項目の状態を推論により確定し、全ての監視項目の状態が確定した場合に、障害状態にある監視項目の一覧を示す障害箇所情報を出力する障害状態推論手段と、
前記障害状態推論手段が出力した障害箇所情報を、二次記憶装置もしくは出力装置に出力する障害箇所出力手段と、を備えることを特徴とする監視装置。
【請求項５】
請求項４に記載の監視装置であって、
前記障害状態推論手段は、前記監視項目間依存関係保持手段が保持する依存関係に基づいて、選択中の監視項目の下位の監視項目を特定し、確定済の監視項目の状態に基づいて、特定した下位の監視項目の状態を推論により確定することを特徴とする監視装置。
【請求項６】
請求項５に記載の監視装置であって、
前記障害状態推論手段は、前記監視項目間依存関係保持手段が保持する依存関係の上位の監視項目から順次選択することを特徴とする監視装置。
【請求項７】
請求項１から３のいずれか１項に記載の監視方法を前記監視装置に実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−２４４２２８（Ｐ２０１２−２４４２２８Ａ）
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願番号】特願２０１１−１０９４２１（Ｐ２０１１−１０９４２１）
【出願日】平成２３年５月１６日（２０１１．５．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年１２月１０日（２０１２．１２．１０）
【国際特許分類】
【出願日】平成２３年５月１６日（２０１１．５．１６）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]