Google Cloud Managed Service for Prometheus

解決する課題

オープンソースの Prometheus は導入は容易ですが、規模が大きくなると「単一サーバーのスケール限界」「長期保存」「高可用性」「シャーディングの設計」といった運用課題が一気に重くなります。Managed Service for Prometheus は、これらの基盤運用を Google 側が肩代わりしつつ、利用者は使い慣れた Prometheus のエコシステムを維持できます。

• Prometheus サーバーの スケーリングや HA 構成を自前で運用したくない
• メトリクスを 長期間保存 して後から振り返りたい
• 既存の PromQL クエリやアラートルール、エクスポーターを捨てずに移行 したい
• 複数クラスタ・複数プロジェクトのメトリクスを 一元的にクエリ したい

主要概念と用語

Managed Service for Prometheus は、Google 社内のグローバルな時系列データベース Monarch をバックエンドに使い、Prometheus 互換のインターフェースを提供します。Cloud Monitoring（Google Cloud Observability）の一部として位置づけられます。

• マネージドコレクション（Managed Collection）: Google が管理するコレクターが、各 Pod の指定に従ってメトリクスをスクレイプする方式。GKE では推奨される収集方法
• セルフデプロイコレクション（Self-deployed Collection）: 利用者が Prometheus 互換のバイナリ（コレクター）を自分でデプロイして送信する方式。GKE 以外や細かな制御が必要な場合に使う
• PodMonitoring / ClusterPodMonitoring: マネージドコレクションでスクレイプ対象を宣言するカスタムリソース。名前空間単位がPodMonitoring、クラスタ全体が ClusterPodMonitoring
• Monarch: メトリクスの保存・クエリを担うグローバル分散の時系列データベース。利用者が直接触ることはない
• PromQL: Prometheus のクエリ言語。Managed Service for Prometheus でもそのまま使え、Cloud Monitoring 側からも PromQL でクエリできる
• Prometheus フロントエンド / クエリ API: 既存の Grafana や Prometheus UI から接続するための Prometheus 互換のクエリエンドポイント
• ルールエバリュエーター（Rule Evaluator）: 記録ルール（recording rule）やアラートルールを評価するコンポーネント。Prometheus のルール定義を流用できる
• エクスポーター（Exporter）: アプリやミドルウェアの状態を Prometheus 形式の指標として公開する仕組み。既存のエクスポーターをそのまま使える

仕様・制限・クォータ

• メトリクスは サンプル（時系列の 1 データ点） 単位で取り込まれ、課金や上限の基本単位になる
• 各時系列は ラベルの組み合わせ で識別される。ラベル基数（cardinality）が高いと系列数が膨らみ、取り込み量とコストが増える
• スクレイプ間隔は短くするほどサンプル数が増える。粒度と取り込み量はトレードオフになる
• マネージドコレクションは GKE での利用が中心 で、Anthos / 他環境やセルフデプロイ方式と使い分ける
• 取り込みや API には レート上限とクォータ があり、超過分はスロットリングされ得る。引き上げは割り当ての調整から申請する
• 保持期間・各種上限・既定のスクレイプ間隔などの具体値は変動するため、設計時は公式ドキュメントとプロジェクトの割り当て画面で確認する

内部の仕組み

収集側のコレクター（マネージドまたはセルフデプロイ）が、対象のエンドポイントからメトリクスを定期的にスクレイプし、Monarch へ送信します。Monarch は単一ノードに依存しないグローバル分散構成のため、利用者がシャーディングやレプリケーションを設計する必要がありません。

クエリ時は、Prometheus 互換のクエリ API が PromQL を受け取り、Monarch に対して評価します。これにより Grafana や既存の Prometheus UI、Cloud Monitoring のいずれからも同じメトリクスを参照できます。記録ルールやアラートルールはルールエバリュエーターが評価し、結果を新たな時系列として書き戻したり、アラートを発火させたりします。

設計パターン / ベストプラクティス

• GKE では マネージドコレクション を基本にし、コレクター自体の運用負荷をなくす
• スクレイプ対象は PodMonitoring / ClusterPodMonitoring で宣言的に管理し、構成をコード化する
• ラベル基数を設計段階で抑える。ユーザー ID やリクエスト ID など高基数のラベルを避け、系列数の爆発を防ぐ
• スクレイプ間隔は 必要十分な粒度 に設定し、過剰な短間隔でサンプル数を増やしすぎない
• ダッシュボードは Grafana か Cloud Monitoring に集約し、PromQL で統一的に可視化する
• 複数クラスタ・複数プロジェクトのメトリクスは 指標スコープ や統合クエリでまとめて参照する

運用・監視

• メトリクスが届かない → コレクター（マネージド/セルフ）の稼働状況、PodMonitoring の対象指定、スクレイプ対象のエンドポイント公開を確認
• 権限エラー → 送信に使うサービスアカウントの IAM 権限（メトリクス書き込み相当）と、Monitoring API の有効化を確認
• クエリ結果が想定と違う → PromQL の評価範囲（range / rate の窓）と、ラベルのマッチ条件を確認
• 取り込み量が急増 → ラベル基数の増加や新しい系列の追加、スクレイプ間隔の短縮を点検する
• アラートが発火しない → ルールエバリュエーターの稼働とルール定義の評価期間、しきい値を確認

コスト

課金は主に 取り込んだサンプル数 に基づきます。同じ時系列でもスクレイプ間隔が短いほどサンプルが増え、系列数（ラベル基数）が多いほど総サンプル数が増えます。したがってコスト最適化は「系列数」と「スクレイプ頻度」を必要十分に絞ることに集約されます。

セキュリティ

• メトリクスの読み取り/書き込み権限は IAM ロール で最小化する（閲覧は Monitoring の閲覧者、送信は書き込みロール相当）
• 送信に使う認証は、キー JSON ではなく Workload Identity（GKE） や アタッチされたサービスアカウント を使い、鍵の漏洩リスクを避ける
• ラベルやメトリクス名に 個人情報や機微情報を含めない。高基数かつ機微なラベルは流出と系列爆発の両面で問題になる
• Prometheus のメトリクスエンドポイントは内部からのみ到達できるようにし、不要な外部公開を避ける

関連サービス・比較

Managed Service for Prometheus は Cloud Monitoring（Google Cloud Observability）の一部で、汎用の監視基盤である Cloud Monitoring と役割が重なりつつも、Prometheus エコシステム互換という点で位置づけが異なります。両者の関係を整理します。

両者は同じバックエンド（Monarch）を共有し、Cloud Monitoring 側からも PromQL でクエリできるため、Prometheus 由来の指標と Google Cloud の標準指標を一元的に扱えます。

ハンズオン / CLI例

# プロジェクトで Cloud Monitoring API を有効化する
# （Managed Service for Prometheus は Monitoring API 配下で提供される）
gcloud services enable monitoring.googleapis.com --project=PROJECT_ID

# GKE クラスタでマネージドコレクションを有効化して作成する
# （--enable-managed-prometheus でマネージド収集を有効にする）
gcloud container clusters create demo-cluster \
  --project=PROJECT_ID \
  --zone=asia-northeast1-a \
  --enable-managed-prometheus

# 既存クラスタへ後からマネージドコレクションを有効化する
gcloud container clusters update demo-cluster \
  --project=PROJECT_ID \
  --zone=asia-northeast1-a \
  --enable-managed-prometheus

# 送信用サービスアカウントにメトリクス書き込み権限を付与する
# （roles/monitoring.metricWriter がメトリクス送信に必要なロール）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:collector-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/monitoring.metricWriter"

スクレイプ対象は、GKE 上で PodMonitoring などのカスタムリソースを適用して宣言的に指定します。PromQL でのクエリやダッシュボードは、Grafana や Cloud Monitoring のメトリクスエクスプローラから行います。