JP2011154483A - 異常検出装置、プログラム、及び異常検出方法 - Google Patents

Abstract

【課題】システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステムを監視するための技術を提供する。
【解決手段】トレンド解析部５５は、性能情報取得部５３が取得した性能情報を用いた、トレンド及び正常範囲を示すトレンド／正常範囲データ５１を作成する。異常判定部５６は、性能情報が示す入力パケット数とＣＰＵ負荷の組み合わせを、対応する正常範囲と比較することにより、異常が発生したか否か判定し、異常が発生したと判定した場合に、レスポンス時間取得部５４が取得したネットワーク情報（レスポンス時間）を予め定めた閾値と比較することにより、深刻な異常か否か再判定する。アラーム処理部５７は、異常判定部５６が深刻な異常と再判定した場合に、その異常をシステム管理者に通知する。
【選択図】図２

Description

本発明は、通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムに発生する異常を検出するための技術に関する。

特開２００６−２３８０４３号公報には、中継装置からトラフィック統計情報を取得し、時系列分析することによって、将来の中継通信数を予測し、異常を早期に判別することが開示されている。

特開２００６−２３８０４３号公報

本発明は、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステム（コンピュータ）を監視するための技術を提供することを目的とする。

本発明を適用した１システムでは、コンピュータの負荷情報を取得する性能情報取得部と、コンピュータの応答時間を取得する応答時間取得部と、負荷情報を基に前記コンピュータの異常動作を判定する第１の異常判定部と、第１の異常判定部がコンピュータが異常動作していると判定した場合に、応答時間に基づいて、コンピュータの異常動作を判定する第２の異常判定部と、第２の異常判定部がコンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、を具備する。上記コンピュータは、例えば通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムを構成するサーバとして用いられるものである。

本発明を適用した場合には、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステムを監視することができる。

本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。 本実施形態による異常検出装置の機能構成を説明する図である。 サーバ情報収集装置が収集した性能情報のデータ構成を説明する図である。 ネットワーク情報収集装置が収集したネットワーク情報のデータ構成を説明する図である。 トレンド／正常範囲データの構成を説明する図である。 サービスシステムのレスポンス時間を説明する図である。 正常範囲を用いて行われる異常判定を説明する図である。 システム管理者がトレンドを変化させる変更を行った後に、性能情報から得られる入力パケット数とＣＰＵ負荷の組み合わせの例を説明する図である。 システム管理者がサービスを追加した場合のレスポンス時間の変化の例を説明する図である。 異常が発生した場合のレスポンス時間の変化の例を説明する図である。 直ちに通知すべき異常と判定しなかった場合の対応方法を説明する図である。 異常検出処理のフローチャートである。 入力パケット数とＣＰＵ負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。 即時異常通知用閾値を設定する場合のトレンド／正常範囲データのデータ構成を説明する図である。 異常検出処理のフローチャートである（変形例）。 本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。

近年の通信ネットワークの発達により、この通信ネットワークに接続された端末装置のユーザにサービスを提供するサービスシステムは数多く構築されている。このサービスシステムは、１台以上のサーバ（データ処理装置）を用いて構築される。多くの人の利用、或いは多くの種類のサービスの提供を想定したサービスシステムは、負荷を分散するために、複数のサーバ（データ処理装置）を用いて構築することにより、大規模化なものとなっているのが普通である。

サービスは、快適に利用できるようにすることが重要である。このことから、サービスの質を常に維持できるように、サーバ（コンピュータ）の動作状況を示す情報を性能情報（負荷情報）として収集し、監視することが行われている。性能情報としては、例えばＣＰＵ負荷（使用率）、メモリ使用量、ディスク使用量、及び単位時間当たりに入力（受信）するデータ量（トラフィック量）などを挙げることができる。通常、サービスの提供を要求するデータの量はサービスの種類や状況等に応じて大きく変動しない。それによりトラフィック量はサービスを要求した要求数を表すものとなる。

大規模なサービスシステムでは、多くの種類のサービスを提供できる、或いは多くの人が利用することから、負荷のモデルの作成は困難なのが実情である。しかし、通常、ユーザの要求が増えるほど、サービスシステムを構成するサーバの処理量（負荷）も増加するという相関が存在する。このことから、サービスシステムでは、サービスシステム内のサーバ毎に、そのサーバのトラフィック量（要求数）とそのサーバのＣＰＵ負荷の相関分析を行い、その結果を用いて異常判定を行うシステム監視方法が採用される場合が多い。

この監視方法では、相関分析の結果、つまりトラフィック量とＣＰＵ負荷の相関関係をトレンド（傾向）として採用し、そのトレンドから、トラフィック量とＣＰＵ負荷の組み合わせのなかで正常と見なす正常範囲を作成（設定）する。それにより、この監視方法では、得られたトラフィック量とＣＰＵ負荷の組み合わせが正常範囲内でなかった場合に、サービスシステムに異常が発生したと判定する。異常検出装置は、そのようにして異常が発生したか否かを判定するものである。相関分析に用いるトラフィック量とＣＰＵ負荷の組み合わせは、直近の定めた期間内に得られた性能情報のものである。正常範囲と比較するトラフィック量とＣＰＵ負荷の組み合わせも、性能情報から得られたものである。

サービスシステムでは、システム管理者によって、サービスの追加、或いは修正等の変更が行われる場合がある。そのような変更に伴い、相関分析から得られるトレンドは変化することがある。正常範囲は、通常、予め定めたタイミングで再作成する。しかし、そのような変更を行った直後には、その変更に合ったトレンドは作成していない。このため、その変更に伴ってトレンドが比較的に大きく変化する場合には、実際には異常ではなくとも異常と誤判定してしまうことがある。

このような誤判定を行う可能性があることから、システム監視方法のなかには、得られたトラフィック量とＣＰＵ負荷の組み合わせが正常範囲外となった場合に、一定期間、異常と判定しないようにしたものがある。その従来のシステム監視方法では、新たな相関分析により正常範囲が得られた後、その正常範囲を用いて異常判定を行うようにしている（特許文献１）。それにより、実際に発生した異常のみを検出することができる。

得られたトラフィック量とＣＰＵ負荷の組み合わせが正常範囲外となるのは、システム管理者による何らかの変更が原因であるとは限らない。つまり、実際に発生した異常、つまり通知すべき異常が原因である可能性がある。このため、一定期間、異常と判定しないようにした場合には、たとえ直ちに通知すべき深刻な異常が実際に発生していたとしても、その異常をシステム管理者に通知するのが遅れてしまうという問題点があった。これは、サービスを快適に利用できない人をより多くする、サービスを快適に利用できない期間をより長くする、ということを意味する。

システム管理者による変更に伴う正常範囲の変化への対応としては、システム管理者自身が正常範囲の再設定を指示するというものも考えられる。しかし、この方法でも、正常範囲を再設定するまで異常判定を行うことはできない。このため、上記従来のシステム監視方法と同様の問題点が存在することとなる。

システム管理者は通常、頻繁にサービスの追加／修正／削除などのサービス変更作業、或いはチューニングなどのシステム変更作業を行っている。正常範囲の再設定の指示は、システム管理者の負荷を増大させる。このようなことから、システム管理者による変更に伴うトレンドの変化に対応することに加えて、システム管理者の負荷の増大を抑えつつ、実際に発生した深刻な異常はシステム管理者が直ちに把握できるようにすることが重要である。

以下、本発明の実施形態について図面を参照しながら説明する。
図１は、本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。

このネットワークシステムは、図１に示すように、端末装置１０が接続可能な通信ネットワーク１に接続された、その端末装置１０のユーザにサービスを提供可能なサービスシステム２０と、そのサービスシステム２０が通信ネットワーク１を介して送受信するデータ（パケット）に係わるネットワーク情報３１を収集するネットワーク情報収集装置３０と、サービスシステム２０を構成するサーバ毎に、そのサーバの動作状況を示す性能情報４１を収集するサーバ情報収集装置４０と、ネットワーク情報収集装置３０及びサーバ情報収集装置４０がそれぞれ収集した情報を用いて、サービスシステム２０に発生した異常を検出する異常検出装置５０と、及びシステム管理者が使用する端末装置６０と、を備えた構成となっている。本実施形態による異常検出装置は、この異常検出装置５０として実現されている。

上記サービスシステム２０は、ルータ２１と、複数台のＷＥＢサーバ２２と、複数台のアプリケーション（ＡＰ）サーバ２３と、１台以上のデータベース（ＤＢ）サーバ２４と、を備えている。それらのルータ２１及び各サーバ（検査対象コンピュータ）２２〜２４は例えばＬＡＮに接続されている。

ルータ２１は、端末装置１０から受信したパケットのヘッダに格納されている送信先アドレスを参照し、何れかのＷＥＢサーバ２２に転送する。ＷＥＢサーバ２２は、その転送により受信したパケットを解析し、そのパケットにより要求されたサービスを提供するための処理をＡＰサーバ２３に依頼する。ＡＰサーバ２３は、必要に応じてＤＢサーバ２４からデータを取得し、依頼された処理を実行し、その実行結果をＷＥＢサーバ２２に返す。ＷＥＢサーバ２２は、その実行結果を用いて、応答とするパケットを生成し送信する。そのようにして送信されたパケットは、ルータ２１、及び通信ネットワーク１を介して端末装置１０に受信される。以降、端末装置１０はシステム管理者が使用する端末装置６０と区別するために、「ユーザ端末」と表記する。

図６は、サービスシステム２０のレスポンス時間を説明する図である。
ユーザ端末１０から送信されたパケットは、サービスシステム２０のルータ２１に受信されてＷＥＢサーバ２２に転送されて処理される。その結果、上記したように、ＡＰサーバ２３による処理、ＤＢサーバ２４による処理、ＡＰサーバ２３による処理、ＷＥＢサーバ２２による処理がそれぞれ実行され、ＷＥＢサーバ２２が生成したパケットがルータ２１を介して通信ネットワーク１上に出力される。このことから、ユーザ端末１０からのパケットを受信してから応答とするパケットを返信するまでに要する時間であるサービスシステム２０全体のレスポンス時間は、それら各サーバ２２〜２４の処理の実行時間、サーバ間の通信に要した時間等を累算したものとなる。

ルータ２１には、このレスポンス時間を計時する計時プログラムが搭載されている。その計時プログラムは、例えばユーザ端末１０から受信したパケット毎に、レスポンス時間を計時し、予め定めた単位時間毎に、計時したレスポンス時間の平均値を算出する。ネットワーク情報収集装置３０は、例えばその単位時間間隔で、レスポンス時間の平均値をネットワーク情報３１としてルータ２１から収集する。

図４は、ネットワーク情報収集装置３０が収集したネットワーク情報３１のデータ構成を説明する図である。図４に示すように、ネットワーク情報収集装置３０は、レスポンス時間の平均値を、その平均値が収集された日時を示す日時情報を共に１レコード（エントリ）に格納する形でネットワーク情報３１を保存する。その日時情報は、ルータ２１が付しても良いが、ネットワーク情報収集装置３０が付すようにしても良い。

このようなレスポンス時間（の平均値）の収集は、周知技術を用いて行われる。以降、特に断らない限り、レスポンス時間とは、収集されたレスポンス時間の平均値を指す意味で用いる。

各サーバ２２〜２４は、例えば性能情報収集用の収集プログラムを実行することにより、予め定めた設定に従い、自サーバの動作状況を示す性能情報（負荷情報）４１を生成する。その性能情報４１として生成する情報には、自サーバが入力（受信）したデータ量を示すトラフィック量、ＣＰＵ負荷（使用率）、及び日時が含まれる。本実施形態では、そのトラフィック量を示す情報として、入力パケット数を採用している。入力パケット数は、設定された単位時間に入力したパケットの総数であり、ＣＰＵ負荷は、その単位時間の平均のＣＰＵ負荷である。そのような性能情報４１は、例えばその単位時間間隔でサーバ情報収集装置４０により収集される。

図３は、サーバ情報収集装置４０が収集した性能情報４１のデータ構成を説明する図である。図３に示すように、サーバ情報収集装置４０は、日時、入力パケット数、及びＣＰＵ負荷を含む性能情報４１を、その性能情報４１を収集したサーバを示す識別子であるサーバ名を追加して１レコード（エントリ）に格納する形で保存する。このような性能情報４１の収集も周知技術を用いて行われる。

異常検出装置５０は、例えばサーバ情報収集装置４０と同様に、上記単位時間間隔でそのサーバ情報収集装置４０から新たに収集された性能情報４１を取得する。トラフィック量（入力パケット数）とＣＰＵ負荷の相関分析は、例えば予め定めた時間間隔でサーバ毎に行う。その相関分析により、例えば入力パケット数とＣＰＵ負荷の相関関係を示す回帰直線をトレンド（傾向）として作成し、そのトレンドから、入力パケット数とＣＰＵ負荷の組み合わせのなかで正常と見なす正常範囲を作成（設定）する。作成した正常範囲は、サーバ情報収集装置４０から随時、取得する性能情報４１が示す入力パケット数とＣＰＵ負荷の組み合わせと比較することにより、その正常範囲を用いた異常判定を行う。

図７は、正常範囲を用いて行われる異常判定を説明する図である。この図７では、横（Ｘ）に入力パケット数、縦（Ｙ）軸にＣＰＵ負荷を取り、１サーバのトレンド７１と正常範囲７２をＸＹ平面上で表している（これは、図８、図１１及び図１３でも同様である）。正常範囲７２は、四角形で表している。この正常範囲７２の上限、及び下限は、入力パケット数が大きくなるほど、トレンド７１との差の絶対値が大きくなるように作成されている。下限を作成するのは、サーバが実行すべき処理を実行できない等の理由により、ＣＰＵ負荷が大きく低下するケースがあるからである。

図７中の黒丸は、トレンド（回帰直線）７１の作成に用いられた入力パケット数とＣＰＵ負荷の組み合わせ、つまり実際に性能情報４１の形で観測された観測データを示している。それにより図７は、正常範囲７２の外に位置する観測データが得られた場合に、異常と判定することを示している。

異常検出装置５０は、作成したトレンド７１及び正常範囲７２はトレンド／正常範囲データ５１として管理する。図５は、そのデータ５１の構成を説明する図である。図５に示すように、そのデータ５１は、対応するサーバを示すサーバ名、トレンド７１を作成した日時（トレンド作成日時）、このデータ５１を有効とする日時を示す開始データ、このデータ５１を無効とする日時を示す最終データ、トレンド７１を示す回帰直線データ、正常範囲７２の上限を示す正常範囲上限データ、及び正常範囲７２の下限を示す正常範囲下限データを含む構成となっている。

回帰直線データは、相関係数、傾き、及びＹ切片を含む構成である。正常範囲上限データ、及び正常範囲下限データは傾き、及びＹ切片を含む構成である。
異常検出装置５０は、最終データが示す日時の経過により、次のトレンド７１、及び正常範囲７２を作成する。システム管理者が例えばサービスを追加する等の変更は、トレンド７１、及び正常範囲７２の作成とは別に行われるのが普通である。また、適切な正常範囲７２の作成には、或る程度の性能情報４１が必要である。このようなことから、システム管理者がサービスを追加する等の変更を行った直後には、その変更に合った適切な正常範囲７２は作成されていないのが普通である。

図１に示すような構成のサービスシステム２０では、サービスの追加に伴い、ＡＰサーバ２３、及びＤＢサーバ２４のうちの少なくとも一方は、入力パケット数に対するＣＰＵ負荷が増大するのが普通である。このため、図８に示すように、観測データ、つまり性能情報４１として得られた入力パケット数とＣＰＵ負荷の組み合わせが示す黒丸の位置は、異常が発生していないとしても、正常範囲７２の外となる可能性がある。しかし、観測データと正常範囲７２との比較を行ったのみでは、実際に異常が発生しているか否かを必ずしも適切に判定することはできない。システム管理者によるトレンド７１を変化させる変更により、本来は異常ではないものが異常と判定された可能性がある。このようなことから本実施形態では、観測データが正常範囲７２の外となった場合に、以下のように対応している。図９〜図１１に示す各説明図を参照して具体的に説明する。

図９は、サービスを追加した場合のレスポンス時間の変化の例を説明する図である。この図９では、横（Ｘ）軸に時間、縦（Ｙ）軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。サービスを追加した時点は、図９中、横軸を指す矢印により示している。

図９に示すように、異常が発生していない状況でサービスを追加したとしても、レスポンス時間は大幅に変化しないのが普通である。これには、サービスの追加の前後で入力パケット数が大きく変化することは少ない、ＣＰＵ負荷が大きく変化するようなサービスの追加を行うケースは稀である、といった実情がある。

レスポンス時間が大きく変化しなければ、ユーザは、利用しているサービスの質が低下したと感じる可能性は低い。このことから、たとえ観測データが正常範囲７２の外となったとしても、システム管理者が早急に対応しなければならない必要性は低いと云える。それにより、システム管理者に異常を直ちに通知しない。

図１０は、異常が発生した場合のレスポンス時間の変化の例を説明する図である。この図１０でも同様に、横（Ｘ）軸に時間、縦（Ｙ）軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。異常が発生した時点は、図１０中、横軸を指す矢印により示している。図１０に示すようなレスポンス時間の変化は、例えばプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放するガベージコレクションが短時間に頻発する異常によって生じる。

図１０に示すように、異常が発生すると、レスポンス時間は非常に長くなるのが普通である。非常に長いレスポンス時間は、ユーザにサービスの質の低下を感じさせる可能性が高い。このことから本実施形態では、直ちに通知すべき異常を判定するための閾値（レスポンス異常判定閾値）を設定し、レスポンス時間がこの閾値を越えたときには、システム管理者に異常を直ちに通知する。その通知は、例えば異常の発生を伝えるためのメッセージ、或いはメールをシステム管理者が使用する端末装置６０に送信することで行われる。

このようにして本実施形態では、観測データが正常範囲７２の外となった場合、レスポンス時間を参照し、直ちに通知すべき異常か否か判定するようにしている。それにより、直ちに通知すべき異常と判定すれば、異常を直ちにシステム管理者に通知し、直ちに通知すべき異常ではないと判定すれば、深刻な異常の可能性は低く、且つサービスを利用するユーザへの影響も小さいと見なし、異常の通知を控える。このため、深刻と考えられる異常の通知が遅くなるのは確実に回避される。それにより、サービスを快適に利用できない人、その時間は共に最小限に抑えることができるようになる。異常検出装置５０がネットワーク情報収集装置３０を介してネットワーク情報（レスポンス時間）を取得するのは、このような異常判定を行うためである。

なお、本実施形態では、レスポンス異常判定閾値を判定基準として設定して、直ちに通知すべき異常を判定（検出）するようにしているが、レスポンス時間の変動量を判定基準として採用しても良い。その変動量の閾値は、レスポンス異常判定閾値のように固定の時間値としても良いが、例えば単位時間当たりのレスポンス時間の差分を、その差分の算出に用いた二つのレスポンス時間の一方で割ることにより得られるような比であっても良い。入力パケット数の変動を考慮して、そのような計算により得られる変動量（比）に、二つのレスポンス時間が得られた際の各ＷＥＢサーバ２２の入力パケット数の累算値の比を乗算したものとしても良い。レスポンス異常判定閾値と変動量を共に用いるようにしても良い。その場合、例えば変動量（比）が閾値以下であっても、レスポンス時間がレスポンス異常判定閾値を越えていれば異常と判定するような方法を採用すれば良い。

直ちに通知すべき異常ではないと判定した場合、本実施形態では、サービスの追加等のトレンド７１を変化させる変更をシステム管理者が行った可能性があると見なして対応する。その対応は、図１１に示すように、新たなトレンド７１ａ、及び正常範囲７２ａを暫定的に作成し、新たに得られた観測データが正常範囲７２ａの外となるか否か確認することで行うようにしている。それにより、観測データが正常範囲７２ａの外になることが確認できた場合、異常が発生しているとして、システム管理者に異常を通知する。観測データが正常範囲７２ａ内になることが確認できた場合には、異常は発生していないとして、システム管理者に異常を通知しない。

このようにして本実施形態では、直ちに通知すべき深刻な異常は直ちに通知し、それ以外の異常は再度、新たに作成した正常範囲７２ａを用いた異常判定により、必要に応じて通知する。それにより、システム管理者にとっては、対応すべき異常にのみ対応すれば済むようになって、無駄な作業を行わなくとも済むようになる。これは、システム管理者の負荷を抑えられることを意味する。また、直ちに対応すべき深刻な異常には迅速に対応できることから、サービスの質の低下も最小限に抑えられることとなる。

図２は、異常検出装置５０の機能構成を説明する図である。この異常検出装置５０は、図２に示すように、トレンド／正常範囲データ５１を含む各種データを格納する記憶部５２と、サーバ情報収集装置４０から性能情報４１を取得する性能情報取得部５３と、ネットワーク情報収集装置３０からネットワーク情報（レスポンス時間）３１を取得するレスポンス時間取得部５４と、性能情報取得部５３が取得した性能情報４１を用いた相関分析により、トレンド７１及び正常範囲７２を示すトレンド／正常範囲データ５１を作成するトレンド解析部５５と、性能情報取得部５３が取得した性能情報４１、及びレスポンス時間取得部５４が取得したネットワーク情報３１を用いて異常を判定する異常判定部５６と、異常判定部５６が異常と判定した場合に、その異常をシステム管理者に通知するアラーム処理部５７と、を備えた構成となっている。これら各部５３〜５７の動作により、上記したような異常判定が実現される。

図２に示す機能構成は、異常検出装置５０として用いられるコンピュータに、本実施形態による異常検出プログラムを実行させることで実現される。ここで図１６を参照して、本発明を適用可能なコンピュータ、つまりこの異常検出プログラムを実行することで異常検出装置５０として使用可能なコンピュータについて具体的に説明する。

図１６に示すコンピュータは、ＣＰＵ８１、メモリ８２、入力装置８３、出力装置８４、外部記憶装置８５、媒体駆動装置８６、及びネットワーク接続装置８７を有し、これらがバス８８によって互いに接続された構成となっている。図１６に示す構成は一例であり、これに限定されるものではない。

ＣＰＵ８１は、当該コンピュータ全体の制御を行う。
メモリ８２は、プログラムの実行、データ更新等の際に、外部記憶装置８５（あるいは可搬型の記録媒体９０）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等の半導体メモリである。ＣＰＵ８１は、プログラムをメモリ８２に読み出して実行することにより、全体の制御を行う。

入力装置８３は、例えば、キーボード、マウス等の操作装置と接続可能なインターフェースである。接続された操作装置に対するユーザの操作を検出し、その検出結果をＣＰＵ８１に通知する。

出力装置８４は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置８７は、例えばネットワーク情報収集装置３０及びサーバ情報収集装置４０と通信ネットワークを介した通信を可能とさせるものである。外部記憶装置８５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。

媒体駆動装置８６は、光ディスクや光磁気ディスク等の可搬型の記録媒体９０にアクセスするものである。
上記異常検出プログラムは、外部記憶装置８５、若しくは記録媒体９０に記録されているか、或いは通信ネットワークを介してネットワーク接続８７により取得される。その異常検出プログラムをメモリ８２に読み出してＣＰＵ８１が実行することにより、異常検出装置５０は実現される。

図１６に示す構成では、図２の記憶部５２は例えば外部記憶装置８５、或いは記録媒体９０が装着された媒体駆動装置８６である。異常検出プログラム、及びトレンド／正常範囲データ５１を含む各種データが外部記憶装置８５にそれぞれ格納されていると想定する場合、性能情報取得部５３、レスポンス時間取得部５４及びアラーム処理部５７は共に、例えばＣＰＵ８１、メモリ８２、外部記憶装置８５、ネットワーク接続装置８７、及びバス８８によって実現される。トレンド解析部５５及び異常判定部５６は共に、例えばＣＰＵ８１、メモリ８２、外部記憶装置８５、及びバス８８によって実現される。

図１２は、異常検出処理のフローチャートである。この検出処理は、上記異常検出プログラムを異常検出装置５０が実行することにより実現される処理である。この検出処理を実行することにより、上記のような異常判定を異常検出装置５０は行うこととなる。次に図１２を参照して、この検出処理について詳細に説明する。

先ず、ステップＳ１１では、サーバ情報収集装置４０から性能情報４１、ネットワーク情報収集装置３０からネットワーク情報３１をそれぞれ取得する。次のステップＳ１２では、現在日時は最終データが示す日時より後（図１２中「トレンド解析時刻」と表記）か否か判定する。現在日時が最終データの示す日時より後であった場合、判定はＹＥＳとなり、ステップＳ１４で新しいトレンド７１及び正常範囲７２を作成してから、ステップＳ１５に移行する。現在日時がトレンド解析時刻より前であった場合には、判定はＮＯとなってステップＳ１３に移行する。

