JP4850733B2 - ヘルスチェック装置及びヘルスチェック方法及びプログラム - Google Patents
ヘルスチェック装置及びヘルスチェック方法及びプログラム Download PDFInfo
- Publication number
- JP4850733B2 JP4850733B2 JP2007015685A JP2007015685A JP4850733B2 JP 4850733 B2 JP4850733 B2 JP 4850733B2 JP 2007015685 A JP2007015685 A JP 2007015685A JP 2007015685 A JP2007015685 A JP 2007015685A JP 4850733 B2 JP4850733 B2 JP 4850733B2
- Authority
- JP
- Japan
- Prior art keywords
- failure
- monitoring
- fault
- information
- pseudo
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Description
本発明は、機器のヘルスチェックを行う技術に関し、具体的には、例えば、コンピュータシステムの監視を行う監視システムのヘルスチェックを行う技術に関する。
従来のヘルスチェック方式は、所定の処理を実行する複数のプロセスのうち、処理の起点に対してチェックデータを送信する送信手段と、処理の終点プロセスにおける処理の終了を検知する処理完了検知手段とによって、対象の処理の正常性確認を行っていた（例えば、特許文献１）。
ネットワークやサーバの正常性を監視する監視システムにおいても、同様に、障害監視を行う監視装置に対して、障害アラームを発生させるトリガを発生させることにより、監視システムを動作させ、テスト用の障害を検知して表示させることや、予め設定したテスト用のメールアドレスなどを利用し通報を行うことで、監視システムの正常性確認を行うヘルスチェックを行える。
ネットワークやサーバの正常性を監視する監視システムにおいても、同様に、障害監視を行う監視装置に対して、障害アラームを発生させるトリガを発生させることにより、監視システムを動作させ、テスト用の障害を検知して表示させることや、予め設定したテスト用のメールアドレスなどを利用し通報を行うことで、監視システムの正常性確認を行うヘルスチェックを行える。
ネットワークやサーバ等のＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システムの運用監視会社の監視システムは、集中監視センターなどに設置されており、専用のオペレータが多数のネットワークやサーバの監視を行い、異常があれば対応を行っている。
監視システムは大規模化の傾向があり、数十台のサーバや百台以上のネットワーク機器からシステム構築されており、監視システム自身の正常性確認が課題である。
また、監視システムが異常な状態でもオペレータは、検出した障害アラーム対応を行う必要があり、異常が発生した際に処理途中であった障害アラームに迅速に対応する必要があるが、オペレータは通常監視システムの構成には精通していないので、迅速な対応が困難であった。
特開２００４−８６５７４号公報
監視システムは大規模化の傾向があり、数十台のサーバや百台以上のネットワーク機器からシステム構築されており、監視システム自身の正常性確認が課題である。
また、監視システムが異常な状態でもオペレータは、検出した障害アラーム対応を行う必要があり、異常が発生した際に処理途中であった障害アラームに迅速に対応する必要があるが、オペレータは通常監視システムの構成には精通していないので、迅速な対応が困難であった。
従来のヘルスチェック装置は、入力パターンが複数あるような場合には対応できておらず、正常性確認の入力が複数ある場合に、どのような入力を行えば正常性を網羅的に確認できるか、入力を行った場合に、正常な場合には出力が得られるのでこれにより正常性を確認していたが、異常があった場合には、どの処理で異常があったのかを自動的に検知することができないという課題があった。
つまり、監視システムで検知する障害は、例えば、ネットワーク障害及びサーバ障害があるが、ネットワーク障害においても複数種類の障害形式があり、サーバ障害においても複数種類の障害形式があり、監視システムのヘルスチェックを有効に行うためには、それぞれの障害形式に対応させた入力データを監視システムに入力する必要がある。
また、監視システムに対するヘルスチェックにおいて監視システムが行った一連の動作の適否を確認するとともに、適正でない場合に一連の動作のうちのどの箇所で適正な対応ができなかったのかを解析する必要があるが、従来はこのような解析手段が存在していなかった。
つまり、監視システムで検知する障害は、例えば、ネットワーク障害及びサーバ障害があるが、ネットワーク障害においても複数種類の障害形式があり、サーバ障害においても複数種類の障害形式があり、監視システムのヘルスチェックを有効に行うためには、それぞれの障害形式に対応させた入力データを監視システムに入力する必要がある。
また、監視システムに対するヘルスチェックにおいて監視システムが行った一連の動作の適否を確認するとともに、適正でない場合に一連の動作のうちのどの箇所で適正な対応ができなかったのかを解析する必要があるが、従来はこのような解析手段が存在していなかった。
この発明は上記のような課題を解決することを主な目的としており、ヘルスチェックの対象における処理実績を管理し、ヘルスチェックの対象における処理実績に基づいて、ヘルスチェックのための入力データを生成してヘルスチェックを行い、また、入力したデータについて出力が行なわれない異常時には、予め処理動作を規定した内容と実際の処理状況を比べることで、どの処理に問題があるのかを自動的に検知し通報する装置等を実現することを主な目的とする。
本発明に係るヘルスチェック装置は、
コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記監視システムによる監視の対象となり、前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部とを有することを特徴とする。
コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記監視システムによる監視の対象となり、前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部とを有することを特徴とする。
本発明では、監視システムが監視対象のコンピュータに対する監視において検知したシステム障害の情報を管理し、監視システムが検知したシステム障害の状況に基づいて、擬似障害を発生させて監視システムの正常性を確認する。具体的には、監視システムが検知したシステム障害の障害検知時刻に基づいて擬似障害を発生させて監視システムに検知させることで、監視システムにおいて特定のシステム障害が長期間検知されてないという事態を排除し、監視システムが検知可能なシステム障害の全てに対して所定の間隔以内でヘルスチェックを行うことで、監視システムの動作確認を漏れのない形で行うことができる。
実施の形態１．
従来のヘルスチェック装置は、入力パターンが複数あるような場合には対応できておらず、正常性確認の入力が複数ある場合に、自動的にどのような入力を行えば正常性を網羅的に確認できるか、入力を行った場合に、正常な場合には出力が得られるのでこれにより正常性を確認していたが、異常があった場合には、どの処理で異常があったのかを自動的に検知することができないという課題があった。
本実施の形態では、上記のような課題を解決することを主な目的としており、入力データについて、複数の入力データを実際に対象が処理している実績を管理し、処理が現時点から遡って動作していないものを自動的に選択して入力とし処理が定期的に動作するようにし、また、入力したデータについて出力が行なわれない異常時には、予め処理動作を規定した内容と実際の処理状況を比べることで、どの処理に問題があるのかを自動的に検知し通報する。
従来のヘルスチェック装置は、入力パターンが複数あるような場合には対応できておらず、正常性確認の入力が複数ある場合に、自動的にどのような入力を行えば正常性を網羅的に確認できるか、入力を行った場合に、正常な場合には出力が得られるのでこれにより正常性を確認していたが、異常があった場合には、どの処理で異常があったのかを自動的に検知することができないという課題があった。
本実施の形態では、上記のような課題を解決することを主な目的としており、入力データについて、複数の入力データを実際に対象が処理している実績を管理し、処理が現時点から遡って動作していないものを自動的に選択して入力とし処理が定期的に動作するようにし、また、入力したデータについて出力が行なわれない異常時には、予め処理動作を規定した内容と実際の処理状況を比べることで、どの処理に問題があるのかを自動的に検知し通報する。
図１は、本実施の形態に係る監視センター１を含む全体システム構成例を示すシステム構成図である。
図１において、監視センター１は、運用監視サービスを提供する。
監視システム２は、監視対象（コンピュータシステム）の運用監視サービスを実現する。
ネットワーク監視装置３は、監視システム２において、監視対象（コンピュータシステム）のネットワークの状態を監視する。ネットワーク監視装置３は、Ｎ／Ｗ監視装置とも表記する。
サーバ監視装置４は、監視システム２において、監視対象（コンピュータシステム）内のサーバ等のコンピュータの状態を監視する。
アラーム統合装置５は、ネットワーク監視とサーバ監視のアラームを統合する。
構成情報データベース６は監視対象の情報を記録している。
障害管理装置７は、障害アラームの記録と管理を行う。
監視モニタ８は、監視を行うオペレータが使用する。
監視ネットワーク９は、監視システム２が監視を行うためのネットワークである。
サーバ１０は、監視システム２の監視対象となるコンピュータシステムに含まれているコンピュータである。
ネットワーク機器１１は、監視システム２の監視対象となるコンピュータシステムに含まれているルータ等のネットワーク機器である。
ヘルスチェック装置１２は、監視システム２のヘルスチェックを行う。
図１において、監視センター１は、運用監視サービスを提供する。
監視システム２は、監視対象（コンピュータシステム）の運用監視サービスを実現する。
ネットワーク監視装置３は、監視システム２において、監視対象（コンピュータシステム）のネットワークの状態を監視する。ネットワーク監視装置３は、Ｎ／Ｗ監視装置とも表記する。
サーバ監視装置４は、監視システム２において、監視対象（コンピュータシステム）内のサーバ等のコンピュータの状態を監視する。
アラーム統合装置５は、ネットワーク監視とサーバ監視のアラームを統合する。
構成情報データベース６は監視対象の情報を記録している。
障害管理装置７は、障害アラームの記録と管理を行う。
監視モニタ８は、監視を行うオペレータが使用する。
監視ネットワーク９は、監視システム２が監視を行うためのネットワークである。
サーバ１０は、監視システム２の監視対象となるコンピュータシステムに含まれているコンピュータである。
ネットワーク機器１１は、監視システム２の監視対象となるコンピュータシステムに含まれているルータ等のネットワーク機器である。
ヘルスチェック装置１２は、監視システム２のヘルスチェックを行う。
ヘルスチェック装置１２は、管理装置１９と擬似監視装置２０から構成される。
管理装置１９には、障害確認部１３、発生障害分類部１４、システム動作確認部１５、障害記録表ＤＢ（データベース）１７、動作管理表ＤＢ（データベース）１８が含まれる。
擬似監視装置２０には、擬似障害発生部１６が含まれる。
障害確認部１３、発生障害分類部１４及び障害記録表ＤＢ１７は、障害情報管理部の例であり、システム動作確認部１５及び動作管理表ＤＢ１８は、動作手順解析部の例である。
なお、図１では、ヘルスチェック装置１２は、管理装置１９と擬似監視装置２０に分かれている、一つのコンピュータ装置でこれらを実現してもよいし、二つ以上のコンピュータ装置で実現してもよい。
管理装置１９には、障害確認部１３、発生障害分類部１４、システム動作確認部１５、障害記録表ＤＢ（データベース）１７、動作管理表ＤＢ（データベース）１８が含まれる。
擬似監視装置２０には、擬似障害発生部１６が含まれる。
障害確認部１３、発生障害分類部１４及び障害記録表ＤＢ１７は、障害情報管理部の例であり、システム動作確認部１５及び動作管理表ＤＢ１８は、動作手順解析部の例である。
なお、図１では、ヘルスチェック装置１２は、管理装置１９と擬似監視装置２０に分かれている、一つのコンピュータ装置でこれらを実現してもよいし、二つ以上のコンピュータ装置で実現してもよい。
ここで、ヘルスチェック装置１２の動作例について概説する。
障害情報管理部は、監視システム２が監視対象（コンピュータシステム）に対する監視において検知した監視対象のシステム障害の情報を管理する。
擬似障害発生部１６は、監視システム２と接続されており、監視システム２による障害監視の対象となる。そして、擬似障害発生部１６は、障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、擬似障害を監視システムの検知の対象とさせる。
また、障害情報管理部は、複数のシステム障害の情報を管理しており、それぞれのシステム障害に対して、監視システム２が監視対象に対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、擬似障害発生部１６は、複数のシステム障害の中から障害検知時刻に基づいて特定のシステム障害を選択する。例えば、障害情報管理部が管理する複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させる。
障害情報管理部は、監視システム２が監視対象（コンピュータシステム）に対する監視において検知した監視対象のシステム障害の情報を管理する。
擬似障害発生部１６は、監視システム２と接続されており、監視システム２による障害監視の対象となる。そして、擬似障害発生部１６は、障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、擬似障害を監視システムの検知の対象とさせる。
また、障害情報管理部は、複数のシステム障害の情報を管理しており、それぞれのシステム障害に対して、監視システム２が監視対象に対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、擬似障害発生部１６は、複数のシステム障害の中から障害検知時刻に基づいて特定のシステム障害を選択する。例えば、障害情報管理部が管理する複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させる。
監視システム２は、監視対象におけるシステム障害としてネットワーク障害を検知することが可能であり、擬似障害発生部１６は、このネットワーク障害検知に対するヘルスチェックとして、監視システム２が監視の対象としているネットワークインタフェース機能の動作を一時的に停止させて擬似ネットワーク障害を発生させる。
また、監視システム２は、監視対象におけるシステム障害としてサーバ障害を検知することが可能であり、擬似障害発生部１６は、このサーバ障害検知に対するヘルスチェックとして、監視システム２が監視の対象としている特定プロセスの起動及び終了、特定プロセスが使用するメモリ利用率、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）利用率、特定のディスクパーティションの利用率の少なくともいずれかを一定間隔の間制御することにより擬似サーバ障害を発生させる。
また、監視システム２は、監視対象におけるシステム障害としてサーバ障害を検知することが可能であり、擬似障害発生部１６は、このサーバ障害検知に対するヘルスチェックとして、監視システム２が監視の対象としている特定プロセスの起動及び終了、特定プロセスが使用するメモリ利用率、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）利用率、特定のディスクパーティションの利用率の少なくともいずれかを一定間隔の間制御することにより擬似サーバ障害を発生させる。
また、障害情報管理部は、監視システム２が監視対象に対する監視において検知した監視対象におけるシステム障害の情報を、ネットワーク障害についてのＰＩＮＧ監視結果の情報、ネットワーク障害についてのＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ） Ｔｒａｐ監視結果の情報、サーバ障害についてのログ監視結果の情報、サーバ障害についてのＣＰＵ利用率監視結果の情報、サーバ障害についてのメモリ利用率監視結果の情報、サーバ障害についてのディスク利用率監視結果の情報に分類して管理する。
また、動作手順解析部は、擬似障害に対して監視システム２が実施すべき正常動作手順を示す動作管理表（正常動作手順情報）を保有し、擬似障害に対して監視システム２が実際に実施した実施動作手順を示す情報（実施動作手順情報）を取得し、動作管理表（正常動作手順情報）と取得した情報（実施動作手順情報）とを比較して、擬似障害に対する監視システム２の実施動作手順を解析する。
また、動作手順解析部は、監視対象で発生したシステム障害（擬似障害ではなく、実際の障害）に対して監視システムが実施すべきシステム障害正常動作手順を示す動作管理表（システム障害正常動作手順情報）も保有し、監視対象で発生したシステム障害に対して監視システム２が実際に実施したシステム障害実施動作手順を示す情報（システム障害実施動作手順情報）を取得し、動作管理表（システム障害正常動作手順情報）と取得した情報（システム障害実施動作手順情報）とを比較して、システム障害に対する監視システム２のシステム障害実施動作手順を解析することも可能である。
また、動作手順解析部は、監視対象で発生したシステム障害（擬似障害ではなく、実際の障害）に対して監視システムが実施すべきシステム障害正常動作手順を示す動作管理表（システム障害正常動作手順情報）も保有し、監視対象で発生したシステム障害に対して監視システム２が実際に実施したシステム障害実施動作手順を示す情報（システム障害実施動作手順情報）を取得し、動作管理表（システム障害正常動作手順情報）と取得した情報（システム障害実施動作手順情報）とを比較して、システム障害に対する監視システム２のシステム障害実施動作手順を解析することも可能である。
次に、監視センター１の全体の動作例を詳細に説明する。
監視センター１は、ネットワークやサーバの運用監視を委託される運用監視会社などの統合的な監視センターであり、多数のネットワークの状態やサーバの死活などを遠隔から監視する。
実際の監視は監視システム２で実現されており、ネットワークの監視はネットワーク監視装置３によって定期的にルータ等の監視対象のネットワーク機器１１に監視ネットワーク９を通じてＰＩＮＧを用いて監視を行っている。
サーバ監視装置４も同様に監視対象のサーバ１０の死活監視、プロセス管理、ログ監視、ＣＰＵ利用率監視、メモリ利用率監視、ディスクの利用率監視などを行っている。
サーバ監視装置４の場合には、監視対象のサーバ１０にサーバ監視装置４のエージェントが導入されており、これによってサーバの各種監視が行われている。
監視センター１は、ネットワークやサーバの運用監視を委託される運用監視会社などの統合的な監視センターであり、多数のネットワークの状態やサーバの死活などを遠隔から監視する。
実際の監視は監視システム２で実現されており、ネットワークの監視はネットワーク監視装置３によって定期的にルータ等の監視対象のネットワーク機器１１に監視ネットワーク９を通じてＰＩＮＧを用いて監視を行っている。
サーバ監視装置４も同様に監視対象のサーバ１０の死活監視、プロセス管理、ログ監視、ＣＰＵ利用率監視、メモリ利用率監視、ディスクの利用率監視などを行っている。
サーバ監視装置４の場合には、監視対象のサーバ１０にサーバ監視装置４のエージェントが導入されており、これによってサーバの各種監視が行われている。
次に、これらのネットワーク監視装置３やサーバ監視装置４が監視対象の障害を検知した場合には、障害アラームが検出されるので、この障害アラームがアラーム統合装置５に送信される。
アラーム統合装置５では、送付された障害アラームがどのような顧客のどのような構成の機器であるかを調べるために、予め構成情報データベース６にこれらの記録が管理されているので、その情報を監視対象のＩＰアドレスやホスト名などを利用して参照し、人間に分かりやすい情報をつくり、監視モニタ８に障害情報を統合一覧表示して障害発生をオペレータに知らせる。
次に、アラーム統合装置５は、この障害アラーム情報をログに保存し、その後、障害管理装置７にも障害発生を送信して、障害管理チケットを起票し、管制員はこの障害管理チケットにより障害対応を実施する。
アラーム統合装置５では、送付された障害アラームがどのような顧客のどのような構成の機器であるかを調べるために、予め構成情報データベース６にこれらの記録が管理されているので、その情報を監視対象のＩＰアドレスやホスト名などを利用して参照し、人間に分かりやすい情報をつくり、監視モニタ８に障害情報を統合一覧表示して障害発生をオペレータに知らせる。
次に、アラーム統合装置５は、この障害アラーム情報をログに保存し、その後、障害管理装置７にも障害発生を送信して、障害管理チケットを起票し、管制員はこの障害管理チケットにより障害対応を実施する。
ヘルスチェック装置１２は、監視システム２に隣接して設置される。
ヘルスチェック装置１２は、前述したように、管理装置１９と擬似監視装置２０から構成され、監視システム２とはＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって接続され、データの交換が可能なように設置する。
さらに、擬似監視装置２０は、２つ以上のネットワークインタフェースを持ち、１つは管理装置１９との通信、１つは監視システム２からの監視に使用する。
また、ネットワーク監視装置３には、擬似監視装置２０のネットワークのアドレスを監視するように設定を行い、サーバ監視装置４の監視設定も擬似監視装置２０に対して行い、例えば擬似監視装置２０にサーバ監視装置４のエージェントを導入することで、擬似監視装置２０のログ監視、プロセス監視、ＣＰＵ利用量の閾値監視、メモリの使用量の閾値監視、ディスクの使用量の閾値監視の設定を行う。このように、擬似監視装置２０は、ネットワーク監視装置３及びサーバ監視装置４の監視対象となり、擬似障害発生部１６が擬似障害を発生させた場合に、ネットワーク監視装置３及びサーバ監視装置４により擬似障害が検知されるように設定しておく。
また、事前に擬似監視装置２０のネットワーク監視やサーバ監視が実行できることを確認しておく。
また、ヘルスチェック装置１２の設置は本番の監視環境に設置して、監視システム２はサービスとしてのネットワーク監視とサーバ監視と同様に擬似監視装置２０に対する監視を実施する。
ヘルスチェック装置１２は、前述したように、管理装置１９と擬似監視装置２０から構成され、監視システム２とはＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によって接続され、データの交換が可能なように設置する。
さらに、擬似監視装置２０は、２つ以上のネットワークインタフェースを持ち、１つは管理装置１９との通信、１つは監視システム２からの監視に使用する。
また、ネットワーク監視装置３には、擬似監視装置２０のネットワークのアドレスを監視するように設定を行い、サーバ監視装置４の監視設定も擬似監視装置２０に対して行い、例えば擬似監視装置２０にサーバ監視装置４のエージェントを導入することで、擬似監視装置２０のログ監視、プロセス監視、ＣＰＵ利用量の閾値監視、メモリの使用量の閾値監視、ディスクの使用量の閾値監視の設定を行う。このように、擬似監視装置２０は、ネットワーク監視装置３及びサーバ監視装置４の監視対象となり、擬似障害発生部１６が擬似障害を発生させた場合に、ネットワーク監視装置３及びサーバ監視装置４により擬似障害が検知されるように設定しておく。
また、事前に擬似監視装置２０のネットワーク監視やサーバ監視が実行できることを確認しておく。
また、ヘルスチェック装置１２の設置は本番の監視環境に設置して、監視システム２はサービスとしてのネットワーク監視とサーバ監視と同様に擬似監視装置２０に対する監視を実施する。
まず、擬似障害アラームの発生方法について説明する。
図２は、図１の障害情報管理部、特に障害確認部の動作例（障害情報管理ステップ）を示すフローチャートである。
ステップＳ１では、障害確認部１３が、ネットワーク監視装置３に新たな障害アラームがあるかどうかを確認する。これはネットワーク監視装置３の管理しているデータを確認することで新たな障害アラームが発生したかどうかを確認する。
次にステップＳ２において、障害確認部１３は、障害アラームが発生したかどうかを判定する。
障害アラームが発生していなければ、ステップＳ４において、障害確認部１３は、サーバ監視装置４のアラームをネットワーク監視装置３と同様にサーバ監視装置４の管理するデータを確認することで実施する。
ステップＳ５でアラームが発生していなければ、障害確認部１３は、新規の障害アラームはないと判断して一定時間の本プロセスをスリープさせ、定期的に障害アラームの確認を行うようにする。
一定時間とはネットワーク監視装置とサーバ監視装置の障害検知の周期に合わせる必要があるが、通常は１分から１０分程度のスリープ時間を設定する。
ステップＳ２やステップＳ５で新規の障害アラームが検知された場合には、ステップＳ３にて障害アラームを障害記録表ＤＢ１７の障害記録表に記入する。障害記録表とは、監視システム２で発生した障害を記録する表である。
図２は、図１の障害情報管理部、特に障害確認部の動作例（障害情報管理ステップ）を示すフローチャートである。
ステップＳ１では、障害確認部１３が、ネットワーク監視装置３に新たな障害アラームがあるかどうかを確認する。これはネットワーク監視装置３の管理しているデータを確認することで新たな障害アラームが発生したかどうかを確認する。
次にステップＳ２において、障害確認部１３は、障害アラームが発生したかどうかを判定する。
障害アラームが発生していなければ、ステップＳ４において、障害確認部１３は、サーバ監視装置４のアラームをネットワーク監視装置３と同様にサーバ監視装置４の管理するデータを確認することで実施する。
ステップＳ５でアラームが発生していなければ、障害確認部１３は、新規の障害アラームはないと判断して一定時間の本プロセスをスリープさせ、定期的に障害アラームの確認を行うようにする。
一定時間とはネットワーク監視装置とサーバ監視装置の障害検知の周期に合わせる必要があるが、通常は１分から１０分程度のスリープ時間を設定する。
ステップＳ２やステップＳ５で新規の障害アラームが検知された場合には、ステップＳ３にて障害アラームを障害記録表ＤＢ１７の障害記録表に記入する。障害記録表とは、監視システム２で発生した障害を記録する表である。
図３は、障害記録表ＤＢ１７に記録される障害記録表のデータ構造例を示す。
２１はアラームのメッセージを格納するエリア、２２は擬似障害発生部１６に擬似障害を発生させるための識別種別の格納エリア、２３は該当する障害アラームの発生回数、２４は該当する障害アラームの最終発生日時を格納するエリア、２５は該当する擬似障害を発生させた回数の累計を格納するエリア、２６は現在擬似障害を発生させている場合に実施中であることを示すフラグを格納するエリアである。
最終発生日時は、監視対象において実際に発生した障害の最終発生日時又は擬似障害発生部１６において擬似障害を発生させた場合の当該擬似障害の最終発生日時である。なお、図３では、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別していないが、これら２つを区別して管理するようにしてもよい。
２１はアラームのメッセージを格納するエリア、２２は擬似障害発生部１６に擬似障害を発生させるための識別種別の格納エリア、２３は該当する障害アラームの発生回数、２４は該当する障害アラームの最終発生日時を格納するエリア、２５は該当する擬似障害を発生させた回数の累計を格納するエリア、２６は現在擬似障害を発生させている場合に実施中であることを示すフラグを格納するエリアである。
最終発生日時は、監視対象において実際に発生した障害の最終発生日時又は擬似障害発生部１６において擬似障害を発生させた場合の当該擬似障害の最終発生日時である。なお、図３では、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別していないが、これら２つを区別して管理するようにしてもよい。
図２のフローチャートで取得された新規の障害アラームは、分類されて図３の形式として格納され、次に説明する発生障害分類部１４にて活用される。
図４は、発生障害分類部１４の動作例を示すフローチャートである。
ステップＳ７では、発生障害分類部１４は、図３で示した障害記録表を入力し、メモリ上に展開する。
ステップ８では、発生障害分類部１４は、障害記録表のレコードを１レコードずつ確認し、選択中フラグがどの障害アラームにも１が記録されていないことを判定する。
もし、選択中フラグに１の記録があれば、これは現在擬似障害の発生中であるので、発生障害分類部１４は、ステップＳ９にて一定時間スリープをして再度ステップＳ７に戻る。
選択中フラグがすべて０であれば、擬似障害が発生していないとみなし、発生障害分類部１４は、擬似障害を発生させるアラーム形式を選択するためのステップＳ１０以降を実施する。
ステップＳ１０では、発生障害分類部１４は、障害記録表の中から最終発生日時の一番古い障害アラームを選択する。実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理している場合は、２つの最終発生日時のうち新しい方の最終発生日時が他の障害アラームの最終発生日時と比べて最も古いかどうかを判定して選択する。
次に、ステップＳ１１にて、発生障害分類部１４は、選択した障害アラームの選択回数に１を加算する。
ステップＳ１２にて、発生障害分類部１４は、該当する障害アラームの選択中フラグに１を設定し、ステップＳ１３にて選択した障害アラームの種別番号を擬似障害発生部１６に送信し、擬似障害を発生させ、待機し、擬似障害発生部１６の処理が終了したとの通知があった際に、ステップＳ１４にて、該当する選択中フラグを０に戻す。
また、図４では図示していないが、発生障害分類部１４は、擬似障害発生部１６の処理が終了したとの通知があった際に、障害記録表の対応する障害アラームの最終発生日時を更新する。なお、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理する場合は、実際の障害の最終発生日時はそのままとし、擬似障害の最終発生日時を更新する。
また、図４のステップＳ１０の処理の後に、ステップＳ１０で選択された最も古いアラームの最終発生日時が一定時間以上前の日時であるかどうかを確認する処理を追加し、一定時間以上前の日時である場合にはステップＳ１１以降の処理を実施し、一定時間以上前の日時でない場合には処理を終了するようにしてもよい。
ステップＳ７では、発生障害分類部１４は、図３で示した障害記録表を入力し、メモリ上に展開する。
ステップ８では、発生障害分類部１４は、障害記録表のレコードを１レコードずつ確認し、選択中フラグがどの障害アラームにも１が記録されていないことを判定する。
もし、選択中フラグに１の記録があれば、これは現在擬似障害の発生中であるので、発生障害分類部１４は、ステップＳ９にて一定時間スリープをして再度ステップＳ７に戻る。
選択中フラグがすべて０であれば、擬似障害が発生していないとみなし、発生障害分類部１４は、擬似障害を発生させるアラーム形式を選択するためのステップＳ１０以降を実施する。
ステップＳ１０では、発生障害分類部１４は、障害記録表の中から最終発生日時の一番古い障害アラームを選択する。実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理している場合は、２つの最終発生日時のうち新しい方の最終発生日時が他の障害アラームの最終発生日時と比べて最も古いかどうかを判定して選択する。
次に、ステップＳ１１にて、発生障害分類部１４は、選択した障害アラームの選択回数に１を加算する。
ステップＳ１２にて、発生障害分類部１４は、該当する障害アラームの選択中フラグに１を設定し、ステップＳ１３にて選択した障害アラームの種別番号を擬似障害発生部１６に送信し、擬似障害を発生させ、待機し、擬似障害発生部１６の処理が終了したとの通知があった際に、ステップＳ１４にて、該当する選択中フラグを０に戻す。
また、図４では図示していないが、発生障害分類部１４は、擬似障害発生部１６の処理が終了したとの通知があった際に、障害記録表の対応する障害アラームの最終発生日時を更新する。なお、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理する場合は、実際の障害の最終発生日時はそのままとし、擬似障害の最終発生日時を更新する。
また、図４のステップＳ１０の処理の後に、ステップＳ１０で選択された最も古いアラームの最終発生日時が一定時間以上前の日時であるかどうかを確認する処理を追加し、一定時間以上前の日時である場合にはステップＳ１１以降の処理を実施し、一定時間以上前の日時でない場合には処理を終了するようにしてもよい。
図５は、擬似障害発生部１６の動作例（擬似障害発生ステップ）を示すフローチャートである。
これは、図４の発生障害分類部１４によって選択された該当障害アラームを擬似的に発生させるアルゴリズムである。
図５では、ステップＳ１５、ステップＳ１７、ステップＳ１９、ステップＳ２１、ステップＳ２３、ステップＳ２５、ステップＳ２７の判定にて、図４に示す処理にて発生障害分類部１４から送信された障害アラームの種別番号を判定して、該当する擬似障害を発生するステップＳ１６、ステップＳ１８、ステップＳ２０、ステップＳ２２、ステップＳ２４、ステップＳ２６、ステップＳ２８のサブルーチンを呼び出し実行する構成である。
これは、図４の発生障害分類部１４によって選択された該当障害アラームを擬似的に発生させるアルゴリズムである。
図５では、ステップＳ１５、ステップＳ１７、ステップＳ１９、ステップＳ２１、ステップＳ２３、ステップＳ２５、ステップＳ２７の判定にて、図４に示す処理にて発生障害分類部１４から送信された障害アラームの種別番号を判定して、該当する擬似障害を発生するステップＳ１６、ステップＳ１８、ステップＳ２０、ステップＳ２２、ステップＳ２４、ステップＳ２６、ステップＳ２８のサブルーチンを呼び出し実行する構成である。
図６は、図５のステップＳ１６（ネットワークダウン）が選択された際に、擬似障害発生部１６が実行するネットワークインタフェースをダウンさせる動作のフローチャートである。
図６は、図３の種別２２の１に該当しており、ＰＩＮＧ ＥＲＲＯＲに相当する擬似障害を発生させる仕組みである。
図６は、図３の種別２２の１に該当しており、ＰＩＮＧ ＥＲＲＯＲに相当する擬似障害を発生させる仕組みである。
ステップＳ２９では、擬似障害発生部１６は、図１の擬似監視装置２０の２つ以上あるネットワークインタフェースのうちの２番目のネットワークインタフェースカード、すなわち、ネットワーク監視装置３からＰＩＮＧ監視されているネットワークインタフェースカードの機能をダウンさせる。
ステップＳ３０では、ネットワーク監視装置３がステップＳ２９の動作によりネットワーク機能がダウンしたことを検知するまで待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にネットワーク監視装置３のＰＩＮＧによる検知間隔は１分から５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ３１では、この時点でネットワーク監視装置３がネットワークの異常を検知しているはずなので、擬似障害発生部１６は擬似監視装置２０のダウンさせたネットワークインタフェースを再起動させ、もとの状態に戻す。
なお、ネットワーク監視装置３がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置３が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３１の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置３では、障害を検知したネットワークインタフェースカードが擬似監視装置２０のネットワークインタフェースカードであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
ステップＳ３０では、ネットワーク監視装置３がステップＳ２９の動作によりネットワーク機能がダウンしたことを検知するまで待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にネットワーク監視装置３のＰＩＮＧによる検知間隔は１分から５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ３１では、この時点でネットワーク監視装置３がネットワークの異常を検知しているはずなので、擬似障害発生部１６は擬似監視装置２０のダウンさせたネットワークインタフェースを再起動させ、もとの状態に戻す。
なお、ネットワーク監視装置３がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置３が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３１の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置３では、障害を検知したネットワークインタフェースカードが擬似監視装置２０のネットワークインタフェースカードであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図７は、図５のステップＳ１７（トラップ）が選択された際に、擬似障害発生部１６が実行するネットワークのインタフェースがダウンしたことをＳＮＭＰ Ｔｒａｐとして発生させる動作のフローチャートである。
図３の種別２２の２に該当しており、ＳＮＭＰ ＴＲＡＰ ＩＦ ＤＯＷＮに相当する擬似障害を発生させる仕組みである。
ステップＳ３２は図１の擬似監視装置２０からＳＮＭＰ ＴＲＡＰを図１のネットワーク監視装置３に発生させるステップである。
ＳＮＭＰ ＴＲＡＰは投げ捨てのデータであるので、これをネットワーク監視装置３で検知する。
なお、ネットワーク監視装置３がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置３が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３２の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置３では、検知したＳＮＭＰ ＴＲＡＰが擬似監視装置２０のものであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図３の種別２２の２に該当しており、ＳＮＭＰ ＴＲＡＰ ＩＦ ＤＯＷＮに相当する擬似障害を発生させる仕組みである。
ステップＳ３２は図１の擬似監視装置２０からＳＮＭＰ ＴＲＡＰを図１のネットワーク監視装置３に発生させるステップである。
ＳＮＭＰ ＴＲＡＰは投げ捨てのデータであるので、これをネットワーク監視装置３で検知する。
なお、ネットワーク監視装置３がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置３が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３２の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置３では、検知したＳＮＭＰ ＴＲＡＰが擬似監視装置２０のものであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図８は、図５のステップＳ２０（プロセスダウン）が選択された際に、擬似障害発生部１６が実行するサーバ監視のプロセスをダウンさせる動作のフローチャートである。
図３の種別２２の３に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲプロセスに相当する擬似障害を発生させる仕組みである。
ステップＳ３３では、擬似障害発生部１６は、擬似監視装置２０上で予め動作させている監視用のプロセスをダウンさせる。この監視用のプロセスは、サーバ監視装置４の監視対象となっているプロセスである。
ステップＳ３４では、サーバ監視装置４がステップＳ３３の動作により監視用のプロセスがダウンしたことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ３５では、この時点でサーバ監視装置４がプロセスの異常を検知しているはずなので、擬似障害発生部１６は、擬似監視装置２０のダウンさせた監視プロセスを再起動させ、もとの状態に戻す。
なお、サーバ監視装置４が監視プロセスの擬似ダウンを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３５の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、障害を検知した監視プロセスが擬似監視装置２０上で稼働している監視プロセスであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図３の種別２２の３に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲプロセスに相当する擬似障害を発生させる仕組みである。
ステップＳ３３では、擬似障害発生部１６は、擬似監視装置２０上で予め動作させている監視用のプロセスをダウンさせる。この監視用のプロセスは、サーバ監視装置４の監視対象となっているプロセスである。
ステップＳ３４では、サーバ監視装置４がステップＳ３３の動作により監視用のプロセスがダウンしたことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ３５では、この時点でサーバ監視装置４がプロセスの異常を検知しているはずなので、擬似障害発生部１６は、擬似監視装置２０のダウンさせた監視プロセスを再起動させ、もとの状態に戻す。
なお、サーバ監視装置４が監視プロセスの擬似ダウンを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３５の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、障害を検知した監視プロセスが擬似監視装置２０上で稼働している監視プロセスであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図９は、図５のステップＳ２２（計算）が選択された際に、擬似障害発生部１６が実行するサーバ監視のＣＰＵ利用率を高めＣＰＵ利用率閾値監視をさせる動作のフローチャートである。
図３の種別２２の４に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＣＰＵに相当する擬似障害を発生させる仕組みである。
ステップＳ３６は、擬似監視装置２０のＣＰＵ負荷を高めるために、加算ループを行うための変数Ｉの初期化ステップである。
ステップＳ３７は、実際の変数Ｉへの加算ステップである。
ステップＳ３８は、加算を終了させる上限の値との判定ステップである。
このように、擬似障害発生部１６は、加算のみを大量に実行することで擬似監視装置２０のＣＰＵ利用率を向上させ、サーバ監視装置４でＣＰＵ利用率の閾値監視アラームを発生させる。
なお、サーバ監視装置４が擬似監視装置２０におけるＣＰＵ利用率が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３８の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたＣＰＵ利用率が擬似監視装置２０におけるＣＰＵ利用率であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図３の種別２２の４に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＣＰＵに相当する擬似障害を発生させる仕組みである。
ステップＳ３６は、擬似監視装置２０のＣＰＵ負荷を高めるために、加算ループを行うための変数Ｉの初期化ステップである。
ステップＳ３７は、実際の変数Ｉへの加算ステップである。
ステップＳ３８は、加算を終了させる上限の値との判定ステップである。
このように、擬似障害発生部１６は、加算のみを大量に実行することで擬似監視装置２０のＣＰＵ利用率を向上させ、サーバ監視装置４でＣＰＵ利用率の閾値監視アラームを発生させる。
なお、サーバ監視装置４が擬似監視装置２０におけるＣＰＵ利用率が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ３８の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたＣＰＵ利用率が擬似監視装置２０におけるＣＰＵ利用率であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図１０は、図５のステップＳ２４（メモリ確保）が選択された際に、擬似障害発生部１６が実行するサーバ監視のメモリ使用率を高めメモリ使用率閾値監視をさせる動作のフローチャートである。
図３の種別２２の５に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＭＥＭＯＲＹに相当する擬似障害を発生させる仕組みである。
ステップＳ３９では、擬似障害発生部１６は、擬似監視装置２０のメモリ利用率を高めるために、メモリアロケート命令により、サーバ監視装置４において閾値監視が発動される量のメモリを取得する。
ステップＳ４０では、サーバ監視装置４がステップＳ３９の動作によりメモリ使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ４１では、この時点でサーバ監視装置４がメモリ使用量の異常（擬似監視装置２０におけるメモリ使用量が閾値を超えている）を検知しているはずなので、擬似障害発生部１６は、ステップＳ４０で取得したメモリをすべて開放し、もとの状態に戻す。
サーバ監視装置４が擬似監視装置２０におけるメモリ使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ４１の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたメモリ使用量が擬似監視装置２０におけるメモリ使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図３の種別２２の５に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＭＥＭＯＲＹに相当する擬似障害を発生させる仕組みである。
ステップＳ３９では、擬似障害発生部１６は、擬似監視装置２０のメモリ利用率を高めるために、メモリアロケート命令により、サーバ監視装置４において閾値監視が発動される量のメモリを取得する。
ステップＳ４０では、サーバ監視装置４がステップＳ３９の動作によりメモリ使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ４１では、この時点でサーバ監視装置４がメモリ使用量の異常（擬似監視装置２０におけるメモリ使用量が閾値を超えている）を検知しているはずなので、擬似障害発生部１６は、ステップＳ４０で取得したメモリをすべて開放し、もとの状態に戻す。
サーバ監視装置４が擬似監視装置２０におけるメモリ使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ４１の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたメモリ使用量が擬似監視装置２０におけるメモリ使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図１１は、図５のステップＳ２６（ＤＩＳＫ確保）が選択された際に、擬似障害発生部１６が実行するサーバ監視のディスク使用率を高めＤＩＳＫ使用率閾値監視をさせる動作のフローチャートである。
図３の種別２２の６に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＤＩＳＫに相当する擬似障害アラームを発生させる仕組みである。
ステップＳ４２では、擬似障害発生部１６は擬似監視装置２０のディスク利用率を高めるために、ＣＲＥＡＴＥＦＩＬＥ命令により、予め決めておいたディスクパーティションに対してファイルを１つ作成する。
ステップＳ４３では、擬似障害発生部１６は、ステップＳ４２で作成したファイルに対して、サーバ監視装置４が規定するディスク閾値を越えるデータ量をＷＲＩＴＥ命令で記述する。
ステップＳ４４では、擬似障害発生部１６は、作成したファイルをＣＬＯＳＥすることで、ディスクパーティションの使用量を増加させる。
ステップＳ４５では、サーバ監視装置４がステップＳ４４の動作によりディスク使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ４６では、この時点でサーバ監視装置４がディスク使用量の異常（擬似監視装置２０におけるディスク使用量が閾値を超えている）を検知しているはずなので、擬似障害発生部１６は、ステップＳ４２で作成したファイルをすべて削除し、もとの状態に戻す。
なお、サーバ監視装置４が擬似監視装置２０におけるディスク使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ４６の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたディスク使用量が擬似監視装置２０におけるディスク使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図３の種別２２の６に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＤＩＳＫに相当する擬似障害アラームを発生させる仕組みである。
ステップＳ４２では、擬似障害発生部１６は擬似監視装置２０のディスク利用率を高めるために、ＣＲＥＡＴＥＦＩＬＥ命令により、予め決めておいたディスクパーティションに対してファイルを１つ作成する。
ステップＳ４３では、擬似障害発生部１６は、ステップＳ４２で作成したファイルに対して、サーバ監視装置４が規定するディスク閾値を越えるデータ量をＷＲＩＴＥ命令で記述する。
ステップＳ４４では、擬似障害発生部１６は、作成したファイルをＣＬＯＳＥすることで、ディスクパーティションの使用量を増加させる。
ステップＳ４５では、サーバ監視装置４がステップＳ４４の動作によりディスク使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部１６は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置４の検知間隔は５分から１５分程度であるので、スリープする時間の目安はこの検知間隔プラス１分程度の時間となる。
ステップＳ４６では、この時点でサーバ監視装置４がディスク使用量の異常（擬似監視装置２０におけるディスク使用量が閾値を超えている）を検知しているはずなので、擬似障害発生部１６は、ステップＳ４２で作成したファイルをすべて削除し、もとの状態に戻す。
なお、サーバ監視装置４が擬似監視装置２０におけるディスク使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置４が検知した場合と同様の手順で判断することができる。すなわち、障害確認部１３が、図２に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップＳ４６の時点では、ヘルスチェック装置１２は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置４では、閾値を超えたディスク使用量が擬似監視装置２０におけるディスク使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図１２は、図５のステップＳ２８（ログ出力）が選択された際に、擬似障害発生部１６が実行するサーバ監視のログ監視をさせる動作のフローチャートである。
図３の種別２２の７に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＬＯＧに相当する擬似障害を発生させる仕組みである。
ステップＳ４７は、擬似監視装置２０に予め用意されたログファイルの内容の監視に対して、監視に該当するレコードを記述するためのログファイルＯＰＥＮ命令である。
ステップＳ４８は、該当するログファイルへのＷＲＩＴＥ命令である。
ステップＳ４９は、ＯＰＥＮしたファイルのＣＬＯＳＥ命令であり、これにより、ログファイルにテスト用の監視ログレコードが出力される。
図３の種別２２の７に該当しており、ＳＥＲＶＥＲ ＥＲＲＯＲ ＬＯＧに相当する擬似障害を発生させる仕組みである。
ステップＳ４７は、擬似監視装置２０に予め用意されたログファイルの内容の監視に対して、監視に該当するレコードを記述するためのログファイルＯＰＥＮ命令である。
ステップＳ４８は、該当するログファイルへのＷＲＩＴＥ命令である。
ステップＳ４９は、ＯＰＥＮしたファイルのＣＬＯＳＥ命令であり、これにより、ログファイルにテスト用の監視ログレコードが出力される。
このように、本実施の形態に係るヘルスチェック装置１２は、障害確認部１３（及び図２に示す処理）により、ネットワーク監視装置３やサーバ監視装置４から新規の障害アラームを集めてきて、管理し、実際に発生している障害アラームの最近実施されていない障害アラームを選択する発生障害分類部１４（及び図４に示す処理）によって障害を選択し、監視システムの監視機能をテストするために、擬似障害発生部１６（及び図５の処理）により、擬似的な障害を実際に擬似監視装置２０で発生させて処理状況を確認する。
個々の装置で発生した障害を管理者に通報するネットワークやサーバ等の障害管理方法やこれに類する障害監視システムにおいては、擬似的な障害を入力とした場合に、ネットワーク監視装置やサーバ監視装置によって入力となる障害アラーム形式が異なり、監視システム側での処理も異なる。
そこで、本実施の形態では、入力となる障害アラームを満遍なく発生させるために、障害アラームの処理状況を管理し、最近発生していない障害アラームの形式を強制的に発生させることで監視システムの正常性を確認している。
また、ネットワーク障害及びサーバ障害をそれぞれ複数種類の障害形式に分類し、それぞれの障害形式における最終発生日時を管理し、最も長期にわたって発生していない障害を擬似障害として優先して発生させるようにしている。
そこで、本実施の形態では、入力となる障害アラームを満遍なく発生させるために、障害アラームの処理状況を管理し、最近発生していない障害アラームの形式を強制的に発生させることで監視システムの正常性を確認している。
また、ネットワーク障害及びサーバ障害をそれぞれ複数種類の障害形式に分類し、それぞれの障害形式における最終発生日時を管理し、最も長期にわたって発生していない障害を擬似障害として優先して発生させるようにしている。
次に、監視システム動作の確認方法について説明する。
図１３は、図１の管理装置１９で動作するシステム動作確認部１５の動作フローチャートである。
ステップＳ５０では、システム動作確認部１５は、図１４で説明する動作管理表の読み込みを行う。
図１３は、図１の管理装置１９で動作するシステム動作確認部１５の動作フローチャートである。
ステップＳ５０では、システム動作確認部１５は、図１４で説明する動作管理表の読み込みを行う。
図１４は、動作管理表ＤＢ１８に記録されている動作管理表の例である。
図１４（ａ）及び（ｂ）に示すように、動作管理表には２つの表が用意されている。
１つ（図１４（ａ））は予め動作を規定した有向グラフをリスト形式（文字列で表現）したものであり、２７はアラーム種別、２８は動作リストである。
もうひとつ（図１４（ｂ））は各システムの障害アラームに対応する処理の履歴（ログ）であり、各システムが生成したものを何らかの方法で集めてきたものである。
２９はアラームＩＤ、３０は処理の日時、３１は実行した動作である。
図１４（ａ）及び（ｂ）に示すように、動作管理表には２つの表が用意されている。
１つ（図１４（ａ））は予め動作を規定した有向グラフをリスト形式（文字列で表現）したものであり、２７はアラーム種別、２８は動作リストである。
もうひとつ（図１４（ｂ））は各システムの障害アラームに対応する処理の履歴（ログ）であり、各システムが生成したものを何らかの方法で集めてきたものである。
２９はアラームＩＤ、３０は処理の日時、３１は実行した動作である。
すなわち、図１４（ａ）の表は、ネットワーク監視とサーバ監視の処理内容を予め決めて有向グラフを表すリスト形式で保存してある情報である。
また、図１４（ｂ）の表は、監視システム２を構成する各装置、ここでは、図１のネットワーク監視装置３、サーバ監視装置４、アラーム統合装置５、構成情報ＤＢ６、障害管理装置７を対象に処理状況のログをネットワーク監視装置３又はサーバ監視装置４が付加するアラームＩＤを通し番号にした情報である。
図１４（ａ）の情報は、ネットワーク監視装置３又はサーバ監視装置４が擬似障害を検知した際に擬似障害に対して監視システム２が実施すべき正常動作手順をサーバ障害、ネットワーク障害に分類して示す情報（正常動作手順情報）である。なお、動作リストの具体的内容については、後述する。
また、図１４（ｂ）の情報は、ヘルスチェック装置１２が、監視システム２から取得した情報であり、擬似障害に対してネットワーク監視装置３又はサーバ監視装置４が実際に実施した実施動作手順を示す情報（実施動作手順情報）である。例えば、アラームＩＤ：０００１は、ネットワーク監視装置３により検知されたネットワークに関する擬似障害に対して監視システム２が実際に実施した動作手順を示しており、ネットワーク障害アラーム検知（一行目）の後、構成情報参照が行われ（二行目）、その後工事チェックが行われた（三行目）ことが示されている。
また、図１４（ｂ）の表は、監視システム２を構成する各装置、ここでは、図１のネットワーク監視装置３、サーバ監視装置４、アラーム統合装置５、構成情報ＤＢ６、障害管理装置７を対象に処理状況のログをネットワーク監視装置３又はサーバ監視装置４が付加するアラームＩＤを通し番号にした情報である。
図１４（ａ）の情報は、ネットワーク監視装置３又はサーバ監視装置４が擬似障害を検知した際に擬似障害に対して監視システム２が実施すべき正常動作手順をサーバ障害、ネットワーク障害に分類して示す情報（正常動作手順情報）である。なお、動作リストの具体的内容については、後述する。
また、図１４（ｂ）の情報は、ヘルスチェック装置１２が、監視システム２から取得した情報であり、擬似障害に対してネットワーク監視装置３又はサーバ監視装置４が実際に実施した実施動作手順を示す情報（実施動作手順情報）である。例えば、アラームＩＤ：０００１は、ネットワーク監視装置３により検知されたネットワークに関する擬似障害に対して監視システム２が実際に実施した動作手順を示しており、ネットワーク障害アラーム検知（一行目）の後、構成情報参照が行われ（二行目）、その後工事チェックが行われた（三行目）ことが示されている。
次に、ステップ５１では、システム動作確認部１５は、このアラームＩＤを通し番号にして記録されているデータをアラームＩＤでソートして処理する。
ステップＳ５２では、システム動作確認部１５は、監視システム２における動作手順が正しく実行されたのか、正しく実行されなかったかの判定が行なわれていない未処理のアラームＩＤについて処理を行うため、動作管理表に登録されたデータ（図１４（ａ）のデータ及び図１４（ｂ）のソート後のデータ）をメモリ上でリスト形式に変換する処理を行う。
ステップＳ５３では、システム動作確認部１５は、ネットワーク障害アラームかサーバ障害アラームかを判定して、該当する動作管理表（図１４（ａ））のサーバかネットワークどちらかを選択する。
ステップＳ５４では、システム動作確認部１５は、ステップＳ５３で選択した予め設定された処理の有向グラフを表現するリストと、アラーム処理を行った過程で採取された各システムのアラームごとの処理内容を１つずつリストの要素について処理を確認することでマッチングを行う。
ステップＳ５５にて、システム動作確認部１５は、マッチングがされていれば、ステップＳ５６で比較しているアラーム側の処理リストが終端に至ったかどうかを判定し、終端であれば、ステップＳ５７にて正常の判定を下し、正常終了する。
ステップＳ５６にて、リストが終端でなければ、リストの要素を１つ進めて次の要素の確認を同じようにステップＳ５４からステップＳ５５にて行う。
ステップＳ５５の処理でマッチングが失敗した場合には、システム動作確認部１５は、監視システム２における動作手順が想定されたとおりに実行されていないと判断し、ステップＳ５８にて異常処理を行い、管理者に異常を通報するなどの処理を行い終了する。
また、システム動作確認部１５は、アラームＩＤの処理が終了したものについては、動作管理表から削除する。
ステップＳ５２では、システム動作確認部１５は、監視システム２における動作手順が正しく実行されたのか、正しく実行されなかったかの判定が行なわれていない未処理のアラームＩＤについて処理を行うため、動作管理表に登録されたデータ（図１４（ａ）のデータ及び図１４（ｂ）のソート後のデータ）をメモリ上でリスト形式に変換する処理を行う。
ステップＳ５３では、システム動作確認部１５は、ネットワーク障害アラームかサーバ障害アラームかを判定して、該当する動作管理表（図１４（ａ））のサーバかネットワークどちらかを選択する。
ステップＳ５４では、システム動作確認部１５は、ステップＳ５３で選択した予め設定された処理の有向グラフを表現するリストと、アラーム処理を行った過程で採取された各システムのアラームごとの処理内容を１つずつリストの要素について処理を確認することでマッチングを行う。
ステップＳ５５にて、システム動作確認部１５は、マッチングがされていれば、ステップＳ５６で比較しているアラーム側の処理リストが終端に至ったかどうかを判定し、終端であれば、ステップＳ５７にて正常の判定を下し、正常終了する。
ステップＳ５６にて、リストが終端でなければ、リストの要素を１つ進めて次の要素の確認を同じようにステップＳ５４からステップＳ５５にて行う。
ステップＳ５５の処理でマッチングが失敗した場合には、システム動作確認部１５は、監視システム２における動作手順が想定されたとおりに実行されていないと判断し、ステップＳ５８にて異常処理を行い、管理者に異常を通報するなどの処理を行い終了する。
また、システム動作確認部１５は、アラームＩＤの処理が終了したものについては、動作管理表から削除する。
図１５、図１６、図１７は有向グラフの考え方を説明するものである。
図１５は、予め監視システム２の各装置が処理を行う内容を有向グラフで分かりやすく説明するためのものである。
監視システム２では、サーバとネットワークでは、監視処理の動作が異なるので、サーバとネットワークで処理が２つ定義してある。
図１５（ａ）に示すように、サーバ障害では、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、障害管理装置７にて障害管理チケットのＯＰＥＮが行われ、工事の場合には障害対応が必要ないので工事属性のチケットがＯＰＥＮされるという処理が監視システム２の正常な動作手順になっていることを示す。
他方、ネットワーク障害では、図１５（ｂ）に示すように、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、どのような障害か本当に障害かを自動的に切り分けるような自動切り分けが実施され、その結果障害であれば、障害管理装置７にて障害管理チケットのＯＰＥＮが行われ、障害でなければ切り分け情報のチケットがＯＰＥＮされ、工事の場合には障害対応が必要ないので工事属性のチケットがＯＰＥＮされるという処理が監視システム７の正常な動作手順になっていることを示す。
図１５は、予め監視システム２の各装置が処理を行う内容を有向グラフで分かりやすく説明するためのものである。
監視システム２では、サーバとネットワークでは、監視処理の動作が異なるので、サーバとネットワークで処理が２つ定義してある。
図１５（ａ）に示すように、サーバ障害では、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、障害管理装置７にて障害管理チケットのＯＰＥＮが行われ、工事の場合には障害対応が必要ないので工事属性のチケットがＯＰＥＮされるという処理が監視システム２の正常な動作手順になっていることを示す。
他方、ネットワーク障害では、図１５（ｂ）に示すように、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、どのような障害か本当に障害かを自動的に切り分けるような自動切り分けが実施され、その結果障害であれば、障害管理装置７にて障害管理チケットのＯＰＥＮが行われ、障害でなければ切り分け情報のチケットがＯＰＥＮされ、工事の場合には障害対応が必要ないので工事属性のチケットがＯＰＥＮされるという処理が監視システム７の正常な動作手順になっていることを示す。
図１６は、図１５のような有向グラフをリスト形式に反映するときの説明図である。
図１６（ａ）は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
リストの各要素は１つの装置での処理に該当している。これがリストの先頭からの要素番号で順に処理が進んでいくことを表現する。
さらに分岐処理の場合には、１つの処理の内容にさらにリストを用いて、１番目の要素は処理、２番目の要素は１番目の要素の処理が真の場合、３番目の要素は１番目の要素の処理が偽の場合の処理を表すようにする。
図１５の構成を表したのが、図１６のサーバ用リスト、ネットワーク用リストである。つまり、図１５（ａ）のサーバ障害処理の動作管理表の有向グラフをリスト形式にしたものが、図１６（ｂ）であり、図１５（ｂ）のネットワーク障害処理の動作管理表の有向グラフをリスト形式にしたものが、図１６（ｃ）である。
そして、これら図１６（ｂ）及び（ｃ）に示す情報が、図１４（ａ）に示すように、動作リストとして動作管理表に反映される。
図１６（ａ）は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
リストの各要素は１つの装置での処理に該当している。これがリストの先頭からの要素番号で順に処理が進んでいくことを表現する。
さらに分岐処理の場合には、１つの処理の内容にさらにリストを用いて、１番目の要素は処理、２番目の要素は１番目の要素の処理が真の場合、３番目の要素は１番目の要素の処理が偽の場合の処理を表すようにする。
図１５の構成を表したのが、図１６のサーバ用リスト、ネットワーク用リストである。つまり、図１５（ａ）のサーバ障害処理の動作管理表の有向グラフをリスト形式にしたものが、図１６（ｂ）であり、図１５（ｂ）のネットワーク障害処理の動作管理表の有向グラフをリスト形式にしたものが、図１６（ｃ）である。
そして、これら図１６（ｂ）及び（ｃ）に示す情報が、図１４（ａ）に示すように、動作リストとして動作管理表に反映される。
図１７は監視システムの各装置の処理結果について、図１４の動作管理表に蓄えられた、処理の内容をリスト形式（図１４（ｂ））で表現する方法について説明する。
リストの要素をさらにリストで表現し、そのリストの内容を実行時間（日時）と処理の名称で表現している。これをリストで構成することで、実際に実行した処理の順番をリストの順番で表現している。
図１７（ａ）は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
図１７（ｂ）は、実際に監視システム２のネットワーク監視装置３又はサーバ監視装置４で障害が検知された際の監視システム２の各装置の処理を、図１７（ａ）の定義に従ってリスト形式にした例を示す。
リストの要素をさらにリストで表現し、そのリストの内容を実行時間（日時）と処理の名称で表現している。これをリストで構成することで、実際に実行した処理の順番をリストの順番で表現している。
図１７（ａ）は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
図１７（ｂ）は、実際に監視システム２のネットワーク監視装置３又はサーバ監視装置４で障害が検知された際の監視システム２の各装置の処理を、図１７（ａ）の定義に従ってリスト形式にした例を示す。
ヘルスチェック装置１２におけるシステム動作確認部１５は、図１７のリストの内容を図１６のリストに照らし合わせて処理のマッチングを行うことで、監視システム２において想定された正しい動作手順が実行されたかどうかをヘルスチェックできる。
以上のように、運用監視センターの監視システムにおいて、監視システムが正しく実施しているかどうかを実際の障害アラームの発生の頻度を見ながらヘルスチェック用の擬似障害アラームを発生させるようにしているので、監視システムの正常性を満遍なくチェックすることができる。
さらに、監視システムに投入した擬似障害アラームの処理がうまく処理されない場合には、動作管理表により、どの処理まで実行できたのかが一目でわかるので、処理の滞留状況が管制員に分かりやすくなっており、滞留したアラームについて継続した処理を実施可能である。つまり、異常があった場合には、予め準備しておく障害アラームの処理手順の規定と実際の障害アラームの処理状況のマッチングを比べることで、どの処理フェーズに問題があるのかを自動的に検知し、通報する。
さらに、本マッチングの処理は、通常稼動している監視システムにも適用し、本物の障害アラームについても、正しく処理が実行されているかどうか確認処理を行い、異常があれば検知するものとする。
つまり、上記の説明では、ヘルスチェック装置１２において発生させた擬似障害に対する監視システムの障害検知動作手順が予め規定された適正な動作手順と一致するかどうかを解析・判断していたが、これを監視対象に対する実際の監視に適用し、監視対象において障害が発生した場合の監視システム２の動作手順と予め規定された適正な動作手順とが一致するかどうかを解析・判断するようにしてもよい。
さらに、監視システムに投入した擬似障害アラームの処理がうまく処理されない場合には、動作管理表により、どの処理まで実行できたのかが一目でわかるので、処理の滞留状況が管制員に分かりやすくなっており、滞留したアラームについて継続した処理を実施可能である。つまり、異常があった場合には、予め準備しておく障害アラームの処理手順の規定と実際の障害アラームの処理状況のマッチングを比べることで、どの処理フェーズに問題があるのかを自動的に検知し、通報する。
さらに、本マッチングの処理は、通常稼動している監視システムにも適用し、本物の障害アラームについても、正しく処理が実行されているかどうか確認処理を行い、異常があれば検知するものとする。
つまり、上記の説明では、ヘルスチェック装置１２において発生させた擬似障害に対する監視システムの障害検知動作手順が予め規定された適正な動作手順と一致するかどうかを解析・判断していたが、これを監視対象に対する実際の監視に適用し、監視対象において障害が発生した場合の監視システム２の動作手順と予め規定された適正な動作手順とが一致するかどうかを解析・判断するようにしてもよい。
ここで、本実施の形態に係るヘルスチェック装置１２のハードウェア構成例について説明する。
図１８は、本実施の形態に示すヘルスチェック装置１２のハードウェア資源の一例を示す図である。なお、図１８の構成は、あくまでもヘルスチェック装置１２のハードウェア構成の一例を示すものであり、ヘルスチェック装置１２のハードウェア構成は図１８に記載の構成に限らず、他の構成であってもよい。
図１８は、本実施の形態に示すヘルスチェック装置１２のハードウェア資源の一例を示す図である。なお、図１８の構成は、あくまでもヘルスチェック装置１２のハードウェア構成の一例を示すものであり、ヘルスチェック装置１２のハードウェア構成は図１８に記載の構成に限らず、他の構成であってもよい。
図１８において、ヘルスチェック装置１２は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。
通信ボード９１５は、図１に示すように、ＬＡＮにより監視システム２に接続されている。これ以外に、例えば、通信ボード９１５は、インターネット、ＷＡＮ（ワイドエリアネットワーク）、無線ネットワークなどに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
上記プログラム群９２３には、本実施の形態の説明において「〜部」、「〜手段」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、本実施の形態の説明において、「〜の判断」、「〜の発生」、「〜の比較」、「〜の解析」、「〜の選択」、「〜の設定」、「〜の登録」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態で説明するフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
ファイル群９２４には、本実施の形態の説明において、「〜の判断」、「〜の発生」、「〜の比較」、「〜の解析」、「〜の選択」、「〜の設定」、「〜の登録」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態で説明するフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
また、本実施の形態の説明において「〜部」、「〜手段」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」、「〜手段」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、本実施の形態の「〜部」、「〜手段」としてコンピュータを機能させるものである。あるいは、本実施の形態の「〜部」、「〜手段」の手順や方法をコンピュータに実行させるものである。
このように、本実施の形態に示すヘルスチェック装置１２は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」、「〜手段」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
以上、本実施の形態では、ネットワークを構成する各装置から通知された障害アラームに応じて、個々の装置で発生した障害を管理者に通報するネットワークやサーバ等の障害管理方法やこれに類する障害監視システムにおいて、実際に発生している障害アラームを取得管理する障害確認手段と実際に発生した障害の発生障害分類手段を備え、
前記発生障害分類手段により解析された障害の発生状況に応じて、自動的に様々な擬似障害を発生させる擬似障害発生手段を備え、これにより擬似的な障害を前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムへ障害アラーム検知させるシステム構成を取り、
さらに、前記発生させた擬似障害による障害アラーム検知の障害検知処理が正しく処理されていることを、前もって取り決めたシステム動作管理表の状態と照らし合わせて確認し、前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムの正常動作を確認するシステム動作確認手段を備えるヘルスチェック装置について説明している。
前記発生障害分類手段により解析された障害の発生状況に応じて、自動的に様々な擬似障害を発生させる擬似障害発生手段を備え、これにより擬似的な障害を前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムへ障害アラーム検知させるシステム構成を取り、
さらに、前記発生させた擬似障害による障害アラーム検知の障害検知処理が正しく処理されていることを、前もって取り決めたシステム動作管理表の状態と照らし合わせて確認し、前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムの正常動作を確認するシステム動作確認手段を備えるヘルスチェック装置について説明している。
更に、本実施の形態では、前記発生障害分類手段として、障害記録表に、実際に発生した障害アラームを記録分類して、単位時間に発生していない障害を選び出し、その選び出した障害を前記擬似障害発生手段により発生させるヘルスチェック装置について説明している。
更に、本実施の形態では、前記発生障害分類手段として、障害記録表に、実際に発生した障害アラームを記録分類して、定義された障害の順番でラウンドロビン方式により発生していない障害を選び出し、その選び出した障害を前記擬似障害発生手段により発生させるヘルスチェック装置について説明している。
更に、本実施の形態では、前記擬似障害発生手段として、ネットワーク障害としてネットワークインタフェース機能の動作の起動，終了を一定間隔の間切り替えて擬似ネットワーク障害を創出するヘルスチェック装置について説明している。
更に、本実施の形態では、前記擬似障害発生手段として、サーバ障害として監視している特定プロセスの起動、終了、前記特定プロセスが使用するメモリ、ＣＰＵ使用量、特定のディスクパーティションの使用量を一定間隔の間制御することにより擬似サーバ障害を創出するヘルスチェック装置について説明している。
更に、本実施の形態では、前記システム動作確認手段として、予め監視システムの処理動作を動作管理表に有向グラフなどで定義しておき、前記擬似障害発生手段により発生した障害アラームの処理が処理通りに実行しているかマッチング処理を行なうことで確認し、異常がある場合には、通報するヘルスチェック装置について説明している。
更に、本実施の形態では、前記システム動作確認手段は、擬似的に発生させた障害アラームのみならず、本番運用で発生する本物の障害アラームについても適用して、処理の異常が検知できるヘルスチェック装置について説明している。
更に、本実施の形態では、前記障害確認手段に用いる障害アラームを管理する形式として、障害アラームをネットワークのＰＩＮＧ監視、ＳＮＭＰ Ｔｒａｐ監視、サーバ監視のログ監視、サーバ監視のＣＰＵ使用量監視、サーバ監視のメモリ使用量監視、サーバ監視のディスク使用量監視などで分類管理するヘルスチェック装置について説明している。
更に、本実施の形態では、前記システム動作確認手段に用いる動作確認を管理する形式として監視システムを構成するサブシステムの処理ごとに処理内容のつながりを有向グラフで登録管理するヘルスチェック装置について説明している。
１ 監視センター、２ 監視システム、３ ネットワーク監視装置、４ サーバ監視装置、５ アラーム統合装置、６ 構成情報ＤＢ、７ 障害管理装置、８ 監視モニタ、９ 監視ネットワーク、１０ サーバ、１１ ネットワーク機器、１２ ヘルスチェック装置、１３ 障害確認部、１４ 発生障害分類部、１５ システム動作確認部、１６ 擬似障害発生部、１７ 障害記録表ＤＢ、１８ 動作管理表ＤＢ、１９ 管理装置、２０ 擬似監視装置。
Claims (10)
- コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部と、
前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報を保有し、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報を取得し、前記正常動作手順情報と前記実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析部とを有することを特徴とするヘルスチェック装置。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部とを有し、
前記障害情報管理部は、
複数のシステム障害の情報を管理しており、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、
前記擬似障害発生部は、
前記障害情報管理部が管理する複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させることを特徴とするヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてネットワーク障害を検知し、
前記擬似障害発生部は、
前記監視システムが監視の対象としているネットワークインタフェース機能の動作を停止させて擬似ネットワーク障害を発生させることを特徴とする請求項１又は２に記載のヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてサーバ障害を検知し、
前記擬似障害発生部は、
前記監視システムが監視の対象としている特定プロセスの起動及び終了、前記特定プロセスが使用するメモリ利用率、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）利用率、特定のディスクパーティションの利用率の少なくともいずれかを一定間隔の間制御することにより擬似サーバ障害を発生させることを特徴とする請求項１又は２に記載のヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてネットワーク障害及びサーバ障害を検知し、
前記障害情報管理部は、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を、ネットワーク障害についてのＰＩＮＧ監視結果の情報、ネットワーク障害についてのＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ） Ｔｒａｐ監視結果の情報、サーバ障害についてのログ監視結果の情報、サーバ障害についてのＣＰＵ利用率監視結果の情報、サーバ障害についてのメモリ利用率監視結果の情報、サーバ障害についてのディスク利用率監視結果の情報に分類して管理することを特徴とする請求項１又は２に記載のヘルスチェック装置。 - 前記動作手順解析部は、
前記コンピュータシステムで発生したシステム障害に対して前記監視システムが実施すべきシステム障害正常動作手順を示すシステム障害正常動作手順情報を保有し、前記コンピュータシステムで発生したシステム障害に対して前記監視システムが実際に実施したシステム障害実施動作手順を示すシステム障害実施動作手順情報を取得し、前記システム障害正常動作手順情報と前記システム障害実施動作手順情報とを比較して、前記システム障害に対する前記監視システムのシステム障害実施動作手順を解析することを特徴とする請求項１に記載のヘルスチェック装置。 - コンピュータが、コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック方法であって、
コンピュータが、前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理ステップと、
コンピュータが、前記障害情報管理ステップにより管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生ステップと、
コンピュータが、前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報と、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析ステップとを有することを特徴とするヘルスチェック方法。 - コンピュータが、コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック方法であって、
コンピュータが、前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理ステップと、
コンピュータが、前記障害情報管理ステップにより管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生ステップとを有し、
前記障害情報管理ステップでは、
コンピュータは、
複数のシステム障害の情報を管理しており、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、
前記擬似障害発生ステップでは、
コンピュータは、前記障害情報管理ステップにおいて管理される複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させることを特徴とするヘルスチェック方法。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うコンピュータに、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理処理と、
前記障害情報管理処理により管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生処理と、
前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報と、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析処理とを実行させることを特徴とするプログラム。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うコンピュータに、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理処理と、
前記障害情報管理処理により管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生処理とを実行させるプログラムであって、
前記障害情報管理処理では、
コンピュータに、
複数のシステム障害の情報を管理させ、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理させ、
前記擬似障害発生処理では、
コンピュータに、前記障害情報管理処理において管理される複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択させ、選択させたシステム障害に対応する擬似障害を発生させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007015685A JP4850733B2 (ja) | 2007-01-26 | 2007-01-26 | ヘルスチェック装置及びヘルスチェック方法及びプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007015685A JP4850733B2 (ja) | 2007-01-26 | 2007-01-26 | ヘルスチェック装置及びヘルスチェック方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008181432A JP2008181432A (ja) | 2008-08-07 |
| JP4850733B2 true JP4850733B2 (ja) | 2012-01-11 |
Family
ID=39725272
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007015685A Expired - Fee Related JP4850733B2 (ja) | 2007-01-26 | 2007-01-26 | ヘルスチェック装置及びヘルスチェック方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4850733B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4937235B2 (ja) * | 2008-11-21 | 2012-05-23 | 株式会社東芝 | 遠隔監視システム及び故障分離方法 |
| JP5267109B2 (ja) * | 2008-12-24 | 2013-08-21 | 日本電気株式会社 | 障害発見システム検証装置、障害発見システム検証方法及び障害発見システム検証制御プログラム |
| CN109544868B (zh) * | 2018-09-28 | 2021-04-27 | 广州智伴人工智能科技有限公司 | 一种自动报警提醒系统 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03269645A (ja) * | 1990-03-19 | 1991-12-02 | Nec Corp | サービスプロセッサ |
| JPH08190499A (ja) * | 1995-01-05 | 1996-07-23 | Fujitsu Ltd | 遠隔監視システム |
| JP2002351755A (ja) * | 2001-05-24 | 2002-12-06 | Hitachi Ltd | 障害発生装置およびコンピュータシステムの試験方法 |
| JP4189854B2 (ja) * | 2003-07-28 | 2008-12-03 | 新日鉄ソリューションズ株式会社 | 障害時動作検証装置及び障害時動作検証方法 |
-
2007
- 2007-01-26 JP JP2007015685A patent/JP4850733B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2008181432A (ja) | 2008-08-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8024617B2 (en) | Method and apparatus for cause analysis involving configuration changes | |
| CN105518629B (zh) | 云部署基础结构确认引擎 | |
| US8429463B2 (en) | Log management method and apparatus, information processing apparatus with log management apparatus and storage medium | |
| US20190268214A1 (en) | Predicting issues before occurrence, detection, or reporting of the issues | |
| US20110314138A1 (en) | Method and apparatus for cause analysis configuration change | |
| JP5223413B2 (ja) | Ｉｔシステムのトラブル対処装置、トラブル対処方法およびそのためのプログラム | |
| US20160378583A1 (en) | Management computer and method for evaluating performance threshold value | |
| JP6085550B2 (ja) | ログ分析装置及び方法 | |
| JP7423942B2 (ja) | 情報処理システム | |
| JP2007241872A (ja) | ネットワーク上のコンピュータ資源の変更監視プログラム | |
| CN116755992B (zh) | 一种基于OpenStack云计算的日志分析方法及系统 | |
| US8438422B2 (en) | Failure response support apparatus and failure response support method | |
| US8601318B2 (en) | Method, apparatus and computer program product for rule-based directed problem resolution for servers with scalable proactive monitoring | |
| CN113708986A (zh) | 服务器监控装置、方法及计算机可读存储介质 | |
| CN117422434A (zh) | 一种智慧运维调度平台 | |
| JP4850733B2 (ja) | ヘルスチェック装置及びヘルスチェック方法及びプログラム | |
| JP5012999B2 (ja) | 保守業務支援プログラム、保守業務支援方法および保守業務支援装置 | |
| US20050283348A1 (en) | Serviceability framework for an autonomic data centre | |
| JP2007241873A (ja) | ネットワーク上のコンピュータ資源の変更監視プログラム | |
| JP2000187585A (ja) | 遠隔障害情報管理装置並びにその方法 | |
| JP4575020B2 (ja) | 障害解析装置 | |
| CN115408271A (zh) | 一站式闭环测试方法、系统、设备及介质 | |
| JP2010009127A (ja) | 管理プログラムおよび管理装置 | |
| CN115102838A (zh) | 服务器宕机风险的应急处理方法和装置、电子设备 | |
| JP4021874B2 (ja) | 障害管理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20091006 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110302 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110913 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110929 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111018 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111019 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141028 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |