ホーム > 特許ランキング > 日鉄ソリューションズ株式会社
知財求人 - 知財ポータルサイト「IP Force」
特許7263206情報処理システム、情報処理システムの制御方法、情報処理装置、及びプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-14
(45)【発行日】2023-04-24
(54)【発明の名称】情報処理システム、情報処理システムの制御方法、情報処理装置、及びプログラム
(51)【国際特許分類】
H04L 43/00 20220101AFI20230417BHJP
【ＦＩ】
H04L43/00
【請求項の数】
10
(21)【出願番号】P 2019192939
(22)【出願日】2019-10-23
(65)【公開番号】P2021069009
(43)【公開日】2021-04-30
【審査請求日】2022-01-11
(73)【特許権者】
【識別番号】000191076
【氏名又は名称】日鉄ソリューションズ株式会社
(74)【代理人】
【識別番号】100117857
【弁理士】
【氏名又は名称】南林 薫
(72)【発明者】
【氏名】岡本 周
(72)【発明者】
【氏名】小野寺 大地
【審査官】大石 博見
(56)【参考文献】
【文献】特開２０１８－１０６４９２（ＪＰ，Ａ）
【文献】特開２０１０－０９７４１７（ＪＰ，Ａ）
【文献】特開２０１５－１９１３２７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ４３／００
(57)【特許請求の範囲】
【請求項1】
互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する取得手段と、前記複数の監視手段のうち少なくとも１以上の監視手段から取得された前記メッセージに基づきイベントデータを生成する生成手段と、
所定の文字列を含む前記イベントデータを抽出する抽出手段と、
前記イベントデータの抽出結果に応じた出力情報の出力を制御する出力制御手段と、
を備え、
前記出力制御手段は、前記抽出手段により抽出された前記イベントデータに含まれる前記文字列に基づき関連性を有することが推定される２以上のイベントデータの組み合わせに基づき判定された正常または異常の出力情報を出力する、
情報処理システム。
【請求項2】
前記複数の監視手段のうちの第１の監視手段は、監視対象の性能に関する第１の監視条件に基づき状態の監視を行い、前記取得手段は、前記第１の監視条件に基づく監視の結果に応じて、第１のメッセージを取得する、
請求項１に記載の情報処理システム。
【請求項3】
前記複数の監視手段のうちの第２の監視手段は、監視対象において逐次記録される履歴に関する第２の監視条件に基づき状態の監視を行い、前記取得手段は、前記第２の監視条件に基づく監視の結果に応じて、第２のメッセージを取得する、
請求項１または２に記載の情報処理システム。
【請求項4】
前記生成手段は、前記監視手段から取得された前記メッセージから、当該監視手段に対応付けられた第１のフォーマットに基づき所定の種別の情報を抽出し、抽出された当該情報に基づき前記イベントデータを生成する、請求項１～３のいずれか１項に記載の情報処理システム。
【請求項5】
前記生成手段は、前記メッセージから抽出された前記所定の種別の情報を、第２のフォーマットに適用することで、前記イベントデータを生成する、請求項４に記載の情報処理システム。
【請求項6】
前記抽出手段は、前記第２のフォーマットに基づき前記イベントデータを抽出する、請求項５に記載の情報処理システム。
【請求項7】
前記複数の監視手段のうち少なくとも一部の監視手段を備える、請求項１～６のいずれか１項に記載の情報処理システム。
【請求項8】
情報処理システムの制御方法であって、互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する取得ステップと、
前記複数の監視手段のうち少なくとも２以上の監視手段から取得された前記メッセージを関連付けてイベントデータを生成する生成ステップと、
所定の文字列を含む前記イベントデータを抽出する抽出ステップと、
前記イベントデータの抽出結果に応じた出力情報の出力を制御する出力制御ステップと、
を含み、
前記出力制御ステップは、前記抽出ステップにおいて抽出された前記イベントデータに含まれる前記文字列に基づき関連性を有することが推定される２以上のイベントデータの組み合わせに基づき判定された正常または異常の出力情報を出力する、
情報処理システムの制御方法。
【請求項9】
互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する取得手段と、前記複数の監視手段のうち少なくとも１以上の監視手段から取得された前記メッセージに基づきイベントデータを生成する生成手段と、
所定の文字列を含む前記イベントデータを抽出する抽出手段と、
前記イベントデータの抽出結果に応じた出力情報の出力を制御する出力制御手段と、
を備え、
前記出力制御手段は、前記抽出手段により抽出された前記イベントデータに含まれる前記文字列に基づき関連性を有することが推定される２以上のイベントデータの組み合わせに基づき判定された正常または異常の出力情報を出力する、
情報処理装置。
【請求項10】
コンピュータに、互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する取得ステップと、
前記複数の監視手段のうち少なくとも１以上の監視手段から取得された前記メッセージに基づきイベントデータを生成するステップと、
所定の文字列を含む前記イベントデータを抽出する抽出ステップと、
前記イベントデータの抽出結果に応じた出力情報の出力を制御する出力制御ステップと、
を実行させ、
前記出力制御ステップは、前記抽出ステップにおいて抽出された前記イベントデータに含まれる前記文字列に基づき関連性を有することが推定される２以上のイベントデータの組み合わせに基づき判定された正常または異常の出力情報を出力する、
プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報処理システム、情報処理システムの制御方法、情報処理装置、及びプログラムに関する。
【背景技術】
【0002】
システムやコンピュータの状態の監視に各種監視ツールが利用される場合がある。このような監視ツールは、例えば、サーバ、ネットワーク、アプリケーション等のような監視対象の状態を監視し、異常と推測される事象の発生を検知すると、メッセージの出力等によりユーザ（例えば、管理者等）に対して情報の報知を行う。これにより、ユーザは、異常の発生を認識して、当該異常に対して迅速に対応を行うことが可能となる。例えば、特許文献１には、システムやコンピュータの状態の監視に係る技術の一例が開示されている。
【0003】
特に、近年では、所謂クラウドシステム等のような、従来に比べてより規模の大きいシステムが導入されるケースもあり、監視ツールを利用することでシステムの管理に係るユーザの負担をより軽減する技術が注目されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開２００２－２５２６１４号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、近年では、監視ツールとしては多様なものが提案されており、これらの中には、監視対象（例えば、サーバ、ネットワーク、アプリケーション等）や監視方法の異なる監視ツールも含まれている。そのため、監視ツールごとに、監視対象の種別や監視に係る条件（例えば、制約）等に応じて、監視対象の状態の監視に係る機能や性能が異なる場合もある。
【0006】
特に、規模の大きいシステムにおいては、より多くのサーバ、ネットワーク、及びアプリケーション等が連携して動作することで相互に影響を及ぼすような場合もある。このような状況下では、監視対象の種別や監視に係る条件等に応じた監視ツールごとの機能差や性能差の影響がより顕著に顕在化する場合もある。このような背景から、複数の監視手段（例えば、監視ツール）を利用した監視対象の状態の監視を可能とする技術の実現が求められている。
【0007】
そこで、本開示では、複数の監視手段を利用した監視対象の状態の監視をより好適な態様で実現可能とする技術を提案する。
【課題を解決するための手段】
【0008】
本発明に係る情報処理システムは、互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する取得手段と、前記複数の監視手段のうち少なくとも１以上の監視手段から取得された前記メッセージに基づきイベントデータを生成する生成手段と、所定の文字列を含む前記イベントデータを抽出する抽出手段と、前記イベントデータの抽出結果に応じた出力情報の出力を制御する出力制御手段と、を備え、前記出力制御手段は、前記抽出手段により抽出された前記イベントデータに含まれる前記文字列に基づき関連性を有することが推定される２以上のイベントデータの組み合わせに基づき判定された正常または異常の出力情報を出力する。
【発明の効果】
【0009】
複数の監視手段を利用した監視対象の状態の監視をより好適な態様で実現することが可能となる。
【図面の簡単な説明】
【0010】
【発明を実施するための形態】
【0011】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0012】
＜概要＞
まず、本実施形態に係る監視システムの概要について説明する。なお、以降の説明では、本実施形態に係る監視システムを、他のシステムと区別するために、便宜上「監視システム１００」とも称する。監視システム１００は、複数の監視部（例えば、監視ツール）を利用して、監視対象となるシステムの状態を監視し、当該監視の結果に応じた情報を所定の出力先に出力する。なお、本開示では、監視対象となるシステムは、複数の装置により実現されるシステムであってもよく、１つの装置により実現されるシステムであってよいものとする。
まず、本実施形態に係る監視システムの概要について説明する。なお、以降の説明では、本実施形態に係る監視システムを、他のシステムと区別するために、便宜上「監視システム１００」とも称する。監視システム１００は、複数の監視部（例えば、監視ツール）を利用して、監視対象となるシステムの状態を監視し、当該監視の結果に応じた情報を所定の出力先に出力する。なお、本開示では、監視対象となるシステムは、複数の装置により実現されるシステムであってもよく、１つの装置により実現されるシステムであってよいものとする。
【0013】
監視システム１００が利用する複数の監視部には、互いに異なる監視条件に基づき所望の監視対象の状態を監視する２以上の監視部が含まれてもよい。具体的な一例として、監視システム１００は、監視対象の種別や監視方法が互いに異なる２以上の監視部を利用することで、所望の監視対象の状態の監視を行ってもよい。
また、監視部として既存のものが利用されてもよい。具体的な一例として、監視システム１００は、複数の監視部のうちの少なくとも一部として、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）として公開されている監視ツールを利用してもよい。
また、監視部として既存のものが利用されてもよい。具体的な一例として、監視システム１００は、複数の監視部のうちの少なくとも一部として、ＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）として公開されている監視ツールを利用してもよい。
【0014】
監視システム１００は、複数の監視部それぞれによる監視結果を組み合わせることで、監視対象となるシステムの状態を推定することも可能である。これにより、個々の監視部による監視結果のみでは推定することが困難な状態を推定することが可能となる。
【0015】
具体的な一例として、監視部Ａが、監視結果に応じて、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の負荷が閾値以上となったことを示すメッセージが出力したものとする。この監視結果のみでは、システムに対して何らかの異常が発生したことで、ＣＰＵの負荷が増大しているものと推測される可能性がある。一方で、バックアップジョブ等のように実行が予定されている通常の処理の中には、実行に伴う負荷が比較的大きいものもある。そのため、例えば、監視部Ａが上記メッセージを出力する直前に、他の監視部Ｂが、監視結果に応じて、バックアップジョブ開始のイベントを検出したことを示すメッセージを出力していたものとする。この場合には、監視部Ａ及び監視部Ｂそれぞれから出力されたメッセージに基づき、バックアップジョブの実行に伴いＣＰＵの負荷が増大しているため、監視部Ａの監視結果が正常な動作によるものであると認識することが可能となる。
【0016】
また、他の一例として、監視部Ａが、監視結果に応じて、Ｗｅｂサーバのプロセスが停止したことを示すメッセージを出力したものとする。この監視結果のみでは、システムに対して何らかの異常が発生したことで、Ｗｅｂサーバのプロセスが停止したものと推測される可能性がある。これに対して、例えば、監視部Ａが上記メッセージを出力する直前に、他の監視部Ｂが、監視結果に応じて、クラウドプロバイダにてＷｅｂサーバのスケールインが実施されたことを示すイベントを検出したことを示すメッセージを出力していたものとする。Ｗｅｂサーバのスケールインはリクエスト数の増減にあわせて不定期に発生するが、その際にＷｅｂサーバのプロセスが停止する場合がある。そのため、この場合には、監視部Ａ及び監視部Ｂそれぞれから出力されたメッセージに基づき、Ｗｅｂサーバのスケールインにより当該Ｗｅｂサーバのプロセスが停止しているため、監視部Ａの監視結果が正常な動作によるものであると認識することが可能となる。
【0017】
監視システム１００は、上記に例示したように、複数の監視部それぞれから監視結果に応じて出力される情報（メッセージ）を、所定のフォーマットで規定された、状態検出の対象とする事象ごとのイベントデータを生成する。
なお、メッセージとは、各監視部が監視結果に応じて出力する情報のうち、特に文字情報で表現されたものを示している。また、イベントデータは、監視システム１００が、各監視部から出力されるメッセージに含まれる少なくとも一部の情報を、所望の事象に対応するイベントに対応付けて生成するデータである。
監視システム１００は、イベントデータの生成に際し、複数の情報（メッセージ）を関連付けることで、１つのイベントデータを生成してもよい。また、監視システム１００は、１つのメッセージから複数の情報を抽出し、個々の情報についてイベントデータを生成してもよい。以上のようにして、監視システム１００では、状態検出に係る検出単位ごとにイベントデータが生成されることとなる。
なお、メッセージとは、各監視部が監視結果に応じて出力する情報のうち、特に文字情報で表現されたものを示している。また、イベントデータは、監視システム１００が、各監視部から出力されるメッセージに含まれる少なくとも一部の情報を、所望の事象に対応するイベントに対応付けて生成するデータである。
監視システム１００は、イベントデータの生成に際し、複数の情報（メッセージ）を関連付けることで、１つのイベントデータを生成してもよい。また、監視システム１００は、１つのメッセージから複数の情報を抽出し、個々の情報についてイベントデータを生成してもよい。以上のようにして、監視システム１００では、状態検出に係る検出単位ごとにイベントデータが生成されることとなる。
【0018】
そして、監視システム１００は、生成した一連のイベントデータを、当該イベントデータの生成に係るフォーマットに応じたフィルタに基づき、正常な状態を示すイベントデータと、異常な状態を示すイベントデータと、に振り分ける。これにより、監視部ごとに固有のルール（例えば、フィルタの規定に係るルール等）に依存せずに、一連のイベントデータを所望の条件に基づき振り分けることが可能となる。
また、監視システム１００は、所定の条件に基づき抽出される２以上のイベントデータの組み合わせに基づき、正常及び異常のいずれかを判定してもよい。このような構成により、監視対象の種別や監視に係る条件等に応じて監視ツールごとの機能差や性能差を活かした監視を実施することができ、監視対象の状態をより正確に把握することが可能となる。
また、監視システム１００は、所定の条件に基づき抽出される２以上のイベントデータの組み合わせに基づき、正常及び異常のいずれかを判定してもよい。このような構成により、監視対象の種別や監視に係る条件等に応じて監視ツールごとの機能差や性能差を活かした監視を実施することができ、監視対象の状態をより正確に把握することが可能となる。
【0019】
そこで、以降では、本実施形態に係る監視システム１００について、特に上述した特徴を実現するための機能構成や処理に着目してより詳細に説明する。
【0020】
＜機能構成＞
図１を参照して、本実施形態に係る監視システム１００を含むシステム１の機能構成の一例について説明する。図１は、システム１の機能構成の一例を示したブロック図である。システム１は、１以上の監視対象１９０と、監視システム１００と、を含む。監視システム１００は、システム１のうち、１以上の監視対象１９０それぞれの状態の監視を実現するための構成に相当する。監視対象１９０は、監視システム１００による状態監視の監視対象を模式的に示したものである。なお、システム１のうち、少なくとも監視システム１００に相当する部分が、本実施形態に係る「情報処理システム」の一例に相当する。
図１を参照して、本実施形態に係る監視システム１００を含むシステム１の機能構成の一例について説明する。図１は、システム１の機能構成の一例を示したブロック図である。システム１は、１以上の監視対象１９０と、監視システム１００と、を含む。監視システム１００は、システム１のうち、１以上の監視対象１９０それぞれの状態の監視を実現するための構成に相当する。監視対象１９０は、監視システム１００による状態監視の監視対象を模式的に示したものである。なお、システム１のうち、少なくとも監視システム１００に相当する部分が、本実施形態に係る「情報処理システム」の一例に相当する。
【0021】
本実施形態において、監視システム１００が状態監視の対象とする監視対象１９０は、ハードウェア的な構成であってもよいし、ソフトウェア的な構成であってもよい。ハードウェア的な構成としての監視対象１９０の一例としては、サーバ、ネットワークスイッチ、ストレージ等のようなハードウェアが挙げられる。また、ソフトウェア的な構成としての監視対象１９０の一例として、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ハイパーバイザ、ミドルウェア、データベース、アプリケーション、コンテナ等が挙げられる。また、所謂ネットワークについても、監視対象１９０に含まれ得る。この場合には、物理的なネットワークと、１以上の物理的なネットワークを含むように規定された論理的なネットワークと、のいずれも監視対象１９０に含まれ得る。
また、サーバ等の情報処理装置を監視対象とする場合においても、当該情報処理装置が所謂ヴァーチャルマシンを利用することでソフトウェア的に実現されていてもよい。この場合には、ヴァーチャルマシンを動作させるハードウェアとしての情報処理装置と、ヴァーチャルマシン上でソフトウェア的に動作する情報処理装置と、のいずれも監視対象１９０に含まれ得る。また、このような状況下では、例えば、複数のハードウェア的な情報処理装置を、ソフトウェア的に１つの情報処理装置として見立てて運用するような場合も想定され得る。このような場合においても、複数のハードウェア的な情報処理装置それぞれと、ソフトウェア的に運用される情報処理装置と、のいずれも監視対象１９０に含まれ得る。
また、図１に示す複数の監視対象１９０のそれぞれは、互いに種別の異なる監視対象であってもよい。
また、サーバ等の情報処理装置を監視対象とする場合においても、当該情報処理装置が所謂ヴァーチャルマシンを利用することでソフトウェア的に実現されていてもよい。この場合には、ヴァーチャルマシンを動作させるハードウェアとしての情報処理装置と、ヴァーチャルマシン上でソフトウェア的に動作する情報処理装置と、のいずれも監視対象１９０に含まれ得る。また、このような状況下では、例えば、複数のハードウェア的な情報処理装置を、ソフトウェア的に１つの情報処理装置として見立てて運用するような場合も想定され得る。このような場合においても、複数のハードウェア的な情報処理装置それぞれと、ソフトウェア的に運用される情報処理装置と、のいずれも監視対象１９０に含まれ得る。
また、図１に示す複数の監視対象１９０のそれぞれは、互いに種別の異なる監視対象であってもよい。
【0022】
監視システム１００は、複数の監視部１１０と、イベント生成部１２１と、メッセージ記憶部１２２と、イベント抽出部１２３と、ルール記憶部１２４と、イベント記憶部１２５と、出力制御部１２６と、出力部１２７とを含む。なお、図１に示す例では、複数の監視部１１０として、特徴の異なる監視部１１０ａ及び１１０ｂが含まれるものとする。
【0023】
監視部１１０は、所定の監視条件に基づき１以上の監視対象１９０の状態を監視する。監視部１１０ａ及び１１０ｂは、互いに異なる監視条件に基づき１以上の監視対象１９０の状態を監視してもよい。また、監視部１１０ａ及び１１０ｂのそれぞれは、互いに異なる監視対象１９０（例えば、互いに種別の異なる監視対象１９０）の状態を監視してもよい。
【0024】
具体的な一例として、少なくとも一部の監視部１１０は、監視対象１９０の状態のうち、特に監視対象１９０の性能に関する状態を監視してもよい。性能に関する状態の一例としては、ＣＰＵの使用率、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等のようなワーキングエリアの使用率、補助記憶装置等のような各種データを記憶させる領域の使用率、ネットワークの通信速度等が挙げられる。
また、他の一例として、少なくとも一部の監視部１１０は、監視対象１９０において所定の記憶領域のファイルに逐次記録される履歴を監視することで、当該監視対象１９０の状態を監視してもよい。この場合には、監視部１１０は、例えば、監視対象１９０において所定の種別の履歴が記録されたことを検出した場合に、当該履歴の検出結果に応じて当該監視対象１９０の状態を判定してもよい。
もちろん、上記はあくまで一例であり、必ずしも監視部１１０による監視対象１９０の状態の監視に係る監視条件を限定するものではない。例えば、アプリケーション、コンテナ、ハイパーバイザ、ＯＳ、ハードウェア、及びネットワーク等のいずれの種別の監視対象１９０の状態を監視するかに応じて監視条件が決定されてもよい。また、監視部１１０として利用される監視ツールに応じて監視条件が決定される場合もある。
また、監視部１１０による監視対象１９０の監視方法についても、当該監視対象１９０の種別に応じて適宜変更されてもよい。例えば、監視部１１０は、他の装置を監視する場合には、ネットワークを介して当該装置から各種情報を収集することで、当該情報に基づき当該装置の監視を行ってもよい。
また、他の一例として、少なくとも一部の監視部１１０は、監視対象１９０において所定の記憶領域のファイルに逐次記録される履歴を監視することで、当該監視対象１９０の状態を監視してもよい。この場合には、監視部１１０は、例えば、監視対象１９０において所定の種別の履歴が記録されたことを検出した場合に、当該履歴の検出結果に応じて当該監視対象１９０の状態を判定してもよい。
もちろん、上記はあくまで一例であり、必ずしも監視部１１０による監視対象１９０の状態の監視に係る監視条件を限定するものではない。例えば、アプリケーション、コンテナ、ハイパーバイザ、ＯＳ、ハードウェア、及びネットワーク等のいずれの種別の監視対象１９０の状態を監視するかに応じて監視条件が決定されてもよい。また、監視部１１０として利用される監視ツールに応じて監視条件が決定される場合もある。
また、監視部１１０による監視対象１９０の監視方法についても、当該監視対象１９０の種別に応じて適宜変更されてもよい。例えば、監視部１１０は、他の装置を監視する場合には、ネットワークを介して当該装置から各種情報を収集することで、当該情報に基づき当該装置の監視を行ってもよい。
【0025】
監視部１１０は、監視対象１９０の状態の監視結果に応じた情報を所定の出力先に出力する。なお、以降では、本実施形態に係る監視システム１００の特徴をより分かりやすくするために、監視部１１０は、監視対象１９０の状態の監視結果に応じた情報が文字情報により示されたメッセージを所定の出力先に出力するものとする。
監視部１１０から出力されたメッセージは、後述するイベント生成部１２１により利用される。そのため、例えば、監視部１１０は、上記監視結果に応じたメッセージをイベント生成部１２１に直接出力してもよい。また、他の一例として、監視部１１０は、上記監視結果に応じたメッセージを所定の記憶領域に記憶させてもよい。メッセージ記憶部１２２は、監視部１１０から出力されたメッセージを記憶する記憶領域を示している。この場合には、イベント生成部１２１は、メッセージ記憶部１２２に記憶されたメッセージを抽出して利用してもよい。
監視部１１０から出力されたメッセージは、後述するイベント生成部１２１により利用される。そのため、例えば、監視部１１０は、上記監視結果に応じたメッセージをイベント生成部１２１に直接出力してもよい。また、他の一例として、監視部１１０は、上記監視結果に応じたメッセージを所定の記憶領域に記憶させてもよい。メッセージ記憶部１２２は、監視部１１０から出力されたメッセージを記憶する記憶領域を示している。この場合には、イベント生成部１２１は、メッセージ記憶部１２２に記憶されたメッセージを抽出して利用してもよい。
【0026】
なお、複数の監視部１１０のうち、一部の監視部１１０による監視対象１９０の状態の監視に係る条件が、「第１の監視条件」の一例に相当し、他の一部の監視部１１０による監視対象１９０の状態の監視に係る条件が、「第２の監視条件」の一例に相当する。また、第１の監視条件に基づく監視結果に応じて対応する監視部１１０から出力されるメッセージが、「第１のメッセージ」の一例に相当する。同様に、第２の監視条件に基づく監視結果に応じて対応する監視部１１０から出力されるメッセージが、「第２のメッセージ」の一例に相当する。
より具体的な一例として、監視対象１９０の状態の監視に係る条件のうち、特に、監視対象１９０の性能に関する監視条件が、「第１の監視条件」の一例に相当する。また、監視対象１９０の状態の監視に係る条件のうち、特に、監視対象１９０において逐次記録される履歴に関する監視条件が、「第２の監視条件」の一例に相当する。
なお、第１の監視条件に基づき監視対象１９０の状態を監視する監視部１１０を、便宜上「第１の監視手段」と称する場合がある。同様に、第２の監視条件に基づき監視対象１９０の状態を監視する監視部１１０を、便宜上「第２の監視手段」と称する場合がある。
より具体的な一例として、監視対象１９０の状態の監視に係る条件のうち、特に、監視対象１９０の性能に関する監視条件が、「第１の監視条件」の一例に相当する。また、監視対象１９０の状態の監視に係る条件のうち、特に、監視対象１９０において逐次記録される履歴に関する監視条件が、「第２の監視条件」の一例に相当する。
なお、第１の監視条件に基づき監視対象１９０の状態を監視する監視部１１０を、便宜上「第１の監視手段」と称する場合がある。同様に、第２の監視条件に基づき監視対象１９０の状態を監視する監視部１１０を、便宜上「第２の監視手段」と称する場合がある。
【0027】
イベント生成部１２１は、監視部１１０が監視対象１９０の状態の監視結果に応じて出力するメッセージに基づき、監視システム１００が状態検出の対象とする事象ごとにイベントデータを生成する。例えば、イベント生成部１２１は、個々の監視部１１０が出力するメッセージごとにイベントデータを生成してもよい。また、他の一例として、イベント生成部１２１は、複数のメッセージに基づき１つのイベントデータを生成してもよい。また、イベント生成部１２１は、１つのメッセージに含まれる複数の情報を抽出し、当該情報ごとにイベントデータを生成してもよい。
【0028】
イベント生成部１２１は、イベントデータの生成に際し、メッセージの出力元となる監視部１１０に関わらず、共通のフォーマットを使用する。
一方で、複数の監視部１１０それぞれから出力されるメッセージについては、出力元となる監視部１１０ごとに異なるフォーマットで記載されている場合がある。そのため、イベント生成部１２１は、複数の監視部１１０それぞれから出力されるメッセージを、当該監視部１１０に対応付けられたフォーマットに基づき解析することでメッセージ中の情報を抽出し、抽出した情報に基づきイベントデータを生成してもよい。
また、１つのメッセージに対して複数の事象に関する情報が含まれる場合もある。このような場合には、イベント生成部１２１は、対象となるメッセージを、当該メッセージの出力元となる監視部１１０に対応付けられたフォーマットに基づき解析することで、複数の事象それぞれに対応する情報を個別に抽出することが可能である。この場合には、前述したように、イベント生成部１２１は、抽出した情報それぞれについてイベントデータを生成してもよい。
また、イベント生成部１２１は、複数のメッセージそれぞれから抽出した情報に基づき、当該複数のメッセージ間に関連性があることを推定または認識した場合には、当該複数のメッセージを関連付けて１つのイベントデータを生成してもよい。
なお、各監視部１１０に対応付けられたフォーマットに関する情報については、イベント生成部１２１が参照可能な記憶領域（例えば、後述するルール記憶部１２４）に記憶させておけばよい。また、監視部１１０に対応付けられたフォーマット（すなわち、監視部１１０ごとに固有のフォーマット）が、「第１のフォーマット」の一例に相当する。
一方で、複数の監視部１１０それぞれから出力されるメッセージについては、出力元となる監視部１１０ごとに異なるフォーマットで記載されている場合がある。そのため、イベント生成部１２１は、複数の監視部１１０それぞれから出力されるメッセージを、当該監視部１１０に対応付けられたフォーマットに基づき解析することでメッセージ中の情報を抽出し、抽出した情報に基づきイベントデータを生成してもよい。
また、１つのメッセージに対して複数の事象に関する情報が含まれる場合もある。このような場合には、イベント生成部１２１は、対象となるメッセージを、当該メッセージの出力元となる監視部１１０に対応付けられたフォーマットに基づき解析することで、複数の事象それぞれに対応する情報を個別に抽出することが可能である。この場合には、前述したように、イベント生成部１２１は、抽出した情報それぞれについてイベントデータを生成してもよい。
また、イベント生成部１２１は、複数のメッセージそれぞれから抽出した情報に基づき、当該複数のメッセージ間に関連性があることを推定または認識した場合には、当該複数のメッセージを関連付けて１つのイベントデータを生成してもよい。
なお、各監視部１１０に対応付けられたフォーマットに関する情報については、イベント生成部１２１が参照可能な記憶領域（例えば、後述するルール記憶部１２４）に記憶させておけばよい。また、監視部１１０に対応付けられたフォーマット（すなわち、監視部１１０ごとに固有のフォーマット）が、「第１のフォーマット」の一例に相当する。
【0029】
また、イベント生成部１２１は、複数の監視部１１０それぞれから出力される一連のメッセージのうち、一部のメッセージを抽出してイベントの生成に利用してもよい。換言すると、イベント生成部１２１は、必ずしも複数の監視部１１０それぞれから出力される一連のメッセージ全てについてイベントデータを生成しなくてもよい。この場合には、イベント生成部１２１は、複数の監視部１１０それぞれから出力される一連のメッセージを所定の条件に基づきフィルタリングすることで、イベントの生成に利用するメッセージを抽出してもよい。なお、メッセージの抽出に係る条件については、イベントの生成にメッセージを利用する監視部１１０の種別や、イベントの生成対象となる事象に応じて適宜設定してもよい。
【0030】
なお、イベント生成部１２１によるイベントの生成に係る処理については、具体的な例とあわせて詳細を別途後述する。そして、イベント生成部１２１は、生成したイベントをイベント抽出部１２３に出力する。
【0031】
イベント抽出部１２３は、イベント生成部１２１から生成されたイベントデータを取得する。イベント抽出部１２３は、取得した一連のイベントデータを所定の抽出条件に基づきフィルタリングすることで、少なくとも一部のイベントデータを抽出する。具体的な一例として、イベント抽出部１２３は、生成された一連のイベントデータから、所定の文字列を含むイベントデータを抽出してもよい。イベントデータの抽出に係る抽出条件を示す情報については、イベント抽出部１２３が参照可能な所定の記憶領域にあらかじめ記憶させておけばよい。例えば、ルール記憶部１２４が、上述したイベントデータの抽出に係る抽出条件を示す情報を記憶してもよい。ルール記憶部１２４は、イベント生成部１２１やイベント抽出部１２３が利用する各種情報やデータを記憶する記憶領域である。
【0032】
また、イベント抽出部１２３は、所定の抽出条件に基づき関連性を有することが推定される２以上のイベントデータを関連付けて抽出してもよい。
具体的な一例として、イベント抽出部１２３は、概要として前述した例のように、ＣＰＵの負荷の増加を示すイベントデータと、バックアップジョブ開始のイベントに関するイベントデータとを関連付けてもよい。これにより、個々のイベントデータのみでは監視対象１９０が異常な状態にあると判定されるような状況下においても、相互に関連付けられた複数のイベントデータに基づき、監視対象１９０が正常な状態にあると判定することも可能となる。
具体的な一例として、イベント抽出部１２３は、概要として前述した例のように、ＣＰＵの負荷の増加を示すイベントデータと、バックアップジョブ開始のイベントに関するイベントデータとを関連付けてもよい。これにより、個々のイベントデータのみでは監視対象１９０が異常な状態にあると判定されるような状況下においても、相互に関連付けられた複数のイベントデータに基づき、監視対象１９０が正常な状態にあると判定することも可能となる。
【0033】
なお、イベント抽出部１２３によるイベントデータの抽出に係る処理については、具体的な例とあわせて詳細を別途後述する。そして、イベント抽出部１２３は、抽出したイベントデータをイベント記憶部１２５に記憶させる。例えば、イベント記憶部１２５は、抽出されたイベントデータを記憶するための記憶領域である。
【0034】
出力制御部１２６は、イベント記憶部１２５に記憶されたイベントデータ（すなわち、イベント抽出部１２３により抽出されたイベントデータ）を読み出し、当該イベントデータに応じた情報を所定の出力先に出力する。例えば、出力制御部１２６は、読み出したイベントデータに応じた情報を所定の出力部（例えば、後述する出力部１２７）に出力させることで、ユーザに対して情報の報知を行ってもよい。また、他の一例として、出力制御部１２６は、読み出したイベントデータを、ネットワークを介して他の装置に転送してもよい。これにより、当該他の装置は、取得したイベントデータを利用して各種処理を実行することが可能となる。
また、出力制御部１２６は、イベント記憶部１２５に記憶されたイベントデータの読み出しに際し、所定の条件に応じて少なくとも一部のイベントデータを読み出してもよい。具体的な一例として、出力制御部１２６は、ユーザによる対応をうながす画面の表示のために監視対象１９０の状態として「異常」を示すイベントデータをイベント記憶部１２５から読み出してもよい。
また、出力制御部１２６は、互いに関連付けられた複数のイベントデータを読み出してもよい。この場合には、出力制御部１２６は、当該複数のイベントデータの組み合わせに応じた情報を所定の出力部に出力させてもよい。具体的な一例として、出力制御部１２６は、当該複数のイベントデータの組み合わせに基づく監視対象１９０の状態（例えば、正常または異常）に応じた情報を所定の出力部に出力させてもよい。
また、出力制御部１２６は、イベント記憶部１２５に記憶されたイベントデータの読み出しに際し、所定の条件に応じて少なくとも一部のイベントデータを読み出してもよい。具体的な一例として、出力制御部１２６は、ユーザによる対応をうながす画面の表示のために監視対象１９０の状態として「異常」を示すイベントデータをイベント記憶部１２５から読み出してもよい。
また、出力制御部１２６は、互いに関連付けられた複数のイベントデータを読み出してもよい。この場合には、出力制御部１２６は、当該複数のイベントデータの組み合わせに応じた情報を所定の出力部に出力させてもよい。具体的な一例として、出力制御部１２６は、当該複数のイベントデータの組み合わせに基づく監視対象１９０の状態（例えば、正常または異常）に応じた情報を所定の出力部に出力させてもよい。
【0035】
出力部１２７は、各種情報を出力するための構成であり、ユーザに対する各種情報の提示に利用される。具体的な一例として、出力部１２７は、ディスプレイ等の表示デバイスにより実現されてもよい。この場合には、出力部１２７は、各種表示情報を表示させることで、ユーザに対して情報を提示する。
また、他の一例として、出力部１２７は、音声や電子音等の音響を出力するスピーカ等の音響出力デバイスにより実現されてもよい。この場合には、出力部１２７は、音声や電信等の音響を出力することで、ユーザに対して情報を提示する。
このように、出力部１２７として適用されるデバイスは、ユーザに対して情報を提示するために利用する媒体に応じて適宜変更されてもよい。
また、他の一例として、出力部１２７は、音声や電子音等の音響を出力するスピーカ等の音響出力デバイスにより実現されてもよい。この場合には、出力部１２７は、音声や電信等の音響を出力することで、ユーザに対して情報を提示する。
このように、出力部１２７として適用されるデバイスは、ユーザに対して情報を提示するために利用する媒体に応じて適宜変更されてもよい。
【0036】
なお、図１に示す機能構成はあくまで一例であり、必ずしもシステム１（特に、監視システム１００）の機能構成を限定するものではない。例えば、監視システム１００の各機能構成が１つの装置により実現されてもよい。なお、この場合には、当該１つの装置が、本実施形態に係る「情報処理装置」の一例に相当する。
また、複数の装置を協働させることで、監視システム１００の各機能構成が実現されてもよい。この場合には、例えば、監視システム１００の各機能構成のうち少なくとも一部の機能構成の処理が複数の装置により実行されることで、当該処理に係る負荷が当該複数の装置に分散されてもよい。また、他の一例として、監視システム１００の各機能構成のうち一部の機能構成と他の機能構成とが、ネットワークを介して接続された互いに異なる装置により実現されてもよい。具体的な一例として、イベント生成部１２１及びイベント抽出部１２３に相当する機能構成と、出力制御部１２６に相当する機能構成と、が互いに異なる装置により実現されてもよい。
また、複数の装置を協働させることで、監視システム１００の各機能構成が実現されてもよい。この場合には、例えば、監視システム１００の各機能構成のうち少なくとも一部の機能構成の処理が複数の装置により実行されることで、当該処理に係る負荷が当該複数の装置に分散されてもよい。また、他の一例として、監視システム１００の各機能構成のうち一部の機能構成と他の機能構成とが、ネットワークを介して接続された互いに異なる装置により実現されてもよい。具体的な一例として、イベント生成部１２１及びイベント抽出部１２３に相当する機能構成と、出力制御部１２６に相当する機能構成と、が互いに異なる装置により実現されてもよい。
【0037】
また、監視システム１００の各機能構成のうち一部の機能構成が、監視システム１００の外部に設けられていてもよい。具体的な一例として、複数の監視部１１０のうち少なくとも一部の監視部１１０が、監視システム１００の外部に設けられており、ネットワークを介して監視システム１００に接続されていてもよい。
【0038】
＜ハードウェア構成＞
図２は、本実施形態に係る監視システム１００を実現するために利用される情報処理装置２００のハードウェア構成の一例を示した図である。図２に示すように、本実施形態に係る情報処理装置２００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１０と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２０と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３０とを含む。また、情報処理装置２００は、補助記憶装置２４０と、出力装置２５０と、入力装置２６０と、ネットワークＩ／Ｆ２７０とを含む。ＣＰＵ２１０と、ＲＯＭ２２０と、ＲＡＭ２３０と、補助記憶装置２４０と、出力装置２５０と、入力装置２６０と、ネットワークＩ／Ｆ２７０とは、バス２８０を介して相互に接続されている。
図２は、本実施形態に係る監視システム１００を実現するために利用される情報処理装置２００のハードウェア構成の一例を示した図である。図２に示すように、本実施形態に係る情報処理装置２００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１０と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２０と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３０とを含む。また、情報処理装置２００は、補助記憶装置２４０と、出力装置２５０と、入力装置２６０と、ネットワークＩ／Ｆ２７０とを含む。ＣＰＵ２１０と、ＲＯＭ２２０と、ＲＡＭ２３０と、補助記憶装置２４０と、出力装置２５０と、入力装置２６０と、ネットワークＩ／Ｆ２７０とは、バス２８０を介して相互に接続されている。
【0039】
ＣＰＵ２１０は、情報処理装置２００の各種動作を制御する中央演算装置である。例えば、ＣＰＵ２１０は、情報処理装置２００全体の動作を制御してもよい。ＲＯＭ２２０は、ＣＰＵ２１０で実行可能な制御プログラムやブートプログラムなどを記憶する。ＲＡＭ２３０は、ＣＰＵ２１０の主記憶メモリであり、ワークエリア又は各種プログラムを展開するための一時記憶領域として用いられる。
【0040】
補助記憶装置２４０は、各種データや各種プログラムを記憶する。補助記憶装置２４０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）や、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）に代表される不揮発性メモリ等のような、各種データを一時的または持続的に記憶可能な記憶デバイスにより実現される。
【0041】
出力装置２５０は、各種情報を出力する装置であり、ユーザに対する各種情報の提示に利用される。本実施形態では、出力装置２５０は、ディスプレイ等の表示デバイスにより実現される。出力装置２５０は、各種表示情報を表示させることで、ユーザに対して情報を提示する。ただし、他の例として、出力装置２５０は、音声や電子音等の音を出力する音響出力デバイスにより実現されてもよい。この場合には、出力装置２５０は、音声や電信等の音を出力することで、ユーザに対して情報を提示する。また、出力装置２５０として適用されるデバイスは、ユーザに対して情報を提示するために利用する媒体に応じて適宜変更されてもよい。なお、出力装置２５０が、各種情報の提示に利用される「出力部」の一例に相当する。
【0042】
入力装置２６０は、ユーザからの各種指示の受け付けに利用される。本実施形態では、入力装置２６０は、マウス、キーボード、タッチパネル等の入力デバイスを含む。ただし、他の例として、入力装置２６０は、マイクロフォン等の集音デバイスを含み、ユーザが発話した音声を集音してもよい。この場合には、集音された音声に対して音響解析や自然言語処理等の各種解析処理が施されることで、この音声が示す内容がユーザからの指示として認識される。また、入力装置２６０として適用されるデバイスは、ユーザからの指示を認識する方法に応じて適宜変更されてもよい。また、入力装置２６０として複数種類のデバイスが適用されてもよい。
【0043】
ネットワークＩ／Ｆ２７０は、外部の装置とのネットワークを介した通信に利用される。なお、ネットワークＩ／Ｆ２７０として適用されるデバイスは、通信経路の種別や適用される通信方式に応じて適宜変更されてもよい。
【0044】
ＣＰＵ２１０は、ＲＯＭ２２０又は補助記憶装置２４０に記憶されたプログラムをＲＡＭ２３０に展開し、このプログラムを実行することで、図１に示す監視システム１００の機能構成や、図３に示すフローチャートで示された処理が実現される。
【0045】
【0046】
Ｓ１０１において、イベント生成部１２１は、複数の監視部１１０それぞれから、監視対象１９０の状態の監視結果に応じたメッセージを取得する。
【0047】
Ｓ１０２において、イベント生成部１２１は、各監視部１１０から取得したメッセージに基づき、監視システム１００が状態検出の対象とする事象ごとにイベントデータを生成する。
【0048】
Ｓ１０３において、イベント抽出部１２３は、イベント生成部１２１により生成された一連のイベントデータを所定の抽出条件に基づきフィルタリングすることで、少なくとも一部のイベントデータを抽出する。具体的な一例として、イベント抽出部１２３は、生成された一連のイベントデータから、所定の文字列を含むイベントデータを抽出してもよい。また、イベント抽出部１２３は、所定の抽出条件に基づき関連性を有することが推定される２以上のイベントデータを関連付けて抽出してもよい。
【0049】
Ｓ１０４において、出力制御部１２６は、イベント抽出部１２３により抽出されたイベントデータに応じた情報が所定の出力先に出力されるように制御する。例えば、出力制御部１２６は、イベント抽出部１２３により抽出されたイベントを出力部１２７に出力させることで、ユーザに対して情報の報知を行ってもよい。また、他の一例として、出力制御部１２６は、読み出したイベントデータを、ネットワークを介して他の装置に転送してもよい。
また、出力制御部１２６は、互いに関連付けられた複数のイベントデータを読み出してもよい。この場合には、出力制御部１２６は、当該複数のイベントデータの組み合わせに応じた情報を所定の出力先に出力してもよい。
また、出力制御部１２６は、互いに関連付けられた複数のイベントデータを読み出してもよい。この場合には、出力制御部１２６は、当該複数のイベントデータの組み合わせに応じた情報を所定の出力先に出力してもよい。
【0050】
監視システム１００は、図３に示す一連の処理を、所定の契機ごとに実行する。具体的な一例として、監視システム１００は、所定の期間ごとに定期的に、図３に示す一連の処理を実行してもよい。また、他の一例として、監視システム１００は、所定のトリガに連動して、図３に示す一連の処理を実行してもよい。
【0051】
＜実施例＞
続いて、監視システム１００の実施例として、監視部１１０から出力されるメッセージに基づく、イベントデータの生成及び抽出に係る処理の一例について、具体的な例を挙げて説明する。なお、本実施例では、複数の監視部１１０として、Ｚａｂｂｉｘと称されるＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）の監視ツールと、Ｐｒｏｍｅｔｈｅｕｓと称されるＯＳＳの監視ツールと、が利用される場合の一例について説明する。
続いて、監視システム１００の実施例として、監視部１１０から出力されるメッセージに基づく、イベントデータの生成及び抽出に係る処理の一例について、具体的な例を挙げて説明する。なお、本実施例では、複数の監視部１１０として、Ｚａｂｂｉｘと称されるＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）の監視ツールと、Ｐｒｏｍｅｔｈｅｕｓと称されるＯＳＳの監視ツールと、が利用される場合の一例について説明する。
【0052】
監視システム１００では、複数の監視部１１０それぞれから出力されるメッセージに基づきイベントデータが生成され、当該イベントデータに基づき監視対象１９０の状態の監視が行われる。具体的には、監視システム１００では、所望の監視対象１９０の異常な動作を検出する場合に、上記イベントデータの規定に係るフォーマットに基づき、所望の事象に対応するイベントデータを抽出することが可能である。そのため、監視システム１００に依れば、各監視部１１０が出力するメッセージのフォーマットに依存せずに、所望の事象に対応するイベントデータを抽出することが可能である。
【0053】
（イベントデータの生成）
ここで、各監視部１１０が出力するメッセージのフォーマットに依存せずに、所望の事象に対応するイベントデータの抽出を可能とするための、当該イベントデータの生成に係る処理の一例について具体的な例を挙げて説明する。
ここで、各監視部１１０が出力するメッセージのフォーマットに依存せずに、所望の事象に対応するイベントデータの抽出を可能とするための、当該イベントデータの生成に係る処理の一例について具体的な例を挙げて説明する。
【0054】
Ｚａｂｂｉｘでは、例えば、サーバの再起動を示すメッセージを抽出する場合に、当該抽出に係る条件式を以下のように表現する。
【0055】
【数1】
【0056】
また、Ｐｒｏｍｅｔｈｅｕｓでは、例えば、ＣＰＵ使用率が９０％を超過したことを示すメッセージを抽出する場合に、当該抽出に係る条件式を以下のように表現する。
【0057】
【数2】
【0058】
これらの監視ツールにおいては、特定の条件を満たす場合に異常ではないものとしてメッセージの出力を抑制するためには、例えば、上記に示した監視ツールごとの条件式の記述方法を理解したうえで、制御に係るスクリプト等を記述または修正することとなる。すなわち、監視ツールごとに、当該監視ツールで用いられている項目名や構文の理解がユーザに求められる。そのため、複数の監視ツールが利用される状況下では、ユーザに対して、監視ツールごとに使用されている項目名や構文の理解が求められることとなり、ユーザへの負担が増加する場合がある。
【0059】
これに対して、監視ツール群とは別にフィルタを用いる場合には、監視ツールが出力するメッセージに対してフィルタにより状態判定の条件を追加することが可能である。この場合には、当該条件については、メッセージの構成とフィルタツールの構文とにより記述することが可能であり、この際に、メッセージの出力元となる監視ツールにおける条件式の構文の理解は求められない。
【0060】
例えば、図４は、監視ツールごとに出力されるメッセージの一例を示した図である。
具体的には、図４（ａ）は、サーバの再起動が行われた場合に、Ｚａｂｂｉｘが出力するメッセージの一例を示している。「ｄａｔｅ」は、メッセージが出力された日時を示すタイムスタンプである。「ｈｏｓｔ」は、監視対象となるサーバのホスト名を示している。「ｓｕｂｊｅｃｔ」は、メッセージの種別を示している。「ｍｅｓｓａｇｅ」は、メッセージの本文を示している。「ｓｅｖｅｒｉｔｙ」は、重要度や緊急度の指標を示している。
また、図４（ｂ）は、ＣＰＵ使用率が９０％を超過した場合に、Ｐｒｏｍｅｔｈｅｕｓが出力するメッセージの一例を示している。「ｄａｔｅ」は、メッセージが出力された日時を示すタイムスタンプである。「ｎｏｄｅ」は、監視対象となるサーバのホスト名を示している。「ｓｕｍｍａｒｙ」は、メッセージの種別を示している。「ｓｔａｔｕｓ」は、監視対象の状態を示している。「ｓｅｖｅｒｉｔｙ」は、重要度や緊急度の指標を示している。
具体的には、図４（ａ）は、サーバの再起動が行われた場合に、Ｚａｂｂｉｘが出力するメッセージの一例を示している。「ｄａｔｅ」は、メッセージが出力された日時を示すタイムスタンプである。「ｈｏｓｔ」は、監視対象となるサーバのホスト名を示している。「ｓｕｂｊｅｃｔ」は、メッセージの種別を示している。「ｍｅｓｓａｇｅ」は、メッセージの本文を示している。「ｓｅｖｅｒｉｔｙ」は、重要度や緊急度の指標を示している。
また、図４（ｂ）は、ＣＰＵ使用率が９０％を超過した場合に、Ｐｒｏｍｅｔｈｅｕｓが出力するメッセージの一例を示している。「ｄａｔｅ」は、メッセージが出力された日時を示すタイムスタンプである。「ｎｏｄｅ」は、監視対象となるサーバのホスト名を示している。「ｓｕｍｍａｒｙ」は、メッセージの種別を示している。「ｓｔａｔｕｓ」は、監視対象の状態を示している。「ｓｅｖｅｒｉｔｙ」は、重要度や緊急度の指標を示している。
【0061】
また、図５は、監視ツールが出力するメッセージに対してフィルタにより状態判定の条件を追加する場合のスクリプトの一例を示した図である。具体的には、図５に示す例は、図４に例示したメッセージの出力を前提として、各メッセージが出力された時刻が２３時から２４時の間の場合には、正常な動作と判断する条件を規定したスクリプトの一例を示している。なお、図５はあくまで一例であり、利用するフィルタツールにおける構文に応じて少なくとも一部の記述方法が適宜変更されてもよい。
【0062】
具体的には、図５に示す例では、監視対象となるサーバのホスト名が、各ツールにおける当該ホスト名を示す項目（それぞれ「ｈｏｓｔ」及び「ｎｏｄｅ」）から取得されている。また、メッセージの種別を表す情報（文字列）が、各ツールにおける当該メッセージの種別を示す項目（それぞれ「ｓｕｂｊｅｃｔ」及び「ｓｕｍｍａｒｙ」）から取得されている。以上のようにして取得された情報が所定の条件を満たす場合に、さらに、メッセージが出力された日時を示す情報が、当該日時を示す項目（いずれも「ｄａｔｅ」）から取得される。そのうえで、メッセージが出力された時間が２３時から２４時の間か否かに応じて、正常及び異常のいずれかが判定されている。
なお、図５を参照するとわかるように、項目名やメッセージの内容については監視ツールごとに異なる可能性があるが、条件判定のための条件式については各監視ツールに依存せずに記述することが可能である。
なお、図５を参照するとわかるように、項目名やメッセージの内容については監視ツールごとに異なる可能性があるが、条件判定のための条件式については各監視ツールに依存せずに記述することが可能である。
【0063】
本実施形態に係る監視システム１００では、上述した特性を利用することで、監視ツールごとに固有のルールに依存せずに、各監視ツールが監視結果に応じて出力する情報それぞれを、共通のルールに基づき一元的に管理可能とする。
【0064】
具体的には、イベント生成部１２１は、上述した特性を利用することで、各監視部１１０から出力されるメッセージから所望の情報を抽出し、所定のフォーマットに基づき抽出した情報を利用してイベントデータを生成する。なお、イベントデータの規定に係るフォーマットが、「第２のフォーマット」の一例に相当する。
【0065】
以下にイベントデータの一例について、（Ａ）～（Ｄ）として示す種別ごとに列挙する。
（Ａ）履歴に関するメッセージで何らかの事象が発生したことを表すもの
・バックアップジョブが開始した
・ソフトウェアで特定のエラーが発生した
・ネットワーク機器のポートの接続が切断された
・サーバが再起動した
・クラウドストレージのリソースが追加された
（Ｂ）履歴に関するメッセージでユーザが何らかの操作を行ったことを表すもの
・管理者がサーバにリモートログインした
・管理者がユーザアカウント作成操作を実行した
・利用者がクラウドにネットワーク追加操作を実行した
・利用者がクラウド上のサーバ削除操作を実行した
（Ｃ）性能や状態に関するメッセージで事前に定義した条件に該当したことを表すもの
・ＣＰＵ使用率が９０％を超えた
・Ｗｅｂサーバへの接続が３回連続で失敗した
・バックアップジョブの実行が３時間を超過しても続いている
・プロセスが実行状態から停止状態に変化した
（Ｄ）性能や状態に関するメッセージで現在の状態を表すもの
・サーバが現在停止中である
・プロセスが現在停止状態である
・現在のＣＰＵ使用率が２０％である
・バックアップジョブが実行中である
（Ａ）履歴に関するメッセージで何らかの事象が発生したことを表すもの
・バックアップジョブが開始した
・ソフトウェアで特定のエラーが発生した
・ネットワーク機器のポートの接続が切断された
・サーバが再起動した
・クラウドストレージのリソースが追加された
（Ｂ）履歴に関するメッセージでユーザが何らかの操作を行ったことを表すもの
・管理者がサーバにリモートログインした
・管理者がユーザアカウント作成操作を実行した
・利用者がクラウドにネットワーク追加操作を実行した
・利用者がクラウド上のサーバ削除操作を実行した
（Ｃ）性能や状態に関するメッセージで事前に定義した条件に該当したことを表すもの
・ＣＰＵ使用率が９０％を超えた
・Ｗｅｂサーバへの接続が３回連続で失敗した
・バックアップジョブの実行が３時間を超過しても続いている
・プロセスが実行状態から停止状態に変化した
（Ｄ）性能や状態に関するメッセージで現在の状態を表すもの
・サーバが現在停止中である
・プロセスが現在停止状態である
・現在のＣＰＵ使用率が２０％である
・バックアップジョブが実行中である
【0066】
また、イベント抽出部１２３は、イベントデータの生成に係るフォーマットに応じた所定の抽出条件に基づき、生成された一連のイベントデータから、少なくとも一部のイベントデータを抽出する。
なお、前述したように、イベント抽出部１２３は、所定の抽出条件に基づき関連性を有することが推定される２以上のイベントデータを関連付けて抽出してもよい。このように複数のイベントデータが関連付けられることで、当該複数のイベントデータに基づき、監視対象１９０の状態をより正確に判定することが可能となる。
なお、前述したように、イベント抽出部１２３は、所定の抽出条件に基づき関連性を有することが推定される２以上のイベントデータを関連付けて抽出してもよい。このように複数のイベントデータが関連付けられることで、当該複数のイベントデータに基づき、監視対象１９０の状態をより正確に判定することが可能となる。
【0067】
以下に、イベントデータの抽出に係る条件と、抽出結果に応じたる監視対象１９０の状態の判定と、の一例（換言すると、フィルタの適用例）について、特に２以上のイベントデータを組み合わせて利用する場合に着目して具体的な例を挙げて説明する。なお、以下に示す例では、上述した（Ａ）～（Ｄ）のイベントデータのうち２以上のイベントデータを組み合わせる場合に着目して、対応する監視対象１９０の状態の判定方法の一例について説明する。
【0068】
－フィルタの適用例１
（Ａ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｂ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「ネットワーク機器のポートの接続が切れた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去３分以内に「クラウドでユーザがネットワーク削除操作を行った」ことを示すイベントに対応するイベントデータが生成されている場合には、当該操作に起因してネットワーク機器のポートの接続が切れたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
（Ａ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｂ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「ネットワーク機器のポートの接続が切れた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去３分以内に「クラウドでユーザがネットワーク削除操作を行った」ことを示すイベントに対応するイベントデータが生成されている場合には、当該操作に起因してネットワーク機器のポートの接続が切れたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
【0069】
－フィルタの適用例２
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ａ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「サーバのＣＰＵ使用率が９０％を超えた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去１０分以内に「サーバが再起動された」ことを示すイベントに対応するイベントデータが生成されている場合には、当該再起動に起因してサーバのＣＰＵ使用率が９０％を超えたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ａ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「サーバのＣＰＵ使用率が９０％を超えた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去１０分以内に「サーバが再起動された」ことを示すイベントに対応するイベントデータが生成されている場合には、当該再起動に起因してサーバのＣＰＵ使用率が９０％を超えたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
【0070】
－フィルタの適用例３
（Ａ）として示すイベントデータが「正常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「異常」な状態にあると判定されてもよい。
具体的な一例として、「サーバ上で特定のエラーが発生した」ことを示すイベントに対応するイベントデータは、当該エラーが直ちに影響を及ぼさない場合には「正常」な状態にあると判定することが可能である。一方で、当該サーバが依存している他のサーバについて、直近で「サーバが停止中である」ことを示すイベントに対応するイベントデータが生成されている場合には、上記エラーがシステム全体に影響を及ぼす可能性がある。すなわち、この場合には、監視対象１９０が「異常」な状態にあると判定されてもよい。
（Ａ）として示すイベントデータが「正常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「異常」な状態にあると判定されてもよい。
具体的な一例として、「サーバ上で特定のエラーが発生した」ことを示すイベントに対応するイベントデータは、当該エラーが直ちに影響を及ぼさない場合には「正常」な状態にあると判定することが可能である。一方で、当該サーバが依存している他のサーバについて、直近で「サーバが停止中である」ことを示すイベントに対応するイベントデータが生成されている場合には、上記エラーがシステム全体に影響を及ぼす可能性がある。すなわち、この場合には、監視対象１９０が「異常」な状態にあると判定されてもよい。
【0071】
－フィルタの適用例４
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｂ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「プロセスが起動状態から停止状態に変化した」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去３分以内に「利用者がサーバ追加操作を行った」ことを示すイベントに対応するイベントデータが生成されている場合には、当該サーバ追加操作に起因してプロセスが起動状態から停止状態に変化したものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｂ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「プロセスが起動状態から停止状態に変化した」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、過去３分以内に「利用者がサーバ追加操作を行った」ことを示すイベントに対応するイベントデータが生成されている場合には、当該サーバ追加操作に起因してプロセスが起動状態から停止状態に変化したものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
【0072】
－フィルタの適用例５
（Ｂ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「管理者がＤＢサーバにリモートログインした」ことを示すイベントに対応するイベントデータは、ＤＢサーバへのリモートログインが運用ルール上禁止している場合には、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、直近で「作業用サーバが停止中である」場合に、例外としてＤＢサーバへのリモートログインが運用ルール上許可されている場合もある。このような場合には、直近で「作業用サーバが停止中である」ことを示すイベントに対応するイベントデータが生成されている場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
（Ｂ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「管理者がＤＢサーバにリモートログインした」ことを示すイベントに対応するイベントデータは、ＤＢサーバへのリモートログインが運用ルール上禁止している場合には、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、直近で「作業用サーバが停止中である」場合に、例外としてＤＢサーバへのリモートログインが運用ルール上許可されている場合もある。このような場合には、直近で「作業用サーバが停止中である」ことを示すイベントに対応するイベントデータが生成されている場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
【0073】
－フィルタの適用例６
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「サーバのメモリ使用率が８０％を超えた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、直近で「バックアップジョブが実行中である」ことを示すイベントに対応するイベントデータが生成されている場合には、当該バックアップジョブの実行が起因してサーバのメモリ使用率が８０％を超えたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
（Ｃ）として示すイベントデータが「異常」な状態を示す場合においても、（Ｄ）として示すイベントデータとの組み合わせに応じて「正常」な状態にあると判定されてもよい。
具体的な一例として、「サーバのメモリ使用率が８０％を超えた」ことを示すイベントに対応するイベントデータは、単体では監視対象１９０が「異常」な状態にあることを示している。一方で、直近で「バックアップジョブが実行中である」ことを示すイベントに対応するイベントデータが生成されている場合には、当該バックアップジョブの実行が起因してサーバのメモリ使用率が８０％を超えたものと推定することが可能である。すなわち、この場合には、監視対象１９０が「正常」な状態にあると判定することが可能である。
【0074】
また、あるイベントが発生した場合に、条件判定のために、当該イベントに対応するイベントデータに対して、過去に発生した別のイベントに対応するイベントデータを関連付けるための条件の一例を以下に示す。
・イベントの発生タイミングを基点として、過去の一定期間内に発生した所定の種類のイベントの有無を検索する
・イベントの発生タイミングを基点として、以降の一定期間内に発生した所定の種類のイベントの有無を監視する
・（Ｄ）に示す状態にあることを示すイベントデータのうち最新のものを保持する
・（Ｃ）に示す状態に変化したことを示すイベントデータのうち最新のものを保持する
なお、上記はあくまで一例であり、必ずしも所望のイベントに対応するイベントデータに対して、過去に発生した別のイベントに対応するイベントデータを関連付ける方法を限定するものではない。
・イベントの発生タイミングを基点として、過去の一定期間内に発生した所定の種類のイベントの有無を検索する
・イベントの発生タイミングを基点として、以降の一定期間内に発生した所定の種類のイベントの有無を監視する
・（Ｄ）に示す状態にあることを示すイベントデータのうち最新のものを保持する
・（Ｃ）に示す状態に変化したことを示すイベントデータのうち最新のものを保持する
なお、上記はあくまで一例であり、必ずしも所望のイベントに対応するイベントデータに対して、過去に発生した別のイベントに対応するイベントデータを関連付ける方法を限定するものではない。
【0075】
＜補足＞
実施形態として上述した例はあくまで一例であり、必ずしも監視システム１００を実現するための構成や、当該監視システム１００の処理を限定するものではない。すなわち、上述した技術思想を逸脱しない範囲で、監視システム１００の構成や処理の一部が適宜変更されてもよい。
実施形態として上述した例はあくまで一例であり、必ずしも監視システム１００を実現するための構成や、当該監視システム１００の処理を限定するものではない。すなわち、上述した技術思想を逸脱しない範囲で、監視システム１００の構成や処理の一部が適宜変更されてもよい。
【0076】
例えば、実施形態として上述した例では、監視部１１０から出力される情報として主にメッセージ（文字情報）を想定して、当該メッセージに基づきイベントデータを生成し、当該イベントデータに基づき監視対象１９０の状態を判定する場合に着目して説明した。
一方で、監視部１１０が出力する情報に応じて監視対象１９０の状態を判定することが可能であれば、当該情報の種別は特に限定されず、当該情報に基づきイベントデータを生成して監視対象１９０の状態の判定に利用することが可能である。
一方で、監視部１１０が出力する情報に応じて監視対象１９０の状態を判定することが可能であれば、当該情報の種別は特に限定されず、当該情報に基づきイベントデータを生成して監視対象１９０の状態の判定に利用することが可能である。
【0077】
具体的な一例として、監視部１１０として各種センサが適用されてもよい。この場合には、イベント生成部１２１は、例えば、監視部１１０（センサ）から所定の状態の検知結果に応じて出力される信号に基づき、イベントデータを生成してもよい。より具体的な一例として、イベント生成部１２１は、監視対象１９０の状態に応じて監視部１１０から出力される信号のレベルや位相が変化する場合には、当該信号のレベルや位相が示す当該監視対象１９０の状態に応じたイベントデータを生成すればよい。
【0078】
また、他の一例として、監視部１１０が、監視対象１９０の状態の監視結果に応じたコードを、監視結果に応じた情報として出力してもよい。このような場合においても、イベント生成部１２１は、例えば、各コードがどの状態に対応しているかが既知であれば、上記コードに基づき、監視部１１０による監視結果を特定してイベントデータを生成することが可能である。
【0079】
また、他の一例として、監視部１１０が、監視結果に応じた情報として、監視対象１９０の状態の監視結果を符号化したデータを出力してもよい。このような場合においても、イベント生成部１２１は、例えば、情報の符号化方法が既知であれば、上記符号化後のデータに基づき、監視部１１０による監視結果を特定してイベントデータを生成することが可能である。
具体的な一例として、イベント生成部１２１は、監視対象１９０の状態の監視結果として取得される情報の一覧が既知であれば、これらの情報それぞれを既知の符号化方法に基づき符号化したデータをあらかじめ保持しておいてもよい。そのうえで、イベント生成部１２１は、監視部１１０から監視結果に応じて出力される符号化後のデータを、あらかじめ保持しておいた符号化後のデータそれぞれと照合することで、監視対象１９０の状態を特定してもよい。
また、他の一例として、イベント生成部１２１は、監視部１１０から監視結果に応じて出力される符号化後のデータを、既知の符号化方法に対応する復号方法により復号し、復号後の情報に基づき監視対象１９０の状態を特定してもよい。
これにより、イベント生成部１２１は、監視部１１０から監視結果に応じた情報として符号化後のデータを取得する場合においても、当該監視結果に応じたイベントデータを生成することが可能となる。
具体的な一例として、イベント生成部１２１は、監視対象１９０の状態の監視結果として取得される情報の一覧が既知であれば、これらの情報それぞれを既知の符号化方法に基づき符号化したデータをあらかじめ保持しておいてもよい。そのうえで、イベント生成部１２１は、監視部１１０から監視結果に応じて出力される符号化後のデータを、あらかじめ保持しておいた符号化後のデータそれぞれと照合することで、監視対象１９０の状態を特定してもよい。
また、他の一例として、イベント生成部１２１は、監視部１１０から監視結果に応じて出力される符号化後のデータを、既知の符号化方法に対応する復号方法により復号し、復号後の情報に基づき監視対象１９０の状態を特定してもよい。
これにより、イベント生成部１２１は、監視部１１０から監視結果に応じた情報として符号化後のデータを取得する場合においても、当該監視結果に応じたイベントデータを生成することが可能となる。
【0080】
また、図１に示す例では複数の監視部１１０それぞれにより互いに異なる監視条件に応じた監視対象１９０の状態の監視が行われている。一方で、複数の監視部１１０の役割を１つの装置が担ってもよい。この場合には、当該装置は、互いに異なる監視条件それぞれに基づく監視対象１９０の状態の監視結果に応じた情報をそれぞれ出力すればよい。
【0081】
また、上述した監視システム１００の各機能構成を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することが可能である。記録媒体としては、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等が挙げられる。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信されてもよい。また、上記コンピュータプログラムを実行させるコンピュータの数は特に限定されない。例えば、上記コンピュータプログラムを、複数のコンピュータ（例えば、複数のサーバ等）が互いに連携して実行してもよい。また、他の一例として、上記コンピュータが複数のプロセッサを備える場合には、上記コンピュータプログラムを、この複数のプロセッサが互いに連携して実行してもよい。
【0082】
＜むすび＞
以上説明したように、本実施形態に係る情報処理システム（例えば、監視システム１００）は、互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する。また、上記情報処理システムは、上記複数の監視手段のうち少なくとも１以上の監視手段から取得された上記メッセージに基づきイベントデータを生成する。また、上記情報処理システムは、所定の抽出条件に基づき上記イベントデータを抽出する。そのうえで、上記情報処理システムは、上記イベントデータの抽出結果に応じた出力情報の出力を制御する。
以上説明したように、本実施形態に係る情報処理システム（例えば、監視システム１００）は、互いに異なる監視条件に基づき状態の監視を行う複数の監視手段それぞれから当該監視の結果に応じたメッセージを取得する。また、上記情報処理システムは、上記複数の監視手段のうち少なくとも１以上の監視手段から取得された上記メッセージに基づきイベントデータを生成する。また、上記情報処理システムは、所定の抽出条件に基づき上記イベントデータを抽出する。そのうえで、上記情報処理システムは、上記イベントデータの抽出結果に応じた出力情報の出力を制御する。
【0083】
以上のような構成により、各監視手段が監視結果に応じて出力する情報を、監視手段ごとに固有のルールに依存せずに、共通のルールに基づき一元的に管理することが可能となる。これにより、各監視手段が監視結果に応じて出力する情報に基づく監視対象の状態を、共通のルールにより規定された条件（換言すると、フィルタ）に基づき判定することが可能となる。すなわち、本実施形態に係る情報処理システムに依れば、複数の監視手段を利用した監視対象の状態の監視をより好適な態様で実現することが可能となる。
【0084】
また、上述した特性から、本実施形態に係る情報処理システムでは、互いに異なる複数の監視手段による監視結果を、共通のルールに基づき組み合わせることで、監視対象の状態を判定することも可能となる。これにより、個々の監視手段による監視結果のみを利用する場合に比べて、監視対象の状態を、より運用に即した態様で正確に判定することが可能となる。
【符号の説明】
【0085】
１００ 監視システム
１１０ 監視部
１２１ イベント生成部
１２２ メッセージ記憶部
１２３ イベント抽出部
１２４ ルール記憶部
１２５ イベント記憶部
１２６ 出力制御部
１２７ 出力部
１９０ 監視対象
１１０ 監視部
１２１ イベント生成部
１２２ メッセージ記憶部
１２３ イベント抽出部
１２４ ルール記憶部
１２５ イベント記憶部
１２６ 出力制御部
１２７ 出力部
１９０ 監視対象
【図1】
【図2】
【図3】
【図4】
【図5】