基于 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 告警的触发速度要慢一些，并且需要更低且较为恒定的错误预算消耗率。 ### 总结 本文是《基于 SLO 告警》系列第 1 篇，主要讲解了 SLO 监控告警基础知识，在后面文章中我将陆续讲解其实战内容，系列文章大致分为 5 篇，欢迎大家关注。 - 基于 SLO 告警（Part 1）：基础概念篇 - 基于 SLO 告警（Part 2）：为什么使用 MWMB 方法 - 基于 SLO 告警（Part 3）：开源项目 sloth 使用 - 基于 SLO 告警（Part 4）：开源项目 pyrra 使用 - 基于 SLO 告警（Part 5）：SLO 多租户与服务化 更多文章，请关注微信公号： https://mp.weixin.qq.com/s/7p5IrthGqM-XcYHU2YqXmw