JP5240013B2 - ネットワーク装置、ネットワーク装置の制御方法、及びプログラム - Google Patents

Description

本発明は、ネットワークを介して管理端末に状態変化イベントの発生を通知するネットワーク装置に関する。

ネットワーク装置の管理を行うためのプロトコルとして、ＳＮＭＰ（Simple Network Management Protocol）が知られている。ＳＮＭＰエージェント機能を有するネットワーク装置は、所定の状態変化を検知した場合に、ＳＮＭＰマネージャ機能を有する管理端末に状態変化の発生を通知するために"ｔｒａｐ"を送信する。

特許文献１は、ＳＮＭＰを用いた装置管理システムの改良について開示している。具体的に述べると、特許文献１に開示されたネットワーク装置は、単位時間当たりのｔｒａｐ送信数が閾値を超えた場合に、閾値を超過したｔｒａｐ（超過ｔｒａｐ）を解析し、超過ｔｒａｐが属する監視項目グループ（例えば、システム故障、インタフェース故障など）を判定する。さらに、ネットワーク装置は、監視項目グループに対応したグループ番号とグループ内での通し番号を超過ｔｒａｐに付与した後に、これらをＳＮＭＰマネージャに送信する。

また、特許文献１に開示されたネットワーク装置は、送信済みのｔｒａｐを記録しておく。ここで、各ｔｒａｐには送信順にシーケンス番号が付与されている。ＳＮＭＰマネージャは、一連の受信済みｔｒａｐの中にシーケンス番号の飛び（抜け落ち）があった場合、抜け落ちたｔｒａｐの再送信をネットワーク装置に要求する。再送信の要求には、ＳＮＭＰのｓｅｔリクエストを使用する。再送信を要求されたネットワーク装置は、未到達のｔｒａｐを再送信する。このとき、未到達のｔｒａｐが複数ある場合、これらのｔｒａｐを再編集して１つのｔｒａｐとしてＳＮＭＰマネージャに送信する。

また、特許文献１に開示されたＳＮＭＰマネージャは、シーケンス番号の飛び（抜け落ち）が検知されなかった場合にも、受信済みｔｒａｐの最終シーケンス番号をネットワーク装置に送信する。ネットワーク装置は、ＳＮＭＰマネージャから受信した最終シーケンス番号を送信済みｔｒａｐのシーケンス番号と照合することによって、ＳＮＭＰマネージャに未到達のｔｒａｐの有無を判定する。未到達のｔｒａｐを検出した場合、ネットワーク装置は、これらのｔｒａｐをＳＮＭＰマネージャに再送信する。

特開２００８−１９８０４１号公報

特許文献１のネットワーク装置は、単位時間当たりのｔｒａｐ送信数が閾値を超えた場合にも、閾値を超えた各ｔｒａｐの送信を継続して行う。このため、特許文献１に開示されたＳＮＭＰ監視システムは、ネットワーク装置から送信される大量のｔｒａｐによって、ネットワーク装置及び管理端末の間でｔｒａｐを転送するネットワーク（ブリッジ、ルータ等の中継装置、通信回線など）の負荷が増大するという問題がある。また、ネットワーク装置におけるｔｒａｐ送信処理および管理端末におけるｔｒａｐ受信処理の負荷も増大する。このため、ネットワーク装置におけるｔｒａｐ送信以外の他の処理に関する処理性能の低下、管理端末におけるｔｒａｐ受信以外の他の処理に関する処理性能の低下を招くおそれがある。

本発明は、上記の問題点を考慮してなされたものであり、ネットワーク装置から大量のイベント通知メッセージ（例えばｔｒａｐ）が短期間に集中して送信されることに起因する、送信元のネットワーク装置、イベント通知メッセージを中継するネットワーク、及びイベント通知メッセージを受信する管理端末の負荷増大を抑制可能なネットワーク装置、ネットワーク装置の制御方法、及びプログラムの提供を目的とする。

本発明の第１の態様は、ネットワーク装置である。当該ネットワーク装置は、イベントの発生に応じて生成されるイベント通知メッセージを、ネットワークを介して管理端末に向けて送信するよう構成されている。さらに、当該ネットワーク装置は、複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信を抑止するよう構成されている。

本発明の第２の態様は、ネットワーク装置の制御方法である。当該方法は、以下のステップ（ａ）及び（ｂ）を含む。
（ａ）イベントの発生に応じて生成されるイベント通知メッセージを、ネットワークを介して管理端末に向けて送信すること、及び
（ｂ）複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信を抑止すること。

本発明の第３の態様は、ネットワーク装置の制御処理をコンピュータに実行させるためのプログラムである。当該プログラムを実行するコンピュータによってもたらされる前記制御処理は、以下のステップ（ａ）及び（ｂ）を含む。
（ａ）イベントの発生に応じて生成されるイベント通知メッセージをネットワークを介して管理端末に向けて送信するための送信指示を生成すること、及び
（ｂ）複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信指示の生成を抑止すること。

上述した本発明の第１〜第３の態様によれば、ネットワーク装置から大量のイベント通知メッセージ（例えばｔｒａｐ）が短期間に集中して送信されることに起因する、送信元のネットワーク装置、イベント通知メッセージを中継するネットワーク、及びイベント通知メッセージを受信する管理端末の負荷増大を抑制可能なネットワーク装置、ネットワーク装置の制御方法、及びプログラムを提供できる。

