JP2014134987A - 情報処理システム監視装置、監視方法、及び監視プログラム - Google Patents

Abstract

【課題】
複数の多様な情報処理システムを対象として、システム障害発生の予兆を検知する方法を提供する。
【解決手段】
複数の監視対象システムを監視するシステムは、複数の指標について計測値を受信し、基準指標について受信した計測値から将来の計測値を予測するための予測モデルを複数の予測モデルから指定し、前記指定した予測モデルに基づいて、前記基準指標の予測値を予測し、前記基準指標およびターゲット指標とを対象としたベイジアンネットワークを生成又は更新し、前記ターゲット指標の計測値が所定の値または値の範囲となる確率を算出する。
【選択図】 図７

Description

情報処理システムの監視装置、監視方法、及び監視プログラムに関し、特に情報処理システムの稼働状況を遠隔より監視し、システムに障害が発生する予兆を検知し、検知した予兆を通知するサービスを提供する装置等に関する。

近年、情報処理システムが企業活動や社会インフラの基盤としてますます重要な位置を占めるようになるにつれ、こうした情報処理システムにおける障害の発生を早期に検知する、あるいは発生した障害の根本原因を分析し迅速な対処を図る、といったことを目的とした様々な技術が開発され、システムの運用管理業務に適用されている。さらに近年では、こうした障害の発生に先立って、その予兆を検知しようとする障害予兆検知技術の重要性が注目されている。

このような障害予兆検知に取り組む技術として、例えば特許文献１が開示するものがある。これは、コンピュータクラスタにおける重要イベントの発生を予測するシステムであり、イベントログおよびシステムパラメタログといった情報を、ベイジアンネットワークによるモデルに入力することで予測を行うハイブリッド予測システムである。

米国特許第７，８９５，３２３号明細書

近年の当業界においては、顧客に対して遠隔地からサービスを提供する、いわゆるクラウドサービス事業が広範に展開されつつある。一般にこうしたサービス事業は、顧客側にとってはハードウェアやソフトウェアライセンスに要する初期コストの削減という点において、またサービス事業者側にとっては、単一のシステムで複数の顧客にサービスを提供する、いわゆるマルチテナント化による資源の集約運用が可能になる点においてコストメリットがある。システム運用管理業務もまた、この潮流の例外ではあり得ない。

こうした状況を鑑みると、前述したような既存の障害予測システムは、クラウドサービス事業として提供する上で要求される、情報処理システムの多様性への適応という点で不十分である。例えば、多種多様なシステムやアプリケーションの特性の差異や、サービスの利用者の要求に対応できていない。また、ベイジアンネットワークの生成に要する処理負荷の問題に対応できていない。

そこで本発明は、複数の多様な情報処理システムを対象としたクラウドサービス事業として、障害発生の予兆を検知する方法、およびプログラム、装置、システムを提供する。これは例えば、情報処理システムの多様性に対応しつつ、処理負荷を削減した障害予兆検知をクラウドサービス事業として提供するものである。

上記課題を解決する、１以上の計算機から構成され、複数の監視対象システムの予兆検知を行うサービスシステムは、（１）前記監視対象システムから、複数の指標について計測値を受信し、（２）前記複数の指標の一部である基準指標について、受信した計測値から将来の計測値を予測するための予測モデルを複数の予測モデルから指定し、（３）前記指定した予測モデルに基づいて、前記基準指標の予測値を予測し、（４）前記基準指標と、前記複数の指標の一部だが前記基準指標と異なる指標であるターゲット指標と、を対象としたベイジアンネットワークを生成又は更新し、（５）前記基準指標の予測値と、前記ベイジアンネットワークと、に基づいて前記ターゲット指標の計測値が所定の値または値の範囲となる確率を算出する。

本発明によれば、複数の多様な情報処理システムを対象として、障害発生の予兆を検知するクラウドサービス事業を提供することができる。

上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

情報処理装置の構成の一例を示すブロック図である。 障害予兆検知サービスの提供形態の一例を示すブロック図である。 監視対象システムの概念の一例を示すブロック図である。 業務サーバから収集する計測値の一例を示すテーブルである。 業務サーバから収集する計測値の別の一例を示すテーブルである。 システムプロファイルテーブルである。 連結された計測値の一例を示すテーブルである。 計測値と性能指標の連結の一例を示すテーブルである。 予兆サーバの構成の一例を示すブロック図である。 予測プロファイルテーブルである。 タスクリストテーブルである。 スケジューラと予兆エンジンの動作の一例を示すフローチャートである。 スケジューラによる中断処理の動作の一例を示すフローチャートである。 システムモデル生成処理の動作の一例を示すフローチャートである。 パラメタ学習のみによるシステムモデル生成処理の動作の一例を示すフローチャートである。 モデルリポジトリの一例を示す図である。 予測モデルリポジトリの一例を示す図である。 予兆検知処理の動作の概要の一例を示すフローチャートである。 時系列予測処理の動作の一例を示すフローチャートである。 確率推論処理の動作の一例を示すフローチャートである。 予兆検知処理の動作の概要の別の一例を示すフローチャートである。 確率推論処理の動作の別の一例を示すフローチャートである。 予兆検知結果を表示するよう設定されたクライアント画面の一例を示すレイアウト図である。 予兆検知結果を表示するよう設定されたクライアント画面の別の一例を示すレイアウト図である。 予測モデルを選択可能とする指標リストの一例を示すレイアウト図である。 システムモデルを選択可能とするよう設定されたクライアント画面の一例を示すレイアウト図である。 システムモデルを選択可能とするよう設定されたクライアント画面の別の一例を示すレイアウト図である。 負荷生成装置のログの一例を示す図である 負荷生成装置のログを変換する処理の動作の一例を示すフローチャートである。 クラスター生成処理の動作の一例を示すフローチャートである。 システム異常度算出処理の動作の一例を示すフローチャートである。 システム異常度を表示するよう設定されたクライアント画面の一例を示すレイアウト図である。 システム異常度を表示するよう設定されたクライアント画面の別の一例を示すレイアウト図である。 タスクリストテーブルの別の一例である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、以後説明される図面においては、同一部には同一符号を付し、その繰り返しの説明は省略または簡略化される。

まず、第一の実施例として、障害予兆検知サービスを提供するためのシステム運用管理装置の例を説明する。

図１は、情報処理装置の構成の一例を示す図である。

情報処理装置１００はプロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５から構成されている。プロセッサ１０１はメモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５と接続されている。ネットワークＩ／Ｆ１０４は、ネットワークスイッチ１０７を経由してネットワーク１０６と接続されている。

情報処理装置１００は、例えばラックマウントサーバ、ブレードサーバ、パーソナルコンピュータ等である。また情報処理装置１００は、プロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５を、いずれも複数を備えることがある。また、ストレージ１０３は、例えばハードディスクドライブ（ＨＤＤ）や、ソリッドステートドライブ（ＳＳＤ）等であり、またはこれらを複数台組み合わせたものである。また、ネットワーク１０６は、例えばイーサネット（登録商標）や、ＩＥＥＥ８０２．１１規格に基づく無線ネットワークや、ＳＤＨ／ＳＯＮＥＴ規格に基づく広域ネットワーク等である。または、ネットワーク１０６は、これら複数のネットワーク技術を組み合わせたネットワークである。

ストレージ１０３は、データを不揮発的に記録し、また読み出すことができる。ネットワークＩ／Ｆ１０４は、それが接続するネットワーク１０６を経由して、他の情報処理装置１００が有するネットワークＩ／Ｆ１０４と通信することができる。コンソール１０５は、ディスプレイ装置を用いてテキスト情報、グラフィカル情報等を表示し、また接続されたヒューマンインタフェースデバイス（不図示）から情報を受信することができる。

情報処理装置１００は、メモリ１０２にユーザプロセス２００、オペレーティングシステム（ＯＳ）２２０を実装している。ユーザプロセス２００、オペレーティングシステム２２０は、いずれもプログラムであって、情報処理装置１００の有するプロセッサ１０１で実行され、これによって情報処理装置１００はメモリ１０２やストレージ１０３へデータを読み書きし、ネットワークＩ／Ｆ１０４とネットワーク１０６を経由して、他の情報処理装置１００のメモリ２００に実装されているユーザプロセス２００やオペレーティングシステム２２０と通信を行い、コンソール１０５に情報を表示し受信することができる。

図２は、システム監視サービスの提供態様の一例を示す図である。

システム監視サービスは、顧客サイト３１０とサービスサイト３０２よりなる。これらサイトは、いずれも１以上の情報処理装置１００を含み、それらを相互に接続するネットワーク１０６と１以上のネットワークスイッチ１０７により構成されている。

顧客サイトとサービスサイトは、典型的には地理的な遠隔地にあり、広域ネットワークにより接続されるが、これ以外の態様、例えばいずれのサイトも同一のデータセンタ内に存在し、データセンタ内ネットワークにより接続されることもあり得る。いずれの態様によっても、顧客サイトに存する情報処理装置と、サービスサイトに存する情報処理装置は、各々接続されたネットワークを経由して相互に通信することができる。

こうしたサイト間の通信は、情報セキュリティの維持を理由として、ネットワークルータやファイアウォール装置（不図示）の設定により制限されることもあり得るが、本実施例において必要となる通信は、それらを可能ならしめるよう設定されているものとする。

顧客サイト３０１は、業務サーバ１１０、監視装置１１１、監視クライアント１１６、業務クライアント１１７を含む。業務サーバ１１０はアプリケーションプログラム２１０がユーザプロセスとして実装され、これを実行する。監視装置１１１は、業務サーバから計測値を定期的に収集する。これら処理は監視装置１１１のストレージに記憶されたプログラムをプロセッサが実行することで行われる。計測値を収集する対象は典型的には業務サーバであるが、これに限定するものではなく、業務クライアント１１７、ネットワークスイッチ１０７等を監視の対象に含むことができる。ここで収集する計測値の例は後述される。監視クライアント１１６は、コンソールを経由して顧客サイトの運用管理担当者に情報を提示し、運用管理担当者が入力した情報を受信する。業務クライアント１１７は、業務クライアントプログラム２１１がユーザプロセスとして実装され、これを実行する。業務クライアントプログラムは、業務サーバで実行されているアプリケーションプログラム２１０と通信を行う。こうしたプログラム間の相互通信により、特定の業務上の目的を達成するようアプリケーションプログラムを構成する方法はクライアント・サーバ方式と呼称され、典型的にはＷｅｂアプリケーションという態様にて当業者には周知のものであろう。

また、業務クライアント１１７は、顧客サイト３０１から離れて存在してもよい。こうした業務クライアントは、各々が接続されたネットワークを経由して業務サーバと通信を行う。

サービスサイト３０２は、蓄積サーバ１１２、予兆サーバ１１３、診断サーバ１１４、ポータルサーバ１１５を含む。蓄積サーバ１１２は、監視装置１１１が収集した計測値を定期的に受信し、ストレージ１０３に蓄積する。計測値を受信するための通信は、監視装置がその契機となる通信を開始する方法や、逆に蓄積サーバがその契機となる通信を開始する方法のいずれを選択してもよい。

予兆サーバ１１３は、蓄積サーバから、その蓄積する計測値を受信し、障害発生の予兆検知を行う。なお、予兆検知処理は予兆サーバ１１３のストレージに記憶された予兆エンジンプログラムをプロセッサが実行することでユーザプロセス（以後予兆エンジンと呼ぶ）を生成することで行われる。なお、予兆サーバはこうした予兆検知処理を行うために必要な情報をストレージ又はメモリに記憶している。こうした情報の一例としてはシステムプロファイル４１０、予測プロファイル４１１、タスクリスト４１２、モデルリポジトリ４１３、予測モデルリポジトリ４１４がある。なお、予兆サーバのこうした情報は図７等を用いて後ほど説明する。

診断サーバ１１４は、予兆サーバから予兆検知の結果を受信し、その予兆の内容に対応する対処方法を選択する。これら処理は診断サーバ１１４のストレージに記憶されたプログラムをプロセッサが実行することで行われる。

ポータルサーバ１１５は、蓄積サーバが蓄積する計測値や、予兆サーバの予兆検知の結果や、診断サーバの選択した対処方法を、顧客サイトの運用管理担当者の要求に応じて送信する。典型的には、顧客サイトにある監視クライアント１１６にユーザプロセスとして実装されたＷｅｂブラウザ２１２は、コンソールから運用管理担当者の指示を受信することを契機として、ポータルサーバに対して情報提示を要求し、Ｗｅｂブラウザはポータルサーバが送信した情報をコンソールに表示する。または、事前に決められた任意の間隔で情報の提示を要求するよう構成してもよい。また情報提示の手段はコンソールのディスプレイ装置に限定されず、電話や電子メール等、運用管理担当者にとって適切な任意の手段を採用することができる。

これら顧客サイトの業務サーバ、監視装置、監視クライアント、およびサービスサイトの蓄積サーバ、予兆サーバ、診断サーバ、ポータルサーバ、および業務クライアントは、いずれも図１に示す情報処理装置１００と同様の構成を有する。そしてこれらサーバで行われる処理は、各サーバのストレージに記憶されたプログラムをプロセッサが実行することで、ユーザプロセス生成を付随して行われる。また、いずれの装置も、処理負荷の分散や可用性の向上等を目的として、複数台を備えることがある。または、１台の情報処理装置が、上記した複数種類のサーバの役割に兼用されることがある。物理的な情報処理装置と、そのサーバとしての役割の対応関係には自由度があり、本実施例はその多数の組み合わせの中の一例であることは留意されたい。

このように、蓄積サーバ、予兆サーバ、診断サーバをサービスサイトに設置することで、顧客サイトにこれらのサーバを設置せずとも、顧客サイトの情報処理システムは障害予兆検知機能を使用することができる。これらのサーバは、データの蓄積や処理を目的として、大容量のストレージや高速なプロセッサ等のハードウェア資源を必要とするため、顧客サイトにとってはそうした高性能かつ高価なハードウェアの導入が不要になる効果がある。

また、システム監視サービスを複数の顧客サイトに提供することもできる。図２は、顧客サイトとサービスサイトが各々一つの実施形態を図示するが、これは顧客サイト毎に個別のサービスサイトを必要とすることを意味するものではない。単一のサービスサイトにて、複数の顧客サイトに対してサービスを提供することができる。

この場合は、サービスサイトを構成する一連のサーバ群は、複数の顧客サイトに対するサービス提供に供される。例えば蓄積サーバ１１２は複数の監視装置１１１から送信されるデータを収集・蓄積し、ポータルサーバ１１５は複数の監視クライアント１１６に対して情報の提供を行う。同様に、予兆サーバ１１３と診断サーバ１１４は、複数の監視装置が収集した計測値を基に、予兆検知と対処方法の選択を行う。

これらサービスサイトの情報処理装置は、複数の顧客サイトで収集した計測値をそれぞれ区別して取り扱うために、個々の顧客サイトの区別に供するためのコードを共有している。こうしたコードの付与によりデータの区別やセキュリティ保護を行う方法は当業者には周知のことであるため、以降の説明から該コードは省略される。また、以降説明されるテーブルに記憶された情報、コンソールが表示する情報についても同様に省略される。

図３は、顧客サイト３０１に含まれる監視対象システムの一例を示す図である。

システム監視サービスのサービス対象は、顧客サイトの業務サーバを単位とすることが多いが、これに限るものではない。業務サーバはユーザプロセスとしてアプリケーションプログラムを実装すると前述した。こうしたアプリケーションプログラムは、業務サーバが単独で実行するとは限らない。むしろ、複数の業務サーバに、各々別個の役割を持つアプリケーションプログラムや、その実行を支援するミドルウェアといったプログラムが実装されており、これら複数のプログラムが相互に通信を行いつつ、ある業務上の目的を達成すべく実行されているのが通常の情報処理システムの態様である。一般に、こうした複数の情報処理装置に分散して実装された多数のプログラムが協調して動作するアプリケーションを分散アプリケーション、こうした情報処理システムを分散処理システムと呼称する。

典型的には、業務サーバ１１０は、ユーザプロセスとしてアプリケーションプログラム２１０を実装する。業務クライアント１１７は、ユーザプロセスとして業務クライアントプログラム２１１を実装する。業務サーバ１１０、業務クライアント１１７はいずれも複数が存在し、ネットワークスイッチ１０７を経由し、ネットワーク１０６がこれらを相互に接続する。

アプリケーションプログラム２１０、業務クライアントプログラム２１１は、一つの分散アプリケーション３１０を構成する。システム監視サービスにおいて、該分散アプリケーションの実行に係る装置群を監視対象システム３１１と呼称し、顧客サイトを構成する装置群を分界し区別する単位を成す。

ただし業務クライアント１１７の中には、分散アプリケーション３１０の一部であっても、顧客サイトから離れて存在する、あるいはネットワークを経由した接続性が一時的にしか存在しない、等といった理由により監視装置による監視の対象としてそぐわないものもあるであろう。また、例えばＷｅｂアプリケーションにおいて、インターネットを経由した不特定多数の業務クライアントプログラムによる通信を処理するよう構成されたものについては、個々の業務クライアントを監視対象とすることは困難である。こうした装置は、監視対象システムの埒外に置くことができる。

一般にシステム運用管理業務は、顧客サイトに存する情報処理装置の個別の稼働状況を把握するのに留まらず、分散処理システム全体としての稼働状況を把握しなければならない。システム監視サービスにおける監視対象システムという概念は、かかる状況を踏まえて導入されたものである。

図４は、監視装置１１１が業務サーバから収集する計測値の一例を示す図である。

本実施例では、計測値の個別の例として、図４（ａ）にプロセッサ性能情報４０１、図４（ｂ）にメモリ性能情報４０２のテーブルを示す。各々のテーブルに共通するのは、レコードそれぞれに当該情報を取得した時刻と、情報を取得するインターバルを含むことである。プロセッサ性能情報の場合、インターバルは、何秒間の値を累積したものかを示し、さらに累積値から使用率を算出したものが計測値となる。一方メモリ性能情報の場合は、収集した値はその収集した時点でのスナップショットであり、インターバルは文字通り、情報の収集間隔の意味である。そして、各レコードはさらに詳細な性能情報の項目を複数含む。

こうした計測値は、典型的には業務サーバにユーザプロセスとして実装されたエージェントが、コマンドの実行や特殊ファイルの読み出し、あるいは専用のＡＰＩを用いるといった方法でＯＳから取得し、監視装置に送信する。

本実施例では、計測値の代表的なものとして上記の二つを取り上げたが、これに限定されるものではなく、他にも監視装置１１１が収集できる統計情報は、同様に計測値の一つとなりうる。例えばネットワークスイッチ１０７からは、ネットワークポート毎のデータ送受信量がＳＮＭＰといったプロトコルで収集可能である。

図５は、予兆サーバ１１３が記憶する、システムプロファイルテーブルの一例を示す図である。

監視対象システムという概念については前述した。これを概念に留まらず、システム監視サービスの予兆検知機能において利用するためにシステムプロファイルテーブル４１０を用意する。システムプロファイルテーブル４１０は、システムＩＤフィールド、システム名フィールド、任意の個数の計測値フィールドを含む。一つのレコードは一つの監視対象システムに対応する。システムＩＤフィールドは一意な符号を、システム名フィールドは監視対象システムを運用管理担当者が特定できるよう付与された名称を格納する。そして、ある監視対象システムを構成する装置から監視装置が収集する計測値には、各々を区別できる名称が付与され、計測値フィールドとしてシステムプロファイルテーブルに格納される。よって、使用する計測値フィールドの個数は、レコードによって異なるものとなる。本実施例では、計測値の名称を業務サーバの名称と計測値の種別を基に生成して付与するが、本実施例の含む各処理の円滑な実行を阻害しないよう一意性を担保できる命名の方法であればこれに限定するものではない。

またシステムプロファイルテーブル４１０は、監視対象システムがその実行に係る分散アプリケーションの性能指標を計測値フィールドに格納する。この性能指標とは、例えばＷｅｂアプリケーションであれば、単位時間当たりの同時接続ユーザ数、平均応答時間といった数値で示される指標である。計測値と同様、こうした性能指標には各々を区別できる名称が付与される。例えば、分散アプリケーションの名称と指標の種別を基に生成してもよい。

システムプロファイルテーブル４１０は、典型的には予兆サーバ１１３のメモリに格納されているが、これに限定せずストレージに格納してもよいし、他のサーバに格納しておき必要に応じて通信により取得するようにしてもよい。また本実施例では、説明を容易とするためにテーブルの形式を採用しているが、キー・バリュー形式やドキュメント指向データベース等、他のデータ構造を採用してもよい。

システムプロファイルテーブル４１０の各レコードは、例えば顧客サイトの運用管理担当者が入力した情報を用いて作成する。

図６は、連結された計測値の一例を示す図である。

監視装置が収集した計測値には、その取得時刻が含まれることは前述した。これを利用し、監視対象システムが含む複数の装置から収集した計測値から、取得時刻が共通なレコードを抽出し連結することができる。そのようにして、ある監視対象システムの複数の業務サーバから収集した計測値を連結したテーブルの例を図６（ａ）のテーブル４０３に示す。テーブル４０３の各フィールドには、システムプロファイルテーブルの計測値フィールドに格納された名称が区別のために付与されている。

さらに、監視対象システムがその実行に係る分散アプリケーションの性能指標も、同様に連結することができる。そのような例を図６（ｂ）のテーブル４０４に示す。フィールド群４０５は、ある監視対象システムがその実行に係る分散アプリケーションの性能指標、フィールド群４０６は該監視対象システムの業務サーバから収集した計測値である。こうした性能指標を取得する方法については後述される。

こうした連結処理は、監視装置、蓄積サーバ、予兆サーバ等、いずれの装置で行ってもよいが、連結された計測値は蓄積サーバのストレージに記憶される。

図７は、予兆サーバの構成の一例を示す図である。

予兆サーバ１１３は、ユーザプロセスとして予兆エンジン２０１を実装する。そしてこのようなユーザプロセスはストレージに記憶された予兆エンジンプログラムをプロセッサが実行することで生成される。予兆エンジンは、データ取得部２０１１、データ記憶部２０１２、モデル生成部２０１３、モデル記憶部２０１４、予測部２０１５、推論部２０１６、出力部２０１７、タスク制御部２０１８を有する。また、予兆サーバ１１３はユーザプロセスとしてスケジューラ２０２を実装する。なお、スケジューラ２０２は予兆エンジンプログラムによって生成されたユーザプロセスでもよく、また他のプログラムによって生成されたユーザプロセスであってもよい。そして、前述した通り、予兆サーバ１１３のメモリはシステムプロファイルテーブル４１０、予測プロファイルテーブル４１１、タスクリストテーブル４１２、モデルリポジトリ４１３、予測モデルリポジトリ４１４を記憶する。なお、これら情報は、メモリに代えてストレージに記憶してもよいし、他のサーバに格納しておき必要に応じて通信により取得するようにしてもよい。

以下に予兆エンジン２０１の各部について説明する。なお、各部の実体はプログラム関数、プログラムモジュール、ライブラリ、クラスインスタンス、等であってもよく、また他の実体であってもよい。さらには、各部が提供する処理を達成できるのであれば、各部はプログラム又はユーザプロセスとして明確に区別できる存在である必要はなく、予兆エンジンプログラム単体又はＯＳ等の他のプログラムと共同で各部が提供する処理を行えれば問題ない。

予兆エンジン２０１のデータ取得部２０１１は、蓄積サーバに対して計測値を送信するよう要求し、計測値を受信し、データ記憶部２０１２に格納する。モデル生成部２０１３は、データ記憶部に記憶された計測値を基にシステムモデルを生成し、モデル記憶部２０１４に格納する。予測部２０１５は、データ記憶部に記憶された計測値と、予測プロファイルテーブル４１１に格納された情報と、予測モデルリポジトリ４１４に格納された情報を基に時系列予測処理を実行し、得られた予測値を推論部２０１６に通知する。推論部２０１６は、受領した予測値と、モデル記憶部に格納されたシステムモデルと、予測プロファイルテーブルに格納された情報を基に確率推論処理を実行し、得られた確率値を出力部２０１７に通知する。

出力部２０１７は、受領した確率値を診断サーバ１１４、ポータルサーバ１１５に対して送信する。タスク制御部２０１８は、スケジューラ２０２からタスクメッセージを受信し、該タスクメッセージの内容に応じて予兆エンジンを構成する上記処理部の処理実行を制御することで、タスクの実行、タスクの中断を行う。予兆サーバが実行する以上の処理を予兆検知処理と呼称する。

出力部２０１７が診断サーバ、ポータルサーバに確率値を送信するにあたっては、必ずしも予兆検知処理に同期して行う必要はなく、メモリやストレージに格納し、情報の提示要求に応じて送信してもよい。

スケジューラ２０２は、タスクリストテーブル４１２から予兆エンジンが実行する予兆検知処理のリストを取得し、予兆エンジンとタスクメッセージの送受信を行い、タスクの実行状況に応じてタスクリストテーブルを更新する。タスクリストテーブル４１２は、予兆エンジンが実行する予兆検知処理のリストを記憶する。

以下、予兆サーバが実行する予兆検知処理の核心をなす、予測プロファイルテーブル４１１、タスクリストテーブル４１２と、スケジューラ２０２、タスク制御部２０１８、モデル生成部２０１３、予測部２０１５、推論部２０１６の処理について詳説する。

図８は、予測プロファイルテーブルの一例を示す図である。

