JP5821471B2 - 情報処理装置、プロセス監視方法、プロセス監視プログラム、記録媒体 - Google Patents

Description

本発明は、情報処理装置、プロセス監視方法、プロセス監視プログラム、記録媒体に関する。

Ｊａｖａ（登録商標）仮想マシンにおいて、プロセスが異常終了する場合がある。プロセスが異常終了する原因としては、例えば、ヒープ領域の不足がある。ヒープ領域はプロセスが使用するメモリ領域の１つであって、その大きさには上限が設定される。プロセスが異常終了すると、プロセスにおいて業務アプリケーションプログラム（以下、業務アプリケーション）を実行することができなくなり、業務アプリケーションの実行が継続できなくなる。

そこで、プロセスが異常終了する前にプロセスが異常終了する可能性が検出され、例えばオペレータに対して警告が出力される。例えば、ヒープ領域の使用量が閾値を超えた場合、警告メッセージが出力される。これにより、プロセスの異常終了を回避して業務アプリケーションの実行を継続する。

また、コンピュータのハードウェア情報を監視し比較して異常を検出することが提案されている。例えば、リクエスト停止ノード選択手段がクラスタを構成する複数の被障害監視ノードのうちリクエストの分配を停止するノードを選択し、リクエスト停止手段が選択されたノードへのリクエストの配信を停止し、希少ノード計算手段が、選択されたノードの詳細情報を詳細情報格納部より取得し、この詳細情報を用いて複数の被障害監視ノードの中から資源の利用状況が他の被障害監視ノードとは異なるパターンを示すノードを算出し、クラスタ障害推定手段が希少ノード計算手段によって計算された計算結果を用いて異常状態にあるノードを検出することが提案されている。

また、制御対象の状態を取り込み、あらかじめ備えられたタスクを実行することにより決定された信号を該制御対象に出力することを繰り返すコントローラを複数備えるとともに、該複数のコントローラがネットワークで接続された分散制御システムにおいて、前記制御対象のタスクの起動関係を格納し、該タスクの起動関係に関する情報と該コントローラで現在実行中のタスクに関する情報に基づいて近々実行順序の来るタスクを特定するシステムシミュレータと、前記複数のコントローラより前記システムシミュレータにより前記特定されたタスクを実行するコントローラを決定するタスクブローカとを備えることが提案されている。

特開２００７−１２２３３０号公報 特許第３７８７３５９号公報

例えば、アプリケーションの障害等の何らかの異常が発生しているプロセスが存在する場合において、異常が発生しているプロセスのヒープ領域の使用量が、閾値を超えない可能性がある。この場合には、ヒープ領域の使用量の閾値を用いても、プロセスが異常終了する可能性を検出することはできない。

また、コンピュータのハードウェア情報を監視し比較して異常を検出する場合には、コンピュータ単位でハードウェア情報が比較される。このため、業務アプリケーションに固有の異常は、検出することができない。

本発明の一側面によれば、アプリケーションに起因してプロセスが異常終了する可能性を検出することを目的とする。

開示される情報処理装置は、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する収集部と、複数のプロセスのうちのあるプロセスに関する特性情報が、複数のプロセスのうち、あるプロセスを除いたプロセスのいずれの特性情報とも特性が異なる場合に、あるプロセスについて異常が発生したと判断する判断部とを含む。

開示される情報処理装置の一側面によれば、アプリケーションに起因してプロセスが異常終了する可能性を検出することができる。

情報処理システムの一例を示す図である。 情報処理装置の一例を示す図である。 プロセス監視処理の説明図である。 情報処理装置のハードウェアの構成の一例を示す図である。 プロセス監視処理フローである。 プロセス監視処理フローである。 プロセス調査処理フローである。

プロセスにおける異常の種類によっては、異常検出のための閾値それ自体を決定することができない場合がある。この場合には、異常検出のための閾値を用いてプロセスが異常終了する可能性を検出することはできない。

例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）において、ステータスコード２００（ＯＫ）が、クライアントからの「リクエストは成功した」ことを示すコードとして規定されている。ステータスコードが「２００」である場合は、クライアントからのリクエストに対するレスポンスと共にリクエストに応じた情報が返信される場合であり、正常復帰の場合である。しかし、実際には、「２００」以外のステータスコードが発生する場合がある。換言すれば、正常復帰ではない場合が発生することがある。

そこで、「２００」以外のステータスコードが発生した場合には、異常が発生したコンピュータを情報処理システムから切り離すことが考えられる。しかし、この場合には、コンピュータそれ自体には異常がないにも拘らず、コンピュータの切離しが頻繁に発生する結果、実際の業務の実行に支障を生じる。従って、「２００」以外のステータスコードが発生しても、コンピュータに異常が発生したと判断することは適切ではない。

一方、「２００」以外のステータスコードが多く発生する傾向がある場合、コンピュータの異常ではなく、業務アプリケーションのデータが破壊された等の異常が発生している可能性がある。

しかし、「２００」以外のステータスコードが発生する頻度は、通常、業務アプリケーション毎に異なり、個々の業務アプリケーションに特有の値をとる。換言すれば、種々の業務アプリケーションに共通の値として、「２００」以外のステータスコードが発生する頻度を算出することができない。従って、種々の業務アプリケーションにおいて、共通に、「２００」以外のステータスコードがある回数だけ発生したら異常であるという判断をすることができない。このため、「２００」以外のステータスコードを用いて、異常検出のための妥当な閾値を定めることはできない。