発明の実施の形態１にかかるネットワーク装置のブロック図である。 発明の実施の形態１にかかるネットワーク装置によるｔｒａｐ送信処理手順を示すフローチャートである。 発明の実施の形態１にかかるネットワーク装置によるｔｒａｐ送信抑止の決定手順を示すフローチャートである。 発明の実施の形態２にかかるネットワーク装置のブロック図である。 設定ファイルの一例を示す図である。 ダイジェストｔｒａｐの一例を示す図である。 発明の実施の形態２にかかるネットワーク装置によるｔｒａｐ送信処理手順を示すフローチャートである。 発明の実施の形態２にかかるネットワーク装置のｔｒａｐ送信に関する状態と状態遷移条件を示すテーブルである。 ｔｒａｐ送信に関する状態遷移の具体例を示す図である。 発明の実施の形態３にかかるネットワーク装置のブロック図である。 ｔｒａｐログファイルの一例を示す図である。 ダイジェストｔｒａｐの一例を示す図である。 発明の実施の形態３にかかるネットワーク装置によるｔｒａｐ送信処理手順を示すフローチャートである。 発明の実施の形態４にかかるネットワーク装置のブロック図である。 ｔｒａｐ送信結果ファイルの一例を示す図である。 ダイジェストｔｒａｐの一例を示す図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜発明の実施の形態１＞
本実施の形態にかかるネットワーク装置１は、ＳＮＭＰエージェント機能を有する。ネットワーク装置１は、ｔｒａｐ送信の対象となるイベント（状態変化、障害通知など）が発生したことに応じて、ＳＮＭＰマネージャ機能を有する管理端末６にｔｒａｐを送信する。以下では、ｔｒａｐ送信の対象となるイベントを"ｔｒａｐ送信イベント"と呼ぶ。

さらに、ネットワーク装置１は、ｔｒａｐ送信イベントの発生量を監視し、ｔｒａｐ送信イベントが集中的に発生した場合にｔｒａｐの送信を抑止する。例えば、ネットワーク装置１は、ｔｒａｐ送信イベントの単位時間当たりの発生数をカウントし、カウント数が予め定められた閾値を超えたことに応じてｔｒａｐの送信を抑止すればよい。ｔｒａｐ送信を抑止する期間は、予め定めた期間としてもよい。また、ネットワーク装置１は、ｔｒａｐ送信イベントの単位時間当たりの発生数が予め定められた解除用の閾値を下回るまで、ｔｒａｐ送信を停止してもよい。

ネットワーク装置１は、ｔｒａｐ送信を抑止期間内において、全てのｔｒａｐの送信を停止してもよいし、規定数以下のｔｒａｐの送信を継続するとともに、規定数を超えるｔｒａｐの送信を停止してもよい。また、ネットワーク装置１は、ｔｒａｐ送信イベントの優先度を識別し、緊急性・重要性の高いｔｒａｐ（例えば重大な障害発生を通知するトラップ）のみを選択的に送信するようにしてもよい。

以下では、ネットワーク装置１の構成及び動作の具体例について説明する。図１は、ネットワーク装置１の構成例を示すブロック図である。図１に示すネットワーク装置１は、ネットワーク（不図示）を介して遠隔に配置された管理端末６にｔｒａｐを送信する。

ｔｒａｐ管理部１１は、ｔｒａｐ送信イベントの通知を受信した場合に、ｔｒａｐ送信通知をｔｒａｐ送信部１２に送る。ｔｒａｐ送信部１２は、ｔｒａｐ送信通知を受信したことに応じて、ＳＮＭＰマネージャ機能を有する管理端末６にｔｒａｐを送信する。ｔｒａｐ受信部６１は、ネットワーク装置１から送信されるｔｒａｐを受信する。

続いて以下では、ネットワーク装置１によるｔｒａｐ送信処理手順とｔｒａｐ送信抑止の決定手順について、図２及び図３のフローチャートを用いて説明する。図２は、ｔｒａｐ管理部１１によるｔｒａｐ送信処理手順の具体例を示すフローチャートである。ｔｒａｐ送信イベントが発生した場合（ステップＳ１０でＹＥＳ）、ｔｒａｐ管理部１１は、現在、ｔｒａｐ送信を抑止中であるか否かを判定する（ステップＳ１１）。ｔｒａｐ送信を抑止中でない場合（Ｓ１１でＮＯ）、ｔｒａｐ管理部１１は、ｔｒａｐ送信部１２にｔｒａｐ送信通知を送る（ステップＳ１２）。一方、ｔｒａｐ送信を抑止している場合（Ｓ１１でＹＥＳ）、ｔｒａｐ管理部１１は、ｔｒａｐ送信通知を生成せずにｔｒａｐ送信を抑止する（ステップＳ１３）。

図３は、ｔｒａｐ管理部１１によるｔｒａｐ送信抑止の決定手順を示すフローチャートである。ｔｒａｐ管理部１１は、定期的に図３に示す手順を実行すればよい。ステップ２０では、ｔｒａｐ管理部１１は、ｔｒａｐ送信イベントの発生履歴を参照し、単位時間当たりのｔｒａｐ送信イベントの発生数"Ｐ"を取得する。ｔｒａｐ送信イベントの発生数Ｐが予め定められた閾値"Ｖ"を超えた場合、（ステップＳ２１でＹＥＳ）、ｔｒａｐ管理部１１は、ｔｒａｐ送信の抑止を決定する（ステップＳ２２）。一方、ｔｒａｐ送信イベントの発生数Ｐが閾値Ｖ未満である場合（Ｓ２１でＮＯ）、ｔｒａｐ管理部１１は、トラップ送信抑止の解除を決定する（ステップＳ２３）。

