特開 2024-145553 情報処理システム、情報処理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024145553

(43)【公開日】2024-10-15

(54)【発明の名称】情報処理システム、情報処理方法及びプログラム

(51)【国際特許分類】

   H04L 43/10 20220101AFI20241004BHJP

   G06F 11/07 20060101ALI20241004BHJP

【ＦＩ】

H04L43/10

G06F11/07 157

G06F11/07 140A

【審査請求】未請求

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2023057956

(22)【出願日】2023-03-31

(71)【出願人】

【識別番号】000136136

【氏名又は名称】株式会社ＰＦＵ

(74)【代理人】

【識別番号】100145838

【弁理士】

【氏名又は名称】畑添 隆人

(74)【代理人】

【識別番号】100103137

【弁理士】

【氏名又は名称】稲葉 滋

(74)【代理人】

【識別番号】100216367

【弁理士】

【氏名又は名称】水谷 梨絵

(72)【発明者】

【氏名】川渕 優

(72)【発明者】

【氏名】平野 一義

(72)【発明者】

【氏名】石崎 智彦

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042JJ15

(57)【要約】

【課題】機器の属性に応じてキープアライブの流量が抑制された死活監視を可能とすることを課題とする。
【解決手段】情報処理システム１に、パケット取得部２１と、監視対象機器９に対して送信されたキープアライブに対する応答パケットが応答タイムアウト時間内に取得されたか否か、及び監視対象機器９からの応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて監視対象機器９の死活監視を行う監視部２５と、自発パケットが応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、キープアライブ及び自発パケットの少なくともいずれかを用いる監視方法を決定する監視方法決定部２４と、を備え、監視部２５は、監視対象機器９について決定された監視方法に従って、監視対象機器９の死活監視を行うこととした。
【選択図】図２

【特許請求の範囲】

【請求項1】

監視対象機器が送受信するパケットを取得するパケット取得手段と、
前記監視対象機器に対して送信されたキープアライブに対する該監視対象機器からの応答パケットが応答タイムアウト時間内に取得されたか否か、及び該監視対象機器からの前記応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて該監視対象機器の死活監視を行う監視手段と、
前記監視対象機器からの前記自発パケットが前記応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、前記キープアライブ及び前記自発パケットの少なくともいずれかを用いる該監視対象機器の監視方法を決定する監視方法決定手段と、を備え、
前記監視手段は、前記監視対象機器について決定された前記監視方法に従って、該監視対象機器の死活監視を行う、
情報処理システム。

【請求項2】

前記監視手段は、前記監視方法決定手段によって前記キープアライブを送信しない監視方法に決定された前記監視対象機器について、該監視対象機器からの前記自発パケットが取得された場合に、該監視対象機器が生存していると判定する、
請求項１に記載の情報処理システム。

【請求項3】

前記監視対象機器が送受信するパケットを解析することで、該監視対象機器の前記属性を取得する属性取得手段を更に備える、
請求項１に記載の情報処理システム。

【請求項4】

前記監視方法決定手段は、前記監視対象機器のＯＳ種別又は用途に応じて、該監視対象機器の監視方法を決定する、
請求項１に記載の情報処理システム。

【請求項5】

前記監視方法決定手段は、前記監視対象機器のＯＳ種別と用途との組み合わせに応じて、該監視対象機器の監視方法を決定する、
請求項４に記載の情報処理システム。

【請求項6】

前記監視手段は、前記監視対象機器について設定された非稼働期間において、該監視対象機器の死活監視を行わない、
請求項１に記載の情報処理システム。

【請求項7】

前記監視対象機器の用途に基づいて前記非稼働期間を設定する非稼働期間設定手段を更に備える、
請求項６に記載の情報処理システム。

【請求項8】

前記監視方法決定手段は、前記監視対象機器に係る前記期待度が第一の範囲の期待度である場合に、該監視対象機器の監視方法を、前記キープアライブを送信することなく、該監視対象機器からの前記自発パケットが取得された場合に該監視対象機器が生存していると判定する監視方法に決定する、
請求項１に記載の情報処理システム。

【請求項9】

前記監視方法決定手段は、前記監視対象機器に係る前記期待度が第二の範囲の期待度である場合に、該監視対象機器の監視方法を、前記キープアライブを定期的に送信する監視方法に決定する、
請求項８に記載の情報処理システム。

【請求項10】

前記監視方法決定手段は、前記監視対象機器に係る前記期待度が第三の範囲の期待度である場合に、該監視対象機器の監視方法を、前記自発パケットが所定期間取得できない場合に前記キープアライブを送信する監視方法に決定する、
請求項９に記載の情報処理システム。

【請求項11】

前記第一の範囲の期待度は、前記応答タイムアウト時間内に前記監視対象機器からの自発パケットが取得できる可能性が第一の閾値以上である期待度である、
請求項１０に記載の情報処理システム。

【請求項12】

前記第二の範囲の期待度は、前記応答タイムアウト時間内に前記監視対象機器からの自発パケットが取得できる可能性が前記第一の閾値よりも小さい第二の閾値未満である期待度である、
請求項１１に記載の情報処理システム。

【請求項13】

前記第三の範囲の期待度は、前記応答タイムアウト時間内に前記監視対象機器からの自発パケットが取得できる可能性が前記第一の閾値未満且つ前記第二の閾値以上である期待度である、
請求項１２に記載の情報処理システム。

【請求項14】

前記第三の範囲の期待度は、前記応答タイムアウト時間内に前記監視対象機器からの自発パケットが取得できる可能性が外的要因によって前記第一の閾値未満且つ前記第二の閾値以上となる場合を含む、
請求項１３に記載の情報処理システム。

【請求項15】

コンピュータが、
監視対象機器が送受信するパケットを取得するパケット取得ステップと、
前記監視対象機器に対して送信されたキープアライブに対する該監視対象機器からの応答パケットが応答タイムアウト時間内に取得されたか否か、及び該監視対象機器からの前記応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて該監視対象機器の死活監視を行う監視ステップと、
前記監視対象機器からの前記自発パケットが前記応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、前記キープアライブ及び前記自発パケットの少なくともいずれかを用いる該監視対象機器の監視方法を決定する監視方法決定ステップと、を実行し、
前記監視ステップでは、前記監視対象機器について決定された前記監視方法に従って、該監視対象機器の死活監視を行う、
情報処理方法。

【請求項16】

コンピュータを、
監視対象機器が送受信するパケットを取得するパケット取得手段と、
前記監視対象機器に対して送信されたキープアライブに対する該監視対象機器からの応答パケットが応答タイムアウト時間内に取得されたか否か、及び該監視対象機器からの前記応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて該監視対象機器の死活監視を行う監視手段と、
前記監視対象機器からの前記自発パケットが前記応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、前記キープアライブ及び前記自発パケットの少なくともいずれかを用いる該監視対象機器の監視方法を決定する監視方法決定手段と、として機能させ、
前記監視手段は、前記監視対象機器について決定された前記監視方法に従って、該監視対象機器の死活監視を行う、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、機器の死活監視技術に関する。

【背景技術】

【0002】

従来、監視対象サーバが、状態通知パケットを定期的に監視装置に送信し、管理サーバが、状態通知パケットがこなくなったことを検出すると、状態通知パケットがこなくなった監視対象サーバ以外の他監視対象サーバからの状態通知パケットが受信できていれば、監視対象サーバのネットワーク構成情報から、管理サーバから状態通知パケットがこなくなった監視対象サーバまでの複数の通信ルートを抽出し、該複数の通信ルートを利用して状態通知パケットがこなくなった監視対象サーバの死活状態を確認する、死活監視方法が提案されている（特許文献１を参照）。

【0003】

また、被監視装置に対する監視間隔を自動的に設定し、設定した監視間隔に基づいて、被監視装置の監視を行なう監視装置であって、被監視装置から監視項目に関する監視データを収集する収集部と、収集部が監視データを収集する際に消費するリソースを収集部の負荷として測定する測定部と、複数の監視データの重複度及び負荷に基づいて被監視装置に対する監視間隔を選定する判定部と、を備え、収集部は、選定された監視間隔に基づいて、監視データを収集する、監視装置が提案されている（特許文献２を参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００９－２０５３６４号公報

【特許文献2】特開２０１８－１６０７５５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

従来、ネットワークで発生した異常を早期に発見するための死活監視システムが用いられている。しかし、キープアライブによる死活監視は、機器数に応じてキープアライブの流量が増えることでネットワーク遅延等の様々な不具合の原因になり得る。

【0006】

本開示は、上記した問題に鑑み、機器の属性に応じてキープアライブの流量が抑制された死活監視を可能とすることを課題とする。

【課題を解決するための手段】

【0007】

本開示の一例は、監視対象機器が送受信するパケットを取得するパケット取得手段と、前記監視対象機器に対して送信されたキープアライブに対する該監視対象機器からの応答パケットが応答タイムアウト時間内に取得されたか否か、及び該監視対象機器からの前記応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて該監視対象機器の死活監視を行う監視手段と、前記監視対象機器からの前記自発パケットが前記応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、前記キープアライブ及び前記自発パケットの少なくともいずれかを用いる該監視対象機器の監視方法を決定する監視方法決定手段と、を備え、前記監視手段は、前記監視対象機器について決定された前記監視方法に従って、該監視対象機器の死活監視を行う、情報処理システムである。

【0008】

本開示は、情報処理装置、システム、コンピュータによって実行される方法又はコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

【発明の効果】

【0009】

本開示によれば、機器の属性に応じてキープアライブの流量が抑制された死活監視を可能とすることが可能となる。

【図面の簡単な説明】

【0010】

【図1】第一の実施形態に係るシステムの構成を示す概略図である。

【図2】第一の実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。

【図3】第二の実施形態に係るシステムの構成を示す概略図である。

【図4】第二の実施形態に係るネットワーク監視装置の機能構成の概略を示す図である。

【図5】実施形態に係る機器情報リストのデータ構造の例を示す図である。

【図6】実施形態に係る動作条件リストのデータ構造の例を示す図である。

【図7】実施形態における、機器の運用種別と当該機器の監視タスクに関連付けられるタイムテーブルとの関係を示す図である。

【図8】実施形態に係る監視設定処理の流れの概要を示すフローチャートである。

【図9】実施形態に係る動作判定処理の流れの概要を示すフローチャートである。

【図10】実施形態に係る、パケット送信頻度が高い監視対象機器に対する監視処理の流れの概要を示すフローチャートである。

【図11】実施形態に係る、パケット送信頻度が中程度の監視対象機器に対する監視処理の流れの概要を示すフローチャートである。

【図12】実施形態に係る、パケット送信頻度が低い監視対象機器に対する監視処理の流れの概要を示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、本開示に係る情報処理装置、システム、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、システム、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

【0012】

以下に説明する実施形態では、本開示に係る情報処理装置、システム、方法及びプログラムを、ネットワーク監視装置が設置された通信システムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、システム、方法及びプログラムは、ネットワークに接続された端末を管理するための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。

【0013】

ひとたびネットワークが停止しその復旧が遅れた場合、甚大な損害が生じる可能性がある。このため従来、ネットワーク管理者は死活監視システムを導入し、ネットワークで発生した異常を早期に発見することで、早期復旧に役立てている。一方で、死活監視は機器の生存を確認するためのパケット（キープアライブ）を機器宛てに送信するため、キープアライブによる機器監視は、機器数に応じてキープアライブの流量が増えることでネットワーク遅延の原因となったり、キープアライブを受信した機器が誤動作したり、死活監視自体がネットワークに異常を引き起こしたり、といった不具合の原因になり得る。

【0014】

そこで、死活監視によるキープアライブの送信を最小限に抑えることが考えられる。しかし、そのためには、ネットワーク管理者が監視対象となる様々な機器に対して、機器毎に通信の特性や運用の仕方が異なることを把握したうえで、機器毎に最適な監視方法を設定する作業が生じ、ネットワーク管理者の作業負担が機器数の増加に伴って増してしまう。

【0015】

上記の状況に鑑み、以下に説明する実施形態に開示されたシステムでは、機器毎に監視方法を変え、最適な監視を可能とする機能を実装することで、ネットワーク管理者の作業負担を抑えつつ、機器の属性に応じた死活監視を可能としている。

【0016】

＜第一の実施形態＞
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、ネットワークに接続されることで互いに通信可能な１又は複数のネットワーク監視装置１、１又は複数のスイッチ装置５、及び１又は複数の監視対象機器９を備える。

【0017】

ネットワーク監視装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信ユニット１５、等を備えるコンピュータである。但し、ネットワーク監視装置１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、ネットワーク監視装置１は、単一の筐体からなる装置に限定されない。ネットワーク監視装置１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

【0018】

スイッチ装置５は、ネットワークに流れるパケットの経路スイッチングを行うための装置であり、また、当該スイッチ装置５を通過するパケットを複製する機能、及び複製されたパケットを送出するミラーポートを備える。ネットワーク監視装置１は、当該ミラーポートから送出されたパケットを受け取ることで、ネットワークに流れるパケットを取得し、ネットワークに接続された監視対象機器９を監視することができる。

【0019】

監視対象機器（以下、「端末」と称する。）９は、オフィスや工場、家庭、公共スペース等において使用される情報機器であり、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、スマートフォン、スキャナー、プリンタ、センサー、産業用機械、ＩｏＴ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）機器等である。

【0020】

図２は、本実施形態に係るネットワーク監視装置１の機能構成の概略を示す図である。ネットワーク監視装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ネットワーク監視装置１に備えられた各ハードウェアが制御されることで、パケット取得部２１、属性取得部２２、非稼働期間設定部２３、監視方法決定部２４及び監視部２５を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、ネットワーク監視装置１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

【0021】

パケット取得部２１は、監視対象機器９が送受信するパケットを取得する。具体的には、パケット取得部２１は、ネットワーク上でキャプチャされたパケット（本実施形態では、Ｅｔｈｅｒｎｅｔフレーム。）を取得する。本実施形態では、上述の通り、スイッチ装置５のミラーポートから送出されたパケットを受信することで、ネットワーク上でキャプチャされたパケットを取得する。但し、ネットワークを流れるパケットを取得する方法には、スイッチ装置５のミラーポートから取得する以外の方法が採用されてもよい。例えば、ネットワーク監視装置１が、ルータ又はスイッチ等のネットワーク上を流れるパケットを中継する装置内に設けられることで、パケット取得部２１は、ネットワーク上でキャプチャされたパケットを取得してもよい。

【0022】

属性取得部２２は、監視対象機器９が送受信するパケットを解析することで、当該監視対象機器９の属性を取得する。本実施形態では、監視対象機器９の属性として、当該パケットの送信元端末のオペレーティングシステム（ＯＳ）種別、及び当該パケットの送信元端末の用途（例えば、「クライアント運用」、「サーバ運用」、「ゲートウェイ運用」、「特殊運用」等）が取得される。なお、本実施形態では、監視対象機器９の属性を、監視対象機器９によって送受信されるパケットを解析することで取得する例を説明するが、監視対象機器９の属性の取得方法は、本実施形態における例示に限定されない。例えば、属性取得部２２は、端末９によるパケットの送信順序及び送信タイミングを特定可能な情報を含むパケットデータを教師データとして用いた学習モデルを用いて、送信元端末のＯＳを判別してもよい。

【0023】

非稼働期間設定部２３は、監視対象機器９の用途に基づいて、当該監視対象機器９が稼働しない期間である非稼働期間を設定する。なお、非稼働期間は、監視対象機器９が稼働しない期間を設定することで特定されてもよいし、監視対象機器９が稼働する期間を設定することで特定されてもよい。

【0024】

監視方法決定部２４は、監視対象機器９からの自発パケットが応答タイムアウト時間内に取得される期待度を推定可能な属性に応じて、キープアライブ及び自発パケットの少なくともいずれかを用いる当該監視対象機器９の監視方法を決定する。本実施形態において、監視方法決定部２４は、監視対象機器９のＯＳ種別と用途との組み合わせに応じて、当該監視対象機器９の監視方法を決定する。但し、監視方法を決定するために参照される属性は、本実施形態において例示された、ＯＳ種別と用途との組み合わせに限定されない。例えば、監視方法決定部２４は、監視対象機器９のＯＳ種別及び用途のいずれか一方に応じて、当該監視対象機器９の監視方法を決定してもよい。

【0025】

ここで、監視対象機器９からの自発パケットが応答タイムアウト時間内に取得される期待度とは、換言すれば、監視対象機器９からの自発パケットの送信頻度である。監視方法決定部２４は、期待度を何らかの閾値と比較することで、監視方法を決定することができる。本実施形態では、期待度を３つの範囲に分けて、監視対象機器９の期待度がいずれの範囲に属するかに応じて、当該監視対象機器９の監視方法を決定する。但し、監視対象機器９の期待度がいずれの範囲に属するかを決定する方法は、期待度と閾値との比較に限定されない。例えば、機器の属性毎に、又は属性の組み合わせ毎に、そのような属性又は属性の組み合わせを有する機器がいずれの範囲に属するかを予め決定しておくことで、期待度を算出することなく、対象の機器が属する範囲を決定し、対象の機器の監視方法を決定することが可能である。また、期待度を算出する場合には、例えば、機器の属性毎に期待度に貢献する重み等を予め定めておいて算出する方法や、実際の自発パケット送信頻度と機器の属性との関係とを学習モデルに学習させておき、機器の属性を当該モデルに入力することで期待度を得る方法等が採用可能である。

【0026】

本実施形態において、第一の範囲の期待度（期待度：高）は、応答タイムアウト時間内に監視対象機器９からの自発パケットが取得できる可能性が第一の閾値以上である期待度である。監視方法決定部２４は、監視対象機器９に係る期待度が第一の範囲の期待度（期待度：高）である場合に、当該監視対象機器９の監視方法を、キープアライブを送信することなく、当該監視対象機器９からの自発パケットが取得された場合に当該監視対象機器９が生存していると判定する監視方法に決定する。

【0027】

また、本実施形態において、第二の範囲の期待度（期待度：低）は、応答タイムアウト時間内に監視対象機器９からの自発パケットが取得できる可能性が第一の閾値よりも小さい第二の閾値未満である期待度である。監視方法決定部２４は、監視対象機器９に係る期待度が第二の範囲の期待度（期待度：低）である場合に、当該監視対象機器９の監視方法を、キープアライブを定期的に送信する監視方法に決定する。

【0028】

また、本実施形態において、第三の範囲の期待度（期待度：中）は、応答タイムアウト時間内に監視対象機器９からの自発パケットが取得できる可能性が第一の閾値未満且つ第二の閾値以上である期待度である。なお、第三の範囲の期待度（期待度：中）は、応答タイムアウト時間内に監視対象機器９からの自発パケットが取得できる可能性が外的要因によって第一の閾値未満且つ第二の閾値以上となる場合を含む。監視方法決定部２４は、監視対象機器９に係る期待度が第三の範囲の期待度（期待度：中）である場合に、当該監視対象機器９の監視方法を、自発パケットが所定期間取得できない場合にキープアライブを送信する監視方法に決定する。

【0029】

監視部２５は、監視対象機器９について決定された監視方法に従って、当該監視対象機器９の死活監視を行う。監視部２５は、監視対象機器９に対して送信されたキープアライブに対する当該監視対象機器９からの応答パケットが応答タイムアウト時間内に取得されたか否か、及び当該監視対象機器９からの応答パケット以外の自発パケットが取得されているか否か、の少なくともいずれかに基づいて当該監視対象機器９の死活監視を行う。このため、監視方法決定部２４によってキープアライブを送信しない監視方法に決定された監視対象機器９について、監視部２５は、当該監視対象機器９からの自発パケットが取得された場合に、当該監視対象機器９が生存していると判定する。また、本実施形態において、監視部２５は、監視対象機器９について設定された非稼働期間において、当該監視対象機器９の死活監視を行わない。

【0030】

＜第二の実施形態＞
以下、本開示に係る機器の死活監視を、監視対象機器９毎に監視タスクを設定することによって実行する実施形態を説明する。なお、上記説明した第一の実施形態に対応する構成については、同一の符号を付して説明する。

【0031】

図３は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、ネットワークに接続されることで互いに通信可能な１又は複数のネットワーク監視装置（死活監視装置。図には１台のみ図示する。）１、ネットワーク監視装置１のマネージャ装置３、１又は複数のスイッチ装置５、及び１又は複数の監視対象機器９を備える。

【0032】

ネットワーク監視装置１は、死活監視機能、及び機器識別機能を提供する。ネットワーク監視装置１は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、記憶装置１４、通信ユニット１５、等を備えるコンピュータである。但し、ネットワーク監視装置１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、ネットワーク監視装置１は、単一の筐体からなる装置に限定されない。ネットワーク監視装置１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。ネットワーク監視装置１において、通信ユニット１５は、ネットワークに接続してパケットを送受信し、ＣＰＵ１１は、死活監視プログラムを実行し、ＲＡＭ１３は、死活監視プログラムの実行に用いられる作業用記憶領域を確保し、記憶装置１４は、死活監視の結果を記憶する。

【0033】

マネージャ装置３は、ネットワーク監視装置１を管理するための機器であり、ユーザは、マネージャ装置３によって提供されるＵＩを介して、死活監視を行うための設定をネットワーク監視装置１に対して行い、ネットワーク監視装置１による死活監視結果を確認する。

【0034】

監視対象機器９は、ネットワーク監視装置１が死活監視の対象とする各種ネットワーク機器である。ここで、いずれの機器を管理対象とするかは、マネージャ装置３を介して設定可能である。

【0035】

図４は、本実施形態に係るネットワーク監視装置１の機能構成の概略を示す図である。ネットワーク監視装置１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、ネットワーク監視装置１に備えられた各ハードウェアが制御されることで、パケット処理部２１、機器識別部２２、データ管理部２３、動作判定部２４、タスク登録部２５、キープアライブ処理部２６、及びマネージャ連携部２７を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、ネットワーク監視装置１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

【0036】

パケット処理部（パケット取得部）２１は、ネットワークに接続された各種端末とネットワーク監視装置１との間の通信を処理する。具体的には、パケット処理部２１は、マネージャ装置３とマネージャ連携部２７との間の通信、ネットワーク上の端末装置と機器識別部２２との間の通信、監視対象機器９とキープアライブ処理部２６との間の通信等を中継する。

【0037】

マネージャ連携部２７は、マネージャ装置３と連携し、マネージャ装置３を利用して、ネットワーク監視装置１によって自動取得された機器情報リスト２３ａを参照し、機器情報リスト２３ａに死活監視の設定を行う。また、マネージャ連携部２７は、後述する機器情報リスト２３ａの内容（死活状態を示す状態フラグを含む。）を定期的にマネージャ装置３に通知することで、ユーザがマネージャ装置３のＵＩ画面で機器情報の一覧を参照する際に、各機器の死活状態（死活監視結果）も合わせて閲覧可能とする。

【0038】

機器識別部（属性取得部）２２は、ネットワーク上に存在する機器を自動検知し、当該機器から受信した汎用パケットを解析することで、当該機器に関する機器情報を取得する。機器情報の取得及び管理については、図５に示す機器情報リスト２３ａ、及び図９に示す動作判定処理を参照して後述する。取得された機器情報は、機器情報リスト２３ａに順次格納される。

【0039】

ここで取得される機器情報には、当該機器のＯＳ種別及び用途が含まれる。なお、ＯＳ種別及び用途は自動取得されてもよいし、手動設定されてもよいが、本実施形態では、少なくともＯＳ種別について自動取得される例を説明する。機器識別部２２は、例えば、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）、Ｎｅｔｗｏｒｋ Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ（ＮｅｔＢＩＯＳ）といった汎用プロトコルで扱われる通信パケットを解析し、パケットに含まれる特定のデータを抽出し、その値に基づいて、ＯＳ種別を特定することができる。ここで、パケットに含まれる特定のデータとは、例えば、ＨＴＴＰについてはＧＥＴリクエストのＵｓｅｒ－Ａｇｅｎｔヘッダの値であってよく、ＤＨＣＰについてはオプションコード５５（Ｐａｒａｍｅｔｅｒ Ｌｉｓｔ）やオプションコード６０（Ｖｅｎｄｏｒ ｃｌａｓｓ ｉｄｅｎｔｉｆｉｅｒ）の値であってよく、ＮｅｔＢＩＯＳについてはＯＳバージョンやサーバタイプの値であってよい。

【0040】

データ管理部２３は、本開示に係る死活監視のために参照されるデータを管理するデータ管理部であり、機器情報リスト２３ａ及び動作条件リスト２３ｂを有する。以下、機器情報リスト２３ａ及び動作条件リスト２３ｂの詳細について説明する。

【0041】

図５は、本実施形態に係る機器情報リスト２３ａのデータ構造の例を示す図である。機器情報リスト２３ａは、機器識別部２２によって自動検知された複数の機器の機器情報の集合体であり、後述する動作条件と照合して利用される。本実施形態において、機器情報は、機器が送信するパケットに基づいて機器識別部２２で自動取得された情報（機器のＩＰアドレス、機器のＭＡＣアドレス、機器に搭載されたＯＳ種別、ホスト名等）と、ユーザが任意で設定可能な情報（役割、詳細情報、備考等）とを含む。また、機器情報には、当該機器の用途を示す因子が含まれる。但し、機器の用途を示す因子は１つの特定の情報に限定されず、例えば、「機種名」、「機器種別」、「機器種別詳細」、「役割」、「備考」が機器の用途を示す因子として参照されてよい。また、機器の用途を示す因子には、自動取得される情報が参照されてもよいし、ユーザによって設定される因子が参照されてもよいし、これらの双方の情報が参照されて用途が決定されてもよい。

【0042】

機器情報の構成因子は、上記に例示された因子に限定されない。例えば、機器情報には、自動取得可能な因子として、ＩＰアドレス、ＭＡＣアドレス、ホスト名、ＮｅｔＢＩＯＳ名、所属セグメント（機器が所属するネットワークセグメント名。例えば、「業務ネットワーク１」等。）、製造元、ＯＳ種別、機種名、機器種別（例えば、ルータ、ＮＡＳ、プリンタ、ネットワークスキャナ等。）、又は役割（例えば、マネージャ、ゲートウェイ等。）が用いられてよい。また、機器情報には、任意の文字列で設定可能な因子として、機器種別詳細（例えば、「個人端末」、「共用端末」等。）、役割（例えば、「マネージャ」、「ゲートウェイ」等。）、又は備考（機器の補足情報）が用いられてよい。

【0043】

図６は、本実施形態に係る動作条件リスト２３ｂのデータ構造の例を示す図である。動作条件リスト２３ｂは、各監視対象機器９に対してどのようにキープアライブを送信するか（監視対象機器９をどのように監視するか）を判断するための複数の動作条件の集合体であり、上述した機器情報（ＯＳ種別、役割等）と照合して利用される。本実施形態において、各々の動作条件は、構成因子として優先度、判定条件、監視方法、及び監視期間を含み、これらの因子が１セットとして紐付けて利用される。

【0044】

動作条件の構成因子のうち、優先度は、判定条件の優先度である。動作条件リスト２３ｂ内の判定条件は、優先度の高い判定条件から順に評価され、最初に判定条件を満たした監視方法が採用される。なお、本実施形態において、優先度は値の小さい順（即ち、１，２，３，４，５，・・・の順）に高い（値の小さい順に評価される）ものとする。

【0045】

判定条件は、監視方法を特定するための判定条件である。機器情報が判定条件と合致した場合、合致した判定条件に紐付いている監視方法が、当該機器情報に係る機器の監視方法として採用される。本実施形態では、判定条件で利用可能な判定因子として、「ＯＳ種別」及び「用途」の２つが用いられ、一般に知られている当該ＯＳの特徴、及び当該機器の用途の組み合わせに基づいて、監視対象機器９のパケット送信頻度（監視対象機器９からの自発パケットが応答タイムアウト時間内に取得される期待度）が特定される。即ち、本実施形態では、「ＯＳ種別」及び「用途」をキーとして条件（ＡＮＤ，ＯＲ，ＮＯＲ等の論理演算子を用いて複数の条件を組み合わせ可。）が設定され、条件を満たすものが合致と判断される。

【0046】

監視方法は、死活監視の方法である。監視タスクは、設定された監視方法に従って、当該監視タスクが担当する監視対象機器９の死活監視を行う。本実施形態では、監視方法として、監視対象機器９によるパケット送信頻度（換言すれば、監視対象機器９からの自発パケットが応答タイムアウト時間内に取得される期待度。）に対応する監視方法が提供され、１つの動作条件に対していずれかの監視方法が紐付けられる。機器が頻繁にパケットを送信していればキープアライブ送信せずとも機器の生存は自明である。よって、頻繁にパケットを送信する機器に対してキープアライブ送信をなくす、もしくはキープアライブ送信頻度を下げることで、キープアライブの流量を減らすことができる。

【0047】

ＯＳには一般的なコンピュータ機器に搭載される汎用ＯＳから、ネットワークスイッチ装置（スイッチ装置５を含む。）や工場の工作機器等の専用装置に特化した専用ＯＳ等いくつか種類がある。また、標準で実装されている機能や通信サービスもＯＳの種類によって異なる。そのため、搭載するＯＳの種類が、その機器の通信特性を左右する。例えば、パケットの送信頻度に着目した場合、以下のように分類できる。

【0048】

パケット送信頻度（期待度）：高・・・クライアント又はサーバを運用するためのＯＳ。当該機器が生きている場合、キープアライブの応答タイムアウト時間（例えば、１分）に必ず機器からの自発パケットが期待できる。ネットワークファイル共有やプリンタ共有のためのブロードキャスト通信（ＮｅｔＢＩＯＳ）やローカル名前解決のためのブロードキャスト通信（ｍＤＮＳ）等が標準で動作し、これらパケットを自発的に定常的に送信するため。

【0049】

パケット送信頻度（期待度）：中・・・サーバ又はゲートウェイ（パケットを中継する機器）を運用するためのＯＳ。当該機器が生きている場合であっても、キープアライブの応答タイムアウト時間（例えば、１分）に必ずしも機器からの自発パケットが期待できない。（他機器の通信等の外的要因によって、必ずくるときもあればしばらく来なくなることもあるような機器）用途に合わせてカスタマイズしてサービス通信が追加され、他機器からのアクセス次第でパケットを送信する頻度が変動するため。

【0050】

パケット送信頻度（期待度）：低・・・特殊な運用がされる機器（工作機械等専用機等）のための専用ＯＳ。当該機器が生きている場合であっても、キープアライブの応答タイムアウト時間（例えば、１分）にほとんど機器からの自発パケットが期待できない（基本的に通信相手や通信量が限られており、基本的に自発パケットを出さない機器）。特定機器（専用の制御端末等）のみを通信相手とし、作業指示等一時的な制御通信パケットを受信し応答を返すのみであり、自発的にはほとんどパケットを発しないため。

【0051】

以上より、本実施形態では、監視対象機器９によるパケット送信頻度が「期待度：高」、「期待度：中」、及び「期待度：低」の３つに分類され、これらの期待度の夫々に対応する３種類の監視方法が提供される。即ち、本実施形態では、１つの動作条件に対して３種類の監視方法のうちいずれかが紐付けられる。なお、本実施形態では高、中、低の３つに分類する例を説明しているが、分類方法はＯＳの特徴を把握したうえで、目安に照らし合わせて決定されればよく、分類の数は本実施形態による例示に限定されない。

【0052】

各監視方法の詳細については後述するが、パケット送信頻度が高い（期待度：高）監視対象機器９のための監視方法（以下、「送信頻度が高の機器向け監視方法」）は、キープアライブを送信せず、監視対象機器９からの自発パケットのみに基づいて当該監視対象機器９の死活判断を行う監視方法である。これにより、当該監視対象機器９に係るキープアライブの流量をゼロにできる。また、パケット送信頻度が中程度（期待度：中）の監視対象機器９のための監視方法（以下、「送信頻度が中の機器向け監視方法」）は、監視対象機器９からの自発パケットがある場合にはキープアライブを送信せず、監視対象機器９からの自発パケットがない場合には監視対象機器９に対してキープアライブを送信し応答の有無で監視対象機器９の死活の判断を行う監視方法である。これにより、当該監視対象機器９に係るキープアライブの流量を抑制できる。また、パケット送信頻度が低い（期待度：低）監視対象機器９のための監視方法（以下、「送信頻度が低の機器向け監視方法」）は、監視対象機器９に対して定期的にキープアライブを送信し、応答の有無で監視対象機器９の死活の判断を行う監視方法（即ち、従来の監視方法）である。

【0053】

更に、機器の属性として用途を参照することで、送信頻度の分類をより細かく制御することが可能となる。例えば、同じＯＳであっても用途によっては利用する通信サービスが変わり、標準以外の通信サービスを追加インストールして利用するケースも存在する。また、クライアント運用とサーバ運用とで比較した場合、通信の起点となるクライアントのほうが、クライアントからの通信の受け手となるサーバよりも自発的に発信するパケットが多い。このため、同じＯＳであっても、機器によっては必ずしもパケット送信頻度は同じとはならない。このことから、ＯＳ種別に加えて、機器の用途を併せて参照することで、送信頻度の分類をより細かく判定することが可能となる。より具体的には、クライアント又はサーバを運用するためのＯＳについては、用途がクライアントである場合にはパケット送信頻度を「期待度：高」と判定し、用途がサーバである場合にはパケット送信頻度を「期待度：中」と判定することが可能である。

【0054】

監視期間は、死活監視が有効となる期間である。監視タスクは、設定された監視期間に基づいて、当該監視タスクが担当する監視対象機器９の死活監視を休止及び／又は再開する。機器が稼働していない期間は、非稼働であることが自明であるため、監視を省略可能である。稼働していない期間は監視しないことで、キープアライブの流量を減らすことができる。

【0055】

図７は、本実施形態における、機器の運用種別と当該機器の監視タスクに関連付けられるタイムテーブルとの関係を示す図である。本実施形態において、監視期間は、機器の運用期間を参考に予め作成されたタイムテーブルの名前を指定することで設定される。タイムテーブルの構成因子は、例えば、月、曜日、日、時刻等の夫々について設定された稼働期間及び／又は休止期間であり、これらの因子を組み合わせることで（ＡＮＤ，ＯＲ，ＮＯＲ等の論理演算子を用いて複数の条件を組み合わせ可。）、タイムテーブルが作成される。

【0056】

用途に従って稼働期間が決まっている機器に対しては、用途に基づく機器の稼働期間に対応する監視期間が設定されることで、当該機器が稼働している間のみ死活監視を行うようにし、機器が稼働していない間のキープアライブの流量を削減できる。このため、予め任意のタイムテーブルを作成し、用途を示す情報にタイムテーブルが紐付けられることで、監視が実行される期間が設定されてもよい。また、部署単位や業務グループ単位等、同じ稼動期間の機器をグルーピング可能な枠組みがあれば、その枠組みに合わせた用途やタイムテーブルを定義することで、効率的な運用が可能である。なお、図７に示された例では、デフォルト（タイムテーブルに何も情報がない場合）を常時稼動とし、休止したい期間を設定することとしているが、休止したい期間に代えて、監視したい期間を設定することとしてもよい。

【0057】

動作判定部（監視方法決定部）２４は、機器情報リスト２３ａと動作条件リスト２３ｂとを照合し、機器情報リスト２３ａに登録された機器のうちの監視対象機器９、及び、当該監視対象機器９についての監視方法を判定し、タスク登録部２５を呼び出す。

【0058】

タスク登録部（監視部）２５は、動作判定部２４による判定結果に基づいて、監視対象機器９毎に決定された監視方法が設定された監視タスクを登録する。ネットワーク監視装置１は、タスク登録部２５によって登録された１又は複数の監視タスクの夫々によって、機器識別部２２によって自動検知された機器のうちユーザが死活監視有効とした監視対象機器９に対する死活監視を行う。

【0059】

監視タスクは、当該監視タスクに設定された監視方法に基づいてキープアライブを送信するようにキープアライブ処理部２６に指示する。本実施形態では、１つの監視対象機器９に対し１つの監視タスクが登録される。監視対象機器９に応じた監視方法が監視タスクに紐付けられ、監視タスクは、紐付けられた監視方法に基づいて、キープアライブ処理部２６に対してキープアライブの送信指示を行う。更に、監視タスクは、自身が指示したキープアライブ送信タイミングを起点として規定時間（応答タイムアウト時間。例えば１分。）内に応答を受信できたか否かを継続的に確認することで、死活監視の結果判定を行う。応答を受信できていれば当該機器の状態がａｌｉｖｅ（生）と判定され、応答を受信できていなければ当該機器の状態がｄｅａｄ（死）と判断される。機器の状態の判定結果は、機器情報リスト２３ａ内の該当する機器情報に含まれる状態フラグ域に、ａｌｉｖｅ／ｄｅａｄ（生／死）を表すフラグを用いて記録される。

【0060】

キープアライブ処理部２６は、指示に従ってキープアライブを送信する。また、送信されたキープアライブへの応答を含む、監視対象機器９からのパケットが受信された場合に、該当する機器情報に、当該パケットを受信した時刻を記録する。即ち、本実施形態において、キープアライブ処理部２６は、キープアライブに対する応答のみならず、監視対象機器９が発信するパケット（自発パケット）全般について、パケット受信時刻を記録する。

【0061】

即ち、本実施形態では、機器情報に含まれるＯＳ種別（自動取得できる情報）及び用途（手動設定する情報）に基づいて、当該機器の監視方法（本実施形態では、機器が送信するパケットの頻度、及び機器が稼働する期間）を自動的に特定し、キープアライブ送信を抑制することとしている。

【0062】

次に、本実施形態に係るシステムによって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

【0063】

図８は、本実施形態に係る監視設定処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、未検知の機器からパケットが受信されたことを契機として実行される。

【0064】

ステップＳ１０１及びステップＳ１０２では、受信パケットが解析され、機器情報が取得される。パケット処理部２１は、未検知の機器からパケットを受信し（ステップＳ１０１）、受信したパケットを機器識別部２２へ転送する。機器識別部２２は、受信されたパケットを解析することで、ネットワーク上の各機器に係る、ＯＳ種別を含む機器情報を取得する（ステップＳ１０２）。即ち、機器識別部２２は、機器から送信されたパケットを自動的に検知し、且つ識別する。機器識別部２２は、取得された機器情報を、機器情報リスト２３ａに記録する。その後、処理はステップＳ１０３へ進む。

【0065】

ステップＳ１０３では、収集された機器情報に係る機器について、死活監視の基本設定が行われる。マネージャ連携部２７は、マネージャ装置３のＵＩ画面を介して、ユーザに対して機器情報リスト２３ａに記憶されている機器情報の一覧を提供する。ユーザは、一覧に含まれる機器のうち、死活監視対象の機器情報に対して、死活監視を有効となるように設定を行う。具体的には、ここでは、機器情報リスト２３ａ内の各機器情報には死活監視の有効／無効を示すフラグ（監視フラグ）が含まれており、ユーザの指示に従って、この監視フラグの書き換えが行われる。また、ユーザは、必要に応じて、動作条件リスト２３ｂを編集することが出来る。死活監視について監視フラグが有効に設定された機器は、後述する動作判定処理において、監視対象機器９として抽出され、監視タスクによる監視の対象とされる。なお、本ステップの処理において、マネージャ装置３からの管理用通信は、マネージャ連携部２７によって中継される。その後、本フローチャートに示された処理は終了する。

【0066】

図９は、本実施形態に係る動作判定処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、定期的に、又はユーザからの監視開始の指示が受け付けられたことを契機として実行される。

【0067】

動作判定部２４は、機器情報リスト２３ａを参照することで監視対象機器９を特定し、特定された監視対象機器９について機器情報リスト２３ａ及び動作条件リスト２３ｂを照合することで、どのような監視方法で監視を行うかを判定する。そして、タスク登録部２５は、動作判定部２４によって監視対象として判定された監視対象機器９について、監視対象機器９毎に監視タスクを登録する。夫々の監視タスクには、動作判定部２４によって導き出された監視方法が紐付けられる。登録された監視タスクの夫々は、互いに異なるスレッドで独立して動作を開始する。監視タスクによる処理の内容は後述する。

【0068】

ステップＳ２０１からステップＳ２０３では、監視対象機器９の機器情報が取得される。動作判定部２４は、機器情報リスト２３ａ内の機器情報のうち、動作判定について未判定の機器情報を順番に１つずつ取得する（ステップＳ２０１）。ここで、機器情報が取得できなかった（即ち、全ての機器情報の参照が完了した）場合（ステップＳ２０２のＮＯ）、本フローチャートに示された処理は終了する。一方、参照すべき機器情報が取得された場合（ステップＳ２０２のＹＥＳ）、動作判定部２４は、取得された機器情報に含まれる監視フラグが有効か否かを確認する（ステップＳ２０３）。監視フラグが無効である場合（ステップＳ２０３のＮＯ）、当該機器情報に係る機器は死活監視の対象でないため、監視タスクの登録はスキップされ、処理はステップＳ２０１へ戻る。一方、監視フラグが有効である場合（ステップＳ２０３のＹＥＳ）、当該機器情報に係る機器は死活監視の対象であるため、処理はステップＳ２０４へ進む。

【0069】

ステップＳ２０４からステップＳ２０８では、監視対象機器９の動作判定、及び動作判定の結果に応じた監視タスクの登録が行われる。動作判定部２４は、動作条件リスト２３ｂ内の動作条件を優先度順に１つずつ取得する（ステップＳ２０４）。ここで、動作条件が取得できなかった（即ち、全ての動作条件の判定が完了した）場合（ステップＳ２０５のＮＯ）、当該監視対象機器９に適用すべき動作条件が発見されなかったため、タスク登録部２５は、取得された機器情報の監視対象機器９に対して従来仕様のキープアライブ処理を用いた監視方法（送信頻度が低の機器向け監視方法と同じ監視方法）を設定した監視タスクを登録する（ステップＳ２０８）。

【0070】

一方、動作条件が取得できた場合（ステップＳ２０５のＹＥＳ）、動作判定部２４は、取得された機器情報と動作条件とを照合し、動作条件の判定条件に合致するか否かを確認する（ステップＳ２０６）。本実施形態では、監視対象機器９のＯＳ種別及び用途が、動作条件に設定された判定条件に設定されたＯＳ種別及び用途の組み合わせに合致するか否かが判定される。動作判定部２４は、参照中の動作条件内の判定条件（本実施形態では、ＯＳ種別及び用途）を順に参照し、監視対象機器９のＯＳ種別及び用途のいずれか一方でも、動作条件に設定された判定条件に設定されたＯＳ種別及び用途に合致しない場合、判定結果を「非合致」とする（ステップＳ２０６のＮＯ）。判定結果が「非合致」である場合、処理はステップＳ２０４へ戻り、動作条件リスト２３ｂ内の次の優先度の動作条件が取得され、ステップＳ２０４以降の処理が繰り返される。

【0071】

一方、動作判定部２４は、監視対象機器９のＯＳ種別及び用途が、動作条件に設定された判定条件に設定されたＯＳ種別及び用途の組み合わせに合致する場合に、判定結果を「合致」とする（ステップＳ２０６のＹＥＳ）。判定結果が「合致」である場合、当該監視対象機器９に適用すべき動作条件が発見されたため、タスク登録部２５は、取得された機器情報の監視対象機器９に対して参照中の動作条件（即ち、判定条件が合致した動作条件）に対応する監視方法（本実施形態では、送信頻度が高の機器向け監視方法、送信頻度が中の機器向け監視方法、及び送信頻度が低の機器向け監視方法のいずれか）が設定された監視タスクを登録する（ステップＳ２０７）。登録された監視タスクは、動作判定部２４及びタスク登録部２５から独立して動作を開始し、紐付けられた監視方法に従ってキープアライブ処理部２６に対しキープアライブの送信指示を行う。その後、処理はステップＳ２０１へ戻り、機器情報リスト２３ａ内の次の機器情報が取得され、ステップＳ２０１以降の処理が繰り返される。

【0072】

次に、本実施形態における、監視方法毎の監視処理を説明する。本実施形態では、監視対象機器９のパケット送信頻度（本実施形態では、「期待度：高」、「期待度：中」、及び「期待度：低」の３つ。）に応じて、監視方法が決定される。

【0073】

パケット送信頻度が高い「期待度：高」の監視対象機器９（クライアント端末等）については、所定時間（例えば、キープアライブについて設定される応答タイムアウト時間）内にパケット送信が十分期待できるパケット送信頻度を有しているため、機器が送信するパケットのみに基づいて死活監視を行い、ネットワーク監視装置１からキープアライブを送信しない監視方法（送信頻度が高の機器向け監視方法）が採用される。但し、ｄｅａｄの誤検出を防止するため、応答がなかった場合に最終確認としてキープアライブを送信することとしてもよい。

【0074】

パケット送信頻度が中程度である「期待度：中」の監視対象機器９（ゲートウェイ装置等）については、状況によっては所定時間内にパケット送信がない可能性があるため、機器が送信するパケットの状況に応じて、ネットワーク監視装置１からのキープアライブを抑制的に送信する監視方法（送信頻度が中の機器向け監視方法）が採用される。

【0075】

パケット送信頻度が低い「期待度：低」の監視対象機器９（通信量の少ない特殊な機器等）については、所定時間内にパケット送信が期待できないため、ネットワーク監視装置１から定常的にキープアライブを送信する監視方法（送信頻度が低の機器向け監視方法）が採用される。

【0076】

図１０は、本実施形態に係る、パケット送信頻度が高い監視対象機器９に対する監視処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、登録されて有効化された状態の１又は複数の監視タスク毎に、監視タスクに対する終了指示が受け付けられるまで、常駐スレッドにおいて定期的（例えば、５秒毎）に繰り返し実行される。

【0077】

ステップＳ３０１では、監視期間に該当するか否かが判定される。監視タスクは、参照中の監視タスクに紐付いたタイムテーブルを参照し、現在のシステム日付、時刻及び曜日がタイムテーブルに設定されている監視期間（例えば、８：００から１７：００までの業務時間内）に該当するか否かを判定する。判定の結果、参照中の監視タスクが監視期間に該当しない（即ち、休止期間中である）と判定された場合（ステップＳ３０１のＮＯ）、本フローチャートに示された処理は終了する。一方、判定の結果、参照中の監視タスクが監視期間に該当すると判定された場合（ステップＳ３０１のＹＥＳ）、処理はステップＳ３０２へ進む。

【0078】

ステップＳ３０２からステップＳ３０４では、自発パケットの受信状況に応じて、監視対象機器９の生死状況が設定される。監視タスクは、監視対象機器９から送信された直前の自発パケット受信時刻が現在時刻から所定時間（例えば、応答タイムアウト時間）内である場合に、監視対象機器９からの自発パケットが正常に受信されていると判断する。監視対象機器９からの自発パケットが受信されていないと判定された場合（ステップＳ３０２のＮＯ）、監視タスクは、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にｄｅａｄフラグを設定する（ステップＳ３０３）。

【0079】

一方、監視対象機器９からの自発パケットが正常に受信されていると判定された場合（ステップＳ３０２のＹＥＳ）、監視タスクは、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にａｌｉｖｅフラグを設定する（ステップＳ３０４）。その後、本フローチャートに示された処理は終了する。

【0080】

図１１は、本実施形態に係る、パケット送信頻度が中程度の監視対象機器９に対する監視処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、登録されて有効化された状態の１又は複数の監視タスク毎に、監視タスクに対する終了指示が受け付けられるまで、常駐スレッドにおいて定期的（例えば、５秒毎）に繰り返し実行される。

【0081】

ステップＳ４０１では、監視期間に該当するか否かが判定される。監視タスクは、参照中の監視タスクに紐付いたタイムテーブルを参照し、現在のシステム日付、時刻及び曜日がタイムテーブルに設定されている監視期間に該当するか否かを判定する。判定の結果、参照中の監視タスクが監視期間に該当しない（即ち、休止期間中である）と判定された場合（ステップＳ４０１のＮＯ）、本フローチャートに示された処理は終了する。一方、判定の結果、参照中の監視タスクが監視期間に該当すると判定された場合（ステップＳ４０１のＹＥＳ）、処理はステップＳ４０２へ進む。

【0082】

ステップＳ４０２及びステップＳ４０３では、参照中の監視タスクに係る監視対象機器９からのキープアライブ応答パケットが応答タイムアウトした場合に、監視対象機器９にｄｅａｄフラグが設定される。なお、本実施形態において、キープアライブの送信及び応答パケット受信はキープアライブ処理部２６によって行われる。キープアライブ処理部２６は、キープアライブへの応答パケットが受信された場合、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にａｌｉｖｅフラグを設定し、更に応答パケットの受信時刻を機器情報内の格納域に記録する。監視タスクは、機器情報に記録された受信時刻を参照して、直前のキープアライブ送信時刻からの経過時間が所定の応答タイムアウト時間（例えば、１分）を超えている状態で、キープアライブへの応答パケットを受信できているか否かを判定することで、応答タイムアウトしたか否か判定する（ステップＳ４０２）。応答タイムアウトしたと判断された場合（ステップＳ４０２のＹＥＳ）、監視タスクは、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にｄｅａｄフラグを設定する（ステップＳ４０３）。その後、処理はステップＳ４０４へ進む。

【0083】

一方、直前のキープアライブ送信時刻から応答タイムアウト時間を経過していない場合、又は直前のキープアライブ送信時刻から応答タイムアウト時間内にキープアライブへの応答パケットを受信できている場合（ステップＳ４０２のＮＯ）、監視タスクは、応答タイムアウトしていないと判断する。応答タイムアウトしていないと判断された場合、処理はステップＳ４０４へ進む。

【0084】

ステップＳ４０４からステップＳ４０７では、キープアライブ送信期限に達しており且つ自発パケットが受信できていない監視対象機器９に対して、キープアライブが送信される。監視タスクは、直前のキープアライブ送信時刻からの経過時間がキープアライブ送信インターバル時間（例えば、１分）を超えているか否かを判定し、経過時間がキープアライブ送信インターバル時間を超えている場合に、キープアライブ送信期限に達していると判定する。キープアライブ送信期限に達していると判定された場合（ステップＳ４０４のＹＥＳ）、監視タスクは、更に、自発パケットの受信状況を確認する（ステップＳ４０５）。具体的には、監視タスクは、監視対象機器９から送信された直前の自発パケット受信時刻が現在時刻から所定時間（例えば、応答タイムアウト時間）内である場合に、監視対象機器９からの自発パケットが正常に受信されていると判断する。監視対象機器９からの自発パケットが受信されていないと判定された場合（ステップＳ４０５のＮＯ）、監視タスクは、キープアライブ処理部２６に対してキープアライブ送信指示を行うことで、監視対象機器９に対してキープアライブを送信する（ステップＳ４０６）。指示を受けたキープアライブ処理部２６は、監視対象機器９に対してキープアライブを送信する。この際、当該キープアライブが送信された時刻が、「直前のキープアライブ送信時刻」として記録される。また、上述の通り、キープアライブ処理部２６は、キープアライブへの応答パケットが受信された際に、ａｌｉｖｅフラグを設定する。

【0085】

一方、キープアライブ送信期限に達していないと判定された場合（ステップＳ４０４のＮＯ）、キープアライブの送信は省略され、本フローチャートに示された処理は終了する。また、監視対象機器９からの自発パケットが正常に受信されていると判定された場合（ステップＳ４０５のＹＥＳ）、キープアライブの送信は省略され、監視タスクは、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にａｌｉｖｅフラグを設定する（ステップＳ４０７）。その後、本フローチャートに示された処理は終了する。

【0086】

即ち、上記説明した、パケット送信頻度が中程度の監視対象機器９に対する監視処理によれば、パケット送信頻度が中程度の監視対象機器９からの自発パケットが所定時間内に受信できている間は、当該監視対象機器９はａｌｉｖｅ状態であると判定され、キープアライブは送信されない。パケット送信頻度が中程度の監視対象機器９へのキープアライブは、当該監視対象機器９からの自発パケットが所定時間内に受信できていないと判定された場合に送信される。キープアライブの送信後、応答タイムアウト時間内に応答パケットが受信できた場合には、当該監視対象機器９はａｌｉｖｅ状態であると判定される。自発パケットが所定時間内に受信できず、且つキープアライブへの応答パケットが応答タイムアウト時間内に受信できない場合、当該監視対象機器９はｄｅａｄ状態であると判定される。

【0087】

図１２は、本実施形態に係る、パケット送信頻度が低い監視対象機器９に対する監視処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、登録されて有効化された状態の１又は複数の監視タスク毎に、監視タスクに対する終了指示が受け付けられるまで、常駐スレッドにおいて定期的（例えば、５秒毎）に繰り返し実行される。

【0088】

ステップＳ５０１では、監視期間に該当するか否かが判定される。監視タスクは、参照中の監視タスクに紐付いたタイムテーブルを参照し、現在のシステム日付、時刻及び曜日がタイムテーブルに設定されている監視期間に該当するか否かを判定する。判定の結果、参照中の監視タスクが監視期間に該当しない（即ち、休止期間中である）と判定された場合（ステップＳ５０１のＮＯ）、本フローチャートに示された処理は終了する。一方、判定の結果、参照中の監視タスクが監視期間に該当すると判定された場合（ステップＳ５０１のＹＥＳ）、処理はステップＳ５０２へ進む。

【0089】

ステップＳ５０２及びステップＳ５０３では、参照中の監視タスクに係る監視対象機器９からのキープアライブ応答パケットが応答タイムアウトした場合に、監視対象機器９にｄｅａｄフラグが設定される。なお、本実施形態において、キープアライブの送信及び応答パケット受信はキープアライブ処理部２６によって行われる。キープアライブ処理部２６は、キープアライブへの応答パケットが受信された場合、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にａｌｉｖｅフラグを設定し、更に応答パケットの受信時刻を機器情報内の格納域に記録する。監視タスクは、機器情報に記録された受信時刻を参照して、直前のキープアライブ送信時刻からの経過時間が所定の応答タイムアウト時間（例えば、１分）を超えている状態で、キープアライブへの応答パケットを受信できているか否かを判定することで、応答タイムアウトしたか否か判定する（ステップＳ５０２）。応答タイムアウトしたと判断された場合（ステップＳ５０２のＹＥＳ）、監視タスクは、機器情報リスト２３ａ内の、監視対象機器９に該当する機器情報の状態フラグ域にｄｅａｄフラグを設定する（ステップＳ５０３）。その後、処理はステップＳ５０４へ進む。

【0090】

一方、直前のキープアライブ送信時刻から応答タイムアウト時間を経過していない場合、又は直前のキープアライブ送信時刻から応答タイムアウト時間内にキープアライブへの応答パケットを受信できている場合（ステップＳ５０２のＮＯ）、監視タスクは、応答タイムアウトしていないと判断する。応答タイムアウトしていないと判断された場合、処理はステップＳ５０４へ進む。

【0091】

ステップＳ５０４及びステップＳ５０５では、キープアライブ送信期限に達している監視対象機器９に対して、キープアライブが送信される。監視タスクは、直前のキープアライブ送信時刻からの経過時間がキープアライブ送信インターバル時間（例えば、１分）を超えているか否かを判定し、経過時間がキープアライブ送信インターバル時間を超えている場合に、キープアライブ送信期限に達していると判定する。キープアライブ送信期限に達していると判定された場合（ステップＳ５０４のＹＥＳ）、監視タスクは、キープアライブ処理部２６に対してキープアライブ送信指示を行うことで、監視対象機器９に対してキープアライブを送信する（ステップＳ５０５）。指示を受けたキープアライブ処理部２６は、監視対象機器９に対してキープアライブを送信する。この際、当該キープアライブが送信された時刻が、「直前のキープアライブ送信時刻」として記録される。また、上述の通り、キープアライブ処理部２６は、キープアライブへの応答パケットが受信された際に、ａｌｉｖｅフラグを設定する。

【0092】

一方、キープアライブ送信期限に達していないと判定された場合（ステップＳ５０４のＮＯ）、キープアライブの送信は省略され、本フローチャートに示された処理は終了する。その後、本フローチャートに示された処理は終了する。

【0093】

＜効果＞
上記説明した実施形態によれば、ネットワークを流れるパケットに基づいて自動的に取得された機器の属性等に基づいて、機器毎に異なる監視方法で、キープアライブを抑えた、効率のよい死活監視を行うことが可能となる。

【0094】

＜バリエーション＞
なお、上記説明した実施形態では、監視対象機器９のパケット送信頻度（期待度）に応じて異なる処理フローが採用される例を説明したが、監視対象機器９のパケット送信頻度に応じて監視方法を異らせる方法は、上記説明した例に限定されない。例えば、監視処理のためのプログラムを１つのプログラムとし、監視対象機器９のパケット送信頻度に応じて監視タスクに設定される送信頻度を示すフラグを監視処理プログラムから参照することで、監視対象のパケット送信頻度に応じてキープアライブ送信処理をスキップする等の、異なる監視方法を実現することとしてもよい。

【符号の説明】

【0095】

１ ネットワーク監視装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】