JP2014178832A - サービス提供システム、サーバ装置、クライアント端末、障害検知方法、及びプログラム - Google Patents

Abstract

【課題】コンピュータシステムにおいて、導入コストの増加を抑制しつつ、障害検知を確実に実行し得る、サービス提供システム、サーバ装置、クライアント端末、障害検知方法、及びプログラムを提供する。
【解決手段】サービス提供システム１００は、クライアント端末１０と、クライアント端末１０にサービスを提供するサーバ装置２０とを備えている。クライアント端末１０は、サーバ装置２０における障害の発生を監視し、障害が発生していると判断した場合に、サーバ装置２０に対してログの採取を要求する。また、サーバ装置２０は、クライアント端末１０から、ログの採取が要求された場合に、ログを採取し、採取したログを格納する。
【選択図】図１

Description

本発明は、障害検知機能を備えたサービス提供システム、サーバ装置、クライアント端末、障害検知方法、及びこれらを実現するためのプログラムに関する。

近年、企業内においては、業務アプリケーションとして、Ｗｅｂアプリケーションの利用が増加しており、各ユーザ（従業員等）へのサービスの提供は、Ｗｅｂブラウザを介して、Ｗｅｂサーバから行なわれている（例えば、特許文献１及び２参照）。このようなＷｅｂアプリケーションを利用する場合は、各クライアント端末に、アプリケーションプログラムを導入する必要がない。よって、クライアント端末の管理が容易になると共に、導入コストの低減が可能となる。

但し、Ｗｅｂアプリケーションを利用する場合は、Ｗｅｂサーバ及びネットワークへの負担が大きく、障害が発生し易いため、意図せずに、サービスの提供が不能になる場合がある。このため、Ｗｅｂアプリケーション提供するシステムにおいては、障害の検知が重要となる。

また、こういったシステムで障害が発生し、サーバ全体が停止した場合、ユーザはサービスを利用できなくなることから、ユーザのクライアント端末からの情報を用いれば、比較的早くに、システムの障害を検知することができると考えられる。更に、特定のネットワークからのアクセスでのみで発生する障害、クライアント端末での特定の操作で発生する障害等は、ユーザの操作、又はクライアント端末が接続されているネットワークに依存する。よって、このような障害の検知においては、特にクライアント端末の情報は有効と考えられる。

但し、障害の報告をユーザからの申告に任せるとすると、障害を検知することができない場合がある。また、ユーザからの申告が遅れ、それによれって、必要な情報が消滅してしまい、原因究明ができないという場合もある。

このため、上述した特許文献のうち、特許文献２は、クライアント端末によって、サービスを提供するサーバ装置からのレスポンスの遅れを検出させ、その後、検出結果を、評価装置に通知させる、システムを提案している。そして、特許文献２に開示されたシステムでは、評価装置は、クライアント端末からの通知を受けると、その内容を電子メールによって管理者の端末に通知する。また、評価装置は、サーバ装置に記憶されているリソース情報に関するログ、及び実行されたタスクに関するログを取得し、これを集積する。

特開２０１０−２３１３６８号公報 特開２０１１−１９７７８５号公報

しかしながら、特許文献２に開示されたシステムを実現しようとすると、サービスを提供するサーバ装置とは別に、評価装置を構築するためのサーバ装置を導入する必要があるため、システムの構築にかかるコストが増大してしまう。また、このコストは、監視対象となるシステムの規模が大きくなる程、更に増大してしまう。

本発明の目的の一例は、上記問題を解消し、コンピュータシステムにおいて、導入コストの増加を抑制しつつ、障害検知を確実に実行し得る、サービス提供システム、サーバ装置、クライアント端末、障害検知方法、及びプログラムを提供することにある。

上記目的を達成するため、本発明の一側面におけるサービス提供システムは、クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを備え、
前記クライアント端末は、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求し、
前記サーバ装置は、前記クライアント端末から、前記ログの採取が要求された場合に、ログを採取し、採取したログを格納する、
ことを特徴とする。

また、上記目的を達成するため、本発明の一側面におけるクライアント端末は、サービスを提供するサーバ装置における障害の発生を監視する、監視部と、
障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ログ採取要求部とを、
備えている、ことを特徴とする。

また、上記目的を達成するため、本発明の一側面におけるサーバ装置は、クライアント端末にサービスを提供するサーバ装置であって、
前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ログ記録要求受付部を備えている、
ことを特徴とする。

