JP5444673B2 - ログ管理方法、ログ管理装置、ログ管理装置を備えた情報処理装置、及びプログラム - Google Patents

Description

本発明は、情報処理装置（コンピュータ）に存在する監視対象、つまり情報処理装置を構成する部品、及び実行中のプログラムを監視することで出力されるログを管理する技術に関する。

従来、サーバ等の情報処理装置では、そのシステムを構成するコンピュータのハードウェアやソフトウェア等の構成要素をそれぞれ監視対象としてログ（又はログメッセージ）を記録することが行われている。そのログは、情報処理装置の動作、状態、或いは操作状況などの事象の時間的推移を示す情報となる。通信ネットワークを介してサービスを提供するシステムを構成するサーバでは、登録したユーザのログオンやログオフ、警告、異常又は故障発生の状態等のシステムに関する様々な事象が記録される。このようなことからログは、障害発生時の原因追及や不正アクセスの痕跡探し、システムの稼働統計をとる等の目的で利用される。

図１６は、従来のログ管理装置の動作を説明する図である。そのログ管理装置１１０は、通信ネットワークを介してサービスを提供するサーバ１００に搭載されたものである。例えば、ログ管理装置１１０として動作させる機能を搭載したソフトウェアによって実現されている。

サーバ１００を構成するＣＰＵ（中央演算処理装置）、メモリ、システムコントローラ、ハードディスク装置（ＨＤＤ）、ホストバスアダプタ等のハードウェア群１０１、及びオペレーティングシステム（ＯＳ）１０２上で動作するソフトウェア（アプリケーション・プログラム等）は、ログをとる監視対象となる。ＯＳ１０２は、各ソフトウェアの動作を監視し、各種イベントが発生、或いは状態の変化が発生した場合に、その内容を示すログをログ管理装置１１０に出力する。また、ＯＳ１０２は、ハードウェア群１０１を構成する各ハードウェアの動作を監視し、何らかの異常が発生しそうな場合や何らかの異常が発生した場合に、その旨（警告や異常）をイベント検知部１０３に通知する。その通知に応答して、イベント通知部１０３は発生した異常、及びその異常が発生したハードウェアを示すログをログ管理装置１１０に出力する。ログ管理装置１１０は、そのようにしてＯＳ１０２、或いはイベント検知部１０３から出力されるログをログファイル１０４に格納する。

そのログファイル１０４は、例えばサーバ１００がハードウェア群１０１の一つとして搭載した不揮発性の記憶装置（例えばハードディスク装置）等に格納される。イベント検知部１０３は、例えばＯＳ１０２に搭載された１ソフトウェアにより実現される。

図１７は、従来のログ管理装置１１０によりログファイル１０４に格納されるログを説明する図である。
図１７は、ハードウェア群１０１を構成する部品ＨＡ及びＨＢにログを出力すべき異常、或いは故障が発生し、ＯＳ１０２上で動作するソフトウェア（図中「ソフト」と表記）ＳＡ、ＳＢ及びＳＣにログを出力すべき異常、或いはイベントが発生した場合を例にとって、出力されるログを示している。例えばソフトウェアＳＡで異常が発生したことでログ管理装置１１０に出力されたログは「ソフトＳＡ異常」と表記している。イベント検知部１０３は、ＯＳ１０２の一部との想定から示していない。図１７に示すようにログは、監視対象がログを出力すべき状態となれば随時、出力される。それにより、時系列で様々な
種別／監視対象のログが入り交じった状態でログファイル１０４に格納される。

図１８は、ログファイル１０４に格納されたログの内容を示す図である。図１８に示すように各ログは、それが出力された月日、時刻、監視対象、種別、及び要因の各データを備えた構成となっている。種別とは、ログを出力させる原因に相当し、具体的には異常、イベント、或いは故障等である。要因は、その種別となる原因が発生したと判断した理由に相当する。
特開２００５−１４１６６３号公報 特開２００６−３０２１７０号公報 特開２００４−２０６１６６号公報

ログは、障害に対応するための有用な情報である。しかし、そのログは、時系列で様々な種別／監視対象のログが入り交じった状態でログファイル１０４に格納される。このため、ログの解析に膨大な時間と労力を必要としていた。

従来のログ管理装置のなかには、ログの解析をより容易に行えるように、ログファイルに収集したログのなかから検索条件を満たすログを抽出して出力するものがある（特許文献１）。

検索条件を設定可能なログ管理装置では、適切な検索条件を設定することにより、解析に必要なログを抽出させることができる。しかし、解析に必要なログのみを抽出できるとは限らない。解析に不必要なログが存在する、解析に必要なログが抜けている、といったことが発生するのが普通である。また、適切な検索条件を設定するためには、ある程度の知識や経験が必要である。このようなことから、保守要員がログ解析をより容易に行えるように支援するためには、検索以外の手法も重視すべきと考えられる。

本発明は、解析をより容易に行えるようにログを出力することにより、障害への対応を支援するための技術を提供することを目的とする。

本発明を適用した１システムでは、情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することでその情報処理装置が出力するログを監視対象毎に分類し、監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を参照して、ログを分類した監視対象のなかで関連付け定義情報に示されている組み合わせを特定し、特定した組み合わせに基づいて、監視対象毎に整理したログを対応付けて表示装置上に出力し、監視対象毎に、一定時間内に出力されたログを解析して、該ログが出力された監視対象の状態を判断し、ログが出力された監視対象の順序、及び該監視対象が属するカテゴリを基に、組み合わせを関連付け定義情報として登録することにより、該関連付け定義情報を更新する。監視対象の状態の判断結果は共に出力し、監視対象毎に分類したログは、特定した組み合わせ毎に、そのログを示すシンボルを時系列に沿って配置した形で出力させる。

