JP4271612B2

JP4271612B2 - 障害検出システム及び方法

Info

Publication number: JP4271612B2
Application number: JP2004106237A
Authority: JP
Inventors: 一樹松井; 昌朋矢崎; 政志宇山
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-03-31
Filing date: 2004-03-31
Publication date: 2009-06-03
Anticipated expiration: 2024-03-31
Also published as: JP2005293140A

Description

企業内システム等において管理されたネットワークに接続された多数のコンピュータおよびアプリケーションについて、システム障害が発生した場合の検出技術に関する。

例えば、特許文献１には、ネットワーク障害対策管理システムが記載されている。このシステムは、ネットワークに障害が生じたとき、自動的に障害ログＤＢ１０４が生成される。記憶されている障害ログＤＢ１０４のいずれかが選択されると、システムは選択された障害ログＤＢ１０４についてトラブルチケットを発行する。管理システムの管理人は、障害の解決方法などの障害関連情報をトラブルチケットに自由に記入する。情報が記録されたトラブルチケットは記憶される。検索項目をキーとしてトラブルチケットを検索することにより、新たな障害が生じたときに過去の障害履歴に基づいて解決方法を得ることができると言う効果を奏する。

別の例として、特許文献２には、ワークフロー実行方法が開示されている。この方法では、プログラムが呼ばれた時点でビジネスフローID(シナリオID)を含むトラブルチケットを発行し、プログラム実行前の情報(データオブジェクト)を収集し、プログラム実行中に障害を検出した場合、シナリオIDとともに保存する。この方法は、障害発生時のワークフローの再実行を容易にする効果を奏する。つまり、ワークフロー実行時に障害が発生した場合に、実行が完了しなかったプログラムについて、事前に保存されたデータオブジェクト等を再利用することで効率的に再実行することを可能とする。
特開平6-326751号公報特開2001-356946号公報

システム管理において、ハードウエアやアプリケーションの障害の原因追及には手間と時間がかかる。また、原因追及の上で人為的なミスがどうしても発生し、それが原因追及に要する手間と時間とに一層の拍車をかけているという現状がある。その一方で、ハードウエアやアプリケーションの障害が企業活動に与えるインパクトを即座に把握したいというニーズがある。例えば、あるサーバまたはあるアプリケーションに障害がおきたとき、どの顧客のどの取引に影響があるか等を即座に把握したいというニーズがある。しかし、既存のシステムやアプリケーションを全て置き換えてこれを実現するのはコストがかかるし、現実的ではない。よって、既存のリソースを有効に活用しつつ、少ないコストでビジネスインパクト分析のような高度な判断ができるような仕組みを作ることが求められている。

しかし、従来から提案されているシステム障害検出技術には、次のような課題がある。例えば、前記特許文献１では、システム管理者が障害の解決方法などをトラブルチケットに書き込んでいる。しかし、書き込まれる障害の解決方法を追求するのは結局システム管理者の手間暇をかけて行わざるを得ない。そのための手間や、障害の原因追及の過程で生じる人為的なミスを防止することは難しい。

また例えば前記特許文献２は、顧客に関する情報をデータオブジェクトに書き込むための仕組みがない。そのため、システム障害が生じたときに、その障害が企業活動上どのように影響するのかを知ることが難しい。

本発明は、企業内業務処理システムや企業間取引システムにおいて障害が発生したときに、その原因追及の手間や時間を軽減する技術を提供することを目的とする。

さらに本発明は、企業内システムや企業間を連携するシステムにおいて障害が発生したときに、その障害が企業活動に及ぼす影響を把握する技術を提供することを目的とする。

前記課題を解決するために、発明１は、アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムを提供する。このシステムは、中継装置とリソース管理装置とを備える。中継装置は以下の手段を有する。
・前記ユーザ端末と前記コンピュータ端末とに接続され、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行手段、
・前記チケット発行手段が発行したチケットを記憶するチケット記憶手段。

前記リソース管理装置は、以下の手段を有する。
・前記アプリケーションの正常応答を前記コンピュータ端末から受信すると前記チケット記憶手段に記憶されているチケットを削除するチケット管理手段、
・少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶手段に記憶されている全てのチケットを回収する回収手段、
・前記エラーログの識別子と前記回収したチケットの識別子とを対応付けて記憶する障害記憶手段。

エラーログとチケットとを対応付けることにより、ユーザと生じたエラーとの対応付が容易になる。従って、異なるコンピュータ端末上でそれぞれ動作するアプリケーションが連携して処理を行うような場合でも、エラーの追跡が容易となる。

ここで、チケットの回収とは、必ずしもチケットキューからのチケットの削除だけを意味しない。例えば、チケットキューに蓄積されているチケットに未回収／回収済のフラグをたてることによる回収も含む。また、一旦チケットキューからチケットを削除した後に、場合に応じてチケットキューに再度チケットを戻すような回収方法も含む。

なお、リクエストされた処理が正常に完了した場合、中継装置は正常応答をアプリケーションから受信し、リクエスト元のユーザ端末に転送してチケットを削除する。

正常に処理を終了した場合にはチケットキューからチケットを削除することにより、エラーが生じたリクエストのチケットのみがチケットキューに残る。従って、チケットキューからのチケットの回収が容易になる。

