特許第6797789号(P6797789)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧

特許6797789状態推定装置、状態推定方法及びプログラム
<>
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000014
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000015
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000016
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000017
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000018
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000019
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000020
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000021
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000022
  • 特許6797789-状態推定装置、状態推定方法及びプログラム 図000023
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6797789
(24)【登録日】2020年11月20日
(45)【発行日】2020年12月9日
(54)【発明の名称】状態推定装置、状態推定方法及びプログラム
(51)【国際特許分類】
   G06F 16/903 20190101AFI20201130BHJP
【FI】
   G06F16/903
【請求項の数】6
【全頁数】20
(21)【出願番号】特願2017-248753(P2017-248753)
(22)【出願日】2017年12月26日
(65)【公開番号】特開2019-114161(P2019-114161A)
(43)【公開日】2019年7月11日
【審査請求日】2019年12月4日
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100124844
【弁理士】
【氏名又は名称】石原 隆治
(72)【発明者】
【氏名】池内 光希
(72)【発明者】
【氏名】渡邉 暁
(72)【発明者】
【氏名】川田 丈浩
(72)【発明者】
【氏名】川原 亮一
【審査官】 鹿野 博嗣
(56)【参考文献】
【文献】 特開2007−087186(JP,A)
【文献】 特開平11−224214(JP,A)
【文献】 特開2011−118695(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/903
(57)【特許請求の範囲】
【請求項1】
第1のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第1のシステムから出力される1以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成部と、
観測対象の第2のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第2のシステムの状態を推定する推定部と、
を有することを特徴とする状態推定装置。
【請求項2】
前記生成部は、前記第1のシステムから出力される各ログメッセージを、当該ログメッセージの種類を示す記号と、当該ログメッセージに含まれる1以上の情報とを含む形式のデータに変換し、前記形式のデータ列を前記パターンとして生成し、
前記推定部は、前記第2のシステムから出力されるログデータに含まれる各ログメッセージを前記形式のデータに変換し、変換後のデータ列と、前記記憶部に記憶された前記パターンとに基づいて、前記第2のシステムの状態を推定する、
ことを特徴とする請求項1記載の状態推定装置。
【請求項3】
前記推定部は、前記状態及び前記ユーザ行動に応じて前記記憶部に記憶されている各前記パターンについて、前記第2のシステムから出力されるログデータに、当該パターンが埋め込まれている度合いを示す指標を計算し、前記状態ごとの前記指標の計算結果に基づいて、前記第2のシステムの状態を推定する、
ことを特徴とする請求項1又は2記載の状態推定装置。
【請求項4】
前記指標は、ログデータ間の類似度、及びログメッセージの出現順序を考慮したアラインメントに基づくログデータ間の類似度の少なくともいずれか一方である、
ことを特徴とする請求項3記載の状態推定装置。
【請求項5】
第1のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第1のシステムから出力される1以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成手順と、
観測対象の第2のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第2のシステムの状態を推定する推定手順と、
をコンピュータが実行することを特徴とする状態推定方法。
【請求項6】
請求項1乃至4いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、状態推定装置、状態推定方法及びプログラムに関する。
【背景技術】
【0002】
近年急速に大規模化してきた通信システムは、数千・数万台の装置から構成され、発生する障害の種類も多岐に渡るため、障害対応には非常に多くの時間を要している。特に、障害の要因を突き止める切り分け作業は、オペレータの多大な稼働を割くものであるため、自動化する機構の需要が高まっている。
【0003】
一般に、障害の要因特定では、装置が出力する「ログメッセージ」に含まれる情報を活用することが多い。ここで、「ログメッセージ」とは、システムが出力する一行のメッセージをいい、複数のログメッセージが出力され、そのまとまりをいうときは「ログデータ」、特にそれらの出現順序をも考慮する場合は「ログメッセージ列」ということにする。
【0004】
図1は、3行からなるログメッセージ列の例を示す図である。通常、ログメッセージは人力での確認が困難なほど膨大な量が出力されるため、自動で解析する技術が開発されてきた。多くの従来技術では、膨大な量の観測ログデータを入力とした機械学習的手法によりイベント間の因果関係を獲得したり、ログデータと障害要因を関連付けるルール作成を行ったりすることで、障害発生時の要因特定を自動化、迅速化している(非特許文献1)。ところが、こうした手法は、障害時に機器の定期監視から出力されるログデータやアラートを用いて学習を行うことが多く、それらに差異が見られない障害同士を切り分けることは困難である。
【0005】
一方、観測ログデータに差異が見られなくても、特定のユーザ行動に伴い発生するログデータには差異が表れ区別できるような障害が存在し、実際にログデータを可視化する取り組みの中では、ユーザ行動に伴い発生するログメッセージ列に積極的に着目して障害の切り分けに有効活用するという技術が存在する。
【0006】
非特許文献2では、IaaSクラウドサービスにおいて、正常運用時に出力されるログデータの中から、ユーザの行動に伴い発生するログメッセージ列のみを抽出して事前学習しておく。障害発生時には、観測されたログメッセージ列と学習済みログメッセージ列との差分を障害要因特定に有効なログメッセージとして検知し、オペレータに提示することで、切り分け作業を効率化する。例えば、正常運用時に「仮想マシンを起動する」というユーザ行動を行った際に出力されるログメッセージ列を事前学習しておくことで、障害時には「仮想マシンを起動する」というユーザ行動をとったときに通常では現れないようなログ(ERRORログやWARNINGログ、特定のプロセスが応答せずタイムアウトを迎えたことを示すログ等)のみが差分として抽出されるため、オペレータは、膨大なログメッセージ列の中から、障害要因の特定に本質的に重要と思われる少数のログメッセージだけを確認すればよいことになる。
【先行技術文献】
【非特許文献】
【0007】
【非特許文献1】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.
【非特許文献2】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.
【発明の概要】
【発明が解決しようとする課題】
【0008】
非特許文献2の技術は、ユーザ行動に伴うログメッセージ列に着目することで、非特許文献1の課題に挑戦しているものといえるが、自動実行されるのは有効なログデータの可視化までであり、そのログデータを読み取って障害要因(すなわち、システムの状態)の特定を行うのはオペレータに任されている。
【0009】
本発明は、上記の点に鑑みてなされたものであって、システムの状態の推定精度を向上させることを目的とする。
【課題を解決するための手段】
【0010】
そこで上記課題を解決するため、状態推定装置は、第1のシステムの複数の状態のそれぞれにおいて、複数のユーザ行動のそれぞれに関して前記第1のシステムから出力される1以上のログメッセージを含むログデータのパターンを生成し、前記パターンを前記状態及び前記ユーザ行動に対応付けて記憶部に記憶する生成部と、観測対象の第2のシステムから出力されるログデータと、前記記憶部に記憶された前記パターンとに基づいて、前記第2のシステムの状態を推定する推定部と、を有する。
【発明の効果】
【0011】
システムの状態の推定精度を向上させることができる。
【図面の簡単な説明】
【0012】
図1】3行からなるログメッセージ列の例を示す図である。
図2】ID化の一例を示す図である。
図3】ログパターン表を説明するための図である。
図4】第1の実施の形態における状態推定装置10のハードウェア構成例を示す図である。
図5】第1の実施の形態における状態推定装置10の機能構成例を示す図である。
図6】スコアの算出方法を説明するための図である。
図7】ログパターン表生成部11が実行する処理手順の一例を説明するためのフローチャートである。
図8】要因特定部12が実行する処理手順の一例を説明するためのフローチャートである。
図9】第2の実施の形態における状態推定装置10の機能構成例を示す図である。
図10】第3の実施の形態における状態推定装置10の機能構成例を示す図である。
【発明を実施するための形態】
【0013】
以下、図面に基づいて本発明の実施の形態を説明する。まず、本実施の形態において使用する用語について定義する。
【0014】
「システム状態s」とは、システムの障害の種類を表し、オペレータが特定したい障害要因と同一視する。すなわち、本実施の形態において、システム状態とは、広義において、システムにおいて発生している障害の種類や当該障害の要因に相当する。例えば、m台の装置からなるシステムにおいて、故障している装置のみを突き止めたい状況を考える。一度に2台以上の装置が壊れないと仮定すると、考えられるシステム状態の集合Sは、S={s|i=0,1,…,m}となる。ここで、sは、どの装置も故障していない状態、s(i=1,2,…,m)は、装置iが故障している状態を表す(すなわち、装置iがシステムの障害の要因であることを表す)。また、別の例として、m個のプロセスが起動しているシステムにおいて、最大1つのプロセスが異常終了する状況を考える。このとき、異常終了したプロセスを突き止めたいとすると、sは、どのプロセスも停止していない状態、s(i=1,2,…,m)は、プロセスiが停止している状態と定めることで、システム状態の集合S(すなわち、システムの障害の要因の集合S)が定義できる。このように、システム状態は、運用者の障害対応方法に応じて任意に定めたものでよい。以下では、システム状態数をm+1とし、システム状態集合をS={s|i=0,1,…,m}で表す。特に、sは、常に正常状態(障害が起きていない状態)を表すものとする。
【0015】
「ユーザ行動a」とは、システムを利用する際に、ユーザが行うことのできるアクション(操作)を表す。例えば、システムとして本発明の適用先の好例であるIaaSクラウドサービスを考えると、「仮想マシン(Virtual Machine;VM)を起動する」、「VMにsshログインする」などがユーザ行動に相当する。以下では、ユーザ行動数をn+1とし、ユーザ行動集合をA={a|j=0,1,…,n}で表す。特に、aは、常にユーザが何も行わないことを表すものとする。
【0016】
「ログメッセージ」とは、システムが出力する一行のメッセージをいう。
【0017】
「ログデータ」とは、出力された複数のログメッセージのまとまり(集合)をいう。
【0018】
「ログメッセージ列」とは、ログデータにおけるログメッセージの出現順序も考慮した情報をいう。
【0019】
「ログ(T,I,α,…,α)」とは、ログメッセージからいくつかの情報(パラメータ)を抽出し、抽出された情報(パラメータ)を組の形式で含むデータをいう。Tは、当該ログメッセージのタイムスタンプ、Iは、当該ログメッセージの種類を示す記号(ID番号)である。ログメッセージに記号(ID番号)を割り当てる際は、例えば、「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.」(以下、「参考文献1」という。)のログテンプレート化技術を利用するとよい。ログテンプレート化技術とは、ログメッセージ内の不変部分と可変パラメタ部分とを分離し、ログメッセージをテンプレート化することで、同種のログメッセージには同じ番号、異種のログメッセージには異なる番号を付与する技術である。α,…,αは、オプションのパラメータであり、障害の要因の特定(推定)で有効と思われる、ログメッセージ内の情報を記録しておく部分である。以降の説明では、D=3とし、αは、装置のホスト名、αは、プロセス名、αは、ログレベル(ERROR、WARNING、INFOなどログメッセージの重要度を表す指標)であるとする。ログメッセージをログの形式に変換することを「ID化」といい、ログメッセージ列内の全てのログメッセージをID化することで得られるログの列を「ログ列」という。図2にID化の一例を示す。
【0020】
「ログパターンLij」とは、システム状態sの状況(すなわち、i≠0であれば、要因sの障害が発生している状況)においてユーザ行動aがなされたときに出力される一連のログ列のことをいう。一般に、このようなログ列は、一意に決まらず試行ごとに揺らぎを持つが、ここではその代表値として選択された一つを指す。ログパターンは、
【0021】
【数1】
と書くことができる(但し、ここではj≠0とする)。ここで、|Lij|は、ログ列を構成するログの総数を表し、組(T,I,α,…,α)は、ログ列の中のk番目のログに相当する。なお、組(T,I,α,…,α)は、i、jにももちろん依存するが、表記を略している。
【0022】
ユーザ行動が無いaのときは、一連のログ列というものが存在せず、例えば、一定期間ごとに実行されるようプログラムされたシステム監視のログのみが得られる。そこで、aに対応するLi0は、何もユーザ行動を起こさないときに一定頻度以上出現するログの集合(正確には、ログデータをID化したとき、一定頻度以上出現するログIDが付与されているログの集合)を表すものとし、Li0を「監視ログ」と呼ぶ。それに対し、Lij(j≠0)は、ユーザ行動に伴い生ずるログ列なので、ログ列Lij(j≠0)を「行動ログ」という。
【0023】
「ログパターン表L'」とは、組(s,a)からLijを割り当てる写像である。すなわち、ログパターン表L'は、Lijを要素にもつ行列であると考えてもよい。
【0024】
図3は、ログパターン表を説明するための図である。例えば、システム状態sを「仮想化ソフト故障」、ユーザ行動aを「VM起動」とする。この場合、仮想化ソフト故障時にユーザがVM起動を実行した際のログパターンはL21なので、L21は、ログパターン表L'中の(s×a)の箇所に収納される。同様に、正常時の監視ログ集合も、「正常状態s」時に「アクション無しa」を行った際に出力されるログ集合と考えられるため、ログパターン表中の(s×a)の箇所に収納される。なお、Lijは、sとaに依存するため、関数fを用いてLij=f(s、a)のように書けそうだが、試行ごとにログの有無やログの出現順序が揺らぐことも考慮してLij〜f(s、a)のように表記している。ここで、「〜」は、類似関係を示す。
【0025】
以下では、実運用で収集されるログメッセージ列からユーザ行動ログパターンを抽出して学習し、事前学習したログパターンとの突合を網羅的に行うことで、尤もらしい障害の種類を推定する状態推定装置10について説明する。
【0026】
図4は、第1の実施の形態における状態推定装置10のハードウェア構成例を示す図である。図4の状態推定装置10は、それぞれバスBで相互に接続されているドライブ装置100、補助記憶装置102、メモリ装置103、CPU104、インタフェース装置105、表示装置106、及び入力装置107等を有する。
【0027】
状態推定装置10での処理を実現するプログラムは、CD−ROM等の記録媒体101によって提供される。プログラムを記憶した記録媒体101がドライブ装置100にセットされると、プログラムが記録媒体101からドライブ装置100を介して補助記憶装置102にインストールされる。但し、プログラムのインストールは必ずしも記録媒体101より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置102は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【0028】
メモリ装置103は、プログラムの起動指示があった場合に、補助記憶装置102からプログラムを読み出して格納する。CPU104は、メモリ装置103に格納されたプログラムに従って状態推定装置10に係る機能を実現する。インタフェース装置105は、ネットワークに接続するためのインタフェースとして用いられる。表示装置106はプログラムによるGUI(Graphical User Interface)等を表示する。入力装置107はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【0029】
なお、表示装置106及び入力装置107は、状態推定装置10にネットワークを介して接続されるPC(Personal Computer)等の端末が有していてもよい。
【0030】
図5は、第1の実施の形態における状態推定装置10の機能構成例を示す図である。図5において、状態推定装置10は、ログパターン表生成部11、要因特定部12及びUI制御部13等を有する。これら各部は、状態推定装置10にインストールされた1以上のプログラムが、CPU104に実行させる処理により実現される。状態推定装置10は、また、ログパターン表DB14を利用する。ログパターン表DB14は、例えば、補助記憶装置102、又は状態推定装置10にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【0031】
ログパターン表生成部11は、正常時又は障害時の実環境システム20内でユーザ行動を起こしそのときに発生するログのパターンを事前に蓄積しておくための処理を実行する。より詳しくは、ログパターン表生成部11は、ログ可視化技術(非特許文献2)の中で提案されたユーザ行動ログデータに着目するという観点を、要因特定自動化技術の中に導入・拡張することを試みて、正常時のみならず障害時のユーザ行動に伴うログデータも含めてログパターンの事前学習を行う。これは、複数種類のユーザ行動のログパターンを組み合わせることで各障害が一意に定まり特定できることを期待したものである。事前学習の結果は、ログパターン表L'としてログパターン表DB14に記憶される。
【0032】
要因特定部12は、運用環境である実環境システム20の障害時のログ列が与えられたときにログパターン表L'を参照して障害の要因(すなわち、実環境システム20の状態)を特定(推定)する。より詳しくは、要因特定部12は、実環境システム20の実運用で収集されるログメッセージ列からユーザ行動ログパターンを抽出し、事前学習したログパターンとの突合を網羅的に行うことで、尤もらしい障害の種類を推定する。ある特定の障害時のみ発生し、他の障害時には発生しないようなユーザ行動ログパターン(例えば、プロセスAが停止しているときに、ユーザがログインを行おうとしたときに限って出力されるERRORログメッセージ列など)が抽出されれば、たとえ大部分が類似したログメッセージを出力する障害が複数有った場合であっても、その差分を敏感に反映して自動要因特定を達成することができる。
【0033】
図5において、要因特定部12は、スコア算出部121及び状態推定部122を含む。スコア算出部121は、ログパターン表L'の各成分Lijについて、運用環境である実環境システム20の障害時のログ列とのスコアを算出する。
【0034】
図6は、スコアの算出方法を説明するための図である。図6の左上には、実環境システム20から出力された観測ログ列Xが示されている。観測ログ列Xにおいて横軸は、タイムスタンプに対応し、縦軸はログIDに対応する。
【0035】
スコア算出部121は、観測ログ列Xが与えられると、観測ログ列Xについて、ログパターン表L'の全LijとのスコアScore(Lij,X)(i=0,1,…,m,j=0,1,…,n)を算出する。ここで、Score(Lij,X)は、LijとXとを入力とし、[0,1]間の実数値を出力する関数であり、高スコアであるほどLijがX内に"埋め込まれている度合い"が高いことを示す指標である。図6の左下には後述する「局所アラインメントに基づくスコア」を計算する際のイメージが示されている。L31の破線の枠は、観測ログ列Xの中からログパターンL31に類似した部分列を抽出し、スコアを計算した結果、Score(L31,X)=0.8となったイメージを表している。Lijは、全部でn×m個存在するため、スコアもn×m個得られることになる。これらのスコアを表にまとめたものが図6の右側の表(以下、「スコア表」という。)である。例えば、Score(L31,X)=0.8は、表中のs×aの箇所に収納されている。空欄箇所は値0が入っているものとみなす。
【0036】
状態推定部122は、このn×mの表に基づいて、システム状態s(すなわち、障害の要因)を推定する。
【0037】
UI制御部13は、運用者からの入力指示の受け付けや、要因特定部12による処理結果の出力等を行う。
【0038】
なお、図5において、技術者は、オフラインでの事前学習に携わる者であり、運用者は、オンラインでの要因特定に携わる者である。
【0039】
以下、状態推定装置10が実行する処理手順について説明する。図7は、ログパターン表生成部11が実行する処理手順の一例を説明するためのフローチャートである。
【0040】
ステップS101において、ログパターン表生成部11は、変数iに0を代入する。変数iは、システム状態sを区別するための変数である。続いて、ログパターン表生成部11は、変数jに0を代入する(S102)。変数jは、ユーザ行動aを区別するための変数である。
【0041】
続いて、ログパターン表生成部11は、システム状態sを再現するためのコマンドを実行する(S103)。例えば、sごとに、当該sを再現するためのコマンドが予め補助記憶装置102等に記憶されており、ログパターン表生成部11は、ステップS102の時点のsに対応するコマンドを読み出して実行する。当該コマンドは、実環境システム20に対して入力されるものであってもよいし、実環境システム20をsの状態にするために、実環境システム20に関連する他のシステムに対して入力されるものであってもよい。例えば、ネットワーク負荷を高めるため処理が実行されるコマンドであってもよい。
【0042】
続いて、ログパターン表生成部11は、ユーザ行動aに相当するコマンドを実環境システム20に対して入力する(S104)。例えば、aごとに、当該aを再現するためのコマンドが予め補助記憶装置102等に記憶されており、ログパターン表生成部11は、ステップS104の時点のaに対応するコマンドを読み出して入力する。その結果、ユーザ行動aが自動的に模擬される。なお、j=0の場合、ログパターン表生成部11は、例えば、コマンドの入力をせずに、一定時間待機する。aは、ユーザ行動無しだからである。
【0043】
続いて、ログパターン表生成部11は、ユーザ行動aに相当するコマンドの実行に応じて実環境システム20から出力されるログデータを収集する(S105)。j=0の場合、待機期間において出力されたログデータが収集される。
【0044】
続いて、ログパターン表生成部11は、当該ログデータについて、フォーマットの統一やパラメタ置換、参考文献1によるID化等を行い、当該ログデータをログパターンLijの形式にする(S106)。続いて、ログパターン表生成部11は、ログパターンLijをログパターン表DB14のログパターン表L'においてi行j列の箇所に記憶する(S107)。すなわち、ログパターン表生成部11は、ログパターンLijを、システム状態s及びユーザ行動aに対応付けてログパターン表DB14に記憶する。
【0045】
続いて、ログパターン表生成部11は、変数jに1を加算し(S108)、変数jがn(ユーザ行動集合Aの要素数)より大きいか否かを判定する(S109)。変数jがn以下である場合(S109でNo)、ログパターン表生成部11は、ステップS103以降を繰り返す。jが変化する度に、ステップS103が再実行されるのは、前回のaの実行により、実環境システム20の状態がsから変化してしまっている可能性が有るからである。
【0046】
変数jがnを超えると(S109でYes)、ログパターン表生成部11は、変数iに1を加算して(S110)、変数iがm(システム状態の集合Sの要素数)より大きいか否かを判定する(S111)。変数iがm以下である場合(S111でNo)、ログパターン表生成部11は、ステップS102以降を繰り返す。変数iがmを超えると(S111でYes)、ログパターン表生成部11は、図7の処理を終了する。その結果、全てのs,i=0,1,…,mとa,j=0,1,…,nに対するログパターンLijが、ログパターン表L'に格納される。
【0047】
但し、あるiに対する処理全て(j=0,1,…,m)をスキップするのは問題ない(もともとそのようなsは存在しなかったと見なせるため)。あるiの処理中に、あるjに対するログが欠損した(ログ生成の失敗など)あるいはあるjをスキップした場合は、そのときの(i,j)の組み合わせを記憶しておき、要因特定時にはログパターン表のi行を用いない、またはログパターン表のj列を用いないという処理が必要になる。また、上記では、ログパターン表生成部11が自動的にs及びaを再現する例を示したが、例えば、ログパターン表生成部11が、技術者に対して、s及びaの再現を促すメッセージを出力し、技術者の手作業による入力に応じて再現されたs及びaにおいて出力されたログデータについて、ステップS105以降が実行されてもよい。又は、運用中の実環境システム20が状態sに陥ったとき各ユーザ行動aが行われてもよい。
【0048】
なお、本実施の形態では、各sに対してあらゆるaのログ列を学習するところに特長がある。例えば、si(1)、si(2)をほぼ同じようなログパターンを出力する異なる障害であるとする。これは、本実施の形態の用語を用いれば、監視ログが似ていて、頻出の行動ログもよく似ているケースにあたるといえる。すなわち、Li(1)0〜Li(2)0、Li(1)j〜Li(2)j(ユーザ行動aは頻出)である(ここで、「〜」は類似を示す)。このような場合でも、ログパターン表中のある特定のユーザ行動aに対する行動ログに差異が認められれば(Li(1)l≠Li(2)l)、要因特定部12において、両者を切り分けることができる。
【0049】
続いて、要因特定部12が実行する処理手順について説明する。まず、障害要因特定問題を定式化する。今、システム状態s'にある実環境システム20の一定期間分のログ列が得られているとする。この期間中、ユーザ(システムのサービス利用者)は、事前に定義されたユーザ行動集合Aに含まれる任意の行動をとっているが、具体的にどのような行動をとったかは未知である。与えられたログ列を、ログパターン表生成部11の前処理と同じ手順でID化したものを「観測ログ列」といい、
【0050】
【数2】
と表す。
【0051】
このとき、観測ログ列X及びログパターン表DB14に記憶されているログパターン表L'を用いて、s'が既知のシステム状態集合S={s|i=0,1,…,m}に属しているという仮定の下で、尤もらしいsを突き止めるというのが障害要因特定問題である。
【0052】
図8は、要因特定部12が実行する処理手順の一例を説明するためのフローチャートである。
【0053】
ステップS201において、スコア算出部121は、一定時間(例えば、数分等)の待機を行い、当該一定時間において、観測対象の実環境システム20から出力されるログデータを収集する。一定時間が経過すると(S201でYes)、スコア算出部121は、ログデータに含まれる各ログメッセージについて図7のステップS106と同様の処理を実行することで各ログメッセージをID化して、観測ログ列Xを生成する(S202)。
【0054】
続いて、スコア算出部121は、予め定義されたスコア算出アルゴリズムに従い、ログパターン表DB14に記憶されているログパターン表L'の全ログパターンLijについて観測ログ列Xに対するスコア=Score(Lij,X)を計算する(S203)。上記したように、このスコアは、LijがXに"埋め込まれている度合い"を数値化した指標である必要がある。例えば、LijがXに含まれているとみなせる確率や、LijがXに出現する回数のようなものが当該スコアとして好適である。なお、スコアの具体例については後述される。
【0055】
続いて、状態推定部122は、スコア算出部121で得られたScore(Lij,X)に基づいて、尤もらしいシステム状態s'(すなわち、システムの障害の種類、障害要因)を求める(S204)。本実施の形態では、システム状態s'の推定法の一例として次式を用いる。
【0056】
【数3】
一部のユーザ行動a(特に監視ログに該当するa)に対しては同じようなログ列を出力するシステム状態s、s'であっても、切り分けのポイントとなるユーザ行動aが実行されていれば、そのログパターンがX内に含まれるか否かがScore(Lil,X),Score(L',X)として表現され、それらの差分が、上式のように全てのjに関する和をとることで、
【0057】
【数4】
の差分として反映され、最終的にs、s'を切り分けることができる。
【0058】
なお、数3は、図6のスコア表の行毎にスコアの総和を求め、当該総和が最大である行に対応するシステム状態siが、システム状態s'として推定されることを示す。図6のスコア表では、システム状態sが要因である例が示されている。
【0059】
続いて、UI制御部13は、推定結果を出力する(S205)。例えば、推定されたシステム状態s'を示す情報が、表示装置106に表示されてもよい。この際、s'=sであれば、正常であることが出力され、s'≠sであれば、s'として推定されたsが出力されてもよい。
【0060】
続いて、スコア算出部121が計算するスコアの一例について説明する。本実施の形態では、当該スコアの一例として2種類のスコアを開示する。常にいずれか一方のスコアが採用されてもよいし、状況に応じて2つのスコアが使い分けたり併用されたりしてもよい。又は、他の方法によってスコアが計算されてもよい。なお、Score(Lij,X)の計算は(i,j)ごとに並列させて行うことも可能である。以下、
【0061】
【数5】
と表す。また、X内のタイムスタンプの列を、
【0062】
【数6】
と表し、Lij内のログIDの列を
【0063】
【数7】
などと表すことにする。
【0064】
[重み付きSimpson係数に基づくスコア]
2種類のスコアのうち、1番目に説明するスコアは、重み付きSimpson係数に基づくスコアである。Iに登場するログIDの中でどのくらいの割合がI'に含まれるかを数値化したものが本スコアである。すなわち、本スコアは、ログの集合(ログデータ)間の類似度の一例である。
【0065】
障害特有のログメッセージには、ERRORやCRITICALのような重要度の高いラベル付けがなされることが多く、障害要因の切り分けの際にも有用となる。そこで、ログレベルに応じて重みを変えるため、重み関数wを導入する。wは、ログレベル空間上の関数で、ERRORのように出現頻度が低く、ログパターンを特徴付けているといえるものに対しては大きな値を、DEBUGのように出現頻度が高く切り分けに有効でなさそうなものに対しては小さな値を与えるように定義しておくのが好適である:w(ERROR)≧w(DEBUG)。
【0066】
Iの中でI'にも登場するログIDの添え字の集合をKとする:K={k∈{1,…,|Lij|}|I=I'k'∃k'∈{1,…,|X|}}。このとき以下の式でスコアを定義する。
【0067】
【数8】
特に、ログレベルを考慮せず、wが定数関数のとき、上記スコアは、I(の順序を無視し集合とみなしたもの)とI'(の順序を無視し集合とみなしたもの)とのSimpson係数(「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.」)と一致する。
【0068】
このスコアは、単純な処理しか行わないため計算時間は短いが、一方で、後段の要因特定時の精度が犠牲になっている。例えば、ログの出現順序を一切考慮しないため、出現するログの集合は同じだが、出現順序が異なるような二つの障害を区別することができない。また、二種類のユーザ行動に対するログ集合の和集合が、別の一種類のユーザ行動に対するログ集合と近い場合には、これらを区別するのは難しい。例えば、Xの中に「VM起動」、「VM停止」の二種類の行動がなされていた場合と、Xの中に「VM再起動」という一種類の行動がなされていた場合を区別するのは難しい。
【0069】
[局所アラインメントに基づくスコア]
前述の重み付きSimpson係数に基づくスコアでの課題を解決するのが、2番目に説明する「局所アラインメントに基づくスコア」である。局所アラインメント(「Smith T. F., Waterman M.S., "Identification of common molecular subsequence," Journal of Molecular Biology, 147, 195-197, 1981.」)とは、二つの文字列P、Q間を比較したとき、最も類似度の高い部分列を両者から抽出するアルゴリズムである。文字列間の類似度は、事前に与えられた文字同士の類似度sim(a,b)(a,bは文字)を用いて定義される。
【0070】
一般に、文字同士の類似度としては、aとbとが類似していれば正の値sim(a,b)>0を、類似していなければ負の値sim(a,b)<0を割り当てておく。このとき、文字列P'、Q'(簡単のため|P'|=|Q'|とする。なお、|Y|は、Yの文字数である)の類似度Sim(P',Q')は、以下の通り、各文字列内の文字同士の類似度の和で定義される。
【0071】
【数9】
局所アラインメントを行うことで、文字列P,Qに対し、それぞれの部分列P',Q'で、Sim(P',Q')が最大になるものを見つけることができる。実際の局所アラインメントでは、ギャップという空文字を導入するが、ここでは簡単のため省略した。また、ここでは、部分列P',Q'の長さを同じとしたが、このような制限も本来は課されない。
【0072】
局所アラインメントを本実施の形態に適用することで、一般に長大となる観測ログ列Xの中からログパターンLijと類似した部分列だけを"掘り起こして"スコア計算を行うことができる。ログの出現順序を考慮した上で特定の行動ログだけ自然に抽出することが可能なので、先に挙げた重み付きSimpson係数に基づくスコアでの問題点を克服できる。すなわち、「局所アラインメントに基づくスコア」は、ログの出現順序を考慮したアラインメントに基づくログデータ間の類似度の一例である。
【0073】
特に、本実施の形態では、後述のメリットから、「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.」による、「改良された局所アラインメント」を利用したスコアを用いる例について説明する。「改良された局所アラインメント」の詳細は割愛するが、主なポイントは次のa〜cの3点である。
【0074】
a:(計算量の削減)XとLijに共通して含まれるIDを抽出してからアラインメントを実行するため、無駄な計算が省かれる。また、アラインメントは、計算時間短縮を考慮したBLASTアルゴリズム(「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.」)に基づく。
【0075】
b:(重み関数の導入)アラインメントで必要となる要素間の類似度sim(Lijk,Xk')として、「改良された局所アラインメント」では、そこに前述のログレベルを考慮した重み関数wを用いる。
【0076】
【数10】
ここで、1(・)は、指示関数、すなわち、1(True)=1、1(False)=0であり、μ(<0)は、ログ不一致の際のペナルティ値である。
【0077】
c:(ログの順序反転の許容)通常のアラインメントでは、配列の順序反転を考慮しないが、「改良された局所アラインメント」では、T及びT'の情報を用い、短時間内でのログ順序の反転をスコア減点のペナルティ付きという形で許容している。
【0078】
本実施の形態において、「改良された局所アラインメント」を用いることは、必須ではないが、次のような観点から適性があると考えられる。
【0079】
a:一般に、Xは長大なログ列であり、多数のLijとの間でスコア算出を行うため、ログ列短縮、計算量削減は重要である。
【0080】
b:重み関数の導入は、Simpson係数に基づくスコアのところで述べた通り、切り分けに有用である。
【0081】
c:各Lijは、行動ログの一サンプルとして収集されたものなので、ログ出現順序の揺らぎを吸収することは重要である。
【0082】
更に、類似度sim(Lij,k,Xk')の与え方により、様々な要因特定問題に対応可能である。例えば、ログIDの出現パターンのみならず、障害の発生したホストまで特定したいのであれば、類似度を
【0083】
【数11】
のように与え、障害の発生したホストごとに異なる状態sを定義しておけば、最終的にScore関数によってそれらを切り分けることができる。
【0084】
以下では、便宜上「改良された局所アラインメント」を、単に「局所アラインメント」という。
【0085】
さて、局所アラインメントアルゴリズムにおける局所アラインメントスコアは、一般には、最良のアラインメントを見つける際の目的関数としての意味合いが強く、その最大値自体を興味の対象とすることは少ない。しかし、本実施の形態では、LijのXに対する"埋め込まれ具合"を指すスコアを必要としているため、最大化された局所アラインメントスコアそのものを利用して次式によりScore関数を与える。
【0086】
【数12】
ここで、分子の最大局所アラインメントスコアとは、先述のSim(P',Q')の最大値に相当するものである。分母は、Lijと同一のログ列がX内に完全に含まれていたときの局所アラインメントスコアであり、この正規化によって、本スコアはLijの長さによらず統一的に扱うことができる。
【0087】
上述したように、第1の実施の形態によれば、システムの観測ログデータに差異が見られず、特定のユーザ行動に伴うログデータにのみ差異が表れるような障害が生じた場合でも、オペレータの多大な稼働を割くことなく、障害の要因について高精度な切り分けができるようになる。すなわち、システムの状態の推定精度を向上させることができる。これにより障害要因特定に要する時間が短縮され、障害によるサービスへの影響時間も短縮させることができる。
【0088】
次に、第2の実施の形態について説明する。第2の実施の形態では第1の実施の形態と異なる点について説明する。第2の実施の形態において特に言及されない点については、第1の実施の形態と同様でもよい。
【0089】
図9は、第2の実施の形態における状態推定装置10の機能構成例を示す図である。図9中、図5と同一部分には同一符号を付し、その説明は省略する。
【0090】
第1の実施の形態では、実環境システム20において障害の生成やユーザ行動の実行をすることでログパターン表L'が生成されるが、そもそも実環境システム20でそのような実験的な行為を行いたくないという場合が考えられる。そこで、第2の実施の形態では、このような場合を考慮して、実環境システム20を模したテストベッド環境システム20tが用意され、テストベッド環境システム20tを用いてログパターン表L'の生成が行われる。
【0091】
次に、第3の実施の形態について説明する。第3の実施の形態では第1の実施の形態と異なる点について説明する。第3の実施の形態において特に言及されない点については、第1の実施の形態と同様でもよい。
【0092】
図10は、第3の実施の形態における状態推定装置10の機能構成例を示す図である。図9中、図5と同一部分には同一符号を付し、その説明は省略する。
【0093】
第1の実施の形態では、実環境システム20から収集されるログデータに基づいて要因推定を行ったが、収集されたログデータ内に状態推定に足る行動ログが含まれていない場合や、状態推定部122が有意なスコア差で要因を特定(推定)できない場合が考えられる。そこで、第3の実施の形態では、このような場合を考慮して、運用者が能動的に実環境システム20で特定のユーザ行動を起こすことが可能とされる。更に、運用者が、要因特定部12にアクセスして、能動的なユーザ行動を起こした期間のログデータを切り出し解析するよう命令することで、ユーザ行動が既知の状態でのスコア算出ができるため、状態推定の精度を高めることができる。
【0094】
なお、上記各実施の形態において、実環境システム20又はテストベッド環境システム20tは、第1のシステムの一例である。実環境システム20は、第2のシステムの一例である。ログパターン表生成部11は、生成部の一例である。要因特定部12は、推定部の一例である。ログパターン表DB14は、記憶部の一例である。ログ列は、データ列の一例である。
【0095】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【0096】
10 状態推定装置
11 ログパターン表生成部
12 要因特定部
13 UI制御部
14 ログパターン表DB
20 実環境システム
20t テストベッド環境システム
100 ドライブ装置
101 記録媒体
102 補助記憶装置
103 メモリ装置
104 CPU
105 インタフェース装置
106 表示装置
107 入力装置
121 スコア算出部
122 状態推定部
B バス
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10