JP2016024786A - ログ解析装置 - Google Patents

Abstract

【課題】複数のアプリケーションのログを解析して、異常事象を検知するログ解析装置を提供する。【解決手段】システムの異常事象を解析するログ解析装置５０において、各アプリケーションから出力されるエラーに関連するエラーログを統合するログ統合部５２ａと、システムの過去の異常事象発生毎に、各アプリケーションから出力されたエラーログをまとめたログパターンと発生した異常事象の内容を対応させてデータベース化したログパターン登録データ１５０を記憶する記憶部５８と、統合ログとログパターン登録データの各ログパターンを比較して、統合ログと前記各ログパターンとの類似度を算出して、ログパターン登録データの中から類似度の高いログパターンを検出するログパターン検出部５２ｂと、検出した類似度の高いログパターンについて、対応する異常事象の内容を通知する通知部５２ｃと、を備える。【選択図】図１

Description

本発明は、システムを構成する複数のアプリケーションのログを解析するログ解析装置に関する。

近年、複数のアプリケーションからなるシステムが、各所で運用されている。例えば、証券通信システムは、通信制御プログラム、ゲートウェイアプリケーション、業務アプリケーション等から構成される。証券通信システムでは、証券取引においてユーザ（機関投資家・証券会社）から受け取った注文情報等を、接続仕様に準拠した通信プロトコルに則って、メッセージ形式変換・通信制御を行うことで、接続先（取引相手となる機関投資家・証券会社）とのやり取りを実現する。

図１６は、一般的な証券通信システム１の構成の一部を示す図である。証券通信システム１は、接続先Ａ（機関投資家、証券会社）のＰＣ（personal computer）２０、接続先Ｂ（機関投資家、証券会社）のＰＣ２０、及びユーザ（機関投資家・証券会社）のＰＣ２２等と接続される。証券通信システム１には、アプリ―ケーションとして、通信制御プログラム１０、ゲートウェイアプリケーション（不図示）、業務アプリケーション１４が含まれる。

通信制御プログラム１０は、ゲートウェイアプリケーションからの指示に従い、接続先のＰＣ２０との接続仕様に準拠した通信プロトコルに則って、メッセージ形式変換・通信制御を行うものである。ゲートウェイアプリケーションは、業務アプリケーション１４のインタフェースに従い、業務アプリケーション１４との送受信メッセージ解析、及び、通信制御プログラム１０への接続／切断指示、注文指示を行うものである。また、業務アプリケーション１４は、ユーザのＰＣ２２へのインタフェースの提供、ゲートウェイアプリケーションへの注文指示、注文状況の管理を行うものである。

このようなシステムにおいてアプリケーションに異常が発生した場合には、運用担当者が各アプリケーションの保守担当者に調査依頼を出し、受領した調査結果に基づき、運用担当者が原因を特定していた。例えば、通信制御プログラム１０から出力されるイベントログ１００および業務アプリケーション１４から出力されるイベントログ１００から、それぞれエラーログ１１０が検出されたとする。

運用担当者は、モニタで、２つのアプリケーション（通信制御プログラム１０及び業務アプリケーション１４）で、エラーログ１１０が発生したことを知る。そして、運用担当者は、どのアプリケーションがシステムエラーの原因であるかを判別できない場合もあり、その場合には、運用担当者は、原因を切り分けるために、それぞれの保守担当者に調査を依頼する。ここでは、通信制御プログラム１０および業務アプリケーション１４の保守担当者にそれぞれ調査を依頼する。運用担当者は、それぞれの保守担当者からの検討結果を受信して、原因を特定することになるので、原因特定までかなりの時間がかかることになる。
そして、人がログを監視する方法では監視能力に限界があるため、複数のコンピュータのログを取得し、ログ蓄積データに統計分析を行う監視システムが提案されている（特許文献１）

特開２００１−１４１８８号公報

複数のアプリケーションから構成されるシステムにおいて、複数のアプリケーションにまたがった異常がシステム内に発生した場合、システムの運用担当者が短時間で原因を特定するのは容易でない。

本願発明は、上記課題に鑑み、複数のアプリケーションのログを解析して、異常事象を検知するログ解析装置を提供することを目的とする。

上記目的を達成するために、複数のアプリケーションが動作するシステムで、各アプリケーションから出力されるログに基づき、前記システムの異常事象を解析するログ解析装置において、前記各アプリケーションから出力されるエラーに関連するエラーログを統合するログ統合部と、前記システムの過去の異常事象発生毎に、前記各アプリケーションから出力された前記エラーログをまとめたログパターンと前記発生した異常事象の内容を対応させてデータベース化したログパターン登録データを記憶する記憶部と、前記統合ログと前記ログパターン登録データの各ログパターンを比較して、前記統合ログと前記各ログパターンとの類似度を算出して、前記ログパターン登録データの中から類似度の高いログパターンを検出するログパターン検出部と、検出した類似度の高いログパターンについて、対応する異常事象の内容を通知する通知部と、を備える。

本発明によれば、複数のアプリケーションのログを解析して、異常事象を検知するログ解析装置を提供することができる。

証券通信システムを含む全体システムの構成を示す図である。 運用担当者から保守担当者へ連絡の流れを示す図である。 異常が発生した場合のログ解析処理の流れを示す図１である。 異常が発生した場合のログ解析処理の流れを示す図２である。 統合ログの具体例１を示す図である。 統合ログの具体例２を示す図である。 ログパターン登録データの構成の具体例を示す図である。 パターンマッチング方式の具体例１を説明するための図である。 パターンマッチング方式の具体例２を説明するための図である。 パターンマッチング処理のメインのフローチャートである。 パターンマッチング処理のサブルーチンである。 次レコード目以降の処理のサブルーチンである。 類似度の通知を説明するサブルーチンである。 第２のパターンマッチング方式の手順を説明するサブルーチンである。 第２のパターンマッチング方式での、比較の具体例１を示す図である。 第２のパターンマッチング方式での、比較の具体例２を示す図である。 一般的な証券通信システム１の構成の一部を示す図である。

以下、図面に従って本発明の実施形態を説明する。本実施形態では、複数のアプリケーションから構成されるシステムとして、証券通信システム１を例にする。

図１は、証券通信システム１にログ解析装置５０が接続された全体システム３００の構成を示す図である。全体システム３００は、証券通信システム１、ログ収集システム４０、ログ解析装置５０、接続先（接続先Ａや接続先Ｂ）のＰＣ（personal computer）２０やユーザのＰＣ２２等から構成される。

証券通信システム１は、証券取引においてユーザから受け取った注文情報等を、接続仕様に準拠した通信プロトコルに則って、メッセージ形式変換・通信制御を行うことで、接続先（取引相手となる機関投資家・証券会社）とのやり取りを実現するものである。

証券通信システム１は、接続先（接続先Ａや接続先Ｂ）のＰＣ２０やユーザのＰＣ２２に接続される。証券通信システム１には、種々のアプリケーションが搭載される。本例では、例えば、通信制御プログラム１０、ゲートウェイアプリケーション１２及び業務アプリケーション１４が備えられる。通信制御プログラム１０、ゲートウェイアプリケーション１２及び業務アプリケーション１４の各アプリケーションは、それぞれ専用のサーバあるいはＰＣで処理が実行される。

通信制御プログラム１０は、ゲートウェイアプリケーションからの指示に従い、接続先ＰＣ２０との接続仕様に準拠した通信プロトコルに則って、メッセージ形式変換・通信制御を行う。

ゲートウェイアプリケーション１２は、業務アプリケーション１４のインタフェースに従い、業務アプリケーション１４との送受信メッセージ解析、及び、通信制御プログラムアプリケーションを使用することにより、通信制御プログラム１０への接続／切断指示、注文指示を行う。

業務アプリケーション１４は、ユーザＰＣ２２へのインタフェースの提供、ゲートウェイアプリケーション１２への注文指示、注文状況の管理を行うものである。業務アプリケーション１４は、ユーザに応じて複数種備えられ、図１では業務アプリケーションＡ、業務アプリケーションＢとして示す。業務アプリケーションＡ、業務アプリケーションＢに対応して、ゲートウェイアプリケーション１２も、ゲートウェイアプリケーションＡ、ゲートウェイアプリケーションＢが備えられる。

証券通信システム１が稼働中は、各アプリケーションから、イベントログ１００が出力される。ログ収集システム４０は、証券通信システム１の各アプリケーションから出力されたイベントログ１００の中から、エラーログ（エラーログ及び警告ログを含む）１１０を収集するものである。ログ収集システム４０は、収集したエラーログ１１０を、ログ解析装置５０に通知する。

ログ解析装置５０は、収集したエラーログ１１０と過去のエラーログパターンを比較して、システムのエラー（異常事象）の原因を推定して、監視端末８０に通知するものである。ログ解析装置５０は、ログ解析部５２及び記憶部５８を備える。

ログ解析部５２は、ＣＰＵ５４、ログ解析プログラム５６を備え、ログ解析プログラム５６を読込んだＣＰＵ５４により実行される機能部である。ログ解析部５２は、ＣＰＵ５４により実行される処理として、ログ統合部５２ａ、ログパターン検出部５２ｂ、通知部５２ｃを備える。

記憶部５８は、証券通信システム１で過去に異常事象(障害)が発生した場合のエラーログとその異常事象の具体的な内容あるいは原因となるアプリケーション（エラーメッセージ）が記載されたログパターン登録データ１５０を記憶する。ログパターン登録データ１５０は、証券通信システム１で過去に発生した障害のデータベースである。システムで異常事象が発生する場合には、複数のログが連続して出力されることが多い。そのため、直接の異常事象を示すエラーログとその直前に連続して出力される警告ログとの組み合わせを、ログパターンとして登録しておき、新たに発生した異常事象の原因特定に利用する。エラーログパターンの具体例は、図７で後述する。

ログ統合部５２ａは、各アプリケーションから出力されるエラーログ１１０をタイムスタンプ順に統合して、統合ログ１２０を生成する。ログパターン検出部５２ｂは、統合ログ１２０とログパターン登録データ１５０の各エラーログパターン（ログパターンとも略す）を比較して、統合ログとログパターンとの類似度を算出して、ログパターン登録データ１５０の中から、今回のエラーと類似度の高い過去のログパターンを検出する。

通知部５２ｃは、ログパターン検出部５２ｂで検出された類似度の高いログパターンにつき、記憶部５８から対応するエラーメッセージを読み出して、監視端末８０に通知する。監視クライアント（運用担当者）は、監視端末８０に表示されたメッセージが見て、保守担当者への連絡等の適当な処置を行う。

図２は、ログ解析装置５０で類似度の高いログパターンが検出され、運用担当者から保守担当者へ連絡がされる流れを示す図である。ログ解析部５２のログ統合部５２ａは、ログ収集システム４０で収集されたエラーログ１１０から、統合ログ１２０を生成する。ログ解析部５２のログパターン検出部５２ｂが、統合ログ１２０と記憶部５８に記憶されたログパターン登録データ１５０をマッチングさせて、類似度を算出する。ログ解析部５２は、類似度の高い過去のログパターンを、通知部５２ｃを介して、監視端末８０（運用担当者）に通知する。運用担当者は、通知された事象の内容（メッセージ）を見て、問題となるアプリケーションの保守担当者に調査・対処の依頼をする。

図３、図４は、証券通信システム１で具体的に異常が発生した場合に行われるログ解析処理の流れを示す図である。例えば、図３に示すように、証券通信システム１の業務アプリケーションＡ１４及び通信制御プログラム１０のイベントログ１００で、それぞれエラーログ１１０が検出されたとする。この場合には、図４で示すように、通信制御プログラム１０のイベントログ１００のエラーログ１１０と、業務アプリケーションＡ１４のイベントログ１００のエラーログ１１０が、ログ収集システム４０によって収集される。

通信制御プログラム１０のイベントログ１００のエラーログ１１０と、業務アプリケーションＡ１４のイベントログ１００のエラーログ１１０が、ログ統合部５２ａによって統合されて、統合ログ１２０となる。ログ解析部５２は、統合ログ１２０とログパターン登録データ１５０を比較し類似度を算出して、類似度の高い事象（ログパターン）を運用担当者に通知する。

運用担当者は、通知されたログパターンの内容から、いずれのあるいは両方のアプリケーションの保守担当者に調査依頼をすべきかを判断し、調査依頼すべき保守担当者に調査依頼を行う。調査依頼された保守担当者は、検出されたエラーログ１１０に関して調査を行い、調査結果を運用担当者に通知する。運用担当者は、保守担当者からの調査結果を確認して、原因を特定して、必要な処置を行う。

このように、対象のシステムにおいて発生する異常事象について、複数アプリケーションから出力されるエラーログを組み合わせて過去のログパターンのマッチングを行うことで、現行での原因特定作業に比べて、原因切分け作業が容易となり、システム復旧までの作業時間を短縮できる。さらに、ログパターンとの類似度が異常の予兆として通知される場合もあるので、運用担当者が異常事象を早期に検出し、事前に対処することも可能となる。これにより、異常事象発生からシステム復旧までの作業時間をより短縮することができる。

次に、ログパターン検出部５２ｂにおいて行われる類似度検出（パターンマッチング）を、具体的に説明する。なお、以下の例では、説明をわかりやすくするため、通信制御プログラム１０と業務アプリケーションＡ１４の２つのアプリケーションで、エラーが発生したとする。なお、業務アプリケーションＡ１４を業務アプリケーション１４と略す。

図５、図６は、統合ログ１２０の具体例をそれぞれ示す図である。図５は、第１の統合ログ１２０ａの例である。左が通信制御プログラム１０のイベントログ１００ａで、右が業務アプリケーション１４のイベントログ１００ｂである。イベントログ１００ａ、１００ｂは、タイムスタンプ、種別、接続先、コード、メッセージの各情報から構成される。タイムスタンプは、当該ログの発生時刻である。種別は、ログの種別（情報、警告、エラー）を示す。接続先は、証券通信システム１からの接続先を示し、任意の名称が設定される。コードは、各アプリケーションごとに付与される、ログのコード番号である。

通信制御プログラム１０のイベントログ１００ａと業務アプリケーション１４のイベントログ１００ｂから、ログ収集システム４０によって警告ログとエラーログが収集される。収集された警告ログとエラーログからログ統合部５２ａによって、統合ログ１２０（第1の統合ログ１２０ａと呼ぶ）が生成される。

統合ログ１２０は、タイムスタンプ順に並べられる。統合ログ１２０は、タイムスタンプ、出力元、種別、接続先、コードの各情報から構成される。また、統合ログ１２０での各エラーログの番号を、古い順から１、２・・・とする。統合ログ１２０での各エラーログを、レコードとも呼ぶ。

図６は、第２の統合ログ１２０ｂの例である。通信制御プログラム１０のイベントログ１００ａと業務アプリケーション１４のイベントログ１００ｂの具体的なログが異なる例である。第２の統合ログ１２０ｂも、第1の統合ログ１２０ａと同様に構成される。

図７は、ログパターン登録データ１５０の構成の具体例を示す図である。前述のように、ログパターン登録データ１５０は、過去の異常事象（障害）発生時に、各アプリケーションから出力されたエラー（警告を含む）ログを、タイムスタンプ順に配列したものである。図７では、３つのログパターン例（Ａ００００１〜Ａ００００３）を示す。Ａ００００１〜Ａ００００３が、それぞれログパターン１，２，３と呼ぶ。

パターンＩＤは、ログパターンの番号である。ログパターン毎に統合ログ１２０とのマッチングが行われる。メッセージは、各ログパターンに対応して発生した異常事象の原因や内容で、監視端末８０に表示される。

枝番Ｅは、ログパターンに含まれる各ログの連番である。出力元は、ログを出力したプログラム（通信制御プログラム／業務アプリケーション）を示す。種別はログの種別（警告／エラー）である。接続先は、証券通信システムからの接続先で、任意の名称が設定される。コードは、各アプリケーションごとに付与される、ログのコード番号である。

例えば、ログパターン１は、枝番１の通信制御プログラム１０のエラーログ（種別エラー、接続先Ａ、コード２１０）、枝番２の業務アプリケーション１４のエラーログ（種別エラー、接続先Ａ、コード２０１）、枝番３の通信制御プログラム１０のエラーログ（種別エラー、接続先Ａ、コード２０１）の、計３つのエラーログから構成される。これは、メッセージに示された内容の異常事象が発生した際に、対応して枝番１〜３のエラーログが時間順に検出されたことを示す。ログパターン２は、枝番１〜枝番６の6個のエラーログから構成される。

図８、図９は、パターンマッチング方式の具体例を説明するための図で、第1のパターンマッチング方式の図である。図５で示した第１の統合ログ１２０ａを例にする。まず、比較開始レコードが設定される。最初は、比較開始レコードがレコードの１番に設定される（Ｓ＝１）。レコード１から、ログパターン登録データ１５０との比較を開始する。パターンＩＤの各枝番１の中で、レコード１と一致するログパターンを探し、レコード１と一致する枝番１のログパターンについて、枝番２以降との一致を判断して、類似度Ｘを算出する。

第１の統合ログ１２０ａのレコード１とログパターン１の枝番１を比較するが不一致であるので、ログパターンをログパターン１からログパターン２に代えて、ログパターン２の枝番１と比較する。図８に示すように、第１の統合ログ１２０ａのレコード１とログパターン２の枝番１は一致する。レコード１とログパターン２の枝番１が一致したので、ログパターン２につき、枝番２〜枝番６とレコード２〜６を比較する。

枝番２とレコード２が一致する。この時点で、枝番１と枝番２がそれぞれ一致しているので、類似度Ｘは、２／６＝３３％と算出される。更に、枝番３〜５までが、レコード３〜５と一致するので、５／６＝０．８３により類似度Ｘは８３％と算出される。そして、枝番６とレコード６は不一致なので、最終的に類似度Ｘは８３%となる。なお、ログパターン１については、類似度Ｘは０％とする。次に、レコード１とログパターン３以降の枝番１につき、順番に比較を行い、上と同様にして、各ログパターンでの類似度を算出していく。そして、レコード１を比較開始レコードとした場合に、全てのログパターンで、類似度を算出する。レコード１を比較開始レコードとした比較の終了後、比較開始レコードをレコード１からレコード２に代えて、同様に全てのログパターンについて、類似度を算出する。

図９は、パターンマッチング処理の具体例２で、第２の統合ログ１２０ｂに対して、比較開始レコードをレコード２とした場合である。図９に示すように、第２の統合ログ１２０ｂのレコード２とログパターン１の枝番１が一致したので、ログパターン１の枝番２、枝番３とレコード３〜４を比較する。レコード３と枝番２が一致するので、類似度Ｘは６６％になり、さらに、レコード４と枝番３が一致するので、ログパターン１の類似度Ｘは１００%と算出される。

