Google Cloud Observability の料金

Google Cloud Observability の料金体系では、お客様が使用量と費用を管理できるようになっています。Google Cloud Observability プロダクトの料金は、データ量または使用量によって決まります。無料のデータ使用量枠を利用できるので、契約や初期費用なしで使用を開始できます。

以下の各表は、Cloud Logging、Cloud Monitoring、Cloud Trace の料金情報をまとめたものです。

Cloud Logging の料金概要

Cloud Monitoring の料金概要

Cloud Trace の料金概要

Google Cloud Observability プロダクトの費用の詳細については、このページの以下のセクションをご覧ください。

• Cloud Logging
• Cloud Monitoring
• Error Reporting
• Cloud Profiler
• Cloud Trace

GKE Enterprise の料金については GKE Enterprise をご覧ください。

使用状況の確認

現在の使用状況を確認するには、Google Cloud コンソールの [Cloud Billing レポート] ページに移動します。

Cloud Billingに移動

料金計算ツールを使用すると、現在の使用状況データに基づく請求額を見積もることができます。

たとえば、すべての Compute Engine VM インスタンスが、1 か月あたり 10 GiB の課金対象のログと 20 MiB の課金対象の指標を生成する場合の料金構成を考えてみましょう。 料金計算ツールを使用することで、Cloud Monitoring と Cloud Logging の推定費用を確認できます。

請求アラートの構成

請求額または予測料金が予算を超えた場合に通知を受け取るには、Google Cloud コンソールの [予算とアラート] ページでアラートを作成します。

1. Google Cloud コンソールで、[お支払い] ページに移動します。

   [お支払い] に移動

   このページは、検索バーを使用して見つけることもできます。

   複数の Cloud 請求先アカウントがある場合は、次のいずれかを行います。

   • 現在のプロジェクト�� Cloud Billing ���管理するには、[リンクされた請求先アカウントに移動] を選択します。
   • 別の Cloud 請求先アカウントを確認するには、[請求先アカウントを管理] を選択し、予算を設定する対象のアカウントを選択します。
2. [お支払い] ナビゲーション メニューから [予算とアラート] を選択します。
3. [予算を作成] add_box をクリックします。
4. 予算ダイアログに入力します。このダイアログでは、Google Cloud のプロジェクトとサービスを選択し、その組み合わせに対する予算を作成します。デフォルトでは、予算の 50%、90%、100% に達すると通知が送られます。詳細については、予算と予算アラートの設定をご覧ください。

Cloud Logging

ログバケットとは、ログデータを保存する Logging コンテナのことです。Logging の料金は、_Default ログバケットとユーザー定義のログバケットに保存されているログデータ量に対して適用されます。Vended Network Logs 以外のストレージでは、データ量が毎月の無料割り当て量を超えた場合に、料金が適用されるようになります。Vended Network Logs には常に料金が適用されます。

_Default ログバケットとユーザー定義のログバケットについては、ログがデフォルトの保持期間（30 日間）を超えて保持された場合も Logging の料金が適用されます。

Logging によるログ ルーティング、Cloud Logging API の使用、およびログスコープの構成には、追加料金は発生しません。また、保持期間が 400 日間に固定された _Required ログバケットに保存されているログに対しても追加料金は発生しません。

このセクションでは、次のトピックに関する情報を提供します。

• Cloud Logging ストレージ モデル
• ストレージの料金
• 保持料金
• Vended Network Logs
• ログストレージの削減
• ログベースの指標の料金
• 取り込まれたログバイト数の月間合計に対するアラート ポリシーの作成

料金情報の概要については、Cloud Logging の料金情報をご覧ください。

Logging の使用に適用されるデータ保持期間などの上限については、割り当てと上限をご覧ください。

Cloud Logging の使用状況データを確認して理解するには、請求の見積もりをご覧ください。

Cloud Logging ストレージ モデル

Google Cloud プロジェクトごとに、Logging によって自動的に _Required と _Default の 2 つのログバケットが作成されます。Logging は、これら 2 つのログバケットのそれぞれにログをルーティングする _Required および _Default という名前のログシンクを自動的に作成します。_Required シンクを無効にしたり変更したりすることはできません。_Default シンクについては、_Default バケットがログを取り込めないように無効にするか、変更することができます。

ユーザー定義のログバケットは、どの Google Cloud プロジェクトにでも作成できます。また、Google Cloud 組織内の Google Cloud プロジェクト全体で、任意の組み合わせでログをルーティングするようにシンクを構成することもできます。

_Default ログバケットとユーザー定義のログバケットには、カスタムの保持期間を構成することができます。

ログバケットをアップグレードすると、ログ分析を使用できるようになります。ログ分析を使用するためにログバケットをアップグレードしても料金はかかりません。

Cloud Logging のバケットとシンクについて詳しくは、転送とストレージの概要をご覧ください。

ストレージの料金

_Required バケットに保存されているログに対して、Logging の料金は発生しません。_Required バケットを削除したり、_Required シンクを変更したりすることはできません。_Required バケットには次のログが保存されます。

• 管理アクティビティ監査ログ
• システム イベント監査ログ
• Google Workspace 管理者監査ログ
• Enterprise グループ監査ログ
• ログイン監査ログ
• アクセスの透明性ログアクセスの透明性ログを有効にする方法については、アクセスの透明性ログのドキュメントをご覧ください。

_Default ログバケットおよびユーザー定義のログバケットに保存されているログデータの合計量が毎月の無料割り当て量を超えると、これらのログバケット内の事前インデックス登録されたログデータに対して Logging の料金が適用されます。_Default ログバケットまたはユーザー定義のログバケットへのログエントリの書き込みはすべて、ストレージ割り当て量に計上されます。たとえば、シンクから 3 つのログバケットにログエントリがルーティングされる場合、そのログエントリは 3 回保存されます。

保持料金

次の表に、ログバケットに保存されたログデータの保持期間を記載します。

デフォルトの保持期間を超えてログが保持された場合は、Logging の保持料金が適用されます。_Required ログバケットの保持期間を構成することはできません。ログバケットのデフォルトの保持期間内でログが保持される場合、保持費用はかかりません。

ログバケットの保持期間を短縮した場合、7 日間の猶予期間が適用されます。この期間中は、短縮された保持期間を超過しているログでも削除されることはありませんが、期限切れのログに対してクエリを実行することや表示することはできません。ただし、この 7 日間はログバケットの保持期間を延長することで完全なアクセス権を復元できます。猶予期間中に保存されたログは、保持費用に計上されます。

ログエントリを複数のログバケットにルーティングする場合、ストレージの料金と保持料金が複数回請求���れる可能性があります。たとえば、ログエントリを _Default ログバケットとユーザー定義のログバケットにルーティングするとします。また、両方のバケットには 30 日を超えるカスタムの保持期間が構成されているとします。この構成では、2 件のストレージの料金と 2 件の保持料金が請求されることになります。

Vended Network Logs

Vended Network Logs を利用できるのは、ログ生成を構成している場合のみです。Vended Network Logs を生成するサービスでは、ログ生成に対して料金が請求されます。これらのログをログバケットに保存する場合や、別のサポート対象の宛先にルーティングする場合は、Cloud Logging または宛先での料金も適用されます。ログ生成の費用については、ネットワーク テレメトリーの料金をご覧ください。

Vended Network Logs を有効にする方法については、VPC Flow Logs を構成する、ファイアウォール ルール ロギングを使用する、Cloud NAT: ログと指標をご覧ください。

Vended Network Logs を確認するには、ログ エクスプローラで次のログ名を基準にフィルタします。

• projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
• projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
• projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
• projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

ログストレージの削減

