JP2018109973A - コンピュータシステムアプリケーションの監視およびアラートのための機構 - Google Patents

コンピュータシステムアプリケーションの監視およびアラートのための機構 Download PDF

Info

Publication number
JP2018109973A
JP2018109973A JP2017245834A JP2017245834A JP2018109973A JP 2018109973 A JP2018109973 A JP 2018109973A JP 2017245834 A JP2017245834 A JP 2017245834A JP 2017245834 A JP2017245834 A JP 2017245834A JP 2018109973 A JP2018109973 A JP 2018109973A
Authority
JP
Japan
Prior art keywords
application
resource
usage
repository
performance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017245834A
Other languages
English (en)
Inventor
ブリュノ・デメイリエ
Demeilliez Bruno
クリストフ・ジェルマン
Germain Christophe
フロラン・ロシェット
Rochette Florent
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Publication of JP2018109973A publication Critical patent/JP2018109973A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3051Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0221Preprocessing measurements, e.g. data collection rate adjustment; Standardization of measurements; Time series or signal analysis, e.g. frequency analysis or wavelets; Trustworthiness of measurements; Indexes therefor; Measurements using easily measured parameters to estimate parameters difficult to measure; Virtual sensor creation; De-noising; Sensor fusion; Unconventional preprocessing inherently present in specific fault detection methods like PCA-based methods
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0283Predictive maintenance, e.g. involving the monitoring of a system and, based on the monitoring results, taking decisions on the maintenance schedule of the monitored system; Estimating remaining useful life [RUL]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3048Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the topology of the computing system or computing system component explicitly influences the monitoring activity, e.g. serial, hierarchical systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3495Performance evaluation by tracing or monitoring for systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5009Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • H04L41/5025Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/16Threshold monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Automation & Control Theory (AREA)
  • Environmental & Geological Engineering (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】コンピュータシステムアプリケーションの監視およびアラートのための機構を提供する。【解決手段】アプリケーションチェーンの1つまたは複数のアプリケーションのパフォーマンスの低下の期間中に消費量プローブによりアプリケーションの資源の使用レベルを測定し、アプリケーションチェーンのアプリケーション別および期間別に、少なくとも1つのメモリ21、22、23において、資源別およびアプリケーション別に、測定リポジトリ1の使用レベルの許容可能パフォーマンスの閾値を定義し記憶することによって使用リポジトリ2を確立する。測定リポジトリと使用リポジトリに応じてパフォーマンス問題のカテゴリ化モジュール3を構成し、監視機構がアプリケーションチェーンにおける1つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合に、アラート機構4を実現する。【選択図】図1

Description

本発明は、ITインフラストラクチャの監視の分野に関し、より具体的には、企業コンピュータシステムのアプリケーションの監視およびアラートの分野に関する。
最高情報責任者(Chief Information Officer:CIO)の活動範囲において、アプリケーションのサービス品質の順守が臨界閾値を上回る場合、またはアプリケーションが機能しない場合、介入が必要となる。一般に、この状況は、ソリューションを運営するインフラストラクチャに対して監視が整備されていない、および/または、アラートにおけるバックアップがなされないかあるいは遅すぎるという事実によって説明される。この場合、一般に、問題の分析に必要なデータが利用できないかまたは利用できなくなっているため、問題の原因を突き止めて問題を是正することはきわめて困難である。
ITインフラストラクチャの監視のためのソリューションは、従来技術から知られている。これらのソリューションは、サーバ上の競合の問題を診断するが、情報システムの資源の飽和とアプリケーションとを関連させることができない。これらのソリューションは、問題を解決するためにのみ技術的介入を開始するが、アプリケーションチェーンのアプリケーションまたはサーバのサービス品質の適正な順守および適正なパフォーマンスを確保するためにCIO(最高情報責任者)がその業務部門に対して保証するべき「サービスレベル合意書(SLA)」の水準に対応することができない。
このような状況において、コンピュータシステムのアプリケーションのパフォーマンスの問題を是正することによって従来技術の短所を解消するソリューションを提案することは注目される。
本発明の目的は、アプリケーションのパフォーマンスの問題を是正および/または予防するためのソリューションを提案することによって、従来技術のいくつかの短所を解消することである。
この目的のため、本発明は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するための、少なくとも1つのコンピュータマシンとマシンによって実行可能なソフトウェアまたはコードとを含むシステムであって、一方では、アプリケーションチェーンの1つまたは複数のアプリケーションのパフォーマンスの低下の期間中にアプリケーションの資源の使用レベルを測定するために資源上にインストールされた消費量プローブによる測定のためと、他方では、アプリケーションチェーンのアプリケーション別および期間別に、メモリ(11)においてこれらの使用レベルを測定リポジトリ(1)に記憶するために、測定リポジトリ(1)を形成するコンピュータハードウェアおよびソフトウェア構成を含み、システムのハードウェアおよびソフトウェア構成は、
少なくとも1つのメモリ(21、22、23)において資源別およびアプリケーション別に、使用レベルの許容可能パフォーマンスの閾値(Smin、Sint、Smax)を定義し、記憶することによって、測定リポジトリのデータの使用リポジトリ(2)を確立し、
測定リポジトリ(1)と使用リポジトリ(2)に応じてパフォーマンス問題のカテゴリ化モジュール(3)を構成し、
監視機構がアプリケーションチェーンにおける1つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合にアラート機構(4)を実現するようにさらに動作可能であることを特徴とするシステムに関する。
したがって、本発明は、アプリケーションが異常な動作を示す時または競合の発生より前に、アラート時にアプリケーションチェーンのアプリケーションの資源消費量と、アプリケーションの漸進的変化とを監視し、上記の問題を解決する。
別の特定の特徴によれば、使用レベルの許容可能パフォーマンスの閾値は、トリップレットを形成して最小閾値と最大閾値と中間閾値とからなる3つの許容可能閾値を含み、閾値のこのトリップレットは資源ごとおよびアプリケーションチェーンのアプリケーションごとに記憶される。
別の特定の特徴によれば、使用リポジトリは、測定リポジトリの使用レベルの測定値に基づいて定義された許容可能消費量区間をメモリに確立し、記憶する少なくとも1つのハードウェアおよびソフトウェア構成を含む。
別の特徴によれば、監視機構は、測定されて測定リポジトリに記憶された資源の使用レベルを、閾値および/またはアプリケーション別に使用リポジトリに確立された消費量区間と比較することができる。
別の特定の特徴によれば、使用リポジトリ(2)は、資源ごとの閾値(Smin、Sint、Smax)別の実際の使用レベル(21)と理論上の使用レベル(22)とをメモリに確立し、記憶するための少なくとも1つのハードウェアおよびソフトウェア構成(20)を含む。
別の特徴によれば、アプリケーションの資源消費量の異なるレベルを特徴づけるために、アプリケーションの資源の使用レベルが数回測定される。
別の特定の特徴によれば、アプリケーションの資源の使用レベルの測定は生産前環境または認定環境において行われる。
別の特定の特徴によれば、必要であれば使用レベルの許容可能パフォーマンスの閾値および/または資源ごとおよびアプリケーション別の消費量区間を精緻化するために、アプリケーションの資源の使用レベルの測定が生産環境においても行われる。
別の特定の特徴によれば、測定リポジトリは、資源別およびアプリケーション別の使用レベルの許容可能パフォーマンスの「季節的」閾値を確立し記憶するために、強い季節的使用変動を有する資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリに記憶するハードウェアおよびソフトウェア構成を含む。
別の特定の特徴によれば、パフォーマンス問題のカテゴリ化モジュールは、
メモリに記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成、または
測定された使用レベルが資源の最大閾値を上回る場合に、メモリに記憶される「ハードウェア異常」カテゴリを作成するための、測定リポジトリ内の利用可能な資源の測定された使用レベルと、使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
測定された使用レベルが資源の許容可能消費量区間外である場合に、メモリに記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するための、測定リポジトリにおいて利用可能な資源の測定された使用レベルと、使用リポジトリのメモリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能消費量区間との比較、または
アプリケーションの資源のニーズの季節性の規則とメモリに記憶される測定リポジトリにおいて利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源別およびアプリケーション別の将来のパフォーマンス低下消費量の計算、または
資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合に、メモリに記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するための、資源の将来の消費量の計算結果と、使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
上記の動作のうちの少なくとも2つの組合せの動作によってカテゴリ化を確立する。
別の特定の特徴によれば、アラート機構は少なくとも1つのメモリに、
測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「ハードウェア異常」アラートと、
測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリにおいて利用可能な前記資源の許容可能消費量区間外である場合の「アプリケーションパフォーマンス低下」アラートと、
カテゴリ化モジュールのメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「予防アプリケーションパフォーマンス」アラートと、のうちの少なくとも1つまたは複数のアラートを作成し記憶する。
別の特定の特徴によれば、システムは、アプリケーションチェーンの1つまたは複数のアプリケーション上の異常、または、アプリケーションの重要資源の過剰消費ないし将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができる。
他の目的は、これらのパフォーマンスの低下事象時に、アプリケーションチェーンのアプリケーション上で観察される徴候の監視およびアラート機構に関する従来技術の1つまたは複数の短所を是正することである。
この目的は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、本発明の特定の特徴のいずれか1つによるシステムを制御する方法であって、
資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップを含み、
方法は、
アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
測定された資源ごとおよびアプリケーションごとの最小閾値と最大閾値と中間閾値とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて使用リポジトリを構築するステップと、
使用リポジトリと、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて1つまたは複数の資源のパフォーマンス問題をカテゴリ化して記憶するステップと、
測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値と比較するステップと、
アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップにおいて取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、をさらに含む。
別の特定の特徴によれば、測定された使用レベルを許容可能パフォーマンスの閾値と比較するステップは、アプリケーションチェーンのアプリケーションを連続的に監視し、アラートするために連続的に反復される。
本発明のその他の特徴および利点は、以下の説明で詳述される。
本発明のその他の特定の特徴および利点は、添付図面を参照しながら以下の説明を読めばより明確にわかるであろう。
本発明の一実施形態によるアプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するためのシステムの要素を概略的に示す図である。 本発明の一実施形態によるアプリケーションチェーンのアプリケーションのパフォーマンスの監視とアラートを行う方法を概略的に示す図である。
以下において、コンピュータプローブとは、例えば、ある特定の変動があった後で、または周期的に、特にネットワークフローの品質またはサービス品質(QoS)を通知することを意図した測定値を自動的に測定し、管理し、監視装置にフィードバックする装置(例えばセンサ)に関連付けられたソフトウェアである。したがって、ネットワークを乱雑にするだけの反復的なコマンドをユーザ側で送る必要がなく、情報のフィードバックは、プローブによって自動的に行われる。
一実施形態では、プローブのサンプリング周波数は、アプリケーションチェーンを構成する異なる物理サーバおよび/または仮想サーバ間の測定値を互いに関係づけることができるように、一定かつ同期していなければならない。
本発明は、少なくとも1つのコンピュータシステムと、マシンによって実行可能なソフトウェアまたはコードとを含み、特にアプリケーションチェーンのアプリケーションのパフォーマンスの低下時に、アプリケーションチェーンのアプリケーション(またはサーバ)のパフォーマンスを監視するための機構を実現するために、アプリケーションチェーンの他のハードウェアまたはソフトウェアと通信するシステムに関する。アプリケーションチェーンのアプリケーションのパフォーマンスの低下は、アプリケーションチェーンのうちの1つまたは複数のアプリケーション(またはサーバ)上でのあらゆる種類の異常動作またはあらゆる種類の起こり得る競合である場合があり、例えばアプリケーションの資源の飽和またはアプリケーションの資源消費量であるが、これらには限定されない。アプリケーションチェーンは、全部または一部が複数のアプリケーションまたはサーバ(A、...、A、...、A)によって使用される1組の資源(R、...,R、...R)を含み、したがって、アプリケーションチェーンの構造は、メモリ内で各アプリケーションAに関連付けられた資源の識別子Lrのリストによって表される。
一実施形態では、システムは、測定リポジトリ(1)を記憶するための少なくとも1つのハードウェアおよびソフトウェア構成を含む。測定リポジトリ(1)は、消費量プローブによって、パフォーマンス低下期間Pdp中にアプリケーションチェーンを構成するすべてのアプリケーション(A、...,A、...A)のアプリケーションAのそれぞれ1つにおける資源Rの使用レベルNurを測定し、次に、これらのレベルNurを期間Pdpに関連付けて測定リポジトリ(1)のメモリ(11)に記憶して情報ダブレット(Nur,Pdp)を構成するための、少なくとも1つのハードウェアおよびソフトウェアコンピュータ構成(10)を含む。
消費量プローブは、資源の使用レベル(Nur)を表す測定値またはメトリクスに関する情報をフィードバックするために各資源に関連付けられる。各資源について、消費量プローブは、その資源名の識別子Lrと使用レベルNuとを定義する。各資源の使用レベルNurは、情報ダブレット(Lr,Nu)に対応する。同じ処理が、トリップレット(Lr,Nu,Pdp)を記憶するためにパフォーマンス問題のない期間についても行われる。
したがって、測定リポジトリのメモリ(11)は、トリプレット(Lr,Nu,Pdp)または(Lr,Nu,Pndp)を記憶し、これはプローブによって送信される情報の数および量を低減して、上述の知られているソリューションと比較してネットワークの大きさを低減するとともに、精度を向上させる効果がある。
実施形態によっては、プローブされる資源は、プロセッサ、入出力およびメモリに加えて、クラスタの各インスタンス、各アプリケーションキャッシュ、JMS/JDBCアプリケーンのプログラミングインターフェースメッセージのファイルの各サイズであり得る。JMS(java messaging service)アプリプログラミングインターフェース(API)は、アプリケーション間でメッセージを送受信するためのプログラミングインターフェースであり、JDBC(java database connectivity)は、データベースへのアクセスを可能にするAPIである。
例えば、資源(プロセッサ(中央演算処理装置(CPU)とも定義される)、メモリなど)の占有率(%)として算出される各サーバに加わる負荷、ディスクの入出力に加わる負荷、またはネットワークの速度に加わる負荷(接続パケット(伝送制御プロトコル(TCP)とも定義される)およびカウントオクテット)などの情報が、消費量プローブによってフィードバックされ得るが、これらには限定されない。
負荷、資源占有率(%)、応答時間、処理時間、CPU使用レベル、ディスク読み取りレベル、ディスク書き込みレベルなどの一般的要素が、プローブにより測定され得るが、ファイル数またはオープンポート数、JDBC(Java(登録商標)プログラムがデータベースにアクセスできるようにするプログラミングインターフェースであるJava DataBase Connectivity)メッセージファイル数、または、JMS(アプリケーション間でのメッセージの送受信のためのプログラミングインターフェースであるJava Message Service)メッセージファイル数、ファイルシステムの占有率、J2EEアプリケーション(Java Enterprise Edition、J2EEは分散アプリケーションの開発および実行のためのサーバ指向プラットフォームである)のためのガベージコレクタまたはメモリリトリーバの稼働率など、より具体的な要素または事象も測定され得る。
コンピュータハードウェアアーキテクチャのファイルシステムとは、例えば前記コンピュータアーキテクチャのファイルがそれに従って体系化され、扱われる一組の原則および規則を意味する。
実施形態によっては、システムは、構成リポジトリ(2)を含むハードウェアおよびソフトウェアコンピュータ構成(20)も含む。実際には、システムのハードウェアおよびソフトウェア構成は、少なくとも1つのメモリ(21、22、23)に、資源ごとおよびアプリケーションチェーンのアプリケーションごとの使用レベルの許容可能パフォーマンスの閾値(Smin、Sint、Smax)を定義し、記憶する、使用リポジトリを確立する。
プローブ消費量による資源の使用レベルの測定は、CIO(最高情報責任者)に、アプリケーションチェーンの任意のアプリケーションの資源消費量の現在のレベルと(計算による)予想レベルとに関する情報を与える。実施形態によっては、資源の消費量または使用の異なるレベルを正確かつ確実に特徴づけることができるように、使用レベルは数回、例えば3回以上測定されるが、これには限定されない。資源の使用レベルの反復測定は、一方では、許容可能パフォーマンスの閾値(Smin、Sint、Smax)、すなわち、そこからアプリケーションの資源のパフォーマンスが低下する閾値を確立し、他方では、アプリケーションの各資源の許容可能消費量区間(In)、すなわち、アプリケーションの資源のパフォーマンスが低下せず、適正に機能する区間を確立する。実施形態によっては、使用レベルのパフォーマンス閾値は、資源ごとおよびアプリケーションチェーンのアプリケーションごとに最小閾値(Smin)と中間閾値(Sint)と最大閾値(Smax)とからなるトリプレットを形成する3つの許容可能閾値を含む。この閾値のトリプレット(Smin、Sint、Smax)は、アプリケーションチェーンの任意のアプリケーションの資源ごとに使用リポジトリ(2)の少なくとも1つのメモリ(21、22、23)に記憶される。これらの異なる閾値は、信頼性のある指標または情報を定義し、確立しやすく、CIOによるアプリケーションのパフォーマンスの状態の認識に寄与するという利点を有する。実施形態によっては、消費量区間(In)は、測定リポジトリ(1)の使用レベルの測定値に基づいて確立され、資源ごとおよびアプリケーションチェーンのアプリケーション別に使用リポジトリ(2)のメモリ(24)に記憶される。この区間は、例えば事前に行われた測定リポジトリ(1)の使用レベルの測定値に基づいて計算することができる。実際には、これらの事前測定により、アプリケーションの使用または消費量の季節性、したがって各物理または仮想アプリケーション上の資源の使用レベルの季節性を確立する。消費量区間は、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値(Smin、Sint、Smax)に基づいて計算することもできる。この場合には、消費量区間は最小パフォーマンス閾値と中間閾値との間、中間閾値と最大閾値との間、または最小閾値と最大閾値との間とすることができる。
実施形態によっては、監視機構は測定されて測定リポジトリ(1)に記憶されている資源の使用レベルを、資源ごとおよびアプリケーションごとに使用リポジトリ(2)内に事前に確立されている、閾値(Smin、Sint、Smax)および/または消費量区間(In)と比較する。測定された使用レベルと事前設定され使用リポジトリに記憶されている閾値および/または区間とのこの比較は、システムがアプリケーションチェーンの1つまたは複数のアプリケーションにおいて潜在的競合および/または異常動作を検出した場合、またはその問題が解決された場合に、以下で詳述するアラート機構(4)を作動させる。したがって、従来技術の解決策とは異なり、本発明のシステムは、資源のパフォーマンスの低下とその影響を受けることになる情報システムのアプリケーションとを関係付けるという利点を有する。したがって、本発明の実施形態によれば、情報システムのアプリケーションの監視およびアラートを設定することによって、生産インシデントを是正および予防する。
実施形態によっては、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値(Smin、Sint、Smax)および/または消費量区間(In)を確立し、記憶するための使用レベルの測定は、生産前コンピュータ環境(アプリケーションのプログラムが部分的に実行される環境)または認定環境(アプリケーションのプログラムが試験される環境)において事前に行うことができる。したがって、この工程は、資源ごとおよびアプリケーション別の上流許容可能パフォーマンス閾値および/または消費量区間(In)を測定および確立して、コンピュータ生産段階に最も近いパフォーマンス閾値および消費量区間を生成し、アプリケーションパフォーマンスの低下の最適な検出を確実にする。
実施形態によっては、資源ごとおよびアプリケーション別の許容可能パフォーマンスの閾値(Smin、Sint、Smax)および/または消費量区間(In)を確立し、記憶するための使用レベルの測定は、事前設定されて使用リポジトリに記憶されているこれらの異なるパフォーマンス閾値および消費量区間を再定義および精緻化するために、コンピュータ生産環境において行うこともできる。この工程は、アプリケーションパフォーマンスが低下しているか否かの漸進的変化に応じて是正措置を実施することができるように、アプリケーションチェーンのアプリケーションの資源ごとのパフォーマンス閾値の漸進的変化を監視し、資源ごとおよびアプリケーションごとのパフォーマンス閾値および消費量区間の最適較正を得るための再測定および確立を再び行う。
図1の例について示すように、実施形態によっては、使用リポジトリ(2)は、少なくとも1つのメモリに、資源ごとの異なる閾値(Smin、Sint、Smax)別の実際の使用レベル(21)と理論使用レベル(22)とを確立し、記憶するための少なくとも1つのハードウェアおよびソフトウェア構成を含む。この場合、相互作用LrRのトリプレット(Nu,A,R)またはダブレット(Nu,Nur)は、
− メモリ(21)に、各資源Rの閾値(Smin、Sint、Smax)ごとの実際の使用レベルNumrRのリスト;
− メモリ(22)に、各資源Rの閾値(Smin、Sint、Smax)ごとの理論使用レベルNumtRのリストを記憶する。
各資源の理論上の使用レベルは、例えば、類似のインフラストラクチャ上のアバカス(例えばネットワークまたはディスクスループット)に応じて取得されるが、これには限定されない。各資源の実際の使用レベルについては、例えば異なる期間にわたる異なるプローブの結果を分析することによって取得されるが、これには限定されない。
実施形態によっては、測定リポジトリ(1)は、資源別およびアプリケーション別の使用リポジトリ(2)のメモリ(23)に、使用レベルの許容可能パフォーマンスの「季節的」閾値(Smin、Smin、Smax)を確立し記憶するために、使用変動の大きい資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリ(11)に記憶するためのハードウェアおよびソフトウェア構成を含む。この場合、相互作用LrRのためにトリプレット(Nu,A,R)またはダブレット(Nu,Nur)は、
− メモリ(21)に、各資源Rの閾値(Smin、Sint、Smax)ごとの実際の使用レベルNumrRのリスト;
− メモリ(22)に、各資源Rの閾値(Smin、Sint、Smax)ごとの理論使用レベルNumtRのリスト;
− メモリ(23)に、各資源Rの閾値(Smin、Sint、Smax)ごとの実際の使用レベルNumsRのリストを記憶する。
資源ごとの季節的使用レベルは、例えば各アプリケーションの資源ごとの全使用周期中(例えば資源またはアプリケーションの使用の変動性に応じて1ヶ月間、3ヶ月間または1年間)に異なるプローブを分析することによって取得されるが、これには限定されない。
これらのパラメータのリストは、資源、アプリケーション、および使用の種類(実際の使用、理論上の使用および/または季節的使用)に応じた、アプリケーションチェーンを構成するアプリケーション(またはサーバ)上の資源の測定された使用レベルと使用リポジトリ(2)の許容可能パフォーマンスの閾値(Smin、Sint、Smax)との比較を可能にすることができる。この比較は、パフォーマンス問題のない期間Pndpとの間で、パフォーマンス問題が発生する期間Pdpにわたって行われる。その目的は、アプリケーションチェーンのアプリケーションの資源の異常動作を是正することができるように、資源が使用レベルまたは異常消費量または最大レベル付近に達したことを検証し、アプリケーションの資源のこの使用レベルについてアラート機構を設定することである。アプリケーションパフォーマンスのこれらの比較分析を行うことによって、生産中のインシデントの時間が自動的に低減する。
実施形態によっては、システムは、測定リポジトリ(1)および使用リポジトリ(2)とに応じたパフォーマンス問題のカテゴリ化モジュール(3)も含む。
パフォーマンス問題のカテゴリ化モジュール(3)は、以下の動作によりカテゴリ化を構成するための少なくとも1つのハードウェアおよびソフトウェア構成(30)を含む。
− メモリ(31)に記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成;または
− 測定された使用レベルが資源の最大閾値を上回る場合にメモリ(32)内に記憶される「ハードウェア異常」カテゴリを作成するために、測定リポジトリにおいて利用可能な資源の測定された使用レベルと使用リポジトリにおいて利用可能なアプリケーションの各資源の使用レベルの許容可能パフォーマンスの最大閾値との比較;または
− 測定された使用レベルが資源の許容可能消費量区間(In)外である場合にメモリ(33)に記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するために、許容可能消費量区間(In)における測定リポジトリにおいて利用可能な資源の測定された使用レベルを使用リポジトリにおいて利用可能なアプリケーションの資源ごとの使用レベルと比較;または
− アプリケーションの資源のニーズの季節性の規則とメモリ(34)に記憶された測定リポジトリにおいて利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源ごとおよびアプリケーションごとのパフォーマンス低下の「将来の消費量」の計算;
− 資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合にメモリ(35)に記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するために、資源の将来の消費量の計算結果を使用リポジトリ内において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値と比較、または上記の動作のうちの少なくとも2つの動作の組合せ。
メモリ(31)(例えばIOネットワークまたはディスク)内の「資源消費量」カテゴリの作成は、その使用レベルNurがアプリケーションチェーンを構成する異なるアプリケーション(A、A、...)上で識別される任意の資源Rを、「資源消費量」にカテゴリ化または分類することからなる規則を使用することによって実現され、前記資源Rの識別子は「資源消費量」専用のメモリ(31)に記憶される。この作成は、資源ごとおよびアプリケーションごとに前記資源Rjの総合使用レベルNuGrを作成するために、測定リポジトリ(1)のメモリにおいて利用可能なアプリケーションの資源間の相互作用を使用して行われる。総合使用レベルNuGrは、各アプリケーションA上で使用される資源のすべてのレベルNurの合計ΣNurAをとることによって求められ、アプリケーションチェーンの任意のアプリケーション上の資源Rの合計測定消費量を表す。
メモリ(32)内の「ハードウェア異常」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルNurが、使用リポジトリ(2)において利用可能な各資源Rの実際の使用レベルNumrRおよび/または理論使用レベルNumtRおよび/または季節的使用レベルNumsRの許容可能パフォーマンスの最大閾値に達したかまたは超えた場合、システムは、例えばアプリケーションチェーンのアプリケーションの資源の飽和後の異常を作成する。
メモリ(33)における「アプリケーションパフォーマンス低下」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルNurが、使用リポジトリ(2)において利用可能な各資源Rの使用レベルの消費量区間外の場合。これは、例えばアプリケーションチェーンのアプリケーションの資源の異常動作時(例えば使われていないアプリケーションまたは、SLAの低下を引き起こすクラスタインスタンス上の問題など)の場合である。
メモリ(34)における「将来の消費量」カテゴリの作成は、「季節性」と呼ばれる規則と資源の現在の使用レベルとに基づいて行われる。資源またはアプリケーションの使用レベルは時間(例えば1日、1週間、1ヶ月または1年の1つまたは複数の時)にわたり変動する可能性があり、それによってアプリケーションチェーンを構成する異なるアプリケーションにわたって資源の使用レベルが変動することは明らかであろう。例えば、一部のアプリケーションは水曜日に需要がより少ない場合があり、これはパートタイマーの標準的な週日休暇によって説明され得る。別の非限定的な例として、金融アプリケーションは一般に、月次決算または四半期決算期間中に使用レベルが高くなる。このように、アプリケーションの使用のあらゆる漸進的変化は、(特にアプリケーションのユーザおよび事業活動の挙動により)アプリケーションによって異なるとともに時間とともに漸進的に変化する季節的規則によって定義され得る。これにより、情報システムのアプリケーションパフォーマンスの問題を自動的かつ連続的に監視し、アラートするためのシステムを採用する必要性の説明がつく。
メモリ(35)における「アプリケーションパフォーマンス予防」カテゴリの作成は、以下の規則を使用して行われる。資源の測定された使用レベルNurに基づく将来の消費量の計算の結果が、アプリケーションの飽和のリスクを示している場合。例えば、これに限定されるものではないが、CPUなどの資源の季節性規則が、期間P+60m(mは任意の存続期間を定義する)にその資源の使用レベル(すなわち将来の消費量)がその期間Pの3.2倍になると規定している場合である。このため、期間Pに、CPUの資源の測定された使用レベルがCPUの合計サイズの26%となる場合である。測定された使用レベルに季節性規則の予測を乗じて得られるこの資源の将来の消費量の結果(日付Dt=P+60mの季節性の規則によれば、使用レベルの26%に3.2を乗じてCPUの合計サイズの83.2%という結果が得られる)が、飽和リスクを示す上で重要となり、このCPUの飽和問題を(例えばCPUメモリを増強することによって)是正するようにアラートが設定される。
実施形態によっては、システムは、監視機構がアプリケーションチェーン内の1つまたは複数のアプリケーションのパフォーマンス問題を検出すると、またはその問題が解決されると、アラート機構(4)を実行するためのハードウェアおよびソフトウェアコンピュータ構成(40)も含む。
アラート機構は、少なくとも1つのメモリ(41、42、43)に以下のアラートのうちの少なくとも1つまたは複数を作成し、記憶する。
− 測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「ハードウェア異常」アラート;
− 測定リポジトリにおいて利用可能なアプリケーションの資源の使用レベルが使用リポジトリ内で利用可能な前記資源の許容可能消費量区間(In)外にある場合の「アプリケーションパフォーマンス低下」アラート;
− カテゴリ化モジュールのメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリにおいて利用可能な前記資源の許容可能パフォーマンスの最大閾値を上回る場合の「予防アプリケーションパフォーマンス」アラート。
「ハードウェア異常」アラートは、生産中の使用レベルが異常な場合に是正措置を設定するためにメモリ(41)に記憶される。この是正措置は、一般に、例えば、これに限定されるものではないが、メモリまたはプロセッサの増強や(スペースを追加するかファイルを削除するなどによる)ディスク上のスペースの開放など、仮想または物理コンピュータシステムのハードウェアまたはソフトウェア構成を変更する。
「アプリケーションパフォーマンス低下」アラートは、アプリケーションチェーン上でパフォーマンスの低下が検出された場合に適切な是正措置を設定するためにメモリ(42)に記憶される。この是正措置は、一般に、アプリケーションを監視して、例えば、これに限定されるものではないが、アプリケーションの非稼働、SLAの低下を引き起こすクラスタインスタンス上の問題などの問題の原因を決定する。このアラートは、資源の測定された使用レベルが、システムの使用リポジトリに記憶されているその事前設定資源の許容可能消費量区間(In)外にある場合に設定される。この区間は、アプリケーションの資源ごとの使用レベルの事前の測定値に基づいて、または資源別およびアプリケーション別のレベルの許容可能消費量の区間に基づいて設定可能である。
「予防アプリケーションパフォーマンス」アラートは、システムの目的が将来の問題の予防と予測である場合に、該当資源についてパフォーマンスの漸進的変化の推奨事項を設定するために、メモリ(43)に記憶される。したがって、アプリケーションの将来の資源消費量の予測に関して、最終期限に是正プログラムが確立される。したがって、この構成は、アプリケーションパフォーマンスの問題を制限し是正することになる最適是正プログラムを設定することができるように、時間を得る。
実施形態によっては、システムは、是正プログラム(5)を含むハードウェアおよびソフトウェア構成を含む。実際には、例えば図1および図2に示すように、システムによって検出されたアラートに従って適切な是正プログラム(5)を設定することができるように、異なる種類のアラートが処理プログラムによって分析される。
実施形態によっては、システムは、アプリケーションチェーンの1つまたは複数のアプリケーションの異常、またはアプリケーションの重要資源の過剰消費または将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができる。
図2の例について示すように、この監視機構は、各資源およびアプリケーション別の使用レベルの測定値を収集し、これらは、パフォーマンス問題を識別するために、カテゴリ化モジュール(3)のメモリ(31)において以下のようにしてカテゴリ化され記憶されることになる。
− 資源ごとおよびアプリケーションごとに事前に確立されたパフォーマンス閾値(Smin、Sint、Smax)との比較により、特に最大パフォーマンス閾値に達している資源が、システムによりカテゴリ化され、カテゴリ化モジュール(3)のメモリ(32)に記憶される;
− 資源ごとおよびアプリケーションごとに事前確立された消費量区間(In)との比較により、特に、許容可能消費量区間から外れる資源がシステムによってカテゴリ化されてカテゴリ化モジュール(3)のメモリ(33)に記憶される;
− 資源ごとおよびアプリケーションごとの将来の消費量を計算することにより、特にパフォーマンス問題のリスクを有することになる資源がシステムによってカテゴリ化され、カテゴリ化モジュール(3)のメモリ(34)に記憶される。
使用レベルが異常な場合、システムは自動的かつ継続的アラートによって改善策を設定する。したがって、検出されたパフォーマンス問題に応じて、システムはアラート機構(4)と適合する是正プログラム(5)とを設定する。例えば、カテゴリ化モジュール(3)が資源の測定された使用レベルがその許容可能パフォーマンスの最大閾値に達したことを示す場合、アラート機構は、その資源に対して適合する是正プログラムを設定するために、「ハードウェア異常」アラートをメモリ(41)に確立する。カテゴリ化モジュール(3)が資源の使用レベルが許容可能消費量の区間外にあることを示す場合、アラート機構は、前記資源に対して適合する是正プログラムを設定するために「アプリケーションパフォーマンス低下」アラートをメモリ(42)に確立する。最後に、カテゴリ化モジュール(3)が、資源の使用レベルが低下のリスク、例えば資源の飽和を呈していることを示す場合、アラート機構は、その資源に対して適合する是正プログラムを設定するために「予防アプリケーションパフォーマンス」アラートをメモリ(43)に確立する。
本発明は、アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、本願の実施形態のうちの1つによるシステムを制御する方法にも関する。この方法は、
資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップと、
アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
測定された各資源および各アプリケーションの最小閾値(Smin)と最大閾値(Smax)と中間閾値(Sint)とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップで取得されたデータに基づいて、使用リポジトリ(2)を構築するステップと、
使用リポジトリ(2)と、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて、、1つまたは複数の資源のパフォーマンス問題をカテゴリ化し、記憶するステップと、
測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値と比較するステップと、
アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップで取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、を含む。
実施形態によっては、アプリケーションチェーンのアプリケーションを連続して監視し、アラートするために、測定された使用レベルを許容可能パフォーマンス閾値と比較するステップが連続的に反復される。
図2の例について示すように、測定リポジトリ(1)のアプリケーションチェーンの資源ごとのアプリケーション別および季節性別の使用レベルの測定値は、カテゴリ化され、カテゴリ化モジュール(3)のメモリ(31)に記憶される。アプリケーションチェーン上のアプリケーションパフォーマンスの問題を監視し、CIOにアラートするために、これらの測定値は、許容可能パフォーマンス閾値と、または資源ごとにアプリケーション別に事前設定されている許容可能消費量の事前設定区間と比較される。測定リポジトリ(1)の使用レベルのこれらの測定値は、以下の3つの異なるステップで比較される。
− まず、測定されたレベルが使用リポジトリ(2)の最大パフォーマンス閾値(Smax)と比較され、使用レベルがその最大パフォーマンス閾値に達している場合、システムによって異常適用アラート(41)が設定される第1のステップ;
− 次に、第1のステップが異常を示さない場合、第2のステップにおいて、使用レベルが使用リポジトリ(2)の消費量区間(In)と比較され、使用レベルがその消費量区間外にある場合、システムによって「アプリケーションパフォーマンス低下」アラート(42)が設定され;
− 次に、第2のステップがパフォーマンスの低下を示さない場合、第3のステップにおいて、測定された使用レベルに基づいて将来の消費量の計算が行われ、使用レベルの測定が資源飽和のリスクを示す場合、システムによって「予防アプリケーションパフォーマンス」アラート(43)が設定され;
− 最後に、第3のステップが資源飽和のリスクを示さない場合、自動的かつ定期的に監視してアプリケーションチェーンにおいてパフォーマンス問題が発生した場合にアラートするために、使用レベルの新たな測定が行われる。
したがって、この方法のこれらの異なるステップは、コンピュータシステムにおけるパフォーマンス問題を制限することにより、またはそのような問題なしにコンピュータの動作の制御を最適化することができるように、連続的かつ自動的に行われる。本発明のアプリケーションパフォーマンス監視方法は、アプリケーションパフォーマンスの低下を迅速かつ自動的に識別し、企業コンピュータシステムのアプリケーションごとに連続的かつ適合した改善のための計画を設定するという利点を有する。
本願は、様々な技術的特徴および利点について図面および/または様々な実施形態を参照しながら説明している。当業者は、明示的に別様に記載されているか、または技術的特徴が相容れないか、または本願に記載の技術的問題のうちの少なくとも1つの解決策を提供しない場合を除き、ある実施形態の技術的特徴を実際には別の実施形態の特徴と組み合わせることが可能であることがわかるであろう。また、明示的に別様に記載されていない限り、ある実施形態において記載されている技術的特徴はその態様のその他の特徴とは分離され得る。
本発明が、特許される本発明の適用範囲から逸脱することなく他の多くの特定の形態の実施形態も可能にすることが、当業者には明かであるはずである。したがって、開示の実施形態は例示的なものとみなされるべきであり、特許請求の範囲によって定義されている範囲において変更されることができ、本発明は上述の詳細に限定されてはならない。
1 測定リポジトリ
2 使用リポジトリ
3 カテゴリ化モジュール
4 アラート機構
5 是正プログラム
10、20、40 ハードウェアおよびソフトウェアコンピュータ構成
11、21、22、23、24、31、32、33、34、35、41、42、43 メモリ

Claims (14)

  1. アプリケーションチェーンのアプリケーションのパフォーマンスを監視するための機構を実装するための、少なくとも1つのコンピュータマシンとマシンによって実行可能なソフトウェアまたはコードとを含むシステムであって、一方では、アプリケーションチェーンの1つまたは複数のアプリケーションのパフォーマンスの低下の期間中にアプリケーションの資源の使用レベルを測定するために資源上にインストールされた消費量プローブによる測定のためと、他方では、アプリケーションチェーンのアプリケーション別および期間別に、メモリ(11)においてこれらの使用レベルを測定リポジトリ(1)に記憶するために、測定リポジトリ(1)を形成するコンピュータハードウェアおよびソフトウェア構成を含み、システムのハードウェアおよびソフトウェア構成は、
    少なくとも1つのメモリ(21、22、23)において資源別およびアプリケーション別に、使用レベルの許容可能パフォーマンスの閾値(Smin、Sint、Smax)を定義し、記憶することによって、測定リポジトリのデータの使用リポジトリ(2)を確立し、
    測定リポジトリ(1)と使用リポジトリ(2)に応じてパフォーマンス問題のカテゴリ化モジュール(3)を構成し、
    監視機構がアプリケーションチェーンにおける1つまたは複数のアプリケーションのパフォーマンス問題を検出した場合、または問題が解決された場合に、アラート機構(4)を実現するようにさらに動作可能であることを特徴とする、システム。
  2. 使用レベルの許容可能パフォーマンスの閾値(Smin、Sint、Smax)が、トリップレットを形成して最小閾値(Smin)と最大閾値(Smax)と中間閾値(Sint)とからなる3つの許容可能閾値を含み、閾値のこのトリップレット(Smin、Sint、Smax)は資源ごとおよびアプリケーションチェーンのアプリケーションごとに記憶されることを特徴とする、請求項1に記載のシステム。
  3. 使用リポジトリ(2)が、メモリ(24)において、測定リポジトリ(1)の使用レベルの測定値に基づいて定義された許容可能消費量区間(In)を確立し、記憶する少なくとも1つのハードウェアおよびソフトウェア構成(20)を含むことを特徴とする、請求項1または2に記載のシステム。
  4. 監視機構が、測定されて測定リポジトリ(1)に記憶された資源の使用レベルを、閾値(Smin、Sint、Smax)および/またはアプリケーション別に使用リポジトリ(2)に確立された消費量区間(In)と比較することができることを特徴とする、請求項1から3のいずれか一項に記載のシステム。
  5. 使用リポジトリ(2)が、資源ごとの閾値(Smin、Sint、Smax)別の実際の使用レベル(21)と理論上の使用レベル(22)とをメモリに確立し、記憶するための少なくとも1つのハードウェアおよびソフトウェア構成(20)を含むことを特徴とする、請求項1から4のいずれか一項に記載のシステム。
  6. アプリケーションの資源消費量の異なるレベルを特徴づけるために、アプリケーションの資源の使用レベルが数回測定されることを特徴とする、請求項1から5のいずれか一項に記載のシステム。
  7. アプリケーションの資源の使用レベルの測定が生産前環境または認定環境において行われることを特徴とする、請求項1から6のいずれか一項に記載のシステム。
  8. 必要であれば使用レベルの許容可能パフォーマンスの閾値(Smin、Sint、Smax)および/または資源ごとおよびアプリケーション別の消費量区間(In)を精緻化するために、アプリケーションの資源の使用レベルの測定が生産環境においても行われることを特徴とする、請求項3から7のいずれか一項に記載のシステム。
  9. 測定リポジトリ(1)が、資源別およびアプリケーション別の使用レベルの許容可能パフォーマンスの「季節的」閾値(Smin、Sint、Smax)を確立し記憶するために、強い季節的使用変動を有する資源またはアプリケーションの「季節的」使用レベルを消費量プローブによって測定し、メモリ(23)に記憶するハードウェアおよびソフトウェア構成を含むことを特徴とする、請求項1から7のいずれか一項に記載のシステム。
  10. パフォーマンス問題のカテゴリ化モジュール(3)が、
    メモリ(31)に記憶され、資源ごとおよびアプリケーションチェーンのアプリケーションごとの測定された使用レベルの合計消費量を含む「資源消費量」カテゴリの作成、または
    測定された使用レベルが資源の最大閾値(Smax)を上回る場合に、メモリ(32)に記憶される「ハードウェア異常」カテゴリを作成するための、測定リポジトリ内(1)の利用可能な資源の測定された使用レベルと、使用リポジトリ(2)において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値(Smax)との比較、または
    測定された使用レベルが資源の許容可能消費量区間(In)外である場合に、メモリ(33)に記憶される「アプリケーションパフォーマンス低下」カテゴリを作成するための、測定リポジトリ(1)において利用可能な資源の測定された使用レベルと、使用リポジトリ(2)のメモリ(24)において利用可能なアプリケーションの資源ごとの使用レベルの許容可能消費量区間(In)との比較、または
    アプリケーションの資源のニーズの季節性の規則とメモリ(34)に記憶される測定リポジトリ(1)において利用可能なアプリケーションの資源の測定された使用レベルとの関連に基づく、資源別およびアプリケーション別の将来のパフォーマンス低下消費量の計算、または
    資源の将来の消費量の計算結果がアプリケーションの資源の許容可能パフォーマンスの最大閾値を上回る場合に、メモリ(35)に記憶される「アプリケーションパフォーマンス予防」カテゴリを作成するための、資源の将来の消費量の計算結果と、使用リポジトリ(2)において利用可能なアプリケーションの資源ごとの使用レベルの許容可能パフォーマンスの最大閾値との比較、または
    上記の動作のうちの少なくとも2つの組合せ
    の動作によってカテゴリ化を確立することを特徴とする、請求項3から9のいずれか一項に記載のシステム。
  11. アラート機構(4)が少なくとも1つのメモリ(41、42、43)に、
    測定リポジトリ(1)において利用可能なアプリケーションの資源の使用レベルが使用リポジトリ(2)において利用可能な前記資源の許容可能パフォーマンスの最大閾値(Smax)を上回る場合の「ハードウェア異常」アラートと、
    測定リポジトリ(1)において利用可能なアプリケーションの資源の使用レベルが使用リポジトリ(2)において利用可能な前記資源の許容可能消費量区間(In)外である場合の「アプリケーションパフォーマンス低下」アラートと、
    カテゴリ化モジュール(3)のメモリにおいて利用可能なアプリケーションの資源の将来の消費量の計算結果が、使用リポジトリ(2)において利用可能な前記資源の許容可能パフォーマンスの最大閾値(Smax)を上回る場合の「予防アプリケーションパフォーマンス」アラートと、
    のうちの少なくとも1つまたは複数のアラートを作成し記憶することを特徴とする、請求項3から10のいずれか一項に記載のシステム。
  12. システムが、アプリケーションチェーンの1つまたは複数のアプリケーション上の異常、または、アプリケーションの重要資源の過剰消費ないし将来の資源過剰消費によるアプリケーションチェーン上のパフォーマンスの低下を連続的に監視し、アラートすることができることを特徴とする、請求項1から11のいずれか一項に記載のシステム。
  13. アプリケーションチェーンのアプリケーションのパフォーマンスを監視し、請求項2から12のいずれか一項によるシステムを制御する方法であって、
    資源消費量の異なるレベルを特徴づけることができるように、アプリケーションチェーンのアプリケーションごとに資源の使用レベルを測定し、記憶するステップを含み、
    方法が、
    アプリケーションの異なる構成要素の資源のニーズを測定し、記憶するステップと、
    測定された資源ごとおよびアプリケーションごとの最小閾値(Smin)と最大閾値(Smax)と中間閾値(Sint)とを確立するために、アプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて使用リポジトリ(2)を構築するステップと、
    使用リポジトリ(2)と、アプリケーションチェーンのアプリケーションの資源のニーズと資源の使用レベルを測定し記憶するステップにおいて取得されたデータに基づいて1つまたは複数の資源のパフォーマンス問題をカテゴリ化して記憶するステップと、
    測定された使用レベルを、カテゴリ化ステップのパフォーマンス問題に基づいて許容可能パフォーマンスの閾値(Smin、Sint、Smax)と比較するステップと、
    アプリケーションチェーンまたはアプリケーションチェーンのアプリケーションの資源を修正することによってパフォーマンス問題を是正するために、比較ステップにおいて取得されたデータに基づいてパフォーマンス問題のアラートを設定するステップと、をさらに含むことを特徴とする方法。
  14. 測定された使用レベルを許容可能パフォーマンスの閾値(Smin、Sint、Smax)と比較するステップが、アプリケーションチェーンのアプリケーションを連続的に監視し、アラートするために連続的に反復されることを特徴とする、請求項13に記載の方法。
JP2017245834A 2016-12-29 2017-12-22 コンピュータシステムアプリケーションの監視およびアラートのための機構 Pending JP2018109973A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1663499 2016-12-29
FR1663499A FR3061570B1 (fr) 2016-12-29 2016-12-29 Mecanisme de surveillance et d'alertes des applications du systeme informatique

Publications (1)

Publication Number Publication Date
JP2018109973A true JP2018109973A (ja) 2018-07-12

Family

ID=59649747

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017245834A Pending JP2018109973A (ja) 2016-12-29 2017-12-22 コンピュータシステムアプリケーションの監視およびアラートのための機構

Country Status (6)

Country Link
US (1) US11556445B2 (ja)
EP (1) EP3343839A1 (ja)
JP (1) JP2018109973A (ja)
CN (1) CN108255671A (ja)
BR (1) BR102017028271A2 (ja)
FR (1) FR3061570B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020144669A (ja) * 2019-03-07 2020-09-10 日本電気株式会社 情報処理装置、コンテナ配置方法及びコンテナ配置プログラム

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3043223A1 (fr) * 2015-11-02 2017-05-05 Bull Sas Mecanisme d'analyse de correlation lors de la degradation des performances d'une chaine applicative.
WO2022018466A1 (en) * 2020-07-22 2022-01-27 Citrix Systems, Inc. Determining server utilization using upper bound values
US11500686B2 (en) 2020-07-31 2022-11-15 International Business Machines Corporation Resource management of a software application with multiple software components
US20230043579A1 (en) * 2021-08-06 2023-02-09 Accenture Global Solutions Limited System for monitoring and optimizing computing resource usage of cloud based computing application
US20230056727A1 (en) * 2021-08-23 2023-02-23 Dell Products, L.P. Managing the degradation of information handling system (ihs) performance due to software installations

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070050777A1 (en) * 2003-06-09 2007-03-01 Hutchinson Thomas W Duration of alerts and scanning of large data stores
WO2006032028A2 (en) * 2004-09-13 2006-03-23 Reactivity, Inc. Metric-based monitoring and control of a limited resource
WO2012098554A1 (en) * 2011-01-17 2012-07-26 Infosys Technologies Limited Method and system for preemptive detection of occurrence of faulty conditions based on resource usage
US8612599B2 (en) * 2011-09-07 2013-12-17 Accenture Global Services Limited Cloud service monitoring system
FR2980266B1 (fr) * 2011-09-15 2014-06-13 Snecma Systeme de surveillance d'une chaine de mesure d'un turboreacteur
US9323628B2 (en) * 2012-10-09 2016-04-26 Dh2I Company Instance level server application monitoring, load balancing, and resource allocation
EP2951686A4 (en) * 2013-01-31 2016-10-12 Hewlett Packard Entpr Dev Lp ASSIGNMENT OF PHYSICAL RESOURCES
FR3025678B1 (fr) 2014-09-04 2020-03-27 Bull Sas Methodes et systemes de surveillance de serveurs informatiques
FR3025960B1 (fr) * 2014-09-15 2016-11-11 Bull Sas Procede de surveillance d'une architecture applicative comportant une pluralite de services
FR3028973B1 (fr) 2014-11-25 2018-03-09 Bull Sas Systeme et methode de test de performances d'une infrastructure informatique
US10142179B2 (en) * 2015-03-12 2018-11-27 Ca, Inc. Selecting resources for automatic modeling using forecast thresholds
US10614056B2 (en) * 2015-03-24 2020-04-07 NetSuite Inc. System and method for automated detection of incorrect data
FR3043223A1 (fr) 2015-11-02 2017-05-05 Bull Sas Mecanisme d'analyse de correlation lors de la degradation des performances d'une chaine applicative.
US10409647B2 (en) * 2016-11-04 2019-09-10 International Business Machines Corporation Management of software applications based on social activities relating thereto

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020144669A (ja) * 2019-03-07 2020-09-10 日本電気株式会社 情報処理装置、コンテナ配置方法及びコンテナ配置プログラム
JP7234702B2 (ja) 2019-03-07 2023-03-08 日本電気株式会社 情報処理装置、コンテナ配置方法及びコンテナ配置プログラム

Also Published As

Publication number Publication date
US11556445B2 (en) 2023-01-17
EP3343839A1 (fr) 2018-07-04
BR102017028271A2 (pt) 2019-01-02
FR3061570B1 (fr) 2020-11-27
FR3061570A1 (fr) 2018-07-06
US20180217912A1 (en) 2018-08-02
CN108255671A (zh) 2018-07-06

Similar Documents

Publication Publication Date Title
JP2018109973A (ja) コンピュータシステムアプリケーションの監視およびアラートのための機構
US8230269B2 (en) Monitoring data categorization and module-based health correlations
US10735522B1 (en) System and method for operation management and monitoring of bots
US9658910B2 (en) Systems and methods for spatially displaced correlation for detecting value ranges of transient correlation in machine data of enterprise systems
US10095598B2 (en) Transaction server performance monitoring using component performance data
US9128792B2 (en) Systems and methods for installing, managing, and provisioning applications
US9798644B2 (en) Monitoring system performance with pattern event detection
JP2004348740A (ja) 異常検出のための自己学習方法及びシステム
US20100043004A1 (en) Method and system for computer system diagnostic scheduling using service level objectives
US20110270804A1 (en) Agile re-engineering of information systems
JP2010526352A (ja) 統計的な分析を利用した性能障害管理システム及びその方法
US10896073B1 (en) Actionability metric generation for events
US20210366268A1 (en) Automatic tuning of incident noise
US11762723B2 (en) Systems and methods for application operational monitoring
US9317269B2 (en) Systems and methods for installing, managing, and provisioning applications
US20150326446A1 (en) Automatic alert generation
JP2011170518A (ja) 状態監視装置及び方法
US8949824B2 (en) Systems and methods for installing, managing, and provisioning applications
US20150281008A1 (en) Automatic derivation of system performance metric thresholds
US20190044797A1 (en) Method and apparatus of establishing computer network monitoring criteria
Wang et al. Analyzing and monitoring kubernetes microservices based on distributed tracing and service mesh
TWI590052B (zh) 資料儲存裝置監測技術
JPWO2014020908A1 (ja) システム状態判別支援装置、及び、システム状態判別支援方法
US10735246B2 (en) Monitoring an object to prevent an occurrence of an issue
US11455558B2 (en) Method and system for managing events using automated rule generation