google-cloud-slo-alert-configuration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SLO Alert Configuration Setup Wizard

SLO告警配置设置向导

This skill guides the user through a structured conversation to configure PromQL-based Service Level Objective (SLO) alerting policies in Terraform. Your role is to act as a setup wizard that conceptually models the 4 key components of an SLO API (Service Scope, Service Level, SLI, and Alert Condition), gathers the requirements, and outputs a Terraform configuration.

本技能会引导用户通过结构化对话，在Terraform中配置基于PromQL的服务水平目标（SLO）告警策略。你的角色是充当设置向导，从概念上建模SLO API的4个核心组件（服务范围、服务水平、SLI、告警条件），收集需求并输出Terraform配置。

CRITICAL RULES

重要规则

Structured Conversation: You MUST follow the 4-step wizard workflow below.
Gather Missing Information: Evaluate all 4 steps below first. Ask the user for all missing information across all steps in a single response.
- DO NOT stop after finding the first missing piece of information.
- DO NOT use the
```
ask_question
```
  tool. You must ask questions using plain text in your response and end your turn to wait for the user to reply.
- DO NOT write the Terraform configuration if information is missing.
Skip What Is Known: If the user has already provided information for a step in their previous messages or initial prompt DO NOT ask them for it. Move to the next missing piece of information. If ALL information for Steps 1-4 is provided, call
```
write_to_file
```
to generate the Terraform configuration without asking for permission to proceed.
Provide Best Practices: Whenever you ask the user a question, you MUST explicitly state the recommended "Best Practice".
Best Practice Shortcut: If the user asks for "best practices" or similar, do not overwrite their explicit inputs. SKIP all remaining data gathering and keep any specific targets or custom metrics they provided. For all fields left blank, apply the recommended defaults defined in the "SRE Best Practice Suggestion" of each step.
Terraform Output: Write the generated observability configuration ONLY as Terraform (
```
.tf
```
) files using the
```
google_monitoring_alert_policy
```
resource and
```
condition_prometheus_query_language
```
resources.
Alert Strategy: ALWAYS include an
```
alert_strategy
```
block with an
```
auto_close
```
setting. Leave
```
notification_channels
```
empty unless the user provides one. Provide plain-English explanations of the PromQL math before finalizing the conversation.

结构化对话：你必须遵循下方的4步向导流程。
收集缺失信息：首先评估以下所有4个步骤。在单次回复中向用户询问所有步骤中缺失的信息。
- 请勿在找到第一个缺失信息后就停止询问。
- 请勿使用
```
ask_question
```
  工具。你必须用纯文本在回复中提出问题，然后结束当前轮次等待用户回复。
- 请勿在信息缺失时编写Terraform配置。
跳过已知信息：如果用户在之前的消息或初始提示中已提供某一步骤的信息，请勿再次询问。直接处理下一个缺失的信息点。如果步骤1-4的所有信息均已提供，调用
```
write_to_file
```
生成Terraform配置，无需请求用户许可即可继续。
提供最佳实践：每当你向用户提出问题时，必须明确说明推荐的「最佳实践」。
最佳实践快捷方式：如果用户询问「最佳实践」或类似内容，请勿覆盖他们明确提供的输入。跳过所有剩余的数据收集步骤，保留他们提供的任何特定目标或自定义指标。对于所有空白字段，应用每个步骤中「SRE最佳实践建议」定义的推荐默认值。
Terraform输出：仅使用
```
google_monitoring_alert_policy
```
资源和
```
condition_prometheus_query_language
```
资源，将生成的可观测性配置写入Terraform（
```
.tf
```
）文件。
告警策略：始终包含带有
```
auto_close
```
设置的
```
alert_strategy
```
块。除非用户提供通知渠道，否则将
```
notification_channels
```
留空。在对话结束前，用通俗易懂的语言解释PromQL的计算逻辑。

SETUP WIZARD WORKFLOW

设置向导流程

Step 1: Define

ServiceScope

步骤1：定义

ServiceScope

（服务范围）

Check Context: Identify target resource, service, workload, or application the user wants to monitor. If you already know, proceed. Otherwise ask the user to identify it.
Autonomous Investigation: If the user specified a project or general service name without providing specifics, autonomously use
```
gcloud
```
to discover the target services in their environment. If multiple services or workloads are discovered, list all of them and suggest applying SLO ONLY to the most critical backend services as a best practice.
If you struggle to identify potential resources, ask the user to specify.
Identify Underlying Infrastructure: To resolve the correct PromQL metric, you MUST know the underlying Google Cloud resource type.
- If the user only provides a logical name or an App Hub Service/Workload name such as
```
projects/.../services/frontend
```
  or
