JP5353540B2 - 動作履歴収集装置、動作履歴収集方法およびプログラム - Google Patents

Description

ネットワークに含まれるノードの動作履歴を収集するための技術に関わる。

ネットワークに含まれるノードでは、そのノードの動作状態を記録したシステムログなどの動作履歴が保存されている。そこで、例えば、ネットワークで故障が発生したときなどには、故障の原因解析やネットワークの復旧のために、システムログの解析が行われる。しかし、ネットワークに含まれる各ノードで保存されているシステムログを全て解析すると復旧まで時間がかかる上、発生した故障への影響が小さいノードについてもシステムログを解析するため、非効率的であるという問題がある。また、この問題は、ネットワークの規模が大きくなるほど大きな問題となる。そこで、予め、ネットワーク中の各ノードについて、そのノードが故障したときにシステムログの解析対象となるノードを決定して、システムログの解析を行うノードに記録することがある。この場合、あるノードで故障が発生すると、故障が発生したノードに対応した解析対象として決められているノードのシステムログが収集される。

関連する技術として、コンピュータシステムの故障事象発生時に出力された故障メッセージＩＤと、予め登録されている故障メッセージＩＤとの照合一致によって、故障事象ごとの故障解析情報取得処理を特定するシステムが知られている。このシステムでは、取得された故障解析情報は、故障事象ごとに用意されているユーティリティプログラムによって解析用情報ファイルに出力される。

特開２００２−３６６３９６号公報

前述のように、ネットワークで故障が発生したときなどに、そのネットワークに含まれる各ノードで保存されているシステムログを全て解析すると非効率的である。そこで、故障の原因の解析などに用いるシステムログの量を限定するために、予め、故障の種類やノードに関連付けて、動作履歴の収集対象を決定することがある。しかし、ネットワークの規模が大きい場合やシステムの一部が遠隔地にある場合には、故障が発生したノードとシステムログの解析対象となるノードを対応付けるための事前の調査は困難である。

本発明では、故障の原因解析や復旧に用いるシステムログなど、ネットワークに含まれるノードの動作履歴を簡便に収集する方法を提供することを目的とする。

本発明の１つの態様の動作履歴収集装置では、ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定する解析手段、前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出されるかの判定を要求する判定要求を送信し、前記判定要求を受けたノードの動作履歴に前記異常が検出されたことを示す異常検出メッセージを受信すると、前記異常が検出されたノードを、前記動作履歴の取得対象のノードに指定するノード指定手段、前記ノード指定手段で指定されたノードの前記動作履歴を収集する動作履歴収集手段を備える。

故障の原因解析や復旧に用いるシステムログなど、ネットワークに含まれるノードの動作履歴を簡便に収集できる。

動作履歴収集装置を使用したネットワークの一例を示す図である。 動作履歴収集装置の構成の一例を説明する図である。 ネットワークに含まれるサーバの構成の一例を示す図である。 障害発生ノードの特定方法の一例を説明する図である。 構成管理データベースの一例を示す図である。 調査対象ノードリストの一例を示す図である。 障害発生ノードとの通信頻度が閾値以上のノードを求める方法の一例を説明する図である。 メッセージ解析部の動作の一例を説明するフローチャートである。 ノード指定部の動作の一例を説明するフローチャートである。 第２の実施形態で用いられる異常履歴検出部が異常を検出する方法の一例を説明する図である。 異常履歴検出部の動作の一例を説明するフローチャートである。 第２の実施形態で用いられる通信頻度解析部の動作の一例を説明するフローチャートである。 関連性マップテーブルの一例を表す図である。 第３の実施形態での動作履歴収集装置の動作の一例を説明するフローチャートである。 収集履歴比較部の動作の一例を説明するフローチャートである。 ノード指定部の動作の一例を説明するフローチャートである。

以下、本実施形態について、図面を参照しながら、詳細に説明する。
実施形態に係る動作履歴収集装置１は、障害が発生した旨のメッセージを受信すると、そのメッセージを解析して障害が発生したノード（障害発生ノード）を特定する。次に、動作履歴収集装置１は、障害発生ノードの近傍に位置するノード（近傍ノード）に対して、各々のノードのシステムログなどの動作履歴に異常が検出されるかの判定をするように要求する。また、障害発生ノードに対しての通信頻度が所定の閾値より大きいノードに対しても、動作履歴収集装置１は、動作履歴に異常が検出されるかの判定を要求する。判定が要求されたノードで、動作履歴からエラーメッセージなどの異常を通知する記録が検出された場合、そのノードは動作履歴収集装置１によって動作履歴を収集される対象として指定される。動作履歴収集装置１は、動作履歴の収集対象として指定されたノードの動作履歴を収集する。すなわち、動作履歴収集装置１は、近傍ノードや障害発生ノードとの通信頻度が一定以上のノードであり、かつ、動作履歴に異常が検出されたノードを、動作履歴の取得対象のノードとして指定し、指定したノードの動作履歴を収集する。

動作履歴収集装置１を用いたネットワークでは、障害が発生した場合、障害発生ノードに合わせて、障害発生ノードの近傍ノードや障害発生ノードとの通信頻度が一定以上のノードを抽出することができる。さらに、動作履歴収集装置１は、近傍ノードや障害発生ノードとの通信頻度が一定以上のノードの中から、動作履歴に異常が検出されたノードを動作履歴の検出対象とする。このため、動作履歴収集装置１を用いたネットワークでは、障害が発生するノードに対応させてシステムログなどの動作履歴の収集対象となるノードを事前に設定するなどの事前調査をしなくてもよく、簡便に動作履歴を収集することができる。

ここで、障害が発生した原因の解析やネットワークの復旧に有用なノードの動作履歴には、障害が発生したことによって通常と異なるメッセージなどが記録されている可能性が高いと考えられる。従って、動作履歴収集装置１は、異常が検出されたノードの動作履歴を収集することにより、障害の原因解析やネットワークの復旧に有用である可能性の高い動作履歴を収集することができる。さらに、異常が検出されたノードを動作履歴の収集対象とするので、障害が発生したときに収集するログの量を限定することもできる。

なお、以下の記載でも、障害発生ノードの近傍に接続されているノードのことを「近傍ノード」と記載する。また、ネットワーク中で障害発生ノードを基準とした接続関係を元に、システムログの収集対象とされうる位置にあるノードを、「障害発生ノードの近傍に位置するノード」と記載することがある。例えば、障害発生ノードのＩＰアドレスと第１〜第３オクテットが共通のノードについて、障害が発生したときにシステムログを収集するシステムでは、障害発生ノードと第１〜第３オクテットが共通のノードは、障害発生ノードの近傍ノードとなる。また、障害が発生したときにシステムログを収集する範囲をセグメントとして、予め決めておき、障害発生ノードと同一のセグメントについてシステムログを収集するシステムでは、障害発生ノードと同一のセグメントにあるノードが近傍ノードとなる。

図１は、動作履歴収集装置１を使用したネットワークの一例を示す図である。図１に示すネットワークには、動作履歴収集装置１、運用管理サーバ２、サーバ３（３ａ〜３ｅ）、ネットワーク装置４（４ａ、４ｂ）が含まれる。ここで、サーバ３の一部を、ユーザ端末などに置き換え、ユーザ端末などを含むネットワークとすることもできる。また、実装形態に合わせて、運用管理に用いられるプログラム等を動作履歴収集装置１や他のサーバ３に導入することもでき、その場合には、運用管理サーバ２を動作履歴収集装置１やサーバ３と同じノードにしたネットワークにすることもできる。以下の説明では、運用管理サーバ２が動作履歴収集装置１やサーバ３と別のノードとしてネットワークに含まれている場合について述べる。

動作履歴収集装置１は、ネットワークに含まれるサーバ３ａ〜３ｅのシステムログやアクセスログなどの任意の種類の動作履歴を収集することができるが、以下の説明では、システムログを収集する場合の例について具体的に述べる。また、動作履歴収集装置１は、外部ネットワーク５やネットワーク装置４ｃを介して、例えば遠隔地などに設置されているサーバ３（３ｆ〜３ｈ）の動作履歴を収集することもできる。

運用管理サーバ２は、ネットワーク中のサーバ３で発生した障害を検出し、動作履歴収集装置１に障害が発生したことを通知する。運用管理サーバ２が検出する障害は、例えば、ネットワーク上のハードウェアに起因する障害や、ネットワーク上のノードがアプリケーションを動作させたときに発生した障害などの任意の障害とすることができる。なお、運用管理サーバ２は、検出した障害を通知するメッセージや検出した障害に関する情報を、運用管理サーバ２のメモリ中のデータ領域に格納することもできる。

