JP2019145024A - 判定プログラム、判定方法、および情報処理装置 - Google Patents

Abstract

【課題】所定の順番で出力された複数の関連するメッセージを検出できるようにする。【解決手段】情報処理装置１０は、複数のソフトウェア１ａ，２ａ，３ａそれぞれの実行により出力された複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃを取得する。次に情報処理装置１０は、メッセージの出力順を示すメッセージパターンを記憶する記憶部１１を参照して、取得した複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、記憶部１１に記憶されたメッセージパターンに対応する組を特定する。そして情報処理装置１０は、特定した組に含まれるメッセージの識別情報を表示部１３に表示する。【選択図】図１

Description

本発明は、判定プログラム、判定方法、および情報処理装置に関する。

大規模なコンピュータシステムは多数のサーバを含んでおり、各サーバでは、それぞれ複数のソフトウェアが実行されている。サーバで実行されるソフトウェアは、それぞれが独自にメッセージを出力し、出力したメッセージをサーバがログとして記録する。またサーバには、コンピュータ本体以外に、さまざまな周辺機器が接続されている。そしてサーバでは、コンピュータ本体がハードウェアに関するメッセージを出力する他、周辺機器もメッセージを出力し、サーバは出力された各メッセージをログとして記録する。その結果、コンピュータシステムでは、様々な種別の大量のメッセージがログとして記録される。

記録されたログは、トラブルの原因特定に利用される。例えばシステム管理者は異常（エラーやアラートなど）を検知した際、すべてのログから原因特定に繋がるメッセージを検索して、検索によって抽出したメッセージを確認することで、トラブルの原因を調査する。その際、システム管理者は、原因を特定できるまで、メッセージの検索および内容確認の作業を繰り返し行う。このような調査を人手だけで行うと、原因特定までに時間がかかる。

そこで、大量のメッセージの解析を支援する技術が考えられている。例えば大量のメッセージから異常を示すメッセージを正確に検出するメッセージ異常自動判別装置がある。またシステム障害時の未処理メッセージの紛失を防止するメッセージ紛失救済方式も考えられている。またメッセージについて発生間隔が一定範囲を外れたか否かを判定し、一定範囲を外れた場合にシステムの障害を検知するメッセージ判定装置もある。さらに、監視対象要素で発生したイベント情報に基づいて、障害箇所をソフトウェア単位で特定できる運用管理方法がある。

特開２００６−３１８０７１号公報 特開平０７−１４１２１１号公報 国際公開第２０１２／１６０６３７号 国際公開第２００４／０６１６８１号

システムのトラブルが発生したとき、複数の関連するメッセージが時系列で順番に出力される場合がある。この場合、これらの複数の関連するメッセージが所定の順番で出力されたことを検出することで、トラブルの原因を特定できる。しかし従来の技術では、大量のメッセージの中から、所定の順番で出力された複数の関連するメッセージを検出することができない。

１つの側面では、本件は、所定の順番で出力された複数の関連するメッセージを検出できるようにすることを目的とする。

１つの案では、コンピュータに、以下の処理を実行させる判定プログラムが提供される。
コンピュータは、複数のソフトウェアそれぞれの実行により出力された複数のメッセージを取得する。次にコンピュータは、メッセージの出力順を示すメッセージパターンを記憶する記憶部を参照して、取得した複数のメッセージに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、記憶部に記憶されたメッセージパターンに対応する組を特定する。そしてコンピュータは、特定した組に含まれるメッセージの識別情報を表示部に表示する。

１態様によれば、所定の順番で出力された複数の関連するメッセージを検出することが可能となる。

第１の実施の形態に係る判定方法の概要を示す図である。 第２の実施の形態のシステム構成の一例を示す図である。 監視サーバのハードウェアの一例を示す図である。 ログの収集例を示す図である。 複数のサーバと監視サーバとが有する機能を示すブロック図である。 ログファイルの一例を示す図である。 メッセージパターン定義情報の一例を示す図である。 条件詳細情報の一例を示す図である。 制御テーブルの一例を示す図である。 制御テーブルの更新例を示す図である。 監視対象登録処理の手順の一例を示すフローチャートである。 管理情報追加処理の手順の一例を示すフローチャートである。 監視処理の手順の一例を示すフローチャートである。 監視解除処理の手順の一例を示すフローチャートである。 監視対象更新処理の手順の一例を示すフローチャートである。 メッセージパターンの第１の照合例を示す図である。 メッセージパターンの第２の照合例を示す図である。 メッセージパターンの第３の照合例を示す図である。 メッセージパターンの第４の照合例を示す図である。 個別ログファイルの一例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、第１の実施の形態について説明する。第１の実施の形態は、大量のメッセージの中から、所定の順番で出力された複数の関連するメッセージの組を判定する判定方法である。この判定方法は、例えば当該判定方法の手順を記述した判定プログラムを、情報処理装置に実行させることで実現できる。

図１は、第１の実施の形態に係る判定方法の概要を示す図である。情報処理装置１０は、複数のサーバ１〜３に接続されている。サーバ１は、ソフトウェア１ａを実行する。そしてサーバ１は、ソフトウェア１ａの実行過程で出力したメッセージ４ａ〜４ｃを、情報処理装置１０に送信する。サーバ２は、ソフトウェア２ａを実行する。そしてサーバ２は、ソフトウェア２ａの実行過程で出力したメッセージ５ａ〜５ｃを、情報処理装置１０に送信する。サーバ３は、ソフトウェア３ａを実行する。そしてサーバ３は、ソフトウェア３ａの実行過程で出力したメッセージ６ａ〜６ｃを、情報処理装置１０に送信する。

情報処理装置１０は、記憶部１１、処理部１２、および表示部１３を有する。記憶部１１は、例えば情報処理装置１０が有するメモリ、またはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサ、または演算回路である。表示部１３は、液晶または有機ＥＬ（Electro Luminescence）などの表示装置である。

記憶部１１は、メッセージの出力順を示すメッセージパターンを記憶する。
処理部１２は、複数のソフトウェア１ａ，２ａ，３ａそれぞれの実行により出力された複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃを取得する。例えば処理部１２は、複数のソフトウェア１ａ，２ａ，３ａそれぞれの実行によりメッセージが出力されるごとに、出力されたメッセージを取得する。

処理部１２は、取得した複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃそれぞれに識別情報「Ｔ１〜Ｔ９」を付与する。例えば処理部１２は、取得日時を示す日時情報を、識別情報として付与する。処理部１２において日時情報を付与することで、各サーバ１〜３の内部時計が不正確な場合であっても、処理部１２が付与した日時情報に基づいて、メッセージ間の先後関係や、連続するメッセージ間の時間間隔を正しく判断することができる。

さらに処理部１２は、記憶部１１を参照して、取得した複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、記憶部１１に記憶されたメッセージパターンに対応する組を特定する。例えば処理部１２は、取得した複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃのうちの１以上のメッセージを組み合わせた組を生成する。そして処理部１２は、生成した組のうち、組に含まれるメッセージの出力順がメッセージパターン通りの組を特定する。

そして処理部１２は、特定した組に含まれるメッセージの識別情報を表示部１３に表示する。
このように情報処理装置１０によれば、複数のソフトウェア１ａ，２ａ，３ａの実行により出力されたメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃの中から、メッセージの出力順を示すメッセージパターンに対応するメッセージの組が特定される。例えば図１の例では、「メッセージｘ１」が出力された後、「メッセージｙ２」が出力され、さらにその後、「メッセージｚ３」が出力されることを示すメッセージパターンが、記憶部１１に格納されている。処理部１２は、取得したメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃの中から、識別情報「Ｔ１」が付与されたメッセージ４ａ、識別情報「Ｔ７」が付与されたメッセージ５ｂ、識別情報「Ｔ８」が付与されたメッセージ６ｃの組を特定する。そして処理部１２は、特定した組に含まれる各メッセージの識別情報「Ｔ１」、「Ｔ７」、「Ｔ８」を表示する。

例えば複数のサーバ１〜３の連携処理についてのトラブル発生時に、情報処理装置１０が、メッセージパターンと一致する時系列のメッセージの組の各メッセージの識別情報を表示する。これにより、そのトラブルの原因を迅速に特定することができる。例えば過去のトラブル対処事例に基づいて、予めメッセージパターンに対応付けて、そのメッセージパターンに対応するメッセージの組が出力されたときのトラブルの原因を示す情報を、記憶部１１に格納しておくことができる。これにより、メッセージパターンと一致する時系列のメッセージの組が出力された場合、システム管理者は、そのメッセージパターンに対応付けられたトラブルの原因を示す情報を参照することで、トラブルの原因を容易に特定できる。

なおメッセージパターンに、時系列で連続するメッセージ間の最大の時間間隔を設定しておくこともできる。この場合、処理部１２は、メッセージパターンに対応する組を特定する際に、取得した複数のメッセージ４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃに含まれるメッセージの組の中から、最大の時間間隔についての条件を満たすメッセージの組を特定する。例えば処理部１２は、組に含まれる複数のメッセージの出力順がメッセージパターン通りであり、時系列上で連続して出力されたメッセージ間の時間間隔がメッセージパターンに示す最大の時間間隔以下の組を特定する。

このようにメッセージパターンに、メッセージ間の時間間隔の条件を含めることで、トラブルの原因としてより適確な時系列のメッセージの組を特定することができる。
また、メッセージパターンには、特定のメッセージが出力されないことを、そのメッセージパターンに対応するメッセージの組の条件として定義することができる。例えばメッセージパターンに、時系列上、第１メッセージの出力後の所定期間内に第２メッセージが出力されないことを定義することができる。この場合、処理部１２は、第１メッセージを取得した場合、取得した第１メッセージの出力後の所定期間内に第２メッセージが出力されたか否かを確認する。そして処理部１２は、所定期間内に第２メッセージが出力されていない場合に、取得した第１メッセージを含み、メッセージパターンに対応する組を特定する。

このように、メッセージパターンにおいて、特定のメッセージが出力されないことを定義できるようにすることで、トラブルの原因としてより適確な時系列のメッセージの組を特定することができる。例えばトラブル発生時には出力されることがないメッセージ（処理の正常終了を示すメッセージなど）を、上記の第２メッセージとして、メッセージパターンに定義しておくことができる。これにより、所定期間内に第２メッセージが出力されたにもかかわらず、メッセージパターンに含まれるメッセージの組が、トラブルの原因に関連するものとして誤って特定されることを抑止できる。すなわち、トラブルの原因の特定精度が向上する。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、複数のサーバで発生したハードウェアまたはソフトウェアのメッセージを、監視サーバで収集し、解析するものである。

図２は、第２の実施の形態のシステム構成の一例を示す図である。ネットワーク２０を介して、複数のサーバ３１，３２，・・・と、それらの動作を監視する監視サーバ１００とが接続されている。複数のサーバ３１，３２，・・・は、例えばｗｅｂサーバ、アプリケーションサーバ、ＤＢ（Data Base）サーバである。監視サーバ１００は、複数のサーバ３１，３２，・・・それぞれがログとして記録したメッセージを収集し、メッセージを解析する。

図３は、監視サーバのハードウェアの一例を示す図である。監視サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、監視サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬを用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、監視サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態における監視サーバ１００の処理機能を実現することができる。なお、複数のサーバ３１，３２，・・・それぞれも、図３に示した監視サーバ１００と同様のハードウェアにより実現することができる。また、第１の実施の形態に示した情報処理装置１０も、図３に示した監視サーバ１００と同様のハードウェアにより実現することができる。

監視サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。監視サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、監視サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また監視サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

監視サーバ１００は、図３に示すハードウェアにより、ネットワーク２０を介して、サーバ３１，３２，・・・からメッセージのログを収集する。
図４は、ログの収集例を示す図である。サーバ３１には、ハードウェアとして、サーバ本体３１ａと周辺機器３１ｂ，３１ｃを有している。サーバ本体３１ａは、プロセッサおよびメモリを有するコンピュータシステムである。周辺機器３１ｂ，３１ｃは、ストレージ装置などの各種機器である。サーバ本体３１ａは、プロセッサやメモリの動作状態を示すメッセージを出力し、そのメッセージをログ４１ａとしてストレージ装置に格納する。周辺機器３１ｂ，３１ｃは、それぞれ周辺機器３１ｂ，３１ｃの動作状態を示すメッセージを出力し、そのメッセージをログ４１ｂ，４１ｃとしてストレージ装置に格納する。

またサーバ３１では、プロセッサによりＯＳ３１ｄを実行しており、ＯＳ３１ｄの実行により提供される実行環境上で例えばミドルウェア３１ｅが実行されている。そしてミドルウェア３１ｅの実行により提供される実行環境上でアプリケーションソフトウェア３１ｆが実行されている。サーバ３１のプロセッサは、ＯＳ３１ｄを実行することで、サーバ３１の動作状態を示すメッセージを出力し、そのメッセージをログ４１ｄとしてストレージ装置に格納する。またサーバ３１のプロセッサは、ミドルウェア３１ｅを実行することで、ミドルウェア３１ｅの実行状態を示すメッセージを出力し、そのメッセージをログ４１ｅとしてストレージ装置に格納する。さらにサーバ３１のプロセッサは、アプリケーションソフトウェア３１ｆを実行することで、アプリケーションソフトウェア３１ｆの実行状態を示すメッセージを出力し、そのメッセージをログ４１ｆとしてストレージ装置に格納する。

監視サーバ１００は、サーバ３１からログ４１ａ〜４１ｆを取得する。同様に、監視サーバ１００は、他のサーバ３２，・・・からもログを取得する。これによって監視サーバ１００では、大量のメッセージを収集することができる。

大量のメッセージから、トラブルの原因特定に繋がるメッセージを効率良く短時間で検索・抽出するためには、以下の条件での検索が有効である。
第１の検索は、時系列関係および時間関係がある複数のメッセージの検索である。例えば過去の事例から、あるトラブル発生時には、３つのメッセージが時系列で所定の順番で出力され、連続するメッセージ間の時間間隔が１分以内であることが分かっていることがある。この場合、出力される３つのメッセージの時系列の関係と、連続するメッセージ間の時間間隔を条件としてメッセージの検索を行い、合致するメッセージ群（１以上のメッセージの組み合わせ）が検出されれば、過去事例と同じ原因であると特定できる。

第２の検索は、時系列関係および時間関係がある複数のメッセージのうちの、特定のメッセージが出力されていないことを確認するための、そのメッセージの検索である。例えば、あるコマンドの実行を要求するメッセージ出力後、５分以内に実行の終了を示す終了メッセージが出力されるという関係がある場合、５分以内に終了メッセージが出ていなければ、そのコマンドの実行過程でトラブルが発生していることが特定できる。

ここで図４に示したように、各サーバ３１，３２，・・・から収集したメッセージは、出力元が様々である。このような出力元の異なる多数のメッセージから、第１の検索および第２の検索を正確に実行するには、以下のような課題がある。

第１の課題は、複数のメッセージが所定の順番で出力されたこと、または出力されていないことを確認するのが困難なことである。例えば従来技術では、特定メッセージが出力されてから一定時間内に別のメッセージが出力されていないことを確認するための検索条件を指定することができない。トラブルの原因をある程度絞り込んだ後であれば、システム管理者が、時系列で出力される、あるいは出力されないメッセージの検索を個別に行い、複数のメッセージ間の時系列関係を確認するのは可能である。しかし、トラブルの原因が絞り込まれていない段階において、可能性のあるすべての原因に関して、関連する個々のメッセージの出力の有無を、人手で確認するのは非現実的である。

第２の課題は、出力元の異なる大量のメッセージに対して、日時による一括検索が困難な点である。様々なハードウェアまたはソフトウェアにより出力されたメッセージには、出力日時を示すタイムスタンプが付与されているが、メッセージの出力元ごとにタイムスタンプのフォーマットが異なる。例えば、日時の表記方法として「01:07:08 2014/05/12」と記述しているメッセージもあれば、「12/May/2014:01:07:38 +0900」と記述しているメッセージもある。従来技術では、このような異なるフォーマットの複数のメッセージについて、日時を指定した検索を一括で行うことができない。しかも、メッセージの出力元の内部時計が、不正確な場合もある。その場合、メッセージが出力された実際の日時と、そのメッセージに付与されたタイムスタンプに示される日時とに誤差が生じ、メッセージ間の時系列関係が不正確となる。

監視サーバ１００は、上記の第１の課題および第２の課題を解決するために、以下のような処理を行う。
第１の課題を解決するために、監視サーバ１００は、時系列で出力される複数のメッセージの出力パターン（メッセージパターン）を、メッセージパターン定義情報として、予め記憶しておく。メッセージパターン定義情報には、あるメッセージが出力されてから関連する次のメッセージが出力されるまでの時間も含まれる。またメッセージパターン定義情報には、あるメッセージが出力されてから別のメッセージが出力されていないことを確認する時間も含まれる。そして監視サーバ１００は、出力されたメッセージをメッセージパターン定義情報に示されるメッセージパターンと照合し、メッセージパターンに合致するメッセージ群を検出する。

これは、トラブルの原因ごとに、別々のログにある複数のメッセージがパターン化できることに基づいている。すなわち、トラブル発見のきっかけとなるエラーなどのメッセージと、それ以前に出力され、原因の特定に役立つアラートなどのメッセージとの間に、一定の時間間隔がある。このような時間間隔を反映させたメッセージパターン定義を用いて、合致するメッセージ群の有無を検出することで、特定メッセージが出力されてから一定時間内に別のメッセージが出力されること、あるいは出力されないことを、確認できる。

第２の課題を解決するために、監視サーバ１００は、複数のログに含まれるメッセージについて、監視サーバ１００自身が、所定のフォーマットにより日時の情報を付与する。これにより、メッセージの出力・未出力についての時間監視に共通の時計を使うことができる。その結果、メッセージの出力元の時刻のずれの影響を受けずに、メッセージの時系列の関係、およびメッセージ間の時間間隔を正確に監視できる。しかも、日時の情報が共通のフォーマットで記述されていることで、出力元の異なる複数のメッセージであっても、各メッセージの出力時刻を認識することができる。

図５は、複数のサーバと監視サーバとが有する機能を示すブロック図である。サーバ３１は、ログを監視サーバ１００に送信するエージェント３１ｇを有している。エージェント３１ｇは、サーバ３１内のハードウェアまたはソフトウェアに関するメッセージのログファイルへの出力を監視する。そしてエージェント３１ｇは、メッセージの出力を検出すると、そのメッセージを監視サーバ１００へ送信する。なおエージェント３１ｇは、送信するメッセージに、そのメッセージの出力元のサーバ名とログファイル名とを付与する。他のサーバ３２，・・・も、同様のエージェントを有している。

監視サーバ１００は、記憶部１１０、ログ収集部１２０、監視対象登録部１３０、監視部１４０、および表示制御部１５０を有する。
記憶部１１０は、収集したメッセージ、およびメッセージの解析に用いる情報を記憶する。記憶部１１０としては、例えばメモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。記憶部１１０には、ログファイル１１１、メッセージパターン定義情報１１２、条件詳細情報１１３、制御テーブル１１４、および複数の個別ログファイル１１５ａ，１１５ｂ，・・・が格納されている。ログファイル１１１は、複数のサーバ３１，３２，・・・それぞれから収集されたメッセージが記録されたファイルである。メッセージパターン定義情報１１２は、トラブルの原因を特定するための時系列でのメッセージの出力パターンを示す情報である。条件詳細情報１１３は、メッセージパターン定義情報１１２に示されるメッセージパターン内の各メッセージに合致する条件についての詳細情報である。制御テーブル１１４は、いずれかのメッセージパターンに少なくとも途中までは合致する時系列のメッセージ群についての管理情報が登録されたデータテーブルである。管理情報には、照合対象のメッセージパターンに沿って時系列上次に出力される、または出力されないメッセージについて、出力されたこと、または出力されなかったことを判定するための情報が示されている。個別ログファイル１１５ａ，１１５ｂ，・・・それぞれは、メッセージパターン定義情報１１２に示されるいずれかのメッセージパターンと合致するメッセージ群が記録されたファイルである。

ログ収集部１２０は、複数のサーバ３１，３２，・・・それぞれからメッセージを収集する。例えばログ収集部１２０は、複数のサーバ３１，３２，・・・それぞれのエージェントが送信したメッセージを受信し、そのメッセージをログファイル１１１に書き込む。なお、ログ収集部１２０は、受信したメッセージに対して、受信した時点の日時を示すタイムスタンプを付与する。

監視対象登録部１３０は、メッセージパターン内の先頭のメッセージに合致するメッセージを検出し、そのメッセージパターンを照合対象のメッセージパターンとする。そして監視対象登録部１３０は、照合対象のメッセージパターンに沿った後続のメッセージの出力の有無を管理するための管理情報を、制御テーブル１１４に登録する。また監視対象登録部１３０は、照合対象のメッセージパターン内の先頭のメッセージに合致するメッセージが書き込まれた新たな個別ログファイルを生成し、生成した個別ログファイルを記憶部１１０に格納する。

監視部１４０は、照合対象のメッセージパターンに途中まで一致している時系列のメッセージ群に続けて、その照合対象のメッセージパターンに合致する次のメッセージの有無を監視する。監視部１４０は、照合対象のメッセージパターンに合致する次のメッセージの有無が確認できた場合、監視対象に対応する制御テーブル１１４内の管理情報を更新する。また監視部１４０は、照合対象のメッセージパターンに合致する次のメッセージが出力を検出した場合、検出したメッセージを、更新した管理情報に対応する個別ログファイルに、追加登録する。

表示制御部１５０は、メッセージパターン定義情報１１２で定義されているメッセージパターンのいずれかと一致するメッセージ群の情報を、モニタ２１に表示する。例えば表示制御部１５０は、制御テーブル１１４を参照して、メッセージパターンに一致するメッセージ群を検出したことにより監視が終了したことを示す管理情報を検出する。そして表示制御部１５０は、検出した管理情報に対応する個別ログファイルの内容を、モニタ２１に表示する。

なお、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
次に、記憶部１１０に格納される情報について、具体的に説明する。

図６は、ログファイルの一例を示す図である。ログファイル１１１には、ログ収集部１２０が収集したメッセージごとのレコードが登録されている。各レコードには、ログ収集部１２０が付与したタイムスタンプ、出力元のサーバ名とログファイル名、および収集したメッセージが含まれる。

図６に示すように、収集したメッセージそれぞれにもタイムスタンプが含まれているが、日時の形式や、メッセージ内でのタイムスタンプの位置が、出力元によって異なる。また、メッセージ内でのタイムスタンプは、時刻にずれのある場合がある。さらに異なるタイムゾーンの時刻が、タイムスタンプとして記録されているメッセージもある。これらのメッセージに、ログ収集部１２０が、監視サーバ１００における内部時計に基づく日時の情報をタイムスタンプとして付与することで、出力元が異なる複数のメッセージの出力日時が、共通の時計に基づいて管理される。

図７は、メッセージパターン定義情報の一例を示す図である。メッセージパターン定義情報１１２には、トラブル発生時に出力する、あるいは出力しないメッセージのパターンが登録されている。具体的には、メッセージパターン定義情報１１２には、メッセージパターンの定義名に対応付けて、そのメッセージパターンの成立条件を示す情報が時系列に登録されている。定義名は、メッセージパターンを識別するための名称である。

成立条件を示す情報には、項番、条件名、待ち時間、発生の有無が含まれる。
項番は、対応する条件のメッセージパターン内での時系列の出現順を示す数値である。項番「１」は、メッセージパターンの最初のメッセージに関する条件である。項番「１」の条件を、特に起点の条件と呼ぶ。メッセージパターンにおける項番が最大値である条件は、メッセージパターンの最後のメッセージに関する条件である。項番が最大値の条件を、特に終点の条件と呼ぶ。図７の例では、定義名「パターン１」のメッセージパターンでは、項番「３」の条件が終点の条件である。また、定義名「パターン２」のメッセージパターンでは、項番「２」の条件が終点の条件である。

条件名は、監視対象のメッセージの判別条件の名称である。なお、判別条件の具体的な内容は、条件詳細情報１１３に示される。待ち時間は、次のメッセージの判別条件が成立するか否かを監視する時間（次のメッセージが関連するメッセージであるための最大の時間間隔）である。発生の有無は、メッセージパターンの成立条件が、判別条件に合致するメッセージが発生することなのか、発生しないことなのかを示す情報である。

図７の例では、定義名「パターン１」のメッセージパターンは、「条件Ａ」→「条件Ｂ」→「条件Ｃ」の順で、各判別条件を満たすメッセージが待ち時間以内に出力された場合に、そのメッセージパターンに一致するメッセージ群が成立する。また定義名「パターン２」のメッセージパターンは、「条件Ｄ」の判別条件を満たすメッセージが出力された後、待ち時間の間に「条件Ｅ」の判別条件を満たすメッセージが出力されない場合に、そのメッセージパターンの成立条件が満たされる。

図８は、条件詳細情報の一例を示す図である。条件詳細情報１１３には、メッセージの判別条件ごとのレコードが登録されている。判別条件のレコードには、条件名、対象サーバ、ログファイル名、ｇｒｅｐ文字列が含まれる。条件名は、判別条件の名称である。対象サーバは、メッセージの出力元のハードウェアまたはソフトウェアを有するサーバの名称である。ログファイル名は、メッセージの取得元のログファイルの名称である。取得元のログファイルとは、メッセージの出力元のハードウェアまたはソフトウェアに関するメッセージが書き込まれたサーバ３１，３２，・・・内のファイルである。ｇｒｅｐ文字列は、ログファイル１１１から、判別条件を満たすメッセージを検索するための検索条件を示す文字列である。ｇｒｅｐ文字列としては、例えばエラーメッセージの文字列の少なくとも一部、エラーコードなどが設定される。ｇｒｅｐ文字列を正規表現で表すこともできる。

図９は、制御テーブルの一例を示す図である。制御テーブル１１４には、照合対象のメッセージパターンに前方一致しているメッセージ群ごとのレコードが登録されている。各レコードには、管理番号、照合対象パターン、監視中条件、期限の欄が設けられている。管理番号の欄には、監視対象のメッセージパターンに前方一致しているメッセージ群の識別番号が設定される。照合対象パターンの欄には、該当するメッセージ群が部分一致しているメッセージパターンの定義名が設定される。監視中条件の欄には、監視対象のメッセージパターンに沿って、次に発生するまたは発生しないことを監視する対象の条件の条件名が設定される。期限の欄には、監視する対象の条件についての監視する期限が設定される。

制御テーブル１１４内のレコードは、監視中条件に合致するメッセージが期限内に出力されたとき、または監視中条件に合致するメッセージが期限内に出力されなかったときに更新される。

図１０は、制御テーブルの更新例を示す図である。例えば図１０の例では、時刻「１０：５１」に、「パターン１」の監視起点である「条件Ａ」に合致するメッセージが出力されている。その結果、時刻「１０：５２」の時点では、制御テーブル１１４に、管理番号「ｉｎｃ０００１」のレコードが登録されている。

時刻「１０：５３」に、「パターン１」の２番目の条件である「条件Ｂ」に合致するメッセージが出力されている。その結果、時刻「１０：５４」の時点では、制御テーブル１１４の管理番号「ｉｎｃ０００１」のレコードの監視中条件と期限とが更新されている。

時刻「１１：００」に、「パターン１」の監視起点である「条件Ａ」に合致するメッセージが出力されている。その結果、時刻「１１：０１」の時点では、制御テーブル１１４に、管理番号「ｉｎｃ０００２」のレコードが登録されている。

時刻「１１：０２」に、「パターン１」の終点である「条件Ｃ」に合致するメッセージが出力されている。その結果、時刻「１１：０３」の時点では、制御テーブル１１４の管理番号「ｉｎｃ０００１」のレコードの監視中条件と期限とが更新されている。終点の条件が満たされたことで、監視中条件には、監視終了を示す情報「ｅｎｄ」が設定されている。

時刻「１１：０４」までに、管理番号「ｉｎｃ０００２」の監視中条件である「条件Ｂ」に合致するメッセージが出力されていない。その結果、時刻「１１：０５」の時点では、制御テーブル１１４の管理番号「ｉｎｃ０００２」のレコードに対応するメッセージ群の監視が終了し、管理番号「ｉｎｃ０００２」のレコードは制御テーブル１１４から削除されている。

時刻「１３：００」に、「パターン２」の監視起点である「条件Ｄ」に合致するメッセージが出力されている。その結果、時刻「１３：０１」の時点では、制御テーブル１１４に、管理番号「ｉｎｃ０００３」のレコードが登録されている。

時刻「１３：０３」までに、管理番号「ｉｎｃ０００３」の監視中条件である「条件Ｅ」に合致するメッセージが出力されていない。「パターン２」では、「条件Ｅ」に合致するメッセージが発生しないことが成立条件となっているため、終点の条件が満たされたこととなる。その結果、時刻「１３：０４」の時点では、制御テーブル１１４の管理番号「ｉｎｃ０００３」のレコードの監視中条件には、監視終了を示す情報「ｅｎｄ」が設定されている。

時刻「１４：１０」に、「パターン２」の監視起点である「条件Ｄ」に合致するメッセージが出力されている。その結果、時刻「１４：１１」の時点では、制御テーブル１１４に、管理番号「ｉｎｃ０００４」のレコードが登録されている。

時刻「１４：１２」に、管理番号「ｉｎｃ０００４」の監視中条件である「条件Ｅ」に合致するメッセージが出力されている。「パターン２」では、「条件Ｅ」に合致するメッセージが発生しないことが成立条件となっているため、終点の条件が満たされないこととなる。その結果、時刻「１４：１４」の時点では、制御テーブル１１４の管理番号「ｉｎｃ０００４」のレコードに対応するメッセージ群の監視が終了し、管理番号「ｉｎｃ０００４」のレコードは制御テーブル１１４から削除されている。

なお図１０に示したような制御テーブル１１４の更新処理の詳細は後述する（図１６〜図１９参照）。
次に監視サーバ１００によるメッセージ監視処理について詳細に説明する。

図１１は、監視対象登録処理の手順の一例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］監視対象登録部１３０は、ログファイル１１１に出力されたメッセージを取得する。例えばいずれかのサーバからメッセージが監視サーバ１００に送信されると、ログ収集部１２０がそのメッセージを取得する。ログ収集部１２０は、取得したメッセージにタイムスタンプを付与し、ログファイル１１１に新たなレコードとして書き込む。監視対象登録部１３０は、ログ収集部１２０がメッセージをログファイル１１１に書き込んだとき、そのログファイル１１１から、書き込んだメッセージを含むレコードを取得する。

［ステップＳ１０２］監視対象登録部１３０は、メッセージパターン定義情報１１２に登録されているメッセージパターンのうちの、取得したメッセージが起点であるかどうかを未確認のメッセージパターンを１つ選択する。

［ステップＳ１０３］監視対象登録部１３０は、取得したメッセージが、選択したメッセージパターンの起点に合致するか否かを判断する。例えば監視対象登録部１３０は、メッセージパターン定義情報１１２から、選択したメッセージパターンの項番「１」の条件名を取得する。次に監視対象登録部１３０は、条件詳細情報１１３から、取得した条件名に対応するレコードを抽出し、抽出したレコードに示される条件と取得したメッセージとを比較する。例えば監視対象登録部１３０は、取得したメッセージの出力元とメッセージの内容とが合致するか否かを確認する。出力元の確認では、監視対象登録部１３０は、取得したメッセージが、抽出したレコードに示される対象サーバ内の該レコードに示されるログファイル名のログファイルから取得したメッセージであることを確認する。内容の確認では、監視対象登録部１３０は、取得したメッセージが、抽出したレコードに示すｇｒｅｐ文字列による検索に合致する文字列を含んでいることを確認する。監視対象登録部１３０は、出力元と内容との両方が合致した場合、取得したメッセージが、選択したメッセージパターンの起点に合致すると判断する。

監視対象登録部１３０は、取得したメッセージが起点に合致する場合、処理をステップＳ１０４に進める。また監視対象登録部１３０は、取得したメッセージが起点に合致しない場合、処理をステップＳ１０５に進める。

［ステップＳ１０４］監視対象登録部１３０は、選択したメッセージパターンを照合対象として、監視対象のメッセージ群を管理するための管理情報の追加処理を行う。この処理の詳細は後述する（図１２参照）。

［ステップＳ１０５］監視対象登録部１３０は、メッセージパターン定義情報１１２に未確認のメッセージパターンがあるか否かを判断する。監視対象登録部１３０は、未確認のメッセージパターンがある場合、処理をステップＳ１０２に進める。また監視対象登録部１３０は、未確認のメッセージパターンがない場合、監視対象登録処理を終了する。

このようにして、取得したメッセージを起点とするメッセージパターンがある場合、対応する管理情報の追加処理が行われる。なお取得したメッセージを起点とするメッセージパターンが複数ある場合、複数の管理情報についての追加処理が行われる。

図１２は、管理情報追加処理の手順の一例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］監視対象登録部１３０は、メッセージパターンが合致するか否かの監視対象とするメッセージ群を一意に識別する番号を、管理番号として採番する。

［ステップＳ１１２］監視対象登録部１３０は、次の監視の期限を決定する。例えば監視対象登録部１３０は、現在の日時に、照合対象のメッセージパターンの起点の条件の待ち時間を加算した日時を、監視の期限とする。

［ステップＳ１１３］監視対象登録部１３０は、制御テーブル１１４に、監視対象のメッセージ群の管理情報を示すレコードを追加する。例えば監視対象登録部１３０は、追加するレコードに、ステップＳ１１１で採番した管理番号、照合対象のメッセージパターンの定義名、そのメッセージパターンの起点の条件名、およびステップＳ１１２で決定した日時を設定する。

［ステップＳ１１４］監視対象登録部１３０は、監視対象のメッセージ群を記録する個別ログファイルを生成する。たとえば監視対象登録部１３０は、ステップＳ１１１に採番した管理番号を付与した個別ログファイルを生成し、その個別ログファイルにステップＳ１０１で取得したメッセージを含むレコードを書き込む。

このようにして、監視対象のメッセージ群に対応する管理情報の追加と、そのメッセージ群を登録する個別ログファイルが生成される。そして監視部１４０により、管理情報に基づいて、監視対象のメッセージ群が、照合対象のメッセージパターンの成立条件を満たすか否かが監視される。

図１３は、監視処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］監視部１４０は、ログファイル１１１に出力されたメッセージを取得する。

［ステップＳ１２２］監視部１４０は、制御テーブル１１４に登録されている監視対象のメッセージ群の管理情報のうち、未選択の管理情報を１つ選択する。
［ステップＳ１２３］監視部１４０は、現在の日時が、選択した管理情報に示されている期限を過ぎているか否かを判断する。監視部１４０は、期限を過ぎている場合、処理をステップＳ１２４に進める。また監視部１４０は、期限を過ぎていない場合、処理をステップＳ１２７に進める。

［ステップＳ１２４］監視部１４０は、照合対象のメッセージパターンにおける監視中条件の発生の有無が「する」か否かを判断する。監視部１４０は、発生の有無が「する」の場合、処理をステップＳ１２５に進める。また監視部１４０は、発生の有無が「しない」の場合、処理をステップＳ１２６に進める。

［ステップＳ１２５］監視部１４０は、監視解除処理を行う。監視解除処理の詳細は後述する（図１４参照）。その後、監視部１４０は、処理をステップＳ１３１に進める。
［ステップＳ１２６］監視部１４０は、監視対象更新処理を行う。監視対象更新処理の詳細は後述する（図１５参照）。その後、監視部１４０は、処理をステップＳ１３１に進める。

［ステップＳ１２７］監視部１４０は、取得したメッセージが、照合対象のメッセージパターンにおける監視中条件に合致するか否かを判断する。例えば監視部１４０は、選択した管理情報の監視中条件の条件名に基づいて、条件詳細情報１１３から、その条件名に対応する条件の詳細を取得する。監視部１４０は、取得した条件と、取得したメッセージとを照合し、合致するか否かを判断する。監視部１４０は、監視中条件に合致した場合、処理をステップＳ１２８に進める。また監視部１４０は、監視中条件に合致しなければ、処理をステップＳ１３１に進める。

［ステップＳ１２９］監視部１４０は、監視対象更新処理を行う。監視対象更新処理の詳細は後述する（図１５参照）。その後、監視部１４０は、処理をステップＳ１３１に進める。

［ステップＳ１３０］監視部１４０は、監視解除処理を行う。監視解除処理の詳細は後述する（図１４参照）。その後、監視部１４０は、処理をステップＳ１３１に進める。
［ステップＳ１３１］監視部１４０は、制御テーブル１１４に登録されている監視対象のメッセージ群の管理情報のうち、未確認の管理情報があるか否かを判断する。監視部１４０は、未確認の管理情報があれば、処理をステップＳ１２２に進める。また監視部１４０は、すべての管理情報について確認が完了した場合、監視処理を終了する。

このようにして、メッセージを取得すると、そのメッセージに関連する管理情報の監視解除処理または監視対象更新処理が行われる。
次に、監視解除処理について詳細に説明する。

図１４は、監視解除処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］監視部１４０は、制御テーブル１１４から、ステップＳ１２２で選択した管理情報を示すレコードを削除する。

［ステップＳ１４２］監視部１４０は、削除した管理情報に対応する個別ログファイルを削除する。例えば監視部１４０は、管理情報を削除する前に、ステップＳ１２２で選択した管理情報の管理番号を取得する。次に監視部１４０は、取得した管理番号が付与された個別ログファイルを、記憶部１１０から削除する。

次に、監視対象更新処理について詳細に説明する。
図１５は、監視対象更新処理の手順の一例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ１５１］監視部１４０は、選択した管理情報の次の期限を計算する。例えば監視部１４０は、メッセージパターン定義情報１１２から、選択した管理情報における照合対象のメッセージパターンの現在の監視中条件の待ち時間を取得する。監視部１４０は、現在の日時に、取得した待ち時間を加算する。そして監視部１４０は、加算結果で示される日時を、次の期限に決定する。

［ステップＳ１５２］監視部１４０は、選択した管理情報の監視中条件が、照合対象のメッセージパターンの終点か否かを判断する。例えば監視部１４０は、メッセージパターン定義情報１１２から、選択した管理情報における照合対象のメッセージパターンの現在の監視中条件が、そのメッセージパターン中の最後の条件であれば、監視中条件が終点であると判断する。監視部１４０は、監視中条件が終点であれば、処理をステップＳ１５４に進める。また監視部１４０は、監視中条件が終点でなければ、処理をステップＳ１５３に進める。

［ステップＳ１５３］監視部１４０は、選択した管理情報の監視中条件と期限とを更新する。例えば監視部１４０は、メッセージパターン定義情報１１２から、選択した管理情報の照合対象のメッセージパターンにおいて、現在の監視中条件の次の項番の条件名を取得する。監視部１４０は、取得した条件名を、選択した管理情報の監視中条件として、その管理情報のレコードに設定する。また監視部１４０は、ステップＳ１５１で計算した期限を、選択した管理情報の監視中条件の期限として、その管理情報のレコードに設定する。その後、監視部１４０は、処理をステップＳ１５５に進める。

［ステップＳ１５４］監視部１４０は、選択した管理情報の監視中条件に、終了（ｅｎｄ）を設定する。
［ステップＳ１５５］監視部１４０は、選択した管理情報に対応する個別ログファイルに、取得したメッセージを出力する。例えば監視部１４０は、選択した管理情報の管理番号を取得する。そして監視部１４０は、取得した管理番号が付与された個別ログファイルに、ステップＳ１２１で取得したメッセージを示すレコードを追加登録する。

このような処理によって、各メッセージパターンに一致する時系列のメッセージ群が検出され、個別ログファイルに格納される。
メッセージパターンを大別すると、特定のメッセージが発生しないことを条件に含むものと、そのような条件を含まないものとがある。図７の例では、定義名「パターン１」のメッセージパターンは、すべての条件について、発生の有無が「する」となっている。それに対して、定義名「パターン２」のメッセージパターンは、条件「条件Ｅ」について、発生の有無が「しない」となっている。以下、特定のメッセージが発生しないことを条件に含む場合と含まない場合とのそれぞれについて、受信したメッセージとメッセージパターンとの照合例を具体的に説明する。

図１６は、メッセージパターンの第１の照合例を示す図である。図１６には、定義名「パターン１」の定義情報によって定義されたメッセージパターンと、受信したメッセージとの照合例とを示している。

監視サーバ１００は、まず時刻「１０：５１」に、条件「条件Ａ」に合致するメッセージを取得している。条件「条件Ａ」は、定義名「パターン１」のメッセージパターンにおける起点である。そこで監視部１４０は、定義名「パターン１」のメッセージパターンと一致するメッセージ群が出力されるか否かを監視するための管理情報を、制御テーブル１１４に登録する。具体的には監視部１４０は、制御テーブル１１４に、新たな管理番号「ｉｎｃ０００１」を付与したレコードを、管理情報として追加する。監視部１４０は、追加した管理情報の照合対象パターンの欄に、照合対称とするメッセージパターンの定義名「パターン１」を設定する。また監視部１４０は、追加した管理情報の監視中条件に、「パターン１」において合致した条件「条件Ａ」の次の条件「条件Ｂ」を設定する。さらに監視部１４０は、追加した管理情報の期限に、現在の日時「１０：５１」に、合致した条件「条件Ａ」の待ち時間「４：００」を加算した日時「２０１６／６／８ １０：５５」を設定する。

また条件「条件Ａ」に合致するメッセージの取得を検知すると、監視部１４０は、そのメッセージを含む新たな個別ログファイル１５１ａを生成する。そして監視部１４０は、生成した個別ログファイル１５１ａを、記憶部１１０に格納する。

次に監視サーバ１００は、時刻「１０：５３」に、条件名「条件Ｂ」の条件に合致するメッセージを取得している。すると監視部１４０は、管理番号「ｉｎｃ０００１」のレコードの監視中条件に、「パターン１」において合致した条件「条件Ｂ」の次の条件「条件Ｃ」を設定する。さらに監視部１４０は、管理番号「ｉｎｃ０００１」のレコードの期限を、現在の日時「１０：５３」に、合致した条件「条件Ｂ」の待ち時間「１０：００」を加算した日時「２０１６／６／８ １１：０３」を設定する。

また条件「条件Ｂ」に合致するメッセージの取得を検知すると、監視部１４０は、そのメッセージを個別ログファイル１５１ａに追加する。
次に監視サーバ１００は、時刻「１１：０２」に、条件「条件Ｃ」に合致するメッセージを取得している。条件「条件Ｃ」は、定義名「パターン１」のメッセージパターンの終点の条件である。そこで監視部１４０は、管理番号「ｉｎｃ０００１」の管理情報の監視中条件に、監視終了を示す情報「ｅｎｄ」を設定する。さらに監視部１４０は、管理番号「ｉｎｃ０００１」のレコードの期限を、現在の日時「１１：０２」に、合致した条件「条件Ｃ」の待ち時間「００：００」を加算した日時「２０１６／６／８ １１：０２」を設定する。

また条件「条件Ｃ」に合致するメッセージの取得を検知すると、監視部１４０は、そのメッセージを個別ログファイル１５１ａに追加する。
このようにして、制御テーブル１１４に、定義名「パターン１」のメッセージパターンに一致するメッセージ群が出力されたことを示す管理情報が記録される。そして、定義名「パターン１」のメッセージパターンに一致するメッセージ群が、個別ログファイル１５１ａに格納される。

図１７は、メッセージパターンの第２の照合例を示す図である。図１７には、定義名「パターン１」の定義情報によって定義されたメッセージパターンと、受信したメッセージとの照合例とを示している。

監視サーバ１００は、まず時刻「１０：５１」に、条件「条件Ａ」に合致するメッセージを取得している。この場合、監視部１４０は、図１６の例と同様に、定義名「パターン１」のメッセージパターンと一致するメッセージ群が出力されるか否かを監視するための管理情報を、制御テーブル１１４に登録する。また、監視部１４０は、そのメッセージを含む新たな個別ログファイル１５１ｂを生成し、生成した個別ログファイル１５１ｂを記憶部１１０に格納する。

その後、監視サーバ１００は、管理情報の期限の日時「２０１６／６／８ １０：５５」を過ぎた時刻「１０：５６」まで、条件「条件Ｂ」に合致するメッセージを取得していない。この場合、監視部１４０は、管理番号「ｉｎｃ０００１」の管理情報を、制御テーブル１１４から削除する。また監視部１４０は、個別ログファイル１５１ｂを記憶部１１０から削除する。

このように、照合対処のメッセージパターンと一致しないことが判明したメッセージ群については、対応する管理情報が削除される。これにより、照合対処のメッセージパターンと一致しないことが判明したメッセージ群は、以後の監視対象から除外される。

図１８は、メッセージパターンの第３の照合例を示す図である。図１８には、定義名「パターン２」の定義情報によって定義されたメッセージパターンと、受信したメッセージとの照合例とを示している。

監視サーバ１００は、まず時刻「１３：００」に、条件「条件Ｄ」に合致するメッセージを取得している。条件「条件Ｄ」は、定義名「パターン２」のメッセージパターンにおける起点である。そこで監視部１４０は、定義名「パターン２」のメッセージパターンと一致するメッセージ群が出力されるか否かを監視するための管理情報を、制御テーブル１１４に登録する。具体的には監視部１４０は、制御テーブル１１４に、新たな管理番号「ｉｎｃ０００２」を付与したレコードを、管理情報として追加する。監視部１４０は、追加した管理情報の照合対象パターンの欄に、照合対称とするメッセージパターンの定義名「パターン２」を設定する。また監視部１４０は、追加した管理情報の監視中条件に、「パターン２」において合致した条件「条件Ｄ」の次の条件「条件Ｅ」を設定する。さらに監視部１４０は、追加した管理情報の期限に、現在の日時「１３：００」に、合致した条件「条件Ｄ」の待ち時間「３：００」を加算した日時「２０１６／６／８ １３：０３」を設定する。

また条件「条件Ｄ」に合致するメッセージの取得を検知すると、監視部１４０は、そのメッセージを含む新たな個別ログファイル１５１ｃを生成する。そして監視部１４０は、生成した個別ログファイル１５１ｃを、記憶部１１０に格納する。

その後、監視サーバ１００は、管理情報の期限の日時「２０１６／６／８ １３：０３」を過ぎた時刻「１３：０４」まで、条件「条件Ｅ」に合致するメッセージを取得していない。メッセージパターン「パターン２」の定義では、条件「条件Ｅ」に合致するメッセージの発生の有無が「しない」となっているため、条件が満たされたこととなる。また条件「条件Ｅ」は、定義名「パターン２」のメッセージパターンの終点の条件である。そのため、監視部１４０は、管理番号「ｉｎｃ０００２」の管理情報の監視中条件に、監視終了を示す情報「ｅｎｄ」を設定する。さらに監視部１４０は、管理番号「ｉｎｃ０００２」のレコードの期限を、現在の日時「１３：０４」に、合致した条件「条件Ｃ」の待ち時間「００：００」を加算した日時「２０１６／６／８ １３：０４」を設定する。

このようにして、制御テーブル１１４に、定義名「パターン２」のメッセージパターンに一致するメッセージ群が出力されたことを示す管理情報が記録される。そして、定義名「パターン２」のメッセージパターンに一致するメッセージ群が、個別ログファイル１５１ｃに格納される。

