JP2000115168A - ネットワークに適用する障害管理システム及びネットワーク管理システム - Google Patents

Abstract

(57)【要約】 【課題】障害の発生時から障害処理が完了するまでに要
する時間を短縮化し、結果としてシステムに設定された
所定の制限時間内に障害回復などの障害管理処理を完了
できるように実現することにある。 【解決手段】マネージャ／エージェント方式によるネッ
トワーク管理システムにおいて、管理対象システム２０
の障害発生時に、管理対象モジュール３２は障害管理テ
ーブル３５を参照して当該障害内容に対応する障害関連
情報を監視タイマ値内に収集する。エージェント３０
は、管理対象モジュール３２により管理情報テーブル３
１に書き込まれた障害関連情報からなる送信パケットを
マネージャ２に送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、特にネットワーク
上において障害管理機能を有するネットワーク管理シス
テムに関する。

【０００２】

【従来の技術】従来、複数のコンピュータ、通信機器、
及び通信回線などのネットワーク機器が接続されて構成
されるネットワークでは、当該ネットワーク上での構成
要素（コンピュータなどの物理的要素以外にデータなど
の論理的要素も含む）を管理するネットワーク管理シス
テムにより効率的な運用が実行されている。

【０００３】近年では、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅ
ｔｗｏｒｋ ＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）
等の標準的プロトコルを使用して、ネットワーク管理に
必要な管理情報を交換して、各種の管理処理を行うシス
テムが注目されている。ネットワーク管理システムは、
ネットワーク上の構成管理（資源管理）や性能管理（効
率的な利用管理）等以外に、障害管理を主たる管理機能
として備えている。障害管理機能は、概略的にはネット
ワーク機器の障害の検出及び当該障害の原因を除去して
回復させる障害回復の機能を意味する。

【０００４】ＳＮＭＰを利用するネットワーク管理シス
テムの概念は、図２２に示すように、マネージャ／エー
ジェント・モデルと呼ばれるシステムである。このシス
テムは、ネットワーク１を介して、管理システム主体で
ある管理ステーション上のマネージャ２と、管理対象シ
ステム（具体的にはネットワーク機器）上のエージェン
ト３とが前記のＳＮＭＰにより情報を交換する構成であ
る。

【０００５】マネージャ２は、各種のネットワーク機器
に組み込まれたエージェント３から各種データを収集し
てシステム全体の管理情報４を構成し、当該管理情報に
基づいて所定の管理機能に必要な制御動作を実行する。
このシステム全体の管理情報４とは、一般的にはＭＩＢ
（Ｍａｎａｇｅｍｅｎｔ ＩｎｆｏｒｍａｔｉｏｎＢａ
ｓｅ）と呼ばれる仮想データベースである。

【０００６】一方、エージェント３は、障害管理などの
各種管理に必要な管理情報を登録する管理情報テーブル
５を管理し、マネージャ２からの要求に応じて当該管理
情報テーブル５に登録されている管理情報を送信する。
管理情報テーブル５には、管理対象モジュールにより管
理情報が不定期に書き込まれる。ここで、管理対象シス
テムに障害が発生すると、エージェント３は自発的に管
理情報テーブル５から障害関連情報をマネージャ２に送
信する機能を有する。

【０００７】このような従来方式のネットワーク管理シ
ステムにおいて、ある障害が発生したときの動作を図２
３のタイミングチャート及び図２４のフローチャートを
参照して説明する。

【０００８】管理対象システムであるネットワーク機器
に障害が発生すると、エージェント３は、管理情報テー
ブルから障害通知を行うための送信メッセージを作成し
て、マネージャ２に送信する（ステップＳ７０〜Ｓ７
３）。管理情報テーブルは、障害が発生した時点で、障
害関連情報が書き込まれて更新される（ステップＳ７
１）。一方、マネージャ２は、エージェント３からメッ
セージを受信すると、システム全体の情報（ＭＩＢ）４
を更新し、障害に対処するために必要な制御内容を決定
する（ステップＳ７４〜Ｓ７６）。

【０００９】ここで、マネージャ２は、エージェント３
から受信した情報が当該障害の対処に必要な全ての障害
情報を含むとは限らないため、必要な情報（情報Ｂ、情
報Ｃ）をエージェント３に要求する（ステップＳ７
７）。エージェント３は、マネージャ２からの情報収集
の要求を受信すると、管理情報テーブルを検索して要求
された障害関連情報を収集する（ステップＳ７８，Ｓ７
９）。そして、再度送信メッセージを作成して、マネー
ジャ２に送信する（ステップＳ８０，Ｓ８１）。以後同
様に、マネージャ２は、エージェント３からメッセージ
を受信すると、システム全体の情報（ＭＩＢ）４を更新
する動作を繰り返す（ステップＳ８２，Ｓ８３）。

【００１０】マネージャ２は、必要な情報を全て取得す
ると、当該情報に基づいて決定した制御内容をエージェ
ント３に指示する（ステップＳ８４，Ｓ８５）。エージ
ェント３は、マネージャ２からの制御指示を受信する
と、当該制御を実行する（ステップＳ８６，Ｓ８７）。
エージェント３は、制御の実行結果である障害回復状況
などを示す応答メッセージを作成して、マネージャ２に
送信する（ステップＳ８８，Ｓ８９）。マネージャ２
は、受信した応答メッセージにより障害回復結果を認識
する（ステップＳ９０）。

【００１１】以上のような一連の動作は、図２３のタイ
ミングチャートに示すように、時系列処理として実現さ
れる。ここで、図２３では、横軸が時間軸であり、時間
Ｔｚは障害の発生時から障害対処に必要な制御動作が終
了するまでの時間を示す。一方、時間Ｔｗは、システム
として制御が完了すべき時間を示す。即ち、障害が発生
してから回復するまでに、システムとして許容される時
間である。

【００１２】

【発明が解決しようとする課題】図２３のタイミングチ
ャートから明らかなように、従来のネットワーク管理シ
ステムによる障害管理方式では、障害の発生時から障害
対処に必要な制御動作が終了するまでの時間Ｔｚが、本
来システムとして完了すべき時間Ｔｗより長くなる事態
が発生する可能性がある。換言すれば、完了すべき時間
Ｔｗ内に、障害回復などに必要な制御動作が終了しない
事態が発生する。

【００１３】このような事態の要因としては、図２３及
び図２４に示すように、実際の制御に必要な時間Ｔｎ以
外に、いわば冗長な時間Ｔｘを費やしていることにあ
る。この冗長な時間Ｔｘとは、マネージャ２が障害関連
情報（情報Ｂ，情報Ｃ）をエージェント３側に要求し、
エージェント３側からマネージャ２側に要求された障害
関連情報を送信するための情報要求、情報収集、及び情
報提供の一連の処理に要する時間である。また、冗長な
時間Ｔｘには、マネージャ２が要求した情報が所定の時
間内に到達せずに、結果として前記の一連の処理に要す
る時間が不確定となる要素も含まれている。

【００１４】そこで、本発明の目的は、障害の発生時か
ら障害処理が完了するまでに要する時間を短縮化し、結
果としてシステムに設定された所定の制限時間内に障害
回復などの障害管理処理を完了できるように実現するこ
とにある。

【００１５】

【課題を解決するための手段】本発明は、特にマネージ
ャ／エージェント方式によるネットワーク管理システム
において、管理対象システムの障害発生時に、エージェ
ント側から障害処理（障害検出及び障害回復など）に必
要な情報を収集して、できるだけ短時間にマネージャ側
に送信する障害管理システムである。

【００１６】このような機能を実現するために、本シス
テムは、ネットワーク機器の障害内容に対応して予め設
定される障害関連情報を登録するための障害管理テーブ
ル手段と、ネットワーク機器の障害発生時に障害管理テ
ーブル手段を参照して当該障害内容に対応する障害関連
情報を収集する情報収集手段と、情報収集手段により収
集された障害関連情報を前記ネットワーク管理システム
に送信する送信手段とを備えている。

【００１７】具体的には、本システムでは、障害発生時
にエージェント側は、自発的に障害処理に必要な障害関
連情報を収集して、所定の制限時間内にマネージャ側に
送信する。必要な障害関連情報を収集するための手段と
して、障害管理テーブルを利用する。従って、障害発生
時に、マネージャ側は、障害処理に必要な障害関連情報
の全てを受信できる可能性が高くなり、当該障害関連情
報をエージェント側に要求する処理を大幅に減少するこ
とが可能となる。これにより、マネージャ側の処理負担
の軽減および障害処理に要する時間の短縮化（冗長時間
の削減）を実現できる。

【００１８】本発明の別の観点として、前記障害管理テ
ーブルにセットした監視タイマ情報により監視タイマ機
能を有するシステムである。監視タイマ機能は、障害発
生時からエージェント側が必要な障害関連情報を収集し
て、マネージャ側に送信するまでの制限時間を監視する
ための機能である。この機能により、マネージャ側は、
所定の時間内に最小限必要な障害関連情報を受信できる
ため、予めシステムとして設定された時間内に障害回復
等の障害処理を完了することを監視することができる。
従って、障害関連情報がエージェント側からマネージャ
側に到達されるまでの時間が不確定になるような事態を
防止することが可能となる。

【００１９】

【発明の実施の形態】以下図面を参照して、本発明の実
施の形態を説明する。

【００２０】図１は本実施形態に関係するネットワーク
管理システムの基本的構成を示すブロック図であり、図
２は同実施形態の障害管理テーブルの構成を説明するた
めの概念図であり、図３は同実施形態のエージェントが
送信する送信パケットの構成を示す概念図であり、図４
は同実施形態のシステムにおける一連の障害処理を説明
するためのフローチャートである。 （システムの構成）本システムは、マネージャ／エージ
ェント方式であり、マネージャとエージェント間でＳＮ
ＭＰ等の標準的プロトコルを使用して、ネットワーク管
理に必要な情報を交換するネットワーク管理システムを
想定する。

【００２１】図１に示すように、マネージャ２は、シス
テム管理の主体である管理ステーション１０に存在す
る。管理ステーション１０には、管理情報の表示及び入
力などの機能を実現するための管理コンソール１１およ
びシステム全体の管理情報であるＭＩＢ（図示せず）が
含まれている。マネージャ２は、ネットワーク１上の通
信回線を介して、エージェント３０との間でパケット単
位の管理情報（後述する障害関連情報、システムの状態
情報等）の交換する。

【００２２】一方、エージェント３０は、管理対象シス
テム２０上に存在し、同実施形態の障害管理機能を実現
する。管理対象システム２０とは、サーバなどのコンピ
ュータ、通信機器、通信回線等のネットワーク機器等の
物理的対象（ハードウエア）およびデータなどの論理的
対象を意味する。即ち、エージェント３０は、例えばサ
ーバ（後述するストリーム配信サーバなど）に常駐して
いる制御プログラム群に含まれる制御プログラムであ
る。

【００２３】エージェント３０に属する機能モジュール
として、障害検出モジュール３３、管理情報テーブル監
視モジュール（以下テーブル監視モジュールと省略す
る）３４、及び管理対象モジュール３２がある。障害検
出モジュール３３は、管理対象システム２０上の機器で
障害が発生したことを検出し、障害管理テーブル３５を
参照して管理対象モジュール３２に障害関連情報の取得
要求を出す。

【００２４】管理対象モジュール３２は管理対象機器か
ら障害関連情報・状態情報・その他の管理情報を取り出
し、管理情報テーブル３１に書き込む。テーブル監視モ
ジュール３４は、障害管理テーブル３５に基づいて管理
情報テーブル３１を監視し、かつエージェント３０に対
して管理情報テーブル３１に登録された情報の送信要求
を出す。

【００２５】管理情報テーブル３１は、管理対象モジュ
ール３２が収集した管理対象システム２０上の機器に関
する管理情報（同実施形態では障害関連情報のみについ
て説明する）を登録するためのテーブルである。エージ
ェント３０は、管理情報テーブル３１に登録された管理
情報を読出して、マネージャ２に送信する送信パケット
（送信情報）を作成する。同実施形態では、エージェン
ト３０は、マネージャ２からの要求に応じて不定期また
は定期的に、当該送信パケットをマネージャ２に送信す
る。また、障害発生時にテーブル監視モジュール３４か
らの指示に従って、当該送信パケットをマネージャ２に
送信する。

【００２６】マネージャ２は、エージェント３０から送
信された情報に基づいてシステム全体の情報（ＭＩＢ）
を管理する。同実施形態では、マネージャ２は、エージ
ェント３０から送信された障害管理に関する情報に基づ
いて、障害処理（障害検出や障害回復など）に関する制
御が必要と判断した場合には、エージェント３０に対し
て制御動作の実行を要求するための制御指示を送信す
る。 （障害管理テーブル３５の構成）障害管理テーブル３５
は、図２に示すように、予め設定された各障害項目
（Ｘ，Ｙ，…）毎に、当該障害の対応処理を行うために
必要な複数の関連情報（ＤＡＴＡ）、その付加情報（Ｆ
ＬＡＧ）、及び監視タイマ値により構成されている。即
ち、障害管理テーブル３５を参照することにより、例え
ばシステム２０上において、障害項目Ｘに相当する障害
が発生した場合には、障害処理に必要な関連情報として
は情報Ａ，Ｂ，Ｃ，Ｄが必要であることが認識される。
また、各関連情報に付加された付加情報（ＦＬＡＧ）に
より、各情報Ａ，Ｂ，Ｃ，Ｄに関して以下のことが指示
される。

【００２７】即ち、ＦＬＡＧが「０」の場合には、その
情報の収集要求が必要であり、かつ管理情報テーブル３
１が未更新であることを示す。ＦＬＡＧが「１」の場合
には、その情報の収集要求が必要であり、かつ管理情報
テーブル３１が更新済みであることを示す。また、ＦＬ
ＡＧが「２」の場合には、その情報は管理情報テーブル
３１に既に登録されていることを示す。従って、ＦＬＡ
Ｇが「２」の情報については、管理対象モジュール３２
による情報収集処理は不要となる。

【００２８】監視タイマ値は、障害発生時からエージェ
ント３０がマネージャ２に、障害関連情報（送信パケッ
ト）を送信するまでの制限時間を示す時間情報である。
即ち、障害発生時からその障害処理に必要な関連情報
を、エージェント３０からマネージャ２に到達するまで
の限界時間を意味する。これにより、エージェント３０
は、制限時間内に障害関連情報をマネージャ２に対して
通知することになる。 （障害処理）以下図１と共に、図２、図３及び図４
（Ａ），（Ｂ）のフローチャートを参照して同実施形態
の障害処理を説明する。

【００２９】まず、図４（Ａ）に示すように、管理対象
システム２０上において、障害検出モジュール３３が機
器の障害（障害項目Ｘとする）の発生を検出すると、障
害管理テーブル３５を参照する（ステップＳ１，Ｓ
２）。ここで、障害検出モジュール３３は、例えば機器
のハードウエアでの障害が発生したことが表示されるス
テータスレジスタや、エラー表示用のレジスタ等をポー
リングすることでエラーを検出したり、エラー発生時に
割り込みが設定されている場合は割り込みにより検出す
る。

【００３０】さらに、障害検出モジュール３３は、障害
管理テーブル３５を参照することにより、当該障害項目
Ｘの障害処理に必要な関連情報（Ａ，Ｂ，Ｃ，Ｄ）を認
識し、さらに付加情報（ＦＬＡＧ）に従って各情報毎に
情報収集要求を管理対象モジュール３２に出す。ここで
は、前述したように、関連情報Ｄについては既に管理情
報テーブル３１に格納されているため、情報収集処理は
不要となる。従って、管理対象モジュール３２は、関連
情報（Ａ，Ｂ，Ｃ）のみについて収集処理を実行する
（ステップＳ３）。

【００３１】また、障害検出モジュール３３は、テーブ
ル監視モジュール３４に対して、管理情報テーブル３１
の監視要求を出す。この要求に応じて、テーブル監視モ
ジュール３４は、障害管理テーブル３５上の障害項目Ｘ
についての情報を自身のモジュール内にコピーし、当該
コピーした関連情報（Ａ〜Ｄ）、その付加情報（ＦＬＡ
Ｇ）、および監視タイマ値に基づいて管理情報テーブル
３１を監視する。

【００３２】管理対象モジュール３２は、障害検出モジ
ュール３３からの指示に応じて障害関連情報（Ａ，Ｂ，
Ｃ）を収集し、管理情報テーブル３１に書き込む（ステ
ップＳ４）。このとき、管理情報テーブル３１に登録さ
れている関連情報（Ｄ）については、そのまま維持して
更新しない。テーブル監視モジュール３４は、管理情報
テーブル３１の書き込み状態を監視し、情報収集要求が
出ていて書き込まれた関連情報については、その各付加
情報のフラグ（ＦＬＡＧ）を「１」にセットする。書き
込まれない関連情報については、フラグ（ＦＬＡＧ）を
「０」のまま維持する。ここでは、管理情報テーブル３
１には、関連情報（Ａ、Ｂ）のみが書き込まれて、関連
情報（Ｃ）は書き込まれていないとする。関連情報
（Ｄ）については、管理情報テーブル３１には既に書き
込まれており、そのまま出力されるため、フラグ（ＦＬ
ＡＧ）を「２」にセットする。

【００３３】ここで、テーブル監視モジュール３４は、
障害管理テーブル３５上の障害項目Ｘに対応する監視タ
イマ値（１．０ｓ）に基づいて、障害発生時からの時間
経過を監視タイマにより監視している。この監視タイマ
がタイムアウトした時点で、テーブル監視モジュール３
４は、前記フラグ情報（ＦＬＡＧ）を管理情報テーブル
３１上の各関連情報Ａ〜Ｄのそれぞれにセットし、エー
ジェント３０に対して送信要求を通知する（ステップＳ
５のＹＥＳ）。なお、テーブル監視モジュール３４は、
監視タイマがタイムアウトする前でも、管理情報テーブ
ル３１に必要な関連情報（Ａ〜Ｄ）の全てが登録された
時点で、エージェント３０に対して送信要求を通知す
る。

【００３４】エージェント３０は、テーブル監視モジュ
ール３４からの要求に応じて、管理情報テーブル３１か
ら障害関連情報を読出し、図３に示すような送信パケッ
トを作成し、マネージャ２に送信する（ステップＳ６，
Ｓ７）。

【００３５】以上の一連の動作がエージェント側で実行
された後に、図４（Ｂ）に示すように、マネージャ側の
処理に移行する。

【００３６】即ち、マネージャ２は、エージェント３０
から送信パケットによる障害関連情報を受信すると、シ
ステム全体の情報（ＭＩＢ）を更新し、障害に対処する
ために必要な制御内容を決定する（ステップＳ１０〜Ｓ
１２）。

【００３７】さらに、マネージャ２は、決定した制御内
容をエージェント３０に指示する（ステップＳ１３，Ｓ
１４）。エージェント３０は、マネージャ２からの制御
指示を受信すると、当該制御を実行することになる。マ
ネージャ２は、エージェント３０から制御の実行結果
（障害回復状況など）を示す応答メッセージを受信し、
障害回復結果等を認識する（ステップＳ１５）。

【００３８】ここで、マネージャ２は、エージェント３
０から受信した障害関連情報では当該障害処理を実行す
る上で不足している場合には、必要な情報をエージェン
ト３０に要求することになる。エージェント３０は、前
述の情報収集処理を再度実行して、マネージャ２から要
求された関連情報を送信する。

【００３９】以上のように本実施形態によれば、障害項
目に対応する障害関連情報がリンクされた構成の障害管
理テーブル３５を利用することにより、障害発生時に当
該障害処理に必要な障害関連情報を管理対象システム側
で自発的に収集する事ができる。エージェント３０は、
収集した障害関連情報を送信パケット形式でマネージャ
２側に送信することができる。従って、障害発生時に収
集したばかりの障害処理に有効な情報を、直ちにマネー
ジャ２側に送信することが可能となる。また、障害管理
テーブル３５に登録された監視タイマ値を使用して、障
害発生時からマネージャ２側に障害関連情報が到達する
までの時間を監視し、制限時間内に当該処理が完了する
ように制御することができる。これにより、マネージャ
２側には所定の制限時間内に必要最小限の障害関連情報
が送信されるため、不確定でかつ長時間を要する障害関
連情報の送信処理を改善できる。従って、従来の方式の
ような冗長な時間を費やすような事態は発生せずに、結
果として障害発生時から所定の時間内で障害処理を完了
することが可能となる。

【００４０】換言すれば、システムが障害処理を開始し
なければならない限界時間内に障害発生時の複数の障害
情報を収集できマネージャに通知することができる。即
ち、監視タイマを設定することにより限界時間内にマネ
ージャに通知することができる。従って、マネージャ側
は障害原因を特定するために必要な障害発生時の情報を
得ることができる。また、エージェントにおいてパケッ
トを作成する際、各情報が障害原因を特定するために有
効な情報なのかどうかを付加してマネージャに送ること
ができる。さらに、障害発生時の復旧処理に必要な情報
をまとめて送ることができるので、マネージャ側の処理
負荷を軽減でき、かつ結果として障害処理に要する時間
の短縮化を図ることができる。 （具体例）図５は、同実施形態のネットワーク管理シス
テムをビデオ・オン・デマンドを実現するストリーム配
信システムに適用した場合の具体例である。

【００４１】本システムは大別して、例えばハードディ
スクドライブ（ＨＤＤ）５２に蓄積された映像データ
（静止画像データを含む）をネットワーク１に送信する
サーバ５０と、当該映像データを受信して表示するクラ
イアント（ユーザ端末）５１と、当該システムの管理を
行う管理ステーション（管理端末）１０により構成され
ている。

【００４２】サーバ５０には、同実施形態におけるエー
ジェント３０および障害関連のモジュール・テーブル群
（３１〜３５）が実装されている。以下これらを総称し
て障害関連処理部５７として表記する。また、管理ステ
ーション１０には、同実施形態のマネージャ２機能が実
装されている。

【００４３】サーバ５０は、ＨＤＤ５２から映像データ
を読出して、メモリ５４に書き込むリード／ライト（Ｒ
／Ｗ）コントローラ５３と、当該メモリ５４から読出し
た映像データからなるストリームをネットワーク１に送
信する送信コントローラ５５とを有する。さらに、サー
バ５０は、メモリ５４上へのデータのリード／ライト動
作時でのパリティエラーを監視するエラーチェック回路
５６、及び前記の障害関連処理部５７を有する。

【００４４】障害関連処理部５７は、ネットワーク１を
介して管理ステーション１０に接続し、前述のＳＮＭＰ
などにより管理ステーション１０との間で障害関連情報
の交換を実行する。管理ステーション１０は、ＨＤＤ５
８にシステム全体の管理情報（ＭＩＢ）を格納して、シ
ステムの障害管理を含む各種のシステム管理を行う。

【００４５】以下図５と共に、図６、図７及び図８のフ
ローチャートを参照して動作を説明する。

【００４６】まず、図８に示すように、サーバ５０は、
クライアント５１からのストリーム送信要求（ビデオ配
信要求）を受信すると、その要求に応じた映像データの
ＨＤＤ５２の格納位置やどのストリームに映像データを
流せば良いか等のストリーム情報を決定する（ステップ
Ｓ２０，Ｓ２１）。

【００４７】Ｒ／Ｗコントローラ５３は、ＨＤＤ５２か
ら要求に応じた映像データを読出し、メモリ５４上に書
き込む（ステップＳ２２）。送信コントローラ５５は、
メモリ５４上から映像データを読出して、当該ストリー
ムをネットワーク１を介してクライアント５１に送信す
る（ステップＳ２４）。クライアント５１は、ストリー
ムを受信して再生する。サーバ５０は、要求された映像
データの全てを送信して終了となる（ステップＳ２
５）。

【００４８】ここで、Ｒ／Ｗコントローラ５３がＨＤＤ
５２読出した映像データをメモリ５４上に書き込むとき
に、メモリのパリティエラーが発生する場合を想定する
（ステップＳ２３のＹＥＳ）。このとき、エラーチェッ
ク回路５６は、パリティエラーを検出すると、割り込み
を発生させる。障害関連処理部５７は、当該割り込みを
受信すると、前述したような一連の障害処理を実行する
（ステップＳ２６〜Ｓ３０）。

【００４９】即ち、障害検出モジュール３３は障害管理
テーブル３５を参照し、管理対象モジュール３２に情報
の収集要求を出すと同時に、テーブル監視モジュール３
４にパリティエラーが発生したことを通知し、管理情報
テーブル３１の監視要求を出す。ここで、サーバ５０に
含まれる管理情報テーブル３１は、具体的には図６に示
すような管理情報を登録するテーブルである。

【００５０】この具体例では、メモリ５４にパリティエ
ラーが発生した場合に、メモリ５４のどこでエラーが発
生したか、どのストリームがどのような状態のときに発
生したか、またその発生時間が分かれば、その障害を回
復させることができるものと想定する。図６に示すよう
に、メモリ５４上のエラー発生位置（部位）に関する情
報がエラー発生情報である。ストリーム情報は、エラー
発生時のストリームを特定するための情報（ストリーム
ＩＤ）であり、送信開始・終了のイベントの度に変化す
る情報である。また、ストリーム情報は、ストリームの
コンテンツ（送信完了のストリーム情報）も含む。時間
情報は、ストリームの送信時間であり、ストリーム送信
時に刻々と変化する情報である。これらの情報が、メモ
リエラーに対する障害処理に必要な情報である。

【００５１】また、障害管理テーブル３５は、図９に示
すように、障害項目（Ｘ，Ｙ，Ｚとする）毎に、当該障
害の対応処理を行うために必要な複数の関連情報（ＤＡ
ＴＡ）、その付加情報（ＦＬＡＧ）、及び監視タイマ値
により構成されている。関連情報としては、前記のよう
に、エラー発生位置（部位）に関するエラー発生情報、
ストリームＩＤやコンテンツであるストリーム情報、ス
トリームの送信時間である時間情報などである。

【００５２】障害関連処理部５７の管理対象モジュール
３２は、パリティエラーの検出通知を受けると同時に複
数の最新の障害関連情報を収集し、管理情報テーブルを
更新する（ステップＳ２６，Ｓ２７）。即ち、図９に示
すように、複数のプログラム１〜Ｍがそれぞれ、対応す
る障害関連情報を収集し、管理情報テーブルの書き込み
を実行する。ここで、最新かどうかの判断は障害管理テ
ーブルのフラグを用いて判断する。また、刻々と変化す
る情報については、障害発生後にデータを上書きされる
前の障害発生時の情報を収集する必要がある。これにつ
いては、前述の監視タイマ機能を利用して、障害発生時
のデータを収集することができる。即ち、パリティエラ
ーが発生してから障害処理を開始しなければならない制
限時間を監視タイマ値に設定し、その制限時間内にでき
るだけ多くの関連情報を収集しマネージャ（管理ステー
ション１０）へ通知する。

【００５３】テーブル監視モジュール３４は、監視タイ
マ値（１０ｓ）に相当する時間経過の後に、収集した各
情報を一括してエージェントに通知する（図１０を参
照）。図１０は、テーブル監視モジュール３４の監視開
始から監視タイマによるタイムアウトまでのタイミング
チャートを示す。ここで、ＥＴ１〜ＥＴ３は、管理対象
モジュール３２のプログラム１によるエラー発生情報
（発生部位）の更新タイミングを示す。また、ＳＴ１，
ＳＴ２は、管理対象モジュール３２のプログラム２によ
るストリーム情報（発生部位）の更新タイミングを示
す。

【００５４】エージェントは、障害発生時のデータに更
新された各障害項目の値から図７に示すような送信パケ
ットを作成して、マネージャ（管理ステーション１０）
に送信する（ステップＳ２８〜Ｓ３０）。マネージャ１
０は、障害関連処理部５７から受信した情報（図７の送
信パケット）に基づいて、ＨＤＤ５８に格納しているシ
ステム全体の情報を更新し、かつ所定のストリームの復
旧処理を実行する。

【００５５】以上のように同実施形態のネットワーク管
理システムを、ビデオ・オン・デマンドを実現するスト
リーム配信システムに適用すると、メモリエラーのよう
な障害が発生しても、短時間に障害処理を実行して、中
断したストリーム配信処理を再開することが可能とな
る。 （変形例１）図１１および図１２は、同実施形態の変形
例１に関するタイミングチャートである。なお、本変形
例は、システム構成および基本的動作については、同実
施形態（図１から図４を参照）と同様である。

【００５６】本変形例の特徴は、監視タイマの使用方法
に関するものである。即ち、障害管理テーブル３５にセ
ットされた監視タイマ値を使用して、障害発生時からそ
の障害に関する情報をエージェント３０がマネージャ２
に通知するまでの限界時間を設定することができる。換
言すれば、エージェント３０は、制限時間までマネージ
ャ２へ情報を通知するのを待つことができる。また、エ
ージェント３０からマネージャ２に通知する時間を決め
ることができるので、マネージャ２が障害処理を開始す
る時間を操作することができる。

【００５７】以下図１１及び図１２を参照して、本変形
例を具体的に説明する。

【００５８】いま仮に、システムとして障害の復旧が完
了しなければならない時間（Ｔｒ）が設定されている場
合に、その障害復旧の作業としては管理対象システム２
０内で障害発生時に自動的に行われる方法と、管理対象
システム２０内での作業で復旧が完了しなかった場合に
行われるマネージャ２の制御による方法とが用意されて
いると想定する。

【００５９】システムとして障害復旧が完了しなければ
ならない時間（Ｔｒ）から、マネージャ側からの制御に
必要な時間（Ｔｎ）と、エージェント／マネージャ間の
通信時間とを差し引いた監視タイマ値を設定する。例え
ば障害項目（Ｘ）に相当する障害の発生時から監視タイ
マ値で定められた制限時間だけ待った時点で、管理対象
システム２０内の障害復旧処理が終了していない場合、
エージェント３０はマネージャ２に対して当該障害の関
連情報および復旧処理状況（障害復旧処理の失敗）をマ
ネージャに通知する。マネージャ２は、エージェント３
０から通知を受けた時点Ｔｓ１から復旧制御を開始する
（図１１を参照）。

【００６０】一方、障害発生時から監視タイマ値で定め
られた制限時間だけ待った時点で、管理対象システム２
０内の障害復旧処理が終了した場合は、エージェント３
０はその時点Ｔｓ２での関連情報・復旧処理状況（障害
復旧処理の成功）をエージェマネージャ２に通知する
（図１２を参照）。

【００６１】以上のように本変形例によれば、システム
が障害処理を開始しなければならない限界時間だけ待っ
て、障害発生時から制限時間までの複数の障害情報を収
集しマネージャに通知することができる。また、基本的
には同実施形態と同様であるが、監視タイマ機能の使用
方法の変更により、エージェント３０からマネージャ２
に障害関連情報を通知する時間を設定できるため、結果
としてマネージャ２が障害処理を開始する時間を操作す
ることが可能となる。 （変形例２）図１３および図１４は、同実施形態の変形
例２に関するフローチャートである。なお、本変形例
は、システム構成については同実施形態（図１から図３
を参照）と同様である。

【００６２】本変形例の特徴は、障害管理テーブル３５
の中の監視タイマ値をテーブル監視モジュール３４がシ
ステムの状態・情報により変更することができる機能で
ある。また、マネージャ２側からもテーブル監視モジュ
ール３４に対して変更指示を出すことにより、障害管理
テーブル３５の内容を変更することができる機能であ
る。

【００６３】まず、図１３のフローチャートを参照し
て、本変形例のエージェント３０側の処理について具体
的に説明する。

【００６４】管理対象システム２０上において、障害検
出モジュール３３が機器の障害の発生を検出すると、障
害管理テーブル３５を参照する（ステップＳ４０，Ｓ４
１）。さらに、障害検出モジュール３３は、障害管理テ
ーブル３５を参照することにより、当該障害処理に必要
な関連情報を認識し、さらに付加情報（ＦＬＡＧ）に従
って各情報毎に情報収集要求を管理対象モジュール３２
に出す。管理対象モジュール３２は、関連情報の収集処
理を実行する（ステップＳ４２）。

【００６５】また、障害検出モジュール３３は、テーブ
ル監視モジュール３４に対して、管理情報テーブル３１
の監視要求を出す。この要求に応じて、テーブル監視モ
ジュール３４は、障害管理テーブル３５から関連情報と
共に、監視タイマ値を取得して、管理情報テーブル３１
を監視する処理を開始する（ステップＳ４３）。

【００６６】このとき、テーブル監視モジュール３４
は、管理情報テーブル３１の監視によりシステム２０の
状態を認識して、この認識結果に基づいて障害管理テー
ブル３５上の監視タイマ値の書き換えを実行する（ステ
ップＳ４４〜Ｓ４６）。管理対象モジュール３２は、障
害検出モジュール３３からの指示に応じて障害関連情報
を収集し、管理情報テーブル３１に書き込む（ステップ
Ｓ４７）。

【００６７】テーブル監視モジュール３４は、障害管理
テーブル３５上の更新した（または維持された）監視タ
イマ値に基づいて、障害発生時からの時間経過を監視タ
イマにより監視している。この監視タイマがタイムアウ
トした時点で、テーブル監視モジュール３４は、エージ
ェント３０に対して送信要求を通知する（ステップＳ４
８のＹＥＳ）。なお、テーブル監視モジュール３４は、
監視タイマがタイムアウトする前でも、管理情報テーブ
ル３１に必要な関連情報の全てが登録された時点で、エ
ージェント３０に対して送信要求を通知する。エージェ
ント３０は、テーブル監視モジュール３４からの要求に
応じて、管理情報テーブル３１から障害関連情報を読出
して送信パケットを作成し、マネージャ２に送信する
（ステップＳ４９，Ｓ５０）。

【００６８】一方、図１４のフローチャートを参照し
て、本変形例のマネージャ２側の処理について具体的に
説明する。

【００６９】即ち、マネージャ２は、エージェント３０
からの応答メッセージに従って、一連の制御の結果を監
視している（ステップＳ６０）。ここで、制御タイムア
ウトの発生又は他のエラーが発生した場合に、マネージ
ャ２は、システム状態の変化を監視し、この監視結果に
基づいて障害管理テーブル３５の登録情報の変更を判断
する（ステップＳ６１〜Ｓ６３）。ここで、監視項目と
しては、例えばネットワーク負荷、ネットワーク障害、
マネージャ３の処理負荷等がある。

【００７０】マネージャ２は、障害管理テーブル３５の
登録情報の変更が必要であると判断すると、エージェン
ト３０に対して変更指示を行う（ステップＳ６４）。エ
ージェント３０側では、テーブル監視モジュール３４が
マネージャ２からの変更指示を受信すると、障害管理テ
ーブル３５の登録情報（監視タイマ値など）の書き換え
を実行する（ステップＳ６７）。エージェント３０は、
テーブル監視モジュール３４からの指示に応じて、変更
指示に対する応答メッセージを作成してマネージャ２に
送信する（ステップＳ６８）。マネージャ２は、応答メ
ッセージを受信すると、所定の処理に移行する（ステッ
プＳ６５）。

【００７１】以上のように本変形例によれば、システム
が障害処理を開始しなければならない限界時間内に障害
発生時の複数の障害情報を収集でき、マネージャに通知
することが可能であることは実施例と同様であるが、さ
らにシステム負荷等を検出して最適な監視タイマ値を設
定することができる。例えば、ネットワークが高負荷状
態であることを検出した場合には制御に費やす時間が短
くなる場合があり、そういった時には監視タイマの値も
短くしてやることにより適切な値となる。従って、例え
ばネットワークの状態が変化して高負荷の状態になった
り、他の処理プロセスの処理負荷が変化する等のシステ
ム状態の変化に対して、制御を失敗するといった影響を
うけることなく、より迅速な制御を行うことが可能とな
る。 （変形例３）図１５から図２１は、同実施形態の変形例
３に関する図である。なお、本変形例の基本的なシステ
ム構成は同実施形態（図１から図３を参照）と同様であ
る。

【００７２】本変形例の特徴は、障害管理テーブル３５
上において、障害関連情報をエージェント３０がマネー
ジャ２に通知する際のリトライ回数を設定した構成であ
る。これにより、マネージャ２への通知の確実性を高
め、かつエージェント／マネージャ間の送受信パケット
数を制限することができる。また、初回の障害通知とは
区別して、リトライによる通知であることをマネージャ
２側に認識させることが可能となる。

【００７３】以下、図１５から図１９を参照して本変形
例のシステムを説明する。

【００７４】本変形例は、図１５に示すように、各障害
項目（Ｘ，Ｙ…）毎にリトライ回数を有する示す障害管
理テーブル３５を使用する。このリトライ回数は、エー
ジェント３０からマネージャ２への障害関連情報の送信
リトライの回数を設定するための情報である。即ち、障
害通知の重要度が高いものについては障害管理テーブル
３５上にリトライ回数を定義し、エージェント３０は監
視タイマ値で定めた時間ごとにリトライ回数だけマネー
ジャ２へ障害情報を通知する。このとき、障害通知に成
功してマネージャ２からの制御指示があった場合には、
エージェント３０はリトライ回数未満でも、その時点で
送信リトライを中止する。

【００７５】このような構成であれば、障害発生時に一
度だけエージェント３０がマネージャ２に障害通知をし
ても、障害通知が確実に行われない場合があるが、リト
ライすることにより、マネージャ２側に障害通知（障害
関連情報の到達）を確実に行うことが可能となる。特
に、ネットワークの負荷を抑えるために、マネージャ２
がエージェント３０からの送信パケットの受信確認をエ
ージェント３０に行わないようなプロトコルを使用した
ネットワーク管理システムに有効である。

【００７６】また、本変形例の障害管理テーブル３５
は、図１５に示すように、付加情報（ＦＬＡＧ）として
２桁の数値情報を使用している。下位の１桁目は、前述
の実施形態の場合と同様である（図２を参照）。一方、
付加情報（ＦＬＡＧ）の上位１桁は、前記の送信リトラ
イの実行回数を示す情報である。即ち、エージェント３
０からマネージャ２への送信リトライが実行される毎
に、「０」、「１」、「２」、「３」と増加していく。
エージェント３０は、図１６に示すように、２桁の付加
情報（ＦＬＡＧ）を有する送信パケットを作成して、マ
ネージャ２側に送信する。

【００７７】このような本変形例について、さらに図１
７及び図１８を参照して具体的に説明する。

【００７８】図１７に示すように、障害発生後１度目の
監視タイマ値内では、エージェント側において必要最小
限の障害関連情報を収集できず、マネージャ２側への障
害通知が失敗する場合が想定できる。そこで、本変形例
のシステムでは、エージェント側は２度目の監視タイマ
値内での送信リトライ（障害関連情報の送信）を実行す
る。リトライでは、十分な障害関連情報が収集されてい
る可能性が高く、マネージャ２側への障害通知が成功す
る確率が高くなる。

【００７９】また、障害発生後１度目の監視タイマ値内
では、収集できなかった障害関連情報を送信リトライに
より、マネージャ２側に通知する場合が想定できる。即
ち、図１８に示すように、障害発生後１度目の監視タイ
マ値内では、関連情報（Ａ、Ｂ、Ｄ）のみからなる送信
パケットがマネージャ側に送信されて、関連情報（Ｃ）
については監視タイマ時間内に収集できなかった場合で
ある。そこで、２度目の監視タイマ値内でのリトライに
より、新たに収集できた関連情報（Ｃ）を含む送信パケ
ットをマネージャ側に送信できる。ここで、前述したよ
うに、送信パケットの付加情報（ＦＬＡＧ）の上位１桁
目が、１度目の「０」から２度目には「１」に変化して
いる。即ち、マネージャ側は、送信パケットの付加情報
（ＦＬＡＧ）の上位１桁目を参照することにより、初回
の送信による障害通知であるか、リトライ送信による障
害通知であるかを判断することができる。

【００８０】以上のように本変形例によれば、障害通知
のリトライ機能によりエージェントからマネージャへの
障害通知の確実性を高めることができる。この場合、リ
トライ回数を定義することにより、エージェント／マネ
ージャ間のパケット送受信によるネットワーク負荷を制
限しながら、障害通知の確実性を高めることができる。
また、リトライ機能により、監視タイマ値ごとに新しい
障害情報を定期的にマネージャに送信することができ
る。

【００８１】図１９から図２１は、本変形例の補足説明
を行うための概念図である。

【００８２】即ち、管理情報テーブル３１に格納されて
いる情報は、管理対象モジュール３２によって障害発生
時に書き換えられる他、定期的に更新される情報もあ
る。従って障害発生時から監視タイマ値ごとにエージェ
ント３０からマネージャ２へリトライ送信している間
に、管理情報テーブル３１の情報が更新され、障害発生
時の情報と異なるものをマネージャ２に送信する場合も
考えられる。このような場合を考慮して、マネージャ２
側においてエージェント３０から受信した情報を格納し
ておき、リトライ毎に送信されてきた関連情報と付加情
報（ＦＬＡＧ）を比較して、格納してあった情報の更新
処理が必要であるかどうかを判断するしくみを用意する
必要がある。

【００８３】図１９はその具体例を示すものであり、障
害発生に伴い関連情報（Ａ，Ｂ，Ｃ，Ｄ）を収集して通
知する場合である。ここでは、関連情報Ｃが収集される
までリトライ送信を繰り返している間に管理情報テーブ
ル３１の関連情報Ｂが更新された例を示している。障害
発生後一度目の送信では、関連情報Ｂはマネージャ２に
対して障害発生時の情報を通知できているが、リトライ
２回目では障害発生後に更新された情報が通知されてい
る。

【００８４】以上のような場合を考慮して、マネージャ
２側でエージェント３０から受信した情報を格納してお
き、リトライの度に送信された障害関連情報と比較し処
理をする機能が必要になる。以下、図２０及び図２１を
参照して説明する。

【００８５】先ず、マネージャ２側ではエージェント３
０から障害情報を受信した際には、その関連情報と付加
情報（ＦＬＡＧ）からなる受信パケットをＨＤＤ１００
に保存する。そして、リトライにより新たな障害情報２
０１を受信したときには、マネージャ２は既にＨＤＤ１
００に格納されている情報２００との比較を行う（図２
１を参照）。マネージャ２側は、付加情報（ＦＬＡＧ）
の下位１桁目の情報に基づいて、「０」から「１」に変
化している関連情報（ここではＣ）については新たに受
信した情報２０１から選択して更新する。また、付加情
報（ＦＬＡＧ）の下位１桁の情報が「１」のまま変化し
ない情報については、すでに障害発生時の情報が通知さ
れていると判断し、ＨＤＤ１００に格納してある情報の
更新はしない。さらに、下位１桁の情報が「１」から
「０」に変化した情報についても、すでに通知されてい
ると判断するので、情報の更新はしない。以上のように
して、ＨＤＤ１００には、比較処理の後に更新された障
害関連情報２０２が格納されることになる。

【００８６】なお、同実施形態の監視タイマ値の設定基
準は、障害処理を実行する上で必要な障害関連情報の通
知時間の制限値に基づいている。具体的には、例えばフ
ァンが停止して所定の時間が経過すると、システムによ
ってはハード的に熱が帯びて、制限温度を越えてしまう
場合がある。このようなシステムでは、その温度に達す
る前に障害関連情報を通知する必要があるため、これを
基準として当該監視タイマ値を設定することになる。

【００８７】

【発明の効果】以上詳述したように本発明によれば、特
にマネージャ／エージェント方式によるネットワーク管
理システムにおいて、管理対象システムの障害発生から
障害処理が完了するまでに要する時間を短縮化し、結果
としてシステムに設定された所定の制限時間内に障害回
復などの障害管理処理を完了することができる。従っ
て、障害発生時にマネージャ側は、障害処理に必要な障
害関連情報の全てを受信できる可能性が高くなり、当該
障害関連情報をエージェント側に要求する処理を大幅に
減少することが可能となる。これにより、マネージャ側
の処理負担の軽減および障害処理に要する時間の短縮化
（冗長時間の削減）を実現できる。

【図面の簡単な説明】

【図１】本発明の実施形態に関係するネットワーク管理
システムの基本的構成を示すブロック図。

【図２】同実施形態の障害管理テーブルの構成を説明す
るための概念図。

【図３】同実施形態のエージェントが送信する送信パケ
ットの構成を示す概念図。

【図４】同実施形態のシステムにおける一連の障害処理
を説明するためのフローチャート。

【図５】同実施形態のシステムを適用したストリーム配
信システムの具体例を示すブロック図。

【図６】同具体例での管理情報テーブルの構成を示す概
念図。

【図７】同具体例での送信パケットの構成を示す概念
図。

【図８】同具体例でのメモリエラー処理を説明するため
のフローチャート。

【図９】同具体例での障害管理テーブルの構成を説明す
るための概念図。

【図１０】同具体例でのメモリエラー処理を説明するた
めのタイミングチャート。

【図１１】同実施形態の変形例１に関係するタイミング
チャート。

【図１２】同変形例１に関係するタイミングチャート。

【図１３】同実施形態の変形例２に関係するフローチャ
ート。

【図１４】同変形例２に関係するフローチャート。

【図１５】同実施形態の変形例３に関係する障害管理テ
ーブルの構成を説明するための概念図。

【図１６】同変形例３に関係する送信パケットの構成を
示す概念図。

【図１７】同変形例３に関係するタイミングチャート。

【図１８】同変形例３に関係するタイミングチャート。

【図１９】同変形例３に関係するタイミングチャート。

【図２０】同変形例３に関係するシステム構成を示す概
念図。

【図２１】同変形例３に関係する概念図。

【図２２】従来のネットワーク管理システムの概念を示
すブロック図。

【図２３】同ネットワーク管理システムの動作を説明す
るためのタイミングチャート。

【図２４】同ネットワーク管理システムの動作を説明す
るためのフローチャート。

【符号の説明】

１…ネットワーク ２…マネージャ １０…管理ステーション １１…管理コンソール ２０…管理対象システム ３０…エージェント ３１…管理情報テーブル ３２…管理対象モジュール ３３…障害検出モジュール ３４…管理情報テーブル監視モジュール ３５…障害管理テーブル ５０…サーバ ５１…クライアント ５２…ＨＤＤ ５３…リード／ライト（Ｒ／Ｗ）コントローラ ５４…メモリ ５５…送信コントローラ ５６…エラーチェック回路 ５７…障害関連処理部

Claims (10)

【特許請求の範囲】
1. 【請求項１】 ネットワークの障害管理機能を有するネ
   ットワーク管理システムに対して、当該ネットワークに
   接続されたネットワーク機器の障害関連情報を送信する
   機能を有する障害管理システムであって、 前記ネットワーク機器の障害内容に対応して予め設定さ
   れる障害関連情報を登録するための障害管理テーブル手
   段と、 前記ネットワーク機器の障害発生時に、前記障害管理テ
   ーブル手段を参照して当該障害内容に対応する障害関連
   情報を収集する情報収集手段と、 前記情報収集手段により収集された障害関連情報を前記
   ネットワーク管理システムに送信する送信手段とを具備
   したことを特徴とする障害管理システム。
2. 【請求項２】 ネットワークの障害管理機能を有するネ
   ットワーク管理システムに対して、当該ネットワークに
   接続されたネットワーク機器の障害関連情報を送信する
   機能を有する障害管理システムであって、 前記ネットワーク機器の障害内容に対応して予め設定さ
   れる障害関連情報および障害発生時から当該障害関連情
   報を前記ネットワーク管理システムに送信するまでの制
   限時間を監視するための監視時間情報を登録するための
   障害管理テーブル手段と、 前記ネットワーク機器の障害発生時に、前記障害管理テ
   ーブル手段を参照して当該障害内容に対応する障害関連
   情報を収集する情報収集手段と、 前記監視時間情報に基づいて前記情報収集手段により収
   集された障害関連情報を、予め設定された制限時間内に
   前記ネットワーク管理システムに送信する送信手段とを
   具備したことを特徴とする障害管理システム。
3. 【請求項３】 ネットワーク上においてエージェントと
   マネージャ間で所定のプロトコルを使用して情報を交換
   し、当該情報に基づいて障害管理を行う機能を有するネ
   ットワーク管理システムであって、 ネットワーク上の管理対象システムの障害発生時に、管
   理情報テーブル手段を参照して当該障害管理に必要な管
   理情報を生成して送信する機能を有するエージェント手
   段と、 前記管理対象システムの障害内容に対応して予め設定さ
   れる障害関連情報を登録するための障害管理テーブル手
   段と、 前記管理対象システムの障害発生時に、前記障害管理テ
   ーブル手段を参照して当該障害内容に対応する障害関連
   情報を収集して、前記管理情報テーブル手段に登録する
   情報収集手段と、 前記エージェント手段から送信された前記障害関連情報
   を含む前記管理情報に基づいて、前記管理対象システム
   の障害管理に必要な制御を行うマネージャ手段とを具備
   したことを特徴とするネットワーク管理システム。
4. 【請求項４】 前記障害管理テーブル手段は、前記管理
   対象システムの障害発生時から前記エージェント手段が
   前記マネージャ手段に前記障害関連情報を含む前記管理
   情報を送信するまでの制限時間を規定した監視時間情報
   を登録していることを特徴とする請求項３記載のネット
   ワーク管理システム。
5. 【請求項５】 前記管理対象システムの障害発生時に、
   前記障害管理テーブル手段を参照して前記管理情報テー
   ブル手段を監視し、前記管理情報テーブル手段に所定の
   前記障害関連情報が登録されたときに、前記エージェン
   ト手段に対して前記障害関連情報を前記マネージャ手段
   に送信することを指示するためのテーブル監視モジュー
   ル手段を有することを特徴とする請求項３記載のネット
   ワーク管理システム。
6. 【請求項６】 前記障害管理テーブル手段に設定する前
   記監視時間情報に基づいて、前記マネージャ手段が前記
   障害関連情報の受信に応じて実行する障害処理の開始時
   点を設定する手段を有することを特徴とする請求項３記
   載のネットワーク管理システム。
7. 【請求項７】 前記障害管理テーブル手段に設定する前
   記監視時間情報を、システムの状態変化または前記マネ
   ージャ手段からの要求に応じて更新する手段を有するこ
   とを特徴とする請求項３記載のネットワーク管理システ
   ム。
8. 【請求項８】 前記障害管理テーブル手段は、予め設定
   される障害項目毎に障害処理に必要な障害関連情報と、
   当該各障害関連情報の収集状況を示す付加情報と、障害
   発生時から当該障害関連情報を送信するまでの制限時間
   を規定した監視時間情報とを有することを特徴とする請
   求項１または請求項２のいずれか記載の障害管理システ
   ム、あるいは請求項３から請求項７のいずれか記載のネ
   ットワーク管理システム。
9. 【請求項９】 前記エージェント手段は、前記マネージ
   ャ手段に前記障害関連情報を含む前記管理情報を送信す
   る送信処理を、所定の条件に基づいて再実行するリトラ
   イ手段を有することを特徴とする請求項３記載のネット
   ワーク管理システム。
10. 【請求項１０】 前記リトライ手段は、前記障害管理テ
    ーブル手段に設定されたリトライ回数情報に基づいてリ
    トライ回数を制御する機能を有することを特徴とする請
    求項９記載のネットワーク管理システム。