また、プロセスにおける異常の種類によっては、異常検出のための閾値を設定したとしても、プロセスが異常終了する可能性を検出することができない。

例えば、複数の業務プロセスにリクエストが均等に振分けられ、かつ、リクエストに依存して使用する資源量が大きく変動しない場合、複数の業務プロセスは、各々、同じ資源量を消費するはずである。そこで、この場合には、資源の消費量を用いて、異常検出のための閾値を設定することが考えられる。

しかし、アプリケーションの障害等の何らかの異常が発生した結果、特定の業務プロセスだけが大きく資源を消費する場合がある。そして、特定の業務プロセスだけが大きく資源を消費してはいるが、資源の消費量が異常検出のための閾値を超えない場合がある。この場合、異常検出のための閾値を設定しても、異常を検出することができない。

なお、前述したように、異常が発生したコンピュータを情報処理システムから切り離す場合には、例えば、クラスタシステムのように、業務を実行するコンピュータとは別に代替のコンピュータが用意される。この場合、異常が発生した業務アプリケーションを実行していたコンピュータを停止して、代替のコンピュータによる業務アプリケーションの実行を開始する。これにより、業務アプリケーションの実行は継続される。しかし、異常が発生したコンピュータが停止されるため、異常が発生していた時のプロセス又は業務アプリケーションの状態を維持することができず、異常の原因が解明できない。

開示される情報処理装置は、閾値を用いることなく、アプリケーションに起因してプロセスが異常終了する可能性を検出する。

図１は、情報処理システムの一例を示す図である。

情報処理システムは、例えばサーバクライアントシステムであり、アプリケーションサーバ１と、クライアント８と、ネットワーク９とを含む。アプリケーションサーバ１は、業務アプリケーション４を実行する、換言すれば、業務処理を実行するサーバ装置である。ネットワーク９は、例えばインターネットのようなネットワークである。クライアント８は、アプリケーションサーバ１に業務リクエストを送信して、業務アプリケーション４の実行を要求するクライアント装置である。

例えば、アプリケーションサーバ１は、ネットワーク９を介して、クライアント８から業務リクエストを受信する。そして、アプリケーションサーバ１は、受信した業務リクエストにおいて指示された業務アプリケーション４を実行する。その後、アプリケーションサーバ１は、クライアント８からの業務リクエストに対するレスポンス及び業務リクエストに応じた情報、換言すれば、業務アプリケーション４の実行結果を、ネットワーク９を介して、クライアント８に送信する。

アプリケーションサーバ１は、振分けプロセス２と、複数の業務プロセス３と、業務アプリケーション４と、複数の代替プロセス５と、業務アプリケーション６と、監視プロセス７とを含む。

振分けプロセス２は、振分け処理を実行する振分け部であり、クライアント８からの業務リクエストを複数の業務プロセス３に振分ける。換言すれば、振分けプロセス２は、業務リクエストを業務プロセス３に送信して、当該業務リクエストの実行を業務プロセス３へ依頼する。

具体的には、振分けプロセス２は、監視プロセス７から業務プロセス３の起動完了の通知を受信した場合に、クライアント８からの業務リクエストを受信する、換言すれば、受付ける。そして、振分けプロセス２は、受け付けた業務リクエストを複数の業務プロセス３の中のいずれの業務プロセス３へ振分けるかを判断する。この後、振分けプロセス２は、前記判断に基づいて、業務リクエストを業務プロセス３に振分ける、換言すれば、業務リクエストの実行を業務プロセス３に依頼する。業務リクエストは、例えば複数の業務プロセス３の各々へ、均等に振分けられる。

また、振分けプロセス２は、監視プロセス７から代替プロセス５の起動完了の通知を受信した場合に、クライアント８から受け付けた業務リクエストを、代替プロセス５へ振分ける。換言すれば、振分けプロセス２は、監視プロセス７から代替プロセス５の起動完了の通知を受信した場合に、クライアント８から受け付けた業務リクエストを、その時点まで業務リクエストを振分けていた業務プロセス３へは振分けないようにする。これにより、業務プロセス３は、代替プロセス５に切り替えられる。

振分けプロセス２は、例えば、業務の開始に先立って、予め定められた振分けプロセス２の起動コマンドを実行することにより起動される。具体的には、例えば、アプリケーションサーバ１の管理者が、アプリケーションサーバ１の入力装置から振分けプロセス２の起動コマンドを入力することにより、アプリケーションサーバ１に振分けプロセス２の起動コマンドを実行させる。

業務プロセス３は、実際に業務の処理を実行する業務処理実行部であり、振分けプロセス２により振分けられたクライアント８からの業務リクエストを実行する。換言すれば、業務プロセス３は、受信した業務リクエストにおいて指示された処理を実行する。

具体的には、業務プロセス３は、振分けプロセス２から業務リクエストを受信すると、受信した業務リクエストを実行する業務アプリケーション４を呼び出して、呼び出した業務アプリケーション４に業務リクエストにおいて指示された処理を実行させる。換言すれば、業務プロセス３は、業務アプリケーション４に基づき処理を実行する。業務プロセス３は、複数の業務リクエストを振分けられた場合、振分けられた業務リクエスト毎に、業務アプリケーション４に当該業務リクエストを処理させる。これにより、業務プロセス３は、クライアント８から依頼された処理を実行する。業務アプリケーション４は、業務プロセス３において実行されるアプリケーションプログラムである。

業務プロセス３は、例えば、監視プロセス７が予め定められた業務プロセス３の起動コマンドを実行することにより起動される。監視プロセス７は、例えば、監視プロセス７が起動されると、業務プロセス３の起動コマンドを実行する。この時、複数の業務プロセス３が起動され、並列して稼動させられる。これにより、負荷を分散し、アプリケーションサーバ１を安定的に稼動させることができる。

代替プロセス５は、業務プロセス３に異常が発生した場合、業務プロセス３に代わって処理を実行するプロセスである。従って、代替プロセス５は、業務プロセス３と同一の機能を有する。

代替プロセス５は、実際に業務の処理を実行する業務処理実行部であり、振分けプロセス２により振分けられたクライアント８からの業務リクエストを実行する。具体的には、代替プロセス５は、振分けプロセス２から業務リクエストを受信すると、受信した業務リクエストを実行する業務アプリケーション６を呼び出して、呼び出した業務アプリケーション６に業務リクエストにおいて指示された処理を実行させる。代替プロセス５は、複数の業務リクエストを振分けられた場合、振分けられた業務リクエスト毎に、業務アプリケーション６に当該業務リクエストを処理させる。これにより、代替プロセス５は、クライアント８から依頼された処理を実行する。

業務アプリケーション６は、代替プロセス５において実行されるアプリケーションプログラムである。業務アプリケーション６は、実際には、業務アプリケーション４と同様のアプリケーションプログラムである。

代替プロセス５は、例えば、監視プロセス７が予め定められた代替プロセス５の起動コマンドを実行することにより起動される。監視プロセス７は、例えば、業務プロセス３に異常が発生した場合に、代替プロセス５の起動コマンドを実行する。なお、監視プロセス７が、例えば、監視プロセス７が起動されると直ちに代替プロセス５の起動コマンドを実行するようにしても良い。

起動される代替プロセス５の数は、例えば、起動された業務プロセス３の数と同じ数とされる。これにより、業務プロセス３に異常が発生した場合に、異常が発生した業務プロセス３のみでなく、全ての業務プロセス３を代替プロセス５に切替えることができる。なお、起動される代替プロセス５の数は、起動された業務プロセス３の数より少ない数であっても良い。

監視プロセス７は、プロセスを起動する起動部であり、業務プロセス３及び代替プロセス５を起動する。前述したように、監視プロセス７は、監視プロセス７の起動コマンドにより起動されると、業務プロセス３の起動コマンドを複数回実行することにより、複数の業務プロセス３を起動する。また、監視プロセス７は、業務プロセス３に異常が発生した場合に、代替プロセス５の起動コマンドを複数回実行することにより、複数の代替プロセス５を起動する。

監視プロセス７は、監視処理を実行する監視部であり、全ての自己が起動したプロセス、換言すれば、業務プロセス３及び代替プロセス５を監視するプロセスである。監視プロセス７は、業務を実行する業務プロセス３及び代替プロセス５を監視し、業務プロセス３について異常が発生したか否かを判断することにより、業務の実行を監視する。業務プロセス３が代替プロセス５に切り替えられた場合には、監視プロセス７は、新たな業務プロセスである代替プロセス５について異常が発生したか否かを判断することにより、業務の実行を監視する。監視プロセス７については、図２を参照して後述する。

監視プロセス７は、例えば、業務の開始に先立って、予め定められた監視プロセス７の起動コマンドを実行することにより起動される。具体的には、例えば、アプリケーションサーバ１の管理者が、アプリケーションサーバ１の入力装置から監視プロセス７の起動コマンドを入力することにより、アプリケーションサーバ１に監視プロセス７の起動コマンドを実行させる。

図２は、情報処理装置の一例を示す図である。図３は、プロセス監視処理の説明図である。なお、図２において、代替プロセス５の図示を省略している。

監視プロセス７は、複数の業務プロセス３、例えば、業務プロセス＃１及び業務プロセス＃２を起動する。起動される業務プロセス３の数は、２個には限られない。また、監視プロセス７は、複数の代替プロセス５、例えば、代替プロセス＃１及び代替プロセス＃２を起動する。起動される代替プロセス５の数は、前述したように、起動された業務プロセス３の数と同数とされる。

この後、監視プロセス７は、図３（Ａ）に示す業務プロセス管理情報７１を生成し、生成した業務プロセス管理情報７１を振分けプロセス２に送信する。実際には、業務プロセス管理情報７１は、業務プロセス３の起動完了の通知に付加される。監視プロセス７は、例えば、全ての起動した業務プロセス３から起動完了の通知を受信すると、業務プロセス３の起動完了の通知を振分けプロセス２に送信する。

業務プロセス管理情報７１は、図３（Ａ）に示すように、実際に業務を実行する業務プロセス３を表す情報である。換言すれば、業務プロセス３は、振分けプロセス２から業務リクエストを振分けられることが可能なプロセスである。業務プロセス管理情報７１は、業務プロセス３の起動の都度に、監視プロセス７により生成される。

業務プロセス管理情報７１は、プロセス番号毎に、プロセスＩＤと、ポート番号とを含む。プロセス番号は、起動されているプロセスの中で、業務リクエストを振分けられて実際に業務を実行するプロセス、換言すれば、業務プロセス３を一意に定める識別情報である。プロセスＩＤは、起動されているプロセスを一意に定める識別情報である。起動されているプロセスには、業務プロセス３、代替プロセス５、及び、その他の全てのプロセスが含まれる。ポート番号は、対応するプロセスＩＤのプロセスがプロセス間通信において使用するポート、例えば論理的なポートを一意に定める識別情報である。

振分けプロセス２は、監視プロセス７から業務プロセス３の起動完了の通知と業務プロセス管理情報７１とを受信すると、業務プロセス管理情報７１に基づいて、クライアント８から受け付けた業務リクエストを業務プロセス３へ振分ける。これに応じて、業務リクエストを振分けられた業務プロセス３は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する。

一方、監視プロセス７は、業務プロセス３の起動完了の通知を振分けプロセス２に送信した後、業務プロセス３を監視する。具体的には、監視プロセス７は、予め定められた周期で定期的に、全ての業務プロセス３から業務プロセス情報を収集する。業務プロセス情報の収集は、収集部７３によって実行される。業務プロセス情報は、各々の業務プロセス３の特性を表す特性情報である。収集部７３は、複数の業務プロセス３の各々から、換言すれば、複数の業務プロセス３の各々について、特性情報を収集する。

例えば、業務プロセス＃１から図３（Ｂ）に示す業務プロセス情報３１が収集され、業務プロセス＃２から図３（Ｃ）に示す業務プロセス情報３２が収集される。なお、図２に示すように、業務プロセス＃１から収集される情報を業務プロセス情報＃１とも言い、業務プロセス＃２から収集される情報を業務プロセス情報＃２とも言う。

業務プロセス情報３１は、図３（Ｂ）に示すように、業務プロセス＃１の特性を表す特性情報である。業務プロセス情報３１は、業務プロセス＃１により生成され、逐次更新される。

業務プロセス情報３１は、プロセスＩＤと、メモリ使用量と、レスポンス時間と、「２００以外の回数」とを含む。プロセスＩＤは、自己のプロセスＩＤ、換言すれば、業務プロセス＃１のプロセスＩＤである。メモリ使用量は、その時点で業務プロセス＃１が使用しているメモリの量である。レスポンス時間は、業務プロセス＃１が自己に振分けられた業務リクエストを受信してから、当該業務リクエストに対するレスポンスを返信するまでの時間である。「２００以外の回数」は、業務プロセス＃１において、ＨＴＴＰにおけるステータスコード「２００」以外のステータスコードが発生した回数である。ＨＴＴＰは、複数の業務プロセス３が例えばクライアント８又は振分けプロセス２との間で通信を行う場合のプロトコルである。

業務プロセス情報３２は、図３（Ｃ）に示すように、業務プロセス＃２の特性を表す特性情報である。業務プロセス情報３２は、業務プロセス＃２により生成され、逐次更新される。

業務プロセス情報３２は、プロセスＩＤと、メモリ使用量と、レスポンス時間と、「２００以外の回数」とを含む。プロセスＩＤは、自己のプロセスＩＤ、換言すれば、業務プロセス＃２のプロセスＩＤである。メモリ使用量は、その時点で業務プロセス＃２が使用しているメモリの量である。レスポンス時間は、業務プロセス＃２が自己に振分けられた業務リクエストを受信してから、当該業務リクエストに対するレスポンスを返信するまでの時間である。「２００以外の回数」は、業務プロセス＃２において、「２００」以外のステータスコードが発生した回数である。

業務プロセス情報３１及び３２において、メモリ使用量、レスポンス時間、「２００以外の回数」が、各々、特性情報である。業務プロセス情報３１及び３２には、各々、複数の種類の特性情報が含まれる。特性情報は、予め定められた特定の処理についての情報、又は、予め定められた特定の資源についての情報である。具体的には、特性情報は、プロセスが実行した処理の結果が所定の処理結果であった回数を示す情報、又は、プロセスが使用する所定の資源の使用量についての情報である。

メモリ使用量には、例えば、Ｊａｖａ仮想マシンにおけるヒープ領域、Ｃヒープ領域、Ｐｅｒｍａｎｅｎｔ世代領域等が含まれる。レスポンス時間としては、業務プロセス３毎のレスポンス時間の他に、業務アプリケーション４毎のレスポンス時間、業務リクエスト毎のレスポンス時間を用いるようにしても良い。「２００以外の回数」として、業務プロセス＃１において、２００番代のステータスコード以外のステータスコードが発生した回数を用いるようにしても良く、また、３００番代及び４００番代のステータスコードが発生した回数を用いるようにしても良い。

特性情報は、メモリ使用量、レスポンス時間、「２００以外の回数」のような、業務プロセス３が使用している資源に関連するデータに限られない。例えば、業務アプリケーション４の固有情報、データベースのコネクション、スレッドプール、トランザクション情報、ファイルディスクリプタ、ハンドル、ＣＰＵ使用率等を、特性情報として用いるようにしても良い。

特性情報として用いられる業務アプリケーション４の固有情報は、例えば、業務アプリケーション４の禁止されている状態である。特性情報として用いられるデータベースのコネクションは、例えば、業務アプリケーション４がデータベースにアクセスする場合におけるソケットの数である。特性情報として用いられるスレッドプールは、例えば、業務プロセス３がプールしているスレッドの数である。特性情報として用いられるトランザクション情報は、例えば、業務プロセス３におけるトランザクションの数や時間である。特性情報として用いられるファイルディスクリプタやハンドルは、業務プロセス３が有する数である。特性情報として用いられるＣＰＵ使用率は、例えば、業務プロセス３がＣＰＵを使用している割合である。

例えば、監視プロセス７の収集部７３は、複数の業務プロセス３の各々に対して特性情報の送信を要求する。これに応じて、複数の業務プロセス３の各々が、特性情報を監視プロセス７の収集部７３に送信する。これにより、特性情報が収集される。特性情報は、業務プロセス３が共有メモリ等の記憶装置に書き込んだ特性情報を、監視プロセス７の収集部７３が参照することにより、収集するようにしても良い。

監視プロセス７は、全ての業務プロセス３から業務プロセス情報を収集すると、収集した業務プロセス情報を比較する。業務プロセス情報の比較は、比較部７４によって実行され、全ての業務プロセス３からの業務プロセス情報の収集の都度に実行される。

例えば、比較部７４は、複数の業務プロセス３の各々から収集された業務プロセス情報を、第１の業務プロセス３と、第１の業務プロセス３以外の業務プロセスである第２の業務プロセス３の集合とに分ける。そして、比較部７４は、第１の業務プロセス３の特性情報と、第２の業務プロセス３の特性情報の集合が示す特性とを比較する。

第１の業務プロセス３は、ある１個の業務プロセス３である。第１の業務プロセス３は、業務プロセス情報を収集した複数の業務プロセス３から、１個の業務プロセス３を順次取り出すことにより取得される。

監視プロセス７は、比較部７４における比較の結果、第１の業務プロセス３の特性情報と、第２の業務プロセス３の特性情報の集合が示す特性とが異なる場合、第１の業務プロセス３に異常が発生したと判断する。異常が発生したか否かの判断は、判断部７５によって実行され、業務プロセス情報の比較の都度に実行される。監視プロセス７、換言すれば、判断部７５は、複数の業務プロセス３のうちのある業務プロセス３に関する特性情報が、複数の業務プロセス３のうち、前記ある業務プロセス３を除いた残りの業務プロセス３のいずれの特性情報とも特性が異なる場合に、前記ある業務プロセス３について異常が発生したと判断する。

第１の業務プロセス３の特性情報と第２の業務プロセス３の特性情報の集合が示す特性とが異なるか否かの判断基準は、特性情報の種類毎に、経験的に定められる。

例えば、業務プロセス＃１が第１の業務プロセス３であり、図３（Ｂ）の業務プロセス情報＃１が第１の業務プロセス３の特性情報であるとする。また、業務プロセス＃２が第２の業務プロセス３であり、図３（Ｃ）の業務プロセス情報＃２が第２の業務プロセス３の特性情報であるとする。更に、業務プロセス＃２と同一の業務プロセス情報を持つ業務プロセス３が、複数存在するものとする。従って、第２の業務プロセス３の特性情報の集合は、図３（Ｃ）の業務プロセス情報＃２の集合である。

この場合、第１の業務プロセス３である業務プロセス＃１の特性情報は、「２００以外の回数」に着目すると、「５」である。これに対して、第２の業務プロセス３である複数の業務プロセス＃２の特性情報の集合が示す特性は、「２００以外の回数」に着目すると、「１」である。従って、第１の業務プロセス３である業務プロセス＃１の特性情報のみが、他の業務プロセス３の特性情報と異なる値を持つ。この結果、第１の業務プロセス３である業務プロセス＃１の特性情報が、第２の業務プロセス３である複数の業務プロセス＃２の特性情報の集合が示す特性と異なることになる。そこで、第１の業務プロセス３である業務プロセス＃１に異常が発生したと判断される。異常が発生したと判断される業務プロセス３の数は、１個に限られない。

また、例えば、メモリ使用量について、例えば、第１の業務プロセス３の特性情報のみが増加傾向にあり、第２の業務プロセス３の特性情報の集合が示す特性が増加傾向に無い、換言すれば、減少又はほぼ一定の値を維持する場合に、第１の業務プロセス３に異常が発生したと判断するようにしても良い。逆に、第１の業務プロセス３の特性情報のみが減少傾向にあり、第２の業務プロセス３の特性情報の集合が示す特性が減少傾向に無い、換言すれば、増加又はほぼ一定の値を維持する場合に、第１の業務プロセス３に異常が発生したと判断するようにしても良い。この場合にも、異常が発生したと判断される業務プロセス３の数は、１個に限られない。

また、例えば、レスポンス時間について、例えば、メモリ使用量と同様にして判断するようにしても良い。

また、前述したように、業務プロセス情報３１及び３２には、各々、複数の種類の特性情報が含まれる。そこで、１種類の特性情報について、第１の業務プロセス３の特性情報と第２の業務プロセス３の特性情報の集合が示す特性とが異なる場合には、第１の業務プロセス３の特性情報と第２の業務プロセス３の特性情報の集合が示す特性とが異なると判断するようにしても良い。逆に、複数の種類の特性情報の各々について、第１の業務プロセス３の特性情報と第２の業務プロセス３の特性情報の集合が示す特性とが異なるか否かを判断して、その多数決により、第１の業務プロセス３の特性情報と第２の業務プロセス３の特性情報の集合が示す特性とが異なるか否かを判断するようにしても良い。

以上により、異常検出のための閾値を用いることなく、業務プロセス３における異常の発生、実際には、異常の発生の予兆を検出することができる。また、異常検出のための妥当な閾値を設定することができないアプリケーションの異常を検出することができる。この結果、業務プロセス３が異常終了して業務が停止することを回避することができる。

監視プロセス７は、業務プロセス３に異常が発生したと判断した場合、例えば、アプリケーションサーバ１の管理者へ、ログへのメッセージの出力や表示装置への表示等により、業務プロセス３に異常が発生したことを警告する。なお、アプリケーションサーバ１の管理者へ、警告と共に、又は、警告とは別に、異常が発生したと判断された業務プロセス３を通知するようにしても良い。

監視プロセス７は、業務プロセス３に異常が発生したと判断した場合、複数の代替プロセス５、例えば、代替プロセス＃１及び代替プロセス＃２を起動する。起動される代替プロセス５の数は、前述したように、起動された業務プロセス３の数と同数とされる。従って、起動される代替プロセス５の数は、２個には限られない。

この後、監視プロセス７は、図３（Ｄ）に示す代替プロセス管理情報７２を生成し、生成した代替プロセス管理情報７２を振分けプロセス２に送信する。実際には、代替プロセス管理情報７２は、代替プロセス５の起動完了の通知に付加される。監視プロセス７は、例えば、全ての起動した代替プロセス５から起動完了の通知を受信すると、代替プロセス５の起動完了の通知を振分けプロセス２に送信する。

代替プロセス管理情報７２は、図３（Ｄ）に示すように、実際に業務を実行する代替プロセス５を表す情報である。代替プロセス管理情報７２は、代替プロセス５の起動の都度に、監視プロセス７により生成される。

代替プロセス管理情報７２は、プロセス番号毎に、プロセスＩＤと、ポート番号とを含む。プロセス番号は、起動されているプロセスの中で、業務リクエストを振分けられて実際に業務を実行するプロセス、換言すれば、業務プロセス３を置換する代替プロセス５を一意に定める識別情報である。

なお、判断部７５が、業務プロセス３について異常が発生した場合に、複数の業務プロセス３と同じ数の代替プロセス５を起動するようにしても良い。また、判断部７５が、業務リクエストを代替プロセス５に振分けるように振分けプロセス２に通知するようにしても良い。

業務プロセス３は、既に振分けられた業務の実行を終了するまで処理を継続する。業務プロセス３は、異常が発生したと判断された業務プロセス３を含むが、異常終了するまでには到っていない。従って、業務プロセス３は、既に振分けられた業務の実行を継続し、終了することができる。

振分けプロセス２は、監視プロセス７から代替プロセス５の起動完了の通知と代替プロセス管理情報７２とを受信すると、代替プロセス管理情報７２に基づいて、クライアント８から受け付けた業務リクエストを代替プロセス５へ振分ける。これに応じて、業務リクエストを振分けられた代替プロセス５は、業務リクエストにおいて依頼された業務を業務アプリケーション６により実行する。

この結果、クライアント８からの業務リクエストの振分け先が変更され、異常が発生した業務プロセス３のみでなく、全ての業務プロセス３が代替プロセス５に切替えられる。これにより、異常が発生した業務プロセス３のみでなく、異常が発生した時点における全ての業務プロセス３の解析が可能となるので、より正確に異常の原因等を知ることができる。この後、代替プロセス５により、業務アプリケーション６の実行が継続される。

一方、監視プロセス７は、代替プロセス５の起動完了の通知を振分けプロセス２に送信した後、複数の業務プロセス３をチェックする。業務プロセス３のチェックは、チェック部７６によって実行される。チェック部７６は、複数の業務プロセス３の各々をチェックする。

具体的には、チェック部７６は、代替プロセス５を起動した場合、プロセス監視処理と並行して、全ての業務プロセス３の異常調査を行う。具体的には、監視プロセス７のチェック部７６は、複数の業務プロセス３の各々に対して全ての情報の送信を要求する。これに応じて、業務プロセス３は、その時点での業務プロセス情報を含む業務プロセス３についての全ての情報を、監視プロセス７のチェック部７６へ送信する。これにより、具体的には、監視プロセス７は、全ての業務プロセス３から業務プロセス情報を含む業務プロセス３についての全ての情報を収集する。

なお、チェック部７６が、判断部７５が業務リクエストを代替プロセス５に振分けるように振分け部に通知した後に、複数の業務プロセス３をチェックするようにしても良い。また、チェック部７６が、業務プロセス情報を含む業務プロセス３についての全ての情報に代えて、予め定められた範囲の情報を収集するようにしても良い。また、業務プロセス３に異常が発生した場合、チェック部７６が、異常が発生した業務プロセス３のみについて、異常調査を行うようにしても良い。

この後、アプリケーションサーバ１の管理者が、収集された情報を解析する。これにより、全ての業務プロセス＃１及び業務プロセス＃２が生存した状態（ａｌｉｖｅ）で、他の業務の実行に影響を与えることなく、全ての業務プロセス＃１及び業務プロセス＃２を調査することができる。従って、異常が発生していた時の業務プロセス３の状態を維持することができるので、異常の原因を正しく解明することができる。

図４は、アプリケーションサーバ１のハードウェアの構成の一例を示す図である。

ＣＰＵ１０１は、ＲＯＭ１０２に格納された制御プログラムに従って、アプリケーションサーバ１を制御する。ＣＰＵ１０１は、例えば主メモリであるＲＡＭ１０３上のプログラムを実行する。これにより、振分けプロセス２、業務プロセス３、業務アプリケーション４、代替プロセス５、業務アプリケーション６、監視プロセス７が実現される。プログラムは、例えば、ＣＤ−ＲＯＭやＤＶＤ等の記録媒体１０９に格納され、記録媒体１０９からＣＤ−ＲＯＭドライブやＤＶＤドライブ等を介してハードディスク１０６に入力され、ハードディスク１０６からＲＡＭ１０３にロードされる。

業務プロセス管理情報７１、代替プロセス管理情報７２、業務プロセス情報３１及び３２は、データ格納部に格納される。データ格納部は、例えばＲＡＭ１０３又はハードディスク１０６に設けられる。換言すれば、データは、例えばＲＡＭ１０３又はハードディスク１０６に格納される。

入力装置１０４は、例えばキーボードであり、マウス等を含んでも良い。出力装置１０５は、例えばディスプレイであり、プリンタ等の出力装置を含んでも良い。ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、入力装置１０４、出力装置１０５、及び、ハードディスク１０６、ネットワーク接続部１０７は、バス１０８を介して、相互に接続される。

ネットワーク接続部１０７は、例えば、送受信装置であり、ネットワーク９に接続され、ネットワーク９を介して他のコンピュータ、例えばクライアント８に接続される。これにより、アプリケーションサーバ１は、クライアント８との間で通信を行う。

なお、クライアント８も、例えば、図４に示すハードウェアの構成を有するコンピュータである。

図５及び図６は、プロセス監視処理フローであり、一体となってプロセス監視処理フローを表す。

アプリケーションサーバ１において監視プロセス７の起動コマンドが実行されることにより、監視プロセス７が起動される（ステップＳ１）。更に、アプリケーションサーバ１において、振分けプロセス２の起動コマンドが実行されることにより、振分けプロセス２が起動される（ステップＳ２）。起動された振分けプロセス２は、監視プロセス７からの業務プロセス３の起動完了の通知待ちの状態となる。監視プロセス７の起動及び振分けプロセス２の起動のいずれを先に実行するようにしても良い。

起動された監視プロセス７は、業務プロセス３の起動コマンドを実行することにより、複数の業務プロセス３を起動する（ステップＳ３）。これにより、例えば、業務プロセス＃１が起動され（ステップＳ４）、業務プロセス＃２が起動される（ステップＳ５）。起動された業務プロセス＃１は自己の起動完了の通知を監視プロセス７に送信し、起動された業務プロセス＃２は自己の起動完了の通知を監視プロセス７に送信する。

監視プロセス７は、全ての起動した業務プロセス＃１及び業務プロセス＃２から起動完了の通知を受信すると、業務プロセス３の起動完了の通知を振分けプロセス２に送信する（ステップＳ６）。ステップＳ６における振分けプロセス２への業務プロセス３の起動完了の通知には、図３（Ａ）に示す業務プロセス管理情報７１が付加される。

振分けプロセス２は、監視プロセス７から業務プロセス３の起動完了の通知を受信すると、クライアント８からの業務リクエストの受付けを開始し、受け付けた業務リクエストを均等に業務プロセス＃１及び業務プロセス＃２へ振分ける（ステップＳ７）。この後、業務プロセス＃１及び業務プロセス＃２により、業務アプリケーション４が実行される。

業務リクエストを振分けられた業務プロセス＃１は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する（ステップＳ８）。また、業務リクエストを振分けられた業務プロセス＃２は、業務リクエストにおいて依頼された業務を、業務アプリケーションにより実行する（ステップＳ９）。

一方、監視プロセス７の収集部７３は、ステップＳ６において業務プロセス３の起動完了の通知を振分けプロセス２に送信した後、予め定められた周期で定期的に、全ての業務プロセス＃１及び業務プロセス＃２から業務プロセス情報を収集する（ステップＳ１０）。例えば、業務プロセス＃１から図３（Ｂ）に示す業務プロセス情報３１が収集され、業務プロセス＃２から図３（Ｃ）に示す業務プロセス情報３２が収集される。

次に、監視プロセス７の比較部７４は、全ての業務プロセス＃１及び業務プロセス＃２から業務プロセス情報を収集すると、収集した業務プロセス情報を比較する（ステップＳ１１）。

次に、監視プロセス７の判断部７５は、ステップＳ１１における比較の結果、第１の業務プロセス３の特性情報が、第２の業務プロセス３の特性情報の集合が示す特性と異なる場合、第１の業務プロセス３に異常が発生したと判断する（ステップＳ１２）。

次に、監視プロセス７は、業務プロセス３に異常が発生したと判断した場合、例えば、アプリケーションサーバ１の管理者へ、業務プロセス３に異常が発生したことを警告する（ステップＳ１３）。

次に、監視プロセス７は、業務プロセス３の数と同数の代替プロセス５を起動する（ステップＳ１４）。これにより、例えば、業務プロセス＃１に対応する代替プロセス＃１が起動され（ステップＳ１５）、業務プロセス＃２に対応する代替プロセス＃２が起動される（ステップＳ１６）。換言すれば、業務プロセス３に異常が発生したと判断された場合、異常が発生した業務プロセス３のみでなく、全ての業務プロセス３が、後述するように、代替プロセス５に切り替えられる。起動された代替プロセス＃１は自己の起動完了の通知を監視プロセス７に送信し、起動された代替プロセス＃２は自己の起動完了の通知を監視プロセス７に送信する。

なお、代替プロセス５の起動を、種々のタイミングで実行するようにしても良い。異常の発生前に、例えば、ステップＳ３において代替プロセス５を起動するようにしても良い。また、ステップＳ１２の実行の後にステップＳ１４を実行し、その後、ステップＳ１３を実行するようにしても良い。

また、業務プロセス３に異常が発生したと判断された場合、異常が発生した業務プロセス３のみを、代替プロセス５に切り替えるようにしても良い。

監視プロセス７は、全ての起動した代替プロセス＃１及び代替プロセス＃２から起動完了の通知を受信すると、振分け先の変更の通知を振分けプロセス２に送信する（ステップＳ１７）。ステップＳ１７における振分けプロセス２への振分け先の変更の通知、換言すれば、代替プロセス５の起動完了の通知には、図３（Ｄ）に示す代替プロセス管理情報７２が付加される。

振分けプロセス２は、監視プロセス７から代替プロセス５の起動完了の通知を受信すると、クライアント８からの業務リクエストの振分け先を業務プロセス３から代替プロセス５に変更し、クライアント８から受け付けた業務リクエストを、均等に代替プロセス＃１及び代替プロセス＃２へ振分ける（ステップＳ１８）。これにより、全ての業務プロセス３が代替プロセス５に切替えられる。この後、代替プロセス＃１及び代替プロセス＃２により、業務アプリケーション６の実行が継続される。

図７は、プロセス調査処理フローである。

監視プロセス７のチェック部７６は、代替プロセス５を起動した場合、プロセス監視処理と並行して、全ての業務プロセス３の異常調査を行う（ステップＳ２１）。これにより、代替プロセス＃１及び代替プロセス＃２の起動の原因となった業務プロセス＃１及び業務プロセス＃２も異常調査される。具体的には、監視プロセス７のチェック部７６は、業務プロセス＃１に対して業務プロセス＃１についての全ての情報の送信を要求し、業務プロセス＃２に対して業務プロセス＃２についての全ての情報の送信を要求する。

これに応じて、業務プロセス＃１は、その時点での業務プロセス情報を含む業務プロセス＃１についての全ての情報を、監視プロセス７のチェック部７６へ送信する（ステップＳ２２）。また、業務プロセス＃２は、その時点での業務プロセス情報を含む業務プロセス＃２についての全ての情報を、監視プロセス７のチェック部７６へ送信する（ステップＳ２３）。

この後、アプリケーションサーバ１の管理者が、収集された情報を解析することにより、全ての業務プロセス＃１及び業務プロセス＃２が生存した状態で、全ての業務プロセス＃１及び業務プロセス＃２を調査することができる。

１ アプリケーションサーバ
２ 振分けプロセス
３ 業務プロセス
４、６ 業務アプリケーション
５ 代替プロセス
７ 監視プロセス
８ クライアント
９ ネットワーク
７３ 収集部
７４ 比較部
７５ 判断部
７６ チェック部

Claims (8)

1. 複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する収集部と、
   前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスと異なる複数の他のプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する判断部とを含む
   ことを特徴とする情報処理装置。
2. 前記情報処理装置が、更に、
   クライアントからのリクエストを前記複数のプロセスに振分ける振分け部を含み、
   前記判断部が、前記１又は複数のプロセスについて異常が発生したと判断する場合に、前記複数のプロセスと同じ数の代替プロセスを起動して、前記リクエストを前記代替プロセスに振分けるように前記振分け部に通知する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記情報処理装置が、更に、
   前記判断部が前記リクエストを前記代替プロセスに振分けるように前記振分け部に通知した後に、前記複数のプロセスをチェックするチェック部を含む
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記特性情報は、プロセスが実行した処理の結果が所定の処理結果であった回数を示す情報又はプロセスが使用する所定の資源の使用量についての情報である
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記特性情報は、前記複数のプロセスが通信を行う場合のプロトコルであるＨＴＴＰにおけるステータスコード２００以外のステータスコードが発生した回数である
   ことを特徴とする請求項４に記載の情報処理装置。
6. 監視プロセスが、複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集し、
   前記監視プロセスが、前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスと異なる複数の他のプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する
   ことを特徴とするプロセス監視方法。
7. プロセスを監視するプロセス監視プログラムであって、
   前記プログラムは、コンピュータに、
   複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する処理と、
   前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスと異なる複数の他のプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する処理とを、実行させる
   ことを特徴とするプロセス監視プログラム。
8. プロセスを監視するプロセス監視プログラムを記録する記録媒体であって、
   前記プロセス監視プログラムは、コンピュータに、
   複数のアプリケーションプログラムに基づき処理を実行する複数のプロセスのそれぞれについて、プロセスの特性を表す特性情報を収集する処理と、
   前記複数のプロセスのうちのあるプロセスに関する特性情報が、前記複数のプロセスのうち、前記あるプロセスと異なる複数の他のプロセスのいずれの特性情報とも特性が異なる場合に、前記あるプロセスについて異常が発生したと判断する処理とを、実行させる
   ことを特徴とする記録媒体。
   

Images