また、上記目的を達成するため、本発明の一側面における障害検知方法は、クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを用いた障害検知方法であって、
（ａ）前記クライアント端末によって、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求する、ステップと、
（ｂ）前記クライアント端末から、前記ログの採取が要求された場合に、前記サーバ装置によって、ログを採取し、採取したログを格納する、ステップと、
を有することを特徴とする。

更に、上記目的を達成するため、本発明の一側面における第１のプログラムは、コンピュータに、
（ａ）サービスを提供するサーバ装置における障害の発生を監視する、ステップと、
（ｂ）前記（ａ）のステップで障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ステップとを、
実行させることを特徴とする。

更に、上記目的を達成するため、本発明の一側面における第２のプログラムは、コンピュータによって、クライアント端末にサービスを提供するためのプログラムであって、
前記コンピュータに、
（ａ）前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ステップを、実行させることを特徴とする。

以上のように、本発明によれば、コンピュータシステムにおいて、導入コストの増加を抑制しつつ、障害検知を確実に実行することができる。

図１は、本発明の実施における、サービス提供システムの構成を概略的に示す図である。 図２は、本発明の実施におけるサーバ装置及びクライアント端末の構成を示すブロック図である。図３は、本発明の実施の形態におけるサービス提供システムで利用される管理テーブルの一例を示す図である。 図３は、本発明の実施の形態におけるサービス提供システムで利用される管理テーブルの一例を示す図である。 図４は、本発明の実施の形態におけるクライアント端末の動作を示すフロー図である。 図５は、本発明の実施の形態におけるサービス提供システムにおいて障害が発生した場合の情報の流れを説明する図である。 図６は、本発明の実施の形態におけるＷｅｂサーバ（サーバ装置）の動作を示すフロー図である。 図７は、本発明の実施の形態におけるサーバ装置及びクライアント端末を実現するコンピュータの一例を示すブロック図である。

（発明の概要）
本発明では、サービス提供用のサーバ装置（例えば、Ｗｅｂサーバ）において、サーバ負荷、リクエストの不正等による障害（以下「サーバ障害」と表記する。）が発生した場合に、サービスを受ける側のクライアント端末において、そのサーバ障害が検知される。また、原因究明に必要なログは、障害発生時に動的にサーバ側に残されるので、障害の解析に利用することができる。つまり、本発明では、サーバ障害を検知するための仕組みと、検知後の動作とに特徴がある。

従来においては、サーバ障害を検知するため、サービス提供用のサーバ装置とは別に、監視用のサーバ装置を設置し、この監視用のサーバ装置によって、サービスサービス提供用のサーバ装置の死活監視を行うのが一般的である。また、監視用のサーバは、多くの場合、サーバ障害の検知後、障害の発生をシステムの管理者に通知するだけである。

これに対して、本発明では、サービス提供用のサーバ装置の死活監視を、サービスを受ける側のクライアント端末が代行する。また、クライアント端末は、サーバ障害が発生すると、サービス提供用のサーバ装置の状態を監視するため、そのパフォーマンスログ等の採取を開始させる。更に、クライアント端末は、障害の発生を、システムの管理者に通知するともできる。

このため、システムの管理者は、監視用のサーバを別途設置することなく、サーバ障害の発生を検知でき、更に、サーバの状態を調査するために有用なログを採取することもできる。このため、管理者は、容易に障害原因を究明することができようになる。また、障害発生時にログが採取されるので、通常運用時において、ログの採取のためにサービス提供用のサーバ装置に負荷がかかることはない。

また、このように、ユーザが使用するクライアント端末によって、サービス提供用のサーバ装置が監視されるので、ユーザの体感に合わせて障害を検知できるようになる。具体的には、ユーザがサービス提供用のサーバ装置の反応が遅いと感じたときに、障害が発生していると判断することができる。

このため、サービス提供用のサーバ装置の性能に関するチューニングを、ユーザの体感に合せて行なうことができるので、様々な角度から、サービス提供用のサーバ装置の性能に関する問題を検出できる。また、この結果、監視用のサーバを設置する場合と比較して、問題に対する対処の初動を早くすることが可能となる。更に、何十台、何百台というクライアント端末が、監視用の装置として機能するため、特定のサーバを監視用の装置として用いる場合と比べて、脆弱性の解消が図られる。

（実施の形態）
以下、本発明の実施の形態における、サービス提供システム、サーバ装置、クライアント端末、障害検知方法、及びプログラムについて、図１〜図７を参照しながら説明する。

［システム構成］
最初に、本実施の形態における、サービス提供システム、サーバ装置、及びクライアント端末の構成について説明する。図１は、本発明の実施における、サービス提供システムの構成を概略的に示す図である。図１において矢印は情報の流れを示している。

図１に示すように、本実施の形態におけるサービス提供システム１００は、クライアント端末１０と、クライアント端末１０にＷｅｂサービスを提供するサーバ装置２０とを備えている。

なお、図１の例では、２台のクライアント端末１０のみが図示されているが、クライアント端末１０の台数は特に限定されるものではない。また、同じく図１の例では、１台のサーバ装置２０のみが図示されているが、サーバ装置２０の台数も特に限定されるものではない。

クライアント端末１０は、監視機構を備えており、これによって、サーバ装置２０における障害の発生を監視する。そして、クライアント端末１０は、障害が発生していると判断した場合は、サーバ装置２０に対してログの採取を要求する。サーバ装置２０は、クライアント端末１０から、ログの採取が要求されると、ログを採取し、採取したログを格納する。

また、クライアント端末１０は、本実施の形態では、障害が発生している判断した場合は、サービス提供システム１００の管理者（システム管理者）の端末（図１において図示せず）に、障害の発生を通知することができる。

このように、サービス提供システム１００では、サーバ装置２０とは別に用意された監視用のサーバ装置ではなく、クライアント端末１０によって、サーバ装置２０の障害が検知される。このため、システムの導入コストの増加を抑制しつつ、障害検知を確実に実行することができる。

続いて、図２及び図３を用いて、本実施の形態におけるサービス提供システム、サーバ装置、及びクライアント端末の構成について更に具体的に説明する。図２は、本発明の実施におけるサーバ装置及びクライアント端末の構成を示すブロック図である。図３は、本発明の実施の形態におけるサービス提供システムで利用される管理テーブルの一例を示す図である。

まず、本実施の形態では、サービス提供システム１００は、Ｗｅｂサービスを提供するシステムであり、サーバ装置２０は、Ｗｅｂサーバである。また、ユーザは、クライアント端末１０に導入されているＷｅｂブラウザ１４を介して、Ｗｅｂサービスの提供を受けることができる。なお、以降においては、サーバ装置２０は、「Ｗｅｂサーバ２０」と表記する。

図２に示すように、クライアント端末１０は、監視機構として、監視部１１と、ログ採取要求部１２とを備えている。監視部１１及びログ採取要求部１２は、クライアント端末１０に導入された監視プログラム１３によって構築されている。また、クライアント端末１０は、上述したように、Ｗｅｂブラウザ１４も備えている。

監視部１１は、図３に示す管理テーブルに従って、Ｗｅｂサーバ１０にＨＴＴＰ形式のリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値（以下「レスポンス閾値」と表記する。）を超えているかどうかを判定する。

例えば、レスポンス閾値が２分に設定されている場合は、Ｗｅｂサーバ２０からクライアント端末１０へのレスポンスが２分を超えた場合、監視部１１はサーバ障害が発生したと判断する。

判定の結果、レスポンスを受信するまでの時間がレスポンス閾値を超えている場合は、監視部１１は、障害が発生していると判断し、ログ採取要求部１２にログの採取を求める旨を通知する。

図３に示すように、クライアント端末１０の管理テーブル１５には、監視対象となるＷｅｂサーバ２０のＵＲＬ（以下「監視対象ＵＲＬ（Uniform Resource Location）」と表記する。）と、レスポンス閾値と、ログ記録要求フラグとが登録されている。なお、図３の例では、監視対象ＵＲＬ及びレスポンス閾値は、Ｗｅｂサーバ２０が提供するサービス（認証サービス、アプリケーションサービス等）毎に登録されている。

図３において、ログ記録要求フラグは、該当するＷｅｂサーバ２０に対して、同一ネットワーク内のクライアント端末１０から、既にログの採取が既に要求されているかどうかを示すフラグである。ログ記録要求フラグは、既に要求されている場合は「False」となり、未だ要求されていない場合は「True」となる。

また、ログ採取要求部１２は、監視部１１から通知を受けると、管理テーブル（図３参照）を確認し、ログ記録要求フラグがTrue及びFalseのいずれであるかを判定する。判定の結果、ログ記録要求フラグがFalseだった場合は、ログ採取要求部１２は、同一ネットワーク内ですでに別のクライアント端末１０がログの採取を要求している（ログ記録要求を送信済）ため、処理を中止する。

一方、判定の結果、このログ記録要求フラグがTrueだった場合は、ログ採取要求部１２は、自身がＷｅｂサーバ２０にログの採取を要求する旨の通知を、ネットワーク内の他のクライアント端末１０にブロードキャストで送信する。これによって、同一ネットワーク内のクライアント端末１０では、該当するＷｅｂサーバ２０のログ記録要求フラグがTrueからFalseに書き換えられる。その後、ログ採取要求部１２は、ログの採取を要求するため、Ｗｅｂサーバ２０に、ログ記録要求を送信する。

また、図１に示すように、Ｗｅｂサーバ２０は、レスポンス閾値管理部２１と、ログ記録要求受付部２２と、記憶部２４と、リクエスト受付部２５、Ｗｅｂサービス提供部２６とを備えている。このうち、リクエスト受付部２５は、クライアント端末１０からのリクエストの受信と、それに対するレスポンスの送信とを行なっている。また、Ｗｅｂサービス提供部２６は、リクエスト受付部２５でやり取りされるリクエストとレスポンスとを利用して、Ｗｅｂサービスに必要なデータを提供する。

また、レスポンス閾値管理部２１とログ記録要求受付部２２とは、Ｗｅｂサーバ２０に導入された常駐プログラム２３によって構築されている。レスポンス閾値管理部２１は、Ｗｅｂサーバ２０からクライアント端末１０へのレスポンスが遅延したときに、クライアント端末１０がＷｅｂサーバ２０に障害が発生していると判定する際のレスポンス閾値（数値）を設定する。

なお、図３に示すように、本実施の形態では、レスポンス閾値管理部２１は、提供されるサービス毎に、レスポンス閾値を設定する。そして、レスポンス閾値管理部２１は、サービス毎に、設定したレスポンス閾値と、対応するＷｅｂサーバ２０のＵＲＬ（監視対象ＵＲＬ）と、対応する操作内容とを管理テーブル２７（図３参照）に登録する。

また、レスポンス閾値管理部２は、管理テーブル２７に登録されている情報が変更されると、その度に、全てのクライアント端末１０に対して、変更後の管理テーブル２７の内容を通知する。これにより、各クライアント端末１０においては、管理テーブル１５が更新される。

ログ記録要求受付部３は、クライアント端末１０からログ記録要求が送信されてくると、送信されてきたログ記録要求に応じて、ログを採取し、採取したログを記録部２４に格納させる。また、このとき、記録部２４は、採取されたログを、ログの採取を要求したクライアント端末１０を識別する情報に関連付けて格納する。

このような構成により、Ｗｅｂサーバ２０は、障害が発生していない通常時においては、ログの採取などの処理は一切行なわず、クライアント端末１０の監視プログラム１３からの要求を待つのみである。従って、通常時において、Ｗｅｂサーバ２０に対して負荷がかかることはない。

一方、クライアント端末１０から、ログ採取の要求を受けたときは、Ｗｅｂサーバ２０は、ログ採取を実行する。そして、本実施の形態では、この採取されたログは、どのクライアント端末１０からの要求で採取されたものであるのかが区別されている。従って、管理者は、採取されたログを解析すれば、障害が、そのクライアント端末に固有の問題であるかどうかを判断することができる。

［システム動作］
次に、本発明の実施の形態における、サービス提供システム、サーバ装置、及びクライアント端末の動作について図４〜図６を用いて説明する。以下の説明においては、適宜図１〜図３を参酌する。また、本実施の形態では、サービス提供システム１００を動作させることによって、障害検知方法が実施される。よって、本実施の形態における障害検知方法の説明は、以下のサービス提供システム１００の動作説明に代える。

［システム動作：クライアント端末］
最初に、クライアント端末１０における動作について図４及び図５を用いて説明する。図４は、本発明の実施の形態におけるクライアント端末の動作を示すフロー図である。図５は、本発明の実施の形態におけるサービス提供システムにおいて障害が発生した場合の情報の流れを説明する図である。

図４及び図５に示すように、まず、各クライアント端末１０において、監視部１１は、ＨＴＴＰ形式のリクエストを送信する。そして、監視部１１は、送信後、Ｗｅｂサーバ２０からレスポンスを受信するまでにかかった時間を計測し、計測した時間がレスポンス閾値を超えているかどうかを判定する（ステップＡ１）。

具体的には、ステップＡ１では、監視部１１は、管理テーブル（図３参照）から、アクセス先となっているＵＲＬ（監視対処ＵＲＬ）に対応するレスポンス閾値を読み出し、読み出したレスポンス閾値に基づいて判定を実施する。

ステップＡ１の判定の結果、計測した時間がレスポンス閾値を超えていない場合は、監視部１１は、待機状態となる。

一方、ステップＡ１の判定の結果、計測した時間がレスポンス閾値を超えている場合は、監視部１１は、ログ採取要求部１２に、ログの採取を求める旨を通知する。これにより、ログ採取要求部１２は、管理テーブル（図３参照）を確認し、ログ記録要求フラグがTrueであるかどうかを判定する（ステップＡ２）。

ステップＡ２の判定の結果、ログ記録要求フラグがTrueでない場合（Falseである場合）は、ログ採取要求部１２は処理を中止する。一方、ステップＡ２の判定の結果、ログ記録要求フラグがTrueである場合は、ログ採取要求部１２は、ログ採取要求をサーバに送信する（ステップＡ３）。

但し、ステップＡ３を実行する場合は、ログ採取要求部１２は、予め、自身がＷｅｂサーバ２０にログの採取を要求する旨の通知を、ネットワーク内の他のクライアント端末１０にブロードキャストで送信する。これにより、同一ネットワーク内のクライアント端末１０では、該当する監視対象ＵＲＬのログ記録要求フラグがTrueからFalseに書き換えられる。

ステップＡ３が実行されると、監視部１１は、システム管理者の端末にメッセージを送信し、Ｗｅｂサーバ２０に障害が発生したことを知らせる（ステップＡ４）。その後、システム管理者は、Ｗｅｂサーバ２０で採取されたログを確認し、障害を解析する。

［システム動作：Ｗｅｂサーバ］
続いて、Ｗｅｂサーバ２０における動作について図５及び図６を用いて説明する。図６は、本発明の実施の形態におけるＷｅｂサーバ（サーバ装置）の動作を示すフロー図である。

図５及び図６に示すように、まず、Ｗｅｂサーバ２０において、ログ記録要求受付部２２は、クライアント端末１０から、新しくログ採取要求を受信しているかどうかを判定する（ステップＢ１）。

ステップＢ１の判定の結果、新しくログ採取要求を受信していない場合は、ログ記録要求受付部２２は、待機状態となる。一方、ステップＢ１の判定の結果、新しくログ採取要求を受信している場合は、ログ記録要求受付部２２は、ログの採取を開始する（ステップＢ２）。

次に、ログ記録要求受付部３は、記録部２４に設けられたクライアント端末毎のフォルダのうち、障害を検知したクライアント端末１０のフォルダの配下に、採取したログを格納する（ステップＢ３）。ステップＢ３の実行後、システム管理者は、採取されたログを確認し、障害を解析する。このとき、システム管理者は、障害を検知したクライアント端末１０を特定できるので、障害が、そのクライアント端末１０に固有の問題であったかどうかを解析することができる。

［実施の形態における効果］
以上のように、本実施の形態によれば、クライアント端末１０によって、サーバ装置２０の障害を検知できるので、システムの導入コストの増加を抑制できる。つまり、近年においては、クラウド環境の利用が増加しているため、サービスを提供するサーバ装置の数が数十台、数百台となる可能性が考えられる。このような場合において、本実施の形態におけるサービス提供システム１００を適用すれば、サービスを利用するクライアント端末一台一台によってサーバ装置を監視できるため、費用の面でも、管理コストの面でも、管理者側の負担を劇的に軽減させることができる。

また、本実施の形態では、クライアント端末が受信するレスポンスの遅延に基づいて障害発生を検知できることから、エンドユーザの体感に合わせて障害をいち早く検知できる。そして、障害をいち早く検知できるので、システム管理者は、障害対策を早期に練ることができる点である。

［変形例］
上述の例では、レスポンスの遅延に基づいて障害発生の有無が判定されているが、本実施の形態では、例えば、レスポンスのステータス等を監視対象として、アプリケーションレベルの障害検知を実行することもできる。具体的には、「HTTPエラー：503サービス利用不可」というエラーが複数回続いた場合に、クライアント端末１０の監視部１１は、障害が発生していると判定することができる。

また、負荷分散のためにＷｅｂサーバが複数台備えられた大規模な環境の場合では、クライアント端末１０の監視部１１が管理している「管理テーブル（図３参照）」に、複数のＷｅｂサーバを登録することができる。この場合、監視部１１は、受信までにかかった時間がレスポンス閾値を超えると、動的に別のＷｅｂサーバ１０に接続先を変更することができる。この態様では、クライアント端末１０は、負荷分散装置として機能するため、ロードバランサが不要となる。

また、上述の例では、クライアント端末として、パーソナルコンピュータが用いられているが、本実施の形態は、これに限定されず、クライアント端末１０は、パーソナルコンピュータ以外の携帯電話、スマートフォン、タブレット型端末等であっても良い。

また、クライアント端末は、パーソナルコンピュータ以外の場合は、Ｗｅｂブラウザ以外のアプリケーションプログラムによってリクエストの送信と、レスポンスの受信とを行なっても良い。更に、この場合、Ｗｅｂサーバは、上述の図６に示すステップＢ３において、クライアント端末のフォルダの配下に採取したログを格納する代わりに、クライアント端末との通信に対応したサーバプロセスのログデータのみを記憶部に格納する。

更に、本実施の形態では、クライアント端末は、ＨＴＴＰ形式のリクエスト及びレスポンスの代わりに、Ａｊａｘ（Asynchronous Java Script + XML）でやりとりされるデータに基づいて、障害が発生しているかどうかを判定することもできる。

［プログラム］
本実施の形態における第１のプログラムは、コンピュータに、図４に示すステップＡ１〜Ａ４を実行させるプログラム、即ち、監視プログラム１３であれば良い。このプログラムをコンピュータにインストールし、実行することによって、本実施の形態におけるクライアント端末１０を実現することができる。この場合、コンピュータのＣＰＵ（Central Processing Unit）は、監視部１１、ログ採取要求部１２として機能し、処理を行なう。

また、本実施の形態における第２のプログラムは、コンピュータに、図６に示すステップＢ１〜Ｂ３を実行させるプログラム、即ち、常駐プログラム２３であれば良い。このプログラムをコンピュータにインストールし、実行することによって、本実施の形態におけるＷｅｂサーバ２０を実現することができる。この場合、コンピュータのＣＰＵ（Central Processing Unit）は、レスポンス閾値管理部１１、ログ記録要求受付部２２として機能し、処理を行なう。

ここで、本実施の形態における第１のプログラムを実行することによって、クライアント端末１０を実現するコンピュータと、本実施の形態における第２のプログラムを実行することによって、Ｗｅｂサーバ２０を実現するコンピュータについて図７を用いて説明する。図７は、本発明の実施の形態におけるサーバ装置及びクライアント端末を実現するコンピュータの一例を示すブロック図である。

図７に示すように、コンピュータ１１０は、ＣＰＵ１１１と、メインメモリ１１２と、記憶装置１１３と、入力インターフェイス１１４と、表示コントローラ１１５と、データリーダ／ライタ１１６と、通信インターフェイス１１７とを備える。これらの各部は、バス１２１を介して、互いにデータ通信可能に接続される。

ＣＰＵ１１１は、記憶装置１１３に格納された、本実施の形態におけるプログラム（コード）をメインメモリ１１２に展開し、これらを所定順序で実行することにより、各種の演算を実施する。メインメモリ１１２は、典型的には、ＤＲＡＭ（Dynamic Random Access Memory）等の揮発性の記憶装置である。また、本実施の形態におけるプログラムは、コンピュータ読み取り可能な記録媒体１２０に格納された状態で提供される。なお、本実施の形態におけるプログラムは、通信インターフェイス１１７を介して接続されたインターネット上で流通するものであっても良い。

また、記憶装置１１３の具体例としては、ハードディスクドライブの他、フラッシュメモリ等の半導体記憶装置が挙げられる。入力インターフェイス１１４は、ＣＰＵ１１１と、キーボード及びマウスといった入力機器１１８との間のデータ伝送を仲介する。表示コントローラ１１５は、ディスプレイ装置１１９と接続され、ディスプレイ装置１１９での表示を制御する。

データリーダ／ライタ１１６は、ＣＰＵ１１１と記録媒体１２０との間のデータ伝送を仲介し、記録媒体１２０からのプログラムの読み出し、及びコンピュータ１１０における処理結果の記録媒体１２０への書き込みを実行する。通信インターフェイス１１７は、ＣＰＵ１１１と、他のコンピュータとの間のデータ伝送を仲介する。

また、記録媒体１２０の具体例としては、ＣＦ（Compact Flash（登録商標））及びＳＤ（Secure Digital）等の汎用的な半導体記憶デバイス、フレキシブルディスク（Flexible Disk）等の磁気記憶媒体、又はＣＤ−ＲＯＭ（Compact Disk Read Only Memory）などの光学記憶媒体が挙げられる。

上述した実施の形態の一部又は全部は、以下に記載する（付記１）〜（付記２２）によって表現することができるが、以下の記載に限定されるものではない。

（付記１）
クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを備え、
前記クライアント端末は、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求し、
前記サーバ装置は、前記クライアント端末から、前記ログの採取が要求された場合に、ログを採取し、採取したログを格納する、
ことを特徴とするサービス提供システム。

（付記２）
前記クライアント端末は、前記サーバ装置にリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値を超えているかどうかを判定し、判定の結果、前記時間が前記閾値を超えている場合に、障害が発生していると判断する、
付記１に記載のサービス提供システム。

（付記３）
前記クライアント端末は、障害が発生していると判断した場合に、更に、前記サービス提供システムの管理者の端末に、障害の発生を通知する、
付記１または２に記載のサービス提供システム。

（付記４）
前記クライアント端末は、当該クライアント端末以外のクライアント端末が、サーバ装置に前記ログの採取を要求していない場合に、当該クライアント端末以外のクライアント端末に対して、前記ログの採取を要求する旨を通知し、その後、前記ログの採取を要求する、
付記１〜３のいずれかに記載のサービス提供システム。

（付記５）
前記サーバ装置が、採取したログを、前記ログの採取を要求した前記クライアント端末を識別する情報に関連付けて格納する、
付記１〜４のいずれかに記載のサービス提供システム。

（付記６）
サービスを提供するサーバ装置における障害の発生を監視する、監視部と、
障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ログ採取要求部とを、
備えている、ことを特徴とするクライアント端末。

（付記７）
前記監視部は、前記サーバ装置にリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値を超えているかどうかを判定し、判定の結果、前記時間が前記閾値を超えている場合に、障害が発生していると判断する、
付記６に記載のクライアント端末。

（付記８）
前記監視部は、障害が発生していると判断した場合に、更に、前記サーバ装置の管理者の端末に、障害の発生を通知する、
付記６または７に記載のクライアント端末。

（付記９）
前記ログ採取要求部は、当該クライアント端末以外のクライアント端末が、サーバ装置に前記ログの採取を要求していない場合に、当該クライアント端末以外のクライアント端末に対して、前記ログの採取を要求する旨を通知し、その後、前記ログの採取を要求する、
付記６〜８のいずれかに記載のクライアント端末。

（付記１０）
クライアント端末にサービスを提供するサーバ装置であって、
前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ログ記録要求受付部を備えている、
ことを特徴とするサーバ装置。

（付記１１）
前記ログ記録要求受付部が、採取したログを、前記ログの採取を要求した前記クライアント端末を識別する情報に関連付けて格納する、
付記１０に記載のサーバ装置。

（付記１２）
クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを用いた障害検知方法であって、
（ａ）前記クライアント端末によって、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求する、ステップと、
（ｂ）前記クライアント端末から、前記ログの採取が要求された場合に、前記サーバ装置によって、ログを採取し、採取したログを格納する、ステップと、
を有することを特徴とする障害検知方法。

（付記１３）
前記（ａ）のステップにおいて、前記サーバ装置にリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値を超えているかどうかを判定し、判定の結果、前記時間が前記閾値を超えている場合に、障害が発生していると判断する、
付記１２に記載の障害検知方法。

（付記１４）
（ｃ）前記（ａ）のステップで、障害が発生していると判断した場合に、更に、クライアント端末によって、前記サービス提供システムの管理者の端末に、障害の発生を通知する、ステップを更に有する、付記１２または１３に記載の障害検知方法。

（付記１５）
前記（ａ）のステップにおいて、当該クライアント端末以外のクライアント端末が、サーバ装置に前記ログの採取を要求していない場合に、当該クライアント端末によって、当該クライアント端末以外のクライアント端末に対して、前記ログの採取を要求する旨を通知し、その後、前記ログの採取を要求する、
付記１２〜１４のいずれかに記載の障害検知方法。

（付記１６）
前記（ｂ）のステップにおいて、採取したログを、前記ログの採取を要求した前記クライアント端末を識別する情報に関連付けて格納する、
付記１２〜１５のいずれかに記載の障害検知方法。

（付記１７）
コンピュータに、
（ａ）サービスを提供するサーバ装置における障害の発生を監視する、ステップと、
（ｂ）前記（ａ）のステップで障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ステップとを、
実行させるプログラム。

（付記１８）
前記（ａ）のステップにおいて、前記サーバ装置にリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値を超えているかどうかを判定し、判定の結果、前記時間が前記閾値を超えている場合に、障害が発生していると判断する、
付記１７に記載のプログラム。

（付記１９）
（ｃ）前記（ａ）のステップで障害が発生していると判断した場合に、更に、前記サーバ装置の管理者の端末に、障害の発生を通知する、ステップを更に前記コンピュータに実行させる、
付記１７または１８に記載のプログラム。

（付記２０）
前記（ｂ）のステップにおいて、当該コンピュータ以外のクライアント端末が、サーバ装置に前記ログの採取を要求していない場合に、当該コンピュータ以外のクライアント端末に対して、前記ログの採取を要求する旨を通知し、その後、前記ログの採取を要求する、
付記１７〜１９のいずれかに記載のプログラム。

（付記２１）
コンピュータによって、クライアント端末にサービスを提供するためのプログラムであって、
前記コンピュータに、
（ａ）前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ステップを、実行させるプログラム。

（付記２２）
（ｂ）前記（ａ）のステップで採取したログを、前記ログの採取を要求した前記クライアント端末を識別する情報に関連付けて格納する、ステップを更に前記コンピュータに実行させる、付記２１に記載のプログラム。

以上のように、本発明によれば、コンピュータシステムにおいて、導入コストの増加を抑制しつつ、障害検知を確実に実行することができる。本発明は、Ｗｅｂサービスを提供するシステムに特に有効である。

１０ クライアント端末
１１ 監視部
１２ ログ採取要求部
１３ 監視プログラム
１４ Ｗｅｂブラウザ
２０ Ｗｅｂサーバ
２１ レスポンス閾値管理部
２２ ログ記録要求受付部
２３ 常駐プログラム
２４ 記憶部
２５ リクエスト受付部
２６ Ｗｅｂサービス提供部
１００ サービス提供システム
１１０ コンピュータ
１１１ ＣＰＵ
１１２ メインメモリ
１１３ 記憶装置
１１４ 入力インターフェイス
１１５ 表示コントローラ
１１６ データリーダ／ライタ
１１７ 通信インターフェイス
１１８ 入力機器
１１９ ディスプレイ装置
１２０ 記録媒体
１２１ バス

Claims (10)

1. クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを備え、
   前記クライアント端末は、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求し、
   前記サーバ装置は、前記クライアント端末から、前記ログの採取が要求された場合に、ログを採取し、採取したログを格納する、
   ことを特徴とするサービス提供システム。
2. 前記クライアント端末は、前記サーバ装置にリクエストを送信してから、それに対応するレスポンスを受信するまでの時間が、閾値を超えているかどうかを判定し、判定の結果、前記時間が前記閾値を超えている場合に、障害が発生していると判断する、
   請求項１に記載のサービス提供システム。
3. 前記クライアント端末は、障害が発生していると判断した場合に、更に、前記サービス提供システムの管理者の端末に、障害の発生を通知する、
   請求項１または２に記載のサービス提供システム。
4. 前記クライアント端末は、当該クライアント端末以外のクライアント端末が、サーバ装置に前記ログの採取を要求していない場合に、当該クライアント端末以外のクライアント端末に対して、前記ログの採取を要求する旨を通知し、その後、前記ログの採取を要求する、
   請求項１〜３のいずれかに記載のサービス提供システム。
5. 前記サーバ装置が、採取したログを、前記ログの採取を要求した前記クライアント端末を識別する情報に関連付けて格納する、
   請求項１〜４のいずれかに記載のサービス提供システム。
6. サービスを提供するサーバ装置における障害の発生を監視する、監視部と、
   障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ログ採取要求部とを、
   備えている、ことを特徴とするクライアント端末。
7. クライアント端末にサービスを提供するサーバ装置であって、
   前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ログ記録要求受付部を備えている、
   ことを特徴とするサーバ装置。
8. クライアント端末と、前記クライアント端末にサービスを提供するサーバ装置とを用いた障害検知方法であって、
   （ａ）前記クライアント端末によって、前記サーバ装置における障害の発生を監視し、障害が発生していると判断した場合に、前記サーバ装置に対してログの採取を要求する、ステップと、
   （ｂ）前記クライアント端末から、前記ログの採取が要求された場合に、前記サーバ装置によって、ログを採取し、採取したログを格納する、ステップと、
   を有することを特徴とする障害検知方法。
9. コンピュータに、
   （ａ）サービスを提供するサーバ装置における障害の発生を監視する、ステップと、
   （ｂ）前記（ａ）のステップで障害が発生していると判断された場合に、前記サーバ装置に対してログの採取を要求する、ステップとを、
   実行させるプログラム。
10. コンピュータによって、クライアント端末にサービスを提供するためのプログラムであって、
    前記コンピュータに、
    （ａ）前記クライアント端末が、当該サーバ装置において障害が発生していると判断し、当該サーバ装置に対してログの採取を要求した場合に、ログを採取し、採取したログを格納する、ステップを、実行させるプログラム。

Images