JPWO2014033894A1 - サービス性能監視方法 - Google Patents

Abstract

ネットワークを通じてクライアント計算機にサービスを提供するサービス実行基盤を監視対象とする監視システムは、同基盤が提供するサービスの負荷毎にコンポーネントの監視値のベースラインを管理し、現在のサービス負荷に応じてベースラインを使い分ける。また、監視システムはベースラインでサービス監視値又はコンポーネント監視値の異常を検知した場合は、直近から所定時間分前までのイベントと、ベースラインの時間帯内のイベントとを比較して、差分イベント（つまり普通でない直近のイベント）を特定する。

Description

実施例は、情報システムを課監視する技術に関する。

従来、システム監視では、監視対象サーバおよび当該サーバで監視可能な監視項目に対して、閾値を設定して、各監視項目ごとに閾値監視をすることで、異常検知を行っていた。しかし、各監視項目に対して適切な閾値を設定することは難しく、設定作業負荷も大きいため、特許文献１では、「計算機システム１の過去の負荷情報に基づいてシステムの負荷の時間的な推移を示す負荷モデルデータを作成する負荷モデルデータ作成手段１４と、負荷モデルデータに指定されたしきい値補正データを加算し、しきい値データを時系列に算出するしきい値データ作成手段１６と、システム１の現在の負荷情報とそれに対応する時刻のしきい値データを比較することによりシステムの異常負荷を検出する異常負荷検出手段１７とを具備する」技術を開示している。

特開２００１−１４２７４６号公報

特許文献１に開示の技術では、ネットワークを通じてクライアント計算機にサービスを提供するシステムを監視対象とすることが難しい。その困難さはたとえば以下の（１）又は（２）である。

（１）ネットワークサービスを提供するシステム（サービス実行基盤）のコンポーネントを監視する場合、端末からのリクエスト内容（例えば、リクエストタイプや、単位時間当たりのリクエスト数）によって監視値は変化し得るが、特許文献１ではそういったリクエスト内容を加味して過去の監視値をベースラインとして管理していないため、誤った異常検知が多発する。

（２）サービス実行基盤で異常を検知した場合、迅速に当該システムで発生するイベントの分析をすることができない。

以上の課題、特に上記（１）を解決するため、サービス実行基盤を監視する監視システムは、同基盤が提供するサービスの負荷毎にコンポーネントの監視値のベースラインを管理し、現在のサービス負荷に応じてベースラインを使い分ける。また、上記（２）を解決するため、監視システムはベースラインでサービス監視値又はコンポーネント監視値の異常を検知した場合は、直近から所定時間分前までのイベントと、ベースラインの時間帯内のイベントとを比較して、差分イベント（つまり普通でない直近のイベント）を特定する。

本発明によって、ネットワークサービスを提供するサービス実行基盤を効果的に監視することができる。

実施例１の情報システムを示す図である。 実施例１の計算機のハードウェア構成を示す図である。 実施例１のサービス監視サーバの構成を示す図である。 実施例１のストリームデータ処理システムを用いたサービス監視マネージャの性能解析処理フローを示す図である。 実施例１の構成情報の例である。 実施例１のシステム実行基盤の一例であるＷｅｂシステムの構成例である。 実施例１のシステム実行基盤のサービスに関する、サービス監視情報ストリームと業務情報付きサービス監視情報ストリームの内容を示す図である。 実施例１のシステム実行基盤のコンポーネントに関する、システム監視情報ストリームと業務情報付きシステム監視情報ストリームの内容を示す図である。 実施例１のシステム実行基盤に関する、イベント監視情報ストリームと業務情報付きイベント情報ストリームの内容を示す図である。 実施例１の業務情報付きイベント情報ストリームの格納先の、イベント情報テーブル、差分イベント情報テーブル、及び類似イベント情報テーブルを示す図である。 実施例１の業務情報付きサービス性能情報ストリームの格納先の、サービス性能情報テーブルを示す図である。 実施例１の業務情報付きシステム性能情報ストリームの格納先の、システム性能情報テーブルを示す図である。 実施例１の業務情報付きサービスグループベースライン情報ストリームの格納先の、サービスグループ性能要約情報テーブルを示す図である。 実施例１の業務情報付きシステムベースライン情報ストリームの格納先の、システム性能要約情報テーブルを示す図である。 実施例１のサービスカタログテーブルと、サービスカタログに基づくシステム稼働情報テーブルを示す図である。 実施例１の性能解析処理部のフロー図である。 実施例１の類似事象検出処理のフロー図である。 実施例１の監視画面を示す図である。 実施例１の監視画面を示す図である。 実施例２の情報システムを示す図である。 実施例２のストリームデータ処理システムを用いたサービス監視マネージャの性能解析処理フローを示す図である。 実施例２のインシデントを取り扱うための情報を示した図である。 実施例２の類似事象検出処理のフロー図である。 実施例２のインシデント検索処理のフロー図である。 実施例２の監視画面を示す図である。

以下に実施例の内容を説明する。なお、以後の説明では以下の用語を用いるがその意味は少なくとも以下である。

ストリーム：イベントや測定値等、時間によって変化し得る情報の時間推移を表した、情報の流れである。

ベースライン：異常を判断する際の元となる過去の監視値又は監視値を統計処理した値である。

なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現にて本発明の情報を説明するが、これら情報は必ずしもテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。

さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。

また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。この場合、プログラム配布サーバはＣＰＵと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶している。そして、配布プログラムをＣＰＵが実行することで、プログラム配布サーバのＣＰＵは配布対象のプログラムを他の計算機に配布する。

図１は、監視システムを含む情報システムの構成図である。監視対象は、サービス実行基盤のＷｅｂシステム１０１と、エンドユーザが各端末１０２からＷｅｂブラウザ１０３を用いてネットワーク１０４経由で利用するサービスである。監視システムは複数のＷｅｂシステムとその上で利用可能なサービスを監視する。なお、本実施例ではサービスの一例としてＷｅｂを例示するが、その他ファイル共有サービスや、その他のネットワークサービスがサービスに含まれる。

Ｗｅｂシステム１０１は、サーバ（プロセッサ、記憶資源、ネットワーク等から構成される）、ＯＳ、ミドルウェア等の物理的又は論理的なコンポーネントから構成されるサービス実行基盤である。そしてＷｅｂシステム１０１を監視する場合、たとえば監視対象サーバ内に常駐してＯＳやミドルウェアの稼働性能を監視するＯＳ監視エージェント１０５やミドルウェア監視エージェント１０６が監視する。あるいは、システムリモート監視サーバ１０７が、システムを構成するサーバのＯＳやミドルウェアの稼働性能をリモート監視するＯＳリモート監視１０８やミドルウェアリモート監視１０９が監視する。ＯＳ監視エージェント１０５、ミドルウェア監視エージェント１０６、ＯＳリモート監視１０８、ミドルウェアリモート監視１０８は、それぞれが監視対象としているコンポーネントの所定の監視項目についての監視値を、サービス監視サーバ１１３に送信する。

Ｗｅｂアクセスで利用するサービス監視は、ネットワークスイッチ１１０のミラーポートからＷｅｂシステム１０１の送受信パケットをミラーリングして、トラフィック監視サーバ１１１に送る。トラフィック監視サーバ１１１に搭載されたトラフィック監視エージェント１１２がＨｔｔｐパケットを解析して、応答時間を算出する。トラフィック監視サーバ１１１は、監視結果のＨｔｔｐパケットの概要と応答時間を、サービス監視サーバ１１３に送信する。ここで、トラフィック監視サーバ１１１が複数あり、それぞれ接続先スイッチからパケットを収集して解析してもよい。また、トラフィック監視サーバ１１１に限らず、ネットワークを流れるパケットを収集して、Ｈｔｔｐパケットを解析して、応答時間を算出して、Ｈｔｔｐパケット情報と応答時間を出力する機能を有するものであればよい。なおサービス監視の方法はこれ以外の方法、例えば、サービス実行基盤のＷｅｂサーバに応答時間を算出可能なプログラムを追加するといった方法を採用してもよい。

イベント監視サーバ１１５内のイベント監視マネージャ１１６は、監視対象であるＷｅｂシステム１０１や、各種監視サーバ１０７や１１１から通知される全てのイベント情報を取得する。なお、サービス実行基盤で発生する（別な言い方をするとイベント監視サーバが検知（受信も含む）する）イベントの種別としては、コンポーネントの障害や警告、コンポーネントの性能などの監視値が所定の基準を超えた場合、サービス実行基盤内で何らかの処理が始まった場合（例えばウィルススキャンやガーベージコレクション、デフラグ等）、とったものが例として考えられるが他の例でもかまわない。

サービス監視サーバ１１３に搭載されたサービス監視マネージャ１１４は、コンポーネント監視値をベースラインと比較し、異常判定を行い、異常通知をイベント監視サーバ１１５内イベント監視マネージャ１１６に通知する。また、Ｈｔｔｐパケット概要と応答時間に基づいて、監視対象サービス毎に応答時間とベースラインとを比較し、異常判定を行い、異常通知イベントをイベント監視サーバ１１５内イベント監視マネージャ１１６に通知する。

ここで、コンポーネント監視値またはサービス性能が異常の場合は、当該サービスと関連システムに関するイベントのうち、ベースラインに採用した正常時間帯と異常時間帯のイベントを比較し、異常時に出現する差分イベントまたはイベントの組み合わせを検出する。そして、当該差分イベントと類似イベントまたはイベントの組み合わせが、過去のイベントの中に含まれているかどうかを検索する。

さらに、応答時間を平準化するための数値計算を行い、監視結果に基づいてベースラインを設定する。

サービス監視の結果は、端末１１７のＷｅｂブラウザ１１８を用いて、リモートから見ることができる。もちろん、サービス監視の結果を表示する端末１１７は、サービス提供を受ける端末１０２と同じであってもよく、別であってもよい。

なお、本実施例のおけるサービス実行基盤を監視する監視システムはトラフィック監視サーバ１１１、サービス監視サーバ１１３、イベント監視サーバ１１５の３つのサーバより構成されているが、最低１つのサーバで以後に示すトラフィック監視とサービス監視が処理できればよい。さらに、請求項において表示や入力について触れているのであれば監視システムには上記趣旨に沿った端末１１７が含まれてもよい。反対に、サービス監視サーバ等トラフィック監視やサービス監視処理を行うサーバで表示や入力を行うのであれば、監視システムには端末を含まなくても良い。また、監視処理の高信頼化や並列化、分散化といった目的で複数のサーバで監視処理を分担するのであればこれら処理を担うサーバをまとめた存在が監視システムである。

なお、以後はコンポーネントの監視値は性能値を例として説明を行うが、その他の監視値（コンポーネントへのアクセスリトライ数、パケットロス率、コンテキストスイッチ数、コンポーネントへのリクエストキュー長やキュー溢れ回数等）にも適用可能である。

次に実施例の端末１０２、Ｗｅｂシステム１０１に含まれるサーバ、トラフィック監視サーバ１１１、システムリモート監視サーバ１０７、イベント監視サーバ１１５、端末１１７以外の計算機のハードウェア構成を図２に示す。図２にあるようにこれら計算機は、プロセッサ２０１、メモリ２０２、記憶デバイス２０３、通信インターフェース２０４を含み、これらは互いに接続される。なお、計算機は必要であれば入力デバイス２０６、出力デバイス２０７を含むことがある。なお、各サーバ、端末をまとめて図２で説明したが、これら計算機が必ずしも同一ハードウェアでなくてもよい。そして、図１の各計算機の隅丸の四角で表されたプログラムは、メモリ２０２又は記憶デバイス２０３（以後、まとめて記憶資源と呼ぶ）に格納され、プロセッサ２０１によって実行される。

図３は、図２で示した計算機の記憶資源に格納される情報、プログラムを表した図である。なお、図ではサービス監視マネージャプログラム１１４（以後は単にサービス監視マネージャと呼ぶ）はメモリ２０２、そのほかの情報は記憶デバイス２０３に格納されているが、記憶資源に格納されるのであれば各プログラム及び情報はどちらに記憶されても良い。サービス監視マネージャ１１４は画面表示処理部３０１と性能解析処理部３０３を含む。記憶デバイス２０３には、構成情報３０４、性能情報３０５、ベースライン情報３０６、イベント情報３０７、システム稼働情報３０８が格納される。端末１１７からＷｅｂブラウザ１１８経由でやりとりする入出力情報、Ｗｅｂシステム１０１やシステムリモート監視サーバ１０７から受信するコンポーネント監視値情報、トラフィック監視サーバ１１１から受信するＨｔｔｐパケットの情報、イベント監視サーバ１１５から受信するイベント情報は、通信インターフェース２０４により入出力される。なお、図２及び図３では入力デバイスと出力デバイスは別なデバイスとして図されているが、スマートフォンやタブレットコンピュータのような計算機がサーバや端末として用いることも想定されることから、入力デバイスと出力デバイスは１つのデバイスが兼ねても良い。

図４は、サービス監視サーバ１１３内の、サービス監視マネージャ１１４の構成と処理フローの例である。サービス監視マネージャ１１４は、ストリームデータ処理システム３０２を用いた性能解析処理部３０３をもつ。クエリリポジトリ４０６には、性能解析処理部３０３の各処理内容の実行コードが格納されている。ストリームデータ処理システム内部で、ストリームデータを格納する方法、受け付けられたクエリの解析、最適化および生成されたクエリ実行形式の登録方法などについては、特開２００６−３３８４３２号公報に開示された技術を用いればよい。ただし、ただし本発明は必ずしも特開２００６−３３８４３２号公報で実現する必要はなく、以下に示す入力ストリームからベースライン情報３０６、性能情報３０５、イベント情報３０７を更新又は作成できれば他の実現方式であってもよい。

ストリームデータ処理システム３０２は、トラフィック監視サーバ１１１からサービス監視情報ストリーム４０１、Ｗｅｂシステム１０１やシステムリモート監視サーバ１０７からシステム監視情報ストリーム４０２、イベント監視サーバ１０５からイベント監視情報ストリーム４０３を受信する。これら入力ストリーム（監視情報ストリーム）４０１から４０３は、ストリームデータフローマネージャ４０４を経由して、クエリ処理エンジン４０５を使用して、性能解析処理を行う。性能解析処理部３０３は、業務識別処理４１０、異常判定処理４１１、類似事象検出処理４１２、ベースライン設定処理４１３の順で実行される。

業務識別処理４１０では、入力ストリーム（監視情報ストリーム）４０１から４０３に、構成情報３０４のサービスとシステムからなる業務情報を付加した業務情報付き監視情報ストリームを生成する。業務情報付きイベント情報ストリーム４０７は、イベント情報３０７に格納する。

異常判定処理４１１では、所定時間内（例えば１分間）の業務情報付きサービス性能ストリームを、サービス毎に、性能値を統計処理（平均値、最大値、最小値、分散値を算出）し、統計値を、ベースライン情報３０６の業務別サービスグループ毎の、ベースライン採用日時のサービス性能要約情報と比較し、ベースライン許容範囲内かどうかを判定し、判定結果を含むサービス性能情報ストリーム４０８を、性能情報３０５に格納する。また、業務情報付きシステム監視情報ストリームの性能値を、ベースライン情報３０６の業務別システム毎の、ベースライン採用日時の、各ホストのエージェント別監視項目のサーバ性能要約情報と比較し、ベースライン許容範囲内かどうかを判定し、判定結果を含むシステム性能情報ストリーム４０８を、性能情報３０５に格納する。ここで、サービス性能およびシステム性能に対して異常と判定された場合は、イベント監視サーバ１１５に通知する。

類似事象検出処理４１２は、サービス性能またはシステム稼働性能がベースライン許容範囲を超過した場合に、イベント情報３０７から、当該業務に関する、異常となった時間帯のイベントと、ベースラインに採用した正常時間帯のイベントを取り出して比較し、異常時にしか現れない差分イベントを検出する。イベント情報３０７のうち、当該業務に関する過去のイベントに、差分イベントと類似のイベントがないかどうかを検索する。当該業務内に類似イベントがなければ、システム稼働情報３０８から、当該業務のシステム構成と類似のシステムを検出し、イベント情報３０７のうち、類似システムに関する業務のイベント情報も、検索対象とする。当該処理の結果、差分イベント情報４０７と類似イベント情報４０７を、イベント情報３０８に格納する。

ベースライン設定処理４１３は、所定時間内（例えば１時間）内の業務情報付きサービス性能ストリームを、サービスグループ毎に、性能値を統計処理（平均値、最大値、最小値、分散値を算出）し、ベースライン情報３０６に格納する。また、所定時間内（例えば１時間）内の業務情報付きシステム性能情報ストリームを、各ホストのエージェント別の監視項目毎に、性能値を統計処理（平均値、最大値、最小値、分散値を算出）し、ベースライン情報３０６に格納する。所定時間（例えば１時間）単位で、サービスグループ毎の、スループット／分の平均値と、ベースライン情報３０６に格納されている過去の同一時間帯のスループット／分の値が近い日時を検出して、翌時間帯の業務別ベースライン採用日時を、当該検出日の翌時間帯として、ベースライン情報３０６に格納する。

図５Ａは、構成情報３０４を示す模式図である。構成情報３０４は、Ｗｅｂシステムに含まれる業務グループを含むコンポーネントに関する情報（例えばコンポーネントの設定情報や属性情報）や、コンポーネント同士の関係（通信関係や包含関係等）を格納している。図５では構成情報３０４に含まれる例として構成情報５０２、サービスグループ情報５０３、システム情報５０４、サービス情報５０５を含むことを示している。

業務情報５０２の内容は、業務名５０２ａ、サービスグループ名５０２ｂ、システム名５０２ｃである。サービスグループ情報５０３の内容は、サービスグループ名５０２ｂ、ＵＲＩパス５０３ａである。サービス情報５０５の内容は、サービスグループ名５０２ｂ、サービス名５０５ａ、サービス内容５０５ｂ、ＵＲＩパス５０５ｃ、ＵＲＩクエリ５０５ｄである。システム情報５０４の内容は、システム名５０２ｃ、ホスト名５０４ａ、ＩＰアドレス５０４ｂである。

図５ＢはＷｅｂシステムの構成例を示した図である。業務グループ５０１は、複数の業務５０２から成る。業務５０２は、サービスグループ５０３とシステム５０４から成る。サービスグループ５０３は、複数のサービス５０５から成る。システム５０４は複数のホスト５０６から成る。ホスト５０６は複数のエージェントから成る。なお、１監視システム及びＷｅｂシステムで複数の業務を扱わないのであれば、業務グループは存在しなくてもよい。同様に複数のサービスを提供しないのであればサービスグループは存在しなくてもよい。

図６は、サービス監視情報ストリーム４０１と、業務識別処理４１０の出力結果の業務情報付きサービス監視情報ストリーム６０５である。

サービス監視情報ストリーム４０１は、時刻６０１、リクエスト情報６０２、レスポンス情報６０３、応答時間６０４より成る。リクエスト情報６０２の内容は、送信元ＩＰアドレス６０２ａ、メソッド６０２ｂ、ＵＲＩパス６０２ｃ、ＵＲＩクエリ６０２ｄである。レスポンス情報６０３の内容は、ＨＴＴＰステータスコード６０３ａ、転送データ量６０３ｂである。

業務情報付きサービス監視情報ストリームは、時刻６０１、業務名５０２ａ、サービスグループ名５０２ｂ、サービス情報５０５、リクエスト情報６０２、レスポンス情報６０３、応答時間６０４から成る。サービス情報５０５の内容は、サービス名５０５ａ、サービス内容５０５ｂである。

図７は、システム監視情報ストリーム４０２と、業務識別処理４１０の出力結果の業務情報付きシステム監視情報ストリーム７０６である。

システム監視情報ストリーム４０２は、時刻７０１、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能値７０５である。ホスト情報７０２の内容は、ホスト名７０２ａ、ＩＰアドレス７０２ｂである。監視項目７０４の内容は、レコード名７０４ａ、フィールド名７０４ｂである。

業務情報付きシステム監視情報ストリーム７０６は、時刻７０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能値７０５から成る。

図８は、イベント監視情報ストリーム４０３と、業務識別処理４１０の出力結果の業務情報付きサービスイベント情報ストリーム４０７ａおよび業務情報付きシステムイベント情報ストリーム４０７ｂである。

イベント監視情報ストリーム４０３は、時刻８０１、イベント情報８０２、オブジェクトタイプ８０３、オブジェクト情報８０４から成る。イベント情報８０２の内容は、重大度８０２ａ、登録時刻８０２ｂ、イベントＩＤ８０２ｃ、ソース ８０２ｄ、メッセージ８０２ｅ、アクション８０２ｆである。オブジェクトタイプ８０３は、イベント発行元を識別するための情報で、サービス情報、システム情報、ジョブ情報などである。

業務情報付きサービスイベント情報ストリーム４０７ａは、時刻８０１、業務名５０２ａ、サービスグループ名５０２ｂ、サービス情報５０５、イベント情報８０２から成る。

業務情報付きシステムイベント情報ストリームは４０７ｂは、時刻８０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、イベント情報８０２から成る。

図９は、業務情報付きイベント情報ストリーム４０７を格納するイベント情報３０７内のイベント情報テーブル３０７ａ、類似事象検索処理４１２で差分イベントおよび類似イベントの、業務情報付きイベント監視情報ストリームを格納する、差分イベント情報テーブル３０７ｂ、類似イベント情報テーブル３０７ｃのテーブル構成である。各イベント情報テーブル３０７ａ、３０７ｂ、３０７ｃは、同一テーブル構成で、時刻８０１、業務名５０２ａ、サービスグループ名５０２ｂ、サービス情報５０５、システム名５０２ｃ、ホスト情報７０２、イベント情報８０２から成る。

図１０は、業務情報付きサービス監視情報ストリーム６０５に対して、異常判定処理４１１で統計値を求めてベースライン判定した結果の、サービス性能情報ストリーム４０８ａを格納する、性能情報３０６内のサービス性能情報テーブル３０５ａである。業務情報付きサービス性能情報ストリーム４０８ａは、時間１００１、業務名５０２ａ、サービスグループ名５０２ｂ、サービス情報５０５、判定１００２、１分あたりの応答時間の統計値１００３、１分あたりのスループット累積値１００４、１分あたりのエラー率累積値１００５から成る。サービス性能情報テーブル３０５ａの内容は、時間１００１、業務名５０２ａ、サービスグループ名５０２ｂ、サービス情報５０５、判定１００２、１分あたりの応答時間の統計値１００３、１分あたりのスループット累積値１００４、１分あたりのエラー率の累積値１００５である。

図１１は、業務情報付きシステム監視情報ストリーム７０６に対して、異常判定処理４１１でベースライン判定した結果の、システム性能情報ストリーム４０８ｂを格納する、性能情報３０６内のシステム性能情報テーブル３０５ｂである。業務情報付きシステム性能情報ストリーム４０８ｂは、時刻１１０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能情報７０５、判定１１０２から成る。システム性能情報テーブル３０５ｂの内容は、時刻１１０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能情報７０５、判定１１０２である。

図１２は、業務情報付きサービス性能情報ストリーム４０８ａに対して、ベースライン設定処理４１３で、所定時間（例えば１時間）で、サービスグループ毎の、サービス性能の統計値を求めて、同一サービスグループ内、同一時間帯で、１分あたりのスループット平均値が最も近い日を検出し、当該検出日の翌時間帯を、翌時間帯の業務別ベースライン採用日時とする、業務情報付きサービスグループベースライン情報ストリーム４０９ａを格納する、ベースライン情報３０６のサービスグループ性能要約情報テーブル３０６ａである。業務情報付きサービス性能ベースライン情報ストリーム４０９ａは、時間１２０１、業務名５０２ａ、サービスグループ名５０２ｂ、スループット（統計値）１２０２、エラー率（統計値）１２０３、応答時間（統計値）１２０４、ベースライン採用日時１２０５から成る。サービスグループ性能要約情報テーブル３０６ａの内容は、時間１２０１、業務名５０２ａ、サービスグループ名５０２ｂ、スループット統計値（１２０２）、エラー率（統計値）１２０３、応答時間（統計値）１２０４、ベースライン採用日時１２０５である。

図１３は、業務情報付きシステム性能情報ストリーム４０８ｂに対して、ベースライン設定処理４１３で、所定時間（例えば１時間）で、システム内のホストのエージェントの監視項目に対する性能値の統計値を求めて、結果の業務情報付きシステムベースライン情報ストリーム４０９ｂを格納する、ベースライン情報３０６のシステム性能要約情報テーブル３０６ｂである。業務情報付きシステムベースライン情報ストリーム４０９ｂは、時間１３０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能値（統計値）１３０２から成る。システム性能要約情報テーブル３０６ｂの内容は、時間１３０１、業務名５０２ａ、システム名５０２ｃ、ホスト情報７０２、エージェント名７０３、監視項目７０４、性能値（統計値）１３０２である。

図７の業務情報付きシステム監視情報ストリーム７０６の時刻７０１が属する時間帯の、業務名５０２ａと一致する、図１２のサービスグループ性能要約情報テーブル３０６ａの時間１２０１と業務名５０２ａの、ベースライン採用日時１２０５をみて、図１３のシステム性能要約情報テーブル３０６ｂの性能値（統計値）を使用する。

図１４は、システム稼働情報３０８に含まれるサービスカタログテーブル１４０１と、システム稼働情報テーブル１４０２である。サービスカタログテーブル１４０１の内容は、システム種別１４０３、サーバスペック１４０４、ＯＳ種別１４０５、ミドルウェア種別１４０６、数量１４０７から成る。

システム稼働情報テーブル１４０２の内容は、システム名５０２ｃ、システム種別１４０３、ＵＰ（Ｕｓｅｒ Ｐｒｏｇｒａｍ）情報１４０８、累積稼働日数１４０９、アラート発生件数１４１０、障害件数１４１１、所定期間の平均サービス性能情報１４１２、所定期間の平均システム性能情報１４１３から成る。

サービスカタログテーブル１４０１は、ＰａａＳ（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）提供者が、提供サービスを登録する。

システム稼働情報テーブル１４０２は、システムを構築時や更改時に、システム名５０２ｃと、サービスカタログテーブル１４０１から選択したシステム種別１４０３と、ＵＰ情報１４０８を登録する。また、累積稼働日数１４０９、アラート発生件数１４１０、障害件数１４１１は、別に管理されているインシデント管理から、定期的に登録更新される。さらに所定期間の平均サービス性能情報１４１２、所定期間の平均システム性能情報１４１３は、性能情報３０５から、定期的に集計処理されて登録更新される。

システム稼動情報テーブル１４０２は、対象システムとシステム種別１４０３が同一のシステムを検索したり、類似システムのうち、稼動実績の長いあるいは近いシステムを選択するために必要である。

図１５は、性能解析処理部３０３の処理の流れである。性能解析処理部３０３は、業務識別処理４１０、異常判定処理４１１、類似事象検出処理４１２、ベースライン設定処理４１３の順で処理する。

業務識別処理４１０は、監視情報ストリームを受信する処理１５０１と、監視情報ストリームに業務情報を付加する処理１５０２からなる。受信処理１５０１は監視情報ストリームの新しい情報を受信する。

監視情報ストリームに業務情報を付加する処理１５０２は、構成情報３０４を参照して、サービス監視情報ストリームの場合は、ＵＲＩが共通のサービスグループに関連する業務を取得し、ＵＲＩとクエリが共通のサービス情報を取得し、業務種別付きサービス監視情報ストリームを作成する。

システム監視情報ストリームの場合は、ホストが含まれるシステムに関連する業務を取得し、業務情報付きシステム監視情報ストリームを作成する。

イベント監視情報ストリームの場合は、オブジェクトタイプがサービスの場合は、オブジェクト情報に格納されているサービス情報のうちのサービスグループに関連する業務を取得し、業務種別付きイベント監視情報を作成する。オブジェクトタイプがホストの場合は、ホストが含まれるシステムに関連する業務を取得し、業務種別付きイベント監視情報を作成する。業務種別付きイベント監視情報は、イベント情報３０７に格納する。

異常判定処理４１１は、所定時間内に到着する業務種別付きサービス監視情報ストリームに対して、性能値の統計値（平均、最大、最小、分散）を求めて、業務種別付きサービス性能情報ストリームを作成する処理１５０３と、業務種別付きサービス性能情報の統計値が、ベースラインを超過していないかを判定し、業務種別付きサービス性能情報ストリームを性能情報３０５に登録する、または業務種別付きシステム監視情報のホスト内エージェントの監視項目に対する性能値がベースラインを超過していないかを判定し、業務種別付きシステム性能情報ストリームを性能情報３０５に登録する処理１５０４から成る。

ベースライン許容範囲を超過するか否かの判定部１５０５の結果、ベースラインを超過する場合、類似事象検出処理４１２を実行する。類似事象検出処理４１２は、正常時と異常時のイベント情報を比較して差分イベントを検出する、イベント情報比較処理１５０６と、差分イベントと類似のイベントが過去に存在するかどうかを検索する、類似イベント検索処理１５０７から成る。

ベースライン設定処理４１３において、まず、所定時間内の性能要約情報を作成する処理１５０８は、業務毎に、サービスグループ毎の単位時間（例えば１分）あたりのサービス性能（応答時間、スループットなど）の、所定時間（例えば１時間）内の統計値を算出して、サービス性能要約情報を作成する。また、同処理１５０８は、システム内の各ホストのエージェント毎の監視項目の性能値の所定時間（例えば１時間）内の統計値を算出して、システム性能要約情報を作成する。同処理１５０８は、単位時間（例えば１分）おきに、性能情報の統計値(最大値、最小値、平均値)を累積していく。
次に、所定時間内のスループット統計値と近い過去の統計値を検出して翌時間帯のベースラインを決定する処理１５０９は、所定時間(例えば１時間)分の性能要約情報が累積された時点で、同一業務のサービスグループの、過去同一時間帯のスループット統計値のうち、最も近い日にちを見つけて、翌時間帯のベースライン採用日として、ベースライン情報３０６に格納する。

図１６は、類似事象検出処理４１２の処理の流れである。類似事象検出処理４１２は、イベント情報比較処理１５０６と類似イベント検索処理１５０７から成る。

イベント情報比較処理１５０６は、業務毎に、ベースライン超過時点を含む直近の所定時間内のイベント情報を取得する処理１６０１と、ベースライン採用時間帯（正常時）のイベント情報を取得する処理１６０２と、ベースライン超過時間帯（異常時）のイベントと、ベースライン採用時間帯（正常時）のイベントで、イベントＩＤを比較し、正常時には出現しないが異常時に出現する差分イベントを検出し、差分イベントをイベント情報３０７に格納する処理１６０３から成る。

類似イベント検索処理１５０７は、同一業務の過去のイベントから、差分イベント（組み合わせ）とイベントＩＤが一致するものを検索する処理１６０４と、差分イベントとの適合性判定部１６０５と、適合イベントが見つかった場合に類似イベント（組み合わせ）をイベント情報３０７に格納する処理１６０６と、システム稼働情報３０８を参照して、当該業務と関連するシステムと、同一のシステム構成をもつ他システムを検索する処理１６０７と、システム類似度判定部１６０８と、類似システム関連業務の過去イベントから、差分イベント（組み合わせ）とイベントＩＤが一致するものを検索する処理１６０９成る。

図１７から図１８は、サービス監視サーバ１１３にインストールされたサービス監視マネージャ１１４の画面表示処理部３０１によって実行され、端末１１７のＷｅｂブラウザ１１８上で表示する監視画面である。

図１７は、業務別に、サービスと関連システム性能をベースライン監視した結果、ベースライン超過を検知し、正常時には出現しない差分イベントを検出した際の、監視画面１７００である。監視画面１７００は、業務一覧表示部１７０１、表示期間指定部１７０２、トポロジー表示部１７０３、差分イベント一覧表示部１７０４、グラフ表示部１７０５から構成される。

本監視画面の使い方は、まず、統合イベント監視ツール側で、業務内サービスあるいはホストでの異常に気付くと、監視画面１７００で、業務一覧表示部１７０１より、確認したい業務を選択する。次に、表示期間指定部１７０２で期間を指定して、トポロジー表示部１７０３により、業務を構成するサービスおよびシステム内ホストの稼働状況を確認する。また、このとき、差分イベント一覧表示部１７０４で、異常時にしか現れないイベントが表示される。そして、グラフ表示部１７０５では、表示期間指定部１７０２で指定した期間内の、トポロジー表示部１７０３で選択した異常箇所の性能傾向と、差分イベント一覧で選択したイベントの発生状況を、確認する。グラフ表示部１７０５において、ベースラインに採用するのは、直近のアクセス数が最も近い同一時間帯の日付の性能値であるため、イベント２が発生している日１７０６の応答時間のベースラインは、最もアクセス数が近い日１７０７の応答時間をベースラインとしている。

図１８は、図１７で検出した差分イベントに対して、同一業務および、同一システム構成の他業務の過去イベントのなかから、類似イベントを検出した結果の監視画面１８００である。監視画面１８００は、業務一覧表示部１８０１、表示期間指定部１８０２、差分イベント一覧表示部１８０３、類似イベント一覧表示部１８０４、グラフ表示部１８０５から構成される。

本監視画面の使い方は、図１７で検出した異常時の差分イベントについて、差分イベント一覧表示部１８０３で、表示期間指定部１８０２で期間を指定して、差分イベントの発生状況を発生件数で確認する。ここで、差分イベントが頻繁に発生しており、無視できるイベントなのか、めったに発生しない注意すべきイベントなのかを判別する。

続いて、発生件数の少ない注意すべきイベントの場合、同一業務または類似システムからなる業務に関わる過去のイベントのなかから、類似イベントを検索し、検索結果を類似イベント一覧１８０４で表示する。

グラフ表示部１８０５で、類似イベント発生状況と性能傾向を、現時点と過去と比較し、障害発生を予測し、障害発生前に対処が可能な情報を提示する。

以上が実施例１の説明である。

次に実施例２を図を用いて説明する。

図１９は、実施例２の構成を示した図であり、実施例１との差異はインシデント管理サーバ１１９を追加したことである。インシデント管理サーバ１１９内には、インシデント管理１２０プログラムを記憶資源に格納し、実行する。

図２０は、図４のサービス監視サーバ１１３内の、サービス監視マネージャ１１４の構成と処理フローに、インシデント管理サーバ１１９のインシデント管理１２０と連携して、類似インシデント情報を追加する場合の構成と処理フローである。ストリームデータ処理システム３０２内の性能解析処理部３０３において、類似事象検出処理４１２は、サービス性能またはシステム稼働性能がベースライン許容範囲を超過した場合に、イベント情報３０７から、当該業務に関する、異常となった時間帯のイベントと、ベースラインに採用した正常時間帯のイベントを取り出して比較し、異常時にしか現れない差分イベントを検出する。そして、インシデント管理サーバ１１９内インシデント管理１２０のインシデント検索処理２００１で、差分イベントが、当該業務に関する過去のイベントに基づいて登録済みのインシデント情報２００２のなかに、類似のインシデント情報が存在するかどうかを検索する。検索の結果、類似インシデントが見つかった場合には、業務情報付きインシデント情報ストリーム２００３を生成し、類似インシデント情報２００４に格納する。

図２１は、図２０のインシデント検索処理２００１の、入力情報２１０１と出力情報２１０３、インシデント情報２００２内のインシデント情報テーブル２１０１と、類似インシデント情報２００４内の類似インシデント情報テーブル２１０４である。

インシデント検索のための入力情報２１０１は、検索対象期間を示す開始日時２１０５と終了日時２１０６、検索対象の業務名５０２ａ、サービスグループ名５０２ｂ、システム名５０２ｃ、インシデントに関連するイベントＩＤ２１０７からなる。

インシデント情報テーブル２１０２は、タイトル２１０８、重要度２１０９、インシデントＩＤ２１１０、インシデントＩＤへのＵＲＬ２１１１、業務名５０２ａ、サービスグループ名５０２ｂ、システム名５０２ｃ、発生日時２１１２、インシデントに関連するイベントＩＤ２１１３から成る。

インシデント検索結果の出力情報２１０３は、２１０２のインシデント情報テーブルの各項目に対応する内容である。

類似インシデント情報テーブル２１０４は、２１０３のインシデント検索結果を格納するために、インシデント情報に対応する各項目から成る。

図２２は、図１６の類似事象検出処理４１２の処理の流れに、類似障害検索処理２２０１を追加した処理フローである。類似事象検出処理４１２において、イベント情報比較処理１５０６により、差分イベントを検出し、イベント情報３０７に格納する。

次に、類似障害検索処理２２０１で、差分イベント（組み合わせ）と類似の関連イベントに基づくインシデントが存在するかどうかを検索する。類似障害検索処理２２０１は、検索期間と業務情報と差分イベント（組み合わせ）から成るデータセットを作成する処理２２０２と、作成したデータセットを入力パラメータとして、類似インシデントを返り値とする検索コマンドを生成する処理２２０３と、生成した検索コマンドをインシデント管理に送信し、類似インシデント情報一覧を受信する処理２２０４から成る。

類似障害検索処理２２０１の結果、類似インシデントが見つかったか否かの判定処理２２０５を行い、類似インシデントが見つかった場合は、類似インシデント情報一覧を類似インシデント情報テーブルに格納する処理２２０６を行い、類似インシデント情報２００４に格納する。るインシデントが見つからなかった場合は、類似イベント検索処理１５０７を実行する。

図２３は、インシデント管理サーバ１１９内のインシデント管理１２０での、インシデント検索処理２００１の処理の流れである。インシデント検索処理２００１は、検索開始日時から終了日時の期間内で、同一業務のインシデントを抽出する処理２３０１と、抽出したインシデントのうち、関連イベントが含まれるインシデントを抽出する処理２３０２と、抽出したインシデント情報から、“タイトル”、“重大度”、“インシデントＩＤ”、“インシデントＩＤへのＵＲＬ”、“業務名”、“発生日時”、“関連イベントＩＤ”から成るデータセットを作成する処理２３０３と、作成したデータセットを送信する処理２３０４から成る。

図２４は、サービス監視サーバ１１３にインストールされたサービス監視マネージャ１１４の画面表示処理部３０１によって実行され、端末１１７のＷｅｂブラウザ１１８上で表示する監視画面である。図２４は、図１８の、差分イベントに対して、類似イベントを検出した結果の監視画面１８００と異なり、類似インシデントを検出した結果の監視画面２４００である。

監視画面２４００において、差分イベント一覧２４０１に対して、検索期間２４０２を指定すると、当該イベントの発生件数が表示される。

次に、類似検索対象にチェック２４０３の付与されたイベント（組み合わせ）に関するインシデントを検索した結果が、類似インシデント一覧２４０４に表示される。

さらに、インシデントＩＤ２４０５をクリックすると、インシデント詳細ＵＲＬ先のインシデント画面２４０６が表示される。インシデント画面２４０６内には、インシデント情報２４０７が表示され、現在発生しているイベントが、障害につながるかどうかを判断することができる。さらに、インシデント画面２４０６には、回避策や解決策といったサービス実行基盤の管理者が行い、そして入力した内容が表示されるため、サービス実行基盤の管理者は、これら表示情報を参考にして、障害発生前に対処することが可能となる。

以上、実施例１及び２の監視システムによって、例えば、不確定に変動するサービス利用と、定時に定型処理するバッチジョブなどのシステム内部処理とで、両方共に類似の利用状況の過去の性能情報であるベースラインを見つけるのは困難であったが、同一時間帯の過去のサービスのスループットのなかで、現在のスループットと近い日にちを見つけるので、定時実行内部処理を加味したシステムおよびサービスのベースラインを、短期間に精度よく見つけることができるようになった。

また、実施例１及び２の監視システムによって、ベースラインの許容範囲を超過した場合、この先放っておくと障害に至ってしまうため対処が必要なケースと、時間経過とともに自然回復するため対処が不要なケースがあるが、予兆段階で正しい判断をするための情報を提示できるようになった。

さらに、実施例１及び２の監視システムによって、サービス利用状況が近い、同一時間帯のシステム稼動性能をベースラインとすることで、外部アクセス変動(外乱)によらない、システム内部処理異常に気づくことができるようになった。従って、外部アクセスによる外的要因か、内部処理異常の内部要因かを切り分けられるようになり、原因調査に要する時間を削減でき、適切な対象方法をとることができるようになった。

なお、図１６にあるように、ステップ１６０２にて取得するイベント情報は、採用されたベースラインの時間帯のイベント情報であるため、結果的に取得されるイベント情報もその時のサービス監視の値に適したものが選択される。これは例えばサービスリクエストが多い時と少ない時とで発生するイベントが相違する場合に好適である。しかし、図１６の類似事象検出処理はベースラインをサービス監視の値と関連付けて管理しない場合でも適用することで、サービス実行基盤で異常を検知後に迅速にイベント分析は可能である。これは図２２も同様である。

なお、コンポーネントの異常検知に用いるベースラインをその時のサービス監視値に近いベースラインを１つ選ぶ代わりに、複数のベースラインから擬似的なベースラインを合成（例えば２つのベースラインの平均化等）してもよい。このような合成はサービス実行基盤のサービス負荷がわずかに増加した場合にコンポーネントの監視値が急激に変化しない場合は好適である。一方の１つのベースラインを選択する場合は、図１７のようなベースライン表示をした場合に、表示ベースラインは事実として発生したものであることから、監視システムのユーザーは事実ベースでの分析をより深く行うことが出来る。また、１つのベースラインを選択した場合のほうが、対応するイベント情報を選択しやすい。

なお、イベント監視サーバ１１５からストリームとして送信されてきたイベントは、イベント監視サーバ１１５がＷｅｂシステム１０１からイベントの内容を示すメッセージを受信したことでイベント監視サーバ１１５が検知するが考えられる。また、他のイベント検知の方法としては、イベント監視サーバ１１５がサービス実行基盤に状態取得要求を送信し、そこで受信した状態によってイベント検知を行う方法も考えられる。しかし、イベント検知は他の方法で実現してもよい。

１０１・・・Ｗｅｂシステム、１０２・・・端末、１１１・・・トラフィック監視サーバ、１１３サービス監視サーバ

Claims (15)

1. 複数のコンポーネントを含み、前記コンポーネントを用いて所定のサービスを提供するサービス実行基盤と通信可能な通信インターフェースと、
   記憶資源と、
   前記サービス実行基盤から、前記所定のサービスの監視値であるサービス監視ストリームと、前記コンポーネントの監視値であるコンポーネント監視ストリームと、を受信処理するプロセッサと、
   を有する監視システムであって、
   前記プロセッサは、
   （Ａ）過去の所定の時間帯のコンポーネント監視ストリームに基づいてコンポーネントベースラインを作成し、
   （Ｂ）過去の所定の時間帯のサービス測定ストリームの統計値を計算し、
   （Ｃ）前記作成したコンポーネントベースラインを、前記所定の時間帯及び（Ｂ）で計算した統計値と対応付けて前記記憶資源に格納し、
   （Ｄ）前記コンポーネントベースライン作成後、サービス監視ストリーム及びコンポーネント監視ストリームを新たに受信したら、当該新規受信したサービス監視ストリームに適するコンポーネントベースラインを選択し、前記選択したコンポーネントベースラインを基準に当該新規受信したコンポーネント監視ストリームの異常を判断する、
   を処理する監視システム。
2. 請求項１記載の監視システムであって、
   前記監視システムは表示装置を有し、
   前記プロセッサは、
   前記新規受信したサービス監視値と、
   前記新規受信したコンポーネント監視値と、
   前記選択したコンポーネントベースラインと、
   を前記表示装置に表示させる、
   監視システム。
3. 請求項２記載の監視システムであって、
   前記プロセッサは、
   （Ｅ）前記サービス実行基盤のイベントを検知し、検知した時間と共に記憶資源に格納し、
   （Ｆ）（Ｄ）にて異常と判断した場合、（Ｄ）のコンポーネントベースラインに対応付けられた前記所定の時間帯を取得し、取得した時間帯内に検知したイベントを選択し、
   （Ｇ）選択したイベントに基づいて、前記所定の時間帯では検知してなかった直近から所定期間前までのイベントを選択し、
   （Ｈ）（Ｇ）で選択したイベントの内容を表示する、
   監視システム。
4. 請求項３記載の監視システムであって、
   前記プロセッサは、
   （Ｉ）（Ｇ）で選択したイベントを過去のイベントから検索することで、類似するイベントを当該類似イベントの検知時間と共に表示する、
   監視システム。
5. 請求項４記載の監視システムであって、
   前記検索対象となる過去のイベントには、システム構成上類似する他のサービス実行基盤のイベントも含まれる、
   監視システム。
6. 請求項３記載の監視システムであって、
   前記プロセッサは、
   （Ｊ）（Ｇ）で選択したイベントをインシデント情報に含まれるイベントと比較することで、前記直近から所定期間前までに新たに検知したイベントに関連する可能性があるインシデントの内容を表示する、
   監視システム。
7. 複数のコンポーネントを含み、前記コンポーネントを用いて所定のサービスを提供するサービス実行基盤を監視する監視システムで実行する監視プログラムであって、
   前記監視プログラムは、
   前記サービス実行基盤から、前記所定のサービスの監視値であるサービス監視ストリームと、前記コンポーネントの監視値であるコンポーネント監視ストリームと、を受信し、
   （Ａ）過去の所定の時間帯のコンポーネント監視ストリームに基づいてコンポーネントベースラインを作成し、
   （Ｂ）過去の所定の時間帯のサービス測定ストリームの統計値を計算し、
   （Ｃ）前記作成したコンポーネントベースラインを、前記所定の時間帯及び（Ｂ）で計算した統計値と対応付けて前記監視システムの記憶資源に格納し、
   （Ｄ）前記コンポーネントベースライン作成後、サービス監視ストリーム及びコンポーネント監視ストリームを新たに受信したら、当該新規受信したサービス監視ストリームに適するコンポーネントベースラインを選択し、前記選択したコンポーネントベースラインを基準に当該新規受信したコンポーネント監視ストリームの異常を判断する、
   ステップを含む監視プログラム。
8. 請求項７記載の監視プログラムであって、
   前記監視プログラムは、
   前記新規受信したサービス監視値と、
   前記新規受信したコンポーネント監視値と、
   前記選択したコンポーネントベースラインと、
   を前記監視システムの表示装置に表示させる、
   ステップを含む監視プログラム。
9. 請求項８記載の監視プログラムであって、
   前記監視プログラムは、
   （Ｅ）前記サービス実行基盤のイベントを検知し、検知した時間と共に記憶資源に格納し、
   （Ｆ）（Ｄ）にて異常と判断した場合、（Ｄ）のコンポーネントベースラインに対応付けられた前記所定の時間帯を取得し、取得した時間帯内に検知したイベントを選択し、
   （Ｇ）選択したイベントに基づいて、前記所定の時間帯では検知してなかった直近から所定期間前までのイベントを選択し、
   （Ｈ）（Ｇ）で選択したイベントの内容を表示する、
   ステップを含む監視プログラム。
10. 請求項９記載の監視プログラムであって、
    前記監視プログラムは、
    （Ｉ）（Ｇ）で選択したイベントを過去のイベントから検索することで、類似するイベントを当該類似イベントの検知時間と共に表示する、
    ステップを含む監視プログラム。
11. 請求項１０記載の監視プログラムであって、
    前記検索対象となる過去のイベントには、システム構成上類似する他のサービス実行基盤のイベントも含まれる、
    監視プログラム。
12. 請求項９記載の監視プログラムであって、
    前記監視プログラムは、
    （Ｊ）（Ｇ）で選択したイベントをインシデント情報に含まれるイベントと比較することで、前記直近から所定期間前までに新たに検知したイベントに関連する可能性があるインシデントの内容を表示する、
    ステップを含む監視プログラム。
13. 請求項３記載の監視システムであって、
    前記イベントの検知とは、
    前記監視システムが前記サービス実行基盤からイベントの内容を記した情報を受信すること、
    または
    前記サービス実行基盤の状態を取得することで、前記監視システムが前記サービス実行基盤にてイベントが発生したと判断する、
    ことを特徴とする監視システム。
14. 請求項９記載の監視プログラムであって、
    前記イベントの検知とは、
    前記監視システムが前記サービス実行基盤からイベントの内容を記した情報を受信すること、
    または
    前記サービス実行基盤の状態を取得することで、前記監視システムが前記サービス実行基盤にてイベントが発生したと判断する、
    ことを特徴とする監視プログラム。
15. 複数のコンポーネントを含み、前記コンポーネントを用いて所定のサービスを提供するサービス実行基盤と、
    前記サービス実行基盤の監視値を含む監視ストリームを受信処理する監視システムと、
    を有するシステムであって、
    前記監視システムは、
    （１）前記サービス実行基盤のイベントを検知し、検知した時間と共に記憶資源に格納し、
    （２）過去の監視ストリームに基づいてベースラインを作成し、
    （３）前記作成したベースラインを、基となった前記過去の監視ストリームの時間帯と関連付けて前記記憶資源に格納し、
    （４）前記ベースライン作成後、監視ストリームを新たに受信したら、前記ベースラインを基準に当該新規受信した監視ストリームの異常を判断し、
    （５）（４）にて異常と判断した場合、（４）のベースラインに対応付けられた時間帯を取得し、取得した時間帯内に検知したイベントを選択し、
    （６）選択したイベントに基づいて、前記取得した時間帯では検知してなかった直近から所定期間前までのイベントを選択し、
    （７）（Ｇ）で選択したイベントの内容を表示する、
    システム。

Images