Prometheus中使用 SLIs 和 Error Budgets 统计服务可靠性指标

Hanze | Nov 17, 2023 min read

译者序

原文链接:SLI 和错误预算:这些术语的含义以及它们如何应用于您的平台监控策略

前言 :

在云服务中经常使用 SLI 来描述服务可靠性指标,作为一个很重要的服务指标甚至常常与赔偿标准联系在一起,那么对于该目标的监控就变得十分重要。在非生产环境的监控部署中也有其十分重要的角色,不仅可以将其定义为健康指标,甚至故障时间的存折,甚至还能够帮助服务开发者确定服务可靠性是否满足上线标准,辅助决策。

术语解释:

当我们谈论系统或服务的可靠性时,有一些关键的概念需要理解:

KPI (Key Performance Indicator). 给定的度量标准,通常以计数器或计量值的形式呈现。该指标有助于传达给定组件或一组相关组件的运行状况、状态、性能或使用情况。

SLI (Service Level Indicator). 是一种从有目的的验证测试中得出的“衍生结果测量”。 SLI 的目标是确认特定的高价值用户工作流程对于最终用户来说既可用且性能可接受。您可以将 SLI 视为用户期望的衡量标准。例如,我的 API 的最终用户希望它可用并在 10 秒内返回请求的响应。如果我的 API 未响应(或响应速度更慢),我的最终用户将对我的 API 服务感到不满。

用户期望的测量应该用简单、易于理解的语言编写。 SLI 应得到整个团队的同意。此外,SLI 还应该使用能够以编程方式测量它们的方式进行编码。

SLO (Service Level Objective). 是为定义的 SLI 设定的阈值,表示用户必须通过的 SLI 测试百分比,以使用户对服务总体感到满意。在设定 SLO 目标时,考虑一下当服务未满足定义的 SLI 时会发生什么情况,这有助于设定目标。如果 SLI 衡量的是面向内部的业务支持服务,可能较短的中断时间更容易被接受,因此您可能会选择比面向客户的应用程序中使用的服务更低的 SLO 目标。

Error Budget. 与目标 SLO 百分比直接相关。您的错误预算表示您愿意在 30 天滚动窗口内允许的量化的停机时间或降低的性能水平。每次 SLI 检查失败时,您都会消耗一些允许的错误预算。 (参见下面的参考图表,显示 SLO 目标百分比如何映射到错误预算值。)

示例 :用于 Pivotal Application Service (PAS) 的 SLI(PCF 的一部分)

这是内部 PCF 运营团队使用的服务水平指示器。

SLI:作为一名应用程序开发人员,我希望能够在 2 分钟内成功 CF Push 我的应用程序。

Availability Measure SLO Target Error Budget per 30 days Unit of Measure
CF Push Availability 99.9% 43.2 minutes Success/Fail metric from PCF Healthwatch

我们以 30 天滚动窗口的形式监控 SLO。然后我们检查实际绩效如何达到我们的目标

如果可用性高于我们的 SLO 目标 - 耶!我们发布新功能
如果可用性低于我们的 SLO 目标 - 我们会停止发布,并专注于可靠性

将新代码或环境配置更改部署到生产环境中总是会带来一些固有的风险,无论这些更改经过多好的测试。只要我们达到 SLO 目标,我们就创造了接受一定程度的停机风险的空间,以换取部署所需功能的收益。

为什么 SLI 是首选监控项

专注于 SLI 的监控指标可以减少您在监控工作上的精力投入。

让我们来看另一个例子,如果我们的 Pivotal ops 团队一再接到关于 CF Push SLI 测试失败的警报,那么我们的 SLO(服务水平目标)目标可能面临风险。包含这种具有关键意义指标的信息会变得更有意义;值班工程师立即能够理解最终用户的影响。如果我是值班工程师,我不希望在半夜接到一些组件指标中明显的延迟波动方面的警报。ps:如果我的应用程序的可用性 SLI(通过金丝雀测试)开始失败,我确实希望能够接到警报。

一项持续运行的用户功能测量测试可以告诉您更多有关系统底层性能的信息,而不是对数十个单独的指标进行监视和警报。

选择错误预算 :这是一个账户

Error Budget 应该怎么做? 为了解决这个问题我们需要先设置一个 SLO 目标,SLO 通常在互联网服务中通常会有“三个 9”或者“五个 9” ,这与给定时间窗口内的错误预算直接相关(请参阅下面的参考图表)。

在 Pivotal,我们严格测量了几个月系统的 SLO,我们可以明显发现按照 Error Budget left 或者 spent 的说法更有的意义。根据我们的经验,相比于严格的表示百分比数字,人们可以快速的理解时间花费及时间余额的影响。我们随后在内部对用于部署重大或有风险的变更时 Error Budget 具体可接受的数值进行了讨论。

通过为组织建立共享的 SLO 目标和错误预算,您可以将重点放在创新和可靠性之间的正确平衡上。您还可以为资源优先投资创建一种共识。

SLI 和 Error Budget 的不同表示方法

有时对于企业服务存在这样一个场景,需要展示监控数据给客户,这时 SLI 和 Error Budget 可能和您设置的理赔标准相关联,但是由于时间度量范围的不通可能导致客户对监控到的数值产生误解,进而造成不必要的沟通成本。

通常在这样的场景下,我们可以将 SLI 表示成单位时间内的“健康度”,Error Budget 表示成健康余额。这样有了更好的解释空间,也便于理解

References

Selecting a Target SLO

Target SLO Allowable Downtime (per 30 days) Likely Requires
99.999% (5 nines) 0.43 minutes Automated Failover
99.99% (4 nines) 4.32 minutes Automated Rollback
99.95% (3.5 nines) 21.6 minutes
99.9% (3 nines) 43.2 minutes Comprehensive monitoring and on-call system in place
99.5% (2.5 nines) 216 minutes (~3.5 hours)
99% (2 nines) 432 minutes (~7 hours)
comments powered by Disqus