(57)【要約】【課題】コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする。【解決手段】コンピュータに障害が発生したことを検出すると、障害情報抽出部１３２が、システムログ１４１及び稼働情報ログ１４２から、抽出条件テーブル１４５を参照して、エラー番号、メッセージＩＤ、オブジェクト、及びイベントからなる障害パターンを抽出する。資料ＩＤ決定部１３３は、抽出した障害パターンにより関連情報テーブル１４４を参照して、前記障害パターンに対応する資料ＩＤ９０２と、それを収集するために実行すべきコマンド９０３を取得する。資料収集部１３１は、このコマンド９０３を実行して、前記障害パターンで特定される障害に対処するのに有益な資料を取得する。前記障害パターンと対応する資料ＩＤ及びコマンドを含む定義ファイル１４６が、管理システム２００に送信され、追加収集すべき資料があればユーザシステム１００で追加の資料収集が実行される。【選択図】  図３
2011118695.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理システムであって、１又は複数の前記コンピュータと通信可能に接続されている管理コンピュータを備え、
前記コンピュータは、自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、
当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、
前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、
前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、
前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、
抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、
前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、
前記障害パターンと、それに対応する前記障害対処情報及び前記コマンドとの組み合わせを障害対処情報定義情報として記録するとともに、当該障害対処情報定義情報を前記管理コンピュータに送信する障害対処情報定義情報生成部と、
を備え、
前記管理コンピュータは、当該管理コンピュータが通信可能に接続されている前記各コンピュータについての前記障害パターンが互いに識別可能に記録されている管理用障害パターン記録部と、
前記各コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している管理用関連情報記録部と、
前記コンピュータの前記障害対処情報定義情報生成部から送信された前記障害対処情報定義情報と、前記管理用障害パターン記録部及び前記管理用関連情報記録部とを比較する追加障害対処情報判定部と、
前記管理用障害パターン記録部及び前記管理用関連情報記録部に、前記障害対処情報定義情報に記録されていない情報が記録されていると判定した場合に、前記障害対処情報定義情報を前記管理用障害パターン記録部及び前記管理用関連情報記録部に記録されている内容に更新して前記コンピュータに送信する障害対処情報定義情報更新部と、
を備えている情報処理システム。
【請求項２】
請求項１に記載の情報処理システムであって、
前記コンピュータは、前記管理コンピュータから受信した前記障害対処情報定義情報を、前記障害パターン記録部及び前記関連情報記録部に記録されている内容と比較し、いずれかに記録されている内容が、受信した前記障害対処情報定義情報に記録されている内容と相違すると判定した場合に、当該障害対処情報定義情報によって、前記障害パターン記録部又は前記関連情報記録部を更新する記録更新部を備えている、情報処理システム。
【請求項３】
請求項１に記載の情報処理システムであって、
前記管理コンピュータは、前記各コンピュータから受信する前記障害対処情報定義情報に基づいて、前記管理用障害パターン記録部及び前記管理用関連情報記録部の内容を変更するために外部からの操作入力を受け付ける操作入力部を備えている情報処理システム。
【請求項４】
請求項１に記載の管理コンピュータであって、自身が保持している前記管理用障害パターン記録部及び前記管理用関連情報記録部の内容によって更新した前記障害対処情報定義情報を、前記各コンピュータに保持されている前記障害パターン記録部及び前記関連情報記録部の内容を更新すべく、適時に前記各コンピュータに送信する管理コンピュータ。
【請求項５】
コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理装置であって、
自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、
当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、
前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、
前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、
前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、
抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、
前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、
を備えている情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置、及び管理コンピュータに係わり、特に、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータに関する。
【背景技術】
【０００２】
今日、多数のコンピュータが通信ネットワークによって接続されてなる大規模な情報処理システムが構築され運用されている。このような大規模情報処理システムにおいては、プロセッサ、記憶装置、通信機器等のハードウェアに起因する問題、情報処理装置のハードウェア上で稼働しているオペレーティングシステム（Operating System、「ＯＳ」）、アプリケーション、各種通信プログラム等のソフトウェアに起因する問題、あるいはユーザ、システム管理者等に係わるヒューマンエラーによる問題など、多種多様な要因によってシステム障害が発生しうる。  
このように、一つの障害でも、多数のハードウェア、ソフトウェア、あるいは人的な要因が複合して引き起こされている場合もあるため、障害の原因を突き止めてその障害から情報処理システムを復旧させるためには、多数の資料を収集して解析する必要がある。このような資料には、各コンピュータのＯＳがシステム上のイベントや状態の変化を記録しているシステムログ（シスログ）、各種構成・設定ファイル、ＯＳ上で稼働しているアプリケーションが稼働状態を記録しているアプリケーションログなどが含まれる。
【０００３】
障害の原因を解析するためには、例えばシステム管理者がこのような資料を参照して経験によって障害個所を特定していくといったプロセスが必要であり、解決に時間と労力を要する問題があった。より具体的には、例えば情報処理システムのベンダーに属するサポートエンジニアが、運用側のシステム管理者に障害に関する問診を行い、障害時用の資料収集コマンドなどによる資料収集を指示することで調査が進められていた。  
この場合、収集対象の資料を人間の判断で選択すると、本来必要な資料が収集対象から漏れるおそれがある。これを防止すべく、必要と考えられる資料を網羅的に収集した場合には、収集する資料が膨大な量になり、その膨大な資料を時間と労力を費やして人手で解析することとなる。
【０００４】
この問題について特許文献１では、障害原因の調査のために必要となる資料を、障害の事象に応じてあらかじめ構造的に定義しておき、原因調査に有益と考えられる順に、繰り返し資料群を自動収集する方法を提案している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１６９６１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１が提案する技術によれば、どのような資料を収集するかについては優先順位が付けられているものの、発生した各障害に関しては、あらかじめ決定しておいた資料を取得することになる。前述のとおり、情報処理システムは複雑化しており、発生した障害の内容だけから原因調査に必要な資料を判断することは困難である。また、優先順位にもとづき資料を取得するにあたり、より効率的に資料を取得するためには、発生した障害について障害原因の調査に実質的に有益な資料は何であるかが適時に見直され、収集する資料の優先順位を更新する仕組みが必要とされる。
【０００７】
本発明は上記の及び他の課題を解決するためになされたものであり、その一つの目的は、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータを提供することである。
【課題を解決するための手段】
【０００８】
本発明は上記の及び他の問題に鑑みてなされたもので、その一態様は、コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理システムであって、１又は複数の前記コンピュータと通信可能に接続されている管理コンピュータを備え、前記コンピュータは、自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、前記障害パターンと、それに対応する前記障害対処情報及び前記コマンドとの組み合わせを障害対処情報定義情報として記録するとともに、当該障害対処情報定義情報を前記管理コンピュータに送信する障害対処情報定義情報生成部と備え、前記管理コンピュータは、当該管理コンピュータが通信可能に接続されている前記各コンピュータについての前記障害パターンが互いに識別可能に記録されている管理用障害パターン記録部と、前記各コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している管理用関連情報記録部と、前記コンピュータの前記障害対処情報定義情報生成部から送信された前記障害対処情報定義情報と、前記管理用障害パターン記録部及び前記管理用関連情報記録部とを比較する追加障害対処情報判定部と、前記管理用障害パターン記録部及び前記管理用関連情報記録部に、前記障害対処情報定義情報に記録されていない情報が記録されていると判定した場合に、前記障害対処情報定義情報を前記管理用障害パターン記録部及び前記管理用関連情報記録部に記録されている内容に更新して前記コンピュータに送信する障害対処情報定義情報更新部とを備えている情報処理システムである。
【発明の効果】
【０００９】
本発明によれば、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータを提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態による資料収集システム１の全体構成図である。
【図２】本発明の一実施形態に係る資料収集システム１に適用されるコンピュータ１０の一例を示す構成図である。
【図３】本発明の一実施形態に係るユーザシステム１００のソフトウェア構成の一例を示す図である。
【図４】本発明の一実施形態に係る管理システム２００のソフトウェア構成の一例を示す図である。
【図５】本発明の一実施形態に係るシステムログ５００の一例を示す図である。
【図６】本発明の一実施形態に係る稼働情報ログ６００の一例を示す図である。
【図７】本発明の一実施形態に係る抽出条件テーブル７００の一例を示す図である。
【図８】本発明の一実施形態に係る固有情報テーブル８００の一例を示す図である。
【図９】本発明の一実施形態に係る関連情報テーブル９００の一例を示す図である。
【図１０】本発明の一実施形態に係る定義ファイル１０００の一例を示す図である。
【図１１】本発明の一実施形態に係る既知情報データベース１１００の一例を示す図である。
【図１２】本発明の一実施形態に係る関連情報データベース１２００の一例を示す図である。
【図１３】本発明の一実施形態に係る資料収集システム１の全体処理フローの一例を示す図である。
【図１４】本発明の一実施形態における障害情報抽出処理フローの一例を示す図である。
【図１５】本発明の一実施形態における資料ＩＤ決定処理フローの一例を示す図である。
【図１６】本発明の一実施形態における追加資料判定処理フローの一例を示す図である。
【図１７】本発明の一実施形態におけるテーブル更新処理フローの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下本発明の一実施形態に係る資料収集システムについて、添付図面を参照しつつ説明する。
【００１２】
《システム全体構成》
図１は、本発明の一実施形態に係る情報処理システムとしての資料収集システム１の全体構成の一例を示す図である。資料収集システム１は、コンピュータであるユーザシステム１００と、管理コンピュータである管理システム２００と、ユーザシステム１００と管理システム２００との間を通信可能に接続している通信ネットワークＮＷとを備えている。  
ユーザシステム１００は、コンピュータによって種々の情報処理を実行すべくユーザのサイトに設置された情報処理システムである。図１の例では、ユーザシステムＡ（１００Ａ）及びＢ（１００Ｂ）の２つのユーザシステムが設置されているが、設置されるユーザシステム１００は１つでも、あるいは３つ以上でもよい。
【００１３】
管理システム２００は、ユーザシステム１００で収集された障害に関する情報（資料）を取得して、当該ユーザシステム１００の保守等を行う要員であるサポートエンジニア等による調査に供する機能を有する情報処理システムである。この管理システム２００は、ユーザシステム１００を設計、製造、販売したベンダーに属しており、ベンダーがユーザシステム１００で発生する種々の障害について、その原因を調査、解析し、ユーザに適切な対処法を迅速に提供するために設けられている。  
通信ネットワークＮＷは、各ユーザシステム１００と管理システム２００との間を通信可能に接続している通信回線である。この通信ネットワークＮＷは、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、ＳＡＮ（Storage Area Network）、インターネット、及び専用線等の任意の通信回線を採用して構築することができる。
【００１４】
《ハードウェア構成》
次に、上記のユーザシステム１００及び管理システム２００のハードウェア構成について説明する。図２に、ユーザシステム１００及び管理システム２００として使用することができるコンピュータ１０のハードウェア構成の一例を示している。  
コンピュータ１０は、中央処理装置１１（例えばＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）、以下簡単のため「ＣＰＵ」と称する）、主記憶装置１２（例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等の記憶素子を備えるメモリ）、補助記憶装置１３（例えばＨＤＤ（Hard Disk Drive））、ユーザの操作入力を受け付ける入力装置１４（例えばキーボードやマウス）、出力装置１５（例えば液晶モニタ）、他の装置との間の通信を実現する通信インタフェース１６（例えばＮＩＣ（Network Interface Card）やＨＢＡ（Host Bus Adapter）)を備えている。
【００１５】
《ソフトウェア構成》
次に、ユーザシステム１００及び管理システム２００のソフトウェア構成について説明する。
【００１６】
〈ユーザシステム１００〉
図３にユーザシステム１００のソフトウェア構成の一例を示している。  
ユーザシステム１００は、ＯＳ１１０と、データＩ／Ｏ部１２０、資料収集部１３１（障害対処情報収集部）、障害情報抽出部１３２、資料ＩＤ決定部１３３（障害対処情報特定部）、定義ファイル生成部１３４（障害対処情報定義情報生成部）、稼働監視部１３５、定義ファイル受領部１３６、及びテーブル更新部１３７（記録更新部）を有するエージェント部１３０と、システムログ１４１（障害情報記録部）、稼働情報ログ１４２（稼働情報記録部）、固有情報テーブル１４３（障害パターン記録部）、関連情報テーブル１４４（関連情報記録部）、抽出条件テーブル１４５、及び定義ファイル１４６（障害対処情報定義情報）を有する管理データ格納部１４０とを備えている。
【００１７】
ＯＳ１１０は、ユーザシステム１００で実行される各種アプリケーションのインタフェースとしてユーザシステム１００のハードウェア制御等を実行するソフトウェアである。ＯＳ１１０は、特に特定のシステムに限定されることはない。例えばＷｉｎｄｏｗｓ（登録商標）、あるいはＵＮＩＸ（登録商標）系のオペレーティングシステム、例えばＬｉｎｕｘ（登録商標）がこのＯＳ１１０として好適に用いられる。
【００１８】
データＩ／Ｏ部１２０は、ユーザシステム１００と外部機器との間でのデータ入出力機能を備えている。  
エージェント部１３０は、後述する管理システム２００のソフトウェアと連携して本実施形態の資料収集システムの各種機能をユーザシステム１００側で実現する、以下のプログラム群である。
【００１９】
資料収集部１３１は、ユーザシステム１００でなんらかの障害が発生したことを契機として、後述する定義ファイル１４６に規定されている内容に従って、障害の発生原因を調査するために必要となる資料を収集する機能を有する。具体的には、資料収集部１３１は、例えば障害発生時のメモリ格納情報を含むメモリダンプの取得、ＣＰＵ利用率及びメモリ使用率、あるいはＨＤＤ空き容量の取得といった、発生した障害の内容に応じて定められた資料の収集を実行する。
【００２０】
障害情報抽出部１３２は、後述するシステムログ１４１及び稼働情報ログ１４２を参照して、障害発生時のシステムの状況及びユーザシステム１００の稼働状況に関する情報を取得する。システムログ１４１は、前記したＯＳ１１０が有する機能によって生成され、ユーザシステム１００を構成するコンピュータ１０の主記憶装置１２に逐次格納されている。
【００２１】
資料ＩＤ決定部１３３は、ユーザシステム１００において発生した障害の内容に応じて、その障害の原因調査に必要となる取得すべき資料の種類を特定する資料ＩＤを決定する機能を有する。  
定義ファイル生成部１３４は、ユーザシステム１００において発生した障害について、その障害の内容に応じてどのような種類の資料を収集するか、及び当該資料収集を実行するためのコマンド等を記録している定義ファイル１３４を生成する機能を有する。
【００２２】
稼働監視部１３５は、ユーザシステム１００の稼働状況を常時監視し、後述する稼働情報ログ１４２として記録する機能を有する。  
定義ファイル受領部１３６は、ユーザシステム１００になんらかの障害が発生した場合に、後述する条件の下で管理システム２００から定義ファイル１４６を受信する機能を有する。  
テーブル更新部１３７は、一定の条件下で管理システム２００からフィードバックされる情報に基づいて、後述の各種テーブルの内容を更新処理する機能を有する。
【００２３】
エージェント部１３０を構成する以上の各機能部の機能は、例えばユーザシステム１００を構成するコンピュータ１０の補助記憶装置１３から、各機能を提供するプログラムを主記憶装置１２に読み出して、ＣＰＵ１１によって実行することにより実現される。各機能部で実行される具体的な処理については、フローチャートを参照して後述する。
【００２４】
次に、管理データ格納部１４０に格納されている各テーブル、ファイル等について説明する。これらのテーブル等に記録されているデータは、ユーザシステム１００が実行する資料収集等の情報処理に際して参照され、利用される。
【００２５】
図５に、システムログ５００（１４１）の一例を示している。システムログ５００には、時刻５０１、エラー番号５０２、及びメッセージＩＤ５０３が、互いに関連づけられて１レコードとして記録されている。このシステムログ５００は、ユーザシステム１００に実装されているＯＳ１１０が有するログ機能によって、ＯＳ１１０になんらかの障害が発生した場合に記録される。
【００２６】
なお、上記でシステムログ１４１に符号５００をあらためて付したのは、ユーザシステム１００の一構成要素であるシステムログ１４１について、それ自体独立した要素として特定する際の便宜のためである。これは、以下説明する他のテーブル、ファイル等についても同様である。
【００２７】
時刻５０１は、当該システムログ５００のレコードが記録されたときに、そのレコードの一部としてレコード記録時の時刻が、ユーザシステム１００が有するシステムクロックから取得して記録される。エラー番号５０２は、ＯＳ１１０が検出した障害の内容に応じて付与される識別符号であり、どのような障害についてどのような識別符号を付与するかは、ＯＳ１１０の仕様に依存する。メッセージＩＤ５０３には、ＯＳ１１０が検出した障害の内容に応じて付与される、障害の内容を表す短いメッセージと、それに付随する固有の識別符号が記録される。図５の例では、システムログ５００の最初のレコードとして、２００９年４月２０日１２時３４分００秒に、エラー番号５０２が「222」、メッセージＩＤ５０３が「000」で特定される障害（警告）が発生したことが記録されている。
【００２８】
次に、稼働情報ログ６００（１４２）について説明する。図６に、稼働情報ログ６００の一例を示している。稼働情報ログ６００には、時刻６０１、オブジェクト６０２、及びイベント６０３が、互いに関連づけられて１レコードとして記録されている。稼働情報ログ６００は、ユーザシステム１００のエージェント部１３０にある稼働監視部１３５によって、ユーザシステム１００で動作しているアプリケーション等のソフトウェアの動作状況等に関し、所定のイベントが発生した場合に記録される。
【００２９】
時刻６０１は、稼働情報ログ６００のレコードが記録されたときに、そのレコードの一部としてレコード記録時の時刻が、ユーザシステム１００が有するシステムクロックから取得して記録される。オブジェクト６０２は、稼働監視部１３５が監視対象とした特定のソフトウェア、サービス、ユーザ等の情報を記録する。イベント６０３には、監視対象であるオブジェクト６０２に対して実行された操作など（ソフトウェアのインストール・アンインストール、サービスの起動・停止、ユーザのログイン・ログアウト等）のイベントの内容が記録される。
【００３０】
図６の例では、稼働情報ログ６００の３番目のレコードとして、２００９年４月３０日２３時５０分００秒に、ユーザシステム１００においてサービスＡが起動されたことが記録されている。なお、稼働情報ログ６００のレコードとしてどのような項目を監視するかは、稼働監視部１３５の仕様として適宜決定することができる。
【００３１】
次に、抽出条件テーブル７００（１４５）について説明する。図７に、抽出条件テーブル７００の一例を示している。抽出条件テーブル７００は、エージェント部１３０にある障害情報抽出部１３２が、ユーザシステム１００で発生した障害に関する情報に関し、どのような情報について、どの程度の時間スパンにおいていくつのサンプルを取得するかを規定している。抽出条件テーブル７００は、エラー番号７０１、メッセージＩＤ７０２、時間閾値の下限値７０３、時間閾値の上限値７０４、及びサンプル個数に相当するサンプリングの回数についての回数閾値７０５を、互いに関連づけて１レコードとして記録している。
【００３２】
エラー番号７０１及びメッセージＩＤ７０２は、図５のシステムログ５００におけるエラー番号５０２及びメッセージＩＤ５０３と同様である。時間閾値の下限値７０３は、障害情報抽出部１３２がシステムログ５００から障害情報を抽出する場合に、障害発生時点からどれくらいの時間だけさかのぼって障害情報の抽出を実行するかを規定している閾値である。時間閾値の上限値７０４は、逆に、障害発生時点から後のどれくらいの時間にわたって（未来に向かって）障害情報を抽出するかを規定している閾値である。回数閾値７０５は、特定のエラー番号７０１とメッセージＩＤ７０２とで指定される障害について、障害情報抽出部１３２が、いくつまでのサンプルを抽出するかを規定している閾値である。
【００３３】
例えば図７の最初のレコードの例では、エラー番号７０１が「111」、メッセージＩＤ７０２が「222」で特定される障害情報については、システムログ５００から、まず障害発生時刻から３６００秒（１時間）前までさかのぼって障害情報を抽出し、次いで障害発生後１０秒まで下って障害情報を抽出する。その際、抽出した障害情報の数が回数閾値７０５に記録されている回数に達したら、障害情報抽出部１３２は抽出処理を終了することとなる。
【００３４】
なお、抽出条件テーブル７００は、ユーザシステム１００の運用を開始する前に、例えば本資料収集システム１を提供しているベンダー等が、あらかじめ設定した抽出条件のレコードを格納して、例えば補助記憶装置１３（図２）に記憶させておくものとする。
【００３５】
次に、固有情報テーブル８００（１４３）について説明する。図８に、本実施形態における固有情報テーブル８００の一例を示している。固有情報テーブル８００には、エラー番号８０１、メッセージＩＤ８０２、オブジェクト８０３、及びイベント８０４に、パターンＩＤ８０５が関連づけられて、１つのレコードとして記録されている。
【００３６】
エラー番号８０１及びメッセージＩＤ８０２は、図５のシステムログ５００におけるエラー番号５０２及びメッセージＩＤ５０３と同様である。また、オブジェクト８０３及びイベント８０４は、図６の稼働情報ログ６００におけるオブジェクト６０２及びイベント６０３と同様である。
【００３７】
パターンＩＤ８０５は、前記のように、エラー番号８０１、メッセージＩＤ８０２、オブジェクト８０３、及びイベント８０４の組み合わせに対して、これらの組み合わせを互いに識別するために付与されている固有の識別符号である。すなわち、パターンＩＤ８０５は、システムログ５００に記録されているエラーの内容（エラー番号８０１及びメッセージＩＤ８０２）と、稼働情報ログ６００に記録されている障害（エラー）発生時近傍でのユーザシステム１００の稼働状況、操作状況（オブジェクト８０３及びイベント８０４）との組み合わせを、ユーザシステム１００において発生する障害のパターンと位置づけ、それらの障害パターン毎に固有の識別符号であるパターンＩＤ８０５を付して識別するようにしている。
【００３８】
なお、図８の例では、パターンＩＤ８０５として、０以上の整数を各障害パターンに順次割り当てているが、他の識別可能な符号を適宜採用してよい。パターンＩＤ８０５を含む固有情報テーブル８００は、ユーザシステム１００の運用を開始する前に、あらかじめ既知の障害パターンとその固有のパターンＩＤ８０５とを組み合わせて、例えば補助記憶装置１３（図２）に記憶させておくものとする。詳しくは後述するが、ユーザシステム１００の運用中に、エージェント部１３０にある資料ＩＤ決定部１３３が、パターンＩＤ８０５が付されていない未知の障害パターンを検出した場合には、パターンＩＤ８０５に「該当なし（例えば「null」）」を記録する。
【００３９】
また、固有情報テーブル８００は、ユーザシステム１００の運用を開始する前に、例えば本資料収集システム１を提供しているベンダー等が、あらかじめ設定した障害パターンとパターンＩＤ８０５との既知の組み合わせをレコードとして格納して、例えば補助記憶装置１３（図２）に記憶させておくものとする。
【００４０】
次に、関連情報テーブル９００（１４４）について説明する。図９に、本実施形態における関連情報テーブル９００の一例を示している。関連情報テーブル９００には、パターンＩＤ９０１、資料ＩＤ９０２、及びコマンド９０３が、互いに関連づけられて１レコードとして記録されている。
【００４１】
パターンＩＤ９０１は、図８に関して前記のように、ユーザシステム１００において発生する障害パターンを特定するための識別符号である。資料ＩＤ９０２は、特定のパターンＩＤ９０１により識別される障害パターンが検出された場合に、ユーザシステム１００においてエージェント部１３０にある資料採取部１３１が収集すべき資料を識別するための識別符号である。ここでは資料ＩＤ９０２として、資料毎に固有の数字を付与している。図９に示すように、あるパターンＩＤ９０１で特定される障害パターンについて収集すべき資料は一つとは限らないため、１つのパターンＩＤ９０１に対して２以上の資料ＩＤ９０２が関連づけられることがある。
【００４２】
コマンド９０３は、資料ＩＤ９０２で特定される資料の収集を実行するために、ＯＳ１１０等に与えられるコマンドが記録される。例えば資料ＩＤ９０２によって特定される資料が障害発生時のメモリダンプであった場合には、対応するコマンド９０３に、ＯＳ１１０に対してメモリダンプを作成させる旨のコマンドを示す識別符号が記録される。
【００４３】
なお、関連情報テーブル９００は、ユーザシステム１００の運用を開始する前に、例えば本資料収集システム１を提供しているベンダー等が、あらかじめ設定したパターンＩＤ９０１と、資料ＩＤ９０２及びコマンド９０３との既知の組み合わせをレコードとして格納して、例えば補助記憶装置１３（図２）に記憶させておくものとする。
【００４４】
次に、定義ファイル１０００（１４６）について説明する。図１０に、本実施形態における定義ファイル１０００の一例を示している。定義ファイル１０００には、エラー番号１００１、メッセージＩＤ１００２、オブジェクト１００３、イベント１００４、パターンＩＤ１００５、資料ＩＤ１００６、コマンド１００７、及び更新フラグ１００８が、互いに関連づけられて１レコードとして記録されている。
【００４５】
この定義ファイル１０００は、ユーザシステム１００においてある障害が発生した場合に、その障害に関して障害情報抽出部１３２が抽出した障害情報のパターンについて、エラー番号１００１、メッセージＩＤ１００２、オブジェクト１００３、及びイベント１００４に基づいてパターンＩＤ１００５とそれに関連づけられた資料ＩＤ１００６及びコマンド１００７を特定し、対応するコマンド１００７を実行すべく、エージェント部１３０の定義ファイル生成部１３４によって生成され、資料収集部１３１等により参照される。
【００４６】
なお、定義ファイル１０００は、ユーザシステム１００の運用を開始する前に、あらかじめ既知の障害パターンと、その固有のパターンＩＤ８０５、資料ＩＤ１００６、及びコマンド１００７の組み合わせをレコードとして格納して、例えば補助記憶装置１３（図２）に記憶させておくものとする。
【００４７】
エラー番号１００１、メッセージＩＤ１００２、オブジェクト１００３、イベント１００４、及びパターンＩＤ１００５は、図８の固有情報テーブル８００に記録されている、エラー番号８０１、メッセージＩＤ８０２、オブジェクト８０３、イベント８０４、及びパターンＩＤ８０５と同様である。また、資料ＩＤ１００６及びコマンド１００７は、図９の関連情報テーブル９００に記録されている資料ＩＤ９０２及びコマンド９０３と同様である。
【００４８】
更新フラグ１００８は、ユーザシステム１００のテーブル更新部１３７が、管理システム２００から受信した定義ファイル１０００の内容に基づいて自身の固有情報テーブル８００及び関連情報テーブル９００の内容を更新するか判定するために参照するフラグであり、更新する場合は「１」が、更新しない場合には「０」が記録される。
【００４９】
〈管理システム２００〉
次に、管理システム２００のソフトウェア構成について説明する。図４に、本実施形態における管理システム２００のソフトウェア構成の一例を示している。管理システム２００は、ＯＳ２１０、データＩ／Ｏ部２２０、追加資料判定部２３１（追加障害対処情報判定部）、定義ファイル更新部２３２（障害対処情報定義情報更新部）、既知情報データベース２４１（管理用障害パターン記録部）、関連情報データベース２４２（管理用関連情報記録部）、及び定義ファイル２４３を備えている。
【００５０】
ＯＳ２１０及びデータＩ／Ｏ部２２０は、図３のユーザシステム１００におけるＯＳ１１０及びデータＩ／Ｏ部１２０と同等の機能を有するものであり、ここでは説明を省略する。
【００５１】
追加資料判定部２３１は、ユーザシステム１００において定義ファイル生成部１３４が生成した定義ファイル１４６（１０００）に対して、自身が保持している、後述の定義ファイル２４３の内容と比較し、ユーザシステム１００で生成された定義ファイル１４６に含まれていない資料があると判定した場合に、その資料を追加する機能を有する。
【００５２】
定義ファイル更新部２３２は、追加資料判定部２３１において追加資料が必要であると判断された場合に、後述する定義ファイル２４３の更新を行う機能を有する。
【００５３】
管理システム２００が有する以上の各機能部の機能は、例えば管理システム２００を構成するコンピュータ１０の補助記憶装置１３から、各機能を提供するプログラムを主記憶装置１２に読み出して、ＣＰＵ１１によって実行することにより実現される。各機能部で実行される具体的な処理については、フローチャートを参照して後述する。
【００５４】
次に、管理システム２００に保持されている各テーブル、ファイル等について説明する。これらのテーブル等に記録されているデータは、管理システム２００が実行する情報処理に際して参照され、利用される。
【００５５】
図１１に、本実施形態における既知情報データベース１１００の一例を示している。この既知情報データベース１１００が保持している情報の項目は、ユーザシステム１００にある固有情報テーブル８００と同様である。しかし、この既知情報データベース１１００に記録されている内容（レコード）は、管理システム２００に接続されている各ユーザシステム１００から受信される定義ファイル１０００の内容を反映すること、及びサポートエンジニア（資料収集システムのベンダー側にいる管理者）が管理システム２００の入力装置１４（操作入力部）を介してその内容を更新することを通じて、同一の障害パターンであってもパターンＩＤ１１０５の項目がユーザシステム１００側の固有情報テーブル８００に記録されているパターンＩＤ８０５とは異なる場合があるという差異がある（例えば図１１のパターンＩＤ１１０５におけるセル斜線部）。
【００５６】
図１２に、本実施形態における関連情報データベース１２００の一例を示している。この関連情報データベース２４２が保持している情報の項目は、ユーザシステム１００にある関連情報テーブル９００と同様である。しかし、この関連情報データベース１２００にも、前記の既知情報データベース１１００の場合と同様の理由で、資料ＩＤ１２０２及びコマンド１２０３の項目はユーザシステム１００側の関連情報テーブル９００とは異なる場合があるという差異がある。
【００５７】
定義ファイル２４３は、ユーザシステム１００に保持されている定義ファイル１０００と同様であるが、管理システム２００には、管理システム２００が通信ネットワークＮＷを通じて管理している各ユーザシステム１００に対応する定義ファイル２４３が保持されている。これらの定義ファイル２４３は、対応するユーザシステム１００に送信され、対応する定義ファイル１４６（１０００）を更新する処理に使用される。
【００５８】
《本実施形態における処理フローの説明》
次に、本実施形態に係る資料収集システム１によって実行される処理フローについて、図面を参照しつつ順次説明する。なお、各処理フローにおいて使用されている符号Ｓは、「ステップ」を表している。
【００５９】
〈システム全体の処理フロー〉
図１３に、本実施形態に係る資料収集システム１によって実行される処理フロー全体について示している。この処理フローは、資料収集システム１において管理システム２００によって管理されている対象のコンピュータのいずれか、すなわちいずれかのユーザシステム１００においてなんらかの障害が発生した場合に実行される処理フローである。図１３は、管理対象のユーザシステム１００における障害発生から、管理システム２００側でサポートエンジニア等の要員が障害の調査及び原因究明に必要な資料を入手するまでの処理の流れを表している。
【００６０】
まずユーザシステム１００で障害が発生したことをＯＳ１１０から通知された場合に、障害情報抽出部１３１は、ＯＳ１１０が記録しているシステムログ１４１の情報をもとに、稼働監視部１３５が記録している稼働情報ログ１４２のレコードの中から、所定の条件に合致する稼働情報を抽出する（Ｓ１３０１）。この障害情報抽出処理については別に後述する。
【００６１】
次いで、資料ＩＤ決定部１３３は、固有情報テーブル１４３を参照し、システムログ１４１に記録されているエラー番号５０２及びメッセージＩＤ５０３、及び障害情報抽出部１３１が抽出した、障害に関連する可能性のある稼働情報に対応する資料ＩＤを取得する（Ｓ１３０２）。この資料ＩＤ決定処理についても、別に後述する。
【００６２】
定義ファイル生成部１３４は、資料ＩＤ決定部１３３から取得した資料ＩＤを入力として、関連情報テーブル１４４から、現在発生している障害と管理対象であるユーザシステム１００の稼働情報に応じた、障害調査に必要な資料を定義する定義ファイル１４６を生成する（Ｓ１３０３）。
【００６３】
資料収集部１３１は、この定義ファイル１４６の内容に基づき、管理対象のユーザシステム１００について資料収集を行う（Ｓ１３０４）。
【００６４】
障害が発生したユーザシステム１００での資料収集が完了したら、資料収集部１３１は、自身が収集した資料（障害発生時のメモリダンプ等）、障害発生時のシステムログ１４１、及びシステムログ１４１に関連して取得された稼働情報ログ１４２と、システムログ１４１、稼働情報ログ１４２等に基づいて生成された定義ファイル１４６を、通信ネットワークＮＷを通じて管理システム２００に送信する（Ｓ１３０５）。
【００６５】
前記定義ファイル１４６を受信した管理システム２００では、追加資料判定部２３１が、受信した定義ファイル１４６を自身が保持している定義ファイル２４３の記録と比較して（Ｓ１３０７）、該当する障害パターンについて追加で収集すべき資料があるか判定する（Ｓ１３０８）。
【００６６】
追加資料判定部２３１が追加で収集すべき資料があると判定した場合（Ｓ１３０８、Ｙｅｓ）、定義ファイル更新部２３２が、管理システム２００に保持されている定義ファイル２４３に追加で収集すべき資料を追加する更新を行う（Ｓ１３０９）。このように、管理システム２００側で、あるユーザシステム１００から受信した資料（システムログ、稼働情報ログ、及び定義ファイル）に含まれていない資料ＩＤで特定される資料が含まれることがあるのは、例えば、管理システム２００に接続されている他のユーザシステム１００から受信した資料に基づいて自身の定義ファイル２４３が更新されることがある、及びいずれかのユーザシステム１００から受信した資料に基づいて、管理システム２００側の要員が、通知された障害について収集すべき資料を経験等により見直し、管理システム２００の既知情報データベース２４１、関連情報データベース２４２、及び定義ファイル２４３を更新しておく、といった処理を行うことがあるためである。
【００６７】
追加資料判定部２３１が追加で収集すべき資料がないと判定した場合（Ｓ１３０８、Ｎｏ）、管理システム２００は、データＩ／Ｏ部２２０、及びディスプレイ装置、プリンタ等の出力装置１５を通じて、ユーザシステム１００から受信した資料を出力する（Ｓ１３１０）。管理システム２００側の要員は、出力された資料を参照して、ユーザシステム１００における障害発生の原因、及び対策を検討して、ユーザシステム１００のシステム管理者へ報告することとなる。具体的には、ユーザシステム１００で取得した資料により障害の要因が特定できたら、管理システム２００側の要員は、電話や電子メールなど適当な方法により障害が発生したユーザシステム１００のシステム管理者に回答することとなる。
【００６８】
なお、あるユーザシステム１００から受信した定義ファイル１０００に、過去に同様の障害が発生したことにより対応付けられているパターンＩＤ１００５及び資料ＩＤ１００６が存在せず（パターンＩＤ１００５及び資料ＩＤ１００６に、いずれも「null」が記録）、自身が保持する既知情報データベース２４１から収集すべき資料を決定することができない場合は、管理システム２００の要員がシステムログ１４１、稼働情報ログ１４２を参照して障害調査に必要と判断した資料を管理コンソール（図示略、例えば管理システム２００を構成するコンピュータ１０の入力装置１４を使用してもよい。）から入力する。この入力された内容に従って、定義ファイル更新部２３２が、管理システム２００に保持されている定義ファイル２４３を更新する。それと併せて、定義ファイル更新部２３２は、既知情報データベース２４１に、ユーザシステム１００から受信した、追加で収集する資料及びユーザシステム１００の稼働情報を登録することによって、既知情報データベース２３１を更新する。
【００６９】
障害が発生したユーザシステム１００は、定義ファイル受領部１３６において管理システム２００から定義ファイル２４３を受信し、受信した定義ファイル２４３が更新された定義ファイル２４３であるか判定する（Ｓ１３１１）。更新された定義ファイル２４３であると判定した場合（Ｓ１３１１、Ｙｅｓ）、処理はＳ１３０４に移行し、更新された定義ファイル２４３によって、再度資料の収集が実行される。定義ファイル受領部１３６が更新定義ファイル２４３を受信していないと判定した場合（Ｓ１３１１、Ｎｏ）、ユーザシステム１００において処理が終了する。
【００７０】
以上のように、本実施形態に係る資料収集システム１の全体処理フローによれば、なんらかの障害が発生したことが検知された場合に、ユーザシステム１００に定義ファイル１０００（１４６）の形態で保持されている、障害のパターンと収集すべき資料との対応付けに基づいて、その障害の原因調査、対策の立案に資すると考えられる資料が自動的に収集され、管理システム２００に送信される。したがって、管理システム２００側のサポートエンジニア等の要員は、受信した資料に基づいて迅速に障害に対応することが可能となる。
【００７１】
また、他のユーザシステム１００で発生した障害に関して収集されるべきと判定された資料や、管理システム２００側でサポートエンジニア等の要員がマニュアルで追加、修正等した定義ファイル２４３の内容が自動的にユーザシステム１００の定義ファイル１４６に反映され、追加の資料収集を実行させることができるので、ユーザシステム１００のシステム管理者が個別に定義ファイル１４６をメインテナンスしなくてすむようになる。
【００７２】
〈障害情報抽出処理〉
次に、本実施形態に係る資料収集システムにおける障害情報抽出処理について説明する。図１４に、当該障害情報抽出処理の処理フローの一例を示している。この障害情報抽出処理では、ユーザシステム１００のエージェント部１３０にある障害情報抽出部１３１によって実行される処理であり、システムログ５００、稼働情報ログ６００から、発生した障害に関連する情報を抽出する。
【００７３】
障害情報抽出部１３２は、ユーザシステム１００のシステム管理者の判断、ユーザシステム１００のエージェント部１３０にある稼働監視部１３５等の各種モニタプログラムが障害発生を検知したことを契機として処理を開始する。  
まず、障害情報抽出部１３２は、ユーザシステム１００に保持されているシステムログ５００を参照し、障害検知時刻の直近に記録されている、エラー発生時刻５０１、エラー番号５０２、及びメッセージＩＤ５０３を取得する（Ｓ１４０１）。
【００７４】
次に、障害情報抽出部１３２は、ユーザシステム１００に保持されている稼働情報ログ６００を参照し、抽出条件テーブル１４５において、前記システムログ５００から取得されたエラー番号５０１に対応して抽出条件テーブル１４５に設定されている時間閾値条件及びサンプル回数閾値条件に従って、それらの条件を満たす稼働情報として、オブジェクト６０１及びイベント６０２を抽出する（Ｓ１４０２）。
【００７５】
次いで、障害情報抽出部１３２は、稼働情報ログ６００に、前記抽出条件テーブル１４５に設定されている条件を満たす他のレコードが記録されているか判定する（Ｓ１４０３）。他のレコードが記録されていると判定した場合（Ｓ１４０３、Ｙｅｓ）、障害情報抽出部１３２は、該当する他のすべてのレコードを取得するまでＳ１４０２〜Ｓ１４０４の処理を反復して実行する。
【００７６】
稼働情報ログ６００に他のレコードが存在しないと判定した場合（Ｓ１４０３、Ｎｏ）、障害情報抽出部１３２は、システムログ５００に他のレコードが記録されているか判定し（Ｓ１４０５）、記録されていると判定した場合（Ｓ１４０５、Ｙｅｓ）、システムログ５００から次のレコードを取得し、Ｓ１４０１の処理へ移行する。システムログ５００に他のレコードが記録されていないと判定した場合（Ｓ１４０５、Ｎｏ）、障害情報抽出部１３２は、発生した障害に関するすべてのシステムログ５００及び稼働情報ログ６００についての情報が取得されたので、障害情報抽出処理を終了する。
【００７７】
この障害情報抽出処理によれば、ユーザシステム１００で発生した障害に関する障害情報を自動的に抽出することができ、それに基づいて必要な資料の収集をさらに実行することができる。
【００７８】
〈資料ＩＤ決定処理〉
次に、本実施形態に係る資料収集システムにおいて実行される資料ＩＤ決定処理について説明する。図１５に、この資料ＩＤ決定処理の処理フローの一例を示している。この資料ＩＤ決定処理では、障害情報抽出部１３２が抽出した、システムログ５００のエラー番号５０２及びメッセージＩＤ５０３と、それらシステムログ５００から抽出された情報に関して稼働情報ログ６００から抽出されたオブジェクト６０２及びイベント６０３に基づいて、当該障害の原因調査等に有益な資料を具体的に特定する。
【００７９】
まず、資料ＩＤ決定部１３３は、ユーザシステム１００に保持されている固有情報テーブル８００を参照し、障害情報抽出部１３２が抽出した、システムログ５００のエラー番号５０２及びメッセージＩＤ５０３と、稼働情報ログ６００のオブジェクト６０２及びイベント６０３の組み合わせに一致するパターンＩＤ８０５が記録されているか判定する（Ｓ１５０２）。
【００８０】
一致するパターンＩＤ８０５が記録されていると判定した場合（Ｓ１５０２、Ｙｅｓ）、資料ＩＤ決定部１３３は、関連情報テーブル９００を参照し、パターンＩＤ９０１に関連付けられた資料ＩＤ９０２が記録されているか判定する（Ｓ１５０３、Ｓ１５０４）。関連する資料ＩＤ９０２が存在すると判定した場合（Ｓ１５０５、Ｙｅｓ）、当該資料ＩＤ９０２とそれに関連づけられているコマンド９０３を取得する（Ｓ１５０７）。
【００８１】
資料ＩＤ決定部１３３が、固有情報テーブル８００内に入力されたシステムログ５００のエラー番号５０２及びメッセージＩＤ５０３と、稼働情報ログ６００のオブジェクト６０２及びイベント６０３との組み合わせに対応するパターンＩＤ８０５が記録されていないと判定した場合（Ｓ１５０２、Ｎｏ）、資料ＩＤ決定部１３３は、当該組み合わせに対してパターンＩＤ８０５に「null（値なし）」を記録する（Ｓ１５０４）。
【００８２】
Ｓ１５０５で、関連情報テーブル９００において、パターンＩＤ９０１に関連づけられている資料ＩＤ９０２が記録されていないと判定した場合（Ｓ１５０５、Ｎｏ）、資料ＩＤ決定部１３３は、障害情報抽出部１３２によって抽出された次の障害情報があるか判定し（Ｓ１５０６）、次の障害情報があると判定した場合（Ｓ１５０６、Ｙｅｓ）、処理をＳ１５０１に移行させて、再度固有情報テーブル８００を参照する処理以降を繰り返す。  
次の障害情報がないと判定した場合（Ｓ１５０６、Ｎｏ）、資料ＩＤ決定部１３３は、処理を終了する。
【００８３】
以上の資料ＩＤ決定処理によれば、障害情報抽出部１３２によって抽出された障害情報に基づいて、当該障害の原因調査等に有益な資料と、その資料の収集を実行するためのコマンドとを自動的に特定することができる。
【００８４】
以上の障害情報抽出処理及び資料ＩＤ決定処理について、図５のシステムログ５００、図６の稼働情報ログ６００、図７の抽出条件テーブル７００、図８の固有情報テーブル８００、及び図９の関連情報テーブル９００の例に則して具体的な処理例を説明する。
【００８５】
まず、障害情報抽出部１３２がユーザシステム１００のシステムログ１４１と稼働情報ログ１４２とを参照し，抽出条件テーブル７００から，条件に合致する稼働情報を抽出する。障害情報「エラー番号111，メッセージ777」については，抽出条件テーブル７００より障害発生の３６００秒（１時間）前から１０秒後までの間に記録されている３個までの稼働情報が対象となるため，稼働情報「2009/05/01 00:30:00の設定Bの変更」，「2009/05/01 00:10:00のパッチFの適用」、及び「2009/04/30 23:50:00のサービスAの起動」を抽出する。  
同様に、障害情報「エラー番号333，メッセージ888」についても，抽出条件テーブル７００に規定されている条件（障害発生１００秒前から１０秒後までの間の１個）に従い，稼働情報「2009/05/01 00:00:30の設定Bの変更」を抽出する。
【００８６】
次に、資料ＩＤ決定部１３３が固有情報テーブル８００を参照することにより，上記障害情報抽出部１３２が抽出したシステムログ５００の「エラー番号５０２」及び「メッセージＩＤ５０３」と、稼働情報ログ６００の「オブジェクト６０２」及び「イベント６０３」の組み合わせから、パターンＩＤ８０５を決定する。障害情報「エラー番号111，メッセージ777」と稼働情報「2009/05/01 00:30:00の設定Bの変更」については「パターンＩＤ８０５が「５」、障害情報「エラー番号111，メッセージ777」と稼働情報「2009/05/01 00:10:00のProduct AのパッチF適用」については，パターンＩＤ８０５が「９」を得る。
【００８７】
他方、障害情報「エラー番号111，メッセージ777」と稼働情報「2009/04/31 23:50:00のサービスAの起動」、及び障害情報「エラー番号333，メッセージ888」と稼働情報「2009/04/31 23:50:00のサービスAの起動」の組み合わせについては，ユーザシステム１００では関連する資料ＩＤを一意に決定できないため，パターンＩＤ８０５として「null」を得て，障害情報と稼働情報の組み合わせのみを保持する。
【００８８】
次に，定義ファイル生成部１３４が，関連情報テーブル９００を参照してこれまでに得たパターンＩＤ「５」、及びパターンＩＤ「９」に対応する資料ＩＤ９０２とそれによって特定される資料を収集するために実行すべき具体的なコマンド９０３とを一意に決定する。図９の関連情報テーブル９００の例では、パターンＩＤ「５」に関連して資料ＩＤ「５」及び「５１」とコマンド「Ｂ」及び「Ｃ」を，パターンＩＤ「９」に関連して資料ＩＤ「９」及びコマンド「Ａ」を得る。
【００８９】
〈追加資料判定処理〉
次に、管理システム２００の追加資料判定部２３１によって実行される追加資料判定処理について説明する。図１６に、追加資料判定処理の処理フローの一例を示している。この追加資料判定処理は、ユーザシステム１００で発生した障害に関して、ユーザシステム１００において収集対象として決定された資料に対して、管理システム２００側でそれに追加して収集すべき資料があるかを判定する処理である。
【００９０】
まず、追加資料判定部２３１は、ユーザシステム１００で収集された資料、システムログ５００、稼働情報ログ６００、及び定義ファイル１０００を受信する（Ｓ１６０１）。
【００９１】
次いで、追加資料判定部２３１は、ユーザシステム１００から受信した定義ファイル１０００を参照し、エラー番号５０２及びメッセージＩＤ５０３を取得する（Ｓ１６０２）。
【００９２】
次に、追加資料判定部２３１は、同じくユーザシステム１００から受信した定義ファイル１０００を参照し、前記取得したエラー番号５０２及びメッセージＩＤ５０３に対応する稼働情報として、オブジェクト６０１及びイベント６０２を取得する（Ｓ１６０３）。
【００９３】
次いで、追加資料判定部２３１は、管理システム２００に保持されている既知情報データベース２４１を参照して、ユーザシステム１００側の定義ファイル１０００から取得したエラー番号５０２、メッセージＩＤ５０３、オブジェクト６０１、及びイベント６０２に従って、既知情報データベース１１００に記録されているパターンＩＤを取得し、前記ユーザシステム１００から受信した定義ファイル１０００に記録されているパターンＩＤ８０５と比較する（Ｓ１６０４）。
【００９４】
追加資料判定部２３１は、ユーザシステム１００から受信した定義ファイル１０００に記録されていたパターンＩＤと管理システム２００に保持されている既知情報データベース１１００に記録されていたパターンＩＤとが一致するか判定する（Ｓ１６０５）。一致すると判定した場合（Ｓ１６０５、Ｙｅｓ）、追加資料判定部２３１は、管理システム２００に保持されている関連情報データベース１２００を参照し、前記取得したパターンＩＤに対応付けられている資料ＩＤを取得する（Ｓ１６０６）。そして、ユーザシステム１００から受信した定義ファイル１０００に記録されている資料ＩＤと異なる資料ＩＤを、既知情報データベース１１００に反映させるために、主記憶装置１２等に格納する（Ｓ１６１０）。
【００９５】
次いで追加資料判定部２３１は、ユーザシステム１００から受信した定義ファイル１０００に他のレコードが記録されているか判定し（Ｓ１６１１）、記録されていると判定した場合（Ｓ１６１１、Ｙｅｓ）、当該他のレコードを取得してＳ１６０２以下の処理に移行する（Ｓ１６１２）。
【００９６】
一方、Ｓ１６０５において、ユーザシステム１００側のパターンＩＤと管理システム２００側のパターンＩＤとが一致しないと判定した場合（Ｓ１６０５、Ｎｏ）、追加資料判定部２３１はさらに、ユーザシステム１００側の障害パターンに対応するパターンＩＤが管理システム２００の既知情報データベース１１００に記録されているか判定する（Ｓ１６０７）。既知情報データベース１１００に記録されていると判定した場合（Ｓ１６０７、Ｙｅｓ）、追加資料判定部２３１は、既知情報データベース１１００に記録されているパターンＩＤ８０５を取得して（Ｓ１６０８）、Ｓ１６０６において当該パターンＩＤによって関連情報データベース１２００を参照する。
【００９７】
Ｓ１６０７において、ユーザシステム１００側の障害パターンに対応するパターンＩＤが管理システム２００の既知情報データベース１１００に記録されていないと判定した場合（Ｓ１６０７、Ｎｏ）、追加資料判定部２３１は、ユーザシステム１００から受信した定義ファイル１０００を、出力装置１５を通じて出力する（Ｓ１６０９）。これは、ユーザシステム１００から受信した定義ファイル１０００から前記のように取得して分析したレコードに記録されている障害パターンが、管理システム２００においては、対応するパターンＩＤが決定されていない未知の障害パターンであると判定されたことを意味するため、当該ユーザシステム１００からの定義ファイル１０００を管理システム２００側のサポートエンジニア等が検討することができるようにするためである。この後、処理はＳ１６１１に移行して、受信した定義ファイル１０００に他のレコードが記録されているか判定する。
【００９８】
このように、本実施形態の追加資料判定処理によれば、ユーザシステム１００側で設定したパターンＩＤと管理システム２００側で保持されているパターンＩＤとが異なる場合に、管理システム２００の既知情報データベース１１００において、他のユーザシステム１００からの障害情報やサポートエンジニアの入力に基づいて更新された最新のパターンＩＤに基づいて、障害の原因調査及び対策検討に必要と考えられる資料をユーザシステム１００側で取得するようにすることができる。
【００９９】
〈テーブル更新処理〉
次に、本実施形態に係る資料収集システムにおいて実行されるテーブル更新処理について説明する。図１７に、テーブル更新処理の処理フローの一例を示している。テーブル更新処理は、ユーザシステム１００にあるテーブル更新部において、管理システム２００に保持されている既知情報データベース１１００及び関連情報データベース１２００の内容を、ユーザシステム１００にある固有情報テーブル８００及び関連情報テーブル９００に反映するために実行される。
【０１００】
まず、ユーザシステム１００の定義ファイル受領部１３６が、管理システム２００から定義ファイル２４３を受信する（Ｓ１７０１）。次いで、テーブル更新部１３７は、受信された定義ファイル２４３を参照して１つのレコードを抽出し、更新フラグ１００９が記録されているか調べる（Ｓ１７０２）。
【０１０１】
受信した定義ファイル１０００の前記レコードに更新フラグ１００９が記録されていると判定した場合（Ｓ１７０３、Ｙｅｓ）、テーブル更新部１３７は、当該レコードに記録されている内容と、自身が属するユーザシステム１００に保持されている固有情報テーブル８００の内容とを比較し（Ｓ１７０４）、両者が一致するか判定する（Ｓ１７０５）。
【０１０２】
一致すると判定した場合（Ｓ１７０５、Ｙｅｓ）、テーブル更新部１３７は、さらに関連情報テーブル９００を参照し、前記受信した定義ファイル１０００から取得したレコードの内容が、関連情報テーブル９００の内容と一致するか判定する（Ｓ１７０６）。一致すると判定した場合（Ｓ１７０６、Ｙｅｓ）、テーブル更新部１３７は、管理システム２００から受信した定義ファイル１０００に他のレコードがあるか判定し（Ｓ１７０９）、他のレコードがあると判定した場合（Ｓ１７０９、Ｙｅｓ）、次のレコードを取得してＳ１７０３の更新フラグ確認へ処理を移行させる（Ｓ１７１０）。
【０１０３】
一方、Ｓ１７０５で管理システム２００から受信した定義ファイル１０００の前記レコードと固有情報テーブル８００の内容とが一致しないと判定した場合（Ｓ１７０５、Ｎｏ）、テーブル更新部１３７は、管理システム２００から受信した定義ファイル１０００のレコードの内容によって固有情報テーブル８００の内容を書き換える更新処理を実行し（Ｓ１７０７）、Ｓ１７０６に処理を移行させる。
【０１０４】
また、Ｓ１７０６で管理システム２００から受信した定義ファイル１０００の前記レコードと関連情報テーブル９００の内容とが一致しないと判定した場合（Ｓ１７０６、Ｎｏ）、テーブル更新部１３７は、管理システム２００から受信した定義ファイル１０００のレコードの内容によって関連情報テーブル９００の内容を書き換える更新処理を実行し（Ｓ１７０８）、Ｓ１７０９に処理を移行させる。
【０１０５】
また、Ｓ１７０３において、管理システム２００から受信した定義ファイル１０００より取得した前記レコードに更新フラグ１００９が記録されていないと判定した場合（Ｓ１７０３、Ｎｏ）、テーブル更新部１３７は、当該レコードに記録されている内容とユーザシステム１００側の固有情報テーブル８００の内容、及び関連情報テーブル９００の内容とが一致しているものとして、処理をＳ１７０９に移行させ、受信した定義ファイル１０００に他のレコードが記録されているか判定する処理を実行する。
【０１０６】
以上説明した本実施形態のテーブル更新処理によれば、管理システム２００に各ユーザシステム１００から通知された障害情報に基づいて、管理システム２００の既知情報データベース１１００及び関連情報データベース１２００に反映された内容、及び管理システム２００のサポートエンジニア等が既知情報データベース１１００及び関連情報データベース１２００に対して加えた変更の内容を、各ユーザシステム１００に保持されている固有情報テーブル８００の内容及び関連情報テーブル９００の内容に反映させ、各ユーザシステム１００において障害が発生した場合に、その障害の原因調査と対策検討とにより有益な資料を常時収集することができるようになる。
【０１０７】
以上、本発明の一実施形態に即して詳細に説明したように、本発明によれば、情報処理装置に障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することが可能となる。
【０１０８】
なお、本明細書では、本発明についてその実施形態に即して添付図面を参照しつつ説明したが、本発明はこのような実施形態によって限定されるものではない。本発明は、特許請求の範囲に記載されている発明の範囲内で、前記の実施形態にかかわらず、種々の形態で実施することができ、当該特許請求の範囲に記載されている発明の均等物も本発明に含まれるものである。
【符号の説明】
【０１０９】
１０  コンピュータ
１１  ＣＰＵ
１２  主記憶装置
１３  補助記憶装置
１４  入力装置
１５  出力装置
１６  通信インタフェース
１００  ユーザシステム
１１０、２１０  ＯＳ
１２０、２２０  データＩ／Ｏ部
１３０  エージェント部
１３１  資料収集部
１３２  障害情報抽出部
１３３  資料ＩＤ決定部
１３４  定義ファイル生成部
１３５  稼働監視部
１３６  定義ファイル受領部
１３７  テーブル更新部
１４０  管理データ格納部
１４１  システムログ
１４２  稼働情報ログ
１４４  関連情報テーブル
１４３  固有情報テーブル
１４５  抽出条件テーブル
１４６、２４３、１０００  定義ファイル
２００  管理システム
２４１  既知情報データベース
２４２  関連情報データベース
２３１  追加資料判定部
２３２  定義ファイル更新部
ＮＷ  通信ネットワーク
【図１】
2011118695.tif 000003
【図２】
2011118695.tif 000004
【図３】
2011118695.tif 000005
【図４】
2011118695.tif 000006
【図５】
2011118695.tif 000007
【図６】
2011118695.tif 000008
【図７】
2011118695.tif 000009
【図８】
2011118695.tif 000010
【図９】
2011118695.tif 000011
【図１０】
2011118695.tif 000012
【図１１】
2011118695.tif 000013
【図１２】
2011118695.tif 000014
【図１３】
2011118695.tif 000015
【図１４】
2011118695.tif 000016
【図１５】
2011118695.tif 000017
【図１６】
2011118695.tif 000018
【図１７】
2011118695.tif 000019