JP2009294837A

JP2009294837A - 障害監視システム及びデバイスと監視装置並びに障害監視方法

Info

Publication number: JP2009294837A
Application number: JP2008146774A
Authority: JP
Inventors: Daisuke Fukui; 大輔福井; Masumi Kawakami; 真澄川上
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2008-06-04
Filing date: 2008-06-04
Publication date: 2009-12-17
Anticipated expiration: 2028-06-04
Also published as: JP5198154B2

Abstract

【課題】監視対象機器の増加に伴う障害情報の通信データ量の増加を防ぎ、通信データ量を削減することによる障害情報の品質低下を防止する。
【解決手段】監視対象のデバイス202上で動作するプログラムモジュールにおいて発生した障害を障害監視部208が検知した際に、障害情報作成部209が、状態遷移監視部207より状態遷移履歴情報を取得し、外部記憶装置212よりプログラムモジュールに関して実施されたテストデータ213を取得し、状態遷移履歴情報およびテストデータを基に障害情報を作成し、障害情報送信部210が、ネットワーク201を介して監視装置215に送信する。
【選択図】図２

Description

本発明は、障害監視システム及びデバイスと監視装置並びに障害監視方法に関し、特にネットワークを通じて直接的または間接的に通信が可能な複数のデバイスにおける障害の発生を監視する技術に関する。

近年、携帯電話やテレビといったコンシューマ機器が多機能化しており、そこに搭載されるソフトウェアの規模は年々増加する傾向にある。一般に、ソフトウェアの規模が増加すると、潜在的なバグの数が増加し、製品出荷後に不良が発生する可能性が高くなる。こうした状況を避けるため、大規模なソフトウェアの開発を高品位に、かつ高効率に行うために、モデルベース開発やソフトウェアプロダクトラインといったソフトウェア開発の方法論に関する研究が進められている。
一方、コンシューマ機器の製品出荷後に発生するソフトウェアの不具合を迅速に修正するための要素技術の研究も進んでいる。ソフトウェアをリモートから更新するための機能を備えたテレビやゲーム機が製品化されている。また、機器上で発生した障害を検出するシステムが一般に知られている。例えば特許文献１記載の障害監視システムや特許文献２記載の組み込み機器用監視装置などがある。
特開平９−９１２１９号公報特開２００４−１８７１９６号公報

一般的な障害検出システムは、監視対象機器からセンタサーバへ障害情報を送信することで障害の検出を行っている。この方式では、監視対象機器の数が増えるにつれて通信回数や通信データ量が増加し、輻輳の発生やサーバ維持費の増加に繋がっている。そこで、前記特許文献１では、発生した障害情報の緊急度を判定し、緊急度が高い障害情報は直ちにセンタサーバへ送信し、緊急度が低い障害情報は一定期間蓄積した後にまとめて送信する手段について述べている。また、前記特許文献２では、監視対象機器同士が連携し、障害情報を回覧することで通信回数を削減する手段について述べている。
しかし、前記特許文献１記載の方式では、通信の回数を削減することは可能であるが、通信データ量の削減には課題が残る。また、前記特許文献２記載の方式では、センタサーバに対する負担は軽減されるが、通信データ量は削減されず、かつ障害情報の収集に係る監視対象機器の高コスト化といった課題を持つ。

一般に通信データ量を削減する方式としてエラーコードの利用や、重要度の低い障害情報を間引いて送信する手段が考えられるが、この方式では障害情報の品質が低下する。エラーコードの送信だけでは想定外の障害に対処することは難しく、障害情報を間引く手段では本当に必要な障害情報にアクセスできなくなる可能性がある。

本発明が解決しようとする第１の課題は、監視対象機器の増加に伴う障害情報の通信データ量の増加である。第２の課題は、通信データ量を削減することによる障害情報の品質低下である。

前記課題を解決するため、本発明ではソフトウェアの開発段階で実施されるテストの結果を基にした障害情報を作成する。例えばモデルベース開発と呼ばれる開発方法論で用いられる状態遷移表を基にした障害情報を作成する。テスト結果を基に、障害発生箇所のテストが実施済である場合は想定外の障害として詳細な障害情報を作成し、未実施である場合は想定内の障害としてテストの実施を促すための簡易な障害情報を作成し、実施中である場合は現在対策中の障害として障害情報を作成しない。この方式を採用することで、前記課題を解決する。

すなわち、本発明は、監視対象となるデバイスと、前記デバイスにおける障害の発生を監視する監視装置と、前記デバイスの障害データを記憶するデータベースである外部記憶装置とからなり、これら装置がネットワークを介してデータの送受信が可能な障害監視システムであって、前記デバイス上で動作するプログラムモジュールにおいて発生した障害を監視する障害監視部と、前記プログラムモジュールの状態遷移を監視する状態遷移監視部と、前記障害監視部が障害の発生を検知した際に前記状態遷移監視部より状態遷移履歴情報を取得し、さらに前記外部記憶装置より前記プログラムモジュールに関して実施されたテストデータを取得し、前記状態遷移履歴情報および前記テストデータを基に障害情報を作成する障害情報作成部と、前記障害情報作成部により作成された障害情報を、ネットワークを介して前記監視装置に送信する障害情報送信部とを有する障害監視システムである。

本発明によれば、監視対象機器からセンタサーバに送信する障害情報のデータ量を削減でき、よって監視対象機器の増加に伴うネットワークトラフィックの増加を抑制することができる。また、ソフトウェアの開発段階で実施されるテストの結果に依拠した監視方法であることから、既存の方式に比べて障害情報の品質を向上させることができ、かつ本発明の導入コストを低く抑えることが可能である。

本発明を実施するための最良の形態を説明する。
本発明の障害監視システム及びデバイスと監視装置並びに障害監視方法の実施形態について、図面を用いて説明する。
図１はハードウェア構成図である。これは、本発明に係る一般的なシステムのハードウェア構成を表すものであり、ハードウェア構成を限定するものではない。また、本発明はネットワークを介した複数の端末を利用するシステムについて述べたものであるが、本図面は単一の端末について示したものであり、本発明に係る全ての端末を網羅するものではない。

演算装置１０１は、主記憶装置１０２にロードされたプログラムデータを解析し、処理を実行する中央演算ユニットである。例えばIntel社製のPentium（登録商標）プロセッサなどが演算装置１０１に該当する。
主記憶装置１０２は、外部記憶装置１０４に記録されているプログラムデータをロードする揮発メモリである。例えばＤＲＡＭ等の半導体メモリが主記憶装置１０２に該当する。
通信装置１０３は、外部ネットワークと通信するための装置である。例えばインターネットに接続するためのネットワークインタフェースカードが通信装置１０３に該当する。
外部記憶装置１０４は、プログラムデータ等を記憶する不揮発メモリである。例えばハードディスク装置が外部記憶装置１０４に該当する。外部記憶装置１０４は、データベース等のネットワークを介した装置であってもよい。

図２はモジュール概念図である。これは、本発明に係る一般的なモジュールの概念構成を表すものであり、モジュールの構成を限定するものではない。図示されているモジュールの包含関係（例えば被監視装置２０２と監視エージェント２０６の包含関係）は一般的な例であり、包含関係を規定するものではない。また、図示されているモジュールがネットワークを介して連携するかどうか、同一の装置上で連携するかどうかについて規定するものではない。

ネットワーク２０１は、データの送受信が行えることを特徴とする通信ネットワークである。例えばインターネットやEthernet（登録商標）などがネットワーク２０１に該当する。

被監視装置２０２は、ネットワーク２０１を介して監視装置２１５によって監視される装置である。例えば携帯電話やホームゲートウェイなどが被監視装置２０２に該当する。
被監視プログラム２０３は、監視エージェント２０６によって監視されるプログラムである。例えばホームゲートウェイ上で動作する情報家電制御プログラムなどが被監視プログラム２０３に該当する。

状態遷移通知部２０４は、被監視プログラム２０３上で発生した状態遷移に関する情報を状態遷移監視部２０７に通知するモジュールである。また、通知方式は、PUSH型（状態遷移通知部２０４から状態遷移監視部２０７へ通知する方式）であってもよく、PULL型（状態遷移監視部２０７から状態遷移通知部２０４に問い合わせる方式）であってもよい。例えばJava（登録商標）のJMX（Java Management Extensions）仕様で規定されるMBeanなどを利用することで状態遷移通知部２０４を実装できる。この具体例については後述する。

障害通知部２０５は、被監視プログラム２０３上で発生した障害に関する情報を障害監視部２０８に通知するモジュールである。また、通知方式は、PUSH型（障害通知部２０５から障害監視部２０８へ通知する方式）であってもよく、PULL型（障害監視部２０８から障害通知部２０５に問い合わせる方式）であってもよい。例えばJavaのJMX仕様で規定されるMBeanなどを利用することで障害通知部２０５を実装できる。この具体例については後述する。

監視エージェント２０６は、被監視プログラム２０３の状態遷移、および被監視プログラム２０３における障害の発生を監視し、被監視プログラム２０３で障害が発生した場合、ネットワーク２０１を介してデータベース２１２より状態遷移表テストデータ２１３および状態遷移パステストデータ２１４等のテストデータを取得し、当該テストデータを基に発生した障害の種類を判定し、発生した障害の種類を基に障害情報を作成し、必要であればネットワーク２０１を介して監視装置２１５に前記障害情報を送信するモジュールであり、また、ネットワーク２０１を介して監視装置２１５より最新のテストデータを受信し、当該テストデータを基にネットワーク２０１を介してデータベース２１２に格納されている状態遷移表テストデータ２１３および状態遷移パステストデータ２１４等の前記テストデータを更新する機能を持ったモジュールである。
監視エージェント２０６は、被監視プログラム２０３と同じマシン上に存在してもよく、ネットワーク２０１を介した別のマシン上に存在してもよい。また、状態遷移表テストデータ２１３および状態遷移パステストデータ２１４等のテストデータは、別のテストデータを利用することも可能である。本実施例では、テストデータの具体的な例として状態遷移表テストデータ２１３および状態遷移パステストデータ２１４を利用する。これらのテストデータの具体例については後述する。

状態遷移監視部２０７は、前述の通り、状態遷移通知部２０４と連携し、被監視プログラム２０３の状態遷移を監視するモジュールである。
障害監視部２０８は、前述の通り、障害通知部２０５と連携し、被監視プログラム２０３上で発生する障害を監視するモジュールである。
障害情報作成部２０９は、障害監視部２０８が障害の発生を検知した際、過去に遷移した状態の履歴情報を状態遷移監視部２０７より取得し、ネットワーク２０１を介して当該情報に対応する状態遷移表テストデータ２１３および状態遷移パステストデータ２１４をデータベース２１２より取得し、当該データを基に障害情報を作成し、必要であれば当該障害情報を障害情報送信部２１０に送信するモジュールである。障害情報の作成手順および障害情報の具体例については後述する。

障害情報送信部２１０は、障害情報作成部２０９によって作成された障害情報を、ネットワーク２０１を介して監視装置２１５の障害情報受信部２１６に送信するモジュールである。
テストデータ更新部２１１は、監視装置２１５のテストデータ送信部２１７がネットワーク２０１を介して送信したテストデータを受信し、当該テストデータを基にデータベース２１２に格納されている状態遷移表テストデータ２１３および状態遷移パステストデータ２１４を更新するモジュールである。

データベース２１２は、状態遷移表テストデータ２１３および状態遷移パステストデータ２１４を格納する外部記憶装置１０４である。
状態遷移表テストデータ２１３は、被監視プログラム２０３の開発段階で実施された状態遷移表テストに関するデータである。
状態遷移パステストデータ２１４は、被監視プログラム２０３の開発段階で実施された状態遷移パステストに関するデータである。
監視プログラム２１４は、ネットワーク２０１を介して監視エージェント２０６から障害情報を受信し、当該障害情報を管理者等に通知し、また、最新のテストデータが存在する場合は当該テストデータをネットワーク２０１を介してテストデータ更新部２１１に送信するモジュールである。

監視装置２１５は、ネットワーク２０１を介して監視エージェント２０６と通信を行い、被監視装置２０２を監視する装置である。
障害情報受信部２１６は、ネットワーク２０１を介して障害情報送信部２１０より障害情報を受信し、当該障害情報を障害情報通知部２１８に通知するモジュールである。
テストデータ送信部２１７は、ネットワーク２０１を介し、被監視プログラム２０３の開発担当者によって実施された最新のテストデータをテストデータ更新部２１１に送信するモジュールである。
障害情報通知部２１８は、障害情報受信部２１６が受信した障害情報を、独自の手段（メール送信、ダイアログ表示等）により管理者等に通知するモジュールである。

