(57)【要約】【課題】  運用系のネットワーク監視装置に対する瞬時的なメッセージ断にも対応できることにより、瞬時的な障害発生時でも円滑に対処できるネットワーク監視システムを提供する。【解決手段】  非運用系のネットワーク監視装置４は、監視対象装置７及び運用系のネットワーク監視装置３の両方から同じ障害通知を受信している否かを判定し、両方から受信している場合又は運用系のネットワーク監視装置３のみから受信している場合は何も実行せず、監視対象装置７のみから受信した場合はデータ保存装置１へ障害通知の内容を登録する。【選択図】  図１
2014179674.tif 000002
【特許請求の範囲】
【請求項１】
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続され、
前記監視対象装置は、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信し、
前記運用系のネットワーク監視装置は、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信し、
前記非運用系のネットワーク監視装置は、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定し、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する、
ネットワーク監視システム。
【請求項２】
前記非運用系のネットワーク監視装置は、新たな障害通知を受信したときに、その前の障害通知を前記判定の対象とする、
請求項１記載のネットワーク監視システム。
【請求項３】
前記非運用系のネットワーク監視装置は、前記障害通知を受信してから一定時間経過したときに、当該障害通知を前記判定の対象とする、
請求項１記載のネットワーク監視システム。
【請求項４】
前記非運用系のネットワーク監視装置は、前記データ保存装置へ前記障害通知の内容を登録した後、当該障害通知の内容を前記データ保存装置に問い合わる、
請求項１乃至３のいずれか一つに記載のネットワーク監視システム。
【請求項５】
前記非運用系のネットワーク監視装置は、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録することに代えて、前記運用系のネットワーク監視装置へ当該障害通知の喪失があった旨の報告をし、
前記運用系のネットワーク監視装置は、前記障害通知の喪失があった旨の報告を受けると、前記データ保存装置へ当該障害通知の内容を登録する、
請求項１乃至４のいずれか一つに記載のネットワーク監視システム。
【請求項６】
前記監視対象装置、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置の少なくとも一つが複数台設けられた、
請求項１乃至５のいずれか一つに記載のネットワーク監視システム。
【請求項７】
前記運用系のネットワーク監視装置は、前記監視対象装置から新たな障害通知を一定時間以上受信できない場合に、新たな障害通知を受信しているか否かを前記非運用系のネットワーク監視装置に問い合わせ、当該非運用系のネットワーク監視装置から新たな障害通知を受信している旨の返答を受けた場合は、当該新たな障害通知を前記データ保存装置へ登録する、
請求項１乃至６のいずれか一つに記載のネットワーク監視システム。
【請求項８】
前記非運用系のネットワーク監視装置は、前記監視対象装置のみから受信した場合は、前記監視対象装置に対して当該障害通知の送信の有無を確認し、当該障害通知の送信があったときは、当該障害通知の喪失があったと判断する、
請求項１乃至７のいずれか一つに記載のネットワーク監視システム。
【請求項９】
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続されたネットワーク監視システムに用いられるネットワーク監視方法であって、
前記監視対象装置が、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信する工程と、
前記運用系のネットワーク監視装置が、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信する工程と、
前記非運用系のネットワーク監視装置が、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定し、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する工程と、
を含むネットワーク監視方法。
【請求項１０】
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続され、
前記監視対象装置が、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信し、
前記運用系のネットワーク監視装置が、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信する、ネットワーク監視システム、
に用いられるネットワーク監視プログラムであって
前記非運用系のネットワーク監視装置に含まれるコンピュータに、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定する処理と、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する処理と、
を実行させるためのネットワーク監視プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク監視システム、ネットワーク監視方法及びネットワーク監視プログラム、換言すると、ネットワーク装置及びネットワーク中継装置に対する、ネットワーク監視装置による障害情報収集の冗長化高度化方法に関する。
【背景技術】
【０００２】
ネットワーク装置及びネットワーク中継装置の障害通知に対する処理能力は、ネットワーク監視装置より相対的に低い。その理由は、ネットワーク装置は自身の本来目的であるアプリケーション処理に注力していること、ネットワーク中継装置は中継処理に注力していることにより、それぞれ、障害通知に対する処理能力に振分けられる割合が監視専門の装置よりも低いためである。
【０００３】
そのため、ネットワーク装置及びネットワーク中継装置によるネットワーク監視装置への障害通知は、なるべく簡素なものであることが求められる。したがって、監視用の障害通知には、ＴＣＰ（例：ｔｅｌｎｅｔ）のような再送能力が必要なプロトコルではなく、ＵＤＰ（例：ＳＮＭＰ）のような再送が不要で負荷の低い通知方法を採用している。例えば、回線障害／回線復旧のように基本的な障害通知は、ＵＤＰベースのＳＮＭＰを使用したＲＦＣ１２１５で標準化されている。その他企業で定義された障害通知もＳＮＭＰを用いて標準化しており、ネットワーク監視装置は監視対象が実装する標準化されたプロトコルを使用せざるを得ない。
【０００４】
標準プロトコルを使わずに新たな機能追加を監視対象の中継装置に導入することは、可能ではあるが、監視対象の装置の種類及び数ともに多い場合に、ネットワーク監視装置の機能の追加と比べて導入コストが非常に高くなる。また、監視対象の装置が自部門の装置で無いとき、レガシーであるとき、他社メーカの装置であるときなど、装置に新たな機能を付与することができない場合も、標準化されたプロトコルのみで監視を行なわざるを得ない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−２４４４９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ただし、ＵＤＰのように再送を行なわないプロトコルを使用した場合、ネットワーク上の回線断や負荷により、障害通知が喪失することがあり得る。この喪失問題を解決するため、障害通知先を冗長して同じ障害通知を複数のネットワーク監視装置に送信することにより、通知の喪失を避けている。
【０００７】
しかし、複数のネットワーク監視装置で受信した全ての障害通知を採用した場合、次の１、２の問題が発生する。１．障害通知のイベント発生が２倍（イベント履歴が２倍）になる。２．受信したタイミングや、処理するタイミングや、障害通知の喪失により、現状状態を表す障害通知の復元問題が発生する（カレントアラームが正しく反映されない）。
【０００８】
ここでは、「障害通知の復元問題」を次のように定義する。障害通知の復元問題とは、例えば監視対象装置Ｎから同一部位の回線障害通知と回線復旧通知とが順次発生し、それらをネットワーク監視装置Ｍ１，Ｍ２が受信した場合に（ただしＭ２は回線復旧を喪失）、Ｍ１の処理で現状を回線復旧としたにもかかわらず、Ｍ２の処理で回線障害の処理をしてあたかも再び障害が復元したかのように見える現象である。逆に障害が発生しているのに復旧しているように見える場合も、ここでは障害通知の復元問題であるとする。
【０００９】
障害通知にはＳＮＭＰの構造上、監視対象装置の起動時からのタイムスタンプが付いているため、障害通知の時間的な前後関係を知ることは時間を掛けることで調査可能である。しかし、全ての障害通知に対して毎回前後関係を確認することは、監視する対象、監視する部位、及び、監視する障害種別が多い場合、並びに、障害通知の発生数が多い場合、一度に大量の障害通知が発生した場合など、ネットワーク監視装置の処理能力としても難しくなるため処理遅延の要因となり、迅速にオペレータに障害を通知できなくなる問題が生じる。
【００１０】
この問題を回避するために、ネットワーク監視系の１つを運用系、残りのネットワーク監視系を非運用系と定義し、運用系のみで障害通知の処理をすることを考えてみる。
【００１１】
これにより、次の１〜４の利点が得られる。１．冗長化により、ロバストなネットワーク上の回線断に対して運用系と非運用系を入れ替えることで対応できる。２．運用系のみに絞ることにより、発生する障害通知が来た数と一致する（イベント履歴が２倍にならない）。３．同じく運用系のみに絞ることにより、時系列で障害通知を処理することができ復元問題が起きない（カレントアラームが正しく反映される）。４．カレントアラームを正しく反映させるため、運用系が全アラームの障害通知に対して毎回前後関係を調査する必要がなく、運用系の処理能力低下が起きない。
【００１２】
その反面、運用系のネットワーク監視装置に対する、負荷による瞬時的なメッセージ断には、対応できないという欠点が生じる。
【００１３】
そこで、本発明の目的は、運用系のネットワーク監視装置に対する瞬時的なメッセージ断にも対応できることにより、瞬時的な障害発生時でも円滑に対処できるネットワーク監視システム等を提供することにある。
【課題を解決するための手段】
【００１４】
本発明に係るネットワーク監視システムは、
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続され、
前記監視対象装置は、
障害が発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信し、
前記運用系のネットワーク監視装置は、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信し、
前記非運用系のネットワーク監視装置は、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定し、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する、
ものである。
【発明の効果】
【００１５】
本発明によれば、ネットワーク監視装置の複数冗長化により、監視対象装置からの障害発生をより正確に受信しつつ、ネットワーク監視装置を運用系と非運用系に分け、非運用系側で運用系への障害通知の抜け漏れを確認することで、瞬時的な障害発生時でも円滑に対処できる。
【図面の簡単な説明】
【００１６】
【図１】実施形態１のネットワーク監視装置を示すブロック図である。
【図２】実施形態１のネットワーク監視装置の動作を示すシーケンスチャート（その１）である。
【図３】実施形態１のネットワーク監視装置の動作を示すシーケンスチャート（その２）である。
【図４】実施形態１のネットワーク監視装置の動作を示すシーケンスチャート（その３）である。
【図５】実施形態２のネットワーク監視装置の動作を示すシーケンスチャートである。
【図６】実施形態３のネットワーク監視装置の動作を示すシーケンスチャートである。
【図７】実施形態４のネットワーク監視装置を示すブロック図である。
【図８】実施形態４のネットワーク監視装置の動作を示すシーケンスチャートである。
【図９】実施形態５のネットワーク監視装置を示すブロック図である。
【図１０】実施形態６のネットワーク監視装置を示すブロック図である。
【図１１】実施形態７のネットワーク監視装置の動作を示すシーケンスチャートである。
【図１２】実施形態８のネットワーク監視装置の動作を示すシーケンスチャートである。
【発明を実施するための形態】
【００１７】
以下、添付図面を参照しながら、本発明を実施するための形態（以下「実施形態」という。）について説明する。
【００１８】
図１は、実施形態１における監視対象装置と冗長化されたネットワーク監視装置との構成例である。
【００１９】
ネットワーク監視システムにおいて、データ保存装置１は、監視対象装置７から報告された障害内容を蓄積するために使用する。ネットワーク２は、データ保存装置１とネットワーク監視装置３，４とを結ぶ。ネットワーク監視装置３，４とデータ保存装置１と間、及び、ネットワーク監視装置３，４の相互間の通信は、ネットワーク２を通じて行なわれる。これらの間の通信は、再送機能を有したプロトコルを用いて行い、ネットワーク５，６と異なりメッセージの喪失は発生させない。
【００２０】
ネットワーク監視装置３，４は、互いに冗長化が組まれており、片方が運用系、もう片方が非運用系となる。ここでは、ネットワーク監視装置３が運用系、ネットワーク監視装置４が非運用系とする。運用系のネットワーク監視装置３は、監視対象装置７からの障害通知を受けると、データ保存装置１に障害内容を登録する。非運用系のネットワーク監視装置４は、監視対象装置７からの障害通知を受けるとその内容を自身で保持する。
【００２１】
運用系のネットワーク監視装置３自体が障害を検出すると、運用系と非運用系は入れ替わって動作をする。このとき、非運用系から運用系に代わったネットワーク監視装置４は、障害が発生した以降の自身で保持していた内容をデータ保存装置１に追加し、障害中に発生した内容をデータ保存装置１に登録して補完する。
【００２２】
ネットワーク５は、ネットワーク監視装置３と監視対象装置７とを結ぶ。監視対象装置７からネットワーク監視装置３への障害通知は、ネットワーク５を通じて行なわれる。ネットワーク６は、ネットワーク監視装置４と監視対象装置７とを結ぶ。監視対象装置７からネットワーク監視装置４への障害通知は、ネットワーク６を通じて行なわれる。障害通知はＵＤＰのように再送を行なわないプロトコルを用いて通知されるため、障害通知の喪失が発生することがある。
【００２３】
本実施形態１の動作を図２、図３、図４のシーケンスチャートを用いて説明する。
【００２４】
図２は、既存のネットワーク監視システムでの正常時の障害通知の処理の例を示している。
【００２５】
図２における監視対象装置１ａは、図１における監視対象装置７と同じであり、障害通知（処理５ａ，６ａ）を発生する。図２におけるネットワーク監視装置２ａは、図１におけるネットワーク監視装置３と同じであり、ここでは運用系としている。図２におけるネットワーク監視装置３ａは、図１におけるネットワーク監視装置４と同じであり、ここでは非運用系としている。図２おけるデータ保存装置４ａは、図１におけるデータ保存装置１と同じである。以下、「運用系のネットワーク監視装置」を「運用系」「非運用系のネットワーク監視装置」を「非運用系」と略称する。
【００２６】
処理５ａ，６ａは監視対象装置１ａからの障害通知である。処理５ａは運用系２ａへの障害通知である。処理６ａは非運用系３ａへの障害通知である。非再送のプロトコルを用いて通信を行なった場合、通知が喪失する場合があり得る。監視対象装置１ａは、ネットワーク監視装置が運用系であるか否かについては考慮しない。なぜなら、監視対象装置１ａは、既存装置であり、系を意識するような処理を持たないためである。
【００２７】
処理７ａは、運用系２ａからデータ保存装置４ａへの障害通知内容の登録処理である。非運用系３ａからは、データ保存装置４ａへの障害通知内容の登録処理は行わない。なぜなら、その登録処理を行なうと二重にアラーム受信したことになり、またタイミングによって障害通知の復元問題も発生させることがあるからである。
【００２８】
ここで、従来技術では、監視対象装置１ａから運用系２ａへの障害通知（処理５ａ）が喪失すると、非運用系３ａへの障害通知（処理６ａ）が喪失していなかったとしても、データ保存装置４ａに障害内容が保存されないという問題があった。
【００２９】
図３は、運用系で障害通知の瞬時的なメッセージ喪失が発生し、非運用系で障害通知が喪失せず存在している場合に、非運用系が障害通知の復旧させる例を示している。
【００３０】
図３における１ｂ〜７ｂまでは、図２における１ａ〜７ａまでと同じ装置又は処理である。処理８ｂは、処理５ｂをイベントトリガとした、運用系２ｂから非運用系３ｂへの監視対象装置１ｂの障害内容の通知である。非運用系３ｂは、運用系２ｂからの障害通知を受け取ると、過去に同じ障害通知が存在したか確認し、つまり障害通知の抜けを判定し、抜けがない場合はデータ保存装置４ｂに障害内容を保存しない。これは、障害通知の復元問題を起こさないようにするための工夫である。
【００３１】
この障害通知の抜けの判定は、大量に障害通知がネットワーク監視装置に到着した場合に負荷の高い処理になる。しかし、負荷が高くなるのは障害通知の抜けの判定を行う非運用系３ｂのみであり、データ保存装置４ｂに書き込みを行なってオペレータに通知を行なう運用系２ｂには影響しない。
【００３２】
また、抜けの判定は、監視対象装置１ｂから非運用系３ｂまでのネットワーク遅延と、監視対象装置１ｂから運用系２ｂを経て非運用系３ｂまでのネットワーク遅延との、どちらか大きいほうに相当する時間以上待ち合わせてから行う。これはネットワーク上の遅延により障害通知の受信が遅れることがあるためである。
【００３３】
障害通知の抜けがあった場合の例は、処理９ｂ〜１５ｂになる。以下のシーケンスは、運用系２ｂへの障害通知が喪失し、非運用系３ｂへの障害通知が喪失しなかった場合の例である。
【００３４】
処理９ｂ，１０ｂは、処理５ｂ，６ｂとは別の、監視対象装置１ｂからの新たな障害通知である。処理９ｂは運用系２ｂへの障害通知である。ただし、このシーケンス例では処理９ｂの障害通知が喪失する。処理１０ｂは、非運用系３ｂへの障害通知である。この場合、処理９ｂの障害通知は喪失しているので、処理８ｂと同様の通知は行なわれない。
【００３５】
処理１１ｂ，１２ｂは、処理９ｂ，１０ｂとは別の、監視対象装置１ｂからの新たな障害通知である。処理１１ｂは運用系２ｂへの障害通知である。処理１２ｂは非運用系３ｂへの障害通知である。処理１４ｂは、処理１１ｂをイベントトリガとした、運用系２ｂから非運用系３ｂへの監視対象装置１ｂの障害内容の通知である。
【００３６】
非運用系３ｂは、運用系２ｂからの新たな障害通知を受け取ると、過去の障害通知について同じ受信が存在したか否かを確認し、処理９ｂに相当する障害通知を運用系２ｂから受信しなかったことを確認する。障害通知の抜けを確認した非運用系３ｂは、非運用系３ｂが保持している障害通知情報から、発生した時刻以降の障害通知で同一部位かつ同一種別の障害通知（発生又は復旧したもの）が存在するか否か確認する。
【００３７】
そのような障害通知が存在した場合は、抜けた障害通知に対する処理１５ｂによる障害内容の登録は、そのイベントのみが発生したことを通知する（イベント履歴登録）のみで、現在のアラームとしての登録（カレントアラーム登録）は行わない。なぜなら、保存した場合、障害通知の復元問題が発生するからである。
【００３８】
この復元問題は、例えば監視対象装置１ｂの同一部位に回線障害が発生後（処理９ｂ，１０ｂに相当）、回線復旧により復旧（処理１１ｂ，１２ｂに相当）し、運用系２ｂに回線障害の抜け（処理９ｂ）があった場合、処理１５ｂにより復元させると、実際には回線は復旧しているのに、オペレータにはあたかも回線障害が起きているかのように見えてしまう問題である。逆に、回線障害が発生しているのに回線復旧のように見える場合もあり得る。
【００３９】
発生した時刻以降の同一部位かつ同一種別の障害通知が存在しないことが確認できれば、非運用系３ｂは処理１５ｂの障害内容の登録処理を行なう。処理１５ｂは、非運用系３ｂからのデータ保存装置４ｂへの障害内容（処理１０ｂ）の登録処理である。
【００４０】
図４は、非運用系で障害通知の瞬時的なメッセージ喪失が発生し、運用系で障害通知が喪失せず存在している場合の例を示している。
【００４１】
図４における１ｃ〜８ｃまでは、図３における１ｂ〜８ｂまでの装置又は処理と同じである。処理９ｃは運用系２ｃへの障害通知である。処理１０ｃは非運用系３ｃへの障害通知である。ただし、このシーケンス例では処理１０ｃの障害通知が喪失する。処理１１ｃは、処理９ｃをイベントトリガとした、運用系２ｃから非運用系３ｃへの監視対象装置１ｃの障害内容の通知である。
【００４２】
ここで、非運用系３ｃは、処理１０ｃに相当する障害通知の抜けがあることを認識するが、運用系２ｃからデータ保存装置４ｃへ障害内容は保存されているため、特に何も行なわない。
【００４３】
本実施形態１によれば、ネットワーク監視装置の複数冗長化により、ネットワーク装置からの障害発生をより正確に受信しつつ、監視対象からの標準化されているプロトコルのみで、ネットワーク監視装置を運用系と非運用系とに意味分けし、非運用側で障害通知の抜け漏れを確認することで瞬時的な障害発生時でも円滑に処理ができる。
【００４４】
＜実施形態２（非運用系が障害状況を保持していない場合）＞
図３及び図４の例では非運用系が障害状況を保持して障害通知の復元問題が発生しないように考慮していたが、非運用系が障害状況を保持しない方法もある。
【００４５】
図５は、非運用系が障害内容を保持しない例である。
【００４６】
図５における１ｄ〜１５ｄは、図３における１ｂ〜１５ｂまでと同じ装置又は処理である。処理１６ｄ，１７ｄでは、データ保存装置４ｄに処理８ｄ，１４ｄに相当するデータがあるか否かについて非運用系３ｄが存在確認を行っている。このようにすることで、非運用系３ｄが障害内容を保持していない場合でも支障がなくなる。
【００４７】
＜実施形態３（非運用系が抜けを検出した場合に運用系へ戻す）＞
図３の例では、非運用系３ｂが障害通知の抜けを検出するとデータ保存装置４ｂに直接障害内容の登録を行っていたが、その場合、運用系２ｂで後から発生した障害内容との復元問題が発生する場合がある。その問題を回避するために、非運用系３ｂは抜けを検出した場合に一旦運用系２ｂに抜けのあった障害内容を送付し、運用系２ｂで更に問題ないことを確認することで一箇所からデータ保存処理を行わせることもできる。
【００４８】
図６は、非運用系が抜けを検出したときに運用系に抜けを報告し、運用系からデータ保存装置へ書き込みを行なう例である。
【００４９】
図６における１ｅ〜１５ｅは、図３における１ｂ〜１５ｂまでと同じ装置又は処理である。処理１５ｅでは、図３における処理１５ｂと異なり、データ保存装置４ｅへの障害内容の登録を行わず、運用系２ｅへ抜けのあった障害内容の報告を行なう工夫をしている。
【００５０】
一旦、非運用系３ｅで確認を行うことで、大半の障害通知については運用系２ｅで確認する必要がなくなり、全ての復元問題の確認処理を運用系２ｅで行うよりも負荷が軽減される。単位時間当りに抜けた障害通知が複数発生する場合は、運用系２ｅの処理負荷が高くなるが、その場合、運用系２ｅの障害通知処理にネットワーク的な問題があると判断できるので、運用系２ｅと非運用系３ｅとを入れ替える処理を行なうことで負荷を下げることもできる。
【００５１】
処理１６ｅは、抜けがあった障害通知をデータ保存装置４ｅに登録する処理である。このとき、非運用系３ｅと同様に、その発生した障害通知の受信時刻以降で同一部位かつ同一種別の障害通知がないことを運用系２ｅ側でも確認し、存在する場合はその障害通知は復元問題を避けるため現状態の障害通知としては廃棄する（カレントアラームとしては廃棄する）。一方、イベントの発生した旨については登録する（イベント履歴としては登録）。
【００５２】
＜実施形態４（非運用系を複数台にする）＞
図３から図６までの例では非運用系は１つであるが、図７のように非運用系を複数台にすることもできる。ただし、非運用系に対し同時に運用系から障害通知を発行すると、複数台の非運用系から同時に同じ障害通知を検出する場合があり得るので、図８に示すような工夫が必要である。
【００５３】
図７は、非運用系を複数台にした場合の構成図である。
【００５４】
図７における１ｆ〜７ｆは、図１における１〜７の装置又はネットワークと同じである。非運用系８ｆはＡ台目である（ここで、Ａは２以上の整数である）。ネットワーク９ｆは、監視対象装置７ｆとＡ台目の非運用系８ｆとを繋ぐで（ここで、Ａは２以上の整数である）。
【００５５】
図８は、非運用系を複数台とした場合のシーケンスである。
【００５６】
図８における１ｇ〜３ｇは、図２における１ａ〜３ａと同じ装置である。非運用系４ｇはａ台目のネットワーク監視装置である（ここで、ａは１＜ａ≦Ａの整数である。）。非運用系５ｇは図７における非運用系８ｆと同じＡ台目のネットワーク監視装置である（ここで、Ａは２≦Ａの整数である）。データ保存装置６ｇは図２におけるデータ保存装置４ａと同じである。処理７ｇ〜１０ｇは、監視対象装置１ｇから運用系２ｇ及び非運用系３ｇ〜５ｇへ向けた同一の障害内容通知である。処理１１ｇは、運用系２ｇからデータ保存装置６ｇへの障害通知内容の登録処理である。
【００５７】
処理１２ｇは、処理７ｇをイベントトリガとした、運用系２ｇから１台目の非運用系３ｇへの、監視対象装置１ｇの障害内容の通知である。これは、監視対象装置１ｇから１台目の非運用系３ｇへの処理８ｇと同じ障害内容通知である。通知を受けた１台目の非運用系３ｇは、同一の障害内容が監視対象装置１ｇから送信されていることを確認後、２台目の非運用系４ｇがあれば同一の障害内容を通知する。このように障害内容は次の非運用系に伝播させる。
【００５８】
処理１３ｇは、ａ−１台目の非運用系３ｇからａ台目（１＜ａ≦Ａ）の非運用系４ｇへの、非運用系４ｇへの処理９ｇと同じ障害内容通知である。通知を受けたａ台目の非運用系４ｇは、同一の障害内容が監視対象装置１ｇから送信されていることを確認後、ａ＋１台目の非運用系５ｇがあればそこへ同一の障害内容を通知する。処理１４ｇは、Ａ−１台目の非運用系４ｇからＡ台目（１＜Ａ）の非運用系５ｇへの、非運用系５ｇへの処理１０ｇと同じ障害内容通知である。通知を受けたＡ台目の非運用系５ｇは、同一の障害内容が監視対象装置１ｇからから送信されていることを確認後、Ａ＋１台目の非運用系がないため、処理を終了する。
【００５９】
処理１５ｇ〜１８ｇは、監視対象装置１ｇから運用系２ｇ及び非運用系３ｇ〜５ｇへ向けた同一の障害内容通知である。ただし、本実施形態４の特徴を示すため、運用系２ｇ及びａ台目以外の非運用系３ｇ，５ｇに向けた障害通知は、ネットワーク中継の途中で喪失した例とする。処理１９ｇ〜２２ｇは、監視対象装置１ｇから運用系２ｇ及び非運用系３ｇ〜５ｇへ向けた同一の障害内容通知である。処理２３ｇは、運用系２ｇからデータ保存装置６ｇへの障害通知内容の登録処理である。
【００６０】
処理２４ｇは、処理１９ｇをイベントトリガとした、運用系２ｇから１台目の非運用系３ｇへの、監視対象装置１ｇの障害内容の通知である。通知を受けた１台目の非運用系３ｇは、同一の障害内容が監視対象装置１ｇから送信されていることを確認後、２台目の非運用系４ｇがあればそこへ同一の障害内容を通知する。このように障害内容は次の非運用系に伝播させる。
【００６１】
処理２５ｇは、ａ−１台目の非運用系３ｇからａ台目（１＜ａ≦Ａ）の非運用系４ｇへの、非運用系４ｇへの処理２１ｇと同じ障害内容通知である。通知を受けたａ台目の非運用系４ｇは、同一の障害内容が監視対象装置１ｇから送信されていることを確認後、ａ＋１台目の非運用系５ｇがあればそこへ同一の障害内容を通知する。ただし、非運用系４ｇは、この時点で処理１７ｇに対応する障害内容の通知が来ていないことを確認により検出できるので、処理２７ｇを行なう。処理２６ｇは、Ａ−１台目の非運用系４ｇからＡ台目（１＜Ａ）の非運用系５ｇへの、非運用系５ｇへの処理２２ｇと同じ障害内容通知である。通知を受けたＡ台目の非運用系５ｇは、同一の障害内容が監視対象装置１ｇから送信されていることを確認後、Ａ＋１台目の非運用系がないため、処理を終了する。
【００６２】
処理２７ｇは、処理２５ｇにより処理１７ｇの障害内容に抜けがあることを検出して、非運用系４ｇからａ−１台目の非運用系３ｇへ抜けの通知を行なう処理である。これは、処理１６ｇと同じ処理となる。このように１台前の非運用系に処理を伝播させる。
【００６３】
処理２８ｇは、抜けがあった障害通知を、非運用系３ｇから運用系２ｇに報告する処理である。このとき、ａ台目の非運用系４ｇと同様に、その発生した障害通知の受信時刻以降で同一部位かつ同一種別の障害通知がないことを運用系２ｇ側でも確認し、存在する場合はその障害通知は復元問題を避けるため廃棄する。
【００６４】
ａ台目の非運用系４ｇが運用系２ｇに通知を返さない理由は二つある。第一に、ａ台目より前の非運用系３ｇに障害内容の情報を通知して蓄積させ、復元問題を避けるための情報として利用させるためである。第二に、ａ台より前の非運用系３ｇが既に抜けを検出して運用系２ｇに報告している場合、再度の通知は運用系２ｇの負荷増大に繋がるので、負荷を増大させないためである。
【００６５】
処理２９ｇは、抜けがあった障害通知を運用系２ｇからデータ保存装置６ｇへ登録する処理である。このとき、ａ台目の非運用系４ｇと同様に、その発生した障害通知の受信時刻以降で同一部位かつ同一種別の障害通知がないことを運用系２ｇ側でも確認し、存在する場合はその障害通知は復元問題を避けるため廃棄する。これは、処理１５ｇと同じ処理になる。
【００６６】
＜実施形態５（監視対象装置を増やす）＞
図３から図８の例では、監視対象装置は１台であったが、監視対象装置を複数台にすることもできる。監視対象装置のそれぞれの動作は、図８に示す動作と同じになる。
【００６７】
図９は、監視対象装置を増やした例である。
【００６８】
図９における１ｈ〜６ｈは、図１における１〜６までと同じ装置又はネットワークである。監視対象装置７ｈは１台目である。監視対象装置８ｈは２台目である。監視対象装置９ｈはＢ−１台目である。これらは、図１の監視対象装置７と同じように管理する。
【００６９】
＜実施形態６（監視地域を増やす）＞
図３から図９の例では、管理対象の装置は１地域だけであったが、ネットワーク監視装置の担当を複数地域に分割し、１ネットワーク監視装置の管理対象の監視対象装置数を削減しつつ、複数地域の装置を監視することもできる。それぞれの地域の動作は、図９に示す動作と同じになる。
【００７０】
図１０は、監視地域を増やした例である。
【００７１】
データ保存装置１ｉは、図９におけるデータ保存装置１ｈと同じである。ネットワーク２ｉ，５ｉ，６ｉは、図９におけるネットワーク２ｈ，５ｈ，６ｈと同じである。運用系３ｉ及び非運用系４ｉは、図９における運用系３ｈ及び非運用系４ｈと同じであり、１番目の地域に存在する監視対象装置７ｉ，８ｉを担当している。
【００７２】
ネットワーク１１ｉ，１２ｉは、図９におけるネットワーク５ｈ，６ｈと同じである。運用系９ｉ及び非運用系１０ｉは、図９における運用系３ｈ及び非運用系４ｈと同じであり、Ｃ番目（１≦Ｃ）の地域に存在する監視対象装置１３ｉ，１４ｉを担当している。
【００７３】
＜実施形態７（アラームが来ていない場合の処置）＞
図６の例では、同一装置から次の障害通知が来るまで、すなわち図６の処理１４ｅの通知が来るまで、図６の処理９ｅの障害通知が抜けたことを検出できない。そのため、次の障害通知が来るまでに時間的な空きがあると、障害の検出が空きの分だけ遅延するという問題がある。遅延を防ぐために図１１のように、特定装置からの障害通知が最後に来たあと、設定した時間までに新たな障害通知が送付されない場合、非運用系に対して抜けが無いか否かの確認の通知を行い、抜けがある場合は運用系に通知を行なわせる工夫を導入することもできる。
【００７４】
図１１における１ｊ〜１０ｊは、図６における１ｅ〜１０ｅと同じ装置又は処理である。ここで、図６との違いは、監視対象装置１ｊから新たな障害通知が出ないことである。処理１１ｊは、監視対象装置１ｊから新たな障害通知が出ない場合に、設定した時間だけ待って非運用３ｊに抜けが無いか否かの確認を行わせる処理である。処理１２ｊは、処理１１ｊの確認通知を受けて、抜けを検出し運用系２ｊに抜けがあることを検知し、運用系２ｊにその旨を通知する処理である（図６における処理１５ｅと同じである。）。処理１３ｊは、処理１２ｊの通知を受けて、転置問題がないことを確認後、データ保存装置４ｊに書き込みを行なう処理である（図６における処理１６ｅと同じである）。
【００７５】
＜実施形態８（監視対象装置への問い合わせ処理の追加）＞
図６の例では監視対象装置に抜けた障害通知が実際に行われているかの確認を行っていないが、監視対象装置に抜けの確認を図１２に示すように行わせることができる。ただし、図３乃至図１１の例では監視対象装置側に本発明のための作りこみは必要ないが、本実施形態８では確認の応答処理を行なうために監視対象装置側に修正が必要になる。
【００７６】
図１２における１ｋ〜１６ｋまでは、図６における１ｅ〜１６ｅと同じ装置又は処理である。処理１７ｋは、非運用３ｋで障害通知の抜けを検出したときに監視対象装置１ｋに確認を行わせる例である。これによって、障害通知の抜けの有無を確定させることができる。障害通知の抜けがある場合は、図６の場合と同様に処理１５ｋの通知を行い、抜けがない場合は処理１５ｋ以降の通知を行なわない。
【００７７】
＜その他＞
以上、上記各実施形態を参照して本発明を説明したが、本発明は上記各実施形態に限定されるものではない。本発明の構成や詳細については、当業者が理解し得るさまざまな変更を加えることができる。また、本発明には、上記各実施形態の構成の一部又は全部を相互に適宜組み合わせたものも含まれる。
【００７８】
本発明に係るネットワーク監視方法は、本発明に係るネットワーク監視システムの動作を方法の発明として捉えたものである。本発明に係るネットワーク監視プログラムは、本発明に係るネットワーク監視システムの各処理（動作）をコンピュータに実行させるためのものである。コンピュータは例えばＣＰＵ、メモリ、入出力インタフェースなどを備え、メモリに記憶された本プログラムをＣＰＵが読み出し解釈し実行する。
【００７９】
本発明の特徴は、ネットワーク監視装置で障害情報の冗長化をする場合に運用系／非運用系を用意する二重化を行なう場合にあたって、運用系情報に非運用系からの情報を加味して通知漏れを防ぐことを特徴とする。運用系システムから非運用系システムに、処理した障害通知情報をＴＣＰのよう再送機能のある安定したプロトコルを用いて通知し、非運用系で喪失した障害通知が無いか否か確認させることで、運用系の負荷を減らして迅速にオペレータに障害を通知しつつ、非運用系で喪失した障害通知を検出／復元できるようにする。
【００８０】
本発明の効果は、ネットワーク監視装置の複数冗長化により、ネットワーク装置からの障害発生をより正確に受信しつつ、監視対象からの標準化されているプロトコルのみで、ネットワーク監視装置を運用系と非運用系とに意味分けし、非運用側で抜け漏れを確認することで瞬時的な障害発生時でも円滑に処理ができるようにしたことである。
【００８１】
換言すると、第１の効果は、ネットワーク装置、ネットワーク中継装置は、負荷を軽減するべく非再送なプロトコルを用いてネットワーク監視装置に障害通知を送信する。障害通知はＲＦＣ１２１５などの標準メッセージが決められており、非再送なプロトコル以外をネットワーク監視装置が選択することはできない。非再送なプロトコルを用いた通信は、ネットワークの負荷／通路状態等により通信が喪失する場合がある。このような背景のもと、本発明では喪失に対する冗長化の高度化について対応している。
【００８２】
第２の効果は、ネットワーク監視装置と監視対象装置との間で間欠的な障害通知の抜けがあった場合に、単位時間当たりの障害通知抜けを計測して運用系／非運用系の切り替えを行なう機能を有する点である。本発明では、主に瞬時的な障害通知抜けの救済について扱っている。
【００８３】
本発明は、ＲＦＣ１２１５などの標準メッセージをＳＮＭＰ非再送なプロトコルを用いて、ネットワーク装置、ネットワーク中継装置を監視するネットワーク監視装置で、障害通知の喪失を防ぐため冗長化を行い、かつ、運用系、非運用系に分けて運用する場合に、運用系で瞬時的に喪失し非運用系で喪失しなかった障害通知を非運用系側で復元させる手法に関する。
【００８４】
上記の実施形態の一部又は全部は以下の付記のようにも記載され得るが、本発明は以下の構成に限定されるものではない。
【００８５】
［付記１］（図１〜図４）
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続され、
前記監視対象装置は、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信し、
前記運用系のネットワーク監視装置は、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信し、
前記非運用系のネットワーク監視装置は、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定し、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する、
ネットワーク監視システム。
【００８６】
［付記２］（図１〜図４）
前記非運用系のネットワーク監視装置は、新たな障害通知を受信したときに、その前の障害通知を前記判定の対象とする、
付記１記載のネットワーク監視システム。
【００８７】
［付記３］（図１〜図４）
前記非運用系のネットワーク監視装置は、前記障害通知を受信してから一定時間経過したときに、当該障害通知を前記判定の対象とする、
付記１記載のネットワーク監視システム。
【００８８】
［付記４］（図５）
前記非運用系のネットワーク監視装置は、前記データ保存装置へ前記障害通知の内容を登録した後、当該障害通知の内容を前記データ保存装置に問い合わる、
付記１乃至３のいずれか一つに記載のネットワーク監視システム。
【００８９】
［付記５］（図６）
前記非運用系のネットワーク監視装置は、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録することに代えて、前記運用系のネットワーク監視装置へ当該障害通知の喪失があった旨の報告をし、
前記運用系のネットワーク監視装置は、前記障害通知の喪失があった旨の報告を受けると、前記データ保存装置へ当該障害通知の内容を登録する、
付記１乃至４のいずれか一つに記載のネットワーク監視システム。
【００９０】
［付記６］（図７〜図１０）
前記監視対象装置、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置の少なくとも一つが複数台設けられた、
付記１乃至５のいずれか一つに記載のネットワーク監視システム。
【００９１】
［付記７］（図１１）
前記運用系のネットワーク監視装置は、前記監視対象装置から新たな障害通知を一定時間以上受信できない場合に、新たな障害通知を受信しているか否かを前記非運用系のネットワーク監視装置に問い合わせ、当該非運用系のネットワーク監視装置から新たな障害通知を受信している旨の返答を受けた場合は、当該新たな障害通知を前記データ保存装置へ登録する、
付記１乃至６のいずれか一つに記載のネットワーク監視システム。
【００９２】
［付記８］（図１２）
前記非運用系のネットワーク監視装置は、前記監視対象装置のみから受信した場合は、前記監視対象装置に対して当該障害通知の送信の有無を確認し、当該障害通知の送信があったときは、当該障害通知の喪失があったと判断する、
付記１乃至７のいずれか一つに記載のネットワーク監視システム。
【００９３】
［付記９］（図１〜図４、方法）
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続されたネットワーク監視システムに用いられるネットワーク監視方法であって、
前記監視対象装置が、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信する工程と、
前記運用系のネットワーク監視装置が、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信する工程と、
前記非運用系のネットワーク監視装置が、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定し、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する工程と、
を含むネットワーク監視方法。
【００９４】
［付記１０］（図１〜図４、プログラム）
監視対象装置、運用系のネットワーク監視装置、非運用系のネットワーク監視装置及びデータ保存装置がネットワークによって通信可能に接続され、
前記監視対象装置が、障害を発生するとその内容を障害通知として、前記運用系のネットワーク監視装置及び前記非運用系のネットワーク監視装置へ送信し、
前記運用系のネットワーク監視装置が、前記監視対象装置から前記障害通知を受信すると、前記データ保存装置へ当該障害通知の内容を登録するとともに、前記非運用系のネットワーク監視装置へ当該障害通知を送信する、ネットワーク監視システム、
に用いられるネットワーク監視プログラムであって
前記非運用系のネットワーク監視装置に含まれるコンピュータに、前記監視対象装置及び前記運用系のネットワーク監視装置の両方から同じ前記障害通知を受信している否かを判定する処理と、前記両方から受信している場合又は前記運用系のネットワーク監視装置のみから受信している場合は何も実行せず、前記監視対象装置のみから受信した場合は前記データ保存装置へ当該障害通知の内容を登録する処理と、
を実行させるためのネットワーク監視プログラム。
【産業上の利用可能性】
【００９５】
本発明は、回線の状況や光レベルや電気レベルの劣化状態などのネットワーク状況、使用メモリ、ＣＰＵ処理負荷状況、消費電力、装置温度、ファン状態など装置状態を監視できる、ネットワーク監視システム分野への利用が考えられる。
【符号の説明】
【００９６】
１  データ保存装置
２  ネットワーク
３  ネットワーク監視装置
４  ネットワーク監視装置
５  ネットワーク
６  ネットワーク
７  監視対象装置
【図１】
2014179674.tif 000003
【図２】
2014179674.tif 000004
【図３】
2014179674.tif 000005
【図４】
2014179674.tif 000006
【図５】
2014179674.tif 000007
【図６】
2014179674.tif 000008
【図７】
2014179674.tif 000009
【図８】
2014179674.tif 000010
【図９】
2014179674.tif 000011
【図１０】
2014179674.tif 000012
【図１１】
2014179674.tif 000013
【図１２】
2014179674.tif 000014