JP2006252459A - 監視装置及び監視方法 - Google Patents
監視装置及び監視方法 Download PDFInfo
- Publication number
- JP2006252459A JP2006252459A JP2005071658A JP2005071658A JP2006252459A JP 2006252459 A JP2006252459 A JP 2006252459A JP 2005071658 A JP2005071658 A JP 2005071658A JP 2005071658 A JP2005071658 A JP 2005071658A JP 2006252459 A JP2006252459 A JP 2006252459A
- Authority
- JP
- Japan
- Prior art keywords
- message
- column
- received
- database
- monitoring
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】監視システムで処理されるメッセージ数が膨大になり、オペレータの負担が増大している。
【解決手段】監視装置において、ネットワークを介して監視対象に関するメッセージを受信すると、メッセージ集約ユニット40が発生要因に応じてメッセージを集約する処理を行う。メッセージ集約ユニット40は、受信したメッセージに関連付けるべきメッセージの条件を格納した監視設定関連付けデータベース44及びジョブ登録関連付けデータベース46と、これらを参照して、受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定し、受信されていた場合、受信したメッセージと既に受信されていたメッセージとを関連付けるメッセージ集約部42を含む。関連のあるメッセージ同士が識別可能に提示される。
【選択図】図8
【解決手段】監視装置において、ネットワークを介して監視対象に関するメッセージを受信すると、メッセージ集約ユニット40が発生要因に応じてメッセージを集約する処理を行う。メッセージ集約ユニット40は、受信したメッセージに関連付けるべきメッセージの条件を格納した監視設定関連付けデータベース44及びジョブ登録関連付けデータベース46と、これらを参照して、受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定し、受信されていた場合、受信したメッセージと既に受信されていたメッセージとを関連付けるメッセージ集約部42を含む。関連のあるメッセージ同士が識別可能に提示される。
【選択図】図8
Description
本発明は、監視技術に関し、特に、ネットワークを介してコンピュータなどの装置を監視する監視装置及び監視方法に関する。
近年、コンピュータのソフトウェアの多様化及びハードウェアの性能向上に伴い、システムの運用要件が複雑化してきている。このため、コンピュータシステムの運用監視を行う監視装置は、各ソフトウェア及びハードウェアからより多くの情報、例えば情報メッセージ及び障害メッセージなどを取得しなければならなくなっている。そのため、これらのメッセージを統括的に取り扱うために、ソフトウェア及びハードウェアごとに個別に運用される管理ツールを統合的に監視するツール(統合監視システム)が提案されている(例えば、非特許文献1参照)。
http://www-6.ibm.com/jp/software/tivoli/products/systems_mgr.html
http://www-6.ibm.com/jp/software/tivoli/products/systems_mgr.html
監視するシステム内で障害が発生すると、各ソフトウェアやハードウェアのコンポーネントの監視ツールが膨大なメッセージを発信する。しかし、連携しあう複数のコンポーネントを個別に運用される管理ツールで監視している場合、こうしたメッセージをオペレータが手作業で関連付けて障害の真の原因を特定することは困難であった。
本発明はこうした状況に鑑みてなされたものであり、その目的は、障害発生に対処する際の効率を向上させる技術を提供することにある。
本発明のある態様は、監視装置に関する。この監視装置は、ネットワークを介して監視対象に関するメッセージを受信する受信部と、受信したメッセージに関連付けるべきメッセージの条件を格納したデータベースと、前記データベースを参照して、前記受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定し、受信されていた場合、前記受信したメッセージと既に受信されていたメッセージとを関連付ける集約部と、前記受信したメッセージを、関連のあるメッセージ同士で識別可能に提示する提示部と、を備えることを特徴とする。
監視対象は、例えば、サーバ装置、パーソナルコンピュータなどの端末装置、それらの装置で動作するプロセスなどであってもよい。メッセージを関連付けるための条件は、障害の発生要因に基づいて設定されてもよい。メッセージを発生要因などに応じて関連付けて提示することにより、障害への対処の効率を向上させることができる。また、障害の発生要因の特定を容易にし、監視業務の信頼性を向上させることができる。
前記集約部は、関連のあるメッセージに対して同一の識別子を付与し、前記提示部は、前記メッセージを、識別子とともに提示してもよい。これにより、関連付けられたメッセージを容易に識別することができる。
前記条件は、メッセージの種別、内容、受信時刻、監視対象の種別、のいずれかに関する条件を含んでもよい。同じ障害で発信される可能性のあるメッセージを関連付けるために、これらの条件が用いられてもよい。
ネットワークを介して監視対象に関するメッセージを受信するステップと、受信したメッセージに関連付けるべきメッセージの条件を格納したデータベースを参照して、前記受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定するステップと、前記受信したメッセージに関連付けるべきメッセージが既に受信されていた場合、前記受信したメッセージと既に受信されていたメッセージとを関連付けるステップと、前記受信したメッセージを、関連のあるメッセージ同士で識別可能に提示するステップと、を含むことを特徴とする。
本発明によれば、監視対象に障害が発生したときに効率良く対処する技術を提供することができる。
図1は、監視装置20の構成を示す。監視装置20は、監視対象となる端末装置14bやサーバ装置14bなど(以下、「監視対象装置」という)が設けられたネットワークシステム12a、12b、・・・、を含む監視対象システム10を監視する。監視対象システム10において、監視対象装置の異常を検知してメッセージを発信する監視プログラム等が設けられており、そのプログラムに設定された条件に合致する状態が発生すると、監視装置20にメッセージが送信される。監視装置20は、監視対象システム10から発信されたメッセージを取得し、取得したメッセージを記録するとともに、オペレータにメッセージを提示し、障害の発生を通知する。オペレータは、提示されたメッセージの内容を見て、障害に対してなすべき対応の内容を判断する。
障害対応の必要がないような状態であってもメッセージが発信される場合があるし、1つの障害発生で同様のメッセージが大量に発信される場合もある。例えば、ウェブサーバがダウンした場合、そのウェブサーバにアクセス要求が発生するたびにエラーメッセージが発信されることになり、ときには何千何万ものメッセージが短期間に連続して発信されることもある。オペレータは、これらのメッセージの全てを見る必要はなく、障害への対応に必要な情報のみを取得できれば十分である。このように、受信したメッセージを全て通知すると、重要でないメッセージにもオペレータが反応しなければならず、障害対応の効率を下げる恐れがある。また、重要でないメッセージの中に重要なメッセージが埋もれてしまい、見落とされる恐れがある。
また、複数のソフトウェアやハードウェアを監視するときに、1つの障害発生に起因するメッセージが複数の監視対象から発信される場合がある。例えば、ある装置がダウンすると、その装置を監視していたツールがノードダウンを示すメッセージを発信し、その装置で実行されていたプロセスを監視していたツールが、プロセスがダウンした旨のメッセージを発信する。従来、これらのメッセージが、いずれも装置がダウンしたことに起因していることは、オペレータが判断しなければならなかった。
そこで、本実施の形態では、所定の条件に基づいてメッセージを取捨選択し、重要ではないメッセージが連続的に提示/通知されるのを抑止するとともに、メッセージを発生要因などに応じて集約して提示する技術を提案する。以下、前者を「連続抑止機能」、後者を「メッセージ集約機能」と呼ぶ。
監視装置20は、メッセージ受信部22、連続抑止ユニット30、メッセージ集約ユニット40、メッセージ登録部50、アラート通知部56、障害メッセージデータベース52、及び無視メッセージデータベース54を含む。これらの構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
メッセージ受信部22は、監視対象システム10から発信されたメッセージを受信する。連続抑止ユニット30は、所定の条件にしたがってメッセージを取捨選択し、不要なメッセージの提示を抑止する。メッセージ集約ユニット40は、メッセージを発生要因などに応じて集約する。連続抑止ユニット30により提示が抑止されたメッセージは、メッセージ集約ユニット40を経由せずにメッセージ登録部50へ送られてもよい。メッセージ登録部50は、受信したメッセージを障害メッセージデータベース52又は無視メッセージデータベース54に登録する。連続抑止ユニット30により提示が抑止されたメッセージは無視メッセージデータベース54に、抑止されずに提示されるメッセージは障害メッセージデータベース52に登録される。アラート通知部56は、提示すべきメッセージを受信したときに、メッセージを受信したことをパトランプや音声などにより通知するとともに、メッセージの内容を提示する。
図2は、監視装置20における処理の流れを概略的に示す。メッセージ受信部22が監視対象のシステムから障害メッセージを受信すると(S10)、連続抑止ユニット30が、所定の条件にしたがって、メッセージを提示するか否かを判断する(S12)。提示すると判断されたメッセージは、さらにメッセージ集約ユニット40により、発生要因などに応じて集約される(S14)。メッセージ登録部50は、メッセージを障害メッセージデータベース52又は無視メッセージデータベース54に登録し(S16)、アラート通知部56は、連続抑止ユニット30により提示すると判断されたメッセージを通知/提示する(S18)。
図3は、連続抑止ユニット30の内部構成を示す。連続抑止ユニット30は、連続抑止判定部32、定義ポリシーデータベース34、解除条件データベース36、及び連続抑止中データベース38を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
定義ポリシーデータベース34は、受信したメッセージの提示を抑止するか否かを判定するための条件を定義した定義ポリシーを格納する。図4は、定義ポリシーデータベース34の内部データの例を示す。定義ポリシーデータベース34には、定義番号欄71、FROM欄72、BODY欄73、TO欄74、通知条件欄75、及び解除条件番号欄76が設けられている。定義番号欄71には、定義ポリシーを一意に識別するための番号が格納される。FROM欄72にはメッセージの提示の抑止を開始する開始条件が、BODY欄73にはメッセージの提示の抑止を実行する抑止条件が、TO欄74にはメッセージの提示の抑止を終了する解除条件が格納され、それぞれに、システムID欄77a、77b、及び77c、メッセージID欄78a、78b、及び78c、ノードID欄79a、79b、及び79c、ノード名欄80a、80b、及び80c、曜日欄81a、81b、及び81c、時間帯欄82a、82b、及び82c、本文(内容)欄83a、83b、及び83cが設けられている。
システムID欄77a、77b、及び77cは、監視対象のシステムを識別するためのIDを格納する。メッセージID欄78a、78b、及び78cは、メッセージの種類を示すIDを格納する。ノードID欄79a、79b、及び79cは、監視対象のノードを識別するためのIDを格納する。ノード名欄80a、80b、及び80cは、監視対象のノードの名称を格納する。曜日欄81a、81b、及び81cは、メッセージが発信された日の曜日に関する条件を格納する。時間帯欄82a、82b、及び82cは、メッセージが発信された時間帯に関する条件を格納する。本文(内容)欄83a、83b、及び83cは、メッセージの本文、すなわち内容に関する条件を格納する。
連続抑止判定部32は、受信したメッセージがこれらの条件に合致するか否かを判定する。FROM欄72に合致したメッセージを受信したときは、その定義ポリシーを連続抑止中データベース38に登録して連続抑止機能を開始させる。BODY欄73に合致したメッセージを受信したときは、その定義ポリシーが連続抑止中データベース38に登録されていれば、すなわち連続抑止中であれば、そのメッセージの提示を抑止する。TO欄74に合致したメッセージを受信したときには、その定義ポリシーが連続抑止中データベース38に登録されていれば、その定義ポリシーを連続抑止中データベース38から削除し、連続抑止機能を解除する。
通知条件欄75は、FROM欄84、BODY欄85、TO欄86を含み、それぞれ、FROM欄72の開始条件、BODY欄73の抑止条件、TO欄74の解除条件に合致したメッセージを提示/通知するか否かを格納する。解除条件番号欄76は、連続抑止処理を解除する条件を示す番号を格納する。解除条件番号に対応する解除条件の内容は、図5に示す解除条件データベース36に格納される。
解除条件データベース36は、連続抑止処理を解除する条件を格納する。図5は、解除条件データベース36の内部データの例を示す。解除条件データベース36には、解除条件番号欄87、タイムアウト時間欄88、最大抑止回数欄89、及びTO到達欄90が設けられている。解除条件番号欄87には、解除条件を一意に識別するための番号が格納される。タイムアウト時間欄88には、連続抑止処理が開始された後、解除するまでの時間が格納される。最大抑止回数欄89には、メッセージの提示を抑止する最大の回数が格納される。TO到達欄90には、定義ポリシーデータベース34のTO欄74に格納された解除条件を適用するか否かが格納される。
連続抑止判定部32は、連続抑止を開始してからタイムアウト時間欄88に格納されたタイムアウト時間が経過するか、メッセージの抑止回数が最大抑止回数欄89に格納された回数に到達するか、TO欄74に格納された解除条件に合致するメッセージを受信したときに、連続抑止中データベース38から該当する定義ポリシーを削除して、連続抑止機能を解除する。
連続抑止中データベース38は、連続抑止を実行中の定義ポリシーを格納する。図6は、連続抑止中データベース38の内部データの例を示す。連続抑止中データベース38には、抑止番号欄91、定義番号欄71、FROM欄72、BODY欄73、TO欄74、通知条件欄75、タイムアウト時間欄88、最大抑止回数欄89、抑止開始日時欄92、及び抑止回数欄93が設けられている。抑止番号欄91には、連続抑止中の定義ポリシーを識別するための番号が格納される。定義番号欄71、FROM欄72、BODY欄73、TO欄74、通知条件欄75には、連続抑止が開始された定義ポリシーが、定義ポリシーデータベース34からコピーされる。タイムアウト時間欄88、最大抑止回数欄89には、定義ポリシーデータベース34の解除条件番号欄76に設定された解除条件の内容が、解除条件データベース36からコピーされる。抑止開始日時欄92には、連続抑止が開始された日時が格納される。抑止回数欄93は、メッセージの提示が抑止された回数が格納される。
図7は、連続抑止方法の手順を示すフローチャートである。連続抑止判定部32は、まず、受信したメッセージと定義ポリシーデータベース34に格納された定義ポリシーをマッチングする(S20)。受信したメッセージが、いずれの定義ポリシーとも一致しない場合は(S22のN)、そのメッセージは抑止されずに提示される(S42)。実際には、メッセージ集約ユニット40により集約されてから提示されることになる。受信したメッセージが、定義ポリシーデータベース34のFROM欄72に定義された開始条件に一致する場合(S22のY)、その定義ポリシーが連続抑止中データベース38に登録済みか否かをマッチングし(S24)、連続抑止中でなければ(S26のN)、連続抑止中データベース38にその定義ポリシーを登録して連続抑止機能を開始する(S28)。また、このメッセージを通知するか否かを、定義ポリシーデータベース34の通知条件欄75のFROM欄84を参照して判定し(S30)、通知「有」であれば(S30のY)、メッセージを通知する(S42)。通知「無」であれば(S30のN)、このメッセージは通知されない。
受信したメッセージが、定義ポリシーデータベース34のBODY欄73に定義された抑止条件に一致する場合(S22のY)、その定義ポリシーが連続抑止中データベース38に登録済みであれば(S26のY)、連続抑止の解除条件が判定され(S32)、連続抑止を解除しない場合は(S34のN)、このメッセージの提示は抑止され、連続抑止中データベース38の該当する定義ポリシーの抑止回数欄93がインクリメントされる(S40)。連続抑止の解除条件に合致する場合、例えば、タイムアウト時間が経過した場合や最大抑止回数に達した場合は(S34のY)、連続抑止中データベース38の該当する定義ポリシーを初期化する(S36)。また、このメッセージを提示するか否かを、定義ポリシーデータベース34又は連続抑止中データベース38の通知条件欄75のTO欄86を参照して判定し(S38)、通知「有」であれば(S38のY)、メッセージを通知する(S42)。通知「無」であれば、このメッセージは通知されない。
受信したメッセージが、定義ポリシーデータベース34のTO欄74に定義された解除条件に一致する場合(S22のY)、その定義ポリシーが連続抑止中データベース38に登録済みであれば(S26のY)、解除条件判定処理(S32)において解除条件に合致すると判定されるので、連続抑止が解除され(S34のY)、連続抑止中データベース38の該当する定義ポリシーが初期化される(S36)。また、このメッセージを提示するか否かを、定義ポリシーデータベース34又は連続抑止中データベース38の通知条件欄75のTO欄86を参照して判定し(S38)、通知「有」であれば(S38のY)、メッセージを通知する(S42)。通知「無」であれば、このメッセージは通知されない。以上の処理が、定義ポリシーデータベースに格納された全ての定義ポリシーのマッチングが終了する(S44のY)まで繰り返される。
連続抑止機能の具体的な使用例をいくつか述べる。まず、第1の例として、サーバ装置や端末装置などを自動的に再起動するときの定義ポリシーの例を説明する。サーバや端末などの装置を定期的に再起動させる場合があるが、装置にリブートがかけられてから起動が終了するまでの間、その装置で実行されているべきプロセス等がダウンしているために、プロセスなどを監視しているツールからエラーメッセージが発信される可能性がある。このエラーメッセージは、装置の再起動に起因するものであり、実質的な障害ではないから、オペレータに通知する必要はない。そのため、定義ポリシーデータベース34のFROM欄72に、再起動が開始されたときに発信されるメッセージを登録しておき、通知条件欄75のFROM欄84を「有」に設定する。また、再起動中に発信される可能性のあるエラーメッセージをBODY欄73に登録しておく。また、再起動が完了したときに発信されるメッセージをTO欄74に登録し、通知条件欄75のTO欄86を「有」に設定する。これにより、再起動が開始されたことがオペレータに通知され、それ以降、再起動に起因するエラーメッセージの通知が抑止される。また、再起動が完了すると、その旨がオペレータに通知され、連続抑止処理が解除される。
第2の例として、サーバや端末などの装置のCPUに高負荷がかかったときの定義ポリシーの例を説明する。CPUに継続的に高い負荷がかかっている場合は障害が発生している可能性が高いが、重いプロセスが走った場合など、瞬間的に高い負荷がかかることがある。後者の場合、継続的な高負荷でなければ、とくに問題はないので、オペレータに通知する必要はない。したがって、CPUの高負荷を示すメッセージを連続的に受信した場合にだけオペレータに通知するような定義ポリシーを設定しておけばよい。定義ポリシーデータベース34のFROM欄72及びBODY欄73に、CPUの高負荷を示すメッセージを登録し、通知条件欄75のFROM欄84に「無」、BODY欄85に「無」、TO欄86に「有」を設定する。TO欄74には何も設定せず、解除条件データベース36の最大抑止回数欄89に、例えば「7回」を設定し、タイムアウト時間欄88に、例えば「560秒」を設定する。これにより、CPUの高負荷を示すメッセージを受信すると、初回はそれを提示せず、同じメッセージを7回受信するまで、メッセージは提示されずに抑止される。最初のメッセージを受信してから560秒が経過するまでに、同じメッセージを8回受信すると、そのメッセージがオペレータに提示されるとともに、連続抑止機能が解除される。
第3の例として、ASPなどで提供されるオンラインプログラムを監視するときの定義ポリシーの例を説明する。インターネットを介してユーザからのアクセスを受け付けるプログラムを監視するツールは、監視するプログラムがダウンすると、そのプログラムにアクセスがあるたびにエラーメッセージを発信する。しかし、オペレータには最初の1回だけメッセージを通知すれば十分である。したがって、定義ポリシーデータベース34のFROM欄72及びBODY欄73に、プログラムがダウンした旨を示すエラーメッセージを登録し、通知条件欄75のFROM欄84に「有」、BODY欄85に「無」、TO欄86に「無」を設定する。TO欄74には何も設定せず、解除条件データベース36のタイムアウト時間欄88に、十分大きな値、例えば「3600秒」を設定し、最大抑止回数欄89には何も設定しない。これにより、プログラムがダウンしたとき、初回のメッセージのみが提示され、以降は全て抑止される。
このように、オペレータにとって必要なメッセージのみを提示し、不要なメッセージの提示を抑止することにより、障害対応の効率を向上させることができる。また、重要なメッセージが見落とされる可能性を低減し、監視の信頼性を向上させることができる。また、開始条件と解除条件を設定可能とすることにより、より柔軟な抑止の形態を設定することができ、提示すべきメッセージを的確に抽出することができる。また、抑止機能の開始と終了を定義し、その間に受信したメッセージを集合として抑止することにより、短期に大量に発信される不要なメッセージを効果的に抑止することができる。
図8は、メッセージ集約ユニット40の内部構成を示す。メッセージ集約ユニット40は、障害番号カウンタ41、メッセージ集約部42、監視設定データベース43、監視設定関連付けデータベース44、ジョブ登録データベース45、ジョブ登録関連付けデータベース46、監視設定登録部47、及びジョブ登録部48を含む。これらの構成も、ハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できる。
監視設定データベース43は、監視装置20が監視する対象に関する情報が格納される。図9は、監視設定データベース43の内部データの例を示す。監視設定データベース43には、監視設定番号欄101、メッセージID欄102、ノードID欄103、ノード名欄104、監視種類欄105、監視対象欄106、及びその他条件欄107が設けられている。監視設定番号欄101には、監視設定を識別するための番号が格納される。メッセージID欄102には、メッセージの種別を識別するためにメッセージに付加されるIDが格納される。ノードID欄103には、監視対象となるノードを識別するためのIDが格納される。ノード名欄104には、監視対象となるノードの名称が格納される。監視種類欄105には、監視内容の種類が格納される。例えば、「ノード」であればノードダウンが監視され、「プロセス」であればプロセスダウンが監視され、「ログ」であればログ出力の内容が監視される。監視対象欄106には、監視対象を具体的に特定するための情報が格納される。例えば、プロセスの監視であればプロセスの名称が、ログの監視であればログの名称が格納される。その他条件欄107には、異常と判断するためのしきい値などの情報を格納する。例えば、監視設定番号「3」及び「4」では、ログに「error」を含む文字列が出力されるとメッセージが発信される。この文字列には正規表現を指定してもよい。監視設定番号「5」では「C」ドライブの使用量が「90%」を超えるとメッセージが発信される。
ジョブ登録データベース45は、監視対象装置において実行されるジョブの情報を格納する。図10は、ジョブ登録データベース45の内部データの例を示す。ジョブ登録データベース45には、ジョブ登録番号欄111、動作環境欄112、フレーム欄113、ネット欄114、ジョブ欄115、プログラム欄116、スケジュール欄117が設けられている。ジョブ登録番号欄111には、ジョブ登録を識別するための番号が格納される。動作環境欄112は、動作環境を示す情報が格納される。フレーム欄113、ネット欄114、ジョブ欄115には、フレーム、ネット、ジョブに関する情報がそれぞれ格納される。プログラム欄116には、実行されるプログラムのファイル名が格納される。スケジュール欄117には、ジョブを実行するスケジュールを示す情報が格納される。
監視設定関連付けデータベース44は、監視設定にしたがって発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図11は、監視設定関連付けデータベース44の内部データの例を示す。監視設定関連付けデータベース44には、監視設定番号欄121、関連監視設定番号欄122、関連ジョブ登録番号欄123、及び時間欄124が設けられている。監視設定番号欄121には、監視設定データベース43に登録された監視設定の番号が格納される。関連監視設定番号欄122には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄123には、その監視設定にしたがって発信されたメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、監視設定番号「1」の監視設定、すなわち、ノードID「AP1」の「APサーバ1」がノードダウンしたときに発信されるメッセージID「AAA」のメッセージは、既に受信していた監視設定番号「2、3」のメッセージ及びジョブ登録番号「1」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、所定の条件にしたがって、いずれのメッセージに関連付けられるかが選択されてもよい。この選択のための条件を監視設定関連付けデータベース44に設定可能としてもよい。例えば、関連付けのための条件に合致した複数のメッセージのうち、最も古いメッセージに関連付けてもよいし、最も新しいメッセージに関連付けてもよいし、優先順位を設定しておいてもよい。時間欄124には、メッセージを関連付ける期間が格納される。例えば、監視設定番号「1」に関するメッセージは、それよりも「300秒」前までに受信していた監視設定番号「2、3」及びジョブ登録番号「1」のメッセージに関連付けられる。300秒以上前に受信していたメッセージには関連付けられない。
ジョブ登録関連付けデータベース46は、登録されたジョブを監視するツールから発信されたメッセージを他のメッセージに関連付けるための条件を格納する。図12は、ジョブ登録関連付けデータベース46の内部データの例を示す。ジョブ登録関連付けデータベース46には、ジョブ登録番号欄131、関連監視設定番号欄132、関連ジョブ登録番号欄133、及び時間欄134が設けられている。ジョブ登録番号欄131には、ジョブ登録データベース45に登録されたジョブ登録番号が格納される。関連監視設定番号欄132には、そのジョブに関するメッセージに関連付けるべきメッセージの監視設定番号が格納される。関連ジョブ登録番号欄133には、そのジョブに関するメッセージに関連付けるべきメッセージのジョブ登録番号が格納される。例えば、ジョブ登録番号「1」のジョブ、すなわち、動作環境「ABC」、フレーム「fr001」、ネット「nt001」、ジョブ「jb001」、プログラム「/home/apl/bt/jb001.cah」、スケジュール「sj001」に関するメッセージは、既に受信していた監視設定番号「1」のメッセージ及びジョブ登録番号「2」のメッセージに関連付けられる。既に受信されていた異なる複数のメッセージが関連付けのための条件に合致する場合は、上述したように、所定の条件にしたがっていずれのメッセージに関連付けられるかが選択されてもよい。時間欄134には、メッセージを関連付ける期間が格納される。例えば、ジョブ登録番号「1」に関するメッセージは、それよりも「300秒」前までに受信していた監視設定番号「1」及びジョブ登録番号「2」のメッセージに関連付けられる。300秒以上前に受信していたメッセージには関連付けられない。
監視設定登録部47は、監視設定データベース43に設定する監視内容を受け付け、監視設定データベース43に登録する。また、監視設定データベース43に登録された監視設定に関連する監視設定及びジョブを監視設定関連付けデータベース44に設定する。ジョブ登録部48は、ジョブ登録データベース45に設定するジョブの内容を受け付け、ジョブ登録データベース45に登録する。また、ジョブ登録データベース45に登録されたジョブに関連するジョブ及び監視設定をジョブ登録関連付けデータベース46に設定する。
メッセージ集約部42は、監視設定関連付けデータベース44、ジョブ登録関連付けデータベース46を参照して、受信したメッセージに関連付けるべきメッセージが以前に受信されていたか否かを判定し、受信されていれば、関連のあるメッセージを集約して表示させるために、障害番号カウンタ41により、既に受信されていたメッセージと同じ障害番号を今回受信したメッセージに付与する。受信されていなければ、障害番号カウンタ41により新たな障害番号を採番して割り当てる。アラート通知部56は、メッセージを提示する際に、障害番号とともに提示する。これにより、関連のあるメッセージをオペレータが識別することができる。
図13は、メッセージ集約方法の手順を示すフローチャートである。メッセージ集約部42は、取得したメッセージが監視設定に関するものかジョブに関するものかを判断し(S50)、監視設定に関するものであれば(S50のY)、監視設定データベース43と監視設定関連付けデータベース44を参照して、該当する監視設定のメッセージに関連付けるべきメッセージの情報を検索する(S52)。取得したメッセージがジョブに関するものであれば(S50のN)、ジョブ登録データベース45とジョブ登録関連付けデータベース46を参照して、該当するジョブのメッセージに関連付けるべきメッセージの情報を検索する(S54)。関連付けに関する情報が取得できなかった場合(S56のN)、受信したメッセージに関連付けるべきメッセージはないので、今回受信したメッセージの障害番号を障害番号カウンタ41により新たに採番してメッセージに付与する(S64)。
関連付けに関する情報が取得できた場合(S56のY)、既に受信していたメッセージに該当するメッセージがあるか否かをマッチングする(S58)。該当するメッセージが障害メッセージデータベース52に登録されていなければ(S60のN)、今回受信したメッセージの障害番号を障害番号カウンタ41により新たに採番してメッセージに付与する(S64)。該当する障害メッセージが障害メッセージデータベース52に登録されていれば(S60のY)、今回受信したメッセージの障害番号を、既に受信していた関連するメッセージの障害番号と同一にする(S62)。こうして集約されたメッセージは、メッセージ登録部50により障害メッセージデータベース52に登録され、アラート通知部56により提示/通知される。
図14(a)(b)は、アラート通知部56により提示されたメッセージ提示画面の例を示す。図14(a)は、メッセージ集約ユニット40によりメッセージが集約される前の画面例を示す。ここでは、連続抑止ユニット30により提示が抑止されたメッセージは提示されない。図14(b)は、メッセージ集約ユニット40によりメッセージが集約された後の画面例を示す。図14(a)では、メッセージID「BBA」のメッセージには障害番号「002」が、メッセージID「DDD」には障害番号「003」が付与されているが、メッセージ集約ユニット40により、これらのメッセージが関連付けられた結果、同一の障害番号「002」が付与されて提示されている。これにより、オペレータは、これらのメッセージが同一の障害に起因するものであると推定することができるので、効率よく対応することができる。また、障害の発生要因の特定を支援し、オペレータがより適切な対策を講じることができるようにすることができる。
上述した連続抑止機能とメッセージ集約機能を組み合わせることにより、必要なメッセージを的確に抽出し、発生要因別に集約して提示することができるので、さらに監視業務の効率化を図ることができる。実施の形態では、連続抑止ユニット30がメッセージを提示するか否かを判断した後、メッセージ集約ユニット40が関連のあるメッセージを集約したが、これらの順序は逆であってもよいし、同時に並行して行われてもよい。
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
10 監視対象システム、20 監視装置、22 メッセージ受信部、30 連続抑止ユニット、32 連続抑止判定部、34 定義ポリシーデータベース、36 解除条件データベース、38 連続抑止中データベース、40 メッセージ集約ユニット、41 障害番号カウンタ、42 メッセージ集約部、43 監視設定データベース、44 監視設定関連付けデータベース、45 ジョブ登録データベース、46 ジョブ登録関連付けデータベース、47 監視設定登録部、48 ジョブ登録部、50 メッセージ登録部、52 障害メッセージデータベース、54 無視メッセージデータベース、56 アラート通知部。
Claims (4)
- ネットワークを介して監視対象に関するメッセージを受信する受信部と、
受信したメッセージに関連付けるべきメッセージの条件を格納したデータベースと、
前記データベースを参照して、前記受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定し、受信されていた場合、前記受信したメッセージと既に受信されていたメッセージとを関連付ける集約部と、
前記受信したメッセージを、関連のあるメッセージ同士で識別可能に提示する提示部と、
を備えることを特徴とする監視装置。 - 前記集約部は、関連のあるメッセージに対して同一の識別子を付与し、
前記提示部は、前記メッセージを、識別子とともに提示することを特徴とする請求項1に記載の監視装置。 - 前記条件は、メッセージの種別、内容、受信時刻、監視対象の種別、のいずれかに関する条件を含むことを特徴とする請求項1又は2に記載の監視装置。
- ネットワークを介して監視対象に関するメッセージを受信するステップと、
受信したメッセージに関連付けるべきメッセージの条件を格納したデータベースを参照して、前記受信したメッセージに関連付けるべきメッセージが既に受信されていたか否かを判定するステップと、
前記受信したメッセージに関連付けるべきメッセージが既に受信されていた場合、前記受信したメッセージと既に受信されていたメッセージとを関連付けるステップと、
前記受信したメッセージを、関連のあるメッセージ同士で識別可能に提示するステップと、
を含むことを特徴とする監視方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005071658A JP2006252459A (ja) | 2005-03-14 | 2005-03-14 | 監視装置及び監視方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005071658A JP2006252459A (ja) | 2005-03-14 | 2005-03-14 | 監視装置及び監視方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2006252459A true JP2006252459A (ja) | 2006-09-21 |
Family
ID=37092856
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005071658A Pending JP2006252459A (ja) | 2005-03-14 | 2005-03-14 | 監視装置及び監視方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2006252459A (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009009448A (ja) * | 2007-06-29 | 2009-01-15 | Mitsubishi Electric Corp | データ送信装置及びデータ送信方法及びプログラム |
JP2010086204A (ja) * | 2008-09-30 | 2010-04-15 | Oki Data Corp | 画像処理装置 |
JP2012094049A (ja) * | 2010-10-28 | 2012-05-17 | Nomura Research Institute Ltd | インシデント管理システムおよびインシデント管理プログラム |
JP2013008162A (ja) * | 2011-06-23 | 2013-01-10 | Fujitsu Ltd | 監視装置、監視方法、および監視プログラム |
JP2013210747A (ja) * | 2012-03-30 | 2013-10-10 | Fujitsu Ltd | 制御プログラム、制御方法および制御装置 |
JPWO2017081866A1 (ja) * | 2015-11-13 | 2018-08-30 | 日本電気株式会社 | ログ分析システム、方法およびプログラム |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63254536A (ja) * | 1987-04-10 | 1988-10-21 | Fujitsu Ltd | エラ−事象の一元管理方式 |
JP2000010805A (ja) * | 1998-06-19 | 2000-01-14 | Hitachi Ltd | コンソールメッセージのルーティング方法およびコンソールシステム |
JP2001256032A (ja) * | 2000-03-14 | 2001-09-21 | Mitsubishi Electric Corp | 障害メッセージ表示装置 |
JP2003228497A (ja) * | 2002-02-04 | 2003-08-15 | Nec Software Chubu Ltd | 障害通知システムおよび障害通知プログラム |
-
2005
- 2005-03-14 JP JP2005071658A patent/JP2006252459A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63254536A (ja) * | 1987-04-10 | 1988-10-21 | Fujitsu Ltd | エラ−事象の一元管理方式 |
JP2000010805A (ja) * | 1998-06-19 | 2000-01-14 | Hitachi Ltd | コンソールメッセージのルーティング方法およびコンソールシステム |
JP2001256032A (ja) * | 2000-03-14 | 2001-09-21 | Mitsubishi Electric Corp | 障害メッセージ表示装置 |
JP2003228497A (ja) * | 2002-02-04 | 2003-08-15 | Nec Software Chubu Ltd | 障害通知システムおよび障害通知プログラム |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009009448A (ja) * | 2007-06-29 | 2009-01-15 | Mitsubishi Electric Corp | データ送信装置及びデータ送信方法及びプログラム |
JP2010086204A (ja) * | 2008-09-30 | 2010-04-15 | Oki Data Corp | 画像処理装置 |
US8138935B2 (en) | 2008-09-30 | 2012-03-20 | Oki Data Corporation | Image processor |
JP2012094049A (ja) * | 2010-10-28 | 2012-05-17 | Nomura Research Institute Ltd | インシデント管理システムおよびインシデント管理プログラム |
JP2013008162A (ja) * | 2011-06-23 | 2013-01-10 | Fujitsu Ltd | 監視装置、監視方法、および監視プログラム |
JP2013210747A (ja) * | 2012-03-30 | 2013-10-10 | Fujitsu Ltd | 制御プログラム、制御方法および制御装置 |
JPWO2017081866A1 (ja) * | 2015-11-13 | 2018-08-30 | 日本電気株式会社 | ログ分析システム、方法およびプログラム |
JP7006272B2 (ja) | 2015-11-13 | 2022-01-24 | 日本電気株式会社 | ログ分析システム、方法およびプログラム |
US11232013B2 (en) | 2015-11-13 | 2022-01-25 | Nec Corporation | Log analysis system, log analysis method, and log analysis program for a user interface |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4527572B2 (ja) | 監視装置及び監視方法 | |
US7979407B2 (en) | Publication of informational messages to software applications in a computing environment | |
JP5075736B2 (ja) | 仮想サーバのシステム障害回復方法及びそのシステム | |
US9015316B2 (en) | Correlation of asynchronous business transactions | |
JP4528116B2 (ja) | 分散環境中でアプリケーションの性能を監視するための方法およびシステム | |
US10223185B2 (en) | Automated defect diagnosis from machine diagnostic data | |
WO2012056561A1 (ja) | 装置監視システム,方法およびプログラム | |
JP2011186783A (ja) | スナップショット管理方法、スナップショット管理装置、及びプログラム | |
JP2008537610A (ja) | トランザクション・ベースのシステムを監視するための方法及びシステム | |
JP2006252459A (ja) | 監視装置及び監視方法 | |
US7783742B2 (en) | Dynamic process recovery in a distributed environment | |
WO2019242455A1 (en) | Method and apparatus for user request forwarding, reverse proxy and computer readable storage medium | |
JP2010244486A (ja) | データ処理システム、その処理方法、及び計算機 | |
JP2007087232A (ja) | システム構成変更によるポリシ修正を容易にするポリシ作成方法、及びポリシ管理方法 | |
US9461879B2 (en) | Apparatus and method for system error monitoring | |
US20180300199A1 (en) | System and method for maintaining the health of a machine | |
JP2009176203A (ja) | 監視装置、監視システム、監視方法およびプログラム | |
US7546604B2 (en) | Program reactivation using triggering | |
JP7243207B2 (ja) | 情報処理システム、情報処理装置及びプログラム | |
JP4533716B2 (ja) | 障害メッセージに対する再警告発動システム | |
US10474544B1 (en) | Distributed monitoring agents for cluster execution of jobs | |
JP2009193153A (ja) | 管理システム、履歴情報の保存方法、及び履歴情報データベースのデータ構造 | |
JP2009266031A (ja) | 計算機システム及び計算機 | |
JP5466740B2 (ja) | 仮想サーバのシステム障害回復方法及びそのシステム | |
JP5378847B2 (ja) | 監視装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070919 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090914 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100309 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100629 |