JP2012168702A - ログ解析装置およびログ解析方法 - Google Patents

Abstract

【課題】システム全体としてシステム内部の処理フローの挙動を容易に把握可能とする。
【解決手段】複数のサーバそれぞれから実行結果を示すログを取得し、取得したログを、当該ログに応じたプロセスと対応付けて、データベース１０１にあらかじめ格納された複数のプロセスを実行する順に記述したイベントパターン内に書き込み、要求に応じてイベントパターンをデータベース１０１から読み出して出力する。
【選択図】図１

Description

本発明は、ログを解析するためのログ解析装置およびログ解析方法に関する。

近年、検索システムに代表されるような、多数のサーバを互いに連携させることにより、大規模なデータ処理や大規模な演算処理を実現する大規模分散処理システムに関する研究が進められている。

このようなシステムでは、多数のサーバに処理を分散させることにより、巨大データの扱いや演算時間の短縮を実現させている。

その一方、運用保守の観点からは、多数のサーバを連動させて処理を行うため、システム内部の挙動の理解が困難になること、問題発生時の原因特定に時間がかかること、性能評価及びボトルネックの特定が困難であることなどが問題とされている。

これらの問題を解決するために、各サーバのメトリクス（ＣＰＵ使用率やディスクＩ／Ｏ等）を監視する方法や、各サーバにおけるログを監視する方法などが使われている。

各サーバのメトリクスを監視する方法としては、インターネット上のサーバを監視するシステムが流用されている。例えば、ＮａｇｉｏｓやＺａｂｂｉｘ等に代表される、サーバのメトリクスの情報を取得し、グラフなどを用いてユーザに可視化するシステムが広く使われている。

Ｎａｇｉｏｓは、リアルタイムでサーバのメトリクスを表示し、問題発生時には電子メールやＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）等を用いてユーザへ通知する仕組みを持っており、サーバの監視に広く用いられている。

また、Ｚａｂｂｉｘは、収集したデータをデータベースに保存することに特徴があり、多数のサーバを監視対象とすることができる。

また、各マシンにおけるログを監視する方法としては、ＳｐｌｕｎｋやＣｈｕｋｗａ等に代表されるシステムが提案されている。

Ｓｐｌｕｎｋは、上述したメトリクスに加えてｓｙｓｌｏｇ等のテキスト形式のログや、各種アプリケーションが出力するログを収集し、インデックスを体系的に作成してデータの解析を行い、ユーザへ通知する仕組みを持つシステムである。

また、Ｃｈｕｋｗａは、大規模環境において、メトリクスや非構造的なテキストベースのログを収集するシステムである（例えば、非特許文献１参照。）。その仕組みは、まず監視対象のホストにＡｇｅｎｔと呼ばれるメトリクスやログを収集する仮想マシンを配置する。次に、Ａｇｅｎｔからのデータを受け取るＣｏｌｌｅｃｔｏｒと呼ばれる仮想マシンを、データを収集するマシンに配置する。データを収集したマシンでは、ＭａｐＲｅｄｕｃｅと呼ばれる分散システムを活用するデータ処理を行い、必要とするデータをデータベースに蓄積し、最終的にＷｅｂブラウザ上でメトリクス等の情報を表示する。これには、監視対象のホストの数をスケールアウトさせることができるところに特色があり、収集する対象を独自に規定することで、大規模環境において様々なデータを収集・蓄積することができる。

さらに、Ｃｈｕｋｗａにおいて収集したデータを解析するシステムとして、ＳＡＬＳＡと呼ばれるシステムがある。ＳＡＬＳＡでは、各ホスト内での処理シーケンスやアプリケーションレベルでの処理シーケンスを可視化することが可能である。非特許文献２に記載された技術においては、Ｈａｄｏｏｐの各ＤａｔａＮｏｄｅ内における処理フローおよびＴａｓｋＴｒａｃｋｅｒによるＭａｐＲｅｄｕｃｅ処理の処理フローを可視化する。それにより、システムの挙動に対する理解を深め、さらに障害の検知に対する有用性を示している。

Ariel Rabkin, Randy Katz. "Chukwa: A system for reliable large-scale log collection", 24th Large Installation System Administration Conference(LISA'10), San Jose, CA, USA, Nov 7-12, 2010. Jiaqi Tan, Xinghao Pan, Solia Kavulya, Rajeev Gandhi and Priya Narasimhan. "SALSA: Analyzing Logs as StAte Machines", First USENIX Workshop on the Analysis of System Logs(WASL '08), San Diego, CA, USA, Dec 7, 2008.

しかしながら、上述した技術においては、大規模分散処理システム全体として、システム内部でのエラーに至る過程やその影響範囲を特定したり、システム内部における性能劣化の要因を示すログの検出を行うことが困難であるという問題点がある。

本発明の目的は、大規模分散処理システムにおいて、あらかじめ記憶した当該システム内部の各処理フローの情報を用いて、各マシンから収集したログを解析することにより、当該システム全体としてシステム内部の処理フローの挙動を把握可能とすることである。

本発明のログ解析装置は、
イベントが発生してから該イベントに応じた値を得るまでに実行される複数のプロセスを複数のサーバそれぞれが実行した結果を示す複数のログを解析するログ解析装置であって、
前記複数のプロセスを実行する順に記述したイベントパターンをあらかじめ格納するデータベースと、
前記複数のサーバそれぞれから前記ログを取得するログ取得部と、
前記ログ取得部が取得したログを、該ログに応じたプロセスと対応付けて、前記イベントパターン内に書き込むログ整理部と、
当該ログ解析装置の外部からの要求に応じて、前記イベントパターンを前記データベースから読み出して出力する出力部とを有する。

また、本発明のログ解析方法は、
イベントが発生してから該イベントに応じた値を得るまでに実行される複数のプロセスを複数のサーバそれぞれが実行した結果を示す複数のログを解析するログ解析方法であって、
前記複数のサーバそれぞれから前記ログを取得する処理と、
前記取得したログを、該ログに応じたプロセスと対応付けて、データベースにあらかじめ格納された前記複数のプロセスを実行する順に記述したイベントパターン内に書き込む処理と、
前記イベントパターンを前記データベースから読み出す処理と、
前記データベースから読み出したイベントパターンを出力する処理とを行う。

以上説明したように、本発明においては、システム全体としてシステム内部の処理フローの挙動を容易に把握可能とすることができる。

本発明における構成要素単位での全体構成の一例を示す図である。 本発明における処理手順の全体構成の一例を示す図である。 あるイベントが発生してから、そのイベントに応じた値を得るまでに実行される複数のプロセスにおける一連の処理の一例を示すシーケンス図である。 図３に示した処理が行われる場合にデータベースに格納されるイベントパターンの一例を示す図である。 図３に示した処理が行われたときにエラーが発生する場合としてデータベースに格納されるイベントパターンの第１の例を示す図である。 図３に示した処理が行われたときにエラーが発生する場合としてデータベースに格納されるイベントパターンの第２の例を示す図である。 図３に示した処理が行われたときにエラーが発生する場合としてデータベースに格納されるイベントパターンの第３の例を示す図である。 ログを収集してから、データベースに記憶されているイベントパターンを用いて当該ログを解析するまでの処理を説明するためのフローチャートである。 収集したログを用いて作成されたイベントパターンの一例を示す図である。 エラーログを検出した場合、そのエラーログを含むイベントパターンを検索する概念図である。 各処理におけるタイムスタンプの一例をシーケンス図に書き込んだ図である。 １つのイベントにおけるプロセス間のタイムスタンプの差を計算する例を示す図である。 計算した発生時刻の差分をイベントパターンのテーブル内に保存した例を示す図である。 本発明のログ解析方法を実施するための大規模分散処理システムの一形態を示す図である。 図１４に示したログ解析装置の内部構成の一例を示す図である。 図１５に示したログ解析装置における処理を説明するためのフローチャートである。

以下に、本発明の実施の形態について図面を参照して説明する。

まず、以下に使用する用語の意味を、以下のように定義する。

［開発時の成果物］：大規模分散処理システムの各種設計書、およびソースコード等の実装に関する情報。

［イベント］：システム外部からの入力等、分散処理の起点となるもの。

［プロセス］：大規模分散処理における処理の機能単位。

［処理フロー］：大規模分散処理において、イベントから始まる内部処理が、外部への出力などで完了するまでの処理の流れをプロセス単位に時系列で整理したもの。

［イベントパターン］：処理フローをデータベースに保存する形式で表現したデータ形式。例えば、イベントの名前をテーブルの名前に、そのイベントから始まる処理において発生する順序で、各行ごとに、発生するプロセス名、処理内容、および出力されるログを持つもの。

次に、本発明のログ解析方法の概要について説明する。

図１は、本発明における構成要素単位での全体構成の一例を示す図である。

図２は、本発明における処理手順の全体構成の一例を示す図である。

図１および図２に示すように、開発段階で作られる基本設計書、外部設計書、内部設計書、詳細設計書などの各種設計書と、当該システムのソースコードとに基づいて、システム外部からの入力等の特定のイベントごとに、プロセス単位での相互作用を時系列で処理フローとして整理する。

続いて、整理した各処理フローごとに、イベントの名前をテーブル名とし、プロセスの処理フロー内での発生の順序、発生したプロセス名、処理の内容、出力が想定されるログを各行に記録した形式でデータベース１０１に保存（格納）する。以降、この保存されたデータテーブルを「イベントパターン」と称する。

ここまでの処理（図１および図２の破線Ａで囲んだ部分）は、事前準備である。

ここで、プロセスとは、大規模分散システムにおいて特定の処理を実行する機能単位を示すものであり、必ずしも一般的なＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が認識するプロセスの単位とは限らない。

図３は、あるイベントが発生してから、そのイベントに応じた値を得るまでに実行される複数のプロセスにおける一連の処理の一例を示すシーケンス図である。

図３に示すように、あるイベント「Ｅｖｅｎｔ Ｘ」が発生してから、複数のプロセス「Ｐｒｏｃｅｓｓ Ａ」、「Ｐｒｏｃｅｓｓ Ｂ」、「Ｐｒｏｃｅｓｓ Ｃ」および「Ｐｒｏｃｅｓｓ Ｄ」が実行されて、その結果の値「Ｖａｌｕｅ Ｖ」が得られる。

図４は、図３に示した処理が行われる場合にデータベース１０１に格納されるイベントパターンの一例を示す図である。

図４に示した例では、Ｌ_XはイベントＸの開始を表すログを表す。また、Ａ、Ｂ、ＣおよびＤはプロセス名を表す。また、Ｐ_A ¹等はそのプロセスにおける処理の内容を表すものであり、具体的にはユーザが処理の内容を記述する。また、Ｌ_A ¹等はその時点での出力が想定される、プロセスの実行を表すログ（「ＳＴＡＲＴ」等）を表すものとし、そのプロセスが実行されたことが確認できるものである。また、ａ_A ¹、ｂ_A ¹、ｃ_A ¹等はＰ_A ¹の実行中に出力されるログとして想定されるログを表す。なお、この中には、Ｐ_A ¹を実行中に出力される、一連の処理の終了を伴わないエラーログも含まれる。また、Ｌ_A ¹に該当するログが存在しない場合は、処理が行われるタイミングで出力されるログを選択するものとする。Ｖａｌｕｅ Ｖは、Ｅｖｅｎｔ Ｘの入力に対するシステムからの出力を表す。ただし、イベントによってはＶａｌｕｅが存在しないものもある。

また、事前準備として、データベース１０１に、Ｅｖｅｎｔ Ｘから始まる処理の途中でエラーが発生し、処理が途中で終了してしまう場合も同様の形式で保存しておく。処理の終了を伴うエラーが発生するケースは、一般的に１つのイベントに対して複数存在する。

図５は、図３に示した処理が行われたときにエラーが発生する場合としてデータベース１０１に格納されるイベントパターンの第１の例を示す図である。

図５に示したＥｖｅｎｔ Ｘｅ１は、イベントＸの入力が発生した後、プロセスＡにおいてイベントＸから始まる処理の終了を伴うエラーログＥ_A ¹が出力されることを示している。

また、同様に、プロセスＢまたはプロセスＣにおいてエラーログが出力されるものも保存しておく。

