JP4968092B2 - ストール検出装置、ストール検出方法、及びストール検出プログラム - Google Patents

Description

本発明は、アプリケーションサーバ等のコンピュータにおいて発生するストールを検出するための技術分野に関する。

従来、ストールとみなすユーザ業務実行時間の設定が行われていない場合、ストール障害と判定するためにはログ採取を行い、ログを解析しなければストール障害が発生しているか判断ができなかった。障害が発生してからストールしているかをログ解析し、ストールしている場合は、スタックトレースを採取し、ストールしているプロセスを再起動するという手順が復旧及び障害原因特定のために必要であり、障害発生時から復旧まで時間がかかり、かつ手間のかかる作業であった。また、スタックトレースを採取しないで障害を復旧させた場合、障害原因が特定できず、障害再現待ちにしなければならないこともあった。

一方、ストールとみなすユーザ業務実行時間の設定を行い、その設定時間を超えた場合にアプリケーションサーバがストールと判断してプロセスを自動再起動して復旧などの方法が知られている。例えば、特許文献１には、メソッドの実行時間を算出し、当該実行時間が当該メソッドの最大実行時間を超えると、タイムアウトとし（ストール検出）、スタック情報をログファイルに書き出す技術が開示されている。また、特許文献２には、アプリケーションプログラムの業務処理実行時刻を記憶しておき、一定周期を行われるストール監視動作の際に、ストール監視動作開始時刻を読み込むと共に前記記憶された業務処理実行時刻を読み込み、当該ストール監視動作開始時刻及び業務処理実行時刻間の時間が予め設定されたストール状態判断時間を超過していた場合に、ストール状態と判断する技術が開示されている。また、特許文献３には、テスト段階においてプログラムの実行時間の最大値を求める旨が記載されている。
特開２００６−１４６６７８号公報 特開２００２−７１７２号公報 特開昭６２−２５６０５０号公報

しかしながら、従来の技術のように、最大実行時間を超えるとストールと判定する方法では、迅速なストール検出は困難という問題がある。

また、従来の技術では、きめ細かなストール判定を行うことが困難であり、またストールと判定する時間の設定もオペレーションごとの大きめの値を設定しなければならなかったため、ストールを検出するまで時間がかかるという問題がある。例えば、ストール検出時にどのオペレーションでストールが発生したのかを特定することが可能であったが、どのメソッドのソースの何行目でストールしているかなどの詳細な情報がわからなかった。

さらに、従来の技術では、ストールとみなす時間を最小の時間に設定することが難しく、ストールとみなして復旧させるまでに時間がかかるという問題がある。

本発明は、以上の問題等に鑑みてなされたものであり、ストール発生後、迅速にストールを検出し、迅速にシステムを復旧させ、かつ詳細な障害原因を特定可能なログを自動で採取することが可能なストール検出装置、ストール検出方法、及びストール検出プログラムを提供することを課題とする。

上記課題を解決するため、請求項１に記載の発明は、アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するストール検出装置であって、前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するスタック情報記録手段と、前記記録されたスタック情報を解析し、メソッド毎のユーザ業務実行時間又はスタック出力回数からストールを検出するストール検出手段と、前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するログ出力手段と、を備えることを特徴とする。

請求項２に記載の発明は、アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するストール検出方法であって、前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するステップと、前記記録されたスタック情報を解析し、前記スタック情報に変化がない回数が予め設定された２以上の回数を超えた場合にストールを検出するステップと、前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するステップと、を含むことを特徴とする。

請求項３に記載のストール検出プログラムの発明は、アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するコンピュータを、前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するスタック情報記録手段、前記記録されたスタック情報を解析し、前記スタック情報に変化がない回数が予め設定された２以上の回数を超えた場合にストールを検出するストール検出手段、及び、前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するログ出力手段として機能させることを特徴とする。

本発明によれば、ユーザが設定や作業を行う事無く、ストール発生後、迅速にストールを検出し、迅速にシステムを復旧させ、かつ詳細な障害原因を特定可能なログを自動で採取することができる。

以下、図面を参照して本発明の最良の実施形態について詳細に説明する。

本発明は、サーバアプリケーションでストールが発生した場合にユーザが特別な設定をする事無く自動でスタック情報をもとにしてストールを検出する等を特徴としている。

先ず、図１を参照して、本発明の一実施形態に係るアプリケーションサーバの構成及び機能について説明する。

図１は、アプリケーションサーバの概要構成の一例を示すブロック図である。

図１に示すように、アプリケーションサーバ80は、サーバアプリケーション30と、スタック採取要求用プロセス40と、メモリ50と、ユーザ業務実行時間解析用プロセス60と、ログ70を有している。なお、アプリケーションサーバ80は、例えばサーバコンピュータからなり、これに搭載されているＣＰＵが記憶部に記憶されたプログラム（本発明のストール検出プログラムを含む）を読み出し実行することにより、サーバアプリケーション30、スタック採取要求用プロセス40、及びユーザ業務実行時間解析用プロセス60として機能するようになっている。

サーバアプリケーション30は、クライアント10からのリクエストをネットワークを介して受信する機能を有している。

スタック採取用プロセス40（本発明におけるスタック情報記録手段の一例）は、オペレータ20からスタック採取間隔（オペレータ20はスタック採取間隔を設定可能）の設定要求を受ける機能を有し、スタック採取要求をサーバアプリケーション30に送信してメモリ50にスタック情報を記録する機能を有している。

ユーザ業務実行時間解析用プロセス60（本発明におけるストール検出手段及びログ出力手段の一例）は、メモリ50に記録されたスタック情報を取得し、ユーザ業務実行時間を解析してメモリ50に記録する機能を有している。また、ユーザ業務実行時間からストールしていると判定（ストールの検出）した場合はメモリ50に記録されたスタック情報をログ70に出力させる機能を有している。さらに、通常運用時のユーザ業務実行時間を計算してメモリ50の記録を更新する機能や、古いユーザ業務実行時間の情報を削除する機能も有している。

次に、本発明の実施例の動作について、図１を用いて例をあげて説明する。

なお、スタック採取要求用プロセス 40 のフローチャートを図２に示し、ユーザ業務実行時間解析用プロセス 60のフローチャートを図３に示し、メモリ50に記録されたスタック情報を図４に示し、メモリ50に記録されたメモリ50に記録された実行時間情報を図５に示し、ストール判定方法の概要を図６に示している。

図１において、クライアント10からサーバアプリケーション30へリクエストが送信されると、サーバアプリケーション30ではユーザ業務の実行を行う。

スタック採取要求用プロセス40は、図２に示すように、スタック採取間隔（スタック出力間隔）を取得可能になっており（ステップＳ１）、オペレータ20が当該スタック採取間隔を設定した場合（ステップＳ２：ＹＥＳ）、これを取得し当該スタック採取間隔を反映する（ステップＳ３）。なお、オペレータ20がスタック採取間隔を設定していない場合は、アプリケーションサーバ80で設定された既定値で動作する。

また、図２に示すように、スタック採取要求用プロセス40は、ユーザ業務実行状況を把握するため、正常動作時に、定期的に（設定されたスタック採取間隔で）スタック採取要求をサーバアプリケーション30に送信し、メモリ50にサーバアプリケーション30のスタック情報を記録する（ステップＳ４〜Ｓ５）。スタック情報は、例えば、図４に示すように、スレッド番号毎にスタックを管理し、スタック出力時間とスタックを記録している。

次に、図３に示すように、ユーザ業務実行時間解析用プロセス60は、メモリ50に記録された図４のスタック情報を定期的に取得し（ステップＳ１１）、当該スタック情報を解析し、メソッド毎の実行時間を測定する（ステップＳ１２）。そして、ユーザ業務実行時間解析用プロセス60は、当該測定した実行時間からストールしているか否かを判定する（ステップＳ１３）。ストールの判定方法としては、例えば、ユーザ業務実行時間解析用プロセス60は、図６（１）に示すように、例えば、スレッド毎に最新のスタック（新しいスタック）と過去のスタック（古いスタック）の比較を行い、スタックに変化があればそのスタック情報から得られたメソッドに対してユーザ業務実行時間（例えば、図６（１）に示す（時刻Ｂ−時刻Ａ）を計算し、メモリ５０に記録する。

