Cloud Monitoring のデータ モニタリング モデルは、次の 3 つの主要なコンセプトで構成されています。
- モニタリング対象リソースタイプ
- 指標タイプ
- 時系列
Cloud Monitoring の指標モデルでは、これらのコンセプトを一般的な用語で説明しています。これらのコンセプトが新しい場合は、まずこのページをお読みください。
このページでは、指標タイプ、モニタリング対象リソース、時系列、および関連するいくつかのコンセプトについて詳しく説明します。これらのコンセプトは、すべての Monitoring 指標の基礎になっています。
次のいずれかを行う場合は、このページの情報を理解する必要があります。
Metrics Explorer を使用して指標データを検査します。
アラート ポリシーの使用で説明されているように、値が通常の制限を超えたときに通知するアラート ポリシーを作成します。
指標データの読み取りで説明されているように、Monitoring API を使用して未加工または集約されたモニタリング データを取得します。
カスタム指標の使用の説明に従って、独自の指標タイプを作成します。
これらのコンセプトと Cloud Monitoring API へのマッピング方法の詳細については、時系列の構造をご覧ください（特に Monitoring API またはカスタム指標を使用する場合）。
ラベルに関する注意事項
モニタリング対象リソースタイプと指標タイプはどちらもラベルをサポートしており、分析中にデータを分類できます。例:
仮想マシンのモニタリング対象リソースタイプには、マシンの場所のラベルとマシンに関連するプロジェクト ID が含まれている場合があります。モニタリング対象リソースに関する情報が記録されると、この情報にはラベルの値が含まれます。
モニタリング対象リソースには、モニタリング対象リソースタイプで定義されたラベルに加えて、システムまたはユーザー指定のメタデータ ラベルが含まれる場合があります。
API リクエストをカウントする指標タイプには、呼び出されたメソッドの名前とリクエストのステータスを記録するラベルを持つ場合があります。
ラベルの使用方法の詳細については、ラベルをご覧ください。
モニタリング対象リソースタイプ
モニタリング対象リソースとは、指標データがキャプチャされたリソースをいいます。最新の集計では、Cloud Monitoring は約 100 種類のモニタリング対象リソースをサポートしています。
モニタリング対象リソースのタイプには、汎用ノードとタスク、Cloud Bigtable のテーブル、Google Kubernetes Engine のアーキテクチャ コンポーネント、さまざまな AWS リソースなどがあります。
モニタリング対象リソースの各タイプは、モニタリング対象リソース記述子と呼ばれるデータ構造で正式に記述されます。詳細については、モニタリング対象リソースタイプをご覧ください。
サポートされる各モニタリング対象リソースタイプには、モニタリング対象リソースリストのエントリがあります。リスト内のエントリは、モニタリング対象リソース記述子から作成されます。このセクションでは、モニタリング対象リソース記述子でキャプチャされる情報について説明し、リストでどのように表示されるかを示します。
モニタリング対象リソースタイプのサンプル
Cloud Storage バケットのリスト内のエントリは次のとおりです。
リスト内のすべてのエントリには、次の情報が含まれます。
- タイプ: エントリのヘッダーには、モニタリング対象リソースのタイプが一覧表示されます。この例では
gcs_bucketです。 - 表示名: モニタリング対象リソースの簡単な説明。
- 説明: モニタリング対象リソースの長い説明。
- ラベル: データを分類するための一連のディメンション。詳細については、ラベルをご覧ください。
指標タイプ
指標タイプは、モニタリング対象リソースから収集できる測定値を表します。指標タイプには、測定対象および測定値がどのように解釈されるかについての説明が含まれます。最新の集計では、Cloud Monitoring は約 1,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 では、独自の指標タイプを定義できます。これらの指標タイプはカスタム指標と呼ばれます。 指標に custom.googleapis.com または external.googleapis.com/prometheus の接頭辞が付いていれば、カスタム指標です。後者の指標は通常 Stackdriver Prometheus サイドカーから取得されます。詳しくは、Prometheus の使用をご覧ください。
たとえば、ストアで販売されるウィジェットの数を追跡する場合、カスタム指標を使用する必要があります。詳しくは、カスタム指標の使用をご覧ください。
ラベル
指標とモニタリング対象リソースタイプの両方の定義にはラベルが含まれます。ラベルは収集するデータを分類する手段です。より詳細な分析を行うためにデータを分類するのに役立ちます。例:
- 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 Console で VM インスタンスなどのリソースを構成するときに、独自のリソース メタデータ ラベルを作成することもできます。
システム メタデータ ラベルとユーザー メタデータ ラベルは、まとめてリソース メタデータ ラベルと呼ばれます。これらのラベルは、時系列フィルタでの指標やモニタリング対象リソースタイプで定義されたラベルと同様に使用できます。フィルタリングの詳細については、モニタリング フィルタをご覧ください。
時系列: モニタリング対象リソースからのデータ
このセクションでは、モニタリング データの概要と時系列での構成について説明します。ここでは、指標モデルのコンセプト コンポーネントが具体的なアーティファクトになります。
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 プロジェクトがある場合は、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 に変更する必要があります。
この例では、Cloud Logging エージェントを実行している Compute Engine インスタンスがあることを前提としています。モニタリング対象リソースタイプは 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 を持つモニタリング対象リソースタイプがあるとします。zone と color の値の組み合わせごとに時系列を取得します。
値について、1 つのラベルが取り得る数は次のとおりです。
- 「東」と「西」の 2 つのゾーンしかない場合、
zoneラベルには最大 2 つの異なる値を指定できます。 - 「赤」、「緑」、「青」の 3 つの色しか使用できない場合、
colorラベルには最大 3 つの異なる値を指定できます。
この指標のカーディナリティは 6 (3×2) ですが、この指標では時系列の数が少ない可能性があります。たとえば、「west」ゾーンからデータを取得しない場合、3 つを超える時系列を取得することはありません。
指標のカーディナリティは、グラフやその他の用途において指標をリクエストする際のパフォーマンスに関する重要な要素です。カーディナリティが高い場合は、クエリの応答時間が長くなる可能性があります。
カーディナリティは、カスタム指標を設計する際にも重要です。ラベルのセットと使用可能な値を決定します。指標タイプで使用できるラベルの数は 30 個までに制限されていますが、ラベルに指定できる値のセットよりも制限があることを確認する必要があります。少数の個別の値（「red」、「green」、「blue」など）が推奨されるアプローチです。タイムスタンプなどのきめ細かい値は使用しないでください。カスタム指標には他にも上限があります。詳細については、カスタム指標をご覧ください。