図３は障害情報の作成に関するフローチャートを示す図である。
ステップ３０１は、状態遷移監視部２０７が被監視プログラム２０３の状態遷移を監視するステップである。このステップにおいて、状態遷移監視部２０７は被監視プログラム２０３上で発生した状態遷移の履歴を保持する。具体的な状態遷移の監視手段については後述する。
ステップ３０２は、障害監視部２０８が被監視プログラム２０３で発生する障害を監視するステップである。このステップにおいて、障害監視部２０８は被監視プログラム２０３上で発生した障害情報のログを保持する。具体的な障害の監視手段については後述する。
ステップ３０１とステップ３０２は、処理が前後してもよく、また、並列に実行されていてもよい。
ステップ３０３は、ステップ３０２で障害が発生したかどうかを調べるステップである。もし障害が発生していなければ、ステップ３０１へ戻る。もし障害が発生した場合は、ステップ３０４へ進む。

ステップ３０４は、障害情報作成部２０９が状態遷移監視部２０７から状態遷移履歴情報を取得するステップである。状態遷移履歴情報の具体例については後述する。
ステップ３０５は、障害情報作成部２０９がステップ３０４で取得した状態遷移履歴情報を基にデータベースを検索するステップである。このステップにおいて、障害情報作成部２０９はデータベースから前記状態遷移履歴情報に対応した状態遷移表テストデータ２１３および状態遷移パステストデータ２１４を検索する。

ステップ３０６は、障害情報作成部２０９がステップ３０５において検索した状態遷移表テストデータ２１３を検証するステップである。ステップ３０４で取得した状態遷移履歴情報と状態遷移表テストデータ２１３を比較し、現在のテスト状態を検証する処理を行う。
ステップ３０７は、ステップ３０６の検証処理において、現在のテスト状態が障害対策中かどうかを判定するステップである。もし障害対策中であれば、障害情報を監視装置２１５に送信する必要がないため、処理を終了する。もし障害対策中でなければ、ステップ３０８へ進む。

ステップ３０８は、ステップ３０６の検証処理において、現在のテスト状態が未実施状態かどうかを判定するステップである。もし未実施であれば、ステップ３１５へ進む。もし未実施でなければ、つまり実施済であれば、ステップ３０９へ進む。

ステップ３０９は、障害情報作成部２０９がステップ３０５において検索した状態遷移パステストデータ２１４を検証するステップである。ステップ３０４で取得した状態遷移履歴情報と状態遷移パステストデータ２１４を比較し、現在のテスト状態を検証する処理を行う。

ステップ３１０は、ステップ３０９の検証処理において、現在のテスト状態が障害対策中かどうかを判定するステップである。もし障害対策中であれば、障害情報を監視装置２１５に送信する必要がないため、処理を終了する。もし障害対策中でなければ、ステップ３１１へ進む。

ステップ３１１は、ステップ３０９の検証処理において、現在のテスト状態が実施済状態かどうかを判定するステップである。もし実施済であれば、ステップ３１３へ進む。もし実施済でなければ、ステップ３１２へ進む。
ステップ３１２は、ステップ３１１において状態遷移パステストデータ２１４のテスト状態が実施済でなかった場合にパス障害情報を作成するステップである。パス障害情報とは、障害発生時点の状態遷移履歴に関する情報である。障害発生箇所は状態遷移パステストが実施されていないため、状態遷移パステストを実施するための最低限の情報のみを作成することで情報量を削減する。パス障害情報の詳細については後述する。
ステップ３１３は、ステップ３１１において状態遷移パステストデータ２１４のテスト状態が実施済であった場合に詳細障害情報を作成するステップである。詳細障害情報とは、メモリダンプやエラーログといった、障害原因の特定に必要な情報である。障害発生箇所は状態遷移パステストが実施されているため、予期せぬ障害が発生したと判断し、詳細な障害情報を作成する。

ステップ３１５は、ステップ３０８において状態遷移表テストデータ２１３のテスト状態が未実施であった場合に簡易障害情報を作成するステップである。簡易障害情報とは、障害発生箇所に対応する状態遷移表のセル（行、列）に関する情報である。障害発生箇所は状態遷移表テストが実施されていないため、状態遷移表テストを実施するための最低限の情報のみを作成することで情報量を削減する。簡易障害情報の詳細については後述する。

ステップ３１４およびステップ３１６は、ステップ３１２、ステップ３１３、およびステップ３１５で作成された障害情報を監視装置２１５の障害情報受信部２１６に送信するステップである。以上の手順により障害情報を作成することで、必要最低限の障害情報のみを監視装置２１５へ送信することができる。