情報処理装置（コンピュータ）を構成するハードウェアである部品は、その情報処理装置上で実行されるプログラム（ソフトウェア）の制御で動作する。このことから、プログラムが動作させる部品が正常に動作しない、或いは部品を動作させるプログラムに不具合が存在するような場合、監視対象をソフトウェア、及びハードウェアのカテゴリに分ければ、一方のカテゴリに属する監視対象のログの出力により、他方のカテゴリに属し、その監視対象に関係する別の監視対象のログが出力されるという、ログ出力上の動作の関連性（依存関係）が成立する。

この関連性（依存関係）に着目し、管理対象別に分類したログを対応付けて出力（表示）させる。障害を発生させる原因となった監視対象、及びその監視対象との間に依存関係が存在する監視対象では、比較的に高い頻度でログが出力される。このため保守要員にとっては、障害を発生させる原因として考えられる監視対象の絞り込み（初期切り分け）はより容易に行えるようになる。従って、障害への対応自体もより容易に行えるようになる。ログが出力された監視対象の状態の判断結果の表示により、障害への事前対応もより容易に行えるようになる。

本発明を適用した場合には、障害への対応をより容易に行えるように支援することができる。

以下、実施形態の例について、図面を参照しながら詳細に説明する。
図１は、本実施形態によるログ管理装置の構成を示す図である。そのログ管理装置２０は、通信ネットワークを介してサービスを提供するサーバ１０に、そのサーバ１０に存在する監視対象の監視によって得られるログを管理するために搭載されたものである。例えば、ログ管理装置２０として動作させる機能を搭載したプログラム（以降「ログ管理ソフト」）によって実現される。

サーバ１０は、ＣＰＵ（中央演算処理装置）、メモリ、システムコントローラ、ハードディスク装置（ＨＤＤ）、ホストバスアダプタ等のハードウェア群１１によって構成され、オペレーティングシステム（ＯＳ）１２上で動作するソフトウェア（ミドルウェアやアプリケーション・プログラム等）が搭載されている。ハードウェア群１１を構成するＣＰＵ（中央演算処理装置）、メモリ、システムコントローラ、ハードディスク装置（ＨＤＤ）、ホストバスアダプタ等の各ハードウェア、及びミドルウェアやアプリケーション・プログラム等の各ソフトウェアは、ログをとる監視対象となる。ＯＳ１２は、実行中の各ソフトウェアの動作を監視し、各種イベントが発生、或いは状態の変化が発生した場合に、その内容を示すログをログ管理装置２０に出力する。また、ＯＳ１２は、ハードウェア群１１を構成する各ハードウェアの動作を監視し、何らかの異常、或いは故障が発生した場合に、その旨をイベント検知部１３に通知する。その通知に応答して、イベント通知部１３は発生した事象（警告、異常、或いは故障）及びその事象が発生したハードウェアを示すログをログ管理装置２０に出力する。ログ管理装置２０は、そのようにしてＯＳ１２、或いはイベント検知部１３から出力されるログを所定のログファイル１６に格納する。

ログ管理装置２０は、構成認識部２１、ログ分類部２２、及び二次元表示部２３を備えた機能構成であり、ログファイル１６以外のデータとしては、構成テーブル群２４、関連付け定義情報２５、及び分類ログテーブル群２６を管理する。それらのデータは、例えばハードディスク装置に保存され、必要に応じてメモリに読み出される。

サーバ１０は、ハードウェア構成情報１４、及びソフトウェア構成情報１５を管理している。ハードウェア構成情報１４は、サーバ１０を構成するハードウェア毎に、つまりハードウェア群１１を構成するＣＰＵ（中央演算処理装置）、メモリ、システムコントローラ、ハードディスク装置（ＨＤＤ）、ホストバスアダプタ等のハードウェア毎に、そのハードウェアについての情報をまとめたものである。ソフトウェア構成情報１５は、サーバ１０が実行するソフトウェア毎に、そのソフトウェアについての情報をまとめたものである。構成情報１４或いは１５に情報が格納されたハードウェア、及びソフトウェアは、ログを出力する監視対象となる。

構成認識部２１は、ハードウェア構成情報１４、及びソフトウェア構成情報１５を参照して、ハード構成テーブル２４ａ（図２）、及びソフト構成テーブル２４ｂ（図３）を構成テーブル群２４として生成する。各構成テーブル２４ａ及び２４ｂは、例えばハードウェア構成情報１４及びソフトウェア構成情報１５にそれぞれ格納されている情報を抽出して格納する形で生成したものである。

図２は、ハード構成テーブル２４ａのデータ構成を示す図である。図３は、ソフト構成テーブル２４ｂのデータ構成を示す図である。
図２に示すように、ハード構成テーブル２４ａには、ＣＰＵ（中央演算処理装置）、メモリ、システムコントローラ、ハードディスク装置（ＨＤＤ）、ホストバスアダプタ等のハードウェア毎に、当該ハードウェアの部品名、搭載位置、状態、及びキーワードの各データが格納されている。キーワードとしては、ハードウェアを示す表現として考えられるものが一つ以上まとめられている。

以降は、「ハードウェア」「ソフトウェア」はそれぞれカテゴリを指す意味で用いる。ハードウェアに属するものは「部品」と表記し、ソフトウェアに属するものは省略形の「ソフト」と表記することとする。

一方のソフト構成テーブル２４ｂには、図３に示すように、ソフトウェアの名称（図中「ソフト名」と表記）、カテゴリ、及び詳細情報の各データがソフトウェア毎に格納されている。カテゴリとは、対応するソフトウェアの種類、或いは搭載された形態に相当するものである。例えば「ｓｙｓｔｅｍ」はＯＳ１２に搭載されたソフトウェアであることを表し、「ａｐｐｌｉｃａｔｉｏｎ」はアプリケーション・プログラムであることを表している。詳細情報は、ソフトウェアの機能、或いは用途等についての情報である。

構成認識部２１は、ハード構成テーブル２４ａ及びソフト構成テーブル２４ｂから構成される構成テーブル群２４の他に、関連付け定義情報２５を作成する。その関連付け定義情報２５は、図４に示すように、異なるカテゴリに属する監視対象間の関連付けを定義したものである。図４に示す例では、部品名が「部品ＨＡ」の部品はソフト名が「ソフトＳＡ」のソフトウェアと関連付けられている。部品名が「部品ＨＢ」の部品はソフト名が「ソフトＳＢ」のソフトウェアと関連付けられている。ソフト名が「ソフトＳＣ」のソフトウェアには部品が関連付けられていない状態である。

例えばソフトウェアを実行する場合、当該ソフトウェアの実行に際して必要なハードウェアを動作させる。このため、ある部品に異常、或いは故障等の正常に動作しない事象が発生すると、その事象はその部品を動作させるソフトウェアに影響を及ぼす。或いは、ソフトウェアの不具合によってハードウェアが正常に動作しない場合もある。このことは、例えばある部品のログが出力されると、その部品を動作させるソフトウェアのログも出力されるという、互いに異なるカテゴリに属する監視対象間にログ出力上の動作の関連性（依存関係）が存在することを意味する。このことから本実施形態では、保守要員がログ解析を行った場合に、その関連性が存在する、或いはその関連性が存在すると推量される監視対象の組み合わせを関連付け定義情報２５中で定義し、ログ出力に利用するようにしている。

監視対象の組み合わせの定義、つまり関連付け定義情報２５の作成、及び更新は、構成認識部２１が行う。構成認識部２１は、ハード構成テーブル２４ａ及びソフト構成テーブル２４ｂを参照して、ハードウェアを構成する部品とソフトウェア間の関連付け定義情報２５を作成する。その作成は、ハード構成テーブル２４ａに部品毎に格納されたキーワード、及びソフト構成テーブル２４ｂのソフトウェア毎に格納された詳細情報を参照して行う。その参照により、キーワード、詳細情報からログ出力上の関連性を有すると考えられる監視対象の組み合わせを抽出して、その組み合わせ情報を格納した関連付け定義情報２５を作成する。

ハードウェア構成情報１４及びソフトウェア構成情報１５は共に、システム構成の変更
等により更新される可能性がある。このことから構成認識部２１は、状況に応じて、ハード構成テーブル２４ａ、ソフト構成テーブル２４ｂ、及び関連付け定義情報２５のうちの何れかの更新を行う。

図５は、関連付け定義情報２５の更新方法を説明する図である。
ログファイル１６には、時系列で部品又はソフトウェアに関するログが格納される。各ログは、それが出力された月日、時刻、監視対象、種別、及び要因の各データを備えた構成となっている。上述したように、ある部品に異常、或いは故障が発生すると、その事象はその部品を動作させるソフトに影響を及ぼす。このことから、ある部品に発生した事象は、その事象によるログが出力された後、その部品を動作させるソフトのログを出力させる。本実施形態では、このことに着目し、ハードウェアに属する監視対象のログに続けて、ソフトウェアに属する監視対象のログが一つ以上、連続する同一パターンが複数回、繰り返された場合、それらの監視対象間には関連性が存在すると見なし、それらの監視対象を関連付け定義情報２５に登録するようにしている。図５に示す例は、部品ＨＧのログの後にソフトＳＨのログが続くパターンが繰り返されたことから、部品ＨＧとソフトＳＨの組み合わせを関連付け定義情報２５に新たに登録する場合のものである。

ログ分類部２２は、ＯＳ１２、或いはイベント検知部１３から出力されたログをログファイル１６に格納する。またログは、構成テーブル群２４に登録された監視対象毎に用意したテーブル（分類ログテーブル）のなかで対応するテーブルに格納する。このことから分類ログテーブル群２６は、監視対象毎に用意した分類ログテーブルから構成される。監視対象毎に異なる分類ログテーブルにログを格納することにより、ログは監視対象別に整理・分類される。

二次元表示部２３は、関連付け定義情報２５を参照して、互いに異なるカテゴリに属する監視対象を関連させ、ログを二次元表示させる。図６は、ログの関連付け方法を説明する図であり、図７は、ログ表示例を示す図である。

