(57)【要約】【課題】  効率的に保守対応を行うことを可能とする障害通知装置を得る。【解決手段】  監視対象装置が備えるオペレーションシステムから障害に関するログを取得する監視手段と、前記オペレーションシステムから取得したログの重要度を判別する分析手段と、前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する通知手段と、を有する障害通知装置。【選択図】      図９
2014228932.tif 000002
【特許請求の範囲】
【請求項１】
監視対象装置が備えるオペレーションシステムから障害に関するログを取得する監視手段と、
前記オペレーションシステムから取得したログの重要度を判別する分析手段と、
前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する通知手段と、
を有する障害通知装置。
【請求項２】
前記閾値以上のログを保存する保存部と、
前記保存部を監視すると共に、新規のログが登録されている場合、その新規ログを前記障害通知情報として登録する管理部とを有し、
前記通知部は前記管理部を監視すると共に、前記新規ログが登録されている場合に、前記障害通知情報を通知する請求項１の障害通知装置。
【請求項３】
アプリケーションプログラムを監視する実行監視手段を更に有し、
前記管理部は、前記実行監視部が取得した前記アプリケーションプログラムに関する障害メッセージを前記障害通知情報として登録する請求項２の障害通知装置。
【請求項４】
前記分析部は、前記監視対象装置が実行することを可能とする複数のアプリケーションプログラム毎に前記ログの重要度を判別し、前記通知部は前記監視対象装置が実行しているアプリケーションプログラムに対応する前記ログの内容を障害通知情報として通知する請求項１乃至３のいずれかに記載の障害通知装置。
【請求項５】
監視対象装置が備えるオペレーションシステムから障害に関するログを取得する監視処理と、
前記オペレーションシステムから取得したログの重要度を判別する分析処理と、
前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する通知処理と、
をコンピュータに実行させる障害通知プログラム。
【請求項６】
前記閾値以上のログを保存する保存処理と、
前記保存部を監視すると共に、新規のログが登録されている場合、その新規ログを前記障害通知情報として登録する管理処理と、
前記新規ログが登録されている場合に、前記障害通知情報を通知する前記通知処理とを前記コンピュータに実行させる、請求項５の障害通知プログラム。
【請求項７】
アプリケーションプログラムを監視する実行監視処理と、前記実行監視処理で取得した前記アプリケーションプログラムに関する障害メッセージを前記障害通知情報として登録する前記管理処理を前記コンピュータに実行させる請求項６の障害通知プログラム。
【請求項８】
前記監視対象装置が実行することを可能とする複数のアプリケーションプログラム毎に前記ログの重要度を判別する前記分析処理と、前記監視対象装置が実行しているアプリケーションプログラムに対応する前記ログの内容を障害通知情報として通知する前記通知処理を前記コンピュータに実行させる請求項５乃至７のいずれかに記載の障害通知プログラム。
【請求項９】
監視対象装置が備えるオペレーションシステムから障害に関するログを取得し、
前記オペレーションシステムから取得したログの重要度を判別し、
前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する障害通知方法。
【請求項１０】
前記閾値以上のログを保存部に保存し、前記保存部を監視すると共に、新規のログが登録されている場合、その新規ログを前記障害通知情報として登録し、前記新規ログが登録されている場合に、前記障害通知情報を通知する請求項９の障害通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ（情報処理装置）に発生する障害を通知する技術に関する。
【背景技術】
【０００２】
分散コンピュータネットワークシステムは、プログラムを構成する個々の部分が同時並行的に複数のコンピュータで実行され、それらがネットワークを介して互いに通信しあうシステムである。したがって、分散コンピュータネットワークシステムを利用すると、一台のコンピュータで計算した場合にくらべて、スループットが向上する。このような分散コンピュータネットワークシステムの監視は、分散しているオフィス先のコンピュータに対してなされなければならないので、遠隔操作でのコマンド制御が必要となる。
【０００３】
特許文献１は、大規模な分散コンピュータネットワークシステムにおける複数装置の管理や監視に関して、統合的なネットワーク監視システムを用いて保守運用を行うシステムを開示する。このネットワーク監視システムは、サーバのリモート監視を行う手段として、監視対象装置に、その監視対象装置の情報収集を行うための情報収集エージェント(プログラム)を組み込んでいる。また、このネットワーク監視システムは、監視装置にネットワーク監視マネージャ(プログラム)を組み込んでいる。図２は、このようなネットワーク監視システムの全体構成を示す図である。ネットワーク監視システムは、保守用ネットワーク監視装置１３０に組み込むネットワーク監視マネージャ機能１３１と、監視対象装置１００、１１０、１２０に組み込む監視エージェント機能１０２、１１２、１２２で構成される。監視対象装置１００、１１０、１２０にはそれぞれ、アプリケーションプログラム１０１、１１１、１２１を組み込んでいる。監視エージェント機能１０２、１１２、１２２によって検知された監視対象装置１００、１１０、１２０の障害情報は、ネットワーク監視マネージャ機能１３１へ通知される。この障害情報は、ネットワーク監視マネージャ機能１３１が実装する独自のＧＵＩ画面１３１ａに表示される。障害の通知先はこのＧＵＩ画面１３１ａ（ＧＵＩ：Ｇｒａｐｈｉｃ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）に限定される。
【０００４】
この方式を、既に運用中の大規模な分散コンピュータネットワークシステム等のネットワークシステムに導入しようとすると、上記のような統合的なネットワーク監視システムやサーバ管理ソフトウェアを、既存のシステムに新たに組み込む必要がある。
【０００５】
一方、一般に運用中のネットワークシステムには、一元的に管理可能な統合監視機能を搭載している。例えば、図３ａに示すように、既存の分散コンピュータシステムには、保守用ネットワーク監視装置１７０の保守作業用ＧＵＩ画面１７１ａから、監視対象となる複数の装置の管理を行う統合監視機能１７１が既に実装されているのが現状である。統合監視機能１７１は、監視対象装置１４０、１５０の稼働状態や障害発生状況等の確認を保守作業用ＧＵＩ画面１７１ａから一元的に行う。また統合監視機能１７１は、この保守作業用ＧＵＩ画面１７１ａから、各種のメンテナンス操作も行う。ここで、監視対象装置１４０、１５０には、それぞれ、障害監視および通知機能を有するアプリケーションプログラム１４１、１５１が組み込まれている。このため、図３ａのシステムに新たに監視対象装置１６０を追加し、この追加に伴って統合ネットワーク監視システムやサーバ管理ソフトウェアを組み込む場合、既存のモニタ装置が、重複する構成となる。図３ｂは、運用中のネットワーク監視装置１７０に、ネットワーク監視マネージャ機能１７２で監視される監視対象装置１６０を追加し、ネットワーク監視マネージャ機能１７２を保守用ネットワーク監視装置１７０にインストールした構成を示す。保守者は既存のＧＵＩ画面１７１ａとネットワーク監視マネージャ機能１７２が提供するＧＵＩ画面１７２ａの、２つの画面から確認作業やメンテナンス操作を行わなければならない。その結果、保守者の作業が煩雑となり作業効率が低下するという問題が発生する。
【０００６】
また、安定稼働しているシステム運用中の装置に、新たなプログラムの追加やソフトウェアを組み込むことは、運用中のアプリケーション動作に影響を及ぼす可能性があるため、容易に実施することはできないという問題がある。
【０００７】
一方、監視で得られる情報は、ＵＮＩＸ（登録商標）系ＯＳ（Ｏｐｅｒａｔｉｏｎ  Ｓｙｓｔｅｍ）のロギング機能を利用しても得ることができる。ＵＮＩＸ系のＯＳは、システム上で発生した各種イベントや状態変化などの動作ログをファイルに記録するシステムログ（ｓｙｓｌｏｇ）と呼ばれるロギング機能を有している。このロギング機能は、ユーザのログイン日時から、カーネル・パニックなどの異常発生時の状況まで、システムに関するさまざまな事象をシステムログファイルに記録する。このためシステムログは、障害発生時の原因追求や不正アクセスの痕跡探しなど、システム管理を行うための重要な情報源となっている。したがって、このロギング機能は、情報収集エージェントや、ネットワーク監視マネージャを、代替することができる。この代替により、既存の分散コンピュータネットワークに統合ネットワーク監視システム等を組み込む場合にも、ネットワーク監視マネージャ機能をインストールする必要はなくなり、ユーザの作業効率の低下は免れられる。
【０００８】
しかし、システムログの内容は一般に複雑である。この内容には障害情報のみならず所定の動作履歴がすべて盛り込まれている。単に障害情報を得ることが目的の場合、システムログは情報過多とも言える。該当するメッセージを１つ１つ確認して、緊急を要する内容のものか、その障害のレベルを判断する必要があるため、保守者の手を煩わせるばかりか、緊急時の障害原因の分析に時間を要するという問題が生じる。
【０００９】
特許文献２では、ＵＮＩＸサーバで発生した障害を検知し、その障害内容を複数の異なるログファイルに記録し、システム保守者に通知するシステムを開示している。しかしこのシステムは、障害すべてについて通知するため、保守者にとって原因を切り分ける作業が不可欠である。インフォメーションレベルで緊急を要さない状態変化やログイン情報などのメッセージから、システム管理者が介在して緊急に対応を必要とする障害発生に伴うメッセージまで、多岐に渡るログが通知される。したがって、システム保守者はその情報を整理することに忙殺されるという問題がある。
【００１０】
特許文献３は、システム管理に資するシステムログに関するデータを管理するログ情報管理装置及びログ情報管理プログラムを開示している。このログ情報管理プログラムは、システムログファイル内のメッセージのキーワード検索を可能とし、システム管理者が、障害発生原因の追求等に最適なログ情報を適宜に抽出できる技術を提供している。しかし、このシステムは、検索に必要な工数を発生させる。
【００１１】
ログ情報を選択して通知することにより、保守者の負担を軽減しているものとしては、
特許文献４に開示された技術が挙げられる。特許文献４は、ログ管理アプリケーションがドライバアプリケーションから出力されるログデータを監視し、エラーレベルを判定した後、所定レベル以上のエラーについてはログデータベースに記録することを、開示している。
【００１２】
また、特許文献５は、システム運用中の障害を集中監視し、障害を検知した際に起動処理部に保存されているログ情報を採取して、警報メッセージとともに外部のリモート保守管理システムに通報することを開示されている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００４−０２１５４９号公報
【特許文献２】特開２０００−１４８５４１号公報
【特許文献３】特開２００３−１４１０７５号公報
【特許文献４】特開２００９−１５１６８０号公報
【特許文献５】特開２００１−３２５１２４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
特許文献１の技術における問題点である、２つの画面を用いて確認作業やメンテナンス操作を行なうという煩雑さ、並びに特許文献２の技術における、検索作業の複雑さは、分散コンピュータシステムの監視を困難にする原因となっている。
【００１５】
特許文献４の技術は、アプリケーションから出力されるログデータでエラーレベルを判定しているので、より深刻なエラーレベルがオペレーションシステムで発生していても、これを検出できるものではない。また、複数のアプリケーションを同時に起動している場合、重複するエラーメッセージが発生することがあり、効率的な対処が阻まれる。また、同じ原因に起因するエラーであっても、アプリケーションによって異なる現象で現れることがあるため、特許文献４の手段は根本的な解決にはつながらない。
【００１６】
特許文献５の技術は、アプリケーションの起動段階で発生したエラーについては、起動処理部に保存されたログデータをすべてリモート保守管理システムに通報するが、ＯＳで発生したエラー一般について通報が行われるものではない。また、障害時にはすべてのログデータが通報されるため、システム保守者に判定の負担がかかる。さらに、この技術では、一端正常に起動した場合は、アプリケーションから出力されるログデータが利用されるため、特許文献４と同様、根本的な解決手段とはならない。
【００１７】
本発明の目的は、保守者が効率的に保守対応を行うことを可能とするように、エラーメッセージを通知する、障害通知装置等を提供することである。
【課題を解決するための手段】
【００１８】
本発明によれば、
監視対象装置が備えるオペレーションシステムから障害に関するログを取得する監視手段と、前記オペレーションシステムから取得したログの重要度を判別する分析手段と、前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する通知手段と、を有する障害通知装置が得られる。
【００１９】
本発明によれば、監視対象装置が備えるオペレーションシステムから障害に関するログを取得する監視処理と、前記オペレーションシステムから取得したログの重要度を判別する分析処理と、前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する通知処理と、コンピュータに実行させる障害通知プログラムが得られる。
【００２０】
本発明によれば、監視対象装置が備えるオペレーションシステムから障害に関するログを取得し、前記オペレーションシステムから取得したログの重要度を判別し、前記ログのうち、前記重要度が閾値以上のログの内容を表す障害通知情報を通知する障害通知方法が得られる。
【発明の効果】
【００２１】
本発明によれば、保守者が効率的に保守対応を行うことを可能とするように、障害情報を通知する障害通知装置等が得られる。
【発明を実施するための形態】
【００２２】
次に、本発明の実施の形態について、基本的構成内容を説明する。
【００２３】
本発明の実施形態の構成について、図面を参照して詳細に説明する。
【００２４】
図１は、本発明の一実施形態に係わる障害通知装置を備える分散コンピュータネットワークの機能ブロック図である。
【００２５】
本発明における障害通知装置３０１は、一例として監視対象ＵＮＩＸ装置１に備えられる。障害通知装置３０１は監視エージェント機能１１、システムログ機能１２、障害ログファイル１２ｃ、障害通知機能１５を備える。監視対象ＵＮＩＸ装置１は、障害通知装置３０１と、システムログ１２ａ、各種ログ１２ｂ、障害監視機能１３、障害管理機能１４、障害通知情報管理テーブル１４ａ、障害通知機能１５を備える。
【００２６】
この監視対象ＵＮＩＸ装置１は、分散コンピュータネットワークシステムにおいて動作する。分散コンピュータネットワークシステムには、他に監視対象装置Ａ３、監視対象装置Ｂ４、監視対象装置Ｃ５、監視対象装置Ｄ６、監視対象装置Ｅ７、監視対象装置Ｆ８が接続されている。
【００２７】
監視エージェント機能１１は監視対象ＵＮＩＸ装置１のオペレーションシステムの動作状況を監視し、その動作状況を表すログを取得して、取得したログをシステムログ機能１２に通知する。監視エージェント機能１１は監視部３１０とも呼ばれる。
【００２８】
システムログ機能１２は、例えばＵＮＩＸ系のＯＳにより提供される。システムログ機能１２は、ＵＮＩＸ系ＯＳの基本機能を実装したソフトウェア(ｋｅｒｎｅｌ)や、バックグラウンドで動作するプログラム(デーモン)等の動作や操作、障害情報等の様々なメッセージを、システムログ１２ａとして記録する。なお監視エージェント機能１１は監視部３１０とも呼ぶ。また、システムログ機能１２は、各種のログを各種ログ１２ｂとして記録する。各種のログとは、ＵＮＩＸ系ＯＳに標準機能として組み込まれているメールサーバソフトウェア、ジョブの定時自動実行プログラム等、ＯＳ標準の機能がその動作ログや障害情報等のメッセージを、機能毎のファイルとして記録したものである。ここで、メールサーバソフトウェアとはｓｅｎｄｍａｉｌ等である。また、ジョブの定時自動実行プログラムとはｃｒｏｎ等である。なお、各種ログ１２ｂは、ファイル群である。
【００２９】
また、システムログ機能１２は、監視エージェント機能１１が検知した監視対象ＵＮＩＸ装置１のハードウェアに生じた障害を通知するメッセージを障害ログファイル１２ｃに記録する。
【００３０】
また、システムログ機能１２は、システムログ１２ａ、各種ログ１２ｂに記録されたメッセージのうち、障害レベルを示す「重要度」が高いメッセージを選択して障害ログファイル１２ｃに格納する。なお、システムログ機能１２は分析部３２０とも呼ばれる。
【００３１】
図４は、障害ログファイル１２ｃの記載内容の一例を示す図である。障害ログファイル１２ｃに記録されるメッセージの「重要度」は、４：ｅｍｅｒｇ(システムが利用できないほどのエラー)、３：ａｌｅｒｔ(緊急に対処すべきエラー)、２：ｃｒｉｔ(致命的なエラー)、１：ｅｒｒ(一般的なエラー)の４段階である。記録対象とするメッセージの「重要度」は、システムログ設定ファイル１２ｄで定義される。例として、システムログ設定ファイル１２ｄは、「重要度４のみ記録」、「重要度３、４を記録」、「重要度１〜４をすべて記録」という規則で記録すべき重要度を定義する。図４は後述するように、システムログ設定ファイル１２ｄにおいて、「重要度３、４を記録」することを定義された場合である。これを言い換えれば、図４は、重要度の閾値を３とする場合の、障害ログファイル１２ｃの例である。システムログ設定ファイル１２ｄは、このシステムログ機能１２が保有する設定ファイルであり、上記の「重要度」の他に、メッセージの「記録先ファイル名」をも定義する。メッセージ記録先ファイル名には、障害ログファイル１２ｃのファイル名などが用いられる。なお、障害ログファイル１２ｃは保存部３３０とも呼ばれる。また、システムログ設定ファイル１２ｄは、システムログ機能１２の、図示されない記憶部に格納される。
【００３２】
次に、本実施形態の動作について、その概略を図１に基づき説明する。システムログ機能１２は、システムログ１２ａ、各種ログ１２ｂの重要度を判定し、ある基準を越える重要度を有するログを障害ログファイル１２ｃに登録する。この判定はシステムログ設定ファイル１２ｄで定義されている、メッセージ毎の重要度を基準として行われる。図４に示す例は重要度３を閾値として、この値以上（ａｌｅｒｔ、ｅｍｅｒｇ）の障害ログが登録されている。障害ログは他の基準で登録されてもよい。例えば重要度が４以上であることを基準とした場合は、１２月２日９時５１分２７秒に発生したｋｅｒｎｅｌプログラムにおける障害ログのみが記録される。
【００３３】
障害監視機能１３は、障害ログファイル１２ｃを常時監視し、新たな障害ログの記録を検知した場合、その障害ログを、障害通知メッセージとして保守者へ通知するために、障害通知メッセージ用のデータ形式に変換する。しかる後、障害監視機能１３は障害管理機能１４へ障害メッセージを送信する。障害管理機能１４は、障害監視機能１３から受信した障害通知メッセージを元に、障害通知情報管理テーブル１４ａへ、障害発生時刻、障害が発生したハードウェア名、アプリケーションプロセス名等の発生箇所を特定する情報、および、障害内容の詳細を互いに関連付けされた状態で登録する。なお、障害通知情報管理テーブル１４ａに記録された上記内容は、障害通知メッセージ用のデータ形式に変換されて記録されている点を除いて、図４の対応する内容と同じである。障害通知機能１５は、障害通知情報管理テーブル１４ａを一定の時間周期で監視する。障害通知機能１５は、障害通知メッセージが新たに登録されたことを検知した場合、障害通知情報管理テーブル１４ａから障害通知メッセージを取得し、保守用のネットワーク監視装置２へこれを送信する。保守者は、保守用ネットワーク監視装置２に接続しているＧＵＩ画面２１によって、一元的にこの分散コンピュータネットワークの保守管理を行う。なお、障害通知機能１５は通知部３４０とも呼ぶ。
【００３４】
次に、本実施形態における障害監視機能１３の動作について、図５の処理概要フローチャートに基づき詳細説明する。
【００３５】
障害監視機能１３は、常時一定秒の周期、または特定のスケジュールに基づいて、障害ログファイル１２ｃを読み出し、新しいログの書き込みの有無をチェックする(ステップＳ０５２〜Ｓ０５９)。新規のログがある場合（ステップＳ０５４にてＹＥＳ）、保守者へ通知するための障害通知メッセージ形式にデータを変換し（ステップＳ０５５）、障害管理機能１４へ障害通知メッセージを送信する(ステップＳ０５６)。なお、前述の一定秒の周期は、障害発生頻度、障害検知の即時性、システム負荷条件を考慮し、例えば１０〜３０秒程度に設定する。図４は、前述したように、障害ログファイル１２ｃに記載された内容の一例である。障害ログファイル１２ｃに格納されるレコードは、「障害発生日時」、「障害発生装置ホスト名」、「障害発生プログラム」、「障害内容詳細」、「障害の重要度」である。これらは互いに関連付けられた状態で格納されている。図４は、重要度が３、４の障害の記録が格納されている例である。このように、障害ログファイル１２ｃには「障害発生日時」が記録されているので、障害ログファイル１２ｃの読み出し処理においては、この障害発生日時の記録を元に、新規のログのみを読み出すことが能率的である。そこで、この「障害発生日時」情報が、前周期で読み出しを完了しているデータの障害ログファイルにおける読み出し開始の位置情報として用いられる。すなわち、「障害ログファイル１２ｃの読み出しが完了したデータの日時」（以降、「日時ＤＰ」（ＤＰ：Ｄａｔａ  Ｐｏｓｉｔｉｏｎ）と称する）に関連づけられたデータにマーカが付される。障害監視機能１３は、次周期において、この位置情報をもとに、「日時ＤＰ」以降のログを、ファイルの最終行まで読み出す(ステップＳ０５３)。
【００３６】
「日時ＤＰ」の情報は、障害監視機能１３の起動時に初期化される(ステップＳ０５１)。障害監視機能１３は「日時ＤＰ」以降に書き込まれたログから、ファイルの最後の行まで、障害ログファイル１２ｃを読み出す（ステップＳ０５３）。障害監視機能１３は、新規のログがあるか否かを判断する（ステップＳ０５４）。新規のログがある場合（ステップＳ０５４にてＹＥＳ）、障害監視機能１３は、取得した新しいログを保守者に通知するための障害通知メッセージの形式に変換する（ステップＳ０５５）。その後、障害監視機能１３はこの障害通知メッセージを障害管理機能１４に送信する（ステップＳ０５６）。障害監視機能１３は、最後に読み込んだ障害メッセージの「障害発生日時」を、「日時ＤＰ」として設定し、更新を完了する(ステップＳ０５７)。一定秒の処理停止（ステップＳ０５８）後、障害監視機能１３は、Ｓ０５２からの処理を再開する。
【００３７】
新規のログがない場合（ステップＳ０５４にてＮＯ）、一定秒の処理停止（ステップＳ０５８）後、障害監視機能１３は、Ｓ０５２からの処理を再開する。
【００３８】
次に、本実施形態における障害管理機能１４の動作について、図５の一部、及び図６の処理概要フローチャートに基づき詳細に説明する。
【００３９】
障害管理機能１４は、障害監視機能１３より通知された障害通知メッセージ（図５  ステップＳ０５６）を受信する(ステップＳ０６１)。障害管理機能１４は、障害通知情報管理テーブル１４ａにこれを登録する(ステップＳ０６２)。
【００４０】
次に、本実施形態における障害通知機能１５の動作について、図７の処理概要フローチャートに基づき詳細説明する。障害通知情報管理テーブル１４ａの読み出し処理においては、新規の障害通知情報のみを読み出すことが能率的である。そこで、障害通知情報管理テーブル１４ａの読み出しを完了したデータにマーカが付される。このマーカを付すことによって、「障害通知情報管理テーブルの読み出しが完了したデータの位置」（以降「管理テーブルＤＰ（ＤＰ：Ｄａｔａ  Ｐｏｓｉｔｉｏｎ）」と称する）の情報が初期化される（ステップＳ０７１）。障害通知機能１５は、この初期化に続いて、Ｓ０７２〜Ｓ０７ａのループ処理を行う。このループ処理において、始めに障害通知機能１５は、上記マーカの位置から、障害通知情報管理テーブル１４ａを読み出し、データ以降に登録された障害通知メッセージを、最終行まで読み出す(ステップＳ０７３)。この読み出しは一定秒の周期で行われてもいいし、特定のスケジュールで行われてもよい。
【００４１】
障害通知機能１５は、新しい障害通知メッセージの書き込みが無いかをチェックする(ステップＳ０７４)。新規の障害通知メッセージがある場合（ステップＳ０７４にてＹＥＳ）、障害通知機能１５は、Ｓ０７５〜Ｓ０７ｂの処理を繰り返す。すなわち、障害通知機能１５は、保守用のネットワーク監視装置２へ障害通知メッセージを送信する(ステップＳ０７６)。障害通知機能１５は、保守用ネットワーク監視装置２への通知手段として、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ベースのネットワーク監視・管理用プロトコルであるＳＮＭＰ(Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ)のトラップメッセージを使用する。
【００４２】
障害通知機能１５は、「管理テーブルＤＰ」の情報を更新する（ステップＳ０７７）。障害通知機能１５は、ＳＮＭＰトラップの送信件数が規定件数以下の場合（ステップＳ０７８にてＹＥＳ）、Ｓ０７５〜Ｓ０７ｂを繰り返す。障害通知機能１５は、ＳＮＭＰトラップの送信件数が規定件数より大きい場合（ステップＳ０７８にてＮＯ）、ステップＳ０７２にもどって処理を繰り返す。
【００４３】
なお、一定秒周期で障害ログファイルの読み出しを行う場合、その周期（ステップＳ０７９）は、障害通知の即時性を考慮するために、例えば、１秒程度の短周期に設定する。
【００４４】
なお、本実施形態においては、障害通知機能１５が、障害監視機能１３、障害管理機能１４、障害通知情報管理テーブル１４ａの機能を兼ね備える構成をとることができる。また、障害監視機能１３が障害管理機能１４を兼ね備える構成をとることができる。
このような障害監視機能１３と障害管理機能１４を兼ね備えた構成、または障害管理機能１４を単に管理部とも呼ぶ。また、障害通知管理テーブル１４ａは管理テーブルとも呼ぶ。
【００４５】
また、障害ログファイル１２ｃにデータが格納された時点で、障害通知機能２０５が随時障害通知メッセージを行う構成をとるができる。この場合、障害監視機能１３、障害管理機能１４、障害通知管理テーブル１４ａは不要である。
【００４６】
本実施形態においては、ＯＳのシステムログの機能を利用して障害管理を行うので、既存のＧＵＩモニタにより保守管理が可能である。また、障害通知メッセージの送信が重要度の高い障害に限られるので、保守者は効率的に保守対応を行うことができる。
【００４７】
監視エージェント機能１１、システムログ機能１２、障害監視機能１３、障害管理機能１４、障害通知機能１５は論理回路などのハードウェアで実現されてもよいし、図示されていないメモリに格納されているプログラムを実行することで実現されてもよい。
【００４８】
本実施形態においてはＯＳとしてＵＮＩＸを用いているが、他のＯＳが用いられてもよい。例えば、ＬＩＮＵＸ（登録商標）が用いられることも可能である。
（第２の実施形態）
次に上述した第１の実施形態を基本とする第２の実施形態について説明する。以下の説明においては、第１の実施形態と同様な構成については、第１の実施形態に係わる図１の部位に付された参照番号と同一の参照番号を付すことにより、重複する説明は省略する。
【００４９】
図８は、本発明の第２の実施形態の構成を示す概略ブロック図である。
【００５０】
本実施形態では、図１の構成に加え、監視対象ＵＮＩＸ装置２００の上で動作するアプリケーションプログラム２０６とアプリケーションプログラム２０７が設けられている。
【００５１】
監視対象ＵＮＩＸ装置２００は、監視対象ＵＮＩＸ装置１と同様、分散コンピュータネットワークシステムに接続されている。この分散コンピュータネットワークシステムには、他に監視対象装置Ａ２２０、監視対象装置Ｂ２３０、監視対象装置Ｃ２４０、監視対象装置Ｄ２５０、監視対象装置Ｅ２６０、監視対象装置Ｆ２７０が広域ＬＡＮ９を介して通信可能に接続されている。
【００５２】
監視対象ＵＮＩＸ装置２００におけるシステムログ２０２ａ、各種ログ２０２ｂ、障害ログファイル２０２ｃはそれぞれ、第１の実施形態のシステムログ１２ａ、各種ログ１２ｂ、障害ログファイル１２ｃと同じ機能を有している。
【００５３】
アプリケーションプログラム２０６とアプリケーションプログラム２０７は、それぞれアプリケーションの実行中に何らかの処理エラーを検出した場合、その障害情報を保守者へ通知するための障害情報メッセージ形式のデータに変換する。また、アプリケーションプログラム２０６とアプリケーションプログラム２０７は、障害管理機能２０４へ障害通知メッセージを送信する。
【００５４】
障害管理機能２０４は、アプリケーション２０６または２０７より通知された障害通知メッセージを受信し、障害監視機能２０３からの障害情報メッセージ受信時と同様に、障害通知情報管理テーブル２０４ａへ障害通知情報を登録する。アプリケーション２０６およびアプリケーション２０７は実行監視部とも呼ぶ。
【００５５】
障害通知情報管理テーブル２０４ａには、障害管理機能２０４、アプリケーションプログラム２０６、アプリケーションプログラム２０７から通知された障害通知メッセージが登録される。障害通知装置３０２が備える障害通知機能２０５は、これらの障害通知メッセージを保守用ネットワーク監視装置２１０に送信する。障害通知機能２０５は、第１の実施形態の障害通知機能１５と同様に、障害ログファイル２０２Ｃから障害監視機能１３が読み込み、障害管理機能２０４に送信通知された障害通知メッセージも、保守用ネットワーク監視装置２１０に送信する。保守者は保守用ネットワーク監視装置２１０に接続しているＧＵＩ画面２１１によって、一元的にこの分散コンピュータネットワークの保守管理を行う。
【００５６】
本発明の第２の実施形態によれば、監視対象ＵＮＩＸ装置１で発生したハードウェア障害やＯＳのエラーのみならず、各種のアプリケーションプログラムで検出されたエラー情報も、障害通知情報管理テーブル２０４ａで一元管理できる。このため、新規にアプリケーションプログラムを追加する場合、障害管理機能２０４とアプリケーションプログラムの障害通知インタフェースを合わせれば、障害情報の管理から保守用ネットワーク監視装置２１０への障害通知が可能となる。したがって、アプリケーションプログラム固有の障害管理機能２０４、障害通知機能２０５の作り込みは不要となる。
（第３の実施形態）
次に上述した第１の実施形態を基本とする第２の実施形態について説明する。以下の説明においては、第１の実施形態と同様な構成については、第１の実施形態に係わる図１の部位に付された参照番号と同一の参照番号を付すことにより、重複する説明は省略する。
【００５７】
第１の実施形態では、重要度に応じて障害通知を障害ログファイル１２ｃに記録した。第３の実施形態では、アプリケーション毎に重要度を設定し、この重要度に応じた障害通知を記録する。障害監視機能１３は、使用中のアプリケーションに多大な影響をもたらす障害メッセージのみを障害管理機能１４へ通知する構成とする。障害通知機能１５は、障害監視機能１３から受信した障害情報メッセージを元に、障害通知情報管理テーブル１４ａへ、障害発生時刻、障害が発生したハードウェア名、アプリケーションプロセス名等の発生箇所を特定する情報、および、障害内容の詳細を登録する。障害通知機能１５は、第1の実施形態と同様に、障害通知情報管理テーブル１４ａを一定周期で監視する。障害通知機能１５は障害通知情報が新たに登録されたことを検知した場合、障害通知情報管理テーブル１４ａから障害情報を取得し、保守用のネットワーク管理装置２へ障害通知メッセージを送信する。
【００５８】
この実施形態では、使用中のアプリケーションに直接影響のない障害メッセージは通知されないので、ユーザは徒に保守作業による中断を受けることなく、第１の実施形態に比べてより効率的に保守対応を実施することができる。
【００５９】
一例として、システムＸにおいて、システムＸの動作に直接影響を及ぼすアプリケーションＡと、システムＸの動作に影響を及ぼさないアプリケーションＢが動作している環境を取り上げる。システムＸにおいては、アプリケーションＡのプロセスが停止した場合、重要な障害となるが、アプリケーションＢのプロセスが停止した場合は、深刻な問題とはならない。「プロセス停止」という障害の重要度の定義を、アプリケーションＡとＢで個別に定義することで、保守者に有用な障害情報のみ通知することができる。すなわち、アプリケーションＡにおいては、プロセスが停止する障害を、アプリケーションＢよりも高い重要度に設定することが、この実施形態では可能である。
【００６０】
本実施形態においては、第２の実施形態と同様に、アプリケーションプログラム２０６、２０７のような実行監視部が実行中のアプリケーションプログラムを特定する、という構成をとることができる。
【００６１】
本実施形態においては、実行中のアプリケーションプログラムを特定するアプリケーションプログラム特定部が、実行中のアプリケーションプログラムを判定する、という構成が取られてもよい。
（第４の実施形態）
第４の実施形態について、図９を参照して説明する。本発明の第４の実施形態は、オペレーションシステムからログを取得する監視部３１０と、オペレーションシステムから取得したログの重要度を判別する分析部３２０と、前記ログのうち、前記重要度が閾値以上のログを障害通知として保守装置に通知する通知部３４０と、を有する障害通知装置３００である。
【００６２】
本実施形態の効果は、オペレーションシステムのログを利用することにより、既存のコンピュータネットワークにおいても、効率的な保守対応が可能なことである。
【００６３】
上述した第１乃至第４の実施形態を例に説明した本発明は、当該実施形態の説明において参照したフローチャート（図５、図６、図７）の機能、或いは図１、図８、図９に示したブロック図において当該装置内に示した各部を実現可能なプログラムを図１０に示す情報処理装置１０００に対して供給した後、そのプログラムをＣＰＵ１１００（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）に対して実行することによって達成される。また、情報処理装置１０００内に供給されたプログラムは、読み書き可能な一時記憶メモリ１２００またはハードディスクドライブ等の不揮発性の記憶装置１３００に格納すればよい。
【図面の簡単な説明】
【００６４】
【図１】本発明の第１の実施形態に係わる障害通知装置を備える分散コンピュータネットワークのブロック図である。
【図２】サーバ管理ソフトウェアを使用したネットワーク監視システム全体構成の一例を示すブロック図である。
【図３ａ】監視対象装置を追加する前の既存ネットワーク監視システム全体構成の一例を示すブロック図である。
【図３ｂ】監視対象装置を追加した後の既存ネットワーク監視システム全体構成の一例を示すブロック図である。
【図４】本発明の第１の実施形態による障害ログファイルの内容の一例を示す図である。
【図５】本発明の第１の実施形態による障害監視機能の処理を表すフローチャートである。
【図６】本発明の第１の実施形態による障害管理機能の処理を表すフローチャートである。
【図７】本発明の第１の実施形態による障害通知機能の処理を表すフローチャートである。
【図８】本発明の第２の実施形態の構成を示すブロック図である。
【図９】本発明の第４の実施形態の構成を示すブロック図である。
【図１０】本発明をコンピュータプログラムで実行する情報処理装置を示すブロック図である。
【符号の説明】
【００６５】
１    監視対象ＵＮＩＸ装置
２    保守用メットワーク監視装置
３    監視対象装置Ａ
４    監視対象装置Ｂ
５    監視対象装置Ｃ
６    監視対象装置Ｄ
７    監視対象装置Ｅ
８    監視対象装置Ｆ
９    広域ＬＡＮ
１１    監視エージェント機能
１２    システムログ機能
１２ａ    システムログ
１２ｂ    各種ログ
１２ｃ    障害ログ
１２ｄ    システムログ設定ファイル
１３    障害監視機能
１４    障害管理機能
１４ａ    障害通知情報管理テーブル
１５    障害通知機能
２１    ＧＵＩ画面
１００    監視対象装置
１０１    アプリケーションプログラム
１０２    監視エージェント機能
１１０    監視対象装置
１１１    アプリケーションプログラム
１１２    監視エージェント機能
１２０    監視対象装置
１２１    アプリケーションプログラム
１２２    監視エージェント機能
１３０    保守用ネットワーク監視装置
１３１    ネットワーク監視マネージャ機能
１３１ａ    ＧＵＩ画面
１４０    監視対象装置
１５０    監視対象装置
１６０    監視対象装置
１４１    アプリケーションプログラム
１５１    アプリケーションプログラム
１６１    アプリケーションプログラム
１６２    監視エージェント機能
１７０    保守用ネットワーク監視装置
１７１    統合監視機能
１７１ａ    保守作業用ＧＵＩ画面
１７２    ネットワーク監視マネージャ機能
１７２ａ    ＧＵＩ画面
２００    監視対象ＵＮＵＸ装置
２０２ａ    システムログ
２０２ｂ    各種ログ
２０２ｃ    障害ログ
２０３    障害監視機能
２０４    障害管理機能
２０４ａ    障害通知情報管理テーブル
２０５    障害通知機能
２０６    アプリケーションプログラム
２０７    アプリケーションプログラム
２１０    保守用ネットワーク監視装置
２１１    ＧＵＩ画面    
２２０    監視対象装置Ａ
２３０    監視対象装置Ｂ
２４０    監視対象装置Ｃ
２５０    監視対象装置Ｄ
２６０    監視対象装置Ｅ
２７０    監視対象装置Ｆ
３００    障害通知装置
３０１    障害通知装置
３０２    障害通知装置
３１０    監視部
３２０    分析部
３４０    通知部
１０００    情報処理装置
１１００    ＣＰＵ
１２００    一時記憶メモリ
１３００    記憶装置
【図１】
2014228932.tif 000003
【図２】
2014228932.tif 000004
【図３ａ】
2014228932.tif 000005
【図３ｂ】
2014228932.tif 000006
【図４】
2014228932.tif 000007
【図５】
2014228932.tif 000008
【図６】
2014228932.tif 000009
【図７】
2014228932.tif 000010
【図８】
2014228932.tif 000011
【図９】
2014228932.tif 000012
【図１０】
2014228932.tif 000013