図１では、「20.100.1.X」のように、各ノードのＩＰアドレスの第３オクテットまでを示しており、第４オクテットは各ノードによって異なる値に設定される。図１に示すように、動作履歴収集装置１と運用管理サーバ２を「20.100.1.X」に配置している構成は一例であって、動作履歴収集装置１や運用管理サーバ２は、ネットワーク上の任意の位置に配置することができる。また、ネットワーク装置４も、ネットワークの接続にあわせた任意のネットワーク装置を用いることができる。サーバ３は、アプリケーションサーバ、ウェブサーバ、データベースサーバ、メールサーバ、運用管理サーバなどとすることができるが他の任意のサーバとすることもできる。図１では、サーバ３ａをデータサーバ、サーバ３ｂ、３ｃをウェブサーバ、サーバ３ｄ〜３ｈをアプリケーションサーバとしたときの例を示している。なお、図１では、サーバ３ａ〜３ｈの各サーバに対応するノード名を「ap00001」などとして記載している。

図２は、動作履歴収集装置１の構成の一例を説明する図である。動作履歴収集装置１は、ＣＰＵ１１、メモリ１２、出入力装置１３、外部記憶装置１４、読み取り装置１５、ネットワーク接続装置１７を備える。

ＣＰＵ１１は、メモリ１２を利用して、システムログを収集する処理を実行する。メモリ１２は、例えば半導体メモリとしてもよく、ＲＡＭ領域とＲＯＭ領域を含んでおり、動作履歴の収集を実行するためのプログラム２０や構成管理データベース３１などの記憶データ３０を格納する。プログラム２０は、メッセージ解析モジュール２１、ノード指定モジュール２２、および、動作履歴収集モジュール２３を含み、さらに収集履歴比較モジュール２４も含むこともある。出入力装置１３は、外部からのデータの入力や外部へのデータの出力に用いられる。外部記憶装置１４は、例えば、ハードディスクなどであり、図２ではメモリ１２に格納されているプログラム２０や記憶データ３０などを格納することもできる。読み取り装置１５は、ＣＰＵ１１の指示に従って、例えばＰＣカードなどの半導体デバイスとして実現される可搬記憶媒体１６にアクセスする。なお、可搬記憶媒体１６は、磁気的作用や光学的作用により情報が出入力される任意の媒体とすることができる。ネットワーク接続装置１７は、ＣＰＵ１１の指示により、ネットワークを介してデータを送受信する。例えば、ネットワーク接続装置１７は、動作履歴収集装置１からサーバ３への要求メッセージの送信やデータの受信などを行う。

ＣＰＵ１１は、メッセージ解析部、ノード指定部、動作履歴収集部、および、収集履歴比較部を含む。ここで、ＣＰＵ１１はプログラム２０を実行することにより、メッセージ解析機能、ノード指定機能、動作履歴収集機能、収集履歴比較機能を実現する。なお、後述するように、収集履歴比較部はオプションとすることができる。

メッセージ解析部は、運用管理サーバ２から動作履歴収集装置１に通知された障害通知メッセージを解析して、障害が発生しているノード（障害発生ノード）を特定する。発生ノードの特定方法については後述する。

ノード指定部は、障害発生ノードの近傍に接続されているノードに対して、異常が発生しているかの判定結果を要求し、さらに、障害発生ノードとの通信頻度が閾値以上のノードに対しても、異常が発生しているかの判定結果を要求する。また、異常が発生しているノードに対しては、発生した異常は障害発生ノードで発生した障害に起因して発生したかの判定結果も要求することができる。なお、ノード指定部は、近傍ノードなど、判定結果を要求する対象となるノードを選択する際に、適宜、構成管理データベース３１を用いる。また、ノード指定部は、障害発生ノードに通信頻度が閾値以上のノードを通知するように要求する。ノード指定部は、判定結果を要求したノードから受信した応答メッセージに応じて、システムログを収集する対象のノードを決定する。ノード指定部の動作については後で詳しく述べる。また、後述するように、関連性マップテーブル３３が用いられる場合、ノード指定部は、システムログの収集対象としたノードの組み合わせを発生した障害と対応付けて、関連性マップテーブル３３に記録する。

動作履歴収集部は、ノード指定部でシステムログの収集対象に決定されたノードにシステムログを記録したデータの送信を要求して、システムログを収集する。収集履歴比較部は、ノード指定部が作成した調査対象ノードリスト３２の内容と、関連性マップを比較する。

記憶データ３０には、構成管理データベース３１、調査対象ノードリスト３２、関連性マップテーブル３３を含めることができるが、関連性マップテーブル３３はオプションとすることもできる。構成管理データベース３１は、ネットワーク中のノードのＩＰアドレスとそのノードにつけられたノード名を一意に対応付ける情報を含む。調査対象ノードリスト３２は、動作履歴に障害が含まれるかの調査の対象となるノードと、そのノードをシステムログの収集対象とするかを記録する。関連性マップテーブル３３は、障害が発生したときにシステムログを収集したノードの履歴と発生した障害を対応付けて記録したテーブルである。これらのテーブルやその使用方法などは後で詳しく述べる。なお、これらのテーブルには、上記の情報のほかの情報も含めることができる。さらに、記憶データ３０には、ｈｏｓｔｓファイルのようなＩＰアドレスとノード名の対応を記録したファイルを含めることができる。

図３は、ネットワークに含まれるサーバの構成の一例を示す図である。ネットワークに含まれるサーバは、図１の例では、サーバ３と運用管理サーバ２である。運用管理サーバ２やサーバ３は、ＣＰＵ４１、メモリ４２、出入力装置４３、外部記憶装置４４、読み取り装置４５、ネットワーク接続装置４７を備える。メモリ４２は、プログラム５０や記憶データ５３を格納しており、プログラム５０は、異常履歴検出モジュール５１と通信頻度解析モジュール５２を含む。ＣＰＵ４１は、メモリ４２を利用して動作履歴収集装置１からの要求を処理する。出入力装置４３、外部記憶装置４４、読み取り装置４５、可搬記憶媒体４６、ネットワーク接続装置４７は、先に述べた出入力装置１３、外部記憶装置１４、読み取り装置１５、可搬記憶媒体１６、ネットワーク接続装置１７と同様である。なお、運用管理サーバ２やサーバ３は、ネットワーク接続装置４７を介して動作履歴収集装置１や他のサーバ３などと通信する。

ＣＰＵ４１は、異常履歴検出部と通信頻度解析部を含む。ここで、ＣＰＵ４１は、プログラム５０を実行することにより、異常履歴検出機能と通信頻度解析機能を実現する。異常履歴検出部は、動作履歴収集装置１からの判定要求に応じて、システムログに記録されている異常を示すメッセージを検出し、メッセージが検出されたかの判定結果を動作履歴収集装置１に送信する。また、異常履歴検出部は、発生した異常が障害発生ノードで発生した障害に起因して発生したかの判定を行う場合には、その判定も行うことができる。

通信頻度解析部は、動作履歴収集装置１からの要求に応じて、通信頻度解析部が動作しているノードとの通信頻度が閾値よりも高いノードを動作履歴収集装置１に通知する。後述する実施形態では、障害発生ノードの通信頻度解析部が、障害発生ノードとの通信頻度が閾値よりも高いノードを動作履歴収集装置１に通知する。記憶データ５３には、ＣＰＵ４１の動作などに用いられるデータや、ネットワーク中のノードのＩＰアドレスとノード名を対応付ける情報などを含めることができる。また、異常履歴検出部の動作に用いられる異常履歴確認フラグなどのフラグを、記憶データ５３に記憶させることもできる。

＜第１の実施形態＞
第１の実施形態として、動作履歴収集装置１がメッセージ解析部、ノード指定部、動作履歴収集部を備える場合について述べる。また、第１の実施形態では、記憶データ３０のうち構成管理データベース３１と調査対象ノードリスト３２は使用されるが、関連性マップテーブル３３は使用されないため、関連性マップテーブル３３を記憶していない動作履歴収集装置１で実施できる。この例では、システムの監視プログラムを運用管理サーバ２上で動作させており、障害に関する情報をそのソフトウェアで用いられるデータ領域に出力ログとして記録しているものとする。ここで、出力ログには、障害通知メッセージの他に、運用管理サーバ２で動作するシステム監視プログラムの実行により出力されたメッセージが含まれているものとする。

図４は、障害発生ノードの特定方法の一例を説明する図である。動作履歴収集装置１は、運用管理サーバ２から障害が発生したことを通知されると、メッセージ解析部を起動させる。メッセージ解析部は、運用管理サーバ２のデータ領域から出力ログを取得する。ここで、メッセージ解析部は、出力ログに含まれる１つのセンテンスなどの出力ログの一部分を取得することもできる。

メッセージ解析部は、障害通知メッセージに含まれる単語を予め記憶しているか、もしくは、適宜、記憶データ３０から読み込むことによって取得する。例えば、障害通知メッセージに「ＥＲＲＯＲ」、「ＷＡＲＮＩＮＧ」などの単語、「ＥＲＲ」などの略語があるという設定を、メッセージ解析部に用いることができる。この場合、「2009/1/10 12:00:00 ap00001 ERR APL001 インターフェイス異常が発生しました。」というメッセージを取得すると、メッセージ解析部は、「ＥＲＲ」を検出することにより、障害通知メッセージを取得したと判定する。

障害通知メッセージを取得すると、メッセージ解析部は図４に示すように、障害通知メッセージを時刻やノードを特定する情報やエラーの内容を示すメッセージなどの情報の種類別に分割する。なお、メッセージ解析部が障害通知メッセージを分割する分割方法は任意に変更することができ、例えば、障害通知メッセージの全体を単語単位に分割することもできる。メッセージ解析部は、分割されたメッセージからノード名を抽出し、得られたノード名を障害発生ノードのノード名として特定する。図４の例では、障害通知メッセージに「ap00001」が含まれていることから、「ap00001」のノード名が割り当てられているサーバ３ｅで障害が発生したことが特定される。

また、メッセージ解析部は、記憶データ３０に記憶されている情報を用いて、ノード名に対応するＩＰアドレスを求め、特定したノード名と共に、ノード指定部に通知する。例えば、記憶データ３０のｈｏｓｔｓファイルでは、「ap00001」のノード名が割り当てられているノードのＩＰアドレスが「20.100.2.1」であることが記録されているとする。すると、メッセージ解析部は、ノード指定部に「ap00001」と「20.100.2.1」を、障害発生ノードを特定する情報として通知する。

図５は、構成管理データベース３１の一例を示す図である。障害発生ノードの通知を受けると、ノード指定部は、構成管理データベース３１を用いて障害発生ノードの近傍に接続されているノードを検索する。図５に示す構成管理データベース３１には、ノード名、ＩＰアドレスとセグメントが記録されているが、ノード指定部は、セグメント情報を含まない構成管理データベース３１を用いて隣接ノードを検出することもできる。ここでは、ＩＰアドレスを用いて近傍ノードを検索するときのノード指定部の動作について述べる。また、この例では、障害発生ノードのＩＰアドレスと第１〜第３オクテットが共通するノードを近傍ノードとするものとする。

ノード指定部は、メッセージ解析部から障害発生ノードのＩＰアドレスを通知されると、構成管理データベース３１のＩＰアドレスの欄を参照し、障害発生ノードと第１〜第３オクテットが共通しているＩＰアドレスが割り当てられたノードを近傍ノードとして抽出する。ノード指定部は、抽出したノードのＩＰアドレスとノード名のうちの少なくとも一方を調査対象ノードリスト３２に記録して、記憶データ３０に記憶する。

例えば、「20.100.2.1」というＩＰアドレスが割り当てられているサーバ３ｅが障害発生ノードとして通知されると、ノード指定部は、図５に示す構成管理データベース３１のＩＰアドレスの欄を参照し、「20.100.2.」を含むノードを抽出する。図５の例では、ノード名がap00002、wb00001、wb00002のノードは、ＩＰアドレスの第１〜第３オクテットが「20.100.2.」障害発生ノードと同じであるので、調査対象ノードとして記録される。なお、ここで調査対象ノードに設定されたノードは、図１のサーバ３ｂ〜３ｄである。

図６に、調査対象ノードリスト３２の一例を示す。図６に示すリストでは、調査対象ノードとそれらのノードのシステムログを収集するかを表すフラグが含まれている。収集対象フラグは、システムログの収集対象を識別するためのフラグで、「１」に設定されているノードはシステムログの収集の対象となる。収集対象外フラグは、システムログの収集対象ではないノードを識別するために用いるフラグで、「１」に設定されているノードはシステムログの収集対象とされない。また、収集対象フラグと収集対象外フラグの両方が「０」の場合は、システムログの収集とするかの判定が行われていないことを表す。そこで、ノード指定部は、近傍ノードなどのノード名を調査対象ノードリスト３２に記録し、収集対象フラグと収集対象外フラグをいずれも「０」にセットする。

次に、ノード指定部は、調査対象ノードの異常履歴検出部に対して、システムログにエラーなどの異常が記録されているかの判定を要求する。例えば、「wb00002」については、収集対象フラグと収集対象外フラグの両方が「０」であるので、ノード指定部は、wb00002からシステムログの調査結果を受信していない。そこで、wb00002の異常履歴検出部にシステムログに異常が記録されているかの判定結果を要求する。ここで、「異常」は、例えば、運用管理サーバ２やサーバ３が正常に動作しているときには検出されない内容のログとすることができる。以下の説明では、障害発生ノード以外のサーバ３などで「ＥＲＲＯＲ」、「ＷＡＲＮＩＮＧ」などの語が記録されているログが観測されたときに、サーバ３などで異常が検出されたものとするが、「異常」と判断される事象は、実装に合わせて変更することができる。

ノード指定部は、さらに、異常履歴検出部から通知された情報に基づいて、適宜、調査対象ノードリスト３２を変更する。例えば、「ap00002」の異常履歴検出部から、ap00002のシステムログ中に異常を示す記録が検出された旨の通知を受けると、ノード指定部は、システムログの収集対象のノードとしてap00002を指定する。すると、ノード指定部は、ap00002について図６に示すように、収集対象フラグを「１」、収集対象外フラグを「０」に設定する。また、「wb00001」のシステムログからは異常を示す記録が検出されなかったことを示す通知を受けると、ノード指定部は、wb00001のシステムログを収集しないことを決定する。すると、ノード指定部は、収集対象外フラグを「１」、収集対象フラグを「０」に設定する。

また、ノード指定部は、障害発生ノードとの通信頻度が閾値以上のノードを、障害発生ノードであるap00001の通信頻度解析部に要求する。通信頻度解析部は、ap00001のアクセスログを参照して、アクセスログに記録されているノードごとに通信回数を集計する。また、通信頻度解析部は、予め閾値を保持していて、その閾値と通信回数を比較し、通信回数が閾値を上回ったノードを、ノード指定部に通知する。なお、予め、通信頻度解析部が検索するアクセスログの量を制限する条件を通信頻度解析部に記憶させることもできる。例えば、障害が発生した当日のシステムログから求めた通信回数が閾値を上回ったノードをノード指定部に通知するように設定できる。また、障害発生の日からさかのぼる日数を予め通信頻度解析部に記憶させることにより、障害発生の日より前のシステムログも通信頻度解析部の解析対象とすることができる。このように、複数の日のシステムログを用いた解析を行うと、障害が発生した日に通信回数が多いノードだけでなく、他の日や日常的に障害発生ノードとの通信回数が多いノードも、システムログを収集するかの判断の対象とすることができる。

図７は、障害発生ノードとの通信頻度が閾値以上のノードを求める方法の一例を説明する図である。図７の例では、ap00001のアクセスログには、ap00010と２１０回、db00001と１７０回、ap00002と１３０回通信が行われていることが記録されているものとする。ここで、通信頻度解析部が保持している閾値が１５０回であるとすると、ap00010とdb00001が、ap00001との通信頻度が高いノードとしてノード指定部に通知される。なお、閾値は、アクセス回数以外のものにすることもできる。例えば、「障害発生ノードとのアクセス回数順にノードをリストアップしたときの上位５台」など、アクセス回数が多い順に一定の数のノードを調査対象としてノード指定部に通知するように設定することもできる。

ノード指定部は、通信頻度解析部からの通知を受けると、通知されたap00010とdb00001の２つのノードを調査対象ノードリスト３２に加え、それぞれのノードがシステムログの収集対象であるかを調査する。この調査方法は、図６を参照しながら述べたのと同様の方法であり、ノード指定部は、ap00010とdb00001のそれぞれの異常履歴検出部に、システムログから異常を示すメッセージを検出できるかを問い合わせる。なお、ここで、ap00010とdb00001は、図１の３ｆと３ａに該当する。このように、通信頻度解析部の解析結果を用いることにより、障害が発生したサーバ３ｅの近傍に位置するサーバ３ｂ〜３ｄに加えて、サーバ３ｅとのアクセス回数が多いサーバ３ａと３ｆについてもシステムログを収集する対象かを調査できる。

ノード指定部は、調査対象ノードリスト３２に含まれている全てのノードについて、システムログの収集対象とするかを調査すると、収集対象に決定したノードのシステムログの収集を動作履歴収集部に要求する。調査対象ノードリスト３２に記録されている各ノードの調査が終了したときに、例えばap00002、ap00010、db00001が収集対象に決定されると、動作履歴収集部はそれらのノードのシステムログを収集する。なお、ノード指定部は、調査対象ノードリスト３２に記録されているノードから、システムログの収集対象とするノードを特定する度に、動作履歴収集部にシステムログの収集を要求することもできる。

以上に述べたように、本実施形態によると、動作履歴収集装置１が障害発生ノードを特定し、障害発生ノードの近傍に位置するノードと障害発生ノードとの通信頻度が閾値よりも高いノードに対して、システムログの収集対象となるかを自律的に問い合わせる。このため、ネットワーク中の各ノードについてそのノードが障害を発生したときにシステムログの収集対象とするノードを予め決定しなくても、動作履歴収集装置１が自律的に、システムログの収集対象を決定し、システムログを収集する。

さらに、動作履歴収集装置１を用いたシステムログの収集では、システムログに異常を通知するメッセージが含まれていないノードは、システムログの収集対象にはならない。従って、障害発生ノードの近傍ノードなどであっても、システムログに異常を通知するメッセージが検出されない場合には、システムログの収集対象とされない。障害の原因解析やネットワークの復旧を行うためのシステムログの解析には、障害に関連して発生した異常が検出されているシステムログを解析することが有用である。すなわち、障害と関連性のある異常が検出されていないシステムログを解析しても、障害の原因解析や障害からの復旧への有用性が低いといえる。本実施形態の動作履歴収集装置１では、システムログに異常を示すメッセージ等が含まれていないノードのシステムログを解析対象としないことにより、システムログの解析を効率的に行うことができるようにする。つまり、動作履歴収集装置１は、障害の原因解析や障害からの復旧への有用性が比較的高いと予測されるシステムログを選択的に収集することができる。

このように、システムログの収集を行うためにネットワークの調査を行わなくてもよいため、本実施形態は、大規模なネットワークや一部分が遠隔地に位置するネットワークなどであっても、動作履歴を簡便に収集することができる。さらに、システムログなどの動作履歴から異常を通知するメッセージが検出されたノードの動作履歴を収集するため、収集される動作履歴の量を制限することができる。従って、障害の発生原因の特定などのために解析する対象として有用な可能性が高い動作履歴を選択しながら、収集する動作履歴の量を制限することができ、動作履歴の解析の効率を良くすることができる。

図８は、メッセージ解析部の動作の一例を説明するフローチャートである。メッセージ解析部は、運用管理サーバ２のデータ領域に記録されている出力ログを１行取得し、「ＥＲＲＯＲ」、「ＷＡＲＮＩＮＧ」などの障害通知メッセージに含まれている語が含まれているかを確認する（ステップＳ１、２）。読み込んだ出力ログに「ＥＲＲＯＲ」などの語が含まれていると、メッセージ解析部は、読み込んだ出力ログは障害通知メッセージであると判定し、障害通知メッセージを単語単位に分割する（ステップＳ３）。次に分割したメッセージからノード名を特定し、記憶データ３０に格納されているネットワーク上のノード名と比較することにより、障害発生ノードのノード名とＩＰアドレスを特定する（ステップＳ４）。障害発生ノードが特定できた場合は、メッセージ解析部は、ノード指定部を起動させて、ノード指定部に障害発生ノードのＩＰアドレス等を通知する（ステップＳ５）。メッセージ解析部は、さらに、解析していない出力ログが運用管理サーバ２に記録されているかを確認し、出力ログの解析が終了するまで、ステップＳ１〜Ｓ６の動作を繰り返す（ステップＳ６）。一方、ステップＳ１で読み込んだ出力ログから「ＥＲＲＯＲ」などの語が検出されない場合には、メッセージ解析部は読み込んだ出力ログのデータを破棄し、出力ログの解析が終了しているかを確認する（ステップＳ２、６）。

図９は、ノード指定部の動作の一例を説明するフローチャートである。なお、図９は、システムログの収集対象のノードが特定されるたびにノード指定部が動作履歴収集部にシステムログの収集を要求する動作履歴収集装置１についてのフローチャートである。ノード指定部は、調査対象ノードリスト３２を初期化する（ステップＳ１１）。障害発生ノードのＩＰアドレス等をメッセージ解析部から通知されると、ノード指定部は、構成管理データベース３１を用いて障害発生ノードの近傍ノードを抽出し、得られた結果を調査対象ノードリスト３２に記録する（ステップＳ１２、Ｓ１３）。次に、ノード指定部は、調査対象ノードリスト３２に記録されているノードの異常履歴検出部に対して、そのノードのシステムログに異常が記録されているかの判定を要求し、調査対象ノードから判定結果を受信する（ステップＳ１４、Ｓ１５）。ノード指定部は、調査対象ノードから、システムログに異常が記録されている旨の通知を受けると、収集対象フラグを使って、その調査対象ノードをシステムログの収集対象に指定する（ステップＳ１６）。さらに、ノード指定部は、動作履歴収集部に、収集対象として指定したノードのシステムログの収集を要求する（ステップＳ１７）。一方、調査対象ノードのシステムログから異常が検出されない場合には、ノード指定部は、収集対象外フラグを用いて、その調査対象ノードのシステムログを収集しないように指定する（ステップＳ１５、Ｓ１８）。次に、ノード指定部は、障害発生ノードの通信頻度解析部に、障害発生ノードとの通信頻度が一定以上のノードを通知するように要求し、通知されたノードを調査対象ノードリスト３２に加える（ステップＳ１９、Ｓ２０）。ステップＳ１４〜Ｓ２０の動作を、ノード指定部は、調査対象ノードリスト３２に記録されている全てのノードに対して処理が行われるまで繰り返す。（ステップＳ２１）。

＜第２の実施形態＞
第１の実施形態において、調査対象ノードのうち、システムログに異常が記録されているものをシステムログの収集対象としたが、障害に関連性の高い異常が記録されているノードをシステムログの収集対象とすることもできる。この場合には、収集されるシステムログの量を第１の実施形態よりもさらに制限することができる。第２の実施形態においても、ノード指定部、動作履歴収集部の動作は第１の実施形態で述べたのとほぼ同様である。

第２の実施形態に係る動作履歴収集装置１で動作するメッセージ解析部は、障害発生ノードを特定するときに、障害が発生した時刻を表す情報も障害通知メッセージから取得することができる。メッセージ解析部に時刻情報の表記形式を予め設定するか、記憶データ３０から読み出させることにより、メッセージ解析部は、分割した障害通知メッセージから障害の発生時刻を抽出できる。メッセージ解析部は、障害の発生時刻をノード指定部に通知する。さらに、第２の実施形態では、ノード指定部は、解析などを要求するときに、異常履歴検出部や通信頻度解析部に障害の発生時刻を通知する。

図１０は、第２の実施形態で用いられる異常履歴検出部が異常を検出する方法の一例を説明する図である。図１０の例では、サーバ３ｅ（ap00001）で２００９年１月１０日の12:00:00に障害が発生した場合について述べる。図１０（ａ）は、障害が発生した時刻の周辺に障害発生ノードで記録されたシステムログを示す。図１０（ｂ）と図１０（ｄ）は、障害が発生した時刻の周辺に、サーバ３ｄ（ap00002）とサーバ３ｃ（wb00001）の各々で記録されたシステムログである。また、図１０（ｃ）と図１０（ｅ）は、障害が発生した日の前日のシステムログのうち、障害が発生した時刻と同じ時刻の周辺にサーバ３ｄとサーバ３ｃで記録された部分の例である。ここで、障害が発生した時刻の周辺のシステムログは、例えば、障害が発生した時刻の前後２０分など、障害が発生した時刻を基準とした所定の時間の範囲に記録されたシステムログとすることができる。さらに、「障害が発生した時刻の１５分前から障害が発生した時刻の５分後まで」など、障害が発生する前と後でシステムログの検索範囲を変更することもできる。

（１）図１０（ａ）に示すように、ap00001で障害が発生すると、前述のように、ノード指定部は、ap00001の近傍ノードの１つであるap00002（サーバ３ｄ）の異常履歴検出部に対して、システムログに異常が検出されているかを問い合わせる。

（２）ap00002の異常履歴検出部は、問い合わせを受けるとap00001で障害が発生した時刻（２００９年１月１０日の12:00:00）の周辺のシステムログを確認して、異常を示す記録があるかを判定する。図１０（ｂ）の例では、12:00:00に通信に失敗したことを示す警告が記録されている。

（３）ap00002の異常履歴検出部は、障害が発生した日の前日である２００９年１月９日のシステムログについて、障害が発生した時刻と同じ時刻の周辺の記録を確認する。すると、図１０（ｃ）には、２００９年１月９日の12:02:00にバッチ処理の失敗を報告するエラーが記録されている。

（４）ap00002の異常履歴検出部は、（２）と（３）で得られた結果を比較することにより、障害が発生した日のシステムログに記録されている異常であって、障害が発生する前日の同時刻やその周辺のシステムログに記録されていない異常があるかを調べる。図１０（ｂ）の12:00:00に通信に失敗したことを示す警告が記録されているのに対して、図１０（ｃ）のシステムログには同じ警告が記録されていない。そこで、異常履歴検出部は、ap00002で12:00:00に発生した通信の失敗は同時刻に定期的に発生する警告ではなく、ap00001で発生した障害に関連して発生した異常である可能性があると判断する。