発明２は、発明１において、前記アプリケーションの実行状態ログのうち前記回収手段が検出すべきレベルを定義する監視レベル情報を記憶する監視レベル情報記憶手段をさらに備える障害検出システムを提供する。ここで、リソース管理装置は、前記監視レベル情報を参照して前記チケットを回収するか否かを判断し、前記判断結果に基づいて前記チケットを回収する。

監視レベル情報は、例えばエラーログ出力時、警告ログ出力時、レスポンスタイム悪化時など、チケットの回収のタイミングを規定する。これにより、適切なタイミングでチケットを回収できるので、発生した障害への対処のタイミングを適切化することができる。

発明３は、発明１において、前記リソース管理装置が回収したチケットに記述されたユーザ識別子に基づいて、前記エラーに関連するユーザ端末を特定し、特定したユーザ端末の識別子を出力する障害通知手段を更に備える障害検出システムを提供する。

障害検出システムの管理者は、障害通知手段により、発生したエラーにより業務上の影響を受けるユーザ端末をすぐに知ることができる。従って、そのユーザ端末の所有者にお詫びするなどの措置を、迅速に取ることができる。

発明４は、アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムが実行する障害検出方法を提供する。この方法は、以下のステップを含む。
・前記ユーザ端末と前記コンピュータ端末とに接続し、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行ステップ、
・前記チケット発行ステップで発行したチケットを記憶するチケット記憶ステップ、
・前記アプリケーションの正常応答を前記コンピュータ端末から受信すると前記チケット記憶ステップで記憶されたチケットを記憶手段から削除するチケット管理ステップ、
・少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶ステップで記憶された全てのチケットを回収する回収ステップ、
・前記エラーログの識別子と前記回収したチケットの識別子とを対応付けて記憶する障害記憶ステップ。

この方法は、前記発明１と同様の作用効果を奏する。

また、中継装置、リソース管理装置及び障害通知手段としてコンピュータを機能させるプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体も本発明に含まれる。ここで、記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。またプログラムには、記録媒体に記憶されているものもダウンロード可能なものが含まれる。

本発明を用いれば、企業内システムや企業間を連携するシステムにおいて障害が発生したときに、その原因追及の手間や時間が軽減される。また、発生した障害が企業活動に及ぼす影響を容易に把握することができる。

＜第１実施形態＞
［概要］
図１は、本発明の第１実施形態に係る障害検出システムの構成図である。障害検出システム１００は、ネットワーク２００を介し、ユーザ端末３００、第１〜第Ｎアプリケーションがそれぞれ動作するコンピュータ４００、各アプリケーションの実行状態を示すログを保存する実行状態ログＤＢ５００と接続されている。第１〜第Ｎアプリケーションは、企業内の業務処理や企業間での取引を実行するために必要となるアプリケーションである。ユーザ端末３００は、企業内の業務処理や企業間取引のリクエストを出し、その応答を受け取る端末であり、通常は企業内に設置されている。

障害検出システム１００は、Wrapper１０１、リソースマネージャ１０２、障害通知装置１０３、障害ログＤＢ１０４、アプリ構成ＤＢ１０５、監視レベル情報ＤＢ１０６及びビジネスプロセス構成ＤＢ１０７を含んでいる。障害検出システム１００の各構成要素は、それぞれ別々のコンピュータ端末上にあってそれらがネットワーク２００により接続されていてもよい。また、各構成要素の全部またはその一部が同じコンピュータ端末上にあってもよい。障害検出システム１００は、企業内の業務処理に必要な各手順を実行するアプリケーションに発生する障害や、企業間取引（以下、ビジネスプロセスという）に必要な各手順を実行するアプリケーションに発生する障害を検出する。

図２、図３は、障害検出システム１００の動作イメージを示す概念説明図である。図２は、障害が起こらない場合、つまり正常時の動作を示す。ユーザ端末３００から業務処理が請求されると、Wrapper１０１はユーザＩＤ付チケットを発行して一時的に記憶する。業務処理とは、１以上のアプリケーションが連携して実行する仕事である。業務処理の一例としては、発注業務処理、受注業務処理、在庫引当業務処理を挙げることができる。さらにWrapper１０１は、リクエストを第１アプリケーションに転送する。リクエストは、業務処理の実行に必要なアプリケーションに次々に順次され、各アプリケーションが起動される。各アプリケーションは、処理を正常に完了すると、転送元に応答を返す。Wrapper１０１には第１アプリケーションから正常応答が返される。正常応答を受信したWrapper１０１は、発行チケットを削除し、ユーザ端末３００に正常応答を転送する。

図３は、障害が起こった場合、つまり異常時における障害検出システム１００の動作イメージを示す概念説明図である。チケットの発行及び各アプリケーションの起動は図２と同様である。いずれかのアプリケーションの動作にエラーが発生すると、そのアプリケーションはエラーログを実行状態ログＤＢ５００に書き込む。リソースマネージャ１０２は、エラーログの書き込みを検出し、発行されている全チケットとエラーログとを対応付けて障害ログＤＢ１０４に書き込む。

