企业官网建设流程全解析

在 AWS CLI 中创建 Application Signals 服务级别目标（SLO）：create-service-level-objective 完整实战

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli

本文基于 AWS CLI 官方示例 create-service-level-objective.rst，结合仓库内 Application Signals 服务的 API 模型定义 service-2.json，完整讲解aws application-signals create-service-level-objective命令的用法：从基础命令与 SLI 配置文件（sli-config.json）的字段含义，到Goal目标配置、周期型/请求型 SLO 的区别、错误预算与燃尽率机制，直至输出字段的逐项解析和常见错误类型，帮助你在 AWS 账户中实际创建并校验一个可用的 SLO。

一、命令功能概述

create-service-level-objective用于创建一个服务级别目标（Service Level Objective，SLO）。SLO 帮助你确认关键业务操作是否满足客户期望：它通过服务级别指示器（Service Level Indicator，SLI）来衡量应用的性能是否达到你设定的目标水平。

该操作对应 Application Signals 的CreateServiceLevelObjectiveAPI。从 API 模型 service-2.json（API 版本2024-04-15）可以看到，其底层 HTTP 调用为：

POST /slo （响应码 200）

根据 API 模型中对该操作的完整文档描述，其核心能力包括：

• 为服务或操作设置可用性、延迟目标，CloudWatch 会频繁测量该目标是否被突破（breached）；
• SLO 的目标性能质量称为attainment goal（达成目标）；
• 既可以基于 Application Signals 自动发现的服务/操作设置 SLO，也可以针对任意 CloudWatch 指标或产生时间序列的数学表达式设置 SLO；
• 注意：对于 Application Signals 发现的服务操作，必须等该操作向 Application Signals 上报标准指标后，才能为其创建 SLO。

输入与输出结构

从 API 模型看，该操作的输入结构为CreateServiceLevelObjectiveInput，其中唯一必填字段是Name；输出结构CreateServiceLevelObjectiveOutput中唯一必填字段是Slo，即创建成功后的 SLO 完整信息。CLI 参数与 API 字段对应如下：

其中--sli-config与--request-based-sli-config不能同时指定：前者创建周期型 SLO，后者创建请求型 SLO。

二、示例命令与 SLI 配置文件

官方示例创建了如下 SLO（引自 create-service-level-objective.rst）：

aws application-signals create-service-level-objective \ --name "SLOName" \ --description "Description of your SLO" \ --sli-config file://sli-config.json

这里通过file://方式从本地sli-config.json文件传入 SLI 配置。示例文件内容如下：

{ "SliMetricConfig": { "MetricDataQueries": [ { "Id": "m1", "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization", "Dimensions": [ { "Name": "InstanceId", "Value": "i-0e5a1234561522" } ] }, "Period": 60, "Stat": "Average" }, "ReturnData": true } ] }, "MetricThreshold": 200, "ComparisonOperator": "LessThanOrEqualTo" }

SliMetricConfig 字段详解

从 API 模型的ServiceLevelIndicatorMetricConfig结构看，SliMetricConfig除了示例中的MetricDataQueries外还支持以下字段：

• KeyAttributes：当 SLO 关联 Application Signals 采集的指标时必须指定，用于定位指标归属的服务。至少包含Type、Name、Environment三个属性，还可包括ResourceType（Type为Resource/AWS::Resource时使用）和Identifier（资源对象标识）；
• OperationName：SLO 监控某个具体服务操作时指定操作名；
• MetricType：监控 Application Signals 标准指标时指定LATENCY或AVAILABILITY；
• MetricName：使用自定义 CloudWatch 指标时指定指标名；
• Statistic/PeriodSeconds：用于与阈值比较的统计量，以及 SLO 评估所用的周期（秒）；
• MetricSource：标识非 Application Signals 服务资源的指标来源；
• DependencyConfig：通过DependencyKeyAttributes与DependencyOperationName定位依赖项；
• CompositeSliConfig：监控服务多个操作的复合 SLI 配置。

