JP5538810B2 - 監視のための大量データ記憶システム - Google Patents

Description

ウェブサービスなどの大規模なデータ処理システムは、メトリクス（metrics）を含む大量のログデータを生成することができる。時には、このようなデータを見直して、データ処理システムにおける問題点を診断してもよい。しかし、このようなシステムによって生成されたログデータ量は、データの記憶と見直しの点において、著しい困難を呈する可能性がある。

大規模なウェブサービスを実行するシステムなどの種々の大規模なコンピュータシステムは、このようなサービス性能の時間経過を記述するメトリクスの形の大量データを生成することができる。例えば、大規模な電子商取引システムが毎日実行する商取引の数は、数百万以上もの範囲に達し、その結果、このようなシステムの性能に関してテラバイト規模で生成された大量のログデータおよび／またはメトリクスとなる。このようなサービスの運営に何か異常が発生すると、担当者は、サービスに関する問題を診断し、最終的には解決策を実施するために、メトリクスを含むかもしれないログデータを探索することが多い。

しかし、このようなサービスがますます大量になるに伴い、サービスが生成するメトリクスの量は増加する。その結果、システムの正常な動作によって生成されるログ項目またはメトリクスの全てを記憶することが問題となる。また、含まれるデータが大量になるため、メトリクスを探索してサービスが経験する問題を診断および修復することはより困難になる。

本発明の開示の様々な実施形態によれば、メトリクスを表す大量データが、監視する出力を生成して、大規模なシステムを操作する各個人が、任意の所定の時間にこのようなシステムの動作の健康状態を知ることができるような方法で記憶される種々のシステムから受信される。様々な実施形態においては、所定のサービスまたはシステムによって生成されるメトリクス全てを記憶するのではなく、受信されたメトリクスの集合を含む、より小さい記憶空間を占めるデータモデルが生成される。データモデルは、たとえ元のデータメトリクスが記憶されず、最終的に破棄されたとしても、所定のシステムの動作の監視が達成されるものである。様々な実施形態によるデータモデルの記憶は、メトリクスのソースが、本明細書で説明されている種々のアプリケーションによってデータがどのように記憶されるかに関する制御を維持するという意味で、駆動されたデータである。

本発明の開示の一実施形態によるデータ通信ネットワークのブロック図である。 本発明の開示の一実施形態による、データソースから図１のデータ通信ネットワーク内のサーバに送信されるメトリック(metric)の図である。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおける、データ記憶アプリケーションの動作の一例を示した図である。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおける、データ記憶アプリケーションの動作の別の例を示した図である。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおいて実行される集合アプリケーションの種々の機能の一例を示したフローチャートである。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおいて実行される集合アプリケーションの別の機能の別の例を示したフローチャートである。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおいて実行されるメトリック・ディレクトリ・アプリケーションの機能の一例を示したフローチャートである。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバにおいて実行されるメトリック・ディレクトリ・アプリケーションの別の機能の一例を示したフローチャートである。 本発明の開示の一実施形態による、図１のデータ通信ネットワーク内のサーバの一例の概略ブロック図である。

本発明の開示の多くの態様は、以下の図面を参照することにより詳細に理解できる。図面におけるコンポーネントは、必ずしも一定の縮尺で記載されておらず、代わりに、本発明の開示の原理を明確に説明することに重点が置かれている。さらに、図中の同様の参照符号は、複数の図面を通して対応する部品を指す。

図１を参照すると、本発明の開示の様々な実施形態によるデータ通信ネットワーク１００が示されている。データ通信ネットワーク１００は、種々のネットワーク上を相互に通信する種々のデバイスを含む。このようなネットワークは、例えば、インターネット、イントラネット、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク、無線ネットワークもしくは他の適切なネットワークなど、または２つ以上のこれらのネットワークの任意の組み合わせを含んでもよい。

様々な実施形態による１つ以上のサーバ１０３が、データ通信ネットワーク１００内の各種デバイスの中にある。１つ以上のサーバ１０３は、理解できるように、例えば、１つ以上のサーババンク内に配置されてもよく、サーバコンピュータを備えてもよい。サーバ１０３は、理解できるように、単一施設内に設置されてもよく、または、複数の地理的に離れた場所に分散されてもよい。便宜上、本明細書では、１つ以上のサーバ１０３はサーバ１０３と称するが、本明細書で引用されるサーバ１０３は複数のサーバを表すこともあることが理解される。

さらに、データ通信ネットワーク１００は、データストリームとしてサーバ１０３に送信され得るログおよび／またはメトリクス１０９を生成する被監視システム１０６を含む。この点に関し、本明細書で考えるようなデータストリームは、理解できるように、例えばバッチ転送または他の転送を採用し得る種々の転送方法を表している。被監視システム１０６は、メトリクス１０９を生成するサービスまたは物理システムの一例である。

この目的を達成するために、メトリクス１０９は、被監視システム１０６の状態を記述してもよい。この被監視システムの状態には、理解できるように、例えば、被監視システム１０６の性能またはメトリック１０９によって定量化され得る他のステータス情報の態様を含んでもよい。例えば、被監視システム１０６は、種々の機能を実行し、機能の性能の特性を記述した種々のメトリクス１０９を生成する実際のサーバコンピュータなどの、ハードウェアベースのシステムを備えてもよい。あるいは、被監視システム１０６は、理解できるように、１つ以上のサーバコンピュータにおいて実行されるウェブサービスまたは他のサービスなどのアプリケーションを備えてもよい。

データ通信ネットワーク１００は、後述するように、サーバ１０３上で各種のサービスと通信する少なくとも１つのクライアント１１３をさらに含む。クライアント１１３は、例えば、デスクトップ型、ラップトップ型、または同様の能力を備える他のコンピュータシステムなど種々のタイプのコンピュータシステムを備えてもよい。この目的を達成するために、クライアント１１３はまた、理解できるように、携帯情報端末、携帯電話、または同様の能力を備える他の携帯用装置を備えてもよい。クライアント１１３は、理解できるように、ブラウザアプリケーション、専用アプリケーション、または他のアプリケーションなど種々のアプリケーションを用いて、サーバ１０３とインターフェースしてもよい。

様々な実施形態に基づいてサーバ１０３で実行される種々のアプリケーションがある。また、後述するように、１つ以上のデータ記憶が、データを記憶するためにサーバ１０３に関連付けされてもよい。サーバ１０３上で実行されるアプリケーションの中には、認証アプリケーション１２３、集合アプリケーション１２６、データ記憶アプリケーション１２９、監視サービス１３３、およびネットワーク・サーバ・アプリケーション１３６がある。さらに、種々のアプリケーションの動作に基づいてデータを記憶するために、サーバ１０３内には種々の記憶キューがある。このような記憶キューは、集合キュー１４３と記憶キュー１４６とを含む。上述のアプリケーションは、それらアプリケーションが実行する機能をどのように構成し得るかについての単なる例であることが理解される。しかし、理解できるように、代替の構成で構成された異なるアプリケーションセットを用いて同じ機能を実行することも可能である。

さらに、データ記憶１４９は、サーバ１０３にアクセス可能なメモリ内に記憶されている。後述するように、メトリクス１０９を表すデータモデル１５１が、データ記憶１４９に記憶されている。この目的を達成するために、データ記憶１４９に記憶されるデータモデル１５１は、ディメンション(dimension)１５３に関係付けされる。ディメンション１５３は、被監視システム１０６からサーバ１０３内に受信されたメトリクス１０９に関連付けて特定される。各データモデル１５１は、時間帯１５６と関連付けて記憶される。各時間帯１５６は、データ記憶１４９内のディメンション１５３のそれぞれ１つと関連付けされている。各時間帯１５６は、所定のディメンション１５３に関連する、複数の連続の時間帯のうちの１つを含む。ディメンション１５３は、ディメンションラベルと値とを有するキーペアを含む。

