(57)【要約】【課題】システムの状態の推定精度を向上させること。【解決手段】状態推定装置は、第１のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第１のシステムから出力される１以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成部と、観測対象の第２のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第２のシステムの状態を推定する推定部と、を有する。【選択図】図５
2019114161.tif 000002
【特許請求の範囲】
【請求項１】
第１のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第１のシステムから出力される１以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成部と、
観測対象の第２のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第２のシステムの状態を推定する推定部と、
を有することを特徴とする状態推定装置。
【請求項２】
前記生成部は、前記第１のシステムから出力される各ログメッセージを、当該ログメッセージの種類を示す記号と、当該ログメッセージに含まれる１以上の情報とを含む形式のデータに変換し、前記形式のデータ列を前記パターンとして生成し、
前記推定部は、前記第２のシステムから出力されるログデータに含まれる各ログメッセージを前記形式のデータに変換し、変換後のデータ列と、前記記憶部に記憶された前記パターンとに基づいて、前記第２のシステムの状態を推定する、
ことを特徴とする請求項１記載の状態推定装置。
【請求項３】
前記推定部は、前記状態及び前記ユーザ行動に応じて前記記憶部に記憶されている各前記パターンについて、前記第２のシステムから出力されるログデータに、当該パターンが埋め込まれている度合いを示す指標を計算し、前記状態ごとの前記指標の計算結果に基づいて、前記第２のシステムの状態を推定する、
ことを特徴とする請求項１又は２記載の状態推定装置。
【請求項４】
前記指標は、ログデータ間の類似度、及びログメッセージの出現順序を考慮したアラインメントに基づくログデータ間の類似度の少なくともいずれか一方である、
ことを特徴とする請求項３記載の状態推定装置。
【請求項５】
第１のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第１のシステムから出力される１以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成手順と、
観測対象の第２のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第２のシステムの状態を推定する推定手順と、
をコンピュータが実行することを特徴とする状態推定方法。
【請求項６】
請求項１乃至４いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、状態推定装置、状態推定方法及びプログラムに関する。
【背景技術】
【０００２】
近年急速に大規模化してきた通信システムは、数千・数万台の装置から構成され、発生する障害の種類も多岐に渡るため、障害対応には非常に多くの時間を要している。特に、障害の要因を突き止める切り分け作業は、オペレータの多大な稼働を割くものであるため、自動化する機構の需要が高まっている。
【０００３】
一般に、障害の要因特定では、装置が出力する「ログメッセージ」に含まれる情報を活用することが多い。ここで、「ログメッセージ」とは、システムが出力する一行のメッセージをいい、複数のログメッセージが出力され、そのまとまりをいうときは「ログデータ」、特にそれらの出現順序をも考慮する場合は「ログメッセージ列」ということにする。
【０００４】
図１は、３行からなるログメッセージ列の例を示す図である。通常、ログメッセージは人力での確認が困難なほど膨大な量が出力されるため、自動で解析する技術が開発されてきた。多くの従来技術では、膨大な量の観測ログデータを入力とした機械学習的手法によりイベント間の因果関係を獲得したり、ログデータと障害要因を関連付けるルール作成を行ったりすることで、障害発生時の要因特定を自動化、迅速化している（非特許文献１）。ところが、こうした手法は、障害時に機器の定期監視から出力されるログデータやアラートを用いて学習を行うことが多く、それらに差異が見られない障害同士を切り分けることは困難である。
【０００５】
一方、観測ログデータに差異が見られなくても、特定のユーザ行動に伴い発生するログデータには差異が表れ区別できるような障害が存在し、実際にログデータを可視化する取り組みの中では、ユーザ行動に伴い発生するログメッセージ列に積極的に着目して障害の切り分けに有効活用するという技術が存在する。
【０００６】
非特許文献２では、ＩａａＳクラウドサービスにおいて、正常運用時に出力されるログデータの中から、ユーザの行動に伴い発生するログメッセージ列のみを抽出して事前学習しておく。障害発生時には、観測されたログメッセージ列と学習済みログメッセージ列との差分を障害要因特定に有効なログメッセージとして検知し、オペレータに提示することで、切り分け作業を効率化する。例えば、正常運用時に「仮想マシンを起動する」というユーザ行動を行った際に出力されるログメッセージ列を事前学習しておくことで、障害時には「仮想マシンを起動する」というユーザ行動をとったときに通常では現れないようなログ（ＥＲＲＯＲログやＷＡＲＮＩＮＧログ、特定のプロセスが応答せずタイムアウトを迎えたことを示すログ等）のみが差分として抽出されるため、オペレータは、膨大なログメッセージ列の中から、障害要因の特定に本質的に重要と思われる少数のログメッセージだけを確認すればよいことになる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Solia P. Kavulya, Kaustubh Joshi, Felicita Di Giandomenico, and Priya Narasimhan, "Failure diagnosis of complex systems," in Resilience assessment and evaluation of computing systems, K. Wolter, A. Avritzer, M. Vieira, and A. van Moorsel, Eds., ed: Springer Berlin Heidelberg, 239-261, 2012.
【非特許文献２】Byung Chul Tak, Shu Tao, Lin Yang, Chao Zhu, and Yaoping Ruan, "LOGAN: Problem Diagnosis in the Cloud Using Log-based Reference Models," IEEE International Conference on Cloud Engineering. IEEE, 2016:62-67, 2016.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
非特許文献２の技術は、ユーザ行動に伴うログメッセージ列に着目することで、非特許文献１の課題に挑戦しているものといえるが、自動実行されるのは有効なログデータの可視化までであり、そのログデータを読み取って障害要因（すなわち、システムの状態）の特定を行うのはオペレータに任されている。
【０００９】
本発明は、上記の点に鑑みてなされたものであって、システムの状態の推定精度を向上させることを目的とする。
【課題を解決するための手段】
【００１０】
そこで上記課題を解決するため、状態推定装置は、第１のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第１のシステムから出力される１以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成部と、観測対象の第２のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第２のシステムの状態を推定する推定部と、を有する。
【発明の効果】
【００１１】
システムの状態の推定精度を向上させることができる。
【図面の簡単な説明】
【００１２】
【図１】３行からなるログメッセージ列の例を示す図である。
【図２】ＩＤ化の一例を示す図である。
【図３】ログパターン表を説明するための図である。
【図４】第１の実施の形態における状態推定装置１０のハードウェア構成例を示す図である。
【図５】第１の実施の形態における状態推定装置１０の機能構成例を示す図である。
【図６】スコアの算出方法を説明するための図である。
【図７】ログパターン表生成部１１が実行する処理手順の一例を説明するためのフローチャートである。
【図８】要因特定部１２が実行する処理手順の一例を説明するためのフローチャートである。
【図９】第２の実施の形態における状態推定装置１０の機能構成例を示す図である。
【図１０】第３の実施の形態における状態推定装置１０の機能構成例を示す図である。
【発明を実施するための形態】
【００１３】
以下、図面に基づいて本発明の実施の形態を説明する。まず、本実施の形態において使用する用語について定義する。
【００１４】
「システム状態ｓｉ」とは、システムの障害の種類を表し、オペレータが特定したい障害要因と同一視する。すなわち、本実施の形態において、システム状態とは、広義において、システムにおいて発生している障害の種類や当該障害の要因に相当する。例えば、ｍ台の装置からなるシステムにおいて、故障している装置のみを突き止めたい状況を考える。一度に２台以上の装置が壊れないと仮定すると、考えられるシステム状態の集合Ｓは、Ｓ＝｛ｓｉ｜ｉ＝０，１，…，ｍ｝となる。ここで、ｓ０は、どの装置も故障していない状態、ｓｉ（ｉ＝１，２，…，ｍ）は、装置ｉが故障している状態を表す（すなわち、装置ｉがシステムの障害の要因であることを表す）。また、別の例として、ｍ個のプロセスが起動しているシステムにおいて、最大１つのプロセスが異常終了する状況を考える。このとき、異常終了したプロセスを突き止めたいとすると、ｓ０は、どのプロセスも停止していない状態、ｓｉ（ｉ＝１，２，…，ｍ）は、プロセスｉが停止している状態と定めることで、システム状態の集合Ｓ（すなわち、システムの障害の要因の集合Ｓ）が定義できる。このように、システム状態は、運用者の障害対応方法に応じて任意に定めたものでよい。以下では、システム状態数をｍ＋１とし、システム状態集合をＳ＝｛ｓｉ｜ｉ＝０，１，…，ｍ｝で表す。特に、ｓ０は、常に正常状態（障害が起きていない状態）を表すものとする。
【００１５】
「ユーザ行動ａｊ」とは、システムを利用する際に、ユーザが行うことのできるアクション（操作）を表す。例えば、システムとして本発明の適用先の好例であるＩａａＳクラウドサービスを考えると、「仮想マシン（Virtual Machine；ＶＭ）を起動する」、「ＶＭにｓｓｈログインする」などがユーザ行動に相当する。以下では、ユーザ行動数をｎ＋１とし、ユーザ行動集合をＡ＝｛ａｊ｜ｊ＝０，１，…，ｎ｝で表す。特に、ａ０は、常にユーザが何も行わないことを表すものとする。
【００１６】
「ログメッセージ」とは、システムが出力する一行のメッセージをいう。
【００１７】
「ログデータ」とは、出力された複数のログメッセージのまとまり（集合）をいう。
【００１８】
「ログメッセージ列」とは、ログデータにおけるログメッセージの出現順序も考慮した情報をいう。
【００１９】
「ログ（Ｔ，Ｉ，α１，…，αＤ）」とは、ログメッセージからいくつかの情報（パラメータ）を抽出し、抽出された情報（パラメータ）を組の形式で含むデータをいう。Ｔは、当該ログメッセージのタイムスタンプ、Ｉは、当該ログメッセージの種類を示す記号（ＩＤ番号）である。ログメッセージに記号（ＩＤ番号）を割り当てる際は、例えば、「Tatsuaki Kimura, Keisuke Ishibashi, Tatsuya Mori, Hiroshi Sawada, and Tsuyoshi Toyono, "Spatio-temporal Factoriza-tion of Log Data for Understanding Network Events," In Proceedings of the IEEE INFOCOM, 2014.」（以下、「参考文献１」という。）のログテンプレート化技術を利用するとよい。ログテンプレート化技術とは、ログメッセージ内の不変部分と可変パラメタ部分とを分離し、ログメッセージをテンプレート化することで、同種のログメッセージには同じ番号、異種のログメッセージには異なる番号を付与する技術である。α１，…，αＤは、オプションのパラメータであり、障害の要因の特定（推定）で有効と思われる、ログメッセージ内の情報を記録しておく部分である。以降の説明では、Ｄ＝３とし、α１は、装置のホスト名、α２は、プロセス名、α３は、ログレベル（ＥＲＲＯＲ、ＷＡＲＮＩＮＧ、ＩＮＦＯなどログメッセージの重要度を表す指標）であるとする。ログメッセージをログの形式に変換することを「ＩＤ化」といい、ログメッセージ列内の全てのログメッセージをＩＤ化することで得られるログの列を「ログ列」という。図２にＩＤ化の一例を示す。
【００２０】
「ログパターンＬｉｊ」とは、システム状態ｓｉの状況（すなわち、ｉ≠０であれば、要因ｓｉの障害が発生している状況）においてユーザ行動ａｊがなされたときに出力される一連のログ列のことをいう。一般に、このようなログ列は、一意に決まらず試行ごとに揺らぎを持つが、ここではその代表値として選択された一つを指す。ログパターンは、
【００２１】
【数１】
2019114161.tif 000003
と書くことができる（但し、ここではｊ≠０とする）。ここで、｜Ｌｉｊ｜は、ログ列を構成するログの総数を表し、組（Ｔｋ，Ｉｋ，αｋ１，…，αｋＤ）は、ログ列の中のｋ番目のログに相当する。なお、組（Ｔｋ，Ｉｋ，αｋ１，…，αｋＤ）は、ｉ、ｊにももちろん依存するが、表記を略している。
【００２２】
ユーザ行動が無いａ０のときは、一連のログ列というものが存在せず、例えば、一定期間ごとに実行されるようプログラムされたシステム監視のログのみが得られる。そこで、ａ０に対応するＬｉ０は、何もユーザ行動を起こさないときに一定頻度以上出現するログの集合（正確には、ログデータをＩＤ化したとき、一定頻度以上出現するログＩＤが付与されているログの集合）を表すものとし、Ｌｉ０を「監視ログ」と呼ぶ。それに対し、Ｌｉｊ（ｊ≠０）は、ユーザ行動に伴い生ずるログ列なので、ログ列Ｌｉｊ（ｊ≠０）を「行動ログ」という。
【００２３】
「ログパターン表Ｌ'」とは、組（ｓｉ，ａｊ）からＬｉｊを割り当てる写像である。すなわち、ログパターン表Ｌ'は、Ｌｉｊを要素にもつ行列であると考えてもよい。
【００２４】
図３は、ログパターン表を説明するための図である。例えば、システム状態ｓ２を「仮想化ソフト故障」、ユーザ行動ａ１を「ＶＭ起動」とする。この場合、仮想化ソフト故障時にユーザがＶＭ起動を実行した際のログパターンはＬ２１なので、Ｌ２１は、ログパターン表Ｌ'中の（ｓ２×ａ１）の箇所に収納される。同様に、正常時の監視ログ集合も、「正常状態ｓ０」時に「アクション無しａ０」を行った際に出力されるログ集合と考えられるため、ログパターン表中の（ｓ０×ａ０）の箇所に収納される。なお、Ｌｉｊは、ｓｉとａｊに依存するため、関数ｆを用いてＬｉｊ＝ｆ（ｓｉ、ａｊ）のように書けそうだが、試行ごとにログの有無やログの出現順序が揺らぐことも考慮してＬｉｊ〜ｆ（ｓｉ、ａｊ）のように表記している。ここで、「〜」は、類似関係を示す。
【００２５】
以下では、実運用で収集されるログメッセージ列からユーザ行動ログパターンを抽出して学習し、事前学習したログパターンとの突合を網羅的に行うことで、尤もらしい障害の種類を推定する状態推定装置１０について説明する。
【００２６】
図４は、第１の実施の形態における状態推定装置１０のハードウェア構成例を示す図である。図４の状態推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。
【００２７】
状態推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２８】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って状態推定装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【００２９】
なお、表示装置１０６及び入力装置１０７は、状態推定装置１０にネットワークを介して接続されるＰＣ（Personal Computer）等の端末が有していてもよい。
【００３０】
図５は、第１の実施の形態における状態推定装置１０の機能構成例を示す図である。図５において、状態推定装置１０は、ログパターン表生成部１１、要因特定部１２及びＵＩ制御部１３等を有する。これら各部は、状態推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。状態推定装置１０は、また、ログパターン表ＤＢ１４を利用する。ログパターン表ＤＢ１４は、例えば、補助記憶装置１０２、又は状態推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００３１】
ログパターン表生成部１１は、正常時又は障害時の実環境システム２０内でユーザ行動を起こしそのときに発生するログのパターンを事前に蓄積しておくための処理を実行する。より詳しくは、ログパターン表生成部１１は、ログ可視化技術（非特許文献２）の中で提案されたユーザ行動ログデータに着目するという観点を、要因特定自動化技術の中に導入・拡張することを試みて、正常時のみならず障害時のユーザ行動に伴うログデータも含めてログパターンの事前学習を行う。これは、複数種類のユーザ行動のログパターンを組み合わせることで各障害が一意に定まり特定できることを期待したものである。事前学習の結果は、ログパターン表Ｌ'としてログパターン表ＤＢ１４に記憶される。
【００３２】
要因特定部１２は、運用環境である実環境システム２０の障害時のログ列が与えられたときにログパターン表Ｌ'を参照して障害の要因（すなわち、実環境システム２０の状態）を特定（推定）する。より詳しくは、要因特定部１２は、実環境システム２０の実運用で収集されるログメッセージ列からユーザ行動ログパターンを抽出し、事前学習したログパターンとの突合を網羅的に行うことで、尤もらしい障害の種類を推定する。ある特定の障害時のみ発生し、他の障害時には発生しないようなユーザ行動ログパターン（例えば、プロセスＡが停止しているときに、ユーザがログインを行おうとしたときに限って出力されるＥＲＲＯＲログメッセージ列など）が抽出されれば、たとえ大部分が類似したログメッセージを出力する障害が複数有った場合であっても、その差分を敏感に反映して自動要因特定を達成することができる。
【００３３】
図５において、要因特定部１２は、スコア算出部１２１及び状態推定部１２２を含む。スコア算出部１２１は、ログパターン表Ｌ'の各成分Ｌｉｊについて、運用環境である実環境システム２０の障害時のログ列とのスコアを算出する。
【００３４】
図６は、スコアの算出方法を説明するための図である。図６の左上には、実環境システム２０から出力された観測ログ列Ｘが示されている。観測ログ列Ｘにおいて横軸は、タイムスタンプに対応し、縦軸はログＩＤに対応する。
【００３５】
スコア算出部１２１は、観測ログ列Ｘが与えられると、観測ログ列Ｘについて、ログパターン表Ｌ'の全ＬｉｊとのスコアＳｃｏｒｅ（Ｌｉｊ，Ｘ）（ｉ＝０，１，…，ｍ，ｊ＝０，１，…，ｎ）を算出する。ここで、Ｓｃｏｒｅ（Ｌｉｊ，Ｘ）は、ＬｉｊとＸとを入力とし、［０，１］間の実数値を出力する関数であり、高スコアであるほどＬｉｊがＸ内に"埋め込まれている度合い"が高いことを示す指標である。図６の左下には後述する「局所アラインメントに基づくスコア」を計算する際のイメージが示されている。Ｌ３１の破線の枠は、観測ログ列Ｘの中からログパターンＬ３１に類似した部分列を抽出し、スコアを計算した結果、Ｓｃｏｒｅ（Ｌ３１，Ｘ）＝０．８となったイメージを表している。Ｌｉｊは、全部でｎ×ｍ個存在するため、スコアもｎ×ｍ個得られることになる。これらのスコアを表にまとめたものが図６の右側の表（以下、「スコア表」という。）である。例えば、Ｓｃｏｒｅ（Ｌ３１，Ｘ）＝０．８は、表中のｓ３×ａ１の箇所に収納されている。空欄箇所は値０が入っているものとみなす。
【００３６】
状態推定部１２２は、このｎ×ｍの表に基づいて、システム状態ｓｉ（すなわち、障害の要因）を推定する。
【００３７】
ＵＩ制御部１３は、運用者からの入力指示の受け付けや、要因特定部１２による処理結果の出力等を行う。
【００３８】
なお、図５において、技術者は、オフラインでの事前学習に携わる者であり、運用者は、オンラインでの要因特定に携わる者である。
【００３９】
以下、状態推定装置１０が実行する処理手順について説明する。図７は、ログパターン表生成部１１が実行する処理手順の一例を説明するためのフローチャートである。
【００４０】
ステップＳ１０１において、ログパターン表生成部１１は、変数ｉに０を代入する。変数ｉは、システム状態ｓｉを区別するための変数である。続いて、ログパターン表生成部１１は、変数ｊに０を代入する（Ｓ１０２）。変数ｊは、ユーザ行動ａｊを区別するための変数である。
【００４１】
続いて、ログパターン表生成部１１は、システム状態ｓｉを再現するためのコマンドを実行する（Ｓ１０３）。例えば、ｓｉごとに、当該ｓｉを再現するためのコマンドが予め補助記憶装置１０２等に記憶されており、ログパターン表生成部１１は、ステップＳ１０２の時点のｓｉに対応するコマンドを読み出して実行する。当該コマンドは、実環境システム２０に対して入力されるものであってもよいし、実環境システム２０をｓｉの状態にするために、実環境システム２０に関連する他のシステムに対して入力されるものであってもよい。例えば、ネットワーク負荷を高めるため処理が実行されるコマンドであってもよい。
【００４２】
続いて、ログパターン表生成部１１は、ユーザ行動ａｊに相当するコマンドを実環境システム２０に対して入力する（Ｓ１０４）。例えば、ａｊごとに、当該ａｊを再現するためのコマンドが予め補助記憶装置１０２等に記憶されており、ログパターン表生成部１１は、ステップＳ１０４の時点のａｊに対応するコマンドを読み出して入力する。その結果、ユーザ行動ａｊが自動的に模擬される。なお、ｊ＝０の場合、ログパターン表生成部１１は、例えば、コマンドの入力をせずに、一定時間待機する。ａ０は、ユーザ行動無しだからである。
【００４３】
続いて、ログパターン表生成部１１は、ユーザ行動ａｊに相当するコマンドの実行に応じて実環境システム２０から出力されるログデータを収集する（Ｓ１０５）。ｊ＝０の場合、待機期間において出力されたログデータが収集される。
【００４４】
続いて、ログパターン表生成部１１は、当該ログデータについて、フォーマットの統一やパラメタ置換、参考文献１によるＩＤ化等を行い、当該ログデータをログパターンＬｉｊの形式にする（Ｓ１０６）。続いて、ログパターン表生成部１１は、ログパターンＬｉｊをログパターン表ＤＢ１４のログパターン表Ｌ'においてｉ行ｊ列の箇所に記憶する（Ｓ１０７）。すなわち、ログパターン表生成部１１は、ログパターンＬｉｊを、システム状態ｓｉ及びユーザ行動ａｊに対応付けてログパターン表ＤＢ１４に記憶する。
【００４５】
続いて、ログパターン表生成部１１は、変数ｊに１を加算し（Ｓ１０８）、変数ｊがｎ（ユーザ行動集合Ａの要素数）より大きいか否かを判定する（Ｓ１０９）。変数ｊがｎ以下である場合（Ｓ１０９でＮｏ）、ログパターン表生成部１１は、ステップＳ１０３以降を繰り返す。ｊが変化する度に、ステップＳ１０３が再実行されるのは、前回のａｊの実行により、実環境システム２０の状態がｓｉから変化してしまっている可能性が有るからである。
【００４６】
変数ｊがｎを超えると（Ｓ１０９でＹｅｓ）、ログパターン表生成部１１は、変数ｉに１を加算して（Ｓ１１０）、変数ｉがｍ（システム状態の集合Ｓの要素数）より大きいか否かを判定する（Ｓ１１１）。変数ｉがｍ以下である場合（Ｓ１１１でＮｏ）、ログパターン表生成部１１は、ステップＳ１０２以降を繰り返す。変数ｉがｍを超えると（Ｓ１１１でＹｅｓ）、ログパターン表生成部１１は、図７の処理を終了する。その結果、全てのｓｉ，ｉ＝０，１，…，ｍとａｊ，ｊ＝０，１，…，ｎに対するログパターンＬｉｊが、ログパターン表Ｌ'に格納される。
【００４７】
但し、あるｉに対する処理全て（ｊ＝０，１，…，ｍ）をスキップするのは問題ない（もともとそのようなｓｉは存在しなかったと見なせるため）。あるｉの処理中に、あるｊに対するログが欠損した（ログ生成の失敗など）あるいはあるｊをスキップした場合は、そのときの（ｉ，ｊ)の組み合わせを記憶しておき、要因特定時にはログパターン表のｉ行を用いない、またはログパターン表のｊ列を用いないという処理が必要になる。また、上記では、ログパターン表生成部１１が自動的にｓｉ及びａｊを再現する例を示したが、例えば、ログパターン表生成部１１が、技術者に対して、ｓｉ及びａｊの再現を促すメッセージを出力し、技術者の手作業による入力に応じて再現されたｓｉ及びａｊにおいて出力されたログデータについて、ステップＳ１０５以降が実行されてもよい。又は、運用中の実環境システム２０が状態ｓｉに陥ったとき各ユーザ行動ａｊが行われてもよい。
【００４８】
なお、本実施の形態では、各ｓｉに対してあらゆるａｊのログ列を学習するところに特長がある。例えば、ｓｉ（１）、ｓｉ（２）をほぼ同じようなログパターンを出力する異なる障害であるとする。これは、本実施の形態の用語を用いれば、監視ログが似ていて、頻出の行動ログもよく似ているケースにあたるといえる。すなわち、Ｌｉ（１）０〜Ｌｉ（２）０、Ｌｉ（１）ｊ〜Ｌｉ（２）ｊ（ユーザ行動ａｊは頻出）である（ここで、「〜」は類似を示す）。このような場合でも、ログパターン表中のある特定のユーザ行動ａｌに対する行動ログに差異が認められれば（Ｌｉ（１）ｌ≠Ｌｉ（２）ｌ）、要因特定部１２において、両者を切り分けることができる。
【００４９】
続いて、要因特定部１２が実行する処理手順について説明する。まず、障害要因特定問題を定式化する。今、システム状態ｓ'にある実環境システム２０の一定期間分のログ列が得られているとする。この期間中、ユーザ（システムのサービス利用者）は、事前に定義されたユーザ行動集合Ａに含まれる任意の行動をとっているが、具体的にどのような行動をとったかは未知である。与えられたログ列を、ログパターン表生成部１１の前処理と同じ手順でＩＤ化したものを「観測ログ列」といい、
【００５０】
【数２】
2019114161.tif 000004
と表す。
【００５１】
このとき、観測ログ列Ｘ及びログパターン表ＤＢ１４に記憶されているログパターン表Ｌ'を用いて、ｓ'が既知のシステム状態集合Ｓ＝｛ｓｉ｜ｉ＝０，１，…，ｍ｝に属しているという仮定の下で、尤もらしいｓｉを突き止めるというのが障害要因特定問題である。
【００５２】
図８は、要因特定部１２が実行する処理手順の一例を説明するためのフローチャートである。
【００５３】
ステップＳ２０１において、スコア算出部１２１は、一定時間（例えば、数分等）の待機を行い、当該一定時間において、観測対象の実環境システム２０から出力されるログデータを収集する。一定時間が経過すると（Ｓ２０１でＹｅｓ）、スコア算出部１２１は、ログデータに含まれる各ログメッセージについて図７のステップＳ１０６と同様の処理を実行することで各ログメッセージをＩＤ化して、観測ログ列Ｘを生成する（Ｓ２０２）。
【００５４】
続いて、スコア算出部１２１は、予め定義されたスコア算出アルゴリズムに従い、ログパターン表ＤＢ１４に記憶されているログパターン表Ｌ'の全ログパターンＬｉｊについて観測ログ列Ｘに対するスコア＝Ｓｃｏｒｅ（Ｌｉｊ，Ｘ）を計算する（Ｓ２０３）。上記したように、このスコアは、ＬｉｊがＸに"埋め込まれている度合い"を数値化した指標である必要がある。例えば、ＬｉｊがＸに含まれているとみなせる確率や、ＬｉｊがＸに出現する回数のようなものが当該スコアとして好適である。なお、スコアの具体例については後述される。
【００５５】
続いて、状態推定部１２２は、スコア算出部１２１で得られたＳｃｏｒｅ（Ｌｉｊ，Ｘ）に基づいて、尤もらしいシステム状態ｓ'（すなわち、システムの障害の種類、障害要因）を求める（Ｓ２０４）。本実施の形態では、システム状態ｓ'の推定法の一例として次式を用いる。
【００５６】
【数３】
2019114161.tif 000005
一部のユーザ行動ａｊ（特に監視ログに該当するａ０）に対しては同じようなログ列を出力するシステム状態ｓｉ、ｓｉ'であっても、切り分けのポイントとなるユーザ行動ａｌが実行されていれば、そのログパターンがＸ内に含まれるか否かがＳｃｏｒｅ（Ｌｉｌ，Ｘ），Ｓｃｏｒｅ（Ｌｉ'ｌ，Ｘ）として表現され、それらの差分が、上式のように全てのｊに関する和をとることで、
【００５７】
【数４】
2019114161.tif 000006
の差分として反映され、最終的にｓｉ、ｓｉ'を切り分けることができる。
【００５８】
なお、数３は、図６のスコア表の行毎にスコアの総和を求め、当該総和が最大である行に対応するシステム状態ｓｉが、システム状態ｓ'として推定されることを示す。図６のスコア表では、システム状態ｓ３が要因である例が示されている。
【００５９】
続いて、ＵＩ制御部１３は、推定結果を出力する（Ｓ２０５）。例えば、推定されたシステム状態ｓ'を示す情報が、表示装置１０６に表示されてもよい。この際、ｓ'＝ｓ０であれば、正常であることが出力され、ｓ'≠ｓ０であれば、ｓ'として推定されたｓｉが出力されてもよい。
【００６０】
続いて、スコア算出部１２１が計算するスコアの一例について説明する。本実施の形態では、当該スコアの一例として２種類のスコアを開示する。常にいずれか一方のスコアが採用されてもよいし、状況に応じて２つのスコアが使い分けたり併用されたりしてもよい。又は、他の方法によってスコアが計算されてもよい。なお、Ｓｃｏｒｅ（Ｌｉｊ，Ｘ）の計算は（ｉ，ｊ）ごとに並列させて行うことも可能である。以下、
【００６１】
【数５】
2019114161.tif 000007
と表す。また、Ｘ内のタイムスタンプの列を、
【００６２】
【数６】
2019114161.tif 000008
と表し、Ｌｉｊ内のログＩＤの列を
【００６３】
【数７】
2019114161.tif 000009
などと表すことにする。
【００６４】
［重み付きＳｉｍｐｓｏｎ係数に基づくスコア］
２種類のスコアのうち、１番目に説明するスコアは、重み付きＳｉｍｐｓｏｎ係数に基づくスコアである。Ｉに登場するログＩＤの中でどのくらいの割合がＩ'に含まれるかを数値化したものが本スコアである。すなわち、本スコアは、ログの集合（ログデータ）間の類似度の一例である。
【００６５】
障害特有のログメッセージには、ＥＲＲＯＲやＣＲＩＴＩＣＡＬのような重要度の高いラベル付けがなされることが多く、障害要因の切り分けの際にも有用となる。そこで、ログレベルに応じて重みを変えるため、重み関数ｗを導入する。ｗは、ログレベル空間上の関数で、ＥＲＲＯＲのように出現頻度が低く、ログパターンを特徴付けているといえるものに対しては大きな値を、ＤＥＢＵＧのように出現頻度が高く切り分けに有効でなさそうなものに対しては小さな値を与えるように定義しておくのが好適である：ｗ（ＥＲＲＯＲ）≧ｗ（ＤＥＢＵＧ）。
【００６６】
Ｉの中でＩ'にも登場するログＩＤの添え字の集合をＫとする：Ｋ＝｛ｋ∈｛１，…，｜Ｌｉｊ｜｝｜Ｉｋ＝Ｉ'ｋ'∃ｋ'∈｛１，…，｜Ｘ｜｝｝。このとき以下の式でスコアを定義する。
【００６７】
【数８】
2019114161.tif 000010
特に、ログレベルを考慮せず、ｗが定数関数のとき、上記スコアは、Ｉ（の順序を無視し集合とみなしたもの）とＩ'（の順序を無視し集合とみなしたもの）とのＳｉｍｐｓｏｎ係数（「M. K. Vijaymeena and K. Kavitha, "A Survey ON SIMILARITY MEASURES IN TEXT MINING," Machine Learning and Applications: An International Journal (MLAIJ), vol. 3, 1, 19-28, 2016.」）と一致する。
【００６８】
このスコアは、単純な処理しか行わないため計算時間は短いが、一方で、後段の要因特定時の精度が犠牲になっている。例えば、ログの出現順序を一切考慮しないため、出現するログの集合は同じだが、出現順序が異なるような二つの障害を区別することができない。また、二種類のユーザ行動に対するログ集合の和集合が、別の一種類のユーザ行動に対するログ集合と近い場合には、これらを区別するのは難しい。例えば、Ｘの中に「ＶＭ起動」、「ＶＭ停止」の二種類の行動がなされていた場合と、Ｘの中に「ＶＭ再起動」という一種類の行動がなされていた場合を区別するのは難しい。
【００６９】
［局所アラインメントに基づくスコア］
前述の重み付きＳｉｍｐｓｏｎ係数に基づくスコアでの課題を解決するのが、２番目に説明する「局所アラインメントに基づくスコア」である。局所アラインメント（「Smith T. F., Waterman M.S., "Identification of common molecular subsequence," Journal of Molecular Biology, 147, 195-197, 1981.」）とは、二つの文字列Ｐ、Ｑ間を比較したとき、最も類似度の高い部分列を両者から抽出するアルゴリズムである。文字列間の類似度は、事前に与えられた文字同士の類似度ｓｉｍ（ａ，ｂ）（ａ，ｂは文字）を用いて定義される。
【００７０】
一般に、文字同士の類似度としては、ａとｂとが類似していれば正の値ｓｉｍ（ａ，ｂ）＞０を、類似していなければ負の値ｓｉｍ（ａ，ｂ）＜０を割り当てておく。このとき、文字列Ｐ'、Ｑ'（簡単のため｜Ｐ'｜＝｜Ｑ'｜とする。なお、｜Ｙ｜は、Ｙの文字数である）の類似度Ｓｉｍ（Ｐ'，Ｑ'）は、以下の通り、各文字列内の文字同士の類似度の和で定義される。
【００７１】
【数９】
2019114161.tif 000011
局所アラインメントを行うことで、文字列Ｐ，Ｑに対し、それぞれの部分列Ｐ'，Ｑ'で、Ｓｉｍ（Ｐ'，Ｑ'）が最大になるものを見つけることができる。実際の局所アラインメントでは、ギャップという空文字を導入するが、ここでは簡単のため省略した。また、ここでは、部分列Ｐ'，Ｑ'の長さを同じとしたが、このような制限も本来は課されない。
【００７２】
局所アラインメントを本実施の形態に適用することで、一般に長大となる観測ログ列Ｘの中からログパターンＬｉｊと類似した部分列だけを"掘り起こして"スコア計算を行うことができる。ログの出現順序を考慮した上で特定の行動ログだけ自然に抽出することが可能なので、先に挙げた重み付きＳｉｍｐｓｏｎ係数に基づくスコアでの問題点を克服できる。すなわち、「局所アラインメントに基づくスコア」は、ログの出現順序を考慮したアラインメントに基づくログデータ間の類似度の一例である。
【００７３】
特に、本実施の形態では、後述のメリットから、「Wenkai Hu, Jiandong Wang, and Tongwen Chen, "A local alignment approach to similarity analysis of industrial alarm flood sequences," Control Engineering Practice, 55, 13-25, 2016.」による、「改良された局所アラインメント」を利用したスコアを用いる例について説明する。「改良された局所アラインメント」の詳細は割愛するが、主なポイントは次のａ〜ｃの３点である。
【００７４】
ａ：（計算量の削減）ＸとＬｉｊに共通して含まれるＩＤを抽出してからアラインメントを実行するため、無駄な計算が省かれる。また、アラインメントは、計算時間短縮を考慮したＢＬＡＳＴアルゴリズム（「Stephen F. Altschul, WarrenGish, Webb Miller, Eugene W. Myers, David J. Lipman,  "Basic local alignment search tool," Journal of Molecular Biology, 215, 3389-3402, 1990.」）に基づく。
【００７５】
ｂ：（重み関数の導入）アラインメントで必要となる要素間の類似度ｓｉｍ（Ｌｉｊｋ，Ｘｋ'）として、「改良された局所アラインメント」では、そこに前述のログレベルを考慮した重み関数ｗを用いる。
【００７６】
【数１０】
2019114161.tif 000012
ここで、１（・）は、指示関数、すなわち、１（Ｔｒｕｅ）＝１、１（Ｆａｌｓｅ）＝０であり、μ（＜０）は、ログ不一致の際のペナルティ値である。
【００７７】
ｃ：（ログの順序反転の許容）通常のアラインメントでは、配列の順序反転を考慮しないが、「改良された局所アラインメント」では、Ｔ及びＴ'の情報を用い、短時間内でのログ順序の反転をスコア減点のペナルティ付きという形で許容している。
【００７８】
本実施の形態において、「改良された局所アラインメント」を用いることは、必須ではないが、次のような観点から適性があると考えられる。
【００７９】
ａ：一般に、Ｘは長大なログ列であり、多数のＬｉｊとの間でスコア算出を行うため、ログ列短縮、計算量削減は重要である。
【００８０】
ｂ：重み関数の導入は、Ｓｉｍｐｓｏｎ係数に基づくスコアのところで述べた通り、切り分けに有用である。
【００８１】
ｃ：各Ｌｉｊは、行動ログの一サンプルとして収集されたものなので、ログ出現順序の揺らぎを吸収することは重要である。
【００８２】
更に、類似度ｓｉｍ（Ｌｉｊ，ｋ，Ｘｋ'）の与え方により、様々な要因特定問題に対応可能である。例えば、ログＩＤの出現パターンのみならず、障害の発生したホストまで特定したいのであれば、類似度を
【００８３】
【数１１】
2019114161.tif 000013
のように与え、障害の発生したホストごとに異なる状態ｓを定義しておけば、最終的にＳｃｏｒｅ関数によってそれらを切り分けることができる。
【００８４】
以下では、便宜上「改良された局所アラインメント」を、単に「局所アラインメント」という。
【００８５】
さて、局所アラインメントアルゴリズムにおける局所アラインメントスコアは、一般には、最良のアラインメントを見つける際の目的関数としての意味合いが強く、その最大値自体を興味の対象とすることは少ない。しかし、本実施の形態では、ＬｉｊのＸに対する"埋め込まれ具合"を指すスコアを必要としているため、最大化された局所アラインメントスコアそのものを利用して次式によりＳｃｏｒｅ関数を与える。
【００８６】
【数１２】
2019114161.tif 000014
ここで、分子の最大局所アラインメントスコアとは、先述のＳｉｍ（Ｐ'，Ｑ'）の最大値に相当するものである。分母は、Ｌｉｊと同一のログ列がＸ内に完全に含まれていたときの局所アラインメントスコアであり、この正規化によって、本スコアはＬｉｊの長さによらず統一的に扱うことができる。
【００８７】
上述したように、第１の実施の形態によれば、システムの観測ログデータに差異が見られず、特定のユーザ行動に伴うログデータにのみ差異が表れるような障害が生じた場合でも、オペレータの多大な稼働を割くことなく、障害の要因について高精度な切り分けができるようになる。すなわち、システムの状態の推定精度を向上させることができる。これにより障害要因特定に要する時間が短縮され、障害によるサービスへの影響時間も短縮させることができる。
【００８８】
次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００８９】
図９は、第２の実施の形態における状態推定装置１０の機能構成例を示す図である。図９中、図５と同一部分には同一符号を付し、その説明は省略する。
【００９０】
第１の実施の形態では、実環境システム２０において障害の生成やユーザ行動の実行をすることでログパターン表Ｌ'が生成されるが、そもそも実環境システム２０でそのような実験的な行為を行いたくないという場合が考えられる。そこで、第２の実施の形態では、このような場合を考慮して、実環境システム２０を模したテストベッド環境システム２０ｔが用意され、テストベッド環境システム２０ｔを用いてログパターン表Ｌ'の生成が行われる。
【００９１】
次に、第３の実施の形態について説明する。第３の実施の形態では第１の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００９２】
図１０は、第３の実施の形態における状態推定装置１０の機能構成例を示す図である。図９中、図５と同一部分には同一符号を付し、その説明は省略する。
【００９３】
第１の実施の形態では、実環境システム２０から収集されるログデータに基づいて要因推定を行ったが、収集されたログデータ内に状態推定に足る行動ログが含まれていない場合や、状態推定部１２２が有意なスコア差で要因を特定（推定）できない場合が考えられる。そこで、第３の実施の形態では、このような場合を考慮して、運用者が能動的に実環境システム２０で特定のユーザ行動を起こすことが可能とされる。更に、運用者が、要因特定部１２にアクセスして、能動的なユーザ行動を起こした期間のログデータを切り出し解析するよう命令することで、ユーザ行動が既知の状態でのスコア算出ができるため、状態推定の精度を高めることができる。
【００９４】
なお、上記各実施の形態において、実環境システム２０又はテストベッド環境システム２０ｔは、第１のシステムの一例である。実環境システム２０は、第２のシステムの一例である。ログパターン表生成部１１は、生成部の一例である。要因特定部１２は、推定部の一例である。ログパターン表ＤＢ１４は、記憶部の一例である。ログ列は、データ列の一例である。
【００９５】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００９６】
１０          状態推定装置
１１          ログパターン表生成部
１２          要因特定部
１３          ＵＩ制御部
１４          ログパターン表ＤＢ
２０          実環境システム
２０ｔ        テストベッド環境システム
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１０６        表示装置
１０７        入力装置
１２１        スコア算出部
１２２        状態推定部
Ｂ            バス
【図１】
2019114161.tif 000015
【図２】
2019114161.tif 000016
【図３】
2019114161.tif 000017
【図４】
2019114161.tif 000018
【図５】
2019114161.tif 000019
【図６】
2019114161.tif 000020
【図７】
2019114161.tif 000021
【図８】
2019114161.tif 000022
【図９】
2019114161.tif 000023
【図１０】
2019114161.tif 000024