JP2001024635A - 障害管理方式および方法 - Google Patents
障害管理方式および方法Info
- Publication number
- JP2001024635A JP2001024635A JP18886899A JP18886899A JP2001024635A JP 2001024635 A JP2001024635 A JP 2001024635A JP 18886899 A JP18886899 A JP 18886899A JP 18886899 A JP18886899 A JP 18886899A JP 2001024635 A JP2001024635 A JP 2001024635A
- Authority
- JP
- Japan
- Prior art keywords
- agent
- manager
- request
- state change
- state
- 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.)
- Granted
Links
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Maintenance And Management Of Digital Transmission (AREA)
Abstract
(57)【要約】
【課題】ＳＮＭＰプロトコルを用いたネットワーク管理
システムにおいて、ＴＲＡＰを用いることなく、ネット
ワークに負荷をかけないようにしながらエージェント監
視状態を獲得することにある。 【解決手段】監視端末１は状態変化確認を行うＧｅｔＲ
ｅｑｕｅｓｔを被監視装置２に対して発行する。監視端
末１は、ＧｅｔＲｅｓｐｏｎｓｅにより状態変化なしの
通知を受けると、一定時間後に状態変化確認を行うＧｅ
ｔＲｅｑｕｅｓｔを再度発行する。一方、被監視端末２
のおいて状態変化が発生すると状態格納エリア２３に発
生順にＩＤと状態とを記憶する。すると、被監視端末２
は、応答として、状態格納エリア２３から一番古いＩＤ
をＧｅｔＲｅｓｐｏｎｓｅに付加して監視端末１に返
す。監視端末１はそのＩＤの状態を読み出すようにＧｅ
ｔＲｅｑｕｅｓｔを被監視端末２に対して発行すること
によって最新状態を獲得する。
システムにおいて、ＴＲＡＰを用いることなく、ネット
ワークに負荷をかけないようにしながらエージェント監
視状態を獲得することにある。 【解決手段】監視端末１は状態変化確認を行うＧｅｔＲ
ｅｑｕｅｓｔを被監視装置２に対して発行する。監視端
末１は、ＧｅｔＲｅｓｐｏｎｓｅにより状態変化なしの
通知を受けると、一定時間後に状態変化確認を行うＧｅ
ｔＲｅｑｕｅｓｔを再度発行する。一方、被監視端末２
のおいて状態変化が発生すると状態格納エリア２３に発
生順にＩＤと状態とを記憶する。すると、被監視端末２
は、応答として、状態格納エリア２３から一番古いＩＤ
をＧｅｔＲｅｓｐｏｎｓｅに付加して監視端末１に返
す。監視端末１はそのＩＤの状態を読み出すようにＧｅ
ｔＲｅｑｕｅｓｔを被監視端末２に対して発行すること
によって最新状態を獲得する。
Description
【０００１】
【発明の属する技術分野】本発明は、通信ネットワーク
のネットワーク管理に関し、特にネットワーク管理プロ
トコルであるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ
ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を用いた
障害管理方式および方法に関する。
のネットワーク管理に関し、特にネットワーク管理プロ
トコルであるＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ
ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を用いた
障害管理方式および方法に関する。
【０００２】
【従来の技術】従来のこの種の障害管理方式は、例え
ば、特開平９−１０１９３２号公報および特開平１０−
３３４０１１号公報に記載されているように、ＳＮＭＰ
プロトコルを用いたネットワーク管理システムにおい
て、エージェントの障害状態をマネージャに通知する場
合、ＴＲＡＰメッセージを用いて行っている。このと
き、ＴＲＡＰメッセージ抜けが生じた場合に、再度ＴＲ
ＡＰメッセージを送信するという手順を取っている。
ば、特開平９−１０１９３２号公報および特開平１０−
３３４０１１号公報に記載されているように、ＳＮＭＰ
プロトコルを用いたネットワーク管理システムにおい
て、エージェントの障害状態をマネージャに通知する場
合、ＴＲＡＰメッセージを用いて行っている。このと
き、ＴＲＡＰメッセージ抜けが生じた場合に、再度ＴＲ
ＡＰメッセージを送信するという手順を取っている。
【０００３】
【発明が解決しようとする課題】しかしながら、従来の
障害管理方式は、ＳＮＭＰはＵＤＰ（Ｕｓｅｒ Ｄａｔ
ａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を利用したコネクショ
ンレスのプロトコルのため、エージェントから通知され
たＴＲＡＰメッセージが必ずしもマネージャに届くとは
限らない。そのため、ＴＲＡＰメッセージが抜けないよ
うに再度送信する手順をとっているので、ネットワーク
の負荷が高いときにＴＲＡＰメッセージを送信すると、
ネットワーク上に過度の負荷をかけると共に、最悪の場
合にはＴＲＡＰメッセージ抜けが発生するいう問題点が
ある。
障害管理方式は、ＳＮＭＰはＵＤＰ（Ｕｓｅｒ Ｄａｔ
ａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を利用したコネクショ
ンレスのプロトコルのため、エージェントから通知され
たＴＲＡＰメッセージが必ずしもマネージャに届くとは
限らない。そのため、ＴＲＡＰメッセージが抜けないよ
うに再度送信する手順をとっているので、ネットワーク
の負荷が高いときにＴＲＡＰメッセージを送信すると、
ネットワーク上に過度の負荷をかけると共に、最悪の場
合にはＴＲＡＰメッセージ抜けが発生するいう問題点が
ある。
【０００４】また、マネージャはＴＲＡＰメッセージが
届かない場合を考慮して全監視項目の状態をＧｅｔ Ｒ
ｅｑｕｅｓｔメッセージまたはＧｅｔ Ｎｅｘｔ Ｒｅ
ｑｕｅｓｔメッセージを利用して定期的にエージェント
に対して獲得に行かなければ正しい状態を獲得できない
という問題点がある。
届かない場合を考慮して全監視項目の状態をＧｅｔ Ｒ
ｅｑｕｅｓｔメッセージまたはＧｅｔ Ｎｅｘｔ Ｒｅ
ｑｕｅｓｔメッセージを利用して定期的にエージェント
に対して獲得に行かなければ正しい状態を獲得できない
という問題点がある。
【０００５】また、定期的に全監視項目の状態の獲得を
行う場合、最初の獲得から次の獲得までのポーリング時
間を長くすると障害を認識できない状態が常に長くなっ
てしまい、逆にポーリング時間を短くすると障害状態は
すぐ認識できるがネットワークの負荷があがってしまい
ＴＲＡＰメッセージ漏れの可能性が増大してしまうとい
う問題点がある。
行う場合、最初の獲得から次の獲得までのポーリング時
間を長くすると障害を認識できない状態が常に長くなっ
てしまい、逆にポーリング時間を短くすると障害状態は
すぐ認識できるがネットワークの負荷があがってしまい
ＴＲＡＰメッセージ漏れの可能性が増大してしまうとい
う問題点がある。
【０００６】本発明の目的は、上記問題点を鑑み、ＳＮ
ＭＰプロトコルを用いたネットワーク管理システムにお
いて、エージェントの状態の監視する手段としてＴＲＡ
Ｐメッセージを用いないでＧｅｔＲｅｑｕｅｓｔだけを
用い、ネットワークに負荷をかけないようにしながらで
きるだけリアルタイムに監視状態を獲得する方式を提供
することにある。
ＭＰプロトコルを用いたネットワーク管理システムにお
いて、エージェントの状態の監視する手段としてＴＲＡ
Ｐメッセージを用いないでＧｅｔＲｅｑｕｅｓｔだけを
用い、ネットワークに負荷をかけないようにしながらで
きるだけリアルタイムに監視状態を獲得する方式を提供
することにある。
【０００７】
【課題を解決するための手段】上記の目的を達成するた
めに、本発明の第１の障害管理方式は、マネージャがＳ
ＮＭＰプロトコルを用いて複数のエージェントの障害の
ネットワ−ク管理を行う障害管理方式において、前記マ
ネージャが一定時間毎に前記エージェントの状態変化の
有無の確認要求を行う第１の要求手段と、前記エージェ
ントは、前記第１の要求手段による確認要求が前記エー
ジェントにあると前記エージェン状態変化の有無を前記
マネージャに通知する第１の通知手段と、前記マネージ
ャが前記第１の通知手段により前記状態変化を検出した
場合に前記状態変化の内容の読出要求を前記エージェン
トに行う第２の要求手段と、前記第２の要求手段による
要求があると前記状態変化の内容を前記マネージャに通
知する第２の通知手段とを有することを特徴としてい
る。
めに、本発明の第１の障害管理方式は、マネージャがＳ
ＮＭＰプロトコルを用いて複数のエージェントの障害の
ネットワ−ク管理を行う障害管理方式において、前記マ
ネージャが一定時間毎に前記エージェントの状態変化の
有無の確認要求を行う第１の要求手段と、前記エージェ
ントは、前記第１の要求手段による確認要求が前記エー
ジェントにあると前記エージェン状態変化の有無を前記
マネージャに通知する第１の通知手段と、前記マネージ
ャが前記第１の通知手段により前記状態変化を検出した
場合に前記状態変化の内容の読出要求を前記エージェン
トに行う第２の要求手段と、前記第２の要求手段による
要求があると前記状態変化の内容を前記マネージャに通
知する第２の通知手段とを有することを特徴としてい
る。
【０００８】更に、上記第１の障害処理方式において、
前記第２の要求手段は前記第１の要求手段を含み、前記
第２の通知手段は前記第１の通知手段を含むことを特徴
としている。
前記第２の要求手段は前記第１の要求手段を含み、前記
第２の通知手段は前記第１の通知手段を含むことを特徴
としている。
【０００９】更に、上記第１の障害処理方式において、
前記第１の通知手段は、前記エージェントが既に状態変
化を検出した状態の時に前記第１の要求手段による確認
要求が前記エージェントにあると前記エージェントが前
記エージェン状態変化のあったことを前記マネージャに
通知し、前記エージェントに状態変化を検出していない
状態の時に前記第１の要求手段による確認要求が前記エ
ージェントにあると前記エージェントが前記エージェン
に状態変化のあったことを前記マネージャに通知するこ
とを特徴としている。
前記第１の通知手段は、前記エージェントが既に状態変
化を検出した状態の時に前記第１の要求手段による確認
要求が前記エージェントにあると前記エージェントが前
記エージェン状態変化のあったことを前記マネージャに
通知し、前記エージェントに状態変化を検出していない
状態の時に前記第１の要求手段による確認要求が前記エ
ージェントにあると前記エージェントが前記エージェン
に状態変化のあったことを前記マネージャに通知するこ
とを特徴としている。
【００１０】また、本発明の第２の障害処理方式は、マ
ネージャがＳＮＭＰプロトコルを用いて複数のエージェ
ントの障害のネットワ−ク管理を行う障害管理方式にお
いて、前記マネージャが前記エージェントの状態変化の
有無の確認要求を行う第１の要求手段と、前記マネージ
ャが前記第１の要求手段で状態変化がない場合に一定時
間たってから前記第１の要求手段を繰り返す繰り返し手
段と、前記エージェントが状態変化を検出する毎にその
状態変化の内容を履歴情報として記憶する記憶手段と、
前記第１の要求手段による確認要求が前記エージェント
にあると前記エージェントが前記記憶手段で記憶されて
いる前記履歴情報を検索することにより状態変化の有無
を前記マネージャに通知する第１の通知手段と、前記マ
ネージャが前記第１の通知手段により前記状態変化を検
出した場合に前記状態変化の内容の読出要求と新たな状
態変化の確認要求とを前記エージェントに同時に行う第
２の要求手段と、前記第２の要求手段による要求がある
と前記エージェントが前記記憶手段で記憶された履歴情
報を検索することにより前記状態変化の内容と前記新た
な状態変化の有無とを前記マネージャに通知する第２の
通知手段とを有することを特徴としている。
ネージャがＳＮＭＰプロトコルを用いて複数のエージェ
ントの障害のネットワ−ク管理を行う障害管理方式にお
いて、前記マネージャが前記エージェントの状態変化の
有無の確認要求を行う第１の要求手段と、前記マネージ
ャが前記第１の要求手段で状態変化がない場合に一定時
間たってから前記第１の要求手段を繰り返す繰り返し手
段と、前記エージェントが状態変化を検出する毎にその
状態変化の内容を履歴情報として記憶する記憶手段と、
前記第１の要求手段による確認要求が前記エージェント
にあると前記エージェントが前記記憶手段で記憶されて
いる前記履歴情報を検索することにより状態変化の有無
を前記マネージャに通知する第１の通知手段と、前記マ
ネージャが前記第１の通知手段により前記状態変化を検
出した場合に前記状態変化の内容の読出要求と新たな状
態変化の確認要求とを前記エージェントに同時に行う第
２の要求手段と、前記第２の要求手段による要求がある
と前記エージェントが前記記憶手段で記憶された履歴情
報を検索することにより前記状態変化の内容と前記新た
な状態変化の有無とを前記マネージャに通知する第２の
通知手段とを有することを特徴としている。
【００１１】更に、上記第１または第２の障害処理方式
において、前記第１および第２の要求手段は、ＧｅｔＲ
ｅｑｕｅｓｔメッセージを使用して要求を行うことを特
徴としている。
において、前記第１および第２の要求手段は、ＧｅｔＲ
ｅｑｕｅｓｔメッセージを使用して要求を行うことを特
徴としている。
【００１２】更に、上記第１または第２の障害処理方式
において、前記第１および第２の通知手段は、ＧｅｔＲ
ｅｓｐｏｎｓｅメッセージを使用して通知することを特
徴としている。
において、前記第１および第２の通知手段は、ＧｅｔＲ
ｅｓｐｏｎｓｅメッセージを使用して通知することを特
徴としている。
【００１３】更に、上記第２の障害処理方式において、
前記記憶手段は、前記状態変化の起こったオブジェクト
ＩＤ（監視対象項目識別番号）とその状態変化の内容と
を発生した順に記憶していくことを特徴としている。
前記記憶手段は、前記状態変化の起こったオブジェクト
ＩＤ（監視対象項目識別番号）とその状態変化の内容と
を発生した順に記憶していくことを特徴としている。
【００１４】更に、上記第２の障害処理方式において、
前記第１の通知手段は、前記記憶手段に記憶された一番
古いオブジェクトＩＤを前記マネージャに通知すること
を特徴としている。
前記第１の通知手段は、前記記憶手段に記憶された一番
古いオブジェクトＩＤを前記マネージャに通知すること
を特徴としている。
【００１５】更に、上記第２の障害処理方式において、
前記第２の要求手段は、前記第１の通知手段で通知のあ
ったオブジェクトＩＤの状態変化の内容の読出要求を行
うことを特徴としている。
前記第２の要求手段は、前記第１の通知手段で通知のあ
ったオブジェクトＩＤの状態変化の内容の読出要求を行
うことを特徴としている。
【００１６】また、本発明の第１の障害処理方法は、マ
ネージャがＳＮＭＰプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記マネージャは一定時間毎に前記エージェン
トの状態変化の有無の確認要求を行い、前記エージェン
トは既に状態変化を検出した状態の時に前記マネージャ
から前記状態変化の有無の確認要求があった場合に状態
変化のあったことをマネージャに通知し、前記マネージ
ャは前記エージェントから前記状態変化のあったという
通知を受けると前記状態変化の内容の読出要求を前記エ
ージェントに行い、前記エージェントは前記マネージャ
から前記状態変化の内容の読出要求があると前記状態変
化の内容を前記マネージャに通知することを特徴として
いる。
ネージャがＳＮＭＰプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記マネージャは一定時間毎に前記エージェン
トの状態変化の有無の確認要求を行い、前記エージェン
トは既に状態変化を検出した状態の時に前記マネージャ
から前記状態変化の有無の確認要求があった場合に状態
変化のあったことをマネージャに通知し、前記マネージ
ャは前記エージェントから前記状態変化のあったという
通知を受けると前記状態変化の内容の読出要求を前記エ
ージェントに行い、前記エージェントは前記マネージャ
から前記状態変化の内容の読出要求があると前記状態変
化の内容を前記マネージャに通知することを特徴として
いる。
【００１７】また、本発明の第２の障害処理方法は、マ
ネージャがＳＮＭＰプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記エージェントが状態変化を検出する毎に状
態変化のあったオブジェクトＩＤ（監視対象項目識別番
号）とその状態変化の内容とを検出順に格納した格納エ
リアを用いて、前記マネージャは一定時間毎に前記エー
ジェントの状態変化の有無の確認要求を行い、前記エー
ジェントは前記マネージャから前記状態変化の有無の確
認要求があった場合に前記格納エリアに格納されていれ
ば状態変化の有を示す一番古い履歴のオブジェクトＩＤ
を，前記格納エリアに格納されていなければ状態変化の
ないことをそれぞれマネージャに通知し、前記マネージ
ャは前記状態変化が有の場合に前記通知のあったオブジ
ェクトＩＤの状態変化の内容の読出要求と新たな状態変
化の有無の確認要求とを前記エージェントに行い、前記
エージェントは前記マネージャから前記オブジェクトＩ
Ｄの状態変化の内容の読出要求と新たな状態変化の有無
の確認要求とがあると前記オブジェクトＩＤの状態変化
の内容と新たな状態変化の有無とを前記マネージャに通
知することを特徴としている。
ネージャがＳＮＭＰプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記エージェントが状態変化を検出する毎に状
態変化のあったオブジェクトＩＤ（監視対象項目識別番
号）とその状態変化の内容とを検出順に格納した格納エ
リアを用いて、前記マネージャは一定時間毎に前記エー
ジェントの状態変化の有無の確認要求を行い、前記エー
ジェントは前記マネージャから前記状態変化の有無の確
認要求があった場合に前記格納エリアに格納されていれ
ば状態変化の有を示す一番古い履歴のオブジェクトＩＤ
を，前記格納エリアに格納されていなければ状態変化の
ないことをそれぞれマネージャに通知し、前記マネージ
ャは前記状態変化が有の場合に前記通知のあったオブジ
ェクトＩＤの状態変化の内容の読出要求と新たな状態変
化の有無の確認要求とを前記エージェントに行い、前記
エージェントは前記マネージャから前記オブジェクトＩ
Ｄの状態変化の内容の読出要求と新たな状態変化の有無
の確認要求とがあると前記オブジェクトＩＤの状態変化
の内容と新たな状態変化の有無とを前記マネージャに通
知することを特徴としている。
【００１８】更に、上記第２の障害処理方法において、
前記エージェントは前記マネージャに前記オブジェクト
ＩＤの状態変化の内容を通知すると前記格納エリアから
通知した状態情報を消すことを特徴としている。
前記エージェントは前記マネージャに前記オブジェクト
ＩＤの状態変化の内容を通知すると前記格納エリアから
通知した状態情報を消すことを特徴としている。
【００１９】
【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して説明する。図１を参照すると、本発明
の実施の形態は、ＬＡＮまたはＷＡＮに接続されたネッ
トワーク３と、ネットワーク３に接続されＳＮＭＰのマ
ネージャ（ネットワークを管理する）である監視端末１
と、ネットワーク３に接続されＳＮＭＰのエージェント
である複数の被監視端末２とから構成される。
て図面を参照して説明する。図１を参照すると、本発明
の実施の形態は、ＬＡＮまたはＷＡＮに接続されたネッ
トワーク３と、ネットワーク３に接続されＳＮＭＰのマ
ネージャ（ネットワークを管理する）である監視端末１
と、ネットワーク３に接続されＳＮＭＰのエージェント
である複数の被監視端末２とから構成される。
【００２０】監視端末１はＳＮＭＰのインターフェース
部であるＳＮＭＰマネージャ制御部１１と、ＳＮＭＰを
用いて獲得した状態を解析する監視解析部１３と、解析
した結果を表示する監視表示部１２とから構成される。
部であるＳＮＭＰマネージャ制御部１１と、ＳＮＭＰを
用いて獲得した状態を解析する監視解析部１３と、解析
した結果を表示する監視表示部１２とから構成される。
【００２１】被監視端末２は、ＳＮＭＰを用いてマネー
ジャと通信するＳＮＭＰエージェント制御部２１と、自
装置における不具合等の監視を行っている監視処理部２
２と、監視処理部２２で検出した監視状態を記憶してい
る状態格納エリア２３から構成される。なお、状態格納
エリア２３は図１に記載されていない被監視端末２内に
ある記憶部に割り付けられており、この状態格納エリア
２３には、監視状態が検出される度に順々に格納されて
いく（履歴が取られる）。
ジャと通信するＳＮＭＰエージェント制御部２１と、自
装置における不具合等の監視を行っている監視処理部２
２と、監視処理部２２で検出した監視状態を記憶してい
る状態格納エリア２３から構成される。なお、状態格納
エリア２３は図１に記載されていない被監視端末２内に
ある記憶部に割り付けられており、この状態格納エリア
２３には、監視状態が検出される度に順々に格納されて
いく（履歴が取られる）。
【００２２】被監視端末２の監視処理部２２は、被監視
端末２で必要な監視項目をすべて処理しており、障害が
発生または復旧した場合はその都度状態格納エリア２３
に状態変化のあった項目のオブジェクトＩＤ［ＭＩＢ
（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂ
ａｓｅ：管理情報ベース）のオブジェクトＩＤに対応］
およびその状態を記憶する。
端末２で必要な監視項目をすべて処理しており、障害が
発生または復旧した場合はその都度状態格納エリア２３
に状態変化のあった項目のオブジェクトＩＤ［ＭＩＢ
（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂ
ａｓｅ：管理情報ベース）のオブジェクトＩＤに対応］
およびその状態を記憶する。
【００２３】また、被監視端末２の監視処理部２２は、
被監視端末２自身の状態を監視している。この状態の監
視対象項目は、項目Ａ、項目Ｂ、項目Ｃ、項目Ｄの４つ
あるとする。被監視端末２の監視処理部２２が監視対象
項目に対する状態の変化を検出すると、検出した順に、
オブジェクトＩＤ（各項目に付けられたＩＤ名：監視対
象項目識別番号）と、そのときの状態の値（コードで管
理）を状態格納エリア内に格納していく。なお、このと
きの監視処理部２２の状態変化の監視方法として、ポー
リングで各項目を見に行く監視方法、および発生時の割
込による監視方法があるが、どちらの場合も適用でき
る。
被監視端末２自身の状態を監視している。この状態の監
視対象項目は、項目Ａ、項目Ｂ、項目Ｃ、項目Ｄの４つ
あるとする。被監視端末２の監視処理部２２が監視対象
項目に対する状態の変化を検出すると、検出した順に、
オブジェクトＩＤ（各項目に付けられたＩＤ名：監視対
象項目識別番号）と、そのときの状態の値（コードで管
理）を状態格納エリア内に格納していく。なお、このと
きの監視処理部２２の状態変化の監視方法として、ポー
リングで各項目を見に行く監視方法、および発生時の割
込による監視方法があるが、どちらの場合も適用でき
る。
【００２４】監視端末１と複数の被監視端末２との間で
ＳＮＭＰを用いたプロトコルで情報のやりとりが行われ
る。なお、ネットワーク管理のオペレーションで使用さ
れるＳＮＭＰメッセージには、ＧｅｔＲｅｑｕｅｓｔメ
ッセージ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔメッセージ、
ＳｅｔＲｅｑｕｅｓｔメッセージ、ＧｅｔＲｅｑｕｅｓ
ｔメッセージ、ＧｅｔＲｅｓｐｏｎｓメッセージ、ＴＲ
ＡＰメッセージの５つがある。なお、以降の説明では、
語尾のメッセージを略して使用する。
ＳＮＭＰを用いたプロトコルで情報のやりとりが行われ
る。なお、ネットワーク管理のオペレーションで使用さ
れるＳＮＭＰメッセージには、ＧｅｔＲｅｑｕｅｓｔメ
ッセージ、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔメッセージ、
ＳｅｔＲｅｑｕｅｓｔメッセージ、ＧｅｔＲｅｑｕｅｓ
ｔメッセージ、ＧｅｔＲｅｓｐｏｎｓメッセージ、ＴＲ
ＡＰメッセージの５つがある。なお、以降の説明では、
語尾のメッセージを略して使用する。
【００２５】図２は、本発明で使用されるＧｅｔＲｅｑ
ｕｅｓｔまたはＧｅｔＲｅｓｐｏｎｓｅ発行時における
ｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールド（ＳＮ
ＭＰメッセージのＵＤＰ形式で定義されたフィールドの
一部で、オブジェクトＩＤとその値の対の配列として定
義したフィールド）の内容を示した図である。図２を参
照すると、ＩＤ（オブジェクトＩＤ）と値とが対となり
複数設定（例では、Ｖ１、Ｖ２、・・・）できるような
っている。ここで、ＧｅｔＲｅｑｕｅｓｔでは、マネー
ジャがｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールド
で指定したオブジェクトの値を、エージェントがＧｅｔ
Ｒｅｓｐｏｎｓｅのｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇ
ｓフィールドのオブジェクトの値に設定して応答する。
すなわち、本発明では、図１の監視端末１のＳＮＭＰマ
ネージャ制御部２１および被監視端末２のＳＮＭＰエー
ジェント制御部２１は、受信したＳＮＭＰメッセージを
解析する場合は、図２のフィールド内容を読み出してメ
ッセージの意味を識別することになる。
ｕｅｓｔまたはＧｅｔＲｅｓｐｏｎｓｅ発行時における
ｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールド（ＳＮ
ＭＰメッセージのＵＤＰ形式で定義されたフィールドの
一部で、オブジェクトＩＤとその値の対の配列として定
義したフィールド）の内容を示した図である。図２を参
照すると、ＩＤ（オブジェクトＩＤ）と値とが対となり
複数設定（例では、Ｖ１、Ｖ２、・・・）できるような
っている。ここで、ＧｅｔＲｅｑｕｅｓｔでは、マネー
ジャがｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇｓフィールド
で指定したオブジェクトの値を、エージェントがＧｅｔ
Ｒｅｓｐｏｎｓｅのｖａｒｉａｂｌｅ−ｂｉｎｄｉｎｇ
ｓフィールドのオブジェクトの値に設定して応答する。
すなわち、本発明では、図１の監視端末１のＳＮＭＰマ
ネージャ制御部２１および被監視端末２のＳＮＭＰエー
ジェント制御部２１は、受信したＳＮＭＰメッセージを
解析する場合は、図２のフィールド内容を読み出してメ
ッセージの意味を識別することになる。
【００２６】次に、図１〜図４を参照して本実施の形態
の全体の動作について説明する。今、図２で使用される
オブジェクトＩＤを説明の都合上、例えば、状態変化の
確認を示す場合は「ＳＴ」、項目Ａは「ＳＡ」、項目Ｂ
は「ＳＢ」、項目Ｃは「ＳＣ」、項目Ｄは「ＳＤ」とす
る。
の全体の動作について説明する。今、図２で使用される
オブジェクトＩＤを説明の都合上、例えば、状態変化の
確認を示す場合は「ＳＴ」、項目Ａは「ＳＡ」、項目Ｂ
は「ＳＢ」、項目Ｃは「ＳＣ」、項目Ｄは「ＳＤ」とす
る。
【００２７】図３を参照すると、先ず、マネージャであ
る監視端末１（以降、略してマネージャと呼ぶこともあ
る）のＳＮＭＰマネージャ制御部１１は、状態変化があ
るかどうかをエージェントに対して図２のＶ１のＩＤに
「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定してＧｅ
ｔＲｅｑｕｅｓｔを発行して確認する（図３のシーケン
スＧ１）。すると、エージェントである被監視端末２
（以降、略してエージェントと呼ぶこともある）のＳＮ
ＭＰエージェント制御部２１は、シーケンスＧ１でＧｅ
ｔＲｅｑｕｅｓｔを受けたときに、ＧｅｔＲｅｑｕｅｓ
ｔを解析（図２のフィールドを検索）する。このとき、
ＳＮＭＰエージェント制御部２１は、状態格納エリア２
３には状態変化（履歴情報）が１つも格納されていない
ため、状態変化なしと認識し、状態確認の状態値として
図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそ
れぞれ設定してＧｅｔＲｅｓｐｏｎｓｅでマネージャに
返す（シーケンスＲ１）。
る監視端末１（以降、略してマネージャと呼ぶこともあ
る）のＳＮＭＰマネージャ制御部１１は、状態変化があ
るかどうかをエージェントに対して図２のＶ１のＩＤに
「ＳＴ」を、値に「ＮＵＬＬ」をそれぞれ設定してＧｅ
ｔＲｅｑｕｅｓｔを発行して確認する（図３のシーケン
スＧ１）。すると、エージェントである被監視端末２
（以降、略してエージェントと呼ぶこともある）のＳＮ
ＭＰエージェント制御部２１は、シーケンスＧ１でＧｅ
ｔＲｅｑｕｅｓｔを受けたときに、ＧｅｔＲｅｑｕｅｓ
ｔを解析（図２のフィールドを検索）する。このとき、
ＳＮＭＰエージェント制御部２１は、状態格納エリア２
３には状態変化（履歴情報）が１つも格納されていない
ため、状態変化なしと認識し、状態確認の状態値として
図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」をそ
れぞれ設定してＧｅｔＲｅｓｐｏｎｓｅでマネージャに
返す（シーケンスＲ１）。
【００２８】次に監視端末１のＳＮＭＰマネージャ制御
部１１は、状態変化確認のＧｅｔＲｅｓｐｏｎｓｅにて
ＮＵＬＬが設定されている場合、状態変化がないと認識
して、一定時間を置いてから再度状態変化を確認するた
め、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」
をそれぞれ設定してＧｅｔＲｅｑｕｅｓｔをエージェン
トに対して発行する（シーケンスＧ２）。このとき、状
態変化確認のＧｅｔＲｅｓｐｏｎｓｅを受けてから、状
態変化確認のＧｅｔＲｅｑｕｅｓｔを発行するまでの時
間は任意の時間に変更可能とする。なお、監視端末１の
ＳＮＭＰマネージャ１１は、ＧｅｔＲｅｑｕｅｓｔ発行
後、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで他に処理
を行わないため、この時間を０にしても問題ない。しか
し、絶え間なくＧｅｔＲｅｑｕｅｓｔまたはＧｅｔＲｅ
ｓｐｏｎｓｅが実行されてしまい、他のネットワークア
プリケーションに影響を与える可能性があるため、時間
の設定はネットワークの速度に応じて変更することが望
ましい。
部１１は、状態変化確認のＧｅｔＲｅｓｐｏｎｓｅにて
ＮＵＬＬが設定されている場合、状態変化がないと認識
して、一定時間を置いてから再度状態変化を確認するた
め、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」
をそれぞれ設定してＧｅｔＲｅｑｕｅｓｔをエージェン
トに対して発行する（シーケンスＧ２）。このとき、状
態変化確認のＧｅｔＲｅｓｐｏｎｓｅを受けてから、状
態変化確認のＧｅｔＲｅｑｕｅｓｔを発行するまでの時
間は任意の時間に変更可能とする。なお、監視端末１の
ＳＮＭＰマネージャ１１は、ＧｅｔＲｅｑｕｅｓｔ発行
後、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで他に処理
を行わないため、この時間を０にしても問題ない。しか
し、絶え間なくＧｅｔＲｅｑｕｅｓｔまたはＧｅｔＲｅ
ｓｐｏｎｓｅが実行されてしまい、他のネットワークア
プリケーションに影響を与える可能性があるため、時間
の設定はネットワークの速度に応じて変更することが望
ましい。
【００２９】一方、マネージャがシーケンスＲ１のＧｅ
ｔＲｅｓｐｏｎｓｅを受けてからシーケンスＧ２のＧｅ
ｔＲｅｑｕｅｓｔを発行するまでに、エージェントにて
項目Ａが障害になり、続いて項目Ｂが障害になったとす
る。すると、被監視端末２の監視処理部２２は、項目Ａ
および続いて発生した項目Ｂの障害を検出し、障害情報
を状態格納エリア２３に格納（１つ目の履歴として「Ｓ
Ａ」とその障害値、２つ目の履歴として「ＳＢ」とその
障害値を格納）する。
ｔＲｅｓｐｏｎｓｅを受けてからシーケンスＧ２のＧｅ
ｔＲｅｑｕｅｓｔを発行するまでに、エージェントにて
項目Ａが障害になり、続いて項目Ｂが障害になったとす
る。すると、被監視端末２の監視処理部２２は、項目Ａ
および続いて発生した項目Ｂの障害を検出し、障害情報
を状態格納エリア２３に格納（１つ目の履歴として「Ｓ
Ａ」とその障害値、２つ目の履歴として「ＳＢ」とその
障害値を格納）する。
【００３０】この後、被監視端末２のＳＮＭＰエージェ
ント制御部２１は、マネージャから状態変化確認のＧｅ
ｔＲｅｑｕｅｓｔ（シーケンスＧ２）を受信した場合に
このメッセージを解析し、状態格納エリア２３に状態変
化が格納されているかを状態格納エリア２３を読み出す
ことにより確認する。この場合、ＳＮＭＰエージェント
制御部２１は、古い情報から検索していく。従って、被
監視端末２のＳＮＭＰエージェント制御部２１は、最初
に発生した項目Ａの状態変化があったことをマネージャ
に通知するために状態変化確認のレスポンスとして図２
のＶ１のＩＤに「ＳＴ」を、値に状態の変化のあった項
目を示す「ＳＡ」をそれぞれ設定してＧｅｔＲｅｓｐｏ
ｎｓｅを返す。（シーケンスＲ２）。
ント制御部２１は、マネージャから状態変化確認のＧｅ
ｔＲｅｑｕｅｓｔ（シーケンスＧ２）を受信した場合に
このメッセージを解析し、状態格納エリア２３に状態変
化が格納されているかを状態格納エリア２３を読み出す
ことにより確認する。この場合、ＳＮＭＰエージェント
制御部２１は、古い情報から検索していく。従って、被
監視端末２のＳＮＭＰエージェント制御部２１は、最初
に発生した項目Ａの状態変化があったことをマネージャ
に通知するために状態変化確認のレスポンスとして図２
のＶ１のＩＤに「ＳＴ」を、値に状態の変化のあった項
目を示す「ＳＡ」をそれぞれ設定してＧｅｔＲｅｓｐｏ
ｎｓｅを返す。（シーケンスＲ２）。
【００３１】次に、監視端末１のＳＮＭＰマネージャ制
御部１１は、シーケンスＲ２で受け取ったＧｅｔＲｅｓ
ｐｏｎｓｅを解析することにより、項目Ａの状態変化が
あったことを認識できるので、項目Ａの状態獲得および
状態変化が他にもないか確認するために状態変化確認の
ＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、ＧｅｔＲ
ｅｑｕｅｓｔには、図２のＶ１のＩＤに「ＳＡ」、値に
「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬ
Ｌ」をそれぞれ設定されて発行される（シーケンスＧ
３）。すると、被監視端末２のＳＮＭＰエージェント制
御部２１は、シーケンスＧ３で受け取ったＧｅｔＲｅｑ
ｕｅｓｔを解析することにより、図２のＶ１およびＶ２
の内容を検索することにより監視端末１から要求された
処理を実行することになる。ＳＮＭＰエージェント制御
部２１は、先ず最初に状態格納エリア２３から最初に格
納されている項目Ａの状態を獲得してレスポンスの値に
設定して、状態格納エリアの項目ＡのＭＩＢのオブジェ
クトＩＤおよび状態をクリアする（１履歴分消去す
る）。更に、状態格納エリア２３に他にも状態変化があ
るか確認する。この時点では、項目Ｂの障害の状態が格
納されているので、状態変化確認のレスポンスには項目
ＢのオブジェクトＩＤを設定してレスポンスを返す。す
なわち、ＧｅｔＲｅｓｐｏｎｓｅには、図２のＶ１のＩ
Ｄに「ＳＡ」、値にその障害値を、Ｖ２のＩＤに「Ｓ
Ｔ」、値に状態変化ありを示す値をそれぞれ設定されて
発行される（シーケンスＲ３）。
御部１１は、シーケンスＲ２で受け取ったＧｅｔＲｅｓ
ｐｏｎｓｅを解析することにより、項目Ａの状態変化が
あったことを認識できるので、項目Ａの状態獲得および
状態変化が他にもないか確認するために状態変化確認の
ＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、ＧｅｔＲ
ｅｑｕｅｓｔには、図２のＶ１のＩＤに「ＳＡ」、値に
「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬ
Ｌ」をそれぞれ設定されて発行される（シーケンスＧ
３）。すると、被監視端末２のＳＮＭＰエージェント制
御部２１は、シーケンスＧ３で受け取ったＧｅｔＲｅｑ
ｕｅｓｔを解析することにより、図２のＶ１およびＶ２
の内容を検索することにより監視端末１から要求された
処理を実行することになる。ＳＮＭＰエージェント制御
部２１は、先ず最初に状態格納エリア２３から最初に格
納されている項目Ａの状態を獲得してレスポンスの値に
設定して、状態格納エリアの項目ＡのＭＩＢのオブジェ
クトＩＤおよび状態をクリアする（１履歴分消去す
る）。更に、状態格納エリア２３に他にも状態変化があ
るか確認する。この時点では、項目Ｂの障害の状態が格
納されているので、状態変化確認のレスポンスには項目
ＢのオブジェクトＩＤを設定してレスポンスを返す。す
なわち、ＧｅｔＲｅｓｐｏｎｓｅには、図２のＶ１のＩ
Ｄに「ＳＡ」、値にその障害値を、Ｖ２のＩＤに「Ｓ
Ｔ」、値に状態変化ありを示す値をそれぞれ設定されて
発行される（シーケンスＲ３）。
【００３２】次に監視端末１のＳＮＭＰマネージャ制御
部１１は、シーケンスＲ３で受け取ったＧｅｔＲｅｓｐ
ｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ制
御部１１は、図２のＶ１の内容（ＳＡとその障害値）
は、監視解析部１３に渡す。すると、監視解析部１３
は、受け取った内容（項目Ａの障害値）を解析して監視
表示部１２に表示する。一方、ＳＮＭＰマネージャ制御
部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏ
ｎｓｅの解析内容（図２のＶ２の内容）から項目Ｂの状
態変化があったことを認識できるので、項目Ｂの状態獲
得および状態変化が他にもないか確認するために状態変
化確認のＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、
ＧｅｔＲｅｑｕｅｓｔには、図２のＶ１のＩＤに「Ｓ
Ｂ」、値に「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値
に「ＮＵＬＬ」をそれぞれ設定されて発行される（シー
ケンスＧ４）。すると、被監視端末２のＳＮＭＰエージ
ェント制御部２１は、シーケンスＧ４で受け取ったＧｅ
ｔＲｅｑｕｅｓｔを解析（図２のＶ１およびＶ２の内容
を検索）することにより監視端末１から要求された処理
を実行することになる。ＳＮＭＰエージェント制御部２
１は、先ず最初に状態格納エリア２３の最初に格納され
ている項目Ｂの状態を獲得してレスポンスの値に設定し
て、状態格納エリアの項目ＢのＭＩＢのオブジェクトＩ
Ｄおよび状態をクリアする（１履歴分消去する）。この
時点で状態格納エリア２３には何も格納されていないの
で、状態変化確認のレスポンスにはＮＵＬＬを設定して
レスポンスを返す。すなわち、ＧｅｔＲｅｓｐｏｎｓｅ
には、図２のＶ１のＩＤに「ＳＢ」、値にその障害値
を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬＬ」をそれぞ
れ設定されて発行される（シーケンスＲ４）。
部１１は、シーケンスＲ３で受け取ったＧｅｔＲｅｓｐ
ｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ制
御部１１は、図２のＶ１の内容（ＳＡとその障害値）
は、監視解析部１３に渡す。すると、監視解析部１３
は、受け取った内容（項目Ａの障害値）を解析して監視
表示部１２に表示する。一方、ＳＮＭＰマネージャ制御
部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏ
ｎｓｅの解析内容（図２のＶ２の内容）から項目Ｂの状
態変化があったことを認識できるので、項目Ｂの状態獲
得および状態変化が他にもないか確認するために状態変
化確認のＧｅｔＲｅｑｕｅｓｔを発行する。すなわち、
ＧｅｔＲｅｑｕｅｓｔには、図２のＶ１のＩＤに「Ｓ
Ｂ」、値に「ＮＵＬＬ」を、Ｖ２のＩＤに「ＳＴ」、値
に「ＮＵＬＬ」をそれぞれ設定されて発行される（シー
ケンスＧ４）。すると、被監視端末２のＳＮＭＰエージ
ェント制御部２１は、シーケンスＧ４で受け取ったＧｅ
ｔＲｅｑｕｅｓｔを解析（図２のＶ１およびＶ２の内容
を検索）することにより監視端末１から要求された処理
を実行することになる。ＳＮＭＰエージェント制御部２
１は、先ず最初に状態格納エリア２３の最初に格納され
ている項目Ｂの状態を獲得してレスポンスの値に設定し
て、状態格納エリアの項目ＢのＭＩＢのオブジェクトＩ
Ｄおよび状態をクリアする（１履歴分消去する）。この
時点で状態格納エリア２３には何も格納されていないの
で、状態変化確認のレスポンスにはＮＵＬＬを設定して
レスポンスを返す。すなわち、ＧｅｔＲｅｓｐｏｎｓｅ
には、図２のＶ１のＩＤに「ＳＢ」、値にその障害値
を、Ｖ２のＩＤに「ＳＴ」、値に「ＮＵＬＬ」をそれぞ
れ設定されて発行される（シーケンスＲ４）。
【００３３】次に、監視端末１のＳＮＭＰマネージャ制
御部１１は、シーケンスＲ４で受け取ったＧｅｔＲｅｓ
ｐｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ
制御部１１は、図２のＶ１の内容（ＳＢとその障害値）
は、監視解析部１３に渡す。すると、監視解析部１３
は、受け取った内容（項目Ｂの障害値）を解析して監視
表示部１２に表示する。一方、ＳＮＭＰマネージャ制御
部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏ
ｎｓｅの解析内容（図２のＶ２の内容）から、状態変化
確認のレスポンスにはＮＵＬＬが入っているため、一定
時間待ってから再度状態変化の確認のＧｅｔＲｅｑｕｅ
ｓｔを発行する。すなわち、ＧｅｔＲｅｑｕｅｓｔに
は、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」
をそれぞれ設定されて発行される（シーケンスＧ５）。
御部１１は、シーケンスＲ４で受け取ったＧｅｔＲｅｓ
ｐｏｎｓｅを解析する。このとき、ＳＮＭＰマネージャ
制御部１１は、図２のＶ１の内容（ＳＢとその障害値）
は、監視解析部１３に渡す。すると、監視解析部１３
は、受け取った内容（項目Ｂの障害値）を解析して監視
表示部１２に表示する。一方、ＳＮＭＰマネージャ制御
部１１は、シーケンスＲ３で受信したＧｅｔＲｅｓｐｏ
ｎｓｅの解析内容（図２のＶ２の内容）から、状態変化
確認のレスポンスにはＮＵＬＬが入っているため、一定
時間待ってから再度状態変化の確認のＧｅｔＲｅｑｕｅ
ｓｔを発行する。すなわち、ＧｅｔＲｅｑｕｅｓｔに
は、図２のＶ１のＩＤに「ＳＴ」を、値に「ＮＵＬＬ」
をそれぞれ設定されて発行される（シーケンスＧ５）。
【００３４】なお、上記説明において、状態変化の有無
の確認を行う手段として、上記と違う方法がある。すな
わち、図１の図示していない記憶部に状態変化の有無を
示す状態語（初期値は「０」）を設け、ＳＮＭＰエージ
ェント制御部２１が、状態変化を検出し、状態格納エリ
ア２３にその状態を格納する度に状態語を「＋１」し、
１履歴消去する度に「−１」するようにしておく。ＳＮ
ＭＰエージェント制御部２１は、ＧｅｔＲｅｑｕｅｓｔ
（図２のフィールドに「ＳＴ」が設定されている場合）
を受信した場合に、この状態語を読みにいくことで、即
座に判別（ＳＮＭＰエージェント制御部２１が、状態語
が「０」の場合は状態変化なし、状態語が「０」でなけ
れば状態変化ありと判定する）できる。
の確認を行う手段として、上記と違う方法がある。すな
わち、図１の図示していない記憶部に状態変化の有無を
示す状態語（初期値は「０」）を設け、ＳＮＭＰエージ
ェント制御部２１が、状態変化を検出し、状態格納エリ
ア２３にその状態を格納する度に状態語を「＋１」し、
１履歴消去する度に「−１」するようにしておく。ＳＮ
ＭＰエージェント制御部２１は、ＧｅｔＲｅｑｕｅｓｔ
（図２のフィールドに「ＳＴ」が設定されている場合）
を受信した場合に、この状態語を読みにいくことで、即
座に判別（ＳＮＭＰエージェント制御部２１が、状態語
が「０」の場合は状態変化なし、状態語が「０」でなけ
れば状態変化ありと判定する）できる。
【００３５】また、上記説明において、監視端末１およ
び被監視端末２はそれぞれ１対１の構成で説明したが、
被監視端末２が複数存在していても構わない。すなわ
ち、監視端末１のＳＮＭＰマネージャ制御部１１が複数
の被監視装置２を監視する場合の一連のシーケンスをフ
ローチャートにまとめたのが図４になる。この場合、図
１の監視端末１には、あらかじめ監視を行う複数の被監
視端末２のネットワークアドレスを図１に記載されてい
ないメモリの監視テーブルに設定しておく（ＳＮＭＰプ
ロトコルでは、それぞれの端末に設定されたネットワー
クアドレスを指定することによりＳＮＭＰメッセージの
送受信ができる）。すなわち、被監視端末２が複数ある
場合、監視端末１のＳＮＭＰマネージャ制御部１１は、
ＧｅｔＲｅｑｕｅｓｔにて状態変化の確認を行う場合
（ステップＦ１）、ステップＦ１の処理を行うたびに順
次確認する被監視端末２の対象を切り替えていくことで
対応できる。例えば、被監視端末２が２台（Ａ、Ｂ）が
あったする。すると、監視端末１の監視テーブルには、
被監視端末２Ａおよび被監視端末２Ｂのネットワークア
ドレスを監視順に設定されている。
び被監視端末２はそれぞれ１対１の構成で説明したが、
被監視端末２が複数存在していても構わない。すなわ
ち、監視端末１のＳＮＭＰマネージャ制御部１１が複数
の被監視装置２を監視する場合の一連のシーケンスをフ
ローチャートにまとめたのが図４になる。この場合、図
１の監視端末１には、あらかじめ監視を行う複数の被監
視端末２のネットワークアドレスを図１に記載されてい
ないメモリの監視テーブルに設定しておく（ＳＮＭＰプ
ロトコルでは、それぞれの端末に設定されたネットワー
クアドレスを指定することによりＳＮＭＰメッセージの
送受信ができる）。すなわち、被監視端末２が複数ある
場合、監視端末１のＳＮＭＰマネージャ制御部１１は、
ＧｅｔＲｅｑｕｅｓｔにて状態変化の確認を行う場合
（ステップＦ１）、ステップＦ１の処理を行うたびに順
次確認する被監視端末２の対象を切り替えていくことで
対応できる。例えば、被監視端末２が２台（Ａ、Ｂ）が
あったする。すると、監視端末１の監視テーブルには、
被監視端末２Ａおよび被監視端末２Ｂのネットワークア
ドレスを監視順に設定されている。
【００３６】図４を参照すると、監視端末１のＳＮＭＰ
マネージャ制御部１１は、システムが立ち上がると、監
視テーブルに従って、送出先を決め、先ず被監視端末２
Ａの状態変化の確認をＧｅｔＲｅｑｕｅｓｔで行う（ス
テップＦ１）。次に監視端末１のＳＮＭＰマネージャ制
御部１１は、ＧｅｔＲｅｓｐｏｎｓｅの内容から状態の
変化がないと判断した場合は、一定時間待って次の被監
視端末である被監視端末２ＢにＧｅｔＲｅｑｕｅｓｔ
（状態変化の確認）を発行する（ステップＦ２，Ｆ５，
Ｆ１）。監視端末１のＳＮＭＰマネージャ制御部１１
は、被監視端末２Ａアクセス時、ステップＦ２で状態変
化を検出した場合は、ＧｅｔＲｅｑｕｅｓｔで被監視端
末２Ａの状態の内容の獲得と状態の変化の確認を行う
（ステップＦ３）。次に監視端末１のＳＮＭＰマネージ
ャ制御部１１は、ＧｅｔＲｅｓｐｏｎｓｅによる被監視
装置２Ａの状態の内容の獲得を行い、このとき新たな被
監視端末２Ａの状態の変化がない場合は、一定時間待っ
た後、監視テーブルから次の端末である被監視端末２Ｂ
にＧｅｔＲｅｑｕｅｓｔ（状態の変化の確認）を発行す
る（ステップＦ４，Ｆ５，Ｆ１）。ステップＦ４で被監
視装置２Ａの状態変化がある場合は、監視端末１のＳＮ
ＭＰマネージャ制御部１１は、状態変化がなくなるま
で、ステップＦ３とステップＦ４を繰り返す。このよう
に被監視端末２Ｂでも状態の変化があった場合は、監視
端末１のＳＮＭＰマネージャ制御部１１は、状態変化な
しを検出するまで、被監視端末２ＢにもステップＦ１〜
Ｆ４の動作を繰り返す。すなわち、被監視端末２が多数
あっても、監視端末１のＳＮＭＰマネージャ制御部１１
は、図４のフローチャートによる同じ動作を実行するこ
とができる。
マネージャ制御部１１は、システムが立ち上がると、監
視テーブルに従って、送出先を決め、先ず被監視端末２
Ａの状態変化の確認をＧｅｔＲｅｑｕｅｓｔで行う（ス
テップＦ１）。次に監視端末１のＳＮＭＰマネージャ制
御部１１は、ＧｅｔＲｅｓｐｏｎｓｅの内容から状態の
変化がないと判断した場合は、一定時間待って次の被監
視端末である被監視端末２ＢにＧｅｔＲｅｑｕｅｓｔ
（状態変化の確認）を発行する（ステップＦ２，Ｆ５，
Ｆ１）。監視端末１のＳＮＭＰマネージャ制御部１１
は、被監視端末２Ａアクセス時、ステップＦ２で状態変
化を検出した場合は、ＧｅｔＲｅｑｕｅｓｔで被監視端
末２Ａの状態の内容の獲得と状態の変化の確認を行う
（ステップＦ３）。次に監視端末１のＳＮＭＰマネージ
ャ制御部１１は、ＧｅｔＲｅｓｐｏｎｓｅによる被監視
装置２Ａの状態の内容の獲得を行い、このとき新たな被
監視端末２Ａの状態の変化がない場合は、一定時間待っ
た後、監視テーブルから次の端末である被監視端末２Ｂ
にＧｅｔＲｅｑｕｅｓｔ（状態の変化の確認）を発行す
る（ステップＦ４，Ｆ５，Ｆ１）。ステップＦ４で被監
視装置２Ａの状態変化がある場合は、監視端末１のＳＮ
ＭＰマネージャ制御部１１は、状態変化がなくなるま
で、ステップＦ３とステップＦ４を繰り返す。このよう
に被監視端末２Ｂでも状態の変化があった場合は、監視
端末１のＳＮＭＰマネージャ制御部１１は、状態変化な
しを検出するまで、被監視端末２ＢにもステップＦ１〜
Ｆ４の動作を繰り返す。すなわち、被監視端末２が多数
あっても、監視端末１のＳＮＭＰマネージャ制御部１１
は、図４のフローチャートによる同じ動作を実行するこ
とができる。
【００３７】なお、上記のステップＦ５の説明におい
て、一定時間を待つという処理は、ＳＮＭＰマネージャ
制御部１１が、図１に図示していないタイマにあらかじ
め決められた値を設定して、タイマを起動し、タイムア
ウト割込によりステップＦ１の処理を実行するようにす
ればよい。
て、一定時間を待つという処理は、ＳＮＭＰマネージャ
制御部１１が、図１に図示していないタイマにあらかじ
め決められた値を設定して、タイマを起動し、タイムア
ウト割込によりステップＦ１の処理を実行するようにす
ればよい。
【００３８】このような処理を行うことによって、ネッ
トワークに一定以上の負荷をかけないようにして複数の
被監視端末の監視を行うことが可能となる。この場合、
タイマ値を図１に図示していないコンソールから変更で
きるようにしておけば、ネットワ−クの規模により変更
できるため、負荷をかけないという点で望ましい。
トワークに一定以上の負荷をかけないようにして複数の
被監視端末の監視を行うことが可能となる。この場合、
タイマ値を図１に図示していないコンソールから変更で
きるようにしておけば、ネットワ−クの規模により変更
できるため、負荷をかけないという点で望ましい。
【００３９】以上説明したように、ＴＲＡＰを用いてい
ないので、ＴＲＡＰ漏れを考慮する必要がなくなる。Ｔ
ＲＡＰによる状態変化の通知方式と比べると、エージェ
ントから連続して状態変化が通知されネットワーク上の
負荷が一時的に高くなることもなく、本発明によるマネ
ージャは、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで次
のＧｅｔＲｅｑｕｅｓｔを一定時間の間発行しないよう
にしているため、マネージャ自身の処理できる速度以上
にネットワークの負荷があがることはない。
ないので、ＴＲＡＰ漏れを考慮する必要がなくなる。Ｔ
ＲＡＰによる状態変化の通知方式と比べると、エージェ
ントから連続して状態変化が通知されネットワーク上の
負荷が一時的に高くなることもなく、本発明によるマネ
ージャは、ＧｅｔＲｅｓｐｏｎｓｅが返ってくるまで次
のＧｅｔＲｅｑｕｅｓｔを一定時間の間発行しないよう
にしているため、マネージャ自身の処理できる速度以上
にネットワークの負荷があがることはない。
【００４０】また、常に全監視項目の状態の獲得を行う
のではなく、状態変化のあったオブジェクトだけを獲得
するので短い時間ですべての状態変化のあった項目の状
態を獲得することができる。
のではなく、状態変化のあったオブジェクトだけを獲得
するので短い時間ですべての状態変化のあった項目の状
態を獲得することができる。
【００４１】従って、ネットワークに負荷をかけないよ
うにしながらできるだけリアルタイムに監視状態を獲得
することが可能となる。
うにしながらできるだけリアルタイムに監視状態を獲得
することが可能となる。
【００４２】
【発明の効果】本発明は、ＳＮＭＰを利用したネットワ
ーク管理システムにおいて、ＳＮＭＰはＵＤＰを利用し
たコネクションレスのプロトコルであるため、ＴＲＡＰ
漏れを考慮する必要があったが、本方式ではＴＲＡＰを
全く使用しないのでＴＲＡＰ漏れを考慮する必要がない
という効果がある。
ーク管理システムにおいて、ＳＮＭＰはＵＤＰを利用し
たコネクションレスのプロトコルであるため、ＴＲＡＰ
漏れを考慮する必要があったが、本方式ではＴＲＡＰを
全く使用しないのでＴＲＡＰ漏れを考慮する必要がない
という効果がある。
【００４３】更に、本発明は、ＧｅｔＲｅｑｕｅｓｔに
より、状態変化の確認をしてから状態変化のあった項目
だけ状態を獲得するようにしているため、常に全監視項
目の状態獲得を行う必要がなく、監視項目分の状態をす
べて獲得するまでの時間を短縮できるという効果があ
る、更に、本発明は、ＴＲＡＰを用いていないため、マ
ネージャからＧｅｔＲｅｑｕｅｓｔを発行してからエー
ジェントからＧｅｔＲｅｓｐｏｎｓｅを受けるまで他の
ＳＮＭＰの処理に対する割り込みが一切発生しないた
め、ネットワーク上の負荷を削減できるという効果があ
る。
より、状態変化の確認をしてから状態変化のあった項目
だけ状態を獲得するようにしているため、常に全監視項
目の状態獲得を行う必要がなく、監視項目分の状態をす
べて獲得するまでの時間を短縮できるという効果があ
る、更に、本発明は、ＴＲＡＰを用いていないため、マ
ネージャからＧｅｔＲｅｑｕｅｓｔを発行してからエー
ジェントからＧｅｔＲｅｓｐｏｎｓｅを受けるまで他の
ＳＮＭＰの処理に対する割り込みが一切発生しないた
め、ネットワーク上の負荷を削減できるという効果があ
る。
【００４４】更に、本発明は、何も状態変化がない場
合、次の状態変化の確認まで任意の時間を設定できるよ
うにすることで最適なネットワークパフォーマンスを提
供することができるという効果がある。
合、次の状態変化の確認まで任意の時間を設定できるよ
うにすることで最適なネットワークパフォーマンスを提
供することができるという効果がある。
【図１】本発明の実施の形態を示すブロック図である。
【図２】ＳＮＭＰメッセージのＵＤＰ形式で定義された
フィールドの一部である。
フィールドの一部である。
【図３】図１の監視端末と被監視端末との間の動作を示
すシーケンス図である。
すシーケンス図である。
【図４】図１の監視端末が複数の被監視端末の監視の動
作を行うフロ−チャートである。
作を行うフロ−チャートである。
１ 監視端末 ２ 被監視端末 ３ ネットワーク １１ ＳＮＭＰマネージャ制御部 １２ 監視表示部 １３ 監視解析部 ２１ ＳＮＭＰエージェント制御部 ２２ 監視処理部 ２３ 状態格納エリア
───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B089 GA21 GB02 GB08 HB06 JA40 JB10 JB16 KA07 KA12 KB04 KB11 5K030 GA01 GA11 HA08 HB06 JA10 LA08 MC07 MC09 5K035 AA01 AA02 GG13 MM03 9A001 BB01 BB03 BB04 CC06 CC07 CC08 FF03
Claims (12)
- 【請求項１】 マネージャがＳＮＭＰプロトコルを用い
て複数のエージェントの障害のネットワ−ク管理を行う
障害管理方式において、前記マネージャが一定時間毎に
前記エージェントの状態変化の有無の確認要求を行う第
１の要求手段と、前記エージェントは、前記第１の要求
手段による確認要求が前記エージェントにあると前記エ
ージェン状態変化の有無を前記マネージャに通知する第
１の通知手段と、前記マネージャが前記第１の通知手段
により前記状態変化を検出した場合に前記状態変化の内
容の読出要求を前記エージェントに行う第２の要求手段
と、前記第２の要求手段による要求があると前記状態変
化の内容を前記マネージャに通知する第２の通知手段と
を有することを特徴とする障害管理方式。 - 【請求項２】 前記第２の要求手段は前記第１の要求手
段を含み、前記第２の通知手段は前記第１の通知手段を
含むことを特徴とする請求項１記載の障害処理方式。 - 【請求項３】 前記第１の通知手段は、前記エージェン
トが既に状態変化を検出した状態の時に前記第１の要求
手段による確認要求が前記エージェントにあると前記エ
ージェントが前記エージェン状態変化のあったことを前
記マネージャに通知し、前記エージェントに状態変化を
検出していない状態の時に前記第１の要求手段による確
認要求が前記エージェントにあると前記エージェントが
前記エージェンに状態変化のあったことを前記マネージ
ャに通知することを特徴とする請求項１または２記載の
障害管理方式。 - 【請求項４】 マネージャがＳＮＭＰプロトコルを用い
て複数のエージェントの障害のネットワ−ク管理を行う
障害管理方式において、前記マネージャが前記エージェ
ントの状態変化の有無の確認要求を行う第１の要求手段
と、前記マネージャが前記第１の要求手段で状態変化が
ない場合に一定時間たってから前記第１の要求手段を繰
り返す繰り返し手段と、前記エージェントが状態変化を
検出する毎にその状態変化の内容を履歴情報として記憶
する記憶手段と、前記第１の要求手段による確認要求が
前記エージェントにあると前記エージェントが前記記憶
手段で記憶されている前記履歴情報を検索することによ
り状態変化の有無を前記マネージャに通知する第１の通
知手段と、前記マネージャが前記第１の通知手段により
前記状態変化を検出した場合に前記状態変化の内容の読
出要求と新たな状態変化の確認要求とを前記エージェン
トに同時に行う第２の要求手段と、前記第２の要求手段
による要求があると前記エージェントが前記記憶手段で
記憶された履歴情報を検索することにより前記状態変化
の内容と前記新たな状態変化の有無とを前記マネージャ
に通知する第２の通知手段とを有することを特徴とする
障害管理方式。 - 【請求項５】 前記第１および第２の要求手段は、Ｇｅ
ｔＲｅｑｕｅｓｔメッセージを使用して要求を行うこと
を特徴とする請求項１，２，３または４記載の障害管理
方式。 - 【請求項６】 前記第１および第２の通知手段は、Ｇｅ
ｔＲｅｓｐｏｎｓｅメッセージを使用して通知すること
を特徴とする請求項１，２，３または４記載の障害管理
方式。 - 【請求項７】 前記記憶手段は、前記状態変化の起こっ
たオブジェクトＩＤ（監視対象項目識別番号）とその状
態変化の内容とを発生した順に記憶していくことを特徴
とする請求項４記載の障害管理方式。 - 【請求項８】 前記第１の通知手段は、前記記憶手段に
記憶された一番古いオブジェクトＩＤを前記マネージャ
に通知することを特徴とする請求項４記載の障害管理方
式。 - 【請求項９】 前記第２の要求手段は、前記第１の通知
手段で通知のあったオブジェクトＩＤの状態変化の内容
の読出要求を行うことを特徴とする請求項４記載の障害
管理方式。 - 【請求項１０】 マネージャがＳＮＭＰプロトコルに基
づいて複数のエージェントの障害のネットワ−ク管理を
行う障害管理方法であって、前記マネージャは一定時間
毎に前記エージェントの状態変化の有無の確認要求を行
い、前記エージェントは既に状態変化を検出した状態の
時に前記マネージャから前記状態変化の有無の確認要求
があった場合に状態変化のあったことをマネージャに通
知し、前記マネージャは前記エージェントから前記状態
変化のあったという通知を受けると前記状態変化の内容
の読出要求を前記エージェントに行い、前記エージェン
トは前記マネージャから前記状態変化の内容の読出要求
があると前記状態変化の内容を前記マネージャに通知す
ることを特徴とする障害管理方法。 - 【請求項１１】 マネージャがＳＮＭＰプロトコルに基
づいて複数のエージェントの障害のネットワ−ク管理を
行う障害管理方法であって、前記エージェントが状態変
化を検出する毎に状態変化のあったオブジェクトＩＤ
（監視対象項目識別番号）とその状態変化の内容とを検
出順に格納した格納エリアを用いて、前記マネージャは
一定時間毎に前記エージェントの状態変化の有無の確認
要求を行い、前記エージェントは前記マネージャから前
記状態変化の有無の確認要求があった場合に前記格納エ
リアに格納されていれば状態変化の有を示す一番古い履
歴のオブジェクトＩＤを，前記格納エリアに格納されて
いなければ状態変化のないことをそれぞれマネージャに
通知し、前記マネージャは前記状態変化が有の場合に前
記通知のあったオブジェクトＩＤの状態変化の内容の読
出要求と新たな状態変化の有無の確認要求とを前記エー
ジェントに行い、前記エージェントは前記マネージャか
ら前記オブジェクトＩＤの状態変化の内容の読出要求と
新たな状態変化の有無の確認要求とがあると前記オブジ
ェクトＩＤの状態変化の内容と新たな状態変化の有無と
を前記マネージャに通知することを特徴とする障害管理
方法。 - 【請求項１２】 前記エージェントは前記マネージャに
前記オブジェクトＩＤの状態変化の内容を通知すると前
記格納エリアから通知した状態情報を消すことを特徴と
する請求項９記載の障害管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18886899A JP3570300B2 (ja) | 1999-07-02 | 1999-07-02 | 障害管理方式および方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18886899A JP3570300B2 (ja) | 1999-07-02 | 1999-07-02 | 障害管理方式および方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001024635A true JP2001024635A (ja) | 2001-01-26 |
| JP3570300B2 JP3570300B2 (ja) | 2004-09-29 |
Family
ID=16231288
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP18886899A Expired - Fee Related JP3570300B2 (ja) | 1999-07-02 | 1999-07-02 | 障害管理方式および方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3570300B2 (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003015973A (ja) * | 2001-07-02 | 2003-01-17 | Canon Inc | ネットワークデバイス管理装置、管理方法及び管理プログラム |
| JP2004102992A (ja) * | 2003-07-31 | 2004-04-02 | Toyomaru Industry Co Ltd | 監視システム、遊技機及び装置管理システム |
| JP2004302532A (ja) * | 2003-03-28 | 2004-10-28 | Fujitsu Ltd | Ｓｎｍｐエージェント装置 |
| US7440125B2 (en) | 2002-06-14 | 2008-10-21 | Brother Kogyo Kabushiki Kaisha | Setting information transmission/reception system |
| JP2009020607A (ja) * | 2007-07-10 | 2009-01-29 | Kyocera Mita Corp | ネットワークデバイス管理システム及びネットワークデバイス管理プログラム |
-
1999
- 1999-07-02 JP JP18886899A patent/JP3570300B2/ja not_active Expired - Fee Related
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003015973A (ja) * | 2001-07-02 | 2003-01-17 | Canon Inc | ネットワークデバイス管理装置、管理方法及び管理プログラム |
| US7440125B2 (en) | 2002-06-14 | 2008-10-21 | Brother Kogyo Kabushiki Kaisha | Setting information transmission/reception system |
| US8045206B2 (en) | 2002-06-14 | 2011-10-25 | Brother Kogyo Kabushiki Kaisha | Setting information transmission/reception system |
| JP2004302532A (ja) * | 2003-03-28 | 2004-10-28 | Fujitsu Ltd | Ｓｎｍｐエージェント装置 |
| JP2004102992A (ja) * | 2003-07-31 | 2004-04-02 | Toyomaru Industry Co Ltd | 監視システム、遊技機及び装置管理システム |
| JP2009020607A (ja) * | 2007-07-10 | 2009-01-29 | Kyocera Mita Corp | ネットワークデバイス管理システム及びネットワークデバイス管理プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3570300B2 (ja) | 2004-09-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110661669B (zh) | 一种基于icmp、tcp、udp协议的网络设备的网络拓扑自动发现方法 | |
| US7472179B2 (en) | System management method for a data center | |
| US5568605A (en) | Resolving conflicting topology information | |
| JP2510075B2 (ja) | Ｓｎｍｐテ―ブルをモニタ及び維持するシステム及び方法 | |
| TW201944236A (zh) | 任務處理方法、裝置及系統 | |
| CA2319303A1 (en) | Carrier-grade snmp interface for fault monitoring | |
| CN111182659B (zh) | 一种Mesh设备的模式切换方法、模式切换装置及Mesh设备 | |
| WO1994019889A1 (en) | System and method for automatic segment resolution on a local area network | |
| CN102263651A (zh) | Snmp网络管理系统中局端设备连接状态的检测方法 | |
| WO2016177144A1 (zh) | 网元监测方法和装置 | |
| EP1800436A1 (en) | Method and apparatus for determining impact of faults on network service | |
| CN114553867A (zh) | 一种云原生的跨云网络监控方法、装置及存储介质 | |
| JP2001024635A (ja) | 障害管理方式および方法 | |
| JP6421516B2 (ja) | サーバ装置、冗長構成サーバシステム、情報引継プログラム及び情報引継方法 | |
| JP4228772B2 (ja) | ネットワーク監視方法およびネットワーク監視装置 | |
| KR100500836B1 (ko) | 매트로 이더넷망의 장애처리 장치 및 그 방법 | |
| CN113709210A (zh) | 一种设备发现方法、装置、系统、电子设备及存储介质 | |
| CN107248935B (zh) | 一种网管发现并监控网元的系统及方法 | |
| JP4790579B2 (ja) | プロセスの監視装置及び監視方法 | |
| KR100580103B1 (ko) | 통신망관리시스템의 서버프로세스 원격감시 방법 | |
| KR100612254B1 (ko) | Ｓｎｍｐ를 사용하는 네트워크 관리 시스템의 통계 데이터관리 방법 및 그 장치 | |
| JPH08147231A (ja) | ネットワークノードの検索方法 | |
| JP2001251323A (ja) | ネットワーク管理装置 | |
| CN116346696B (zh) | 批量网络测试方法、装置、设备及存储介质 | |
| CN112769889B (zh) | 服务数据的推送方法、装置、存储介质以及电子装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 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: 20040601 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040614 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |