(57)【要約】【課題】  手動で実行した障害回復処理を自動で実行する障害回復処理として取り込むことができるサーバ障害回復方法およびサーバ障害回復システムを提供する。【解決手段】  １台以上設置された被監視サーバ１に障害が発生したとき、前記被監視サーバ１と通信回線を介して接続された監視サーバ２が、障害回復処理を実行するサーバ障害回復方法において、前記被監視サーバ１が自サーバの状態を監視し、障害が発生したとき、前記監視サーバ２へ障害が発生したことを通知し、障害回復処理において使用するテーブルを有する前記監視サーバ２が、前記被監視サーバ１から障害の通知を受けた後、入力による命令を受け付け、前記命令を被監視サーバ１に送信して行う処理を含む所定の障害回復処理を選択し、前記被監視サーバ１に対して障害回復処理を実行し、その実行後に前記テーブルに障害回復処理が行われたことを示す情報を書き込む。【選択図】      図１
2006023910.tif 000002
【特許請求の範囲】
【請求項１】
１台以上設置された被監視サーバに障害が発生したとき、前記被監視サーバと通信回線を介して接続された監視サーバが、障害回復処理を実行し、監視端末がその状況を監視するサーバ障害回復方法において、
前記被監視サーバが自サーバの状態を監視し、障害が発生したとき、前記監視サーバへ障害が発生したことを通知し、
障害回復処理において使用するテーブルを有する前記監視サーバが、前記被監視サーバから障害の通知を受けた後、入力による命令を受け付け、前記命令を被監視サーバに送信して行う処理を含む所定の障害回復処理を選択し、前記被監視サーバに対して障害回復処理を実行し、その実行後に前記テーブルに障害回復処理が行われたことを示す情報を書き込む
ことを特徴とするサーバ障害回復方法。
【請求項２】
前記被監視サーバは、出力する可能性のある障害メッセージおよび障害名称を格納する管理テーブルを有し、障害メッセージの出力有無を常時監視し、障害メッセージが出力されたときに、前記管理テーブルを基に、発生日時と発生サーバ名称と障害名称とを前記監視サーバへ通知する
ことを特徴とする請求項１に記載のサーバ障害回復方法。
【請求項３】
前記監視サーバは、前記障害名称と該当する障害回復処理名称と障害回復処理の成功確率とを格納する障害回復処理管理テーブルと、前記障害回復処理名称と該当する障害回復コマンドとを格納する障害回復コマンドテーブルとを有し、前記被監視サーバからの通知を受けて前記障害回復処理管理テーブルから前記成功確率の高い障害回復処理名称を選定し、該当する障害回復コマンドを前記障害回復コマンドテーブルから選択して順次実行する
ことを特徴とする請求項１または請求項２に記載のサーバ障害回復方法。
【請求項４】
前記監視サーバは、前記障害名称と障害回復処理とを実施した後に成功の可否を確認する結果確認処理と、前記結果確認処理を実施した後に確認した事項を示す確認事項とを格納する結果確認処理管理テーブルを有し、前記監視サーバに障害回復コマンドを全て実行した後、または手動で障害回復処理を実行した後に、前記結果確認処理管理テーブルに格納されている結果確認処理を実行し、前記障害回復処理の成功を判定し、前記結果確認処理を実行後に、該当する障害回復処理の成功確率を計算し、その計算結果を前記障害回復処理管理テーブルへ格納する
ことを特徴とする請求項１ないし請求項３のいずれか１項に記載のサーバ障害回復方法。
【請求項５】
前記監視サーバは、前記被監視サーバに発生した障害の状況を格納する障害履歴管理テーブルを有し、前記被監視サーバからの通知を受けた後、前記障害履歴管理テーブルへ発生日時、発生サーバの名称、および障害名称を前記障害履歴管理テーブルに格納し、障害回復処理名称の検索処理を実行した後、前記障害履歴管理テーブルへ検索結果を格納し、前記結果確認処理を実行した後、前記障害履歴管理テーブルへ実行結果を格納し、
前記監視端末が前記障害履歴管理テーブルを定期的に監視し、前記障害履歴管理テーブルの内容が追加されたときに変更内容を表示する
ことを特徴とする請求項１ないし請求項４のいずれか１項に記載のサーバ障害回復方法。
【請求項６】
１台以上設置された被監視サーバに障害が発生したとき、前記被監視サーバと通信回線を介して接続された監視サーバが、障害回復処理を実行し、その状況を監視端末が監視するサーバ障害回復システムにおいて、
前記被監視サーバは、出力する可能性のある障害メッセージおよび障害名称を格納する管理テーブルを有するとともに、障害メッセージの出力有無を監視する機能と、障害メッセージが出力されたときに、前記管理テーブルを基に、発生日時と発生サーバ名称と障害名称とを監視サーバへ通知する機能とを備え、
前記監視サーバは、障害名称と該当する障害回復処理名称と障害回復処理の成功確率を格納する障害回復処理管理テーブルと、障害回復処理名称と該当する障害回復コマンドを格納する障害回復コマンドテーブルと、障害名称と障害回復処理を実施した後に成功の可否を確認する結果確認処理と、結果確認処理を実施した後の確認事項を示す確認事項とを格納する結果確認処理管理テーブルと、前記被監視サーバに発生した障害の状況を格納する障害履歴管理テーブルとを有するとともに、
被監視サーバからの通知を受けて前記障害回復処理管理テーブルから成功確率の高い障害回復処理名称を選定する機能と、該当する障害回復コマンドを前記障害回復コマンドテーブルより順次実行する機能と、前記監視サーバに障害回復コマンドを全て実行した後、または、手入力を受け付けそれを被監視サーバに送信して行う障害回復処理を実行した後に、前記結果確認処理管理テーブルに格納されている結果確認処理を実行する機能と、障害回復処理の成功を判定する機能と、結果確認処理を実行後に、該当する障害回復処理の成功確率を計算する機能と、計算結果を前記障害回復処理管理テーブルへ格納する機能と、被監視サーバからの通知を受けた後、障害履歴管理テーブルへ発生日時、発生サーバの名称、および障害名称を前記障害履歴管理テーブルに格納する機能と、障害回復処理名称の検索処理を実行した後、障害履歴管理テーブルへ検索結果を格納する機能と、結果確認処理を実行した後、障害履歴管理テーブルへ実行結果を格納する機能とを備え、
前記監視端末は、前記障害履歴管理テーブルを定期的に監視する機能と、前記障害履歴管理テーブルの内容が追加されたときに変更内容を表示する機能とを備えた
ことを特徴とするサーバ障害回復システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、被監視サーバに障害が発生したとき、監視サーバが、自動的に障害回復処理を実行するサーバ障害回復方法およびサーバ障害回復システムに関する。
【背景技術】
【０００２】
従来の一般的なサーバ障害回復システムでは、監視サーバが、被監視サーバの状態を、常時、監視し、障害が発生した場合は、監視サーバを介して障害が発生した被監視サーバを監視端末に表示し、管理者に通知する。そして、管理者は、障害が発生したサーバにおいて出力されている障害のメッセージＩＤから障害の原因を調査し、原因に応じた障害回復処理を行う。このようなシステムでは、障害のメッセージＩＤを確認してから原因を調査するのに時間を要し、障害発生から障害回復までに多くの時間がかかるという問題点があった。また、障害による顧客業務の停止時間を最小限に抑止する必要性があることから、障害の回復作業を優先するあまり、確認作業に十分な時間を割くことができず、誤った障害回復処理の選択や誤ったコマンドの投入などの人為的な誤りも発生しやすいという問題点もあった。
【０００３】
このような問題点を解決する方法として、特許文献１に示すようなシステムを用いた方法が提案されている。このシステムでは、過去に発生したサーバ障害事例の履歴とサーバ障害発生後の履歴を比較することにより、最も類似している障害事例を選定し、適切なサーバ障害回復処理を選択する。具体的には、過去に発生したサーバ障害事例の履歴と、現在のサーバ障害を含む履歴とを比較し、メッセージＩＤの一致した数を示す履歴確信度と、ハードウェア、ソフトウェアおよび監視項目の一致した数を示す監視確信度の２点からサーバ障害の原因を解析し、自動もしくは手動にてサーバ障害回復処理を実行している。
【特許文献１】特開平１０−３１２３２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、前記従来のシステムを用いたサーバ障害回復方法には問題点がある。すなわち、入力を受け付け、その命令により実行した障害回復処理を自動で実行する障害回復処理として取り込むことができない点であって、自動で実行した障害回復処理が失敗になった場合もしくは予め障害の回復方法が手動に設定されていた場合は、手動にて障害回復処理を実行する運用になっている。したがって、入力を受け付け、その命令に従って障害回復処理を実行した後、同一の障害が再発した場合にも、同様に障害回復処理を実行する必要がある
【０００５】
本発明は、前記問題点に鑑みてなされたものであり、その目的とするところは、入力を受け付け、その命令により実行した障害回復処理を入力による命令なしで実行する障害回復処理として取り込むことができるサーバ障害回復方法およびサーバ障害回復システムを提供することにある。
【課題を解決するための手段】
【０００６】
本発明は、前記目的を達成するために、１台以上設置された被監視サーバに障害が発生したとき、前記被監視サーバと通信回線を介して接続された監視サーバが、障害回復処理を実行し、監視端末がその状況を監視するサーバ障害回復方法において、前記被監視サーバが自サーバの状態を監視し、障害が発生したとき、前記監視サーバへ障害が発生したことを通知し、障害回復処理において使用するテーブルを有する前記監視サーバが、前記被監視サーバから障害の通知を受けた後、入力による命令を受け付け、前記命令を被監視サーバに送信して行う処理を含む所定の障害回復処理を選択し、前記被監視サーバに対して障害回復処理を実行し、その実行後に前記テーブルに障害回復処理が行われたことを示す情報を書き込むことを特徴とする。これにより、入力を受け付け、その命令に従って障害回復処理を行ったときも、それをテーブルに反映させることができる。
【発明の効果】
【０００７】
このようなサーバ障害回復方法およびサーバ障害回復システムによれば、入力を受け付け、その命令に従って障害回復処理を行ったときも、それがテーブルに反映されるので、入力を受け付け、その命令に従って実行した障害回復処理を自動で実行する障害回復処理として取り込むことができ、後に同じ障害が起きたときに、自動で障害回復処理を行うことが可能になる。
【発明を実施するための最良の形態】
【０００８】
以下に、本発明の一実施形態を図１ないし図７を用いて説明する。
【０００９】
図１は、本発明のサーバ障害回復システムにおけるハードウェアおよびソフトウェアとしてのモジュールの構成を示すブロック構成図である。このサーバ障害回復システムは、被監視サーバ１と、監視サーバ２と、監視端末３から構成される。そして、被監視サーバ１は、メッセージＩＤ管理テーブル１ａおよび障害メッセージ監視モジュール１ｂとから構成される。監視サーバ２は、障害解析モジュール２ａ、結果確認モジュール２ｂ、手動対処モジュール２ｃ、障害回復処理管理テーブル２ｄ、障害回復コマンドテーブル２ｅ、結果確認処理管理テーブル２ｆおよび障害履歴管理テーブル２ｇから構成される。監視端末３は、障害状態通知モジュール３ａから構成される。
【００１０】
図２は、図１における各テーブルのデータ構成の一例である。以下に図２の各テーブルについて説明する。
【００１１】
図２の（ａ）に示すメッセージＩＤ管理テーブルは、図１のメッセージＩＤ管理テーブル１ａのデータ構成例である。「メッセージＩＤ」の欄は、図１の被監視サーバ１から出力されるメッセージを識別するキーとして用いられ、監視対象とする障害のメッセージが被監視サーバ１毎にあらかじめ設定される。「障害名称」の欄は、監視サーバ２へ通知する障害の内容を表し、メッセージＩＤが異なっていても、障害回復処理が同一の場合は、同一の障害名称として管理される。
【００１２】
図２の（ｂ）に示す障害回復処理管理テーブルは、図１の障害回復処理管理テーブル２ｄのデータ構成例である。「発生サーバ」の欄は、障害発生元のサーバを表し、「障害名称」の欄は、障害の名称を表し、「障害回復処理名称」の欄は、図１の監視サーバ２から実行する障害回復処理を識別するためのキーとして用いる。「実行回数」、「成功回数」および「成功確率」の欄では、「障害回復処理名称」がキーとして格納されており、「実行回数」の欄には、該当する障害回復処理を手動もしくは自動で実行した回数が格納され、「成功回数」の欄には、該当する障害回復処理を手動もしくは自動で実行して成功した回数が格納される。「成功確率」の欄には、前記の「実行回数」と「成功回数」とに基づき算出された障害回復処理の成功確率が格納される。
【００１３】
図２の（ｃ）に示す障害回復コマンドテーブルは、図１の障害回復コマンドテーブル２ｅのデータ構成例である。「障害回復コマンド」の欄には、障害回復処理を実行する上で必要となるコマンドが格納され、１つの「障害回復処理名称」に対して、１つ以上の「障害回復コマンド」が存在する。
【００１４】
図２の（ｄ）に示す結果確認処理管理テーブルは、図１の結果確認処理管理テーブル２ｆのデータ構成例である。「結果確認処理」および「確認事項」の欄は、「発生サーバ」と「障害名称」がキーとして格納されており、「結果確認処理」の欄には、手動もしくは自動で障害回復処理を実行後に、実行した障害回復処理の成功可否を確認するための処理が格納され、「確認事項」の欄には、結果確認処理を実施した後の確認事項が格納される。
【００１５】
図２の（ｅ）に示す障害履歴管理テーブルは、図１の障害履歴管理テーブル２ｇのデータ構成例である。「発生日時」の欄には、被監視サーバ１にてメッセージが出力された時刻が格納される。「検索結果」および「実行結果」の欄では、「発生日時」、「発生サーバ」および「障害名称」がキーとして格納されており、「検索結果」の欄には、監視サーバ２が障害回復処理管理テーブル２ｄの「障害回復処理名称」を検索した結果が格納され、「実行結果」の欄には、監視サーバ２が結果確認処理管理テーブル２ｆの「結果確認処理」を実行した結果が格納される。
【００１６】
続いて、各モジュールについて説明する。
【００１７】
障害メッセージ監視モジュール１ｂは、被監視サーバ１の状態を、常時、監視しており、メッセージＩＤ管理テーブル１ａに定義されている障害のメッセージＩＤが出力されたとき、監視サーバ２へ障害を通知する。
【００１８】
障害解析モジュール２ａは、被監視サーバ１から障害の通知を受けた後、障害名称を障害履歴管理テーブル２ｇへ書き込む。そして、障害回復処理管理テーブル２ｄから最も成功確率の高い障害回復処理名称を選定し、障害回復コマンド管理テーブル２ｅに記録されている障害回復コマンドを、順次、実行する。
【００１９】
結果確認モジュール２ｂは、結果確認処理管理テーブル２ｆに記録されている結果確認処理を実行し、障害回復処理の成功可否を判定する。そして、結果確認処理を実行後、実行した障害回復処理の成功確率を再計算し、障害回復処理管理テーブル２ｄへ格納する。
【００２０】
手動対処モジュール２ｃは、入力を受け付け、その命令に従って障害回復処理を実行した後、障害回復処理管理テーブル２ｄと障害回復コマンドテーブル２ｅへ障害回復処理名称を追加し、障害回復コマンドを格納する。
【００２１】
障害状態通知モジュール３ａは、障害履歴管理テーブル２ｇの状態を、常時、監視しており、障害履歴管理テーブル２ｇに履歴が追加された場合に、変更内容を監視端末３において出力する。
【００２２】
次に、図３ないし図７のフローチャートに基づいて、本発明のサーバ障害回復システムの備える各モジュールの処理動作を説明する。各モジュールの処理動作は、サーバ障害回復プログラムを起動することにより実現される。また、サーバ障害回復プログラムは記録媒体に記録することにより利用可能である。
【００２３】
まず、図３を参照して、被監視サーバ１の障害メッセージ監視モジュール１ｂの起動から終了までの動作を説明する。
【００２４】
サーバ障害回復システムが終了か否かで処理を分岐する（ステップＳ１０）。終了でない場合は（ステップｓ１０のNO）、メッセージＩＤ管理テーブル１ａに格納されている「メッセージＩＤ」が、被監視サーバ１から出力されているかを監視する(ステップＳ１１)。終了の場合は（ステップＳ１０のYES）処理を終わる。「メッセージＩＤ」が出力されていれば（ステップＳ１２のYES）、メッセージＩＤ管理テーブル１ａから該当する「障害名称」を検索する（ステップＳ１３）。メッセージＩＤ管理テーブル１ａに格納されていない「メッセージＩＤ」が出力された場合は（ステップＳ１２のNO）、「障害名称」の検索を行わない。次に、監視サーバ２へ「発生日時」と「発生サーバ」と「障害名称」を通知し（ステップＳ１４）、監視サーバ２の障害解析モジュール２ａへ処理を移す（ステップＳ１５）。
【００２５】
次に、図４を参照して、監視サーバ２の障害解析モジュール２ａの起動から終了までの動作を説明する。
【００２６】
監視サーバ２（障害解析モジュール２ａ）はステップＳ１４により、障害メッセージ監視モジュール１ｂからの通知を受信すると（ステップＳ２０）、障害履歴管理テーブル２ｇに障害の「発生日時」と「発生サーバ」と「障害名称」を格納する（ステップＳ２１）。次に、障害回復処理管理テーブル２ｄを検索し、発生した「障害名称」に対応する「障害回復処理名称」が格納されている場合は（ステップＳ２２のYES）、障害履歴管理テーブル２ｇの「検索結果」の欄にYESを書き込む（ステップＳ２３）。そして、障害回復処理管理テーブル２ｄに格納されている「障害回復処理名称」から最も成功確率の高い障害回復処理名称を選択し(ステップＳ２４)、障害回復コマンドテーブル２ｅに格納されている「障害回復コマンド」を実行する（ステップＳ２５）。障害回復処理管理テーブル２ｄにおいて、実行した「障害回復処理名称」の「実行回数」に１を加算し（ステップＳ２６）、結果確認モジュール２ｂへ処理を移す（ステップＳ２７）。一方で、発生した「障害名称」に対応する「障害回復処理名称」が格納されていなかった場合は（ステップＳ２２のNO）、障害履歴管理テーブル２ｇの「検索結果」の欄にNOを書き込み（ステップＳ２８）、手動対処モジュール２ｃへ処理を移す（ステップＳ２９）。
【００２７】
次に、図５を参照して、監視サーバ２の結果確認モジュール２ｂの起動から終了までの動作を説明する。
【００２８】
まず、結果確認処理管理テーブル２ｆから、発生した「障害名称」に対応する「結果確認処理」を実行し(ステップＳ３０)、「結果確認処理」の実行結果が結果確認処理管理テーブル２ｆに格納されている「確認事項」と等しいか判定する（ステップＳ３１）。「確認事項」と等しい場合は（ステップＳ３１のYES）、障害履歴管理テーブル２ｇの「実行結果」の欄にYESを書き込み（ステップＳ３２）、障害回復処理管理テーブル２ｄの該当する「障害回復処理名称」の「成功回数」に１を加算する（ステップＳ３３）。次に、障害回復処理管理テーブル２ｄにおいて、実行した「障害回復処理名称」の「実行回数」と「成功回数」とから「成功確率」を算出し（ステップＳ３４）、障害回復処理管理テーブル２ｄの「成功確率」へ格納する（ステップＳ３５）。最後に、障害履歴管理テーブル２ｇから、該当する「発生日時」、「発生サーバ」、「障害名称」、「検索結果」および「実行結果」をクリアする（ステップＳ３６）。一方で、「確認事項」と等しくなかった場合は（ステップＳ３１のNO）、障害履歴管理テーブル２ｇの「実行結果」の欄にNOを書き込み（ステップＳ３７）、障害回復処理管理テーブル２ｄにおいて、実行した「障害回復処理名称」の「実行回数」と「成功回数」とから「成功確率」を算出し（ステップＳ３８）、障害回復処理管理テーブル２ｄの「成功確率」へ格納する（ステップＳ３９）。最後に、障害履歴管理テーブル２ｇから、該当する「実行結果」をクリアし（ステップＳ３Ａ）、手動対処モジュール２ｃへ処理を移す（ステップＳ３Ｂ）。
【００２９】
次に、図６を参照して、監視サーバ２の手動対処モジュール２ｃの起動から終了までの動作を説明する。
【００３０】
まず、障害回復コマンドテーブル２ｅへ「障害回復処理名称」を追加し（ステップＳ４０）、入力を受け付け、それを被監視サーバ１に送信して、障害回復処理を実行する（ステップＳ４１）。次に、障害回復コマンドテーブル２ｅにおいて、前記のように実行した障害回復処理である追加された「障害回復処理名称」に対して、「障害回復コマンド」を格納する（ステップＳ４２）。最後に、障害回復処理管理テーブル２ｄに対して、障害回復コマンドテーブル２ｅへ追加した「障害回復処理名称」を追加し（ステップＳ４３）、「実行回数」に１を加算した後（ステップＳ４４）、結果確認モジュール１３へ処理を移す（ステップＳ４５）。
【００３１】
最後に、図７を参照して、監視端末３の障害状態通知モジュール３ａの起動から終了までの動作を説明する。
【００３２】
サーバ障害回復システムが終了するまで処理を行う（ステップＳ５０）。終了の場合は、（ステップＳ５０のYES）処理を終わる。終了でない場合は（ステップＳ５０のNO）、図１の監視サーバ２にある障害履歴管理テーブル２ｇの「発生日時」と「発生サーバ」と「障害名称」を参照し、前回、参照した状態と比較して、前記の３項目が追加されていれば（ステップＳ５１のYES）、「発生日時」と「発生サーバ」と「障害名称」を管理者に通知する（ステップＳ５２）。一方で、前記の３項目が追加されていない場合は（ステップＳ５１のNO）、図１の障害履歴管理テーブル２ｇの「検索結果」を参照し、前回、参照した状態と比較して、「検索結果」の欄が追加されているかを判定する（ステップＳ５３）。「検索結果」の欄が追加されている場合は（ステップＳ５３のYES）、「検索結果」がYESであるかを判定し（ステップＳ５４）、YESの場合は（ステップＳ５４のYES）、障害回復処理の開始を管理者に通知し（ステップＳ５５）、NOの場合は（ステップＳ５４のNO）、手動の回復が必要なことを管理者に通知する（ステップＳ５６）。また、検索結果が追加されていない場合は（ステップＳ５３のNO）、図１の障害履歴管理テーブル２ｇの「実行結果」を参照し、前回、参照した状態と比較して、「実行結果」の欄が追加されているかを判定する。「実行結果」が追加されている場合は（ステップＳ５７のYES）、「実行結果」の欄がYESであるかを判定し、YESの場合は（ステップＳ５８のYES）、障害の回復を管理者に通知し（ステップＳ５９）、NOの場合は（ステップＳ５８のNO）、手動の回復が必要なことを管理者に通知する（ステップＳ５Ａ）。最後に、実行結果も追加されていない場合は（ステップＳ５７のNO）、監視端末３からの管理者への通知は行わない。
【００３３】
本実施形態のサーバ障害回復方法およびサーバ障害回復システムによれば、従来のサーバ障害回復システムにおいて、ハードウェアおよびソフトウェアの構成が異なるサーバにも適用可能になる。
【００３４】
また、被監視サーバから障害の発生元のサーバ名称と障害名称とを監視サーバに通知するので、障害の発生元および原因を迅速に特定することが可能となり、また、監視サーバにおいて、障害発生元のサーバ名称と障害名称とに応じた障害回復処理を選択できるため、適切な障害回復処理を実行することが可能となる。
【００３５】
また、監視サーバに障害名称と該当する障害回復処理名称と障害回復処理名称の成功確率を格納する障害回復処理管理テーブルと、障害回復処理名称と該当する障害回復コマンドを格納する障害回復コマンドテーブルとを備えたことで、専門の知識を持たない者でも扱うことが可能となる。
【００３６】
また、障害名称と障害回復処理を実施した後に成功の可否を確認する結果確認処理と結果確認処理を実施した後の確認事項を示す確認事項を格納する結果確認処理管理テーブルを備えることで、障害回復結果を蓄積してより成功率の高い障害回復処理を選択することが可能となる。
【００３７】
さらにまた、被監視サーバに発生した障害の状況を格納する障害履歴管理テーブルを備え、監視端末が障害履歴管理テーブルを定期的に監視するようにしたことで、監視端末において、サーバの障害状況、特に手動による障害回復処理が必要かを迅速に知ることが可能となる。
【図面の簡単な説明】
【００３８】
【図１】本発明の一実施形態に係るサーバ障害回復システムのブロック構成図である。
【図２】本発明の一実施形態に係る各データテーブルを示す図である。
【図３】本発明の一実施形態に係る障害メッセージ監視モジュールの処理手順を示すフローチャートである。
【図４】本発明の一実施形態に係る障害解析モジュールの処理手順を示すフローチャートである。
【図５】本発明の一実施形態に係る結果確認モジュールの処理手順を示すフローチャートである。
【図６】本発明の一実施形態に係る手動対処モジュールの処理手順を示すフローチャートである。
【図７】本発明の一実施形態に係る障害状態通知モジュールの処理手順を示すフローチャートである。
【符号の説明】
【００３９】
１      被監視サーバ
１ａ    メッセージＩＤ管理テーブル
２      監視サーバ
２ｄ    障害回復処理管理テーブル
２ｅ    障害回復コマンドテーブル
２ｆ    結果確認処理管理テーブル
２ｇ    障害履歴管理テーブル
３      監視端末
【図１】
2006023910.tif 000003
【図２】
2006023910.tif 000004
【図３】
2006023910.tif 000005
【図４】
2006023910.tif 000006
【図５】
2006023910.tif 000007
【図６】
2006023910.tif 000008
【図７】
2006023910.tif 000009