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
ネットワークやサーバの正常性を監視する監視システムにおいても、同様に、障害監視を行う監視装置に対して、障害アラームを発生させるトリガを発生させることにより、監視システムを動作させ、テスト用の障害を検知して表示させることや、予め設定したテスト用のメールアドレスなどを利用し通報を行うことで、監視システムの正常性確認を行うヘルスチェックを行える。
監視システムは大規模化の傾向があり、数十台のサーバや百台以上のネットワーク機器からシステム構築されており、監視システム自身の正常性確認が課題である。
また、監視システムが異常な状態でもオペレータは、検出した障害アラーム対応を行う必要があり、異常が発生した際に処理途中であった障害アラームに迅速に対応する必要があるが、オペレータは通常監視システムの構成には精通していないので、迅速な対応が困難であった。
つまり、監視システムで検知する障害は、例えば、ネットワーク障害及びサーバ障害があるが、ネットワーク障害においても複数種類の障害形式があり、サーバ障害においても複数種類の障害形式があり、監視システムのヘルスチェックを有効に行うためには、それぞれの障害形式に対応させた入力データを監視システムに入力する必要がある。
また、監視システムに対するヘルスチェックにおいて監視システムが行った一連の動作の適否を確認するとともに、適正でない場合に一連の動作のうちのどの箇所で適正な対応ができなかったのかを解析する必要があるが、従来はこのような解析手段が存在していなかった。
コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記監視システムによる監視の対象となり、前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部とを有することを特徴とする。
従来のヘルスチェック装置は、入力パターンが複数あるような場合には対応できておらず、正常性確認の入力が複数ある場合に、自動的にどのような入力を行えば正常性を網羅的に確認できるか、入力を行った場合に、正常な場合には出力が得られるのでこれにより正常性を確認していたが、異常があった場合には、どの処理で異常があったのかを自動的に検知することができないという課題があった。
本実施の形態では、上記のような課題を解決することを主な目的としており、入力データについて、複数の入力データを実際に対象が処理している実績を管理し、処理が現時点から遡って動作していないものを自動的に選択して入力とし処理が定期的に動作するようにし、また、入力したデータについて出力が行なわれない異常時には、予め処理動作を規定した内容と実際の処理状況を比べることで、どの処理に問題があるのかを自動的に検知し通報する。
図1において、監視センター1は、運用監視サービスを提供する。
監視システム2は、監視対象(コンピュータシステム)の運用監視サービスを実現する。
ネットワーク監視装置3は、監視システム2において、監視対象(コンピュータシステム)のネットワークの状態を監視する。ネットワーク監視装置3は、N/W監視装置とも表記する。
サーバ監視装置4は、監視システム2において、監視対象(コンピュータシステム)内のサーバ等のコンピュータの状態を監視する。
アラーム統合装置5は、ネットワーク監視とサーバ監視のアラームを統合する。
構成情報データベース6は監視対象の情報を記録している。
障害管理装置7は、障害アラームの記録と管理を行う。
監視モニタ8は、監視を行うオペレータが使用する。
監視ネットワーク9は、監視システム2が監視を行うためのネットワークである。
サーバ10は、監視システム2の監視対象となるコンピュータシステムに含まれているコンピュータである。
ネットワーク機器11は、監視システム2の監視対象となるコンピュータシステムに含まれているルータ等のネットワーク機器である。
ヘルスチェック装置12は、監視システム2のヘルスチェックを行う。
管理装置19には、障害確認部13、発生障害分類部14、システム動作確認部15、障害記録表DB(データベース)17、動作管理表DB(データベース)18が含まれる。
擬似監視装置20には、擬似障害発生部16が含まれる。
障害確認部13、発生障害分類部14及び障害記録表DB17は、障害情報管理部の例であり、システム動作確認部15及び動作管理表DB18は、動作手順解析部の例である。
なお、図1では、ヘルスチェック装置12は、管理装置19と擬似監視装置20に分かれている、一つのコンピュータ装置でこれらを実現してもよいし、二つ以上のコンピュータ装置で実現してもよい。
障害情報管理部は、監視システム2が監視対象(コンピュータシステム)に対する監視において検知した監視対象のシステム障害の情報を管理する。
擬似障害発生部16は、監視システム2と接続されており、監視システム2による障害監視の対象となる。そして、擬似障害発生部16は、障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、擬似障害を監視システムの検知の対象とさせる。
また、障害情報管理部は、複数のシステム障害の情報を管理しており、それぞれのシステム障害に対して、監視システム2が監視対象に対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、擬似障害発生部16は、複数のシステム障害の中から障害検知時刻に基づいて特定のシステム障害を選択する。例えば、障害情報管理部が管理する複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させる。
また、監視システム2は、監視対象におけるシステム障害としてサーバ障害を検知することが可能であり、擬似障害発生部16は、このサーバ障害検知に対するヘルスチェックとして、監視システム2が監視の対象としている特定プロセスの起動及び終了、特定プロセスが使用するメモリ利用率、CPU(Central Processing Unit)利用率、特定のディスクパーティションの利用率の少なくともいずれかを一定間隔の間制御することにより擬似サーバ障害を発生させる。
また、動作手順解析部は、監視対象で発生したシステム障害(擬似障害ではなく、実際の障害)に対して監視システムが実施すべきシステム障害正常動作手順を示す動作管理表(システム障害正常動作手順情報)も保有し、監視対象で発生したシステム障害に対して監視システム2が実際に実施したシステム障害実施動作手順を示す情報(システム障害実施動作手順情報)を取得し、動作管理表(システム障害正常動作手順情報)と取得した情報(システム障害実施動作手順情報)とを比較して、システム障害に対する監視システム2のシステム障害実施動作手順を解析することも可能である。
監視センター1は、ネットワークやサーバの運用監視を委託される運用監視会社などの統合的な監視センターであり、多数のネットワークの状態やサーバの死活などを遠隔から監視する。
実際の監視は監視システム2で実現されており、ネットワークの監視はネットワーク監視装置3によって定期的にルータ等の監視対象のネットワーク機器11に監視ネットワーク9を通じてPINGを用いて監視を行っている。
サーバ監視装置4も同様に監視対象のサーバ10の死活監視、プロセス管理、ログ監視、CPU利用率監視、メモリ利用率監視、ディスクの利用率監視などを行っている。
サーバ監視装置4の場合には、監視対象のサーバ10にサーバ監視装置4のエージェントが導入されており、これによってサーバの各種監視が行われている。
アラーム統合装置5では、送付された障害アラームがどのような顧客のどのような構成の機器であるかを調べるために、予め構成情報データベース6にこれらの記録が管理されているので、その情報を監視対象のIPアドレスやホスト名などを利用して参照し、人間に分かりやすい情報をつくり、監視モニタ8に障害情報を統合一覧表示して障害発生をオペレータに知らせる。
次に、アラーム統合装置5は、この障害アラーム情報をログに保存し、その後、障害管理装置7にも障害発生を送信して、障害管理チケットを起票し、管制員はこの障害管理チケットにより障害対応を実施する。
ヘルスチェック装置12は、前述したように、管理装置19と擬似監視装置20から構成され、監視システム2とはLAN(Local Area Network)によって接続され、データの交換が可能なように設置する。
さらに、擬似監視装置20は、2つ以上のネットワークインタフェースを持ち、1つは管理装置19との通信、1つは監視システム2からの監視に使用する。
また、ネットワーク監視装置3には、擬似監視装置20のネットワークのアドレスを監視するように設定を行い、サーバ監視装置4の監視設定も擬似監視装置20に対して行い、例えば擬似監視装置20にサーバ監視装置4のエージェントを導入することで、擬似監視装置20のログ監視、プロセス監視、CPU利用量の閾値監視、メモリの使用量の閾値監視、ディスクの使用量の閾値監視の設定を行う。このように、擬似監視装置20は、ネットワーク監視装置3及びサーバ監視装置4の監視対象となり、擬似障害発生部16が擬似障害を発生させた場合に、ネットワーク監視装置3及びサーバ監視装置4により擬似障害が検知されるように設定しておく。
また、事前に擬似監視装置20のネットワーク監視やサーバ監視が実行できることを確認しておく。
また、ヘルスチェック装置12の設置は本番の監視環境に設置して、監視システム2はサービスとしてのネットワーク監視とサーバ監視と同様に擬似監視装置20に対する監視を実施する。
図2は、図1の障害情報管理部、特に障害確認部の動作例(障害情報管理ステップ)を示すフローチャートである。
ステップS1では、障害確認部13が、ネットワーク監視装置3に新たな障害アラームがあるかどうかを確認する。これはネットワーク監視装置3の管理しているデータを確認することで新たな障害アラームが発生したかどうかを確認する。
次にステップS2において、障害確認部13は、障害アラームが発生したかどうかを判定する。
障害アラームが発生していなければ、ステップS4において、障害確認部13は、サーバ監視装置4のアラームをネットワーク監視装置3と同様にサーバ監視装置4の管理するデータを確認することで実施する。
ステップS5でアラームが発生していなければ、障害確認部13は、新規の障害アラームはないと判断して一定時間の本プロセスをスリープさせ、定期的に障害アラームの確認を行うようにする。
一定時間とはネットワーク監視装置とサーバ監視装置の障害検知の周期に合わせる必要があるが、通常は1分から10分程度のスリープ時間を設定する。
ステップS2やステップS5で新規の障害アラームが検知された場合には、ステップS3にて障害アラームを障害記録表DB17の障害記録表に記入する。障害記録表とは、監視システム2で発生した障害を記録する表である。
21はアラームのメッセージを格納するエリア、22は擬似障害発生部16に擬似障害を発生させるための識別種別の格納エリア、23は該当する障害アラームの発生回数、24は該当する障害アラームの最終発生日時を格納するエリア、25は該当する擬似障害を発生させた回数の累計を格納するエリア、26は現在擬似障害を発生させている場合に実施中であることを示すフラグを格納するエリアである。
最終発生日時は、監視対象において実際に発生した障害の最終発生日時又は擬似障害発生部16において擬似障害を発生させた場合の当該擬似障害の最終発生日時である。なお、図3では、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別していないが、これら2つを区別して管理するようにしてもよい。
ステップS7では、発生障害分類部14は、図3で示した障害記録表を入力し、メモリ上に展開する。
ステップ8では、発生障害分類部14は、障害記録表のレコードを1レコードずつ確認し、選択中フラグがどの障害アラームにも1が記録されていないことを判定する。
もし、選択中フラグに1の記録があれば、これは現在擬似障害の発生中であるので、発生障害分類部14は、ステップS9にて一定時間スリープをして再度ステップS7に戻る。
選択中フラグがすべて0であれば、擬似障害が発生していないとみなし、発生障害分類部14は、擬似障害を発生させるアラーム形式を選択するためのステップS10以降を実施する。
ステップS10では、発生障害分類部14は、障害記録表の中から最終発生日時の一番古い障害アラームを選択する。実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理している場合は、2つの最終発生日時のうち新しい方の最終発生日時が他の障害アラームの最終発生日時と比べて最も古いかどうかを判定して選択する。
次に、ステップS11にて、発生障害分類部14は、選択した障害アラームの選択回数に1を加算する。
ステップS12にて、発生障害分類部14は、該当する障害アラームの選択中フラグに1を設定し、ステップS13にて選択した障害アラームの種別番号を擬似障害発生部16に送信し、擬似障害を発生させ、待機し、擬似障害発生部16の処理が終了したとの通知があった際に、ステップS14にて、該当する選択中フラグを0に戻す。
また、図4では図示していないが、発生障害分類部14は、擬似障害発生部16の処理が終了したとの通知があった際に、障害記録表の対応する障害アラームの最終発生日時を更新する。なお、実際の障害の最終発生日時と擬似障害の最終発生日時とを区別して管理する場合は、実際の障害の最終発生日時はそのままとし、擬似障害の最終発生日時を更新する。
また、図4のステップS10の処理の後に、ステップS10で選択された最も古いアラームの最終発生日時が一定時間以上前の日時であるかどうかを確認する処理を追加し、一定時間以上前の日時である場合にはステップS11以降の処理を実施し、一定時間以上前の日時でない場合には処理を終了するようにしてもよい。
これは、図4の発生障害分類部14によって選択された該当障害アラームを擬似的に発生させるアルゴリズムである。
図5では、ステップS15、ステップS17、ステップS19、ステップS21、ステップS23、ステップS25、ステップS27の判定にて、図4に示す処理にて発生障害分類部14から送信された障害アラームの種別番号を判定して、該当する擬似障害を発生するステップS16、ステップS18、ステップS20、ステップS22、ステップS24、ステップS26、ステップS28のサブルーチンを呼び出し実行する構成である。
図6は、図3の種別22の1に該当しており、PING ERRORに相当する擬似障害を発生させる仕組みである。
ステップS30では、ネットワーク監視装置3がステップS29の動作によりネットワーク機能がダウンしたことを検知するまで待機時間があるため、擬似障害発生部16は、一定間隔時間このプロセス自体をスリープさせる。
一般的にネットワーク監視装置3のPINGによる検知間隔は1分から5分程度であるので、スリープする時間の目安はこの検知間隔プラス1分程度の時間となる。
ステップS31では、この時点でネットワーク監視装置3がネットワークの異常を検知しているはずなので、擬似障害発生部16は擬似監視装置20のダウンさせたネットワークインタフェースを再起動させ、もとの状態に戻す。
なお、ネットワーク監視装置3がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置3が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS31の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置3では、障害を検知したネットワークインタフェースカードが擬似監視装置20のネットワークインタフェースカードであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の2に該当しており、SNMP TRAP IF DOWNに相当する擬似障害を発生させる仕組みである。
ステップS32は図1の擬似監視装置20からSNMP TRAPを図1のネットワーク監視装置3に発生させるステップである。
SNMP TRAPは投げ捨てのデータであるので、これをネットワーク監視装置3で検知する。
なお、ネットワーク監視装置3がネットワークの擬似障害を検知したかどうかは、監視対象における異常をネットワーク監視装置3が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS32の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、ネットワーク監視装置3では、検知したSNMP TRAPが擬似監視装置20のものであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の3に該当しており、SERVER ERRORプロセスに相当する擬似障害を発生させる仕組みである。
ステップS33では、擬似障害発生部16は、擬似監視装置20上で予め動作させている監視用のプロセスをダウンさせる。この監視用のプロセスは、サーバ監視装置4の監視対象となっているプロセスである。
ステップS34では、サーバ監視装置4がステップS33の動作により監視用のプロセスがダウンしたことを検知するまで、待機時間があるため、擬似障害発生部16は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置4の検知間隔は5分から15分程度であるので、スリープする時間の目安はこの検知間隔プラス1分程度の時間となる。
ステップS35では、この時点でサーバ監視装置4がプロセスの異常を検知しているはずなので、擬似障害発生部16は、擬似監視装置20のダウンさせた監視プロセスを再起動させ、もとの状態に戻す。
なお、サーバ監視装置4が監視プロセスの擬似ダウンを検知したかどうかは、監視対象における異常をサーバ監視装置4が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS35の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置4では、障害を検知した監視プロセスが擬似監視装置20上で稼働している監視プロセスであることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の4に該当しており、SERVER ERROR CPUに相当する擬似障害を発生させる仕組みである。
ステップS36は、擬似監視装置20のCPU負荷を高めるために、加算ループを行うための変数Iの初期化ステップである。
ステップS37は、実際の変数Iへの加算ステップである。
ステップS38は、加算を終了させる上限の値との判定ステップである。
このように、擬似障害発生部16は、加算のみを大量に実行することで擬似監視装置20のCPU利用率を向上させ、サーバ監視装置4でCPU利用率の閾値監視アラームを発生させる。
なお、サーバ監視装置4が擬似監視装置20におけるCPU利用率が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置4が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS38の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置4では、閾値を超えたCPU利用率が擬似監視装置20におけるCPU利用率であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の5に該当しており、SERVER ERROR MEMORYに相当する擬似障害を発生させる仕組みである。
ステップS39では、擬似障害発生部16は、擬似監視装置20のメモリ利用率を高めるために、メモリアロケート命令により、サーバ監視装置4において閾値監視が発動される量のメモリを取得する。
ステップS40では、サーバ監視装置4がステップS39の動作によりメモリ使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部16は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置4の検知間隔は5分から15分程度であるので、スリープする時間の目安はこの検知間隔プラス1分程度の時間となる。
ステップS41では、この時点でサーバ監視装置4がメモリ使用量の異常(擬似監視装置20におけるメモリ使用量が閾値を超えている)を検知しているはずなので、擬似障害発生部16は、ステップS40で取得したメモリをすべて開放し、もとの状態に戻す。
サーバ監視装置4が擬似監視装置20におけるメモリ使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置4が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS41の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置4では、閾値を超えたメモリ使用量が擬似監視装置20におけるメモリ使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の6に該当しており、SERVER ERROR DISKに相当する擬似障害アラームを発生させる仕組みである。
ステップS42では、擬似障害発生部16は擬似監視装置20のディスク利用率を高めるために、CREATEFILE命令により、予め決めておいたディスクパーティションに対してファイルを1つ作成する。
ステップS43では、擬似障害発生部16は、ステップS42で作成したファイルに対して、サーバ監視装置4が規定するディスク閾値を越えるデータ量をWRITE命令で記述する。
ステップS44では、擬似障害発生部16は、作成したファイルをCLOSEすることで、ディスクパーティションの使用量を増加させる。
ステップS45では、サーバ監視装置4がステップS44の動作によりディスク使用量が増加したことを検知するまで、待機時間があるため、擬似障害発生部16は、一定間隔時間このプロセス自体をスリープさせる。
一般的にサーバ監視装置4の検知間隔は5分から15分程度であるので、スリープする時間の目安はこの検知間隔プラス1分程度の時間となる。
ステップS46では、この時点でサーバ監視装置4がディスク使用量の異常(擬似監視装置20におけるディスク使用量が閾値を超えている)を検知しているはずなので、擬似障害発生部16は、ステップS42で作成したファイルをすべて削除し、もとの状態に戻す。
なお、サーバ監視装置4が擬似監視装置20におけるディスク使用量が閾値を超えたことを検知したかどうかは、監視対象における異常をサーバ監視装置4が検知した場合と同様の手順で判断することができる。すなわち、障害確認部13が、図2に示す手順と同様の手順により、新たな障害アラームとして擬似障害に対する障害アラームを受信することで判断可能である。このため、ステップS46の時点では、ヘルスチェック装置12は擬似障害が検知されたかどうかは認識していない。
なお、サーバ監視装置4では、閾値を超えたディスク使用量が擬似監視装置20におけるディスク使用量であることを識別可能であり、このため、検知した障害はヘルスチェックのための擬似障害であることを認識することができる。
図3の種別22の7に該当しており、SERVER ERROR LOGに相当する擬似障害を発生させる仕組みである。
ステップS47は、擬似監視装置20に予め用意されたログファイルの内容の監視に対して、監視に該当するレコードを記述するためのログファイルOPEN命令である。
ステップS48は、該当するログファイルへのWRITE命令である。
ステップS49は、OPENしたファイルのCLOSE命令であり、これにより、ログファイルにテスト用の監視ログレコードが出力される。
そこで、本実施の形態では、入力となる障害アラームを満遍なく発生させるために、障害アラームの処理状況を管理し、最近発生していない障害アラームの形式を強制的に発生させることで監視システムの正常性を確認している。
また、ネットワーク障害及びサーバ障害をそれぞれ複数種類の障害形式に分類し、それぞれの障害形式における最終発生日時を管理し、最も長期にわたって発生していない障害を擬似障害として優先して発生させるようにしている。
図13は、図1の管理装置19で動作するシステム動作確認部15の動作フローチャートである。
ステップS50では、システム動作確認部15は、図14で説明する動作管理表の読み込みを行う。
図14(a)及び(b)に示すように、動作管理表には2つの表が用意されている。
1つ(図14(a))は予め動作を規定した有向グラフをリスト形式(文字列で表現)したものであり、27はアラーム種別、28は動作リストである。
もうひとつ(図14(b))は各システムの障害アラームに対応する処理の履歴(ログ)であり、各システムが生成したものを何らかの方法で集めてきたものである。
29はアラームID、30は処理の日時、31は実行した動作である。
また、図14(b)の表は、監視システム2を構成する各装置、ここでは、図1のネットワーク監視装置3、サーバ監視装置4、アラーム統合装置5、構成情報DB6、障害管理装置7を対象に処理状況のログをネットワーク監視装置3又はサーバ監視装置4が付加するアラームIDを通し番号にした情報である。
図14(a)の情報は、ネットワーク監視装置3又はサーバ監視装置4が擬似障害を検知した際に擬似障害に対して監視システム2が実施すべき正常動作手順をサーバ障害、ネットワーク障害に分類して示す情報(正常動作手順情報)である。なお、動作リストの具体的内容については、後述する。
また、図14(b)の情報は、ヘルスチェック装置12が、監視システム2から取得した情報であり、擬似障害に対してネットワーク監視装置3又はサーバ監視装置4が実際に実施した実施動作手順を示す情報(実施動作手順情報)である。例えば、アラームID:0001は、ネットワーク監視装置3により検知されたネットワークに関する擬似障害に対して監視システム2が実際に実施した動作手順を示しており、ネットワーク障害アラーム検知(一行目)の後、構成情報参照が行われ(二行目)、その後工事チェックが行われた(三行目)ことが示されている。
ステップS52では、システム動作確認部15は、監視システム2における動作手順が正しく実行されたのか、正しく実行されなかったかの判定が行なわれていない未処理のアラームIDについて処理を行うため、動作管理表に登録されたデータ(図14(a)のデータ及び図14(b)のソート後のデータ)をメモリ上でリスト形式に変換する処理を行う。
ステップS53では、システム動作確認部15は、ネットワーク障害アラームかサーバ障害アラームかを判定して、該当する動作管理表(図14(a))のサーバかネットワークどちらかを選択する。
ステップS54では、システム動作確認部15は、ステップS53で選択した予め設定された処理の有向グラフを表現するリストと、アラーム処理を行った過程で採取された各システムのアラームごとの処理内容を1つずつリストの要素について処理を確認することでマッチングを行う。
ステップS55にて、システム動作確認部15は、マッチングがされていれば、ステップS56で比較しているアラーム側の処理リストが終端に至ったかどうかを判定し、終端であれば、ステップS57にて正常の判定を下し、正常終了する。
ステップS56にて、リストが終端でなければ、リストの要素を1つ進めて次の要素の確認を同じようにステップS54からステップS55にて行う。
ステップS55の処理でマッチングが失敗した場合には、システム動作確認部15は、監視システム2における動作手順が想定されたとおりに実行されていないと判断し、ステップS58にて異常処理を行い、管理者に異常を通報するなどの処理を行い終了する。
また、システム動作確認部15は、アラームIDの処理が終了したものについては、動作管理表から削除する。
図15は、予め監視システム2の各装置が処理を行う内容を有向グラフで分かりやすく説明するためのものである。
監視システム2では、サーバとネットワークでは、監視処理の動作が異なるので、サーバとネットワークで処理が2つ定義してある。
図15(a)に示すように、サーバ障害では、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、障害管理装置7にて障害管理チケットのOPENが行われ、工事の場合には障害対応が必要ないので工事属性のチケットがOPENされるという処理が監視システム2の正常な動作手順になっていることを示す。
他方、ネットワーク障害では、図15(b)に示すように、障害アラーム検出、構成情報の参照、障害アラームのデータベースへの記録、拠点工事などの場合に障害アラームをフィルタリングするための工事情報のチェック、工事でなければ障害なので、どのような障害か本当に障害かを自動的に切り分けるような自動切り分けが実施され、その結果障害であれば、障害管理装置7にて障害管理チケットのOPENが行われ、障害でなければ切り分け情報のチケットがOPENされ、工事の場合には障害対応が必要ないので工事属性のチケットがOPENされるという処理が監視システム7の正常な動作手順になっていることを示す。
図16(a)は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
リストの各要素は1つの装置での処理に該当している。これがリストの先頭からの要素番号で順に処理が進んでいくことを表現する。
さらに分岐処理の場合には、1つの処理の内容にさらにリストを用いて、1番目の要素は処理、2番目の要素は1番目の要素の処理が真の場合、3番目の要素は1番目の要素の処理が偽の場合の処理を表すようにする。
図15の構成を表したのが、図16のサーバ用リスト、ネットワーク用リストである。つまり、図15(a)のサーバ障害処理の動作管理表の有向グラフをリスト形式にしたものが、図16(b)であり、図15(b)のネットワーク障害処理の動作管理表の有向グラフをリスト形式にしたものが、図16(c)である。
そして、これら図16(b)及び(c)に示す情報が、図14(a)に示すように、動作リストとして動作管理表に反映される。
リストの要素をさらにリストで表現し、そのリストの内容を実行時間(日時)と処理の名称で表現している。これをリストで構成することで、実際に実行した処理の順番をリストの順番で表現している。
図17(a)は、リスト形式にて処理を表示する際の一般的な定義形式を示している。
図17(b)は、実際に監視システム2のネットワーク監視装置3又はサーバ監視装置4で障害が検知された際の監視システム2の各装置の処理を、図17(a)の定義に従ってリスト形式にした例を示す。
さらに、監視システムに投入した擬似障害アラームの処理がうまく処理されない場合には、動作管理表により、どの処理まで実行できたのかが一目でわかるので、処理の滞留状況が管制員に分かりやすくなっており、滞留したアラームについて継続した処理を実施可能である。つまり、異常があった場合には、予め準備しておく障害アラームの処理手順の規定と実際の障害アラームの処理状況のマッチングを比べることで、どの処理フェーズに問題があるのかを自動的に検知し、通報する。
さらに、本マッチングの処理は、通常稼動している監視システムにも適用し、本物の障害アラームについても、正しく処理が実行されているかどうか確認処理を行い、異常があれば検知するものとする。
つまり、上記の説明では、ヘルスチェック装置12において発生させた擬似障害に対する監視システムの障害検知動作手順が予め規定された適正な動作手順と一致するかどうかを解析・判断していたが、これを監視対象に対する実際の監視に適用し、監視対象において障害が発生した場合の監視システム2の動作手順と予め規定された適正な動作手順とが一致するかどうかを解析・判断するようにしてもよい。
図18は、本実施の形態に示すヘルスチェック装置12のハードウェア資源の一例を示す図である。なお、図18の構成は、あくまでもヘルスチェック装置12のハードウェア構成の一例を示すものであり、ヘルスチェック装置12のハードウェア構成は図18に記載の構成に限らず、他の構成であってもよい。
RAM914は、揮発性メモリの一例である。ROM913、FDD904、CDD905、磁気ディスク装置920の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード915、キーボード902、スキャナ装置907、FDD904などは、入力部、入力装置の一例である。
また、通信ボード915、表示装置901、プリンタ装置906などは、出力部、出力装置の一例である。
磁気ディスク装置920には、オペレーティングシステム921(OS)、ウィンドウシステム922、プログラム群923、ファイル群924が記憶されている。プログラム群923のプログラムは、CPU911、オペレーティングシステム921、ウィンドウシステム922により実行される。
ファイル群924には、本実施の形態の説明において、「〜の判断」、「〜の発生」、「〜の比較」、「〜の解析」、「〜の選択」、「〜の設定」、「〜の登録」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してCPU911によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのCPUの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のCPUの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、本実施の形態で説明するフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、RAM914のメモリ、FDD904のフレキシブルディスク、CDD905のコンパクトディスク、磁気ディスク装置920の磁気ディスク、その他光ディスク、ミニディスク、DVD等の記録媒体に記録される。また、データや信号は、バス912や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
前記発生障害分類手段により解析された障害の発生状況に応じて、自動的に様々な擬似障害を発生させる擬似障害発生手段を備え、これにより擬似的な障害を前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムへ障害アラーム検知させるシステム構成を取り、
さらに、前記発生させた擬似障害による障害アラーム検知の障害検知処理が正しく処理されていることを、前もって取り決めたシステム動作管理表の状態と照らし合わせて確認し、前記ネットワークやサーバ等の障害管理方法やこれに類する障害監視システムの正常動作を確認するシステム動作確認手段を備えるヘルスチェック装置について説明している。
Claims (10)
- コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部と、
前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報を保有し、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報を取得し、前記正常動作手順情報と前記実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析部とを有することを特徴とするヘルスチェック装置。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック装置であって、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理部と、
前記障害情報管理部が管理するシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生部とを有し、
前記障害情報管理部は、
複数のシステム障害の情報を管理しており、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、
前記擬似障害発生部は、
前記障害情報管理部が管理する複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させることを特徴とするヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてネットワーク障害を検知し、
前記擬似障害発生部は、
前記監視システムが監視の対象としているネットワークインタフェース機能の動作を停止させて擬似ネットワーク障害を発生させることを特徴とする請求項1又は2に記載のヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてサーバ障害を検知し、
前記擬似障害発生部は、
前記監視システムが監視の対象としている特定プロセスの起動及び終了、前記特定プロセスが使用するメモリ利用率、CPU(Central Processing Unit)利用率、特定のディスクパーティションの利用率の少なくともいずれかを一定間隔の間制御することにより擬似サーバ障害を発生させることを特徴とする請求項1又は2に記載のヘルスチェック装置。 - 前記監視システムは、前記コンピュータシステムにおけるシステム障害としてネットワーク障害及びサーバ障害を検知し、
前記障害情報管理部は、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を、ネットワーク障害についてのPING監視結果の情報、ネットワーク障害についてのSNMP(Simple Network Management Protocol) Trap監視結果の情報、サーバ障害についてのログ監視結果の情報、サーバ障害についてのCPU利用率監視結果の情報、サーバ障害についてのメモリ利用率監視結果の情報、サーバ障害についてのディスク利用率監視結果の情報に分類して管理することを特徴とする請求項1又は2に記載のヘルスチェック装置。 - 前記動作手順解析部は、
前記コンピュータシステムで発生したシステム障害に対して前記監視システムが実施すべきシステム障害正常動作手順を示すシステム障害正常動作手順情報を保有し、前記コンピュータシステムで発生したシステム障害に対して前記監視システムが実際に実施したシステム障害実施動作手順を示すシステム障害実施動作手順情報を取得し、前記システム障害正常動作手順情報と前記システム障害実施動作手順情報とを比較して、前記システム障害に対する前記監視システムのシステム障害実施動作手順を解析することを特徴とする請求項1に記載のヘルスチェック装置。 - コンピュータが、コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック方法であって、
コンピュータが、前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理ステップと、
コンピュータが、前記障害情報管理ステップにより管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生ステップと、
コンピュータが、前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報と、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析ステップとを有することを特徴とするヘルスチェック方法。 - コンピュータが、コンピュータシステムの監視を行う監視システムのヘルスチェックを行うヘルスチェック方法であって、
コンピュータが、前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理ステップと、
コンピュータが、前記障害情報管理ステップにより管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生ステップとを有し、
前記障害情報管理ステップでは、
コンピュータは、
複数のシステム障害の情報を管理しており、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理し、
前記擬似障害発生ステップでは、
コンピュータは、前記障害情報管理ステップにおいて管理される複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択し、選択したシステム障害に対応する擬似障害を発生させることを特徴とするヘルスチェック方法。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うコンピュータに、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理処理と、
前記障害情報管理処理により管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生処理と、
前記擬似障害に対して前記監視システムが実施すべき正常動作手順を示す正常動作手順情報と、前記擬似障害に対して前記監視システムが実際に実施した実施動作手順を示す実施動作手順情報とを比較して、前記擬似障害に対する前記監視システムの実施動作手順を解析する動作手順解析処理とを実行させることを特徴とするプログラム。 - コンピュータシステムの監視を行う監視システムのヘルスチェックを行うコンピュータに、
前記監視システムが前記コンピュータシステムに対する監視において検知した前記コンピュータシステムのシステム障害の情報を管理する障害情報管理処理と、
前記障害情報管理処理により管理されているシステム障害の情報に基づき、システム障害に対応する擬似障害を発生させて、前記擬似障害を前記監視システムの検知の対象とさせる擬似障害発生処理とを実行させるプログラムであって、
前記障害情報管理処理では、
コンピュータに、
複数のシステム障害の情報を管理させ、
それぞれのシステム障害に対して、前記監視システムが前記コンピュータシステムに対する監視においてシステム障害を検知した障害検知時刻の情報を管理させ、
前記擬似障害発生処理では、
コンピュータに、前記障害情報管理処理において管理される複数のシステム障害の中から障害検知時刻が最も古いシステム障害を選択させ、選択させたシステム障害に対応する擬似障害を発生させることを特徴とするプログラム。
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) | Itシステムのトラブル対処装置、トラブル対処方法およびそのためのプログラム | |
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 |