JP7415363B2 - ログ分析装置、方法及びプログラム - Google Patents

Description

本発明は、ログ分析装置、方法及びプログラムに関し、特に、システムから出力されるログを分析するためのログ分析装置、方法及びプログラムに関する。

特許文献１には、情報処理システムが出力するログを分析するログ分析システムに関する技術が開示されている。特許文献１にかかるログ分析システムでは、ログメッセージの組み合わせについて正常パターンと異常パターンとを記憶部に記憶している。そして、当該ログ分析システムは、読み込まれたログメッセージについて正常パターン及び異常パターンと一致するか否かを判定する。当該ログ分析システムは、ログメッセージがいずれにも一致しない場合、新たなパターンとして生成し、記憶部に記録する。

特許文献２には、ログフォーマットごとの周期モデルを生成し、周期モデルを用いてログが異常か否かを判定するログ分析システムに関する技術が開示されている。特許文献３には、異種混成のログソースから正規表現パターンを生成し、訓練ログからモデル及びプロファイルを生成するログ分析プラットフォームに関する技術が開示されている。特許文献４には、ログ判定システムに関する技術が開示されている。特許文献４にかかるログ判定システムは、予めログデータから学習を行い、ログ判定基準を構築する。そして、当該ログ判定システムは、構築された判定基準に基づいて、取得されるログデータが異常ログか、また、異常の前兆を示すログかを判定する。

国際公開第２０１６／１３２７１７号 国際公開第２０１７／１１５４５８号 特表２０１９－５０１４４８号公報 特開２０１４－１１５７６８号公報

しかしながら、特許文献１では、判定対象のログに何らかの対処が必要であると判定されたとしても、対処すべき順序の判別が困難であるという問題点がある。その理由は、実運用上の影響度合いに基づく対処の緊急度が考慮されていないためである。尚、特許文献２から４においてもこのような問題点を解決することができない。

本開示は、このような問題点を解決するためになされたものであり、ログデータに対する対処すべき順序を実運用に即して適切に判別するためのログ分析装置、方法及びプログラムを提供することを目的とする。

本開示の第１の態様にかかるログ分析装置は
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する判定部と、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する取得部と、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する特定部と、
を備える。

本開示の第２の態様にかかるログ分析方法は、
コンピュータが、
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定し、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得し、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する。

本開示の第３の態様にかかるログ分析プログラムは、
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する処理と、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する処理と、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する処理と、
をコンピュータに実行させる。

本開示により、ログデータに対する対処すべき順序を実運用に即して適切に判別するためのログ分析装置、方法及びプログラムを提供することができる。

本実施形態１にかかるログ分析装置の構成を示すブロック図である。 本実施形態１にかかるログ分析方法の流れを示すフローチャートである。 本実施形態２にかかるログ分析システムの全体構成を示すブロック図である。 本実施形態２にかかるログ分析装置の構成を示すブロック図である。 本実施形態２にかかるログ分析方法の流れを示すフローチャートである。 本実施形態３にかかるログ分析システムの全体構成を示すブロック図である。 本実施形態３にかかるログ分析装置の構成を示すブロック図である。 本実施形態３にかかるログ分析方法の流れを示すフローチャートである。

以下では、本開示の実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜実施形態１＞
図１は、本実施形態１にかかるログ分析装置１００の構成を示すブロック図である。ログ分析装置１００は、複数のノードを含む情報処理システム内の少なくとも一部のノードから出力されるログデータを分析するための情報処理装置である。ログ分析装置１００は、判定部１１０と、取得部１２０と、特定部１３０とを備える。

判定部１１０は、１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する。ここで、ログデータは、所定のノード上で稼働するオペレーティングシステム、ミドルウェア、アプリケーション等から出力されるログメッセージである。また、ログ判定モデルは、入力されるログデータについて所定の演算を行うことにより、運用又は保守担当者等（以下、管理者と呼ぶ。）による情報処理システムへの対処が必要か否かの判定結果を出力する判定ロジックである。例えば、ログ判定モデルは、当該判定ロジックが実装されたプログラムモジュールであるか、機械学習により学習されたモデルプログラムである。また、判定部１１０は、ログメッセージが処理状況の単なる通知を示す場合や、警告を示す場合には、対処が不要と判定する。一方、判定部１１０は、ログメッセージがエラーを示す場合には、管理者による対処が必要と判定する。また、判定部１１０は、エラー内容によっては対処が不要と判定してもよい。ここで、対処とは、例えば、管理者による障害の復旧作業といった一時的な処置や、設定変更、ハードウェアの交換又はソフトウェアの改修といった恒久的な処置が挙げられる。そして、一時的な処置には、例えば、アプリケーションの再起動、データパッチ、データリカバリ、ユーザへの障害の通知等が挙げられるが、これらに限定されない。

取得部１２０は、判定部１１０によりログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する。ここで、状況情報とは、例えば、ノードにおけるリソースの負荷状況や、ノードの稼働状況といった情報であるが、これらに限定されない。

特定部１３０は、取得部１２０により取得された状況情報に基づいて、ログデータに対する対処の緊急度を特定する。ここで、緊急度とは、例えば、管理者による対処の緊急度合いを示す情報であり、少なくとも２段階以上を区別できるものであればよい。

図２は、本実施形態１にかかるログ分析方法の流れを示すフローチャートである。まず、判定部１１０は、１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する（Ｓ１１）。ログデータに対する対処が必要と判定された場合、取得部１２０は、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する（Ｓ１２）。そして、特定部１３０は、状況情報に基づいて、ログデータに対する対処の緊急度を特定する（Ｓ１３）。尚、ステップＳ１１でログデータに対する対処が不要と判定された場合、当該ログ分析方法の処理を終了する。

このように本実施形態では、システムから出力されたログデータに対する、管理者による対処の要否を判定することに加えて、システムに関する現在の状況情報を用いて対処の緊急度を特定するものである。特に、複数のログデータから複数の種類のエラーが検出された場合、単にエラーの発生順に対処すればよいとは限らない。例えば、特定の対処に長時間を要する場合には、他の対処を先に実施した方が良い場合もある。そして、エラーの組み合わせが同じであっても、現在の状況情報に応じて対処の優先度が異なる場合もある。そのため、本実施形態により、対処が必要なログデータが多数存在した場合であっても、管理者はログデータに対する対処すべき順序を実運用に即して適切に判別することができる。

尚、ログ分析装置１００は、図示しない構成としてプロセッサ、メモリ及び記憶装置を備えるものである。また、当該記憶装置には、本実施形態にかかるログ分析方法の処理が実装されたコンピュータプログラムが記憶されている。そして、当該プロセッサは、記憶装置からコンピュータプログラムを前記メモリへ読み込み、当該コンピュータプログラムを実行する。これにより、前記プロセッサは、判定部１１０、取得部１２０及び特定部１３０の機能を実現する。

または、判定部１１０、取得部１２０及び特定部１３０は、それぞれが専用のハードウェアで実現されていてもよい。また、各装置の各構成要素の一部又は全部は、汎用または専用の回路（circuitry）、プロセッサ等やこれらの組合せによって実現されもよい。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組合せによって実現されてもよい。また、プロセッサとして、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＦＰＧＡ（field-programmable gate array）等を用いることができる。

また、ログ分析装置１００の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。また、ログ分析装置１００の機能がＳａａＳ（Software as a Service）形式で提供されてもよい。

＜実施形態２＞
本実施形態２は、上述した実施形態１の具体的な実施例である。図３は、本実施形態２にかかるログ分析システム２００の全体構成を示すブロック図である。ログ分析システム２００は、情報処理システム２０と、状況監視サーバ３１と、ログ分析装置３２と、システム構成ＤＢ（DataBase）３３と、モデルＤＢ３４と、アラートログＤＢ３５とを備え、これらがネットワークＮを介して接続されている。ネットワークＮは、ＬＡＮ（Local Area Network）、インターネット等の通信回線網である。

情報処理システム２０は、運用対象の情報処理システムであり、ノード２１、・・・ノード２ｎ（ｎは２以上の自然数。）を備える。ノード２１等の各ノードは、単体のコンピュータ装置、ブレードサーバのような情報処理基板、又は、仮想マシン等である。また、各ノードは、オペレーティングシステム、ミドルウェア及びアプリケーション等が稼働しているものとする。

状況監視サーバ３１は、情報処理システム２０の各ノードの稼働状況を監視するサーバ装置である。例えば、状況監視サーバ３１は、ログ分析装置３２から状況情報の取得要求を受信した場合、指定されたノードにおける現在の負荷状況や稼働状況の取得コマンドを発行し、コマンドの応答結果をログ分析装置３２へ返信する。ここで、負荷状況には、例えば、ノードのＣＰＵ（Central Processing Unit）、メモリ、ＨＤＤ（Hard Disk Drive）、ネットワーク帯域の使用率が挙げられるが、これらに限定されない。また、稼働状況は、ノードが現用系で稼働しているか、待機系で稼働しているか等を示すものとする。尚、状況監視サーバ３１自体が情報処理システム２０に含まれていても良い。また、状況監視サーバ３１は、公知の技術で実現可能であるため、詳細な説明を省略する。