図６は、図３に示した処理が行われたときにエラーが発生する場合としてデータベース１０１に格納されるイベントパターンの第２の例を示す図である。

図６に示したＥｖｅｎｔ Ｘｅ２は、イベントＸの入力が発生した後、プロセスＢにおいてイベントＸから始まる処理の終了を伴うエラーログＥ_B ²が出力されることを示している。

図７は、図３に示した処理が行われたときにエラーが発生する場合としてデータベース１０１に格納されるイベントパターンの第３の例を示す図である。

図７に示したＥｖｅｎｔ Ｘｅ３は、イベントＸの入力が発生した後、プロセスＣにおいてイベントＸから始まる処理の終了を伴うエラーログＥ_C ³が出力されることを示している。

ここまでの処理が、図１および図２の破線Ａで囲んだ部分で示した事前準備である。

次に、図１および図２の破線Ｂで囲んだ部分で示したログ収集・保存の処理について説明する。

大規模分散処理システムにおいては、処理を分散して複数のサーバ（マシン）に実行させる。そのため、それぞれのサーバにおける実行結果を示すログを収集する必要がある。

まず、複数の監視対象のマシンに仮想マシンを設置し、その仮想マシンがホストで出力されるログを収集する。

次に、データを蓄積するマシン上で、ホストからログデータを受け取る仮想マシンを設置する。そして、この仮想マシンからデータをファイル（データベース１０１）に書き込む。なお、これらのログ収集方法の実現に関しては、既存技術を用いることができる。

図８は、ログを収集してから、データベース１０１に記憶されているイベントパターンを用いて当該ログを解析するまでの処理を説明するためのフローチャートである。

収集したログからイベントごとのデータテーブル（上述したイベントパターン）を作成するために、収集したログデータの中からイベントの開始を表すログを検出する（ステップＳ１）。イベントの開始を表すログは各イベントパターンに１つずつ含まれている（図４に示したＬ_X）。したがって、このログをキーワードとして収集したログの集合の中から検索することで検出を行う。

続いて、以降の処理がデータベース１０１に保存されたイベントパターンのいずれに該当するかを以下のようにして判別する。

まず、検出されたログが、検出された時刻を中心として、あらかじめ設定された時間の間に収集されたログを検索対象とし（ステップＳ２）、各プロセスにおいて事前準備でデータベース１０１に格納されたログが出力されたかどうかに基づいて、イベントパターンを決定する（ステップＳ３〜Ｓ６）。

これらの処理は、イベントごとに既に保存されているイベントパターンから作成することができるものであり、処理が終了するまでに出力されるべきログが、収集したログに含まれているかどうかを分岐の条件としたものである。さらに、収集したログは、該当するイベントパターンの中で、設計・実装から出力が想定される（上述した事前準備で格納されたイベントパターンの）ログの部分と入れ替えてログから作成されるイベントパターンとしてデータベース１０１に保存（格納）する。

図９は、収集したログを用いて作成されたイベントパターンの一例を示す図である。

図９に示したＬ_X、Ｌ_A ¹、ａ_A ¹等は、実際に出力（収集）されたログを表す。

また、実際に出力されたログには、ログの出力時刻を示すタイムスタンプが含まれている。ここで、このタイムスタンプをプロセスの実行を表すログから抽出して、１つの情報としてデータベース１０１に保存しておく。

図９に示した例では、ＴはＬ_Xが出力された時刻を表し、Ｔ¹はＬ_A ¹が出力された時刻を表す。これは、収集したログの集合の中からタイムスタンプＴを含むログＬ_Xが検出され、次にタイムスタンプＴ¹を含むＬ_A ¹が検出されたことを意味する。Ｔ²以下についても同様に、該当のログが出力された時刻を表す。

このようにしてデータベース１０１に保存した、収集したログから作成するイベントパターンを用いて、エラーログ検出時に障害を発生させる起点となったイベントの特定を行う。

次に、図１および図２の破線Ｃで囲んだ部分で示したエラーログ検出の処理について説明する。

図１０は、エラーログを検出した場合、そのエラーログを含むイベントパターンを検索する概念図である。

エラーログの検出は、収集したログの中からエラーをキーワード（Ｅｒｒｏｒ（エラー）やＷａｒｎ（警告））を用いて検索することで行う。

データベース１０１に保存されているログから作成されるイベントパターンの集合の中から、検出されたエラーログを含むものを検索し、イベントパターンを特定する。

エラーログを含むイベントパターンは、エラーログを含むが処理自体は正常に完了するもの（図４に示したａ_A ¹、ｂ_A ¹などにエラーログが含まれるもの）と、そのエラーにより処理が終了するもの（図５に示したＥ_A ¹などが検出された場合）とがある。図１０に示した例の場合、エラーログｅ_A ¹が時刻００４に始まったＥｖｅｎｔ Ｙの処理の途中で発生したことを意味する（この例では、Ｅｖｅｎｔ Ｙから始まる処理自体は完了している。上述したエラーログを含むイベントパターンのうち、前者の場合）。これにより、検出されたエラーログが、どのイベントから始まる処理の実行中に発生したものなのかを特定する。

次に、図１および図２の破線Ｄで囲んだ部分で示した性能低下調査の処理について説明する。

収集したログに基づいて作成したイベントパターンのデータベース１０１を用いて、プロセス単位での処理の遅延時間の算出という方法で、システムの性能低下の検出を行う。

まず、収集したログから作成した各イベントパターンにおいて、共通のプロセスで発生順序が異なるものを抽出し、それらのタイムスタンプ間の差分を計算する。

あるプロセスから他のプロセスへ処理が流れ、再び元のプロセスに処理が戻り、さらに他のプロセスへ処理が移動するまでの経過時間を算出する。差分を計算する時間を上述したように共通のプロセス間に限定する理由は、マシンが異なる場合、必ずしも内部時刻を共通化できないためである。

図１１は、各処理におけるタイムスタンプの一例をシーケンス図に書き込んだ図である。

図１１に示すように、最初のプロセスＡでのログのタイムスタンプが示す時刻はＴ¹であり、次のプロセスＢでのログのタイムスタンプが示す時刻はＴ²であり、次のプロセスＣでのログのタイムスタンプが示す時刻はＴ³であり、次のプロセスＢでのログのタイムスタンプが示す時刻はＴ⁴であり、次のプロセスＤでのログのタイムスタンプが示す時刻はＴ⁵であり、次のプロセスＢでのログのタイムスタンプが示す時刻はＴ⁶であり、次のプロセスＡでのログのタイムスタンプが示す時刻はＴ⁷である。

図１２は、１つのイベントにおけるプロセス間のタイムスタンプの差を計算する例を示す図である。ここでのタイムスタンプが示す時刻は、図１１にて挙げたものである。

図１２に示すものである場合、イベントパターンの中で複数現れるプロセスはＡおよびＢである。プロセスＡは発生順序の１および７に現れるため、この間の時間間隔をタイムスタンプから算出する（Ｔ⁷−Ｔ¹）。また、プロセスＢは発生順序２、４および６に現れるため、それぞれの時間間隔を算出する（Ｔ⁶−Ｔ⁴、Ｔ⁴−Ｔ²）。

このように計算した時間間隔をイベントパターンに追加して保存する。

図１３は、計算した発生時刻の差分をイベントパターンのテーブル内に保存した例を示す図である。

図１３に示すように、イベントパターンにおいて、計算した発生時刻の差分をタイムスタンプの次の行に保存する。

外部からデータベース１０１へ問い合わせがあった場合、この保存された時間差についての情報に基づいて、システムのユーザへ通知する。または、各イベントから始まる処理におけるプロセスごとに閾値をあらかじめ設定しておき、保存された時間差が当該閾値を超えるようなイベントパターンが発生した場合、システムのユーザへ通知する。これにより、処理遅延による性能の低下をユーザへ知らせることができる。

以上に述べたように本発明によれば、大規模分散処理システムのログ解析結果から内部挙動の把握を可能にし、それに基づいて、障害発生時にはその障害が属する処理過程およびイベントを特定、処理低下のボトルネック箇所を特定するという効果が得られる。