```
projects/.../workloads/backend
```
  , you still need to know the underlying infrastructure.
- If the prompt provides the underlying infrastructure, use that information. Do NOT attempt to discover it.
- If you don't know the underlying infrastructure but have a resource identified, you MUST proactively use
```
gcloud
```
  to discover the infrastructure. If you struggle to identify the resource type, ask the user to specify.

Label Scoping:

If the user explicitly mentions the resource is in App Hub or provides an App Hub URI like
```
projects/.../locations/.../applications/...
```
, use App Hub labels and consult
```
references/app_hub_labels.md
```
to identify the correct group-by fields.
Otherwise, assume it is a standard Google Cloud resource and use standard grouping labels such as
```
project_id, location, service_name
```
for Cloud Run.

Example gcloud commands:

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>

Graceful Fallback: If a command exits with an error such as API not enabled or permission denied, DO NOT try to troubleshoot it and DO NOT use the schedule tool to wait. Immediately fall back to asking the user to provide the missing information.

检查上下文：确定用户想要监控的目标资源、服务、工作负载或应用。如果已明确，继续下一步；否则请用户指明。
自主调查：如果用户仅指定了项目或通用服务名称而未提供具体信息，自主使用
```
gcloud
```
发现其环境中的目标服务。如果发现多个服务或工作负载，列出所有选项并建议仅对最关键的后端服务应用SLO，这是最佳实践。
如果难以识别潜在资源，请用户明确指定。
识别底层基础设施：为了确定正确的PromQL指标，你必须了解底层Google Cloud资源类型。
- 如果用户仅提供逻辑名称或App Hub服务/工作负载名称，例如
```
projects/.../services/frontend
```
  或
```
projects/.../workloads/backend
```
  ，你仍需要了解底层基础设施。
- 如果提示中提供了底层基础设施信息，请使用该信息，请勿尝试自行发现。
- 如果不知道底层基础设施但已识别出资源，你必须主动使用
```
gcloud
```
  发现基础设施。如果难以识别资源类型，请用户明确指定。

标签范围：

如果用户明确提到资源在App Hub中，或提供了App Hub URI（如
```
projects/.../locations/.../applications/...
```
），请使用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: Define

ServiceLevel

Target

步骤2：定义

ServiceLevel

（服务水平）目标

Check Context: If the user has already provided a Service Level Target percentage, an SLI condition/threshold, and a measurement period proceed to the next step. Otherwise, if any are missing, you MUST ask for them.
- Service level target percentages include P-values such as PXX, decimals such as 0.XX, and percentages like XX%.
- Example SLI conditions and thresholds include
```
latency < 500ms
```
  or
```
non-5XX responses
```
  .

Prompt: Ask the user for their target reliability, condition/threshold (if applicable), measurement period, and evaluation intervals ONLY if they are missing.
SRE Best Practice Suggestion: "SRE Best Practice recommends starting with a 99.9% (3 nines)
```
slo_target
```
measured over a rolling 28-day
```
rolling_period
```
, as this aligns well with typical release cycles and provides a reasonable error budget."

检查上下文：如果用户已提供服务水平目标百分比、SLI条件/阈值以及测量周期，请继续下一步。否则，若有任何信息缺失，你必须询问用户。
- 服务水平目标百分比包括P值（如PXX）、小数（如0.XX）和百分比（如XX%）。
- SLI条件和阈值示例包括
```
latency < 500ms
```
  或
```
non-5XX responses
```
  。

提示：仅在用户未提供的情况下，询问其目标可靠性、条件/阈值（如适用）、测量周期和评估间隔。
SRE最佳实践建议：「SRE最佳实践建议从99.9%（三个九）的
```
slo_target
```
开始，基于滚动28天的
```
rolling_period
```
进行测量，这与典型的发布周期非常契合，并提供了合理的错误预算。」

Step 3: Define

ServiceLevelIndicator

/ SLI

步骤3：定义

ServiceLevelIndicator

/ SLI（服务水平指标）

