JP2007207117A

JP2007207117A - 性能監視装置、性能監視方法及びプログラム

Info

Publication number: JP2007207117A
Application number: JP2006027622A
Authority: JP
Inventors: Yoshifumi Sakai; 良文坂井; Yoshitaka Ikeda; 佳隆池田; Tomokazu Shindo; 朋和進藤; Yuichi Yokoyama; 雄一横山
Original assignee: NS Solutions Corp
Current assignee: NS Solutions Corp
Priority date: 2006-02-03
Filing date: 2006-02-03
Publication date: 2007-08-16
Anticipated expiration: 2026-02-03
Also published as: JP4705484B2

Abstract

【課題】様々な形態で発生する事象に対して、最も的確な対策を選択・策定することを可能とする。
【解決手段】モニタ部１０１は、ＡＣ環境及び非ＡＣ環境の状態に係る状態情報を取得し、分析部１０３又はモデル診断部１０６は、取得された状態情報に基づいて、ＡＣ環境の装置の状態を判定する。シミュレーション部１０８は、その判定結果に対応する対策リストを参照し、対策リストに含まれる少なくとも一つの対策夫々によるシミュレーション処理を実行し、各対策の効果を評価する。
【選択図】図１

Description

本発明は、例えば、対象となる外部装置の状態をコンピュータが管理する所謂自律型コンピューティングに適用可能な性能監視装置、性能監視方法及びプログラムに関するものである。

人間によるコンピュータ管理の負荷を軽減するためにコンピュータが自ら管理する仕組み、所謂自律型コンピューティングが実現しつつある。自律型コンピューティングでは、コンピュータは所定の運用指針に基づいて、自律的に自己の障害を修復する（例えば、非特許文献１参照）。この自己管理は、以下のような手順を繰り返すことで実現されている。
（１）先ず、コンピュータシステムを監視してハードウェア、ソフトウェアの挙動をログデータとして集約
（２）集約したものを分析して状況を把握
（３）目的達成のための対策を立てる
（４）計画を実行・制御する

例えば、ＣＰＵの利用率を監視し（１）、利用率が急激に高まったときに（２）、他のリソースに負荷分散するという対策を立て（３）、実際に一部の処理を他のマシンに振り分ける（４）という処理をコンピュータが自律的に実行する。

ところで、今日提案されている自律型コンピューティングの技術では上記（１）〜（４）のサイクルで運用されるが、（３）のプランニングの処理は元々人間が設定した運用指針に沿うように仕向けられている。従って、自律型コンピューティングを実装する上で設計者は予想でき得る事象について様々な運用指針を用意しておく。コンピュータは当初設定した運用指針を守って動作し続けることができるかどうかを判断して必要なアクションを起こすようになっている。また、以後本文中の前記自律型コンピューティングを、非特許文献１中のオートノミック・コンピューティング（ＡＣ）と同義として説明する。

「オートノミック・コンピューティングアーキテクチャに関するブループリント」、インターネット＜URL:http://www-6.ibm.com/jp/autonomic/pdf/acbp2_2005-06_v7.pdf＞

しかしながら、コンピュータシステムでは日常的に発生しうる事象、例えば負荷が高まったりすることは想定しやすいが、システム構成が途中から変更されたり、人為的ミスによる障害など予想しがたい事象が発生することがある。また、現時点で問題が発生していなくとも、将来発生しうる問題の兆候が潜んでいることもある。そもそも、当初設定したポリシーが間違っているということも無いわけではない。

このように、運用指針が適用しづらい事象が発生したり、現時点で異常が表れていないので通常の運用指針に基づいた運用が行われたり、本当は変更した方が良い運用指針が潜在したまま運用を続けると、間違えた運用指針に基づいてコンピュータが自律的制御を行ってしまうなど、オートノミック・コンピューティング本来の目的である"自律的に最適な処理を行うことで、人間が介在せずに変化に対応する"ことが達成できなくなってしまう。

そこで、本発明の目的は、様々な形態で発生する、又は、将来発生しうる事象に対して、最も的確な対策を選択・策定することを可能とすることにある。

本発明の性能監視装置は、少なくとも一つの外部装置と通信回線を介して接続される性能監視装置であって、前記外部装置の状態に係る状態情報を取得する取得手段と、前記取得手段により取得される前記状態情報に基づいて、前記外部装置の状態を判定する判定手段と、前記判定手段による判定結果に対応する対策リストを参照し、前記対策リストに含まれる少なくとも一つの対策情報夫々による前記外部装置の状態に係るシミュレーション処理を実行し、前記各対策情報により示される対策の効果を評価するシミュレーション手段とを有することを特徴とする。
本発明の性能監視方法は、少なくとも一つの外部装置と通信回線を介して接続される性能監視装置による性能監視方法であって、前記外部装置の状態に係る状態情報を取得する取得ステップと、前記取得ステップにより取得される前記状態情報に基づいて、前記外部装置の状態を判定する判定ステップと、前記判定ステップによる判定結果に対応する対策リストを参照し、前記対策リストに含まれる少なくとも一つの対策情報夫々による前記外部装置の状態に係るシミュレーション処理を実行し、前記各対策情報により示される対策の効果を評価するシミュレーションステップとを含むことを特徴とする。
本発明のプログラムは、前記性能監視方法をコンピュータに実行させることを特徴とする。

本発明においては、外部装置の状態情報、又は後述する状態情報により作成したモデルに基づいて、外部装置の現在・将来の状態を分析・診断（判定）し、その判定結果に対応する対策リストに含まれる各対策によるシミュレーション処理を行って、対策リストに含まれる各対策情報に示される対策の効果を評価するように構成している。即ち、本発明は、外部装置が様々な事象の状態に陥っても、その状態に対応する対策リストによるシミュレーションを行って各対策の効果を評価することができる。
従って、本発明によれば、その評価結果に基づいて、様々な形態で発生する外部装置の事象に対して、最も的確な対策を選択・策定することが可能となる。

先ず、本発明の実施形態について説明する前に、以下の説明で用いる文言の定義を行う。
「ポリシー」とは、後述するオートノミック・コンピューティング環境（以下ＡＣ環境とする）の運用に関する指針である。ポリシーの一例としては、「ＣＰＵ使用率が０〜１０％であれば余剰である、ＣＰＵ使用率が１１〜８０％であれば正常である、ＣＰＵ使用率が８１％以上であれば過負荷である」、「ＣＰＵ使用率が過負荷の場合は、シミュレーションを実行して最適な結果を残した対策を選択する」、「システムの応答がない場合は、即座に再起動する」等が挙げられる。
「対策リスト」とは、ＡＣ環境内の装置に生じ得る各事象に紐つけられる対策の集合であり、事象と対策とはｍ：ｎで対応付けられている。なお、ｍ＝ｎであってもよく、ｍ≠ｎであってもよい。対策リストの一例としては、「ＣＰＵ使用率が閾値を超えている」という事象に対して「対策１．ＣＰＵを１つ追加、対策２．ＣＰＵを２つ追加、対策３.サーバ追加による負荷分散」で構成された対策リスト等が挙げられる。
「モデル」とは、ＡＣ環境及び後述する非ＡＣ環境から取得する監視データに基づいて、ＡＣ環境内の各装置について特徴を抽出したものである。その一例として、ＡＣ環境内におけるＡＰサーバからＣＰＵ使用率を示す監視データを取得した場合には、その線形近似式を求めることによってＣＰＵ使用率の時系列変化を表す以下のモデルが抽出できる。
ｆ（ｔ）＝ａｔ＋ｂ
ｆ（ｔ）：ＣＰＵ使用率、ｔ：時間、ａ，ｂ：実値

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

図１は、本発明の実施形態に係るＡＣ性能監視装置１００の機能的な構成を示すブロック図である。図１に示すように、本実施形態に係るＡＣ性能監視装置１００は、サーバ類１００１、ストレージ類１００２及びネットワーク（ＮＷ）装置類１００３等から構成される情報処理システムであるＡＣ環境、及び、非ＡＣ環境とＬＡＮ（Local Area Network）等の通信回線で接続され、この通信回線を介して各装置の状態を監視することが可能である。

なお、ＡＣ環境とは、本実施形態におけるオートノミック・コンピューティングの技術を適用する環境であり、図１の例では、サーバ類１００１、ストレージ類１００２及びネットワーク装置類１００３である。これに対し、非ＡＣ環境とは、本実施形態におけるオートノミック・コンピューティングの技術の適用外となる環境であり、この非ＡＣ環境から取得される監視データはＡＣ環境に対するオートノミック・コンピューティングに利用することも可能である。

また、上述したサーバ類１００１とは、ＷｅｂサーバやＡＰサーバ等の各種サーバのことであり、ストレージ類１００２とは、ＤＢ等の情報を記録可能な装置類である。ネットワーク装置類１００３とは、サーバ類１００１及びストレージ類１００２の各装置間を接続するＬＡＮ等の通信ネットワークである。

モニタ部１０１は、ＡＣ環境及び非ＡＣ環境の各装置の状態を示す以下の監視データを取得する。ＡＣ環境のＷｅｂサーバ、ＡＰサーバ及びＤＢサーバからは、監視データとして、メモリの使用量を示すデータ及びＣＰＵの使用率を示すデータ等のリソース使用状況データ、ＡＣ環境の各装置の処理履歴を示すログデータ等を取得する。また、モニタ部１０１は、ＡＣ環境におけるＷｅｂサーバ、ＡＰサーバ及びＤＢサーバ間を接続する各通信回線（ネットワーク装置）からは、監視データとして、それらの通信回線で通信されるトランザクションのスループット、処理名等を示すトランザクションデータを取得する。モニタ部１０１は、取得した監視データを標準的なフォーマットに変換して後述するイベント情報蓄積部１０２に蓄積する。標準フォーマットへの変換は、必ずしも必要とはならないが、多種多様な情報を効率的に分析・診断（判定）するために行っている。以下では代表的な標準フォーマットであるＣＢＥ(Common Base Event)を用いた実施形態のみについて説明するが、処理を行う為の標準化に用いるフォーマットであればＣＢＥに限定する必要が無い事は言うまでも無い。

さらに、モニタ部１０１は、非ＡＣ環境からも監視データを取得する。非ＡＣ環境の装置から取得する監視データとしては、例えば、ＡＣ環境に対してアクセスを行う非ＡＣ環境の装置を監視し、ＡＣ装置の各装置に対して行われるアクセス数を監視データとして取得したり、ＡＣ環境内の温度を計測する非ＡＣ環境内の装置である温度計から温度データを監視データとして取得することが挙げられる。その他にも、ＡＣ環境内の装置に対するアクセス数が急激増加することが予測される時期情報を非ＡＣ環境内の装置から監視データとして取得することもできる。以下では、ＡＣ環境から取得する監視データのみを用いたオートノミック・コンピューティングについて説明するが、これらの非ＡＣ環境から取得できる監視データを更に加味することによってより精度の高いオートノミック・コンピューティングを実現することが可能となる。

分析部１０３は、モニタ部１０１が変換したＣＢＥデータに問題がないかを、知識情報蓄積部１０４から読み込んだポリシー１０４１に基づいて分析する。例えば、ＣＢＥデータによって示されるＣＰＵの使用率が８０％を越えている場合、ポリシー１０４１に基づいて、ＣＰＵ使用率が過負荷な状態であるという事象が分析される。ポリシー１０４１の一例を上記の説明で挙げたが、例えば上記のようにＣＰＵ使用率に関して分析する場合、分析対象となるＣＢＥデータが示す数値に一番近いポリシー、「ＣＰＵの使用率が閾値の８０％を越えたら過負荷な状態である」旨のポリシー１０４１が知識情報蓄積部１０４から読み込まれる。

また例えば、分析対象となるＣＢＥデータがメモリの使用量であり、ＣＢＥデータが９０％を示す場合、この分析対象に一番近いデータに該当するポリシー「メモリに使用率が閾値の８５％を越えるとメモリが過度に消費された状態にある」旨のポリシー１０４１が知識情報蓄積部１０４から読み込まれ、この場合ＣＢＥデータによって示されるメモリの使用率が８５％を越えている為、メモリが過度に消費された状態であるという事象が分析される。

また例えば、分析対象となるＣＢＥデータがスループットを示すトランザクションデータであり、ＣＢＥデータが１２０トランザクション/秒を示す場合、この分析対象に一番近いデータに該当するポリシー「スループットが１００トランザクション/秒未満であればサービスレベルが所定の範囲に収まる、スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲内に収まらない」旨のポリシー１０４１が読み込まれ、この場合ＣＢＥデータによって示されるスループットが１００トランザクション/秒を越えている為、システムが過負荷な状態であるという事象が分析される。

