Cloud Monitoring の料金

Google Cloud Observability の料金体系により、Google Cloud での使用量を 費用を最適化できますGoogle Cloud Observability プロダクトの料金は、データ量または できます。データ使用量の無料割り当てを使用して、無料で 使用料は発生しません

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

Cloud Logging の料金概要

機能	料金^1	毎月の無料割り当て量
Logging ストレージ^*	$0.50/GiB、 インデックス、クエリ、ログ分析のためにログをバケット ストレージにストリーミングするための 1 回限りの料金 分析ログバケットに最大 30 日間のストレージが含まれます。 ログデータのクエリと分析に追加料金はかかりません。	毎月プロジェクトごとに最初の 50GiB
ロギングの保持^†	30 日を超えて保持されたログについては、1 か月で GiB あたり $0.01。保持に応じて月単位で請求されます。	デフォルトの保持期間間保持されたログに保持費用は発生しません。
ログルーター^‡	追加料金なし	該当なし
ログ分析^♣	追加料金なし	該当なし

^* ストレージ ボリュームでは、インデックス登録の前にログエントリの実際のサイズがカウントされます。 Google Cloud Storage バケットに保存されるログは、 _Required ログバケット。
^† _Required ログバケットに保存されたログには保持料金は発生しません。 400 日間の固定保持期間があります
^‡ ログ ルーティングは、Cloud Logging API を介して受信したログを 表示されます。転送されたログに宛先料金が適用される場合があります。
^♣ ログ分析の使用や SQL クエリの発行のためにログバケットをアップグレードしても料金はかかりません。 [ログ分析] ページから確認できます。
注: Cloud Logging の料金の文言は 2023 年 7 月 19 日に変更されました。 無料割り当てとレートに変更はありません請求書は、古いバージョンの 説明します。

Cloud Monitoring の料金概要

機能	料金	毎月の無料割り当て量	発効日
<ph type="x-smartling-placeholder"></ph> すべての Monitoring データ Managed Service for Prometheus を使用して取り込まれたデータを除く	$0.2580/MiB^1: 最初の 150 ～ 100,000 MiB $0.1510/MiB: 次の 100,000 ～ 250,000 MiB $0.0610/MiB: 250,000 MiB 超	すべての課金対象外の Google Cloud 指標 請求先アカウントごとに最初の 150 MiB 取り込まれたバイト数で課金される指標	2018 年 7 月 1 日
を使用して取り込まれた指標 Google Cloud Managed Service for Prometheus <ph type="x-smartling-placeholder"></ph> GKE コントロール プレーンの指標	100 万サンプルあたり $0.06^†: 取り込まれた最初の 500 億サンプル^† 100 万サンプルあたり $0.048: 次に取り込まれる 5,000 ～ 2,500 億サンプル 100 万サンプルあたり $0.036: 次に取り込まれるサンプル 2,500 ～ 5,000 億件 100 万サンプルあたり $0.024: 取り込まれたサンプル 5,000 億以上	該当なし	2023 年 8 月 8 日
Monitoring の API 呼び出し	1,000 ごとに $0.01 の読み取り API 呼び出し （書き込み API 呼び出しは無料）	請求先アカウントごとの最初の 100 万回の読み取り API 呼び出し	2018 年 7 月 1 日
Monitoring 稼働時間チェックの実行	$0.30/1,000 回の実行^‡	Google Cloud プロジェクトあたり 100 万回の実行	2022 年 10 月 1 日
実行 合成モニターのモニタリング	$1.20/1,000 回の実行^*	請求先アカウントごとに 100 回の実行	2023 年 11 月 1 日
アラート ポリシー	アラート ポリシーの条件ごとに月額 $1.50 指標アラート ポリシー条件のクエリによって返される 1,000,000 時系列あたり $0.35^♣	該当なし	2025 年 1 月 7 日

^† Google Cloud Managed Service for Prometheus は 外部で作成された指標データ用の Cloud Monitoring ストレージと、 そのデータを取得します。 Managed Service for Prometheus は、指標の代わりに取り込まれたサンプルに基づいて Prometheus に合わせてバイトを学びました。サンプルベースの測定の詳細については、管理可能かつ予測可能な料金をご覧ください。計算例については、取り込まれたサンプル数に基づく料金の例をご覧ください。
^# サンプルは請求先アカウントごとにカウントされます。
^‡ 実行料金は、それが定義されている請求先アカウントに請求されます。 詳細については、次をご覧ください: <ph type="x-smartling-placeholder"></ph> 稼働時間チェック実行の料金。
^* 実行料金は、それが定義されている請求先アカウントに請求されます。 実行のたびに、他の Google Cloud サービスから追加料金が発生する可能性があります。 Cloud Functions、Cloud Storage、Cloud Logging などのサービスが含まれます。 これらの追加料金の詳細については それぞれの Google Cloud サービスの料金に関するドキュメントをご覧ください。
^♣ 詳細については、以下をご覧ください。 アラートの料金。

Cloud Trace の料金概要

機能	料金	毎月の無料割り当て量	発効日
Trace での取り込み	100 万スパンごとに $0.20	請求先アカウントごとに最初の 250 万スパン	2018 年 11 月 1 日

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

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

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

使用状況の確認

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

Cloud Billingに移動

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

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

	1 VM	10 個の VM	100 VM	1,000 VM
1 か月あたりの指標費用	$0.00	$12.90	$477.30	$5,121.30
1 か月あたりの Logging 費用	$0.00	$25.00	$475.00	$4,975.00
合計費用:	$0.00	$37.90	$952.30	$10,096.30

請求アラートの構成

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

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

   [お支払い] に移動

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

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

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

   • Cloud Logging の使用状況に関するアラートを作成するには [Cloud Logging] を選択
   • Cloud Monitoring の使用状況に関するアラートを作成するには、Stackdriver Monitoring を選択します。
   • Cloud Trace の使用状況に関するアラートを作成するには、[Stackdriver Trace] を選択します。

Cloud Logging

ログバケットは、ログデータを保存する Logging コンテナです。 Logging では、保存されているログデータの量に対して課金される _Default ログバケットとユーザー定義のログバケット そのボリュームが 毎月の無料割り当て量。 _Default ログバケットとユーザー定義のログバケットの場合、次のようになります。 Cloud Logging は、次の期間にログが デフォルトの保持期間よりも長く保持される 30 日間

Logging によるログのルーティングに追加料金はかかりません。 Cloud Logging API を使用するか、_Required ログバケットに保存されているログの場合、 400 日間の固定保持期間があります

このセクションでは、次のトピックについて説明します。

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

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

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

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

Cloud Logging ストレージ モデル

Google Cloud プロジェクトごとに、Logging が自動的に _Required と _Default の 2 つのログバケットを作成します。 この 2 つのバケットに対して、Logging は自動的にログシンクを作成します。 _Required と _Default という、対応する名前付きの 使用します。_Required シンクは無効にすることも、変更することもできません。無効にするには、 _Default バケットが実行されないように _Default シンクを変更します。 新しいログの保存場所です

Google Chat では ユーザー定義のログバケットを作成する Google Cloud プロジェクト内で 管理できますまた、VPC フローログに基づいて Google Cloud からの お客様の組織の Google Cloud プロジェクト間でも、 ログバケットにマッピングします。

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

ログバケットをアップグレードして ログ分析。 ログ分析を使用するためにログバケットをアップグレードする場合、料金はかかりません。

Cloud Logging のバケットとシンクの詳細については、このモジュールの ルーティングとストレージの概要

ストレージの料金

Logging は、_Required バケットに保存されているログに対して課金しません。 _Required バケットの削除や _Required シンクの変更はできません。 _Required バケットには、次のログが保存されます。

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

で確認できます。

注: Cloud Logging に自動的に保存されるログのコピーを _Required バケットを別のログバケットに転送してから、storage と 保持料金が適用されます。

Logging では、インデックスに登録されたログデータの量に対して _Default ログバケットとユーザー定義のログバケットに保存される。 合計使用量が毎月の無料割り当て分を 超えると発生します _Default ログバケットまたは ユーザー定義のログバケットはストレージ割り当てにカウントされます。 たとえば、ログエントリを特定のリージョンにルーティングする その場合、ログエントリは 3 回保存されます。

保持料金

注: 2023 年 4 月 1 日より、_Default バケットとユーザー定義のログバケットのデフォルトの保持期間を超えて保持されたログデータには、保持費用が適用されます。料金について詳しくは、Cloud Logging の料金のサマリーをご覧ください。ログバケットの課金対象ストレージを確認するには、Google Cloud コンソールの [ログストレージ] ページに移動します。

次の表に、Google Cloud Storage に保存されているログのデータ保持期間を ログバケット:

バケット	デフォルトの保持期間	カスタム保持
_Required	400 日	構成不可
_Default	30 日	構成可能
ユーザー定義	30 日	構成可能

ログの保持期間が長くなると、保持費用が発生します。 デフォルトの保持期間より長くなります。保持期間は構成できません _Required ログバケットに対して設定します。 特定の期間のログのみを保存する場合、保持期間は ログバケットのデフォルトの保持期間です。

ログバケットの保持期間を短縮すると、7 日間の保持期間が 期限切れのログは削除されません。クエリも表示もできない 防ぐことができます。ただし、この 7 日以内であれば、次の方法で完全アクセス権を復元できます。 ログバケットの保持期間を延長できます 猶予期間中に保存されたログは、保持費用にカウントされます。

ログエントリを複数のログバケットにルーティングすると、 保存と保持のコストが複数回発生しますたとえば、Kubernetes サービス _Default ログバケットとユーザー定義のログバケットへのログエントリ。 また、両方のバケットにカスタムの保持期間を設定すると仮定します。 30 日を超える期間を選択しますこの構成では 2 つのストレージ料金と 2 つの保持料金が発生します

ログストレージを削減する

Logging では、ログエントリを手動で特定し、除外する シンクに除外フィルタを構成することで、ログバケットに保存できます。 除外フィルタを使用すると、ストレージ費用を削減できます。または Cloud Logging からログを転送するかどうかも検討できます。

除外フィルタでは、フィルタに一致するすべてのログエントリを削除するか、 フィルタに一致する一部のログのみを削除できます。 ログエントリがシンクの除外フィルタと一致すると、そのシンクは ログエントリを宛先にルーティングしませんその結果 ログエントリを取り込みません。除外されたログエントリはカウントされません ストレージ割り当てに対して 課金されます設定方法については、 除外フィルタについては、以下をご覧ください。 ログの除外。

ログバケットに保存されていないログへのアクセスを保持するには、 Cloud Logging からサポートされているサービス アカウントにログエントリをルーティングするログシンク あります。Cloud Logging では、ログのルーティングに対して料金は発生しません。 ただし、ログを受信する Google Cloud サービスでは、 確認します。詳細については、次のドキュメントをご覧ください。

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

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

ログベースの指標の料金

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

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

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

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

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

アラート ポリシーの作成手順

アラート ポリシーを作成するには:

1. Google Cloud コンソールで [アラート] ページに移動します。

   アラートに移動

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

2. 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
3. [アラート] ページで、[CREATE POLICY] をクリックします。
4. リソース、指標、フィルタを選択するには、[指標を選択] メニューを開き、[New condition] テーブルの値を使用します。
   1. （省略可）メニューを関連エントリに限定するには、フィルタバーにリソースまたは指標名を入力します。
   2. リソースタイプを選択します。たとえば、[VM インスタンス] を選択します。
   3. 指標カテゴリを選択します。たとえば、[インスタンス] を選択します。
   4. 指標を選択します。たとえば、[CPU 使用率] を選択します。
   5. [適用] を選択します。
5. [次へ] をクリックして、アラート ポリシー トリガーを構成します。これらのフィールドに入力するには、[Configure alert trigger] テーブルの値を使用します。
6. [次へ] をクリックします。

7. （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

8. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
9. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
10. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
11. [Create Policy] をクリックします。

[New condition] フィールド	値
リソースと指標	[リソース] メニューで、[グローバル] を選択します。 [指標カテゴリー] メニューで、[ログベースの指標] を選択します。 [指標] メニューで、[取り込みログバイト数の月間合計] を選択します。
フィルタ	なし
時系列全体 時系列集計	sum
ローリング ウィンドウ	60 m
ローリング ウィンドウ関数	max

アラート・トリガーの構成 フィールド	値
条件タイプ	Threshold
アラート トリガー	Any time series violates
しきい値の位置	Above threshold
しきい値	許容値を決定します。
再テスト ウィンドウ	最小許容値は 30 分です。

