问题描述
在阅读了Google SRE书籍多次后，仍然对如何设置burn rate以及触发警报所需的时间有一些疑问。他的大部分问题都来自书中的这一部分：https://landing.google.com/sre/workbook/chapters/alerting-on-slos/#4-alert-on-burn-rate。
1. 在表格5-4中，99.9%的SLO对应burn rate为1时的错误率为0.1%。我想确认一下 – 这个0.1%是从100% – 99.9%得出的，其中99.9%是SLO。这是否意味着如果某个服务的SLO非常低（比如90%的SLO），那么它的burn rate为1时的错误率将为10%。我理解得对吗？
2. 在书中的下面几句话中，提到了以下公式：
对于基于burn rate的警报，警报触发所需的时间为(1-SLO/error ratio) * alerting window size * burn rate。
所以，如果我的SLO为95%，错误率为1（假设过去1小时内的所有请求都是错误的）。假设我的burn rate为1。如果我将这些值代入公式中，我得到：
(100-95/1) * 1小时 * 1 = 5
这里让我困惑的是，这个5是指5小时吗？你需要将1小时转换为60分钟来得到分钟数吗？这是Prometheus触发第一个警报所需的时间吗？
此外，如果需要5小时才能触发警报，那么检测时间是否太晚了？也许一些关于如何使用这个公式计算一些实际值的具体示例会非常有帮助。
3. 下一个公式是：
警报触发时消耗的错误预算为：(burn rate * alerting window size)/period。
我只想澄清一下 – 如果我的burn rate为1，警报窗口大小为1小时，这意味着在5小时内，我将消耗(1 * 1)/5 = 20%的错误预算。我理解得对吗？
4. 表格5-8中推荐的参数是，如果长窗口为1小时，短窗口为5分钟，burn rate为14.4，消耗的错误预算为2%。在上面的图表中，显示了5分钟的错误率（10%）高于1小时的错误率。如果burn rate相同（14.4），为什么它们的错误率会不同？我很难理解这一点。
它还说基于这些信息，将在5分钟内发出警报。这对于任何SLO都是正确的吗？还是只对99.9%的SLO有效？
5. 最后，只想澄清一下：本章中的示例使用了以下记录规则，用于计算每个请求的错误比率：
job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)
如果我想类似地用于识别延迟 – 即超过2秒的所有请求的比率，那么这将是以下PromQL：
(sum by (job, le) (rate(latency_quantile{job="myjob", le="2"}[1h])) /sum by (job, le) (rate(request_count{job="myjob"}[1h]))) > (14.4 * 0.001)
这看起来正确吗？
总之，我希望这一章，作者们承认它有一些复杂的实现，能够提供一些更具体的示例，特别是关于公式和burn rate的部分。一些在表格和图表中指定的示例是有意义的。但有些需要更多的解释来理解细微差别（例如，指定burn rate为14.4意味着占用2%的错误预算，这是因为当你除以30/14.4时，你得到50小时的错误预算，而1小时是这50小时的2%）。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
- 是的，你的理解是正确的。当你将SLO表示为百分比时，你的错误率也应该表示为百分比。所以，在你的例子中，错误率为1等于100%。这将使方程变为：
(100-95/100) * 1小时 * 1 = 0.05小时 = 3分钟
- 公式中的period是你选择的SLO的报告周期。你没有提到你选择了什么时间段。工作手册中的示例是30天。如果你在示例中使用30天（720小时）的时间段，那么在警报触发的3分钟内，你将消耗约0.14%的错误预算：
( 1 * 1小时 ) / 720小时 = 0.14%
- 错误率不同是因为它们是在不同的时间段内测量的。（请注意，图表使用对数刻度，所以实际的错误率和5分钟测量的峰值是15%，而不是10%。）
- 考虑在错误开始后的一分钟内测量的情况：
- 5分钟的测量将看到4分钟没有错误加上一分钟的15%错误，总体错误率为3%。
- 60分钟的测量将看到59分钟没有错误加上一分钟的15%错误，总体错误率只有0.25%。
- 然后考虑在错误开始后的5分钟内测量的情况：
- 5分钟的测量将看到5分钟的15%错误，所以总体错误率将为15%。
- 60分钟的测量将看到55分钟没有错误加上5分钟的15%错误，所以总体错误率将为1.25%。这实际上仍然太低，无法触发警报，所以实际上需要超过5分钟才能触发警报。
- 使用之前的公式，实际触发警报所需的时间为5.76分钟：
5.76 = (0.001/0.15) * 60 * 14.4
- 你的PromQL似乎是在查看好的事件而不是坏的事件，因为le=”2″选择器是用于计算小于等于2秒的延迟的桶计数。你可能需要为好的事件创建一个单独的”good_latency_rate1h”记录规则，然后对于警报使用类似”(1-good_latency_rate1h) > (14.4*0.001)”的条件。