システム構成ＤＢ３３は、情報処理システム２０の構成を管理する構成管理データベースである。システム構成ＤＢ３３は、各ノードの定義情報及び連携先情報を少なくとも管理する。ここで、ノードの定義情報は、ノードの役割や用途、ハードウェアスペック、稼働するソフトウェアに関する情報である。ノードの役割や用途とは、例えば、ノード上で稼働するアプリケーションが業務系であるか、管理（監視）系であるかといったことを特定できる情報であってもよい。また、連携先情報は、ノードの連携先のノードに関する情報、例えば、ホスト名やＩＰ（Internet Protocol）アドレス等である。

モデルＤＢ３４は、対処不要モデル３４１及び要対処モデル３４２を管理するデータベースである。対処不要モデル３４１及び要対処モデル３４２は、上述したログ判定モデルの一例である。

対処不要モデル３４１は、ログデータに対する対処が不要であるか否かを判定するモデルである。まず、対処不要モデル３４１は、ログデータが単なる通知や警告を示す場合、対処が不要と判定する。また、例えば、ログデータがエラーログであっても、情報処理システム２０へ実質的な影響がない場合がある。この場合、ログデータがエラーログであっても、情報処理システム２０に対する管理者による具体的な対処（操作、作業等）が不要となる。よって、対処不要モデル３４１は、このようなエラーログについても対処が不要と判定する。

要対処モデル３４２は、ログデータに対する具体的な対処方法が判明しているか否かを判定するモデルである。例えば、あるログデータに対して過去に具体的な対処方法が判明している場合がある。そこで、要対処モデル３４２は、このようなログデータについて、（具体的な対処方法が判明しているため）対処が必要であると判定する。

そのため、あるログデータが、対処不要モデル３４１及び要対処モデル３４２のいずれでも検出されない（ログフォーマットが不一致となる）場合、当該ログデータに対する対処が不明であることを示す。

また、対処不要モデル３４１及び要対処モデル３４２は、過去のログデータから特徴のある共通的な文字列と変数部分とを含むログフォーマットを用いて、入力されたログデータと照合し、一致又は不一致を照合結果として出力する。

また、対処不要モデル３４１及び要対処モデル３４２は、ログデータを入力として、設定されたパラメータを用いて所定の演算を行い、演算結果を出力する処理が実装されたプログラムモジュールやモデル式である。ここで、パラメータは、重み付け係数やバイアスを含む。尚、対処不要モデル３４１及び要対処モデル３４２は、ニューラルネットワーク、サポートベクターマシン等により実現可能である。例えば、対処不要モデル３４１及び要対処モデル３４２は、学習されたログフォーマットと入力されたログデータとを照合し、一致又は不一致を判定する。

アラートログＤＢ３５は、ノード２１から２ｎから出力されたログデータ対する分析結果等を管理するデータベースである。アラートログＤＢ３５は、ログフォーマット３５１、対処要否３５２及び対処方法３５３を対応付けて少なくとも管理する。ログフォーマット３５１は、各ノードから出力されたログデータのうち共通する文字列と文字列の可変部分とを定義したログメッセージの書式情報である。例えば、ログフォーマット３５１は、ログメッセージの固定文字列と変数部分とで構成される。ログフォーマット３５１は、予め設定されたものか、ログ分析装置３２により解析されて導出されたものであってもよい。尚、ログフォーマット３５１の代わりにログメッセージそのものを用いても良い。対処要否３５２は、ログフォーマット３５１に該当するログデータについて過去に管理者により対処が実施されたか否かを示す情報である。対処方法３５３は、対処要否３５２が「要」であるログフォーマット３５１について、管理者により実施された対処内容を示す情報である。対処方法３５３は、例えば、所定のジョブを再実行することや、アプリケーションの再起動などが挙げられるが、これに限定されない。

尚、システム構成ＤＢ３３、モデルＤＢ３４及びアラートログＤＢ３５のそれぞれは、記憶装置を備えるコンピュータ上で稼働するデータベース管理ソフトウェアにより実現可能である。

図４は、本実施形態２にかかるログ分析装置３２の構成を示すブロック図である。ログ分析装置３２は、記憶部４１と、メモリ４２と、ＩＦ（InterFace）部４３と、制御部４４とを備える。記憶部４１は、ハードディスク、フラッシュメモリ等の不揮発性記憶装置である。記憶部４１は、ログ分析プログラム４１１を記憶する。ログ分析プログラム４１１は、本実施形態にかかるログ分析方法の処理が実装されたコンピュータプログラムである。

メモリ４２は、ＲＡＭ（Random Access Memory）等の揮発性記憶装置であり、制御部４４の動作時に一時的に情報を保持するための記憶領域である。ＩＦ部４３は、ログ分析装置３２の外部との入出力を行うインタフェースである。例えば、ＩＦ部４３は、外部から取得したデータを制御部４４へ出力する。また、ＩＦ部４３は、制御部４４から受け付けたデータを外部へ出力する。

制御部４４は、ログ分析装置３２の各構成を制御するプロセッサつまり制御装置である。制御部４４は、記憶部４１からログ分析プログラム４１１をメモリ４２へ読み込み、ログ分析プログラム４１１を実行する。これにより、制御部４４は、判定部４４１、取得部４４２、特定部４４３、表示部４４４、登録部４４５及び学習部４４６の機能を実現する。

判定部４４１は、上述した判定部１１０の一例であり、対処不要モデル３４１及び要対処モデル３４２を用いて、入力されたログデータに対する対処の要否を判定する。ここで、判定部４４１は、ノード２１から２ｎのそれぞれから出力されるログメッセージを検知した場合に判定を行うものとする。そして、判定部４４１は、ログデータを対処不要モデル３４１及び要対処モデル３４２のログフォーマットと照合し、一致するか否かを判定する。尚、ログデータが対処不要モデル３４１及び要対処モデル３４２のいずれとも一致しない場合、当該ログデータは、対処方法が未知であるログ（以後、未知ログと呼ぶ。）といえる。

取得部４４２は、上述した取得部１２０の一例であり、判定部４４１においてログデータが対処不要モデル３４１と一致せず、要対処モデル３４２と一致する場合に、システム構成ＤＢ３３から、ログデータを出力したノードの定義情報や当該ノードの連携先情報を取得する。例えば、取得部４４２は、ログデータを出力したノードの識別情報をキーとしてシステム構成ＤＢ３３に対して検索を行う。

また、取得部４４２は、状況監視サーバ３１に対して負荷状況や稼働状況の取得要求を行う。尚、取得部４４２は、状況監視サーバ３１の機能を備えていても良い。

特定部４４３は、上述した特定部１３０の一例であり、取得部４４２により取得されたノードの定義情報や連携先情報から、ログデータが示すエラーによる情報処理システム２０への影響範囲を特定する。

また、特定部４４３は、取得部４４２により取得された負荷状況や稼働状況に基づいて、対処の緊急度を特定する。これにより、ログ分析装置３２は、ノードの最新の状態を動的に取得して、緊急度を特定するため、緊急度の精度がより向上する。

さらに、特定部４４３は、特定された情報処理システム２０への影響範囲に基づいて対処の緊急度を特定することが望ましい。これにより、緊急度を特定する精度がより向上する。

また、特定部４４３は、取得されたノードの定義情報に基づいて、対処の緊急度を特定してもよい。例えば、ノードの役割（定義情報）が管理系を示す場合、特定部４４３は、ノードの役割が業務系の場合と比べて緊急度を低く特定する。これにより、業務系の障害の復旧を優先させ、業務への影響を最小限に抑えることができる。

さらに、特定部４４３は、ログデータが発生した時間帯をさらに加味して、緊急度を特定することが望ましい。その理由は、同じエラーであっても発生した時間帯によって対処の緊急度が異なるためである。特に、ノードの役割（定義情報）が業務系を示す場合、特定部４４３は、エラーの発生時間帯が業務時間帯である日中であれば緊急度を相対的に高く、業務時間外である夜間であれば緊急度を相対的に低く特定する。一方、ノードの役割（定義情報）が夜間バッチの実行であれば、特定部４４３は、エラーの発生時間帯が夜間の場合に緊急度を相対的に高く、日中であれば緊急度を相対的に低く特定する。これにより、緊急度の妥当性が向上する。

また、特定部４４３は、ログデータに対応する対処方法をアラートログＤＢ３５から特定する。例えば、特定部４４３は、ログデータが該当するログフォーマット３５１に対応付けられた対処方法３５３を特定する。

表示部４４４は、特定部４４３により特定された緊急度に従ってログデータを表示装置（不図示）に表示する。これにより、管理者が対処の緊急度を明確に把握できる。このとき、表示部４４４は、特定された優先度と対応付けてログデータを表示してもよい。または、表示部４４４は、特定された優先度に従った順序でログデータを表示してもよい。併せて、表示部４４４は、特定部４４３により特定された情報処理システム２０への影響範囲を表示するとよい。