図４は、前記JMX技術を利用した場合の状態遷移監視手段および障害監視手段を表すシーケンス図である。JMX技術は、MBeanとよばれるプログラム監視向けモジュールを開発することで、プログラムの内部状態を外部から監視できるようにするための技術である。Javaのバージョン５（Java SE ５）から、JMX技術が標準技術として導入されている。図４では、このJMX技術を利用した場合の被監視プログラム２０３の監視手段を示す。図では処理の流れを単純化するため、MBeanServer等のJMX関連モジュールについては記載を省略する。

最初に、監視エージェント２０６は、状態遷移監視リスナの登録要求４０３を状態遷移監視MBean４０１へ送信する。当該リスナの登録に成功すると、状態遷移監視MBean４０１はエラーを発生させずに登録成功メッセージ４０４を返す。
次に、監視エージェント２０６は、障害監視リスナの登録要求４０５を障害監視MBean４０２へ送信する。当該リスナの登録に成功すると、障害監視MBean４０２は、エラーを発生させずに登録成功メッセージ４０６を返す。

次に、被監視プログラム２０３は、プログラム内部の状態が変化すると状態遷移メッセージ４０７を状態遷移監視MBean４０１へ送信する。状態遷移監視MBean４０１は、当該状態遷移メッセージ４０７を受信すると、状態遷移監視リスナを通じて状態遷移通知メッセージ４０８を監視エージェント２０６へ送信する。監視エージェント２０６は、当該状態遷移通知メッセージ４０８を受信すると、状態遷移履歴（ログ）更新する処理４０９を行う。このようにして、監視エージェント２０６は状態遷移履歴情報を保持する。

プログラム内部で障害が発生すると、被監視プログラム２０３は、障害発生メッセージ４１０を障害監視MBean４０２へ送信する。障害監視MBean４０２は、障害発生メッセージ４１０を受信すると、障害監視リスナを通じて障害発生通知メッセージ４１１を監視エージェント２０６へ送信する。監視エージェント２０６は、当該障害発生通知メッセージ４１１を受信すると、状態遷移履歴情報を確認する処理４１２を行い、次に障害情報を作成する処理４１３を行い、最後に障害情報を送信する処理４１４を行う。障害の作成手順および障害情報の送信処理については図３に示した通りである。このように、JMX技術等を利用することで外部監視用プログラムを作成できる。但し、これは障害監視方法の一例であり、他のプログラムを記述することも、専用のハードウェアを利用して監視することも可能である。

図５は本発明で参照している状態遷移表の例を示す図である。これは、モデルベース開発と呼ばれる開発手法において一般に利用される、プログラムの状態遷移を表すデータである。
イベントＡ５０１、イベントＢ５０２、イベントＣ５０３、イベントＤ５０４は、プログラムに関連して発生するイベントの種類を表し、状態Ａ５０５、状態Ｂ５０６、状態Ｃ５０７、状態Ｄ５０８、状態Ｅ５０９は、プログラムの遷移し得る状態を表している。また、図中の「×」はある状態の時にそのイベントが発生する可能性がないことを表し、図中の「／」はある状態の時にそのイベントが発生しても処理が行われず、無視されることを表し、図中の「遷移Ｘ（ＸはＡからＥまでのいずれかのアルファベット）」はある状態の時にそのイベントＸが発生すると、アルファベットＸに対応する別の状態に遷移することを表している。例えば図５の表は、状態Ａ５０５の時にイベントＢ５０２は発生する可能性がないことを表し、状態Ｂ５０６の時にイベントＡ５０１が発生しても無視されることを表し、状態Ｃ５０７の時にイベントＣ５０３が発生するとプログラムの状態が状態Ａ５０５に遷移することを表している。このような状態遷移表がモデルベース開発と呼ばれる開発方法において一般に利用されている。

図６は、図５で示した状態遷移表に対応する数値データの例を示す表である。図中のe１（６０１）、e２（６０２）、e３（６０３）、e４（６０４）は、それぞれイベントａ５０１、イベントｂ５０２、イベントｃ５０３、イベントｄ５０４に対応し、ｓ１（６０５）、s２（６０６）、s３（６０７）、s４（６０８）、s５（６０９）は、それぞれ状態Ａ５０５、状態Ｂ５０６、状態Ｃ５０７、状態Ｄ５０８、状態Ｅ５０９に対応している。表中の番号は、図５の表中で示す表記にそれぞれ対応している。このように状態遷移表そのものを文字列データとして利用するのではなく、状態遷移表に対応した数値データを利用することで情報量を削減できる。これは情報量を削減するための一般的な例である。

図７は、図６で示したフォーマットを用いて表記した状態遷移履歴情報の例を示す表である。図中の発生順序７０１は状態遷移が発生した順番を表す数値であり、セル番号７０２は図６で示した数値データに対応する数値である。この例では、状態Ｅの時にイベントＢが発生して状態Ｄに遷移し、状態Ｄの時にイベントＣが発生して状態Ｃに遷移し、状態Ｃの時にイベントＡが発生して状態Ｂに遷移し、状態Ｂの時にイベントＤが発生して状態Ａに遷移し、状態Ａの時にイベントＢが発生したことを示している。図５の状態遷移図では状態Ａの時にイベントＢは発生しないと表記されているが、この例では状態Ａの時にイベントＢが発生したことを示している。
ここで、図３の説明において述べた簡易障害情報とは、障害発生直前の状態遷移に対応するセル番号７０２の数値データを障害情報として利用するものである。図７の例では、簡易障害情報に相当するデータは「２」となる。但し、これは情報量を削減するための簡易障害情報の一例であり、その内容を限定するものではない。

図８は、図６で示したフォーマットを用いて表記した状態遷移表テストデータ２１３の例を示す表である。状態遷移表テストとは、状態遷移表の各マトリクスが正常に動作するかどうかを確認するテストであり、モデルベース開発で一般的に行われるテスト手法である。例えば図５においては、状態Ａの時にイベントＡが発生した場合に状態Ｂへ正しく遷移するかどうかといった動作をテストする。
図中のセル番号８０１は図６で示した数値データに対応する数値であり、テスト状態８０２はセル番号８０１に対応した状態遷移表テストの実施状態を表す数値である。テスト状態８０２の数値は、「０」が実施済であることを表し、「１」が未実施であることを表し、「２」が実施不可能であることを表し、「３」が対策中であることを表している。
ここで、実施不可能とは、ある状態の時にイベントが発生し得ないためにテストが不可能である（図５の「×」に該当する）という意味であり、対策中とは、現在テスト中であるという意味である。このような状態遷移表テストデータ２１３を利用することで、どういった種類の障害情報を作成すべきか、また、障害情報を監視装置２１５に送信すべきかどうかを判定することができる。判定手順の例については図３で示した通りである。

図９は、図６で示したフォーマットを用いて表記した状態遷移パステストデータ２１４の例を示す表である。状態遷移パステストとは、状態遷移表の一連の状態遷移が正常に動作するかどうかを確認するテストであり、モデルベース開発で一般的に行われるテスト手法である。例えば図５においては、状態Ａの時にイベントＡが発生した場合に状態Ｂへ正しく遷移し、さらに状態Ｂの時にイベントＢが発生した場合に状態Ｅへ正しく遷移し、さらに状態Ｅの時にイベントＡが発生した場合に正しく当該イベントを無視するかどうかといった一連の動作をテストする。
図中の状態遷移パス９０１は図６で示した数値データに対応する状態遷移履歴を表すデータであり、テスト状態９０２は状態遷移パス９０１に対応した状態遷移パステストの実施状況を表す数値である。テスト状態９０２の数値は、「０」が実施済であることを表し、「１」が対策中（例えば事前に受付済み）であることを表す。図中に表れない状態遷移パスは、全てテスト状態が未実施であることを示すものとする。未実施の状態遷移パスを図中に表記しない理由は、状態遷移パス９０１の取り得る値を全て網羅するとデータ量が膨大になるためである。このような状態遷移パステストデータ２１４を利用することで、どういった種類の障害情報を作成すべきか、また、障害情報を監視装置２１５に送信すべきかどうかを判定することができる。判定手順の例については図３で示した通りである。
ここで、図３の説明において述べたパス傷害情報とは、障害発生前の一連の状態遷移に対応する状態遷移パス９０１の数値データを障害情報として利用するものである。図９の例では、パス障害情報に相当するデータは「１、６、２０、９、５」等になる。但し、これは情報量を削減するためのパス障害情報の一例であり、その内容を限定するものではない。