図６に示すように、各分類ログテーブルから読み出されたログは関連付け定義情報２５に従ってまとめられ、図７に示すようにログ表示は、関連付けられたカテゴリの異なる監視対象の組み合わせ毎に、ログの内容を示すシンボルを時系列に沿って配置する形で行われる。ここではシンボルとして、例えば、警告（警告を行った動作により出力されたログ）を示す「Ｗ」、異常（異常の発生により出力されたログ）を示す「Ｅ」、及び構成テーブル群２４に登録されていない監視対象により出力されたログ（図中「未知メッセージ」と表記）を示す「Ｕ］のみを表記している。図７では、縦軸に監視対象、横軸に時間をとったグラフによる二次元表示としているが、縦軸と横軸を逆にした二次元表示としても良い。

図７に示すように、何らかの障害が発生した監視対象、及びその監視対象と関連性を有する別カテゴリの監視対象では、高い頻度でログが出力される。それらの監視対象のログはまとめた形で表示される。このため、障害に対応する保守要員にとっては、障害が発生している可能性が考えられる監視対象（被疑箇所）の絞り込み（初期切り分け）を容易に行えるようになる。被疑箇所を見落とすようなことは発生し難くなる。また監視対象毎に時系列にログを配置することから、障害が発生する監視対象、その障害が発生し易い時間帯等の把握も容易に行うことができる。このようなことから保守要員は、障害への適切な対応、及び解析をより容易、且つ迅速に行えることとなる。

本実施形態では、各分類ログテーブルを検索し、一定時間内に同一の要因によるワーニング（警告）又はエラー（異常、或いは故障等）を示すログが一定回数以上、記録された場合、その分類ログテーブルに対応する監視対象は故障していると見なし、その旨を警告
表示するようにしている。その警告表示により、被疑箇所の見落としはより防止することができ、事前対応もより容易に行えるようになる。その警告表示は、シンボルの表示色を変更することで行っている。

図８は、故障の判断方法を説明する図である。
図８に示す分類ログテーブルでは、「ｃｃｃｃ」を要因とする異常によるログが一定時間内に３回記録されている。本実施形態では、一定時間内に同一の要因によるログを検索し、そのログが３回以上記録されたことを条件に、分類ログテーブルに対応する監視対象が故障しているか否かの判断を行うようにしている。故障していると判断した場合、その旨はシンボルの表示色を変更することで示すようにしている。図７では、表示色を変えているシンボルは、「エラー集中→故障表示」と表記した破線で囲うことで示している。その破線で囲まれたシンボルは、部品ＨＡ及びソフトＳＡで交互に繰り返されている「Ｗ」と「Ｅ」である。

また、本実施形態では、分類ログテーブル毎に、統計情報を保持するようにしている。その統計情報は、同一の要因によるログが記録された回数のカウント結果（カウント値）を含むものである。新たにログが記録された場合、その統計情報、つまり対応するカウント値を更新するようにしている。カウント値は、例えば予め定めた時間帯で分けて、保持するようにしている。これは、サーバ１０の負荷の重さや提供するサービスは、時間帯によって異なることが多い傾向があるためである。

監視対象に何らかの不具合が存在する場合、同じ要因によるログが出力される頻度が高くなる。通常、不具合を放置した場合には、当該不具合が他のハードウェア又はソフトウェアに伝播することにより、データや状態等の整合性が取れなくなり、最終的にはシステム・パニックを引き起こす結果となる。このことから統計情報、つまり同じ要因によるログのカウント値は、今後、致命的なエラーが発生する可能性の判断に用いる。致命的なエラー（障害）が発生する可能性が高いと判断した場合、その可能性（エラー予兆）を警告表示するようにしている。その警告表示により、事前対応がより容易に行えるように支援する。

図９は、エラー予兆の判断方法を説明する図である。
図９において、分類ログテーブルの右側に上から「１１１１２２３・・・」と表記した数字は、同じ要因によるログのカウント値を示している。本実施形態では、エラー予兆の警告を行うべきか否かを判断するうえでの閾値を３とすることにより、カウント値が３以上となっているログの監視対象はエラー予兆の警告を行うべきと見なすようにしている。エラー予兆を警告すべきとする監視対象は、ログのシンボルの表示色を変更することで示すようにしている。図７では、エラー予兆の警告のために表示色を変えているシンボルは、「エラー予兆」と表記した破線で囲うことで示している。その破線で囲まれたシンボルは、部品ＨＢで３つの「Ｗ」の後に位置する「Ｅ」である。

上述したように本実施形態によるログ管理装置は、サーバ１０がログ管理ソフトを実行することで実現される。以降は、構成認識部２１、ログ分類部２２及び二次元表示部２３を実現させるために実行される処理について、図１０〜図１４に示すフローチャートを参照して詳細に説明する。

図１０は、関連付け定義情報作成処理のフローチャートである。この作成処理は、構成テーブル群２４（ハード構成テーブル２４ａ、及びソフト構成テーブル２４ｂ）、及び関連付け定義情報２５を作成するために実行される処理である。その実行は、例えばログ管理ソフトの起動後、構成テーブル群２４、及び関連付け定義情報２５が存在しないことが確認されたことが契機とされる。始めに図１０を参照して、この作成処理について詳細に
説明する。

先ず、ステップＳ１では、ハードウェア構成情報１４を参照する。続くステップＳ２では、その構成情報１４に登録されている部品の情報を抽出する。次のステップＳ３では、ハードディスク装置等の不揮発性の記憶装置にハード構成テーブル２４ａを作成し、抽出した情報を格納する。その次のステップＳ４では、情報を格納した部品毎に、状態として正常に動作していることを示す「ｎｏｒｍａｌ」を格納する。また、部品毎に、搭載位置の情報や他の項目の情報からキーワードを生成し格納する。そのようにして、図２に示すような内容のハード構成テーブル２４ａを作成する。