予測プロファイルテーブル４１１は、予兆エンジンが実行すべき予兆検知処理の定義を格納するものである。予測プロファイルテーブルの各レコードは各々一つの予兆検知処理を格納し、予測プロファイルＩＤフィールドで一意に区別される。システム名フィールドは、システムプロファイルテーブルに記録されているシステム名のいずれかを格納する。または、システムＩＤを格納してもよい。モデルＩＤフィールドは確率推論処理で用いるシステムモデルのＩＤを、予測モデルＩＤフィールドは時系列予測処理で用いる予測モデルのＩＤを格納する。既定リードタイムフィールドは、時系列予測処理で用いる値を、基準指標フィールド、ターゲット指標フィールド、予測事象フィールドは、確率推論処理で用いる値を各々格納する。これらのＩＤや値の使用方法は後述される。

予測プロファイルテーブル４１１の各レコードは、例えば顧客サイトの運用管理担当者が入力した情報を用いて作成する。その一例は後述される。

図９は、タスクリストテーブルの一例を示す図である。

予測プロファイルテーブル４１１が、予兆検知処理を定義するものであったのに対し、タスクリストテーブル４１２は処理各々の実行状況を管理するためのテーブルである。監視対象システムが分散アプリケーションの実行に供されている限り、その内部状態は刻一刻と変化を続け、障害発生のリスクもまた変化する以上、予兆検知処理も継続的に実行する必要があり、タスクリストテーブルはその管理のために存在する。以降、タスクリストテーブルに格納された予兆検知処理をタスクと呼称することがある。

タスクリストテーブルの各レコードは各々一つの予兆検知処理を格納し、各々はＩＤフィールドに格納された予測プロファイルＩＤで予測プロファイルテーブルとの対応関係が定まる。実行フラグフィールドは、レコードに記憶された予兆検知処理を定期的に実行するか否かを示すフラグを格納する。該フラグが“Ｙ”であれば定期的な実行に供され、“Ｎ”であれば実行されない。インターバルフィールドは、定期的な実行を行う場合の実行間隔を示す数値を、典型的には秒数で格納する。最終更新フィールドは、各レコードの予兆検知処理が最後に実行開始された時刻を格納する。実行中フィールドは、実行中のタスクを一意に特定できるＩＤ（ＴＩＤ）、または実行中のタスクがない場合にはＮＵＬＬを格納する。

タスクリストテーブル４１２の各レコードのうち、最終更新フィールドと実行中フィールド以外は、例えば顧客サイトの運用管理担当者が入力した情報を用いて作成する。

図１０は、スケジューラと予兆エンジンの処理手順の一例を示す図である。

スケジューラは、タスクリストテーブルに格納された予兆検知処理各々について、実行の開始、実行完了の確認を行う。本実施例では、スケジューラはスレッド機構を使用して並列処理を行うよう構成されているが、マルチプロセスによる構成や、その他の並列処理機構、非同期処理機構を採用することもできる。

まずスケジューラのスレッドＡは、タスクリストを取得する（ステップＳ１００１）。以下の処理は、タスクリストに記録された全タスクを対象に行う（ステップＳ１００２）。まず実行フラグフィールドに“Ｙ”が格納されているかを判定する（ステップＳ１００３）。ついで実行中フィールドがＮＵＬＬであるかを判定する（ステップＳ１００４）。続いて現在時刻と最終更新時刻の差が、インターバル以上であるかを判定する（ステップＳ１００５）。これらの判定が肯定されると、該タスクは実行可能であり、かつ前回実行時からインターバルを越えて未実行状態にあることになるので、スレッドＡは該タスクの実行メッセージを送信し（ステップＳ１００６）、タスクリストの最終更新時刻を現在時刻に、実行中フィールドを生成したＴＩＤに更新する（ステップ１００７）。スレッドＡは、この一連の処理を定期的に実行することによって、予兆検知処理を継続的に実行するよう予兆エンジンに指示する。

予兆エンジンのタスク制御部は、常に実行メッセージの受信待ち状態にある。スケジューラが送信した実行メッセージを受信すると（ステップＳ１０２１）、該実行メッセージに格納されたタスクに基づいて、予兆エンジン内の各処理部に処理を指示しタスクを実行する（ステップＳ１０２２）。タスクの実行が完了すると、完了メッセージを送信し（ステップＳ１０２３）、実行メッセージ受信待ち状態に復帰する。

スケジューラのスレッドＢは、常に完了メッセージの受信待ち状態にある。タスク制御部が送信した完了メッセージを受信すると（ステップＳ１０１１）、タスクリストの該タスクに対応するレコードの実行中フィールドをＮＵＬＬに更新する（ステップＳ１０１２）。

スケジューラと、予兆エンジン内のタスク制御部とのメッセージ交換には、ＨＴＴＰ、ＲＰＣ、メッセージキュー等、任意のプロセス間通信の方式を用いてよい。

図１１は、予兆エンジンで実行中のタスクを中断する処理手順の一例を示す図である。

予兆エンジンが実行するタスクによっては、何らかの要因により、実行開始時点からインターバルを越えてもなお実行中のままとなっているタスクが存在する可能性がある。このようなタスクの処理結果は、例え正常に出力されたとしても時期を逸したものであるので、処理を中断して計算資源の浪費を防ぐことが望ましい。

本実施例では、スケジューラのスレッドＣがタスクのアボート処理を行う。まずスレッドＣは、タスクリストを取得する（ステップＳ１１０１）。以下の処理は、タスクリストに記録された全タスクを対象に行う（ステップＳ１１０２）。まず実行フラグフィールドに“Ｙ”が格納されているかを判定する（ステップＳ１１０３）。ついで実行中フィールドがＮＵＬＬでないかを判定する（ステップＳ１１０４）。続いて最終更新時刻とインターバルの和が、現在時刻より小さいかを判定する（ステップＳ１１０５）。これらの判定が肯定されると、該タスクは実行中であり、かつ前回実行時から既定のインターバルを超過していることになるので、スレッドＣは該タスクのアボートメッセージを予兆エンジンのタスク処理部に送信する（ステップＳ１１０６）。スレッドＣは、この一連の処理を定期的に実行することによって、予兆エンジンのタスクが計算資源を浪費することを防ぐ。

図１２は、予兆エンジン２０１で行われる、システムモデル生成の処理手順の一例を示す図である。

予兆検知処理には、監視対象システムのシステムモデルが必要である。このシステムモデルとは、システムプロファイルテーブル４１０に記録されている、監視対象システムに係る計測値や性能指標について、図６（ｂ）に示すテーブル４０４のような具体的な数値のデータを基にして、その計測値ないし性能指標間相互の関係を記述する統計的モデルである。このようなモデルとして、例えばベイジアンネットワークを採用することができる。

ベイジアンネットワークは、複数の確率変数をノードとする非循環有向グラフと、該グラフの表現するノード間の依存関係に基づいた各変数の条件付き確率表ないし条件付き確率密度関数により構成される確率モデルであり、統計的学習によりモデルを構築することができる。特に、変数の観測データを利用して、非循環有向グラフの構造を決定することを構造学習、グラフの各ノードの条件付き確率表ないし条件付き確率密度関数のパラメタを生成することをパラメタ学習と呼称する。

本実施例では、予兆エンジン２０１のモデル生成部２０１３とモデル記憶部２０１４がシステムモデル生成処理を行う。システムモデル生成処理は、典型的にはタスク制御部がモデル生成メッセージを受信することを契機として実行される。該メッセージは、モデル生成の対象である監視対象システムのシステム名またはシステムＩＤと、モデル生成に使用する計測値の時間的な範囲を示す指定区間とを含む。

図１２（ａ）は、構造学習とパラメタ学習の両者を行うシステムモデル生成の処理手順を示す。

モデル生成部は、モデル生成メッセージから指定区間を取得する（ステップＳ１２０１）。次いで、モデル生成部はシステムプロファイルテーブルに記録されている該監視対象システムの計測値の項目を取得する（ステップＳ１２０２）。計測値の項目について、データ記憶部から指定区間の範囲に該当する計測値を取得する（ステップＳ１２０３）。取得した計測値をメモリに格納し（ステップＳ１２０４）、クレンジング処理を行う（ステップＳ１２０５）。クレンジング処理には、外れ値の除去、欠損値の補完、正規化といった、観測データを対象とした統計処理として一般に知られている方式や、その組み合わせを使用する。クレンジング処理済みの計測値を学習データとして、構造学習を実行し（ステップＳ１２０６）、生成したグラフ構造に対して、同様に計測値を学習データとしてパラメタ学習を行う（ステップＳ１２０７）。構造学習のアルゴリズムとしては、Ｈｉｌｌ−Ｃｌｉｍｂｉｎｇ法、Ｇｒｏｗ−Ｓｈｒｉｎｋ法等が、パラメタ学習のアルゴリズムとしては、最尤法、ベイズ推定法等が知られているが、適切なものを任意に選択してよい。そしてモデル記憶部が、モデル生成部が生成したシステムモデルをモデルリポジトリ４１３に格納する（ステップＳ１２０８）。

図１２（ｂ）は、既にモデルリポジトリに格納されているグラフ構造に対して、パラメタ学習のみを行うシステムモデル生成の処理手順を示す。

モデル生成部の、モデル生成メッセージからの指定区間の取得（ステップＳ１２１１）からクレンジング処理（ステップＳ１２１５）までの処理は、図１２（ａ）に示す処理と同様である。モデル生成部は、クレンジング処理済みの計測値を得た後、モデル記憶部に対して該監視対象システムのシステムモデルを要求する。モデル記憶部はモデルリポジトリに格納されたシステムモデルを取得し、モデル生成部はシステムモデルからグラフ構造を取得する（ステップＳ１２１６）。続いてクレンジング処理済み計測値を学習データとして、パラメタ学習を行う（ステップＳ１２１７）。こうして更新したシステムモデルを、モデル記憶部がモデルリポジトリに格納する（ステップＳ１２１８）。

このような既知のグラフ構造を使用したパラメタ学習によるシステムモデル生成処理によって、構造学習に要する処理負荷を削減することができる。

図１３は、モデルリポジトリの一例を示す図である。

図１３（ａ）に示すモデルリポジトリ４１３は、予兆エンジンがシステムモデル生成処理を行った結果生成されたシステムモデルを記録する。各モデルはＩＤフィールドによって一意に特定可能であり、運用管理担当者が各モデルを弁別することが容易となるようモデル名を付与することができる。モデル名を表示する例は後述される。

システムモデルは、構造学習により生成されたグラフ構造と、パラメタ学習により生成されたパラメタ群からなることは前述した。モデルリポジトリの構造フィールドは、構造学習により生成されたグラフ構造を格納する。パラメタフィールドは、パラメタ学習により生成された条件付き確率表ないし条件付き確率密度関数のパラメタを格納する。

ただし、これらグラフ構造ないしパラメタは、テーブルに直接格納するには適さない形でメモリ上に存在することがある。この場合、テーブルには各々へのポインタを格納してもよい。本実施例では、説明を容易とするためにテーブルの形式を採用しているが、オブジェクトデータベースやグラフデータベース等、他のデータ構造を採用してもよい。また、別途用意するコンテンツリポジトリや構成管理ツール等の機能を利用したり、単にファイルシステムに格納したりするのでもよい。どのような態様であれ、システムモデルのグラフ構造をパラメタから独立して取得できるよう構成するのが望ましい。

図１３（ｂ）に示す予測モデルリポジトリは、後述する時系列予測処理で用いる予測モデルを記録する。各モデルはＩＤフィールドによって一意に特定可能である。アルゴリズムフィールドは、時系列予測モデルの構築に用いるアルゴリズムを、過去データ期間フィールドは、時系列予測処理において使用する過去データの時間的な範囲を記録する。また、予測モデルリポジトリは、これ以外にも時系列予測モデルの構築に必要なパラメタを記録することができる。

図１４は、予兆エンジン２０１で行われる、予兆検知の処理手順の一例を示す図である。

本実施例では、システムモデルをベイジアンネットワークによる確率モデルで表現する。ベイジアンネットワークでは、あるノードの値を観測したとき、他のノードがある値を取る確率を求めることができる。このような処理を確率推論と呼称する。本実施例のベイジアンネットワークを構成する各ノードは、監視対象システムを構成する業務サーバ等から収集した計測値、分散アプリケーションの性能指標である。よって、ある計測値ないし性能指標が得られれば、確率推論により他の計測値ないし性能指標がある値を取る確率を求めることができる。

この特性を予兆検知に応用するにあたって、本実施例では、時系列予測を併用する。一般に時系列予測とは、ある変数の通時的な変化を観測して得られたデータ（時系列データ）からモデルを構築し、該モデルに基づいて変数の将来の値を予測する技術である。このような技術に適用するモデル構築の手法として、例えば線形回帰、指数平滑法、ＡＲＩＭＡモデル等が知られている。

本実施例の予兆検知方式の概要は、まず時系列予測によって、ある性能指標の将来の値を得、次いでその値を入力としてベイジアンネットワークによる確率推論を行う、というものである。

図１４（ａ）に、本方式の処理手順の一例を示す。本処理は、タスク制御部２０１８が実行メッセージを受信することを契機に開始する。まず予測部２０１５は、予測プロファイルテーブル４１１に格納された基準指標をデータ記憶部２０１２から取得し（ステップＳ１４０１）、メモリに格納する（ステップＳ１４０２）。次いで、同じく予測プロファイルテーブルに記録された予測モデルと既定リードタイムに従って時系列予測処理を行う（ステップＳ１４０３）。続いて時系列予測によって得られた予測値と、予測プロファイルテーブルに格納されたシステムモデル、ターゲット指標と予測事象に従って確率推論を行う（ステップＳ１４０４）。最後に、確率推論によって得た確率を出力する（ステップＳ１４０５）。

図１４（ｂ）は、図１４（ａ）のステップＳ１４０３に対応する時系列予測の処理手順を、より詳細に示す。まず予測部は、予測プロファイルテーブルに記録された予測モデルＩＤを取得し、該ＩＤに従って、予測モデルリポジトリ４１４から該当するアルゴリズムと時系列予測処理に必要なパラメタを得る（ステップＳ１４１１）。次いで、同じく予測モデルリポジトリから、過去データ期間を取得（ステップＳ１４１２）する。取得した過去データ期間の分、基準指標の計測値を取得する（ステップＳ１４１３）。続いて予測プロファイルテーブルから、既定リードタイムを取得する（ステップＳ１４１４）。既定リードタイムとは、時系列予測処理で得られる予測値を、過去データの最終時点から何秒後の値とするかを示す値である。以上のステップで得られた、時系列予測のアルゴリズムとパラメタ、計測値、既定リードタイムを用いて、時系列予測処理を実行する（ステップＳ１４１５）。処理の結果得られた予測値を、メモリに格納する（ステップＳ１４１６）。

図１４（ｃ）は、図１４（ａ）のステップＳ１４０４に対応する確率推論の処理手順を、より詳細に示す。まず推論部は、メモリに格納された予測値を取得する（ステップＳ１４２１）。ついで、予測プロファイルテーブルに記録されたモデルＩＤを取得し、該ＩＤに従って、モデルリポジトリからシステムモデルを取得する（ステップＳ１４２２）。続いて、同じく予測プロファイルテーブルからターゲット指標と（ステップＳ１４２３）、予測事象を取得（ステップＳ１４２４）する。ターゲット指標とは、ベイジアンネットワークの確率推論において、確率を求める対象となるノードに相当し、予測事象とは、確率を求めるにあたって、該ターゲット指標がどの値を取るか、あるいはどの範囲の値をとるかの条件を記述する情報であり、典型的には閾値である値を超過するかを条件とする。例えば、ターゲット指標が分散アプリケーションの平均応答時間である場合、該ターゲット指標が３０００ミリ秒を超過することを「Ｔ＞３０００」という予測事象で表現する。そして、以上のステップで得られた、予測値、システムモデル、ターゲット指標と予測事象を用いて確率推論処理を実行する（ステップＳ１４２５）。

図１５は、予兆エンジン２０１で行われる、予兆検知の処理手順の別の一例を示す図である。

図１４では、時系列予測と確率推論を併用する処理手順を示した。システムモデルとして採用するベイジアンネットワークは、因果ネットワークという別名でも知られているように、各ノードに対応する観測データ間の因果関係の構造を表現することも可能である。この性質を活用するのが、図１５に示す処理手順である。すなわち、時系列予測の処理を省略し、取得した基準指標を入力として、システムモデルによる確率推論を行う。

図１５（ａ）に、本方式の処理手順の一例を示す。図１４（ａ）に示す処理手順から、時系列予測のステップ（ステップＳ１４０３）を除いた他は、同一の処理手順であり、予測値に代えてステップＳ１５０２でメモリに格納した基準指標を用いて確率推論を行う（ステップＳ１５０３）箇所が相違点となる。

図１５（ｂ）は、図１５（ａ）のステップＳ１５０３に対応する確率推論の処理手順を、より詳細に示す。こちらも、図１４（ｃ）に示す処理手順から、時系列予測による予測値を取得するステップ（ステップＳ１４２１）を除いた他は、同一の処理手順である。

図１６は、予兆検知結果を表示するよう設定された画面の一例を示す図である。

上記説明した予兆検知処理によって予兆サーバ１１３が出力した予測事象の発生確率は、ポータルサーバ１１５に送信され、ポータルサーバがさらに監視クライアント１１６に送信する。監視クライアントに実装されたＷｅｂブラウザ２１２は、例えば図１６に示すような画面を表示することによって、この確率を顧客サイト３０１の運用管理担当者に伝達する。

監視クライアントに実装されたＷｅｂブラウザは、コンソール１０５にクライアント画面５００を表示する。クライアント画面５００は、機能メニュー５０１、システムリスト５０２、指標リスト５０３、プロットエリア５０４を有する。機能メニュー５０１は複数のボタンを有し、例えば「リアルタイム監視」ボタンを含む。システムリスト５０２は、典型的には顧客サイトの監視対象システムと分散アプリケーションを階層構造で一覧表示し、また運用管理担当者の入力した情報に対応して、一覧表示された項目のうち特定の項目が選択状態にあることを表示する。選択状態にある項目をそれ以外の項目から弁別するために、該選択状態にある項目に下線を引く、フォントや背景色を周囲と異なったものとする等の手段を用いてもよい。指標リスト５０３は、前記選択状態にある項目に対応する監視対象システムで収集対象となっている計測値や性能指標を一覧表示し、さらにそれらのうちどの計測値や性能指標がプロットエリア５０４に表示する対象として選択されているかを表示する。

指標リスト５０３の詳細部を説明する。指標リストはテーブル様に表示されており、指標名称フィールド５０３１、状況フィールド５０３２、インターバルフィールド５０３３、予兆フィールド５０３４、予測モデルフィールド５０３５を有する。

指標名称フィールドは、監視対象システムで収集対象となっている計測値や性能指標の名称をレコードとして一覧表示し、また各レコードはチェックボックスを有する。名称は、システムプロファイルテーブルに格納された名称を用いてもよいし、運用管理担当者にとってより直観的な把握が容易な名称に変換して表示してもよい。チェックボックスが、運用管理担当者の入力に従って選択状態に遷移すると、該チェックボックスを有するレコードの計測値または性能指標の過去データを、プロットエリア５０４の左半分に時系列プロットする。

状況フィールドは、各レコードに対応する計測値や性能指標が、監視装置１１１による収集等によって蓄積サーバ１１２に蓄積されているか否かを表示する。インターバルフィールドは、計測値や性能指標を収集するインターバルの設定値を表示する。例えば図４に示すように、計測値にそれを収集したインターバルが添付されている場合はその値を使用してもよい。

予兆フィールドは、計測値や性能指標のうち、前述した予兆検知処理にて基準指標となっている指標に“α”記号、ターゲット指標となっている指標に“β”記号を各々表示する。これらの記号は、クライアント画面が表示する内容を煩雑にしないために例として採用しているものであり、任意のものを選択してよい。また、α−β記号の組は、一つの指標リストにつき一組に限定されるものではない。

予測モデルフィールドは、α記号が付されているレコードに対応する指標が、予兆検知処理の時系列予測において使用する予測モデルの名称を表示する。名称は予測モデルリポジトリ４１４に格納された名称を用いることができる。

プロットエリア５０４は、例えば横軸の左から右方向を時間の推移に設定した時系列プロットを表示する。プロットエリアの略中央にある境界線の左側に、指標リストの指標名称フィールドが有するチェックボックスが選択状態にあるレコードに対応する計測値または性能指標をプロットする。また、縦軸は少なくともターゲット指標と設定されている指標の表示に好適なスケールを左右いずれかに設定し、予測プロファイルテーブルの予測事象フィールドにて閾値として設定されている値を水平線として表示する。境界線の右側には、予測プロファイルテーブルが格納する各予兆検知処理のうち、システムリスト５０２で選択状態にある監視対象システムないし分散アプリケーションに係るものについて、そのタスクの処理結果として出力する確率を表示する。典型的には、前記境界線の位置を現時点として、該予兆検知処理の既定リードタイムに相当する距離だけ右側に離れた箇所に垂直線を表示し、前記閾値を示す水平線との交点の付近に該確率を表示する。また同じく境界線の右側には、該タスクの時系列予測処理で得られた予測値を表示する。典型的には、例えば予測モデルの構築に線形回帰を採用する場合において、基準指標に対応するプロット線と前記境界線との交点、および該予測値の両者を通過する線分を表示することで、該予測値を基準指標である計測値から時系列予測により算出したことを表現することが考えられる。

プロットエリアは、図４に示す計測値のインターバルに応じて、または図９に示すタスクリストテーブルのインターバルに応じて、あるいは表示する情報がポータルサーバから送信可能になったタイミングを契機とする等、様々な機会にその表示する内容を更新することができる。または、運用管理担当者の入力に応じて表示内容を更新したり、更新について任意のタイミングやインターバルを設定できるよう構成したりしてもよい。また、表示内容の更新はクライアント画面全体を同期して行う必要はなく、部分的に更新してもよい。

図１７は、予兆検知結果を表示するよう設定された画面の別の一例を示す図である。

図１６に示すクライアント画面は、予測プロファイルテーブルの予測事象フィールドにて、ターゲット指標がある閾値を超過する確率を求めるよう設定された予兆検知処理について、その処理結果を表示するものであった。図１７が示すのは、これとは別の予測事象として、該ターゲット指標がある上下限値で表現される特定範囲内にある確率を求めるよう設定された予兆検知処理について、その処理結果を表示するクライアント画面である。

プロットエリア５０４は、前記境界線の位置を現時点として、予兆検知処理の既定リードタイムに相当する距離だけ右側に離れた箇所に垂直線を表示する。そして、該垂直線を縦軸と見做して前記上下限値に対応する二つの点と、ターゲット指標の時系列プロットにより表示されたプロット線と境界線との交点とをそれぞれ結ぶ点線を表示し、その付近に前記確率を表示する。この点線は、運用管理担当者が前記上下限値を容易に把握できることを目的として表示するものであり、この目的を達成するのに好適な任意の方法を採用してよい。クライアント画面のこれ以外の部分は、図１６に示す例と同様である。

図１８は、予測モデルを選択する画面の一例を示す図である。

予兆検知処理の時系列予測で使用する予測モデルは、予測プロファイルテーブルに格納された予兆検知処理毎に各々設定することができる。運用管理担当者がこの設定を行うことができるよう、指標リストのうち基準指標となっているレコードについては、予測モデルフィールドが例えばドロップダウンリストとして構成されている。

図１８は、指標リスト５０３のうち予兆フィールド５０３４が“α”を表示しているレコードについて、予測モデルフィールド５０３５がドロップダウンリストとして選択可能状態にある例を示す。該ドロップダウンリストは、予測モデルリポジトリ４１４に記録されている各予測モデルを選択肢として表示することができる。また、予兆エンジンの予測部２０１５が使用可能な予測モデルであれば任意のものを併せて選択肢として表示することができる。

図１９は、システムモデルを選択する画面の一例を示す図である。

モデルリポジトリ４１３は、ある監視対象システムのモデルを複数含みうる。そこで、予測プロファイルテーブル４１１のモデルＩＤフィールドにどのモデルＩＤを格納するか、運用管理担当者が監視クライアント１１６から指定する手段を提供する。システムモデルの選択は、例えば運用管理担当者が機能メニュー５０１の有する「ホーム」ボタンを選択押下し、さらにシステムリスト５０２で管理対象システムを選択したことを契機として、設定メニュー５０５を表示することで実施可能になる。

図１９（ａ）は、監視対象システムのシステムモデルを選択する画面を示す。

クライアント画面５００は、設定メニュー５０５を有する。設定メニューは「構成設定」ボタンを有し、運用管理担当者が該ボタンを選択押下すると、クライアント画面は構成設定フレーム５０６を表示する。構成設定フレームは、使用モデルフィールド５０６１、使用モデル指定ドロップダウンリスト５０６２、モデル登録ボタン５０６３を有する。使用モデルフィールドは、システムリストにて選択状態にある監視対象システムの予兆検知処理において、既定で使用されるシステムモデルの名称を表示する。運用管理担当者が使用モデルフィールドの有するボタンを押下すると、クライアント画面は使用モデル指定ドロップダウンリスト５０６２を表示する。該使用モデル指定ドロップダウンリストは、モデルリポジトリに格納されている該監視対象システムのシステムモデルのモデル名を一覧表示する。運用管理担当者が該リストのうち一つを選択することを契機に、選択されたシステムモデルを使用モデルフィールドに表示する。しかる後に、例えばＯＫボタン（非図示）を運用管理担当者が選択押下することを契機に、該選択されたシステムモデルを既定で使用するシステムモデルとして設定する。

運用管理担当者がモデル登録ボタン５０６３を選択押下すると、例えばファイル選択ダイアログ（非図示）を表示し、システムモデルに相当する情報を含むファイルを予兆サーバにアップロードするよう促すことができる。アップロードされたシステムモデルは、モデルリポジトリに格納され、前記使用モデル指定ドロップダウンリストの一覧表示に含まれる。

図１９（ｂ）は、予兆検知処理が使用するシステムモデルを選択する画面を示す。

クライアント画面５００は、設定メニュー５０５を有する。設定メニューは「予兆検知設定」ボタンを有し、運用管理担当者が該ボタンを選択押下すると、クライアント画面は予兆検知設定フレーム５０７を表示する。予兆検知設定フレームは、予測プロファイル名フィールド５０７１、使用モデルフィールド５０７２、使用モデル指定ドロップダウンリスト５０７３を有する。予測プロファイル名フィールドは、予測プロファイルテーブルに格納された予測プロファイルのうち一つを表示できる。また、ドロップダウンリストも兼ねており、運用管理担当者による選択操作を契機として、表示する予測プロファイルを変更する。表示する予測プロファイルを、選択された予測プロファイルと呼ぶ。使用モデルフィールドは、選択された予測プロファイルのモデルＩＤを表示する。運用管理担当者が使用モデルフィールドの有するボタンを押下すると、クライアント画面は使用モデル指定ドロップダウンリスト５０７３を表示する。該使用モデル指定ドロップダウンリストは、モデルリポジトリに格納されているシステムモデルのうち、選択された予測プロファイルのシステム名フィールドに対応するシステムのシステムモデルを一覧表示する。運用管理担当者が該リストのうち一つを選択することを契機に、選択されたシステムモデルを使用モデルフィールドに表示する。しかる後に、例えばＯＫボタン（非図示）を運用管理担当者が選択押下することを契機に、該選択されたシステムモデルのモデルＩＤを、該選択された予測プロファイルのモデルＩＤフィールドに設定する。

図２０は、負荷生成装置が出力するテーブルの一例を示す図である。

前述のモデル生成処理を実行するためには、計測値と性能指標を連結したテーブルが必要である。計測値については、業務サーバに実装されたＯＳと監視装置により収集するのは難しくはないが、性能指標の入手はそれほど容易ではない。そのため、分散アプリケーションに対して人工的に処理負荷を生成するよう構成された負荷生成装置を用い、その装置が出力するログを加工することで、性能指標を得る方法を必要に応じて採用してもよい。負荷生成装置は、典型的には情報処理装置に、負荷生成を行うプログラムをユーザプロセスとして実装するが、独立した装置でもよい。

テーブル４０６は、こうした負荷生成装置が分散アプリケーションに対して発行したリクエストのログを示すテーブルの一例である。リクエストログは、スレッドＩＤフィールド、応答時間フィールド、経過時間フィールド、タイムスタンプフィールドを含む。

図２１は、負荷生成装置が出力するリクエストログを性能指標に変換する処理手順の一例を示す図である。

まずスライス幅を取得する（Ｓ２１０１）。スライス幅とは、リクエストログの変換処理において単位とする時間的な幅であり、典型的には図４に示すような計測値のインターバルと統一するのが好適である。次いで、リクエストログをスライス単位に分割する（Ｓ２１０２）。以下の処理は、分割された全てのスライス単位に行う（Ｓ２１０３）。まず一意なスレッドＩＤをカウントし（Ｓ２１０４）、同時接続ユーザ数を得る。次いでレコード数をスライス幅で除算し（Ｓ２１０５）、リクエスト処理スループットを得る。そして応答時間の平均値を算出（Ｓ２１０６）し、平均応答時間を得る。以上の処理により算出された、同時接続ユーザ数、リクエスト処理スループット、平均応答時間は、分散アプリケーションの性能指標としてモデル生成処理で使用することができる。

本実施例では、同時接続ユーザ数、リクエスト処理スループット、平均応答時間を算出しているが、監視対象システムの特性に応じて他の指標を算出してもよい。こうした変換処理は、負荷生成装置内で行ってもよいし、リクエストログを転送した上でサービスサイト内のサーバが実行してもよい。

以上、第一の実施例では、単一のサービスサイトが複数の顧客サイトにサービスを提供する、いわゆるマルチテナントの構成について説明した。これによって顧客は、顧客サイトにてプロセッサ資源を用意せずにベイジアンネットワークによる予兆検知結果を得ることができる。

次に、本発明を適用した第二の実施例を説明する。

第一の実施例ではベイジアンネットワークによるシステムモデルと時系列予測を併用する予兆検知システムについて説明した。この方式は、生成するモデルには、監視対象システムのありうべき状態を網羅的に含むことを前提としている。しかしながら、現実のシステム運用においては、モデル生成時に用いた計測値には含まれない状態が顕現することもあろう。

そこで本実施例では、このような事態に対応するために、クラスター分析手法を併用するよう構成された予兆検知システムを説明する。クラスター分析は、多次元のデータをクラスターという単位に分類するデータ分析手法の一つであり、例えばＫ平均法といったアルゴリズムが知られている。この手法により、既知のクラスターに分類されない計測値が現れたことを検出することができる。

すなわち、まず監視対象システムが正常に稼働している時に収集した計測値を、クラスター分析によって事前に分類しておく。次いで、システム運用中に逐次取得できる計測値に対して、この事前の分析で生成された各クラスターの基準点との距離を算出し、その距離が閾値を超過するとシステムに何らかの異常が発生していると判定する、という方式である。この距離は、いわばシステムの異常度に相当するものである。

以下、基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。

図２２は、予兆エンジン２０１で行われる、正常時クラスター生成の処理手順の一例を示す図である。

予兆サーバは、計測値を取得し（ステップＳ２２０１）、これをメモリに格納する（ステップＳ２２０２）。次いでこの計測値を対象にクラスター分析を実行する（ステップＳ２２０３）。結果、生成された各クラスターの基準点群を、クラスター分類器としてメモリまたはストレージに格納する（ステップＳ２２０４）。

図２３は、予兆エンジン２０１で行われる、異常度算出処理の一例を示す図である。

予兆サーバは、計測値を取得し（ステップＳ２３０１）、これをメモリに格納する（ステップＳ２３０２）。次いでクラスター分類器を取得し（ステップＳ２３０３）、計測値とクラスター分類器からシステム異常度を算出する（ステップＳ２３０４）。そして得られたシステム異常度を出力する（ステップＳ２３０５）。

図２４（ａ）は、システム異常度を表示するよう設定された画面の一例を示す図である。

クライアント画面５００の指標リスト５０３は指標名称フィールドを有し、各レコードはチェックボックスを有する。システム異常度に対応するレコードのチェックボックスが、運用管理担当者の入力に従って選択状態に遷移すると、過去に算出された該システム異常度のデータを、プロットエリア５０４の略中央に表示する境界線の左半分に時系列プロットする。クライアント画面のこれ以外の部分は、第一の実施例と同様である。

図２４（ｂ）は、システム異常度を表示するよう設定された画面の別の一例を示す図である。

クライアント画面５００の指標リスト５０３に表示された、システム異常度に対応するレコードのチェックボックスのみが選択状態にあるとき、プロットエリア５０４に該システム異常度のデータのみを時系列プロットする。また、前記システム異常度の閾値として設定されている値を水平線として表示する。クライアント画面のこれ以外の部分は、図２４（ａ）に示す例と同様である。

次に、本発明を適用した第三の実施例を説明する。第一の実施例では、単一のサービスサイトが複数の顧客サイトにサービスを提供する、いわゆるマルチテナントの構成について説明した。この場合、複数の顧客サイト、ないし顧客システムに対しサービスサイトにとって同一の優先度で予兆検知処理が実行される。すなわち予兆検知処理の実行は、予測プロファイルテーブル４１１とタスクリストテーブル４１２によって制御されており、タスクリストテーブルに記録されているタスクは特に優先度の区別なく実行されるよう構成される。

しかしながら、特に予兆サーバでの予兆検知処理はプロセッサ資源を消費し、さらに処理に時間的制約が存在する一方、サービスに供することのできるハードウェア資源には限度があるため、複数の予兆検知処理に優先度を設定することは有用である。

そこで本実施例では、このマルチテナント構成においてタスクに優先度を設定し、これに従って処理を実行する例を説明する。基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。

図２５は、タスクリストテーブルの一例を示す図である。