Cloud Logging のストレージ費用を削減するには、ログシンクに除外フィルタを構成し、特定のログをルーティング対象から除外します。除外フィルタでは、フィルタに一致するログエントリをすべて除外することも、一致するログの特定の割合だけを除外することもできます。ログエントリがシンクの除外フィルタに一致すると、そのログエントリはシンクからその宛先にルーティングされません。除外されたログエントリはストレージの割り当て量を消費しません。除外フィルタを設定する手順については、ログの除外をご覧ください。

Cloud Logging のストレージ費用を削減するには、Cloud Logging からサポート対象の宛先にログをルーティングするという方法もあります。Cloud Logging でサポート対象の宛先にログをルーティングしても、料金は発生しません。ただし、宛先でログを受��すると、その宛先での料金が請求される場合があります。

• Cloud Storage の料金
• BigQuery の料金
• Pub/Sub の料金

Cloud Logging からログをルーティングする方法については、サポートされている宛先にログをルーティングするをご覧ください。

ログベースの指標の料金

システム定義のログベースの指標は、すべての Google Cloud プロジェクトに提供されるものであり、課金対象外です。

���ーザー定義のログ��ースの指標は、Cloud Monitoring のカスタム指標のクラスであり、課金対象となります。料金の詳細については、課金対象の指標をご覧ください。

詳しくは、ログベースの指標の概要をご覧ください。

取り込まれたログバイト数の月間合計に対するアラート ポリシーの作成

ログバケットに書き込まれたログバイト数が Cloud Logging のユーザー定義の上限を超えたときにトリガーされるアラート ポリシーを作成するには、次の設定を使用します。

Cloud Monitoring

Monitoring での課金対象は次のとおりです。

• 取り込まれたバイト数で測定される指標（指標の取り込み量が毎月の無料の割り当て量を超過した場合）。

  課金対象外の指標は、割り当て上限の対象には含まれません。

• 取り込まれたサンプル数で測定された指標。

• 毎月の無料 API 割り当てを超えた Cloud Monitoring API 読み取り呼び出し。

  Monitoring API の書き込み呼び出しには、割り当て上限が適用されません。

• 稼働時間チェックの実行。

• 合成モニターの実行。

• 1 か月あたりのアクティブな条件の数で測定されるアラート ポリシー条件。

• アラート ポリシー条件のクエリによって返される時系列。

Monitoring における取り込みとは、Monitoring に時系列データを書き込むプロセスのことです。各時系列には、いくつかのデータポイントが含まれており、そうしたデータポイントが取り込み料金の基礎になります。料金については、Cloud Monitoring の料金をご覧ください。

このセクションでは、次の情報を提供します。

• 課金対象と課金対象外の指標の定義。
• バイト単位とサンプルベースの取り込み方法についての説明。
• 取り込まれたバイト数で課金される指標の料金の例。
• 取り込まれたサンプル数で課金される指標の料金の例。
• 稼働時間チェックの実行に対する料金の例（発効日: 2022 年 10 月 1 日）。
• 合成モニターの実行に対する料金の例（発効日: 2023 年 11 月 1 日）。
• アラートの料金の説明と例（発効日: 2026 年 4 月）。

最新の料金情報については、Cloud Monitoring の料金をご覧ください。

Monitoring の使用に適用される上限については、割り当てと上限をご覧ください。

現在の使用状況を確認するには、次のいずれかの操作を行います。

• Google Cloud コンソールで、[お支払い] ページに移動します。

  [お支払い] に移動

  このページは、検索バーを使用して見つけることもできます。

• Google Cloud コンソールで、[settings設定] ページに移動します。

  [設定] に移動

  検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] となっている結果を選択します。

現在の使用状況データに基づき、請求額を見積もることができます。

課金対象外の指標

Google Cloud、GKE Enterprise、Knative から取得した指標データは課金対象外です。課金対象外（無料）の指標には、以下のものが含まれます。

• Google Cloud の指標。詳細については、脚注 2 をご覧ください。
• GKE Enterprise の指標。詳細については、脚注 2 をご覧ください。
• Istio の指標
• Knative の指標
• Google Kubernetes Engine システム指標
• agent.googleapis.com/agent/ 指標

課金対象の指標

課金対象外の指標セクションに記載された指標を除くすべての指標データは、課金対象です。ほとんどの指標の取り込みでは、バイト数で課金されますが、サンプル数で課金されるものもあります。こうした料金モデルについては、以降のセクションで説明します。

取り込みの費用に影響する要因は次のとおりです。

• 指標によって収集されるデータポイント（スカラー値または分布値）の型。

  • 特定の指標タイプに関連付けられたデータ型の詳細については、指標の一覧をご覧ください。
  • スカラーデータ型と分布データ型の詳細については、値の型をご覧ください。

• 時系列に書き込まれるデータポイントの数。この値は、データをサンプリングする頻度とデータのカーディナリティによって異なります。カーディナリティによって、指標とモニタリング対象リソースタイプの組み合わせに対して生成される時系列の数が決まります。詳細については、カーディナリティをご覧ください。

時系列を構成する指標とリソースラベルの値は課金に影響しません。

取り込まれたバイト数で課金される指標

次の指標は課金対象であり、取り込まれたバイト数に応じて料金が設定されます。

• agent.googleapis.com/agent/ グループを除く agent.googleapis.com の下のエージェントの指標

  2021 年 8 月 6 日以降、agent.googleapis.com/processes/ 指標は他の課金対象の指標に対するボリューム レートの 5% で課金されます。たとえば、100 MiB のプロセス指標の取り込みには、5 MiB の他の課金対象の指標の取��込みと同じ費用が発生します³。

• Ops エージェントを使用したサードパーティの統合からの指標。これらの指標は、workload.googleapis.com/APPLICATION.METRIC 形式の識別子を使用して Cloud Monitoring に取り込まれます。たとえば、指標タイプ workload.googleapis.com/nginx.requests はこのカテゴリに分類されます。

• Ops エージェントによって Cloud Monitoring に workload.googleapis.com 指標として取り込まれる OpenTelemetry Protocol（OTLP）指標。これは構成オプションです。詳しくは、OTLP 指標の取り込み形式をご覧ください。

• カスタム指標。これには、Cloud Monitoring API または言語固有のクライアント ライブラリ（OpenCensus および OpenTelemetry）を使用して送信される指標が含まれますが、これらに限定されるものではありません。

• 外部指標

• ユーザー定義のログベースの指標

料金計算に使用される取り込み量は、次のように計算されます。

• スカラーデータ型の場合: 時系列に書き込まれるデータポイントごとに 8 バイト。ユーザー定義のログベースのカウンタ指標は、このカテゴリに分類されます。
• 分布データ型の場合: 時系列に書き込まれるデータポイントごとに 80 バイト。

時系列のデータポイントの詳細については、時系列: モニタリング対象リソースからのデータをご覧ください。

取り込まれたサンプル数に基づいて課金される指標

次の指標は課金対象であり、取り込まれたサンプル数に基づいて料金が設定されます。

• Google Cloud Managed Service for Prometheus の指標: prometheus.googleapis.com 指標。

料金計算に使用されるサンプル数は、次のように計算されます。

• スカラーデータ型の場合: 時系列に書き込まれるポイントごとに 1。
• 分布データ型の場合: 時系列に書き込まれるポイントごとに 2、ゼロ以外のカウントを持つヒストグラム バケットごとに 1。

時系列のデータポイントの詳細については、時系列: モニタリング対象リソースからのデータをご覧ください。

指標の取り込み量に関するアラート

1 か月あたりの指標の取り込み量に基づいてアラートを作成することはできません。ただし、Cloud Monitoring の費用に対してアラートを作成することは可能です。詳細については、請求アラートの構成をご覧ください。

取り込まれたバイト数に基づく料金の例

次の例では、取り込まれたバイト数で課金される指標について、指標データを収集するコストの見積もりを得る方法を示します。この例は、計算方法を説明するためのものです。包括的な見積もりには、料金計算ツールを使用してください。このツールにアクセスする場合は、Google Cloud Observability プロダクトを使用して、指標、ロギング、トレースデータを入力してください。

