“SLO是SREs最喜欢的一个词，”Björn“Beorn”Rabenstein在上周圣地亚哥的KubeCon + CloudNativeCon上的演讲中说。“当然，这也有助于设计决策、设定正确的目标，并以正确的方式设置警报。一切都是好的。”
在接下来的半小时里，Grafana实验室的首席软件工程师bob电竞频道(前谷歌SRE和SoundCloud生产工程师)开始解释他和其他人是如何以及为什么采用基于slow的警报，以及他目前是如何将延迟纳入到Grafana实验室的警报中。
第一幕:SLO的基础知识
在演讲开始时，Rabenstein列出了他不打算谈论的事情(但你可以在后面查阅更多信息)，为他的演讲奠定了基础:
1.有SLO，也有SLI和SLA。Rabenstein说:“谷歌三年前出版的蓝色SRE书是我最喜欢的科技书籍之一，你应该读一下。”“它有整整一章，第四章，它是关于slo的，也涉及sli和sla。都在那里。所以如果你读了这篇文章，你就能达成共识。”
2.负责任地享受slo。今年早些时候在都柏林举行的SRECon大会上，Narayan Desai谈到slo是如何出错的Rabenstein说。“听到可能出现问题的地方，我真的很高兴。我想消除这种错误的印象，即这种方法总是有效的。所以你必须一直思考。”
3.有一门测量延迟SLOs的科学。海因里希·哈特曼在SRECon的演讲提供了对Rabenstein所谈论的背后的科学的更深入的研究。Rabenstein说:“我在这里讲的是如何实际操作，我认为这在数学上是正确的。”“但在你的情况下，你可能不得不做一些稍微不同的事情，一旦你偏离了食谱，你应该真正了解它背后的科学，看看海因里希的演讲。”
4.度量与日志——讨论。“假设你快要违反SLO了，你想要实时收到警报。这是基于参数的，”Rabenstein说道。“如果你真的违反了SLA，比如你有一个客户协议，而你没有履行你的SLA，那么你的客户会得到一些补偿，这现在是精确的科学。你要给他们确切的货币单位作为补偿。”在这种情况下，你不会使用你的指标;你需要在日志中进行精确的计算。他补充说:“如果你的日志处理足够可靠和快速，你完全可以根据日志处理来发出警报。”“这可以归结为从动态日志中创建指标。”
无论是使用度量还是日志，Rabenstein的演讲中讨论的原则仍然适用。
一些背景及资料
Rabenstein首先介绍了基于症状的警报，这在第六章的SRE书。“slo警报实际上是基于症状的警报的一个很好的例子，”他说。“要了解它背后的整个哲学，以及如何不过度使用，你可以阅读那一章。”
第十章在这本书中，Rabenstein补充道，涵盖了从时间序列数据中实际的警报。这也被戏称为Borgmon章节，因为它解释了谷歌传统上是如何基于指标进行警报和监视的。博格蒙体系是普罗米修斯精神上的祖父。所以这也有助于你理解基本概念，我在这里不讨论这些。”
第二个重要的资源是站点可靠性工作手册，该网站提供了更实用的操作指导。第五章Rabenstein说:“在slo上迭代使用不同的警报方法，这样你才能真正理解它。”他补充说，在SoundCloud，他利用这一章在slo上设置警报在博客上写过后来给了一个说话在柏林普罗米修斯聚会．
对SLOs进行警报
Rabenstein从那里开始了他的演讲，并附上了这篇博客文章中的表格:
SRE书中描述的slo警报的基本思想是测量各种时间窗口(表中的“长窗口”)的错误率，然后对它们发出警报。如果你每月的错误预算消耗得很快，你就会快速分页，只有当错误预算消耗得足够慢，以至于在工作时间内回复是可以接受的时候，你才会给人开罚单。
“最容易理解的是你有三天的时间，”他说。“你的平均错误率就是因素一，在不超出你的错误预算的情况下，你所能承受的错误率。假设您想要99.9%的可用性。你的误差预算是在一个计费周期内(通常是一个月)0.1%的误差。所以如果你有0.1%的错误率，因素一，平均三天，这意味着你正在以你允许的最快速度消耗你的错误预算。这不算太糟，但如果这个月剩下的时间里发生什么事，你就完蛋了，对吧?这就是为什么如果你浪费了10%的错误预算，三天就是一个月的10%，你应该做点什么。所以你得到一张罚单，因为你不需要叫醒别人。这是一个长期缓慢错误预算燃烧报告。在工作时间，你可以发现你的系统出了什么问题。”
桌子的速度在加快，最快的是一小时窗口。Rabenstein说:“你有14.4的误差预算，这意味着在0.1%的误差预算下，如果你在一小时内的平均错误率为1.44%，你就得到了一页，而在你得到这一页的那一刻，你在短短一小时内就消耗了每月误差预算的2% !这太快了。这就是需要有人清醒过来解决问题的地方。”
他接着补充说，直觉会告诉您，平均一个小时对于一个页面来说太长了，因为如果您遇到严重的停机，您希望在一分钟内知道。“但直觉是错误的，”他说。
这张来自工作簿的图表显示，“如果你有1.44%的错误率，那么实际上需要一个小时来检测它，”Rabenstein说。“在一个小时的窗口内，如果一切都很好，大部分时间误差为0%，然后突然开始出现100%的误差，在不到一分钟的时间内，平均误差为1.44%。这就是有趣的地方。在不到一分钟的时间内，这个警报就会呼叫你，即使平均一个多小时，所以这个警报实际上没有太慢的问题。”
最重要的结论是:“你可以查看相当长的平均值，仍然可以在慢速错误燃烧时收到有意义的警报，”他说。
但这里有一个潜在的问题，如下图所示。
“蓝色曲线是实际的错误率，”他解释道。“所以在T + 10分钟的时候，你会因为什么原因停机——你的微服务的一些实例坏了，你会有15%的错误率。会发生什么呢?红线是一个小时的平均值。因此，这条红线需要5分钟才能超过1.44%的误差阈值。所以五分钟后，即使有部分中断，你还是会得到一个页面。假设值班工程师醒来，在五分钟内解决问题，好工程师。错误率降至零，工程师就可以回去睡觉了。”
但是，问题是红线将在阈值之上停留一个小时，因为这个错误峰值是在一个小时的平均值中。警报一直在响。你可能会忍不住在寻呼机上打瞌睡，或者让普罗米修斯的警报静音。但是，如果发生了其他事情，错误峰值再次发生，警报就会被静音，没有人会收到通知。
那么，如何确保如果中断再次发生，警报将迅速重置呢?Rabenstein说:“你取5分钟的平均值，这就是从表格进入游戏的短窗口。“对于一个小时的长窗口，你需要另一个五分钟的窗口，你还需要计算平均错误率。”
仅凭这一点提醒就太吵了;一些错误峰值不应该触发警报。“但如果你在两条曲线都高于阈值时发出警报，那么你就能两全其美，”他说。“这个页面是因为绿色和红色都在折页上方，一旦你解决了停机问题，绿色曲线就会迅速下降。所以从这一刻起，你的警报停止。这里的红色区域是警报实际发射时的区域，这正是你想要的。”
如何配置提醒
SRE工作手册包括如何在Prometheus中配置警报的说明(并且可以转移到其他系统中)。但这可能需要大量的手工工作，Rabenstein建议使用某种配置管理。“在Grbob电竞频道afana实验室，我们就是这样Jsonnet粉丝们，”他说。“如果你在这里写一个Jsonnet表，这几乎是同一个表，对吗?所以你只要把这个表输入到Jsonnet中，然后你就有了一些Jsonnet粘合代码，它可以创建你在Prometheus中需要的所有记录和警报规则。”
Rabenstein说，当团队完成对SLO配置代码的修改后，它最终将是开源的。他补充说，在SoundCloud，所有的规则都是手工编码的，所以完全可行。使用Jsonnet的另一种方法是SLO libsonnetMatthias Loibl创建的开源软件。他甚至还加了一个web前端为它。Rabenstein说:“所以现在你有了规则生成服务。
第二幕:关于延迟SLOs的思考
演讲的前半部分讨论了以定义良好的错误结束的请求，比如500。但同样重要的是延迟SLOs。
“现在在现实世界中，你会看到很少有公司给你提供延迟sla，”Rabenstein说。“互联网服务提供商喜欢告诉你他们有99.9%的正常运行时间。这是什么意思?这意味着它是基于时间的，但整个晚上我都在睡觉，我没有使用我的互联网连接。即使有停机时间，我也不会注意到，我的ISP会告诉我它们一直都在工作。不使用服务就像ISP的免费正常运行时间。然后我有一个10分钟的超级重要的视频会议，然后我的网络就断了。对我来说，这就像完全停电一样。他们说，是的，每个月10分钟，这是三个9，这很好。”
一个更好的选择是:基于请求的SLA，它说:“在每个月里，我们将成功服务99%的请求。”但这还不包括延迟，Rabenstein指出，“假设我有一个请求，我想从我的服务提供者那里得到响应，我的浏览器最终超时了，我告诉我的服务提供者，好吧，这个请求没有成功，我的服务提供者告诉我，不，不，不。它会成功的。它只需要5分钟，浏览器超时是你的错。”
在内部，这也很重要，因为从事微服务的独立团队需要彼此就微服务的工作效果达成一致，并期望特定的响应时间。他说:“你希望在那里有延迟，如果它没有明确地存在，它就是隐含的。”
Rabenstein的下一个建议是:“每个月，我们都会成功满足99.9%的请求。99%的延迟将在500毫秒之内。”
使用这个SLA，如果您在10毫秒内得到一个503错误，它将计入一个错误预算，而不计入另一个，因为它是在500毫秒阈值内返回的。而那1%慢的人仍然可以达到这个SLA。
“缓慢的请求可能是无用的，”他指出，“所以在不违反SLA的情况下，这仍然允许1.1%的请求是无用的。当然，这并不是一直发生，但还是有点奇怪。现在让我们站在服务提供者的角度考虑问题:我想在烧毁错误预算时发出警报，但现在我有两个错误预算。我有0.1%的错误和1%的慢查询。如果我违反了一个错误预算而不是另一个，我会提醒吗?我可以用一个来补偿另一个吗?一切都很复杂。”
所以他的结论是尽量让慢请求和错误一样。他说:“每个月告诉你的客户，我们将在500毫秒内成功满足99.9%的请求。”“所以这意味着如果一个错误来的很快，它仍然是一个错误。如果一个请求返回，但是很慢，就会被视为一个错误。这对用户来说是公平的，对双方来说都很容易讲道理。”
bob电竞频道Grafana实验室已经将这些想法应用到其托管的Prometheus/Cortex产品中。混合查询可能具有挑战性;Booking.com通过创建不同的存储桶解决了这个问题有不同sla的昂贵和不那么昂贵的查询。
第三幕:务实的实施
Rabenstein表示:“当然，你可以在此基础上进行迭代，让游戏变得更加复杂。“但如果你可以，就做简单的那个。”对于基于slow的警报，您必须在边缘的某个地方应用您的测量，以从外部角度查看系统的响应速度。在SoundCloud，他们使用边缘负载平衡器。在Cortex中，有一个Cortex网关作为系统的入口点。
有一条摄取(写入)路径，当人们发送Prometheus指标时，Cortex需要摄取它们，还有一条读取路径，人们运行PromQL查询从Cortex检索Prometheus指标。在Grbob电竞频道afana实验室，他们在这个网关上创建了一个普罗米修斯直方图，有不同的桶，包括1秒和2.5秒的SLOs。它们按状态代码、方法和路由(读或写路径)进行分区。
Rabenstein承认，Prometheus从业者的传统智慧不鼓励划分直方图，因为直方图在Prometheus中非常昂贵。但是“我遇到越来越多的用例，我想要划分直方图，”他说，“我们有足够大的普罗米修斯服务器来做这件事。无耻的插头,我在PromCon做了一个演讲最近，我告诉人们我的研究，希望在不远的将来使直方图更便宜。”
对于Grbob电竞频道afana实验室来说，SLO可以在不到一秒的时间内成功完成99.9%的写操作，并在不到2.5秒的时间内对99.5%的读操作做出响应。“这是一个SLO，而不是SLA，”Rabenstein指出。“我们还没有向客户承诺，如果速度变慢，我们会赔偿他们，但我们希望在未来这样做。我认为这是设置SLO来指导你的设计的一个很好的途径。然后，如果你能将其转化为SLA，它将让你的用户非常高兴，它将使你在竞争对手面前拥有优势，这些竞争对手可能对延迟SLA不那么有野心。”的之前报道的努力加快PromQL查询是延迟SLO启发的改进的一个很好的例子。
怎么做
为此，创建记录规则，给出一个错误比率，其中慢速请求与显式错误计数相同。
以下是每个请求读写SLO错误的规则，平均超过一小时:
从直方图中，“我们选择1秒的桶作为写入规则，因为这是写入SLO的延迟，我们的目标是快速完成所有事情，”Rabenstein解释道。“这是推送路径，因为这是写入路径。我们从直方图中快速取出所有不是500的东西，然后除以总数。但这是非常灵活的。例如，你可以将其更改为排除400秒，因为404秒的风暴将很快得到响应，这不应该算作免费正常运行时间。你可以在这里混搭。”对于读规则，2.5秒桶是根据读SLO的延迟来使用的。
对于所有其他所需的时间窗口都存在相应的规则。
回头看看最初基于错误的方法的表格，Rabenstein指出它实际上根本没有改变。“我们使用完全相同的原则，”他说。“一旦我们定义了这些记录规则，我们就回到了原点。从本质上讲，我们现在有一个看起来像错误率的记录规则，但它实际上是错误和缓慢查询的比率。”
请参阅以下两个示例警报规则，并将它们与上面纯基于错误的原始警报进行比较。
结论
Rabenstein说:“延迟实际上在SLA中非常有意义，我们应该帮助我们的客户。”“基于slow的警报确实是一个很好的想法——当然也有一些注意事项。”
将这两种想法结合起来，会增加基于slow的警报的延迟。“slo有点野心勃勃，你可以让它影响你的设计，”他说，“然后在某个时候，你可以对客户非常友好，把它变成真正的SLA。”避免不必要的复杂性是非常重要的:“让所有的事情尽可能简单——但不是更简单!”
