Cloud Monitoring のデータ モニタリング モデルは、次の 3 つの主要なコンセプトで構成されています。
- モニタリング対象リソースタイプ
- 指標タイプ
- 時系列
ドキュメントの指標モデルでは、これらの Cloud Monitoring のコンセプトを一般的な用語で説明しています。これらのコンセプトについて初めてご覧になる場合は、まずこのページをお読みください。
このページでは、指標タイプ、モニタリング対象リソース、時系列のほか、関連するいくつかのコンセプトについて詳しく説明します。これらのコンセプトは、すべての Monitoring 指標の基礎になっています。
次のいずれかを行う場合は、このページの情報を理解しておく必要があります。Metrics Explorer を使用して指標データを検査する。
アラート ポリシーの使用で説明されているように、値が通常の上限を超えたときに通知するアラート ポリシーを作成する。
時系列データを取得するで説明されているように、Monitoring API を使用して未加工または集計されたモニタリング データを取得する。
ユーザー定義の指標の概要の説明に沿って、独自の指標タイプを作成する。
ラベルについて
モニタリング対象リソースタイプと指標タイプはどちらもラベルをサポートしており、分析中にデータを分類できます。例:
- 仮想マシンのモニタリング対象リソースタイプには、マシンのロケーションのラベルとマシンに関連するプロジェクト ID が含まれている場合があります。モニタリング対象リソースに関する情報が記録される場合、その情報にはラベルの値が含まれます。モニタリング対象リソースには、モニタリング対象リソースタイプで定義されたラベルに加えて、システムまたはユーザー指定のメタデータ ラベルが含まれる場合があります。
- API リクエストをカウントする指標タイプは、呼び出されたメソッドの名前とリクエストのステータスを記録するラベルを持つ場合があります。
ラベルの使用方法の詳細については、ラベルをご覧ください。
モニタリング対象リソースタイプ
モニタリング対象リソースとは、指標データがキャプチャされるリソースのことです。Cloud Monitoring は約 270 種類のモニタリング対象リソースをサポートしています。
モニタリング対象リソースのタイプには、汎用のノードとタスク、Google Kubernetes Engine のアーキテクチャ コンポーネント、Bigtable のテーブル、各種 AWS リソースなど、さまざまなものがあります。モニタリング対象リソースの各タイプは、モニタリング対象リソース記述子と呼ばれるデータ構造で正式に記述されます。詳細については、モニタリング対象リソースの記述子をご覧ください。
サポートされているモニタリング対象リソースタイプはそれぞれ、モニタリング対象リソースのリストにエントリがあります。リスト内のエントリは、モニタリング対象リソース記述子から作成されています。このセクションでは、モニタリング対象リソース記述子でキャプチャされる情報について説明し、リストでどのように表示されるかを示します。
モニタリング対象リソースタイプのサンプル
次の図は、Cloud Storage バケットのリスト内のエントリを示しています。
リスト内のすべてのエントリには、次の情報が含まれます。
- タイプ: エントリのヘッダーには、モニタリング対象リソースのタイプが掲載されます。この例では
gcs_bucketです。 - 表示名: モニタリング対象リソースの簡単な説明。
- 説明: モニタリング対象リソースの詳しい説明。
- ラベル: データを分類するための一連のディメンション。詳細については、ラベルをご覧ください。
指標タイプ
指標タイプは、モニタリング対象リソースから収集できる測定値を表します。指標タイプには、測定対象と、測定値の解釈方法についての説明が含まれます。Cloud Monitoring は約 6,500 種類の指標をサポートし、新しいタイプを定義する機能を備えています。指標タイプには、API 呼び出しの数、ディスク使用量の統計情報、ストレージ消費量など、さまざまなものがあります。
各指標タイプは、指標記述子と呼ばれるデータ構造で正式に記述されます。詳しくは、指標記述子をご覧ください。
組み込み指標タイプはそれぞれ、指標リストページにエントリがあります。これらのテーブルのエントリは、指標記述子から作成されています。このセクションでは、指標タイプでキャプチャされる情報について説明し、参考資料でどのように表示されるかを示します。
指標タイプのサンプル
次の図は、Cloud Storage 指標タイプのエントリを示しています。
テーブルに指標タイプが表示され、テーブルのヘッダーには情報レイアウトの説明が表示されます。このセクションでは例として 1 つのエントリを使用していますが、すべてのテーブルで同じ形式を採用しています。
サンプルの Cloud Storage テーブル エントリでは、1 つの指標タイプについて次の情報が提供されます。
指標タイプ: 指標タイプの識別子。この例では
storage.googleapis.com/api/request_countです。接頭辞
storage.googleapis.comは、Cloud Storage 用の名前空間として機能します。特定のモニタリング対象リソースタイプに関連付けられている指標タイプはすべて、同じ名前空間を使用します。テーブル内のエントリは、名前空間が省略されています。
Cloud Storage に関連付けられている指標タイプはすべて、Cloud Storage 指標のテーブルに掲載されています。
リリース ステージ: 色分けされたブロックで、指標タイプのリリース ステージ（アルファ、ベータ、一般提供など）を示します。
表示名: 指標タイプを説明する短い文字列。この例では「リクエスト数」です。
種類、型、単位: この行は、データ値を解釈するための情報を提供します。この例では、単位のない 64 ビット整数として記録されたデルタ指標（つまり、
1値）です。モニタリング対象リソース: この指標タイプを使用できるモニタリング対象リソース。値は、モニタリング対象リソースタイプで説明されている値と同じです。
説明: 記録された内容とその記録方法に関する詳細情報。ラベルとは斜体で区別します。
ラベル: データを分類するための一連のディメンション。詳細については、ラベルをご覧ください。
Cloud Monitoring API を使用してモニタリング データにアクセスするときは、API 呼び出しに Google Cloud プロジェクトを含めます。取得できるのは、その Google Cloud プロジェクトに表示されるデータのみです。たとえば、指標タイプ storage.googleapis.com/api/request_count についてプロジェクトのデータをリクエストすると、プロジェクト内の Cloud Storage バケットの API カウントのみが表示されます。プロジェクトで Cloud Storage バケットを使用していない場合、指標データは返されません。
組み込み指標タイプ
組み込み指標タイプは、Cloud Monitoring などの Google Cloud サービスによって定義されます。この指標タイプは、一般的なインフラストラクチャの標準的な測定値を記述するものであり、誰でも使用できます。
指標リストには、組み込み指標タイプがすべて表示されます。外部指標リストページに表示される指標は、Cloud Monitoring とオープンソース プロジェクトまたはサードパーティ プロバイダが連携して定義している、組み込み指標の特別なサブセットです。通常、これらの指標にはexternal.googleapis.com という接頭辞が付いています。
カスタム指標
アプリケーションをビルドする際に、測定する必要がある特定のプロパティが存在するものの、Cloud Monitoring に指標が組み込まれていない場合があります。Cloud Monitoring では、独自の指標タイプを定義したり、外部ソースから指標タイプをインポートしたりできます。これらの指標タイプはカスタム指標と呼ばれます。指標の接頭辞が custom.googleapis.com または prometheus.googleapis.com の場合はカスタム指標です。後者の指標は通常、Google Cloud Managed Service for Prometheus から取得されます。
たとえば、ストアで販売されるウィジェットの数を追跡する場合、カスタム指標を使用する必要があります。詳しくは、ユーザー定義の指標の概要をご覧ください。
ラベル
ラベルとは、データ値に関する情報を指定するために使用できる Key-Value ペアのことです。
指標とモニタリング対象リソースのラベル
指標タイプもモニタリング対象リソースタイプも、その定義にはラベルが含まれています。ラベルは収集するデータを分類する手段です。より詳細な分析を行うためにデータを分類するのに役立ちます。例:
- Cloud Storage の指標タイプ
storage.googleapis.com/api/request_countには、response_codeとmethodという 2 つのラベルがあります。 - Cloud Storage モニタリング対象リソースタイプ
gcs_bucketには、project_id、bucket_name、locationという 3 つのラベルがあります。ラベルは、リソースタイプの特定のインスタンスを識別します。
したがって、Cloud Storage バケットから収集された API リクエストのすべてのデータは、呼び出されたメソッド、呼び出しのレスポンス コード、および関係するバケットの名前、ロケーション、プロジェクトによって分類されます。ラベルのセットは、指標またはモニタリング対象リソースタイプによって異なります。使用可能なラベルは、指標リストとモニタリング対象リソースリストのページに記載されています。
API 呼び出しをカウントする際にレスポンス コード、メソッド名、ロケーションを追跡することで、特定の API メソッドの呼び出し数、メソッド呼び出しの失敗数、特定のロケーションでの特定のメソッド呼び出しの失敗数を取得できます。
ラベルの数と各ラベルが取り得る値の数をカーディナリティと呼びます。カーディナリティは、指標とモニタリング対象リソースタイプのペアに対して収集される可能性のある時系列の数です。ラベルの値の 1 つの組み合わせに対して 1 つの時系列があります。詳細については、カーディナリティ: 時系列とラベルをご覧ください。
リソース メタデータ ラベル
指標とモニタリング対象リソースタイプで定義されたラベルに加えて、Monitoring は、モニタリング対象リソースに関する追加情報を内部で収集し、システム メタデータ ラベルに保存します。これらのシステム メタデータ ラベルは、読み取り専用の値として使用できます。一部のリソースでは、 Google Cloud コンソールで VM インスタンスなどのリソースを構成するときに、独自のリソース メタデータ ラベルを作成することもできます。
システム メタデータ ラベルとユーザー メタデータ ラベルは、まとめてリソース メタデータ ラベルと呼ばれます。これらのラベルは、時系列フィルタでの指標やモニタリング対象リソースタイプで定義されたラベルと同様に使用できます。
リソース メタデータ ラベルは、明示的に集計する場合にのみクエリ結果に表示されます。
フィルタリングの詳細については、Monitoring フィルタをご覧ください。
時系列: モニタリング対象リソースからのデータ
このセクションでは、モニタリング データの概要と時系列での構成について説明します。ここでは、指標モデルのコンセプト コンポーネントが具体的なアーティファクトになります。
Cloud Monitoring は、指標とモニタリング対象リソースタイプのペアについて、定期的な測定値を経時的に保存します。測定値は時系列で収集され、各時系列には次の項目が含まれます。
時系列が属する指標タイプの名前と、指標ラベルの値の 1 つの組み合わせ。
一連の（タイムスタンプ、値）ペア。値は測定値で、タイムスタンプは測定が行われた時刻です。
時系列データのソースであるモニタリング対象リソースと、リソースのラベルの値の 1 つの組み合わせ。
時系列は、データを生成する指標とリソースラベルの組み合わせごとに作成されます。
様式化された例: 指標タイプ storage.googleapis.com/api/request_count には、プロジェクトの Cloud Storage バケットに多数の時系列を含めることができます。次の図は、考えられる時系列の例を示しています。
この図では、値 bucket: xxxx はモニタリング対象リソースタイプの bucket_name ラベルの値を表し、response_code と method は指標タイプのラベルを表します。リソースと指標ラベルの値の組み合わせごとに 1 つの時系列があります。この図は、その一部を示しています。
Cloud Monitoring では、空の時系列が記録されません。Cloud Storage バケットの例では、特定のバケットを使用していない場合や、特定の API メソッドを一度も呼び出さない場合、そのラベルについてはデータは収集されず、時系列でメンションされません。つまり、プロジェクトに特定の指標のデータがまったくない場合、指標タイプは決して表示されません。
指標タイプは、指標の時系列に存在するモニタリング対象リソースのタイプを示しません。Cloud Storage のモニタリング対象リソースタイプは、gcs_bucket 1 つのみです。一部の指標タイプは、複数のモニタリング対象リソースとペアになっています。
実際の例: Google Cloud プロジェクトがある場合は、API Explorer ウィジェットを試すことができます。このツールは Monitoring API の timeSeries.list メソッドに関するリファレンス ページにあります。
timeSeries.listリファレンス ページを開きます。[Try this method] というラベルが付いたペインに、次のコードを入力します。
- name:
projects/PROJECT_ID。PROJECT_IDは実際の Google Cloud プロジェクトの ID に置き換えます。 - filter:
metric.type="logging.googleapis.com/log_entry_count" resource.type="gce_instance" - interval.start_time: 開始時刻を入力し、終了時刻の 20 分前であることを確認します。
- interval.end_time: 終了時刻を入力します。
- name:
リクエストが成功すると、リクエストに一致する時系列データが返されます。次のスニペットのようになります。
{
"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": "2024-03-29T13:53:00Z",
"endTime": "2024-03-29T13:54:00Z"
},
"value": {
"int64Value": "0"
}
},
...
]
},
...
]
}
トラブルシューティングを含め、API Explorer ウィジェットの使用方法の詳細については、API Explorer の使用をご覧ください。
カーディナリティ: 時系列とラベル
すべての時系列は、指標とモニタリング対象リソースタイプの特定のペアに関連付けられます。指標とモニタリング対象リソースタイプには、それぞれいくつかのラベルがあります。Cloud Monitoring では、一連のラベルに対する値の一意の組み合わせの数が、指標タイプまたはモニタリング対象リソースタイプのカーディナリティです。これらの値は、指標カーディナリティとリソース カーディナリティと呼ばれ、これにより、生成される可能性のある時系列の数（合計カーディナリティ）が決定します。
指標、リソース、合計カーディナリティ
たとえば、color と zone の 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）。
独自の指標を設計する際は、ラベルに使用できる一連の値に制約があることを確認してください。少数の個別の値（「red」、「green」、「blue」など）を使用することをおすすめします。たとえば、color ラベルに 8 ビット RGB 値を使用する場合、値の数は 1,600 万を超えます。指標ラベルには、タイムスタンプ、一意の ID、ユーザー ID、IP アドレス、パラメータ化されていない URL などの高解像度値を使用しないでください。
クエリのパフォーマンスとカーディナリティ
データに対するクエリを発行すると、リクエストするデータ量がクエリのパフォーマンスを左右する最大の要因になります。通常、1 時間のデータに対するクエリは、同じクエリが 6 か月全体をカバーする場合よりも高速です。ただし、リクエストによって返されるデータの量は、リクエスト内の時系列の数にも左右されます。カーディナリティが低い指標の 2 か月分のデータを取得するクエリは、取得するデータ量の違いにより、カーディナリティが非常に高い指標の 2 か月分のデータを取得するクエリよりも高速である可能性が高くなります。
カーディナリティは主に、ラベルの数ではなく、ラベルの取り得る値の数によって異なります。一般に、ビジネスニーズに基づいて Pod や VM の数を変更する場合と同様に、リソースのカーディナリティを制御することはできません。ただし、システム指標を使用するのではなく Cloud Monitoring に指標を取り込むと、指標のカーディナリティをある程度制御できます。たとえば、ユーザー定義のカスタム指標を使用して、ラベルと使用可能な値を決定します。Prometheus 指標を取り込む場合は、ラベル変更を使用すると、一連のラベルの変更と、取り込まない時系列の除外を行えます。
Cloud Monitoring の [指標の管理] ページを使用して、カーディナリティの問題がある可能性のある指標を特定できます。[指標の管理] ページを表示するには、次の操作を行います。
-
Google Cloud コンソールで、[ 指標の管理] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
- ツールバーで時間枠を選択します。デフォルトでは、[指標の管理] ページには、過去 1 日間に収集された指標に関する情報が表示されます。
[指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。
Cloud Monitoring で時系列データの保存と取得を行う方法に関する技術的な背景については、Monarch: Google's Planet-Scale In-Memory Time Series Database をご覧ください。
Cloud Monitoring のユーザー定義指標の上限については、ユーザー定義指標をご覧ください。