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)【要約】
【課題】SNMPプロトコルを用いたネットワーク管理
システムにおいて、TRAPを用いることなく、ネット
ワークに負荷をかけないようにしながらエージェント監
視状態を獲得することにある。 【解決手段】監視端末1は状態変化確認を行うGetR
equestを被監視装置2に対して発行する。監視端
末1は、GetResponseにより状態変化なしの
通知を受けると、一定時間後に状態変化確認を行うGe
tRequestを再度発行する。一方、被監視端末2
のおいて状態変化が発生すると状態格納エリア23に発
生順にIDと状態とを記憶する。すると、被監視端末2
は、応答として、状態格納エリア23から一番古いID
をGetResponseに付加して監視端末1に返
す。監視端末1はそのIDの状態を読み出すようにGe
tRequestを被監視端末2に対して発行すること
によって最新状態を獲得する。
システムにおいて、TRAPを用いることなく、ネット
ワークに負荷をかけないようにしながらエージェント監
視状態を獲得することにある。 【解決手段】監視端末1は状態変化確認を行うGetR
equestを被監視装置2に対して発行する。監視端
末1は、GetResponseにより状態変化なしの
通知を受けると、一定時間後に状態変化確認を行うGe
tRequestを再度発行する。一方、被監視端末2
のおいて状態変化が発生すると状態格納エリア23に発
生順にIDと状態とを記憶する。すると、被監視端末2
は、応答として、状態格納エリア23から一番古いID
をGetResponseに付加して監視端末1に返
す。監視端末1はそのIDの状態を読み出すようにGe
tRequestを被監視端末2に対して発行すること
によって最新状態を獲得する。
Description
【0001】
【発明の属する技術分野】本発明は、通信ネットワーク
のネットワーク管理に関し、特にネットワーク管理プロ
トコルであるSNMP(Simple Network
management Protocol)を用いた
障害管理方式および方法に関する。
のネットワーク管理に関し、特にネットワーク管理プロ
トコルであるSNMP(Simple Network
management Protocol)を用いた
障害管理方式および方法に関する。
【0002】
【従来の技術】従来のこの種の障害管理方式は、例え
ば、特開平9−101932号公報および特開平10−
334011号公報に記載されているように、SNMP
プロトコルを用いたネットワーク管理システムにおい
て、エージェントの障害状態をマネージャに通知する場
合、TRAPメッセージを用いて行っている。このと
き、TRAPメッセージ抜けが生じた場合に、再度TR
APメッセージを送信するという手順を取っている。
ば、特開平9−101932号公報および特開平10−
334011号公報に記載されているように、SNMP
プロトコルを用いたネットワーク管理システムにおい
て、エージェントの障害状態をマネージャに通知する場
合、TRAPメッセージを用いて行っている。このと
き、TRAPメッセージ抜けが生じた場合に、再度TR
APメッセージを送信するという手順を取っている。
【0003】
【発明が解決しようとする課題】しかしながら、従来の
障害管理方式は、SNMPはUDP(User Dat
agram Protocol)を利用したコネクショ
ンレスのプロトコルのため、エージェントから通知され
たTRAPメッセージが必ずしもマネージャに届くとは
限らない。そのため、TRAPメッセージが抜けないよ
うに再度送信する手順をとっているので、ネットワーク
の負荷が高いときにTRAPメッセージを送信すると、
ネットワーク上に過度の負荷をかけると共に、最悪の場
合にはTRAPメッセージ抜けが発生するいう問題点が
ある。
障害管理方式は、SNMPはUDP(User Dat
agram Protocol)を利用したコネクショ
ンレスのプロトコルのため、エージェントから通知され
たTRAPメッセージが必ずしもマネージャに届くとは
限らない。そのため、TRAPメッセージが抜けないよ
うに再度送信する手順をとっているので、ネットワーク
の負荷が高いときにTRAPメッセージを送信すると、
ネットワーク上に過度の負荷をかけると共に、最悪の場
合にはTRAPメッセージ抜けが発生するいう問題点が
ある。
【0004】また、マネージャはTRAPメッセージが
届かない場合を考慮して全監視項目の状態をGet R
equestメッセージまたはGet Next Re
questメッセージを利用して定期的にエージェント
に対して獲得に行かなければ正しい状態を獲得できない
という問題点がある。
届かない場合を考慮して全監視項目の状態をGet R
equestメッセージまたはGet Next Re
questメッセージを利用して定期的にエージェント
に対して獲得に行かなければ正しい状態を獲得できない
という問題点がある。
【0005】また、定期的に全監視項目の状態の獲得を
行う場合、最初の獲得から次の獲得までのポーリング時
間を長くすると障害を認識できない状態が常に長くなっ
てしまい、逆にポーリング時間を短くすると障害状態は
すぐ認識できるがネットワークの負荷があがってしまい
TRAPメッセージ漏れの可能性が増大してしまうとい
う問題点がある。
行う場合、最初の獲得から次の獲得までのポーリング時
間を長くすると障害を認識できない状態が常に長くなっ
てしまい、逆にポーリング時間を短くすると障害状態は
すぐ認識できるがネットワークの負荷があがってしまい
TRAPメッセージ漏れの可能性が増大してしまうとい
う問題点がある。
【0006】本発明の目的は、上記問題点を鑑み、SN
MPプロトコルを用いたネットワーク管理システムにお
いて、エージェントの状態の監視する手段としてTRA
Pメッセージを用いないでGetRequestだけを
用い、ネットワークに負荷をかけないようにしながらで
きるだけリアルタイムに監視状態を獲得する方式を提供
することにある。
MPプロトコルを用いたネットワーク管理システムにお
いて、エージェントの状態の監視する手段としてTRA
Pメッセージを用いないでGetRequestだけを
用い、ネットワークに負荷をかけないようにしながらで
きるだけリアルタイムに監視状態を獲得する方式を提供
することにある。
【0007】
【課題を解決するための手段】上記の目的を達成するた
めに、本発明の第1の障害管理方式は、マネージャがS
NMPプロトコルを用いて複数のエージェントの障害の
ネットワ−ク管理を行う障害管理方式において、前記マ
ネージャが一定時間毎に前記エージェントの状態変化の
有無の確認要求を行う第1の要求手段と、前記エージェ
ントは、前記第1の要求手段による確認要求が前記エー
ジェントにあると前記エージェン状態変化の有無を前記
マネージャに通知する第1の通知手段と、前記マネージ
ャが前記第1の通知手段により前記状態変化を検出した
場合に前記状態変化の内容の読出要求を前記エージェン
トに行う第2の要求手段と、前記第2の要求手段による
要求があると前記状態変化の内容を前記マネージャに通
知する第2の通知手段とを有することを特徴としてい
る。
めに、本発明の第1の障害管理方式は、マネージャがS
NMPプロトコルを用いて複数のエージェントの障害の
ネットワ−ク管理を行う障害管理方式において、前記マ
ネージャが一定時間毎に前記エージェントの状態変化の
有無の確認要求を行う第1の要求手段と、前記エージェ
ントは、前記第1の要求手段による確認要求が前記エー
ジェントにあると前記エージェン状態変化の有無を前記
マネージャに通知する第1の通知手段と、前記マネージ
ャが前記第1の通知手段により前記状態変化を検出した
場合に前記状態変化の内容の読出要求を前記エージェン
トに行う第2の要求手段と、前記第2の要求手段による
要求があると前記状態変化の内容を前記マネージャに通
知する第2の通知手段とを有することを特徴としてい
る。
【0008】更に、上記第1の障害処理方式において、
前記第2の要求手段は前記第1の要求手段を含み、前記
第2の通知手段は前記第1の通知手段を含むことを特徴
としている。
前記第2の要求手段は前記第1の要求手段を含み、前記
第2の通知手段は前記第1の通知手段を含むことを特徴
としている。
【0009】更に、上記第1の障害処理方式において、
前記第1の通知手段は、前記エージェントが既に状態変
化を検出した状態の時に前記第1の要求手段による確認
要求が前記エージェントにあると前記エージェントが前
記エージェン状態変化のあったことを前記マネージャに
通知し、前記エージェントに状態変化を検出していない
状態の時に前記第1の要求手段による確認要求が前記エ
ージェントにあると前記エージェントが前記エージェン
に状態変化のあったことを前記マネージャに通知するこ
とを特徴としている。
前記第1の通知手段は、前記エージェントが既に状態変
化を検出した状態の時に前記第1の要求手段による確認
要求が前記エージェントにあると前記エージェントが前
記エージェン状態変化のあったことを前記マネージャに
通知し、前記エージェントに状態変化を検出していない
状態の時に前記第1の要求手段による確認要求が前記エ
ージェントにあると前記エージェントが前記エージェン
に状態変化のあったことを前記マネージャに通知するこ
とを特徴としている。
【0010】また、本発明の第2の障害処理方式は、マ
ネージャがSNMPプロトコルを用いて複数のエージェ
ントの障害のネットワ−ク管理を行う障害管理方式にお
いて、前記マネージャが前記エージェントの状態変化の
有無の確認要求を行う第1の要求手段と、前記マネージ
ャが前記第1の要求手段で状態変化がない場合に一定時
間たってから前記第1の要求手段を繰り返す繰り返し手
段と、前記エージェントが状態変化を検出する毎にその
状態変化の内容を履歴情報として記憶する記憶手段と、
前記第1の要求手段による確認要求が前記エージェント
にあると前記エージェントが前記記憶手段で記憶されて
いる前記履歴情報を検索することにより状態変化の有無
を前記マネージャに通知する第1の通知手段と、前記マ
ネージャが前記第1の通知手段により前記状態変化を検
出した場合に前記状態変化の内容の読出要求と新たな状
態変化の確認要求とを前記エージェントに同時に行う第
2の要求手段と、前記第2の要求手段による要求がある
と前記エージェントが前記記憶手段で記憶された履歴情
報を検索することにより前記状態変化の内容と前記新た
な状態変化の有無とを前記マネージャに通知する第2の
通知手段とを有することを特徴としている。
ネージャがSNMPプロトコルを用いて複数のエージェ
ントの障害のネットワ−ク管理を行う障害管理方式にお
いて、前記マネージャが前記エージェントの状態変化の
有無の確認要求を行う第1の要求手段と、前記マネージ
ャが前記第1の要求手段で状態変化がない場合に一定時
間たってから前記第1の要求手段を繰り返す繰り返し手
段と、前記エージェントが状態変化を検出する毎にその
状態変化の内容を履歴情報として記憶する記憶手段と、
前記第1の要求手段による確認要求が前記エージェント
にあると前記エージェントが前記記憶手段で記憶されて
いる前記履歴情報を検索することにより状態変化の有無
を前記マネージャに通知する第1の通知手段と、前記マ
ネージャが前記第1の通知手段により前記状態変化を検
出した場合に前記状態変化の内容の読出要求と新たな状
態変化の確認要求とを前記エージェントに同時に行う第
2の要求手段と、前記第2の要求手段による要求がある
と前記エージェントが前記記憶手段で記憶された履歴情
報を検索することにより前記状態変化の内容と前記新た
な状態変化の有無とを前記マネージャに通知する第2の
通知手段とを有することを特徴としている。
【0011】更に、上記第1または第2の障害処理方式
において、前記第1および第2の要求手段は、GetR
equestメッセージを使用して要求を行うことを特
徴としている。
において、前記第1および第2の要求手段は、GetR
equestメッセージを使用して要求を行うことを特
徴としている。
【0012】更に、上記第1または第2の障害処理方式
において、前記第1および第2の通知手段は、GetR
esponseメッセージを使用して通知することを特
徴としている。
において、前記第1および第2の通知手段は、GetR
esponseメッセージを使用して通知することを特
徴としている。
【0013】更に、上記第2の障害処理方式において、
前記記憶手段は、前記状態変化の起こったオブジェクト
ID(監視対象項目識別番号)とその状態変化の内容と
を発生した順に記憶していくことを特徴としている。
前記記憶手段は、前記状態変化の起こったオブジェクト
ID(監視対象項目識別番号)とその状態変化の内容と
を発生した順に記憶していくことを特徴としている。
【0014】更に、上記第2の障害処理方式において、
前記第1の通知手段は、前記記憶手段に記憶された一番
古いオブジェクトIDを前記マネージャに通知すること
を特徴としている。
前記第1の通知手段は、前記記憶手段に記憶された一番
古いオブジェクトIDを前記マネージャに通知すること
を特徴としている。
【0015】更に、上記第2の障害処理方式において、
前記第2の要求手段は、前記第1の通知手段で通知のあ
ったオブジェクトIDの状態変化の内容の読出要求を行
うことを特徴としている。
前記第2の要求手段は、前記第1の通知手段で通知のあ
ったオブジェクトIDの状態変化の内容の読出要求を行
うことを特徴としている。
【0016】また、本発明の第1の障害処理方法は、マ
ネージャがSNMPプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記マネージャは一定時間毎に前記エージェン
トの状態変化の有無の確認要求を行い、前記エージェン
トは既に状態変化を検出した状態の時に前記マネージャ
から前記状態変化の有無の確認要求があった場合に状態
変化のあったことをマネージャに通知し、前記マネージ
ャは前記エージェントから前記状態変化のあったという
通知を受けると前記状態変化の内容の読出要求を前記エ
ージェントに行い、前記エージェントは前記マネージャ
から前記状態変化の内容の読出要求があると前記状態変
化の内容を前記マネージャに通知することを特徴として
いる。
ネージャがSNMPプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記マネージャは一定時間毎に前記エージェン
トの状態変化の有無の確認要求を行い、前記エージェン
トは既に状態変化を検出した状態の時に前記マネージャ
から前記状態変化の有無の確認要求があった場合に状態
変化のあったことをマネージャに通知し、前記マネージ
ャは前記エージェントから前記状態変化のあったという
通知を受けると前記状態変化の内容の読出要求を前記エ
ージェントに行い、前記エージェントは前記マネージャ
から前記状態変化の内容の読出要求があると前記状態変
化の内容を前記マネージャに通知することを特徴として
いる。
【0017】また、本発明の第2の障害処理方法は、マ
ネージャがSNMPプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記エージェントが状態変化を検出する毎に状
態変化のあったオブジェクトID(監視対象項目識別番
号)とその状態変化の内容とを検出順に格納した格納エ
リアを用いて、前記マネージャは一定時間毎に前記エー
ジェントの状態変化の有無の確認要求を行い、前記エー
ジェントは前記マネージャから前記状態変化の有無の確
認要求があった場合に前記格納エリアに格納されていれ
ば状態変化の有を示す一番古い履歴のオブジェクトID
を,前記格納エリアに格納されていなければ状態変化の
ないことをそれぞれマネージャに通知し、前記マネージ
ャは前記状態変化が有の場合に前記通知のあったオブジ
ェクトIDの状態変化の内容の読出要求と新たな状態変
化の有無の確認要求とを前記エージェントに行い、前記
エージェントは前記マネージャから前記オブジェクトI
Dの状態変化の内容の読出要求と新たな状態変化の有無
の確認要求とがあると前記オブジェクトIDの状態変化
の内容と新たな状態変化の有無とを前記マネージャに通
知することを特徴としている。
ネージャがSNMPプロトコルに基づいて複数のエージ
ェントの障害のネットワ−ク管理を行う障害管理方法で
あって、前記エージェントが状態変化を検出する毎に状
態変化のあったオブジェクトID(監視対象項目識別番
号)とその状態変化の内容とを検出順に格納した格納エ
リアを用いて、前記マネージャは一定時間毎に前記エー
ジェントの状態変化の有無の確認要求を行い、前記エー
ジェントは前記マネージャから前記状態変化の有無の確
認要求があった場合に前記格納エリアに格納されていれ
ば状態変化の有を示す一番古い履歴のオブジェクトID
を,前記格納エリアに格納されていなければ状態変化の
ないことをそれぞれマネージャに通知し、前記マネージ
ャは前記状態変化が有の場合に前記通知のあったオブジ
ェクトIDの状態変化の内容の読出要求と新たな状態変
化の有無の確認要求とを前記エージェントに行い、前記
エージェントは前記マネージャから前記オブジェクトI
Dの状態変化の内容の読出要求と新たな状態変化の有無
の確認要求とがあると前記オブジェクトIDの状態変化
の内容と新たな状態変化の有無とを前記マネージャに通
知することを特徴としている。
【0018】更に、上記第2の障害処理方法において、
前記エージェントは前記マネージャに前記オブジェクト
IDの状態変化の内容を通知すると前記格納エリアから
通知した状態情報を消すことを特徴としている。
前記エージェントは前記マネージャに前記オブジェクト
IDの状態変化の内容を通知すると前記格納エリアから
通知した状態情報を消すことを特徴としている。
【0019】
【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して説明する。図1を参照すると、本発明
の実施の形態は、LANまたはWANに接続されたネッ
トワーク3と、ネットワーク3に接続されSNMPのマ
ネージャ(ネットワークを管理する)である監視端末1
と、ネットワーク3に接続されSNMPのエージェント
である複数の被監視端末2とから構成される。
て図面を参照して説明する。図1を参照すると、本発明
の実施の形態は、LANまたはWANに接続されたネッ
トワーク3と、ネットワーク3に接続されSNMPのマ
ネージャ(ネットワークを管理する)である監視端末1
と、ネットワーク3に接続されSNMPのエージェント
である複数の被監視端末2とから構成される。
【0020】監視端末1はSNMPのインターフェース
部であるSNMPマネージャ制御部11と、SNMPを
用いて獲得した状態を解析する監視解析部13と、解析
した結果を表示する監視表示部12とから構成される。
部であるSNMPマネージャ制御部11と、SNMPを
用いて獲得した状態を解析する監視解析部13と、解析
した結果を表示する監視表示部12とから構成される。
【0021】被監視端末2は、SNMPを用いてマネー
ジャと通信するSNMPエージェント制御部21と、自
装置における不具合等の監視を行っている監視処理部2
2と、監視処理部22で検出した監視状態を記憶してい
る状態格納エリア23から構成される。なお、状態格納
エリア23は図1に記載されていない被監視端末2内に
ある記憶部に割り付けられており、この状態格納エリア
23には、監視状態が検出される度に順々に格納されて
いく(履歴が取られる)。
ジャと通信するSNMPエージェント制御部21と、自
装置における不具合等の監視を行っている監視処理部2
2と、監視処理部22で検出した監視状態を記憶してい
る状態格納エリア23から構成される。なお、状態格納
エリア23は図1に記載されていない被監視端末2内に
ある記憶部に割り付けられており、この状態格納エリア
23には、監視状態が検出される度に順々に格納されて
いく(履歴が取られる)。
【0022】被監視端末2の監視処理部22は、被監視
端末2で必要な監視項目をすべて処理しており、障害が
発生または復旧した場合はその都度状態格納エリア23
に状態変化のあった項目のオブジェクトID[MIB
(Management Information B
ase:管理情報ベース)のオブジェクトIDに対応]
およびその状態を記憶する。
端末2で必要な監視項目をすべて処理しており、障害が
発生または復旧した場合はその都度状態格納エリア23
に状態変化のあった項目のオブジェクトID[MIB
(Management Information B
ase:管理情報ベース)のオブジェクトIDに対応]
およびその状態を記憶する。
【0023】また、被監視端末2の監視処理部22は、
被監視端末2自身の状態を監視している。この状態の監
視対象項目は、項目A、項目B、項目C、項目Dの4つ
あるとする。被監視端末2の監視処理部22が監視対象
項目に対する状態の変化を検出すると、検出した順に、
オブジェクトID(各項目に付けられたID名:監視対
象項目識別番号)と、そのときの状態の値(コードで管
理)を状態格納エリア内に格納していく。なお、このと
きの監視処理部22の状態変化の監視方法として、ポー
リングで各項目を見に行く監視方法、および発生時の割
込による監視方法があるが、どちらの場合も適用でき
る。
被監視端末2自身の状態を監視している。この状態の監
視対象項目は、項目A、項目B、項目C、項目Dの4つ
あるとする。被監視端末2の監視処理部22が監視対象
項目に対する状態の変化を検出すると、検出した順に、
オブジェクトID(各項目に付けられたID名:監視対
象項目識別番号)と、そのときの状態の値(コードで管
理)を状態格納エリア内に格納していく。なお、このと
きの監視処理部22の状態変化の監視方法として、ポー
リングで各項目を見に行く監視方法、および発生時の割
込による監視方法があるが、どちらの場合も適用でき
る。
【0024】監視端末1と複数の被監視端末2との間で
SNMPを用いたプロトコルで情報のやりとりが行われ
る。なお、ネットワーク管理のオペレーションで使用さ
れるSNMPメッセージには、GetRequestメ
ッセージ、GetNextRequestメッセージ、
SetRequestメッセージ、GetReques
tメッセージ、GetResponsメッセージ、TR
APメッセージの5つがある。なお、以降の説明では、
語尾のメッセージを略して使用する。
SNMPを用いたプロトコルで情報のやりとりが行われ
る。なお、ネットワーク管理のオペレーションで使用さ
れるSNMPメッセージには、GetRequestメ
ッセージ、GetNextRequestメッセージ、
SetRequestメッセージ、GetReques
tメッセージ、GetResponsメッセージ、TR
APメッセージの5つがある。なお、以降の説明では、
語尾のメッセージを略して使用する。
【0025】図2は、本発明で使用されるGetReq
uestまたはGetResponse発行時における
variable−bindingsフィールド(SN
MPメッセージのUDP形式で定義されたフィールドの
一部で、オブジェクトIDとその値の対の配列として定
義したフィールド)の内容を示した図である。図2を参
照すると、ID(オブジェクトID)と値とが対となり
複数設定(例では、V1、V2、・・・)できるような
っている。ここで、GetRequestでは、マネー
ジャがvariable−bindingsフィールド
で指定したオブジェクトの値を、エージェントがGet
Responseのvariable−binding
sフィールドのオブジェクトの値に設定して応答する。
すなわち、本発明では、図1の監視端末1のSNMPマ
ネージャ制御部21および被監視端末2のSNMPエー
ジェント制御部21は、受信したSNMPメッセージを
解析する場合は、図2のフィールド内容を読み出してメ
ッセージの意味を識別することになる。
uestまたはGetResponse発行時における
variable−bindingsフィールド(SN
MPメッセージのUDP形式で定義されたフィールドの
一部で、オブジェクトIDとその値の対の配列として定
義したフィールド)の内容を示した図である。図2を参
照すると、ID(オブジェクトID)と値とが対となり
複数設定(例では、V1、V2、・・・)できるような
っている。ここで、GetRequestでは、マネー
ジャがvariable−bindingsフィールド
で指定したオブジェクトの値を、エージェントがGet
Responseのvariable−binding
sフィールドのオブジェクトの値に設定して応答する。
すなわち、本発明では、図1の監視端末1のSNMPマ
ネージャ制御部21および被監視端末2のSNMPエー
ジェント制御部21は、受信したSNMPメッセージを
解析する場合は、図2のフィールド内容を読み出してメ
ッセージの意味を識別することになる。
【0026】次に、図1〜図4を参照して本実施の形態
の全体の動作について説明する。今、図2で使用される
オブジェクトIDを説明の都合上、例えば、状態変化の
確認を示す場合は「ST」、項目Aは「SA」、項目B
は「SB」、項目Cは「SC」、項目Dは「SD」とす
る。
の全体の動作について説明する。今、図2で使用される
オブジェクトIDを説明の都合上、例えば、状態変化の
確認を示す場合は「ST」、項目Aは「SA」、項目B
は「SB」、項目Cは「SC」、項目Dは「SD」とす
る。
【0027】図3を参照すると、先ず、マネージャであ
る監視端末1(以降、略してマネージャと呼ぶこともあ
る)のSNMPマネージャ制御部11は、状態変化があ
るかどうかをエージェントに対して図2のV1のIDに
「ST」を、値に「NULL」をそれぞれ設定してGe
tRequestを発行して確認する(図3のシーケン
スG1)。すると、エージェントである被監視端末2
(以降、略してエージェントと呼ぶこともある)のSN
MPエージェント制御部21は、シーケンスG1でGe
tRequestを受けたときに、GetReques
tを解析(図2のフィールドを検索)する。このとき、
SNMPエージェント制御部21は、状態格納エリア2
3には状態変化(履歴情報)が1つも格納されていない
ため、状態変化なしと認識し、状態確認の状態値として
図2のV1のIDに「ST」を、値に「NULL」をそ
れぞれ設定してGetResponseでマネージャに
返す(シーケンスR1)。
る監視端末1(以降、略してマネージャと呼ぶこともあ
る)のSNMPマネージャ制御部11は、状態変化があ
るかどうかをエージェントに対して図2のV1のIDに
「ST」を、値に「NULL」をそれぞれ設定してGe
tRequestを発行して確認する(図3のシーケン
スG1)。すると、エージェントである被監視端末2
(以降、略してエージェントと呼ぶこともある)のSN
MPエージェント制御部21は、シーケンスG1でGe
tRequestを受けたときに、GetReques
tを解析(図2のフィールドを検索)する。このとき、
SNMPエージェント制御部21は、状態格納エリア2
3には状態変化(履歴情報)が1つも格納されていない
ため、状態変化なしと認識し、状態確認の状態値として
図2のV1のIDに「ST」を、値に「NULL」をそ
れぞれ設定してGetResponseでマネージャに
返す(シーケンスR1)。
【0028】次に監視端末1のSNMPマネージャ制御
部11は、状態変化確認のGetResponseにて
NULLが設定されている場合、状態変化がないと認識
して、一定時間を置いてから再度状態変化を確認するた
め、図2のV1のIDに「ST」を、値に「NULL」
をそれぞれ設定してGetRequestをエージェン
トに対して発行する(シーケンスG2)。このとき、状
態変化確認のGetResponseを受けてから、状
態変化確認のGetRequestを発行するまでの時
間は任意の時間に変更可能とする。なお、監視端末1の
SNMPマネージャ11は、GetRequest発行
後、GetResponseが返ってくるまで他に処理
を行わないため、この時間を0にしても問題ない。しか
し、絶え間なくGetRequestまたはGetRe
sponseが実行されてしまい、他のネットワークア
プリケーションに影響を与える可能性があるため、時間
の設定はネットワークの速度に応じて変更することが望
ましい。
部11は、状態変化確認のGetResponseにて
NULLが設定されている場合、状態変化がないと認識
して、一定時間を置いてから再度状態変化を確認するた
め、図2のV1のIDに「ST」を、値に「NULL」
をそれぞれ設定してGetRequestをエージェン
トに対して発行する(シーケンスG2)。このとき、状
態変化確認のGetResponseを受けてから、状
態変化確認のGetRequestを発行するまでの時
間は任意の時間に変更可能とする。なお、監視端末1の
SNMPマネージャ11は、GetRequest発行
後、GetResponseが返ってくるまで他に処理
を行わないため、この時間を0にしても問題ない。しか
し、絶え間なくGetRequestまたはGetRe
sponseが実行されてしまい、他のネットワークア
プリケーションに影響を与える可能性があるため、時間
の設定はネットワークの速度に応じて変更することが望
ましい。
【0029】一方、マネージャがシーケンスR1のGe
tResponseを受けてからシーケンスG2のGe
tRequestを発行するまでに、エージェントにて
項目Aが障害になり、続いて項目Bが障害になったとす
る。すると、被監視端末2の監視処理部22は、項目A
および続いて発生した項目Bの障害を検出し、障害情報
を状態格納エリア23に格納(1つ目の履歴として「S
A」とその障害値、2つ目の履歴として「SB」とその
障害値を格納)する。
tResponseを受けてからシーケンスG2のGe
tRequestを発行するまでに、エージェントにて
項目Aが障害になり、続いて項目Bが障害になったとす
る。すると、被監視端末2の監視処理部22は、項目A
および続いて発生した項目Bの障害を検出し、障害情報
を状態格納エリア23に格納(1つ目の履歴として「S
A」とその障害値、2つ目の履歴として「SB」とその
障害値を格納)する。
【0030】この後、被監視端末2のSNMPエージェ
ント制御部21は、マネージャから状態変化確認のGe
tRequest(シーケンスG2)を受信した場合に
このメッセージを解析し、状態格納エリア23に状態変
化が格納されているかを状態格納エリア23を読み出す
ことにより確認する。この場合、SNMPエージェント
制御部21は、古い情報から検索していく。従って、被
監視端末2のSNMPエージェント制御部21は、最初
に発生した項目Aの状態変化があったことをマネージャ
に通知するために状態変化確認のレスポンスとして図2
のV1のIDに「ST」を、値に状態の変化のあった項
目を示す「SA」をそれぞれ設定してGetRespo
nseを返す。(シーケンスR2)。
ント制御部21は、マネージャから状態変化確認のGe
tRequest(シーケンスG2)を受信した場合に
このメッセージを解析し、状態格納エリア23に状態変
化が格納されているかを状態格納エリア23を読み出す
ことにより確認する。この場合、SNMPエージェント
制御部21は、古い情報から検索していく。従って、被
監視端末2のSNMPエージェント制御部21は、最初
に発生した項目Aの状態変化があったことをマネージャ
に通知するために状態変化確認のレスポンスとして図2
のV1のIDに「ST」を、値に状態の変化のあった項
目を示す「SA」をそれぞれ設定してGetRespo
nseを返す。(シーケンスR2)。
【0031】次に、監視端末1のSNMPマネージャ制
御部11は、シーケンスR2で受け取ったGetRes
ponseを解析することにより、項目Aの状態変化が
あったことを認識できるので、項目Aの状態獲得および
状態変化が他にもないか確認するために状態変化確認の
GetRequestを発行する。すなわち、GetR
equestには、図2のV1のIDに「SA」、値に
「NULL」を、V2のIDに「ST」、値に「NUL
L」をそれぞれ設定されて発行される(シーケンスG
3)。すると、被監視端末2のSNMPエージェント制
御部21は、シーケンスG3で受け取ったGetReq
uestを解析することにより、図2のV1およびV2
の内容を検索することにより監視端末1から要求された
処理を実行することになる。SNMPエージェント制御
部21は、先ず最初に状態格納エリア23から最初に格
納されている項目Aの状態を獲得してレスポンスの値に
設定して、状態格納エリアの項目AのMIBのオブジェ
クトIDおよび状態をクリアする(1履歴分消去す
る)。更に、状態格納エリア23に他にも状態変化があ
るか確認する。この時点では、項目Bの障害の状態が格
納されているので、状態変化確認のレスポンスには項目
BのオブジェクトIDを設定してレスポンスを返す。す
なわち、GetResponseには、図2のV1のI
Dに「SA」、値にその障害値を、V2のIDに「S
T」、値に状態変化ありを示す値をそれぞれ設定されて
発行される(シーケンスR3)。
御部11は、シーケンスR2で受け取ったGetRes
ponseを解析することにより、項目Aの状態変化が
あったことを認識できるので、項目Aの状態獲得および
状態変化が他にもないか確認するために状態変化確認の
GetRequestを発行する。すなわち、GetR
equestには、図2のV1のIDに「SA」、値に
「NULL」を、V2のIDに「ST」、値に「NUL
L」をそれぞれ設定されて発行される(シーケンスG
3)。すると、被監視端末2のSNMPエージェント制
御部21は、シーケンスG3で受け取ったGetReq
uestを解析することにより、図2のV1およびV2
の内容を検索することにより監視端末1から要求された
処理を実行することになる。SNMPエージェント制御
部21は、先ず最初に状態格納エリア23から最初に格
納されている項目Aの状態を獲得してレスポンスの値に
設定して、状態格納エリアの項目AのMIBのオブジェ
クトIDおよび状態をクリアする(1履歴分消去す
る)。更に、状態格納エリア23に他にも状態変化があ
るか確認する。この時点では、項目Bの障害の状態が格
納されているので、状態変化確認のレスポンスには項目
BのオブジェクトIDを設定してレスポンスを返す。す
なわち、GetResponseには、図2のV1のI
Dに「SA」、値にその障害値を、V2のIDに「S
T」、値に状態変化ありを示す値をそれぞれ設定されて
発行される(シーケンスR3)。
【0032】次に監視端末1のSNMPマネージャ制御
部11は、シーケンスR3で受け取ったGetResp
onseを解析する。このとき、SNMPマネージャ制
御部11は、図2のV1の内容(SAとその障害値)
は、監視解析部13に渡す。すると、監視解析部13
は、受け取った内容(項目Aの障害値)を解析して監視
表示部12に表示する。一方、SNMPマネージャ制御
部11は、シーケンスR3で受信したGetRespo
nseの解析内容(図2のV2の内容)から項目Bの状
態変化があったことを認識できるので、項目Bの状態獲
得および状態変化が他にもないか確認するために状態変
化確認のGetRequestを発行する。すなわち、
GetRequestには、図2のV1のIDに「S
B」、値に「NULL」を、V2のIDに「ST」、値
に「NULL」をそれぞれ設定されて発行される(シー
ケンスG4)。すると、被監視端末2のSNMPエージ
ェント制御部21は、シーケンスG4で受け取ったGe
tRequestを解析(図2のV1およびV2の内容
を検索)することにより監視端末1から要求された処理
を実行することになる。SNMPエージェント制御部2
1は、先ず最初に状態格納エリア23の最初に格納され
ている項目Bの状態を獲得してレスポンスの値に設定し
て、状態格納エリアの項目BのMIBのオブジェクトI
Dおよび状態をクリアする(1履歴分消去する)。この
時点で状態格納エリア23には何も格納されていないの
で、状態変化確認のレスポンスにはNULLを設定して
レスポンスを返す。すなわち、GetResponse
には、図2のV1のIDに「SB」、値にその障害値
を、V2のIDに「ST」、値に「NULL」をそれぞ
れ設定されて発行される(シーケンスR4)。
部11は、シーケンスR3で受け取ったGetResp
onseを解析する。このとき、SNMPマネージャ制
御部11は、図2のV1の内容(SAとその障害値)
は、監視解析部13に渡す。すると、監視解析部13
は、受け取った内容(項目Aの障害値)を解析して監視
表示部12に表示する。一方、SNMPマネージャ制御
部11は、シーケンスR3で受信したGetRespo
nseの解析内容(図2のV2の内容)から項目Bの状
態変化があったことを認識できるので、項目Bの状態獲
得および状態変化が他にもないか確認するために状態変
化確認のGetRequestを発行する。すなわち、
GetRequestには、図2のV1のIDに「S
B」、値に「NULL」を、V2のIDに「ST」、値
に「NULL」をそれぞれ設定されて発行される(シー
ケンスG4)。すると、被監視端末2のSNMPエージ
ェント制御部21は、シーケンスG4で受け取ったGe
tRequestを解析(図2のV1およびV2の内容
を検索)することにより監視端末1から要求された処理
を実行することになる。SNMPエージェント制御部2
1は、先ず最初に状態格納エリア23の最初に格納され
ている項目Bの状態を獲得してレスポンスの値に設定し
て、状態格納エリアの項目BのMIBのオブジェクトI
Dおよび状態をクリアする(1履歴分消去する)。この
時点で状態格納エリア23には何も格納されていないの
で、状態変化確認のレスポンスにはNULLを設定して
レスポンスを返す。すなわち、GetResponse
には、図2のV1のIDに「SB」、値にその障害値
を、V2のIDに「ST」、値に「NULL」をそれぞ
れ設定されて発行される(シーケンスR4)。
【0033】次に、監視端末1のSNMPマネージャ制
御部11は、シーケンスR4で受け取ったGetRes
ponseを解析する。このとき、SNMPマネージャ
制御部11は、図2のV1の内容(SBとその障害値)
は、監視解析部13に渡す。すると、監視解析部13
は、受け取った内容(項目Bの障害値)を解析して監視
表示部12に表示する。一方、SNMPマネージャ制御
部11は、シーケンスR3で受信したGetRespo
nseの解析内容(図2のV2の内容)から、状態変化
確認のレスポンスにはNULLが入っているため、一定
時間待ってから再度状態変化の確認のGetReque
stを発行する。すなわち、GetRequestに
は、図2のV1のIDに「ST」を、値に「NULL」
をそれぞれ設定されて発行される(シーケンスG5)。
御部11は、シーケンスR4で受け取ったGetRes
ponseを解析する。このとき、SNMPマネージャ
制御部11は、図2のV1の内容(SBとその障害値)
は、監視解析部13に渡す。すると、監視解析部13
は、受け取った内容(項目Bの障害値)を解析して監視
表示部12に表示する。一方、SNMPマネージャ制御
部11は、シーケンスR3で受信したGetRespo
nseの解析内容(図2のV2の内容)から、状態変化
確認のレスポンスにはNULLが入っているため、一定
時間待ってから再度状態変化の確認のGetReque
stを発行する。すなわち、GetRequestに
は、図2のV1のIDに「ST」を、値に「NULL」
をそれぞれ設定されて発行される(シーケンスG5)。
【0034】なお、上記説明において、状態変化の有無
の確認を行う手段として、上記と違う方法がある。すな
わち、図1の図示していない記憶部に状態変化の有無を
示す状態語(初期値は「0」)を設け、SNMPエージ
ェント制御部21が、状態変化を検出し、状態格納エリ
ア23にその状態を格納する度に状態語を「+1」し、
1履歴消去する度に「−1」するようにしておく。SN
MPエージェント制御部21は、GetRequest
(図2のフィールドに「ST」が設定されている場合)
を受信した場合に、この状態語を読みにいくことで、即
座に判別(SNMPエージェント制御部21が、状態語
が「0」の場合は状態変化なし、状態語が「0」でなけ
れば状態変化ありと判定する)できる。
の確認を行う手段として、上記と違う方法がある。すな
わち、図1の図示していない記憶部に状態変化の有無を
示す状態語(初期値は「0」)を設け、SNMPエージ
ェント制御部21が、状態変化を検出し、状態格納エリ
ア23にその状態を格納する度に状態語を「+1」し、
1履歴消去する度に「−1」するようにしておく。SN
MPエージェント制御部21は、GetRequest
(図2のフィールドに「ST」が設定されている場合)
を受信した場合に、この状態語を読みにいくことで、即
座に判別(SNMPエージェント制御部21が、状態語
が「0」の場合は状態変化なし、状態語が「0」でなけ
れば状態変化ありと判定する)できる。
【0035】また、上記説明において、監視端末1およ
び被監視端末2はそれぞれ1対1の構成で説明したが、
被監視端末2が複数存在していても構わない。すなわ
ち、監視端末1のSNMPマネージャ制御部11が複数
の被監視装置2を監視する場合の一連のシーケンスをフ
ローチャートにまとめたのが図4になる。この場合、図
1の監視端末1には、あらかじめ監視を行う複数の被監
視端末2のネットワークアドレスを図1に記載されてい
ないメモリの監視テーブルに設定しておく(SNMPプ
ロトコルでは、それぞれの端末に設定されたネットワー
クアドレスを指定することによりSNMPメッセージの
送受信ができる)。すなわち、被監視端末2が複数ある
場合、監視端末1のSNMPマネージャ制御部11は、
GetRequestにて状態変化の確認を行う場合
(ステップF1)、ステップF1の処理を行うたびに順
次確認する被監視端末2の対象を切り替えていくことで
対応できる。例えば、被監視端末2が2台(A、B)が
あったする。すると、監視端末1の監視テーブルには、
被監視端末2Aおよび被監視端末2Bのネットワークア
ドレスを監視順に設定されている。
び被監視端末2はそれぞれ1対1の構成で説明したが、
被監視端末2が複数存在していても構わない。すなわ
ち、監視端末1のSNMPマネージャ制御部11が複数
の被監視装置2を監視する場合の一連のシーケンスをフ
ローチャートにまとめたのが図4になる。この場合、図
1の監視端末1には、あらかじめ監視を行う複数の被監
視端末2のネットワークアドレスを図1に記載されてい
ないメモリの監視テーブルに設定しておく(SNMPプ
ロトコルでは、それぞれの端末に設定されたネットワー
クアドレスを指定することによりSNMPメッセージの
送受信ができる)。すなわち、被監視端末2が複数ある
場合、監視端末1のSNMPマネージャ制御部11は、
GetRequestにて状態変化の確認を行う場合
(ステップF1)、ステップF1の処理を行うたびに順
次確認する被監視端末2の対象を切り替えていくことで
対応できる。例えば、被監視端末2が2台(A、B)が
あったする。すると、監視端末1の監視テーブルには、
被監視端末2Aおよび被監視端末2Bのネットワークア
ドレスを監視順に設定されている。
【0036】図4を参照すると、監視端末1のSNMP
マネージャ制御部11は、システムが立ち上がると、監
視テーブルに従って、送出先を決め、先ず被監視端末2
Aの状態変化の確認をGetRequestで行う(ス
テップF1)。次に監視端末1のSNMPマネージャ制
御部11は、GetResponseの内容から状態の
変化がないと判断した場合は、一定時間待って次の被監
視端末である被監視端末2BにGetRequest
(状態変化の確認)を発行する(ステップF2,F5,
F1)。監視端末1のSNMPマネージャ制御部11
は、被監視端末2Aアクセス時、ステップF2で状態変
化を検出した場合は、GetRequestで被監視端
末2Aの状態の内容の獲得と状態の変化の確認を行う
(ステップF3)。次に監視端末1のSNMPマネージ
ャ制御部11は、GetResponseによる被監視
装置2Aの状態の内容の獲得を行い、このとき新たな被
監視端末2Aの状態の変化がない場合は、一定時間待っ
た後、監視テーブルから次の端末である被監視端末2B
にGetRequest(状態の変化の確認)を発行す
る(ステップF4,F5,F1)。ステップF4で被監
視装置2Aの状態変化がある場合は、監視端末1のSN
MPマネージャ制御部11は、状態変化がなくなるま
で、ステップF3とステップF4を繰り返す。このよう
に被監視端末2Bでも状態の変化があった場合は、監視
端末1のSNMPマネージャ制御部11は、状態変化な
しを検出するまで、被監視端末2BにもステップF1〜
F4の動作を繰り返す。すなわち、被監視端末2が多数
あっても、監視端末1のSNMPマネージャ制御部11
は、図4のフローチャートによる同じ動作を実行するこ
とができる。
マネージャ制御部11は、システムが立ち上がると、監
視テーブルに従って、送出先を決め、先ず被監視端末2
Aの状態変化の確認をGetRequestで行う(ス
テップF1)。次に監視端末1のSNMPマネージャ制
御部11は、GetResponseの内容から状態の
変化がないと判断した場合は、一定時間待って次の被監
視端末である被監視端末2BにGetRequest
(状態変化の確認)を発行する(ステップF2,F5,
F1)。監視端末1のSNMPマネージャ制御部11
は、被監視端末2Aアクセス時、ステップF2で状態変
化を検出した場合は、GetRequestで被監視端
末2Aの状態の内容の獲得と状態の変化の確認を行う
(ステップF3)。次に監視端末1のSNMPマネージ
ャ制御部11は、GetResponseによる被監視
装置2Aの状態の内容の獲得を行い、このとき新たな被
監視端末2Aの状態の変化がない場合は、一定時間待っ
た後、監視テーブルから次の端末である被監視端末2B
にGetRequest(状態の変化の確認)を発行す
る(ステップF4,F5,F1)。ステップF4で被監
視装置2Aの状態変化がある場合は、監視端末1のSN
MPマネージャ制御部11は、状態変化がなくなるま
で、ステップF3とステップF4を繰り返す。このよう
に被監視端末2Bでも状態の変化があった場合は、監視
端末1のSNMPマネージャ制御部11は、状態変化な
しを検出するまで、被監視端末2BにもステップF1〜
F4の動作を繰り返す。すなわち、被監視端末2が多数
あっても、監視端末1のSNMPマネージャ制御部11
は、図4のフローチャートによる同じ動作を実行するこ
とができる。
【0037】なお、上記のステップF5の説明におい
て、一定時間を待つという処理は、SNMPマネージャ
制御部11が、図1に図示していないタイマにあらかじ
め決められた値を設定して、タイマを起動し、タイムア
ウト割込によりステップF1の処理を実行するようにす
ればよい。
て、一定時間を待つという処理は、SNMPマネージャ
制御部11が、図1に図示していないタイマにあらかじ
め決められた値を設定して、タイマを起動し、タイムア
ウト割込によりステップF1の処理を実行するようにす
ればよい。
【0038】このような処理を行うことによって、ネッ
トワークに一定以上の負荷をかけないようにして複数の
被監視端末の監視を行うことが可能となる。この場合、
タイマ値を図1に図示していないコンソールから変更で
きるようにしておけば、ネットワ−クの規模により変更
できるため、負荷をかけないという点で望ましい。
トワークに一定以上の負荷をかけないようにして複数の
被監視端末の監視を行うことが可能となる。この場合、
タイマ値を図1に図示していないコンソールから変更で
きるようにしておけば、ネットワ−クの規模により変更
できるため、負荷をかけないという点で望ましい。
【0039】以上説明したように、TRAPを用いてい
ないので、TRAP漏れを考慮する必要がなくなる。T
RAPによる状態変化の通知方式と比べると、エージェ
ントから連続して状態変化が通知されネットワーク上の
負荷が一時的に高くなることもなく、本発明によるマネ
ージャは、GetResponseが返ってくるまで次
のGetRequestを一定時間の間発行しないよう
にしているため、マネージャ自身の処理できる速度以上
にネットワークの負荷があがることはない。
ないので、TRAP漏れを考慮する必要がなくなる。T
RAPによる状態変化の通知方式と比べると、エージェ
ントから連続して状態変化が通知されネットワーク上の
負荷が一時的に高くなることもなく、本発明によるマネ
ージャは、GetResponseが返ってくるまで次
のGetRequestを一定時間の間発行しないよう
にしているため、マネージャ自身の処理できる速度以上
にネットワークの負荷があがることはない。
【0040】また、常に全監視項目の状態の獲得を行う
のではなく、状態変化のあったオブジェクトだけを獲得
するので短い時間ですべての状態変化のあった項目の状
態を獲得することができる。
のではなく、状態変化のあったオブジェクトだけを獲得
するので短い時間ですべての状態変化のあった項目の状
態を獲得することができる。
【0041】従って、ネットワークに負荷をかけないよ
うにしながらできるだけリアルタイムに監視状態を獲得
することが可能となる。
うにしながらできるだけリアルタイムに監視状態を獲得
することが可能となる。
【0042】
【発明の効果】本発明は、SNMPを利用したネットワ
ーク管理システムにおいて、SNMPはUDPを利用し
たコネクションレスのプロトコルであるため、TRAP
漏れを考慮する必要があったが、本方式ではTRAPを
全く使用しないのでTRAP漏れを考慮する必要がない
という効果がある。
ーク管理システムにおいて、SNMPはUDPを利用し
たコネクションレスのプロトコルであるため、TRAP
漏れを考慮する必要があったが、本方式ではTRAPを
全く使用しないのでTRAP漏れを考慮する必要がない
という効果がある。
【0043】更に、本発明は、GetRequestに
より、状態変化の確認をしてから状態変化のあった項目
だけ状態を獲得するようにしているため、常に全監視項
目の状態獲得を行う必要がなく、監視項目分の状態をす
べて獲得するまでの時間を短縮できるという効果があ
る、更に、本発明は、TRAPを用いていないため、マ
ネージャからGetRequestを発行してからエー
ジェントからGetResponseを受けるまで他の
SNMPの処理に対する割り込みが一切発生しないた
め、ネットワーク上の負荷を削減できるという効果があ
る。
より、状態変化の確認をしてから状態変化のあった項目
だけ状態を獲得するようにしているため、常に全監視項
目の状態獲得を行う必要がなく、監視項目分の状態をす
べて獲得するまでの時間を短縮できるという効果があ
る、更に、本発明は、TRAPを用いていないため、マ
ネージャからGetRequestを発行してからエー
ジェントからGetResponseを受けるまで他の
SNMPの処理に対する割り込みが一切発生しないた
め、ネットワーク上の負荷を削減できるという効果があ
る。
【0044】更に、本発明は、何も状態変化がない場
合、次の状態変化の確認まで任意の時間を設定できるよ
うにすることで最適なネットワークパフォーマンスを提
供することができるという効果がある。
合、次の状態変化の確認まで任意の時間を設定できるよ
うにすることで最適なネットワークパフォーマンスを提
供することができるという効果がある。
【図1】本発明の実施の形態を示すブロック図である。
【図2】SNMPメッセージのUDP形式で定義された
フィールドの一部である。
フィールドの一部である。
【図3】図1の監視端末と被監視端末との間の動作を示
すシーケンス図である。
すシーケンス図である。
【図4】図1の監視端末が複数の被監視端末の監視の動
作を行うフロ−チャートである。
作を行うフロ−チャートである。
1 監視端末 2 被監視端末 3 ネットワーク 11 SNMPマネージャ制御部 12 監視表示部 13 監視解析部 21 SNMPエージェント制御部 22 監視処理部 23 状態格納エリア
───────────────────────────────────────────────────── フロントページの続き Fターム(参考) 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)
- 【請求項1】 マネージャがSNMPプロトコルを用い
て複数のエージェントの障害のネットワ−ク管理を行う
障害管理方式において、前記マネージャが一定時間毎に
前記エージェントの状態変化の有無の確認要求を行う第
1の要求手段と、前記エージェントは、前記第1の要求
手段による確認要求が前記エージェントにあると前記エ
ージェン状態変化の有無を前記マネージャに通知する第
1の通知手段と、前記マネージャが前記第1の通知手段
により前記状態変化を検出した場合に前記状態変化の内
容の読出要求を前記エージェントに行う第2の要求手段
と、前記第2の要求手段による要求があると前記状態変
化の内容を前記マネージャに通知する第2の通知手段と
を有することを特徴とする障害管理方式。 - 【請求項2】 前記第2の要求手段は前記第1の要求手
段を含み、前記第2の通知手段は前記第1の通知手段を
含むことを特徴とする請求項1記載の障害処理方式。 - 【請求項3】 前記第1の通知手段は、前記エージェン
トが既に状態変化を検出した状態の時に前記第1の要求
手段による確認要求が前記エージェントにあると前記エ
ージェントが前記エージェン状態変化のあったことを前
記マネージャに通知し、前記エージェントに状態変化を
検出していない状態の時に前記第1の要求手段による確
認要求が前記エージェントにあると前記エージェントが
前記エージェンに状態変化のあったことを前記マネージ
ャに通知することを特徴とする請求項1または2記載の
障害管理方式。 - 【請求項4】 マネージャがSNMPプロトコルを用い
て複数のエージェントの障害のネットワ−ク管理を行う
障害管理方式において、前記マネージャが前記エージェ
ントの状態変化の有無の確認要求を行う第1の要求手段
と、前記マネージャが前記第1の要求手段で状態変化が
ない場合に一定時間たってから前記第1の要求手段を繰
り返す繰り返し手段と、前記エージェントが状態変化を
検出する毎にその状態変化の内容を履歴情報として記憶
する記憶手段と、前記第1の要求手段による確認要求が
前記エージェントにあると前記エージェントが前記記憶
手段で記憶されている前記履歴情報を検索することによ
り状態変化の有無を前記マネージャに通知する第1の通
知手段と、前記マネージャが前記第1の通知手段により
前記状態変化を検出した場合に前記状態変化の内容の読
出要求と新たな状態変化の確認要求とを前記エージェン
トに同時に行う第2の要求手段と、前記第2の要求手段
による要求があると前記エージェントが前記記憶手段で
記憶された履歴情報を検索することにより前記状態変化
の内容と前記新たな状態変化の有無とを前記マネージャ
に通知する第2の通知手段とを有することを特徴とする
障害管理方式。 - 【請求項5】 前記第1および第2の要求手段は、Ge
tRequestメッセージを使用して要求を行うこと
を特徴とする請求項1,2,3または4記載の障害管理
方式。 - 【請求項6】 前記第1および第2の通知手段は、Ge
tResponseメッセージを使用して通知すること
を特徴とする請求項1,2,3または4記載の障害管理
方式。 - 【請求項7】 前記記憶手段は、前記状態変化の起こっ
たオブジェクトID(監視対象項目識別番号)とその状
態変化の内容とを発生した順に記憶していくことを特徴
とする請求項4記載の障害管理方式。 - 【請求項8】 前記第1の通知手段は、前記記憶手段に
記憶された一番古いオブジェクトIDを前記マネージャ
に通知することを特徴とする請求項4記載の障害管理方
式。 - 【請求項9】 前記第2の要求手段は、前記第1の通知
手段で通知のあったオブジェクトIDの状態変化の内容
の読出要求を行うことを特徴とする請求項4記載の障害
管理方式。 - 【請求項10】 マネージャがSNMPプロトコルに基
づいて複数のエージェントの障害のネットワ−ク管理を
行う障害管理方法であって、前記マネージャは一定時間
毎に前記エージェントの状態変化の有無の確認要求を行
い、前記エージェントは既に状態変化を検出した状態の
時に前記マネージャから前記状態変化の有無の確認要求
があった場合に状態変化のあったことをマネージャに通
知し、前記マネージャは前記エージェントから前記状態
変化のあったという通知を受けると前記状態変化の内容
の読出要求を前記エージェントに行い、前記エージェン
トは前記マネージャから前記状態変化の内容の読出要求
があると前記状態変化の内容を前記マネージャに通知す
ることを特徴とする障害管理方法。 - 【請求項11】 マネージャがSNMPプロトコルに基
づいて複数のエージェントの障害のネットワ−ク管理を
行う障害管理方法であって、前記エージェントが状態変
化を検出する毎に状態変化のあったオブジェクトID
(監視対象項目識別番号)とその状態変化の内容とを検
出順に格納した格納エリアを用いて、前記マネージャは
一定時間毎に前記エージェントの状態変化の有無の確認
要求を行い、前記エージェントは前記マネージャから前
記状態変化の有無の確認要求があった場合に前記格納エ
リアに格納されていれば状態変化の有を示す一番古い履
歴のオブジェクトIDを,前記格納エリアに格納されて
いなければ状態変化のないことをそれぞれマネージャに
通知し、前記マネージャは前記状態変化が有の場合に前
記通知のあったオブジェクトIDの状態変化の内容の読
出要求と新たな状態変化の有無の確認要求とを前記エー
ジェントに行い、前記エージェントは前記マネージャか
ら前記オブジェクトIDの状態変化の内容の読出要求と
新たな状態変化の有無の確認要求とがあると前記オブジ
ェクトIDの状態変化の内容と新たな状態変化の有無と
を前記マネージャに通知することを特徴とする障害管理
方法。 - 【請求項12】 前記エージェントは前記マネージャに
前記オブジェクトIDの状態変化の内容を通知すると前
記格納エリアから通知した状態情報を消すことを特徴と
する請求項9記載の障害管理方法。
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 | Snmpエージェント装置 |
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 | Snmpエージェント装置 |
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) | Snmpテ―ブルをモニタ及び維持するシステム及び方法 | |
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) | Snmp를 사용하는 네트워크 관리 시스템의 통계 데이터관리 방법 및 그 장치 | |
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 |