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 バケットを使用していない場合、指標データは返されません。
組み込み指標タイプ
組み込み指標タイプは、Google Cloud サービス（Cloud Monitoring を含む）によって定義されます。この指標タイプは、一般的なインフラストラクチャの標準的な測定値を記述し、誰でも使用できます。
指標の一覧には、組み込み指標タイプがすべて表示されます。外部指標リストページに表示される指標は、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 インスタンスなどのリソースを構成するときに、独自のリソース メタデータ ラベルを作成することもできます。
システム メタデータ ラベルとユーザー メタデータ ラベルは、まとめてリソース メタデータ ラベルと呼ばれます。これらのラベルは、時系列フィルタでの指標やモニタリング対象リソースタイプで定義されたラベルと同様に使用できます。フィルタリングの詳細については、モニタリング フィルタをご覧ください。
時系列: モニタリング対象リソースからのデータ
このセクションでは、モニタリング データの概要と時系列での構成について説明します。ここでは、指標モデルのコンセプト コンポーネントが具体的なアーティファクトになります。
Cloud Monitoring は、指標とモニタリング対象リソースタイプのペアの定期的な測定値を保存します。測定値は時系列で収集され、各時系列には次の項目が含まれます。
時系列が属する指標タイプの名前と、指標ラベルの値の組み合わせの 1 つ。
一連の（タイムスタンプtimestamp、値timestamp）ペア。値は測定値で、タイムスタンプは測定が行われた時刻です。
時系列データのソースであるモニタリング対象リソースと、リソースのラベルの値の 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 プロジェクトがある場合は、Monitoring API の timeSeries.list メソッドに関するリファレンス ページにある API Explorer ウィジェットを試すことができます。
timeSeries.listリファレンス ページを開きます。[Try this method] というラベルが付いたペインに、次のコードを入力します。
- 名前:
projects/PROJECT_IDは、Google Cloud プロジェクトの ID をPROJECT_IDに置き換えます。 - フィルタ:
metric.type="logging.googleapis.com/log_entry_count" resource.type="gce_instance" - interval.start_time: 開始時間を入力し、終了時間の 20 分前であることを確認します。
- interval.end_time: 終了時間を入力します。
- 名前:
リクエストが成功すると、リクエストに一致する時系列データが返されます。それは次のスニペットのようになります。
{
"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 のグローバル スケール インメモリ時系列データベースをご覧ください。
Cloud Monitoring のユーザー定義指標の上限については、ユーザー定義指標をご覧ください。