JP2015064872A - 監視システム、システム及び監視方法 - Google Patents

Abstract

【課題】サービス提供の可否を直接的に監視することができる監視システム、システム及び監視方法を提供する。
【解決手段】サービスの享受に必要な１以上のアクセス処理の順序及び当該１以上のアクセス処理それぞれで用いられるアクセス情報を定義したアクセスデータに基づいて、当該サービスを提供するサービス提供システムにアクセスし、１以上のアクセス処理それぞれのアクセス結果を取得するアクセス部１５１と、１以上のアクセス結果を解析し、１以上のアクセス処理それぞれのアクセス結果情報を生成するアクセス結果解析部１５３と、１以上のアクセス結果情報に基づいて、サービスの提供の可否に関するレポートを作成する作成部１５５と、レポートを出力する出力部１５７と、を備える。
【選択図】図２

Description

本発明は、監視システム、システム及び監視方法に関する。

従来から、クラウドサービスなどのウェブサービスを提供するサービス提供システムを監視する技術が知られている（例えば、特許文献１参照）。このような技術では、サービス提供システムを構成するサーバ群のプロセッサやメモリの利用状況及びネットワークの利用状況などハードウェアのリソースから、各サーバが動作可能であるか否かを監視することが一般的である。

従って、上述したような従来技術では、サービス提供システムを構成する各サーバの動作の可否からサービス提供の可否を間接的に監視しているに過ぎず、サービス提供の可否を直接的に監視することはできなかった。

本発明は、上記事情に鑑みてなされたものであり、サービス提供の可否を直接的に監視することができる監視システム、システム及び監視方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の一態様にかかる監視システムは、サービスの享受に必要な１以上のアクセス処理の順序及び当該１以上のアクセス処理それぞれで用いられるアクセス情報を定義したアクセスデータに基づいて、当該サービスを提供するサービス提供システムにアクセスし、前記１以上のアクセス処理それぞれのアクセス結果を取得するアクセス部と、前記１以上のアクセス結果を解析し、前記１以上のアクセス処理それぞれのアクセス結果情報を生成するアクセス結果解析部と、前記１以上のアクセス結果情報に基づいて、前記サービスの提供の可否に関するレポートを作成する作成部と、前記レポートを出力する出力部と、を備える。

本発明によれば、サービス提供の可否を直接的に監視することができるという効果を奏する。

図１は、第１実施形態の監視システムを含むシステムの構成の一例を示すブロック図である。 図２は、第１実施形態の監視システムの構成の一例を示すブロック図である。 図３は、第１実施形態の「ログイン」というアクセス処理に用いられるＨＴＴＰリクエストの一例を示す図である。 図４は、第１実施形態の「ログイン」というアクセス処理に対するＨＴＴＰレスポンスの一例を示す図である。 図５は、第１実施形態のアクセス結果情報のフォーマットの一例を示す図である。 図６は、第１実施形態のアクセス成功を表すアクセス結果情報の一例を示す図である。 図７は、第１実施形態のアクセス失敗を表すアクセス結果情報の一例を示す図である。 図８は、第１実施形態のレポートの一例を示す図である。 図９は、第１実施形態の監視システムで実行されるアクセス処理群の一例を示すシーケンス図である。 図１０は、第１実施形態の監視システムで実行される解析処理の一例を示すフローチャート図である。 図１１は、第２実施形態の監視システムを含むシステムの構成の一例を示すブロック図である。 図１２は、第２実施形態の監視システムの構成の一例を示すブロック図である。 図１３は、第２実施形態の「ユーザ情報取得」というアクセス処理に用いられるＨＴＴＰリクエストの一例を示す図である。 図１４は、第２実施形態のサービス提供システムの構成の一例を示すブロック図である。 図１５は、第２実施形態の記憶システムに記憶された情報の一例を示す図である。 図１６は、第２実施形態の検索部が記憶システムに送る検索リクエストの一例を示す図である。 図１７は、第２実施形態の検索リクエストに対する検索レスポンスの一例を示す図である。 図１８は、第２実施形態のエラー通知情報の一例を示す図である。 図１９は、第２実施形態のシステムで実行されるアクセス処理の一例を示すシーケンス図である。 図２０は、第２実施形態の監視システムで実行される検索及び出力処理の一例を示すシーケンス図である。 図２１は、変形例３のテーブルの一例を示す図である。 図２２は、変形例４のエラー情報の一例を示す図である。 図２３は、各実施形態の各システムのハードウェア構成の一例を示す図である。

以下、添付図面を参照しながら、本発明にかかる監視システム、システム及び監視方法の実施形態を詳細に説明する。

（第１実施形態）
図１は、第１実施形態の監視システム１００を含むシステム１０の構成の一例を示すブロック図である。システム１０は、図１に示すように、サービス提供システム１と監視システム１００とを、含む。サービス提供システム１と監視システム１００とは、インターネット２を介して接続されている。

サービス提供システム１は、インターネット２を介してクラウドサービスなどのウェブサービスを提供するものであり、１以上のサーバから構成されている。第１実施形態では、サービス提供システム１が提供するサービスが、クラウドプリンティングサービスである場合を例に取り説明するが、これに限定されるものではない。サービス提供システム１が提供可能なサービスは、例えば、ストレージサービスなど様々なクラウドサービス（広義には、ウェブサービス）が挙げられる。

監視システム１００は、サービス提供システム１によるサービス提供の可否を監視するものであり、１台のコンピュータで構成してもよいし、複数台のコンピュータで構成してもよい。

図２は、第１実施形態の監視システム１００の構成の一例を示すブロック図である。監視システム１００は、図２に示すように、通信部１１０と、操作部１２０と、表示部１３０と、記憶部１４０と、制御部１５０とを、備える。

通信部１１０は、インターネット２を介して、サービス提供システム１などの外部システムと通信するものであり、例えば、ＮＩＣ（Network Interface Card）などの通信装置により実現できる。

操作部１２０は、各種操作の入力を行うものであり、例えば、キーボード、マウス、タッチパッド、及びタッチパネルなどの入力装置により実現できる。

表示部１３０は、各種画面を表示するものであり、例えば、液晶ディスプレイ及びタッチパネル式ディスプレイなどの表示装置により実現できる。

記憶部１４０は、監視システム１００で実行される監視プログラムなどの各種プログラム、及び監視システム１００で行われる各種処理に使用されるデータなどを記憶する。記憶部１４０は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、メモリカード、光ディスク、及びＲＡＭ（Random Access Memory）などの磁気的、光学的、及び電気的に記憶可能な記憶装置の少なくともいずれかにより実現できる。

制御部１５０は、監視システム１００の各部を制御するものであり、ＣＰＵ（Central Processing Unit）などの制御装置により実現できる。制御部１５０は、アクセス部１５１と、アクセス結果解析部１５３と、作成部１５５と、出力部１５７とを、含む。制御部１５０は、記憶部１４０に記憶されている監視プログラムを起動（実行）することにより、アクセス部１５１、アクセス結果解析部１５３、作成部１５５、及び出力部１５７をソフトウェアとして実現する。

アクセス部１５１は、サービスの享受に必要な１以上のアクセス処理の順序及び当該１以上のアクセス処理それぞれで用いられるアクセス情報を定義したアクセスデータに基づいて、当該サービスを提供するサービス提供システム１にアクセスする。

アクセス部１５１は、所定のプロトコルでサービス提供システム１にアクセス可能、即ち、所定のプロトコルでサービス提供システム１と通信可能なソフトウェアモジュールであればよく、例えば、Apache JMeterなどのウェブサービスの負荷測定ツールやLinux（登録商標）のcurlコマンドなどが挙げられる。第１実施形態では、所定のプロトコルがＨＴＴＰ（Hyper Text Transfer Protocol）である場合を例に取り説明するが、これに限定されるものではなく、種々のプロトコルを採用できる。

アクセスデータは、サービスのユースケースにおける一連のアクセス処理（以下、「シナリオ」と称する場合がある）の順序、及びそれぞれのアクセス処理に用いられるアクセス情報を定義したものが該当する。例えば、クラウドプリンティングであれば、クラウドプリンティングのユースケースである「ログイン」、「印刷用文書送信」、「印刷用文書確認」、「印刷要求」、及び「ログアウト」という５つのアクセス処理（クラウドプリンティングのシナリオ）をこの順序で定義するとともに、それぞれのアクセス処理に用いられるアクセス情報を定義したものが該当する。なお第１実施形態では、各アクセス処理がＨＴＴＰ通信で行われるため、アクセス情報は、ＨＴＴＰリクエストとなる。第１実施形態では、アクセス情報は記憶部１４０に記憶されているものとするが、これに限定されるものではない。

図３は、第１実施形態の「ログイン」というアクセス処理に用いられるＨＴＴＰリクエストの一例を示す図である。なお、図３に示す例では、図示を省略しているが、アクセス先（詳細には、サービス提供システム１が提供するクラウドプリンティングサービスのログイン画面）のＵＲＬ（Uniform Resource Locator）もＨＴＴＰリクエストに含まれる。

また、ＨＴＴＰリクエストについては、全ての情報をアクセスデータに予め定義しておく必要はなく、少なくとも一部の情報を定義し、その他の情報については、ＨＴＴＰリクエストの送信時に生成するようにしてもよい。

そしてアクセス部１５１は、アクセスデータに基づいてサービス提供システム１にアクセスすると、１以上のアクセス処理それぞれのアクセス結果を取得する。第１実施形態では、前述のとおり、各アクセス処理がＨＴＴＰ通信で行われるため、アクセス結果は、ＨＴＴＰレスポンスとなる。

図４は、第１実施形態の「ログイン」というアクセス処理に対するＨＴＴＰレスポンスの一例を示す図である。なお、図４に示す例では、ログインに成功した場合のＨＴＴＰレスポンスを示している。

アクセス結果解析部１５３は、アクセス部１５１により取得された１以上のアクセス結果を解析し、１以上のアクセス処理それぞれのアクセス結果情報を生成し、生成した１以上のアクセス結果情報をログとして記憶部１４０に記憶する。

具体的には、アクセス結果解析部１５３は、取得された１以上のアクセス結果それぞれが、予め定められたアクセス結果であるか否かを判定する。第１実施形態では、前述のとおり、各アクセス処理がＨＴＴＰ通信で行われるため、アクセス結果解析部１５３は、ＨＴＴＰレスポンスのＨＴＴＰヘッダに含まれるステータスコード（図４に示す例では、「２００」）が、予め定められたステータスコード（アクセス成功時のステータスコード）であるか否かを判定したり、ＨＴＴＰレスポンスのＨＴＴＰボディに予め定められたキーワードが含まれているか否かを判定したりする。

例えば、「ログイン」というアクセス処理の場合、ＨＴＴＰレスポンスのＨＴＴＰボディに「ようこそ」というキーワードが含まれるものとする。この場合、アクセス結果解析部１５３は、ＨＴＴＰボディに「ようこそ」というキーワードが含まれているか否かを判定する。なお、ＨＴＴＰボディに含まれる予め定められたキーワードは、サービス提供システム１が提供するクラウドサービスやアクセス処理の内容に依存して定まる。

そしてアクセス結果解析部１５３は、判定の結果、予め定められたアクセス結果である場合、アクセス成功を表すアクセス結果情報を生成し、予め定められたアクセス結果でない場合、アクセス失敗を表すアクセス結果情報を生成する。

なお第１実施形態では、アクセス結果解析部１５３は、アクセス結果情報をＣＳＶ（Comma Separated Values）形式で生成し、記憶部１４０に記憶するものとするが、アクセス結果情報のデータ形式はこれに限定されるものではない。

図５は、第１実施形態のアクセス結果情報のフォーマットの一例を示す図である。図５に示す例では、アクセス結果情報は、日時、応答時間、アクセス内容、ＨＴＴＰステータスコード、アクセス失敗理由、及びアクセス先ＵＲＬを含む。

日時は、アクセスを行った日時を示す。応答時間は、ＨＴＴＰリクエストを送信してからＨＴＴＰレスポンスを受信するまでの時間を示す。アクセス内容は、アクセス処理の内容（「ログイン」や「ログアウト」など）を示す。ＨＴＴＰステータスコードは、ＨＴＴＰレスポンスのＨＴＴＰヘッダに含まれるステータスコード（「２００（ＯＫ）」や「４０４（Ｎｏｔ Ｆｏｕｎｄ）」）を示す。アクセス失敗理由は、アクセス失敗の理由を示すものであり、アクセス失敗を表すアクセス結果情報の場合に、アクセス結果解析部１５３がアクセス部１５１により取得されたアクセス結果と予め定められたアクセス結果との判定結果に基づいて生成する。アクセス先ＵＲＬは、アクセス先のＵＲＬを示す。なお、日時、応答時間、アクセス内容、ＨＴＴＰステータスコード、及びアクセス先ＵＲＬは、アクセス部１５１により取得されたアクセス結果に含まれている。

図６は、第１実施形態のアクセス成功を表すアクセス結果情報の一例を示す図であり、日時、応答時間、アクセス内容、ＨＴＴＰステータスコード、及びアクセス先ＵＲＬで構成されている。

図７は、第１実施形態のアクセス失敗を表すアクセス結果情報の一例を示す図であり、日時、応答時間、アクセス内容、ＨＴＴＰステータスコード、アクセス失敗理由、及びアクセス先ＵＲＬで構成されている。なお、図７に示す例では、アクセス結果解析部１５３は、ＨＴＴＰレスポンスのＨＴＴＰヘッダに含まれるステータスコードが、予め定められたステータスコード（図７に示す例では、「２００」）であるか否かを判定した結果、ＨＴＴＰヘッダに含まれるステータスコードが、「２００」でなかったため、アクセス失敗理由を「Test failed : code expected to match /200/」としている。

作成部１５５は、アクセス結果解析部１５３により生成された１以上のアクセス結果情報に基づいて、サービスの提供の可否に関するレポートを作成する。具体的には、作成部１５５は、レポートとして、１以上のアクセス結果情報を時系列で並べたレポートを作成する。従って、レポートは、１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれない場合、サービスを提供可能な旨を表し、１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれる場合、サービスを提供不可能な旨を表す。

なお第１実施形態では、作成部１５５は、記憶部１４０から１以上のアクセス結果情報を取得し、取得した１以上のアクセス結果情報を時系列に並べ、ＨＴＭＬ（HyperText Markup Language）形式に変換してレポートを作成するものとするが、レポートの形式はこれに限定されるものではない。

また第１実施形態では、作成部１５５は、１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれる場合、レポートとして、当該アクセス失敗を表すアクセス結果情報を強調したレポートを作成する。例えば、作成部１５５は、アクセス失敗を表すアクセス結果情報を、アクセス成功を表すアクセス結果情報と色分けしたレポートを作成する。これにより、アクセス失敗を表すアクセス結果情報を見つけやすくすることができる。

出力部１５７は、作成部１５５により作成されたレポートを出力する。出力部１５７は、例えば、作成部１５５により作成されたレポートを、表示部１３０のウェブブラウザ上に表示出力してもよいし、通信部１１０を介して図示せぬ管理者端末等のウェブブラウザ上に表示出力させてもよい。

図８は、第１実施形態のレポートの一例を示す図である。図８に示す例では、複数のアクセス結果情報が時系列で並べられており、アクセス失敗を表すアクセス結果情報がアクセス成功を表すアクセス結果情報と色分けされて表示されている。

図９は、第１実施形態の監視システム１００で実行されるアクセス処理群の一例を示すシーケンス図であり、クラウドプリンティングのユースケースに沿った一連のアクセス処理のシーケンスを示す。

まず、アクセス部１５１は、クラウドプリンティングのシナリオ及び当該シナリオを構成する各アクセス処理で用いられるアクセス情報を定義したアクセスデータに基づいて、ログイン要求のＨＴＴＰリクエストをサービス提供システム１へ送信し（ステップＳ１０１）、当該ＨＴＴＰリクエストに対するＨＴＴＰレスポンス（応答１）をサービス提供システム１から取得する（ステップＳ１０３）。

続いて、アクセス結果解析部１５３は、取得されたＨＴＴＰレスポンス（応答１）が、予め定められたＨＴＴＰレスポンスであるか否かを判定することで、ログインできたか否かを解析し（ステップＳ１０５）、解析結果に応じたアクセス結果情報を生成し、ログとして記憶部１４０に出力（記憶）する（ステップＳ１０７）。

続いて、アクセス部１５１は、アクセスデータに基づいて、印刷文書登録のＨＴＴＰリクエストをサービス提供システム１へ送信し（ステップＳ１１１）、当該ＨＴＴＰリクエストに対するＨＴＴＰレスポンス（応答２）をサービス提供システム１から取得する（ステップＳ１１３）。

続いて、アクセス結果解析部１５３は、取得されたＨＴＴＰレスポンス（応答２）が、予め定められたＨＴＴＰレスポンスであるか否かを判定することで、文書登録できたか否かを解析し（ステップＳ１１５）、解析結果に応じたアクセス結果情報を生成し、ログとして記憶部１４０に出力（記憶）する（ステップＳ１１７）。

以降、監視システム１００は、クラウドプリンティングのシナリオに沿って同様の処理を繰り返す。

最後に、アクセス部１５１は、アクセスデータに基づいて、ログアウトのＨＴＴＰリクエストをサービス提供システム１へ送信し（ステップＳ１２１）、当該ＨＴＴＰリクエストに対するＨＴＴＰレスポンス（応答Ｎ）をサービス提供システム１から取得する（ステップＳ１２３）。

続いて、アクセス結果解析部１５３は、取得されたＨＴＴＰレスポンス（応答Ｎ）が、予め定められたＨＴＴＰレスポンスであるか否かを判定することで、ログアウトできたか否かを解析し（ステップＳ１２５）、解析結果に応じたアクセス結果情報を生成し、ログとして記憶部１４０に出力（記憶）する（ステップＳ１２７）。

続いて、作成部１５５は、記憶部１４０から１以上のログを取得し（ステップＳ１３１、Ｓ１３３）、取得した１以上のログを時系列に並べ、ＨＴＭＬ形式に変換してレポートを作成する（ステップＳ１３５）。

図１０は、第１実施形態の監視システム１００で実行される解析処理の一例を示すフローチャート図である。

まず、アクセス部１５１は、アクセス処理のＨＴＴＰリクエストをサービス提供システム１へ送信し（ステップＳ２０１）、当該ＨＴＴＰリクエストに対するＨＴＴＰレスポンスをサービス提供システム１から受信する（ステップＳ２０３）。なお、アクセス部１５１が一定時間以内にＨＴＴＰレスポンスを受信しなかった場合、アクセス結果解析部１５３は、アクセス失敗と判定し（ステップＳ２１１）、アクセス失敗を表すアクセス結果情報を生成する。

続いて、アクセス結果解析部１５３は、受信されたＨＴＴＰレスポンスのＨＴＴＰステータスコードが、予期したステータスコード（アクセス成功時のステータスコード）であるか否かを判定する（ステップＳ２０５）。なお、ＨＴＴＰステータスコードが予期したステータスコードでない場合（ステップＳ２０５でＮｏ）、アクセス結果解析部１５３は、アクセス失敗と判定し（ステップＳ２１１）、アクセス失敗を表すアクセス結果情報を生成する。

ＨＴＴＰステータスコードが予期したステータスコードである場合（ステップＳ２０５でＹｅｓ）、アクセス結果解析部１５３は、ＨＴＴＰステータスコードがリダイレクトを示すか否かを判定する（ステップＳ２０６）。なお、ＨＴＴＰステータスコードがリダイレクトを示す場合（ステップＳ２０６でＹｅｓ）、ステップＳ２０１へ戻り、アクセス部１５１は、リダイレクト先（ＨＴＴＰレスポンスで指定されたリダイレクト先のＵＲＬ）へアクセス（ＨＴＴＰリクエストを送信）する。

ＨＴＴＰステータスコードがリダイレクトを示さない場合（ステップＳ２０６でＮｏ）、アクセス結果解析部１５３は、ＨＴＴＰボディの内容が予期したものであるか否か、即ち、ＨＴＴＰボディに予期したキーワードが含まれているか否かを判定する（ステップＳ２０７）。なお、ＨＴＴＰボディの内容が予期したものでない場合（ステップＳ２０７でＮｏ）、アクセス結果解析部１５３は、アクセス失敗と判定し（ステップＳ２１１）、アクセス失敗を表すアクセス結果情報を生成する。

ＨＴＴＰボディの内容が予期したものである場合（ステップＳ２０７でＹｅｓ）、アクセス結果解析部１５３は、アクセス成功と判定し（ステップＳ２０９）、アクセス成功を表すアクセス結果情報を生成する。

以上のように第１実施形態では、監視システムは、ユーザがクラウドサービスを享受するためのサービス提供システムに対する一連のアクセス処理時に送信されるデータをアクセスデータとして定義し、当該アクセスデータに基づいて一連のアクセス処理を実行してアクセス結果を解析し、サービスの提供の可否に関するレポートを作成する。

従って第１実施形態によれば、従来のように、サービス提供システムを構成する各サーバのハードウェアのリソースから各サーバが動作可能であるか否かを監視することで、サービス提供の可否を間接的に監視するのではなく、サービス提供システムによるサービス提供の可否を直接的に監視することができる。つまり第１実施形態では、ユーザ視点、即ち、サービスレベルでのサービス提供の可否を監視することができる。

この結果、第１実施形態では、従来のように、サービス提供システムとしてサービスを提供可能であるにも関わらず、サービス提供システムを構成するサーバ群の一部のサーバが動作不能であるため、サービス提供システムとしてサービスを提供できないと判断されてしまうことを防止でき、サービスを提供可能であるか否かの判断精度を向上させることができる。

（第２実施形態）
第２実施形態では、サービス提供システム内におけるエラー発生箇所をユーザに把握させることが可能な例について説明する。以下では、第１実施形態との相違点の説明を主に行い、第１実施形態と同様の機能を有する構成要素については、第１実施形態と同様の名称・符号を付し、その説明を省略する。

図１１は、第２実施形態の監視システム１１００を含むシステム１０１０の構成の一例を示すブロック図である。システム１０１０は、図１１に示すように、外部システム１２００と記憶システム１３００（エラー記憶部の一例）とを、更に含む。外部システム１２００及び記憶システム１３００は、インターネット２に接続されている。

外部システム１２００は、どのような処理を行うシステムであってもよいが、例えば、データベースシステムなどが挙げられる。なお、外部システム１２００は、１以上のサーバから構成されている。

記憶システム１３００は、例えば、ストレージシステムなどが挙げられる。なお、記憶システム１３００は、１以上のサーバから構成されている。

図１２は、第２実施形態の監視システム１１００の構成の一例を示すブロック図である。監視システム１１００は、図１２に示すように、記憶部１１４０、並びに制御部１１５０のアクセス部１１５１、出力部１１５７、及び検索部１１５９が、第１実施形態と相違する。

アクセス部１１５１は、アクセス処理を識別するアクセス処理識別情報を生成し、当該アクセス処理識別情報と当該アクセス処理で用いられるアクセス情報とを用いて、当該アクセス処理を行う。なお、第２実施形態でも、各アクセス処理がＨＴＴＰ通信で行われ、アクセス情報は、ＨＴＴＰリクエストであるものとする。

アクセス処理識別情報は、アクセス部１１５１がアクセス処理を行う際に生成する識別子であり、毎回内容が異なるものとする。従って、異なるタイミングで同一のアクセス処理（ＨＴＴＰリクエスト）を行う場合であっても、アクセス処理識別情報を用いれば、これらのアクセス処理を識別できる。

図１３は、第２実施形態の「ユーザ情報取得」というアクセス処理に用いられるＨＴＴＰリクエストの一例を示す図である。図１３に示すＨＴＴＰリクエストは、記憶部１１４０に記憶されているＨＴＴＰリクエストにアクセス部１１５１より生成されたＸ−Ｒｅｑｕｅｓｔ−ＩＤ（アクセス処理識別情報の一例）が付与されて生成されたＨＴＴＰリクエストである。

ここで、サービス提供システム１００１、外部システム１２００、及び記憶システム１３００について説明する。第２実施形態では、サービス提供システム１００１が１のサーバで構成されている場合を例に取り説明するが、これに限定されるものではない。

図１４は、第２実施形態のサービス提供システム１００１の構成の一例を示すブロック図である。サービス提供システム１００１は、図１４に示すように、処理部１００２−１〜１００２−３を備える。

処理部１００２−１は、受付部１００３−１と、処理要求部１００４−１と、処理結果解析部１００５−１と、を含む。処理部１００２−２は、受付部１００３−２と、処理要求部１００４−２と、処理結果解析部１００５−２と、を含む。処理部１００２−３は、受付部１００３−３と、処理要求部１００４−３と、処理結果解析部１００５−３と、を含む。

なお、以下の説明では、処理部１００２−１〜１００２−３を各々区別する必要がない場合は、単に処理部１００２と称し、受付部１００３−１〜１００３−３を各々区別する必要がない場合は、単に受付部１００３と称し、処理要求部１００４−１〜１００４−３を各々区別する必要がない場合は、単に処理要求部１００４と称し、処理結果解析部１００５−１〜１００５−３を各々区別する必要がない場合は、単に処理結果解析部１００５と称する場合がある。

また第２実施形態では、処理部１００２の数が３つである場合を例に取り説明するが、これに限定されず、複数であれば、いくつであってもよい。処理部１００２−１〜１００２−３は、階層構造を有している。第２実施形態では、処理部１００２−１の階層が最も高く、処理部１００２−２の階層が処理部１００２−１の次に高く、処理部１００２−３の階層が処理部１００２−２の次に高いものとするが、これに限定されるものではない。

受付部１００３は、監視システム１１００からのアクセス処理、又は複数の処理部１００２のうち自身の上位階層に位置する処理部１００２からの処理要求を受け付ける。

第２実施形態では、処理部１００２−１〜１００２−３は、前述した階層構造を有しているため、受付部１００３−１は、監視システム１１００からのアクセス処理を受け付け、受付部１００３−２は、処理部１００２−１からの処理要求を受け付け、受付部１００３−３は、処理部１００２−２からの処理要求を受け付ける。なお、処理要求は、アクセス処理同様、ＨＴＴＰリクエストであるものとするが、これに限定されるものではない。

処理要求部１００４は、受付部１００３により受け付けられたアクセス処理又は処理要求に基づいて、当該アクセス処理又は処理要求に含まれるアクセス処理識別情報を含む処理要求を複数の処理部１００２のうち自身の下位階層に位置する処理部１００２又は外部システム１２００に行って処理結果を取得する。

第２実施形態では、処理部１００２−１〜１００２−３は、前述した階層構造を有している。受付部１００３−１は、前述の通り、監視システム１１００からのアクセス処理を受け付ける。このため、処理要求部１００４−１は、監視システム１１００からのアクセス処理に基づいて、当該アクセス処理を処理するための処理要求を生成して、当該アクセス処理に含まれるアクセス処理識別情報を付与し、アクセス処理識別情報が付与された処理要求を処理部１００２−２に行い、処理部１００２−２から処理結果を取得し、監視システム１１００に返却する。

また受付部１００３−２は、前述の通り、処理部１００２−１からの処理要求を受け付ける。このため、処理要求部１００４−２は、処理部１００２−１からの処理要求に基づいて、当該処理要求を処理するための処理要求を生成して、処理部１００２−１からの処理要求に含まれるアクセス処理識別情報を付与し、アクセス処理識別情報が付与された処理要求を処理部１００２−３に行い、処理部１００２−３から処理結果を取得し、処理部１００２−１に返却する。

また受付部１００３−３は、前述の通り、処理部１００２−２からの処理要求を受け付ける。このため、処理要求部１００４−３は、処理部１００２−２からの処理要求に基づいて、当該処理要求を処理するための処理要求を生成して、処理部１００２−２からの処理要求に含まれるアクセス処理識別情報を付与し、アクセス処理識別情報が付与された処理要求を外部システム１２００に行い、外部システム１２００から処理結果を取得し、処理部１００２−２に返却する。

処理結果解析部１００５は、返却された処理結果を解析し、当該処理結果が処理失敗を表す場合、当該処理結果と、当該処理結果を得るために行った処理要求と、当該処理要求の送信元を示す送信元情報と、当該処理要求の送信先を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する。なお、処理結果が処理成功であるか処理失敗であるかの解析手法は、第１実施形態のアクセス結果解析部１５３と同様の手法を採用すればよい。

処理結果解析部１００５−１は、処理部１００２−２から返却された処理結果を解析し、当該処理結果が処理失敗を表す場合、当該処理結果と、当該処理結果を得るために行った処理要求と、処理部１００２−１を示す送信元情報と、処理部１００２−２を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する。

処理結果解析部１００５−２は、処理部１００２−３から返却された処理結果を解析し、当該処理結果が処理失敗を表す場合、当該処理結果と、当該処理結果を得るために行った処理要求と、処理部１００２−２を示す送信元情報と、処理部１００２−３を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する。

処理結果解析部１００５−３は、外部システム１２００から返却された処理結果を解析し、当該処理結果が処理失敗を表す場合、当該処理結果と、当該処理結果を得るために行った処理要求と、処理部１００２−３を示す送信元情報と、外部システム１２００を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する。

図１５は、第２実施形態の記憶システム１３００に記憶された情報の一例を示す図である。図１５に示す例では、日時、リクエストモジュール（送信元情報の一例）、レスポンスモジュール（送信先情報の一例）、リクエストヘッダ（処理要求の一例）、及びレスポンスヘッダ（処理結果の一例）を記憶している。

なお、図１５に示す例では、モジュールＡが処理部１００２−１を表し、モジュールＢが処理部１００２−２を表し、モジュールＤが処理部１００２−３を表し、外部サービスが外部システム１２００を表す。

また、図１５に示す例では、リクエスト及びレスポンスのいずれにおいてもヘッダの情報を保存し、ボディの情報を保存していない。これは、ボディの情報はサイズが大きくなりやすく、ボディの情報も保存すると、記憶システム１３００の記憶容量を圧迫するおそれがあり、ボディの情報を保存することは、セキュリティの観点から好ましくない場合も考えられるためである。

そして、図１５に示す例では、処理部１００２−１が、「ユーザ情報取得」というアクセス処理を処理するため、「ユーザ１の設定情報取得」という処理要求を処理部１００２−２に行い、処理部１００２−２が、「ユーザ１の設定情報取得」という処理要求を処理するため、「ＩＤ“１２３４５”の画像取得」という処理要求を処理部１００２−３に行い、処理部１００２−３が、「ＩＤ“１２３４５”の画像取得」という処理要求を処理するため、「画像取得」という処理要求を外部システム１２００に行っているが、処理部１００２−３が外部システム１２００からの画像取得に失敗しているため、全ての処理結果が失敗となっている。

ここで、監視システム１１００の説明に戻る。

検索部１１５９は、アクセス処理識別情報に対応付けられた１以上のエラー情報を記憶システム１３００から検索する。具体的には、検索部１１５９は、アクセス結果解析部１５３の解析の結果、１以上のアクセス結果情報のいずれかがアクセス失敗を表す場合、アクセス結果情報がアクセス失敗を表すアクセス処理のアクセス処理識別情報を含む１以上のエラー情報を記憶システム１３００から検索する。

例えば、図１５に示す例の場合、「ユーザ情報取得」というアクセス処理のアクセス結果情報がアクセス失敗を表すため、検索部１１５９は、「ユーザ情報取得」というアクセス処理で用いられたＸ−Ｒｅｑｕｅｓｔ−ＩＤを含む１以上のエラー情報を記憶システム１３００から検索する。なお、Ｘ−Ｒｅｑｕｅｓｔ−ＩＤは、エラー情報に含まれるリクエストヘッダに含まれている。図１６に、この検索時に用いられ、検索部１１５９が記憶システム１３００に送る検索リクエストの一例を示す。この検索リクエストの結果、検索部１１５９は、図１５に示す３件のエラー情報を取得する。図１７に、図１６に示す検索リクエストに対する検索レスポンスの一例を示す。

出力部１１５７は、検索部１１５９により検索された１以上のエラー情報に基づく出力を更に行う。例えば、出力部１１５７は、図１７に示す検索レスポンスを、図１８に示すように、エラー情報が発生した時系列に整形したエラー通知情報を生成し、システム１０１０の運用者や解析者のメールアドレスへ通知する。なお、システム１０１０の運用者や解析者のメールアドレスは、記憶部１１４０に記憶されているものとする。エラー通知情報では、エラー情報が発生した時系列で整形されているため、運用者や解析者は、エラー発生箇所（エラーの原因となった処理部１００２又は外部サービス１２００）を容易に把握できる。なお、エラー情報に基づく通知は、ＲＳＳ（RDF Site Summary）の更新やＩＲＣ（Internet Relay Chat）への通知としてもよい。

図１９は、第２実施形態のシステム１０１０で実行されるアクセス処理の一例を示すシーケンス図である。なお、図１９に示す例では、処理の結果、図１５に示すエラー情報が記憶システム１３００に記憶される例について説明する。

まず、アクセス部１１５１は、Ｘ−Ｒｅｑｕｅｓｔ−ＩＤを生成し、記憶部１１４０に記憶されているＨＴＴＰリクエストに付与して、「ユーザ情報取得」というＨＴＴＰリクエストを行う（ステップＳ３０１）。

続いて、処理部１００２−１は、監視システム１１００からのＨＴＴＰリクエストに基づいて、当該ＨＴＴＰリクエストを処理するためのＨＴＴＰリクエストを生成して、監視システム１１００からのＨＴＴＰリクエストに含まれるＸ−Ｒｅｑｕｅｓｔ−ＩＤを付与し、Ｘ−Ｒｅｑｕｅｓｔ−ＩＤが付与されたＨＴＴＰリクエストを処理部１００２−２に行う（ステップＳ３０３）。

続いて、処理部１００２−２は、処理部１００２−１からのＨＴＴＰリクエストに基づいて、当該ＨＴＴＰリクエストを処理するためのＨＴＴＰリクエストを生成して、処理部１００２−１からのＨＴＴＰリクエストに含まれるＸ−Ｒｅｑｕｅｓｔ−ＩＤを付与し、Ｘ−Ｒｅｑｕｅｓｔ−ＩＤが付与されたＨＴＴＰリクエストを処理部１００２−３に行う（ステップＳ３０５）。

続いて、処理部１００２−３は、処理部１００２−２からのＨＴＴＰリクエストに基づいて、当該ＨＴＴＰリクエストを処理するためのＨＴＴＰリクエストを生成して、処理部１００２−２からのＨＴＴＰリクエストに含まれるＸ−Ｒｅｑｕｅｓｔ−ＩＤを付与し、Ｘ−Ｒｅｑｕｅｓｔ−ＩＤが付与されたＨＴＴＰリクエストを外部システム１２００に行う（ステップＳ３０７）。

続いて、処理部１００２−３は、外部システム１２００に行ったＨＴＴＰリクエストのＨＴＴＰレスポンスを、外部システム１２００から取得する（ステップＳ３０９）。ここでは、図１５に示す例で説明したとおり、ＨＴＴＰレスポンスは、エラーレスポンスであるとする。

続いて、処理部１００２−３は、ＨＴＴＰレスポンスがエラーレスポンスであるため、ＨＴＴＰレスポンスのヘッダと、ＨＴＴＰリクエストのヘッダと、処理部１００２−３を示す送信元情報と、外部システム１２００を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する（ステップＳ３１１）。

続いて、処理部１００２−３は、ＨＴＴＰレスポンスとしてエラーレスポンスを処理部１００２−２に返却する（ステップＳ３１３）。

続いて、処理部１００２−２は、ＨＴＴＰレスポンスがエラーレスポンスであるため、ＨＴＴＰレスポンスのヘッダと、ＨＴＴＰリクエストのヘッダと、処理部１００２−２を示す送信元情報と、処理部１００２−３を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する（ステップＳ３１５）。

続いて、処理部１００２−２は、ＨＴＴＰレスポンスとしてエラーレスポンスを処理部１００２−１に返却する（ステップＳ３１７）。

続いて、処理部１００２−１は、ＨＴＴＰレスポンスがエラーレスポンスであるため、ＨＴＴＰレスポンスのヘッダと、ＨＴＴＰリクエストのヘッダと、処理部１００２−１を示す送信元情報と、処理部１００２−２を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶する（ステップＳ３１９）。

続いて、処理部１００２−１は、ＨＴＴＰレスポンスとしてエラーレスポンスを監視システム１１００に返却する（ステップＳ３２１）。

図２０は、第２実施形態の監視システム１１００で実行される検索及び出力処理の一例を示すシーケンス図である。

まず、アクセス結果解析部１５３は、１以上のアクセス結果情報（ＨＴＴＰレスポンス）のいずれかがアクセス失敗を表すか否か判定する（ステップＳ４０１）。ここでは、１つのアクセス結果情報がアクセス失敗を表すものとする。

続いて、アクセス結果解析部１５３は、アクセス結果情報がアクセス失敗を表すＨＴＴＰリクエストに付与されたＸ−Ｒｅｑｕｅｓｔ−ＩＤを検索部１１５９に通知する（ステップＳ４０３）。

続いて、検索部１１５９は、通知されたＸ−Ｒｅｑｕｅｓｔ−ＩＤをキーとする検索リクエストを記憶システム１３００に送る（ステップＳ４０５）。

続いて、記憶システム１３００は、送られたＸ−Ｒｅｑｕｅｓｔ−ＩＤをキーとして、当該Ｘ−Ｒｅｑｕｅｓｔ−ＩＤを含むエラー情報の検索を行い、検索された１以上のエラー情報を含む検索レスポンスを監視システム１１００に返却する（ステップＳ４０７）。
続いて、検索部１１５９は、返却された検索レスポンスに含まれる１以上のエラー情報を出力部１１５７に返却する（ステップＳ４０９）。

続いて、出力部１１５７は、返却された１以上のエラー情報を整形してエラー通知情報を生成し（ステップＳ４１１）、システム１０１０の運用者や解析者のメールアドレスへ通知する（ステップＳ４１３）。

以上のように第２実施形態では、監視システムは、アクセス処理に当該アクセス処理を識別可能なアクセス処理識別情報を含め、サービス提供システムの各処理部は、上位から通知されたアクセス処理識別情報を含めた処理要求を下位に行い、処理結果が失敗となった場合には、アクセス処理識別情報を含む処理要求、処理結果、送信元情報、及び送信先情報を対応付けたエラー情報を記憶する。

このため第２実施形態によれば、アクセス処理識別情報を基にエラー情報を検索すれば、このアクセス処理識別情報を用いたアクセス処理において、エラーが発生した１以上の処理部、及び１以上の処理部のうちエラーの原因となった処理部を、ログ解析などを行わなくてもユーザに把握させることができる。

（変形例）
なお、本発明は、上記各実施形態に限定されるものではなく、種々の変形が可能である。

（変形例１）
上記第２実施形態において、検索部１１５９は、操作部１２０からのユーザ操作に基づいて入力されたアクセス処理識別情報を含む１以上のエラー情報を記憶システム１３００から検索するようにしてもよい。

このようにすれば、システム１０１０の運用者や解析者は、アクセス結果解析部１５３の解析の結果に関係なく、過去のエラー情報なども検索でき、発生頻度の高いエラーを事前に把握するなど、システム１０１０の潜在的な問題の発見に繋げることができる。

（変形例２）
上記第２実施形態において、検索部１１５９は、アクセス結果解析部１５３の解析の結果、１以上のアクセス結果情報のいずれもがアクセス失敗を表さない場合であっても、アクセス処理のアクセス処理識別情報を含む１以上のエラー情報を記憶システム１３００から検索してもよい。

このようにすれば、例えば、処理部１００２が取得した処理結果が処理失敗であっても、予め定められた回数リトライ処理を行う仕様であり、処理結果が最終的に処理成功となったような場合であっても、処理結果が処理成功となるまでの処理失敗となった処理結果などをシステム１０１０の運用者や解析者に把握させることができる。

（変形例３）
上記第２実施形態において、出力部１１５７は、エラー情報の原因となった処理部１００２の担当者のアドレス又はエラー情報の原因となった外部システム１２００の担当者のアドレスにエラー情報に基づく出力を行うようにしてもよい。

この場合、図２１に示すような、処理部（モジュール）又は外部システム（外部サービス）毎に担当者のアドレスを対応付けたテーブルを記憶部１１４０に記憶しておき、出力部１１５７は、エラー情報の原因となった処理部又は外部システムに対応付けられたアドレスにエラー情報に基づく出力を行えばよい。

このようにすれば、処理部又は外部システム単位でエラー通知を行うことができ、より早期な対応が期待できる。

（変形例４）
上記第２実施形態において、処理結果解析部１００５は、処理結果が処理失敗を表す場合、図２２に示すように、当該処理結果、当該処理結果を得るために行った処理要求、送信元情報、及び送信先情報に加え、処理結果解析部１００５を含む処理部を特定可能な特定情報を対応付けたエラー情報を記憶システム１３００に記憶するようにしてもよい。特定情報は、例えば、処理部を含むサーバのＩＰアドレス、処理部を含むＯＳ（Operating System）のＯＳ名、処理部のＩＤ、及び処理部のバージョン情報などが挙げられる。

このようにすれば、処理部を含むサーバをミラーリングなど冗長に構成して、サービス提供システム１００１を構築している場合や、サーバ内に同種の処理部１００２が複数存在するような場合であっても、エラーが生じた処理部１００２を特定できる。

（変形例５）
上記第２実施形態において、各処理部１００２が処理結果解析部１００５を含むのではなく、サービス提供システム１００１が処理結果解析部１００５を含み、処理結果解析部１００５は、複数の処理要求部１００４それぞれが取得した処理結果を解析し、処理結果が処理失敗を表す場合、処理結果と、前記処理結果を得るために行った処理要求と、当該処理要求の送信元を示す送信元情報と、当該処理要求の送信先を示す送信先情報と、を対応付けたエラー情報を記憶システム１３００に記憶するようにしてもよい。

このようにすれば、各処理部１００２が処理結果解析部１００５を含む必要がなく、保守性を向上できる。またこのようにすれば、処理結果解析部１００５は、非同期でエラー情報を記憶システム１３００に記憶できるため、設計上好ましくなる。

（変形例６）
上記第２実施形態では、各処理部１００２が同期的に処理要求を行う例について説明したが、上位の処理部１００２がサービス提供システム１００１のキューなど図示せぬ記憶部に処理要求を蓄積していく、下位の処理部１００２が記憶部に蓄積されている処理要求を順次処理するような非同期的に処理要求を行う場合にも適用できる。

（ハードウェア構成）
図２３は、上記各実施形態の監視システム、サービス提供システム、外部システム、及び記憶システム１３００（以下、「上記各実施形態の各システム」と称する）のハードウェア構成の一例を示す図である。上記各実施形態の各システムは、ＣＰＵなどの制御装置８０１と、ＲＯＭやＲＡＭなどの記憶装置８０２と、ＨＤＤなどの外部記憶装置８０３と、ディスプレイなどの表示装置８０４と、キーボードやマウスなどの入力装置８０５と、通信Ｉ／Ｆ（インタフェース）などの通信装置８０６と、を備えており、通常のコンピュータを利用したハードウェア構成となっている。

上記各実施形態の各システムで実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、ＣＤ−Ｒ、メモリカード、ＤＶＤ（Digital Versatile Disk）、フレキシブルディスク（ＦＤ）等のコンピュータで読み取り可能な記憶媒体に記憶されて提供される。

また、上記各実施形態の各システムで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、上記各実施形態の各システムで実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。また、上記各実施形態の各システムで実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するようにしてもよい。

上記各実施形態の各システムで実行されるプログラムは、上述した各部をコンピュータ上で実現させるためのモジュール構成となっている。実際のハードウェアとしては、ＣＰＵがＨＤＤからプログラムをＲＡＭ上に読み出して実行することにより、上記各部がコンピュータ上で実現されるようになっている。

１、１００１ サービス提供システム
１０、１０１０ システム
２ インターネット
１００、１１００ 監視システム
１１０ 通信部
１２０ 操作部
１３０ 表示部
１４０、１１４０ 記憶部
１５０、１１５０ 制御部
１５１、１１５１ アクセス部
１５３ アクセス結果解析部
１５５ 作成部
１５７、１１５７ 出力部
１１５９ 検索部
８０１ 制御装置
８０２ 記憶装置
８０３ 外部記憶装置
８０４ 表示装置
８０５ 入力装置
８０６ 通信装置
１００２−１〜１００２−３（１００２） 処理部
１００３−１〜１００３−３（１００３） 受付部
１００４−１〜１００４−３（１００４） 処理要求部
１００５−１〜１００５−３（１００５） 処理結果解析部
１２００ 外部システム
１３００ 記憶システム

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

Claims (14)