図１０〜図１３のフローチャートを用いて、図８，図９で一例を示したパターンマッチング処理手順の流れを説明する。パターンマッチング処理は、主にログ解析部５２により実行される。

図１０は、パターンマッチング処理のメインのフローチャートである。ログ統合部５２ａは、統合ログ１２０を生成する（ステップＳ１０）。ログパターン検出部５２ｂは、統合ログ１２０での比較開始レコードの番号をＳとし、初期値としてＳ＝１とする（ステップＳ１２）。前述のように、比較開始レコードは、ログパターン登録データ１５０との比較を開始する統合ログ１２０のレコード番号である。

また、ログ統合部５２ａは、統合ログ１２０を追加する（ステップＳ１４）。ログ統合部５２ａは、ログ収集システム４０から新たなエラーログの通知があれば、各アプリケーションで出力された警告ログやエラーログを、タイムスタンプ順に統合ログ１２０に追加する。ログパターン検出部５２ｂは、記憶部５８からログパターン登録データ１５０を読み出す（ステップＳ１６）。ログパターン検出部５２ｂは、パターンマッチングを実行する（ステップＳ１８）。

図１１は、パターンマッチング処理のサブルーチンである。ログパターンの番号をＰ（１，２・・・、ｅｎｄ）とし、ログパターン１から順番に比較していくため、初期値として、Ｐ＝１を設定する（ステップＳ３０）。最後のログパターンをＰｅｎｄとする。
統合ログの比較を開始するレコードＲとして、Ｓを設定する（ステップＳ３２）。初期値として、Ｒ＝１とする。

ログパターンＰの中で比較される枝番（１，２・・・、ｅｎｄ）につき、初期値として、Ｅ＝１とする（ステップＳ３４）。最後の枝番をＥｅｎｄと表す。

ログパターン検出部５２ｂは、統合ログ１２０のレコードＲとログパターンＰの枝番Ｅを比較する（ステップＳ３６）。最初は、レコード１とログパターン１の枝番１のデータを比較する。

ログパターン検出部５２ｂは、レコードのデータと枝番のデータを比較して、出力元、種別、接続先、コードの全てが一致するかを判断する（ステップＳ３８）。ログパターン検出部５２ｂは、出力元等全てが一致すると判断すると（ステップＳ３８ＹＥＳ）、（１／Ｅｅｎｄ×１００）を類似度Ｘ（Ｐ）に加算する（ステップＳ４０）。類似度Ｘ（Ｐ）は、ログパターンＰの類似度である。

次に、ログパターン検出部５２ｂは、次レコード目以降のパターンマッチングを行う。枝番１で一致したからである。図１２は、次レコード目以降のパターンマッチング処理のサブルーチンである。統合ログ１２０の比較するレコードＲ＝Ｒ＋１、ログパターンの比較する枝番Ｅ＝Ｅ＋１とする（ステップＳ６０）。統合ログ１２０のレコードＲとログパターンＰの枝番Ｅを比較する（ステップＳ６２）。

ログパターン検出部５２ｂは、出力元、種別、接続先、コードの全てが一致するかを判断する（ステップＳ６４）。ログパターン検出部５２ｂは、全てが一致すると判断すると（ステップＳ６４ＹＥＳ）、（１／Ｅｅｎｄ×１００）を類似度Ｘ（Ｐ）に加算する（ステップＳ６６）。ログパターン検出部５２ｂは、統合ログ１２０の比較するレコードＲ＝Ｒ＋１、ログパターンの比較する枝番Ｅ＝Ｅ＋１とする（ステップＳ６８）。

一方、ログパターン検出部５２ｂは、全てが一致はしないと判断すると（ステップＳ６４ＮＯ）、ステップＳ６６をジャンプして、ステップＳ６８に進む。

ステップＳ６８に続き、ログパターン検出部５２ｂは、枝番Ｅ>Ｅｅｎｄであるかを判断し（ステップＳ７０）、枝番Ｅ>Ｅｅｎｄでないと判断すると（ステップＳ７０ＮＯ）、ステップＳ６２に戻り、次のレコードと枝番との比較を行う。ログパターン検出部５２ｂは、枝番Ｅ>Ｅｅｎｄであると判断すると（ステップＳ７０ＹＥＳ）、このサブルーチンを終了する。これにより、ログパターンＰの類似度Ｘが算出される。図１１のステップＳ４４に進む。

ログパターン検出部５２ｂは、比較するログパターンを切換えるため、ログパターンＰ＝Ｐ＋１とする（ステップＳ４４）。また、ログパターン検出部５２ｂは、ステップＳ３８で全てが一致はしないと判断すると（ステップＳ３８ＮＯ）、ステップＳ４０及びステップＳ４２をジャンプして、ステップＳ４４に進む。この場合には、前述したように、このログパターンの類似度Ｘ＝０とする。