上述したように、取得した性能情報４１が示す入力パケット数とＣＰＵ負荷の組み合わせが正常範囲７２の外であった場合、トレンド７１及び正常範囲７２の再作成を行う。その再作成は、例えば変数である短期トレンド取得フラグをオン（ｏｎ）にし、その再作成を行うべき日時を示す最終データを設定して行われる。入力パケット数とＣＰＵ負荷の組み合わせが正常範囲７２の外にならなかった場合には、有効としているトレンド／正常範囲データ５１の最終データが示す日時が経過することにより、ステップＳ１２の判定はＹＥＳとなる。このようなことから、最終データが示す日時は、更新されている場合がある。それにより、図１２では最終データが示す日時を「トレンド解析時刻」と表記している。短期トレンド取得フラグがオンとなっている状況でステップＳ１４に移行した場合、トレンド／正常範囲データ５１の作成と共に、短期トレンド取得フラグのオフが行われる。短期トレンド取得フラグがオンされていることにより再作成したトレンド７１は以降「短期トレンド７１ａ」と呼ぶことにする。短期トレンド７１ａから設定される正常範囲７２は以降「短期正常範囲７２ａ」と呼ぶことにする。

ステップＳ１３では、短期トレンド取得フラグがオンか否か判定する。そのフラグがオン、例えばそのフラグの値が１であった場合、判定はＹＥＳとなってステップＳ１９に移行する。そのフラグがオフ、例えばそのフラグの値が０であった場合には、判定はＮＯとなってステップＳ１５に移行する。

ステップＳ１５では、取得した性能情報４１毎に、その性能情報４１が示す入力パケット数とＣＰＵ負荷の組み合わせを対応のトレンド／正常範囲データ５１が示す正常範囲７２と比較して、その組み合わせが正常範囲７２外か否か判定する。その組み合わせのなかに正常範囲７２外のものがあった場合、判定はＹＥＳとなってステップＳ１６に移行する。その組み合わせの何れも正常範囲７２内であった場合には、判定はＮＯとなり、上記ステップＳ１１に戻る。

ステップＳ１６では、短期トレンドを作成（取得）した直後か否か判定する。直前のステップＳ１５において、入力パケット数とＣＰＵ負荷の組み合わせが新しい短期正常範囲７２ａ外と確認された場合、判定はＹＥＳとなってステップＳ１７に移行し、異常の発生をシステム管理者に通知（緊急アラーム）する。その後は所定の処理を実行する。その組み合わせが外となったのが短期正常範囲７２ａでなかった場合には、判定はＮＯとなってステップＳ１８に移行する。

ステップＳ１８では、短期トレンド７１等を作成すべき日時（トレンド解析時刻）を設定し、その日時に最終データを更新し、短期トレンド取得フラグをオンにする。続くステップＳ１９では、レスポンス時間に大きな変動があるか否か判定する。ステップＳ１１で取得したネットワーク情報３１が示すレスポンス時間がレスポンス異常判定閾値を越えていた場合、判定はＹＥＳとなってステップＳ２０に移行し、異常の発生をシステム管理者に通知（緊急アラーム）する。その後は所定の処理を実行する。そのレスポンス時間がレスポンス異常判定閾値を越えていない場合には、判定はＮＯとなり、上記ステップＳ１１に戻る。

この異常検出処理を実行することにより、図２の各部５３−５７が実現される。ステップＳ１５、或いはステップＳ１９のＮＯの判定によりステップＳ１１に戻っても、直ちにステップＳ１１は実行しない。ステップＳ１１は、予め定めたタイミングの到来を待って実行する。それにより、異常検出処理は実際には例えば予め定めた時間間隔で実行される。

なお、本実施形態では、正常範囲７２を用いた異常判定により異常が判定された場合、レスポンス時間の閾値（レスポンス異常判定閾値）を判定基準とした異常判定を行うようになっているが、それ以外の判定基準を採用しても良い。入力パケット数とＣＰＵ負荷の組み合わせのなかで、直ちに通知すべき異常と見なす範囲をその判定基準として採用しても良い。以降は、そのような判定基準を採用した場合の変形例について、図１３〜図１５に示す各説明図を参照して具体的に説明する。

図１３は、入力パケット数とＣＰＵ負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。この図１３は、その範囲を、即時異常通知用閾値７３として設定した場合の例を示している。トレンド７１の上下に即時異常通知用閾値７３を設定しているのは、入力パケット数に対し、ＣＰＵ負荷の極端な増大、及び低下を共に異常として検出するためである。

このような即時異常通知用閾値７３を判定基準として採用しても、レスポンス時間の極端な増大や、ＣＰＵ負荷の極端な低下を深刻な異常と見なし、システム管理者に直ちに通知することができる。このため、上記実施形態と同様の効果を得ることができる。

図１４は、このような即時異常通知用閾値７３を設定する場合のトレンド／正常範囲データ５１のデータ構成を説明する図である。図１４に示すように、二つの即時異常通知用閾値７３は、即時異常通知閾値上限データ、及び即時異常通知閾値下限データとして管理される。それらのデータは、傾き、及びY切片を含む構成である。

図１５は、このような即時異常通知用閾値７３を設定した場合の異常検出処理のフローチャートである。この図１５では、図１２と基本的に同じ内容の処理ステップには同一の符号を付している。それにより、図１２から異なる部分にのみ着目して、その説明を行う。

この図１５では、ステップＳ１５のＹＥＳの判定によりステップＳ３１に移行する。そのステップＳ３１では、ステップＳ１５において、正常範囲７２外と確認された入力パケット数とＣＰＵ負荷の組み合わせ毎に、その組み合わせが２つの即時異常通知用閾値の何れかを越えているか否か判定する。その組み合わせのなかに２つの即時異常通知用閾値７３の範囲外となるものがあった場合、判定はＹＥＳとなってステップＳ３２に移行し、異常の発生をシステム管理者に通知（緊急アラーム）する。その後は所定の処理を実行する。その組み合わせの何れも２つの即時異常通知用閾値７３の範囲内であった場合には、判定はＮＯとなってステップＳ１６に移行する。ステップＳ１６以降は図１２と同じであるため、説明は省略する。

１ 通信ネットワーク
１０、６０ 端末装置
２０ サービスシステム
２１ ルータ
２２ ＷＥＢサーバ
２３ アプリケーション（ＡＰ）サーバ
２４ データベース（ＤＢ）サーバ
３０ ネットワーク情報収集装置
３１ ネットワーク情報
４０ サーバ情報収集装置
４１ 性能情報
５０ 異常検出装置
５１ トレンド／正常範囲データ
５２ 記憶部
５３ 性能情報取得部
５４ レスポンス時間取得部
５５ トレンド解析部
５６ 異常判定部
５７ アラーム処理部

Claims (7)

1. コンピュータの負荷情報を取得する性能情報取得部と、
   前記コンピュータの応答時間を取得する応答時間取得部と、
   前記負荷情報を基に前記コンピュータの異常動作を判定する第１の異常判定部と、
   前記第１の異常判定部が前記コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記コンピュータの異常動作を判定する第２の異常判定部と、
   前記第２の異常判定部が前記コンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、
   を具備することを特徴とする異常検出装置。
2. 前記性能情報取得部は、前記コンピュータのトラフィック量を取得し、
   前記トラフィック量と前記負荷情報の傾向を基に、前記第１の異常判定部の判定基準を決定する傾向解析部をさらに備えることを特徴とする請求１記載の異常検出装置。
3. 前記第１の異常判定部が前記負荷情報に著しい変化があると判断した場合には、前記第１の異常通知部が異常を通知することを特徴とする請求項１記載の異常検出装置。
4. コンピュータに、
   検査対象コンピュータの負荷情報を取得する性能情報手段と、
   前記検査対象コンピュータの応答時間を取得する応答時間取得手段と、
   前記負荷情報を基に前記検査対象コンピュータの異常動作を判定する第１の異常判定手段と、
   前記第１の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定する第２の異常判定手段と、
   前記第２の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知手段として機能させるためのプログラム。
5. 前記性能情報取得手段は、前記検査対象コンピュータのトラフィック量を取得し、
   前記トラフィック量と前記負荷情報の傾向を基に、前記第１の異常判定手段の判定基準を決定する傾向解析手段をさらに備えることを特徴とする請求４記載のプログラム。
6. 前記第１の異常判定手段が前記負荷情報に著しい変化があると判断した場合には、前記第１の異常通知手段が異常を通知することを特徴とする請求項４記載のプログラム。
7. コンピュータが、
   検査対象コンピュータの負荷情報を取得し、
   前記検査対象コンピュータの応答時間を取得し、
   前記負荷情報を基に前記検査対象コンピュータの異常動作を判定し、
   前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定し、
   前記応答時間に基づいた判定の結果、前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知を行う異常検出方法。