JP2017182601A - 監視装置、監視システム及び監視プログラム - Google Patents

Abstract

【課題】監視対象の装置に関する情報を有効に利用する。【解決手段】監視装置が、通信装置からの通知情報を取得する取得手段と、前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表す情報を生成し、該生成した情報を第１のイベント発生情報として抽出する抽出手段と、前記第１のイベント発生情報を出力する出力手段と、を備える。【選択図】図１

Description

本発明は、監視するための、監視装置、監視システム及び監視プログラムに関する。

通信ネットワークに含まれる各通信装置の状態を把握するための技術としてｓｙｓｌｏｇを利用することが広く行われている。

ここで、ｓｙｓｌｏｇを利用する技術の一例が特許文献１に記載されている。特許文献１に記載のログ情報管理サーバは、ネットワークを介して接続される送信元機器から、送信元機器で発生したイベントのシスログデータを受信する。また、受信したシスログデータ、シスログデータに付加された受信時刻及びイベントが発生した送信元機器を特定可能なデータをデータベースに記憶することによりログ情報を生成する。

その後、管理者端末からの要求を受け付けたログ情報管理サーバは、ログ情報のデータベースから要求に対応するログ情報を取得し、取得したログ情報を管理者端末に送信する。

管理者端末のユーザは、受信したログ情報を参照することによりシステムトラブルの原因等を特定することが可能となる。

特開２００３−１４１０７５号公報

このようにｓｙｓｌｏｇは、システムの管理作業に不可欠な情報収集源であり、システムで発生したトラブルの原因はｓｙｓｌｏｇを調べて分かることが多い。

しかしながら、特許文献１等に記載のログ情報管理サーバに記憶されるｓｙｓｌｏｇは、システム管理でトラブルの発生原因を調べるための使い勝手において充分なものとは言えない。

なぜならば、システム管理を行うユーザが、ログ情報管理サーバに記録されたｓｙｓｌｏｇを参照するためには、特許文献１に記載のように、管理者端末を利用して自発的にサーバに問合せを行う等の処理が必要だからである。

本発明は上記課題に鑑み提案するものであって、監視対象の装置に関する情報を有効に利用することが可能な、監視装置、監視システム及び監視プログラムを提供することを目的とする。

本発明の第１の観点によれば、通信装置からの通知情報を取得する取得手段と、前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表す情報を生成し、該生成した情報を第１のイベント発生情報として抽出する抽出手段と、前記第１のイベント発生情報を出力する出力手段と、を備えることを特徴とする監視装置が提供される。

本発明の第２の観点によれば、上記本発明の第１の観点により提供される監視装置と、クライアント端末とを備える監視システムであって、前記通信手段は、前記クライアント端末からの要求の有無を問うこと無く、前記第１及び第２のイベント発生情報を前記クライアント端末に対して出力することを特徴とする監視システムが提供される。

本発明の第３の観点によれば、通信装置からの通知情報を取得する取得手段と、前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表す情報を生成し、該生成した情報を第１のイベント発生情報として抽出する抽出手段と、前記第１のイベント発生情報を出力する出力手段と、を備える監視装置としてコンピュータを機能させることを特徴とする監視プログラムが提供される。

本発明によれば、監視対象の装置に関する情報を有効に利用することが可能となる。

本発明の実施形態全体の基本的構成を表す図である。 本発明の実施形態における監視装置やクライアント端末に含まれる機能ブロックを表すブロック図である。 本発明の実施形態における監視装置の基本的動作を表すフローチャートである。 本発明の実施形態におけるｓｙｓｌｏｇファイル群の一例を表す図である。

まず、本発明の実施形態の概略を説明する。本発明の実施形態は、ｓｙｓｌｏｇを利用してネットワーク装置の障害を検知する障害監視システムに関するものである。より具体的には、ｓｙｓｌｏｇをキーワードに基づき検索することにより、保存される全ｓｙｓｌｏｇの中から障害検出に有用なものを抽出する。そして抽出したものを、ＳＮＭＰ（Simple Network Management Protocol）等で通知される障害情報と同様に、クライアントに通知することにより、発生中の障害を表示する。

これにより、ｓｙｓｌｏｇに保存されたトラブル発生原因を即座に、原因が分かりやすい形で表示することを可能とする。

以上が本発明の実施形態の概略である。

次に、本発明の実施形態について図面を参照して詳細に説明する。

図１を参照すると、本実施形態である監視システム監視装置１００は、監視装置１０、クライアント端末２０、第１の通信装置３１、第２の通信装置３２、第３の通信装置３３及び第４の通信装置３４を含む。なお、以下の説明においては、これら第１の通信装置３１、第２の通信装置３２、第３の通信装置３３及び第４の通信装置３４のそれぞれを特定することなく呼ぶ場合に、単に「通信装置」や「各通信装置」と表記する。