ステップＳ４に続くステップＳ５では、ソフトウェア構成情報１５を参照する。次のステップＳ６では、その構成情報１５に登録されているソフトの情報を抽出し、抽出した情報を格納した図３に示すようなソフト構成テーブル２４ｂを作成する。その後はステップＳ７に移行する。

ステップＳ７では、ハード構成テーブル２４ａに登録された部品のキーワードを抽出し、そのキーワードを用いて、ソフト構成テーブル２４ｂの詳細情報を対象とした検索を行う。続くステップＳ８では、キーワードを含む詳細情報が存在するか否かを判定する。検索の結果、キーワードを含む詳細情報を抽出できた場合、判定はＹｅｓとなってステップＳ９に移行する。そうでない場合には、判定はＮｏとなってステップＳ１０に移行する。

ステップＳ９では、検索に用いたキーワードを有する部品、及びそのキーワードを含む詳細情報を有するソフトを示す組み合わせを関連付け定義情報２５に反映させ、その組み合わせを示す情報を格納する。次のステップＳ１０では、検索に用いたキーワードを有する部品はハード構成テーブル２４ａの最後のものか否かを判定する。キーワード検索の対象となる部品が他に存在しない場合、判定はＹｅｓとなり、ここで関連付け定義情報作成処理を終了する。そうでない場合には、判定はＮｏとなって上記ステップＳ７に戻る。それにより、別の部品のキーワードを用いた検索を行う。

例えば部品ＨＡのキーワードの一つである「ＣＰＵ」はソフトＳＡの詳細情報中に存在している。部品ＨＢのキーワードである「ＭＥＭ」「ｍｅｍ」等は、ソフトＳＢの詳細情報中の「Ｍｅｍｏｒｙ」に対応すると見なされる（図２及び図３）。これらのことから、部品ＨＡとソフトＳＡ、部品ＨＢとソフトＳＢ、の２つの組み合わせは関連付け定義情報２５に登録されることとなる。

図１１は、構成テーブル更新処理のフローチャートである。この更新処理は、ハードウェア構成情報１４、或いはソフトウェア構成情報１５の更新に合わせて、ハード構成テーブル２４ａ、或いはソフト構成テーブル２４ｂを更新するための処理である。例えばログ管理ソフトの起動後、無条件で一度、実行される。次に図１１を参照して、この更新処理について詳細に説明する。

先ず、ステップＳ２１では、ハードウェア構成情報１４を参照する。次のステップＳ２２では、ハード構成テーブル２４ａを参照する。その後に移行するステップＳ２３では、ハードウェア構成情報１４及びハード構成テーブル２４ａ間での差分判定、つまりそれらのうちの一方にのみ登録されている部品の存在を判定する。そのような部品が存在していない場合、差分なしと判定し、ステップＳ２５に移行する。そうでない場合には、差分ありと判定して、ステップＳ２４に移行し、ハードウェア構成情報１４と登録された部品が同じとなるようにハード構成テーブル２４ａを更新する。その更新後に上記ステップＳ２５に移行する。

ステップＳ２５では、ソフトウェア構成情報１５を参照する。次のステップＳ２６では、ソフト構成テーブル２４ｂを参照する。その後に移行するステップＳ２７では、ソフトウェア構成情報１５及びソフト構成テーブル２４ｂ間での差分判定、つまりそれらのうちの一方にのみ登録されているソフトの存在を判定する。そのようなソフトが存在していない場合、差分なしと判定し、ここで構成テーブル更新処理を終了する。そうでない場合には、差分ありと判定して、ステップＳ２８に移行し、ソフトウェア構成情報１５と登録されたソフトが同じとなるようにソフト構成テーブル２４ｂを更新する。その更新後、この構成テーブル更新処理を終了する。

図１２は、関連付け定義情報更新処理のフローチャートである。この更新処理は、ログファイル１６に記録されたログを参照して、関連付け定義情報２５を更新するための処理である。例えばログ管理ソフトの起動後に、或いは一定時間間隔で実行される。次に図１２を参照して、この更新処理について詳細に説明する。関連付け定義情報２５の更新は、図５に示す方法で行われる。

先ず、ステップＳ４１では、記録されたログをキーにしてログファイル１６を検索する。続くステップＳ４２では、その検索により、複数行に渡り同一パターンのログ（メッセージ）が有るか否かを検出する、すなわち、同じ順序で複数の異なる監視対象のログが連続し、且つそれらが属するカテゴリが全て同じでない同一パターンが複数あるか否かのチェックを行う。次のステップＳ４３では、そのチェックにより、同一パターンが複数有ったか否かを判定する。同一パターンが複数有った場合、判定はＹｅｓとなってステップＳ４４に移行する。そうでない場合には、判定はＮｏとなり、ここで関連付け定義情報更新処理を終了する。

ステップＳ４４では、同一パターン、つまり複数行のログ（メッセージ）を単一のログに分解する。次のステップＳ４５では、ハードウェアに属する監視対象のログを抽出し、ハード構成テーブル２４ａを参照して、その監視対象である部品を特定する。続くステップＳ４６では、ソフトウェアに属する監視対象のログを抽出し、ソフト構成テーブル２４ｂを参照して、その監視対象であるソフトを特定する。その特定後はステップＳ４７に移行する。

ステップＳ４７では、ステップＳ４６及びＳ４７でそれぞれ特定した監視対象の組み合わせが既に関連付け定義情報２５に存在するか否かを判定する。その組み合わせが既に登録されていた場合、判定はＹｅｓとなり、ここで関連付け定義情報更新処理を終了する。そうでない場合には、判定はＮｏとなってステップＳ４９に移行し、その組み合わせを関連付け定義情報２５に反映させる。その後、関連付け定義情報更新処理を終了する。

上記図１０〜図１２に示す各処理を実行することにより、構成テーブル群２４及び関連付け定義情報２５の作成、及び更新が必要に応じて行われる。このことから、構成認識部２１が実現される。

図１３は、ログ分類処理のフローチャートである。この分類処理は、ＯＳ１２或いはイベント検知部１３から出力されたログをログファイル１６に記録し、対応する分類ログテーブルに格納するための処理である。例えばＯＳ１２或いはイベント検知部１３からのログの出力を契機に実行される。ログ分類部２２は、この分類処理を実行することで実現される。次に図１３を参照して、この分類処理について詳細に説明する。

先ず、ステップＳ６１では、ＯＳ１２或いはイベント検知部１３から通知されたログを入力する。次のステップＳ６２では、入力したログを内部バッファに格納する。その次のステップＳ６３では、内部バッファに格納したログ（図中「イベント情報」と表記）をロ
グファイル１６に記録する。その後はステップＳ６４に移行する。

ステップＳ６４では、ログに対応する構成テーブルを参照する。続くステップＳ６５では、ログが出力された監視対象（図中「イベント」と表記）が構成テーブルに含まれているか否かのチェックを行う。次のステップＳ６６では、その監視対象が構成テーブルに含まれているか否かを判定する。その監視対象が構成テーブルに登録されている場合、判定はＹｅｓとなってステップＳ６７に移行する。そうでない場合には、判定はＮｏとなってステップＳ７１に移行する。

ステップＳ６７では、ログを格納する分類ログテーブルを決定する。続くステップＳ６８では、決定したテーブルにログを格納する。その後は、ステップＳ６９で内部バッファを消去してから、ログ分類処理を終了する。

一方、ステップＳ７０では、内部バッファに格納したログは構成テーブル（構成テーブル群２４）には登録されていない未知の監視対象のものと特定する。次のステップＳ７１では、このログが出力された監視対象を対応する構成テーブルに登録する更新を行い、そのログを格納するための分類ログテーブルを作成する。その作成後は上記ステップＳ６８に移行し、作成した分類ログテーブルにログを格納する。

未知の監視対象から出力された最初のログは、図７に示すように「Ｕ」で表すようにしている。その最初のログであることは、例えば種別としてその旨を示すデータを書き込むことで常に特定することができる。

本実施形態では、構成テーブル群２４を参照し、登録されている監視対象毎に分類ログテーブルを作成するようになっている。しかし、各分類ログテーブルに格納したログは関連付け定義情報２５に従ってまとめる形で表示する。このことから作成する分類ログテーブルは、関連付け定義情報２５に組み合わせとして登録された監視対象用のみとしても良い。

図１４は、二次元表示処理のフローチャートである。この表示処理は、図７に示すようにログを二次元表示するための処理である。例えばログの出力を保守要員等に指示されたことを契機に実行される。二次元表示部２３は、この表示処理を実行することで実現される。最後に図１４を参照して、この表示処理について詳細に説明する。

先ず、ステップＳ８１では、分類ログテーブル群２６を参照し、続くステップＳ８２では、そのなかの一つを選択する。次のステップＳ８３では、前に選択した分類ログテーブルは最後か否かを判定する。今回、選択する対象となる分類ログテーブルが存在しない場合、判定はＹｅｓとなり、ここで二次元表示処理を終了する。そうでない場合には、判定はＮｏとなってステップＳ８４に移行する。

ログは、時系列で出力する。このことから、ステップＳ８４〜Ｓ８８では、分類ログテーブルの先頭から（早く記録されたほうから）ログを順次、読み込み、そのログを示すシンボルを配置していくための処理が行われる。

先ず、ステップＳ８４では、１行（に記録されたログ）を読み込む。続くステップＳ８５では、ログをその種別に対応するシンボルに変換する。次のステップＳ８６では、月日、及び時刻を抽出して時間を認識する。その次のステップＳ８７では、シンボルを認識した時間で決定される位置にプロットする。その後はステップＳ８８に移行して、そのようにしてシンボルの配置を決定したログは最後の行に記録されていたか否かを判定する。そのログが最後の行に記録されていた場合、判定はＹｅｓとなってステップＳ８９に移行する。そうでない場合には、判定はＮｏとなって上記ステップＳ８４に戻る。

ステップＳ８９では、一定時間内に一定回数以上の同じ要因の異常により出力されたログが有るか否かを判定する（図８）。そのようなログが有った場合、判定はＹｅｓとなり、ステップＳ９０で故障を警告表示するための表示変更、つまりシンボルの表示色の変更を行ってからステップＳ９１に移行する。そうでない場合には、判定はＮｏとなってそのステップＳ９１に移行する。

