JP2018045403A - 異常検知システム及び異常検知方法 - Google Patents

Abstract

【課題】複数のイベント系列が混在するログから監視対象システムの異常を検知するシステムを提供する。【解決手段】異常検知システム１は、監視対象システム２が出力したログに含まれる時系列のイベントを、所定のルールに基づいて記号化イベントに変換する記号化手段１１２と、記号化手段によって記号化された正常時のログに基づいて同じパターンで出現する記号化イベント列を頻出パターンとして学習する学習手段１１５と、記号化手段によって記号化された監視時のログにおいて頻出パターンが生起しているか否かに基づいて異常の発生の有無を検知する異常検知手段１１７とを有する。【選択図】図１

Description

本発明は、対象システムの異常を検知する技術に関する。

様々な情報通信サービスや社会インフラサービスは、多数の計算機、各種機器及び設備から構成されるシステムによって支えられている。当該システムは、より便利なサービスの提供及び高度な最適化のために、大規模かつ複雑である。また、当該システムは、コスト低減や柔軟なソフト更新等の要請から、異なる企業が提供するハードウェアやソフトウェア、又は、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）を組み合わせて構築されることも多い。このようなシステムは、内部がブラックボックスとなりやすく、運用監視の負担が大きい。

システムを運用監視するためのソフトウェアは、運用監視者の負担を軽減するために、検索機能や所定のルールに対する適合可否のチェック機能などを提供する。しかし、監視対象のデータ量は膨大であり、データの特性を把握してルールを設計しないと、不要なものも多数検出されてしまう。すなわち、ルールを適切に設計する負荷が大きい。

特許文献１には、ログに含まれるイベントの順列と正常時におけるログの特徴を示すパターン情報の順列とを比較することにより、ログと正常時パターンとの不一致箇所を特定し、特定した不一致箇所に基づいてログと正常時パターンとの不一致の程度が所定の閾値を超えているか否かを判定することにより、異常を検知する技術が開示されている。

特開２０１２−９４０４６号公報

データセンタの複数のサーバを管理する場合、或るイベント系列中に他の単発イベントや別のイベント系列が割り込むログを監視対象とする必要がある。理由は次の通りである。データセンタでは、様々な目的に応じて、サーバ上のソフトが相互に連携して処理を行う。例えば、ＤＢへデータを登録するトランザクションなど、定型の動作が行われる場合、複数のサーバが別々に一連のトランザクションに関するログを書き込む。この場合、ｆｌｕｅｎｔｄ、Ｚａｂｂｉｘなど、ログを監視、収集及び統合するソフトを使用して、複数のサーバのログを１つのログに時系列に統合して分析する。しかしながら、様々なソフトが別々の文脈でログを出力しているため、複数のログを時系列に統合すると、或るイベント系列の途中に他のイベント系列が割り込んでしまう。

特許文献１の技術は、上記のように、或るイベント系列の途中に他のイベント系列が割り込む状況を想定していない。このため、特許文献１の技術は、他のイベントが割り込んだ箇所を、不一致箇所として扱ってしまう。すなわち、特許文献１の技術は、或るイベント系列において順序が一致していたとしても、他のイベント系列の割り込みによる不一致箇所が存在すると、全体として異常が発生しているのか否かを正しく判断することができない。

そこで本発明の目的は、複数のイベント系列が混在するログから監視対象システムの異常を検知するシステムを提供することにある。

一実施形態に係る、監視対象システムの異常を検知する異常検知システムは、
監視対象システムが出力したログに含まれる時系列のイベントを、所定のルールに基づいて記号化イベントに変換する記号化手段と、
記号化手段によって記号化された正常時のログに基づいて、同じパターンで出現する記号化イベント列を頻出パターンとして学習する学習手段と、
記号化手段によって記号化された監視時のログにおいて頻出パターンが生起しているか否かに基づいて、異常の発生の有無を検知する異常検知手段と、を有する。

本発明によれば、複数のイベント系列が混在するログから監視対象システムの異常を検知することができる。

異常検知システムの構成例。 計算機のハードウェアの構成例。 統合前のログの一例。 統合後のログの一例。 テンプレートデータの一例。 記号化イベントの一例。 頻出系列パターンの一例。 監視対象パターンの一例。 異常検知結果データの一例。 監視対象選定及びモデル学習フェーズの処理の一例を示すフローチャート。 テンプレート生成処理の一例を示すフローチャート。 ウィンドウサイズ決定処理の一例を示すフローチャート。 レストパターンの生起開始から終了までのイベント数の度数分布の例 レストパターンのウィンドウサイズ決定処理の変形例を示すフローチャート。 監視フェーズ処理の一例を示すフローチャート。 ログ情報監視画面の一例。 追跡情報表示画面の一例。 異常検出回数表示画面の一例。

以下、実施形態を説明する。以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信インターフェイスデバイスのうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ、そのプロセッサを有する装置とされてもよい。プロセッサが行う処理の一部又は全部が、ハードウェア回路で行われてもよい。コンピュータプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

＜概略＞
本実施形態に係る異常検知システムは、情報通信サービスや社会インフラサービスを支える計算機および関連機器又は設備等から構成される機器、計算機又はシステム（「監視対象システム」と呼ぶ）のログから、監視対象システムにおいて異常が発生しているか否かを検知する。これにより、異常検知システムは、これらのサービスに係るシステムの安定的な運用を支援する。ログは、日時、テキスト又は数値等で表現されたメッセージを含むイベントの集合であってよい。

異常検知システムの処理は、監視対象選定及びモデル学習フェーズと、監視フェーズとに分けられてよい。

監視対象選定及びモデル学習フェーズは、監視対象システムが出力した正常時のログから頻出系列パターンに基づき監視対象を選定するとともに、頻出系列パターンの生起の予測を行うための予測モデルを学習する。

監視フェーズは、監視時のログについて監視対象の頻出系列パターンの生起の予測結果と実際に発生したログのイベント列に乖離がある場合、それを異常と判断し、ユーザに通知および関連情報を表示する。

監視対象選定及びモデル学習フェーズでは、次のＡ１〜Ａ５の処理が実行されてよい。
（Ａ１）テキスト処理やクラスタリング処理に基づき、テキストや数値などで記載された正常時のログを記号列に変換する。
（Ａ２）記号化されたイベント列から頻出系列パターンを抽出する。すなわち、頻出系列パターンとは、正常時に頻出するイベント列（イベントの順序）のパターンである。
（Ａ３）頻出系列パターンを構成する要素列の部分要素列から構成される部分パターンを生成する。すなわち、部分パターンとは、頻出系列パターンの一部分のイベント列（イベントの順序）のパターンである。
（Ａ４）Ａ２で抽出した頻出系列パターンと、Ａ３で生成した部分パターンとの組の集合から、監視に用いる部分パターンを選定する。この選定方法については後述する。その際、頻出系列パターン内の部分パターンの生起を監視するために用いるウィンドウサイズ（「部分パターンのウィンドウサイズ」と呼ぶ）と、その部分パターンが生起してから頻出系列パターンが最後まで生起するまでの間のパターン（「レストパターン」と呼ぶ）を監視するために用いるウィンドウサイズ（「レストパターンのウィンドウサイズ」と呼ぶ）と、を決定する。
（Ａ５）生成した頻出系列パターン、部分パターン、及び正常時のログに基づき、部分パターンが生起したときにその部分パターンを含む頻出系列パターンが生起する確率を算出するための統計的な予測モデルを学習する。

監視フェーズでは、学習フェーズで学習したパターンやモデルに基づいて、ログから異常を検知する。そして、監視フェーズは、運用監視者に対して、検知結果や関連情報などを提示する。監視フェーズは、次のＢ１〜Ｂ３の要件を全て満たす場合に異常と判定してよい。
（Ｂ１）部分パターンのウィンドウサイズの範囲において、部分パターンが生起する。
（Ｂ２）部分パターンの生起後に、部分パターンのウィンドウサイズとレストパターンのウィンドウサイズとを合わせた範囲において、その部分パターンを含む頻出系列パターンが生起する確率が所定の閾値以上である。
（Ｂ３）その部分パターンの生起後に、その部分パターンを含む頻出系列パターンが生起していない。

すなわち、監視フェーズは、正常時であれば生起するはずの頻出系列パターンが生起していない場合、異常と判断する。

異常判定処理では、次のＣ１〜Ｃ３の処理が実行されてよい。
（Ｃ１）監視時のログを前述同様に記号列に変換する。
（Ｃ２）監視対象選定及びモデル学習フェーズで選定された各パターンを用いて、ログに対して異常検知を行う。例えば、上記Ｂ１乃至Ｂ３の要件を全て満たすか否かを判定する。
（Ｃ３）その検知結果を通知し、関連情報を表示する。

なお、本実施形態のログは、日時、テキスト又は数値等で表現されたメッセージの集合であるが、ログはどのようなものであってもよい。例えば、カメラやマイクなどから得られる画像や音声に対してパターン認識を行い、タグ（アノテーション）や文章を抽出したものをログのイベントとしてもよい。

＜システム構成＞
図１は、本実施形態に係る異常検知システムの構成例を示す。

異常検知システム１は、異常検知装置１１と、端末１２とを有する。異常検知装置１１は、ログから抽出した頻出系列パターンに基づいて、監視対象システム２に異常が発生しているか否かを検知する。端末１２は、その検知結果を表示する。

異常検知装置１１と端末１２とは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のネットワークで接続されてよい。監視対象システム２は、１以上の被監視装置２１を有してよい。各被監視装置２１は、ＬＡＮ又はＷＡＮ等のネットワークで接続されてよい。なお、各サブシステムは、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）に代表されるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の他のネットワークを介して接続されても良い。

上記の各構成要素の数は増減してもよい。各構成要素は、１つのネットワークで接続されても良いし、階層分けされて接続されてもよい。例えば、異常検知装置１１は、複数の装置で構成されてもよいし、端末１２と同一のハードウェア上で実現されてもよい。例えば、１以上の被監視装置２１が、異常検知装置１１又は端末１２とハードウェアを共有してもよい。

＜機能とハードウェア＞
図２は、計算機のハードウェアの構成例を示す。以下、図１及び図２を参照しながら、異常検知システム１の機能について説明する。

異常検知装置１１は、機能として、ログ収集部１１１、ログ記号化部１１２、監視パターン生成部１１３、ウィンドウサイズ決定部１１４、予測モデル学習部１１５、系列パターン生起予測部１１６、異常検知部１１７、データ管理部１１８を有してよい。これらの機能は、異常検知装置１１が備えるＣＰＵ１Ｈ１０１が、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１Ｈ１０２又は外部記憶装置１Ｈ１０４に格納されたプログラムをＲＡＭ（Ｒｅａｄ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１Ｈ１０３に読み込み、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１Ｈ１０５、マウスやキーボード等に代表される外部入力装置１Ｈ１０６、ディスプレイなどに代表される外部出力装置１Ｈ１０７を制御することによって実現されてよい。

端末１２は、機能として、表示部１２１を有する。この機能は、端末１２が備えるＣＰＵが、ＲＯＭ又は外部記憶装置に格納されたプログラムをＲＡＭに読み込み、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）、マウスやキーボード等に代表される外部入力装置、ディスプレイなどに代表される外部出力装置を制御することで実現されてよい。

被監視装置２１は、機能として、ログ収集機能や、装置ごとの目的（例えばデータ管理、Ｗｅｂページのホスティング、設備の制御等）に応じた各種機能を有する。これらの機能は、被監視装置２１が備えるＣＰＵが、ＲＯＭ又は外部記憶装置に格納されたプログラムをＲＡＭに読み込み、通信Ｉ／Ｆ、マウスやキーボード等に代表される外部入力装置、ディスプレイなどに代表される外部出力装置を制御することによって実現されてよい。

＜データ構造＞
図３は、統合前のログ１Ｄ１の一例を示す。統合前のログ１Ｄ１は、異常検知装置１１によって監視対象システム２から収集されてよい。

ログ１Ｄ１には、１つ以上のイベントが含まれてよい。図３は、ＢＳＤ又はＬｉｎｕｘ（登録商標）などのＯＳにおいて出力される「ｓｙｓｌｏｇ」の例である。

イベントは、そのイベントが生成された日時、発行したデータソース名、及び、イベントの内容を表す短いテキストによって構成されてよい。また、イベントの重要度（ｉｎｆｏ，ｅｒｒｏｒ等）が付与されてもよい。ｓｙｓｌｏｇやｗｅｂサーバログなどでは、図３に示すように、１行が１つのイベントに対応する。しかし、複数行が１つのイベントに対応してもよい。本実施形態では、ログの記載形式に関わらず、イベントの日時を除いた部分の情報を「メッセージ」と呼ぶ。

図４は、統合後のログの一例を示す。統合後のログは、異常検知装置１１によって監視対象システム２から収集された複数のログ１Ｄ１が、データ管理部１１８によって統合されたものであってよい。

統合後のログにおけるイベントは、データ項目として、イベントＩＤ１Ｄ２０１と、日時１Ｄ２０２と、メッセージ１Ｄ２０３とを有してよい。

イベントＩＤ１Ｄ２０１は、統合後のイベントを一意に識別するための値である。ログ収集部１１１は、被監視装置２１からログを収集する際に、各イベントにイベントＩＤ１Ｄ２０１を付与してよい。

日時１Ｄ２０２は、イベントが発生した日時である。ログ収集部１１１は、容易に日時を比較できるように、日時１Ｄ２０２をＩＳＯ８６０１などの共通フォーマットに統一してよい。

メッセージ１Ｄ２０３は、日時１Ｄ２０２に発生したイベントの内容である。

図５は、テンプレートデータ１Ｄ３の一例を示す。テンプレートデータ１Ｄ３は、データ管理部１１８で管理されてよい。

テンプレートデータ１Ｄ３０２は、イベントを記号化する際に用いられる。テンプレートデータ１Ｄ３０２は、データ項目として、クラスＩＤ１Ｄ３０１と、テンプレート文１Ｄ３０２とを有して良い。

クラスＩＤ１Ｄ３０１は、テンプレートデータ１Ｄ３０２を一意に識別するための値である。クラスＩＤ１Ｄ３０１は、記号化されたイベントと対応付けられてよい。すなわち、記号化されたイベントには、何れかのクラスＩＤ１Ｄ３０１が対応付けられる。

テンプレート文１Ｄ３０２は、類似するメッセージ１Ｄ２０３を抽象化するための文である。テンプレート文１Ｄ３０２は、メッセージ１Ｄ２０３の一部がワイルドカードで表現された文であってよい。

図５の例では、「＊」が任意の文字列、「＄ＮＵＭ」が数値にマッチするワイルドカードを意味する。なお、正規表現にマッチするか否か、又は、特定の文字列群を含むか否かなどによってもイベントを記号化することができる。したがって、テンプレート文１Ｄ３０２は、それらを表現した文であってもよい。

図６は、記号化イベント１Ｄ４の一例を示す。記号化イベント１Ｄ４は、データ管理部１１８で管理されてよい。

記号化イベント１Ｄ４０１は、イベントを記号列に変換した後のデータである。記号化イベント１Ｄ４０１は、データ項目として、イベントＩＤ１Ｄ４０１と、日時１Ｄ４０２と、クラスＩＤ１Ｄ４０３とを有して良い。

クラスＩＤ１Ｄ４０３は、イベントＩＤ１Ｄ４０１のイベントに対応付けられたテンプレートデータ１Ｄ３のクラスＩＤ１Ｄ３０１である。ログの収集と同時にイベントを記号化する場合、記号化イベント１Ｄ４の数は、統合後のログのイベント１Ｄ２の数と一致する。

図６の例では、イベントＩＤ１Ｄ４０１「１０００００１」のイベントには、クラスＩＤ１Ｄ４０３「４」が対応付けられている。これは、イベントＩＤ「１０００００１」のイベントのメッセージ１Ｄ２０３は、図５のクラスＩＤ１Ｄ３０１「４」に対応するテンプレート文１Ｄ３０２「ｍａｃｈｉｎｅ１ ａｎａｃｒｏｎ［＄ＮＵＭ］：Ｊｏｂ ＊ ｔｅｒｍｉｎａｔｅｄ」に適合するメッセージであったことを表す。

図７は、頻出系列パターン１Ｄ５の一例を示す。頻出系列パターン１Ｄ５は、データ管理部１１８で管理されてよい。

頻出系列パターン１Ｄ５は、正常時のログに関する記号化イベント１Ｄ４０１に対して系列パターンマイニングを適用することで得られてよい。頻出系列パターン１Ｄ５は、データ項目として、パターンＩＤ１Ｄ５０１、パターン長１Ｄ５０２、出現回数１Ｄ５０３、パターン１Ｄ５０４を有して良い。

パターンＩＤ１Ｄ５０１は、頻出系列パターン１Ｄ５を一意に識別するための値である。

パターン長１Ｄ５０２は、パターン１Ｄ５０４に含まれるクラスＩＤの数である。

出現回数１Ｄ５０３は、正常時のログにおいてパターン１Ｄ５０４が発生した回数である。

パターン１Ｄ５０４は、正常時のログにおいて時系列に頻出するクラスＩＤのセットである。

図７のパターンＩＤ１Ｄ５０１「０」の頻出系列パターンは、クラスＩＤが時系列に「０→４→２→１８→７」（１Ｄ５０４）と出現するパターンであることを示す。また、このパターンＩＤ１Ｄ５０１「０」のパターン１Ｄ５０４は、５つ（１Ｄ５０２）のクラスＩＤから構成されており、正常時のログにおいて３４回（１Ｄ５０３）出現していることを示す。

図８は、監視対象パターン１Ｄ６の一例を示す。監視対象パターン１Ｄ６は、データ管理部１１８で管理されてよい。

監視対象パターン１Ｄ６は、監視対象となる頻出系列パターンと、当該頻出系列パターンに含まれる一部のパターン（「部分パターン」という）とを含む。監視対象パターン１Ｄ６は、データ項目として、パターンＩＤ１Ｄ６０１と、全体パターン１Ｄ６０２と、部分パターン１Ｄ６０３と、部分パターンのウィンドウサイズ１Ｄ６０４と、レストパターンのウィンドウサイズ１Ｄ６０５とを有してよい。
パターンＩＤ１Ｄ６０１及び全体パターン１Ｄ６０２は、それぞれ、図７の頻出系列パターン１Ｄ５のパターンＩＤ１Ｄ５０１及びパターン１Ｄ５０４と対応する。

部分パターン１Ｄ６０３は、全体パターン１Ｄ６０２の一部に含まれるパターンである。

部分パターンのウィンドウサイズ１Ｄ６０４は、部分パターン１Ｄ６０３の生起の監視に用いられる区間である。部分パターンのウィンドウサイズ１Ｄ６０４は、監視対象のイベント数であってもよいし、監視時間（例えば１０秒や１分）であってもよい。

レストパターンのウィンドウサイズ１Ｄ６０５は、部分パターン１Ｄ６０３の生起後の監視に用いられる区間である。レストパターンのウィンドウサイズ１Ｄ６０５も、監視対象のイベント数であってもよいし、監視時間であってもよい。

図８の１行目は、全体パターン１Ｄ６０２が「１→１７→１５→８→１６」、部分パターン１Ｄ６０３が「１→１７→１５→８」であり、レストパターンは「１６」である。よって、部分パターン１Ｄ６０３「１→１７→１５→８」が、部分パターンのウィンドウサイズ１Ｄ６０４「６イベント」の区間内で生起した場合、当該部分パターンが生起したと判断してよい。また、レストパターン「１６」が、部分パターンの発生後からレストパターンのウィンドウサイズ１Ｄ６０５「５イベント」の区間内で生起した場合、レストパターンが発生したと判断してよい。

図９は、異常検知結果データ１Ｄ７の一例を示す。異常検知結果データ１Ｄ７は、データ管理部１１８で管理されてよい。

異常検知結果データ１Ｄ７は、異常検知の結果を表すデータである。異常検知結果データ１Ｄ７は、データ項目として、アノマリＩＤ１Ｄ７０１と、開始イベントＩＤ１Ｄ７０２と、終了イベントＩＤ１Ｄ７０３と、パターンＩＤ１Ｄ７０４とを有してよい。

アノマリＩＤ１Ｄ７０１は、異常検知の結果を一意に識別するための値である。

開始イベントＩＤ１Ｄ７０２及び終了イベントＩＤ１Ｄ７０３は、異常を検知した区間の開始と終了のイベントＩＤを表す。

パターンＩＤ１Ｄ７０４は、異常検知に用いられた監視対象パターン１Ｄ６のパターンＩＤ１Ｄ６０１を表す。

図９の１行目は、アノマリＩＤ１Ｄ７０１「０」の異常検知結果は、開始イベントＩＤ１Ｄ７０２「１００００７３」から終了イベントＩＤ１Ｄ７０３「１００００８８」の区間において、パターンＩＤ１Ｄ７０４「３５」に係る異常が検知されたことを示す。なお、ウィンドウをスライドさせて異常を検出するので、アノマリＩＤ「１」のときにも同様にパターンＩＤ「３５」に係る異常が検知されている。

なお、データ管理部１１８は、予測モデルのパラメータを管理してもよい。この場合、データ管理部１１８、予測モデルに適宜対応するパラメータを管理するためデータ構造を有してよい。予測モデルの生成には、リカレントニューラルネットワークが用いられてよい。この場合、モデルのパラメータは、重み行列の集合となる。

＜処理フロー＞
図１０は、監視対象選定及びモデル学習フェーズの処理の一例を示すフローチャートである。

なお、本処理の前に、異常検知装置１１は、被監視装置２１から正常時のログを収集し、データ管理部１１８に、統合後のログ（図４参照）を登録済みであるとする。

まず、ログ記号化部１１２は、正常時の統合後のログの各イベント１Ｄ３を、テンプレートデータ１Ｄ３を用いて記号化し、記号化イベント１Ｄ４を生成する（ステップ１Ｆ１０１）。テンプレートの生成方法については後述する。なお、ログ記号化部１１２は、何れのテンプレートデータ１Ｄ３にも該当しないイベント１Ｄ３については、未知のイベントであるとして、例えば「−１」など、未知を示す適切な記号を割り当ててよい。

次に、監視パターン生成部１１３は、記号化イベントに対して、ＰｒｅｆｉｘｓｐａｎやＡｐｒｉｏｒｉ Ａｌｌなどの頻出系列パターンマイニングを適用し、閾値「Ｃ」以上出現するパターン（つまり頻出系列パターン）を抽出する（ステップ１Ｆ１０２）。本実施形態では閾値「Ｃ」を「３０回」としているが、閾値「Ｃ」は、監視するログや目的に応じて適切に設定されてよい。

次に、監視パターン生成部１１３は、頻出系列パターンから全ての部分パターンを抽出する。そして、監視パターン生成部１１３は、「頻出系列パターンの生起回数／部分パターンの生起回数」が閾値α以上に該当する部分パターンを抽出し、その中から長さが最短の部分パターンを選択する。そして、監視パターン生成部１１３は、その選択した部分パターンを、監視対象パターン１Ｄ６に登録する（ステップ１Ｆ１０３）。この時点では、部分パターンのウィンドウサイズ１Ｄ６０４及びレストパターンのウィンドウサイズ１Ｄ６０５は未定なため、「−１」などの無効を表す値であってよい。また、本実施形態では閾値αを「０．９５」としているが、閾値αは監視するログや目的に応じて適切に設定されてよい。このような部分パターンを選択することにより、比較的早い時点で頻出系列パターンの生起を、比較的高い精度で予測することができるようになる。なお、本実施形態では、監視パターン数を削減するために、１つの部分パターンと頻出系列パターンとの組とを選択しているが、２つ以上の組を選択してもよい。

次に、ウィンドウサイズ決定部１１４は、部分パターンのウィンドウサイズ１Ｄ６０４とレストパターンのウィンドウサイズ１Ｄ６０５とを決定し、監視対象パターン１Ｄ６に登録する（ステップ１Ｆ１０４）。ウィンドウサイズの決定方法については後述する。

次に、予測モデル学習部１１５は、生成した頻出系列パターン、部分パターン、及び、正常時のログを用いて、部分パターンが生起したときに頻出系列パターンが生起する確率を算出するための統計的な予測モデルを学習する。そして、予測モデル学習部１１５は、その学習した予測モデルに係るパラメータを、データ管理部１１８に登録する（ステップ１Ｆ１０５）。そして、本処理を終了する。

例えば、リカレントニューラルネットワークの一種であるＬＳＴＭ（Ｌｏｎｇ ｓｈｏｒｔ−ｔｅｒｍ Ｍｅｍｏｒｙ）で構成される予測モデルを用いる。例えば、リカレントニューラルネットワークにおいて、１ｏｆＫ表現された或るイベントのクラスＩＤを入力と、１ｏｆＫ表現された次のイベントのクラスＩＤを出力とする。そして、ネットワークを、入力側から、全結層、ＬＳＴＭ層、ＬＳＴＭ層、ＬＳＴＭ層、全結層で構成し、最後にソフトマックス関数を介して出力を得る。ネットワークの構成は、監視するログや目的に応じて適切に設定されてよい。予測モデルに係るパラメータは、各層の重み行列の集合であってよい。

