指標モデルのコンポーネント

Cloud Monitoring のデータ モニタリング モデルは、次の 3 つの主要なコンセプトで構成されています。

  • モニタリング対象リソースタイプ
  • 指標タイプ
  • 時系列

ドキュメントの指標モデルでは、これらの Cloud Monitoring のコンセプトを一般的な用語で説明しています。これらのコンセプトについて初めてご覧になる場合は、まずこのページをお読みください。

このページでは、指標タイプ、モニタリング対象リソース、時系列のほか、関連するいくつかのコンセプトについて詳しく説明します。これらのコンセプトは、すべての Monitoring 指標の基礎になっています。

時系列データを取得するに記載されているように、Monitoring API を使用して未加工または集計されたモニタリング データを取得する場合、このページの情報を理解しておく必要があります。これらのコンセプトと Cloud Monitoring API へのマッピング方法の詳細については、時系列の構造をご覧ください(特に Monitoring API を使用する場合)。

ラベルについて

モニタリング対象リソースタイプと指標タイプはどちらもラベルをサポートしており、分析中にデータを分類できます。例:

  • 仮想マシンのモニタリング対象リソースタイプには、マシンのロケーションのラベルとマシンに関連するプロジェクト ID が含まれている場合があります。モニタリング対象リソースに関する情報が記録される場合、その情報にはラベルの値が含まれます。
  • API リクエストをカウントする指標タイプは、呼び出されたメソッドの名前とリクエストのステータスを記録するラベルを持つ場合があります。

ラベルの使用方法の詳細については、ラベルをご覧ください。

モニタリング対象リソースタイプ

モニタリング対象リソースとは、指標データがキャプチャされるリソースのことです。Cloud Monitoring は約 270 種類のモニタリング対象リソースをサポートしています。

モニタリング対象リソースのタイプには、汎用のノードとタスク、Google Kubernetes Engine のアーキテクチャ コンポーネントなど、さまざまなものがあります。

モニタリング対象リソースの各タイプは、モニタリング対象リソース記述子と呼ばれるデータ構造で正式に記述されます。詳細については、モニタリング対象リソースの記述子をご覧ください。

サポートされているモニタリング対象リソースタイプはそれぞれ、モニタリング対象リソースのリストにエントリがあります。リスト内のエントリは、モニタリング対象リソース記述子から作成されています。このセクションでは、モニタリング対象リソース記述子でキャプチャされる情報について説明し、リストでどのように表示されるかを示します。

モニタリング対象リソースタイプのサンプル

次の図は、Cloud Storage バケットのリスト内のエントリを示しています。

Cloud Storage バケットのリスト。

リスト内のすべてのエントリには、次の情報が含まれます。

  • タイプ: エントリのヘッダーには、モニタリング対象リソースのタイプが掲載されます。この例では gcs_bucket です。
  • 表示名: モニタリング対象リソースの簡単な説明。
  • 説明: モニタリング対象リソースの詳しい説明。
  • ラベル: データを分類するための一連のディメンション。詳細については、ラベルをご覧ください。

指標タイプ

指標タイプは、モニタリング対象リソースから収集できる測定値を表します。指標タイプには、測定対象と、測定値の解釈方法についての説明が含まれます。

指標タイプには、API 呼び出しの数、ディスク使用量の統計情報、ストレージ消費量など、さまざまなものがあります。

各指標タイプは、指標記述子と呼ばれるデータ構造で正式に記述されます。詳しくは、指標記述子をご覧ください。

組み込み指標タイプはそれぞれ、指標リストページにエントリがあります。これらのテーブルのエントリは、指標記述子から作成されています。このセクションでは、指標タイプでキャプチャされる情報について説明し、参考資料でどのように表示されるかを示します。

指標タイプのサンプル

次の図は、Cloud Storage 指標タイプのエントリを示しています。

Cloud Storage の指標リストの抜粋。

テーブルに指標タイプが表示され、テーブルのヘッダーには情報レイアウトの説明が表示されます。このセクションでは例として 1 つのエントリを使用していますが、すべてのテーブルで同じ形式を採用しています。

サンプルの Cloud Storage テーブル エントリでは、1 つの指標タイプについて次の情報が提供されます。

  • 指標タイプ: 指標タイプの識別子。この例では storage.googleapis.com/api/request_count です。

    接頭辞 storage.googleapis.com は、Cloud Storage 用の名前空間として機能します。特定のモニタリング対象リソースタイプに関連付けられている指標タイプはすべて、同じ名前空間を使用します。

    テーブル内のエントリは、名前空間が省略されています。

    Cloud Storage に関連付けられている指標タイプはすべて、Cloud Storage 指標のテーブルに掲載されています。

  • リリース ステージ: 色分けされたブロックで、指標タイプのリリース ステージ(アルファ、ベータ、一般提供など)を示します。

  • 表示名: 指標タイプを説明する短い文字列。この例では「リクエスト数」です。

  • 種類、型、単位: この行は、データ値を解釈するための情報を提供します。この例では、単位のない 64 ビット整数として記録されたデルタ指標(つまり、1 値)です。

    • 種類: この例は、一定期間の変化を記録するデルタ指標です。つまり、各データポイントは、前のデータポイントが書き込まれてからの API 呼び出しの回数を記録します。種類の詳細については、値の型と指標の種類をご覧ください。

    • 型: この例では、値を 64 ビット整数として記録します。型の詳細については、値の型と指標の種類をご覧ください。

    • 単位: この例の指標はカウントを表しているため、明示的な単位は必要ありません。数字の 1 は、単位が不要であることを示しています。

  • モニタリング対象リソース: この指標タイプを使用できるモニタリング対象リソース。値は、モニタリング対象リソースタイプで説明されている値と同じです。

  • 説明: 記録された内容とその記録方法に関する詳細情報。ラベルとは斜体で区別します。

  • ラベル: データを分類するための一連のディメンション。詳細については、ラベルをご覧ください。

Cloud Monitoring API を使用してモニタリング データにアクセスするときは、API 呼び出しに Trusted Cloud プロジェクトを含めます。取得できるのは、その Trusted Cloud プロジェクトに表示されるデータのみです。たとえば、指標タイプ storage.googleapis.com/api/request_count についてプロジェクトのデータをリクエストすると、プロジェクト内の Cloud Storage バケットの API カウントのみが表示されます。プロジェクトで Cloud Storage バケットを使用していない場合、指標データは返されません。

組み込み指標タイプ

組み込み指標タイプは、Cloud Monitoring などの Trusted Cloud by S3NS サービスによって定義されます。この指標タイプは、一般的なインフラストラクチャの標準的な測定値を記述するものであり、誰でも使用できます。

指標リストには、組み込み指標タイプがすべて表示されます。

ラベル

ラベルとは、データ値に関する情報を指定するために使用できる Key-Value ペアのことです。

指標とモニタリング対象リソースのラベル

指標タイプもモニタリング対象リソースタイプも、その定義にはラベルが含まれています。ラベルは収集するデータを分類する手段です。より詳細な分析を行うためにデータを分類するのに役立ちます。例:

  • Cloud Storage の指標タイプ storage.googleapis.com/api/request_count には、response_codemethod という 2 つのラベルがあります。
  • Cloud Storage モニタリング対象リソースタイプ gcs_bucket には、project_idbucket_namelocation という 3 つのラベルがあります。ラベルは、リソースタイプの特定のインスタンスを識別します。

したがって、Cloud Storage バケットから収集された API リクエストのすべてのデータは、呼び出されたメソッド、呼び出しのレスポンス コード、および関係するバケットの名前、ロケーション、プロジェクトによって分類されます。ラベルのセットは、指標またはモニタリング対象リソースタイプによって異なります。使用可能なラベルは、指標リストモニタリング対象リソースリストのページに記載されています。

API 呼び出しをカウントする際にレスポンス コード、メソッド名、ロケーションを追跡することで、特定の API メソッドの呼び出し数、メソッド呼び出しの失敗数、特定のロケーションでの特定のメソッド呼び出しの失敗数を取得できます。

ラベルの数と各ラベルが取り得る値の数をカーディナリティと呼びます。カーディナリティは、指標とモニタリング対象リソースタイプのペアに対して収集される可能性のある時系列の数です。ラベルの値の 1 つの組み合わせに対して 1 つの時系列があります。詳細については、カーディナリティ: 時系列とラベルをご覧ください。

時系列: モニタリング対象リソースからのデータ

このセクションでは、モニタリング データの概要と時系列での構成について説明します。ここでは、指標モデルのコンセプト コンポーネントが具体的なアーティファクトになります。

Cloud Monitoring は、指標とモニタリング対象リソースタイプのペアについて、定期的な測定値を経時的に保存します。測定値は時系列で収集され、各時系列には次の項目が含まれます。

  • 時系列が属する指標タイプの名前と、指標ラベルの値の 1 つの組み合わせ。

  • 一連の(タイムスタンプ、値)ペア。値は測定値で、タイムスタンプは測定が行われた時刻です。

  • 時系列データのソースであるモニタリング対象リソースと、リソースのラベルの値の 1 つの組み合わせ。

時系列は、データを生成する指標とリソースラベルの組み合わせごとに作成されます。

様式化された例: 指標タイプ storage.googleapis.com/api/request_count には、プロジェクトの Cloud Storage バケットに多数の時系列を含めることができます。次の図は、考えられる時系列の例を示しています。

この図では、値 bucket: xxxx はモニタリング対象リソースタイプの bucket_name ラベルの値を表し、response_codemethod は指標タイプのラベルを表します。リソースと指標ラベルの値の組み合わせごとに 1 つの時系列があります。この図は、その一部を示しています。

指標に複数の時系列が表示されている画像

Cloud Monitoring では、空の時系列が記録されません。Cloud Storage バケットの例では、特定のバケットを使用していない場合や、特定の API メソッドを一度も呼び出さない場合、そのラベルについてはデータは収集されず、時系列でメンションされません。つまり、プロジェクトに特定の指標のデータがまったくない場合、指標タイプは決して表示されません。

指標タイプは、指標の時系列に存在するモニタリング対象リソースのタイプを示しません。Cloud Storage のモニタリング対象リソースタイプは、gcs_bucket 1 つのみです。一部の指標タイプは、複数のモニタリング対象リソースとペアになっています。

カーディナリティ: 時系列とラベル

すべての時系列は、指標とモニタリング対象リソースタイプの特定のペアに関連付けられます。指標とモニタリング対象リソースタイプには、それぞれいくつかのラベルがあります。Cloud Monitoring では、一連のラベルに対する値の一意の組み合わせの数が、指標タイプまたはモニタリング対象リソースタイプのカーディナリティです。これらの値は、指標カーディナリティとリソース カーディナリティと呼ばれ、これにより、生成される可能性のある時系列の数(合計カーディナリティ)が決定します。

たとえば、colorzone の 2 つのラベルを指定する指標タイプがあるとします。指標カーディナリティは、ラベルの取り得る値の数によって異なります。

  • 「赤」、「緑」、「青」の 3 つの色しか使用できない場合、color ラベルには最大 3 つの異なる値を指定できます。
  • 「東」と「西」の 2 つのゾーンしかない場合、zone ラベルには最大 2 つの異なる値を指定できます。

この指標のカーディナリティは 6 です(3×2)。color ラベルの取り得る値が 1,000 個あり、すべての色がすべてのゾーンに表示される場合、指標カーディナリティは 2,000 です(1,000×2)。指標タイプではなくモニタリング対象リソースタイプのラベルの場合にも、同じ計算が適用されます。

このカーディナリティの値は、可能性のあるラベル値の組み合わせの数に基づいた最大値です。ラベル値のすべての組み合わせが実際に生じない場合、実際の実効値は大幅に低くなる可能性があります。たとえば、各色が両方のゾーンではなく 1 つのゾーンにのみ表示される場合、実行中のシステムに表示される時系列の最大数は 1,000 です。ただし、実際のカーディナリティの有用性は、特定の組み合わせが表示されない理由と、今後その組み合わせが生じるかどうかによって異なります。

カーディナリティは、ラベルの取り得る値によって異なります。

時系列データが書き込まれると、指標とモニタリング対象リソースタイプによって分類されます。指標とリソースタイプのすべてのペアの合計カーディナリティは、指標カーディナリティとリソース カーディナリティの積です。カーディナリティが 1,000 の指標と、カーディナリティが 100 のリソースがあり、すべてのラベル値が存在する場合、100,000 個の時系列があります(1,000×100)。