1. サービスの享受に必要な１以上のアクセス処理の順序及び当該１以上のアクセス処理それぞれで用いられるアクセス情報を定義したアクセスデータに基づいて、当該サービスを提供するサービス提供システムにアクセスし、前記１以上のアクセス処理それぞれのアクセス結果を取得するアクセス部と、
   前記１以上のアクセス結果を解析し、前記１以上のアクセス処理それぞれのアクセス結果情報を生成するアクセス結果解析部と、
   前記１以上のアクセス結果情報に基づいて、前記サービスの提供の可否に関するレポートを作成する作成部と、
   前記レポートを出力する出力部と、
   を備える監視システム。
2. 前記アクセス結果解析部は、前記１以上のアクセス結果それぞれが、予め定められたアクセス結果であるか否かを判定し、予め定められたアクセス結果である場合、アクセス成功を表すアクセス結果情報を生成し、予め定められたアクセス結果でない場合、アクセス失敗を表すアクセス結果情報を生成する請求項１に記載の監視システム。
3. 前記アクセス失敗を表すアクセス結果情報は、取得されたアクセス結果と前記予め定められたアクセス結果との判定結果に基づくアクセス失敗理由を示す請求項２に記載の監視システム。
4. 前記作成部は、前記レポートとして、前記１以上のアクセス結果情報を時系列で並べたレポートを作成する請求項１〜３のいずれか１つに記載の監視システム。
5. 前記レポートは、前記１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれない場合、前記サービスを提供可能な旨を表し、前記１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれる場合、前記サービスを提供不可能な旨を表す請求項４に記載の監視システム。
6. 前記作成部は、前記１以上のアクセス結果情報にアクセス失敗を表すアクセス結果情報が含まれる場合、前記レポートとして、当該アクセス失敗を表すアクセス結果情報を強調したレポートを作成する請求項４又は５に記載の監視システム。
7. 前記サービスは、クラウドサービスである請求項１〜６のいずれか１つに記載の監視システム。
8. 請求項１〜７のいずれか１つに記載の監視システムと前記サービス提供システムとを備えるシステムであって、
   前記アクセス部は、アクセス処理を識別するアクセス処理識別情報を生成し、当該アクセス処理識別情報と当該アクセス処理で用いられるアクセス情報とを用いて、当該アクセス処理を行い、
   前記サービス提供システムは、
   階層構造を有する複数の処理部を備え、
   前記複数の処理部それぞれは、
   前記監視システムからのアクセス処理、又は前記複数の処理部のうち自身の上位階層に位置する処理部からの処理要求を受け付ける受付部と、
   前記受け付けられたアクセス処理又は処理要求に基づいて、前記受け付けられたアクセス処理又は処理要求に含まれる前記アクセス処理識別情報を含む処理要求を前記複数の処理部のうち自身の下位階層に位置する処理部又は外部システムに行って処理結果を取得する処理要求部と、
   前記処理結果を解析し、前記処理結果が処理失敗を表す場合、前記処理結果と、前記処理結果を得るために行った処理要求と、当該処理要求の送信元を示す送信元情報と、当該処理要求の送信先を示す送信先情報と、を対応付けたエラー情報をエラー記憶部に記憶する処理結果解析部と、を含み、
   前記監視システムは、
   前記アクセス処理識別情報に対応付けられた１以上のエラー情報を前記エラー記憶部から検索する検索部を更に備え、
   前記出力部は、検索された前記１以上のエラー情報に基づく出力を更に行うシステム。
9. 前記検索部は、前記１以上のアクセス結果情報のいずれかがアクセス失敗を表す場合、アクセス結果情報がアクセス失敗を表すアクセス処理のアクセス処理識別情報を含む１以上のエラー情報を前記エラー記憶部から検索する請求項８に記載のシステム。
10. 前記検索部は、ユーザ操作に基づいて入力されたアクセス処理識別情報を含む１以上のエラー情報を前記エラー記憶部から検索する請求項８に記載のシステム。
11. 前記出力部は、前記エラー情報の原因となった処理部の担当者のアドレス又は前記エラー情報の原因となった前記外部システムの担当者のアドレスに前記エラー情報に基づく出力を行う請求項８〜１０のいずれか１つに記載のシステム。
12. 前記エラー情報は、当該エラー情報を前記エラー記憶部に記憶した処理結果解析部を含む処理部を特定可能な特定情報を更に含む請求項８〜１１のいずれか１つに記載のシステム。
13. 請求項１〜７のいずれか１つに記載の監視システムと前記サービス提供システムとを備えるシステムであって、
    前記アクセス部は、アクセス処理を識別するアクセス処理識別情報を生成し、当該アクセス処理識別情報と当該アクセス処理で用いられるアクセス情報とを用いて、当該アクセス処理を行い、
    前記サービス提供システムは、
    階層構造を有する複数の処理部を備え、
    前記複数の処理部それぞれは、
    前記監視システムからのアクセス処理、又は前記複数の処理部のうち自身の上位階層に位置する処理部からの処理要求を受け付ける受付部と、
    前記受け付けられたアクセス処理又は処理要求に基づいて、前記受け付けられたアクセス処理又は処理要求に含まれる前記アクセス処理識別情報を含む処理要求を前記複数の処理部のうち自身の下位階層に位置する処理部又は外部システムに行って処理結果を取得する処理要求部と、を含み、
    前記サービス提供システムは、
    前記複数の処理要求部それぞれが取得した前記処理結果を解析し、前記処理結果が処理失敗を表す場合、前記処理結果と、前記処理結果を得るために行った処理要求と、当該処理要求の送信元を示す送信元情報と、当該処理要求の送信先を示す送信先情報と、を対応付けたエラー情報をエラー記憶部に記憶する処理結果解析部を更に備え、
    前記監視システムは、
    前記アクセス処理識別情報に対応付けられた１以上のエラー情報を前記エラー記憶部から検索する検索部を更に備え、
    前記出力部は、検索された前記１以上のエラー情報に基づく出力を更に行うシステム。
14. サービスの享受に必要な１以上のアクセス処理の順序及び当該１以上のアクセス処理それぞれで用いられるアクセス情報を定義したアクセスデータに基づいて、当該サービスを提供するサービス提供システムにアクセスし、前記１以上のアクセス処理それぞれのアクセス結果を取得するアクセスステップと、
    前記１以上のアクセス結果を解析し、前記１以上のアクセス処理それぞれのアクセス結果情報を生成する解析ステップと、
    前記１以上のアクセス結果情報に基づいて、前記サービスの提供の可否に関するレポートを作成する作成ステップと、
    前記レポートを出力する出力ステップと、
    を含む監視方法。

Images