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

Description

本発明は、監視対象装置の過去と現在の稼働情報に基づき、異常検出を行う異常検出技術に関するものである。

近年、業務システムのWebアプリ化や、インターネットビジネスの普及などを受け、Webシステムが扱うビジネス規模が拡大している。そこで、Webシステムの高信頼化が必須となっている。しかし、Webシステムで起きる異常は多種多様であり、原因もソフトウェアのバグによるものやオペレータの操作ミスによるものなど多岐に渡るため、完全に防ぐことは難しい。よって、異常は起きるものとして、異常が起きた際にすぐ対策を行えるよう、様々な異常検出技術が開発されている。特にマルチベンダ化・ブラックボックス化が進んだ近年のWebシステムにおいては、異常に関するデータを得にくい場合があるため、比較的データを得やすい、過去の正常な稼働情報を基にモデルデータを作成し、現在の稼働情報がモデルデータと乖離しているか否かによって、異常検出を行う技術が提案されている。

なお、本発明における異常とは、ハードウェアの停止や誤動作、中央処理部(Central Processing Unit：ＣＰＵ)やネットワークの過負荷、メモリ領域の不足などにより、サービス水準合意（Service Level Agreement：ＳＬＡ)を満たさなくなる可能性のある状態をさす。また、本発明におけるモデルデータとは、過去の正常な稼働情報を平均するなどの方法によって求められた、典型的な正常な稼働情報をさす。

従来技術として、計算機システムの過去の負荷情報に基づいて、計算機システムの負荷の時間的な推移を捉えた負荷モデルデータを作成し、現在と対応する時刻の負荷モデルデータを用いて閾値を決め、現在の負荷がその閾値を超えたか否かによって異常検出を図る技術（例えば特許文献１）や、計算機システムの過去の稼働データから周期的な変化パターンを求め、現在の稼働データの変化パターンが、求めた過去のどの変化パターンともマッチングしない場合を異常と判断することで、異常検出を図る技術(例えば特許文献２)などがある。

特開２００１-１４２７４６号公報 特開２００８-１９１８３９号公報

特許文献１に記載の従来技術では、現在と対応する時刻のモデルデータを判定に用いる為、その時刻に普段起きない、正常なイベントに起因した負荷の変動が発生している際に誤検出をしてしまう恐れがある。また、特許文献２に記載の従来技術では、過去の周期性に現在も従っているかによって判定を行うため、その周期で普段起きない、正常なイベントに起因した稼働データの変動が発生している際に誤検出が起きてしまう恐れがある。対策として、誤検出した変化パターンは、以降例外として検出しないようにするが、システムの構成や環境の変化などによって、例外とした変化パターンが異常に該当するようになった場合には、検出漏れが起きてしまうという恐れがある。

例えば、業務システムのサーバアクセス数を監視する場合、同じ平日の午前中でも、アップデートを行っている場合とそうでない場合、社内行事がある場合とそうでない場合では想定されるアクセス数が異なるため、それぞれの状況に適したモデルデータを用いて判定を行わなくてはならない。以上のように、時間や周期性のみに基づいてモデルデータを作成すると、判定に適したモデルデータを作成できない場合があるという課題があった。

特許文献１に記載の従来技術では、異常検出時に管理者へ異常負荷を検出した旨が通知される。特許文献２に記載の従来技術では、過去に起きたことがある異常の検出時には、その異常に関する情報を管理者へ通知するが、過去に起きたことがない異常の場合には、異常検出した旨のみが通知される。従って、特に課題１で述べたような誤検出時には、管理者は実際には異常が起きていないことを判断しなくてはならない。そのために、管理者は別途監視対象装置のログを開いてエラーメッセージを探したり、プログラムによってネットワークの死活を確認するなどの方法によって、システムが正常に稼働しているか詳細に解析する必要がある。正常であることの確認は異常であることの確認よりも難しく、確かに正常に稼働しているため、恐らく判定に用いたモデルデータが適切でなかったことによる誤検出であろうと判断するころには、多大な時間がかかってしまっている。以上のように、異常検出した旨のみを通知すると、現在の判定に用いているモデルデータが適切であるか判断が出来ず、判定結果の妥当性判断に時間がかかるという課題があった。

そこで本発明では、より現在の状態を表すのに適したモデルデータを作成して判定を行うことで、再現率や適合率といった異常検出精度を向上させること、更には、判定の根拠を管理者へ伝えることで、判定結果の妥当性判断にかかる時間を短縮させることが可能な異常検出方法、装置、及びプログラムを提供することを目的とする。

上記の目的を達成するため、本発明においては、処理部と記憶部を備えた装置を用い、監視対象システムの異常検出を行う異常検出方法であって、処理部は、監視対象システムからアクセスログとプロセス稼働ログを取得する手順と、取得したアクセスログを時間毎に分類し、時間毎の稼働情報として記録する手順と、取得したプロセス稼働ログから、記録した稼働情報のプロセス状態を分析する手順と、分析して抽出したプロセス状態から作業名を求める作業名付与手順と、求めた作業名を稼働情報に関連付けし、稼働状況として記録する手順を実行することを特徴とする異常検出方法を提供する。

また、上記の目的を達成するため、処理部と記憶部とを備え、監視対象システムの異常検出を行う異常検出装置であって、処理部は、監視対象システムからアクセスログとプロセス稼働ログを取得するログ収集制御部と、取得した前記アクセスログを時間毎に分類し、時間毎の稼働状況として記録する稼働情報分析部と、
記録した稼働状況のプロセス状態をプロセス稼働ログから抽出し、抽出したプロセス状態から作業名を求め、稼働状況に関連付けて記録するプロセス状態分析・作業名付与部と、記録した稼働状況について現在の稼働状況と過去の稼働状況の乖離度を算出して異常判定する異常判定部とを備えることを特徴とする異常検出装置、更にはその処理部用の異常検出プログラムを提供する。

本発明の好適な実施態様においては、上記の目的を達成するため、時間による周期性の他に、プロセスの状態に基づいて、稼働情報を分類することで、より現在の状態を表すのに適したモデルデータを作成することを可能とする。具体的には、監視対象の計算機システムから一定時間間隔で収集した、アクセスログにより求まるアクセス頻度などの稼働情報を、まず曜日および時間帯などの時間軸によって分類する。これにより、判定したい稼働情報の、曜日や時間帯による周期性を考慮したモデルの作成を行うことが出来る。次に、曜日および時間帯などの時間軸によって分類した稼働情報を、さらにプロセス状態によって分類する。

なお、本明細書において、プロセス状態とは、どの様な組合せのプロセスが、どのようなリソースの使用状況で、どのタイミングで動いていたかなどの、プロセスの稼働に関する情報を意味する。このプロセス状態を用いることにより、判定したい稼働情報の曜日や時間帯などの時間軸による周期性を考慮した上で、さらにプロセスの稼働状態も考慮したモデルの作成を行うことができる。また、このようにして曜日および時間帯などの周期性を考慮した時間毎の分類とプロセス状態による分類を行った稼働情報を、本明細書では稼働状況と呼ぶこととする。

本明細書における異常検出は、過去の稼働状況から、曜日、時間帯などの時間毎、及びプロセス状態の条件が共通のエントリを抽出して、稼働情報の値をエントリ全体で平均することで求まるモデルデータと、現在の稼働情報の値との統計的乖離度を算出して、ある水準以上に乖離がある場合に異常と判定する方法で行う。エントリを抽出する際のルールは、監視対象の計算機システムが現在稼働している環境である、曜日や時間などの条件に応じて何を抽出するかルールを作成しておき、これに従う。

このように、曜日、時間帯、プロセス状態で分類した稼働情報から、モデルデータを作成して異常検出を行うことで、課題１の判定に適したモデルデータを作成できない場合があるという課題を解決する。

さらに、本発明の好適な態様においては、判定に用いたデータを全て可視化することで、異常判定の根拠を管理者に示す。また、判定に用いるモデルデータとして、より適切な可能性があるモデルデータもレコメンドすることで、現在の判定に用いているモデルデータが適切でない可能性を示唆する。さらに、現在の判定に用いているモデルデータが適切でなく、レコメンドしたモデルデータの方が現在の判定に適している場合には、エントリの抽出条件にモデルデータの条件を追記可能とし、次回の判定から使用することを可能とする。

具体的には、管理者へ示すモニタリング画面には、モデルデータのグラフ、現在の稼働状況のグラフ、モデルデータと現在の稼働状況の乖離度を示す。

この際、モデルデータのグラフおよび現在の稼働状況のグラフには、プロセス状態と、作業名を付与しておく。作業名とは、プロセス状態から推測される、グラフの傾向が出る要因となった作業の名前で、監視対象の計算機システムの稼働状態を総称したものである。作業名の付与は管理者の可読性を向上させるためのものであるため、プロセス名から求まるアプリケーション名としてもよいし、システム管理ツールなどによって関連づけられた、管理者が管理のために用いる名前を用いてもよい。

さらに、過去の稼働状況から、現在の稼働状況とプロセス状態が類似したエントリを抽出し、稼働情報の値を平均することで、現在と類似した稼働状況のモデルデータを作成する。前記類似した稼働状況のモデルデータは、現在の判定に用いるのにより適切な可能性があるモデルデータとしてレコメンドする。レコメンドしたモデルデータを管理者が選択すると、モニタリング画面にはレコメンドしたモデルデータと現在の稼働情報から算出される乖離度が表示されるようにしておく。レコメンドしたモデルデータの方が現在の判定に適している場合には、エントリを抽出する際のルールにレコメンドしたモデルデータを作成するためのルールを追記可能とし、次回の判定の際に表示する。異常判定はルールに記述してあり同時に作成されたモデルデータ全てが乖離している場合に下してもよいし、いずれかが乖離している場合に下してもよい。

このように、どの様なグラフを想定して、現在のグラフがどの程度乖離しているから異常と判定しているのか、想定している状態と現在の状態は似ているのか、などを可視化することで、課題２の現在の判定に用いているモデルデータが適切であるか判断が出来ず、判定結果の妥当性判断に時間がかかるという課題を解決する。

本発明によれば、従来誤検出が起きる恐れがあった、時間や周期性に従わないイベントが起きている場合のうち、プロセスに特徴が現れるイベントを考慮した判定を行うことが可能となり、再現率や適合率といった異常検出精度が向上する。また、従来管理者が判断を行うのに時間がかかっていた、誤検出が起きた場合にも、判定の根拠を詳細に知ることが可能となり、判定結果の妥当性判断にかかる時間を短縮させる。

第一の実施例の計算機システムの構成の一例を示すブロック図である。 第一の実施例の異常検出装置の構成機能の一例を示すブロック図である。 第一の実施例の分析対象データとなるアクセスログの構成の一例を表した図である。 第一の実施例の分析対象データとなるプロセス稼働ログの構成の一例を表した図である。 第一の実施例の分析結果の総アクセス数テーブルの構成の一例を表した図である。 第一の実施例の分析結果のＵＲＬ別アクセス数テーブルの構成の一例を表した図である。 第一の実施例の分析結果のプロセス状態テーブルの構成の一例を表した図である。 第一の実施例の分析結果の作業名テーブルの構成の一例を表した図である。 第一の実施例の異常検出装置のログ収集制御部の処理の一例を表すフローチャートを示す図である。 第一の実施例の異常検出装置の稼働情報分析部の処理の一例を表すフローチャートを示す図である。 第一の実施例の異常検出装置のプロセス状態分析部の処理の一例を表すフローチャートを示す図である。 第一の実施例の異常検出装置の作業名付与部の処理の一例を表すフローチャートを示す図である。 第一の実施例の異常判定に使用するテーブルとなるエントリ抽出ルールの構成の一例を表した図である。 第一の実施例の異常検出装置の異常判定部の処理の一例を表すフローチャートを示す図である。 第一の実施例の異常検出装置の類似稼働状況抽出部の処理の一例を示すフローチャートを示す図である。 第一の実施例の異常検出装置のモニタリング画面の構成の一例を示す図である。 第一の実施例の異常検出装置のモニタリング画面のダイアログの構成の一例を示す図である。 第二の実施例の異常検出装置の構成機能の一例を示すブロック図である。 第二の実施例の異常検出装置の選択反映部の処理の一例を表すフローチャートを示す図である。 第二の実施例の異常検出装置のユーザ選択結果反映画面の構成の一例を示す図である。 第二の実施例の異常検出装置のモニタリング画面の構成の一例を示す図である。

以下、本発明の実施形態について図１から図１４を順に参照して説明する。なお、以下の説明において、処理部が実行するプログラムの各要素を、「部」、「機能」、「手順」等と呼ぶ場合がある点に留意されたい。例えば、稼働情報分析プログラムを、「稼働情報分析部」、「稼働情報分析機能」、「稼働情報分析手順」等である。

第１の実施例は、アクセスログとプロセス稼働ログを用いて、モデルデータを作成し、Ｗｅｂサーバの異常検出を行い、異常判定結果とその根拠を画面に表示する構成の実施例である。

図１は、本実施例における計算機システムの全体構成を示すブロック図である。

本実施例では、Ｗｅｂサービスを提供するＷｅｂサーバ装置２０３、Ｗｅｂサーバ装置２０３が提供するサービスを利用する一つ以上のクライアントパーソナルコンピュータ(Personal Computer：ＰＣ)１００、Ｗｅｂサーバ装置２０３の異常検出を行う異常検出装置１２０、および前記計算機システムを相互に接続するネットワーク１３６を含む。

クライアントＰＣ１００は、それぞれが内部バスで接続された、処理部であるＣＰＵ(Central Processing Unit)１０２、記憶部であるメモリ１０１、インターフェイス（Ｉ／Ｆ）１０３、更にはディスプレイ１０４、入力装置１０５が接続されるコンピュータである。ＣＰＵ１０２は、メモリ１０１に記憶されるプログラムを実行する。メモリ１０１は、ＣＰＵ１０２によって実行されるプログラムや必要となるデータを一時的に記憶する。プログラムは具体的には、オペレーティングシステム（ＯＳ）やＷｅｂブラウザなどである。インターフェイス１０３は、ディスプレイ１０４、入力装置１０５やネットワーク１３６などの外部機器とのデータ入出力を行う。ディスプレイ１０４はＣＰＵ１０２によって計算された情報を表示する。入力装置１０５はキーボードやマウスなどクライアントＰＣ１００の利用者からの入力を受け付ける。本図には記載していないが、更に記憶部として外部記憶装置などを含んでも良い。

Ｗｅｂサーバ装置２０３は、クライアントＰＣ１００に情報を公開したり、業務システムを提供したりするためのサーバである。Ｗｅｂサーバ装置２０３は、クライアントＰＣ１００と同様に処理部であるＣＰＵ１１２、記憶部であるメモリ１１１、インターフェイス１１３、外部記憶装置１１４などから構成される。記憶部である外部記憶装置１１４には公開するＷｅｂページが格納されている。ＷｅｂページはＨＴＭＬ（Hyper Text Marｋup Language）言語など、クライアントＰＣ１００で動作するＷｅｂクライアントプログラムが解釈可能な言語で記述されている。また、Ｗｅｂページを特定するための識別子としてＵＲＬ（Uniform Resource Locator）が関連付けられている。Ｗｅｂサーバ装置２０３上で動作するＷｅｂサーバプログラムは、上述のＷｅｂクライアントプログラムからＵＲＬを含むＨＴＴＰ（Hyper Text Transfer Protocol）リクエストを受信する。

Ｗｅｂサーバプログラムは、ＵＲＬに関連付いているＷｅｂページを外部記憶装置１１４から取得し、ＷｅｂクライアントプログラムにＨＴＴＰレスポンスとして送信する。Ｗｅｂページの送受信は、ＨＴＴＰなどの通信プロトコルを用いて、ネットワーク１３６を介して実行される。Ｗｅｂサーバプログラムは、外部記憶装置１１４に格納された静的なＷｅｂページの提供以外に、Ｗｅｂアプリケーションサーバ、ＣＧＩ（Common Gateway Interface）システムやデータベースシステムなどを用いて動的にＷｅｂページを生成して提供する場合もある。

異常検出装置１２０は、本実施例の計算機システムの異常検出装置であり、クライアントＰＣ１００と同様に、ＣＰＵ１２２、メモリ１２１、インターフェイス１２３、外部記憶装置１２４、ディスプレイ１２５、入力装置１２６などから構成される。なお、上述の説明から明らかなように、異常検出装置１２０はクライアントＰＣ１００同様、通常のコンピュータ構成を有しており、その内部動作は上述したクライアントＰＣ１００と同様である。異常検出装置１２０で動作するプログラムの詳細については、図２から図１４を参照して説明する。

ネットワーク１３６は、上述の計算機システムを相互に接続する。ネットワーク１３６は、企業内のＬＡＮ（Local Area Networｋ）や、ＬＡＮ間を接続するＷＡＮ（Wide Area Networｋ）、ＩＳＰ（Internet Service Provider）が提供するネットワークである。

本実施例では、異常検出装置１２０は、Ｗｅｂサーバ装置２０３の異常監視を実施する。

図２は、図１に示した動作環境全体のうち本実施例の特徴に関する、異常検出装置１２０で動作するプログラムの構成機能要素を示すブロック図である。

Ｗｅｂサーバ装置２０３はＯＳ２０４と、ＯＳ２０４上で動作するプログラムであるＷｅｂサーバ１１０から構成され、これらのプログラムは、メモリ１１１等の記憶部に記憶され、上述したＣＰＵ１１２で実行されることによりその構成機能を実現する。Ｗｅｂサーバ１１０やＯＳ２０４はハードウェアやソフトウェアの実行状態や、実行した処理や発生したエラーなどのイベント履歴などをログとして生成する。このログは、外部記憶装置１１４あるいはネットワークに接続されたストレージ装置などに適宜書き込むことで記録される。本実施例では、Ｗｅｂサーバ１１０が生成するログのうち、ＷｅｂクライアントプログラムからＵＲＬを含むＨＴＴＰリクエストを受信したことを記録したアクセスログ２０１と、ＯＳ２０４が生成するログのうち、ＣＰＵ１１２が実行したプログラムのインスタンスであるプロセスの状態を記録したプロセス稼働ログ２０２を用いて異常の検出を行う。アクセスログとプロセス稼働ログの構成については後述する。

まず、図２を参照して、本実施例の異常検出の大まかな流れについて説明する。異常検出装置１２０は、Ｗｅｂサーバ装置２０３の外部記憶装置１１４に格納されているアクセスログ２０１とプロセス稼働ログ２０２をネットワーク１３６経由で取得し、分析することで、Ｗｅｂサーバ装置２０３の異常判定を行う。異常判定の結果は、Ｕ／Ｉ(User Interface)制御表示部２６０を通して、異常検出装置１２０の表示部であるディスプレイ１２５へ出力される。つまり、異常検出は（１）ログの取得、（２）ログの分析、（３）異常の判定、（４）判定結果の表示という４つの流れから成る。

より具体的には、（１）ログの取得はログ収集制御部２１０から構成される。ログ収集制御部２１０は、監視対象装置であるＷｅｂサーバ装置２０３のアクセスログ２０１とプロセス稼働ログ２０２を取得し、稼働情報分析部２２０、プロセス状態分析部２３０へ送信する。前述のアクセスログ２０１、プロセス稼働ログ２０２の収集は、ＦＴＰ（File Transport Protocol）などのファイル転送プロトコル、ＣＩＦＳ（Common Internet File System）、ＮＦＳ（Networｋ File System）などのファイル共有機能を利用して実現する。監視対象装置上で異常検出装置専用のファイル転送プログラムを常駐させて取得しても良い。また、ログ収集制御部２１０は稼働情報分析部２２０と作業名付与部２４０によって、外部記憶装置１２４の稼働状況管理テーブル２８０が更新された時点で、異常判定部２５０と類似稼働状況抽出部２７０の呼出を行う。

（２）ログの分析は、稼働情報分析部２２０、プロセス状態分析部２３０、作業名付与部２４０から構成される。なお、このプロセス状態分析部２３０と作業名付与部２４０とを纏めてプロセス状態分析・作業名付与部と呼ぶ場合がある。

稼働情報分析部２２０はアクセスログの情報を、アクセス数などの稼働情報に変換するための機能部である。稼働情報分析部２２０はログ収集制御部２１０からアクセスログ２０１を受信し、ＵＲＬ別のアクセス数などの稼働情報を抽出する。抽出した稼働情報は、異常判定に用いるため、外部記憶装置１２４の稼働状況管理テーブル２８０に記録する。稼働状況管理テーブル２８０については後述する。

プロセス状態分析部２３０はプロセス稼働ログの情報を、プロセス状態に変換するための機能部である。プロセス状態とは、どの様な組合せのプロセスが、どのようなリソースの使用状況で、どのタイミングで動いていたかなどの、プロセスの稼働に関する情報である。抽出したプロセス状態の情報は、異常判定に用いるため、外部記憶装置２１４の稼働状況管理テーブル２８０に記録する。

作業名付与部２４０は、後述するモニタリング画面において管理者の可読性を向上させるために作業名を付与するための機能部である。作業名とはプロセス状態から推測される、稼働情報の値の傾向が出る要因となった作業の名前で、Ｗｅｂサーバ装置２０３の稼働状態を総称したものである。作業名は、プロセス状態分析部２３０から受信した、プロセス状態を基に、プロセス名から求まるアプリケーション名としてもよいし、システム管理ツールなどによって関連づけられた、管理者が管理のために用いる名前を用いてもよい。

このように、本実施例ではアクセスログ２０１の他にプロセス稼働ログ２０２を用いて分析を行うことで、より精度の高いモデルデータの作成を狙うものである。

稼働状況管理テーブル２８０はアクセスログ２０１とプロセス稼働ログ２０２を分析した結果のテーブルであり、単位時間あたりの総アクセス数やＵＲＬ別アクセス数などの稼働情報、単位時間に動いていた特長的なプロセスの名前、プロセスが使用していたＣＰＵやメモリなどのリソース量、プロセスを基に名づけられる作業名などの情報を含む。稼働状況管理テーブル２８０の詳細な構成については後述する。

（３）異常の判定は異常判定部２５０と類似稼働状況抽出部２７０で行う。

異常判定部２５０は、ログ収集制御部２１０に呼び出され、外部記憶装置１２４に格納された稼働状況管理テーブル２８０と選択ルールであるエントリ抽出ルール２９０を基に異常の判定を行う。異常検出は、過去の稼働状況から曜日、時間帯、プロセス状態の条件が共通のエントリを抽出して、稼働情報の値をエントリ全体で平均することで求まるモデルデータと、現在の稼働状況との統計的乖離度を算出して、ある水準以上に乖離がある場合に異常と判定する方法で行う。エントリを抽出する際の条件は、エントリ抽出ルール２９０に従う。また、異常判定時には、モデルデータと現在の稼働状況から、プロセスの稼働状態がどの程度似ているかを表す類似度を算出する。乖離度および類似度の算出のアルゴリズムについては後述する。乖離度、類似度およびそれらの算出に用いたデータは、表示部であるディスプレイ１２５へ表示するために用いる。

類似稼働状況抽出部２７０は、ログ収集制御部２１０によって呼び出され、外部記憶装置１２４に格納された稼働状況管理テーブル２８０とエントリ抽出ルール２９０を基に、プロセスの稼働状態が現在の稼働状況と類似したモデルデータを用いて異常判定部２５０と同様の処理を行う。乖離度、類似度およびそれらの算出に用いたデータは、現在の判定に用いるのにより適切な可能性があるモデルデータとしてディスプレイ１２５へレコメンド表示するために用いる。

（４）判定結果の表示はＵ／Ｉ制御表示部２６０から構成される。

Ｕ／Ｉ制御表示部２６０は異常判定の結果と判定の根拠、レコメンドするモデルデータを表示し、管理者からの入力を受け付けるための機能部である。

Ｕ／Ｉ制御表示部２６０は、異常判定部２５０から受信した、乖離度、類似度およびそれらの算出に用いたデータを基に、モデルデータのグラフ、現在の稼働状況のグラフ、モデルデータと現在の稼働状況の乖離度を表示する。この際各々のグラフには、プロセス状態や作業名などの情報を付与しておく。モニタリング画面の詳細については後述する。

さらにＵ／Ｉ制御表示部２６０は類似稼働状況抽出部２７０から受信した乖離度、類似度およびそれらの算出に用いたデータを基に、レコメンドするモデルデータのグラフを表示する。この際、レコメンドするモデルデータのグラフには、プロセス状態や作業名などの情報を付与しておく。さらに、Ｕ／Ｉ制御表示部２６０は入出力装置１２６からの入力を受け付け、例えばレコメンドしたモデルデータを管理者が選択すると、モニタリング画面には対応した乖離度を表示する。

以下、本実施例の異常検出装置１２０の各機能部の詳細と各外部記憶装置に格納されているデータ構造の詳細について述べる。

図３はＷｅｂサーバ１１０が生成するアクセスログ２０１の構成の一例を表した図である。Ｗｅｂサーバ１１０は、クライアントＰＣ１００からアクセス先ＵＲＬを含むＨＴＴＰ要求を受け付けると、必要な処理を実施し、クライアントＰＣ１００に応答を送信すると共に、外部記憶装置１１４に、要求を処理した日付、時刻、要求されたＵＲＬなどをアクセスログとして記録する。

本実施例におけるアクセスログ２０１は日付３０１、時刻３０２、要求ＵＲＬ３０３を含む。アクセスログにその他の情報が含まれている場合は、フィルタリングを行って、日付３０１、時刻３０２、要求ＵＲＬの情報のみを取得する。アクセスログ２０１はＷｅｂサーバ１１０のアクセス状況を解析するために用いる。解析したアクセス状況は、Ｗｅｂサーバ１１０の異常検出を行うための乖離度を算出するために用いる。

図４はＯＳ２０４が生成するプロセス稼働ログ２０２の構成の一例を表した図である。ＯＳ２０４は、ＣＰＵ１０２がメモリ１０１に記憶されるプログラムを実行すると共に、外部記憶装置１１４に、プログラムを実行するためのインスタンスであるプロセスの名称、ＣＰＵ使用率などをプロセス稼働ログとして記録する。このプロセス稼働ログはバイナリ形式の場合もあれば、ＣＳＶ(Comma Separated Values)形式の場合もある。

本実施例におけるプロセス稼働ログ２０２は日付４０１、時刻４０２、プロセス名４０３、ＣＰＵ使用率４０４を含む。プロセス稼働ログは例えばプログラム言語のPerformanceCounterクラスによっても生成できる。プロセス稼働ログにその他の情報が含まれている場合は、フィルタリングを行って、日付４０１、時刻４０２、プロセス名４０３、ＣＰＵ使用率４０４の情報のみを取得する。ＣＰＵ使用率とは、単位時間中にプロセス名４０３が示すプロセスが、プログラムを実行するためにＣＰＵ１１２を占拠している時間の割合を表すものである。プロセス稼働ログ２０２はＷｅｂサーバ装置２０３のプロセス稼働状態を解析するために用いる。解析したプロセス稼働状態は、Ｗｅｂサーバ装置２０３の異常検出を行うための乖離度を算出する際のエントリの抽出や、モニタリング画面へ異常判定結果の詳細を示すために用いる。

図５Ａ、図５Ｂ、図５Ｃ、図５Ｄは外部記憶装置１２４に格納されている、稼働状況管理テーブル２８０の構成を表した図である。管理状況テーブルには大きく分けて、４つの情報が含まれる。単位時間あたりの総アクセス数、単位時間あたりのＵＲＬ別アクセス数、単位時間あたりのプロセス状態、作業名の４つがそれにあたり、各々は図５Ａ、図５Ｂ、図５Ｃ、図５Ｄの形式で記録される。

図５Ａは総アクセス数テーブル５００の構成を表す図である。総アクセス数テーブル５００は、単位時間あたりにＷｅｂサーバ１１０へクライアントＰＣ１００から何回リクエストがあったかを管理するためのテーブルである。総アクセス数は異常判定部２５０が乖離度の計算を行うために用いたり、Ｕ／Ｉ制御表示部２６０がモニタリング画面の表示を行うために用いる。総アクセス数テーブルはレコードを識別するための稼働ＩＤ５０１、日付５０２、時間５０３、総アクセス数５０４を含む。

図５ＢはＵＲＬ別アクセス数テーブル５１０の構成を表す図である。ＵＲＬ別アクセス数テーブル５１０は、単位時間あたりにＷｅｂサーバ１１０へクライアントＰＣ１００からどのＵＲＬへ何回リクエストがあったかＵＲＬ別アクセス数を管理するためのテーブルである。ＵＲＬ別アクセス数は異常判定部２５０が乖離度の計算を行うために用いる。ＵＲＬ別アクセス数テーブル５１０はレコードを識別するための稼働ＩＤ５１１、要求ＵＲＬ５１２、アクセス数５１３を含む。

図５Ｃはプロセス状態テーブル５２０の構成を表す図である。プロセス状態テーブル５２０は、単位間あたりに、どの様な組合せのプロセスが、どのようなリソースの使用状況で、どのタイミングで動いていたかなどの、プロセスの稼働に関する情報を管理するテーブルである。プロセス状態は異常判定部２５０がモデルデータの作成を行う際に、稼働状況管理テーブル２８０からエントリを抽出するための条件に用いたり、Ｕ／Ｉ制御表示部２６０がモニタリング画面の表示を行うために用いる。プロセス状態テーブル５２０はレコードを識別するための稼働ＩＤ５２１、単位時間に動いていた特徴プロセス名５２２、特徴プロセスの平均ＣＰＵ使用率５２３、プロセスプロパティ５２４を含む。本実施例におけるプロセスプロパティ５２４とは、単位時間内における、プロセスの起動タイミングや終了タイミングである。プロセスプロパティ５２４は、プロセスの親プロセス、プロセスの稼働時間、プロセスの使用している通信ポート、プロセスの占有している計算機リソース量など、プロセスの特徴を現す情報を用いる。このようにして、プロセスの組合せに加え、各プロセスのプロパティによって識別を行うことで、例えばシステムがCDRの書き込みを行う場合であれば、データ作成準備中なのか書き込み中なのかセッションクローズ中なのかなどの段階によって挙動が異なるが、これらを分けて考えることが出来る。

図５Ｄは作業名テーブル５３０の構成を表す図である。作業名テーブル５３０は、プロセス名と作業名の紐付けをするテーブルであり、後述するモニタリング画面において管理者の可読性を向上させるためのテーブルである。作業名とはプロセス状態から推測される、稼働情報の値の傾向が出る要因となった作業の名前で、Ｗｅｂサーバ装置２０３の稼働状態を総称したものである。作業名は、プロセス状態分析部２３０から受信した、プロセス状態を基に、プロセス名から求まるアプリケーション名としてもよいし、システム管理ツールなどによって関連づけられた、管理者が管理のために用いる名前を用いてもよい。作業名テーブル５３０は、プロセス名５３１、作業名５３２を含む。

図６はログ収集制御部２１０の処理を表すフローチャートである。

ログ収集制御部２１０は１時間間隔で駆動し、Ｗｅｂサーバの更新分のログを取得した後、異常検出装置の複数の機能部を呼び出す。この処理は、例えばＯＳのタイマー機能やプログラムのタイマー機能を用いることで、ループして行われる。駆動間隔を１時間とすることは、稼働状況が１時間ごとにまとまりのある状況であるとみなすことに相当する。本実施例においては１時間とするが、この間隔は３０分や２時間など任意の時間でよい。

最初にステップＳ６００では、外部記憶装置１１４からアクセスログ２０１を取得し、直近一時間分のファイルデータをスカラー変数accessLogへ格納する。以降スカラー変数とは、数値や文字列を格納するための変数の意として用いる。次にステップＳ６０１では、外部記憶装置１１４からプロセス稼働ログ２０２を取得し、直近一時間分のファイルデータをスカラー変数processLogへ格納する。前記アクセスログ２０１、プロセス稼働ログ２０２の収集は、ＦＴＰ（File Transport Protocol）などのファイル転送プロトコル、ＣＩＦＳ（Common Internet File System）、ＮＦＳ（Networｋ File System）などのファイル共有機能を利用して実現する。監視対象装置上で異常検出装置専用のファイル転送プログラムを常駐させて取得しても良い。取得するアクセスログ２０１とプロセス稼働ログの長さは、前回駆動した時刻からの更新分のみでよいため、直近一時間分のファイルデータを各スカラー変数へ格納する。この処理は、例えばプログラム言語のファイルポイント機能を利用することで実現できる。ファイルポイント機能とは、前回どこまでファイルを読み込んだかという位置を特定する機能である。次にステップＳ６０２では、accessLogを引数として稼働情報分析部２２０を呼出す。次にステップＳ６０３では、processLogを引数としてプロセス状態分析部２３０を呼出す。ステップＳ６０２、Ｓ６０３による機能部の呼び出しは、どちらが先に行われてもよい。次にステップＳ６０４では、異常判定部２５０を呼出す。次にステップS６０５では、類似稼働状況抽出部２７０を呼出す。ステップＳ６０４、Ｓ６０５による機能部の呼び出しは、どちらが先に行われてもよい。以上のステップによりログの取得処理が実現される。

図７は稼働情報分析部２２０の処理を表すフローチャートである。

稼働情報分析部２２０はアクセスログ２０１の情報を、総アクセス数やＵＲＬ別アクセス数などの稼働情報に変換するための機能部である。稼働情報分析部２２０はログ収集制御部２１０によって呼び出され、稼働状況管理テーブル２８０へ稼働情報を記録する。

最初にステップＳ７００では、ＵＲＬ文字列をキーとする連想配列urlCount_hを初期化する。次にステップＳ７０１では、accessLogから１レコード取得し、日付３０１、カラム、時刻３０２カラム、要求ＵＲＬ３０３カラムの値を、それぞれスカラー変数date、time、urlへ格納する。accessLogとは図６で述べた直近一時間分のアクセスログ２０１であり、構成はアクセスログ２０１と同様である。次にステップＳ７０２では、urlをキーとしたurlCount_hの値をカウントアップする。これにより、ＵＲＬ別のアクセス数を積算することができる。次にステップＳ７０３では、accessLogに次のレコードがあるかないかを判別する。次の行がある場合はステップＳ７０１に戻り、アクセス数の加算を続ける。次の行がない場合は、ステップＳ７０４に進む。次にステップＳ７０４では、timeをhh:mm:ssと表したときのhh値をst、hh値に１を加算した値をendとした時間”st-end”を生成し、スカラー変数timeSlotへ格納する。これにより、時間帯を求めることができる。次にステップＳ７０５では、urlCount_hの全要素の値を加算して総アクセス数を求めスカラー変数totalCount_hへ格納する。次にステップＳ７０６では、dateとtimeSlotを連結したユニークな値を生成しスカラー変数idへ格納する。この処理は例えばdateとtimeSlotを引数とする一次関数を用意して実現できる。次にステップＳ７０７では、稼働状況管理テーブル５００へ、稼働ＩＤ５０１＝id、日付５０２＝date、時間５０３=timeSlot、総アクセス数５０４＝totalCount_hのレコードを追加する。次にステップＳ７０８では、urlCount_hから１要素読み込み、キーＵＲＬをｋey、値をスカラー変数valueへ格納する。次にステップＳ７０９では、稼働状況管理テーブル５１０へ、稼働ＩＤ５１１＝id、要求ＵＲＬ５１２＝ｋey、アクセス数５１３＝valueのレコードを追加する。次にステップＳ７１０では、urlCount_hに次の要素があるか判別を行い、次の要素がある場合はステップＳ７０８に戻り、テーブルの追加を続ける。次の行がない場合は処理を終了する。以上のステップにより、アクセスログ２０１から、稼働情報を抽出する処理を実現できる。

図８はプロセス状態分析部２３０の処理を表すフローチャートである。

プロセス状態分析部２３０はプロセス稼働ログ２０２の情報を、プロセス状態の情報に変換するための機能部である。プロセス状態分析部２３０はログ収集制御部２１０によって呼び出され、稼働状況管理テーブル２８０へ稼働情報を記録する。プロセス状態とは、どの様な組合せのプロセスが、どのようなリソースの使用状況で、どのタイミングで動いていたかなどの、プロセスの稼働に関する情報である。

最初にステップＳ８００では、プロセス名文字列をキーとする連想配列totalCpuRatio_hとstartTime_hを初期化する。次にステップＳ８０１では、processLogから１レコード取得し、日時４０１カラム、時刻４０２カラム、プロセス名４０３カラム、ＣＰＵ使用率４０４カラムの値を、それぞれスカラー変数date、time、procName、cpuRatioへ格納する。processLogとは図６で述べた直近一時間分のプロセス稼働ログ２０２であり、構成はプロセス稼働ログ２０２と同様である。次にステップＳ８０２では、procNameをキーとしたtotalCpuRatio_hの値があるか判断する。値がある場合はステップＳ８０３に進み、ない場合はステップ８０４へ進む。ステップＳ８０３では、procNameをキーとするstartTime_hの値にtimeを格納し、その後ステップ８０４へ進む。これにより、各プロセスが最初に起動した時刻を記録しておくことができ、プロセスプロパティの生成ができる。プロセスプロパティとは、プロセスの特徴を示す情報であり、本実施例では、プロセスの起動時刻を用いる。プロセスプロパティは後述するモニタリング画面において管理者の可読性を向上させるための情報であるため、プロセスの親プロセス、プロセスの稼働時間、プロセスの使用している通信ポート、プロセスの占有している計算機リソース量など、プロセスの特徴を現す情報であればよい。

次にステップＳ８０４では、procNameをキーとしたtotalCpuRatio_hの値へcpuRatioを加算する。これにより、プロセス別にＣＰＵ利用率を積算することができる。次にステップＳ８０５では、processLogに次のレコードがあるか判断する。次のレコードがある場合はステップＳ８０１に戻り、ＣＰＵ使用率の積算を続ける。次のレコードがない場合はステップＳ８０６へ進む。次にステップＳ８０６では、totalCpuRatio_hの値が大きい上位３つのキーを抽出し配列procName_aへ格納する。これにより、単位時間内における特徴プロセスを抽出できる。積算したＣＰＵ使用率ではなく、平均ＣＰＵ使用率を用いて比較を行って実現してもよい。この処理は、稼働情報分析部２２０の値の傾向が出る要因となったと推測される作業に関連する、プロセスの抽出を図るものである。

次にステップＳ８０７では、procName_aの各要素をキーとしたtotalCpuRatio_hの値を単位時間で割り、プロセス別の平均ＣＰＵ使用率を求めて配列aveCpuRatio_aに格納する。この単位時間とは、ログ収集分析部２１０が駆動する間隔をプロセス稼働ログが生成される間隔の単位へ変換したもののことであり、本実施例においては３６００である。これにより、特徴プロセスごとの平均ＣＰＵ使用率を求めることができる。次にステップＳ８０８では、dateとtimeSlotを連結したユニークな値を生成しスカラー変数idへ格納する。この処理は、図７のステップＳ７０６の処理と同様である。次にステップＳ８０９では、procName_aの各要素について、稼働状況管理テーブル５２０へ稼働ＩＤ５２１＝id、特徴プロセス名５２２＝procName_a、平均ＣＰＵ使用率５２３＝aveCpuRatio_a、プロセスプロパティ５２４＝startTime_h＋“起動”のレコードを追加する。

次にステップＳ８１０では、procName_aを引数として作業名付与部を呼出す。

以上のステップにより、プロセス稼働ログ２０２から、プロセス状態を抽出する処理を実現できる。

図９は作業名付与部２４０の処理を示すフローチャートである。

作業名付与部２４０は後述するモニタリング画面において管理者の可読性を向上させるために作業名を付与するための機能部である。作業名とはプロセス状態から推測される、稼働情報の値の傾向が出る要因となった作業の名前で、Ｗｅｂサーバ装置２０３の稼働状態を総称したものである。作業名は、プロセス状態分析部２３０から受信した、プロセス状態を基に、プロセス名から求まるアプリケーション名としてもよいし、システム管理ツールなどによって関連づけられた、管理者が管理のために用いる名前を用いてもよい。作業名付与部２４０はプロセス状態分析部２３０によって呼び出され、稼働状況管理テーブル２８０へ作業名を記録する。

最初にステップＳ９００ではprocName_aの各要素について、プロセス名をＯＳ２０４に問合せてアプリケーション名を取得し、スカラー変数tasｋnameへ格納する。procName_aとはプロセス状態分析部２３０によって生成された、特徴プロセス名である。作業名をシステム管理ツールなどによって関連づけられた、管理者が管理のために用いる名前とする場合は、問合せ先をＯＳの代わりにシステム管理ツールとすることで実現できる。次にステップＳ９０１では、procName_aの各要素について、稼働ＩＤ＝id、プロセス名５３１＝procName_a、作業名＝tasｋnameを値にもつレコードを稼働状況管理テーブル５３０へ追加する。以上のステップにより、特徴プロセス名から、作業名を抽出する処理を実現できる。

図１０は外部記憶装置１２４に格納されている、エントリ抽出ルール２９０の構成を表す図である。エントリ抽出ルール２９０は、後述する異常判定部２５０が外部記憶装置１２４に格納されている稼働状況管理テーブル２８０から、Ｗｅｂサーバ装置２０３が稼働している環境である、曜日や時間などの条件に応じてエントリを抽出するための選択ルールを管理する選択ルールテーブルである。エントリ抽出ルール２９０は、曜日条件１００１、時間条件１００２、特徴プロセス１００３を含む。曜日条件１００１、時間条件１０２は、Ｗｅｂサーバ装置２０３が稼働している環境である、曜日や時間などの条件を表す。特徴プロセス１００３は、前記条件に応じた、エントリを抽出するための条件を表す。つまり、曜日条件１００１と時間条件１００２に記載の環境で異常検出を行う場合は、対応する特徴プロセス１００３を持つエントリを稼働状況管理テーブル２８０の中から抽出することを意味する。このテーブルは全て管理者が作成する。本実施例では記載していないが、曜日条件１００１と時間帯条件１００２に記載の環境において、過去に最も多かった特徴プロセスの組合せをプロセス状態分析部２３０が記録してもよい。

図１１は異常判定部２５０の処理を示すフローチャートである。異常判定部２５０は、ログ収集制御部２１０に呼び出され、外部記憶装置１２４に格納された稼働状況管理テーブル２８０とエントリ抽出ルール２９０を基に異常の判定を行う。異常検出は、過去の稼働状況から曜日、時間帯、プロセス状態の条件が共通のエントリを抽出して、稼働情報の値をエントリ全体で平均することで求まるモデルデータと、現在の稼働状況との統計的乖離度を算出して、ある水準以上に乖離がある場合に異常と判定する方法で行う。エントリを抽出する際の条件は、選択ルールテーブルのエントリ抽出ルール２９０に従う。

最初にステップＳ１１００では、稼働状況管理テーブル５００から日付５０２カラムと時間５０３カラムの値が最新のレコードを抽出する。次にステップＳ１１０１では、稼働ＩＤ５０１カラムの値によって稼働状況管理テーブル５００、５１０、５２０の結合ビューtestTableを作成する。次にステップＳ１１０２では、testTableの日付５０２カラム、時間５０３カラム、総アクセス数５０４カラムの値をそれぞれスカラー変数testDate、testTimeSlot、testTotalCountへ格納する。次にステップＳ１１０３では、testTableの要求ＵＲＬ５１２カラムの値をキーに連想配列testUrlCountへアクセス数５１３カラムの値を格納する。次にステップＳ１１０４では、testTableの特徴プロセス名５２２カラムの値をキーに連想配列testCpuRatioへ平均ＣＰＵ使用率５２３カラムの値を格納する。

ステップＳ１１００からＳ１１０４の処理は働状況管理テーブル２８０からテストデータを取得することに相当する。テストデータとは異常か否か判定したいデータのことである。結合の処理は、結合はＲＤＢのjoin機能を使って実現できる。次にステップＳ１１０５では、testDateの値を曜日に変換し、スカラー変数dowへ格納する。

次にステップＳ１１０６では、エントリ抽出ルール２９０から、曜日条件１００１＝dow、時間条件１００２＝testTimeSlotのレコードを抽出して、特徴プロセス１００３カラムの値をスカラー変数modelProcへ格納する。次にステップＳ１１０７では、日付５０２の値を曜日に変換したものがdowと一致かつ、時間５０３＝testTimeSlotかつ特徴プロセス名５２２カラムの値がmodelProcを全て含むレコードを抽出する。次にステップＳ１１０８では、ステップＳ１１０６、Ｓ１１０７によって抽出されたレコードがないかを判断する。レコードがない場合はステップＳ１１１６に進み、レコードがある場合はステップＳ１１０９へ進む。

次にステップＳ１１０９では、稼働ＩＤ５０１カラムの値によって稼働状況管理テーブル５００、５１０、５２０の結合ビューmodelTableを作成する。次にステップＳ１１１０では、modelTableの総アクセス数５０４カラムの平均値をスカラー変数modelTotalCountへ格納する。次にステップＳ１１１１では、modelTableの要求ＵＲＬ５１２カラムの値をキーに連想配列modelUrlCount_hへアクセス数５１３カラムの平均値を格納する。

次にステップＳ１１１２では、modelTableの特徴プロセス名５２２カラムの値をキーに連想配列modelCpuRatioへ平均ＣＰＵ使用率５２３カラムの平均値を格納する。ステップＳ１１０９からＳ１１１２の処理は働状況管理テーブル２８０からモデルデータを生成することに相当する。モデルデータとは、テストデータの異常判定を行うために、正常な状態として用いるデータのことを指す。次にステップＳ１１１３では、testTotalCount、testUrlCount、modelTotalCount、modelUrlCount_hの値を用いて乖離度を求めスカラー変数modDivへ格納する。ここでいう乖離度とは、カイ二乗値などの統計量である。カイ二乗値については後述する。

次にステップＳ１１１４では、testCpuRatio、modelCpuRatioの値を用いて類似度を求めスカラー変数modSimへ格納する。ここでいう類似度とは、ベクトルのなす各などの値である。ベクトルのなす各については後述する。次にステップS１１１５では、modDivが５％水準の閾値を超えているかを判断する。超えている場合はステップＳ１１１６へ進み、超えていない場合は処理を終了する。ステップＳ１１１６では、警告フラグのスカラー変数modelAlertにtrueを、スカラー変数modelTimeslotにtestTimeSlotを格納する。警告フラグとは、後述するモニタリング画面が警告のメッセージを表示するか判断するためのフラグである。

ここで、カイ二乗値によって異常検出を行うアルゴリズムについて述べる。
まずカイ二乗分布について説明する。異常値算出のため、統計的検定で用いられるカイ二乗分布を用いる。カイ二乗分布はデータ数に応じた自由度nを持つ。

異常判定の際には、カイ二乗分布の上側確率の値がある値αとなるカイ二乗値すなわち、
∫χ2dχ2 = α …………… (１)
となるχ2値と比較することで判定を行う。

次に多項分布とχ二乗分布について説明する。今、ｋ個の互いに排反な事象Aiがあり、P(Ai)＝Pi(i=1,2,…,ｋ)とし、Ａ１∪Ａ２∪…∪Ａｋ=Ωは全事象とする。ｎ回の独立試行で、事象Aiに入る度数を確率変数Xiであらわす(i=1,2,…,ｋ)。

このとき十分nが大きければ、
χ2 ＝ Σ( Xi - n*Pi )2 / n*Pi …………… (２)
は、自由度ｋ-1のカイ二乗分布で近似できる。ただし、n*Pi ≧ 5とする。ここで、n*Piは事象Aiが起こる期待度数である。

次に本実施例への適用について説明する。上記(１)のカイ二乗分布を、以下の手順で異常判定に用いる。今、モデルデータの総アクセス数をＮ、URL別アクセス数をＮi（i=1~ｋ）とし、テストデータの総アクセス数をｎ、URL別ＨＩＴ数をni(i=1~ｋ)とする。モデルデータからPi＝｛N1/N,…Nｋ/N｝と推定する。

一方、テストデータのi番目の期待値はn*Ni/N、観測値はniとなるため、
χ2 ＝ Σ(ni - n*Ni/N) / n*(Ni/N) …………… (３)
となる。

この値を自由度ｋ−１のカイ二乗分布として、上側確率がある値αとなるカイ二乗値を算出できる。つまり、この値を閾値として、カイ二乗値が閾値を超える場合を異常として判定することは、モデルデータの値を理想としたとき、テストデータの値がα/100％以下で観測される値である場合に異常とみなす(α%水準で乖離がある場合を異常とみなす)ことに相当する。

本実施例では、ＵＲＬごとのアクセス数と総アクセス数を用いてカイ二乗検定によって乖離度を算出したが、稼働状況を示すスカラーやベクトルを比較し、上側確率を定義できる検定方法であれば何を用いてもよい。例えば、Ｇ検定により判断してもよいし、ベイズの仮説検定や多項検定やフィッシャーの正確確率検定により判断してもよいし、シェフェ法やテューキー法による分散分析により判断してもよい。

また、ここでベクトルのなす各によって類似度を求めるアルゴリズムについて述べる。今、モデルデータで稼働しているプロセスをa1~aｋ、平均CPU使用率をAi（i=1~ｋ）とし、テストデータで稼働しているプロセスをa1~aｋ、平均CPU使用率をBi(i=1~ｋ)とする。

モデルデータベクトルA=(A1,A2,…,Aｋ)テストデータベクトルB=(B1,B2,…,Bｋ)として、ベクトルの類似度を(4)によって求める。
<A,B>/||A||||B|| …………… (4)
<A,B>はベクトルAとベクトルBの内積、||A||はベクトルAのノルムである。

ベクトルAとBが最も類似している場合はこの値は１、ベクトルAとBが最も類似していない場合はこの値は０となる。このベクトル類似度を求めることで、プロセスの組合せが同じで、プロセスごとのCPU使用率の比が同じものを類似度が高いとして評価することができる。以上のステップにより、稼働状況管理テーブル２８０から、乖離度と類似度を抽出する処理を実現できる。

図１２は類似稼働状況抽出部２７０の処理を示すフローチャートである。

類似稼働状況抽出部２７０は、ログ収集制御部２１０に呼び出され、外部記憶装置１２４に格納された稼働状況管理テーブル２８０とエントリ抽出ルール２９０を基に、プロセスの稼働状態が現在の稼働状況と類似したモデルデータを用いて異常判定部２５０と同様の処理を行う。

以下ステップを説明するが、処理は異常判定部と同様で、エントリ抽出ルール２９０ではなく、テストデータの特徴プロセスをキーに稼働状況管理テーブル２８０からエントリを抽出する部分が異なる。

最初にステップＳ１２００では、Ｓ１１００とＳ１１０１に記載のステップを実行する。この処理は稼働状況管理テーブル２８０からテストデータを取得することに相当する。次にステップＳ１２０１では、エントリ抽出ルール２９０から特徴プロセス１００３カラムの値がtestCpuRatioの全プロセス名を含むレコードを１つ抽出して、曜日条件１００１カラム、時間条件１００２カラムの値それぞれスカラー変数dow、recTimeSlotへ格納する。

次にステップＳ１２０２では、日付５０２の値を曜日に変換したものがdowと一致かつ、時間５０３=recTimeSlotかつの特徴プロセス名５２２カラムの値がtestCpuRatioを全て含むレコードを抽出する。次にステップＳ１２０３では、ステップＳ１２０１、Ｓ１２０２によって抽出されたレコードがないか判断する。レコードがない場合はステップＳ１２０４へ進み、ある場合はステップＳ１２０５へ進む。ステップＳ１２０４では、警告フラグのスカラー変数recAlertにtrueを、スカラー変数recTimeSlotにtestTimeSlotを格納し、処理を終了する。

ステップＳ１２０５では、稼働ＩＤ５０１カラムの値によって稼働状況管理テーブル５００、５１０、５２０の結合ビューrecommendtableを作成する。次にステップＳ１２０６では、recTableの総アクセス数５０４カラムの平均値をスカラー変数recTotalCountへ格納する。次にステップＳ１２０７では、recTableの要求ＵＲＬ５１２カラムの値をキーに連想配列recUrlCountへアクセス数５１３カラムの平均値を格納する。

次にステップＳ１２０８では、recTableの特徴プロセス名５２２カラムの値をキーに連想配列recCpuRatioへ平均ＣＰＵ使用率５２３カラムの平均値を格納する。

次にステップＳ１２０９では、testTotalCount、testUrlCount、recTotalCount、recrulcoutの値を用いて乖離度を求めスカラー変数recDivへ格納する。次にステップＳ１２１０では、testCpuRatio、recCpuRatioの値を用いて類似度を求めスカラー変数recSimへ格納する。

次にステップＳ１２１１では、recDivが５％水準の閾値を超えているかを判断する。超えている場合はステップＳ１２１２へ進み、超えていない場合はステップＳ１２１３へ進む。ステップＳ１２１２では、警告フラグのスカラー変数recAlertにtrueを、スカラー変数recTimeSlotにtestTimeSlotを格納し、ステップＳ１２１３へ進む。

次にステップＳ１２１３では、dow、recTimeSlot、 recTotalCount、 recUrlCount、 recCpuRatio、 recSim、 recAlert、 recTimeSlotを値に持つ構造体の配列に追加する。この処理は、レコメンドするモデルデータの候補を保存しておくための処理である。

次にステップＳ１２１４では、エントリ抽出ルール２９０に特徴プロセス１００３カラムの値がtestCpuRatioの全プロセス名を含むレコードが他にあるかを判断する。他にある場合はステップＳ１２０１へ戻り、モデルデータ候補の抽出を続ける。他にない場合はステップＳ１２１５へ進む。次にステップＳ１２１５では、構造体の配列からrecSimの値が大きい上位２つを抽出する。この２つはレコメンドするモデルデータとして用いる。

ここで、レコメンドの概念についても説明を行う。本実施例の異常検出装置では、エントリ抽出ルール２９０によって生成されたモデルデータを用いて判定を行う。このルールは一般に曜日や時間帯によって周期的に行われる業務などのイベントによって固定的に決められるものである。しかし、業務などのイベントには周期的でない突発的なイベントもあり、突発的なイベントが起きている際には判定に用いる稼働状況が適切でない場合があり得る。そこで稼働しているプロセスの類似性からモデルデータを作成して、今の判定に用いるモデルデータとしてレコメンドを行うものである。

図１３は異常検出装置のモニタリング画面１３００の構成を表す図である。Ｕ／Ｉ制御表示部２６０が生成する画面であり、モデルデータのグラフ、現在の稼働状況のグラフ、モデルデータと現在の稼働状況の乖離度を表示する。この際、モデルデータのグラフ、乖離度および現在の稼働状況のグラフには、プロセス状態と、作業名などの情報を付与しておく。さらに類似稼働状況抽出部から受信したモデルデータとモデルデータの作成に用いたデータを基に、レコメンドするモデルデータのグラフを表示する。この際、レコメンドするモデルデータのグラフには、プロセス状態と作業名などの情報を付与しておく。このような画面にしておくことで、管理者に異常判定の根拠を示すことを図る。異常判定の根拠を示すことで、管理者は判断を行うことが出来るようになる。例えば、突発的なウィルスパターンアップデートがあると、システムに負荷がかかるためスループットが低下し、アクセス数が減少する。このような場合、普段とは乖離した状態であるため異常として検出されるが、現在の稼働状況に付与されたプロセス状態が示されていることで、ウィルスパターンアップデートを行っていることがわかる。さらに、レコメンドするモデルデータに付与されたプロセス状況が示されていることで、アクセス数の傾向はウィルスパターンアップデートによる影響であるということがわかり、異常ではないと判断が出来るようになる。

表示部に表示されるモニタリング画面１３００は、閉じるボタン１３０１、メッセージ表示部１３０２、現在状況表示部１３０３、稼働状況表示部１３０４、乖離度表示部１３０５、類似稼働状況表示部１３０６、から構成される。閉じるボタン１３０１はモニタリング画面１３００を閉じるためのボタンである。メッセージ表示部１３０２はメッセージの出力であり、異常検出の際などに管理者へ通知を行うものである。modelAlert、recAlertなどの変数にtrueが格納されているかによって表示するか判断され生成される。管理者への通知は、音によるものでも良いし、色によるものでも良い。現在状況表示部１３０３は現在の状況を表示するもので、現在状況詳細表示部１３１１、現在状況グラフ表示部１３１２から構成される。これらはtestTimeSlot、testTotalCount、testCpuRatioの値を用いて生成される。

稼働状況表示部１３０４は稼働の状況を表示するもので、稼働状況詳細表示部１３１３、類似度表示部１３１４、稼働状況グラフ１３１５、乖離度算出ボタン１３１６から構成される。これらはtestTimeSlot、modelTotalCount、modelCpuRatio、modSimの値を用いて生成される。乖離度算出ボタン１３１６により、乖離度表示部１３０５の表示を対応する値に切り替える。

乖離度表示部１３０５は現在状況と稼働状況の乖離度を表示するもので、比較対象詳細表示部１３１７、乖離度グラフ表示部１３１８から構成される。これらはtestTimeSlot、modelCpuRatio、modDivとrecTimeSlot、recCpuRatio、recDivを切り替えて用いて生成される。

類似稼働状況表示部１３０６は現在状況と類似した稼働状況を表示するもので、類似稼働状況詳細表示部１３１３、類似稼働状況類似度表示部１３１４、類似稼働状況グラフ表示部１３１５、乖離度算出ボタン１３１６から構成される。これらはrecTimeSlot、recTotalCount、recCpuRatio、recSimの値を用いて生成される。

図１４は異常検出装置のモニタリング画面１３００のダイアログ１４００の構成を表す図である。ダイアログ１４００はモニタリング画面１３００に表示されている各々のグラフのプロセス状態に関する情報を表示する画面である。

作業名１４０１、平均ＣＰＵ使用率１４０２、プロセスプロパティ１４０３、ＯＫボタン１４０４から構成される。この画面は稼働状況管理テーブル５２０と５３０を用いることで生成できる。ＯＫボタン１４０４はダイアログ１４００を閉じるためのボタンである。ダイアログ１４００は各グラフの持つプロセスのプロパティを表示するもので、モニタリング画面１３００の各詳細をマウスでクリックすることで表示されるダイアログである。マウスのカーソルを合わせることで表示されるポップアップであってもよいし、ダイアログ１４００の情報は各詳細表示部の中に表示しても良い。

以上が第１の実施例の処理の一例である。本実施例ではアクセスログを用いたが、Webサーバの稼働の状態によって変化する、値が算出できるものであれば、何を用いてもよい。また、監視対象もそれに伴い、Webサーバに限らず、何らかの計算機システムであればよい。このようにして異常判定結果と判定根拠の表示を行うことにより、従来、管理者が判断を行うことが困難だった、誤検出をした場合にも、判断にかかる時間を短縮させる。

第２の実施例は、異常検出装置１２０がＷｅｂサーバ装置２０３の異常を検出した後、反映ボタンが押されたため、誤検出を起こさないようエントリ抽出ルールを更新する構成の実施例である。

図１５は本実施例における、異常検出装置１２０で動作するプログラムの構成機能要素を示すブロック図である。選択反映部１５００以外の構成は、前記第１の実施例と同様である。選択反映部１５００は反映ボタンの選択があった場合に、エントリ抽出ルール２９０の更新を行う機能部である。

図１６は選択反映部の処理の一例を示すフローチャートである。最初にステップS１６０１では、エントリ抽出ルールにレコメンドした稼働状況を作成した条件を入れる編集画面１７００を表示する。編集画面については後述する。次にステップS１６０２では、エントリ抽出ルールの更新を行う。以上のステップによりエントリ抽出ルール２９０の更新を実現する。

図１７はエントリ抽出ルール編集画面１７００の構成の一例を表した図である。エントリ抽出ルール編集画面１７００はメッセージ部１７０１、Yesボタン１７０２、NOボタン１７０３、閉じるボタン１７０４、曜日条件１７０５、時間帯条件１７０６、作業名ＩＤ１７０７、曜日条件１７１１、時間帯条件１７１２、作業名ＩＤ１７１３から構成される。メッセージ部１７０１は常に“選択をルールに反映しますか?”文字列を表示する部分である。曜日条件１７０５、時間帯条件１７０６、作業名ＩＤ１７０７はエントリ抽出ルール編集画面１７００を表示した際の現在稼働状況から生成される。曜日条件１７１１、時間帯条件１７１２、作業名ＩＤ１７１３はエントリ抽出ルール２９０と稼働状況管理テーブル５３０から生成される。Yesボタン１７０２の入力を受付けた際は、エントリ抽出ルールへ、現在の稼働状況を加える。Noボタン１７０３の入力を受付けた場合は何もせずエントリ抽出ルール編集画面１７００を閉じる。これにより、管理者がエントリ抽出ルールに誤りがあると判断した場合は、次回から現在の状況を用いて判定が行えるよう、容易に変更を行うことができる。

図１８はモニタリング画面の構成の一例を表す図である。反映ボタン１８００と稼働状況１３０４以外の構成は、前記第１の実施例と同様である。反映ボタン１８００は、エントリ抽出ルール編集画面１７００を表示するためのボタンである。稼働状況１３０４は複数の候補から構成される。これは、エントリ抽出ルール２９０の更新が行われたことにより、複数の稼働状況によって判定が行われるためである。異常判定は全ての稼働状況が異常と判定した場合に下してもよいし、いずれかの稼働状況が異常と判定した場合に下してもよい。

以上が第２の実施例の処理の一例である。このようにして異常の表示と選択の反映を行うことにより、判定に用いる稼働状況の選択ルールをより適切なものにすることができ、再現率や適合率といった異常検出の精度を向上させることができる。

なお、本発明は、前述した２つの実施例に限定されるものではなく、本発明から類推される範囲で多種多様な変形例に対して実施可能なものである。

本発明は、監視対象装置の過去と現在の稼働情報に基づき、異常検出を行う技術として有用である。

１００…クライアントPC
１２０…異常検出装置
２０１…アクセスログ
２０２…プロセス稼働ログ
２０３…Ｗｅｂサーバ装置
２１０…ログ収集制御部
２２０…稼働情報分析部
２３０…プロセス状態分析部
２４０…作業名付与部
２５０…異常判定部
２６０…Ｕ／Ｉ制御表示部
２７０…類似稼働状況抽出部
２８０…稼働状況管理テーブル
２９０…エントリ抽出ルール
１３００…モニタリング画面
１４００…ダイアログ
１７００…エントリ抽出ルール編集画面。

Claims (10)

1. 処理部と記憶部を備えた装置を用い、監視対象システムの異常検出を行う異常検出方法であって、
   前記処理部は、
   前記監視対象システムからアクセスログとプロセス稼働ログを取得する手順と、
   取得した前記アクセスログを時間毎に分類し、時間毎の稼働情報として記録する手順と、
   取得した前記プロセス稼働ログから、記録した前記稼働情報のプロセス状態を抽出する手順と、
   抽出した前記プロセス状態から作業名を求める作業名付与手順と、
   求めた前記作業名を前記稼働情報に関連付けして稼働状況として記録する手順と、
   現在の稼働状況と過去の稼働状況を基に異常を検出する手順を実行し、
   前記異常を検出する手順では、記録した前記稼働状況について、現在の稼働状況と過去の稼働状況の乖離度を算出する手順を実行し、
   前記処理部は、
   前記過去の稼働状況を、関連付いている前記作業名で分類する手順と、
   分類した前記過去の稼働状況から、選択ルールに従って前記乖離度の算出に用いる過去の稼働状況を選択する手順と、
   前記現在の稼働状況に関連付いている前記作業名と、分類した一つ以上の前記過去の稼働状況に関連付いている前記作業名から類似度を算出する手順とを更に実行する、
   ことを特徴とする異常検出方法。
2. 請求項１記載の異常検出方法であって、
   前記装置は表示部を更に備え、
   前記処理部は、
   前記現在の稼働状況と、前記過去の稼働状況と、前記稼働状況に関連付いている前記作業名と、算出した前記乖離度を前記表示部に表示する手順を更に実行する、
   ことを特徴とする異常検出方法。
3. 請求項１記載の異常検出方法であって、
   前記作業名付与手順は、
   前記プロセス状態のプロセスの起動と終了のタイミングに基づいて前記作業名を求める、
   ことを特徴とする異常検出方法。
4. 請求項２記載の異常検出方法であって、
   前記表示する手順は、算出した前記類似度の高い一つ以上の前記稼働状況を表示する、
   ことを特徴とする異常検出方法。
5. 処理部と記憶部とを備え、監視対象システムの異常検出を行う異常検出装置であって、
   前記処理部は、
   前記監視対象システムからアクセスログとプロセス稼働ログを取得するログ収集制御部と、
   取得した前記アクセスログを時間毎に分類し、時間毎の稼働状況として記録する稼働情報分析部と、
   記録した前記稼働状況のプロセス状態を前記プロセス稼働ログから抽出し、抽出した前記プロセス状態から作業名を求め、前記稼働状況に関連付けて記録するプロセス状態分析・作業名付与部と、
   記録した前記稼働状況について、現在の稼働状況と過去の稼働状況の乖離度を算出する乖離度算出部と、を備え、
   前記記憶部は、
   前記乖離度算出部の乖離度算出に用いる、前記過去の稼働状況を選択する選択ルールテーブルを備え、
   前記稼働情報分析部は、
   前記過去の稼働状況を、関連付いている前記作業名で分類し、
   分類した前記過去の稼働状況から、前記選択ルールテーブルに従って前記乖離度の算出に用いる過去の稼働状況を選択し、
   前記現在の稼働状況に関連付いている前記作業名と、分類した一つ以上の前記過去の稼働状況に関連付いている前記作業名から類似度を算出する、
   ことを特徴とする異常検出装置。
6. 請求項５記載の異常検出装置であって、
   前記処理部は、
   前記現在の稼働状況と、前記過去の稼働状況と、前記稼働状況に関連付いている前記作業名と、算出した前記乖離度を出力表示するユーザインターフェイス制御部を更に備える、
   ことを特徴とする異常検出装置。
7. 請求項６記載の異常検出装置であって、
   表示部を更に備え、
   前記ユーザインターフェイス制御部は、算出された前記類似度の高い一つ以上の前記稼働状況を前記表示部に表示する、
   ことを特徴とする異常検出装置。
8. 監視対象システムの異常検出を行う、処理部と記憶部とを備えた装置の異常検出プログラムであって、
   前記処理部に、
   前記監視対象システムからアクセスログとプロセス稼働ログを取得する手順と、
   取得した前記アクセスログを時間毎に分類し、時間毎の稼働情報として記録する手順と、
   取得した前記プロセス稼働ログから、記録した前記稼働情報のプロセス状態を抽出する手順と、
   抽出した前記プロセス状態から作業名を求める作業名付与手順と、
   求めた前記作業名を前記稼働情報に関連付けして稼働状況として記録する手順と、現在の稼働状況と過去の稼働状況を基に異常を検出する手順を実行させ、
   前記異常を検出する手順では、
   記録した前記稼働状況について、現在の稼働状況と過去の稼働状況の乖離度を算出する手順を実行させ、
   前記処理部に、
   前記過去の稼働状況を、関連付いている前記作業名で分類する手順と、
   分類した前記稼働状況から、選択ルールに従って前記乖離度の算出に用いる前記過去の稼働状況を選択する手順と、
   前記現在の稼働状況に関連付いている前記作業名と、分類した一つ以上の前記過去の稼働状況に関連付いている前記作業名から類似度を算出する手順とを更に実行させ、
   前記類似度を算出する手順において、算出した前記類似度の高い一つ以上の前記稼働状況を表示させる、
   ことを特徴とする異常検出プログラム。
9. 請求項８記載の異常検出プログラムであって、
   前記処理部に、
   前記現在の稼働状況と、前記過去の稼働状況と、前記稼働状況に関連付いている前記作業名と、算出した前記乖離度を出力させる手順を更に実行させる、
   ことを特徴とする異常検出プログラム。
10. 請求項８記載の異常検出プログラムであって、
    前記作業名付与手順は、
    前記プロセス状態のプロセスの起動と終了のタイミングに基づいて前記作業名を求める、
    ことを特徴とする異常検出プログラム。

Images