上述したように、本実施の形態にかかるネットワーク装置１は、複数のｔｒａｐ送信イベントが集中的に発生した場合に、複数のｔｒａｐ送信イベントに対応する複数のｔｒａｐのうち少なくとも一部の送信を抑止する。これにより、ｔｒａｐ送信部１２におけるｔｒａｐ送信処理の負荷、ネットワーク装置１と管理端末６との間のネットワークのデータ転送負荷、および管理端末６におけるｔｒａｐ受信処理の負荷を軽減することができる。

＜発明の実施の形態２＞
本実施の形態にかかるネットワーク装置２は、上述した装置１と同様に、複数のｔｒａｐ送信イベントが集中的に発生した場合に、複数のｔｒａｐ送信イベントに対応する複数のｔｒａｐのうち少なくとも一部の送信を抑止する。さらに、ネットワーク装置２は、ｔｒａｐ送信抑止を行った場合に、ｔｒａｐ送信が抑止されたことを示す抑止通知メッセージを管理端末６に送信する。抑止通知メッセージは、ｔｒａｐとして送信すればよい。このとき、抑止通知メッセージの送信に要する負荷増大を抑えるため、複数のｔｒａｐの送信が抑止されたことを包括的に示すｔｒａｐを送信すればよい。この包括的な通知を含むｔｒａｐを、以下では"ダイジェストｔｒａｐ"と呼ぶ。

続いて、ネットワーク装置２の構成及び動作の具体例について詳細に説明する。図４は、ネットワーク装置２の構成例を示すブロック図である。ｔｒａｐ管理部２１は、装置２内の複数の機能部２３の各々からｔｒａｐ送信イベントの発生通知を受け取る。ｔｒａｐ送信抑止を行っていない場合、ｔｒａｐ管理部２１は、ｔｒａｐ送信イベントの発生通知の受信に応じてｔｒａｐ送信部にｔｒａｐ送信通知を送る。一方、ｔｒａｐ送信抑止を行っている場合、ｔｒａｐ管理部２１は、ｔｒａｐ送信イベントに対応したｔｒａｐを送信するための送信通知の生成を停止する。このとき、ｔｒａｐ管理部２１は、全てのｔｒａｐ送信イベントに関するｔｒａｐ送信を停止してもよいし、規定量以下のｔｒａｐ送信を行いつつ規定量を超えるｔｒａｐ送信を停止してもよい。また、ｔｒａｐ管理部２１は、複数の機能部２３のうち予め定められた一部から通知されるｔｒａｐ送信イベントに関するｔｒａｐのみを選択的に送信するよう、ｔｒａｐ送信部２２に指示してもよい。

また、ｔｒａｐ管理部２１は、ｔｒａｐ送信イベントに対応したｔｒａｐの送信を抑止した場合、ｔｒａｐ送信抑止を行ったことを示すダイジェストｔｒａｐの送信をｔｒａｐ送信部２２に指示する。ダイジェストｔｒａｐは、送信抑止されたｔｒａｐを特定可能な情報を含んでもよい。ダイジェストｔｒａｐによる通知内容の一例を図６に示す。図６のダイジェストｔｒａｐ２２１は、シーケンス番号１００〜２００の合計１０１個のｔｒａｐの送信が停止されたことを示している。

タイマ部２４は、予め定められたタイムアウト時間が経過する度にｔｒａｐ管理部２１にタイムアウト通知を送る。本実施の形態では、タイマ部２４によって計測されるタイムアウト時間は、ｔｒａｐ管理部２１がｔｒａｐ送信を抑止するか否かの決定を行う周期（単位時間）に対応している。ｔｒａｐ管理部２１は、タイムアウト時間毎にｔｒａｐ送信イベントの発生数を集計し、集計した値に基づいてｔｒａｐ送信の抑止を決定する。

設定ファイル２５は、ネットワーク装置２に関する初期設定情報が記録されたファイルである。設定ファイル２５の一例を図５に示す。図５の例の中で、「ｔｒａｐ送信先アドレス」は、ｔｒａｐ送信先のＳＮＭＰマネージャ、つまり管理端末６のＩＰ（Internet Protocol）アドレスである。なお、複数の宛先をｔｒａｐの送信先に設定してもよい。

「抑止設定フラグＦ＿ｓ」は、ネットワーク装置２においてｔｒａｐ送信の抑止動作を行うか否かを示す。当該フラグがＯＦＦの場合、ネットワーク装置２は、ｔｒａｐ送信イベントが集中的に発生してもｔｒａｐ送信抑止を行わない。例えば、フラグＦ＿ｓがＯＦＦである場合、タイマ部２４によるタイムアウト通知の出力を停止すればよい。これにより、ｔｒａｐ管理部２１によるｔｒａｐ抑止判定の実行が行われなくなるため、ｔｒａｐ抑止動作を停止できる。

「ｔｒａｐ送信イベント閾値Ｖ」は、ｔｒａｐ管理部２１が単位時間当たりのｔｒａｐ送信イベントの発生数との比較に使用する閾値である。閾値Ｖの単位は、例えば、単位時間（タイムアウト時間Ｔ）当たりのｔｒａｐ送信イベント発生数として規定すればよい。なお、ｔｒａｐ送信イベントを集計する期間はタイムアウト時間と一致している必要はなく、タイムアウト時間より長い時間又は短い時間で集計してもよい。

「タイムアウト時間Ｔ」は、タイマ部２４がタイムアウト通知を送信する周期を規定する。最後に、「ｔｒａｐ送信抑止期間Ｎ×Ｔ」は、ｔｒａｐ送信イベントの発生頻度が閾値Ｖを超えたことをｔｒａｐ管理部２１が検出した場合に、その後ｔｒａｐ送信抑止を行う時間を規定する。ここで、Ｎは、正の整数である。つまり、図５の例では、ｔｒａｐ送信抑止期間をタイムアウト時間の整数倍としている。

続いて以下では、ネットワーク装置２によるｔｒａｐ送信処理手順とｔｒａｐ送信抑止の決定手順について、図７〜９を用いて説明する。図７は、ｔｒａｐ管理部２１によるｔｒａｐ送信処理手順の具体例を示すフローチャートである。ステップＳ３０では、ｔｒａｐ管理部２１が、イベント通知を受信する。ステップＳ３１及びＳ３２では、ステップＳ３０で受信したイベント通知の種別を判定する。具体的には、受信したイベント通知がタイマ部２４からのタイムアウト通知であった場合（ステップＳ３１でＹＥＳ）、トラップ管理部２１は、タイムアウト処理を行う（ステップＳ３２）。ステップＳ３２におけるタイムアウト処理は、ｔｒａｐ送信イベント数に対する閾値判定結果に基づいてｔｒａｐ送信抑止を決定すること、及びダイジェストｔｒａｐを送信すること、を含む。なお、タイムアウト処理の具体例については後述する。

ステップＳ３０で受信したイベント通知が機能部２３からのｔｒａｐ送信イベントであった場合（ステップＳ３３でＹＥＳ）、トラップ管理部２１は、現在、ｔｒａｐ送信を抑止中であるか否かを判定する（ステップＳ３４）。ｔｒａｐ送信を抑止中でない場合（Ｓ３４でＮＯ）、ｔｒａｐ管理部２１は、ｔｒａｐ送信部２２にｔｒａｐ送信通知を送る（ステップＳ３５）。一方、ｔｒａｐ送信を抑止している場合（Ｓ３４でＹＥＳ）、ｔｒａｐ管理部２１は、ｔｒａｐ送信通知を生成せずにｔｒａｐ送信を抑止する（ステップＳ３５）。

図８は、ステップＳ３２のタイムアウト処理で実行される処理内容の一覧を示すテーブルである。図８の例では、ｔｒａｐ管理部２１は、（i）ｔｒａｐ頻発フラグＦの値、（ii）ｔｒａｐ送信イベント数と閾値Ｖとの大小関係、及び（iii）ｔｒａｐ送信抑止開始からの経過時間に基づいて現在の状態を判定し、判定した状態に対応する予め定められた動作を実行する。ここで、"ｔｒａｐ頻発フラグＦ"は、ｔｒａｐ送信を抑止中であるか否かを示すフラグである。ｔｒａｐ送信が抑止される場合にフラグＦの値がＯＮに設定され、ｔｒａｐ送信抑止が解除される場合にフラグＦの値がＯＦＦに設定される。ｔｒａｐ頻発フラグＦは、ｔｒａｐ送信を抑止中であるか否かの判定（図７のステップＳ３４）において参照される。以下では、図８に示す状態１〜状態８について順に説明する。

（状態１）
ｔｒａｐ頻発フラグＦがＯＮ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ未満、かつ変数ＫがＮ未満である場合、ｔｒａｐ管理部２１は"状態１"であると判定する。ここで、変数Ｋは、ｔｒａｐ抑止期間の満了を判定するために使用される。変数Ｋは、ｔｒａｐ抑止期間に入るときに１にセットされ、タイムアウト時間が経過する度に１ずつカウントアップされる。よって、変数Ｋの値がＮになったときが、ｔｒａｐ抑止期間の満了に相当する。状態１と判定した場合、ｔｒａｐ管理部２１は、ダイジェストｔｒａｐを送信し、頻発フラグＦをＯＦＦとし、変数Ｋの値を０とする。つまり、ｔｒａｐ管理部２１は、状態１と判定した場合に、それまで行われていたｔｒａｐ送信抑止を解除する。

（状態２）
ｔｒａｐ頻発フラグＦがＯＮ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ未満、かつ変数Ｋの値がＮである場合、ｔｒａｐ管理部２１は"状態２"であると判定する。状態２におけるｔｒａｐ管理部２１の処理内容は、上述した状態１と同様である。

（状態３）
ｔｒａｐ頻発フラグＦがＯＮ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ以上、かつ変数ＫがＮ未満である場合、ｔｒａｐ管理部２１は"状態３"であると判定する。状態３と判定したｔｒａｐ管理部２１は、変数Ｋの値を１だけカウントアップし、ｔｒａｐ送信抑止を継続する。

（状態４）
ｔｒａｐ頻発フラグＦがＯＮ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ以上、かつ変数Ｋの値がＮである場合、ｔｒａｐ管理部２１は"状態４"であると判定する。状態４と判定したｔｒａｐ管理部２１は、ダイジェストｔｒａｐを送信し、変数Ｋの値を１にリセットする。つまり、状態４と判定したｔｒａｐ管理部２１は、先のｔｒａｐ抑止期間の満了に伴ってダイジェストｔｒａｐを送信するとともに、新たなｔｒａｐ抑止期間を設定してｔｒａｐ送信抑止を継続する。

（状態５）
ｔｒａｐ頻発フラグＦがＯＦＦ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ未満、かつ変数ＫがＮ未満である場合、ｔｒａｐ管理部２１は"状態５"であると判定する。状態５は、ｔｒａｐ送信抑止が行われておらず、かつ、先のタイムアウト時間内においてｔｒａｐ送信イベントの集中がなかった場合に対応する。よって、状態５と判定したｔｒａｐ管理部２１は、特に何も行わなくてもよい。

（状態６）
ｔｒａｐ頻発フラグＦがＯＦＦ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ未満、かつ変数Ｋの値がＮである場合、ｔｒａｐ管理部２１は"状態６"であると判定する。ただし、状態６は、正常動作時には発生し得ない状態である。よって、ｔｒａｐ管理部２１は、状態６であると判定した場合に、異常回避のための処理、例えば、頻発フラグＦおよび変数Ｋのリセットを行ってもよい。

（状態７）
ｔｒａｐ頻発フラグＦがＯＦＦ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ以上、かつ変数ＫがＮ未満である場合、ｔｒａｐ管理部２１は"状態７"であると判定する。状態７と判定したｔｒａｐ管理部２１は、ｔｒａｐ送信抑止を開始するために、頻発フラグＦをＯＮにセットし、変数Ｋを１だけカウントアップする。

（状態８）
ｔｒａｐ頻発フラグＦがＯＦＦ、単位時間当たりのｔｒａｐ送信イベントＰが閾値Ｖ以上、かつ変数Ｋの値がＮである場合、ｔｒａｐ管理部２１は"状態８"であると判定する。ただし、状態８は、正常動作時には発生し得ない状態である。よって、ｔｒａｐ管理部２１は状態８であると判定した場合に、異常回避のための処理、例えば、頻発フラグＦおよび変数Ｋのリセットを行ってもよい。

図９（ａ）及び（ｂ）は、図８のテーブルに従ったｔｒａｐ管理部２１の動作例を示している。なお、ｔｒａｐ送信抑止期間を規定するＮの設定値は"２"であり、タイムアウト時間Ｔの設定値は１０（秒）とする。図９（ａ）は、０〜９０秒の間の１０秒毎の各タイムアウト期間に発生したｔｒａｐ送信イベント数を表している。図９（ｂ）は、タイムアウト時間の満了時におけるｔｒａｐ管理部２１による状態判定結果と、動作内容をしめす一覧表である。

時刻０における頻発フラグＦの初期値をＯＦＦ、変数Ｋの初期値を０とする。時刻１０秒では、時刻０〜１０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ未満である。このため、ｔｒａｐ管理部２１は、状態５であると判定し、ｔｒａｐ送信抑止・解除に関する動作を行わない。

時刻２０秒では、時刻１０〜２０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ以上である。このため、ｔｒａｐ管理部２１は、状態７であると判定し、ｔｒａｐ送信抑止を開始する。

時刻３０秒では、時刻２０〜３０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が引き続き閾値Ｖ以上である。このため、ｔｒａｐ管理部２１は、状態３であると判定し、ｔｒａｐ送信抑止を継続する。

時刻４０秒では、時刻３０〜４０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ未満である。このため、ｔｒａｐ管理部２１は、状態２であると判定し、ｔｒａｐ送信抑止を解除する。ｔｒａｐ送信抑止を解除する際に、ｔｒａｐ管理部２１は、時刻３０〜４０秒の間に送信抑止されたｔｒａｐを通知するためのダイジェストｔｒａｐの送信をｔｒａｐ送信部２２に指示する。

時刻５０秒では、時刻４０〜５０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ以上である。このため、ｔｒａｐ管理部２１は、状態７であると判定し、ｔｒａｐ送信抑止を開始する。

時刻６０秒では、時刻５０〜６０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が引き続き閾値Ｖ以上である。このため、ｔｒａｐ管理部２１は、状態３であると判定し、ｔｒａｐ送信抑止を継続する。

時刻７０秒では、時刻６０〜７０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が引き続き閾値Ｖ以上である。かつ、変数Ｋの値はＮである。よって、ｔｒａｐ管理部２１は、状態４であると判定する。そして、ｔｒａｐ管理部２１は、時刻５０〜７０秒の間に送信抑止されたｔｒａｐを通知するためのダイジェストｔｒａｐの送信をｔｒａｐ送信部２２に指示するとともに、変数Ｋの値をリセットすることにより新たなｔｒａｐ抑止期間を設定してｔｒａｐ送信抑止を継続する。

時刻８０秒では、時刻７０〜８０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ未満である。このため、ｔｒａｐ管理部２１は、状態１であると判定し、ｔｒａｐ送信抑止を解除する。ｔｒａｐ送信抑止を解除する際に、ｔｒａｐ管理部２１は、時刻７０〜８０秒の間に送信抑止されたｔｒａｐを通知するためのダイジェストｔｒａｐの送信をｔｒａｐ送信部２２に指示する。

時刻９０秒では、時刻８０〜９０秒のタイムアウト時間におけるｔｒａｐ送信イベントの発生数が閾値Ｖ以上である。このため、ｔｒａｐ管理部２１は、状態７であると判定し、ｔｒａｐ送信抑止を開始する。

上述したように、本実施の形態にかかるネットワーク装置２は、ｔｒａｐ送信イベントが集中的に発生した場合に少なくとも一部のｔｒａｐ送信イベントに関するｔｒａｐ送信を抑止する。さらに、ネットワーク装置２は、送信抑止されたｔｒａｐを包括的に通知するためのダイジェストｔｒａｐを管理端末６に送信する。このため、ネットワーク装置２は、ｔｒａｐ送信量の増大に起因する負荷の増大を抑制しながら、送信抑止されたｔｒａｐの存在を管理端末６に通知することができる。

＜発明の実施の形態３＞
本実施の形態にかかるネットワーク装置３は、上述したネットワーク装置２の改良である。ネットワーク装置３は、機能部２３から受信したｔｒａｐ送信イベントの履歴を保持する。この履歴は、送信抑止されたｔｒａｐ送信イベントに関する履歴も含む。さらに、ネットワーク装置３は、管理端末６からの要求に応じて、保持しておいたｔｒａｐ送信イベントの履歴を管理端末６に送信する。

図１０は、ネットワーク装置３の構成例を示すブロック図である。ｔｒａｐ管理部３１は、上述したｔｒａｐ管理部２１と同様に、ｔｒａｐ送信イベントに応じたｔｒａｐの送信指示、ｔｒａｐ送信の抑止判定、ダイジェストｔｒａｐの送信指示を行う。さらに、ｔｒａｐ管理部３１は、ｔｒａｐの生成履歴をｔｒａｐログファイル３６に保存する。

ｔｒａｐログファイル３６は、ｔｒａｐ送信部２２に送信指示されたｔｒａｐの情報だけでなく、送信抑止されたｔｒａｐの情報も含む。さらに、ｔｒａｐログファイル３６は、ダイジェストｔｒａｐの情報を格納してもよい。図１１は、ｔｒａｐログファイル３６の具体例を示す図である。図１１中のログ３６１及び３６２は、ｔｒａｐ送信部２２に送信指示された２つのｔｒａｐ（シーケンス番号１及び２）の情報を示している。ログ３６３は、送信抑止されたｔｒａｐ（シーケンス番号２００）の情報を示している。図１１の例では、"status: normal"が送信指示されたことを示し、"status: untransmission"が送信抑止されたことを示している。ログ３６４は、ダイジェストｔｒａｐ（シーケンス番号２０１）の情報である。図１１の例では、ダイジェストｔｒａｐは、タイムアウト期間中に送信抑止されたｔｒａｐ群のシーケンス番号範囲（＃１００〜＃２００）と、ｔｒａｐログファイル３６（trap.log）の参照を促すメッセージを含む。図１２は、ログ３６４に対応するダイジェストｔｒａｐ３２１の通知内容を示す図である。

ＦＴＰ（File Transfer protocol）サーバ部３７は、管理端末６が有するＦＴＰクライアント部６２からのＦＴＰプロトコルに従ったアクセスを受け付け、ＦＴＰクライアント部６２にｔｒａｐログファイル３６の内容を送信する。つまり、管理端末６を操作するネットワーク管理者は、管理端末６からネットワーク装置３にアクセスし、ｔｒａｐログファイル３６の内容を参照することができる。なお、ｔｒａｐログファイル３６の転送に使用するプロトコルはＦＴＰに限られない。例えば、ＨＴＴＰ（Hypertext Transfer Protocol）を用いてもよい。この場合、ＦＴＰサーバ部３７に代えてＨＴＴＰサーバ機能をネットワーク装置３に配置すればよい。

図１３は、ｔｒａｐ管理部３１によるｔｒａｐ送信処理手順の具体例を示すフローチャートである。なお、図１３中のステップＳ３０〜Ｓ３６は、図７に示した同一符号のステップと同様であるため説明を省略する。ステップＳ４１では、ｔｒａｐ管理部３１は、受信したｔｒａｐ送信イベントの内容をｔｒａｐログファイル３６に記録する。ステップＳ４２では、送信抑止したｔｒａｐのｔｒａｐログファイル３６における"status"を"untransmission"に変更する。

上述したように、本実施の形態にかかるネットワーク装置３は、送信抑止されたｔｒａｐをログファイル３６に記憶しておく。そして、ネットワーク装置３は、ダイジェストｔｒａｐを受信する管理端末６からのアクセスを受け付け、管理端末６の要求に応じて、送信抑止されたトラップの内容を管理端末に送信する。これにより、ネットワーク管理者は、送信抑止されたｔｒａｐの通知内容を管理端末６から参照することができる。

なお、本実施の形態では、送信抑止が発生したことを示すダイジェストｔｒａｐの送信とともに、送信抑止されたｔｒａｐのログファイル３６への記録を行う構成を示した。しかしながら、ダイジェストｔｒａｐの送信を行わずに、送信抑止されたｔｒａｐのログファイル３６への記録を行ってもよい。この構成では、ネットワーク装置３において送信抑止が行われたことを管理端末６が速やかに認識することはできない。しかしながら、管理端末６を操作する管理者は、受信されたｔｒａｐシーケンス番号が不連続であることによって、未到達のｔｒａｐの存在を認識することができる。この後、ネットワーク装置３にアクセスして、ｔｒａｐログファイル３６を参照することによって、ｔｒａｐの送信抑止が行われたこと、送信抑止されたｔｒａｐの内容を確認することができる。

＜発明の実施の形態４＞
本実施の形態にかかるネットワーク装置４は、上述したネットワーク装置３の改良である。ネットワーク装置４の構成例を図１４に示す。ネットワーク装置４は、ｔｒａｐ送信部４２によるｔｒａｐ送信結果を送信結果ファイル４８に記録する。上述したｔｒａｐログファイル３６は、ｔｒａｐ管理部３１によって作成され、各ｔｒａｐについて送信指示が行われたか否かを記録する。一方、送信結果ファイル４８は、ネットワークへのｔｒａｐ送信が成功したか否かを記録する。

図１５は、送信結果ファイル４８の具体例を示す図である。図１５中のログ４８１〜４８３は、シーケンス番号１、２、及び２００のｔｒａｐの送信履歴を示している。図１５の例では、"transmission result: OK"が送信成功を表し、"transmission result: ＮＧ"が送信失敗を表す。図１５のログ４８２は、シーケンス番号２のｔｒａｐが送信インタフェースのリンクダウンによって送信できなかったことを示している。

図１６は、ｔｒａｐ送信部４２から送信されるダイジェストｔｒａｐによる通知内容の具体例を示している。図１６のダイジェストｔｒａｐ４２１は、タイムアウト期間中に送信抑止されたｔｒａｐ群のシーケンス番号範囲（＃１００〜＃２００）と、ｔｒａｐログファイル３６（trap.log）および送信結果ファイル４８（send_result.log）の参照を促すメッセージを含む。

送信抑止されたｔｒａｐ、およびｔｒａｐ送信部４２が送信に失敗したｔｒａｐの情報を含むｔｒａｐログファイル３６と、ｔｒａｐの送信成否を表す送信結果ファイル４８を作成することによって、以下の利点がある。第１に、ｔｒａｐログファイル３６及び送信結果ファイル４８を管理端末６から参照することによって、ｔｒａｐが管理端末６に到達しなった原因が、（i）ｔｒａｐ管理部３１による送信抑止、（ii）ｔｒａｐ送信部４２の送信失敗、又は（iii）これら以外（装置４と管理端末６の間のネットワークでのパケット廃棄等）のいずれであるかを容易に特定できる。また、いずれの原因でｔｒａｐが未到達となった場合であっても、全てのｔｒａｐの通知内容を管理端末６から確認できる。

第２に、ｔｒａｐ管理部３１とｔｒａｐ送信部４２との間に配置され、ｔｒａｐ送信通知を格納するキュー（不図示）がいっぱいになって一部のｔｒａｐ送信通知が廃棄された場合であっても、ｔｒａｐログファイル３６及び送信結果ファイル４８を参照することによって、ｔｒａｐ未到達の原因がｔｒａｐ送信通知の廃棄にあることが特定できる。

なお、複数の管理端末６にｔｒａｐ送信を行う場合、ｔｒａｐログファイル３６及び送信結果ファイル４８には、ｔｒａｐ送信先ごとにｔｒａｐ情報を記録するとよい。ｔｒａｐ送信先ごとに記録する理由の１つは、複数の宛先に対してｔｒａｐを送信する時刻は必ずしも一致しないためである。また、他の理由は、ハード構成やタイミングによっては、ｔｒａｐ送信部４２でのｔｒａｐ送信の成否が送信先ごとに異なる可能性があるためである。

ところで、発明の実施の形態１〜４で述べたｔｒａｐ管理部１１、２１、及び３１によるｔｒａｐ送信処理は、ＭＰＵ（Micro Processing Unit）、ＣＰＵ（Central Processing Unit）等を含むコンピュータ・システムを用いて行なってもよい。具体的には、図２、３、７、及び１３のフローチャートを用いて説明した処理手順に関する記述を含むプログラムをコンピュータ・システムに実行させればよい。これらのプログラムは、様々な種類の記憶媒体に格納することが可能であり、また、通信媒体を介して伝達されることが可能である。ここで、記憶媒体には、例えば、フレキシブルディスク、ハードディスク、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭカートリッジ、バッテリバックアップ付きＲＡＭメモリカートリッジ、不揮発性ＲＡＭ、フラッシュメモリ等が含まれる。また、通信媒体には、電話回線等の有線通信媒体、マイクロ波回線等の無線通信媒体等が含まれ、インターネットも含まれる。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

１、２、３、４ ネットワーク装置
１１、２１、３１ ｔｒａｐ管理部
１２、２２、４２ ｔｒａｐ送信部
２３ 機能部
２４ タイマ部
２５ 設定ファイル
３６ ｔｒａｐログファイル
３７ ＦＴＰサーバ部
４８ 送信結果ファイル
６ 管理端末
６１ ｔｒａｐ受信部
６２ ＦＴＰクライアント部

Claims (14)

