(57)【要約】【課題】ジョブ同士の処理の関連性を考慮してエラー発生の可能性を監視できる監視装置、監視プログラム及び記録媒体を提供することを課題とする。【解決手段】監視対象装置１１を監視する監視装置１００であって、監視対象装置１１のジョブの実行結果データを過去の実績として蓄積している蓄積手段１０２からジョブの実行結果データを取得する取得手段と、ジョブの実行結果データから監視対象装置１１の監視に利用する監視用データを作成する監視用データ作成手段と、監視対象装置１１からジョブ実行中取得データを取得し、ジョブ実行中取得データと監視用データとを比較した結果に基づいて、監視対象装置１１のジョブのエラー判定を行うエラー判定手段と、エラー判定の結果を通知するエラー通知手段とを有することにより上記課題を解決する。【選択図】図１２
2012027873.tif 000002
【特許請求の範囲】
【請求項１】
監視対象装置を監視する監視装置であって、
前記監視対象装置のジョブの実行結果データを過去の実績として蓄積している蓄積手段から前記ジョブの実行結果データを取得する取得手段と、
前記ジョブの実行結果データから前記監視対象装置の監視に利用する監視用データを作成する監視用データ作成手段と、
前記監視対象装置からジョブ実行中取得データを取得し、該ジョブ実行中取得データと前記監視用データとを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うエラー判定手段と、
前記エラー判定の結果を通知するエラー通知手段と
を有する監視装置。
【請求項２】
前記監視用データ作成手段は、前記ジョブの実行結果データに含まれる正常処理結果及びエラー処理結果から、正常処理時の処理件数と処理時間との相関関係及びエラー処理時の処理件数と処理時間との相関関係を表した相関図を監視用データとして作成すること
を特徴とする請求項１記載の監視装置。
【請求項３】
前記監視用データ作成手段は、前記ジョブの実行結果データに含まれる正常処理結果及びエラー処理結果から、正常処理時の処理件数と滞留ジョブ数との相関関係及びエラー処理時の処理件数と滞留ジョブ数との相関関係を表した相関図を監視用データとして作成すること
を特徴とする請求項１記載の監視装置。
【請求項４】
前記エラー判定手段は、前記ジョブ実行中取得データに含まれる処理件数と処理時間との相関関係と、前記相関図における前記正常処理時の処理件数と処理時間との相関関係及びエラー処理時の処理件数と処理時間との相関関係とを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うこと
を特徴とする請求項２記載の監視装置。
【請求項５】
前記エラー判定手段は、前記ジョブ実行中取得データに含まれる処理件数と滞留ジョブ数との相関関係と、前記相関図における前記正常処理時の処理件数と滞留ジョブ数との相関関係及びエラー処理時の処理件数と滞留ジョブ数との相関関係とを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うこと
を特徴とする請求項３記載の監視装置。
【請求項６】
前記エラー判定手段は、前記監視対象装置のジョブのエラー判定を、段階的に行い、
前記エラー通知手段は、前記エラー判定手段が行った段階的なエラー判定に基づいて段階的に前記エラー判定の結果を通知すること
を特徴とする請求項４又は５記載の監視装置。
【請求項７】
監視対象装置を監視するコンピュータを、
前記監視対象装置のジョブの実行結果データを過去の実績として蓄積している蓄積手段から前記ジョブの実行結果データを取得する取得手段、
前記ジョブの実行結果データから前記監視対象装置の監視に利用する監視用データを作成する監視用データ作成手段、
前記監視対象装置からジョブ実行中取得データを取得し、該ジョブ実行中取得データと前記監視用データとを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うエラー判定手段、
前記エラー判定の結果を通知するエラー通知手段
として機能させるための監視プログラム。
【請求項８】
監視対象装置を監視するコンピュータを、
前記監視対象装置のジョブの実行結果データを過去の実績として蓄積している蓄積手段から前記ジョブの実行結果データを取得する取得手段、
前記ジョブの実行結果データから前記監視対象装置の監視に利用する監視用データを作成する監視用データ作成手段、
前記監視対象装置からジョブ実行中取得データを取得し、該ジョブ実行中取得データと前記監視用データとを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うエラー判定手段、
前記エラー判定の結果を通知するエラー通知手段
として機能させるための監視プログラム
を記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視対象装置を監視する監視装置、監視プログラム、及び、該監視プログラムを記録した記録媒体に関する。
【背景技術】
【０００２】
近年では、商取引に関する情報を標準的な書式に統一して、企業間で電子的に交換する仕組みであるＷＥＢ−ＥＤＩ（WEB Electronic Data Interchange）がよく利用されるようになった。ＷＥＢ−ＥＤＩは、受発注や見積もり、決済、出入荷などに関わるデータを予め定められた形式にしたがって電子化し、例えばインターネット標準の技術を利用して送受信する。
【０００３】
ＷＥＢ−ＥＤＩを利用するシステムでは例えば図１に示すように、特定のジョブが滞留することで、それ以降の多くのジョブが滞留する障害が発生していた。図１はサーバ間でのデータ送受信を行うジョブ実行システムの一例の構成図である。なお、ジョブ実行及びスケジューリングの対象はサーバＢとなる。図１ではサーバ間におけるデータ送受信連携処理での具体的なエラーの発生例を示している。
【０００４】
図１（Ａ）はサーバＡ、サーバＢ及びサーバＣを表している。図１（Ａ）のジョブ実行システムではサーバＢにおいて、ジョブ（１）及び（２）のデータ送受信連携処理が行われる。ジョブ（１）はサーバＢがサーバＡからデータを受信する。ジョブ（２）はサーバＢがサーバＣにデータを送信する。図１（Ａ）ではジョブ（１）の処理が滞ると、ジョブ（２）が実行されない。
【０００５】
図１（Ｂ）は、サーバＡ１、サーバＡ２、サーバＢ、サーバＣを表している。図１（Ｂ）のジョブ実行システムではサーバＢにおいて、ジョブ（１）−（３）のデータ送受信連携処理が行われる。
【０００６】
ジョブ（１）はサーバＢがサーバＡ１からデータを受信する。ジョブ（２）はサーバＢがサーバＡ２からデータを受信する。ジョブ（３）はサーバＢがサーバＣにデータを送信する。図１（Ｂ）ではジョブ（２）の処理が滞ると、ジョブ（１）及び（２）の実行結果を必要とするジョブ（３）が実行されない。
【０００７】
図１に示したようなジョブの処理が滞るエラーの発生から正常処理への復旧には管理者がエラーの影響範囲を調べてリカバリを行う必要がある。例えば前回までのジョブの実行結果をもとにジョブの再実行箇所を判定し、バッチ処理の障害復旧を行うシステムは従来から知られていた（例えば特許文献１参照）。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来、サーバ間でのデータ送受信連携処理では、管理者がエラー発生に気付くまでのタイムラグによりエラーの影響範囲が拡大してしまい、復旧までに多くの時間を要するという問題があった。従来、サーバ間でのデータ送受信連携処理では各ジョブに関連性があるため、時間と共にエラーの影響を受けるジョブが多くなり、エラーの影響範囲及びリカバリ対象範囲の特定に時間が掛かる。
【０００９】
また、従来、サーバ間でのデータ送受信連携処理ではエラーを未然に検知することも難しかった。また、管理者はエラーを経験的に判断している場合もあり、エラー発生の可能性を定量的に判断できないという問題もあった。なお、特許文献１に記載の技術はサーバ間でのジョブ同士の処理の関連性を考慮するものではない。
【００１０】
本発明は、上記の点に鑑みなされたものであり、ジョブ同士の処理の関連性を考慮してエラー発生の可能性を監視できる監視装置、監視プログラム及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明は、監視対象装置を監視する監視装置であって、前記監視対象装置のジョブの実行結果データを過去の実績として蓄積している蓄積手段から前記ジョブの実行結果データを取得する取得手段と、前記ジョブの実行結果データから前記監視対象装置の監視に利用する監視用データを作成する監視用データ作成手段と、前記監視対象装置からジョブ実行中取得データを取得し、該ジョブ実行中取得データと前記監視用データとを比較した結果に基づいて、前記監視対象装置のジョブのエラー判定を行うエラー判定手段と、前記エラー判定の結果を通知するエラー通知手段とを有することを特徴とする。
【００１２】
なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。
【発明の効果】
【００１３】
本発明によれば、ジョブ同士の処理の関連性を考慮してエラー発生の可能性を監視できる監視装置、監視プログラム及び記録媒体を提供可能である。
【図面の簡単な説明】
【００１４】
【図１】サーバ間でのデータ送受信を行うジョブ実行システムの一例の構成図である。
【図２】複数のサーバ間でのデータ送受信を行うジョブ実行システムの一例の構成図である。
【図３】従来のジョブ実行システムにおける問題点を説明する為の一例のフローチャートである。
【図４】エラーの影響範囲が拡大する様子を表した一例のイメージ図である。
【図５】ジョブの実行状態を説明する一例のイメージ図である。
【図６】一般的なジョブの一例の説明図である。
【図７】本実施例で監視対象とするジョブの一例の説明図である。
【図８】本実施例における実行結果データ登録処理の一例のイメージ図である。
【図９】本実施例におけるエラー判定処理の一例のイメージ図である。
【図１０】エラー判定に用いる相関図の一例のグラフ図である。
【図１１】エラー判定に用いる相関図の他の例のグラフ図である。
【図１２】本実施例の監視システムの一例の構成図である。
【図１３】本実施例の監視システムの処理手順を表した一例のフローチャートである。
【図１４】本実施例の監視システムの一例のハードウェア構成図である。
【図１５】本実施例の監視システムの一例の機能ブロック図である。
【図１６】監視サーバが有する各機能ブロックの処理手順を表した一例のシーケンス図である。
【図１７】本実施例の監視システムで利用するテーブルの一例の構成図である。
【発明を実施するための形態】
【００１５】
次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。本実施例では、図２に示すような複数のサーバ間でのデータ送受信を行うジョブ実行システムを対象とする。図２のジョブ実行システムは連携元サーバ１０、監視対象である監視対象サーバ１１、連携先サーバ１２を有する。
【００１６】
監視対象サーバ１１はジョブ実行及びスケジューリングの対象となる。監視対象サーバ１１は連携元サーバ１０からデータを受信するジョブと、連携先サーバ１２にデータを送信するジョブとを実行する。監視対象サーバ１１はジョブスケジュール１３を有する。監視対象サーバ１１が有するジョブスケジュール１３は連携元サーバ１０から連携先サーバ１２に正しくデータを中継するように監視対象サーバ１１で動く送信処理のジョブ、受信処理のジョブの順を定めたものである。
【００１７】
図３は従来のジョブ実行システムにおける問題点を説明する為の一例のフローチャートである。ジョブ実行システムにおいてエラーが発生すると、ステップＳ１では管理者による状況確認が行われる。ステップＳ２に進み、管理者はエラーの影響範囲を調査する。ステップＳ３に進み、管理者は応急処置を行うと共に、管理区に連絡を行う。
【００１８】
ステップＳ４に進み、管理者はリカバリが必要か否かを判断する。リカバリが必要と判断すれば、管理者はステップＳ５に進み、リカバリ手順の作成を行う。管理者はステップＳ６に進み、作成したリカバリ手順に従ってリカバリ作業を行う。管理者はステップＳ７に進み、エラー対応後の状況確認を行う。なお、ステップＳ４において、リカバリが不要と判断すれば、管理者はステップＳ７に進み、エラー対応後の状況確認を行う。
【００１９】
ステップＳ８に進み、管理者はジョブ実行システムが復旧したか否かを判断する。管理者はジョブ実行システムが復旧していないと判断すると、ステップＳ１に戻り、ジョブ実行システムが復旧するまで処理を繰り返す。管理者はジョブ実行システムが復旧したと判断すると、図３のフローチャートの処理を終了する。
【００２０】
例えば図３のフローチャートではエラー発生からステップＳ３までの間に、エラーの影響範囲が拡大する。従来のジョブ実行システムではエラーの発生に管理者が気付き、復旧対応（ステップＳ３の処理）をするまでエラーの影響範囲が拡大してしまい、復旧までに多くの時間を要してしまう。
【００２１】
そこで、本実施例のジョブ実行システムでは、エラーが発生する以前に「正常な処理から外れた処理」を管理者へ通知することで、エラー発生を予防、又は、エラー発生時の早急な対応を実現する。言い換えれば、本実施例のジョブ実行システムは、ジョブの実行状態がエラー発生の可能性を含んでいるか否かを判定・通知することにより、エラー発生を出来る限り未然に防ぎ、復旧に掛かる時間を削減する。
【００２２】
図４はエラーの影響範囲が拡大する様子を表した一例のイメージ図である。図４は上から下の方向に時間が経過している。図４中、×印を付した矢印は失敗したジョブを表している。また、斜線を付した四角はジョブにエラーを起こしている監視対象サーバ１１又は連携先サーバ１２を表している。
【００２３】
図４の上段は監視対象サーバ１１が連携元サーバ１０からデータを受信するジョブを表している。図４の上段のジョブは失敗している。図４の上段から時間が経過した図４の中段は監視対象サーバ１１が連携先サーバ１２にデータを送信するジョブを表している。図４の中段のジョブは失敗している。また、図４の中段から時間が経過した図４の下段は連携先サーバ１２が他の連携先サーバ１２にデータを送信するジョブを表している。図４の下段のジョブは失敗している。
【００２４】
図４に示したように、ジョブ実行システムではデータ送受信の一部が失敗すると、そのデータ送受信に関与するデータ送受信が全てエラーとなる。また、エラーの影響範囲はエラーが発生してから時間が経つほどに大きくなる。
【００２５】
図５は、ジョブの実行状態を説明する一例のイメージ図である。待ち状態のジョブ２０はジョブスケジュール１３により設定されたジョブ実行時刻に実行が促される。実行が促された待ち状態のジョブ２０は入力データ（ＩＯ）１４が入力されたあと、ステップＳ１０に進み、キュー３０に入れられて実行可能状態のジョブ２１となる。キュー３０に入れられた実行可能状態のジョブ２１は、順にステップＳ１１に進み、実行状態のジョブ２２となり、実行される。
【００２６】
そして、実行が完了したジョブ２２はステップＳ１２に進み、待ち状態のジョブ２０となる。ステップＳ１２では実行結果１５がアウトプットされる。本実施例のジョブ実行システムでは実行状態のジョブ２２のほか、実行可能状態のジョブ２１もエラー判定の材料として管理を行う。
【００２７】
図６は、一般的なジョブの一例の説明図である。ジョブ３１は、システムや管理者等のユーザからの処理データ（ＩＯ）３３とトリガ（実行命令）３４とに基づいて処理を実行する。実行完了後のジョブ３１は、処理の実行結果３５を戻す。１つのジョブ実行システム内で多くのジョブ３１を実行する場合であっても、ジョブ３１には、それぞれ個別に処理データ（ＩＯ）３３と実行結果３５とが存在する。図６のジョブ３１は印刷ジョブ等である。
【００２８】
図７は本実施例で監視対象とするジョブの一例の説明図である。図７はジョブ４１〜４３の順で処理が実行される。図７では前のジョブの実行結果を後のジョブの処理データとして用いている。例えばジョブ４１の実行結果４６はジョブ４２の処理データ４６として用いられる。例えばジョブ４２の実行結果４８はジョブ４３の処理データ４８として用いられる。
【００２９】
また、トリガは時間イベントなので、ジョブ実行時刻に前のジョブ（例えばジョブ４２の場合は前のジョブ４１）が確実に終了している必要がある。ジョブにエラーが発生した場合、図７の例ではエラーが発生したジョブを停止、再実行する際にも、前後のジョブとの関連性を考慮することが必要である。
【００３０】
図８は本実施例における実行結果データ登録処理の一例のイメージ図である。図８に示すように、本実施例における実行結果データ登録処理では、実行可能状態のジョブ２１と実行状態のジョブ２２とからジョブ開始時取得データ６０及びジョブ完了時取得データ６１を取得する。
【００３１】
ジョブ開始時取得データ６０にはジョブ内処理件数７１が含まれる。ジョブ完了時取得データ６１には最大ジョブ滞留数７２、エラー発生時ジョブ滞留数７３、ジョブ実行完了時間７４、エラー発生時までの経過時間７５が含まれる。ジョブ内処理件数７１はジョブ開始時に実行状態のジョブ２２から取得される。最大ジョブ滞留数７２はジョブ完了時にキュー３０から取得される。
【００３２】
エラー発生時ジョブ滞留数７３はジョブ完了時にキュー３０から取得される。ジョブ実行完了時間７４はジョブ完了時に実行状態のジョブ２２から取得される。エラー発生時までの経過時間はジョブ完了時に実行状態のジョブ２２から取得される。取得されたジョブ開始時取得データ６０及びジョブ完了時取得データ６１は実行結果マスタＤＢ６２に登録される。なお、実行結果マスタ６２は後述の監視データ蓄積ＤＢ１０２に相当する。
【００３３】
図９は本実施例におけるエラー判定処理の一例のイメージ図である。本実施例におけるエラー判定処理では、実行可能状態のジョブ２１と実行状態のジョブ２２とからジョブ開始時取得データ６０及びジョブ実行中取得データ６３を取得する。
【００３４】
ジョブ開始時取得データ６０に含まれるジョブ内処理件数７１は図８と同様であるため説明を省略する。ジョブ実行中取得データ６３にはジョブ滞留数７６、ジョブ実行経過時間７７が含まれる。ジョブ滞留数７６はジョブ２２の実行中にキュー３０からリアルタイムに取得される。ジョブ実行経過時間７７は実行状態のジョブ２２からリアルタイムに取得される。
【００３５】
本実施例におけるエラー判定処理では、今回取得したジョブ内処理件数７１、ジョブ滞留数７６及びジョブ実行経過時間７７と、前回以前に実行結果マスタＤＢ６２に登録したジョブ内処理件数７１、最大ジョブ滞留数７２、エラー発生時ジョブ滞留数７３、ジョブ実行完了時間７４、エラー発生時までの経過時間７５とを比較（照会）してエラーか否かを判定する。
【００３６】
エラー判定には図１０に示すような相関図を用いることができる。図１０はエラー判定に用いる相関図の一例のグラフ図である。図１０は、処理件数と処理時間との相関を表している。実線８１は、正常処理の相関曲線を表す。実線８２は、エラー処理の相関曲線を表す。
【００３７】
点線８５の内側の点８３は、正常処理結果（実績値）を表す。点線８６の内側の×印８４は、エラー処理結果（実績値）を表す。点線８５は正常処理の平均誤差を表す。点線８６はエラー処理の平均誤差を表す。実線８７は処理限界時間（後ろの関連ジョブの投入時間）を表す。
【００３８】
正常処理の相関曲線（回帰直線）及びエラー処理の相関曲線（回帰直線）は最小２乗法により算出する。また、標準誤差をもとに、正常処理の平均誤差及びエラー処理の平均誤差は算出される。処理限界時間（後ろの関連ジョブの投入時間）はジョブ名を取得キーとしてジョブスケジュール１３から取得される関連ジョブの投入時刻から実行状態のジョブ２２のジョブ投入時刻を引いて算出する。
【００３９】
図１０の相関図は、前回以前の実行結果をプロットし、ジョブ毎のジョブ実行完了時間７４−ジョブ内処理件数７１の散布図を作成したものである。図１０では正常処理結果を表す点８３の一次関数の相関曲線（実線）８１を引き、平均誤差の曲線（点線）８５も同様に描写している。
【００４０】
また、図１０ではエラー処理結果を表す点８４の一次関数の相関曲線（実線）８２を引き、平均誤差の曲線（点線）８６も同様に描写している。後ろに関連する関連ジョブがある場合は例えば実行中のジョブのジョブ投入時刻から関連ジョブのジョブ投入時刻を引いた処理限界時間に実線８７を引く。
【００４１】
エラー判定は処理が時間と共に「ａ→ｂ→ｃ→ｄ」と流れるので、それぞれのポイントで判定を行い、必要に応じて通知を行う。本実施例におけるエラー判定処理では処理ａが正常処理平均誤差範囲内にあるため正常な処理と判定し、通知を行わない。また、本実施例におけるエラー判定処理では処理ｂが正常処理平均誤差範囲外且つエラー処理平均誤差範囲外にあるため注意を送信し、処理監視を注意深く行うことを促す。
【００４２】
また、本実施例におけるエラー判定処理では、処理ｃがエラー処理平均誤差範囲内にあるため警告を送信し、影響のあるジョブ（影響ジョブ）と共に通知、応急処置、監視復旧などを促す。さらに、本実施例におけるエラー判定処理では、処理ｄが処理限界時間８７を超過しているためエラー検知を送信する。
【００４３】
すなわち、本実施例におけるエラー判定処理では、正常処理の結果、エラー処理の結果それぞれの相関曲線８１、８２の平均誤差の曲線８５、８６に入るか否か、処理限界時間８７を超過するか否かによりエラー判定を行っている。
【００４４】
なお、図１０のように正常処理平均誤差範囲とエラー処理平均誤差範囲とが重なっている場合は、より緊急度の高いエリア（正常処理平均誤差範囲とエラー処理平均誤差範囲とが重なっている場合はエラー処理平均誤差範囲）に状態があるものとして、エラー判定及び通知が行われる。図１０の相関図は、ジョブの処理において、処理件数が多くなると処理時間が長くなるという確認された実績に基づき、処理件数と処理時間とに相関関係があると仮定してエラー判定を行うものである。
【００４５】
なお、エラー判定には図１１に示す相関図を用いることもできる。図１１はエラー判定に用いる相関図の他の例のグラフ図である。図１１は、処理件数と滞留ジョブ数との相関を表している。
【００４６】
実線９１は、正常処理時の最大ジョブ滞留数の平均値を表す。実線９２は、エラー発生時のジョブ滞留数の平均値を表す。点線９５の内側の点９３は正常処理時の最大ジョブ滞留数（実績値）を表す。点線９６の内側の×印９４はエラー発生時のジョブ滞留数（実績値）を表す。点線９５は正常処理時の平均誤差を表す。点線９６はエラー処理時の平均誤差を表す。実線９７は限界滞留ジョブ数（後ろの関連ジョブまでのジョブ数）を表す。
【００４７】
図１１の相関図はジョブ滞留数が著しく処理件数の影響を受けないと仮定し、平均値と平均誤差とによるエラー判定を行うものである。図１１の相関図は図１０の相関図と同様な判定でエラー判定及び通知が行われる。
【実施例１】
【００４８】
図１２は本実施例の監視システムの一例の構成図である。図１２に示す監視システムは上記したジョブ実行システムを含む。図１２の監視システムは、連携元サーバ１０、監視対象サーバ１１、連携先サーバ１２、監視サーバ１００、クライアントＰＣ１０１、監視データ蓄積ＤＢ１０２を有する。
【００４９】
連携元サーバ１０、監視対象サーバ１１、連携先サーバ１２は図２と同様であり、説明を省略する。監視サーバ１００は監視対象サーバ１１から上記したようなジョブ開始時取得データ６０、ジョブ完了時取得データ６１、ジョブ実行中取得データ６３を取得する。
【００５０】
監視サーバ１００は、取得したジョブ開始時取得データ６０、ジョブ完了時取得データ６１を、監視結果データとして監視データ蓄積ＤＢ１０２に登録する。監視データ蓄積ＤＢ１０２は上記した実行結果マスタＤＢ６２に相当する。監視サーバ１００は、監視対象サーバ１１からジョブ実行中取得データ６３を取得すると共に、監視データ蓄積ＤＢ１０２からジョブ開始時取得データ６０、ジョブ完了時取得データ６１を監視用データとして取得する。監視サーバ１００は取得したジョブ開始時取得データ６０、ジョブ完了時取得データ６１、ジョブ実行中取得データ６３に基づき、エラー判定処理を行う。
【００５１】
監視サーバ１００は上記したエラー判定処理に基づき、注意、警告、エラーなどをクライアントＰＣ１０１に送信する。クライアントＰＣ１０１は管理者が操作する端末の一例である。監視データ蓄積ＤＢ１０２は上記したジョブ開始時取得データ６０、ジョブ完了時取得データ６１を監視結果データ（実績）として蓄積する。
【００５２】
図１３は本実施例の監視システムの処理手順を表した一例のフローチャートである。ステップＳ２１に進み、監視対象サーバ１１はジョブ監視を開始する。監視対象サーバ１１はジョブ開始時取得データ６０としてジョブ名、ジョブ投入時刻、処理件数を監視サーバ１００に送信する。
【００５３】
ステップＳ２２に進み、監視対象サーバ１１はジョブ監視を継続し、ジョブ実行中取得データ６３としてジョブ滞留数７６、ジョブ実行経過時間７７を監視サーバ１００に送信する。
【００５４】
一方、監視サーバ１００はステップＳ３１に進み、監視対象サーバ１１からジョブ開始時取得データ６０としてジョブ名、ジョブ投入時刻、処理件数を受信する。ステップＳ３２に進み、監視サーバ１００は監視データ蓄積ＤＢ１０２から過去実績の監視用データを取得する。
【００５５】
ステップＳ３３に進み、監視サーバ１００は図１０、図１１に示したような相関図を作成する。ステップＳ３４に進み、監視サーバ１００は処理が終了すればステップＳ３５に進み、ジョブ完了時取得データ６１を監視結果データとして監視データ蓄積ＤＢ１０２に登録した後、ステップＳ３６に進む。また、監視サーバ１００は処理が終了していなければ、ステップＳ３６に進む。
【００５６】
ステップＳ３６において、監視サーバ１００は図１０、図１１に示したような相関図を用いて、処理が上記の正常処理平均誤差範囲内にあれば正常な処理と判定し、通知を行わない。また、監視サーバ１００は処理が上記の正常処理平均誤差範囲外且つエラー処理平均誤差範囲外にあればステップＳ３７に進み、管理者に注意を送信する。
【００５７】
また、監視サーバ１００は処理が上記のエラー処理平均誤差範囲内にあればステップＳ３７に進み、管理者に警告を送信する。また、監視サーバ１００は処理が上記の処理限界時間８７を超過していればステップＳ３７に進み、管理者にエラー検知を送信する。
【００５８】
図１４は本実施例の監視システムの一例のハードウェア構成図である。図１４は図１２に示した監視システムの一例のハードウェア構成図である。監視対象サーバ１１はＣＰＵ２０１、メモリ２０２、ＨＤＤ２０３、ＮＩＣ２０４を有する。監視対象サーバ１１のＨＤＤ２０３には例えばジョブ実行プログラムが登録されている。
【００５９】
監視サーバ１００はＣＰＵ２０１、メモリ２０２、ＨＤＤ２０３、ＮＩＣ２０４を有する。監視データ蓄積ＤＢ１０２を実現する監視データ蓄積ＤＢサーバ１０３は、ＣＰＵ２０１、メモリ２０２、ＨＤＤ２０３、ＮＩＣ２０４を有する。また、クライアントＰＣ１０１は、ＣＰＵ２０１、メモリ２０２、ＨＤＤ２０３、ＮＩＣ２０４、Ｉ／Ｏ２０５を有する。クライアントＰＣ１０１はＩ／Ｏ２０５を経由してディスプレイ１０４に接続されている。図１４の監視システムは、監視対象サーバ１１、監視サーバ１００、クライアントＰＣ１０１、監視データ蓄積ＤＢサーバ１０３がＨＵＢを経由して接続されている。
【００６０】
本実施例の監視プログラムは、監視サーバ１００を制御する各種プログラムの少なくとも一部である。ＨＤＤ２０３は、監視サーバ１００を制御する各種プログラムを記録した記録媒体の一例である。監視サーバ１００を制御する各種プログラムを記録した記録媒体はＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。
【００６１】
監視サーバ１００を制御する各種プログラムは、例えば監視サーバ１００の起動時にＨＤＤ２０３から読み出され、メモリ２０２に格納される。ＣＰＵ２０１はメモリ２０２に格納された監視サーバ１００を制御する各種プログラムに従って、後述するような各種処理を実現している。
【００６２】
図１５は本実施例の監視システムの一例の機能ブロック図である。図１５に示すように監視対象サーバ１１は、ジョブ実行処理部３００を有する。監視サーバ１００はジョブ投入時データ取得部３０１、ジョブ実行状態取得部３０２、監視用データ作成部３０３、実行状態エラー判定部３０４、エラー通知作成・送信部３０５、判定用過去実績取得部３０６、監視結果登録部３０７を有する。監視データ蓄積ＤＢサーバ１０３は監視結果データ参照部３０８、監視結果データ更新部３０９を有する。
【００６３】
監視対象サーバ１１のジョブ実行処理部３００はジョブを実行する。監視データ蓄積ＤＢサーバ１０３の監視結果データ参照部３０８は、過去実績としての監視用データを参照する。また、監視データ蓄積ＤＢサーバ１０３の監視結果データ更新部３０９は実績である監視結果データ（実行結果データ）で監視用データを更新する。
【００６４】
なお、監視サーバ１００が有する各機能ブロックの処理は図１６のシーケンス図を参照しつつ説明する。図１６は監視サーバが有する各機能ブロックの処理手順を表した一例のシーケンス図である。
【００６５】
ジョブ投入時データ取得部３０１は監視対象サーバ１１からジョブ開始時取得データ６０としてジョブ名、ジョブ投入時刻、処理件数を受信すると、ステップＳ４１に進み、監視用データ作成部３０３にジョブ名、ジョブ投入時刻、処理件数を送信して監視データ作成処理開始を指示する。
【００６６】
監視用データ作成部３０３はステップＳ４２に進み、判定用過去実績取得部３０６に過去実績（監視用データ）取得を指示する。判定用過去実績取得部３０６は監視データ蓄積ＤＢサーバ１０３の監視結果データ参照部３０８を呼び出し、監視データ蓄積ＤＢ１０２から過去実績を取得する。なお、過去実績はジョブ名をキーとして取得される。
【００６７】
ステップＳ４３に進み、判定用過去実績取得部３０６はステップＳ４２の戻り値として過去実績を監視用データ作成部３０３に送信する。過去実績を受信すると、監視用データ作成部３０３は図１０、図１１に示したような相関図を作成する。監視用データ作成部３０３は、ステップＳ４４に進み、作成した相関図をエラー通知作成・送信部３０５に送信する。
【００６８】
ジョブ実行状態データ取得部３０２は監視対象サーバ１１からジョブ実行中取得データ６３としてジョブ実行経過時間、ジョブ滞留数を受信すると、ステップＳ４５に進み、実行状態エラー判定部３０４に実行状態正誤判定を指示する。実行状態エラー判定部３０４は上記したエラー判定処理を行う。エラー判定処理には、図１０又は図１１に示した相関図が用いられる。実行状態エラー判定部３０４は注意、警告又はエラー検知の送信が必要と判定すると、ステップＳ４６に進み、注意、警告又はエラー検知の送信をエラー通知作成・送信部３０５に依頼する。ステップＳ４７に進み、エラー通知作成・送信部３０５は管理者のクライアントＰＣ１０１に注意を送信する。
【００６９】
ジョブ実行状態データ取得部３０２は処理が終了すればステップＳ４８に進み、実行状態エラー判定部３０４に実行終了を通知する。ステップＳ４９に進み、実績状態エラー判定部３０４は、監視結果登録部３０７に実績登録を指示する。監視結果登録部３０７は監視データ蓄積ＤＢサーバ１０３の監視結果データ更新部３０９を呼び出して、監視データ蓄積ＤＢ１０２に実績として監視結果データを取得する。ステップＳ５０に進み、実行状態判定部３０４はジョブ実行状態データ取得部３０２に監視終了通知を行って、処理を終了する。
【００７０】
図１７は本実施例の監視システムで利用するテーブルの一例の構成図である。本実施例の監視システムでは、図１７（Ａ）に示す正常処理結果のテーブル、図１７（Ｂ）に示すエラー処理結果のテーブル、図１７（Ｃ）に示すジョブスケジュールのテーブルを利用している。
【００７１】
本実施例の監視システムでは、正常処理結果のテーブル、エラー処理結果のテーブルから前回までの過去実績を取得し、監視終了時、正常処理結果のテーブル、エラー処理結果のテーブルに実績を登録する。
【００７２】
本実施例の監視システムは、ジョブの実行結果データを履歴として監視データ蓄積ＤＢ１０２に登録しておき、履歴から相関関係の平均誤差を取得することで、エラー発生の可能性を定量的に判断できる。また、エラー発生の可能性をアラートすることで、監視担当者などの管理者は、エラーの発生を未然に察知することができ、あらかじめエラーの影響範囲、リカバリ対象範囲、リカバリ方法などを準備しておくことができるため、復旧までの時間を短縮できる。
【００７３】
また、本実施例の監視システムは、運用年月が経過するごとにエラーの判定精度が上がるというメリットがある。これは本実施例の監視システムがジョブの実行結果を判断基準として用いるためである。本実施例の監視システムは多くの実績を蓄積することで高い信頼性のエラー判定を実現できる。
【００７４】
本実施例の監視システムでは、注意、警告又はエラー検知が段階的に管理者へ通知されるので、管理者がエラーの発生に未然に気付くことができ、予防策や対応の事前準備がし易いという長所がある。また、本実施例の監視システムでは、エラーの頻発箇所を特定してジョブスケジュール１３を改修する際の材料とすることもできる。例えば処理Ａの件数が多く、処理Ｂの処理に影響を及ぼすケースが多い場合は、処理Ｂをさらに後の時間に実行させることで、エラーの発生を回避させることができる。
【００７５】
本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。なお、特許請求の範囲に記載した取得手段は判定用過去実績取得部３０６に相当し、監視用データ作成手段は監視用データ作成部３０３に相当し、エラー判定手段は実行状態エラー判定部３０４に相当し、エラー通知手段はエラー通知作成・送信部３０５に相当する。
【符号の説明】
【００７６】
１０    連携元サーバ
１１    監視対象サーバ
１２    連携先サーバ
１３    ジョブスケジュール
１４    入力データ（ＩＯ）
１５、３５    実行結果
２０    待ち状態のジョブ
２１    実行可能状態のジョブ
２２    実行状態のジョブ
３０    キュー
３１、４１〜４３    ジョブ
３３、４４、４６、４８    処理データ（ＩＯ）
３４、４５、４７、４９    トリガ（実行命令）
４６、４８、５０    実行結果
６０    ジョブ開始時取得データ
６１    ジョブ完了時取得データ
６２    実行結果マスタＤＢ
６３    ジョブ実行中取得データ
７１    ジョブ内処理件数
７２    最大ジョブ滞留数
７３    エラー発生時ジョブ滞留数
７４    ジョブ実行完了時間
７５    エラー発生時までの経過時間
７６    ジョブ滞留数
７７    ジョブ実行経過時間
８１、８２、８７、９１、９２、９７    実線
８３、９３    点
８４、９４    ×印
８５、８６、９５、９６    点線
１００    監視サーバ
１０１    クライアントＰＣ
１０２    監視データ蓄積ＤＢ
１０３    監視データ蓄積ＤＢサーバ
１０４    ディスプレイ
２０１    ＣＰＵ
２０２    メモリ
２０３    ＨＤＤ
２０４    ＮＩＣ
２０５    Ｉ／Ｏ
３００    ジョブ実行処理部
３０１    ジョブ投入時データ取得部
３０２    ジョブ実行状態取得部
３０３    監視用データ作成部
３０４    実行状態エラー判定部
３０５    エラー通知作成・送信部
３０６    判定用過去実績取得部
３０７    監視結果登録部
３０８    監視結果データ参照部
３０９    監視結果データ更新部
Ａ、Ｂ、Ｃ、Ａ１、Ａ２    サーバ
【先行技術文献】
【特許文献】
【００７７】
【特許文献１】特開２００８−２１７３６７号公報
【図１】
2012027873.tif 000003
【図２】
2012027873.tif 000004
【図３】
2012027873.tif 000005
【図４】
2012027873.tif 000006
【図５】
2012027873.tif 000007
【図６】
2012027873.tif 000008
【図７】
2012027873.tif 000009
【図８】
2012027873.tif 000010
【図９】
2012027873.tif 000011
【図１０】
2012027873.tif 000012
【図１１】
2012027873.tif 000013
【図１２】
2012027873.tif 000014
【図１３】
2012027873.tif 000015
【図１４】
2012027873.tif 000016
【図１５】
2012027873.tif 000017
【図１６】
2012027873.tif 000018
【図１７】
2012027873.tif 000019