障害対策支援システム
【課題】障害の発生原因の特定と障害回復までの時間がシステム管理者の個人的なスキルによってばらつき易い。
【解決手段】監視システムから障害通知メールを受けると、障害通知メールから障害が発生した機能を特定すると共に、対応する障害ログから原因の特定に有益な情報をキーワード検索により取得する。この後、受信したメールと、取得したログに関する情報を関連付けて蓄積する。後日同様の障害が発生した場合には、過去の障害履歴をシステム管理者に迅速に通知する。
【解決手段】監視システムから障害通知メールを受けると、障害通知メールから障害が発生した機能を特定すると共に、対応する障害ログから原因の特定に有益な情報をキーワード検索により取得する。この後、受信したメールと、取得したログに関する情報を関連付けて蓄積する。後日同様の障害が発生した場合には、過去の障害履歴をシステム管理者に迅速に通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、新たに発生した障害の解決を過去の障害事例に基づいて支援するシステムに関する。
【背景技術】
【０００２】
コンピュータシステムの運用管理では、障害の発生原因、その特定方法、その対策方法等に関するノウハウの蓄積と伝達が重要とされる。従来、ノウハウの蓄積や伝達は、自身の経験による獲得、口頭による伝達、「障害管理シート」と呼ばれる障害の原因と対策をまとめたドキュメント等により行われている。また、システム障害の発生は、監視システムからシステム管理者に宛てた障害通知メールにより通知され、通知を受けたシステム管理者が障害内容の特定と回復作業を行う仕組みになっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平８−３１４７５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
コンピュータシステムに障害が発生した場合、システム管理者は、まず障害の適切な回復方法を決定する必要がある。この際、システム管理者は、障害が発生した機能の特定、障害が発生した機能のログの参照、「障害管理シート」のようなドキュメントの参照を実行し、場合によっては、過去に同様の障害が発生した際のメールのやりとりを検索する等の作業を実行する。そして、障害の発生原因の特定後に障害の回復手順を確立する作業手順が採用されている。
【０００５】
しかし、このような従来手法では、障害対策の正しさや障害回復までの早さがシステム管理者個人のスキルに依存しやすい。
【０００６】
例えばログを参照して障害対策を検索しようとしても、ログには、障害の発生原因以外の情報（例えばシステムの稼働状況等を記した正常なログ）も数多く含まれている。従って、ログの中から、障害の発生原因が出力されている箇所をいかに早く特定できるかは、システム管理者個人のスキルに依存することが多い。更に、障害の発生原因を特定できるほどの正確なログがそもそも出力されていないこともある。その場合は、経験から障害発生原因を推測する必要があるが、経験には大きな個人差が存在する。
【０００７】
また、過去にやりとりされたメールには、障害が回復されるまでの知識その他の有益な情報が多く含まれることが経験的に知られている。しかし、経験の浅いメンバの場合には、該当するメールを探しきれない可能性もある。
【０００８】
そこで、本発明では、システム管理者個人のスキル差を前提としながらも、障害回復の早さと正確さのばらつきを少なくできる機能を提供することを目的とする。
【課題を解決するための手段】
【０００９】
この目的のため、本発明は、障害発生時に出力される障害ログのうち障害の特定に有益な部分（概要）と障害が回復されるまでのメールのやりとり等とを関連付けて自動的に蓄積する。そして、同様の障害が後日発生した場合には、発生した障害に基づいて蓄積データを検索し、関連する過去の障害ログの概要をシステム管理者に自動的に通知する仕組みを提案する。
【発明の効果】
【００１０】
本発明によれば、システム管理者が複数の作業を経て取得する必要があった情報を、障害通知メールを通じて自動的に通知することができる。これにより、作業の手間を大幅に軽減することができる。また、システム管理者は、障害通知メールを通じて過去の対策例に容易にアクセスできるため、障害回復の早さと正確さのばらつきを少なくすることができる。
【図面の簡単な説明】
【００１１】
【図１】形態例に係る障害対策支援システムの概略構成を示す図である。
【図２】障害通知メールの一例を示す図である。
【図３】メールフォーマットの一形態例を示す図である。
【図４】メール解析結果ファイルの一形態例を示す図である。
【図５】機能別ログ配置場所ＤＢのデータ構成例を示す図である。
【図６】機能別監視文字ＤＢのデータ構成例を示す図である。
【図７】ログ解析結果ファイルの一形態例を示す図である。
【図８】メールＤＢのデータ構成例を示す図である。
【図９】ログＤＢのデータ構成例を示す図である。
【図１０】メール／ログ関連ＤＢのデータ構成例を示す図である。
【図１１】対策方法ＤＢのデータ構成例を示す図である。
【図１２】障害履歴通知メールの形態例を示す図である。
【図１３】障害対策履歴参照／対策詳細登録画面の一形態例を示す図である。
【図１４】障害通知メールの受信から障害履歴の通知までに実行される処理手順の概要を示すフローチャートである。
【図１５】システム管理者による障害通知メールの受信から障害対策の完了までに実行される作業手順の概要を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、発明に係る障害対策支援システムの形態例を図面に基づいて説明する。なお、図面は、専ら発明の説明を目的として作図したものであり、発明の範囲を限定するものではない。
【００１３】
（１）システムの全体構成
図１に、形態例に係る障害対策支援システム１００の全体構成例を示す。障害対策支援システム１００は、メール受信部１０１、メール解析部１０２、ログ解析部１０３、メール／ログ履歴登録部１０４、障害対策履歴検索部１０５、メール送信部１０６、障害対策履歴参照／対策詳細登録部１０７、メールフォーマットファイル１０８、ログ監視情報登録部１０９、機能別ログ配置場所ＤＢ１１０、機能別監視文字ＤＢ１１１、障害情報蓄積ＤＢ部１１２、取得ログ配置フォルダ１１７で構成される。
【００１４】
ここで、メール受信部１０１は、当システム宛のメールの受信に用いられる。メール解析部１０２は、受信したメールが障害通知メールか否かを解析する処理部である。解析結果はメール解析結果ファイルとして出力される。ログ解析部１０３は、障害通知メールと解析されたメールを解析対象として、メール内に障害解析に有益なログが含まれるか否かを解析する処理部である。解析結果はログ解析結果ファイルとして出力される。
【００１５】
メール／ログ履歴登録部１０４は、メール解析結果ファイルとログ解析結果ファイルの情報を、障害情報蓄積ＤＢ部１１２の対応するデータベースに登録する処理部である。障害対策履歴検索部１０５は、受信したメールが障害通知メールであった場合に、当該メールや障害ログの解析結果に基づいて、関連性が高い過去の障害履歴を検索する処理部である。メール送信部１０６は、検索された障害履歴を障害履歴通知メールとしてシステム管理者に通知する処理部である。
【００１６】
障害対策履歴参照／対策詳細登録部１０７は、検索された障害履歴とそれに紐付けられた対策方法の参照処理と編集処理を分担する処理機能部である。メールフォーマットファイル１０８は、受信したメールの解析時に参照するフォーマット情報が格納されるストレージ領域である。ログ監視情報登録部１０９は、機能別ログ配置場所ＤＢ１１０及び機能別監視文字ＤＢ１１１に対する情報の登録処理を分担する処理部である。
【００１７】
機能別ログ配置場所ＤＢ１１０と機能別監視文字ＤＢ１１１は、ログファイルの解析に使用する情報を格納するデータベースである。なお、機能別ログ配置場所ＤＢ１１０には、外部システムにおけるログファイル（障害ログ）の格納場所が機能別に格納される。また、機能別監視文字ＤＢ１１１には、監視対象とする文字列が機能別に格納される。障害情報蓄積ＤＢ部１１２は、解析されたメール情報と、解析されたログ情報を蓄積するストレージ装置又はストレージ領域である。取得ログ配置フォルダ１１７は、外部システムのログファイルをローカルエリアに保存するために使用されるストレージ装置又はストレージ領域である。
【００１８】
なお、障害対策支援システム１００には、ネットワーク経由で障害対策を支援したい外部システム１１８と、監視対象の外部システム１１８が正常に動作しているか否かを監視する監視システム１１９とが接続されている。なお、支援対象としての外部システム１１８の数は１つに限らず、複数の場合も考えられる。一方、監視システム１１９は、外部システム１１８に対して一対一に配置されても良いし、複数の外部システム１１８に対して１つ配置されても良い。
【００１９】
ここで、監視システム１１９は、外部システム１１８のログ、ジョブの終了コード、ＯＳ（オペレーションシステム）のイベントログ等に基づいて障害の発生を検知し、管理者メンバに対して障害通知メールを送信するように機能する。
【００２０】
図２に、障害通知メールの一例を示す。図２に示すように、障害通知メールには、障害が発生した機能、障害が発生した時間、監視システムが検知した情報等が記述される。例えば送信元「From」には監視システムのメールアドレスが記述され、宛先「To」には管理者メンバのメールアドレスが記述され、タイトル「Subject」には障害が発生した機能、本文「body」には検知された情報の概要が記される。
【００２１】
ところで、この形態例の場合、障害通知メールは、監視システム１１９から管理者メンバと障害対策支援システム１００の両方に宛てて送信される。このため、前述したメール受信部１０１では、障害通知メールを受信することができる。なお、障害対策支援システム１００に対する障害通知メールの送信は、管理者用メーリングリストに当システムを加える等の方法により実現することができる。
【００２２】
（２）各部の詳細動作
続いて、障害対策支援システムを構成する各部において実行される詳細動作の内容を説明する。
（２−１）メール解析部の詳細動作
メール解析部１０２は、受信したメールとメールフォーマットファイル１０８とを比較することにより、受信したメールが監視システム１１９から受信された障害通知メールか否かを判定する処理を実行する。障害通知メールであると判定された場合、メール解析部１０２は、障害が発生した機能が何かをメールから取得し、取得された情報をログ解析部１０３に渡す機能を提供する。一方、障害通知メールであると判定された場合、メール解析部１０２は、受信したメールをメール／ログ履歴登録部１０４に渡す機能を提供する。
【００２３】
図３にメールフォーマットの一例を示す。メールフォーマットには、障害通知メールの形式情報（例えば送信元「From」、送信先「To」、タイトル、本文がどのような形式となっているか）と、障害通知メールから障害が発生した機能を抜き出すために必要な情報とが記述されている。ここでは、図２に示す障害通知メールと、図３に示すメールフォーマットを使用して解析処理を実行する例を考える。
【００２４】
最初に、メール解析部１０２は、受信したメールがメールフォーマットと一致するか否かを確認する。この場合、メール解析部１０２は、障害通知メール（図２）の「From」、「To」と、メールフォーマット（図３）の「From」、「To」とを比較する。両者が一致する場合、受信されたメールには、メールフォーマット（図３）と同じメールアドレスが記述されていることが分かる。
【００２５】
次に、メール解析部１０２は、「Subject」の５文字目がアルファベットで、続く４文字が数値で記載されているか否かを判定する。図２の例の場合、先頭から５文字目の文字が「Ｂ」であり、続く４文字が「１００５」である。以上の通り、図２の受信されたメールは、「From」、「To」、「Subject」の全てがメールフォーマット（図３）と一致する。この一致検出により、メール解析部１０２は、図２に示すメールが監視システム１１９から発せられた障害通知メールであると判断する。
【００２６】
次に、メール解析部１０２は、受信されたメールの「Subject」の先頭から５文字目から９文字目までに位置する計５文字を障害が発生した機能の識別子（ＩＤ）として抽出する。なお、この形態例に係る監視システム１１９には、該当位置に対して、障害の発生した機能を特定する識別子（ＩＤ）を付与する機能が搭載されているものとする。図２の場合、「Ｂ１００５」が識別子（ＩＤ）として抽出される。なお、この形態例の場合には、英数字と４文字の数字で識別子（ＩＤ）を定義しているが、言うまでもなくこれは一例である。また、識別子の配置場所についても一例である。
【００２７】
このように、障害が発生した機能を特定する識別子（ＩＤ）が抽出されると、メール解析部１０２は、メール解析結果ファイルを生成する。図４に、メール解析結果ファイルの一例を示す。メール解析結果ファイルは、障害発生機能欄４０１と、受信したメールの全文４０２で構成される。なお、受信したメールが監視システム１１９から受信した障害通知メールでなかった場合、障害発生機能欄４０１は空欄のままとする。ここで、受信メールの全文４０２を付加するのは、後で説明するメールＤＢ１１３にメールを登録するためである。
【００２８】
メール解析部１０２は、障害通知メールであると判定した場合、メール解析結果ファイル（図４）をログ解析部１０３に出力し、障害通知メールでなかった場合、障害発生機能欄４０１が空欄のメール解析結果ファイルをメール／ログ履歴登録部１０４に出力する。なお、障害通知メールの判定に使用するメールフォーマットの作成とメールフォーマットファイル１０８への登録は、監視対象システム１００の稼動前に、システム管理者によって事前に行われる。
【００２９】
（２−２）ログ解析部の詳細動作
ログ解析部１０３は、外部システム１１８にアクセスして、障害通知メールに対応するログファイル（障害ログ）から障害の発生原因を特定するために有益な情報が含まれていないか否かを検索する処理を実行する。
【００３０】
この動作に先立ち、ログ解析部１０３は、メール解析結果ファイル（図４）を受信すると、その障害発生機能欄４０１の内容に基づいて障害が発生した機能を識別子（ＩＤ）により特定する。
【００３１】
障害が発生した機能が特定されると、ログ解析部１０３は、当該機能をキーとして機能別ログ配置場所ＤＢ１１０を参照し、特定した機能に対応するログの配置場所を取り出す。
【００３２】
図５に、機能別ログ配置場所ＤＢ１１０のデータ構造例を示す。機能別ログ配置場所ＤＢ１１０には、機能ＩＤ５０１に対応付けるように、配置サーバ５０２、取得方法５０３、配置サーバに対するログインユーザ５０４、パスワード５０５、ログファイル名５０６が保持されている。
【００３３】
ログ解析部１０３は、この機能別ログ配置場所ＤＢ１１０の記述内容に従い、障害が発生した外部システム１１８に所定の方法でログインし、ログファイルを障害対策支援システム１００のローカルフォルダである取得ログ配置フォルダ１１７に配置する。ただし、外部システム１１８の種類やログファイルの配置場所等により、ログファイルの取得方法には多くのパターンがある。このため、図５に示す機能別ログ配置場所ＤＢ１１０が保持する情報は一例である。
【００３４】
次に、ログ解析部１０３は、外部システム１１８から取得したログファイルをキーワードで検索し、障害の発生原因を特定するために有益な情報を取得する処理を実行する。この際、ログ解析部１０３は、機能別監視文字ＤＢ１１１より、機能ＩＤについて登録されている任意の文字列を検索用のキーワードとして取り出す。
【００３５】
図６に、機能別監視文字ＤＢ１１１のデータ構造例を示す。機能別監視文字ＤＢ１１１には、機能ＩＤ６０１に対応付けるように、ログファイルに検索をかけるためのキーワードである監視対象文字列６０２と、監視対象文字６０２がヒットした箇所から前後何行のログを合わせて取得するかを指定する前後取得行数６０３が保持されている。
【００３６】
この形態例の場合、特定の機能ＩＤに限定せずに使用するキーワードを、機能ＩＤ６０１に“−”を設定することで登録できるものとする。従って、図６の場合、「Exception」、「エラーが発生しました。」、「処理をスキップします。」の３つが、全ての機能ＩＤに共通に使用する監視対象文字として登録されている。
【００３７】
ログ解析部１０３は、機能ＩＤ６０１を指定して取得できた複数の監視対象文字列６０２と、全機能に共通する監視対象文字列を使用してログファイルを検索する。そして、ログファイル内に監視対象文字と同じ文字列が存在した場合、その監視対象文字の一覧と、前後取得行数６０３により指定された行数分の文字列をログ情報として取得する。このログ情報が、特許請求の範囲における「障害履歴の概要」の一部に対応する。図６の場合には、監視対象文字列が出現する行と、その前後各１行の計３行が取得範囲であることを意味している。
【００３８】
このように、前後の行もログ情報の取得範囲として指定するのは、監視対象文字列の近くには障害対策に有益な情報が出現する可能性が高いためである。また、取得する範囲を限定することにより、障害対策時おける作業の効率性を高めるためである。例えば障害通知メールに対応する障害ログをそのまま蓄積する場合、たとえ関連する障害ログにアクセスできたとしても、障害原因に関連する障害ログを、人手を解して実行する必要がある。
【００３９】
なお、この形態例の場合には、前後各１行を含めた計３行を指定しているが、取得範囲を更に増やすこともできる。ただし、取得範囲を増やしすぎると閲覧負荷も増加する。従って、取得範囲は、ログ監視情報登録部１０９を通じて変更できることが望ましい。また、取得範囲は、監視対象文字列が出現する行に対して前方側だけ又は後方側だけとしても良い。
【００４０】
図７に、ログ解析部１０３によって実行されたキーワード検索の結果を書き出したログ解析結果ファイルの一例を示す。ログ解析結果ファイルには、障害の発生した機能を特定する機能ＩＤ７０１に対応付けるように、ヒットした監視対象文字列７０２と、検索にヒットした行とその前後の行から取得される前後ログ情報７０３と、検索したログファイルのローカル配置場所である元ログファイル名７０４とが保持されている。
【００４１】
なお、１つのログの中から同一の監視対象文字が複数回ヒットした場合も、ヒットした全ての箇所について同様の情報が保存される。図７の場合には、「納品書送付履歴がありません。」が２回ヒットした例を表している。このような保存形態を採用するのは、同じ原因で複数回の障害が発生していることを管理者に通知するためである。なお、ログ解析部１０３は、ログファイル内にヒットした監視文字が存在しない場合でも、機能ＩＤ以外の情報項目が全て空白のログ解析結果ファイルを作成するものとする。
【００４２】
このようにログ解析結果ファイル（図７）の作成が完了すると、ログ解析部１０３は、作成されたログ解析結果ファイルを、メール解析部１０２から受け取ったメール解析結果ファイル（図４）と共に、メール／ログ履歴登録部１０４に出力する。
【００４３】
（２−３）メール／ログ履歴登録部の詳細動作
メール／ログ履歴登録部１０４は、受け取ったメール解析結果ファイル（図４）と、ログ解析結果ファイル（図７）の内容を障害情報蓄積ＤＢ部１１２に登録する処理を実行する。なお、障害情報蓄積ＤＢ部１１２は、メールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５、対策方法ＤＢ１１６で構成される。メール/ログ履歴登録部１０４は、これら４つのＤＢ（データベース）のうちメールＤＢ１１３、ログＤＢ１１４及びメール／ログ関連ＤＢ１１５の３つにデータを登録する機能を分担する。
【００４４】
また、メール／ログ履歴登録部１０４は、データの登録後、今回登録したログＩＤの一覧を障害履歴検索部１０５に引き渡す処理を実行する。以下、メール／ログ履歴登録部１０４によるデータの登録先となる３つのテーブルのデータ構造を図８〜図１０に示す。
【００４５】
図８は、メールＤＢ１１３のデータ構造例である。メールＤＢ１１３は、障害対策支援システム１００が受信した全てのメール（メール解析結果ファイル）を蓄積するデータベースである。メールＤＢ１１３は、各メールを管理するために、一意のコードであるメールＩＤ８０１を振り出すことによりメールの情報を管理する。メールＤＢ１１３には、メールＩＤ８０１に対応付けるように、メール解析結果ファイル（図４）のメール本文４０２の情報が登録される。具体的には、メール本文８０７と、メールのヘッダ情報を構成する基本的な情報８０２〜８０６を個別に保持する。ただし、後述する障害対策履歴参照／対策詳細登録部１０７において、過去の障害発生メールのやりとりをツリー形式で見れるように、メールのツリーを作成するための情報である「In-Replay-To」ヘッダ８０４と、「References」ヘッダ８０５は必ず個別に保持しておく。この情報は必須の情報である。
【００４６】
図９は、ログＤＢ１１４のデータ構造例である。ログＤＢ１１４は、ログ解析結果ファイル（図７）を蓄積するデータベースである。ログＤＢ１１４は、各ログを管理するために、一意のコードであるログＩＤ９０１を振り出すことによりログの情報を管理する。ログＤＢ１１４には、ログＩＤ９０１に対応付けるように、機能ＩＤ９０２、監視対象文字列９０３、前後ログ情報９０４、元ログファイル９０５が登録される。なお、機能ＩＤ９０２は、図７に示すログ解析結果ファイルの機能ＩＤ７０１に対応する。同様に、監視対象文字列９０３は図７における監視対象文字列７０２に対応し、前後ログ情報９０４は図７における前後ログ情報７０３に対応し、元ログファイル９０５は図７における元ログファイル７０４に対応する。
【００４７】
図１０は、メール／ログ関連ＤＢ１１５のデータ構造例である。メール／ログ関連ＤＢ１１５は、メール／ログ履歴登録部１０４に対してメール解析結果ファイル（図４）と、ログ解析結果ファイル（図７）が同時に渡された場合に、これら２つのファイルを関連付ける情報を登録するデータベースである。図１０に示すように、メール／ログ関連ＤＢ１１５は、メールＩＤ１００１と、ログＩＤ１００２と、この２つの関連に対して対策方法（後述する）を紐付けるための対策方法ＩＤ１００３とを保持している。
【００４８】
（２−４）障害対策履歴検索部の詳細動作
障害対策履歴検索部１０５は、メール解析結果ファイル（図４）とログ解析結果ファイル（図７）とに基づいて、過去の障害履歴を検索する処理機能を実行する。障害対策履歴検索部１０５は、メールＤＢ１１３と、ログＤＢ１１４と、メール／ログ関連ＤＢ１１５を関連付けた仮想テーブルを検索対象として、ログ解析結果ファイル（図７）の機能ＩＤ７０１と監視対象文字列７０２を検索キーにした検索動作を実行する。この検索動作により、障害対策履歴検索部１０５は、メールＩＤとログＩＤの組み合わせで特定される障害履歴を取得する。
【００４９】
複数の取得結果が検出された場合、障害対策履歴検索部１０５は、対策方法ＩＤ１００３が紐付いている障害履歴、又は、対策方法ＩＤ１００３に紐付けられている対策方法ＤＢ１１６の重要度１１０３が高い障害履歴を優先的に取得する手法を採用する。図１１に、対策方法ＤＢ１１６のデータ構造例を示す。対策方法ＤＢ１１６には、対策方法の登録時に対策方法ＩＤが振り出され、この対策方法ＤＢ１１６に対応付けるように、対策方法１１０２と重要度１１０３とが関連付けられて保存されている。因みに、対策方法１１０２と重要度１１０３は、システム管理者によって個別に登録される情報である。
【００５０】
障害対策履歴検索部１０５は、取得できた情報を過去の障害履歴として管理者メンバに通知する。ただし、取得できた情報量が多い場合、メールでの通知が困難な場合も考えられる。そこで、この形態例の場合には、障害対策履歴検索部１０５は、取得した情報を参照できる画面にアクセスするための情報を通知する方法を採用する。例えば参照画面をインターネット上のＷＥＢ画面で実現する場合、障害対策履歴検索部１０５は、取得したメールＩＤとログＩＤをＵＲＬのＧＥＴパラメータに設定し、ＵＲＬの一覧形式により通知する。このＵＲＬの一覧はメール送信部１０６に渡され、管理者メンバに対して障害履歴通知メールとして送付される。
【００５１】
（２−５）メール送信部の詳細動作
図１２に、メール送信部１０６が送信する障害履歴通知メールの一例を示す。障害履歴通知メールには、障害対策履歴検索部１０５によって取得されたメールＩＤとログＩＤの組み合わせをパラメータとするＵＲＬが[過去履歴]として一覧される。一方、障害履歴通知メールには、メール／ログ履歴登録部１０４により渡されるメールＩＤをパラメータとするＵＲＬが[今回ログ]として一覧表示される。このように、今回ログと過去履歴とを区別することにより、メールを受け取った管理者メンバが情報を参照しやすい構造を実現する。なお、[今回ログ]については、メールＩＤだけをパラメータとするのは（図１２参照）、メールに対応する全てのログを表示する必要があり、特定のログだけに限定する必要がないためである。
【００５２】
なお、この形態例の場合には、障害履歴通知メールを、[今回ログ]にアクセスするためのＵＲＬと、[過去履歴]にアクセスするためのＵＲＬと、対応する障害通知メールの情報（ヘッダ及び本文の全てを含む。）とで形成する場合について説明したが、障害通知メールを特定できるのであれば、必ずしも図１２に示す構成を採用する必要はない。例えば障害履歴通知メールを、[今回ログ]にアクセスするためのＵＲＬと、[過去履歴]にアクセスするためのＵＲＬだけで構成し、メールの「Subject」等に障害通知メールを特定する情報を記述したり、メールの本文に障害通知メールにアクセスにするためのＵＲＬ等を記述しても良い。
【００５３】
（２−６）障害対策履歴参照／対策詳細登録部の詳細動作
障害対策履歴参照／対策詳細登録部１０７は、管理者メンバ側の端末に対するユーザインターフェース機能を提供する。前述したように、管理者メンバには、障害履歴通知メール（図１２）として過去の障害履歴等がＵＲＬとして通知される。障害対策履歴参照／対策詳細登録部１０７は、管理者メンバ側の端末に過去の障害履歴に対する情報をネットワーク経由で提供するためのユーザインターフェース機能を提供する。
【００５４】
図１３に、障害対策履歴参照／対策詳細登録部１０７によって管理者メンバ側に提供される表示画面例を示す。この画面は、障害履歴通知メール（図１２）において、[過去履歴]のＵＲＬの一つがクリックされた場合の表示例である。図１３に示す画面例は、メール履歴参照欄１３０３、ログ履歴参照欄１３０４、登録／変更ボタン１３０５を有している。なお、ログ履歴参照欄１３０４は、障害対策コメント登録欄１３０１と重要度登録欄１３０２を一組とする１つ又は複数の表示欄で構成される。
【００５５】
また、ログ履歴参照欄１３０４には、監視文字毎に取得ログ配置フォルダ１１７内のログファイルにアクセスするためのリンク情報１３０６が埋め込まれた状態で表示される。このリンク情報１３０６をクリックすると、対応するログファイルの全体を取得することができる。
【００５６】
なお、ログ履歴参照欄１３０４に表示する情報は、通知されたメールＩＤとログＩＤの組み合わせに基づいて、メールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５、対策方法ＤＢ１１６を検索することにより取得することができる。
【００５７】
また、メールＤＢ１１３から取得できたメールＩＤ８０１に紐付けられたメールはツリー情報として取得しておく。メールのツリー化は、メールのヘッダ情報を構成する「In-Replay-To」と「References」に基づいて実行する。因みに、「In-Replay-To」と「References」は、メールＤＢ１１３に個別に保持されている。また、ツリー化を実現するための詳細な方法は周知であるため、ここでは説明を省略する。ツリー化されたメールは、図１３に示すように、メール履歴参照欄１３０３に一覧的に表示される。
【００５８】
こここで理解すべき点は、図１３に示す画面は、１つの障害通知メールに対して自動的に生成される点である。従って、管理者メンバは、１つの障害通知メールの発生時に、過去の障害通知メール、それらに紐付けられているメールのやりとり、ログ情報の抜粋（３行分）、元のログファイル、登録された対策情報を１組として取得することが可能になる。すなわち、障害対策に必要な情報を１まとめにして一度に確認することができる。
【００５９】
また、障害対策履歴参照／対策詳細登録部１０７は、図１３に示す画面を通じて受け付けた障害対策コメント登録欄１３０１及び障害の重要度登録欄１３０２に対する情報の入力又は選択に基づいて、入力情報を対策方法ＤＢ１１６に保存する機能も提供する。情報の登録又は変更は、登録／変更ボタン１３０５のクリック操作の受け付けにより確定する。
【００６０】
（３）システム全体における処理動作の流れ
図１４に、障害対策支援システム１００において実行される処理動作のうち、障害履歴通知メールが管理者メンバに送信されるまでの動作の概要を示す。
【００６１】
まず、障害対策支援システム１００は、当システム宛の障害通知メールをメール受信部１０１で受信する（ステップ１４０１）。
【００６２】
メール解析部１０２は、受信したメールとメールフォーマットとが一致するか否かを判定する（ステップ１４０２）。
【００６３】
ここで、メールフォーマットと一致した場合（肯定結果の場合）、メール解析部１０２は、受信したメールから障害が発生した機能を特定し、メール解析結果ファイル（図４）を作成する。一方、メールフォーマットと一致しない場合（否定結果の場合）、メール解析部１０２は、監視システム１１９からの障害通知メールではないと判断し、ログの検索（ステップ１４０３）は実施しない。
【００６４】
ステップ１４０２で障害が発生した機能が特定された場合、ログ解析部１０３は、特定された機能のログファイルを取得し、ログファイル内を機能毎の監視対象文字で検索する。この検索により、ログ解析部１０３は、障害発生原因を特定するために有益と考えられる情報を取得し、ログ解析結果ファイル（図７）を作成する（ステップ１４０３）。
【００６５】
ステップ１４０２で作成されたメール解析結果ファイル（図４）と、ステップ１４０３で作成されたログ解析結果ファイル（図７）の情報は、メール／ログ履歴登録部１０４により障害情報蓄積ＤＢ部１１２のメールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５に登録される（ステップ１４０４）。
【００６６】
なお、ステップ１４０３で実行されたログ内の検索において、監視対象文字列がヒットしない場合でも、ログ解析結果ファイル（図７）は保存される。この場合、ログ解析結果ファイル（図７）には機能ＩＤ７０１しか設定されず、監視対象文字列７０２、前後ログ情報７０３、元ログファイル７０４には空情報が登録される。これは、登録したメール情報がどの機能に関するものかを特定するためである。また、ログＤＢ１１４でも機能ＩＤ９０２を登録するためである。
【００６７】
また、ステップ１４０２の判定結果が否定結果であった場合、メール／ログ履歴登録部１０４は、受信したメールをメールＤＢ１１３に登録する。このメール情報は、障害機能とは結びつかないが、監視システム１１９から発せられた障害通知メールに対してツリーで紐付ける可能性があると考えられるためである。
【００６８】
以上、ステップ１４０４の登録処理が完了すると、障害対策履歴検索部１０５が、障害の発生した機能とログファイル内を検索してヒットした監視対象文字列とをキーワードに使用して障害情報蓄積ＤＢ部１１２を検索し、過去に同様の障害が発生した事例がないか否か確認する（ステップ１４０５）。
【００６９】
ステップ１４０５で過去の障害発生事例が検索された場合、その情報を管理者メンバに通知する（ステップ１４０６）。以上が、障害対策支援システム１００の処理動作のおおよその流れである。
【００７０】
図１５に、監視者メンバが障害対策支援システム１００から障害履歴通知メールを受信した以降に、管理者メンバによって実行される操作手続の流れを示す。
【００７１】
前述したように、管理者メンバは、メール送信部１０６より障害履歴通知メールを受信する（ステップ１５０１）。管理者は過去の障害発生事例で通知された対策方法、過去のメールのやりとり、ログ情報を参考に障害対策を実施する（ステップ１５０２）。
【００７２】
障害対策後、管理者メンバは、通知された過去の障害発生事例が有益であったかどうか、また、今後はより詳細な情報を通知して欲しいか等、通知された情報について検討する（ステップ１５０３）。通知内容が有益であったと判断した場合は、肯定結果を得て処理を終了する。
【００７３】
一方、ステップ１５０３で、管理者メンバが、同様の障害の発生時により良い情報が通知されるように通知情報の内容を見直したいと考えた場合（否定結果の場合）、対策方法の追加や編集、監視対象文字列の見直し等を行う（ステップ１５０４）。
【符号の説明】
【００７４】
１００…障害対策支援システム、１０１…メール受信部、１０２…メール解析部、１０３…ログ解析部、１０４…メール／ログ履歴登録部、１０５…障害対策履歴検索部、１０６…メール送信部、１０７…障害対策履歴参照／対策詳細登録部、１０８…メールフォーマットファイル、１０９…ログ監視情報登録部、１１０…機能別ログ配置場所ＤＢ、１１１…機能別監視文字ＤＢ、１１２…障害情報蓄積ＤＢ部、１１３…メールＤＢ、１１４…ログＤＢ、１１５…メール／ログ関連ＤＢ、１１６…対策方法ＤＢ、１１７…取得ログ配置フォルダ、１１８…外部システム、１１９…監視システム。
【技術分野】
【０００１】
本発明は、新たに発生した障害の解決を過去の障害事例に基づいて支援するシステムに関する。
【背景技術】
【０００２】
コンピュータシステムの運用管理では、障害の発生原因、その特定方法、その対策方法等に関するノウハウの蓄積と伝達が重要とされる。従来、ノウハウの蓄積や伝達は、自身の経験による獲得、口頭による伝達、「障害管理シート」と呼ばれる障害の原因と対策をまとめたドキュメント等により行われている。また、システム障害の発生は、監視システムからシステム管理者に宛てた障害通知メールにより通知され、通知を受けたシステム管理者が障害内容の特定と回復作業を行う仕組みになっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平８−３１４７５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
コンピュータシステムに障害が発生した場合、システム管理者は、まず障害の適切な回復方法を決定する必要がある。この際、システム管理者は、障害が発生した機能の特定、障害が発生した機能のログの参照、「障害管理シート」のようなドキュメントの参照を実行し、場合によっては、過去に同様の障害が発生した際のメールのやりとりを検索する等の作業を実行する。そして、障害の発生原因の特定後に障害の回復手順を確立する作業手順が採用されている。
【０００５】
しかし、このような従来手法では、障害対策の正しさや障害回復までの早さがシステム管理者個人のスキルに依存しやすい。
【０００６】
例えばログを参照して障害対策を検索しようとしても、ログには、障害の発生原因以外の情報（例えばシステムの稼働状況等を記した正常なログ）も数多く含まれている。従って、ログの中から、障害の発生原因が出力されている箇所をいかに早く特定できるかは、システム管理者個人のスキルに依存することが多い。更に、障害の発生原因を特定できるほどの正確なログがそもそも出力されていないこともある。その場合は、経験から障害発生原因を推測する必要があるが、経験には大きな個人差が存在する。
【０００７】
また、過去にやりとりされたメールには、障害が回復されるまでの知識その他の有益な情報が多く含まれることが経験的に知られている。しかし、経験の浅いメンバの場合には、該当するメールを探しきれない可能性もある。
【０００８】
そこで、本発明では、システム管理者個人のスキル差を前提としながらも、障害回復の早さと正確さのばらつきを少なくできる機能を提供することを目的とする。
【課題を解決するための手段】
【０００９】
この目的のため、本発明は、障害発生時に出力される障害ログのうち障害の特定に有益な部分（概要）と障害が回復されるまでのメールのやりとり等とを関連付けて自動的に蓄積する。そして、同様の障害が後日発生した場合には、発生した障害に基づいて蓄積データを検索し、関連する過去の障害ログの概要をシステム管理者に自動的に通知する仕組みを提案する。
【発明の効果】
【００１０】
本発明によれば、システム管理者が複数の作業を経て取得する必要があった情報を、障害通知メールを通じて自動的に通知することができる。これにより、作業の手間を大幅に軽減することができる。また、システム管理者は、障害通知メールを通じて過去の対策例に容易にアクセスできるため、障害回復の早さと正確さのばらつきを少なくすることができる。
【図面の簡単な説明】
【００１１】
【図１】形態例に係る障害対策支援システムの概略構成を示す図である。
【図２】障害通知メールの一例を示す図である。
【図３】メールフォーマットの一形態例を示す図である。
【図４】メール解析結果ファイルの一形態例を示す図である。
【図５】機能別ログ配置場所ＤＢのデータ構成例を示す図である。
【図６】機能別監視文字ＤＢのデータ構成例を示す図である。
【図７】ログ解析結果ファイルの一形態例を示す図である。
【図８】メールＤＢのデータ構成例を示す図である。
【図９】ログＤＢのデータ構成例を示す図である。
【図１０】メール／ログ関連ＤＢのデータ構成例を示す図である。
【図１１】対策方法ＤＢのデータ構成例を示す図である。
【図１２】障害履歴通知メールの形態例を示す図である。
【図１３】障害対策履歴参照／対策詳細登録画面の一形態例を示す図である。
【図１４】障害通知メールの受信から障害履歴の通知までに実行される処理手順の概要を示すフローチャートである。
【図１５】システム管理者による障害通知メールの受信から障害対策の完了までに実行される作業手順の概要を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、発明に係る障害対策支援システムの形態例を図面に基づいて説明する。なお、図面は、専ら発明の説明を目的として作図したものであり、発明の範囲を限定するものではない。
【００１３】
（１）システムの全体構成
図１に、形態例に係る障害対策支援システム１００の全体構成例を示す。障害対策支援システム１００は、メール受信部１０１、メール解析部１０２、ログ解析部１０３、メール／ログ履歴登録部１０４、障害対策履歴検索部１０５、メール送信部１０６、障害対策履歴参照／対策詳細登録部１０７、メールフォーマットファイル１０８、ログ監視情報登録部１０９、機能別ログ配置場所ＤＢ１１０、機能別監視文字ＤＢ１１１、障害情報蓄積ＤＢ部１１２、取得ログ配置フォルダ１１７で構成される。
【００１４】
ここで、メール受信部１０１は、当システム宛のメールの受信に用いられる。メール解析部１０２は、受信したメールが障害通知メールか否かを解析する処理部である。解析結果はメール解析結果ファイルとして出力される。ログ解析部１０３は、障害通知メールと解析されたメールを解析対象として、メール内に障害解析に有益なログが含まれるか否かを解析する処理部である。解析結果はログ解析結果ファイルとして出力される。
【００１５】
メール／ログ履歴登録部１０４は、メール解析結果ファイルとログ解析結果ファイルの情報を、障害情報蓄積ＤＢ部１１２の対応するデータベースに登録する処理部である。障害対策履歴検索部１０５は、受信したメールが障害通知メールであった場合に、当該メールや障害ログの解析結果に基づいて、関連性が高い過去の障害履歴を検索する処理部である。メール送信部１０６は、検索された障害履歴を障害履歴通知メールとしてシステム管理者に通知する処理部である。
【００１６】
障害対策履歴参照／対策詳細登録部１０７は、検索された障害履歴とそれに紐付けられた対策方法の参照処理と編集処理を分担する処理機能部である。メールフォーマットファイル１０８は、受信したメールの解析時に参照するフォーマット情報が格納されるストレージ領域である。ログ監視情報登録部１０９は、機能別ログ配置場所ＤＢ１１０及び機能別監視文字ＤＢ１１１に対する情報の登録処理を分担する処理部である。
【００１７】
機能別ログ配置場所ＤＢ１１０と機能別監視文字ＤＢ１１１は、ログファイルの解析に使用する情報を格納するデータベースである。なお、機能別ログ配置場所ＤＢ１１０には、外部システムにおけるログファイル（障害ログ）の格納場所が機能別に格納される。また、機能別監視文字ＤＢ１１１には、監視対象とする文字列が機能別に格納される。障害情報蓄積ＤＢ部１１２は、解析されたメール情報と、解析されたログ情報を蓄積するストレージ装置又はストレージ領域である。取得ログ配置フォルダ１１７は、外部システムのログファイルをローカルエリアに保存するために使用されるストレージ装置又はストレージ領域である。
【００１８】
なお、障害対策支援システム１００には、ネットワーク経由で障害対策を支援したい外部システム１１８と、監視対象の外部システム１１８が正常に動作しているか否かを監視する監視システム１１９とが接続されている。なお、支援対象としての外部システム１１８の数は１つに限らず、複数の場合も考えられる。一方、監視システム１１９は、外部システム１１８に対して一対一に配置されても良いし、複数の外部システム１１８に対して１つ配置されても良い。
【００１９】
ここで、監視システム１１９は、外部システム１１８のログ、ジョブの終了コード、ＯＳ（オペレーションシステム）のイベントログ等に基づいて障害の発生を検知し、管理者メンバに対して障害通知メールを送信するように機能する。
【００２０】
図２に、障害通知メールの一例を示す。図２に示すように、障害通知メールには、障害が発生した機能、障害が発生した時間、監視システムが検知した情報等が記述される。例えば送信元「From」には監視システムのメールアドレスが記述され、宛先「To」には管理者メンバのメールアドレスが記述され、タイトル「Subject」には障害が発生した機能、本文「body」には検知された情報の概要が記される。
【００２１】
ところで、この形態例の場合、障害通知メールは、監視システム１１９から管理者メンバと障害対策支援システム１００の両方に宛てて送信される。このため、前述したメール受信部１０１では、障害通知メールを受信することができる。なお、障害対策支援システム１００に対する障害通知メールの送信は、管理者用メーリングリストに当システムを加える等の方法により実現することができる。
【００２２】
（２）各部の詳細動作
続いて、障害対策支援システムを構成する各部において実行される詳細動作の内容を説明する。
（２−１）メール解析部の詳細動作
メール解析部１０２は、受信したメールとメールフォーマットファイル１０８とを比較することにより、受信したメールが監視システム１１９から受信された障害通知メールか否かを判定する処理を実行する。障害通知メールであると判定された場合、メール解析部１０２は、障害が発生した機能が何かをメールから取得し、取得された情報をログ解析部１０３に渡す機能を提供する。一方、障害通知メールであると判定された場合、メール解析部１０２は、受信したメールをメール／ログ履歴登録部１０４に渡す機能を提供する。
【００２３】
図３にメールフォーマットの一例を示す。メールフォーマットには、障害通知メールの形式情報（例えば送信元「From」、送信先「To」、タイトル、本文がどのような形式となっているか）と、障害通知メールから障害が発生した機能を抜き出すために必要な情報とが記述されている。ここでは、図２に示す障害通知メールと、図３に示すメールフォーマットを使用して解析処理を実行する例を考える。
【００２４】
最初に、メール解析部１０２は、受信したメールがメールフォーマットと一致するか否かを確認する。この場合、メール解析部１０２は、障害通知メール（図２）の「From」、「To」と、メールフォーマット（図３）の「From」、「To」とを比較する。両者が一致する場合、受信されたメールには、メールフォーマット（図３）と同じメールアドレスが記述されていることが分かる。
【００２５】
次に、メール解析部１０２は、「Subject」の５文字目がアルファベットで、続く４文字が数値で記載されているか否かを判定する。図２の例の場合、先頭から５文字目の文字が「Ｂ」であり、続く４文字が「１００５」である。以上の通り、図２の受信されたメールは、「From」、「To」、「Subject」の全てがメールフォーマット（図３）と一致する。この一致検出により、メール解析部１０２は、図２に示すメールが監視システム１１９から発せられた障害通知メールであると判断する。
【００２６】
次に、メール解析部１０２は、受信されたメールの「Subject」の先頭から５文字目から９文字目までに位置する計５文字を障害が発生した機能の識別子（ＩＤ）として抽出する。なお、この形態例に係る監視システム１１９には、該当位置に対して、障害の発生した機能を特定する識別子（ＩＤ）を付与する機能が搭載されているものとする。図２の場合、「Ｂ１００５」が識別子（ＩＤ）として抽出される。なお、この形態例の場合には、英数字と４文字の数字で識別子（ＩＤ）を定義しているが、言うまでもなくこれは一例である。また、識別子の配置場所についても一例である。
【００２７】
このように、障害が発生した機能を特定する識別子（ＩＤ）が抽出されると、メール解析部１０２は、メール解析結果ファイルを生成する。図４に、メール解析結果ファイルの一例を示す。メール解析結果ファイルは、障害発生機能欄４０１と、受信したメールの全文４０２で構成される。なお、受信したメールが監視システム１１９から受信した障害通知メールでなかった場合、障害発生機能欄４０１は空欄のままとする。ここで、受信メールの全文４０２を付加するのは、後で説明するメールＤＢ１１３にメールを登録するためである。
【００２８】
メール解析部１０２は、障害通知メールであると判定した場合、メール解析結果ファイル（図４）をログ解析部１０３に出力し、障害通知メールでなかった場合、障害発生機能欄４０１が空欄のメール解析結果ファイルをメール／ログ履歴登録部１０４に出力する。なお、障害通知メールの判定に使用するメールフォーマットの作成とメールフォーマットファイル１０８への登録は、監視対象システム１００の稼動前に、システム管理者によって事前に行われる。
【００２９】
（２−２）ログ解析部の詳細動作
ログ解析部１０３は、外部システム１１８にアクセスして、障害通知メールに対応するログファイル（障害ログ）から障害の発生原因を特定するために有益な情報が含まれていないか否かを検索する処理を実行する。
【００３０】
この動作に先立ち、ログ解析部１０３は、メール解析結果ファイル（図４）を受信すると、その障害発生機能欄４０１の内容に基づいて障害が発生した機能を識別子（ＩＤ）により特定する。
【００３１】
障害が発生した機能が特定されると、ログ解析部１０３は、当該機能をキーとして機能別ログ配置場所ＤＢ１１０を参照し、特定した機能に対応するログの配置場所を取り出す。
【００３２】
図５に、機能別ログ配置場所ＤＢ１１０のデータ構造例を示す。機能別ログ配置場所ＤＢ１１０には、機能ＩＤ５０１に対応付けるように、配置サーバ５０２、取得方法５０３、配置サーバに対するログインユーザ５０４、パスワード５０５、ログファイル名５０６が保持されている。
【００３３】
ログ解析部１０３は、この機能別ログ配置場所ＤＢ１１０の記述内容に従い、障害が発生した外部システム１１８に所定の方法でログインし、ログファイルを障害対策支援システム１００のローカルフォルダである取得ログ配置フォルダ１１７に配置する。ただし、外部システム１１８の種類やログファイルの配置場所等により、ログファイルの取得方法には多くのパターンがある。このため、図５に示す機能別ログ配置場所ＤＢ１１０が保持する情報は一例である。
【００３４】
次に、ログ解析部１０３は、外部システム１１８から取得したログファイルをキーワードで検索し、障害の発生原因を特定するために有益な情報を取得する処理を実行する。この際、ログ解析部１０３は、機能別監視文字ＤＢ１１１より、機能ＩＤについて登録されている任意の文字列を検索用のキーワードとして取り出す。
【００３５】
図６に、機能別監視文字ＤＢ１１１のデータ構造例を示す。機能別監視文字ＤＢ１１１には、機能ＩＤ６０１に対応付けるように、ログファイルに検索をかけるためのキーワードである監視対象文字列６０２と、監視対象文字６０２がヒットした箇所から前後何行のログを合わせて取得するかを指定する前後取得行数６０３が保持されている。
【００３６】
この形態例の場合、特定の機能ＩＤに限定せずに使用するキーワードを、機能ＩＤ６０１に“−”を設定することで登録できるものとする。従って、図６の場合、「Exception」、「エラーが発生しました。」、「処理をスキップします。」の３つが、全ての機能ＩＤに共通に使用する監視対象文字として登録されている。
【００３７】
ログ解析部１０３は、機能ＩＤ６０１を指定して取得できた複数の監視対象文字列６０２と、全機能に共通する監視対象文字列を使用してログファイルを検索する。そして、ログファイル内に監視対象文字と同じ文字列が存在した場合、その監視対象文字の一覧と、前後取得行数６０３により指定された行数分の文字列をログ情報として取得する。このログ情報が、特許請求の範囲における「障害履歴の概要」の一部に対応する。図６の場合には、監視対象文字列が出現する行と、その前後各１行の計３行が取得範囲であることを意味している。
【００３８】
このように、前後の行もログ情報の取得範囲として指定するのは、監視対象文字列の近くには障害対策に有益な情報が出現する可能性が高いためである。また、取得する範囲を限定することにより、障害対策時おける作業の効率性を高めるためである。例えば障害通知メールに対応する障害ログをそのまま蓄積する場合、たとえ関連する障害ログにアクセスできたとしても、障害原因に関連する障害ログを、人手を解して実行する必要がある。
【００３９】
なお、この形態例の場合には、前後各１行を含めた計３行を指定しているが、取得範囲を更に増やすこともできる。ただし、取得範囲を増やしすぎると閲覧負荷も増加する。従って、取得範囲は、ログ監視情報登録部１０９を通じて変更できることが望ましい。また、取得範囲は、監視対象文字列が出現する行に対して前方側だけ又は後方側だけとしても良い。
【００４０】
図７に、ログ解析部１０３によって実行されたキーワード検索の結果を書き出したログ解析結果ファイルの一例を示す。ログ解析結果ファイルには、障害の発生した機能を特定する機能ＩＤ７０１に対応付けるように、ヒットした監視対象文字列７０２と、検索にヒットした行とその前後の行から取得される前後ログ情報７０３と、検索したログファイルのローカル配置場所である元ログファイル名７０４とが保持されている。
【００４１】
なお、１つのログの中から同一の監視対象文字が複数回ヒットした場合も、ヒットした全ての箇所について同様の情報が保存される。図７の場合には、「納品書送付履歴がありません。」が２回ヒットした例を表している。このような保存形態を採用するのは、同じ原因で複数回の障害が発生していることを管理者に通知するためである。なお、ログ解析部１０３は、ログファイル内にヒットした監視文字が存在しない場合でも、機能ＩＤ以外の情報項目が全て空白のログ解析結果ファイルを作成するものとする。
【００４２】
このようにログ解析結果ファイル（図７）の作成が完了すると、ログ解析部１０３は、作成されたログ解析結果ファイルを、メール解析部１０２から受け取ったメール解析結果ファイル（図４）と共に、メール／ログ履歴登録部１０４に出力する。
【００４３】
（２−３）メール／ログ履歴登録部の詳細動作
メール／ログ履歴登録部１０４は、受け取ったメール解析結果ファイル（図４）と、ログ解析結果ファイル（図７）の内容を障害情報蓄積ＤＢ部１１２に登録する処理を実行する。なお、障害情報蓄積ＤＢ部１１２は、メールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５、対策方法ＤＢ１１６で構成される。メール/ログ履歴登録部１０４は、これら４つのＤＢ（データベース）のうちメールＤＢ１１３、ログＤＢ１１４及びメール／ログ関連ＤＢ１１５の３つにデータを登録する機能を分担する。
【００４４】
また、メール／ログ履歴登録部１０４は、データの登録後、今回登録したログＩＤの一覧を障害履歴検索部１０５に引き渡す処理を実行する。以下、メール／ログ履歴登録部１０４によるデータの登録先となる３つのテーブルのデータ構造を図８〜図１０に示す。
【００４５】
図８は、メールＤＢ１１３のデータ構造例である。メールＤＢ１１３は、障害対策支援システム１００が受信した全てのメール（メール解析結果ファイル）を蓄積するデータベースである。メールＤＢ１１３は、各メールを管理するために、一意のコードであるメールＩＤ８０１を振り出すことによりメールの情報を管理する。メールＤＢ１１３には、メールＩＤ８０１に対応付けるように、メール解析結果ファイル（図４）のメール本文４０２の情報が登録される。具体的には、メール本文８０７と、メールのヘッダ情報を構成する基本的な情報８０２〜８０６を個別に保持する。ただし、後述する障害対策履歴参照／対策詳細登録部１０７において、過去の障害発生メールのやりとりをツリー形式で見れるように、メールのツリーを作成するための情報である「In-Replay-To」ヘッダ８０４と、「References」ヘッダ８０５は必ず個別に保持しておく。この情報は必須の情報である。
【００４６】
図９は、ログＤＢ１１４のデータ構造例である。ログＤＢ１１４は、ログ解析結果ファイル（図７）を蓄積するデータベースである。ログＤＢ１１４は、各ログを管理するために、一意のコードであるログＩＤ９０１を振り出すことによりログの情報を管理する。ログＤＢ１１４には、ログＩＤ９０１に対応付けるように、機能ＩＤ９０２、監視対象文字列９０３、前後ログ情報９０４、元ログファイル９０５が登録される。なお、機能ＩＤ９０２は、図７に示すログ解析結果ファイルの機能ＩＤ７０１に対応する。同様に、監視対象文字列９０３は図７における監視対象文字列７０２に対応し、前後ログ情報９０４は図７における前後ログ情報７０３に対応し、元ログファイル９０５は図７における元ログファイル７０４に対応する。
【００４７】
図１０は、メール／ログ関連ＤＢ１１５のデータ構造例である。メール／ログ関連ＤＢ１１５は、メール／ログ履歴登録部１０４に対してメール解析結果ファイル（図４）と、ログ解析結果ファイル（図７）が同時に渡された場合に、これら２つのファイルを関連付ける情報を登録するデータベースである。図１０に示すように、メール／ログ関連ＤＢ１１５は、メールＩＤ１００１と、ログＩＤ１００２と、この２つの関連に対して対策方法（後述する）を紐付けるための対策方法ＩＤ１００３とを保持している。
【００４８】
（２−４）障害対策履歴検索部の詳細動作
障害対策履歴検索部１０５は、メール解析結果ファイル（図４）とログ解析結果ファイル（図７）とに基づいて、過去の障害履歴を検索する処理機能を実行する。障害対策履歴検索部１０５は、メールＤＢ１１３と、ログＤＢ１１４と、メール／ログ関連ＤＢ１１５を関連付けた仮想テーブルを検索対象として、ログ解析結果ファイル（図７）の機能ＩＤ７０１と監視対象文字列７０２を検索キーにした検索動作を実行する。この検索動作により、障害対策履歴検索部１０５は、メールＩＤとログＩＤの組み合わせで特定される障害履歴を取得する。
【００４９】
複数の取得結果が検出された場合、障害対策履歴検索部１０５は、対策方法ＩＤ１００３が紐付いている障害履歴、又は、対策方法ＩＤ１００３に紐付けられている対策方法ＤＢ１１６の重要度１１０３が高い障害履歴を優先的に取得する手法を採用する。図１１に、対策方法ＤＢ１１６のデータ構造例を示す。対策方法ＤＢ１１６には、対策方法の登録時に対策方法ＩＤが振り出され、この対策方法ＤＢ１１６に対応付けるように、対策方法１１０２と重要度１１０３とが関連付けられて保存されている。因みに、対策方法１１０２と重要度１１０３は、システム管理者によって個別に登録される情報である。
【００５０】
障害対策履歴検索部１０５は、取得できた情報を過去の障害履歴として管理者メンバに通知する。ただし、取得できた情報量が多い場合、メールでの通知が困難な場合も考えられる。そこで、この形態例の場合には、障害対策履歴検索部１０５は、取得した情報を参照できる画面にアクセスするための情報を通知する方法を採用する。例えば参照画面をインターネット上のＷＥＢ画面で実現する場合、障害対策履歴検索部１０５は、取得したメールＩＤとログＩＤをＵＲＬのＧＥＴパラメータに設定し、ＵＲＬの一覧形式により通知する。このＵＲＬの一覧はメール送信部１０６に渡され、管理者メンバに対して障害履歴通知メールとして送付される。
【００５１】
（２−５）メール送信部の詳細動作
図１２に、メール送信部１０６が送信する障害履歴通知メールの一例を示す。障害履歴通知メールには、障害対策履歴検索部１０５によって取得されたメールＩＤとログＩＤの組み合わせをパラメータとするＵＲＬが[過去履歴]として一覧される。一方、障害履歴通知メールには、メール／ログ履歴登録部１０４により渡されるメールＩＤをパラメータとするＵＲＬが[今回ログ]として一覧表示される。このように、今回ログと過去履歴とを区別することにより、メールを受け取った管理者メンバが情報を参照しやすい構造を実現する。なお、[今回ログ]については、メールＩＤだけをパラメータとするのは（図１２参照）、メールに対応する全てのログを表示する必要があり、特定のログだけに限定する必要がないためである。
【００５２】
なお、この形態例の場合には、障害履歴通知メールを、[今回ログ]にアクセスするためのＵＲＬと、[過去履歴]にアクセスするためのＵＲＬと、対応する障害通知メールの情報（ヘッダ及び本文の全てを含む。）とで形成する場合について説明したが、障害通知メールを特定できるのであれば、必ずしも図１２に示す構成を採用する必要はない。例えば障害履歴通知メールを、[今回ログ]にアクセスするためのＵＲＬと、[過去履歴]にアクセスするためのＵＲＬだけで構成し、メールの「Subject」等に障害通知メールを特定する情報を記述したり、メールの本文に障害通知メールにアクセスにするためのＵＲＬ等を記述しても良い。
【００５３】
（２−６）障害対策履歴参照／対策詳細登録部の詳細動作
障害対策履歴参照／対策詳細登録部１０７は、管理者メンバ側の端末に対するユーザインターフェース機能を提供する。前述したように、管理者メンバには、障害履歴通知メール（図１２）として過去の障害履歴等がＵＲＬとして通知される。障害対策履歴参照／対策詳細登録部１０７は、管理者メンバ側の端末に過去の障害履歴に対する情報をネットワーク経由で提供するためのユーザインターフェース機能を提供する。
【００５４】
図１３に、障害対策履歴参照／対策詳細登録部１０７によって管理者メンバ側に提供される表示画面例を示す。この画面は、障害履歴通知メール（図１２）において、[過去履歴]のＵＲＬの一つがクリックされた場合の表示例である。図１３に示す画面例は、メール履歴参照欄１３０３、ログ履歴参照欄１３０４、登録／変更ボタン１３０５を有している。なお、ログ履歴参照欄１３０４は、障害対策コメント登録欄１３０１と重要度登録欄１３０２を一組とする１つ又は複数の表示欄で構成される。
【００５５】
また、ログ履歴参照欄１３０４には、監視文字毎に取得ログ配置フォルダ１１７内のログファイルにアクセスするためのリンク情報１３０６が埋め込まれた状態で表示される。このリンク情報１３０６をクリックすると、対応するログファイルの全体を取得することができる。
【００５６】
なお、ログ履歴参照欄１３０４に表示する情報は、通知されたメールＩＤとログＩＤの組み合わせに基づいて、メールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５、対策方法ＤＢ１１６を検索することにより取得することができる。
【００５７】
また、メールＤＢ１１３から取得できたメールＩＤ８０１に紐付けられたメールはツリー情報として取得しておく。メールのツリー化は、メールのヘッダ情報を構成する「In-Replay-To」と「References」に基づいて実行する。因みに、「In-Replay-To」と「References」は、メールＤＢ１１３に個別に保持されている。また、ツリー化を実現するための詳細な方法は周知であるため、ここでは説明を省略する。ツリー化されたメールは、図１３に示すように、メール履歴参照欄１３０３に一覧的に表示される。
【００５８】
こここで理解すべき点は、図１３に示す画面は、１つの障害通知メールに対して自動的に生成される点である。従って、管理者メンバは、１つの障害通知メールの発生時に、過去の障害通知メール、それらに紐付けられているメールのやりとり、ログ情報の抜粋（３行分）、元のログファイル、登録された対策情報を１組として取得することが可能になる。すなわち、障害対策に必要な情報を１まとめにして一度に確認することができる。
【００５９】
また、障害対策履歴参照／対策詳細登録部１０７は、図１３に示す画面を通じて受け付けた障害対策コメント登録欄１３０１及び障害の重要度登録欄１３０２に対する情報の入力又は選択に基づいて、入力情報を対策方法ＤＢ１１６に保存する機能も提供する。情報の登録又は変更は、登録／変更ボタン１３０５のクリック操作の受け付けにより確定する。
【００６０】
（３）システム全体における処理動作の流れ
図１４に、障害対策支援システム１００において実行される処理動作のうち、障害履歴通知メールが管理者メンバに送信されるまでの動作の概要を示す。
【００６１】
まず、障害対策支援システム１００は、当システム宛の障害通知メールをメール受信部１０１で受信する（ステップ１４０１）。
【００６２】
メール解析部１０２は、受信したメールとメールフォーマットとが一致するか否かを判定する（ステップ１４０２）。
【００６３】
ここで、メールフォーマットと一致した場合（肯定結果の場合）、メール解析部１０２は、受信したメールから障害が発生した機能を特定し、メール解析結果ファイル（図４）を作成する。一方、メールフォーマットと一致しない場合（否定結果の場合）、メール解析部１０２は、監視システム１１９からの障害通知メールではないと判断し、ログの検索（ステップ１４０３）は実施しない。
【００６４】
ステップ１４０２で障害が発生した機能が特定された場合、ログ解析部１０３は、特定された機能のログファイルを取得し、ログファイル内を機能毎の監視対象文字で検索する。この検索により、ログ解析部１０３は、障害発生原因を特定するために有益と考えられる情報を取得し、ログ解析結果ファイル（図７）を作成する（ステップ１４０３）。
【００６５】
ステップ１４０２で作成されたメール解析結果ファイル（図４）と、ステップ１４０３で作成されたログ解析結果ファイル（図７）の情報は、メール／ログ履歴登録部１０４により障害情報蓄積ＤＢ部１１２のメールＤＢ１１３、ログＤＢ１１４、メール／ログ関連ＤＢ１１５に登録される（ステップ１４０４）。
【００６６】
なお、ステップ１４０３で実行されたログ内の検索において、監視対象文字列がヒットしない場合でも、ログ解析結果ファイル（図７）は保存される。この場合、ログ解析結果ファイル（図７）には機能ＩＤ７０１しか設定されず、監視対象文字列７０２、前後ログ情報７０３、元ログファイル７０４には空情報が登録される。これは、登録したメール情報がどの機能に関するものかを特定するためである。また、ログＤＢ１１４でも機能ＩＤ９０２を登録するためである。
【００６７】
また、ステップ１４０２の判定結果が否定結果であった場合、メール／ログ履歴登録部１０４は、受信したメールをメールＤＢ１１３に登録する。このメール情報は、障害機能とは結びつかないが、監視システム１１９から発せられた障害通知メールに対してツリーで紐付ける可能性があると考えられるためである。
【００６８】
以上、ステップ１４０４の登録処理が完了すると、障害対策履歴検索部１０５が、障害の発生した機能とログファイル内を検索してヒットした監視対象文字列とをキーワードに使用して障害情報蓄積ＤＢ部１１２を検索し、過去に同様の障害が発生した事例がないか否か確認する（ステップ１４０５）。
【００６９】
ステップ１４０５で過去の障害発生事例が検索された場合、その情報を管理者メンバに通知する（ステップ１４０６）。以上が、障害対策支援システム１００の処理動作のおおよその流れである。
【００７０】
図１５に、監視者メンバが障害対策支援システム１００から障害履歴通知メールを受信した以降に、管理者メンバによって実行される操作手続の流れを示す。
【００７１】
前述したように、管理者メンバは、メール送信部１０６より障害履歴通知メールを受信する（ステップ１５０１）。管理者は過去の障害発生事例で通知された対策方法、過去のメールのやりとり、ログ情報を参考に障害対策を実施する（ステップ１５０２）。
【００７２】
障害対策後、管理者メンバは、通知された過去の障害発生事例が有益であったかどうか、また、今後はより詳細な情報を通知して欲しいか等、通知された情報について検討する（ステップ１５０３）。通知内容が有益であったと判断した場合は、肯定結果を得て処理を終了する。
【００７３】
一方、ステップ１５０３で、管理者メンバが、同様の障害の発生時により良い情報が通知されるように通知情報の内容を見直したいと考えた場合（否定結果の場合）、対策方法の追加や編集、監視対象文字列の見直し等を行う（ステップ１５０４）。
【符号の説明】
【００７４】
１００…障害対策支援システム、１０１…メール受信部、１０２…メール解析部、１０３…ログ解析部、１０４…メール／ログ履歴登録部、１０５…障害対策履歴検索部、１０６…メール送信部、１０７…障害対策履歴参照／対策詳細登録部、１０８…メールフォーマットファイル、１０９…ログ監視情報登録部、１１０…機能別ログ配置場所ＤＢ、１１１…機能別監視文字ＤＢ、１１２…障害情報蓄積ＤＢ部、１１３…メールＤＢ、１１４…ログＤＢ、１１５…メール／ログ関連ＤＢ、１１６…対策方法ＤＢ、１１７…取得ログ配置フォルダ、１１８…外部システム、１１９…監視システム。
【特許請求の範囲】
【請求項１】
受信したメールが障害通知メールである場合、障害が発生した機能を特定する情報を受信したメールから抜き出す手段と、
受信したメールが障害通知メールである場合、事前に定めた文字列により、当該障害通知メールに対応する障害ログを検索する手段と、
受信した障害通知メールと対応する障害ログについての検索結果をデータベースに登録する手段と、
受信した障害通知メールの情報と対応する障害ログに対応する検索結果に基づいて過去の障害履歴を検索する手段と、
検索された過去の障害履歴の概要にアクセスするための情報と今回の障害ログにアクセスするための情報とを管理者端末に通知する手段と
を有することを特徴とする障害対策支援システム。
【請求項２】
前記障害履歴の概要は、障害ログの検索時にヒットした文字列が存在する行の情報と、その前及び又は後に位置する少なくとも１行の情報である
ことを特徴とする請求項１に記載の障害対策支援システム。
【請求項３】
前記管理者端末から前記障害履歴の概要の読み出しを受け付けた場合において、障害通知メールと障害履歴の概要との組み合わせについて登録されているコメント文が存在するとき、当該コメント文をデータベースより検索して前記管理者端末に通知する手段
を更に有することを特徴とする請求項１に記載の障害対策支援システム。
【請求項４】
前記コメント文に優先度が登録されている場合、前記コメント文と共に優先度を前記管理者端末に通知する
ことを特徴とする請求項３に記載の障害対策支援システム。
【請求項５】
検索された過去の障害履歴の概要にアクセスするための前記情報と、今回の障害ログにアクセスするための前記情報と、前記障害通知メールの情報とを合成した障害履歴通知メールを管理者端末に通知する
ことを特徴とする請求項１に記載の障害対策支援システム。
【請求項６】
前記障害通知メールを一意に特定する識別子と、前記障害通知メールについて検出された１つ又は複数の障害ログを一意に特定する識別子との組み合わせに基づいて、過去の障害履歴の概要にアクセスするための前記情報と今回の障害ログにアクセスするための前記情報を取得する
ことを特徴とする請求項１に記載の障害対策支援システム。
【請求項１】
受信したメールが障害通知メールである場合、障害が発生した機能を特定する情報を受信したメールから抜き出す手段と、
受信したメールが障害通知メールである場合、事前に定めた文字列により、当該障害通知メールに対応する障害ログを検索する手段と、
受信した障害通知メールと対応する障害ログについての検索結果をデータベースに登録する手段と、
受信した障害通知メールの情報と対応する障害ログに対応する検索結果に基づいて過去の障害履歴を検索する手段と、
検索された過去の障害履歴の概要にアクセスするための情報と今回の障害ログにアクセスするための情報とを管理者端末に通知する手段と
を有することを特徴とする障害対策支援システム。
【請求項２】
前記障害履歴の概要は、障害ログの検索時にヒットした文字列が存在する行の情報と、その前及び又は後に位置する少なくとも１行の情報である
ことを特徴とする請求項１に記載の障害対策支援システム。
【請求項３】
前記管理者端末から前記障害履歴の概要の読み出しを受け付けた場合において、障害通知メールと障害履歴の概要との組み合わせについて登録されているコメント文が存在するとき、当該コメント文をデータベースより検索して前記管理者端末に通知する手段
を更に有することを特徴とする請求項１に記載の障害対策支援システム。
【請求項４】
前記コメント文に優先度が登録されている場合、前記コメント文と共に優先度を前記管理者端末に通知する
ことを特徴とする請求項３に記載の障害対策支援システム。
【請求項５】
検索された過去の障害履歴の概要にアクセスするための前記情報と、今回の障害ログにアクセスするための前記情報と、前記障害通知メールの情報とを合成した障害履歴通知メールを管理者端末に通知する
ことを特徴とする請求項１に記載の障害対策支援システム。
【請求項６】
前記障害通知メールを一意に特定する識別子と、前記障害通知メールについて検出された１つ又は複数の障害ログを一意に特定する識別子との組み合わせに基づいて、過去の障害履歴の概要にアクセスするための前記情報と今回の障害ログにアクセスするための前記情報を取得する
ことを特徴とする請求項１に記載の障害対策支援システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１０−２５７０６６（Ｐ２０１０−２５７０６６Ａ）
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願番号】特願２００９−１０４１７３（Ｐ２００９−１０４１７３）
【出願日】平成２１年４月２２日（２００９．４．２２）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願日】平成２１年４月２２日（２００９．４．２２）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]