ステップＳ９１では、同じ要因の異常により出力されたログのなかでカウント値が閾値を越えているものがあるか否かを判定する（図９）。そのようなログが有った場合、判定はＹｅｓとなり、ステップＳ９２でエラー予兆を警告表示するための表示変更、つまりシンボルの表示色の変更を行ってから、上記ステップＳ８２に戻る。そうでない場合には、判定はＮｏとなり、そのステップＳ８２に戻る。

ステップＳ８２での分類ログテーブルの選択は、関連付け定義情報２５を参照して行われる。それにより、関連付け定義情報２５で登録された組み合わせの一方を選択した後は、次にその組み合わせで残った方を選択する。そのような選択を行うことにより、図７に示すように、関連付け定義情報２５に登録された組み合わせ毎に監視対象のログをまとめる形で表示するようにしている。

なお、本実施形態は、監視対象を搭載したコンピュータであるサーバ１０上で実現されているが、外部装置として、或いは外部装置上に実現させても良い。また、出力されたログは対応する分類ログテーブルに格納することで予め整理するようにしているが、ログの出力時に、ログファイル１６に記録されたログを対象に整理を行うようにしても良い。

図１５は、ハードウェア構成の実施形態の一例を示す図である。ここで図１５を参照して、本実施形態によるログ管理装置として適用可能なコンピュータ（情報処理装置）の構成について具体的に説明する。

図１５に示すコンピュータは、ＣＰＵ６１、メモリ６２、入力装置６３、出力装置６４、外部記憶装置６５、媒体駆動装置６６、及びネットワーク接続装置６７を有し、これらがバス６８によって互いに接続された構成となっている。同図に示す構成は一例であり、これに限定されるものではない。

ＣＰＵ６１は、当該コンピュータ全体の制御を行う。
メモリ６２は、プログラム実行、データ更新等の際に、外部記憶装置６５（あるいは可搬型の記録媒体Ｍ）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ６１は、プログラムをメモリ６２に読み出して実行することにより、全体の制御を行う。

入力装置６３は、例えば、キーボード、マウス等の操作装置と接続されたインターフェースである。操作装置に対するユーザの操作を検出し、その検出結果をＣＰＵ６１に通知する。

出力装置６４は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置６７は、例えばイントラネットやインターネット等の通信ネットワークを介して、外部装置と通信を行うためのものである。外部記憶装置６５は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。

媒体駆動装置６６は、光ディスクや光磁気ディスク等の可搬型の記録媒体Ｍにアクセス
するものである。
上述の構成では、ログ管理ソフトは外部記憶装置６５、若しくは記録媒体Ｍにアクセスするか、或いはネットワーク接続装置６７を介して取得される。そのようにして取得可能なログ管理装置をＣＰＵ６１に実行させることにより、本実施形態によるログ管理装置２０は実現される。

構成テーブル群２４、関連付け定義情報２５、及び分類ログテーブル群２６は、例えば外部記憶装置６５に保存され、必要に応じてメモリ６２に読み出される。ログファイル１６、ハードウェア構成情報１４、及びソフトウェア構成情報１５は、例えば外部記憶装置６５に保存される。ログ出力（表示）は、例えば出力装置６４、或いはネットワーク接続装置６７を介して行われる。そのログ出力は、媒体駆動装置６６を介して記録媒体Ｍにデータを記録することで行わせることもできる。このことからログ管理装置２０は、ログを出力するサーバ２０（情報処理装置）とは異なる情報処理装置に搭載しても良い。ログ管理装置２０にログを管理させる情報処理装置は複数台であっても良い。

以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置が出力するログを該情報処理装置、及び別の情報処理装置の一方により管理する方法において、
前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類ステップと、
前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を参照して、前記分類ステップでログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定ステップと、
前記特定ステップで特定した前記組み合わせに基づいて、前記分類ステップで前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力ステップと、
を含むことを特徴とするログ管理方法。
（付記２）
前記ログが出力された前記監視対象の順序、及び該監視対象が属するカテゴリを基に、前記組み合わせを前記関連付け定義情報として登録することにより、該関連付け定義情報を更新する更新ステップ、
を更に含むことを特徴とする付記１記載のログ管理方法。
（付記３）
前記更新ステップでは、前記ログが出力される前記監視対象の順序を監視することにより、互いに異なるカテゴリに属する複数の監視対象のログが連続する同一のパターンが複数回、繰り返された場合に、該同一のパターンを構成するログが出力された複数の監視対象の組み合わせを前記関連付け定義情報として登録する、
ことを特徴とする付記２記載のログ管理方法。
（付記４）
前記出力ステップでは、前記特定ステップで特定した前記組み合わせ毎に、前記分類ステップで前記監視対象毎に分類したログを示すシンボルを時系列に沿って配置した形で表示出力させる、
ことを特徴とする付記１記載のログ管理方法。
（付記５）
前記監視対象毎に、一定時間内に出力されたログを解析して、該ログが出力された監視対象の状態を判断する解析ステップを更に含み、
前記出力ステップでは、前記解析ステップでの判断結果を共に出力する、
ことを特徴とする付記４記載のログ管理方法。
（付記６）
前記分類ステップでは、前記監視対象毎に、該監視対象により出力されたログを格納するテーブルを作成することにより分類する、
ことを特徴とする付記２記載のログ管理方法。
（付記７）
情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置から出力されるログを管理する装置において、
前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類手段と、
前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を記憶した情報記憶手段と、
前記情報記憶手段に記憶された前記関連付け定義情報を参照して、前記分類ステップでログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定手段と、
前記特定手段が特定した前記組み合わせに基づいて、前記分類手段が前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力手段と、
を具備することを特徴とするログ管理装置。
（付記８）
付記７記載のログ管理装置を備えている、
ことを特徴とする情報処理装置。
（付記９）
情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置が出力するログを管理するログ管理装置として用いられるコンピュータに、
前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類機能と、
記憶手段に記憶された、前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を参照して、前記分類機能によりログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定機能と、
前記特定機能により特定した前記組み合わせに基づいて、前記分類機能により前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力機能と、
を実現させるためのプログラム。

