JP6878984B2 - 監視プログラム、監視方法および監視装置 - Google Patents

Description

本発明は、監視プログラム、監視方法および監視装置に関する。

データセンタなどの大規模なＩＴ（Information Technology）システムでは、監視製品を導入し、業務サーバの安定稼動を監視することが行われている。例えば、業務サーバに異常が発生した場合、監視製品によって監視イベントが発行され、オペレータが監視イベントの内容を確認のうえ対処の判断を行っている。また、例えば、サーバ集約によって複数の業務アプリケーションをミドルウェア上に集約して運用している環境においても、監視製品によって各業務アプリケーションの監視が行われる。

このようなＩＴシステムなどでは、メンテナンスなどの運用管理操作の対象や回数も増えることもあり、各運用管理操作をワークフローとして自動化している。一方で、メンテナンスのためにサーバの停止などを行った場合、大量の監視イベントが通知されるので、オペレータは、すべての監視イベントを一つ一つ確認することになり、他の障害への対応の遅れや見逃しが発生する可能性が高い。近年では、メンテナンスなどを行う場合、監視製品の機能によって、メンテナンス対象のサーバの監視抑制の設定を行って、監視イベントの通知を抑制することが行われている。

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

しかしながら、監視抑制の設定を行うことができないまま、メンテナンスが実行されることにより、運用管理操作による自明な監視イベントと障害による監視イベントとが発生する状況が起こりうる。この結果、他の障害への対応の遅れや見逃しが発生する可能性が高くなる。例えば、緊急メンテナンスで監視担当者による監視抑制の設定が間に合わない場合やメンテナンスの影響範囲を正しく理解できていない場合、自明な監視イベントの通知が実行されてしまう。

また、運用管理操作の自動化は、効果的な部分を優先して行っており、すべて一律で自動化している訳ではないので、ワークフローとして自動化をした範囲と、自動化していない範囲とが混在した状態が増えている。このような状況では、監視抑制の設定をしてしまうと、ワークフローによって発生する自明な監視イベントだけでなく、その間に発生したワークフローとは関係のない監視イベントも抑制してしまう。

一つの側面では、運用に関する処理に起因して生じるイベントに関する情報の通知を選択的に抑制することができる監視プログラム、監視方法および監視装置を提供することを目的とする。

第１の案では、監視プログラムは、コンピュータに、サーバの監視に関するイベントを取得すると、取得した前記イベントに関する情報を端末に通知する処理を実行させる。監視プログラムは、コンピュータに、前記サーバの運用に関する処理の識別情報と、該サーバの監視に関するイベントのうち該サーバの運用に関する処理の実行中に発生したイベントと、を取得する処理を実行させる。監視プログラムは、コンピュータに、サーバの運用に関する処理に起因して発生したイベントを該処理の識別情報に対応付けて記憶する記憶部を参照して、取得した前記処理の識別情報に対応付けられたイベントを特定する処理を実行させる。監視プログラムは、コンピュータに、取得した前記イベントのうち、特定した前記イベントに関する情報の通知を抑制する処理を実行させる。

一実施形態によれば、運用に関する処理に起因して生じるイベントに関する情報の通知を選択的に抑制することができる。

図１は、実施例１にかかるシステムの全体構成例を示す図である。 図２は、実施例１にかかるシステム構成ツリーを説明する図である。 図３は、実施例１にかかるワークフローを説明する図である。 図４は、実施例１にかかる監視装置の機能構成を示す機能ブロック図である。 図５は、監視イベントＤＢに記憶される監視イベントの例を示す図である。 図６は、実施例１にかかる運用管理装置の機能構成を示す機能ブロック図である。 図７は、ワークフロー管理ＤＢに記憶されるワークフローの例を示す図である。 図８は、変数管理ＤＢに記憶される変数の例を示す図である。 図９は、インスタンス管理ＤＢに記憶されるインスタンスの例を示す図である。 図１０は、イベントパターン管理ＤＢに記憶されるイベントパターンの例を示す図である。 図１１は、遷移ルート管理ＤＢに記憶される遷移ルートの例を示す図である。 図１２は、パターンデータ管理ＤＢに記憶されるパターンデータの例を示す図である。 図１３は、フィルタリング管理ＤＢに記憶されるフィルタの例を示す図である。 図１４は、ワークフローの実行処理の流れを示すフローチャートである。 図１５は、イベントパターンの更新処理の全体的な流れを示すフローチャートである。 図１６は、イベントグループ化の分割を説明する図である。 図１７は、イベントグループの生成を説明する図である。 図１８は、イベントグループ群を説明する図である。 図１９は、生成されたイベントパターンを説明する図である。 図２０は、突合処理の流れを示すフローチャートである。 図２１は、一致処理の流れを示すフローチャートである。 図２２は、一致判定の結果を説明する図である。 図２３は、フィルタリングを説明する図である。 図２４は、イベントパターンの更新処理の流れを示すフローチャートである。 図２５は、イベントパターンの再生成処理の流れを示すフローチャートである。 図２６は、ハードウェア構成例を示す図である。

以下に、本願の開示する監視プログラム、監視方法および監視装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［システム構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、業務サーバ群１と監視装置１０と運用管理装置５０とがネットワークＮを介して接続される。なお、ネットワークＮは、有線や無線を問わず、インターネットや専用線などの各種ネットワークを採用することができる。また、監視装置１０と運用管理装置５０とは、別々の筐体で実現することもでき、同じ筐体で実現することもできる。

業務サーバ群１は、複数の業務サーバから構成される業務システムであり、例えば帳票管理のシステムなどである。図２は、実施例１にかかるシステム構成ツリーを説明する図である。図２に示すように、業務サーバ群１は、Ｗｅｂ／ＡＰサーバ、ＷＦサーバ、ＤＢサーバを有する帳票管理システムである。なお、Ｗｅｂ／ＡＰサーバは、Ｗｅｂサービスと業務アプリケーションであるＡＰサービスとをクライアントに提供し、ＷＦサーバは、帳票管理である帳票サービスをクライアントに提供し、ＤＢサーバは、ＤＢの検索などのＤＢサービスをクライアントに提供する。

監視装置１０は、業務サーバ群１を監視するサーバの一例である。具体的には、監視装置１０は、監視アプリケーション（監視製品）のマネージャ機能を有し、監視アプリケーションのエージェント機能を業務サーバ群１の各サーバにインストールして、サーバの停止や異常処理などの監視イベントを検出する。そして、監視装置１０は、検出した監視イベントをディスプレイ等に表示することで、異常をオペレータに通知する。

監視項目の一例としては、例えば、監視装置１０は、各サーバの死活監視、各サーバの残ディスク容量の監視、各サーバのイベントログ監視、各サービスの起動状態監視、システム動作の監視を実行する。

運用管理装置５０は、業務サーバ群１の各サーバに対して、メンテナンスなどの運用管理操作（運用製品）を実行するサーバの一例である。具体的には、運用管理装置５０は、メンテナンスなどの運用管理操作をワークフローとして自動化し、業務サーバ群１に対して、メンテナンス等を自動で実行する。なお、メンテナンスの一例としては、ハードウェアの交換、パッチ適用、メモリ増設などがある。本実施例では、帳票管理のシステムを構成するＷＦサーバの帳票サービスを停止後にメンテナンス作業を実施し、その後に帳票サービスを起動するというワークフローを実行する。

図３は、実施例１にかかるワークフローを説明する図である。図３に示すように、ワークフローは、運用製品が実行し、ＳＴＡＲＴノードから開始してＥＮＤノードまで１つずつノードを遷移するように制御する。ノードごとに１つの「運用操作部品」を設定し、その運用操作部品の処理が完了すれば次のノードに遷移する。例えば、ノード１の構成情報の収集処理が終了すると、ノード２のサービス停止処理が実行される。ここでは、分岐のないワークフローとなっているが、運用操作部品の実行結果によって処理を分岐させ、異なるノードに遷移させることもできる。

［監視装置の機能構成］
図４は、実施例１にかかる監視装置の機能構成を示す機能ブロック図である。図４に示すように、監視装置１０は、通信部１１、記憶部１２、制御部１５を有する。

通信部１１は、他の装置の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部１１は、業務サーバ群１から監視イベントを受信し、運用管理装置５０からフィルタを受信する。また、通信部１１は、収集した監視イベントを、運用管理装置５０へ送信する。

記憶部１２は、データやプログラムを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、監視イベントＤＢ１３とフィルタリングＤＢ１４を記憶する。

監視イベントＤＢ１３は、業務サーバ群１で検出された監視イベントを記憶するデータベースである。図５は、監視イベントＤＢ１３に記憶される監視イベントの例を示す図である。図５に示すように、各監視イベントは、「イベントＮｏ、レベル、ソース、イベント種別、メッセージ、発生日時、対処フラグ」から構成される。

ここで記憶される「イベントＮｏ」は、監視イベントを識別する識別子であり、発生順に一意に与えられる。「レベル」は、監視イベントの緊急度を示す情報であり、緊急度が高い順に、ＥＲＲＯＲ、ＷＡＲＮＩＮＧ、ＩＮＦＯなどが設定される。「ソース」は、監視イベントの発生元のサーバを示す情報であり、ＷＦサーバやＤＢサーバなどが設定される。なお、ワークフローとは関係がなく、帳票管理システムとは関係のないＸＸサーバであっても、ノイズが検出された場合を考慮して検出対象の監視イベントに含める。

「イベント種別」は、監視イベントの種別を示す情報であり、例えばイベントログ監視、プロセス監視、シナリオ監視、ＭＩＢ（Management Information Base）監視などが設定される。「メッセージ」は、監視イベントで検出されるエラーメッセージを示す。「発生日時」は、監視イベントが発生した日時を示す。「対処フラグ」は、監視イベントに対して障害対応等が実行されたか否かを示す情報である。

図５の１行目の監視イベントは、「ＸＸサーバ」から出力された「イベントログ監視」の「ＥＲＲＯＲ」の監視イベントであり、「２０１６年９月３日、００：０４：０２」に、対処「不要」である「ログローテーションに失敗しました。」のメッセージが出力されたことを示す。

フィルタリングＤＢ１４は、監視イベントをフィルタリングするフィルタを記憶するデータベースである。ここで記憶されるフィルタは、運用管理装置５０によって生成される。なお、記憶されるフィルタについては、後述するので、詳細な説明は省略する。

制御部１５は、監視装置１０全体を司る処理部であり、例えばプロセッサなどである。制御部１５は、監視イベント管理部１６、フィルタリング部１７、画面出力部１８を有する。なお、監視イベント管理部１６、フィルタリング部１７、画面出力部１８は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。

監視イベント管理部１６は、監視機能を実行して、業務サーバ群１の各サーバを監視する処理部である。例えば、監視イベント管理部１６は、各サーバで発生した監視イベントを検出して、監視イベントＤＢ１３に登録する。

フィルタリング部１７は、検出された監視イベントのフィルタリングを実行する処理部である。具体的には、フィルタリング部１７は、フィルタリングＤＢ１４に記憶されるフィルタを用いて、検出された監視イベントのフィルタリングを実行して、当該監視イベントが出力対象か否かを判定する。そして、フィルタリング部１７は、出力対象である場合は、当該監視イベントに関する情報を画面出力部１８に通知し、出力対象ではない場合は、当該監視イベントに関する情報の画面出力部１８への通知を抑制する。

画面出力部１８は、監視イベントをディスプレイなどの表示部に表示する処理部である。例えば、画面出力部１８は、フィルタリング部１７から、出力対象の監視イベントに関する情報として「イベントＮｏ」などを受信すると、該当する監視イベントを監視イベントＤＢ１３から読み出して、ディスプレイなどの表示部に表示する。

［運用管理装置の機能構成］
図６は、実施例１にかかる運用管理装置の機能構成を示す機能ブロック図である。図６に示すように、運用管理装置５０は、通信部５１、記憶部５２、制御部７０を有する。

通信部５１は、他の装置の通信を制御する処理部であり、例えば通信インタフェースなどである。例えば、通信部５１は、監視装置１０から監視イベントを受信し、監視装置１０にフィルタを送信する。

記憶部５２は、データやプログラムを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部５２は、ワークフロー管理ＤＢ５３、変数管理ＤＢ５４、インスタンス管理ＤＢ５５、監視イベント管理ＤＢ５６、イベントパターン管理ＤＢ５７、遷移ルート管理ＤＢ５８、パターンデータ管理ＤＢ５９、フィルタリング管理ＤＢ６０を記憶する。

ワークフロー管理ＤＢ５３は、自動化されたワークフローの実行内容を記憶するデータベースである。図７は、ワークフロー管理ＤＢに記憶されるワークフローの例を示す図である。図７に示すように、ワークフロー管理ＤＢ５３は、ワークフローごとに、「ワークフローＮｏ、部品Ｎｏ、運用操作部品名、操作対象、操作サービス／資源、次の部品Ｎｏ」を記憶する。なお、ここで記憶される情報は、メンテナンス実行者などによって設定される。

「ワークフローＮｏ」は、ワークフローを識別する識別子である。「部品Ｎｏ」は、ワークフローを構成する部品の識別子である。「操作対象」は、部品の操作対象を示す情報であり、「操作サービス／資源」は、部品が操作するサービスや資源を示す情報である。「次の部品Ｎｏ」は、次に実行される部品を示す。

図７の例では、ワークフローＮｏ．１は、０から９９までの部品で構成され、１番目の部品は、部品名が「操作対象／資源の取得」であり、この部品の後に２番目の部品が実行されることを示す。また、部品Ｎｏ．３の部品名「サービス停止確認」は、変数１の変数２に対して実行され、確認結果に応じて、部品Ｎｏ．４と部品Ｎｏ．５に分離することを示す。

変数管理ＤＢ５４は、ワークフローで読み出される変数を管理するデータベースである。図８は、変数管理ＤＢに記憶される変数の例を示す図である。図８に示すように、変数管理ＤＢ５４は、「変数Ｎｏ、インスタンスＮｏ、ノードＮｏ、変数名、変数値」を対応付けて記憶する。なお、ここで記憶される情報は、メンテナンス実行者などによって設定される。

「変数Ｎｏ」は、変数を識別する識別子であり、「インスタンスＮｏ」は、例えば事象や事例などのインスタンスを識別する識別子である。「ノードＮｏ」は、ワークフローで実行されるノードを識別する識別子である。「変数名」は、ワークフローの各部品で読み出される変数の名称であり、「変数値」は、当該変数名に設定される値である。図８の例では、変数ＮＯ．１として、インスタンスＮｏ．１のノードＮｏ．０において、変数値（ｈｏｓｔＡ）の変数１が設定されることを示す。

インスタンス管理ＤＢ５５は、ワークフローごとに、各ワークフローで実行されたインスタンスを記憶するデータベースである。図９は、インスタンス管理ＤＢ５５に記憶されるインスタンスの例を示す図である。図９に示すように、インスタンス管理ＤＢ５５は、「インスタンスＮｏ、ワークフローＮｏ、ノード位置、ノード遷移元、開始日時、終了日時、実行結果（標準出力）、実行結果（復帰値）」などを対応付けて記憶する。ここで記憶される情報は、ワークフローが実行されるたびに、ワークフロー実行部７１によって格納される。

図９の例では、インスタンスＮｏ．１は、ワークフローＮｏ．１のワークフローで実行されたインスタンスであることを示す。また、図９の１行目は、ノード０から遷移したノード１において、２０１６年９月３日００：０４：００から２０１６年９月３日００：０４：０２に実行され、実行結果として「構成情報の取得に成功」が取得され、実行結果が「０（正常）」であることを示す。

監視イベント管理ＤＢ５６は、業務サーバ群１で発生した監視イベントを記憶するデータベースである。ここで記憶される情報は、監視装置１０から取得した情報であり、監視装置１０で管理される情報と同じなので、詳細な説明は省略する。

イベントパターン管理ＤＢ５７は、ワークフローの実行で発生した監視イベントの集計結果を記憶するデータベースである。図１０は、イベントパターン管理ＤＢに記憶されるイベントパターンの例を示す図である。図１０に示すように、イベントパターン管理ＤＢ５７は、「パターンＮｏ、ワークフローＮｏ、ノードＮｏ、操作対象、操作資源、実行回数、データＮｏ、遷移ルート、更新日時」などを対応付けて記憶する。

「パターンＮｏ」は、イベントパターンを識別する識別子であり、「ワークフローＮｏ」は、イベントパターンが発生したワークフローを識別する識別子であり、「ノードＮｏ」は、イベントパターンを発行したノードを識別する識別子である。「操作対象」は、イベントパターンの発生時に操作されたサーバの識別子であり、「操作資源」は、イベントパターンの発生時に操作されたサービスの識別子である。「実行回数」は、イベントパターンの実行回数であり、「データＮｏ」は、詳細内容を特定するときに使用する識別子である。「遷移ルート」は、イベントパターンの順番を示す情報であり、「更新日時」は、最新の更新日時（発生日時）である。

図１０の例では、パターンＮｏ．２は、ワークフローＮｏ．１のノード２において、ＡＰサーバのＷｅｂサービスに対して実行されたときに発生した監視イベントである。この監視イベントは、過去に１４回発生し、遷移ルート１に該当し、データＮｏ．２−４で特定される詳細なイベント内容に該当し、更新日時が２０１６年９月３日の００：０４：００であることを示す。

遷移ルート管理ＤＢ５８は、ワークフロー実行時のノードの遷移ルートを記憶するデータベースである。図１１は、遷移ルート管理ＤＢに記憶される遷移ルートの例を示す図である。図１１に示すように、遷移ルート管理ＤＢ５８は、「遷移ルートＮｏ、ワークフローＮｏ、遷移元ノード、遷移先ノード」を対応付けて記憶する。なお、ここで記憶される情報は、メンテナンス実行者などによって設定される。

「遷移ルートＮｏ」は、遷移ルートを識別する識別子であり、「ワークフローＮｏ」は、ワークフローを識別する識別子である。「遷移元ノード」は、遷移元のノードを識別する識別子であり、「遷移先ノード」は、遷移先のノードを識別する識別子である。図１１の１行目の例は、ワークフローＮｏ．１が有する遷移ルートを示し、ノード０からノード１への遷移を示す情報である。

パターンデータ管理ＤＢ５９は、イベントパターンで発生したパターンの詳細情報を管理するデータベースである。図１２は、パターンデータ管理ＤＢに記憶されるパターンデータの例を示す図である。図１２に示すように、パターンデータ管理ＤＢ５９は、「データＮｏ、イベント種類、メッセージ、ソース、レベル、発生時刻、信頼度、マージン」などを対応付けて記憶する。

「データＮｏ」は、パターンデータを識別する識別子である。「イベント種類」は、監視イベントの種別を示す情報である。「メッセージ」は、当該監視イベントで出力されるメッセージの内容である。「ソース」は、当該監視イベントの発行元のサーバを示す情報である。「レベル」は、発行された監視イベントの危険度を示す情報である。「発生時刻」は、監視イベントの発生時刻である。「信頼度」は、監視イベントがワークフローを起因とするものか否かを示す情報である。「マージン」は、監視イベントの発生時刻の許容範囲を示す情報である。

図１２の例では、データＮｏ．２は、ＡＰサーバで発行されたイベントログ監視の監視イベントであり、「〜サービスを停止します」のメッセージが、危険度「ＩＮＦＯ」で、「００：００：０２」に発行されたことを示す。また、データＮｏ．２のパターンデータには、マージンとして「２」、信頼度として「８０」が設定される。つまり、「００：００：０２」から前後２秒の間で出力された、データＮｏ．２と同じ内容の監視イベントは、データＮｏ．２として扱うことを示す。

フィルタリング管理ＤＢ６０は、監視イベントをフィルタリングするフィルタに関する情報を管理するデータベースである。図１３は、フィルタリング管理ＤＢに記憶されるフィルタの例を示す図である。図１３に示すように、フィルタリング管理ＤＢ６０は、「フィルタＮｏ、イベント種類、メッセージ、ソース、レベル、時刻条件、アクション、繰り返し」などを対応付けて記憶する。

「フィルタＮｏ」は、フィルタを識別する識別子である。「イベント種類」は、監視イベントの種別を示す情報である。「メッセージ」は、当該監視イベントで出力されるメッセージの内容である。「ソース」は、当該監視イベントの発行元のサーバを示す情報である。「レベル」は、発行された監視イベントの危険度を示す情報である。「時刻条件」は、当該監視イベントが出力されると想定される時間帯である。「アクション」は、当該監視イベントの発行時に対応するアクションの内容である。「繰り返し」は、当該フィルタによる制御の繰り返し回数を示す。

図１３の場合、フィルタＮｏ．１は、２０１６年９月３日の００：０４：０１から００：０４：０５の間に、ＡＰサーバから発行された、「〜サービスを停止します」かつ「ＩＮＦＯ」に対応するイベントログの表示を抑制することを示す。

制御部７０は、運用管理装置５０全体を司る処理部であり、例えばプロセッサなどである。制御部７０は、ワークフロー実行部７１とフィルタリング処理部８０を有する。なお、ワークフロー実行部７１とフィルタリング処理部８０は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。

（１．ワークフローの実行）
ワークフロー実行部７１は、ワークフローを実行する処理部である。具体的には、ワークフロー実行部７１は、予め定めた時間に到達した場合やメンテナンス実行者によって開始が指示された場合、図７に示すワークフロー管理ＤＢ５３に記憶されるワークフローの中から、該当するワークフローをＳｔａｒｔノードからＥＮＤノードまで順に実行する。

図１４は、ワークフローの実行処理の流れを示すフローチャートである。図１４に示すように、ワークフロー実行部７１は、Ｓｔａｒｔノードから開始し（Ｓ１０１）、ＥＮＤノードまでＳ１０２からＳ１０７のループ処理を実行する。具体的には、ワークフロー実行部７１は、ワークフロー管理ＤＢ５３から操作対象と操作内容を取得し（Ｓ１０３）、運用操作部品に設定される処理を実行する（Ｓ１０４）。そして、ワークフロー実行部７１は、ノードの処理完了の通知を受信すると（Ｓ１０５）、次のノードへ遷移して（Ｓ１０６）、次の処理を実行する。

（２．フィルタリング制御）
フィルタリング処理部８０は、ワークフローの実行を起因とする監視イベントの出力を抑制するフィルタを生成する処理部である。フィルタリング処理部８０は、イベントパターン読込部８１、イベントパターン生成部８２、突合処理部８３、信頼度判定部８４、一致判定部８５、フィルタリング更新部８６を、イベントパターン更新部８７を有する。

ここでは、全体的な処理の流れを説明した後に、各処理の詳細を説明する。図１５は、イベントパターンの更新処理の全体的な流れを示すフローチャートである。図１５に示すように、フィルタリング処理部８０は、イベントパターン管理ＤＢ５７から該当するイベントパターンを読み込み（Ｓ２０１）、すでに作成済みである監視イベントのイベントパターンと今回新たに出力された監視イベントとを突合する突合処理を実行する（Ｓ２０２）。

その後、フィルタリング処理部８０は、該当するイベントパターンの信頼度が閾値以上である場合（Ｓ２０３：Ｙｅｓ）、イベントパターンの一致判定を実行する（Ｓ２０４）。そして、フィルタリング処理部８０は、類似度が閾値以上である場合（Ｓ２０５：Ｙｅｓ）、フィルタリングを更新し（Ｓ２０６）、イベントパターンを更新する（Ｓ２０７）。なお、フィルタリング処理部８０は、信頼度が閾値未満である場合（Ｓ２０３：Ｎｏ）、Ｓ２０４からＳ２０６を実行せずに、イベントパターンを更新する（Ｓ２０７）。また、フィルタリング処理部８０は、類似度が閾値未満である場合（Ｓ２０５：Ｎｏ）、Ｓ２０６を実行せずに、イベントパターンを更新する（Ｓ２０７）。

（２−１．イベントパターン読込）
イベントパターン読込部８１は、イベントパターン管理ＤＢ５７からイベントパターンの読み込みを実行する処理部である。具体的には、イベントパターン読込部８１は、指定されたワークフローＮｏとインスタンスＮｏとノード位置から、インスタンス管理ＤＢ５５および変数管理ＤＢ５４を検索して、ノードの遷移ルートや設定された変数（対象サーバや制御対象のリソースなど）を取得する。

その後、イベントパターン読込部８１は、イベントパターン管理ＤＢ５７を検索して、取得したインスタンス情報と一致する条件のイベントパターンを取得する。ここで、イベントパターン読込部８１は、例えば初回起動時などイベントパターンが存在しない場合、信頼度は０とする。そして、イベントパターン読込部８１は、イベントパターンの生成し指示をイベントパターン生成部８２に出力する。

一方、イベントパターン読込部８１は、イベントパターンが存在する場合、信頼度をパターンデータ管理ＤＢ５９から取得する。そして、イベントパターン読込部８１は、取得した信頼度がユーザ指定の閾値を下回っている場合については一致判定をしないように制御する。

（２−２．イベントパターンの初回生成）
イベントパターン生成部８２は、イベントパターン読込部８１が読み込む対象のイベントパターンがない場合の初回時に、イベントパターンを生成する処理部である。具体的には、イベントパターン生成部８２は、ワークフローの開始から終了までに発生した監視イベントをグループ化するイベントグループの生成と、過去のワークフロー実行時に発生した監視イベントに基づくイベントグループの生成とを実行する。

まず、イベントパターン生成部８２は、イベントグループの生成を実行する。例えば、イベントパターン生成部８２は、ワークフローの開始から終了までに発生した監視イベントを、図１６のようにノードごとに分割する。このとき、各ノードの開始時間はワークフローの経過時間で表現できる。図１６は、イベントグループ化の分割を説明する図である。図１６に示すように、イベントパターン生成部８２は、ノード毎に、ワークフローの経過時間（開始時刻をＴｆ＝０）、各ノードの経過時間（開始時間をＴｎｘ＝０、ｘはノード）で分割する。

図３のワークフローを例に説明すると、イベントパターン生成部８２は、ノード１の開始から終了、ノード２の開始から終了、ノード３の開始から終了、ノード４の開始から終了に分割する。そして、イベントパターン生成部８２は、分割された各区間において、区間内で発生した監視イベントを時系列に並べる。なお、ワークフローとは関係ない監視イベントが検出された場合を考慮し、帳票管理システムとは関係のない別のＸＸサーバで発生した監視イベントを含めることとする。

各ノードで発生した監視イベントの収集結果を図１７に示す。図１７は、イベントグループの生成を説明する図である。図１７に示すように、ワークフローの実行時に、ノード１では、Ｔｎ１＝１．０のときにＸＸサーバでイベントログが発生し、ノード２では、Ｔｎ２＝３．０のときにＷＦサーバでイベントログが発生し、Ｔｎ２＝５．０のときに監視製品による監視イベントが検出されている。また、ノード３では、Ｔｎ３＝１．０のときにＤＢサーバでイベントログが発生し、Ｔｎ３＝２．０のときにＡＰサーバでイベントログが発生し、Ｔｎ３＝１０．０、５５．５、１１５．０のときに監視製品による監視イベントが検出され、Ｔｎ３＝２０．０と８０．０のときにＸＸサーバでイベントログが発生し、Ｔｎ３＝６０．０のときにＷＦサーバでイベントログが発生した。また、ノード４では、Ｔｎ４＝３．０のときにＷＦサーバでイベントログが発生した。

次に、イベントパターンの生成について説明する。イベントパターン生成部８２は、過去のワークフロー実行時に発生した監視イベントから、実行履歴の数だけイベントグループを生成する（図１０参照）。それらイベントグループ群から統計的な発生パターンを求めることで、特定のワークフロー実行時に発生するイベントパターンを作成することができる。なお、イベントパターンはノードごとに作成し、全ノードのイベントパターンの集合がワークフローのイベントパターンとなる。

なお、図１０のイベントパターンにおいて、ワークフローＮｏとノード位置の情報から、ワークフロー定義を格納したワークフロー管理ＤＢ５３を参照することで、各ノードに設定された運用操作部品を参照できる。また、図１２のパターンデータは、図１７の時系列データを配列として格納したものである。また、信頼度の実態は、パターンデータの配列要素、言い換えると監視イベント単位ごとに保持する値である。

続いて、イベントパターンの生成手順を説明する。第１に、イベントパターン生成部８２は、指定されたワークフローＮｏの定義情報を解析し、実行するノードの一覧を取得する。図３の例では、イベントパターン生成部８２は、ノード１（構成情報を取得）、ノード２（サービスを停止）、ノード３（Activity）、ノード４（サービスを起動）の４つを取得する。

第２に、イベントパターン生成部８２は、取得したワークフローＮｏとノード番号からでワークフロー（運用製品）の実行ログを検索し、過去に該当ノードを実行した日時、操作対象、操作資源などを取得する。第３に、イベントパターン生成部８２は、取得した実行ログのうち、操作対象や操作資源などの条件が合致する履歴の数だけ、以下の処理１−２を繰り返す。処理１：実行日時の開始から次ノード開始の期間で発生したすべての監視イベントを監視製品のログから検索する処理。処理２：イベントグループの生成処理。

最後に、イベントパターン生成部８２は、複数のイベントグループから統計的なパターンを求め、ノードごとにイベントパターンを生成する。図１８は、イベントグループ群を説明する図である。図１８は、横軸を経過時間とし、時系列に発生イベントを示している。また、網掛け等は、イベント種別により区別される。

図１８の（ａ）は、ワークフローＮｏ．１００のノード２のイベントグループを説明する図である。ノード２の「サービスを停止」について、７回分のイベントグループが存在したとしても、呼び出し時のパラメータ（操作対象や操作資源）の違いから、帳票サービスを対象とした５回分のデータを用いる。図１８の（ａ）は、過去にワークフローＮｏ．１００を数回実行したときに、インスタンスＮｏ．１０、２０、３０、４０、５０のそれぞれにおいて出力された監視イベントを表す。

ノード２の「サービスを停止」について、残りの２回分のデータを用いて作成したイベントパターンを図１８の（ｂ）に示す。図１８の（ｂ）は、過去にワークフローＮｏ．１００を数回実行したときに、インスタンスＮｏ．３５、４５のそれぞれにおいて出力された監視イベントを表す。

図１８に示すイベントパターンを生成した結果、点線枠（×印）で示したような特定のイベントグループにのみ存在する監視イベントは、運用操作部品の処理によって発生したものではないと判定することができる。つまり、ノイズであるとして、イベントパターンに含めない。このノイズについては、回数を重ねることによって全体に与える影響が小さくなる。

また、点線枠（矢印）で示したような、ノードの境界に位置する監視イベントについては、イベントパターンによって「サービスを停止」部品側のノードに含まれる場合と、次ノードに含まれる場合が考えられる。これは、運用製品と監視製品それぞれ別のログ情報を用いるために発生する。このような境界付近の監視イベントについては、マージン区間を設けることで、境界で分断されないように判定を行う。なお、図１８では次ノードのみを示しているが、実際には前ノードとのマージンについても同様に考慮する。

そして、イベントパターン生成部８２は、ノードごとに、呼び出し元ワークフローや対象サーバを考慮したイベントパターンを作成する。図１９は、生成されたイベントパターンを説明する図である。図１９は、図１８に示したイベントグループに基づいて生成したイベントパターンである。図１９に示すように、帳票サービスについては、インスタンスＩＤ＝１０、２０、３０、４０、５０で共通する２つの監視イベントがイベントパターンに登録され、Ｗｅｂサービスについては、インスタンスＩＤ＝３５、４５で共通する６つの監視イベントがイベントパターンに登録される。つまり、これらのイベントパターンが、表示抑制対象の監視イベントとなる。

（２−３．突合処理）
図６に戻り、突合処理部８３は、イベントパターン読込部８１によってイベントパターンが読み込まれた場合に、ワークフロー管理ＤＢ５３に記憶される情報と監視イベント管理ＤＢ５６に記憶される情報を突き合せ、運用操作実行中に発生した監視イベント一覧を取得する処理部である。具体的には、突合処理部８３は、運用操作を行った日時をスタートして、ワークフローと発生した監視イベントとの突合を行い、イベントグループを生成する。

図２０は、突合処理の流れを示すフローチャートである。図２０に示すように、突合処理部８３は、開始時間を計算する（Ｓ３０１）。例えば、突合処理部８３は、指定されたワークフローＮｏとインスタンスＮｏとノード位置を用いて、ワークフロー管理ＤＢ５３を検索し、インスタンス情報に含まれる該当ノードの開始日時を取得する。その後、突合処理部８３は、イベントパターン情報に含まれる「最初の監視イベントの発生日時マージン値」を取得し、そのマージンを含めた値を設定する。

続いて、突合処理部８３は、終了時間を計算する（Ｓ３０２）。例えば、突合処理部８３は、指定されたワークフローＮｏとインスタンスＮｏとノード位置を用いて、ワークフロー管理ＤＢ５３を検索し、インスタンス情報に含まれる該当ノードの終了日時を取得する。その後、突合処理部８３は、イベントパターン情報に含まれる「最後の監視イベントの発生日時マージン値」を取得し、そのマージンを含めた値を設定する。

そして、突合処理部８３は、監視イベント管理ＤＢ５６に記憶される監視イベントを、日時指定で検索する（Ｓ３０３）。例えば、突合処理部８３は、Ｓ３０１で取得した開始日時からＳ３０２で取得した終了日時との間に発生したすべての監視イベントを取得する。

その後、突合処理部８３は、監視イベントが存在する場合（Ｓ３０４：Ｙｅｓ）、イベントグループを生成し（Ｓ３０５）、監視イベントが存在しない場合（Ｓ３０４：Ｎｏ）、処理を終了する。例えば、突合処理部８３は、取得された監視イベントの一覧から、監視イベントをノード開始時からの相対時間で時系列に並べた監視イベントの配列を作成する。なお、イベントグループの生成の詳細は、図１６から図１８と同様なので、詳細な説明を省略する。

（２−４．信頼度の判定処理）
信頼度判定部８４は、イベントパターン読込部８１で読み込まれたイベントパターンの信頼度が閾値以上か否かを判定する処理部である。具体的には、信頼度判定部８４は、該当するイベントパターンに設定されるデータＮｏを特定する。続いて、信頼度判定部８４は、特定したデータＮｏに該当するパターンデータをパターンデータ管理ＤＢ５９から検索する。そして、信頼度判定部８４は、検索されたパターンデータに設定される信頼度が閾値以上か否かを判定する。

つまり、読み込まれたイベントパターンが信頼度の高いイベントパターンである場合にのみ、当該監視イベントの抑制判定の可否を判定する。ここで、詳細については後述するが、信頼度は、「過去のワークフロー実行時に発生していた」ことを統計情報として信頼する度合いを示す情報である。つまり、信頼度は、実行回数ごとのイベントパターンに相関がある場合は高く、相関がない場合は低くなる。この値を考慮することで、１度しか発生していないイベントパターンを採用してしまうケースを防ぐことができる。ノイズの影響を受けることで、運用開始時は信頼性が低下するが、同じ環境で実行回数（母数）を増やしていくことで向上する。

（２−５．一致処理）
一致判定部８５は、イベントパターン読込部８１によって新たに生成されたイベントグループと、イベントパターン読込部８１によってイベントパターン管理ＤＢ５７から読み込まれたイベントパターンとの一致判定を行い、類似度を計算する処理部である。具体的には、一致判定部８５は、ワークフローの実行によって発生したイベントグループと、イベントパターン管理ＤＢ５７に登録されるイベントパターンとを照合し、過去の運用操作によって発生したイベントを検出する。イベントグループはノードごとに分割されているので、一致判定部８５は、各ノードの運用操作部品のイベントグループとそれぞれ一致判定をする。一致判定部８５は、この判定の確からしさは類似度として計算する。過去のデータと一致しない場合、類似度は低くなる。

つまり、一致判定部８５は、今回のワークフローの実行時に生成されたイベントグループに含まれる各監視イベントが、過去のワークフローの実行時に検出された監視イベントと類似するか否かを判定する。そして、一致判定部８５は、類似する場合は、今回のワークフローの実行時に検出された監視イベントの起因を、ワークフローの実行と判定する。すなわち、一致判定部８５は、その監視イベントを表示抑制対象と判定することができる。

図２１は、一致処理の流れを示すフローチャートである。図２１に示すように、一致判定部８５は、一致フラグを初期化する（Ｓ４０１）。例えば、一致判定部８５は、イベントパターンのイベントグループの比較結果を格納する領域を初期化する。

続いて、一致判定部８５は、イベントパターンのすべての監視イベントについてＳ４０２からＳ４０５のループ処理を実行する。具体的には、一致判定部８５は、マージン区間内に同一の監視イベントが存在するか否かを判定する（Ｓ４０３）。そして、一致判定部８５は、同一の監視イベントが存在する場合（Ｓ４０３：Ｙｅｓ）、一致フラグをＯＮにし（Ｓ４０４）、同一の監視イベントが存在しない場合（Ｓ４０３：Ｎｏ）、次の監視イベントについて判定を実行する。

監視イベントには、運用操作時の環境の変化や監視製品の検出タイミングのズレによって一致と判断されないイベントが存在する。そのため、一致フラグが残存するイベントパターンについて、（１）イベントパターンの時間の長さを正規化する処理、（２）イベントの発生時刻をスライド移動する処理、（３）繰り返し検出されているイベントを１つに統合する処理、（４）ユーザ指定で無視すると定義されているイベントを対象外にする処理の各処理を実行する。なお、このループ処理はイベントパターン中で信頼度の高い監視イベントの順に実施する。

そして、ループ処理が終了すると、一致判定部８５は、類似度を計算する（Ｓ４０６）。具体的には、一致判定部８５は、一致フラグがＯＮの監視イベントを、該当のイベントパターンと一致するように補正する。そして、一致判定部８５は、補正後のイベントグループとイベントパターンを比較し、類似度を計算する。

類似度とは、イベントグループが過去のイベントパターンと共通している度合いを示す値であり、監視イベントの発生源やタイミングに相関がある場合は高く、相関がない場合は低くなる。例えば、一致判定部８５は、相関係数を用いた「Ｓｉ＝１００×（ｆ（Ａｉ，Ａｐ（ｉ−１））＋１）／２」によって、相関係数を算出する。

ここで、Ｓｉはｉ番目のイベントグループとｉ−１番目のイベントパターンの類似度であり、ｆは相関関数であり、−１から１の範囲で値を返す。Ａｉはｉ番目のイベントグループであり、Ａｐｉはｉ番目のイベントパターンである。なお、ｉ番目のイベントグループについては、実行回数ごとのずれを考慮して、所定の補正を行ったものを用いることができる。所定の補正の一例としては、ノード開始から終了までの時間の正規化（イベントパターンに合わせて縮尺）、監視イベントの発生時間スライド、複数発生している監視イベントの統合、その他ユーザ定義している判定不要イベントの除外などがある。

（２−６．フィルタ更新処理）
図６に戻り、フィルタリング更新部８６は、一致判定によって運用操作に伴って発生した監視イベントの表示抑制を実行するフィルタリングデータ（フィルタ）を作成または更新する処理部である。具体的には、フィルタリング更新部８６は、信頼度判定部８４によって信頼度が閾値以上と判定され、一致判定部８５によって類似度が閾値以上と判定された監視イベントのイベントパターンの表示を抑制するためのフィルタルールを生成したり、既存のフィルタに当該フィルタルールを追加したりする。

図２２は、一致判定の結果を説明する図である。図２２は、ワークフローを実行したタイミングで表示された１２個の監視イベントをしている。このうち、ＸＸサーバのイベントログで検出された３個の監視イベント以外は、過去のワークグループを実行したときに出力されたイベントパターンと一致すると判定されたとする。この場合、フィルタリング更新部８６は、ＸＸサーバで検出された３個の監視イベントのみを表示し、それ以外の表示を抑制するフィルタを生成する。つまり、Ｔｎ１＝１．０、Ｔｎ３＝２０．０、Ｔｎ３＝８０．０の監視イベントのみが表示出力される。

すなわち、信頼度と類似度が閾値以上の場合のみ、一致したと判断される。これは、信頼できる過去データから作成したイベントパターンと、発生したイベントグループに高い相関が見られることを意味する。この場合は、フィルタリング更新部８６は、過去に行った対処に従い、監視イベントを抑制するなど自動的に対処する。なお、この閾値は利用者が設定することも可能である。

なお、抑制するのはイベントパターンにあり、かつ過去に対処不要としている監視イベントのみである。図２２の場合では、「サービスの停止」部品によって発生した監視イベントはイベントパターンと一致しているため、正しく抑制される。また、他の運用操作部品についても監視設定から発生する監視イベントであり、イベントパターンに含まれるため、同じく抑制される。図２２では、このように抑制する監視イベントを、×マークで記載している。一方で、「構成要素を取得」部品やメンテナンス作業については、それぞれの運用操作部品のイベントパターンに含まれない、言い換えるとこのワークフローの操作以外の要因で発生している。このようなノイズについては意図したとおり抑制しない。

そして、フィルタリング更新部８６は、生成したフィルタを監視装置１０に送信し、監視装置１０は、フィルタによってフィルタリングを実行する。図２３は、フィルタリングを説明する図である。図２３に示すように、運用管理装置５０は、サーバ群にワークフローを実行する。この実行に伴って、監視装置１０は、Ｔｎ１＝１．０、Ｔｎ２＝３．０、Ｔｎ２＝５．０、Ｔｎ３＝１．０、Ｔｎ３＝２．０、Ｔｎ３＝１０．０、Ｔｎ３＝２０．０などの監視イベントを検出する。

これと並行して、運用管理装置５０は、実行結果および検出結果を用いて、イベントパターンとの一致判定をもとに、フィルタリングの生成および更新を実行して、監視装置１０に送信する。そして、監視装置１０は、更新されたフィルタリングを適用して、検出したＴｎ１＝１．０、Ｔｎ２＝３．０、Ｔｎ２＝５．０、Ｔｎ３＝１．０、Ｔｎ３＝２．０、Ｔｎ３＝１０．０、Ｔｎ３＝２０．０などの監視イベントのうち、Ｔｎ１＝１．０とＴｎ３＝２０．０の監視イベントのみを対処要と表示する。もしくは、監視装置１０は、Ｔｎ１＝１．０とＴｎ３＝２０．０以外の監視イベントを対処不要と表示する。

（２−７．イベントパターンの更新処理）
イベントパターン更新部８７は、今回のワークフローの対象としたイベントグループの情報を用いて、イベントパターンを更新する処理部である。イベントパターンは、必ずしもワークフローの開始に伴って再作成しなくてもよい。あらかじめ作成済みのイベントパターンは、イベントパターン管理ＤＢ５７に登録してあるので、これを更新することで計算量や計算時間を低減することができる。このような差分アップデートの場合、作成済みのイベントパターンと発生したイベントグループの比較または統合によって、イベントパターンを更新する。なお、 通常は登録済みイベントパターンを用いて計算し、これとは別に定期的にイベントパターンを再作成することで、「過去に発生していた監視イベント」を最新に保つことができる。

図２４は、イベントパターンの更新処理の流れを示すフローチャートである。イベントパターン更新部８７は、イベントグループを読み込み（Ｓ５０１）、イベントパターンを読み込む（Ｓ５０２）。例えば、イベントパターン更新部８７は、イベントパターン管理ＤＢ５７から更新元のイベントパターンを読み込み、今回のメンテナンスで検出されたイベントグループを各処理部から取得する。

続いて、イベントパターン更新部８７は、取得したイベントパターンの各監視イベントについて、Ｓ５０３からＳ５０７のループ処理を実行する。具体的には、イベントパターン更新部８７は、イベントパターンとイベントグループとの間で、一致する監視イベントがある場合（Ｓ５０４：Ｙｅｓ）、発生時刻およびマージンを更新し（Ｓ５０５）、信頼度を更新する（Ｓ５０６）。なお、イベントパターン更新部８７は、イベントパターンとイベントグループとの間で、一致する監視イベントがない場合（Ｓ５０４：Ｎｏ）、Ｓ５０５を実行することなく、Ｓ５０６を実行する。

例えば、発生時刻は、最新の時刻に更新する。マージンの更新値は、実行回数が重みとなり、過去への影響を考慮して、「（実行回数×イベントパターンの値＋イベントグループの値）／（実行回数＋１）」で更新する。また、イベントパターン更新部８７は、すべてのイベントグループの監視イベントについて、イベントパターンの信頼度を更新する。発生時刻、マージンの場合と同じく、更新値は実行回数が重みとなるが、基本的に一致すれば増え、一致しなければ下がる。

ここで、信頼度について説明する。イベントパターンは漸化処理で求める。つまり、実行回数がｉ番目のイベントパターンは、ｉ−１番目のイベントパターンと、ｉ番目に発生したイベントグループから求める。また、イベントパターン全体の信頼度は、イベントパターン中の各監視イベントがもつ信頼度の平均となる。監視イベント単位の信頼度は、出現回数／試行回数で計算できる。例えば、ｎ回中ｍ回のときは、「ｎ／ｍ×１００」であり、毎回発生する場合は１００となる。ただし、実行回数ごとに信頼度に与える影響が異なることを考慮し、「過去に発生したデータの影響を小さくするように、時間依存で減少させる補正」や「ユーザ対処があったときの影響を大きくするように、対処結果依存で増加または減少させる補正」を実行することもできる。

（２−８．イベントパターンの生成処理）
イベントパターン更新部８７は、ワークフローの実行に依存することなく、予め指定した間隔や管理者が指定した間隔で、イベントパターン管理ＤＢ５７に記憶されるイベントパターンの再作成を実行する処理部である。

例えば、イベントパターン更新部８７は、ワークフローの実行と並行して処理を行うこともできる。新規作成と異なる点は、ノード遷移をするたびに通知され、その通知をトリガーとしてノード単位でイベントパターン作成時することである。信頼度の計算方法についての異なる点は、イベントグループ作成時にはそのタイミングまでに発生した監視イベントのみ存在するが、対処不要や対処済みなどのユーザ対処の有無を取得できない点である。

図２５は、イベントパターンの再生成処理の流れを示すフローチャートである。図２５に示すように、イベントパターン更新部８７は、管理者等によって指定された回数だけ、Ｓ６０１からＳ６０６のループ処理を実行する。具体的には、イベントパターン更新部８７は、ｉを変数、初期値を指定値、繰り返し回数を試行回数として、ループ処理を実行する。例えば、イベントパターン更新部８７は、ｉ番目のイベントグループを生成し（Ｓ６０２）、ｉ番目とイベントグループとイベントパターンの一致判定を実行し（Ｓ６０３）、補正付き信頼度を計算した後（Ｓ６０４）、イベントパターンを更新する（Ｓ６０５）。

より詳細には、イベントパターンの再作成では、試行回数だけ「イベントグループの作成」と「一致判定」、「イベントパターン更新」を繰り返し行う。上述したイベントパターンの初期生成と異なり、運用管理製品と監視製品のデータ保持期間の関係上、ワークフロー管理ＤＢ５３のインスタンス情報にあるが監視イベントに存在しない、または、その逆が考えられるので、試行回数の開始タイミングを、何ヶ月前からまたは何回目から指定する。

また、信頼度に過去情報に関する補正を付けることができる。したがって、補正付き信頼度Ｒｉ´は、補正無し信頼度Ｒｉを計算するときに、所定の係数を乗算することで求めることができる。例えば、時間の係数であり、現在からの過去のデータであるほど減衰する曲線となる「Ｋｔ（ｉ）」、ユーザ対処による教示の係数であり、ユーザが対処不要とした回のイベントグループの影響を強く反映するように設定する「Ｋｕ（ｉ）」などの係数を用いる。

［効果］
運用管理装置５０は、メンテナンスなどの運用操作によって発生する監視イベントをパターン化して、イベントパターンとして記録できる。運用管理装置５０は、上記イベントパターンの信頼度および、イベントパターンとの相関を示す類似度によって運用管理特有の情報の不確かさを表現することができる。運用管理装置５０は、上記イベントパターンに基づいて、事前定義なしに指定のワークフローによって発生する監視イベントを抑制するフィルタリングルールを生成することができる。

運用管理装置５０は、監視製品や運用製品のログからフィルタリングルールを自動生成するため、定義による管理が不要であり大規模環境にも適応ができる。また、監視アプリケーションのエージェントを必要としないため、監視アプリケーションのエージェントを業務サーバにインストールできない環境でも適応できる。運用管理装置５０は、ワークフローの動作安定度を「信頼度」として定量的に示すことができる。利用者はこの数値が低ければ、環境もしくはワークフローに問題があると認識することができる。

運用管理装置５０は、ワークフローによって発生する監視イベントのみを抑制することができる。自明かつ大量の監視イベントの確認が不要となり、手動操作や障害によって発生したイベントのみを確認することができる。オペレータの負担は低減され、監視イベントの見逃しや対応への遅れが発生する可能性を低減できる。

［比較］
一般的に、ワークフローで運用操作を行った場合、発生する監視イベントは、対象サーバから操作後すぐに発生するものだけでなく、関連するサーバやある程度時間が経ってから発生するものがある。部品の実行によって直接的に発生する監視イベントについては、操作と現象が明らかであることから、オペレータの負担も少なく、監視対象外と判定することができるが、部品の実行によって間接的に発生する監視イベントについては、オペレータで判断することが難しい。運用管理装置５０では、イベントグループとして判定することで、監視イベントを統合的に判断するが、それでもまだ、ワークフローを実行するごとに異なるイベントグループが発生する可能性もある。

つまり、他のサーバから発生する監視イベントの有無、監視製品のリトライやインターバルの設定による監視イベントの発生タイミングのズレ、対象サーバや関連サーバ上アプリの状態による、発生する監視イベントの有無などのノイズがあるので、同じ対象サーバに、同じ論理構成で、同じワークフローを実行した場合であっても、必ずしも同じイベントパターンなるとは限らない。その結果、実行履歴から正しくイベントパターンを作成することができず、過去のワークフロー実行期間に発生していたかどうかの判定が難しいこともある。つまり、監視イベントを正しく抑制できないこともある。

ところが、運用管理装置５０は、実行履歴におけるイベントグループ間の相関を「信頼度」として、イベントグループとイベントパターン間の相関を「類似度」として示すことで、ノイズの除去を行っている。また、監視製品による監視イベントの検出タイミングの変化など、同じ運用の範囲で発生しうるイベントグループの変動に対しては許容するように信頼度を計算することで対応している。したがって、運用管理装置５０は、上記ノイズを正確に特定して、イベントパターンの対象外とすることができるので、監視イベントを正しく抑制できる。

さらに、運用管理装置５０は、「信頼度」が閾値以上でなければフィルタリングによる抑制を行わないので、過剰な抑制を軽減できる。また、運用管理装置５０は、イベントグループ間の相関を評価するにあたって、ワークフローで発生する監視イベントのイベントパターンの変化が早く収束するように、実行履歴のうち古いイベントグループほど影響が小さくなるように導出することもできる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。

［判定材料］
上記実施例では、信頼度を用いる例を説明したが、これに限定されるものではなく、例えば過去の実行回数などを用いることもでき、信頼度等の情報を用いずに、イベントパターンだけで判定することもできる。

［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。なお、監視装置１０と運用管理装置５０は１つの筐体で実現することもできる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［ハードウェア構成］
運用管理装置５０と監視装置１０は、同様のハードウェア構成を有するので、ここでは、情報処理装置１００として説明する。図２６は、ハードウェア構成例を示す図である。図２６に示すように、情報処理装置１００は、通信インタフェース１００ａ、ＨＤＤ（Hard Disk Drive）１００ｂ、メモリ１００ｃ、プロセッサ１００ｄを有する。

通信インタフェース１００ａは、他の装置の通信を制御するネットワークインタフェースカードなどである。ＨＤＤ１００ｂは、プログラムやデータなどを記憶する記憶装置の一例である。

メモリ１００ｃの一例としては、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。プロセッサ１００ｄの一例としては、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、ＰＬＤ（Programmable Logic Device）等が挙げられる。

また、情報処理装置１００は、プログラムを読み出して実行することでフィルタリング方法を実行する情報処理装置として動作する。つまり、情報処理装置１００は、ワークフロー実行部７１とフィルタリング処理部８０と同様の機能を実行するプログラムを実行する。この結果、情報処理装置１００は、ワークフロー実行部７１とフィルタリング処理部８０と同様の機能を実行するプロセスを実行することができる。なお、この他の実施例でいうプログラムは、情報処理装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ（Magneto−Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。

５０ 運用管理装置
５１ 通信部
５２ 記憶部
５３ ワークフロー管理ＤＢ
５４ 変数管理ＤＢ
５５ インスタンス管理ＤＢ
５６ 監視イベント管理ＤＢ
５７ イベントパターン管理ＤＢ
５８ 遷移ルート管理ＤＢ
５９ パターンデータ管理ＤＢ
６０ フィルタリング管理ＤＢ
７１ ワークフロー実行部
８０ フィルタリング処理部
８１ イベントパターン読込部
８２ イベントパターン生成部
８３ 突合処理部
８４ 信頼度判定部
８５ 一致判定部
８６ フィルタリング更新部
８７ イベントパターン更新部

Claims (6)

1. サーバの監視に関するイベントを取得すると、取得した前記イベントに関する情報を端末に通知する監視プログラムにおいて、
   前記サーバの運用に関する処理の識別情報と、該サーバの監視に関するイベントのうち該サーバの運用に関する処理の実行中に発生したイベントと、を取得し、
   前記サーバの運用に関する処理で発生するイベントの発生パターンを示すイベントパターンごとに、当該イベントパターンに含まれる前記サーバの運用に関する処理に起因して発生したイベントと該処理の識別情報と前記イベントパターンの信頼度とを対応付けて記憶する記憶部を参照して、取得された各識別情報に対応付けられた各イベントの発生順に基づいて、前記イベントの通知判定に利用する該当イベントパターンを特定し、
   前記該当イベントパターンの信頼度が閾値未満である場合には、取得された前記各イベントに関する情報の通知を実行し、前記該当イベントパターンの信頼度が閾値以上である場合には、取得した前記各イベントのうち、前記該当イベントパターンに含まれるイベントに関する情報の通知を抑制する、
   処理をコンピュータに実行させることを特徴とする監視プログラム。
2. 前記サーバの運用に関する処理である運用処理が過去に実行されたときに出力された複数のイベントを収集し、
   収集された前記複数のイベントの種別および発生時刻にしたがって、前記運用処理に起因して発生するイベントの出力パターンを生成して前記記憶部に格納する処理を前記コンピュータにさらに実行させ、
   前記特定する処理は、前記記憶部に記憶される複数のイベントパターンのうち、前記出力パターンに該当する前記該当イベントパターンを特定することを特徴とする請求項１に記載の監視プログラム。
3. 前記格納する処理は、前記出力パターンに含まれる各イベントに対して、前記運用処理が過去に実行されたときに当該イベントが出力された出力回数に基づく信頼度を算出し、算出した信頼度を前記出力パターンの各イベントに対応付けて前記記憶部に格納し、
   前記抑制する処理は、取得した前記運用処理の識別情報に対応付けられたイベントのうち、前記出力パターンに含まれる閾値以上の信頼度を有するイベントと一致するイベントに関する情報の通知を抑制することを特徴とする請求項２に記載の監視プログラム。
4. 前記運用処理を新たに実行するたびに、前記運用処理の実行中に発生した複数のイベントを取得し、取得した前記複数のイベントの種別および発生時刻にしたがって、前記運用処理に起因して発生するイベントの出力パターンを生成し、
   生成した前記出力パターンが前記記憶部に記憶されていない場合、前記運用処理を起因とするイベントの新たな出力パターンとして登録する処理を前記コンピュータにさらに実行させることを特徴とする請求項２または３に記載の監視プログラム。
5. サーバの監視に関するイベントを取得すると、取得した前記イベントに関する情報を端末に通知する監視方法において、
   前記サーバの運用に関する処理の識別情報と、該サーバの監視に関するイベントのうち該サーバの運用に関する処理の実行中に発生したイベントと、を取得し、
   前記サーバの運用に関する処理で発生するイベントの発生パターンを示すイベントパターンごとに、当該イベントパターンに含まれる前記サーバの運用に関する処理に起因して発生したイベントと該処理の識別情報と前記イベントパターンの信頼度とを対応付けて記憶する記憶部を参照して、取得された各識別情報に対応付けられた各イベントの発生順に基づいて、前記イベントの通知判定に利用する該当イベントパターンを特定し、
   前記該当イベントパターンの信頼度が閾値未満である場合には、取得された前記各イベントに関する情報の通知を実行し、前記該当イベントパターンの信頼度が閾値以上である場合には、取得した前記各イベントのうち、前記該当イベントパターンに含まれるイベントに関する情報の通知を抑制する、
   処理をコンピュータが実行することを特徴とする監視方法。
6. サーバの監視に関するイベントを取得すると、取得した前記イベントに関する情報を端末に通知する監視装置において、
   前記サーバの運用に関する処理の識別情報と、該サーバの監視に関するイベントのうち該サーバの運用に関する処理の実行中に発生したイベントと、を取得する取得部と、
   前記サーバの運用に関する処理で発生するイベントの発生パターンを示すイベントパターンごとに、当該イベントパターンに含まれる前記サーバの運用に関する処理に起因して発生したイベントと該処理の識別情報と前記イベントパターンの信頼度とを対応付けて記憶する記憶部を参照して、取得された各識別情報に対応付けられた各イベントの発生順に基づいて、前記イベントの通知判定に利用する該当イベントパターンを特定する特定部と、
   前記該当イベントパターンの信頼度が閾値未満である場合には、取得された前記各イベントに関する情報の通知を実行し、前記該当イベントパターンの信頼度が閾値以上である場合には、取得した前記各イベントのうち、前記該当イベントパターンに含まれるイベントに関する情報の通知を抑制する抑制部と
   を有することを特徴とする監視装置。

Images