JP2007272328A - コンピュータ・システム - Google Patents

Abstract

【課題】コンピュータ間のトラフィック量の増大を抑制しつつ、アプリケーションに対する障害監視及びログ情報の収集・記憶を実現する。
【解決手段】アプリケーション・サーバ30上で動作し業務処理を行う業務処理モジュール及びウェブ・サーバ40上で動作し画面制御処理を行う画面制御モジュールは、自モジュールと同一のサーバ上で動作するログサービスモジュールへ定期的にハートビートを送信し、ログサービスモジュールはハートビートを受信する毎に、ログファイルにログ情報を書き出し、ハートビート送信元のモジュールへ応答を送信し、同一サーバ上で動作する監視モジュールへハートビート送信元モジュールの生存通知を送信する。監視モジュールは、生存通知の受信時間間隔に基づいて障害監視対象のモジュールの動作状態が正常か否か判定し、障害が発生したと判断した場合は監視用コンピュータ50へ通知する。
【選択図】図１

Description

本発明はコンピュータ・システムに係り、特に、アプリケーション・プログラムを実行することで所定の業務処理を行うアプリケーション手段として機能する業務処理用コンピュータを含んで構成されたコンピュータ・システムに関する。

コンピュータ・システムにおいて、障害の発生を監視し、障害が発生した場合に直ちに対処することで、障害発生の影響を最小限に止めることは非常に重要であり、この種の技術として、例えば特許文献１には、障害監視コンピュータを設置すると共に、障害監視コンピュータと監視センタ用コンピュータを、ネットワークを介して情報を送受可能とし、障害監視コンピュータがｐｉｎｇ応答確認により障害を検知した場合に監視センタ用コンピュータへ障害検知信号を送出することで、監視対象ネットワークにおける障害発生等を、遠隔の監視センタで迅速かつ的確に把握することを可能とする技術が提案されている。

また、特許文献２には、複数台のコンピュータが接続されたコンピュータネットワークにおいて、個々のコンピュータが機器の識別情報と機器の状態情報をパケットにしたデータを交換し、所定周期で受信しているパケットが連続して複数回未受信となった場合に障害発生と判断して通報する技術が開示されている。

また、コンピュータ・システムによっては、ＣＰＵやメモリ、ディスク等の利用時間等の稼働情報を収集・蓄積してコンピュータ・システムの稼働状況の把握・管理や課金等に利用することも行われており、例えば特許文献３には、分散サーバと運用サーバを有する分散処理システムにおいて、分散サーバにより稼働情報を収集し、稼働情報取得完了の分散サーバから運用サーバが稼働情報を順次収集する技術が開示されている。
特開２００１−２９８４２６号公報 特開２００１−７５８３７号公報 特開平９−２７４５９６号公報

コンピュータ・システムが特定のアプリケーション・プログラムを実行することで実現される特定の業務処理が、処理の実行に対して高い信頼性が要求される非常に重要な処理である場合には、特定のアプリケーション・プログラムの動作が滞ったときに直ちに検知可能で、かつ、特定のアプリケーション・プログラムの動作が滞ったときに、原因を解析して早期に復旧させるために、どの時点までは動作状態が正常であったかや、動作が滞る以前のアプリケーション・プログラムの動作状況等も把握可能なようにコンピュータ・システムが構成されていることが望ましい。

従来より、コンピュータの障害監視としては特許文献１，２に記載されているような技術が提案されており、動作状態を把握するためのログ情報の収集・記憶としては特許文献３に記載されているような技術が提案されている。しかしながら、上記のような技術を適用して特定のアプリケーション・プログラムの障害監視やログ情報の収集・記憶を行うためには、各コンピュータ間で障害監視のための通信やログ情報収集・記憶のための通信を行う必要があるので、コンピュータ・システムを構成する各コンピュータ間のトラフィックが増大するという問題がある。特に、コンピュータ・システムで行うべき特定の業務処理がコンピュータに大きな負荷が加わる処理である場合には、コンピュータに加わる負荷を分散させることを目的として、特定の業務処理を行う業務処理用コンピュータを複数台設けた構成が採用されるが、このような構成において、個々の業務処理用コンピュータで実行される特定のアプリケーション・プログラムの障害監視やログ情報の収集・記憶を行おうとすると、コンピュータ間のトラフィックは飛躍的に増大する。

また、コンピュータ間の通信では、通信回線の障害等によってコンピュータ間の情報の送受が一時的に途絶えた場合にも、各コンピュータの状態の不一致や各コンピュータが保持している情報の矛盾・欠落等が生じないように、第１のコンピュータが第２のコンピュータから情報を受信した場合、第１のコンピュータは第２のコンピュータへ応答を返すと共に、第２のコンピュータは第１のコンピュータから所定時間以上応答を受信しない場合に、情報の再送信を行う通信方式が採用されるが、上記のようにコンピュータ間のトラフィックが非常に多い場合、或るコンピュータに何らかの理由で発生した処理遅延等の障害が、当該コンピュータと通信を行っている他のコンピュータにも影響を与え易く、或るコンピュータで発生した処理遅延等の障害がコンピュータ・システム全体に波及してしまう事態が生ずる可能性が高くなるという問題もある。

本発明は上記事実を考慮して成されたもので、コンピュータ間のトラフィック量の増大を抑制しつつ、アプリケーションに対する障害監視及びログ情報の収集・記憶を実現できるコンピュータ・システムを得ることが目的である。

上記目的を達成するために請求項１記載の発明に係るコンピュータ・システムは、各々アプリケーション・プログラムを実行することで所定の業務処理を行うアプリケーション手段として各々機能する複数台の業務処理用コンピュータと、個々の業務処理用コンピュータと通信回線を介して各々接続された監視用コンピュータを含んで構成されたコンピュータ・システムであって、前記業務処理用コンピュータ上で動作し、同一の業務処理用コンピュータ上で動作するアプリケーション手段との間で定期的に通信を行い、当該通信によって判別した前記同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態を前記同一の業務処理用コンピュータに設けられた第２記憶手段にログ情報として記憶させると共に、前記定期的な通信が途絶えたことに基づいて前記同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態が異常と判断した場合に前記監視用コンピュータへ通知する監視手段が前記複数台の業務処理用コンピュータに各々設けられていることを特徴としている。

請求項１記載の発明に係るコンピュータ・システムは、各々アプリケーション・プログラムを実行することで所定の業務処理を行うアプリケーション手段として各々機能する複数台の業務処理用コンピュータと、個々の業務処理用コンピュータと通信回線を介して各々接続された監視用コンピュータを含んで構成されている。ここで、請求項１記載の発明では、複数台の業務処理用コンピュータに監視手段が各々設けられており、この監視手段は、同一の業務処理用コンピュータ上で動作するアプリケーション手段との間で定期的に通信を行い、当該通信によって判別した同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態を同一の業務処理用コンピュータに設けられた第２記憶手段にログ情報として記憶させると共に、前記定期的な通信が途絶えたことに基づいて同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態が異常と判断した場合に監視用コンピュータへ通知する。

このように、請求項１記載の発明では、個々の業務処理用コンピュータ上で動作するアプリケーション手段についてのログ情報の収集・記憶及び障害監視が、個々のアプリケーション手段と同一の業務処理用コンピュータ上で動作する監視手段によって各々行われるので、個々のアプリケーション手段についてのログ情報の収集・記憶及び障害監視が個々の業務処理用コンピュータ内で完結しており、個々のアプリケーション手段についてログ情報の収集・記憶及び障害監視を各々行うために、コンピュータ・システムを構成する個々のコンピュータの間で通信を行う必要がなくなる。また、本発明に係る監視手段は、同一の業務処理用コンピュータ上で動作するアプリケーション手段との間で定期的に通信を行って、アプリケーション手段の動作状態をログ情報として記憶させると共に、定期的な通信が途絶えたことに基づいて同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態が異常と判断する障害監視を行うので、ログ情報の収集・記憶のための通信と障害監視のための通信を別々に行う場合と比較して通信の回数を削減することができる。

従って、請求項１記載の発明によれば、コンピュータ間のトラフィック量の増大を抑制しつつ、アプリケーション（手段）の障害監視及びログ情報の収集・記憶を実現することができる。また前述のように、個々のアプリケーション手段についてのログ情報の収集・記憶及び障害監視が個々の業務処理用コンピュータ内で完結しているために、コンピュータ間のトラフィック量の増大が抑制されることでコンピュータ・システムの耐障害性を向上させることができる（一部のコンピュータで処理遅延等の障害が発生してもコンピュータ・システム全体に波及し難くなる）と共に、コンピュータ・システムに新たな業務処理用コンピュータを追加することも容易に行うことができ、コンピュータ・システムの拡張性も向上させることができる。

なお、請求項１記載の発明において、アプリケーション手段と監視手段との間の定期的な通信は、例えば監視手段がアプリケーション手段へ動作情報を問い合わせる所定の情報を定期的に送信し、アプリケーション手段は監視手段から所定の情報を受信する毎に応答を送信することで行ってもよいが、この場合、監視手段から所定の情報を受信したか否かを常時監視し、所定の情報を受信した場合には応答を送信する処理を、本来行うべき業務処理と並行して行うようにアプリケーション手段を構成する必要があるので、アプリケーション手段に負荷が加わり、アプリケーション手段が本来行うべき業務処理の遅延等が生ずる恐れがある。

これを考慮すると、請求項１記載の発明において、例えば請求項２に記載したように、アプリケーション手段は、所定の業務処理と並行して、同一の業務処理用コンピュータ上で動作する監視手段へ生存通知を送信する送信処理を定期的に行い、監視手段は、同一の業務処理用コンピュータ上で動作するアプリケーション手段より最後に生存通知を受信してからの経過時間が閾値以上の場合に、前記定期的な通信が途絶えたと判断し、アプリケーション手段の動作状態が異常と判断するように構成することが好ましい。

請求項２記載の発明では、アプリケーション手段が自発的（能動的）に生存通知を送信するので、例えば業務処理を一定単位行う毎に生存通知を送信する等、生存通知を送信する処理を行うことが大きな負荷とならないようにアプリケーション手段を構成することが可能となり、アプリケーション手段が本来行うべき業務処理の遅延等が生じることを抑制できる。また監視手段は、アプリケーション手段から生存通知を定期的に受信している間は、アプリケーション手段の動作状態は正常と判別できる一方で、アプリケーション手段より最後に生存通知を受信してからの経過時間が閾値以上の場合には、アプリケーション手段の動作状態が異常と判断することができ、アプリケーション手段の動作状態を確実に判断することができる。なお、請求項２記載の発明において、監視手段がアプリケーション手段から生存通知を受信した場合、受信した生存通知に対する応答をアプリケーション手段へ送信するように構成することが望ましい。

また、請求項１記載の発明において、監視手段は、例えば請求項３に記載したように、別の特定の業務処理用コンピュータ上で動作する監視手段へ定期的に生存通知を送信すると共に、別の特定の業務処理用コンピュータ上で動作する監視手段より最後に生存通知を受信してからの経過時間が閾値以上か否かを判断することで、別の特定の業務処理用コンピュータ又は別の特定の業務処理用コンピュータ上で動作する監視手段の動作状態を判別し、別の特定の業務処理用コンピュータ又は別の特定の業務処理用コンピュータ上で動作する監視手段の動作状態が異常と判断した場合に監視用コンピュータへ通知するように構成されていることが好ましい。

請求項３記載の発明では、異なる業務処理用コンピュータ上で動作する監視手段同士が生存通知を送信し合うので、別の業務処理用コンピュータ又は別の業務処理用コンピュータ上で動作する監視手段に異常が発生した場合にも検知することができる。また、当該異常検知は、最後に生存通知を受信してからの経過時間が閾値以上か否かを判断することで行っているので、別の業務処理用コンピュータ上で動作する監視手段から生存通知を受信した監視手段が、生存通知送信元の監視手段へ応答を送信する必要がなくなると共に、生存通知送信元の監視手段が、生存通知の送信から所定時間以上経過しても応答を受信しない場合に生存通知を再送信する等の処理を行う必要もなくなる。従って、或る業務処理用コンピュータで発生した処理遅延等の障害が、監視手段同士の通信を通じて別の業務処理用コンピュータへ波及することも防止することができる。

また、請求項２又は請求項３記載の発明において、監視手段は、例えば請求項４に記載したように、生存通知を受信する毎に受信時刻を同一の業務処理用コンピュータに設けられた第１記憶手段に記憶させ、第１記憶手段に記憶させた受信時刻に基づいて判断するように構成することができる。

また、請求項２記載の発明のように、アプリケーション手段が、所定の業務処理と並行して、同一の業務処理用コンピュータ上で動作する監視手段へ生存通知を送信する送信処理を定期的に行う場合、監視手段は、例えば請求項５に記載したように、同一の業務処理用コンピュータ上で動作するアプリケーション手段より生存通知を受信する毎に、生存通知の受信時刻を含む情報を、監視手段が動作するコンピュータに設けられた第２記憶手段にログ情報として記憶させるように構成することが好ましい。

監視手段へ生存通知を送信する送信処理をアプリケーション手段が定期的に行う場合、監視手段がアプリケーション手段から生存通知を定期的に受信している間は、アプリケーション手段の動作状態は正常と判断することができ、生存通知の受信時間間隔が長くなってきた場合には、アプリケーション手段に大きな負荷が加わっているか、アプリケーション手段の動作状態が不調になっている可能性が高いと判断できる。このように、アプリケーション手段の動作状態は生存通知の受信時間間隔から判断することができ、上記のように、監視手段が生存通知を受信する毎に、生存通知の受信時刻を含む情報をログ情報として記憶させることで、アプリケーション手段の動作が滞った等の場合にも、ログ情報を参照することで、どの時点までは動作状態が正常であったかや、動作が滞る以前のアプリケーション・プログラムの動作状況等を把握することが可能となり、原因を解析してアプリケーション手段の動作を早期に復旧させることが可能となる。

また、請求項１記載の発明において、例えば請求項６に記載したように、アプリケーション手段は、所定の業務処理を行ってエラーが発生した場合に、同一の業務処理用コンピュータ上で動作する監視手段へエラーの内容を表すエラー情報を送信し、監視手段は、同一の業務処理用コンピュータ上で動作するアプリケーション手段からエラー情報を受信した場合に、受信したエラー情報を同一の業務処理用コンピュータに設けられた第２記憶手段にエラーログ情報として記憶させると共に、監視用コンピュータへエラーの発生を通知するように構成することが好ましい。これにより、所定の業務処理でエラーが発生した場合にも検知できると共に、第２記憶手段に記憶されたエラーログ情報を参照することで、発生したエラーの内容を把握することが可能となる。

また、本発明に係るログ情報はコンピュータ・システムを管理する管理者が参照する情報であるが、アプリケーション手段が行う処理の業務処理が、ユーザからの依頼に従って行う処理である場合、請求項６記載の発明に係るエラーログ情報をユーザが閲覧・確認したいというニーズが生ずる。このニーズを満たすために、請求項６記載の発明において、例えば請求項７に記載したように、複数台の業務処理用コンピュータと通信回線を介して各々接続されたログ情報管理用コンピュータを更に設け、業務処理用コンピュータ上で動作し、同一の業務処理用コンピュータに設けられた第２記憶手段に記憶されているエラーログ情報をログ情報管理用コンピュータへ定期的に転送し、前記ログ情報管理用コンピュータに設けられた第３記憶手段に記憶させる転送手段を、複数台の業務処理用コンピュータに各々設けることが好ましい。これにより、個々の業務処理用コンピュータの第２記憶手段に記憶されたエラーログ情報（個々の業務処理用コンピュータのアプリケーション手段に対応するエラーログ情報）がログ情報管理用コンピュータに一元管理されることになり、エラーログ情報を閲覧に供することが可能となる。

また、請求項７記載の発明において、ログ情報管理用コンピュータには、例えば請求項８に記載したように、ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を前記第３記憶手段から読み出して配信要求元の端末装置へ転送するログ情報管理手段が設けられていることが好ましい。これにより、エラーログ情報の閲覧・確認を所望しているユーザが、端末装置を介してエラーログ情報をオンラインで閲覧・確認することが可能となり、エラーログ情報の閲覧・確認を所望しているユーザの利便性が向上する。

以上説明したように本発明は、各々アプリケーション・プログラムを実行することで所定の業務処理を行うアプリケーション手段として各々機能する複数台の業務処理用コンピュータに、同一の業務処理用コンピュータ上で動作するアプリケーション手段との間で定期的に通信を行い、当該通信によって判別したアプリケーション手段の動作状態を第２記憶手段にログ情報として記憶させると共に、前記定期的な通信が途絶えたことに基づいてアプリケーション手段の動作状態が異常と判断した場合に監視用コンピュータへ通知する監視手段を各々設けたので、コンピュータ間のトラフィック量の増大を抑制しつつ、アプリケーションに対する障害監視及びログ情報の収集・記憶を実現できる、という優れた効果を有する。

以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るコンピュータ・システム１０が示されている。コンピュータ・システム１０は、端末装置１２を含んで構成された第１のコンピュータ・システム１４と第２のコンピュータ・システム１６の間に設けられており、第１のコンピュータ・システム１４から送信された電文及び第２のコンピュータ・システム１６から送信された電文を各々受信し、受信した電文の内容に応じた所定の処理（業務処理）を行った後に、他方のコンピュータ・システムへ送信する機能を有している。

なお、例えば第２のコンピュータ・システム１６としては、金融機関に設置され、金融機関の顧客から指示された金融取引を行う金融取引システムを適用することができ、第１のコンピュータ・システム１４としては、金融機関の顧客が端末装置１２を介して所望の金融取引を指示するためのコンピュータ・システムを適用することができる。この場合、本実施形態に係るコンピュータ・システム１０は、業務処理として、受信した電文を送信先のコンピュータ・システムに適合したフォーマットへ変換する等の処理を行うように構成することができるが、本発明に係る業務処理としては任意の処理を適用可能である。

図１に示すように、コンピュータ・システム１０は２台のデータベース・サーバ２０Ａ，２０Ｂと、複数台のアプリケーション・サーバ３０（図には２台のアプリケーション・サーバ３０Ａ，３０Ｂを示す）と、複数台のウェブ・サーバ４０（図には２台のウェブ・サーバ４０Ａ，４０Ｂを示す）と、監視用コンピュータ５０を含んで構成されており、これらの各サーバ及びコンピュータは通信回線５２を介して互いに接続されている。なお、本実施形態に係るコンピュータ・システム１０では、データベース・サーバ２０については２台のデータベース・サーバ２０Ａ，２０Ｂの何れか一方のみ稼働され（稼働中のデータベース・サーバ２０に重大な障害が発生した場合に、待機中のデータベース・サーバ２０が稼働中に切り替わる）、アプリケーション・サーバ３０及びウェブ・サーバ４０については全台のサーバが常時稼働される。

データベース・サーバ２０は、ＣＰＵ２２、ＲＡＭ等から成るメモリ２４、ハードディスクドライブ（ＨＤＤ）６６、ネットワークインタフェース（Ｉ／Ｆ）部２８を備えており、ネットワークＩ／Ｆ部２８を介して通信回線５２に接続されており、更に通信回線を介して第１のコンピュータ・システム１４及び第２のコンピュータ・システム１６に各々接続されている。データベース・サーバ２０のＨＤＤ２６には電文格納テーブル及びログテーブルが各々記憶されており、ＣＰＵ２２が電文処理を行うための電文処理プログラムと、ＣＰＵ２２がログ通信監視処理を行うためのログ通信監視プログラムが各々インストールされている。なお、ログテーブルを記憶するＨＤＤ２６は請求項８に記載の第３記憶手段に対応している。

この電文処理プログラムがＣＰＵ２２によって実行されることでデータベース・サーバ２０上で動作する電文処理モジュールは、第１のコンピュータ・システム１４及び第２のコンピュータ・システム１６から電文を受信し、受信した電文について業務処理を行う複数台のアプリケーション・サーバ３０に加わる負荷が均一となるように、受信した電文を処理するアプリケーション・サーバ３０を決定し、決定したアプリケーション・サーバ３０を宛先として設定した電文を電文格納テーブルに格納させると共に、アプリケーション・サーバ３０による業務処理が完了した電文を、電文送信先のコンピュータ・システムへ送信する電文処理を行う。なお、ログ通信監視プログラムがＣＰＵ２２によって実行されることでデータベース・サーバ２０上で動作するログ通信監視モジュールについては後述する。

また、アプリケーション・サーバ３０は、ＣＰＵ３２、ＲＡＭ等から成るメモリ３４、ＨＤＤ３６、ネットワークＩ／Ｆ部３８を備えており、ネットワークＩ／Ｆ部３８を介して通信回線５２に接続されている。アプリケーション・サーバ３０のＨＤＤ３６には、ログ情報及びエラーログ情報を格納するためのログファイルが記憶されており、ＣＰＵ３２が業務処理を行うための業務処理プログラムと、ＣＰＵ３２が監視処理を行うための監視処理プログラムと、ＣＰＵ３２がログサービス処理を行うためのログサービスプログラムと、ＣＰＵ３２がログ回収処理を行うためのログ回収プログラムが各々インストールされている（各処理については後述）。ログファイルを記憶するＨＤＤ３６は請求項５，６に記載の第２記憶手段に対応している。

なお、アプリケーション・サーバ３０は本発明に係る業務処理用コンピュータに、業務処理プログラムは本発明に係るアプリケーション・プログラムに対応しており、ＣＰＵ３２が業務処理プログラムを実行することでアプリケーション・サーバ３０上で動作する処理モジュール（業務処理モジュール）は本発明に係るアプリケーション手段（詳しくは請求項２に記載のアプリケーション手段）に対応している。また、ＣＰＵ３２がログサービスプログラムを実行することでアプリケーション・サーバ３０上で動作するログサービスモジュールと、ＣＰＵ３２が障害監視ログラムを実行することでアプリケーション・サーバ３０上で動作する監視モジュールは本発明に係る監視手段（詳しくは請求項２〜請求項６に記載の監視手段）に対応しており、ＣＰＵ３２がログ回収プログラムを実行することでアプリケーション・サーバ３０上で動作するログ回収モジュールは請求項７に記載の転送手段に対応している。

また、ウェブ・サーバ４０は、ＣＰＵ４２、ＲＡＭ等から成るメモリ４４、ＨＤＤ４６、ネットワークＩ／Ｆ部４８を備えており、ネットワークＩ／Ｆ部４８を介して通信回線５２に接続されている。ウェブ・サーバ４０のＨＤＤ４６には、ＣＰＵ４２が画面制御処理を行うための画面制御プログラムと、ＣＰＵ４２が障害監視処理を行うための障害監視プログラムと、ＣＰＵ４２がログサービス処理を行うためのログサービスプログラムが各々インストールされており（各処理については後述）、ログ情報及びエラーログ情報を格納するためのログファイルも記憶されている。

なお、ウェブ・サーバ４０も本発明に係る業務処理用コンピュータに、画面制御プログラムも本発明に係るアプリケーション・プログラムに対応しており、ＣＰＵ４２が画面制御プログラムを実行することでウェブ・サーバ４０上で動作する画面制御モジュールも本発明に係るアプリケーション手段（詳しくは請求項２に記載のアプリケーション手段）に対応し、当該画面制御モジュールによって行われる画面制御処理（後述）も本発明に係る所定の業務処理に対応している。また、ウェブ・サーバ４０はデータベース・サーバ２０と共に請求項７，８に記載のログ情報管理用コンピュータとしても機能し、ウェブ・サーバ４０上で動作する画面制御モジュールは請求項８に記載のログ情報管理手段にも対応している。また、ＣＰＵ４２がログサービスプログラムを実行することでウェブ・サーバ４０上で動作するログサービスモジュールと、ＣＰＵ４２が障害監視プログラムを実行することでウェブ・サーバ４０上で動作する監視モジュールも本発明に係る監視手段（詳しくは請求項２〜請求項６に記載の監視手段）に対応しており、ＣＰＵ４２がログ回収プログラムを実行することでウェブ・サーバ４０上で動作するログ回収モジュールも請求項７に記載の転送手段に対応している。

更に、本実施形態に係るコンピュータ・システム１０は本発明に係るコンピュータ・システムに対応している。また、監視用コンピュータ５０はコンピュータ・システム１０を管理する管理者によって使用されるコンピュータであり、本発明に係る監視用コンピュータに対応している。

次に本実施形態の作用として、各サーバ３０上で動作する各種モジュールによって実現される処理について説明する。なお、以下では説明を簡単にするために、同時に稼働しているアプリケーション・サーバ３０及びウェブ・サーバ４０の台数を各々２台とし、各々２台のサーバの一方を１系（フローチャート上では「＃１」と表記）、他方を２系（フローチャート上では「＃２」と表記）と称して区別する。

個々のアプリケーション・サーバ３０上で動作する業務処理モジュールは、各々図２に示す業務処理を行っている。この業務処理では、まずステップ６０において、データベース・サーバ２０のＨＤＤ２６に記憶されている電文格納テーブル内に、自サーバ３０宛の電文（処理対象電文）が格納されているか否か判定する。処理対象電文が格納されていない場合は判定が否定されてステップ６２へ移行し、前回ハートビートを送信してからの経過時間が所定時間ｔ１以上になったか否か判定する。この判定も否定された場合はステップ６０に戻り、何れかの判定が肯定される迄ステップ６０，６２を繰り返す。

ステップ６２の判定が肯定された場合はステップ６４へ移行し、自モジュールと同一のアプリケーション・サーバ３０上で動作している同系のログサービスモジュール（自モジュールが１系の業務処理モジュールであれば１系のログサービスモジュール、自モジュールが２系の業務処理モジュールであれば２系のログサービスモジュール）へハートビートを送信する。なお、このハートビートは自モジュールの動作状態が正常であることを表す所定桁数のメッセージＩＤを含む情報であり、請求項２記載のアプリケーション手段が送信する生存通知に対応している。

ステップ６６では、ステップ６４で送信したハートビートに対する応答を同系のログサービスモジュールから受信したか否か判定する。判定が否定された場合はステップ６８へ移行し、ステップ６４でハートビートを送信してからの経過時間が所定時間ｔ２以上になったか否か判定する。この判定も否定された場合はステップ６６に戻り、何れかの判定が肯定される迄ステップ６６，６８を繰り返す。同系のログサービスモジュールからハートビートに対する応答を所定時間ｔ２以内に受信できなかった場合には、ステップ６８の判定が肯定されてステップ７０へ移行し、同系のログサービスモジュールへのハートビートの再送信を行ってステップ６６に戻る。そして、同系のログサービスモジュールからハートビートに対する応答を受信すると、ステップ６６の判定が肯定されてステップ６０に戻る。

このように、本実施形態に係る業務処理では、同系のログサービスモジュールからハートビートに対する応答を受信する迄の間、所定時間ｔ２が経過する毎に同系のログサービスモジュールへのハートビートの送信を繰り返しているが、これは本実施形態に係るコンピュータ・システム１０において、処理対象電文に対して行う業務処理が非常に重要な処理であるので、ハートビートを受信したログサービスモジュールがログファイルへログ情報を書き込む処理と完全に同期させる必要があり、ログファイルへのログ情報の書き込みが完了したか確認できない状態でアプリケーション・サーバ３０が業務処理を進めてしまうことを避けたいことが理由であり、上記のように完全に同期させる必要が無い場合には、ハートビートの再送信が所定回に達した時点でハートビートの再送信を打ち切るようにしてもよい。

一方、前述のステップ６０の判定において、電文格納テーブル内に処理対象電文が格納されていた場合は上記判定が肯定されてステップ７２へ移行し、電文格納テーブルから処理対象電文を取り出し、取り出した処理対象電文に基づき、次のステップ７４において、例えば処理対象電文を送信先のコンピュータ・システムに適合したフォーマットへ変換する等の業務処理を行う。ステップ７６では、ステップ７４の業務処理においてエラーが発生したか否か判定する。判定が否定された場合はステップ８６へ移行し、前回ハートビートを送信してから所定件の処理対象電文について業務処理を行ったか否か判定する。判定が否定された場合はステップ６０に戻り、電文格納テーブル内に処理対象電文が格納されている間、ステップ８６の判定が肯定される迄ステップ６０，ステップ７２〜７６，ステップ８６を繰り返す。そして、前回ハートビートを送信してから業務処理を行った処理対象電文の件数が所定件に達すると、ステップ８６の判定が肯定されてステップ６４へ移行し、先に説明したステップ６４〜ステップ７０において、同系のログサービスモジュールへのハートビートの送信を行う。

上述したように、アプリケーション・サーバ３０上で動作する業務処理モジュールは、処理対象電文が存在していないときには、同系のログサービスモジュールへのハートビートの送信を所定時間ｔ１周期で行い、処理対象電文が存在しているときには、所定件の処理対象電文について業務処理を行う毎に、同系のログサービスモジュールへのハートビートの送信を行う。上記のタイミングで自発的に（能動的に）ハートビートを送信する処理は、他のモジュールから所定の情報を受信した場合にハートビートを送信する処理と比較して業務処理モジュールに加わる負荷が小さく、上記タイミングでハートビートを送信することに伴って業務処理の遅延等が生ずることを防止できる。なお、上記のように業務処理モジュールが自発的に（能動的に）ハートビートの送信を行うことは請求項２記載の発明に対応している。

また、ステップ７４の業務処理でエラーが発生した場合には、ステップ７６の判定が肯定されてステップ７８へ移行し、発生したエラーの内容を表すエラー情報（このエラー情報には発生したエラーの種類に対応するエラーコード等の情報が含まれる）を同系のログサービスモジュールへ送信し(ステップ７８)、エラー情報に対する応答を同系のログサービスモジュールから受信したか否か判定し(ステップ８０)、応答を未受信であればエラー情報の送信から所定時間ｔ２以上経過したか否か判定し(ステップ８２)、エラー情報の送信から所定時間ｔ２以上経過する毎に同系のログサービスモジュールへのエラー情報の再送信を行う(ステップ８４)。

そして、エラー情報に対する応答を同系のログサービスモジュールから受信すると、ステップ８０の判定が肯定されて前述のステップ８６へ移行する。これにより、業務処理で発生したエラーの内容を表すエラー情報が、先に説明したステップ６４〜ステップ７０と同様にして同系のログサービスモジュールへ送信されることになる。上述した業務処理は、個々のアプリケーション・サーバ３０上で動作する個々の業務処理モジュールによって各々行われる。

また本実施形態では、ウェブ・サーバ４０のＣＰＵ４２が画面制御プログラムを実行することでウェブ・サーバ４０上で動作する画面制御モジュール、及び、データベース・サーバ２０のＣＰＵ２２が電文処理プログラムを実行することでデータベース・サーバ２０上で動作する電文処理モジュール及びログ通信監視モジュールにおいても、業務処理モジュールと同様にハートビート及びエラー情報の送信が行われる。

すなわち、本実施形態では、データベース・サーバ２０のＨＤＤ２６に記憶されているログテーブルに、個々のアプリケーション・サーバ３０上で動作する業務処理モジュールによる業務処理で発生したエラーの内容を表すエラーログ情報が格納されるが(詳細は後述）、ウェブ・サーバ４０は、ログテーブルにエラーログ情報を、第１のコンピュータ・システム１４の端末装置１２を介して閲覧することを可能とする機能を提供している。

この機能は、ウェブ・サーバ４０上で動作する画面制御モジュールが、データベース・サーバ２０上で動作するログ通信監視モジュールと協働することで実現され、画面制御モジュールは、端末装置１２を介してエラーログ情報の閲覧が要求された場合に、閲覧対象のエラーログ情報の転送をログ通信監視モジュールへ要求し、ログ通信監視モジュールによってログテーブルから読み出されて転送されたエラーログ情報に基づき、該エラーログ情報を端末装置１２のディスプレイに表示させるための表示画面を生成し、生成した表示画面の情報を閲覧要求元の端末装置１２へ配信する画面制御処理を行う。これにより、端末装置１２のディスプレイにエラーログ情報が表示される。

画面制御モジュールは、自モジュールと同系のウェブ・サーバ４０上で動作するログサービスモジュールに対し、業務処理モジュールによって行われる業務処理（図２）と同様に、上記の画面制御処理を行っていないときには一定時間間隔でハートビートを送信し、上記の画面制御処理を行っているときには、画面制御処理を一定単位行う毎にハートビートを送信し、画面制御処理でエラーが発生した場合にはエラー情報を送信する。

また、データベース・サーバ２０上で動作する電文処理モジュールは、アプリケーション・サーバ上で動作するログサービスモジュールがハートビート送信先とされており、複数台のアプリケーション・サーバ３０のうちハートビート送信先として設定されたアプリケーション・サーバ３０上で動作するログサービスモジュールに対し、業務処理モジュールによって行われる業務処理（図２）と同様に、先に説明した電文処理を行っていないときには一定時間間隔でハートビートを送信し、電文処理を行っているときには、電文処理を一定単位行う毎にハートビートを送信し、電文処理でエラーが発生した場合にはエラー情報を送信する。また、データベース・サーバ上で動作するログ通信監視モジュールについても、電文処理モジュールと同一のログサービスモジュールへ一定時間間隔でハートビートを送信するが、詳細は後述する。

次に、個々のアプリケーション・サーバ３０及び個々のウェブ・サーバ４０上で各々動作するログサービスモジュールによって各々行われるログサービス処理について、図３を参照して説明する。

このログサービス処理では、まずステップ１００において、他のモジュールから何らかの情報を受信したか否か判定し、判定が肯定される迄ステップ１００を繰り返す。なお、本実施形態において、ウェブ・サーバ４０上で動作するログサービスモジュールは、自モジュールと同一のウェブ・サーバ４０上で動作する画面制御モジュールから送信されるハートビート及びエラー情報のみを受信し、アプリケーション・サーバ３０上で動作するログサービスモジュールは、自モジュールと同一のアプリケーション・サーバ３０上で動作する業務処理モジュールから送信されるハートビート及びエラー情報を受信すると共に、データベース・サーバ２０上で動作する電文処理モジュール及びログ通信監視モジュールのハートビート送信先に設定されているログサービスモジュールについては、電文処理モジュール及びログ通信監視モジュールからのハートビート及び電文処理モジュールからのエラー情報も受信する。

他のモジュールから情報（ハートビート又はエラー情報）を受信すると、ステップ１００の判定が肯定されてステップ１０２へ移行し、受信した情報が業務処理モジュール、画面制御モジュール、電文処理モジュール及びログ通信監視モジュールの何れかから送信されたハートビートであれば、ハートビートの受信時刻やハートビートに含まれるメッセージＩＤ、ハートビートの送信元識別情報等をログ情報としてログファイルに書き出し、受信した情報が業務処理モジュール、画面制御モジュール及び電文処理モジュールの何れかから送信されたエラー情報であれば、受信したエラー情報に受信時刻や送信元識別情報等を付加し、エラーログ情報としてログファイルに書き出す。なお、ログファイルを記憶するウェブ・サーバ４０のＨＤＤ４６及びアプリケーション・サーバ３０のＨＤＤ３６は本発明に係る第２記憶手段に対応している。

次のステップ１０４では、受信情報（ハートビート又はエラー情報）の送信元（自モジュールと同一のサーバ上で動作する業務処理モジュール、データベース・サーバ２０上で動作する電文処理モジュール、ログ通信監視モジュールの何れか）へ応答を送信する。また、ステップ１０６では、ステップ１０２でログファイルへのログ情報又はエラーログ情報の書き出しが成功したか否か判定する。判定が肯定された場合はステップ１１０へ移行し、自モジュールと同一のサーバ（ウェブ・サーバ４０又はアプリケーション・サーバ３０）上で動作している監視モジュールに対し、先に受信した情報がハートビートであれば、当該ハートビートの送信元のモジュールが生存している（動作している）ことを意味する生存通知を送信し、先に受信した情報がエラー情報であれば、当該エラー情報の送信元の業務処理モジュールでエラーが発生したことを意味するエラー通知を送信し、ステップ１００に戻る。

また、先のステップ１０２においてＨＤＤの障害等の理由でログファイルへのログ情報又はエラーログ情報の書き出しに失敗した場合には、ステップ１０６の判定が否定されてステップ１０８へ移行し、ログファイルへの情報の書き出しに失敗したことを意味するエラーコードを含むエラー通知を、自モジュールと同一のサーバ上で動作している監視モジュールへ送信した後にステップ１１０へ移行する。従って、ログファイルへのログ情報又はエラーログ情報の書き出しに失敗した場合は、自モジュールと同一のサーバ上で動作している監視モジュールに対し、上記のエラー通知を送信しログファイルへの書き出し失敗を通知した後に、他のモジュールから受信した情報に基づく生存通知又はエラー通知の送信が行われることになる。

続いて、個々のアプリケーション・サーバ３０及び個々のウェブ・サーバ４０上で各々動作する監視モジュールによって各々行われる障害監視処理について、図４を参照して説明する。なお、障害監視処理は先に説明したログサービス処理と共に本発明に係る監視手段に相当する処理であり、同一のサーバ上で動作するログサービスモジュールと監視モジュールは、本発明に係る監視手段に対応している。

監視モジュールによって実現される障害監視処理では、まずステップ１２０で、他のモジュールから何らかの情報を受信したか否か判定する。個々の監視モジュールは自モジュールと同一のサーバ上で動作するログサービスモジュールから生存通知及びエラー通知を各々受信すると共に、他系のサーバ（自モジュールが１系のアプリケーション・サーバ３０上で動作している場合は２系のアプリケーション・サーバ３０、自モジュールが２系のウェブ・サーバ４０上で動作している場合は１系のウェブ・サーバ４０）上で動作する他系の監視モジュールからハートビートも受信する。ステップ１２０の判定が肯定された場合はステップ１４０へ移行し、受信した情報は自モジュールと同一のサーバ上で動作するログサービスモジュールから送信されたエラー通知か否か判定する。

受信した情報が自モジュールと同一のサーバ上で動作するログサービスモジュールから送信された生存通知、或いは他系のサーバ上で動作する他系の監視モジュールから送信されたハートビートである場合には、上記判定が否定されてステップ１４２へ移行し、自モジュールが動作するサーバのＨＤＤに記憶されている最終受信日時テーブルを更新した後にステップ１２０に戻る。この最終受信日時テーブルは、ログサービスモジュールから受信する生存通知によって動作状態が正常であることが通知される各モジュール（自モジュールと同一のサーバ上で動作する業務処理モジュール又は画面制御モジュール（及び電文処理モジュール、ログ通信監視モジュール）と、ハートビート送信元の他系の監視モジュールについて、生存通知又はハートビートを最後に受信した日時を各々登録するためのテーブルであり、ステップ１４２における最終受信日時テーブルの更新は、受信した情報に対応するモジュール（生存通知を受信した場合は当該生存通知によって動作状態が正常であることが通知された業務処理モジュール、画面制御モジュール、電文処理モジュール、ログ通信監視モジュールの何れか、ハートビートを受信した場合は他系の監視モジュール）の最終受信日時を現在の日時で上書きすることによって成される。なお、上記の最終受信日時テーブルを記憶するＨＤＤは請求項４に記載の第１記憶手段に対応している。

また、受信した情報がエラー通知であった場合には、ステップ１４０の判定が肯定されてステップ１４４へ移行し、受信したエラー通知を監視用コンピュータ５０へ転送することで、エラーの発生を監視用コンピュータ５０へ通知する。監視モジュールが受信するエラー通知には、発生したエラーの種類を表すエラーコードが含まれており、このエラーコードは、発生したエラーが業務処理で発生したエラーである場合はエラーが発生した業務処理モジュールによって設定され、発生したエラーが画面制御処理で発生したエラーである場合はエラーが発生した画面制御モジュールによって設定され、発生したエラーが電文処理で発生したエラーである場合はエラーが発生した電文処理モジュールによって設定され、発生したエラーがログファイルへの情報の書き出し失敗である場合はログサービスモジュールによって設定される。各サーバ上で動作する監視モジュールの何れかからエラー通知を受信した場合、監視用コンピュータ５０は、受信したエラー通知に含まれるエラーコードを対応するエラーメッセージに変換してディスプレイに表示する。これにより、コンピュータ・システム１０の管理者は、コンピュータ・システム１０内の何れのモジュールでどのようなエラーが発生したのかを直ちに認識することができ、必要に応じてエラー解消のための対処や再発防止のための対策を講ずることができる。

また、監視モジュールが他のモジュールから情報を受信していない場合は、ステップ１２０の判定が否定されてステップ１２２へ移行し、他系の監視モジュールへ前回ハートビートを送信してからの経過時間が所定時間ｔ３以上となったか否か判定する。判定が否定された場合はステップ１２８へ移行するが、判定が肯定された場合は、ステップ１２４で他系の監視モジュールと通信可能な状態か否か判定する。他系のサーバがダウンしている、或いは自モジュールが動作するサーバと他系のサーバとの間の通信回線に障害が発生している等の原因で他系の監視モジュールとの間にリンクが確立できない場合は、上記判定が否定されてステップ１２８へ移行するが、判定が肯定された場合は、ステップ１２６で他系の監視モジュールへハートビートを送信した後にステップ１２８へ移行する。このように、各サーバ上で動作する監視モジュールは、他系の監視モジュールへのハートビートの送信を所定時間ｔ３周期で各々行う。

ステップ１２８では最終受信日時テーブルを参照し、障害監視対象の各モジュール（自モジュールと同一のサーバ上で動作する業務処理モジュール又は画面制御モジュール、他系の監視モジュール（自モジュールと同一のサーバ上で動作するログサービスモジュールが電文処理モジュール及びログ通信監視モジュールのハートビート送信先に設定されている場合は、電文処理モジュール及びログ通信監視モジュールも障害監視対象となる）のうち、最終受信日時テーブルに記憶されている最終受信日時からの経過時間が閾値以上となっているモジュールを探索する。なお、上記の閾値は、最終受信日時テーブルに最終受信日時が登録されている各モジュール毎に設定されている。次のステップ１３０では、ステップ１２８の探索によって該当するモジュールが発見されたか否か判定する。この判定が否定された場合、障害監視対象の各モジュールは何れも動作状態が正常と判断できるので、何ら処理を行うことなくステップ１２０に戻る。

一方、ステップ１２８の探索で該当するモジュールが発見された場合、該当するモジュールには障害が発生している可能性が高いと判断できる（上記場合は、請求項１に記載の「アプリケーション手段との間の定期的に通信が途絶えた」ことに相当する）。このため、ステップ１３０の判定が肯定された場合はステップ１３２へ移行し、ステップ１２８の探索で発見されたモジュールに障害が発生している可能性が高いことを監視用コンピュータ５０へ通知する。この場合も、監視用コンピュータ５０のディスプレイにメッセージが表示されることで、コンピュータ・システム１０の管理者がコンピュータ・システム１０の状況を把握することができ、必要に応じて障害復旧のための対処や再発防止のための対策を講ずることができる。またステップ１３４では、障害が発生している可能性が高いと判定したモジュールが何れのモジュールかに応じて処理を分岐する。

障害が発生している可能性が高いと判定したモジュールが自モジュールと同一のサーバ上で動作する業務処理モジュールである場合には、ステップ１３４からステップ１３６へ移行し、データベース・サーバ２０の電文格納テーブルに格納されている電文の宛先を参照し、障害が発生している可能性が高いと判定した業務処理モジュールが宛先に設定されている電文（障害が発生している可能性が高いと判定した業務処理モジュールで処理予定の電文）について、宛先を他系の業務処理モジュールへ書き替えた後にステップ１２０に戻る。この場合、データベース・サーバ２０が受信した電文に対する業務処理は全て他系の業務処理モジュールによって行われることになる。また、障害が発生している可能性が高いと判定したモジュールが、データベース・サーバ２０上で動作する電文処理モジュール又はログ通信監視モジュールである場合には、ステップ１３４からステップ１３８へ移行し、障害が発生している可能性が高いと判定した電文処理モジュール又はログ通信監視モジュールをデータベース・サーバ２０上で再起動した後にステップ１２０に戻る。

なお本実施形態では、障害が発生している可能性が高いと判定した業務処理モジュールが、自モジュールと同一のサーバ上で動作する画面制御モジュールであった場合及び他系の監視モジュールであった場合には何ら処理を行わず、管理者に対処を委ねているが、障害が発生したモジュールの再起動等の何らかの処理を行うようにしてもよい。

次に、個々のアプリケーション・サーバ３０及び個々のウェブ・サーバ４０上で各々動作するログ回収モジュールによって各々行われるログ回収処理について、図５を参照して説明する。このログ回収処理では、まずステップ１５０において、データベース・サーバ２０のログ通信監視モジュールへエラーログ情報を前回送信してからの経過時間が所定時間ｔ４以上となったか否か判定し、判定が肯定される迄ステップ１５０を繰り返す。上記判定が肯定されるとステップ１５２へ移行し、自モジュールが動作しているサーバのＨＤＤに記憶されているログファイルから、データベース・サーバ２０のログ通信監視モジュールへの転送を行っていないエラーログ情報を全て読み出す。

そしてステップ１５４では、ログファイルから読み出したエラーログ情報をデータベース・サーバ２０のログ通信監視モジュールへ転送し、データベース・サーバ２０のＨＤＤ２６に記憶されているログテーブルに書き出させた後にステップ１５０に戻る。ログ回収モジュールが上記処理を行うことにより、各サーバに設けられたログファイルに書き出されたエラーログ情報は、業務処理モジュールや画面制御モジュール、電文処理モジュールからのエラー情報の送信、ログサービスモジュールによるログファイルへのエラーログ情報の書き出しと非同期にログテーブルへ移され、ログテーブルに一元管理されることになる。

続いて、データベース・サーバ２０上で動作するログ通信監視モジュールによって行われるログ通信監視処理について、図６を参照して説明する。このログ通信監視処理では、まずステップ１６０において、個々のアプリケーション・サーバ３０のうち、自モジュール及び電文処理モジュールのハートビートの送信先として設定されているアプリケーション・サーバ３０上で動作しているログサービスモジュール（ハートビート送信先のログサービスモジュール）へ前回ハートビートを送信してからの経過時間が所定時間ｔ５以上となったか否か判定し、判定が肯定される迄ステップ１６０を繰り返す。ステップ１６０の判定が肯定されるとステップ１６２へ移行し、ハートビート送信先のログサービスモジュールと通信可能な状態か否か判定する。

ステップ１６２の判定が肯定された場合はステップ１６４へ移行し、ハートビート送信先のログサービスモジュールへハートビートを送信する。次のステップ１６６では、ステップ１６４で送信したハートビートに対する応答をハートビート送信先のログサービスモジュールから受信したか否か判定する。判定が否定された場合は１ステップ６８へ移行し、ステップ１６４でハートビートを送信してからの経過時間が所定時間ｔ２以上になったか否か判定する。この判定も否定された場合はステップ１６６に戻り、何れかの判定が肯定される迄ステップ１６６，１６８を繰り返す。

ハートビート送信先のログサービスモジュールからハートビートに対する応答を所定時間ｔ２以内に受信できなかった場合には、ステップ１６８の判定が肯定されてステップ１７０へ移行し、ハートビート送信先のログサービスモジュールへのハートビートの再送信回数が所定値ｎに達したか否か判定する。判定が否定された場合はステップ１７２でハートビートの送信先へのハートビートの再送信を行ってステップ１６６に戻る。そして、ハートビート送信先のログサービスモジュールからハートビートに対する応答を受信した場合には、ステップ１６６の判定が肯定されてステップ１６０に戻る。

一方、ハートビート送信先のアプリケーション・サーバ３０がダウンしている、又は自モジュールが動作するデータベース・サーバ２０とハートビート送信先のアプリケーション・サーバ３０との間の通信回線に障害が発生している等の原因で、ハートビート送信先のログサービスモジュールとの間にリンクが確立できずステップ１６２の判定が否定された場合、或いは、ハートビート送信先のログサービスモジュールへのハートビートの再送信をｎ回行ったものの所定時間ｔ２以内に応答を受信できずステップ１７０の判定が肯定された場合には、ハートビート送信先のログサービスモジュールに障害が発生している可能性が高いと判断できる。このため、上記場合にはステップ１７４へ移行し、自モジュール及び電文処理モジュールのハートビートの送信先を、現在設定されているアプリケーション・サーバ３０と別（他系）のアプリケーション・サーバ３０へ切り替えた後にステップ１７４へ戻る。これにより、ハートビート送信先のログサービスモジュールに障害が発生している可能性が高い場合には、電文処理モジュール及びログ通信監視モジュールのハートビート送信先が他系のログサービスモジュールへ切り替わることになる。

続いて、各サーバ上で動作する各モジュールが上述した各処理を行うことで実現される障害監視／検知シーケンスについて、図７〜図１６を参照して更に説明する。

各サーバが正常に動作しており、各モジュールの動作状態も正常である場合、図７に示すシーケンスで障害監視が行われる。すなわち、１系のアプリケーション・サーバ３０上で動作する１系の業務処理モジュールは、自モジュールと同一のサーバ３０上で動作するログサービスモジュールへのみ定期的にハートビートを送信する(図７の(1))。ログサービスモジュールは、同一のサーバ３０上で動作する１系の業務処理モジュールからハートビートを受信する毎に、ログファイルへログ情報を書き出し(図７の(2))、ハートビート送信元の１系の業務処理モジュールへ応答を送信する(図７の(3))と共に、自モジュールと同一のサーバ３０上で動作する監視モジュールへ１系の業務処理モジュールの生存通知を送信する(図７の(4))。

１系のアプリケーション・サーバ３０上で動作する監視モジュールは、自モジュールと同一のサーバ３０上で動作するログサービスモジュールから１系の業務処理モジュールの生存通知を受信すると、最終受信日時テーブルに登録されている１系の業務処理モジュールに対応する最終受信日時を更新し、更新後の最終受信日時からの経過時間に基づいて１系の業務処理モジュールにおける障害の発生を監視するが、１系の業務処理モジュールの動作状態が正常である場合、上記の経過時間が閾値に達する前に１系の業務処理モジュールの生存通知をログサービスモジュールから再度受信することで、１系の業務処理モジュールの動作状態が正常であると判断される。

なお、図７では１系のアプリケーション・サーバ３０上で動作する１系の業務処理モジュールの障害監視シーケンスを示しているが、２系のアプリケーション・サーバ３０上で動作する２系の業務処理モジュールについても、同様のシーケンスによって障害監視・ログファイルへのログ情報の書き出しが行われる。また、個々のウェブ・サーバ４０においても、個々のウェブ・サーバ４０上で動作する個々の画面制御モジュールから定期的に送信されるハートビートに基づいて同様のシーケンスが行われることで、個々の画面制御モジュールの障害監視・ログファイルへのログ情報の書き出しが行われる。

また、１系の業務処理モジュールによる業務処理でエラーが発生した場合、図８に示すシーケンスで業務処理のエラーが検知される。すなわち、１系の業務処理モジュールは業務処理でエラーが発生すると自モジュールと同一のサーバ３０上で動作するログサービスモジュールへエラー情報を送信する(図８の(1))。ログサービスモジュールは、自モジュールと同一のサーバ３０上で動作する業務処理モジュールからエラー情報を受信すると、ログファイルにエラーログ情報を書き出し(図８の(2))、エラー情報送信元の１系の業務処理モジュールへ応答を送信し(図８の(3))、１系の業務処理モジュールによる業務処理におけるエラーの発生を通知するエラー通知を自モジュールと同一のサーバ３０上で動作する監視モジュールへ送信する(図８の(4))。そして、自モジュールと同一のサーバ３０上で動作するログサービスモジュールからエラー通知を受信した監視モジュールは、監視用コンピュータ５０へエラー通知を送信することで、１系の業務処理モジュールによる業務処理におけるエラーの発生を通知する。これにより管理者は、監視用コンピュータ５０を通じて、１系の業務処理モジュールによる業務処理でエラーが発生したことを認識し、必要に応じてエラー解消のための対処や再発防止のための対策を講ずることができる。

また、上記シーケンスと非同期かつ一定の周期で、１系のアプリケーション・サーバ３０上で動作するログ回収モジュールは、自モジュールが動作するサーバ３０に設けられたログファイルから、データベース・サーバ２０のログテーブルへ未転送のエラーログ情報を読み出し(図８の(a))、読み出したエラーログ情報をデータベース・サーバ２０へ転送し、データベース・サーバ２０に設けられたログテーブルに書き出す(図８の(b))。このシーケンスでログテーブルに書き出されたエラーログ情報は、第１のコンピュータ・システム１４の端末装置１２を介しての閲覧に供せられる。

なお、図８では１系のアプリケーション・サーバ３０上で動作する１系の業務処理モジュールからエラー情報が送信された場合のシーケンスを示しているが、２系のアプリケーション・サーバ３０上で動作する２系の業務処理モジュールによる業務処理でエラーが発生した場合にも、２系のアプリケーション・サーバ３０内で上記のシーケンスが行われることで、２系の業務処理モジュールによる業務処理でのエラーの発生が検知されると共に、ログファイルに書き出されたエラーログ情報のログテーブルへの転送・書き出しが行われる。また、個々のウェブ・サーバ４０上で動作する個々の画面制御モジュールによる画面制御処理でエラーが発生した場合にも、エラーが発生した画面制御モジュールが動作するウェブ・サーバ４０内で上記のシーケンスが行われることで、画面制御モジュールによる画面制御処理でのエラーの発生が検知されると共に、ログファイルに書き出されたエラーログ情報のログテーブルへの転送・書き出しが行われる。従って、各サーバ上で動作する業務処理モジュールや画面制御モジュールに対応するエラーログ情報は、全てログテーブルに書き出されて一元管理されることになり、これらのエラーログ情報を第１のコンピュータ・システム１４の端末装置１２を介して閲覧することが可能となる。

また、１系の業務処理モジュールに障害が発生した場合（１系の業務処理モジュールがプロセスとして実行中であるものの動作が滞っている状態に陥った場合を含む）には、図９に示すように、１系の業務処理モジュールから同一のサーバ３０上で動作するログサービスモジュールへのハートビートの送信(図９の(1))が滞るので、同一のサーバ３０上で動作するログサービスモジュールによるログファイルへのログ情報の書き出し(図９の(2))、業務処理モジュールへのハートビートの応答送信(図９の(3))、同一のサーバ３０上で動作する監視モジュールへの１系の業務処理モジュールの生存通知の送信(図９の (4))も滞ることになる。これにより、同一のサーバ３０上で動作する監視モジュールにおいて、１系の業務処理モジュールの生存通知を最後に受信してからの経過時間が閾値以上となることで障害発生が検知され、自モジュールと同一のサーバ３０上で動作している業務処理モジュール（又はログサービスモジュール）の障害発生が監視用コンピュータ５０へ通知されると共に、データベース・サーバ２０の電文格納テーブルに格納されている電文の宛先を他系の業務処理モジュールへ書き替える宛先書替処理が行われる。

また、１系のログサービスモジュールに障害が発生した場合には、図１０に示すように、１系の業務処理モジュールから同一のサーバ３０上で動作するログサービスモジュールへハートビートを送信できない(図１０の(1))ので、同一のサーバ３０上で動作するログサービスモジュールによるログファイルへのログ情報の書き出し(図１０の(2))、業務処理モジュールへのハートビートの応答送信(図１０の(3))、同一のサーバ３０上で動作する監視モジュールへの１系の業務処理モジュールの生存通知の送信(図１０の (4))も行われない。これにより、図９に示すシーケンスと同様に、同一のサーバ３０上で動作する監視モジュールにおいて、１系の業務処理モジュールの生存通知を最後に受信してからの経過時間が閾値以上となることで障害発生が検知され、自モジュールと同一のサーバ３０上で動作している業務処理モジュール（又はログサービスモジュール）の障害発生が監視用コンピュータ５０へ通知されると共に、データベース・サーバ２０の電文格納テーブルに格納されている電文の宛先を他系の業務処理モジュールへ書き替える宛先書替処理が行われる。

監視モジュールが同一のサーバ３０上で動作する業務処理モジュールの生存通知を一定時間以内に受信できない場合、原因としては、図９に示すような業務処理モジュールでの障害発生と、図１０に示すようなログサービスモジュールでの障害発生が考えられ、本実施形態に係るコンピュータ・システム１０では両者を判別することは困難である。但し、本実施形態に係る業務処理モジュールは、ハートビートの送信時に、送信したハートビートに対する応答を受信した後に業務処理を再開するので、業務処理モジュールに障害が発生した場合にも、業務処理モジュールがハートビートを送信するログサービスモジュールに障害が発生した場合にも、業務処理モジュールによる業務処理は滞ることになる。このため、本実施形態では特定の業務処理モジュールの生存通知が途絶えた場合、その原因を判別することなく一律に上記の宛先書替処理を行うことで、業務処理が滞ることを防止している。

また、特定のアプリケーション・サーバ３０上で動作する業務処理モジュール又はログサービスモジュールの障害発生が監視用コンピュータ５０を通じて通知された場合、管理者は、特定のアプリケーション・サーバ３０に設けられたログファイルに格納されているログ情報の参照等を行うことで、障害が発生したモジュールが業務処理モジュールかログサービスモジュールかを判別し、必要に応じて障害復旧のための対処や再発防止のための対策を講ずる。なお、障害が発生したアプリケーション・サーバ３０上で動作するログサービスモジュールが、データベース・サーバ２０上で動作する電文処理モジュール及びログ通信監視モジュールからのハートビートも受信している場合には、上記のログサービスモジュールから電文処理モジュールの生存通知及びログ通信監視モジュールの生存通知も監視モジュールへ送信されるので、上記のログサービスモジュールからの特定の業務処理モジュールの生存通知が途絶えた場合、これらの別モジュールの生存通知は受信しているか否かに基づいて、障害が発生したモジュールが業務処理モジュールかログサービスモジュールかを自動的に判別可能である。また、業務処理モジュールと同様に、監視モジュールへ定期的にハートビートを送信するようにログサービスモジュールを構成してもよく、この場合は障害が発生したモジュールが業務処理モジュールかログサービスモジュールかを自動的に判別することができる。

また管理者は、業務処理モジュールに障害が発生したと判別した場合、ログファイルに書き込まれているログ情報のうち、障害が発生した業務処理モジュールに対応するログ情報を抽出・参照する。このログ情報には、障害が発生した業務処理モジュールからハートビートを受信した時刻が含まれており、障害が発生した業務処理モジュールからハートビートを最後に受信した時刻に基づいて、障害が発生した業務処理モジュールがどの時点までは正常に動作していたのかを認識できると共に、障害が発生した業務処理モジュールからハートビートの送信が途絶える以前のハートビートの受信時間間隔の変動等に基づき、障害発生以前の業務処理モジュールの動作状態等も把握することができ（業務処理モジュールの動作状態が不良になるとハートビートの送信時間間隔も大きくなる）、ログ情報に基づいて発生した障害の原因解析等を行うことができる。

なお、図９，１０では１系のアプリケーション・サーバ３０上で動作する業務処理モジュール又はログサービスモジュールで障害が発生した場合のシーケンスを示しているが、２系のアプリケーション・サーバ３０上で動作する業務処理モジュール又はログサービスモジュールで障害が発生した場合にも、２系のアプリケーション・サーバ３０内で上記のシーケンスが行われることで、障害発生が検知されると共に障害が発生したモジュールの判別が行われる。また、個々のウェブ・サーバ４０上で動作する画面制御モジュール又はログサービスモジュールで障害が発生した場合にも、障害が発生したウェブ・サーバ４０内で上記のシーケンスが行われることで、障害発生が検知されると共に障害が発生したモジュールの判別が行われる。

また、１系のアプリケーション・サーバ３０上で動作するログサービスモジュールでログファイルへのログ情報の書き出しに失敗した場合には、図１１に示すシーケンスでログ情報の書き出し失敗（書き出し障害）が検知される。すなわち、１系の業務処理モジュールが同一のサーバ３０上で動作するログサービスモジュールへハートビートを送信し(図１１の(1))、このハートビートの受信を契機として同一のサーバ３０上で動作するログサービスモジュールがログファイルへのログ情報の書き出しを行ったものの、当該書き出しに失敗した場合(図１１の(2))、ログサービスモジュールは、まずハートビートに対する応答をハートビート送信元の１系の業務処理モジュールへ送信し(図１１の(2))、ログファイルへのログ情報の書き出しに失敗したことを通知するエラー通知を同一のサーバ３０上で動作する監視モジュールへ送信し(図１１の(4))、１系の業務処理モジュールの生存通知を監視モジュールへ送信する (図１１の(5))。

そして、ログサービスモジュールから受信したエラー通知に基づき、ログサービスモジュールにおけるログファイルへのログ情報の書き出し失敗が監視モジュールによって監視用コンピュータ５０へ通知される。管理者は、監視用コンピュータ５０を通じて１系のアプリケーション・サーバ３０上で動作するログサービスモジュールでログ情報の書き出しが失敗したことを認識することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。なお、図１１では１系のアプリケーション・サーバ３０上で動作するログサービスモジュールでログ情報の書き出し失敗が発生した場合のシーケンスを示しているが、２系のアプリケーション・サーバ３０や個々のウェブ・サーバ４０上で動作するログサービスモジュールでログ情報の書き出し失敗が発生した場合にも、ログ情報の書き出し失敗が発生したサーバ内で上記のシーケンスが行われることで、ログ情報の書き出し失敗が検知される。

また、１系のアプリケーション・サーバ３０上で動作する監視モジュールに障害が発生した場合には、図１２に示したシーケンスが行われる。１系の業務処理モジュールが同一のサーバ３０上で動作するログサービスモジュールへハートビートを送信すると(図１２の(1))、ログサービスモジュールは、このハートビートの受信を契機として、ログファイルへのログ情報の書き出し(図１２の(2))、ハートビート送信元の１系の業務処理モジュールへの応答の送信(図１２の(3))、同一のサーバ３０上で動作する監視モジュールへの１系の業務処理モジュールの生存通知の送信(図１０の(4))を順次行う。但し、同一のサーバ３０上で動作する監視モジュールに障害が発生した場合、ログサービスモジュールから送信された生存通知は監視モジュールで受信されない（ログサービスモジュールから監視モジュールへエラー通知が送信された場合も同様）。

これに対して本実施形態では、１系のアプリケーション・サーバ３０上で動作する１系の監視モジュールと２系のアプリケーション・サーバ３０上で動作する２系の監視モジュールが互いにハートビートを送信し合っており、上述した１系の監視モジュールの障害発生は、２系の監視モジュールにおいて、１系の監視モジュールからのハートビートの受信が途絶えることで２系の監視モジュールによって検知され、２系の監視モジュールから監視用コンピュータ５０へ通知される。管理者は、監視用コンピュータ５０を通じて１系の監視モジュールに障害が発生したことを認識することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。

なお、図１２では１系の監視モジュールで障害が発生した場合のシーケンスを示しているが、２系の監視モジュールで障害が発生した場合には、１系の監視モジュールによって２系の監視モジュールの障害発生が検知され、同様に監視用コンピュータ５０への通知が行われる。また、何れかのウェブ・サーバ４０上で動作する監視モジュールで障害が発生した場合にも、上記と同様に他系の監視モジュールによって障害の発生が検知され、監視用コンピュータ５０へ通知される。

一方、各サーバが正常に動作しており、各モジュールの動作状態も正常である場合、データベース・サーバ２０に関しては、図１３に示すシーケンスで障害監視が行われる。すなわち、データベース・サーバ２０上で動作する電文処理モジュールは、ハートビート送信先として設定されたアプリケーション・サーバ３０（１系及び２系のアプリケーション・サーバ３０の何れか一方）上で動作するログサービスモジュールへ定期的にハートビートを送信する(図１３の(1))。ログサービスモジュールは、データベース・サーバ２０上で動作する電文処理モジュールからハートビートを受信する毎に、ログファイルへログ情報を書き出し(図１３の(2))、ハートビート送信元の電文処理モジュールへ応答を送信する(図１３の(3))と共に、自モジュールと同一のサーバ３０上で動作する監視モジュールへ電文処理モジュールの生存通知を送信する(図１３の(4))。

また、データベース・サーバ２０上で動作するログ通信監視モジュールも、上記シーケンスと非同期のタイミングで、ハートビート送信先として設定されたアプリケーション・サーバ３０上で動作するログサービスモジュールへ定期的にハートビートを送信する(図１３の(a))。ログサービスモジュールは、データベース・サーバ２０上で動作するログ通信監視モジュールからハートビートを受信する毎に、ログファイルへログ情報を書き出し(図１３の(b))、ハートビート送信元のログ通信監視モジュールへ応答を送信し (図１３の(c))、自モジュールと同一のサーバ３０上で動作する監視モジュールへログ通信監視モジュールの生存通知を送信する(図１３の(d))。

電文処理モジュール及びログ通信監視モジュールのハートビート送信先として設定されたアプリケーション・サーバ３０上で動作する監視モジュールは、ログサービスモジュールから電文処理モジュールの生存通知を受信すると、最終受信日時テーブルに登録されている電文処理モジュールに対応する最終受信日時を更新し、ログサービスモジュールからログ通信監視モジュールの生存通知を受信すると、最終受信日時テーブルに登録されているログ通信監視モジュールに対応する最終受信日時を更新し、更新後の最終受信日時からの経過時間に基づいて各モジュール（電文処理モジュール及びログ通信監視モジュール）の障害発生を各々監視するが、各モジュールの動作状態が正常である場合、上記の経過時間が閾値に達する前に各モジュールの生存通知をログサービスモジュールから再度受信することで、各モジュールの動作状態が正常であると判断される。

また、電文処理モジュールに障害が発生した場合には、図１４に示すように、電文処理モジュールからログサービスモジュールへのハートビートの送信(図１４の(1))が滞るので、ログサービスモジュールによるログファイルへのログ情報の書き出し(図１４の(2))、電文処理モジュールへのハートビートの応答送信(図１４の(3))、監視モジュールへの電文処理モジュールの生存通知の送信(図１４の(4))も滞ることになる。一方、この例ではログ通信監視モジュールには障害は発生していないので、ログ通信監視モジュールからログサービスモジュールへのハートビートの送信 (図１４の(a))、ログサービスモジュールによるログファイルへログ情報を書き出し(図１４の(b))、ログ通信監視モジュールへの応答送信(図１４の(c))、監視モジュールへのログ通信監視モジュールの生存通知の送信(図１４の(d))は何れも正常に行われる。

これにより、監視モジュールにおいて、電文処理モジュールの生存通知を最後に受信してからの経過時間が閾値以上となることで障害発生が検知され、電文処理モジュールの障害発生が監視用コンピュータ５０へ通知される。監視モジュールにおける電文処理モジュールの生存通知の受信時間間隔が閾値以上となった場合、原因としては電文処理モジュールの障害以外に、ログサービスモジュールの障害も考えられるが、監視用コンピュータ５０を通じて電文処理モジュールの障害発生が通知された管理者は、ログ通信監視モジュールの障害発生が通知されていないことに基づいて、障害が発生したモジュールが電文処理モジュールであることを特定することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。

また、ログ通信監視モジュールに障害が発生した場合は、図１５に示すように、ログ通信監視モジュールからログサービスモジュールへのハートビートの送信(図１５の(a))が滞るので、ログサービスモジュールによるログファイルへのログ情報の書き出し(図１５の(b))、ログ通信監視モジュールへのハートビートの応答送信(図１５の(c))、監視モジュールへのログ通信監視モジュールの生存通知の送信(図１５の(d))も滞ることになる。一方、この例では電文処理モジュールには障害は発生していないので、電文処理モジュールからログサービスモジュールへのハートビートの送信(図１５の(1))、ログサービスモジュールによるログファイルへログ情報を書き出し(図１５の(2))、電文処理モジュールへの応答送信(図１５の(3))、監視モジュールへの電文処理モジュールの生存通知の送信(図１５の(4))は何れも正常に行われる。

これにより、同一のサーバ３０上で動作する監視モジュールにおいて、ログ通信監視モジュールの生存通知を最後に受信してからの経過時間が閾値以上となることで障害発生が検知され、ログ通信監視モジュールの障害発生が監視用コンピュータ５０へ通知される。監視モジュールにおけるログ通信監視モジュールの生存通知の受信時間間隔が閾値以上となった場合、原因としてはログ通信監視モジュールの障害以外に、ログサービスモジュールの障害も考えられるが、監視用コンピュータ５０を通じてログ通信監視モジュールの障害発生が通知された管理者は、電文処理モジュールの障害発生が通知されていないことに基づいて、障害が発生したモジュールがログ通信監視モジュールであると特定することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。

また、電文処理モジュール及びログ通信監視モジュールのハートビート送信先として設定されたアプリケーション・サーバ３０上で動作するログサービスモジュールに障害が発生した場合には、図１６に示すように、電文処理モジュールからログサービスモジュールへのハートビートの送信(図１６の(1))が滞り、ログサービスモジュールによるログファイルへのログ情報の書き出し(図１６の(2))、電文処理モジュールへのハートビートの応答送信(図１６の(3))、監視モジュールへの電文処理モジュールの生存通知の送信(図１６の(4))も滞る。また、同様にログ通信監視モジュールからログサービスモジュールへのハートビートの送信(図１６の(a))も滞り、ログサービスモジュールによるログファイルへのログ情報の書き出し(図１６の(b))、ログ通信監視モジュールへのハートビートの応答送信(図１６の(c))、監視モジュールへのログ通信監視モジュールの生存通知の送信(図１６の(d))も滞る。

この場合、ログ通信監視モジュールにおいて、ログサービスモジュールへハートビートをｎ回再送信してもログサービスモジュールから応答を受信できないことに基づいて、ログサービスモジュールの障害発生が検知され、ログ通信監視モジュールにより、電文処理モジュール及びログ通信監視モジュールのハートビート送信先が、他系のアプリケーション・サーバ３０へ切り替えされる。また、ログサービスモジュールに障害が発生した場合、同一のサーバ３０上で動作する監視モジュールでは、ログサービスから生存通知を受信する各モジュールについて、生存通知を最後に受信してからの経過時間が全て閾値以上となり、各モジュールの障害発生が監視用コンピュータ５０へ通知される。監視用コンピュータ５０を通じて各モジュールの障害発生が通知された管理者は、各モジュールの障害発生が全て通知されたことに基づいて、障害が発生したモジュールがログサービスモジュールであると特定することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。

上述したように、本実施形態に係るコンピュータ・システム１０は、個々のアプリケーション・サーバ３０上で動作する個々の業務処理モジュール及び個々のウェブ・サーバ４０上で動作する個々の画面制御モジュールについてのログ情報の収集（ログファイルへのログ情報の書き出し）及び障害監視が、個々の業務処理モジュール又は個々の画面制御モジュールと同一のサーバ上で動作するログサービスモジュール及び監視モジュールによって行われるので、個々の業務処理モジュール及び個々の画面制御モジュールについてのログ情報の収集及び障害監視が個々のサーバ内で完結しており、個々の業務処理モジュール及び個々の画面制御モジュールについてログ情報の収集及び障害監視を各々行うための各サーバ間の通信が不要となる。また、個々のサーバ上で動作するログサービスモジュール及び監視モジュールは、ログ情報の収集及び障害監視の対象モジュール（同一のサーバ上で動作する業務処理モジュール又は画面制御モジュール）からのハートビートの受信を契機として、ログファイルへのログ情報の書き出し及び障害監視のための最終受信日時テーブルの更新を行うので、前記対象モジュールとの間で、ログ情報書き出しのための通信と障害監視のための通信を別々に行う場合と比較して、同一サーバ上で動作するモジュール間の通信回数も削減することができる。

従って、本実施形態に係るコンピュータ・システム１０は、各サーバ上で動作する各モジュール（業務処理モジュール又は画面制御モジュール）について障害監視及びログ情報の収集を各々行うにも拘わらず、各サーバ間及び同一サーバ上で動作するモジュール間のトラフィック量の増大を抑制することができる。また前述のように、各サーバ上で動作する業務処理モジュールや画面制御モジュールについてのログ情報の収集及び障害監視が各サーバ内で完結しているために、各サーバ間のトラフィック量の増大が抑制されることで、一部のサーバで処理遅延等の障害が発生した場合にもコンピュータ・システム全体に波及し難いので耐障害性が高く、かつ、コンピュータ・システム１０にアプリケーション・サーバ３０やウェブ・サーバ４０を新たに追加することも容易であるので、拡張性も高いという利点も有している。

更に、本実施形態に係るコンピュータ・システム１０では、本発明に係るアプリケーション手段に相当する各モジュール（業務処理モジュール及び画面制御モジュール）が自発的かつ定期的にハートビートを送信するので、ハートビートの受信側で各モジュールの動作状態の判別が可能になると共に、各モジュールが外部から所定の情報を受信する度にハートビートを送信する方式と比較して、各モジュールの動作状態判別のために各モジュールに大きな負荷が加わることで各モジュールが定常的に行う処理に遅延等が生ずることも回避することができる。

なお、上記ではデータベース・サーバ２０に加わる負荷を抑制したいという要求を満たすために、データベース・サーバ２０にはログサービスモジュール及び監視モジュールを設けず、データベース・サーバ２０上で動作する電文処理モジュール及びログ通信監視モジュールが、アプリケーション・サーバ３０上で動作するログサービスモジュールへハートビートを送信する構成を例に説明したが、これに限定されるものではなく、データベース・サーバ２０にログサービスモジュール及び監視モジュールを設け、電文処理モジュール及びログ通信監視モジュールが自モジュールと同一のサーバ２０上で動作するログサービスモジュールへハートビートを送信するように構成してもよい。この態様では、電文処理モジュール及びログ通信監視モジュールも本発明に係るアプリケーション手段として機能し、データベース・サーバ２０も本発明に係る業務処理用コンピュータとして機能することになる。

また、上記ではログファイルに書き出されるログ情報及びエラーログ情報のうち、エラーログ情報のみをデータベース・サーバ２０へ転送してログテーブルに書き出すことで、端末装置１２からの閲覧対象としていたが、これに限定されるものではなく、ログ情報もデータベース・サーバ２０へ転送してログテーブルに書き出すことで、端末装置１２からの閲覧対象にログ情報も加えてもよい
また、上記では本発明に係るコンピュータ・システムとして、第１のコンピュータ・システム１４と第２のコンピュータ・システム１６の間に設けられたコンピュータ・システム１０を例に説明したが、本発明はこれに限定されるものではなく、他のコンピュータ・システムと接続されていない独立したコンピュータ・システムであってもよい。

更に、上記では本発明に係る監視手段に相当する処理のうち、ログファイルにログ情報やエラーログ情報を書き出す処理をログサービスモジュールによって行い、監視対象のモジュールの生存通知（ハートビート）の受信時間間隔に基づいて監視対象のモジュールの動作状態が正常か否かを判定する処理を監視モジュールによって行う態様を説明したが、本発明はこれに限定されるものではなく、ログサービスモジュールと監視モジュールを一体化し、上記各処理を単一のモジュールによって行うようにしてもよい。

また、上記では本発明に係るアプリケーション手段に相当する各モジュール（業務処理モジュール及び画面制御モジュール）が自発的かつ定期的にハートビートを送信する態様を説明したが、これに限定されるものではなく、外部から所定の情報を受信する度にハートビートを送信するように上記各モジュールを構成することも本発明の権利範囲に含まれる。但し、上記構成では各モジュールが定常的に行う処理に遅延等が生ずる可能性があるので、各モジュールが自発的かつ定期的にハートビートを送信するように各モジュールを構成することが望ましい。

本実施形態に係るコンピュータ・システムの概略ブロック図である。 業務処理モジュールで実行される業務処理を示すフローチャートである。 ログサービスモジュールで実行されるログサービス処理を示すフローチャートである。 監視モジュールで実行される障害監視処理を示すフローチャートである。 ログ回収モジュールで実行されるログ回収処理を示すフローチャートである。 ログ通信監視モジュールで実行されるログ通信監視処理を示すフローチャートである。 通常時の障害監視シーケンスを示す説明図である。 アプリケーション・サーバの業務処理モジュールでエラーが発生した場合のエラー検知シーケンスを示す説明図である。 アプリケーション・サーバの業務処理モジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。 アプリケーション・サーバのログサービスモジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。 ログファイルへのログ情報の書き出し障害が発生した場合の障害検知シーケンスを示す説明図である。 アプリケーション・サーバの監視モジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。 データベース・サーバに関する通常時の障害監視シーケンスを示す説明図である。 データベース・サーバの電文処理モジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。 データベース・サーバのログ通信監視モジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。 アプリケーション・サーバのログサービスモジュールに障害が発生した場合の障害検知シーケンスを示す説明図である。

符号の説明

１０ コンピュータ・システム
２０ データベース・サーバ
２６ ＨＤＤ
３０ アプリケーション・サーバ
３６ ＨＤＤ
４０ ウェブ・サーバ
４６ ＨＤＤ
５０ 監視用コンピュータ

Claims (8)

1. 各々アプリケーション・プログラムを実行することで所定の業務処理を行うアプリケーション手段として各々機能する複数台の業務処理用コンピュータと、個々の業務処理用コンピュータと通信回線を介して各々接続された監視用コンピュータを含んで構成されたコンピュータ・システムであって、
   前記業務処理用コンピュータ上で動作し、同一の業務処理用コンピュータ上で動作するアプリケーション手段との間で定期的に通信を行い、当該通信によって判別した前記同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態を前記同一の業務処理用コンピュータに設けられた第２記憶手段にログ情報として記憶させると共に、前記定期的な通信が途絶えたことに基づいて前記同一の業務処理用コンピュータ上で動作するアプリケーション手段の動作状態が異常と判断した場合に前記監視用コンピュータへ通知する監視手段が前記複数台の業務処理用コンピュータに各々設けられていることを特徴とするコンピュータ・システム。
2. 前記アプリケーション手段は、前記所定の業務処理と並行して、同一の業務処理用コンピュータ上で動作する前記監視手段へ生存通知を送信する送信処理を定期的に行い、
   前記監視手段は、同一の業務処理用コンピュータ上で動作する前記アプリケーション手段より最後に生存通知を受信してからの経過時間が閾値以上の場合に、前記定期的な通信が途絶えたと判断し、前記アプリケーション手段の動作状態が異常と判断することを特徴とする請求項１記載のコンピュータ・システム。
3. 前記監視手段は、別の特定の業務処理用コンピュータ上で動作する監視手段へ定期的に生存通知を送信すると共に、前記別の特定の業務処理用コンピュータ上で動作する監視手段より最後に生存通知を受信してからの経過時間が閾値以上か否かを判断することで、前記別の特定の業務処理用コンピュータ又は前記別の特定の業務処理用コンピュータ上で動作する監視手段の動作状態を判別し、前記別の特定の業務処理用コンピュータ又は前記別の特定の業務処理用コンピュータ上で動作する監視手段の動作状態が異常と判断した場合に前記監視用コンピュータへ通知することを特徴とする請求項１記載のコンピュータ・システム。
4. 前記監視手段は、前記生存通知を受信する毎に受信時刻を前記同一の業務処理用コンピュータに設けられた第１記憶手段に記憶させ、前記第１記憶手段に記憶させた前記受信時刻に基づいて最後に生存通知を受信してからの経過時間を判断することを特徴とする請求項２又は請求項３記載のコンピュータ・システム。
5. 前記監視手段は、同一の業務処理用コンピュータ上で動作する前記アプリケーション手段より生存通知を受信する毎に、前記生存通知の受信時刻を含む情報を、前記監視手段が動作するコンピュータに設けられた第２記憶手段にログ情報として記憶させることを特徴とする請求項２記載のコンピュータ・システム。
6. 前記アプリケーション手段は、前記所定の業務処理を行ってエラーが発生した場合に、同一の業務処理用コンピュータ上で動作する前記監視手段へ前記エラーの内容を表すエラー情報を送信し、
   前記監視手段は、同一の業務処理用コンピュータ上で動作する前記アプリケーション手段から前記エラー情報を受信した場合に、受信した前記エラー情報を前記同一の業務処理用コンピュータに設けられた第２記憶手段にエラーログ情報として記憶させると共に、前記監視用コンピュータへエラーの発生を通知することを特徴とする請求項１記載のコンピュータ・システム。
7. 前記複数台の業務処理用コンピュータと通信回線を介して各々接続されたログ情報管理用コンピュータを更に備え、
   前記業務処理用コンピュータ上で動作し、同一の業務処理用コンピュータに設けられた前記第２記憶手段に記憶されているエラーログ情報を前記ログ情報管理用コンピュータへ定期的に転送し、前記ログ情報管理用コンピュータに設けられた第３記憶手段に記憶させる転送手段が前記複数台の業務処理用コンピュータに各々設けられていることを特徴とする請求項６記載のコンピュータ・システム。
8. 前記ログ情報管理用コンピュータには、前記ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を前記第３記憶手段から読み出して配信要求元の前記端末装置へ転送するログ情報管理手段が設けられていることを特徴とする請求項７記載のコンピュータ・システム。

Images