JP6280862B2 - イベント分析システムおよび方法 - Google Patents

Description

本発明は、鉄道や電力等の社会インフラのシステムやその設備の保守、障害対応等におけるイベント分析システムおよびイベント分析方法に関する。

昨今、鉄道の乗り入れや電力融通など、社会インフラは大規模化と複雑化が進みつつあり、障害対応や保守のコスト増大、熟練者不足が問題となってきている。また、社会インフラに係るシステムが、インターネット等の公衆通信ネットワークに接続されることが一般化してきた結果、サイバー攻撃など新たな脅威も生まれている。これらを背景として、従来から開発・実用化が進められてきたタービン等のコンポーネント単位の障害分析に加え、コンポーネントを制御する計算機に起因する障害や計算機が出力するデータから分析できる障害などのシステムレベルの障害に対する対応迅速化が求められている。

一般的に計算機では、社会インフラの状態を計測するセンサ値のように、定期的に計測される時系列の数値データではなく、不定期に発生するOSやミドルウェアの警告やエラー、コマンドの実行結果、あるいは、アプリケーションの内部ステート遷移や動作履歴などに関する時系列の文字列データ、いわゆるログが分析対象の大半を占める。

システムレベルの障害に対応するために、特許文献１では、障害等のイベントを発生させる原因を予め定義し、発生原因間の遷移を有限オートマトンでモデル化し、観察されるイベントの生成確率が最も高くなる発生原因の状態遷移を出力する技術が開示されている。これによって、定義した発生原因の発生過程を用いた原因分析や将来のイベント発生予測をユーザに提示することができる。

特開２０１１−１７５５０４号公報

しかしながら、特許文献１記載の技術を適用するためには、イベントの発生原因を装置開発者が予め適切に定義する必要がある。ところが、複数のコンポーネント（装置や設備等の社会インフラを構成する要素）に複数の計算機を接続したシステムでは、ある計算機で発生した障害の原因がネットワーク上の他のコンポーネントに起因する等、イベント(障害などのシステムの状態)の発生原因の候補が膨大となり、予めすべてを定義することが困難である。従って、イベントの発生原因が特定できないばかりか、例えば発生原因が特定できないイベントを他の発生原因から発生したと判定することになりかねないため、発生原因の推定精度が悪化する可能性がある。

一方、発生原因は適切に定義されているが、実際には発生原因に対応するイベントが観測できない状況もある。例えば、ログとしては出力したものの、ディスクの記憶容量やネットワークリソースの制約から、出力したログを破棄している場合等に、イベントが観測できない状況が生じる。このような場合、前述とは逆にある発生原因に対応させるイベントが観測できないため、他のイベントを対応させることとなり、発生原因を分析しても、発生するイベントを正しく解釈できなくなる可能性がある。

このような状況にあっては、システムの運用開始や改修にかかる、障害検知や分析などに要する時間とコストが多大になる。そこで、監視対象システムの障害の発生原因を事前に定義する必要のないイベント分析システムおよび方法が必要とされる。

開示するイベント分析システムは、監視対象システムの稼働時の第１のイベント列に基づき第１のイベントを予測する局所予測モデルを予め学習する局所予測モデル学習プロセス、監視対象システムの第２のイベント列を監視し、監視した第２のイベント列に含まれる第２のイベントの観測結果と、局所予測モデルを用いて予測した第１のイベントの予測結果とが不一致の第２のイベントを抽出する異常検知プロセス、および、第２のイベントの抽出に応答して、監視した第２のイベント列に含まれ、観測結果を生じさせる、第２のイベントの直前に発生した第３のイベントを起点としてバックトレースした第１のイベントグラフを作成する障害分析支援プロセスを有する。

開示するイベント分析システムによれば、監視対象システムからのイベントに基づく局所予測モデルを用いて、監視対象システムの異常発生に対応したイベントを分析できるので、障害検知や分析などのシステムの運用開始や改修にかかる時間とコストを削減できる。

イベント分析システムの構成図である。 イベント列の例である。 局所予測モデルパラメータの例である。 モデル予測精度データの例である。 イベントグラフデータの例である。 ノードイベントの例である。 事例データの例である。 特徴関数定義の例である。 局所予測モデル学習プロセスの処理フローチャートである。 局所予測モデルの学習の処理フローチャートである。 障害分析支援プロセスの処理フローチャートである。 イベントグラフの作成の処理フローチャートである。 事例登録プロセスの処理フローチャートである。 事例提示プロセスの処理フローチャートである。 イベントグラフ表示画面の例である。 事例データ表示画面の例である。

本実施形態は、鉄道や電力等の社会インフラのシステム（監視対象システムと呼ぶ）が稼働中に出力するログに基づいて、障害の検知、対応支援、および事例提示のためのイベント（監視対象システムの状態）を分析するシステムの例である。詳細な説明に先立って、本実施形態のイベント分析システムの概略を説明する。

イベント分析システムは、モデル学習、障害分析支援、事例提示の3つの機能（プロセス）を備える。モデル学習は、監視対象システムから正常時のログを収集、解析することで得られるイベント列からイベントの変化を局所的に予測する局所予測モデルを学習する。

障害分析支援は、監視対象システムの異常状態を検知し、その異常状態に至る過程を分析し、その分析結果を保守員やエンジニアに提示する。具体的には、次のように障害分析を支援する。イベント分析システムは、局所予測モデルを用いてイベントの変化を予測し、予測結果と観測されたイベントとの乖離（一致の有無）を監視する。乖離がある（不一致の）場合、イベント分析システムは、観測されたイベントを障害と判定し、抽出する。この判定は、一般的な社会インフラなどの監視対象システムは状態遷移ベースで作られ、タイミングは異なっても状態遷移過程は同じであるので、予測と異なる場合、監視対象システムの異常な挙動である可能性が高いことに基づく。次に、抽出したイベントの直前に発生したイベントを起点にイベントを遡って（バックトレースして）、関連するイベントを抽出し、抽出したイベントを連結することでイベントグラフを生成する。そして、障害に対応する保守員やエンジニアにこのイベントグラフを提示する。このイベントグラフは、障害の発生に寄与した可能性が高いイベントを連結したものであるため、保守員やエンジニアが、障害発生に至る流れを把握し、根本的な原因を発見することに役立つ。

事例提示は、障害分析支援によって生成された、障害発生に至る可能性のあるイベントグラフをキーにして、保守員やエンジニアが予め登録した障害原因と対策内容に関する事例データを検索し、検索結果に基づいて障害への対策を提示する。保守員やエンジニアが事例データを登録する際、事例データと関連するイベントを指定しておく。イベント分析システムは、指定されたイベントからイベントグラフを生成し、事例データと対応付けて登録しておく。その上で、イベント分析システムは、監視対象システムから抽出されるイベントに基づいてイベントグラフを生成し、登録されているイベントグラフとの類似を監視する。イベント分析システムは、類似したイベントグラフを見つけた場合、保守員やエンジニアに、生成したイベントグラフと対応する事例データを提示する。すなわち、イベントグラフを事例データのキーとして、監視対象システムの稼働時に生成したイベントグラフに基づいて事例データを検索し、検索した事例データを生成したイベントグラフと対応させて提示する。これによって、既知の障害に類似する障害であれば、保守員やエンジニアが分析に時間を要することなく対策できる。

図１は、イベント分析システムの構成図である。イベント分析システムは、監視対象システム１のイベントを監視するイベント監視装置２、分析用計算機３、および操作端末４を備える。監視対象システム１とイベント監視装置２は、監視対象システム１内の制御用LAN(Local Area Network)等の制御用ネットワーク１４を介して接続される。イベント監視装置２、分析用計算機３、および操作端末４は、インターネット等または自営網などのネットワーク５を介して接続される。

なお、図１に示すように、典型的なイベント分析システムでは、イベント監視装置２は、監視対象システム１が設置された現地サイトに置かれ、分析用計算機３はデータセンターなどに設置される。一方、操作端末４は、現地サイトの保守員と保守拠点のエンジニアが使うために、現地サイトと保守拠点との双方に設置される。なお、これら構成および配置は一例であって、すべて現地サイトに置くことも可能であるし、後述のイベント監視装置２の一部機能（収集解析部、転送部）を除いて保守拠点に集約することも可能である。また、イベント監視装置２、分析用計算機３、および操作端末４がネットワークで接続されていないシステムの場合、USB（Universal Serial Bus）メモリ等の記憶媒体を介してイベントや局所予測モデルのパラメータ（後述）を受け渡す形態を採ってもよい。

監視対象システム１は、様々なシステムであり、その形態も様々であるが、センサやアクチュエータを持った設備１１、設備１１の状態をセンサを介して監視し、設備１１を制御するコントローラ１２、およびコントローラ１２を統括する制御用計算機１３を備え、これらは制御用ネットワーク１４を介して接続される。なお、図示する構成要素は一例であって、設備11などの要素数は増減してもよく、一つの制御用ネットワーク１４で接続されていても、階層化された制御用ネットワーク１４で接続されていてもよい。

図１を用いて、各装置の構成を説明する。イベント監視装置２は、収集解析部２１、異常検知部２２、および事例検索部２３の各処理部、並びに、短期イベント記憶部２４、およびパラメータ記憶部２５の各記憶部を備えるコンピュータである。

収集解析部２１は、監視対象システム１のコントローラ１２、制御用計算機１３、および制御用ネットワーク１４（ログ出力するネットワーク機器）からログを収集し、収集したログを解析して時系列のイベント列を生成し、分析用計算機３に送信する。異常検知部２２は、分析用計算機３から受信した局所予測モデルのパラメータに基づき監視対象システム１の異常状態を検知する。事例検索部２３は、分析用計算機３から受信したイベントグラフに対応する、事例データを検索する。短期イベント記憶部２４はイベントを格納する。短期イベント記憶部２４はイベントを、分析用計算機３に送信するまで一時的に格納するバッファである。パラメータ記憶部２５は、局所予測モデルのパラメータ、事例データなどを格納する。

分析用計算機３は、モデル学習部３１、イベントグラフ作成部３２、および操作管理部３３の各処理部、並びに、イベント記憶部３４、モデル記憶部３５、および事例記憶部３６の各記憶部を備えるコンピュータである。

モデル学習部３１は、イベント監視装置２が生成したイベント列から監視対象システム１の正常時の局所予測モデルを生成する。イベントグラフ作成部３２は、起点となるイベントから遡り（バックトレースして）、監視対象システム１の異常状態を示すイベントの発生に至るまでの、監視対象システム１の局所予測モデル上で異常状態の発生に寄与するイベントを抽出し、抽出したイベントを連結することでイベントグラフを作成する。操作管理部３３は、操作端末４への表示情報の作成や、操作端末４からの事例データを登録する。

イベント記憶部３４は、イベント監視装置２から受信したイベントを格納する。モデル記憶部３５は、局所予測モデルのパラメータ等を格納する。事例記憶部３６は、事例データおよびそれに対応するイベントグラフ等を格納する。

操作端末４は、分析用計算機３で作成された表示情報の表示や、事例データを入力する。

なお、以上の各処理部及び各記憶部の配置は一例であって、他の装置上にあっても、複数の装置上に配置されてもよい。例えば、異常検知部２２が分析用計算機３にあってもよいし、イベントグラフ作成部３２がイベント監視装置２に配置されてもよい。

図２は、短期イベント記憶部２４およびイベント記憶部３４が格納するイベント列１００（イベントが一つの場合もイベント列と呼ぶ。）の例である。イベント列１００は、監視対象システム１から収集したログを解析することで得られ、サイトID１０１、時刻１０２、イベントID１０３、および詳細データ１０４を含む。サイトID１０１及びイベントID１０３は、それぞれ現地サイト及びイベントを識別するための識別子である。図２には、ある現地サイトSite1の通信ミドルウェアの通信ログの例として、詳細データ１０４に「2014/9/21 12:23:14.1034 SEND TYPE=xxx DATA=yyy」を示している。このようなイベント列１００を発生させるログの場合、イベント列１００は、サイトID１０１にSite1を格納し、ログに含まれる時刻部分（詳細データ１０４の時刻部分）を時刻１０２に格納し、「装置名.通信ミドルウェアの名前.ログ名.SEND」等に対応してあらかじめ定められた識別子をイベントID１０２に格納し、ログ全体、もしくは不要な箇所を削除したログの一部の文字列を詳細データ１０４に格納する。

このように、イベント（図２のレコード）の時系列の連なりがイベント列である。前述したように、イベントが一つの場合もイベント列と呼ぶ。なお、短期イベント記憶部２４は現地サイトのイベントを格納するが、イベント記憶部３４は、分析用計算機３に接続する全ての現地サイトのイベントを格納する。

図３は、パラメータ記憶部２５およびモデル記憶部３５が格納する局所予測モデルパラメータ２００の例である。詳細は後述するが、イベントの局所予測モデルにはロジスティック回帰モデル（２値の場合の対数線形モデル）を用いる。このため、イベントの特徴（図８を用いて後述）に対する重みベクトルが局所予測モデルのパラメータである。局所予測モデルパラメータ２００は、サイトID２０１、イベントID２０２、特徴ID２０３、および重み２０４を含む。サイトID２０１及びイベントID２０２は、それぞれ現地サイト及びイベントを識別するための識別子であり、特徴ID２０３は局所予測モデルに対応するイベントの特徴を識別するための識別子である。局所予測モデルは、サイトID２０１とイベントID２０２との対によって特定される。

なお、他のモデルを用いる場合は、適宜パラメータも変更する。また、パラメータ記憶部２４は自サイトに関係するパラメータを格納するが、モデル記憶部３５は、分析用計算機に接続する全ての現地サイトのパラメータを格納する。

図４は、モデル記憶部３５が格納するモデル予測精度データ３００の例である。モデル予測精度データ３００は、サイトID３０１、イベントID３０２、及び予測精度３０３を含む。サイトID３０１及びイベントID３０２は、それぞれ現地サイト及びイベントを識別するための識別子である。詳細は後述するが、予測精度３０３は、イベント列から算出された、局所予測モデルの予測精度を表す。

図５は、パラメータ記憶部２５および事例記憶部３６が格納するイベントグラフデータ４００の例である。イベントグラフデータ４００は、イベントの発生過程を表現するイベントグラフのエッジ情報であり、グラフID４０１、親ノードID４０２、子ノードID４０３、連結タイプ４０４、重み４０５を含む。グラフID４０１は、イベントグラフを識別するための識別子である。親ノードID４０２および子ノードID４０３はノードを識別するための識別子であり、イベントの発生をバックトレースするので、子ノードID４０３のイベントが親ノードID４０２のイベントを発生させることを意味し、親ノードID４０２および子ノードID４０３のそれぞれは図６のノードイベント５００で定義される。連結タイプ４０４は、エッジの導出過程（子ノードID４０３のイベントから親ノードID４０２のイベントへの状態遷移）に基づいて設定される。重み４０５は、局所予測モデルの予測に用いられる。イベントグラフデータ４００の詳細は、イベント分析システムの動作説明等において後述する。

図６は、パラメータ記憶部２５および事例記憶部３６が格納する、イベントグラフのノードとなるノードイベント５００の例である。ノードイベント５００は、イベントグラフのノードとイベントの対応を示すデータであり、ノードID５０１、サイトID５０２、時刻５０３、イベントID５０４を含む。ノードID５０１が、イベントグラフ４００の親ノードID４０２または子ノードID４０３と対応し、サイトID５０２、時刻５０３、およびイベントID５０４が、イベント列１００のサイトID１０１、時刻１０２、イベントID１０３と対応する。

図７は、パラメータ記憶部２５および事例記憶部３６が格納する事例データ６００の例である。事例データ６００は、操作端末４を介して、保守員やエンジニアが障害を発見、解析、対策後に、すなわち発生した障害に関して入力するデータであって、事例ID６０１、サイトID６０２、グラフID６０３、内容データ６０４を含む。事例ID６０１、サイトID６０２、及びグラフID６０３は、それぞれ、事例データ、現地サイト及びイベントグラフを識別するための識別子である。事例ID６０１とサイトID６０２との対で事例データが特定される。内容データ６０４は、保守員やエンジニアによって入力されるデータであり、典型的には「[状況]マシン2のプロセスが異常終了、[原因]追加したマシンの性能がHUBの性能を超えパケットロス、[対策]HUBを最新型に変更」といった状況、原因、対策に関する情報が入力される。なお、この入力項目を含むフォーマットは、対象のシステムに応じて適宜変更される。グラフID６０３は、内容データ６０４に対応したイベントグラフを表すので、グラフID６０３で識別されるイベントグラフをキーにして、稼働中の監視対象システム１のイベント列（グラフID６０３で識別されるイベントグラフに対応する障害に至るイベント列）から事例データが検索される。

図８、モデル記憶部３５が格納する特徴関数定義７００の例である。特徴関数定義７００は、局所予測モデルの入力となる特徴量を生成するための特徴関数の定義データであって、特徴ID７０１と、特徴関数定義７０２を含む。特徴ID７０１は、特徴関数定義７０２の定義を識別するための識別子である。

本実施形態では、特定のイベントの発生や、特定のイベント列の発生順序または発生タイミングを特徴量として用いる。一般に特徴関数は、引数（または入力）としてのイベント列に対して数値（１又は０）を返す関数であって、前述以外の定義、例えば、単に複合イベントの発生や、イベントIDだけでなく、イベントの詳細データに含まれる特定キーワード等を考慮した関数を定義することができる。