MetricDataQueries 规则

本示例使用的是"自定义 CloudWatch 指标"方式（MetricDataQueries）。从MetricDataQuery的模型文档看，有以下硬性规则：

• Id必填，用于将查询关联到结果，且在MetricDataQueries数组内唯一。合法字符为字母、数字、下划线，首字符必须是小写字母（示例中的m1即符合）；
• 每个MetricDataQuery对象中必须且只能指定Expression（指标数学表达式）或MetricStat（直接指标）之一；
• 单个MetricDataQueries数组最多 20 个MetricDataQuery，其中最多 10 个包含MetricStat、最多 10 个包含Expression；若使用表达式，则恰好一个表达式的ReturnData必须为true，其结果将作为 SLO 依据；
• Period单位为秒：常规分辨率指标最短 60 秒且必须是 60 的倍数；高频指标（StorageResolution为 1 秒）可取 1、5、10、30、60 或 60 的倍数；
• MetricStat内部Metric、Period、Stat均为必填，Metric由Namespace、MetricName、Dimensions组成；Stat可为任意 CloudWatch 统计量或扩展统计量；
• 示例中MetricThreshold: 200与ComparisonOperator: "LessThanOrEqualTo"表示：将 SLI 指标值与阈值 200 比较，比较运算符取自ServiceLevelIndicatorComparisonOperator枚举：GreaterThanOrEqualTo、GreaterThan、LessThan、LessThanOrEqualTo。

Goal 目标配置与默认值

示例命令未显式传入--goal，但输出中却出现了完整的Goal结构，这是因为 API 模型给出了明确的默认值：

RollingInterval需要DurationUnit（枚举：MINUTE、HOUR、DAY、MONTH）和Duration（最小值 1）。若使用日历区间CalendarInterval，则还需要StartTime（第一个区间的开始时间，例如希望"每周一早上 6 点开始"就要指定周一 6 点的开始时间），区间结束后会自动开始下一个。

三、输出解析

示例命令的执行输出为：

{ "Slo": { "Arn": "arn:aws:application-signals:us-east-1:123456789101:slo/SLOName", "Name": "SLOName", "Description": "Description of your SLO", "CreatedTime": "2024-12-27T08:16:09.032000+05:30", "LastUpdatedTime": "2024-12-27T08:16:09.032000+05:30", "Sli": { "SliMetric": { "MetricDataQueries": [ { "Id": "m1", "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization", "Dimensions": [ { "Name": "InstanceId", "Value": "i-0e59876543234522" } ] }, "Period": 60, "Stat": "Average" }, "ReturnData": true } ] }, "MetricThreshold": 200.0, "ComparisonOperator": "LessThanOrEqualTo" }, "EvaluationType": "PeriodBased", "Goal": { "Interval": { "RollingInterval": { "DurationUnit": "DAY", "Duration": 7 } }, "AttainmentGoal": 99.0, "WarningThreshold": 50.0 } } }

逐项说明：

• Arn：SLO 的 ARN，格式为arn:aws:application-signals:<region>:<account-id>:slo/<name>，后续查询、更新、删除或查询预算报告时可用；
• EvaluationType：本例为PeriodBased（周期型）。该字段枚举仅有PeriodBased与RequestBased两种，由你传入的是--sli-config还是--request-based-sli-config决定；
• Goal：未传参时按默认值填充，即 7 天滚动区间、达成目标 99%、告警阈值 50%，与 API 模型文档声明的默认值完全一致；
• Sli.SliMetric：回显你传入的 SLI 指标配置（注意示例输出中的InstanceId值与输入文件略有出入，属于示例文档的示意写法，实际输出会忠实回显你的输入）；
• MetricThreshold在输出中以浮点数200.0表示，AttainmentGoal、WarningThreshold同理，均为 API 模型中的double类型。

四、周期型与请求型 SLO：评估方式与错误预算

创建 SLO 时需要先明确它是周期型还是请求型，二者的评估方式完全不同（引自 API 模型中CreateServiceLevelObjective的官方文档）：

• 周期型（period-based）：在指定总时间区间内划分若干时间段（period）。每个时间段判定应用是否达标，达成率 = 达标周期数 / 总周期数。例如达成目标 99.9% 意味着区间内至少 99.9% 的周期处于达标状态；
• 请求型（request-based）：不预定义时间周期，而是直接度量"达标请求数 / 总请求数"。任意时刻都可以计算截至指定时间戳的达标请求占比，并与目标比较。

错误预算（Error Budget）

创建 SLO 后，可以获取其错误预算报告。错误预算是应用可以"不达标"但仍能满足 SLO 目标的时间或请求量：

• 周期型 SLO 的错误预算初始值由"最多允许多少个周期失败而不违反总目标"决定。每记录一个失败周期，剩余错误预算就减少一次，且同一区间内错误预算永远不会增加。例如"每月 99.95% 的请求在 2000ms 内完成"换算下来每月允许约 21.9 分钟停机；
• 请求型 SLO 的剩余错误预算是动态的，随达标请求占比升降而增减。

错误预算报告可通过同目录下的 batch-get-service-level-objective-budget-report.rst 示例中的batch-get-service-level-objective-budget-report命令获取。

燃尽率（Burn Rate）

通过--burn-rate-configurations可为 SLO 创建燃尽率指标：每项配置指定一个回看窗口（LookBackWindowMinutes，单位分钟）。燃尽率衡量服务消耗错误预算的相对速度——燃尽率恰为 1 表示 SLO 目标将恰好达成。例如指定 60 分钟回看窗口时：

燃尽率 = 回看窗口内的错误率 / (100% - 达成目标百分比)

服务关联角色

执行CreateServiceLevelObjective时，若账户中尚不存在，Application Signals 会自动创建服务关联角色AWSServiceRoleForCloudWatchApplicationSignals，该角色包含xray:GetServiceGraph、logs:StartQuery、logs:GetQueryResults、cloudwatch:GetMetricData、cloudwatch:ListMetrics、tag:GetResources、autoscaling:DescribeAutoScalingGroups等权限，用于支撑 SLO 的指标采集与评估。

五、可能的错误类型

从 API 模型看，CreateServiceLevelObjective声明了以下错误，排查 CLI 报错时可对照：

六、周边操作与验证路径

创建 SLO 只是完整工作流的起点，仓库中同目录的 Application Signals 示例可串联起完整生命周期（均位于 awscli/examples/application-signals/）：

• 查询单个 SLO：get-service-level-objective.rst；
• 列出全部 SLO：list-service-level-objectives.rst；
• 更新 SLO：update-service-level-objective.rst；
• 删除 SLO：delete-service-level-objective.rst；
• 拉取错误预算报告：batch-get-service-level-objective-budget-report.rst。

此外，CLI 的本地调试可用aws application-signals create-service-level-objective help查看 AWS CLI 自动生成的参数帮助；若需了解 SLO 监控对象（服务、操作、依赖）的发现与列表操作，可参考 list-services.rst、list-service-operations.rst 与 list-service-dependencies.rst 等示例。

适用前提小结

• 需要已配置 AWS 凭证与目标区域，且具备 Application Signals / CloudWatch 相关 API 的调用权限；
• 本仓库内置的 Application Signals 服务模型版本为2024-04-15（见 awscli/botocore/data/application-signals/），命令参数以该版本模型为准；
• 对 Application Signals 发现的服务操作创建 SLO 前，需确保该操作已向 Application Signals 上报标准指标；
• --sli-config（周期型）与--request-based-sli-config（请求型）二选一，不可同时使用；使用--create-recommended-slo true时可省略阈值与比较运算符。

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli