JP5503177B2

JP5503177B2 - 障害情報収集装置

Info

Publication number: JP5503177B2
Application number: JP2009089439A
Authority: JP
Inventors: 智之望月; 実金子
Original assignee: Hitachi Systems Ltd
Current assignee: Hitachi Systems Ltd
Priority date: 2009-04-01
Filing date: 2009-04-01
Publication date: 2014-05-28
Anticipated expiration: 2029-04-01
Also published as: JP2010244137A

Description

本発明は、サーバ装置やストレージ装置等の装置からなる情報システムを対象として、ハードウェアやソフトウェアの障害が発生したときに、その障害の原因分析をするための分析用情報を収集する障害情報収集装置に関する。

従来、情報システムを最適な状態に維持するために、その運用・保守が行われてきた。運用・保守では、監視対象となるサーバ装置やストレージ装置等の装置が正常に動作しているかを監視し、障害を検知した場合にはその原因を分析・特定し、対策処理を実行する。

監視では、監視対象装置に対して、インターネットやイントラネットなどのネットワークを診断するプログラムであるｐｉｎｇ（Packet InterNet Groper）等のアクセスを行って応答を確認するものと、監視対象装置にエージェントプログラムをインストールし、そのエージェントプログラムから情報を取得するものがある。応答を確認する場合、適切な時間内に応答が返ってきているか、応答内容が適切であるかを判断する。エージェントプログラムを利用する場合には、エージェントプログラムが監視対象装置の状態をチェックして問題を検出したときに外部に通知する場合と、外部からエージェントプログラムに対して問い合わせをしたときに応答として監視対象装置の状態情報を返す場合がある。

監視により監視対象装置で障害が発生していることを検知した場合には、障害復旧のための対策処理を実行するために、障害の発生した原因を分析する。障害原因分析では、まず障害が発生した監視対象装置に直接アクセス、または、エージェントプログラムを介して障害原因分析のための分析用情報を取得する。特許文献１では、障害発生を検出したときに、事前に登録したルールに従い個別収集部を起動して、障害原因分析のための情報を収集する。

特開平７−２１９８１７号公報

しかし、障害発生を検出したときに、障害原因分析をするための分析用情報を収集しようとしても、システムがビジーであったり停止したりして収集できない場合や、障害により分析用情報が欠落する場合があり、十分な分析用情報を収集できず障害原因分析を実行できない場合がある。

そこで、本発明の障害情報収集装置は、情報システムを構成する監視対象装置の障害発生時に障害原因分析のための分析用情報を収集・蓄積する障害情報収集装置であって、障害情報収集部、障害情報記憶部、障害時分析用情報収集部、退避分析用情報記憶部、分析用情報収集設定情報を記憶した分析用情報収集設定情報記憶部、定期分析用情報収集部、一時蓄積分析用情報記憶部、を有し、前記障害情報収集部は、前記監視対象装置を監視し、障害が発生したとき、当該障害情報を検出し、障害情報記憶部に登録し、かつ当該障害情報記憶部を参照して、障害の発生した監視対象装置の障害情報をパラメータとして、障害時分析用情報収集部を起動し、前記障害時分析用情報収集部は、前記障害情報収集部による障害検出時に、前記分析用情報収集設定情報記憶部を参照して、当該記憶部の分析用情報収集設定情報を元に、前記一時蓄積分析用情報記憶部に一時蓄積した分析用情報の中から、検出した障害の原因分析に必要となる分析用情報を取得し、前記退避分析用情報記憶部に退避保存し、定期分析用情報収集部は、前記分析用情報収集設定情報記憶部を参照して、当該記憶部の分析用情報収集設定情報を元に、定期的に前記監視対象装置から分析用情報を収集し、当該収集した情報を前記一時蓄積分析用情報記憶部に一時蓄積し、前記障害時分析用情報収集部により障害情報を検出したとき、検出した障害情報とその障害原因分析するための分析用情報、又は当該障害情報のみを、前記障害情報収集装置の管理者側に通報し得るように構成し、前記監視対象装置がビジーや停止している場合にも、障害要因分析を分析するに足りる分析用情報を収集することが可能としたことを特徴とする。

