JP2011118695A - 情報処理システム、情報処理装置、及び管理コンピュータ - Google Patents

情報処理システム、情報処理装置、及び管理コンピュータ Download PDF

Info

Publication number
JP2011118695A
JP2011118695A JP2009275823A JP2009275823A JP2011118695A JP 2011118695 A JP2011118695 A JP 2011118695A JP 2009275823 A JP2009275823 A JP 2009275823A JP 2009275823 A JP2009275823 A JP 2009275823A JP 2011118695 A JP2011118695 A JP 2011118695A
Authority
JP
Japan
Prior art keywords
information
failure
recording unit
pattern
management
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
Application number
JP2009275823A
Other languages
English (en)
Inventor
Hisashi Takahashi
尚志 高橋
Noriyasu Kotaki
伯泰 小瀧
Manabu Hirukawa
学 比留川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009275823A priority Critical patent/JP2011118695A/ja
Publication of JP2011118695A publication Critical patent/JP2011118695A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

【課題】コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする。
【解決手段】コンピュータに障害が発生したことを検出すると、障害情報抽出部132が、システムログ141及び稼働情報ログ142から、抽出条件テーブル145を参照して、エラー番号、メッセージID、オブジェクト、及びイベントからなる障害パターンを抽出する。資料ID決定部133は、抽出した障害パターンにより関連情報テーブル144を参照して、前記障害パターンに対応する資料ID902と、それを収集するために実行すべきコマンド903を取得する。資料収集部131は、このコマンド903を実行して、前記障害パターンで特定される障害に対処するのに有益な資料を取得する。前記障害パターンと対応する資料ID及びコマンドを含む定義ファイル146が、管理システム200に送信され、追加収集すべき資料があればユーザシステム100で追加の資料収集が実行される。
【選択図】 図3

Description

本発明は、情報処理システム、情報処理装置、及び管理コンピュータに係わり、特に、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータに関する。
今日、多数のコンピュータが通信ネットワークによって接続されてなる大規模な情報処理システムが構築され運用されている。このような大規模情報処理システムにおいては、プロセッサ、記憶装置、通信機器等のハードウェアに起因する問題、情報処理装置のハードウェア上で稼働しているオペレーティングシステム(Operating System、「OS」)、アプリケーション、各種通信プログラム等のソフトウェアに起因する問題、あるいはユーザ、システム管理者等に係わるヒューマンエラーによる問題など、多種多様な要因によってシステム障害が発生しうる。
このように、一つの障害でも、多数のハードウェア、ソフトウェア、あるいは人的な要因が複合して引き起こされている場合もあるため、障害の原因を突き止めてその障害から情報処理システムを復旧させるためには、多数の資料を収集して解析する必要がある。このような資料には、各コンピュータのOSがシステム上のイベントや状態の変化を記録しているシステムログ(シスログ)、各種構成・設定ファイル、OS上で稼働しているアプリケーションが稼働状態を記録しているアプリケーションログなどが含まれる。
障害の原因を解析するためには、例えばシステム管理者がこのような資料を参照して経験によって障害個所を特定していくといったプロセスが必要であり、解決に時間と労力を要する問題があった。より具体的には、例えば情報処理システムのベンダーに属するサポートエンジニアが、運用側のシステム管理者に障害に関する問診を行い、障害時用の資料収集コマンドなどによる資料収集を指示することで調査が進められていた。
この場合、収集対象の資料を人間の判断で選択すると、本来必要な資料が収集対象から漏れるおそれがある。これを防止すべく、必要と考えられる資料を網羅的に収集した場合には、収集する資料が膨大な量になり、その膨大な資料を時間と労力を費やして人手で解析することとなる。
この問題について特許文献1では、障害原因の調査のために必要となる資料を、障害の事象に応じてあらかじめ構造的に定義しておき、原因調査に有益と考えられる順に、繰り返し資料群を自動収集する方法を提案している。
特開2009−169610号公報
しかしながら、特許文献1が提案する技術によれば、どのような資料を収集するかについては優先順位が付けられているものの、発生した各障害に関しては、あらかじめ決定しておいた資料を取得することになる。前述のとおり、情報処理システムは複雑化しており、発生した障害の内容だけから原因調査に必要な資料を判断することは困難である。また、優先順位にもとづき資料を取得するにあたり、より効率的に資料を取得するためには、発生した障害について障害原因の調査に実質的に有益な資料は何であるかが適時に見直され、収集する資料の優先順位を更新する仕組みが必要とされる。
本発明は上記の及び他の課題を解決するためになされたものであり、その一つの目的は、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータを提供することである。
本発明は上記の及び他の問題に鑑みてなされたもので、その一態様は、コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理システムであって、1又は複数の前記コンピュータと通信可能に接続されている管理コンピュータを備え、前記コンピュータは、自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、前記障害パターンと、それに対応する前記障害対処情報及び前記コマンドとの組み合わせを障害対処情報定義情報として記録するとともに、当該障害対処情報定義情報を前記管理コンピュータに送信する障害対処情報定義情報生成部と備え、前記管理コンピュータは、当該管理コンピュータが通信可能に接続されている前記各コンピュータについての前記障害パターンが互いに識別可能に記録されている管理用障害パターン記録部と、前記各コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している管理用関連情報記録部と、前記コンピュータの前記障害対処情報定義情報生成部から送信された前記障害対処情報定義情報と、前記管理用障害パターン記録部及び前記管理用関連情報記録部とを比較する追加障害対処情報判定部と、前記管理用障害パターン記録部及び前記管理用関連情報記録部に、前記障害対処情報定義情報に記録されていない情報が記録されていると判定した場合に、前記障害対処情報定義情報を前記管理用障害パターン記録部及び前記管理用関連情報記録部に記録されている内容に更新して前記コンピュータに送信する障害対処情報定義情報更新部とを備えている情報処理システムである。
本発明によれば、コンピュータに障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することを可能とする、情報処理システム、情報処理装置、及び管理コンピュータを提供することができる。
本発明の一実施形態による資料収集システム1の全体構成図である。 本発明の一実施形態に係る資料収集システム1に適用されるコンピュータ10の一例を示す構成図である。 本発明の一実施形態に係るユーザシステム100のソフトウェア構成の一例を示す図である。 本発明の一実施形態に係る管理システム200のソフトウェア構成の一例を示す図である。 本発明の一実施形態に係るシステムログ500の一例を示す図である。 本発明の一実施形態に係る稼働情報ログ600の一例を示す図である。 本発明の一実施形態に係る抽出条件テーブル700の一例を示す図である。 本発明の一実施形態に係る固有情報テーブル800の一例を示す図である。 本発明の一実施形態に係る関連情報テーブル900の一例を示す図である。 本発明の一実施形態に係る定義ファイル1000の一例を示す図である。 本発明の一実施形態に係る既知情報データベース1100の一例を示す図である。 本発明の一実施形態に係る関連情報データベース1200の一例を示す図である。 本発明の一実施形態に係る資料収集システム1の全体処理フローの一例を示す図である。 本発明の一実施形態における障害情報抽出処理フローの一例を示す図である。 本発明の一実施形態における資料ID決定処理フローの一例を示す図である。 本発明の一実施形態における追加資料判定処理フローの一例を示す図である。 本発明の一実施形態におけるテーブル更新処理フローの一例を示す図である。
以下本発明の一実施形態に係る資料収集システムについて、添付図面を参照しつつ説明する。
《システム全体構成》
図1は、本発明の一実施形態に係る情報処理システムとしての資料収集システム1の全体構成の一例を示す図である。資料収集システム1は、コンピュータであるユーザシステム100と、管理コンピュータである管理システム200と、ユーザシステム100と管理システム200との間を通信可能に接続している通信ネットワークNWとを備えている。
ユーザシステム100は、コンピュータによって種々の情報処理を実行すべくユーザのサイトに設置された情報処理システムである。図1の例では、ユーザシステムA(100A)及びB(100B)の2つのユーザシステムが設置されているが、設置されるユーザシステム100は1つでも、あるいは3つ以上でもよい。
管理システム200は、ユーザシステム100で収集された障害に関する情報(資料)を取得して、当該ユーザシステム100の保守等を行う要員であるサポートエンジニア等による調査に供する機能を有する情報処理システムである。この管理システム200は、ユーザシステム100を設計、製造、販売したベンダーに属しており、ベンダーがユーザシステム100で発生する種々の障害について、その原因を調査、解析し、ユーザに適切な対処法を迅速に提供するために設けられている。
通信ネットワークNWは、各ユーザシステム100と管理システム200との間を通信可能に接続している通信回線である。この通信ネットワークNWは、LAN(Local Area Network)、WAN(Wide Area Network)、SAN(Storage Area Network)、インターネット、及び専用線等の任意の通信回線を採用して構築することができる。
《ハードウェア構成》
次に、上記のユーザシステム100及び管理システム200のハードウェア構成について説明する。図2に、ユーザシステム100及び管理システム200として使用することができるコンピュータ10のハードウェア構成の一例を示している。
コンピュータ10は、中央処理装置11(例えばCPU(Central Processing Unit)やMPU(Micro Processing Unit)、以下簡単のため「CPU」と称する)、主記憶装置12(例えばRAM(Random Access Memory)やROM(Read Only Memory)等の記憶素子を備えるメモリ)、補助記憶装置13(例えばHDD(Hard Disk Drive))、ユーザの操作入力を受け付ける入力装置14(例えばキーボードやマウス)、出力装置15(例えば液晶モニタ)、他の装置との間の通信を実現する通信インタフェース16(例えばNIC(Network Interface Card)やHBA(Host Bus Adapter))を備えている。
《ソフトウェア構成》
次に、ユーザシステム100及び管理システム200のソフトウェア構成について説明する。
〈ユーザシステム100〉
図3にユーザシステム100のソフトウェア構成の一例を示している。
ユーザシステム100は、OS110と、データI/O部120、資料収集部131(障害対処情報収集部)、障害情報抽出部132、資料ID決定部133(障害対処情報特定部)、定義ファイル生成部134(障害対処情報定義情報生成部)、稼働監視部135、定義ファイル受領部136、及びテーブル更新部137(記録更新部)を有するエージェント部130と、システムログ141(障害情報記録部)、稼働情報ログ142(稼働情報記録部)、固有情報テーブル143(障害パターン記録部)、関連情報テーブル144(関連情報記録部)、抽出条件テーブル145、及び定義ファイル146(障害対処情報定義情報)を有する管理データ格納部140とを備えている。
OS110は、ユーザシステム100で実行される各種アプリケーションのインタフェースとしてユーザシステム100のハードウェア制御等を実行するソフトウェアである。OS110は、特に特定のシステムに限定されることはない。例えばWindows(登録商標)、あるいはUNIX(登録商標)系のオペレーティングシステム、例えばLinux(登録商標)がこのOS110として好適に用いられる。
データI/O部120は、ユーザシステム100と外部機器との間でのデータ入出力機能を備えている。
エージェント部130は、後述する管理システム200のソフトウェアと連携して本実施形態の資料収集システムの各種機能をユーザシステム100側で実現する、以下のプログラム群である。
資料収集部131は、ユーザシステム100でなんらかの障害が発生したことを契機として、後述する定義ファイル146に規定されている内容に従って、障害の発生原因を調査するために必要となる資料を収集する機能を有する。具体的には、資料収集部131は、例えば障害発生時のメモリ格納情報を含むメモリダンプの取得、CPU利用率及びメモリ使用率、あるいはHDD空き容量の取得といった、発生した障害の内容に応じて定められた資料の収集を実行する。
障害情報抽出部132は、後述するシステムログ141及び稼働情報ログ142を参照して、障害発生時のシステムの状況及びユーザシステム100の稼働状況に関する情報を取得する。システムログ141は、前記したOS110が有する機能によって生成され、ユーザシステム100を構成するコンピュータ10の主記憶装置12に逐次格納されている。
資料ID決定部133は、ユーザシステム100において発生した障害の内容に応じて、その障害の原因調査に必要となる取得すべき資料の種類を特定する資料IDを決定する機能を有する。
定義ファイル生成部134は、ユーザシステム100において発生した障害について、その障害の内容に応じてどのような種類の資料を収集するか、及び当該資料収集を実行するためのコマンド等を記録している定義ファイル134を生成する機能を有する。
稼働監視部135は、ユーザシステム100の稼働状況を常時監視し、後述する稼働情報ログ142として記録する機能を有する。
定義ファイル受領部136は、ユーザシステム100になんらかの障害が発生した場合に、後述する条件の下で管理システム200から定義ファイル146を受信する機能を有する。
テーブル更新部137は、一定の条件下で管理システム200からフィードバックされる情報に基づいて、後述の各種テーブルの内容を更新処理する機能を有する。
エージェント部130を構成する以上の各機能部の機能は、例えばユーザシステム100を構成するコンピュータ10の補助記憶装置13から、各機能を提供するプログラムを主記憶装置12に読み出して、CPU11によって実行することにより実現される。各機能部で実行される具体的な処理については、フローチャートを参照して後述する。
次に、管理データ格納部140に格納されている各テーブル、ファイル等について説明する。これらのテーブル等に記録されているデータは、ユーザシステム100が実行する資料収集等の情報処理に際して参照され、利用される。
図5に、システムログ500(141)の一例を示している。システムログ500には、時刻501、エラー番号502、及びメッセージID503が、互いに関連づけられて1レコードとして記録されている。このシステムログ500は、ユーザシステム100に実装されているOS110が有するログ機能によって、OS110になんらかの障害が発生した場合に記録される。
なお、上記でシステムログ141に符号500をあらためて付したのは、ユーザシステム100の一構成要素であるシステムログ141について、それ自体独立した要素として特定する際の便宜のためである。これは、以下説明する他のテーブル、ファイル等についても同様である。
時刻501は、当該システムログ500のレコードが記録されたときに、そのレコードの一部としてレコード記録時の時刻が、ユーザシステム100が有するシステムクロックから取得して記録される。エラー番号502は、OS110が検出した障害の内容に応じて付与される識別符号であり、どのような障害についてどのような識別符号を付与するかは、OS110の仕様に依存する。メッセージID503には、OS110が検出した障害の内容に応じて付与される、障害の内容を表す短いメッセージと、それに付随する固有の識別符号が記録される。図5の例では、システムログ500の最初のレコードとして、2009年4月20日12時34分00秒に、エラー番号502が「222」、メッセージID503が「000」で特定される障害(警告)が発生したことが記録されている。
次に、稼働情報ログ600(142)について説明する。図6に、稼働情報ログ600の一例を示している。稼働情報ログ600には、時刻601、オブジェクト602、及びイベント603が、互いに関連づけられて1レコードとして記録されている。稼働情報ログ600は、ユーザシステム100のエージェント部130にある稼働監視部135によって、ユーザシステム100で動作しているアプリケーション等のソフトウェアの動作状況等に関し、所定のイベントが発生した場合に記録される。
時刻601は、稼働情報ログ600のレコードが記録されたときに、そのレコードの一部としてレコード記録時の時刻が、ユーザシステム100が有するシステムクロックから取得して記録される。オブジェクト602は、稼働監視部135が監視対象とした特定のソフトウェア、サービス、ユーザ等の情報を記録する。イベント603には、監視対象であるオブジェクト602に対して実行された操作など(ソフトウェアのインストール・アンインストール、サービスの起動・停止、ユーザのログイン・ログアウト等)のイベントの内容が記録される。
図6の例では、稼働情報ログ600の3番目のレコードとして、2009年4月30日23時50分00秒に、ユーザシステム100においてサービスAが起動されたことが記録されている。なお、稼働情報ログ600のレコードとしてどのような項目を監視するかは、稼働監視部135の仕様として適宜決定することができる。
次に、抽出条件テーブル700(145)について説明する。図7に、抽出条件テーブル700の一例を示している。抽出条件テーブル700は、エージェント部130にある障害情報抽出部132が、ユーザシステム100で発生した障害に関する情報に関し、どのような情報について、どの程度の時間スパンにおいていくつのサンプルを取得するかを規定している。抽出条件テーブル700は、エラー番号701、メッセージID702、時間閾値の下限値703、時間閾値の上限値704、及びサンプル個数に相当するサンプリングの回数についての回数閾値705を、互いに関連づけて1レコードとして記録している。
エラー番号701及びメッセージID702は、図5のシステムログ500におけるエラー番号502及びメッセージID503と同様である。時間閾値の下限値703は、障害情報抽出部132がシステムログ500から障害情報を抽出する場合に、障害発生時点からどれくらいの時間だけさかのぼって障害情報の抽出を実行するかを規定している閾値である。時間閾値の上限値704は、逆に、障害発生時点から後のどれくらいの時間にわたって(未来に向かって)障害情報を抽出するかを規定している閾値である。回数閾値705は、特定のエラー番号701とメッセージID702とで指定される障害について、障害情報抽出部132が、いくつまでのサンプルを抽出するかを規定している閾値である。
例えば図7の最初のレコードの例では、エラー番号701が「111」、メッセージID702が「222」で特定される障害情報については、システムログ500から、まず障害発生時刻から3600秒(1時間)前までさかのぼって障害情報を抽出し、次いで障害発生後10秒まで下って障害情報を抽出する。その際、抽出した障害情報の数が回数閾値705に記録されている回数に達したら、障害情報抽出部132は抽出処理を終了することとなる。
なお、抽出条件テーブル700は、ユーザシステム100の運用を開始する前に、例えば本資料収集システム1を提供しているベンダー等が、あらかじめ設定した抽出条件のレコードを格納して、例えば補助記憶装置13(図2)に記憶させておくものとする。
次に、固有情報テーブル800(143)について説明する。図8に、本実施形態における固有情報テーブル800の一例を示している。固有情報テーブル800には、エラー番号801、メッセージID802、オブジェクト803、及びイベント804に、パターンID805が関連づけられて、1つのレコードとして記録されている。
エラー番号801及びメッセージID802は、図5のシステムログ500におけるエラー番号502及びメッセージID503と同様である。また、オブジェクト803及びイベント804は、図6の稼働情報ログ600におけるオブジェクト602及びイベント603と同様である。
パターンID805は、前記のように、エラー番号801、メッセージID802、オブジェクト803、及びイベント804の組み合わせに対して、これらの組み合わせを互いに識別するために付与されている固有の識別符号である。すなわち、パターンID805は、システムログ500に記録されているエラーの内容(エラー番号801及びメッセージID802)と、稼働情報ログ600に記録されている障害(エラー)発生時近傍でのユーザシステム100の稼働状況、操作状況(オブジェクト803及びイベント804)との組み合わせを、ユーザシステム100において発生する障害のパターンと位置づけ、それらの障害パターン毎に固有の識別符号であるパターンID805を付して識別するようにしている。
なお、図8の例では、パターンID805として、0以上の整数を各障害パターンに順次割り当てているが、他の識別可能な符号を適宜採用してよい。パターンID805を含む固有情報テーブル800は、ユーザシステム100の運用を開始する前に、あらかじめ既知の障害パターンとその固有のパターンID805とを組み合わせて、例えば補助記憶装置13(図2)に記憶させておくものとする。詳しくは後述するが、ユーザシステム100の運用中に、エージェント部130にある資料ID決定部133が、パターンID805が付されていない未知の障害パターンを検出した場合には、パターンID805に「該当なし(例えば「null」)」を記録する。
また、固有情報テーブル800は、ユーザシステム100の運用を開始する前に、例えば本資料収集システム1を提供しているベンダー等が、あらかじめ設定した障害パターンとパターンID805との既知の組み合わせをレコードとして格納して、例えば補助記憶装置13(図2)に記憶させておくものとする。
次に、関連情報テーブル900(144)について説明する。図9に、本実施形態における関連情報テーブル900の一例を示している。関連情報テーブル900には、パターンID901、資料ID902、及びコマンド903が、互いに関連づけられて1レコードとして記録されている。
パターンID901は、図8に関して前記のように、ユーザシステム100において発生する障害パターンを特定するための識別符号である。資料ID902は、特定のパターンID901により識別される障害パターンが検出された場合に、ユーザシステム100においてエージェント部130にある資料採取部131が収集すべき資料を識別するための識別符号である。ここでは資料ID902として、資料毎に固有の数字を付与している。図9に示すように、あるパターンID901で特定される障害パターンについて収集すべき資料は一つとは限らないため、1つのパターンID901に対して2以上の資料ID902が関連づけられることがある。
コマンド903は、資料ID902で特定される資料の収集を実行するために、OS110等に与えられるコマンドが記録される。例えば資料ID902によって特定される資料が障害発生時のメモリダンプであった場合には、対応するコマンド903に、OS110に対してメモリダンプを作成させる旨のコマンドを示す識別符号が記録される。
なお、関連情報テーブル900は、ユーザシステム100の運用を開始する前に、例えば本資料収集システム1を提供しているベンダー等が、あらかじめ設定したパターンID901と、資料ID902及びコマンド903との既知の組み合わせをレコードとして格納して、例えば補助記憶装置13(図2)に記憶させておくものとする。
次に、定義ファイル1000(146)について説明する。図10に、本実施形態における定義ファイル1000の一例を示している。定義ファイル1000には、エラー番号1001、メッセージID1002、オブジェクト1003、イベント1004、パターンID1005、資料ID1006、コマンド1007、及び更新フラグ1008が、互いに関連づけられて1レコードとして記録されている。
この定義ファイル1000は、ユーザシステム100においてある障害が発生した場合に、その障害に関して障害情報抽出部132が抽出した障害情報のパターンについて、エラー番号1001、メッセージID1002、オブジェクト1003、及びイベント1004に基づいてパターンID1005とそれに関連づけられた資料ID1006及びコマンド1007を特定し、対応するコマンド1007を実行すべく、エージェント部130の定義ファイル生成部134によって生成され、資料収集部131等により参照される。
なお、定義ファイル1000は、ユーザシステム100の運用を開始する前に、あらかじめ既知の障害パターンと、その固有のパターンID805、資料ID1006、及びコマンド1007の組み合わせをレコードとして格納して、例えば補助記憶装置13(図2)に記憶させておくものとする。
エラー番号1001、メッセージID1002、オブジェクト1003、イベント1004、及びパターンID1005は、図8の固有情報テーブル800に記録されている、エラー番号801、メッセージID802、オブジェクト803、イベント804、及びパターンID805と同様である。また、資料ID1006及びコマンド1007は、図9の関連情報テーブル900に記録されている資料ID902及びコマンド903と同様である。
更新フラグ1008は、ユーザシステム100のテーブル更新部137が、管理システム200から受信した定義ファイル1000の内容に基づいて自身の固有情報テーブル800及び関連情報テーブル900の内容を更新するか判定するために参照するフラグであり、更新する場合は「1」が、更新しない場合には「0」が記録される。
〈管理システム200〉
次に、管理システム200のソフトウェア構成について説明する。図4に、本実施形態における管理システム200のソフトウェア構成の一例を示している。管理システム200は、OS210、データI/O部220、追加資料判定部231(追加障害対処情報判定部)、定義ファイル更新部232(障害対処情報定義情報更新部)、既知情報データベース241(管理用障害パターン記録部)、関連情報データベース242(管理用関連情報記録部)、及び定義ファイル243を備えている。
OS210及びデータI/O部220は、図3のユーザシステム100におけるOS110及びデータI/O部120と同等の機能を有するものであり、ここでは説明を省略する。
追加資料判定部231は、ユーザシステム100において定義ファイル生成部134が生成した定義ファイル146(1000)に対して、自身が保持している、後述の定義ファイル243の内容と比較し、ユーザシステム100で生成された定義ファイル146に含まれていない資料があると判定した場合に、その資料を追加する機能を有する。
定義ファイル更新部232は、追加資料判定部231において追加資料が必要であると判断された場合に、後述する定義ファイル243の更新を行う機能を有する。
管理システム200が有する以上の各機能部の機能は、例えば管理システム200を構成するコンピュータ10の補助記憶装置13から、各機能を提供するプログラムを主記憶装置12に読み出して、CPU11によって実行することにより実現される。各機能部で実行される具体的な処理については、フローチャートを参照して後述する。
次に、管理システム200に保持されている各テーブル、ファイル等について説明する。これらのテーブル等に記録されているデータは、管理システム200が実行する情報処理に際して参照され、利用される。
図11に、本実施形態における既知情報データベース1100の一例を示している。この既知情報データベース1100が保持している情報の項目は、ユーザシステム100にある固有情報テーブル800と同様である。しかし、この既知情報データベース1100に記録されている内容(レコード)は、管理システム200に接続されている各ユーザシステム100から受信される定義ファイル1000の内容を反映すること、及びサポートエンジニア(資料収集システムのベンダー側にいる管理者)が管理システム200の入力装置14(操作入力部)を介してその内容を更新することを通じて、同一の障害パターンであってもパターンID1105の項目がユーザシステム100側の固有情報テーブル800に記録されているパターンID805とは異なる場合があるという差異がある(例えば図11のパターンID1105におけるセル斜線部)。
図12に、本実施形態における関連情報データベース1200の一例を示している。この関連情報データベース242が保持している情報の項目は、ユーザシステム100にある関連情報テーブル900と同様である。しかし、この関連情報データベース1200にも、前記の既知情報データベース1100の場合と同様の理由で、資料ID1202及びコマンド1203の項目はユーザシステム100側の関連情報テーブル900とは異なる場合があるという差異がある。
定義ファイル243は、ユーザシステム100に保持されている定義ファイル1000と同様であるが、管理システム200には、管理システム200が通信ネットワークNWを通じて管理している各ユーザシステム100に対応する定義ファイル243が保持されている。これらの定義ファイル243は、対応するユーザシステム100に送信され、対応する定義ファイル146(1000)を更新する処理に使用される。
《本実施形態における処理フローの説明》
次に、本実施形態に係る資料収集システム1によって実行される処理フローについて、図面を参照しつつ順次説明する。なお、各処理フローにおいて使用されている符号Sは、「ステップ」を表している。
〈システム全体の処理フロー〉
図13に、本実施形態に係る資料収集システム1によって実行される処理フロー全体について示している。この処理フローは、資料収集システム1において管理システム200によって管理されている対象のコンピュータのいずれか、すなわちいずれかのユーザシステム100においてなんらかの障害が発生した場合に実行される処理フローである。図13は、管理対象のユーザシステム100における障害発生から、管理システム200側でサポートエンジニア等の要員が障害の調査及び原因究明に必要な資料を入手するまでの処理の流れを表している。
まずユーザシステム100で障害が発生したことをOS110から通知された場合に、障害情報抽出部131は、OS110が記録しているシステムログ141の情報をもとに、稼働監視部135が記録している稼働情報ログ142のレコードの中から、所定の条件に合致する稼働情報を抽出する(S1301)。この障害情報抽出処理については別に後述する。
次いで、資料ID決定部133は、固有情報テーブル143を参照し、システムログ141に記録されているエラー番号502及びメッセージID503、及び障害情報抽出部131が抽出した、障害に関連する可能性のある稼働情報に対応する資料IDを取得する(S1302)。この資料ID決定処理についても、別に後述する。
定義ファイル生成部134は、資料ID決定部133から取得した資料IDを入力として、関連情報テーブル144から、現在発生している障害と管理対象であるユーザシステム100の稼働情報に応じた、障害調査に必要な資料を定義する定義ファイル146を生成する(S1303)。
資料収集部131は、この定義ファイル146の内容に基づき、管理対象のユーザシステム100について資料収集を行う(S1304)。
障害が発生したユーザシステム100での資料収集が完了したら、資料収集部131は、自身が収集した資料(障害発生時のメモリダンプ等)、障害発生時のシステムログ141、及びシステムログ141に関連して取得された稼働情報ログ142と、システムログ141、稼働情報ログ142等に基づいて生成された定義ファイル146を、通信ネットワークNWを通じて管理システム200に送信する(S1305)。
前記定義ファイル146を受信した管理システム200では、追加資料判定部231が、受信した定義ファイル146を自身が保持している定義ファイル243の記録と比較して(S1307)、該当する障害パターンについて追加で収集すべき資料があるか判定する(S1308)。
追加資料判定部231が追加で収集すべき資料があると判定した場合(S1308、Yes)、定義ファイル更新部232が、管理システム200に保持されている定義ファイル243に追加で収集すべき資料を追加する更新を行う(S1309)。このように、管理システム200側で、あるユーザシステム100から受信した資料(システムログ、稼働情報ログ、及び定義ファイル)に含まれていない資料IDで特定される資料が含まれることがあるのは、例えば、管理システム200に接続されている他のユーザシステム100から受信した資料に基づいて自身の定義ファイル243が更新されることがある、及びいずれかのユーザシステム100から受信した資料に基づいて、管理システム200側の要員が、通知された障害について収集すべき資料を経験等により見直し、管理システム200の既知情報データベース241、関連情報データベース242、及び定義ファイル243を更新しておく、といった処理を行うことがあるためである。
追加資料判定部231が追加で収集すべき資料がないと判定した場合(S1308、No)、管理システム200は、データI/O部220、及びディスプレイ装置、プリンタ等の出力装置15を通じて、ユーザシステム100から受信した資料を出力する(S1310)。管理システム200側の要員は、出力された資料を参照して、ユーザシステム100における障害発生の原因、及び対策を検討して、ユーザシステム100のシステム管理者へ報告することとなる。具体的には、ユーザシステム100で取得した資料により障害の要因が特定できたら、管理システム200側の要員は、電話や電子メールなど適当な方法により障害が発生したユーザシステム100のシステム管理者に回答することとなる。
なお、あるユーザシステム100から受信した定義ファイル1000に、過去に同様の障害が発生したことにより対応付けられているパターンID1005及び資料ID1006が存在せず(パターンID1005及び資料ID1006に、いずれも「null」が記録)、自身が保持する既知情報データベース241から収集すべき資料を決定することができない場合は、管理システム200の要員がシステムログ141、稼働情報ログ142を参照して障害調査に必要と判断した資料を管理コンソール(図示略、例えば管理システム200を構成するコンピュータ10の入力装置14を使用してもよい。)から入力する。この入力された内容に従って、定義ファイル更新部232が、管理システム200に保持されている定義ファイル243を更新する。それと併せて、定義ファイル更新部232は、既知情報データベース241に、ユーザシステム100から受信した、追加で収集する資料及びユーザシステム100の稼働情報を登録することによって、既知情報データベース231を更新する。
障害が発生したユーザシステム100は、定義ファイル受領部136において管理システム200から定義ファイル243を受信し、受信した定義ファイル243が更新された定義ファイル243であるか判定する(S1311)。更新された定義ファイル243であると判定した場合(S1311、Yes)、処理はS1304に移行し、更新された定義ファイル243によって、再度資料の収集が実行される。定義ファイル受領部136が更新定義ファイル243を受信していないと判定した場合(S1311、No)、ユーザシステム100において処理が終了する。
以上のように、本実施形態に係る資料収集システム1の全体処理フローによれば、なんらかの障害が発生したことが検知された場合に、ユーザシステム100に定義ファイル1000(146)の形態で保持されている、障害のパターンと収集すべき資料との対応付けに基づいて、その障害の原因調査、対策の立案に資すると考えられる資料が自動的に収集され、管理システム200に送信される。したがって、管理システム200側のサポートエンジニア等の要員は、受信した資料に基づいて迅速に障害に対応することが可能となる。
また、他のユーザシステム100で発生した障害に関して収集されるべきと判定された資料や、管理システム200側でサポートエンジニア等の要員がマニュアルで追加、修正等した定義ファイル243の内容が自動的にユーザシステム100の定義ファイル146に反映され、追加の資料収集を実行させることができるので、ユーザシステム100のシステム管理者が個別に定義ファイル146をメインテナンスしなくてすむようになる。
〈障害情報抽出処理〉
次に、本実施形態に係る資料収集システムにおける障害情報抽出処理について説明する。図14に、当該障害情報抽出処理の処理フローの一例を示している。この障害情報抽出処理では、ユーザシステム100のエージェント部130にある障害情報抽出部131によって実行される処理であり、システムログ500、稼働情報ログ600から、発生した障害に関連する情報を抽出する。
障害情報抽出部132は、ユーザシステム100のシステム管理者の判断、ユーザシステム100のエージェント部130にある稼働監視部135等の各種モニタプログラムが障害発生を検知したことを契機として処理を開始する。
まず、障害情報抽出部132は、ユーザシステム100に保持されているシステムログ500を参照し、障害検知時刻の直近に記録されている、エラー発生時刻501、エラー番号502、及びメッセージID503を取得する(S1401)。
次に、障害情報抽出部132は、ユーザシステム100に保持されている稼働情報ログ600を参照し、抽出条件テーブル145において、前記システムログ500から取得されたエラー番号501に対応して抽出条件テーブル145に設定されている時間閾値条件及びサンプル回数閾値条件に従って、それらの条件を満たす稼働情報として、オブジェクト601及びイベント602を抽出する(S1402)。
次いで、障害情報抽出部132は、稼働情報ログ600に、前記抽出条件テーブル145に設定されている条件を満たす他のレコードが記録されているか判定する(S1403)。他のレコードが記録されていると判定した場合(S1403、Yes)、障害情報抽出部132は、該当する他のすべてのレコードを取得するまでS1402〜S1404の処理を反復して実行する。
稼働情報ログ600に他のレコードが存在しないと判定した場合(S1403、No)、障害情報抽出部132は、システムログ500に他のレコードが記録されているか判定し(S1405)、記録されていると判定した場合(S1405、Yes)、システムログ500から次のレコードを取得し、S1401の処理へ移行する。システムログ500に他のレコードが記録されていないと判定した場合(S1405、No)、障害情報抽出部132は、発生した障害に関するすべてのシステムログ500及び稼働情報ログ600についての情報が取得されたので、障害情報抽出処理を終了する。
この障害情報抽出処理によれば、ユーザシステム100で発生した障害に関する障害情報を自動的に抽出することができ、それに基づいて必要な資料の収集をさらに実行することができる。
〈資料ID決定処理〉
次に、本実施形態に係る資料収集システムにおいて実行される資料ID決定処理について説明する。図15に、この資料ID決定処理の処理フローの一例を示している。この資料ID決定処理では、障害情報抽出部132が抽出した、システムログ500のエラー番号502及びメッセージID503と、それらシステムログ500から抽出された情報に関して稼働情報ログ600から抽出されたオブジェクト602及びイベント603に基づいて、当該障害の原因調査等に有益な資料を具体的に特定する。
まず、資料ID決定部133は、ユーザシステム100に保持されている固有情報テーブル800を参照し、障害情報抽出部132が抽出した、システムログ500のエラー番号502及びメッセージID503と、稼働情報ログ600のオブジェクト602及びイベント603の組み合わせに一致するパターンID805が記録されているか判定する(S1502)。
一致するパターンID805が記録されていると判定した場合(S1502、Yes)、資料ID決定部133は、関連情報テーブル900を参照し、パターンID901に関連付けられた資料ID902が記録されているか判定する(S1503、S1504)。関連する資料ID902が存在すると判定した場合(S1505、Yes)、当該資料ID902とそれに関連づけられているコマンド903を取得する(S1507)。
資料ID決定部133が、固有情報テーブル800内に入力されたシステムログ500のエラー番号502及びメッセージID503と、稼働情報ログ600のオブジェクト602及びイベント603との組み合わせに対応するパターンID805が記録されていないと判定した場合(S1502、No)、資料ID決定部133は、当該組み合わせに対してパターンID805に「null(値なし)」を記録する(S1504)。
S1505で、関連情報テーブル900において、パターンID901に関連づけられている資料ID902が記録されていないと判定した場合(S1505、No)、資料ID決定部133は、障害情報抽出部132によって抽出された次の障害情報があるか判定し(S1506)、次の障害情報があると判定した場合(S1506、Yes)、処理をS1501に移行させて、再度固有情報テーブル800を参照する処理以降を繰り返す。
次の障害情報がないと判定した場合(S1506、No)、資料ID決定部133は、処理を終了する。
以上の資料ID決定処理によれば、障害情報抽出部132によって抽出された障害情報に基づいて、当該障害の原因調査等に有益な資料と、その資料の収集を実行するためのコマンドとを自動的に特定することができる。
以上の障害情報抽出処理及び資料ID決定処理について、図5のシステムログ500、図6の稼働情報ログ600、図7の抽出条件テーブル700、図8の固有情報テーブル800、及び図9の関連情報テーブル900の例に則して具体的な処理例を説明する。
まず、障害情報抽出部132がユーザシステム100のシステムログ141と稼働情報ログ142とを参照し,抽出条件テーブル700から,条件に合致する稼働情報を抽出する。障害情報「エラー番号111,メッセージ777」については,抽出条件テーブル700より障害発生の3600秒(1時間)前から10秒後までの間に記録されている3個までの稼働情報が対象となるため,稼働情報「2009/05/01 00:30:00の設定Bの変更」,「2009/05/01 00:10:00のパッチFの適用」、及び「2009/04/30 23:50:00のサービスAの起動」を抽出する。
同様に、障害情報「エラー番号333,メッセージ888」についても,抽出条件テーブル700に規定されている条件(障害発生100秒前から10秒後までの間の1個)に従い,稼働情報「2009/05/01 00:00:30の設定Bの変更」を抽出する。
次に、資料ID決定部133が固有情報テーブル800を参照することにより,上記障害情報抽出部132が抽出したシステムログ500の「エラー番号502」及び「メッセージID503」と、稼働情報ログ600の「オブジェクト602」及び「イベント603」の組み合わせから、パターンID805を決定する。障害情報「エラー番号111,メッセージ777」と稼働情報「2009/05/01 00:30:00の設定Bの変更」については「パターンID805が「5」、障害情報「エラー番号111,メッセージ777」と稼働情報「2009/05/01 00:10:00のProduct AのパッチF適用」については,パターンID805が「9」を得る。
他方、障害情報「エラー番号111,メッセージ777」と稼働情報「2009/04/31 23:50:00のサービスAの起動」、及び障害情報「エラー番号333,メッセージ888」と稼働情報「2009/04/31 23:50:00のサービスAの起動」の組み合わせについては,ユーザシステム100では関連する資料IDを一意に決定できないため,パターンID805として「null」を得て,障害情報と稼働情報の組み合わせのみを保持する。
次に,定義ファイル生成部134が,関連情報テーブル900を参照してこれまでに得たパターンID「5」、及びパターンID「9」に対応する資料ID902とそれによって特定される資料を収集するために実行すべき具体的なコマンド903とを一意に決定する。図9の関連情報テーブル900の例では、パターンID「5」に関連して資料ID「5」及び「51」とコマンド「B」及び「C」を,パターンID「9」に関連して資料ID「9」及びコマンド「A」を得る。
〈追加資料判定処理〉
次に、管理システム200の追加資料判定部231によって実行される追加資料判定処理について説明する。図16に、追加資料判定処理の処理フローの一例を示している。この追加資料判定処理は、ユーザシステム100で発生した障害に関して、ユーザシステム100において収集対象として決定された資料に対して、管理システム200側でそれに追加して収集すべき資料があるかを判定する処理である。
まず、追加資料判定部231は、ユーザシステム100で収集された資料、システムログ500、稼働情報ログ600、及び定義ファイル1000を受信する(S1601)。
次いで、追加資料判定部231は、ユーザシステム100から受信した定義ファイル1000を参照し、エラー番号502及びメッセージID503を取得する(S1602)。
次に、追加資料判定部231は、同じくユーザシステム100から受信した定義ファイル1000を参照し、前記取得したエラー番号502及びメッセージID503に対応する稼働情報として、オブジェクト601及びイベント602を取得する(S1603)。
次いで、追加資料判定部231は、管理システム200に保持されている既知情報データベース241を参照して、ユーザシステム100側の定義ファイル1000から取得したエラー番号502、メッセージID503、オブジェクト601、及びイベント602に従って、既知情報データベース1100に記録されているパターンIDを取得し、前記ユーザシステム100から受信した定義ファイル1000に記録されているパターンID805と比較する(S1604)。
追加資料判定部231は、ユーザシステム100から受信した定義ファイル1000に記録されていたパターンIDと管理システム200に保持されている既知情報データベース1100に記録されていたパターンIDとが一致するか判定する(S1605)。一致すると判定した場合(S1605、Yes)、追加資料判定部231は、管理システム200に保持されている関連情報データベース1200を参照し、前記取得したパターンIDに対応付けられている資料IDを取得する(S1606)。そして、ユーザシステム100から受信した定義ファイル1000に記録されている資料IDと異なる資料IDを、既知情報データベース1100に反映させるために、主記憶装置12等に格納する(S1610)。
次いで追加資料判定部231は、ユーザシステム100から受信した定義ファイル1000に他のレコードが記録されているか判定し(S1611)、記録されていると判定した場合(S1611、Yes)、当該他のレコードを取得してS1602以下の処理に移行する(S1612)。
一方、S1605において、ユーザシステム100側のパターンIDと管理システム200側のパターンIDとが一致しないと判定した場合(S1605、No)、追加資料判定部231はさらに、ユーザシステム100側の障害パターンに対応するパターンIDが管理システム200の既知情報データベース1100に記録されているか判定する(S1607)。既知情報データベース1100に記録されていると判定した場合(S1607、Yes)、追加資料判定部231は、既知情報データベース1100に記録されているパターンID805を取得して(S1608)、S1606において当該パターンIDによって関連情報データベース1200を参照する。
S1607において、ユーザシステム100側の障害パターンに対応するパターンIDが管理システム200の既知情報データベース1100に記録されていないと判定した場合(S1607、No)、追加資料判定部231は、ユーザシステム100から受信した定義ファイル1000を、出力装置15を通じて出力する(S1609)。これは、ユーザシステム100から受信した定義ファイル1000から前記のように取得して分析したレコードに記録されている障害パターンが、管理システム200においては、対応するパターンIDが決定されていない未知の障害パターンであると判定されたことを意味するため、当該ユーザシステム100からの定義ファイル1000を管理システム200側のサポートエンジニア等が検討することができるようにするためである。この後、処理はS1611に移行して、受信した定義ファイル1000に他のレコードが記録されているか判定する。
このように、本実施形態の追加資料判定処理によれば、ユーザシステム100側で設定したパターンIDと管理システム200側で保持されているパターンIDとが異なる場合に、管理システム200の既知情報データベース1100において、他のユーザシステム100からの障害情報やサポートエンジニアの入力に基づいて更新された最新のパターンIDに基づいて、障害の原因調査及び対策検討に必要と考えられる資料をユーザシステム100側で取得するようにすることができる。
〈テーブル更新処理〉
次に、本実施形態に係る資料収集システムにおいて実行されるテーブル更新処理について説明する。図17に、テーブル更新処理の処理フローの一例を示している。テーブル更新処理は、ユーザシステム100にあるテーブル更新部において、管理システム200に保持されている既知情報データベース1100及び関連情報データベース1200の内容を、ユーザシステム100にある固有情報テーブル800及び関連情報テーブル900に反映するために実行される。
まず、ユーザシステム100の定義ファイル受領部136が、管理システム200から定義ファイル243を受信する(S1701)。次いで、テーブル更新部137は、受信された定義ファイル243を参照して1つのレコードを抽出し、更新フラグ1009が記録されているか調べる(S1702)。
受信した定義ファイル1000の前記レコードに更新フラグ1009が記録されていると判定した場合(S1703、Yes)、テーブル更新部137は、当該レコードに記録されている内容と、自身が属するユーザシステム100に保持されている固有情報テーブル800の内容とを比較し(S1704)、両者が一致するか判定する(S1705)。
一致すると判定した場合(S1705、Yes)、テーブル更新部137は、さらに関連情報テーブル900を参照し、前記受信した定義ファイル1000から取得したレコードの内容が、関連情報テーブル900の内容と一致するか判定する(S1706)。一致すると判定した場合(S1706、Yes)、テーブル更新部137は、管理システム200から受信した定義ファイル1000に他のレコードがあるか判定し(S1709)、他のレコードがあると判定した場合(S1709、Yes)、次のレコードを取得してS1703の更新フラグ確認へ処理を移行させる(S1710)。
一方、S1705で管理システム200から受信した定義ファイル1000の前記レコードと固有情報テーブル800の内容とが一致しないと判定した場合(S1705、No)、テーブル更新部137は、管理システム200から受信した定義ファイル1000のレコードの内容によって固有情報テーブル800の内容を書き換える更新処理を実行し(S1707)、S1706に処理を移行させる。
また、S1706で管理システム200から受信した定義ファイル1000の前記レコードと関連情報テーブル900の内容とが一致しないと判定した場合(S1706、No)、テーブル更新部137は、管理システム200から受信した定義ファイル1000のレコードの内容によって関連情報テーブル900の内容を書き換える更新処理を実行し(S1708)、S1709に処理を移行させる。
また、S1703において、管理システム200から受信した定義ファイル1000より取得した前記レコードに更新フラグ1009が記録されていないと判定した場合(S1703、No)、テーブル更新部137は、当該レコードに記録されている内容とユーザシステム100側の固有情報テーブル800の内容、及び関連情報テーブル900の内容とが一致しているものとして、処理をS1709に移行させ、受信した定義ファイル1000に他のレコードが記録されているか判定する処理を実行する。
以上説明した本実施形態のテーブル更新処理によれば、管理システム200に各ユーザシステム100から通知された障害情報に基づいて、管理システム200の既知情報データベース1100及び関連情報データベース1200に反映された内容、及び管理システム200のサポートエンジニア等が既知情報データベース1100及び関連情報データベース1200に対して加えた変更の内容を、各ユーザシステム100に保持されている固有情報テーブル800の内容及び関連情報テーブル900の内容に反映させ、各ユーザシステム100において障害が発生した場合に、その障害の原因調査と対策検討とにより有益な資料を常時収集することができるようになる。
以上、本発明の一実施形態に即して詳細に説明したように、本発明によれば、情報処理装置に障害が発生した場合に、当該障害の内容に応じて、原因解析に資する適切な資料を収集することが可能となる。
なお、本明細書では、本発明についてその実施形態に即して添付図面を参照しつつ説明したが、本発明はこのような実施形態によって限定されるものではない。本発明は、特許請求の範囲に記載されている発明の範囲内で、前記の実施形態にかかわらず、種々の形態で実施することができ、当該特許請求の範囲に記載されている発明の均等物も本発明に含まれるものである。
10 コンピュータ
11 CPU
12 主記憶装置
13 補助記憶装置
14 入力装置
15 出力装置
16 通信インタフェース
100 ユーザシステム
110、210 OS
120、220 データI/O部
130 エージェント部
131 資料収集部
132 障害情報抽出部
133 資料ID決定部
134 定義ファイル生成部
135 稼働監視部
136 定義ファイル受領部
137 テーブル更新部
140 管理データ格納部
141 システムログ
142 稼働情報ログ
144 関連情報テーブル
143 固有情報テーブル
145 抽出条件テーブル
146、243、1000 定義ファイル
200 管理システム
241 既知情報データベース
242 関連情報データベース
231 追加資料判定部
232 定義ファイル更新部
NW 通信ネットワーク

Claims (5)

  1. コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理システムであって、1又は複数の前記コンピュータと通信可能に接続されている管理コンピュータを備え、
    前記コンピュータは、自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、
    当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、
    前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、
    前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、
    前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、
    抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、
    前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、
    前記障害パターンと、それに対応する前記障害対処情報及び前記コマンドとの組み合わせを障害対処情報定義情報として記録するとともに、当該障害対処情報定義情報を前記管理コンピュータに送信する障害対処情報定義情報生成部と、
    を備え、
    前記管理コンピュータは、当該管理コンピュータが通信可能に接続されている前記各コンピュータについての前記障害パターンが互いに識別可能に記録されている管理用障害パターン記録部と、
    前記各コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している管理用関連情報記録部と、
    前記コンピュータの前記障害対処情報定義情報生成部から送信された前記障害対処情報定義情報と、前記管理用障害パターン記録部及び前記管理用関連情報記録部とを比較する追加障害対処情報判定部と、
    前記管理用障害パターン記録部及び前記管理用関連情報記録部に、前記障害対処情報定義情報に記録されていない情報が記録されていると判定した場合に、前記障害対処情報定義情報を前記管理用障害パターン記録部及び前記管理用関連情報記録部に記録されている内容に更新して前記コンピュータに送信する障害対処情報定義情報更新部と、
    を備えている情報処理システム。
  2. 請求項1に記載の情報処理システムであって、
    前記コンピュータは、前記管理コンピュータから受信した前記障害対処情報定義情報を、前記障害パターン記録部及び前記関連情報記録部に記録されている内容と比較し、いずれかに記録されている内容が、受信した前記障害対処情報定義情報に記録されている内容と相違すると判定した場合に、当該障害対処情報定義情報によって、前記障害パターン記録部又は前記関連情報記録部を更新する記録更新部を備えている、情報処理システム。
  3. 請求項1に記載の情報処理システムであって、
    前記管理コンピュータは、前記各コンピュータから受信する前記障害対処情報定義情報に基づいて、前記管理用障害パターン記録部及び前記管理用関連情報記録部の内容を変更するために外部からの操作入力を受け付ける操作入力部を備えている情報処理システム。
  4. 請求項1に記載の管理コンピュータであって、自身が保持している前記管理用障害パターン記録部及び前記管理用関連情報記録部の内容によって更新した前記障害対処情報定義情報を、前記各コンピュータに保持されている前記障害パターン記録部及び前記関連情報記録部の内容を更新すべく、適時に前記各コンピュータに送信する管理コンピュータ。
  5. コンピュータに発生する障害に対処するための障害対処情報を収集する情報処理装置であって、
    自身に発生する障害に関する情報である障害情報を記録する障害情報記録部と、
    当該コンピュータにおけるハードウェア及びソフトウェアの稼働状況を記録する稼働情報記録部と、
    前記障害情報と関係を有するものとして関連づけられている前記稼働情報との組み合わせである障害パターンが、互いに識別可能に記録されている障害パターン記録部と、
    前記障害パターン各々について、当該障害パターンによって特定される前記障害が発生した場合に、前記コンピュータにおいて収集すべき障害対処情報と、その障害対処情報の収集を実行するためのコマンドとの組み合わせを対応付けて記録している関連情報記録部と、
    前記障害が発生したことを検出した場合に、前記障害情報記録部に記録されている前記障害情報と、所定の条件に従って前記障害情報と対応付けられる前記稼働情報とを抽出する障害情報抽出部と、
    抽出した当該障害情報及び稼働情報との組み合わせから前記障害パターン記録部を参照して前記障害パターンを特定し、前記関連情報記録部を参照して特定した前記障害パターンに対応する前記障害対処情報を特定する障害対処情報特定部と、
    前記関連情報記録部を参照して、前記障害対処情報を収集するために実行すべき前記コマンドを特定し、当該コマンドを実行して前記障害対処情報を収集する障害対処情報収集部と、
    を備えている情報処理装置。
JP2009275823A 2009-12-03 2009-12-03 情報処理システム、情報処理装置、及び管理コンピュータ Pending JP2011118695A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009275823A JP2011118695A (ja) 2009-12-03 2009-12-03 情報処理システム、情報処理装置、及び管理コンピュータ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009275823A JP2011118695A (ja) 2009-12-03 2009-12-03 情報処理システム、情報処理装置、及び管理コンピュータ

Publications (1)

Publication Number Publication Date
JP2011118695A true JP2011118695A (ja) 2011-06-16

Family

ID=44283936

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009275823A Pending JP2011118695A (ja) 2009-12-03 2009-12-03 情報処理システム、情報処理装置、及び管理コンピュータ

Country Status (1)

Country Link
JP (1) JP2011118695A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9047408B2 (en) 2013-03-19 2015-06-02 International Business Machines Corporation Monitoring software execution
JP2016218844A (ja) * 2015-05-22 2016-12-22 日本電気株式会社 監視装置
JP2019114161A (ja) * 2017-12-26 2019-07-11 日本電信電話株式会社 状態推定装置、状態推定方法及びプログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9047408B2 (en) 2013-03-19 2015-06-02 International Business Machines Corporation Monitoring software execution
JP2016218844A (ja) * 2015-05-22 2016-12-22 日本電気株式会社 監視装置
JP2019114161A (ja) * 2017-12-26 2019-07-11 日本電信電話株式会社 状態推定装置、状態推定方法及びプログラム

Similar Documents

Publication Publication Date Title
CN108763038B (zh) 告警数据的管理方法、装置、计算机设备及存储介质
US8276023B2 (en) Method and system for remote monitoring subscription service
US20180240056A1 (en) Web-based support subscriptions
US8578337B2 (en) Method and system for quality assurance subscription service
EP2648104A1 (en) Dependability maintenance device, dependability maintenance system, malfunction supporting system, method for controlling dependability maintenance device, control program, computer readable recording medium recording control program
US20220129287A1 (en) Alerting, diagnosing, and transmitting computer issues to a technical resource in response to an indication of occurrence by an end user
US20060200450A1 (en) Monitoring health of actively executing computer applications
US20140089744A1 (en) Information processing apparatus, information processing method, and recording medium
US20140310564A1 (en) Autonomous Service Management
US8489941B2 (en) Automatic documentation of ticket execution
JP2010009552A (ja) ソフトウェア構成要素をバックアップするためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP2017532660A (ja) マルチテナント・サービスのための自動テナント・アップグレード
US11086919B2 (en) Service regression detection using real-time anomaly detection of log data
JP2011118695A (ja) 情報処理システム、情報処理装置、及び管理コンピュータ
JP6317074B2 (ja) 障害通知装置、障害通知プログラムならびに障害通知方法
JP2016045004A (ja) 分析装置管理システム
US8402125B2 (en) Method of managing operations for administration, maintenance and operational upkeep, management entity and corresponding computer program product
JP2001344130A (ja) リモートメンテナンス装置と、その装置に接続される端末と、リモートメンテナンス処理用プログラム及びそのプログラムの記録媒体
JP2016181022A (ja) 情報処理装置、情報処理プログラム、情報処理方法、及びデータセンタシステム
CN111739564A (zh) 一种录音数据的采集系统及采集方法
WO2010010393A1 (en) Monitoring of backup activity on a computer system
Barakat et al. Windows forensic investigations using powerforensics tool
JP2007241873A (ja) ネットワーク上のコンピュータ資源の変更監視プログラム
US9223946B1 (en) Specification and configuration of management intent
KR102500038B1 (ko) 비대면 기반의 컴퓨터 유지보수장치