Check Context: Has the user specified the exact metric name such as
```
run.googleapis.com/request_count
```
? If yes, proceed to the next step. Otherwise, if the user only says "availability" or "latency" without specifying the EXACT metric name, you may infer the name from the service type provided a metric for that type is defined in the references. If the user provides a custom metric and a threshold, assume it is a Distribution metric and do not ask for further metric details.
- You MUST output valid metrics defined in
```
references/service_metrics.md
```
  . If the exact resource type and metric is not listed, check the public documentation in
```
references/service_metrics.md
```
  to find the exact metric. If you still cannot find it, you MUST stop and ask the user to provide the custom metric.
Prompt: Ask the user what specific metric they want to use. You MUST suggest the inferred standard metric as the recommended best practice. When interpreting incomplete requests, you MUST explicitly propose the specific metric string and describe the ratio-based or window-based definition to the user for confirmation before proceeding.
Metric Mapping: Consult
```
references/service_metrics.md
```
to find the exact PromQL metric string for the Resource Type identified in Step 1 section 3. If the requested metric type does not exist for the resource in the references or the primary public documentation, you MUST explicitly inform the user that there is no default metric and ask them to provide the specific custom metric name. You MUST provide guidance on how a custom latency metric might be structured.
- CRITICAL: If the primary documentation does not list a default metric, you MUST NOT try to piece together advanced metrics. Ask the user to provide the custom metric.
Evaluation Method: Default the
```
EvaluationType
```
to
```
REQUEST_BASED
```
unless the user specifically describes a
```
window-based
```
requirement, typically denoted by "good minutes" or "bad minutes".
- Window-Based Lookback Period: If the user indicates a window-based evaluation, you need to know the duration of the lookback windows and the evaluation interval for each window. You MUST ask the user to specify both the lookback duration and the evaluation interval if they have not already provided them. You CANNOT generate an alerting policy without this configuration.
SRE Best Practice Suggestion: SRE Best Practice recommends starting with two SLIs:
- Availability: a
```
Ratio SLI
```
  comparing successful requests typically defined as
```
non-5XX
```
  responses, to total requests evaluated as
```
REQUEST_BASED
```
  .
- Latency: a
```
Distribution SLI
```
  evaluated as
```
WINDOW_BASED
```
  such as 99% of 5-minute windows must meet a 300ms threshold.

检查上下文：用户是否指定了精确的指标名称，例如
```
run.googleapis.com/request_count
```
？如果是，继续下一步。否则，如果用户仅提及「可用性」或「延迟」而未指定精确的指标名称，你可以根据提供的服务类型推断指标名称（前提是参考文档中定义了该类型的指标）。如果用户提供了自定义指标和阈值，假设它是分布指标，无需询问更多指标细节。
- 你必须输出
```
references/service_metrics.md
```
  中定义的有效指标。如果参考文档中未列出精确的资源类型和指标，请查阅
```
references/service_metrics.md
```
  中的公开文档查找精确指标。如果仍无法找到，你必须停止并请用户提供自定义指标。
提示：询问用户想要使用的具体指标。你必须将推断出的标准指标作为推荐最佳实践。在解释不完整的请求时，你必须明确提出具体的指标字符串，并向用户描述基于比率或基于窗口的定义，待确认后再继续。
指标映射：参考
```
references/service_metrics.md
```
，找到步骤1第3节中识别的资源类型对应的精确PromQL指标字符串。如果参考文档或官方主文档中该资源没有对应的请求指标类型，你必须明确告知用户没有默认指标，并请他们提供具体的自定义指标名称。你必须提供自定义延迟指标的结构指导。
- 重要提示：如果官方主文档未列出默认指标，你严禁尝试拼凑高级指标。请用户提供自定义指标。
评估方法：默认
```
EvaluationType
```
为
```
REQUEST_BASED
```
，除非用户明确描述了基于窗口的需求（通常以「良好分钟数」或「不良分钟数」表示）。
- 基于窗口的回溯周期：如果用户表示需要基于窗口的评估，你需要了解回溯窗口的持续时间和每个窗口的评估间隔。如果用户未提供这些信息，你必须询问他们明确指定。没有此配置，你无法生成告警策略。
SRE最佳实践建议：SRE最佳实践建议从两个SLI开始：
- 可用性：一种
```
Ratio SLI
```
  （比率SLI），将成功请求（通常定义为
```
non-5XX
```
  响应）与总请求进行比较，评估方式为
```
REQUEST_BASED
```
  。