図１０は、図３の説明において述べた障害情報の送信手順を示すシーケンス図である。
最初に、障害情報作成部２０９は、前記障害情報の送信要求１００１を障害情報送信部２１０へ送信する。次に、障害情報送信部２１０は、前記障害情報を監視装置２１５の障害情報受信部２１６へ送信する処理１００２を行う。次に、障害情報受信部２１６は、障害情報送信部２１０より受信した前記障害情報の通知要求１００３を障害情報通知部２１８へ送信する。障害情報通知部２１８は前記障害情報の解析処理１００４を行い、前記障害情報を人間が読むことのできる形式に変換し、メール送信等の手段により被監視装置２０２の管理者へ通知する処理１００５を行う。最後に、障害情報通知部２１８は、通知に成功したことを示すメッセージ１００６を障害情報受信部２１６へ送信し、障害情報受信部２１６は、障害情報の受信に成功したことを示すメッセージ１００７を障害情報送信部２１０へ送信し、障害情報送信部２１０は、障害情報の送信に成功したことを示すメッセージ１００８を障害情報作成部２０９へ送信する。以上の流れにより障害情報を被監視装置２０２の管理者に通知するが、これは一般的な通知方法を述べたものであり、通知方法を限定するものではない。

図１１はテストデータの更新手順を示すシーケンス図である。障害情報の通知を受けた管理者は、障害箇所をテストし、バグを修正したモジュールを配信すると共に、前記テストデータのテスト状態を更新することができる。

最初に、管理者１１０１は、被監視プログラム２０３に関する最新のテストデータを監視プログラム２１４へ入力する処理１１０２を行う。次に、監視プログラム２１４は、前記最新のテストデータを更新するメッセージを監視エージェント２０６へ送信する処理１１０３を行う。次に、監視エージェント２０６は、受信した前記最新のテストデータをデータベース２１２へ送信し、前記テストデータを更新する処理１１０４を行う。最後に、データベース２１２はテストデータの更新に成功したことを示すメッセージ１１０５を監視エージェント２０６へ送信し、監視エージェント２０６は、テストデータの受信に成功したことを示すメッセージ１１０６を監視プログラム２１４へ送信し、監視プログラム２１４は、テストデータの入力に成功したことを示すメッセージ１１０７を管理者１１０１へ送信する。以上の流れによりテストデータの更新を行うが、これは一般的な更新方法を述べたものであり、更新方法を限定するものではない。特に、テスト状態の更新は監視エージェント２０６が自動で行うことも考えられるが、ここでは一般的な例として管理者による更新処理を示したものである。

本発明に係る一般的なシステムのハードウェア構成を示す図である。本発明に係るモジュールの概念的な構成を示す図である。障害情報の生成手順の一例を示すフローチャートである。 JMX技術を利用した場合の状態監視手段の一例を示すシーケンス図である。モデルベース開発で用いられる状態遷移表の一例を示す図である。状態遷移表に対応した数値データの一例を示す表である。状態遷移履歴データの一例を示す表である。状態遷移表テストデータの一例を示す表である。状態遷移パステストデータの一例を示す表である。障害情報の送信方法の一例を示すシーケンス図である。テストデータの更新方法の一例を示すシーケンス図である。

符号の説明

１０１演算装置、１０２主記憶装置、１０３通信装置、１０４外部記憶装置、２０１ネットワーク、２０２被監視装置、２０３被監視プログラム、２０４状態遷移通知部、２０５障害通知部、２０６監視エージェント、２０７状態遷移監視部、２０８障害監視部、２０９障害情報策西部、２１０障害情報送信部、２１１テストデータ更新部、２１２データベース、２１３状態遷移表テストデータ、２１４状態遷移パステストデータ、２１５監視装置、２１６障害情報受信部、２１７テストデータ送信部、２１８障害情報通知部。

Claims

