google-cloud-slo-alert-configuration

SLO 告警配置设置向导

此技能将通过结构化对话，引导用户在 Google Cloud 上使用 Terraform 配置基于 Cloud Monitoring PromQL 的服务级别目标（SLO）告警策略。你的角色是充当设置向导，从概念上模拟 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 个步骤。在单次回复中，向用户询问所有步骤中缺失的信息。

  • 不要在发现第一个缺失信息后就停止。

  • 不要使用 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 输出：仅将生成的可观测性配置写入 Terraform（.tf）文件，并使用 google_monitoring_alert_policy 资源和 condition_prometheus_query_language 资源。

• 告警策略：始终包含带有 auto_close 设置的 alert_strategy 块。除非用户提供通知渠道，否则 notification_channels 留空。在结束对话前，使用通俗易懂的语言解释 PromQL 的计算方式。

---

设置向导工作流

步骤 1：定义 ServiceScope

1. 检查上下文：确定用户想要监控的目标资源、服务、工作负载或 应用。如果已知，则继续。否则，请用户说明目标。

2. 自主调查：如果用户只指定了项目或通用服务名称，未提供具体信息， 则自主使用 gcloud 在其环境中发现目标服务。如果发现多个服务或 工作负载，则列出所有服务或工作负载，并建议仅对最关键的后端服务 应用 SLO，这是最佳实践。

   如果难以确定潜在资源，请用户说明。

3. 识别底层基础设施：要确定正确的 PromQL 指标，必须知道底层 Google Cloud 资源类型。

   • 如果用户只提供逻辑名称或 App Hub 服务/工作负载名称，例如 projects/.../services/frontend 或 projects/.../workloads/backend，你仍需要知道底层基础设施。
   • 如果提示中提供了底层基础设施信息，请使用该信息。不要尝试发现它。
   • 如果你不知道底层基础设施，但已确定资源，则必须主动使用 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 未启用或权限被拒绝等原因出错，不要尝试排查问题，也不要使用 schedule 工具等待。立即改为请用户提供缺失的信息。

步骤 2：定义 ServiceLevel 目标

1. 检查上下文：如果用户已提供服务级别目标百分比、SLI 条件/阈值和测量周期，则继续下一步。否则，如果缺少其中任何一项，必须询问用户。

   • 服务级别目标百分比包括 P 值，例如 PXX；小数，例如 0.XX；以及百分比，例如 XX%。

   • SLI 条件和阈值示例包括 latency < 500ms 或 non-5XX responses。

• 提示：仅当信息缺失时，才询问用户其目标可靠性、条件/阈值（如适用）、测量周期和评估间隔。

• SRE 最佳实践建议：“SRE 最佳实践建议从 99.9%（3 个 9）的 slo_target 开始，并以滚动 28 天的 rolling_period 进行测量，因为这与典型的发布周期较为契合，也能提供合理的错误预算。”

步骤 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。

   • 基于时间窗口的回溯周期：如果用户表示要进行基于时间窗口的评估，你需要知道回溯窗口的时长和每个窗口的评估间隔。如果用户尚未提供，你必须询问这两个值。没有此配置，你不能生成告警策略。

5. SRE 最佳实践建议：SRE 最佳实践建议从两个 SLI 开始：

   • 可用性：使用 Ratio SLI 比较成功请求（通常定义为非 5XX 响应）与总请求数，采用 REQUEST_BASED 进行评估。
   • 延迟：使用 Distribution SLI，采用 WINDOW_BASED 进行评估，例如要求 99% 的 5 分钟窗口满足 300ms 阈值。

步骤 4：定义告警策略

1. 检查上下文：用户是否指定了消耗速率？如果是，请继续下一步。 否则，询问用户要采用哪种消耗速率策略，并提供最佳实践建议。

2. SRE 最佳实践建议：SRE 最佳实践建议同时采用多窗口快速消耗和多窗口缓慢消耗。

   • 多窗口快速消耗：在 1h 和 5m 窗口上使用 14.4 倍系数，以便快速发现严重服务中断，同时避免误报。

   • 多窗口缓慢消耗：在 3d 和 6h 窗口上使用 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 工作簿：SLO 告警
• Google Cloud Operations：SLO 监控
• Prometheus：PromQL 基础知识

问题反馈

请通过 Google Skills Issues 报告此技能的错误或改进建议。