(57)【要約】【課題】  本発明の課題は、障害を解析するために必要な資料採取を行う際に資料採取による予期せぬ２次障害を発生させないようにすることにある。【解決手段】  前記課題は、障害発生のシステムで許容できる２次障害のリスクのポリシーをパラメータシート１１１として規定し、資料採取を行う時にこのポリシーと、データベース中に格納された資料採取影響テーブル１１２、障害システムの動的な情報とを比較する事によって、取得する資料を選択することで達成される。【選択図】  図１
2006195687.tif 000002
【特許請求の範囲】
【請求項１】
監視対象のシステムで発生した障害を解析するために必要な資料採取を安全に行うシステムであって、
監視対象のシステムで発生した障害を識別するための識別情報を受信して、過去に発生した障害とその際に採取した資料を示す事例データベースを参照し、前記受信した識別情報で識別される障害を解析するために必要な資料を前記事例データベース中から選択する障害診断部と、
前記選択された必要な資料と、その資料の採取による影響を記述した資料採取影響データベースを照合することで管理対象のシステムで実行する資料採取を抽出する資料採取影響確認部と、前記抽出された資料を監視対象システムに要求する資料要求部を有することを特徴とする障害調査資料採取システム。
【請求項２】
請求項１に記載の障害調査資料採取システムにおいて、その資料の採取による影響を確認するときに、事前に監視対象システムのシステム管理者が設定したパラメータシートを基準として資料採取の影響と比較を特徴とする障害調査資料採取システム。
【請求項３】
請求項１または請求項２に記載の障害調査資料採取システムにおいて、監視対象のシステムで実行された資料採取の実績を前記資料採取影響データベースに更新する事例影響更新部を有することを特徴とする障害調査資料採取システム。
【請求項４】
請求項１、請求項２、請求項３に記載の障害調査資料採取システムにおいて、資料採取の影響を確認するときに、動的に監視対象のシステムの状況を取得することで、事前に資料採取の影響の見積もりを行うことを特徴とする障害調査資料採取システム。
【請求項５】
請求項２に記載のパラメータシートにおいて、資料採取の影響を判断するときに、資料採取の成功実績を用いることを特徴とする障害調査資料採取システム。
【請求項６】
請求項２に記載のパラメータシートにおいて、資料採取の影響を判断するときに、ディスクの使用量を用いることを特徴とする障害調査資料採取システム。
【請求項７】
請求項２に記載のパラメータシートにおいて、資料採取の影響を判断するときに、パフォーマンスへの影響を用いることを特徴とする障害調査資料採取システム。
【請求項８】
請求項２に記載のパラメータシートにおいて、資料採取の影響を判断するときに、数値化されない状態変化を禁止条件として用いることを特徴とする障害調査資料採取システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象のシステムで発生した障害を解析するための資料採取方法及びそのシステムに関するものである。
【背景技術】
【０００２】
従来、ハードウェアまたはソフトウェアの不良や設定ミスによる障害解析において、マニュアル等で対処できない場合には、カスタマサポートセンタへ問い合わせていた。
【０００３】
そして出力されたログに基づき、更に詳細な情報を得るという作業を、障害発生側管理者とサポートセンタ側担当者との間で何度かやり取りする事で障害解析に必要な情報を集め人手と時間を要していた。
【０００４】
また、この人手と時間を軽減するために、発生した障害解析に必要な情報収集を自動的に行い人手でのやりとりを軽減させるシステムについて特開２００３−３４５６２８号公報に記載されている。
【０００５】
その概要は、過去に発生した障害とその際に採取した資料を示すデータベースを参照し、障害発生時のログと比較することにより解析に必要な資料を特定し採取を行う処理を自動化するシステムである。
【０００６】
【特許文献１】特開２００３−３４５６２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来技術は、障害解析に必要な情報を効率よく網羅的に取る機能は備えているが、障害発生側管理者によるシステムの管理ポリシーや、資料採取を行う事自体による影響を考慮していないため、資料採取自体によるディスクフル、システムハング、パフォーマンスへの負荷等といったシステム管理者にとって予期せぬ２次障害が起こりうるという安全性への問題があった。
【０００８】
本発明の目的は、事前にシステム管理者によるシステムの許容できるリスクをポリシーとして定め、そのリスク範囲内での資料採取を実現することにある。
【課題を解決するための手段】
【０００９】
本発明では、事前にシステム管理者は、システムの許容できるリスクのポリシーをパラメータシートとして規定する機能を備え、さらに資料採取を行う時にこのポリシーと、データベース中に格納された資料採取影響テーブル、障害システムの動的な情報を比較する事によって、取得する資料を選択することで達成するものである。
【発明の効果】
【００１０】
本発明によれば、資料採取時の動的なシステムの状態を確認した上で資料採取を行うため、システムの状態判断することで資料採取実施前に、起こりうる２次障害の把握、抑止するという効果がある。
【発明を実施するための最良の形態】
【００１１】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。
【００１２】
図１は、本発明における一実施例である障害調査資料採取システムの構成を示すものである。
【００１３】
本実施例では、システムはネットワーク１０４に接続された監視対象システム１００と障害管理システム１０５で実現されており、監視対象システム１００は、資料採取コマンドを実行し資料取得を行う資料採取部１０２と、発生したエラーを検知する障害検知部１０３が割り当てられ、障害管理システム１０５には、調査に必要な資料を特定する障害診断部１０６、資料取得による影響を確認し実行可能かどうかを判断する取得資料影響確認部１０７、資料要求部１０８、資料取得による実績を資料採取影響データベースに反映させる事例影響更新部１０９が割り当てられる。
【００１４】
障害管理システム１０５には、これまでに発生した障害の事例を示す情報を保持する事例データベース１１０と、監視対象システム１００の許容できる影響度をポリシーとして事前に登録したパラメータシート１１１と、資料採取の実績情報と資料採取による影響情報を保持する資料採取影響データベース１１２と、見積りコマンドテーブル１１４と資料採取コマンドテーブル１１５を持つコマンドデータベース１１３を有している。本実施例では、ネットワークで接続された監視対象システム１００に資料採取部１０２と障害検知部１０３を配置しているが、障害管理システム側に配置してもよいし、独立した監視システムとしてもよい。また、障害管理システム１０５は、ネットワーク経由で複数の監視対象システムの障害監視をしてもよい。
【００１５】
次に図１を用いて本システムの動作を簡単に説明する。
【００１６】
監視対象システム１００内で、障害１０１が発生した場合、障害検知部１０３が発生した障害を検知しエラー番号を障害診断部１０６に送信する。
【００１７】
エラー番号を受信した障害診断部１０６は、エラー番号をキーとして事例データベースを検索し調査に必要な資料採取番号を特定し、取得資料影響確認部１０７へ制御を移す。
【００１８】
取得資料影響確認部１０７ではパラメータシート１１１と資料採取影響データベース１１２の情報から、実際に資料取得を行うかどうかを絞り込み資料要求部１０８へ制御を移す。なお、取得資料影響確認部１０７は、資料採取内容によってはシステムの状態によって影響が異なる場合もあるため、資料採取部１０２と通信を行い監視対象システムの動的な情報の取得も行う。
【００１９】
資料要求部１０８では、資料採取コマンドテーブル１１３を検索し取得資料コマンドを得て、このコマンドを資料採取部１０２へ送信することで資料の採取を実現し、事例影響更新部１０９へ制御を移す。
【００２０】
事例影響更新部１０９では、資料取得の実績情報を資料採取影響データベース１１２に反映させ更新する。取得した資料の格納処理については、特開２００３−３４５６２８号公報の方式を用いる。
【００２１】
事例データベース１１０は、これまでに発生した障害の事例を示す情報を保持するデータベースである。事例データベースには、図２で示すように障害発生のエラー番号２０１、エラーの発生要因２０２、これまでにこの障害の原因究明に必要となった資料を取得するための資料採取番号２０３がある。
【００２２】
図２での例では、エラー番号「ERRDB002」の発生要因として「メモリ破損」「HDD不良」が登録されており、調査にはそれぞれ資料採取番号「OS0002」「NET088」であらわされる資料の採取が必要であることを意味している。
【００２３】
なお、この事例データベースは、障害管理システムの運用者が随時追加していくものとする。
【００２４】
パラメータシート１１１は、監視対象システム１００の管理者が監視対象システム１００の許容できる資料採取による影響度をポリシーとして記載し、障害管理システムの運用者が事前に障害管理システム１０５に登録した設定情報である。パラメータシート１１１は、事前に監視対象システムごとに１つ設定する。
【００２５】
パラメータシート１１１には、図３で示すように、資料採取の成功確率による条件について設定を行う実績３０１、トレースのサイズによる資料採取実行の条件について設定を行うトレースサイズ３０２、パフォーマンスへの影響による資料採取実行の条件について設定を行うパフォーマンス３０３、「ハング」、「アプリケーションの再起動」といった特定の禁止条件について設定を行う禁止条件３０４がある。
【００２６】
パフォーマンス３０３の場合は、監視対象システムの管理者がパフォーマンスへの影響を重要視するかどうかを「１」「２」「３」で数値化することで登録し、数字が小さいほうが影響を重要視していることを意味する。
【００２７】
図３での例では、資料採取の成功率が６０％以上、かつ資料採取によるトレースサイズが１０MByte以内、かつパフォーマンスへの影響を重要視せず、かつ資料採取によるハング、アプリケーションの再起動が報告されている場合は取得しないということを表している。ここで、設定された条件の中で、ひとつでも条件を満たさない場合は資料の採取は行わない。
【００２８】
資料採取影響データベース１１２は、資料採取の実績情報と資料採取による影響情報を保持するデータベースである。資料採取影響データベース１１２には、図４で示すように、資料採取の内容ごとに一意に定められた資料採取番号４０１、プラットフォーム４０２、実施回数４０３、成功回数４０４、資料採取時に動的に見積もりを行うかどうかを判断する見積りフラグ４０５、資料採取でのディスク使用量情報をあらわすトレースサイズ４０６、資料採取によるパフォーマンスへの負荷情報であるCPU負荷４０７、資料採取による特記事項情報である注意事項４０８がある。
【００２９】
資料採取の処理内容によって、システムへの負荷が静的に定まる場合と、障害発生時のシステムの状況により影響が動的に変化する場合がある。この状況に対応するため見積りフラグ情報４０５では、設定値「０」の場合は動的な見積りは行わないことを意味し、「１」の場合は、資料採取前に監視対象システム１００にて動的に見積りが必要であることを意味する。動的な見積りを行う項目については、トレースのサイズ４０６、ＣＰＵへの負荷４０７があり、これらの項目に見積り採取番号が含まれている。
【００３０】
パフォーマンスへの影響情報であるCPU負荷４０７の場合は、パフォーマンスへの影響を「１」「２」「３」の３段階で数値化して登録されており、数字が高いほうがパフォーマンスへの影響が大きいことを意味する。
【００３１】
図５の見積りコマンドテーブル１１４は、見積り採取番号とその番号が意味するコマンドスクリプト情報をもつテーブルであり、各見積採取番号５０１と資料名５０２とコマンド実行スクリプト５０３を持つ。
【００３２】
図６の資料採取コマンドテーブル１１５は、資料採取番号とその番号が意味するコマンドスクリプト情報をもつテーブルであり、各見積採取番号６０１と資料名６０２とコマンド実行スクリプト６０３を持つ。
【００３３】
図７は障害検知部１０３による障害発生を検知した際の一連の流れを示したフローチャートである。図７で示すように、監視システム１００内で障害が発生した場合に、資料見地部１０３が検知する（ステップ７０１）。次に障害管理システム１０５へ発生したエラー番号を送信する（ステップ７０２）。その後処理を終了する。
【００３４】
図８は障害診断部１０６によるエラー番号から調査に必要な資料の特定を行う際の一連の流れを示したフローチャートである。図８で示すように、障害検知部１０３から受信したエラー番号をキーとして事例データベース１１０から、エラー番号２０１と一致する項目の資料採取番号２０３を抽出しリストにする（ステップ８０１）。その後、抽出したリストが空かどうかを確認する（ステップ８０２）。空の場合は保守員へ通知等をする。リストが空でない場合は、このリストを取得資料影響確認部へ渡し（ステップ８０３）、処理を終了する。
【００３５】
図２の事例データベース１１０を例に説明すると、障害診断部１０６がエラー番号「ERRDB0002」を受信した場合に、事例データベース１１０を検索し、このエラー番号の調査に必要な資料採取番号「OS0002」２０４、「NET088」２０５がリストとして抽出され取得資料影響確認部１０７へ渡される。
【００３６】
図９は、取得資料影響確認部１０７による絞込み処理を行う際の一連の流れを示したフローチャートである。図９で示すように、まずパラメータシート１１１を読み込む（ステップ９０１）。次に障害診断部１０６から受け取った資料採取番号のリストから１つ資料採取番号を取り出し、資料採取番号をキーとして資料採取影響データベース１１２が資料採取番号４０１と一致する情報を取得し保持する（ステップ９０２）。この取得した情報の中から見積もりフラグ４０５の値によって、動的に監視対象システム１００で取得資料の負荷見積もりを行うかどうかを判別する（ステップ９０３）。
【００３７】
ここで、見積もりフラグが「０」の場合は、そのまま次のステップ９０６に進む。
【００３８】
見積もりフラグが「１」の場合は、動的に監視対象システム１００での見積りが必要であることを意味するため、トレースサイズ４０６の見積り採取番号をキーとして見積もりコマンドテーブル１１４から、見積採取番号５０１と一致するコマンド実行スクリプト５０４を取得し（ステップ９０４）、このスクリプトを資料採取部１０２に送信し監視対象システム１００側で実行する事で動的な状態を入手し、その値をステップ９０２で保持した資料影響のトレースサイズ４０６に反映させる（ステップ９０５）。
【００３９】
その後、パラメータシート１１１と資料採取影響をステップ９０６以降にて比較を行い条件に合致しているかの確認を行う。
【００４０】
まず、最初に成功確率の比較では、パラメータシート１１１の実績３０１と、資料採取影響データベースの実施回数４０３と成功回数４０４から求める成功確率を比べる（ステップ９０６）。実績３０１であらわされる確率より資料採取の成功確率が高い場合は、次に領域の比較のステップ（ステップ９０７）へ進み、それ以外の場合はステップ９１１へ進む。
【００４１】
資料採取による使用領域の比較では、パラメータシート１１１のトレースサイズ３０２と、資料採取影響データベースの資料採取によるトレースサイズ４０６を比較する（ステップ９０７）。３０２の値より４０６の値が同じか小さい場合は、次のCPU負荷への比較のステップ（ステップ９０８）へ進み、それ以外の場合はステップ９１１へ進む。
【００４２】
CPU負荷への比較のステップでは、パラメータシート１１１のパフォーマンス３０３と、資料採取影響データベースのCPU負荷４０７を比較する（ステップ９０８）。３０３の値より４０７の値が同じか小さい場合は、注意事項の比較のステップ（ステップ９０９）へ進み、それ以外の場合はステップ９１１へ進む。
【００４３】
注意事項の比較のステップでは、パラメータシート１１１の禁止条件３０４と、資料採取影響データベースの注意事項４０８を比較する（ステップ９０９）。３０４に記載の内容が、４０８に記載されている内容と同様の記載がない場合は、パラメータシートの全ての条件を満たしたリストとして資料採取番号を追加し（ステップ９１０）、それ以外の場合はステップ９１１へ進む。
【００４４】
次にステップ９１１では、障害診断部１０６から受け取った資料採取番号のリストの中で、パラメータシートと資料採取影響データベースとの未比較な資料採取番号番号がある場合はステップ９０２へ進み、全て比較し終えた場合は、パラメータシートの全ての条件を満たしたリストを資料要求部１０８に渡し（ステップ９１２）、処理を終了する。
【００４５】
図９での処理の流れを、障害診断部１０６から受け取った資料採取番号のリストに「OS0002」、「NET088」が登録されていることを想定し、図３でのパラメータシートと、図４での資料採取影響データベースの値を用いて詳細な説明を行う。
【００４６】
まず、資料採取番号のリストから「OS0002」を取り出し、ステップ９０２で資料採取番号をキーとして資料採取影響データベースから検索することで、この資料採取による影響の情報（４１０）を得て保持する。次に見積りフラグのチェック（ステップ９０３）では、見積りフラグが「１」であるため、メモリ情報取得に必要なDISK使用量について動的に監視対象システムの情報を取得する（ステップ９０５）。この例では、動的な情報の取得で資料取得によるトレースサイズが５MByteであるとしこの値を反映させる。次にパラメータシートと資料採取による影響の比較（ステップ９０６、ステップ９０７、ステップ９０８、ステップ９０９）ではいずれもパラメータシートの条件を満たしているため、この資料採取番号「OS0002」をリストに追加（ステップ９１０）する。
【００４７】
次に、資料採取番号「NET088」の場合は、ステップ９０２で資料採取番号をキーとして資料採取影響データベースから検索することで、この資料採取による影響の情報（４０９）を得る。次に見積りフラグのチェックでは、見積りフラグが「０」のため、動的な見積りは行わない。次にパラメータシートと資料採取の影響の比較において、注意事項の比較（ステップ９０９）で、パラメータシートの禁止条件に「ハング」があり、「NET088」の注意事項４０８に同様に「ハング」の記載があるため「NET088」については、リストへの登録（９１０）は行われない。上記判定により、「OS0002」のリストのみが要求資料部に渡される（ステップ９１２）。
【００４８】
図１０は、資料採取部１０２による監視対象システムでの資料採取を行う際の一連の流れを示したフローチャートである。図１０で示すように、障害管理システム１０５から送信されたコマンドを受信し、監視対象システム１００で実行する（ステップ１００１）。次に実行結果を資料要求部１０８へ送信し（ステップ１００２）、終了する。
【００４９】
図１１は、資料要求部１０８、事例影響更新部１０９によるシステムでの資料採取を行う際の一連の流れを示したフローチャートである。
【００５０】
図１１で示すように、資料採取番号のリスト情報から1つ資料採取番号を取り出し（ステップ１１０１）、次に取り出した資料採取番号６０１をキーとして資料採取コマンドテーブル１１３のコマンド実行スクリプト情報６０３を得る（ステップ１１０２）。
【００５１】
次に監視対象システム１００内の資料採取部１０２へ送信し結果を得る（ステップ１１０３）。次に事例影響更新部１０９で取得の成否について確認する（ステップ１１０４）。
【００５２】
取得に失敗した場合は、資料採取影響データベース１１２の実施回数４０３の値を１増加させ、失敗理由を注意事項４０８に反映させる（ステップ１１０５）。
【００５３】
取得に成功した場合は、資料採取影響データベース１１２の実施回数４０３および成功回数をそれぞれ１増加させ（ステップ１１０６）、受信した資料を保存する（ステップ１１０７）。なお保存方式については既存技術を用いる。
【００５４】
次に資料採取番号のリストの資料を全て取得したかどうかを確認し（ステップ１１０８）、まだ未取得の資料番号がある場合はステップ１１０１に進み、全て取得を試みた場合は処理を終了させる。
【図面の簡単な説明】
【００５５】
【図１】本実施形態の障害調査資料採取システムの概略構成を示す図である。
【図２】事例データベース。
【図３】パラメータシート。
【図４】資料採取影響データベース。
【図５】見積りコマンドテーブル。
【図６】資料採取コマンドテーブル。
【図７】障害検知部の処理のフローチャート。
【図８】障害診断部の処理のフローチャート。
【図９】取得資料影響確認部の処理のフローチャート。
【図１０】資料採取部の処理のフローチャート。
【図１１】資料要求部、事例影響更新部の処理のフローチャート
【符号の説明】
【００５６】
１００…監視対象システム、１０１…障害、１０２…資料採取部、１０３…障害検知部、１０４…ネットワーク、１０５…障害管理システム、１０６…障害診断部、１０７…取得資料影響確認部、１０８…資料要求部、１０９…事例影響更新部、１１０…事例データベース、１１１…パラメータシート、１１２…資料採取影響データベース、１１３…コマンドデータベース、１１４…見積りコマンドテーブル、１１５…資料採取コマンドテーブル。
【図１】
2006195687.tif 000003
【図２】
2006195687.tif 000004
【図３】
2006195687.tif 000005
【図４】
2006195687.tif 000006
【図５】
2006195687.tif 000007
【図６】
2006195687.tif 000008
【図７】
2006195687.tif 000009
【図８】
2006195687.tif 000010
【図９】
2006195687.tif 000011
【図１０】
2006195687.tif 000012
【図１１】
2006195687.tif 000013