基本的なシナリオ: 複数のモニタリング対象リソース（Compute Engine、Google Kubernetes Engine、App Engine など）が、複数の指標からデータを毎月書き込んでいます。

各シナリオにおける可変要素としては次のものが挙げられます。

• リソースの数
• 指標の数
• 指標が Google Cloud 指標であるかどうか
• 指標データの書き込みレート

このセクションの例では、2020 年 7 月現在の Monitoring の料金を使用しています。

共通する背景情報

次の料金の例では、取り込まれる各指標データポイントの型が double、int64、または bool という前提です。料金計算では 8 バイトとしてカウントされます。1 か月は 730 時間（365 日 ÷ 12 か月 × 24 時間）、つまり 43,800 分とします。

毎分 1 データポイントのレートで 1 か月間データを書き込む 1 つの指標の場合:

• 合計データポイント数: 43,800
• 取り込まれる総量:
  • 350,400 バイト（43,800 データポイント × 8 バイト）
  • 0.33416748 MiB（350,400 バイト ÷ 1,048,576 バイト/MiB）

毎時 1 データポイントのレートで 1 か月間データを書き込む 1 つの指標の場合:

• 合計データポイント数: 730
• 取り込まれる総量:
  • 5,840 バイト（730 データポイント × 8 バイト）
  • 0.005569458 MiB（5,840 バイト ÷ 1,048,576 バイト/MiB）

例

シナリオ 1: 1,000 個のリソースがあり、それぞれが 75 個の指標を書き込んでいます。これらは Google Cloud 指標のみで、1 分あたり 1 データポイントのレートで書き込んでいます。

• 1 か月の取り込み量: 25,063 MiB = 0.33416748 MiB（指標 1 つ分）× 75,000（1,000 リソース × 75 指標）
• 1 か月のおよその費用: $0.00（無料分の Google Cloud 指標）

シナリオ 2: 1,000 個のリソースがあり、それぞれが 75 個のカスタム指標を書き込んでいます。これらは課金対象の指標で、毎分 1 データポイントのレートで書き込んでいます。

• 1 か月の取り込み量: 25,063 MiB（上に同じ）
• 1 か月のおよその費用: $6,427.55

シナリオ 3: 1,000 個のリソースがあり、それぞれが 75 個のカスタム指標を書き込んでいます。 これらは課金対象の指標で、毎時 1 データポイントのレートで書き込んでいます。

• 1 か月の取り込み量: 418 MiB = 0.005569458 MiB（指標 1 つ分）× 75,000
• 1 か月のおよその費用: $69.14

シナリオ 4: 1 つのリソースが 500,000 個の指標を書き込んでいます。これらは課金対象の指標で、それぞれ毎分 1 データポイントのレートで書き込んでいます。

• 1 か月の取り込み量: 167,084 MiB = 0.33416748 MiB（指標 1 つ分）× 500,000
• 1 か月のおよその費用: $35,890.98

管理と予測が可能な料金

Managed Service for Prometheus の料金は、管理できるように設計されています。サンプル単位で課金されるため、次の手段を使用して費用を管理できます。

• サンプリング期間: 指標スクレイピング期間を 15 秒から 60 秒に変更することで、カーディナリティを犠牲にすることなく 75% のコスト削減を実現できます。サンプリング期間は、ジョブ単位、ターゲット単位、または全体に対して構成できます。

• フィルタ: フィルタを使用して、サービスのグローバル データストアに送信されるサンプル数を減らすことができます。詳しくは、エクスポートされた指標のフィルタリングをご覧ください。Prometheus スクレイピング構成で指標の再ラベル付け構成ファイルを使用し、ラベル マッチャーに基づいて取り込み時に指標をドロップします。

• カーディナリティが高く価値の低いデータを、ローカルに保持します。同じスクレイピング構成を使用して、Managed Service for Prometheus とともに標準の Prometheus を実行し、サービスのグローバル データストアに送る価値がないデータをローカルに保持できます。

Managed Service for Prometheus の料金は、予測できるように設計されています。

• スパースなヒストグラムがペナルティの対象になることはありません。サンプルは、最初のゼロ以外の値に��いてのみカウントされ、以降はバケット _n 内の値がバケット _n-1 内の値よりも大きい場合にカウントされます。たとえば、値が 10 10 13 14 14 14 のヒストグラムでは、1 つ目、3 つ目、4 つ目のバケットで 3 つのサンプルとしてカウントされます。

  使用するヒストグラムの数と用途に応じて、変更されていないバケットを料金から除外すると、請求対象としてカウントされるサンプル数が、ヒストグラム バケットの絶対数が示す数よりも 20～40% 少なくなることがあります。

• サンプルごとに課金することで、HPA や GKE Autopilot によって作成されるような、迅速にスケールされたコンテナや、スケールされないプリエンプティブル（エフェメラル）コンテナに対してペナルティが科されることはありません。

  Managed Service for Prometheus が指標単位で課金される場合、新しいコンテナが起動されるたびに 1 か月分のカーディナリティの料金が発生します。サンプル単位の料金設定では、コンテナの実行中にのみ料金が発生します。

クエリ（アラートクエリを含む）

Prometheus の記録ルールが実行されているときに発行されるクエリを含め、ユーザーが発行するすべてのクエリは、Cloud Monitoring API 呼び出しにより、課金対象となります。 現在の料金については、Managed Service for Prometheus の料金または Monitoring の料金のサマリー表をご覧ください。

取り込まれたサンプル数に基づく料金の例

以降の例では、取り込まれたサンプル数に基づいて課金される指標を収集する場合の費用を見積もる方法を示します。サンプルベースの課金は、Google Cloud Managed Service for Prometheus で使用されています。

以下の例は、課金データを示すものではなく、計算手法を示すことを目的としています。

簡単なシナリオとして、各月で複数の時系列にまたがって書き込みを行うコンテナまたは Pod がいくつかあるとします。買いこまれるデータはスカラー値または分布値で構成されています。

各シナリオにおける可変要素としては次のものが挙げられます。

• コンテナまたは Pod の数。
• 時系列の数。
• データがスカラー値、分布値、またはその両方で構成されているかどうか。
• データの書き込みレート。

サンプル数のカウント

料金を見積もるには、サンプル数をカウントする方法を把握する必要があります。値としてカウントされるサンプル数は、次の要因によって異なります。

• 値はスカラーなのか分布なのか
• 値の書き込みレート

このセクションでは、毎月の請求期間で時系列に書き込まれるサンプルの数を見積もる方法について説明します。

1 か月は、約 730 時間（365 日 ÷ 12 か月 × 24 時間）、すなわち 43,800 分あるいは 2,628,000 秒とします。

時系列がスカラー値を��き込む場合は、各値が 1 つのサンプルとしてカウントされます。1 か月間に書き込まれるサンプルの数は、値が書き込まれる頻度のみによって決まります。以下の例を考えてみましょう。

• 15 秒ごとに書き込まれる値の場合:
  • 書き込みレート: 1 値/15 秒 = 1 サンプル/15 秒
  • 1 か月あ���りのサンプル数: 175,200（1 サンプル/15 秒 × 2,628,000 秒/月）
• 60 秒ごとに書き込まれる値の場合:
  • 書き込みレート: 1 値/60 秒 = 1 サンプル/60 秒
  • 1 か月あたりのサンプル数: 43,800 （1 サンプル/60 秒* 2,628,000 秒/月）

時系列が分布値を書き込む場合、各値には 2 + n サンプルを含めることができます。ここで、n はヒストグラムのバケットの数です。1 か月に書き込まれるサンプルの数は、ヒストグラムのバケット数と、値が書き込まれる頻度によって決まります。

たとえば、50 バケットのヒストグラムの各インスタンスには 52 個のサンプルを含めることができます。値が 60 秒ごとに 1 回書き込まれる場合、50 バケットのヒストグラムでは、1 か月あたり最大 2,277,600 個のサンプルが書き込まれます。100 バケットのヒストグラムで値が 60 秒ごとに 1 回書き込まれる場合、各ヒストグラムには 102 個のサンプルが含まれ、1 か月あたり最大 4,467,600 個のサンプルが書き込まれます。

ほとんどの分布時系列には、最大数に満たないサンプルが含まれます。実際には、20%～40% のヒストグラム バケットが空になります。ユーザーが Istio などによって生成されたスパースなヒストグラムを使用している場合は、この割合がさらに高くなります。

サンプル数をカウントして料金を設定する際は、空でない値を持つバケットのみが対象となります。ヒストグラムあたりのサンプルの最大数は 2 + n です。バケットの 25% が空の場合、想定されるサンプル数は 1 ヒストグラムあたり 2 + .75n です。バケットの 40% が空の場合、想定されるサンプル数は 1 ヒストグラムあたり 2 + .60n です。

次の計算とサマリー表で、サンプルの最大数と、より現実的に想定されるサンプル数を示します。

• 15 秒ごとに 50 バケットのヒストグラム値が書き込まれる場合:

  • 書き込みレート: 1 値/15 秒
  • 最大サンプル数:
    • ヒストグラムあたり: 52
    • 1 か月あたり: 9,110,400（52 × 1 値/15 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（25% が空の場合）
    • ヒストグラムあたり: 39.5（2 + 0.75（50））、すなわち 2 +（50 - 12.5）
    • 1 か月あたり: 6,920,400（39.5 × 1 値/15 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（40% が空の場合）
    • ヒストグラムあたり: 32（2 + 0.6（50）、すなわち 2 +（50 - 20））
    • 1 か月あたり: 5,606,400（32 × 1 値/15 秒 × 2,628,000 秒/月）

• 60 秒ごとに 50 バケットのヒストグラム値が書き込まれる場合:

  • 書き込みレート: 1 値/60 秒
  • 最大サンプル数:
    • ヒストグラムあたり: 52
    • 1 か月あたり: 2,277,600（52 × 1 値/60 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（25% が空の場合）
    • ヒストグラムあたり: 39.5（2 + 0.75（50））、すなわち 2 +（50 - 12.5）
    • 1 か月あたり: 1,730,100（39.5 × 1 値/60 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（40% が空の場合）
    • ヒストグラムあたり: 32（2 + 0.6（50）、すなわち 2 +（50 - 20））
    • 1 か月あたり: 1,401,600（32 × 1 値/60 秒 × 2,628,000 秒/月）

• 15 秒ごとに 100 バケットのヒストグラム値が書き込まれる場合:

  • 書き込みレート: 1 値/15 秒
  • 最大サンプル数:
    • ヒストグラムあたり: 102
    • 1 か月あたり: 17,870,400（102 × 1 値/15 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（25% が空の場合）
    • ヒストグラムあたり: 77（2 + 0.75（100）、すなわち 2 +（100 - 25））
    • 1 か月あたり: 13,490,400（77 × 1 値/15 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（40% が空の場合）
    • ヒストグラムあたり: 62（2 + .6（100）、すなわち 2 +（100 - 40））
    • 1 か月あたり: 10,862,400（62 × 1 値/15 秒 × 2,628,000 秒/月）

• 60 秒ごとに 100 バケットのヒストグラム値が書き込まれる場合:

  • 書き込みレート: 1 値/60 秒
  • 最大サンプル数:
    • ヒストグラムあたり: 102
    • 1 か月あたり: 4,467,600（102 × 1 値/60 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（25% が空の場合）
    • ヒストグラムあたり: 77（2 + 0.75（100）、すなわち 2 +（100 - 25））
    • 1 か月あたり: 3,372,600（77 × 1 値/60 秒 × 2,628,000 秒/月）
  • 想定されるサンプル数（40% が空の場合）
    • ヒストグラムあたり: 62（2 + .6（100）、すなわち 2 +（100 - 40））
    • 1 か月あたり: 2,715,600 （62 × 1 値/60 秒 × 2,628,000 秒/月）

次の表は、上記の情報をまとめたものです。

例

料金を見積もるには、1 か月の間に書き込まれたサンプル数をカウントして、価格設定の値を適用します。サンプルには、次のように段階的な範囲に応じて 100 万単位で料金が設定されます。

このセクションの残りの部分では、考えられるシナリオについて説明します。

シナリオ 1: 100 個のコンテナがあり、それぞれが 1,000 個のスカラー時系列を書き込みます。

パターン A: 各時系列が 15 秒ごとに書き込まれる場合（1 サンプル/15 秒）、1 か月に書き込まれるサンプル数は 17,520,000,000 個（175,200 サンプル/月 × 1,000 時系列 × 100 コンテナ）、すなわち 17,520 百万個となります。

パターン B: 各時系列が 60 秒ごとに書き込まれる場合（1 サンプル/60 秒）、1 か月に書き込まれるサンプル数は 4,380,000,000 個（43,800 サンプル/月 × 1,000 時系列 × 100 コンテナ）、すなわち 4,380 百万個となります。

どちらの場合も、50,000 百万サンプル未満のため、1 段目の料金のみが適用されます。他の料金で課金されるサンプルはありません。

シナリオ 2: 1,000 個のコンテナがあり、それぞれが 1,000 個のスカラー時系列を書き込みます。

パターン A: 各時系列が 15 秒ごとに書き込まれる場合（1 サンプル/15 秒）、1 か月あたりの書き込みサンプル数は 175,200,000,000 個（175,200 百万個）となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 残りの 125,200 百万個のサンプルは、2 段目の料金で課金されます。
• 他の料金で課金されるサンプルはありません。

パターン B: 各時系列が 60 秒ごとに書き込まれる場合（1 サンプル/60 秒）、1 か月に書き込まれるサンプル数は、43,800,000,000 個（43,800 百万個）となります。この月間の値は 50,000 百万サンプル未満のため、1 段目の料金のみが適用されます。

シナリオ 3: 100 個のコンテナがあり、それぞれが 1,000 個の 100 バケット分布の時系列を書き込みます。バケットの 25% は、空になることが予想されます。

パターン A: 各時系列が 15 秒ごとに書き込まれる場合（1 サンプル/15 秒）、1 か月に書き込まれるサンプル数は 1,349,040,000,000 個（13,490,400 サンプル/月 × 1,000 時系列 × 100 コンテナ）、すなわち 1,349,040 百万個となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 次の 200,000 百万個のサンプルは、2 段目の料金で課金されます。
• その月の 250,000 百万個のサンプルは、3 段目の料金で課金されます。
• 残りの 749,040 百万個のサンプルは、4 段目の料金で課金されます。

パターン B: 各時系列が 60 秒ごとに書き込まれる場合（1 サンプル/60 秒）、1 か月に書き込まれるサンプル数は 337,260,000,000 個（3,372,600 サンプル/月 × 1,000 時系列 × 100 コンテナ）、すなわち 337,260 百万個となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 次の 200,000 百万個のサンプルは、2 段目の料金で課金されます。
• 残りの 87,260 百万個のサンプルは、3 段目の料金で課金されます。

シナリオ 4: 1,000 個のコンテナがあり、それぞれが 10,000 個の 100 バケット分布の時系列を書き込みます。バケットの 40% は、空になることが予想されます。

パターン A: 各時系列が 15 秒ごとに書き込まれる場合（1 サンプル/15 秒）、1 か月に書き込まれるサンプル数は 108,624,000,000,000 個（10,862,400 サンプル/月 × 10,000 時系列 × 1,000 コンテナ）、すなわち 108,624,000 百万個となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 次の 200,000 百万個のサンプルは、2 段目の料金で課金されます。
• その月の 250,000 百万個のサンプルは、3 段目の料金で課金されます。
• 残りの 108,124,000 百万個のサンプルは、4 段目の料金で課金されます。

パターン B: 各時系列が 60 秒ごとに書き込まれる場合（1 サンプル/60 秒）、1 か月に書き込まれるサンプル数は 27,156,000,000,000 個（2,715,600 サンプル/月 × 10,000 時系列 × 1,000 コンテナ）、すなわち 27,156,000 百万個となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 次の 200,000 百万個のサンプルは、2 段目の料金で課金されます。
• その月の 250,000 百万個のサンプルは、3 段目の料金で課金されます。
• 残りの 26,656,000 百万個のサンプルは、4 段目の料金で課金されます。

シナリオ 5: 以下があるとします。

• 1,000 個のコンテナがあり、それぞれが 15 秒ごとに 1,000 個のスカラー時系列を書き込みます。1 か月あたりの書き込みサンプル数は、175,200,000,000 個（175,200 百万個）となります。（シナリオ 2、パターン A）

• 1,000 個のコンテナがあり、それぞれが 15 秒ごとに 10,000 個の 100 バケット分布の時系列を書き込みます。バケットの 40% は、空になることが予想されます。1 か月あたりの書き込みサンプル数は、108,624,000,000,000 個（108,624,000 百万個）となります。（シナリオ 4、パターン A）

1 か月あたりのサンプル合計数は、108,799,200 百万個（175,200 百万 + 108,624,000 百万個）となります。

• 最初の 50,000 百万個のサンプルは、1 段目の料金で課金されます。
• 次の 200,000 百万個のサンプルは、2 段目の料金で課金されます。
• その月の 250,000 百万個のサンプルは、3 段目の料金で課金されます。
• 残りの 108,299,200 百万個のサンプルは、4 段目の料金で課金されます。

稼働時間チェックの実行に対する料金（発効日: 2022 年 10 月 1 日）

Monitoring では、毎月の無料割り当て量である 100 万回の実行を超える、稼働時間チェックのリージョン実行ごとに料金が発生します。3 つのリージョンで実行されるチェックは、3 回の実行としてカウントされます。

稼働時間チェックの実行費用は、$0.30/1,000 回の実行です。この料金は、請求書に「Monitoring 稼働時間チェック」の SKU「CA14-D3DE-E67F」として記載されます。

以下の例は、稼働時間チェックの実行費用の見積もり方を示しています。以下の例は、課金データを示すものではなく、計算手法を示すことを目的としています。

稼働時間チェックの実行回数のカウント

稼働時間チェックの費用を見積もるには、1 か月に行われたリージョン実行の回数を把握する必要があります。Monitoring では、毎月の無料割り当て量である 100 万回の実行を超える 1,000 回の実行ごとに $0.30 の料金を請求します。

稼働時間チェックの費用を見積もるには、次の計算を使用できます。

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

稼働時間チェックごとの実行回数は、次の構成オプションによって異なります。

• 稼働時間チェックの実行頻度（間隔）: 1 分、5 分、10 分、または 15 分。

• 稼働時間チェックを実行するリージョンの数。

• 稼働時間チェックの対象として構成されているターゲットの数。稼働時間チェックが単一の VM を対象に構成されている場合、ターゲットの数は 1 です。稼働時間チェックがリソース グループを対象に構成されている場合、ターゲットの数はグループに含まれているリソースの数です。

稼働時間チェックを構成するとき、稼働時間チェックのロケーションを指定します。各ロケーションは 1 つ以上のリージョンにマッピングされています。以下の表に、稼働時間チェックの有効なロケーションと、そのロケーションがマッピングされているリージョンを記載します。

少なくとも 3 つのリージョンで稼働時間チェックを実行するように構成する必要があります。

稼働時間チェックの実行回数を見積もるには、稼働時間チェックのロケーションでカバ���され��い���リージョン���数���把握する必要があります。

• ASIA_PACIFIC、EUROPE、SOUTH_AMERICA にはそれぞれ 1 つのリージョンが含まれています。
• USA には 3 つのリージョンが含まれています。
• GLOBAL には 6 つのリージョンが含まれています。

1 か月は 730 時間（365 日 ÷ 12 か月 × 24 時間）、つまり 43,800 分とします。

• USA で 1 分ごとに実行するように構成された稼働時間チェックは、3 つのリージョンで実行されます。この稼働時間チェックが 1 台の VM を対象に構成されている場合、稼働時間チェックは毎月 131,400 回（3 x 43,800）実行されます。この稼働時間チェックが 10 メンバーからなるリソース グループを対象に構成されている場合、稼働時間チェックは毎月 1,314,000 回（10 x 131,400）実行されます。

• ASIA_PACIFIC、EUROPE、USA で 1 分ごとに実行するように構成された稼働時間チェックは、5 つのリージョンで実行されます。この稼働時間チェックが単一のターゲットを対象に構成されている場合、稼働時間チェックは毎月 219,000 回実行されます。

以下の表に、異なる数のリージョンと異なる頻度で実行するように構成された単一の稼働時間チェックの 1 時間ごと、および 1 か月ごとの実行回数を記載します。

例

料金を見積もるには、1 か月あたりの合計実行回数を判断し、そこから 1,000,000 を引きます。1,000,000 回を超えた分の実行については 1,000 回ごとに $0.30 の料金が請求されるため、残りの実行回数に .0003 を掛けます。

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

シナリオ 1: ロケーション USA で 1 台の VM を 1 分間隔でチェックする稼働時間チェックが構成されています。このチェックは 3 つのリージョンで実行されます。このチェックの 1 か月あたりの実行回数は 131,400 回で、費用はかかりません。

シナリオ 2: ロケーション USA で 10 メンバーからなるリソース グループを 1 分間隔でチェックする稼働時間チェックが構成されています。このチェックは 3 つのリージョンで実行されます。このチェックの 1 か月あたりの実行回数は 10 x 131,400 回で、毎月 $94.20 の費用がかかります。このシナリオとシナリオ 1 の唯一の違いは、ターゲットの数です。

シナリオ 3: 10 件の GLOBAL 稼働時間チェックが構成されていて、それぞれ 1 台の VM を 1 分間隔でチェックします。これらのチェックは 6 つのリージョンで実行されるため、各チェックが毎月 262,800 回実行されます。1 か月あたりの合計実行回数は 2,628,000 回（10 x 262,800）となります。このシナリオでは毎月 $488.40 の費用がかかります。

シナリオ 4: ロケーション USA で 1 台の VM を 5 分間隔でチェックする 5 件の稼働時間チェックが構成されています。これらのチェックは 3 つのリージョンで実行されるため、各チェックが毎月 26,280 回実行されます。この一連のチェックの 1 か月あたりの合計実行回数は 105,120 回（4 x 26,280）となります。

1 台��� VM を 15 分間隔でチェックする 2 件の GLOBAL 稼働時間チェックも構成されています。これらのチェックは 6 つのリージョンで実行されるため、各チェックが毎月 17,520 回実行されます。この一連のチェックの 1 か月あたりの合計実行回数は 35,040 回（2 x 17,520）となります。

1 か月あたりの合計実行回数は 140,160 回（105,120 + 35,040）となります。このシナリオでは費用はかかりません。

合成モニターの実行に対する料金（発効日: 2023 年 11 月 1 日）

Cloud Monitoring では、請求先アカウントあたりの毎月の無料割り当て量である 100 回の実行を超える、合成モニターの実行ごとに料金を請求します。たとえば、3 つの合成モニターを作成し、それぞれのモニターが 5 分間隔で実行するように構成すると、1 か月あたりの合計実行回数は 26,784 回になります。

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

課金対象の実行回数を判断するには、合計実行回数から無料割り当ての回数を引き、その結果に料金を掛けます。

アラートの料金

2026 年 4 月以降、Cloud Monitoring でアラートに対する課金が開始されます。料金モデルは次のとおりです。

• アラート ポリシーの条件あたり月額 $1.50。
• 指標アラート ポリシー条件のクエリによって返される 1,000,000 時系列あたり $0.35。

このセクションでは、次の情報を提供します。

• アラートに関する用語の定義
• さまざまなアラート ポリシー構成での料金の例
• アラート ポリシーの統合または削除によるコスト削減案
• アラート ポリシーに対する課金からのオプトアウトに関する情報

定義

• 条件: アラート ポリシーの条件は、対応が必要となる、特定のリソースまたはリソース グループの状態を記述します。

  • フィルタを使用して指標しきい値クエリまたは指標の不在クエリを作成するアラート ポリシーでは、最大 6 件の条件を組み合わせることができます。
  • 次のクエリタイプのアラート ポリシーで設定できる条件は 1 つのみです。
    • Prometheus Query Language（PromQL）のクエリ
    • Monitoring Query Language（MQL）
    • ログベースのアラートで使用するログの一致

  条件あたりの月額は $1.50 です。条件に対する課金を停止するには、アラート ポリシーを削除する必要があります。ポリシーをスヌーズまたは無効化しても、課金は停止されません。

• 指標およびログベースのアラート ポリシー: ログの一致条件以外の条件タイプを使用するアラート ポリシーは、いずれも指標アラート ポリシーです。指標アラート ポリシーの条件では、時系列が返されます。実行期間ごとに、指標アラート ポリシーの条件クエリが Cloud Monitoring データストアに対して実行されます。これによって返されたクエリがしきい値と照らし合わせて評価され、アラート ポリシーを起動するかどうかが判断されます。

  ログベースのアラート ポリシーではログの一致条件を使用します。ログの一致条件によって返される時系列はありません。

• 実行期間: Cloud Monitoring が条件を実行する頻度（間隔）。ほとんどの条件タイプでは、30 秒間隔で実行され、この頻度を変更することはできません。PromQL クエリを使用する条件では、実行期間を設定できます。詳細については、実行期間の長さを延長する（PromQL のみ）をご覧ください。

• 返された時系列: 各実行期間中に、指標アラート ポリシーの条件クエリが Cloud Monitoring データストアに対して実行されます。Cloud Monitoring は、各クエリのレスポンスとして時系列データを返します。レスポンスに含まれる各時系列が、返された時系列 1 つとしてカウントされます。

  1 か月あたりに返される時系列の数は、次の要素によって決まります。

  • 基礎となるデータの形状とスコープ。
  • 条件のクエリで使用するフィルタと集計。
  • 実行期間。

  たとえば、以下の設定からなる構成があるとします。

  • 100 台の仮想マシン（VM）。各 VM は 1 つのサービスに属しています。
  • 各 VM が 1 つの指標 metric_name を出力します。この指標のラベルには 10 個の値が含まれます。
  • 合計で 5 つのサービス。

  100 台の VM が設定されていて、それぞれが 10 個（ラベル値につき 1 つ）の時系列を生成できるので、基礎となる時系列は合計で 1,000 個となります。VM ごとにメタデータのようなラベルも含まれています。このラベルには、5 つのサービスのうち、その VM が属するサービスが記録されます。

  PromQL を使用して、次のようにアラート ポリシーを構成できます。これらの構成のそれぞれで、実行期間ごとに返される時系列の数は異なります。

  構成	PromQL クエリ	期間ごとに返される時系列の数
  集計なし	rate(metric_name[1m])	1,000
  VM ごとに集計	sum by (vm) (rate(metric_name[1m]))	100
  ラベル値ごとに集計	sum by (label_key) (rate(metric_name[1m]))	10
  サービスごとに集計	sum by (service) (rate(metric_name[1m]))	5
  ラベル値およびサービスごとに集計	sum by (service, label_key) (rate(metric_name[1m]))	50
  フリートごとに集計	sum (rate(metric_name[1m]))	1
  1 つの VM にフィルタして集計	sum (rate(metric_name{vm="my_vm_name"}[1m]))	1
  1 つのサービスにフィルタして集計	sum (rate(metric_name{service="my_service_name"}[1m]))	1

料金の例

以下の例は 30 日の月で行われるため、次の評価期間が適用されます。

• 1 か月あたり 86,400 回の 30 秒間の実行期間
• 1 か月あたり 172,800 回の 15 秒間の実行期間（PromQL クエリのみ）

例 1: 1 件のポリシーで VM ごとに集計（実行期間 30 秒）

この例では次の構成を使用します。

データ

• 100 VM
• 各 VM が 1 つの指標 metric_name を出力します。
• metric_name には 10 個の値が含まれる 1 つのラベルがあります。

• 1 つのアラート条件
• VM レベルでの条件の集計
• 30 秒間の実行期間

• 条件費用: 1 条件 x 月額 $1.50 = 1 か月あたり $1.50
• 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 860 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
• 合計費用: 1 か月あたり $4.52

例 2: 100 件のポリシー（VM ごとに 1 件）で VM ごとに集計（実行期間 30 秒）

この例では次の構成を使用します。

データ

• 100 VM
• 各 VM が 1 つの指標 metric_name を出力します。
• metric_name には 10 個の値が含まれる 1 つのラベルがあります。

• 100 件の条件
• 各条件がフィルタされ、1 つの VM に集計されます。
• 30 秒間の実行期間

• 条件費用: 100 条件 x 月額 $1.50 = 1 か月あたり $150
• 時系列費用: 100 の条件 * 実行期間ごとに返される 1 条件あたりの時系列 1 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 860 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
• 合計費用: 1 か月あたり $153.02

例 3: 1 件のポリシーで VM ごとに集計（実行期間 15 秒）

この例では次の構成を使用します。

データ

• 100 VM
• 各 VM が 1 つの指標 metric_name を出力します。
• metric_name には 10 個の値が含まれる 1 つのラベルがあります。

• 1 件の PromQL アラート条件
• VM レベルでの条件の集計
• 15 秒間の実行期間

• 条件費用: 1 条件 x 月額 $1.50 = 1 か月あたり $1.50
• 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 172,800 回の実行期間 = 1 か月あたりに返される時系列 1,730 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $6.05
• 合計費用: 1 か月あたり $7.55

例 4: 1 件のポリシーでサービスごとに集計（実行時間 30 秒）

この例では次の構成を使用します。

データ

• 100 台の VM。各 VM は 1 つのサービスに属します
• 合計で 5 つのサービス
• 各 VM が 1 つの指標 metric_name を出力します。
• metric_name には 10 個の値が含まれる 1 つのラベルがあります。

• 1 件の条件
• サービスレベルでの条件の集計
• 30 秒間の実行期間

• 条件費用: 1 条件 x 月額 $1.50 = 1 か月あたり $1.50
• 時系列費用: 実行期間ごとに返される時系列 5 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 432,000 件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $0.14
• 合計費用: 1 か月あたり $1.64

例 5: 1 件のポリシーで VM ごとに集計、VM あたりの基になるカーディナリティが高（実行期間 30 秒）

この例では次の構成を使用します。

データ

• 100 VM
• 各 VM が 1 つの指標 metric_name を出力します。
• metric_name には 100 個のラベルがあり、それぞれに 1,000 個の値があります

• 1 件の条件
• VM レベルでの条件の集計
• 30 秒間の実行期間

• 条件費用: 1 条件 x 月額 $1.50 = 1 か月あたり $1.50
• 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 850 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
• 合計費用: 1 か月あたり $4.52

例 6: 1 件のポリシーで VM ごとに集計、2 つの指標の和集合を含む 1 件の条件（実行期間 30 秒）

この例では次の構成を使用します。

データ

• 100 VM
• 各 VM が 2 つの指標 metric_name_1 および metric_name_2 を出力します。
• どちらの指標にも、10 個の値を含む 1 つのラベルがあります。

• 1 件の条件
• VM レベルでの条件の集計
• 条件では指標の和集合に対して OR 演算子を使用します。
• 30 秒間の実行期間

• 条件費用: 1 条件 x 月額 $1.50 = 1 か月あたり $1.50
• 時系列費用: 2 件の指標 x 実行期間ごとに返される時系列 100 件 x 1 か月あたり 86400 回の実行期間 = 1 か月あたりに返される時系列 1,730 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $6.05
• 合計費用: 1 か月あたり $7.55

例 7: 100 件のログベースのアラート ポリシー

この例では次の構成を使用します。

アラート ポリシー

• 100 件の条件（1 件のログベースのアラート ポリシーごとに 1 件の条件）

• 条件費用: 100 条件 x 月額 $1.50 = 1 か月あたり $150.00
• 時系列費用: $0 （ログベースのアラート ポリシーでは時系列は返されません）。
• 合計費用: 1 か月あたり $150.00

アラートの課金を削減するための提案

アラート ポリシーを統合して、より多くのリソースに対して動作するようにする

条件ごとに $1.50 の費用がかかるため、1 つのアラート ポリシーを使用して各リソースをモニタリングするよりも、1 つのアラート ポリシーを使用して複数のリソースをモニタリングする方が費用対効果に優れた方法になります。たとえば、例 1 と例 2 を比べると、どちらの例でも同じ数のリソースをモニタリングしています。ただし、例 2 では 100 件のアラート ポリシーを使用していますが、例 1 で使用しているアラート ポリシーは 1 件だけです。その結果、例 1 の 1 か月あたりの料金は $150 近く低くなります。

アラートが必要なレベルのみに集計する

より高いレベルの粒度に集計すると、低い粒度に集計する場合よりもコストが高くなります。たとえば、Google Cloud プロジェクト レベルでの集計はクラスタレベルでの集計よりも費用が安く、クラスタレベルでの集計はクラスタレベルと名前空間レベルでの集計よりも費用が安くなります。

たとえば、例 1 と例 4 を比較すると、どちらの例も、同じ基になるデータに対して動作し、使用しているアラート ポリシーも 1 件のみです。ただし、例 4 のアラート ポリシーはサービスごとに集計されるため、VM ごとに詳細に集計される例 1 のアラート ポリシーほど費用がかかりません。

また、例 1 と例 5 を比較すると、例 5 の指標のカーディナリティは例 1 の指標のカーディナリティの 10,000 倍です。ただし、例 1 と例 5 のアラート ポリシーは両方とも VM ごとに集計され、どちらの例でも VM の数が同じであることから、料金は同じです。

アラート ポリシーを構成する場合は、ユースケースに最適な集計レベルを選択します。たとえば、CPU 使用率に関するアラートを重視する場合は、VM と CPU のレベルで集計できます。エンドポイントごとのレイテンシに関するアラートを重視する場合は、エンドポイント レベルで集計できます。

未集計の元データに関するアラートを発生させない

Monitoring はディメンション指標システムを使用します。このシステムでは、指標の合計カーディナリティは、モニタリング対象リソースの数にその指標のラベルの組み合わせを掛けた数と等しくなります。たとえば、指標を出力する VM が 100 台あり、その指標にそれぞれ 10 個の値を持つ 10 個のラベルがある場合、合計カーディナリティは 100 x 10 x 10 = 10,000 となります。

カーディナリティのスケーリングによっては、元データに対するアラートの費用が非常に高くなることがあります。上記の例では、実行期間ごとに 10,000 件の時系列が返されます。ただし、VM ごとに集計した場合、基になるデータのラベル カーディナリティとは関係なく、実行期間ごとに 100 件の時系列のみ��返されます。

また、元データに基づくアラートには、指標に新しいラベルが追加されると時系列が増加するというリスクもあります。上記の例では、ユーザーが指標に新しいラベルを追加すると、合計カーディナリティが 100 x 11 x 10 = 11,000 件の時系列にまで増加します。この場合、アラート ポリシーに変更がなくても、実行期間ごとに返される時系列の数が 1,000 増加します。代わりに VM ごとに集計すると、基になるカーディナリティは増加しても、返される時系列は 100 件のみになります。

不要なレスポンスをフィルタで除外する

アラートのニーズに必要なデータのみを評価するように条件を構成します。修正するための措置を取らない場合は、その条件をアラート ポリシーから除外します。たとえば、インターンの開発用 VM に関してアラートを出す必要はないでしょう。

不要なアラートや費用を削減するために、重要でない時系列をフィルタで除外できます。Google Cloud のメタデータ ラベルを使用すると、アセットにカテゴリでタグ付けし、不要なメタデータ カテゴリをフィルタで除外できます。

トップストリーム演算子を使用して、返される時系列の数を減らす

条件で PromQL または MQL クエリを使用する場合は、トップ ストリーム演算子を使用して、最も高い値で返される時系列の数を選択できます。

• PromQL: topk
• MQL: top

たとえば、PromQL クエリの topk(metric, 5) 句は、実行期間ごとに返される時系列の数を 5 に制限します。

時系列の数に制限を加えると、次のようなデータの欠落やアラートの不具合が発生する可能性があります。

• N 件以上の時系列がしきい値を超えた場合、上位 N 件の時系列外のデータが失われます。
• 違反する時系列が上位 N 件の時系列外で発生した場合は、除外された時系列がしきい値をまたいでもインシデントが自動的にクローズされる可能性があります。
• 条件クエリで、想定したとおりに機能しているベースライン時系列などの重要なコンテキストが示されない場合があります。

このようなリスクを軽減するには、N に大きい値を選択し、多数の時系列を評価するアラート ポリシー（個々の Kubernetes コンテナのアラートなど）でのみトップストリーム演算子を使用します。

実行期間を長くする（PromQL のみ）

条件で PromQL クエリを使用する場合、条件の evaluationInterval フィールドを設定して、実行期間の長さを変更できます。

評価間隔が長いほど、1 か月間に返される時系列は少なくなります。たとえば、15 秒間隔の条件クエリは、30 秒間隔のクエリの 2 倍の頻度で実行され、1 分間隔のクエリは、30 秒間隔のクエリの半分の頻度で実行されます。

オプトアウト

既存の Google Cloud 契約が 2026 年 4 月まで有効な場合、契約の有効期限までアラートに対する課金を免除するよう、Cloud Monitoring アラート請求担当チームに申請できます。有効な契約をお持ちのお客様に対する課金の免除は、ケースバイケースで考慮されます。

免除を申請できるのは 2024 年 11 月 1 日までです。契約更新まで課金の免除を申請するには、こちらの課金免除申請フォームにご記入ください。

Error Reporting

エラーデータを Google Cloud プロジェクトにレポートするには、Error Reporting API または Cloud Logging API を使用します。

Error Reporting の使用に対する料金は発生しません。ただし、ログエントリが生成されて Cloud Logging に保存されるため、Cloud Logging の費用が発生する可能性があります。

Error Reporting の使用に適用される上限につい���は、割り当てと上限をご覧ください。

Cloud Profiler

Cloud Profiler の使用に伴う費用はありません。

Profiler の使用に適用される上限については、割り当てと上限をご覧ください。

Cloud Trace

Trace では、取り込まれ、スキャンされたトレーススパンの数を基に課金されます。レイテンシ データが Trace に送信されると、そのデータはスパンで構成されたトレースとしてパッケージ化され、そのスパンが Cloud Trace バックエンドによって取り込まれます。トレースデータを表示すると、保存されたスパンが Cloud Trace によってスキャンされます。 このセクションでは、次の情報を提供します。

• 課金対象と課金対象外のトレーススパンを定義します。
• 料金の例を提示します。
• トレーススパンの取り込みを削減する方法について説明します。
• トレーススパンの取り込みがしきい値に達した場合に通知できるアラート ポリシーの設定について説明します。

最新の料金情報については、Cloud Trace の料金をご覧ください。

Trace の使用に適用される上限については、割り当てと上限をご覧ください。

