JP2015138512A - 状態監視装置、状態監視方法、及び状態監視プログラム - Google Patents

Abstract

【課題】スケジューリングにより実行されるアプリケーションの実行ミスを回避する。【解決手段】状態監視装置において、予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部を有し、前記監視部は、動作中の他の監視部を監視し、異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持する。【選択図】図１

Description

本発明は、状態監視装置、状態監視方法、及び状態監視プログラムに関する。

Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ（ＰＣ）等の情報処理装置において、スケジューリングされた常駐アプリケーションの実行時に何らかの原因で停止又はエラーとなった場合、管理者等が目視で確認したり、個別にアプリケーションの再起動等が必要となる。

例えば、予め設定された監視情報から異常の有無を判断し、異常があると判断した場合に、対象のプロセスを再起動する障害監視システムや、２つのコンピュータ間でそれぞれの実行プログラムの停止を監視する監視プログラムが存在する。

特開２００１−５６７７２号公報 特開２００９−２８２６０１号公報

しかしながら、従来手法では、監視対象の状態を取得する間隔により問題が発生する。 例えば、間隔が数秒単位の短い間隔の場合には、システムへの負荷や監視ツール自体による他のアプリケーションへの影響が発生する可能性が大きくなる。逆に、数十分単位の長い間隔の場合には、監視対象アプリケーションでエラーが発生しても、状態の取得時間の谷間である場合には、すぐに異常を検知できない。

また、異常発生時の対応の一つである再起動は、顧客が作業中か又は事前に設定した時間帯でのＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）の再起動のみに対応しており、複数の監視対象アプリケーションの動作スケジュールに基づいた適切な再起動ができない。また、２つのコンピュータ間で監視する場合に、一方で問題が発生した時間が、他方の監視対象アプリケーションの起動前である場合には、監視対象アプリケーションのエラー確認が実施できない事態が発生する。

１つの側面では、本発明は、スケジューリングにより実行されるアプリケーションの実行ミスを回避することを目的とする。

一態様における状態監視装置は、予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部を有し、前記監視部は、動作中の他の監視部を監視し、異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持する。

スケジューリングにより実行されるアプリケーションの実行ミスを回避することができる。

状態監視装置の機能構成例を示す図である。 状態監視装置のハードウェア構成例を示す図である。 状態監視処理の一例を示すフローチャートである。 監視部における具体的な処理内容を説明するための図である。 監視ツールにおける監視対象アプリの監視内容を説明するための図である。 相互監視部の機能構成例を示す図である。 設定情報の入力画面例を示す図である。 記憶部に記憶される設定情報の一例を示す図である。 実施例に対応する設定情報の一例を示す図である。 監視ツールがダウンした場合の処理例を示す図（その１）である。 監視ツールがダウンした場合の処理例を示す図（その２）である。

以下、添付図面を参照しながら実施例について詳細に説明する。

＜本実施形態における状態監視装置の機能構成例＞
図１は、状態監視装置の機能構成例を示す図である。図１に示す情報処理装置の一例としての状態監視装置１０は、入力部１１と、出力部１２と、記憶部１３と、設定管理部１４と、監視部１５と、実行処理部１６と、監視対象アプリケーション（以下、必要に応じて「アプリケーション」を「アプリ」と略称する）１７とを有する。

入力部１１は、ユーザ等から本実施形態における状態監視処理に関する各種設定情報等の入力等を受け付ける。なお、入力部１１は、キーボードやマウス、タッチパネル等の入力インターフェースから入力された各種情報や指示の入力等を受け付けることができるが、これに限定されるものではない。

出力部１２は、設定情報の入力画面や入力部１１により入力された各種設定情報、入力された指示に対応する処理を実行した結果等を画面に表示してユーザに提示する。出力部１２は、例えばディスプレイやモニタ、タッチパネル等であるが、これに限定されるものではない。

記憶部１３は、本実施形態における状態監視装置１０の処理で必要な各種情報を記憶する。記憶部１３は、例えばユーザから入力された設定情報（例えば、実行するアプリ、アプリの動作スケジュール、動作テスト内容（コマンド等）、優先順位等）を記憶したり、処理実行命令情報、動作テスト結果、問題（異常、エラー）発生時の処理内容等を記憶する。記憶部１３は、例えばディスク装置やメモリ等のストレージ手段である。

設定管理部１４は、１又は複数の監視対象アプリ１７を監視する各監視部１５−１〜１５−ｎを同時に動作させ、各監視部１５−１〜１５−ｎに対する設定や指示等の管理を行う。例えば、設定管理部１４は、各監視部１５−１〜１５−ｎが正常に動作しているかの監視を各監視部同士で行わせたり、問題（異常、エラー）発生時の動作等の設定を行うこともできる。

監視部１５は、例えば状態監視装置１０で実行される１又は複数の監視対象アプリ１７のそれぞれを監視する監視ツール（ソフトウェア）である。監視部１５は、例えば予め割り当てられた１又は複数の監視対象アプリ１７を監視する。また、監視部１５は、他の監視部の監視も行う。例えば、本実施形態では、任意の個数の監視ツール（監視部１５）を起動させ、それぞれの監視ツールがそれぞれ他の監視ツール及び監視対象アプリの状態監視を実施する。そのため、ある１つの監視ツールが停止した場合でも、他の監視ツールが監視対象アプリの監視を継続することができる。

ここで、監視部１５の構成について説明する。監視部１５−１〜１５−ｎは、それぞれ、スケジュール管理部２１と、動作テスト実施部２２と、優先順位管理部２３と、問題発生時処理実施部（処理実施部）２４と、相互監視部２５とを有する。

スケジュール管理部２１は、設定管理部１４から設定情報を受け取り、受け取った設定情報に含まれるテストスケジュール等を動作テスト実施部２２に出力する。テストスケジュールは、例えば監視対象アプリ１７が実行する所定のタスクの実行時間に基づいて、その時間よりも所定時間前の時間が設定される。

動作テスト実施部２２は、スケジュール管理部２１から得られるテストスケジュールの通知内容に基づいて、実行処理部１６に対し、監視対象アプリ１７への動作テスト実施要求を出力する。動作テスト実施要求とは、例えば監視対象アプリ１７に対する動作テストコマンドの実施や動作状況確認等であるが、これに限定されるものではない。動作テストの内容は、例えば監視対象アプリ１７が通常行うタスクに対応して設定され、タスクと同様の内容が好ましいが、これに限定されるものではない。また、動作テスト実施部２２は、実行処理部１６からテスト結果を受け取り、その内容から問題が発生したと判断した場合に、問題発生通知を問題発生時処理実施部２４に出力する。

優先順位管理部２３は、設定管理部１４から設定情報を受け取り、受け取った設定情報に含まれる監視対象アプリ１７の優先順位を問題発生時処理実施部２４に出力する。問題発生時処理実施部２４は、動作テスト実施部２２から問題（異常、エラー）発生通知を受け取ると、その内容に対応する対処内容に基づく処理実行指示を実行処理部１６に出力する。なお、問題発生時処理実施部２４は、優先順位管理部２３から得られる優先順位に基づく処理実行指示を実行処理部１６に出力してもよい。相互監視部２５は、同時に動作している各監視部１５の相互の状況を監視し、問題が発生している場合には、その監視部１５の再起動等を行う。

実行処理部１６は、ユーザが入力部１１から入力した設定情報を受け付けると、その設定情報を記憶部１３に記憶する。また、実行処理部１６は、記憶部１３に記憶された設定情報を読み込み、読み込んだ設定情報を設定管理部１４に出力する。また、実行処理部１６は、設定情報に含まれるスケジュールに基づいて実行対象の監視対象アプリを設定されたタイミングで起動して処理を実行させる。

また、実行処理部１６は、監視部１５からの動作テスト実施要求等に基づいて、対応する監視対象アプリ１７に動作テストの処理の実施を要求し、監視対象アプリ１７からテスト結果（実行結果）を取得する。また、実行処理部１６は、設定画面や監視対象アプリ１７の実行結果等を示すような各種画面を出力部１２に出力する。

監視対象アプリ１７は、状態監視装置１０内で予め設定されたスケジューリングで所定のタスクを実行する１又は複数のアプリである。監視対象アプリ１７は、例えばユーザが指定したタイミングで実行するアプリや、ＯＳ起動中は常時動き続けると共に定期的に設定された処理を実行する常駐アプリ等がある。監視対象アプリ１７としては、例えばＴＶ録画アプリやセキュリティアプリ、情報収集アプリ、バックアップアプリ等がある。また、監視対象アプリ１７は、これに限定されるものではなく、例えば音楽配信やグループ電話、Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ（ＳＮＳ）等の各種サービス等でもよい。また、タスクとは、例えばＴＶ録画アプリにおける予約された番組の録画や、セキュリティアプリにおけるウィルスチェック、バックアップアプリにおけるバックアップファイルの作成等である。

図１の例では、それぞれ異なる監視対象アプリ１７−１〜１７−３を有しているが、数についてはこれに限定されるものではない。監視対象アプリ１７は、実行処理部１６から得られる監視部１５からの処理実施要求に基づいて、処理（テスト）を実施し、その結果を実行処理部１６に出力する。

状態監視装置１０は、ＰＣやサーバ等であるが、これに限定されるものではなく、例えばタブレット端末やスマートフォン等の情報端末でもよい。本実施形態では、上述した状態監視装置１０を用いて、監視ツール（監視部１５）がユーザに指定されたアプリ（サービス等を含む）を監視し、停止状態や、問題（異常、エラー）が発生した際に、設定情報に基づき、そのアプリの再起動やＯＳ自体の再起動を自動で実行する。これにより、本実施形態では、予めスケジューリングされて実行されるアプリが、確実に実施されるようになり、アプリの実行ミスを回避できる。

なお、本実施形態では、上述した監視ツール（監視部１５）自体も常駐アプリに相当する。そのため、監視ツールの動作が停止することを回避する必要がある。そこで、本実施形態では、上述したように、複数の監視ツールを同時に動作させ、相互監視部２５において各監視ツール同士を監視させる。これにより、例えばある監視ツールに異常が発生した場合に、その監視ツールを再起動させることで、常に複数の監視ツールが起動している状況を維持することができる。

また、本実施形態では、監視ツールが、監視対象アプリの動作スケジュール（タスクの実行スケジュール）に対応させて、その直前に動作テストを実施して問題が発生しているかを確認することで、装置全体の負荷を最小限に抑止し、状況を取得する谷間も存在しない。また、本実施形態では、複数の監視対象アプリの動作スケジュールに基づいて動的に再起動が可能かの判断が実施されるため、より適切な時間に再起動を実施することができる。

＜ハードウェア構成例＞
図２は、状態監視装置のハードウェア構成例を示す図である。図２に示す状態監視装置１０のコンピュータ本体には、入力装置３１と、出力装置３２と、ドライブ装置３３と、補助記憶装置３４と、主記憶装置３５と、各種制御を行うＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）３６と、ネットワーク接続装置３７とを有するよう構成されており、これらはシステムバスＢで相互に接続されている。

入力装置３１は、状態監視装置１０のユーザ等が操作するキーボード及びマウス等のポインティングデバイスや、マイクロフォン等の音声入力デバイスを有する。入力装置３１は、ユーザ等からのプログラムの実行指示、各種設定情報、アプリ等を起動するための情報等の入力を受け付ける。

出力装置３２は、本実施形態における処理を行うためのコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、ＣＰＵ３６が有する状態監視プログラムによりプログラムの実行経過や結果等を表示する。また、出力装置３２は、上述の処理結果等を紙等の印刷媒体に印刷して、ユーザ等に提示する。

ここで、本実施形態においてコンピュータ本体にインストールされる実行プログラムは、可搬型の記録媒体３８等により提供される。プログラムを記録した記録媒体３８は、ドライブ装置３３にセット可能であり、ＣＰＵ３６からの制御信号に基づき、記録媒体３８に含まれる実行プログラムが、記録媒体３８からドライブ装置３３を介して補助記憶装置３４にインストールされる。

補助記憶装置３４は、例えばＨａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）やＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等のストレージ手段等である。補助記憶装置３４は、ＣＰＵ３６からの制御信号に基づき、本実施形態における実行プログラムや、コンピュータに設けられた状態監視プログラム等を記憶し、必要に応じて入出力を行う。補助記憶装置３４は、ＣＰＵ３６からの制御信号等に基づいて、記憶された各情報から必要な情報を読み出したり、書き込むことができる。

主記憶装置３５は、ＣＰＵ３６により補助記憶装置３４から読み出された実行プログラム等を格納する。なお、主記憶装置３５は、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）やＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）等である。なお、補助記憶装置３４及び主記憶装置３５は、例えば上述した記憶部１３に対応している。

ＣＰＵ３６は、ＯＳ等の制御プログラム、及び主記憶装置３５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御して各処理を実現することができる。プログラムの実行中に必要な各種情報等は、補助記憶装置３４から取得することができ、また実行結果等を格納することもできる。

具体的には、ＣＰＵ３６は、例えば入力装置３１から得られるプログラムの実行指示等に基づき、補助記憶装置３４にインストールされた状態監視プログラムを実行させることにより、主記憶装置３５上でプログラムに対応する処理を行う。

例えば、ＣＰＵ３６は、状態監視プログラムを実行させることで、例えば上述した設定管理部１４による管理、監視部１５によるアプリやツールの監視、実行処理部１６による各種処理の実行制御等を行う。なお、ＣＰＵ３６における処理内容は、これに限定されるものではない。

ネットワーク接続装置３７は、ＣＰＵ３６からの制御信号に基づき、通信ネットワーク等と接続することにより、実行プログラムやアプリ、設定情報等を、通信ネットワークに接続されている外部装置等から取得する。また、ネットワーク接続装置３７は、プログラムを実行することで得られた実行結果又は本実施形態における実行プログラム自体を外部装置等に提供することができる。

記録媒体３８は、例えばＣｏｍｐａｃｔ Ｄｉｓｋ（ＣＤ）、Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ（ＤＶＤ）、ＳＤメモリカード、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）メモリ等であるが、これに限定されるものではない。

図２に示すハードウェア構成に実行プログラム（例えば、状態監視プログラム等）をインストールすることで、ハードウェア資源とソフトウェアとが協働して本実施形態における状態監視処理等を実現することができる。

＜状態監視処理の一例＞
次に、本実施形態における状態監視処理について具体的に説明する。図３は、状態監視処理の一例を示すフローチャートである。図３の例において、状態監視装置１０のＯＳが起動されると（Ｓ０１）、監視ツールの条件設定等を行う（Ｓ０２）。Ｓ０２の処理では、例えば、入力部１１により、監視対象設定や、監視対象の重要度（優先度）の設定、動作状況確認手順又は動作テスト設定、問題発生時の処理設定等を行う。

監視対象設定とは、例えば監視対象アプリに対する動作テストの実行ファイル（＊．ｅｘｅ）や実行サービス、監視対象の実行時間（タスクの実行スケジュール）等の設定である。監視対象の重要度設定とは、例えば複数のアプリの実行スケジュールが重なった場合に監視する優先順位等の設定である。動作状況確認手順又は動作テスト設定とは、例えば監視対象アプリの動作確認手順や動作テストの内容等の設定である。問題発生時の処理設定とは、例えばテスト時に問題が発生した際にＯＳ毎の再起動、アプリ毎の再起動、サービス毎の再起動等、関連サービスも含めて１又は複数の再起動等の設定である。なお、設定内容については、上述した例に限定されるものではなく、例えば設定された各処理を実行するタイミングやスケジュール等を設定してもよい。

次に、状態監視装置１０は、監視ツール（監視部１５）の起動と監視ツール自体の動作確認を行う（Ｓ０３）。Ｓ０３の処理では、複数の監視ツールを起動し、各監視ツール同士が正常に動作しているかを相互に監視する。

ここで、各監視ツールが正常に動作しているか否かを判断し（Ｓ０４）、各監視ツールが正常動作していない場合（Ｓ０３において、ＮＯ）、Ｓ０３の処理に戻り、監視ツールの再起動を実施する。

また、監視ツールが正常動作している場合（Ｓ０３において、ＹＥＳ）、監視部１５は、監視対象アプリ１７の監視を開始する（Ｓ０５）。Ｓ０５の処理では、監視ツール自体の動作確認も予め設定されたスケジュール等に基づいて実施する。例えば、監視対象アプリ１７への動作テストを実施する場合には、監視ツール内での優先順位に従う。例えば、５つの監視ツール（監視部１５−１〜１５−５）が起動している場合、優先順位を高く設定した「監視ツール１」のみが動作テストのタスクを実行させる。

ここで、監視ツールの動作確認時刻か否かを判断し（Ｓ０６）、監視ツールの動作確認時刻である場合（Ｓ０６において、ＹＥＳ）、Ｓ０４の処理に戻り、相互監視部２５により監視ツールの動作確認を行う。

また、監視ツールの動作確認時刻でない場合（Ｓ０６において、ＮＯ）、予め設定された監視対象アプリ１７の起動時刻か否かを判断する（Ｓ０７）。監視対象アプリ１７の起動時刻でない場合（Ｓ０７において、ＮＯ）、Ｓ０５の処理に戻る。また、監視対象アプリ１７の起動時刻である場合（Ｓ２７において、ＹＥＳ）、動作状況確認又は動作テストを開始する（Ｓ０８）。

Ｓ０８の処理では、例えば監視対象アプリ１７のタスクの実行スケジュールに基づいて、タスク実行時刻の少し前（例えば、数秒前又は数分前等の所定時間前）に監視ツールによる監視対象アプリの動作状況確認又は動作テスト等を実施する。なお、上記の所定時間は、動作テストの実行時間や、テスト結果で監視対象アプリ１７に問題が発生していると判断した場合に、再起動等の対処が行える時間以上の時間が設定されるのが好ましい。

動作状況の確認としては、例えば予めスケジュールされている処理と同様の処理を実施し、その結果から動作確認を行うことができる。例えば、監視対象アプリが情報収集アプリである場合には、収集された情報が送信された履歴があるかを確認する。また、監視対象アプリが録画アプリである場合には、録画されたファイルが存在するかを確認する。また、監視対象アプリが、バックアップアプリであれば、バックアップファイルが存在するかを確認する。

また、監視対象アプリの動作異常の判断基準としては、例えば予め設定したアプリ実行ファイルやサービスが存在しない（問題が発生し終了してしまった場合）や、特定のエラーコード、イベントログを出力している等がある。なお、判断基準は、これに限定されるものではなく、例えばエラーが発生した際のＯＳのイベントログの状況、エラーが発生した際のアプリのエラーコード情報、正常に動作した際に作成されるファイル等が存在するか否か等を基準に判断することができる。なお、上述した動作状況の確認内容や動作異常の判断基準は、アプリ毎に設定することができるが、上述した例に限定されるものではない。

Ｓ０８の処理後、動作テストの実施で問題（異常）が発生したか否かを判断し（Ｓ０９）、問題が発生した場合（Ｓ０９において、ＹＥＳ）、問題発生時の処理を実施し（Ｓ１０）、Ｓ０５の処理に戻る。Ｓ１０の処理では、監視ツール（監視部１５）が予め設定された対処内容に基づく処理を実行する。実行する対処としては、例えば「ＯＳの再起動（監視ツールがＯＳに再起動要求を実行する）」、「アプリ、サービスの再起動（監視ツールが予め設定された監視対象実行ファイルやサービスを起動させ、再度常駐状態にする）」等がある。

また、Ｓ１０の処理では、優先順位による処理実行を行うことができる。例えば、ＯＳの再起動に関しては、予め設定した監視優先順位に基づいて判断することができる。例えば、アプリＡ（監視対象アプリ１７−１）が、動作異常でＯＳの再起動が必要な場合でも、アプリＡより優先度の高いアプリＢ（監視対象アプリ１７−２）のタスク実行スケジュール時刻と重なっていた場合には、アプリＡのための再起動動作はアプリＢの動作が終了してからとなる。

また、Ｓ０９の処理において、動作テストで問題が発生していない場合（Ｓ０９において、ＮＯ）、次に、処理終了か否かを判断し（Ｓ１１）、処理終了でない場合（Ｓ１１において、ＮＯ）、Ｓ０５の処理に戻り、監視を継続する。また、処理終了である場合（Ｓ１１において、ＹＥＳ）、状態監視処理を終了する。

＜監視部１５における具体的な処理内容＞
次に、上述した監視部１５における具体的な処理内容について図を用いて説明する。図４は、監視部における具体的な処理内容を説明するための図である。図４の例において、まず、ユーザ等が必要情報を入力する。必要情報とは、上述したように各監視対象アプリの設定等の入力であり、例えば、監視対象（実行ファイル、サービス等）、実行スケジュール、アプリの優先順位、動作確認手順、問題発生時の対処動作等から１又は複数が選択的に入力される。

設定管理部１４は、入力された必要情報に基づいて各監視部１５（例えば、図４に示す監視ツール１〜４）に設定内容を通知する。具体的には、設定管理部１４は、スケジュール管理部２１にスケジュール（例えば監視ツールのテストスケジュール）を通知する。スケジュール管理部２１は、実際の処理を動作テスト実施部２２に通知する。

動作テスト実施部２２は、通知された監視ツールのテストスケジュールに基づいて、監視対象アプリの動作確認を実施し、その動作結果に基づいて動作テスト結果の判定を行う。動作テスト結果の判定では、例えば監視対象アプリの動作確認による監視対象アプリの状態を判定する。

次に、動作テスト実施部２２は、動作テストの結果として問題（異常）が発生していた場合に、その旨を問題発生時処理実施部２４に出力する。

問題発生時処理実施部２４は、監視対象アプリの動作確認結果に問題があった場合に、予め設定された優先順位や問題発生時に対処内容に基づいて、監視対象アプリの再起動処理等を実施する。なお、優先順位は、設定管理部１４から優先順位管理部２３に通知される。優先順位管理部２３は、監視対象アプリの優先順位に基づいて実際の処理を問題発生時処理実施部２４に通知する。また、問題発生時の対処内容は、設定管理部１４から通知される。

相互監視部２５は、監視ツール同士の相互監視を実施し、他の監視ツールに問題が発生した場合にはそのツールの再起動等を実施する。つまり、本実施形態では、同時期に実行しているそれぞれの監視ツールが相互に監視を実施する。また、各監視ツールがそれぞれ監視対象アプリを監視する。

ここで、図５は、監視ツールにおける監視対象アプリの監視内容を説明するための図である。図５の例では、複数の監視対象アプリＡ〜Ｃ（上述した監視対象アプリ１７−１〜１７−３に相当する）がある場合に、複数の監視ツール１〜３（上述した監視部１５−１〜１５−３に相当する）で、各監視対象アプリの全て（複数）を監視する。また、図５の例では、各監視ツール１〜３同士も監視する。これにより、スケジューリングされて実行されるアプリの実行ミスを回避することができる。

なお、図５の例では、３つの監視ツールと３つの監視対象アプリを設けた例について説明したが、数については、これに限定されるものではない。例えば、図５に示すように、監視ツールが３つ起動している場合、監視ツール１は、監視ツール２と監視ツール３の動作を監視する。監視ツール２は、監視ツール１と監視ツール３の動作を監視する。監視ツール３は、監視ツール１と監視ツール２の動作を監視する。

ここで、複数の監視ツールが正常に起動している場合、各監視対象アプリの動作テストを実施するのはツール内での優先順位に依存する。これは、複数の監視ツールが同時に動作テストを実施することを回避するためである。

＜相互監視部２５の機能構成例＞
次に、上述した相互監視部２５の機能構成例について図を用いて説明する。図６は、相互監視部の機能構成例を示す図である。図６では、一例として、２つの監視ツールによる相互監視動作として、例えば監視ツール１が監視ツール２を監視している状況を示しており、説明の便宜上、ツール内の相互監視部２５のみを抜き出して記載している。

図６に示す相互監視部２５−１，２５−２（以下、必要に応じて「相互監視部２５」という）は、それぞれ動作確認用信号発信部４１（４１−１、４１−２）と、動作確認用受信部４２（４２−１、４２−２）と、動作確認部４３（４３−１、４３−２）と、再起動実施部４４（４４−１、４４−２）とを有する。

動作確認用信号発信部４１は、定期的に他の監視ツールが動作しているか確認用の信号を送信する。図６の例では、監視ツール１から監視ツール２に対して動作確認信号が送信される。動作確認用受信部４２は、他の監視ツールから送信された動作確認信号を受信し、動作していることを示す信号を返信する。図６の例では、監視ツール２が、監視ツール１からの動作確認信号を受信し、返信信号を監視ツール１に送信する。

動作確認部４３は、他の監視ツールの動作を確認する。例えば、動作確認部４３は、他の監視ツールに動作確認信号を送信してから所定時間内に返信信号を受信したか否かにより動作を確認することができる。この場合、動作確認部４３は、所定時間内に返信信号を受信していれば、その監視ツールは、正常に動作している判断し、所定時間内に返信信号を受信していなければ、その監視ツールは、問題（異常）ありと判断することができる。なお、動作確認内容は、これに限定されるものではなく、例えば返信信号の内容を確認し、エラーコード等の異常を示す情報が含まれている場合には、問題ありと判断してもよい。図６の例では、監視ツール２からの返信信号に問題ありを示す情報が含まれていた場合を示している。

再起動実施部４４は、問題のあった監視ツールに対し再起動処理を行う。図６の例では、監視ツール１から監視ツール２に再起動処理が送信される。再起動処理を受け取った漢詩ツールは、ツールの再起動を実行する。

なお、図６に示す相互監視部２５は、監視ツール内の他の部分から独立して動作する。また、図６の例では、２つの監視ツールによる相互監視動作を示したが、３以上の監視ツール間でも他の監視ツールに対して同様の相互監視動作が行われる。

＜設定情報の入力画面例＞
次に、上述した入力部１１においてユーザ等が入力する各設定情報の入力画面例（ユーザインターフェース）について、図を用いて説明する。図７は、設定情報の入力画面例を示す図である。図７の例では、画面５０−１から画面５０−１０の順に画面が遷移することで、ユーザが各種設定情報を入力する。

まず、図７の例では、ＯＳの起動後に画面５０−１が表示される。画面５０−１の下部のタスクバーには、画面５０−２に示すような監視対象アプリ登録に関する設定情報と、監視ツールに関する設定情報を入力するための画面を表示する２つのボタンが表示されている。

ここで、画面５０−２から「監視ツール設定」を選択すると、監視ツールの並列動作数及び監視ツール間の動作確認間隔の設定画面５０−３が表示される。ユーザは入力部１１により画面５０−３に表示された各情報に対する設定を行う。設定が完了すると、入力された情報が記憶部１３に記憶される。

また、画面５０−２で「監視対象アプリ登録」を選択すると、画面５０−４に示す入力フォームが表示される。ユーザは、入力部１１により監視対象アプリ名の設定を行う。また、ユーザは、画面５０−５で動作スケジュールファイルの設定を行い、画面５０−６で監視対象アプリの優先度（重要度）の設定を行う。また、ユーザは、画面５０−７で動作テストコマンド及びテスト実行時間の設定を行う。動作テストコマンドの設定とは、例えば監視対象アプリに対する動作テストの実行ファイル（＊．ｅｘｅ）や実行サービス等の設定等であるが、これに限定されるものではない。また、テスト実行時間は、実際に実施される各アプリの実行スケジュールを基準として、その実行スケジュールから所定時間前に動作テストを行うかを設定する。例えば、監視対象アプリの動作スケジュールが「毎日１４：００」である場合に、テスト実行時間として１２０秒前（「毎日１３：５８」）と設定する。本実施形態では、監視対象アプリが実際に動作するタイミングの直前に動作確認を行うことで、スケジューリングにより実行されるアプリの実行ミスを適切に回避することができる。

次に、ユーザは、画面５０−８で動作テスト確認後の結果ファイルの保存先（例えばアプリのログ、ＯＳのログ等）の設定を行う。このとき、画面５０−９に示すように、結果がＯＫの場合とＮＧの場合とで、異なる保存先を設定することができる。次に、ユーザは、画面５０−１０で結果がＮＧの動作に対する対処内容（オペレーション）の設定を行う。上述した図７で設定された情報は、記憶部１３に設定情報として記憶される。

図８は、記憶部に記憶される設定情報の一例を示す図である。図８（Ａ）は、監視ツール設定情報の一例を示し、図８（Ｂ）は、監視対象アプリ登録情報の一例を示す。図８（Ａ）に示す監視ツール設定情報の項目としては、例えば「並列動作数」、「動作確認間隔」等があるが、これに限定されるものではない。また、図８（Ｂ）に示す監視対象アプリ登録情報の項目としては、例えば「監視対象アプリ名」、「動作スケジュール」、「優先度」、「動作テストコマンド」、「テスト実行時間」、「結果ファイル」、「オペレーション」等があるが、これに限定されるものではない。

ここで、「優先度」は、数値が小さい方が優先度が高いことを示しており、優先度が「１」の場合には、そのアプリが最優先であることを示すが、これに限定されるものではない。また、「テスト実行時間」は、動作スケジュールに設定されたタスクの実行時間を基準にして、その時間よりも所定時間前の時間が設定される。この「テスト実行時間」は、例えば、数秒前や数分前等のようにタスク実行時間の直前の時間であることが好ましく、例えば動作テストの実行時間や、テスト結果で問題があった場合に再起動時間以上の時間が設定される。また、「結果ファイル」は、ＯＫ又はＮＧ時のファイル保存先（アドレス情報）等を示している。また、「オペレーション」における「Ｒｅｂｏｏｔ ＯＳ」は、ＯＳの再起動を示し、「Ｃ：￥Ｐｒｏｇｒａｍ Ｆｉｌｅｓ￥ＢＢＢ￥ＢＢＢ．ｅｘｅ／ｒ」は、指定したアプリの再起動を示している。上述した各項目は、図７に示すユーザインタフェースを用いて入力することができ、ユーザは任意に設定の変更や削除等を行うことができる。

＜実施例＞
ここで、上述した本実施形態における状態監視処理を適用した実施例について、図を用いて説明する。なお、以下の説明では、監視対象アプリの例として、例えば「ＴＶ録画アプリ」と「セキュリティアプリ」の２つのアプリを用いる。

まず、ユーザは、上述した図７に示すユーザインタフェースを用いて、各アプリに対する設定情報を入力する。設定情報としては、例えば各アプリの実施ファイル（例えば、ＴＶＲＥＣ．ｅｘｅ、ＡＮＴＩＶＩＲＵＳ（登録商標）．ｅｘｅ）や、各アプリの実行スケジュール等であるが、これに限定されるものではない。

