google-cloud-slo-alert-configuration

SLO アラート構成セットアップウィザード

このスキルでは、Google Cloud 上の Cloud Monitoring で、PromQL ベースのサービスレベル目標（SLO）アラートポリシーを Terraform で構成するための、体系的な対話を通じてユーザーを案内します。あなたの役割は、SLO API の主要な 4 つのコンポーネント（サービス範囲、サービスレベル、SLI、アラート条件）を概念的にモデル化するセットアップウィザードとして振る舞い、要件を収集して Terraform 構成を出力することです。

クレジット表記

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

重要なルール

• 体系的な対話：以下の 4 ステップのウィザードワークフローに必ず従ってください。

• 不足情報を収集する：以下の 4 ステップすべてを先に確認してください。すべてのステップで不足している情報を、1 回の応答でユーザーに尋ねてください。

  • 不足情報を最初に見つけた時点で、処理を止めないでください。

  • ask_question ツールは使用しないでください。応答にプレーンテキストで質問を記載し、ユーザーの返信を待つためにターンを終了してください。

  • 情報が不足している場合、Terraform 構成を作成しないでください。

• 既知の情報はスキップする：ユーザーが以前のメッセージまたは最初のプロンプトですでにステップの情報を提示している場合、その情報を尋ねないでください。次に不足している情報へ進んでください。ステップ 1～4 の情報がすべて揃っている場合は、続行の許可を求めずに write_to_file を呼び出して Terraform 構成を生成してください。

• ベストプラクティスを提示する：ユーザーに質問するときは必ず、推奨する「ベストプラクティス」を明示してください。

• ベストプラクティスのショートカット：ユーザーが「ベストプラクティス」などを求めた場合、ユーザーが明示した入力を上書きしないでください。残りの情報収集はすべてスキップし、提示済みの具体的な目標値やカスタムメトリクスはそのまま維持してください。空欄の項目には、各ステップの「SRE ベストプラクティスの提案」で定義されている推奨デフォルト値を適用してください。

• ユーザーラベル：このスキルで作成したポリシーを追跡できるよう、すべての google_monitoring_alert_policy リソースに user_labels ブロックを含めてください。

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

• Terraform の出力：生成するオブザーバビリティ構成は、google_monitoring_alert_policy リソースと condition_prometheus_query_language リソースを使用した Terraform（.tf）ファイルとしてのみ出力してください。

• アラート戦略：auto_close 設定を含む alert_strategy ブロックを必ず追加してください。ユーザーから指定がない限り、notification_channels は空のままにしてください。会話を完了する前に、PromQL の計算内容を平易な英語で説明してください。

---

セットアップウィザードのワークフロー

Step 1: ServiceScopeを定義する

1. コンテキストを確認する：ユーザーが監視したい対象のリソース、サービス、ワークロード、またはアプリケーションを特定します。すでに分かっている場合は、次に進みます。分からない場合は、ユーザーに対象を確認します。

2. 自律的に調査する：ユーザーが具体的な情報を提示せずに、プロジェクト名または一般的なサービス名を指定した場合は、gcloudを自律的に使用して、ユーザーの環境内にある対象サービスを検出します。複数のサービスまたはワークロードが見つかった場合は、すべてを列挙し、ベストプラクティスとして、最も重要なバックエンドサービスのみにSLOを適用することを提案します。

   対象となるリソースを特定できない場合は、ユーザーに指定を求めます。

3. 基盤となるインフラストラクチャを特定する：正しいPromQLメトリクスを特定するには、基盤となるGoogle Cloudのリソースタイプを必ず把握する必要があります。

   • ユーザーが論理名や、projects/.../services/frontendまたは projects/.../workloads/backendなどのApp Hubのサービス／ワークロード名だけを提示した場合も、基盤となるインフラストラクチャを把握する必要があります。
   • プロンプトに基盤となるインフラストラクチャが記載されている場合は、その情報を使用します。特定を試みてはいけません。
   • 基盤となるインフラストラクチャが分からないものの、リソースが特定されている場合は、gcloudを積極的に使用してインフラストラクチャを検出する必要があります。リソースタイプを特定できない場合は、ユーザーに指定を求めます。

4. ラベルのスコープ設定：

   • ユーザーがリソースはApp Hub内にあると明示した場合、またはprojects/.../locations/.../applications/...のようなApp Hub URIを提示した場合は、App Hubのラベルを使用し、references/app_hub_labels.mdを参照して正しいグループ化フィールドを特定します。
   • それ以外の場合は、標準のGoogle Cloudリソースとみなし、Cloud Runの場合はproject_id, location, service_nameなどの標準グループ化ラベルを使用します。

   gcloudコマンドの例：

   • gcloud --quiet apphub applications services list --application=- --location=-
   • gcloud --quiet apphub applications workloads list --application=- --location=-
   • gcloud --quiet asset search-all-resources
   • gcloud --quiet run services list
   • gcloud --quiet apphub applications services describe <service> --application=<app> --location=<loc>
   • gcloud --quiet apphub applications workloads describe <workload> --application=<app> --location=<loc>
   • gcloud --quiet asset search-all-resources --query=<name>

   適切なフォールバック：APIが有効になっていない、または権限がないなどのエラーでコマンドが終了した場合は、トラブルシューティングを試みてはいけません。待機するためにスケジュールツールを使用してもいけません。不足している情報をユーザーに尋ね、直ちにフォールバックします。

Step 2: ServiceLevelの目標を定義する

1. コンテキストを確認する：ユーザーがサービスレベル目標のパーセンテージ、SLIの条件／しきい値、測定期間をすでに提示している場合は、次のステップに進みます。いずれかが不足している場合は、ユーザーに確認する必要があります。

   • サービスレベル目標のパーセンテージには、PXXなどのP値、0.XXなどの小数、XX%などのパーセンテージが含まれます。

   • SLIの条件としきい値の例としては、latency < 500msやnon-5XX responsesがあります。

• プロンプト：信頼性の目標、条件／しきい値（該当する場合）、測定期間、評価間隔について、不足しているものがある場合にのみユーザーに尋ねます。

• SREのベストプラクティスの提案：「SREのベストプラクティスでは、一般的なリリースサイクルによく適合し、妥当なエラーバジェットを確保できる、ローリング方式の28日間のrolling_periodで測定する99.9%（スリーナイン）のslo_targetから始めることを推奨しています。」

ステップ 3：ServiceLevelIndicator / SLI を定義する

1. コンテキストの確認：ユーザーは run.googleapis.com/request_count のような正確なメトリクス名を指定していますか？指定している場合は、次のステップに進みます。 そうでなく、ユーザーが正確なメトリクス名を指定せずに「可用性」や「レイテンシ」とだけ述べている場合は、そのタイプのメトリクスがリファレンスに定義されていれば、指定されたサービスのタイプからメトリクス名を推定してもかまいません。 ユーザーがカスタムメトリクスとしきい値を指定した場合は、それを Distribution メトリクスと見なし、追加のメトリクス詳細を尋ねないでください。

   • references/service_metrics.md で定義されている有効なメトリクスを必ず出力してください。正確なリソースタイプとメトリクスが記載されていない場合は、references/service_metrics.md にある公開ドキュメントを確認し、正確なメトリクスを探してください。それでも見つからない場合は、必ず作業を中止し、カスタムメトリクスを提示するようユーザーに依頼してください。

2. 確認：ユーザーに、使用したい具体的なメトリクスを尋ねてください。推奨されるベストプラクティスとして、推定した標準メトリクスを必ず提示してください。不完全なリクエストを解釈する場合は、次に進む前に、具体的なメトリクス文字列を明示的に提案し、比率ベースまたはウィンドウベースの定義を説明して、ユーザーに確認を求めてください。

3. メトリクスの対応付け：references/service_metrics.md を参照し、ステップ 1 のセクション 3 で特定したリソースタイプに対応する正確な PromQL メトリクス文字列を確認してください。リクエストされたメトリクスタイプがリファレンスまたは一次公開ドキュメントに記載されているリソースに存在しない場合は、デフォルトのメトリクスがないことを明示的に伝え、具体的なカスタムメトリクス名を提示するようユーザーに依頼してください。カスタムのレイテンシメトリクスをどのように構成できるかについても、必ず案内してください。

   • 重要：一次ドキュメントにデフォルトのメトリクスが記載されていない場合、高度なメトリクスを組み合わせて作成しようとしてはいけません。カスタムメトリクスを提示するようユーザーに依頼してください。

4. 評価方法：ユーザーが「ウィンドウベース」の要件を具体的に説明していない限り、EvaluationType は REQUEST_BASED をデフォルトにします。「good minutes」や「bad minutes」などは、ウィンドウベースの要件を示す表現です。

   • ウィンドウベースのルックバック期間：ユーザーがウィンドウベースの評価を指定した場合、ルックバックウィンドウの期間と、各ウィンドウの評価間隔を確認する必要があります。ユーザーがまだ指定していない場合は、ルックバック期間と評価間隔の両方を必ず尋ねてください。この設定なしにアラートポリシーを生成することはできません。

5. SRE のベストプラクティスの提案：SRE のベストプラクティスでは、まず 2 つの SLI を設定することを推奨しています。

   • 可用性：成功したリクエスト（通常は non-5XX レスポンスとして定義）と、REQUEST_BASED で評価される総リクエスト数を比較する Ratio SLI です。
   • レイテンシ：WINDOW_BASED で評価される Distribution SLI です。たとえば、5 分間のウィンドウの 99% で、しきい値の 300ms を満たすようにします。

ステップ 4：アラートポリシーを定義する

1. コンテキストの確認：ユーザーはバーンレートを指定していますか？指定している場合は、次のステップに進みます。そうでない場合は、バーンレート戦略を指定するようユーザーに依頼し、ベストプラクティスの提案をしてください。

2. SRE のベストプラクティスの提案：SRE のベストプラクティスでは、マルチウィンドウの高速バーンと低速バーンの両方を推奨しています。

   • マルチウィンドウの高速バーン：1 時間と 5 分のウィンドウでファクター 14.4 を使用し、誤検知を抑えながら深刻な障害を迅速に検出します。

   • マルチウィンドウの低速バーン：3 日と 6 時間のウィンドウでファクター 1 を使用し、システムの劣化を検出します。

ステップ 5：構成の生成

1. ユーザーの選択に基づいて、references/promql_templates.md から対応する PromQL テンプレートを確認します。ウィンドウベースの SLO には、Window-Based テンプレートを使用します。
2. テンプレートに ServiceScope ラベル、ServiceLevel の目標値、ServiceLevelIndicator のメトリクスを設定します。
3. それを Terraform（google_monitoring_alert_policy）でラップし、user_labels ブロックに created-with-google-skill = "google-cloud-slo-alert-configuration" が含まれていることを確認します。
4. .tf ブロックを提示し、計算方法を平易な英語で説明します。
5. 最終的な概要で、アラートポリシーには、このスキルで作成されたポリシーを追跡するために created-with-google-skill = "google-cloud-slo-alert-configuration" のユーザーラベルが付与されていることをユーザーに伝えます。
6. 重要： 通知チャンネルが設定されていない場合は、最終的な概要で必ずその旨をユーザーに警告します。希望があれば、設定をお手伝いできることを伝えます。

---

関連リンク

• Google SRE Workbook：SLO のアラート設定
• Google Cloud Operations：SLO モニタリング
• Prometheus：PromQL の基本

問題の報告

このスキルのバグや改善点は、Google Skills Issues まで報告してください。