このページでは、Google Cloud Observability の費用を最適化してモニタリングする方法について説明します。料金情報については、Google Cloud Observability の料金をご覧ください。
次のドキュメントもご覧ください。
- 料金を見積もる。
- 料金の例。
- Cost Explorer で費用を最適化する。Cost Explorer は、費用データと使用率の指標の現在の値と過去の値を可視化します。そのため、このデータは最適化の機会の特定に役立ちます。
最適化
このセクションでは、Cloud Logging、Cloud Trace、Google Cloud Managed Service for Prometheus に関連する費用を削減または最適化する方法について説明します。
ログストレージを削減する
Cloud Logging のストレージ費用を削減するには、ログシンクに除外フィルタを構成し、特定のログをルーティング対象から除外します。除外フィルタでは、フィルタに一致するログエントリをすべて除外することも、一致するログの特定の割合だけを除外することもできます。ログエントリがシンクの除外フィルタに一致すると、そのログエントリはシンクからその宛先にルーティングされません。除外されたログエントリはストレージの割り当て量を消費しません。除外フィルタを設定する手順については、ログの除外をご覧ください。
Cloud Logging のストレージ費用を削減するには、Cloud Logging からサポート対象の宛先にログをルーティングするという方法もあります。Cloud Logging でサポート対象の宛先にログをルーティングしても、料金は発生しません。ただし、宛先でログを受信すると、その宛先での料金が請求される場合があります。
Cloud Logging からログをルーティングする方法については、サポートされている宛先にログをルーティングするをご覧ください。
Managed Service for Prometheus の費用を最適化する
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 の料金のサマリー表をご覧ください。
トレース使用量を削減する
トレーススパンの取り込み量を管理するには、トレースのサンプリング レートを管理して、パフォーマンス分析に必要なトレース量と許容される費用の間でバランスを取るようにします。
トラフィックの多いシステムでは、多くの場合、トランザクションの 1/1,000（場合によっては 1/10,000）をサンプリングするだけで、パフォーマンス分析を行うのに十分な情報を得られます。
サンプリング レートの構成は、Cloud Trace クライアント ライブラリを使用して行います。
アラートの課金を削減する
2026 年 5 月 1 日以降、Cloud Monitoring でアラート ポリシーの使用に対する課金が開始されます。料金モデルについては、アラートの料金をご覧ください。このドキュメントでは、アラートの費用を削減するために活用できる戦略について説明しています。
アラート ポリシーを統合して、より多くのリソースに対して動作するようにする
条件ごとに $0.10 の費用がかかるため、1 つのアラート ポリシーを使用して各リソースをモニタリングするよりも、1 つのアラート ポリシーを使用して複数のリソースをモニタリングする方が費用対効果に優れた方法になります。以下の例を考えてみましょう。
例 1
データ
- 100 VM
- 各 VM が 1 つの指標
metric_nameを出力します。 metric_nameには 10 個の値が含まれる 1 つのラベルがあります。
- 1 つのアラート条件
- VM レベルでの条件の集計
- 30 秒間の実行期間
- 条件費用: 1 条件 x 月額 $0.10 = 1 か月あたり $0.10
- 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 860 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
- 合計費用: 1 か月あたり $3.12
例 2
データ
- 100 VM
- 各 VM が 1 つの指標
metric_nameを出力します。 metric_nameには 10 個の値が含まれる 1 つのラベルがあります。
- 100 件の条件
- 各条件がフィルタされ、1 つの VM に集計されます。
- 30 秒間の実行期間
- 条件費用: 100 条件 x 月額 $0.10 = 1 か月あたり $10
- 時系列費用: 100 条件 * 実行期間ごとに返される 1 条件あたりの時系列 1 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 860 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
- 合計費用: 1 か月あたり $13.02
どちらの例でも、同じ数のリソースをモニタリングします。ただし、例 2 では 100 件のアラート ポリシーを使用していますが、例 1 で使用しているアラート ポリシーは 1 件だけです。その結果、例 1 の 1 か月あたりの料金は $10 近く低くなります。
アラートが必要なレベルのみに集計する
より高いレベルの粒度に集計すると、低い粒度に集計する場合よりもコストが高くなります。たとえば、 Google Cloud プロジェクト レベルでの集計はクラスタレベルでの集計よりも費用が安く、クラスタレベルでの集計はクラスタレベルと名前空間レベルでの集計よりも費用が安くなります。
以下の例を考えてみましょう。
例 1
データ
- 100 VM
- 各 VM が 1 つの指標
metric_nameを出力します。 metric_nameには 10 個の値が含まれる 1 つのラベルがあります。
- 1 つのアラート条件
- VM レベルでの条件の集計
- 30 秒間の実行期間
- 条件費用: 1 条件 x 月額 $0.10 = 1 か月あたり $0.10
- 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 860 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
- 合計費用: 1 か月あたり $3.12
例 4
データ
- 100 台の VM。各 VM は 1 つのサービスに属します
- 合計で 5 つのサービス
- 各 VM が 1 つの指標
metric_nameを出力します。 metric_nameには 10 個の値が含まれる 1 つのラベルがあります。
- 1 件の条件
- サービスレベルでの条件の集計
- 30 秒間の実行期間
- 条件費用: 1 条件 x 月額 $0.10 = 1 か月あたり $0.10
- 時系列費用: 実行期間ごとに返される時系列 5 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 432,000 件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $0.14
- 合計費用: 1 か月あたり $0.24
例 5
データ
- 100 VM
- 各 VM が 1 つの指標
metric_nameを出力します。 metric_nameには 100 個のラベルがあり、それぞれに 1,000 個の値があります
- 1 件の条件
- VM レベルでの条件の集計
- 30 秒間の実行期間
- 条件費用: 1 条件 x 月額 $0.10 = 1 か月あたり $0.10
- 時系列費用: 実行期間ごとに返される時系列 100 件 * 1 か月あたり 86,400 回の実行期間 = 1 か月あたりに返される時系列 850 万件 * 100 万件の時系列ごとに $0.35 = 1 か月あたり $3.02
- 合計費用: 1 か月あたり $3.12
例 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(metric, 5) 句は、実行期間ごとに返される時系列の数を 5 に制限します。
時系列の数に制限を加えると、次のようなデータの欠落やアラートの不具合が発生する可能性があります。
- N 件以上の時系列がしきい値を超えた場合、上位 N 件の時系列外のデータが失われます。
- 違反する時系列が上位 N 件の時系列外で発生した場合は、除外された時系列がしきい値をまたいでもインシデントが自動的にクローズされる可能性があります。
- 条件クエリで、想定したとおりに機能しているベースライン時系列などの重要なコンテキストが示されない場合があります。
このようなリスクを軽減するには、N に大きい値を選択し、多数の時系列を評価するアラート ポリシー（個々の Kubernetes コンテナのアラートなど）でのみトップストリーム演算子を使用します。
実行期間を長くする（PromQL のみ）
条件で PromQL クエリを使用する場合、条件の evaluationInterval フィールドを設定して、実行期間の長さを変更できます。
評価間隔が長いほど、1 か月間に返される時系列は少なくなります。たとえば、15 秒間隔の条件クエリは、30 秒間隔のクエリの 2 倍の頻度で実行され、1 分間隔のクエリは、30 秒間隔のクエリの半分の頻度で実行されます。
モニタリング
このセクションでは、アラート ポリシーを作成して費用をモニタリングする方法について説明します。アラート ポリシーは、指標データをモニタリングし、そのデータがしきい値を超えたときに通知できます。
取り込まれたログバイト数の月間合計をモニタリングする
ログバケットに書き込まれたログバイト数が Cloud Logging のユーザー定義の上限を超えたときにトリガーされるアラート ポリシーを作成するには、次の設定を使用します。
| [New condition] フィールド |
値 |
|---|---|
| リソースと指標 | [リソース] メニューで、[グローバル] を選択します。 [指標カテゴリ] メニューで、[ログベースの指標] を選択します。 [指標] メニューで、[取り込みログバイト数の月間合計] を選択します。 |
| フィルタ | なし |
| 時系列全体 時系列集計 |
sum |
| ローリング ウィンドウ | 60 m |
| ローリング ウィンドウ関数 | max |
| [アラート トリガーの構成] フィールド |
値 |
|---|---|
| 条件タイプ | Threshold |
| Alert trigger | Any time series violates |
| しきい値の位置 | Above threshold |
| しきい値 | 許容値を決定します。 |
| 再テスト ウィンドウ | 最小許容値は 30 分です。 |
取り込まれた合計指標をモニタリングする
1 か月あたりの指標の取り込み量に基づいてアラートを作成することはできません。ただし、Cloud Monitoring の費用に対してアラートを作成することは可能です。詳細については、請求アラートを構成するをご覧ください。
取り込まれたトレーススパンの月間合計をモニタリングする
取り込まれた Cloud Trace スパンの月間合計が、ユーザー定義の上限を超えたときに起動するアラート ポリシーを作成するには、次の設定を使用します。
| [New condition] フィールド |
値 |
|---|---|
| リソースと指標 | [リソース] メニューで、[グローバル] を選択します。 [指標カテゴリ] メニューで、[お支払い] を選択します。 [指標] メニューで、[Monthly trace spans ingested] を選択します。 |
| フィルタ | |
| 時系列全体 時系列集計 |
sum |
| ローリング ウィンドウ | 60 m |
| ローリング ウィンドウ関数 | max |
| [アラート トリガーの構成] フィールド |
値 |
|---|---|
| 条件タイプ | Threshold |
| Alert trigger | Any time series violates |
| しきい値の位置 | Above threshold |
Threshold value |
許容値を決定します。 |
| 再テスト ウィンドウ | 最小許容値は 30 分です。 |
請求アラートを構成する
請求額または予測料金が予算を超えた場合に通知を受け取るには、 Google Cloud コンソールの [予算とアラート] ページでアラートを作成します。
-
Google Cloud コンソール [お支払い] ページに移動します。
このページは、検索バーを使用して見つけることもできます。
複数の Cloud 請求先アカウントがある場合は、次のいずれかを行います。
- 現在のプロジェクトの Cloud Billing を管理するには、[リンクされた請求先アカウントに移動] を選択します。
- 別の Cloud 請求先アカウントを確認するには、[請求先アカウントを管理] を選択し、予算を設定する対象のアカウントを選択します。
- [お支払い] ナビゲーション メニューから [予算とアラート] を選択します。
- [予算を作成] をクリックします。
- 予算ダイアログに入力します。このダイアログでは、 Google Cloud のプロジェクトとサービスを選択し、その組み合わせに対する予算を作成します。デフォルトでは、予算の 50%、90%、100% に達すると通知が送られます。詳細については、予算と予算アラートの設定をご覧ください。