SLO应该很简单，来认识一下Sloth工具吧

Kubernetes apiserver延迟,SLO与Sloth

在科技圈，每年都会有一些比其他词更流行的热词。比如：

• 2017：加密货币和区块链
• 2018：可观测性和追踪
• 2019：服务网状
• 2020：GitOps

而今年流行的一个新词是 SLO。

你肯定最近听说了“服务级别目标”（SLO）这个词，不仅仅是因为SLOConf。SLO并不新鲜，，如果你看到这篇文章，你可能已经熟悉了SLI、SLO、SLA、错误预算等概念。

除了这个词流行之外，SLOs（服务级别目标）很赞，如果你还没有使用它们，不妨试试，我相信你会从中获益。

现在我要讲讲我是怎么实现 Sloth 的，如果你想直接跳到 Sloth小节 ，可以直接跳到那里。

很久很久以前……

我不知道SLOs具体是什么时候创建的，不过在我开始对SRE文化产生兴趣时，第一次接触到它们是在SRE书籍的第四章，后来又在SRE工作手册中继续了解。

对我而言，SLOs 不仅仅是工具或框架，而是一种思考和应用可观测性的方法（叮！- 2018），是一种语言……用一句话来说，一种 文化。然而，每当我试图向朋友、家人、同事……在不同的公司中解释时，总是遇到同样的问题：

虽然每个人都知道 SLOs 的术语和目的，但很多人在真正应用 SLOs、理解其应用过程或实际操作方面遇到困难。

（2018–2019）服务运营者

那是在2018年，那年我在Spotahome工作，我是做平台的工程师/SRE，写代码并做运维。我们希望让这变得简单，这样人们不需要去记住现有的所有SLO术语，当时这方面的资料并不多，我们想开始在公司里应用SLOs。

我们创建了一个Kubernetes操作器，并将服务的SLO定义为一个CRD。我们称之为Service Level Operator。该CRD很简单：给我一个请求事件的查询，给我一个错误请求事件（例如5xx）的查询，然后操作器将定期计算比率（0-1），并通过约定的度量标准定期提供给Prometheus。

操作员的工作做得很好，我们有非常简单的仪表板，能够快速提供洞察，然而，缺少了周期指标、警报、SLO相关信息……我们在SLO方面还有许多不足，但这作为第一步来说已经相当不错了。

(2019–2020) 阿萨迪托

2019年年末，我搬到了一家叫Cabify的新公司。某些团队已经开始应用并实施SLO。然而，在创建这些SLO的Prometheus规则时，仍然存在很多容易出错的手动操作。甚至开始为这些手动制定的Prometheus规则编写单元测试来保证它们的准确性！这简直就是纯粹的苦工toil。

我考虑了这个问题，我们如何能改进流程，并在公司内部启动了一个新项目。Asadito，一款名为Asadito的CLI工具，用于生成所有需要的Prometheus规则，以创建SLI记录规则和基于SLO的警报（多窗口多时段）。主要的想法是追求简单性和灵活性，以提高SLO的采用率。

换句话说，我在创建服务级别操作员时的一些经验被应用到了这家公司，并对其进行了相应的调整以适应需求。

多个团队开始使用这个工具，突然之间，公司在所有愿意使用它的团队中有了标准化的服务水平目标(SLOs)，你可以发现所有团队的SLOs，我们有一个通用的SLO Grafana仪表盘，一个易于理解的SLO规范仓库。

相比2018年的服务级别操作员的工作，这有了很大的改进，并且非常成功地运作。

成功啦！

(2021) 慢吞吞 树懒

我现在已经不在这些公司工作了。现在已经到了2021年，我觉得人们在实施SLOs时还有困难，不应该这样。此外，我认为我在过去几家公司在这方面做出了积极的贡献，所以。

在经历了 service level operator 和 Asadito 的体验之后，我想要类似的东西，并且对每个人开放，就像我用业余时间开发的所有开源软件（OSS）项目一样。

跟树懒打声招呼！

懒惰可以轻松地为Prometheus基于一个可扩展的配置文件生成SLO。易于理解和维护。

这是CLI吗？还是Kubernetes控制器或操作符？它既是，也是，会根据你的需求来调整，你可以根据喜好选择使用方式。

懒惰特性的尝试试图移除所有让用户在实际应用SLO时感到困惑的部分：例如，奇怪的错误预算计算公式、不同的时间范围、不同的可视化图表形式……

简洁聚焦于简洁性，有着安全的默认设置，目的是为了满足90-95%的人的需求（这算是市场策略吧！）。如果你是那5-10%的人之一，我感到很抱歉，不过你可能已经有了自己的工具或自定义了SLO规则。

我们来看一个SLO的例子，Sloth能为你做什么。

spec

从规格说明中可以看出，我们为每个服务定义了多个SLO，这样做背后的思路是每个服务都应该有一个清晰简单的SLO说明。这有两大目的：

• 每个服务都有其SLO。
• 服务的SLO记录在文档中。

每个SLO都有一个ID，目标值/目标（例如 99.9%），一个类型为 events 的 SLI（还有类型为 raw 的 SLI），最后是可选的告警部分，以启用或禁用自动 多窗口多烧录（multiwindow-multiburn）告警生成功能。

SLI Prometheus 查询需要一个模板变量 {{.window}}，SLOth 会将这个变量扩展为生成规则所需的 SLO 时间窗口（例如5m, 1h, 3d等）。

验证过程