上述のように、被監視システム１０６は、ネットワークまたは他の通信システムを介してサーバ１０３に送信または転送されるメトリクス１０９を生成する。あるいは、被監視システム１０６がサーバ１０３内で実行されてもよく、この場合、転送はサーバ１０３内のアプリケーション間の転送を必要とする。

メトリクス１０９は、メトリクス１０９が、事前に定義された特定の転送プロトコルおよび／またはフォーマットに適合することを最初に保証する認証アプリケーション１２３によって受信される。さらに、認証アプリケーション１２３は、後述するように、メトリクス１０９によって特定されたディメンション１５３の数が時間経過に伴って所定のしきい値を超えないことを保証するか、またはそうでない場合は、ディメンションオーバーランを示さないことを保証するように構成される。メトリクス１０９が認証アプリケーション１２３によって認証されると、メトリクス１０９は集合キュー１４３内に置かれ、集合アプリケーション１２６によって作動される。

集合アプリケーション１２６は、集合キュー１４３内のメトリクス１０９を処理し、その結果を記憶キュー１４６に供給し、データ記憶アプリケーション１２９によってデータ記憶１４９に記憶されるようにする。様々な実施形態によれば、集合アプリケーション１２６は、各時間帯１５６に対する複数のメトリクス１０９を集める役割を果たす。この目的を達成するために、集合アプリケーション１２６は、サーバ１０３内に受信され、および認証アプリケーション１２３によって認証されたメトリクス１０９の時間集合を実行するように構成されている。

詳細に説明すると、様々な実施形態によれば、メトリクス１０９が認証アプリケーション１２３内に受信される速度は極めて速い。例えば、受信されるメトリクス１０９は、例えば、１日に３０テラバイトなど、１日に複数のテラバイトのデータを含むことが可能である。ただし、フローの速度は、この水準より小さくても大きくてもよい。場合によっては、このようなフロー速度は、毎分２００，０００、または最大で５００，０００またはそれ以上のメトリクスを含んでもよいが、フロー速度は任意の速度であってもよい。このようなメトリクス１０９をそれぞれ記憶するのは、経済的にも、また必要な記憶空間や設備といった点からもかなり費用を要する可能性がある。

一実施形態によれば、メトリクス１０９自体を全て記憶しようとするのではなく、データモデル１５１が、複数の連続の時間帯１５６のうちのそれぞれ１つに関連付けて構成される。別の表現をすれば、各連続の時間帯１５６に関連するメトリクス１０９はデータモデル１５１によって表される。一実施形態によれば、データモデル１５１を生成する処理は、各連続の時間帯１５６に対するメトリクス１０９を集合し、それによって１つ以上の集合メトリクスを生成することを含む。この目的を達成するために、データモデル１５１は１つ以上の集合メトリクスを含んでもよい。

例えば、時間帯１５６は任意の時間間隔として特定できることが理解されるが、連続の時間帯１５６のそれぞれを１分と特定する。時間帯１５６のうちの所定の１つの時間帯に関連する各メトリック１０９は、時間帯１５６を表すデータモデル１５１内に集められる。したがって、所定の１分の時間帯１５６に対して、時間帯１５６に関連する各メトリック１０９がその時間帯１５６に対するデータモデル１５１内に集められる。複数のメトリクス１０９をデータモデル１５１内に集めるために、後述のように、種々の計算が実行されてもよい。最終的に、各時間帯１５６に関連するデータモデル１５１は、時間帯１５６に対するメトリクス１０９に関する種々の情報を表す多数の値を含んでもよい。

メトリック１０９は、例えば、メトリック１０９が、時間帯１５６自体の中にあるタイムスタンプを有する場合、所定の時間帯１５６に関連付けられる。所定のメトリック１０９に関連するタイムスタンプは、被監視システム１０６によって生成されてもよく、または認証システム１２３によって生成されてもよく、サーバ１０３内にメトリック１０９を受信するときにメトリック１０９に関連付けされてもよい。

所定のメトリック１０９は、複数の時間帯１５６に対する集合内に含まれてもよく、その場合、各時間帯１５６は複数の異なるディメンション１５３のうちの１つに関連付けされている。本発明の開示の様々な実施形態によれば、ディメンション１５３は、データ記憶１４９内でデータモデル１５１が保持されるカテゴリーである。様々な実施形態によれば、１つ以上のディメンション１５３が、サーバ１０３内に受信された各メトリック１０９に関連付けられている。ディメンション１５３は、最終的には、データ記憶１４９へのデータモデル１５１の記憶を組織化するために用いられる。すなわち、所定の時間帯１５６に関連するデータモデル１５１はそれぞれ、ディメンション１５３のうちの１つに関連付けしてデータ記憶１４９に記憶される。

メトリック１０９が、例えば１つ以上の関連ディメンション１５３と共に、サーバ１０３内に受信されると、メトリック１０９は、関連するディメンション１５３のそれぞれに対する各時間帯１５６に関連する集合内で使用される。このように、所定のメトリック１０９は、メトリック１０９に関連するディメンション１５３の各時間帯１５６に関連する複数の異なるデータモデル１５１に結果的になる集合内で使用されてもよい。

この目的を達成するために、集合アプリケーション１２６が所定のメトリック１０９を処理するとき、アプリケーション１２６はメトリック１０９に関連するディメンション１５３を決定する。その後、集合アプリケーション１２６は、メトリック１０９と共に含まれているディメンション１５３に関連する各時間帯１５６に対するデータモデル１５１に結果的になる集合内にメトリック１０９を含む。

一実施形態によれば、メトリック１０９が、それぞれのディメンション１５３の１つ以上の時間帯１５６に対して実行される集合内に含まれると、集合アプリケーション１２６はメトリック１０９を破棄する。この点から、生成されたメトリクス１０９が実際はもはや存在しないため、被監視システム１０６の動作に関する診断または他の機能を実行するために、各時間帯１５６に対するデータモデル１５１のみがアクセスされてもよい。別の表現をすれば、データモデル１５１の生成を結果的にもたらす集合の後は、実際のメトリクス１０９は、実際には記憶されていないため回復することができない。これは、時間帯１５６に関連してデータモデル１５１を記憶する記憶空間の量が、実際のメトリクス１０９自体を記憶するのに必要となる記憶空間の量よりも実質的に少ないため、有利である。実際のメトリクス１０９の代わりにデータモデル１５１を記憶することは、例えば、１０００対１の比率または他の比率で、記憶されるデータが減ることを意味する可能性がある。

一実施形態によれば、データの記憶がデータ記憶１４９内でそれにより組織化されるディメンション１５３は、サーバ１０３内に受信されたメトリック１０９内にディメンション１５３が出現することに基づいて、増大または拡大されてもよい。この意味では、ディメンション１５３を増大または拡大するとは、既存のディメンションに新しいディメンション１５３を加えることを意味する。一実施形態によれば、新しいディメンション１５３は、メトリック１０９に関連して最初に出現するだけで生成される。様々な実施形態によれば、集合アプリケーション１２６は、集合アプリケーション１２６が、メトリック１０９に関連する新しいディメンション１５３と遭遇すると、最初に新しいディメンション１５３を含むメトリック１０９のタイムスタンプを含む待ち状態の時間帯１５６で始まる新しいディメンション１５３に対する後続のメトリクス１０９の集合を開始するように、構成されている。

この点に関して、データモデル１５１の記憶は、駆動されたデータである。データ記憶１４９内でデータモデル１５１がそれに関連付けされるディメンション１５３は、サーバ１０３内に受信されたメトリクス１０９に基づいて生成される。別の表現をすれば、ディメンション１５３は、データ記憶１４９内で事前に構成されておらず、または特定されていない。これは、有利には、メトリクス１０９の記憶において、被監視システム１０６のオペレータに大きい自由度を提供する。具体的には、メトリクス１０９が集められ、記憶されるディメンション１５３に関する制御は、被監視システム１０６のオペレータによって維持される。

同時に、認証システム１２３は、ディメンション１５３の拡大がエラーを含むかどうかを検出するように構成されている。これは、後述するように、例えば、拡大によって、所定の被監視システム１０６がディメンション１５３を過大に生成する結果となる場合に発生することがある。例えば、認証アプリケーション１２３は、所定のエンティティに対するディメンション１５３の数を、以前の合意に基づいた任意の所定の時間におけるディメンション１５３のしきい値に限定するように構成されてもよい。この限界を超えると、認証システム１２３は、ディメンション１５３が拡大したことによって、ディメンション１５３の許容可能なしきい値を超えるディメンション１５３の総数となったことを現場の担当者に知らせるサーバ１０３内でエラーを生成し得る。

あるいは、認証アプリケーション１２３は、新しいディメンション１５３が、実際には、新しいかまたは以前に存在していないディメンション１５３が誤って出現する結果をもたらす、以前の既存のディメンション１５３の誤った変数であるかどうかを検出することによって、ディメンション１５３の拡大がエラーを含むかどうかを検出するように構成されてもよい。例えば、場合によっては、被監視システム１０６は、所定のディメンション１５３をタイムスタンプまたは他のデータに追加してもよい。

時間帯１５６に関連するタイムスタンプを有する受信された別のメトリクス１０９が存在しない状態が現れるため、所定の時間帯１５６に対する集合が完了したと見なされると、集合の結果得られたデータモデル１５１は、記憶キュー１４６内に置かれ、それぞれのディメンション１５３に関連付けてデータ記憶１４９内に記憶される。したがって、データ記憶１４９内の各ディメンション１５３に対するデータは、複数の連続の時間帯１５６に関連するデータを含む。

一実施形態によれば、データモデル１５１は、限定された時間帯に対して、データ記憶１４９に記憶される。この目的を達成するために、データ記憶アプリケーション１２９は、所定の時間帯に対してデータモデルを記憶した後、データモデル１５１を破棄するよう構成されてもよい。記憶時間の長さは、記憶空間がどのくらい存在するか、データモデル１５１または記憶される他のデータによって示されるデータ量がどのくらい存在するか、および／またはデータを記憶する目的によって変化する可能性がある。このような時間帯は、例えば、２週間または他の期間である場合もある。いずれにせよ、例えば事業目的などのデータを記憶する目的が、使用される記憶空間の量などに関わらず、記憶時間が特定されることを要求する場合もある。

さらに、監視サービス１３３は、クライアント１１３からの要求に応じて、データ記憶１４９内に記憶されたデータモデル１５１に基づいて、情報を提供するように構成されている。このように、監視サービス１３３は、データ記憶１４９内に記憶されたデータモデル１５１に基づいて被監視システム１０６の性能を表す出力を生成するように構成されている。

この目的を達成するために、ネットワーク・サーバ・アプリケーション１３６は、監視サービス１３３へのブラウザアクセスまたは他のアクセスが容易になるウェブサーバまたは他のサーバアプリケーションを備えてもよい。監視サービス１３３は、データ記憶１４９内に記憶されたデータに基づいてレポートを生成するように構成されてもよい。このようなレポートは、被監視システム１０６の過去の性能に関する情報を中継してもよい。レポートは、所定のエンティティに対するクライアント１１３に送信されるように、事前に決定され、自動的に生成されてもよく、クライアント１１３によってリアルタイムに要求されてもよい。例えば、所定のエンティティが、データがデータ記憶１４９内に記憶されたディメンション１５３に基づいて、特定のレポートなどを要求してもよい。さらに、クライアント１１３に提供するレポートその他を生成する際に別の方法を採用して、被監視システム１０６の動作の健康状態を監視できるようにしてもよい。

さらに、別の実施形態によれば、サーバ上で実行可能なアプリケーションはさらに、データ記憶１６６内の１つ以上のアクティブ・メトリック・リスト１６９を維持するメトリック・ディレクトリ・アプリケーション１６３を含む。メトリック・ディレクトリ・アプリケーション１６３は、データモデル１５１がそれに対して検索され得るアクティブメトリクス１０９のリストを保持する役割を果たす。この目的を達成するために、メトリック１０９の１つ以上のインスタンスから生成されたデータモデル１５１が、データ記憶１４９に記憶されるたびに、そのデータモデルのコピーがメトリック・ディレクトリ・アプリケーション１６３に供給される。あるいは、メトリクス１０９自体のコピーがメトリック・ディレクトリ・アプリケーション１６３に送信されてもよい。アクティブ・メトリック・リスト１６９はそれぞれ、表、データベースまたは他のデータ構造の形で記憶されてもよい。

受信されたデータモデル１５１のコピーに基づいて、メトリック・ディレクトリ・アプリケーション１６３が１つ以上のアクティブ・メトリック・リスト１６９を保持する。具体的には、アクティブ・メトリック・リスト１６９は、監視サービス１３３を介してアクセスされ得るデータ記憶１４９内に現在記憶されているアクティブメトリクス１６９のリストを含む。具体的には、被監視システム１０６の動作を監視する目的でデータモデル１５１内に組み込まれたデータにアクセスするために、クライアント１１３は、最初、データ記憶１４９内でデータがそれに対して記憶されているメトリクス１０９のディレクトリを要求することができる。あるいは、このようなディレクトリは、クライアント１１３がホームページまたは他の入力の開始点においてデータ記憶１４９内のデータにアクセスを試みるときに、自動的に生成されてもよい。アクティブ・メトリック・リスト１６９は、例えば、メトリクス１０９をサーバ１０３に送信する所定のエンティティに関連付けられてもよい。

要求に応じて、または、クライアント１１３に送信される、例えば、ホームページなどの最初のポータルを作成する際に、メトリック・ディレクトリ・アプリケーション１６３は、クライアント１１３に提示するために、データ記憶１４９内にデータモデル１５１がそれに対して現在記憶されているアクティブメトリクス１０９の現在リストまたはディレクトリを生成するように構成される。アクティブメトリクス１０９の現在リストまたはディレクトリが、実際に現在のものであることを保証するために、メトリック・ディレクトリ・アプリケーション１６３は、アクティブ・メトリック・リスト１６９を保持するよう構成される。

これを実現するために、一実施形態によれば、被監視システム１０６から受信されたメトリック１０９の最後のインスタンスが、所定の時間帯よりも長くデータ記憶１４９に記憶されている場合、メトリック１０９はアクティブ・メトリック・リスト１６９に記載されない。一例では、このような時間帯は、分、時間、日、週、月または他の間隔で測定されるいずれの時間帯であってもよい。一例の時間帯は、２週間であってもよい。しかし、時間帯は、利用可能な記憶空間などの要因や他の変数によって変化してもよい。

一実施形態によれば、メトリック・ディレクトリ・アプリケーション１６３が、メトリック１０９自体の形の、または、アクティブ・メトリック・リスト１６９にリストアップされていないデータモデル１５１として、集合アプリケーション１２６から新しいメトリック１０９を受信すると、メトリック・ディレクトリ・アプリケーション１６３は、メトリック１０９に関連した現在のタイムスタンプを識別し、メトリック１０９に関する情報と、それぞれのアクティブ・メトリック・リスト１６９内の現在のタイムスタンプとを記憶する。

メトリック１０９がアクティブ・メトリック・リスト１６９内に以前から含まれている場合は、メトリック・ディレクトリ・アプリケーション１６３は、単に、メトリック１０９の最新に受信したインスタンスのタイムスタンプを有するメトリック１０９に関連するタイムスタンプを更新する。このようにして、現在のアクティブメトリクス１０９および／またはアクティブ・メトリック・リスト１６９内のデータモデル１５１の最新リストが維持される。