つまり、第１のパターンマッチング方式では、比較開始レコードと枝番１が一致した場合に限り、そのログパターンについて枝番２以降の比較を行い類似度Ｘを算出し、比較開始レコードと枝番１が不一致の場合には、そのログパターンについては枝番２以降の比較は行わず、類似度Ｘ＝０とする。

以上説明した第１のパターンマッチング方式によれば、一番古いレコードであるレコード１を基準にして各ログパターンの類似度を算出して、次のレコード２を基準として各ログパターンの類似度を算出するようにして、統合ログ１２０の開始レコードを１つずつタイムスタンプの新しいものに切換えていくので、パターンマッチングの処理中に、統合ログ１２０にエラーログが順次追加させていく場合にも、容易に対応できる。

ログパターン検出部５２ｂは、ログパターンＰ>Ｐｅｎｄであるかを判断し（ステップＳ４６）、ログパターンＰ>Ｐｅｎｄでないと判断すると（ステップＳ４６ＮＯ）、ステップＳ３２に戻り、次のログパターンでの比較を行う。ログパターン検出部５２ｂは、ログパターンＰ＞Ｐｅｎｄであると判断すると（ステップＳ４６ＹＥＳ）、類似度の通知を行う（ステップＳ４８）。

図１３は、類似度の通知を説明するサブルーチンである。ログパターン検出部５２ｂは、類似度Ｘｍａｘに、Ｘ（１）〜Ｘ（Ｐｅｎｄ）の最大値を設定する（ステップＳ８０）。Ｘ（１）はログパターン１で算出された類似度で、Ｘ（Ｐｅｎｄ）はログパターンＰｅｎｄで算出された類似度を示し、つまり、Ｘｍａｘは、図１２のサブルーチンで得られたログパターンの中での最大の類似度である。

ログパターン検出部５２ｂは、類似度Ｘｍａｘ＞８０％であるかを判断する（ステップＳ８２）。８０％は、保守担当者の監視端末８０に通知を行うか否かで設定された閾値である。ログパターン検出部５２ｂが、類似度Ｘｍａｘ＞８０％であると判断すると（ステップＳ８２ＹＥＳ）、通知部５２ｃは、監視端末８０に類似度Ｘｍａｘに該当する"ログパターン"、"ログパターンに対応するメッセージ"、"類似度"等を通知する（ステップＳ８４）。通知後、ログパターン検出部５２ｂは、図１０のステップＳ２０に進む。

なお、監視端末８０へ通知する類似度Ｘの閾値を８０%にしたのは、一例である。また、類似度Ｘが最大となったログパターンを通知するとしたが、これに限られるものではなく、類似度Ｘが所定以上になったログパターンを全て通知するようにしてもよい。

そして、ログパターン検出部５２ｂは、類似度Ｘｍａｘ＞８０％ではないと判断すると（ステップＳ８２ＮＯ）、監視端末８０等への通知は行わず、図１０のステップＳ２０に進む。

ログパターン検出部５２ｂは、Ｓ＝Ｓ＋１とする（ステップＳ２０）。比較開始レコードＳの番号を１つ増やす。図９で説明したように、Ｒ＝２が比較開始レコードに設定される。ログパターン検出部５２ｂは、パターンマッチング処理の停止指示を受けたかを判断する（ステップＳ２２）。パターンマッチング処理の停止は、運用担当者の指示により実行される。ログパターン検出部５２ｂは、パターンマッチング処理の停止指示を受けていないと判断すると（ステップＳ２２ＮＯ）、ステップＳ１４に戻る。

ログパターン検出部５２ｂは、パターンマッチング処理の停止指示を受けたと判断すると（ステップＳ２２ＹＥＳ）、この処理を終了する。なお、ログパターン検出部５２ｂは、統合ログ１２０の最後のレコードまで、パターンマッチングが終了した場合には、統合ログ１２０に新たなエラーログが追加されるまで、ステップＳ１６で停止していてもよい。

パターンマッチングの方式は、図１２で紹介した方式に限られず、色々な方式が考えられる。他のパターンマッチング方式の１つとして、第２のパターンマッチング方式を、図１４、図１５を用いて説明する。

図１４は、第２のパターンマッチング方式の処理の手順を説明するフローチャートである。なお、統合ログ１２０の生成やログパターン登録データ１５０の記憶部５８からの読出しは、図１０での処理（ステップＳ１０，Ｓ１４、Ｓ１６）と同じであるので、説明は省略する。

ログパターン検出部５２ｂは、ログパターンＰ＝１とする（ステップＳ９０）。ログパターン検出部５２ｂは、統合ログの比較開始レコードＳ＝１とする（ステップＳ９２）。ログパターン検出部５２ｂは、全ての枝番と対応するレコードを比較する（ステップＳ９４）。一致の判断は、ステップＳ３８の場合と同様である。

つまり、第1のパターンマッチング方式では、枝番１と比較開始レコードが一致したログパターンに限り、枝番２〜枝番ｅｎｄとレコードの比較を行ったが、第２のパターンマッチング方式では、枝番１と比較開始レコードが不一致のログパターンでも、そのログパターンの全ての枝番と対応するレコードを比較する。

ログパターン検出部５２ｂは、類似度Ｘを算出する（ステップＳ９６）。類似度Ｘの算出は、図１１での説明と同様である。ログパターン検出部５２ｂは、比較開始レコードを１つ繰り下げるため、Ｓ＝Ｓ＋１とする（ステップＳ９８）。ログパターン検出部５２ｂは、比較されるレコードが最後のレコードＲｅｎｄに達したかを判断する（ステップＳ１００）。ログパターン検出部５２ｂは、比較されるレコードが最後のレコードＲｅｎｄに達していないと判断すると（ステップＳ１００ＮＯ）、ステップＳ９４に戻る。ログパターン検出部５２ｂは、比較されるレコードが最後のレコードＲｅｎｄに達したと判断すると（ステップＳ１００ＹＥＳ）、監視端末８０に最大の類似度等を通知する（ステップＳ１０２）。通知内容は、ステップＳ８４と同等でよい。ログパターン検出部５２ｂは、比較したログパターンの中で最大の類似度が、所定の閾値（８０%）を超した場合に、通知するようにしてもよい。

ログパターン検出部５２ｂは、比較するログパターンを切換えるために、Ｐ＝Ｐ＋１とする（ステップＳ１０４）。ログパターン検出部５２ｂは、Ｐ＞Ｐｅｎｄであるかを判断し（ステップＳ１０６）、Ｐ＞Ｐｅｎｄでないと判断すると（ステップＳ１０６ＮＯ）、ステップＳ９２に戻る。Ｐｅｎｄは、ログパターンの最後のパターンを示す。ログパターン検出部５２ｂは、Ｐ＞Ｐｅｎｄであると判断すると（ステップＳ１０６ＹＥＳ）、第２のパターンマッチング処理を終了する。

第２のパターンマッチング方式による比較の具体例を、図１５Ａ、図１５Ｂに示す。ここでは、枝番の番号をＥ１、Ｅ２等とし、レコードの番号をＲ１、Ｒ２等と示す。図１５Ａの右側に、統合ログ１２０ｃを示し、解析される統合ログ１２０ｃが、Ｒ１〜Ｒｅｎｄのレコードから構成されるとする。図１５Ａは、ログパターン１でのパターンマッチングである。

まず、統合ログ１２０ｃから“Ｒ１、Ｒ２、Ｒ３”が比較のレコードとして選択され、ログパターン１の“Ｅ１、Ｅ２、Ｅ３”とそれぞれ比較されて、類似度Ｘ１が算出される。次に、統合ログ１２０ｃから“Ｒ２、Ｒ３、Ｒ４”が比較のレコードとして選択され、ログパターン１の“Ｅ１、Ｅ２、Ｅ３”と比較されて、類似度Ｘ２が算出される。この処理が、Ｒｅｎｄになるまで行われる。Ｒｅｎｄに達すると、ログパターン１での処理を終了する。類似度Ｘ１〜Ｘｅｎｄ−２の中で、最大の類似度が通知される。

続いて、ログパターンが１から２に切換えられる。図１５Ｂは、ログパターン２でのパターンマッチング処理である。まず、統合ログ１２０ｃから“Ｒ１〜Ｒ６”が比較のレコードとして選択され、ログパターン２の“Ｅ１〜Ｅ６”とそれぞれ比較されて、類似度Ｘが算出される。次に、統合ログ１２０から“Ｒ２〜Ｒ７”が比較するレコードとして選択され、ログパターン２の“Ｅ１〜Ｅ６”と比較されて、類似度Ｘが算出される。以降は、図１５Ａでの説明と同等で、ログパターン２での処理を終了する。最大の類似度が通知される。

以上のように、第２のパターンマッチング方式では、統合ログ１２０の各レコードと各枝番を同時に比較するので、第１のパターンマッチング方式では、取りこぼしてしまうログパターン（開始レコードと枝番１が不一致であるが、それ以降での一致性が極めて高いようなケース）でも、見逃すことなく通知することができる。