当懒惰系统生成SLO规则时，它会验证规范，包括SLI查询、选项……因此，错误的SLO的反馈回路尽可能快地，这样你就不会因为错误的SLO而浪费时间，创建一个简单的SLO需要的时间不会超过3个小时。

CLI使用

把你把它当作普通的 CLI 来使用，比如用于 gitops (叮! 2020)：

运行以下命令生成服务的SLO：

sloth generate -i ./myservice-slo.yml

用法（Kubernetes 控制器/操作员）

如果 Sloth 正在作为控制器，你可以使用 Kubectl 自动提交类似配置清单，这个清单是一个 CRD。Sloth 控制器会生成这些规则，并将它们存储为 Prometheus 规则，供 prometheus-operator 使用。

你可以用下面的命令运行控制器：

# 运行控制器的命令

    慢的 Kubernetes 控制器

获取 k8s 集群中创建的 SLOs 及其状态：

    kubectl get slos --所有命名空间中的

普罗米修斯规则

普罗米修斯生成的规则是由惰性决定的，并且这些规则是标准化的。这将使得所有服务级别目标（SLO）易于发现，信息不会缺失，并且有一个统一的SLO体系。

这些规则可以分成三大类：

• SLI 记录规则。
• SLO 元数据记录规则。
• 多窗口多刻录警示规则。

你可以使用这个 Prometheus 查询来获取 Sloth 生成的所有指标。

    count({sloth_id!= ""}) by (__name__)

控制面板

正如之前所说，所有SLOs都采用相同的统一实现方式，因此我们可以创建一个通用的Grafana仪表板来展示所有SLO的状态信息。

我家的 WiFi 在 Sloth 仪表板上显示 SLO（服务级别目标）。

如你所知，Sloth 去除了 SLO 配置中的复杂环节，并假设了安全的默认值，例如 30 天的时间窗口。这样仪表板自带错误预算燃尽图，可以查看并据此决策每月预算状况（我考虑添加每周 7 天的选项）。如果你觉得这很有趣，可以在评论或 GitHub 问题中提出建议。

我家 wifi 使用体验，包括了 SLO 错误预算的月度烧尽图。

提醒

我们讨论了multiwindow-mutiburn告警，其中包括Sloth实现的基于错误预算消耗的告警。Sloth 实现了 Google 描述的标准，大多数情况下足够好，因为它跟踪的是慢速和快速错误预算消耗的告警。Sloth 会创建两种类型的告警（如下：每种告警都可以启用或禁用）。

• 关键页面警报：现在请注意
• 票证警告：有点不对劲，暂时不用太担心，有空的时候再看看

你不需要担心设置提醒，就像其他事情一样，Sloth 会自动设定安全的时间提醒，在这些不同情况下提醒你。

一个关于未来 未来的 简洁起见 一个更为简洁的版本

未来

树懒的未来会是怎样的呢？

OpenSLO

最近，OpenSLO 发布了作为一个 SLO 标准。有意思的是，它是在 Sloth 开发的同时创建的，我们当时并不认识对方。

现在，我正在尝试将Sloth规范适配到OpenSLO规范。我觉得它们可能不会完全兼容（比如，OpenSLO没有警报相关的功能），然而，如果我们支持OpenSLO在Sloth上，Sloth的规范将得到持续维护，成为重要地位，因为它的简洁和全面的功能。

更新通知 (2021/06/30)：现已支持 OpenSLO

v0.5.0 发布，支持 OpenSLO 的发布公告

SLI插件：SLI插件列表

我对这个功能超级激动，很快就能用上了，请敬请期待。

更新 (2021年6月10日)：在最新版的 Sloth 发布中，SLI 插件已提供请点击这里查看最新的 Sloth 发布

SLI 插件发布了推特帖子解释它们

这些是任何人都可以在外部开发的简单的 Go 文件，无需在 Sloth 内部进行。Sloth 在启动时会通过传递一些标志从文件系统中读取这些文件。从那时起，任何 SLO 都可以直接在 SLI 规范中的部分引用这些 SLI 插件，而无需编写 Prometheus 查询语句。你可以想象这种扩展性带来的力量，例如：

• 在公司级别共享通用的SLI指标仓库，这可以由一个团队或有经验的人来共同维护。
• 基于社区的SLI仓库（通用、框架、库和应用）。
• 让复杂的Prometheus SLI查询变得简单。
• 避免在团队或公司的不同服务中重复查询…
• 利用SLI插件来学习，并作为创建您自己的插件的参考。
• 确保SLI查询的验证和安全性。

将有一个通用的SLI仓库供使用，人们可以向其中贡献内容，并且也可以更轻松地使用它来设置这样的SLO。

结论

我简要介绍了Sloth能为你做些什么，更多详细信息请参阅Sloth文档。

简而言之，我通常会这样形容懒惰。

让 SLOs 的应用变得简单。

如果你试着用这些服务，你可以从这里下载预构建的二进制文件，只需下载，创建一个简单的配置，生成 Prometheus 规则，不到 5 分钟，你就能为这个服务运行 SLO 了，加油哦 :)

（SLO 为 Service Level Objective，服务级别目标）

如果你能给我反馈、意见，或者你已经在为自己或你的公司使用它……我将非常感激！这种反馈能极大地激励我，所以我非常感激。你可以在下方评论，或通过GH问题反馈 :)

感谢阅读，祝你愉快SLOing！

拜拜！

哎，我忘了。

区块链！(叮！2017)，服务网格 mesh！(叮！2019)。