異常検出装置、プログラム、及び異常検出方法
【課題】システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステムを監視するための技術を提供する。
【解決手段】トレンド解析部55は、性能情報取得部53が取得した性能情報を用いた、トレンド及び正常範囲を示すトレンド/正常範囲データ51を作成する。異常判定部56は、性能情報が示す入力パケット数とCPU負荷の組み合わせを、対応する正常範囲と比較することにより、異常が発生したか否か判定し、異常が発生したと判定した場合に、レスポンス時間取得部54が取得したネットワーク情報(レスポンス時間)を予め定めた閾値と比較することにより、深刻な異常か否か再判定する。アラーム処理部57は、異常判定部56が深刻な異常と再判定した場合に、その異常をシステム管理者に通知する。
【解決手段】トレンド解析部55は、性能情報取得部53が取得した性能情報を用いた、トレンド及び正常範囲を示すトレンド/正常範囲データ51を作成する。異常判定部56は、性能情報が示す入力パケット数とCPU負荷の組み合わせを、対応する正常範囲と比較することにより、異常が発生したか否か判定し、異常が発生したと判定した場合に、レスポンス時間取得部54が取得したネットワーク情報(レスポンス時間)を予め定めた閾値と比較することにより、深刻な異常か否か再判定する。アラーム処理部57は、異常判定部56が深刻な異常と再判定した場合に、その異常をシステム管理者に通知する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムに発生する異常を検出するための技術に関する。
【背景技術】
【0002】
特開2006−238043号公報には、中継装置からトラフィック統計情報を取得し、時系列分析することによって、将来の中継通信数を予測し、異常を早期に判別することが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2006−238043号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明は、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステム(コンピュータ)を監視するための技術を提供することを目的とする。
【課題を解決するための手段】
【0005】
本発明を適用した1システムでは、コンピュータの負荷情報を取得する性能情報取得部と、コンピュータの応答時間を取得する応答時間取得部と、負荷情報を基に前記コンピュータの異常動作を判定する第1の異常判定部と、第1の異常判定部がコンピュータが異常動作していると判定した場合に、応答時間に基づいて、コンピュータの異常動作を判定する第2の異常判定部と、第2の異常判定部がコンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、を具備する。上記コンピュータは、例えば通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムを構成するサーバとして用いられるものである。
【発明の効果】
【0006】
本発明を適用した場合には、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステムを監視することができる。
【図面の簡単な説明】
【0007】
【図1】本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。
【図2】本実施形態による異常検出装置の機能構成を説明する図である。
【図3】サーバ情報収集装置が収集した性能情報のデータ構成を説明する図である。
【図4】ネットワーク情報収集装置が収集したネットワーク情報のデータ構成を説明する図である。
【図5】トレンド/正常範囲データの構成を説明する図である。
【図6】サービスシステムのレスポンス時間を説明する図である。
【図7】正常範囲を用いて行われる異常判定を説明する図である。
【図8】システム管理者がトレンドを変化させる変更を行った後に、性能情報から得られる入力パケット数とCPU負荷の組み合わせの例を説明する図である。
【図9】システム管理者がサービスを追加した場合のレスポンス時間の変化の例を説明する図である。
【図10】異常が発生した場合のレスポンス時間の変化の例を説明する図である。
【図11】直ちに通知すべき異常と判定しなかった場合の対応方法を説明する図である。
【図12】異常検出処理のフローチャートである。
【図13】入力パケット数とCPU負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。
【図14】即時異常通知用閾値を設定する場合のトレンド/正常範囲データのデータ構成を説明する図である。
【図15】異常検出処理のフローチャートである(変形例)。
【図16】本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0008】
近年の通信ネットワークの発達により、この通信ネットワークに接続された端末装置のユーザにサービスを提供するサービスシステムは数多く構築されている。このサービスシステムは、1台以上のサーバ(データ処理装置)を用いて構築される。多くの人の利用、或いは多くの種類のサービスの提供を想定したサービスシステムは、負荷を分散するために、複数のサーバ(データ処理装置)を用いて構築することにより、大規模化なものとなっているのが普通である。
【0009】
サービスは、快適に利用できるようにすることが重要である。このことから、サービスの質を常に維持できるように、サーバ(コンピュータ)の動作状況を示す情報を性能情報(負荷情報)として収集し、監視することが行われている。性能情報としては、例えばCPU負荷(使用率)、メモリ使用量、ディスク使用量、及び単位時間当たりに入力(受信)するデータ量(トラフィック量)などを挙げることができる。通常、サービスの提供を要求するデータの量はサービスの種類や状況等に応じて大きく変動しない。それによりトラフィック量はサービスを要求した要求数を表すものとなる。
【0010】
大規模なサービスシステムでは、多くの種類のサービスを提供できる、或いは多くの人が利用することから、負荷のモデルの作成は困難なのが実情である。しかし、通常、ユーザの要求が増えるほど、サービスシステムを構成するサーバの処理量(負荷)も増加するという相関が存在する。このことから、サービスシステムでは、サービスシステム内のサーバ毎に、そのサーバのトラフィック量(要求数)とそのサーバのCPU負荷の相関分析を行い、その結果を用いて異常判定を行うシステム監視方法が採用される場合が多い。
【0011】
この監視方法では、相関分析の結果、つまりトラフィック量とCPU負荷の相関関係をトレンド(傾向)として採用し、そのトレンドから、トラフィック量とCPU負荷の組み合わせのなかで正常と見なす正常範囲を作成(設定)する。それにより、この監視方法では、得られたトラフィック量とCPU負荷の組み合わせが正常範囲内でなかった場合に、サービスシステムに異常が発生したと判定する。異常検出装置は、そのようにして異常が発生したか否かを判定するものである。相関分析に用いるトラフィック量とCPU負荷の組み合わせは、直近の定めた期間内に得られた性能情報のものである。正常範囲と比較するトラフィック量とCPU負荷の組み合わせも、性能情報から得られたものである。
【0012】
サービスシステムでは、システム管理者によって、サービスの追加、或いは修正等の変更が行われる場合がある。そのような変更に伴い、相関分析から得られるトレンドは変化することがある。正常範囲は、通常、予め定めたタイミングで再作成する。しかし、そのような変更を行った直後には、その変更に合ったトレンドは作成していない。このため、その変更に伴ってトレンドが比較的に大きく変化する場合には、実際には異常ではなくとも異常と誤判定してしまうことがある。
【0013】
このような誤判定を行う可能性があることから、システム監視方法のなかには、得られたトラフィック量とCPU負荷の組み合わせが正常範囲外となった場合に、一定期間、異常と判定しないようにしたものがある。その従来のシステム監視方法では、新たな相関分析により正常範囲が得られた後、その正常範囲を用いて異常判定を行うようにしている(特許文献1)。それにより、実際に発生した異常のみを検出することができる。
【0014】
得られたトラフィック量とCPU負荷の組み合わせが正常範囲外となるのは、システム管理者による何らかの変更が原因であるとは限らない。つまり、実際に発生した異常、つまり通知すべき異常が原因である可能性がある。このため、一定期間、異常と判定しないようにした場合には、たとえ直ちに通知すべき深刻な異常が実際に発生していたとしても、その異常をシステム管理者に通知するのが遅れてしまうという問題点があった。これは、サービスを快適に利用できない人をより多くする、サービスを快適に利用できない期間をより長くする、ということを意味する。
【0015】
システム管理者による変更に伴う正常範囲の変化への対応としては、システム管理者自身が正常範囲の再設定を指示するというものも考えられる。しかし、この方法でも、正常範囲を再設定するまで異常判定を行うことはできない。このため、上記従来のシステム監視方法と同様の問題点が存在することとなる。
【0016】
システム管理者は通常、頻繁にサービスの追加/修正/削除などのサービス変更作業、或いはチューニングなどのシステム変更作業を行っている。正常範囲の再設定の指示は、システム管理者の負荷を増大させる。このようなことから、システム管理者による変更に伴うトレンドの変化に対応することに加えて、システム管理者の負荷の増大を抑えつつ、実際に発生した深刻な異常はシステム管理者が直ちに把握できるようにすることが重要である。
【0017】
以下、本発明の実施形態について図面を参照しながら説明する。
図1は、本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。
【0018】
このネットワークシステムは、図1に示すように、端末装置10が接続可能な通信ネットワーク1に接続された、その端末装置10のユーザにサービスを提供可能なサービスシステム20と、そのサービスシステム20が通信ネットワーク1を介して送受信するデータ(パケット)に係わるネットワーク情報31を収集するネットワーク情報収集装置30と、サービスシステム20を構成するサーバ毎に、そのサーバの動作状況を示す性能情報41を収集するサーバ情報収集装置40と、ネットワーク情報収集装置30及びサーバ情報収集装置40がそれぞれ収集した情報を用いて、サービスシステム20に発生した異常を検出する異常検出装置50と、及びシステム管理者が使用する端末装置60と、を備えた構成となっている。本実施形態による異常検出装置は、この異常検出装置50として実現されている。
【0019】
上記サービスシステム20は、ルータ21と、複数台のWEBサーバ22と、複数台のアプリケーション(AP)サーバ23と、1台以上のデータベース(DB)サーバ24と、を備えている。それらのルータ21及び各サーバ(検査対象コンピュータ)22〜24は例えばLANに接続されている。
【0020】
ルータ21は、端末装置10から受信したパケットのヘッダに格納されている送信先アドレスを参照し、何れかのWEBサーバ22に転送する。WEBサーバ22は、その転送により受信したパケットを解析し、そのパケットにより要求されたサービスを提供するための処理をAPサーバ23に依頼する。APサーバ23は、必要に応じてDBサーバ24からデータを取得し、依頼された処理を実行し、その実行結果をWEBサーバ22に返す。WEBサーバ22は、その実行結果を用いて、応答とするパケットを生成し送信する。そのようにして送信されたパケットは、ルータ21、及び通信ネットワーク1を介して端末装置10に受信される。以降、端末装置10はシステム管理者が使用する端末装置60と区別するために、「ユーザ端末」と表記する。
【0021】
図6は、サービスシステム20のレスポンス時間を説明する図である。
ユーザ端末10から送信されたパケットは、サービスシステム20のルータ21に受信されてWEBサーバ22に転送されて処理される。その結果、上記したように、APサーバ23による処理、DBサーバ24による処理、APサーバ23による処理、WEBサーバ22による処理がそれぞれ実行され、WEBサーバ22が生成したパケットがルータ21を介して通信ネットワーク1上に出力される。このことから、ユーザ端末10からのパケットを受信してから応答とするパケットを返信するまでに要する時間であるサービスシステム20全体のレスポンス時間は、それら各サーバ22〜24の処理の実行時間、サーバ間の通信に要した時間等を累算したものとなる。
【0022】
ルータ21には、このレスポンス時間を計時する計時プログラムが搭載されている。その計時プログラムは、例えばユーザ端末10から受信したパケット毎に、レスポンス時間を計時し、予め定めた単位時間毎に、計時したレスポンス時間の平均値を算出する。ネットワーク情報収集装置30は、例えばその単位時間間隔で、レスポンス時間の平均値をネットワーク情報31としてルータ21から収集する。
【0023】
図4は、ネットワーク情報収集装置30が収集したネットワーク情報31のデータ構成を説明する図である。図4に示すように、ネットワーク情報収集装置30は、レスポンス時間の平均値を、その平均値が収集された日時を示す日時情報を共に1レコード(エントリ)に格納する形でネットワーク情報31を保存する。その日時情報は、ルータ21が付しても良いが、ネットワーク情報収集装置30が付すようにしても良い。
【0024】
このようなレスポンス時間(の平均値)の収集は、周知技術を用いて行われる。以降、特に断らない限り、レスポンス時間とは、収集されたレスポンス時間の平均値を指す意味で用いる。
【0025】
各サーバ22〜24は、例えば性能情報収集用の収集プログラムを実行することにより、予め定めた設定に従い、自サーバの動作状況を示す性能情報(負荷情報)41を生成する。その性能情報41として生成する情報には、自サーバが入力(受信)したデータ量を示すトラフィック量、CPU負荷(使用率)、及び日時が含まれる。本実施形態では、そのトラフィック量を示す情報として、入力パケット数を採用している。入力パケット数は、設定された単位時間に入力したパケットの総数であり、CPU負荷は、その単位時間の平均のCPU負荷である。そのような性能情報41は、例えばその単位時間間隔でサーバ情報収集装置40により収集される。
【0026】
図3は、サーバ情報収集装置40が収集した性能情報41のデータ構成を説明する図である。図3に示すように、サーバ情報収集装置40は、日時、入力パケット数、及びCPU負荷を含む性能情報41を、その性能情報41を収集したサーバを示す識別子であるサーバ名を追加して1レコード(エントリ)に格納する形で保存する。このような性能情報41の収集も周知技術を用いて行われる。
【0027】
異常検出装置50は、例えばサーバ情報収集装置40と同様に、上記単位時間間隔でそのサーバ情報収集装置40から新たに収集された性能情報41を取得する。トラフィック量(入力パケット数)とCPU負荷の相関分析は、例えば予め定めた時間間隔でサーバ毎に行う。その相関分析により、例えば入力パケット数とCPU負荷の相関関係を示す回帰直線をトレンド(傾向)として作成し、そのトレンドから、入力パケット数とCPU負荷の組み合わせのなかで正常と見なす正常範囲を作成(設定)する。作成した正常範囲は、サーバ情報収集装置40から随時、取得する性能情報41が示す入力パケット数とCPU負荷の組み合わせと比較することにより、その正常範囲を用いた異常判定を行う。
【0028】
図7は、正常範囲を用いて行われる異常判定を説明する図である。この図7では、横(X)に入力パケット数、縦(Y)軸にCPU負荷を取り、1サーバのトレンド71と正常範囲72をXY平面上で表している(これは、図8、図11及び図13でも同様である)。正常範囲72は、四角形で表している。この正常範囲72の上限、及び下限は、入力パケット数が大きくなるほど、トレンド71との差の絶対値が大きくなるように作成されている。下限を作成するのは、サーバが実行すべき処理を実行できない等の理由により、CPU負荷が大きく低下するケースがあるからである。
【0029】
図7中の黒丸は、トレンド(回帰直線)71の作成に用いられた入力パケット数とCPU負荷の組み合わせ、つまり実際に性能情報41の形で観測された観測データを示している。それにより図7は、正常範囲72の外に位置する観測データが得られた場合に、異常と判定することを示している。
【0030】
異常検出装置50は、作成したトレンド71及び正常範囲72はトレンド/正常範囲データ51として管理する。図5は、そのデータ51の構成を説明する図である。図5に示すように、そのデータ51は、対応するサーバを示すサーバ名、トレンド71を作成した日時(トレンド作成日時)、このデータ51を有効とする日時を示す開始データ、このデータ51を無効とする日時を示す最終データ、トレンド71を示す回帰直線データ、正常範囲72の上限を示す正常範囲上限データ、及び正常範囲72の下限を示す正常範囲下限データを含む構成となっている。
【0031】
回帰直線データは、相関係数、傾き、及びY切片を含む構成である。正常範囲上限データ、及び正常範囲下限データは傾き、及びY切片を含む構成である。
異常検出装置50は、最終データが示す日時の経過により、次のトレンド71、及び正常範囲72を作成する。システム管理者が例えばサービスを追加する等の変更は、トレンド71、及び正常範囲72の作成とは別に行われるのが普通である。また、適切な正常範囲72の作成には、或る程度の性能情報41が必要である。このようなことから、システム管理者がサービスを追加する等の変更を行った直後には、その変更に合った適切な正常範囲72は作成されていないのが普通である。
【0032】
図1に示すような構成のサービスシステム20では、サービスの追加に伴い、APサーバ23、及びDBサーバ24のうちの少なくとも一方は、入力パケット数に対するCPU負荷が増大するのが普通である。このため、図8に示すように、観測データ、つまり性能情報41として得られた入力パケット数とCPU負荷の組み合わせが示す黒丸の位置は、異常が発生していないとしても、正常範囲72の外となる可能性がある。しかし、観測データと正常範囲72との比較を行ったのみでは、実際に異常が発生しているか否かを必ずしも適切に判定することはできない。システム管理者によるトレンド71を変化させる変更により、本来は異常ではないものが異常と判定された可能性がある。このようなことから本実施形態では、観測データが正常範囲72の外となった場合に、以下のように対応している。図9〜図11に示す各説明図を参照して具体的に説明する。
【0033】
図9は、サービスを追加した場合のレスポンス時間の変化の例を説明する図である。この図9では、横(X)軸に時間、縦(Y)軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。サービスを追加した時点は、図9中、横軸を指す矢印により示している。
【0034】
図9に示すように、異常が発生していない状況でサービスを追加したとしても、レスポンス時間は大幅に変化しないのが普通である。これには、サービスの追加の前後で入力パケット数が大きく変化することは少ない、CPU負荷が大きく変化するようなサービスの追加を行うケースは稀である、といった実情がある。
【0035】
レスポンス時間が大きく変化しなければ、ユーザは、利用しているサービスの質が低下したと感じる可能性は低い。このことから、たとえ観測データが正常範囲72の外となったとしても、システム管理者が早急に対応しなければならない必要性は低いと云える。それにより、システム管理者に異常を直ちに通知しない。
【0036】
図10は、異常が発生した場合のレスポンス時間の変化の例を説明する図である。この図10でも同様に、横(X)軸に時間、縦(Y)軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。異常が発生した時点は、図10中、横軸を指す矢印により示している。図10に示すようなレスポンス時間の変化は、例えばプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放するガベージコレクションが短時間に頻発する異常によって生じる。
【0037】
図10に示すように、異常が発生すると、レスポンス時間は非常に長くなるのが普通である。非常に長いレスポンス時間は、ユーザにサービスの質の低下を感じさせる可能性が高い。このことから本実施形態では、直ちに通知すべき異常を判定するための閾値(レスポンス異常判定閾値)を設定し、レスポンス時間がこの閾値を越えたときには、システム管理者に異常を直ちに通知する。その通知は、例えば異常の発生を伝えるためのメッセージ、或いはメールをシステム管理者が使用する端末装置60に送信することで行われる。
【0038】
このようにして本実施形態では、観測データが正常範囲72の外となった場合、レスポンス時間を参照し、直ちに通知すべき異常か否か判定するようにしている。それにより、直ちに通知すべき異常と判定すれば、異常を直ちにシステム管理者に通知し、直ちに通知すべき異常ではないと判定すれば、深刻な異常の可能性は低く、且つサービスを利用するユーザへの影響も小さいと見なし、異常の通知を控える。このため、深刻と考えられる異常の通知が遅くなるのは確実に回避される。それにより、サービスを快適に利用できない人、その時間は共に最小限に抑えることができるようになる。異常検出装置50がネットワーク情報収集装置30を介してネットワーク情報(レスポンス時間)を取得するのは、このような異常判定を行うためである。
【0039】
なお、本実施形態では、レスポンス異常判定閾値を判定基準として設定して、直ちに通知すべき異常を判定(検出)するようにしているが、レスポンス時間の変動量を判定基準として採用しても良い。その変動量の閾値は、レスポンス異常判定閾値のように固定の時間値としても良いが、例えば単位時間当たりのレスポンス時間の差分を、その差分の算出に用いた二つのレスポンス時間の一方で割ることにより得られるような比であっても良い。入力パケット数の変動を考慮して、そのような計算により得られる変動量(比)に、二つのレスポンス時間が得られた際の各WEBサーバ22の入力パケット数の累算値の比を乗算したものとしても良い。レスポンス異常判定閾値と変動量を共に用いるようにしても良い。その場合、例えば変動量(比)が閾値以下であっても、レスポンス時間がレスポンス異常判定閾値を越えていれば異常と判定するような方法を採用すれば良い。
【0040】
直ちに通知すべき異常ではないと判定した場合、本実施形態では、サービスの追加等のトレンド71を変化させる変更をシステム管理者が行った可能性があると見なして対応する。その対応は、図11に示すように、新たなトレンド71a、及び正常範囲72aを暫定的に作成し、新たに得られた観測データが正常範囲72aの外となるか否か確認することで行うようにしている。それにより、観測データが正常範囲72aの外になることが確認できた場合、異常が発生しているとして、システム管理者に異常を通知する。観測データが正常範囲72a内になることが確認できた場合には、異常は発生していないとして、システム管理者に異常を通知しない。
【0041】
このようにして本実施形態では、直ちに通知すべき深刻な異常は直ちに通知し、それ以外の異常は再度、新たに作成した正常範囲72aを用いた異常判定により、必要に応じて通知する。それにより、システム管理者にとっては、対応すべき異常にのみ対応すれば済むようになって、無駄な作業を行わなくとも済むようになる。これは、システム管理者の負荷を抑えられることを意味する。また、直ちに対応すべき深刻な異常には迅速に対応できることから、サービスの質の低下も最小限に抑えられることとなる。
【0042】
図2は、異常検出装置50の機能構成を説明する図である。この異常検出装置50は、図2に示すように、トレンド/正常範囲データ51を含む各種データを格納する記憶部52と、サーバ情報収集装置40から性能情報41を取得する性能情報取得部53と、ネットワーク情報収集装置30からネットワーク情報(レスポンス時間)31を取得するレスポンス時間取得部54と、性能情報取得部53が取得した性能情報41を用いた相関分析により、トレンド71及び正常範囲72を示すトレンド/正常範囲データ51を作成するトレンド解析部55と、性能情報取得部53が取得した性能情報41、及びレスポンス時間取得部54が取得したネットワーク情報31を用いて異常を判定する異常判定部56と、異常判定部56が異常と判定した場合に、その異常をシステム管理者に通知するアラーム処理部57と、を備えた構成となっている。これら各部53〜57の動作により、上記したような異常判定が実現される。
【0043】
図2に示す機能構成は、異常検出装置50として用いられるコンピュータに、本実施形態による異常検出プログラムを実行させることで実現される。ここで図16を参照して、本発明を適用可能なコンピュータ、つまりこの異常検出プログラムを実行することで異常検出装置50として使用可能なコンピュータについて具体的に説明する。
【0044】
図16に示すコンピュータは、CPU81、メモリ82、入力装置83、出力装置84、外部記憶装置85、媒体駆動装置86、及びネットワーク接続装置87を有し、これらがバス88によって互いに接続された構成となっている。図16に示す構成は一例であり、これに限定されるものではない。
【0045】
CPU81は、当該コンピュータ全体の制御を行う。
メモリ82は、プログラムの実行、データ更新等の際に、外部記憶装置85(あるいは可搬型の記録媒体90)に記憶されているプログラムあるいはデータを一時的に格納するRAM等の半導体メモリである。CPU81は、プログラムをメモリ82に読み出して実行することにより、全体の制御を行う。
【0046】
入力装置83は、例えば、キーボード、マウス等の操作装置と接続可能なインターフェースである。接続された操作装置に対するユーザの操作を検出し、その検出結果をCPU81に通知する。
【0047】
出力装置84は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置87は、例えばネットワーク情報収集装置30及びサーバ情報収集装置40と通信ネットワークを介した通信を可能とさせるものである。外部記憶装置85は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【0048】
媒体駆動装置86は、光ディスクや光磁気ディスク等の可搬型の記録媒体90にアクセスするものである。
上記異常検出プログラムは、外部記憶装置85、若しくは記録媒体90に記録されているか、或いは通信ネットワークを介してネットワーク接続87により取得される。その異常検出プログラムをメモリ82に読み出してCPU81が実行することにより、異常検出装置50は実現される。
【0049】
図16に示す構成では、図2の記憶部52は例えば外部記憶装置85、或いは記録媒体90が装着された媒体駆動装置86である。異常検出プログラム、及びトレンド/正常範囲データ51を含む各種データが外部記憶装置85にそれぞれ格納されていると想定する場合、性能情報取得部53、レスポンス時間取得部54及びアラーム処理部57は共に、例えばCPU81、メモリ82、外部記憶装置85、ネットワーク接続装置87、及びバス88によって実現される。トレンド解析部55及び異常判定部56は共に、例えばCPU81、メモリ82、外部記憶装置85、及びバス88によって実現される。
【0050】
図12は、異常検出処理のフローチャートである。この検出処理は、上記異常検出プログラムを異常検出装置50が実行することにより実現される処理である。この検出処理を実行することにより、上記のような異常判定を異常検出装置50は行うこととなる。次に図12を参照して、この検出処理について詳細に説明する。
【0051】
先ず、ステップS11では、サーバ情報収集装置40から性能情報41、ネットワーク情報収集装置30からネットワーク情報31をそれぞれ取得する。次のステップS12では、現在日時は最終データが示す日時より後(図12中「トレンド解析時刻」と表記)か否か判定する。現在日時が最終データの示す日時より後であった場合、判定はYESとなり、ステップS14で新しいトレンド71及び正常範囲72を作成してから、ステップS15に移行する。現在日時がトレンド解析時刻より前であった場合には、判定はNOとなってステップS13に移行する。
【0052】
上述したように、取得した性能情報41が示す入力パケット数とCPU負荷の組み合わせが正常範囲72の外であった場合、トレンド71及び正常範囲72の再作成を行う。その再作成は、例えば変数である短期トレンド取得フラグをオン(on)にし、その再作成を行うべき日時を示す最終データを設定して行われる。入力パケット数とCPU負荷の組み合わせが正常範囲72の外にならなかった場合には、有効としているトレンド/正常範囲データ51の最終データが示す日時が経過することにより、ステップS12の判定はYESとなる。このようなことから、最終データが示す日時は、更新されている場合がある。それにより、図12では最終データが示す日時を「トレンド解析時刻」と表記している。短期トレンド取得フラグがオンとなっている状況でステップS14に移行した場合、トレンド/正常範囲データ51の作成と共に、短期トレンド取得フラグのオフが行われる。短期トレンド取得フラグがオンされていることにより再作成したトレンド71は以降「短期トレンド71a」と呼ぶことにする。短期トレンド71aから設定される正常範囲72は以降「短期正常範囲72a」と呼ぶことにする。
【0053】
ステップS13では、短期トレンド取得フラグがオンか否か判定する。そのフラグがオン、例えばそのフラグの値が1であった場合、判定はYESとなってステップS19に移行する。そのフラグがオフ、例えばそのフラグの値が0であった場合には、判定はNOとなってステップS15に移行する。
【0054】
ステップS15では、取得した性能情報41毎に、その性能情報41が示す入力パケット数とCPU負荷の組み合わせを対応のトレンド/正常範囲データ51が示す正常範囲72と比較して、その組み合わせが正常範囲72外か否か判定する。その組み合わせのなかに正常範囲72外のものがあった場合、判定はYESとなってステップS16に移行する。その組み合わせの何れも正常範囲72内であった場合には、判定はNOとなり、上記ステップS11に戻る。
【0055】
ステップS16では、短期トレンドを作成(取得)した直後か否か判定する。直前のステップS15において、入力パケット数とCPU負荷の組み合わせが新しい短期正常範囲72a外と確認された場合、判定はYESとなってステップS17に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。その組み合わせが外となったのが短期正常範囲72aでなかった場合には、判定はNOとなってステップS18に移行する。
【0056】
ステップS18では、短期トレンド71等を作成すべき日時(トレンド解析時刻)を設定し、その日時に最終データを更新し、短期トレンド取得フラグをオンにする。続くステップS19では、レスポンス時間に大きな変動があるか否か判定する。ステップS11で取得したネットワーク情報31が示すレスポンス時間がレスポンス異常判定閾値を越えていた場合、判定はYESとなってステップS20に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。そのレスポンス時間がレスポンス異常判定閾値を越えていない場合には、判定はNOとなり、上記ステップS11に戻る。
【0057】
この異常検出処理を実行することにより、図2の各部53−57が実現される。ステップS15、或いはステップS19のNOの判定によりステップS11に戻っても、直ちにステップS11は実行しない。ステップS11は、予め定めたタイミングの到来を待って実行する。それにより、異常検出処理は実際には例えば予め定めた時間間隔で実行される。
【0058】
なお、本実施形態では、正常範囲72を用いた異常判定により異常が判定された場合、レスポンス時間の閾値(レスポンス異常判定閾値)を判定基準とした異常判定を行うようになっているが、それ以外の判定基準を採用しても良い。入力パケット数とCPU負荷の組み合わせのなかで、直ちに通知すべき異常と見なす範囲をその判定基準として採用しても良い。以降は、そのような判定基準を採用した場合の変形例について、図13〜図15に示す各説明図を参照して具体的に説明する。
【0059】
図13は、入力パケット数とCPU負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。この図13は、その範囲を、即時異常通知用閾値73として設定した場合の例を示している。トレンド71の上下に即時異常通知用閾値73を設定しているのは、入力パケット数に対し、CPU負荷の極端な増大、及び低下を共に異常として検出するためである。
【0060】
このような即時異常通知用閾値73を判定基準として採用しても、レスポンス時間の極端な増大や、CPU負荷の極端な低下を深刻な異常と見なし、システム管理者に直ちに通知することができる。このため、上記実施形態と同様の効果を得ることができる。
【0061】
図14は、このような即時異常通知用閾値73を設定する場合のトレンド/正常範囲データ51のデータ構成を説明する図である。図14に示すように、二つの即時異常通知用閾値73は、即時異常通知閾値上限データ、及び即時異常通知閾値下限データとして管理される。それらのデータは、傾き、及びY切片を含む構成である。
【0062】
図15は、このような即時異常通知用閾値73を設定した場合の異常検出処理のフローチャートである。この図15では、図12と基本的に同じ内容の処理ステップには同一の符号を付している。それにより、図12から異なる部分にのみ着目して、その説明を行う。
【0063】
この図15では、ステップS15のYESの判定によりステップS31に移行する。そのステップS31では、ステップS15において、正常範囲72外と確認された入力パケット数とCPU負荷の組み合わせ毎に、その組み合わせが2つの即時異常通知用閾値の何れかを越えているか否か判定する。その組み合わせのなかに2つの即時異常通知用閾値73の範囲外となるものがあった場合、判定はYESとなってステップS32に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。その組み合わせの何れも2つの即時異常通知用閾値73の範囲内であった場合には、判定はNOとなってステップS16に移行する。ステップS16以降は図12と同じであるため、説明は省略する。
【符号の説明】
【0064】
1 通信ネットワーク
10、60 端末装置
20 サービスシステム
21 ルータ
22 WEBサーバ
23 アプリケーション(AP)サーバ
24 データベース(DB)サーバ
30 ネットワーク情報収集装置
31 ネットワーク情報
40 サーバ情報収集装置
41 性能情報
50 異常検出装置
51 トレンド/正常範囲データ
52 記憶部
53 性能情報取得部
54 レスポンス時間取得部
55 トレンド解析部
56 異常判定部
57 アラーム処理部
【技術分野】
【0001】
本発明は、通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムに発生する異常を検出するための技術に関する。
【背景技術】
【0002】
特開2006−238043号公報には、中継装置からトラフィック統計情報を取得し、時系列分析することによって、将来の中継通信数を予測し、異常を早期に判別することが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2006−238043号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明は、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステム(コンピュータ)を監視するための技術を提供することを目的とする。
【課題を解決するための手段】
【0005】
本発明を適用した1システムでは、コンピュータの負荷情報を取得する性能情報取得部と、コンピュータの応答時間を取得する応答時間取得部と、負荷情報を基に前記コンピュータの異常動作を判定する第1の異常判定部と、第1の異常判定部がコンピュータが異常動作していると判定した場合に、応答時間に基づいて、コンピュータの異常動作を判定する第2の異常判定部と、第2の異常判定部がコンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、を具備する。上記コンピュータは、例えば通信ネットワークを介して接続される端末装置のユーザにサービスを提供するサービスシステムを構成するサーバとして用いられるものである。
【発明の効果】
【0006】
本発明を適用した場合には、システム管理者による変更に伴うトレンドの変化に対応しつつ、実際に発生した深刻な異常の通知を直ちに行えるようにサービスシステムを監視することができる。
【図面の簡単な説明】
【0007】
【図1】本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。
【図2】本実施形態による異常検出装置の機能構成を説明する図である。
【図3】サーバ情報収集装置が収集した性能情報のデータ構成を説明する図である。
【図4】ネットワーク情報収集装置が収集したネットワーク情報のデータ構成を説明する図である。
【図5】トレンド/正常範囲データの構成を説明する図である。
【図6】サービスシステムのレスポンス時間を説明する図である。
【図7】正常範囲を用いて行われる異常判定を説明する図である。
【図8】システム管理者がトレンドを変化させる変更を行った後に、性能情報から得られる入力パケット数とCPU負荷の組み合わせの例を説明する図である。
【図9】システム管理者がサービスを追加した場合のレスポンス時間の変化の例を説明する図である。
【図10】異常が発生した場合のレスポンス時間の変化の例を説明する図である。
【図11】直ちに通知すべき異常と判定しなかった場合の対応方法を説明する図である。
【図12】異常検出処理のフローチャートである。
【図13】入力パケット数とCPU負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。
【図14】即時異常通知用閾値を設定する場合のトレンド/正常範囲データのデータ構成を説明する図である。
【図15】異常検出処理のフローチャートである(変形例)。
【図16】本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0008】
近年の通信ネットワークの発達により、この通信ネットワークに接続された端末装置のユーザにサービスを提供するサービスシステムは数多く構築されている。このサービスシステムは、1台以上のサーバ(データ処理装置)を用いて構築される。多くの人の利用、或いは多くの種類のサービスの提供を想定したサービスシステムは、負荷を分散するために、複数のサーバ(データ処理装置)を用いて構築することにより、大規模化なものとなっているのが普通である。
【0009】
サービスは、快適に利用できるようにすることが重要である。このことから、サービスの質を常に維持できるように、サーバ(コンピュータ)の動作状況を示す情報を性能情報(負荷情報)として収集し、監視することが行われている。性能情報としては、例えばCPU負荷(使用率)、メモリ使用量、ディスク使用量、及び単位時間当たりに入力(受信)するデータ量(トラフィック量)などを挙げることができる。通常、サービスの提供を要求するデータの量はサービスの種類や状況等に応じて大きく変動しない。それによりトラフィック量はサービスを要求した要求数を表すものとなる。
【0010】
大規模なサービスシステムでは、多くの種類のサービスを提供できる、或いは多くの人が利用することから、負荷のモデルの作成は困難なのが実情である。しかし、通常、ユーザの要求が増えるほど、サービスシステムを構成するサーバの処理量(負荷)も増加するという相関が存在する。このことから、サービスシステムでは、サービスシステム内のサーバ毎に、そのサーバのトラフィック量(要求数)とそのサーバのCPU負荷の相関分析を行い、その結果を用いて異常判定を行うシステム監視方法が採用される場合が多い。
【0011】
この監視方法では、相関分析の結果、つまりトラフィック量とCPU負荷の相関関係をトレンド(傾向)として採用し、そのトレンドから、トラフィック量とCPU負荷の組み合わせのなかで正常と見なす正常範囲を作成(設定)する。それにより、この監視方法では、得られたトラフィック量とCPU負荷の組み合わせが正常範囲内でなかった場合に、サービスシステムに異常が発生したと判定する。異常検出装置は、そのようにして異常が発生したか否かを判定するものである。相関分析に用いるトラフィック量とCPU負荷の組み合わせは、直近の定めた期間内に得られた性能情報のものである。正常範囲と比較するトラフィック量とCPU負荷の組み合わせも、性能情報から得られたものである。
【0012】
サービスシステムでは、システム管理者によって、サービスの追加、或いは修正等の変更が行われる場合がある。そのような変更に伴い、相関分析から得られるトレンドは変化することがある。正常範囲は、通常、予め定めたタイミングで再作成する。しかし、そのような変更を行った直後には、その変更に合ったトレンドは作成していない。このため、その変更に伴ってトレンドが比較的に大きく変化する場合には、実際には異常ではなくとも異常と誤判定してしまうことがある。
【0013】
このような誤判定を行う可能性があることから、システム監視方法のなかには、得られたトラフィック量とCPU負荷の組み合わせが正常範囲外となった場合に、一定期間、異常と判定しないようにしたものがある。その従来のシステム監視方法では、新たな相関分析により正常範囲が得られた後、その正常範囲を用いて異常判定を行うようにしている(特許文献1)。それにより、実際に発生した異常のみを検出することができる。
【0014】
得られたトラフィック量とCPU負荷の組み合わせが正常範囲外となるのは、システム管理者による何らかの変更が原因であるとは限らない。つまり、実際に発生した異常、つまり通知すべき異常が原因である可能性がある。このため、一定期間、異常と判定しないようにした場合には、たとえ直ちに通知すべき深刻な異常が実際に発生していたとしても、その異常をシステム管理者に通知するのが遅れてしまうという問題点があった。これは、サービスを快適に利用できない人をより多くする、サービスを快適に利用できない期間をより長くする、ということを意味する。
【0015】
システム管理者による変更に伴う正常範囲の変化への対応としては、システム管理者自身が正常範囲の再設定を指示するというものも考えられる。しかし、この方法でも、正常範囲を再設定するまで異常判定を行うことはできない。このため、上記従来のシステム監視方法と同様の問題点が存在することとなる。
【0016】
システム管理者は通常、頻繁にサービスの追加/修正/削除などのサービス変更作業、或いはチューニングなどのシステム変更作業を行っている。正常範囲の再設定の指示は、システム管理者の負荷を増大させる。このようなことから、システム管理者による変更に伴うトレンドの変化に対応することに加えて、システム管理者の負荷の増大を抑えつつ、実際に発生した深刻な異常はシステム管理者が直ちに把握できるようにすることが重要である。
【0017】
以下、本発明の実施形態について図面を参照しながら説明する。
図1は、本実施形態による異常検出装置が適用されたネットワークシステムの構成を説明する図である。
【0018】
このネットワークシステムは、図1に示すように、端末装置10が接続可能な通信ネットワーク1に接続された、その端末装置10のユーザにサービスを提供可能なサービスシステム20と、そのサービスシステム20が通信ネットワーク1を介して送受信するデータ(パケット)に係わるネットワーク情報31を収集するネットワーク情報収集装置30と、サービスシステム20を構成するサーバ毎に、そのサーバの動作状況を示す性能情報41を収集するサーバ情報収集装置40と、ネットワーク情報収集装置30及びサーバ情報収集装置40がそれぞれ収集した情報を用いて、サービスシステム20に発生した異常を検出する異常検出装置50と、及びシステム管理者が使用する端末装置60と、を備えた構成となっている。本実施形態による異常検出装置は、この異常検出装置50として実現されている。
【0019】
上記サービスシステム20は、ルータ21と、複数台のWEBサーバ22と、複数台のアプリケーション(AP)サーバ23と、1台以上のデータベース(DB)サーバ24と、を備えている。それらのルータ21及び各サーバ(検査対象コンピュータ)22〜24は例えばLANに接続されている。
【0020】
ルータ21は、端末装置10から受信したパケットのヘッダに格納されている送信先アドレスを参照し、何れかのWEBサーバ22に転送する。WEBサーバ22は、その転送により受信したパケットを解析し、そのパケットにより要求されたサービスを提供するための処理をAPサーバ23に依頼する。APサーバ23は、必要に応じてDBサーバ24からデータを取得し、依頼された処理を実行し、その実行結果をWEBサーバ22に返す。WEBサーバ22は、その実行結果を用いて、応答とするパケットを生成し送信する。そのようにして送信されたパケットは、ルータ21、及び通信ネットワーク1を介して端末装置10に受信される。以降、端末装置10はシステム管理者が使用する端末装置60と区別するために、「ユーザ端末」と表記する。
【0021】
図6は、サービスシステム20のレスポンス時間を説明する図である。
ユーザ端末10から送信されたパケットは、サービスシステム20のルータ21に受信されてWEBサーバ22に転送されて処理される。その結果、上記したように、APサーバ23による処理、DBサーバ24による処理、APサーバ23による処理、WEBサーバ22による処理がそれぞれ実行され、WEBサーバ22が生成したパケットがルータ21を介して通信ネットワーク1上に出力される。このことから、ユーザ端末10からのパケットを受信してから応答とするパケットを返信するまでに要する時間であるサービスシステム20全体のレスポンス時間は、それら各サーバ22〜24の処理の実行時間、サーバ間の通信に要した時間等を累算したものとなる。
【0022】
ルータ21には、このレスポンス時間を計時する計時プログラムが搭載されている。その計時プログラムは、例えばユーザ端末10から受信したパケット毎に、レスポンス時間を計時し、予め定めた単位時間毎に、計時したレスポンス時間の平均値を算出する。ネットワーク情報収集装置30は、例えばその単位時間間隔で、レスポンス時間の平均値をネットワーク情報31としてルータ21から収集する。
【0023】
図4は、ネットワーク情報収集装置30が収集したネットワーク情報31のデータ構成を説明する図である。図4に示すように、ネットワーク情報収集装置30は、レスポンス時間の平均値を、その平均値が収集された日時を示す日時情報を共に1レコード(エントリ)に格納する形でネットワーク情報31を保存する。その日時情報は、ルータ21が付しても良いが、ネットワーク情報収集装置30が付すようにしても良い。
【0024】
このようなレスポンス時間(の平均値)の収集は、周知技術を用いて行われる。以降、特に断らない限り、レスポンス時間とは、収集されたレスポンス時間の平均値を指す意味で用いる。
【0025】
各サーバ22〜24は、例えば性能情報収集用の収集プログラムを実行することにより、予め定めた設定に従い、自サーバの動作状況を示す性能情報(負荷情報)41を生成する。その性能情報41として生成する情報には、自サーバが入力(受信)したデータ量を示すトラフィック量、CPU負荷(使用率)、及び日時が含まれる。本実施形態では、そのトラフィック量を示す情報として、入力パケット数を採用している。入力パケット数は、設定された単位時間に入力したパケットの総数であり、CPU負荷は、その単位時間の平均のCPU負荷である。そのような性能情報41は、例えばその単位時間間隔でサーバ情報収集装置40により収集される。
【0026】
図3は、サーバ情報収集装置40が収集した性能情報41のデータ構成を説明する図である。図3に示すように、サーバ情報収集装置40は、日時、入力パケット数、及びCPU負荷を含む性能情報41を、その性能情報41を収集したサーバを示す識別子であるサーバ名を追加して1レコード(エントリ)に格納する形で保存する。このような性能情報41の収集も周知技術を用いて行われる。
【0027】
異常検出装置50は、例えばサーバ情報収集装置40と同様に、上記単位時間間隔でそのサーバ情報収集装置40から新たに収集された性能情報41を取得する。トラフィック量(入力パケット数)とCPU負荷の相関分析は、例えば予め定めた時間間隔でサーバ毎に行う。その相関分析により、例えば入力パケット数とCPU負荷の相関関係を示す回帰直線をトレンド(傾向)として作成し、そのトレンドから、入力パケット数とCPU負荷の組み合わせのなかで正常と見なす正常範囲を作成(設定)する。作成した正常範囲は、サーバ情報収集装置40から随時、取得する性能情報41が示す入力パケット数とCPU負荷の組み合わせと比較することにより、その正常範囲を用いた異常判定を行う。
【0028】
図7は、正常範囲を用いて行われる異常判定を説明する図である。この図7では、横(X)に入力パケット数、縦(Y)軸にCPU負荷を取り、1サーバのトレンド71と正常範囲72をXY平面上で表している(これは、図8、図11及び図13でも同様である)。正常範囲72は、四角形で表している。この正常範囲72の上限、及び下限は、入力パケット数が大きくなるほど、トレンド71との差の絶対値が大きくなるように作成されている。下限を作成するのは、サーバが実行すべき処理を実行できない等の理由により、CPU負荷が大きく低下するケースがあるからである。
【0029】
図7中の黒丸は、トレンド(回帰直線)71の作成に用いられた入力パケット数とCPU負荷の組み合わせ、つまり実際に性能情報41の形で観測された観測データを示している。それにより図7は、正常範囲72の外に位置する観測データが得られた場合に、異常と判定することを示している。
【0030】
異常検出装置50は、作成したトレンド71及び正常範囲72はトレンド/正常範囲データ51として管理する。図5は、そのデータ51の構成を説明する図である。図5に示すように、そのデータ51は、対応するサーバを示すサーバ名、トレンド71を作成した日時(トレンド作成日時)、このデータ51を有効とする日時を示す開始データ、このデータ51を無効とする日時を示す最終データ、トレンド71を示す回帰直線データ、正常範囲72の上限を示す正常範囲上限データ、及び正常範囲72の下限を示す正常範囲下限データを含む構成となっている。
【0031】
回帰直線データは、相関係数、傾き、及びY切片を含む構成である。正常範囲上限データ、及び正常範囲下限データは傾き、及びY切片を含む構成である。
異常検出装置50は、最終データが示す日時の経過により、次のトレンド71、及び正常範囲72を作成する。システム管理者が例えばサービスを追加する等の変更は、トレンド71、及び正常範囲72の作成とは別に行われるのが普通である。また、適切な正常範囲72の作成には、或る程度の性能情報41が必要である。このようなことから、システム管理者がサービスを追加する等の変更を行った直後には、その変更に合った適切な正常範囲72は作成されていないのが普通である。
【0032】
図1に示すような構成のサービスシステム20では、サービスの追加に伴い、APサーバ23、及びDBサーバ24のうちの少なくとも一方は、入力パケット数に対するCPU負荷が増大するのが普通である。このため、図8に示すように、観測データ、つまり性能情報41として得られた入力パケット数とCPU負荷の組み合わせが示す黒丸の位置は、異常が発生していないとしても、正常範囲72の外となる可能性がある。しかし、観測データと正常範囲72との比較を行ったのみでは、実際に異常が発生しているか否かを必ずしも適切に判定することはできない。システム管理者によるトレンド71を変化させる変更により、本来は異常ではないものが異常と判定された可能性がある。このようなことから本実施形態では、観測データが正常範囲72の外となった場合に、以下のように対応している。図9〜図11に示す各説明図を参照して具体的に説明する。
【0033】
図9は、サービスを追加した場合のレスポンス時間の変化の例を説明する図である。この図9では、横(X)軸に時間、縦(Y)軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。サービスを追加した時点は、図9中、横軸を指す矢印により示している。
【0034】
図9に示すように、異常が発生していない状況でサービスを追加したとしても、レスポンス時間は大幅に変化しないのが普通である。これには、サービスの追加の前後で入力パケット数が大きく変化することは少ない、CPU負荷が大きく変化するようなサービスの追加を行うケースは稀である、といった実情がある。
【0035】
レスポンス時間が大きく変化しなければ、ユーザは、利用しているサービスの質が低下したと感じる可能性は低い。このことから、たとえ観測データが正常範囲72の外となったとしても、システム管理者が早急に対応しなければならない必要性は低いと云える。それにより、システム管理者に異常を直ちに通知しない。
【0036】
図10は、異常が発生した場合のレスポンス時間の変化の例を説明する図である。この図10でも同様に、横(X)軸に時間、縦(Y)軸にレスポンス時間を取り、レスポンス時間の時間変化の例を示している。異常が発生した時点は、図10中、横軸を指す矢印により示している。図10に示すようなレスポンス時間の変化は、例えばプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放するガベージコレクションが短時間に頻発する異常によって生じる。
【0037】
図10に示すように、異常が発生すると、レスポンス時間は非常に長くなるのが普通である。非常に長いレスポンス時間は、ユーザにサービスの質の低下を感じさせる可能性が高い。このことから本実施形態では、直ちに通知すべき異常を判定するための閾値(レスポンス異常判定閾値)を設定し、レスポンス時間がこの閾値を越えたときには、システム管理者に異常を直ちに通知する。その通知は、例えば異常の発生を伝えるためのメッセージ、或いはメールをシステム管理者が使用する端末装置60に送信することで行われる。
【0038】
このようにして本実施形態では、観測データが正常範囲72の外となった場合、レスポンス時間を参照し、直ちに通知すべき異常か否か判定するようにしている。それにより、直ちに通知すべき異常と判定すれば、異常を直ちにシステム管理者に通知し、直ちに通知すべき異常ではないと判定すれば、深刻な異常の可能性は低く、且つサービスを利用するユーザへの影響も小さいと見なし、異常の通知を控える。このため、深刻と考えられる異常の通知が遅くなるのは確実に回避される。それにより、サービスを快適に利用できない人、その時間は共に最小限に抑えることができるようになる。異常検出装置50がネットワーク情報収集装置30を介してネットワーク情報(レスポンス時間)を取得するのは、このような異常判定を行うためである。
【0039】
なお、本実施形態では、レスポンス異常判定閾値を判定基準として設定して、直ちに通知すべき異常を判定(検出)するようにしているが、レスポンス時間の変動量を判定基準として採用しても良い。その変動量の閾値は、レスポンス異常判定閾値のように固定の時間値としても良いが、例えば単位時間当たりのレスポンス時間の差分を、その差分の算出に用いた二つのレスポンス時間の一方で割ることにより得られるような比であっても良い。入力パケット数の変動を考慮して、そのような計算により得られる変動量(比)に、二つのレスポンス時間が得られた際の各WEBサーバ22の入力パケット数の累算値の比を乗算したものとしても良い。レスポンス異常判定閾値と変動量を共に用いるようにしても良い。その場合、例えば変動量(比)が閾値以下であっても、レスポンス時間がレスポンス異常判定閾値を越えていれば異常と判定するような方法を採用すれば良い。
【0040】
直ちに通知すべき異常ではないと判定した場合、本実施形態では、サービスの追加等のトレンド71を変化させる変更をシステム管理者が行った可能性があると見なして対応する。その対応は、図11に示すように、新たなトレンド71a、及び正常範囲72aを暫定的に作成し、新たに得られた観測データが正常範囲72aの外となるか否か確認することで行うようにしている。それにより、観測データが正常範囲72aの外になることが確認できた場合、異常が発生しているとして、システム管理者に異常を通知する。観測データが正常範囲72a内になることが確認できた場合には、異常は発生していないとして、システム管理者に異常を通知しない。
【0041】
このようにして本実施形態では、直ちに通知すべき深刻な異常は直ちに通知し、それ以外の異常は再度、新たに作成した正常範囲72aを用いた異常判定により、必要に応じて通知する。それにより、システム管理者にとっては、対応すべき異常にのみ対応すれば済むようになって、無駄な作業を行わなくとも済むようになる。これは、システム管理者の負荷を抑えられることを意味する。また、直ちに対応すべき深刻な異常には迅速に対応できることから、サービスの質の低下も最小限に抑えられることとなる。
【0042】
図2は、異常検出装置50の機能構成を説明する図である。この異常検出装置50は、図2に示すように、トレンド/正常範囲データ51を含む各種データを格納する記憶部52と、サーバ情報収集装置40から性能情報41を取得する性能情報取得部53と、ネットワーク情報収集装置30からネットワーク情報(レスポンス時間)31を取得するレスポンス時間取得部54と、性能情報取得部53が取得した性能情報41を用いた相関分析により、トレンド71及び正常範囲72を示すトレンド/正常範囲データ51を作成するトレンド解析部55と、性能情報取得部53が取得した性能情報41、及びレスポンス時間取得部54が取得したネットワーク情報31を用いて異常を判定する異常判定部56と、異常判定部56が異常と判定した場合に、その異常をシステム管理者に通知するアラーム処理部57と、を備えた構成となっている。これら各部53〜57の動作により、上記したような異常判定が実現される。
【0043】
図2に示す機能構成は、異常検出装置50として用いられるコンピュータに、本実施形態による異常検出プログラムを実行させることで実現される。ここで図16を参照して、本発明を適用可能なコンピュータ、つまりこの異常検出プログラムを実行することで異常検出装置50として使用可能なコンピュータについて具体的に説明する。
【0044】
図16に示すコンピュータは、CPU81、メモリ82、入力装置83、出力装置84、外部記憶装置85、媒体駆動装置86、及びネットワーク接続装置87を有し、これらがバス88によって互いに接続された構成となっている。図16に示す構成は一例であり、これに限定されるものではない。
【0045】
CPU81は、当該コンピュータ全体の制御を行う。
メモリ82は、プログラムの実行、データ更新等の際に、外部記憶装置85(あるいは可搬型の記録媒体90)に記憶されているプログラムあるいはデータを一時的に格納するRAM等の半導体メモリである。CPU81は、プログラムをメモリ82に読み出して実行することにより、全体の制御を行う。
【0046】
入力装置83は、例えば、キーボード、マウス等の操作装置と接続可能なインターフェースである。接続された操作装置に対するユーザの操作を検出し、その検出結果をCPU81に通知する。
【0047】
出力装置84は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置87は、例えばネットワーク情報収集装置30及びサーバ情報収集装置40と通信ネットワークを介した通信を可能とさせるものである。外部記憶装置85は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
【0048】
媒体駆動装置86は、光ディスクや光磁気ディスク等の可搬型の記録媒体90にアクセスするものである。
上記異常検出プログラムは、外部記憶装置85、若しくは記録媒体90に記録されているか、或いは通信ネットワークを介してネットワーク接続87により取得される。その異常検出プログラムをメモリ82に読み出してCPU81が実行することにより、異常検出装置50は実現される。
【0049】
図16に示す構成では、図2の記憶部52は例えば外部記憶装置85、或いは記録媒体90が装着された媒体駆動装置86である。異常検出プログラム、及びトレンド/正常範囲データ51を含む各種データが外部記憶装置85にそれぞれ格納されていると想定する場合、性能情報取得部53、レスポンス時間取得部54及びアラーム処理部57は共に、例えばCPU81、メモリ82、外部記憶装置85、ネットワーク接続装置87、及びバス88によって実現される。トレンド解析部55及び異常判定部56は共に、例えばCPU81、メモリ82、外部記憶装置85、及びバス88によって実現される。
【0050】
図12は、異常検出処理のフローチャートである。この検出処理は、上記異常検出プログラムを異常検出装置50が実行することにより実現される処理である。この検出処理を実行することにより、上記のような異常判定を異常検出装置50は行うこととなる。次に図12を参照して、この検出処理について詳細に説明する。
【0051】
先ず、ステップS11では、サーバ情報収集装置40から性能情報41、ネットワーク情報収集装置30からネットワーク情報31をそれぞれ取得する。次のステップS12では、現在日時は最終データが示す日時より後(図12中「トレンド解析時刻」と表記)か否か判定する。現在日時が最終データの示す日時より後であった場合、判定はYESとなり、ステップS14で新しいトレンド71及び正常範囲72を作成してから、ステップS15に移行する。現在日時がトレンド解析時刻より前であった場合には、判定はNOとなってステップS13に移行する。
【0052】
上述したように、取得した性能情報41が示す入力パケット数とCPU負荷の組み合わせが正常範囲72の外であった場合、トレンド71及び正常範囲72の再作成を行う。その再作成は、例えば変数である短期トレンド取得フラグをオン(on)にし、その再作成を行うべき日時を示す最終データを設定して行われる。入力パケット数とCPU負荷の組み合わせが正常範囲72の外にならなかった場合には、有効としているトレンド/正常範囲データ51の最終データが示す日時が経過することにより、ステップS12の判定はYESとなる。このようなことから、最終データが示す日時は、更新されている場合がある。それにより、図12では最終データが示す日時を「トレンド解析時刻」と表記している。短期トレンド取得フラグがオンとなっている状況でステップS14に移行した場合、トレンド/正常範囲データ51の作成と共に、短期トレンド取得フラグのオフが行われる。短期トレンド取得フラグがオンされていることにより再作成したトレンド71は以降「短期トレンド71a」と呼ぶことにする。短期トレンド71aから設定される正常範囲72は以降「短期正常範囲72a」と呼ぶことにする。
【0053】
ステップS13では、短期トレンド取得フラグがオンか否か判定する。そのフラグがオン、例えばそのフラグの値が1であった場合、判定はYESとなってステップS19に移行する。そのフラグがオフ、例えばそのフラグの値が0であった場合には、判定はNOとなってステップS15に移行する。
【0054】
ステップS15では、取得した性能情報41毎に、その性能情報41が示す入力パケット数とCPU負荷の組み合わせを対応のトレンド/正常範囲データ51が示す正常範囲72と比較して、その組み合わせが正常範囲72外か否か判定する。その組み合わせのなかに正常範囲72外のものがあった場合、判定はYESとなってステップS16に移行する。その組み合わせの何れも正常範囲72内であった場合には、判定はNOとなり、上記ステップS11に戻る。
【0055】
ステップS16では、短期トレンドを作成(取得)した直後か否か判定する。直前のステップS15において、入力パケット数とCPU負荷の組み合わせが新しい短期正常範囲72a外と確認された場合、判定はYESとなってステップS17に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。その組み合わせが外となったのが短期正常範囲72aでなかった場合には、判定はNOとなってステップS18に移行する。
【0056】
ステップS18では、短期トレンド71等を作成すべき日時(トレンド解析時刻)を設定し、その日時に最終データを更新し、短期トレンド取得フラグをオンにする。続くステップS19では、レスポンス時間に大きな変動があるか否か判定する。ステップS11で取得したネットワーク情報31が示すレスポンス時間がレスポンス異常判定閾値を越えていた場合、判定はYESとなってステップS20に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。そのレスポンス時間がレスポンス異常判定閾値を越えていない場合には、判定はNOとなり、上記ステップS11に戻る。
【0057】
この異常検出処理を実行することにより、図2の各部53−57が実現される。ステップS15、或いはステップS19のNOの判定によりステップS11に戻っても、直ちにステップS11は実行しない。ステップS11は、予め定めたタイミングの到来を待って実行する。それにより、異常検出処理は実際には例えば予め定めた時間間隔で実行される。
【0058】
なお、本実施形態では、正常範囲72を用いた異常判定により異常が判定された場合、レスポンス時間の閾値(レスポンス異常判定閾値)を判定基準とした異常判定を行うようになっているが、それ以外の判定基準を採用しても良い。入力パケット数とCPU負荷の組み合わせのなかで、直ちに通知すべき異常と見なす範囲をその判定基準として採用しても良い。以降は、そのような判定基準を採用した場合の変形例について、図13〜図15に示す各説明図を参照して具体的に説明する。
【0059】
図13は、入力パケット数とCPU負荷の組み合わせから、直ちに通知すべき異常と見なす範囲の設定例を説明する図である。この図13は、その範囲を、即時異常通知用閾値73として設定した場合の例を示している。トレンド71の上下に即時異常通知用閾値73を設定しているのは、入力パケット数に対し、CPU負荷の極端な増大、及び低下を共に異常として検出するためである。
【0060】
このような即時異常通知用閾値73を判定基準として採用しても、レスポンス時間の極端な増大や、CPU負荷の極端な低下を深刻な異常と見なし、システム管理者に直ちに通知することができる。このため、上記実施形態と同様の効果を得ることができる。
【0061】
図14は、このような即時異常通知用閾値73を設定する場合のトレンド/正常範囲データ51のデータ構成を説明する図である。図14に示すように、二つの即時異常通知用閾値73は、即時異常通知閾値上限データ、及び即時異常通知閾値下限データとして管理される。それらのデータは、傾き、及びY切片を含む構成である。
【0062】
図15は、このような即時異常通知用閾値73を設定した場合の異常検出処理のフローチャートである。この図15では、図12と基本的に同じ内容の処理ステップには同一の符号を付している。それにより、図12から異なる部分にのみ着目して、その説明を行う。
【0063】
この図15では、ステップS15のYESの判定によりステップS31に移行する。そのステップS31では、ステップS15において、正常範囲72外と確認された入力パケット数とCPU負荷の組み合わせ毎に、その組み合わせが2つの即時異常通知用閾値の何れかを越えているか否か判定する。その組み合わせのなかに2つの即時異常通知用閾値73の範囲外となるものがあった場合、判定はYESとなってステップS32に移行し、異常の発生をシステム管理者に通知(緊急アラーム)する。その後は所定の処理を実行する。その組み合わせの何れも2つの即時異常通知用閾値73の範囲内であった場合には、判定はNOとなってステップS16に移行する。ステップS16以降は図12と同じであるため、説明は省略する。
【符号の説明】
【0064】
1 通信ネットワーク
10、60 端末装置
20 サービスシステム
21 ルータ
22 WEBサーバ
23 アプリケーション(AP)サーバ
24 データベース(DB)サーバ
30 ネットワーク情報収集装置
31 ネットワーク情報
40 サーバ情報収集装置
41 性能情報
50 異常検出装置
51 トレンド/正常範囲データ
52 記憶部
53 性能情報取得部
54 レスポンス時間取得部
55 トレンド解析部
56 異常判定部
57 アラーム処理部
【特許請求の範囲】
【請求項1】
コンピュータの負荷情報を取得する性能情報取得部と、
前記コンピュータの応答時間を取得する応答時間取得部と、
前記負荷情報を基に前記コンピュータの異常動作を判定する第1の異常判定部と、
前記第1の異常判定部が前記コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記コンピュータの異常動作を判定する第2の異常判定部と、
前記第2の異常判定部が前記コンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、
を具備することを特徴とする異常検出装置。
【請求項2】
前記性能情報取得部は、前記コンピュータのトラフィック量を取得し、
前記トラフィック量と前記負荷情報の傾向を基に、前記第1の異常判定部の判定基準を決定する傾向解析部をさらに備えることを特徴とする請求1記載の異常検出装置。
【請求項3】
前記第1の異常判定部が前記負荷情報に著しい変化があると判断した場合には、前記第1の異常通知部が異常を通知することを特徴とする請求項1記載の異常検出装置。
【請求項4】
コンピュータに、
検査対象コンピュータの負荷情報を取得する性能情報手段と、
前記検査対象コンピュータの応答時間を取得する応答時間取得手段と、
前記負荷情報を基に前記検査対象コンピュータの異常動作を判定する第1の異常判定手段と、
前記第1の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定する第2の異常判定手段と、
前記第2の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知手段として機能させるためのプログラム。
【請求項5】
前記性能情報取得手段は、前記検査対象コンピュータのトラフィック量を取得し、
前記トラフィック量と前記負荷情報の傾向を基に、前記第1の異常判定手段の判定基準を決定する傾向解析手段をさらに備えることを特徴とする請求4記載のプログラム。
【請求項6】
前記第1の異常判定手段が前記負荷情報に著しい変化があると判断した場合には、前記第1の異常通知手段が異常を通知することを特徴とする請求項4記載のプログラム。
【請求項7】
コンピュータが、
検査対象コンピュータの負荷情報を取得し、
前記検査対象コンピュータの応答時間を取得し、
前記負荷情報を基に前記検査対象コンピュータの異常動作を判定し、
前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定し、
前記応答時間に基づいた判定の結果、前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知を行う異常検出方法。
【請求項1】
コンピュータの負荷情報を取得する性能情報取得部と、
前記コンピュータの応答時間を取得する応答時間取得部と、
前記負荷情報を基に前記コンピュータの異常動作を判定する第1の異常判定部と、
前記第1の異常判定部が前記コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記コンピュータの異常動作を判定する第2の異常判定部と、
前記第2の異常判定部が前記コンピュータが異常動作していると判定した場合に、異常を通知する異常通知部と、
を具備することを特徴とする異常検出装置。
【請求項2】
前記性能情報取得部は、前記コンピュータのトラフィック量を取得し、
前記トラフィック量と前記負荷情報の傾向を基に、前記第1の異常判定部の判定基準を決定する傾向解析部をさらに備えることを特徴とする請求1記載の異常検出装置。
【請求項3】
前記第1の異常判定部が前記負荷情報に著しい変化があると判断した場合には、前記第1の異常通知部が異常を通知することを特徴とする請求項1記載の異常検出装置。
【請求項4】
コンピュータに、
検査対象コンピュータの負荷情報を取得する性能情報手段と、
前記検査対象コンピュータの応答時間を取得する応答時間取得手段と、
前記負荷情報を基に前記検査対象コンピュータの異常動作を判定する第1の異常判定手段と、
前記第1の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定する第2の異常判定手段と、
前記第2の異常判定手段が前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知手段として機能させるためのプログラム。
【請求項5】
前記性能情報取得手段は、前記検査対象コンピュータのトラフィック量を取得し、
前記トラフィック量と前記負荷情報の傾向を基に、前記第1の異常判定手段の判定基準を決定する傾向解析手段をさらに備えることを特徴とする請求4記載のプログラム。
【請求項6】
前記第1の異常判定手段が前記負荷情報に著しい変化があると判断した場合には、前記第1の異常通知手段が異常を通知することを特徴とする請求項4記載のプログラム。
【請求項7】
コンピュータが、
検査対象コンピュータの負荷情報を取得し、
前記検査対象コンピュータの応答時間を取得し、
前記負荷情報を基に前記検査対象コンピュータの異常動作を判定し、
前記検査対象コンピュータが異常動作していると判定した場合に、前記応答時間に基づいて、前記検査対象コンピュータの異常動作を判定し、
前記応答時間に基づいた判定の結果、前記検査対象コンピュータが異常動作していると判定した場合に、異常を通知する異常通知を行う異常検出方法。
【図2】
【図3】
【図4】
【図5】
【図9】
【図12】
【図1】
【図6】
【図7】
【図8】
【図10】
【図11】
【図13】
【図14】
【図15】
【図16】
【図3】
【図4】
【図5】
【図9】
【図12】
【図1】
【図6】
【図7】
【図8】
【図10】
【図11】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2011−154483(P2011−154483A)
【公開日】平成23年8月11日(2011.8.11)
【国際特許分類】
【出願番号】特願2010−14720(P2010−14720)
【出願日】平成22年1月26日(2010.1.26)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成23年8月11日(2011.8.11)
【国際特許分類】
【出願日】平成22年1月26日(2010.1.26)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]