1. イベントの発生に応じて生成されるイベント通知メッセージを、ネットワークを介して管理端末に向けて送信する送信手段と、
   複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信を抑止する管理手段と、
   前記イベント通知メッセージの前記ネットワークへの送信に成功したか否かを示す送信結果情報と、送信抑止された前記少なくとも一部のイベント通知メッセージの内容を示すメッセージログ情報を記憶する記憶手段と、
   前記管理端末からのアクセスを受け付けるとともに、前記管理端末の要求に応じて、前記送信結果情報及び前記メッセージログ情報を前記管理端末に向けて送信する通信手段と、
   を備えるネットワーク装置。
2. 前記少なくとも一部のイベント通知メッセージの送信が抑止された場合に、前記送信手段は、前記少なくとも一部のイベント通知メッセージの送信抑止の発生を包括的に示す抑止通知メッセージを前記管理端末に向けて送信する、請求項１に記載のネットワーク装置。
3. 前記抑止通知メッセージは、送信抑止された前記少なくとも一部のイベント通知メッセージを特定可能な情報を含む、請求項２に記載のネットワーク装置。
4. 前記管理手段は、単位時間当たりの前記イベントの発生量が予め定められた閾値を超えた場合に前記イベント通知メッセージの送信抑止を決定する、請求項１〜３のいずれか１項に記載のネットワーク装置。
5. 前記記憶手段は、前記メッセージログ情報を格納したログファイルを記憶し、
   前記通信手段は、ＦＴＰ（File Transfer protocol）サーバ機能を有し、前記管理端末からのＦＴＰプロトコルに従ったアクセスに応答して前記ログファイルを前記管理端末に送信する、
   請求項１〜３のいずれか１項に記載のネットワーク装置。
6. 前記ネットワーク装置は、ＳＮＭＰ（Simple Network Management Protocol）エージェント機能を有し、
   前記イベント通知メッセージ及び前記抑止通知メッセージは、ＳＮＭＰで定義されたトラップとして生成される、請求項１〜５のいずれか１項に記載のネットワーク装置。
7. イベントの発生に応じて生成されるイベント通知メッセージを、ネットワークを介して管理端末に向けて送信すること、
   複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信を抑止すること、
   前記イベント通知メッセージの前記ネットワークへの送信に成功したか否かを示す送信結果情報と、送信抑止された前記少なくとも一部のイベント通知メッセージの内容を示すメッセージログ情報を記憶手段に格納すること、及び
   前記管理端末からのアクセスを受け付けるとともに、前記管理端末の要求に応じて、前記送信結果情報及び前記メッセージログ情報を前記管理端末に向けて送信すること、
   を含むネットワーク装置の制御方法。
8. 前記少なくとも一部のイベント通知メッセージの送信が抑止された場合に、前記少なくとも一部のイベント通知メッセージの送信抑止の発生を包括的に示す抑止通知メッセージを前記管理端末に向けて送信すること、
   をさらに含む、請求項７に記載の方法。
9. 前記抑止通知メッセージは、送信抑止された前記少なくとも一部のイベント通知メッセージを特定可能な情報を含む、請求項８に記載の方法。
10. 前記格納することは、前記メッセージログ情報を格納したログファイルを格納することを含み、
    前記送信結果情報及び前記メッセージログ情報を送信することは、ＦＴＰ（File Transfer protocol）サーバとして動作することで、前記管理端末からのＦＴＰプロトコルに従ったアクセスに応答して前記ログファイルを前記管理端末に送信することを含む、
    請求項７〜９のいずれか１項に記載の方法。
11. ネットワーク装置の制御処理をコンピュータに実行させるためのプログラムであって、
    前記制御処理は、
    イベントの発生に応じて生成されるイベント通知メッセージをネットワークを介して管理端末に向けて送信するための送信指示を生成すること、
    複数のイベントが集中的に発生した場合に、前記複数のイベントに対応する複数のイベント通知メッセージのうち少なくとも一部の送信指示の生成を抑止すること、
    前記イベント通知メッセージの前記ネットワークへの送信に成功したか否かを示す送信結果情報と、送信抑止された前記少なくとも一部のイベント通知メッセージの内容を示すメッセージログ情報を記憶手段に格納すること、及び
    前記管理端末からのアクセスを受け付けるとともに、前記管理端末の要求に応じて、前記送信結果情報及び前記メッセージログ情報を前記管理端末に向けて送信すること、
    を含む、プログラム。
12. 前記制御処理は、
    前記少なくとも一部のイベント通知メッセージの送信指示が抑止された場合に、前記少なくとも一部のイベント通知メッセージの送信抑止の発生を包括的に示す抑止通知メッセージを前記管理端末に向けて送信するための送信指示を生成すること、
    をさらに含む、請求項１１に記載のプログラム。
13. 前記抑止通知メッセージは、送信抑止された前記少なくとも一部のイベント通知メッセージを特定可能な情報を含む、請求項１２に記載のプログラム。
14. 前記格納することは、前記メッセージログ情報を格納したログファイルを格納することを含み、
    前記送信結果情報及び前記メッセージログ情報を送信することは、ＦＴＰ（File Transfer protocol）サーバとして動作することで、前記管理端末からのＦＴＰプロトコルに従ったアクセスに応答して前記ログファイルを前記管理端末に送信することを含む、
    請求項１１〜１３のいずれか１項に記載のプログラム。

Images