監視装置１０は、監視対象となる各通信装置から取得した情報に基づいて、各通信装置に障害が発生しているか否かを監視する。そして、監視装置１０は、障害が発生していることを検知したならば、その旨及びその障害の内容をクライアント端末２０に対して通知する。

ここで、監視装置１０は、汎用のサーバ装置に所定のソフトウェアを組み込むことにより実現することができる。つまり、サーバ装置の演算処理部が、記憶部等を利用して、かかる所定のソフトウェアによる演算処理を行い、かかる演算処理の結果に基づいてサーバ装置内の各ハードウェアを制御することにより監視装置１０を実現できる。

クライアント端末２０は、監視システム監視装置１００を管理するオペレータ等が利用する端末である。クライアント端末２０は、監視装置１０から障害の発生した旨及びその障害の内容を通知されると、通知された内容を画面に表示する。これにより、障害発生時に、オペレータが障害の内容等を即座に認識することが可能となる。

また、クライアント端末２０は、例えば、汎用のパーソナルコンピュータに所定のソフトウェアを組み込むことにより実現することができる。つまり、パーソナルコンピュータの演算処理部が、記憶部等を利用して、かかる所定のソフトウェアによる演算処理を行い、かかる演算処理の結果に基づいてパーソナルコンピュータ内の各ハードウェアを制御することによりクライアント端末２０を実現できる。

なお、監視装置１０及びクライアント端末２０に含まれる具体的な機能ブロックについては、図２を参照して後述する。

他方、各通信装置は、それぞれが通信を行う装置である。各通信装置は、パーソナルコンピュータ等のエンドポイント端末であってもよいが、例えば、ルータやＬ２スイッチといった中継機器であってもよい。何れにせよ、各通信装置もハードウェアや、ハードウェアとソフトウェアの組み合わせにより実現される。

そして、監視システム１００では、通信装置間の接続により通信ネットワーク５０が形成される（かかる接続及び通信ネットワーク５０を図中では実線で表す。）。そして、各通信装置間で所定のデータの送受信を行う。なお、各通信装置間で、送受信されるデータの具体的な種別やその内容に特に制限はない。

一方で、各通信装置は、監視装置１０との接続により監視ネットワーク４０も形成する（かかる接続及び監視ネットワーク４０を図中では実線で表す。）。そして、各通信装置は、かかる監視ネットワーク４０を経由して、監視装置１０に所定の情報を通知する。

ここで、本実施形態における各通信装置は、自通信装置等に障害が発生した場合に、ＳＮＭＰといったプロトコルを用い、障害が発生した旨及びその障害の内容等を監視装置１０に対して通知する。かかる通知される情報を以下の説明においては、「障害トラップ（ＳＮＭＰ）」と呼ぶ。

ここで、ＳＮＭＰに準拠した場合、平常時には監視装置１０から各通信装置への定期的な状態の問い合わせを実施し、各通信装置は、かかる問合せに返答を行う。また、これに加えて、何らかの異常、すなわち障害が発生した場合には、各通信装置から監視装置１０に対して障害トラップ（ＳＮＭＰ）が通知される。

監視装置１０はこれら各通信装置からの情報を収集し、クライアント端末２０に表示をさせる。そして、その表示に基づいて、オペレータが障害解析および障害復旧を実施する。

障害トラップ（ＳＮＭＰ）には、例えば、障害の内容を表すメッセージ、障害トラップ（ＳＮＭＰ）の送信元の通信装置を特定するための情報（例えば、送信元の通信装置のＩＰ（Internet Protocol）アドレスや装置名）、障害種別が含まれる。

ここで、障害種別とは、障害トラップがＳＮＭＰにより各通信装置から送信された障害トラップであるか、ｓｙｓｌｏｇファイルに基づいて障害送信部１５により生成された障害トラップであるか、を識別するための情報である。障害トラップ（ＳＮＭＰ）には、前者であることを識別するための情報が障害種別として付与される。

また、本実施形態では、かかるＳＮＭＰに関連する通信のみならず、ｓｙｓｌｏｇを利用した障害検知も行う。

具体的には、各通信装置は、自通信装置等が所定の状態等になった場合に、かかる所定の状態を表すログデータを監視装置１０に対して通知する。かかるログデータは、ｓｙｓｌｏｇに準拠して通知されることから、以下の説明においては「ログデータ（ｓｙｓｌｏｇ）」と呼ぶ。

そして、上述したように、監視装置１０は受信した全てのログデータ（ｓｙｓｌｏｇ）を対象としてキーワードに基づき検索することにより、障害検出に有用なものを抽出し、抽出した情報に基づいて「障害トラップ（ｓｙｓｌｏｇ）」を生成する。そして、生成した障害トラップ（ｓｙｓｌｏｇ）をクライアント端末２０に通知する。

ここで、障害トラップ（ｓｙｓｌｏｇ）には、ｓｙｓｌｏｇファイルに含まれるメッセージ、ｓｙｓｌｏｇファイルの送信元の通信装置を特定するための情報（例えば、送信元の通信装置のＩＰアドレスや装置名）、障害種別が含まれる。

ここで、上述したように、障害種別とは、障害トラップがＳＮＭＰにより各通信装置から送信された障害トラップであるか、ｓｙｓｌｏｇファイルに基づいて障害送信部１５により生成された障害トラップであるか、を識別するための情報である。障害トラップ（ｓｙｓｌｏｇ）には、後者であることを識別するための情報が障害種別として付与される。

次に、監視装置１０及びクライアント端末２０に含まれる機能ブロックについて図２を参照して説明をする。

図２を参照すると、監視装置１０は、状態障害管理部１１、障害受信部１２、キーワード設定部１３、キーワードデータベース１４、障害送信部１５、ｓｙｓｌｏｇファイル群１６及びキーワード検知部１７を含む。

また、クライアント端末２０は画面表示部２１及び操作部２２を含む。以下これら各機能ブロックについて説明をする。なお、図２では、各通信装置を通信装置群３１、３２、３３及び３４としてまとめて表記する。

状態障害管理部１１は、障害の状態を管理する部分である。状態障害管理部１１は、後述の障害受信部１２より障害トラップを受信する。そして、受信した障害トラップに基づいて自己が管理及び記憶する「状態管理情報」を更新する。具体的には、受信した障害トラップを状態管理情報に新たに追加する更新を行う。

また、状態障害管理部１１は、更新後の状態管理情報をクライアント端末２０に対して送信する。

ここで、送信は、例えばＪＲＭＰ(Java Remote Method Protocol)（登録商標）等を用いて、監視装置１０とクライアント端末２０をリモート接続することにより実現することができる。この場合には、状態管理情報を送信するという表現ではなく、クライアント端末２０が記憶する状態管理情報を監視装置１０が参照可能となるというように表現することもできる。

障害受信部１２は、障害トラップを受信する部分である。障害受信部１２は、各通信装置から障害トラップ（ＳＮＭＰ）を受信する。また、障害受信部１２は、後述の障害送信部１５からも障害トラップ（ｓｙｓｌｏｇ）を受信する。そして、障害受信部１２は、受信した各障害トラップを、状態障害管理部１１に送信する。

キーワード設定部１３は、後述の操作部２２から、キーワードの設定を受け付ける部分である。かかるキーワードは、後述のキーワード検知部１７が、ｓｙｓｌｏｇファイル群１６全体から、障害トラップ（ｓｙｓｌｏｇ）を生成するための情報が含まれているｓｙｓｌｏｇファイルを検知するために用いられる。

ここで、キーワードは、クライアント端末２０を利用するオペレータや、監視装置１０を製造するメーカ等によって設定されるものとする。この際、本実施形態が設置される環境に応じて、選択された文言がキーワードとして選択される。

キーワードの具体例は、例えば「Ｃｈａｓｓｉｄ［」や、「Ｓｙｓｔｅｍ ＣＰＵ」等の文言である。また、キーワードは１つの文言であっても複数の文言であってよい。また、複数の文言を組み合わせて、これらにＡＮＤ条件や、ＯＲ条件を設定することにより１つのキーワードとしてもよい。

また、設定されるキーワードの総数は任意であるが、例えば、１０個程度のキーワードを設定するようにすると良い。更に、キーワードは、オペレータ等がキーボード等の入力デバイスにより文言を入力するようにして設定しても良く、予め準備されている文言をオペレータ等が選択することにより設定するようにしても良い。

キーワードデータベース１４は、キーワード設定部１３により設定されたキーワードが格納されるデータベースである。

障害送信部１５は、後述のキーワード検知部１７が検知した、キーワードを含むｓｙｓｌｏｇファイルを受信し、受信したｓｙｓｌｏｇファイルに基づいて障害トラップ（ｓｙｓｌｏｇ）を生成し、生成した障害トラップ（ｓｙｓｌｏｇ）を障害受信部１２に送信する。

ｓｙｓｌｏｇファイル群１６は、各通信装置から受信したログデータ（ｓｙｓｌｏｇ）を、ｓｙｓｌｏｇファイル群として保存する部分である。

なお、本実施形態ｓｙｓｌｏｇファイル群は上述したように障害トラップ（ｓｙｓｌｏｇ）を生成するために用いられるが、一般的なログデータとしても利用することもできる。例えば、クライアント端末２０から要求があった場合に、監視装置１０は、ｓｙｓｌｏｇファイル群１６をクライアント端末２０に送信する。クライアント端末２０を利用するオペレータ等は、かかるｓｙｓｌｏｇファイル群１６を参照することにより、各通信装置の動作状況の履歴を確認することが可能となる。

キーワード検知部１７は、キーワードデータベース１４を参照することにより、現在設定されているキーワードを取得する。そして、取得したキーワードを検索キーとしてｓｙｓｌｏｇファイル群１６に含まれる各ｓｙｓｌｏｇファイルを検索することにより、キーワードを含むｓｙｓｌｏｇファイルを検知して、抽出する。キーワード検知部１７は、抽出したｓｙｓｌｏｇファイルを、障害トラップ（ｓｙｓｌｏｇ）の生成のために障害送信部１５に対して送信する。

各通信装置は、上述したように障害トラップ（ＳＮＭＰ）や、ログデータ（ｓｙｓｌｏｇ）を監視装置１０に対して送信する。

次に、クライアント端末２０との通信について説明をする。

状態障害管理部１１から、クライアント端末２０に対してＪＲＭＰ等で送信された、障害トラップ（ＳＮＭＰ）や、障害トラップ（ｓｙｓｌｏｇ）といった障害情報は、クライアント端末２０が備える画面表示部２１に表示される。かかる画面表示部２１は例えば液晶等のディスプレイにより実現することができる。

なお、各障害トラップ受信時には、クライアント端末２０の、画面表示部２１に表示するのみならず、クライアント端末２０が備えるスピーカーから警告音を出力するようにしたり、クライアント端末２０に接続されたプリンターから各障害トラップの内容をプリントアウトしたりするようにしても良い。

クライアント端末２０を利用するオペレータ等はこれらの出力を参照することにより、障害の発生や、障害の状況を把握することが可能となる。

次に、操作部２２は、オペレータ等の操作を受け付ける部分であり、例えば、キーボードやタッチパネルやマウスといったデバイスにより実現することができる。操作部２２が受け付けた操作内容は、監視装置１０に送信される。そして、オペレータ等は、画面表示部２１に表示されるキーワードの設定画面を参照しながら、操作部２２を利用してキーワードの設定を行う。

また、オペレータ等は、画面表示部２１に表示される状態管理情報を参照しながら、操作部２２を利用して状態管理情報の更新を行う。ここで、更新とは、例えば、障害に対して対象を行った後に、この対処済みの障害に対応する障害トラップを状態管理情報から削除するようなことである。

次に、図３のフローチャートを参照して、監視装置１０の具体的な動作について詳細に説明する。

なお、以下の説明の前提として、予め操作部２２及びキーワード設定部１３等を利用してオペレータ等が設定したキーワードが、キーワードデータベース１４に格納されているものとする。

まず、障害受信部１２が障害トラップ（ＳＮＭＰ）を受信したか否かを判定する（ステップＳ１０１）。受信したのであれば（ステップＳ１０１において）、受信した障害トラップ（ＳＮＭＰ）に基づいて、状態管理情報を更新する。具体的には、受信した障害トラップ（ＳＮＭＰ）を状態管理情報に追加する更新を行う。

ここで、障害トラップ（ＳＮＭＰ）は、状態障害管理部１１により、例えば、障害の発生した部位単位で障害管理情報として管理される。そして、更新後の状態管理情報は、障害情報として状態障害管理部１１からクライアント端末２０に対して送信される（ステップＳ１０３）。そして、上述したようにクライアント端末２０に対して送信された状態管理情報は、画面表示部２１に表示される。

一方で、障害トラップ（ＳＮＭＰ）を受信していない場合には（ステップＳ１０５）、所定の周期が経過したか否かを判定する（ステップＳ１０５）。ここで、所定の周期とは、キーワード検知部１７がキーワードを含むｓｙｓｌｏｇが存在するか否かの検知を実行する周期である。かかる周期は任意に定めることができる。本例では、かかる周期は１分であるとする。つまり、ステップＳ１０５では、前回キーワード検知部１７が検知を行ってから１分が経過したか否かを判定する。

ここで、未だ１分が経過していない場合は（ステップＳ１０５においてＮｏ）、ステップＳ１０１に戻り処理を継続する。

一方で、１分が経過した場合には、ステップＳ１０７に遷移して、キーワード検知部１７がｓｙｓｌｏｇファイル群１６に対してキーワード検知を実行する（ステップＳ１０７）。

かかるキーワード検知について図４を参照して説明を行う。図４にはｓｙｓｌｏｇファイル群１６に含まれるｓｙｓｌｏｇファイルの一例を表す。なお、これらｓｙｓｌｏｇファイルのそれぞれは、各通信装置から受信したログデータ（ｓｙｓｌｏｇ）を保存したものである。

図４に示すように、各ｓｙｓｌｏｇファイルは、時刻、送信元装置名及びメッセージを含む。

ここで、時刻は、ｓｙｓｌｏｇファイルの元となるログデータ（ｓｙｓｌｏｇ）が生成された時刻である。また、送信元装置名は、ログデータ（ｓｙｓｌｏｇ）の送信元の通信装置の名称である。なお、送信元装置名を、送信元装置を特定するための他の情報に置き換えるようにしても良い。例えば、送信元装置に割当てられたＩＰアドレスとしても良い。メッセージは、障害の発生を検知するための情報が含まれていれば、任意の内容であって良い。具体的なメッセージの内容としては、例えば、「chassisd[4196]: CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power off」「System CPU utilization is high」というメッセージにすると良い。このメッセージは、通信装置が「電源ユニットがPower OffとなりTrapが生成」「CPU使用率が高くなった」という状態になったことを表すメッセージである。

また、図４に表す例では、ｓｙｓｌｏｇファイル群１６を、１つのファイル群として管理している。しかし、このようにするのではなく、監視対象の通信装置毎にファイル群を作成して、通信装置毎に管理をするようにしても良い。

キーワード検知部１７は、このようなｓｙｓｌｏｇファイル群１６を対象としてキーワード検知を行う。まず、キーワード検知部１７はキーワードデータベース１４を参照して現在設定されているキーワードを確認する。ここで、キーワードとして、例えば「Ｓｙｓｔｅｍ ＣＰＵ」が設定されていたとする。

すると、キーワード検知部１７は、かかる「Ｓｙｓｔｅｍ ＣＰＵ」検索キーとして、ｓｙｓｌｏｇファイル群１６内のメッセージの項目を検索する。そして、検索キーと一致する文言が含まれているメッセージを検知すると、このメッセージを含んだｓｙｓｌｏｇファイルを検出する。

ここで、ｓｙｓｌｏｇファイル群１６には、徐々に多数のｓｙｓｌｏｇファイルが蓄積されていく。これに対して、１分間の検出のたびに全てのｓｙｓｌｏｇファイルを検索対象とすると、検知に要する時間が長くなってしまう。また、演算処理量も増加する。

そこで、本実施形態では、直近の所定時間の時刻情報を持つｓｙｓｌｏｇファイルのみを検索対象とする。例えば、上述したように１分間周期で検知を行うのであれば、図４の左下に示すように直近１分間の時刻情報を持つｓｙｓｌｏｇファイルのみを検索対象とする。これにより、検知に要する時間を短くすると共に、演算処理量を減らすことが可能となる。

例えば、図４の例で言えば、現在が「Ｎｏｖ ２２ １５：０５：００」であるとしたならば、直近１分間のｓｙｓｌｏｇファイルを検索対象として、キーワード「Ｓｙｓｔｅｍ ＣＰＵ」を含んだｓｙｓｌｏｇファイル、具体的には図中上から４つ目のｓｙｓｌｏｇファイルが抽出される。

なお、ｓｙｓｌｏｇファイルが生成されてから、監視装置１０がｓｙｓｌｏｇファイルを受信するまでのタイムラグがあることを考慮して、１分間周期で検知を行う場合に、直近１分間ではなく、直近１分数秒間や、１分数十秒間の時刻情報を持つｓｙｓｌｏｇファイルを検索対象とするようにしても良い。このようにして、前回検知したｓｙｓｌｏｇファイルと同一のｓｙｓｌｏｇファイルを仮に再度検知したとしても、この再度の検知は無かったものとして取り扱うようにすると良い。これにより、上記のタイムラグを考慮できると共に、検知が重複することも防止することが可能となる。

このようにして、キーワード検知部１７は、キーワードを含んだメッセージを有するｓｙｓｌｏｇファイルを検知すると（ステップＳ１０９においてＹｅｓ）、かかるｓｙｓｌｏｇファイルを抽出する。そして、抽出したｓｙｓｌｏｇファイルを障害送信部１５に送信する。

かかるｓｙｓｌｏｇファイルを受信した障害送信部１５は、受信したｓｙｓｌｏｇファイル内の情報に基づいて障害トラップ（ｓｙｓｌｏｇ）を生成する（ステップＳ１１１）。障害トラップ（ｓｙｓｌｏｇ）の内容については上述した通りである。生成した障害トラップ（ｓｙｓｌｏｇ）は、障害受信部１２を介して状態障害管理部１１に送信される。

一方で、キーワードを含んだメッセージを検知しなかった場合には（ステップＳ１０９においてＮｏ）、ステップＳ１０１に戻り、処理を継続する。

次に、ステップＳ１１３において、状態障害管理部１１は、受信した障害トラップ（ｓｙｓｌｏｇ）に基づいて、状態管理情報を適宜更新する。

具体的には、受信した障害トラップ（ｓｙｓｌｏｇ）を状態管理情報に追加する更新を行う。そして、更新後の状態管理情報は、障害情報として状態障害管理部１１からクライアント端末２０に対して送信される（ステップＳ１１３）。そして、上述したようにクライアント端末２０に対して送信された状態管理情報は、画面表示部２１に表示される。

ここで、状態障害管理部１１は、障害受信部１２から受信した障害トラップ（ｓｙｓｌｏｇ）全てに基づいて状態管理情報の更新をしても良い。

しかしながら、クライアント端末２０を利用するオペレータ等は、障害が発生した箇所や、発生した障害の内容を把握することができればよく、その障害が繰り返し発生している事実は特に把握しなくとも良い場合が考えられる。

そこで、このような場合には、同様な障害トラップ（ｓｙｓｌｏｇ）を利用して、何度も状態管理情報を更新はせず、必要な場合にのみ適宜更新するようにする。これにより、同様な障害についての更新が大量になされてしまい、オペレータ等が、他の大切な更新を見落としてしまうようなことを防止することができる。

このようにするために、本実施形態では、状態障害管理部１１が障害受信部１２から受信した障害トラップ（ｓｙｓｌｏｇ）について、障害トラップ（ｓｙｓｌｏｇ）単位で状態管理情報として管理する。そして、通常は、障害トラップ（ｓｙｓｌｏｇ）を新たに受信したとき、状態管理情報に１件追加する。

しかしながら、障害トラップ（ｓｙｓｌｏｇ）を受信したとき、同一通信装置・同一メッセージの状態管理情報が登録済みの場合は、状態管理情報の更新は行わない。つまり、この受信した障害トラップ（ｓｙｓｌｏｇ）を状態管理情報に新たに追加する処理は行なわない。ここで、同一メッセージとは、障害の発生時刻以外のデータが完全に一致するものをいう。キーワード検知のキーワードが一致しただけでは、同一メッセージではなく、異なったメッセージとする。

このようにして、本実施形態では、或る通信装置において、同様の障害が連続して発生し、障害トラップ（ｓｙｓｌｏｇ）を複数回受信した場合であっても、２回目以降の障害の発生時刻のみが異なり、送信元の通信装置及びメッセージの内容が同一の障害トラップ（ｓｙｓｌｏｇ）を利用した更新は行なわない。

そして、更新を行わないことにより、障害が最初に発生した時の状態管理情報のまま、すなわち、障害発生時刻を保ったままとなると共に、新たに状態管理情報が１件追加されることはなくなる。

そのため、同様な障害についての更新が大量になされてしまい、オペレータ等が、他の大切な更新を見落としてしまうようなことを防止することができる。

ステップＳ１１３の処理を終了後、監視装置１０は、ステップＳ１０１に戻り処理を継続する。

以上、本実施形態の動作について説明した。

なお、障害管理情報は、オペレータ等により、その内容を変更することもできる。具体的には、障害管理情報に含まれる障害トラップを参照したオペレータ等は、障害が発生したことを把握する。すると、オペレータ等は、障害の発生した通信装置に対して対処を行うことにより、障害を復旧させる。

その後、オペレータ等は、操作部２２を利用して手動で、復旧済みの障害に対応する障害トラップの削除操作を行う。かかる操作内容は、状態障害管理部１１に通知され、状態障害管理部１１は、対応する障害トラップを状態管理情報から削除する。これにより、以後、すでに復旧済みの障害に対応する障害トラップが画面表示部２１に表示されることを防止できる。

また、削除後に再度、同様の障害が発生して、その旨を表す障害トラップ（ｓｙｓｌｏｇ）等を再度受信したような場合には、再度受信した障害トラップ（ｓｙｓｌｏｇ）は、情報管理情報に１件追加されることとなる。そのため、オペレータ等は、障害が再発したことを把握することも可能となる。

以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。

第１の効果は、ｓｙｓｌｏｇファイル群に新たにログデータ（ｓｙｓｌｏｇ）が記載された場合に、障害発生を抽出して通知できることである。その理由は、従来のように、ｓｙｓｌｏｇファイルに、単に動作状況を表すログデータ（ｓｙｓｌｏｇ）と、障害の発生を把握するために利用できるログデータ（ｓｙｓｌｏｇ）が混在している状態でも、キーワードに一致するメッセージを含むログデータ（ｓｙｓｌｏｇ）を、障害の発生を把握するために利用できるログデータ（ｓｙｓｌｏｇ）として抽出できるからである。

第２の効果は、オペレータ等が、発生中の障害を把握することが容易になることである。その理由は、障害が発生して、ｓｙｓｌｏｇログファイル群に連続して同じ障害のログデータ（ｓｙｓｌｏｇ）が保存される場合に、最初のログデータ（ｓｙｓｌｏｇ）に基づいて生成した障害トラップ（ｓｙｓｌｏｇ）のみを障害管理情報に追加するからである。つまり、オペレータ等は、全ての情報を確認せずに、監視装置により抽出された情報のみを確認するのみで足りるからである。

第３の効果は、キーワード検知を高速に実行できることである。その理由は、ｓｙｓｌｏｇファイル群に含まれる全てのログデータ（ｓｙｓｌｏｇ）を対象として検索を行うこと無く、所定時間の間のログデータ（ｓｙｓｌｏｇ）を対象として検索を行えば良いからである。

なお、上記の監視システムに含まれる監視装置等の各機器は、それぞれが、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の監視システムに含まれる監視装置等の各機器により行なわれる監視方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory）)を含む。

また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変形を施した形態での実施が可能である。以下、幾つかの変形例を例示する。

上述した実施形態では、障害の発生を検知するためのログデータ（ｓｙｓｌｏｇ）を抽出できるようなキーワードを設定していた。しかしながら、キーワードを異なるものとすることにより、障害の発生を検知する以外の用途に上述の実施形態を利用するようにしても良い。例えば、リソースの使用量を把握するための（ｓｙｓｌｏｇ）を抽出できるようなキーワードを設定するようにしても良い。

また、図１では、監視装置１０とクライアント端末２０を、１対１として記載しているが、必ずしもこのようにする必要はない。例えば、１つの監視装置１０に複数のクライアント端末２０が接続されるようにしても良い。また、図１では、通信装置の台数を４台としているが、通信装置の台数も４台には限定されず、任意の台数とすることが可能である。

更に、上述の実施形態では、クライアント端末２０に対してる障害トラップ（ＳＮＭＰ）と、障害トラップ（ｓｙｓｌｏｇ）を含んだ状態管理情報を通知するとしていたがこれを変形するようにしても良い。例えば、これらの障害トラップの情報をそのまま通知するのではなく、これらの障害トラップから必要な情報を取得して、所定のフォーマットに沿って情報を見やすくするように編集しても良い。これにより、オペレータ等が、情報の内容を把握しやすくなるので良い。他にも、例えば、状態障害管理部１１等で、各障害トラップに任意の情報を追加してからクライアント端末２０に送信するようにしても良い。例えば、各障害トラップの生成された時刻のみならず、各障害トラップをクライアント端末２０が受信した時刻も情報として追加するようにしても良い。

更に、クライアント端末２０からの要求の有無を問うこと無く、画面表示部２１への状態管理情報の表示を行うようにすると良い。

監視装置１０の、機能の一部をクライアント端末２０にて実現するようにしても良い。例えば、状態障害管理部１１が行っていた状態管理情報の管理をクライアント端末２０で行うようにしても良い。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）
通信装置からの通知情報を取得する取得手段と、
前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表す情報を生成し、該生成した情報を第１のイベント発生情報として抽出する抽出手段と、
前記第１のイベント発生情報を出力する出力手段と、
を備えることを特徴とする監視装置。

（付記２）
前記抽出手段は、前記取得手段が取得した前記通知情報が前記所定のイベントの発生を表すイベント発生情報であれば該イベント発生情報を第２のイベント発生情報として抽出し、
前記出力手段は、前記第１のイベント発生情報に加えて、更に前記第２のイベント発生情報を出力することを特徴とする付記１に記載の監視装置。

（付記３）
前記所定のイベントの発生とは、前記通信装置における障害の発生であり、
前記出力手段は、前記通信装置に障害が発生した旨の通知を行うために、外部に対して前記出力をすることを特徴とする付記１又は２に記載の監視装置。

（付記４）
一度抽出した前記所定のキーワードが含まれるメッセージと同一のメッセージが再度抽出された場合に、該再度抽出されたメッセージに基づいて生成する前記第１のイベント発生情報は出力しないことを特徴とする付記１乃至３の何れか１に記載の監視装置。

（付記５）
一度抽出した前記所定のキーワードが含まれるメッセージと同一のメッセージが再度抽出された場合に、前記メッセージを出力した出力先から所定の返答を得たことを条件として、前記再度抽出されたメッセージに基づいて生成する前記第１のイベント発生情報を出力することを特徴とする付記４に記載の監視装置。

（付記６）
前記抽出手段は、前記抽出行うにあたり、一度前記所定のキーワードが含まれているか否かの判定の対象とした通知情報については、以後前記判定の対象とはしないことを特徴とする付記１乃至５の何れか１に記載の監視装置。

（付記７）
前記メッセージ取得手段が取得した通知情報を、各通知情報が前記抽出手段により抽出されたか否かに関わらず記憶する記憶手段を更に備え、
前記通信手段は、前記記憶手段が記憶しているメッセージの参照要求があった場合には、該要求元に対して前記記憶しているメッセージを出力することを特徴とする付記１乃至６の何れか１に記載の監視装置。

（付記８）
前記通信装置の状態を表すメッセージとは、ｓｙｓｌｏｇに準拠したログデータに含まれるメッセージであることを特徴とする付記１乃至７の何れか１に記載の監視装置。

（付記９）
前記抽出手段は、所定の周期で前記抽出を行うことを特徴とする付記１乃至６の何れか１に記載の監視装置。

（付記１０）
付記１乃至９の何れか１に記載の監視装置と、クライアント端末とを備える監視システムであって、
前記通信手段は、前記クライアント端末からの要求の有無を問うこと無く、前記第１及び第２のイベント発生情報を前記クライアント端末に対して出力することを特徴とする監視システム。

（付記１１）
付記１乃至９の何れか１に記載の監視装置と、前記クライアント端末通信装置とを備える監視システムであって、
前記通信装置は、
該通信装置に前記所定のイベントが発生した場合にイベントの発生を表すイベント発生情報を前記通知情報として前記監視装置に対して送信すると共に、
該通信装置が所定の状態となった場合に、該所定の状態を表すメッセージを前記通知情報として前記監視装置に対して送信する、ことを特徴とする監視システム。

（付記１２）
通信装置からの通知情報を取得する取得手段と、
前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表すイベント発生情報を生成して第１のイベント発生情報として抽出する抽出手段と、
前記第１のイベント発生情報を出力する出力手段と、
を備える監視装置としてコンピュータを機能させることを特徴とする監視プログラム。

（付記１３）
ネットワーク装置が持つ障害通知機能として装置のログデータをファイルに記録するｓｙｓｌｏｇと呼ばれる機能が保存するメッセージを利用した障害記録手段と、前記記録手段からの障害内容を含めるメッセージを検知する障害検知手段と、障害発生装置・障害内容を外部に通知する障害通知機能、同じ障害が連続発生に対する状態を管理する障害状態管理手段と、ｓｙｓｌｏｇアラートを検知するためのキーワードを設定するためのキーワード設定手段と、キーワードを含むｓｙｓｌｏｇのログメッセージを検知するキーワード検知手段と、キーワード検知したログメッセージを送信・通知する障害送信手段と、障害受信する障害受信手段と、障害の状態を管理する障害状態管理部を備える監視装置。

本発明は、通信装置の管理に用いることができ、特に通信装置の障害検出に好適である。

１０ 監視装置
１１ 状態障害管理部
１２ 障害受信部
１３ キーワード設定部
１４ キーワードデータベース
１５ 障害送信部
１６ ｓｙｓｌｏｇファイル群
１７ キーワード検知部
２０ クライアント端末
２１ 画面表示部
２２ 操作部
３１ 第１の通信装置
３２ 第２の通信装置
３３ 第３の通信装置
３４ 第４の通信装置
４０ 監視ネットワーク
５０ 通信ネットワーク
１００ 監視システム監視装置

Claims (10)

1. 通信装置からの通知情報を取得する取得手段と、
   前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表す情報を生成し、該生成した情報を第１のイベント発生情報として抽出する抽出手段と、
   前記第１のイベント発生情報を出力する出力手段と、
   を備えることを特徴とする監視装置。
2. 前記抽出手段は、前記取得手段が取得した前記通知情報が前記所定のイベントの発生を表すイベント発生情報であれば該イベント発生情報を第２のイベント発生情報として抽出し、
   前記出力手段は、前記第１のイベント発生情報に加えて、更に前記第２のイベント発生情報を出力することを特徴とする請求項１に記載の監視装置。
3. 前記所定のイベントの発生とは、前記通信装置における障害の発生であり、
   前記出力手段は、前記通信装置に障害が発生した旨の通知を行うために、外部に対して前記出力をすることを特徴とする請求項１又は２に記載の監視装置。
4. 一度抽出した前記所定のキーワードが含まれるメッセージと同一のメッセージが再度抽出された場合に、該再度抽出されたメッセージに基づいて生成する前記第１のイベント発生情報は出力しないことを特徴とする請求項１乃至３の何れか１項に記載の監視装置。
5. 一度抽出した前記所定のキーワードが含まれるメッセージと同一のメッセージが再度抽出された場合に、前記メッセージを出力した出力先から所定の返答を得たことを条件として、前記再度抽出されたメッセージに基づいて生成する前記第１のイベント発生情報を出力することを特徴とする請求項４に記載の監視装置。
6. 前記抽出手段は、前記抽出行うにあたり、一度前記所定のキーワードが含まれているか否かの判定の対象とした通知情報については、以後前記判定の対象とはしないことを特徴とする請求項１乃至５の何れか１項に記載の監視装置。
7. 前記メッセージ取得手段が取得した通知情報を、各通知情報が前記抽出手段により抽出されたか否かに関わらず記憶する記憶手段を更に備え、
   前記通信手段は、前記記憶手段が記憶しているメッセージの参照要求があった場合には、該要求元に対して前記記憶しているメッセージを出力することを特徴とする請求項１乃至６の何れか１項に記載の監視装置。
8. 前記通信装置の状態を表すメッセージとは、ｓｙｓｌｏｇに準拠したログデータに含まれるメッセージであることを特徴とする請求項１乃至７の何れか１項に記載の監視装置。
9. 請求項１乃至８の何れか１項に記載の監視装置と、クライアント端末とを備える監視システムであって、
   前記通信手段は、前記クライアント端末からの要求の有無を問うこと無く、前記第１及び第２のイベント発生情報を前記クライアント端末に対して出力することを特徴とする監視システム。
10. 通信装置からの通知情報を取得する取得手段と、
    前記取得手段が取得した前記通知情報に前記通信装置の状態を表すメッセージであって所定のキーワードが含まれているメッセージが含まれていれば、該メッセージに基づいて所定のイベントの発生を表すイベント発生情報を生成して第１のイベント発生情報として抽出する抽出手段と、
    前記第１のイベント発生情報を出力する出力手段と、
    を備える監視装置としてコンピュータを機能させることを特徴とする監視プログラム。

Images