障害通知装置１０３は、障害ログＤＢ１０４への書き込みを検出し、エラーログに書かれているエラーの内容とユーザＩＤとを、障害検出システム１００の管理者に通知する。これにより、どのユーザがどのようなエラーにより業務上の影響を受けるのかを迅速に把握することができる。

［構成］
次に、障害検出システム１００の構成について、さらに詳細に説明する。

（１）Wrapper
図４は、Wrapper１０１の機能構成を示すブロック図である。Wrapper１０１は、ユーザ端末３００からのリクエストに応じてユーザＩＤ付チケットを発行し、アプリケーションからの正常応答に応じて発行したチケットを削除する。図１ではWrapper１０１を１つしか示していないが、実際は各業務毎にWrapper１０１が起動する。例えば発注業務処理用Wrapper１０１、受注業務処理用Wrapper１０１、在庫引当業務処理用Wrapper１０１はそれぞれ独立に起動し、独立に動作する。Wrapper１０１により発行されたチケットは正常に業務処理が行われた後は削除されるので、削除されずに残ったチケットは異常事態の発生を示していることになる。Wrapper１０１は、下記の機能を有している。

チケット管理テーブル１０１１：後述するチケット管理部１０１３が発行するチケットを一時的に記憶する。１つのWrapper１０１が複数のユーザ端末からのリクエストを受け付けている場合、リクエストの数だけチケットが発行される。以下の説明において、１つのWrapperのチケット管理テーブル１０１１に蓄積されているチケットのことを、「チケットキュー」と言うことがある。チケットキューは１つのWrapper１０１に１つ形成される。各Wrapperのチケットキューは、キューＩＤで識別される。

セッション管理部１０１２：ユーザ端末３００とアプリケーションとの間の通信を中継する。例えば、ユーザ端末３００から業務処理のリクエストを受信すると、その業務処理を行う上で最初に起動すべきアプリケーション（以下、第１アプリケーションという）にそのリクエストを転送する。また、第１アプリケーションからの応答を、ユーザ端末３００に転送する。

チケット管理部１０１３：ユーザ端末３００からのリクエストに応じてユーザＩＤ付チケットを発行し、チケット管理テーブル１０１１に格納する。また、アプリケーションからの正常応答に応じ、チケット管理テーブル１０１１から全チケットを削除する。言い換えれば、アプリケーションから正常応答が返ってこない限り、発行されたチケットはチケット管理テーブル１０１１に残ったままになる。例えばアプリケーションがエラー応答を返したり、エラー発生によりWrapper１０１に応答を返さなかった場合である。

図５は、Wrapper１０１が発行するチケットの概念説明図である。チケットには、チケットを識別するチケットＩＤ、Wrapper１０１を識別するWrapperＩＤ、リクエスト元のユーザ端末３００を識別するユーザＩＤが含まれる。ユーザＩＤとしては例えばユーザ端末３００のネットワークアドレスを用いることができる。この例では、その他に構成ＩＤ及びフローＩＤをさらに含んでいる。構成ＩＤとは、企業内の業務処理を構成するアプリケーションの構成を特定する識別子である。構成ＩＤで特定されるアプリケーション構成の内容は、アプリ構成ＤＢ１０５に記憶されている。フローＩＤとは、ビジネスプロセスの実行に必要な各手順を特定する識別子である。フローＩＤで特定される手順の内容は、ビジネスプロセス構成ＤＢ１０７に記憶されている。

図６は、アプリ構成ＤＢ１０５に記憶されているアプリケーション構成情報の概念説明図である。構成ＩＤ“１”は、Ｗｅｂサーバ、受注システム、データベースの３つのアプリケーションにより業務処理が構成されることを示す。同様に、構成ＩＤ“２”は、Ｗｅｂサーバ、在庫引当システム、データベースの３つのアプリケーションにより業務処理が構成されることを示す。従って、アプリケーション構成情報は、複数のアプリケーションの接続状態を示しているとも言える。

図７は、ビジネスプロセス構成ＤＢ１０７に記憶されているビジネスプロセス構成情報の概念説明図である。フローＩＤ“１”は、ある企業間取引に必要な一手順が受注システムによる処理であり、パラメータとして（１００，２００）を渡して受注システムを起動することが記述されている。

なお、Wrapper１０１は、起動したときに、いずれかの構成ＩＤ及びフローＩＤや第１アプリケーションのアドレスなどの情報を読み込んでいる。例えば、発注業務処理用Wrapper１０１であれば、発注業務に必要なアプリケーション構成を特定する構成ＩＤ、その発注業務が行われる段階を特定するフローＩＤ、ユーザ端末３００からのリクエストを転送する第１アプリケーションのアドレスなどを、起動時に読み込んでいる。これら読み込んだ情報に基づいて、Wrapper１０１はチケットへの構成ＩＤ及びフローＩＤの書き込みやリクエストの転送を行う。

