JP2014509036A - メトリックデータに動的にタグを付けるための方法およびシステム - Google Patents

Abstract

コンピューティングリソースのプロバイダによってメトリックデータに動的にタグ付けするためのシステムおよび方法が説明される。要求ユーザまたはアプリケーションは、コンピューティングリソースのプロバイダに、要求ユーザまたはアプリケーションによって指定される構成および／または設定に基づいてメトリックにタグ付けするよう要求することができる。次いで、タグ付けされたメトリックデータは、後で処理ユーザまたはアプリケーションによって処理することができる。
【選択図】図１

Description

会社および組織は、それらの活動を支援するために多数のコンピューティングシステムを相互接続するコンピュータネットワークを運営する。コンピューティングシステムは、単一の地理的な場所に（例えば、ローカルネットワークの一部として）位置させるか、または複数の別個の地理的な場所（１つ以上のプライベートまたはパブリック中間ネットワークを介して接続される）に位置させることができる。データセンターは、膨大な数の相互接続されたコンピューティングシステムを格納することができ、例えばプライベートデータセンターは、単一の組織によって運営され、また、パブリックデータセンターは、顧客にコンピューティングリソースを提供するために、第三者によって運営される。パブリックおよびプライベートデータセンターは、ネットワークアクセス、電力、ハードウェアリソース（例えば、計算および記憶）、およびデータセンター、組織、または他の顧客によって所有されるハードウェアのための安全な設置施設を提供することができる。

データセンターリソースの利用度増加を促進するために、仮想化技術は、単一の物理コンピューティングマシンが、接続されたコンピュータユーザに対して独立したコンピュータマシンとして現れ、動作する、仮想マシンの１つ以上のインスタンスをホストすることを可能にすることができる。仮想化によって、単一の物理コンピューティングデバイスは、動的な様式で仮想マシンを作成、維持、または削除することができる。その結果、ユーザは、データセンターからコンピュータリソースを要求することができ、可変数の仮想マシンリソースを「必要に応じて」、または少なくとも「要求に応じて」ユーザに提供することができる。

データセンターの規模および範囲が増大するにつれて、データセンターの物理および仮想コンピューティングリソースを提供、管理、および監視する作業がますます複雑になってきた。

図面全体を通して、参照される要素間の対応関係を示すために、参照番号が再使用され得る。図面は、本明細書で説明される例示的な実施形態を例示するために提供されているものであり、本開示の範囲を限定することを意図しない。
通信ネットワークを介して複数のユーザコンピューティングシステムにコンピューティングリソースを提供することができる、プログラム実行サービスの一実施例を概略的に例示するネットワーク図である。 プログラム実行サービスのユーザまたはアプリケーションによって要求されるメトリックのタグ付けを管理するように構成される、動的タグ付けマネージャの例示的な構成要素の概略ブロック図である。 ユーザコンピューティングシステムとプログラム実行サービスの動的タグ付けマネージャとの間の例示的な相互作用を概略的に例示するネットワーク図である。 動的タグ付けマネージャと、ユーザコンピューティングシステムと、コンピューティングリソースとの間の例示的な相互作用を概略的に例示するネットワーク図である。 動的タグ付けマネージャ構成要素によって実装される動的タグ付けマネージャルーチンを例示するフロー図である。 メトリックデータのタグ付けを要求するために使用することができる表示の一実施例を示す図である。 タグ付けしたメトリックデータを提示するために出力することができる表示の一実施例を示す図である。

コンピューティングリソースのプロバイダによってメトリックデータに動的にタグ付けするための、システムおよび方法の実施形態を説明する。例示的に、コンピューティングリソースは、プログラム実行機能、データ記憶装置または管理機能、ネットワーク帯域幅等を含むことができる。いくつかの実装において、ユーザは、将来の使用期間中にユーザのためのコンピュータリソースを管理および予約することができる、仮想化インフラストラクチャを生成することを要求することができる。例えば、ユーザは、将来の使用期間中にユーザのためのデータ記憶装置またはネットワーク帯域幅を管理および予約することができる、仮想化インフラストラクチャを生成することを要求することができる。コンピューティングリソースプロバイダは、ユーザの要求を満たすためにプロバイダのコンピュータリソースのうちのどれを利用可能にすることができるのかを決定することができ、そして、要求された使用期間中にそのようなコンピュータリソースをユーザに割り当てることができる。

仮想化環境は、プログラム実行サービス上でユーザプログラムを実行するための１つ以上のインフラストラクチャサービスとともに、ユーザプログラムのためのアプリケーションソフトウェアスタックを含む、ランタイム環境とすることができる。仮想化環境としては、ユーザが選択可能なオペレーティングシステム（例えば、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）等）、アプリケーションサーバ（例えば、Ａｐａｃｈｅ Ｔｏｍｃａｔ）、システムまたはアプリケーション構成等が挙げられる。仮想化環境は、特定のＵＲＬでホストされるように構成することができる。インフラストラクチャサービスとしては、要求されたコンピューティングリソース全体にわたって作業負荷を分配するためのロードバランサ、負荷または需要の変動に応答してコンピューティングリソースをスケーリングするためのロードスケーラ、コンピューティングリソースへのアクセスを制御するためのファイアウォールもしくは他のサービス、ユーザがプログラムの実行を監視することを可能にする監視インターフェース、データ記憶リソース（例えば、スケーラブルボリュームブロック記憶装置）等が挙げられるが、これらに限定されない。いくつかの実施形態において、ユーザは、仮想化インフラストラクチャに含むことができる１つ以上のプログラムまたはサービスを選択することが可能であり得る。例えば、ユーザは、複数のデータベースモデル（例えば、リレーショナルデータベース、ＳＱＬデータベース、Ｏｒａｃｌｅデータベース等）から選択することが可能であり得る。いくつかの実施形態において、インフラストラクチャサービスは、複数のユーザの間で共用リソースとするのではなく、ユーザ向けにカスタマイズすることができる。例えば、いくつかのそのような実施形態において、ロードバランサは、プログラム実行サービスの複数のユーザの間で共有または分配するのではなく、ユーザのアプリケーション向けに個々にカスタマイズすることができる。

メトリックデータは、ユーザに割り当てられた種々のコンピューティングリソースのために収集することができる。コンピューティングリソースのメトリックデータは、コンピュータリソースの使用パターンおよび機能を監視するために、分析、傾向把握、報告等を行うことができる。メトリックデータは、プログラム実行サービスまたは別のサービスによって収集することができる。例えば、コンピュータリソースの動作性能、リソース利用度、需要パターン等を測定することができる。いくつかの実装において、メトリックデータは、要求ユーザまたはアプリケーションによる要求に応じて、タグ付けすることができる。要求ユーザまたはアプリケーションは、タグ付けしたメトリックデータを後で処理することができるように、任意のキー／値対をメトリックデータに追加するよう仮想化インフラストラクチャに要求することができる。次いで、タグ付けしたメトリックデータを、処理ユーザまたはアプリケーションに出力することができる。

本明細書で使用される場合、その通常の意味を有することに加えて、「測定」という用語は、１組の属性を伴う観測値を意味することができる。例えば、測定値は、可能な他の（またはより少数の）特性の中で、名前、１組の寸法、名前空間、単位、および／またはタイムスタンプを含むことができる。本明細書で使用される場合、その通常の意味を有することに加えて、「寸法」という用語は、（下で詳細に説明される）ＩｎｓｔａｎｃｅＩＤ、ＩｎｓｔａｎｃｅＴｙｐｅ、Ａｖａｉｌａｂｉｌｉｔｙ Ｚｏｎｅ、または他の因子等によって、測定値をどのように集約することができるのかを特定するために使用することができる。本明細書で使用される場合、その通常の意味を有することに加えて、名前空間は、測定値を収集したサービスを識別する。さらに、本明細書で使用される場合、その通常の意味を有することに加えて、メトリックは、測定データの集約を含むことができる。

ユーザは、種々の測定値をどのように集約させるのかを指定する、１つ以上のメトリックを指定することができる。例えば、メトリックデータは、測定値データと同じ属性を含むことができ、所与の期間内での、所与の名前を伴ういくつかまたは全ての測定値の集約であることができる。別の例として、メトリックは、測定値のいくつかまたは全ての集約を特定の名前空間に含むことができ、または別のメトリックは、特定のインスタンスＩＤを有するいくつかまたは全ての測定値の集約を含むことができる。メトリックは、いくつかの実施形態において、他のメトリックの集約であることができる。この柔軟性の結果、特定の実施形態において、メトリックは、ユーザの嗜好に基づく種々の寸法を含む。本明細書で使用される場合、その通常の意味を有することに加えて、「タグ」という用語は、特定のメトリックと関連付けられた任意のキー／値対を意味することができる。例えば、タグは、特定のメトリックのためのキー「ｉｎｓｔａｎｃｅＩＤ」が「１２３４５６」の値を有することを示すことができる。別の例として、タグは、特定のメトリックのためのキー「ｃｕｓｔｏｍｅｒＩＤ」が特定のデータストアの記録に見られる値「１２，５」を有することを示すことができる。

ここで、本開示の種々の態様を、特定の実施例および実施形態に関して説明するが、それらは、例示することを意図したものであり、本開示を限定するものではない。

図１は、通信ネットワーク１０８を介して複数のユーザコンピューティングシステム１０４にコンピューティングリソースを提供することができる、プログラム実行サービス１００の一実施例を概略的に例示するネットワーク図である。プログラム実行サービス１００は、ウェブおよび／または他のアプリケーションホスティングに使用するためにレンタルするためのコンピューティングリソースを提供することができる、１つのウェブサービスまたは１群のウェブサービスであることができる。例えば、プログラム実行サービス１００は、ユーザに代わって１つのプログラムまたは１組のプログラムを実行するために、ユーザからの要求を管理することができる。少なくとも、ユーザコンピューティングシステム１０４のいくつかは、プログラム実行サービス１００から遠隔にあることができる。この実施例において、ユーザは、コンピューティングシステム１０４を使用して、通信ネットワーク１０８を通じてプログラム実行サービス１００にアクセスすることができる。ネットワーク１０８は、例えば、おそらくは種々の異なる当事者によって運営される、インターネット等のリンクされたネットワークの公的にアクセス可能なネットワークであることができる。他の実施形態において、ネットワーク１０８は、例えば非特権ユーザが全体的にまたは部分的にアクセスできない会社または大学のネットワーク等の、プライベートネットワークであることができる。さらに他の実施形態において、ネットワーク１０８は、インターネットへのおよび／またはそれからのアクセスを伴う、１つ以上のプライベートネットワークを含むことができる。

プログラム実行サービス１００は、複数のユーザについてプログラムの実行を管理するための、種々の機能を提供する。図１で例示される実施例において、プログラム実行サービス１００は、ユーザに代わってプログラムを実行することができる、複数のコンピューティングノード１１２を含む。コンピューティングノード１１２は、１つ以上の物理コンピューティングシステム上でホストされる、１つ以上の物理コンピューティングシステム１１６および／または１つ以上の仮想マシン１２０を含むことができる。例えば、ホストコンピューティングシステムは、複数の仮想マシン１２０を提供することができ、それらの仮想マシンを管理するために、仮想マシン（「ＶＭ」）マネージャ１２４（例えば、ハイパーバイザーまたは他の仮想マシンモニタ）を含むことができる。

図１で例示される実施例において、コンピューティングノード１１２のそれぞれは、１つ以上のプログラムを実行するために利用可能な若干のコンピューティングリソースを有する。各コンピューティングノード１１２は、特定の程度のプログラム実行能力を提供することができ、これは、例えば、処理能力（例えば、処理ユニットの数またはサイズ）、メモリ容量、記憶容量、ネットワーク帯域幅容量、非ネットワーク通信帯域幅等のうちの１つ以上の組み合わせによって測定することができる。いくつかの実施形態において、プログラム実行サービス１００は、事前構成されたコンピューティングノード１１２を提供することができ、各事前構成されたコンピューティングノードは、ユーザに代わってプログラムを実行するために利用可能な、ほぼ同等のおよび／または同等の量のリソースを有する。他の実施形態において、プログラム実行サービス１００は、ユーザに代わってプログラムを実行するためにユーザが選択することができる、種々の異なるコンピューティングノード１１２の選択肢を提供することができる。さらに他の実施形態において、プログラム実行サービス１００は、ユーザに、およびユーザのプログラム実行に特有である、種々のコンピューティングノードを生成することができる。いくつかのそのような実施形態において、コンピューティングノード１１２は、様々な量および／またはタイプのコンピューティングリソース（例えば、処理ユニットのサイズ、速度、および／またはタイプ、処理ユニットの数、メモリおよび／または記憶装置の量、３２ビットまたは６４ビット等のプラットフォーム構成、オペレーティングシステム等）を有することができる。

プログラム実行サービス１００は、データ、プログラム、および他のユーザ情報の大容量記憶装置を提供する記憶ノード１３４へのアクセスを伴う、ユーザコンピューティングシステム１０４を提供することができる。記憶ノード１３４としては、任意のタイプの永続的なデータ記憶装置、例えばハードディスクドライブ、光ディスクドライブ等の、例えば不揮発性メモリデバイスが挙げられる。図１で例示される実施例において、コンピューティングノード１１２は、ネットワーク１２８を介して記憶ノード１３４にアクセスすることができる。ネットワーク１２８は、例えばスイッチ、エッジルータ、コアルータ等の、複数のネットワーキングデバイス（図示せず）を含むことができる。ネットワーク１２８は、図１で示されるネットワーク１０８とは異なるネットワークであることができるが、そうである必要はない。

プログラム実行サービス１００のユーザまたはアプリケーションは、動的タグ付けマネージャ１３０を介してプログラム実行サービス１００と相互作用することができる。例えば、ユーザまたはアプリケーションは、ユーザに代わって使用されたプログラム実行サービス１００のリソースと関連付けられた１つ以上のメトリック（例えば、リソース利用度および／または需要パターン）のタグ付けを要求することができる。動的タグ付けマネージャ１３０は、コンピューティングノード１１２および記憶ノード１３４に接続すること、またはネットワーク１２８を介してそれらと通信することができる。動的タグ付けマネージャ１３０は、ネットワーク１０８を通じて、ユーザコンピューティングシステム１０４からメトリックのタグ付けの要求を受信することができる。ユーザ（またはユーザによって許可された他のユーザ）は、サービス１００が、処理ユーザまたはアプリケーションに後で提示することができるコンピューティングノードと関連付けられた１つ以上の測定値にタグ付けすることを、動的タグ付けマネージャ１３０を介して要求することができる。いくつかの実装において、ユーザは、異なるサービスによって収集されたメトリックデータにタグ付けするよう動的タグ付けマネージャ１３０に要求することができる。例えば、メトリックデータは、ネットワークリソースの実績（例えば、トラフィック、待ち時間、速度、エラー等）、商品の販売および／またはサービスの実績（例えば、販売数量、利益、費用対効果、キャッシュフロー、売上目標等）、財源の実績（例えば、株式、投資、資本利得／損失等）等に関連し得る。

