为 Google Cloud 资源配置基于 PromQL…

当需要为 App Hub 或指定 GCP 资源创建 SLO 告警策略（而非普通告警策略）时，按向导式流程收集信息并输出 Terraform 配置。

适用场景

解决思路

1. 按 4 步向导流程推进：ServiceScope（服务范围）、ServiceLevel（服务水平目标）、SLI（服务级别指标）、Alert Condition（告警条件）。
2. 先评估全部 4 步所需信息，在单次回复中用纯文本一次性询问所有缺失信息；不要找到第一个缺失项就停止，不要使用 ask_question 工具，信息不全时不要写 Terraform。
3. 用户已提供的信息直接跳过，不再重复询问；若 1-4 步信息齐全，直接调用 write_to_file 生成 Terraform，无需请求许可。
4. 每次提问时都必须明确给出推荐的 Best Practice。
5. 若用户要求“最佳实践”，不要覆盖其已明确输入的内容，跳过剩余信息收集，保留其指定目标或自定义指标，其余留空字段套用各步的 SRE 最佳实践默认值。
6. 在所有 google_monitoring_alert_policy 资源中加入 user_labels 块：created-with-google-skill = "google-cloud-slo-alert-configuration"。
7. 仅以 Terraform（.tf）文件形式输出，使用 google_monitoring_alert_policy 资源和 condition_prometheus_query_language 资源。
8. 始终包含带 auto_close 设置的 alert_strategy 块；除非用户提供，否则 notification_channels 留空；定稿前用通俗语言解释 PromQL 数学含义。
9. Step 1：确定要监控的目标资源/服务/工作负载/应用；若用户只给了项目或笼统服务名，用 gcloud 自主发现目标服务，发现多个时列出并建议只对最关键的后端服务应用 SLO。
10. Step 1：必须确定底层 GCP 资源类型以解析正确的 PromQL 指标；若用户只给逻辑名或 App Hub 名称，需主动用 gcloud 发现底层基础设施；若提示中已给出底层基础设施则直接使用，不要再去发现。
11. Step 1：若用户明确提到资源在 App Hub 或给出 App Hub URI，使用 App Hub 标签并查阅 references/app_hub_labels.md 确定正确的 group-by 字段；否则按标准 GCP 资源处理，使用如 Cloud Run 的 project_id、location、service_name 等标准分组标签。
12. Step 1 可用 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>。
13. Step 1 优雅降级：若命令因 API 未启用或权限不足报错，不要排查、不要用 schedule 工具等待，立即回退到让用户补充缺失信息。
14. Step 2：确认服务水平目标百分比（PXX、0.XX 或 XX%）、SLI 条件/阈值（如 latency < 500ms 或 non-5XX responses）、测量周期与评估间隔；缺失则询问。
15. Step 2 最佳实践：从 99.9%（3 个 9）的 slo_target、滚动 28 天 rolling_period 开始，契合典型发布周期并提供合理错误预算。
16. Step 3：若用户已给出确切指标名（如 run.googleapis.com/request_count）则继续；若只说“可用性”或“延迟”，可从服务类型推断指标名（前提是 references 中已定义该类型指标）；若用户给出自定义指标和阈值，视为 Distribution 指标，不再追问细节。
17. Step 3：只能输出 references/service_metrics.md 中定义的有效指标；若未列出，查该文件中的公开文档找确切指标；仍找不到必须停下让用户提供自定义指标。
18. Step 3：询问用户想用哪个具体指标，并必须把推断出的标准指标作为推荐最佳实践；对不完整请求，必须明确给出具体指标字符串并描述基于比率或基于窗口的定义，让用户确认后再继续。
19. Step 3：查阅 references/service_metrics.md 找到 Step 1 所定资源类型对应的确切 PromQL 指标字符串；若该资源在 references 或主要公开文档中不存在所请求指标类型，必须明确告知无默认指标并让用户提供自定义指标名，同时给出自定义延迟指标结构的指导；主要文档未列默认指标时，绝不要自行拼凑高级指标。
20. Step 3：EvaluationType 默认设为 REQUEST_BASED，除非用户明确描述 window-based 需求（通常表现为“good minutes”或“bad minutes”）。
21. Step 3：若为 window-based 评估，必须向用户询问 lookback 窗口时长和每个窗口的评估间隔，二者缺一不可，否则无法生成告警策略。
22. Step 3 最佳实践：从两个 SLI 开始——可用性用 Ratio SLI，比较成功请求（通常定义为 non-5XX）与总请求，按 REQUEST_BASED 评估；延迟用 Distribution SLI，按 WINDOW_BASED 评估，如 99% 的 5 分钟窗口须满足 300ms 阈值。
23. Step 4：确认用户是否指定 burn rate；未指定则询问 burn rate 策略并给出最佳实践建议。
24. Step 4 最佳实践：同时配置多窗口快速燃烧和多窗口慢速燃烧——快速燃烧用 1h 和 5m 窗口、因子 14.4，快速捕获严重故障且避免误报；慢速燃烧用 3d 和 6h 窗口、因子 1，捕获系统退化。
25. Step 5：根据用户选择从 references/promql_templates.md 查找对应 PromQL 模板，window-based SLO 用 Window-Based 模板。
26. Step 5：用 ServiceScope 标签、ServiceLevel 目标和 ServiceLevelIndicator 指标填充模板。
27. Step 5：用 Terraform（google_monitoring_alert_policy）包装，确保 user_labels 块包含 created-with-google-skill = "google-cloud-slo-alert-configuration"。
28. Step 5：呈现 .tf 块并用通俗英语解释其数学含义。
29. Step 5：在最终总结中告知用户告警策略已打上 created-with-google-skill = "google-cloud-slo-alert-configuration" 用户标签以便追踪。
30. Step 5：若未配置通知渠道，必须在最终总结中明确警告用户，并告知可协助设置。

适用边界 · 注意事项

• 不要用于标准（非 SLO）告警策略。
• 当 references 或主要公开文档中没有该资源类型的默认指标时，不要自行拼凑高级指标，应让用户提供自定义指标。
• gcloud 命令因 API 未启用或权限不足失败时，不要排查错误或用 schedule 工具等待，应回退到询问用户。