(57)【要約】【課題】複数の要因の組合せからなるアプリケーションソフトウェアのエラーに対する有効かつ適正な対処方法を一元管理して、複数の被監視装置で発生する様々、かつ、複雑なアプリケーションソフトウェアのエラーにも柔軟に対応したエラー対処方法をシステム管理者に明示することである。【解決手段】単一または複数のエラーログ対処方法が関係付けられたデータベース２９−１〜２９−４を構築し、ネットワークを介して被監視装置からエラーログ監視部２４により取得されるエラーログファイルに基づき、前記データベース２９−１〜２９−４を参照して有効な対処方法をＤＢ検索部２５が検索し、該検索された結果を所定の通知先に通知する構成を特徴とする。【選択図】      図６
2004213302.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して通信可能な複数のデータ処理装置のエラーログを監視するエラー監視装置であって、
各データ処理装置に蓄積されているエラーログファイルを定期的に取得する取得手段と、
単一または複数のエラーログ対処方法が関係付けられたデータベースと、
前記取得手段により取得されるエラーログファイルに基づき、前記データベースを参照して有効な対処方法を検索する検索手段と、
前記検索手段により検索された結果を所定の通知先に通知する通知手段と、
を有することを特徴とするエラー監視装置。
【請求項２】
前記検索手段により有効な対処方法を検索できない場合に、前記ネットワークを介して該取得されたログファイルに基づき所定のＷｅｂサーバを検索して有効な対処ファイルを取得するＷｅｂサーバ参照手段を有することを特徴とする請求項１記載のエラー監視装置。
【請求項３】
前記通知手段は、前記Ｗｅｂサーバ参照手段により取得される有効な対処ファイルに関する情報を所定の通知先に通知することを特徴とする請求項１または２記載のエラー監視装置。
【請求項４】
前記データベースは、単一または複数のエラーログ対処方法を新規登録あるいは内容更新を可能とすることを特徴とする請求項１記載のエラー監視装置。
【請求項５】
ネットワークを介して通信可能な複数のデータ処理装置のエラーログを監視するエラー監視装置におけるエラー監視方法であって、
各データ処理装置に蓄積されているエラーログファイルを定期的に取得する取得ステップと、
前記取得ステップにより取得されるエラーログファイルに対して、単一または複数のエラーログ対処方法が関係付けられたデータベースを参照して有効な対処方法を検索する検索ステップと、
前記検索ステップにより検索された結果を所定の通知先に通知する通知ステップと、
を有することを特徴とするエラー監視方法。
【請求項６】
前記検索ステップにより有効な対処方法を検索できない場合に、前記ネットワークを介して該取得されたログファイルに基づき所定のＷｅｂサーバを検索して有効な対処ファイルを取得するＷｅｂサーバ参照ステップを有することを特徴とする請求項５記載のエラー監視方法。
【請求項７】
前記通知ステップは、前記Ｗｅｂサーバ参照ステップにより取得される有効な対処ファイルに関する情報を所定の通知先に通知することを特徴とする請求項５または６記載のエラー監視方法。
【請求項８】
前記データベースは、単一または複数のエラーログ対処方法を新規登録あるいは内容更新を可能とすることを特徴とする請求項５記載のエラー監視方法。
【請求項９】
請求項５〜８のいずれかに記載のエラー監視方法を実現するプログラムを記憶したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【請求項１０】
請求項５〜８のいずれかに記載のエラー監視方法を実現することを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して通信可能な複数のデータ処理装置のエラーログを監視するエラー監視装置およびエラー監視方法およびコンピュータが読取り可能な記憶媒体およびプログラムに関するものである。
【０００２】
【従来の技術】
近年、価格の低価格化等によりパーソナルコンピュータが急速に普及し、それに伴い、多数のアプリケーションソフトウェアが開発、販売されている。
【０００３】
そして、多くのアプリケーションソフトウェアは、単体で動作している訳ではなく、オペレーティングシステムと協働しており、また、別のソフトウェア・ハードウェアと連携して動作している。
【０００４】
よって、あるアプリケーションソフトを使用中にエラーが発生した場合でも、フロントで使用しているアプリケーションそのものではなく、その他の関連するソフトウェア、ネットワークやハードなど、さまざまな要因が考えられ、原因追求には、多くの時間を要する。
【０００５】
このようなエラーが発生した場合の対処方法として、ユーザ自らが自発的に、インターネット等のサポートサイトに接続し、解決方法を得ることが行われている。
【０００６】
一方、サポートサイトでは、問い合わせがあった内容に対して、回答を返す仕組みになっているが、問合せをするにも、各製品の知識、導入されているシステム環境を熟知していなければならず、また実際に対応する際には、多大な手間と時間を要するケースも珍しくない。
【０００７】
また、特開平８−３１４７６３号公報では、ログファイルの内容を解析し、ログ情報の参照者に応じて必要な情報を必要なときに理解しやすい内容で通知するログ情報解析装置が提案されている。
【０００８】
【特許文献１】
特開平８−３１４７６３号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、上記方法では、複数のソフトウェアのエラー発生時のことは考慮されておらす、上述のように、複数のソフトウェアやハードウェアが連動して動作しているような環境では、エラーの原因を特定することが難しい。
【００１０】
また、起こりうるエラー対処方法をあらかじめ登録しておく必要があり、対処方法が得られない場合は、更なる解決手段が存在しなくなり、エラー解消操作に移行できなくなるという問題点があった。
【００１１】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、ネットワークを介して被監視装置から取得されるエラーログファイルに対して、単一または複数のエラーログ対処方法が関係付けられたデータベースを構築し、取得されるエラーログファイルに基づき、前記データベースを参照して有効な対処方法を検索し、該検索された結果を所定の通知先に通知することにより、複数の要因の組合せからなるアプリケーションソフトウェアのエラーに対する有効かつ適正な対処方法を一元管理して、複数の被監視装置で発生する様々、かつ、複雑なアプリケーションソフトウェアのエラーにも柔軟に対応したエラー対処方法をシステム管理者に明示することができる利便性に優れたエラー監視装置およびエラー監視方法およびコンピュータが読取り可能な記憶媒体およびプログラムを提供することである。
【００１２】
【課題を解決するための手段】
本発明に係る第１の発明は、ネットワークを介して通信可能な複数のデータ処理装置のエラーログを監視するエラー監視装置（図１に示すエラー監視装置５）であって、各データ処理装置に蓄積されているエラーログファイルを定期的に取得する取得手段（図６に示すエラーログ監視部２４）と、前記取得手段により取得されるエラーログファイルに対して、単一または複数のエラーログ対処方法が関係付けられたデータベース（図６に示すキーワードＤＢ２９−１（図２），対処方法ＤＢ２９−２（図３），組み合わせログＤＢ２９−３（図４），ＷｅｂサーバＤＢ２９−４（図５））と、前記取得手段により取得されるエラーログファイルに基づき、前記データベースを参照して有効な対処方法を検索する検索手段（図６に示すＤＢ検索部２５）と、前記検索手段により検索された結果を所定の通知先に通知する通知手段（図６に示す制御部２２が通信部２１を介して図１５に示す処理結果通知画面を通知処理する）とを有することを特徴とする。
【００１３】
本発明に係る第２の発明は、前記検索手段により有効な対処方法を検索できない場合に、前記ネットワークを介して該取得されたログファイルに基づき所定のＷｅｂサーバを検索して有効な対処ファイルを取得するＷｅｂサーバ参照手段（図６に示す制御部２２が通信部２１を介して参照処理する）を有することを特徴とする。
【００１４】
本発明に係る第３の発明は、前記通知手段は、前記Ｗｅｂサーバ参照手段により取得される有効な対処ファイルに関する情報を所定の通知先に通知することを特徴とする。
【００１５】
本発明に係る第４の発明は、データベースのいずれかのデータベースは、単一または複数のエラーログ対処方法を新規登録あるいは内容更新を可能とする（図１１に示す登録画面，図１２に示すログ入力画面）ことを特徴とする。
【００１６】
本発明に係る第５の発明は、ネットワークを介して通信可能な複数のデータ処理装置のエラーログを監視するエラー監視装置におけるエラー監視方法であって、各データ処理装置に蓄積されているエラーログファイルを定期的に取得する取得ステップ（図７のステップＳ３０１，Ｓ３０２）と、前記取得ステップにより取得されるエラーログファイルに対して、単一または複数のエラーログ対処方法が関係付けられたデータベースを参照して有効な対処方法を検索する検索ステップ（図７のステップＳ３０３〜Ｓ３１２）と、前記検索ステップにより検索された結果を所定の通知先に通知する通知ステップ（図７のステップＳ３１３，Ｓ３１５，３１６）とを有することを特徴とする。
【００１７】
本発明に係る第６の発明は、前記検索ステップにより有効な対処方法を検索できない場合に、前記ネットワークを介して該取得されたログファイルに基づき所定のＷｅｂサーバを検索して有効な対処ファイルを取得するＷｅｂサーバ参照ステップ（図９のステップＳ４０１〜Ｓ４１０）を有することを特徴とする。
【００１８】
本発明に係る第７の発明は、前記通知ステップは、前記Ｗｅｂサーバ参照ステップにより取得される有効な対処ファイルに関する情報を所定の通知先に通知することを特徴とする。
【００１９】
本発明に係る第８の発明は、前記データベースのいずれかのデータベースは、複数のエラーログ対処方法を新規登録あるいは内容更新を可能とする（図１０のステップＳ５０１〜Ｓ５０６）ことを特徴とする。
【００２０】
本発明に係る第９の発明は、請求項５〜８のいずれかに記載のエラー監視方法を実行するためのプログラムをコンピュータが読み取り可能な記憶媒体に記憶したことを特徴とする。
【００２１】
本発明に係る第１０の発明は、請求項５〜８のいずれかに記載のエラー監視方法を実行するためのプログラムであることを特徴とする。
【００２２】
【発明の実施の形態】
図１は、本発明の第１実施形態を示すエラー監視装置を適用可能なデータ処理システムの一例を示すシステム構成図である。
【００２３】
図１において、１〜３はメーカＷｅｂサーバで、種々のアプリケーションを開発販売するメーカが個別に管理しており、インターネット４を介してエラー監視装置５と通信可能に構成されている。
【００２４】
エラー監視装置５は、ローカルのネットワーク６を介して、被監視装置７，８と通信可能に構成されている。
【００２５】
１１はキーワードデータベースで、図２に示すデータ構造でキーワードＩＤ毎でログファイルとキーワードを管理している。１２は対処方法データベースで、図３に示すデータ構造で対処方法ＩＤ毎に対処方法に関する情報を管理している。
【００２６】
１３は組合せログデータベースで、図４に示すデータ構造で組合せＩＤ毎に複数の対処方法の組合せを管理している。１４はＷｅｂサーバデータベースで、図５に示すデータ構造でＵＲＬ＿ＩＤ毎に対処方法を取得するためのＵＲＬファイルに関する情報を管理している。なお、各データベース１１〜１４は、例えばハードディスクで構成される記憶部とデータ要求に応答するコンピュータ等で構成され、エラー監視装置５が各データベース１１〜１４を参照して、エラー対処方法をネットワーク上の図示しない管理者ＰＣに通知する。
【００２７】
７，８は被監視装置で、所定のＯＳでハードディスク等にインストールされている各種のアプリケーションを起動して、所望のデータ処理を行う。なお、被監視装置７は、ログファイル９を図示しないハードディスク等で記憶管理している。同様に、被監視装置８は、ログファイル１０を図示しないハードディスク等で記憶管理している。
【００２８】
図６は、図１に示したエラー監視装置５の構成を説明するブロック図である。なお、図１に示したシステムでは、データベース１１〜１４を外部装置とし構成した場合を示すが、本実施形態では、Ｉ／Ｆを介して接続される外部記憶装置（記憶部）２９内に構築する場合を示す。
【００２９】
図６において、２１は通信部で、ネットワーク６を介して被監視装置７，８との通信と、インターネット４を介してメーカＷｅｂサーバ１〜３または図示しない商用サーバとの間で所定のプロトコルで通信処理する。２２は制御部で、ＣＰＵ，ＲＡＭ，ＲＯＭを備え、記憶部２９に記憶されるＯＳをＲＡＭ上にロードし、さらに、記憶部２９から各種のアプリケーションをＲＡＭ上にロードして各種のデータ処理および本発明に係るエラー監視処理を行う。
【００３０】
なお、記憶部２９において、キーワードデータベース２９−１は、図１に示したデータベース１１と同等で、図２に示すデータ構造でキーワードＩＤ毎でログファイルとキーワードを管理している。
【００３１】
２９−２は対処方法データベースで、図３に示すデータ構造で対処方法ＩＤ毎に対処方法に関する情報を管理している。
【００３２】
２９−３は組合せログデータベースで、図４に示すデータ構造で組合せＩＤ毎に複数の対処方法の組合せを管理している。２９−４はＷｅｂサーバデータベースで、図５に示すデータ構造でＵＲＬ＿ＩＤ毎に対処方法を取得するためのＵＲＬファイルに関する情報を管理している。
【００３３】
なお、各データベース２９−１〜２９−４は、例えばハードディスクで構成され、制御部２２が被監視装置７または被監視装置８からエラーログファイルを取得して、各データベース２９−１〜２９−４を参照して、エラー対処方法をネットワーク上の図示しない管理者ＰＣに通知する。
【００３４】
ここで、各データベースは、それぞれ別々のデータベースとして説明しているが、各ＩＤ毎の項目について管理することが可能であるような、１つのデータベースとして構成してもよい。
【００３５】
２９−５は取得情報記憶領域で、被監視装置７または被監視装置８からエラーログファイルが一時的に記憶される。
【００３６】
２８は記憶制御部で、記憶部２９に対するデータベース参照要求や、データベースの更新等を制御する。３０は入力部で、キーボードやポインティングデバイス等で構成される。
【００３７】
２４はエラーログ監視部で、あらかじめ設定されたタイミングで、あるいは指定されたタイミングで、ネットワーク６上の被監視装置７または被監視装置８より、エラーログファイル９，１０の取得処理を行う。２５はＤＢ検索部で、ネットワーク６上の被監視装置７または被監視装置８より、エラーログファイル９，１０に基づいて、各データベース２９−１〜２９−４をＤＢ検索部２５が検索して、通信部２１を介して検索した結果をネットワーク６上の管理者の管理者ＰＣに通知処理する。２６は表示制御部で、表示部２７に対するデータ表示を制御する。
【００３８】
図７は、本発明に係るエラー監視装置における第１のデータ処理手順の一例を示すフローチャートであり、図６に示した制御部２２が記憶部２９等からＲＡＭ上に監視処理プログラムをロードして実行される手順に対応する。なお、Ｓ３０１〜Ｓ３１６は各ステップを示す。
【００３９】
まず、ステップＳ３０１において、あらかじめ設定されたスケジュールに従って、例えば被監視装置７内の記憶装置内で管理されている履歴領域上に、エラーログファイルがあるかどうかを監視して、ステップＳ３０２で、エラーログがあるかどうか図２に示したキーワードＤＢのログファイル名に書かれたログファイルについて判断する。例えばエラーが発生した時に出来るタイプのログファイルであれば、エラーログファイルがあるかどうかでエラーログの有無を判断し、またエラーが発生した時に、図８に示したような既存のファイルにエラー内容が追記されるタイプのエラーログファイルであれば、エラーログファイルがあり且つ新しく書かれた部分があるかどうかで、エラーログの有無を判断する。エラーログが無かったと判断した場合には、スッテップＳ３０１に戻り、再度スケジュール間隔に従って、エラーログファイルを監視する。
【００４０】
一方、ステップＳ３０２で、エラーログがあると判断した場合には、ステップＳ３０３に進み、キーワードＤＢ２９−１の中に設定されたキーワードが含まれるかどうかをＤＢ検索部２５が検索して、ステップＳ３０４で、キーワードがヒットしたかどうかを判断する。
【００４１】
なお、本実施形態では、ほとんどのログファイルはテキストで書かれているので、容易にテキストベースでの検索を行うことができる。また、テキスト形式でない場合は、別途検索可能なプログラム等を使用して対応することになる。また、本実施形態では、図２に示すキーワード欄中の「？」は任意の一文字とする。
【００４２】
一方、ステップＳ３０４において、キーワードがヒットしたと判断した場合には、ステップＳ３０５に進み、図３に示したデータ構造の対処方法ＤＢ２９−２をＤＢ検索部２５が検索し、参照しているログファイルに対応したエラーメッセージが存在しているかどうかを判断する。
【００４３】
例えば、ステップＳ３０４において、ＳｏｆｔＡ￥ａｐｌ．ｌｏｇ内に「ｅｒｒ．２００」というエラーメッセージがある場合、キーワード「Ｅｒｒ．？？？」にヒットするので、「キーワードヒット」となり対処方法ＤＢを検索する。
【００４４】
この場合、対処方法ＤＢ２９−２のＳｏｆｔＡ￥ａｐｌ．ｌｏｇには「ｅｒｒ．２０４」しか登録されていないので、ステップＳ３０６ではエラーメッセージはヒットしないということになる。
【００４５】
一方、ステップＳ３０４で、キーワードがヒットしなかったと判断した場合は、未知の問題となるため、ステップＳ３１５へ進み、その旨をネットワーク６を介して図示しない管理者の管理者ＰＣに通知して、処理をステップＳ３０８へ移行する。
【００４６】
そして、ステップＳ３０６で、エラーメッセージがヒットしなかったと判断した場合は、対処方法が未知のエラーメッセージということになるので、ステップＳ３１４で、Ｗｅｂサーバ参照処理ルーチンを実行して、ステップＳ３０８へ進む。
【００４７】
一方、ステップＳ３０６で、エラーメッセージがヒットしたと判断した場合には、ステップＳ３０７で、図３に示すデータ構造の対処方法ＤＢ２９−２より、該当する対処方法ＩＤを取得し、取得情報記憶領域２９−５に保管する。
【００４８】
次いで、ステップＳ３０８で、ステップＳ３０２で得られたエラーログファイル内の全てのキーワードについて処理したかどうかを判断して、検索していないキーワードが残っていると判断した場合は、ステップＳ３０３に戻り、再度同じ処理を行う。
【００４９】
一方、ステップＳ３０８で、全てのキーワードについて処理したと判断した場合は、ステップＳ３０９で、ステップＳ３０１で得られた全てのエラーログファイルについて処理を行ったかどうかを判断し、検索していないエラーログファイルが残っていると判断した場合は、ステップＳ３０２に戻り、再度同じ処理を行う。
【００５０】
これにより、すべてのエラーログファイル、キーワードについて処理が行われたことになる。
【００５１】
一方、ステップＳ３０９で、全エラーログファイル検索が終了したと判断した場合には、ステップＳ３１０において、ステップＳ３０７で取得した対処方法ＩＤの数が複数（２個以上）であるかどうかを判断して、２個以上であると判断した場合には、ステップＳ３１１で、図５に示すデータ構造の組合せログＤＢ２９−３をＤＢ検索部２５が検索する。
【００５２】
そして、ステップＳ３１２で、取得している複数の対処方法ＩＤの数で示される対処方法ＩＤで、同じＩＤの組み合わせがあるかどうかを判断する。
【００５３】
例えば、ステップＳ３０７で取得した対処方法ＩＤが、図３に示した「ｔｈ００１」と「ｔｈ００２」であったと判断した場合は、図４に示したデータ構造の組合せログＤＢ２９−３の「ｋｕ００１」と「ｋｕ００４」がヒットするので、ステップＳ３１３で、上記４つのＩＤ番号（「ｔｈ００１」「ｔｈ００２」「ｋｕ００１」「ｋｕ００４」）を、ネットワーク６を介して図示しない管理者の管理者ＰＣに通知して、本処理を終了する。
【００５４】
ここでＩＤ番号とともに必要とされる他の項目（例えば、対処方法等）を通知するような構成にしてもよい。
【００５５】
また、複数取得した対処方法ＩＤが「ｔｈ００１」と「ｔｈ００４」であった場合は、同じＩＤの組合せがないので、ステップＳ３１２の判定がＮＯとなり、ステップＳ３１６へ進み、該当するＩＤ番号（「ｔｈ００１」「ｔｈ００４」）をネットワーク６を介して図示しない管理者の管理者ＰＣに通知して、本処理を終了する。
【００５６】
ここでもＩＤ番号とともに必要とされる他の項目（例えば、対処方法等）を通知するような構成にしてもよい。
【００５７】
また、ステップＳ３１０において、対処方法ＩＤの数が２個未満であると判断されたときもステップＳ３１６に進み、同様の処理を行い、処理を終了する。
【００５８】
図９は、本発明に係るエラー監視装置における第２のデータ処理手順の一例を示すフローチャートであり、図６に示した制御部２２が記憶部２９等からＲＡＭ上に監視処理プログラムをロードして実行される図８に示したステップＳ３１４のＷｅｂサーバ参照処理ルーチンの詳細手順に対応する。なお、Ｓ４０１〜Ｓ４１２は各ステップを示す。
【００５９】
まず、ステップＳ４０１において、図５に示したデータ構造のＷｅｂサーバＤＢ２９−４を参照する。
【００６０】
そして、ステップＳ４０２で、ＷｅｂサーバＤＢ２９−４上のログファイルの項目を参照し、該当する参照ＵＲＬが有るか否かを判断して、該当する参照ＵＲＬが存在しないと判断した場合は、エラーとしてステップＳ４１２に進み、そのエラーである旨をネットワーク６を介して図示しない管理者の管理者ＰＣに結果として通知して（Ｓ４１１）、本処理を終了する。
【００６１】
一方、ステップＳ４０２で、該当する参照ＵＲＬが存在すると判断した場合は、ステップＳ４０３において、通信部２１がインターネット４を介して設定されているＵＲＬのＷｅｂサーバに接続処理を行い、ステップＳ４０４において、接続確認（接続ＯＫ）がとれたかどうかを判断して、接続がＮＧであったような場合は、エラーとしてステップＳ４１２に進み、その結果をネットワーク６を介して図示しない管理者の管理者ＰＣに結果として通知して、本処理を終了する。
【００６２】
一方、ステップＳ４０４で、接続確認（接続ＯＫ）がとれたと判断した場合には、ステップＳ４０５において、接続したサイト上でキーワードに基づいて対処方法を検索（図７に示したステップＳ３０５と同様のキーワードについて検索処理）する。
【００６３】
そして、ステップＳ４０６において、キーワードに対応した対処方法が有るかどうかを判断し、キーワードに対応した対処方法があると判断した場合は、ステップＳ４０７において、エラー監視装置の記憶部２９の取得情報記憶領域２９−５に保存し、ステップＳ４０８に進む。
【００６４】
なお、本実施形態において、ステップＳ４０６の判断方法としては、ＷｅｂサーバＤＢ２９−４内の対処方法キーワードが含まれている部分があるかどうかを検索する方法が挙げられる。
【００６５】
つまり、キーワードが含まれるｈｔｍｌファイルをｆｔｐ等によりダウンロードする方法でもよいし、また、後から管理者が対応するときのために、該当するサイトからリンクされている、すべての情報を収集し、その情報をＷｅｂサーバＤＢ２９−４の参照ＵＲＬに登録するようにしてもよい。また、記憶容量が不足している場合は、ＵＲＬそのものを保存するように構成してもよい。
【００６６】
一方、ステップＳ４０６において、対処方法が存在しないと判断された場合には、ステップＳ４０８に進む。
【００６７】
そして、ステップＳ４０８において、ソフトウェアの修正プログラム等のパッチ情報があるかどうかを検索し、ステップＳ４０９において、キーワードに対応したパッチファイルが有るかどうかを判断し、パッチファイルがあると判断した場合は、ステップＳ４１０において、エラー監視装置の記憶部２９の取得情報記憶領域２９−５に保存し、ステップＳ４１１に進む。
【００６８】
本実施形態では、ステップＳ４０９の判断方法としては、多くのメーカはパッチファイルを一定の規則に従って命名していることが多いので、そのファイル名を設定した、ＷｅｂサーバＤＢ内のパッチファイルキーワードが含まれている部分があるかどうかを検索する方法が挙げられる。該当するパッチファイルをｆｔｐ等によりダウンロードする方法でもよいし、ＵＲＬのみ保存するように構成してもよい。
【００６９】
一方、ステップＳ４０９において、パッチ情報が存在しないと判断された場合には、ステップＳ４１１に進む。
【００７０】
そして、ステップＳ４１１では、ステップＳ４０１〜ステップＳ４１０，ステップＳ４１２までに行った処理結果をネットワーク６を介して図示しない管理者の管理者ＰＣに結果として通知して、本処理を終了する。
【００７１】
図１０は、本発明に係るエラー監視装置における第３のデータ処理手順の一例を示すフローチャートであり、図６に示した記憶制御部２８によるデータベース登録受付処理手順に対応する。なお、Ｓ５０１〜Ｓ５０６は各ステップを示す。
【００７２】
図１１，図１２は、図６に示した表示部２７に表示されるデータベース更新メニュー画面の一例を示す図であり、図１１がメイン更新メニュー画面に対応し、図１２が、図１１に示したメイン更新メニュー画面で選択された組合せログデータの更新メニュー画面に対応する。
【００７３】
図１１において、ＳＢ１〜ＳＢ４は選択バーで、選択バーＳＢ１を選択すると、キーワードデータベース２９−１に対する更新メニュー画面（不図示）が表示部２７に表示される。また、選択バーＳＢ２を選択すると、対処方法データベース２９−２に対する更新メニュー画面（不図示）が表示部２７に表示される。また、選択バーＳＢ３を選択すると、組合せログデータベース２９−３に対する更新メニュー画面（図１２に示す）が表示部２７に表示される。また、選択バーＳＢ４を選択すると、Ｗｅｂサーバデータベース２９−４に対する更新メニュー画面（不図示）が表示部２７に表示される。
【００７４】
図１１において、Ｂ１は決定ボタンを示し、Ｂ２は終了ボタンを示す。また、図１２において、Ｂ１１は決定ボタンを示し、Ｂ１２はキャンセルボタンを示し、Ｂ１３は終了ボタンを示す。
【００７５】
まず、記憶制御部２８は、ステップＳ５０１で、図示しないデータベース更新メニューを表示部２７に表示して、図６に示したデータベース２９−１〜２９−４のいずれのデータベースを更新するのかの選択指示を判断して（Ｓ５０２）、ＮＯ、例えば図１１に示したデータベース更新メニューに備える終了ボタンＢ２が押下されたと判断した場合には、本処理を終了する。
【００７６】
一方、ステップＳ５０２で、図１１に示した選択バーＳＢ１〜ＳＢ４のいずれかが選択されたと判断した場合には、ステップＳ５０３で、選択された選択バーに対応する入力メニュー画面、例えば図１２に示す入力メニュー画面を表示部２７に表示する。
【００７７】
そして、図１２に示す例では、端末番号，ステータス，対処方法，対処日，対処結果等の項目を入力部３０より入力した後、ステップＳ５０４で、図１２に示したボタンＢ１１が押下指示されて、入力された内容を決定する指示がなされたかどうかを判断して、ボタンＢ１１が押下指示されたと判断した場合は、ステップＳ５０５で、この場合には、組合せログデータ２９−３に登録して、データベースの内容を更新して、処理を終了する。
【００７８】
一方、ステップＳ５０４で、ボタンＢ１１が押下されず、キャンセルを指示するボタンＢ１２あるいは終了を指示するボタンＢ１３が指示されているかどうかを、ステップＳ５０６で、終了が指示されているかどうかを判断して、ボタンＢ１３が押下指示されたと判断した場合には、本処理を終了する。
【００７９】
一方、ステップＳ５０６で、ボタンＢ１２が押下指示されたと判断した場合には、ステップＳ５０１へ戻り、他のデータベースの更新処理を継続して実行する。
【００８０】
これにより、図７，図８のフローチャートで通知を受けた管理者は、図６に示した各データベース２９−１〜２９−４の内容を更新して、適正なエラーログ処理判定するためのデータベースを最適化することができる。以下、図１３，図１４に対処方法データベース，組み合せログデータベースの更新状態を示す
図１３は、図３に示した対処方法データベースの更新状態を示す図である。
【００８１】
図１４は、図４に示した組み合せログデータベースの更新状態を示す図である。
【００８２】
図１５は、監視サーバ５から管理者への処理結果通知画面の一例を示す模式図である。
【００８３】
なお、本実施形態では、管理者への通知は、ネットワーク６を介して図示しない管理者の管理者ＰＣに図１５に示す処理結果通知画面を通知するように構成してもよいし、予め登録されている管理者の電子メールアドレスに図１５に示したものと同様の内容を電子メールにて送信して通知するように構成してもよいし、予め登録されているサイト（管理者により定期的にチェックされる）に図１５に示した内容を記載することで管理者に通知するように構成してもよい。
【００８４】
以下、図１６に示すメモリマップを参照して本発明に係るエラー監視装置で読み出し可能なデータ処理プログラムの構成について説明する。
【００８５】
図１６は、本発明に係るエラー監視装置で読み出し可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【００８６】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【００８７】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【００８８】
本実施形態における図７，図９，図１０に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【００８９】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００９０】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９１】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ等を用いることができる。
【００９２】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９３】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００９４】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【００９５】
上記実施形態によれば、エラーの対処方法を事前に取得しておくので、実際に対応する時の検索の手間と時間が短縮される。
【００９６】
また、メーカのサポートサイトでは、得ることが難しい、特定のアプリケーションの組み合わせにより発生するエラーについても対処方法を得ることができる。
【００９７】
また、対処の結果について受け付けることにより、有用な情報を蓄積し、エラー対応の際の始めに通知することができる。
【００９８】
【発明の効果】
以上説明したように、本発明によれば、単一または複数のエラーログ対処方法が関係付けられたデータベースを構築し、取得されるエラーログファイルに基づき、前記データベースを参照して有効な対処方法を検索し、該検索された結果を所定の通知先に通知するので、複数の要因の組合せからなるアプリケーションソフトウェアのエラーに対する有効かつ適正な対処方法を一元管理して、複数の被監視装置で発生する様々、かつ、複雑なアプリケーションソフトウェアのエラーにも柔軟に対応したエラー対処方法をシステム管理者に明示することができる。
【００９９】
また、複数の要因の組合せからなるアプリケーションソフトウェアのエラーに対する有効かつ適正な対処方法を一元管理して、複数の被監視装置で発生する様々、かつ、複雑なアプリケーションソフトウェアのエラーにも柔軟に対応したエラー対処方法をシステム管理者に明示することができる利便性に優れたエラー対処システムを自在に構築できるという効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１実施形態を示すエラー監視装置を適用可能なデータ処理システムの一例を示すシステム構成図である。
【図２】図１に示したキーワードデータベースのデータ構造を説明する図である。
【図３】図１に示した対処方法データベースのデータ構造を説明する図である。
【図４】図１に示した組合せデータベースのデータ構造を説明する図である。
【図５】図１に示したＷｅｂサーバデータベースのデータ構造を説明する図である。
【図６】図１に示したエラー監視装置の構成を説明するブロック図である。
【図７】本発明に係るエラー監視装置における第１のデータ処理手順の一例を示すフローチャートである。
【図８】図１に示した被監視装置内で蓄積されるエラーログファイルの一例を示す図である。
【図９】本発明に係るエラー監視装置における第２のデータ処理手順の一例を示すフローチャートである。
【図１０】本発明に係るエラー監視装置における第３のデータ処理手順の一例を示すフローチャートである。
【図１１】図６に示した表示部に表示されるデータベース更新メニュー画面の一例を示す図である。
【図１２】図６に示した表示部に表示されるデータベース更新のための入力メニュー画面の一例を示す図である。
【図１３】図３に示した対処方法データベースの更新状態を示す図である。
【図１４】図４に示した組み合せログデータベースの更新状態を示す図である。
【図１５】監視サーバから管理者への処理結果通知画面の一例を示す模式図である。
【図１６】本発明に係るエラー監視装置で読み出し可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【符号の説明】
２１  通信部
２２  制御部
２３  システムバス
２４  エラーログ監視部
２５  ＤＢ検索部
２６  表示制御部
２７  表示部
２８  記憶制御部
２９  記憶部
２９−１  キーワードデータベース
２９−２  対処方法データベース
２９−３  組合せログデータベース
２９−４  Ｗｅｂログデータベース
２９−５  取得情報記憶領域
３０  入力部
【図１】
2004213302.tif 000003
【図２】
2004213302.tif 000004
【図３】
2004213302.tif 000005
【図４】
2004213302.tif 000006
【図５】
2004213302.tif 000007
【図６】
2004213302.tif 000008
【図７】
2004213302.tif 000009
【図８】
2004213302.tif 000010
【図９】
2004213302.tif 000011
【図１０】
2004213302.tif 000012
【図１１】
2004213302.tif 000013
【図１２】
2004213302.tif 000014
【図１３】
2004213302.tif 000015
【図１４】
2004213302.tif 000016
【図１５】
2004213302.tif 000017
【図１６】
2004213302.tif 000018