本発明の障害情報収集装置は、検出した障害情報と退避した分析用情報を管理者に通知する障害情報通報部を備えたことを特徴とする。
また、検出した障害情報を管理者に通知する障害情報通報部と、障害情報と退避した分析用情報を参照する障害情報表示部と、を備え、前記障害時分析用情報収集部は、障害情報を検出したとき、前記障害情報通報部を起動し、検出した障害情報とその障害原因分析するための分析用情報、又は当該障害情報のみを、前記障害情報通報部を介して前記障害情報収集装置の管理者側に通報することを特徴とする。
また、前記一時蓄積分析用情報記憶部に定期的に収集することにより一時蓄積した分析用情報が設定された容量を超えた場合に、優先度の低い分析用情報から削除する分析用情報削除部を備えたことを特徴とする。

本発明によれば、障害発生に至るまでの分析用情報を利用することにより、障害原因分析が可能となる範囲を拡大することができる。これにより、障害復旧の迅速化や障害の再発防止につながり、システムの稼働率を向上させることができる。

図１は、障害情報収集装置を利用するときのシステム構成を示す図である。図２は、情報種別を格納する情報種別ＤＢ１１１１を示す。図３は、監視設定情報を格納する監視設定情報ＤＢ１１１２を示す。図４は、分析用情報収集設定情報を格納する分析用情報収集設定情報ＤＢ１１１３を示す。図５は、障害情報を格納する障害情報ＤＢ１１１４を示す。図６は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ａ）構成情報を示す。図７は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｂ）稼働情報（ＣＰＵ使用率）を示す。図８は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｃ）ログ情報を示す。図９は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｄ）設定ファイルを示す。図１０は、障害情報収集部１１２１の動作のフローチャートである。図１１は、分析用情報収集部（障害時）１１２２の動作のフローチャートである。図１２は、分析用情報収集部（定期）１１２３の動作のフローチャートである。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

図１は、本発明の障害情報収集装置を利用するときのシステム構成を示したものである。障害情報収集装置１は、サーバ装置やストレージ装置などの装置からなる情報システムである監視対象システム２の稼働状況を監視し、障害発生の検出と、障害原因分析のための情報を収集するものである。

障害情報収集装置１は、データやプログラムを格納するハードディスクなどからなる記憶部１１と、演算処理をするＣＰＵ（中央処理装置）１２、プログラムや演算処理に関係する一時的な情報を記憶するメモリ１３、キーボードやマウスなどの入力部１４、ディスプレイなどの出力部１５、Ethernet（登録商標）などの通信部１６からなる。記憶部１１は、データとして、情報種別を格納する情報種別ＤＢ（データベース）１１１１、監視設定情報を格納する監視設定情報ＤＢ１１１２、分析用情報収集設定情報を格納する分析用情報収集設定情報ＤＢ１１１３、障害情報を格納する障害情報ＤＢ１１１４、分析用情報を格納する分析用情報ＤＢ（退避）１１１５、および、分析用情報ＤＢ（一時蓄積）１１１６を備えている。また、記憶部１１では、障害情報収集部１１２１、分析用情報収集部（障害時）１１２２、分析用情報収集部（定期）１１２３、障害情報通報部１１２４、障害情報表示部１１２５を構成するプログラムを格納する。障害情報収集装置１は、プログラムを記憶部１１からメモリ１３にロードし、ＣＰＵ１２で演算することで、各種プログラムを実行する。

監視対象システム２は、サーバ装置やストレージ装置等の監視対象装置２１、２２からなる。ここでは、監視対象装置２１はＷｅｂサーバが動作するサーバ装置、監視対象装置２２はＤＢサーバが動作するサーバ装置で、ＷｅｂサーバとＤＢサーバが連携して動作する。障害情報収集装置１が監視対象装置２１、２２を監視するときには、それぞれの監視対象装置にエージェントプログラム２１１、２２１をインストールする。エージェントプログラムは監視対象装置上で動作し、監視対象装置が正常に稼動しているかをチェックして障害を検出した場合に、障害情報収集装置１に障害情報を通知する。また、障害情報収集装置１からの要求に応じて情報を返す。さらに、定期的または情報が生成されるタイミングで、障害情報収集装置１に障害原因分析のための情報を通知する。障害情報収集装置１は、エージェントプログラム２１１、２２１を介することで、監視対象装置２１、２２の情報を取得する。

図２は、障害情報収集装置１で監視対象システム２から収集する情報種別について纏めた情報種別ＤＢ１１１１である。ここでいう「情報」は、監視対象システム２が正常に稼動しているかを監視するために収集する収集情報と、障害検出時に原因分析を行うために収集する障害原因の分析用情報がある。情報種別ＤＢ１１１１は、収集する情報の種別を識別する情報コード１１１、監視対象装置を識別する装置コード１１２、収集する情報の内容を示す収集情報１１３、情報を取得するために方法を示す取得方法１１４を含む。障害情報収集装置１は、取得方法１１４で指定したコマンドを実行することで、監視対象装置２１，２２やエージェントプログラム２１１，２２１と通信して情報を取得する。

また、情報種別ＤＢ１１１１は、障害原因を分析するために収集する障害原因の分析用情報１１５に関して、定期的に収集する収集間隔１１６と、その情報を保持するときの最大容量１１６、保持するときの優先度１１８の情報を含む。収集間隔１１６は、障害原因分析に必要な情報が確実に収集でき、かつ、監視対象システム２の稼働状況に問題を与えない範囲で設定する。また、最大容量１１６は、障害原因分析で必要となる情報量となるように設定する。後述の分析用情報収集部（定期）１１２３で説明するが、障害原因の分析用情報１１５が最大容量１１６を超えたら、情報の種別ごとに決められた優先度１１８に従い、優先度の低いものから削除する。優先度には、時間やログレベルなどがある。

時間では直近のものほど優先度１１８が高い。ログレベルでは、ＣＲＩＴＩＣＡＬやＥＲＲＯＲなどの重要なログほど優先度が高く、ＩＮＦＯやＤＥＢＵＧなどのログほど優先度が低いと区別する。

図３は、障害情報収集部１１２１が、監視対象システム２が正常に稼動しているかを監視するための設定である監視設定情報ＤＢ１１１２である。監視設定情報ＤＢ１１１２は、個々の監視設定を識別する監視コード１２１、監視対象システム２が正常に稼動しているかを監視するために収集する収集情報（情報コード）１２２、収集情報（情報コード）１２２から障害が発生したかを判断するときの閾値１２３、収集情報（情報コード）１２２を収集する監視間隔１２４、障害と判断する障害判断条件１２５、障害と判断したときの障害コード１２６を含む。

例えば、監視設定Ｍ００１では、監視対象装置２１（Ｗｅｂサーバ）に対して１０分ごとにアクセスし、その応答時間が１０秒以上であれば、Ｅ００１の障害と判断する。また、応答コードが５００番であれば、Ｅ００２の障害と判断する。また、監視設定Ｍ００２のＳＮＭＰトラップのように、エージェントプログラム２１１，２２１が障害を検出して通知する場合には、監視間隔１２４の設定は不要となる。ＳＮＭＰトラップの内容により、障害判断条件１２５であるＣＰＵ障害・メモリ障害・電源異常等を判断する。なお、閾値１２３・障害判断条件１２５・障害コード１２６は、監視設定情報ＤＢ１１１２に記述するのではなく、各種情報を取得する情報種別ＤＢ１１１１で指定したコマンド内に埋め込まれていても良い。

図４は、分析用情報収集設定情報ＤＢ１１１３である。分析用情報収集設定情報ＤＢ１１１３は、障害の発生した装置の装置コード１３１、発生した障害の種別を識別する障害コード１３２、定期的に収集する定期収集分１３３の障害分析用情報についての情報コード１３４及び抽出期間１３５、障害発生時に収集する障害時収集分１３６の障害分析用情報についての情報コード１３７を含む。

例えば、「監視対象装置２１でＥ００１の障害が発生した場合、分析用情報収集部（定期）１１２３は、定期的に収集する情報から直近１日分のＤ０００（構成情報）、Ｄ００３（ＣＰＵ使用率）、Ｄ００４（メモリ使用量）、Ｄ００５（システムログ）、Ｄ００６（設定ファイル）を抽出し、さらに最新の構成情報を収集する」という設定となっている。収集する分析用情報は、障害の発生した装置からだけでなく、関連する装置からも収集する場合がある。

図５は、障害情報収集部１１１２で検出した障害情報を記憶する障害情報ＤＢ１１１４である。障害情報ＤＢ１１１４は、監視設定情報ＤＢ１１１２の監視コード１４１、障害が発生した装置の装置コード１４２、検出した障害の障害コード１４４、障害を検出した検出時刻１４４、検出した障害の詳細情報１４５を含む。例えば１１１４ａは、「Ｍ００１の監視において、２００８年１２月０１日の１２：０１に監視対象装置２１でＥ００１の障害（Ｗｅｂサーバの応答時間が１０秒を超えた）を検出した」ことを示す。

図６〜図９は、障害原因分析に使用する分析用情報を記憶する分析用情報ＤＢ（退避）１１１５や分析用情報ＤＢ（一時蓄積）１１１６である。障害情報収集装置１が分析用情報ＤＢ（退避）１１１５と分析用情報ＤＢ（一時蓄積）１１１６で格納する情報は同様の形式のものであり、後述する分析用収集部（障害時）１１２２が、必要に応じて、分析用情報ＤＢ（一時蓄積）１１１６から分析用情報を抽出して、分析用情報ＤＢ（退避）１１１５に保存する。

分析用情報には、構成情報、稼動情報、ログ情報、設定ファイルがある。図６の（ａ）構成情報は、監視対象システム２にどのような構成アイテムがあるかを示した情報である。構成情報は、どのような装置があるかのハードウェア情報、各装置上で動作するソフトウェアの情報、及び、それらの接続情報を持つ。例えば、２００８年１２月０１日１１：００に取得した構成情報では、監視対象機器２１と監視対象機器２２があり、それぞれでweb-serverとdb-serverが稼動して、通信していることがわかる。

図７の（ｂ）稼動情報は、ＣＰＵ使用率・メモリ使用量・ディスク使用量などのリソースの利用状況や、構成アイテムのステータスに関する稼働情報である。稼動情報は、取得時刻、取得した値の情報を持つ。

図８の（ｃ）ログ情報は、障害ログやアクセスログなどのログである。ログ情報は、ログを出力した時刻、ログメッセージの情報を持つ。

図９の（ｄ）設定情報は、監視対象装置やそれ上で動作するソフトウェアの設定である。設定情報は、取得するごとにファイルに出力し、そのファイル名と取得時刻を持つ。
なお、分析用情報ＤＢ（退避）１１１５と分析用情報ＤＢ（一時蓄積）１１１６は同様の形式であるため、別々のＤＢとして分けるのではなく、同一のＤＢに格納し、退避用と一時蓄積用を区別するフラグ情報を使用して管理しても良い。

図１０は、障害が発生したか否かを監視する障害情報収集部１１２１の動作のフローチャートである。障害情報収集部１１２１は、図３に示す監視設定情報ＤＢ１１１２を参照し、監視項目を取得する（ステップ１）。この場合、監視コードＭ００１、Ｍ００２に関する障害情報を取得する。以降、監視設定ごとに、停止要求があるまでステップ２〜４を繰返し継続する。

障害情報収集部１１２１は、例えば、監視コードＭ００１に関しては、１０分間隔で監視対象装置２１であるＷｅｂサーバに対してアクセスを行い、応答時間が閾値の１０秒を超えているか、応答コードが適切かをチェックする（ステップ２）。また、監視コードＭ００２に関しては、障害情報収集部１１２１は、監視対象装置２２のエージェントプログラム２２１からの障害通報を受けるべくＳＮＭＰトラップを待ち受けし、ＳＮＭＰトラップの内容をチェックする。障害情報収集部１１２１は、障害を検出した場合、検出した障害情報を障害情報ＤＢ１１１４に登録する（ステップ３）。

障害情報収集部１１２１は、図５に示す障害情報ＤＢ１１１４を参照して、障害の発生した監視対象装置の装置コード１４２と、発生した障害の障害コード１４３をパラメータとして、分析用情報収集部（障害時）１１２２を起動する（ステップ４）。

図１１は、障害情報収集部１１２１が障害を検出したときに起動される分析用情報収集部（障害時）１１２２の動作のフローチャートである。以下では、「装置コード：２１、障害コード：Ｅ００１」を引数として分析用情報収集部（障害時）１１２２を起動したときを例に説明する。

分析用情報収集部（障害時）１１２２は、図４に示す分析用情報収集設定情報ＤＢ１１１３を参照して、装置コード１３１と障害コード１３２を元に、分析用情報ＤＢ（一時蓄積）ＤＢ１１１６から抽出する分析用情報を取得する（ステップ１）。「装置コード：２１、障害コード：Ｅ００１」より、「定期収集分：Ｄ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６（１日分）、障害時収集分：Ｄ０００」がわかる。

分析用情報収集部（障害時）１１２２は、分析用情報ＤＢ（一時蓄積）ＤＢ１１１６から指定期間の分析用情報を抽出し、分析用情報ＤＢ（退避）１１１５に保存する（ステップ２）。ステップ１で取得した情報から、定期収集分１３３としてＤ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６の１日分の情報を取得すれば良いことがわかる。そこで、分析用情報ＤＢ（一時蓄積）１１１６から直近１日分の構成情報・稼動情報（ＣＰＵ使用率）・稼動情報（メモリ使用量）・システムログ・設定情報を抽出し、分析用情報ＤＢ（退避）１１１５に保存する。

分析用情報収集部（障害時）１１２２は、障害時収集分１３６の情報が定義されている場合に、管理対象機器２１からそれらの情報を取得する（ステップ３）。ステップ１で取得した情報から、障害時収集分１３６として情報コード１３７のＤ０００を収集すれば良いことがわかる。また、図２に示す情報種別ＤＢ１１１１を参照すると、情報コード１１１のＤ０００はコマンド０を実行することで取得することがわかる。そこで、コマンド０を実行することで最新の構成情報を取得し、分析用情報ＤＢ（退避）ＤＢ１１１５に保存する。

分析用情報収集部（障害時）１１２２は、障害情報通報部１１２４を起動し、検出した障害情報とその障害原因を分析するための分析用情報をメールなどで管理者に通報する（ステップ４）。

図１２は、分析用情報を定期的に収集する分析用情報収集部（定期）１１２３の動作のフローチャートである。分析用情報収集部（定期）１１２３は、図４に示す分析用情報収集設定情報ＤＢ１１１３を参照して、定期的に収集する定期収集分１３３の情報を取得する（ステップ１）。分析用情報収集設定情報ＤＢ１１１３より、定期的にＤ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６を収集する必要があることがわかる。以下、分析用情報の種別ごと、図２に示す情報種別ＤＢ１１１１にある分析用情報の収集間隔１１６で情報収集する。例えば、Ｄ００５のシステムログは、１０分間隔でステップ２・ステップ３を実行する。

分析用情報収集部（定期）１１２３は、取得した情報を分析用情報ＤＢ（一時蓄積）１１１６に登録する（ステップ２）。情報の種別ごとに登録方法が異なる。図６に示す（ａ）構成情報の場合、監視対象システム全体へのｐｉｎｇによる応答の有無から装置一覧の取得や、エージェントプログラムを介して各装置で稼動するソフトウェアのプロセス情報、ソフトウェア間の通信接続情報などを収集し、前回の収集結果から変化があれば分析用情報ＤＢ（一時蓄積）に登録する。図７に示す（ｂ）稼動情報の場合、収集した情報をそのまま分析用情報ＤＢ（一時蓄積）ＤＢ１１１６に追記する。図８に示す（ｃ）ログ情報の場合、前回取得分から追加された部分のみを分析用情報ＤＢ（一時蓄積）１１１６に追記する。図９に示す（ｄ）設定情報の場合、前回収集した設定情報から変化があった場合に、分析用情報ＤＢ（一時蓄積）ＤＢに登録する。

分析用情報収集部（定期）１１２３は、分析用情報ＤＢ（一時蓄積）１１１６の容量が最大容量以上になった場合、優先度の低い情報から順に削除する（ステップ３）。容量の基準となる値は、図２に示す情報種別ＤＢ１１１１の最大容量１１７で設定された値である。優先度１１８は、前述したように、情報を取得した時間やログレベルなどにより決まる。保存している分析用情報が最大容量１１７を超えなくなるように、優先度の低い分析用情報から削除する。

以上から、監視対象装置２１のＷｅｂサーバの応答時間が閾値の１０秒を超えたことを検出したときに、監視対象装置２１がビジーでアクセスできないなどの場合でも、障害発生に至るまでの構成情報、稼動情報（ＣＰＵ使用率・メモリ使用量）、ログ情報、設定情報を取得することが可能となる。

図７の（ｂ）稼動情報（ＣＰＵ使用率）を見ると、図５に示す障害発生時（２００８／１２／０１１２：０１）の前にＣＰＵ使用率が高くなっている（９２％−９５％）ことがわかる。また、図８の（ｃ）ログ情報を見ると、障害発生前にＤＢコネクションエラーが多発していることがわかる。図６の（ａ）構成情報を見ると、監視対象装置２１のＷｅｂサーバは、取得時刻（２００８／１２／０１１２：００）で、監視対象装置２２のＤＢサーバと通信していることがわかるので、「ＤＢサーバとの接続関係でエラーが発生してＣＰＵ使用率が高くなりＷｅｂサーバの応答が悪くなった」などと推測することができる。また、図９の（ｄ）ＤＢサーバの最新の設定ファイルなどを含めて調査することで、ＤＢの設定に問題がないかなど、より障害の原因を分析することができる。

実施例１では、障害情報を検出したときに、障害情報通報部１１２４が障害情報と分析用情報を管理者に通報していたが、障害情報のみを通報するようにしても良い。その場合、障害原因分析の作業者が障害情報収集装置１の障害情報表示部１１２５を利用して分析用情報を参照する。

以上のように、本発明では、障害が発生したために監視対象装置と通信ができずに障害分析情報を収集できない場合や、障害が発生することによりメモリやディスクにある障害分析用情報を損失した場合でも、定期的に収集した情報を利用することで障害原因分析を実行可能となる。

なお、常に障害原因分析用の情報を収集せずに、障害の予兆を検知したときに障害に関連する情報を収集して分析する方法がある。しかし、実際には予兆を定義することは難しい。また、予兆を定義しても、監視をしたときに予兆を検出できない、または、予兆を検出してすぐに障害が発生した場合には、障害原因分析のための情報を収集することができないことがある。本発明は、予兆を定義できなくても障害原因分析用の情報を収集可能であるので、幅広く活用可能である。

１障害情報収集装置
２監視対象システム
１１記憶部
１２ＣＰＵ
１３メモリ
１４入力部
１５出力部
１６通信部
２１監視対象装置
２２監視対象装置
１１１情報コード
１１２装置コード
１１３収集情報
１１４取得方法
１１５障害原因の分析用情報
１１６収集間隔
１１７最大容量
１１８優先度
１２１監視コード
１２２収集情報（情報コード）
１２３閾値
１２４監視間隔
１２５障害判断条件
１２６障害コード
１３１装置コード
１３２障害コード
１３３定期収集分
１３４情報コード
１３５抽出期間
１３６障害時収集分
１３７情報コード
１４１監視コード
１４２装置コード
１４３障害コード
１４４検出時刻
１４５詳細情報
２１１エージェントプログラム
２２１エージェントプログラム
１１１１情報種別ＤＢ
１１１２監視設定情報ＤＢ
１１１３分析用情報収集設定情報ＤＢ
１１１４障害情報ＤＢ
１１１５分析用情報ＤＢ（退避）
１１１６分析用情報ＤＢ（一時蓄積）
１１２１障害情報収集部
１１２２分析用情報収集部（障害時）
１１２３分析用情報収集部（定期）
１１２４障害情報通報部
１１２５障害情報表示部

Claims

情報システムを構成する監視対象装置の障害発生時に障害原因分析のための分析用情報を収集・蓄積する障害情報収集装置において、
障害情報収集部、障害情報記憶部、障害時分析用情報収集部、退避分析用情報記憶部、分析用情報収集設定情報を記憶した分析用情報収集設定情報記憶部、定期分析用情報収集部、一時蓄積分析用情報記憶部、を有し、
前記障害情報収集部は、
前記監視対象装置を監視し、障害が発生したとき、当該障害情報を検出し、障害情報記憶部に登録し、かつ当該障害情報記憶部を参照して、障害の発生した監視対象装置の障害情報をパラメータとして、障害時分析用情報収集部を起動し、
前記障害時分析用情報収集部は、
前記障害情報収集部による障害検出時に、前記分析用情報収集設定情報記憶部を参照して、当該記憶部の分析用情報収集設定情報を元に、前記一時蓄積分析用情報記憶部に一時蓄積した分析用情報の中から、検出した障害の原因分析に必要となる分析用情報を取得し、前記退避分析用情報記憶部に退避保存し、
定期分析用情報収集部は、
前記分析用情報収集設定情報記憶部を参照して、当該記憶部の分析用情報収集設定情報を元に、定期的に前記監視対象装置から分析用情報を収集し、当該収集した情報を前記一時蓄積分析用情報記憶部に一時蓄積し、
前記障害時分析用情報収集部により障害情報を検出したとき、検出した障害情報とその障害原因分析するための分析用情報、又は当該障害情報のみを、前記障害情報収集装置の管理者側に通報し得るように構成し、
前記監視対象装置がビジーや停止している場合にも、障害要因分析を分析するに足りる分析用情報を収集することが可能とした
ことを特徴とする障害情報収集装置。
請求項１に記載の障害情報収集装置において、
検出した障害情報と退避した分析用情報を管理者に通知する障害情報通報部を備えたことを特徴とする障害情報収集装置。
請求項１又は請求項２に記載の障害情報収集装置において、
検出した障害情報を管理者に通知する障害情報通報部と、
障害情報と退避した分析用情報を参照する障害情報表示部と、
を備え、
前記障害時分析用情報収集部は、障害情報を検出したとき、前記障害情報通報部を起動し、検出した障害情報とその障害原因分析するための分析用情報、又は当該障害情報のみを、前記障害情報通報部を介して前記障害情報収集装置の管理者側に通報することを特徴
とする障害情報収集装置。
請求項１ないし請求項３のいずれかに記載の障害情報収集装置において、
前記一時蓄積分析用情報記憶部に定期的に収集することにより一時蓄積した分析用情報が設定された容量を超えた場合に、優先度の低い分析用情報から削除する分析用情報削除部を備えたことを特徴とする障害情報収集装置。