(57)【要約】【課題】ネットワークの障害原因の解析時間を短縮する。【解決手段】ネットワーク機器の監視装置が有するコンピュータに、監視対象の状態を示す情報の要求と前記状態の変化時刻の要求とを含む問い合わせメッセージを前記ネットワーク機器へ送信する処理と、前記状態を示す情報と前記状態の変化時刻とを含む応答メッセージを前記ネットワーク機器から受信する処理とを実行させるプログラムである。【選択図】図８
2017126817.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク機器の監視装置が有するコンピュータに、
監視対象の状態を示す情報の要求と前記状態の変化時刻の要求とを含む問い合わせメッセージを前記ネットワーク機器へ送信する処理と、
前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記ネットワーク機器から受信する処理と
を実行させるプログラム。
【請求項２】
前記問い合わせメッセージを送信する処理において、前記状態を示す情報の要求と前記状態の変化時刻の要求を示す第１の識別子とを含む問い合わせメッセージを送信する
請求項１に記載のプログラム。
【請求項３】
前記問い合わせメッセージを送信する処理において、前記問い合わせメッセージとして、前記第１の識別子を含むＳＮＭＰのGetRequestメッセージを送信し、
前記応答メッセージを受信するステップにおいて、前記応答メッセージとして、前記状態の変化時刻と前記状態の変化時刻の含有を示す第２の識別子とを含むＳＮＭＰのGetResponseメッセージを受信する
請求項２に記載のプログラム。
【請求項４】
ネットワーク機器が有するコンピュータに、
監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求とを含む問い合わせメッセージを前記ネットワーク機器の監視装置から受信した場合に、記憶部に記憶された前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記監視装置へ送信する
処理を実行させるプログラム。
【請求項５】
前記問い合わせメッセージが前記監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求を示す第１の識別子を含む場合に、前記応答メッセージを生成する処理を前記コンピュータに実行させる
請求項４に記載のプログラム。
【請求項６】
前記監視装置から受信されたＳＮＭＰのGet Requestメッセージが前記第１の識別子を
含む場合に、前記応答メッセージを生成する処理において、前記GetRequestメッセージで指定された状態と当該状態の変化時刻とを含むＳＮＭＰのGetResponseメッセージを生成
する処理を前記コンピュータに実行させる
請求項５に記載のプログラム。
【請求項７】
ネットワーク機器の監視装置であって、
監視対象の状態を示す情報の要求と前記状態の変化時刻の要求とを含む問い合わせメッセージを前記ネットワーク機器へ送信する送信部と、
前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記ネットワーク機器から受信する受信部と
を含む監視装置。
【請求項８】
監視装置によって監視されるネットワーク機器であって、
監視対象の状態を示す情報と、前記監視対象の状態の変化時刻とを記憶する記憶部と、
前記監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求とを含む問い合わせメッセージが前記ネットワーク機器の監視装置から受信された場合に、前記記憶部に記憶された前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含
む応答メッセージを前記監視装置へ送信する制御部と
を含むネットワーク機器。
【請求項９】
監視装置の情報取得方法であって、
前記監視装置が、
監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求とを含む問い合わせメッセージをネットワーク機器へ送信し、
前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記ネットワーク機器から受信する
ことを含む監視装置の情報取得方法。
【請求項１０】
ネットワーク機器の情報提供方法であって、
前記ネットワーク機器が、
監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求とを含む問い合わせメッセージが前記ネットワーク機器の監視装置から受信された場合に、記憶部に記憶された前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記監視装置へ送信する
ことを含むネットワーク機器の情報提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム，監視装置，ネットワーク機器，監視装置の情報取得方法，及びネットワーク機器の情報提供方法に関する。
【背景技術】
【０００２】
Simple Network Management Protocol（ＳＮＭＰ）は、ネットワーク機器をネットワーク経由で監視及び制御するためのプロトコルである。ＳＮＭＰでは、ネットワーク機器を監視する監視装置が「ＳＮＭＰマネージャ」と呼ばれ、ＳＮＭＰマネージャの監視下に置かれるネットワーク機器が「ＳＮＭＰエージェント」と呼ばれる。
【０００３】
ＳＮＭＰでは、ＳＮＭＰマネージャとＳＮＭＰエージェントとの通信によって、監視及び制御が行われる。ＳＮＭＰエージェントは、監視対象（装置やソフトウェアなど）の状態を示す情報を、Management Information Base（ＭＩＢ：管理情報ベース）と呼ばれる
公開用の情報で管理している。
【０００４】
ＳＮＭＰマネージャは、ＭＩＢの情報（監視対象の状態を示す情報：「状態情報」とも表記）をＳＮＭＰエージェントから受信し、受信した状態情報（ＭＩＢの情報）をデータベースＤＢで管理する。ＳＮＭＰマネージャは、受信された状態情報が、以前に受信したＤＢ中の状態情報と不一致の場合に、状態の変化を知ることができる。
【０００５】
ＳＮＭＰマネージャがＭＩＢの情報をＳＮＭＰエージェントから取得する方法には、トラップとポーリングとがある。トラップは、ＳＮＭＰエージェントが監視対象の状態の変化を示すメッセージ（「ＳＮＭＰトラップ」と呼ばれる）を能動的に生成し、ＳＮＭＰマネージャに送信する方法である。ＳＮＭＰマネージャは、ＳＮＭＰトラップに含まれた状態情報を取得することで、状態変化を知り得る。
【０００６】
ポーリングは、ＳＮＭＰマネージャがＳＮＭＰエージェントに監視対象の指定を含む問い合わせを行い、ＳＮＭＰエージェントが監視対象の状態情報を含む応答をＳＮＭＰマネージャに送信する方法である。ＳＮＭＰマネージャは、応答に含まれた状態情報を取得することで、状態変化を知り得る。
【０００７】
ＳＮＭＰマネージャは、トラップを用いて状態情報を入手することができる。但し、ＳＮＭＰトラップは、再送制御のないUser Datagram Protocol（ＵＤＰ）で送信される。このため、ＳＮＭＰトラップがマネージャに到達することなくロストすると、ＳＮＭＰマネージャは状態変化を知ることができない。このような問題を回避するために、例えば、定周期でのポーリングが併用され、ＳＮＭＰトラップがロストしても、ポーリングの応答で状態変化を知ることができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００１−２４６３５号公報
【特許文献２】特開２００４−２３５７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ネットワークで障害が発生した場合、障害の原因の特定に、ＳＮＭＰマネージャで保管
された状態の変化が使用される場合がある。例えば、回線の切断によって、ＳＮＭＰエージェントが管理している監視対象の状態が変化した場合、ＳＮＭＰエージェントは、変化後の状態を示す情報と、トラップの発生時刻とを含むＳＮＭＰトラップをＳＮＭＰマネージャに送る。ＳＮＭＰトラップを受信したＳＮＭＰマネージャは、状態を示す情報ともに、トラップの生成時刻を、「状態変化の発生時刻」として保管する。このような、「状態変化の発生時刻」が、ＳＮＭＰエージェントで保管されているシステムの動作状況やメッセージなどの記録（ログ、syslogと呼ばれる）からの情報（ログ）の抽出範囲の画定に使用される。
【００１０】
例えば、「状態変化の発生時刻」がトラップの発生時刻である場合、トラップの発生時刻は回線の切断の時点から離れていない。このため、例えば、「状態変化の発生時刻」から或る時間遡った時間帯をsyslogからの抽出範囲と定め、抽出したログを解析すれば、障害の原因となったログを見つけることができると考えられる（但し、ログを更に遡る場合もあり得る）。
【００１１】
ところが、ＳＮＭＰエージェントは、状態変化の発生時刻や、トラップの発生時刻を保管しない。また、ポーリングにおける応答メッセージには、状態変化の発生時刻は含まれない（状態情報が状態変化の発生時刻を示す情報を含まない）。このため、ＳＮＭＰマネージャは、応答メッセージから状態情報を取得した時刻（取得時刻と呼ぶ）を「状態変化の発生時刻」として管理する。
【００１２】
取得時刻は、ＳＮＭＰトラップにおける状態変化の発生時刻よりも遅れている（回線切断時点から遠い）。このため、上記した或る時間遡った時間帯のログを解析しても、障害の原因を発見できない可能性が少なくない。これより、ＳＮＭＰマネージャは、例えば、「状態変化の発生時刻」からポーリングの周期（或る時間より長い）を遡った時間帯のログ情報をＳＮＭＰエージェントから入手し、ログ解析を行う（さらに、時間を遡ったログ解析がなされる場合もあり得る）。この結果、ネットワークの障害の原因の解析に時間がかかることがあった。
【００１３】
一つの側面では、本発明は、ネットワークの障害原因の解析時間を短縮し得る技術を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の一態様は、ネットワーク機器の監視装置が有するコンピュータに、監視対象の状態を示す情報の要求と前記監視対象の状態の変化時刻の要求とを含む問い合わせメッセージを前記ネットワーク機器へ送信する処理と、前記監視対象の状態を示す情報と前記監視対象の状態の変化時刻とを含む応答メッセージを前記ネットワーク機器から受信する処理とを実行させるプログラムである。
【発明の効果】
【００１５】
本発明によれば、ネットワークの障害原因の解析時間を短縮し得る。
【図面の簡単な説明】
【００１６】
【図１】図１は、実施形態に係るネットワーク構成例を示す。
【図２】図２は、マネージャ１として動作可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。
【図３】図３は、プログラムの実行によって得られる情報処理装置（ＣＰＵ）の機能を模式的に示す図である。
【図４】図４は、エージェントとして動作可能なネットワーク機器のハードウェア構成例を示す図である。
【図５】図５は、プログラムの実行によって得られるネットワーク機器（ＣＰＵ）の機能を模式的に示す図である。
【図６】図６は、監視用テーブルのデータ構造例を示す。
【図７】図７は、ＭＩＢ−ＤＢの一例を示す。
【図８】図８は、ネットワーク監視システムの動作例を示す。
【図９】図９は、ＳＮＭＰトラップの生成処理の一例を示すフローチャートである。
【図１０】図１０は、ＳＮＭＰトラップのフォーマットを示す。
【図１１】図１１は、フラグ付きGetRequest生成に係る処理例を示すフローチャートである。
【図１２】図１２は、ポーリング時の問い合わせメッセージとして使用されるフラグ付きGetRequestのフォーマット例を示す。
【図１３】図１３は、フラグ付きGetRequestの受信時の処理例を示すフローチャートである。
【図１４】図１４は、時刻付きGetResponseのフォーマット例を示す。
【図１５】図１５は、GetResponseの受信処理の例を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、図面を参照して実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。
【００１８】
図１は、実施形態に係るネットワーク構成例を示す。図１には、ネットワーク機器の監視システムの一例として、ＳＮＭＰを用いた監視システムの例が図示されている。監視システムは、ＳＮＭＰマネージャ１（以下、単に「マネージャ１」と表記）と、ＳＮＭＰエージェント２（以下、単に「エージェント２」と表記）とを含む。マネージャ１は、エージェント２とネットワーク３を介して接続される。
【００１９】
マネージャ１は、エージェント２を監視する監視装置の一例であり、ＳＮＭＰエージェントは、マネージャの監視下に置かれるネットワーク機器である。すなわち、マネージャ１は、「監視装置」の一例であり、エージェント２は、「ネットワーク機器」の一例である。
【００２０】
マネージャ１は、例えば、パーソナルコンピュータ（ＰＣ），ワークステーション（ＷＳ），サーバマシンのような汎用または専用のコンピュータである。一方、エージェント２は、例えば、ルータ，レイヤ３スイッチのような中継装置、及び中継装置以外のコンピュータを含む（マネージャ１として動作し得るコンピュータも含む）。もっとも、ソフトウェア（プログラム）の実行によってＳＮＭＰマネージャ又はＳＮＭＰエージェントとして動作可能なあらゆるコンピュータは、「監視装置」及び「ネットワーク機器」に含まれ得る。
【００２１】
エージェント２は、複数の監視対象の項目に対応する情報であるＭＩＢを管理している。ＭＩＢは、監視対象の項目の現在の状態を示す情報である。ＭＩＢは、「監視対象の状態を示す情報」の一例である。マネージャ１は、トラップ及びポーリングによって、エージェント２から所望のＭＩＢを得ることができる。
【００２２】
＜マネージャの構成＞
図２は、マネージャ１として動作可能な情報処理装置（コンピュータ）のハードウェア構成例を示す。図２において、情報処理装置１０は、バスを介して相互に接続されたCentral Processing Unit（ＣＰＵ：中央演算処理装置）１１，主記憶装置１２，補助記憶装
置１３，ネットワークインタフェース回路（ＮＷ  ＩＦ）１４，入出力装置１５を含んでいる。
【００２３】
主記憶装置１２は、ＣＰＵ１１によって実行されるプログラム及びプログラムの実行に際して使用されるデータの記憶領域，ＣＰＵ１１の作業領域、通信データのバッファ領域などとして使用される。主記憶装置１２は、例えばRandom Access Memory（ＲＡＭ）、又はＲＡＭ及びRead Only Memory（ＲＯＭ）の組み合わせで形成される。
【００２４】
補助記憶装置１３は、プログラム及びデータの記憶領域として使用される。補助記憶装置１３は、例えば、ハードディスクドライブ（ＨＤＤ），Solid State Drive（ＳＳＤ）
，フラッシュメモリ，Electrically Erasable Programmable Read-Only Memory（EEPROM
）などである。補助記憶装置１３は、ディスク記憶媒体を含み得る。
【００２５】
ＮＷ  ＩＦ１４は、通信処理を行うインタフェース回路である。ＮＷ  ＩＦ１４として、例えば、Local Area Network（ＬＡＮ）カード、或いはネットワークインタフェースカード（ＮＩＣ）と呼ばれるカード装置を適用し得る。
【００２６】
入出力装置１５は、入力装置と出力装置とを含む、入力装置は、情報処理装置１０への情報やデータの入力に使用される。入力装置は、キー，ボタン，ポインティングデバイス（マウスなど），タッチパネルなどを含む。入力装置は、マイクロフォンのような音声入力装置を含み得る。出力装置は、情報の出力に使用される。出力装置は、例えば、ディスプレイ，プリンタなどである。出力装置は、スピーカのような音声出力装置を含み得る。
【００２７】
ＣＰＵ１１は、主記憶装置１２及び補助記憶装置１３の少なくとも一方に記憶されたプログラムを実行することによって、マネージャ１として動作する。図３は、プログラムの実行によって得られる情報処理装置１０（ＣＰＵ１１）の機能を模式的に示す図である。
【００２８】
図３において、マネージャ１として動作する情報処理装置１０のＣＰＵ１１は、プログラムの実行によって、送信処理部１０１と、送信部１０２と、受信部１０３と、受信処理部１０４として動作（機能）する。管理情報データベース（管理情報ＤＢ）１０５は、主記憶装置１２及び補助記憶装置１３の少なくとも一方に記憶される。
【００２９】
送信処理部１０１は、ＳＮＭＰメッセージを生成する。ＳＮＭＰメッセージは、例えば、GetRequestである。GetRequest以外に、マネージャ１が生成し得るＳＮＭＰメッセージとしては、GetNextRequest，GetBulkRequestがある。GetRequestは、１又は複数のＭＩＢの指定を含み、指定した各ＭＩＢを得るために使用される。GetNextRequestは、ＭＩＢの指定（１又は複数）を含み、指定したＭＩＢの次のＭＩＢ（１又は複数）を得るために使用される。GetBulkRequestは、１又は複数のＭＩＢの指定と、繰り返し回数とを含み、指定したＭＩＢの次のＭＩＢ（項目）から繰り返し回数個分のＭＩＢを得るために使用される。GetRequest，GetNextRequest，GetBulkRequestのそれぞれは、「問い合わせメッセージ」の一例である。本実施形態では、問い合わせに、状態を示す情報ともに状態が変化した時刻を含んだ応答を送信する要求（「監視対象の状態の変化時刻の要求」の一例）を含むことができる。
【００３０】
送信部１０２は、送信処理部１０１で生成されたＳＮＭＰメッセージ（GetRequestなど）を送信する。なお、送信部１０２が送信するＳＮＭＰメッセージは、必ずしも送信処理部１０１によって生成される必要はなく、送信処理部１０１以外から受け取ったＳＮＭＰメッセージを送信する場合もあり得る。
【００３１】
受信部１０３は、エージェント２から送信されてくるＳＮＭＰメッセージを受信する。受信されるＳＮＭＰメッセージは、例えば、ＳＮＭＰトラップ、GetResponseである。受
信処理部１０４は、受信部１０３でＳＮＭＰメッセージから、ＭＩＢを抽出し、管理情報
ＤＢ１０５に記憶する。受信処理部１０４は、ＳＮＭＰメッセージにＭＩＢの状態が変化した時刻が含まれている場合には、当該時刻も管理情報ＤＢ１０５に記憶する。ＭＩＢの状態が変化した時刻は、「監視対象の状態の変化時刻」の一例である。
【００３２】
＜エージェントの構成例＞
図４は、エージェント２として動作可能なネットワーク機器２０のハードウェア構成例を示す図である。ネットワーク機器２０は、一例として、バスを介して相互に接続された、ＣＰＵ２１と、主記憶装置２２と、補助記憶装置２３と、ネットワークインタフェース回路（ＮＷ  ＩＦ）２４とを含む。主記憶装置２２，補助記憶装置２３，ＮＷ  ＩＦ２４は、主記憶装置１２，補助記憶装置１３，ＮＷ  ＩＦ１４と同様のものを適用可能であるので説明を省略する。
【００３３】
ＣＰＵ２１は、補助記憶装置２３に記憶されたプログラムを主記憶装置２２にロードして実行することによって、エージェント２として動作する。図５は、プログラムの実行によって得られるネットワーク機器２０（ＣＰＵ２１）の機能を模式的に示す図である。
【００３４】
プログラムの実行によって、ネットワーク機器２０のＣＰＵ２１は、一例として、送信部２０１，テーブル生成部２０２，ＳＮＭＰメッセージ生成部２０３，ポーリング受信部２０４，及び受信処理部２０５として動作（機能）することができる。監視用テーブル２０６及びＭＩＢ２０７は、主記憶装置２２及び補助記憶装置２３の少なくとも一方に記憶される。
【００３５】
送信部２０１は、ＳＮＭＰトラップ（ＳＮＭＰ−ＴＲＡＰ）を送信するとともに、トラップの発生時刻をテーブル生成部２０２に送る。テーブル生成部２０２は、トラップの発生時刻を「状態変化の発生時刻」として、監視用テーブル２０６に記憶する。
【００３６】
ポーリング受信部は、マネージャ１から送信された問い合わせメッセージ（GetRequestなど）などメッセージを受信し、受信処理部２０５に渡す。受信処理部２０５は、問い合わせメッセージをＳＮＭＰメッセージ生成部２０３へ渡す。
【００３７】
ＳＮＭＰメッセージ生成部２０３は、問い合わせメッセージを解析し、マネージャ１から要求されたＭＩＢをＭＩＢ２０７から取得する。ＭＩＢ２０７は、ＭＩＢの集合を記憶したデータベースである。また、ＳＮＭＰメッセージ生成部２０３は、ＭＩＢ２０７から取得したＭＩＢに対応する状態変化の発生時刻が監視用テーブル２０６に記憶されていれば、当該時刻を監視用テーブルから取得する。ＳＮＭＰメッセージ生成部２０３は、ＭＩＢ及び状態変化の発生時刻（「監視対象の状態の変化時刻」の一例）を含む応答メッセージ（GetResponse）を生成し、送信部２０１に渡す。送信部２０１は、応答メッセージえ
をマネージャ１へ送信する。
【００３８】
ＣＰＵ１１，ＣＰＵ２１は、「プロセッサ」，「コントローラ」，「制御部」，「コンピュータ」の一例である。主記憶装置１２及び２２，補助記憶装置１３及び２３のそれぞれは、「記憶部」，「メモリ」，「記憶装置」，「記憶媒体」，「コンピュータ読み取り可能な記憶媒体」の一例である。
【００３９】
なお、ＣＰＵ１１，ＣＰＵ２１は、ＭＰＵ（Microprocessor）、プロセッサとも呼ばれる。ＣＰＵは、単一のプロセッサに限定される訳ではなく、マルチプロセッサ構成であってもよい。また、単一のソケットで接続される単一のＣＰＵがマルチコア構成を有していても良い。
【００４０】
ＣＰＵ１１，ＣＰＵ２１によって行われる少なくとも一部の処理は、ＣＰＵ以外のプロ
セッサ、例えば、Digital Signal Processor(DSP)、Graphics Processing Unit（GPU）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われても良い。また、上記各部の少なくとも一部の処理は、集積回路（ＩＣ）、その他のディジタル回路であっても良い。また、上記各部の少なくとも一部にアナログ回路が含まれても良い。
【００４１】
集積回路は、ＬＳＩ，Application Specific Integrated Circuit（ASIC），プログラ
マブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(FPGA)を含む。上記各部は、プロセッサと集積回路との組み合わせであっても良
い。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ），ＳｏＣ（System-on-a-chip）チップ，システムＬＳＩ，チップセットなどと呼ばれる。
【００４２】
＜監視用テーブル、ＭＩＢ＞
図６は、監視用テーブル２０６のデータ構造例を示す。監視用テーブル２０６は、オブジェクトＩＤ（ＯＩＤ）と、状態変化の発生時刻とを含む１以上のレコードを記憶する。ＯＩＤは、ＭＩＢの識別子である。状態変化の発生時刻として、例えば、トラップの発生時刻が記憶される。但し、ＳＮＭＰトラップの生成とは別に、状態変化が検知され、そのときの時刻が監視用テーブル２０６に記憶されるようにしても良い。
【００４３】
図７は、ＭＩＢ２０７の一例を示す。ＭＩＢ２０７は、ＭＩＢの情報（ＭＩＢオブジェクト）の集合体であり、集合体はツリー構造であらわされる。図７の例では、一部のＭＩＢオブジェクトに係るレコードを抽出した表が例示されている。ＭＩＢ２０７は、各ＭＩＢ（監視対象）の名前と値とを記憶する。名前（識別情報）として、ＯＩＤが使用される。ＯＩＤは、数字及びドット、或いはニーモニック（英文字）で表現される。ＯＩＤに対応する値、「監視対象の状態を示す情報」の一例である。ＯＩＤに対応する値が、ＭＩＢ２０７から読み出される。
【００４４】
＜動作例＞
図８は、ネットワーク監視システムの動作例を示す。図８の動作例は、監視装置の情報取得方法、ネットワーク機器の情報提供方法の一例である。図８において、エージェント２は、ＭＩＢオブジェクトの状態変化を検出すると、ＳＮＭＰトラップの生成を行う（図８＜１＞）。
【００４５】
図９は、ＳＮＭＰトラップの生成処理の一例を示すフローチャートである。図９に示す処理は、例えば、エージェント２（ネットワーク機器２０）の送信部２０１として動作するＣＰＵ２１によって行われる。
【００４６】
図９において、０１では、ＣＰＵ２１は、障害（例えば、回線切断）の発生を検出する。０２では、ＣＰＵ２１は、障害に伴うＭＩＢの情報の状態変化に係る情報を格納する。すなわち、ＣＰＵ２１は、障害に対応するＭＩＢ２０７のＭＩＢオブジェクトの値を、変化後の状態を示す値に更新する。
【００４７】
０３では、ＣＰＵ２１は、ＳＮＭＰトラップを生成する。図１０は、ＳＮＭＰトラップのフォーマットを示す。ＳＮＭＰトラップのメッセージは、ＳＮＭＰバージョン，コミュニティ名，ＴＲＡＰ  ＰＤＵ（Protocol Data Unit）を含む。
【００４８】
ＴＲＡＰ  ＰＤＵは、ＴＲＡＰ，装置ＩＤ，エージェントアドレス，トラップ番号，拡張トラップ番号，発生時刻，関連ＭＩＢ情報を含む。装置ＩＤは、ＯＩＤであり、エージェントアドレスは、トラップが発生した装置（エージェント２）のInternet Protocol（
ＩＰ）アドレスである。トラップ番号は、トラップの種別を示す識別番号であり、拡張ト
ラップ番号は、トラップ番号の補足用の番号である。発生時刻は、トラップが発生した時刻を示す、関連ＭＩＢ情報は、トラップに関連する情報である。
【００４９】
ＣＰＵ１１は、０３において、状態が変化したＭＩＢのＯＩＤを「装置ＩＤ」に設定し、トラップの発生時刻を「発生時刻」に設定し、ＯＩＤに対応するＭＩＢの値（状態）を関連ＭＩＢ情報に設定したＳＮＭＰトラップを生成する。
【００５０】
０４では、ＣＰＵ１１は、ＳＮＭＰトラップ中の装置ＩＤ（ＯＩＤ），エージェントアドレス，トラップ番号，拡張トラップ番号，及び発生時刻を、監視用テーブル２０６に格納する。発生時刻は、「状態変化の発生時刻」として格納される。なお、監視用テーブル２０６には、ＯＩＤ及び発生時刻が少なくとも格納されるようにしても良い。ＯＩＤと発生時刻とで、ＭＩＢの変化時刻を推定できるからである。
【００５１】
０５では、ＣＰＵ２１は、ＳＮＭＰトラップを送信する。このようにして、図８に示すように、ＳＮＭＰトラップがマネージャ１に送信される（図８＜２＞）一方で、状態変化の発生時刻が監視用テーブル２０６に記憶される（図８＜３＞）。
【００５２】
マネージャ１は、一定の周期で、ポーリングを行う。ポーリングを開始する前に、マネージャ１は、状態変化の発生時刻を取得するかの判定を行い（図８＜４＞）、取得する場合に、フラグ付きGetRequestの生成を行う（図８＜５＞）。
【００５３】
図１１は、図８＜４＞，＜５＞に係るマネージャ１の処理例を示すフローチャートである。図１１の処理は、例えば、送信処理部１０１及び送信部１０２として動作するＣＰＵ１１によって実行される。
【００５４】
１０１では、ＣＰＵ１１は、状態変化の発生時刻の取得が必要か否かを判定する。当該判定は、例えば、マネージャ１に対し、入出力装置１５を用いて、状態変化の発生時刻の取得を指示する情報（フラグ）が設定されているか否かを判定することによって行われる。
【００５５】
発生時刻を取得しない場合には、通常のポーリングが行われる（１０４）。これに対し、発生時刻を取得する場合には、ＣＰＵ１１は、ＳＮＭＰメッセージのＯＩＤフィールドに、フラグ「ＦＦ」（「第１の識別子」の一例である）を設定する（１０２）。
【００５６】
図１２は、ポーリング時の問い合わせメッセージとして使用されるGetRequestのフォーマット例を示す。ＳＮＭＰメッセージは、ＰＤＵタイプ，リクエストＩＤ，エラーインデックス，オブジェクトデータの共通フォーマットを有する。
【００５７】
ＰＤＵタイプフィールドに、メッセージタイプとして、“GetRequest”を示す情報が設定されることで、エージェント２にて、ＳＮＭＰメッセージがGetRequestとして扱われる。オブジェクトデータのフィールドには、複数のＯＩＤの指定を含めることができる。図１２の例では、３つのＭＩＢ（ＯＩＤ１，ＯＩＤ２，ＯＩＤ３）の名前“Ａ”，“Ｂ”，“Ｃ”が設定されている。
【００５８】
さらに、ＯＩＤ１＝“Ａ”に係る空き領域に、特殊フラグ“ＦＦ”が設定されている。フラグ“ＦＦ”は、「監視状態の状態の変化時刻の要求」、「第１の識別子」の一例である。すなわち、ＯＩＤ１＝“Ａ”について、状態変化の発生時刻が要求されている。なお、エージェント２で識別し得る限り、フラグの値は“ＦＦ”以外の値を適用できる。このように、フラグを設定するか否かは、ＯＩＤ（ＭＩＢオブジェクト）毎に行うことができる。
【００５９】
なお、通常のポーリングとは、フラグ“ＦＦ”が設定されないGetRequestの送信を意味する。このようにして、図８に示すように、フラグ付きGetRequestが送信される（図８＜６＞）。
【００６０】
エージェント２は、フラグ付きGetRequestを受信すると、図１３に示す処理を行う。図１３は、フラグ付きGetRequestの受信時の処理例を示すフローチャートである。図１３の処理は、例えば、ＣＰＵ２１によって行われる。
【００６１】
図１３において、GetRequestが受信されると（２０１）、ＣＰＵ２１は、状態変化の発生時刻の送信が必要か否かを判定する。当該判定は、GetRequestにフラグ“ＦＦ”が付与されているか否かによって行われる。送信が不要である場合、通常のGetResponseが生成
される。
【００６２】
送信が必要である場合、時刻付きGetResponseが生成される（２０３）。図１４は、時
刻付きGetResponseのフォーマット例を示す。図１４に示すように、フォーマットは、GetRequestと同じフォーマットを有し、ＰＤＵタイプに“GetResponse”を示す情報が設定されることで、当該ＳＮＭＰメッセージはマネージャ１にてGetResponseと扱われる。
【００６３】
図１４に示すように、GetResponseでは、オブジェクトデータのＯＩＤに対応するフィ
ールドに、ＯＩＤ１の名前“Ａ”と、名前“Ａ”に対応する値“１”が設定される。値“１”は、「監視対象の状態を示す情報」の一例である。この値の直後に、特別な識別子（特殊文字）“＠＠”が設定される。続いて、監視用テーブル２０６に格納されていた状態変化の発生時刻が書き込まれる。特別な識別子“＠＠”は、「監視対象の状態の変化時刻の含有を示す第２の識別子」の一例である。但し、マネージャ１が認識し得る限り、“＠＠”以外の識別子が使用されても良い。
【００６４】
２０３で、ＣＰＵ２１は、各ＯＩＤ（図１４のＯＩＤ１〜３）に対応するＭＩＢの値をＭＩＢ２０７から得て、ＳＮＭＰフォーマットの所定位置にセットする。２０４では、ＣＰＵ２１は、フラグＦＦがセットされていたＯＩＤ（ＯＩＤ１）で監視用テーブル２０６を検索し、ＯＩＤ１に対応づけて記憶されている「状態変化の発生時刻」を読み出し、識別子“＠＠”とともにＯＩＤ１のＭＩＢの値の後ろに書き込む。すなわち、ＯＩＤに対応する値を格納するフィールドでは、ＯＩＤに対応する値と、発生時刻とが識別子“＠＠”を挟んで並べられた状態となっている。
【００６５】
２０５では、ＣＰＵ２１は、時刻付きGetResponseをマネージャ１へ送信する。このよ
うにして、図８に示すように、時刻付きGetResponseが生成され（図８＜７＞）、マネー
ジャ１へ送信される（図８＜８＞）。
【００６６】
マネージャ１では、GetResponseの受信処理が行われる（図８＜９＞）。図１５は、GetResponseの受信処理の例を示すフローチャートである。図１５の処理は、例えば、ＣＰＵ１１によって行われる。
【００６７】
１５１では、ＣＰＵ１１は、GetResponseから取得される情報と前回取得された情報と
を比較し、両者に差異があるか否かを判定する。例えば、１５１の処理は、前回取得された情報と同じビット数又は文字数の情報を、ＯＩＤ１の値が格納されたフィールドから読み出し、両者（両ビット列又は文字列）が一致するか否かを判定することで行われる。時刻が付与されている場合、ビット長が長く（文字数が多くなる）なるので、前回の取得情報と不一致と判定されるのを回避するためである。
【００６８】
１５２では、ＣＰＵ１１は、識別子“＠＠”が検出できるか否かを判定する。識別子“＠＠”が、１５１で比較に用いたビット列（文字列）の末尾に連続しているか否かを判定する。識別子が検出できない場合は、処理が１５４に進み、識別子が検出された場合は、処理が１５３に進む。
【００６９】
なお、１５１及び１５２の処理は、以下のようにしても良い。すなわち、ＣＰＵ１１は、最初に、ＯＩＤに対応する値（ビット列又は文字列）が識別子“＠＠”のビット列又は文字列を含むかどうかを判定する。ビット列又は文字列が含まれる場合、ＣＰＵ１１は、識別子“＠＠”より前にあるビット列又は文字列と、前回の取得情報に相当するビット列又は文字列とが一致するか否かを判定する。ビット列又は文字列が一致する場合、ＣＰＵ１１は、処理を１５４に進め、一致しない場合、処理を１５３に進める。
【００７０】
１５３では、ＣＰＵ１１は、識別子“＠＠”に後続するビット列又は文字列を、状態変化の発生時刻として抽出する。１５１又は１５２を経て１５４の処理が行われる場合、ＣＰＵ１１は、取得情報（ＭＩＢ）を、管理情報ＤＢ１０５に記憶する。１５２で識別子“＠＠”が発見されずに１５４の処理が行われる場合は、通常のGetResponseに対する処理
である。
【００７１】
これに対し、１５３を経て１５４の処理が行われる場合は、ＣＰＵ１１は、取得情報（ＭＩＢ）とともに「状態変化の発生時刻」を管理情報ＤＢ１０５に記憶する。このような管理情報ＤＢ１０５の記憶内容、状態変化の発生時刻は、障害原因の特定時において、エージェント２が保有又は管理するsyslogからログを抽出する時間帯を決定するために使用される。
【００７２】
なお、GetNextRequest及びGetBalkRequestについての具体例は省略するが、これらの問い合わせメッセージについて、図１３に示した受信処理を適用し得る。すなわち、GetNextRequest及びGetBalkRequestで指定されたＭＩＢから特定されるＭＩＢ（ＯＩＤに対応する値）がＭＩＢ２０７から読み出される。また、ＯＩＤに対応する状態変化の発生時刻が監視用テーブル２０６から読み出される。そして、これらを含んだGetResponse（図１４
）が生成され、マネージャ１に送信される。これらの点は、GetRequestの場合と同じである。換言すれば、GetNextRequest及びGetBalkRequestは、取得を所望するＭＩＢの指定方法がGetRequestと異なるだけで、それ以外については、図８以降に説明した動作例に係る構成を適用可能である。
【００７３】
＜実施形態の作用効果＞
実施形態では、マネージャ１として動作する情報処理装置１０（「監視装置」の一例）のＣＰＵ１１（「監視装置のコンピュータ」の一例）が、プログラムの実行によって以下の処理を行う。すなわち、ＣＰＵ１１は、エージェント２として動作するネットワーク機器２０に、GetRequest（「問い合わせメッセージ」の一例）を送信する処理を実行する。GetRequestは、マネージャ１が取得を要求するＭＩＢのＯＩＤの指定（「監視対象の状態を示す情報の要求」の一例）と、フラグ“ＦＦ”（「状態の変化時刻の要求」，「第１の識別子」）とを含む。また、ＣＰＵ１１は、ＭＩＢ（「監視対象の状態を示す情報」の一例）と、状態変化の発生時刻（「監視対象の状態の変化時刻」の一例）とを含むGetResponse（「応答メッセージ」の一例）をネットワーク機器２０（エージェント２）から受信
する処理を実行する。
【００７４】
これによって、マネージャ１は、状態を示す情報と、その状態の変化の発生時刻とを記憶して管理しておき、状態変化の発生時刻を、syslogのようなログから所定時間帯のログを抽出する場合の目安として用いることができる。状態変化の発生時刻は、先に説明したような、GetResponseからＭＩＢを取得した時刻よりも障害原因の発生時刻に近いため、
抽出するログの時間帯（時間範囲）を小さくすることができる。換言すれば、障害の原因を示すログが含まれている範囲の絞り込みが容易となる。これによって、ネットワークの障害の原因の解析に要する時間を短縮することができる。ひいては、障害の原因特定に要する時間が短縮されることで、復旧に要する時間も短縮し得る。
【００７５】
本実施形態では、GetRequestを送信するステップ（「問い合わせメッセージを送信するステップ」の一例）において、ＭＩＢの指定に係る情報と、フラグ“ＦＦ”（「前記監視対象の状態の変化時刻の要求を示す第１の識別子」の一例）とを含むGetResponseを送信
する。このように、フラグの設定によって、エージェント２は、容易に、状態変化の発生時刻が要求されているかどうかを判定することができる。
【００７６】
本実施形態では、問い合わせメッセージとして、フラグを含むＳＮＭＰのGetRequestメッセージを送信し、識別子“＠＠”（「監視対象の状態の変化時刻の含有を示す第２の識別子」の一例）及び状態変化の発生時刻を含むＳＮＭＰのGetResponseを受信する。この
ようにして、ＳＮＭＰに対する小規模な改良で、ポーリングにおいても、状態変化の発生時刻をエージェントから得ることができ、ＳＮＭＰトラップがロストした場合に備えることができる。以上説明した実施形態の構成は、適宜組み合わせることができる。
【符号の説明】
【００７７】
１・・・ＳＮＭＰマネージャ
２・・・ＳＮＭＰエージェント
１０・・・情報処理装置（監視装置）
１１，２１・・・ＣＰＵ
１２，２２・・・主記憶装置
１３，２３・・・補助記憶装置
１４，２４・・・ネットワークインタフェース回路
【図１】
2017126817.tif 000003
【図２】
2017126817.tif 000004
【図３】
2017126817.tif 000005
【図４】
2017126817.tif 000006
【図５】
2017126817.tif 000007
【図６】
2017126817.tif 000008
【図７】
2017126817.tif 000009
【図８】
2017126817.tif 000010
【図９】
2017126817.tif 000011
【図１０】
2017126817.tif 000012
【図１１】
2017126817.tif 000013
【図１２】
2017126817.tif 000014
【図１３】
2017126817.tif 000015
【図１４】
2017126817.tif 000016
【図１５】
2017126817.tif 000017