タスクリストテーブル４１５は、図９に示したタスクリストテーブル４１２の各フィールドに加えて、優先度フィールドを有する。優先度フィールドは、予兆エンジン１１１３が各タスクの実行に際して設定する優先度を格納する。スケジューラ２０２は、タスクリストテーブルに格納されたタスクのうち実行フラグフィールドに“Ｙ”と指定されているタスクについて実行メッセージを送信する際に、該メッセージに優先度を含める。予兆エンジンのタスク制御部２０１８は、受信した実行メッセージが含む優先度を基に、優先度を設定してタスクを実行する。優先度を指定する方法として、例えばＯＳの備える優先度設定ＡＰＩを使用する方法がある。

タスクリストテーブルの優先度フィールドに値を設定する方法として、例えば予測プロファイルテーブル４１１の既定リードタイムフィールドの値を用いる方法がある。これは、既定リードタイムが長いタスクほど、予兆検知処理の出力結果が運用管理担当者にとって有用である期間が長いと想定されることを利用し、既定リードタイムが長いタスクの優先度を下降させる方法である。

またタスクリストテーブルの優先度フィールドに値を設定する別の方法として、例えばモデルリポジトリ４１３に格納されているグラフ構造が含むノード数が多いものほど優先度を上昇させるという方法がある。これは、多くのノードを含むベイジアンネットワークであるほど、確率推論処理により多くの計算資源を要するという点に注目した方法である。

またタスクリストテーブルの優先度フィールドに値を設定する別の方法として、例えばシステムプロファイルテーブル４１０に格納されている計測値の項目の数が多いシステムほど、該システムに係る予兆検知処理の優先度を上昇させるという方法がある。これは、モデルリポジトリに格納されているグラフ構造のノード数に従って優先度を設定するのと同様の理由による。

またタスクリストテーブルの優先度フィールドに値を設定する別の方法として、例えば基準指標に設定されている計測値ないし性能指標について、現時点を基準として過去一定期間の値を取得し、大きな変化が認められるものほど優先度を上昇させるという方法がある。変化の度合いを定量化するために、該計測値ないし性能指標の過去一定期間の値を時系列データと見做し、例えば自己共分散を算出する、ＣＵＳＵＭアルゴリズムのような変化点検出方法を用いる、等の方法がある。

上記したいずれの方法であっても、タスクリストテーブルと他のテーブルとの関連付けは、各レコードの含むＩＤによって容易に行うことができるであろう。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ＨＤＤ、ＳＳＤ等の記憶装置、またはＳＤカード、ＤＶＤ−ＲＯＭ等の記憶媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１００…情報処理装置、 １１０…業務サーバ、 １１１…監視装置、 １１２…蓄積サーバ、 １１３…予兆サーバ、 １１４…診断サーバ、 １１５…ポータルサーバ、 １１６…監視クライアント、 ２０１…予兆エンジン、 ２０２…スケジューラ、 ２１０…アプリケーションプログラム、 ３０１…顧客サイト、 ３０２…サービスサイト

Claims (20)

1. １以上の計算機から構成され、複数の監視対象システムの予兆検知を行うサービスシステムであって、前記１以上の計算機は、
   （１）前記監視対象システムから、複数の指標について計測値を受信し、
   （２）前記複数の指標の一部である基準指標について、受信した計測値から将来の計測値を予測するための予測モデルを複数の予測モデルから指定し、
   （３）前記指定した予測モデルに基づいて、前記基準指標の予測値を予測し、
   （４）前記基準指標と、前記複数の指標の一部だが前記基準指標と異なる指標であるターゲット指標と、を対象としたベイジアンネットワークを生成又は更新し、
   （５）前記基準指標の予測値と、前記ベイジアンネットワークと、に基づいて前記ターゲット指標の計測値が所定の値または値の範囲となる確率を算出する、
   サービスシステム。
2. 請求項１記載のサービスシステムであって、
   前記１以上の計算機は、受信済みの前記基準指標の計測値、及び前記ターゲット指標の計測値に基づいて前記ベイジアンネットワークを生成する、
   サービスシステム。
3. 請求項１乃至２記載のサービスシステムであって、
   前記計測値は、前記監視対象システムが実行するアプリケーションプログラムの実行状況を数値化したデータである、
   サービスシステム。
4. 請求項１乃至３記載のサービスシステムであって、前記１以上の計算機は、
   （６）前記複数の監視対象システムそれぞれ毎に、前記複数の指標から前記基準指標を指定する入力を受信し、
   （７）監視対象システムの識別子と、指定された予測モデルと、前記基準指標と、の組で管理することで、監視対象システム毎に異なる指標を基準指標と設定し得る、
   サービスシステム。
5. 請求項１乃至４記載のサービスシステムであって、前記１以上の計算機は、
   （２ａ）前記予測モデルの指定のための入力を受信する、
   サービスシステム。
6. 請求項１乃至５記載のサービスシステムであって、
   前記１以上の計算機は、
   （４ａ）複数のベイジアンネットワークを生成、前記１以上の計算機のメモリ又はストレージに記憶し、
   （８）（５）の確率算出のために用いるベイジアンネットワークを、前記複数のベイジアンネットワークから指定する入力を受信する、
   サービスシステム。
7. 請求項１乃至６記載のサービスシステムであって、前記１以上の計算機は、
   （９）前記確率算出に用いる前記所定の値または値の範囲を指定する入力を受信する、
   サービスシステム。
8. 請求項１乃至７記載のサービスシステムであって、
   前記１以上の計算機は、（４）及び（５）の処理についての実行優先度を制御する、
   サービスシステム。
9. 請求項８記載のサービスシステムであって、
   前記実行優先度は、異なる監視対象システム同士でも有効である、
   サービスシステム。
10. 請求項８又は９記載のサービスシステムであって、
    前記実行優先度は、
    前記確率算出の対象時刻、
    監視対象システムの指標の数、
    過去の計測値の変化の度合い、
    の少なくとも１つに基づいて制御する、
    サービスシステム。
11. 複数の監視対象システムの予兆検知を行うサービスシステムを構成する１以上の計算機で実行されるプログラムであって、
    （１）前記監視対象システムから、複数の指標について計測値を受信し、
    （２）前記複数の指標の一部である基準指標について、受信した計測値から将来の計測値を予測するための予測モデルを複数の予測モデルから指定し、
    （３）前記指定した予測モデルに基づいて、前記基準指標の予測値を予測し、
    （４）前記基準指標と、前記複数の指標の一部だが前記基準指標と異なる指標であるターゲット指標と、を対象としたベイジアンネットワークを生成又は更新し、
    （５）前記基準指標の予測値と、前記ベイジアンネットワークと、に基づいて前記ターゲット指標の計測値が所定の値または値の範囲となる確率を算出する、
    プログラム。
12. 請求項１１記載のプログラムであって、
    受信済みの前記基準指標の計測値、及び前記ターゲット指標の計測値に基づいて前記ベイジアンネットワークを生成する、
    プログラム。
13. 請求項１１乃至１２記載のプログラムであって、
    前記計測値は、前記監視対象システムが実行するアプリケーションプログラムの実行状況を数値化したデータである、
    プログラム。
14. 請求項１１乃至１３記載のプログラムであって、
    （６）前記複数の監視対象システムそれぞれ毎に、前記複数の指標から前記基準指標を指定する入力を受信し、
    （７）監視対象システムの識別子と、指定された予測モデルと、前記基準指標と、の組で管理することで、監視対象システム毎に異なる指標を基準指標と設定し得る、
    プログラム。
15. 請求項１１乃至１４記載のプログラムであって、
    （２ａ）前記予測モデルの指定のための入力を受信する、
    プログラム。
16. 請求項１１乃至１５記載のプログラムであって、
    （４ａ）複数のベイジアンネットワークを生成、前記１以上の計算機のメモリ又はストレージに記憶し、
    （８）（５）の確率算出のために用いるベイジアンネットワークを、前記複数のベイジアンネットワークから指定する入力を受信する、
    プログラム。
17. 請求項１１乃至１６記載のプログラムであって、
    （９）前記確率算出に用いる前記所定の値または値の範囲を指定する入力を受信する、
    プログラム。
18. 請求項１１乃至１７記載のプログラムであって、
    （４）及び（５）の処理についての実行優先度を制御する、
    プログラム。
19. 請求項１８記載のプログラムであって、
    前記実行優先度は、異なる監視対象システム同士でも有効である、
    プログラム。
20. 請求項１８又は１９記載のプログラムであって、
    前記実行優先度は、
    前記確率算出の対象時刻、
    監視対象システムの指標の数、
    過去の計測値の変化の度合い、
    の少なくとも１つに基づいて制御する、
    プログラム。

Images