JP2021179830A

JP2021179830A - 監視システム、監視装置及び監視方法

Info

Publication number: JP2021179830A
Application number: JP2020085162A
Authority: JP
Inventors: あやめ古賀; Ayame Koga; 一紀大坪; Kazunori Otsubo; 安彰齋藤; Yasuaki Saito
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2020-05-14
Filing date: 2020-05-14
Publication date: 2021-11-18
Anticipated expiration: 2040-05-14
Also published as: US20210357301A1; JP7012778B2

Abstract

【課題】監視対象システムにおける障害発生時の状況把握、及び対処の迅速化できる監視システムを提供する。【解決手段】監視システム１０は、ネットワークを介して監視対象システム２０に接続され、表示部３１、通知部３２、優先度算出部３３、イベント分析部３４、対処履歴管理部３５、構成管理部３６、イベント管理部３７を有する。イベント管理部は、監視対象システムで発生した複数のイベントを管理する。イベント分析部は、監視対象システムの構成、複数のイベントの発生タイミング及び過去に行った対処の実績に基づいて複数のイベントを分析し、関連して発生したイベントを同一のグループに分類する。通知部は、複数のイベントをグループ毎に通知する。【選択図】図１

Description

本発明は、監視対象システムを監視する監視システム、監視装置及び監視方法に関する。

従来、業務を支援するシステムとして、例えば特開２００７‐２１３２９４号公報（特許文献１）に開示の技術がある。この公報には、「生産計画を立案する際に、生産職場に対して、各職場で生産能力が固定の期間、職場間で作業者の融通が可能な期間、人員の新規採用で生産能力を考慮しなくてよい期間を考慮しながら、生産能力を調整しながら実行可能な生産計画を作成する。」という記載がある。このように、様々な業務の自動化・最適化やスマート化、またそれを支えるインフラ機器の仮想化技術の発展に伴い、ＩＴシステムは大規模・複雑化している。

特開２００７‐２１３２９４号公報

上記特許文献１によれば、生産計画を立案する際に作業者の職場配置を考慮しながら実行可能な生産計画の立案を可能にすることができる。このようなシステムでは、システムの構成要素、例えばサーバやストレージで障害等が発生した場合に、異常を通知するイベントが生成される。

しかしながら、大規模なシステムでは、多くの構成要素が複雑に関係することになるため、複数のイベントが発生した場合に、障害箇所の把握やイベント間の関連の把握が困難となり、迅速な対処が難しくなるという課題があった。

そこで、本発明では、監視対象システムにおける障害発生時の状況把握、及び対処の迅速化を目的とする。

上記目的を達成するために、代表的な本発明の監視システム及び監視装置の一つは、監視対象システムで発生した複数のイベントを管理するイベント管理部と、前記監視対象システムの構成、前記複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて前記複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析部と、前記複数のイベントを前記グループごとに通知する通知部とを備える。
また、代表的な本発明の監視方法の一つは、監視対象システムで発生した複数のイベントを管理するイベント管理ステップと、前記監視対象システムの構成、前記複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて前記複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析ステップと、前記複数のイベントを前記グループごとに通知する通知ステップとを含む。

本発明によれば、監視対象システムにおける障害発生時の状況把握、及び対処の迅速化が実現できる。
上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。

実施例に係る監視システムの構成図。監視対象システムの構成を示す構成図。監視システムのデータの具体例を示す図。（その１）監視システムのデータの具体例を示す図。（その２）監視システムのデータの具体例を示す図。（その３）監視システムのデータの具体例を示す図。（その４）監視システムの処理手順を示すフローチャート。図７に示したイベントのグルーピング処理の詳細を示すフローチャート。図８に示した時間的距離の算出の詳細を示すフローチャート。図８に示した対処履歴からの距離の算出の詳細を示すフローチャート。図８に示した最終的な距離の算出とグルーピングの詳細を示すフローチャート。図７に示した優先度の算出の詳細を示すフローチャート。図１２に示したファクターの値の算出の詳細を示すフローチャート。図１２に示した優先度の決定の詳細を示すフローチャート。図７に示した表示出力の詳細を示すフローチャート。表示の具体例についての説明図。図７に示したパラメータ調整の詳細を示すフローチャート。

以下、本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明において、「ｘｘｘテーブル」といった表現により、入力に対して出力が得られる情報を説明することがあるが、この情報は、どのような構造のデータでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。

また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明において、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及び／又はインタフェース部などを用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有するコントローラのようなデバイス）とされてもよい。

プログラムは、計算機のような装置にインストールされてもよいし、例えば、プログラム配布サーバ又は計算機が読み取り可能な（例えば非一時的な）記録媒体にあってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、「プロセッサ部」は、１又は複数のプロセッサである。プロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。また、プロセッサは、シングルコアでもよいしマルチコアでもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以下の説明において、種々の対象の識別情報として、識別番号が使用されるが、識別番号以外の種類の識別情報（例えば、英字や符号を含んだ識別子）が採用されてもよい。

また、以下の説明において、同種の要素を区別しないで説明する場合には、参照符号（又は、参照符号のうちの共通符号）を使用し、同種の要素を区別して説明する場合は、要素の識別番号（又は参照符号）を使用することがある。

図１は、実施例に係る監視システムの構成図である。図１に示すように、監視システム１０は、ネットワークを介して監視対象システム２０に接続される。また、監視システム１０は、その内部に表示部３１、通知部３２、優先度算出部３３、イベント分析部３４、対処履歴管理部３５、構成管理部３６、イベント管理部３７を有する。さらに監視システム１０は、構成情報ＤＢ（database）４１、分析パラメータＤＢ４２、対処履歴ＤＢ４３、人財管理ＤＢ４４及びイベントＤＢ４５を有する。

構成情報ＤＢ４１は、監視対象システム２０の構成に関する情報を保持するデータベースである。分析パラメータＤＢ４２は、監視対象システム２０で発生したイベントを分析する際に用いる各種パラメータを保持するデータベースである。対処履歴ＤＢ４３は、監視対象システム２０に生じたイベントの対処の履歴を保持するデータベースである。人財管理ＤＢ４４は、監視システム１０の操作者を含む人財に関する情報を保持するデータベースである。イベントＤＢ４５は、監視対象システム２０で発生したイベントを保持するデータベースである。

表示部３１は、例えば液晶パネルなどであり、操作者に対する表示出力に用いられる。通知部３２は、表示部３１における表示画面を生成することで、操作者に対する通知の内容を制御する処理部である。優先度算出部３３は、イベントをグループ分けして通知する際に、グループごとの通知の優先度を算出する処理部である。

イベント分析部３４は、イベントを分析してグループ分けを行う処理部である。対処履歴管理部３５は、過去に行った対処の実績を対処履歴ＤＢ４３に登録して管理する。構成管理部３６は、監視対象システム２０の構成を構成情報ＤＢ４１に登録して管理する。イベント管理部３７は、監視対象システム２０で発生した複数のイベントをイベントＤＢ４５に登録して管理する。

イベント分析部３４は、具体的には、監視対象システム２０の構成、複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて複数のイベントを分析し、関連して発生したイベントを同一のグループに分類する。監視対象システム２０は、複数のサービスをそれぞれ提供する複数のサービスシステムを含み、イベント分析部３４は、異なるサービスシステムにまたがって発生した複数のイベントを同一のグループに分類可能である。

また、イベント分析部３４、所定の条件を満たす操作者による操作に基づいて、グループへの分類に係るパラメータを調整し、分析パラメータＤＢ４２に登録することで、以降の分析に反映する。

優先度算出部３３は、同一のグループに分類されたイベントの重大度、関連する機器の数、システムの重要度、対処の所要時間に基づいて、グループの優先度を算出する。

通知部３２は、複数のイベントをグループごとに通知する。また、グループとともに優先度の通知を行う。通知の一例を挙げれば、監視対象システム２０の構成をツリー構造として表示し、グループに分類されたイベントを含むツリー最上位のノードに対応付けて当該グループを表示する表示画面を生成する。

図２は、監視対象システム２０の構成を示す構成図である。図２に示すように、監視対象システム２０は、サービスシステムとして生産計画立案システム６１、生産管理日次集計処理７１、受発注管理システム８１を有する。

生産計画立案システム６１は、ＡＩサーバ６２及びストレージボリューム６３を構成要素として有する。生産管理日次集計処理７１は、生産管理ＤＢサーバ７２及びストレージボリューム７３を構成要素として有する。受発注管理システム８１は、受発注ＤＢサーバ８２及びストレージボリューム８３を構成要素として有する。

さらに、生産計画立案システム６１は、生産管理ＤＢサーバ７２にアクセスして生産管理日次集計処理７１のデータを利用することができる。同様に、受発注管理システム８１は、生産管理ＤＢサーバ７２にアクセスして生産管理日次集計処理７１のデータを利用することができる。

また、図２では、監視対象システム２０で発生する障害の具体例を示している。まず、生産計画立案システム６１が過大な演算を実施すると（Ａ１）、生産管理日次集計処理７１の構成要素であるストレージボリューム７３のＩ／Ｏ負荷が増大し（Ａ２）、生産管理ＤＢ７２のレスポンスが低下する（Ａ３）。その結果、生産管理日次集計処理７１のバッチ処理遅延が生じている（Ａ４）。

さらに、図２では、生産計画立案システム６１の過大な演算（Ａ１）に起因する一連の障害（Ａ２〜Ａ４）とは独立した障害として、受発注ＤＢサーバ８２のＣＰＵリソース不足（Ｂ１）が生じ、受発注管理市システム（Ｂ２）が引き起こされた状態を示している。

図３〜図６は、監視システム１０のデータの具体例を示す図である。図３のイベントテーブルは、イベントＤＢ４５に格納されるテーブルである。イベントテーブルは、イベントに対して発生時刻順に付与された識別番号であるＩＤ、発生時刻である時間、イベントの深刻さを示す重大度、イベントがどの構成要素で発生したかを示す発生元、イベントの内容を示すメッセージなどを項目として有する。

図３のグルーピングパラメータテーブルは、分析パラメータＤＢ４２に格納されるテーブルである。グルーピングパラメータテーブルは、時間的な距離に対する係数、構成的な距離に対する係数、対処履歴からの距離に対する係数、グルーピングの係数を項目として有する。

図３の優先度パラメータテーブルは、分析パラメータＤＢ４２に格納されるテーブルである。優先度パラメータテーブルは、グループの重大度に対する係数、関連する機器の数に対する係数、システムの重要度に対する係数、対処の所要時間に対する係数を項目として有する。

対処履歴テーブルは、対処履歴ＤＢ４３に格納されるテーブルである。対処履歴テーブルは、対処を行った日付、対処時の参照順序、対処に要した時間の項目を有する。対処時の参照順序は、イベントの対処に当たった識者が、どの順序でイベントの情報を参照したかを示すものである。参照したイベントは、その種類を識別可能な識別情報（Ｅ１〜Ｅ５）によって示す。識者とは、例えば所定以上のスキルを有する熟練の操作者である。

図４に示す構成情報テーブルは、構成情報ＤＢ４１に格納されるテーブルである。構成情報テーブルは、ＩＤ、構成要素、重要度、関連の項目を有する。構成情報テーブルのＩＤは、監視対象システム２０における構成要素を一意に識別する情報である。項目「構成要素」は、その構成要素の名称などである。重要度は、監視対象システムにおいてどれだけ重要な構成要素であるかを示す。項目「関連」には、その構成要素と直接接続された他の構成要素が列挙されている。

図４に示す人財管理テーブルは、人財管理ＤＢ４４に格納されたテーブルである。人財管理テーブルは、ＩＤ、氏名、スキル評価の項目を有する。ＩＤは、人財管理テーブルに登録された操作者などの人財を一意に特定する識別情報である。氏名は、登録された操作者などの人材の氏名を示す。スキル評価は、操作者としてのスキルの評価であり、「一般」であるか「識者」に該当するかを示す。

図５に示す距離テーブルは、複数のイベントの関係を評価した結果を示すテーブルである。評価の結果は「最終的な距離」として示される。例えば、「ＩＤ１」のイベントは、「ＩＤ２」のイベントとの距離が「５．３９」、「ＩＤ３」のイベントとの距離が「０．６４」、「ＩＤ４」のイベントとの距離が「０．９９」、「ＩＤ５」のイベントとの距離が「６．０３」である。

図５に示す優先度テーブルは、グループについて求めた、重大度、関連機器数、重要度、対処所要時間、スコア、優先度を示すデータである。

図６に示すイベントグループテーブルは、グループ分けの結果を示すテーブルである。図６では、グループＧ１に「ＩＤ１」、「ＩＤ３」、「ＩＤ４」のイベントが分類され、グループＧ２に「ＩＤ２」、「ＩＤ５」のイベントが分類されている。

図７は、監視システム１０の処理手順を示すフローチャートである。まず、監視システム１０のイベント分析部３４が、イベントのグルーピングを実行し（ステップＳ１０１）、優先度算出部３３がグループの優先度を算出する（ステップＳ１０２）。そして、通知部３２が、監視対象システム２０の構成ツリーにグループをマッピングして、表示部３１に表示出力させる（ステップＳ１０３）。

イベント分析部３４は、操作者が識者であるならば（ステップＳ１０４；Ｙｅｓ）、識者による操作を取得し、識者の知見を踏まえたパラメータ調整を行って（ステップＳ１０５）、処理を終了する。識者でなければ（ステップＳ１０４；Ｎｏ）、そのまま処理を終了する。

図８は、図７に示したイベントのグルーピング処理（Ｓ１０１）の詳細を示すフローチャートである。イベントのグルーピング処理が開始されると、イベント分析部３４は、時間的距離の算出（ステップＳ２０１）、構成的な距離の算出（ステップＳ２０２）、対処履歴からの距離の算出（ステップＳ２０３）を順次実行し、最終的な距離の算出を行う（ステップＳ２０４）。そして、最終的な距離に基づいてイベントのグルーピングを行って（ステップＳ２０５）、元の処理に戻る。

図９は、図８に示した時間的距離の算出（Ｓ２０１）の詳細を示すフローチャートである。時間的距離の算出を開始すると、まず、イベント分析部３４は、イベントテーブルよりイベント情報を参照する（ステップＳ３０１）。

ステップＳ３０２〜ステップＳ３０７は、ループ処理である。イベント分析部３４は、変数ｉを用いてステップＳ３０２〜ステップＳ３０７をイベントの数だけ繰り返す。

同様に、ステップＳ３０３〜ステップＳ３０６は、ループ処理である。イベント分析部３４は、変数ｊを用いてステップＳ３０３〜ステップＳ３０６をイベントの数だけ繰り返す。

ステップＳ３０４において、イベント分析部３４は、次式によりイベントｉとイベントｊの時間的距離を求める。
時間的距離＝絶対値（イベントｉの時刻−イベントｊの時刻）

ステップＳ３０５において、イベント分析部３４は、算出した時間的距離を距離テーブルに格納する。

ステップＳ３０２〜ステップＳ３０７のループ処理が終了した後、イベント分析部３４は、時間的距離の算出を終了し、元の処理に戻る。

図１０は、図８に示した対処履歴からの距離の算出（Ｓ２０２）の詳細を示すフローチャートである。対処履歴からの距離の算出を開始すると、まず、イベント分析部３４は、イベントテーブルよりイベント情報を参照する（ステップＳ４０１）。

ステップＳ４０２〜ステップＳ４０９は、ループ処理である。イベント分析部３４は、変数ｉを用いてステップＳ４０２〜ステップＳ４０９をイベントの数だけ繰り返す。

ステップＳ４０３において、イベント分析部３４は、対処履歴ＤＢ４３よりイベントｉを含む対処履歴一覧を抽出する。

ステップＳ４０４〜ステップＳ４０８は、ループ処理である。イベント分析部３４は、変数ｊを用いてステップＳ４０４〜ステップＳ４０８をイベントの数だけ繰り返す。

ステップＳ４０５において、イベント分析部３４は、イベント参照順序を特定する。そして、ステップＳ４０６において、イベント参照順序から距離を算出する。具体的には、イベントｉとイベントｊの参照順序の差分の絶対値を求め、その平均値を距離として算出する。例えば、イベントｉとイベントｊが２つの対処履歴で参照され、一方の対処履歴で１番目と２番目、他方の対処履歴で５番目と３番目なら、
（｜１−２｜＋｜５−３｜）／２＝１．５
となる。

ステップＳ４０７において、イベント分析部３４は、算出した対処履歴からの距離を距離テーブルに格納する。

ステップＳ４０２〜ステップＳ４０９のループ処理が終了した後、イベント分析部３４は、対処履歴からの距離の算出を終了し、元の処理に戻る。

図１１は、図８に示した最終的な距離の算出（Ｓ２０４）とグルーピング（Ｓ２０５）の詳細を示すフローチャートである。図１１のステップＳ５０１〜ステップＳＳ５０６が最終的な距離の算出（Ｓ２０４）の詳細であり、図１１のステップＳ５０７〜ステップＳＳ５１２がグルーピング（Ｓ２０５）の詳細である。

ステップＳ５０１〜ステップＳ５０６は、ループ処理である。イベント分析部３４は、変数ｉを用いてステップＳ５０１〜ステップＳ５０６をイベントの数だけ繰り返す。

同様に、ステップＳ５０２〜ステップＳ５０５は、ループ処理である。イベント分析部３４は、変数ｊを用いてステップＳ５０２〜ステップＳ５０５をイベントの数だけ繰り返す。

ステップＳ５０３において、イベント分析部３４は、距離テーブルより、イベントｉ，ｊ間の時間的距離、構成的距離、対処履歴からの距離を参照する。
ステップＳ５０４において、イベント分析部３４は、時間的距離、構成的距離、対処履歴からの距離からイベントｉ,ｊ間の最終的距離を出して、距離テーブルに格納する。最終的距離は、時間的距離、構成的距離、対処履歴に対し、グルーピングパラメータテーブルに示された係数をかけて合計することで求める。

ステップＳ５０１〜ステップＳ５０６のループ処理が終了した後、イベント分析部３４は、ステップＳ５０７〜ステップＳ５１２のループ処理を開始する。イベント分析部３４は、変数ｉを用いてステップＳ５０７〜ステップＳ５１２をイベントの数だけ繰り返す。

同様に、ステップＳ５０８〜ステップＳ５１１は、ループ処理である。イベント分析部３４は、変数ｊを用いてステップＳ５０８〜ステップＳ５１１をイベントの数だけ繰り返す。

ステップＳ５０９において、イベント分析部３４は、最終的距離がグルーピングパラメータテーブルに示された閾値（例えば５）以下であるか否かを判定する。判定の結果、閾値以下であれば（ステップＳ５０９；Ｙｅｓ）、ステップＳ５１０に移行し、閾値を超えていれば（ステップＳ５０９；Ｎｏ）、ステップＳ５１１に移行する。

ステップＳ５１０において、イベント分析部３４は、イベントｉ，ｊをイベントグループテーブルに登録し、ステップＳ５１１に移行する。

ステップＳ５０７〜ステップＳ５１２のループ処理が終了した後、イベント分析部３４は、処理を終了する。

図１２は、図７に示した優先度の算出（ステップＳ１０２）の詳細を示すフローチャートである。優先度算出部３３は、優先度の算出を開始すると、まず、各ファクター（変数）の値を算出する（ステップＳ６０１）。このファクターは、具体的には、グループの重大度、関連機器数、重要度、対処所要時間である。

優先度算出部３３は、学習モデルにより求めた係数を各ファクターに乗算して合計することで優先度を決定し（ステップＳ６０２）、処理を終了する。係数は、例えば、ニューラルネットワークやロジスティック回帰モデルを用いて機械学習により予め求められ、優先度パラメータテーブルとして分析パラメータＤＢ４２に格納されている。

図１３は、図１２に示したファクターの値の算出（Ｓ６０１）の詳細を示すフローチャートである。優先度算出部３３は、まず、イベントグループテーブルよりイベントグループ情報を取得する（ステップＳ７０１）。

ステップＳ７０２〜ステップＳ７０７は、ループ処理である。優先度算出部３３は、変数ｉを用いてステップＳ７０２〜ステップＳ７０７をイベントグループの数だけ繰り返す。

ステップＳ７０３において、優先度算出部３３は、イベントグループに属するイベントの重大度を取得し、その最大値を「グループの重大度」として優先度テーブルに格納する。
ステップＳ７０４において、優先度算出部３３は、構成情報テーブルより各イベントの発生元の構成要素の関連機器数を取得、最大の関連機器数を「グループの関連機器数」として優先度テーブルに格納する。
ステップＳ７０５において、優先度算出部３３は、構成情報テーブルより各イベントの発生元の構成要素の重要度を取得、最も高い重要度を「グループの重要度」として優先度テーブルに格納する。
ステップＳ７０６において、優先度算出部３３は、対処履歴ＤＢ４３から関連イベントが５０％以上一致する対処履歴を抽出し、対処所要時間の平均を「対処所要時間」として優先度テーブルに格納する。

ステップＳ７０２〜ステップＳ７０７のループ処理が終了した後、優先度算出部３３は、処理を終了する。

図１４は、図１２に示した優先度の決定（Ｓ６０２）の詳細を示すフローチャートである。優先度算出部３３は、まず、イベントグループテーブルよりイベントグループ情報を取得する（ステップＳ８０１）。

ステップＳ８０２〜ステップＳ８０６は、ループ処理である。優先度算出部３３は、変数ｉを用いてステップＳ８０２〜ステップＳ８０６をイベントグループの数だけ繰り返す。

ステップＳ８０３において、優先度算出部３３は、優先度テーブルよりイベントグループｉのファクター(重大度、関連機器数、重要度、対処所要時間)を取得する。
ステップＳ８０４において、優先度算出部３３は、優先度パラメータテーブルより係数を取得する。
ステップＳ８０５において、優先度算出部３３は、ファクターと係数からスコアを算出し、優先度テーブルに格納する。

ステップＳ８０２〜ステップＳ８０６のループ処理が終了した後、優先度算出部３３は、優先度テーブルのスコアをソートして優先度を決定し、優先度テーブルに格納して（ステップＳ８０７）、処理を終了する。

図１５は、図７に示した表示出力（ステップＳ１０３）の詳細を示すフローチャートである。通知部３２は、まず、構成情報テーブルより全ての構成要素を取得する（ステップＳ９０１）。通知部３２は、取得した構成要素の接続関係からツリーを生成する（ステップＳ９０２）。

通知部３２は、優先度テーブルを参照し、生成したツリーにグループと優先度をマッピングすることで、優先度付きツリーを生成する（ステップＳ９０３）。具体的には、グループに分類されたイベントをすべて含むノードに対応付けてマッピングする。通知部３２は、グループと優先度をマッピングしたツリーを表示部３１に表示させ（ステップＳ９０４）、処理を終了する。

図１６は、表示の具体例についての説明図である。図１６では、生産管理日次集計処理のノードにグループＧ１がマッピングされている。このグループＧ１には、イベントＩＤ１，ＩＤ３，ＩＤ４が含まれ、優先度は１である。同様に、受発注管理システムのノードにグループＧ２がマッピングされている。このグループＧ２には、イベントＩＤ２，ＩＤ５が含まれ、優先度は２である。

図１７は、図７に示したパラメータ調整（Ｓ１０５）の詳細を示すフローチャートである。イベント分析部３４は、識者がグルーピングの判断の根拠として用いた画面における最終のソート状況を取得する（ステップＳ１００１）。イベント分析部３４は、識者が最後にソートしたフィールドのグルーピングパラメータの係数を１０％増やしてグルーピングパラメータテーブルを更新する（ステップＳ１００２）。

同様に、優先度算出部３３は、識者が優先度の判断の根拠として用いた画面における最終のソート状況を取得する（ステップＳ１００３）。優先度算出部３３は、識者が最後にソートしたフィールドのグルーピングパラメータの係数を１０％増やしてグルーピングパラメータテーブルを更新する（ステップＳ１００２）。

監視システム１０がグルーピング及び優先度の判定結果を出力した後、識者が最終的な距離やスコア以外のパラメータでソートを行ったとすれば、識者は監視システム１０の判定結果とは異なる判断を行ったと推定できる。そして、この場合には識者がソートしたパラメータは、識者の判断の根拠として用いたものと考えられる。そこで、識者がソートしたパラメータの重みを上げることで、以降の監視システム１０による判定は、より識者の判断に近づくと期待できるのである。なお、識者が最終的な距離やスコアでソートした場合には、監視システム１０の判定の詳細を確認し、判定結果が妥当と考えたと推定できるので、パラメータの更新を行う必要はない。

上述してきたように、本実施例に係る監視システム１０は、監視対象システム２０で発生した複数のイベントを管理するイベント管理部３７と、監視対象システム２０の構成、複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析部３４と、複数のイベントをグループごとに通知する通知部３２とを備える。かかる構成及び動作により、監視対象システム２０における障害発生時の状況把握、及び対処の迅速化が実現できる。例えば、複数障害が同時に発生した場合であっても、迅速に対処することが可能となる。

また、本実施例に係る監視システム１０は、各グループについて、該グループに分類されたイベントの重大度、関連する機器の数、システムの重要度、対処の所要時間に基づいて、グループの優先度を算出する優先度算出部３３をさらに備える。また、本実施例に係る監視システム１０では、通知部３２は、監視対象システムの構成をツリー構造として表示し、グループに分類されたイベントを含むツリー最上位のノードに対応付けて当該グループを表示する。このため、操作者は、どのイベントから対処すべきであるかを適切に判断することができる。

また、本実施例に係る監視システム１０において、イベント分析部３４は、所定の条件を満たす操作者による操作に基づいて、グループへの分類に係るパラメータを調整する。このため、監視システム１０による判定精度を徐々に向上することができる。

また、本実施例に係る監視システム１０において、監視対象システム２０は、複数のサービスをそれぞれ提供する複数のサービスシステムを含み、イベント分析部３４は、異なるサービスシステムにまたがって発生した複数のイベントを同一のグループに分類可能である。このため、監視対象システムが大規模で複雑な構成であっても、障害発生時の状況把握、及び対処の迅速化が実現できる。

なお、本発明は上述の実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、かかる構成の削除に限らず、構成の置き換えや追加も可能である。

例えば、上述の実施例では、監視対象システムの構成に基づく距離の算出について詳細な説明を省略したが、構成要素間のホップ数を距離とするなど、任意の方法で構成に基づく距離を算出することができる。

また、上述の実施例では、過去の対処実績から距離を求めることで、イベントの内容に基づく評価を行っているが、イベントの種別間の距離を事前に定義して用いてもよい。

また、上述の実施例に開示した監視対象システムはあくまでも一例であり、任意のシステムを監視対象システムとして実施可能である。

１０：監視システム、２０：監視対象システム、３１：表示部、３２：通知部、３３：優先度算出部、３４：イベント分析部、３５：対処履歴管理部、３６：構成管理部、３７：イベント管理部、４１：構成情報ＤＢ、４２：分析パラメータＤＢ、４３：対処履歴ＤＢ、４４：人財管理ＤＢ、４５：イベントＤＢ

Claims

監視対象システムで発生した複数のイベントを管理するイベント管理部と、
前記監視対象システムの構成、前記複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて前記複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析部と、
前記複数のイベントを前記グループごとに通知する通知部と
を備えたことを特徴とする監視システム。
前記グループについて、該グループに分類されたイベントの重大度、関連する機器の数、システムの重要度、対処の所要時間に基づいて、前記グループの優先度を算出する優先度算出部をさらに備え、
前記通知部は、前記グループとともに前記優先度を通知する
ことを特徴とする請求項１に記載の監視システム。
前記通知部は、前記監視対象システムの構成をツリー構造として表示し、前記グループに分類されたイベントを含むツリー最上位のノードに対応付けて当該グループを表示することを特徴とする請求項１に記載の監視システム。
前記イベント分析部は、所定の条件を満たす操作者による操作に基づいて、前記グループへの分類に係るパラメータを調整することを特徴とする請求項１に記載の監視システム。
前記監視対象システムは、複数のサービスをそれぞれ提供する複数のサービスシステムを含み、
前記イベント分析部は、異なるサービスシステムにまたがって発生した複数のイベントを同一のグループに分類可能であることを特徴とする請求項１に記載の監視システム。
監視対象システムで発生した複数のイベントを管理するイベント管理部と、
前記監視対象システムの構成、前記複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて前記複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析部と、
前記複数のイベントを前記グループごとに通知する通知部と
を備えたことを特徴とする監視装置。
監視対象システムで発生した複数のイベントを管理するイベント管理ステップと、
前記監視対象システムの構成、前記複数のイベントの発生タイミング、及び過去に行った対処の実績に基づいて前記複数のイベントを分析し、関連して発生したイベントを同一のグループに分類するイベント分析ステップと、
前記複数のイベントを前記グループごとに通知する通知ステップと
を含むことを特徴とする監視方法。