なお、別の方法が用いられてもよい。例えば、直接ロジスティック回帰やＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）などの識別モデルが用いられてもよい。例えば、或るイベントを基点にそのイベントからτ個前までのイベントの各クラスＩＤを入力とする。そして、その基点としたイベントの次のイベントから、レストパターンのウィンドウサイズだけ先のイベントまでの区間に、監視対象の頻出系列パターンが生起したか否か（「０」ｏｒ「１」）を判定する。「τ」には、「１０」など、適切な値が設定されてよい。

また、簡単な予測モデルに、ステップ１Ｆ１０３の場合と同様の「頻出系列パターンの生起回数／部分パターンの生起回数」を用いることもできる。予測モデルは、監視するログや目的に応じて適切に選定されてよい。

以上、監視対象選定及びモデル学習フェーズの処理を説明した。本実施形態のように、イベントをいったん記号化し、その記号化イベントにおける頻出系列パターンを監視対象とすることにより、イベントが文字列であっても数値であっても同じように取り扱うことができる。

さらに、頻出系列パターンの抽出において「飛び」を許容することにより、例えば、或るトランザクションに係るイベント列の間に、単発又は別のトランザクションのイベントが紛れ込んでいたとしても、同じパターンとして抽出することができる。

なお、ルールを定めて、登録する頻出系列パターン１Ｄ６を限定してもよい。例えば、システムの構成変更によって発生しないことが自明の特定のパターンを登録しない、というルールを定めてもよい。

図１１は、テンプレート生成処理の一例を示すフローチャートである。

なお、本処理の前に、異常検知装置１１は、被監視装置２１から正常時のログを収集し、データ管理部１１８に、統合後のログ（図４参照）を登録済みであるとする。

まず、ログ記号化部１１２は、正常時の統合後のログの各イベント１Ｄ３における「数値列」、「ＩＰアドレス」、「ＵＲＩ」、「ＭＡＣアドレス」などの典型的な文字列を、「＄ＮＵＭ」、「＄ＩＰＡＤＤＲ」、「＄ＵＲＩ」、「＄ＭＡＣＡＤＤＲ」などの文字列に置換する（ステップ１Ｆ２０１）。

ログ記号化部１１２は、各イベントを、イベントに含まれる単語群のＪａｃｃａｒｄ距離に基づくＷａｒｄ法により、クラスタリングする（ステップ１Ｆ２０２）。クラスタは、距離が指定値（例えば０．５）以下の範囲で結合すると定義されてもよい。また、情報量基準などに基づいて適切なクラスタ数が決定されてもよい。

ログ記号化部１１２は、同じクラスタ番号が割り当たったイベント群について、最長共通部分列を動的計画法（ｓｍｉｔｈ ｗａｔｅｒｍａｎアルゴリズム）等を用いて抽出する。そして、ログ記号化部１１２は、各イベントについて、最長共通部分列の各要素の間に文字列が存在する場合、最長共通部分列の該当する文字の間にワイルドカード（＊）を追加し、テンプレートを生成する。そして、ログ記号化部１１２は、テンプレートを識別するためのクラスＩＤを、「０」からの連番等でテンプレートデータ１Ｄ３に登録し、本処理を終了する（ステップ１Ｆ２０３）。

なお、本実施形態では、ログの単語群のＪａｃｃａｒｄ距離に基づくＷａｒｄ法によりクラスタリングを行っているが、他の方法であってもよい。例えば、同じクラスタに属すイベントに共通する単語群を代表単語群として抽出し、その代表単語群との距離に基づいてクラスタを割り当てても良い。この場合、テンプレートは代表単語群となり、どのクラスタからも遠いイベントを未知のイベントに割り当ててよい。他にも、「ｓｋｉｐｇｒａｍ」や「ＧｌｏＶｅ」等によって単語をベクトル表現化し、それを足し合わせたベクトルをイベントのベクトル表現とし、そのベクトルをＫ−ｍｅａｎｓでクラスタリングし、クラスＩＤを生成しても良い。

また、上記は、「ｓｙｓｌｏｇ」など、テキストを主体としたログを想定したテンプレート生成となっており、数値全般を「＄ＮＵＭ」に変換している。しかし、数値データに対して適当なビンを設定して度数分布を作成し、各ログ中の数値について対応するビンのＩＤを、クラスＩＤとして割り振ってもよい。例えば、数値「１〜１０」にはクラスＩＤ「１」を、数値「１１〜２０」にはクラスＩＤ「２」を割り当ててもよい。

図１２は、ウィンドウサイズを決定する処理の一例を示すフローチャートである。

まず、図１２を用いて、部分パターンのウィンドウサイズを決定する処理について説明する。

ウィンドウサイズ決定部１１４は、図１３の例のように、複数の部分パターンが生起を開始してから終了するまでの区間のイベント数に基づき、度数分布を作成する（ステップ１Ｆ４０１）。

次に、ウィンドウサイズ決定部１１４は、その作成した度数分布におけるイベント数が小さい方から例えば９０％の要素が含まれるところでのイベント数（９０パーセンタイル）を、部分パターンのウィンドウサイズに決定する。そして、ウィンドウサイズ決定部１１４は、監視対象パターン１Ｄ６に、その決定したウィンドウサイズを登録し、処理を終了する（ステップ１Ｆ４０２）。図１３の例では、「５〜１２」のイベント数でパターンが発生し、小さい方から９０％が含まれるイベント数は「１０」であるので、部分パターンのウィンドウサイズを「１０」に決定する。

なお、上記では、イベント数を用いてウィンドウサイズを決定しているが、ログの実際の時刻を用いても良いし、ログの実際の時刻及びイベント数を併用してもよい。

また、上記では、ウィンドウサイズを、小さい方から９０％が含まれるときのイベント数（９０パーセンタイル）としている。しかし、対数正規分布などの統計モデルに当てはめて、その「平均」又は「平均＋３×標準偏差」に最も近い整数値を、ウィンドウサイズに決定してもよい。また、ウィンドウサイズの度数分布から外れ値を除去した部分集合を作成し、その部分集合の中の最長値を、ウィンドウサイズに決定してもよい。

次に、図１２を用いて、レストパターンのウィンドウサイズを決定する処理について説明する。

ウィンドウサイズ決定部１１４は、図１３の例のように、複数のレストパターンが生起を開始してから終了するまでの区間のイベント数に基づき、度数分布を作成する（ステップ１Ｆ４０１）。

次に、ウィンドウサイズ決定部１１４は、その作成した度数分布におけるイベント数が小さい方から例えば９０％の要素が含まれるところでのイベント数（９０パーセンタイル）を、レストパターンのウィンドウサイズに決定する。そして、ウィンドウサイズ決定部１１４は、監視対象パターン１Ｄ６に、その決定したウィンドウサイズを登録し、処理を終了する（ステップ１Ｆ４０２）。

これにより、監視対象の部分パターン及びレストパターンごとに、他のイベントの割り込みを考慮したウィンドウサイズが決定される。

なお、上記では、イベント数を用いてウィンドウサイズを決定しているが、ログの実際の時刻を用いても良いし、ログの実際の時刻及びイベント数を併用してもよい。

また、上記では、ウィンドウサイズを、小さい方から９０％が含まれるときのイベント数（９０パーセンタイル）としている。しかし、対数正規分布などの統計モデルに当てはめて、その「平均」又は「平均＋３×標準偏差」に最も近い整数値を、ウィンドウサイズに決定してもよい。また、ウィンドウサイズの度数分布から外れ値を除去した部分集合を作成し、その部分集合の中の最長値を、ウィンドウサイズに決定してもよい。

図１４は、レストパターンのウィンドウサイズを決定する処理の変形例を示すフローチャートである。

ウィンドウサイズ決定部１１４は、複数の部分パターンが生起を開始してから終了するまでの区間のイベント数と、複数のレストパターンが生起を開始してから終了するまでの区間のイベント数と、に基づく統計モデル（例えば線形回帰モデル）を作成する（ステップ１Ｆ５０１）。

次に、ウィンドウサイズ決定部１１４は、部分パターンのウィンドウサイズに対するレストパターンのウィンドウサイズの決定表を作成する（ステップ１Ｆ５０２）。

この場合、ウィンドウサイズは、部分パターンが生起を開始してから終了するまでの区間のイベント数に応じて動的に変化する。したがって、監視対象パターン１Ｄ６のレストパターンのウィンドウサイズ１Ｄ６０５の代わりに、ステップ１Ｆ５０２で作成した決定表を保持しておき、適宜その決定表を参照してレストパターンのウィンドウサイズを決定してよい。これによれば、多数の割り込みが発生して部分パターンのウィンドウサイズが大きくなると、それに合わせて、レストパターンのウィンドウサイズも大きくなる。

図１５は、監視フェーズの処理の一例を示すフローチャートである。

なお、本処理の前に、異常検知装置１１は、被監視装置２１から監視時のログを収集し、データ管理部１１８に、統合後のログ（図４参照０を登録済みであるとする。また、既に正常時のログに対して、監視対象選定及びモデル学習が行われているとする。

まず、ログ記号化部１１１は、監視対象選定及びモデル学習フェーズの場合と同様に、監視時のログを記号化する（ステップ１Ｆ６０１）。

次に、系列パターン生起予測部１１６は、監視時のログにおける監視対象に選定された各パターンについて、部分パターンが生起しているか否かを判定する（ステップ１Ｆ６０２）。系列パターン生起予測部１１６は、部分パターンが生起していないと判定した場合（ＮＯ）、本処理を終了し、生起していると判定した場合（ＹＥＳ）、ステップ１Ｆ６０３に進む。

ステップ１Ｆ６０２の判定結果がＹＥＳの場合、系列パターン生起予測部１１６は、その生起していると判定した部分パターンを含む頻出系列パターンの生起確率を算出する（ステップ１Ｆ６０２）。

本実施形態では、例えば次のように、リカレントニューラルネットワークの一種であるＬＳＴＭに係る予測モデルを使用して、生起確率を推定する。

まず、リカレントニューラルネットワークの内部状態をいったん初期化し、部分パターンが発生する数十時刻前からリカレントニューラルネットワークにその時刻のイベントのクラスＩＤを入力し、内部状態を更新する。

そして、部分パターンが発生し終わった時刻の次の時刻から、レストパターンのウィンドウサイズの分、逐次サンプルを生成する。すなわち、リカレントニューラルネットワークに或る時刻のクラスＩＤを入力すると、出力として、次の時刻の各クラスＩＤの生起確率が得られる。その生起確率を使用してルーレット選択を行うことにより、予測される次のクラスＩＤを出力する。これを複数回繰り返すことにより、レストパターンのウィンドウサイズ分の予測クラスＩＤ列（予測レストパターンのクラスＩＤ列）が複数個得られる。

そして、部分パターンのクラスＩＤ列と各予測レストパターンのクラスＩＤ列とを連結したクラス列で、監視対象の頻出系列パターンが生起した回数を数える。

最後に、この回数を、予測レストパターンの総数で除算することにより、頻出系列パターンの生起確率を推定することができる。

リカレントニューラルネットワークの一種であるＬＳＴＭを使用することにより、監視対象の部分パターンのウィンドウサイズより以前の情報が自然な形で加味されるので、予測精度が向上し得る。なお、処理負荷を下げる必要がある場合、上記のルーレット選択の部分を、最大の確率を有するクラスＩＤを選択するように変更し、一度だけサンプルを作成してよい。

次に、異常検知部１１７は、ステップ１Ｆ６０２で部分パターンが生起していたパターンに関して、生起確率が閾値「γ」以上であり、かつ、レストパターンのウィンドウサイズ内でレストパターンが生起しているか否か、すなわち、部分パターンと組み合わせて監視対象とした頻出系列パターンが生起しているか否かを判定する。この判定の結果、生起確率が閾値「γ」以上であり、かつ、頻出系列パターンが発生していないパターンが存在する場合（ＹＥＳ）、ステップ１Ｆ６０５に進む。この判定の結果が否定的な場合は（ＮＯ）、本処理を終了する（ステップ１Ｆ６０４）。なお、本実施形態では閾値「γ」を「０．９５」とするが、求められる性能（精度と再現率）に応じて他の閾値に設定してもよい。

ステップ１Ｆ６０４の判定結果がＹＥＳの場合、異常検知部１１７は、そのパターンに関して異常があったと判定する。その場合、異常検知部１１７は、異常のあった箇所、すなわち、部分パターンの開始箇所のイベントＩＤ（開始イベントＩＤ）と、部分パターンの終了箇所にレストパターンのウィンドウサイズの分を進めた箇所のイベントＩＤ（終了イベントＩＤ）と、を抽出する。

そして、異常検知部１１７は、検知したデータごとにアノマリＩＤ１Ｄ７０１を付与しながら、上記の開始イベントＩＤ、終了イベントＩＤ及びパターンＩＤを、異常検知結果データ１Ｄ７に登録する（ステップ１Ｆ６０５）。

そして、異常検知部１１７は、端末１２の表示部１２１に対して、異常検知結果データ１Ｄ７に異常検知結果を登録したことを通知し（ステップ１Ｆ６０６）、本処理を終了する。

端末１２の表示部１２１は、この通知を受けて、各種ログやパターンのデータと、異常検知結果データ１Ｄ７とを表示してよい。すなわち、端末１２は、運用監視者に異常検知結果を提示してよい。

＜ユーザインターフェース＞
図１６は、ログ情報監視画面１Ｇ１の例を示す。ログ情報監視画面１Ｇ１は、端末１２の表示部１２１によって表示されてよい。

ログ情報監視画面１Ｇ１には、パターンリスト１Ｇ１０１と、テンプレートリスト１Ｇ１０２と、ログリスト１Ｇ１０３とが表示されてよい。

パターンリスト１Ｇ１０１０には、監視対象のログに出現する頻出系列パターン１Ｄ５のパターンＩＤ１Ｄ５０１とパターン長１Ｄ５０２と出現回数１Ｄ５０３とが表示されてよい。

テンプレートリスト１Ｇ２０２には、パターンリスト１Ｇ１０１０で選択された頻出系列パターン１Ｄ５のパターン１Ｄ５０４に対応するテンプレートデータ１Ｄ３が表示されてよい。

これらを表示することにより、運用監視者は、どのような頻出系列パターンが異常検知のための監視対象となっているか、及び、それがどのようなログにマッチし得るのかなどを知ることができる。

ログリスト１Ｇ１０３には、イベント１Ｄ２及び記号化イベント１Ｄ４に対応する、イベントＩＤ、日時、クラスＩＤ及びメッセージが表示されてよい。その際、異常が検知されたイベントのクラスＩＤには、図１６の１Ｇ１０３ａに示す「！３７」のように、強調されたり、追加の記号が付されたりしてよい。さらに、そのクラスＩＤには、後述の異常追跡情報表示画面１Ｇ２へのリンクが付与されてよい。これにより、運用監視者は、どのイベントで異常が検知されたかを、容易に知ることができる。

図１７は、追跡情報表示画面１Ｇ２の例を示す。追跡情報表示画面１Ｇ２は、端末１２の表示部１２１によって表示されてよい。

図１７の例の画面は、前述したログ情報監視画面１Ｇ１において異常が検知されたイベントからリンクされた画面であってよい。すなわち、図１７の例の画面には、そのリンク元の異常に関する内容が表示されてよい。

追跡情報表示画面１Ｇ２は、異常パターンＩＤ選択タブ１Ｇ２０１で区切られてよい。そのタブで区切られた中に、テンプレートリスト１Ｇ２０２と、異常検知個所付近のログリスト１Ｇ２０３とが表示されてよい。

異常パターンＩＤ選択タブ１Ｇ２０１は、異常を検知した監視対象のパターンのパターンＩＤ分だけ生成されてよい。図１７の例は、パターンＩＤ「１」、「１２」、「２１」のパターンに関する異常が検知されたことを表している。このタブごとに、異常を検知したパターンが異なり、表示される内容も異なる。

テンプレートリスト１Ｇ２０２には、異常を検知した監視対象パターンに関するクラスＩＤとテンプレートとのリストが表示されてよい。

異常検知個所付近のログリスト１Ｇ２０３には、異常検知結果データ１Ｄ７の開始イベントＩＤから終了イベントＩＤまでの区間のイベントが表示される。図１７の例では、パターンＩＤ「１」の部分パターンに該当するクラスＩＤ「１」、「１７」、「１５」、「「８」のイベントと、レストパターンのウィンドウサイズであるその後の５つ分のイベントとが表示されている。

なお、頻出パターンに基づく時系列の異常検知の観点から、何れの時点まで正しく動作していたと考えられるかを判別できるように、頻出系列パターンに該当するイベントのクラスＩＤには、図１７に示す「＊１＊」や「＊１７＊」のように、強調や追加の記号が付与されてよい。

図１８は、異常検出回数表示画面１Ｇ３の例を示す。異常検出回数表示画面１Ｇ３は、端末１２の表示部１２１によって表示されてよい。異常検出回数表示画面１Ｇ３は、ログ情報監視画面１Ｇ１と合わせて利用されてもよいし、単独で利用されてもよい。

異常検出回数表示画面１Ｇ３には、異常検出回数グラフ１Ｇ３０１と、異常パターン選択ボックス１Ｇ３０２とが表示されてよい。

異常検出回数グラフ１Ｇ３０１には、異常パターン選択ボックス１Ｇ３０２で指定されたパターンに関する一定時間幅の単位での異常検出回数の度数分布（ヒストグラム）が表示されてよい。図１８の例では、異常パターン選択ボックス１Ｇ３０２で「すべて」が選択されているので、「すべて」の監視対象のパターンが対象となっている。異常パターン選択ボックス１Ｇ３０２は、各種の監視対象のパターンや、その組み合わせを選択可能であってよい。また、異常パターン選択ボックス１Ｇ３０２において、組み合わせやすべてのパターンが選択されている場合、その内訳が分かるように色分けなどがされてもよい。

本実施形態では、度数分布のビン幅（時間幅）を１時間とする。例えば、１つのビン幅（時間幅）における異常検出回数は、５月１２日の午後９：００では、５月１２日の午後８：３０〜５月１２日の午後９：３０までに検出された異常の総数に対応する。なお、システムや運用監視者の要求に応じて、時間幅は、３０分単位、１５分単位などに変更されてもよい。

異常検出回数グラフ１Ｇ３０１には、閾値１Ｇ３０１ａが設定されてよい。異常検出回数が閾値１Ｇ３０１ａ以上である箇所は、１Ｇ３０１ｂに示すように、強調表示されてよい。本実施形態では、閾値１Ｇ３０１ａには、過去１週間の平均の２倍を設定する。ただし、閾値１Ｇ３０１ａに係る期間や倍数は変更されてもよいし、閾値１Ｇ３０１ａには運用監視者が固定の値を予め設定してもよいし、時間を考慮して変動を統計モデルで学習しておき閾値１Ｇ３０１ａを変動させてもよい。