（２）リソースマネージャ
図８は、リソースマネージャ１０２の機能構成を示すブロック図である。リソースマネージャ１０２は、実行状態ログＤＢ５００へのエラーログの書き込み発生を監視し、エラーログが書き込まれると、発生したエラーログとチケット管理テーブル１０１１内の全チケットとを対応付けて障害ログＤＢ１０４に書き込む。各チケットにはユーザＩＤが記述されているので、エラーログとチケットとを対応付けることにより、発生したエラーにより影響を受けるユーザとエラーとを関連づけることができる。Wrapper１０１が複数起動しているとき、リソースマネージャ１０２は起動しているWrapper１０１全てからチケットを回収する。また、リソースマネージャ１０２は、エラーログだけでなく、エラーが発生する前に出力される警告ログや、アプリケーションの応答が悪化した状態を示すログなどを、チケットと対応付けることもできる。リソースマネージャ１０２は以下の機能を有している。

ＩＯ処理部１０２１：ネットワーク２００を介し、Wrapper１０１からチケットキューを回収したり、実行状態ログＤＢ５００から新たに発生したログを回収したりする。ここで、回収とは、チケット管理テーブル１０１１のチケットやログが削除される場合、元のチケットやログは残りそのコピーを取得する場合のどちらもがあり得る。コピーを取得する場合、元のチケットには回収済フラグをたてておいてもよい。

チケット回収部１０２２：ＩＯ処理部１０２１から受け取ったチケットキューのキューＩＤとチケットキューのアドレスを、チケットキュー所在管理テーブル１０２３に格納する。チケットキューのアドレスは、Wrapper１０１内のチケットキューの格納場所を示す。

チケットキュー所在管理テーブル１０２３：キューＩＤとチケットキューのアドレスとを記憶する。

ログ取得部１０２４：ＩＯ処理部１０２１から受け取ったログの識別子（以下、ログＩＤという）とログのアドレスとを、ログファイル所在管理テーブル１０２５に格納する。ログのアドレスは、実行状態ログＤＢ５００内のログの格納場所を示す。

ログファイル所在管理テーブル１０２５：ログのログＩＤとログのアドレスとを記憶する。

チケット回収条件判断部１０２６：監視レベル情報を参照し、障害ログＤＢ１０４への書き込みタイミングを決定する。

障害ログＤＢ１０４保存部１０２７：障害ログＤＢ１０４へのログＩＤ、キューＩＤ、ログのアドレス及びチケットキューのアドレスの書き込みを行う。書き込まれるログとチケットキューとは１対１に対応するとは限らない。障害ログＤＢ１０４は、データの格納及び検索が可能であれば、いかなる形態でもよい。

図９は、チケットキュー所在管理テーブル１０２３の概念説明図である。この例では、チケットキュー所在管理テーブル１０２３には、チケットキューのキューＩＤとチケットキューのアドレスであるＵＲＬとが対応付けられて蓄積されている。

図１０は、ログファイル所在管理テーブルの概念説明図である。この例では、ログファイル所在管理テーブルには、ログＩＤとログのアドレスであるＵＲＬとが対応付けられて蓄積されている。

図１１は、監視レベル情報ＤＢ１０６に記憶される監視レベル情報の概念説明図である。監視レベル情報は、例えばユーザである企業毎に設定されている。監視レベル情報は、エラーログ発生時だけでなく、それ以外の時にもチケットキュー及びアプリケーションの実行状態ログを障害ログＤＢ１０４に回収するかどうかを定義する。言い換えれば、監視レベル情報は、アプリケーションの実行状態ログのうちリソースマネージャ１０２が検出すべきレベルを定義する。この例では、警告ログ発生時及びレスポンス悪化時に回収を行うことが定義されている。従って、チケット回収条件判断部１０２６は、発生したログがエラーログまたは警告ログであれば、回収したチケットキューとログとを障害ログＤＢ１０４に書き込むと判断する。また、チケット回収条件判断部１０２６は、あるアプリケーションのレスポンスが悪化していると判断すれば、そのアプリケーションの実行状態ログとチケットキューとを障害ログＤＢ１０４に書き込むと判断する。すなわち、監視レベル情報を用いることにより、エラー発生前の段階でエラーに直結しそうな危険な状態を検出することができる。

ここで警告ログとは、エラー発生前の段階でアプリケーションが出力するログである。レスポンス悪化時とは、第ｊアプリケーションが第（ｊ＋１）アプリケーションを起動してから第（ｊ＋１）アプリケーションの応答までの時間が他のアプリケーションの応答時間よりも長い場合などである。レスポンスの悪化は、実行状態ログＤＢ５００に書き込まれる各アプリケーションの実行状態ログをリソースマネージャ１０２が監視することで判別可能である。実行状態ログには時刻情報が含まれているのが通例だからである。

（３）障害通知装置
図１２は、障害通知装置１０３の機能構成を示すブロック図である。障害通知装置１０３は、障害ログＤＢ１０４への書き込み発生を検出し、書き込まれたチケットとログとからどのユーザが使用中のアプリケーションがどのようなエラーを発生させたのかを、障害検出システム１００の管理者に通知する。管理者は、この通知に基づいて、エラーの影響を受けるまたは受けそうなユーザに対し、迅速な対応を取ることができる。障害通知装置１０３は、下記の機能を有している。

アラートルール記述ファイル１０３１：エラーの内容やエラーの影響を受けるユーザの通知先を決定するためのアラートルールを定義する。図１３は、アラートルールの一例を示す。この例では、あるユーザが使用中のアプリケーションにエラーが発生した場合は通知先を障害検出システムの管理者のチーフマネージャとし、それ以外のユーザの場合は管理者のオペレータを通知先とするアラートルールを示す。アラートルールを用いることにより、例えば重要顧客がエラーの影響を受ける場合には責任者に通知子、迅速な対応を取ることができる。

アラート生成部１０３２：アラートルール記述ファイル１０３１、ログの内容、チケットキューに含まれるチケットとを参照し、エラーの内容及びユーザＩＤの通知先を決定する。ここで、ログの内容及びチケットの内容は、ログのアドレス及びチケットキューのアドレスにアクセスすることにより、取得する。

通知出力部１０３３：エラー発生とユーザＩＤとを通知する画面を、障害通知装置１０３に接続されるディスプレイ（図示せず）に出力する。また、例えば電子メールクライアントを用いて通知出力部１０３３を構成し、通知を他のコンピュータ端末に送信することもできる。

［処理］
図１４は、本実施形態例に係る障害通知システムが実行する処理の流れの一例を示す説明図である。この処理は、大別して（１）チケットの発行と、（２）障害ログＤＢ１０４への保存と、（３）エラーの通知出力とに分けられる。

（１）チケットの発行
まず、ユーザ端末３００がWrapper１０１に対し、業務処理の実行を要求するリクエストを送信する（＃１）。このリクエストには、ユーザ端末３００のアドレスなどのユーザＩＤが含まれている。

リクエストを受信したWrapper１０１は、リクエストされた業務処理に対してユーザＩＤ付チケットを発行し、チケット管理テーブル１０１１にチケットを格納する（＃２，＃３）。さらにWrapper１０１は、受信したリクエストを第１アプリケーションが動作しているコンピュータ４００に転送する（＃４）。

コンピュータ４００の第ｊアプリケーション（１≦ｊ≦Ｎ）は、次々にリクエストを受信し、アプリケーション毎の処理を開始する（＃５，＃６）。各アプリケーションは、処理の実行中に、実行状態を示すログを実行状態ログＤＢ５００に出力する。例えば処理を完了するまでにエラーが発生した場合（＃７，＃８）、第ｊアプリケーションはエラーログを実行状態ログＤＢ５００に出力する（＃９）。エラーが発生することなく処理を完了したら、第ｊアプリケーションは正常応答をリクエスト元に送信する（＃１０）。ここで、リクエスト元とは、Wrapper１０１または第ｊアプリケーションを呼ぶ第（ｊ−１）アプリケーションである。

Wrapper１０１は、正常応答を第１アプリケーションから受信すると（＃１１）、チケット管理テーブル１０１１に残っている全チケットを削除し（＃１２）、正常応答をリクエスト元ユーザ端末３００に転送する（＃１４）。言い換えれば、Wrapper１０１は、正常応答を第１アプリケーションから受信するまで、チケット管理テーブルのチケットを削除しない。従って、チケット管理テーブル内に残存するチケットは、そのWrapper１０１に対応する業務処理の実行中に何らかの異常が発生したことを示す。

（２）障害ログＤＢ１０４への保存
リソースマネージャ１０２は、起動すると、監視レベル情報ＤＢ１０６から監視レベル情報を読み込んでおく（＃２０）。リソースマネージャ１０２は、実行状態ログＤＢ５００への書き込みを監視し、新たなログが書き込まれると監視レベル情報に基づいて障害ログＤＢ１０４への書き込みを行うか否かを判断する（＃２１，＃２２）。例えば、発生したログが警告ログであり、監視レベル情報に「エラーログ、警告ログまたはレスポンスの悪化時」と定義されていれば、書き込むと判断する。書き込む場合は、発生したログと、起動しているWrapper１０１にあるチケットキューとを回収し、障害ログＤＢ１０４に保存する（＃２３，＃２４）。

（３）エラーの通知出力
障害通知装置１０３は、例えば起動時に、アプリ構成ＤＢ１０５及びビジネスプロセス構成ＤＢ１０７から、それぞれアプリケーション構成とビジネスプロセス構成とを読み込んでおく（＃２５，＃２６）。その後、障害通知装置１０３は、障害ログＤＢ１０４への書き込みを監視し（＃２７）、障害ログＤＢ１０４への書き込みが発生すると、新たに障害ログＤＢ１０４に書き込まれたチケットに基づいてユーザＩＤを特定する（＃２８）。また、障害通知装置１０３は、構成ＩＤ及びフローＩＤを特定しても良い。エラーを起こしたアプリケーションが構成ＩＤで特定されるアプリケーション構成に含まれていない場合、障害通知装置１０３は障害通知を行わなわず、回収したチケットを元に戻すと良い。

さらに、障害通知装置１０３は、記憶しているアラートルールを参照し、障害通知の通知先を決定する（＃２９）。例えば、重要顧客が関連しているエラーが発生した場合には、障害通知の通知先を図示しないマネージャ端末に決定する。その後、障害通知装置１０３は、決定した通知先に障害発生通知を送信する（＃３０）。この通知には、少なくともユーザＩＤを含み、さらに構成ＩＤに対応するアプリケーション構成や、フローＩＤに対応するビジネスプロセス構成を含んでいてもよい。