一方、スタックに変化がない場合はそのメソッドの実行が継続されているのか、または新規に同じメソッドが実行されているのかが別途測定しているメソッド開始時刻から判断される。メソッドの実行が継続されていると判断された場合、メモリ５０のユーザ業務実行時間を暫定で更新しておく。

そして、ユーザ業務実行時間解析用プロセス60は、図６（１）に示すように、ユーザ業務実行時間が平均実行時間を大幅に超えたと実行時間の分散などの統計学的見地から判断した場合（平均実行時間の所定値倍以上である場合の一例）、ストールが発生していると判定（ストールの検出）する（ステップＳ１４：ＹＥＳ）。

なお、ストール判定は、ユーザ業務実行時間からではなく、図６（２）に示すように、スタック情報を解析しスタック出力回数から行うようにすることも可能である。例えば、スタック情報に変化がない回数からストールの発生が判断される（スタック情報に変化がない回数が所定回数を超えた場合、ストールが発生していると判定（ストールの検出）される）。例えば、図４に示すスタック情報からスタックに変化がない状態が何回続くかわかるため、正常動作時と比較してスタックに変化がない状態がいつまでも続けばストールと判定する。

そして、ユーザ業務実行時間解析用プロセス60は、ストールと判定、つまり、ストールを検出した場合、メモリ50に記録されているスタック情報をログ70に出力させる（ステップＳ１５）。

また、例えば、図３に示すように、ユーザ業務実行時間解析用プロセス60は、メモリ50に実行時間が指定回数分記録されたと判断した場合（ステップＳ１６：ＹＥＳ）、平均実行時間を再計算し、メモリ50の記録を更新する（ステップＳ１７）。つまり、ユーザ業務の平均実行時間は、定期的に計算され、メモリ50の平均実行時間が更新される。

また、ユーザ業務実行時間解析用プロセス60は、過去の実行時間とスタックを削除する（ステップＳ１８）。つまり、メモリ50では最新の一定時間分のスタック情報を記録し、メモリ節約のため古いスタック情報やユーザ業務実行時間はユーザ業務実行時間解析用プロセス60により削除される。

また、ユーザ業務の平均実行時間を初期化したい場合はオペレータがアプリケーションサーバ80に初期化要求を出し、アプリケーションサーバ80がユーザ業務実行時間監視用プロセス60に初期化命令を出すことにより、ユーザ業務実行時間監視用プロセス60がメモリ50に記録されたユーザ業務の平均実行時間を初期化する。

そして、ストール発生と判定した時点でアプリケーションサーバ80は、サーバアプリケーション30のストールしているプロセスを自動で再起動し、復旧させる。サーバアプリケーション30のストールしているプロセスが再起動されると、クライアント10にはエラーが返却される。エラーのマイナー番号からクライアント10はサーバアプリケーション30でストールが発生したことを確認できるので、ログ70に出力されたスタックを確認し、ストール箇所を特定する。

なお、クライアントに返却されたエラーからストールしていることが判明した場合、サーバアプリケーションの不具合をログから確認し、ユーザアプリケーションを修正すればよい。

次に、本発明の他の実施例について図１を用いて説明する。

上記実施例では、サーバアプリケーション30でストールが発生した場合、メモリ50に記録しているスタック情報をログ70に記録し、クライアント10がログ70を確認する方法としているが、ストールが発生した時点でログ70に出力された情報をクライアント10へ通知することも可能である。

また、上記実施例では、ストール発生時について記述しているが、ストール障害ではなくスローダウン障害が発生した場合にログ70にスローダウン情報を出力し、クライアント10に通知することも可能である。スローダウン障害とはマシン負荷などにより通常のユーザ業務実行時間より時間がかかってしまう障害のことである。これはユーザ業務実行時間解析用プロセス60がユーザ業務実行時間をメソッド単位でメモリ50に記録しているため、実現可能である。

以上説明したように上記実施形態によれば、ストール発生後、迅速にストールを検出し、迅速にシステムを復旧させ、かつ詳細な障害原因を特定可能なログを自動で採取することができる。

ストール判定に関して、ユーザが設定や作業を行う事無く、アプリケーションサーバが自動かつ最小限の時間で行うことができる。つまり、ストールとみなすユーザ業務実行時間の設定が行われていない場合、従来はストールしているかを判断するため、ログ採取を行い、ログからストールしているかを確認するしか方法がなかったが、本実施形態によれば、定期的にユーザアプリケーションのスタック情報をメモリに統計情報として記録しているため、ストールとみなす時間が設定されていなくてもアプリケーションサーバがユーザ業務実行時間からストールを検出し、自動でプロセスを再起動して復旧させることができる。

また、上記実施形態によれば、正常運用時のスタックをメモリに記録し、ユーザ業務実行時間をメソッド単位で記録しているため、ストールが発生した場合はどのオペレーションのどのロジックでストールしているかをアプリケーションサーバが瞬時に判断可能である。ストール判定のためのログ採取の必要がなくなり、迅速にストール障害を復旧することができる。

また、上記実施形態によれば、ストールが発生した場合に自動でスタックトレースを採取し、ストール箇所をソースの行レベルで確認することができる。従来はストールが発生していることを確認後に、ユーザが手動でスタックトレースを採取するなどしないと詳細な情報を得ることができなかったが、上記実施形態では、ストール発生時に自動でスタックをログに出力するためユーザが設定や作業を行う必要がなく手間がかからない。さらに、ストール検出時にユーザアプリケーションのスタック情報をログに出力するため、どのメソッドのソースの何行目でストールしているかがなど、詳細な情報が取得できる。

また、ストール判定をスタック情報から行うため、ユーザ業務実行時間をメソッド単位で測定することが可能であり、従来と比べて細かい単位でストール判定が可能である。これによりストールとみなす時間をメソッド単位で設定することができ、ストール発生後迅速に復旧できる。

また、スタックトレースを採取する前にストール障害を復旧し、障害原因が特定できなくなることも無くなる。

なお、本発明はアプリケーションサーバでJava（登録商標）アプリケーションを使用している場合を想定して記述しているが、スタック情報が採取可能なあらゆるシステムで実装することが可能である。

アプリケーションサーバの概要構成の一例を示すブロック図である。 スタック採取要求用プロセス 40 のフローチャートを示す図である。 ユーザ業務実行時間解析用プロセス 60のフローチャートを示す図である。 メモリ50に記録されたスタック情報を示す図である。 メモリ50に記録されたメモリ50に記録された実行時間情報を示す図である。 ストール判定方法の概要を示す図である。

符号の説明

80 アプリケーションサーバ
30 サーバアプリケーション
40 スタック採取要求用プロセス
50 メモリ
60 ユーザ業務実行時間解析用プロセス
70 ログ

Claims (3)

1. アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するストール検出装置であって、
   前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するスタック情報記録手段と、
   前記記録されたスタック情報を解析し、前記スタック情報に変化がない回数が予め設定された２以上の回数を超えた場合にストールを検出するストール検出手段と、
   前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するログ出力手段と、
   を備えることを特徴とするストール検出装置。
2. アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するストール検出方法であって、
   前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するステップと、
   前記記録されたスタック情報を解析し、前記スタック情報に変化がない回数が予め設定された２以上の回数を超えた場合にストールを検出するステップと、
   前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するステップと、
   を含むことを特徴とするストール検出方法。
3. アプリケーションのスタック情報が採取可能なシステムの前記アプリケーションで発生したストールを検出するコンピュータを、
   前記アプリケーションのスタック情報を所定のスタック採取間隔でメモリに記録するスタック情報記録手段、
   前記記録されたスタック情報を解析し、前記スタック情報に変化がない回数が予め設定された２以上の回数を超えた場合にストールを検出するストール検出手段、及び、
   前記ストールが検出された場合、メモリに記録されているスタック情報をログに出力するログ出力手段として機能させることを特徴とするストール検出プログラム。

Images