図１９は、メッセージパターンの第４の照合例を示す図である。図１９には、定義名「パターン２」の定義情報によって定義されたメッセージパターンと、受信したメッセージとの照合例とを示している。

監視サーバ１００は、まず時刻「１３：００」に、条件「条件Ｄ」に合致するメッセージを取得している。この場合、監視部１４０は、図１８の例と同様に、定義名「パターン２」のメッセージパターンと一致するメッセージ群が出力されるか否かを監視するための管理情報を、制御テーブル１１４に登録する。また、監視部１４０は、そのメッセージを含む新たな個別ログファイル１５１ｄを生成し、生成した個別ログファイル１５１ｄを記憶部１１０に格納する。

次に監視サーバ１００は、時刻「１３：０２」に、条件名「条件Ｅ」の条件に合致するメッセージを取得している。メッセージパターン「パターン２」の定義では、条件「条件Ｅ」に合致するメッセージの発生の有無が「しない」となっているため、条件を満たさなかったこととなる。この場合、監視部１４０は、管理番号「ｉｎｃ０００２」の管理情報を、制御テーブル１１４から削除する。また監視部１４０は、個別ログファイル１５１ｄを記憶部１１０から削除する。

このように、照合対処のメッセージパターンと一致しないことが判明したメッセージ群については、対応する管理情報の削除により、以後の監視対象から除外される。
システム管理者は、監視中条件が「ｅｎｄ」となっている管理情報に対応する個別ログファイル１５１ａ，１５１ｃを参照することで、メッセージパターン定義情報１１２に示されたメッセージパターンに合致するメッセージ群の詳細な内容を確認することができる。

図２０は、個別ログファイルの一例を示す図である。図２０には、定義名「パターン１」のメッセージパターンに一致するメッセージ群が格納された個別ログファイル１５１ａの具体例が示されている。

個別ログファイル１５１ａは、ファイル名「ｉｎｃ０００１．ｌｏｇ」によって対応する管理番号が示されている。個別ログファイル１５１ａには、定義名「パターン１」のメッセージパターンに示されている各条件に合致したメッセージが、該当メッセージの取得ごとに格納されている。各メッセージには、監視サーバ１００で付与したタイムスタンプ、出力元のサーバのサーバ名、および出力元のログファイル名が含まれる。そして、定義名「パターン１」のメッセージパターンに示されている各条件に合致したメッセージを含む個別ログファイル１５１ａの内容がモニタ２１に表示される。

例えば表示制御部１５０は、システム管理者から、メッセージパターンと一致するメッセージ群の表示要求を受け取ると、監視中条件が「ｅｎｄ」となっている管理情報に対応する個別ログファイルの内容を、モニタ２１に表示する。また表示制御部１５０は、制御テーブル１１４を監視し、いずれかの管理情報の監視中条件に「ｅｎｄ」と設定されたことを検出したときに、その管理情報に対応する個別ログファイルの内容を、モニタ２１に表示することもできる。

システム管理者は、表示された個別ログファイル１５１ａの内容を参照し、発生したトラブルの詳細を確認することができる。このような確認作業は、すべてのメッセージを記録したログファイル１１１の内容を確認して、トラブルの原因を調査する場合に比べて、極めて容易である。しかも、メッセージパターンと一致しなかったメッセージ群を格納した個別ログファイルは、記憶部１１０から削除されるため、システム管理者は、確認すべき個別ログファイル１５１ａを容易に見つけ出すことができる。

〔その他の実施の形態〕
第２の実施の形態では、監視サーバ１００において、取得したメッセージにタイムスタンプを付与しているが、各サーバ３１，３２，・・・がメッセージに付与したタイムスタンプが正確である場合、監視サーバ１００はタイムスタンプを付与しなくてもよい。例えばサーバ３１，３２，・・・それぞれの内部時計の時刻合わせが定期的に行われている場合、サーバ３１，３２，・・・が付与したタイムスタンプの日時を信用することができる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１〜３ サーバ
１ａ，２ａ，３ａ ソフトウェア
４ａ〜４ｃ，５ａ〜５ｃ，６ａ〜６ｃ メッセージ
１０ 情報処理装置
１１ 記憶部
１２ 処理部
１３ 表示部

Claims (6)

1. コンピュータに、
   複数のソフトウェアそれぞれの実行により出力された複数のメッセージを取得し、
   メッセージの出力順を示すメッセージパターンを記憶する記憶部を参照して、取得した前記複数のメッセージに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、前記記憶部に記憶された前記メッセージパターンに対応する組を特定し、
   特定した前記組に含まれるメッセージの識別情報を表示部に表示する、
   処理をコンピュータに実行させる判定プログラム。
2. 前記メッセージパターンには、時系列で連続するメッセージ間の最大の時間間隔が示されており、
   前記メッセージパターンに対応する組の特定では、取得した前記複数のメッセージに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力順が前記メッセージパターン通りであり、時系列上で連続して出力されたメッセージ間の時間間隔が前記メッセージパターンに示す最大の時間間隔以下の組を特定する、
   請求項１記載の判定プログラム。
3. 前記複数のメッセージの取得では、複数のソフトウェアそれぞれの実行によりメッセージが出力されるごとに、出力されたメッセージを取得し、
   前記コンピュータに、さらに、取得した前記複数のメッセージそれぞれに、取得日時を示す日時情報を付与する処理を実行させる、
   請求項１または２記載の判定プログラム。
4. 前記メッセージパターンには、第１メッセージの出力後の所定期間内に第２メッセージが出力されないことが定義されており、
   前記メッセージパターンに対応する組の特定では、前記第１メッセージを取得した場合、取得した前記第１メッセージの出力後の前記所定期間内に前記第２メッセージが出力されたか否かを確認し、前記所定期間内に前記第２メッセージが出力されていない場合、取得した前記第１メッセージを含み、前記メッセージパターンに対応する組を特定する、
   請求項１ないし３のいずれかに記載の判定プログラム。
5. コンピュータが、
   複数のソフトウェアそれぞれの実行により出力された複数のメッセージを取得し、
   メッセージの出力順を示すメッセージパターンを記憶する記憶部を参照して、取得した前記複数のメッセージに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、前記記憶部に記憶された前記メッセージパターンに対応する組を特定し、
   特定した前記組に含まれるメッセージの識別情報を表示部に表示する、
   判定方法。
6. メッセージの出力順を示すメッセージパターンを記憶する記憶部と、
   複数のソフトウェアそれぞれの実行により出力された複数のメッセージを取得し、前記記憶部を参照して、取得した前記複数のメッセージに含まれるメッセージの組のうち、組に含まれる複数のメッセージの出力状況が、前記記憶部に記憶された前記メッセージパターンに対応する組を特定し、特定した前記組に含まれるメッセージの識別情報を表示部に表示する処理部と、
   を有する情報処理装置。
   

Images