本実施形態によるログ管理装置の構成を示す図である。 ハード構成テーブルのデータ構成を示す図である。 ソフト構成テーブルのデータ構成を示す図である。 関連付け定義情報のデータ構成を示す図である。 関連付け定義情報の更新方法を説明する図である。 ログの関連付け方法を説明する図である。 ログ表示例を示す図である。 故障の判断方法を説明する図である。 エラー予兆の判断方法を説明する図である。 関連付け定義情報作成処理のフローチャートである。 構成テーブル更新処理のフローチャートである。 関連付け定義情報更新処理のフローチャートである。 ログ分類処理のフローチャートである。 二次元表示処理のフローチャートである。 ハードウェア構成の実施形態の一例を示す図である。 従来のログ管理装置の動作を説明する図である。 従来のログ管理装置によりログファイルに格納されるログを説明する図である。 ログファイルに格納されたログの内容を示す図である。

符号の説明

１０ サーバ
１１ ハードウェア群
１２ ＯＳ
１３ イベント検知部
１４ ハードウェア構成情報
１５ ソフトウェア構成情報
１６ ログファイル
２０ ログ管理装置
２１ 構成認識部
２２ ログ分類部
２３ 二次元表示部
２４ 構成テーブル群
２５ 関連付け定義情報
２６ 分類ログテーブル群

Claims (4)

1. 情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置が出力するログを該情報処理装置、及び別の情報処理装置の一方により管理する方法において、
   前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類ステップと、
   前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を参照して、前記分類ステップでログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定ステップと、
   前記特定ステップで特定した前記組み合わせに基づいて、前記分類ステップで前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力ステップと、
   前記監視対象毎に、一定時間内に出力されたログを解析して、該ログが出力された監視対象の状態を判断する解析ステップと、
   前記ログが出力された前記監視対象の順序、及び該監視対象が属するカテゴリを基に、前記組み合わせを前記関連付け定義情報として登録することにより、該関連付け定義情報を更新する更新ステップと、を含み、
   前記出力ステップでは、前記解析ステップでの判断結果を共に出力し、前記特定ステップで特定した前記組み合わせ毎に、前記分類ステップで前記監視対象毎に分類したログを示すシンボルを時系列に沿って配置した形で出力させる、
   ことを特徴とするログ管理方法。
2. 情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置から出力されるログを管理する装置において、
   前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類手段と、
   前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を記憶した情報記憶手段と、
   前記情報記憶手段に記憶された前記関連付け定義情報を参照して、前記分類手段がログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定手段と、
   前記特定手段が特定した前記組み合わせに基づいて、前記分類手段が前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力手段と、
   前記監視対象毎に、一定時間内に出力されたログを解析して、該ログが出力された監視対象の状態を判断する解析手段と、
   前記ログが出力された前記監視対象の順序、及び該監視対象が属するカテゴリを基に、前記組み合わせを前記関連付け定義情報として登録することにより、該関連付け定義情報を更新する更新手段と、を具備し、
   前記出力手段は、前記解析手段による判断結果を共に出力でき、前記特定手段が特定した前記組み合わせ毎に、前記分類手段が前記監視対象毎に分類したログを示すシンボルを時系列に沿って配置した形で出力させる、
   ことを特徴とするログ管理装置。
3. 請求項２記載のログ管理装置を備えている、
   ことを特徴とする情報処理装置。
4. 情報処理装置を構成する部品、及び実行中のプログラムを監視対象として監視することで該情報処理装置が出力するログを管理するログ管理装置として用いられるコンピュータに、
   前記ログを前記情報処理装置に存在する前記監視対象毎に分類する分類機能と、
   記憶手段に記憶された、前記監視対象をハードウェア及びソフトウェアのカテゴリに分け、互いに異なるカテゴリに属する監視対象間で動作に関連性が存在すると見なす監視対象の組み合わせを示す関連付け定義情報を参照して、前記分類機能によりログを分類した監視対象のなかで該関連付け定義情報に示されている組み合わせを特定する特定機能と、
   前記特定機能により特定した前記組み合わせに基づいて、前記分類機能により前記監視対象毎に分類したログを対応付けて表示装置上に出力する出力機能と、
   前記監視対象毎に、一定時間内に出力されたログを解析して、該ログが出力された監視対象の状態を判断する解析機能と、
   前記ログが出力された前記監視対象の順序、及び該監視対象が属するカテゴリを基に、前記組み合わせを前記関連付け定義情報として登録することにより、該関連付け定義情報を更新する更新機能と、を実現させ、
   前記出力機能は、前記解析機能による判断結果を共に出力でき、前記特定機能により特定した前記組み合わせ毎に、前記分類機能により前記監視対象毎に分類したログを示すシンボルを時系列に沿って配置した形で出力させる、
   ことを特徴とするプログラム。