以下に、詳細な実施例を説明する。
（実施例）
図１４は、本発明のログ解析方法を実施するための大規模分散処理システムの一形態を示す図である。

本形態は図１４に示すように、ログ解析装置１００と、複数のサーバ２００−１〜２００−ｎ（ｎは２以上の整数）とが接続された構成となっている。

ログ解析装置１００は、イベントが発生してからそのイベントに応じた値を得るまでに実行される複数のプロセスをサーバ２００−１〜２００−ｎそれぞれが実行した結果を示す複数のログを解析する装置である。

サーバ２００−１〜２００−ｎは、分散された複数の処理をそれぞれ行う情報処理装置である。また、サーバ２００−１〜２００−ｎは、各処理を実行した結果をログとして残す（保存する）。このログの保存方法は、一般的な情報処理装置で行われているものと同じである。

図１５は、図１４に示したログ解析装置１００の内部構成の一例を示す図である。

図１４に示したログ解析装置１００には図１５に示すように、データベース１０１と、ログ取得部１０２と、ログ整理部１０３と、出力部１０４と、間隔算出部１０５と、比較部１０６とが設けられている。

データベース１０１は、上述したデータベース１０１と同じものであり、一連の複数のプロセスを実行する順に記述したイベントパターンをあらかじめ格納する。この格納方法は、図３〜７を用いて説明したとおりである。

ログ取得部１０２は、サーバ２００−１〜２００−ｎそれぞれからログを取得する。また、ログ取得部１０２は、取得したログをログ整理部１０３へ出力する。

ログ整理部１０３は、ログ取得部１０２から出力されてきたログを、当該ログに応じたプロセスと対応付けて、データベース１０１に格納されているイベントパターン内に書き込む。また、ログ整理部１０３は、ログ取得部１０２から出力されてきたログから当該ログが出力された時刻を示す時刻情報（タイムスタンプ）を抽出し、抽出した時刻情報をログとともにデータベース１０１に格納されているイベントパターン内に書き込む。なお、これらの動作の詳細は、図９を用いて説明したとおりである。

間隔算出部１０５は、データベース１０１に格納されているイベントパターン内に書き込まれている時刻情報に基づいて、それぞれのプロセスについてのログの出力間隔を算出する。なお、この動作の詳細は、図１１〜１３を用いて説明したとおりである。また、間隔算出部１０５は、算出した出力間隔を比較部１０６へ出力する。

比較部１０６は、間隔算出部１０５から出力されてきた出力間隔と、あらかじめ設定された閾値（時間）とを比較する。この閾値は、上述したように、プロセスごとに設定されているものであっても良い。また、比較部１０６は、比較の結果を出力部１０４へ出力する。

出力部１０４は、ログ解析装置１００の外部からの要求に応じて、イベントパターンをデータベース１０１から読み出して出力する。この「外部からの要求」は、ログ解析装置１００を操作するユーザが、ログ解析装置１００へ所定の操作（所定の情報の入力や、所定の入力キーの選択等）が行われた場合、要求があったと判定されるものであれば良い。また、その要求には、どのイベントのイベントパターンの出力を要求しているか等の、詳細な要求内容が含まれるものであっても良い。

また、出力部１０４は、比較部１０６から出力されてきた比較の結果を示す通知を出力する。このとき、出力部１０４は、比較部１０６から出力されてきた比較の結果が、出力間隔が閾値を超えているものである場合、サーバ２００−１〜２００−ｎのうちの該当するサーバの処理性能の低下を示す通知を出力する。

なお、出力部１０４からのイベントパターンや上述した通知の出力方法は、表示であっても良いし、他の通信装置への送信であっても良く、ユーザがそれらの情報を認識できるものであれば良い。これにより、ユーザは、イベントパターンや通知を見て、プロセスの実行状況や、障害箇所の特定、システム全体としてシステム内部の処理フローの挙動を把握することができる。

以下に、図１５に示したログ解析装置１００における処理について説明する。

図１６は、図１５に示したログ解析装置１００における処理を説明するためのフローチャートである。

まず、サーバ２００−１〜２００−ｎから各プロセスを実行した結果であるログが、ログ取得部１０２によって取得される（ステップＳ１１）。

