JP2009151388A

JP2009151388A - 監視処理プログラム、方法及び装置

Info

Publication number: JP2009151388A
Application number: JP2007326509A
Authority: JP
Inventors: Yoshiki Tagashira; 芳樹田頭
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2007-12-18
Filing date: 2007-12-18
Publication date: 2009-07-09
Anticipated expiration: 2027-12-18
Also published as: JP4863984B2

Abstract

【課題】アプリケーションの状態をより正確に判断する
【解決手段】サーバにおける所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているログDBに格納されている最新ログ・レコードが第1所定時間前における最新ログ・レコードと異なる場合にサーバにおける監視エージェント・プログラムから送信される通知を受信する工程と、監視エージェント・プログラムからの通知を受信してから第2所定時間経過するまでに次の通知を受信しない場合、所定のアプリケーション・プログラムにアプリケーション処理依頼を送信する工程と、アプリケーション処理依頼を送信してから第3所定時間経過するまでにアプリケーション処理依頼に対する応答を所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断する工程とを含む。
【選択図】図４

Description

本発明は、アプリケーションの生存監視のための技術に関し、より詳しくは、アプリケーションの状態をより正確に判断するための技術に関する。

従来、例えば、業務処理サーバ（以下、被監視サーバと呼ぶ）のアプリケーション層レベルの生存監視を行う場合、図１に示すように、監視マネージャ（例えば、監視装置等）が、生存監視のためのリクエスト（以下、生存監視リクエストと呼ぶ）を定期的に被監視サーバに送信し、被監視サーバのアプリケーション層の処理を実行させる。そして、アプリケーションが正常に動作していれば、生存監視リクエストに対する応答が一定時間内に送信されるため、監視マネージャはアプリケーションの状態を正常とみなす。一方、アプリケーションに異常が生じている場合には、生存監視リクエストに対する応答が一定時間内に送信されないので、監視マネージャはアプリケーションの状態を異常とみなす。

上記のような技術に類似するものとして、例えば特許第３９０３４３７号公報記載の技術がある。具体的には、２つのネットワーク・インタフェースを備えた複数のピア・ノードと、少なくとも１つのゲートウェイとからクラスタが構成され、ピア・ノード間でハートビート・メッセージを送信し、ハートビート損失を検出したピア・ノードが、２つのネットワーク・インタフェースのそれぞれを介して、クラスタにおける全てのピア・ノードおよびゲートウェイにオペレーティング・システムレベルのＩＣＭＰ（Internet Control Message Protocol）エコーを発行し、ＩＣＭＰエコーの応答を分析してクラスタにおける障害の位置を決定するようになっている。さらに、所定の時間間隔内のＩＣＭＰエコーの応答の受信およびハートビート損失の検出の双方に応答して、ピア・ノードに対してアプリケーション・レベルのｐｉｎｇ（Packet INternet Groper）を発行するようになっている。

しかしながら、上で述べたような従来技術では、生存監視リクエストを受信した被監視サーバにおいてアプリケーション層の処理を実行しなければならない。そのため、例えば図２に示すように被監視サーバが高負荷状態にある場合には、生存監視リクエストに応じた処理を実施するまでに時間がかかり、一定時間内に応答することができないため、アプリケーションは正常に動作しているにもかかわらず、監視マネージャにおいて異常と判断されてしまう場合がある。

特に、複数台のサーバで負荷分散しているような場合、アプリケーションの状態が異常と判断されると、そのサーバは負荷分散の対象から外されてしまい、他のサーバの負荷を増加させることになる。そして、図３に示すように、サーバが次々と負荷分散の対象から外されることになり、最終的にシステムダウンを起こす可能性がある。

また、例えば特開２００６−１７２０５０号公報には、ネットワークにより接続されている同一の動作をする２つのサーバ計算機を有するホットスタンバイ式２重化システムが開示されている。具体的には、２つのサーバ計算機の各々に、ネットワークに接続された他方のサーバ計算機が正常に動作しているかどうかの状態を監視すると共に、自サーバ計算機の状態を他方のサーバ計算機に通知するハートビートモジュールと、自サーバ計算機内のプロセスを監視し、プロセスの異常を検出した場合はハートビートモジュールにプロセス異常の検出を通知するプロセス監視モジュールと、自サーバ計算機内のログを監視し、異常ログを検出した場合はハートビートモジュールに異常ログの検出を通知するログ監視モジュールとを備える。また、ハートビートモジュールは、他方のサーバ計算機のハートビートモジュールが送信するハートビート信号を受信し、当該ハートビート信号を一定時間内に受信できなかった場合は他方のサーバ計算機が正常に動作していないと判断して自サーバ計算機をマスタとし、ハートビート信号を一定時間内に受信できた場合は他方のサーバ計算機の状態が正常に動作していると判断して自サーバ計算機をスレーブとするようになっている。しかし、当該公報では、他方のサーバ計算機のハートビートモジュールに異常が生じて、ハートビート信号が送信されなくなった場合も、直ちに他方のサーバ計算機が正常に動作していないと判断されてしまい、他方のサーバ計算機のハートビートモジュールに異常が生じているのか、プロセスに異常が生じているのか判断することはできない。また、当該公報では、自サーバ計算機のプロセスの異常を検出したり、異常ログを検出したりする必要があるため、このような異常を監視する処理がサーバ計算機の負荷となってしまう。
特許第３９０３４３７号公報特開２００６−１７２０５０号公報

以上述べたように、従来技術では、被監視サーバのアプリケーションの状態を正確に判断することができない。また、被監視サーバにおける監視処理の負荷を軽減できているとは言えない。

従って、本発明の目的は、被監視サーバのアプリケーションの状態をより正確に判断するための技術を提供することである。

また、本発明の他の目的は、被監視サーバにおける監視処理の負荷を抑えつつ、被監視サーバのアプリケーション層レベルの生存監視を行うための技術を提供することである。

本発明に係る監視処理方法は、サーバにおける所定のアプリケーション・プログラムの状態を監視する方法であって、所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合にサーバにおける監視エージェント・プログラムから送信される通知（例えば、最新ログ・レコード。単に所定のアプリケーション・プログラムの生存を表す通知であってもよい。）を受信するステップと、監視エージェント・プログラムからの通知を受信してから第２の所定時間経過するまでに次の通知を受信しない場合、所定のアプリケーション・プログラムにアプリケーション処理依頼を送信するステップと、アプリケーション処理依頼を送信してから第３の所定時間経過するまでにアプリケーション処理依頼に対する応答を所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断するステップとを含む。

このようにすれば、例えば、第２の所定時間内に監視エージェント・プログラムからの次の通知を受信した場合、及び、第３の所定時間内にアプリケーション・プログラムからの応答を受信した場合には、アプリケーション・プログラムの動作が正常であるとみなすようにすれば、高負荷状態であっても、被監視サーバのアプリケーションの状態を正確に判断することができる。

また、被監視サーバでは、第１の所定時間間隔毎に、ログ・レコードが更新されたか否かを判断すればよく、被監視サーバにおける監視処理の負荷を軽減することができる。なお、（１）被監視サーバがアイドリング状態（動作は正常）の場合、（２）アプリケーション・プログラムに異常が生じている場合、（３）監視エージェント・プログラムに異常が生じている場合のいずれかの場合に、アプリケーション処理依頼（すなわち、生存監視リクエスト）を送信することになるが、正常動作中にアプリケーション処理依頼が送信されるのは、上記（１）の場合だけである。すなわち、アイドリング状態であれば、被監視サーバにアプリケーション層の処理を実行させても問題にはならない。

また、アプリケーション処理依頼を送信してから第３の所定時間経過するまでにアプリケーション処理依頼に対する応答を所定のアプリケーション・プログラムから受信し、アプリケーション処理依頼に対する応答を受信してから第４の所定時間経過するまでに監視エージェント・プログラムからの通知を受信しない場合、当該監視エージェント・プログラムに異常が生じていると判断するステップをさらに含むようにしてもよい。

このようにすれば、アプリケーション・プログラムに異常が生じているのか、監視エージェント・プログラムに異常が生じているのかを把握することができるようになる。

なお、本発明に係る監視処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、被監視サーバのアプリケーションの状態をより正確に判断できる。

また、本発明の他の側面によれば、被監視サーバにおける監視処理の負荷を抑えつつ、被監視サーバのアプリケーション層レベルの生存監視を行うことができる。

図４に本発明の一実施の形態に係るシステム概要を示す。例えば、社内ＬＡＮ（Local Area Network）又はインターネットのようなネットワーク１には、クライアント端末３と、監視対象となる被監視サーバ５とが接続されている。また、同様に社内ＬＡＮ又はインターネットのようなネットワーク９には、被監視サーバ５と、被監視サーバ５を監視する監視マネージャ７とが接続されている。なお、図４の例では、監視マネージャ７に接続される被監視サーバ５は１台であるが、複数台接続される場合もある。また、図４の例では、被監視サーバ５に接続されるクライアント端末３も１台であるが、複数台接続される場合もある。

被監視サーバ５は、クライアント端末３からのリクエスト又は監視マネージャ７からの生存監視リクエストに応じた処理を実行するアプリケーション５１と、アプリケーション５１から出力されるログ・レコードを格納するログＤＢ５３と、ログＤＢ５３に格納された最新ログ・レコードを監視し、監視マネージャ７に所定の通知を送信する監視エージェント５５とを有する。

また、監視マネージャ７は、アプリケーション５１からの、生存監視リクエストに対する応答又は監視エージェント５５からの所定の通知を受信する受信部７１と、所定時間内に生存監視リクエストに対する応答又は所定の通知を受信したか監視する監視処理部７３と、生存監視リクエストを送信するリクエスト送信部７５とを有する。

次に、図５乃至図８を用いて、図４に示したシステムの処理概要を説明する。図４に示したシステムの基本的な処理の流れを図５に示す。まず、クライアント端末３は、例えば被監視サーバ５の提供するサービスなどを利用する場合、被監視サーバ５にリクエストを送信する（図５：ステップ（１））。そして、被監視サーバ５のアプリケーション５１は、クライアント端末３からのリクエストを受信し、リクエストに応じた処理を実行し、リクエストに対する応答をクライアント端末３に送信する（ステップ（２））。このとき、アプリケーション５１は、実行した処理に関するログ・レコードを生成し、ログＤＢ５３に出力する（ステップ（３））。なお、本実施の形態では、アプリケーション５１において処理が正常に終了した場合に、ログ・レコードが出力されるものとする。

また、被監視サーバ５の監視エージェント５５は、一定時間（例えば第１の所定時間）間隔毎に、ログＤＢから最新ログ・レコードを読み出す（ステップ（４））。そして、監視エージェント５５は、読み出した最新ログ・レコードと監視マネージャ７に前回送信したログ・レコードとが同一かどうか判断し、前回送信したログ・レコードと異なる場合には、読み出した最新ログ・レコードを監視マネージャ７に送信する（ステップ（５））。

そして、監視マネージャ７の受信部７１は、被監視サーバ５の監視エージェント５５から定期的に送信される最新ログ・レコードを受信する。また、監視マネージャ７の監視処理部７３は、一定時間（例えば第２の所定時間）内に次の最新ログ・レコードを受信したか監視し、一定時間内に次の最新ログ・レコードを受信した場合には、被監視サーバ５のアプリケーション５１の状態を正常と判断する（ステップ（６））。

このように、被監視サーバ５のアプリケーション５１が正常に動作しており、クライアント端末３からのリクエストに応じて処理を実行していれば、最新ログ・レコードが更新され、被監視サーバ５の監視エージェント５５から監視マネージャ７に最新ログ・レコードが送信されることになる。従って、本実施の形態では、監視マネージャ７が、一定時間内に次の最新ログ・レコードを受信することで、被監視サーバ５のアプリケーション５１の状態を正常と判断する。

また、（１）被監視サーバ５がアイドリング状態（動作は正常）の場合、（２）被監視サーバ５のアプリケーション５１に異常が生じている場合、（３）被監視サーバ５の監視エージェント５５に異常が生じている場合のいずれかの場合、監視エージェント５５からの通知（最新ログ・レコードの送信）が一定時間以上なされないこととなる。図６乃至図８を用いて、各々の場合における処理を説明する。

図６に、（１）被監視サーバ５がアイドリング状態（動作は正常）の場合における処理の流れを示す。被監視サーバ５がアイドリング状態の場合、アプリケーション層の処理は行われず、被監視サーバ５のアプリケーション５１からログ・レコードが出力されない。そして、ステップ（５）において、最新ログ・レコードが前回送信したログ・レコードと同一であると判断され、被監視サーバ５の監視エージェント５５は、最新ログ・レコードの送信を行わない。そのため、監視マネージャ７の監視処理部７３は、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出する（図６：ステップ（７））。一定時間以上通知がなされていないことを検出すると、監視マネージャ７のリクエスト送信部７５は、生存監視リクエストを被監視サーバ５に送信する（ステップ（８））。また、監視マネージャ７の監視処理部７３は、生存監視リクエストを送信してから一定時間（例えば第３の所定時間）経過するまでの間に、生存監視リクエストに対する応答を被監視サーバ５から受信したか否か監視する（ステップ（９））。

一方、被監視サーバ５のアプリケーション５１は、監視マネージャ７からの生存監視リクエストを受信すると、生存監視リクエストに応じた処理を実行し、生存監視リクエストに対する応答を監視マネージャ７に送信する（ステップ（１０））。このとき、アプリケーション５１は、実行した処理に関するログ・レコードを生成し、ログＤＢ５３に出力する（ステップ（１１））。

監視マネージャ７の受信部７１は、被監視サーバ５のアプリケーション５１からの、生存監視リクエストに対する応答を受信する。生存監視リクエストを送信してから一定時間経過するまでの間に、生存監視リクエストに対する応答を受信した場合には、監視マネージャ７の監視処理部７３は、続いて、一定時間（例えば第４の所定時間）経過するまでに、被監視サーバ５からの最新ログ・レコードを受信したか否か監視する（ステップ（１２））。

また、被監視サーバ５の監視エージェント５５は、ログＤＢから最新ログ・レコードを読み出す（ステップ（１３））。そして、監視エージェント５５は、読み出した最新ログ・レコードと監視マネージャ７に前回送信したログ・レコードとが同一かどうか判断する。なお、ステップ（１１）において、新たなログ・レコードが出力されているため、読み出した最新ログ・レコードは、前回送信したログ・レコードとは異なるものと判断される。そして、監視エージェント５５は、読み出した最新ログ・レコードを監視マネージャ７に送信する（ステップ（１４））。そして、監視マネージャ７の受信部７１は、被監視サーバ５の監視エージェント５５からの最新ログ・レコードを受信する。

このように、被監視サーバ５がアイドリング状態（動作は正常）の場合には、監視マネージャ７は、生存監視リクエストを送信してから一定時間（第３の所定時間）経過するまでに、生存監視リクエストに対する応答を受信し、その後、一定時間（第４の所定時間）経過するまでに最新ログ・レコードを受信することになる。従って、監視マネージャ７は、生存監視リクエストに対する応答及び最新ログ・レコードを受信することで、被監視サーバ５のアプリケーション５１の状態を正常と判断する（ステップ（１５））。

図７に、（２）被監視サーバ５のアプリケーション５１に異常が生じている場合における処理の流れを示す。被監視サーバ５のアプリケーション５１に異常が生じている場合、アプリケーション層の処理が正常に終了しないため、アプリケーション５１からログ・レコードが出力されない。そして、ステップ（５）において、最新ログ・レコードが前回送信したログ・レコードと同一であると判断され、被監視サーバ５の監視エージェント５５は、最新ログ・レコードの送信を行わない。そのため、監視マネージャ７の監視処理部７３は、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出する（図７：ステップ（１６））。一定時間以上通知がなされていないことを検出すると、監視マネージャ７のリクエスト送信部７５は、生存監視リクエストを被監視サーバ５に送信する（ステップ（１７））。また、監視マネージャ７の監視処理部７３は、生存監視リクエストを送信してから一定時間経過するまでの間に、生存監視リクエストに対する応答を被監視サーバ５から受信したか否か監視する（ステップ（１８））。

一方で、被監視サーバ５のアプリケーション５１は、監視マネージャ７からの生存監視リクエストを受信する。しかし、被監視サーバ５のアプリケーション５１に異常が生じているため、生存監視リクエストに応じた処理が正常に終了せず、生存監視リクエストに対する応答は送信されない。

このように、被監視サーバ５のアプリケーション５１に異常が生じている場合には、監視マネージャ７は、生存監視リクエストを送信しても、一定時間経過するまでに生存監視リクエストに対する応答を受信しない。従って、監視マネージャ７は、一定時間内に生存監視リクエストに対する応答がない場合には、被監視サーバ５のアプリケーション５１の状態を異常と判断する（ステップ（１９））。

図８に、（３）被監視サーバ５の監視エージェント５５に異常が生じている場合における処理の流れを示す。被監視サーバ５の監視エージェント５５に異常が生じている場合、被監視サーバ５のアプリケーション５１は正常に動作していても、最新ログ・レコードは送信されない。そのため、監視マネージャ７の監視処理部７３は、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出する（図８：ステップ（２０））。一定時間以上通知がなされていないことを検出すると、監視マネージャ７のリクエスト送信部７５は、生存監視リクエストを被監視サーバ５に送信する（ステップ（２１））。また、監視マネージャ７の監視処理部７３は、生存監視リクエストを送信してから一定時間経過するまでの間に、生存監視リクエストに対する応答を被監視サーバ５から受信したか否か監視する（ステップ（２２））。

一方、被監視サーバ５のアプリケーション５１は、監視マネージャ７からの生存監視リクエストを受信すると、生存監視リクエストに応じた処理を実行し、生存監視リクエストに対する応答を監視マネージャ７に送信する（ステップ（２３））。このとき、アプリケーション５１は、実行した処理に関するログ・レコードを生成し、ログＤＢ５３に出力する（ステップ（２４））。

監視マネージャ７の受信部７１は、被監視サーバ５のアプリケーション５１からの、生存監視リクエストに対する応答を受信する。生存監視リクエストを送信してから一定時間経過するまでの間に、生存監視リクエストに対する応答を受信した場合には、監視マネージャ７の監視処理部７３は、続いて、一定時間経過するまでに、被監視サーバ５からの最新ログ・レコードを受信したか否か監視する（ステップ（２５））。しかし、被監視サーバ５の監視エージェント５５に異常が生じているため、最新ログ・レコードは送信されない。

このように、被監視サーバ５の監視エージェント５５に異常が生じている場合には、監視マネージャ７は、生存監視リクエストを送信してから一定時間経過するまでに、生存監視リクエストに対する応答を受信するが、その後、最新ログ・レコードは受信しない。従って、監視マネージャ７は、生存監視リクエストに対する応答を受信した後、一定時間内に最新ログ・レコードが送信されない場合には、被監視サーバ５の監視エージェント５５の状態を異常と判断する（ステップ（２６））。

次に、図５乃至図８のような処理を実施するための被監視サーバ５のアプリケーション５１及び監視エージェント５５、並びに、監視マネージャ７の処理をより詳細に説明する。図９に、被監視サーバ５のアプリケーション５１の処理フローを示す。まず、アプリケーション５１は、クライアント端末３からのリクエスト又は監視マネージャ７からの生存監視リクエストを受信する（図９：ステップＳ１）。なお、いずれのリクエストも、アプリケーション層の処理を実行させるためのものである。そして、アプリケーション５１は、受信したリクエスト又は生存監視リクエストに応じた処理を実施する（ステップＳ３）。そして、当該処理が正常に終了した場合（ステップＳ５：Ｙｅｓルート）、アプリケーション５１は、実施した処理に関するログ・レコードを生成し、ログＤＢ５３に格納する（ステップＳ７）。また、アプリケーション５１は、クライアント端末３又は監視マネージャ７に、リクエストに対する応答又は監視リクエストに対する応答を送信する（ステップＳ９）。

図１０に、被監視サーバ５の監視エージェント５５の処理フローを示す。なお、監視エージェント５５は、図１０に示すような処理を定期的に実施する。まず、監視エージェント５５は、ログＤＢ５３から最新ログ・レコードを読み出す（図１０：ステップＳ１１）。なお、図示していないが、ログＤＢ５３にログ・レコードが格納されていない場合には、ステップＳ１３及びステップＳ１５の処理をスキップし、処理を終了する。

そして、読み出した最新ログ・レコードが、前回監視マネージャ７に送信したログ・レコードと同一であるか判断する（ステップＳ１３）。読み出したログ・レコードが、前回監視マネージャ７に送信したログ・レコードと同一であると判断された場合（ステップＳ１３：Ｙｅｓルート）、ステップＳ１５の処理をスキップし、処理を終了する。

一方、読み出した最新ログ・レコードが、前回監視マネージャ７に送信したログ・レコードと異なると判断された場合（ステップＳ１３：Ｎｏルート）、監視エージェント５５は、最新ログ・レコードを監視マネージャ７に送信し、送信履歴を更新する（ステップＳ１５）。なお、最後に送信したログ・レコードに関する情報（例えば、ログ・レコードの生成日時）を送信履歴として保持する。その後、処理を終了する。

図１１に、監視マネージャ７の処理フローを示す。まず、監視マネージャ７の監視処理部７３は、被監視サーバ５の監視エージェント５５から送信されるログ・レコードを監視する（図１１：ステップＳ２１）。なお、監視対象の被監視サーバ５が複数存在するような場合は、各被監視サーバ５の監視エージェント５５からのログ・レコードを監視する。そして、監視処理部７３は、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出したか判断する（ステップＳ２３）。被監視サーバ５の監視エージェント５５から、一定時間内に通知がなされた場合（ステップＳ２３：Ｎｏルート）、ステップＳ２１の処理に戻る。

一方、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出した場合（ステップＳ２３：Ｙｅｓルート）、監視マネージャ７のリクエスト送信部７５が、生存監視リクエストを被監視サーバ５のアプリケーション５１に送信する（ステップＳ２５）。また、監視処理部７３は、被監視サーバ５のアプリケーション５１からの、生存監視リクエストに対する応答を監視し、生存監視リクエストに対する応答を一定時間内に受信したか否か判断する（ステップＳ２７）。

被監視サーバ５のアプリケーション５１からの、生存監視リクエストに対する応答を一定時間内に受信しない場合（ステップＳ２７：Ｎｏルート）、監視処理部７３は、被監視サーバ５のアプリケーション５１に異常があると判断する（ステップＳ２９）。そして、異常時の処理（例えば、警告の出力や、被監視サーバ５の切り離し等）が予め決められている場合には、当該処理を実施する。そして、処理を終了する。

一方、被監視サーバ５からの、生存監視リクエストに対する応答を一定時間内に受信した場合（ステップＳ２７：Ｙｅｓルート）、監視処理部７３は、続いて、被監視サーバ５の監視エージェント５５からのログ・レコードを監視し、最新ログ・レコードを一定時間内に受信したか否か判断する（ステップＳ３１）。

生存監視リクエストに対する応答を受信した後、被監視サーバ５の監視エージェント５５からの最新ログ・レコードを一定時間内に受信しない場合（ステップＳ３１：Ｎｏルート）、監視処理部７３は、被監視サーバ５の監視エージェント５５に異常があると判断する（ステップＳ３３）。そして、異常時の処理（例えば、警告の出力や、監視エージェント５５の再起動等）が予め決められている場合には、当該処理を実施する。そして、処理を終了する。

一方、生存監視リクエストに対する応答を受信した後、被監視サーバ５の監視エージェント５５からの最新ログ・レコードを一定時間内に受信した場合（ステップＳ３１：Ｙｅｓルート）、ステップＳ２１の処理に戻る。すなわち、被監視サーバ５のアプリケーション５１及び監視エージェント５５が正常に動作している場合には、ステップＳ２１の処理に戻る。

以上のような処理を実施することにより、高負荷状態であっても被監視サーバ５のアプリケーション５１の状態を正確に判断することができる。さらに、被監視サーバ５のアプリケーション５１に異常が生じているのか、監視エージェント５５に異常が生じているのかも判断できるようになる。なお、監視エージェント５５は、ログ・レコードが更新されているか否かを判断すればよく、被監視サーバ５における負荷も軽減される。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した被監視サーバ５の監視エージェント５５の処理フロー（図１０）では、ステップＳ１３において、読み出した最新ログ・レコードが前回送信したログ・レコードと同一か否か判断し、異なる場合にのみ、被監視サーバ５の監視エージェント５５が、当該最新ログ・レコードを送信するようになっているが、ステップＳ１３の判断処理をスキップし、前回送信したログ・レコードと同一であっても、一定時間間隔毎に、現時点の最新ログ・レコード（ログＤＢ５３にログ・レコードが格納されていない場合には空のログ・レコード）を監視マネージャ７に送信するようにしてもよい。

この場合、上で説明した監視マネージャ７の処理フロー（図１１）のステップＳ２３において、被監視サーバ５の監視エージェント５５から、一定時間以上通知がなされていないことを検出した場合、監視エージェント５５に異常があると判断し、処理を終了するようにすればよい。また、ステップＳ２３とステップＳ２５の間に、受信したログ・レコードの内容が一定時間以上同一であるか否かを監視する処理を追加し、ログ・レコードの内容が一定時間以上同一であることを検出した場合には、ステップＳ２５の処理に移行（すなわち、生存監視リクエストを送信）し、ログ・レコードの内容が一定時間内に更新されている場合には、ステップＳ２１の処理に戻るようにすればよい。

また、上で説明した被監視サーバ５のアプリケーション５１の処理では、処理が正常に終了した場合にのみ、ログ・レコードを出力するようになっているが、例えばアプリケーション５１が動作を継続できるような状態で処理が異常終了した場合も、ログ・レコードを出力するようにしてもよい。この場合、監視エージェント５５では、ログ・レコードが更新されたものとみなして処理をすればよい。このようにしても、被監視サーバ５のアプリケーション５１の生存を確認することは可能である。

なお、図４に示したクライアント端末３、被監視サーバ５及び監視マネージャ７は、図１２のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
サーバにおける所定のアプリケーション・プログラムの状態を監視するための処理をコンピュータに実行させるためのプログラムであって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信するステップと、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信するステップと、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断するステップと、
をコンピュータに実行させる監視処理プログラム。

（付記２）
前記アプリケーション処理依頼を送信してから前記第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信し、前記アプリケーション処理依頼に対する応答を受信してから第４の所定時間経過するまでに前記監視エージェント・プログラムからの前記通知を受信しない場合、当該監視エージェント・プログラムに異常が生じていると判断するステップ
をさらにコンピュータに実行させる付記１記載の監視処理プログラム。

（付記３）
サーバにおける所定のアプリケーション・プログラムの状態を監視する方法であって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信するステップと、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信するステップと、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断するステップと、
を含み、コンピュータにより実行される監視処理方法。

（付記４）
サーバにおける所定のアプリケーション・プログラムの状態を監視する装置であって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信する手段と、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信する手段と、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断する手段と、
を有する監視処理装置。

（付記５）
所定のアプリケーション・プログラムを実行し、前記所定のアプリケーション・プログラムから出力されるログ・レコードを監視する監視手段を有するサーバと、
前記所定のアプリケーション・プログラムの状態を監視する監視処理装置と、
を有し、
前記監視手段は、
第１の所定時間間隔毎に、前記ログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが前記第１の所定時間前における最新ログ・レコードと同一であるか判断する手段と、
前記アプリケーションログ格納部に格納されている最新ログ・レコードが前記第１の所定時間前における最新ログ・レコードと異なると判断された場合、所定の通知を前記監視処理装置に送信する通知手段と、
を有し、
前記監視処理装置は、
前記通知手段からの前記所定の通知を受信する手段と、
前記通知手段からの前記所定の通知を受信してから第２の所定時間経過するまでに次の前記所定の通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信する手段と、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断する手段と、
を有する監視システム。

従来のアプリケーション層レベルの生存監視を説明するための図である。従来のアプリケーション層レベルの生存監視を説明するための図である。従来のアプリケーション層レベルの生存監視を説明するための図である。本発明の実施の形態に係るシステム構成図である。本発明の実施の形態におけるシステムの処理概要を説明するための図である。本発明の実施の形態におけるシステムの処理概要を説明するための図である。本発明の実施の形態におけるシステムの処理概要を説明するための図である。本発明の実施の形態におけるシステムの処理概要を説明するための図である。被監視サーバのアプリケーションの処理フローを示す図である。被監視サーバの監視エージェントの処理フローを示す図である。監視マネージャの処理フローを示す図である。コンピュータの機能ブロック図である。

符号の説明

１，９ネットワーク３クライアント端末
５被監視サーバ７監視マネージャ
５１アプリケーション５３ログＤＢ
５５監視エージェント
７１受信部７３監視処理部
７５リクエスト送信部

Claims

サーバにおける所定のアプリケーション・プログラムの状態を監視するための処理をコンピュータに実行させるためのプログラムであって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信するステップと、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信するステップと、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断するステップと、
をコンピュータに実行させる監視処理プログラム。
前記アプリケーション処理依頼を送信してから前記第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信し、前記アプリケーション処理依頼に対する応答を受信してから第４の所定時間経過するまでに前記監視エージェント・プログラムからの前記通知を受信しない場合、当該監視エージェント・プログラムに異常が生じていると判断するステップ
をさらにコンピュータに実行させる請求項１記載の監視処理プログラム。
サーバにおける所定のアプリケーション・プログラムの状態を監視する方法であって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信するステップと、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信するステップと、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断するステップと、
を含み、コンピュータにより実行される監視処理方法。
サーバにおける所定のアプリケーション・プログラムの状態を監視する装置であって、
前記所定のアプリケーション・プログラムから出力されるログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが第１の所定時間前における最新ログ・レコードと異なる場合に前記サーバにおける監視エージェント・プログラムから送信される通知を受信する手段と、
前記監視エージェント・プログラムからの前記通知を受信してから第２の所定時間経過するまでに次の前記通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信する手段と、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断する手段と、
を有する監視処理装置。
所定のアプリケーション・プログラムを実行し、前記所定のアプリケーション・プログラムから出力されるログ・レコードを監視する監視手段を有するサーバと、
前記所定のアプリケーション・プログラムの状態を監視する監視処理装置と、
を有し、
前記監視手段は、
第１の所定時間間隔毎に、前記ログ・レコードを格納しているアプリケーションログ格納部に格納されている最新ログ・レコードが前記第１の所定時間前における最新ログ・レコードと同一であるか判断する手段と、
前記アプリケーションログ格納部に格納されている最新ログ・レコードが前記第１の所定時間前における最新ログ・レコードと異なると判断された場合、所定の通知を前記監視処理装置に送信する通知手段と、
を有し、
前記監視処理装置は、
前記通知手段からの前記所定の通知を受信する手段と、
前記通知手段からの前記所定の通知を受信してから第２の所定時間経過するまでに次の前記所定の通知を受信しない場合、前記所定のアプリケーション・プログラムにアプリケーション処理依頼を送信する手段と、
前記アプリケーション処理依頼を送信してから第３の所定時間経過するまでに前記アプリケーション処理依頼に対する応答を前記所定のアプリケーション・プログラムから受信しない場合、当該所定のアプリケーション・プログラムに異常が生じていると判断する手段と、
を有する監視システム。