（５）ap00001で発生した障害に関連して発生した異常を含むシステムログは、障害の原因解析や障害からの復旧に有用である可能性が高いため、異常履歴検出部は、ap00002をシステムログの収集の対象としてノード指定部に報告する。ノード指定部は、ap00002をシステムログの収集対象として調査対象ノードリスト３２に記録し、動作履歴収集部にシステムログの収集を要求する。

（６）次に、ノード指定部は、ap00001の近傍ノードであるwb00001（サーバ３ｃ）の異常履歴検出部に対して、システムログに異常が検出されているかを問い合わせる。
（７）wb00001の異常履歴検出部は、問い合わせを受けると２００９年１月１０日の12:00:00の周辺のシステムログを確認して、異常を示す記録があるかを判定する。図１０（ｄ）の例では、12:02:00にバッチ処理に失敗したことを示すエラーが記録されている。

（８）wb00001の異常履歴検出部は、障害が発生した日の前日の２００９年１月９日のシステムログについて、障害が発生した時刻と同じ時刻の周辺の記録を確認する。すると、図１０（ｅ）には、２００９年１月９日の12:02:00にバッチ処理の失敗を報告するエラーが記録されている。

（９）wb00001の異常履歴検出部は、（７）と（８）で得られた結果を比較することにより、障害が発生した日のシステムログに記録されている異常であり、かつ、障害が発生する前日のシステムログに記録されていない異常があるかを調べる。図１０（ｄ）と図１０（ｅ）のシステムログには、12:02:00に同じバッチ処理の失敗を報告するエラーが記録されている。そこで、異常履歴検出部は、wb00001で12:02:00に発生した通信の失敗は同時刻に定期的に発生するエラーであると判断する。すなわち、wb00001で発生したエラーはap00001で発生した障害に関連しておらず、障害の原因解析や障害からの復旧に対する有用性が低い可能性がある。なお、ここでは、図１０（ｄ）と図１０（ｅ）のいずれにも、他にエラーや警告が記録されていなかったものとする。

（１０）異常履歴検出部は、wb00001はシステムログの収集の対象ではないことをノード指定部に報告する。ノード指定部は、wb00001をシステムログの収集対象外として調査対象ノードリスト３２に記録する。

手順（１）〜（１０）で述べたように、第２の実施形態では、障害が発生した日のシステムログだけでなく、障害が発生した日の前日のシステムログについても、障害が発生した時刻と同じ時刻に異常が発生するかを、異常履歴検出部が調べる。その結果、同時刻に定期的に発生するエラー等は、障害とは関係なく発生していると判断する。一方、障害が発生した日のシステムログに記録されている警告などであって、かつ、障害が発生した日の前日のシステムログに記録されていない警告などは、障害の発生に関係している可能性があると判断する。そして、動作履歴収集装置１は、障害の発生に関係している可能性のあるシステムログを収集することにより、第１の実施形態に比べて収集するシステムログの量を制限することができる。さらに、収集されたシステムログは、障害の発生に関連して観測されたエラーなどを含んでいる可能性が高いものであるため、第１の実施形態の動作履歴収集装置１を用いたときに比べて、障害の原因解析などのためにシステムログを解析する際の利便性も大きい。

手順（２）などで、障害が発生した時刻の周辺のシステムログを検索するとき、異常履歴検出部は、障害が発生した時刻のログの前後１００行など、予め、検索する範囲を指定する情報を保持しているものとする。また、検索する範囲の指定方法は任意であり、例えば、異常履歴検出部に一定の時間範囲を記憶させておき、障害が発生した時刻を基準として、その一定の時間範囲に入る時刻に記録されたログを検索する対象とすることもできる。例えば、障害が発生した時刻の１０分前から障害が発生した時刻の１０分後までに観測された異常を記録したログを検索の対象とすることができる。

異常履歴検出部は、障害の発生に関連した異常がシステムログに記録されているかを確認するときに、「異常履歴確認フラグ」などのフラグを用いて手順（２）や手順（３）での検出結果を保持することもできる。異常履歴確認フラグが「１」の場合には、障害が発生した日のシステムログに、定期的に発生している異常以外の異常が含まれる可能性があることを示す。一方、異常履歴確認フラグが「０」の場合には、障害が発生した日のシステムログに含まれている異常は、過去において発生している異常であることを示す。例えば、図１０を参照しながら述べた例では、手順（２）でap00002に異常が発生していることが確認されているので、異常履歴検出部は、異常履歴確認フラグを「１」に設定する。手順（４）においてap00002で発生した警告は定期的に発生する警告ではないことが確認されると、異常履歴検出部は、異常履歴確認フラグを「１」にしたままにし、ap00002がシステムログの収集対象であることをノード指定部に報告する。一方、wb00001の異常履歴検出部は、手順（７）では、異常履歴確認フラグを「１」に設定するが、手順（９）において手順（７）で検出されたエラーが定期的に観測されるものであることを確認すると、異常履歴確認フラグを「０」に変更する。

図１１は、異常履歴検出部の動作の一例を説明するフローチャートである。図１１を参照しながら、障害が発生した日とその前日のシステムログに加えて、障害が発生した日の前の週のシステムログも用いて、異常履歴検出部が動作する場合の例について述べる。なお、障害が発生した日のシステムログと比較する対象として、障害が発生した日の前日や前週のシステムログを用いているのは一例である。障害に関連して異常が発生しているかを確認するために用いるシステムログは、実装に応じて任意の日のシステムログとすることができる。

異常履歴検出部は、異常履歴確認フラグを初期化する（ステップＳ３１）。次に、障害が発生した時刻の周辺のシステムログから「ＥＲＲＯＲ」や「ＷＡＲＮＩＮＧ」などの語を含むメッセージが抽出されると、異常履歴確認フラグを「１」に設定する（ステップＳ３２〜Ｓ３４）。次に、異常履歴検出部は、障害が発生した日の前の日のシステムログを参照し、障害が発生した時刻と同時刻の周辺に、抽出されたメッセージと同じメッセージが検出されるかを調べる（ステップＳ３５）。すなわち、障害が発生した時刻の周辺のシステムログに記録されている異常と同じ異常が、障害が発生する前日から同時刻周辺に繰り返して発生している異常であるかを確認する。ステップＳ３５の条件に該当するメッセージがシステムログに含まれていない場合、異常履歴検出部は、異常履歴確認フラグを「１」のまま保持する（ステップＳ３６、Ｓ３７）。さらに、異常履歴検出部は、障害が発生した日の一週間前のシステムログを参照し、抽出されたメッセージと同じメッセージが検出されるかを調べる（ステップＳ３８）。すなわち、障害が発生した時刻の周辺のシステムログに記録されている異常と同じ異常が、一週間ごとに同時刻周辺に繰り返して発生する異常であるかを確認する。ステップＳ３８の条件に該当するメッセージがシステムログに含まれていない場合、異常履歴検出部は、異常履歴確認フラグを「１」のままで保持し、そのノードをシステムログの収集対象とする（ステップＳ３９、Ｓ４０）。一方、ステップＳ３６、Ｓ３９のいずれかで、抽出されたメッセージと同じメッセージがシステムログから確認された場合、異常履歴検出部は、異常履歴確認フラグを「１」から「０」に変更する（ステップＳ４２、４３）。また、ステップＳ３３で「ＥＲＲＯＲ」などの語を含むメッセージが抽出されない場合も、異常履歴検出部は、異常履歴確認フラグを「０」に設定する（ステップＳ３３、Ｓ４１)。異常履歴確認フラグの値が「０」であれば、異常履歴検出部は、そのノードをシステムログの収集対象としないことを、ノード指定部に報告する。

図１１を参照して、近傍ノードの異常履歴検出部が動作する方法について述べたが、障害発生ノードとの通信頻度が閾値以上のノードにおいても、異常履歴検出部は同様に動作する。第２の実施形態の通信頻度解析部は、障害が発生した時刻に障害発生ノードとの通信頻度が閾値以上のノードを、調査対象ノードとしてノード指定部に通知する。

図１２は、第２の実施形態で用いられる通信頻度解析部の動作の一例を説明するフローチャートである。図１２の例では、通信頻度解析部は、ｍ、ｎ、ｒの３つの変数を用いて、障害発生ノードとの通信頻度が一定以上のノードを求める。ｍとｒは、予め、通信頻度解析部に設定されているか、もしくは、通信頻度解析部が記憶データ５３から読み出すことができるようにメモリ４２に記憶されている。ここで、この例では、通信頻度として、アクセス数を用いるものとする。ｍは、通信頻度を調査する日数を示し、通信頻度解析部は、障害が発生した日を基準としてｍ日までさかのぼった日のシステムログから障害が発生した日のシステムログを用いて通信頻度を計算する。ｎは、ｍ日分のシステムログが処理されているかを判定するために用いる変数である。ｒは、調査対象ノードとするかを判断するための閾値であり、通信頻度解析部は、アクセス数が上位のｒ台のノードを調査対象ノードとして特定する。

通信頻度解析部は、最初にｎの値を「０」に初期化する（ステップＳ５１）。次に、まず、通信頻度解析部の処理対象とする日のシステムログのうち、障害が発生した時刻と同時刻の周辺の内容から、ノードごとのアクセス数を求め、ｎを１だけインクリメントする（ステップＳ５２、Ｓ５３）。ｎとｍの値を比較し、ｎがｍ以上ではない場合、通信頻度解析部の処理対象とする日のシステムログのうち、まだ処理対象となっていない日のシステムログについて、ステップＳ５２、Ｓ５３の処理を繰り返す（ステップＳ５２〜５４）。ｎとｍの値が等しくなると、対象とするシステムログの処理が終了するので、ステップＳ５２〜５４の処理で得られた結果から、上位ｒ台のノードを調査対象ノードとして特定する（ステップＳ５５）。

図１２に示す動作をする通信頻度解析部は、前述のとおり、システムログのうちの障害が発生した時刻の周辺の記録を検索するため、障害が発生した時刻の周辺でのアクセス数が閾値を超えたノードを検出する。障害が発生した時刻に障害発生ノードとのアクセスが多いノードでは、障害に関連して異常が発生する可能性が高い。したがって、図１２の動作を行う通信頻度解析部がシステムログの収集対象として検出したノードは、障害が発生した日のシステムログ全体を用いて求めた場合に比べて、異常が発生しているノードである可能性が高くなる。なお、図１２に示した動作を行う通信頻度解析部は、第１の実施形態に係る動作履歴収集装置１で用いることもできる。この場合、メッセージ解析部が障害の発生時刻を検出し、ノード指定部から障害発生ノードの通信頻度解析部に障害の発生時刻が通知される。

＜第３の実施形態＞
第３の実施形態では、過去に行われた収集結果を用いたシステムログの収集について述べる。第３の実施形態では、過去に収集されたシステムログと重複するシステムログの収集を避けることにより、システムログの収集量を簡便に制限することができる。

第３の実施形態に係る動作履歴収集装置１では、メッセージ解析部、ノード指定部、動作履歴収集部に加えて、収集履歴比較部が動作する。また、記憶データ３０に記憶されている関連性マップテーブル３３が使用される。

図１３は、関連性マップテーブルの一例を表す図である。関連性マップテーブルには、関連性マップと発生キーワードが記録されている。また、関連性マップテーブルには、その他の情報を含めることもでき、図１３の例では、関連例マップと発生キーワードの他に、その関連性マップが用いられた障害の最新の発生日時や障害発生ノードが記録されている。なお、発生キーワードは、障害通知メッセージに含まれるメッセージや、障害の種類を特定するための単語や文字列とすることができる。

関連性マップには、動作履歴収集装置１でシステムログなどの動作履歴を収集したときの条件が記録されている。動作履歴の収集が行われたときの条件には、動作履歴の収集が行われたノードと障害発生ノードの履歴が含まれるが、他の任意の情報を加えることもできる。関連性マップは、例えば、コード配列を固定したコードとすることができる。例えば、図１に示すネットワークでの収集履歴を記録する関連性マップは、各桁の数値を左から順に
ap00001、ap00002、wb00001、wb00002、db00001、um00001、ap00010、ap00011、ap00012
の９台のノードの状態に対応させた９桁のコードとすることができる。また、コードに記録される数値は、ノードが取りうる状態に対応させた任意の値とすることができ、
発生ノード : ２
システムログの収集対象となったノード ： １
システムログの収集対象ではないノード ： ０
のように、予め設定できる。例えば、ap00001で障害が発生し、ap00002、wb00002、db00001、ap00010の４台のノードのシステムログが収集されることが調査対象ノードリスト３２に記録されている場合には、「２１０１１０１００」というコードとなる。

次に、収集履歴比較部が行う調査対象ノードリスト３２と関連性マップの比較について述べる。収集履歴比較部は、ノード指定部から調査対象ノードリスト３２と過去の収集履歴の比較を要求される。このとき、ノード指定部は、収集履歴比較部に障害発生ノードを通知するものとする。収集履歴比較部は、前述のコード配列の配列順とコードに記録される数値の種類を予め記憶しており、調査対象ノードリスト３２を関連性マップの表記方法に変換して関連性マップと比較したときの適合率を求める。ここで、適合率は、例えば、収集履歴比較部が求めたコードと関連性マップが一致した桁数の全体の桁数に占める割合として以下の式から計算することができる。
適合率（％）＝（値が一致した桁の数）／（関連性マップの桁数)×１００

また、収集履歴比較部は、適合閾値を記憶することができる。ここで、適合閾値は、適合率を用いて過去に類似事象があるかを判断するために用いられる閾値である。以下の記載では、過去の収集履歴との適合率が適合閾値以上であり、かつ、発生した障害が同じ障害である場合を、「過去に類似事象が発生している」と記載することがある。収集履歴比較部は、過去に類似事象が発生している場合には、システムログの収集を行わないようにノード指定部に通知する。

図１４は、第３の実施形態での動作履歴収集装置１の動作の一例を説明するフローチャートである。ステップＳ６１はメッセージ解析部の動作、ステップＳ６２、Ｓ６３とＳ６７〜Ｓ７０はノード指定部の動作、Ｓ６４、Ｓ６５は収集履歴比較部の動作であり、Ｓ６６は動作履歴収集部の動作である。図１３と図１４を参照しながら、第３の実施形態の動作について詳しく述べる。また、以下の例では、適合率が７０％以上で、発生した障害が同じ種類であるときに、収集履歴比較部は、過去に類似事象が起こっていると判定するものとする。

さらに、図１４のフローチャートと図１４の説明で述べる例では、ノード指定部は複数の調査対象ノードに対してシステムログの収集対象であるかの判定結果を同時に要求することができる場合について示している。第１および第２の実施形態に係る動作履歴収集装置１においても、図１４に示すのと同様に、ノード指定部は複数の対象ノードに同時に判定結果を要求し、それぞれのノードから通知された結果を同時に処理して調査対象ノードリスト３２を更新できる。また、第３の実施形態に係る動作履歴収集装置１でも、後で述べるように、ノード指定部は対象ノードの１つずつに判定結果を要求することもできる。

メッセージ解析部による障害発生ノードの特定と、ノード指定部による近傍ノードの特定などは第１もしくは第２の実施形態での動作と同様とすることができる（ステップＳ６１、Ｓ６２）。ここでは、ap00001が障害発生ノード、ap00002、wb00001、wb00002が近傍ノードとして特定されたものとする。

次に、ノード指定部は、近傍ノードのそれぞれにシステムログの収集対象であるかの判定を要求し、近傍ノードから通知された判定結果に基づいて調査対象ノードリスト３２を更新する（ステップＳ６３)。システムログの収集対象であるかの判定は、前述のとおり、近傍ノードのシステムログに異常が検出されるかによって行われ、第１と第２の実施形態で述べたいずれの方法を用いてもよい。ここでは、ap00002は収集対象ノードで、wb00001とwb00002は収集対象でなかったものとする。

収集履歴比較部は、調査対象ノードリスト３２の内容をコードに変換して適合率を計算する（ステップＳ６４)。なお、ノード指定部は、収集履歴比較部に適合率の計算を要求するときに、障害発生ノードと発生キーワードを通知する。ap00001が障害発生ノードであることと近傍ノードの３台について収集対象ノードかが分かっているので、収集履歴比較部は、
２１００
というコードを生成する。この４桁のコードを図１３の関連性マップテーブルに記録されている関連性マップの各々と比較して適合率を計算する。項番１に記録されている関連性マップと比較すると、最初の２桁が一致するが、関連性マップは９桁あるため、適合率は２２％である。次に、項番２に記録されている関連性マップと比較すると、４桁が一致するので適合率は４４％である。収集履歴比較部は、同様に、他の関連性マップとの適合率も計算する。

次に、収集履歴比較部は、得られた適合率と適合閾値を比較し、さらに、発生キーワードも比較することによって、過去に類似事象が起こっているかを確認する（ステップＳ６５)。ここでは、図１３に記載されている関連性マップのいずれとも適合率は７０％未満であるため、収集履歴比較部は、過去に類似事象は起こっていないと判定する。

過去に類似事象が起こっていないと判定されると、ノード指定部の要求に応じて、動作履歴収集部は、収集対象ノードのシステムログを収集する（ステップＳ６６)。ここで、動作履歴収集部は、システムログを一時ファイルとして記憶データ３０に格納することもできる。

ノード指定部は、障害発生ノードに、障害発生ノードとの通信頻度が閾値を超えているノードの通知を要求し、障害発生ノードからの通知に応じて調査対象ノードリスト３２を更新する（ステップＳ６７、Ｓ６８)。この動作は、第１の実施形態で述べたノード指定部や通信頻度解析部の動作と同様である。

