JP2018113028A - Ｉｔインフラストラクチャにおいて実行されるアプリケーションのバッチ処理を監視するための方法およびシステム - Google Patents

Abstract

【課題】ＩＴインフラストラクチャにおいて実行されるアプリケーションのバッチ処理を監視する。【解決手段】バッチによる、リソースの通常の消費量を記録し５０、バッチの実行を経時的に追跡調査し５１、前記リソースの瞬間的消費量を測定し５２、インシデントに近い期間中に実行されたバッチのそれぞれの、瞬間的消費量と通常の消費量とを比較５３することにより、インフラストラクチャのコンピューティングリソースの少なくとも１つの輻輳インシデントを検出し６０、前記インシデントの原因にある少なくとも１つのバッチを識別する７０。【選択図】図１

Description

本発明は、ＩＴインフラストラクチャを監視する分野に関し、より具体的には、これらのＩＴインフラストラクチャ内で実行されるアプリケーションにおけるバッチ処理の分野に関する。これらのバッチ処理は、ほとんどのアプリケーションにあり、ユーザの介入なしのコンピュータ上のコマンド（プロセス）セットの自動連結である。１つが終了すると（結果に関係なく）、コンピュータは、次のバッチを処理する。スタックのすべてのバッチが実行されてしまうと、バッチ処理が終わる。

これらの処理をトリガすることが、例えばスケジューラによって、自動化され得る。競合するアクセス問題を回避するために、または適用負荷（ａｐｐｌｉｃａｔｉｖｅ ｌｏａｄ）を軽減するために、バッチ処理がスケジュールされる必要がある。このように、スケジューラの目的は、概して、処理の優先順位を確保することにもある。実際には、いくつかの処理は、他の処理が仕上げられたときのみ行われる必要がある。バッチ処理は、とりわけ、自動化されたタスクに対して、例えば、公共団体または民間団体のコンピュータ機器にわたってアカウントを管理するために使用される。バッチにおいて立ち上げられる作業は、通常、インタラクティブなまたはトランザクショナルな作業に使用されない処理周期のみを使用する。これらの作業は、通常、アプリケーションの標準使用範囲外（夜間や週末）で実行されるが、それのみではない。

アプリケーションのバッチ処理の分野における課題は、生産中、すなわち、ユーザの彼らの作業時間中、アプリケーションの正しい動作を確実にするために必要である長い重要な処理がしばしばあることである。具体的には、バッチ処理の実行は、生産中のアプリケーションの動作を危うくする、ＩＴインフラストラクチャリソースにおける輻輳を引き起こす場合がある。このような輻輳インシデントは、１つまたは複数のサーバ上の１つまたは複数のリソースの飽和、およびリソースの輻輳による１つまたは複数のリソースの持続時間の大幅な増加を特徴とすることが多い。実行時間の延長により、場合によっては、割り当てられた時間内にすべての処理が実行され得ないことが起こる。またある場合には、計画期間内に処理が完了されることができなかった場合、生産も打ち切られる必要がある。このように、生産中にインシデントが起こると、原因を決定するために分析が行われる必要がある。ある特有の課題は、使用可能な唯一の情報が、通常、スケジューリング機構に関連しているものであることから、特に、インシデントがバッチ処理に関連している場合、この分析が難しいという事実に関する。

この背景において、バッチ処理を監視し、生産中に起こる輻輳インシデントの原因にある可能性がある処理を識別する診断を可能にするためのツールを提案する解決策を提案することは興味深い。

本発明の目的は、ＩＴインフラストラクチャにおける輻輳インシデントの診断のための方法を提案することによって、先行技術のいくつかの欠点を解消することにある。

この目的は、スケジューラによって決定された計画カレンダに従って、ＩＴインフラストクチャにおいて実行されるアプリケーションのバッチ処理を監視するための方法によって達成され、方法は、前記インフラストラクチャのコンピューティングリソースの輻輳の、インシデントとして知られている少なくとも１つの事象の検出用に、および前記インシデントの原因に関与している可能性がある少なくとも１つのバッチの識別用に、構成された監視ソフトウェアによって、以下のステップ：
− 前記計画カレンダを表すデータからの、バッチによる前記インフラストラクチャのコンピューティングリソースの通常の消費量を表すデータの、監視ソフトウェアによってアクセス可能なメモリへの経時的な記録ステップと、
− 前記計画カレンダを表すデータによる、経時的なすべてのバッチの実行の追跡調査ステップと、
− 前記インフラストラクチャのコンピューティングリソースの瞬間的消費量の、監視ツールによる、経時的な測定ステップと、
− 前記識別を可能にするための、瞬間的消費量を表すデータと通常の消費量を表すテータとの間の、検出されたインシデントに近い期間中に実行されたバッチのそれぞれに対する、比較ステップと、
を実施することにより、実施されることを特徴とする。

別の特有の特徴によれば、前記インフラストラクチャのコンピューティングリソースの少なくとも１つのインシデントの検出ステップは、前記インシデントのタイムスタンプ処理をトリガする。

別の特有の特徴によれば、前記インシデントのタイムスタンプ処理ステップのつぎに、監視ソフトウェアによる、この事象に近い期間の決定が続き、この期間は、この事象に先行する、および／または後続する時間間隔まで拡張されることが可能である。

別の特有の特徴によれば、コンピューティングリソースの通常の消費量を表すデータの記録ステップは、バッチの実行の持続時間全体にわたるリソースの消費量プロファイルの、バッチのそれぞれに対する、記録ステップを含む。

別の特有の特徴によれば、監視ソフトウェアのユーザが、バッチの今後の実行の間の他のインシデントを回避するために取られるべき方策を決定し、任意選択で、結果としてカレンダを修正するための、分析および／または決定への補助を提供するための診断レポートの、監視ソフトウェアによる生成を、インシデントの分析中に得られた識別ステップがトリガする。

別の特有の特徴によれば、監視ソフトウェアによる少なくとも１つのインシデントの検出ステップは、特に瞬間的消費量の測定ステップ中に得られたデータによる、インシデントに近い前記期間中に実行されたバッチのそれぞれに関するフットプリントの、監視ソフトウェアによってアクセス可能なメモリへの記録をトリガする。

別の特有の特徴によれば、監視ソフトウェアによる少なくとも１つのインシデントの検出ステップは、特に瞬間的消費量の測定ステップ中に得られたデータによる、インシデント履歴の、監視ソフトウェアによってアクセス可能なメモリへの記録をトリガする。

別の特有の特徴によれば、監視ソフトウェアによる、瞬間的消費量を表すデータと通常の消費量を表すデータとの間の比較ステップは、前記インシデントの原因に関与している可能性がある少なくとも１つのバッチの前記識別を可能にする。

別の特有の特徴によれば、前記インシデントの原因に関与している可能性がある少なくとも１つのバッチの前記識別は、検出されたインシデントに関係する分析中のデータと、以前のインシデントに関係するデータとの間の少なくとも１つの相関づけに基づいている。

別の特有の特徴によれば、前記相関づけは、以下のステップ：
− バッチのフットプリントを表すデータとインシデント履歴を表すデータとの間の比較分析ステップと、
− バッチのフットプリントを表すデータと通常の消費量を表すデータとの比較分析ステップと、のうちの少なくとも１つを含む。

別の特有の特徴によれば、瞬間的消費量の測定ステップは、様々なパラメータを測定する複数のプローブの事前配備によって行われ、監視ツールが、このようにして測定された値を表すデータを監視ソフトウェアに伝送する。

別の特有の特徴によれば、瞬間的消費量の測定ステップ中に生成されたデータは、通常の消費量の記録ステップ中に格納されたデータを計算するために、監視ソフトウェアによって使用される。

別の特有の特徴によれば、前記計画カレンダを表すデータによる、バッチの実行の経時的な追跡調査ステップが、監視ソフトウェアのユーザによる前の計画ステップに続いて得られ、監視ソフトウェアがカレンダを表すデータを記録することを可能にする。

本発明の別の目的は、ＩＴインフラストラクチャにおける輻輳インシデントの診断を可能にするシステムを提案することによって、先行技術のいくつかの欠点を解消することにある。

この目的は、スケジューラによって決定された計画カレンダに従って、ＩＴインフラストラクチャにおいて実行されるアプリケーションのバッチ処理を監視するためのシステムによって達成され、システムは、本発明による方法を実施することによる、前記インフラストラクチャのコンピューティングリソースの輻輳の、インシデントとして知られている少なくとも１つの事象の検出用に、および前記インシデントの原因に関与している可能性がある少なくとも１つのバッチの識別用に、構成された監視ソフトウェアがその上で実行されるコンピュータ手段を備える、ことを特徴とする。

本発明の別の目的は、ＩＴインフラストラクチャにおける輻輳インシデントの診断を可能にするプログラムを提案することによって、先行技術のいくつかの欠点を解消することにある。

この目的は、本発明による方法を実施するための、コンピュータ手段によって読み取り可能な媒体に格納され、これらのコンピュータ手段によって実行可能な命令を含む、コンピュータプログラム製品によって達成される。

本発明の他の特有の特徴および利点は、以下の添付図面に関連して示される、続く記述を読んだ時点で、よりはっきりと分かるようになるであろう。

本発明の実施形態による、方法のステップを示す図である。 本発明の実施形態による、システムを示す図である。

本発明は、ＩＴインフラストラクチャにおいて実行されるアプリケーションのバッチ処理を監視するための方法およびシステム、ならびに方法を実施するためのコンピュータプログラム製品に関する。

「スケジューラ」、「計画カレンダ（ＣＡ）」という用語は、本記述では、当業者に対して、それぞれ、「スケジューリングプログラム」、「実行時間スケジューリング」、またはいずれかの同意義を表すこれらの用語の意味において使用され、これらの用語は、これらの用語が指す機能性を限定するとして解釈されてはならない。

概して、本出願は、機能特性に言及し、「ａ」または「ａｎ」という用語を使用するが、これは、実際には、ほぼ「少なくとも１つの」であり、本文に明確に述べられていない限り、個数を明示する必要がない、ということが当業者には明らかである。また、当業者であれば、本出願に提供されている機能の考察を読むことから、可能な変形形態を理解できることがはっきりしているので、本出願は、関わっている精緻な構造特性または端末タイプに関する詳細を提供することなく、コンピュータ手段およびＩＴインフラストラクチャに言及する。このように、本出願が言及する本記述および図面は、限定的として解釈されてはならない。

本出願は、スケジューラによって決定された計画カレンダ（ＣＡ）に従って、ＩＴインフラストラクチャ（ＦＷ）において実行されるアプリケーションのバッチ（ＢＡ）処理を監視するための方法にさらに関する。この方法は、一方において、前記インフラストラクチャ（ＦＷ）のコンピュータリソースの輻輳の、インシデント（ＥＣ）として知られている少なくとも１つの事象の検出（６０）用に、他方において、前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の識別（７０）用に、構成された監視ソフトウェア（ＬＳ）によって通常実施される。この検出（６０）とこの識別（７０）とは、以下のステップ：
− 前記計画カレンダ（ＣＡ）を表すデータからの、バッチ（ＢＡ）による前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの通常の消費量（ＣＭ）を表すデータの、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの経時的な記録ステップ（５０）と、
− 前記計画カレンダ（ＣＡ）を表すデータによる、すべてのバッチ（ＢＡ）の実行の経時的な追跡調査ステップ（５１）と、
− 前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの瞬間的消費量（ＣＩ）の、監視ツール（ＳＵ）による、経時的な測定ステップ（５２）と、
− 前記識別（７０）を可能にするための、瞬間的消費量（ＣＩ）を表すデータと、通常の消費量（ＣＭ）を表すデータとの間の、検出されたインシデント（ＥＣ）に近い期間（ＰＥ）中に実行されたバッチ（ＢＡ）のそれぞれに対する、比較ステップ（５３）と、
を実施することにより得られるのが好ましい。

いくつかの実施形態において、コンピューティングリソースの通常の消費量（ＣＭ）を表すデータの記録ステップ（５０）は、バッチの実行の持続時間全体にわたるリソースの消費量プロファイル（ＰＣ）の、バッチ（ＢＡ）のそれぞれに対する記録ステップ（５００）を含む。実際には、リソースの消費量が、実行期間にわたって一定ではないことから、バッチの実行持続時間全体にわたる、リソースの消費量を考量する必要がある。いくつかの実施形態において、通常の消費量（ＣＭ）を表すデータは、例えば、処理電力の消費量、使用されたメモリおよび／または空きメモリ、ネットワークの入力／出力および／または記憶メモリの数量、機械上で実行するプロセスなどの情報を表すデータを含む。

いくつかの実施形態において、前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）は、前記インシデント（ＥＣ）のタイムスタンプ処理（６１）をトリガする。いくつかの実施形態において、前記インシデント（ＥＣ）のこのタイムスタンプ処理（６１）のつぎに、監視ソフトウェア（ＬＳ）による、この事象に近い期間（ＰＥ）の決定（６１０）が続き、この期間は、この事象に先行する、および／または後続する時間間隔まで拡張されることができる。

いくつかの実施形態において、監視ソフトウェア（ＬＳ）による少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）は、特に瞬間的消費量（ＣＩ）の測定ステップ（５２）中に得られたデータによる、インシデント（ＥＣ）に近い前記期間（ＰＥ）中に実行されたバッチ（ＢＡ）のそれぞれに関するフットプリント（ＥＢ）の、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの記録（６２）をトリガする。バッチ（ＢＡ）のフットプリント（ＥＢ）のこの記録（６２）中、監視ソフトウェア（ＬＳ）が、監視ツール（ＳＵ）によって、瞬間的消費量（ＣＩ）を測定する（５２）ことから来る情報を使用して、カレンダ（ＣＡ）に基づく、したがって、リソースの使用の正確さが劣る推定に基づくよりもむしろ、実際のフットプリントを生成することが好ましい。いくつかの実施形態において、このようなフットプリント（ＥＢ）を表すデータは、例えば、全リソース消費量、タイムスタンプ処理、入力／出力データだけではなく、場合によっては、例えば通常の消費量（ＣＭ）の記録ステップ（５０）を介して得られる、リソース消費量プロファイル（ＰＣ）など、の情報を表すデータを含む。また、入力／出力データは、例えば、使用されたまたは生成されたファイル、データベース、ネットワーク（イントラネット、エクストラネット、インターネット・・・）から発生するデータなど、様々な形態を有することができる。

いくつかの実施形態において、監視ソフトウェア（ＬＳ）による少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）は、特に瞬間的消費量（ＣＩ）の測定ステップ（５２）中に得られたデータによる、インシデント履歴（ＨＩ）の、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの、記録（６３）をトリガする。いくつかの実施形態において、このインシデント履歴（ＨＩ）を表すデータは、例えば、タイムスタンプ処理、インシデントの期間にわたって実行するバッチのコンテキスト、全リソース消費量、場合によっては、以前のインシデントの分析中に得られた識別（７０）から来る診断（ＲＤ）などの情報を表すデータを含む。

いくつかの実施形態において、監視ソフトウェア（ＬＳ）による、瞬間的消費量（ＣＩ）を表すデータと、通常の消費量（ＣＭ）を表すデータとの間の比較ステップ（５３）は、前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の前記識別（７０）を可能にする。この比較ステップ（５３）は、例えば閾値または標準平均値に対する比較のための、各バッチによるリソースの使用レベルを識別する変数の少なくとも１つの計算に、特に対応することができる。前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の前記識別（７０）が、検出されたインシデント（ＥＣ）に関係する分析中のデータと、以前のインシデントに関係するデータとの間の少なくとも１つの相関づけ（７００）に基づいていることが好ましい。いくつかの実施形態において、前記相関づけ（７００）は、以下のステップ：
− バッチのフットプリント（ＥＢ）を表すデータと、インシデント履歴（ＨＩ）を表すデータとの間の比較分析ステップ（７０１）と、
− バッチのフットプリント（ＥＢ）を表すデータと、通常の消費量（ＣＭ）を表すデータとの比較分析ステップ（７０２）と、
のうちの少なくとも１つを含む。

いくつかの実施形態において、監視ソフトウェア（ＬＳ）のユーザが、バッチ（ＢＡ）のその後の実行の間の他のインシデント（ＣＥ）を回避するために取られるべき方策を決定し、任意選択で、結果としてカレンダ（ＣＡ）を修正するための、分析および／または決定への補助を提供するための診断レポート（ＲＤ）の、監視ソフトウェア（ＬＳ）による生成（７１）を、インシデント（ＥＣ）の分析中に得られた識別ステップ（７０）がトリガする。実際には、診断レポートは、例えば通常の消費量に対する使用レベルを示す、リソース使用の、例えば合成表の形式であることができる。このタイプのレポートまたは表は、例えば検出されたインシデントの特性を列挙することによって、インシデントの特性であるインシデントのリソースを見せる可能性がある。このように、インシデントに関わっている可能性のある各バッチは、輻輳中に行方不明になったリソースに関係する情報にアクセスするユーザによって識別され得、これによりバッチの計画カレンダを修正するか、またはＩＴインフラストラクチャの編成を見直すことすら行う。

いくつかの実施形態において、瞬間的消費量（ＣＩ）の測定ステップ（５２）は、様々なパラメータを測定する複数のプローブの事前配備（５２０）によって行われ、監視ツール（ＳＵ）が、このようにして測定された値を表すデータを監視ソフトウェア（ＬＳ）に伝送する。ＩＴインフラストラクチャ（ＦＷ）を監視するためには、例えば、処理電力消費量、使用されたメモリおよび／または空きメモリ、ネットワークの入力／出力の、および／または記憶メモリの数量、機械上で実行するプロセスなど、様々なタイプの（通常、物理的な）パラメータのうちの少なくとも１つのパラメータをそれぞれが監視する、いくつかの特殊なツールによって管理されることが多い、いくつかのプローブを配備することが通常好ましい。監視ソフトウェア（ＬＳ）は、この監視ツール（ＳＵ）と直接通信するか、またはこの監視ツール（ＳＵ）によって測定されたデータに後でアクセスするかのいずれかを行うように構成される可能性がある。

いつかの実施形態において、瞬間的消費量（ＣＩ）の測定ステップ（５２）中に生成されたデータは、通常の消費量（ＣＭ）の記録ステップ（５０）中に格納されたデータを計算するために、監視ソフトウェア（ＬＳ）によって使用される。

いくつかの実施形態において、前記計画カレンダ（ＣＡ）を表すデータによる、バッチ（ＢＡ）の実行の経時的な追跡調査ステップ（５１）が、監視ソフトウェア（ＬＳ）のユーザによる前の計画ステップ（５９）に続いて、得られ、監視ソフトウェアがカレンダ（ＣＡ）を表すデータを記録することを可能にする。

本出願は、したがって、バッチ処理を監視するためのシステムにも関する。このシステムは、本発明の様々な実施形態による、方法を実施するように構成された、監視ソフトウェア（ＬＳ）がその上で実行されるコンピュータ手段を備える。図２に示されているように、このようなコンピュータ手段は、これらのコンピュータ手段間の、特にＩＴインフラストラクチャ（ＦＷ）内にある、監視ソフトウェアと監視ツール（ＳＵ）との間の通信によって監視されたＩＴインフラストラクチャ（ＦＷ）にあるコンピュータ手段とは別個とすることができるが、もちろん、このＩＴインフラストラクチャ（ＦＷ）内でこれらのコンピュータ手段を実行することが可能である。前記インフラストラクチャ（ＦＷ）のこれらのコンピュータ手段およびコンピューティングリソースは、例えば互いに通信するサーバにおいて実装された、少なくとも１つのプロセッサ、および少なくとも１つのメモリまたはデータベースを当然のことながら備える。その一方で、本出願は、本発明による、方法を実施するための、コンピュータ手段によって読み取り可能な媒体に格納され、これらのコンピュータ手段によって実行可能な命令を含む、コンピュータプログラム製品にも関する。このように、方法によって提案された機能性は、様々なＩＴインフラストラクチャ（ＦＷ）を監視するための様々なコンピュータ手段上で配備され得る。

本出願は、図面および／または様々な実施形態に関連して、様々な技術特性および利点を説明している。当業者であれば、明示的に別段の定めがない限り、あるいはこれらの特徴が互換性のないものであること、または組み合わせが本出願において述べられている技術的課題のうちの少なくとも１つに対する解決策を提供しないことが明らかである限り、所与の実施形態の技術特性が、別の実施形態の特徴と実際に組み合わされ得る、ということを理解するだろう。また、所与の実施形態において説明された技術的特性は、明示的に別段の定めのない限り、このモードの他の特性から分離され得る。

本発明が、請求項に記載されたような本発明の適用分野から逸脱することなく、多くの他の特定の形態における実施形態を可能にすることが、当業者には分かるはずである。結果として、本実施形態は、例示として考えられなければならないが、添付の請求項の範囲によって定められた分野において変更され得、本発明は、本明細書の上に示された詳細に限定されてはならない。

ＣＡ 計画カレンダ
ＢＡ バッチ
ＦＷ インフラストラクチャ
ＬＳ 監視ソフトウェア
ＥＣ インシデント
ＣＭ 通常の消費量
ＳＵ 監視ツール
ＣＩ 瞬間的消費量
ＰＥ 期間
ＰＣ 消費量プロファイル
ＥＢ フットプリント
ＨＩ インシデント履歴
ＲＤ 診断、診断レポート
ＣＥ インシデント
ＯＲＤ スケジューラ

Claims (15)

1. スケジューラによって決定された計画カレンダ（ＣＡ）に従って、ＩＴインフラストラクチャ（ＦＷ）において実行されるアプリケーションのバッチ（ＢＡ）処理を監視するための方法であって、
   前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの輻輳の、インシデント（ＥＣ）として知られている少なくとも１つの事象の検出（６０）用に、および前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の識別（７０）用に、構成された監視ソフトウェア（ＬＳ）によって、
   前記計画カレンダ（ＣＡ）を表すデータからの、バッチ（ＢＡ）による前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの通常の消費量（ＣＭ）を表すデータの、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの経時的な記録ステップ（５０）と、
   前記計画カレンダ（ＣＡ）を表すデータによる、すべてのバッチ（ＢＡ）の実行の経時的な追跡調査ステップ（５１）と、
   前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの瞬間的消費量（ＣＩ）の、監視ツール（ＳＵ）による、経時的な測定ステップ（５２）と、
   前記識別（７０）を可能にするための、瞬間的消費量（ＣＩ）を表すデータと通常の消費量（ＣＭ）を表すデータとの間の、検出されたインシデント（ＥＣ）に近い期間（ＰＥ）中に実行されたバッチ（ＢＡ）のそれぞれに対する、比較ステップ（５３）と、
   を実施することにより、
   実施されることを特徴とする、方法。
2. 前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）が、前記インシデント（ＥＣ）のタイムスタンプ処理（６１）をトリガする、ことを特徴とする、請求項１に記載の方法。
3. 前記インシデント（ＥＣ）のタイムスタンプ処理ステップ（６１）のつぎに、監視ソフトウェア（ＬＳ）による、この事象に近い期間（ＰＥ）の決定（６１０）が続き、この期間が、事象に先行する、および／または後続する時間間隔まで拡張されることができる、ことを特徴とする、請求項２に記載の方法。
4. コンピューティングリソースの通常の消費量（ＣＭ）を表すデータの記録ステップ（５０）が、バッチの実行の持続時間全体にわたるリソースの消費量プロファイル（ＰＣ）の、バッチ（ＢＡ）のそれぞれに対する、記録ステップ（５００）を含む、ことを特徴とする、請求項１から３のいずれか一項に記載の方法。
5. 監視ソフトウェア（ＬＳ）のユーザが、バッチ（ＢＡ）の今後の実行の間の他のインシデント（ＣＥ）を回避するために取られるべき方策を決定し、任意選択で、結果としてカレンダ（ＣＡ）を修正するための、分析および／または決定への補助を提供するための診断レポート（ＲＤ）の、監視ソフトウェア（ＬＳ）による生成（７１）を、インシデント（ＥＣ）の分析中に得られた識別ステップ（７０）がトリガする、ことを特徴とする、請求項１から４のいずれか一項に記載の方法。
6. 監視ソフトウェア（ＬＳ）による少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）が、特に瞬間的消費量（ＣＩ）の測定ステップ（５２）中に得られたデータによる、インシデント（ＥＣ）に近い前記期間（ＰＥ）中に実行されたバッチ（ＢＡ）のそれぞれに関するフットプリント（ＥＢ）の、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの記録（６２）をトリガする、ことを特徴とする、請求項１から５のいずれか一項に記載の方法。
7. 監視ソフトウェア（ＬＳ）による少なくとも１つのインシデント（ＥＣ）の検出ステップ（６０）が、特に瞬間的消費量（ＣＩ）の測定ステップ（５２）中に得られたデータによる、インシデント履歴（ＨＩ）の、監視ソフトウェア（ＬＳ）によってアクセス可能なメモリへの記録（６３）をトリガする、ことを特徴とする、請求項１から６のいずれか一項に記載の方法。
8. 監視ソフトウェア（ＬＳ）による、瞬間的消費量（ＣＩ）を表すデータと通常の消費量（ＣＭ）を表すデータとの間の比較ステップ（５３）が、前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の前記識別（７０）を可能にする、ことを特徴とする、請求項１から７のいずれか一項に記載の方法。
9. 前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の前記識別（７０）が、検出されたインシデント（ＥＣ）に関係する分析中のデータと、以前のインシデントに関係するデータとの間の少なくとも１つの相関づけ（７００）に基づいている、ことを特徴とする、請求項６または７に記載の方法。
10. 前記相関づけ（７００）が、
    バッチのフットプリント（ＥＢ）を表すデータと、インシデント履歴（ＨＩ）を表すデータとの間の比較分析ステップ（７０１）と、
    バッチのフットプリント（ＥＢ）を表すデータと、通常の消費量（ＣＭ）を表すデータとの間の比較分析ステップ（７０２）と、
    のうちの少なくとも１つを含む、ことを特徴とする、請求項９に記載の方法。
11. 瞬間的消費量（ＣＩ）の測定ステップ（５２）が、様々なパラメータを測定する複数のプローブの事前配備（５２０）によって行われ、監視ツール（ＳＵ）が、このようにして測定された値を表すデータを監視ソフトウェア（ＬＳ）に伝送する、ことを特徴とする、請求項１から１０のいずれか一項に記載の方法。
12. 瞬間的消費量（ＣＩ）の測定ステップ（５２）中に生成されたデータが、通常の消費量（ＣＭ）の記録ステップ（５０）中に格納されたデータを計算するために、監視ソフトウェア（ＬＳ）によって使用される、ことを特徴とする、請求項１から１１のいずれか一項に記載の方法。
13. 前記計画カレンダ（ＣＡ）を表すデータによる、バッチ（ＢＡ）の実行の経時的な追跡調査ステップ（５１）が、監視ソフトウェア（ＬＳ）のユーザによる、前の計画ステップ（５９）に続いて得られ、監視ソフトウェア（ＬＳ）が、カレンダ（ＣＡ）を表すデータを記録することを可能にする、ことを特徴とする、請求項１から１２のいずれか一項に記載の方法。
14. スケジューラ（ＯＲＤ）によって決定された計画カレンダ（ＣＡ）に従って、ＩＴインフラストラクチャ（ＦＷ）において実行されるアプリケーションのバッチ（ＢＡ）処理を監視するためのシステムであって、請求項１から１３のいずれか一項に記載の方法を実施することによる、前記インフラストラクチャ（ＦＷ）のコンピューティングリソースの輻輳の、インシデント（ＥＣ）として知られている少なくとも１つの事象の検出（６０）用に、および前記インシデント（ＥＣ）の原因に関与している可能性がある少なくとも１つのバッチ（ＢＡ）の識別（７０）用に、構成された監視ソフトウェア（ＬＳ）がその上で実行されるコンピュータ手段を備える、ことを特徴とする、システム。
15. コンピュータ手段によって読み取り可能な媒体に格納されたコンピュータプログラム製品であって、請求項１から１３のいずれか一項に記載の方法を実施するための、これらのコンピュータ手段によって実行可能な命令を含む、コンピュータプログラム製品。

Images