監視対象となるデバイスと、前記デバイスにおける障害の発生を監視する監視装置と、前記デバイスの障害データを記憶するデータベースである外部記憶装置とからなり、これら装置がネットワークを介してデータの送受信が可能な障害監視システムであって、
前記デバイス上で動作するプログラムモジュールにおいて発生した障害を監視する障害監視部と、前記プログラムモジュールの状態遷移を監視する状態遷移監視部と、前記障害監視部が障害の発生を検知した際に前記状態遷移監視部より状態遷移履歴情報を取得し、さらに前記外部記憶装置より前記プログラムモジュールに関して実施されたテストデータを取得し、前記状態遷移履歴情報および前記テストデータを基に障害情報を作成する障害情報作成部と、前記障害情報作成部により作成された障害情報を、ネットワークを介して前記監視装置に送信する障害情報送信部とを有することを特徴とする障害監視システム。
前記テストデータが、前記プログラムモジュールに関して実施された状態遷移表テストの結果に対応する状態遷移表テストデータ、または状態遷移パステストの結果に対応する状態遷移パステストデータ、またはその両方である請求項１記載の障害監視システム。
前記障害情報作成部が、前記状態遷移表テストデータと前記状態遷移履歴情報を基に、前記プログラムモジュールが前記状態遷移表テストですでに合格しているかどうかを判定し、合格している場合はメモリダンプや障害ログ等の詳細障害情報を作成し、合格していない場合は前記状態遷移表テストデータの状態遷移表に対応する簡易障害情報を作成する請求項２記載の障害監視システム。
前記障害情報作成部が、前記状態遷移パステストデータと前記状態遷移履歴情報を基に、前記プログラムモジュールが前記状態遷移パステストにすでに合格しているかどうかを判定し、合格している場合は前記詳細障害情報を作成し、合格していない場合は前記状態遷移パステストデータの状態遷移パスに対応するパス障害情報を作成する請求項３記載の障害監視システム。
前記障害情報作成部が、前記状態遷移表テストデータと、前記状態遷移履歴情報を基に、前記プログラムモジュールが前記状態遷移表テストにパスしているかどうかを判定し、パスしていない場合は前記簡易障害情報を作成し、パスしている場合は前記状態遷移パステストデータと、前記状態遷移履歴情報を基に、前記プログラムモジュールが前記状態遷移パステストにパスしているかどうかを判定し、パスしていない場合は前記パス障害情報を作成し、パスしている場合は前記詳細障害情報を作成する請求項２記載の障害監視システム。
前記障害情報作成部が、前記障害情報を前記監視装置に送信した際、前記状態遷移履歴情報に対応する前記テストデータを対策中のものとして前記外部記憶装置に記憶し、障害が再発した際、前記状態遷移履歴情報に対応する前記テストデータが対策中である場合は、前記障害情報の作成を行わず、また前記監視装置への前記障害情報の送信も行わない請求項１〜請求項５のいずれか１項に記載の障害監視システム。
前記デバイスの管理者等によって前記監視装置に入力された最新のテストデータおよびテストデータの対策状況を前記外部記憶装置に送信し、前記外部記憶装置が記憶するテストデータを更新させるテストデータ更新部を有する請求項１〜請求項６のいずれか１項に記載の障害監視システム。
プログラムモジュールを備え、監視装置及びデバイス障害データを記憶するデータベースである外部記憶装置とネットワークを介してデータの送受信が可能なデバイスであって、
前記プログラムモジュールにおいて発生した障害を監視する障害監視部と、前記プログラムモジュールの状態遷移を監視する状態遷移監視部と、前記障害監視部が障害の発生を検知した際に前記状態遷移監視部より状態遷移履歴情報を取得し、さらに前記外部記憶装置より前記プログラムモジュールに関して実施されたテストデータを取得し、前記状態遷移履歴情報および前記テストデータを基に障害情報を作成する障害情報作成部と、前記障害情報作成部により作成された障害情報を、ネットワークを介して前記監視装置に送信する障害情報送信部とを有することを特徴とするデバイス。
デバイスの管理者等によって最新のテストデータおよびテストデータの対策状況を入力し、外部記憶装置が記憶するテストデータを更新させるよう送信するテストデータ送信部を有することを特徴とする監視装置。
監視対象となるデバイスと、前記デバイスにおける障害の発生を監視する監視装置と、前記デバイスの障害データを記憶するデータベースである外部記憶装置とからなり、これら装置がネットワークを介してデータの送受信が可能な障害監視システムにおける障害を監視する方法であって、
前記デバイス上で動作するプログラムモジュールにおいて発生した障害を監視する障害監視ステップと、前記プログラムモジュールの状態遷移を監視する状態遷移監視ステップと、前記障害監視ステップにより障害の発生を検知した際に前記状態遷移監視ステップにより状態遷移履歴情報を取得し、さらに前記外部記憶装置より前記プログラムモジュールに関して実施されたテストデータを取得し、前記状態遷移履歴情報および前記テストデータを基に障害情報を作成する障害情報作成ステップと、前記障害情報作成ステップにより作成された障害情報を、ネットワークを介して前記監視装置に送信する障害情報送信ステップとを有することを特徴とする障害監視方法。
前記テストデータが、前記プログラムモジュールに関して実施された状態遷移表テストの結果に対応する状態遷移表テストデータ、または状態遷移パステストの結果に対応する状態遷移パステストデータ、またはその両方である請求項１０記載の障害監視方法。