cloud-run-alert-configuration

Cloud Run アラート設定

Terraform と PromQL（Cloud Monitoring）を使用した、Cloud Run 向けの本番環境レベルの可観測性です。SRE のプラクティスに基づき、ユーザーへの実際の影響とスケーリングの上限に厳密に焦点を当てています。

---

帰属情報

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、必ず使用状況の帰属情報をお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコード内では決して実行しない）の場合は、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:cloud-run-alert-configuration)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:cloud-run-alert-configuration) を追加してください。

重要なルール

• プロンプト優先の高速パス（対象が指定されている場合は調査をスキップ）：
  • ユーザーのプロンプトで対象の Cloud Run サービス、ジョブ、またはワーカープール名が明示的に指定されている場合（例：'video-encoder'、'nightly-reconciliation'、'web-frontend'、'catalog-service'、'api-gateway'、'order-processor'）、ワークスペース内の .tf ファイルのスキャン（find_by_name、code_search、list_dir）と gcloud CLI による調査コマンドをすべてスキップしてください。
  • プロンプトですでに対象名が指定されている場合は、gcloud、terraform、またはファイル検索ツールを実行しないでください。代わりに、Terraform 変数でプロジェクト ID（variable "scoping_project_id" { default = "my-gcp-project" }）と対象リソース名をパラメーター化し、直ちに ステップ 2（アラートの設定） に進んでください。
• 自律的な調査（対象名が省略されている場合のみ）：
  • ルートのモノレポや範囲が限定されていないディレクトリをスキャンしないでください：ルートのワークスペースディレクトリ全体に対して find_by_name や ls を実行しないでください。
  • 設定を最初に確認：プロンプトでリソース名が省略されている場合に限り、作業ディレクトリ直下の .tf ファイルで google_cloud_run_v2_service、google_cloud_run_service、または google_cloud_run_v2_job を確認してください。
  • 次に CLI を確認（失敗時は安全にフォールバック）：プロンプトまたはローカルの .tf ファイルで設定されていない場合に限り、gcloud config get-value project と gcloud run services list を試してください。認証やメタデータのエラーなど、gcloud コマンドが失敗した場合、または terraform が見つからない場合は、直ちに CLI コマンドの実行を停止し、明示的な変数のデフォルト値を使用したパラメーター化 HCL を出力してください。
• ワークロードの振り分け：対象のワークロードを必ず分類し、それぞれに対応するリファレンスガイドに従ってください。
  • HTTP サービスの場合は、services.md に従ってください。
  • Cloud Run ジョブの場合は、jobs.md に従ってください。
  • ワーカープールの場合は、worker_pools.md に従ってください。
• 明示的なデフォルト値とユーザーによる上書き：
  • 対象ワークロードのリファレンスファイルで指定されているすべての定数（SLO 目標、レイテンシしきい値、SLA、飽和上限、レートガード）には、必ず明示的なデフォルト値を使用してください。
  • 最終的な要約出力で適用したデフォルト値を明示し、Terraform 変数またはプロンプト入力によって、デフォルトの定数をカスタマイズまたは上書きできることをユーザーに明確に伝えてください。
• メトリクススコープの一元管理：すべての Terraform google_monitoring_alert_policy リソースで project = var.scoping_project_id をパラメーター化し、単一のプロジェクトまたは一元管理された Cloud Monitoring Metrics Scope のどちらもポリシーの対象にできるようにしてください。
• PromQL の duration（再テスト期間）ルール：
  • ルックバックが 25 時間以下の場合：一時的な異常やスケールアップの遅延を吸収するため、duration = "300s"（5 分のバッファ）を設定してください（duration = "0s" を使用する即時ジョブ失敗アラートを除く）。
  • ルックバックが 25 時間を超える場合（例：3 日／7 日のスローバーン）：duration を完全に省略するか（または 0s に設定してください）。Cloud Monitoring は、ルックバックが 25 時間を超える PromQL クエリで duration が設定されていると、クエリを拒否します（INVALID_ARGUMENT）。
• Terraform の標準と必須ラベル：
  • google_monitoring_alert_policy と condition_prometheus_query_language を直接使用した、明確で完全な .tf 設定を回答に含めてください。
  • 必須のユーザーラベル：すべての google_monitoring_alert_policy リソースに、次の内容を含む user_labels ブロックを必ず指定してください。

    user_labels = {
      created-with-google-skill = "cloud-run-alert-configuration"
    }
    

  • alert_strategy { auto_close = "604800s" } を含め、notification_channels = var.notification_channels をパラメーター化してください。

ワークフローの手順

1. 検出と対象の特定

• 迅速な方法（プロンプトに対象名がある場合）：ユーザーのプロンプトに対象の Cloud Run サービス、ジョブ、またはワーカープール名が記載されている場合は、すべての検出コマンドとファイル検索を省略し、直接ステップ 2に進みます。
• 検出の代替手順（対象名がない場合）：プロンプトにリソース名が指定されていない場合に限り、ローカルの .tf ファイルを確認するか、gcloud を実行して対象ワークロードの種類と名前を特定します。gcloud の認証に失敗した場合は、直ちにデフォルトの Terraform 変数（var.scoping_project_id）に切り替えます。

2. アラートの設定

• 対応するガイドを参照して、アラートポリシーを生成します。
  • HTTP サービス：services.md を開きます。可用性 SLO（5xx）、リクエストレイテンシ（P95/P99）、クライアントエラー（4xx）、コンテナインスタンスの飽和、コンテナの CPU／メモリ使用率、トラフィックの異常（減少／急増）、および課金対象のインスタンス稼働時間をカバーする、要求されたアラートポリシーまたは標準セットを適用します。
  • バッチジョブ：jobs.md を開きます。ジョブ実行失敗の即時アラート（duration = "0s"）を適用します。
  • ワーカープール：worker_pools.md を開きます。4 つのポリシーからなる標準セット（タスク成功 SLO の Fast Burn／Slow Burn、バックログ ETD、メッセージ経過時間 SLA）を適用します。

3. Terraform の生成とレビュー

• 明示的にパラメーター化されたデフォルト値と必須の user_labels ブロック（created-with-google-skill = "cloud-run-alert-configuration"）を含む、完全な HCL 設定を回答に提示します。
• 適用したデフォルト値を明記し、すべての定数をユーザーが上書きできることを伝えます。
• PromQL のロジックとトリガーのしきい値を、分かりやすい平易な英語で説明します。

---

追加リソース

• Cloud Run のドキュメント
• Cloud Monitoring PromQL のドキュメント
• Terraform での Google Cloud アラートポリシー
• Google SRE ワークブック：SLO に基づくアラート