図９は、実施例に対応する設定情報の一例を示す図である。図９（Ａ）は、「ＴＶ録画アプリ」に対応する設定情報を示し、図９（Ｂ）は、「セキュリティアプリ」に対応する設定情報を示している。ユーザにより設定された図９（Ａ）,（Ｂ）に示す各設定情報は、記憶部１３に記憶される。

次に、図９（Ａ）,（Ｂ）に設定された情報に基づいて、監視ツール（監視部１５）は、各監視対象アプリが正常に動作しているかを動作テストにより監視する。例えば、設定したスケジュールに基づくタイミングで、「ＴＶ録画アプリ」の動作テストとして実際に１チャンネルを３０秒録画し、録画したファイルが存在するかの確認を実施する。また、設定したスケジュールに基づくタイミングで、「セキュリティアプリ」の動作テストとして実際にＡＮＴＩＶＩＲＵＳ．ｅｘｅが起動していることの確認を実施する。

ここで、監視ツールは、動作テストの結果を確認し、「ＴＶ録画アプリ」に問題が発生していた場合に、図９（Ａ）に示す設定情報に基づき、ＯＳに再起動を行う。また、監視ツールは、動作テストの結果を確認し、「セキュリティアプリ」に問題が発生していた場合に、図９（Ｂ）に示す設定情報に基づき、アプリケーションの再起動を行う。なお、実施例では、優先順位が設定されており、「ＴＶ録画アプリ」のスケジュールを最優先する設定であるため、ＯＳの再起動が優先的に実施される。また、「セキュリティアプリ」のみに問題が発生した場合には、「ＴＶ録画アプリ」が最優先されるため、録画スケジュールが実行終了するまで、アプリの再起動を実施しないようにしてもよい。また、ＯＳやアプリに再起動後は、実際のスケジュールに基づいてタスクが実行される。

なお、本実施例では、実際に実施される各アプリの録画スケジュール、ウイルスチェックスケジュールに基づいて、その数分前又は数秒前にＰＣを起動し、予め設定された動作テスト等により監視対象アプリが正常に動作するかの確認を行う。これにより、スケジューリングにより実行されるアプリの実行ミスを回避することができる。

＜監視ツールがダウンした場合の対応例＞
ここで、本実施形態では、監視ツール自体に異常が発生する（監視ツール自体がダウンする）場合もある。そのような場合には、相互監視部２５が他の監視ツールの異常を検知して対応を行う。ここで、本実施形態において、監視ツールがダウンした場合の処理例について図を用いて説明する。

図１０，図１１は、監視ツールがダウンした場合の処理例を示す図（その１，その２）である。図１０，図１１の例では、監視ツール１〜３を有し、それぞれの監視ツールに優先順位が設定されている。この優先順位にしたがって、対応する監視ツールが監視対象アプリに対して動作テストを実施する。また、図１０，図１１の例では、上から下に時系列に処理が行われているものとする。

図１０の例は、監視ツール１〜３が正常に動作している場合の例を示し、図１１の例は、監視ツール１がダウン状態（正常に動作していない状態）となった場合を示している。図１０の例において、各監視ツール１〜３は、共に設定管理部１４から得られる設定情報から動作テスト開始時間を認識し（Ｓ２１〜Ｓ２３）、優先順位を確認する（Ｓ２４〜Ｓ２６）。監視ツール２は、上位の監視ツール１からの動作テスト実施の通知を待つ（Ｓ２７）。また、監視ツール２は、監視ツール１，２からの動作テスト実施の通知を待つ（Ｓ２８）。

次に、監視ツール１は、動作テストを実施する通知を全ツール（監視ツール２，３）へ送信する（Ｓ２９）。監視ツール２，３は、上位の監視ツール１からの実施通知を受け取り、返信を送信し（Ｓ３０，Ｓ３１）、その先の処理を停止する（Ｓ３２，Ｓ３３）。

監視ツール１は、監視対象アプリの動作テストを実施し（Ｓ３４）、問題があれば問題発生時の処理を実行する（Ｓ３５）。また、監視ツール１は、全ツール（監視ツール２，３）から実施通知に対する返信を受信したら処理を停止する（Ｓ３６）。

一方、図１１の例に示すように、監視ツール１が正常に動作しておらず（ダウン状態）、上述したＳ２４，Ｓ２９，Ｓ３４，Ｓ３５の処理が実施できない場合、監視ツール２が処理を実施する。この場合、監視ツール２は、上位の監視ツール１からの動作テスト実施の通知を動作テスト開始時間から所定時間待ったが（Ｓ２７）、上位からの実施通知を受信できないため処理を実施する（Ｓ４１）。

監視ツール２は、動作テストを実施する通知を全ツール（監視ツール１，３）へ送信し（Ｓ４２）、監視対象アプリの動作テストを実施する（Ｓ４３）。また、監視ツール２は、問題があれば問題発生時の処理を実行する（Ｓ４４）。

このとき、監視ツール１は、他の監視ツール（例えば、監視ツール２の相互監視部等）等からの再起動処理により、ツールの再起動を行い（Ｓ４５）、監視ツール２からの実施通知を受け取り、返信を送信する（Ｓ４６）。

なお、監視ツール３は、図１０の例と同様の処理を行い、上位（図１１の例では、監視ツール２）からの実施通知を受け取り、返信を送信し（Ｓ３１）、その先の処理を停止する（Ｓ３３）。

監視ツール２は、全ツール（監視ツール１，３）から実施通知への返信を受信したら処理を停止する（Ｓ４８）。

このように、本実施形態によれば、複数のツールを同時に動作させ、各監視ツール同士を監視させることで、一つの監視ツールがダウンした場合でも、その監視ツールを再起動させることができる。更に上述した図１１に示すように、動作テストが実行できない監視ツールの代わりの他の監視ツールが、設定した時間通りに動作テストを実施することができる。したがって、本実施形態では、常に複数の監視ツールが起動している状況を保つことで、適切な時間にアプリの動作テストを実行できるため、スケジューリングによりタスクを実行するアプリの実行ミスを回避することができる。

上述したように本実施形態によれば、スケジューリングにより実行されるアプリケーションの実行ミスを回避することができる。例えば、本実施形態によれば、スケジューリングされて動作するアプリケーションを監視することで、実行前に動作テストを行いエラー等を検知し対処することで、スケジュール通りにアプリケーションが動作することを可能とする。

以上、実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、上述した各実施例の一部又は全部を組み合わせることも可能である。

なお、以上の実施例に関し、更に以下の付記を開示する。
（付記１）
予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部を有し、
前記監視部は、動作中の他の監視部を監視し、異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持することを特徴とする状態監視装置。
（付記２）
前記監視部は、
前記スケジュールに基づく動作テストの実行時間を管理するスケジュール管理部と、
前記スケジュール管理部で管理された時間に前記アプリケーションに対して動作テストを実施する動作テスト実施部と、
前記アプリケーションに対する優先順位を管理する優先順位管理部と、
前記動作テスト実施部による動作テストの結果で異常が発生していると判断されたアプリケーションに対して、前記優先順位管理部から得られる優先順位に基づく処理を実施する処理実施部とを有することを特徴とする付記１に記載の状態監視装置。
（付記３）
前記監視部は、
動作中の他の監視部を監視する相互監視部を有し、
前記相互監視部は、前記他の監視部に動作確認信号を送信し、前記動作確認信号に対する前記他の監視部からの返信信号に基づいて、前記他の監視部に再起動処理を行うことを特徴とする付記１又は２に記載の状態監視装置。
（付記４）
前記監視部は、
前記アプリケーションに対して前記動作テストを実行する前記他の監視部に異常が発生していた場合に、前記他の監視部に代わって前記動作テストを実行することを特徴とする付記２に記載の状態監視装置。
（付記５）
前記動作テストは、前記アプリケーションにおいて前記所定のタスクが実行される時間に基づいて、前記時間よりも所定時間前に実行することを特徴とする付記２に記載の状態監視装置。
（付記６）
状態監視装置が、
予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部同士を監視し、
異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持することを特徴とする状態監視方法。
（付記７）
予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部同士を監視し、
異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持する、処理をコンピュータに実行させる状態監視プログラム。

１０ 状態監視装置（情報処理装置）
１１ 入力部
１２ 出力部
１３ 記憶部
１４ 設定管理部
１５ 監視部
１６ 実行処理部
１７ 監視対象アプリ
２１ スケジュール管理部
２２ 動作テスト実施部
２３ 優先順位管理部
２４ 問題発生時処理実施部（処理実施部）
２５ 相互監視部
３１ 入力装置
３２ 出力装置
３３ ドライブ装置
３４ 補助記憶装置
３５ 主記憶装置
３６ ＣＰＵ
３７ ネットワーク接続装置
３８ 記録媒体
４１ 動作確認用信号発信部
４２ 動作確認用受信部
４３ 動作確認部
４４ 再起動実施部
５０ 画面

Claims (6)

1. 予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部を有し、
   前記監視部は、動作中の他の監視部を監視し、異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持することを特徴とする状態監視装置。
2. 前記監視部は、
   前記スケジュールに基づく動作テストの実行時間を管理するスケジュール管理部と、
   前記スケジュール管理部で管理された時間に前記アプリケーションに対して動作テストを実施する動作テスト実施部と、
   前記アプリケーションに対する優先順位を管理する優先順位管理部と、
   前記動作テスト実施部による動作テストの結果で異常が発生していると判断されたアプリケーションに対して、前記優先順位管理部から得られる優先順位に基づく処理を実施する処理実施部とを有することを特徴とする請求項１に記載の状態監視装置。
3. 前記監視部は、
   動作中の他の監視部を監視する相互監視部を有し、
   前記相互監視部は、前記他の監視部に動作確認信号を送信し、前記動作確認信号に対する前記他の監視部からの返信信号に基づいて、前記他の監視部に再起動処理を行うことを特徴とする請求項１又は２に記載の状態監視装置。
4. 前記動作テストは、前記アプリケーションにおいて前記所定のタスクが実行される時間に基づいて、前記時間よりも所定時間前に実行することを特徴とする請求項２に記載の状態監視装置。
5. 状態監視装置が、
   予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部同士を監視し、
   異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持することを特徴とする状態監視方法。
6. 予め設定されたスケジュールに基づいて所定のタスクが実行されるアプリケーションを監視する複数の監視部同士を監視し、
   異常が発生した監視部が存在した場合に、前記異常が発生した監視部を再起動させて、前記複数の監視部が起動している状況を維持する、処理をコンピュータに実行させる状態監視プログラム。

Images