基于 SLO 告警（Part 1）：基础概念

看过 Google 网站可靠性工作手册 一书的朋友都知道，该书在第一部分重点讲解了基于 SLO 的告警监控相关知识，可见基于 SLO 的监控告警依然成为一种趋势，那在实际工作中，我们该如何实施和落地 SLO 监控告警呢？

今天我们就来看看第一部分，基于 SLO 监控告警的一些基础概念。

为什么需要基于 SLO 告警

基于 SLO 告警相对于传统告警方法，它能够做到：

• 告警基于具体症状（SLIs），而不是具体原因。

• 可以触发不同级别的告警信息（一般警告可以生成工单，严重告警直接 OnCall）。

• 会考虑时间和数量两个维度（特定时间的错误速率和错误数量）。

这些能力带来的直接好处包括但不限于：

• 正确的时间触发正确的告警（重要的告警可以立即触发，不重要的可以适当延迟）。

• 有效减少告警疲劳。

• 减少误报和漏报。

什么是 SLI

SLI 全称为 Service level indicator 及服务水平指标，它是一种量化您的服务如何响应用户的方法，而我们 SLO 是完全依赖 SLI 的。

对于用户而言什么是好/坏的服务呢？举个例子：

• 状态码 >= 500 可视为错误。

• 请求延迟 > 200ms 可视为错误。

• 进程运行非 0 状态码退出可视为错误。

通常我们可以使用事件来衡量它：(good/bad) 数量 / total 数量。

什么是 SLO

SLO 全称为 Service level objective 及服务水平目标。通常它是一个百分比，表示您的服务在特定时间段内可能出现多少 SLI 错误。

什么是错误预算

错误预算是您在特定时间段内可以拥有的错误数量，这是由 SLO 驱动的。

举个例子：

• SLI 错误：状态码 >= 500 所有请求

• 时间周期：30 天

• SLO：99.9%

• 错误预算：0.0999 (100-99.9)%

• 30 天总请求数：10000

• 允许的错误请求数：9.99 (10000 * 0.0999 / 100)

如果我们有超过 9.99 个 >=500 的请求响应，我们将燃烧更多的可用预算，如果我们有更少的错误，这个时间周期内的错误预算还有富余。

什么是燃烧率

这里燃烧率指燃烧错误预算的速度。这是基于 SLO 的告警的关键，一般我们根据多个窗口周期的不同错误预算燃烧率来进行告警。

不同燃烧率举例：

• 1: 您在预期期间消耗了 100% 的错误预算（例如，如果 30 天，则刚好 30 天消耗完毕）

• 2: 您在预期期间内消耗了 200% 的错误预算（例如，如果是 30 天，则 15 天消耗完毕）。

• 60: 您在预期周期内消耗了 6000% 的错误预算（例如，如果周期为 30 天，则 12 小时消耗完毕）。

• 1080: 您在预期周期内消耗了 108000% 的错误预算（例如，如果周期为 30 天，则 40 分钟消耗完毕）。

什么是 ticket 和 page 告警

我们一般使用多窗口、多燃烧率策略进行告警，针对不同的 SLI，不同周期不同燃烧率，我们会产生不同级别的告警信息，主要包括 ticket 和 page 两种。

• page: 指严重告警，需要发送通知重要频道，触发 oncall 等。

• ticket：指一般告警，可以发送不重要的频到，生成对应工单等。

它们触发的逻辑略有不同，page 触发速度更快，但需要更快的错误预算消耗率，而 ticket 告警的触发速度要慢一些，并且需要更低且较为恒定的错误预算消耗率。

以 99.9% SLO 为例，通常它们的告警配置对照表可以为：

总结

本文是《基于 SLO 告警》系列第 1 篇，主要讲解了 SLO 监控告警基础知识，在后面文章中我将陆续讲解其实战内容，系列文章大致分为 5 篇，欢迎大家关注。

• 基于 SLO 告警（Part 1）：基础概念篇

• 基于 SLO 告警（Part 2）：为什么使用 MWMB 方法

• 基于 SLO 告警（Part 3）：开源项目 sloth 使用

• 基于 SLO 告警（Part 4）：开源项目 pyrra 使用

• 基于 SLO 告警（Part 5）：SLO 多租户与服务化

参考文章：https://sloth.dev/faq