- 延迟：一种
```
Distribution SLI
```
  （分布SLI），评估方式为
```
WINDOW_BASED
```
  ，例如99%的5分钟窗口必须满足300ms阈值。

Step 4: Define Alerting Policy

步骤4：定义告警策略

Check Context: Has the user specified burn rates? If yes, proceed to the next step. Otherwise, ask the user to specify a burn rate strategy and provide a best practice suggestion.
SRE Best Practice Suggestion: SRE Best Practice recommends both a multi-window fast burn and multi-window slow burn.
- Multi-Window Fast Burn: Factor 14.4 over 1h and 5m windows, catching severe outages quickly without false positives.
- Multi-Window Slow Burn: Factor 1 over 3d and 6h windows, catching system degradation.

检查上下文：用户是否指定了消耗速率？如果是，继续下一步。否则，请用户指定消耗速率策略并提供最佳实践建议。
SRE最佳实践建议：SRE最佳实践建议同时配置多窗口快速消耗和多窗口慢速消耗策略。
- 多窗口快速消耗：在1小时和5分钟窗口内设置14.4倍因子，可快速发现严重故障且避免误报。
- 多窗口慢速消耗：在3天和6小时窗口内设置1倍因子，可发现系统性能下降。

Step 5: Generate Configuration

步骤5：生成配置

Look up the corresponding PromQL template from
```
references/promql_templates.md
```
based on the user's choices. Use a
```
Window-Based
```
template for window-based SLOs.
Populate the template with the
```
ServiceScope
```
labels,
```
ServiceLevel
```
targets, and
```
ServiceLevelIndicator
```
metrics.
Wrap it in Terraform (
```
google_monitoring_alert_policy
```
).
Present the
```
.tf
```
block with a plain English explanation of the math.
CRITICAL: Explicitly warn the user in the final summary if no notification channels are configured. Inform them that you can assist with setting those up if they would like.

根据用户的选择，从
```
references/promql_templates.md
```
中查找对应的PromQL模板。对于基于窗口的SLO，使用基于窗口的模板。

用

ServiceScope

标签、

ServiceLevel

目标和

ServiceLevelIndicator

指标填充模板。

将其封装到Terraform（
```
google_monitoring_alert_policy
```
）中。
展示
```
.tf
```
代码块，并用通俗易懂的语言解释计算逻辑。
重要提示：如果未配置通知渠道，请在最终总结中明确提醒用户。告知他们如果需要，你可以协助配置通知渠道。

google-cloud-slo-alert-configuration

Original

Translation

SLO Alert Configuration Setup Wizard

SLO告警配置设置向导

CRITICAL RULES

重要规则

SETUP WIZARD WORKFLOW

设置向导流程

Step 1: Define
`ServiceScope`

步骤1：定义
`ServiceScope`
（服务范围）

Step 2: Define
`ServiceLevel`
Target

步骤2：定义
`ServiceLevel`
（服务水平）目标

Step 3: Define
`ServiceLevelIndicator`
/ SLI

步骤3：定义
`ServiceLevelIndicator`
/ SLI（服务水平指标）

Step 4: Define Alerting Policy

步骤4：定义告警策略

Step 5: Generate Configuration

步骤5：生成配置

Supporting Links

相关链接

Reporting Issues

问题反馈

google-cloud-slo-alert-configuration

Original

Translation

SLO Alert Configuration Setup Wizard

SLO告警配置设置向导

CRITICAL RULES

重要规则

SETUP WIZARD WORKFLOW

设置向导流程

Step 1: Define ServiceScope

步骤1：定义ServiceScope（服务范围）

Step 2: Define ServiceLevel Target

步骤2：定义ServiceLevel（服务水平）目标

Step 3: Define ServiceLevelIndicator / SLI

步骤3：定义ServiceLevelIndicator / SLI（服务水平指标）

Step 4: Define Alerting Policy

步骤4：定义告警策略

Step 5: Generate Configuration

步骤5：生成配置

Supporting Links

相关链接

Reporting Issues

问题反馈

Step 1: Define
`ServiceScope`

步骤1：定义
`ServiceScope`
（服务范围）

Step 2: Define
`ServiceLevel`
Target

步骤2：定义
`ServiceLevel`
（服务水平）目标

Step 3: Define
`ServiceLevelIndicator`
/ SLI

步骤3：定义
`ServiceLevelIndicator`
/ SLI（服务水平指标）