すると、ログ取得部１０２によって取得されたログが、ログ整理部１０３によって、当該ログに応じたプロセスと対応付けられて、データベース１０１に格納されているイベントパターン内に書き込まれる（ステップＳ１２）。

その後、ログ解析装置１００の外部から、イベントパターンの出力の要求があったかどうかが出力部１０４によって判定される（ステップＳ１３）。

イベントパターンの出力の要求があったと判定された場合、要求に応じたイベントパターンが出力部１０４によってデータベース１０１から読み出され（ステップＳ１４）、読み出されたイベントパターンが出力部１０４から出力される（ステップＳ１５）。

１００ ログ解析装置
１０１ データベース
１０２ ログ取得部
１０３ ログ整理部
１０４ 出力部
１０５ 間隔算出部
１０６ 比較部
２００−１〜２００−ｎ サーバ

Claims (10)

1. イベントが発生してから該イベントに応じた値を得るまでに実行される複数のプロセスを複数のサーバそれぞれが実行した結果を示す複数のログを解析するログ解析装置であって、
   前記複数のプロセスを実行する順に記述したイベントパターンをあらかじめ格納するデータベースと、
   前記複数のサーバそれぞれから前記ログを取得するログ取得部と、
   前記ログ取得部が取得したログを、該ログに応じたプロセスと対応付けて、前記イベントパターン内に書き込むログ整理部と、
   当該ログ解析装置の外部からの要求に応じて、前記イベントパターンを前記データベースから読み出して出力する出力部とを有するログ解析装置。
2. 請求項１に記載のログ解析装置において、
   前記ログ整理部は、前記ログ取得部が取得したログから該ログが出力された時刻を示す時刻情報を抽出し、該抽出した時刻情報を前記ログとともに前記イベントパターン内に書き込むことを特徴とするログ解析装置。
3. 請求項２に記載のログ解析装置において、
   前記時刻情報に基づいて、各プロセスについてのログの出力間隔を算出する間隔算出部と、
   前記間隔算出部が算出した出力間隔と、あらかじめ設定された閾値とを比較する比較部とを有し、
   前記出力部は、前記比較部における比較の結果を示す通知を出力することを特徴とするログ解析装置。
4. 請求項３に記載のログ解析装置において、
   前記出力部は、前記比較部における比較の結果、前記出力間隔が前記閾値を超えている場合、前記サーバの処理性能の低下を示す通知を出力することを特徴とするログ解析装置。
5. 請求項１に記載のログ解析装置において、
   前記出力部は、前記イベントパターンを表示することを特徴とするログ解析装置。
6. 請求項３に記載のログ解析装置において、
   前記出力部は、前記通知を表示することを特徴とするログ解析装置。
7. イベントが発生してから該イベントに応じた値を得るまでに実行される複数のプロセスを複数のサーバそれぞれが実行した結果を示す複数のログを解析するログ解析方法であって、
   前記複数のサーバそれぞれから前記ログを取得する処理と、
   前記取得したログを、該ログに応じたプロセスと対応付けて、データベースにあらかじめ格納された前記複数のプロセスを実行する順に記述したイベントパターン内に書き込む処理と、
   前記イベントパターンを前記データベースから読み出す処理と、
   前記データベースから読み出したイベントパターンを出力する処理とを行うログ解析方法。
8. 請求項７に記載のログ解析方法において、
   前記取得したログから該ログが出力された時刻を示す時刻情報を抽出する処理と、
   前記抽出した時刻情報を前記ログとともに前記イベントパターン内に書き込む処理とを行うことを特徴とするログ解析方法。
9. 請求項８に記載のログ解析方法において、
   前記時刻情報に基づいて、各プロセスについてのログの出力間隔を算出する処理と、
   前記算出した出力間隔と、あらかじめ設定された閾値とを比較する処理と、
   前記比較の結果を示す通知を出力する通知処理とを行うことを特徴とするログ解析方法。
10. 請求項９に記載のログ解析方法において、
    前記通知処理は、前記比較の結果、前記出力間隔が前記閾値を超えている場合、前記サーバの処理性能の低下を示す通知を出力することを特徴とするログ解析方法。

Images