(57)【要約】      （修正有）【課題】障害発生を検出したときに、システムがビジーであったり停止している場合にも、障害原因分析をするための十分な分析用情報を収集する手段を提供する。【解決手段】分析用情報収集部（定期）１１２３は、定期的に障害原因分析のための分析用情報を収集し、分析用情報ＤＢ（一時蓄積）１１１６に一時蓄積する。障害検出時に、分析用情報収集部（障害時）１１２２は、一時蓄積した分析用情報から発生した障害の原因分析に必要な部分を抽出し、また、新規に分析用情報を収集可能であれば分析用情報を収集して、分析用情報ＤＢ（退避）１１１５に格納する。【選択図】図１
2010244137.tif 000002
【特許請求の範囲】
【請求項１】
情報システムを構成する監視対象装置の障害発生時に障害原因分析のための分析用情報を収集・蓄積する障害情報収集装置において、
定期的に監視対象装置から分析用情報を収集して一時蓄積する定期分析用情報収集部と、
監視対象装置を監視して障害を検出する障害情報収集部と、
障害情報収集部による障害検出時に、一時蓄積した分析用情報の中から、検出した障害の原因分析に必要となる部分を抽出して退避する分析用情報抽出部と、
を備えたことを特徴とする障害情報収集装置。
【請求項２】
請求項１に記載の障害情報収集装置において、
障害情報収集部にて障害検出時に、監視対象装置から分析用情報の収集を試みて、取得できた場合には取得した分析用情報を退避する障害時分析用情報収集部を備えたことを特徴とする障害情報収集装置。
【請求項３】
請求項１又は請求項２に記載の障害情報収集装置において、
検出した障害情報と退避した分析用情報を管理者に通知する障害情報通報部を備えたことを特徴とする障害情報収集装置。
【請求項４】
請求項１又は請求項２に記載の障害情報収集装置において、
検出した障害情報を管理者に通知する障害情報通報部と、
障害情報と退避した分析用情報を参照する障害情報表示部と、
を備えたことを特徴とする障害情報収集装置。
【請求項５】
請求項１ないし請求項４のいずれかに記載の障害情報収集装置において、
定期的に収集することにより一時蓄積した分析用情報が設定された容量を超えた場合に、優先度の低い分析用情報から削除する分析用情報削除部を備えたことを特徴とする障害情報収集装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ装置やストレージ装置等の装置からなる情報システムを対象として、ハードウェアやソフトウェアの障害が発生したときに、その障害の原因分析をするための分析用情報を収集する障害情報収集装置に関する。
【背景技術】
【０００２】
従来、情報システムを最適な状態に維持するために、その運用・保守が行われてきた。運用・保守では、監視対象となるサーバ装置やストレージ装置等の装置が正常に動作しているかを監視し、障害を検知した場合にはその原因を分析・特定し、対策処理を実行する。
【０００３】
監視では、監視対象装置に対して、インターネットやイントラネットなどのネットワークを診断するプログラムであるｐｉｎｇ（Packet InterNet Groper）等のアクセスを行って応答を確認するものと、監視対象装置にエージェントプログラムをインストールし、そのエージェントプログラムから情報を取得するものがある。応答を確認する場合、適切な時間内に応答が返ってきているか、応答内容が適切であるかを判断する。エージェントプログラムを利用する場合には、エージェントプログラムが監視対象装置の状態をチェックして問題を検出したときに外部に通知する場合と、外部からエージェントプログラムに対して問い合わせをしたときに応答として監視対象装置の状態情報を返す場合がある。
【０００４】
監視により監視対象装置で障害が発生していることを検知した場合には、障害復旧のための対策処理を実行するために、障害の発生した原因を分析する。障害原因分析では、まず障害が発生した監視対象装置に直接アクセス、または、エージェントプログラムを介して障害原因分析のための分析用情報を取得する。特許文献１では、障害発生を検出したときに、事前に登録したルールに従い個別収集部を起動して、障害原因分析のための情報を収集する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平７−２１９８１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、障害発生を検出したときに、障害原因分析をするための分析用情報を収集しようとしても、システムがビジーであったり停止したりして収集できない場合や、障害により分析用情報が欠落する場合があり、十分な分析用情報を収集できず障害原因分析を実行できない場合がある。
【課題を解決するための手段】
【０００７】
そこで、本発明の障害情報収集装置は、情報システムを構成する監視対象装置の障害発生時に障害原因分析のための分析用情報を収集・蓄積する障害情報収集装置であって、定期的に監視対象装置から分析用情報を収集して一時蓄積する定期分析用情報収集部と、監視対象装置を監視して障害を検出する障害情報収集部と、障害情報収集部による障害検出時に、一時蓄積した分析用情報の中から、検出した障害の原因分析に必要となる部分を抽出して退避する分析用情報抽出部と、を備えたことを特徴とする。
【０００８】
本発明の障害情報収集装置は、定期的に障害原因分析のための分析用情報を収集・一時蓄積しておき、障害検出時に一時蓄積した分析用情報から発生した障害の原因分析に必要な部分を抽出し、また、新規にその分析用情報を収集可能であればその分析用情報を収集して、障害原因分析に利用する。また、定期的に収集した分析用情報を保存するときに、記憶部の容量を超えることを防ぐために、一定量を超えたら優先度の低い分析用情報から削除する。
【発明の効果】
【０００９】
本発明によれば、障害発生に至るまでの分析用情報を利用することにより、障害原因分析が可能となる範囲を拡大することができる。これにより、障害復旧の迅速化や障害の再発防止につながり、システムの稼働率を向上させることができる。
【図面の簡単な説明】
【００１０】
【図１】図１は、障害情報収集装置を利用するときのシステム構成を示す図である。
【図２】図２は、情報種別を格納する情報種別ＤＢ１１１１を示す。
【図３】図３は、監視設定情報を格納する監視設定情報ＤＢ１１１２を示す。
【図４】図４は、分析用情報収集設定情報を格納する分析用情報収集設定情報ＤＢ１１１３を示す。
【図５】図５は、障害情報を格納する障害情報ＤＢ１１１４を示す。
【図６】図６は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ａ）構成情報を示す。
【図７】図７は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｂ）稼働情報（ＣＰＵ使用率）を示す。
【図８】図８は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｃ）ログ情報を示す。
【図９】図９は、分析用情報ＤＢ（退避）１１１５・分析用情報ＤＢ（一時蓄積）１１１６の（ｄ）設定ファイルを示す。
【図１０】図１０は、障害情報収集部１１２１の動作のフローチャートである。
【図１１】図１１は、分析用情報収集部（障害時）１１２２の動作のフローチャートである。
【図１２】図１２は、分析用情報収集部（定期）１１２３の動作のフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【実施例１】
【００１２】
図１は、本発明の障害情報収集装置を利用するときのシステム構成を示したものである。障害情報収集装置１は、サーバ装置やストレージ装置などの装置からなる情報システムである監視対象システム２の稼働状況を監視し、障害発生の検出と、障害原因分析のための情報を収集するものである。
【００１３】
障害情報収集装置１は、データやプログラムを格納するハードディスクなどからなる記憶部１１と、演算処理をするＣＰＵ（中央処理装置）１２、プログラムや演算処理に関係する一時的な情報を記憶するメモリ１３、キーボードやマウスなどの入力部１４、ディスプレイなどの出力部１５、Ethernet（登録商標）などの通信部１６からなる。記憶部１１は、データとして、情報種別を格納する情報種別ＤＢ（データベース）１１１１、監視設定情報を格納する監視設定情報ＤＢ１１１２、分析用情報収集設定情報を格納する分析用情報収集設定情報ＤＢ１１１３、障害情報を格納する障害情報ＤＢ１１１４、分析用情報を格納する分析用情報ＤＢ（退避）１１１５、および、分析用情報ＤＢ（一時蓄積）１１１６を備えている。また、記憶部１１では、障害情報収集部１１２１、分析用情報収集部（障害時）１１２２、分析用情報収集部（定期）１１２３、障害情報通報部１１２４、障害情報表示部１１２５を構成するプログラムを格納する。障害情報収集装置１は、プログラムを記憶部１１からメモリ１３にロードし、ＣＰＵ１２で演算することで、各種プログラムを実行する。
【００１４】
監視対象システム２は、サーバ装置やストレージ装置等の監視対象装置２１、２２からなる。ここでは、監視対象装置２１はＷｅｂサーバが動作するサーバ装置、監視対象装置２２はＤＢサーバが動作するサーバ装置で、ＷｅｂサーバとＤＢサーバが連携して動作する。障害情報収集装置１が監視対象装置２１、２２を監視するときには、それぞれの監視対象装置にエージェントプログラム２１１、２２１をインストールする。エージェントプログラムは監視対象装置上で動作し、）監視対象装置が正常に稼動しているかをチェックして障害を検出した場合に、障害情報収集装置１に障害情報を通知する。また、）障害情報収集装置１からの要求に応じて情報を返す。さらに、定期的または情報が生成されるタイミングで、障害情報収集装置１に障害原因分析のための情報を通知する。障害情報収集装置１は、エージェントプログラム２１１、２２１を介することで、監視対象装置２１、２２の情報を取得する。
【００１５】
図２は、障害情報収集装置１で監視対象システム２から収集する情報種別について纏めた情報種別ＤＢ１１１１である。ここでいう「情報」は、監視対象システム２が正常に稼動しているかを監視するために収集する収集情報と、障害検出時に原因分析を行うために収集する障害原因の分析用情報がある。情報種別ＤＢ１１１１は、収集する情報の種別を識別する情報コード１１１、監視対象装置を識別する装置コード１１２、収集する情報の内容を示す収集情報１１３、情報を取得するために方法を示す取得方法１１４を含む。障害情報収集装置１は、取得方法１１４で指定したコマンドを実行することで、監視対象装置２１，２２やエージェントプログラム２１１，２２１と通信して情報を取得する。
【００１６】
また、情報種別ＤＢ１１１１は、障害原因を分析するために収集する障害原因の分析用情報１１５に関して、定期的に収集する収集間隔１１６と、その情報を保持するときの最大容量１１６、保持するときの優先度１１８の情報を含む。収集間隔１１６は、障害原因分析に必要な情報が確実に収集でき、かつ、監視対象システム２の稼働状況に問題を与えない範囲で設定する。また、最大容量１１６は、障害原因分析で必要となる情報量となるように設定する。後述の分析用情報収集部（定期）１１２３で説明するが、障害原因の分析用情報１１５が最大容量１１６を超えたら、情報の種別ごとに決められた優先度１１８に従い、優先度の低いものから削除する。優先度には、時間やログレベルなどがある。
【００１７】
時間では直近のものほど優先度１１８が高い。ログレベルでは、ＣＲＩＴＩＣＡＬやＥＲＲＯＲなどの重要なログほど優先度が高く、ＩＮＦＯやＤＥＢＵＧなどのログほど優先度が低いと区別する。
【００１８】
図３は、障害情報収集部１１２１が、監視対象システム２が正常に稼動しているかを監視するための設定である監視設定情報ＤＢ１１１２である。監視設定情報ＤＢ１１１２は、個々の監視設定を識別する監視コード１２１、監視対象システム２が正常に稼動しているかを監視するために収集する収集情報（情報コード）１２２、収集情報（情報コード）１２２から障害が発生したかを判断するときの閾値１２３、収集情報（情報コード）１２２を収集する監視間隔１２４、障害と判断する障害判断条件１２５、障害と判断したときの障害コード１２６を含む。
【００１９】
例えば、監視設定Ｍ００１では、監視対象装置２１（Ｗｅｂサーバ）に対して１０分ごとにアクセスし、その応答時間が１０秒以上であれば、Ｅ００１の障害と判断する。また、応答コードが５００番であれば、Ｅ００２の障害と判断する。また、監視設定Ｍ００２のＳＮＭＰトラップのように、エージェントプログラム２１１，２２１が障害を検出して通知する場合には、監視間隔１２４の設定は不要となる。ＳＮＭＰトラップの内容により、障害判断条件１２５であるＣＰＵ障害・メモリ障害・電源異常等を判断する。なお、閾値１２３・障害判断条件１２５・障害コード１２６は、監視設定情報ＤＢ１１１２に記述するのではなく、各種情報を取得する情報種別ＤＢ１１１１で指定したコマンド内に埋め込まれていても良い。
【００２０】
図４は、分析用情報収集設定情報ＤＢ１１１３である。分析用情報収集設定情報ＤＢ１１１３は、障害の発生した装置の装置コード１３１、発生した障害の種別を識別する障害コード１３２、定期的に収集する定期収集分１３３の障害分析用情報についての情報コード１３４及び抽出期間１３５、障害発生時に収集する障害時収集分１３６の障害分析用情報についての情報コード１３７を含む。
【００２１】
例えば、「監視対象装置２１でＥ００１の障害が発生した場合、分析用情報収集部（定期）１１２３は、定期的に収集する情報から直近１日分のＤ０００（構成情報）、Ｄ００３（ＣＰＵ使用率）、Ｄ００４（メモリ使用量）、Ｄ００５（システムログ）、Ｄ００６（設定ファイル）を抽出し、さらに最新の構成情報を収集する」という設定となっている。収集する分析用情報は、障害の発生した装置からだけでなく、関連する装置からも収集する場合がある。
【００２２】
図５は、障害情報収集部１１１２で検出した障害情報を記憶する障害情報ＤＢ１１１４である。障害情報ＤＢ１１１４は、監視設定情報ＤＢ１１１２の監視コード１４１、障害が発生した装置の装置コード１４２、検出した障害の障害コード１４４、障害を検出した検出時刻１４４、検出した障害の詳細情報１４５を含む。例えば１１１４ａは、「Ｍ００１の監視において、２００８年１２月０１日の１２：０１に監視対象装置２１でＥ００１の障害（Ｗｅｂサーバの応答時間が１０秒を超えた）を検出した」ことを示す。
【００２３】
図６〜図９は、障害原因分析に使用する分析用情報を記憶する分析用情報ＤＢ（退避）１１１５や分析用情報ＤＢ（一時蓄積）１１１６である。障害情報収集装置１が分析用情報ＤＢ（退避）１１１５と分析用情報ＤＢ（一時蓄積）１１１６で格納する情報は同様の形式のものであり、後述する分析用収集部（障害時）１１２２が、必要に応じて、分析用情報ＤＢ（一時蓄積）１１１６から分析用情報を抽出して、分析用情報ＤＢ（退避）１１１５に保存する。
【００２４】
分析用情報には、構成情報、稼動情報、ログ情報、設定ファイルがある。図６の（ａ）構成情報は、監視対象システム２にどのような構成アイテムがあるかを示した情報である。構成情報は、どのような装置があるかのハードウェア情報、各装置上で動作するソフトウェアの情報、及び、それらの接続情報を持つ。例えば、２００８年１２月０１日１１：００に取得した構成情報では、監視対象機器２１と監視対象機器２２があり、それぞれでweb-serverとdb-serverが稼動して、通信していることがわかる。
【００２５】
図７の（ｂ）稼動情報は、ＣＰＵ使用率・メモリ使用量・ディスク使用量などのリソースの利用状況や、構成アイテムのステータスに関する稼働情報である。稼動情報は、取得時刻、取得した値の情報を持つ。
【００２６】
図８の（ｃ）ログ情報は、障害ログやアクセスログなどのログである。ログ情報は、ログを出力した時刻、ログメッセージの情報を持つ。
【００２７】
図９の（ｄ）設定情報は、監視対象装置やそれ上で動作するソフトウェアの設定である。設定情報は、取得するごとにファイルに出力し、そのファイル名と取得時刻を持つ。
なお、分析用情報ＤＢ（退避）１１１５と分析用情報ＤＢ（一時蓄積）１１１６は同様の形式であるため、別々のＤＢとして分けるのではなく、同一のＤＢに格納し、退避用と一時蓄積用を区別するフラグ情報を使用して管理しても良い。
【００２８】
図１０は、障害が発生したか否かを監視する障害情報収集部１１２１の動作のフローチャートである。障害情報収集部１１２１は、図３に示す監視設定情報ＤＢ１１１２を参照し、監視項目を取得する（ステップ１）。この場合、監視コードＭ００１、Ｍ００２に関する障害情報を取得する。以降、監視設定ごとに、停止要求があるまでステップ２〜４を繰返し継続する。
【００２９】
障害情報収集部１１２１は、例えば、監視コードＭ００１に関しては、１０分間隔で監視対象装置２１であるＷｅｂサーバに対してアクセスを行い、応答時間が閾値の１０秒を超えているか、応答コードが適切かをチェックする（ステップ２）。また、監視コードＭ００２に関しては、障害情報収集部１１２１は、監視対象装置２２のエージェントプログラム２２１からの障害通報を受けるべくＳＮＭＰトラップを待ち受けし、ＳＮＭＰトラップの内容をチェックする。障害情報収集部１１２１は、障害を検出した場合、検出した障害情報を障害情報ＤＢ１１１４に登録する（ステップ３）。
【００３０】
障害情報収集部１１２１は、図５に示す障害情報ＤＢ１１１４を参照して、障害の発生した監視対象装置の装置コード１４２と、発生した障害の障害コード１４３をパラメータとして、分析用情報収集部（障害時）１１２２を起動する（ステップ４）。
【００３１】
図１１は、障害情報収集部１１２１が障害を検出したときに起動される分析用情報収集部（障害時）１１２２の動作のフローチャートである。以下では、「装置コード：２１、障害コード：Ｅ００１」を引数として分析用情報収集部（障害時）１１２２を起動したときを例に説明する。
【００３２】
分析用情報収集部（障害時）１１２２は、図４に示す分析用情報収集設定情報ＤＢ１１１３を参照して、装置コード１３１と障害コード１３２を元に、分析用情報ＤＢ（一時蓄積）ＤＢ１１１６から抽出する分析用情報を取得する（ステップ１）。「装置コード：２１、障害コード：Ｅ００１」より、「定期収集分：Ｄ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６（１日分）、障害時収集分：Ｄ０００」がわかる。
【００３３】
分析用情報収集部（障害時）１１２２は、分析用情報ＤＢ（一時蓄積）ＤＢ１１１６から指定期間の分析用情報を抽出し、分析用情報ＤＢ（退避）１１１５に保存する（ステップ２）。ステップ１で取得した情報から、定期収集分１３３としてＤ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６の１日分の情報を取得すれば良いことがわかる。そこで、分析用情報ＤＢ（一時蓄積）１１１６から直近１日分の構成情報・稼動情報（ＣＰＵ使用率）・稼動情報（メモリ使用量）・システムログ・設定情報を抽出し、分析用情報ＤＢ（退避）１１１５に保存する。
【００３４】
分析用情報収集部（障害時）１１２２は、障害時収集分１３６の情報が定義されている場合に、管理対象機器２１からそれらの情報を取得する（ステップ３）。ステップ１で取得した情報から、障害時収集分１３６として情報コード１３７のＤ０００を収集すれば良いことがわかる。また、図２に示す情報種別ＤＢ１１１１を参照すると、情報コード１１１のＤ０００はコマンド０を実行することで取得することがわかる。そこで、コマンド０を実行することで最新の構成情報を取得し、分析用情報ＤＢ（退避）ＤＢ１１１５に保存する。
【００３５】
分析用情報収集部（障害時）１１２２は、障害情報通報部１１２４を起動し、検出した障害情報とその障害原因を分析するための分析用情報をメールなどで管理者に通報する（ステップ４）。
【００３６】
図１２は、分析用情報を定期的に収集する分析用情報収集部（定期）１１２３の動作のフローチャートである。分析用情報収集部（定期）１１２３は、図４に示す分析用情報収集設定情報ＤＢ１１１３を参照して、定期的に収集する定期収集分１３３の情報を取得する（ステップ１）。分析用情報収集設定情報ＤＢ１１１３より、定期的にＤ０００・Ｄ００３・Ｄ００４・Ｄ００５・Ｄ００６を収集する必要があることがわかる。以下、分析用情報の種別ごと、図２に示す情報種別ＤＢ１１１１にある分析用情報の収集間隔１１６で情報収集する。例えば、Ｄ００５のシステムログは、１０分間隔でステップ２・ステップ３を実行する。
【００３７】
分析用情報収集部（定期）１１２３は、取得した情報を分析用情報ＤＢ（一時蓄積）１１１６に登録する（ステップ２）。情報の種別ごとに登録方法が異なる。図６に示す（ａ）構成情報の場合、監視対象システム全体へのｐｉｎｇによる応答の有無から装置一覧の取得や、エージェントプログラムを介して各装置で稼動するソフトウェアのプロセス情報、ソフトウェア間の通信接続情報などを収集し、前回の収集結果から変化があれば分析用情報ＤＢ（一時蓄積）に登録する。図７に示す（ｂ）稼動情報の場合、収集した情報をそのまま分析用情報ＤＢ（一時蓄積）ＤＢ１１１６に追記する。図８に示す（ｃ）ログ情報の場合、前回取得分から追加された部分のみを分析用情報ＤＢ（一時蓄積）１１１６に追記する。図９に示す（ｄ）設定情報の場合、前回収集した設定情報から変化があった場合に、分析用情報ＤＢ（一時蓄積）ＤＢに登録する。
【００３８】
分析用情報収集部（定期）１１２３は、分析用情報ＤＢ（一時蓄積）１１１６の容量が最大容量以上になった場合、優先度の低い情報から順に削除する（ステップ３）。容量の基準となる値は、図２に示す情報種別ＤＢ１１１１の最大容量１１７で設定された値である。優先度１１８は、前述したように、情報を取得した時間やログレベルなどにより決まる。保存している分析用情報が最大容量１１７を超えなくなるように、優先度の低い分析用情報から削除する。
【００３９】
以上から、監視対象装置２１のＷｅｂサーバの応答時間が閾値の１０秒を超えたことを検出したときに、監視対象装置２１がビジーでアクセスできないなどの場合でも、障害発生に至るまでの構成情報、稼動情報（ＣＰＵ使用率・メモリ使用量）、ログ情報、設定情報を取得することが可能となる。
【００４０】
図７の（ｂ）稼動情報（ＣＰＵ使用率）を見ると、図５に示す障害発生時（２００８／１２／０１  １２：０１）の前にＣＰＵ使用率が高くなっている（９２％−９５％）ことがわかる。また、図８の（ｃ）ログ情報を見ると、障害発生前にＤＢコネクションエラーが多発していることがわかる。図６の（ａ）構成情報を見ると、監視対象装置２１のＷｅｂサーバは、取得時刻（２００８／１２／０１  １２：００）で、監視対象装置２２のＤＢサーバと通信していることがわかるので、「ＤＢサーバとの接続関係でエラーが発生してＣＰＵ使用率が高くなりＷｅｂサーバの応答が悪くなった」などと推測することができる。また、図９の（ｄ）ＤＢサーバの最新の設定ファイルなどを含めて調査することで、ＤＢの設定に問題がないかなど、より障害の原因を分析することができる。
【００４１】
実施例１では、障害情報を検出したときに、障害情報通報部１１２４が障害情報と分析用情報を管理者に通報していたが、障害情報のみを通報するようにしても良い。その場合、障害原因分析の作業者が障害情報収集装置１の障害情報表示部１１２５を利用して分析用情報を参照する。
【００４２】
以上のように、本発明では、障害が発生したために監視対象装置と通信ができずに障害分析情報を収集できない場合や、障害が発生することによりメモリやディスクにある障害分析用情報を損失した場合でも、定期的に収集した情報を利用することで障害原因分析を実行可能となる。
【００４３】
なお、常に障害原因分析用の情報を収集せずに、障害の予兆を検知したときに障害に関連する情報を収集して分析する方法がある。しかし、実際には予兆を定義することは難しい。また、予兆を定義しても、監視をしたときに予兆を検出できない、または、予兆を検出してすぐに障害が発生した場合には、障害原因分析のための情報を収集することができないことがある。本発明は、予兆を定義できなくても障害原因分析用の情報を収集可能であるので、幅広く活用可能である。
【符号の説明】
【００４４】
１  障害情報収集装置
２  監視対象システム
１１  記憶部
１２  ＣＰＵ
１３  メモリ
１４  入力部
１５  出力部
１６  通信部
２１  監視対象装置
２２  監視対象装置
１１１  情報コード
１１２  装置コード
１１３  収集情報
１１４  取得方法
１１５  障害原因の分析用情報
１１６  収集間隔
１１７  最大容量
１１８  優先度
１２１  監視コード
１２２  収集情報（情報コード）
１２３  閾値
１２４  監視間隔
１２５  障害判断条件
１２６  障害コード
１３１  装置コード
１３２  障害コード
１３３  定期収集分
１３４  情報コード
１３５  抽出期間
１３６  障害時収集分
１３７  情報コード
１４１  監視コード
１４２  装置コード
１４３  障害コード
１４４  検出時刻
１４５  詳細情報
２１１  エージェントプログラム
２２１  エージェントプログラム
１１１１  情報種別ＤＢ
１１１２  監視設定情報ＤＢ
１１１３  分析用情報収集設定情報ＤＢ
１１１４  障害情報ＤＢ
１１１５  分析用情報ＤＢ（退避）
１１１６  分析用情報ＤＢ（一時蓄積）
１１２１  障害情報収集部
１１２２  分析用情報収集部（障害時）
１１２３  分析用情報収集部（定期）
１１２４  障害情報通報部
１１２５  障害情報表示部
【図１】
2010244137.tif 000003
【図２】
2010244137.tif 000004
【図３】
2010244137.tif 000005
【図４】
2010244137.tif 000006
【図５】
2010244137.tif 000007
【図６】
2010244137.tif 000008
【図７】
2010244137.tif 000009
【図８】
2010244137.tif 000010
【図９】
2010244137.tif 000011
【図１０】
2010244137.tif 000012
【図１１】
2010244137.tif 000013
【図１２】
2010244137.tif 000014