以上説明した実施形態により、少なくとも以下の効果が奏せられる。
・監視対象のシステムにおいて発生する異常事象について、現行では複数のアプリケーション間にまたがる異常の原因特定には時間がかかっていたが、複数アプリケーションから出力されるログを組み合わせて、過去の異常事象のログパターンとのパターンマッチングを行うことで、原因切分け作業が容易となり、システム復旧までの作業時間を短縮できる。
・さらに、ログパターンとの類似度を異常の予兆として通知することによって、運用担当者による異常事象の早期検出、及び、事前対処が可能となり、さらに、異常発生からシステム復旧までの作業時間を短縮できる。

なお、上記実施形態では、複数アプリケーションのシステム例として、証券通信システムを例にしたが、交通システムや金融システム等他のシステムにも適用可能である。また、上記実施形態では、ログ解析部５２をＣＰＵ５４によるソフトウェア処理により実現されると説明したが、これに限るものではなく、一部あるいは全てをハードウェアで構成してもよい。

また、本発明は上述した実施形態そのままに限定されるものではく、実施段階でのその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施形態に示される全構成要素を適宜組み合わせても良い。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。このような、発明の趣旨を逸脱しない範囲内において種々の変形や応用が可能であることはもちろんである。

１ 証券通信システム
１０ 通信制御プログラム
１２ ゲートウェイアプリケーション
１４ 業務アプリケーション
２０ 接続先のＰＣ
２２ ユーザのＰＣ
４０ ログ収集システム
５０ ログ解析装置
５２ ログ解析部
５２ａ ログ統合部
５２ｂ ログパターン検出部
５２ｃ 通知部
５４ ＣＰＵ
５６ ログ解析プログラム
５８ 記憶部
８０ 監視端末
１００、１００ａ、１００ｂ イベントログ
１１０ エラーログ
１２０ 統合ログ
１２０ａ 第１の統合ログ
１２０ｂ 第２の統合ログ
１５０ ログパターン登録データ
３００ 全体システム

Claims (4)

1. 複数のアプリケーションが動作するシステムで、各アプリケーションから出力されるログに基づき、前記システムの異常事象を解析するログ解析装置において、
   前記各アプリケーションから出力されるエラーに関連するエラーログを統合するログ統合部と、
   前記システムの過去の異常事象発生毎に、前記各アプリケーションから出力された前記エラーログをまとめたログパターンと前記発生した異常事象の内容を対応させてデータベース化したログパターン登録データを記憶する記憶部と、
   前記統合ログと前記ログパターン登録データの各ログパターンを比較して、前記統合ログと前記各ログパターンとの類似度を算出して、前記ログパターン登録データの中から類似度の高いログパターンを検出するログパターン検出部と、
   検出した類似度の高いログパターンについて、対応する異常事象の内容を通知する通知部と、を備える
   ことを特徴とするログ解析装置。
2. 前記ログ統合部は、前記エラーログをタイムスタンプ順に並べて前記統合ログを生成し、
   前記ログパターン検出部は、タイムスタンプ順に並んだ前記統合ログの複数のエラーログと、タイムスタンプ順に並べられた前記各ログパターンの中の複数のエラーログを、一対一で比較して類似度を算出する
   ことを特徴とする請求項１に記載のログ解析装置。
3. 複数のアプリケーションが動作するシステムで、各アプリケーションから出力されるログに基づき、前記システムの異常事象を解析するログ解析方法において、
   前記各アプリケーションから出力されるエラーに関連するエラーログを統合する処理と、
   前記システムの過去の異常事象発生毎に、前記各アプリケーションから出力された前記エラーログをまとめたログパターンと前記発生した異常事象の内容を対応させてデータベース化したログパターン登録データを記憶する記憶部から前記ログパターン登録データを読み出す処理と、
   前記統合ログと前記ログパターン登録データの各ログパターンを比較して、前記統合ログと前記各ログパターンとの類似度を算出して、前記ログパターン登録データの中から類似度の高いログパターンを検出する処理と、
   前記検出した類似度の高いログパターンについて、対応する異常事象の内容を通知する処理と、を含む
   ことを特徴とするログ解析方法。
4. 複数のアプリケーションが動作するシステムで、各アプリケーションから出力されるログに基づき、前記システムの異常事象を解析するログ解析装置のコンピュータで実行されるプログラムにおいて、
   前記各アプリケーションから出力されるエラーに関連するエラーログを統合する処理と、
   前記システムの過去の異常事象発生毎に、前記各アプリケーションから出力された前記エラーログをまとめたログパターンと前記発生した異常事象の内容を対応させてデータベース化したログパターン登録データを記憶する記憶部から前記ログパターン登録データを読み出す処理と、
   前記統合ログと前記ログパターン登録データの各ログパターンを比較して、前記統合ログと前記各ログパターンとの類似度を算出して、前記ログパターン登録データの中から類似度の高いログパターンを検出する処理と、
   前記検出した類似度の高いログパターンについて、対応する異常事象の内容を通知する処理と、を含む
   ことを特徴とするプログラム。

Images