いくつかの実施形態において、ユーザは、サービス１００が、ユーザに代わってメトリックにタグ付けするための１つ以上のタグを生成することを、動的タグ付けマネージャ１３０を介して要求することができる。サービス１００は、１つ以上のタグを生成することができ、またはユーザは、メトリックにタグ付けするための１つ以上のタグを生成するために、ユーザがどの基準を嗜好するのかを指定することができる。種々の実施形態において、タグ付けの嗜好および／または設定は、１つ以上のメトリックのタグ付けを要求するときに指定するか、ならびに／またはユーザがプログラム実行サービス１００のサービスを使用することを申し込むおよび／もしくは予約するとき等の、１つ以上の他のときに指定することができる。いくつかの実施形態において、動的タグ付けマネージャ１３０は、１人以上のユーザに申し込みおよび／または登録サービスを提供することができ、よって、ユーザは、メトリックのタイプに関連する情報、および／またはメトリックのタグ付けに対する嗜好、アカウント情報（例えば、ユーザ名、請求情報等）、利用規約等を指定することができる。

いくつかの実施形態において、ユーザが、サービスに申し込むおよび／または登録するために動的タグ付けマネージャ１３０と情報をやり取りした後またはそうする前に、ユーザには、１つ以上の要求識別子（例えば、キー、トークン、ユーザ名、パスワード等）を発行することができ、この識別子は、ユーザと関連付けられ、ユーザに代わって使用されているリソースと関連付けられた１つ以上のメトリックのタグ付けを要求することと連携して使用される。他の実施形態では、プログラム実行サービス１００の申し込みおよび／または登録サービスに関連する種々の動作を行うために、動的タグ付けマネージャ１３０以外のモジュールを提供することができる。

いくつかの実施形態において、動的タグ付けマネージャ１３０は、１つ以上の物理または仮想コンピューティングシステムによって実行または具現化される。例えば、いくつかの実施形態では、動的タグ付けマネージャ１３０を実行するために、ＣＰＵと、Ｉ／Ｏ構成要素と、記憶装置と、メモリとを含む構成要素を有する、サーバコンピューティングシステムを使用することができる。Ｉ／Ｏ構成要素としては、ディスプレイ、ネットワーク１２８に対するネットワーク接続、コンピュータが読み出し可能な媒体ドライブ、および他のＩ／Ｏデバイス（例えば、キーボード、マウス、スピーカー等）が挙げられる。動的タグ付けマネージャ１３０の実施形態は、１つ以上の実行可能なプログラムモジュールとしてサーバのメモリに記憶することができ、動的タグ付けマネージャ１３０は、ネットワーク１２８を通じて、コンピューティングノード１１２（例えば、物理コンピューティングシステム１１６および／またはＶＭ１２０）と相互作用することができる。動的タグ付けマネージャ１３０は、ネットワーク１０８を介して、ユーザからメトリックのタグ付けの要求を受信することができる。

図２Ａは、ユーザまたはアプリケーションからメトリックデータのタグ付けの要求を管理することができる、動的タグ付けマネージャ１３０の実施形態の例示的な構成要素の概略的ブロック図である。この実施形態において、動的タグ付けマネージャ１３０は、デフォルトタグ付けモジュール２０４と、取得モジュール２０８と、処理モジュール２１２と、タグ付けモジュール２１６とを含む。

デフォルトタグ付けモジュール２０４は、例えばリソース利用度、リソース監視等の、プログラム実行サービス１００によって収集された１つ以上のメトリックにタグ付けする。このメトリックデータは、プログラムサービス１００もしくは別のサービスによって収集される標準メトリックを含むことができ、および／または収集のためにユーザによって定義または作成されるメトリック、プラグイン、拡張子等を含むことができる。メトリックデータは、異なる寸法を含むことができ、ユーザは、ユーザ自身のメトリックを作成および／または定義することができる。いくつかの実装において、タグ付けは、収集されたメトリックの中へキー／値対（例えば、「名前空間」＝「名前空間１」および／または「名前」＝「ＣＰＵＵｔｉｌｉｚａｔｉｏｎ」）を挿入することを含む。

デフォルトタグ付けモジュールは、プログラム実行サービスのシステム設計者が所望する多数のタグとして含むことができる。例えば、プログラム実行サービスのシステム設計者は、ＩｎｓｔａｎｃｅＩＤ（例えば、メトリックを生成したインスタンスのＩＤ）、ＩｎｓｔａｎｃｅＴｙｐｅ（例えば、メトリックを生成したインスタンスのタイプ）、Ｎａｍｅｓｐａｃｅ（例えば、メトリックを生成したサービス）、ＡｖａｉｌａｂｉｌｉｔｙＺｏｎｅ（例えば、メトリックを生成した領域またはゾーン）、Ｎａｍｅ（例えば、メトリックの名前）、ＲｅｓｏｕｒｃｅＴｙｐｅ（例えば、メトリックを生成したリソースのタイプ）等に基づいて、それぞれの収集されたメトリックにデフォルトでタグ付けすることを所望することができる。システム設計者はまた、１つ以上の要因に基づいて、より多い、または異なるタグでそれぞれのメトリックにタグ付けすることを所望することもできる。例えば、記憶装置と関連付けられたメトリックの場合、システム設計者は、データベースクラス、データベースタイプ等に基づいて、メトリックにタグ付けするように決定することができる。デフォルトタグ付けモジュール２０４およびシステム設計者によって、複数の他の構成を実装することができる。

取得モジュール２０８は、例えば、ユーザまたはアプリケーションに代わって使用される１つ以上のコンピューティングリソースと関連付けられたメトリックに１つ以上の追加タグを追加する要求等の要求を、プログラム実行サービス１００によって管理される１つ以上のメトリックにタグ付けするためのユーザまたはアプリケーションから受信する。要求は、追加されるいくつかまたは全てのタグを含むことができる。追加されるタグは、異なるものであることができ、また、上で論じたデフォルトタグに追加することができる。追加タグは、プログラム実行サービス１００のユーザまたはアプリケーションによって所望され、システム設計者によって設計されるデフォルトタグと異なるタグであることができる。

追加タグの一例としては、サーバタイプまたはアプリケーションスタックのキー／値対を指定するタグが挙げられる。この例示的なタグは、ユーザによって所望され得るので、ユーザまたはアプリケーションは、それらのそれぞれのサーバタイプまたはスタックによって、タグ付けされたメトリックを後で処理することができる。ユーザは、取得モジュール２０８に、それぞれのメトリックについてキー「ｓｅｒｖｅｒＴｙｐｅ」およびその関連する値を含むように、メトリックデータにタグ付けするよう要求することができる。別の例として、追加タグは、顧客の固有の識別子と関連付けられたタグを含むことができる。この例において、タグは、ユーザまたはアプリケーションが、請求目的等で、顧客と関連付けられた固有の識別子に基づいて、タグ付けされたメトリックを処理することができるように、ユーザまたはアプリケーションによって所望され得る。

さらに別の例として、ユーザは、追加タグがコンピューティングリソースの任意の変更の通知について、追加タグを追加するように要求することができる。この例において、追加タグは、ユーザまたはアプリケーションによって、任意の信頼できる当事者に状態変更を通知するために使用することができる。ユーザは、この例において、キー「ＣｈａｎｇｅＮｏｔｉｆｉｃａｔｉｏｎ」を加えるように、およびそのそれぞれの値がリソース変更の状態を示す値（例えば、「インスタンス終了」）を割り当てるように要求することができる。さらなる例として、プログラム実行サービスのアプリケーションは、例えば、タグ付けされたメトリックデータを請求のために後で処理することができるように、コンピューティングリソースと関連付けられた顧客アカウントを示すために、追加タグを追加するように要求し得る。

アプリケーションはまた、例えば、コンピューティングリソースに対して統計分析を行うために、追加タグに基づいて、タグ付けされたメトリックデータを後で処理することができるように、コンピューティングリソースの地理的ゾーン、領域、データセンター等と関連付けられた追加タグを追加するように要求することもできる。種々のタグを、ユーザまたはアプリケーションによって作成または定義し、プログラム実行サービス１００によってサポートすることができる。メトリックデータをタグ付けする要求は、種々の方法で、取得モジュール２０８によって受信することができる。例えば、要求は、ユーザ（例えば、プログラム実行サービス１００によって提供される双方向コンソールまたは他のＧＵＩを介して）から、それ自体の他のプログラムまたは他のインスタンスの実行を自動的に開始するユーザの実行プログラムから、プログラミングツール（例えば、コマンドラインツール、統合された開発環境等）から、プログラム実行サービス１００によって提供されるアプリケーションプログラミングインターフェース（「ＡＰＩ」）（例えば、ウェブサービスを使用するＡＰＩ）を介して、動的タグ付けマネージャ１３０と相互作用するプログラムから、およびその他から直接受信することができる。

メトリックのタグ付けの要求は、タグの数および／またはタイプ、使用するタグの最小数および／または最大数、メトリックにタグ付けする際に使用する基準の数および／またはタイプ等を含むことができる。タグ付けの要求は、他のタイプの嗜好、要件、および／または規制（例えば、好ましいタグ付けのタイプ、タグ付けの頻度、タグ付けの条件等）を含むことができる。代替として、動的タグ付けマネージャ１３０は、これらの嗜好、要件、規制等を指定するためのオプションをユーザに提供するように構成すること、および／またはこれらのオプションを自動的に提供するように構成することができる。

取得モジュール２０８はまた、サービスからタグ付けの要求を受信することもできる。例えば、取得モジュール２０８は、プログラム実行サービス１００の別のモジュールまたはサーバからタグ付けの要求を受信することができ、または外部サービスから要求を受信することができる。要求は、上で論じたように、タグ、要件、嗜好等を含むことができる。

タグ付けの要求を取得モジュール２０４によって受信した後、処理モジュール２０８は、メトリックデータに追加タグをタグ付けするために通信することができる、１つ以上のコンピューティングノードを決定するために、その要求を処理することができる。処理モジュール２０８は、追加タグを分析し、メトリックデータに追加タグをタグ付けするために、どのコンピューティングノードを通信させることが必要であるかを決定することができる。例えば、ユーザによる記憶リソースの使用に関連する追加タグについて、処理モジュール２０８は、どの記憶ノード１３４がユーザによって使用されているかを特定することができる。別の例として、ユーザのどの顧客が請求目的でロードバランサを使用しているかを示す追加タグについて、処理モジュール２０８は、どのロードバランシングノードがユーザによって使用されているかを特定することができる。

特定の実施形態において、ユーザは、上で論じたように、タグ付けのためにユーザがどの基準を所望するかを指定することができ、処理モジュール２０８は、その基準に基づいて１つ以上の追加タグを決定することができ、かつ、メトリックに追加タグをタグ付けするために通信することができる１つ以上のコンピューティングノードを決定することができる。例えば、ユーザは、ウィザードを介して、例えば、プログラム実行サービスを伴うユーザのアカウントが複数の顧客に使用されること、およびユーザが、顧客のコンピューティングリソースの使用に基づいてユーザに直接請求できるようにしたいことを、取得モジュール２０８に示し得る。ユーザは、どのコンピューティングリソースがどの顧客によって使用されているかを示し得る。処理モジュール２０８は、次いで、固有の顧客識別番号と関連付けられた追加タグが、ユーザによって所望されるタグ付けを提供すると判断し、タグ付けを行うためにどのコンピューティングノードと通信すべきかを決定することができる。処理モジュール２０８は、決定した追加タグをユーザに提示することができ、よって、ユーザ、別のユーザ、またはアプリケーションは、タグ付けされたメトリックを後で処理することができる（下で論じる）。

図２Ａで例示される実施形態において、タグ付けモジュール２１６は、コンピューティングノードに任意の測定または収集したメトリックに追加タグをタグ付けするよう要求するために、１つ以上の決定したコンピューティングノードと通信する。タグ付けモジュール２１６と１つ以上の決定したコンピューティングノードとの間の相互作用は、種々の方法で起こり得る。例えば、相互作用は、１つ以上の決定したコンピューティングノードによって提供される他のタイプの通信インターフェースのＡＰＩを介して起こり得る。タグ付けモジュール２１６は、決定したコンピューティングノードによって測定または収集される任意のメトリックに追加されるべき、キー／値対を通信することができる。タグ付けモジュール２１６はまた、所望に応じてコンピューティングノードがデータにタグ付けすることを可能にするために、決定したコンピューティングノードによって必要とされる任意の追加情報を通信することもできる。いくつかの実装において、タグ付けの後に、取得モジュール２０８は、１つ以上のさらなる追加タグまたは追加タグに対する１つ以上の修正の要求を受信することができ、処理モジュール２１２およびタグ付けモジュール２１６は、上で論じたように、１つ以上のさらなる追加タグまたは追加タグに対する１つ以上の修正に基づいて、任意のタグ付けを行うことができる。

図４は、上で論じたように、プログラム実行サービスにメトリックデータへのタグ付けを行うよう要求するためにユーザに提示することができる、例示的なグラフィカルユーザインターフェースを例示する。取得モジュール４０８は、ユーザがタグ付けを要求することを可能にするために、ユーザに例示のウェブページを提示することができる。図４で示されるように、ユーザは、上で論じたようにメトリックデータに加えられるべき、複数の追加タグを指定することができる。いくつかの例として、タグ＃１およびタグ＃２は、プログラム実行サービスに、示されたＩＤを有する任意のコンピューティングノードインスタンスに、示される指定されたキー／値対をタグ付けするよう要求するために、ユーザによって作成することができる。

上で開示されるように、これらの追加タグを加えることは、ユーザまたはアプリケーションが、所望（例えば、請求等）に応じて、タグ付けされたメトリックデータを後で処理することを可能にする。さらに、タグ＃３は、ロードバランサを備える任意のコンピューティングノードインスタンスについて、キー「ｓｅｒｖｅｒＴｙｐｅ」を加えるべきであるよう指定するために、ユーザによって作成することができる。ユーザが「＄」を使用してキーの値を指定すると、プログラム実行サービスは、リアルタイムまたはランタイムで追加キーの値を決定し、ユーザによって指定されるようメトリクスデータに追加キーをタグ付けするように構成することができる。例えば、プログラム実行サービスが、ロードバランサが、ウェブサーバと関連付けられたコンピューティングノードインスタンスと関連付けられていることをランタイムで判定した場合、次いで、キー「ｓｅｒｖｅｒＴｙｐｅ」を、プログラム実行サービスによって値「ｗｅｂＳｅｒｖｅｒ」に割り当てることができ、そして、メトリックデータにこの追加タグをタグ付けすることができる。このキーに与えられる値は、ユーザおよびプログラム実行サービスによって定義することができる。例えば、特定のキー（例えば、ｓｅｒｖｅｒＴｙｐｅ）に割り当てられることができる種々の値は、ユーザによって定義し、記憶ノード１３４を使用して、プログラム実行サービスによって記憶することができる。これらの記憶値は、特定のキーに割り当てるべき値を決定するために、コンピューティングノードインスタンスによって後でアクセスすることができる。

タグ＃４は、コンピューティングノードインスタンスと関連付けられた任意の状態変更について、追加タグが作成され、追加されるよう指定するために、ユーザによって作成することができる。ユーザは、示されるように、この追加タグが「ｃｈｎｇｅＳｔａｔｕｓ」というキーで与えられるべきであること示しており、そのキーに割り当てられる値は、そのキーを見つけることができる値の場所を示すことができる、参照「＆ａｄｄｒｅｓｓ」によって見出すことができる。例えば、上で説明したように、特定のキーに割り当てることができる値は、記憶ノード１３４によって管理することができ、「＆ａｄｄｒｅｓｓ」は、データ記憶装置に記憶された特定のキーに割り当てることができる値のリストを管理する、記憶ノード１３４に対する参照であることができる。別の例として、「＆ａｄｄｒｅｓｓ」は、値のリストを見つけることができる記憶場所、ウェブアドレス等を直接参照することができる。キーの値は、動的タグ付けマネージャによってユーザの要求時に決定され、キーと関連付けられ得、またはその値は、コンピューティングノードインスタンスによってランタイムで決定することができる。

タグ＃５は、ユーザの顧客によってユーザが請求を行うことを可能にする追加タグが、プログラム実行サービスによって生成されるよう指定するために、ユーザによって作成することができる。上で論じたように、プログラム実行サービスは、次いで、ユーザによって指定された基準に基づいて、１つ以上の追加タグを生成することができる。例えば、プログラム実行サービスは、ユーザによって要求される請求を提供するために、キー「ｃｕｓｔＩＤ」を有する追加タグを生成し得る。プログラム実行サービスは、次いで、顧客の識別子と関連付けられた値を割り当て、メトリックにこれらのキー／値対をタグ付けすることができる。プログラム実行サービスは、上で挙げた例と類似した特定のキーに割り当てられる値を決定し得る。さらに、タグ付けされたメトリックを処理するユーザおよびアプリケーションが、メトリックにタグ付けするために使用されたキーを提供するよう記憶ノードに後で要求することができるように、プログラム実行サービスは、記憶ノード１３４を使用して生成される、１つ以上のキーを記憶し得る。キーのリストはまた、リクエストを行なうユーザに提供することもできる。

図２Ａに戻ると、動的タグ付けモジュール１３０は、図２Ａで例示されるものと異なるように構成することができる。例えば、例示されたモジュールによって提供される種々の機能は、組み合わせる、再配列する、追加する、または削除することができる。いくつかの実施形態において、追加のまたは異なるプロセッサまたはモジュールは、図２Ａで例示される例示的な実施形態を参照して説明される機能の一部または全部を行うことができる。数多くの実装の変形例が可能である。

概してメトリックデータのタグ付けに関して説明されているが、他の実施形態において、動的タグ付けマネージャ１３０は、任意のタイプのデータにタグ付けすることができる。このようなデータのタイプには、例えば、ネットワークデータ（例えば、ネットワークトラフィック、性能データ、エラーデータ等）、販売データ（例えば、目録データ、利益データ、収入データ、予測データ等）、財務データ（例えば、投資データ、クレジットデータ、保険データ等）等のうちの１つ以上を含むことができる。

図２Ｂは、ユーザコンピューティングシステム１０４ａと、プログラム実行サービス１００の動的タグ付けマネージャ１３０との間の例示的な相互作用を概略的に例示するネットワーク図である。プログラム実行サービス１００は、複数のユーザコンピューティングシステム１０４ａ、１０４ｂ、・・・、１０４ｎにコンピューティングリソースを提供することができる。この例示的な実施例において、プログラム実行サービス１００は、動的タグ付けマネージャ１３０とプログラム的に相互作用するように、ユーザコンピューティングシステム１０４ａ、１０４ｂ、・・・、１０４ｎのためのＡＰＩを提供する。

図２Ｂは、要求ＡＰＩを使用したメトリックデータのタグ付けの要求を通信する、ユーザコンピューティングシステム１０４ａを例示的に示す。要求ＡＰＩ（１）は、ネットワーク１０８を介して通信され、（２）は、プログラム実行サービス１００の動的タグ付けマネージャ１３０によって受信される。要求ＡＰＩは、例えば、タグの数および／またはタイプ、タグの最小数および／または最大数、タグ、メトリックにタグ付けする際に使用する基準の数および／またはタイプ等の、ユーザの要求に関する情報を含むことができる。要求ＡＰＩは、例えば、メトリックデータのタグ付けに対するユーザの希望に関連する、嗜好、要件、および／または規制等の、要求に関する他の情報を含むことができる。例えば、要求ＡＰＩは、ユーザがメトリックデータにタグ付けするアクセスを与えられること、好ましいタグ付けのタイプ、タグ付けの頻度、タグ付けの条件等に関する情報を含むことができる。

図２Ｂで示される実施例において、動的タグ付けマネージャ１３０は、ネットワーク１０８を介して、確認ＡＰＩ（３）と通信し、ユーザコンピューティングシステム１０４ａによって受信される（４）である。確認ＡＰＩは、プログラム実行サービス１００が要求を（全体的または部分的に）認めることができるかどうかに関連する情報を含むことができる。確認ＡＰＩはまた、ユーザの要求と関連付けられ、メトリックデータのタグ付けと連携して使用される、１つ以上の要求識別子（例えば、キー、トークン、ユーザ名、パスワード等）を含むこともできる。確認ＡＰＩは、例えばユーザの嗜好、要件、および／または規制を満たすことができることを確認する情報等の、他の情報を含むことができる。

図２Ｂは、プログラム実行サービス１００の動的タグ付けマネージャ１３０とＡＰＩを介してプログラム的に相互作用する、ユーザコンピューティングシステム１０４ａを例示的に示す。プログラム実行サービス１００は、ＡＰＩを介して、他のユーザコンピューティングシステム（例えば、ユーザコンピューティングシステム１０４ｂ、・・・、１０４ｎ）から、メトリックデータにタグ付けする要求を受信することができ、そして、ＡＰＩを介して、他のユーザコンピューティングシステムに確認を通信することができる（当該の要求および確認は、図２Ｂの例示的な実施例に示さず）。動的タグ付けマネージャ１３０（または他の好適な構成要素）は、複数のユーザコンピューティングシステムにタグ付けされたメトリックデータを提示することができる。プログラム実行サービス１００とユーザコンピューティングシステムとの間では、（加えて、または代替として）他のタイプのプログラム的相互作用が可能である。例えば、要求は、ユーザ（例えば、プログラム実行サービス１００によって提供される双方向コンソールまたは他のＧＵＩを介して）から、それ自体の他のプログラムまたは他のインスタンスの実行を自動的に開始するユーザの実行プログラムから、およびその他から直接受信することができる。

図２Ｃは、ユーザコンピューティングノード１１２と、プログラム実行サービス１００の動的タグ付けマネージャ１３０との間の例示的な相互作用を概略的に例示するシステム図である。動的タグ付けマネージャ１３０は、コンピューティングノード１１２のインスタンス１４２ａ、１４２ｂ、・・・、１４２ｎによってメトリックデータのタグ付けを要求することができる。上で説明したように、動的タグ付けマネージャ１３０は、タグ付けの要求をユーザコンピューティングシステム１０４ａ、・・・、１０４ｎから受信することができる。一実施例において、上で説明したように、コンピューティングノード１１２は、コンピューティングノード１１２およびインスタンス１４２ａ、１４２ｂ、・・・、１４２ｎとプログラム的に相互作用するように、動的タグ付けマネージャ１３０のためのＡＰＩを提供する。動的タグ付けマネージャ１３０とコンピューティングノード１１２との間の通信は、例えば、タグの数および／またはタイプ、タグの最小数および／または最大数、タグ等の、ユーザの要求に関する情報を含むことができる。通信は、上で論じたタグ付けを行うために、コンピューティングノード１１２によって管理されるメトリックデータに追加すべきキー／値対、およびコンピューティングノード１１２によって必要とされる他の基準または情報を指定することができる。

図３は、動的タグ付けマネージャルーチン３００の例示的な実施形態を概略的に例示するフロー図である。いくつかの実装において、ルーチン３００は、図１および図２を参照して説明されるプログラム実行サービス１００の動的タグ付けマネージャ１３０の実施形態によって実装することができる。例示的なルーチン３００は、メトリックデータのタグ付けの要求を行うユーザに関して説明される。例示的なルーチン３００は、動的タグ付けマネージャ１３０の種々の態様を例示することを意図したものであり、それらに限定するものではない。

図３を参照すると、プログラム実行サービスは、ブロック３０４で、メトリックデータのタグ付けをデフォルト設定することを行う。システム設計者は、プログラム実行サービスによって管理、収集、監視等が行われるメトリックデータに挿入または追加されるべき、デフォルトタグを指定する。上で説明したように、種々のデフォルトタグを使用することができ、使用されるデフォルトタグの数またはタイプは、システム設計者によって設計されるように、それぞれのメトリックデータ間で変動させることができる。ブロック３０８で、プログラム実行サービス１００によるメトリックのタグ付けについて、ユーザから動的タグ付けマネージャ１３０によって要求が受信される。上で論じたように、要求は、タグの所望の数および／またはタイプ、タグの最小数および／または最大数、メトリックをタグ付けする際に使用する基準の数および／またはタイプ等を含むことができる。要求は、特定のユーザ（１人または複数）だけがメトリックデータにタグ付けするアクセスを認められるよう指定することができる。タグ付けの要求は、他のタイプの嗜好、要件、および／または規制（例えば、好ましいタグ付けのタイプ、タグ付けの頻度、タグ付けの条件等）を含むことができる。

ブロック３１２で、動的タグ付けマネージャ１３０は、メトリックデータにタグ付けするための１つ以上の追加タグを決定するために、受信した要求を処理する。種々の実施形態において、タグ付けの要求は、メトリックにタグ付けするために使用される、追加タグを含む。プログラムサービス１００は、１つ以上の追加タグを決定するために、要求を分析する。いくつかの実装において、受信した要求は、１つ以上の追加タグを作成または生成するために、プログラムサービス１００によって使用することができる。上で論じたように、受信した要求は、メトリックをタグ付けする際に使用される基準を指定し得、プログラム実行サービスは、メトリックをタグ付けする際に使用される１つ以上の追加タグを作成するために、この基準を分析し得る。

図３を参照すると、ルーチン３００は、ブロック３１６を続け、そこでは、動的タグ付けマネージャ１３０が、メトリックデータに１つ以上の追加タグをタグ付けし、それによって、タグ付けされたメトリックを、処理ユーザまたはアプリケーションによって後で処理することを可能にする。動的タグ付けマネージャ１３０は、メトリックデータへの追加タグのタグ付けを行うために通信することができる、１つ以上のコンピューティングノードを決定する。動的タグ付けマネージャ１３０は、次いで、決定された１つ以上のコンピューティングノードと通信して、コンピューティングノードによって管理、収集、監視等が行われるメトリックデータに追加タグをタグ付けするようコンピューティングノードに要求する。動的タグ付けマネージャ１３０は、タグ付けを行うために使用される追加タグ、およびタグ付けを行うために使用される条件、基準等を、コンピューティングノードに提供することができる。

ブロック３２０で、随意に、ルーチン３００の実施形態によって他のサービスを行うことができる。例えば、プログラムサービス１００は、タグ付けされたメトリックデータを処理ユーザまたはアプリケーションに出力することができる。タグ付けされたメトリックデータのいくつかの例としては、「ｉｎｓｔａｎｃｅＩＤ＝ｉ−０２０ｆ０ｄ６ａ」、「ｉｎｓｔａｎｃｅＴｙｐｅ＝記憶ノード」、「ホスト名＝ｗｗｗ．ｘｙｘ．ｃｏｍ」、「ＩＰアドレス＝１０．２５４．１１１．４」、「ゾーン＝ｕｓ−ｅａｓｔ−１ａ」、「ｄｉｓｋＲｅａｄｂｙｔｅｓ＝５ＫＢ」、「データセンター＝ｓｎａｐ−８０１０ｆ６ｅ９」、「ＣＰＵＵｔｉｌｉｚａｔｉｏｎ＝５時間」、「ｂｉｌｌｉｎｇＩＤ＝１２３４５６」、または「ｉｎｓｔａｎｃｅＩＤ＝ｉ−０３０ｇ０ｗ２ｂ」、「ｉｎｓｔａｎｃｅＴｙｐｅ＝ロードバランサ」、「ゾーン＝ｕｓ−ｅａｓｔ−１ｂ」、「ｂｉｌｌｉｎｇＩＤ＝１２３４５６」等の例示的なタグが挙げられる。タグ付けされたメトリックデータについて、多くの他の変形例が可能である。動的タグ付けマネージャ１３０は、様々な方法で、処理ユーザまたはアプリケーションに、タグ付けされたメトリックデータを出力することができる。例えば、プログラムサービス１００は、ＡＰＩもしくは他の通信インターフェース、ウェブページ、双方向コンソール、アプリケーション等を使用して、タグ付けされたメトリックデータを出力することができる。

図５は、プログラム実行サービスが随意に処理ユーザに出力することができる、例示的なウェブページを例示する。例示されるように、プログラム実行サービスは、タグ付けされたメトリックデータ内に含まれる全てのタグを列記する、ウェブページを出力することができる。プログラム実行サービス１００は、タグ付けされたメトリックデータ内に含まれるキー／値対を決定し、ユーザにそれらを出力するために、タグ付けされたメトリックデータを解析することができる。示されるように、タグ付けされたメトリックデータは、上で論じたデフォルトタグおよび追加タグの双方を含む。別の例として、プログラム実行サービスは、タグ付けされたメトリックを任意の所望の様式で出力することを可能にするために、プログラム実行サービスと関連付けられたアプリケーションを介して、タグ付けされたメトリックデータを出力することができる。例えば、プログラム実行サービスは、それらのタグに基づいてメトリックデータを集約する、集約アプリケーションにタグ付けされたメトリックを出力することができる。

集約アプリケーションは、一例として、顧客と関連付けられたタグに基づいて、タグ付けされたメトリックデータを集約し、集約したメトリックを請求または統計分析目的で処理することができるように、処理ユーザまたはアプリケーションにそれらを提示することができる。集約アプリケーションは、タグ付けされたメトリックを解析して、顧客と関連付けられた全てのタグの場所を特定し、これらの（例えば、類似したキーを有する）タグまたはタグの組み合わせに基づいて、メトリックを集約またはグループ化することができる。種々の集約および下位集約は、集約アプリケーションによって提供することができ、また、タグ付けされたメトリックデータを、種々の他のアプリケーションに出力することもできる。いくつかの実装において、タグ付けされたメトリックを出力することは、プログラム実行サービス以外の別のサービスによって提供することができる。

本開示の実施形態は、以下の付記を考慮して説明することができる。
付記１．メトリックにタグ付けするためのシステムであって、
コンピュータハードウェアを備えるコンピュータシステムを備え、コンピュータシステムは、１つ以上のコンピューティングノードを備え、かつ、
デフォルトタグをメトリックに少なくとも挿入することによって、コンピューティングノードの１つ以上の性能に関連する１つ以上のメトリックに、キーおよび値の対を備えるデフォルトタグをタグ付けするように構成される、デフォルトタグ付けモジュールと、
１つ以上のメトリックにタグ付けする際に使用される少なくとも１つの追加タグを受信するように構成される、取得モジュールであって、少なくとも１つの追加タグは、デフォルトタグとは異なる、取得モジュールと、
少なくとも１つの追加タグを分析して、１つ以上のメトリックに少なくとも１つの追加タグをタグ付けするために通信する、１つ以上のコンピューティングノードを決定するように構成される、処理モジュールと、
決定された１つ以上のコンピューティングノードと通信して、１つ以上のメトリックに少なくとも１つの追加タグをタグ付けすることを要求し、それによって、タグ付けされたメトリックをその後に集約することを可能にするように構成される、タグ付けモジュールと、
を実装するようにプログラムされる、システム。
付記２．取得モジュールはさらに、要求ユーザから少なくとも１つの追加タグの少なくとも１つを受信するように構成される、付記１に記載のシステム。
付記３．要求ユーザから受信したタグの少なくとも１つは、要求ユーザと関連付けられた請求識別子に関連する、付記２に記載のシステム。
付記４．タグ付けモジュールはさらに、複数のコンピューティングノードと通信することによって、１つ以上のメトリックにタグ付けするように構成される、付記１に記載のシステム。
付記５．タグ付けされたメトリックは、処理ユーザまたはアプリケーションによって集約されるように構成される、付記１に記載のシステム。
付記６．メトリックにタグ付けする方法であって、
コンピュータハードウェアを備える１つ以上のコンピュータシステムによって、
１つ以上のメトリックに、キーおよび値対を備えるデフォルトタグをタグ付けすることと、
１つ以上のメトリックにタグ付けする際に使用される少なくとも１つの追加タグを受信することであって、少なくとも１つの追加タグは、デフォルトタグとは異なる、受信することと、
１つ以上のメトリックに追加タグをタグ付けするために通信する１つ以上のコンピューティングノードを決定するために、追加タグを分析することと、
決定された１つ以上のコンピューティングノードと通信して、１つ以上のメトリックに追加タグをタグ付けすることを要求し、それによって、タグ付けされたメトリックをその後に集約することを可能にすることと、
を含む、方法。
付記７．アプリケーションプログラミングインターフェースを使用して、複数のコンピューティングノードと通信することをさらに含む、付記６に記載の方法。
付記８．要求ユーザまたはアプリケーションから、少なくとも１つの追加タグに対する少なくとも１つの修正を受信し、少なくとも１つの修正に少なくとも基づいて、分析および通信ステップを行うことをさらに含む、付記６に記載の方法。
付記９．コンピューティングノードの少なくとも１つは、ロードバランサ、ファイアウォール、物理マシン、仮想マシン、記憶ノード、およびデータベースサーバのうちの１つ以上を備える、付記６に記載の方法。
付記１０．処理アプリケーションは、グラフィカルユーザインターフェースアプリケーションである、付記６に記載の方法。
付記１１．タグ付けされたメトリックは、処理ユーザまたはアプリケーションによって処理される、付記６に記載の方法。
付記１２．処理ユーザまたは処理アプリケーションに、タグ付けされたメトリックを出力することをさらに含む、付記１１に記載の方法。
付記１３．少なくとも１つの追加タグの少なくとも１つは、要求アプリケーションに由来する、付記１１に記載の方法。
付記１４．少なくとも１つの追加タグの少なくとも１つは、要求ユーザに由来する、付記１１に記載の方法。
付記１５．要求ユーザおよび処理ユーザは、異なる、付記１４に記載の方法。
付記１６．要求アプリケーションおよび処理アプリケーションは、異なる、付記１３に記載の方法。
付記１７．そこに記憶された実行可能命令を備える、非一時的な物理記憶装置であって、実行可能な命令は、コンピューティングシステムに、少なくとも、
データにタグ付けする際に使用される少なくとも１つのタグを受信させ、少なくとも１つのタグは、キーおよび値の対を備え、
データにタグをタグ付けするために通信する１つ以上のコンピューティングノードを決定するために、追加タグを分析させ、
決定された１つ以上のコンピューティングノードと通信して、データにタグをタグ付けすることを要求し、それによって、タグ付けされたデータをその後に処理することを可能にさせるように構成される、
非一時的な物理記憶装置。
付記１８．タグ付けされたデータは、処理ユーザまたはアプリケーションによって処理されるように構成される、付記１７に記載の非一時的な物理記憶装置。
付記１９．処理ユーザまたは処理アプリケーションに、タグ付けされたデータを出力することをさらに含む、付記１８に記載の非一時的な物理記憶装置。
付記２０．少なくとも１つの追加タグの少なくとも１つは、要求アプリケーションから受信される、付記１８に記載の非一時的な物理記憶装置。
付記２１．少なくとも１つの追加タグの少なくとも１つは、要求ユーザから受信される、付記１８に記載の非一時的な物理記憶装置。
付記２２．要求ユーザおよび処理ユーザは、異なる、付記２１に記載の非一時的な物理記憶装置。
付記２３．要求アプリケーションおよび処理アプリケーションは、異なる、付記２０に記載の非一時的な物理記憶装置。
付記２４．実行可能命令を実行するように構成されるコンピューティングデバイスと組み合わせた、付記１７に記載の非一時的な物理記憶装置。
付記２５．メトリックにタグ付けする方法であって、
コンピュータハードウェアを備えるコンピュータシステムによって、
１つ以上のメトリックにタグ付けする際に使用される少なくとも１つの追加タグを受信することであって、少なくとも１つの追加タグは、１つ以上のメトリックに含まれるデフォルトタグとは異なる、受信することと、
１つ以上のメトリックに少なくとも１つの追加タグをタグ付けすることと、
少なくとも１つの追加タグを含む、タグ付けされたメトリックを出力することと、
を含む、方法。
付記２６．タグ付けされたメトリックは、処理ユーザまたはアプリケーションに出力される、付記２５に記載の方法。
付記２７．少なくとも１つの追加タグの少なくとも１つは、要求アプリケーションに由来する、付記２５に記載の方法。
付記２８．コンピューティングシステムは、複数のコンピューティングデバイスを備える、付記２５に記載の方法。

前項で説明されるプロセス、方法、およびアルゴリズムのそれぞれは、１つ以上のコンピュータまたはコンピュータプロセッサによって実行されるコードモジュールに具現化するか、またはそれによって完全にもしくは部分的に自動化することができる。コードモジュールは、ハードドライブ、固体メモリ、光ディスクおよび／またはその他等の、任意のタイプの非一時的なコンピュータが読み出し可能な記憶媒体またはコンピュータ記憶デバイスに記憶することができる。システムおよびモジュールはまた、無線に基づくおよび有線／ケーブルに基づく媒体を含む、種々のコンピュータが読み出し可能な伝送媒体上の生成されたデータ信号として（例えば、搬送波または他のアナログもしくはデジタル伝搬信号の一部として）伝送することもでき、また（例えば、単一もしくは多重化アナログ信号の一部として、または複数の個別デジタルパケットもしくはフレームとして）種々の形態を取ることができる。プロセスおよびアルゴリズムは、特定用途向け回路に部分的または全体的に実装することができる。開示されたプロセスおよびプロセスステップの結果は、例えば揮発性もしくは不揮発性記憶装置等の、任意のタイプの非一時的なコンピュータ記憶装置に永続的にまたは別様に記憶することができる。

上で説明した種々の特徴およびプロセスは、互いとは独立に使用することができ、または種々の方法で組み合わせることができる。全ての可能な組み合わせおよび部分的組み合わせは、本開示の範囲内であることが意図される。加えて、特定の方法またはプロセスブロックは、いくつかの実装において省略することができる。本明細書で説明される方法およびプロセスはまた、いかなる特定のシーケンスにも限定されず、それらに関連するブロックまたは状態は、適切である他のシーケンスで行うことができる。例えば、説明されるブロックもしくは状態は、具体的に開示されたもの以外の順序で行うことができ、または複数のブロックもしくは状態は、単一のブロックもしくは状態で組み合わせることができる。例示的なブロックまたは状態は、連続して、並行して、またはいくつかの他の様式で行うことができる。ブロックまたは状態は、開示された例示的な実施形態に追加する、またはそこから除去することができる。本明細書で説明される例示的なシステムおよび構成要素は、説明されるものと異なるように構成することができる。例えば、要素を、開示された例示的な実施形態に追加する、そこから除去する、またはそれと比較して再配列することができる。

本明細書で使用される、数ある中でも、「できる（ｃａｎ）」、「かもしれない（ｃｏｕｌｄ）」、「してもよい（ｍｉｇｈｔ）」、「得る（ｍａｙ）」、「例えば（ｅ．ｇ．，）」等の条件付き言語は、別途具体的に提示されない限り、または別様に使用される文脈内で理解されるように、一般に、特定の実施形態が特定の特徴、要素、および／またはステップを含む一方で、他の実施形態がそれらを含まないことを伝えるよう意図される。したがって、そのような条件付き言語は、一般に、特徴、要素、および／もしくはステップが、いかなる形であれ１つ以上の実施形態に必要であること、または、作者による入力もしくは指示の有無に関わらず、これらの特徴、要素、および／もしくはステップが任意の特定の実施形態に含まれていようと、そこで実行されようと、１つ以上の実施形態が、決定するための論理を必然的に含むことを示唆することを意図しない。「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｖｉｎｇ）」等の用語は、同義語であり、開放様式で包括的に使用され、追加的な要素、特徴、作用、動作等を排除しない。また、「または」という用語は、例えば要素のリストを接続するために使用されるときに、「または」という用語が、そのリストの中の要素の１つ、いくつか、もしくは全てを意味するように、その包括的な意味合いで使用される（また、その排他的な意味では使用されない）。

特定の例示的な実施形態を説明してきたが、これらの実施形態は、単なる例として提示されたものであり、本明細書で開示される本発明の範囲を限定することを意図しない。したがって、いかなる上の説明においても、任意の特定の特徴、特性、ステップ、モジュール、またはブロックが必要もしくは不可欠であることを示唆することを意図しない。実際に、本明細書で説明される新しい方法およびシステムは、種々の他の形態で具現化することができ、さらに、本明細書で開示される本発明の趣旨から逸脱することなく、本明細書で説明される方法およびシステムの形態において、種々の省略、置換、および変更を行うことができる。添付の付記およびそれらの均等物は、本明細書で開示される本発明の特定の範囲および趣旨の範囲内に含まれる、そのような形態または修正例を包含しようとすることが意図される。

Claims (15)

1. メトリックにタグ付けするためのシステムであって、
   コンピュータハードウェアを備えるコンピュータシステムを備え、前記コンピュータシステムは、１つ以上のコンピューティングノードを備え、かつ、
   デフォルトタグをメトリックに少なくとも挿入することによって、前記コンピューティングノードの１つ以上の性能に関連する１つ以上の前記メトリックに、キーおよび値の対を備える前記デフォルトタグをタグ付けするように構成される、デフォルトタグ付けモジュールと、
   前記１つ以上のメトリックにタグ付けする際に使用される少なくとも１つの追加タグを受信するように構成される、取得モジュールであって、前記少なくとも１つの追加タグは、前記デフォルトタグとは異なる、取得モジュールと、
   前記少なくとも１つの追加タグを分析して、前記１つ以上のメトリックに前記少なくとも１つの追加タグをタグ付けするために通信する、１つ以上のコンピューティングノードを決定するように構成される、処理モジュールと、
   前記決定された１つ以上のコンピューティングノードと通信して、前記１つ以上のメトリックに前記少なくとも１つの追加タグをタグ付けすることを要求し、それによって、前記タグ付けされたメトリックをその後に集約することを可能にするように構成される、タグ付けモジュールと、
   を実装するようにプログラムされる、システム。
2. 前記取得モジュールはさらに、要求ユーザから前記少なくとも１つの追加タグの少なくとも１つを受信するように構成される、請求項１に記載のシステム。
3. 前記要求ユーザから受信した前記タグの少なくとも１つは、前記要求ユーザと関連付けられた請求識別子に関連する、先行する請求項のいずれか１項に記載のシステム。
4. 前記タグ付けモジュールはさらに、前記複数のコンピューティングノードと通信することによって、前記１つ以上のメトリックにタグ付けするように構成される、先行する請求項のいずれか１項に記載のシステム。
5. 前記タグ付けされたメトリックは、処理ユーザまたはアプリケーションによって集約されるように構成される、先行する請求項のいずれか１項に記載のシステム。
6. メトリックにタグ付けする方法であって、
   コンピュータハードウェアを備える１つ以上のコンピュータシステムによって、
   １つ以上のメトリックに、キーおよび値対を備えるデフォルトタグをタグ付けすることと、
   前記１つ以上のメトリックにタグ付けする際に使用される少なくとも１つの追加タグを受信することであって、前記少なくとも１つの追加タグは、前記デフォルトタグとは異なる、受信することと、
   前記１つ以上のメトリックに前記追加タグをタグ付けするために通信する１つ以上のコンピューティングノードを決定するために、前記追加タグを分析することと、
   前記決定された１つ以上のコンピューティングノードと通信して、前記１つ以上のメトリックに前記追加タグをタグ付けすることを要求し、それによって、前記タグ付けされたメトリックをその後に処理することを可能にすることと、
   を含む、方法。
7. アプリケーションプログラミングインターフェースを使用して、前記複数のコンピューティングノードと通信することをさらに含む、請求項６に記載の方法。
8. 前記要求ユーザまたはアプリケーションから、前記少なくとも１つの追加タグに対する少なくとも１つの修正を受信し、前記少なくとも１つの修正に少なくとも基づいて、前記分析および通信ステップを行うことをさらに含む、請求項６または７に記載の方法。
9. 前記コンピューティングノードの少なくとも１つは、ロードバランサ、ファイアウォール、物理マシン、仮想マシン、記憶ノード、およびデータベースサーバのうちの１つ以上を備える、請求項６〜８のいずれか１項に記載の方法。
10. 前記処理アプリケーションは、グラフィカルユーザインターフェースアプリケーションである、請求項６〜９のいずれか１項に記載の方法。
11. 前記タグ付けされたメトリックは、処理ユーザまたはアプリケーションによって処理される、請求項６〜１０のいずれか１項に記載の方法。
12. 前記処理ユーザまたは前記処理アプリケーションに、前記タグ付けされたメトリックを出力することをさらに含む、請求項１１のいずれか１項に記載の方法。
13. 前記少なくとも１つの追加タグの少なくとも１つは、要求アプリケーションに由来する、請求項６〜１２のいずれか１項に記載の方法。
14. 前記要求アプリケーションおよび処理アプリケーションは、異なる、請求項１３に記載の方法。
15. 前記少なくとも１つの追加タグの少なくとも１つは、要求ユーザに由来する、請求項６〜１４のいずれか１項に記載の方法。

Images