イベント情報蓄積部１０２は、モニタ部１０１によって変換されたＣＢＥデータを蓄積する。また、イベント情報蓄積部１０２は、蓄積したＣＢＥデータに対して定期的に統計処理を行って蓄積するＣＢＥデータ量を削減する。統計処理の例としては、一定期間中に蓄積したＣＢＥデータの最大／最小値を求める方法や、一定期間中に蓄積したＣＢＥデータの平均値を求める方法等が挙げられる。

イベント情報蓄積部１０２に蓄積される情報としては、上述したリソース使用情報データ、ログデータ及びトランザクションデータ等の他、構成情報が蓄積される。構成情報とは、監視対象としたい情報処理システムの構成を示す情報（例えば、監視対象の情報処理システムは６台のＷｅｂサーバと２台のＡＰサーバと１台のＤＢサーバから構成される等）、情報処理システムを構成する各装置間がどのように接続され、そして、各装置間を接続するためのネットワークはどれほどの転送レートを持ったものであるかを示す情報、各装置内のハードウェア及びソフトウェアのスペックを示す情報等が含まれる。各ハードウェア及びソフトウェアのスペックとしては、単に購入時のスペックだけでなく、ファームウェアやソフトウェアのバージョン等も登録しておくとよい。なお、蓄積される構成情報は例えばオペレータ等によって入力される方法のみならず、ネットワークを介してＡＣ性能監視装置１００が取得して入力するようにしてもよい。

モデル抽出部１０５は、イベント情報蓄積部１０２に蓄積されたＣＢＥデータに基づいて、該当するＡＣ環境の装置のモデル１０４２を抽出する。例えば、モデル抽出部１０５はＡＣ環境における或る装置のＣＰＵ使用率を示すＣＢＥデータを逐次取得し、それを線形近似することによってＣＰＵ使用率の時系列変化を表すモデル１０４２を抽出することができる。

また、モデル抽出部１０５はＡＣ環境における或る装置のスループットを示すＣＢＥデータを逐次取得し、それを線形近似することによってスループットの時系列変化を表すモデル１０４２を抽出することができる。

さらに、モデル抽出部１０５は、上記のように、ＣＰＵ使用率及びスループットの時系列変化を線形近似したモデル１０４２を抽出した場合には、それらのモデル１０４２からＣＰＵ使用率とスループットとの相関関係を示すモデル１０４２を抽出することもできる。このようなモデル１０４２の抽出方法については後に詳述する。抽出した各モデル１０４２は、知識情報蓄積部１０４に蓄積する。

モデル診断部１０６は、知識情報蓄積部１０４に蓄積されるモデル１０４２と当該モデル１０４２に該当するポリシー１０４１とを参照し、ポリシー１０４１に基づいてモデル１０４２の診断を行う。

例えば、参照したモデル１０４２がＣＰＵ使用率の時系列変化を表すモデルであれば、当該モデル１０４２に該当するポリシー１０４１として、「ＣＰＵ使用率が０〜１０％であれば余剰である、ＣＰＵ使用率が１１〜８０％であれば正常である、ＣＰＵ使用率が８１％以上であれば過負荷である」というポリシー１０４１が参照される。将来の或る時点における予測値が所定の閾値を越えると予測される場合には、ＣＰＵ使用率に関して将来問題が生じる可能性があるという事象が診断される。

図６を用いて問題の事象がモデル診断部１０６によって診断される例を具体的に説明する。ＣＰＵ使用率の時系列変化を表すモデルがｆ_a（ｘ）＝αｘ＋βであり、そのモデルに紐付けられるポリシーが「ＣＰＵ使用率が０〜１０％であれば余剰である、ＣＰＵ使用率が１１〜８０％であれば正常である、ＣＰＵ使用率が８１％以上であれば過負荷である」である場合、図６に示すように、１カ月後におけるＣＰＵ使用率ｆ_a（ｘ）の値は８０％を越えている。このような場合、モデル診断部１０６は、１カ月後にはＣＰＵ使用率が過負荷の為、問題が生じる可能性があると診断する。

また、参照したモデル１０４２がスループットの時系列変化を表すモデルであれば、当該モデル１０４２に該当するポリシー１０４１として、「スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲に収まる、スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲内に収まらない」というポリシー１０４２が参照される。将来の或る時点における予測値が所定の閾値を越えると予測される場合には、スループットに関して将来問題が生じる可能性があるという事象が診断される。

図７を用いて問題の事象がモデル診断部１０６によって診断される他の例を具体的に説明すると、処理Ａ及び処理Ｂのスループットの時系列変化を表すモデルが夫々、ｆ_A（ｘ）＝α₁ｘ＋β₁、ｆ_B（ｘ）＝α₂ｘ＋β₂であり、それらのモデルに紐付けられるポリシーが「スループットが１００トランザクション/秒未満であればサービスレベルが所定の範囲に収まる、スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲内に収まらない」である場合、図７に示すように、１カ月後における処理Ａのスループットｆ_A（ｘ）の値は１００トランザクション/秒を越えている。このような場合、モデル診断部１０６は、１カ月後には処理Ａのスループットに問題が生じる可能性があると診断する。一方、１カ月後までの処理Ｂのスループットｆ_B（ｘ）の値は１００トランザクション/秒を下回っているため、１カ月後までに処理Ｂのスループットに問題が生じる可能性があると診断されない。

さらに、参照したモデル１０４２がＣＰＵ使用率とスループットとの相関関係を示すモデルであれば、当該モデル１０４２に該当するポリシー１０４１として、「ＣＰＵ使用率とスループットとの相関関係が前後１日において誤差１０％以内に収めるべきである」というポリシー１０４１が参照される。将来の或る時点におけるＣＰＵ使用率とスループットとの相関関係が所定の均衡を保てていないことが予測される場合には、それらの相関関係に将来問題が生じる可能性があるという事象が分析される。

図８を用いて問題の事象がモデル診断部１０６によって診断される更に他の例を具体的に説明すると、処理ａのＣＰＵ使用率とスループットとの相関関係を示すモデルが夫々、ｆ_TA（ｘ）＝ρ₁ｘ＋θ₁、ｆ_TB（ｘ）＝ρ₂ｘ＋θ₂であり、ｆ_TA（ｘ）は2006/01/01のデータを、ｆ_TB（ｘ）は2006/01/02のデータに基づいて作成したモデルである。それらのモデルに紐付けられるポリシーが「ＣＰＵ使用率とスループットとの相関関係が前後１日において誤差１０％以内に収めるべきである」である場合、図８に示すように、ｆ_TA（ｘ₁）とｆ_TB（ｘ₁）の間に１０％以上の誤差があれば、ＣＰＵ使用率とスループットとのバランスが崩れてシステムが異常な状態にあると診断する。

計画部１０７は、分析部１０３によるＣＢＥデータに対する分析の結果、問題があると分析された事象、又は、モデル診断部１０６により将来問題が生じる可能性があると診断された事象に紐付けられた対策リスト１０４３を知識情報蓄積部１０４から選択し、その対策リスト１０４３に含まれる各対策によるシミュレーション処理を後述のシミュレーション部１０８に対して依頼する。

例えば、対象となる事象が「１カ月後におけるＣＰＵ使用率が８０％を越える」ような事象の場合、その事象に紐付けられる対策リスト１０４３の例として以下の（１）〜（６）に示すような対策リスト１０４３が挙げられる。
（１）ＣＰＵを１つ追加
（２）ＣＰＵを２つ追加
（３）サーバ追加による負荷分散（処理分散パターンＡ）
（４）サーバ追加による負荷分散（処理分散パターンＢ）
（５）サーバ追加による負荷分散（処理分散パターンＣ）
（６）サーバ追加による負荷分散（処理分散パターンＤ）

なお、図５（ａ）に示すように、処理分散パターンＡとは、本来、２種類の処理Ａと処理Ｂとを１つのサーバで処理していたが、そのサーバと追加したサーバとで処理Ａと処理Ｂとを一つずつ分散させて処理させる処理分散パターンである。

処理分散パターンＢとは、図５（ｂ）に示すように、本来、２種類の処理Ａと処理Ｂとを１つのサーバで処理していたが、そのサーバには同様に処理Ａと処理Ｂとを実行させるとともに、追加サーバにも処理Ａを実行させ、元々処理させていたサーバの処理Ａに関する処理負担を軽減する処理分散パターンである。

処理分散パターンＣとは、図５（ｃ）に示すように、本来、２種類の処理Ａと処理Ｂとを１つのサーバで処理していたが、そのサーバには同様に処理Ａと処理Ｂとを実行させるとともに、追加サーバにも処理Ｂを実行させ、元々処理させていたサーバの処理Ｂに関する処理負担を軽減する処理分散パターンである。

処理分散パターンＤとは、図５（ｄ）に示すように、本来、２種類の処理Ａと処理Ｂとを１つのサーバで処理していたが、そのサーバには同様に処理Ａと処理Ｂとを実行させるとともに、追加サーバにも処理Ａと処理Ｂとの両方を実行させ、元々処理させていたサーバの処理Ａ及び処理Ｂに関する処理負担を軽減する処理分散パターンである。

シミュレーション部１０８は、計画部１０７によって選択された対策リスト１０４３を知識情報蓄積部１０４から参照し、その対策リスト１０４３によるシミュレーション処理を実行する。

なお、シミュレーション部１０８は、装置（又は、複数の装置から成るシステム）の構成変更の効果を定量化するためのシミュレータと呼ばれるツールによって構成することができる。シミュレータは、装置（又はシステム）構成や処理の特徴が入力されることによって性能値を予測することができる。ここで、装置（又はシステム）構成として入力される情報としては、例えば、サーバ数、ＣＰＵ数等が挙げられる。処理の特徴として入力される情報としては、例えば、各処理のＣＰＵにおける処理時間、各処理の発生頻度等が挙げられる。性能値として予測される情報としては、ＣＰＵ使用率、各処理に対する応答時間等が挙げられる。これらの入力データは、知識情報蓄積部１０４から読み出したモデルに基づいて算出して得られる情報であるため、モデルをパラメータとしてシミュレータに与えてもよい。

例えば、対象となる事象が上述した「１カ月後におけるＣＰＵ使用率が８０％を越える」ような事象の場合、上記の（１）〜（６）の対策を含む対策リスト１０４３についてシミュレーション処理が実行され、以下のように各対策を実施した際の効果が定量化される。
対策（１）の結果：ＣＰＵ使用率８５％
対策（２）の結果：ＣＰＵ使用率なし（実現不可能な構成と判断されたため）
対策（３）の結果：ＣＰＵ使用率４０％
対策（４）の結果：ＣＰＵ使用率５５％
対策（５）の結果：ＣＰＵ使用率５５％
対策（６）の結果：ＣＰＵ使用率６５％

また、対象となる事象が、例えば分析部１０３によって現在のＣＰＵ使用率が既に８０％を越えていると分析されたような事象であれば、同じく、その事象に対応する対策リスト１０４３が参照され、シミュレーション処理によって当該対策リスト１０４３内の対策毎に効果が定量化されることになる。

計画部１０７は、当該事象に該当するポリシー１０４１を知識情報蓄積部１０４から参照し、シミュレーション部１０８によるシミュレーション処理の評価結果のうちポリシー１０４１を満たす結果を導いた対策を決定する。例えば、当該事象に該当するポリシー１０４１が「ＣＰＵ使用率が過負荷の場合は、シミュレーションを実行して最適な結果を残した対策を選択する」というポリシー１０４１であれば、上記の例の場合、対策（３）が決定されることになる。計画部１０７は、このように対策を決定すると、例えば、対策（３）を１週間後に実行する等、対策の実行をスケジューリングする。

計画実行部１０９は、計画部１０７によって作成されたスケジュールに従って対策を実行する。

対策探索部１１０は、シミュレーション部１０８によるシミュレーション処理の全ての結果が、当該事象に該当するポリシー１０４１を満たさない場合、知識情報蓄積部１０４に蓄積される対策のうち当該事象に紐付けられていない対策を選択し、選択された対策によるシミュレーション処理をシミュレーション部１０８に対して依頼する。シミュレーション部１０８は、選択された対策を知識情報蓄積部１０４から参照し、各対策についてシミュレーション処理を実行し、各対策を実施した際の効果を定量化する。

対策探索部１１０は、このように当該事象に紐付けられていない対策に対するシミュレーション処理の結果のうち、上記ポリシー１０４１を満たす結果を導いた対策が存在する場合、知識情報蓄積部１０４内においてその対策を当該事象に紐付けられた対策リスト１０４３に追加させるとともに、上記ポリシー１０４１を満たす結果に対応する対策を計画部１０７に渡す。

このように対策探索部１１０によってポリシーを満たす対策が発見され、対策探索部１１０によって当該対策が渡された場合、計画部１０７は、同様に当該対策の実行をスケジューリングする。

図２は、ＡＣ性能監視装置１００のハードウェア構成を示すブロック図である。ＣＰＵ２０１は、システムバスに接続される各デバイスやコントローラを統括的に制御する。ＲＯＭ２０３又はＨＤ２０７には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Basic Input/Output System）やオペレーティングシステムプログラムや、ＡＣ性能監視装置１００が実行する例えば図３−１及び図３−２に示す処理のプログラム等が記憶されている。

