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

Description

本発明はコンピュータ・システムに係り、特に、アプリケーション・プログラムが業務処理用コンピュータによって実行されることで業務処理用コンピュータ上で所定の業務処理が行われるコンピュータ・システムに関する。

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

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

上記の特許文献１，２の技術は、何れもコンピュータ・システム内の別のコンピュータが監視対象のコンピュータへ何らかの情報を送信し、監視対象のコンピュータから応答が有ったか否かに基づいて監視対象のコンピュータにおける障害の発生を検知する技術であり、監視対象のコンピュータに電源断により稼働が停止した等の障害が発生した場合には検知可能である。しかし、コンピュータ上では通常、オペレーティング・システムのプログラムを含む複数のプログラムが並列に実行されており、コンピュータ自体は正常に稼働しているものの、何らかの理由で、実行中の複数のプログラムのうちの一部のプログラムの動作（当該プログラムによる処理）が滞ってしまう状況も生じ得る。これに対し特許文献１，２に記載の技術では、監視対象のコンピュータ上で実行されている複数のプログラムのうち、特定のアプリケーション・プログラムが正常に動作しているか否かを確認することはできない。

また、監視対象のコンピュータ上で動作しているオペレーティングシステムに対し、特定アプリケーションが監視対象のコンピュータ上でプロセスとして実行中か否かを外部から問い合わせれば、特定アプリケーションが監視対象のコンピュータ上でプロセスとして実行中か否かを確認することは可能である。しかし、特定アプリケーションがプロセスとして実行中であっても動作（処理）が滞ってしまっている状況も生じ得るので、特定アプリケーションが監視対象のコンピュータ上でプロセスとして実行中であったとしても、特定アプリケーションが正常に動作している保障はない。

本発明は上記事実を考慮して成されたもので、対応するプログラムがコンピュータによって実行されることで実現される特定アプリケーションの動作状態を判別できるコンピュータ・システムを得ることが目的である。

上記目的を達成するために請求項１記載の発明に係るコンピュータ・システムは、対応するアプリケーション・プログラムが業務処理用コンピュータによって実行されることで前記業務処理用コンピュータ上で動作し、処理対象の電文が有るか否かを判定し、処理対象の電文が有る場合は処理対象の電文に応じた所定の業務処理を行い、生存通知を送信する送信処理を前回行ってから前記所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は前記送信処理を行い、前記送信処理を前回行ってから前記所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、前記送信処理を前回行ってから前記所定の業務処理を行った処理対象の電文の数が一定値に達した場合は前記送信処理を行うアプリケーション手段と、前記業務処理用コンピュータ又は前記業務処理用コンピュータと通信回線を介して接続された別のコンピュータ上で動作し、前記アプリケーション手段より前記生存通知を受信すると共に、前記アプリケーション手段より最後に生存通知を受信してからの経過時間に基づいて前記アプリケーション手段の動作状態を判別する監視手段と、を含んで構成されている。

請求項１記載の発明に係るコンピュータ・システムは、１台のコンピュータ（業務処理用コンピュータ）又は業務処理用コンピュータを含む複数台のコンピュータを含んで構成されている。業務処理用コンピュータ上では、対応するアプリケーション・プログラムが業務処理用コンピュータによって実行されることで、処理対象の電文が有るか否かを判定し、処理対象の電文が有る場合は処理対象の電文に応じた所定の業務処理を行うアプリケーション手段が動作しており、監視手段は、業務処理用コンピュータ又は業務処理用コンピュータと通信回線を介して接続された別のコンピュータ上で動作している。ここで、請求項１記載の発明に係るアプリケーション手段は、生存通知を送信する送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は送信処理を行い、送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、送信処理を前回行ってから所定の業務処理を行った処理対象の電文の数が一定値に達した場合は送信処理を行う。また、請求項１記載の発明に係る監視手段は、アプリケーション手段より生存通知を受信すると共に、アプリケーション手段より最後に生存通知を受信してからの経過時間に基づいてアプリケーション手段の動作状態を判別する。

このように、請求項１記載の発明では、生存通知を送信する送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は送信処理を行い、送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、送信処理を前回行ってから所定の業務処理を行った処理対象の電文の数が一定値に達した場合は送信処理を行うようにアプリケーション手段を構成することで、アプリケーション手段から生存通知を定期的に送信させているので、アプリケーション手段から生存通知が定期的に送信されている場合には、アプリケーション手段の動作状態は正常と判断できる一方で、アプリケーション手段からの生存通知の送信が途絶えたり、生存通知の送信間隔が非常に大きくなった場合には、アプリケーション手段が動作が滞っている状態と判断できる。上記に基づき、アプリケーション手段からの生存通知を受信する監視手段は、アプリケーション手段より最後に生存通知を受信してからの経過時間に基づいてアプリケーション手段の動作状態を判別するので、請求項１記載の発明によれば、対応するプログラム（アプリケーション・プログラム）がコンピュータ（業務処理用コンピュータ）によって実行されることで実現される特定アプリケーション（アプリケーション手段）の動作状態を判別することができる。

なお、特定アプリケーションの動作状態を判別することは、特定アプリケーションに対して監視手段が動作状態を問い合わせる問い合わせ情報を送信し、問い合わせ情報に対する応答を特定アプリケーションから受信したか否か等を判断することで行うことも可能であるが、この場合、問い合わせ情報を受信したか否かを常時監視し、問い合わせ情報を受信した場合には応答を送信する処理を、本来行うべき業務処理と並行して行うように特定アプリケーションを構成する必要があるので、特定アプリケーションに負荷が加わり、特定アプリケーションが本来行うべき業務処理の遅延等が生ずる恐れがある。

これに対して請求項１記載の発明において、アプリケーション手段を、生存通知を送信する送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は送信処理を行い、送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、送信処理を前回行ってから所定の業務処理を行った処理対象の電文の数が一定値に達した場合は送信処理を行うように構成することは、例えば、送信処理を行う毎に、所定時間をタイマ値とするタイマをスタートさせると共にカウンタの値をリセットし、処理対象の電文が有ると判定する度に、処理対象の単一の電文に応じた処理の業務処理を行ってカウンタの値を更新すると共に前記タイマを再スタートさせ、前記タイマがタイムアウトするか前記カウンタの値が一定値になった場合に前記送信処理を行う、というごく簡単な処理をアプリケーション手段に行わせることによって実現することができるので、業務処理の処理効率の低下やアプリケーション手段による処理のオーバヘッドの増大を招くことも回避することができる。なお、請求項１記載の発明において、監視手段がアプリケーション手段から生存通知を受信した場合、受信した生存通知に対する応答をアプリケーション手段へ送信するように構成することが望ましい。

また、請求項１記載の発明において、監視手段は、例えば請求項２に記載したように、アプリケーション手段より生存通知を受信する毎に、生存通知の受信時刻を含む情報を第２記憶手段にログ情報として記憶させるように構成することが好ましい。

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

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

また、請求項３記載の発明において、監視手段が動作するコンピュータと通信回線を介して接続された監視用コンピュータがコンピュータ・システムに設けられている場合、監視手段は、例えば請求項４に記載したように、アプリケーション手段からエラー情報を受信した場合に、監視用コンピュータへエラーの発生を通知するように構成することが好ましい。これにより、コンピュータ・システムを管理する管理者が、所定の業務処理でエラーが発生したことを監視用コンピュータを通じて認識することが可能となり、第２記憶手段に記憶されたエラーログ情報の参照・解析／分析等を行って必要な対策を講ずることができる。

また、請求項２に記載のログ情報はコンピュータ・システムを管理する管理者が参照する情報であるが、アプリケーション手段が行う処理の業務処理が、ユーザからの依頼に従って行う処理である場合、請求項３記載の発明に係るエラーログ情報をユーザが閲覧・確認したいというニーズが生ずる。請求項３記載の発明において、アプリケーション手段が各々動作する複数台の業務処理用コンピュータと、複数台の業務処理用コンピュータと通信回線を介して各々接続された監視用コンピュータ及びログ情報管理用コンピュータが各々設けられている場合、上記のニーズを満たすために、例えば請求項５に記載したように、監視手段は、ログ情報管理用コンピュータ上で動作し、複数台の業務処理用コンピュータ上で動作する個々のアプリケーション手段から生存通知及びエラー情報を各々受信し、ログ情報管理用コンピュータに設けられた第２記憶手段にログ情報又はエラーログ情報として記憶させる第１監視手段、及び、少なくとも１つの業務処理用コンピュータ上で動作し、第１監視手段が生存通知又はエラー情報を受信する毎に第１監視手段から生存通知又はエラー情報が転送され、個々のアプリケーション手段から第１監視手段を経由して生存通知を受信した時間間隔に基づいて個々のアプリケーション手段の動作状態を判別し、任意のアプリケーション手段の動作状態が異常と判断した場合に監視用コンピュータへ通知すると共に、任意のアプリケーション手段から第１監視手段を経由してエラー情報を受信した場合に監視用コンピュータへエラーの発生を通知する第２監視手段から成り、ログ情報管理用コンピュータには、ログ情報管理用コンピュータ上で動作し、ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を第２記憶手段から読み出して配信要求元の端末装置へ転送するログ情報管理手段が設けられていることが好ましい。

請求項５記載の発明では、ログ情報管理用コンピュータ上で動作する第１監視手段が、複数台の業務処理用コンピュータ上で動作するアプリケーション手段から生存通知及びエラー情報を各々受信することで、個々の業務処理用コンピュータのアプリケーション手段に対応するエラーログ情報（及びログ情報）が、ログ情報管理用コンピュータに設けられた第２記憶手段に一元管理されることになる。また、端末装置からエラーログ情報の配信が要求されると、配信対象のエラーログ情報が第２記憶手段から読み出されて配信要求元の端末装置へ転送されるので、エラーログ情報の閲覧・確認を所望しているユーザが、端末装置を介してエラーログ情報をオンラインで閲覧・確認することが可能となり、エラーログ情報の閲覧・確認を所望しているユーザの利便性が向上する。また、個々の業務処理用コンピュータのアプリケーション手段に対応するエラーログ情報がログ情報管理用コンピュータに一元管理され、閲覧に供せられることで、閲覧・確認対象のエラーログ情報に対応するエラーが、複数台の業務処理用コンピュータのうちの何れの業務処理用コンピュータで行われた業務処理で発生したエラーかをユーザが意識する必要もなくなる。

また、請求項３記載の発明において、アプリケーション手段が各々動作する複数台の業務処理用コンピュータと、複数台の業務処理用コンピュータと通信回線を介して各々接続されたログ情報管理用コンピュータが各々設けられている場合、前述のニーズを満たすために、例えば請求項６に記載したように、監視手段は、個々の業務処理用コンピュータ上で各々動作し、同一の業務処理用コンピュータ上で動作するアプリケーション手段から生存通知及び前記エラー情報を各々受信し、同一の業務処理用コンピュータに設けられた第２記憶手段にログ情報又はエラーログ情報として記憶させ、個々の業務処理用コンピュータには、個々の業務処理用コンピュータ上で各々動作し、同一の業務処理用コンピュータに設けられた第２記憶手段に記憶されているエラーログ情報をログ情報管理用コンピュータへ定期的に転送する転送手段が設けられており、ログ情報管理用コンピュータには、ログ情報管理用コンピュータ上で動作し、任意の前記業務処理用コンピュータからエラーログ情報を受信する毎に、ログ情報管理用コンピュータに設けられた第３記憶手段に受信したエラーログ情報を記憶させると共に、ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を第３記憶手段から読み出して配信要求元の端末装置へ転送するログ情報管理手段が設けられていることがより好ましい。

請求項６記載の発明では、個々の業務処理用コンピュータのアプリケーション手段に対応するエラーログ情報が、個々の業務処理用コンピュータに設けられた第２記憶手段に一旦記憶された後に、転送手段によってログ情報管理用コンピュータへ転送されることで、ログ情報管理用コンピュータに設けられた第３記憶手段に一元管理される。また、端末装置からエラーログ情報の配信が要求されると、配信対象のエラーログ情報が第３記憶手段から読み出されて配信要求元の端末装置へ転送されるので、請求項５記載の発明と同様に、エラーログ情報の閲覧・確認を所望しているユーザが、端末装置を介してエラーログ情報をオンラインで閲覧・確認することが可能となり、エラーログ情報の閲覧・確認を所望しているユーザの利便性が向上すると共に、閲覧・確認対象のエラーログ情報に対応するエラーが、複数台の業務処理用コンピュータのうちの何れの業務処理用コンピュータで行われた業務処理で発生したエラーかをユーザが意識する必要もなくなる。

また、先に説明した請求項５記載の発明では、第１監視手段がログ情報管理用コンピュータ上で動作し、個々の業務処理用コンピュータとログ情報管理用コンピュータの間で、生存通知が定常的に送受されると共にエラー発生時にはエラー情報も送受されると共に、第１監視手段が生存通知又はエラー情報を受信する毎に、業務処理用コンピュータ上で動作する第２監視手段に生存通知又はエラー情報が転送されるので、各コンピュータ間のトラフィック量が増大し、一部のコンピュータで処理遅延等の障害が発生した場合にコンピュータ・システム全体に波及し易いという欠点がある。これに対して請求項６記載の発明では、個々の業務処理用コンピュータ上で動作するアプリケーション手段についてのログ情報の収集・第２記憶手段への記憶及び障害監視が、個々のアプリケーション手段と同一の業務処理用コンピュータ上で動作する監視手段によって行われ、個々のアプリケーション手段についてのログ情報の収集・第２記憶手段への記憶及び障害監視が個々の業務処理用コンピュータ内で完結しているので、コンピュータ間のトラフィック量の増大を抑制することができ、コンピュータ・システムの耐障害性を向上させることができる（一部のコンピュータで処理遅延等の障害が発生してもコンピュータ・システム全体に波及し難くなる）。また、コンピュータ・システムに新たな業務処理用コンピュータを追加することも容易に行うことができ、コンピュータ・システムの拡張性も向上させることができる。

以上説明したように本発明は、業務処理用コンピュータ上で動作し処理対象の電文が有るか否かを判定し、処理対象の電文が有る場合は処理対象の電文に応じた所定の業務処理を行うアプリケーション手段を、生存通知を送信する送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は送信処理を行い、送信処理を前回行ってから所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、送信処理を前回行ってから所定の業務処理を行った処理対象の電文の数が一定値に達した場合は送信処理を行うように構成し、アプリケーション手段より最後に生存通知を受信してからの経過時間に基づいてアプリケーション手段の動作状態を判別するようにしたので、対応するプログラムがコンピュータによって実行されることで実現される特定アプリケーションの動作状態を判別できる、という優れた効果を有する。

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

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

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

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

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

また、アプリケーション・サーバ３０は、ＣＰＵ３２、ＲＡＭ等から成るメモリ３４、ＨＤＤ３６、ネットワークＩ／Ｆ部３８を備えており、ネットワークＩ／Ｆ部３８を介して通信回線５２に接続されている。アプリケーション・サーバ３０のＨＤＤ３６には、ＣＰＵ３２が業務処理（後述）を行うための業務処理プログラムと、ＣＰＵ３２が障害監視処理（後述）を行うための障害監視プログラムが各々インストールされている。なお、アプリケーション・サーバ３０は本発明に係る業務処理用コンピュータに、業務処理プログラムは本発明に係るアプリケーション・プログラムに対応しており、ＣＰＵ３２が業務処理プログラムを実行することでアプリケーション・サーバ３０上で動作する処理モジュール（業務処理モジュール）は本発明に係るアプリケーション手段（詳しくは請求項１，５に記載のアプリケーション手段）に対応している。また、ＣＰＵ３２が障害監視プログラムを実行することでアプリケーション・サーバ３０上で動作する処理モジュール（監視モジュール）は本発明に係る監視手段（詳しくは、請求項４に記載の監視手段及び請求項５に記載の第２監視手段）に対応している。

また、ウェブ・サーバ４０は、ＣＰＵ４２、ＲＡＭ等から成るメモリ４４、ＨＤＤ４６、ネットワークＩ／Ｆ部４８を備えており、ネットワークＩ／Ｆ部４８を介して通信回線５２に接続されている。ウェブ・サーバ４０のＨＤＤ４６には、ＣＰＵ４２がログサービス処理（後述）を行うためのログサービスプログラムと、ＣＰＵ４２が画面制御処理を行うための画面制御プログラムが各々インストールされており、ログ情報及びエラーログ情報を格納するためのログファイルも記憶されている。ＣＰＵ４２がログサービスプログラムを実行することでウェブ・サーバ４０上で動作する処理モジュール（ログサービスモジュール）は、アプリケーション・サーバ３０上で動作する監視モジュールと共に本発明に係る監視手段に対応しており、詳しくは請求項２，３に記載の監視手段及び請求項５に記載の第１監視手段に対応している。また、本実施形態に係るコンピュータ・システム１０は本発明に係るコンピュータ・システム、より詳しくは請求項５に記載のコンピュータ・システムに対応しており、ウェブ・サーバ４０は請求項５に記載のログ情報管理用コンピュータに対応している。

ログサービスモジュールは、個々のアプリケーション・サーバ３０上で業務処理モジュールが正常に動作している間、個々の業務処理モジュールに対応するログ情報をログファイルに格納すると共に、個々の業務処理モジュールからエラーの発生が通知される毎に、通知されたエラーをエラーログ情報としてログファイルに格納する処理を行うが（詳細は後述）、ウェブ・サーバ４０は、ログファイルに格納された各情報のうちのエラーログ情報を、第１のコンピュータ・システム１４の端末装置１２を介して閲覧することを可能とする機能を提供している。

この機能は、ＣＰＵ４２が画面制御プログラムを実行することでウェブ・サーバ４０上で動作する処理モジュール（画面制御モジュール）によって実現され、画面制御モジュールは、端末装置１２を介してエラーログ情報の閲覧が要求された場合に、閲覧対象のエラーログ情報をログファイルから読み出し、読み出したエラーログ情報を端末装置１２のディスプレイに表示させるための表示画面を生成し、生成した表示画面の情報を閲覧要求元の端末装置１２へ配信する。これにより、端末装置１２のディスプレイにエラーログ情報が表示される。なお、上記の画面制御モジュールは請求項５に記載のログ情報管理手段に対応している。

また、監視用コンピュータ５０はコンピュータ・システム１０を管理する管理者によって使用されるコンピュータであり、請求項６に記載の監視用コンピュータに対応している。

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

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

ステップ６２の判定が肯定された場合はステップ６４へ移行し、１系のウェブ・サーバ４０上で動作しているログサービスモジュール（１系のログサービスモジュール）と通信可能な状態か否か判定する。１系のウェブ・サーバ４０がダウンしている、或いは自サーバ３０と１系のウェブ・サーバ４０との間の通信回線に障害が発生している等の原因で１系のログサービスモジュールとの間にリンクが確立できない場合は、上記判定が否定されステップ６５で１系のログサービスの障害発生を表す１系障害フラグに１をセットした後にステップ７４へ移行するが、１系のログサービスモジュールと通信可能な状態であれば、ステップ６４の判定が肯定されてステップ６６へ移行し、１系のウェブ・サーバ４０上で動作している１系のログサービスモジュールへハートビートを送信する。なお、このハートビートは自モジュールの動作状態が正常であることを表す所定桁数のメッセージＩＤを含む情報であり、本発明に係るアプリケーション手段が送信する生存通知に対応している。

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

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

また、１系のログサービスモジュールからハートビートに対する応答を受信すると、ステップ６８の判定が肯定されてステップ７４へ移行し、２系のウェブ・サーバ４０上で動作しているログサービスモジュール（２系のログサービスモジュール）と通信可能な状態か否か判定する。この判定が否定された場合は、２系のログサービスモジュールへのハートビートの送信を行うことなくステップ７５で２系のログサービスの障害発生を表す２系障害フラグに１をセットした後にステップ８０へ移行するが、２系のログサービスモジュールと通信可能な状態であれば、ステップ７４の判定が肯定されてステップ７６へ移行し、２系のログサービスモジュールへハートビートを送信する。このハートビートも本発明に係るアプリケーション手段が送信する生存通知に対応している。

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

そして２系のログサービスモジュールからハートビートに対する応答を受信すると、ステップ７７の判定が肯定されてステップ８０へ移行し、１系障害フラグ及び２系障害フラグの一方に１がセットされているか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ６０へ戻るが、判定が肯定された場合はステップ８１へ移行し、障害が発生していないログサービスモジュールに対し、他系のログサービスモジュール（１がセットされている障害フラグに対応するログサービスモジュール）に障害が発生していることを通知する障害通知を送信する。次のステップ８２では、障害が発生していないログサービスモジュールから障害通知に対する応答を受信したか否か判定し、判定が肯定される迄ステップ８２を繰り返す。そして、応答を受信すると判定が肯定されてステップ６０に戻る。

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

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

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

また、１系のログサービスモジュールと通信不能の場合又はエラー情報に対する応答を１系のログサービスモジュールから受信した場合は、２系のログサービスモジュールと通信可能か否か判定し(ステップ１００)、通信可能であれば前述のエラー情報を２系のログサービスモジュールへ送信し(ステップ１０２)、エラー情報に対する応答を２系のログサービスモジュールから受信したか否か判定し(ステップ１０４)、応答を未受信であればエラー情報の送信から所定時間ｔ２以上経過したか否か判定し(ステップ１０６)、エラー情報の送信から所定時間ｔ２以上経過する毎に２系のログサービスモジュールへのエラー情報の再送信を行う(ステップ１０８)。

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

なお、データベース・サーバ２０上で動作する電文処理モジュールにおいても、上記と同様に、受信電文が存在しないために電文処理を行っていない時には、所定時間ｔ１周期で１系及び２系のログサービスモジュールへのハートビートの送信が行われ、受信電文に対して電文処理を行っている時には、所定件の受信電文に対して電文処理を行う毎に、１系及び２系のログサービスモジュールへのハートビートの送信が行われる。

次に１系で動作する１系のログサービスモジュール及び２系のウェブ・サーバ４０上で動作する２系のログサービスモジュールによって各々実現されるログサービス処理（図３参照）、及び、１系のアプリケーション・サーバ３０上で動作する１系の監視モジュール及び２系のアプリケーション・サーバ３０上で動作する２系の監視モジュールによって各々実現される障害監視処理（図４参照）について順に説明する。なお、ログサービス処理及び障害監視処理は本発明に係る監視手段に相当する処理である。

ログサービスモジュールによって実現されるログサービス処理では、まずステップ１２０において、他のモジュールから何らかの情報を受信したか否か判定し、判定が肯定される迄ステップ１２０を繰り返す。他のモジュール（アプリケーション・サーバ３０上で動作する業務処理モジュール又はデータベース・サーバ２０上で動作する電文処理モジュール）から情報（ハートビート又はエラー情報又は障害通知）を受信すると、ステップ１２０の判定が肯定されてステップ１２１へ移行し、受信した情報が、業務処理モジュールから送信された障害通知（他系のログサービスモジュールの障害を通知する情報）か否か判定する。判定が肯定された場合はステップ１３４へ移行するが、判定が否定された場合はステップ１２２へ移行し、受信した情報が業務処理モジュール又は電文処理モジュールから送信されたハートビートであれば、ハートビートの受信時刻やハートビートに含まれるメッセージＩＤ、ハートビートの送信元識別情報等をログ情報としてログファイルに書き出し、受信した情報が業務処理モジュールから送信されたエラー情報であれば、受信したエラー情報に受信時刻や送信元識別情報等を付加し、エラーログ情報としてログファイルに書き出す。なお、ログファイルを記憶するウェブ・サーバ４０のＨＤＤ４６は請求項２，４，５に記載の第２記憶手段に対応している。

次のステップ１２４では、ステップ１２２でログファイルへのログ情報又はエラーログ情報の書き出しが成功したか否か判定する。判定が肯定された場合はステップ１３４へ移行し、１系のアプリケーション・サーバ３０上で動作している監視モジュール（１系の監視モジュール）と通信可能な状態か否か判定する。１系の監視モジュールとの間にリンクが確立できない場合は上記判定が否定されてステップ１３８へ移行するが、１系の監視モジュールと通信可能な状態であれば、ステップ１３４の判定が肯定されてステップ１３６へ移行し、１系の監視モジュールに対して、先に受信した情報がハートビートであれば、当該ハートビートの送信元のモジュールが生存している（動作している）ことを意味する生存通知を送信し、先に受信した情報がエラー情報であれば、当該エラー情報の送信元の業務処理モジュールでエラーが発生したことを意味するエラー通知を送信し、先に受信した情報が障害通知であれば、他系（自モジュールが１系であれば２系、自モジュールが２系であれば１系）のログサービスモジュールで障害が発生したことを意味するエラー通知を送信する。

次のステップ１３８では、２系のアプリケーション・サーバ３０上で動作している監視モジュール（２系の監視モジュール）と通信可能な状態か否か判定する。２系の監視モジュールとの間にリンクが確立できない場合は上記判定が否定されてステップ１４２へ移行するが、２系の監視モジュールと通信可能な状態であれば、ステップ１３８の判定が肯定されてステップ１４０へ移行し、２系の監視モジュールに対して先のステップ１３６と同様に生存通知又はエラー通知を送信する。そして、ステップ１４２では受信情報（ハートビート又はエラー情報又は障害通知）の送信元（１系の業務処理モジュール又は２系の業務処理モジュール又は電文処理モジュール）へ応答を送信し、ステップ１２０に戻る。

また、先のステップ１２２においてＨＤＤ４６の障害等の理由でログファイルへのログ情報又はエラーログ情報の書き出しに失敗した場合には、ステップ１２４の判定が否定されてステップ１２６へ移行し、１系の監視モジュールと通信可能な状態か否か判定する。判定が否定された場合はステップ１３０へ移行するが、判定が肯定された場合は次のステップ１２８において、ログファイルへの情報の書き出しに失敗したことを意味するエラーコードを含むエラー通知を１系の監視モジュールへ送信する。また、ステップ１３０では２系の監視モジュールと通信可能な状態か否か判定する。判定が否定された場合はステップ１３４へ移行するが、判定が肯定された場合は次のステップ１３２において、上記のエラー通知を２系の監視モジュールへ送信した後にステップ１３４へ移行する。

従って、ログファイルへのログ情報又はエラーログ情報の書き出しに失敗した場合は、１系及び２系の監視モジュールに対し、上記のエラー通知を送信しログファイルへの書き出し失敗を通知した後に、他のモジュールから受信した情報に基づく生存通知又はエラー通知の送信が行われることになる。

一方、監視モジュールによって実現される障害監視処理（図４）では、まずステップ１５０で、他のモジュールから何らかの情報を受信したか否か判定する。個々の監視モジュールは１系及び２系のログサービスモジュールから生存通知及びエラー通知を各々受信すると共に、他系の監視モジュールからハートビートも受信する。ステップ１５０の判定が肯定された場合はステップ１７０へ移行し、受信した情報は１系又は２系のログサービスモジュールから送信されたエラー通知か否か判定する。

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

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

また、監視モジュールが他のモジュールから情報を受信していない場合は、ステップ１５０の判定が否定されてステップ１５２へ移行し、他系の監視モジュールへ前回ハートビートを送信してからの経過時間が所定時間ｔ３以上となったか否か判定する。判定が否定された場合はステップ１５８へ移行するが、判定が肯定された場合は、ステップ１５４で他系の監視モジュールと通信可能な状態か否か判定する。この判定が否定された場合もステップ１５８へ移行するが、判定が肯定された場合は、ステップ１５６で他系の監視モジュールへハートビートを送信した後にステップ１５８へ移行する。このように、１系及び２系の監視モジュールは、他系の監視モジュールへのハートビートの送信を所定時間ｔ３周期で行う。

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

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

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

続いて、１系・２系のアプリケーション・サーバ３０上で動作する１系・２系の業務処理モジュールが業務処理（図２）を各々行い、１系・２系のウェブ・サーバ４０上で動作する１系・２系のログサービスモジュールがログサービス処理（図３）を各々行い、１系・２系のアプリケーション・サーバ３０上で動作する１系・２系の監視モジュールが障害監視処理（図４）を行うことで実現される障害監視／検知シーケンスについて、図５〜図１０を参照して更に説明する。

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

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

なお、図５では１系の業務処理モジュールから１系のログサービスモジュールへのハートビートの送信に関連するシーケンスを示しているが、１系の業務処理モジュールからは２系のログサービスモジュールへもハートビートが送信され、同様に２系の業務処理モジュールからも１系・２系のログサービスモジュールへハートビートが送信され、同様にデータベース・サーバ２０上で動作する電文処理モジュールからも１系・２系のログサービスモジュールへハートビートが送信され、各ハートビートについて上記のシーケンスが各々実行される。

また、１系の業務処理モジュールによる業務処理でエラーが発生した場合、図６に示すシーケンスで業務処理のエラーが検知される。すなわち、１系の業務処理モジュールは業務処理でエラーが発生すると１系のログサービスモジュールへエラー情報を送信する(図６の(1))。１系のログサービスモジュールは、１系の業務処理モジュールからエラー情報を受信すると、ログファイルにエラーログ情報を書き出し(図６の(2))、１系の業務処理モジュールによる業務処理におけるエラーの発生を通知するエラー通知を１系・２系の監視モジュールへ順次送信し(図６の(3),(4))、エラー情報送信元の１系の業務処理モジュールへ応答を送信する(図６の(5))。

上記のエラー検知シーケンスでは、１系・２系の監視モジュールへエラー通知が各々送信されるが、監視モジュールから監視用コンピュータ５０へのエラー通知は、１系・２系の監視モジュールのうち先にエラー通知を受信した監視モジュールによって行われる。これにより、管理者は、監視用コンピュータ５０を通じて、１系の業務処理モジュールによる業務処理でエラーが発生したことを認識し、必要に応じてエラー解消のための対処や再発防止のための対策を講ずることができる。なお、１系の業務処理モジュールからは２系のログサービスモジュールへもエラー情報が送信され、このエラー情報に対しても上記のシーケンスが実行される。また、２系の業務処理モジュールによる業務処理でエラーが発生した場合にも、上記と同様のシーケンスが実行される。また、上記のシーケンスでログファイルに書き出されたエラーログ情報は、第１のコンピュータ・システム１４の端末装置１２を介しての閲覧に供せられる。

また、１系の業務処理モジュールに障害が発生した場合（１系の業務処理モジュールがプロセスとして実行中であるものの動作が滞っている状態に陥った場合を含む）には、図７に示すシーケンスで１系の業務処理モジュールの障害が検知される。すなわち、１系の業務処理モジュールに障害が発生すると、１系の業務処理モジュールから１系のログサービスモジュールへのハートビートの送信(図７の(1))が滞るので、１系のログサービスモジュールによるログファイルへのログ情報の書き出し(図７の(2))、１系・２系の監視モジュールへの１系の業務処理モジュールの生存通知の送信(図７の(3),(4))も滞ることになる。これにより、１系・２系の監視モジュールにおいて、１系の業務処理モジュールの生存通知を最後に受信してからの経過時間が閾値以上となることで１系の業務処理モジュールの障害発生が検知され、１系・２系の監視モジュールのうちの何れかによって１系の業務処理モジュールの障害発生が監視用コンピュータ５０へ通知される。

一方、２系の業務処理モジュールには障害は発生していないので、２系の業務処理モジュールは１系のログサービスモジュールへハートビートを送信し(図７の(5))、１系のログサービスモジュールは、２系の業務処理モジュールからのハートビートの受信を契機として、ログファイルへのログ情報の書き出し(図７の(6))、１系・２系の監視モジュールへの２系の業務処理モジュールの生存通知の送信(図７の(7),(8))、ハートビート送信元の２系の業務処理モジュールへの応答の送信(図７の(9))を順次行う。

１系・２系の監視モジュールが１系の業務処理モジュールの生存通知を一定時間以内に受信できない場合、原因としては、１系の業務処理モジュールでの障害発生以外に、ログサービスモジュールでの障害発生も考えられるが、管理者は、１系の業務処理モジュールの障害発生が監視用コンピュータ５０を通じて通知されている一方で、２系の業務処理モジュールの障害発生が通知されていないことに基づいて、１系の業務処理モジュールに障害が発生したことを認識することができる（この例では、２系のログサービスモジュールからの１系の業務処理モジュールの生存通知も監視モジュールが一定時間以内に受信できないので、これに基づいて監視モジュールが「１系の業務処理モジュールの障害」と自動的に判断して監視用コンピュータ５０に通知することも可能である）。

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

また監視モジュールは、１系の業務処理モジュールに障害が発生したと判断すると、電文格納テーブルに格納されている電文のうち１系の業務処理モジュールが宛先に設定されている電文について、宛先を２系の業務処理モジュールへ書き替える。これにより、データベース・サーバ２０が受信した電文に対する業務処理は、全て２系の業務処理モジュールによって行われる。なお、２系の業務処理モジュールで障害が発生した場合にも、上記と同様のシーケンスが実行される。

また、１系のログサービスモジュールに障害が発生した場合には、図８に示すシーケンスで１系のログサービスモジュールの障害が検知される。すなわち、１系のログサービスモジュールに障害が発生すると、１系の業務処理モジュールから１系のログサービスモジュールへハートビートを送信できない(図８の(1))ので、１系のログサービスモジュールによるログファイルへのログ情報を書き出し、１系・２系の監視モジュールへの１系の業務処理モジュールの生存通知の送信も行われない。一方、２系のログサービスモジュールには障害は発生していないので、１系の業務処理モジュールは２系のログサービスモジュールへハートビートを送信し(図８の(2))、２系のログサービスモジュールは、１系の業務処理モジュールからのハートビートの受信を契機として、ログファイルへのログ情報の書き出し(図８の(3))、１系・２系の監視モジュールへの１系の業務処理モジュールの生存通知の送信(図８の(4),(5))、ハートビート送信元の１系の業務処理モジュールへの応答の送信(図８の(6))を順次行う。

１系の業務処理モジュールは、送信したハートビートに対する応答を２系のログサービスモジュールから受信すると、先に１系のログサービスモジュールへハートビートを送信できなかったことに基づいて障害通知を送信することで、１系のログサービスモジュールに障害が発生していることを２系のログサービスモジュールへ通知する(図７の(7))。２系のログサービスモジュールは、１系の業務処理モジュールから障害通知を受信すると、１系のログサービスモジュールに障害が発生していることを表すエラー通知を１系・２系の監視モジュールへ順次送信し(図８の(8),(9))、障害通知送信元の１系の業務処理モジュールへ応答を送信する(図８の(10))を順次行う。そして、１系・２系の監視モジュールのうちの何れかによって１系のログサービスモジュールの障害発生が監視用コンピュータ５０へ通知される。管理者は、監視用コンピュータ５０を通じて１系のログサービスモジュールの障害発生を認識することができ、必要に応じて障害復旧のための対処や再発防止のための対策を講ずることができる。

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

そして、１系のログサービスモジュールから受信したエラー通知に基づき、１系・２系の監視モジュールのうちの何れかによって、１系のログサービスモジュールにおけるログファイルへのログ情報の書き出し失敗が監視用コンピュータ５０へ通知される。管理者は、監視用コンピュータ５０を通じて１系のログサービスモジュールにおいてログ情報の書き出しが失敗したことを認識することができ、必要に応じて復旧のための対処や再発防止のための対策を講ずることができる。

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

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

なお、上記では請求項５に記載の第１監視手段に相当するログサービスモジュールをウェブ・サーバ４０に設けると共に、請求項５に記載の第２監視手段に相当する監視モジュールを個々のアプリケーション・サーバ３０に各々設け、個々のアプリケーション・サーバ３０上で動作する業務処理モジュールが、ウェブ・サーバ４０上で動作するログサービスモジュールへハートビートを送信し、ハートビートを受信したログサービスモジュールはログファイルへログ情報を書き出すと共に、アプリケーション・サーバ３０上で動作する監視モジュールへ生存通知を送信し、監視モジュールは生存通知の受信時間間隔に基づいて業務処理モジュールの動作状態が正常か否か判断する態様を説明したが、この態様は各サーバ間のトラフィック量（通信量）が多く、一部のサーバで処理遅延等の障害が発生した場合にコンピュータ・システム１０全体に障害が波及し易いという欠点がある。例えばウェブ・サーバ４０で処理遅延が発生し、業務処理モジュールがハートビートに対するログサービスモジュールの応答を所定時間以内に受信できない場合、業務処理モジュールによる業務処理も滞り、ウェブ・サーバ４０の処理遅延がアプリケーション・サーバ３０にも波及する。上記を考慮し、図１１に示すようにコンピュータ・システムを構成してもよい。

図１１に示すコンピュータ・システムでは、個々のアプリケーション・サーバ３０に、業務処理モジュール及び監視モジュールに加えログサービスモジュール及びログ回収モジュールが設けられており、個々のアプリケーション・サーバ３０のＨＤＤ３６にはログファイルも記憶されている。個々のサーバ３０上で動作する業務処理モジュールは、同一のサーバ３０上で動作するログサービスモジュールへのみハートビート及びエラー情報を送信し(図１１の(1))、ログサービスモジュールは、ハートビートの受信時には同一のサーバ３０上のログファイルへログ情報を書き出し(図１１の(2))、ハートビート送信元の業務処理モジュールへ応答を送信する(図１１の(3))と共に、同一のサーバ３０上で動作する監視モジュールへ業務処理モジュールの生存通知を送信する(図１１の(4))。これにより、個々のサーバ３０上で動作する監視モジュールは、同一のサーバ３０上で動作する業務処理モジュールについてのみ動作状態が正常か否か判定し、動作状態が異常と判断した場合には監視用コンピュータ５０へ通知する。

また、図示は省略するが、同一のサーバ３０上で動作する業務処理モジュールからエラー情報を受信した場合、ログサービスモジュールは、同一のサーバ３０上のログファイルへエラーログ情報を書き出し、エラー情報送信元の業務処理モジュールへ応答を送信し、同一のサーバ３０上で動作する監視モジュールへ業務処理モジュールのエラー発生を通知するエラー通知を送信する。そして監視モジュールは、同一のサーバ３０上で動作するログサービスモジュールからエラー通知を受信すると、受信したエラー通知を監視用コンピュータ５０へ転送することで、同一のサーバ３０上で動作する業務処理モジュールによる業務処理におけるエラーの発生を通知する。

このように、図１１に示す態様では、業務処理モジュールからのハートビートの送信時にサーバ間の通信を行うことなく、ログ情報の書き出し及び業務処理モジュールの動作状態の判定を行うことができるので、サーバ間のトラフィック量を抑制することができ、コンピュータ・システムの耐障害性を向上させることができる。また、図１１に示す態様においても、個々の業務処理モジュールが自発的にハートビートを送信するので、個々の業務処理モジュールの動作状態の判別が可能になると共に、業務処理モジュールの動作状態判別のために業務処理モジュールに大きな負荷が加わることで業務処理の遅延等が生ずることも回避することができる。

また、図１１に示す態様では、個々のサーバ３０上で動作する業務処理モジュールに対応するログ情報及びエラーログ情報が、個々のサーバ３０に設けられたログファイルに分散されて記憶されることになる。このため、データベース・サーバ２０のＨＤＤ２６にはエラーログ情報を格納するためのログテーブルが設けられており、個々のサーバ３０上で動作するログ回収モジュールは、第１のコンピュータ・システム１４の端末装置１２を介してエラーログ情報を閲覧可能とすることを目的として、業務処理モジュールからのハートビートやエラー情報の送信タイミングとは非同期に、同一のサーバ３０に設けられたログファイルからエラーログ情報を読み出すことで回収し(図１１の(a))、回収したエラーログ情報をデータベース・サーバ２０へ転送する(図１１の(b))。そして、データベース・サーバ２０は、ログ回収モジュールから転送されたエラーログ情報をログテーブルに書き出すと共に、第１のコンピュータ・システム１４の端末装置１２からウェブ・サーバ４０を介してエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報をログテーブルから読み出しウェブ・サーバ４０を介して配信要求元の端末装置１２へ配信する処理を行う。これにより、端末装置１２を介してエラーログ情報を閲覧することが可能となる。

なお、図１１に示す態様に係るコンピュータ・システムは請求項６記載の発明に対応しており、この態様において、データベース・サーバ２０は請求項６に記載のログ情報管理用コンピュータに、ログサービスモジュール及び監視モジュールは請求項６に記載の監視手段に、ログ回収モジュールは請求項６に記載の転送手段に各々対応しており、データベース・サーバ２０上で動作し、ログ回収モジュールから転送されたエラーログ情報をログテーブルへ書き出すと共に、エラーログ情報の配信要求時に配信対象のエラーログ情報をログテーブルから読み出して配信する処理を行う処理モジュールは請求項６に記載のログ情報管理手段に、データベース・サーバ２０のＨＤＤ２６は請求項６に記載の第３記憶手段に対応している。

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

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

符号の説明

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

Claims (6)

1. 対応するアプリケーション・プログラムが業務処理用コンピュータによって実行されることで前記業務処理用コンピュータ上で動作し、処理対象の電文が有るか否かを判定し、処理対象の電文が有る場合は処理対象の電文に応じた所定の業務処理を行い、生存通知を送信する送信処理を前回行ってから前記所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続した場合は前記送信処理を行い、前記送信処理を前回行ってから前記所定の業務処理を行うべき処理対象の電文が無い状態が所定時間以上継続することなく、前記送信処理を前回行ってから前記所定の業務処理を行った処理対象の電文の数が一定値に達した場合は前記送信処理を行うアプリケーション手段と、
   前記業務処理用コンピュータ又は前記業務処理用コンピュータと通信回線を介して接続された別のコンピュータ上で動作し、前記アプリケーション手段より前記生存通知を受信すると共に、前記アプリケーション手段より最後に生存通知を受信してからの経過時間に基づいて前記アプリケーション手段の動作状態を判別する監視手段と、
   を含むコンピュータ・システム。
2. 前記監視手段は、前記アプリケーション手段より生存通知を受信する毎に、前記生存通知の受信時刻を含む情報を第２記憶手段にログ情報として記憶させることを特徴とする請求項１記載のコンピュータ・システム。
3. 前記アプリケーション手段は、前記所定の業務処理を行ってエラーが発生した場合に前記監視手段へエラー情報を送信し、
   前記監視手段は、前記アプリケーション手段から前記エラー情報を受信する毎に、受信した前記エラー情報を第２記憶手段にエラーログ情報として記憶させることを特徴とする請求項１記載のコンピュータ・システム。
4. 前記コンピュータ・システムには、前記監視手段が動作するコンピュータと通信回線を介して接続された監視用コンピュータが設けられており、
   前記監視手段は、前記アプリケーション手段から前記エラー情報を受信した場合に、前記監視用コンピュータへエラーの発生を通知することを特徴とする請求項３記載のコンピュータ・システム。
5. 前記アプリケーション手段が各々動作する複数台の前記業務処理用コンピュータと、前記複数台の業務処理用コンピュータと通信回線を介して各々接続された監視用コンピュータ及びログ情報管理用コンピュータが各々設けられ、
   前記監視手段は、
   前記ログ情報管理用コンピュータ上で動作し、前記複数台の業務処理用コンピュータ上で動作する個々のアプリケーション手段から前記生存通知及び前記エラー情報を各々受信し、前記ログ情報管理用コンピュータに設けられた前記第２記憶手段にログ情報又はエラーログ情報として記憶させる第１監視手段、
   及び、少なくとも１つの業務処理用コンピュータ上で動作し、前記第１監視手段が前記生存通知又は前記エラー情報を受信する毎に前記第１監視手段から前記生存通知又は前記エラー情報が転送され、個々のアプリケーション手段から前記第１監視手段を経由して前記生存通知を受信した時間間隔に基づいて前記個々のアプリケーション手段の動作状態を判別し、任意のアプリケーション手段の動作状態が異常と判断した場合に前記監視用コンピュータへ通知すると共に、任意のアプリケーション手段から前記第１監視手段を経由して前記エラー情報を受信した場合に前記監視用コンピュータへエラーの発生を通知する第２監視手段から成り、
   前記ログ情報管理用コンピュータには、前記ログ情報管理用コンピュータ上で動作し、前記ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を前記第２記憶手段から読み出して配信要求元の前記端末装置へ転送するログ情報管理手段が設けられていることを特徴とする請求項３記載のコンピュータ・システム。
6. 前記アプリケーション手段が各々動作する複数台の前記業務処理用コンピュータと、前記複数台の業務処理用コンピュータと通信回線を介して各々接続されたログ情報管理用コンピュータが各々設けられ、
   前記監視手段は、個々の前記業務処理用コンピュータ上で各々動作し、同一の業務処理用コンピュータ上で動作するアプリケーション手段から前記生存通知及び前記エラー情報を各々受信し、前記同一の業務処理用コンピュータに設けられた第２記憶手段にログ情報又はエラーログ情報として記憶させ、
   個々の前記業務処理用コンピュータには、個々の前記業務処理用コンピュータ上で各々動作し、同一の業務処理用コンピュータに設けられた第２記憶手段に記憶されている前記エラーログ情報を前記ログ情報管理用コンピュータへ定期的に転送する転送手段が設けられており、
   前記ログ情報管理用コンピュータには、前記ログ情報管理用コンピュータ上で動作し、任意の前記業務処理用コンピュータからエラーログ情報を受信する毎に、前記ログ情報管理用コンピュータに設けられた第３記憶手段に前記受信したエラーログ情報を記憶させると共に、前記ログ情報管理用コンピュータと通信回線を介して接続された端末装置からエラーログ情報の配信が要求された場合に、配信対象のエラーログ情報を前記第３記憶手段から読み出して配信要求元の前記端末装置へ転送するログ情報管理手段が設けられていることを特徴とする請求項３記載のコンピュータ・システム。

Images