以下、イベント監視装置２および分析用計算機３の連携により各プロセスの処理を説明するが、説明を簡単にするために、図２〜図８の各データを各記憶部に格納する処理を必ずしも明示していない。

図９は、局所予測モデル学習プロセスの処理フローチャートである。局所予測モデル学習プロセスの処理は、収集解析部２１およびモデル学習部３１の連携により実行される。

収集解析部２１は、監視対象システム１から、OSやミドルウェアの警告やエラー、コマンドの実行結果、アプリケーションの内部ステート遷移や動作履歴などに関する時系列の文字列データであるログを収集する（S１０１）。収集解析部２１は、収集したログを解析し、自サイトのサイトID１０１に対応させ、ログの内容（アラームであれば、エラーレベルやそのID等）に応じた時刻１０２、イベントID１０３及び詳細データ１０４を付与したイベント１００を抽出し、短期イベント記憶部２４に格納する（S１０２）。なお、短期イベント記憶部２４に格納されたイベント列１００は、分析用計算機３への送信完了（イベント記憶部３４への格納完了）に応じて削除される。

モデル学習部３１は、定期的（１日１回の頻度等）にイベント監視装置の短期イベント記憶部２４からのイベント列１００を収集し、イベント記憶部３４に格納する（S１０３）。モデル学習部３１は、監視対象システム１の正常時のイベント列１００を用いて、イベントの変化を局所的に予測する局所予測モデルを学習し、局所予測モデルパラメータ２００を作成し、作成した局所予測モデルパラメータ２００をモデル記憶部３５に格納する（S１０４）。この処理については、後述する。

モデル学習部３１は、交差検定等を用いて作成した局所予測モデルの予測精度を算出し、モデル予測精度データ３００を作成し、モデル記憶部３５に格納する（S１０５）。モデル学習部３１は、作成した局所予測モデルパラメータ２００と、モデル予測精度データ３００をイベント監視装置２に送信する。イベント監視装置２は、受信した局所予測モデルパラメータ２００とモデル予測精度データ３００をパラメータ記憶部２５に格納し、処理を終える（S１０６）。

なお、監視対象システム１の運用時（正常時）のイベント列からモデルを学習する例を述べたが、実際には、監視対象システム１の出荷前テストや出荷した後の現地での試運転で収集されたイベント列を用いて学習してもよい。

図１０は、モデル学習部３１による局所予測モデルの学習（S１０４）の処理フローチャートである。ここでは、局所予測モデルとしてL1正則化付のロジスティック回帰を用いる。説明に先立って定義を説明する。

イベント集合Eは、イベント列１００に対応し、E = {E_i,t | i=1,2,3,…,I, t=1,2,3,…,T}と記載する。ここで、E_i,tはイベント集合の要素であり、iはサイトID１０１とイベントID１０３との対（以下では、イベントID１０３を代表させ、「イベントIDがi」などと記載する。）を示し、tは時刻１０２を示す。時刻tにイベントIDがiのイベントが発生していない場合、E_i,tは値Emptyが対応付けられる。そうでないならば（発生しているならば）、E_i,tはサイトID１０１、イベントID１０３、時刻１０２に対応するイベント列１００のレコードが対応付けられる。

ある時刻tsから他の時刻te-1までのイベントの部分集合をE[ts:te]={E_i,t | i=1,2,3,…,I, t=ts,…,te}と記載する。

イベント変化C(i, t)は、E_i,tがEmptyでなく、K時刻前（t-K：t-1、t-2、・・・のように離散的な時刻を表す。以下も同様の表現を用いる。）までに発生したEmptyでないイベントの中で最新のイベントE_i,t’と、イベントIDが同じでない場合に1、それ以外は0を返す関数とする。ここで、Kは予め定義しておく定数であって、本実施形態では、各イベントIDについてE_iの平均発生間隔の２倍とする。ただし、それ以外の値、例えば3分、等の定数であってもかまわない。

特徴ベクトルΦ(E([ts:te]))は、E[ts:te]における特徴を表し、Φ(E[ts:te])=[φ_1(E([ts:te])), …, φ_k(E([ts:te])), … , φ_K(E([ts:te]))]と記載する。ここで、φ_k(・)は特徴量関数であり、φ_k(E[ts:te])は、E[ts:te]のk番目の特徴量を表す。

重みベクトルW_iは、イベントIDがiの局所予測モデルの重みベクトルであり、W_i=[W_i,0, W_i,1, … , W_i,K]と記載する。