Cloud Monitoring

Monitoring では、以下に対して料金が発生します。

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

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

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

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

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

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

• 合成モニターの実行。

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

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

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

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

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

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

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

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

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

  [お支払い] に移動

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

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

  Monitoring の [設定] に移動

  検索バーを使用してこのページを検索する場合は、小見出しが [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.googleapis.com/agent/ グループ

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

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

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

• AWS の指標

• カスタム指標 これには、 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 指標）

	取り込み量（MiB）	単価（$/MiB）	費用（$）
	上限なし	0.00	$0.00
合計	25,063		$0.00

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

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

	取り込み量（MiB）	単価（$/MiB）	費用（$）
	150	0.00	$0.00
	24,913	0.258	$6,427.55
合計	25,063		$6,427.55

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

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

	取り込み量（MiB）	単価（$/MiB）	費用（$）
	150	0.00	$0.00
	267	0.258	$69.14
合計	417		$69.14

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

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

	取り込み量（MiB）	単価（$/MiB）	費用（$）
	150	0.00	$0.00
	99,850	0.258	$25,761.30
	67,084	0.151	$10,129.68
合計	167,084		$35,890.98

管理と予測が可能な料金

Managed Service for Prometheus の料金は、 制御可能。サンプル単位で課金されるため、次の手段を使用して費用を管理できます。

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

• フィルタ: フィルタを使用して、送信されるサンプルの数を減らすことができます。 サービスのローバル データストアに送信します。詳細については、以下をご覧ください。 エクスポートした指標をフィルタする。 指標の再ラベル付けの構成を 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 か月分の基数に対して支払うことになります 新しいコンテナを起動するたびに 1 回発行されますサンプル単位の料金設定では、コンテナの実行中にのみ料金が発生します。

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

ユーザーが発行したすべてのクエリ（Prometheus の実行時に発行されたクエリを含む） 実行された場合は、Cloud Monitoring API 呼び出しを通じて課金されます。 現在のレートについては、 Managed Service for Prometheus の料金または Monitoring の料金。

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

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

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

次のような簡単なシナリオを想定します。各月で複数の時系列にまたがって書き込みを行うコンテナかポッドがあるとします。そのデータはスカラー値や分布で構成されています。

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

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

サンプルのカウント

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

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

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

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 個のサンプルが含まれ、月あたり最大 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 か月あたりのサンプル数 （最大）	1 か月あたりのサンプル数 （25% が空）	1 か月あたりのサンプル数 （40% が空）
50	1 サンプル / 15 秒	9,110,400	6,920,400	5,606,400
50	1 サンプル / 60 秒	2,277,600	1,730,100	1,401,600
100	1 サンプル / 15 秒	17,870,400	13,490,400	10,862,400
100	1 サンプル / 60 秒	4,467,600	3,372,600	2,715,600

例

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

取り込み範囲	Prometheus 向けのマネージド サービス	範囲の最大値
最大 500 億（50,000 百万）	$0.06/100 万	$3,000.00
500 億～2,500 億（250,000 百万）	$0.048/100 万	9,600.00 ドル
2,500 億～ 5,000 億（50 万）	$0.036/100 万	$9,000.00
5,000 億超	$0.024/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 百万となります。

どちらのケースでも 最初のレートのみが適用されます。サンプルの請求は 表示することもできます

バリアント	取り込まれたサンプル	取り込み範囲	Managed Service for Prometheus （$0.06、$0.048、$0.036、$0.024）
A（1 サンプル/15 秒） 合計	175 億 2,000 万 175 億 2,000 万	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$1,051.20 1,051.20 ドル
B（1 サンプル/60 秒） 合計	43 億 8,000 万 43 億 8,000 万	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$262.80 262.80 ドル

シナリオ 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 段目のレートのみが適用されます。

バリアント	取り込まれたサンプル	取り込み範囲	Managed Service for Prometheus （$0.06、$0.048、$0.036、$0.024）
A（1 サンプル/15 秒） 合計	50,000 百万 1 億 252 億 1 億 752 億回	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $6,009.60 9,009.60 ドル
B（1 サンプル/60 秒） 合計	438 億 43,800 万人	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$2,628.00 2,628.00 ドル

シナリオ 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 段目のレートで課金されます。
• 次の 25 万サンプルは、第 3 レートで請求されます。
• 残りの 7,490 億 4,000 万サンプルは、第 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 段目のレートで課金されます。

バリアント	取り込まれたサンプル	取り込み範囲	Managed Service for Prometheus （$0.06、$0.048、$0.036、$0.024）
A（1 サンプル/15 秒） 合計	50,000 百万 2 億 250,000 百万 749,040 百万 13 億 490 億 4,000 万	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $9,600.00 $9,000.00 $17,976.96 39,576.96 ドル
B（1 サンプル/60 秒） 合計	50,000 百万 2 億 872 億 6,000 万 3 億 372 億 6,000 万	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $9,600.00 $3,141.36 15,741.36 ドル

シナリオ 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 段目のレートで課金されます。
• 次の 25 万サンプルは、第 3 レートで請求されます。
• 残りの 1 億 8,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 段目のレートで課金されます。
• 次の 25 万サンプルは、第 3 レートで請求されます。
• 残りの 2,665 万 6,000 万サンプルは、第 4 レートで請求されます。

バリアント	取り込まれたサンプル	取り込み範囲	Managed Service for Prometheus （$0.06、$0.048、$0.036、$0.024）
A（1 サンプル/15 秒） 合計	50,000 百万 2 億 250,000 百万 1 億 8,124,000 億 1 億 8,624,000 億	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $9,600.00 $9,000.00 $2,594,976.00 2,616,576.00 ドル
B（1 サンプル/60 秒） 合計	50,000 百万 2 億 250,000 百万 266 億 5,600 万 2,715 万 6,000 万	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $9,600.00 $9,000.00 $639,744.00 661,344.00 ドル

シナリオ 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 段目のレートで課金されます。
• 次の 25 万サンプルは、第 3 レートで請求されます。
• 残りの 1,082 億 9,920 億サンプルは、第 4 レートで請求されます。

バリアント	取り込まれたサンプル	取り込み範囲	Managed Service for Prometheus （$0.06、$0.048、$0.036、$0.024）
2A + 4A 合計	50,000 百万 2 億 250,000 百万 1 億 8,299,200 億 1 億 8,799,200 億	最大 50,000 万 最大 250,000 万 最大 5 億 5 億超	$3,000.00 $9,600.00 $9,000.00 $2,599,180.80 2,620,780.80 ドル

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

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

稼働時間チェックの実行にかかる費用は、1,000 回の実行ごとに $0.30 です。 請求額は、請求書に SKU「CA14-D3DE-E67F」と記載されます。 「Monitoring Uptime Checks」と指定します。

次の例は、Google Cloud Storage バケットの費用を見積もる方法を 稼働時間チェックを実行できます。これらの例は、 計算方法であり、課金データを提供するものではありません。

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

稼働時間チェックの費用を見積もるには 1 か月以内にリージョンで実行できます料金のモニタリング 1,000 回の実行ごとに $0.30、100 万回の実行の毎月の無料割り当て。

稼働時間チェックの費用を見積もるには、以下を使用します。 計算:

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

各稼働時間チェックの実行回数は次の要因によって異なる 構成の選択肢:

• 稼働時間チェックの実行頻度: 1 分ごと、5 分ごと、 10 分または 15 分です。

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

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

稼働時間チェックを構成するときに、VM のロケーションを 各ロケーションは 1 つ以上のリージョンにマッピングされます。「 次の表に、稼働時間チェックで有効なロケーションとリージョンを示します。 マッピングします。

稼働時間チェック構成の場所	Google Cloud リージョンを含む
ASIA_PACIFIC	asia-southeast1
EUROPE	europe-west1
SOUTH_AMERICA	southamerica-east1
USA	us-central1, us-east4, us-west1
GLOBAL	他のロケーションに含まれるすべてのリージョン

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

稼働時間チェックの実行回数を見積もるには、次の情報が必要です。 稼働時間チェックのロケーションでカバーされるリージョンの数を指定します。

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

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

• USA で 1 分に 1 回実行されるように構成された稼働時間チェック 3 つのリージョンにデプロイされていますこの稼働時間チェックが 1 つのサービスに対する この稼働時間チェックは 131,400 回実行される （3 × 43,800）回表示されます。チェックが構成されているかどうか 10 人のメンバーを含むリソース グループをチェックすると、稼働時間チェックが実行され、 1,314,000（10 * 131,400）回（1 か月）。

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

次の表は、1 つのインスタンスの 1 時間ごとと 1 か月ごとの実行数を示しています。 異なる頻度、異なる頻度で実行されるように構成された稼働時間チェック リージョン数:

チェックの実行頻度（1 回ごと）:	リージョンの数	ターゲットごとの 1 時間の実行回数	ターゲットごとの 月間実行数
1 分	3 4 5 6	180 240 300 360	131,400 175,200 219,000 262,800
5 分	3 4 5 6	36 48 60 72	26,280 35,040 43,000 52,660
10 分	3 4 5 6	18 24 30 36	13,140 17,520 21,900 2 万 6,280
15 分	3 4 5 6	12 16 20 24 歳	8,760 11,680 14,600 17,520 人

例

料金を見積もるには、月間合計実行数を決定して、1,000,000 を引きます。残りの実行は 1,000 回実行ごとに $0.30 が課金されるため、 残りの実行時間に 0.0003 を掛けます。

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

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

月間合計実行数	課金対象の月間実行数 （1,000,000 以上）	費用 （1,000 回の実行ごとに $0.30）
13 万 1,400	0	$0.00

シナリオ 2: ロケーション USA に 1 つの稼働時間チェックがあります。 10 人のメンバーからなるリソース グループを 1 分ごとにチェックします。このチェックは 3 秒後に実行されます あります。このチェックは月に 10 * 131,400 回実行され、 月額 $94.20 です。このシナリオとシナリオ 1 の唯一の違いは ターゲットの数です

月間合計実行数	課金対象の月間実行数 （1,000,000 以上）	費用 （1,000 回の実行ごとに $0.30）
1,314,000 人（10 目標）	31 万 4,000	94.20 ドル

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

月間合計実行数	課金対象の月間実行数 （1,000,000 以上）	費用 （1,000 回の実行ごとに $0.30）
2,628,000	162 万 8,000	488.40 ドル

シナリオ 4: ロケーション USA に 5 つの稼働時間チェックがあるとします。 5 分ごとに 1 つの VM をチェックしますこれらのチェックは 3 つのリージョンで実行されるため、 チェックは 1 か月に 26,280 回実行されます。月間合計実行数 105,120（4 * 26,280）になります。

また、15 個ごとに 1 つの VM をチェックする 2 つの GLOBAL 稼働時間チェックもあります。 できます。これらのチェックは 6 つのリージョンで実行されるため、各チェックは実行されます 17,520 回/月このプロジェクトの月間合計実行数 35,040（2 × 17,520）です。

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

月間合計実行数	課金対象の月間実行数 （1,000,000 以上）	費用 （1,000 回の実行ごとに $0.30）
140,160	0	$0.00

合成モニターの実行にかかる料金（発効日: 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

課金対象の実行数を決定するには、無料割り当てを差し引きます。 （実行の合計数）から求め、結果を コスト:

月間合計実行数	課金対象の月間実行数 （請求先アカウントごとに 100 回を超える実行）	費用 （1,000 回の実行ごとに $1.20）
26,784	26,684	32.02 ドル

アラートの料金

2025 年 1 月 7 日以降、Cloud Monitoring アラートの課金が開始されます。 料金モデルは次のとおりです。

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

で確認できます。

重要: MSA は、料金が有効になる 60 日前と 30 日前に送信されます。

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

• アラート用語の定義。
• さまざまなアラートの料金の例 できます。
• 費用を削減するための推奨事項 アラートポリシーの統合または削除などができます
• 課金のオプトアウトに関する情報 モニタリングできます。

定義

• Condition: 特定の条件 アラート ポリシーは、リソースまたはリソースのグループが、 レスポンスが必要な状態になっています。

  • フィルタを使用して作成するアラート ポリシー metric-threshold または 指標の不在クエリを 最大 6 つの条件を組み合わせます。
  • 次のクエリタイプのアラート ポリシーに含めることができるのは、 単一の条件: <ph type="x-smartling-placeholder">
    </ph>
    • Prometheus Query Language（PromQL）クエリ
    • Monitoring Query Language（MQL）
    • ログの一致: ログベースのアラート。

  料金は、条件ごとに月額 $1.50 です。 条件に対する課金を停止するには、アラート ポリシーを削除する必要があります。 ポリシーをスヌーズまたは無効化しても、 請求が行われなくなります

• 指標とログベースのアラート ポリシー: ログ一致条件を除くすべての条件タイプは、metric アラートである ポリシー指標アラート ポリシーの条件は時系列を返します。 各実行期間中に、指標アラート ポリシーの条件が実行される Cloud Monitoring データストアに対してクエリを実行できます。返される 次に、時系列がしきい値に照らして評価され、 アラートポリシーがトリガーされます

  ログベースのアラート ポリシーでは、ログ一致条件を使用します。ログ一致条件 返されることはありません。

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

• 返される時系列: 実行のたびに、指標が Cloud Monitoring に対してその条件のクエリを実行します。 作成されます。Cloud Monitoring は、レスポンスとして時系列データを返します。 確認できますレスポンスの各時系列は 1 つの時系列としてカウントされます。 返されます。

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

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

  たとえば、次の構成があるとします。

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

  100 台の VM があり、それぞれが 10 個の時系列（ 合計 1,000 の基になる時系列があります。 各 VM にはメタデータに似たラベルもあり、 VM が属する 5 つのサービスを指定できます。

  アラート ポリシーは、 構成ごとに異なる数値が生成される 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

料金の例

以下の例は 1 か月（30 日間）に発生したため、次のようになります。 評価期間：

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

例 1: 1 つのポリシー、VM に集約、30 秒

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

データ

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

アラート ポリシー

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

発生する費用

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

例 2: 100 個のポリシー（VM ごとに 1 個）、VM に集約、30 秒

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

データ

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

アラート ポリシー

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

発生する費用

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

例 3: 1 つのポリシー、VM に集約、15 秒

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

データ

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

アラート ポリシー

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

発生する費用

• 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
• 時系列の費用: 期間ごとに 100 個の時系列 * 172,800 回/月 = 1 か月あたり 1,730 万の時系列 * 100 万時系列あたり $0.35 = 月額 $6.05
• 総費用: 月額 7.55 ドル

例 4: 各サービスに 1 つのポリシーを 30 秒で集約する

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

データ

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

アラート ポリシー

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

発生する費用

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

例 5: 1 つのポリシーを VM に集約するVM あたりの基になるカーディナリティが高い（30 秒）

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

データ

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

アラート ポリシー

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

発生する費用

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

例 6: 1 つのポリシーを VM に集約する2 つの指標を 1 つの条件（30 秒）に統合します

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

データ

• 100 VM
• 各 VM は、metric_name_1 と metric_name_2 の 2 つの指標を出力します。
• どちらの指標にもラベルが 1 つあり、それぞれに 10 個の値が設定されています。

アラート ポリシー

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

発生する費用

• 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
• 時系列の費用: 2 つの指標 x 1 期間あたり指標ごとに 100 個の時系列が返される * 86400 期間（1 か月あたり）= 1 か月あたり 1,730 万の時系列 * 100 万時系列あたり $0.35 = 月額 $6.05
• 総費用: 月額 7.55 ドル

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

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

アラート ポリシー

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

発生する費用

• 条件の費用: 100 条件 × 1 か月あたり $1.50 = 月額 $150.00
• 期間グラフの費用: $0 （ログベースのアラート ポリシーは時系列を返しません）。
• 総費用: 月額$150.00

アラート料金の削減に関する提案

指標ベースのアラート ポリシーを構成する場合は、次のものを使用します。 推奨事項をご確認ください。

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

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

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

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

たとえば、例 1 と例 4 を比較します。 どちらの例も、同じ基盤となるデータに対して動作し、単一のアラートを使用します。 に関するポリシーに準拠する必要があります。ただし、例 4 のアラート ポリシーはサービスに集約されるため、VM に詳細に集約される例 1 のアラート ポリシーよりも費用が安いです。

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

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

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

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

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

また、元データに対するアラートを行うと、指標に新しいラベルが付けられたときに時系列が増加するリスクもあります。上記の例では、ユーザーが指標に新しいラベルを追加すると、合計カーディナリティが 100 * 11 * 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 秒間隔のクエリの半分の頻度で実行されます。

注: その他のアラート ポリシー条件は 30 秒の実行に固定されています。 確認できます。

オプトアウト

次の期限までに期限切れにならない既存の Google Cloud 契約がある場合 2025 年 1 月 7 日以降、契約になるまでアラートの課金を遅らせることができます Cloud Monitoring の免除をリクエストして更新時期を迎えている 課金チームにアラートを送信します有効な契約をお持ちのお客様に対する免除 状況に応じて判断します

2024 年 11 月 1 日まで免除を申請できます。 契約更新まで課金免除を申請するには、 課金免除のリクエスト フォームに記入します。

Error Reporting

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

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

Cloud Profiler

Cloud Profiler の使用に費用はかかりません。

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

Cloud Trace

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

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

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

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

現在または過去の使用状況を確認する方法については、 請求の見積もり

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

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

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

課金対象のトレースというセクションに記載されているスパンを除くすべてのトレーススパンの取り込みは課金対象となり、取り込まれる量に応じて課金されます。これには、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 スパンの月間合計が、ユーザー定義の上限を超えたときにトリガーされるアラート ポリシーを作成するには、次の設定を使用します。

アラート ポリシーの作成手順

アラート ポリシーを作成するには:

1. Google Cloud コンソールで [アラート] ページに移動します。

   アラートに移動

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

2. 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
3. [アラート] ページで、[CREATE POLICY] をクリックします。
4. リソース、指標、フィルタを選択するには、[指標を選択] メニューを開き、[New condition] テーブルの値を使用します。
   1. （省略可）メニューを関連エントリに限定するには、フィルタバーにリソースまたは指標名を入力します。
   2. リソースタイプを選択します。たとえば、[VM インスタンス] を選択します。
   3. 指標カテゴリを選択します。たとえば、[インスタンス] を選択します。
   4. 指標を選択します。たとえば、[CPU 使用率] を選択します。
   5. [適用] を選択します。
5. [次へ] をクリックして、アラート ポリシー トリガーを構成します。これらのフィールドに入力するには、[Configure alert trigger] テーブルの値を使用します。
6. [次へ] をクリックします。

7. （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

8. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
9. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
10. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
11. [Create Policy] をクリックします。

[New condition] フィールド	値
リソースと指標	[リソース] メニューで、[グローバル] を選択します。 [指標カテゴリー] メニューで、[お支払い] を選択します。 [指標] メニューで、[Monthly trace spans ingested] を選択します。
フィルタ
時系列全体 時系列集計	sum
ローリング ウィンドウ	60 m
ローリング ウィンドウ関数	max

アラート・トリガーの構成 フィールド	値
条件タイプ	Threshold
アラート トリガー	Any time series violates
しきい値の位置	Above threshold
Threshold value	許容値を決定します。
再テスト ウィンドウ	最小許容値は 30 分です。

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 つのステップ

指標のスコープの請求への影響

ほとんどの場合、指標のスコープは請求には影響しません。ログと指標は、データを受信する Google Cloud プロジェクトで課金されます。プロジェクトの指標スコープは、表示およびモニタリングできる指標があるプロジェクトのコレクションを定義します。指標スコープを定義する際に、どのプロジェクトで指標データを受信するかに影響されることはなく、データの重複を招くこともありません。

たとえば、組織に 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 通りの方法で表示できるようになりましたが、請求される料金に変更はありません。

AWS アカウントをモニタリングする場合は、AWS の 作成することで、AWS アカウントから Google Cloud に AWS コネクタ プロジェクト。 AWS アカウントのログデータとモニタリング データはコネクタ プロジェクトで保持されます。

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

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

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

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

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

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

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

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

VPC フローログを Logging に送信する場合、VPC フローログの生成料金は不要となり、Logging の料金のみが適用されます。ただし、送信した VPC フローログを Logging から除外すると、VPC フローログの料金が適用されます。詳細については、次をご覧ください: Google Cloud 料金計算ツール 次に、[Cloud Load Balancing とネットワーク サービス] タブを選択します。

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

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

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

次のステップ

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

カスタム見積もりをリクエストする

Google Cloud の従量課金制では、使用したサービスに対してのみ料金が発生します。カスタム見積もりをご希望の場合は、Google のセールスチームにお問い合わせください。

お問い合わせ