(57)【特許請求の範囲】
【請求項１】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数部と、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数部と、
該第１計数部により計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数部により計数された該応答があった要求の数が第２閾値以上である場合に、障害の予兆を検出する検出部と、をそなえた処理装置。
【請求項２】
該要求が、動的な要求であるか否かを判断する判断部をそなえ、
該第１計数部は、該判断部により、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して該所定時間応答がない要求の数を計数し、
該第２計数部は、該判断部により、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する請求項１記載の処理装置。
【請求項３】
該判断部が、該要求の対象を示す対象情報の種類に基づいて、該動的な要求であるか否かを判断する請求項２記載の処理装置。
【請求項４】
該判断部が、該要求のペイロードの容量に基づいて、該動的な要求であるか否かを判断する請求項２記載の処理装置。
【請求項５】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない該要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
該第１計数ステップにより計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が第２閾値以上である場合に、無応答状態の予兆を検出する検出ステップと、をそなえた処理方法。
【請求項６】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
該第１計数ステップにより計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が第２閾値以上である場合に、無応答状態の予兆を検出する検出ステップと、をコンピュータに実行させる処理用プログラム。
【請求項７】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数部と、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数部と、
第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数部により計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数部により計数された該応答がない要求の数と、該第１の時間範囲において該第２計数部により計数された該応答があった要求の数と、に基づいて障害を検出する検出部と、をそなえた処理装置。
【請求項８】
該検出部が、該第１の時間範囲における、該第１計数部により計数された該応答がない要求の数が第１閾値以上であるとともに、該第１の時間範囲における、該第２計数部により計数された該応答があった要求の数が第２閾値以上であり、かつ、該無応答数が、第３閾値より大きい場合、該障害として、該サーバが無応答になる予兆を検出する請求項７記載の処理装置。
【請求項９】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数ステップにより計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数ステップにより計数された該応答がない要求の数と、該第１の時間範囲において該第２計数ステップにより計数された該応答があった要求の数と、に基づいて無応答状態の予兆を検出する検出ステップと、をそなえた処理方法。
【請求項１０】
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数ステップにより計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数ステップにより計数された該応答がない要求の数と、該第１の時間範囲において該第２計数ステップにより計数された該応答があった要求の数と、に基づいて無応答状態の予兆を検出する検出ステップと、をコンピュータに実行させる処理用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理装置，処理方法，処理用プログラム，同プログラムを記録したコンピュータ読取可能な記録媒体に関する。
【背景技術】
【０００２】
複数のサーバから構成されるシステムとして、例えば、ＷＥＢサーバ，ＡＰ（Application）サーバ，ＤＢ（Data Base）サーバをそなえる３階層システムが知られている（下記特許文献１参照）。また、複数のサーバから構成されるシステムにおいて、システムの部分的な停止が原因で全システムが停止する場合がある。
このように、システムの部分的な停止が原因で全システムが停止する障害を、図１２（ａ）−（ｃ）を用いて説明する。図１２（ａ）−（ｃ）は３階層システムを示す図である。ここで、３階層システム２００は、ＷＥＢサーバ２１０，２台のＡＰサーバ２２０および３台のＤＢサーバ２３０をそなえる。各サーバは、クライアント２４０からの要求を保持するＦＩＦＯ（First in First Out）キューをそなえる。具体的には、ＷＥＢサーバ２１０は、ＦＩＦＯキュー３００をそなえる。同様に、２台のＡＰサーバ２２０は、それぞれＦＩＦＯキュー３１０，３２０をそなえ、また、３台のＤＢサーバ２３０は、それぞれＦＩＦＯキュー３３０，３４０，３５０をそなえる。キューに保持された要求は、この要求に対応する応答が行なわれることで解放される。なお、クライアント２４０は、図１２（ａ）にのみ記載し、図１２（ｂ），（ｃ）では便宜上省略している。
【０００３】
ここで、このＦＩＦＯキュー３４０をそなえるＤＢサーバ２３０は、クライアント２４０からの要求に応じてサービスＡに係る情報を提供する。例えば、このＤＢサーバ２３０に障害が発生した場合、このＤＢサーバ２３０において、サービスＡに対する応答が行なわれなくなり［図１２（ａ）参照］、ＦＩＦＯキュー３４０が溢れる。ＦＩＦＯキュー３４０が溢れることにより、ＦＩＦＯキュー３４０をそなえるＷＥＢサーバ２３０は無応答状態となる。さらには、このＤＢサーバ２３０からの応答を待っているＡＰサーバ２２０のＦＩＦＯキュー３１０，３２０が溢れ［図１２（ｂ）参照］、ＡＰサーバ２２０は無応答状態となる。そして、最終的には、ＷＥＢサーバ２１０のＦＩＦＯキュー３００が溢れることで、クライアントからの要求を受けることができなくなり、システム２００全体が無応答となる［図１２（ｃ）参照］。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−８６２０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来の３階層システムにおいては、システムの部分的な停止が原因で全システムが停止する場合において、システムが停止し、クライアントからの要求を受けることができなくなるまで、障害の発生に気付かず、障害を検出できないという問題点があった。
１つの側面では、システム停止の予兆を検知することを目的とする。
【０００６】
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本件の他の目的の1つとして位置付けることができる。
【課題を解決するための手段】
【０００７】
１つの案では、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数部と、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数部と、該第１計数部により計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数部により計数された該応答があった要求の数が第２閾値以上である場合に、障害の予兆を検出する検出部と、をそなえる処理装置を用いる。
【０００８】
また、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、該第１計数ステップにより計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が第２閾値以上である場合に、無応答状態の予兆を検出する検出ステップと、をそなえる処理方法を用いる。
【０００９】
さらに、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、該第１計数ステップにより計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が第２閾値以上である場合に、無応答状態の予兆を検出する検出ステップと、をコンピュータに実行させる処理用プログラムを用いる。
【００１０】
また、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数部と、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数部と、第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数部により計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数部により計数された該応答がない要求の数と、該第１の時間範囲において該第２計数部により計数された該応答があった要求の数と、に基づいて障害を検出する検出部と、をそなえた処理装置を用いる。
さらに、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数ステップにより計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数ステップにより計数された該応答がない要求の数と、該第１の時間範囲において該第２計数ステップにより計数された該応答があった要求の数と、に基づいて無応答状態の予兆を検出する検出ステップと、をそなえた処理方法を用いる。
また、クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、第１の時間範囲と当該第１の時間範囲に時系列的に連続する第２の時間範囲とのそれぞれにおいて該第１計数ステップにより計数された該応答がない要求の数の差である無応答数と、該第１の時間範囲において該第１計数ステップにより計数された該応答がない要求の数と、該第１の時間範囲において該第２計数ステップにより計数された該応答があった要求の数と、に基づいて無応答状態の予兆を検出する検出ステップと、をコンピュータに実行させる処理用プログラムを用いる。
【発明の効果】
【００１１】
システム停止の予兆を検知することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】実施形態の一例にかかるシステムの構成を示す図である。
【図２】実施形態の一例にかかる障害検出装置の構成を示す図である。
【図３】実施形態の一例にかかる第１テーブルを示す図である。
【図４】実施形態の一例にかかる障害検出装置の動作を説明するためのフローチャートである。
【図５】実施形態の一例にかかる障害検出装置の動作を説明するためのフローチャートである。
【図６】第１変形例にかかる障害検出装置の動作を説明するためのフローチャートである。
【図７】第２変形例にかかる第２テーブルを示す図である。
【図８】第２変形例にかかる障害検出装置の動作を説明するためのフローチャートである。
【図９】第３変形例にかかる第２テーブルを示す図である。
【図１０】第３変形例にかかる障害検出装置の動作を説明するためのフローチャートである。
【図１１】第４変形例にかかるリクエストツリーを説明するための図である。
【図１２】（ａ）−（ｃ）は、従来の３階層システムおける無応答障害を説明するための図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本展開方法に係る実施の形態を説明する。
〔Ａ〕第１実施形態の説明
図１は、実施形態の一例にかかるシステムの構成を示す図である。システム１００は、障害検出装置１，クライアント１０，分岐部２０，スイッチ３０，ＷＥＢサーバ４０，ＡＰサーバ５０，ＤＢサーバ６０およびインターネット７０をそなえる。クライアント１０は、インターネット７０および分岐部２０を介してスイッチ３０に通信可能に接続されている。分岐部２０は、クライアント装置１０およびスイッチ３０との間に配置され、障害検出装置１と通信可能に接続されている。さらに、スイッチ３０は、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０と通信可能に接続されている。また、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０は、スイッチ３０を介して相互に通信可能に接続されている。
【００１４】
クライアント１０は、例えば、ＰＣ（Personal Computer）であり、インターネット７０を介して、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０からなるサーバに対してリクエストを送信する。
分岐部２０は、例えば、ネットワークタップであり、サーバとクライアント１０との間で送受信されるパケットをモニタする。
【００１５】
スイッチ３０は、例えば、Ｌ２スイッチであり、パケットを中継転送する。
ＷＥＢサーバ４０は、クライアント１０からの要求に応じてＨＴＭＬ（Hyper Text Markup Language）ファイルを送信する。
ＤＢサーバ６０は、データベースをそなえ、このデータベースの検索／更新処理を実行する。また、ＤＢサーバ６０は、クライアント１０からの要求に応じて所定のサービスに係る情報を提供する。
【００１６】
ＡＰサーバ５０は、ＷＥＢサーバ４０とＤＢサーバ６０との橋渡しを行ない、ＤＢサーバ６０におけるデータベースの検索／更新処理を制御する。
ここで、本実施形態の一例においては、上述のＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０により３階層システムを構成している。なお、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０は、それぞれ、ＦＩＦＯキューをそなえる。また、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０は、既知の種々のサーバシステムを用いることができ、その詳細な説明は省略する。
【００１７】
障害検出装置１は、分岐部２０によりモニタされたパケットに基づいて、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ６０からなるサーバに発生した障害を検出する。
図２は実施形態の一例にかかる障害検出装置１の構成を示す図である。図２に示す障害検出装置１は、ＣＰＵ（Central Processing Unit）２，記憶部３および入力Ｉ／Ｆ部４をそなえる。ＣＰＵ２，記憶部３および入力Ｉ／Ｆ部４はバス５を介して相互に通信可能に接続されている。
【００１８】
記憶部３は、例えば、ＲＡＭ（Random Access Memory），ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等のデータを格納可能な記憶装置であり、各種情報を記憶する。具体的は、記憶部３は、後述する第１テーブル３１を記憶する。
入力Ｉ／Ｆ（インターフェイス）部４は、例えば、ＮＩＣ（Network Interface Card）であり、外部ネットワークと通信可能に接続されるインターフェイスである。入力Ｉ／Ｆ部４は、クライアント１０とＷＥＢサーバ４０との間で送受信されるパケットを、分岐部２０を介して受信する。なお、クライアントとサーバとの間で送受信されるパケットは、例えば、ＩＰヘッダ部，ＴＣＰヘッダ部，ＨＴＴＰヘッダ部およびＨＴＴＰボディ部をそなえる。クライアントとサーバとの間で送受信されるパケットは、既知の種々のパケットを用いることができ、その詳細な説明は省略する。
【００１９】
ＣＰＵ２は、例えば、記憶部３に記憶された各種アプリケーションプログラムを実行することにより種々の演算や制御を行ない、これにより、各種機能を実現する処理装置である。
例えば、ＣＰＵ２は、処理用プログラムを実行することにより、処理部２１，障害検出部２２および通知部２３として機能する。
【００２０】
処理部２１は、入力Ｉ／Ｆ部４にて受信したパケットに基づいて、各種の処理を行なう。処理部２１は、第１判断部２１１，第２判断部２１２およびテーブル作成部２１３をそなえる。
第１判断部２１１は、例えば、入力Ｉ／Ｆ部４にて受信したパケットのＨＴＴＰヘッダ部を参照することで、入力Ｉ／Ｆ部４にて受信したパケットが、クライアントからサーバに対する要求（リクエスト）か、サーバからクライアントに対する応答（レスポンス）かを判断する。
【００２１】
第２判断部２１２は、第１判断部２１１が、リクエストであると判断した場合に、例えば、そのパケットのＨＴＴＰヘッダ部に記載されたＵＲＬ（Uniform Resource Locator）を参照する。第２判断部２１２は、この参照により、入出力Ｉ／Ｆ部４にて受信したパケットに係るリクエストが、動的なリクエストであるか否かを判断する。具体的には、ＵＲＬの末尾（対象情報）が、「.jpg」，「.gif」などの拡張子を有する画像データや、「.html」，「.css」などの拡張子を有する共通フォーマットやスタイルシートなどの静的なコンテンツを示していれば、第２判断部２１２は、動的なリクエストではないと判断する。一方、ＵＲＬの末尾が、「.jsp」，「.cgi」などの拡張子を有するリクエスト毎に動的に生成されるコンテンツを示していれば、第２判断部２１２は、動的なリクエストであると判断する。すなわち、第２判断部２１２は、要求が動的な要求であるか否かを判断する判断部として機能する。
【００２２】
ここで、動的なリクエストとは、例えば、３階層システムにおけるＷＥＢサーバ４０のみでは応答することができないリクエストであり、ＡＰサーバ５０およびＤＢサーバ６０が協働することで応答することができるリクエストを示す。言い換えれば、動的なリクエストとは、複数のサービスによって共有されるＦＩＦＯキュー（例えばＡＰサーバのそなえるＦＩＦＯキュー）を使用するリクエストである。
【００２３】
一方、静的なリクエストとは、例えば、ＷＥＢサーバ４０のみで応答することができるリクエストを示す。すなわち、動的なリクエストは、静的なリクエストに比べ、レスポンスがない場合、クライアント１０の業務に影響を及ぼしやすいリクエストである。
テーブル作成部２１３は、第１テーブル３１を作成する。具体的には、テーブル作成部２１３は、第２判断部２１２によって、動的なリクエストであると判断されたリクエスト（以下、単に動的リクエストという場合がある）に関する所定の情報を記憶部３に記録することで第１テーブル３１を作成する。
【００２４】
図３は、実施形態の一例にかかる第１テーブルである。図３に示す第１テーブル３１は、ＴＣＰ（Transmission Control Protocol）コネクションＩＤ毎に、URLに含まれるパス名（以下、単にパスという場合がある）およびリクエスト時刻が関連付けられている。テーブル作成部２１３によって、ＴＣＰコネクションＩＤ毎に、パスおよびリクエスト時刻が、第１テーブル３１に記録される。
【００２５】
ここで、ＴＣＰコネクションＩＤとは、クライアント１０のＩＰアドレスおよびポート番号と、ＷＥＢサーバ４０のＩＰアドレスおよびポート番号との対である。それぞれのＩＰアドレスは、テーブル作成部２１３が、ＩＰヘッダ部を参照することで取得する、それぞれのポート番号は、テーブル作成部２１３が、ＴＣＰヘッダ部を参照することで取得する。図３では、便宜上、ＴＣＰコネクションＩＤをＡ，Ｂ，Ｃで表している。
【００２６】
また、パスは、テーブル作成部２１３が、リクエストのＨＴＴＰヘッダ部を参照することで取得する。
さらに、リクエスト時刻は、障害検出装置１がパケットを受信した時刻であり、例えば、テーブル作成部２１３が、障害検出装置１がそなえる図示しないタイマや内部時計から、パケットを受信した時刻を取得する。
【００２７】
また、テーブル作成部２１３は、第１判断部によってレスポンスであると判断されたパケットに対応するリクエストが、第１テーブル３１に存在するか否かを判定する。具体的には、テーブル作成部２１３は、レスポンスに係るパケットから、レスポンスに係るＴＣＰコネクションＩＤを取得し、第１テーブル３１に記録されたＴＣＰコネクションＩＤと一致するか否かを判定する。
【００２８】
テーブル作成部２１３は、レスポンスに対応するリクエストが存在する場合には、第１テーブル３１から、レスポンスに対応するリクエストを削除する。従って、第１テーブル３１には、レスポンスがないリクエストに関する情報のみが記録される。
また、テーブル作成部２１３は、ＷＥＢサーバ４０から応答があった回数を動的レスポンス数として計数する。具体的には、テーブル作成部２１３は、第１テーブル３１から、レスポンスに対応するリクエストを削除するとともに、動的レスポンス数をインクリメントすることで、動的レスポンス数を計数する。すなわち、テーブル作成部２１３は、応答があった要求の数を計数する第２計数部として機能する。
【００２９】
障害検出部２２は、サーバの障害を検出する。この障害検出部２２は、計数部２２１および第３判断部２２２をそなえる。
計数部２２１は、例えば、第１テーブル３１を参照し、この参照により、予め決められたＴ秒間以上レスポンスがないリクエスト（以下、単に無応答リクエストという場合がある）の数を計数する。具体的には、計数部２２１は、第１テーブル３１のリクエスト時刻と、タイマや内部時計を参照することで、無応答リクエストの数を計数する。すなわち、計数部２２１は、所定時間応答がない要求の数を計数する第１計数部として機能する。
【００３０】
ここで、レスポンスがないリクエストを判断するための時間Ｔは、例えば、３０秒や６０秒であり、業務アプリケーションの通常の応答時間よりも極めて大きい値である。すなわち、Ｔはリクエストに対して無応答であると判断できる値である。なお、Ｔは、上記の例に限定されるものではなく種々の値に設定可能である。
第３判断部２２２は、サーバに障害が発生しているか否かを判断する。具体的には、サーバが無応答となる予兆があるか、または、サーバが無応答状態か否かを判断する。
【００３１】
障害を検出するため、第３判断部２２２は、無応答リクエストの数が、予め決められた閾値Ｍ以上か否かを判断する。さらに、無応答リクエストの数が、予め決められた閾値Ｍ以上の場合、第３判断部２２２は、テーブル作成部２１３により計数された動的レスポンス数が、予め決められた閾値Ｎ以上か否かを判断する。
そして、第３判断部２２２は、この判断の結果、テーブル作成部２１３により計数された動的レスポンス数が、予め決められた閾値Ｎ以上の場合、無応答リクエストが原因でサーバが無応答となる予兆があると判断する。言い換えれば、第３判断部２２２は、サーバが無応答となる予兆を検出する。また、第３判断部２２２は、テーブル作成部２１３により計数された動的レスポンス数が、予め決められた閾値Ｎ未満の場合、サーバが無応答であると判断する。言い換えれば、第３判断部２２２は、サーバが無応答状態であることを検出する。すなわち、第３判断部２２２は、応答がない要求の数と、応答があった要求の数とに基づいて障害を検出する検出部として機能する。
【００３２】
ここで、例えば、閾値Ｍは、ＡＰサーバ５０の有するキューが保持できるリクエストの数の一割程度の値とすることが望ましく、閾値Ｎは、１−１００程度の値であることが望ましい。
通知部２３は、サーバの管理者に対して通知する種々の情報を出力する。具体的には、第３判断部２２２によりサーバがダウンする予兆があると判断された場合、通知部２３は、無応答リクエストが原因でサーバがダウンする予兆がある旨を管理者に対して通知する。また、第３判断部２２２によりサーバが無応答であると判断された場合、通知部２３は、サーバが無応答である旨を管理者に対して通知する。
【００３３】
なお、通知部２３は、動的レスポンス数が、閾値Ｎ以上の場合または閾値Ｎ未満の場合のいずれにおいても、第１テーブル３１の情報を選択的に管理者に対して通知してもよい。例えば、無応答リクエストチェック部２２は、第１テーブル３１に記録された無応答リクエストのパスを管理者に対して通知してもよいし、第１テーブル３１に記録された無応答リクエストのパスに共通する部分のみを管理者に通知してもよい。さらに、通知部２３は、無応答リクエストの無応答となっている時間を管理者に通知することもできる。
【００３４】
また、通知部２３は、管理者に対して種々の情報を通知することに代え、管理者に通知した種々の情報を記憶部３にログとして保存することもできる。
ここで、管理者に対する情報の通知方法は、例えば、電子メールを用いて情報を通知してもよいし、管理者がそなえるディスプレイに情報を直接表示するようにしてもよい。
図４は、上述の如く構成された、実施形態の一例としての障害検出装置１の処理部２１の動作を示すフローチャートである。
【００３５】
まず、入力Ｉ／Ｆ部４が、新たにパケットを受信すると（ステップＡ１）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがリクエストであるか否かを判断する（ステップＡ２）。リクエストであると判断された場合（ステップＡ２のＹｅｓルート参照）、第２判断部２１２が、受信したパケットのＨＴＴＰヘッダを参照することで、動的なリクエストであるか否かを判断する（ステップＡ３）。動的なリクエストであると判断された場合（ステップＡ３のＹｅｓルート参照）、テーブル作成部２１３が、動的リクエストを第１テーブル３１に記録する（ステップＡ４）。なお、動的なリクエストではないと判断された場合（ステップＡ３のＮｏルート参照）、このリクエストを第１テーブル３１に記録せず、再びステップＡ１に戻る。
【００３６】
また、リクエストではないと判断された場合（ステップＡ２のＮｏルート参照）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがレスポンスであるか否かを判断する（ステップＡ５）。レスポンスであると判断された場合（ステップＡ５のＹｅｓルート参照）、テーブル作成部２１３が、レスポンスに対応するリクエストが第１テーブル３１に記録されているか判断する（ステップＡ６）。レスポンスに対応するリクエストが第１テーブル３１に記録されていると判断された場合（ステップＡ６のＹｅｓルート参照）、テーブル作成部２１３が、第１テーブル３１から、レスポンスに対応するリクエストを削除し（ステップＡ７）、動的レスポンス数を１インクリメントする（ステップＡ８；第２計数ステップ）。
【００３７】
なお、レスポンスでないと判断された場合（ステップＡ５のＮｏルート参照）、再びステップＡ１に戻る。また、レスポンスに対応するリクエストが第１テーブル３１に記録されていないと判断された場合（ステップＡ６のＮｏルート参照）、再びステップＡ１に戻る。
図５は、実施形態の一例としての障害検出装置１の障害検出部２２および通知部２３の動作を示すフローチャートである。
【００３８】
まず、計数部２２１は、タイマや内部時計および第１テーブル３１を参照することで、Ｔ秒間以上レスポンスがないリクエスト（無応答リクエスト）の数を計数する（ステップＡ１０１；第１計数ステップ）。次に、第３判断部２２２は、無応答リクエストの数が閾値Ｍ以上か否かを判断する（ステップＡ１０２）。無応答リクエストの数が閾値Ｍ以上である場合（ステップＡ１０２のＹｅｓルート参照）、第３判断部２２２は、テーブル作成部２１３により計数された動的レスポンス数が閾値Ｎ以上か否かを判断する（ステップＡ１０３）。テーブル作成部２１３により計数された動的レスポンス数が閾値Ｎ以上の場合（ステップＡ１０３のＹｅｓルート参照）、第３判断部２２２は、サーバが無応答となる予兆を検出する（検出ステップ）。通知部２３は、サーバが無応答となる予兆がある旨を管理者に対して、電子メール等を用いて通知する（ステップＡ１０４）。そして、無応答リクエストチェック部２２は、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。また、テーブル作成部２１３により計数された動的レスポンス数が閾値Ｎ未満の場合（ステップＡ１０３のＮｏルート参照）、第３判断部２２２は、サーバが無応答であること（無応答障害）を検出する（検出ステップ）。通知部２３は、サーバが無応答である旨を管理者に対して、電子メール等を用いて通知し（ステップＡ１０６）、無応答リクエストチェック部２２は、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。なお、無応答リクエストの数が閾値Ｍ未満である場合（ステップＡ１０２のＮｏルート参照）、第３判断部２２２は、サーバに障害は発生していないものと判断し、無応答リクエストチェック部２２は、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。
【００３９】
上述したステップＡ１０１−Ａ１０６の処理は、所定の周期毎に繰り返し行なわれる。
このように、実施形態の一例にかかる障害検出装置１によれば、サーバが無応答となる予兆を自動的に検出することができる。
従って、実施形態の一例にかかる障害検出装置１によれば、無応答となる予兆を検出できるため、障害箇所や障害原因の特定の時間が短縮され、障害復旧に要する時間を短縮することができる。
【００４０】
さらに、実施形態の一例にかかる障害検出装置１によれば、障害復旧に要する時間を短縮することができるため、運用コストを抑えることができる。
また、実施形態の一例にかかる障害検出装置１によれば、通知部２３が、サーバが無応答となる予兆を管理者に通知するため、管理者は、サーバ全体が無応答となる前に適切に対応することができる。
【００４１】
さらに、実施形態の一例にかかる障害検出装置１によれば、通知部２３が、第１テーブル３１の情報を選択的に管理者に対して通知するため、管理者は、障害箇所や障害原因の特定に要する時間を短縮することができる。
また、実施形態の一例にかかる障害検出装置１によれば、通知部２３が第１テーブル３１の情報を選択的ログとして保存するため、従来、無応答障害時にログとして残らなかった情報を用いて障害の解析を行なうことができる。従って、実施形態の一例にかかる障害検出装置１によれば障害箇所や障害原因の特定の時間が短縮され、障害復旧に要する時間を短縮することができる。
【００４２】
〔Ｂ〕変形例の説明
[Ｂ−１]第１変形例の説明
なお、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
例えば、障害検出部２２は、上述した実施形態の障害検出部２２としての機能に加え、前回の周期における、無応答リクエストの数と、今回の周期における無応答リクエストの数との差に基づいて障害の発生を検出することもできる。なお、既述の符号と同一の符号は同一もしくは略同一の部分を示す。
【００４３】
具体的には、本変形例における障害検出部２２は、前回の周期における、無応答リクエストの数と、今回の周期における無応答リクエストの数との差を算出する。すなわち、障害検出部２２は、第１の時間範囲である前回の周期における、無応答リクエストの数と、第１の時間範囲に時系列的に連続する第２の時間範囲である今回の周期における、無応答リクエストの数との差を算出する。
【００４４】
図６は、実施形態の一例としての障害検出装置１の第１変形例における障害検出部２２および通知部２３の動作を示すフローチャートである。なお、本変形例においては、図５に示したステップＡ１０１に代えて、ステップＡ２０１に示す処理が行なわれる。さらに、図５に示すフローチャートにステップＡ２０２およびＡ２０３が加えられている。なお、図４中の符号と同一の符号をそなえるステップは、同一もしくは略同一のステップを示す。
【００４５】
まず、計数部２２１は、タイマおよび第１テーブル３１を参照することで、今回の周期における、無応答リクエストの数ＮＲを計数する（ステップＡ２０１）。次に、第３判断部２２２は、無応答リクエストの数が閾値Ｍ以上か否かを判断する（ステップＡ１０２）。無応答リクエストの数ＮＲが閾値Ｍ以上である場合（ステップＡ１０２のＹｅｓルート参照）、第３判断部２２２は、テーブル作成部２１３により計数された動的レスポンス数が閾値Ｎ以上か否かを判断する（ステップＡ１０３）。動的レスポンス数が閾値Ｎ以上の場合（ステップＡ１０３のＹｅｓルート参照）、障害検出部２２は、無応答リクエストの数ＮＲと、前回の周期における無応答リクエストの数ＮＲＰＲＶとの差（以下、単に無応答リクエスト差という場合がある）を算出する。そして、第３判断部２２２は、無応答リクエスト差が、予め決められた閾値Ｌより大きいか否かを判断する（ステップＡ２０２）。無応答リクエスト差が、閾値Ｌより大きい場合（ステップＡ２０２のＹｅｓルート参照）、第３判断部２２２は、サーバが無応答となる予兆があると判断し、通知部２３は、サーバが無応答となる予兆がある旨を管理者に対して、電子メール等を用いて通知する（ステップＡ１０４）。そして、障害検出部２２は、ＮＲをＮＲＰＲＶとし（ステップＡ２０３）、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。
【００４６】
また、無応答リクエスト差が、閾値Ｌ以下の場合（ステップＡ２０２のＮｏルート参照）、第３判断部２２２は、サーバ自体のレスポンスが遅いことを示しているのみで、無応答リクエストに起因する障害がサーバに発生しているわけではないと判断する。そして、障害検出部２２は、ＮＲをＮＲＰＲＶとし（ステップＡ２０３）、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。
【００４７】
また、テーブル作成部２１３により計数された動的レスポンス数が閾値Ｎ未満の場合（ステップＡ１０３のＮｏルート参照）、第３判断部２２２は、サーバが無応答であると判断し、通知部２３は、サーバが無応答である旨を管理者に対して、電子メール等を用いて通知する（ステップＡ１０６）。そして、障害検出部２２は、ＮＲをＮＲＰＲＶとし（ステップＡ２０３）、テーブル作成部２１３により計数された動的レスポンス数を０にリセットする（ステップＡ１０５）。
【００４８】
なお、無応答リクエストの数ＮＲが閾値Ｍ未満である場合（ステップＡ１０２のＮｏルート参照）、第３判断部２２２は、サーバに障害は発生していないものと判断し、障害検出部２２は、ＮＲをＮＲＰＲＶとする（ステップＡ２０３）とともに、テーブル作成部２１３により計数された動的レスポンス数を０にリセットするとともに、ＮＲをＮＲＰＲＶとする（ステップＡ１０５）。
【００４９】
このように、本変形例の障害検出装置１においても、第１実施形態と同一の効果を得られるほか、無応答リクエスト差に基づいて、障害の発生を検知しているため、より正確に障害の発生を検知することができる。具体的には、無応答リクエストが多い場合でも、無応答リクエスト差が小さければ、サーバ自体のレスポンスが遅いことを示しているのみで、無応答リクエストに起因する障害がサーバに発生しているわけではないと判断できる。従って、より正確にサーバにおける障害の発生を検知することができる。
[Ｂ−２]第２変形例の説明
上述した実施形態の一例において、第２判断部２１２は、パケットのＨＴＴＰヘッダ部に記載されたＵＲＬに含まれるパスに基づいて動的なリクエストであるか否かを判断していたが、これに限定されるものではない。
【００５０】
例えば、第２判断部２１２は、リクエストに係るパケットのペイロードに対してハッシュ関数を適用することで得られるハッシュ値に基づいて、動的なリクエストであるか否かを判断することもできる。なお、既述の符号と同一の符号は同一もしくは略同一の部分を示す。
本変形例におけるにおけるテーブル作成部２１３は、上述した実施形態のテーブル作成部２１３としての機能に加え、第２テーブル３２を作成する。具体的には、テーブル作成部２１３は、パケットのペイロードを参照し、ハッシュ値を算出し、記憶部３に記録することで第２テーブル３２を作成する。
【００５１】
図７は、実施形態の一例にかかる第２テーブル３２である。図７に示す第２テーブル３２は、パス毎に、リクエストハッシュ値およびレスポンスハッシュ値が変化するか否かを示す情報が関連付けられている。また、図７に示す第２テーブル３２は、パス毎に、リクエストハッシュ値およびレスポンスハッシュ値が関連付けられている。また、第２テーブル３２は、例えば、記憶部３に格納されている。なお、図７においては、ハッシュ値が変化することを示す値として「変化」と記載し、ハッシュ値が固定であることを示す値として「固定」と記載し、具体的なハッシュ値の値は便宜上省略している。
【００５２】
リクエストハッシュ値およびレスポンスハッシュ値は、それぞれ、テーブル作成部２１３がリクエストおよびレスポンスに係るパケットのペイロードに対してＭＤ（Message Digest Algorithm）５やＳＨＡ（Secure Hash Algorithm）などのハッシュ関数を適用することで求められたハッシュ値である。
テーブル作成部２１３は、リクエストに係るパケットのペイロードからハッシュ値を算出し、第２テーブル３２に記録する。この時、同一パスに係るリクエストが既に記録されている場合には、リクエストハッシュ値を比較する。この比較の結果ハッシュ値が異なる場合には、第２テーブル３２にリクエストハッシュ値が変化することを示す値、例えばフラグ等を設定する。なお、ハッシュ値が同一の場合には、リクエストハッシュ値が固定である旨を示す値、例えばフラグ等を設定する。なお、同一パスに係るリクエストが既に記録されている場合には、新たにリクエストハッシュ値を記録しなくともよく、この場合、同一パスに係るリクエストのうち最初に第２テーブル３２に記録されたリクエストのハッシュ値を、ハッシュ値の比較に用いる。
【００５３】
同様に、テーブル作成部２１３は、レスポンスに係るパケットのペイロードからハッシュ値を算出し、第２テーブル３２に記録する。この時、同一パスに係るレスポンスが既に記録されている場合には、レスポンスハッシュ値を比較する。この比較の結果ハッシュ値が異なる場合には、第２テーブル３２にレスポンスハッシュ値が変化することを示す値、例えばフラグ等を設定する。なお、ハッシュ値が同一の場合には、レスポンスハッシュ値が固定である旨を示す値、例えばフラグ等を設定する。なお、同一パスに係るレスポンスが既に記録されている場合には、新たにレスポンスハッシュ値を記録しなくともよく、この場合、同一パスに係るレスポンスのうち最初に第２テーブル３２に記録されたレスポンスのハッシュ値を、ハッシュ値の比較に用いる。
【００５４】
ここで、テーブル作成部２１３は、例えば、動的なリクエストか否かに関わらず、リクエストに係るパケットから、図３に示したように、ＴＣＰコネクションＩＤおよびパスを記録する。そして、テーブル作成部２１３は、レスポンスに係るパケットから、ＴＣＰコネクションＩＤを取得し、リクエストおよびレスポンスに係るＴＣＰコネクションＩＤを比較する。テーブル作成部２１３は、この比較により一致したＴＣＰコネクションＩＤに対応付けられているパスに基づいて、対応するリクエストが、第２テーブル３２に記録されているか否かを判断することができる。
【００５５】
本変形例における第２判断部２１２は、ハッシュ値に基づいて動的なリクエストか否かを判断する。具体的には、第２テーブル３２のリクエストハッシュ値またはレスポンスハッシュ値が変化することを示す場合には、動的なリクエストであると判断する。なお、第２判断部２１２は、第２テーブル３２のリクエストハッシュ値およびレスポンスハッシュ値が変化することを示している場合に、動的なリクエストであると判断してもよい。なお、第２判断部２１２が、リクエストハッシュ値のみに基づいて動的なリクエストであるか否かを判断する場合には、第２テーブル３２は、少なくともパスとリクエストハッシュ値とをそなえていればよい。また、第２判断部２１２が、レスポンスハッシュ値のみに基づいて動的なリクエストであるか否かを判断する場合には、第２テーブル３２は、少なくともパスとレスポンスハッシュ値とをそなえていればよい。
【００５６】
図８は、実施形態の一例としての障害検出装置１の第２変形例における処理部２１の動作を示すフローチャートである。なお、本変形例においては、図４に示すフローチャートのステップＡ３に代えてステップＡ３０２の処理が行なわれる。さらに、図４に示すフローチャートにステップＡ３０１，Ａ３０３およびＡ３０４が加えられている。図４中の符号と同一の符号をそなえるステップは、同一もしくは略同一のステップを示す。
【００５７】
まず、入力Ｉ／Ｆ部４が、パケットを受信すると（ステップＡ１）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがリクエストであるか否かを判断する（ステップＡ２）。ステップＡ２にて、リクエストであると判断された場合（ステップＡ２のＹｅｓルート参照）、テーブル作成部２１３が、パケットからパスを取得するとともに、パケットのペイロードからハッシュ値を求め、第２テーブル３２にハッシュ値を記録する（ステップＡ３０１）。なお、同一のパスが、第２テーブル３２に記録されていない場合には、テーブル作成部２１３は、パスも記録する。また、このハッシュ値の記録とともに、テーブル作成部２１３は、第２テーブル３２に既にリクエストハッシュ値が記録されている場合には、ハッシュ値を比較し、変化または固定を示すフラグを記録する。そして、第２判断部２１２は、第２テーブル３２のリクエストハッシュ値またはレスポンスハッシュ値を参照することで、動的なリクエストであるか否かを判断する（ステップＡ３０２）。動的なリクエストであると判断された場合（ステップＡ３０２のＹｅｓルート参照）、すなわち、リクエストハッシュ値およびレスポンスハッシュ値のいずれかが変化を示している場合、テーブル作成部２１３が、動的リクエストを第１テーブル３１に記録する（ステップＡ４）。なお、動的なリクエストではないと判断された場合（ステップＡ３０２のＮｏルート参照）、すなわち、リクエストハッシュ値およびレスポンスハッシュ値が固定を示している場合、このリクエストを第１テーブル３１に記録せず、再びステップＡ１に戻る。
【００５８】
また、ステップＡ２にてリクエストではないと判断された場合（ステップＡ２のＮｏルート参照）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがレスポンスであるか否かを判断する（ステップＡ５）。レスポンスであると判断された場合（ステップＡ５のＹｅｓルート参照）、テーブル作成部２１３が、レスポンスに対応するリクエストが第２テーブル３２に記録されているか判断する（ステップＡ３０３）。レスポンスに対応するリクエストが第２テーブル３２に記録されていると判断された場合（ステップＡ３０３のＹｅｓルート参照）、テーブル作成部２１３が、第２テーブル３２にハッシュ値を記録する（ステップＡ３０４）。なお、このハッシュ値の記録とともに、テーブル作成部２１３は、第２テーブル３２に既にレスポンスハッシュ値が記録されている場合には、ハッシュ値を比較し、変化または固定を示すフラグを記録する。次に、テーブル作成部２１３が、レスポンスに対応するリクエストが第１テーブル３１に記録されているか判断する（ステップＡ６）。レスポンスに対応するリクエストが第１テーブル３１に記録されていると判断された場合（ステップＡ６のＹｅｓルート参照）、第１テーブル３１から、レスポンスに対応するリクエストを削除する（ステップＡ７）とともに、動的レスポンス数をカウントする（ステップＡ８）。
【００５９】
なお、レスポンスでないと判断された場合（ステップＡ５のＮｏルート参照）、再びステップＡ１に戻る。また、レスポンスに対応するリクエストが第２テーブル３２に記録されていないと判断された場合（ステップＡ３０３のＮｏルート参照）、再びステップＡ１に戻る。さらに、レスポンスに対応するリクエストが第１テーブル３１に記録されていないと判断された場合（ステップＡ６のＮｏルート参照）、再びステップＡ１に戻る。
【００６０】
このように、本変形例の障害検出装置１においても、第１実施形態と同一の効果を得られるほか、ハッシュ値に基づいて、動的なリクエストか否かを判断するため、パスに動的なリクエストか否かを判断できる情報がない場合においても、動的なリクエストか否かを判断できる。従って、より正確に動的なリクエストを判断することができ、さらには、より正確にサーバにおける障害の予兆の発生を検知することができる。
【００６１】
なお、ハッシュ関数を用いず、ハッシュ値に代えてパケットのペイロードの容量に基づいて、本変形例の処理を実行してもよい。
[Ｂ−３]第３変形例の説明
上述した実施形態の一例において、第２判断部２１２は、パケットのＨＴＴＰヘッダ部に記載されたＵＲＬに含まれるパスに基づいて動的なリクエストであるか否かを判断していたが、これに限定されるものではない。
【００６２】
例えば、第２テーブル３２は、パス毎に、応答回数，応答時間平均および応答時間分散をそなえてもよく、第２判断部２１２は、応答時間平均または応答時間分散に基づいて動的リクエストであるか否かを判断することもできる。なお、既述の符号と同一の符号は同一もしくは略同一の部分を示す。
本変形例におけるテーブル作成部２１３は、上述した実施形態のテーブル作成部２１３としての機能に加え、第２テーブル３２を作成する。
【００６３】
本変形例における第２テーブル３２を図９に示す。図９に示す第２テーブル３２は、パス毎に、応答回数，応答時間平均および応答時間分散が関連付けられている。
応答回数は、障害検出装置１がレスポンスを受信した回数であり、応答時間平均は、障害検出装置１がリクエストを受信し、このリクエストに対応するレスポンスを受信するまでの時間である応答時間の平均である。また、応答時間分散は、応答時間の分散である。
【００６４】
ここで、テーブル作成部２１３は、例えば、動的なリクエストか否かに関わらず、リクエストに係るパケットから、図３に示したように、ＴＣＰコネクションＩＤ，パスおよびリクエスト時刻を記録する。そして、テーブル作成部２１３は、レスポンスに係るパケットから、ＴＣＰコネクションＩＤを取得し、リクエストおよびレスポンスに係るＴＣＰコネクションＩＤを比較する。この比較により一致したＴＣＰコネクションＩＤに対応付けられている受信時刻と、同一のＴＣＰコネクションＩＤを有するレスポンスに係るパケットの受信時刻とに基づいて、応答時間を算出することができる。なお、レスポンスに係るパケットの受信時刻は、例えば、テーブル作成部２１３が、タイマや内部時計を参照することで、取得することができる。また、リクエストおよびレスポンスに係るＴＣＰコネクションＩＤの比較により一致したＴＣＰコネクションＩＤに対応付けられているパスに基づいて、対応するリクエストが、第２テーブル３２に記録されているか否かを判断することができる。
【００６５】
さらに、テーブル作成部２１３は、例えば、リクエストおよびレスポンスに係るＴＣＰコネクションＩＤを比較し、一致した回数を計数することで、応答回数を求めることができる。
そして、テーブル作成部２１３は、応答時間および応答回数に基づいて、応答時間平均および応答時間分散を求め、この応答時間平均および応答時間分散を第２テーブル３２に記録する。
【００６６】
本変形例における第２判断部２１２は、応答時間平均または応答時間分散に基づいて、動的リクエストであるか否かを判断する。具体的には、リクエストに係るパケットのパスに対応する第２テーブル３２の応答時間平均または応答時間分散を、所定の閾値と比較することで、動的なリクエストであると判断する。
ここで、応答時間平均に対する閾値は、例えば１００msec，応答時間分散に対する閾値は、例えば、１０msecであることが望ましい。但し、これらに限定されるものではなく、閾値の値は、種々の値に設定可能である。ここで、第２判断部２１２は、例えば、第２テーブル３２の応答時間平均または応答時間分散が閾値以上の場合には、動的なリクエストであると判断する。なお、第２判断部２１２は、第２テーブル３２の応答時間平均および応答時間分散が、それぞれの閾値以上の場合に、動的なリクエストであると判断してもよい。
【００６７】
なお、第２判断部２１２が、応答時間平均のみに基づいて動的なリクエストであるか否かを判断する場合には、第２テーブル３２は、少なくともパスと応答時間平均とをそなえていればよい。また、第２判断部２１２が、応答時間分散のみに基づいて動的なリクエストであるか否かを判断する場合には、第２テーブル３２は、少なくともパスと応答時間分散とをそなえていればよい。
【００６８】
図１０は、実施形態の一例としての第３変形例における障害検出装置１の処理部２１の動作を示すフローチャートである。なお、本変形例においては、図４に示すフローチャートのステップＡ３に代えてステップＡ４０２の処理が行なわれる。さらに、図４に示すフローチャートにステップＡ４０１，Ａ４０３およびＡ４０４が加えられている。図４中の符号と同一の符号をそなえるステップは、同一もしくは略同一のステップを示す。
【００６９】
まず、入力Ｉ／Ｆ部４が、パケットを受信すると（ステップＡ１）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがリクエストであるか否かを判断する（ステップＡ２）。ステップＡ２にて、リクエストであると判断された場合（ステップＡ２のＹｅｓルート参照）、テーブル作成部２１３が、パケットからパスを取得し、第２テーブル３２に記録する（ステップＡ４０１）。なお、同一のパスが、第２テーブル３２に記録されている場合には、テーブル作成部２１３は、パスを記録しない。そして、第２判断部２１２は、リクエストに係るパケットのパスに対応する応答時間平均または応答時間分散、および、それぞれに対応する閾値を参照することで、動的なリクエストであるか否かを判断する（ステップＡ４０２）。動的なリクエストであると判断された場合（ステップＡ４０２のＹｅｓルート参照）、すなわち、応答時間平均または応答時間分散のいずれかが対応する閾値以上の場合、テーブル作成部２１３が、動的リクエストを第１テーブル３１に記録する（ステップＡ４）。なお、動的なリクエストではないと判断された場合（ステップＡ４０２のＮｏルート参照）、すなわち、応答時間平均および応答時間分散が、それぞれに対応する閾値未満の場合、このリクエストを第１テーブル３１に記録せず、再びステップＡ１に戻る。
【００７０】
また、リクエストではないと判断された場合（ステップＡ２のＮｏルート参照）、第１判断部２１１は、受信したパケットのＨＴＴＰヘッダを参照することで、受信したパケットがレスポンスであるか否かを判断する（ステップＡ５）。レスポンスであると判断された場合（ステップＡ５のＹｅｓルート参照）、テーブル作成部２１３が、レスポンスに対応するリクエストが第２テーブル３２に記録されているか判断する（ステップＡ４０３）。レスポンスに対応するリクエストが第２テーブル３２に記録されていると判断された場合（ステップＡ４０３のＹｅｓルート参照）、テーブル作成部２１３が、応答回数および応答時間を求めることで、応答時間平均や応答時間分散を求め、第２テーブル３２に記録する（ステップＡ４０４）。次に、テーブル作成部２１３が、レスポンスに対応するリクエストが第１テーブル３１に記録されているか判断する（ステップＡ６）。レスポンスに対応するリクエストが第１テーブル３１に記録されていると判断された場合（ステップＡ６のＹｅｓルート参照）、第１テーブル３１から、レスポンスに対応するリクエストを削除する（ステップＡ７）とともに、動的レスポンス数をカウントする（ステップＡ８）。
【００７１】
なお、レスポンスでないと判断された場合（ステップＡ５のＮｏルート参照）、再びステップＡ１に戻る。また、レスポンスに対応するリクエストが第２テーブル３２に記録されていないと判断された場合（ステップＡ４０３のＮｏルート参照）、再びステップＡ１に戻る。さらに、レスポンスに対応するリクエストが第１テーブル３１に記録されていないと判断された場合（ステップＡ６のＮｏルート参照）、再びステップＡ１に戻る。
【００７２】
このように、本変形例においても、第１実施形態と同一の効果を得られる。
[Ｂ−４]第４変形例の説明
なお、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
例えば、ＣＰＵ２は、上述した機能に加え、記憶部３に記憶された処理用プログラムを実行することにより、リクエストツリー生成機能として機能する。
【００７３】
リクエストツリー生成機能は、例えば、第２判断部２１２にて、動的なリクエストであると判断されたリクエストのＨＴＴＰヘッダを参照することでパスを取得し、そのパスを図１１に示すようにツリー形式で記憶部３に記憶させることで、リクエストツリーを生成する。例えば、リクエストツリー生成機能は、図５におけるステップＡ１０２の処理後に機能することとしてもよいし、図５におけるステップＡ１０１の処理後に機能することとしてもよい。
【００７４】
さらに、リクエストツリー生成機能は、テーブル作成部２１３によって、レスポンスがあったと判断されたリクエストに係るパスについて、レスポンスがあった旨（図１１の○印参照）を記録する。また、リクエストツリー生成機能は、計数部２２１により、Ｔ秒以上レスポンスがないと判断されたリクエストに係るパスについて、レスポンスがない旨（図１１の×印参照）を記録する。なお、同一のパスについて、レスポンスがあった旨とレスポンスがない旨とが重複した場合には、レスポンスがあった旨を記録しても良いし、レスポンスがない旨を記録してもよい。
【００７５】
図１１は、リクエストツリー生成機能により作成されたリクエストツリーの一例を示す図である。図１１では、path1/path4，path1/path5およびpath1/path6というパスを有するリクエストに対して、Ｔ秒以上レスポンスがないことを示している。さらに、図１１は、path2/path7，path3/path8，path3/path9，およびpath3/path10というパスを有するリクエストに対して、レスポンスがあったことを示している。
【００７６】
通知部２３は、リクエストツリーを参照することで、Ｔ秒以上レスポンスがないことを示している、パスに共通する部分を抽出し、この共通する部分を、サーバが無応答となる予兆がある旨やサーバが無応答である旨とともに管理者に対して通知する。
このように、本変形例の障害検出装置１においても、第１実施形態と同一の効果を得られるほか、Ｔ秒以上レスポンスがないことを示しているパスに共通する部分を管理者に通知することで、管理者は障害の原因を容易かつ迅速に特定することができる。
【００７７】
〔Ｃ〕その他
なお、開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
なお、例えば、本実施形態の一例に係る第２テーブル３２は、パス毎にリクエストハッシュ値およびレスポンスハッシュ値が記録されているが、これに限定されるものではない。例えば、パス毎に、リクエストハッシュ値，レスポンスハッシュ値，応答時間平均，応答時間分散を記録してもよい。なお、この場合、第２判断部２１２は、例えば、リクエストハッシュ値，レスポンスハッシュ値，応答時間平均および応答時間分散に基づいて、動的なリクエストか否かを判断する。
【００７８】
さらに、本実施形態の一例に係るシステム１００は、２台のクライアント１０をそなえるが、これに限定されるものではなく、システム１００は、クライアント１０を１台または３台以上そなえてもよい。
また、本実施形態の一例に係るシステム１００は、１台のＷＥＢサーバ４０をそなえるが、これに限定されるものではなく、システム１００は、ＷＥＢサーバ４０を２台以上そなえてもよい。
【００７９】
さらに、本実施形態の一例に係るシステム１００は、１台のＡＰサーバ５０をそなえるが、これに限定されるものではなく、システム１００は、ＡＰサーバ５０を２台以上そなえてもよい。
また、本実施形態の一例に係るシステム１００は、１台のＤＢサーバ６０をそなえるが、これに限定されるものではなく、システム１００は、ＤＢサーバ６０を２台以上そなえてもよい。
【００８０】
さらに、本実施形態の一例に係るシステム１００では、障害検出装置１は、分岐部２０を介してパケットを受信しているが、これに限定されるものではい。例えば、障害検出装置１は、スイッチ３０のモニタポートを介してパケットを受信してもよい。また、障害検出装置１は、例えば、クライアント１０とスイッチ３０との間にゲートウェイのように挿入されることで、パケットを受信してもよい。
【００８１】
また、本実施形態の一例に係る障害検出部２２は、Ｔ秒間以上レスポンスがない動的なリクエストの数と、レスポンスがあった動的なリクエストの数とに基づいて障害を検出しているが、これに限定されるものではない。例えば、動的なリクエストか否かに関わらず、全てのリクエストについて、Ｔ秒間以上レスポンスがないかを判断し、Ｔ秒間以上レスポンスがない全てリクエストの数と、レスポンスがあった全てのリクエストの数とに基づいて障害を検出してもよい。
【００８２】
さらに、本実施形態の一例に係るシステム１００は、ＷＥＢサーバ４０，ＡＰサーバ５０およびＤＢサーバ５０からなる３階層システムをそなえているが、これに限定されるものではない。例えば、システム１００は、複数のサーバからなる２階層または４階層以上のシステムをそなえてもよい。
障害検出装置１にそなえられるＣＰＵの各機能を実現するための種々のアプリケーションプログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ  ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。
【００８３】
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数部と、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数部と、
該第１計数部により計数された該応答がない要求の数と、該第２計数部により計数された該応答があった要求の数と、に基づいて障害を検出する検出部と、をそなえたことを特徴とする処理装置。
【００８４】
（付記２）
該要求が、動的な要求であるか否かを判断する判断部をそなえ、
該第１計数部は、該判断部により、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して該所定時間応答がない要求の数を計数し、
該第２計数部は、該判断部により、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数することを特徴とする付記１記載の処理装置。
【００８５】
（付記３）
該判断部が、該要求の対象を示す対象情報の種類に基づいて、該動的な要求であるか否かを判断することを特徴とする付記２記載の処理装置。
（付記４）
該判断部が、該要求のペイロードの容量に基づいて、該動的な要求であるか否かを判断することを特徴とする付記２記載の処理装置。
【００８６】
（付記５）
該判断部が、該要求のペイロードの容量に基づくハッシュ値に基づいて、該動的な要求であるか否かを判断することを特徴とする付記２記載の処理装置。
（付記６）
該判断部が、該要求に先行して該クライアントから該サーバに対して送信された先行要求と同一の対象に対する該要求について、該要求のペイロードの容量が、該先行要求のペイロードの容量と異なる場合、当該要求を該動的な要求であると判断することを特徴とする付記４記載の処理装置。
【００８７】
（付記７）
該判断部が、該要求に先行して該クライアントから該サーバに対して送信された先行要求と同一の要求先に対する該要求について、該要求のペイロードの容量に基づくハッシュ値が、該先行要求のペイロードの容量に基づくハッシュ値と異なる場合、当該要求を該動的な要求であると判断することを特徴とする付記５記載の処理装置。
【００８８】
（付記８）
該検出部が、該第１計数部により計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数部により計数された該応答があった要求の数が第２閾値以上である場合、該障害として、該サーバが無応答状態になる予兆を検出することを特徴とする付記１〜７のいずれか１項に記載の処理装置。
【００８９】
（付記９）
該検出部が、該第１計数部により計数された該応答がない要求の数が該第１閾値以上であり、かつ、該第２計数部により計数された該応答があった要求の数が該第２閾値未満である場合、該障害として、該サーバが無応答状態であることを検出することを特徴とする付記８記載の処理装置。
【００９０】
（付記１０）
該検出部が、
第１の時間範囲における、該第１計数部により計数された該応答がない要求の数と、第１の時間範囲に時系列的に連続する第２の時間範囲における、該第１計数部により計数された該応答がない要求の数との差である無応答数と、
該第１の時間範囲における、該第１計数部により計数された該応答がない要求の数と、
該第１の時間範囲における、該第２計数部により計数された該応答があった要求の数と、
に基づいて、障害を検出することを特徴とする付記１〜７のいずれか１項に記載の処理装置。
【００９１】
（付記１１）
該検出部が、該第１の時間範囲における、該第１計数部により計数された該応答がない要求の数が第１閾値以上であるとともに、該第１の時間範囲における、該第２計数部により計数された該応答があった要求の数が第２閾値以上であり、かつ、該無応答数が、第３閾値より大きい場合、該障害として、該サーバが無応答になる予兆を検出することを特徴とする付記１０記載の処理装置。
【００９２】
（付記１２）
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない該要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
該第１計数ステップにより計数された該応答がない要求の数と、該第２計数ステップにより計数された該応答があった要求の数と、に基づいて障害を検出する検出ステップと、をそなえたことを特徴とする処理方法。
【００９３】
（付記１３）
該要求が、動的な要求であるか否かを判断する判断ステップをそなえ、
該第１計数ステップは、該判断ステップにより、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して該所定時間応答がない要求の数を計数し、
該第２計数ステップは、該判断ステップにより、該動的な要求であると判断された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数することを特徴とする付記１２記載の処理方法。
【００９４】
（付記１４）
該判断ステップが、該要求の対象を示す対象情報の種類に基づいて、該動的な要求であるか否かを判断することを特徴とする付記１３記載の処理方法。
（付記１５）
該判断ステップが、該要求のペイロードの容量に基づくハッシュ値に基づいて、該動的な要求であるか否かを判断することを特徴とする付記１３記載の処理方法。
【００９５】
（付記１６）
該判断ステップが、該要求に先行して該クライアントから該サーバに対して送信された先行要求と同一の要求先に対する該要求について、該要求のペイロードの容量に基づくハッシュ値が、該先行要求のペイロードの容量に基づくハッシュ値と異なる場合、当該要求を該動的な要求であると判断することを特徴とする付記１５記載の処理方法。
【００９６】
（付記１７）
該検出ステップが、該第１計数ステップにより計数された該応答がない要求の数が第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が第２閾値以上である場合、該障害として、該サーバが無応答状態になる予兆を検出することを特徴とする付記１２〜１６のいずれか１項に記載の処理方法。
【００９７】
（付記１８）
該検出ステップが、該第１計数ステップにより計数された該応答がない要求の数が該第１閾値以上であり、かつ、該第２計数ステップにより計数された該応答があった要求の数が該第２閾値未満である場合、該障害として、該サーバが無応答状態であることを検出することを特徴とする付記１７記載の処理方法。
【００９８】
（付記１９）
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、
該クライアントから該サーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
該第１計数ステップにより計数された該応答がない要求の数と、該第２計数ステップにより計数された該応答があった要求の数と、に基づいて障害を検出する検出ステップと、をコンピュータに実行させる処理用プログラム。
【００９９】
（付記２０）
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して所定時間応答がない要求の数を計数する第１計数ステップと、
クライアントからサーバに対して送信された要求のうち、該サーバから該クライアントに対して応答があった要求の数を計数する第２計数ステップと、
該第１計数ステップにより計数された該応答がない要求の数と、該第２計数ステップにより計数された該応答があった要求の数と、に基づいて障害を検出する検出ステップと、をコンピュータに実行させる処理用プログラムを記録したコンピュータ読取可能な記録媒体。
【符号の説明】
【０１００】
１    障害検出装置
２    ＣＰＵ
３    記憶部
４    入力Ｉ／Ｆ部
５    バス
１０    クライアント
２０    分岐部
２１    処理部
２２    障害検出部
２３    通知部
３０    スイッチ
３１    第１テーブル
３２    第２テーブル
４０    ＷＥＢサーバ
５０    ＡＰサーバ
６０    ＤＢサーバ
７０    インターネット
１００    システム
２１１    第１判断部
２１２    第２判断部
２１３    テーブル作成部
２２１    計数部
２２２    第３判断部
【図１】
0005732767.tif 000002
【図２】
0005732767.tif 000003
【図３】
0005732767.tif 000004
【図４】
0005732767.tif 000005
【図５】
0005732767.tif 000006
【図６】
0005732767.tif 000007
【図７】
0005732767.tif 000008
【図８】
0005732767.tif 000009
【図９】
0005732767.tif 000010
【図１０】
0005732767.tif 000011
【図１１】
0005732767.tif 000012
【図１２】
0005732767.tif 000013