JP3805711B2 - サイト領域内ボトルネック特定方法 - Google Patents
サイト領域内ボトルネック特定方法 Download PDFInfo
- Publication number
- JP3805711B2 JP3805711B2 JP2002103695A JP2002103695A JP3805711B2 JP 3805711 B2 JP3805711 B2 JP 3805711B2 JP 2002103695 A JP2002103695 A JP 2002103695A JP 2002103695 A JP2002103695 A JP 2002103695A JP 3805711 B2 JP3805711 B2 JP 3805711B2
- Authority
- JP
- Japan
- Prior art keywords
- bottleneck
- log information
- server
- network element
- site area
- 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
Landscapes
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、サイト領域内ボトルネック特定方法に関し、詳しくは、インターネットのエンド・トゥ・サーバ（End-to-Server ）におけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するためのサイト領域内ボトルネック特定方法に係わる。
【０００２】
【従来の技術】
近年、インターネットにおける性能、経済性、信頼性といったネットワーク品質に対する関心が高まり、広域ネットワークの特性を計測する手法の重要性が増してきている。
【０００３】
例えば、ＭＳＰ（Managed Service Provider）において、映像等の大衆向け配信サービスを提供するアプリケーション、ネットワーク、サーバを対象とした品質管理サービス事業を効率良く実現するには、対象ネットワークの品質劣化監視及びその検出分析を行うことが必須となる。
【０００４】
このため、上記のようなサービスを提供する際に、エンドユーザからの申告等によりネットワーク品質に劣化が生じていることが判明した場合には、サービス提供者は、その劣化の要因となっている対象ネットワーク上の箇所、即ちボトルネックを早急かつ的確に特定し、これに対処することが責務であるといえる。
【０００５】
従来、対象ネットワーク上のエンド・トゥ・サーバにおけるボトルネックを特定する方法としては、その対象ネットワーク上に存在する全てのサーバの中で、何れのサーバがボトルネックとなっているかをリモートで逐一検査していくものが知られている。
【０００６】
しかし、この方法では、対象ネットワークが大規模になるにつれて、自ずと適用性が悪くなり、当該対象ネットワーク中におけるボトルネック特定箇所を総合的に判断することも困難である。
【０００７】
これに対し、対象ネットワーク上のエンド・トゥ・エンド（End-to-End）におけるボトルネックを特定する方法として、ＭＩＮＣプロジェクト（ＭＩＮＣ：Multicast-based Inference of Network-internal Characteristics ）によるものが知られている。
【０００８】
このＭＩＮＣプロジェクトによる方法は、マルチキャストにより、対象ネットワーク上の１つの始点から多数の終点へ向けて試験パケットを送信し、このときのエンド・トゥ・エンドの観測データからパス上の特性を得て、その対象ネットワーク中のパケットロスや遅延を推定するものである。
【０００９】
【発明が解決しようとする課題】
しかしながら、上述のＭＩＮＣプロジェクトによる方法は、マルチキャスト適用時における木構造の特質から理論的には高い精度を持つものの、インターネットが、その広域性と管理主体の分散に起因して、その状態を直接的に管理し制御することが困難な対象であるため、以下に示すような問題を有している。
【００１０】
即ち、ＭＩＮＣプロジェクトによる方法に用いられるマルチキャストは、現在運用されているインターネットでは実用的でないため柔軟性が低く、また、試験パケットによる片道特性の観測は、現在運用されているインターネットでは困難な場合がある。
【００１１】
以上の問題を解消するには、所要のボトルネック特定方法が、パス全体が木構造をとらないネットワークに対しても適用可能であることが条件となるが、以上のＭＩＮＣプロジェクトによる手法を木構造以外のネットワークに適用することはできず、現時点では、これを実際のＩＳＰ（Internet Service Provider ）に適用することも事実上困難である。
【００１２】
即ち、現状では、インターネット上に分散した複数のネットワーク要素に生じ得るボトルネックを直接的に特定することが困難であるため、そのボトルネックを他の計測データから統計的に推定可能な新たな技術が必要とされている。
【００１３】
ここにおいて、本発明の解決すべき主要な目的は、次のとおりである。
【００１４】
即ち、本発明の第１の目的は、サイト領域に存在する複数のネットワーク要素におけるボトルネックを効率良く特定することの可能なサイト領域内ボトルネック特定方法を提供せんとするものである。
【００１５】
本発明の第２の目的は、サイト領域に存在する１以上のサーバにおけるボトルネックを特に効率良く特定することの可能なサイト領域内ボトルネック特定方法を提供せんとするものである。
【００１６】
本発明の他の目的は、明細書、図面、特に特許請求の範囲の各請求項の記載から、自ずと明らかとなろう。
【００１７】
【課題を解決するための手段】
本発明方法においては、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにおいて、各ネットワーク要素の処理能力の判定に供し得るログ情報を収集するログ情報収集処理と、各ネットワーク要素のログ情報に基づいて、当該各ネットワーク要素がボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、各ネットワーク要素中にボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理とを順次実行する、という特徴的構成手法を講じる。
【００１８】
さらに具体的詳細に述べると、当該課題の解決は、本発明が、以下に列挙する上位概念から下位概念に亙る新規な特徴的構成手法を採用することにより、前記目的を達成するよう為される。
【００１９】
即ち、本発明方法の第１の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記コンピュータは、前記ボトルネック判定処理において、その収集した前記１以上のログ情報中において前記ボトルネックの判定基準とすべき単一のログ情報を当該コンピュータ内に予め対応設定された判定閾値と比較した結果、当該単一のログ情報が当該判定閾値の許容範囲外であった場合に、該当する特定のサーバの個体識別子を前記ボトルネックリストに記載するボトルネックサーバ記載処理、を経た後の当該ボトルネックリスト中に、指定数を超える当該特定のサーバの前記個体識別子が存在すると、前記ログ情報収集処理において前記所定時間内に収集した当該単一のログ情報の平均値を算出するログ情報平均値算出処理と、その算出した前記単一のログ情報の前記平均値を元に、前記特定のサーバの前記個体識別子を前記判定閾値との差異が大きいものから順に前記指定数だけ抽出するサーバ指定数抽出処理と、その指定数だけ抽出した前記特定のサーバの前記個体識別子により、前記ボトルネックサーバ記載処理を経た後の前記ボトルネックリストの内容を書き換えるボトルネックリスト書換処理と、を順次実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２１】
本発明方法の第２の特徴は、上記本発明方法の第１の特徴における前記複数のネットワーク要素が、その１つの要素として、１以上からなるサーバを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のサーバにおける利用可能ＲＡＭメモリ残量、ＮＩＣ使用総帯域、ＣＰＵ使用率、ＨＤＤデータ読込み速度、接続待ちクライアント数、及び秒間累積発生エラー数のうち１以上を収集してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２２】
本発明方法の第３の特徴は、上記本発明方法の第２の特徴における前記ログ情報収集処理が、前記１以上のサーバに関する前記１以上のログ情報の収集に際し、前記コンピュータ内に設定されたパフォーマンスモニタを用いてなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２３】
本発明方法の第４の特徴は、上記本発明方法の第２又は第３の特徴における前記コンピュータが、前記ログ情報収集処理において、前記１以上のサーバ中に前記１以上のログ情報を前記所定時間内に収集できないものが存在した場合、そのログ情報収集不能な特定のサーバに関する前記ボトルネック判定処理を実行することなく、その特定のサーバの個体識別子を前記ボトルネックリストに追記する故障候補サーバ追記処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２４】
本発明方法の第５の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなるファイアウォールを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のファイアウォールにおけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定のファイアウォールの個体識別子を前記ボトルネックリストに記載するボトルネックファイアウォール記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２５】
本発明方法の第６の特徴は、上記本発明方法の第５の特徴における前記ログ情報収集処理が、前記１以上のファイアウォールに関する前記パケットロス率の収集に際し、前記コンピュータ内に設定された管理情報ベースを用いてなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２６】
本発明方法の第７の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなる負荷分散装置を含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上の負荷分散装置におけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定の負荷分散装置の個体識別子を前記ボトルネックリストに記載するボトルネック負荷分散装置記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２７】
本発明方法の第８の特徴は、上記本発明方法の第７の特徴における前記ログ情報収集処理が、前記１以上の負荷分散装置から取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴いてなる、サイト領域内ボトルネック特定方法。
【００２８】
本発明方法の第９の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなるサーバＬＡＮを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のサーバＬＡＮにおけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定のサーバＬＡＮの個体識別子を前記ボトルネックリストに記載するボトルネックサーバＬＡＮ記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２９】
本発明方法の第１０の特徴は、上記本発明方法の第９の特徴における前記ログ情報収集処理が、前記１以上のサーバＬＡＮから取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴ってなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００３１】
【発明の実施の形態】
以下、本発明の実施の形態につき、添付図面を参照しつつ、サイト領域に存在する複数のネットワーク要素におけるボトルネック特定を実現するための第１方法例と、同サイト領域に存在する１以上のサーバにおけるボトルネック特定を実現するための第２方法例とを順に挙げて説明する。
【００３２】
（第１方法例）
まず初めに、図１は、本発明の第１方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域のシステム構成を示す図であり、図２は、図１に示したサイト領域内の各ネットワーク要素から収集されるログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【００３３】
まず、図１に示すように、本第１方法例に係るサイト領域内ボトルネック特定方法は、サイト領域に存在する複数のネットワーク要素におけるボトルネック特定を実現するための前提として、インターネット１との接続が図られたサイト領域２ａ内に、３つのサーバＳ１，Ｓ２及びＳ３と、２つのファイアウォールＦ１及びＦ２と、２つの負荷分担装置Ｂ１及びＢ２と、２つのサーバＬＡＮ（ＬＡＮ：Local Area Network）：Ｐ１及びＰ２とを有するシステムに適用されるものとする。
【００３４】
一方、図２に示すように、ネットワーク要素をなすサーバＳ１，Ｓ２及びＳ３には、ログ情報判定項目として、判定閾値を１００ＭＢ／ｓ（メガバイト／秒．上限値）としたＮＩＣ使用総帯域（ＮＩＣ：Network Information Card）と、判定閾値を５０％（上限値）としたＣＰＵ使用率（ＣＰＵ：Central Processing Unit ）とが設定されているものとする。
【００３５】
また、ネットワーク要素をなすファイアウォールＦ１及びＦ２、負荷分担装置Ｂ１及びＢ２、並びにサーバＬＡＮ：Ｐ１及びＰ２には、ログ情報判定項目として、それぞれ、判定閾値を２．０％としたパケットロス率が設定されているものとする。
【００３６】
なお、以上のログ情報判定項目及び対応する判定閾値が設定されたボトルネック閾値テーブル３ａは、サイト領域２ａに設置された任意のコンピュータに保持されるようになっており、同コンピュータとしては、サイト領域２ａ内に存在する何れかのサーバ（Ｓ１，Ｓ２又はＳ３）を当てたり、或いは、これらサーバ（Ｓ１，Ｓ２又はＳ３）とは独立して、同サイト領域２ａ内に個別に設置することが可能である。
【００３７】
次に、図３は、本発明の第１方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【００３８】
同図に示すように、この方法例に係るサーバ領域内ボトルネック特定方法は、上述したコンピュータが、まず、サーバＳ１，Ｓ２及びＳ３におけるボトルネックの特定（ＳＴ１）と、ファイアウォールＦ１及びＦ２におけるボトルネックの特定（ＳＴ２）と、負荷分担装置Ｂ１及びＢ２におけるボトルネックの特定（ＳＴ３）と、サーバＬＡＮ：Ｐ１及びＰ２におけるボトルネックの特定（ＳＴ４）とをそれぞれ実行することにより開始される（実行順序は問わず）。
【００３９】
以上の各ボトルネックの特定に際し、コンピュータは、各ネットワーク要素の処理能力の判定に供し得るログ情報として、サーバＳ１，Ｓ２及びＳ３からは、ＮＩＣ使用総帯域及びＣＰＵ使用率を所定時間に亙って収集し、ファイアウォールＦ１及びＦ２、負荷分担装置Ｂ１及びＢ２、並びにサーバＬＡＮ：Ｐ１及びＰ２からは、パケットロス率を所定時間に亙って収集する（ログ情報収集処理）。
【００４０】
なお、コンピュータが、サーバＳ１，Ｓ２及びＳ３からＮＩＣ使用総帯域及びＣＰＵ使用率を収集する際には、同コンピュータ内に設定されたパフォーマンスモニタ（ソフトウェア手段．図示せず）を利用することができ、ファイアウォールＦ１及びＦ２からパケットロス率を収集する際には、同コンピュータ内に設定された管理情報ベース（ＭＩＢ：Management Information Base ）を利用することができる。
【００４１】
また、同コンピュータが、負荷分担装置Ｂ１及びＢ２並びにサーバＬＡＮ：Ｐ１及びＰ２からパケットロス率を収集する際には、これら各ネットワーク要素から取得したパケット送受信のカウンタ数に基づいて、所要のパケットロス率を計算するようにするとよい。
【００４２】
次に、コンピュータは、図４（ａ）〜（ｄ）に例示するように、各ネットワーク要素毎に得られるログ情報の観測値を、自身が保持するログ情報観測値テーブル４ａに書き出し、当該ログ情報観測値と、これらに対応して予め設定されたボトルネック閾値テーブル３ａにおける判定閾値とを比較して、それら各ネットワーク要素がボトルネックを構成するか否かを判定する（ボトルネック判定処理）。なお、図中に示す「○」は、該当するネットワーク要素がボトルネックを構成しないと判定されたことを意味する（後に示す「●」は、該当するネットワーク要素がボトルネックを構成すると判定されたことを意味する。以下同じ）。
【００４３】
このとき、コンピュータは、先に収集したＮＩＣ使用総帯域及びＣＰＵ使用率のうちボトルネックの判定基準とすべき単一のログ情報（詳細は第２方法例にて述べる）を、対応する上記判定閾値と比較した結果、その単一のログ情報が判定閾値の許容範囲外であった場合に、該当するサーバの個体識別子（Ｓ１，Ｓ２又はＳ３）をボトルネックリスト（図示せず）に記載するようにする（ボトルネックサーバ記載処理）。
【００４４】
また、同コンピュータは、収集したパケットロス率を、対応する上記判定閾値と比較した結果、それが判定閾値の許容範囲外であった場合に、該当する特定のファイアウォールの個体識別子（Ｆ１又はＦ２）、負荷分担装置の個体識別子（Ｂ１又はＢ２）、及びサーバＬＡＮの個体識別子（Ｐ１又はＰ２）をボトルネックリストに記載するようにする（ボトルネックファイアウォール記載処理、ボトルネック負荷分担装置記載処理、及びボトルネックサーバＬＡＮ記載処理）。
【００４５】
次に、コンピュータは、上記ボトルネックリストが空（φ）であるか否かを判別する（ＳＴ５）。以上の例示では、全てのネットワーク要素がボトルネックを構成しないと判定されており、その結果、ボトルネックリストが空であるため（ＳＴ５；ＹＥＳ）、同コンピュータは、今回の観測では、特定すべきボトルネックがサイト領域２ａ内に全く存在しなかったものと判断する（ＳＴ６）。
【００４６】
これに対し、図５（ａ）〜（ｄ）に例示するように、ログ情報観測値テーブル４ｂに書き出された各ネットワーク要素毎のログ情報観測値のうち、サーバＳ２のＣＰＵ使用率とファイアウォールＦ１のパケットロス率とが、共に判定閾値の許容範囲外であり、これら各ネットワーク要素がボトルネックを構成すると判定された場合、コンピュータは、該当する個体識別子Ｓ２及びＦ１をボトルネックリストに記載する。
【００４７】
そして、コンピュータは、上記ボトルネックリストが空であるか否かを判別するが、今回は、当該ボトルネックリストが空ではないため（ＳＴ５；ＮＯ）、ボトルネックが、サイト領域２ａ内のサーバＳ２及びファイアウォールＦ１に存在していると判断し、そのボトルネックリストを外部に出力する（ＳＴ７）。
【００４８】
（第２方法例）
続いて、図６は、本発明の第２方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域の部分システム構成を示す図であり、図７は、本発明の第２方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【００４９】
まず、図６に示すように、本第２方法例に係るサイト領域内ボトルネック特定方法は、サイト領域に存在する１以上のサーバにおけるボトルネック特定を実現するための前提として、サイト領域２ｂ内に、５つのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５を有するシステムに適用されるものとする（ファイアウォール、負荷分担装置、及びサーバＬＡＮの数及び有無は問わない）。
【００５０】
また、上記サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報判定項目としては、第１方法例における場合と同様、判定閾値を１００ＭＢ／ｓ（上限値）としたＮＩＣ使用総帯域と、判定閾値を５０％（上限値）としたＣＰＵ使用率とが設定されており、これらＮＩＣ使用総帯域及びＣＰＵ使用率のうち、ボトルネックの判定基準、即ち、優先的に判定すべき単一のログ情報として、システム保守者（図示せず）により「ＣＰＵ使用率」が選択されているものとする。
【００５１】
そして、図７に示すように、この方法例に係るサーバ領域内ボトルネック特定方法は、サイト領域２ｂ内のコンピュータが、まず、サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５におけるログ情報を、所定時間Ｔに亙り間隔ｔでｘ回収集するためのタイムスライスτ（１≦τ≦ｘ，ｘ＝Ｔ／ｔ）に「１」をセットすると共に（ＳＴ１１）、サーバの個体識別子をＳｉ（１≦ｉ≦ｎ，ｎ＝５）としたときのカウンタに「１」をセットし（ＳＴ１２）、さらに、該当するＳ１のログ情報の収集（ＳＴ１３）を実行することにより開始される。なお、以降の説明では、簡単のため、各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報の収集回数ｘを「ｘ＝３」とする。
【００５２】
次に、コンピュータは、サーバＳ１に関するログ情報が正常に収集できたか否かを判別し（ＳＴ１４）、当該ログ情報が正常に収集できている場合には（ＳＴ１４；ＹＥＳ）、タイムスライスτ＝１におけるサーバＳ１内のボトルネックを判定する（ＳＴ１５）。
【００５３】
次に、コンピュータは、カウンタｉを「１」インクリメントし（ＳＴ１６）、上述したタイムスライスτ＝１におけるＳＴ１３以降の処理を、サーバＳ２，Ｓ３，Ｓ４及びＳ５についても同様に実行し（ＳＴ１７：ＮＯ）、そのカウンタｉの値が規定値の「５（＝ｎ）」を上回った時点で（ＳＴ１７；ＹＥＳ）、タイムスライスτを「１」インクリメントする（ＳＴ１８）。
【００５４】
そして、コンピュータは、今度は、タイムスライスτ＝２におけるＳＴ１２以降の処理を、全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５についても同様に実行し（ＳＴ１９；ＮＯ）、以下、この繰り返し処理を、そのタイムスライスτの値が規定値の「３（＝ｘ）」を上回るまで実行する（ＳＴ１９；ＹＥＳ）。
【００５５】
以上の処理の結果、コンピュータ内に、図８に示すようなログ情報観測値テーブル４ｃが得られたとする。このとき、全てのタイムスライスτ＝１，２，３において所要のログ情報が正常に収集できており、しかも、全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関し、判定閾値を超過したログ情報が全く存在していないため、コンピュータは、今回の観測では、特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在しなかったものと判断する（ボトルネックリストには何も記載しない）。
【００５６】
これに対し、コンピュータ内に、図９に示すようなログ情報観測値テーブル４ｄが得られた場合、同コンピュータは、サーバＳ１における所要のログ情報（ＮＩＣ使用総帯域及びＣＰＵ使用率）が、全てのタイムスライスτ＝１，２，３の何れにおいても正常に収集できなかったとして（ＳＴ１４；ＮＯ）、該当する個体識別子Ｓ１を、自身に保持される故障候補リスト（図示せず）に記載する（ＳＴ２０）。但し、この故障候補リストへの個体識別子の記載は、図７のフローチャートからも明らかなように、実際には、前述した処理の過程において（所要のログ情報を正常に収集できなかったことが判明した時点で）随時実行される。
【００５７】
次に、コンピュータは、上記故障候補リストに、同一の個体識別子により特定されるサーバ（Ｓ１）がｘ個（３個）あるか否かを判別するが（ＳＴ２１）、図９のログ情報観測値テーブル４ｄによれば、サーバＳ１における所要のログ情報が全てのタイムスライスτ＝１，２，３において正常に収集されておらず、その度に上述のＳＴ２０の処理が実行され、当該故障候補リストには同一のサーバ（個体識別子Ｓ１）が３個存在することになるため（ＳＴ２１；ＹＥＳ）、同コンピュータは、その故障候補リストの内容（個体識別子Ｓ１）をボトルネックリストに追記する（ＳＴ２２．故障候補サーバ追記処理）。
【００５８】
なお、図９のログ情報観測値テーブル４ｄに示されるサーバＳ１以外の残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５に関しては、判定閾値を超過したログ情報が存在していないため、コンピュータは、特定すべきボトルネックが、これら残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５には存在しなかったものと判断する（これら残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５に関しては、ボトルネックリストには何も記載しない）。
【００５９】
次に、コンピュータは、上記故障候補リストに、同一の個体識別子により特定されるサーバがｘ個存在しない場合には（ＳＴ２１；ＮＯ）、特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在していないとして、今度は、ボトルネックリストに、ｋ個を超えるサーバ（個体識別子）があるか否かを判別する（ＳＴ２３）。
【００６０】
なお、以上に示す「ｋ」なる値は、システム保守者により指定される数（指定数）であり、上記ボトルネックリスト中に、仮にこの指定数を超えるサーバ（個体識別子）が存在している場合に、障害が重度に及んでいるボトルネックのみを最終的なボトルネックリストへ出力させて、軽度のボトルネックに関する不要な出力を排除するためのものである。なお、以降の説明では、簡単のため、この指定数ｋを「ｋ＝３」とする。
【００６１】
ここで、システム保守者によりボトルネックの判定基準として事前に選択された「ＣＰＵ使用率」に基づき、サーバＳ１，Ｓ２，Ｓ３及びＳ４がボトルネックと判定され、それらの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４がボトルネックリストに記載されているものとする。
【００６２】
そして、これに伴い、コンピュータ内に、図１０に示すようなログ情報観測値テーブル４ｅが得られており、サーバＳ１，Ｓ２及びＳ３に関するＣＰＵ使用率が、全てのタイムスライスτ＝１，２，３において判定閾値を超過し、かつ、サーバＳ４に関するＣＰＵ使用率が、タイムスライスτ＝３において判定閾値を超過しているものとする（超過項目を下線により示す。以下同じ）。
【００６３】
このとき、コンピュータは、ボトルネックリストにｋ個（３個）を超える４個のサーバの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４が存在するとして（ＳＴ２３；ＹＥＳ）、そのボトルネックリストに記載のサーバＳ１，Ｓ２，Ｓ３及びＳ４に関する各ログ情報、即ち、各ＣＰＵ使用率の平均値を算出する（ＳＴ２４．ログ情報平均値算出処理）。
【００６４】
この結果、コンピュータは、図１１に示すような新たなログ情報観測値テーブル４ｆを得て、これら各ＣＰＵ使用率（各ログ情報）の平均値を元に、各サーバの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４を判定閾値（５０％）との差異が大きい順にソートし（Ｓ２（＝９０）＞Ｓ１（＝７０）＞Ｓ３（＝６０）＞Ｓ４（＝４０））、上位３個（ｋ個）のサーバに関する個体識別子、即ち、Ｓ２，Ｓ１及びＳ３を抽出する（ＳＴ２５．サーバ指定数抽出処理）。
【００６５】
なお、図１０のログ情報観測値テーブル４ｅに示される全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５には、ＮＩＣ使用総帯域に関して判定閾値を超過したログ情報が存在していないため、コンピュータは、同ＮＩＣ使用総帯域につき特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在しなかったものと判断する（ボトルネックリストには何も記載しない）。
【００６６】
そして以下、コンピュータは、上述したＳＴ２５の処理で抽出した上位３個のサーバに関する個体識別子Ｓ２，Ｓ１及びＳ３を、最終的なボトルネックリストに出力すると共に、前述したＳＴ２０〜ＳＴ２２の処理において、ボトルネックリストに故障候補リストの内容が追記された場合には、その内容により示されるサーバの個体識別子（図９の例では「Ｓ１」）を、故障のサーバを示すものとして、最終的なボトルネックリストに出力する（ＳＴ２６）。
【００６７】
これに対し、コンピュータ内に、図１２に示すようなログ情報観測値テーブル４ｇが得られており、サーバＳ１に関するＣＰＵ使用率のみが、タイムスライスτ＝３において判定閾値を超過している場合、同コンピュータは、ボトルネックリストに、ｋ個（３個）を超えない１個のサーバの個体識別子Ｓ１のみが存在するとして（ＳＴ２３；ＮＯ）、上述したＳＴ２４及びＳＴ２５の処理を実行することなく、該当する個体識別子Ｓ１を、ボトルネックを構成するサーバとして、最終的なボトルネックリストに出力する。
【００６８】
なお、以上の第２方法例の説明では、サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報判定項目として、ＮＩＣ使用総帯域及びＣＰＵ使用率を挙げたが、この他にも、例えば、利用可能ＲＡＭメモリ残量（ＲＡＭ：Random Access Memory）、ＨＤＤデータ読込み速度（ＨＤＤ：Hard Disk Drive ）、接続待ちクライアント数、秒間累積発生エラー数などを併せて適用することが可能であり、これら各ログ情報判定項目は、何れも、コンピュータ内に設定された前述のパフォーマンスモニタにより収集することが可能である。
【００６９】
最後に、以上の第２方法例で説明したサーバ内ボトルネック判定処理（図７のフローチャートにおけるＳＴ１５の処理）につき、上述した多数のログ情報判定項目を適用した場合の具体例を挙げて説明する。
【００７０】
図１３は、図６に示したサイト領域２ｂ内の各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５から収集される各種ログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図であり、図１４は、図７に示したサーバ内ボトルネック判定処理の詳細を説明するためのフローチャートである。
【００７１】
まず、図１３に示すように、コンピュータ内に設定されたボトルネック閾値テーブル３ｂには、サイト領域２ｂ内の各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５のログ情報判定項目として、判定閾値を１００ＭＢ（下限値）とした利用可能ＲＡＭメモリ残量と、判定閾値を１０ＭＢ／ｓ（上限値）としたＮＩＣ使用総帯域と、判定閾値を５０％（上限値）としたＣＰＵ使用率と、判定閾値を５０ＭＢ／ｓ（上限値）としたＨＤＤデータ読込み速度と、判定閾値を１（上限値）とした接続待ちクライアント数と、判定閾値を１個／ｓ（上限値）とした秒間累積発生エラー数とが設定されているものとする。
【００７２】
また、サーバＳ１に関するログ情報として、利用可能ＲＡＭメモリ残量：２００ＭＢ、ＮＩＣ使用総帯域：５ＭＢ／ｓ、ＣＰＵ使用率：３０％、ＨＤＤデータ読込み速度：３０ＭＢ／ｓ、接続待ちクライアント数：０、秒間累積発生エラー数：０個／ｓがそれぞれ収集され、サーバＳ２に関するログ情報として、利用可能ＲＡＭメモリ残量：５０ＭＢ、ＮＩＣ使用総帯域：５ＭＢ／ｓ、ＣＰＵ使用率：３０％、ＨＤＤデータ読込み速度：３０ＭＢ／ｓ、接続待ちクライアント数：０、秒間累積発生エラー数：０個／ｓがそれぞれ収集されたものとする。
【００７３】
ここで、まず、サーバＳ１のログ情報に基づくサーバ内ボトルネック判定処理に際しては、図１４に示すように、利用可能ＲＡＭメモリ残量が閾値未満（ＳＴ３１；ＮＯ）であり、ＮＩＣ使用総帯域が閾値以上（ＳＴ３２；ＮＯ）であり、ＣＰＵ使用率が閾値以上（ＳＴ３３；ＮＯ）であり、ＨＤＤデータ読込み速度が閾値以上（ＳＴ３４；ＮＯ）であり、接続待ちクライアント数が閾値以上（ＳＴ３５；ＮＯ）であり、秒間累積発生エラー数が閾値以上（ＳＴ３６；ＮＯ）であるため、コンピュータは、ボトルネックリストにサーバＳ１（個体識別子）を記載しない（ＳＴ３７）。
【００７４】
これに対し、サーバＳ２のログ情報に基づくサーバ内ボトルネック判定処理に際しては、同図に示すように、利用可能ＲＡＭメモリ残量が閾値以上（ＳＴ３１；ＹＥＳ）であるため（図１３参照）、コンピュータは、ボトルネックリストにサーバＳ２（個体識別子）を記載するようにする（ＳＴ３８）。
【００７５】
以上、本発明の実施の形態につき、第１及び第２方法例を挙げて説明したが、本発明は、必ずしも上述した手法にのみ限定されるものではなく、本発明にいう目的を達成し、後述の効果を有する範囲内において、適宜、変更実施することが可能なものである。
【００７６】
【発明の効果】
以上、詳細に説明したように、本発明によれば、サイト領域に存在する複数のネットワーク要素の性能低下や障害などの故障を、観測値を元にいち早く把握するようにしたことから、それら複数のネットワーク要素におけるボトルネック、特に、１以上のサーバにおけるボトルネックを、極めて効率良く特定することが可能になる。
【図面の簡単な説明】
【図１】本発明の第１方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域のシステム構成を示す図である。
【図２】図１に示したサイト領域内の各ネットワーク要素から収集されるログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【図３】本発明の第１方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【図４】本発明の第１方法例において適用されるログ情報観測値テーブルの一例を示す図である。
【図５】本発明の第１方法例において適用されるログ情報観測値テーブルの他の例を示す図である。
【図６】本発明の第２方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域の部分システム構成を示す図である。
【図７】本発明の第２方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【図８】本発明の第２方法例において適用されるログ情報観測値テーブルの一例を示す図である。
【図９】本発明の第２方法例において適用されるログ情報観測値テーブルの他の例を示す図である。
【図１０】本発明の第２方法例において適用されるログ情報観測値テーブルのさらに他の例を示す図である。
【図１１】図１０に示したログ情報観測値テーブルからログ情報の平均値を算出して得た新たなログ情報観測値テーブルを示す図である。
【図１２】本発明の第２方法例において適用されるログ情報観測値テーブルのさらにまた他の例を示す図である。
【図１３】図６に示したサイト領域内の各サーバ収集される各種ログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【図１４】図７に示したサーバ内ボトルネック判定処理の詳細を説明するためのフローチャートである。
【符号の説明】
１…インターネット
２ａ，２ｂ…サイト領域
３ａ，３ｂ…ボトルネック閾値テーブル
４ａ〜４ｇ…ログ情報観測値テーブル
Ｓ１〜Ｓ５…サーバ
Ｆ１，Ｆ２…ファイアウォール
Ｂ１，Ｂ２…負荷分散装置
Ｐ１，Ｐ２…サーバＬＡＮ
【発明の属する技術分野】
本発明は、サイト領域内ボトルネック特定方法に関し、詳しくは、インターネットのエンド・トゥ・サーバ（End-to-Server ）におけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するためのサイト領域内ボトルネック特定方法に係わる。
【０００２】
【従来の技術】
近年、インターネットにおける性能、経済性、信頼性といったネットワーク品質に対する関心が高まり、広域ネットワークの特性を計測する手法の重要性が増してきている。
【０００３】
例えば、ＭＳＰ（Managed Service Provider）において、映像等の大衆向け配信サービスを提供するアプリケーション、ネットワーク、サーバを対象とした品質管理サービス事業を効率良く実現するには、対象ネットワークの品質劣化監視及びその検出分析を行うことが必須となる。
【０００４】
このため、上記のようなサービスを提供する際に、エンドユーザからの申告等によりネットワーク品質に劣化が生じていることが判明した場合には、サービス提供者は、その劣化の要因となっている対象ネットワーク上の箇所、即ちボトルネックを早急かつ的確に特定し、これに対処することが責務であるといえる。
【０００５】
従来、対象ネットワーク上のエンド・トゥ・サーバにおけるボトルネックを特定する方法としては、その対象ネットワーク上に存在する全てのサーバの中で、何れのサーバがボトルネックとなっているかをリモートで逐一検査していくものが知られている。
【０００６】
しかし、この方法では、対象ネットワークが大規模になるにつれて、自ずと適用性が悪くなり、当該対象ネットワーク中におけるボトルネック特定箇所を総合的に判断することも困難である。
【０００７】
これに対し、対象ネットワーク上のエンド・トゥ・エンド（End-to-End）におけるボトルネックを特定する方法として、ＭＩＮＣプロジェクト（ＭＩＮＣ：Multicast-based Inference of Network-internal Characteristics ）によるものが知られている。
【０００８】
このＭＩＮＣプロジェクトによる方法は、マルチキャストにより、対象ネットワーク上の１つの始点から多数の終点へ向けて試験パケットを送信し、このときのエンド・トゥ・エンドの観測データからパス上の特性を得て、その対象ネットワーク中のパケットロスや遅延を推定するものである。
【０００９】
【発明が解決しようとする課題】
しかしながら、上述のＭＩＮＣプロジェクトによる方法は、マルチキャスト適用時における木構造の特質から理論的には高い精度を持つものの、インターネットが、その広域性と管理主体の分散に起因して、その状態を直接的に管理し制御することが困難な対象であるため、以下に示すような問題を有している。
【００１０】
即ち、ＭＩＮＣプロジェクトによる方法に用いられるマルチキャストは、現在運用されているインターネットでは実用的でないため柔軟性が低く、また、試験パケットによる片道特性の観測は、現在運用されているインターネットでは困難な場合がある。
【００１１】
以上の問題を解消するには、所要のボトルネック特定方法が、パス全体が木構造をとらないネットワークに対しても適用可能であることが条件となるが、以上のＭＩＮＣプロジェクトによる手法を木構造以外のネットワークに適用することはできず、現時点では、これを実際のＩＳＰ（Internet Service Provider ）に適用することも事実上困難である。
【００１２】
即ち、現状では、インターネット上に分散した複数のネットワーク要素に生じ得るボトルネックを直接的に特定することが困難であるため、そのボトルネックを他の計測データから統計的に推定可能な新たな技術が必要とされている。
【００１３】
ここにおいて、本発明の解決すべき主要な目的は、次のとおりである。
【００１４】
即ち、本発明の第１の目的は、サイト領域に存在する複数のネットワーク要素におけるボトルネックを効率良く特定することの可能なサイト領域内ボトルネック特定方法を提供せんとするものである。
【００１５】
本発明の第２の目的は、サイト領域に存在する１以上のサーバにおけるボトルネックを特に効率良く特定することの可能なサイト領域内ボトルネック特定方法を提供せんとするものである。
【００１６】
本発明の他の目的は、明細書、図面、特に特許請求の範囲の各請求項の記載から、自ずと明らかとなろう。
【００１７】
【課題を解決するための手段】
本発明方法においては、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにおいて、各ネットワーク要素の処理能力の判定に供し得るログ情報を収集するログ情報収集処理と、各ネットワーク要素のログ情報に基づいて、当該各ネットワーク要素がボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、各ネットワーク要素中にボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理とを順次実行する、という特徴的構成手法を講じる。
【００１８】
さらに具体的詳細に述べると、当該課題の解決は、本発明が、以下に列挙する上位概念から下位概念に亙る新規な特徴的構成手法を採用することにより、前記目的を達成するよう為される。
【００１９】
即ち、本発明方法の第１の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記コンピュータは、前記ボトルネック判定処理において、その収集した前記１以上のログ情報中において前記ボトルネックの判定基準とすべき単一のログ情報を当該コンピュータ内に予め対応設定された判定閾値と比較した結果、当該単一のログ情報が当該判定閾値の許容範囲外であった場合に、該当する特定のサーバの個体識別子を前記ボトルネックリストに記載するボトルネックサーバ記載処理、を経た後の当該ボトルネックリスト中に、指定数を超える当該特定のサーバの前記個体識別子が存在すると、前記ログ情報収集処理において前記所定時間内に収集した当該単一のログ情報の平均値を算出するログ情報平均値算出処理と、その算出した前記単一のログ情報の前記平均値を元に、前記特定のサーバの前記個体識別子を前記判定閾値との差異が大きいものから順に前記指定数だけ抽出するサーバ指定数抽出処理と、その指定数だけ抽出した前記特定のサーバの前記個体識別子により、前記ボトルネックサーバ記載処理を経た後の前記ボトルネックリストの内容を書き換えるボトルネックリスト書換処理と、を順次実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２１】
本発明方法の第２の特徴は、上記本発明方法の第１の特徴における前記複数のネットワーク要素が、その１つの要素として、１以上からなるサーバを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のサーバにおける利用可能ＲＡＭメモリ残量、ＮＩＣ使用総帯域、ＣＰＵ使用率、ＨＤＤデータ読込み速度、接続待ちクライアント数、及び秒間累積発生エラー数のうち１以上を収集してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２２】
本発明方法の第３の特徴は、上記本発明方法の第２の特徴における前記ログ情報収集処理が、前記１以上のサーバに関する前記１以上のログ情報の収集に際し、前記コンピュータ内に設定されたパフォーマンスモニタを用いてなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２３】
本発明方法の第４の特徴は、上記本発明方法の第２又は第３の特徴における前記コンピュータが、前記ログ情報収集処理において、前記１以上のサーバ中に前記１以上のログ情報を前記所定時間内に収集できないものが存在した場合、そのログ情報収集不能な特定のサーバに関する前記ボトルネック判定処理を実行することなく、その特定のサーバの個体識別子を前記ボトルネックリストに追記する故障候補サーバ追記処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２４】
本発明方法の第５の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなるファイアウォールを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のファイアウォールにおけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定のファイアウォールの個体識別子を前記ボトルネックリストに記載するボトルネックファイアウォール記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２５】
本発明方法の第６の特徴は、上記本発明方法の第５の特徴における前記ログ情報収集処理が、前記１以上のファイアウォールに関する前記パケットロス率の収集に際し、前記コンピュータ内に設定された管理情報ベースを用いてなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２６】
本発明方法の第７の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなる負荷分散装置を含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上の負荷分散装置におけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定の負荷分散装置の個体識別子を前記ボトルネックリストに記載するボトルネック負荷分散装置記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２７】
本発明方法の第８の特徴は、上記本発明方法の第７の特徴における前記ログ情報収集処理が、前記１以上の負荷分散装置から取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴いてなる、サイト領域内ボトルネック特定方法。
【００２８】
本発明方法の第９の特徴は、インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、前記複数のネットワーク要素が、その１つの要素として、１以上からなるサーバＬＡＮを含んで構成され、前記ログ情報収集処理が、所要の前記ログ情報として、当該１以上のサーバＬＡＮにおけるパケットロス率を収集し、前記コンピュータが、前記ボトルネック判定処理において、その収集した前記パケットロス率を当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、該当する特定のサーバＬＡＮの個体識別子を前記ボトルネックリストに記載するボトルネックサーバＬＡＮ記載処理、を実行してなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００２９】
本発明方法の第１０の特徴は、上記本発明方法の第９の特徴における前記ログ情報収集処理が、前記１以上のサーバＬＡＮから取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴ってなる、サイト領域内ボトルネック特定方法の構成採用にある。
【００３１】
【発明の実施の形態】
以下、本発明の実施の形態につき、添付図面を参照しつつ、サイト領域に存在する複数のネットワーク要素におけるボトルネック特定を実現するための第１方法例と、同サイト領域に存在する１以上のサーバにおけるボトルネック特定を実現するための第２方法例とを順に挙げて説明する。
【００３２】
（第１方法例）
まず初めに、図１は、本発明の第１方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域のシステム構成を示す図であり、図２は、図１に示したサイト領域内の各ネットワーク要素から収集されるログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【００３３】
まず、図１に示すように、本第１方法例に係るサイト領域内ボトルネック特定方法は、サイト領域に存在する複数のネットワーク要素におけるボトルネック特定を実現するための前提として、インターネット１との接続が図られたサイト領域２ａ内に、３つのサーバＳ１，Ｓ２及びＳ３と、２つのファイアウォールＦ１及びＦ２と、２つの負荷分担装置Ｂ１及びＢ２と、２つのサーバＬＡＮ（ＬＡＮ：Local Area Network）：Ｐ１及びＰ２とを有するシステムに適用されるものとする。
【００３４】
一方、図２に示すように、ネットワーク要素をなすサーバＳ１，Ｓ２及びＳ３には、ログ情報判定項目として、判定閾値を１００ＭＢ／ｓ（メガバイト／秒．上限値）としたＮＩＣ使用総帯域（ＮＩＣ：Network Information Card）と、判定閾値を５０％（上限値）としたＣＰＵ使用率（ＣＰＵ：Central Processing Unit ）とが設定されているものとする。
【００３５】
また、ネットワーク要素をなすファイアウォールＦ１及びＦ２、負荷分担装置Ｂ１及びＢ２、並びにサーバＬＡＮ：Ｐ１及びＰ２には、ログ情報判定項目として、それぞれ、判定閾値を２．０％としたパケットロス率が設定されているものとする。
【００３６】
なお、以上のログ情報判定項目及び対応する判定閾値が設定されたボトルネック閾値テーブル３ａは、サイト領域２ａに設置された任意のコンピュータに保持されるようになっており、同コンピュータとしては、サイト領域２ａ内に存在する何れかのサーバ（Ｓ１，Ｓ２又はＳ３）を当てたり、或いは、これらサーバ（Ｓ１，Ｓ２又はＳ３）とは独立して、同サイト領域２ａ内に個別に設置することが可能である。
【００３７】
次に、図３は、本発明の第１方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【００３８】
同図に示すように、この方法例に係るサーバ領域内ボトルネック特定方法は、上述したコンピュータが、まず、サーバＳ１，Ｓ２及びＳ３におけるボトルネックの特定（ＳＴ１）と、ファイアウォールＦ１及びＦ２におけるボトルネックの特定（ＳＴ２）と、負荷分担装置Ｂ１及びＢ２におけるボトルネックの特定（ＳＴ３）と、サーバＬＡＮ：Ｐ１及びＰ２におけるボトルネックの特定（ＳＴ４）とをそれぞれ実行することにより開始される（実行順序は問わず）。
【００３９】
以上の各ボトルネックの特定に際し、コンピュータは、各ネットワーク要素の処理能力の判定に供し得るログ情報として、サーバＳ１，Ｓ２及びＳ３からは、ＮＩＣ使用総帯域及びＣＰＵ使用率を所定時間に亙って収集し、ファイアウォールＦ１及びＦ２、負荷分担装置Ｂ１及びＢ２、並びにサーバＬＡＮ：Ｐ１及びＰ２からは、パケットロス率を所定時間に亙って収集する（ログ情報収集処理）。
【００４０】
なお、コンピュータが、サーバＳ１，Ｓ２及びＳ３からＮＩＣ使用総帯域及びＣＰＵ使用率を収集する際には、同コンピュータ内に設定されたパフォーマンスモニタ（ソフトウェア手段．図示せず）を利用することができ、ファイアウォールＦ１及びＦ２からパケットロス率を収集する際には、同コンピュータ内に設定された管理情報ベース（ＭＩＢ：Management Information Base ）を利用することができる。
【００４１】
また、同コンピュータが、負荷分担装置Ｂ１及びＢ２並びにサーバＬＡＮ：Ｐ１及びＰ２からパケットロス率を収集する際には、これら各ネットワーク要素から取得したパケット送受信のカウンタ数に基づいて、所要のパケットロス率を計算するようにするとよい。
【００４２】
次に、コンピュータは、図４（ａ）〜（ｄ）に例示するように、各ネットワーク要素毎に得られるログ情報の観測値を、自身が保持するログ情報観測値テーブル４ａに書き出し、当該ログ情報観測値と、これらに対応して予め設定されたボトルネック閾値テーブル３ａにおける判定閾値とを比較して、それら各ネットワーク要素がボトルネックを構成するか否かを判定する（ボトルネック判定処理）。なお、図中に示す「○」は、該当するネットワーク要素がボトルネックを構成しないと判定されたことを意味する（後に示す「●」は、該当するネットワーク要素がボトルネックを構成すると判定されたことを意味する。以下同じ）。
【００４３】
このとき、コンピュータは、先に収集したＮＩＣ使用総帯域及びＣＰＵ使用率のうちボトルネックの判定基準とすべき単一のログ情報（詳細は第２方法例にて述べる）を、対応する上記判定閾値と比較した結果、その単一のログ情報が判定閾値の許容範囲外であった場合に、該当するサーバの個体識別子（Ｓ１，Ｓ２又はＳ３）をボトルネックリスト（図示せず）に記載するようにする（ボトルネックサーバ記載処理）。
【００４４】
また、同コンピュータは、収集したパケットロス率を、対応する上記判定閾値と比較した結果、それが判定閾値の許容範囲外であった場合に、該当する特定のファイアウォールの個体識別子（Ｆ１又はＦ２）、負荷分担装置の個体識別子（Ｂ１又はＢ２）、及びサーバＬＡＮの個体識別子（Ｐ１又はＰ２）をボトルネックリストに記載するようにする（ボトルネックファイアウォール記載処理、ボトルネック負荷分担装置記載処理、及びボトルネックサーバＬＡＮ記載処理）。
【００４５】
次に、コンピュータは、上記ボトルネックリストが空（φ）であるか否かを判別する（ＳＴ５）。以上の例示では、全てのネットワーク要素がボトルネックを構成しないと判定されており、その結果、ボトルネックリストが空であるため（ＳＴ５；ＹＥＳ）、同コンピュータは、今回の観測では、特定すべきボトルネックがサイト領域２ａ内に全く存在しなかったものと判断する（ＳＴ６）。
【００４６】
これに対し、図５（ａ）〜（ｄ）に例示するように、ログ情報観測値テーブル４ｂに書き出された各ネットワーク要素毎のログ情報観測値のうち、サーバＳ２のＣＰＵ使用率とファイアウォールＦ１のパケットロス率とが、共に判定閾値の許容範囲外であり、これら各ネットワーク要素がボトルネックを構成すると判定された場合、コンピュータは、該当する個体識別子Ｓ２及びＦ１をボトルネックリストに記載する。
【００４７】
そして、コンピュータは、上記ボトルネックリストが空であるか否かを判別するが、今回は、当該ボトルネックリストが空ではないため（ＳＴ５；ＮＯ）、ボトルネックが、サイト領域２ａ内のサーバＳ２及びファイアウォールＦ１に存在していると判断し、そのボトルネックリストを外部に出力する（ＳＴ７）。
【００４８】
（第２方法例）
続いて、図６は、本発明の第２方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域の部分システム構成を示す図であり、図７は、本発明の第２方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【００４９】
まず、図６に示すように、本第２方法例に係るサイト領域内ボトルネック特定方法は、サイト領域に存在する１以上のサーバにおけるボトルネック特定を実現するための前提として、サイト領域２ｂ内に、５つのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５を有するシステムに適用されるものとする（ファイアウォール、負荷分担装置、及びサーバＬＡＮの数及び有無は問わない）。
【００５０】
また、上記サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報判定項目としては、第１方法例における場合と同様、判定閾値を１００ＭＢ／ｓ（上限値）としたＮＩＣ使用総帯域と、判定閾値を５０％（上限値）としたＣＰＵ使用率とが設定されており、これらＮＩＣ使用総帯域及びＣＰＵ使用率のうち、ボトルネックの判定基準、即ち、優先的に判定すべき単一のログ情報として、システム保守者（図示せず）により「ＣＰＵ使用率」が選択されているものとする。
【００５１】
そして、図７に示すように、この方法例に係るサーバ領域内ボトルネック特定方法は、サイト領域２ｂ内のコンピュータが、まず、サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５におけるログ情報を、所定時間Ｔに亙り間隔ｔでｘ回収集するためのタイムスライスτ（１≦τ≦ｘ，ｘ＝Ｔ／ｔ）に「１」をセットすると共に（ＳＴ１１）、サーバの個体識別子をＳｉ（１≦ｉ≦ｎ，ｎ＝５）としたときのカウンタに「１」をセットし（ＳＴ１２）、さらに、該当するＳ１のログ情報の収集（ＳＴ１３）を実行することにより開始される。なお、以降の説明では、簡単のため、各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報の収集回数ｘを「ｘ＝３」とする。
【００５２】
次に、コンピュータは、サーバＳ１に関するログ情報が正常に収集できたか否かを判別し（ＳＴ１４）、当該ログ情報が正常に収集できている場合には（ＳＴ１４；ＹＥＳ）、タイムスライスτ＝１におけるサーバＳ１内のボトルネックを判定する（ＳＴ１５）。
【００５３】
次に、コンピュータは、カウンタｉを「１」インクリメントし（ＳＴ１６）、上述したタイムスライスτ＝１におけるＳＴ１３以降の処理を、サーバＳ２，Ｓ３，Ｓ４及びＳ５についても同様に実行し（ＳＴ１７：ＮＯ）、そのカウンタｉの値が規定値の「５（＝ｎ）」を上回った時点で（ＳＴ１７；ＹＥＳ）、タイムスライスτを「１」インクリメントする（ＳＴ１８）。
【００５４】
そして、コンピュータは、今度は、タイムスライスτ＝２におけるＳＴ１２以降の処理を、全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５についても同様に実行し（ＳＴ１９；ＮＯ）、以下、この繰り返し処理を、そのタイムスライスτの値が規定値の「３（＝ｘ）」を上回るまで実行する（ＳＴ１９；ＹＥＳ）。
【００５５】
以上の処理の結果、コンピュータ内に、図８に示すようなログ情報観測値テーブル４ｃが得られたとする。このとき、全てのタイムスライスτ＝１，２，３において所要のログ情報が正常に収集できており、しかも、全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関し、判定閾値を超過したログ情報が全く存在していないため、コンピュータは、今回の観測では、特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在しなかったものと判断する（ボトルネックリストには何も記載しない）。
【００５６】
これに対し、コンピュータ内に、図９に示すようなログ情報観測値テーブル４ｄが得られた場合、同コンピュータは、サーバＳ１における所要のログ情報（ＮＩＣ使用総帯域及びＣＰＵ使用率）が、全てのタイムスライスτ＝１，２，３の何れにおいても正常に収集できなかったとして（ＳＴ１４；ＮＯ）、該当する個体識別子Ｓ１を、自身に保持される故障候補リスト（図示せず）に記載する（ＳＴ２０）。但し、この故障候補リストへの個体識別子の記載は、図７のフローチャートからも明らかなように、実際には、前述した処理の過程において（所要のログ情報を正常に収集できなかったことが判明した時点で）随時実行される。
【００５７】
次に、コンピュータは、上記故障候補リストに、同一の個体識別子により特定されるサーバ（Ｓ１）がｘ個（３個）あるか否かを判別するが（ＳＴ２１）、図９のログ情報観測値テーブル４ｄによれば、サーバＳ１における所要のログ情報が全てのタイムスライスτ＝１，２，３において正常に収集されておらず、その度に上述のＳＴ２０の処理が実行され、当該故障候補リストには同一のサーバ（個体識別子Ｓ１）が３個存在することになるため（ＳＴ２１；ＹＥＳ）、同コンピュータは、その故障候補リストの内容（個体識別子Ｓ１）をボトルネックリストに追記する（ＳＴ２２．故障候補サーバ追記処理）。
【００５８】
なお、図９のログ情報観測値テーブル４ｄに示されるサーバＳ１以外の残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５に関しては、判定閾値を超過したログ情報が存在していないため、コンピュータは、特定すべきボトルネックが、これら残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５には存在しなかったものと判断する（これら残りのサーバＳ２，Ｓ３，Ｓ４及びＳ５に関しては、ボトルネックリストには何も記載しない）。
【００５９】
次に、コンピュータは、上記故障候補リストに、同一の個体識別子により特定されるサーバがｘ個存在しない場合には（ＳＴ２１；ＮＯ）、特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在していないとして、今度は、ボトルネックリストに、ｋ個を超えるサーバ（個体識別子）があるか否かを判別する（ＳＴ２３）。
【００６０】
なお、以上に示す「ｋ」なる値は、システム保守者により指定される数（指定数）であり、上記ボトルネックリスト中に、仮にこの指定数を超えるサーバ（個体識別子）が存在している場合に、障害が重度に及んでいるボトルネックのみを最終的なボトルネックリストへ出力させて、軽度のボトルネックに関する不要な出力を排除するためのものである。なお、以降の説明では、簡単のため、この指定数ｋを「ｋ＝３」とする。
【００６１】
ここで、システム保守者によりボトルネックの判定基準として事前に選択された「ＣＰＵ使用率」に基づき、サーバＳ１，Ｓ２，Ｓ３及びＳ４がボトルネックと判定され、それらの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４がボトルネックリストに記載されているものとする。
【００６２】
そして、これに伴い、コンピュータ内に、図１０に示すようなログ情報観測値テーブル４ｅが得られており、サーバＳ１，Ｓ２及びＳ３に関するＣＰＵ使用率が、全てのタイムスライスτ＝１，２，３において判定閾値を超過し、かつ、サーバＳ４に関するＣＰＵ使用率が、タイムスライスτ＝３において判定閾値を超過しているものとする（超過項目を下線により示す。以下同じ）。
【００６３】
このとき、コンピュータは、ボトルネックリストにｋ個（３個）を超える４個のサーバの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４が存在するとして（ＳＴ２３；ＹＥＳ）、そのボトルネックリストに記載のサーバＳ１，Ｓ２，Ｓ３及びＳ４に関する各ログ情報、即ち、各ＣＰＵ使用率の平均値を算出する（ＳＴ２４．ログ情報平均値算出処理）。
【００６４】
この結果、コンピュータは、図１１に示すような新たなログ情報観測値テーブル４ｆを得て、これら各ＣＰＵ使用率（各ログ情報）の平均値を元に、各サーバの個体識別子Ｓ１，Ｓ２，Ｓ３及びＳ４を判定閾値（５０％）との差異が大きい順にソートし（Ｓ２（＝９０）＞Ｓ１（＝７０）＞Ｓ３（＝６０）＞Ｓ４（＝４０））、上位３個（ｋ個）のサーバに関する個体識別子、即ち、Ｓ２，Ｓ１及びＳ３を抽出する（ＳＴ２５．サーバ指定数抽出処理）。
【００６５】
なお、図１０のログ情報観測値テーブル４ｅに示される全てのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５には、ＮＩＣ使用総帯域に関して判定閾値を超過したログ情報が存在していないため、コンピュータは、同ＮＩＣ使用総帯域につき特定すべきボトルネックが、何れのサーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５にも存在しなかったものと判断する（ボトルネックリストには何も記載しない）。
【００６６】
そして以下、コンピュータは、上述したＳＴ２５の処理で抽出した上位３個のサーバに関する個体識別子Ｓ２，Ｓ１及びＳ３を、最終的なボトルネックリストに出力すると共に、前述したＳＴ２０〜ＳＴ２２の処理において、ボトルネックリストに故障候補リストの内容が追記された場合には、その内容により示されるサーバの個体識別子（図９の例では「Ｓ１」）を、故障のサーバを示すものとして、最終的なボトルネックリストに出力する（ＳＴ２６）。
【００６７】
これに対し、コンピュータ内に、図１２に示すようなログ情報観測値テーブル４ｇが得られており、サーバＳ１に関するＣＰＵ使用率のみが、タイムスライスτ＝３において判定閾値を超過している場合、同コンピュータは、ボトルネックリストに、ｋ個（３個）を超えない１個のサーバの個体識別子Ｓ１のみが存在するとして（ＳＴ２３；ＮＯ）、上述したＳＴ２４及びＳＴ２５の処理を実行することなく、該当する個体識別子Ｓ１を、ボトルネックを構成するサーバとして、最終的なボトルネックリストに出力する。
【００６８】
なお、以上の第２方法例の説明では、サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５に関するログ情報判定項目として、ＮＩＣ使用総帯域及びＣＰＵ使用率を挙げたが、この他にも、例えば、利用可能ＲＡＭメモリ残量（ＲＡＭ：Random Access Memory）、ＨＤＤデータ読込み速度（ＨＤＤ：Hard Disk Drive ）、接続待ちクライアント数、秒間累積発生エラー数などを併せて適用することが可能であり、これら各ログ情報判定項目は、何れも、コンピュータ内に設定された前述のパフォーマンスモニタにより収集することが可能である。
【００６９】
最後に、以上の第２方法例で説明したサーバ内ボトルネック判定処理（図７のフローチャートにおけるＳＴ１５の処理）につき、上述した多数のログ情報判定項目を適用した場合の具体例を挙げて説明する。
【００７０】
図１３は、図６に示したサイト領域２ｂ内の各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５から収集される各種ログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図であり、図１４は、図７に示したサーバ内ボトルネック判定処理の詳細を説明するためのフローチャートである。
【００７１】
まず、図１３に示すように、コンピュータ内に設定されたボトルネック閾値テーブル３ｂには、サイト領域２ｂ内の各サーバＳ１，Ｓ２，Ｓ３，Ｓ４及びＳ５のログ情報判定項目として、判定閾値を１００ＭＢ（下限値）とした利用可能ＲＡＭメモリ残量と、判定閾値を１０ＭＢ／ｓ（上限値）としたＮＩＣ使用総帯域と、判定閾値を５０％（上限値）としたＣＰＵ使用率と、判定閾値を５０ＭＢ／ｓ（上限値）としたＨＤＤデータ読込み速度と、判定閾値を１（上限値）とした接続待ちクライアント数と、判定閾値を１個／ｓ（上限値）とした秒間累積発生エラー数とが設定されているものとする。
【００７２】
また、サーバＳ１に関するログ情報として、利用可能ＲＡＭメモリ残量：２００ＭＢ、ＮＩＣ使用総帯域：５ＭＢ／ｓ、ＣＰＵ使用率：３０％、ＨＤＤデータ読込み速度：３０ＭＢ／ｓ、接続待ちクライアント数：０、秒間累積発生エラー数：０個／ｓがそれぞれ収集され、サーバＳ２に関するログ情報として、利用可能ＲＡＭメモリ残量：５０ＭＢ、ＮＩＣ使用総帯域：５ＭＢ／ｓ、ＣＰＵ使用率：３０％、ＨＤＤデータ読込み速度：３０ＭＢ／ｓ、接続待ちクライアント数：０、秒間累積発生エラー数：０個／ｓがそれぞれ収集されたものとする。
【００７３】
ここで、まず、サーバＳ１のログ情報に基づくサーバ内ボトルネック判定処理に際しては、図１４に示すように、利用可能ＲＡＭメモリ残量が閾値未満（ＳＴ３１；ＮＯ）であり、ＮＩＣ使用総帯域が閾値以上（ＳＴ３２；ＮＯ）であり、ＣＰＵ使用率が閾値以上（ＳＴ３３；ＮＯ）であり、ＨＤＤデータ読込み速度が閾値以上（ＳＴ３４；ＮＯ）であり、接続待ちクライアント数が閾値以上（ＳＴ３５；ＮＯ）であり、秒間累積発生エラー数が閾値以上（ＳＴ３６；ＮＯ）であるため、コンピュータは、ボトルネックリストにサーバＳ１（個体識別子）を記載しない（ＳＴ３７）。
【００７４】
これに対し、サーバＳ２のログ情報に基づくサーバ内ボトルネック判定処理に際しては、同図に示すように、利用可能ＲＡＭメモリ残量が閾値以上（ＳＴ３１；ＹＥＳ）であるため（図１３参照）、コンピュータは、ボトルネックリストにサーバＳ２（個体識別子）を記載するようにする（ＳＴ３８）。
【００７５】
以上、本発明の実施の形態につき、第１及び第２方法例を挙げて説明したが、本発明は、必ずしも上述した手法にのみ限定されるものではなく、本発明にいう目的を達成し、後述の効果を有する範囲内において、適宜、変更実施することが可能なものである。
【００７６】
【発明の効果】
以上、詳細に説明したように、本発明によれば、サイト領域に存在する複数のネットワーク要素の性能低下や障害などの故障を、観測値を元にいち早く把握するようにしたことから、それら複数のネットワーク要素におけるボトルネック、特に、１以上のサーバにおけるボトルネックを、極めて効率良く特定することが可能になる。
【図面の簡単な説明】
【図１】本発明の第１方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域のシステム構成を示す図である。
【図２】図１に示したサイト領域内の各ネットワーク要素から収集されるログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【図３】本発明の第１方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【図４】本発明の第１方法例において適用されるログ情報観測値テーブルの一例を示す図である。
【図５】本発明の第１方法例において適用されるログ情報観測値テーブルの他の例を示す図である。
【図６】本発明の第２方法例に係るサイト領域内ボトルネック特定方法に適用されるサイト領域の部分システム構成を示す図である。
【図７】本発明の第２方法例に係るサーバ領域内ボトルネック特定方法を説明するためのフローチャートである。
【図８】本発明の第２方法例において適用されるログ情報観測値テーブルの一例を示す図である。
【図９】本発明の第２方法例において適用されるログ情報観測値テーブルの他の例を示す図である。
【図１０】本発明の第２方法例において適用されるログ情報観測値テーブルのさらに他の例を示す図である。
【図１１】図１０に示したログ情報観測値テーブルからログ情報の平均値を算出して得た新たなログ情報観測値テーブルを示す図である。
【図１２】本発明の第２方法例において適用されるログ情報観測値テーブルのさらにまた他の例を示す図である。
【図１３】図６に示したサイト領域内の各サーバ収集される各種ログ情報の判定閾値を規定したボトルネック閾値テーブルを示す図である。
【図１４】図７に示したサーバ内ボトルネック判定処理の詳細を説明するためのフローチャートである。
【符号の説明】
１…インターネット
２ａ，２ｂ…サイト領域
３ａ，３ｂ…ボトルネック閾値テーブル
４ａ〜４ｇ…ログ情報観測値テーブル
Ｓ１〜Ｓ５…サーバ
Ｆ１，Ｆ２…ファイアウォール
Ｂ１，Ｂ２…負荷分散装置
Ｐ１，Ｐ２…サーバＬＡＮ
Claims (10)
- インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、
前記コンピュータは、
前記ボトルネック判定処理において、その収集した前記１以上のログ情報中において前記ボトルネックの判定基準とすべき単一のログ情報を当該コンピュータ内に予め対応設定された判定閾値と比較した結果、当該単一のログ情報が当該判定閾値の許容範囲外であった場合に、該当する特定のサーバの個体識別子を前記ボトルネックリストに記載するボトルネックサーバ記載処理、を経た後の当該ボトルネックリスト中に、指定数を超える当該特定のサーバの前記個体識別子が存在すると、
前記ログ情報収集処理において前記所定時間内に収集した当該単一のログ情報の平均値を算出するログ情報平均値算出処理と、
その算出した前記単一のログ情報の前記平均値を元に、前記特定のサーバの前記個体識別子を前記判定閾値との差異が大きいものから順に前記指定数だけ抽出するサーバ指定数抽出処理と、
その指定数だけ抽出した前記特定のサーバの前記個体識別子により、前記ボトルネックサーバ記載処理を経た後の前記ボトルネックリストの内容を書き換えるボトルネックリスト書換処理と、を順次実行する、
ことを特徴とするサイト領域内ボトルネック特定方法。 - 前記複数のネットワーク要素は、
その１つの要素として、１以上からなるサーバを含んで構成され、
前記ログ情報収集処理は、
所要の前記ログ情報として、当該１以上のサーバにおける利用可能ＲＡＭメモリ残量、ＮＩＣ使用総帯域、ＣＰＵ使用率、ＨＤＤデータ読込み速度、接続待ちクライアント数、及び秒間累積発生エラー数のうち１以上を収集する、
ことを特徴とする請求項１に記載のサイト領域内ボトルネック特定方法。 - 前記ログ情報収集処理は、
前記１以上のサーバに関する前記１以上のログ情報の収集に際し、
前記コンピュータ内に設定されたパフォーマンスモニタを用いる、
ことを特徴とする請求項２に記載のサイト領域内ボトルネック特定方法。 - 前記コンピュータは、
前記ログ情報収集処理において、前記１以上のサーバ中に前記１以上のログ情報を前記所定時間内に収集できないものが存在した場合、
そのログ情報収集不能な特定のサーバに関する前記ボトルネック判定処理を実行することなく、その特定のサーバの個体識別子を前記ボトルネックリストに追記する故障候補サーバ追記処理、を実行する、
ことを特徴とする請求項２又は３に記載のサイト領域内ボトルネック特定方法。 - インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、
前記複数のネットワーク要素は、
その１つの要素として、１以上からなるファイアウォールを含んで構成され、
前記ログ情報収集処理は、
所要の前記ログ情報として、当該１以上のファイアウォールにおけるパケットロス率を収集し、
前記コンピュータは、
前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、
該当する特定のファイアウォールの個体識別子を前記ボトルネックリストに記載するボトルネックファイアウォール記載処理、を実行する、
ことを特徴とするサイト領域内ボトルネック特定方法。 - 前記ログ情報収集処理は、
前記１以上のファイアウォールに関する前記パケットロス率の収集に際し、
前記コンピュータ内に設定された管理情報ベースを用いる、
ことを特徴とする請求項５に記載のサイト領域内ボトルネック特定方法。 - インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、
前記複数のネットワーク要素は、
その１つの要素として、１以上からなる負荷分散装置を含んで構成され、
前記ログ情報収集処理は、
所要の前記ログ情報として、当該１以上の負荷分散装置におけるパケットロス率を収集し、
前記コンピュータは、
前記ボトルネック判定処理において、その収集した前記パケットロス率を、当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、
該当する特定の負荷分散装置の個体識別子を前記ボトルネックリストに記載するボトルネック負荷分散装置記載処理、を実行する、
ことを特徴とするサイト領域内ボトルネック特定方法。 - 前記ログ情報収集処理は、
前記１以上の負荷分散装置から取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴う、
ことを特徴とする請求項７に記載のサイト領域内ボトルネック特定方法。 - インターネットのエンド・トゥ・サーバにおけるサイト領域に設置された任意のコンピュータにより、当該サイト領域に存在する複数のネットワーク要素がボトルネックを構成するか否かを特定するため、前記コンピュータにおいて、前記複数のネットワーク要素から、各ネットワーク要素の処理能力の判定に供し得るログ情報を所定時間に亙ってそれぞれ収集するログ情報収集処理と、その収集した前記各ネットワーク要素の前記ログ情報に基づいて、当該各ネットワーク要素が前記ボトルネックを構成するか否かをそれぞれ判定するボトルネック判定処理と、この判定の結果、前記各ネットワーク要素中に前記ボトルネックを構成する１以上のネットワーク要素が存在した場合に、当該ネットワーク要素の個体識別子を記載してなるボトルネックリストを出力するボトルネックリスト出力処理と、を順次実行するサイト領域内ボトルネック特定方法であって、
前記複数のネットワーク要素は、
その１つの要素として、１以上からなるサーバＬＡＮを含んで構成され、
前記ログ情報収集処理は、
所要の前記ログ情報として、当該１以上のサーバＬＡＮにおけるパケットロス率を収集し、
前記コンピュータは、
前記ボトルネック判定処理において、その収集した前記パケットロス率を当該コンピュータ内に前記各ネットワーク要素毎の前記ログ情報と対応して予め設定された判定閾値と比較した結果、当該パケットロス率が当該判定閾値の許容範囲外であった場合に、
該当する特定のサーバＬＡＮの個体識別子を前記ボトルネックリストに記載するボトルネックサーバＬＡＮ記載処理、を実行する、
ことを特徴とするサイト領域内ボトルネック特定方法。 - 前記ログ情報収集処理は、
前記１以上のサーバＬＡＮから取得したパケット送受信のカウンタ数に基づいて、所要の前記パケットロス率を計算する処理を伴う、
ことを特徴とする請求項９に記載のサイト領域内ボトルネック特定方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002103695A JP3805711B2 (ja) | 2002-04-05 | 2002-04-05 | サイト領域内ボトルネック特定方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002103695A JP3805711B2 (ja) | 2002-04-05 | 2002-04-05 | サイト領域内ボトルネック特定方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003298655A JP2003298655A (ja) | 2003-10-17 |
| JP3805711B2 true JP3805711B2 (ja) | 2006-08-09 |
Family
ID=29389363
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002103695A Expired - Fee Related JP3805711B2 (ja) | 2002-04-05 | 2002-04-05 | サイト領域内ボトルネック特定方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3805711B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100866857B1 (ko) | 2003-10-29 | 2008-11-04 | 인터내셔널 비지네스 머신즈 코포레이션 | 정보 시스템, 부하 제어 방법, 부하 제어 프로그램 및 기록매체 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007052327A1 (ja) * | 2005-10-31 | 2007-05-10 | Fujitsu Limited | 性能異常分析装置、方法及びプログラム、並びに性能異常分析装置の分析結果表示方法 |
| JP4343983B2 (ja) * | 2005-11-24 | 2009-10-14 | ヒューレット−パッカード デベロップメント カンパニー エル．ピー． | ネットワーク管理装置およびネットワークの管理方法 |
| US9794149B2 (en) | 2012-03-30 | 2017-10-17 | Nippon Telegraph And Telephone Corporation | User experienced quality estimation apparatus, terminal bottleneck determination apparatus, similar operation extraction apparatus, method and program |
| JP2014192584A (ja) * | 2013-03-26 | 2014-10-06 | Kddi Corp | 設定装置、端末装置、設定プログラム、計測システム及び計測方法 |
-
2002
- 2002-04-05 JP JP2002103695A patent/JP3805711B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100866857B1 (ko) | 2003-10-29 | 2008-11-04 | 인터내셔널 비지네스 머신즈 코포레이션 | 정보 시스템, 부하 제어 방법, 부하 제어 프로그램 및 기록매체 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003298655A (ja) | 2003-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7836330B2 (en) | Stream distribution system and failure detection method | |
| US7266758B2 (en) | Network monitoring program, network monitoring method, and network monitoring apparatus | |
| US11671342B2 (en) | Link fault isolation using latencies | |
| US9183033B2 (en) | Method and system for analyzing root causes of relating performance issues among virtual machines to physical machines | |
| CN110290012A (zh) | RabbitMQ集群故障的检测恢复***及方法 | |
| US20020177910A1 (en) | Performance measurement system for large computer network | |
| US20030074161A1 (en) | System and method for automated analysis of load testing results | |
| CN103718535B (zh) | 硬件故障的缓解 | |
| EP2657843B1 (en) | Operation management device, operation management method, and program | |
| US8291066B2 (en) | Method and system for transaction monitoring in a communication network | |
| CN105488610A (zh) | 一种电力应用***故障实时分析诊断***及方法 | |
| US7457722B1 (en) | Correlation of application instance life cycle events in performance monitoring | |
| JP5560936B2 (ja) | 構成情報取得方法、仮想プローブおよび構成情報取得制御装置 | |
| JP6220625B2 (ja) | 遅延監視システムおよび遅延監視方法 | |
| US20070086350A1 (en) | Method, system, and computer program product for providing failure detection with minimal bandwidth usage | |
| Martinello et al. | Web service availability—impact of error recovery and traffic model | |
| JP3805711B2 (ja) | サイト領域内ボトルネック特定方法 | |
| US8499074B2 (en) | Method and apparatus for accessing files stored in a storage access network (SAN) or network attached storage (NAS) | |
| Iyer et al. | Measurement-based analysis of networked system availability | |
| Liu et al. | Towards a community cloud storage | |
| US7254638B2 (en) | Method and apparatus for identifying slow links and for providing application-based responses to slow links in a distributed computer network | |
| Borzemski et al. | An Empirical Study of Web Quality: Measuring the Web from Wroclaw University of Technology Campus. | |
| Dutta et al. | ReDAL: an efficient and practical request distribution technique for application server clusters | |
| JP2006033715A (ja) | ネットワークｅ２ｅ性能評価システムと方法およびプログラム | |
| JP2001195285A (ja) | アプリケーション性能劣化要因分析方法，アプリケーション性能劣化要因分析システムおよびそのプログラム記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040802 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060118 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060207 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060330 |
|
| 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: 20060425 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060510 |
|
| 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: 20090519 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110519 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120519 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |