JP4255366B2 - ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 - Google Patents
ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 Download PDFInfo
- Publication number
- JP4255366B2 JP4255366B2 JP2003399937A JP2003399937A JP4255366B2 JP 4255366 B2 JP4255366 B2 JP 4255366B2 JP 2003399937 A JP2003399937 A JP 2003399937A JP 2003399937 A JP2003399937 A JP 2003399937A JP 4255366 B2 JP4255366 B2 JP 4255366B2
- Authority
- JP
- Japan
- Prior art keywords
- network
- failure
- application
- connection
- monitoring
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
- H04L43/0829—Packet loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/18—Protocol analysers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Monitoring And Testing Of Transmission In General (AREA)
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Description
本発明はネットワークの運用状態を監視するためのネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置に関し、特にネットワーク上で発生した障害を検出するネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置に関する。
情報技術の発達に伴い、多くの企業では、コンピュータシステムを使用した業務の効率化が図られている。コンピュータシステムは、ネットワークを介して複数のコンピュータやスイッチ等の複数の通信機器が接続される。そして、コンピュータで行うことができる業務範囲の拡大に伴って、ネットワークが年々大規模化している。
また、システムのアーキテクチャ等のオープン化や規格化に伴って、異なるメーカ製の機器を組み合わせて、ネットワークを構築することが可能となっている。さらに、ネットワーク上の機器のインテリジェント化も進められている。その結果、ネットワークの構成が複雑化している。
このように、大規模で且つ複雑な構成のネットワークでトラブルが発生した場合、個々の装置の動作状況が確認される。ところで、ネットワークにおける障害は、個々の装置の動作状況だけでは判断できない場合が多く存在する。そのため、ネットワーク上の故障箇所や原因を特定するのは、非常に困難な作業である。故障箇所や原因が長期間判明しなければ、ネットワークを利用する顧客の業務が長時間停止してしまう。
そこで、ネットワーク設計情報と、機器の稼働統計情報をとリンクさせたり、ＩＰ（Internet Protocol）層やＡＴＭ（Asynchronous Transfer Mode）層といった異なるプロトコル層をリンクさせたりして、稼働統計情報の一覧を表示する技術が考えられている（たとえば、特許文献１参照）。この技術では、ネットワーク上の機器から定期的に稼働統計情報を収集し、収集した稼働統計情報を指数値と比較する。比較の結果、指数値を超えている場合には、障害の予兆が発生したものと判断する。障害の予兆が検出された場合、予兆を発生させた装置等に関連する稼働統計情報を一覧表示させることで、障害予兆の関係する範囲の特定に役立てている。
特開２００２−９９４６９号公報（段落番号〔００４３〕〜〔００４４〕）
しかし、特許文献１に記載された技術では、障害予兆を自動で検出できるが、その障害の発生箇所や原因はシステム管理者が判断しなければならない。たとえば、ある装置から他の装置に対して送信したデータが届かない場合、従来技術でも、データを送信した装置でエラーを検出することはできる。ところが、データを送信した装置から他の装置までの通信経路上の何処に障害があるのかを、監視システムにおいて自動で判断することはできない。
このように、従来は、各装置における稼働統計情報等から障害の予兆を検出することはできても、実際の障害箇所を特定するのはシステム管理者であった。そのため、障害解析に過大な時間が掛かっていた。しかも、障害発生箇所の特定は大規模なシステムになればなるほど困難となるため、障害解析に要する時間の肥大化が問題となっていた。
また、障害解析を困難にしている要因として、各装置内の機能の複雑化がある。一般に、ネットワーク上の通信機能はレイヤで分かれている。障害に対して対策を施す上で、どの機能で障害が発生しているのかを特定するのは重要である。ところが、従来の技術ではトランスポート層レベルの監視機能はなかった。また、ネットワーク機器の監視機能（ＩＣＭＰ（Internet Control Message Protocol）機能）を利用した監視機能はあったが実際の通信状態の依存関係はなく、誤った判断をする場合があった。そのため、これらの機能の障害を正確に検出することは困難であった。
本発明はこのような点に鑑みてなされたものであり、ネットワーク上での障害発生箇所の切り分けを自動的に行うことができるネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置を提供することを目的とする。
本発明の第１の態様では上記課題を解決するために、図１に示すような機能をコンピュータに実行させるネットワーク監視プログラムが提供される。このネットワーク監視プログラムは、ネットワーク上の障害発生箇所を検出するためのものであり、コンピュータに以下の機能を実行させることができる。
ネットワーク監視プログラムに基づいて動作するコンピュータは、記憶手段１ｄ、通信状況監視手段１ｅ、異常検出手段１ｆ、障害箇所判定手段１ｇおよび障害情報出力手段１ｈを有する。
記憶手段１ｄは、ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブル１ｄａを記憶する。通信状況監視手段１ｅは、ネットワーク上の他の機器との間の通信状況を監視する。異常検出手段１ｆは、通信状況監視手段１ｅで検出された通信内容から異常を示す事象を検出する。障害箇所判定手段１ｇは、障害箇所判定テーブル１ｄａを参照し、異常検出手段１ｆで検出された事象の発生原因となる要素を判定する。障害情報出力手段１ｈは、障害箇所判定手段１ｇでの判定結果を示す障害情報８を出力する。
このようなネットワーク監視プログラムをコンピュータで実行させることにより、通信状況監視手段１ｅにより、ネットワーク上の他の機器との間の通信状況が監視される。そして、異常検出手段１ｆにより、通信状況監視手段１ｅで検出された通信内容から異常を示す事象が検出される。すると、障害箇所判定手段１ｇにより、異常検出手段１ｆで検出された事象の発生原因となる要素が判定される。そして、障害情報出力手段１ｈにより、障害箇所判定手段１ｇでの判定結果を示す障害情報が出力される。
本発明の第２の態様では上記課題を解決するために、ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、コンピュータを、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、を有する前記ネットワーク上の複数の装置から前記障害情報を収集する障害情報収集手段、前記障害情報収集手段が前記複数の装置から収集した前記障害情報に共通する要素を、前記ネットワーク上での障害発生箇所と判断する障害発生箇所絞り込み手段、として機能させることを特徴とするネットワーク監視プログラムが提供される。
このようなネットワーク監視プログラムをコンピュータで実行させると、障害情報収集手段によって、事象の発生原因となる要素の判定機能を有する複数の装置から判定結果を示す障害情報が収集される。そして、障害発生箇所絞り込み手段により、複数の障害情報に共通する要素が、ネットワーク上での障害発生箇所と判断される。
本発明の第３の態様では上記課題を解決するために、ネットワーク上の障害発生箇所を検出するためのネットワーク監視方法において、通信状況監視手段が、前記ネットワーク上の他の機器との間の通信状況を監視し、異常検出手段が、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出し、障害箇所判定手段が、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定し、障害情報出力手段が、前記障害箇所判定手段での判定結果を示す障害情報を出力する、ことを特徴とするネットワーク監視方法が提供される。
このようなネットワーク監視方法によれば、上記第１の態様に係るネットワーク監視プログラムを実行するコンピュータと同様の処理が行われる。
本発明の第４の態様では上記課題を解決するために、ネットワーク上の障害発生箇所を検出するためのネットワーク監視装置において、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、を有することを特徴とするネットワーク監視装置が提供される。
本発明の第４の態様では上記課題を解決するために、ネットワーク上の障害発生箇所を検出するためのネットワーク監視装置において、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、を有することを特徴とするネットワーク監視装置が提供される。
このようなネットワーク監視装置によれば、上記第１の態様に係るネットワーク監視プログラムを実行するコンピュータと同様の処理が行われる。
以上説明したように本発明では、障害の発生原因となり得る要素が予め分類され、分類された要素に対して、通信の異常を示す事象が予め対応付けられているため、通信の異常を示す事象を検出した場合、その事象の障害発生原因となる要素を自動的に判定することができる。その結果、障害の自動回避や早期復旧が可能となる。
以下、本発明の実施の形態を図面を参照して説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
まず、実施の形態に適用される発明の概要について説明し、その後、実施の形態の具体的な内容を説明する。
図１は、実施の形態に適用される発明の概念図である。図１の例では、自装置１がスイッチ（ＳＷ）２に接続されている。ＳＷ２は、ネットワーク３を介して相手装置４に接続されている。ここで、本発明に係るネットワーク監視機能を有する自装置１と相手装置４との間で通信する場合を想定する。
自装置１は、相手装置４との通信やネットワーク監視を行うために、アプリケーション１ａ、通信手段１ｂ、通信インタフェース１ｃ、記憶手段１ｄ、通信状況監視手段１ｅ、異常検出手段１ｆ、障害箇所判定手段１ｇ、および障害情報出力手段１ｈを有する。
アプリケーション１ａは、自装置１内で動作する処理機能である。たとえば、アプリケーション１ａとして、Ｗｅｂサーバ機能などのサーバ機能を実装することができる。通信手段１ｂは、アプリケーション１ａと相手装置４との間のデータ通信を制御する。通信インタフェース１ｃは、接続された伝送路を介した通信を行う。
記憶手段１ｄは、障害箇所判定テーブル１ｄａを記憶する。障害箇所判定テーブル１ｄａは、ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、ネットワークを介した通信の異常を示す事象が対応付けられている。なお、異常を示す事象には、正常な事象の組み合わせ（あるいは累積）によって異常と判断できる事象も含まれる。
障害発生要素の分類方法の１つに、自装置１との間での接続関係に基づいた分類がある。たとえば、ネットワーク上の各機器を、自装置１、隣接伝送路５、非隣接伝送路６、相手装置４に分類する。
また、障害発生要素の他の分類方法として、各装置が有する機能に基づいた分類方法がある。たとえば、各装置で動作するアプリケーション１ａや、通信機能を司る通信手段１ｂ等に分類にすることができる。
通信状況監視手段１ｅは、ネットワーク上の他の機器との間の通信状況を監視する。たとえば、通信状況監視手段１ｅは、通信手段１ｂと通信インタフェース１ｃとの間で受け渡されるパケット７を取得して、その内容を解析する。なお、通信状況の監視は、たとえば、コネクション毎に監視することができる。また、通信状況の監視は、異常な通信に限らず、正常な通信も含めて監視する。たとえば、異常な通信と同時期に行われた正常な通信を監視し、その履歴を記録しておく。このような正常な通信の履歴も障害原因の特定に有効に利用できる。
異常検出手段１ｆは、通信状況監視手段１ｅで検出された通信内容から異常を示す事象を検出する。たとえば、応答遅延、パケットの再送、パケットの重複受信等の事象が検出される。なお、異常を示す事象と同時に、その事象と同時期に発生した正常な事象も検出される。
障害箇所判定手段１ｇは、障害箇所判定テーブル１ｄａを参照し、異常検出手段１ｆで検出された事象の発生原因となる要素を判定する。すなわち、障害箇所判定手段１ｇは、異常検出手段１ｆで検出された事象に該当する事象を、障害箇所判定テーブル１ｄａから検索する。そして、障害箇所判定手段１ｇは、検出した事象に対応付けられている障害発生要素を、事象の発生原因となる要素として判定する。
障害情報出力手段１ｈは、障害箇所判定手段１ｇでの判定結果を示す障害情報８を出力する。
このようなネットワーク監視プログラムによれば、通信状況監視手段１ｅにより、ネットワーク上の他の機器との間の通信状況が監視される。そして、異常検出手段１ｆにより、通信状況監視手段１ｅで検出された通信内容から異常を示す事象が検出される。すると、障害箇所判定手段１ｇにより、異常検出手段１ｆで検出された事象の発生原因となる要素が判定される。そして、障害情報出力手段１ｈにより、障害箇所判定手段１ｇでの判定結果を示す障害情報８が出力される。
このようなネットワーク監視プログラムによれば、通信状況監視手段１ｅにより、ネットワーク上の他の機器との間の通信状況が監視される。そして、異常検出手段１ｆにより、通信状況監視手段１ｅで検出された通信内容から異常を示す事象が検出される。すると、障害箇所判定手段１ｇにより、異常検出手段１ｆで検出された事象の発生原因となる要素が判定される。そして、障害情報出力手段１ｈにより、障害箇所判定手段１ｇでの判定結果を示す障害情報８が出力される。
このようにして、通信の異常を示す事象を検出した場合、その事象の障害発生原因となる要素を自動的に判定することができる。その結果、障害の自動回避や早期復旧が可能となる。
ところで、大規模なネットワーク上では、ネットワーク監視機能を複数のサーバに導入し、且つ、それらを管理する管理サーバと併用することができる。これにより、さらに精度の高い異常監視および、トラブルの自動回避が可能となる。以下、ネットワーク監視機能と管理サーバとを有するネットワーク監視システムの例を、本発明の実施の形態として具体的に説明する。
図２は、ネットワークシステム構成例を示す図である。これは、各種機能および通信路が２重化されたネットワークの例である。この例では、インターネット４１０に、ルータ４２１，４２２が接続されている。ルータ４２１，４２２には、ファイアウォール（ＦＷ）４３１，４３２が接続されている。ＦＷ４３１，４３２には、スイッチ（ＳＷ）４４１，４４２を介して、Ｗｅｂサーバ１００，２１０が接続されている。Ｗｅｂサーバ１００，２１０には、スイッチ（ＳＷ）４４３，４４４を介して、アプリケーション（ＡＰ）サーバ２２０，２３０が接続されている。ＡＰサーバ２２０，２３０には、スイッチ（ＳＷ）４４５，４４６を介して、データベース（ＤＢ）サーバ２４０，２５０が接続されている。
また、ＳＷ４４１，４４３，４４５には、管理サーバ３００が接続されている。なお、ＳＷ４４１〜４４６は、レイヤ３スイッチ（ＯＳＩ参照モデルのネットワーク層（第３層）のデータでパケットの行き先を判断して転送を行うもの）である。
この例では、Ｗｅｂサーバ１００，２１０、アプリケーション（ＡＰ）サーバ２２０，２３０、およびデータベース（ＤＢ）サーバ２４０，２５０に、ネットワーク監視機能が実装されているものとする。ネットワーク監視機能が検出した障害情報は、管理サーバ３００で収集される。管理サーバ３００において、収集した障害情報を解析することで、障害箇所を特定することができる。
たとえば、ＳＷ４４３で障害が発生した場合を考える。この場合、Ｗｅｂサーバ１００において、ＳＷ４４３を経由した通信路での異常を検出できる。また、ＡＰサーバ２２０も同様に、ＳＷ４４３を経由した通信路での異常を検出できる。さらに、ＤＢサーバ２４０において、ＳＷ４４５，４４６を経由した隣接しない通信路での異常を検出できる。各サーバで検出された異常を示す障害情報は、管理サーバ３００に通知される。
管理サーバ３００は、各サーバから通知された障害情報に基づいて、障害箇所を特定する。具体的には、各サーバから収集した障害情報で示される障害発生要素のうち、重複する要素に障害があると判断することができる。この例では、ＳＷ４４３で障害が発生していると判断される。このように、各サーバにネットワーク監視機能を実装することで、的確な障害解析を迅速に、且つ的確に行うことが可能となる。
以下、Ｗｅｂサーバ１００に実装されたネットワーク監視機能を例に採り、ネットワーク監視機能の詳細を説明する。まず、ネットワーク監視機能を実装するために必要なハードウェア構成を説明する。
図３は、本発明の実施の形態に用いるＷｅｂサーバのハードウェア構成例を示す図である。Ｗｅｂサーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および複数の通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄが接続されている。
ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。
グラフィック処理装置１０４には、モニタ９１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ９１の画面に表示させる。入力インタフェース１０５には、キーボード９２とマウス９３とが接続されている。入力インタフェース１０５は、キーボード９２やマウス９３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。
複数の通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄは、それぞれＳＷ４４１〜４４４に接続されている。通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄは、ＳＷ４４１〜４４４を介して、他のコンピュータとの間でデータの送受信を行う。
以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には、Ｗｅｂサーバ１００のハードウェア構成を示したが、管理サーバ３００等の他のサーバも同様のハードウェア構成で実現することができる。
Ｗｅｂサーバ１００に実装されるネットワーク監視機能は、ＯＳのカーネル部分で動作する機能と、カーネルより上位のユーザ部分で動作する機能とに分かれる。
図４は、Ｗｅｂサーバのソフトウェア構成例を示す図である。図４において、ネットワーク監視部１００ａ，１００ｂがネットワーク監視機能を司っている。
図４は、Ｗｅｂサーバのソフトウェア構成例を示す図である。図４において、ネットワーク監視部１００ａ，１００ｂがネットワーク監視機能を司っている。
カーネル内に配置されたネットワーク監視部１００ａは、通信インタフェース（ＮＩＣ）１０６ａ，１０６ｂ，１０６ｃ，１０６ｄとＩＰ／ＡＲＰ（Address Resolution Protocol）１００ｃとの間のドライバ部分に設けられる。すなわち、通信インタフェース（ＮＩＣ）１０６ａ，１０６ｂ，１０６ｃ，１０６ｄとＩＰ／ＡＲＰ１００ｃとの間で受け渡されるパケットは、常にネットワーク監視部１００ａを経由する。また、ネットワーク監視部１００ａは、ＩＰ／ＡＲＰ１００ｃ等のレイヤ３レベル（ネットワーク層）の情報を監視すると共に、ＴＣＰ（Transmission Control Protocol）１００ｄ等のレイヤ４レベル（トランスポート層）のプロトコルでの通信の監視も行う。
ユーザ部分（カーネル以外の部分）に配置されたネットワーク監視部１００ｂは、障害情報収集機能を行うデーモン（バックグラウンドサービス）である。具体的には、ネットワーク監視部１００ｂは、カーネルに配置されたネットワーク監視部１００ａから異常検出通知を受け取って、障害情報１１０に蓄積する。障害情報１１０は、たとえば、ＨＤＤ１０３内の記憶領域に設けられる。また、異常検出通知を受け取った際に、その異常検出通知を障害情報１１０に蓄積すると共に管理サーバ３００へ通知することもできる。
管理サーバ３００は、定期的に障害情報１１０を収集する。管理サーバ３００では、他のサーバからも同様に障害情報を収集する。そして、管理サーバ３００において、障害情報の内容を解析することで、障害箇所が特定できる。
ネットワーク監視部１００ａ，１００ｂは、通信状態を監視するために、次のような機能を有する。
図５は、ネットワーク監視部の機能を示すブロック図である。カーネル側のネットワーク監視部１００ａは、パケット解析部１２０とコネクション監視部１３０とを有する。
図５は、ネットワーク監視部の機能を示すブロック図である。カーネル側のネットワーク監視部１００ａは、パケット解析部１２０とコネクション監視部１３０とを有する。
パケット解析部１２０は、通信パケットの内容を解析する。解析結果は、コネクション監視部１３０に渡される。
コネクション監視部１３０は、パケット解析部１２０から渡された解析結果に基づいて、コネクションの状態を監視し、コネクションの異常等を検出する。コネクションの監視には、コネクション毎のコネクションテーブル１４０，１４０ａ，１４０ｂ，・・・が利用される。コネクションテーブル１４０，１４０ａ，１４０ｂ，・・・には、現在のコネクションの状態やエラー等の発生状況が記録される。
コネクション監視部１３０は、パケット解析部１２０から渡された解析結果に基づいて、コネクションの状態を監視し、コネクションの異常等を検出する。コネクションの監視には、コネクション毎のコネクションテーブル１４０，１４０ａ，１４０ｂ，・・・が利用される。コネクションテーブル１４０，１４０ａ，１４０ｂ，・・・には、現在のコネクションの状態やエラー等の発生状況が記録される。
たとえば、コネクションテーブル１４０には、コネクション管理テーブル１４１、送信監視テーブル１４２、受信監視テーブル１４３が設けられる。コネクション管理テーブル１４１は、コネクションの接続相手を示す情報や、そのコネクションでの異常の発生状況などが登録される。送信監視テーブル１４２には、Ｗｅｂサーバ１００から送信されるパケットの異常の有無を監視するための情報が逐次登録される。受信監視テーブル１４３には、Ｗｅｂサーバ１００が受信したパケットの異常の有無を監視するための情報が逐次登録される。
ユーザ部分に配置されたネットワーク監視部１００ｂは、トラブル事象ＤＢ１５０と障害判定部１６０とを有する。トラブル事象ＤＢ１５０には、障害発生条件（障害の発生を示す１以上の事象）と、その条件を満たしたときの障害発生箇所（障害を生じさせた要素）とが予め登録されている。
障害判定部１６０は、コネクションテーブル１４０，１４０ａ，１４０ｂ，・・・を参照して、エラー等の異常発生内容に基づいて、異常箇所推定テーブル１７０にエラー発生状況を設定する。異常箇所推定テーブル１７０には、コネクション毎に、発生した異常の内容や発生回数が登録される。障害判定部１６０は、異常箇所推定テーブル１７０の内容と、トラブル事象ＤＢ１５０に登録されている障害発生条件とを照合し、障害発生条件を満たしたコネクションを検出する。障害判定部１６０は、障害発生条件を満たしたコネクションが有る場合、検出された障害の内容を障害情報１１０に記録する。
次に、トラブル事象ＤＢ１５０に登録される情報について詳細に説明する。トラブル事象ＤＢ１５０には、障害の内容に応じて、その障害の発生箇所を示す情報が登録されている。ここで、障害の発生箇所を示す情報には、障害を生じさせたハードウェアを示す情報と、障害を生じさせたソフトウェアを示す情報とがある。
障害を生じさせたハードウェアを示す情報は、Ｗｅｂサーバ１００との間の接続関係に基づいて、障害発生箇所の区分けが行われている。
図６は、障害発生箇所のハードウェア的な区分けを示す図である。障害発生箇所を示す領域は、自装置１１、隣接伝送路１２、非隣接伝送路１３、および相手装置１４に分けられる。自装置１１での障害とは、Ｗｅｂサーバ１００自身の装置内で発生した障害であるが、通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄで発生した障害は除く。隣接伝送路１２で発生した障害とは、通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄからＳＷ４４３，４４４との間の通信機能で発生した障害である。非隣接伝送路１３で発生した障害とは、ＳＷ４４３，４４４と通信相手の装置（たとえば、ＤＢサーバ２４０）との間の通信機能で発生した障害である。相手装置１４で発生した障害とは、通信相手の装置（たとえば、ＤＢサーバ２４０）で発生した障害である。
図６は、障害発生箇所のハードウェア的な区分けを示す図である。障害発生箇所を示す領域は、自装置１１、隣接伝送路１２、非隣接伝送路１３、および相手装置１４に分けられる。自装置１１での障害とは、Ｗｅｂサーバ１００自身の装置内で発生した障害であるが、通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄで発生した障害は除く。隣接伝送路１２で発生した障害とは、通信インタフェース１０６ａ，１０６ｂ，１０６ｃ，１０６ｄからＳＷ４４３，４４４との間の通信機能で発生した障害である。非隣接伝送路１３で発生した障害とは、ＳＷ４４３，４４４と通信相手の装置（たとえば、ＤＢサーバ２４０）との間の通信機能で発生した障害である。相手装置１４で発生した障害とは、通信相手の装置（たとえば、ＤＢサーバ２４０）で発生した障害である。
また、障害を生じさせたソフトウェアを示す情報は、通信プログラムの階層で区分けされている。
図７は、障害発生箇所のソフトウェア的な区分けを示す図である。図７の例では、Ｗｅｂサーバ１００において、Ｗｅｂサーバ機能２１に加えてＤＢサーバ機能２２が実装されている場合を想定している。ここで、伝送路３１，３２を介して受け取ったパケットは、レイヤ３（ネットワーク層）の通信機能２３とレイヤ４（トランスポート層）の通信機能２４を介してＷｅｂサーバ機能２１やＤＢサーバ機能２２に渡される。
図７は、障害発生箇所のソフトウェア的な区分けを示す図である。図７の例では、Ｗｅｂサーバ１００において、Ｗｅｂサーバ機能２１に加えてＤＢサーバ機能２２が実装されている場合を想定している。ここで、伝送路３１，３２を介して受け取ったパケットは、レイヤ３（ネットワーク層）の通信機能２３とレイヤ４（トランスポート層）の通信機能２４を介してＷｅｂサーバ機能２１やＤＢサーバ機能２２に渡される。
このとき、レイヤ３の通信機能２３で発生した障害、レイヤ４の通信機能２４で発生した障害、あるいは、Ｗｅｂサーバ機能２１やＤＢサーバ機能２２等のアプリケーション機能で発生した障害とが区分けされる。たとえば、ＤＢサーバ機能２２に障害がある場合、Ｗｅｂサーバ機能２１やＤＢサーバ機能２２に対応するポートを監視していれば、Ｗｅｂサーバ機能２１に対する通信は正常に行えているが、ＤＢサーバ機能２２に対する通信が正常に行えないことが分かる。すると、通信機能２３，２４は正常であるが、ＤＢサーバ機能２２に異常があることを、容易に推定できる。
このような障害発生箇所の判断を行うために、トラブル事象ＤＢ１５０には、障害の検知条件に対応付けてハードウェア的な障害発生箇所またはソフトウェア的な障害発生箇所を示す情報が登録されている。
図８は、トラブル事象ＤＢのデータ構造例を示す図である。トラブル事象ＤＢ１５０には、障害発生機器分類テーブル１５１と障害発生機能分類テーブル１５２とが設けられている。
障害発生機器分類テーブル１５１には、障害の検知条件と、その障害のハードウェア的な発生箇所を示す情報とが登録されている。具体的には、障害発生機器分類テーブル１５１には、検知条件の欄と障害発生機器の欄とが設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられている。
検知条件の欄には、障害発生と認定するための条件が設定されている。障害発生機器の欄には、障害を発生させた機器が属する領域が示されている。たとえば、自装置、隣接伝送路、非隣接伝送路、相手装置等である。
障害発生機器分類テーブル１５１を参照することで、障害発生箇所の切り分けが可能である。たとえば、コネクション監視部１３０において、自分側の通信インタフェース、ＩＰアドレス、ポート番号、相手側の通信インタフェース、ＩＰアドレス、ポート番号をモニタする。そして、コネクションの有無（確立状態）の情報を取得する。さらに障害判定部１６０が、再送パケットの有無、重複受信パケットの有無、データの欠落の有無、Ａｃｋ（確認応答）の応答時間、リセット信号をモニタし統計的に処理する。これによって、自側サーバ、隣接伝送路、伝送路、特定相手サーバのどの箇所でトラブルが発生しているか切り分けを行う。
障害発生例１：自側Ａｃｋの応答時間が基準値より大きかった場合、コネクション監視部１３０が応答遅延を検出する。すると、障害判定部１６０が障害発生機器分類テーブル１５１の１番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機器として「自装置」が登録されているため、障害判定部１６０は自側サーバに何かしら問題があると判断する。
障害発生例２：自側サーバの通信インタフェースに対するコネクションすべてに異常（再送パケット、重複受信パケット、データの欠落、応答遅延）があるとき、コネクション監視部１３０がコネクション異常を検出する。すると、障害判定部１６０が障害発生機器分類テーブル１５１の２番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機器として「隣接伝送路」が登録されているため、障害判定部１６０は隣接している伝送路が故障していると判断する。
障害発生例３：一部のコネクションにおいて、不特定のＩＰアドレス、ポートで異常が発生した場合、コネクション監視部１３０がそれらのコネクション異常を検出する。すると、障害判定部１６０が障害発生機器分類テーブル１５１の３番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機器として「非隣接伝送路」が登録されているため、隣接していない伝送路中にエラーが発生したとして判断する。
障害発生例４：コネクション確立時に、特定相手ＩＰアドレス、ポートで障害が発生している場合、コネクション監視部１３０がそれらのコネクション異常を検出する。すると、障害判定部１６０が障害発生機器分類テーブル１５１の４番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機器として「相手装置」が登録されているため、障害判定部１６０は通信相手のサーバが故障していると判断する。
このように、障害発生機器分類テーブル１５１に基づいて、障害発生箇所をハードウェア的に分類することができる。
障害発生機能分類テーブル１５２には、障害の検知条件と、その障害のソフトウェア的な発生箇所を示す情報とが登録されている。具体的には、障害発生機能分類テーブル１５２には、検知条件の欄と障害発生機能の欄とが設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられている。
障害発生機能分類テーブル１５２には、障害の検知条件と、その障害のソフトウェア的な発生箇所を示す情報とが登録されている。具体的には、障害発生機能分類テーブル１５２には、検知条件の欄と障害発生機能の欄とが設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられている。
検知条件の欄には、障害発生と認定するための条件が設定されている。障害発生機能の欄には、障害を発生させた機能が属する領域が示されている。たとえば、アプリケーションやネットワーク監視部等である。
障害発生機能分類テーブル１５２を参照することで、障害発生箇所の切り分けが可能である。すなわち、コネクション監視部１３０が、特定の１レイヤだけではなく、複数レイヤの情報を総合的に判断し、監視する。そして、障害判定部１６０が、監視結果と障害発生機能分類テーブル１５２とを比較することで、以下のような部分障害に関しても、検知することができる。
障害発生例５：ＩＰレベルではコネクションが確立されているが、ポート毎にはコネクションが確立されていない場合、コネクション監視部１３０がそれらのコネクション異常を検出する。すると、障害判定部１６０が障害発生機能分類テーブル１５２の１番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機能として「アプリケーション」が登録されているため、障害判定部１６０はアプリケーションで障害が発生していると判断できる。
障害発生例６：自側と相手側で正常にコネクションが確立されている状況で、ネットワーク機器の監視機能（ＩＣＭＰ機能）に異常があり、pingコマンドによる応答がないような場合、コネクション監視部１３０がそれらのコネクション異常を検出する。すると、障害判定部１６０が障害発生機能分類テーブル１５２の２番目のレコードに基づいて障害を検出する。このとき、該当レコードの障害発生機能として「ネットワーク監視部」が登録されているため、障害判定部１６０はネットワーク機器のＩＣＭＰ機能の部分故障と判断できる。
このように、複数のレイヤを監視した結果に基づいて障害箇所を総合的に判断するため、アプリケーションレベルの障害かネットワーク監視部の障害かを切り分けることができるようになる。
なお、障害判定部１６０における障害検出では、一般的に障害と認識される前の段階の予兆を検出することもできる。たとえば、ネットワークは自立制御されているために、ＴＣＰレベルで問題（再送等）が起こっていても自動復旧してしまい、障害は検知されない。ところが、障害発生の予兆として、ＴＣＰレベルで問題（再送等）が頻発する場合もある。従来は、ＴＣＰレベルで問題（再送等）に基づく障害検出が行われていないため、通常管理者は重大な問題が発生するまでシステムに異常があることを認識できなかった。
そこで、本実施の形態に係るコネクション監視部１３０は、ＴＣＰレベルで自動復旧（再送等）しているような、通常では確認することのできない情報をモニタする。そして、障害判定部１６０は、モニタされた情報に基づいてトラブルの予兆推定を行う。
図９は、トラブル予兆推定例を示す図である。たとえば、Ｗｅｂサーバ１００からＡＰサーバ２２０に対して送信されるパケットが一度で届かずに再送された場合を考える。
通常、Ｗｅｂサーバ１００からＡＰサーバ２２０への再送が発生していても異常が発生していないと考えられている。しかし、Ｗｅｂサーバ１００からＡＰサーバ２２０へのパケットの再送が発生しているということは、伝送路またはサーバでパケットが失われたことを意味している。この頻度が高くなると重大なトラブルに発展してしまう。たとえば、Ｗｅｂサーバ１００からＡＰサーバ２２０へ頻繁に再送パケットが送られていれば、ＡＰサーバ２２０でＣＰＵ等の能力不足などが発生し始めている場合が考えられる。このようなトラブルの予兆を検出して障害情報として管理者に通知すれば、重大なトラブルが発生する前に対処が可能となる。
通常、Ｗｅｂサーバ１００からＡＰサーバ２２０への再送が発生していても異常が発生していないと考えられている。しかし、Ｗｅｂサーバ１００からＡＰサーバ２２０へのパケットの再送が発生しているということは、伝送路またはサーバでパケットが失われたことを意味している。この頻度が高くなると重大なトラブルに発展してしまう。たとえば、Ｗｅｂサーバ１００からＡＰサーバ２２０へ頻繁に再送パケットが送られていれば、ＡＰサーバ２２０でＣＰＵ等の能力不足などが発生し始めている場合が考えられる。このようなトラブルの予兆を検出して障害情報として管理者に通知すれば、重大なトラブルが発生する前に対処が可能となる。
以下、障害やその予兆を検出するための処理手順について説明する。
図１０は、ネットワーク監視処理手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。なお、以下の処理は、他の装置との間の通信が行われる毎に実行される。
図１０は、ネットワーク監視処理手順を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。なお、以下の処理は、他の装置との間の通信が行われる毎に実行される。
［ステップＳ１１］パケット解析部１２０は、コネクションをキャプチャする。すなわち、他の装置との間でのコネクション確立から、そのコネクションを介して伝送されたパケットを取得する。
［ステップＳ１２］パケット解析部１２０は、キャプチャしたパケットのＴＣＰやＩＰのヘッダを抽出する。
［ステップＳ１３］パケット解析部１２０は、抽出したヘッダ情報を解析する。この処理の詳細は後述する。
［ステップＳ１３］パケット解析部１２０は、抽出したヘッダ情報を解析する。この処理の詳細は後述する。
［ステップＳ１４］コネクション監視部１３０は、初回のイベントか否かを判断する。該当コネクションに対応する更新中のコネクションテーブルが設けられていなければ、初回のイベントであると判断できる。初回のイベントの場合、処理がステップＳ１５に進められる。そうでなければ、処理がステップＳ１６に進められる。
［ステップＳ１５］コネクション監視部１３０は、コネクションテーブルの内容に基づいて検出される障害情報を、一定時間後に障害情報１１０にマージ（追加統合）するように、該当するコネクションテーブルの状態を設定する。
［ステップＳ１６］障害判定部１６０は、コネクションテーブル１４０に基づいて障害を検出し、その結果に基づいて障害情報１１０を更新（マージ）する。この処理の詳細は後述する。
次に、ヘッダ情報の解析処理について詳細に説明する。
図１１は、ヘッダ情報解析処理の手順を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
図１１は、ヘッダ情報解析処理の手順を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ２１］コネクション監視部１３０は、取得したパケットに対応するコネクションテーブルが存在するか否かを判断する。コネクションテーブルが存在すれば、処理がステップＳ２３に進められる。コネクションテーブルが存在しなければ、処理がステップＳ２２に進められる。
［ステップＳ２２］コネクション監視部１３０は、ＩＰアドレス、ポート番号の組み合わせに対応付けたコネクションテーブルを生成する。生成されたコネクションテーブルは、たとえば、ＲＡＭ１０２内の記憶領域に格納される。
［ステップＳ２３］コネクション監視部１３０は、応答（Ａｃｋ）の番号、シーケンス番号、データ長より、再送、重複受信、遅延、パケットロストを検出する。検出した結果は、コネクションテーブルに登録される。その後、図１０に示す処理に戻り、ステップＳ１４に処理が進められる。
次に、特定のコネクションによって送受信されるパケットに基づいたコネクションテーブルの作成例を具体的に説明する。
図１２は、コネクション上での通信例を示す図である。図１２は、Ｗｅｂサーバ１００に実装されたネットワーク監視機能によって、ＡＰサーバ２２０との間で確立したコネクションを監視した場合の例を示している。ここで、Ｗｅｂサーバ１００のＩＰアドレスは「192.168.10.10」であり、Ｗｅｂサーバとして機能を提供するアプリケーションのポート番号は「80」である。また、ＡＰサーバ２２０のＩＰアドレスは「192.168.10.20」であり、処理機能を提供するアプリケーションのポート番号は「10000」である。
図１２は、コネクション上での通信例を示す図である。図１２は、Ｗｅｂサーバ１００に実装されたネットワーク監視機能によって、ＡＰサーバ２２０との間で確立したコネクションを監視した場合の例を示している。ここで、Ｗｅｂサーバ１００のＩＰアドレスは「192.168.10.10」であり、Ｗｅｂサーバとして機能を提供するアプリケーションのポート番号は「80」である。また、ＡＰサーバ２２０のＩＰアドレスは「192.168.10.20」であり、処理機能を提供するアプリケーションのポート番号は「10000」である。
ここで、Ｗｅｂサーバ１００とＡＰサーバ２２０との間で受け渡されるパケット４０〜４５に着目する。ここで、パケット４０〜４５の内容について、図１３を参照して説明する。なお、パケット４４は、何らかの障害により正しく伝送されなかったものとする。
図１３は、Ｗｅｂサーバ側のパケットの内容を示す図である。この図には、パケット４０〜４５について、Ｗｅｂサーバ１００が認識した通信状態（正常か異常か）、Ｗｅｂサーバ１００におけるパケットの送受信の時間（監視開始からの時間）、ＳＲＣ−ＩＰ（送信元のＩＰアドレス）、ＳＲＣ−Ｐｏｒｔ（送信元のポート番号）、ＤＳＴ−ＩＰ（宛先のＩＰアドレス）、ＤＳＴ−Ｐｏｒｔ（宛先のポート番号）、Sequence no（シーケンス番号）、Ack no（応答番号）、Data Len（データ長）が示されている。
パケット４０は、状態が正常、時間が０．５秒、ＳＲＣ−ＩＰが「192.168.10.20」、ＳＲＣ−Ｐｏｒｔが「10000」、ＤＳＴ−ＩＰが「192.168.10.10」、ＤＳＴ−Ｐｏｒｔが「80」、Sequence noが「1900」、Ack noが「1000」、Data Lenが１００バイトである。
パケット４１は、状態が正常、時間が１．０秒、ＳＲＣ−ＩＰが「192.168.10.10」、ＳＲＣ−Ｐｏｒｔが「80」、ＤＳＴ−ＩＰが「192.168.10.20」、ＤＳＴ−Ｐｏｒｔが「10000」、Sequence noが「1000」、Ack noが「2000」、Data Lenが１０バイトである。
パケット４２は、状態が正常、時間が２．５秒、ＳＲＣ−ＩＰが「192.168.10.20」、ＳＲＣ−Ｐｏｒｔが「10000」、ＤＳＴ−ＩＰが「192.168.10.10」、ＤＳＴ−Ｐｏｒｔが「80」、Sequence noが「2000」、Ack noが「1010」、Data Lenが０バイトである。
パケット４３は、状態が正常、時間が３．０秒、ＳＲＣ−ＩＰが「192.168.10.10」、ＳＲＣ−Ｐｏｒｔが「８０」、ＤＳＴ−ＩＰが「192.168.10.20」、ＤＳＴ−Ｐｏｒｔが「10000」、Sequence noが「1010」、Ack noが「2000」、Data Lenが２０バイトである。
パケット４４は、何らかの理由でＷｅｂサーバ１００に到達できなかったパケットである。そのため、図１３では状態と時間との欄が空欄となっている。パケット４４の内容はＳＲＣ−ＩＰが「192.168.10.20」、ＳＲＣ−Ｐｏｒｔが「10000」、ＤＳＴ−ＩＰが「192.168.10.10」、ＤＳＴ−Ｐｏｒｔが「80」、Sequence noが「2000」、Ack noが「1030」、Data Lenが１００バイトであるが、このパケット４４はＷｅｂサーバ１００に到達しない。そのため、Ｗｅｂサーバ１００側では、ＴＣＰプロトコルの機能により、パケット４３と同様の内容のパケット４５が再送される。
パケット４５は、状態が異常、時間が６．０秒、ＳＲＣ−ＩＰが「192.168.10.10」、ＳＲＣ−Ｐｏｒｔが「８０」、ＤＳＴ−ＩＰが「192.168.10.20」、ＤＳＴ−Ｐｏｒｔが「10000」、Sequence noが「1010」、Ack noが「2000」、Data Lenが２０バイトである。
Ｗｅｂサーバ１００のパケット解析部１２０は、実際に入出力されたパケット４１〜４３，４５のヘッダ情報を解析して、それらの情報（図１３に示す情報）をコネクション監視部１３０に渡す。コネクション監視部１３０は、受け取った情報に基づいてコネクションテーブル１４０を作成する。コネクションテーブル１４０は、図５に示すようにコネクション管理テーブル１４１、送信監視テーブル１４２、および受信監視テーブル１４３で構成される。これらのテーブルのデータ構造例を以下に示す。
図１４は、コネクション管理テーブルのデータ構造例を示す図である。コネクション管理テーブル１４１には、インタフェース名、自側ＩＰ、自側Ｐｏｒｔ、相手側ＩＰ、相手側Ｐｏｒｔ、再送カウンタ、重複受信カウンタ、パケットロストカウンタ、応答遅延カウンタ、パケットサイズカウンタ、パケット数カウンタ、相手側応答時間基準、および自側応答時間基準が登録されている。
インタフェース名は、コネクションを確立した通信インタフェースの識別情報である。図１４の例では、インタフェース名は「hme0」である。
自側ＩＰは、自分のＩＰアドレスである。図１４の例では、ＩＰアドレスは「192.168.10.10」である。
自側ＩＰは、自分のＩＰアドレスである。図１４の例では、ＩＰアドレスは「192.168.10.10」である。
自側Ｐｏｒｔは、コネクション使用するアプリケーションのポート番号である。図１４の例では、ポート番号は「80」である。
相手側ＩＰは、通信相手側の装置のＩＰアドレスである。図１４の例では、相手側のＩＰアドレスは「192.168.10.20」である。
相手側ＩＰは、通信相手側の装置のＩＰアドレスである。図１４の例では、相手側のＩＰアドレスは「192.168.10.20」である。
相手側Ｐｏｒｔは、コネクションを使用して通信する相手側のアプリケーションのポート番号である。図１４の例では、相手側アプリケーションのポート番号は「10000」である。
再送カウンタは、パケットの再送を行った回数である。図１４の例では、パケットの再送を１回行っている。
重複受信カウンタは、同一パケットを重複して受け取った回数である。図１４の例では、パケットの重複受信は発生していない。
重複受信カウンタは、同一パケットを重複して受け取った回数である。図１４の例では、パケットの重複受信は発生していない。
パケットロストカウンタは、パケットを紛失した回数である。図１４の例では、パケットロストは発生していない。
応答遅延カウンタは、自装置においてパケットを受信してから通信相手に応答を返すまでの時間が基準値を超えてしまった回数である。自装置の処理負荷が過大である場合に、応答の遅延が発生する。そのために応答遅延の発生回数をカウントすることで、自装置の処理負荷の増大による障害の発生を検知できる。図１４の例では、応答遅延は発生していない。
応答遅延カウンタは、自装置においてパケットを受信してから通信相手に応答を返すまでの時間が基準値を超えてしまった回数である。自装置の処理負荷が過大である場合に、応答の遅延が発生する。そのために応答遅延の発生回数をカウントすることで、自装置の処理負荷の増大による障害の発生を検知できる。図１４の例では、応答遅延は発生していない。
パケットサイズカウンタは、受信したパケットサイズのトータルを示している。図１４の例では、パケットサイズカウンタの値は「０」である。
パケット数カウンタは、送受信したパケットの総数を示すカウンタである。図１４の例では、パケット数カウンタの値は「０」である。
パケット数カウンタは、送受信したパケットの総数を示すカウンタである。図１４の例では、パケット数カウンタの値は「０」である。
相手側応答時間基準は、相手側から応答の待ち時間である。この時間だけ待っても応答がない場合、応答遅延と判定され、応答遅延カウンタをカウントアップする。図１４の例では、相手側応答時間基準は、「１．５秒」である。
自側応答時間基準は、自分が相手に応答を返すときの許容時間である。この時間内に応答が返せない場合、応答遅延が検出される。図１４の例では、自側応答時間基準は、「０．５秒」である。
図１５は、送信監視テーブルのデータ構造例を示す図である。送信監視テーブル１４２には、シーケンス番号予測、時間、相手側応答時間の欄が設けられている。
シーケンス番号予測の欄には、相手装置に対して次に送信されるパケットのシーケンス番号の予測値が設定される。前回送信されたパケットのシーケンス番号にデータ長を加えた値がシーケンス番号の予測値となる。次に送信されたパケットのシーケンス番号がシーケンス番号予測値より小さければ、パケットの再送が行われたことが分かる。
シーケンス番号予測の欄には、相手装置に対して次に送信されるパケットのシーケンス番号の予測値が設定される。前回送信されたパケットのシーケンス番号にデータ長を加えた値がシーケンス番号の予測値となる。次に送信されたパケットのシーケンス番号がシーケンス番号予測値より小さければ、パケットの再送が行われたことが分かる。
時間は、自側でパケットを送信した時間（コネクションの監視を開始してからの経過時間）である。相手側応答時間は、パケットを送信した時刻から、そのパケットに対する通信相手からの応答を受け取った時刻までの経過時間である。
図１６は、受信監視テーブルのデータ構造例を示す図である。受信監視テーブル１４３には、シーケンス番号予測、時間、自側応答時間の欄が設けられている。
シーケンス番号予測の欄には、相手装置から次に受信するパケットのシーケンス番号の予測値が設定される。前回受信したパケットのシーケンス番号にデータ長を加えた値がシーケンス番号の予測値となる。次に受信したパケットのシーケンス番号がシーケンス番号予測値より小さければ、パケットの重複受信であることが分かる。
シーケンス番号予測の欄には、相手装置から次に受信するパケットのシーケンス番号の予測値が設定される。前回受信したパケットのシーケンス番号にデータ長を加えた値がシーケンス番号の予測値となる。次に受信したパケットのシーケンス番号がシーケンス番号予測値より小さければ、パケットの重複受信であることが分かる。
時間は、相手側からパケットを受信した時間（コネクションの監視を開始してからの経過時間）である。自側応答時間は、パケットを受信した時刻から、そのパケットに対して自側の装置が応答するまでの経過時間である。
次に、図１２に示す通信（パケットの内容は図１３に示す）が行われたときの送信監視テーブル１４２と受信監視テーブル１４３との状態遷移について説明する。
図１７は、送信監視テーブルと受信監視テーブルとの状態遷移を示す第１の図である。
図１７は、送信監視テーブルと受信監視テーブルとの状態遷移を示す第１の図である。
状態ＳＴ１は、図１２に示すパケット４０の受信直後（時間０．５）の状態である。Ｗｅｂサーバ１００がパケット４０を受信すると、コネクション監視部１３０が受信側のシーケンス番号を予測し、受信監視テーブル１４３にレコードを追加する。
図１７の例では、シーケンス番号予測の欄に「2000」（パケット４０のシーケンス番号「1900」にデータ長「100」を加えた値）が設定され、時間の欄に「０．５」が設定されている。
状態ＳＴ２は、図１２に示すパケット４１の送信直後（時間１．０）の状態である。Ｗｅｂサーバ１００がパケット４１を送信すると、コネクション監視部１３０が送信側のシーケンス番号を予測し、送信監視テーブル１４２にレコードを追加する。同時に、コネクション監視部１３０は、受信監視テーブル１４３の自側応答時間の欄に値を設定する。
図１７の例では、送信監視テーブル１４２のシーケンス番号予測の欄に「1010」（パケット４１のシーケンス番号「1000」にデータ長「10」を加えた値）が設定され、時間の欄に「１．０」が設定されている。また、受信監視テーブル１４３の自側応答時間の欄に、「０．５」（送信監視テーブル１４２の時間「１．０」から受信監視テーブル１４３の時間「０．５」を減算した値）が設定されている。
状態ＳＴ３は、図１２に示すパケット４２の受信直後（時間２．５）の状態である。Ｗｅｂサーバ１００がパケット４２を受信すると、コネクション監視部１３０が受信側のシーケンス番号を予測し、受信監視テーブル１４３を更新する。同時にコネクション監視部１３０は、送信監視テーブル１４２の相手側応答時間の欄に値を設定する。
図１７の例では、受信監視テーブル１４３のシーケンス番号予測の欄に「2000」（パケット４２のシーケンス番号「2000」にデータ長「0」を加えた値）が設定され、時間の欄に「２．５」が設定されている。また、送信監視テーブル１４２の相手側応答時間の欄に「１．５」（受信監視テーブル１４３の時間「２．５」から送信監視テーブルの時間「１．０」を減算した値）が設定されている。
なお、パケット４２のシーケンス番号は、事前に予測されていたシーケンス番号と一致するため、異常が起こっていないと判断される。
図１８は、送信監視テーブルと受信監視テーブルとの状態遷移を示す第２の図である。
図１８は、送信監視テーブルと受信監視テーブルとの状態遷移を示す第２の図である。
状態ＳＴ４は、図１２に示すパケット４３の送信直後（時間３．０）の状態である。Ｗｅｂサーバ１００がパケット４３を送信すると、コネクション監視部１３０が送信側のシーケンス番号を予測し、送信監視テーブル１４２を更新する。同時に、コネクション監視部１３０は、受信監視テーブル１４３の自側応答時間の欄に値を設定する。
図１８の例では、送信監視テーブル１４２の新たなレコードとして、シーケンス番号予測の欄に「1030」（パケット４３のシーケンス番号「1010」にデータ長「20」を加えた値）が設定され、時間の欄に「３．０」が設定されている。また、受信監視テーブル１４３の自側応答時間の欄に、「０．５」（送信監視テーブル１４２に新たに設定された時間「３．０」から受信監視テーブル１４３の時間「２．５」を減算した値）が設定されている。
なお、パケット４３のシーケンス番号は、事前に予測されていたシーケンス番号と一致するため、異常が起こっていないと判断される。
状態ＳＴ５は、図１２に示すパケット４５の送信直後（時間６．０）の状態である。Ｗｅｂサーバ１００がパケット４５を送信すると、コネクション監視部１３０が送信側のシーケンス番号を予測し、送信監視テーブル１４２を更新する。
状態ＳＴ５は、図１２に示すパケット４５の送信直後（時間６．０）の状態である。Ｗｅｂサーバ１００がパケット４５を送信すると、コネクション監視部１３０が送信側のシーケンス番号を予測し、送信監視テーブル１４２を更新する。
図１８の例では、送信監視テーブル１４２のシーケンス番号予測の欄に「1030」（パケット４５のシーケンス番号「1010」にデータ長「20」を加えた値）が設定され、時間の欄に「６．０」が設定されている。
ここで、パケット４５の送信を検出したコネクション監視部１３０は、パケット４５のシーケンス番号「1010」が、送信監視テーブル１４２に既に設定されていたシーケンス番号予測「1030」よりも小さいことを検出する。これにより、コネクション監視部１３０はパケット４５が再送用のパケットであると判断する。すると、コネクション監視部１３０は、コネクション管理テーブル１４１の再送カウンタの値をカウントアップする。
このようにしてコネクションテーブル１４０が更新される。そして、障害判定部１６０は、コネクションテーブル１４０内の情報に基づいて、各コネクションでの障害の発生の有無を判断する。そして、障害判定部１６０は、障害を検出すると障害情報を更新する。
図１９は、障害情報更新処理の手順を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
［ステップＳ３１］障害判定部１６０は、コネクション情報を解析する。この処理の詳細は後述する。
［ステップＳ３１］障害判定部１６０は、コネクション情報を解析する。この処理の詳細は後述する。
［ステップＳ３２］障害判定部１６０は、障害推定結果を障害情報に登録する。
図２０は、コネクション情報解析処理の手順を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
図２０は、コネクション情報解析処理の手順を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。
［ステップＳ４１］障害判定部１６０は、発生した全コネクションのイベントを集計する。
［ステップＳ４２］障害判定部１６０は異常箇所推定テーブル１７０を生成し、集計結果をコード化する（以下、コード化された情報をステータスコードと呼ぶ）。
［ステップＳ４２］障害判定部１６０は異常箇所推定テーブル１７０を生成し、集計結果をコード化する（以下、コード化された情報をステータスコードと呼ぶ）。
［ステップＳ４３］障害判定部１６０は、ステータスコードに基づいて、トラブル事象ＤＢ１５０を検索する。
［ステップＳ４４］障害判定部１６０は、トラブル事象ＤＢ１５０内に該当するトラブル事象を検出し、トラブル箇所や原因を判断する。
［ステップＳ４４］障害判定部１６０は、トラブル事象ＤＢ１５０内に該当するトラブル事象を検出し、トラブル箇所や原因を判断する。
図２１は、異常箇所推定テーブルのデータ構造例を示す図である。異常箇所推定テーブル１７０には、コネクション、正常、異常の欄が設けられている。各欄の横方向に並べられた情報同士が互いに関連づけられている。
コネクションの欄には、各コネクションを一意に識別するための識別情報が設定される。正常の欄には、正常に通信されたパケットの数が設定される。異常の欄には、異常（イベント）が検出されたときのそのイベントの種別と回数とが設定される。
図２１の例では、異常の欄に、イベントの種別として、再送、重複受信、パケットロスト、送信側応答遅延、および受信側応答遅延が設けられている。コネクション毎に、各イベントの発生回数が設定される。
この異常箇所推定テーブル１７０は、コネクションテーブル１４０よりイベントを集計することで作成される。テーブル作成後、該当するコネクションのイベント発生状態を示すフラグがクリアされ、コネクションテーブル１４０が初期化される。なお、異常箇所推定テーブル１７０はインタフェース毎に生成される。
このような異常箇所推定テーブル１７０に基づいて、ステータスコードが生成される。
図２２は、ステータスコードの例を示す図である。この例では、再送、重複受信、パケットロスト、送信側応答遅延、および受信側応答遅延に対応するステータスコード１７１が設定されている。ステータスコードの値は、以下の意味を有している。
０：コネクションでトラフィック無し
１：正常コネクション有り
２：特定ＩＰアドレスで異常イベント有り（正常コネクション無し）
３：特定ＩＰアドレスで異常イベント有り（正常コネクション有り）
４：複数ＩＰアドレスで異常イベント有り（正常コネクション無し）
５：複数ＩＰアドレスで異常イベント有り（正常コネクション有り）
障害判定部１６０は、ステータスコード１７１に基づいて異常の発生数を認識し、トラブル事象ＤＢ１５０より該当する検知条件を検索する。そして、検出された検知条件に基づいて、今回発生した現象の障害発生箇所を判定する。
図２２は、ステータスコードの例を示す図である。この例では、再送、重複受信、パケットロスト、送信側応答遅延、および受信側応答遅延に対応するステータスコード１７１が設定されている。ステータスコードの値は、以下の意味を有している。
０：コネクションでトラフィック無し
１：正常コネクション有り
２：特定ＩＰアドレスで異常イベント有り（正常コネクション無し）
３：特定ＩＰアドレスで異常イベント有り（正常コネクション有り）
４：複数ＩＰアドレスで異常イベント有り（正常コネクション無し）
５：複数ＩＰアドレスで異常イベント有り（正常コネクション有り）
障害判定部１６０は、ステータスコード１７１に基づいて異常の発生数を認識し、トラブル事象ＤＢ１５０より該当する検知条件を検索する。そして、検出された検知条件に基づいて、今回発生した現象の障害発生箇所を判定する。
たとえば、図２２の例では、再送のコードが「３」である。すなわち、特定のＩＰアドレスで異常イベントが発生しており、且つそのＩＰアドレスとの間での正常コネクションが存在していることが分かる。このコードに基づいて、図８に示すトラブル事象ＤＢ１５０を検索すると、「一部のコネクションにおいて、不特定のＩＰアドレス、ポートで異常検出」という検知条件が検出される。従って、非隣接伝送路に障害があると判定される。
異常が検知された場合、対応するコネクションテーブルの情報や障害箇所の判定結果が、障害情報１１０に登録される。
以上のような障害箇所の判定が各サーバ上で行われ、障害情報が生成される。各サーバで生成された障害情報１１０は、管理サーバ３００で収集される。収集される障害情報１１０には、ステータスコード（マージ処理で生成したもの）やエラーメッセージ（マージ処理で推定した結果（異常発生箇所・原因の推定結果））が含まれる。管理サーバ３００は、収集した障害情報に基づいて、ネットワーク内での障害箇所をより正確に特定する。
以上のような障害箇所の判定が各サーバ上で行われ、障害情報が生成される。各サーバで生成された障害情報１１０は、管理サーバ３００で収集される。収集される障害情報１１０には、ステータスコード（マージ処理で生成したもの）やエラーメッセージ（マージ処理で推定した結果（異常発生箇所・原因の推定結果））が含まれる。管理サーバ３００は、収集した障害情報に基づいて、ネットワーク内での障害箇所をより正確に特定する。
図２３は、管理サーバでの障害箇所判断手順を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。
［ステップＳ５１］管理サーバ３００は、他のサーバのネットワーク監視機能から、異常ログが送られるのを待機する。
［ステップＳ５１］管理サーバ３００は、他のサーバのネットワーク監視機能から、異常ログが送られるのを待機する。
［ステップＳ５２］管理サーバ３００は、全てのネットワーク監視機能に対して、監視情報の取得要求を送信する。そして、管理サーバ３００は、取得要求に応じて返信される監視情報を取得する。
［ステップＳ５３］管理サーバ３００は、複数のサーバから送られる監視情報に基づいて、障害発生箇所と原因とを推定する。たとえば、図２で示したように、Ｗｅｂサーバ１００とＡＰサーバ２２０とから送られる監視情報を解析することで、ＳＷに障害が発生していると判断することが可能である。
［ステップＳ５４］管理サーバ３００は、回避可否／回避方法を判断する。たとえば、図２の例に示すようにＳＷ４４３に障害が発生した場合、ＳＷ４４３を介して行われていた通信の接続先をＳＷ４４４に切り替えることで、障害を回避できる。
［ステップＳ５５］管理サーバ３００は、対象サーバに対して、回避方法に基づいた制御指示を送信する。図２の例に示すようにＳＷ４４３に障害が発生した場合、管理サーバ３００からＷｅｂサーバ１００とＡＰサーバ２２０とに対して、ＳＷ４４３を介した通信をＳＷ４４４経由に切り替えるように指示が出される。
［ステップＳ５６］管理サーバ３００は、監視終了の指示があったか否かを判断する。監視終了の指示があった場合、処理を終了する。監視終了の指示がなければ、処理がステップＳ５１に進められる。
このようにして、管理サーバ３００において、ネットワーク上の障害箇所が判断される。また、管理サーバ３００は、ネットワーク上の障害発生状況を監視画面に表示して、ネットワークの管理者自身が障害箇所を判断することもできる。
図２４は、監視画面例を示す図である。監視画面６０には、構成情報表示部６１と異常通知情報表示部６２とが設けられている。
構成情報表示部６１には、ネットワーク内のノードの配置と接続関係とが表示されている。図２４の例では、異常を検出したサーバが強調表示されている。これにより、管理者による障害箇所の確認が容易となる。
構成情報表示部６１には、ネットワーク内のノードの配置と接続関係とが表示されている。図２４の例では、異常を検出したサーバが強調表示されている。これにより、管理者による障害箇所の確認が容易となる。
異常通知情報表示部６２には、検出された異常の内容が表示される。たとえば、ステータスコードの内容や、異常が発生した通信インタフェースの識別番号が表示される。また、サーバで判定された障害箇所の判定結果も表示される。図２４の例では、「非隣接伝送路で異常が発生した可能性があります（相手システムとの間のネットワーク機器を確認してください）。」と表示されている。さらに、異常通知情報表示部６２内には、詳細情報として、コネクション毎の状態を示す情報が表示される。
異常通知情報表示部６２の表示内容は、切替ボタン６３を選択することで切り替えることができる。
以上説明したように、本実施の形態によれば、各サーバにおいてネットワーク上の障害箇所を判定することができる。しかも、ハードウェア的な障害箇所と、ソフトウェア的な障害箇所との判定が可能である。これにより、ネットワーク管理者の経験に頼らずに、迅速に障害箇所を特定することができる。
以上説明したように、本実施の形態によれば、各サーバにおいてネットワーク上の障害箇所を判定することができる。しかも、ハードウェア的な障害箇所と、ソフトウェア的な障害箇所との判定が可能である。これにより、ネットワーク管理者の経験に頼らずに、迅速に障害箇所を特定することができる。
さらに、複数のサーバで検出された異常の内容を管理サーバ３００で収集し、それらを統合して障害箇所を判定するため、障害箇所の切り分けを、細かな範囲で行うことができる。その結果、障害箇所の特定、および障害の復旧を迅速に行うことが可能となる。
ところで、ネットワーク監視機能において、自装置側のアプリケーションがサーバなのかクライアントなのかを識別することもできる。たとえば、セッション開始時に転送される同期要求（ＳＹＮ）パケットを検出することで、サーバとクライアントとを判別することができる。
図２５は、サーバ・クライアント識別機能を示す図である。図２５には、Ｗｅｂサーバ１００のソフトウェア構成例を用いて、サーバ・クライアントの判別方法を示している。この例では、Ｗｅｂサーバ１００に何らかのアプリケーション１００ｅが実装されている。このアプリケーション１００ｅがサーバとして機能する場合、他の装置からアプリケーション１００ｅに対して、同期要求パケットが送られてくる。また、アプリケーション１００ｅがクライアントとして機能する場合、アプリケーション１００ｅから他の装置に対して同期要求パケットが送信される。
ネットワーク監視部１００ａは、通信インタフェース（ＮＩＣ）１０６ａとＩＰ／ＡＲＰ１００ｃとの間で受け渡されるパケットのＴＣＰパケットヘッダを解析する。そして、ネットワーク監視部１００ａは、受け取ったパケットが同期要求パケットであることを検出すると、その同期要求パケットの転送方向を判別する。
同期要求パケットが通信インタフェース１０６ａからアプリケーション１００ｅに渡された場合、同期要求パケットの転送方向は上り方向（ｕｐ）である。同期要求パケットがアプリケーション１００ｅから通信インタフェース１０６ａに渡された場合、同期要求パケットの転送方向は下り方向（ｄｏｗｎ）である。
ネットワーク監視部１００ａは、同期要求パケットの転送方向が上り方向であれば、アプリケーション１００ｅがサーバであると判断する。また、ネットワーク監視部１００ａは、同期要求パケットの転送方向が下り方向であれば、アプリケーション１００ｅがクライアントであると判断する。
このように、サーバとクライアントとを識別することで、アプリケーション１００ｅがサーバかクライアントかで、異常検出の精度を変えることができる。アプリケーション１０ｅがサーバの場合、装置に異常が発生した場合の業務に与える影響が大きくなる。そこで、装置の異常監視精度を高く設定することで、異常の検出を迅速に行うことができる。
たとえば、アプリケーションがサーバであれば、応答遅延（自装置の過大な負荷等に起因する）を判定するための自側応答時間基準を厳しく（クライアントの場合より短い値）設定する。これにより、サーバで生じた障害を迅速に見つけだすことができる。
また、アプリケーションがサーバの場合、複数のコネクションを１つのコネクションテーブルで管理することで、ＲＡＭ１０２等の記憶領域の効率的な利用を図ることもできる。具体的には、クライアントかサーバかの判断処理が、ネットワーク監視部１００ａ内のパケット解析部１２０（図５に示す）において実行され、その結果がコネクション監視部１３０（図５に示す）に渡される。コネクション監視部１３０は、アプリケーション１００ｅがサーバであるかクライアントであるかの判断結果に応じたコネクションテーブルを生成する。
具体的には、アプリケーション１００ｅがクライアントの場合、アプリケーション１００ｅと他の装置との間で確立されたコネクション毎に、コネクションテーブルが生成される。生成されるコネクションテーブルの内容は、図１４〜図１６に示したものと同様である。
一方、アプリケーション１００ｅがサーバの場合、アプリケーション１００ｅに対して確立される複数のコネクションが、１つのコネクションテーブルに対応付けられる。たとえば、アプリケーション１００ｅに対して最初のコネクションが確立されたとき、コネクションテーブルが生成され、アプリケーション１００ｅに対して２つめ以降のコネクションが確立されても、新たなコネクションテーブルの生成は行われない。そして、コネクション監視部１３０は、複数のコネクションを１つのコネクションテーブルによって監視する。
アプリケーション１００ｅがサーバの場合、コネクションテーブル内のコネクション管理テーブルの内容が、アプリケーション１００ｅがクライアントの場合と異なる。
図２６は、アプリケーションがサーバの場合のコネクション管理テーブルのデータ構造例を示す図である。このコネクション管理テーブル１４１ａの内容は、図１４に示したコネクション管理テーブル１４１とほぼ同じであるが、相手側ＩＰと相手側Ｐｏｒｔの内容が異なっている。
図２６は、アプリケーションがサーバの場合のコネクション管理テーブルのデータ構造例を示す図である。このコネクション管理テーブル１４１ａの内容は、図１４に示したコネクション管理テーブル１４１とほぼ同じであるが、相手側ＩＰと相手側Ｐｏｒｔの内容が異なっている。
コネクション管理テーブル１４１ａでは、相手側ＩＰとして「＊．＊．＊．＊」が設定されている。これは、相手装置のＩＰアドレスが不特定であることを示している。また、コネクション管理テーブル１４１ａでは、相手側Ｐｏｒｔとして「＊」が設定されている。これは、相手装置内のアプリケーションのポート番号が不特定であることを示している。すなわち、パケット解析部１２０で解析されたパケットの自側ＩＰと自側Ｐｏｒｔがコネクション監視テーブル１４１ａと一致すれば、そのパケットは、コネクション監視テーブル１４１ａを含むコネクションテーブルを用いた監視対象と判断される。
このように、アプリケーション１００ｅがサーバの場合、複数の通信相手を１つのコネクションテーブルで一括管理することで、Ｗｅｂサーバ１００にかかる負荷を軽減することができる。すなわち、アプリケーション１００ｅが本来行うべき業務への影響を最小限に抑えることができる。
なお、ネットワーク監視部や管理サーバが有すべき機能の処理内容を記述したプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現できる。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。
プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
（付記１） ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラム。
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラム。
（付記２） 前記障害箇所判定テーブルでは、前記ネットワークに接続された機器が前記要素として定義されており、前記コンピュータとの間の接続関係に基づいて分類されていることを特徴とする付記１記載のネットワーク監視プログラム。
（付記３） 前記障害箇所判定テーブルでは、前記ネットワークに接続された機器が、前記コンピュータ自身を示す自装置、前記コンピュータに隣接する伝送路を示す隣接伝送路、前記隣接伝送路以外の伝送路を示す非隣接伝送路、通信相手を示す相手装置に分類されていることを特徴とする付記２記載のネットワーク監視プログラム。
（付記４） 前記障害箇所判定テーブルでは、前記自装置に対して、受信したパケットに対する前記コンピュータによる応答が遅延するという事象が対応付けられていることを特徴とする付記３記載のネットワーク監視プログラム。
（付記５） 前記障害箇所判定テーブルでは、前記隣接伝送路に対して、全てのコネクションにおいて異常が検出されるという事象が対応付けられていることを特徴とする付記３記載のネットワーク監視プログラム。
（付記６） 前記障害箇所判定テーブルでは、前記非隣接伝送路に対して、一部のコネクションにおいて、不特定のアドレスの装置との間の通信の異常が検出されるという事象が対応付けられていることを特徴とする付記３記載のネットワーク監視プログラム。
（付記７） 前記障害箇所判定テーブルでは、前記相手装置に対して、特定のアドレスの装置との間の通信に異常が検出されるという事象が対応付けられていることを特徴とする付記３記載のネットワーク監視プログラム。
（付記８） 前記障害箇所判定テーブルでは、前記ネットワークに接続された機器内で実現される機能が前記要素として定義されていることを特徴とする付記１記載のネットワーク監視プログラム。
（付記９） 前記障害箇所判定テーブルでは、前記要素としてアプリケーションが定義されており、前記アプリケーションが動作する装置に対してコネクションが確立し、前記アプリケーションに対してコネクションが確立できないという事象が対応付けられており、
前記通信状況監視手段は、アプリケーション間のコネクションと装置間のコネクションとの確立の有無を監視することを特徴とする付記８記載のネットワーク監視プログラム。
前記通信状況監視手段は、アプリケーション間のコネクションと装置間のコネクションとの確立の有無を監視することを特徴とする付記８記載のネットワーク監視プログラム。
（付記１０） 前記障害箇所判定テーブルでは、前記要素としてネットワーク監視機能が定義されており、前記ネットワーク監視機能に対して、トランスポート層でのコネクションが確立されているにもかかわらずネットワーク層での異常が検出されたという事象が対応付けられており、
前記通信状況監視手段は、前記トランスポート層でのコネクションと前記ネットワーク層でのコネクションとの確立の有無を監視することを特徴とする付記８記載のネットワーク監視プログラム。
前記通信状況監視手段は、前記トランスポート層でのコネクションと前記ネットワーク層でのコネクションとの確立の有無を監視することを特徴とする付記８記載のネットワーク監視プログラム。
（付記１１） 前記通信状況監視手段は、通信されるパケットのヘッダ情報に基づいて、自装置で動作している機能がサーバかクライアントかを判断し、判断結果に応じて前記機能の監視内容を決定することを特徴とする付記１記載のネットワーク監視プログラム。
（付記１２） 前記通信状況監視手段は、前記他の機器との間の正常な通信を含めた通信状況を監視することを特徴とする付記１記載のネットワーク監視プログラム。
（付記１３） ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、を有する前記ネットワーク上の複数の装置から前記障害情報を収集する障害情報収集手段、
前記障害情報収集手段が前記複数の装置から収集した前記障害情報に共通する要素を、前記ネットワーク上での障害発生箇所と判断する障害発生箇所絞り込み手段、
として機能させることを特徴とするネットワーク監視プログラム。
（付記１３） ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、を有する前記ネットワーク上の複数の装置から前記障害情報を収集する障害情報収集手段、
前記障害情報収集手段が前記複数の装置から収集した前記障害情報に共通する要素を、前記ネットワーク上での障害発生箇所と判断する障害発生箇所絞り込み手段、
として機能させることを特徴とするネットワーク監視プログラム。
（付記１４） ネットワーク上の障害発生箇所を検出するためのネットワーク監視方法において、
通信状況監視手段が、前記ネットワーク上の他の機器との間の通信状況を監視し、
異常検出手段が、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出し、
障害箇所判定手段が、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定し、
障害情報出力手段が、障害箇所判定手段での判定結果を示す障害情報を出力する、
ことを特徴とするネットワーク監視方法。
通信状況監視手段が、前記ネットワーク上の他の機器との間の通信状況を監視し、
異常検出手段が、前記通信状況監視手段で検出された通信内容から異常を示す事象を検出し、
障害箇所判定手段が、前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定し、
障害情報出力手段が、障害箇所判定手段での判定結果を示す障害情報を出力する、
ことを特徴とするネットワーク監視方法。
（付記１５） ネットワーク上の障害発生箇所を検出するためのネットワーク監視装置において、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、
を有することを特徴とするネットワーク監視装置。
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段と、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段と、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、
を有することを特徴とするネットワーク監視装置。
（付記１６） ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムを記録したコンピュータ読み取り可能な記録媒体において、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラムを記録したコンピュータ読み取り可能な記録媒体。
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介した通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記ネットワーク上の他の機器との間の通信状況を監視する通信状況監視手段、
前記通信状況監視手段で検出された通信内容から異常を示す事象を検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラムを記録したコンピュータ読み取り可能な記録媒体。
１ 自装置
１ａ アプリケーション
１ｂ 通信手段
１ｃ 通信インタフェース
１ｄ 記憶手段
１ｄａ 障害箇所判定テーブル
１ｅ 通信状況監視手段
１ｆ 異常検出手段
１ｇ 障害箇所判定手段
１ｈ 障害情報出力手段
２ スイッチ（ＳＷ）
３ ネットワーク
４ 相手装置
５ 隣接伝送路
６ 非隣接伝送路
７ パケット
８ 障害情報
１ａ アプリケーション
１ｂ 通信手段
１ｃ 通信インタフェース
１ｄ 記憶手段
１ｄａ 障害箇所判定テーブル
１ｅ 通信状況監視手段
１ｆ 異常検出手段
１ｇ 障害箇所判定手段
１ｈ 障害情報出力手段
２ スイッチ（ＳＷ）
３ ネットワーク
４ 相手装置
５ 隣接伝送路
６ 非隣接伝送路
７ パケット
８ 障害情報
Claims (10)
- ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、通信状況に応じて変動する所定のパラメータの値が基準値を超えることが、前記ネットワークを介した通信の異常を示す事象として対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記コンピュータ上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間の通信状況を監視して前記所定のパラメータの値を取得すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバかクライアントかに応じて、前記障害箇所判定テーブルに設定されている前記基準値を変更する通信状況監視手段、
前記通信状況監視手段で取得された前記所定のパラメータの値が前記基準値を超えた場合に、異常を示す事象が発生したことを検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラム。 - 前記障害箇所判定テーブルには、前記アプリケーションからの応答遅延時間が基準値を超えることが、前記ネットワークを介した通信の異常を示す事象として設定されており、
前記通信状況監視手段は、前記アプリケーションがサーバであれば、当該アプリケーションがクライアントの場合よりも前記応答遅延時間の基準値を短い値にすることを特徴とする請求項１記載のネットワーク監視プログラム。 - 前記障害箇所判定テーブルでは、前記ネットワークに接続された機器が前記要素として定義されており、前記コンピュータ自身を示す自装置、前記コンピュータに隣接する伝送路を示す隣接伝送路、前記隣接伝送路以外の伝送路を示す非隣接伝送路、通信相手を示す相手装置に分類されていることを特徴とする請求項１記載のネットワーク監視プログラム。
- ネットワーク上の障害発生箇所を検出するためのネットワーク監視プログラムにおいて、
コンピュータを、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介したコネクションを用いた通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段、
前記コンピュータ上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間のコネクションを用いた通信状況を監視すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバであれば、全ての前記他の装置との間のコネクションの状態をまとめて１つのコネクション管理テーブルで管理し、当該アプリケーションがクライアントであれば、複数の前記他の装置それぞれとの間のコネクションの状態を個別のコネクション管理テーブルで管理する通信状況監視手段、
前記通信状況監視手段が有する前記コネクション管理テーブルに示されるコネクションの状態に基づいて異常を示す事象を検出する異常検出手段、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段、
として機能させることを特徴とするネットワーク監視プログラム。 - 前記障害箇所判定テーブルでは、前記要素として前記他の装置上で動作する他のアプリケーションが定義されており、当該要素としての当該他のアプリケーションに対して、当該他のアプリケーションが動作する当該他の装置に対してコネクションが確立するが、当該他のアプリケーションに対してコネクションが確立できないという事象が対応付けられており、
前記通信状況監視手段は、アプリケーション間のコネクションと装置間のコネクションとの確立の有無を監視することを特徴とする請求項４記載のネットワーク監視プログラム。 - 前記障害箇所判定テーブルでは、前記要素としてネットワーク監視機能が定義されており、前記ネットワーク監視機能に対して、トランスポート層でのコネクションが確立されているにもかかわらずネットワーク層での異常が検出されたという事象が対応付けられており、
前記通信状況監視手段は、前記トランスポート層でのコネクションと前記ネットワーク層でのコネクションとの確立の有無を監視することを特徴とする請求項４記載のネットワーク監視プログラム。 - ネットワーク上の障害発生箇所をコンピュータで検出するためのネットワーク監視方法において、
前記コンピュータが、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、通信状況に応じて変動する所定のパラメータの値が基準値を超えることが、前記ネットワークを介した通信の異常を示す事象として対応付けられた障害箇所判定テーブルを記憶手段で記憶し、
前記コンピュータ上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間の通信状況を監視して前記所定のパラメータの値を取得すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバかクライアントかに応じて、前記障害箇所判定テーブルに設定されている前記基準値を変更し、
取得された前記所定のパラメータの値が前記基準値を超えた場合に、異常を示す事象が発生したことを検出し、
前記障害箇所判定テーブルを参照し、検出された事象の発生原因となる要素を判定し、
判定結果を示す障害情報を出力する、
ことを特徴とするネットワーク監視方法。 - ネットワーク上の障害発生箇所をコンピュータで検出するためのネットワーク監視方法において、
前記コンピュータが、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介したコネクションを用いた通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶手段で記憶し、
前記コンピュータ上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間のコネクションを用いた通信状況を監視すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバであれば、全ての前記他の装置との間のコネクションの状態をまとめて１つのコネクション管理テーブルで管理し、当該アプリケーションがクライアントであれば、複数の前記他の装置それぞれとの間のコネクションの状態を個別のコネクション管理テーブルで管理し、
前記コネクション管理テーブルに示されるコネクションの状態に基づいて異常を示す事象を検出し、
前記障害箇所判定テーブルを参照し、検出された事象の発生原因となる要素を判定し、
判定結果を示す障害情報を出力する、
ことを特徴とするネットワーク監視方法。 - ネットワーク上の障害発生箇所を検出するためのネットワーク監視装置において、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、通信状況に応じて変動する所定のパラメータの値が基準値を超えることが、前記ネットワークを介した通信の異常を示す事象として対応付けられた障害箇所判定テーブルを記憶する記憶手段と、
前記ネットワーク監視装置上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間の通信状況を監視して前記所定のパラメータの値を取得すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバかクライアントかに応じて、前記障害箇所判定テーブルに設定されている前記基準値を変更する通信状況監視手段と、
前記通信状況監視手段で取得された前記所定のパラメータの値が前記基準値を超えた場合に、異常を示す事象が発生したことを検出する異常検出手段と、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、
を有することを特徴とするネットワーク監視装置。 - ネットワーク上の障害発生箇所を検出するためのネットワーク監視装置において、
前記ネットワーク上で障害の発生原因となり得る要素が予め分類され、分類された要素に対して、前記ネットワークを介したコネクションを用いた通信の異常を示す事象が対応付けられた障害箇所判定テーブルを記憶する記憶手段と、
前記ネットワーク監視装置上で動作するアプリケーションと前記コンピュータの通信インタフェースとの間で受け渡されるパケットを解析することで前記ネットワーク上の他の装置との間のコネクションを用いた通信状況を監視すると共に、受け渡されるパケットから同期要求パケットを抽出し、当該同期要求パケットが当該アプリケーションに対して送信されたものか、当該アプリケーションから送信されたものかによって、当該アプリケーションがサーバかクライアントかを判断し、当該アプリケーションがサーバであれば、全ての前記他の装置との間のコネクションの状態をまとめて１つのコネクション管理テーブルで管理し、当該アプリケーションがクライアントであれば、複数の前記他の装置それぞれとの間のコネクションの状態を個別のコネクション管理テーブルで管理する通信状況監視手段と、
前記通信状況監視手段が有する前記コネクション管理テーブルに示されるコネクションの状態に基づいて異常を示す事象を検出する異常検出手段と、
前記障害箇所判定テーブルを参照し、前記異常検出手段で検出された事象の発生原因となる要素を判定する障害箇所判定手段と、
前記障害箇所判定手段での判定結果を示す障害情報を出力する障害情報出力手段と、
を有することを特徴とするネットワーク監視装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003399937A JP4255366B2 (ja) | 2003-11-28 | 2003-11-28 | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 |
| US10/834,461 US7266758B2 (en) | 2003-11-28 | 2004-04-29 | Network monitoring program, network monitoring method, and network monitoring apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003399937A JP4255366B2 (ja) | 2003-11-28 | 2003-11-28 | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005167347A JP2005167347A (ja) | 2005-06-23 |
| JP4255366B2 true JP4255366B2 (ja) | 2009-04-15 |
Family
ID=34696775
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003399937A Expired - Fee Related JP4255366B2 (ja) | 2003-11-28 | 2003-11-28 | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7266758B2 (ja) |
| JP (1) | JP4255366B2 (ja) |
Families Citing this family (64)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7321560B2 (en) * | 2003-09-02 | 2008-01-22 | Kddi Corporation | Method for detecting failure location of network in the Internet |
| JP2006031335A (ja) * | 2004-07-15 | 2006-02-02 | Hitachi Ltd | 情報処理システム及び方法 |
| US7719965B2 (en) * | 2004-08-25 | 2010-05-18 | Agilent Technologies, Inc. | Methods and systems for coordinated monitoring of network transmission events |
| GB2425680B (en) * | 2005-04-27 | 2009-05-20 | Hewlett Packard Development Co | Network analysis |
| JP4612525B2 (ja) * | 2005-10-25 | 2011-01-12 | エヌ・ティ・ティ・コミュニケーションズ株式会社 | ネットワーク障害部位特定装置および方法 |
| US7570580B1 (en) * | 2005-12-02 | 2009-08-04 | At&T Corp. | Automatic problem isolation for multi-layer network failures |
| JP4559974B2 (ja) * | 2006-01-16 | 2010-10-13 | 三菱電機株式会社 | 管理装置及び管理方法及びプログラム |
| JP4594258B2 (ja) * | 2006-03-10 | 2010-12-08 | 富士通株式会社 | システム分析装置およびシステム分析方法 |
| US20070234118A1 (en) * | 2006-03-30 | 2007-10-04 | Sardella Steven D | Managing communications paths |
| JP4570582B2 (ja) * | 2006-03-31 | 2010-10-27 | 富士通株式会社 | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 |
| JP4939102B2 (ja) * | 2006-04-21 | 2012-05-23 | 株式会社日立製作所 | ネットワークブート計算機システムの高信頼化方法 |
| US20070293232A1 (en) * | 2006-06-20 | 2007-12-20 | Aruze Corp. | Wireless communication failure monitoring system and monitoring device |
| US7613949B1 (en) * | 2006-06-30 | 2009-11-03 | Boone Lewis A | Fault isolation system and method |
| JP4126707B2 (ja) | 2006-07-28 | 2008-07-30 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 情報システムの状態を解析する技術 |
| JP4842738B2 (ja) * | 2006-09-01 | 2011-12-21 | 株式会社日立システムズ | 障害管理支援システム及びその情報管理方法 |
| JP2008085916A (ja) * | 2006-09-28 | 2008-04-10 | Toshiba Corp | 通信システムの主装置及びこの主装置で使用される登録方法 |
| JP2008217735A (ja) * | 2007-03-08 | 2008-09-18 | Nec Corp | 障害解析システム、方法、及び、プログラム |
| JP2008310628A (ja) * | 2007-06-15 | 2008-12-25 | Toppan Printing Co Ltd | 障害監視装置 |
| JP4946824B2 (ja) * | 2007-11-26 | 2012-06-06 | 富士通株式会社 | 監視装置 |
| US8793362B2 (en) * | 2007-11-29 | 2014-07-29 | Barclays Capital Inc. | Communications enterprise server monitor |
| US8086905B2 (en) | 2008-05-27 | 2011-12-27 | Hitachi, Ltd. | Method of collecting information in system network |
| US8406748B2 (en) | 2009-01-28 | 2013-03-26 | Headwater Partners I Llc | Adaptive ambient services |
| US8391834B2 (en) | 2009-01-28 | 2013-03-05 | Headwater Partners I Llc | Security techniques for device assisted services |
| US8275830B2 (en) | 2009-01-28 | 2012-09-25 | Headwater Partners I Llc | Device assisted CDR creation, aggregation, mediation and billing |
| US8448015B2 (en) * | 2008-06-17 | 2013-05-21 | My Computer Works, Inc. | Remote computer diagnostic system and method |
| JP5161736B2 (ja) | 2008-11-18 | 2013-03-13 | 株式会社東芝 | 障害診断プログラム、方法、および通信装置 |
| US10484858B2 (en) | 2009-01-28 | 2019-11-19 | Headwater Research Llc | Enhanced roaming services and converged carrier networks with device assisted services and a proxy |
| JP5225473B2 (ja) * | 2009-12-09 | 2013-07-03 | 株式会社東芝 | 通信装置及び通信システム |
| JP5488002B2 (ja) | 2010-01-28 | 2014-05-14 | 富士通株式会社 | 事例データ生成プログラム、方法及び装置 |
| US8868029B2 (en) | 2010-01-29 | 2014-10-21 | Alcatel Lucent | Method and apparatus for managing mobile resource usage |
| US8767584B2 (en) * | 2010-01-29 | 2014-07-01 | Alcatel Lucent | Method and apparatus for analyzing mobile services delivery |
| JP5549304B2 (ja) * | 2010-03-23 | 2014-07-16 | 富士通株式会社 | 判定装置、判定方法および判定プログラム |
| JP5625940B2 (ja) | 2011-01-19 | 2014-11-19 | 富士通株式会社 | 監視プログラム、監視装置、及び監視方法 |
| JP5229696B2 (ja) * | 2011-03-04 | 2013-07-03 | 日本電気株式会社 | 情報処理システム、情報処理装置、その制御方法、及びその制御プログラム、通信環境監視復旧方法 |
| US9009220B2 (en) * | 2011-10-14 | 2015-04-14 | Mimecast North America Inc. | Analyzing stored electronic communications |
| WO2013103387A1 (en) | 2012-01-06 | 2013-07-11 | Siemens Enterprise Communications Gmbh & Co. Kg | Method for optimizing network performance after a temporary loss of connection |
| JP5884569B2 (ja) * | 2012-03-14 | 2016-03-15 | 日本電気株式会社 | 通信機器およびその障害の検出方法 |
| CN103378982A (zh) * | 2012-04-17 | 2013-10-30 | 深圳市腾讯计算机系统有限公司 | 互联网业务运行监测方法和系统 |
| CN103001822B (zh) * | 2012-08-29 | 2016-07-06 | 五八同城信息技术有限公司 | 网络异常的处理方法及装置 |
| JP6047410B2 (ja) * | 2013-01-25 | 2016-12-21 | 株式会社Ｎｔｔドコモ | 試験装置 |
| US9323627B1 (en) * | 2014-04-29 | 2016-04-26 | Juniper Networks, Inc. | System, method, and apparatus for detecting fault conditions experienced by remote physical ports |
| US10135704B2 (en) * | 2014-06-20 | 2018-11-20 | Microsoft Technology Licensing, Llc | Identification of candidate problem network entities |
| US9749422B2 (en) | 2014-12-05 | 2017-08-29 | Unify Gmbh & Co. Kg | Method and system for telecommunication device monitoring |
| EP3242422B1 (en) * | 2014-12-30 | 2023-07-05 | Solid, Inc. | Monitoring apparatus of distributed antenna system |
| US9652361B2 (en) | 2015-03-03 | 2017-05-16 | International Business Machines Corporation | Targeted multi-tiered software stack serviceability |
| JP6221123B2 (ja) * | 2015-06-15 | 2017-11-01 | ３ｐｌｅｘ株式会社 | 防犯カメラヘルスチェック |
| DE102015010706B4 (de) | 2015-08-14 | 2017-10-05 | Unify Gmbh & Co. Kg | Verfahren, Vorrichtung und System für ein Verfahren zum Einschalten einer Überwachung von Überwachungsobjekten in einer Computer-Implementierten Telekommunikationsumgebung |
| CN107294799B (zh) * | 2016-03-31 | 2020-09-01 | 阿里巴巴集团控股有限公司 | 一种分布式系统中节点的处理方法和装置 |
| US10257750B2 (en) * | 2016-11-15 | 2019-04-09 | Mist Systems, Inc. | Methods and apparatus for capturing and/or using packets to facilitate fault detection |
| JP6754338B2 (ja) * | 2017-08-10 | 2020-09-09 | 日本電信電話株式会社 | 障害解析支援装置、障害解析支援方法および障害解析支援プログラム |
| JP6977522B2 (ja) * | 2017-12-07 | 2021-12-08 | オムロン株式会社 | 制御システム、情報処理装置、異常要因推定プログラム |
| US10523549B1 (en) * | 2019-06-02 | 2019-12-31 | Cybertoka Ltd | Method and system for detecting and classifying networked devices |
| US11151150B2 (en) | 2019-09-13 | 2021-10-19 | Salesforce.Com, Inc. | Adjustable connection pool mechanism |
| CN112583623B (zh) * | 2019-09-30 | 2023-02-07 | 中兴通讯股份有限公司 | 过滤信息配置方法及系统 |
| US11636067B2 (en) * | 2019-10-04 | 2023-04-25 | Salesforce.Com, Inc. | Performance measurement mechanism |
| US11165857B2 (en) | 2019-10-23 | 2021-11-02 | Salesforce.Com, Inc. | Connection pool anomaly detection mechanism |
| US11991038B2 (en) * | 2020-02-26 | 2024-05-21 | Nippon Telegraph And Telephone Corporation | Damaged part identifying apparatus, method and program |
| JP7322806B2 (ja) * | 2020-05-15 | 2023-08-08 | トヨタ自動車株式会社 | 車両用異常検出装置 |
| JP7574934B2 (ja) * | 2021-07-05 | 2024-10-29 | 日本電信電話株式会社 | 障害推定装置、方法およびプログラム |
| US12185135B2 (en) * | 2021-12-17 | 2024-12-31 | Rakuten Mobile, Inc. | Physical network function device access control |
| JP7741014B2 (ja) * | 2022-03-10 | 2025-09-17 | 株式会社日立ハイテク | 分散システムおよび分散システムを構成する分散装置 |
| CN115580527A (zh) * | 2022-09-30 | 2023-01-06 | 深圳拓邦股份有限公司 | 一种网络通讯故障排查方法、装置、设备及存储介质 |
| CN118118318A (zh) * | 2023-08-11 | 2024-05-31 | 华为技术有限公司 | 故障检测方法、系统、装置及存储介质 |
| CN119134334B (zh) * | 2024-11-08 | 2025-02-18 | 广东电网有限责任公司中山供电局 | 继电保护装置的维修处理方法、装置、电子设备 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2461261A1 (fr) * | 1979-07-11 | 1981-01-30 | Cit Alcatel | Dispositif de controle de bon fonctionnement d'un equipement electronique |
| US5303112A (en) * | 1990-10-26 | 1994-04-12 | S & C Electric Company | Fault detection method and apparatus |
| US6324161B1 (en) * | 1997-08-27 | 2001-11-27 | Alcatel Usa Sourcing, L.P. | Multiple network configuration with local and remote network redundancy by dual media redirect |
| JP2002099469A (ja) | 2000-09-25 | 2002-04-05 | Hitachi Ltd | ネットワークシステム性能診断方法及びその装置 |
-
2003
- 2003-11-28 JP JP2003399937A patent/JP4255366B2/ja not_active Expired - Fee Related
-
2004
- 2004-04-29 US US10/834,461 patent/US7266758B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005167347A (ja) | 2005-06-23 |
| US7266758B2 (en) | 2007-09-04 |
| US20050144505A1 (en) | 2005-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4255366B2 (ja) | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 | |
| US20070177523A1 (en) | System and method for network monitoring | |
| JP3983138B2 (ja) | 障害情報収集プログラムおよび障害情報収集装置 | |
| US7213179B2 (en) | Automated and embedded software reliability measurement and classification in network elements | |
| JP3556842B2 (ja) | ネットワーク監視機構、ネットワーク監視装置およびネットワーク管理方法 | |
| US7010718B2 (en) | Method and system for supporting network system troubleshooting | |
| JP4576249B2 (ja) | ネットワーク管理装置及び方法 | |
| US20100080129A1 (en) | Network troubleshooting using path topology | |
| US20080114581A1 (en) | Root cause analysis approach with candidate elimination using network virtualization | |
| US20090070463A1 (en) | Preliminary Classification of Events to Facilitate Cause-Based Analysis | |
| JP4412031B2 (ja) | ネットワーク監視システム及びその方法、プログラム | |
| EP1703671B1 (en) | Device and method for network monitoring | |
| US7593351B1 (en) | Method and system for collecting and consolidating network traffic information | |
| JP5342082B1 (ja) | ネットワーク障害解析システムおよびネットワーク障害解析プログラム | |
| CN118550752A (zh) | 一种云平台故障检测及运维系统、方法、设备及存储介质 | |
| JP4464256B2 (ja) | ネットワーク上位監視装置 | |
| JP4570582B2 (ja) | ネットワーク監視プログラム、ネットワーク監視方法、およびネットワーク監視装置 | |
| KR100964392B1 (ko) | 망 관리에서의 장애 관리 시스템 및 그 방법 | |
| CN120811865A (zh) | 一种基于多维协议诊断的地震网络通信故障定位方法 | |
| US12143286B2 (en) | Network monitoring device, network monitoring method, and network monitoring program | |
| KR100887874B1 (ko) | 인터넷 망의 장애 관리 시스템 및 그 방법 | |
| JP2001244946A (ja) | ネットワーク監視装置 | |
| CN115242820B (zh) | 一种集群节点故障处理方法、装置、设备及介质 | |
| US20060039288A1 (en) | Network status monitoring and warning method | |
| KR20040028400A (ko) | 매트로 이더넷망의 장애처리 장치 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071108 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071120 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080121 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080725 |
|
| 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: 20090127 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090127 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120206 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130206 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140206 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |