(57)【要約】  大量のデータの高速検索に適合された特別なデータ構造に収集及び保存するシステム。性能メトリックデータは１つの例である。性能メトリックデータは、時系列測定値として記録され、ユニコードに変換され、１日につき１つのディレクトリを有し、その日に収集された全てのメトリックデータを保存する特別なデータ構造に配置される。性能メトリックデータは、データの収集対象となるマシン上で動作する１つ又は複数のプローブによって収集される。性能メトリックデータは、何らかのデータパスを介してサーバーに送信される前に圧縮される。解析が実行されるサーバーにおけるデータ構造は、リソースタイプごとにサブディレクトリを有する。各サブディレクトリは、属性グループにおける属性について測定された性能メトリックデータ値のテキストファイルを含み、この属性グループはこのテキストファイルが担当している。各属性は、自身のセクションを有し、性能メトリックデータ値は、ユニコードの１６進数でカンマ区切りのリストとして、時系列に記録される。性能メトリックデータの解析は、正規表現を用いて行われる。速度のために、キャッシュメモリが用いられる。クエリスクリーン上でユーザーによって指定された開始時間及び終了時間外の性能メトリックデータは、正規表現が適用される前に除外される。
2016521402.tif 000002
【特許請求の範囲】
【請求項１】
シーケンスデータを送信するプローブから、前記シーケンスデータを受信し、
前記シーケンスデータを、正規表現を用いて検索可能な符号に符号化し、前記符号化されたシーケンスデータを保存する、
ことを特徴とする計算機上で動作するプロセス。
【請求項２】
前記シーケンスデータの符号化方式として、符号の全順序が定義されたものを用いる、
ことを特徴とする請求項１記載のプロセス。
【請求項３】
前記シーケンスデータの前記符号化方式として、前記シーケンスデータからUnicode文字への変換を用いる、
ことを特徴とする請求項２記載のプロセス。
【請求項４】
前記シーケンスデータは、時系列データである、
ことを特徴とする請求項１記載のプロセス。
【請求項５】
前記シーケンスデータの検索を行う際、シーケンスデータのデータ列に対してパターンマッチングを行う、
ことを特徴とする計算機上で動作するプロセス。
【請求項６】
前記シーケンスデータを検索する際、前記シーケンスデータのデルタ値に対してパターンマッチングを行う、
ことを特徴とする請求項５記載のプロセス。
【請求項７】
前記パターンマッチングにおいて、正規表現を用いる、
ことを特徴とする請求項５記載のプロセス。
【請求項８】
前記パターンマッチングにおいて、正規表現を用いる、
ことを特徴とする請求項６記載のプロセス。
【請求項９】
事前定義された構文規則を用いることで、複数のシーケンスデータに対して異なるデータ列のパターンをマッチングさせて検索する、
ことを特徴とする請求項７記載のプロセス。
【請求項１０】
前記事前定義された構文規則として、検索条件を指定するための構文を部分構文に分割する分割記法、及び前記分割した部分構文を順番に評価していく際に用いる評価順序を有し、前記評価順序にしたがって前記各部分構文を評価していくことで、前記検索条件を満たす時間の範囲を絞り込んでいく、
ことを特徴とする請求項４記載のプロセス。
【請求項１１】
前記事前定義された構文規則として、検索条件を指定するための構文を複数の部分構文に分割する分割記法、及び前記分割した部分構文を順番に評価していく際に用いる評価順序を有し、前記評価順序にしたがって前記各部分構文を評価していくことで、前記検索条件を満たす時間の範囲を絞り込んでいく、
ことを特徴とする請求項９記載のプロセス。
【請求項１２】
前記事前定義された構文規則として、前記部分構文間に木構造状の関係を規定するためのブロック定義記法を有し、前記木構造状の関係のrootからleafに向かって順に前記部分構文を評価していくことで、複数通りの絞り込みに基づく検索を同時に行う、
ことを特徴とする請求項１０記載のプロセス。
【請求項１３】
前記事前定義された構文規則として、複数の時系列データ間の関係性を定義、削除するための記法を有し、前記関連性が定義された前記複数の時系列データ間を行き来する形で前記絞り込みを行う、
ことを特徴とする請求項１０記載のプロセス。
【請求項１４】
前記事前定義された構文規則として、部分構文による評価結果を変数へ束縛するための記法と、前記変数に束縛された前記評価結果を他の部分構文内で用いるための記法とを有し、前記部分構文の前記評価結果を再利用する、
ことを特徴とする請求項１０記載のプロセス。
【請求項１５】
前記事前定義された構文規則は、複数の符号化された値とマッチする条件を記述するための記法であり、値の範囲検索ができる、
ことを特徴とする請求項８記載のプロセス。
【請求項１６】
前記事前定義された構文規則は、部分構文内に複数の条件を記述し、前記複数の条件間の論理関係を記述するための記法を有し、前記絞り込み時に異なる基準、異なる時系列データを用いることができる、
ことを特徴とする請求項１０記載のプロセス。
【請求項１７】
符号化時のシーケンスデータの値と符号との間のマッピング方式として、小さいデータサイズを有する前記符号は、高発生頻度を有するデータの前記値にマッピングされる、
ことを特徴とする請求項１記載のプロセス。
【請求項１８】
前記シーケンスデータの前記値と前記符号との間のマッピングは、前記シーケンスデータのサンプリングインデックスの値に基づいて決定される、
ことを特徴とする請求項１７記載のプロセス。
【請求項１９】
前記シーケンスデータの値と前記符号との間の前記マッピングは、シーケンスデータの種類に基づいて決定される、
ことを特徴とする請求項１７記載のプロセス。
【請求項２０】
前記シーケンスデータの前記値と前記符号との間の前記マッピング時における、シーケンスデータの前記値の量子化の幅は、必要な解像度に基づいてユーザーによって決定される、
ことを特徴とする請求項１７記載のプロセス。
【請求項２１】
監視される計算機上のリソースを監視し、前記監視の結果として得られる各種属性値を時系列データとして送信するように構成又はプログラムされたプローブから、前記時系列データを受信するようにプログラムされ、
前記時系列データを、前記時系列データが収集された日付及び前記時系列データの前記属性値が関連する前記リソースの各々のインデックスと合わせて、データの時間スライスとして保存するようにプログラムされる、
ことを特徴とするデータ保存装置。
【請求項２２】
前記時系列データが収集された前記日付によって前記時系列データを１つの軸に分類し、前記時系列データをリソースによってもう１方の軸に分類する階層的なデータ構造を作成する保存方法を用いて、前記時系列データを保存するように更にプログラムされる、
ことを特徴とする請求項２１記載のデータ保存装置。
【請求項２３】
時系列データの前記各時間スライスを前記データ保存装置のファイルシステムの１つのディレクトリにマッピングすることによって、前記階層的なデータ構造を作成するようにプログラムされる、
ことを特徴とする請求項２２記載のデータ保存装置。
【請求項２４】
前記時系列データを前記保存する際、前記プローブによって前記時系列データが収集された日付及び前記時系列データの収集元のリソースの識別子に基づいてキーを作成するようにプログラムされ、前記キーと前記時系列データとを紐付けて保存するように更にプログラムされる、
ことを特徴とする請求項２１記載のデータ保存装置。
【請求項２５】
前記時系列データを前記保存する際、前記時系列データを属性ごとにまとめるように更にプログラムされる、
ことを特徴とする請求項２１記載のデータ保存装置。
【請求項２６】
前記時系列データを前記保存する際、属性ごと、あるいは属性の総数に比べて十分少ない数の属性集合ごとにファイルを作成するようにプログラムされる、
ことを特徴とする請求項２３記載のデータ保存装置。
【請求項２７】
前記時系列データを前記保存する際、属性ごと、あるいは属性の総数に比べて十分少ない数の属性集合ごとにファイルを作成するようにプログラムされる、
ことを特徴とする請求項２５記載のデータ保存装置。
【請求項２８】
前記時系列データを前記保存する際、事前に指定されたパターンに基づいてパターンマッチング検索を行い、前記パターンにマッチした時系列データの保存位置への参照を作成し、同時に前記時系列データ及び前記参照を保存するように更にプログラムされる、
ことを特徴とする請求項２１記載のデータ保存装置。
【請求項２９】
前記時系列データを前記保存する際、前記時系列データの事前に指定されたパターンを検索可能な形で圧縮するように更にプログラムされる、
ことを特徴とする請求項２１に記載のデータ保存装置。
【請求項３０】
検索によく使用されるデータパターンを前記クエリとして用いるように更にプログラムされる、
ことを特徴とする請求項２８に記載のデータ保存装置。
【請求項３１】
検索によく使用されるデータパターンを前記クエリとして用いるように更にプログラムされる、
ことを特徴とする請求項２９に記載のデータ保存装置。
【請求項３２】
前記時系列データを前記保存する際、事前に定義した前記時系列データの値の集合に対して統計情報を求め、前記時系列データ及び前記統計情報を同時に保存する、
ことを特徴とする請求項２１記載のデータ保存装置。
【発明の詳細な説明】
【背景技術】
【０００１】
大量の性能データが生成されるＩＴシステム及び他のシステムの管理では、大量の性能データを収集し、編成し、記憶し、高速に検索して、管理問題を評価することが可能である必要がある。例えば、サーバー仮想化システムは、同時に動作している多くの仮想サーバーを有する。これらの仮想サーバーの管理は、仮想サーバーについてのデータを収集し、編成し、記憶し、解析するツールが作業に上手く適合されていないため、困難である。
【０００２】
仮想サーバーであれ他のサーバーであれ、サーバーを遠隔監視する従来技術による一方法は、遠隔のマシンと監視されるサーバーとの間に仮想私設ネットワークを確立することである。次に、監視に使用される遠隔のマシンは、監視されるサーバーに接続し、性能データを観測することができる。この方法の利点は、監視されるサーバーのハードウェア又はソフトウェアを変更する必要がないことである。この方法の欠点は、仮想私設ネットワークがデータを送信する際に経由する信頼性の高い広帯域幅接続が必要なことである。監視されるサーバーが、豊富なグラフィックスを生成するソフトウェアを実行する場合、帯域幅要件は高くなる。これは、特に、監視されるサーバーが、海外、例えば、インド又は中国のデータセンターにあり、監視するコンピューターが米国又は監視されるサーバーから遠く離れたどこかにある場合に問題であり、高価であり得る。
【０００３】
遠隔のサーバーの性能を監視する別の方法は、その遠隔のサーバー上にエージェントプログラムを配置することであり、このエージェントプログラムは、性能データを収集し、収集されたデータを遠隔監視するサーバーに転送する。この方法も、監視されるサーバーと監視するサーバーとの間に高帯域幅データリンクが必要であるという問題点を有する。この高帯域幅要件は、サポートされ監視され得る遠隔のサーバーの数が少数であることを意味する。拡張性も問題である。
【０００４】
他の非ＩＴシステムは、様々な問題を評価するために収集し、編成し、記憶し、検索する必要がある大量のデータを生成する。例えば、橋は、応力読み取り値及び歪み読み取り値を常時生成する何千もの応力センサー及び歪みセンサーを取り付けられている場合がある。技術者によるこれらの読み取り値の評価は、安全問題の管理及び新しい橋の設計又は既存の橋の改造に重要である。
【０００５】
性能データが収集されると、巨大な量の性能データがある場合、パターンについてのデータ解析が問題である。性能ツール及びイベントログツール等の従来技術によるシステムは、リレーショナルデータベース（データセットに見られる共通の特徴が一致するデータを記憶するテーブル）を使用して、収集されたデータを記憶する。これらはデータウェアハウス技法である。ＳＱＬクエリを使用して、リレーショナルデータベース内の時系列性能データのテーブルを検索する。
【０００６】
幾つかの制限が、リレーショナルデータベース及びＳＱＬクエリを使用することから生じる。第１に、新しいインデックスが計算される際、既存のデータの他の全ての行に影響が波及する。別の問題点は、１つ若しくは複数のサーバー又は他のリソースの複数の属性に関する分刻みで収集された性能メトリックデータを記憶するために必要な記憶量である。性能データをリレーショナルデータベースに記憶することは、記憶すべきデータ量が大きい場合に大きな商用データベースが必要であり得るため、記憶、及び検索できるようにインデックスを付けての記憶の両方で、時間のみならず、金銭でもオーバーヘッドコストを生じさせる。
【０００７】
さらに、テーブルからのキー列を使用して複数のテーブルにわたる行を結合する場合、ＳＱＬクエリは効率的である。しかし、一連の隣接する行中の列の値のパターンをチェックすることが必要である場合、ＳＱＬクエリは良好でない。これは、所望の情報をプログラミングで抽出する「ストアドプロシージャ」の形態でのカスタムプログラミングを必要とする。これは、パターン検索が必要な都度、カスタムプログラムを書く必要があり、面倒であり、時間がかかり、かつ高価である。検索されるパターンが複雑になると、ストアドプロシージャプログラムの複雑性もより高くなる。
【０００８】
パターンを検索する他の方法は、Ｍ−１回、テーブルを自己結合することと、複雑な結合句を用いることとを必要とする。これは、結合の数が２又は３を超えると非実用的になる。
【０００９】
上述したように、問題は、性能データ量が大きくなるにつれて悪化する。これは、例えば、監視される多数のサーバーの様々な性能特徴を監視する多数のセンサー又は多数のエージェントから分ごとに性能データを受信する場合に生じ得る。例えば、数年分のデータを記憶する必要がある場合も、データセットは非常に大きくなり得る。大量のデータは、Ｏｒａｃｌｅ等の高価、複雑で強力な商用データベースを必要とする。
【００１０】
データベースを使用しない性能メトリックデータの解析を行う少なくとも１つの従来技術による方法がある。これはＨａｄｏｏｐと呼ばれる技術により普及した。この従来技術による方法では、データはファイルシステムに記憶され、操作される。Ｈａｄｏｏｐに基づくアルゴリズムの主目標は、潜在的に異なるマシン上のデータ値を互いに独立して処理でき、それにより、手法に拡張性をもたらすように、データセットを分けることである。Ｈａｄｏｏｐ技法のリファレンスは、データの処理に使用される実際のプロセスについて曖昧である。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
したがって、より多くのセンサー又はサーバーを所与の帯域幅のデータリンクで遠隔監視できるように、収集される性能データの量を低減する装置及び方法に対する必要性が生じている。リレーショナルデータベースを使用せずにデータを編成し記憶するとともに、ストアドプロシージャプログラムを書く必要も、テーブル結合を行い複雑な結合句を書く必要もなくパターンについてデータを検索可能であることも必要とされている。
【図面の簡単な説明】
【００１２】
【図１】性能データを編成し、記憶し、検索する本明細書に記載のプロセスを実行することができる一般的なサーバーのブロック図を示す図である。
【図２】性能が遠隔監視されているリソースの１日の性能データを記憶するディレクトリ構造の例を示す図である。
【図３】２つの属性グループをそれぞれ有する３つの異なるリソースの３つの異なる日の性能メトリックデータを記憶する個別のディレクトリを含むファイルシステムの別の例を示す図である。
【図４】プローブにより収集されたデータ例のディレクトリ構造の図である。
【図５】監視サーバーが実行する、プローブデータを受信し、検索及び解析のためにディレクトリ構造に記憶する（正：store）高レベルプロセスのフローチャートである。
【図６】一般的な正規表現クエリのシンタックスを説明するために使用される正規表現のテンプレートである。
【図７】クエリ要求ハンドラーモジュールの一実施形態のフローチャートである。
【図８Ａ】プローブデータインポーターの処理のフローチャートである。
【図８Ｂ】プローブデータインポーターの処理のフローチャートである。
【図８Ｃ】プローブデータインポーターの処理のフローチャートである。
【図９Ａ】システム内のモジュールの図である。
【図９Ｂ】ＮＲＤＢアクセスマネージャーモジュールの処理のフローチャートである。
【図１０】性能メトリックデータ解析のクエリ要求処理が行われ、ＮＲＤＢが性能メトリックデータ及び構成データを記憶するＭｅｇｈａと呼ばれる中央サーバー内の主な機能モジュールを含む全体システムの一実施形態のブロック図である。
【図１１】クエリ要求プロセッサの一実施形態による処理のフローチャートである。
【図１２】時系列データの例である。
【図１３】評価の処理のフローチャートである。
【図１４】検索クエリの構文の例である。
【図１５】処理のフローチャートである。
【図１６】処理のフローチャートである。
【図１７】処理のフローチャートである。
【図１８】処理のフローチャートである。
【図１９】処理のフローチャートである。
【図２０】処理のフローチャートである。
【図２１】処理のフローチャートである。
【図２２】パターンマッチングを説明する図である。
【図２３】処理のフローチャートである。
【図２４】パターンマッチングを説明する図である。
【図２５】処理のフローチャートである。
【図２６】時間スライスを説明する図である。
【図２７】処理のフローチャートである。
【発明を実施するための形態】
【００１３】
リレーショナルデータベースではなく検索技法を使用して、データを記憶し編成する基盤性能データ解析（及び他の大量の性能データ解析）のための装置及びプロセスが本明細書に開示される。データは、特別なフォルダー及びディレクトリ構造に記憶され、１日分の性能データに１つのディレクトリがある。これにより、より高速にデータを収集し、処理し、記憶することができる。ディレクトリに対応する日にＩＴ環境内の１つ若しくは複数のリソース又は何らかの他の環境内の１つ若しくは複数のセンサーから収集された全ての性能データは、そのディレクトリ内のファイルに記憶される。リソースごとにサブディレクトリがあり、ディレクトリ名がそのリソースのシグネチャである。一属性グループにつき１つのファイルがある。各属性ファイルは、グループ内にあると定義された属性ごとに１つずつ、Ｎ個のセクションを有する。各セクションはＭ個の値を有し、Ｍ個の値は、リソースに対応する日全体のその属性の時系列値全体を含む。
【００１４】
結果として、収集された全ての性能データはパターンとして記憶され、パターンは多くのソースからのデータであり、ソートされて、上述した特別なディレクトリ構造に時系列で記憶され、したがって、特定の日の全てのソースからの全てのデータは、１つのディレクトリ構造に記憶される。このデータ構造では、一方の軸として時間、他方の軸として各データ要素を用いてデータセットを検索することができる。
【００１５】
属性値はバンド値又はデルタ値のいずれかとして記憶される。特定の日の特定の読み取りの属性の各値は、Ｊａｖａ  ＵＴＦ−８符号化文字列として記憶され、各値は１つのＵｎｉｃｏｄｅ文字で符号化される。換言すれば、各性能メトリック値の数値はＪａｖａ  ＵＴＦ−８符号化文字列の文字に変換される。これにより、シンタックスが既知であり、形式言語の形態を含む標準の正規表現を使用しての検索が可能になる。シンタックスの様々な要素を使用して、パターンについて性能データを通じて検索する検索クエリを構築することができる。正規表現は数値ではなくテキストのみを検索することができ、これが、性能メトリック読み取り値又は性能メトリック値が、記憶前に数値からテキストに変換することの理由である。
【００１６】
正規表現のシンタックスは、単に適切なシンタックスの表現を書くことにより、複雑な検索及びパターン解析が可能なツールが豊富であり、それにより、リレーショナルデータベースのデータを検索する際に同じことを行うために、カスタムプログラム又は「ストアドプロシージャ」をＳＱＬで書くという時間のかかる必要性がなくなる。
【００１７】
Ｕｎｉｃｏｄｅは、世界の書記法の大半で表現されるテキストの一貫した符号化、表現、及び処理の計算業界標準である。Ｕｎｉｃｏｄｅは、ｈｅｘ０〜ｈｅｘ１０ＦＦＦＦに及ぶ約１００万の文字の集合である。日本語及び中国語のあらゆるシンボル、世界中の全てのアルファベット、並びに性能メトリックが表現される全ての数値に１個の文字が充てられる十分なＵｎｉｃｏｄｅ文字がある。エージェントから受信する各性能メトリック値は、これらのＵｎｉｃｏｄｅ文字のうちの１つに変換される。
【００１８】
正規表現で表現される特定の条件を満たす特定のリソースから、特定のデータパターンを定義する正規表現を用いて性能データを検索することは、キーワードについて大量のテキストを検索し、特定の意味的用法又は検索文字列に合うテキストの部分のみを報告することに類似する。このことは、測定したデータを予め記述可能な符号、すなわち正規表現の使用によって検索可能な符号へ符号化しておくことで、検索基準、又はそれと等価の非決定性オートマトンを規定する正規表現を用いて、データパターンが識別可能であることを意味する。
【００１９】
このことから、請求項に係る技術のシステムは、性能メトリックデータが正規表現を用いて検索可能な文字に変換されることになるＵｎｉｃｏｄｅの符号化方式等の符号化方式を用いて、性能メトリックデータを符号化する。性能データを符号化するのに用いることができる符号の具体例としてはＵｎｉｃｏｄｅが挙げられる。Ｕｎｉｃｏｄｅ標準には１１００００個の符号が定義されており、これは性能メトリックデータの数値を符号化する上で十分な量である。以降の説明ではＵｎｉｃｏｄｅに符号化したことを前提として説明するが、本明細書における請求項に係る技術のシステムではＵｎｉｃｏｄｅ以外の符号化方式についても、符号化された性能データが正規表現を用いて検索可能であれば実施可能である。
【００２０】
正規表現の使用により、データの記憶にリレーショナルデータベースが使用され、データベースの検索にＳＱＬが使用される場合に必要な「ストアドプロシージャ」と呼ばれる複雑なカスタムプログラムを書く必要なく、性能データの複雑なパターンを検索することができる。
【００２１】
本明細書における請求項に係るシステムは、ユーザーが、検索クエリを正規表現として下書きできるようにする。ユーザーは、これを行うために、ユーザーが、請求項に係る技術の幾つかの実施形態がユーザーによる選択及び実行のために提供する事前定義された検索のみを使用したい場合を除き、正規表現のシンタックスを知らなければならない。正規表現は、特定の文字、ワード、又は文字パターン等のテキスト文字列を照合する簡潔で柔軟性のある手段を提供する。
【００２２】
正規表現は、パーサー生成器として機能するか、又はテキストを調べ、提供された仕様に一致する部分を識別するプログラムである正規表現プロセッサにより解釈可能な形式言語で書かれる。好ましい実施形態では、本明細書に添付された付録Ａで詳述されるＭＡＲＳクエリ言語が、正規表現を用いて実装する検索が表現される形式言語である。
【００２３】
本明細書に記載の特別なディレクトリ構造に性能メトリックデータを符号化するＵｎｉｃｏｄｅ文字を記憶することは、非常に大量のデータが収集され、記憶される場合であっても、Ｏｒａｃｌｅ等の高価なデータベースシステムを使用する必要性をなくす。
【００２４】
性能データは、エージェントプログラムにより収集され、エージェントプログラムは、センサーに結合されるか、又は監視中のＩＴリソースにプログラムされる。これらのエージェントプログラムは、データリンクを介して性能データを収集し、圧縮し、遠隔監視サーバーに送信し、遠隔監視サーバーは、性能データを収集し、Ｕｎｉｃｏｄｅに変換し、上で定義されたディレクトリ構造に記憶する。遠隔監視サーバーはまた、正規表現検索クエリを構成するインターフェースをユーザーに提供するとともに、ユーザーが実行できる「定型（canned）」検索も提供し、各定型検索は、ユーザーが目的に合うように僅かに変更することができる事前定義される正規表現である。
【００２５】
性能メトリックデータを収集し、記憶し、処理するプロセス及び装置は、少なくとも２つの点でＳＱＬデータベース技術と異なる。第１に、パーティションアルゴリズムは、時間スライスに基づいて性能データを記憶する。時間スライスに基づいてデータを記録することで、データを追加する際の時間軸に関するＩｎｄｅｘ作成のコストを下げることができ、データベースの性能への影響を抑えることが可能となる。このことは、時間軸方向のデータ検索高速化とデータ追記の性能を維持する上で重要である。
【００２６】
また、時間スライスに加えて各データ要素ごとにスライスを作成してデータを記録することで、時間軸と各データ要素の軸でデータ検索を行うことが可能となる。図２及び図３はこの手法をディレクトリ構造とファイルシステム上のファイルで実現した場合の図である。ディレクトリ構造によってスライスが実現及び実装されており、データはファイルシステム上のファイルとして記録される。ただし、これ以外にも日付とデータ要素の識別子を元にキーを作成し、そのキーとデータを対応付けるといったことでも同様のことが実現できる。以降の説明では、ディレクトリ構造とファイルシステム上のファイルで上記方法を実現したことを前提に説明を行う。さらに、データを予め時間、データ要素ごとのスライスで区切り、データをまとめることはデータの圧縮及び保存時における容量削減の観点で重要である。同じデータ要素に含まれるデータは似たような値を取る傾向が有り、したがって、このようなデータは圧縮率が高い、すなわち、ファイルサイズを圧縮プログラムによって削減することができることが知られている。
【００２７】
例が図２及び図３に示される特別なディレクトリ構造にデータを時間スライスで記憶することにより、一方の軸として時間、他方の軸として各データ要素を用いてデータを検索することができる。これは、キーワードのマッチング等、キーワードについて大量のテキストを検索し、次に、特定の意味的用法に合うテキストの部分のみを報告することに類似する。
【００２８】
また本手法を用いることで、データベース全体に影響を与えることなく保存データへのアクセスを高速化することもできる。予めよく検索するデータパターンが登録されていたり、過去の検索又は検索結果から認識可能な傾向がある場合等、よく検索するデータパターンが既知である場合、保存する前にパターンマッチングを行うことでそのようなデータパターンの検索を高速にすることができる。その際の処理を図２２を用いて説明する。図２２は、時系列データ２２０２、及びよく検索されるクエリデータパターンの集合２２０３を示す。タイムウィンドウ２２０１は、時系列データ等の絶え間なく流れるデータに対して逐次処理を行う際に参照可能なデータの範囲を表している。このような状況で、図２３に記すような処理を行うことで保存したデータへの参照を高速化することができる。
【００２９】
まず、タイムウィンドウに対して新たにデータが追加された後、タイムウィンドウ２２０１に含まれるデータに対して、既知のよく検索されるクエリデータパターン２２０３を用いてパターンマッチングを行う。そののち、タイムウィンドウから先頭のデータの要素を出して保存し、このとき先ほどのパターンマッチでマッチングした場合、そのデータはよく参照されることが予測されるため、保存する際にその保存場所に関する情報もあわせて保存する。
【００３０】
この処理にかかる時間はタイムウィンドウに含まれるデータ量とパターンマッチを行うのに用いるデータパターンの数に依存する。タイムウィンドウに含まれるデータ量は通常メモリに載る程度のサイズである。そのため、データへの参照が限られることから、データベース全体に影響を与えることがない。
【００３１】
さらに、上記の例ではよく検索するデータパターンにマッチするデータの保存位置をあわせて保存していたが、データを圧縮して保存する場合等では、保存場所がわかっていてもマッチした文字列を含む時系列データ全体を展開しないと目的のデータが取り出せない場合も考えられる。その場合は図２４にあるように、よく検索によく用いられるクエリデータパターン２２０３にマッチするデータのみすぐに取り出せる形で圧縮して保存することで、この問題を回避できる。図２４では、２４０１、２４０２は通常の圧縮方式で保存したデータであり、部分構文２４０３はよく検索するクエリデータパターン２２０３にマッチするデータを別途圧縮したものである。また、図２５にこのときの処理の流れを記す。タイムウィンドウに含まれるデータに対してマッチング処理を行うのは図２３と同様であるが、データがパターンにマッチした場合（ステップ２５０１：ＹＥＳ）、そのデータを別の符号化方式で符号化して保存する部分が異なる（ステップ２５０２）。
【００３２】
なお本方法で用いている時間スライスのサイズは、データの検索が十分高速に行うことができる範囲で指定することを想定しているが、サンプリングレートの変更等で時間スライス内のデータ量が多すぎる状態になることが考えられる。そのような場合、時間スライスのサイズを変更する以外に、ある時間範囲に含まれるデータの統計値を保存前に計算して一緒に保存することで、データの参照を高速にすることができる。図２６はその例を示したものである。ここでは２つの時間スライス２６０１、２６０２に、その統計値としてａ、ｂ、ｃ、ｄ、ｅのデータ及びｄ、ｅ、ｆ、ｇのデータをそれぞれ含むデータが保存されているとする。このときｆｇというデータの並びを検索することを考えると、事前に統計量を参照することで、時間スライス２６０１を検索する必要が無いことがわかるため、検索時間を高速化できる。
【００３３】
この流れを図２７にて説明する。タイムウィンドウに含まれるデータに対して統計値の計算を行い、その結果をデータとともに保存する。ここで、統計値を保存する際に用いるデータの範囲はデータ検索に必要な統計値の詳細度、データ検索時に求められるレスポンスタイム等に応じて自由に設定可能であり、またそれらのデータの範囲は互いに被っていてもよく、またどの範囲に含まれないデータがあってもよい。
【００３４】
請求項に係る技術と従来技術との第２の違いは、性能データを解析し検索する方法が、性能メトリックの数値がＵｎｉｃｏｄｅテキスト文字に変換済みであるＵｎｉｃｏｄｅ符号化テキストを検索するのに使用される正規表現に基づくことである。正規表現は、確立され事前定義されたシンタックス及びセマンティクス（合わせてグラマーとみなされる）を有しており、このシンタックス及びセマンティクスを使用して様々な表現を形成して、カスタム検索用に構成された正規表現で表現された基準を満たすパターンについて性能データを検索することができる。正規表現は、全ての異なる種類の検索について導出して、検索を特定のリソース、それらのリソースの特定の属性、特定の日、又は特定の日の間の特定の時間間隔等に制限することができる。複雑性なく、かつ正しいデータを見つけて解析するストアドプロシージャの形態でカスタムプログラムを書く手間なしで、大きな柔軟性が提供される。
【００３５】
性能メトリックデータを検索して解析する本明細書に記載のプロセスは、ＸＰＡＴＨ技術により着想を得て、ＸＰＡＴＨ技術に幾らか類似している。ＸＰＡＴＨは、ＸＭＬドキュメントデータをトラバースするために使用される技法である。ＸＰＡＴＨのような技法は、本明細書では、基盤性能メトリックデータ及び時間の経過に伴うそのデータの変化を解析するために使用される。本明細書に記載のプロセスは、ＸＰＡＴＨの概念を時間スライスにより編成され記憶されたデータの検索及び解析に拡張し、それにより、本明細書において教示される検索及び解析技法を効率的かつ高速にする。性能データの検索及び解析は、パスに基づく技法を使用して行われる。データを表すグラフが作成される。グラフＧは、頂点及び辺（Ｖ，Ｅ）からなる表現形式である。辺は２つの頂点を繋ぎ、頂点は、表現を評価し、次に、表現に基づいて、適切な辺を通るトラバースを可能にする能力を有する。
【００３６】
図１は、性能データを編成し、記憶し、検索する本明細書に記載のプロセスを実行することができる一般的なサーバーのブロック図である。コンピューターシステム１００は、情報を通信するバス１０２又は他の通信機構と、バス１０２に結合され、情報を処理するプロセッサ１０４とを含む。コンピューターシステム１００は、バス１０２に結合され、情報及びプロセッサ１０４が実行する命令を記憶する、ランダムアクセスメモリ（ＲＡＭ）又は他の動的記憶デバイス等のメインメモリ１０６も含む。メインメモリ１０６は、プロセッサ１０４により実行される命令の実行中、一時変数又は他の中間情報を記憶するのに使用することもできる。コンピューターシステム１００は、通常、バス１０２に結合され、プロセッサ１０４の静的な情報及び命令を記憶する読み取り専用メモリ（ＲＯＭ）１０８又は他の静的記憶装置を更に含む。磁気ディスク又は光ディスク等の記憶装置１１０が提供され、バス１０２に結合されて、情報及び命令を記憶する。通常、性能データは、記憶装置１１０に特定のディレクトリ構造で記憶される。
【００３７】
コンピューターシステム１００は、バス１０２を介して、フラットスクリーンの陰極線管（ＣＲＴ）等のディスプレイ１１２に結合して、性能データを解析しているコンピューターユーザーに対して情報を表示することができる。英数字キー及び他のキーを含む入力装置１１４は、バス１０２に結合されて、情報及びコマンド選択をプロセッサ１０４に通信する。別の種類のユーザー入力装置は、マウス、トラックボール、タッチパッド、又はカーソル方向キー等のカーソル制御装置１１６であり、方向情報及びコマンド選択をプロセッサ１０４に通信するとともに、ディスプレイ１１２上のカーソル移動を制御する。この入力装置は通常、装置が平面内の位置を特定できるようにする２つの軸である第１の軸（例えば、ｘ）及び第２の軸（例えば、ｙ）で２度の自由度を有する。
【００３８】
性能データを編成し、記憶し、検索する本明細書に記載のプロセスは、コンピューターシステム１００をハードウェアプラットフォームとして使用するが、分散処理等の他のコンピューター構成を使用することもできる。一実施形態によれば、性能データを受信し、編成し、記憶し、検索するプロセスは、プロセッサ１０４が、メインメモリ１０６に含まれる１つ又は複数の命令の１つ又は複数のシーケンスを実行することに応答して、コンピューターシステム１００により提供される。そのような命令は、記憶装置１１０等の別のコンピューター可読媒体からメインメモリ１０６に読み出すことができる。メインメモリ１０６に含まれる命令シーケンスの実行により、プロセッサ１０４が本明細書に記載のプロセスステップを実行する。マルチプロセッシング構成での１つ又は複数のプロセッサを利用して、メインメモリ１０６に含まれる命令シーケンスを実行することもできる。代替の実施形態では、ハードワイヤード回路を、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて使用して、本発明を実施することができる。したがって、請求項に係る技術の実施形態は、ハードウェア回路及びソフトウェアのいかなる特定の組み合わせにも限定されない。
【００３９】
本明細書で使用される「コンピューター可読媒体」という用語は、実行のためにプロセッサ１０４に命令を提供することに関与する任意の媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、及び伝送媒体を含むが、これらに限定されない多くの形態をとることができる。
【００４０】
不揮発性媒体としては、例えば、記憶装置１１０等の光ディスク又は磁気ディスクが挙げられる。揮発性媒体としては、メインメモリ１０６等のダイナミックメモリが挙げられる。伝送媒体としては、バス１０２を構成するワイヤを含め、同軸ケーブル、銅線、及び光ファイバーが挙げられる。伝送媒体は、無線周波数（ＲＦ）データ通信及び赤外線（ＩＲ）データ通信中に生成されるような音波又は光波の形態をとることもできる。一般的な形態のコンピューター可読媒体としては、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ、任意の他の光学媒体、パンチカード、紙テープ、パターンになった穴を有する任意の他の物理的な媒体、ＲＡＭ、ＰＲＯＭ、及びＥＰＲＯＭ、フラッシュＥＰＲＯＭ、任意の他のメモリチップ若しくはカートリッジ、後述するような搬送波、又はコンピューターが読み取り可能な任意の他の媒体が挙げられる。
【００４１】
様々な形態のコンピューター可読媒体が、実行のために１つ又は複数の命令の１つ又は複数のシーケンスをプロセッサ１０４に供給することに関わることができる。例えば、命令は最初に、遠隔のコンピューターの磁気ディスクに担持することができる。遠隔のコンピューターは、命令をダイナミックメモリにロードし、モデムを使用して電話回線を介して命令を送信することができる。コンピューターシステム１００にローカルのモデムは、電話回線上又はブロードバンドリンク上でデータを受信し、赤外線送信機を使用して、データを赤外線信号に変換することができる。バス１０２に結合された赤外線検出機が、赤外線信号で搬送されたデータを受信し、データをバス１０２上に配置することができる。バス１０２はデータをメインメモリ１０６に搬送し、プロセッサ１０４は、メインメモリ１０６から命令を索出し実行する。メインメモリ１０６が受信した命令は、任意選択的に、プロセッサ１０４による実行の前又は後に記憶装置１１０に記憶することができる。
【００４２】
コンピューターシステム１００は、バス１０２に結合された通信インターフェース１１８も含む。通信インターフェース１１８は、ローカルネットワーク１２２に接続されたネットワークリンク１２０に双方向データ通信結合を提供する。例えば、通信インターフェース１１８は、データ通信接続をインターネットへの対応する種類のブロードバンドリンクに提供する総合サービスデジタル通信網（ＩＳＤＮ）カード又はモデムとすることができる。別の例として、通信インターフェース１１８は、データ通信接続を互換性のあるＬＡＮに提供するローカルエリアネットワーク（ＬＡＮ）カードとすることができる。無線リンクを実施することもできる。任意のそのような実施態様では、通信インターフェース１１８は、様々な種類の情報を表すデジタルデータストリームを搬送する電気信号、電磁信号、又は光信号を送受信する。
【００４３】
ネットワークリンク１２０は通常、１つ又は複数のネットワークを通じて他のデータ装置にデータ通信を提供する。例えば、ネットワークリンク１２０は、ローカルネットワーク１２２を通じてホストコンピューター１２４又はインターネットサービスプロバイダー（ＩＳＰ）１２６により運営されるデータ機器に接続を提供することができる。そして、ＩＳＰ１２６は、現在では一般に「インターネット」１２８と呼ばれるワールドワイドパケットデータ通信ネットワークを通じてデータ通信サービスを提供する。ローカルネットワーク１２２及びインターネット１２８はともに、デジタルデータストリームを搬送する電気信号、電磁信号、又は光信号を使用する。デジタルデータをコンピューターシステム１００とやりとりする、様々なネットワークを通じた信号並びにネットワークリンク１２０上の及び通信インターフェース１１８を通じた信号は、情報を輸送する搬送波の例示的な形態である。
【００４４】
コンピューターシステム１００は、ネットワーク（複数の場合もある）、ネットワークリンク１２０、及び通信インターフェース１１８を通じて、プログラムコードを含め、メッセージを送信し、データを受信することができる。インターネットの例では、性能データが監視されているサーバー１３０は、インターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２、及び通信インターフェース１１８を通じて性能データを収集するエージェントプログラムを介して、性能データをコンピューターシステム１００に送信することができる。受信された性能データは、本明細書において後述するプロセスにより記憶され、検索することができる。
【００４５】
請求項に係る技術のシステムは、ソフトウェア側及びデータ側に、上述したハードウェアプラットフォーム等で実行され記憶される以下の構成要素を有する：
データ記憶マネージャー、
クエリ要求ハンドラー、
データアクセスマネージャー、
プローブインターフェース、及び
ＮＲＤＢと呼ばれ、以下のディレクトリ構造の見出しで詳述され、図２及び図３に示されるプロプライエタリ非リレーショナルデータベース。
【００４６】
データ記憶マネージャー
この構成要素は、明確に定義されたフォーマットでプローブからデータを受信し、ＮＲＤＢに受信したデータを記憶する。プローブは、外部データソースから定期的にデータを収集し、データ記憶マネージャーが処理可能なフォーマットにデータを書き込む外部ソフトウェアプログラムである。データ記憶マネージャーは、本明細書の別の箇所で説明されるプローブデータフォーマットでデータを受信し、圧縮解除し、ＮＲＤＢについて本明細書に記載されるディレクトリ構造及びデータフォーマットでＮＲＤＢに記憶することができる限り、任意のプログラム構造を有することができる。好ましい実施形態では、データ記憶マネージャーは、図５のフローチャートの処理を実行可能なプログラム構造を有する。データ記憶マネージャーは、収集中の性能データを記憶するのに十分な速度、メモリ容量、及びディスク容量を有する任意の既製のコンピューターで実行することができる。
【００４７】
クエリ要求ハンドラー
この構成要素は、外部アプリケーション又はユーザーから検索クエリを受け取り、その結果を返信する。クエリ言語は、正規表現のプロプライエタリシンタックスであり、プロプライエタリシンタックスは、クエリ定義言語の見出しの下で以下に与えられ、データを解析する検索パターンを指定する構造を提供する。クエリ要求ハンドラーは、後述するシンタックスを有する正規表現が埋め込まれたクエリ要求を受信し、これらのクエリをパースし、図７のフローチャートの処理を実行することができる任意のプログラム構造を有することができる。クエリ要求ハンドラーは、収集中の性能データを記憶するのに十分な速度、メモリ容量、及びディスク容量を有する任意の既製のコンピューターで実行することができる。
【００４８】
データアクセスマネージャー
この構成要素は、請求項に係る技術のプロプライエタリ非リレーショナルデータベース（ＮＲＤＢ）に記憶されたデータへのアクセスを提供する。この構成要素は、結果をより高速に提供する標準キャッシュ技法を内部的に利用する。データアクセスマネージャーは、ＮＲＤＢのようなディレクトリ構造にアクセスすることができる任意のプログラム構造を有することができ、ＮＲＤＢの例は図３及び図４であり、ＮＲＤＢは、図７のフローチャートの処理を実行するために、ＮＲＤＢからのデータに対するクエリ要求ハンドラーの要求をサポートする。データアクセスマネージャーは、収集中の性能データを記憶するのに十分な速度、メモリ容量、及びディスク容量を有する任意の既製のコンピューターで実行することができる。
【００４９】
プローブインターフェース
ＮＲＤＢ
請求項に係る技術の全てのデータはＮＲＤＢに記憶される。ＮＲＤＢはファイル及びフォルダーからなる通常のファイルシステムを使用する。これは、データの記憶及びアクセスを最適化するデータファイルの特別なフォルダー構造及び特別な符号化を使用する。
【００５０】
データ記憶マネージャー、検索ハンドラー、データアクセスマネージャー、及びプローブインターフェースを実施する全体ソフトウェアは、好ましい実施形態では、Ｊａｖａ仮想マシン内部のコモディティハードウェアで実行するように設計される。コモディティハードウェアは、通常入手可能なＩｎｔｅｌ  ｘ８６／６４アーキテクチャベースのコンピューターとして定義される。ＣｅｎｔＯＳ等の標準Ｌｉｎｕｘ流通品が、ベースオペレーティングシステムとして使用される。
【００５１】
システムがどのように働いて、性能メトリックデータを収集し、解析するかの例として、サーバー１３０が、性能が監視される実行中の１組の仮想マシンを有するサーバーであると仮定する。各仮想マシンの性能メトリックデータが、エージェント又はプローブプロセス（図示せず）により、又は幾つかの実施形態では、あらゆる仮想マシンに個別のプローブプロセスにより収集される。性能データは、日ごとに収集されて、サーバー１３０上で様々な性能メトリックを測定する。ＣＰＵサイクル利用率、ハードディスクアクセス時間、ハードディスク容量等のサーバー１３０自体の性能データを収集することもできる。通常、多くの場合に分単位で同時に測定される幾つかのメトリックがある。
【００５２】
エージェントプロセスにより収集されるこの性能メトリックデータは圧縮されてパケット化され、パケットがインターネット１２８を介して、ローカルエリアネットワーク１２２が接続されたＩＳＰ１２６に送信される。ローカルエリアネットワークは、ネットワークライン１２０を介して監視サーバーシステム１００の通信インターフェース１１８に結合される。
【００５３】
プローブデータフォーマット
あらゆる要素の性能メトリックデータは、プローブにより収集される。プローブは、監視されている要素又は属性を有するコンピューターで実行中のプログラムである。各要素のプローブは、定期的又は散発的に（通常、呼び出しが毎分行われる）、コンピューター又は他のマシンのオペレーティングシステムにアプリケーションプログラムインターフェース呼び出しを行い、監視されている要素の性能データを収集する。プローブは、所望の性能メトリックデータを収集し、プローブデータに関して後述するデータフォーマットにすることができる任意のエージェントハードウェア及び／又はソフトウェアの組み合わせとすることができる。
【００５４】
プローブはＩＴ属性のみのためである必要はない。プローブは機械的構造又は自動車システムのデータを収集することもできる。例えば、橋を設計する技術者は、温度センサー及び歪みセンサーを構造の様々な位置に取り付けることができ、コンピューターで実行中のプローブプログラムにより各センサーが読み取られ、プローブプログラムは随時、各センサーに定期的に問い合わせ、その読み取りを行い、記憶及び解析のために他の場所に送信する。プローブは全てのセンサーデータを収集し、データを後述するデータ構造フォーマットにフォーマットし、データ構造を圧縮し、圧縮データをパケット化して、任意のデータパスを介して、解析のために他の場所にあるシステムに送信する。車、エンジン等の場合も同様である。プローブシステムは多かれ少なかれ、無線テレメトリーリンクにより性能データを地上局にフィードバックする、衛星及びミサイルに使用されるテレメトリーシステムの現代の均等物のようなものである。
【００５５】
プローブにより収集された性能メトリックデータ値は通常、インターネットを介した送信のためにパケット化される。プローブデータフォーマットの主な目的は、プローブが生成するデータ量を低減し、それにより、プローブデータが送信される際に経由するデータリンク上の帯域幅要件を低減することである。これは、データの記憶に必要な記憶量を低減するとともに、別のロケーションへの送信をより高速にもする。プローブプログラムは、好ましい実施形態では、性能メトリックデータからＵｎｉｃｏｄｅへの変換を行わないが、幾つかの代替の実施形態では、行うことができる。
【００５６】
プローブは、監視している全ての要素の１日の全ての属性データを収集し、図４に示されるようなディレクトリ構造を作成する。ディレクトリ構造はファイルを含み、ファイルはプローブがデータを収集したあらゆる属性の時系列の属性値（性能メトリックデータ）を記憶する。属性値は数値であり、プローブによりＵｎｉｃｏｄｅ値に変換されない。それは、監視するサーバー側で行われる。
【００５７】
図４では、ブロック１８０は最上位レベルのディレクトリを表し、ブロック１８２は全てのホストタイプ要素のフォルダーを表し、ブロック１８４は、監視されている全てのディスクタイプ要素のフォルダーを表す。フォルダー１８２及び１８４のそれぞれは、好ましくは、サブディレクトリによりシンボル化されたタイプの監視されているあらゆる要素のプローブにより得られる属性値を含むテキストファイルを含む。各テキストファイルは、好ましくは、１行が、そのグループ内で監視されている要素のうちの１つについて測定された性能メトリック値を含む、同じグループ内の監視される全ての要素の全ての性能メトリック値を含む。例えば、ホストフォルダー１８２は１つのテキストファイルＡ１．ｔｘｔを有することができるが、そのファイルは、好ましくは、監視されているホスト要素ごとに１つずつ、複数の行を含む。例えば、ブロック１８６及び１８８は、Ｈ１及びＨ２と呼ばれるＡ１．ｔｘｔ内のグループで監視されている２つの特定のホストの性能メトリック値を含む。ブロック１８６及び１８８内のＨ１及びＨ２は、性能メトリックデータが収集されたホストを一意に識別する一意の文字列を表す。Ｈ１は、カンマ区切りリスト内のＶ１、Ｖ２、・・・、Ｖ１４４０の値でシンボル化される行内に記憶される１４４０個の性能メトリック測定値を有する。ホストＨ１では、性能値は毎分測定された。ホストＨ２でも同じである。ブロック１９０及び１９２は、好ましくは、フォルダー１８４で表される被監視要素「ディスク」のグループ内の２つのディスクＤ１及びＤ２についてプローブが収集した性能メトリック値を含む。ディスクＤ１及びＤ２のこれらの性能メトリック値は、好ましくは、Ａ２．ｔｘｔという名前のテキストファイルの異なるセクション又は行に記憶される。
【００５８】
データファイル及びサブディレクトリの全体の集合体は、好ましくは、プローブにより１つのｚｉｐファイルにジップされ、ｚｉｐファイルはデータ構造の圧縮版である。データの圧縮版を送信することにより、プローブと監視サーバー（複数の場合もある）との間のデータパスへの帯域幅要件が大幅に低減する。ｚｉｐファイルがアンジップされる場合、図４のようなデータ構造（又はデータ構造は監視されている要素及び属性の数値であれ、何であれ）が結果として生成される。
【００５９】
プローブにより生成される任意のペイロードは、以下の構造に準拠しなければならない：
ListOfFiles<YYYYMMDD_HHmmSS>_< (SiteName + "_"+ServerName +"_"+ ArraySerialNumber)の暗号化値のベース６４符号化テキスト>_<ProbeType>.txtという名前の第１のファイル
・このファイル内部の各ラインは、好ましくは、このペイロードの一部であるファイルの名前を有する
・ファイルが構成データ又はイベントデータである場合、ファイルの名前は、Conf<YYYYMMDD_HHmmSS>_<(SiteName + "_"+ServerName +"_"+ ArraySerialNumber)の暗号化値のベース６４符号化テキスト>_<ProbeType>.zip.encでなければならない
・ファイルが性能データを有する場合、ファイルの名前は、Perf<YYYYMMDD_HHmmSS>_<(SiteName + "_"+ServerName +"_"+ ArraySerialNumber)の暗号化値のベース６４符号化テキスト>_<ProbeType>.zip.encでなければならない。
ただし、
・SiteName−プローブに割り当てられたサイトの名前、
・ServerName−データが収集されているエンティティの名前であり、プローブ構成中にユーザーにより記入されるテキスト、
・ArraySerialNumber−エンティティを更に識別する任意選択的な追加情報、
・ProbeType−データが収集されているエンティティのタイプ−ＶＭＷａｒｅ、ＳＭＩＳ、ＮｅｔＡｐｐ、Ａｍａｚｏｎ  ＥＣＳ、ブリッジセンサー
である。
１つ又は複数の．ｚｉｐファイルがファイルのリスト中で識別される。
【００６０】
構成ｚｉｐファイルは、２つのタイプ：
・スナップショット、
・ミニスナップショット
とすることができる１つ又は複数のファイルを含むことが好ましい。
【００６１】
スナップショット
スナップショットタイプファイルは、プローブが接続されているデータソースについての全体構成を含むことが好ましい。このファイルの名前は、<SiteName>_<DataSource>_snapshot_<YYYYMMDD>_<HHMMSS>_<Version>.txtである。ただし、
・<Site Name>：プローブが配置されたロケーション（実際の物理的な場所）の識別子、
・<Data Source>：データが収集されているデータソース（リソース、すなわち、ホスト、ディスクアレイ、プリンター等）の識別子、
・<YYYYMMDD>_<HHMMSS>：スナップショットが作成された日時、
・<Version>：ファイルのバージョン
である。
【００６２】
スナップショットのファイルフォーマットは、好ましくは、以下の通りである：
%meta
probe_id:<Identifier>
probe_type:<Probe Type>
probe_site:<Site Name>
probe_server:<Server Name>
probe_version:<Probe Version>
%meta
｛
t;<YYYYMMDD_HHMMSS>
{
R:<ResourceType>#<Resouce Id>
O:{<ResourceType>#<Another_Resource_id>,}+?
b:<Begin Time YYYYMMDD_HHMMSS>?
e:<End Time YYYYMMDD_HHMMSS>?
a:(<Attribute Id>=<Attribute Value>}+
r:{<Resource Type>#<Resource Id>,}+
$:{<Event Id><space><Event String>}+
}+
}+
【００６３】
実施例：
%meta
probe_id:Cust_192.168.0.63
probe_type:VMWare
probe_site:Cust1
probe_server:192.168.0.63
probe_version:10
%meta
t:20110624_062248
R:dc#Cust_192.168.0.63_datacenter-2
a:name=MTNVIEW
R:ds#Cust_192.168.0.63_datastore-205
a:name=FAS960_home
a:capacity=51322806272
a:freeSpace=42685091840
a:uncommitted=17323200512
a:provisionedSpace=25960914944
a:type=NFS
a:URL=netfs://192.168.0.50//vol/vol0/home/
a:sioc=disabled
r:h#Cust1_192.168.0.63_host-171,
R:ds#Cust1_192.168.0.63_datastore-10
a:name=Storage1
$:AlarmSnmpCompleted Alarm 'Host error'- an SNMP trap for entity 192.168.0.48 was sent
【００６４】
更新
構成が変更され、構成関連イベントが発生した場合、それらは、好ましくは、ミニスナップショットファイルに書かれる。このファイルの名前は、<Site name>_<Data Source>_minisnapshot_<YYYYMMDD>_<HHMMSS>_<version>.txt <YYYYMMDD>_<HHMMSS>である。
【００６５】
このファイルのフォーマットは、好ましくは、スナップショットファイルと全く同じである。主な違いは、このファイルのフォーマットはスナップショットタイプのファイルのデータのサブセットのみを有することである。サブセットは、スナップショットファイルが作成された最後の時間から構成データに生じた変更を捕捉する。
【００６６】
性能データ
性能データは、以下のディレクトリ構造を有することが好ましいｚｉｐファイルである：
・<YYYYMMDD_HHMMSS>−このディレクトリ名はこのデータセットで指定される時系列の開始時間である。
・<Resource Type>−リソースタイプごとに１つのディレクトリ
・<Attribute Id>.txt−性能メトリックごとに１つのファイル
各<Attribute Id>.txtは、各ラインが以下のフォーマットを有する１つ又は複数のラインを有する：
<Resource Signature> ',' {Value} ',' {',' <Value> } +
【００６７】
値リストは、時間の開始時に指定されたリソースのその性能メトリックの値の時間順の系列である。メトリック値が特定の時点で存在しない場合、空白又は空値が許される。
【００６８】
ＮＲＤＢファイルシステム構造
性能メトリックデータは、好ましくは、以下に定義されるファイルシステム構造に記憶される。フォーマットＹＹＹＹＭＭＤＤで日ごとに１つのディレクトリが作成されることが好ましい。特定の日のデータモデル内の全てのリソースの全ての性能データは、好ましくは、このディレクトリに記憶される。このディレクトリ下には、ディレクトリ名が好ましくはそのリソースのシグネチャである各リソースのディレクトリがあることが好ましい。このディレクトリ下には、好ましくは、一属性グループに１つのファイルがある。ディレクトリは、好ましくは、このようなものになる：
<YYYYMMDD>−日ごとに１つのフォルダー
<Resource Type>
<AttributeGroupId>.perf
・<YYYYMMDD_HHMMSS>−このディレクトリ名は、好ましくは、このデータセットで指定される時系列の開始時間を含む
・<Resource Type>−好ましくはリソースタイプごとに１つのディレクトリ
<Attribute Id>.txt−好ましくは性能メトリックごとに１つのファイル
<AttributeGroupId>.perfファイルは、好ましくは、各サンプルの処理済み値を圧縮フォーマットで記憶する。このフォーマットについてこれより詳細に説明する。ファイルは、好ましくは、「ｎ」個のセクションに分割される。ただし、「ｎ」は、同じグループ内にあると定義される属性である。各セクションは、好ましくは、「ｍ」個の値、すなわちそのリソースの属性のその日の全体時系列値を保持する。したがって、例えば、プローブのサンプリング間隔が１分である場合、１４４０個（１日は１４４０分）の値があることになる。各<Attribute Id>.txtは、好ましくは、各ラインが以下のフォーマットを有する１つ又は複数のラインを有する：
<Resource Signature> ',' {Value} ',' {',' <Value> } +
【００６９】
値リストは、好ましくは、時間の開始時に指定されたリソースのその性能メトリックの値の時間順の系列である。メトリック値が特定の時点で存在しない場合、空白又は空値が許される。
【００７０】
現在、プローブから受信される性能メトリック属性の未処理の各値に対応して、好ましくは２つのタイプの処理済み値が記憶される：
・バンド値
・属性は、未処理値を記憶する「忠実性」を定義することができる。これはバンドファクターと呼ばれる。バンドファクターは好ましくは整数であり、最小値は好ましくは１であり、最大値は好ましくは任意の正の整数値である。バンドファクターが１の場合、忠実性の損失はない。この処理済み値は未処理値と同じである。バンドファクターが１０の場合、処理済み値は、好ましくは最も近い整数に丸められた未処理値の１／１０である。
・デルタ値
・デルタ値は、好ましくは、時間ｔ−１でのバンド値及び時間ｔでのバンド値からの割合での変化である。
【００７１】
性能メトリック属性の１４４０個の値の各セットが（毎分、１つの値が測定されると仮定して）、好ましくはＪａｖａ  ＵＴＦ−８符号化文字列として記憶される。各性能メトリック属性値は、好ましくは、文字列内の１つのＵｎｉｃｏｄｅ文字として符号化される。
【００７２】
図２は、性能が遠隔に監視されているリソースの１日の性能データを記憶するディレクトリ構造の例である。図１のプロセッサ１０４は、本発明の一実施形態によれば、メインメモリ１０６に記憶された命令により、各日分のデータに好ましくは１つのディレクトリと、性能メトリックデータが受信されている各リソースに好ましくは１つのサブディレクトリとを有する特別なディレクトリ構造を作成するようにプログラムされる。図２では、ブロック１５０は、２０１１年８月１４日に収集された性能メトリックデータを記憶するために作成されたディレクトリを表す。ブロック１５２により表されるサブディレクトリは、リソースＥ１の性能データが記憶されることになるサブディレクトリを表す。この例では、リソースＥ１が図１のサーバー１３０であると仮定する。
【００７３】
各サブディレクトリは、好ましくは、そのサブディレクトリのシグネチャにディレクトリ名を有する。この場合、サブディレクトリ１５２は、そのディレクトリ名に２０１１０８１４を有し、この２０１１０８１４は、好ましくは、サブディレクトリ１５２がその一部分となっているディレクトリの名前である。
【００７４】
各サブディレクトリは、好ましくは、性能メトリック値を記憶する性能メトリックデータにより測定中の各属性グループに１つの属性ファイルを含む。各属性ファイルは、好ましくは、ファイルが作成されたグループ内にあると定義された属性ごとに１つずつ、Ｎ個のセクションを有する。各セクションは、好ましくは、値がそのセクションに記録される特定の属性のＭ個の性能メトリック値を保持する。そのセクションのデータは、好ましくは、そのセクションが充てられた属性の全体の時系列の値を含む。
【００７５】
図２の例では、サブディレクトリ１５２には２つの属性グループしかないため、２つのファイル１５４及び１５６しかない。これらのファイルのそれぞれが、サーバー１３０で実行中の仮想マシンのうちの１つを表すと仮定する。各ファイルは、日全体分のメトリックを、その性能メトリックの値の記憶が充てられたそのファイルのセクションに記録する性能メトリックデータ値の時間スライスである。通常、メトリックが分ごとに測定された値を有する場合、そのメトリックが充てられたファイルのセクションは、Ｊａｖａ  ＵＴＦ−８符号化文字列として符号化されたそのメトリックの１４０個のカンマ区切り値を有することになる。ＵＴＦ−８はＵｎｉｃｏｄｅのマルチバイト文字符号化である。ＵＴＦ−８は、Ｕｎｉｃｏｄｅ文字セット内のあらゆる文字を表すことができる。Ｕｎｉｃｏｄｅ文字セット内の１１１２０６４個のコードポイントのそれぞれが、オクテットと呼ばれる１つ〜４つの８ビットバイトで構成されるＵＴＦ−８文字列に符号化される。Ｕｎｉｃｏｄｅ文字セット内の前の方にある文字ほど、より少数のバイトを使用して符号化され、より大きな効率に繋がる。最初の１２８個のＵｎｉｃｏｄｅ文字セットは、１２８個のＡＳＣＩＩ文字に一致する。
【００７６】
請求項に係る技術のシステムは、性能メトリック値をＵｎｉｃｏｄｅ文字にマッピングし、次に、ＵＴＦ−８を用いて符号化するマッピングテーブルを有する。Ｕｎｉｃｏｄｅは正の値のみをサポートするため、Ｕｎｉｃｏｄｅ範囲は分割され、第１の範囲のＵｎｉｃｏｄｅ値は、正の性能メトリック値にマッピングされ、第２の範囲のＵｎｉｃｏｄｅ値は負の性能メトリック値にマッピングされる。
【００７７】
ただし、このマッピングの方式は一例にすぎない。値の出現頻度を調べ、出現頻度が多い値に小さいサイズの符号を割り当てることで、データの格納に必要なストレージサイズを小さくすることができる。また、性能メトリック値の種類やデータの測定時間帯（時間スライス）によって値の分布が異なっている場合は、性能メトリック値の種類やデータの測定時間帯に応じてマッピングを変えることで、データ格納に必要なストレージサイズの更なる軽減を実現できる。さらに、マッピング時に複数の値を１つの符号に割り振る（量子化）マッピング方式が考えられるが、その際の量子化の幅を、データを使う際に求められる詳細度（解像度）に応じて調整することで、必要な符号の数を減らすことができる。その結果、短い符号長の符号を用いることができ、必要なストレージサイズの削減を実現できる。
【００７８】
測定からの各性能メトリック値は、好ましくは、１６進数系（ｈｅｘ）で１つのＵｎｉｃｏｄｅ文字として符号化される。
【００７９】
全てのリソース及び全てのプローブからの新しい各日分のデータは、好ましくは、新しいディレクトリ構造に記憶される。ディレクトリ、サブディレクトリ、及びファイルの名前は、好ましくは、データが収集された日、データが収集されたリソース、及び性能メトリックデータがファイルの様々なセクションに記憶される特定の属性グループについての情報を含む。
【００８０】
図２の例では、ディレクトリ構造１５０は、サブディレクトリ１５２で表される同じリソースからの２つの異なるメトリックの分ごとに収集された１日のメトリックデータのファイル１５４及び１５６を有する。換言すれば、監視中のリソースは１つのみである。また、図２の例では、各属性グループに１つのみの属性があり、合計で２つの属性のみが収集された性能メトリックデータを有する。性能メトリックデータは２０１１年８月１４日に収集されたため、その日のメトリックデータを記憶するために作成されたディレクトリ１５０の名前は２０１１０８１４である。Ｅ１と呼ばれる監視中の１つのみのリソースがあるため、２０１１０８１４＿Ｅ１と呼ばれるサブディレクトリ１５２が作成される。そのサブディレクトリは２つのファイルを含む。第１のファイル１５４の名前はＥ１／Ｇ１であり、グループ１（グループＥ１／Ｇ１には１つのメトリックＭ１のみがあるため、１つのセクションのみを有する）のメトリックＭ１のメトリック値を記憶する。メトリックＭ１の値は、分ごとに収集され、値Ｖ１〜Ｖ１４４０としてシンボル化され、カンマ区切りリストとして記憶される。値Ｖ１は、８／１４／２０１１の時間００：０１：０１、すなわち、８／１４／２０１１の最初の分に測定されるメトリックＭ１の値である。値Ｖ２は、８／１４／２０１１の時間００：０２：０１、すなわち８／１４／２０１１の第２の分に測定されたメトリックＭ１の値である。値Ｖ１４４０は、８／１４／２０１１の最後の分である２３：５９：０１に測定されたメトリックＭ１の値である。したがって、カンマ区切りリスト上の任意の特定の値の位置は、８／１４／２０１１において値が捕捉された時間を示す。
【００８１】
リソースＥ１のサブディレクトリ内の第２のファイル１５６の名前はＥ１／Ｇ２であり、グループ２（これもグループ内に１つのメトリックのみを有するため、ファイル内に１つのセクションのみがある）内のメトリックＭ２の値を記憶する。これは、ファイルＥ１／Ｇ１と同じ構造を有するため、詳細に示さなかった。
【００８２】
ファイルの各位置に記憶された値は好ましくはＵｎｉｃｏｄｅ符号化され、これは、メトリック値の数値が符号化プロセスでテキスト文字又は文字列にマッピングされたことを意味する。他の実施形態では、数値をテキスト値に変換する他の符号化プロセスが用いられ得る。
【００８３】
これにより、シンタックス及びセマンティクス（合わせて形式言語のグラマーと呼ばれる）の事前定義された規則である形式言語の形態（コンピュータサイエンティストが「形式言語」という用語を使用する意味で使用される）の正規表現を使用して、これらの値を検索することが可能になる。正規表現を形成できる要素は既知であり、各要素は、どのように構成されるかについて各自の既知のシンタックスを有するとともに、何を意味するかを定義する各自の独自で既知のセマンティクスを有する。性能メトリックデータを何らかの方法で解析したい人は、正規表現の構成に利用可能な要素と、要素のシンタックス及びセマンティクスを使用して正規表現を構成することができる。任意の正規表現シンタックスを用いて本発明の教示を実施することができるが、請求項に係る技術は、この用途に最適化され、本明細書の他の箇所に開示されるプロプライエタリシンタックスを用いる。
【００８４】
図３は、３つの異なるリソースの３つの異なる日の性能メトリックデータを記憶する個別のディレクトリを含むファイルシステムの別の例であり、各リソースは２つの属性グループを有する。メトリックデータを記憶するファイルシステムは、ブロック１５８で表される。３日分の性能データは、ディレクトリ１６０、１６２、及び１６４のそれぞれに記憶される。これらのディレクトリのそれぞれは、Ｒ１、Ｒ２、及びＲ３という名前の３つのサブディレクトリを有し、各サブディレクトリは、エージェントにより測定され送信された性能メトリック値を符号化する実際のファイル又はテキストデータを含むフォルダーである。ブロック１６６及び１６８は、グループ１及びグループ２の属性のそれぞれのリソース１について２０１１年７月２７日に収集された性能メトリックデータを記憶するＧＲＰ１．ＴＸＴ及びＧＲＰ２．ＴＸＴという名前のカンマ区切りテキストファイルを表す。
【００８５】
異なる属性性能値を同じファイルにグループ化する理由は、ロード及び解析の速度である。通常、リソースの解析は、特定の間隔にわたり幾つかの異なる属性のパターン又は値又は値の変化を見ることを含む。解析に関わる属性が全て同じグループにグループ化される場合、好ましくは、これらの属性は同じファイルに記憶される。このようにして、解析を行う必要がある全てのデータは、好ましくは、単に関心のある日に対応するディレクトリ構造から、解析中のリソースの属性グループを含む適切なファイルを読み出すことにより、メモリにロードして解析することができる。そのファイルは、オペレーティングシステムへの標準ファイルアクセス呼び出しによりメモリにロードされ、単数又は複数の正規表現検索をデータに対して実行することができる。これは、幾つかの異なるファイルをロードする必要がある場合、又はより多数の読み出しを必要とするＳＱＬクエリをデータベースに対して行う必要がある場合よりも高速である。
【００８６】
図５は、監視するサーバーが好ましくは実行する、プローブから性能メトリックデータのｚｉｐファイルを受信し、データを復元して記憶するプロセスの高レベルフローチャートである。ブロック２００は、プローブから性能メトリックデータのｚｉｐファイルを受信するプロセスを表す。ブロック２０２は、ｚｉｐファイルを圧縮解除して、図４に示されるようなデータ構造を復元するプロセスを表す。ブロック２０４は、そのような目的でサーバーが使用するマッピングテーブルを使用して、テキストファイルに記憶された数値性能メトリック値を好ましくはＵｎｉｃｏｄｅ文字に変換するプロセスを表す。ブロック２０６は、ステップ２０４において導出されるＵｎｉｃｏｄｅデータ構造を好ましくはＮＲＤＢデータ構造の適切な部分に記憶するプロセスを表す。データ構造はすでに、好ましくは各テキストファイルが表す要素タイプのサブディレクトリで監視中の各要素のメトリックデータの個々のテキストファイルを用いてデータが収集された特定の日の１つのディレクトリとして構造化されているため、通常、これは単に、ディレクトリ全体及びその全てのファイルをディスクに記憶することを伴う。
【００８７】
正規表現をどのように使用して、メトリック性能データを解析することができるかの例
ＣＰＵ利用率が少なくとも５分以上にわたって９０％〜１００％であるか否かを解析者が知りたかったものと仮定する。ＣＰＵ利用率の性能メトリックデータの検索及び解析を行う正規表現シンタックスは、汎用シンタックス内にある：
［Ｕ９０−Ｕ１００］｛５，｝−１００−２００
【００８８】
ＣＰＵ利用率メトリック値のＵｎｉｃｏｄｅ符号化を考慮に入れるように、この正規シンタックスを変換するには、９０％利用率を表すＣＰＵ利用率メトリック値がＵｎｉｃｏｄｅｈｅｘ文字ａにマッピングされ、９２．５％ＣＰＵ利用率がＵｎｉｃｏｄｅｈｅｘ文字ｂにマッピングされ、９５％がｈｅｘ文字ｃにマッピングされ、９７．５％がｈｅｘ文字ｄにマッピングされ、１００％がｈｅｘ文字ｅにマッピングされると仮定する。ＣＰＵ利用率メトリック値が分ごとに測定される場合、ＣＰＵ利用率が、少なくとも５分にわたって９０％〜１００％であるか否かを判断する正規表現は、
［ａ−ｅ］｛５｝［ｇ］
になり、問題となっている日の問題となっているＣＰＵのＣＰＵ利用率値を記憶するファイル内の５つの連続した値が、ｈｅｘ文字ａ〜ｅの任意の組み合わせである場合、表現が真と評価されることを意味する。これは、その特定の日のあらゆる時間で、ＣＰＵ利用率メトリック値が、ｈｅｘ  ａ〜ｈｅｘ  ｅの任意の組み合わせである５つの連続した値を有した場合、それらの間隔ごとに、ＣＰＵ利用率が９０％〜１００％であったことを意味する。これは、ＣＰＵが限界に達し、別のＣＰＵを追加すべきであることを意味することができる。
【００８９】
請求項に係る技術の好ましい実施形態では、ユーザーは、クエリを構成するために、正規表現のシンタックスを知らなければならない。代替の実施形態では、ユーザーが問題空間内で考え、クエリを分かりやすい英語で構成できるようにするユーザーインターフェースが提供され、システムは、そのクエリを、そのクエリ及び解析を実行する正規表現に適切なシンタックスに変換する。幾つかの実施形態では、請求項に係る技術のシステムのソフトウェア部分はユーザーインターフェースを提示し、このユーザーインターフェースは、ユーザーが様々な形態の解析を行うために使用することができる事前定義された検索のセットを有する。事前定義された各検索は、選択された場合、正規表現を生成させ、性能メトリックデータを検索し、結果を返すために使用させる。幾つかの実施形態では、これらの事前定義された検索は、ユーザーが設定可能な変数を有するテンプレートである。例えば、ＣＰＵ利用率がｚ分を超えてｘ％〜ｙ％であるか否かを判断する事前定義された検索が存在することができ、ここで、ｘ、ｙ、及びｚは、検索実行前にユーザーが設定できる変数である。
【００９０】
検索／クエリを実行するために、好ましい実施形態では、システムのソフトウェアは、クエリ表現ボックスと、開始時間に１つ、終了時間に１つの、２つの時間範囲ボックスとを表示する。これらの開始時間ボックス及び終了時間ボックスは、好ましい実施形態ではカレンダーであり、ユーザーは単に、データを検査する最初の日を選択し、検査するデータの最後の日である第２の日を終了時間カレンダーで選択するだけである。次に、ユーザーは、クエリを正規表現シンタックス内のクエリ表現ボックスにタイプし、リターンを押下する。次に、ソフトウェアは、ユーザーにより指定された１日又は複数日に適切なディレクトリ構造に自動的にアクセスし、クエリ表現で指定された性能メトリック属性値を含む適切なファイルにアクセスし、それらの属性値をメモリ内に読み取り、クエリ表現で指定された論理を使用してデータを調べる。
【００９１】
図６は、一般的な正規表現クエリのシンタックスを説明するために使用される正規表現のテンプレートである。正規表現の冒頭にあるｈは、この特定のクエリがホスト性能メトリックデータを検索するように設計されることを示す。クエリがディスク又は他のものについてのものであった場合、問題となっているリソースのタイプを示すものが、ｈの代わりになる。
【００９２】
大きな左括弧は、実際のクエリ表現の開始を示す。クエリ表現の冒頭にある＠シンボルはキーワードである。「ＣＰＵ  ｕｓａｇｅ（ＣＰＵ使用率）」項は、検索すべき属性データの名前であり、ＣＰＵ使用率の性能メトリックデータを含む正確なファイル名をソフトウェアに調べさせるのは、この属性名である。「ｒｘ」項は、続くものが正規表現であることを示し、「ｂ」項は、検索のタイプがデルタデータとは対照的にバンドデータであることを示す。［Ｕ９０−Ｕ１００］｛５｝は、バンドデータ検索の実行に使用すべき実際の基準を示す正規表現であり、すなわち、どの性能メトリックデータがクエリを満たし、どれが満たさないかを定義する。正規表現は、ファイルに記憶された別の正規表現へのポインターとすることもできる。ポインターは、使用すべき正規表現の一意のＩＤを含む。
【００９３】
バンド値は、Ｕｎｉｃｏｄｅ化することができる最大の数値（約１００００００）よりも大きな数値の内部表現の、計算されるか、又はマッピングされる値である。例えば、データ転送速度が毎秒２０００万ビットであり、メトリックが２０００００００である場合、バンド値は、例えば、１０００万の減少係数を使用してそのメトリックに関して計算されて、Ｕｎｉｃｏｄｅ化前に２０００万の数値を数値２に低減する。大きな数値である性能メトリックの範囲をＵｎｉｃｏｄｅ範囲にする任意の減少係数を内部表現のために使用することができる。次に、実際の性能メトリック数値ではなく、計算されたバンド値に対して検索が行われる。
【００９４】
デルタ値は、急に大きくなる（spike）性能メトリックデータの解析に有用である。デルタ値は、前の測定時からどれくらいの値が変化したかを記録する。
【００９５】
システムは、好ましい実施形態では、幾つか又は全ての性能メトリックのバンド値及びデルタ値の両方を計算し記憶する。
【００９６】
クエリ定義言語
目的
・リソースセットから別の関係リソースセット等へのトラバースを可能にする
・トラバースの各段階で、特定のフィルタリング基準を適用する：
・構成属性：特定の値に一致、値の変化
・関係：関係の加算又は削除
・性能メトリック：特定のパターンに一致
【００９７】
クエリ定義言語の詳細について説明する前に、本検索手法の基本的な動きについて例を用いて説明する。例を説明する際に用いるデータ例を図１２に示す。まず時系列データを測定する環境として、ｖｍとｈｏｓｔの２つの種類のリソースタイプがあるとする。
リソースタイプがｖｍとして分類されるリソースとしてｖｍ１とｖｍ２、ｈｏｓｔとして分類されるリソースとしてｈｏｓｔ１があるとする。リソースタイプがｖｍのリソースはｒｅａｄｌａｔｅｎｃｙとｒｅａｄｉｏｐの２つの属性を持っており、リソースタイプがｈｏｓｔのリソースはｒｅａｄｌａｔｅｎｃｙの属性を持つとする。
【００９８】
このとき、時系列データは、時間スライスを識別できるＩＤ１２０４並びにＩＤ１２０５及びＩＤ１２０６が、付与されたリソースを識別するために用いられる状態で保存される。図１２ではわかりやすさのために時間スライス−リソース識別子という階層的な構造及び、複数の時系列データを１つの表１２０７の形で表現しているが、これらの時系列データは１つの表である必要はなく、またそれぞれの行に１２０８といったタイムスタンプが付与されている必要はない。また、この図の例では分かりやすさのために測定データを数値の形で示しているが、実際には時系列データのパターンマッチを行いやすくするために英数字として符号化された形で保存している。また、リソースＩＤがｖｍ１、ｖｍ２のデータと、リソースＩＤがｈ１のデータの間には、事前に関係があることが定義されているとする。
【００９９】
ここで、検索クエリとして図１４のような構文が与えられたとする。図１４のこの検索クエリは、３つの小さな正規表現からなる１つの大きな正規表現である。すると、本明細書が開示するシステムは事前定義された構文規則に基づいて、この１つの大きな正規表現の構文を解釈する。この事前定義された構文規則は、形式言語を用いて書かれた正規表現に符号化された全ての検索において用いなければならないシンタックスを定義する形式言語の文法規則を用いて、事前定義された順序で３つの小さな正規表現のそれぞれの構文を解釈し、各検索は前回の検索によって発見されたデータのみの検索に制限される。この場合、大きな正規表現の構文は、部分構文１４０１、１４０２、１４０３を有する３つの小さな正規表現に分割され、これらは始めから順番に評価される。そのため、この場合、「事前定義された構文規則」は、３つの小さな正規表現が１つの大きな正規表現の中で出現する順序で、これら３つの小さな正規表現を評価することであり、正規表現１４０１に符号化された最初の検索が、これらの検索を開始したユーザーによって規定された時間窓内の時系列データに対して行われない限りは、各検索は前回の検索によって発見されたマッチングデータの検索に制限される。事前定義された構文規則は、１つの大きな正規表現を構成する小さな正規表現によって実行される検索の間の木構造関係も定義することができる。そのような場合、最初の検索はルート検索と呼ばれ、木の枝又は葉を構成する小さな正規表現が、ルート検索によって発見されたデータに対して行われる。したがって、そのような場合の事前定義された構文規則は、「最初にルート検索を行い、次に、木の枝から他の検索が分岐する場合には、ルート検索によって発見されたデータに対して木の葉の検索を行い、それが続く」というものである。別の事前定義された構文規則は、検索基準として、複数の符号化された値にマッチする条件を示す記法を用いて検索を行うというものであり、この規則では、値の範囲検索が可能であり、上述の記法は任意のもの又は値の範囲のうちの任意のものにマッチすることができるワイルドカードのようなものである。
【０１００】
図１３は、各検索が前回の検索によって発見されたデータに対して行われる一連の検索の流れを示す。まず、リソースＩＤがｖｍであるリソースの所定範囲においてｒｅａｄｌａｔｅｎｃｙ性能メトリックに対するクエリを実行する。このクエリは、図１４の１４０１に示される、分割によって得られた正規表現部分構文を有し、図１３のフローチャートでステップ１３０１によって表わされる。このとき、このクエリでは、まずデータのリソースタイプがｖｍでなければならず、今回ではリソースＩＤがｖｍ１及びｖｍ２ということになる。このクエリでは、ｒｅａｄｌａｔｅｎｃｙの属性が読み込まれると、クエリは、１４０１に示されるクエリの構文によって与えられるように、２０と１０００との間の性能メトリック値を探す。この性能メトリック値は図１２のテーブルに記録され、その各々はデータ格納の際に符号化方式によって符号化される。すなわち、図１４の正規表現セグメント１４０１によって確立されたクエリは、ｖｍタイプのリソースについてｒｅａｄｌａｔｅｎｃｙの全ての性能メトリック値を探し、これは図１２の時間スライスデータの場合、ｖｍ１及びｖｍ２のＩＤを有し、値が２０から１０００までのリソースを意味する。その後符号化された２０と１０００の値を元に正規表現に基づいた検索式が作成される。このときの検索式では、検索言語が範囲検索をサポートしていればそれに従って書いても良いし、サポートしていない場合は２０から１０００までの間の値をそれぞれ符号化し、２０から１０００までの範囲に含まれる値を符号化した文字集合にマッチングするものとしても良い。そして、正規表現に基づいた検索式に従って、先ほど読み込まれたデータに対してパターンマッチングを行い、合致するデータを取得する。今回の事例では、図１２のテーブルに含まれるデータのうち、リソースＩＤがｖｍ１、ｖｍ２のデータ、時間の範囲、及びリソースＩＤとしてｖｍ１、ｖｍ２、及びｒｅａｄｌａｔｅｎｃｙ性能メトリックが取得される。取得されたデータは、図１２のテーブルの破線１２０３で囲まれる領域である。すなわち、正規表現１４０１、１４０２、及び１４０３に符号化される検索は、その順序で実行され、各検索は前回の検索で発見されたマッチングデータへの検索に制限される。
【０１０１】
次に、属性がｒｅａｄｌａｔｅｎｃｙであるホスト性能メトリックに対するクエリが、分割によって得られた部分構文１４０２を有する正規表現を用いて実行され、このクエリは図１３のステップ１３０２によって表わされる。このときのデータの検索範囲は、リソースタイプがｈであるデータ、ここではリソースＩＤがｈ１であり、属性がｒｅａｄｌａｔｅｎｃｙであるデータのうち、時間の範囲が１３０１の過程で得られたものに限られる。検索の処理内容は、このデータに対して部分構文１４０２を評価することで得られ、これらの処理内容はステップ１３０２で適用される。その結果として、破線１２０２で囲まれる領域に含まれるデータのうち、リソースＩＤがｈｏｓｔ１のデータと、時間の範囲、及びリソースＩＤとしてｈ１が取得される。
【０１０２】
その後、分割によって得られた部分構文１４０３を有する正規表現を用いて、ステップ１３０３によって表わされるように、第３の限定検索が実行される。このときのデータの検索範囲は、時間の範囲がステップ１３０２で得られたデータに限られ、リソースタイプがｖｍ、つまり、今回はリソースＩＤがｖｍ１、ｖｍ２であるデータに対して検索が行われ、この検索は、属性がｒｅａｄｉｏｐであるデータに対して行われる。このデータに対して、部分構文１４０３を評価することで得られるこの検索の処理内容を、ステップ１３０３で適用する。その結果として、破線１２０３で囲まれる領域に含まれるデータのうち、リソースＩＤがｖｍ２のデータと、時間の範囲、及びリソースＩＤとしてｖｍ２が取得される。
【０１０３】
なお今回の事例では、入力された構文の評価を検索処理実施時に行なっているが、自動レポーティングといった同じ構文を何度も使用する場合には、構文の変換を事前に行うという実施形態も取り得る。幾つかの実施形態では、記述された検索が頻繁に実行される場合、この検索をユーザーによってカスタマイズすることができる検索テンプレートとして含めることもできるし、ユーザーを正規表現のシンタックスを知る必要から分離する問題空間で作業することを可能にするユーザーインターフェースから呼ぶことができる、「定型検索」に含めることもできる。
【０１０４】
本明細書では、このようなデータの絞り込みの過程をトラバースと表現する。
【０１０５】
クエリの構築に使用することができる基本シンタックス構築ブロック
ＸＰａｔｈ式データ処理／フィルタリング及びこの処理が様々な検索クエリに適用される。
<Resource Type>/<*Related resource type>[= <conf attrId> rx <regex> OR|AND
…][~<conf attr id>,,,][@<perf attr id> <rx b|d>|rxId <regex or regex pattern id>][$<event id,,,][+|-<related resource type]/{Related resource type/…}{Related resource type/…}
【０１０６】
関係トラバース：
<resource type>/<related resource type>/…. 
Ex: v/h/d
上記表現によって、以下のパスにとなる。
v->h->d
【０１０７】
複数トラバースパス:
<resource type>/{<related resource type>/....}{<another related type>/....}
この複数トラバースパスの構文規則を用いる処理の流れを図１５を用いて説明する。図１５において、ｖ、ｈ１、ｈ２はそれぞれ部分構文によって表わされるクエリである。まずｖの部分構文によって表わされるクエリが評価される（ステップ１５０１）。その後、部分構文ｖによって表わされるクエリから（発見されたデータ）の評価結果に対してｈ１、ｈ２の部分構文によって表わされるクエリがそれぞれ適用され、評価される（ステップ１５０２、１５０３）。その後、得られた結果をマージする（ステップ１５０４）。
例２
Ex: v/{h/n}{r/d}
上記サンプルの場合の処理の流れについて説明する。ここで、ｖ、ｈ、ｎ、ｒ及びｄは、全て、構文v/{h/n}{r/d}を有する全体のクエリの構文の一部分である正規表現として表現されるクエリを表わす。まずｖが評価され、その次にｖの評価結果に対してｈとｒがそれぞれ適用される。その後、ｈとｒのそれぞれの適用結果に対して、ｎとｄがそれぞれ適用される。最終的に、処理の流れとしては、下記の２つのパスが実行されたものとなり、処理結果としてこの２つの結果がマージされたものが得られる。
・v/h/n (v->h->n)
・v/r/d (v->r->d)
別の例
備考:クエリの数若しくはサブパスの数に制限はなく、かつ任意の数のレベルの入れ子パスが以下のサンプルに示される
ようにサポートされる:
Ex: v/{h/{r1/d1}{n}}{r2/d2}
上記サンプルの場合の処理の流れについて説明する。まずｖが評価され、その次にｖの評価結果に対してｈとｒ２がそれぞれ適用される。ｒ２の適用結果に対してはｄ２が適用される。一方、ｈの適用結果に対してはｒ１とｎがそれぞれ適用され、ｒ１の適用結果に対しては更にｄ１が適用される。最終的に、下記の３つのパスが実行されたものとなり、処理結果として、この３つの結果がマージされたものが得られる。
・v/h/r1/d1
・v/h/n
・v/r2/d2
【０１０８】
構成の変更の検索：
<resource type>[~ <attr id>, <attr id>,,,]
Ex: v/h[~attr1,attr2]/n
タイプ「ｖ」の全てのリソースをとり、構成属性ａｔｔｒ１及びａｔｔｒ２を有し、所与の時間窓内に変更を有するタイプ「ｈ」の関係リソースを見つける。次に、結果として生じるタイプ「ｈ」のリソースに関係するタイプ「ｎ」のリソースを見つける。
【０１０９】
性能データのパターンの発見：
<resource type>[@*<attr id> <rx b|d> |rxId <expression or id>][@....] 
<resource type>[@*#tw1#<attr Id> rx b|d <expr….>]/<r type>[@^tw1^ <attr id> <rx b| d> ….]
<resource type>[@*#tw1#<attr Id> rx b|d <expr….>]/<r type>[@#tw2#^tw1^ <attr id> <rx b|d> ….]
ただし、
＊：結果として生じるデータを無視する  １）続けて使用するための時間窓の導出に使用可能である  ２）論理パターンの構築に使用可能である
ｂ：バンドデータの場合  ｄ：デルタ値の場合
特記：実際の正規表現（regex）内の任意の数値（除外＝＞数量詞）には、「Ｕ」が前置されるべきであり、例えば、［４０−９０］｛５｝は［Ｕ４０−Ｕ９０］｛５｝になる。ここで、文字クラス内の数値は変更されたが、数量詞、すなわち、｛５｝は変更されない。
【０１１０】
様々なタイプの正規表現クエリの例
例
・v[@attr1 rx b U90+]/h
この構文を有するクエリは、所与の時間窓内で９０以上のメトリックａｔｔｒ１値の性能データを有する全ての仮想マシンを見つける。次に、各ホストを見つける。一致した性能データを返しもする。
・v[@attr1 rxId rxp1]/h
このクエリは、先行する例と同様であるが、個別のファイルで定義される正規表現パターンid(regex pattern id)を指定する。
処理結果の再利用:
・rt1[@#tw# attr1 attrCond1]/rt2[@^tw^ attr2 attrCond2]
このときの処理の流れを図１６に示す．まず、rt1[attr1 attrCond1]という部分構文によって表わされるクエリの評価結果がｔｗに束縛される。
その後、rt2[attr2 attrCond2]という部分構文によって表わされるクエリが評価されるが、その際に処理されるデータの範囲は、ｔｗに束縛されている時間範囲となる。
例
・v[@#tw1# attr1 rx b U90+]/h[@^tw1^ attr2 rx b U80+]
最初のメトリックは、続くパスでは任意の他のメトリックにより参照することができる期間Ｉｄ（ｔｗ１）を定義した。メトリックａｔｔｒ１が任意の一致データにより生成された場合、各時間窓にはｉｄ「ｔｗ１」が割り当てられ、同じ時間窓がメトリックattr2 [attr12 or attr2?]で使用される。接続されたホストが、結果として生成されるｔｗ１よりも更に狭い時間窓を有する場合、共通のスロットがメトリックａｔｔｒ２に使用されることに留意する。
【０１１１】
イベントフィルター：
シンタックス：[$*t:<regex pattern>,d:<regex pattern>]
ただし、
＊：結果として生じるデータを無視する（いかなる出力も生成しないが、論理パターンの構築に使用することができる）  ｔ：イベントのタイプを対象として検索する  ｄ：イベントの説明を対象として検索する
以下が有効である：
・[$t:rmAdded] //タイプチェック
・[$d:error] //説明チェック
・[$t:rmAdded,d:error] // 論理ＯＲ
・[$*t:rmAdded] //タイプチェック、結果を無視する
・[$*d:error] //説明チェック、結果を無視する
・[$*t:rmAdded,d:error] //論理ＯＲ、結果を無視する
【０１１２】
リソース加算／削除：
<resource type>[+ <related resource types added>,,,,][- <related resource types removed>,,,,] 
Ex: v[+h,d,n][-h,d]
上記表現は、タイプ「ｈ」、「ｄ」、「ｎ」の関係が追加されたか、又はタイプ「ｈ」、「ｄ」の関係が削除されたタイプ「ｖ」のリソースを返す。
一致する関係のデータの除外の仕方
<resource type>/*<related resource>/<sub resource>
Ex: v/*h/d
上記表現は、タイプ「ｖ」のリソース及びタイプ「ｄ」の関係リソースを直接返す。しかし、出力でタイプ「ｈ」の一致リソースのデータをスキップする。
備考：任意の上記組み合わせを混ぜることができる。同じクエリで構成変更、性能データフィルター、イベントリスト、マルチパス等を指定することができる。
【０１１３】
論理ＡＮＤ演算子
論理ＡＮＤ演算子はパスレベル及びフィルターレベルでサポートされる。  論理ＡＮＤ演算子を用いることで、処理の適用条件を絞ることができる。
パスレベル：
シンタックス: P1/[&]P2/[&]P3/P4....
パスレベルにおける論理ＡＮＤ演算子を用いた場合の処理の流れを説明する。まずＡＮＤ演算子を用いた処理の基本的な流れを図１７に記す。
ここで、図１７、１８、１９にあるｐ１、ｐ２、及びｐ３はそれぞれクエリ部分構文である。ｐ１／＆ｐ２と記述することで図１７で示されるように処理が実行され、ｐ２の部分構文を有するクエリで指定された条件が成立するときのみｐ１が評価される。
例１： p1/&p2 p1&&p2 備考:ｐ１は、ｐ２が適格の場合のみ適格である。
また、この演算子は重ねて使うこともできる。その際の処理の流れを図１８に記す。
例２： p1/&p2/&p3 p1&&p2&&p3 備考:ｐ２はｐ３に依存し、ｐ１はｐ２に依存する。
演算子によって実行可否が判定されるのは、論理ＡＮＤ演算子の１つ前までの部分構文までであり、それより前の部分構文は無条件で評価される。その際の処理の流れを図１９に示す。
例３： p1/p2/&p3 p1、p2&&p3 備考:ｐ１は、ｐ２の状態に関係なく適格とすることができるが、ｐ２は、ｐ３が適格の場合のみ適格とすることができる。
例４： p1/&p2/p3/&p4 p1&&p2、p3&&p4 備考:ｐ２はｐ３の状態に関係な適格とすることができる。
フィルターレベル
シンタックス: P1[filter1][&][filter2][&][filter3]/P2[filter1][&][filter2].....
フィルターレベルにおける論理ＡＮＤ演算子を用いた場合の処理の流れを説明する。
まず基本的な流れを図２０に記す。ここで、図２０、２１に出てくるｐ１は処理を表す部分構文、ｆ１、ｆ２、ｆ３はｐ１の処理に与えるデータをフィルターするフィルター処理を表す。
p1[f1]&[f2]と記述することで図２０のように処理が実行され、ｐ１の適用先データとしてｆ１及びｆ２の両方の条件を満たすデータを指定することができる。
例１： p1[=1001 rx Demo3]&[@2001 rx b U10+] 備考：Ｐ１は、両方のフィルターが一致を見つけた場合のみ適格である。
単純にフィルター処理を指定する部分構文を並べた場合はＯＲとしてみなされ、それは論理ＡＮＤ演算よりも先に適用される。その際の処理の流れを図２１に示す。
例２： p[f1][f2]&[f3] (f1||f2)&&f3
例３： p[f1]&[f2][&f3] f1&&f2&&f3
例４： p[f1][f2][f3] f1||f2||f3
例５： p[f1]&[f2][f3] f1&&(f2||f3)
備考：ｆ１に失敗する場合、終了する（ｆ２又はｆ３を処理しない）論理２０ＡＮＤへの短絡実行失敗。
例６： p[f1]&&&&&[f2] f1&&f2 備考: 複数の＆は１つに畳まれる。
例７： p[f1][f2]& f1||f2 備考: 最後の＆は無視される。
その他
正規表現パターンは、括弧を含むことができるが、一致するペアがある場合のみである。リソースがより高レベルのパスに含まれる場合、下位レベルのパスで繰り返されない。
例
v[=attr1 rx Demo3]/*h/v
結果の第３のレベルでは、Ｄｅｍｏ３は繰り返されない。
v[=attr1 rx Demo3]/h/v
【０１１４】
正規表現（Regex）パターン
クエリは、以下のフォーマットで個別のファイルで定義される正規表現文字列又は正規表現パターンｉｄの両方をサポートする：
<PatternList> <Pattern id=" " extraDataPoints=""><![CDATA[<pattern>]]></Pattern> </PatternList>
例
<PatternList> <Pattern id="rxp1" extraDataPoints="30"> <![CDATA[9+]]> </Pattern> </PatternList>
ｉｄ「ｒｘｐ２」を有するパターンは、正規表現パターンを性能データに直接適用する。
ＥｘｔｒａＤａｔａＰｏｉｎｔｓは、結果セットで使用されて、一致する値に加えて、追加のデータを返す。一致した値の前後に３０ポイントを追加する。
【０１１５】
クエリ処理フロー
構成データは、どのタイプのリソースが、システムに記憶された性能メトリックデータを有するか、及びリソースの各タイプの属性が何であるかをシステムに教える。上記属性のうちの幾つかは、性能データが測定された可能性がある。構成データは基本的に、どのリソースがその時間期間に存在したかを教える。
【０１１６】
図７は、クエリプロセッサの処理のフローチャートである。クエリプロセッサが開始されると、まず、クエリを読み出し、検索すべき性能データの間隔の開始時間及び終了時間を特定し、次に、構成データファイルを読み出して、クエリの時間フレームに関して（クエリ表現の開始日及び終了日を設定することによりユーザーにより設定される）、どのリソースが存在するか、又は存在したかを特定する。これらのプロセスはステップ２１０により表される。関連するクエリ間隔の一部分のみで単数又は複数のリソースが存在する場合、クエリプロセッサは、構成データから、これらのリソースが関連する間隔中に存在した有効時間を特定し、リソースがなお存在する場合、関連するクエリ間隔中のどの時間に、リソースが出現したのかを特定する。リソースは、サーバーがオフラインになる際、又はディスクが取り替えられる際等に出現し消えることがある。クエリ及び構成データファイルを読み出し、どのリソースが関連する間隔中の任意の時間に存在したかを特定することは、ステップ２１０により示される。構成ファイルは、どのリソースがクエリで指定されるリソースに関連するかを教えるデータも含む。例えば、特定のサーバー内に含まれるか、又は特定のサーバーに接続されたディスクが、そのサーバーに関連するものとして示される。
【０１１７】
サーバーは、構成ファイル内のこの全てのデータを読み出し、ステップ２１２において、関係リソースのみ、すなわち、図６のクエリで２０８において識別されたリソースタイプに一致し、クエリ間隔中の任意の時間に存在したシステムのリソース及び任意の関係リソースのマップを作成する。好ましくは実施形態では、２０８での文字列はリソースタイプのみを識別する。図６のこの例では、リソースタイプはホストである。ステップ２１４は、関係する日、関係するリソース（指定されたリソース及び関係リソース）、並びに関係する属性（クエリで指定された属性）について性能メトリックデータの１日全体をロードするプロセスを表す。これにより、後述するように、クエリで識別された開始時間に開始し、終了時間に終了する関係する間隔に含まれる１日又は複数日の全体でのそのタイプの全てのリソースの全ての性能データがメモリにロードされる。これらの開始時間及び終了時間は、ユーザーが、クエリボックス並びに開始時間ボックス及び終了時間ボックスを示すコンピューターのディスプレイとインタラクトすることにより、図６のクエリ表現を入力する際、クエリ表現ボックスからの個別のボックス（図示せず）においてユーザーにより与えられる。
【０１１８】
指定されていないタイプのリソースの性能データのこのフィルタリング除去により、クエリプロセッサは、図６のクエリシンタックスで２０８において示される関係リソースタイプのみについて、ＮＲＤＢに記憶された性能メトリックデータを容易かつ迅速に見つけることができる。
【０１１９】
次に、クエリプロセッサは、クエリ表現のパースを開始し、図６のクエリの要素２１３から、２０８で指定されたリソースタイプのどのタイプの属性データがＮＲＤＢに記憶されているかを特定するとともに、クエリプロセッサがクエリを実行するために何を必要とするかを特定する。図６のクエリの例では、クエリプロセッサは、クエリをパースし、その部分２１３を読み出し、２０８において文字列により識別される全てのホストに対してＣＰＵ使用率についてのメトリックデータに対して検索を実行すると決定する。これは、図７のステップ２１４により示される。
【０１２０】
また、ステップ２１４において、クエリプロセッサは、クエリ画面（図示せず）でユーザにより設定される開始時間（日時）及び終了時間（日時）を調べる。次に、クエリプロセッサは、ＮＲＤＢに行き、ディレクトリ構造を調べ、クエリの開始時間及び終了時間を含む関係する１日又は複数日のディレクトリ構造を見つける。次に、クエリプロセッサは、これらの関係ディレクトリ中のいずれの１つ又は複数のサブディレクトリが図６の２０８で示されるタイプのリソースの性能メトリックデータを含むかを特定する。次に、クエリプロセッサは、関係するサブディレクトリ中のテキストファイルを特定し、どのテキストファイルが、クエリ表現において識別された属性、すなわち、２１３において識別された属性を含む属性グループの性能メトリックデータを含むかを特定する。クエリプロセッサは、構成データファイルから、他のどのリソースが２０８で識別されたリソースタイプに関連するかも特定し、幾つかの実施形態では、関係する間隔のこれらの関係リソースの性能メトリックデータをメモリにロードする。これもステップ２１４の一部である。
【０１２１】
次に、ステップ２１６において、クエリプロセッサは、必要なデータがすでにキャッシュに記憶されているか否かを判断する。記憶されている場合、ディスク読み出しの時間を節約するために、必要なデータがキャッシュメモリからロードされる。必要なデータがキャッシュに記憶されていない場合、ステップ２１８において、クエリプロセッサは読み出し要求をオペレーティングシステムＡＰＩに送信して、クエリに必要なデータを含む適切な１つ又は複数のテキストファイルをメモリに読みこむ。ステップ２１８は、図６の２０８において文字列において識別されたタイプのリソース、及びクエリ表現の２１３において識別された属性を含む属性グループの１日全体分の性能データをロードする。
【０１２２】
ここで、関係する属性を含む属性グループ全体の、並びに開始日及び終了日にわたって広がる１日又は複数日全体の性能メトリックデータを含むファイルの全ての性能メトリックデータがメモリに記憶される。メモリ内のデータは、クエリで指定されていない属性の性能メトリックデータと、クエリで与えられる開始時間及び終了時間外の関係する属性の性能メトリックデータとの両方を含む。この過剰なデータをなくすために、クエリプロセスは、関係する属性のデータのみを含み、クエリで指定された開始時間のみで開始し、終了時間のみで終了する新しい文字列を構築する。このプロセスはステップ２２０により示される。これを行うために、クエリプロセッサは、２０８において識別された関係リソースの２１３において識別された関係属性の性能メトリックデータを含むロードファイル内の行を見つけ、指定された開始時間について記録された値に達するまでエントリをカウントする。その性能メトリック値及び終了時間まで続く全ての後続値は、ＮＲＤＢに記憶された順序と同じ順序で新しいファイルにコピーされ、これらは全てステップ２２０により示される。
【０１２３】
ステップ２２２において、２２１に示される正規表現の論理は、ステップ２２０において作成された新しいファイル内の性能データに適用されて、ステップ２０８において識別されたタイプのあらゆるリソースの検索クエリの２２１において正規表現で表現される基準を満たす値を見つける。そのようにして見つけられた値が返され、Ｕｎｉｃｏｄｅから再び、プローブから受信した元の性能メトリック値に復号化される。２０８において示されたタイプの複数のリソースからクエリに一致する複数のサブ文字列が見つけられる場合、そのような全ての一致するサブ文字列は、どのリソースが各文字列を返したかについての識別データとともに返される。好ましい実施形態を含む幾つかの実施形態では、また、リソース識別情報（図６の例では特定のホスト識別情報）、属性識別情報（図６の例ではＣＰＵ使用率）についてのメタデータと、クエリの開始時間及び終了時間、並びに返された値が記録された時間とが、結果の解析を助けるために返される。幾つかの実施形態では、真又は偽の結果のみが返される。幾つかの実施形態では、真の結果が返され、正規表現に一致した性能メトリック値のサブ文字列も、Ｕｎｉｃｏｄｅから、プローブから受信した性能メトリック値に復号化されて戻された後に返される。
【０１２４】
入れ子クエリ
問題を解決するために、性能メトリックデータのトラブルシューティングが必要である複雑な状況が生じることがある。一例は、ホストが複数の仮想マシンを実行中であり、そのうちの１つが著しく減速したか、又は応答を停止し、理由を特定する必要がある場合である。そのような場合、以下に与えられるような入れ子クエリセットを使用して、問題の原因を特定することができる。
vm[@readlatency rx b [U20-U1000] {5}/h[@readlatency rx b [U20-U1000]{5}/vm[@readiop rx b [U1000-U2000]{5}]
【０１２５】
上記クエリは実際には、性能データを掘り下げて、遅い仮想マシンに関する問題が何であるかを見つけ出すように設計された３つの入れ子クエリである。
【０１２６】
クエリの最初の部分は、vm[@readlatency rx b [U20-U1000]{5}/である。このクエリは、連続した５つの読み取り値でＵ２０〜Ｕ１０００である全ての仮想マシンの読み出し待ち時間属性（速度の尺度）を見る。この範囲Ｕ２０〜Ｕ１０００は、実行がかなり遅い全ての仮想マシンを見つける。
【０１２７】
次に、問いは、これらの仮想マシンの実行が何故遅いのかになる。それを見つけ出すために、１つの問いは、仮想マシン自体のコードを実行中のホストの実行が、何らかの理由により遅いことである。このクエリをパースするに当たり、クエリプロセッサは、クエリの開始時に文字列ｖｍにより識別された仮想マシンタイプに関係する全てのホストタイプリソースを特定する。これらの全てのホストの性能メトリックデータは、仮想マシンの性能メトリックデータが図７の処理に従ってメモリにロードされる際、メモリにロードされる。１つ又は複数のホストの実行が遅いか否かを見つけ出すために、クエリの第２の部分が使用される。その部分は、
h[@readlatency rx b [U20-U1000]{5}/
である。
【０１２８】
クエリのこの第２の部分は、クエリの第１の部分で識別された仮想マシンリソースタイプに関係するホストタイプリソースの全ての読み出し待ち時間性能メトリック値を見て、これらのホストのいずれの実行が遅いかを特定する。返されるデータは、どのホストが遅い読み出し待ち時間を有するかを示す。次に、問いは、このホスト又は複数のホストの実行が何故遅いかになる。それに答えるために、クエリの第３の部分が使用される。その部分は、ホストに関係するどの仮想マシンで、ホストを行き詰まらせている高いＩＯ動作が進行中であるかを特定する。クエリの第３の部分は、
vm[@readiop rx b [V1000-V2000]{5}]
である。
【０１２９】
このクエリは、高レベルの入出力動作が進行中である仮想マシンの識別情報を返す。この高レベルのＩ／Ｏ動作は、ホストのハードウェアを行き詰まらせ、他の仮想マシンが減速又は停止した理由を説明する。次に、結果を使用して、システムを行き詰まらせている仮想マシンをシャットダウンするか、又は他の仮想マシンを遅くしないように、動作を何らかの方法で変更する。
【０１３０】
例えば、返された結果は、ホスト１上の仮想マシン３が多数のＩ／Ｏ動作を実行中であるため、ホスト１上の仮想マシン１の実行が遅く、ホスト１の実行が遅いことを示す場合がある。３つのクエリに一致する別のデータセットが、ホスト２で実行中の仮想マシン４が多数のＩ／Ｏ動作を実行中であるため、ホスト２の実行が遅いことにより、ホスト２で実行中の仮想マシン２の実行が遅いことを示す場合もある。
【０１３１】
モジュール処理フロー
図８は、図８Ａ〜図８Ｃで構成される、プローブデータインポーターの処理のフローチャートである。プローブデータインポーターはデータインポートスケジューラールーチンを実行し、このルーチンは、ステップ２３０に示されるように、一定間隔でデータインポート動作を実行する。ステップ２３２は、処理すべき新しいデータを求めてプローブデータフォルダーをチェックする。テスト２３４は、新しいデータが到着したか否かを判断し、到着していない場合、処理はステップ２３０に戻る。新しいデータが到着していた場合、ステップ２３６が実行され、ファイルリストをパースして、ソートされた順で新しいデータ内の構成ファイル及び性能メトリックデータファイルのリストを得る。テスト２３８は、新しいデータが内部に性能メトリックデータを有するか否かを判断する。有する場合、ステップ２４０が実行されて、性能データをインポートする。新しいデータが内部に性能データファイルを有しない場合、処理はステップ２３８からステップ２４２にスキップし、ステップ２４２において、テストが実行されて、構成データが到着したか否かを判断する。到着していない場合、処理はステップ２３０に戻り、次のデータインポートを待つ。新しい構成データが到着していた場合、ステップ２４４が実行され、新しい構成データをインポートする。
【０１３２】
ステップ２４６は、ソートされたリスト内に列挙される性能メトリックデータファイルの処理を開始する。各リソースの関係性能カウンターは、記憶及びアクセス最適化のために一緒にグループ化される。ステップ２４８は、性能カウンターグループに基づいてファイルグループを作成し、１つのファイルグループが、性能カウンターグループごとに形成される。ステップ２５０は、スレッドプールを作成し、複数のスレッドでファイルグループを処理する。Ｊａｖａ  ＡＰＩ（ｊａｖａユーティリティの並列実行用パッケージ）を使用して、スレッドプールを作成し、各スレッドは一度に１つのファイルグループを取り上げて処理する。１つのファイルグループ処理が完了した後、同じスレッドは次のファイルグループがもしあれば、それを取り上げて処理し、プロセスは、全てのファイルグループが処理されるまで繰り返される。スレッドプール内の総合スレッドカウントが、アプリケーションプロプライエタリファイルを通じて構成される。ステップ２５２は各スレッドの処理である。各スレッドにおいて、ファイルが読み出され、ファイルで識別されたリソースが見つけられ、リソースカウンターグループが作成される。リソースごとに１つのリソースカウンターグループがある。ステップ２５４において、別のスレッドプールが形成され、リソースカウンターグループは、上記で説明したように処理される。ステップ２５６において、スレッドごとに、リソースカウンターグループデータが処理され、メモリ内のデータ構造が各リソースの収集された性能メトリックデータを反映するように更新される。リソースカウンターを使用して、各テキストファイルにおいて、各性能メトリックデータ値が収集された時間を適宜反映するために、この値を記憶すべき場所を特定する。最後に、ステップ２５８において、メモリにおいて作成されたデータ構造、すなわち、性能メトリック値がＵｎｉｃｏｄｅに変換され、本明細書の別の箇所に記載される構造に従ってテキストファイルに記憶される際に作成されたテキストファイルは、ＮＲＤＢの不揮発性記憶装置に書き込まれる。
【０１３３】
図８Ｃのステップ２６０は、ソートされたリストに列挙された構成ファイルの処理の開始を表す。ステップ２６２において、構成データファイルはパースされ、タイムスタンプ及びリソースシグネチャが見つけられる。テスト２６４は、リソースシグネチャにより識別されるリソースがＮＲＤＢで見つけられたか否かを判断する。見つけられない場合、ステップ２６６は、利用可能な構成データを使用してＮＲＤＢ内のミニスナップショットファイルを作成する。テスト２６４が、構成ファイルで識別されたリソースがＮＲＤＢ内にすでにあると判断した場合、ステップ２６８は、構成変更及びイベントがＮＲＤＢ内の更新ファイルに保存されるステップに飛ぶ。最後に、ステップ２７０において、メモリ内構成データは、ＮＲＤＢからの再ロードによりリフレッシュされる。
【０１３４】
図９は、図９Ａ及び図９Ｂで構成され、ＮＲＤＢアクセスマネージャーモジュールのモジュール図及び処理のフローチャートである。ＮＲＤＢアクセスマネージャーモジュール３００は、構成データ及び性能メトリックデータが記憶された非リレーショナルデータベースファイルシステム３０２へのアクセスを制御する。ＮＲＤＢアクセスマネージャーモジュール３００は、ＮＲＤＢからデータを索出し、モジュール３００を実行中のサーバーのメモリ内のキャッシュ３０４及びファイルシステム内のキャッシュ３０６を使用して、頻繁にアクセスされるデータを記憶し、データアクセスを加速させる。性能データ及び構成データは、上述した処理によりプローブデータインポーターモジュール３０８によりプローブからインポートされ、ＮＲＤＢアクセス管理モジュール３００を介してＮＲＤＢに配置される。ＮＲＤＢ内の性能メトリックデータを解析するクエリ要求は、クエリ要求ハンドラーモジュール３１０により処理され、クエリ要求ハンドラーモジュール３１０は、ＮＲＤＢアクセスマネージャーモジュール３００を介してＮＲＤＢ内のデータにアクセスする。
【０１３５】
図９Ｂでは、ＮＲＤＢアクセスマネージャーの処理は、クエリプロセスハンドラーから性能メトリックデータ要求を受信することで開始され、この要求はライン３１２により示される。ステップ３１４は、要求された性能データがシステムＲＡＭ及びファイルシステム内の性能データキャッシュ３０４内にあるか否かを判断する。ある場合、ステップ３１６に飛び、性能データがキャッシュからクエリプロセスハンドラー３１０に返される。テスト３１４が、要求された性能データがキャッシュ内にないと判断する場合、ステップ３１８が実行されて、要求されたデータをＮＲＤＢファイルシステムからキャッシュ３０４にロードし、次に、ステップ３１６が、要求されたデータをクエリプロセスハンドラー３１０に返す。
【０１３６】
プローブデータインポーター３０８は、ステップ３２０を通じて、データパス３２１を介して更新された構成データ、新しい構成データ、及び新しい性能データをＮＲＤＢに追加し、ＲＡＭ内の各構成データキャッシュ３２３又はＲＡＭ及びＮＲＤＢファイルシステム自体内の性能データキャッシュ３０４を更新する。ＮＲＤＢアクセスマネージャーは、性能メトリックデータを処理する前に、性能キャッシュを通じて性能メトリックデータのメモリ内表現（Ｊａｖａオブジェクト）を取得する。性能キャッシュはまず、メモリ内で、このデータがファイルからすでにロードされているか否かを確認する。ロードされていない場合、所与の日付のファイルからデータをロードする。データがない場合、その日の全てのサンプリング間隔のテンプレートデータ（デフォルト値）を用いてファイルを作成する。開始時間に基づいて、適切な場所のメモリ内性能メトリックデータを更新する。グループ内の全てのメトリックデータが処理されると、変更をファイルに戻してコミットする。データは、ファイルに保存される前に圧縮される（デフレートフォーマット）。
【０１３７】
図１０は、Ｍｅｇｈａ（商標）と呼ばれる中央サーバー内の主な機能モジュールを含むシステム全体の一実施形態のブロック図であり、Ｍｅｇｈａ（商標）では、性能メトリックデータ解析のクエリ要求処理が行われ、ＮＲＤＢが性能メトリックデータ及び構成データを記憶する。性能メトリックデータを問い合わせたい人は、クライアントコンピューター３３０で実行中のウェブブラウザーを使用して、ＲＥＳＴアプリケーションプログラムインターフェース（ＡＰＩ）を使用してＭｅｇｈａサーバーで実行中のウェブ要求コントローラー３３２に非同期要求を送信する。ウェブ要求コントローラー３３２は、要求を受信し、検証し、次に、非同期Ｊａｖａ  ＡＰＩ呼び出しを用いてクエリ要求プロセッサモジュール３１０に転送する。次に、ウェブ要求コントローラーは、クライアントが結果のために戻る必要があることを示唆することにより、クライアントコンピューター３３０にステータスを返す。クエリ要求プロセッサ３１０は、要求を処理し、結果を結果キャッシュ３１１に追加的に保存する。次に、クライアントコンピューター３３０は、結果要求をウェブ要求コントローラー３３２に返送し、要求コントローラー３３２は結果キャッシュ３１１をチェックする。次に、結果は、利用可能な場合、ウェブ要求コントローラー２３２によりクライアント３３０にＸＭＬフォーマットで返される。クエリ要求プロセッサがまだ要求を処理中の場合、ウェブ要求コントローラーは、クライアントが後に別の結果要求を送信する必要があることを示すステータスヒントをクライアントに送信する。リポートエンジン３１３は、Ｊａｖａ  ＡＰＩインボケーションを用いてクエリ要求をクエリ要求プロセッサ３１０に非同期送信し、Ｊａｖａ  ＡＰＩを通じて結果データを結果キャッシュ３１１から読み出すＪａｖａクラスオブジェクトである。
【０１３８】
図１１は、クエリ要求プロセッサの一実施形態による処理のフローチャートである。ステップ３２０は検索クエリをパースする。検索クエリが無効フォーマットを有する場合、結果キャッシュはエラーで更新され、処理は終了する。各クエリは、高レベルリソースタイプで開始される。クエリ要求プロセッサは、リソースタイプを読み出し、ステップ３２２において、クエリで指定されたタイプの全てのリソースのＮＲＤＢ内の全ての性能メトリックデータを要求することにより応答する。その要求は、ＮＲＤＢアクセスマネージャーを通じて行われる。ステップ３２４において、スレッドプールが作成されて、クエリで識別されたタイプの各リソースからのデータを処理する。各スレッドは、クエリで識別されたタイプのリソースの１つからのデータを処理する。作成されるスレッドの数は、アプリケーションプロプライエタリファイルに構成される。
【０１３９】
ステップ３２６において、クエリで指定される任意のフィルターが適用される。フィルターは、構成属性一致、イベント、性能データパターン等のようなものとすることができる。指定された全てのフィルターは、順番に適用される。例えば、以下のクエリ
vm[=name rx exchangevm1][$t:Network adapter added][@usedCapacity rx b u40+]
は、指定された１つの構成属性一致フィルター、イベントフィルター、及び１つの性能データパターン一致フィルターを有する。
【０１４０】
フィルターを適用した後、スレッドが、リソースの性能メトリックデータがテスト３２８においてクエリで指定された基準を満たすことを見つけた場合、テスト３３０が実行される。テスト３２８が、リソースの性能メトリックデータがクエリの基準を満たさないと判断した場合、ステップ３３１が実行されて、性能メトリックデータを破棄する。ステップ３３０において、クエリが調べられて、クエリで指定されたサブリソースへのサブパスがあるか否かを判断する。指定されたサブパスがある場合、サブリソースへのサブパスの性能メトリックデータがＮＲＤＢからロードされる。次に、任意の指定されたフィルターが再びステップ３２６において適用され、サブリソースが適格であるか否か、すなわち、サブリソースの性能メトリックデータがクエリで指定された基準を満たすか否かを判断する。このプロセスは、クエリで指定される、サブリソースへの全てのサブパスが処理されるまで続けられる。サブパスがなくなった場合、又は元々、サブパスが指定されていないかった場合、テスト３３２が実行されて、最上位レベルリソースが適格であるか否かを判断し、適格ではない場合、データはステップ３３１において破棄される。最上位レベルリソースが適格の場合、ステップ３３４において、適格なリソースを、クエリで指定された基準を満たす任意の性能データとともに、結果キャッシュに追加する。
【０１４１】
上述された実施形態の趣旨及び範囲から逸脱しない適切な代替の実施形態を当業者は理解しよう。全てのそのような代替の実施形態は、本明細書に添付される特許請求の範囲内に含まれることが意図される。
【図１】
2016521402.tif 000003
【図２】
2016521402.tif 000004
【図３】
2016521402.tif 000005
【図４】
2016521402.tif 000006
【図５】
2016521402.tif 000007
【図６】
2016521402.tif 000008
【図７】
2016521402.tif 000009
【図８Ａ】
2016521402.tif 000010
【図８Ｂ】
2016521402.tif 000011
【図８Ｃ】
2016521402.tif 000012
【図９Ａ】
2016521402.tif 000013
【図９Ｂ】
2016521402.tif 000014
【図１０】
2016521402.tif 000015
【図１１】
2016521402.tif 000016
【図１２】
2016521402.tif 000017
【図１３】
2016521402.tif 000018
【図１４】
2016521402.tif 000019
【図１５】
2016521402.tif 000020
【図１６】
2016521402.tif 000021
【図１７】
2016521402.tif 000022
【図１８】
2016521402.tif 000023
【図１９】
2016521402.tif 000024
【図２０】
2016521402.tif 000025
【図２１】
2016521402.tif 000026
【図２２】
2016521402.tif 000027
【図２３】
2016521402.tif 000028
【図２４】
2016521402.tif 000029
【図２５】
2016521402.tif 000030
【図２６】
2016521402.tif 000031
【図２７】
2016521402.tif 000032
【国際調査報告】
2016521402.tif 000033
2016521402.tif 000034
2016521402.tif 000035