さらに、アクティブ・メトリック・リスト１６９内の所定のメトリック１０９に関連するタイムスタンプがメトリック１０９に関連する最新のデータが、上述の所定の記憶時間帯よりも長くデータ記憶１４９に記憶されていたことを示す場合は、メトリック・ディレクトリ・アプリケーション１６３は、続いて、このようなメトリック１０９をアクティブ・メトリック・リスト１６９から除去する。例えば、データモデル１５１が所定の記憶時間帯でデータ記憶１４９にのみ記憶されていると仮定すると、このようなデータモデル１５１はそれらが破棄されているため、利用できない。このような状況で、アクティブ・メトリック・リスト１６９にリストアップされたメトリクス１０９は古くなっていく。したがって、メトリック・ディレクトリ・アプリケーション１６３によって、アクティブ・メトリック・リスト１６９から古くなったメトリクス１０９を除去することによって、クライアント１１３は確実に、データ記憶１４９内に存在しないメトリクス１０９へのアクセスを試みないようになる。

さらに、所定の被監視システム１０６を作動するエンティティは、プライバシーまたは安全への配慮により、アクティブ・メトリック・リスト１６９内にメトリクス１０９を含むことを選択しない場合もある。この目的を達成するために、このようなエンティティによって、サーバ１０３内に送信されるメトリクス１０９に識別子を含むようにし、この識別子によりそのようなメトリクス１０９を無視するかまたは破棄するようにメトリック・ディレクトリ・アプリケーション１６３に指示して、そのようなメトリクス１０９がアクティブ・メトリック・リスト１６９内に含まれないようにしてもよい。

図２を参照すると、本発明の開示の一実施形態による被監視システム１０６によって生成されたメトリック１０９（図１）の一例が示されている。メトリック１０９は、拡張可能なマークアップ言語（ＸＭＬ）で表現されるが、理解できるように、メトリック１０９は他の言語およびフォーマットで表現されてもよいことが理解される。メトリック１０９は、例えば、「ネーム」、「ネームスペース」、「ウェブサイト」、「ページタイプ」および「サーバ」などのディメンション１５３（図１）を含む。これらのディメンション１５３は、所定のメトリクス１０９に含まれ得る多数の異なる種類のディメンション１５３の単なる例であることが理解される。この目的を達成するために、ディメンション１５３は、理解されるように、１つの変数または他の値まで減少し得る任意のカテゴリーであってもよい。メトリック１０９が生成された時間を示すタイムスタンプ１７３がさらに、メトリック１０９に関連付けられる。ディメンション１５３は「ネーム」および「ネームスペース」を含むものとして示されているが、実施形態によっては、これらのフィールドはディメンション１５３を含まず、「ディメンション」ネストの外側のメトリック１０９内のいずれの位置に置かれてもよい。

このようにして、タイムスタンプ１７３は、メトリック１０９が生成された時点における被監視システム１０６の状態を識別できる。図２の例では、タイムスタンプ１７３は、ウェブページの作成に関連する待ち時間を示す。したがって、ページ自体が作成された後に待ち時間が特定されると、タイムスタンプ１７３が生成される。あるいは、メトリック１０９は、タイムスタンプ１７３なしにサーバ１０３（図１）で受信されてもよい。このような場合、認証アプリケーション１２３は、メトリック１０９を受信次第、タイムスタンプ１７３を生成し、このようなタイムスタンプ１７３をメトリック１０９に関連付けるように構成されてもよい。

メトリック１０９はさらに、被監視システム１０６（図１）の作動のいくつかの態様を記述する値１７６を含む。例えば、図２のメトリック１０９に記述される値１７６は、ウェブページの作成に関連する待ち時間を表す値である。しかし、メトリック１０９に関連する値１７６は、理解できるように、値で表現できるかまたは値を定量化できる被監視システム１０６の１つの態様を表してもよいことが理解される。これに加えて、メトリック１０９はさらに、値１７６の単位１７９を表す。

特定の例を提供するために、メトリクス１０９は、プロセッサリソースの利用百分率、およびネットワークインターフェースに関連するトラフィック処理能力を示してもよい。メトリクス１０９は、ディスクまたは他の種類のメモリに書き込まれるかまたはそこから読み出されるバイト数を含んでもよい。メトリクス１０９は、応答待ち時間、要求回数、ならびに、健康なおよび／または不健康なホストのインスタンス数に関係してもよい。さらに、メトリクス１０９は、所定の被監視システム１０６の作動または利用に関連する他のパラメータに関係してもよい。

図３を参照すると、本発明の開示の様々な実施形態によるサーバ１０３内の種々のコンポーネントの動作を示すブロック図が示されている。この目的を達成するために、図３は、集合キュー１４３と、集合アプリケーション１２６と、記憶キュー１４６と、データ記憶アプリケーション１２９と、データ記憶１４９とを示している。集合キュー１４３は、タイムスタンプ１７３と、種々のディメンション１５３と、値１７６と、ユニット１７９とに関して表される、複数のメトリクス１０９を含む。

集合アプリケーション１２６は、集合キュー１４３からメトリクス１０９にアクセスし、時間集合を実行し、それによって、上述のように、各時間帯１５６に対するデータモデル１５１を生成する。例えば、図３で示されるように、集合アプリケーション１２６は、現在、３つの異なるディメンション１５３、すなわちディメンションＤ１、Ｄ２、Ｄ３に対する待ち状態の時間帯１５６ａに対してデータモデル１５１を生成している。ディメンションＤ１、Ｄ２、Ｄ３は、ネーム、ネームスペースおよびページタイプを含むメトリクス１０９のディメンション１５３に相当する。本明細書で説明するディメンション１５３は、単に例として提供されているのであって、他のディメンション１５３が採用されてもよいことが理解される。集合アプリケーション１２６は、ディメンション１５３のそれぞれに対する待ち状態の時間帯１５６ａについてのデータモデル１５１を計算する。例えば、図３に関して示されるように、現在待ち状態の時間帯１５６ａは、「１０：０１」で始まる１分間の間隔に対するものである。

３つのディメンション１５３に対して３つの待ち状態の時間帯１５６ａがあり、各時間帯１５６は、データ記憶１４９内のディメンション１５３の１つにそれぞれ関連付けて記憶される。集合アプリケーション１２６が集合キュー１４３からメトリクス１０９を取得すると、集合アプリケーション１２６は、各ディメンション１５３または遭遇する任意の他のディメンション１５３に対して待ち状態の時間帯１５６ａのそれぞれについてのデータモデル１５１を計算する。ある時点で、別のメトリクス１０９が待ち状態の時間帯１５６に対して受信される可能性がないと考えられる。そのような時点では、集合アプリケーション１２６は、データ記憶１４９内に記憶されるべき待ち状態の時間帯１５６ａに対するメトリクス１０９の集合の結果を、記憶キュー１４６内に置く。

記憶キュー１４６内に置かれたデータモデル１５１は、例えば、被監視システム１０６（図１）からサーバ１０３内に受信されている各時間帯１５６に関連するメトリクス１０９を記述するかまたは表す、複数の集合メトリクスを含んでもよい。この目的を達成するために、集合メトリクスは、例えば、各時間帯１５６に関連するメトリクス１０９の総数と、各時間帯１５６のメトリクス１０９に関連する値１７６の平均と、値１７６の最大値および／または値１７６の最小値とを含んでもよい。また、任意の他の種類の集合メトリックまたは、所定の時間帯１５６に対するメトリクス１０９についての他の情報と同様に、値１７６の合計が保持されてもよい。

計算された集合メトリクスの種類は、各時間帯１５６に対して実行される集合度合いに関係する。したがって、集合度合いは、所定の時間帯１５６に関連するメトリクス１０９に対してデータモデル１５１で保持された情報の詳細度合いに関係する。より多くの集合メトリクスが計算される場合、またはより大量の情報がデータモデル１５１内で保持される場合、集合度合いは低くなる。また、より少ない集合メトリクスが計算される場合、またはより少ない量の情報がデータモデル１５１内で保持されている場合、集合度合いはより高くなるという逆のことも成り立つ。

集合度合いはデータモデル１５１が生成される時間帯１５６の長さにも関連する。集合度合いは時間帯１５６が短くなるにつれて減少する。逆に、時間帯１５６が長くなるにつれて、集合度合いは高くなる。

選択される集合度合いは、被監視システム１０６を監視するために必要なデータに部分的に依存してもよい。この目的のために、記憶されたデータモデル１５１の特性が、被監視システム１０６を監視できる方法をある程度決定する。例えば、データモデル１５１を検査して、被監視システム１０６が動作しきい値に適合しているかどうかを決定する必要がある。データモデル１５１は、動作しきい値に関して被監視システム１０６の性能を決定および／または測定するために必要なデータを反映しなければならない。例えば、平均待ち時間が所定のしきい値より大きくなる場合、待ち時間を低減するために、処理容量などの追加のリソースを導入するといった、訂正アクションをとる必要がある。あるいは、各時間帯１５６に対するメトリクス１０９の集合度合いを特定することにより、１つ以上の事前に定義された動作しきい値に関して測定され得るかまたは測定され得ない被監視システム１０６の性能の全体監視を可能にする、必要とされる集合メトリクスを有するデータモデル１５１を生成する。

場合によっては、集合アプリケーション１２６は集合キュー１４３からメトリクス１０９の遅れた１つを取得してもよい。例えば、図３に示されるように、集合キュー１４３は１０：０１のタイムスタンプ１７３を有する大部分のメトリクス１０９を含む。しかし、メトリクス１０９の１つは「０９：５２」のタイムスタンプ１７３を有する。これは、いくつかの理由で、被監視システム１０６から相対的に遅れて受信したメトリック１０９を表す。このような「遅れた」メトリクス１０９は、他のメトリクス１０９に対して時間順序から外れて受信したメトリクス１０９を表す。

一実施形態によれば、集合アプリケーション１２６は遅れたメトリック１０９に関連する各時間帯１５６に対するデータモデル１５１に関するデータ記憶アプリケーション１２９に要求を送信してもよい。次に、データ記憶アプリケーション１２９は、各時間帯１５６に対するデータモデル１５１にアクセスし、データモデル１５１を集合アプリケーション１２６に戻す。メトリクス１０９の遅れた１つが記憶キュー１４６内に記憶された時間帯１５６に関連している場合には、データ記憶アプリケーション１２９は、所定の時間帯１５６がデータ記憶１４９内にまだ記憶されていないことが決定された後に、記憶キュー１４６を探索してもよい。

集合アプリケーション１２６からの要求に応答して、データ記憶アプリケーション１２９は、メトリクス１０９の遅れた１つの時間帯１５６に関連するデータモデル１５１に戻り、この結果、それぞれのデータモデル１５１がメトリクス１０９の遅れた１つで更新されてもよい。その後、集合アプリケーション１２６は、置かれるべき記憶キュー１４６内のデータモデル１５１の更新された１つを、データ記憶１４９に置く。この点において、データモデル１５１の更新された１つはデータ記憶１４９内に記憶されてもよい。１つの代替方法では、データモデル１５１の更新された１つは、理解できるように、前のデータモデル１５１に上書きされてもよい。

これは、集合アプリケーション１２６が時間帯１５６の古い１つに対する値を維持できる点で明らかな利点を提供する。これは、理解できるように、例えばインターネットまたは他のネットワークなどの様々なネットワークを介する中継においてメトリクス１０９が維持される状況に対応する。

さらに、所定のディメンション１５３に対して記憶された時間帯１５６は、被監視システム１０６がサーバ１０３のクロックに対して早く設定されたクロックを有することができることから、サーバ１０３により認知される現在時間より大きいタイムスタンプ１７３を有してもよい、ことに留意すべきである。したがって、各時間帯１５６に関連するタイムスタンプ１７３は、将来、サーバ１０３により認知される時間に比べて延長してもよい。一実施形態によれば、遮断の指定は、将来、サーバ１０３のクロックに比べてはるかに遠いタイムスタンプ１７３を有する受信したメトリクス１０９が無視されるか、または被監視システム１０６内のタイムスタンプ１７３の問題点を解決するために取られる訂正アクションを必要とするエラーが発生するように、指定される。一実施形態によれば、将来のタイムスタンプ１７３に対する許容できる制限は、サーバ１０３の現在時間から１時間、または理解できる他の時間制限である。このような時間制限は、生成されたメトリクス１０９の実際の時間に比べて将来はるかに遠いタイムスタンプ１７３が生成されるというような、被監視システム１０６に関連する故障が存在する可能性がある、という事実を反映する。

さらに、集合キュー１４３および記憶キュー１４６が採用され、および様々な機能コンポーネントが構成され、これにより、電源喪失の発生時におけるデータの喪失等を防止する。

次に図４を参照すると、様々な実施形態に関して図３に示されたのと同様に、様々なコンポーネントの動作の別の例が示されている。図４に示されるように、集合キュー１４３内にメトリクス１０９を受信したある時点で、新しいディメンション１５３が表われる。具体的には、「ページタイプ＝ページ１」の新しいディメンションが集合キュー１４３内に現れる。新しいディメンション１５３の出現に応答して、集合アプリケーション１２６は新しいディメンション１５３に関連する新しい待ち状態の時間帯Ｄ４を生成する。集合アプリケーション１２６はまた、データ記憶１４９内への記憶のために新しいディメンションＤ４が生成されている、データ記憶アプリケーション１２９と通信してもよい。

あるいは、データ記憶アプリケーション１２９は、記憶キュー１４６から新しいディメンション１５３に関連するデータモデル１５１にアクセスするとき、データ記憶１４９内の新しいディメンション１５３に関連するそれぞれのデータモデル１５１を自動的に記憶してもよい。これは、データ記憶１４９内へのデータモデル１５１の記憶がデータ駆動型である事実を表す。すなわち、データは、理解できるように、サーバ１０３が被監視システム１０６から受信したメトリクス１０９に関連するディメンション１５３に基づいて、自動的に新しいディメンション１５３に関連付けて記憶される。

図５を参照すると、上述の説明を考慮して、集合アプリケーション１２６の様々な機能の一例を表すフローチャートが示されている。あるいは、図５のフローチャートはサーバ１０３（図１）において実行される方法のステップを示すものとして見ることもできる。

図５のフローチャートは、例えば、集合キュー１４３（図３）から得られる各メトリック１０９（図２）に対して実行されるルーチンを表す。所定のメトリック１０９が集合キュー１４３（図３）から得られたと仮定すると、次にボックス２５０において、集合アプリケーション１２６が、メトリック１０９に関連するタイムスタンプ１７３（図２）が、任意の所定時間において集合アプリケーション１２６により維持されたそれぞれのディメンション１５３（図３）に対する現在待ち状態の時間帯１５６ａ（図３）に関する時間順序から外れているかどうかを決定する。現在のメトリック１０９を考慮に入れる必要がある１つ以上のデータモデル１５１（図３）が、ディメンション１５３のそれぞれ１つに関連する記憶キュー１４６（図１）内またはデータ記憶１４９（図１）内に既に記憶されている場合、メトリック１０９は順序から外れてもよい。

