服务级别目标（SLO）配置示例
示例1：包含延迟蓝图的应用程序服务层目标
目标： 确保在固定的一周时间内，"机器人商店"应用程序90%的调用平均延迟优于100毫秒。
SLO的配置如下：
实体：机器人商店应用程序
- 作用域：
- 边界：所有服务
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
指示符：
- 蓝图：延迟
- 类型：时间
- 聚合：平均值
- 阈值：100 毫秒
目标：
- SLO目标：90%
- 时间窗口类型：滚动
- 时间窗口长度：1周
场景 ：假设服务层目标（SLO）在为期一周的SLO时间窗口内（ 自2025-03- 04起）存在400分钟异常时段（即400分钟内平均延迟超过100毫秒）：
该SLO的误差预算将按以下方式计算：
- 时间段x中的分钟数 × (1 - SLO目标百分比)
- 时间窗口总分钟数：1周内24×60×7分钟=10080分钟
- SLO目标百分比：90%（ 0.9 ）
- 误差预算：10080 × (1 - 0. 0.9 ) = 1008 分钟
SLO状态将按以下方式计算：
- SLO状态 = 100% × (时间窗口内总分钟数 - 时间窗口内异常分钟数) / 时间窗口内总分钟数
- 100% × (10080总分钟数 - 400无效分钟数) / 10080总分钟数 = 96.03 %
示例 2：基于事件的可用性蓝图的网站 SLO
目标： 确保在2025年3月1日开始的固定4天周期内，对演示网站购物车页面（ cart.html ）的 HTTP 请求能达到95%的可用性。
SLO的配置如下：
- 实体：演示网站
- 信标： HTTP 请求
- 自定义筛选器：位置 > 页面名称 = 购物车
- 指示符：
- 蓝图：可用性
- 类型：事件计数（正确判断与错误判断的总计数）
- 目标：
- SLO目标：95%
- 时间窗口类型：固定
- 时间窗口长度：4天
- 开始时间：2025年3月1日 0:00
场景 ：假设在2025年3月1日开始的SLO时间窗口内，存在234次成功的 HTTP 请求和11次失败的 HTTP 请求：
该SLO的误差预算将按以下方式计算：
- 活动：
- 有效事件计数：234个信标
- 不良事件计数：11个信标
- 总事件计数：234 + 11 = 245 个信标
- SLO目标百分比：95%（ 0.95 ）
- 误差预算：245 × (1 - 0.95 ) = 12 个信标
- 剩余错误预算：12 - 11 = 1 个信标
- 剩余误差预算百分比：100% * (12 - 11) / 12 = 8.33 %
SLO状态将按以下方式计算：
- SLO状态 = 100% × 时间窗口内有效事件总数 / 时间窗口内事件总数
- 100% × 234 个信标 / 245 个信标 = 95.5 %
示例 3：基于流量蓝图的合成监控
目标： 确保在2025年3月18日开始的固定周期内，每分钟运行3次合成监控测试（购物车、首页和产品列表页），测试频率需稳定维持在99%以上。
SLO的配置如下：
实体：
- 购物车测试
- 主页测试
- 产品列表页面测试
指示符：
- 蓝图：流量
- 阈值：> 每分钟15个结果
目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1周
- 开始时间：2025年3月18日 0:00
场景 ：假设SLO 在2025-03-18 开始的SLO时间窗口内，存在21分钟期间合成测试运行次数少于15次的情况：
该SLO的误差预算将按以下方式计算：
- 时间段x中的分钟数 × (1 - SLO目标百分比)
- 总分钟数：1周内24×60×7分钟=10080分钟
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：10080 × (1 - 0. 0.99 ) = 101分钟
- 剩余容差：101 - 21 = 80
- 剩余误差预算百分比：100% * (101 - 21) / 101 = 79.21 %
SLO状态将按以下方式计算：
- SLO状态 = 100% × (时间窗口内总分钟数 - 时间窗口内异常分钟数) / 时间窗口内总分钟数
- 100% × (10080总分钟数 - 21无效分钟) / 10080总分钟数 = 99.8 %
示例 4：使用标签过滤器基于事件的可用性进行合成监控 SLO
目标： 确保在为期1天的固定时间内，合成结账流程测试的可用性至少达到99%。
SLO的配置如下：
- 实体：合成
- 作用域：
- 筛选方法：基于筛选条件
- 标签过滤表达式： synthetic.testName startsWith "checkout"
- 指示符：
- 蓝图：可用性
- 类型：事件计数（良好测试结果与不良测试结果的总数）
- 良好事件： call.erroneous = false
- 错误事件： call.erroneous = true
- 目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1天
- 开始时间：2026年1月18日 0:00
场景 ：假设在始于 2026-01-18 的 SLO 时间窗口内，共有 14,850 次成功的合成测试执行和 150 次失败的执行。
该SLO的误差预算将按以下方式计算：
- 活动：
- 有效事件数：14,850 次测试执行
- 失败事件计数：150次测试执行
- 事件总数：14,850 + 150 = 15,000 次执行
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：15,000 × (1 − 0.99 ) = 150 次执行
- 剩余误差预算：150 − 150 = 0 次执行
- 剩余误差预算百分比：100% × (0 / 150) = 0%
SLO状态将按以下方式计算：
- SLO 状态 = 100% × 正常事件总数 / 事件总数
- 100% × 14,850 / 15,000 = 99%
示例 5：使用自定义蓝图的应用 SLO
目标： 确保在1天滚动周期内，"机器人商店"应用程序98%的调用不会返回 HTTP 状态码400。
SLO的配置如下：
实体：机器人商店应用程序
- 作用域：
- 边界：所有服务
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
指示符：
- 蓝图：定制
- 类型：事件计数（正确判断与错误判断的总计数）
- 良好过滤器： HTTP 状态码 ≠ 400
- 错误过滤器： HTTP 状态码 = 400
目标：
- SLO目标：98%
- 时间窗口类型：滚动
- 时间窗口长度：1天
场景 ：假设在2025年3月10日开始的为期一天的SLO时间窗口内，该SLO共处理了25000通有效通话和200通无效通话：
该SLO的误差预算将按以下方式计算：
- 活动：
- 有效事件计数：25000次调用
- 不良事件计数：200次呼叫
- 总事件计数：25000 + 200 = 25200 次调用
- SLO目标百分比：98%（ 0.98 ）
- 误差预算：25200 × (1 - 0. 0.98 ) = 504 次调用
- 剩余错误预算：504 - 200 = 304 次调用
- 剩余误差预算百分比：100% * (504 - 200) / 504 = 60.32 %
SLO状态将按以下方式计算：
- SLO状态 = 100% × 时间窗口内有效事件总数 / 时间窗口内事件总数
- 100% × 25000 次呼叫 / 25200 次呼叫 = 99.2 %
示例 6：基于事件的延迟蓝图的应用 SLO
目标： 确保在固定的两周周期内，"机器人商店"应用程序92%的呼叫延迟优于100毫秒。
SLO的配置如下：
实体：机器人商店应用程序
- 作用域：
- 边界：所有服务
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
指示符：
- 蓝图：延迟
- 类型：事件计数（正确判断与错误判断的总计数）
- 判断正确：延迟 < 100 毫秒
- 错误判断：延迟 ≥ 100 毫秒
目标：
- SLO目标：92%
- 时间窗口类型：固定
- 时间窗口长度：2周
- 开始时间：2025年3月10日 0:00
场景 ：假设在从2025年3月10日开始的为期两周的SLO时间窗口内，SLO系统共处理了50000次有效呼叫和1000次无效呼叫：
该SLO的误差预算将按以下方式计算：
- 活动：
- 有效事件计数：50000次调用
- 不良事件计数：1000次呼叫
- 总事件计数：50000 + 1000 = 51000 次调用
- SLO目标百分比：92%（ 0.92 ）
- 误差预算：51000 × (1 - 0. 0.92 ) = 4080 次调用
- 剩余错误预算：4080 - 1000 = 3080 次调用
- 剩余误差预算百分比：100% * (4080 - 1000) / 4080 = 75.49 %
SLO状态将按以下方式计算：
- SLO状态 = 100% × 时间窗口内有效事件总数 / 时间窗口内事件总数
- 100% × 50000 次呼叫 / 51000 次呼叫 = 98.04 %
示例 7：基于时间可用性蓝图的网站 SLO
目标： 确保在滚动周期为3天内， HTTP 对Demo网站的请求能达到92%的可用性，且错误率低于5%。
SLO的配置如下：
- 实体：演示网站
- 信标： HTTP 请求
- 指示符：
- 蓝图：可用性
- 类型：时间
- 错误率阈值：5%
- 目标：
- SLO目标：92%
- 时间窗口类型：滚动
- 时间窗口长度：3天
场景 ：假设SLO在为期3天的SLO时间窗口内（自 2025-03- 05起）存在200分钟异常时段（即200分钟的平均误差率超过5%）：
该SLO的误差预算将按以下方式计算：
- 时间段x中的分钟数 × (1 - SLO目标百分比)
- 时间窗口总分钟数：3天内24×60×3分钟=4320分钟
- SLO目标百分比：92%（ 0.92 ）
- 误差预算：4320 × (1 - 0. 0.92 ) = 346 分钟
SLO状态将按以下方式计算：
- SLO状态 = 100% × (时间窗口内总分钟数 - 时间窗口内异常分钟数) / 时间窗口内总分钟数
- 100% × (4320总分钟数 - 200无效分钟数) / 4320总分钟数 = 95.37 %
示例 8：基于时间饱和度的基础设施 SLO 蓝图（CPU）
目标： 确保生产主机在7天滚动周期内，99%的时间内CPU利用率保持在75%以下。
- 实体：基础设施
- 基础设施类型：主机
- 标签过滤器表达式：
availabilityZone = "us-east-1"
- 指示符：
- 蓝图：饱和度
- 类型：时间
- 度量：
cpu.used - 聚合：平均值
- 运算符：≥
- 阈值：75%
- 目标：
- SLO目标：99%
- 时间窗口类型：滚动
- 时间窗口长度：7天
- 时间段x中的分钟数 × (1 - SLO目标百分比)
- 时间窗口总分钟数：1周内24×60×7分钟=10080分钟
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：10080 × (1 - 0. 0.99 ) = 101分钟
- SLO状态 = 100% × (时间窗口内总分钟数 - 时间窗口内异常分钟数) / 时间窗口内总分钟数
- 100% × (10080总分钟数 - 25无效分钟) / 10080总分钟数 = 99.75 %
示例 9：基于事件的饱和蓝图的基础设施 SLO（内存）
目标： 确保数据库服务器内存使用率在1天滚动周期内， 99.9 %的指标快照中保持低于85%。
- 实体：基础设施
- 基础设施类型：主机
- 标签过滤器表达式：
host.fqdn contains "company-name" AND availabilityZone = "us-east-1"
- 指示符：
- 蓝图：饱和度
- 类型：事件计数（良好指标快照与不良指标快照的总计数）
- 度量：
memory.used - 运算符：≥
- 阈值：85%
- 目标：
- SLO 目标： 99.9 %
- 时间窗口类型：滚动
- 时间窗口长度：1天
- 活动：
- 优质活动计数：8,640张快照
- 不良事件计数：5次快照
- 总事件计数：8,640 + 5 = 8,645 个快照
- SLO目标百分比： 99.9 %（ 0.999 ）
- 误差预算：8,645 × (1 - 0. 0.999 ) = 8.65 个快照（四舍五入为9）
- 剩余错误预算：9 - 5 = 4 个快照
- 剩余误差预算百分比：100% * (9 - 5) / 9 = 44.44 %
- SLO状态 = 100% × 时间窗口内有效事件总数 / 时间窗口内事件总数
- 100% × 8,640 个快照 / 8,645 个快照 = 99.94 %
示例 10：针对 Kubernetes 集群的自定义蓝图的基础设施 SLO
目标： 确保生产环境的 Kubernetes 集群在7天滚动周期内， 99.9 %的时间内至少保持6个可用节点。
- 实体：基础设施
- 基础设施类型： Kubernetes 集群
- 标签过滤器表达式：
kubernetes.cluster.name = "prod-cluster"
- 指示符：
- 蓝图：定制
- 类型：事件计数（良好指标快照与不良指标快照的总计数）
- 良好事件： nodes.count >= 6
- 不良事件： nodes.count <6
- 目标：
- SLO 目标： 99.9 %
- 时间窗口类型：滚动
- 时间窗口长度：7天
- 活动：
- 优质事件计数：60,400张快照
- 不良事件计数：80个快照
- 总事件计数：60,400 + 80 = 60,480 个快照
- SLO目标百分比： 99.9 %（ 0.999 ）
- 误差预算：60,480 × (1 - 0. 0.999 ) = 60.48 个快照（四舍五入为60）
- 剩余容差：60 - 80 = -20 个快照（超出限制）
- 剩余容差百分比：100% × (-20 / 60) = -33.33 %（超额消耗）
- SLO状态 = 100% × 时间窗口内有效事件总数 / 时间窗口内事件总数
- 100% × 60,400 张快照 / 60,480 张快照 = 99.87 %
示例 11：带时区绑定的 SLO 行为
目标： 确保 SLO 时间窗口与日历时间一致，并且每天保持不变（即使在夏令时调整期间也是如此），以确保报告的准确性和一致性。 请确保 SLO 的计算与特定时区相关联，因为夏令时转换会根据配置的时区影响时间窗口。
- 实体：机器人商店应用程序
- 作用域：
- 边界：所有服务
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
- 作用域：
- 指示符：
- 蓝图：延迟
- 类型：时间
- 聚合：平均值
- 阈值：100 毫秒
- 目标：
- SLO目标：90%
- 时间窗口类型：固定
- 时间窗口长度：3天
- 绑定时区：启用
- 时区：Europe/Berlin
示例 12：与团队关联的学习成果目标
目标： 将该学习成果（SLO）分配给与该用户关联的一个或多个团队。 随后，这些团队关联将用于实施访问限制。
实体：机器人商店应用程序
- 作用域：
- 边界：所有服务
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
- 作用域：
指示符：
- 蓝图：延迟
- 类型：时间
- 聚合：平均值
- 阈值：100 毫秒
目标：
- SLO目标：90%
- 时间窗口类型：滚动
- 时间窗口长度：1周
详细信息：
- 名称：示例学习成果
- 标签（可选）：示例标签
- 团队：团队1，团队2
示例 13：月中创建的日历月 SLO
目标：确保在日历月期间，99%的"支付服务"应用程序调用平均延迟低于200毫秒，该服务水平目标（SLO）于1月15日创建。
SLO的配置如下：
- 实体：支付服务应用程序
- 作用域：
- 边界：来电
- 包含内部调用：false
- 包含合成调用：false
- 服务：所有服务
- 终端点：所有终端点
- 作用域：
- 指示符：
- 蓝图：延迟
- 类型：时间
- 聚合：平均值
- 阈值：200 毫秒
- 目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1个日历月
- 绑定时区：启用
- 时区：America/New_York
- 开始时间：2025年1月15日 00:00
场景 ：该SLO于2025年1月15日创建。 日历月SLO与月份边界一致，若在月中创建，则会形成部分的第一时段。
- 时长：17天（1月15日至1月31日）
- 总分钟数：17 × 24 × 60 = 24,480 分钟
- 误差预算：24,480 × (1 - 0. 0.99 ) = 245 分钟
- 记录的错误时间：30分钟
- SLO状态：100% × (24,480 - 30) / 24,480 = 99.88 %
- 剩余误差预算：245 - 30 = 215 分钟
- 时长：28天（完整日历月）
- 总分钟数：28 × 24 × 60 = 40,320 分钟
- 误差预算：40,320 × (1 - 0. 0.99 ) = 403 分钟
- 记录的错误时间：50分钟
- SLO状态：100% × (40,320 - 50) / 40,320 = 99.88 %
- 剩余容差：403 - 50 = 353 分钟
- 时长：31天（完整日历月）
- 总分钟数：31 × 24 × 60 = 44,640 分钟
- 误差预算：44,640 × (1 - 0.99 ) = 446 分钟
示例 14：在当月第一天创建日历月 SLO
目标：确保 HTTP 对"电子商务网站"的请求在日历月期间达到95%的可用性，服务水平目标（SLO）于3月1日创建。
SLO的配置如下：
- 实体：电子商务网站
- 信标： HTTP 请求
- 自定义过滤器：无
- 指示符：
- 蓝图：可用性
- 类型：时间
- 错误率阈值：5%
- 目标：
- SLO目标：95%
- 时间窗口类型：固定
- 时间窗口长度：1个日历月
- 绑定时区：启用
- 时区：UTC
- 开始时间：2025年3月1日 00:00
场景 ：该SLO创建于2025年3月1日（当月首日）。 所有测量周期均为完整的日历月。
- 时长：31天（完整日历月）
- 总分钟数：31 × 24 × 60 = 44,640 分钟
- 误差预算：44,640 × (1 - 0. 0.95 ) = 2,232 分钟
- 记录的无效分钟数：400分钟
- SLO状态：100% × (44,640 - 400) / 44,640 = 99.10 %
- 剩余误差预算：2,232 - 400 = 1,832 分钟
- 时长：30天（完整日历月）
- 总分钟数：30 × 24 × 60 = 43,200 分钟
- 误差预算：43,200 × (1 - 0. 0.95 ) = 2,160 分钟
- 记录的无效分钟数：350分钟
- SLO状态：100% × (43,200 - 350) / 43,200 = 99.19 %
- 剩余误差预算：2,160 - 350 = 1,810 分钟
示例 15：采用基于事件的延迟蓝图的移动应用 SLO（Android 版 HTTP 延迟）
本示例演示了如何配置一个移动应用 SLO，该 SLO 使用基于事件的延迟蓝图，以确保在 1 天的固定时间段内，来自 Android 设备发往购物车服务的 HTTP 请求中，99% 的请求延迟小于 200 毫秒。
配置
SLO 的配置如下：
- 实体：移动应用
- 筛选方法：基于筛选条件
- 标签过滤表达式：
mobileBeacon.platform EQUALS "Android"
- 指示符：
- 蓝图：延迟
- 信标类型： HTTP 请求
- Beacon 自定义过滤器：
mobileBeacon.http.url EQUALS "https://rs-cart/add-cart" - 度量：
httpLatency - 类型：事件计数（正常信标与异常信标的总计数）
- 阈值：200 毫秒
- 运算符：
>
- 目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1天
- 时区：UTC
- 开始时间：2026-02-18 00:00
方案分析
在从 2026-02-18 开始的 SLO 时间窗口内，共有 19,800 次延迟小于 200 毫秒的 HTTP 请求，以及 200 次延迟大于或等于 200 毫秒的 HTTP 请求。
误差预算计算
误差预算的计算方法如下：
- 有效事件数：19,800 个信标
- 异常事件计数：200 个信标
- 事件总数：19,800 + 200 = 20,000 个信标
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：20,000 × (1 - 0.99 ) = 200 个信标
- 剩余误差预算：200 - 200 = 0 个信标
- 剩余误差预算百分比：100% × (0 / 200) = 0%
SLO状态计算
SLO 状态的计算方法如下：
SLO 状态 = 100% × 时间窗口内合格事件总数 / 时间窗口内事件总数
100% × 19,800 个信标 / 20,000 个信标 = 99%
示例 16：采用基于时间的可用性蓝图的移动应用 SLO（受崩溃影响的会话）
本示例演示了如何配置一个移动应用 SLO，该 SLO 使用基于时间的可用性蓝图，以确保在固定的一日历月内，99% 的时间内，“零售”移动应用因崩溃而受影响的会话数保持在每分钟 15 次以下。
配置
SLO 的配置如下：
- 实体：移动应用
- 筛选方法：单个移动应用
- 移动应用：零售移动应用
- 指示符：
- 蓝图：可用性
- 信标类型：崩溃
- 度量：
crashAffectedSessionCount - 类型：基于时间
- 聚合：SUM
- 阈值：15
- 运算符：
>
- 目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1个日历月
- 时区：Europe/Dublin
- 开始时间：2026-02-01 00:00
方案分析
在从 2026-02-01 开始的 SLO 时间窗口内，该 SLO 在该日历月内出现了 120 分钟的异常情况，这意味着有 120 分钟内受崩溃影响的会话数量超过了 15。
误差预算计算
误差预算的计算方法是：该时间段内的分钟数乘以（1 - SLO目标百分比）：
- 时间窗口内的总分钟数：28 × 24 × 60 = 40,320 分钟（2月）
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：40,320 × (1 - 0. 0.99 ) = 403 分钟
- 剩余误差预算：403 - 120 = 283 分钟
- 剩余误差预算百分比：100% × (283 / 403) = 70.22 %
SLO状态计算
SLO 状态的计算方法如下：
SLO 状态 = 100% × (时间窗口内的总分钟数 - 时间窗口内的异常分钟数) / 时间窗口内的总分钟数
100% × (40,320 总分钟数 - 120 不良分钟数) / 40,320 总分钟数 = 99.70 %
示例 17：采用自定义蓝图的移动应用 SLO（ HTTP 请求快速且视图切换流畅）
本示例演示了如何配置一个移动应用 SLO，该 SLO 使用自定义（高级）蓝图，以确保在固定的一日历月内，电子商务移动应用中 99% 的用户交互都能获得快速的 HTTP API 响应（小于 500 毫秒）和流畅的视图切换（小于 300 毫秒）。
配置
SLO 的配置如下：
- 实体：移动应用
- 筛选方法：单个移动应用
- 移动应用：电商移动应用、购物移动应用
- 指示符：
- 蓝图：自定义（高级）
- 类型：事件计数（正常信标与异常信标的总计数）
- 好的活动：
- 信标类型： HTTP 请求
- 度量：
httpLatency - 阈值：500 毫秒
- 运算符：
<
- 坏事：
- 信标类型：查看更改
- 度量：
viewChangeDuration - 阈值：300 毫秒
- 运算符：
>
- 目标：
- SLO目标：99%
- 时间窗口类型：固定
- 时间窗口长度：1个日历月
- 时区：UTC
- 开始时间：2026-02-01 00:00
方案分析
在从 2026-02-01 开始的 SLO 时间窗口内，共有 85,000 次 HTTP 请求符合“良好”标准（延迟小于 500 毫秒），另有 1,500 次视图变更被归类为“不良”（viewChangeDuration 延迟大于 300 毫秒）。
误差预算计算
误差预算的计算方法如下：
- 有效事件数：85,000个信标
- 异常事件计数：1,500 个信标
- 事件总数：85,000 + 1,500 = 86,500 个信标
- SLO目标百分比：99%（ 0.99 ）
- 误差预算：86,500 × (1 - 0.99 ) = 865 个信标
- 剩余误差预算：865 - 1,500 = -635 个信标（超出）
- 剩余误差预算百分比：100% × (-635 / 865) = -73.41 %（超支）
SLO状态计算
SLO 状态的计算方法如下：
SLO 状态 = 100% × 时间窗口内合格事件总数 / 时间窗口内事件总数
100% × 85,000 个信标 / 86,500 个信标 = 98.27 %
自定义蓝图行为
此自定义蓝图展示了在不同交互类型下监控用户体验的灵活性。 “良好事件”的定义是基于快速的响应（httpLatencyHTTP API ），即从 HTTP 请求信标开始计时，响应时间少于 500 毫秒；而“不良事件”则是视图切换缓慢（viewChangeDuration 从视图变化信标开始计时，响应时间超过 300 毫秒）。 该方法通过利用不同类型信标的指标，同时监控后端 API 的性能和前端导航的流畅度，而这无法通过单一的标准蓝图来实现。 不符合“良好”或“不良”标准的事件将被排除在 SLO 计算之外。
服务级别智能警报配置示例
示例 1：服务级别智能警报，用于监控 SLO 的状态
目标： 当自动售货机可靠性服务级别目标配置状态低于90%时，触发警报并报告问题。
“服务级别智能警报”的配置如下：
Rule:
Alert Type: Service Levels Objective
Metric: Status
Threshold:
Operator: <
value: 0.90
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
完成“智能警报”配置后，系统将开始监控自动售货机可靠性 SLO 配置的状态。
场景：监控与事件触发
SLO跌破阈值
- 假设自动售货机可靠性服务水平目标（SLO）降至89%，低于90%的设定阈值。
- 当时间阈值设置为10分钟时，系统将在整个10分钟窗口期内保持等待状态，之后才会采取任何行动。
- 若系统可用性指标（SLO）在10分钟后仍低于90%，系统将触发事件并提交问题报告。
SLO返回值超过阈值
- 若经过一段时间后，SLO状态恢复并回升至90%以上，系统将持续进行监控。
- 然而，如果状态持续保持在90%以上，系统将等待5分钟的到期时间阈值。
- 若SLO在整整5分钟内持续高于90%，该事件将自动关闭。
示例 2：用于监控 SLO 错误预算的服务级别智能警报
目标： 当自动售货机可靠性SLO配置的错误预算消耗百分比超过50%时，触发警报并报告问题。
“服务级别”智能警报的配置如下：
Rule:
Alert Type: Error Budget
Metric: Burned Percentage
Threshold:
Operator: >
value: 0.50
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
完成智能警报配置后，系统将开始监控自动售货机可靠性 SLO 配置中的错误预算消耗百分比。
场景：监控与事件触发
误差预算消耗超过50%
- 假设误差预算消耗超过50%。
- 当时间阈值设置为10分钟时，系统将在等待满10分钟后才采取任何行动。
- 若错误预算消耗在10分钟后仍高于50%，系统将触发事件并提交问题报告。
误差预算消耗降至50%以下
- 如果一段时间后，错误预算消耗回落至50%以下，系统将继续进行监控。
- 若错误预算消耗率保持在50%以下，系统将等待5分钟的到期时间阈值。
- 若在整整5分钟内，错误预算消耗始终低于50%，该事件将自动关闭。
服务级别消耗率智能警报计算
烧钱率的计算公式为：
消耗速率 = (已消耗的容错预算 * SLO时间窗口) / 告警窗口
- 例如：
- 假设过去12小时内消耗的容差预算为70%，且自动售货机可靠性SLO的时间窗口为1天（24小时）。
- 过去12小时的资金消耗率为： ( 0.70 * 24) / 12 = 1.4
- 同样地，如果过去2小时消耗的误差预算达到20%
- 过去2小时的资金消耗率为： ( 0.20 * 24) / 2 = 2.4
示例 3 - 智能告警：通过单一告警窗口和阈值监控 SLO 的消耗速率
目标：若自动售货机可靠性SLO配置的消耗率在过去12小时内超过1，则触发警报并报告问题。
“服务级别”智能警报的配置应为：
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: SINGLE
Duration: 12 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
完成“智能警报”配置后，系统将开始监控指定警报时段内“自动售货机可靠性”SLO配置的消耗速率。
场景：监控与事件触发
警报窗口期（过去12小时）的资金消耗率超过1
- 假设过去12小时的计算燃烧速率开始超过1。
- 当时间阈值设置为10分钟时，系统将等待完整的10分钟窗口期后才采取任何行动。
- 若10分钟后消耗速率仍高于1，系统将触发警报事件并提交问题报告。
警报窗口期（过去12小时）的资金消耗率降至1以下
- 若一段时间后，告警窗口的消耗速率降至1以下，系统将继续监控。
- 如果消耗速率保持在1以下，系统将等待5分钟的到期时间阈值。
- 若在整整5分钟内，消耗率始终低于1，该事件将自动关闭。
示例4 - 智能警报用于监控具有多个警报窗口及相应阈值的SLO消耗速率
目标：当自动售货机可靠性SLO配置的消耗速率在过去24小时内超过1，且在过去2小时内超过4时，触发警报并提交问题报告。
“服务级别”智能警报的配置应为：
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: LONG
Duration: 24 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
,
Alert Window Type: SHORT
Duration: 2 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 4
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
完成“智能警报”配置后，系统将开始监控自动售货机可靠性 SLO 配置的消耗速率，涵盖长短两种警报窗口。
场景：监控与事件触发
无论是长警报窗口（过去24小时）还是短警报窗口（过去2小时），资金消耗率均超过1
- 假设过去24小时的计算燃烧率开始超过1，而过去2小时的计算燃烧率开始超过4。
- 当时间阈值设置为10分钟时，系统将等待完整的10分钟窗口期后才采取任何行动。
- 若两个告警窗口的消耗速率在10分钟后仍超出阈值，系统将触发告警事件并提交问题。
在长警报窗口期内，资金消耗率降至1以下，但在短警报窗口期内仍保持在4以上
- 若经过一段时间后，长警报窗口的消耗速率降至1以下，但短警报窗口的消耗速率仍高于4，系统将继续进行监控。
- 若在长期告警窗口期内，消耗率持续低于1，系统将等待5分钟的到期时间阈值。
- 若在长警报窗口的完整5分钟内，消耗率始终低于1，则无论短警报窗口的数值如何，该事件将自动关闭——因为必须同时触发两个阈值才能触发警报。 反之亦然——即使短警报窗口触发了阈值，但长警报窗口并未触发。
在长警报窗口期，资金消耗率降至1以下；在短警报窗口期，降至4以下
- 若经过一段时间后，两个告警窗口的消耗速率均降至各自阈值以下，系统将继续进行监控。
- 如果消耗速率保持在阈值以下，系统将等待5分钟的到期时间阈值。
- 若燃烧速率在整整5分钟内始终低于阈值，该事件将自动关闭。
故障诊断
以下是解决配置服务水平目标（SLO）常见问题的建议。
问题 ：未消耗任何错误预算，SLO状态始终为100%。
- 解决方案 ：使用SLO仪表板上的指标图表验证该指标在SLO时间窗口内是否始终未超过阈值，从而确保未消耗错误预算。 您可考虑相应调整阈值。
问题 ：未消耗任何错误预算，SLO状态始终为100%。
- 解决方案 ：使用SLO仪表板上的流量图表 ，验证该实体在SLO时间窗口内是否正在接收流量。 否则，错误预算和SLO状态将不受影响。
问题 ：错误预算持续快速耗尽，服务水平目标状态持续为负。
- 解决方案 ：使用SLO仪表板上的指标图表验证该指标是否在SLO时间窗口内持续超过阈值，从而导致错误预算快速消耗。 您可考虑相应调整阈值。
问题 ：由于时间窗口错位，烧钱率警报未被触发。
- 解决方案 ：
- 固定时间窗口服务水平目标（SLO） ：若SLO配置采用固定时间窗口，当耗尽率计算基于的告警窗口长度超过SLO时间段内的实际经过时间时，告警可能不会触发。 例如，如果警报窗口需要12小时内的数据，但服务水平目标（SLO）时间窗口刚刚开始，那么消耗率可能没有足够的时间超过阈值。 因此，即使在经过的时间段内消耗率较高，也不会触发警报。
- 滚动时间窗口服务级别目标（SLO） ：若将SLO设置为滚动时间窗口，当告警窗口超出SLO创建时间时，消耗率计算可能不会触发告警。 例如，如果告警窗口超出了服务水平目标（SLO）创建或生效的时段，则无法正确计算消耗率，因为告警窗口内无法获取完整的数据。
- 解决方案 ：