JP4230946B2 - アプリケーション監視装置、そのプログラム、及びその記録媒体。 - Google Patents

Description

本発明は、複数のプロセスで構成され、それぞれのプロセスが実行ログを出力するアプリケーションシステムの、システム障害を復旧する技術に関する。

２４時間連続稼動が必要である業務アプリケーションシステムにおいて、アプリケーションに異常が発生した場合、その異常を速やかに復旧し、業務への支障を最小限に留める必要がある。

そこで従来、複数のプロセスで構成されるコンピュータシステムにおいて、プロセスの異常を監視し、プロセスの異常終了を検知すると、そのプロセス名と終了コードを取得して対応する連動処理（再起動等）を実行し、上記異常を速やかに復旧していた（特許文献１参照）。
特開２０００−３１１０９９号公報

従来の自動復旧の仕組みはプロセスの異常のみを監視している。このため、見かけ上プロセスが正常に存在していればプロセスは正常なものとして判断されるため、プロセスが存在していても実際には業務アプリケーションとして正常に機能していないような場合、自動復旧の対象から外れてしまう。例えばＤＢへの書込みを行なうアプリケーションが排他で待ち状態になっている場合、プロセスは存在しているがアプリケーション自体は待ち状態のままなので処理は停止している。しかし従来の自動復旧の仕組みでは、プロセスが存在しているためアプリケーションの異常は検知できない。また、プロセスがゾンビプロセスとして残った場合、アプリケーションとしては正常に動作していない。しかしこのような場合もプロセスが存在しているためアプリケーションの異常を検知できない。

更に、従来のプロセス異常を監視して自動復旧する仕組みでは、異常を検知して復旧処理を行なった場合にプロセス異常に対応する復旧処理のみが行なわれるため、この復旧処理により上記異常の発端となっている原因が解消されていない場合もある。このような場合は復旧処理後に同一の異常が再び生じてしまい、同様の復旧処理が繰り返し行なわれることになる。そして、上記復旧処理が繰り返し行なわれても、当然、上記異常の発端となっている原因が解消されることはない。よってプロセス異常の監視・復旧だけでは解消されない種の異常が生じた場合、従来は異常が解消されないどころか同様の復旧処理が繰り返し行なわれることになり、業務に大きな支障をきたすため問題となっていた。

そこで本発明は、アプリケーションが正常に機能しているかどうかを監視する技術を提供し、更に復旧処理が適切に行なわれない場合に管理者に通知する技術を提供することを目的とする。

本発明は上記課題を解決するために以下のように構成する。
本発明のプログラムの態様一つは、アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させることを前提とし、プロセスのログファイルに出現するログメッセージを監視する機能と、前記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させる。

なお、前記アプリケーション障害に対する対応処理は、前記プロセス及び前記アプリケーション障害と判定されたログメッセージの種類との組み合わせによって任意に設定されていることが望ましい。

本発明のプログラムの態様のその他の一つは、アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させることを前提とし、プロセスのログファイルのログ更新時間を監視する機能と、前記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させる。

なお、前記アプリケーション障害の判定基準となる前記所定時間間隔は、前記判定を行なう時間帯ごとに任意に時間間隔が設定されている、ことが望ましい。
本発明のプログラムのその他の態様一つは、アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させることを前提とし、プロセスのログファイルに出現するログメッセージを監視する機能と、前記ログファイルのログ更新時間を監視する機能と、前記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合または前記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させる。

また、以上の各態様のプログラムは、前記対応処理の実行日時をプロセス毎に管理する機能と、前記プロセス毎に管理される実行日時から所定時間間隔内の実行回数を前記プロセス毎に算出する機能と、前記所定時間間隔内の実行回数が所定回数を超えた場合に対応処理エラーと判定し、前記所定時間間隔内の実行回数が所定回数を超えたプロセスを停止して監視対象から外す機能と、前記所定時間間隔内の実行回数が所定回数を超えたプロセスの管理者に前記対応処理エラーの情報を通知する機能と、を更にコンピュータに実現させるものであるとなお良い。

本発明のコンピュータ読み取り可能な記録媒体の態様の一つは、アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実現させるプログラムを記録し、プロセスのログファイルに出現するログメッセージを監視する機能と、前記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラムを記録する。

本発明のコンピュータ読み取り可能な記録媒体のその他の態様の一つは、アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実現させるプログラムを記録し、プロセスのログファイルのログ更新時間を監視する機能と、前記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラムを記録する。

なお、以上の各態様のコンピュータに読み取り可能な記録媒体は、上記各態様前記対応処理の実行日時をプロセス毎に管理する機能と、前記プロセス毎に管理される実行日時から所定時間間隔内の実行回数を前記プロセス毎に算出する機能と、前記所定時間間隔内の実行回数が所定回数を超えた場合に対応処理エラーと判定し、前記所定時間間隔内の実行回数が所定回数を超えたプロセスを停止して監視対象から外す機能と、前記所定時間間隔内の実行回数が所定回数を超えたプロセスの管理者に前記対応処理エラーの情報を通知する機能と、を更にコンピュータに実現させるプログラムを記録するとなお良い。

本発明のアプリケーション監視装置の態様の一つは、アプリケーション障害を検知して自動的に障害対応することを前提とし、プロセスのログファイルに出現するログメッセージを監視する機能と、前記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、を有する。

本発明のアプリケーション監視装置のその他の態様の一つは、アプリケーション障害を検知して自動的に障害対応することを前提とし、プロセスのログファイルのログ更新時間を監視する機能と、前記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、を有する。

本発明のアプリケーション監視装置のその他の態様の一つは、アプリケーション障害を検知して自動的に障害対応することを前提とし、プロセスのログファイルに出現するログメッセージを監視する機能と、前記ログファイルのログ更新時間を監視する機能と、前記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合または前記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、を有する。

また、以上の各態様のアプリケーション監視装置は、前記対応処理の実行日時をプロセス毎に管理する機能と、前記プロセス毎に管理される実行日時から所定時間間隔内の実行回数を前記プロセス毎に算出する機能と、前記所定時間間隔内の実行回数が所定回数を超えた場合に対応処理エラーと判定し、前記所定時間間隔内の実行回数が所定回数を超えたプロセスを停止して監視対象から外す機能と、前記所定時間間隔内の実行回数が所定回数を超えたプロセスの管理者に前記対応処理エラーの情報を通知する機能と、を更に有すると、なお良い。

本発明では、プロセスのログファイルにおいてログメッセージの出現頻度を監視する。 このため、アプリケーションの障害を上記ログメッセージの出現頻度から検知し、これに対応する復旧処理を自動で実行できるようになる。

また本発明は、プロセスのログファイルの更新時間間隔を監視する。このため、アプリケーションの障害を上記ログフィルの更新時間間隔から検知し、これに対応する復旧処理を自動で実行できるようになる。

更に本発明では、上記アプリケーション障害が検知された後に自動で実行される対応処理の実行頻度を監視する。このため、アプリケーション障害の復旧処理が適切ではなかった旨を自動で検知することが可能になり、それを管理者に通知することができる。

以上のように本発明では、プロセスのログファイルからアプリケーション異常を検出できる。このためプロセスの存在の有無を監視するだけでは検出できないアプリケーション障害を検出できるようになり、このように検出された障害に対して復旧処理が行なえる。また、以上のように復旧処理を行なって正常に対処できない場合は、その状況を検出し、管理者に通知できるようになるので、簡易的な障害については自動復旧させ、高度な障害については速やかに管理者に通知できるようになる。

以下、本発明を実施するための最良の形態を、図面を参照しながら詳細に説明する。
図１は、本発明の実施の形態におけるアプリケーション監視装置の一構成例である。
本装置は、ＣＰＵ（中央処理装置）、メモリ、外部記録部、入出力部、及び通信部が互いにバスを介して接続される一つ或いは複数のコンピュータによって構成され、各種のプログラムが外部記録装置からメモリにロードされ、ＣＰＵ（中央処理装置）で適宜実行されることにより、以下に詳述する機能を実現する。

同図に示されるように、本例のアプリケーション監視装置は、メモリにロードされた複数のプロセス（以下において、監視対象として扱われるプロセスを監視対象外のプロセスと区別して監視対象プロセスと呼ぶこととする）1のそれぞれの実行履歴を個別のログファイル２に出力するようにし、上記監視対象プロセス１と同様に該ログファイル２を監視の対象とすることによりアプリケーション障害を検知する。このログファイル２には、各プロセスを対象に検知されたログメッセージやログ更新時間などが含まれ、監視対象プロセスの存在の有無以外に上記ログファイル２のログメッセージやログ更新時間などからアプリケーション異常を検知することができる。そして、本アプリケーション監視装置ではそれらからアプリケーション障害を検知すると自動復旧（または障害対応処理ともいう）を試みる。

同図には、メモリにロードされた監視対象プロセスを監視するプロセス監視機能３、当該監視対象プロセスのログメッセージを監視するログメッセージ監視機能４、及び当該監視対象プロセスのログ更新時間を監視するログ更新時間監視機能５からなる監視機能６が構成されている。

各監視機能６は、アプリケーション障害状態の判定基準となる判定基準情報を記録するマスタ情報記録部７を参照し、該当する判定基準情報に基づく監視対象プロセスの存在の有無或いは該当する判定基準情報とログファイルの持つ情報（ログメッセージやログ更新時間など）との比較からアプリケーション障害の有無を判定する。

また、各監視機能６は、アプリケーション障害と判定した場合、上記判定基準情報を記録するマスタ情報記録部７に対し上記判定基準情報と対応付けされて記録される対応処理情報（例えばプロセスの種類毎に指定された対応処理方法）を基に自動復旧処理（または対応処理ともいう）を行なう。

更に本例では、監視機能６によって実行された自動復旧処理の実行回数を逐次記録する対応処理実行ログ記録部８を備え、該対応処理実行ログ記録部８に記録された対応処理実行回数とマスタ情報記録部７に記録された判定基準情報とから上記対応処理の適用頻度を監視する対応処理実行ログ監視機能９が構成される。該対応処理実行ログ監視機能９は、上記対応処理の適用頻度が上記マスタ情報記録部７に記録される適用頻度の閾値を超えると、アプリケーション障害（特にこの場合は上記対応処理が適切な処理ではない場合なので、厳密に言うと対応処理エラーである）である状態の通知（これもまた障害対応処理の一つである）を該当する管理者へ行なう。

以上を整理すると本構成のアプリケーション監視装置では次の１から４の監視・復旧処理を行なう。
１．マスタ情報記録部７の判定基準情報に基づき、プロセス監視機能３は監視対象プロセス１の存在の有無を判定し、監視対象プロセス１が存在しない場合にアプリケーション障害の発生と認定して特定の復旧処理を行なう。

２．マスタ情報記録部７の判定基準情報に基づき、ログメッセージ監視機能４は監視対象プロセス１のログファイル２への特定のログメッセージの出現を調べ、特定のログメッセージの出現頻度に応じてアプリケーション障害の発生と認定し、特定の復旧処理を行なう。

３．マスタ情報記録部７の判定基準情報に基づき、ログ更新時間監視機能５は監視対象プロセス１のログファイル２のログ更新間隔をチェックし、所定時間以上ログ更新が行なわれない場合にアプリケーション障害の発生と認定して特定の復旧処理を行なう。

４．マスタ情報記録部７の判定基準情報に基づき、対応処理実行ログ監視機能９は対応処理実行ログ記録部８に記録された各監視機能６の復旧処理が行なわれた頻度をチェックし、復旧処理が行なわれた頻度が所定回数よりも高い場合に適切な復旧処理が行なわれていないと認定して管理者へ通知する。

上記の機能をより理解しやすいように、以下に具体的なテーブル例と動作例を挙げて説明する。
そこで本例のマスタ情報記録部７において提供される情報（上記判定基準情報を含む情報）を以下のように整理しておく。

アプリケーション障害を該当する管理者へ通知するための管理者マスタ情報１０、プロセスを一意に識別するためのプロセスマスタ情報１１、プロセス監視機能３に対して上記判定基準情報及び対応処理情報を提供するプロセス監視マスタ情報１２、ログメッセージ監視機能４に対して上記判定基準情報及び対応処理情報を提供するログメッセージ監視マスタ情報１３、ログ更新時間監視手段５に対して対応処理情報を提供するログ更新時間監視マスタ情報１４、ログ更新時間監視手段５に対して判定基準情報を提供するログ更新時間監視閾値マスタ情報１５、及び対応処理実行ログ監視手段９に対して判定基準情報を提供する対応処理実行ログ監視マスタ情報１６である（以下において、情報１０から１６を総称してマスタ情報と呼ぶことにする）。

なお、上記マスタ情報記録部７に記録される各マスタ情報は、プロセス登録ツール１７を利用して情報の登録・更新・削除が可能である。
また、監視対象となる各プロセスの起動・停止をプロセス操作ツール１８から行なうことができる。

続いて、上記各マスタ情報を記録するマスタ情報記録部７のテーブル、対応処理実行ログ、ログファイルの構成を一例を挙げて示すと共に、該構成におけるアプリケーション障害監視・復旧動作について説明する。

図２から図４は上記各マスタ情報を記録するマスタ情報記録部７のテーブル例である。
図２（a）は管理者マスタテーブルの一例である。
同図の管理者マスタテーブル２０は、カラム「プロセスＳＥＱ」２００及びカラム「管理者」２０１によって構成される。

カラム「プロセスＳＥＱ」２００にはプロセスを一意に識別する番号が格納される。また、カラム「管理者」２０１にはプロセスに対応する管理者のメールアドレスが格納される。

なお、以下のテーブルにおいても上記同様にカラム「プロセスＳＥＱ」が構成され、このカラムは外部キーに設定されている。よって、特に説明しない限り、そのカラムにはプロセスを一意に識別する番号が格納される。

図２（b）はプロセスマスタテーブルの一例である。
同図のプロセスマスタテーブル２１は、カラム「プロセスＳＥＱ」２１０、カラム「プロセス名」２１１、カラム「起動シェル」２１２、カラム「停止シェル」２１３、カラム「状態」２１４、及びカラム「ログファイル名」２１５によって構成される。

カラム「プロセス名」２１１にはプロセスＳＥＱによって一意に識別されるプロセス名前が格納される。
カラム「起動シェル」２１２及びカラム「停止シェル」２１３にはそれぞれ、起動シェルのファイル名、停止シェルのファイル名が格納される。本例では「起動シェル」２１２に、再起動を実行する起動シェルのファイル名が格納される。

カラム「状態」２１４にはプロセスを監視対象に指定するか否かを示すフラグが格納される。本例では「０」を監視対象外、「１」を監視対象とする。なお、「０」は手動でアプリケーションを停止することにより監視対象外とすることができる。

カラム「ログファイル名」２１５には当該プロセスのログファイルのファイル名が格納される。
図３（ａ）は、プロセス監視マスタテーブルの一例である。

同図のプロセス監視マスタテーブル３０は、カラム「プロセスＳＥＱ」３００、カラム「監視間隔」３０1、カラム「対応処理フラグ」３０２、カラム「障害対応シェル」３０３、及びカラム「通知フラグ」３０４によって構成される。

カラム「監視間隔」３０1にはプロセスを監視する監視間隔の時間が格納される。本例では分単位の数字が格納される。
カラム「対応処理フラグ」３０２にはアプリケーション障害発生時の対応処理方法を示すフラグが格納される。本例では、処理を行なわない場合を「０」、障害調査用にログファイルを退避し、プロセスマスタテーブル２１のカラム「起動シェル」２１２の名前からプロセスを再起動する場合を「１」、障害調査用にログファイルを退避し、プロセス監視マスタテーブル３０のカラム「障害対応シェル」３０３から該「障害対応シェル」３０３に格納される対応処理を行なう場合を「２」とする。

カラム「障害対応シェル」３０３には上記対応処理を行なう障害対応シェルのファイル名が格納される。
カラム「通知フラグ」３０４には管理者へ通知するか否かのフラグが格納される。本例では通知しない場合を「０」、通知する場合を「１」とする。

図３（ｂ）は、ログメッセージ監視マスタテーブルの一例である。
同図のログメッセージ監視マスタテーブル３１は、カラム「プロセスＳＥＱ」３１０、カラム「監視間隔」３１１、カラム「監視メッセージ」３１２、カラム「単位時間」３１３、カラム「出現回数閾値」３１４、カラム「対応処理フラグ」３１５、カラム「障害対応シェル」３１６、及びカラム「通知フラグ」３１７によって構成される。
カラム「監視間隔」３１１にはログメッセージを監視する監視間隔の時間が格納される。本例では分単位の数字が格納される。

カラム「監視メッセージ」３１２にはアプリケーション障害と判定されるログメッセージが格納される。
カラム「単位時間」３１３には後述する出現回数の閾値が設定される単位時間が格納される。本例では分単位の数字が格納される。

カラム「出現回数閾値」３１４には、カラム「監視メッセージ」３１２に格納されるメッセージがカラム「単位時間」に格納される単位時間あたりに出現する回数の閾値が格納される。

カラム「対応処理フラグ」３１５にはアプリケーション障害発生時の対応処理方法を示すフラグが格納される。本例では、処理を行なわない場合を「０」、障害調査用にログファイルを退避し、プロセスマスタテーブル２１のカラム「起動シェル」２１２の名前からプロセスを再起動する場合を「１」、障害調査用にログファイルを退避し、ログメッセージ監視マスタテーブル３１のカラム「障害対応シェル」３１６から該「障害対応シェル」３１６に格納される対応処理を行なう場合を「２」とする。

なお、「障害対応シェル」３１６及びカラム「通知フラグ」３１７は、プロセス監視マスタテーブル３０のカラム「障害対応シェル」３０３及びカラム「通知フラグ」３０４においてそれぞれ説明した通りのものであるため、ここでの説明を省略する。

図３（ｃ）は、ログ更新時間監視マスタテーブルの一例である。
本例のログ更新時間監視マスタテーブル３２は、カラム「プロセスＳＥＱ」３２０、カラム「監視間隔」３２1、カラム「対応処理フラグ」３２２、カラム「障害対応シェル」３２３、及びカラム「通知フラグ」３２４によって構成される。

カラム「監視間隔」３２１にはログ更新時間を監視する監視間隔の時間が格納される。本例では分単位の数字が格納される。
カラム「対応処理フラグ」３２２にはアプリケーション障害発生時の対応処理方法を示すフラグが格納される。本例では、処理を行なわない場合を「０」、障害調査用にログファイルを退避し、プロセスマスタテーブル２１のカラム「起動シェル」２１２の名前からプロセスを再起動する場合を「１」、障害調査用にログファイルを退避し、ログ更新時間監視マスタテーブル３２のカラム「障害対応シェル」３２３から該「障害対応シェル」３２３に格納される対応処理を行なう場合を「２」とする。

なお、「障害対応シェル」３２３及びカラム「通知フラグ」３２４は、プロセス監視マスタテーブル３０のカラム「障害対応シェル」３０３及びカラム「通知フラグ」３０４においてそれぞれ説明した通りのものであるため、ここでの説明を省略する。

図３（ｄ）は、ログ更新時間監視閾値マスタテーブルの一例である。
同図のログ更新時間監視閾値マスタテーブル３３は、カラム「プロセスＳＥＱ」３３０、カラム「曜日」３３１、０時から２３時まで１時間ごとに分けられたカラム「時刻」３３２によって構成される。

カラム「曜日」３３１には曜日が格納される。
カラム「時刻」３３２には、カラム「曜日」３３１に格納される曜日の０時から２３時で示される各時間帯に対して、各々、ログ更新の時間間隔の閾値が格納される。本例では分単位で数字が格納される。

図４は、対応処理実行ログ監視マスタテーブルの一例である。
同図の対応処理実行ログ監視マスタテーブル４０は、カラム「プロセスＳＥＱ」４００、カラム「監視間隔」４０１、カラム「単位時間」４０２、カラム「対応処理実行回数閾値」４０３、及びカラム「通知フラグ」４０４によって構成される。

カラム「監視間隔」４０１には対応処理実行ログを監視する監視間隔の時間が格納される。本例では分単位の数字が格納される。
カラム「単位時間」４０２には後述する出現回数の閾値が設定される単位時間が格納される。本例では分単位の数字が格納される。

カラム「対応処理実行回数閾値」４０３には、対応処理実行ログに書き出された対応処理の実行履歴を対象とし、カラム「単位時間」に格納される単位時間あたりに対応処理が実行される回数の閾値が格納される。

カラム「通知フラグ」４０４には管理者へ通知するか否かのフラグが格納される。本例では通知しない場合を「０」、通知する場合を「１」とする。
図５は、対応処理実行ログを格納する対応処理実行ログテーブルの一例である。

同図の対応処理実行ログテーブル５０は、カラム「ＳＥＱ」５００、カラム「プロセスＳＥＱ」５０１、カラム「対応処理フラグ」５０２、及びカラム「実行時刻」５０３によって構成されている。

カラム「ＳＥＱ」５００は、任意の対応処理の実行を一意に識別するための番号である。
カラム「プロセスＳＥＱ」５０１は、マスタ情報記録部７の各テーブルの「プロセスＳＥＱ」に該当する。

カラム「対応処理フラグ」５０２は、対応処理の種類の指定に利用できるが、特に本例では使用しない。
カラム「実行時刻」５０３は、対応処理が実行された日時が格納される。本例では、西暦／月／日、時：分：秒が格納される。

本対応処理実行ログテーブル５０には、対応処理が実行されるたびに上記各カラムに対応するレコードが追加される。
図６は監視対象プロセスのログファイルの一例である。

同図のログファイルの例では、例えば一行目を例に挙げると「２００４０１２８２３２２」は２００４年１月２８日２３時２２分を意味し、「ＩＮＦＯ」はログメッセージを意味している。

続いて、上記構成の基で実行させるアプリケーション監視動作の一例を説明する。
図７は、監視対象プロセスに対する監視及びアプリケーション障害時の対応処理のフローチャートである。

本例では５分間待機してから（Ｓ７００）、監視対象プロセスの監視を行なう。
先ず、プロセスマスタテーブル２１から、メモリにロードされたプロセスに該当するプロセス名のレコードを取得し、カラム「状態」２１４の値を調べる（Ｓ７０２）。

ここで上記値が「０」の場合、アプリケーションが停止状態にあるため監視の必要はなく、ステップＳ７００に戻る。
また、上記値が「１」の場合、監視対象として設定されているため続くステップＳ７０４の処理を行なう。

ステップＳ７０４においては対応するプロセスＳＥＱ番号のレコードをプロセス監視マスタテーブル３０から取得し、「監視間隔」３０１の値を調べる。
現在時刻が監視間隔の値の倍数でない場合、ステップＳ７００に戻る。

また、現在時刻が監視間隔の値の倍数である場合、続いてプロセスの存在の有無を調べる（Ｓ７０６）。
ここでプロセスの存在が確認されると、ステップＳ７００に戻る。

また、プロセスが存在しないと判定された場合には、以下に述べる「対応処理フロー」が実行される。
先ず、対応するプロセスＳＥＱ番号のレコードをプロセス監視マスタテーブル３０から取得し、「対応処理フラグ」３０２の値を調べる（Ｓ７０８）。

対応処理フラグの値が「０」の場合、処理を実行せずに後述するステップＳ７１０の処理に移行する。
また、対応処理フラグの値が「１」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ７１２）、その後、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「起動シェル」２１２によって指定されるプロセスの起動を実行し（Ｓ７１４）、ステップＳ７１０の処理に移行する。

また更に、対応処理フラグの値が「２」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ７１６）、その後、対応するプロセスＳＥＱ番号のレコードをプロセス監視マスタテーブル３０から取得し、カラム「障害対応シェル」３０３によって指定される障害対応シェルを実行し（Ｓ７１８）、ステップＳ７１０の処理に移行する。

ステップＳ７１０においては、対応するプロセスＳＥＱ番号のレコードをプロセス監視マスタテーブル３０から取得し、カラム「通知フラグ」３０４の値を調べる。この値が「０」の場合、ステップＳ７００の処理に戻り、「１」の場合、対応するプロセスＳＥＱ番号のレコードを管理者マスタテーブル２０から取得し、カラム「管理者」２０１によって指定される管理者のメールアドレスに通知してから（Ｓ７２０）、ステップＳ７００の処理に戻る。

図８は、監視対象プロセスにおけるログメッセージに対する監視及びアプリケーション障害時の対応処理のフローチャートである。
本例では５分間待機してから（Ｓ８００）、監視対象プロセスの監視を行なう。

先ず、プロセスマスタテーブル２１から、メモリにロードされたプロセスに該当するプロセス名のレコードを取得し、カラム「状態」２１４の値を調べる（Ｓ８０２）。
ここで上記値が「０」の場合、アプリケーションが停止状態にあるため監視の必要はなく、ステップＳ８００に戻る。

また、上記値が「１」の場合、監視対象として設定されているため続くステップＳ８０４の処理を行なう。
ステップＳ８０４においては対応するプロセスＳＥＱ番号のレコードをログメッセージ監視マスタテーブル３１から取得し、「監視間隔」３１１の値を調べる。

現在時刻が監視間隔の値の倍数でない場合、ステップＳ８００に戻る。
また、現在時刻が監視間隔の値の倍数である場合、ログファイルにおける所定のログメッセージの出現頻度を調べ、この出現頻度が所定の閾値を超えているかどうか調べる（Ｓ８０６）。

ここで所定のログメッセージの出現頻度が所定の閾値を超えていないと判定されると、ステップＳ８００に戻る。
また、所定の閾値を超えていると判定されると、以下に述べる「対応処理フロー」が実行される。

先ず、対応するプロセスＳＥＱ番号のレコードをログメッセージ監視マスタテーブル３１から取得し、「対応処理フラグ」３１５の値を調べる（Ｓ８０８）。
対応処理フラグの値が「０」の場合、処理を実行せずに後述するステップＳ８１０の処理に移行する。

また、対応処理フラグの値が「１」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ８１２）、その後、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「起動シェル」２１２によって指定されるプロセスの起動を実行し（Ｓ８１４）、ステップＳ８１０の処理に移行する。

また更に、対応処理フラグの値が「２」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ８１６）、その後、対応するプロセスＳＥＱ番号のレコードをログメッセージ監視マスタテーブル３１から取得し、カラム「障害対応シェル」３１６によって指定される障害対応シェルを実行し（Ｓ８１８）、ステップＳ８１０の処理に移行する。

ステップＳ８１０においては、対応するプロセスＳＥＱ番号のレコードをログメッセージ監視マスタテーブル３１から取得し、カラム「通知フラグ」３１７の値を調べる。この値が「０」の場合、ステップＳ８００の処理に戻り、「１」の場合、対応するプロセスＳＥＱ番号のレコードを管理者マスタテーブル２０から取得し、カラム「管理者」２０１によって指定される管理者のメールアドレスに通知してから（Ｓ８２０）、ステップＳ８００の処理に戻る。

図９は、監視対象プロセスにおけるログ更新時間に対する監視及びアプリケーション障害時の対応処理のフローチャートである。
本例では５分間待機してから（Ｓ９００）、監視対象プロセスの監視を行なう。

先ず、プロセスマスタテーブル２１から、メモリにロードされたプロセスに該当するプロセス名のレコードを取得し、カラム「状態」２１４の値を調べる（Ｓ９０２）。
ここで上記値が「０」の場合、アプリケーションが停止状態にあるため監視の必要はなく、ステップＳ９００に戻る。

また、上記値が「１」の場合、監視対象として設定されているため続くステップＳ９０４の処理を行なう。
ステップＳ９０４においては対応するプロセスＳＥＱ番号のレコードをログ更新時間監視マスタテーブル３２から取得し、カラム「監視間隔」３２１の値を調べる。

現在時刻が監視間隔の値の倍数でない場合、ステップＳ９００に戻る。
また、現在時刻が監視間隔の値の倍数である場合、次のように、ログファイルの更新間隔を調べ、この更新間隔が所定の閾値を超えているかどうか調べる（Ｓ９０６）。

先ず、ログファイルのファイル名などに示された更新時刻を取得し、該更新時刻から現在時刻を差し引いて更新時間間隔を計算する。次に、ログ更新時間監視閾値マスタテーブル３３から対応するプロセスＳＥＱ番号の現在の曜日のレコードを取得し、現在の時間帯のカラムに格納される値（閾値）を取得する。そして、上記更新時間間隔と上記閾値とを比較する。

ここで、上記更新時間間隔が上記閾値を超えなければ、ステップＳ９００の処理に戻る。
また、上記更新時間間隔が上記閾値を超えた場合には、以下に述べる「対応処理フロー」が実行される。

先ず、対応するプロセスＳＥＱ番号のレコードをログ更新時間監視マスタテーブル３２から取得し、「対応処理フラグ」３２２の値を調べる（Ｓ９０８）。
対応処理フラグの値が「０」の場合、処理を実行せずに後述するステップＳ９１０の処理に移行する。

また、対応処理フラグの値が「１」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ９１２）、その後、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「起動シェル」２１２によって指定されるプロセスの起動を実行し（Ｓ９１４）、ステップＳ９１０の処理に移行する。

また更に、対応処理フラグの値が「２」の場合、障害調査用として、対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、カラム「ログファイル名」２１５によって指定されるログファイルを一旦外部記録装置に退避し（Ｓ９１６）、詳しくは後述するが、その後、対応するプロセスＳＥＱ番号のレコードをログ更新時間監視マスタテーブル３２から取得し、カラム「障害対応シェル」３２３によって指定される障害対応シェルを実行し（Ｓ９１８）、ステップＳ９１０の処理に移行する。

ステップＳ９１０においては、対応するプロセスＳＥＱ番号のレコードをログ更新時間監視マスタテーブル３２から取得し、カラム「通知フラグ」３２４の値を調べる。この値が「０」の場合、ステップＳ９００の処理に戻り、「１」の場合、対応するプロセスＳＥＱ番号のレコードを管理者マスタテーブル２０から取得し、カラム「管理者」２０１によって指定される管理者のメールアドレスに通知してから（Ｓ９２０）、ステップＳ９００の処理に戻る。

ここで、障害対応シェル実行例を、図３（ｂ）に示されるログメッセージ監視マスタテーブル３１を基に説明する。
但し、図３（ｂ）のログメッセージ監視マスタテーブル３１のカラム「障害対応シェル」３１６に示される「ａａａ．ｓｈ」は、後述のプロセスＢ再起動後にプロセスＡを再起動するシェルとする。

例えばプロセスＡ（プロセスＳＥＱ：００１、ソケットクライアントプロセス）とプロセスＢ（ソケットサーバプロセス）が存在する場合、プロセスＡからプロセスＢに対してソケット通信が行なわれている。

このとき、プロセスＡのログファイルに、アプリケーション障害を示すログメッセージの「ＥＲＲＯＲ」が出現すると、ログメッセージ監視マスタテーブル３１のカラム「対応処理フラグ」３１５の値「１」に基づいてプロセスＡを再起動する。これに対しプロセスＡのログファイルに、通信障害を示すログメッセージの「ＳＯＣＫＥＴ」が出現すると、ログメッセージ監視マスタテーブル３１のカラム「対応処理フラグ」３１５の値「２」に基づいてカラム「障害対応シェル」３１６の「ａａａ．ｓｈ」を実行する。この障害対応シェルは上述したようにプロセスＢ再起動後にプロセスＡを再起動するためのシェルなので、その順に再起動を実行し、上記通信障害を回避する。

なお、特に説明しないが後述する障害対応シェルも、参照するテーブルは異なるが、同様の手順で処理を説明することができる。
図１０は、対応処理実行ログの監視及びアプリケーション障害時の対応処理のフローチャートである。

本例では５分間待機してから（Ｓ１０００）、監視対象プロセスの監視を行なう。
先ず、プロセスマスタテーブル２１から、メモリにロードされたプロセスに該当するプロセス名のレコードを取得し、カラム「状態」２１４の値を調べる（Ｓ１００２）。

ここで上記値が「０」の場合、アプリケーションが停止状態にあるため監視の必要はなく、ステップＳ１０００に戻る。
また、上記値が「１」の場合、監視対象として設定されているため続くステップＳ１００４の処理を行なう。

ステップＳ１００４においては対応するプロセスＳＥＱ番号のレコードを対応処理実行ログ監視マスタテーブル４０から取得し、カラム「監視間隔」４０１の値を調べる。
現在時刻が監視間隔の値の倍数でない場合、ステップＳ１０００に戻る。

また、現在時刻が監視間隔の値の倍数である場合、実行された対応処理の単位時間あたりの回数を調べ、この回数が所定の閾値を超えているかどうか判定する（Ｓ１００６）。
このステップＳ１００６における「単位時間あたりの対応処理実行回数の算出処理」は例えばＳＱＬ文を用いるものとすると、次のように記述できる。

（ＳＱＬ文）
ＳＥＬＥＣＴ ＣＯＵＮＴ（＊）ＦＲＯＭ 対応処理実行ログ
ＷＨＷＲＥ プロセスＳＥＱ＝‘＊＊＊’
ＡＮＤ 実行時刻＞現在時刻−単位時間

そして、得られた結果（すなわち現在時刻から遡って所定の単位時間内に対応処理が実行された回数）と対応処理実行ログ監視マスタテーブル４０のカラム「対応処理実行回数閾値」４０３の値とを比較することにより判定を行なう。

ここで、上記実行回数が上記閾値を超えなければ、ステップＳ１０００の処理に戻る。
また、上記実行回数が上記閾値を超えた場合には対応するプロセスＳＥＱ番号のレコードをプロセスマスタテーブル２１から取得し、そしてカラム「停止シェル」２１３に指定された停止シェルを実行して当該プロセスを停止し、当該プロセスのカラム「状態」２１４の値を「０」に変更して当該プロセスを監視対象から外す（Ｓ１００８）。

続いて、対応するプロセスＳＥＱ番号のレコードを対応処理実行ログ監視マスタテーブル４０から取得し、カラム「通知フラグ」４０４の値を調べる。この値が「０」の場合、ステップＳ１０００の処理に戻り、「１」の場合、対応するプロセスＳＥＱ番号のレコードを管理者マスタテーブル２０から取得し、カラム「管理者」２０１によって指定される管理者のメールアドレスに通知してから（Ｓ１０２０）、ステップＳ１０００の処理に戻る。

以上説明してきた各処理はプログラムの形態で配布することもできる。
その場合、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの記録媒体に上記プログラムやファイルを記録させて配布したり、或いは、公衆網等で用いられる伝送媒体を介して、そのプログラムやファイルの一部、若しくは全部を配信するようにしたりすることができる。この場合、それを受け取ったユーザは、ＣＤ−ＲＯＭ装置などの読み取り装置（入出力部の一部）を利用してフロッピー（登録商標）ディスクやＣＤ−ＲＯＭやＤＶＤなどの可搬型記録媒体から上記プログラムやファイルを外部記録部にコピーしたり、コンピュータの通信部を介してインターネットから上記プログラムやファイルを外部記録部にコピーしたりすることができる。そして、ＣＰＵで実行することにより、ユーザのコンピュータ上でも上述した機能を実現できる。

以上に述べたように、本発明の実施の形態では、プロセスのログファイルからアプリケーション異常を検出できる。このためプロセスの存在の有無を監視するだけでは検出できないアプリケーション障害を検出できるようになり、このように検出された障害に対して復旧処理が行なえる。また、以上のように復旧処理を行なって正常に対処できない場合は、その状況を検出し、管理者に通知できるようになるので、簡易的な障害については自動復旧させ、高度な障害については速やかに管理者に通知できるようになる。

（付記１）アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させるプログラムであって、プロセスのログファイルに出現するログメッセージを監視する機能と、上記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラム。

（付記２）上記アプリケーション障害に対する対応処理は、上記プロセス及び上記アプリケーション障害と判定されたログメッセージの種類との組み合わせによって任意に設定されている、ことを特徴とする付記１に記載のプログラム。

（付記３）上記対応処理の実行日時をプロセス毎に管理する機能と、上記プロセス毎に管理される実行日時から所定時間間隔内の実行回数を上記プロセス毎に算出する機能と、上記所定時間間隔内の実行回数が所定回数を超えた場合に対応処理エラーと判定し、上記所定時間間隔内の実行回数が所定回数を超えたプロセスを停止して監視対象から外す機能と、上記所定時間間隔内の実行回数が所定回数を超えたプロセスの管理者に上記対応処理エラーの情報を通知する機能と、を更にコンピュータに実現させる付記１または２に記載のプログラム。

（付記４）アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させるプログラムであって、プロセスのログファイルのログ更新時間を監視する機能と、上記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラム。

（付記５）上記アプリケーション障害の判定基準となる上記所定時間間隔は、上記判定を行なう時間帯ごとに任意に時間間隔が設定されている、ことを特徴とする付記４に記載のプログラム。

（付記６）上記対応処理の実行日時をプロセス毎に管理する機能と、上記プロセス毎に管理される実行日時から所定時間間隔内の実行回数を上記プロセス毎に算出する機能と、上記所定時間間隔内の実行回数が所定回数を超えた場合に対応処理エラーと判定し、上記所定時間間隔内の実行回数が所定回数を超えたプロセスを停止して監視対象から外す機能と、上記所定時間間隔内の実行回数が所定回数を超えたプロセスの管理者に上記対応処理エラーの情報を通知する機能と、を更にコンピュータに実現させる付記４または５に記載のプログラム。

（付記７）アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実現させるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、プロセスのログファイルに出現するログメッセージを監視する機能と、上記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラムを記録したコンピュータ読み取り可能な記録媒体。

（付記８）アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実現させるプログラムを記録したコンピュータ読み取り可能な記録媒体であって、プロセスのログファイルのログ更新時間を監視する機能と、上記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、をコンピュータに実現させるプログラムを記録したコンピュータ読み取り可能な記録媒体。

（付記９）アプリケーション障害を検知して自動的に障害対応するコンピュータによる、アプリケーション障害を検知して自動的に障害対応する方法であって、プロセスのログファイルに出現するログメッセージを監視し、上記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する、ことを特徴とする方法。

（付記１０）アプリケーション障害を検知して自動的に障害対応するコンピュータによる、アプリケーション障害を検知して自動的に障害対応する方法であって、プロセスのログファイルのログ更新時間を監視し、上記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する、ことを特徴とする方法。

（付記１１）アプリケーション障害を検知して自動的に障害対応するアプリケーション監視装置であって、プロセスのログファイルに出現するログメッセージを監視する機能と、上記ログファイルにおける所定のログメッセージの出現頻度が所定回数以上であった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、を有することを特徴とするアプリケーション監視装置。

（付記１２）アプリケーション障害を検知して自動的に障害対応するアプリケーション監視装置であって、プロセスのログファイルのログ更新時間を監視する機能と、上記ログファイルのログ更新が所定時間間隔以上行なわれなかった場合にアプリケーション障害と判定し、該アプリケーション障害に対する対応処理を実行する機能と、を有することを特徴とするアプリケーション監視装置。

本発明の実施の形態におけるアプリケーション監視装置の一構成例である。 管理者マスタテーブル／プロセスマスタテーブルの一例である。 プロセス監視マスタテーブル／ログメッセージ監視マスタテーブル／ログ更新時間監視マスタテーブル／ログ更新時間監視閾値マスタテーブルの一例である。 対応処理実行ログ監視マスタテーブルの一例である。 対応処理実行ログを格納する対応処理実行ログテーブルの一例である。 監視対象プロセスのログファイルの一例である。 監視対象プロセスに対する監視及びアプリケーション障害時の対応処理のフローチャートである。 監視対象プロセスにおけるログメッセージに対する監視及びアプリケーション障害時の対応処理のフローチャートである。 監視対象プロセスにおけるログ更新時間に対する監視及びアプリケーション障害時の対応処理のフローチャートである。 対応処理実行ログの監視及びアプリケーション障害時の対応処理のフローチャートである。

符号の説明

１ 監視対象プロセス
２ ログファイル
３ プロセス監視機能
４ ログメッセージ監視機能
５ ログ更新時間監視機能
６ 監視機能
７ マスタ情報記録部
８ 対応処理実行ログ記録部
９ 対応処理実行ログ監視機能

Claims (2)

1. アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させるプログラムであって、
   プロセスのログファイルに出現するログメッセージを監視するステップと、
   前記ログファイルにおける所定のログメッセージの出現頻度が前記プロセスの該ログメッセージ毎に予め設定された所定回数以上であった場合にアプリケーション障害と判定するステップと、
   前記判定されたアプリケーション障害に予め対応付けられている対応処理を実行するステップと、
   前記実行された対応処理の実行日時を前記プロセス毎に管理するステップと、
   前記管理されたプロセス毎の前記対応処理の実行日時から予め該プロセス毎に設定された所定時間間隔内の前記対応処理の実行回数を該プロセス毎に算出するステップと、
   前記所定時間間隔内の前記実行回数が予め前記プロセス毎に設定された閾値を超えたプロセスを停止させて監視対象から外すステップと
   をコンピュータに実行させることを特徴とするアプリケーション監視プログラム。
2. アプリケーション障害を検知して自動的に障害対応する処理をコンピュータに実行させるプログラムであって、
   プロセスのログファイルのログ更新時間を監視するステップと、
   前記ログファイルのログ更新が前記プロセス毎に予め設定された所定時間間隔以上行われなかった場合にアプリケーション障害と判定するステップと、
   前記判定されたアプリケーション障害に予め対応付けられている対応処理を実行するステップと、
   前記実行された対応処理の実行日時を前記プロセス毎に管理するステップと、
   前記管理されたプロセス毎の前記対応処理の実行日時から予め該プロセス毎に設定された所定時間間隔内の前記対応処理の実行回数を該プロセス毎に算出するステップと、
   前記所定時間間隔内の前記実行回数が予め前記プロセス毎に設定された閾値を超えたプロセスを停止させて監視対象から外すステップと
   をコンピュータに実行させることを特徴とするアプリケーション監視プログラム。

Images