現在または過去の使用状況を確認する方法については、請求の見積も��をご覧ください。

課金対象外のトレーススパン

Cloud Trace の料金は、App Engine スタンダード、Cloud Run functions、Cloud Run で自動生成されたスパンには適用されません。これらのトレースの取り込みは課金対象外です。

自動生成されたトレースは、Cloud Trace API の割り当てを消費せず、API 使用状況の指標でもカウントされません。

課金対象のトレーススパン

課金対象のトレース（「課金対象のトレース」のリンク先は、課金対象外のトレースです）というセクションに記載されているスパンを除くすべてのトレーススパンの取り込みは課金対象となり、取り込まれる量に応じて課金されます。 これには、App Engine スタンダード アプリケーションに追加したインストルメンテーションによって作成されたトレーススパンが該当します。

料金の例

この例では 2020 年 7 月現在の Trace の料金を使用しています。

• 1 か月で 200 万スパンを取り込む場合、費用は $0 です（月間に取り込まれる最初の 250 万スパンは無料です）。
• 1 か月で 1,400 万スパンを取り込む場合、費用は $2.30 です（月間の最初の 250 万スパンは無料です。それを超えるスパンの費用を計算すると、1,150 万スパン × $0.20/100 万スパン = $2.30 となります）。
• 1 か月で 10 億スパンを取り込む場合、費用は $199 です（月間の最初の 250 万スパンは無料です。それを超えるスパンの費用を計算すると、9 億 9,750 万スパン × $0.20/100 万スパン = $199.50 となります）。

トレース使用量の削減

トレーススパンの取り込み量を管理するには、トレースのサンプリング レートを管理して、パフォーマンス分析に必要なトレース量と許容される費用の間でバランスを取るようにします。

トラフィックの多いシステムでは、多くの場合、トランザクションの 1/1,000（場合によっては 1/10,000）をサンプリングするだけで、パフォーマンス分析を行うのに十分な情報を得られます。

サンプリング レートの構成は、Cloud Trace クライアント ライブラリを使用して行います。

取り込みスパン数の月間合計に関するアラート

取り込まれた Cloud Trace スパンの月間合計が、ユーザー定義の上限を超えたときに起動するアラート ポリシーを作成するには、次の設定を使用します。

GKE Enterprise

GKE Enterprise のシステムログと指標は無料です。コントロール プレーン ログ、コントロール プレーンの指標、Kube 状態指標のキュレートされたサブセットは、GKE Enterprise が有効なプロジェクトでクラスタ作成時に登録された Google Cloud 上の GKE クラスタに対してデフォルトで有効になっています。コントロール プレーン ログには Cloud Logging の料金が発生しますが、デフォルトで有効な指標は追加料金なしで含まれています。

��まれ��� GKE ���ログと指標の一覧については、収集されるログと使用可能な指標をご覧ください。

Google Distributed Cloud クラスタでは、GKE Enterprise のシステムログと指標には次のものが含まれます。

• 管理クラスタ内のすべてのコンポーネントのログと指標
• ユーザー クラスタ内の次の名前空間のコンポーネントのログと指標: kube-system、gke-system、gke-connect、knative-serving、istio-system、monitoring-system、config-management-system、gatekeeper-system、cnrm-system

よくある質問

無料で使用できるプロダクトの機能はありますか？

Google Cloud Observability プロダクトの使用はデータ容量に応じて課金されます。このページで説明されているデータ容量の費用を除き、Google Cloud Observability プロダクトの他の機能はすべて無料で使用できます。

料金を教えてください。

費用の見積もりについては、請求の見積もりをご覧ください。

課金についてご不明な点がございましたら、課金に関する質問をご覧ください。

使用量の詳細を把握する方法を教えてください。

Metrics Explorer を使用すると、ログや指標の数値を細かいレベルまで掘り下げて把握できます。詳細については、Metrics Explorer での詳細な使用状況の表示をご覧ください。

費用を管理する方法にご関心をお持ちの場合は、次のブログ投稿をご覧ください。

• クラウド管理者向けの Cloud Logging の料金: そのアプローチと費用を削減する方法
• Cloud Logging の費用を予算内で管理するための 4 つのステップ

指標スコープとログスコープは、課金にどのように影響しますか？

ほとんどの場合、指標スコープとログスコープは課金には影響しません。ログと指標は、データを受け取るプロジェクト、請求先アカウント、フォルダ、または組織に対して課金されます。プロジェクトの指標スコープは、プロジェクトで表示およびモニタリングできる指標があるリソースのコレクションを定義します。指標スコープを定義しても、どのリソースで指標データを受信するかに影響することはなく、データの重複を招くこともありま��ん。同様に、ログスコープは、確認する必要があるログエントリを保存またはルーティングする対象のリソースをリストするだけのものです。

たとえば、組織に 100 台の仮想マシン（VM）があるとします。そのうち 60 台の VM が Project-A でホストされ、40 台の VM が Project-B にあります。Project-A はその VM の指標を受け取って保存し、指標が課金対象の場合は課金されます。同様に、Project-B はその VM の指標を受け取って保存し、指標が課金対象の場合は課金されます。Project-A と Project-B を含む指標スコープを作成する場合、100 台の VM の指標を組み合わせて表示できます。現在、Project-A の指標のみ、Project-B の指標のみ、または組み合わせた指標を選択して表示できるようになっています。Project-A の指標を 2 通りの方法で表示できるようになりましたが、追加で課金されることはありません。

無料の割り当て量を超えるとどうなりますか？

無料割り当て量を超える使用量に対しては、自動的に課金されます。 ログや指標が失われることはありません。発生する可能性のある費用について詳しくは、請求の見積もりをご覧ください。

アラート ポリシーを作成して使用状況をモニタリングし、料金のしきい値に近づいたら通知を受け取ることができます。

プロジェクトに使用しない Google Cloud ログが大量に存在します。これらのログの使用料金が心配です。使用料金が課金されないようにする方法を教えてください。

ログを除外すると、Logging に取り込まれるログを制御できます。詳しくは、ログ使用量の削減をご覧ください。

ログが除外されている場合��プロジェクトにログを送信しているサービスはエラーを受信しますか？

いいえ。ログエントリを送信するサービスが、Logging にログエントリが取り込まれるかどうかを確認することはできません。

Virtual Private Cloud のフローログでは請求が二重に行われるのでしょうか？

VPC フローログを Logging に送信する場合、VPC フローログの生成料金は発生せず、Logging の料金のみが適用されます。ただし、VPC フローログを送信した後で、そのログを Logging から除外すると、VPC フローログに対して課金されます。詳細については、Google Cloud 料金計算ツールをご覧ください。そのうえで、「Cloud Load Balancing とネットワーク サービス」というタイトルのタブを選択してください。

¹ 料金計算では、すべての単位がバイナリ測定として扱われます。たとえば、メビバイト（MiB、または 2²⁰バイト）または、ギビバイト（GiB、または 2³⁰バイト）などです。

² 1 分あたりの測定データポイントの最大数が 1 である Google Cloud 指標または GKE Enterprise 指標は無料です。これは現時点で最も細かい測定単位ですが、将来的には、これより細かな単位で測定される指標に対して料金が発生する可能性があります。

³ 現在、プロセス指標は、事前に定義されたデフォルトのレート（1 分ごと）で収集されていますが、これを変更することはできません。通常、このデータはゆっくりと変化するため、現在これらの指標はオーバーサンプリングされています。したがって、指標を 20 分間隔でサンプリングする場合は、標準レートの 5% でプロセス指標を請求すれば標準レートと一致します。これらの指標から 100 MiB のデータを収集するユーザーについては、5 MiB のみが請求対象になります。

次のステップ

• Google Cloud Observability のドキュメントを確認する。
• 料金計算ツールを試す。
• Google Cloud Observability のソリューションとユースケースについて学習する。