なお、図２の例では、ハードディスク（ＨＤ）２０７はＡＣ性能監視装置１００の内部に配置された構成としているが、他の実施形態としてＨＤ２０７に相当する構成がＡＣ性能監視装置外部に配置された構成としてもよい。また、本実施形態に係る例えば図３−１及び図３−２に示す処理を行なうためのプログラムは、フレキシブルディスク（ＦＤ）２０６やＣＤ−ＲＯＭ等、コンピュータ読み取り可能な記録媒体に記録され、それらの記録媒体から供給される構成としてもよいし、インターネット等の通信媒体を介して供給される構成としてもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０２にロードして、プログラムを実行することで各種動作を実現するものである。

ディスクコントローラ２０５は、ＨＤ２０７やＦＤ２０６等の外部メモリへのアクセスを制御する。通信ＩＦコントローラ２０４は、インターネットやＬＡＮと接続し、例えばＴＣＰ／ＩＰによって外部との通信を制御するものである。

ディスプレイコントローラ２０８は、ディスプレイ２０９における画像表示を制御する。

ＫＢ（キーボード）コントローラ２１０は、キーボード（ＫＢ）２１１からの操作入力を受け付け、ＣＰＵ２０１に対して送信する。なお、図示していないが、キーボード２１１の他に、マウス等のポインティングデバイスもユーザの操作手段として本実施形態に係るＡＣ性能監視装置１００に適用可能である。

モニタ部１０１、分析部１０３、モデル抽出部１０５、モデル診断部１０６、計画部１０７、シミュレーション部１０８、計画実行部１０７及び対策探索部１１０は、例えばＨＤ２０７内に記憶され、必要に応じてＲＡＭ２０２にロードされるプログラム及びそれを実行するＣＰＵ２０１に相当する構成である。

また、知識情報蓄積部１０４及びイベント情報蓄積部１０２は、例えばＨＤ２０７又はＲＡＭ２０２内の一部記憶領域に相当する構成である。なお、知識情報蓄積部１０４及びイベント情報蓄積部１０２は、ＡＣ性能監視装置１００内部に備える構成の他、外部に備えた構成としてもよい。

次に、本実施形態に係るＡＣ性能監視装置１００の動作を、図３−１、図３−２、図１０及び図１１のフローチャートを参照しながら説明する。

先ず、図１０を用いてモニタ部１０１による監視データの取得処理からイベント情報蓄積部１０２へのＣＢＥデータの蓄積処理について説明する。図１０において、モニタ部１０１は、ＡＣ環境及び非ＡＣ環境の各装置から監視データを取得し、取得した監視データをＣＢＥデータに変換する（ステップＳ１００１、Ｓ１００２）。次に、モニタ部１０１は、当該ＣＢＥデータをイベント情報蓄積部１０２に蓄積させる（ステップＳ１００３）。このようにモニタ部１０１は、ステップＳ１００１〜ステップＳ１００３の処理を繰り返し実行してＣＢＥデータをイベント情報蓄積部１０２に対して蓄積していく。なお、イベント情報蓄積部１０２内では、例えば所定期間毎に、蓄積されるＣＢＥデータの最大／最小値や平均値等を算出し、その値のみを保持するようにすることで蓄積するデータ量の削減が図られる。

次に、図３−１及び図３−２を用いて、イベント情報蓄積部１０２に蓄積されたＣＢＥデータに基づくモデルによってＡＣ環境の診断処理を行い、診断結果に問題がある場合には対策を実行するまでの処理について説明する。図３−１において、モデル抽出部１０５は、ＡＣ環境及び非ＡＣ環境の各装置に対応するＣＢＥデータをイベント情報蓄積部１０２から取得し、モデル１０４２を抽出する（ステップＳ３０１、Ｓ３０２）。

ここで、モデル１０４２の抽出方法を、図４を参照しながら具体的に説明する。
先ず、図４（ａ）において、前回モデル１０４２を抽出した時点（時間２）から所定時間が経過し、モデル抽出部１０５は、時間１及び時間２の監視データとともに、新たに時間３の監視データを今回取得する。ここで取得する監視データは、図４（ａ）に示すように、ＣＰＵ使用率を示す監視データとスループットを示す監視データとであるものとする。

次に、モデル抽出部１０５は、時間に対するＣＰＵの使用率の関係を表す座標系において、時間１〜時間３の監視データをプロットし、プロットした各監視データの線形近似式（ｆ_a（ｘ）＝αｘ＋β）を求めることによって、ＣＰＵ使用率の時系的変化を表すモデル１０４２を抽出する。モデル抽出部１０５は、抽出したモデル１０４２を知識情報蓄積部１０４に対して蓄積する。

また、モデル抽出部１０５は、図４（ｂ）に示すように、時間に対するスループットの関係を表す座標系において、処理Ａ及び処理Ｂ夫々に関するスループットを示す時間１〜時間３の監視データをプロットし、処理Ａと処理Ｂとの夫々について各監視データの線形近似式（ｆ_A（ｘ）＝α₁ｘ＋β₁、ｆ_B（ｘ）＝α₂ｘ＋β₂）を求めることによって、スループットの時系的変化を表すモデル１０４２を抽出する。モデル抽出部１０５は、抽出したモデル１０４２を知識情報蓄積部１０４に対して蓄積する。

次に、モデル抽出部１０５は、これらの２つのモデル１０４２に対して相関分析及び多変量解析を行うことで、図４（ｃ）に示すように、処理Ａと処理Ｂとの夫々について、ＣＰＵ使用率とスループットとの相関を表す線形近似式（ｆ_TA（ｘ）＝ρ₁ｘ＋θ₁、ｆ_TB（ｘ）＝ρ₂ｘ＋θ₂）を求め、ＣＰＵ使用率とスループットとの相関を示すモデル１０４２を抽出する（ステップＳ３０３）。モデル抽出部１０５は、抽出したモデル１０４２を知識情報蓄積部１０４に対して蓄積する。

続いて、モデル診断部１０６は、知識情報蓄積部１０４に蓄積される複数のモデル１０４２と各モデル１０４２に該当するポリシー１０４１を夫々参照し、各モデル１０４２に対して該当するポリシー１０４１に基づく診断を実行する（ステップＳ３０４）。例えば、ＣＰＵ使用率の時系列変化を表すモデル１０４２に対しては、「ＣＰＵ使用率が０〜１０％であれば余剰である、ＣＰＵ使用率が１１〜８０％であれば正常である、ＣＰＵ使用率が８１％以上であれば過負荷である」というポリシー１０４１が適用される。そして、今回抽出したモデル１０４２から将来のＣＰＵ使用率を予測することもできる。今回抽出したモデル１０４２の傾向でＣＰＵ使用率が増加していき、例えば１カ月後のＣＰＵ使用率が８０％を越えることが予測される場合には、ＣＰＵ使用率に将来（１カ月後）に問題が生じる可能性があると診断する。

また、例えば、スループットの時系列変化を表すモデル１０４２に対しては、「スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲に収まる、スループットが１００トランザクション/秒以上であればサービスレベルが所定の範囲内に収まらない」というポリシー１０４１が適用される。同じく今回抽出したモデル１０４２からスループットを予測することもできる。今回抽出したモデル１０４２の傾向でスループットが増加していき、例えば３週間後にスループットが１００トランザクション/秒を越えることが予測される場合には、スループットに将来（３週間後）に問題が生じる可能性があると診断する。

また、例えば、ＣＰＵ使用率とスループットとの相関を表すモデル１０４２に対しては、「ＣＰＵ使用率とスループットとの相関関係が前後１日において誤差１０％以内に収めるべきである」というポリシー１０４１が適用される。このモデル１０４２からはＣＰＵ使用率に対するスループットの傾向を判定することができるため、例えば、上記ポリシー１４０１に基づきＣＰＵ使用率に対してスループットが１年前と比較して１０％以上低い（又は、高い）と判定される場合には、問題があると診断される。

なお、ここでは、ＣＰＵ使用率の時系的変化を示すモデル１０４２とスループットの時系的変化を示すモデル１０４２とを抽出した後、ＣＰＵ使用率とスループットとの相関を示すモデル１０４２を抽出する流れのみについて説明しているが、ＣＰＵ使用率の時系列変化を示すモデル１０４２、スループットの時系的変化を示すモデル１０４２、ＣＰＵ使用率とスループットとの相関を示すモデル１０４２の抽出処理は夫々独立して行なうことができる。つまり、本実施形態におけるモデル抽出処理は、図３−１に示す流れには限られず、それぞれのモデルの抽出処理は任意のタイミングで行なわれる。また、ＣＰＵ使用率の時系列変化を示すモデル１０４２、スループットの時系的変化を示すモデル１０４２及びＣＰＵ使用率とスループットとの相関を示すモデル１０４２の全てを抽出せずに、そのうちの一部のモデルを抽出することもできる。即ち、ＣＰＵ使用率とスループットとの相関を示すモデル１０４２は抽出せずにＣＰＵ使用率の時系列変化を示すモデル１０４２及びスループットの時系的変化を示すモデル１０４２の２つのモデルだけを抽出することもできるし、ＣＰＵ使用率の時系列変化を示すモデル１０４２とスループットの時系的変化を示すモデル１０４２との何れか一方の１つのモデルのみを抽出することもできる。

続いて、計画部１０７は、モデル診断部１０６によりモデル１０４２に問題があると診断された場合、知識情報蓄積部１０４においてその問題の事象に紐付けられる対策リスト１０４３を選択する（ステップＳ３０５／ＹＥＳ、Ｓ３０６）。例えば、対象となる事象が１カ月後におけるＣＰＵ使用率が８０％を超過するという事象の場合、上述した（１）〜（６）の対策を含む対策リスト１０４３が選択されることになる。

ここで、計画部１０７は、当該ポリシー１０４１に基づいてシミュレーション部１０８にシミュレーション処理を依頼するか否かを判断する（ステップＳ３０７）。例えば、当該ポリシー１０４１が「システムの応答がない場合は、即座に再起動する」である場合には、シミュレーション部１０８に対してシミュレーション処理を依頼せず、即座に対策の実行をスケジューリングする（ステップＳ３０７／ＮＯ、Ｓ３１２）。また、対象となる事象が緊急の対処を要するものであるとして予めポリシー１０４１において定められている場合には、その問題がある事象の内容と当該事象に紐付けられている対策リスト１０４３をユーザに対して報知してもよい。これによって、ユーザは報知された対策リスト１０４３のうちから所望の対策を選択し、対策の実行を行うことができる。

一方、例えば、当該ポリシー１０４１が「ＣＰＵ使用率が過負荷の場合は、シミュレーションを実行して最適な結果を残した対策を選択する」である場合、計画部１０７は、対策リスト１０４３に含まれる各対策のシミュレーション処理をシミュレーション部１０８に対して依頼する（ステップＳ３０７／ＹＥＳ、Ｓ３０８）。シミュレーション部１０８は、計画部１０７によって選択された対策リスト１０４３を参照し、その対策リスト１０４３に含まれる各対策のシミュレーション処理を実行する（ステップＳ３０９）。

続いて、計画部１０７は、当該事象に該当するポリシー１０４１を知識情報蓄積部１０４から参照し、シミュレーション部１０８によるシミュレーション処理の結果のうち、参照したポリシー１０４１を満たす結果を導いた対策が存在するか否かを判定する（ステップＳ３１０）。

ポリシー１０４１を満たす結果を導いた対策が一つのみ存在する場合、計画部１０７は、その対策の実行を決定し、当該対策の実行をスケジューリングする（ステップＳ３１０／ＹＥＳ、Ｓ３１１、Ｓ３１２）。また、ポリシー１０４１を満たす結果を導いた対策が複数存在する場合には、計画部１０７は、ポリシー１０４１「ＣＰＵ使用率が過負荷の場合は、シミュレーションを実行して最適な結果を残した対策を選択する」に基づいてその複数の対策のうち最適な結果を導いた対策の実行を決定し、当該対策の実行をスケジューリングする（ステップＳ３１０／ＹＥＳ、Ｓ３１１、Ｓ３１２）。

計画実行部１０９は、計画部１０７によって作成されたスケジュールに従って対策を実行する（ステップＳ３１３）。計画部１０７によって例えば「１カ月後に１つＣＰＵを追加する」という対策のスケジュールが作成された場合、計画実行部１０９は、計画部１０７によって上記計画が作成された日から１カ月後に対象となるＡＣ環境の装置に対してＣＰＵを１つ追加するように制御する。

一方、シミュレーション部１０８によるシミュレーション処理の結果のうち、ポリシー１０４１を満たす結果を導いた対策が存在しないと判定された場合（当該事象に紐つけられる対策リスト１０４３にポリシー１０４１を満たす結果を導く対策が含まれない場合）、対策探索部１１０は、当該対策リスト１０４３以外の対策を知識情報蓄積部１０４から参照し、参照した対策に対するシミュレーション処理をシミュレーション処理部１０８に順次依頼する（ステップＳ３１０／ＮＯ、Ｓ３１４）。

シミュレーション処理部１０８は、対策探索部１１０によって依頼された対策のシミュレーション処理を実行する（ステップＳ３１５）。

続いて、対策探索部１１０は、当該対策リスト１０４３以外の対策の全てについてのシミュレーション処理を依頼すると、シミュレーション部１０８による各対策に対するシミュレーション処理の結果と上記ポリシー１０４１とを照らし合わせ、ポリシー１０４１を満たす結果を導いた対策が存在するか否かを判断する（ステップＳ３１６／ＮＯ、Ｓ３１７）。なお、本実施形態では、対策探索部１１０は、知識情報蓄積部１０４内に蓄積される上記対策リスト以外の対策全てを探索する全探索手法を用いているが、他の実施形態として、上記対策リスト以外の対策をランダムに探索するランダム探索手法や一定のポリシー（条件）を満たす対策が発見された時点で探索を止める最適化方法論等を利用することもできる。

ポリシー１０４１を満たす結果を導いた対策が一つのみ存在する場合、対策探索部１１０は、その対策の実行を決定し、当該対策の実行のスケジューリングを計画部１０７に対して依頼する（ステップＳ３１７／ＹＥＳ、Ｓ３１８）。また、ポリシー１０４１を満たす結果を導いた対策が複数存在する場合、対策探索部１１０は、その複数の対策のうち最適な結果を導いた対策の実行を決定し、当該探索の実行のスケジューリングを計画部１０７に対して依頼する（ステップＳ３１７／ＹＥＳ、Ｓ３１８）。一方、ポリシー１０４１を満たす結果を導いた対策が存在しない場合（ステップＳ３１７／ＮＯ）、ステップＳ３０１の処理に戻る。

続いて、対策探索部１１０は、計画部１０７に対してスケジューリングを依頼した対策を、当該事象の対策リスト１０４３に追加して紐つける（ステップＳ３１９）。このように対策探索部１１０によって今回探索された対策が対策リスト１０４３に追加される。従って、次回、同じ事象が分析部１０３によって分析、又は、モデル診断部１０６によって診断された場合、ステップＳ３１４〜ステップＳ３１９を行うことなく、今回探索された対策についてのシミュレーション処理を行うことが可能となる。

続いて、計画部１０７は、対策探索部１１０から依頼された対策の実行をスケジューリングする（ステップＳ３１２）。

計画実行部１０９は、計画部１０７によって作成されたスケジュールに従って対策を実行する（ステップＳ３１３）。

次に、図１０及び図３−２を用いて、モニタ部１０１から直接得られるＣＢＥデータを分析し、分析結果に問題がある場合には対策を実行するまでの処理について説明する。なお、図３−２は、上述したように、ＡＣ環境の診断処理を含む流れを説明する上でも用いている。以下に説明する分析処理を含む流れにおいても図３−２と同様の処理が行なわれるため、図３−２に該当する処理については適宜説明を省略する。

図１１において、分析部１０３は、モニタ部１０１からＣＢＥデータを取得し、当該ＣＢＥデータに該当するポリシー１０４１を知識情報蓄積部１０４から参照し、参照したポリシー１０４１に基づいて当該ＣＢＥデータに問題がないかを分析する（ステップＳ１１０１、Ｓ１１０２）。上述したように、ＣＢＥデータがＣＰＵの使用率を示すデータであって、且つ、「ＣＰＵ使用率が０〜１０％であれば余剰である、ＣＰＵ使用率が１１〜８０％であれば正常である、ＣＰＵ使用率が８１％以上であれば過負荷である」というポリシー１０４１であれば、ＣＢＥデータにより示されるＣＰＵの使用率が８０％を越えていたらＣＢＥデータに問題があると分析され、反対にＣＢＥデータにより示されるＣＰＵの使用率が８０％未満である場合には、ＣＢＥデータには問題がないと分析される。

続いて、計画部１０７は、分析部１０３によりＣＢＥデータに問題があると分析された場合、知識情報蓄積部１０４においてその問題の事象に紐付けられる対策リスト１０４３を選択する（ステップＳ１１０２／ＹＥＳ、Ｓ１１０３）。

次に、計画部１０７は、当該ポリシー１０４１に基づいてシミュレーション部１０８にシミュレーション処理を依頼するか否かを判断する。例えば、当該ポリシー１０４１が「システムの応答がない場合は、即座に再起動する」である場合には、シミュレーション部１０８に対してシミュレーション処理を依頼せず、即座に対策の実行をスケジューリングする（ステップＳ１１０４／ＮＯ、Ｓ３１２）。また、対象となる事象が緊急の対処を要するものであるとして予めポリシー１０４１において定められている場合には、その問題がある事象の内容と当該事象に紐付けられている対策リスト１０４３をユーザに対して報知してもよい。これによって、ユーザは報知された対策リスト１０４３のうちから所望の対策を選択し、対策の実行を行なうことができる。なお、ステップＳ３１２以降の処理は、ＡＣ環境の診断処理を含む流れと同様であるため、説明を省略する。

一方、例えば、当該ポリシー１０４１が「ＣＰＵ使用率が過負荷の場合は、シミュレーションを実行して最適な結果を残した対策を選択する」である場合、計画部１０７は、対策リスト１０４３に含まれる各対策のシミュレーション処理をシミュレーション部１０８に対して依頼する（ステップＳ１１０４／ＹＥＳ、Ｓ３０８）。シミュレーション部１０８は、計画部１０７によって選択された対策リスト１０４３を参照し、その対策リスト１０４３に含まれる各対策のシミュレーション処理を実行する（ステップＳ３０９）。なお、ステップＳ３１０以降の処理は、ＡＣ環境の診断処理を含む流れと同様であるため、説明を省略する。

以上のように、本実施形態においては、監視データ（ＣＢＥデータ）に対応するポリシーから現在の問題の事象を分析（判定）し、又は、監視データ（ＣＢＥデータ）の履歴からモデルを抽出して当該モデルとそのモデルに対応するポリシーから現在・将来の問題の事象を診断（判定）し、上記判定結果に基づいてその事象に対応する対策リストによるシミュレーション処理を行って、各対策の効果を評価するようにしている。即ち、本実施形態は、ＡＣ環境内における各装置が様々な事象に陥った場合でも、その事象に対応する対策リストによるシミュレーション処理によって各対策の効果を評価することができる。

従って、本実施形態によれば、各対策の効果に関する評価結果に基づいて、ＡＣ環境内における各装置の様々な事象に対して最も的確な対策を選択・策定することが可能である。

また、本実施形態では、計画部１０７が最適な効果を導いた対策の決定及び対策の実行のスケジューリングを行い、計画実行部１０９によってそのスケジューリングに従って対策を自動的に実行することが可能である。

さらに、本実施形態では、仮に或る事象に対応する対策リストから最適な対策が発見できなかった場合でも、その他の対策を探索することによって、当該事象に適用する対策の幅を事前の対策リストから更に広げることが可能である。

以上では、ＣＰＵ使用率の時系列変化、スループットの時系列変化及びＣＰＵ使用率とスループットとの相関関係を表すモデルを抽出した場合について説明を行った。これら以外にも、例えば、図９に示すように、前後１日において処理Ａのスループットと処理Ｂのスループットとの監視データを取得し、それらに基づいて処理Ａのスループットと処理Ｂのスループットとの相関関係を表すモデルｆ_TAB1（ｘ）＝ρ_AB1ｘ＋θ_AB1、ｆ_TAB2（ｘ）＝ρ_AB2ｘ＋θ_AB2を抽出して問題の事象を診断することも可能である。即ち、それらのモデルに紐付けられるポリシーが「処理Ａのスループットと処理Ｂのスループットとの相関関係が前後１日において誤差１０％以内に収めるべきである」である場合、図９に示すように、ｆ_TAB1（ｘ₁）とｆ_TAB2（ｘ₁）の間に１０％以上の誤差があれば、処理Ａのスループットと処理Ｂのスループットとのバランスが崩れる可能性があると分析又は診断する。その後は同様に、この問題の事象に対応する対策リストによるシミュレーション処理が実行され、最適な結果を導いた対策が実行される。

本発明は、以上に述べたモデル以外にもＡＣ環境から取得し得る監視データに基づいて、種々のモデルを抽出できることは勿論である。また、同一の装置から得られた監視データだけでなく、異なる複数の装置から監視データを得て、装置間の監視データの相関関係を表すモデル等の抽出を行うことも可能である。

本発明の実施形態に係るＡＣ性能監視装置の機能的な構成を示すブロック図である。ＡＣ性能監視装置のハードウェア構成を示すブロック図である。本発明の実施形態に係るＡＣ性能監視装置の動作を示すフローチャートである。本発明の実施形態に係るＡＣ性能監視装置の動作を示すフローチャートである。モデルの抽出方法を具体的に説明するための図である。複数の処理分散パターンを説明するための図である。問題の事象が分析部によって分析又はモデル診断部によって診断される例を具体的に説明するための図である。問題の事象が分析部によって分析又はモデル診断部によって診断される例を具体的に説明するための図である。問題の事象が分析部によって分析又はモデル診断部によって診断される例を具体的に説明するための図である。他のモデルの抽出例及びそのモデルに基づく問題の事象の分析又は診断例を説明するための図である。本発明の実施形態に係るＡＣ性能監視装置の動作を示すフローチャートである。本発明の実施形態に係るＡＣ性能監視装置の動作を示すフローチャートである。

符号の説明

１００：ＡＣ性能監視装置
１０１：モニタ部
１０２：イベント情報蓄積部
１０３：分析部
１０４：知識情報蓄積部
１０５：モデル抽出部
１０６：モデル診断部
１０７：計画部
１０８：シミュレーション部
１０９：計画実行部
１１０：対策探索部
１００１：サーバ類
１００２：ストレージ類
１００３：ネットワーク装置類
１００４：非ＡＣ環境
１０４１：ポリシー
１０４２：モデル
１０４３：対策リスト

Claims

少なくとも一つの外部装置と通信回線を介して接続される性能監視装置であって、
前記外部装置の状態に係る状態情報を取得する取得手段と、
前記取得手段により取得される前記状態情報に基づいて、前記外部装置の状態を判定する判定手段と、
前記判定手段による判定結果に対応する対策リストを参照し、前記対策リストに含まれる少なくとも一つの対策情報夫々による前記外部装置の状態に係るシミュレーション処理を実行し、前記各対策情報により示される対策の効果を評価するシミュレーション手段とを有することを特徴とする性能監視装置。
前記取得手段により取得される前記状態情報を外部又は内部の記録媒体内に蓄積する蓄積手段と、
前記記録媒体内に蓄積される前記状態情報の履歴に基づいて、前記外部装置の状態を表すモデル情報を抽出するモデル抽出手段とを更に有し、
前記判定手段は、前記モデル情報に基づいて前記外部装置の状態を判定することを特徴とする請求項１に記載の性能監視装置。
前記判定手段は、前記モデル情報と、更に前記状態情報の種類に応じた前記外部装置の運用に係るポリシー情報とに基づいて、前記外部装置の状態を判定することを特徴とする請求項２に記載の性能監視装置。
前記シミュレーション手段による前記各対策の効果の評価結果に基づいて、前記対策リストから一つの対策情報を決定する対策決定手段を更に有することを特徴とする請求項１乃至３の何れか１項に記載の性能監視装置。
前記対策決定手段により前記評価結果に基づいて前記対策リストから一つの対策情報を決定することができなかった場合、前記対策リストに含まれない他の対策情報を探索する探索手段を更に有し、
前記シミュレーション手段は、前記他の対策情報による前記外部装置の状態に係るシミュレーション処理を実行し、前記他の対策情報により示される対策の効果を評価することを特徴とする請求項４に記載の性能監視装置。
前記探索手段は、前記対策決定手段が前記他の対策情報により示される対策の効果の評価結果に基づいて前記他の対策情報を決定した場合、前記他の対策情報を前記判定結果に対応付けることを特徴とする請求項５に記載の性能監視装置。
少なくとも一つの外部装置と通信回線を介して接続される性能監視装置による性能監視方法であって、
前記外部装置の状態に係る状態情報を取得する取得ステップと、
前記取得ステップにより取得される前記状態情報に基づいて、前記外部装置の状態を判定する判定ステップと、
前記判定ステップによる判定結果に対応する対策リストを参照し、前記対策リストに含まれる少なくとも一つの対策情報夫々による前記外部装置の状態に係るシミュレーション処理を実行し、前記各対策情報により示される対策の効果を評価するシミュレーションステップとを含むことを特徴とする性能監視方法。
請求項７に記載の性能監視方法をコンピュータに実行させるためのプログラム。