登録部４４５は、複数のログメッセージを分析してログフォーマットを決定し、決定したログフォーマット３５１をアラートログＤＢ３５に登録する。尚、ログフォーマットの決定の仕方は、公知の技術を用いることができるため、詳細な説明を省略する。

また、登録部４４５は、未知ログに対して管理者が判定した対処要否、対処方法の入力を受け付け、該当するログフォーマットに、対処要否と対処方法とを対応付けてアラートログＤＢ３５に登録する。

学習部４４６は、ログデータ（ログフォーマット）と、当該ログデータの判定結果（対処要否）及び対処内容（対処方法）とを学習用データとして、対処不要モデル３４１及び要対処モデル３４２を学習する。例えば、学習部４４６は、各ログフォーマット３５１に、対応する対処要否３５２をラベルとして付して学習用データとし、対処不要モデル３４１を機械学習する。また、学習部４４６は、対処要否３５２が「要」であるログフォーマット３５１について、対処方法３５３の有無をラベルとして付して学習用データとし、要対処モデル３４２を機械学習する。そして、判定部４４１は、学習後の対処不要モデル３４１及び要対処モデル３４２を用いて判定を行う。

図５は、本実施形態２にかかるログ分析方法の流れを示すフローチャートである。まず、判定部４４１は、ノード２１から２ｎのそれぞれから出力されるログデータ（ログメッセージ）を検知する（Ｓ２０１）。次に、判定部４４１は、ログデータを対処不要モデル３４１のログフォーマットと照合する（Ｓ２０２）。一致と判定した場合、ステップＳ２０１へ戻る。この場合、既知の対処不要なログであるため、管理者は対処を行わない。

一方、ステップＳ２０２で不一致と判定した場合、判定部４４１は、ログデータを要対処モデル３４２のログフォーマットと照合する（Ｓ２０３）。一致と判定した場合、取得部４４２は、システム構成ＤＢ３３から、ログデータを出力したノードの定義情報や当該ノードの連携先情報を取得する。そして、特定部４４３は、取得されたノードの定義情報や連携先情報から、ログデータが示すエラーによる情報処理システム２０への影響範囲を特定する（Ｓ２０４）。

続いて、取得部４４２は、状況監視サーバ３１に対して負荷状況や稼働状況の取得要求を行う。そして、特定部４４３は、取得された負荷状況や稼働状況、システムへの影響範囲、ノードの定義情報、連携先情報、ログデータが発生した時間帯に基づいて、対処の緊急度を特定する（Ｓ２０５）。

そして、特定部４４３は、ログデータに対応する対処方法をアラートログＤＢ３５から特定する（Ｓ２０６）。

その後、表示部４４４は、緊急度に基づいて表示する（Ｓ２０７）。例えば、表示部４４４は、ログデータ、緊急度、システムへの影響度合いを対応付けて表示装置に表示する。その後、ステップＳ２０１へ戻る。これにより、管理者は、表示装置に表示された内容、特に、緊急度を加味して、ログデータに対する対処を実施できる。

ステップＳ２０３で不一致と判定した場合、つまり、検知したログデータが未知ログであった場合、表示部４４４は、ログデータが未知ログである旨を表示装置に表示する。そして、管理者は、未知ログに対して対処要否を検討し、対処が「要」である場合、その対処方法を検討する。また、管理者は、未知ログのログフォーマットを決定してもよい。その後、管理者は、ログ分析装置３２に対して未知ログのログフォーマットと対処要否及び対象方法を入力する。そのため、ログ分析装置３２は、未知ログのログフォーマットと対処要否及び対象方法の入力を受け付ける（Ｓ２０８）。

そして、登録部４４５は、受け付けた未知ログのログフォーマットと対処要否及び対象方法とを対応付けて、アラートログＤＢ３５に登録する（Ｓ２０９）。

その後、学習部４４６は、アラートログＤＢ３５に登録されているログフォーマット３５１、対処要否３５２及び対処方法３５３を学習用データとして対処不要モデル３４１及び要対処モデル３４２を機械学習する（Ｓ２１０）。その後、ステップＳ２０１へ戻る。

このように、本実施形態によりログデータに対する対処すべき順序を実運用に即して適切に判別することができる。

＜実施形態３＞
本実施形態３は、上述した実施形態２の変形例である。図６は、本実施形態３にかかるログ分析システム２００ａの全体構成を示すブロック図である。ログ分析システム２００ａは、情報処理システム２０と、状況監視サーバ３１と、ログ分析装置３２ａと、システム構成ＤＢ３３と、モデルＤＢ３４ａと、アラートログＤＢ３５ａとを備え、これらがネットワークＮを介して接続されている。尚、以下の説明では、実施形態２と同様の構成には、同一の符号を付し、適宜、説明を省略する。

モデルＤＢ３４ａは、要対処モデル３４２の代わりに、要対処モデル（低緊急度）３４２１、要対処モデル（中緊急度）３４２２及び要対処モデル（高緊急度）３４２３を管理する。要対処モデル（低緊急度）３４２１、要対処モデル（中緊急度）３４２２及び要対処モデル（高緊急度）３４２３は、緊急度ごとのログ判定モデルである。

アラートログＤＢ３５ａは、ログフォーマット３５１に緊急度３５４をさらに対応付けて管理する。

図７は、本実施形態３にかかるログ分析装置３２ａの構成を示すブロック図である。ログ分析装置３２ａは、記憶部４１ａと、メモリ４２と、ＩＦ部４３と、制御部４４ａとを備える。記憶部４１ａは、ログ分析プログラム４１１ａを記憶する。ログ分析プログラム４１１ａは、本実施形態にかかるログ分析方法の処理が実装されたコンピュータプログラムである。

制御部４４ａは、記憶部４１ａからログ分析プログラム４１１ａをメモリ４２へ読み込み、ログ分析プログラム４１１ａを実行する。これにより、制御部４４ａは、判定部４４１ａ、取得部４４２ａ、特定部４４３ａ、表示部４４４、登録部４４５ａ及び学習部４４６ａの機能を実現する。

登録部４４５ａは、未知ログに対して管理者が判定した対処要否、対処方法及び緊急度の入力を受け付け、該当するログフォーマットに、対処要否と対処方法と緊急度とを対応付けてアラートログＤＢ３５ａに登録する。

学習部４４６ａは、ログデータに対する対処が必要と判定された場合、当該ログデータにおける学習用データを用いて、特定された緊急度に対応するログ判定モデルを学習する。例えば、中緊急度と特定された場合、学習部４４６ａは、対処要否３５２が「要」、かつ、緊急度３５４が「中」であるログフォーマット３５１について、対処方法３５３の有無をラベルとして付して学習用データとし、要対処モデル（中緊急度）３４２２を機械学習する。要対処モデル（低緊急度）３４２１及び要対処モデル（高緊急度）３４２３についても同様である。

判定部４４１ａは、複数のログ判定モデル（要対処モデル（低緊急度）３４２１、要対処モデル（中緊急度）３４２２及び要対処モデル（高緊急度）３４２３）のそれぞれに対して、ログデータに対する対処の要否を判定する。

特定部４４３ａは、ログデータの判定に用いられたログ判定モデルに対応する緊急度をさらに加味して、緊急度を特定する。

取得部４４２ａは、特定された緊急度に基づき、ログデータへの対処内容をさらに特定する。

図８は、本実施形態３にかかるログ分析方法の流れを示すフローチャートである。以下では、図５と同様の処理については説明を省略する。ステップＳ２０２で不一致と判定した場合、判定部４４１ａは、ログデータを要対処モデル（高緊急度）３４２３のログフォーマットと照合する（Ｓ２０３ａ）。不一致と判定した場合、判定部４４１ａは、ログデータを要対処モデル（中緊急度）３４２２のログフォーマットと照合する（Ｓ２０３ｂ）。不一致と判定した場合、判定部４４１ａは、ログデータを要対処モデル（低緊急度）３４２１のログフォーマットと照合する（Ｓ２０３ｃ）。

ステップＳ２０３ａ、Ｓ２０３ｂ及びＳ２０３ｃのいずれかで一致と判定した場合、ステップＳ２０４へ進む。ステップＳ２０４の後、特定部４４３ａは、取得された負荷状況や稼働状況、システムへの影響範囲、ノードの定義情報、連携先情報、ログデータが発生した時間帯に加えて、一致と判定したログ判定モデルに対応する緊急度に基づいて、対処の緊急度を特定する（Ｓ２０５ａ）。例えば、ステップＳ２０３ａにおいて一致と判定した場合、特定部４４３ａは、対処の緊急度を「高」と特定する。

そして、特定部４４３ａは、特定された緊急度に基づき、ログデータに対応する対処方法をアラートログＤＢ３５ａから特定する（Ｓ２０６ａ）。例えば、ステップＳ２０３ａにおいて一致と判定した場合、特定部４４３ａは、ログデータが該当するログフォーマット３５１及び「高」である緊急度３５４に対応付けられた対処方法３５３を特定する。

ステップＳ２０３ｃで不一致と判定した場合、つまり、検知したログデータがいずれの要対処モデルとも一致しなかった場合、未知ログとなる。未知ログの場合、管理者は、未知ログに対して対処要否を検討し、対処が「要」である場合、その対処方法及び緊急度を検討する。また、管理者は、未知ログのログフォーマットを決定してもよい。その後、管理者は、ログ分析装置３２に対して未知ログのログフォーマットと対処要否、対象方法及び緊急度を入力する。そのため、ログ分析装置３２は、未知ログのログフォーマットと対処要否、対象方法及び緊急度の入力を受け付ける（Ｓ２０８ａ）。

そして、登録部４４５ａは、受け付けた未知ログのログフォーマットと対処要否、対象方法及び緊急度とを対応付けて、アラートログＤＢ３５ａに登録する（Ｓ２０９ａ）。

その後、学習部４４６ａは、アラートログＤＢ３５ａに登録されているログフォーマット３５１、対処要否３５２、対処方法３５３及び緊急度３５４を学習用データとして対処不要モデル３４１、要対処モデル（低緊急度）３４２１、要対処モデル（中緊急度）３４２２及び要対処モデル（高緊急度）３４２３を機械学習する（Ｓ２１０ａ）。その後、ステップＳ２０１へ戻る。

このように、本実施形態によってもログデータに対する対処すべき順序を実運用に即して適切に判別することができる。

＜その他の実施形態＞
尚、上述の実施形態では、ハードウェアの構成として説明したが、これに限定されるものではない。本開示は、任意の処理を、ＣＰＵにコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本開示は上記実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本開示は、それぞれの実施形態を適宜組み合わせて実施されてもよい。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記Ａ１）
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する判定部と、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する取得部と、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する特定部と、
を備えるログ分析装置。
（付記Ａ２）
前記状況情報は、前記ノードのリソースの負荷状況又は稼働状況の少なくともいずれかを含む
付記Ａ１に記載のログ分析装置。
（付記Ａ３）
前記取得部は、
前記システムの構成を管理する構成データベースから、前記ノードの定義情報をさらに取得し、
前記特定部は、
前記定義情報をさらに加味して、前記緊急度を特定する
付記Ａ１又はＡ２に記載のログ分析装置。
（付記Ａ４）
前記取得部は、
前記構成データベースから、前記ノードの連携先のノードに関する連携先情報をさらに取得し、
前記特定部は、
前記連携先情報をさらに加味して、前記緊急度を特定する
付記Ａ３に記載のログ分析装置。
（付記Ａ５）
前記特定部は、
前記ログデータが発生した時間帯をさらに加味して、前記緊急度を特定する
付記Ａ１乃至Ａ４のいずれか１項に記載のログ分析装置。
（付記Ａ６）
前記ログデータと、当該ログデータの判定結果及び対処内容とを学習用データとして、前記ログ判定モデルを学習する学習部をさらに備える
付記Ａ１乃至Ａ５のいずれか１項に記載のログ分析装置。
（付記Ａ７）
前記ログ分析装置は、前記緊急度ごとの複数のログ判定モデルを有し、
前記学習部は、
前記ログデータに対する対処が必要と判定された場合、当該ログデータにおける前記学習用データを用いて、前記特定された緊急度に対応する前記ログ判定モデルを学習し、
前記判定部は、前記複数のログ判定モデルのそれぞれに対して、前記ログデータに対する対処の要否を判定し、
前記特定部は、
前記ログデータの判定に用いられたログ判定モデルに対応する緊急度をさらに加味して、前記緊急度を特定する
付記Ａ６に記載のログ分析装置。
（付記Ａ８）
前記特定された緊急度に従って前記ログデータを表示する表示部をさらに備える
付記Ａ１乃至Ａ７のいずれか１項に記載のログ分析装置。
（付記Ａ９）
前記特定部は、
前記特定された緊急度に基づき、前記ログデータへの対処内容をさらに特定する
付記Ａ１乃至Ａ８のいずれか１項に記載のログ分析装置。
（付記Ｂ１）
コンピュータが、
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定し、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得し、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する
ログ分析方法。
（付記Ｃ１）
１以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する処理と、
前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する処理と、
前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する処理と、
をコンピュータに実行させるログ分析プログラム。

１００ ログ分析装置
１１０ 判定部
１２０ 取得部
１３０ 特定部
２００ ログ分析システム
２０ 情報処理システム
２１ ノード
２ｎ ノード
Ｎ ネットワーク
３１ 状況監視サーバ
３２ ログ分析装置
３３ システム構成ＤＢ
３４ モデルＤＢ
３４１ 対処不要モデル
３４２ 要対処モデル
３５ アラートログＤＢ
３５１ ログフォーマット
３５２ 対処要否
３５３ 対処方法
４１ 記憶部
４１１ ログ分析プログラム
４２ メモリ
４３ ＩＦ部
４４ 制御部
４４１ 判定部
４４２ 取得部
４４３ 特定部
４４４ 表示部
４４５ 登録部
４４６ 学習部
２００ａ ログ分析システム
３２ａ ログ分析装置
３４ａ モデルＤＢ
３４２１ 要対処モデル（低緊急度）
３４２２ 要対処モデル（中緊急度）
３４２３ 要対処モデル（高緊急度）
３５ａ アラートログＤＢ
３５４ 緊急度
４１ａ 記憶部
４１１ａ ログ分析プログラム
４４ａ 制御部
４４１ａ 判定部
４４２ａ 取得部
４４３ａ 特定部
４４５ａ 登録部
４４６ａ 学習部

Claims (10)

1. １以上のログ判定モデルを用いて、所定のログデータに対する対処の要否を判定する判定部と、
   前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する取得部と、
   前記状況情報に基づいて、前記ログデータに対する対処の緊急度を特定する特定部と、
   を備え、
   前記判定部は、前記緊急度ごとに設けられた複数のログ判定モデルのそれぞれに対して、前記ログデータに対する対処の要否を判定し、
   前記特定部は、前記ログデータの判定に用いられたログ判定モデルに対応する緊急度にさらに基づいて、前記緊急度を特定する
   ログ分析装置。
2. 前記状況情報は、前記ノードのリソースの負荷状況又は稼働状況の少なくともいずれかを含む
   請求項１に記載のログ分析装置。
3. 前記取得部は、
   前記システムの構成を管理する構成データベースから、前記ノードの定義情報をさらに取得し、
   前記特定部は、
   前記定義情報にさらに基づいて、前記緊急度を特定する
   請求項１又は２に記載のログ分析装置。
4. 前記取得部は、
   前記構成データベースから、前記ノードの連携先のノードに関する連携先情報をさらに取得し、
   前記特定部は、
   前記連携先情報にさらに基づいて、前記緊急度を特定する
   請求項３に記載のログ分析装置。
5. 前記特定部は、
   前記ログデータが発生した時間帯にさらに基づいて、前記緊急度を特定する
   請求項１乃至４のいずれか１項に記載のログ分析装置。
6. 前記ログデータと、当該ログデータの判定結果及び対処内容とを学習用データとして、前記ログ判定モデルを学習する学習部をさらに備える
   請求項１乃至５のいずれか１項に記載のログ分析装置。
7. 前記ログ分析装置は、前記緊急度ごとの複数のログ判定モデルを有し、
   前記学習部は、
   前記ログデータに対する対処が必要と判定された場合、当該ログデータにおける前記学習用データを用いて、前記特定された緊急度に対応する前記ログ判定モデルを学習し、
   前記判定部は、前記複数のログ判定モデルのそれぞれに対して、前記ログデータに対する対処の要否を判定し、
   前記特定部は、
   前記ログデータの判定に用いられたログ判定モデルに対応する緊急度にさらに基づいて、前記緊急度を特定する
   請求項６に記載のログ分析装置。
8. 前記特定された緊急度に従って前記ログデータを表示する表示部をさらに備える
   請求項１乃至７のいずれか１項に記載のログ分析装置。
9. コンピュータが、
   緊急度ごとに設けられた複数のログ判定モデルを用いて、前記複数のログ判定モデルのそれぞれに対して、所定のログデータに対する対処の要否を判定し、
   前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得し、
   前記状況情報と前記ログデータの判定に用いられたログ判定モデルに対応する緊急度とに基づいて、前記ログデータに対する対処の緊急度を特定する
   ログ分析方法。
10. 緊急度ごとに設けられた複数のログ判定モデルを用いて、前記複数のログ判定モデルのそれぞれに対して、所定のログデータに対する対処の要否を判定する処理と、
    前記ログデータに対する対処が必要と判定された場合、当該ログデータの出力元のノードを含むシステムに関する現在の状況情報を取得する処理と、
    前記状況情報と前記ログデータの判定に用いられたログ判定モデルに対応する緊急度とに基づいて、前記ログデータに対する対処の緊急度を特定する処理と、
    をコンピュータに実行させるログ分析プログラム。

Images