以上の定義に従って、局所予測モデルの学習の処理を説明する。モデル学習部３１は、学習回数のカウンタcntに0を代入し、各W_iに乱数を設定する（S２０１）。モデル学習部３１は、時刻変数tに1からTまでの値をランダムに設定する（S１０２）。モデル学習部３１は、特徴量Φ([E[t-τ,t])を算出する。ここでτは定数であって、各イベントIDについてE_iの平均発生間隔とする（S２０３）。モデル学習部３１は、イベントIDに対応する変数iに0を代入する（S２０４）。

モデル学習部３１は、入力を特徴量Φ([E[t-τ,t])、出力をC(i, t)とするL1正則化付ロジスティック回帰モデルとして表現されたイベントiの局所予測モデルの重みベクトルW_iを更新する（S２０５）。ここで、特徴量Φ([E[t-τ,t])を生成するために、特徴関数定義７００に登録された特徴関数φ_kの定義７０２を用いる。具体的には、例えば、あるイベントIDのイベントが発生したならば１、そうでなければ０、というような単一イベントの関係に基づく特徴や、あるイベントIDのイベントが発生した2秒後以内に他のイベントIDのイベントが発生したならば１、そうでなければ０、というような複数のイベントとイベントの順序関係に基づく特徴を用いる。重みベクトルW_iの更新には、勾配法や劣勾配法で更新した重みベクトルと正則化項の最適化によって最終的な重みベクトルを決定するForward Backward Splittingを用いる。これによって、スパースな重みベクトルW_iを得ることができる。

モデル学習部３１は、変数iを1インクリメントする（S２０６）。モデル学習部３１は、すべてのiについてS２０５〜S２０６を実行したかを判定し、実行した場合はS２０８に移り、そうでない場合は、S２０５に戻る（S２０７）。

S２０７において、すべてのiについて実行した場合、モデル学習部３１はカウンタcntを1インクリメントする（S２０８）。モデル学習部３１は、cntが予め定められた回数N未満かを判定し、未満の場合、S２０２に戻り、そうでない（以上の）場合は、処理を終了する（S２０９）。

説明した局所予測モデルは、イベントの明示的な因果関係や原因を扱う必要がなく、モデル学習部３１が、イベント監視装置２を介して監視対象システム１から取得したイベント列を用いるので、対象とする監視対象システム１に関して知識をほとんど持たない人でも、局所予測モデルの構築が可能である。また、重みベクトルのスパース化によって後述の処理で生成されるイベントグラフが簡素化できる。この結果、保守員やエンジニアにわかりやすいイベントグラフを提示できる。また、事例検索のためにイベントグラフとイベント列の相関を求めるための計算量も小さくできる。

以上は、ロジスティック回帰モデルを用いた例を示したが、多値の変化を扱う場合には、前記のような入力の特徴量と多値のイベント変化の組合せとして表現される特徴関数（素性関数）に関する対数線形モデルを用いることができる。さらに、他の予測モデル、例えばCW(Confidence-Weighted)やAROW(Adaptive Regularization of Weight Vectors)等の識別モデルCRF(Conditional Random Fields)等の構造予測が可能なモデルを用いてもよい。また、モデルの更新方法についても、単なる勾配法や劣勾配法を用いるだけであってもよいし、その他の手法を用いても良い。

図１１は、障害分析支援プロセスの処理フローチャートである。障害分析支援プロセスの処理は、収集解析部２１、異常検知部２２、イベントグラフ作成部３２、および操作管理部３３の連携により実行される。障害分析支援プロセスの処理は、新しいイベントに応じて又は定期的に実行される。収集解析部２１は、前述の処理（S１０１、S１０２）と同様に、監視対象システム１からログを収集し、最新のイベント列１００を短期イベント記憶部２４に格納する。ここで、説明を簡単にするために、格納された（観測された）イベント列１００をイベントID＝１００、時刻tとする。異常検知部２２が、時刻t-1に観測したイベントをもとに、局所予測モデルを用いて時刻tのイベントを予測する（S３０１）。

異常検知部２２は、予測した時刻ｔのイベントの予測結果と観測した時刻ｔのイベントID=100（観測結果）が一致しているか否かを判定する。一致していれば処理を終了し、一致していなければS３０３に移る（S３０２）。予測結果と観測結果が一致していない場合、異常検知部２２は、分析用計算機３に監視対象システム１の異常を通知する（S３０３）。イベントグラフ作成部３２は、異常を通知したイベント監視装置２から最新のイベント列１００を収集する（S３０４）。最新のイベント列１００がイベント記憶部３４にすでに格納されている場合は、イベントグラフ作成部３２はイベント記憶部３４から最新のイベント列１００を収集する。

イベントグラフ作成部３２は、観測され、異常が通知されたイベント（前述の例の時刻ｔのイベント）の直前のイベント（前述の例の時刻ｔ-1の観測されたイベント）を起点として、イベントを時間的に遡って（バックトレースして）関連するイベントを抽出し、抽出したイベントを連結することでイベントグラフを作成する（S３０５）。この処理の詳細は、後述する。操作管理部３３は、操作端末４に異常の発生通知と、作成したイベントグラフを送信する。部操作端末４は、受信した内容を表示し、障害分析支援プロセスの処理を終了する（S３０６）。

以上の説明において、異常検知部２２は、予測結果と観測結果の乖離に基づいて異常検知したが、明確に障害に至る異常であると判定できるイベントの検出や、他の手法、例えば１Class SVM(Support Vector Machine)やSVM等を用いた異常検知を併用してもよい。

図１２は、イベントグラフ作成部３２によるイベントグラフの作成（図１１のS３０５）の処理フローチャートである。イベントグラフ作成部３２は、異常が通知されたイベントに対応するノードイベント５００を、事例記憶部３６に格納する。そして、イベントグラフデータ４００の親ノードID402を「Empty」、子ノードID403を事例記憶部３６に格納したノードイベント５００のノードID501、連結タイプ４０４を「なし」、重み４０５を「Empty」として、イベントグラフデータ４００を作成し、事例記憶部３６に格納する。（S４０１）。

イベントグラフ作成部３２は、通知されたイベントのM時刻前に発生したイベントをイベント管理部３４のイベント列１００から抽出し、ノードイベント５００を作成し、事例記憶部３６に登録する。さらにイベントグラフ作成部３２は、通知されたイベントのノードID（親ノード）と、抽出した各イベントのノードID（子ノード）のタプルをスタック（Last-in First-out）に追加する。スタックは、分析用計算機３のワークエリア（作業記憶領域）に設ける。なお、M時刻前に発生したイベントが複数ある場合は、別々にスタックに追加する（S４０２）。本実施例ではMは通知されたイベントの平均発生間隔とする。なお、１分前まで等、Mは対象によって自由に変更してよい。

イベントグラフ作成部３２は、スタックが空かどうかを判定し、スタックが空の場合は本処理を終了し、そうでない場合はS４０４に移る（S４０３）。イベントグラフ作成部３２は、スタックから親ノードと子ノードのタプルを取り出し（S４０４）、取り出した親ノード、子ノードに対応するイベントグラフデータ４００を作成し、事例管理部３６に登録する。このとき、イベントグラフデータ４００の親ノードID４０２が通知されたノードである場合、連結タイプ４０４には「異常遷移」、重み４０５には「Empty」、通知されたノードでない場合は連結タイプ４０４には「正常遷移」、重み４０５には親ノードに対応するイベントIDの局所予測モデルにおける子ノードに対応するイベントIDの重みを登録する（S４０５）。

イベントグラフ作成部３２は、取り出した子ノードの局所予測モデルの予測精度３０３が予め設定された閾値α（例えば、α＝0.6）未満であるかを判定し、α未満である場合にはS４０３に戻り、そうでない場合にはS４０７に移る（S４０６）。予測精度がα未満でなかった場合、イベントグラフ作成部３２は、局所予測モデルによる子ノードの予測結果が観測結果（子ノード）と乖離していないか（すなわち、True-PositiveもしくはFalse-Negativeであること）を判定する。乖離していない場合はS４０８に移り、そうでない場合はS４０９に移る（S４０７）。

予測結果と観測結果が乖離していない場合、イベントグラフ作成部３２は、再帰的にイベントグラフを作成するために、観測結果（子ノード）を新たな親ノード、局所予測モデルの重みが一定値以上（スパース化できれているならば０でない）の特徴関数で用いたイベント（予測に寄与するイベント）を新たな子ノードとしてスタックに追加し、S４０３に戻る（S４０８）。

予測結果と観測結果が乖離している場合、イベントグラフ作成部３２は、観測結果（子ノード）のM時刻前に発生したイベントを抽出し、ノードイベント５００を作成し、事例管理部３６に登録する。イベントグラフ作成部３２は、観測結果を新たな親ノード、登録したノードイベントに対応するノードを新たな子ノードとしてイベントグラフデータ４００を作成し、事例記憶部３６に格納する。このときイベントグラフ作成部３２は、イベントグラフデータ４００の連結タイプ４０４には「異常遷移」、重み４０５には「Empty」を設定する。そして、ステップ１S４０３に戻る（S４０９）。

以上のように、局所予測モデルに基づいて、あるイベントの発生過程を分析、抽出することができる。

図１３は、事例登録プロセスの処理フローチャートである。事例登録プロセスの処理は、保守員やエンジニアが前述の障害分析支援プロセスを活用して、障害の原因を突き止め、対策を講じた後に、操作管理部３３および事例検索部２３の連携により実行される。保守員やエンジニアが、事例ID、サイトID、突き止めた原因や講じた対策を、操作端末４を介して入力する（S５０１）。

保守員やエンジニアが、操作端末４を用いて、障害に関係するイベントグラフを、入力した原因および対策に対応付ける。操作端末４は、イベントグラフと原因および対策などが対応付けられた事例データ６００を操作管理部３３に送信する。操作管理部３３は受信した事例データ６００を事例記憶部３６に格納する（S５０２）。

事例管理部３６は、格納された事例データ６００、事例データ６００のグラフID６０３として参照されているイベントグラフデータ４００、並びに、イベントグラフデータ４００の親ノードID４０２および子ノードID４０３として参照されているノードイベント５００を、イベント監視装置２の事例検索部２３に配信する。事例検索部２３は、受信した事例データ６００、イベントグラフデータ４００およびノードイベント５００をパラメータ記憶部２５に格納し、処理を終了する（S５０３）。

なお、あるサイトの事例を他のサイトに配信する場合に、システム構成や動作上存在しないイベントをイベントグラフから削除しておく。

運用時に起きた障害に関する事例を登録する例を述べたが、実際には、監視対象システム１の出荷前テストや出荷した後の現地での試運転で発生した障害等を同様に登録してもよい。

図１４は、事例提示プロセスの処理フローチャートである。事例提示プロセスの処理は、事例検索部２３および操作管理部３３の連携によって定期的に実行される。短期イベント記憶部２４には、最新のイベント列が格納されている状態を前提として、事例提示プロセスの処理を説明する。

事例照合部２３は、短期イベント記憶部２４に格納されている現時刻(t)からτ時刻前まで（t-τ〜t）のイベント列１００を取得する。そして、事例検索部２３は、イベント列１００とパラメータ記憶部２５に格納されているイベントグラフデータ４００、ノードイベント５００との相関（または類似度、距離）を計算する（S６０１）。例えば、イベント列１００の発生順序が重要となることが多いことを考慮すると、発生順序を反映できる相関係数であるスピアマンの順位相関係数を用いることができる。また、イベント列１００の詳細データ１０４を考慮するならば、前述したイベントグラフの生成処理に基づき、短期イベント記憶部２４から取得したイベント列１００の最新時刻付近のイベント列からイベントグラフを生成し、イベントグラフ同士のグラフカーネル（ツリーカーネル）によって類似性を図ることもできる。これは、観測したイベント列に基づいたイベントグラフをキーにすることで、稼働中のイベント列を使って、類似したイベントグラフに対応する事例を検索することを可能とする。

事例検索部２３が、相関が予め設定した閾値γ（例えば、γ＝0.8）以上となる事例があるかを判定し、該当する事例ある場合にはS６０３に移り、そうでなければ処理を終了する（S６０２）。

イベントグラフ間の相関が閾値γ以上に対応する事例がある場合、事例検索部２３は、その事例データ６００を分析用計算機３の操作管理部３３に通知する。操作管理部３３は、通知された事例データ６００と対応するイベントグラフデータ４００、並びに、イベントグラフデータ４００の親ノードID４０２および子ノードID４０３に対応するノードイベント５００を操作端末４に送信する。操作端末４１は、受信した各データを表示（保守員やエンジニアに通知）し、処理を終了する（S６０３）。

以上のように、イベントグラフを使うことで稼動している監視対象システム１のイベント列からリアルタイムで事例の検索が可能になる。さらに、イベントグラフは、障害が起きた際のイベントからバックトレースすることで生成しているので、最終的な障害が起きる前に事例を検索し、保守員やエンジニアに提示することも可能となる。

なお、本実施形態ではリアルタイムで事例を検索するためにイベントグラフを用いる方法を説明したが、イベントグラフ同士の類似性から事例を分類し、体系化して保守員やエンジニアに提示することもできる。

図１５は、イベントグラフ表示画面１１００の例である。イベントグラフ表示画面１１００は、イベント監視装置２の異常検知部２２が検出した異常に関連するイベントIDとイベントグラフを操作端末４の画面に表示したものである。イベントグラフ表示画面１１００は、サイト表示ボックス１１０１、日時表示ボックス１１０２、異常イベントID表示ボックス１１０３、およびイベントグラフモニタ１１０４を有する。

サイト表示ボックス１１０１には、異常が発生した監視対象システム１のサイトを表示する。日時表示ボックス１１０２には、異常が発生した時刻を表示する。異常イベントID表示ボックス１１０３には通知されたイベントIDを表示する。イベントグラフモニタ１１０４には、イベントグラフデータ４００に基づいて、異常イベントID表示ボックス１１０３に表示したイベント１１０４aをルートノードとし、子孫ノードに対応するイベントIDを左側に配置するツリー状の有向グラフを表示する。また、イベントグラフモニタ１１０４の下部には、表示された各ノードに対応するイベントの発生時刻が表示される。

図１５に示す例のように、あるイベントが他の２つのイベントの発生に寄与することがあり（あるノードに親ノードが2つ存在する場合があり、図中、イベントID４４に、イベントID６７とイベントID１０８の親ノードがある）、厳密に各ノードが半順序集合をなすツリーではない。

また、イベントグラフデータ４００の連結タイプ４０４に応じて表示方法を次のように変更する。連結タイプ４０４が「異常遷移」である場合、同じ親ノードを持つ兄弟ノードを破線枠１１０４bで囲み、親ノードとその破線枠１１０４bとをエッジ１１０４ｃで結ぶ。さらに、そのエッジの上に「！（１１０４c）」を表示することで、「異常遷移」であることを明示する。連結タイプ４０４が「正常遷移」である場合、親ノードと子ノードを直接エッジで結ぶ。さらに、そのエッジの上に「○（１１０４d）」を表示することで、「正常遷移」であることを明示する。また、対応する局所予測モデルの重み（１１０４e）を、局所予測モデルパラメータ２００の重み２０４に基づいて表示する。なお、正常遷移が何段も続く場合は間のノードとエッジを省略して表示してもよい。以上のように表示することで、保守員やエンジニアが障害の発生過程を示すイベントを視覚的に捉えることができる。また、「！」や「○」は記号の一例であって、視覚的に認識される表示であればよく、他の記号あるいは文字列等で表記されていてもかまわない。

図１６は、事例データ表示画面１２００の例である。事例データ表示画面１２００は、イベント監視装置２の事例検索部２３が検索し、検索時刻を付与して、分析用計算機３に通知した事例データを、操作端末４に表示したものである。事例データ表示画面１２００は、サイト表示ボックス１２０１、日時表示ボックス１２０２、事例リスト１２０３、稼動状況リスト１２０４、および事例イベントグラフモニタ１２０５を備える。

サイト表示ボックス１２０１には、分析用計算機３に通知された事例データ６００のサイトID６０１を表示する。日時表示ボックス１２０２には、通知された事例データ６００の検索時刻を表示する。事例リスト１２０３には通知された事例データ６００の事例ID６０１、相関（事例データを検索する際のイベントグラフ間の相関）、および内容データ６０４を表示する。稼働状況リスト１２０４には、サイト表示ボックス１２０１に表示したサイトで発生した最近のイベント列１００の時刻１０２、イベントID１０３、および詳細データ１０４を表示する。事例イベントグラフモニタ１２０５には、事例リスト１２０３で選択された事例データ６００のイベントグラフを表示する。

稼働状況リスト１２０４に表示されているイベントIDがイベントグラフのノードとして表示されている場合、そのノードを特徴づける（そのノードの表示色を変えるなどにより、他とは異なる態様で表示する。）。以上のような事例データの表示により、保守員やエンジニアが発生したイベント列と近い事例を把握することができる。

前述の処理説明では、図１５および図１６の表示画面例に表示されるすべてのデータが、イベント監視装置２から分析用計算機３を介して、または分析用計算機３から、操作端末４に送信されるように説明していないが、処理説明を簡明にするために詳細を省略したものである。

以上に説明したように、本実施形態によれば、事前にイベントの発生原因等を定義する必要がなく、監視対象システムから取得したイベント列を用いて局所予測モデルを構築でき、構築した局所予測モデルを利用することにより、障害検知や分析などのシステムの運用開始または改修にかかる時間とコストを削減できる。

また、本実施形態によれば、稼働している監視対象システムのログからリアルタイムに異常を検知したり、生成したイベントグラフを事例のキーとして検索できるので、熟練していない保守員やエンジニアであっても監視対象システムの異常や事例を把握することができる。

さらに、本実施形態によれば、装置間の相互作用で起きる障害であっても、実際の監視対象システムの動作から局所予測モデルを構築するので、発生する障害に特有のイベント列に含まれるノイズ（監視対象システムとは無関係のイベント）が少なく、障害の発生原因の推定に要する時間を少なくできる。

１：監視対象システム、２：イベント監視装置、３：分析用計算機、４：操作端末、５：ネットワーク、１１：設備、１２：コントローラ、１３：制御用計算機、１４：制御用ネットワーク、２１：収集解析部、２２：異常検知部、２３：事例検索部、２４：短期イベント記憶部、２５：パラメータ記憶部、３１：モデル学習部、３２：イベントグラフ作成部、３３：操作管理部、３４：イベント記憶部、３５：モデル記憶部、３６：事例記憶部。

Claims (15)

1. 監視対象システムの稼働時の第１のイベント列に基づき第１のイベントを予測する局所予測モデルを予め学習する局所予測モデル学習プロセス、
   前記監視対象システムの第２のイベント列を監視し、監視した前記第２のイベント列に含まれる第２のイベントの観測結果と、前記局所予測モデルを用いて予測した前記第１のイベントの予測結果とが不一致の前記第２のイベントを抽出する異常検知プロセス、および
   前記第２のイベントの抽出に応答して、監視した前記第２のイベント列に含まれ、前記観測結果を生じさせる、前記第２のイベントの直前に発生した第３のイベントを起点としてバックトレースした第１のイベントグラフを作成する障害分析支援プロセスを有することを特徴とするイベント分析システム。
2. 前記局所予測モデルを用いた予測は、前記第１のイベント列に含まれる前記第１のイベントの発生順序及び発生タイミングの一方に基づいて予測することを特徴とする請求項１記載のイベント分析システム。
3. 前記障害分析支援プロセスは、前記第３のイベントに対する前記局所予測モデルの予測精度が高く、前記第３のイベントの予測結果と前記第３のイベントの観測結果とが一致する場合には、前記第３のイベントの予測に寄与した、前記第２のイベント列に含まれる第４のイベントを新しい起点として、前記第２のイベント列に含まれるイベント列を再帰的に抽出し、再帰的に抽出した前記イベント列を結合した前記第１のイベントグラフを生成することを特徴とする請求項１記載のイベント分析システム。
4. 前記障害分析支援プロセスは、前記再帰的に抽出した前記イベント列に含まれる第４のイベントに対する前記局所予測モデルの予測精度が高く、前記第４のイベントの予測結果と前記第４のイベントの観測結果とが不一致の場合には、前記第４のイベントの直前のイベント列を抽出して、前記再帰的な抽出を終了し、さらに、前記第４のイベントに対する前記局所予測モデルの予測精度が低い場合は前記再帰的な抽出を終了することを特徴とする請求項３記載のイベント分析システム。
5. 前記局所予測モデル学習プロセスは、前記局所予測モデルの重みベクトルをスパース化することを特徴とする請求項１記載のイベント分析システム。
6. 第２のイベントグラフに対応させた事例を有し、前記第２のイベント列と相関の強い前記第２のイベントグラフを検索し、検索した前記第２のイベントグラフに対応する前記事例を操作端末に表示する事例提示プロセスをさらに有することを特徴とする請求項１記載のイベント分析システム。
7. 前記事例提示プロセスは、前記第２のイベント列に含まれる前記第２のイベントの発生順序を反映する相関係数を用いて前記相関を算出することを特徴とする請求項６記載のイベント分析システム。
8. 前記事例提示プロセスは、前記第２のイベント列のバックトレースの経緯を視覚的に認識されるように表示し、前記第２のイベント列に含まれるイベント間の遷移が正常遷移の場合は、前記イベント間の遷移の予測に用いた前記局所予測モデルの重みを付与してグラフ表示することを特徴とする請求項６記載のイベント分析システム。
9. 前記異常検知プロセスが用いる、サイトに関連する前記局所予測モデルを、前記監視対象システムのサイトに設置するイベント監視装置にあらかじめ記憶することを特徴とする請求項１記載のイベント分析システム。
10. 監視対象システムのイベント分析システムにおけるイベント分析方法であって、前記イベント分析システムは、
    前記監視対象システムの稼働時の第１のイベント列に基づき第１のイベントを予測する局所予測モデルを予め学習し、
    前記監視対象システムの第２のイベント列を監視し、監視した前記第２のイベント列に含まれる第２のイベントの観測結果と、前記局所予測モデルを用いて予測した前記第１のイベントの予測結果とが不一致の前記第２のイベントを抽出し、
    前記第２のイベントの抽出に応答して、監視した前記第２のイベント列に含まれ、前記観測結果を生じさせる、前記第２のイベントの直前に発生した第３のイベントを起点としてバックトレースした第１のイベントグラフを作成することを特徴とするイベント分析方法。
11. 前記イベント分析システムは、前記第３のイベントに対する前記局所予測モデルの予測精度が高く、前記第３のイベントの予測結果と前記第３のイベントの観測結果とが一致する場合には、前記第３のイベントの予測に寄与した、前記第２のイベント列に含まれる第４のイベントを新しい起点として、前記第２のイベント列に含まれるイベント列を再帰的に抽出し、再帰的に抽出した前記イベント列を結合したイベントグラフを生成することを特徴とする請求項１０記載のイベント分析方法。
12. 前記イベント分析システムは、前記再帰的に抽出した前記イベント列に含まれる第４のイベントに対する前記局所予測モデルの予測精度が高く、前記第４のイベントの予測結果と前記第４のイベントの観測結果とが不一致の場合には、前記第４のイベントの直前のイベント列を抽出して、前記再帰的な抽出を終了し、さらに、前記第４のイベントに対する前記局所予測モデルの予測精度が低い場合は前記再帰的な抽出を終了することを特徴とする請求項１１記載のイベント分析方法。
13. 前記イベント分析システムは、第２のイベントグラフに対応させた事例を有し、前記第２のイベント列と相関の強い前記第２のイベントグラフを検索し、検索した前記第２のイベントグラフに対応する前記事例を操作端末に表示することを特徴とする請求項１０記載のイベント分析方法。
14. 前記イベント分析システムは、前記第２のイベント列に含まれる前記第２のイベントの発生順序を反映する相関係数を用いて前記相関を算出することを特徴とする請求項１３記載のイベント分析方法。
15. 前記イベント分析システムは、前記第２のイベント列のバックトレースの経緯を視覚的に認識されるように表示し、前記第２のイベント列に含まれるイベント間の遷移が正常遷移の場合は、前記イベント間の遷移の予測に用いた前記局所予測モデルの重みを付与してグラフ表示することを特徴とする請求項１３記載のイベント分析方法。

Images