［画面例］
図１５は、前述の処理により、障害通知装置１０３が出力する障害通知画面例である。この例では、ユーザＩＤ、エラーが生じた処理のアプリケーション構成及びビジネスプロセスが示されている。すなわち、在庫引き当てアプリケーションがデータベース（ＤＢ）に書き込みを行おうとしたときにエラーが発生したこと、その日時が示されている。

［効果］
以上のように、本発明の障害検出システムを用いれば、企業内の業務処理システムやビジネスプロセスシステムにおいて障害が発生したときに、その障害により影響を受ける企業を自動的に特定する。また、どの企業がどのような障害の影響を受けたかを、自動的に特定する。さらに、どのような業務処理システムまたはビジネスプロセスシステムにおいて障害が発生したのか、また発生した障害はそのシステムを構築するどの部分またはどの段階なのかを、自動的に特定する。エラーの発生前に、エラーに直結しそうな事態を検知して障害検出システムの管理者に通知することもできる。その結果、障害の原因の追及の手間や時間を軽減することができる。また、発生した障害が企業活動に及ぼす影響を容易に把握し、障害の発生に迅速に対応することができる。

＜その他の実施形態＞
上記の方法を実行するためのプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。またプログラムには、記録媒体に記憶されているものもダウンロード可能なものが含まれる。

［実施例１］
図１６は、本発明の実施例１の説明図である。本実施例では、ASP事業者が、受注や在庫引当などの業務アプリケーション４００１，４００２を、複数の顧客企業にネットワーク２００経由で提供する場合を想定する。ASP事業者側では、受注アプリケーション４００１と在庫引当アプリケーション４００２とがデータベースシステムを共有している。ユーザ端末３００１は受注アプリケーション４００１を使用し、ユーザ端末３００２は在庫引当アプリケーション４００２を使用している。

ユーザ端末３００１が受注の業務アプリケーションの処理を開始すると、Ｗｒａｐｐｅｒ１０１−１は、ユーザ端末３００１のユーザＩＤ付チケットを発行し、チケットキュー１０１１（チケット管理テーブル１０１１に相当）に登録する。また、ユーザ端末３００２が在庫引当のアプリケーションの処理を開始すると、Ｗｒａｐｐｅｒ１０１−２は、ユーザ端末３００２のユーザＩＤ付チケットを発行し、チケットキュー１０１１に登録する。各業務アプリケーション４００の処理が実行され、このうち在庫引当アプリケーション４００２がデータベースに書き込もうとして、Disk Fullにより書込失敗のエラーが発生したとする。すると、実行状態ログＤＢ１０５が記録され、リソースマネージャ１０２がそれを検出し、チケットキュー１０１１に残っているチケットとエラーログとをセットで障害ログＤＢ１０４に保存する。

その後、図示しない障害通知装置は、チケットのユーザＩＤ、構成ＩＤ、フローＩＤを取得し、構成ＩＤに基づいてアプリ構成ＤＢ１０５を、フローＩＤに基づいてビジネスプロセス構成ＤＢ１０７を参照する。さらに、障害通知装置は、「ユーザ端末３００２が使用中の在庫引当アプリケーションが書き込みエラーを起こした」と言う状態を把握し、たとえばユーザ端末３００２に対し、アラートを通知する。各アラートは、ユーザ端末３００に直接通知してもよいし、あるいは障害検出システムのオペレータにEメール等で通知してもよい。

［実施例２］
図１７は、本発明の実施例２の説明図である。本実施例では、実施例１と同様、ASP事業者が、受注や在庫引当などの業務アプリケーションを、複数の顧客企業にネットワーク経由で提供する場合を想定する。ユーザ端末３００１は受注アプリケーションを使用し、ユーザ端末３００２は在庫引当アプリケーションを使用している。チケットキューには、ユーザ端末３００１及びユーザ端末３００２のリクエストが蓄積されている。

このとき、回収したチケットからユーザＩＤ、構成ＩＤ、フローＩＤを取得し、構成ＩＤに基づいてアプリ構成ＤＢ１０５を参照することにより、図示しない障害通知装置が、障害の影響を受けたユーザ端末３００１と、これから影響を受ける可能性があるユーザ端末３００２とにアラートを通知する。既にデータベースに障害が発生しており、そのデータベースを共有しているアプリケーションを使用中の他ユーザ端末３００は、障害の影響を受ける可能性が高いからである。ここで、各アラートは、ユーザ端末３００に直接通知してもよいし、あるいは障害検出システムのオペレータにEメール等で通知してもよい。

［実施例３］
図１８は、本発明の実施例３の説明図である。本実施例では、チケットの回収のタイミングを決定するにあたって、監視レベル情報を使用する。

本実施例では、実施例１と同様、ASP事業者が、受注や在庫引当などの業務アプリケーションを、複数の顧客企業にネットワーク経由で提供する場合を想定する。ユーザ端末３００１は受注アプリケーションを使用し、ユーザ端末３００２は在庫引当アプリケーションを使用している。チケットキューには、ユーザ端末３００１及びユーザ端末３００２のリクエストが蓄積されている。

ユーザ端末３００１が受注の業務アプリケーションの処理を開始すると、Ｗｒａｐｐｅｒ１０１−１は、ユーザ端末３００１のユーザＩＤ付チケットを発行し、チケットキュー１０１１（チケット管理テーブル１０１１に相当）に登録する。また、ユーザ端末３００２が在庫引当のアプリケーションの処理を開始すると、Ｗｒａｐｐｅｒ１０１−２は、ユーザ端末３００２のユーザＩＤ付チケットを発行し、チケットキュー１０１１に登録する。各業務アプリケーション４００の処理が実行され、このうち在庫引当アプリケーション４００２がデータベースに書き込もうとして、データベースのレスポンスが悪化したとする。すると、実行状態ログＤＢ１０５にレスポンスの悪化ログとログ処理時刻とが記録される。

リソースマネージャ１０２は、監視レベル情報ＤＢ１０６を参照して監視レベル情報を取り込み、各アプリケーションが出力するログとログ処理時刻とを常時監視して、監視レベル情報で指定された条件に合致するかを計算する。その条件を満たした場合に、チケットキュー１０１１に保存されているチケットをログ情報と組み合わせて障害ログＤＢ１０４に保存する。監視レベル情報に記載される回収タイミング情報としては、エラーログ出力時、警告ログ出力時、レスポンスタイム悪化時といった回収タイミングが想定できる。

このとき、回収したチケットからユーザＩＤ、構成ＩＤ、フローＩＤを取得し、構成ＩＤに基づいてアプリ構成ＤＢ１０５を参照することにより、図示しない障害通知装置が、障害の影響を受けたユーザ端末３００２と、これから影響を受ける可能性があるユーザ端末３００１とにアラートを通知する。既にデータベースに障害が発生しており、そのデータベースを共有しているアプリケーションを使用中の他ユーザ端末は、障害の影響を受ける可能性が高いからである。ここで、各アラートは、ユーザ端末３００に直接通知してもよいし、あるいは障害検出システムのオペレータにEメール等で通知してもよい。

＜付記＞
（付記１）
アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムであって、
中継装置とリソース管理装置とを備え、
前記中継装置は、
前記ユーザ端末と前記コンピュータ端末とに接続され、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行手段と、
前記チケット発行手段が発行したチケットを記憶するチケット記憶手段と、を有し、
前記リソース管理装置は、
少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶手段に記憶されているチケットを回収する回収手段と、
前記エラーログの識別子と前記チケットの識別子とを対応付けて記憶する障害記憶手段と、を有している障害検出システム。

（付記２）
前記中継装置は、前記チケット記憶手段に記憶されているチケットを削除するチケット管理手段をさらに備える、付記１に記載の障害検出システム。

（付記３）
前記アプリケーションの実行状態ログのうち前記回収手段が検出すべきレベルを定義する監視レベル情報を記憶する監視レベル情報記憶手段をさらに備え、
前記リソース管理装置は、前記監視レベル情報を参照して前記チケットを回収するか否かを判断し、前記判断結果に基づいて前記チケットを回収する、
付記１に記載の障害検出システム。

（付記４）
前記リソース管理装置が回収したチケットに記述されたユーザ識別子に基づいて、前記エラーに関連するユーザ端末を特定し、特定したユーザ端末の識別子を出力する障害通知手段を更に備える、付記１に記載の障害検出システム。

（付記５）
複数のアプリケーションの接続状態を示したアプリケーション構成情報を記憶しているアプリケーション構成記憶手段をさらに備え、
前記障害通知手段は、前記アプリケーション構成記憶手段に記憶されたアプリケーション構成情報と前記リソース管理装置が回収したチケットの記述とに基づいて、前記ユーザ端末が使用しているアプリケーションを特定し、特定したアプリケーションの識別子をさらに出力し、
前記チケット発行手段は、前記アプリケーション構成情報への参照情報を前記チケットに書き込む、
付記４に記載の障害検出装置。

アプリケーション構成情報は、１つの処理を実行する上で必要なアプリケーションの組み合わせを定義する。アプリケーション構成は、例えば構成ＩＤにより識別される。チケットに構成ＩＤを書き込み、回収したチケットに書き込まれた構成ＩＤに対応するアプリケーション構成を読み出すことにより、あるエラーに関連するアプリケーションが簡単に把握できるようになる。言い換えれば、エラーの影響を受けるユーザ端末が使用しているアプリケーションを簡単に把握することができる。

（付記６）
複数のアプリケーションからなる処理の各ステップを定義するビジネスプロセス構成情報を記憶しているビジネスプロセス構成記憶手段をさらに備え、
前記障害通知手段は、前記ビジネスプロセス構成記憶手段に記憶されたビジネスプロセス構成情報と前記リソース管理装置が回収したチケットの記述とに基づいて、前記エラーが発生した時点を特定し、特定した時点をさらに出力し、
前記チケット発行手段は、前記ビジネスプロセス構成情報への参照情報をチケットに書き込む、
付記４に記載の障害検出装置。

ビジネスプロセス構成情報は、１つの処理を実行するアプリケーションの順序を定義する。ビジネスプロセス構成は、例えばフローＩＤにより識別される。チケットにフローＩＤを書き込み、回収したチケットに書き込まれたフローＩＤに対応するビジネスプロセス構成を読み出すことにより、１つの処理を行うための複数段階のうちどの段階でエラーが起こったのかを簡単に把握することができる。

（付記７）
前記障害通知装置は、電子メールクライアントが動作するコンピュータ端末と前記ネットワークを介して接続されており、
前記障害通知装置は、電子メールクライアントをさらに有し、前記エラーに関連するユーザ端末の識別子を前記電子メールクライアントにより前記コンピュータ端末に送信する、
付記４に記載の障害検出システム。

障害検出システムの管理ユーザが使用するコンピュータ端末と障害通知装置が動作するコンピュータ端末とが異なる場合でも、管理ユーザはエラーの発生及びそのエラーに関連する顧客を知ることができる。さらに、障害通知装置にアラートルール記憶手段を設け、通知先決定条件を記憶させることもできる。そうすれば、エラーの発生条件に応じてエラーの通知先を変えることができる。例えば、重要顧客に関連するアプリケーションがエラーを起こした場合は管理ユーザのマネージャ端末に通知し、それ以外のエラーはオペレータ端末に通知することが挙げられる。

（付記８）
アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムが実行する障害検出方法であって、
前記ユーザ端末と前記コンピュータ端末とに接続し、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行ステップと、
前記チケット発行ステップで発行したチケットを記憶するチケット記憶ステップと、
少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶ステップで記憶されたチケットを回収する回収ステップと、
前記エラーログの識別子と前記チケットの識別子とを対応付けて記憶する障害記憶ステップと、
を含む障害検出方法。

本発明は、企業内の業務システムや企業間の取引システムにおける障害の検出に適用可能である。

第１実施形態に係る障害検出システムの構成図障害検出システムの動作イメージを示す概念説明図（正常時）障害検出システムの動作イメージを示す概念説明図（異常時） Wrapperの機能構成を示すブロック図 Wrapperが発行するチケットの概念説明図アプリ構成ＤＢに記憶されているアプリケーション構成情報の概念説明図ビジネスプロセス構成ＤＢに記憶されているビジネスプロセス構成情報の概念説明図リソースマネージャの機能構成を示すブロック図チケットキュー所在管理テーブルの概念説明図ログファイル所在管理テーブルの概念説明図監視レベル情報ＤＢに記憶される監視レベル情報の概念説明図障害通知装置の機能構成を示すブロック図アラートルールの一例を示す説明図障害通知システムが実行する処理の流れの一例を示す説明図障害通知の画面例実施例１の説明図実施例２の説明図実施例３の説明図

符号の説明

１００：障害検出システム
２００：ネットワーク
３００：ユーザ端末
４００：アプリケーションが動作するコンピュータ
５００：実行状態ログＤＢ
１０１：Wrapper
１０２：リソースマネージャ
１０３：障害通知装置
１０４：障害ログＤＢ１０４
１０５：アプリ構成ＤＢ
１０６：監視レベル情報ＤＢ
１０７：ビジネスプロセス構成ＤＢ

Claims

アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムであって、
中継装置とリソース管理装置とを備え、
前記中継装置は、
前記ユーザ端末と前記コンピュータ端末とに接続され、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行手段と、
前記チケット発行手段が発行したチケットを記憶するチケット記憶手段と、を有し、
前記リソース管理装置は、
前記アプリケーションの正常応答を前記コンピュータ端末から受信すると前記チケット記憶手段に記憶されているチケットを削除するチケット管理手段と、
少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶手段に記憶されている全てのチケットを回収する回収手段と、
前記エラーログの識別子と前記回収したチケットの識別子とを対応付けて記憶する障害記憶手段と、を有している障害検出システム。
前記アプリケーションの実行状態ログのうち前記回収手段が検出すべきレベルを定義する監視レベル情報を記憶する監視レベル情報記憶手段をさらに備え、
前記リソース管理装置は、前記監視レベル情報を参照して前記チケットを回収するか否かを判断し、前記判断結果に基づいて前記チケットを回収する、
請求項１に記載の障害検出システム。
前記リソース管理装置が回収したチケットに記述されたユーザ識別子に基づいて、前記エラーに関連するユーザ端末を特定し、特定したユーザ端末の識別子を出力する障害通知手段を更に備える、請求項１に記載の障害検出システム。
アプリケーションが動作している１以上のコンピュータ端末と前記アプリケーションのユーザの端末とにネットワークを介して接続される障害検出システムが実行する障害検出方法であって、
前記ユーザ端末と前記コンピュータ端末とに接続し、前記ユーザ端末からいずれかのアプリケーションへのリクエストに応じて前記ユーザ端末を識別するユーザ識別子が記述されたチケットを発行するチケット発行ステップと、
前記チケット発行ステップで発行したチケットを記憶するチケット記憶ステップと、
前記アプリケーションの正常応答を前記コンピュータ端末から受信すると前記チケット記憶ステップで記憶されたチケットを記憶手段から削除するチケット管理ステップと、
少なくとも前記アプリケーションがエラー発生時に出力するエラーログを検出し、前記チケット記憶ステップで記憶された全てのチケットを回収する回収ステップと、
前記エラーログの識別子と前記回収したチケットの識別子とを対応付けて記憶する障害記憶ステップと、
を含む障害検出方法。