(57)【要約】【課題】業務プログラムの稼動状態を安定的に監視し、異常と判断した場合には、業務プログラムの動作を抑えることを可能とする業務プログラム監視制御システムを提供することを目的とする。【解決手段】監視装置２１と、監視装置２１と通信可能な顧客コンピュータ１０の処理により稼動するランチャーと、顧客コンピュータ１０が有する記憶手段１２に格納された監視ルールと、を備え、ランチャーは、業務プログラムをランチャーの子プロセスとして稼動させ、業務プログラムの稼動状態を監視ルールと比較し、監視ルールに該当する場合は異常と判断し、ランチャーにより業務プログラムの動作を抑える動作制御を行い、かつ、監視装置２１に異常を通知することにより上記課題を解決する。【選択図】図１
2008269383.tif 000002
【特許請求の範囲】
【請求項１】
監視装置と、当該監視装置と通信可能な顧客コンピュータの処理により稼動するランチャーと、前記顧客コンピュータが有する記憶手段に格納された監視ルールと、を備える業務プログラム監視制御システムにおいて、
前記ランチャーは、業務プログラムを当該ランチャーの子プロセスとして稼動させ、当該業務プログラムの稼動状態を前記監視ルールと比較し、当該監視ルールに該当する場合は異常と判断し、当該ランチャーにより前記業務プログラムの動作を抑える動作制御を行い、かつ、前記監視装置に異常を通知することを特徴とする業務プログラム監視制御システム。
【請求項２】
請求項１に記載の業務プログラム監視制御システムにおいて、前記業務プログラムの起動の際は、
前記顧客コンピュータの処理により、当該業務プログラムの親プロセスであるランチャーを起動し、当該ランチャーを介して前記業務プログラムを起動することを特徴とする業務プログラム監視制御システム。
【請求項３】
請求項１に記載の業務プログラム監視制御システムにおいて、前記監視ルールは、業務プログラムごとに設定が可能であることを特徴とする業務プログラム監視制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務プログラム監視制御システムに関し、特に、業務プログラムの稼動状態を常に監視し、異常と判断した場合には、業務プログラムの動作を抑えることを可能とする業務プログラム監視制御システムに関する。
【背景技術】
【０００２】
ＰＣ、サーバ等の情報機器において、業務プログラムのループを検知した場合、他の業務プログラムの稼働に影響を与えないために、異常が発生した業務プログラムを強制終了する対処を実施している。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、業務プログラムの異常兆候を検出し、対象業務を強制終了させる対処では次の課題がある。（ａ）異常兆候の検知が誤検出であった場合に、正常な業務を終了させてしまう。（ｂ）業務を強制終了させる対処が遅れた場合、他の業務プログラムが動けなくなるため、影響が拡大する。（ｃ）異常の業務プログラムを強制終了させてしまうと、お客様コンピュータから業務プログラムを消すことになるため、異常状態が消えてしまい、調査不可能となる。
【０００４】
上記の課題に鑑みて、本発明は、業務プログラムの稼動状態を常に監視し、異常と判断した場合には、業務プログラムの動作を抑えることを可能とする業務プログラム監視制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明の業務プログラム監視制御システムは、  監視装置と、当該監視装置と通信可能な顧客コンピュータの処理により稼動するランチャーと、前記顧客コンピュータが有する記憶手段に格納された監視ルールと、を備える業務プログラム監視制御システムにおいて、前記ランチャーは、業務プログラムを当該ランチャーの子プロセスとして稼動させ、当該業務プログラムの稼動状態を前記監視ルールと比較し、当該監視ルールに該当する場合は異常と判断し、当該ランチャーにより前記業務プログラムの動作を抑える動作制御を行い、かつ、前記監視装置に異常を通知することを特徴とする。
【０００６】
さらに本発明の業務プログラム監視制御システムは、前記業務プログラムの起動の際は、
前記顧客コンピュータの処理により、当該業務プログラムの親プロセスであるランチャーを起動し、当該ランチャーを介して前記業務プログラムを起動することを特徴とする。さらに本発明の業務プログラム監視制御システムは、前記監視ルールは、業務プログラムごとに設定が可能であることを特徴とする。
【発明の効果】
【０００７】
本発明によれば、業務プログラム監視制御システムにおいて、業務プログラムの稼動状態を常に監視し、異常と判断した場合には、業務プログラムの動作を抑えることを可能とする。
【発明を実施するための最良の形態】
【０００８】
本発明を実施するための最良の形態を説明する。
【０００９】
図１は、本発明の一実施形態を示すシステム構成図である。顧客システム１には、顧客コンピュータ１０と監視装置２１があり、これらは、互いにネットワーク等により通信可能となっている。そして、顧客コンピュータ１０は、顧客コンピュータ用処理部１１と、顧客コンピュータ用記憶手段１２と、メモリ１３を有し、顧客コンピュータ用処理部１１の処理により各業務プログラムをランチャーを介して稼動可能となっている。また、監視装置２１には、監視装置用処理部２２と、ランチャーインタフェース２５と、外部インタフェース２４と、監視装置用記憶手段２３を有している。なお、監視装置２１に対して顧客コンピュータ１０が複数台存在しても本発明は実現可能である。
【００１０】
監視装置用処理部２２は、ログ記録／表示、ＤＢメンテナンス等の処理を可能とする。記憶手段２３には、監視ルール２３ａ、業務状態２３ｂ、ログ２３ｃ等のデータベースを有している。外部インタフェース２４からは、メール３３の送受信や端末装置３２での表示を可能とする。ランチャーインタフェース２５からは、少なくとも、顧客コンピュータ用処理部１１におけるランチャーに関する通信を可能としている。
【００１１】
顧客コンピュータ用処理部１１は、各業務プログラムを、業務プログラムごとにランチャーを介して稼動させることを可能としている。この場合、ランチャーは、業務プログラムの親プロセスとなり、異常検知と動作制御の機能を有する。これにより、業務プログラムごとに、業務プログラムの監視及び制御が可能となっている。図１では、一例として業務Ａと業務Ｂについて記載してある。業務プログラムは、業務に使用するプログラムであれば、その種類を特定するものではない。顧客コンピュータ用記憶手段１２は、監視ルールや業務状態のデータを有している。
【００１２】
図２は、本発明の業務プログラムの監視・制御実行時の一実施形態を示すフローチャートである。まず、顧客コンピュータ処理部１１は、業務プログラムにかかわるランチャーの起動する（Ｓ２０１）。そして、顧客コンピュータ用記憶手段に有する監視ルールをメモリ１３に格納し、ランチャーの子プロセスとして業務プログラムを起動する（Ｓ２０２）。次に、ランチャーは、業務プログラムの状態を監視する（Ｓ２０３）。次に、業務プログラムが終了したかを判断し（Ｓ２０４）、終了した場合は、図３のＳ３０１に進む。一方、終了していないと判断した場合は、動作制御の解除要求があるかを判断する（Ｓ２０５）。
【００１３】
Ｓ２０５において、動作制御の解除要求がある場合は、業務プログラムの動作制御の解除を実施および監視ルールの初期化を行う（Ｓ２０６）。そして、業務プログラムの動作制御解除を監視装置に通知する（Ｓ２０７）。この通知は、例えば、通知日時、動作解除である旨、リソース名、業務名、メッセージ（業務プログラムの動作制御を解除等）などである。当該通知を受けた監視装置２１（監視装置用処理部２２）は、運用管理者に業務プログラムが正常化したことを、例えばメール３３等で通知し、当該通知したことを、ランチャーに報告する（Ｓ２０８）。この報告は、例えば、報告日時、動作解除の通知であった旨、リソース名、業務名、結果（正常に通知したか等）などである。そして、ランチャーの処理において、Ｓ２０７の後はＳ２０３にもどる。
【００１４】
Ｓ２０５において、動作制御の解除要求がない場合は、異常兆候の検知すなわち、業務プログラムの状態と監視ルールの条件と比較を行う（Ｓ２０９）。これにより、監視ルールに該当しない場合はＳ２０３にもどる。監視ルールに該当する場合、すなわち、異常と判断された場合は、監視ルールに従い、業務プログラムの動作制御を実行する（Ｓ２１０）。異常と判断される場合は、正常から異常になる場合と、異常のままの場合があげられる。また、動作制御は後に述べる優先制御により行う。
【００１５】
そして、異常の検知が、正常から異常に変化した場合であるかを判断し（Ｓ２１１）、正常から異常に変化した場合でないときは、Ｓ２０３にもどる。そして、正常から異常に変化した場合であるときは、監視装置２１に異常を検知したことを通知する（Ｓ２１２）。この通知は、例えば、通知日時、異常通知である旨、リソース名、業務名、メッセージ（業務プログラムのループの兆候を検知等）などである。そして、当該通知を受けた監視装置２１（監視装置用処理部２２）は、運用管理者に業務の異常検知を、例えばメール３３等で通知し、当該通知したことを、ランチャーに報告する（Ｓ２１３）。この報告は、例えば、報告日時、異常通知であった旨、リソース名、業務名、結果（正常に通知したか等）などである。なお、異常のままである場合は、Ｓ２０３に戻り、監視を継続する。
【００１６】
図３は、本発明の業務プログラムの終了時の一実施形態を示すフローチャートである。
図２のＳ２０４において、業務プログラムの終了と判断された場合、図３に行き、異常検知中（動作制御実施中）に業務プログラムが終了したかを判断する（Ｓ３０１）。そして、異常検知中以外の状態で業務プログラムが終了した場合は、そのまま、ランチャーを終了する（Ｓ３０４）。また、異常検知中に業務プログラムが終了した場合は、監視装置２１に業務プログラムが終了したことを通知する（Ｓ３０２）。この通知は、例えば、通知日時、終了通知である旨、リソース名、業務名、などである。当該通知を受けた監視装置２１（監視装置用処理部２２）は運用管理者に業務プログラムの終了を、例えばメール３３等で通知し、当該通知したことを、ランチャーに報告する（Ｓ３０３）。この報告は、例えば、報告日時、終了通知であった旨、リソース名、業務名、結果（正常に通知したか等）などである。そして、ランチャーが終了する（Ｓ３０４）。
【００１７】
図４は、本発明の状態管理テーブル及び監視ルールテーブルの一例である。これらは、顧客コンピュータ用記憶手段１２にから、監視時には、メモリに格納され（Ｓ２０２）、異常兆候の検知（Ｓ２０９）で適用される。図４において、監視ルールテーブルのルールＮｏ．ごとに条件１と条件２が設定されており、ルールＮｏ．１５には、条件１は、ＣＰＵの値が８０を超える場合であり、条件２はＴＩＭＥが３秒を超える場合である。すなわち、ＣＰＵの使用率が８０％を超える状態が３秒をこえる場合に当該監視ルールに該当し、異常と判断される。なお、ランチャーは、ＣＰＵの使用率をリアルタイムで測定（少なくとも１秒に１回以上）可能となっている。
【００１８】
また、図４の監視ルールテーブルのルールＮｏ．１５の優先制御は「−１」である。これは、顧客コンピュータ１０の顧客コンピュータ用処理部１１の処理の優先順位を一つ下げる制御を行うことを示している。例えば、ＯＳ（オペレーティングシステム）においては、ＣＰＵの優先順位を決定する機能を有しており、この機能により、ランチャーを介して、当該業務プログラムの優先順位を下げることにより、業務プログラムの動作（ＣＰＵ使用率等）を抑える動作制御である優先制御を可能とする。
【００１９】
図４においては、例えば、業務Ｂの場合、状態管理テーブルより、ルールＮｏ．１５が適用され、監視ルールテーブルより、ルールＮｏ．１５に対応する条件が選択され、適用される。なお、リソース名におけるサーバ１は、例えば、図１においては、顧客コンピュータ１０が該当する。
【００２０】
また、図２のＳ２０２において、状態管理テーブルに当該起動しようとしている業務に係るルールＮｏ．の設定がない場合は、ランチャーを介して業務プログラムを起動し、その後、ランチャーは終了する。すなわち、ランチャーを介さないで業務プログラムのみで稼動し、その後の監視及び制御は行わない。これにより、監視の必要ない業務プログラムをランチャーを介さないで稼動するため、顧客コンピュータ用処理部１１の負荷を軽くすることができる。
【００２１】
図５は、本発明のログ表示画面の一例である。ログは、ログのデータベース２３ｃに存在しており、これを、監視装置用処理部２２の処理により端末装置３２で確認、編集できる。図５に示される、ログの内容としては、顧客コンピュータ１０からの報告や応答に関する内容であり、「異常報告」「異常応答」についてのリソース名や業務名、プロセスＩＤ、応答の各情報が表示されている。そして、指定した表示期間でログの内容が表示されるようになっている。
【００２２】
図６は、本発明の状態管理テーブルのメンテナンス画面の一例である。状態管理テーブルは、業務状態のデータベース２３ｂに存在しており、状態管理テーブルのメンテナンスは、監視装置用処理部２２の処理により端末装置３２で行うことができる。そして、リソース名、業務名、ルールＮｏ．等を設定することができる。リソース名におけるサーバ１は、例えば図１においては、顧客コンピュータ１０が該当する。また、図６において、状況（閾値）は、参考データとして業務稼動中に設定した閾値を超えた回数が示されるための設定である。
【００２３】
そして、メンテナンスされた状態管理テーブルは、監視装置用処理部２２の処理により、顧客コンピュータ１０に送信され、顧客コンピュータ用記憶手段１２に有する、状態管理テーブルのデータが更新される。
【００２４】
図７は、本発明の監視ルールのメンテナンス画面の一例である。監視ルールは、監視ルールのデータベース２３ａに存在しており、監視ルールのメンテナンスは、監視装置用処理部２２の処理により端末装置３２で行うことができる。そして、ルールＮｏ．ごとにＣＰＵの使用率、ＴＩＭＥ，監視間隔、優先制御の設定が可能となっている。
【００２５】
そして、メンテナンスされた状態管理テーブルは、監視装置用処理部２２の処理により、顧客コンピュータ１０に送信され、顧客コンピュータ用記憶手段１２に有する、監視ルールのデータが更新される。
【００２６】
以上のように本発明は、異常のある業務プログラムを優先制御により、動作を抑制することで他の業務への影響を最小限に抑えることができる。さらに、業務の起動時にあらかじめ登録してある監視ルールを決定することにより、業務プログラム個別の監視および制御が可能となる。さらに、異常が誤検知だった場合でも動作制御を解除することで、業務プログラムの動作を元の状態に戻すことができる。さらに、業務プログラムを強制終了させない方式により、お客様コンピュータ内に異常の状態が保たれるため、運用管理者は原因追求が可能となる。さらに、業務プログラムの状態監視、異常の検出、および動作を抑制する制御をランチャーに装備することで、リアルタイムで監視・制御できる。さらに、ネットワーク障害等により、ランチャーと監視装置間の通信が途絶えても、監視・制御が継続できる。さらに、日々の業務プログラムの稼働状態から、ランチャーを介して業務プログラムを起動するか直接起動するかを切替可能にすることにより、全ての業務プログラムをランチャーを介して起動する方式と比べ、お客様コンピュータのリソース消費量を減らすことが可能となる。
【図面の簡単な説明】
【００２７】
【図１】本発明の一実施形態を示すシステム構成図である。
【図２】本発明の業務プログラムの監視・制御実行時の一実施形態を示すフローチャートである。
【図３】本発明の業務プログラムの終了時の一実施形態を示すフローチャートである。
【図４】本発明の状態管理テーブル及び監視ルールテーブルの一例である。
【図５】本発明のログ表示画面の一例である。
【図６】本発明の状態管理テーブルのメンテナンス画面の一例である。
【図７】本発明の監視ルールのメンテナンス画面の一例である。
【符号の説明】
【００２８】
１      顧客システム
１０    顧客コンピュータ
１１    顧客コンピュータ用処理部
１２    顧客コンピュータ用記憶手段
１３    メモリ
２１    監視装置
２２    監視装置用処理部
２３    監視装置用記憶手段
２３ａ  監視ルール
２３ｂ  業務状態
２３ｃ  ログ
２４    外部インタフェース
２５    ランチャーインタフェース
３１    運用管理者
３２    端末装置
３３    メール
【図１】
2008269383.tif 000003
【図２】
2008269383.tif 000004
【図３】
2008269383.tif 000005
【図４】
2008269383.tif 000006
【図５】
2008269383.tif 000007
【図６】
2008269383.tif 000008
【図７】
2008269383.tif 000009