(57)【要約】  過去の平常時の挙動に基づいてパフォーマンスの監視を行う場合、平常時と異なるパフォーマンスの挙動を検出に際して、リソースの使い方が変動するシステムにおいては、平常時と異なる使い方が原因なのかどうかを判別することが難しい。システム稼動時のパフォーマンスを測定して平常稼動時と異なるパフォーマンスを検出する手段と、システムの使用に関する特性を測定して平常稼動時と異なる特性であることを検出する手段と、パフォーマンス情報と使用に関する特性情報を照合する手段により、パフォーマンスの挙動がシステムの使用に関する特性の変化であるかどうかを判別し、監視精度の向上を図る。
2017134758.tif 000002
【特許請求の範囲】
【請求項１】
第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機を管理し、プロセッサを含む管理計算機であって、
前記プロセッサは、
前記第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と前記第１のアプリケーションプログラムから前記第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得し、
前記第１の稼働性能の異常度と前記第１の使用特性の異常度とを算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする管理計算機。
【請求項２】
前記プロセッサは、
前記第１の稼働性能の異常度と第１の閾値とを比較する第１の判定をし、前記第１の使用特性の異常度と第２の閾値とを比較する第２の判定をし、
前記第１の判定と前記第２の判定との結果に基づいて、前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１に記載の管理計算機。
【請求項３】
前記管理計算機はさらに記憶装置を含み、
前記記憶装置は稼働性能の基準値と使用特性の基準値とを格納し、
前記プロセッサは、
前記取得した第１の稼働性能の前記稼働性能の基準値からの外れ度合いを前記第１の稼働性能の異常度として算出し、
前記取得した第１の使用特性の前記使用特性の基準値からの外れ度合いを前記第１の使用特性の異常度として算出する、
ことを特徴とする請求項２に記載の管理計算機。
【請求項４】
前記管理計算機は、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、には第１の通知を表示し、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、には第２の通知を表示する、
ことを特徴とする請求項３に記載の管理計算機。
【請求項５】
前記プロセッサは、所定の期間内に、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第１の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第２の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第３の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第４の回数、
を計測し、
前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数とのうち最大のものを算出し、
前記管理計算機は、
前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数の何れが最大かによって異なる通知を表示する、
ことを特徴とる請求項３に記載の管理計算機。
【請求項６】
前記プロセッサは、
前記取得した第１の稼働性能値から前記稼働性能値の基準値を作成し、前記取得した第１の使用特性値から使用特性値の基準値を作成する、
前記記憶装置は、前記作成された稼働性能値の基準値と前記作成された使用特性値の基準値とを格納する、
ことを特徴とする請求項３に記載の管理計算機。
【請求項７】
前記プロセッサは、所定の期間内に、前記第１の使用特性の異常度の前記第２の閾値を越える割合が所定の値を上回る場合には、前記稼働性能の基準値と前記使用特性の基準値とを再作成し、
前記記憶装置は、前記再作成された稼働性能の基準値と前記再作成された使用特性の基準値とを格納する、
ことを特徴とする請求項６に記載の管理計算機。
【請求項８】
前記管理計算機はさらに第２の管理対象計算機を管理し、
前記プロセッサは、
前記第２の管理対象計算機のリソース性能に関する値である第２の稼働性能と前記第１のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第２の使用特性とを取得し、
前記第２の稼働性能の異常度と前記第２の使用特性の異常度とを算出し、
前期第１の使用特性と前記第２の使用特性との合計である合計使用特性を算出し、
前記合計使用特性の異常度を算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記第２の稼働性能の異常度と前記第２の使用特性の異常度と前記算出された合計使用特性とから前記第１の管理対象計算機と第２の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１に記載の管理計算機。
【請求項９】
前記管理計算機はさらに第２のアプリケーションプログラムからアクセスされ、
前記プロセッサはさらに、
前記第２のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第３の使用特性を取得し、
前記第３の使用特性の異常度を算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記算出された第３の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１に記載の管理計算機。
【請求項１０】
第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機の管理方法であって、
前記第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と前記第１のアプリケーションプログラムから前記第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得し、
前記第１の稼働性能の異常度と前記第１の使用特性の異常度とを算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする管理対象計算機の管理方法。
【請求項１１】
前記第１の稼働性能の異常度と第１の閾値とを比較する第１の判定をし、
前記第１の使用特性の異常度と第２の閾値とを比較する第２の判定をし、
前記第１の判定と前記第２の判定との結果に基づいて、前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
【請求項１２】
前記管理計算機はさらに記憶装置を含み、
前記記憶装置は稼働性能の基準値と使用特性の基準値とを格納し、
前記取得した第１の稼働性能の前記稼働性能の基準値からの外れ度合いを前記第１の稼働性能の異常度として算出し、
前記取得した第１の使用特性の前記使用特性の基準値からの外れ度合いを前記第１の使用特性の異常度として算出する、
ことを特徴とする請求項１１に記載の管理対象計算機の管理方法。
【請求項１３】
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、には第１の通知を表示し、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、には第２の通知を表示する、
ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
【請求項１４】
所定の期間内に、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第１の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第２の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第３の回数、
前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第４の回数、
を計測し、
前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数とのうち最大のものを算出し、
前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数の何れが最大かによって異なる通知をする、
ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
【請求項１５】
前記取得した第１の稼働性能値から前記稼働性能値の基準値を作成し、
前記取得した第１の使用特性値から使用特性値の基準値を作成し、
前記作成された稼働性能値の基準値と前記作成された使用特性値の基準値とを格納する、
ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
【請求項１６】
所定の期間内に、前記第１の使用特性の異常度の前記第２の閾値を越える割合が所定の値を上回る場合には、前記稼働性能の基準値と前記使用特性の基準値とを再作成し、
前記再作成された稼働性能の基準値と前記再作成された使用特性の基準値とを格納する、
ことを特徴とする請求項１５に記載の管理対象計算機の管理方法。
【請求項１７】
前記管理計算機はさらに第２の管理対象計算機を管理し、
前記第２の管理対象計算機のリソース性能に関する値である第２の稼働性能と前記第１のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第２の使用特性とを取得し、
前記第２の稼働性能の異常度と前記第２の使用特性の異常度とを算出するステップと、
前期第１の使用特性と前記第２の使用特性との合計である合計使用特性を算出し、
前記合計使用特性の異常度を算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記第２の稼働性能の異常度と前記第２の使用特性の異常度と前記算出された合計使用特性とから前記第１の管理対象計算機と第２の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
【請求項１８】
前記管理計算機はさらに第２のアプリケーションプログラムからアクセスされ、
前記第２のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第３の使用特性を取得し、
前記第３の使用特性の異常度を算出し、
前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記算出された第３の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はシステムの稼働時の状況を監視する管理計算機および管理方法に関するものである。
【背景技術】
【０００２】
システムの運用管理においては、システムの稼動時にシステムの処理能力が低下することで利用者に影響を与えることを防ぐために、システムの処理の状況（以降では稼動性能と呼ぶ）を監視することで、稼働性能の異常に早期に気づき、事前に適切な対処する必要がある。稼動性能を把握するための指標としては、リソース使用量、スループット、レスポンスタイム等がある。【０００３】
ここでリソースとはシステムが処理を行うために必要な資源であって、システムを構成するサーバ、ストレージ装置、ネットワーク機器および、それら装置のCPU、メモリ、入出力装置、二次記憶装置等である。システムの稼動性能監視の方法としては、従来、平常時の性能指標の測定データを基準として、性能指標が平常時のふるまいと異なる場合を異常として検出する方法がある。【０００４】
平常時のシステムの性能指標の測定データから基準を作成する方法として、単一の性能指標の監視項目について時系列の基準を作成する方法が［特許文献１］に示されている。また、複数の性能指標の監視項目を組合せ、測定データのベクトル位置で分類することにより基準を作成する方法が［特許文献２］に示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2001-142746号公報
【特許文献２】特開2012-242985号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
クラウド環境のようにシステムをユーザに提供する場合、システムのリソースを使用するアプリケーションの挙動などのシステムのリソースの使い方（以降では使用特性と呼ぶ）が変化することがある。システムリソースの稼動性能は使用特性が変化していなくても、システムリソース自体の問題によって変動することもあれば、システムリソース自体に問題がなくとも、使用特性が変化したことに依存して変動することもある。そして、稼働性能の変動がシステムリソース自体の問題によるものなのか、使用特性の変化によるものなのかによって、とるべき適切な対処が異なる。しかし、前記の従来技術では、使用特性の変化は考慮されていないため、リソースの稼動時の性能指標に関する測定値が基準作成時のデータにない範囲となり、異常として検出された場合、管理者が、システム自体の問題による稼働性能の異常なのか、使用特性の変化による稼働性能の異常なのかをまず分析する必要ある。そのため、適切な対処をとるまでにかかる作業負担が多く、迅速な対処が行えないという課題がある。 
本発明は稼働性能の監視においてシステムリソースの使い方（使用特性）の変化を考慮した適切な判定を行うことで、管理者の原因調査や対策にかかる作業負担を軽減することを目的とする。
【課題を解決するための手段】
【０００７】
管理計算機は、プロセッサを含み、第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機を管理する。プロセッサは、第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と第１のアプリケーションプログラムから第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得する。そして、第１の稼働性能の異常度と第１の使用特性の異常度とを算出し、算出された第１の稼働性能の異常度と算出された第１の使用特性の異常度とから第１の管理対象計算機の稼働状況を通知する。
【発明の効果】
【０００８】
本発明によれば、稼働性能の監視において、リソースの使い方（使用特性）の変動が原因かどうかの適切な判定によって管理者の原因分析負担が軽減され、取るべき適切な措置を迅速に決定することが出来る。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施例１におけるシステムの概念を示す図である。
【図２】本発明の実施例１における管理サーバのハードウェア構成を示す図である。
【図３】本発明の実施例１における性能監視プログラムの機能モジュールの構成を示す図である。
【図４】本発明の実施例１における性能監視プログラムのフローチャートを示す図である。
【図５】本発明の実施例１における稼動性能に関する監視項目を管理する稼動性能監視項目管理テーブルのテーブル構成を示す図である。
【図６】本発明の実施例１における使用特性に関する監視項目を管理する使用特性監視項目管理テーブルのテーブル構成を示す図である。
【図７】本発明の実施例１における基準データを管理する仕組みを示す図である。
【図８】本発明の実施例１における性能監視プログラムの稼働状況診断処理のフローチャートを示す図である。
【図９】本発明の実施例１における監視対象のデータを時系列に管理する監視データ管理テーブルのテーブル構成を示す図である。
【図１０】本発明の実施例１における判定方法の仕組みを示す図である。
【図１１】本発明の実施例１における一定期間分のデータを使用した判定方法の仕組みを示す図である。
【図１２】本発明の実施例１における判定結果に応じた通知内容を管理する通知管理テーブルのテーブル構成を示す図である。
【図１３】本発明の実施例１における出力画面の例を示す図である。
【図１４】本発明の実施例２におけるシステムの概要を示す図である。
【図１５】本発明の実施例３におけるシステムの概念を示す図である。
【図１６】本発明の実施例３における一時刻の異常度の例を示す図である。
【発明を実施するための形態】
【００１０】
［第１の実施例］
図１は本発明を実施するコンピュータシステムの概念図である。それぞれ1台以上のユーザ計算機１００、サーバ１０２、ネットワーク機器１０３、ストレージ装置１０４と、システムを管理するための管理サーバ１０１から構成される。１台以上のユーザ計算機１００ではアプリケーションプログラム１０６が動作し、１台以上のサーバはそれぞれネットワークに接続される。またサーバ１０２とストレージ装置１０４は、図１ではネットワーク機器１０３経由で接続しているが、直接接続であってもよい。管理サーバ１０１は管理用ネットワーク（図示せず）を介して各装置と接続される。サーバでは例えばデータベース（DB）実行基盤（以降ではDBサーバと呼ぶ）やアプリケーション実行基盤といったミドルウェア１０５が動作し、アプリケーションプログラム１０６はインターネットまたはローカルネットワーク経由でミドルウェアにアクセスする。アプリケーションプログラムはミドルウェアと同じサーバ上で動作してもよい。
【００１１】
図２は管理サーバ１０１のハードウェア構成を示している。１つ以上の中央処理装置（CPU）２０１、メモリ２０２、ハードディスク等の二次記憶装置２０３、キーボード、マウスからの入力とディスプレイへの出力情報を制御する入出力インタフェース２０４、ネットワークに接続するネットワークインタフェース２０５から構成される。他サーバ１０２のハードウェア構成も同様である。なお、サーバおよび管理サーバは仮想サーバであってもよい。
【００１２】
管理サーバ１０１のメモリ２０２上には性能監視プログラム２０６がロードされ、CPU２０１により実行される。また二次記憶装置２０３には性能監視プログラムが使用するテーブル２０７のデータが保存される。アプリケーションサーバ１０２ではアプリケーションプログラムがメモリ上にロードされ、CPUにより実行される。
【００１３】
なお、各サーバは物理マシンでなく仮想マシンとして実装されてもよい。
【００１４】
図３は性能監視プログラムの機能モジュール構成を示す。サーバ、ストレージ装置等の性能指標であるリソース使用量等の稼動時の情報を収集する稼動性能情報収集部３０１、サーバ上のミドルウェアへのアクセスに関する情報を収集する使用情報収集部３０２、システムの正常稼動時に一定期間収集した情報を使用して監視の基準を作成する監視基準作成部３０３、作成した監視基準を管理する監視基準管理テーブル３０４、稼動性能情報の定期的な測定データを基準と比較して異常度を算出する稼動性能異常度算出部３０５、使用情報の定期的な測定データを基準と比較して異常度を算出する使用特性異常算出部３０６、算出した異常度から状況の判定を行う状況判定部３０７、判定結果を出力する出力部３０８から構成される。
【００１５】
図４は本実施例における性能監視プログラムのフローチャートであり、本実施例の処理の流れを示している。各ステップは中央処理装置（CPU）２０１によって実行される。監視基準作成ステップS４０１では一定期間収集した稼動性能の情報と使用特性の情報のそれぞれについて、監視基準を作成する。稼働性能の監視基準は図５の稼動性能監視項目管理テーブルに基づいて、使用特性の監視基準は図６の使用特性監視項目管理テーブルに基づいてそれぞれ作成される。よって、図５の稼動性能監視項目管理テーブル５００、図６の使用特性監視項目管理テーブル６００についてまず説明する。
【００１６】
図５は稼動性能監視項目管理テーブルの構成を示す図である。複数の監視項目を組み合わせたベクトルを管理するためのベクトルIDフィールド５０１、収集対象の装置またはソフトウェアの種別を示す対象フィールド５０２、監視対象の項目名を示す監視項目フィールド５０３から構成される。監視項目は、サーバ、サーバ上のミドルウェア、ストレージ装置、ネットワーク機器といった対象装置、ソフトウェアから定期的に情報を収集する項目であって、ベクトルは一つ以上の監視項目の組み合わせで管理する。これらの監視項目は監視対象装置のリソース性能に関する値であり、監視対象の装置のリソースが自身の処理能力を現在どれだけ発揮出来ているかを示すものである。図５の例では、ベクトルＩＤが１のベクトルは、収集対象をサーバとして、監視項目であるＣＰＵ使用率とメモリ使用率を管理する。ベクトルID５０１の組み合わせはシステムで事前に定義するか、管理サーバを使用するユーザが追加、削除により設定してもよく、図５で示すベクトルID５０１の組み合わせは例示に過ぎない。
【００１７】
図６は使用特性監視項目管理テーブルの構成を示す図である。複数の監視項目を組み合わせたベクトルを管理するためのベクトルIDフィールド６０１、収集対象の装置またはソフトウェアの種別を示す対象フィールド６０２、監視項目フィールド６０３から構成される。図６の例では、ベクトルＩＤが１のベクトルは、収集対象をサーバとして、監視項目であるセッション数とトランザクション数を管理する。これらの監視項目は、ユーザ計算機で稼動するアプリケーションプログラムからサーバへのアクセスに関する値である。監視項目は、システムで事前に設定するか、管理サーバを使用するユーザが追加、削除により設定され、一つ以上のベクトルとして管理する。図６で示すベクトルID６０１の組み合わせは例示に過ぎない。
【００１８】
図４の監視基準作成ステップS４０１での基準作成の説明に戻る。図５の稼動性能監視項目管理テーブルの監視項目フィールド５０３にある監視項目について、一定期間分の情報を収集する。ここでの期間は予めシステムに固定としてもよいし、管理サーバを使用する管理者が設定してもよい。各監視項目のデータは監視時刻が同じまたは監視時刻誤差内のものを同時刻のデータとみなして、各監視項目を軸とする複数次元のベクトル値として表す。
【００１９】
監視時刻誤差を1分未満とする場合、例えば監視項目フィールド５０３のＣＰＵ使用率の10時00分00秒のデータｘ１と、メモリ使用率の10時00分10秒のデータｙ１は、一つのベクトルのデータ（ｘ１、ｙ１）とする。ベクトル値として表した一定期間分のデータを一つ以上のグループに分類する。分類方法は例えば、近い値を複数の円（2次元の場合、三次元以上の場合は球）に分類し、グループの中心座標と半径を抽出するK-means手法とする。ここでのグループはクラスタと呼ばれる。分類結果は、図７（a）の監視基準管理テーブルに保存する。監視基準管理テーブルについては後に説明する。
【００２０】
また図６の使用特性監視項目管理テーブルで管理する監視項目についても、同様に情報の収集と分類を行う。
【００２１】
次に、作成した監視基準を使用した稼動状況診断を行う（S４０２）。稼動診断処理については後に図８の詳細フローを用いて説明する。
【００２２】
稼動診断処理後は、結果に基づいて通知が必要かを判定する（S４０３）。ここでの判定は、一時刻分の測定データの結果に基づいて、各ベクトルの判定結果に正常でない状態がある場合に通知を行う（S４０４）。または過去の複数（ｍ）回分の測定データの結果に基づいてｎ回以上、正常でない状態が続いた場合に通知するとしてもよい。回数ｍ、ｎはシステムで定義するかユーザが指定する。
【００２３】
稼動診断処理は、測定データ収集の都度、処理するフローとしているが、一定期間分をまとめて行ってもよい。その場合、通知が必要かどうかの判定は、ベクトル毎に一定期間分のデータの判定結果をまとめて、最も多い種別の通知のみを出力する方法としてもよい。
【００２４】
さらに、監視基準の再作成が必要かどうかを判断する（S４０５）。使用特性データの異常度が閾値以上である場合には、過去複数（ｍ）回分の使用特性データの異常度がｎ回以上閾値以上であるかを判断する。n回以上閾値以上になっている場合には、監視基準の再作成が必要として、再度、稼働性能と使用特性の双方について監視基準の作成を行う。
【００２５】
図７は作成した監視の基準となるクラスタを管理する仕組みを示す。図７(a)は作成した監視基準を管理する監視基準管理テーブルの構成を示す図である。監視基準作成処理により抽出したクラスタを識別するためのクラスタIDフィールド７０１、クラスタ別に、中心座標についてベクトルを構成する軸ごとの数値で管理する中心座標フィールド７０２、クラスタの円（３次元以上では球）の半径を管理する半径フィールド７０３から構成される。図７は２つの監視項目による２次元のベクトルを例としているが、３次元以上の場合は中心座標の軸フィールドを次元数に合わせる。図７（ｂ）はＣＰＵ使用率とメモリ使用率の２つの監視項目から作成した基準のクラスタを２次元グラフ上で示す例の図である。ここでは４つのクラスタが作成され、それぞれＩＤを付与する。
【００２６】
図８は稼動状況診断処理の流れを示すフローチャート図である。各ステップは中央処理装置（CPU）２０１によって実行される。測定した使用特性データについて、監視基準と比較して監視基準からの外れ度合いを示す数値（以降ではこの数値を異常度を呼ぶ）を算出する（S８０１）。ここで、異常度の算出は、測定データと中心座標との距離が最も近いクラスタを特定し、クラスタの半径を１と正規化して、測定データと中心座標との距離に基づいて算出する。測定データがクラスタから離れるほど、異常度は大きくなる。
【００２７】
管理サーバではユーザに対する通知を行うための判定基準として、異常度に対する閾値を管理する。閾値は、稼動性能監視ベクトルと使用特性監視ベクトルで同じ値であっても、異なる値であってもよい。閾値はシステムで事前に定義してもよいし、ユーザが設定してもよい。
【００２８】
次に稼動性能監視ベクトルについて同様に、ベクトル毎に測定データから異常度を算出する（Ｓ８０２）。
図８では、最初に使用特性データの異常度について閾値と比較し（S８０３）、次に稼動性能データの異常度について閾値を比較する（S８０４、S８０５）。その結果、状態を決定する（S８０６〜S８０９）。ここでリソースの稼動の状態を以下の条件で定義する。
【００２９】
・正常状態：使用特性が閾値未満かつ稼動性能が閾値未満の場合
・警告状態：使用特性が閾値未満かつ稼動性能が閾値以上の場合
・要注意状態：使用特性が閾値以上かつ稼動性能が閾値以上の場合
・注意（リスク小）状態：使用特性が閾値以上かつ稼動性能が閾値未満の場合
そして、この閾値との比較による状態決定を稼動性能監視用の全ベクトルについて繰り返す（S８１０、S８１１）。
【００３０】
図９は監視項目の測定データを管理する監視データ管理テーブルの構成を示す。使用特性ベクトルと稼動性能監視用の各ベクトルについて、時刻毎に、測定データと算出した異常度を管理する。ここで時刻に対する測定データは、監視時刻誤差内のものを該時刻のデータとみなす。例えば監視時刻誤差は±30秒未満とすると、時刻10時00分の測定データは09時59分31秒〜10時00分30秒間の監視時刻を持つデータとする。
【００３１】
図１０は稼動状況診断の仕組みを示す図である。図１０(a)は使用特性監視用ベクトルの一例である。監視項目として、DBサーバの使用を示すトランザクション数をｘ軸、セッション数をｙ軸としている。各円は監視基準であるクラスタを示している。図１０(b)は稼動性能監視用ベクトルの一例である。監視項目として、CPU使用率をｘ軸、メモリ使用率をｙ軸としている。各ベクトル上の丸印は測定データを示す。＃１〜＃４の丸印はそれぞれ同時刻のデータであることを示す。例えば図９で管理するデータから、時刻T1における測定データを＃１とした場合、図１０(a)では＃１のデータ（１００１）は異常度がa1で閾値未満であり、クラスタの円内にある。
【００３２】
図１０(b)では＃１のデータ（１００２）は異常度がa11で閾値以上であり、クラスタの円から外れている。使用特性と稼動性能の異常度をグラフのx軸、ｙ軸で表したものが図１０(ｃ)である。時刻T1における異常度（a1、a11）はデータ１００３の位置にプロットされ、この位置は警告範囲１００４であるため、状態は警告と判定される。＃２〜＃４についても同様に異常度に基づいてプロットした場合、それぞれ正常１００５、要注意１００６、注意(リスク小)１００７の範囲となり、各状態と判定される。
【００３３】
図１１はある稼動性能ベクトルについて、一定期間分のデータを監視した結果の例を示す図である。図４のフローチャートにおける通知が必要かの判断（S４０３）において、一定期間分のデータを使用する場合、一定期間のデータのうち、正常状態、警告状態、要注意状態、注意（リスク小）状態と判定されたデータの数をそれぞれ計測し、もっとも多いデータの数だった状態を通知する。例えば、図１１のようにそれぞれの異常度が閾値以上である範囲（１１０１）になるデータが最も多い場合、要注意状態と判断して通知を出力する。
【００３４】
また基準の再作成が必要かの判断（S４０５）においては、図１１の使用特性の異常度が閾値以上の範囲（１１０１と１１０２）に、一定割合以上のデータがある場合、稼働性能の基準と使用特性の基準の再作成が必要と判断する。再作成が必要と判断した場合には、稼働性能の基準と使用性能の基準を再作成し、管理サーバ１０１が再作成した稼働性能の基準と使用特性の基準を二次記憶装置２０３に格納する。具体的には図７（a）監視基準管理テーブルを更新する。
【００３５】
図１２は状態に応じて出力する通知内容を管理するテーブルである。監視対象のリソースを示す対象フィールド１２０１、状態フィールド１２０２と対応するメッセージ種別を示す種別フィールド１２０３、メッセージ内容を管理するメッセージフィールド１２０４から構成される。正常状態については本例ではメッセージをなし（null）で管理し、出力しない。メッセージに対象ベクトルの監視項目や対象装置を含めてもよい。
【００３６】
図１３は本実施例における出力画面の例を示す図である。上段（１３０１）には、監視対象の稼動性能監視用ベクトルの異常度を時系列に表示し、下段（１３０２）には、出力された通知をイベント一覧として表示する。イベント一覧では通知の種別とともに、適切な対処法を提案するメッセージを表示してもよい。上段のグラフ上で稼動性能が閾値を超過している場合でも通知は警告（１３０３）と注意（１３０４）といった異なる種別となっている。これらの表示により、管理者は、異なる通知によってとるべき適切な対処法を切り分けることができ、迅速な対処が可能となる。
【００３７】
また、管理者によっては、多くの通知の中から、例えば、警告（１３０３）の通知に対して優先的に対応したい場合もある。よって、図１３に示す出力画面上で、管理者が通知したい通知種別の選択を受け付け、選択された通知種別の通知のみを表示するようにしてもよい。これにより、多くの通知が発生した際に、管理者が現在必要としている通知のみを表示することで、管理者の管理効率が向上する。図１３は出力画面の一例にすぎず、例えば図１１の画面を出力してもよい。
【００３８】
以上により、リソース監視において、リソースを使用する側の特性の変動が原因かどうかの適切な判定によって通知を分けることができ、管理者に対する切り分け処理の負担を軽減できる。
【００３９】
一つの具体例では、クラウド環境のPaaS（Platform as a Service）形態で、DBサーバをユーザのアプリケーションプログラムに提供する。提供システムの監視において、DBサーバを実行するサーバのCPU使用率が普段と異なることを検出した場合、例えばDBサーバで適切でない実行計画を用いたことでCPU使用が増えたケースはDBサーバの側の異常つまりリソース自体の異常だが、トランザクション数が普段より多いケースは入力増加というリソースの使い方（使用特性）の変化に伴うCPU使用増加である。従来技術ではこれらを区別できないため、管理者がどちらのケースなのかを分析せねばならず、適切な対処を迅速に行うことができない。
【００４０】
しかし、本発明により、CPU使用率の変動を検出し、通知がなされる場合には、トランザクション数に変動があったか否かによってさらに異なる通知がされるため、管理者は通知に対応する適切な対処を迅速に行うことが可能となる。
［第２の実施例］
本発明の第１の実施例の変形例として、アプリケーションプログラムが使用するミドルウェアが複数のサーバに分散された構成の実施例を示す。実施例１は稼動状況を監視する装置一台と、アプリケーションプログラムによる使用特性を一つのベクトルで監視する形態であるのに対して、本実施例は稼動状況を監視する装置およびミドルウェアが複数台である点が異なる。
【００４１】
図１４は実施例２における本発明が対象とするシステムの概要を示す。複数台のサーバで同じミドルウェアが動作し、アプリケーションプログラムとサーバは負荷分散装置１４０１に接続する。アプリケーションプログラムからのアクセスは、負荷分散装置によって、複数台のミドルウェアに分散して処理される。複数のミドルウェアへの分散は、ユーザ計算機１０６やサーバ１０２が負荷分散ソフトウェアを有して実行してもよいし、ユーザ計算機１０６やサーバ１０２とは別の装置が負荷分散ソフトウェアを有して実行してもよい。
【００４２】
ここでは実施例１同様、ミドルウェアをDBサーバの例で説明する。DBサーバは複数台での分散処理する構成において、ストレージ装置を共有としてデータを共有する。
【００４３】
本実施例においては、アプリケーションプログラムの使用特性はアクセス先である各サーバのOSおよびDBサーバから取得する。さらに、同時刻に各サーバから取得した使用情報に関する監視項目の測定データを合算した値を算出する。なお監視時刻が一定誤差内のデータを、同時刻の測定データとみなす。
【００４４】
使用特性監視用ベクトルについては、複数のDBサーバをそれぞれ監視するベクトルと、合算値を監視するベクトルを設ける。図９で示した監視データ管理テーブルには、使用特性監視用のカラム（図９の例ではトランザクション数、セション数、異常度）をサーバ毎に設ける。さらに、トランザクション数、セション数それぞれについて、分散構成の全サーバの合計値と、合計値における異常度を管理するカラムを設ける。
【００４５】
稼動性能については、実施例１同様、サーバ、ストレージ装置等から収集し、装置毎に稼動性能監視用ベクトルを設けて監視する。
【００４６】
測定データの合算処理は、図４のフローチャートの監視基準の作成処理（S４０１）と稼動診断処理（S４０２）において行う。
【００４７】
監視基準については、使用特性監視用の監視基準として分散されたDBサーバ毎の基準と、DBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準を作成する。
図８のフローチャートで示す稼動診断処理については、使用特性データから異常度を算出するステップ（S801）において、サーバ毎の使用特性の異常度と各サーバの使用特性の合計値の異常度を算出する。サーバ毎の使用特性の異常度は、サーバ毎の使用特性とDBサーバ毎の基準から算出し、各サーバの使用特性の合計値の異常度は、各サーバの使用特性の合計値とアプリケーションプログラム毎の基準から算出する。
【００４８】
算出の方法は実施例１と同様である。使用特性の異常度とサーバの稼働性能の異常度を照らし合わせる場合、異常度を照らし合わせて状況を判別するステップでは、まず実施例１と同様に、サーバ毎にサーバの使用特性の異常度と、各稼動性能の異常度とを照らし合わせて判定する。つまり、図８のステップ（S８０１）でサーバ毎の使用特性とDBサーバ毎の基準とからサーバ毎の使用特性の異常度を算出する。そして、ステップ（S８０３）ではサーバ毎の使用特性の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
【００４９】
この判定により、個々のサーバに分散されたサーバへのアプリケーションプログラムからのアクセスが、それぞれのサーバの稼動性能に与える影響を考慮した状況を判別した通知を行うことができる。
【００５０】
上記の判定に加えて、本実施例では個々のサーバの各稼動性能の異常度に対して、分散されたアクセスの合計値に基づくアプリケーションプログラムの使用特性の異常度を照らし合わせて判定する処理を追加する。つまり、図８のステップ（S８０１）で各サーバの使用特性の合計値とDBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準とから各サーバの使用特性の合計値の異常度を算出する。そして、ステップ（S８０３）では各サーバの使用特性の合計値の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
【００５１】
上記のサーバ毎の使用特性の異常度との突き合わせによる判定では、分散の割合が変化したのか、アプリケーションプログラムの使用特性そのものが変化したのか分からないので、アプリケーションプログラム単位に合計した値を使用特性として照らし合わせることで、アプリケーションプログラムの使用特性が平常時と異なる状況なのかを判別した通知が可能になる。
【００５２】
さらに、使用特性の異常度とストレージ装置の稼働性能の異常度を照らし合わせる場合は、ストレージ装置は分散サーバに共有されているため、使用特性は合計値の異常度を使用し、ストレージ装置の各稼動性能の異常度と照らし合わせて判定する。つまり、図８のステップ（S８０１）で各サーバの使用特性の合計値とDBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準とから各サーバの使用特性の合計値の異常度を算出する。そして、ステップ（S８０３）では各サーバの使用特性の合計値の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
【００５３】
この判定により、ストレージ装置の稼働性能が平常時と異なる（異常度が閾値以上）場合であっても、アプリケーションプログラムの使用特性が平常時と異なる状況なのかを判別した適切な通知を行うことができる。  また、本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S４０５）については、アプリケーションプログラム単位で使用状況が変化したかを判断するため、使用特性データとして各サーバの合計値から算出される異常度のデータを用いる。合計値の使用特性データの異常度が閾値以上である場合に、一定期間の過去データのうち一定個数以上が閾値以上である場合には、使用特性と各稼動性能のベクトルについて監視基準の再作成が必要と判断する。
【００５４】
以上により、分散処理構成のシステムにおいても、分散されたリソースの稼動性能と、それらのリソースを使用するアプリケーションプログラムの使用特性のデータを照らし合わせることにより、リソースの状態の適切な判定による通知が可能となる。
［第３の実施例］
本発明の第１の実施例の変形例として、一台の装置のリソースに対して、使用するソフトウェアが複数である構成における実施例を示す。実施例１は稼動性能を監視する装置一台と、アプリケーションプログラムによる使用特性を一つのベクトルで監視する形態であるのに対して、本実施例は装置一台の稼動性能に対して、使用特性のベクトルが複数となる点が異なる。
ここでは、サーバ仮想化環境を例とする。図１５は実施例３における本発明が対象とするシステムの概要を示す。一台の物理サーバ１５０１のリソースを仮想化基盤ソフトウェアであるハイパーバイザ１５０２が仮想化し、複数の仮想マシン１５０３が使用する構成である。クラウド環境では仮想マシンを顧客に提供するIaaS（Infrastructure as a Service）形態を想定する。
【００５５】
物理サーバ１５０１は図１と同様にネットワーク機器１０３に経由でストレージ装置１０４と接続されるが直接接続であってもよい。管理サーバ１０１は管理用ネットワーク（図示せず）を介して図１５のように各装置と接続される。仮想マシン１５０３上にはアプリケーションプログラム等が動作するが、ここでは個々のアプリケーションプログラムは監視の対象とせず、仮想マシン毎に物理サーバのリソースを使用する情報を、使用特性監視用ベクトルの情報として取得する。図６の使用特性監視項目管理テーブルには、対象を仮想マシンとして、仮想マシンの監視項目であるCPU使用率やメモリ使用率の組合せを管理する。
【００５６】
稼動性能の情報については、実施例１と同様に装置から稼動時の情報を収集する。ここでは物理サーバのハイパーバイザを対象とし、リソースの競合等に関する項目を稼動性能監視用ベクトルの情報として収集する。例えばCPUで仮想マシンの実行をスケジュールできなかった時間の割合を示す値や、メモリのスワップ使用量等とする。図５の稼動性能監視項目管理テーブルには、対象をハイパーバイザとして、これらの項目を組み合わせて管理する。
【００５７】
測定データについては、図９の監視データ管理テーブルには、使用特性監視用のカラムを仮想マシン毎に設けて管理する。稼動性能監視用のカラムはハイパーバイザ用の監視項目のカラムで管理する。
【００５８】
図４のフローチャートにおいて、監視基準の作成処理（S４０１）は第１の実施例と同様である。仮想マシン毎の使用特性データとハイパーバイザの稼動性能データについて、過去の測定データから監視基準を作成する。
【００５９】
図８の稼動状況診断処理では、仮想マシン毎の使用特性データとハイパーバイザの稼働性能データについてそれぞれ異常度を算出する。データを照らし合わせて状況を判断する処理については、実施例１では各稼動性能データの異常度に対して、同一時間帯の一つの使用特性データの異常度を照らし合わせるが、本実施例では一つの稼動性能データの異常度に対して、同一時間帯の複数の使用特性データを照らし合わせる点が異なる。
【００６０】
図１６は、本実施例における、ある時刻のデータを判定する仕組みを示す図である。ハイパーバイザの稼動性能データの異常度をｙ軸に、各仮想マシンの使用特性データの異常度をｘ軸で表している。丸印はある時刻のそれぞれの異常度をベクトルで表した座標を示している。同一時刻において稼動性能データの異常度は同じであり、図１６には時刻T1におけるデータ１６０１と、時刻T2におけるデータ１６０２を示している。
【００６１】
本実施例における判定では、ハイパーバイザの稼動性能データが平常時と異なり（異常度が閾値以上）、いずれの仮想マシンも平常時と同様の使用特性である（異常度が閾値未満）場合（１６０１）は、ハイパーバイザの稼働状況を警告状態と判断する。
【００６２】
ハイパーバイザの稼動性能データが平常時と異なり（異常度が閾値以上）、いくつかの仮想マシンの使用特性データが平常時と異なる（異常度が閾値以上）場合（１６０２）は、該仮想マシンの使用特性が変化したことによるハイパーバイザの挙動であって、要注意状態と判断する。ここでは、使用特性データの異常度が閾値以上の仮想マシンが全体台数に対して特定の割合以上の場合に要注意状態と判断してもよいし、異常度が閾値以上の仮想マシンが１台であっても要注意状態と判断してもよい。範囲に含まれる仮想マシンの割合についての判断条件は予めシステムか管理者が定義しておく。ハイパーバイザの稼動性能データが閾値未満である場合についても、正常か注意（リスク小）状態かは、仮想マシン毎の使用特性データの異常度と、各範囲に含まれる仮想マシンの割合によって同様に判定する。
【００６３】
通知時のメッセージについては、実施例１の図１２と同様で、対象をハイパーバイザとして状態別に管理し、判定に従って通知する。
【００６４】
なお、通知については、一時刻の判断結果が正常時以外の場合に通知する方法だけでなく、一定期間の判定結果について、最も多くの判定結果が含まれる状態を通知する方法としてもよい。例えば時刻T１からT10までの判定結果が、T1では警告、T2〜T10までは要注意であれば、T10の判定後に要注意状態として通知する。
【００６５】
さらに本実施例では、判定した状態の通知に、仮想マシンの情報を含めて通知する。例えば判定状態が警告である場合には、各仮想マシンの使用特性データの異常度はいずれも閾値未満であり、「稼動性能に影響を与える仮想マシンはなし」とする。判定状態が要注意である場合には、使用特性データの異常度が閾値以上の仮想マシンが存在し、「使用特性が変化した仮想マシンはVM１,VM２,VM３」といった情報を通知に付与する。
ユーザへの表示については、図１２による通知に限られず、例えば管理計算機が図１６に示す画面を表示し、図１６を示す画面上で個々のデータにVM１,VM２,VM３といったそれぞれの仮想マシンを対応させてユーザに示してもよい。これにより、ユーザは稼働性能に影響を与えている、仮想マシンとその使用特性の異常度がどの程度かを把握することが可能となる。
【００６６】
また本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S405）については、仮想マシン毎に複数の使用特性データを持つことから、使用特性データの異常度が閾値以上になった仮想マシンが、システムで定義する特定の割合以上になった場合に、基準の再作成が必要と判断する。各仮想マシンの使用特性データとハイパーバイザの稼動性能データについて、それぞれ監視基準を再作成する。
【００６７】
以上により、リソースの提供側であるハイパーバイザの稼動性能と、リソースを使用する各仮想マシンの使用特性を照らし合わせることで、ハイパーバイザのリソースに問題があるのか、使用特性の変化した仮想マシンが影響しているのかを判別して、適切な通知を行うことができる。また管理者はハイパーバイザの稼動性能が平常時と異なる場合に、影響を与えている仮想マシンを容易に判別することができる。
【００６８】
また、本実施例は図１５の構成に限られず、図１でユーザ計算機１００が複数存在し、複数のアプリケーションプログラム１０６からサーバ１０２にアクセスがある場合にも適応できる。
【００６９】
この場合には、複数のアプリケーションプログラム１０６毎に、図６に示すアプリケーションプログラム１０６からサーバ１０２へのアクセスに関する値を管理する。そして、使用特性が監視用ベクトルの情報として取得する情報は、仮想マシン毎に物理サーバを使用する情報ではなく、複数のアプリケーションプログラム１０６毎のサーバ１０２へのアクセスに関する値となる。
【００７０】
稼働性能の情報については、実施例１と同様であり、測定データについては、図９の監視データ管理テーブルには、使用特性監視用のカラムをアプリケーションプログラム（AP）１０６毎に設けて管理する。
【００７１】
図４のフローチャートにおいて、監視基準作成処理(S401)は実施例１と同様である。アプリケーションプログラム１０６毎の使用特性データと図５に示す監視項目の稼働性能データについて、過去の測定データから監視基準を作成する。
【００７２】
図８の稼働状況診断処理では、アプリケーションプログラム１０６毎の使用特性データとサーバ１０５、ストレージ１０４の稼働性能データについてそれぞれ異常度を算出する。データを照らし合わせて状況を判断する処理については、図１５の構成の場合と同様に一つの稼動性能データの異常度に対して、同一時間帯の複数の使用特性データを照らし合わせる。
【００７３】
図１６では、サーバ１０２又はストレージ装置１０４の稼動性能データの異常度をｙ軸に、各アプリケーションプログラム１０６の使用特性データの異常度をｘ軸で表す点が図１５の構成の場合と異なる。
【００７４】
図１の構成の場合における判定では、サーバ１０２又はストレージ装置１０４の稼動性能データが平常時と異なり（異常度が閾値以上）、複数の使用特性の何れもが平常時と同様の使用特性である（異常度が閾値未満）場合（１６０１）は、サーバ１０２又はストレージ装置１０４の稼働状況を警告状態と判断する。
【００７５】
サーバ１０２又はストレージ装置１０４の稼動性能データが平常時と異なり（異常度が閾値以上）、いくつかの使用特性データが平常時と異なる（異常度が閾値以上）場合（１６０２）は、使用特性が変化したことによるサーバ１０２又はストレージ装置１０４の挙動であって、要注意状態と判断する。ここでは、使用特性データの異常度が閾値以上のアプリケーションプログラム１０６の数が総数に対して特定の割合以上の場合に要注意状態と判断してもよいし、異常度が閾値以上のアプリケーションプログラム１０６が１つあっても要注意状態と判断してもよい。範囲に含まれるアプリケーションプログラム１０６の割合についての判断条件は予めシステムか管理者が定義しておく。ハイパーバイザの稼動性能データが閾値未満である場合についても、正常か注意（リスク小）状態かは、アプリケーションプログラム１０６の使用特性データの異常度と、各範囲に含まれるアプリケーションプログラム１０６の割合によって同様に判定する。
【００７６】
通知時のメッセージについては、対象をサーバ１０２又はストレージ装置１０４として状態別に管理し、判定に従って通知する。
【００７７】
なお、通知については、一時刻の判断結果が正常時以外の場合に通知する方法だけでなく、一定期間の判定結果について、最も多くの判定結果が含まれる状態を通知する方法としてもよい。例えば時刻T１からT10までの判定結果が、T1では警告、T2〜T10までは要注意であれば、T10の判定後に要注意状態として通知する。
【００７８】
さらに図１の構成の場合の本実施例では、判定した状態の通知に、アプリケーションプログラム１０６の情報を含めて通知する。例えば判定状態が警告である場合には、各アプリケーションプログラム１０６の使用特性データの異常度はいずれも閾値未満であり、「稼動性能に影響を与えるアプリケーションプログラム１０６はなし」とする。判定状態が要注意である場合には、使用特性データの異常度が閾値以上のアプリケーションプログラム１０６が存在し、「使用特性が変化したアプリケーションプログラム１０６はAP１,AP２,AP３」といった情報を通知に付与する。
【００７９】
ユーザへの表示については、図１２による通知に限られず、例えば管理計算機が図１６に示す画面を表示し、図１６を示す画面上で個々のデータにAP１,AP２,AP３といったアプリケーションプログラム１０６を対応させてユーザに示してもよい。これにより、ユーザは稼働性能に影響を与えている、アプリケーションプログラム１０６とその使用特性の異常度がどの程度かを把握することが可能となる。
【００８０】
また図１の構成における本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S405）については、アプリケーションプログラム１０６毎に複数の使用特性データを持つことから、使用特性データの異常度が閾値以上になったアプリケーションプログラム１０６が、システムで定義する特定の割合以上になった場合に、基準の再作成が必要と判断する。各アプリケーションプログラム１０６の使用特性データとサーバ１０２、ストレージ装置１０４の稼動性能データについて、それぞれ監視基準を再作成する。
【００８１】
以上により、リソースの提供側であるサーバ１０２、ストレージ装置１０４の稼動性能と、各アプリケーションプログラム１０６からサーバ１０２へのアクセスに関する値である使用特性を照らし合わせることで、サーバ１０２、ストレージ装置１０４のリソースに問題があるのか、使用特性の変化したアプリケーションプログラム１０６が影響しているのかを判別して、適切な通知を行うことができる。また管理者は稼動性能が平常時と異なる場合に、影響を与えているアプリケーションプログラム１０６を容易に判別することができる。
【符号の説明】
【００８２】
１００：ユーザ計算機
１０１：管理サーバ
１０２：サーバ
１０３：ネットワーク機器
１０４：ストレージ装置
１０５：実行基盤ソフトウェア
１０６：アプリケーションプログラム
【図１】
2017134758.tif 000003
【図２】
2017134758.tif 000004
【図３】
2017134758.tif 000005
【図４】
2017134758.tif 000006
【図５】
2017134758.tif 000007
【図６】
2017134758.tif 000008
【図７】
2017134758.tif 000009
【図８】
2017134758.tif 000010
【図９】
2017134758.tif 000011
【図１０】
2017134758.tif 000012
【図１１】
2017134758.tif 000013
【図１２】
2017134758.tif 000014
【図１３】
2017134758.tif 000015
【図１４】
2017134758.tif 000016
【図１５】
2017134758.tif 000017
【図１６】
2017134758.tif 000018
【国際調査報告】
2017134758.tif 000019
2017134758.tif 000020
2017134758.tif 000021
2017134758.tif 000022