(57)【特許請求の範囲】
【請求項１】
障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログに基づいて障害予兆を検出する障害予兆検出システムであって、
上記プログラムの障害予兆を検出する範囲を規定する処理監視単位の名称と障害予兆の有無の判断に使うログを検出定義として予め作成して登録しておく検出定義作成装置と、上記ソフトウェアのプログラムが実行されるたびに出力されるログを取得し、その取得したログに対して、上記検出定義作成装置で作成された検出定義に基づいて障害予兆を検出するログ解析装置とを備え、
上記ログ解析装置は、上記プログラムの障害に紐づいたエラーログを検出するとともに、上記検出定義作成装置において予め作成された検出定義に基づき、上記プログラムの処理監視単位ごとに、本来正常な処理が実行された場合に発生すると予定されている検出ログの発生の有無を解析し、上記検出ログが発生しない場合には、これを障害予兆として検出することを特徴とする障害予兆検出システム。
【請求項２】
試験情報解析装置を備え、上記試験情報解析装置は、上記ソフトウェアのプログラムの処理監視単位ごとに試験内容を定義する試験情報を入力する試験情報入力部と、上記試験情報入力部から入力された上記試験情報に基づいて、上記ソフトウェアのプログラムが処理監視単位ごとに所定通りに動作するか否かの試験が実施される際に、その処理監視単位ごとのプログラム実行による試験結果が正常となる場合に得られるログ情報を抽出する試験情報解析部と、上記試験情報解析部で抽出された上記ログ情報を上記検出定義作成装置に対して検出定義の情報として送信する試験情報送信部と、を含むことを特徴とする請求項１に記載の障害予兆検出システム。
【請求項３】
上記試験情報解析装置の試験情報入力部に入力される試験情報に対して、処理監視単位ごとのプログラムのソースコードの開始時点を示す開始ログと終了時点を示す終了ログの情報を追加するログ追加処理部を備えることを特徴とする、請求項２に記載の障害予兆検出システム。
【請求項４】
上記ログ解析装置により検出ログが発生していないと解析された場合でも、システム運用上、障害予兆を敢えて通知する必要がない場合には、その障害予兆がある旨の通知を抑止する障害該当判定部を備える、ことを特徴とする請求項１から請求項３のいずれか１項に記載の障害予兆検出システム。
【請求項５】
特定のソースコードとその参照元や参照先となるソースコードの関係を定義した影響通知部を備え、上記ログ解析装置は、検出ログが発生しない場合にこれを障害予兆として検出する場合に、上記影響通知部の情報に基づいて特定のソースコードの参照元と参照先のソースコードについても障害予兆発生の可能性ありとして通知することを特徴とする請求項１から請求項４のいずれか１項に記載の障害予兆検出システム。
【請求項６】
障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログに基づいて障害予兆を検出するために、上記プログラムの障害予兆を検出する範囲を規定する処理監視単位の名称と障害予兆の有無の判断に使うログを検出定義として予め作成して登録しておく第１のステップと、
障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログを取得し、その取得したログに対して、予め作成された上記検出定義に基づいて障害予兆を検出し、障害予兆があればその旨を通知する第２のステップとを備え、
上記第２のステップでは、上記ソフトウェアのプログラムの障害に紐づいたエラーログを検出した場合だけでなく、予め作成された上記検出定義に基づき、プログラムの処理監視単位ごとに処理の開始、終了を検出し、かつ本来正常な処理が実行された場合に発生すると予定されている検出ログが発生しない場合には、これを障害予兆として検出することを特徴とする障害予兆検出方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ソフトウェアの実行時に出力するシステムログ（以下、単にログという）の特徴から障害の予兆を検出することで、障害発生を未然に防止、もしくは早期発見する障害予兆検出システムおよびその方法に関するものである。
【背景技術】
【０００２】
従来、ソフトウェアの障害検出においては、障害と紐づいたエラーログを予め定義し、ソフトウェアが稼働する現場では定義されたエラーログの発生を起因としてエラーと判定する(例えば、下記の特許文献1参照)。
【０００３】
列車の運行管理システムを例にとって説明すると、司令員が入力した列車番号がシステムに存在しないものである場合、システムは定義されたエラーログを出力するので、そのエラーログを確認していくことで障害の特定が行われる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−９８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のログによる障害検出方式は、このように障害に紐づいたエラーログを発生するので、エラーログが明示的に発生しない障害の場合にはその発見が遅れ、その結果、業務に支障をきたす可能性があるといった問題があった。
【０００６】
この発明は、上記のような課題を解決するためになされたものであり、障害に紐づいたエラーログを明示的に発生する場合だけでなく、これに加えて、エラーログが明示的に発生しない場合でも障害予兆として検出できるようにして、より多くの障害に対して早期対応が可能となる障害予兆検出システムおよび障害予兆検出方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
この発明に係る障害予兆検出システムは、障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログに基づいて障害予兆を検出するものであって、上記プログラムの障害予兆を検出する範囲を規定する処理監視単位の名称と障害予兆の有無の判断に使うログを検出定義として予め作成して登録しておく検出定義作成装置と、上記ソフトウェアのプログラムが実行されるたびに出力されるログを取得し、その取得したログに対して、上記検出定義作成装置で作成された検出定義に基づいて障害予兆を検出するログ解析装置とを備え、上記ログ解析装置は、プログラムの障害に紐づいたエラーログを検出するとともに、上記検出定義作成装置において予め作成された検出定義に基づき、プログラムの処理監視単位ごとに、本来正常な処理が実行された場合に発生すると予定されている検出ログの発生の有無を解析し、上記検出ログが発生しない場合には、これを障害予兆として検出することを特徴としている。
【０００８】
また、この発明に係る障害予兆検出方法は、障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログに基づいて障害予兆を検出するために、上記プログラムの障害予兆を検出する範囲を規定する処理監視単位の名称と障害予兆の有無の判断に使うログを検出定義として予め作成して登録しておく第１のステップと、障害の解析対象となるソフトウェアのプログラムが実行されるたびに出力されるログを取得し、その取得したログに対して、予め作成された上記検出定義に基づいて障害予兆を検出し、障害予兆があればその旨を通知する第２のステップとを備え、上記第２のステップでは、上記ソフトウェアのプログラムの障害に紐づいたエラーログを検出した場合だけでなく、予め作成された上記検出定義に基づき、プログラムの処理監視単位ごとに処理の開始、終了を検出し、かつ本来正常な処理が実行された場合に発生すると予定されている検出ログが発生しない場合には、これを障害予兆として検出することを特徴としている。
【発明の効果】
【０００９】
この発明によれば、障害に紐づいたエラーログを明示的に発生する場合だけでなく、これに加えて、エラーログが明示的に発生しない場合でも障害予兆として検出できるので、より多くの障害に対して早期対応が可能となる。
【図面の簡単な説明】
【００１０】
【図１】この発明の実施の形態１に係る障害予兆検出システムの構成を示すブロック図である。
【図２】この発明の実施の形態１に係る障害予兆検出システムの障害予兆の検出処理動作を示すフローチャートである。
【図３】この発明の実施の形態１に係る障害予兆検出システムの検出定義作成装置で作成される検出定義テーブルとログ監視状態テーブルの一例を示す説明図である。
【図４】この発明の実施の形態２に係る障害予兆検出システムの構成を示すブロック図である。
【図５】この発明の実施の形態２に係る障害予兆検出システムの試験情報解析部で予め定義される試験定義テーブルの一例を示す説明図である。
【図６】この発明の実施の形態３に係る障害予兆検出システムの構成を示すブロック図である。
【図７】この発明の実施の形態３に係る障害予兆検出システムの障害該当判定部で予め設定される障害判定テーブルの一例を示す説明図である。
【図８】この発明の実施の形態４に係る障害予兆検出システムの構成を示すブロック図である。
【図９】この発明の実施の形態４に係る障害予兆検出システムの試験情報解析部で定義される試験定義テーブルの一例を示す説明図である。
【図１０】この発明の実施の形態５に係る障害予兆検出システムの構成を示すブロック図である。
【図１１】この発明の実施の形態５に係る障害予兆検出システムの影響通知部に予め設定登録されるソース参照関連管理テーブルの一例を示す説明図である。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１はこの発明の実施の形態１における障害予兆検出システムの構成を示すブロック図である。
【００１２】
この発明の実施の形態１における障害予兆検出システム１は、検出定義作成装置１００と、ログ解析装置２００とにより構成される。検出定義作成装置１００とログ解析装置２００の間は図示しないが、ネットワーク接続もしくはＣＤ等のメディアによりデータを受け渡すことができる。なお、各装置１００、２００は一般的な計算機によって構成される。
【００１３】
検出定義作成装置１００は、障害の解析対象となるソフトウェア９００について、そのプログラムが実行されるたびに出力されるログに基づいて障害予兆を検出するために、プログラムの障害予兆を検出する範囲を規定する処理監視単位の名称や障害予兆の有無の判断に使うログなどを検出定義として予め作成して登録しておくために設けられており、定義入力部１１と検出定義作成部１２とからなる。
【００１４】
一方、ログ解析装置２００は、障害の解析対象となるソフトウェア９００において、そのプログラムが実行されるたびに出力されるログを取得し、その取得したログに対して、検出定義作成装置１００で作成された検出定義に基づいて障害予兆を検出し、障害予兆があれば、その旨を通知するものであり、ログ取得部２１、ログ解析部２２、検出定義管理部２３、ログ状態管理部２４、および障害予兆通知部２５からなる。
【００１５】
次に、各装置１００、２００の具体的な構成について説明する。
【００１６】
検出定義作成装置１００において、定義入力部１１は、検出定義を作成するために必要となる情報を入力するインタフェースであり、例えばキーボートやマウス、タブレット端末などで構成される。検出定義作成部１２は、定義入力部１１から入力された情報を用いて検出定義を作成し、この検出定義の情報を図３（ａ）に示すような検出定義テーブルとして保持する。
【００１７】
一方、ログ解析装置２００において、ログ取得部２１は、解析対象のソフトウェア９００のプログラム実行時に発生する各種ログを取得する。また、検出定義管理部２３は、検出定義作成装置１００の検出定義作成部１２で作成された検出定義を取得する。ログ解析部２２は、ログ取得部２１で取得されたログの内容を解析し、障害予兆を検出する。そのログ解析の際、ログ解析部２２は、検出定義管理部２３が保持する検出定義の情報を使用する。ログ状態管理部２４は、ログ解析部２２で解析中の状態を管理するためのメモリを備えており、ログ解析部２２による解析結果を図３（ｂ）に示すようなログ監視状態テーブルとして保持する。さらに、ログ解析部２２は、ログ解析した結果、ログ状態管理部２４に登録された情報に基づいて障害予兆の有無を判断し、障害予兆があると判断した場合には、その旨を障害予兆通知部２５に通知する。障害予兆通知部２５は、ログ解析部２２からの障害予兆の通知に応じて、ログ解析装置２００が備える図示しないＣＲＴや液晶などの表画面上、あるいは外部の警報装置に対して障害予兆がある旨を通知する。
【００１８】
次に、この障害予兆検出システム１の障害予兆の検出処理動作について、図２に示すフローチャートを参照して説明する。なお、符号Ｓは各処理ステップを意味する。
【００１９】
この実施の形態１における処理動作は、図２（ａ）に示すように、検出定義を作成する作成フローＳ１と、図２（ｂ）に示すように、検出定義と解析対象となるソフトウェアのログとに基づいて障害検出を実施する解析フローＳ２とに大別される。
【００２０】
まず、作成フローＳ１については、定義入力部１１から検出定義作成部１２に対して障害予兆を検出するために必要な検出定義の情報を入力し（Ｓ１１）、検出定義作成部１２にその検出定義の情報を登録する（Ｓ１２）。これにより、検出定義作成部１２には、定義入力部１１から入力された情報に基づいて、図３（ａ）に示すような検出定義テーブルが作成される。そして、検出定義作成部１２で作成された図３（ａ）に示すような検出定義テーブルの情報は、ログ解析装置２００の検出定義管理部２３に転送されてここに登録される。
【００２１】
図３（ａ）に示す検出定義テーブルの作成に際しては、障害予兆を検出する解析対象範囲としてプログラムの処理監視単位を設定して登録する。また、ソフトウェアは様々な処理の開始や実行にあたって処理が実行したことを示すトレースログを出力することが一般的である。そこで、このトレースログを利用して、処理監視単位ごとに、障害予兆の有無の判断に使うログを登録する。すなわち、処理監視単位ごとに、障害予兆検出を開始する目印となるログを開始ログ、終了時の目印となるログを終了ログとして登録する。さらに、正常に処理監視単位内のプログラムに基づく処理が正常に実行された場合に終了ログの発生直前に通常発生されるログを検出ログとして登録する。
【００２２】
一方、解析フローＳ２については、ログ取得部２１が実行中のソフトウェアから開始ログを取得する。なお、解析対象となるソフトウェア９００は、ここではプログラムの処理監視単位名ごとにマルチタクスで動作しているものとする。
【００２３】
ログ解析部２２は、この開始ログが検出定義管理部２３に移管されている検出定義テーブル（図３（ａ））に登録された開始ログに該当した場合、処理監視単位番号をキーとして、ログ状態管理部２４が備える図３（ｂ）に示すログ監視状態テーブルに対して、現在の状態を”開始”にセットする（Ｓ２１）。
【００２４】
また、ログ解析部２２は、ログ取得部２１が取得する検出ログの発生を監視し、検出ログが発生した場合、ログ状態管理部２４に設けられているログ監視状態テーブル（図３（ｂ））に対して、検出ログの発生を”有”にセットする（Ｓ２２）。
【００２５】
さらに、ログ解析部２２は、ログ取得部２１が取得する終了ログの発生を監視し、終了ログが発生した場合、ログ状態管理部２４が備えるログ監視状態テーブル（図３（ｂ））に対して、現在の状態を”終了”にセットする（Ｓ２３）。
【００２６】
そして、ログ解析部２２は、ログ状態管理部２４が備えるログ監視状態テーブル（図３（ｂ））を参照して、ログ解析を行う（Ｓ２４）。すなわち、終了ログの状態が”終了”になっている処理監視単位につき、検出ログの発生の有無を判断する（Ｓ２５）。
【００２７】
ログ解析部２２は、終了ログが”終了”の状態になっているにもかかわらず、検出ログの発生が”有”でない場合、その処理監視単位のプログラムは、本来正常な処理が実行された場合に発生するはずの検出ログが発生し無かったので、その処理監視単位のプログラムには障害が有るものと判断し、障害予兆通知部２５によりその旨をログ解析装置２００が備える図示しないＣＲＴや液晶などの表画面上、あるいは外部の警報装置に通知する（Ｓ２６）。
【００２８】
上記処理の具体例として、図３（ｂ）のログ監視状態テーブルにおいて、処理監視単位名が”１０００１”のプログラムについては、そのタスクが未だ完了していないので、開始ログの状態は”開始”のままになっていて、終了ログは未だ発生されていない。したがって、検出ログも発生されておらず、障害予兆通知部２５からは障害予兆の通知は出力されない。
【００２９】
処理監視単位名が”１０００２”のプログラムについては、そのタスクが既に完了したので、終了ログが発生し、現在の状態は”終了”となっている。にもかかわらず、検出ログの発生状態は”無”なので、この場合には、処理監視単位名が”１０００２”のプログラム処理には障害が発生している可能性がある。このため、障害予兆通知部２５から障害予兆の通知が出力される。
【００３０】
一方、処理監視単位名が”１０００３”のプログラムについては、そのタスクが既に完了したので、終了ログが発生して現在の状態は”終了”となっている。また、検出ログが正常に発生されたので、その発生状態が”有”となっている。この場合には、処理監視単位名が”１０００３”のプログラム処理は正常に実行されたものと判断し、このため、障害予兆通知部２５から障害予兆の通知は出力されない。
【００３１】
なお、処理監視単位名が”１００１１”のプログラムについては、そのタスクの実行完了前にプログラムの明確な障害に紐づいたエラーログが発生されているので、その場合には検出ログの発生の有無にかかわらず、障害予兆通知部２５から障害予兆の通知が出力される。
【００３２】
このように、この実施の形態１では、検出定義作成装置１００において予め作成した検出定義に基づき、ログ解析装置２００によりプログラムの処理監視単位ごとに処理の開始、終了を検出し、本来正常な処理が実行された場合に発生すると予定されている検出ログが発生しないことが分かった場合には、これを障害予兆として検出するようにした。その結果、障害に紐づいたエラーログを検出する場合に加えて、明示的にエラーログが発生しない場合でも、障害予兆を検出することができる。このため、より多くの障害に対して早期対応が可能となるという効果が得られる。
【００３３】
実施の形態２．
図４はこの実施の形態２における障害予兆検出システムの構成を示すブロック図であり、図１に示した実施の形態１の構成と対応する部分には同一の符号を付す。
【００３４】
この実施の形態２の特徴は、上記実施の形態１の構成に対して、試験情報解析装置３００を追加し、これによって解析対象となるソフトウェア９００の試験実施に伴って、図３（ａ）に示したような検出定義テーブルが簡便に作成できるようにしていることである。
【００３５】
解析対象となるソフトウェア９００がインストールされる製品は、製品の出荷前に当該ソフトウェア９００が所定通りに動作するか否かが試験される。その試験に際しては、予め正常な結果が得られることが期待されるデータを入力するだけでなく、間違った結果が得られるデータを故意に入力してエラーを発生させ、ソフトウェア９００が正しく動作することを確認する。
【００３６】
そこで、この実施の形態２では、試験情報解析装置３００を、試験情報入力部３１、試験情報解析部３２、および試験情報送信部３３で構成している。
【００３７】
ここに、試験情報入力部３１は、試験内容を定義するために必要となる試験情報を入力するインタフェースであり、例えばキーボートやマウス、タブレット端末などで構成される。この場合、試験内容を定義するために必要となる試験情報としては、処理監視対象となる個々のプログラムに対応付けた試験番号、処理監視単位名、当該プログラムの試験結果を想定して正常／異常となる情報が入力される。
【００３８】
試験情報解析部３２は、試験情報入力部３１から入力された試験内容を定義した試験情報を、図５に示すような試験定義テーブルとしてメモリに保持するとともに、この試験定義テーブルに基づいて、ソフトウェア９００のプログラムが処理監視単位ごとに所定通りに動作するか否かの試験が実施される際に、そのソフトウェア９００の処理監視単位ごとのプログラム実行による試験結果が正常となる際に得られるログ情報を抽出する。
【００３９】
すなわち、試験情報解析部３２は、処理監視単位ごとに実行されたプログラムの処理結果が正常となる場合に得られる検出ログを抽出する。そして、試験情報解析部３２は、こうして抽出した情報（処理監視単位名と検出ログ）を、試験情報送信部３３を介して検出定義作成装置１００に検出定義の情報として送信する。
【００４０】
そして、検出定義作成部１２において、試験情報解析装置３００から送られてくる検出定義の情報に、さらに開始ログと終了ログとを処理監視単位名ごとに人手で別途追加することで、図３（ａ）に示したような検出定義テーブルが完成される。
【００４１】
これにより、図３（ａ）に示したような検出定義テーブルをソフトウェア９００の試験を実施する際に簡便に作成できるので、障害予兆解析を行う上で必要な検出定義テーブルを検出定義作成装置１００で独自に作成する場合に比べて、その手間や準備時間を削減することができるという効果が得られる。
なお、その他の構成および作用効果は、実施の形態１の場合と同様であるから、ここでは詳しい説明は省略する。
【００４２】
実施の形態３．
図６はこの発明の実施の形態３における障害予兆検出システムの構成を示すブロック図であり、図４に示した実施の形態２の構成と対応する部分には同一の符号を付す。
【００４３】
解析対象となるソフトウェア９００のプログラム内の一部の処理範囲を実行する場合、その処理内容によっては、エラーログが発生されない限り、検出ログが発生されなくても全体の処理結果に影響を及ぼさない程度のもので、運用上、支障のないプログラムが存在することがある。
【００４４】
そこで、この実施の形態３では、上記実施の形態２の構成に対して、ログ解析装置２００内に障害該当判定部２６を追加し、この障害該当判定部２６には、図７に示すように、検出ログが発生されなくても、障害予兆を殊更通知する必要がないことを定義できる障害判定テーブルを予め設定してメモリに登録している。
【００４５】
例えば、図７に示す障害判定テーブルにおいて、処理監視単位名が”１００１”や”１００３”のプログラムについては、そのタスクが既に完了して現在の状態が”終了”となる場合に検出ログの発生が無ければ、障害予兆があるとして障害予兆通知部２５による通知を許容（ＹＥＳ）するように予め設定しておく。
【００４６】
これに対して、処理監視単位名が”１００２”のプログラムについては、そのタスクが既に完了して現在の状態が”終了”となる場合に検出ログの発生がなくても、障害予兆通知部２５による通知は不要（Ｎｏ）と予め設定しておく。
【００４７】
したがって、前述の実施の形態１では、図３（ｂ）に示したように、処理監視単位名が”１００２”のプログラムについては、そのタスクが既に完了して現在の状態が”終了”となっている場合に検出ログの発生がなければ障害予兆通知部２５による通知がなされるのに対して、この実施の形態３では、障害該当判定部２６が図７に示した障害判定テーブルを参照することにより、検出ログの発生がない場合でも障害予兆通知部２５による通知が抑止される。
【００４８】
このように、この実施の形態３では、障害該当判定部２６を設け、プログラム内の一部の処理範囲を実行する際、その処理内容によって全体の処理結果に影響を及ぼさない程度のものである場合には、検出ログの発生がなくても運用上、特に支障はないと判断して障害予兆通知を抑止することが可能になる。これにより、各処理監視単位名のプログラムの全てについて通知の有無を確認する手間を省くことができ、特に確認数が多くなるような障害予兆通知がある場合に確認時間を削減できるという効果が得られる。
なお、その他の構成および作用効果は、実施の形態２の場合と同様であるから、ここでは詳しい説明は省略する。
【００４９】
実施の形態４．
図８はこの発明の実施の形態４における障害予兆検出システムの構成を示すブロック図であり、図６に示した実施の形態３の構成と対応する部分には同一の符号を付す。
【００５０】
この実施の形態４の特徴は、図８に示すように、上記実施の形態３の構成に対して、ログ追加処理部４１とログ追加情報送信部４２からなるソース管理装置４００を追加し、これによって解析対象となるソフトウェア９００の試験に伴って図３（ａ）に示したような検出定義テーブルが自動的に作成できるようにしていることである。
【００５１】
ここに、ログ追加処理部４１は、試験番号に対応した処理監視単位ごとのプログラムのソースコードの開始時点を示す開始ログと終了時点を示す終了ログの情報を入力し、ログ追加情報送信部４２は、このログ追加処理部４１で追加された開始ログと終了ログの情報を試験情報解析装置３００に送信する。
【００５２】
このログ追加処理部４１から送信された開始ログと終了ログの情報は、試験情報入力部３１を介して試験情報解析部３２に取り込まれるので、試験情報解析部３２が備える試験定義テーブルには、図９に示すように、処理監視対象となる個々のプログラムに対応付けた試験番号、処理監視単位名、当該プログラムの試験結果が正常／異常となる情報（図５参照）だけでなく、さらに、試験番号に対応した処理監視単位ごとのプログラムのソースコード、そのソースコードの開始時点を示す開始ログと終了時点を示す終了ログの情報も併せて登録される。
【００５３】
試験情報解析装置３００は、実施の形態２で説明したように、解析対象となるソフトウェア９００のプログラムの処理監視単位ごとに所定通りに動作するか否かの試験が実施される際に、そのソフトウェア９００の処理監視単位ごとのプログラム実行による試験結果が正常となる際に得られるログ情報を抽出する。この場合に抽出される情報としては、処理監視単位名、検出ログ、開始ログ、終了ログが含まれる。そして、こうして抽出した情報が検出定義作成装置１００に対して検出定義として送信されるので、検出定義作成部１２は、図３（ａ）に示したような検出定義テーブルが自動的に作成される。
【００５４】
このように、この実施の形態４では、実施の形態３の構成に対してソース管理装置４００を追加し、これによって解析対象となるソフトウェア９００の試験に伴って図３（ａ）に示したような検出定義テーブルが自動的に作成されるため、障害予兆解析のために必要とする検出定義テーブルを検出定義作成装置１００で独自に作成する場合に比べて、その手間や準備時間を大幅に削減できるという効果が得られる。
なお、その他の構成および作用効果は、実施の形態３の場合と同様であるから、ここでは詳しい説明は省略する。
【００５５】
実施の形態５．
図１０はこの発明の実施の形態５における障害予兆検出システムの構成を示すブロック図であり、図８に示した実施の形態４の構成と対応する部分には同一の符号を付す。
【００５６】
この実施の形態５では、図１０に示すように、上記実施の形態４の構成に対して、ソース管理装置４００内に、影響通知部４３を追加し、この影響通知部４３には、図１１に示すような、各処理監視単位名に関連するソースコードとその参照元や参照先のプログラムのソースコードとの関連を定義したソース参照関連管理テーブルを予めメモリに登録して保持している。そして、このソース参照関連管理テーブルの情報を障害該当判定部２６に通知するようにしている。
【００５７】
これにより、ログ解析部２２のログ解析の結果、所定の処理監視単位名をもつプログラムのタスクが既に完了して現在の状態が”終了”となっているにもかかわらず、検出ログの発生がないと解析された場合であって、かつ、障害該当判定部２６に予め登録されている図７に示した障害判定テーブルにより、検出ログ未発生時に障害予兆を通知することが許容（ＹＥＳ）されていると判定された場合、障害該当判定部２６は、影響通知部４３から通知された図１１に示すソース参照関連管理テーブルを参照して、当該処理監視単位名をもつプログラムのソースコードとその参照元や参照先のプログラムのソースコードを、障害予兆通知部２５を介して例えば図示しないＣＲＴや液晶などの表画面上に通知する。
【００５８】
例えば、処理監視単位名が”１０００１”をもつプログラムに障害予兆があると判定される場合、図１１に示したソース参照関連管理テーブルに基づき、そのソースコード”ＡＡＡ．ｃ”と、その参照元であるプログラムのソースコード”ｍａｉｎ．ｃ”や、参照先のプログラムのソースコード”ＡＡＡ−１．ｃ”や”ＡＡＡ−２．ｃ”が通知される。
【００５９】
これにより、所定の処理監視単位名をもつプログラムについて、そのソースコードが変更された場合に検出ログが発生しなかった時には、その変更されたソースコードの参照元や参照先のプログラムのソースコードについても障害予兆発生の可能性ありとして、再度確認することができるので、ソースコードの変更に伴って発生する可能性のある周辺処理のプログラムについての障害予兆を漏らさず検出することができる。このため、より多くの障害に対して早期対応が可能となる効果が得られる。
なお、その他の構成および作用効果は、実施の形態４の場合と同様であるから、ここでは詳しい説明は省略する。
【００６０】
この発明は上記の実施の形態１〜５の構成のみに限定されるものではなく、この発明の趣旨を逸脱しない範囲において、各実施の形態１〜５の構成の一部に変形を加えたり、構成の一部を省略することができ、さらに、各実施の形態１〜５の構成を適宜組み合わせることが可能である。
【符号の説明】
【００６１】
１  障害予兆検出システム、１００  検出定義作成装置、１１  定義入力部、
１２  検出定義作成部、２００  ログ解析装置、２１  ログ取得部、２２  ログ解析部、２３  検出定義管理部、２４  ログ状態管理部、２５  障害予兆通知部、
２６  障害該当判定部、３００  試験情報解析装置、３１  試験情報入力部、
３２  試験情報解析部、３３  試験情報送信部、４００  ソース管理装置、
４１  ログ追加処理部、４２  ログ追加情報送信部、４３  影響通知部。
【図１】
0006410705.tif 000002
【図２】
0006410705.tif 000003
【図３】
0006410705.tif 000004
【図４】
0006410705.tif 000005
【図５】
0006410705.tif 000006
【図６】
0006410705.tif 000007
【図７】
0006410705.tif 000008
【図８】
0006410705.tif 000009
【図９】
0006410705.tif 000010
【図１０】
0006410705.tif 000011
【図１１】
0006410705.tif 000012