本実施形態によれば、複数を統合したログから、異常を検知することができる。よって、運用監視者の負担を低減することができる。

また、運用監視者が、上述のウィンドウサイズを手動で設定することは難しい。例えば、ウィンドウサイズを長くし過ぎると、別のイベント列と合わせて正常と判断されてしまおそれがあり、ウィンドウサイズを短くし過ぎると、別のイベント列と合わせた結果、その区間で正常なイベント列が最後まで出力されずに異常なイベント列であると判断されてしまうおそれがある。しかし、本実施形態では、監視対象パターンごとに最適なウィンドウサイズが自動的に決定されるので、固定のウィンドウサイズを用いる場合に比べて、高い異常検知性能（精度及び／又は再現率）を実現することができる。

また、本実施形態は、単に異常があったことを提示するだけでなく、異常がどのような頻出系列パターンに関して発生したものであり、また、その頻出系列パターンを構成するイベントのどこまでは正常に生起していたかなどを、認識可能な態様で提示する。これにより、運用監視者は、単に異常があったことだけでなく、どのような原因で異常が発生したのかを究明するために有用な情報を得ることができる。すなわち、運用監視者が、より短時間で異常の原因を究明できる可能性が高まる。

上述した実施形態は、本発明の説明のための例示であり、本発明の範囲を実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１：異常検知システム ２：監視対象システム １１：異常検知装置 １２：端末 ２１：被監視装置

Claims (14)

1. 監視対象システムの異常を検知する異常検知システムであって、プロセッサとメモリを備え、
   前記プロセッサは、
   前記監視対象システムが出力したログに含まれる時系列のイベントを、所定のルールに基づいて記号化イベントに変換する記号化手段と、
   前記記号化手段によって記号化された正常時のログに基づいて、同じパターンで出現する記号化イベント列を頻出パターンとして学習する学習手段と、
   前記記号化手段によって記号化された監視時のログにおいて前記頻出パターンが生起しているか否かに基づいて、異常の発生の有無を検知する異常検知手段と、を実行する
   異常検知システム。
2. 前記異常検知手段は、
   前記頻出パターンを構成する記号化イベント列のサイズに基づいて、前記記号化された監視時のログから、前記頻出パターンが生起しているか否かの検知対象とする記号化イベント列を抽出する
   請求項１に記載の異常検知システム。
3. 前記異常判定手段は、
   前記抽出した検知対象の記号化イベント列において、前記頻出パターンの一部である部分パターンが生起しており、且つ、前記部分パターンが生起したときに前記部分パターンを含む前記頻出パターンが生起する確率が所定の閾値以上であるにも関わらず、前記頻出パターンの前記部分パターンの後に出現するパターンであるレストパターンが出現していない場合、異常有りと判定する
   請求項２に記載の異常検知システム。
4. 前記プロセッサは、
   前記記号化された正常時のログに基づいて、前記記号化された監視時のログから部分パターンの生起の判定区間に関するサイズである部分パターンのウィンドウサイズを決定するウィンドウサイズ決定手段、をさらに実行する
   請求項３に記載の異常検知システム。
5. 前記ウィンドウサイズ決定手段は、
   前記部分パターンが生起したときに当該部分パターンを含む前記頻出パターンが生起する確率が所定の閾値以上である複数の部分パターンのサイズの内の最小サイズに基づいて、前記ウィンドウサイズを決定する
   請求項４に記載の異常検知システム。
6. 前記ウィンドウサイズ決定手段は、
   複数の頻出パターンのイベント数の度数分布における所定の２つのパーセンタイルの間のイベント数に基づいて、前記ウィンドウサイズを決定する
   請求項４に記載の異常検知システム。
7. 前記ウィンドウサイズ決定手段は、
   複数の頻出パターンのイベント数の度数分布を所定の統計モデルにフィッティングし、その統計モデルの平均値に関する値に最も近いイベント数に基づいて、前記ウィンドウサイズを決定する
   請求項４に記載の異常検知システム。
8. 前記学習手段は、
   前記記号化された正常時のログを用いて、前記部分パターンが生起したときに前記部分パターンを含む前記頻出パターンが生起する確率を、ＬＳＴＭ（Ｌｏｎｇ ｓｈｏｒｔ−ｔｅｒｍ Ｍｅｍｏｒｙ）に係る予測モデルとして学習する
   請求項３に記載の異常検知システム。
9. 前記学習手段は、
   前記記号化された正常時のログを用いて、前記部分パターンが生起したときに前記部分パターンを含む前記頻出パターンが生起する確率を、統計モデルとして学習する
   請求項３に記載の異常検知システム。
10. 前記記号化手段は、
    正常時のログのイベント群に基づいて生成された複数のクラスタに共通する語に基づいてテンプレートを生成し、
    監視時のログのイベントに対して、
    或るテンプレートが適合する場合、その適合するテンプレートに基づく記号を割り当て、
    何れのテンプレートとも適合しない場合、未知のイベントである旨を示す記号を割り当てる
    請求項１に記載の異常検知システム。
11. 前記プロセッサは、
    各頻出パターンのサイズ及び出現回数を表示するＧＵＩを生成するＧＵＩ生成手段、をさらに実行する
    請求項２に記載の異常検知システム。
12. 前記プロセッサは、
    前記監視時のログを出力すると共に、異常有りと判定されたイベントを他のイベントと区別可能な態様で表示するＧＵＩを生成するＧＵＩ生成手段、をさらに実行する
    請求項２に記載の異常検知システム。
13. 前記ＧＵＩ生成手段は、
    前記異常有りと判定されたイベントに当該イベントの異常に関する情報を含むＧＵＩへのリンクを付与し、
    前記リンク先のＧＵＩとして、前記異常有りと判定されたイベントに関連する頻出パターン及び当該イベントを含む監視時のログを表示するＧＵＩを生成する
    請求項１１に記載の異常検知システム。
14. コンピュータが、監視対象システムの異常を検知する機能を提供する異常検知方法であって、
    記号化手段が、前記監視対象システムが出力したログに含まれる時系列のイベントを、所定のルールに基づいて記号化イベントに変換し、
    前記学習手段が、前記記号化手段によって記号化された正常時のログに基づいて、同じパターンで出現する記号化イベント列を頻出パターンとして学習し、
    前記異常検知手段が、前記記号化手段によって記号化された監視時のログにおいて前記頻出パターンが生起しているか否かに基づいて、異常の発生の有無を検知する
    異常検知方法。

Images