次に、ノード指定部は、調査対象ノードリスト３２に記録されているノードのうち、収集対象とするかの判定が行われていないノードがあるかを判断する（ステップＳ６９)。この判断手法は、第１の実施形態で述べたとおりの手法とすることができる。ここでは、障害発生ノードとの通信頻度が閾値以上であったノードについては、判定が行われていないため、ステップＳ６３に戻る。

ステップＳ６３での判定の結果、再度調査対象ノードリスト３２が変更される。ここで、ap00010とap00011が収集対象ノードとして検出され、他のノードは収集対象とならなかったとする。すると、ステップＳ６４で収集履歴比較部は、
２１００００１１０
というコードを生成する。すると、ステップＳ６５で収集履歴比較部は、得られたコードが項番２に記録されている関連性マップと８８％の適合率であることを算出し、発生キーワードを比較する。

ノード指定部から通知された発生キーワードが「ＡＰＬ００２」である場合は、項番２に記録されている発生キーワードと一致するので、収集履歴比較部は、過去に類似事象があると判断し、システムログの収集を終了する（ステップＳ６５)。このとき、適宜、ステップＳ６６で生成された一時ファイルなどを削除するように設定することもできる。

一方、発生キーワードが項番２に記録されている発生キーワードと一致しない場合には、過去に類似事象が起こっていないと判断され、ステップＳ６６〜Ｓ６８の処理を繰り返す（ステップＳ６５〜Ｓ６８)。調査対象ノードリスト３２に記録されているノードで判定されていないノードがない場合には、ノード指定部は、調査対象ノードリスト３２の内容をコードに変換し、関連性マップテーブル３３に記録する（ステップＳ７０）。なお、ノード指定部は、収集履歴比較部に変換したコードを要求し、収集履歴比較部から通知されたコードを関連性マップテーブル３３に記録することもできる。

図１５は、収集履歴比較部の動作の一例を説明するフローチャートである。収集履歴比較部は、調査対象ノードリスト３２が更新されるまで待機する(ステップＳ８１、Ｓ８２)。調査対象ノードリスト３２が更新されると、収集履歴比較部は、その内容をコードに変換し、関連性マップテーブル３３に記録されている関連性マップとの適合率を計算する（ステップＳ８３）。適合閾値以上（ｔ％）の適合率があると、その関連性マップに対応付けられた発生キーワードと、ノード指定部から通知された発生キーワードが一致するかを確認する（ステップＳ８４、Ｓ８５）。両者の発生キーワードが一致すると、収集履歴比較部は、過去に類似事象があったと判断して、ノード指定部にその旨を通知する（ステップＳ８７)。一方、発生キーワードが不一致の場合は、収集履歴比較部は、過去に類似事象がないと判断し、その旨を通知する（ステップＳ８６、Ｓ８８)。また、適合率が適合閾値未満の場合も、収集履歴比較部は、過去に類似事象がないと判断し、その旨を通知する（ステップＳ８４、Ｓ８８)。なお、図１５に示した動作は収集履歴比較部の動作の一例である。例えば、Ｓ８１とＳ８２を変更することよって、収集履歴比較部が適合率を計算する条件を変更できるなど、収集履歴比較部の動作を変形することができる。

図１６は、ノード指定部の動作の一例を説明するフローチャートである。ここで、図１６の動作をするノード指定部が備えられている動作履歴収集装置１では、収集履歴比較部の動作が図１５のフローチャートから変形されている。この動作履歴収集装置１に含まれる収集履歴比較部は、ステップＳ８１とＳ８２で調査対象ノードリスト３２が更新されているかを確認せず、ノード指定部から過去事象があるかの問い合わせを受けたかを確認する。すなわち、収集履歴比較部は、ノード指定部から類似事象があるかの問い合わせを受けると、過去に類似事象が起こっているかを確認する。また、図１６では、ノード指定部は、システムログに異常が検出されたかの判定要求は、１回に１つの調査対象ノードに対して行う場合の例について述べる。

ステップＳ９１〜Ｓ９３では、図９のステップＳ１１〜Ｓ１３の動作として説明した動作と同様に、調査対象ノードリスト３２の初期化や近傍ノードの記録などが行われる。ノード指定部は、調査対象ノードリスト３２に記録されたノードの１つに、システムログに異常を示すメッセージが記録されているかの判定を要求する（ステップＳ９４)。次に、ノード指定部は、収集履歴比較部に、過去に類似事象が発生しているかを問い合わせる（ステップＳ９５)。収集履歴比較部は、図１５のステップＳ８３〜Ｓ８８に述べた方法で過去に類似事象があったかを確認して、結果をノード指定部に通知する。類似事象が無く、判定を要求されたノードで異常を示すメッセージが検出されたことが通知されると、ノード指定部は、異常を示すメッセージが検出されたノードについて収集対象フラグを立てる（ステップＳ９６〜Ｓ９８)。さらに、ノード指定部は、収集対象フラグを立てたノードについてのシステムログの収集を動作履歴収集部に要求する（ステップＳ９９）。一方、類似事象は無く、判定を要求されたノードでシステムログに異常を示すメッセージが検出されなかったことが通知されると、ノード指定部は、通知を受けたノードについて収集対象外フラグを立てる（ステップＳ９６、Ｓ９７、Ｓ１００)。

次に、ノード指定部は、障害発生ノードに対して、障害発生ノードとの通信頻度が閾値を超えているノードの通知を要求し、通知されたノードを調査対象ノードリスト３２に記録する（ステップＳ１０１、Ｓ１０２）。ノード指定部は、調査対象ノードリスト３２に記載されているノードのうち、収集対象とするかの判定が行われていないノードがあるかを確認し、判定が行われていないノードがある場合は、ステップＳ９４〜Ｓ１０３の処理を繰り返す。一方、調査対象ノードリスト３２に記載されているノードがいずれも収集対象となるかの判定を行っている場合には、関連性マップテーブル３３を更新して終了する（ステップＳ１０３、Ｓ１０４）。

さらに、ステップＳ９６で、収集履歴比較部によって過去に類似事象が発生したことを通知されたときには、システムログの収集を中断し、収集ずみのシステムログや作成した一時ファイルなどを削除する（ステップＳ９６、Ｓ１０５)。その後、ノード指定部は、関連性マップテーブル３３を更新する（ステップＳ１０４)。この場合の関連性マップテーブル３３の更新は、例えば、関連性マップテーブル３３の最新発生時刻の変更とすることができる。なお、先に図１４を参照しながら述べたように、類似事象が発見された場合には関連性マップテーブル３３の更新を行わないようにすることもできる。

このような実施形態とすることにより、過去に類似した事象が起こっているシステムログが重複して収集されることを避けることができる。また、動作履歴収集装置１は、過去にシステムログの収集対象となったノードと、システムログの収集対象としようとするノードの比較などを行うことにより、システムログを重複して収集することを自律的に回避する。従って、本実施形態によると、システムログの収集対象のノードやシステムログを収集する条件を、オペレータなどが障害発生ノード別に求めることなく、簡便にシステムログを収集することができる。

＜その他＞
なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。

以上の説明では、ＩＰアドレスの第１〜第３オクテットが共通するノードを検索することにより、近傍ノードを求める方法について述べたが、近傍ノードは、共通のセグメント中のノードとすることもできる。図５に示したように、構成管理データベース３１において、各ノードが属するセグメントを記録している場合には、障害発生ノードと同一のセグメントに属するノードを近傍ノードとすることができる。この場合、ノード指定部は、メッセージ解析部から通知された障害発生ノードのＩＰアドレスをキーとして、障害発生ノードの属するセグメントを特定する。さらに、ノード指定部は、構成管理データベース３１のセグメントの欄を検索し、障害発生ノードと同一のセグメントに属するノードを近傍ノードとして指定する。例えば、ap00001が障害発生ノードであると、ノード指定部は、ap00001と同一セグメントに属するap00002、wb00001、wb00002を近傍ノードとする。このように、セグメントに応じて近傍ノードを指定すると、第１〜第３オクテットが異なるノードであっても近傍ノードとして指定することができる。そこで、例えば、同一のセグメントに２５６台以上のノードが属している場合や、同一のセグメントにＩＰアドレスの第１〜第３オクテットが異なるノードが混在している場合などでも、ノード指定部は、近傍ノードを指定することができる。

また、近傍ノードを障害発生ノードと同一のサブネットに属するノードとすることもできる。この場合、ノード指定部は、サブネットの設定を知るために、予めネットマスクを記憶しているか、記憶データ３０から読み出す。次に、メッセージ解析部から障害発生ノードを通知されると、ノード指定部は、障害発生ノードと同一のサブネットに属するノードを構成管理データベース３１から抽出する。例えば、図１に示すネットワークでap00001が障害発生ノードであるとする。ネットマスクが「２５５．２５５．２５５．０」である場合、ノード指定部は構成管理データベース３１を確認し、第１〜第３オクテットがap00001と同じ「２０．１００．２．」であるap00002、wb00001、wb00002を近傍ノードとする。一方、ネットマスクが「２５５．２５５．０．０」である場合、ノード指定部は、第１および第２オクテットがap00001と同じ「２０．１００．」であるノードを近傍ノードとする。すると、ap00002、wb00001、wb00002に加えて、db00001とum00001を近傍ノードとする。

さらに、ノード指定部は、ホップ数を用いて近傍ノードを指定することもできる。ノード指定部は、ホップ数による判定では、ネットワーク装置４で区切られたネットワークの境界の数に応じてホップ数を決定する。このとき構成管理データベース３１において、各ノードやネットワーク装置４を収容するネットワーク装置４を各ノードなどに対応付けて記録することができる。例えば、ap00001が障害発生ノードでホップ数が１のノードを近傍ノードとするとき、ネットワーク装置４ｂに収容されているノードが近傍ノードとなる。またホップ数が２の場合には、ノード指定部は、ネットワーク装置４ｂなどを収容しているネットワーク装置は４ａであることを求め、ネットワーク装置４ａに収容されているノードを近傍ノードとして指定する。

第３の実施形態の説明では、関連性マップを使用したときの収集履歴の記録について述べたが、収集履歴の記録方法は関連性マップの作成には限られない。例えば、障害発生ノードや収集対象となったノードのノード名などを記録したリストなどの形で、収集が行われたときの条件を記録することもできる。

また、以上の説明では、通信頻度解析部は、通信頻度をアクセス数として求める場合について述べたが、一定時間でのアクセス数として通信頻度を求めることもできる。かかる場合には、通信頻度解析部は、予め、アクセス数を求める時間範囲を記憶しているか、ノード指定部から指定される。

さらに、第１および第３の実施形態において、第２の実施形態と同様に、障害が発生した時刻を基準とした所定の時間の範囲のシステムログを検索するように異常履歴検出部を変形することもできる。

上述の各実施形態に対し、さらに以下の付記を開示する。
（付記１）
ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定する解析手段、
前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出されるかの判定を要求する判定要求を送信し、前記判定要求を受けたノードの動作履歴に前記異常が検出されたことを示す異常検出メッセージを受信すると、前記異常が検出されたノードを、前記動作履歴の取得対象のノードに指定するノード指定手段、
前記ノード指定手段で指定されたノードの前記動作履歴を収集する動作履歴収集手段
を備えることを特徴とする動作履歴収集装置。
（付記２）
前記ノード指定手段は、前記障害が発生した時刻を基準とした所定の時間の範囲に前記異常が検出されるかの判定を要求する
ことを特徴とする付記１に記載の動作履歴収集装置。
（付記３）
前記ノード指定手段は、前記近傍ノードおよび前記アクセスノードに対して、前記障害が発生した時刻を基準とした所定の時間の範囲に記録された異常が、前記障害に関連した異常であるかの判定をさらに要求し、
前記記録された異常が前記動作履歴に定期的に記録されていない場合に、前記異常を検出したノードは、前記判定要求への返信として前記異常検出メッセージを送信する
ことを特徴とする付記１乃至２に記載の動作履歴収集装置。
（付記４）
前記近傍ノードおよび前記アクセスノードは、前記障害が発生した日より前の日の前記異常が発生した時刻と同じ時刻を基準とした時間範囲に、前記異常が検出されていない場合、前記異常が前記障害に関連した異常であると判定する
ことを特徴とする付記３に記載の動作履歴収集装置。
（付記５)
第１の障害の発生に起因して前記動作履歴が収集されたノードを、収集履歴として記録する収集履歴記録手段と、
第２の障害の発生に起因して前記異常検出メッセージを送信したノードと前記収集履歴に含まれるノードの一致率を算出する比較手段をさらに備え、
前記動作履歴収集手段は、前記一致率が所定の割合より小さい場合に、前記ノード指定手段で指定されたノードの動作履歴を収集する
ことを特徴とする付記１乃至４に記載の動作履歴収集装置。
（付記６）
前記メッセージ解析手段は、前記ネットワークで発生した前記第１および第２の障害の種類を特定し、
前記収集履歴記録手段は、前記収集履歴を、前記第１の障害の種類と関連付けて記録し、
前記動作履歴収集手段は、前記一致率が所定の割合より小さく、かつ、前記第１の障害と前記第２の障害が一致しない場合に、前記第２の障害の発生に起因して前記ノード指定手段で指定されたノードの動作履歴を収集する
ことを特徴とする付記５に記載の動作履歴収集装置。
（付記７）
ネットワークに含まれるノードの履歴を収集する履歴収集ノードは、前記ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定し、
前記履歴収集ノードは、前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出されるかの判定を要求する判定要求を送信し、
前記判定要求を受けたノードの前記動作履歴に異常が検出されたことを示す異常検出メッセージを受信すると、前記異常が検出されたノードを、前記動作履歴の取得対象のノードに指定し、
前記指定されたノードで記録された動作履歴を収集する
ことを特徴とする動作履歴収集方法。
（付記８）
ネットワークに含まれるコンピュータを、
前記ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定するメッセージ解析手段、
前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出された場合に異常検出メッセージを送信することを要求する要求メッセージを送信する送信手段、および、
前記異常検出メッセージを受信すると、前記異常検出メッセージを送信したノードで記録された動作履歴を収集する動作履歴収集手段
として機能させることを特徴とする動作履歴収集プログラム。

１ 動作履歴収集装置
２ 運用管理サーバ
３（３ａ〜３ｈ） サーバ
４（４ａ〜４ｃ） ネットワーク装置
５ 外部ネットワーク
１１、４１ ＣＰＵ
１２、４２ メモリ
１３、４３ 出入力装置
１４、４４ 外部記憶装置
１５、４５ 読み取り装置
１６、４６ 可搬記憶媒体
１７、４７ ネットワーク接続装置
２０、５０ プログラム
２１ メッセージ解析モジュール
２２ ノード指定モジュール
２３ 動作履歴収集モジュール
２４ 収集履歴比較モジュール
３０、５３ 記憶データ
３１ 構成管理データベース
３２ 調査対象ノードリスト
３３ 関連性マップテーブル
５１ 異常履歴検出モジュール
５２ 通信頻度解析モジュール

Claims (5)

1. ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定する解析手段、
   前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出されるかの判定を要求する判定要求を送信し、前記判定要求を受けたノードの動作履歴に前記異常が検出されたことを示す異常検出メッセージを受信すると、前記異常が検出されたノードを、前記動作履歴の取得対象のノードに指定するノード指定手段、
   前記ノード指定手段で指定されたノードの前記動作履歴を収集する動作履歴収集手段
   を備えることを特徴とする動作履歴収集装置。
2. 前記ノード指定手段は、前記近傍ノードおよび前記アクセスノードに対して、前記障害が発生した時刻を基準とした所定の時間の範囲に記録された異常が、前記障害に関連した異常であるかの判定をさらに要求し、
   前記記録された異常が前記動作履歴に定期的に記録されていない場合に、前記異常を検出したノードは、前記判定要求への返信として前記異常検出メッセージを送信する
   ことを特徴とする請求項１に記載の動作履歴収集装置。
3. 第１の障害の発生に起因して前記動作履歴が収集されたノードを、収集履歴として記録する収集履歴記録手段と、
   第２の障害の発生に起因して前記異常検出メッセージを送信したノードと前記収集履歴に含まれるノードの一致率を算出する比較手段をさらに備え、
   前記動作履歴収集手段は、前記一致率が所定の割合より小さい場合に、前記ノード指定手段で指定されたノードの動作履歴を収集する
   ことを特徴とする請求項１乃至２に記載の動作履歴収集装置。
4. ネットワークに含まれるノードの履歴を収集する履歴収集ノードは、前記ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定し、
   前記履歴収集ノードは、前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出されるかの判定を要求する判定要求を送信し、
   前記判定要求を受けたノードの前記動作履歴に異常が検出されたことを示す異常検出メッセージを受信すると、前記異常が検出されたノードを、前記動作履歴の取得対象のノードに指定し、
   前記指定されたノードで記録された動作履歴を収集する
   ことを特徴とする動作履歴収集方法。
5. ネットワークに含まれるコンピュータを、
   前記ネットワークで障害が発生したことを通知するメッセージを解析して、前記障害が発生した障害発生ノードを特定するメッセージ解析手段、
   前記障害発生ノードの近傍ノードと、前記障害発生ノードとの通信頻度が所定の閾値より大きいノードを表すアクセスノードとに対して、各々のノードの動作履歴に異常が検出された場合に異常検出メッセージを送信することを要求する要求メッセージを送信する送信手段、および、
   前記異常検出メッセージを受信すると、前記異常検出メッセージを送信したノードで記録された動作履歴を収集する動作履歴収集手段
   として機能させることを特徴とする動作履歴収集プログラム。

Images