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

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

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

Cloud Monitoring の指標モデルでは、これらのコンセプトを一般的な用語で説明しています。これらのコンセプトが新しい場合は、まずこのページをお読みください。

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

次のいずれかを行う場合は、このページの情報を理解する必要があります。

これらのコンセプトと Cloud Monitoring API へのマッピング方法の詳細については、時系列の構造をご覧ください(特に Monitoring API またはカスタム指標を使用する場合)。

ラベルに関する注意事項

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

  • 仮想マシンのモニタリング対象リソースタイプには、マシンのロケーションのラベルと、マシンに関連付けられているプロジェクト ID が含まれる場合があります。モニタリング対象リソースに関する情報が記録される場合、この情報にはラベルの値が含まれます。

    モニタリング対象リソースには、モニタリング対象リソースタイプで定義されたラベルに加えて、システムまたはユーザー指定のメタデータ ラベルが含まれる場合があります。

  • API リクエストをカウントする指標タイプには、呼び出されたメソッドの名前とリクエストのステータスを記録するラベルを持つ場合があります。

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

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

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

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

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

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

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

Cloud Storage バケットの一覧にあるエントリをご覧ください。

Cloud Storage バケットのリスト。

表のすべてのエントリには次の情報が含まれています。

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

指標タイプ

指標タイプは、モニタリング対象リソースから収集できる測定値を記述します。指標タイプには、測定対象と測定方法の説明が含まれます。 最終的に、Cloud Monitoring は約 1,500 種類の指標をサポートし、新しいタイプを定義できるようになります。

指標タイプには、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 は、単位が不要であることを示しています。

  • モニタリング対象リソース: この指標タイプが利用可能であるモニタリング対象のリソース。ここに表示される値は、モニタリング対象リソースタイプで説明されている値と同じです。

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

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

現在の Google Cloud プロジェクトまたはワークスペースに属するモニタリング データにのみアクセスできます。たとえば、storage.googleapis.com/api/request_count 指標タイプからデータをリクエストすると、プロジェクト内の Cloud Storage バケットの API カウントのみが表示されます。プロジェクトで Cloud Storage バケットを使用していない場合、バケットから指標データは取得されません。

組み込み指標タイプ

組み込み指標タイプは、Cloud Monitoring を含む Google Cloud サービスによって定義されます。これらの指標タイプは、さまざまな共通インフラストラクチャの標準的な測定値を記述し、誰でも使用できます。

指標の一覧には、組み込み指標タイプがすべて表示されます。 外部指標の一覧ページに記載されている指標は、オープンソース プロジェクトまたはサードパーティ プロバイダとの提携により Cloud Monitoring で定義されている組み込み指標の特別なサブセットです。通常、これらの指標には接頭辞 external.googleapis.com が付いています。

カスタム指標

アプリケーションをビルドするとき、特定のプロパティを測定したくても、適用できる組み込み指標がない場合があります。Cloud Monitoring では、独自の指標タイプを定義できます。これらの指標タイプはカスタム指標と呼ばれます。指標に接頭辞として custom.googleapis.com または external.googleapis.com/prometheus が付いている場合、それはカスタム指標です。後者の指標は通常、Stackdriver Prometheus サイドカーから取得されます。詳しくは、Prometheus の使用をご覧ください。

たとえば、ストアで販売されるウィジェットの数を追跡する場合、カスタム指標を使用する必要があります。詳しくは、カスタム指標の使用をご覧ください。

ラベル

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

  • 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 つの時系列があります。詳細については、カーディナリティ: 時系列とラベルをご覧ください。

リソース メタデータ ラベル

指標とモニタリング対象リソースタイプで定義されたラベルに加えて、Monitoring は、モニタリング対象リソースに関する追加情報を内部で収集し、システム メタデータ ラベルに保存します。これらのシステム メタデータ ラベルは、読み取り専用の値として使用できます。一部のリソースでは、Google Cloud Console で VM インスタンスなどのリソースを構成するときに、独自のリソース メタデータ ラベルを作成することもできます。

システム メタデータ ラベルとユーザー メタデータ ラベルは、まとめてリソース メタデータ ラベルと呼ばれます。これらのラベルは、時系列フィルタでの指標やモニタリング対象リソースタイプで定義されたラベルと同様に使用できます。フィルタリングの詳細については、モニタリング フィルタをご覧ください。

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

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

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 つのみです。一部の指標タイプは、複数のモニタリング対象リソースとペアになっています。

実際の例: ワークスペースに Google Cloud プロジェクトがある場合、Monitoring API の timeSeries.list メソッドの参照ページにあるAPI Explorer ウィジェットを試すことができます。下の [TRY IT]ボタンは、timeSeries.list メソッドに以下のデフォルト パラメータを設定します。

  • 名前: projects/[PROJECT_ID]
  • フィルタ: metric.type="logging.googleapis.com/log_entry_count" resource.type="gce_instance"
  • interval.start_time: 2019-11-11T00:00:00Z
  • interval.end_time: 2019-11-11T00:20:00Z
  • フィールド: timeSeries.metric

この例を実行するには、名前フィールドの [PROJECT_ID をプロジェクト ID に変更する必要があります。

この例では、Compute Engine インスタンスが Cloud Logging エージェントで実行していることを前提としています。モニタリング対象リソースのタイプは gce_instance、指標タイプは logging.googleapis.com/log_entry_count です。該当する値がない場合は変更できます。

時系列データを取得する場合は、開始時刻と終了時刻を指定する必要があります。この例では、2019 年 11 月 11 日の期間を使用します。ただし、時系列データは 6 週間保存されるため、リクエストを実行する前に、日付も調整する必要があります。

リクエストを実行するには、下のボタンをクリックし、必要に応じてパラメータを調整し、ウィジェット パネルの下部にある [実行]ボタンをクリックします。

試してみる

リクエストが成功すると、リクエストに一致する時系列データが返されます。次のようになります。

{
  "timeSeries": [
    {
      "metric": {
        "labels": {
          "severity": "INFO",
          "log": "compute.googleapis.com/activity_log"
        },
        "type": "logging.googleapis.com/log_entry_count"
      },
      "resource": {
        "type": "gce_instance",
        "labels": {
          "instance_id": "0",
          "zone": "us-central1",
          "project_id": "your-project-id"
        }
      },
      "metricKind": "DELTA",
      "valueType": "INT64",
      "points": [
        {
        "interval": {
            "startTime": "2019-10-29T13:53:00Z",
            "endTime": "2019-10-29T13:54:00Z"
          },
          "value": {
            "int64Value": "0"
          }
        },
        ...
      ]
    },
    ...
  ]
}

このウィジェットの使用方法(トラブルシューティングなど)について詳しくは、API Explorer をご覧ください。

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

各時系列は、指標とモニタリング対象リソースタイプの特定のペアに関連付けられていますが、各ペアには多くの時系列を設定できます。設定可能な時系列の数は、ペアのカーディナリティ(ラベルの数と、各ラベルが受け入れることができる値の数)によって決まります。

たとえば、あるラベル color を指定するごく普通の指標タイプと、別のラベル zone を持つモニタリング対象リソースタイプがあるとします。zonecolor の値の組み合わせごとに時系列を取得します。

値について、1 つのラベルが取り得る数は次のとおりです。

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

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

この指標のカーディナリティは 6 (3×2) ですが、この指標では時系列の数が少ない可能性があります。たとえば、「west」ゾーンからデータを取得しない場合、3 つを超える時系列を取得することはありません。

指標のカーディナリティは、グラフやその他の用途において指標をリクエストする際のパフォーマンスに関する重要な要素です。カーディナリティが高い場合は、クエリの応答時間が長くなる可能性があります。

カーディナリティは、カスタム指標の設計(ラベルのセットとその可能な値が決定されます)にも関係します。指標タイプでは使用できるラベルは最大 10 個ですが、ラベルに可能な値のセットも制限する必要があります。少数の個別の値(「赤」、「緑」、「青」など)を使用することをおすすめします。タイムスタンプなどのきめ細かな値は使用できません。カスタム指標には他にも制限があります。詳細については、カスタム指標をご覧ください。