ボックス２５０において、現在のメトリック１０９が時間順序から外れていると決定された場合、集合アプリケーション１２６はボックス２５３に進む。そうでない場合、集合アプリケーション１２６はボックス２５６に進む。ボックス２５３では、集合アプリケーション１２６は、集合アプリケーション１２６の現在待ち状態の時間帯１５６に関する時間順序から外れているメトリック１０９に関連する１つ以上のデータモデル１５１の更新を実行する。これには、上述の更新が必要なそれぞれのデータモデル１５１を検索するために、データ記憶アプリケーション１２９（図１）と通信することを含み得る。その後、図示されるように、集合アプリケーション１２６は終了する。

ボックス２５６では、集合アプリケーション１２６は、集合キュー１４３から得られた現在のメトリック１０９内に新しいディメンション１５３が存在するかどうかを決定する。存在する場合、集合アプリケーション１２６はボックス２５９に進む。存在しない場合、集合アプリケーション１２６はボックス２６３に進む。

ボックス２５９では、集合アプリケーション１２６は、新しいディメンション１５３に対する新しい記憶バケットおよび待ち状態の時間帯１５６ａのセットアップを実行する。この意味における記憶「バケット」は、データ記憶１４９内の新しいディメンションに関連するデータモデル１５１または他のデータの記憶を表す抽象概念である。新しいディメンション１５３に対する新しい記憶バケットのセットアップを実行するために、集合アプリケーション１２６はデータ記憶アプリケーション１２９と通信して、新しいディメンション１５３に対する新しい記憶バケットの必要なことをデータ記憶アプリケーション１２６に通知してもよい。

あるいは、集合アプリケーション１２６は単に、新しいディメンション１５３に対する新しい待ち状態の時間帯１５６ａに関連する新しいデータモデル１５１を生成してもよい。データモデル１５１をそのメトリクスから計算できるメトリクス１０９が受信されない時間帯１５６が存在する場合、このような時間帯１５６に対してデータモデル１５１は記憶されないことに留意すべきである。この意味において、所定のディメンション１５６に対する時間帯１５６により表される時間記録は、データの存在しない空白を有することもある。

ボックス２５９から、集合アプリケーション１２６はボックス２６３に進む。ボックス２６３では、集合アプリケーション１２６は、集合アプリケーション１２６により維持されている現在の時間帯のうちの待ち状態の１つのデータモデル１５１の計算において、現在のメトリック１０９に関連するタイムスタンプ１７３（図２）が含まれるべきかどうか、あるいは、１つ以上のディメンション１５３の次の連続する時間帯１５６に対するデータモデル１５１の計算において、新しいメトリック１０９が含まれるべきかどうかを決定する。メトリック１０９が時間帯１５６の次の連続する１つに関連するディメンション１５３を含むと仮定すると、集合アプリケーション１２６は、ボックス２７３に進み、ディメンション１５３を含まない場合はボックス２７６に進む。

ボックス２７３では、現在のメトリック１０９にも関連している、新しい待ち状態の時間帯１５６ａに関連する１つ以上のデータモデル１５１が計算される。その後、ボックス２７９では、全面的に推定される対応する時間帯１５６に関連する１つ以上のデータモデル１５１が、データ記憶１４９（図１）内の記憶のために記憶キュー１４６（図３）内に置かれる。この点において、集合アプリケーション１２６は、記憶キュー１４６内に置かれる前の待ち状態の時間帯１５６ａと同様に、各ディメンション１５３に対する最小数の連続時間帯１５６を維持してもよい。

このような時間帯１５６は、理解できるように、先入れ先出し方式で維持されてもよい。各時間帯１５６に関連する所定のデータモデル１５１を記憶キュー１４６内に置くかどうかの決定は、任意の追加のメトリクス１０９がそれぞれの１つ以上の時間帯１５６に対して処理されなかったことを受信したと考えられるかどうかに依存する。これは、各ディメンション１５３に対してどれほど多くの連続の時間帯１５６が、任意の所定時間において集合アプリケーション１２６によって待ち状態として維持されるかを決定してもよい。ボックス２７９において、いずれかの待ち状態の時間帯１５６ａが記憶キュー内に置かれていると仮定すると、その後、図示されるように、集合アプリケーション１２６は終了する。

ボックス２７６を参照すると、現在のメトリック１０９のタイムスタンプ１７３が、上述のように、それぞれのディメンションに対する新しい時間帯１５６を生成することを要求しないと仮定すると、ボックス２７６では、現在の待ち状態の時間帯１５６に対するデータモデル１５１が、集合キュー１４３から受信した現在のメトリック１０９に基づいて再計算される。その後、集合アプリケーション１２６は終了する。

図６を参照すると、データ記憶１４９（図１）内に既に記憶されている、所定のディメンション１５３（図１）に対する時間帯１５６（図１）に関連するデータモデル１５１（図３）を更新する際の、集合アプリケーション１２６の機能の一例を表すフローチャートが示されている。図６では、集合アプリケーション１２６は、時間順序から外れたメトリクス１０９（図２）のうちの１つを受信している。あるいは、図６のフローチャートは、上記更新を達成するためにサーバ１０３（図１）において実行される方法のステップを示すものとして見ることもできる。

最初にボックス３０３において、時間順序から外れており、およびメトリック１０９内に示されるそれぞれのディメンション１５３に対する以前に記憶された時間帯のデータモデル１５１の計算において考慮に入れられるメトリック１０９を受信すると、集合アプリケーション１２６は、タイムスタンプ１７３（図２）および遅れたメトリック１０９のディメンション１５３に対応する各時間帯１５６に対するデータモデル１５１を要求する。この要求は、要求されたデータモデル１５１を取得し、およびそれらのデータモデルを集合アプリケーション１２６に送り返し得るデータ記憶アプリケーション１２９に提供されてもよい。

ボックス３０６では、集合アプリケーション１２６は、要求されたデータモデル１５１がデータ記憶アプリケーション１２９から受信されているかどうか、または受信されていない場合は、集合アプリケーション１２６が利用可能かどうかを決定する。上記いずれかが満たされていると仮定すると、ボックス３０９において、集合アプリケーション１２６は、遅れて受信したメトリック１０９に基づいて各時間帯１５６に対するデータモデル１５１を再計算する。その後、ボックス３１３において、各時間帯１５６に対するデータモデル１５１が記憶キュー１４６内に置かれ、上述のように、最終的に、所定のディメンション１５３の各時間帯に関連するデータ記憶１４９内に記憶される。上述のように、各時間帯１５６に対して新しく計算されたデータモデル１５１は、前から存在している時間帯１５６に最終的に上書きされる可能性がある。その後、図示されるように、集合アプリケーション１２６は終了する。

図７を参照すると、メトリック１０９（図１）を維持およびアクティブ・メトリック・リスト１６９（図１）に追加する場合における、メトリック・ディレクトリ・アプリケーション１６３の機能の一例を表すフローチャートが示されている。あるいは、図７のフローチャートは、上記維持および追加を達成するためにサーバ１０３（図１）において実行される方法のステップを示すものとして見ることもできる。

最初にボックス３３１において、メトリック・ディレクトリ・アプリケーション１６３は、識別子がメトリック１０９に関連付けられているかどうか、またはメタリック１０９またはデータモデル１５１がアクティブ・メトリック・リスト１６９内に含まれていないことを示すデータモデル１５１（図１）に関連付けられているかどうかを決定する。上記いずれかが満たされている場合、メトリック・ディレクトリ・アプリケーション１６３は図示のように終了し、その場合、メトリック１０９またはデータモデル１５１は無視および／または破棄される。上記いずれかが満たされていない場合、メトリック・ディレクトリ・アプリケーション１６３はボックス３３３に進む。ボックス３３３では、メトリック・ディレクトリ・アプリケーション１６３は、メトリック１０９または集合アプリケーション１２６または他のソースからのメトリック１０９の複数のインスタンスを表すデータモデル１５１を検査し、そのようなメトリック１０９がアクティブ・メトリック・リスト１６９の一部として現在存在するかどうかを識別する。メトリック１０９が現在存在する場合、メトリック・ディレクトリ・アプリケーション１６３はボックスに進む。存在しない場合は、メトリック・ディレクトリ・アプリケーション１６３はボックス３３９に移動する。

ボックス３３６では、メトリック・ディレクトリ・アプリケーション１６３は、メトリック１０９自体に関連するアクティブ・メトリック・リスト１６９内のメトリック１０９に対する最新のタイムスタンプを記憶する。その後、メトリック・ディレクトリ・アプリケーション１６３のこの機能は終了する。

ボックス３３９では、メトリック・ディレクトリ・アプリケーション１６３は、以前に存在しないメトリック１０９をアクティブ・メトリック・リスト１６９に追加する。その後、ボックス３４３において、新しく追加されたメトリック１０９に対するタイムスタンプが、新しく追加されたメトリック１０９に関連付けてアクティブ・メトリック・リスト１６９内に記憶される。その後、メトリック・ディレクトリ・アプリケーション１６３のこの機能は、図示されるように終了する。

図８を参照すると、アクティブ・メトリック・リスト１６９（図１）から古くまたは遅れたメトリック１０９（図１）を除去する場合における、メトリック・ディレクトリ・アプリケーション１６３（図１）の別の機能の一例を表すフローチャートが示されている。あるいは、図７のフローチャートは、上記除去を達成するためにサーバ１０３（図１）において実行される方法のステップを示すものとして見ることもできる。メトリック・ディレクトリ・アプリケーション１６３の機能は、アクティブ・メトリック・リスト１６９内に記憶されたメトリクス１０９のそれぞれ対して循環するループを含む。

最初のボックス３５３において、メトリック・ディレクトリ・アプリケーション１６３は、考慮中のアクティブ・メトリック・リスト１６９内の現在のメトリクス１０９に対する最新のタイムスタンプ１７３（図２）を取得する。次に、ボックス３５６において、メトリック・ディレクトリ・アプリケーション１６３は、事前に定義された時間帯に対するデータモデル１５１（図１）のみが記憶され得ると仮定して、メトリック１０９がそのメトリックに関連するタイムスタンプ１７３に基づいて古いかどうかを決定する。それぞれのメトリック１０９が古い場合、メトリック・ディレクトリ・アプリケーション１６３はボックス３５９に進行する。ボックス３５９では、古いメトリック１０９は、アクティブ・メトリック・リスト１６９から除去される。ボックス３５６において、メトリック１０９は古くないと決定される場合、メトリック・ディレクトリ・アプリケーション１６３のこの部分はボックス３６３に移動し、考慮するためのアクティブ・メトリック・リスト１６９内にリストアップされた次のメトリック１０９を特定する。メトリクス１０９がアクティブ・メトリック・リスト１６９から除去されると、メトリック・ディレクトリ・アプリケーション１６３はボックス３６３に進み、考慮するための次のメトリック１０９を特定する。したがって、メトリック・ディレクトリ・アプリケーション１６３のこの部分は、メトリクス１０９のそれぞれを連続的に検査して古いメトリックを識別し、それらメトリックをアクティブ・メトリック・リスト１６９から除去する。

次に図９を参照すると、本発明の開示の１つの実施形態によるサーバ１０３（図１）の一例の概略ブロック図が示されている。サーバ１０３は、例えばプロセッサ４０３およびメモリ４０６（これら両方はローカルインタフェース４０９に接続されている）を有する、プロセッサ回路を含む。この目的のために、サーバ１０３は、例えばこのような構造を有するサーバコンピュータを備えてもよい。ローカルインタフェース４０９は、理解できるように、例えば、付帯のアドレス／制御バスを有するデータバスまたは他のバス構造を備えてもよい。

プロセッサ４０３により実行されるデータおよびいくつかのコンポーネントの両方は、メモリ４０６に記憶される。具体的には、確認アプリケーション１２３、集合アプリケーション１２６／１２６ａ、データ記憶アプリケーション１２９、監視サービス１３３、ネットワーク・サーバ・アプリケーション１３６、メトリック・ディレクトリ・アプリケーション１６３、および可能性のある他のアプリケーションがメモリ４０６に記憶される。さらに、サーバ・オペレーティング・システムが、理解できるように、メモリ４０６に記憶されてもよく、またプロセッサにより実行されてもよい。さらにまた、集合キュー１４３、記憶キュー１４６、データ記憶１４９、およびデータ記憶１６６がメモリ４０６に記憶されてもよく、あるいはこれらはサーバ１０３にアクセスできる特定の他のメモリに記憶されてもよい。なお、理解できるように、メモリ４０６内に記憶され、またプロセッサ４０３により実行可能な他のアプリケーションがあってもよいことを理解されたい。また、他のデータがメモリ４０６に記憶され、プロセッサ４０３によりアクセスされてもよい。一実施形態によれば、データ記憶１４９および１６６のそれぞれは、例えばデータベースまたは他の適切なデータ記憶構造を備えてもよい。その場合、本明細書において説明される任意のコンポーネントは、ソフトウェアの形、すなわち、例えばＣ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｊａｖａ（登録商標） Ｓｃｒｉｐｔ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、Ｆｌａｓｈなどの多くのプログラミング言語、または他のプログラミング言語のうちの任意の１つで実現される。

多くのソフトウェアコンポーネントがメモリ４０６に記憶され、プロセッサ４０３により実行可能であってもよい。この点に関して、用語の「実行可能」は、最終的にはプロセッサ４０３により実行できる形のプログラムファイルを意味する。実行可能なプログラムの例は、例えば、メモリ４０６のランダムアクセス部分にロードでき、またプロセッサ４０３により実行できるフォーマットの機械コードに変換可能なコンパイルされたプログラムであってもよく、または、メモリ４０６のランダムアクセス部分にロードでき、およびプロセッサ４０３等により実行できる目的コードといった適正なフォーマットで表され得るソースコードであってもよい。実行可能なプログラムは、メモリ４０６の任意の部分またはコンポーネント内に記憶されてもよく、これらメモリとしては、例えばランダムアクセス・メモリ、読み出し専用メモリ、ハードドライブ、コンパクトディスク（ＣＤ）、フロッピー（登録商標）ディスク、または他のメモリコンポーネントが挙げられる。

本明細書では、メモリ４０６は揮発性および不揮発性メモリならびにデータ記憶コンポーネントの両方として定義される。揮発性コンポーネントは電源の喪失時にデータ値を維持できないコンポーネントである。不揮発性コンポーネントは電源の喪失時にもデータ値を維持できるコンポーネントである。このように、メモリ４０６は、例えばランダムアクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハード・ディスク・ドライブ、関連のフロッピー（登録商標）ディスク・ドライブを介してアクセスされるフロッピー（登録商標）ディスク、コンパクト・ディスク・ドライブを介してアクセスされるコンパクトディスク、適切なテープドライブを介してアクセスされる磁気テープ、および／または他のメモリコンポーネント、あるいは任意の２つ以上のこれらメモリコンポーネントの組み合わせを備えてもよい。さらに、ＲＡＭは、例えばスタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、または磁気ランダムアクセス・メモリ（ＭＲＡＭ）および他のそのようなデバイスを備えてもよい。ＲＯＭは、例えばプログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ）、または他の同様のメモリデバイスを備えてもよい。

上述のようなサーバ１０３上で実行される様々なコンポーネントは、上述のような汎用ハードウェアにより実行されるソフトウェアまたはコード内で実現されてもよいが、代替として、専用ハードウェアまたはソフトウェア／汎用ハードウェアおよび専用ハードウェアの組み合わせで実現されてもよい。専用ハードウェアで実現される場合、上記の様々なコンポーネントは、多くの技術のうちのいずれか１つまたは組み合わせを採用する回路または状態機械として実現されてもよい。それらの技術は、これらに限定されないが、１つ以上のデータ信号を加えることにより様々な論理関数を実現する論理ゲートを有するディクリート論理回路、適切な論理ゲートを有する特定用途向け集積回路、または他のコンポーネント等を含んでよい。

図５から図８のフローチャートは、集合アプリケーション１２６とメトリック・ディレクトリ・アプリケーション１６３との一部の機能および動作を示す。ソフトウェアで実現されている場合、各ブロックはモジュール、セグメント、または特定の論理機能を実現するためにプログラム命令を含むコードの一部を表す場合がある。プログラム命令は、コンピュータシステムまたは他のシステム内のプロセッサなどの適切な実行システムにより認識できる数値命令を含むプログラミング言語または機械コードで書かれた、人の読むことができるステートメントを含むソースコードの形で実現されてもよい。機械コードはソースコード等から変換されてもよい。ハードウェアで実現される場合、各ブロックは、特定の論理機能を実現するための回路または多数の相互接続回路を表してもよい。

図５から図８のフローチャートは特定の実行順序を示すが、実行順序は図示の順序と異なってもよいことは理解されたい。例えば、２つ以上のブロックの実行順序は図示される順序に対して任意に異なってもよい。また、図５から図８において連続して示されている２つ以上のブロックは、同時にまたは部分的に同時に実行されてもよい。さらに、任意の数のカウンタ、状態変数、警告セマフォー(warning semaphores)、またはメッセージが、拡張ユティリティ、アカウンティング、性能測定、または障害解析支援等を提供する目的のために、ここに説明される論理フローに追加されてもよい。このような変形形態の全ては本発明の範囲内にあると理解されたい。

また、確認アプリケーション１２３、集合アプリケーション１２６、データ記憶アプリケーション１２９、監視サービス１３３、メトリック・ディレクトリ・アプリケーション１６３、および上述のサーバ１０３内で実現される任意の他のコンポーネントがソフトウェアまたはコードを含む場合、上記コンポーネントは、例えばコンピュータシステムまたは他のシステム内のプロセッサなどの命令実行システムにより使用するための、または命令システムと接続して使用するための、任意のコンピュータ可読媒体内で実現できる。この意味において、論理は、例えば、コンピュータ可読媒体から取り込みでき、命令実行システムにより実行できる命令および宣言を含むステートメントを含んでもよい。本発明の開示に関しては、「コンピュータ可読媒体」は、命令実行システムにより使用するための、または命令システムと接続して使用するための、ソフトウェアまたはコードを含み、記憶し、または維持できる任意の媒体であってもよい。コンピュータ可読媒体は、多くの物理媒体、例えば、電子、磁気、光、電磁、または半導体媒体のうちの任意の１つを含んでもよい。適切なコンピュータ可読媒体の多くの特定の例には、これらに限定されないが、磁気テープ、磁気フロッピー（登録商標）ディスク、磁気ハードドライブ、またはコンパクトディスクを含む。またコンピュータ可読媒体は、例えばスタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）およびダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、または磁気ランダムアクセス・メモリ（ＭＲＡＭ）を含む、ランダムアクセス・メモリ（ＲＡＭ）であってもよい。さらにコンピュータ可読媒体は、読み出し専用メモリ（ＲＯＭ）、プログラム可能読み出し専用メモリ（ＰＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、または他の種類のメモリデバイスであってもよい。

本発明の開示の上述の実施形態は単に、本発明の原理の明確な理解のために示した実現形態の可能な例であることが強調されるべきである。本発明の開示の精神および原理から実質的に逸脱することなく、上述の実施形態に対する多くの変形形態および修正形態が実現可能である。このような修正形態および変形形態は全て、本明細書において本発明の範囲内に含まれ、添付の特許請求の範囲により保護されるものとする。

（関連出願の相互参照）
本願は、米国特許仮出願の出願番号第６１／１０６，９０１号（２００８年１０月２０日出願）の発明の名称「監視のための大量データ記憶システム」：米国特許仮出願の出願番号第６１／１０６，９０３号（２００８年１０月２０日出願）の発明の名称「監視のための大量データの記憶システム」：米国特許仮出願の出願番号第６１／１０６，９０４号（２００８年１０月２０日出願）の発明の名称「監視のための大量データ記憶システム」：に対する優先権を主張するものであって、これらの仮出願のそれぞれは参照によりその全内容が本明細書に組み込まれる。本願はさらに、米国特許仮出願の出願番号第１２／４９３，５９６号（２００９年６月２９日出願）の発明の名称「監視のための大量データ記憶システム」と、米国特許仮出願の出願番号第１２／４９３，５５８号（２００９年６月２９日出願）の発明の名称「監視のための大量データ記憶システム」とに対する優先権を主張するものであって、これらの仮出願のそれぞれは参照によりその全内容が本明細書に組み込まれる。

Claims (11)

1. システムの状態を記述するメトリクスのストリームから、サーバで複数のデータモデルを生成するステップであって、前記メトリクスのそれぞれは複数の連続時間帯のうちの１つの時間帯に関連付けされており、各データモデルは連続時間帯のうちの対応する１つの時間帯に関連付けされたメトリクスを表す、ステップと、
   所定の時間帯に対する前記データモデルのそれぞれを記憶するステップと、
   前記所定の時間帯の終了時に前記データモデルのそれぞれを破棄するステップと、
   前記メトリクスのそれぞれを、使用後、前記データモデルの少なくとも１つを生成する際に破棄するステップと、
   を備える方法。
2. 前記サーバが前記システムとデータ通信する際に、前記システムから前記サーバにメトリクスのストリームを受信するステップをさらに備える、請求項１に記載の方法。
3. メトリクスに対する少なくとも１つのデータモデルが記憶されている該メトリクスのリストを維持するステップをさらに備える、請求項１に記載の方法。
4. 前記データモデルに基づいて前記システムの性能を表す出力を生成するステップをさらに備える、請求項１に記載の方法。
5. 前記データモデルの記憶された１つを、時間順序から外れて受信された前記メトリクスの１つで更新するステップをさらに備える、請求項１に記載の方法。
6. 前記メトリクスからサーバで前記データモデルを生成するステップは、連続の時間帯のそれぞれに対してシステムから受信した前記メトリクスの総数を維持するステップをさらに備える、請求項１に記載の方法。
7. 前記メトリクスからサーバで前記データモデルを生成するステップは、連続の時間帯のそれぞれに対してシステムから受信した前記メトリクスの最小の１つを識別するステップをさらに備える、請求項１に記載の方法。
8. 前記メトリクスからサーバで前記データモデルを生成するステップは、連続の時間帯のそれぞれに対してシステムから受信した前記メトリクスの最大の１つを識別するステップをさらに備える、請求項１に記載の方法。
9. 前記メトリクスからサーバで前記データモデルを生成するステップは、連続の時間帯のそれぞれに対してシステムから受信した前記メトリクスの平均を計算するステップをさらに備える、請求項１に記載の方法。
10. 前記メトリクスから前記データモデルを生成するステップは、
    各連続の時間帯に関連するサーバ内の前記メトリクスを集合するステップをさらに備え、
    各連続の時間帯に関連するサーバ内の前記メトリクスを集合する前記ステップによって連続の時間帯のそれぞれに対して少なくとも１つの集合メトリクスを生成する、
    請求項１に記載の方法。
11. 各連続の時間帯に対する前記メトリクスの集合度合いは結果的に、少なくとも１つの所定の動作しきい値に対する前記システムの性能を監視できる少なくとも１つの集合メトリックになる、請求項１に記載の方法。

Images