我们之前在上一篇关于执行SLO的博文以及跟踪和执行SLO的网络研讨会中介绍了燃烧率的基本知识。即使基本概念很清楚（如果燃烧率大于1，SLO就有危险），但要制定基于燃烧率值的警报策略还是很困难。
当然，如果实施得当，基于燃烧率的警报可以确保服务水平目标（SLO）得到执行和满足。然而，当把它们与传统的、基于阈值的警报模型（例如，只要在过去2分钟内90%的请求时间超过200ms，就会发出警报）相比，问题是不言自明的。
燃烧率是一个相对抽象的术语，这可能会使一个使用基于燃烧率的警报的系统的属性变得混乱和不直观。
在基于阈值的模型中，负责设置警报的工程师清楚地掌握了警报发射后的情况，更重要的是，预计警报何时发射。
另一方面，在30天的滚动窗口中，SLO为99.9%，需要200ms的响应延迟，在1小时的回溯窗口中，阈值为14.4的多燃烧率警报，有5分钟长的控制窗口，谁能说何时会发射？
如果你已经熟悉了基于SLO的警报，那么这些警报应该是相当敏感的，因为它们会在几分钟内启动。然而，在操作复杂的系统时，这类不确定性是不可接受的：对系统特性（包括其警报策略）的深刻理解将改善日常操作中发生的事故（或停电）的平均恢复时间。
在这篇博文中，我们将展示如何更好地理解基于燃烧率的警报的特性，以及Backyards，我们的企业级服务网格平台，如何在实施这种警报策略的过程中帮助你。
剖析停电 🔗︎
在进入基于燃烧率的警报的计算之前，让我们先看看事件是如何处理的。这将帮助我们了解在设计基于SLO的警报策略时，我们应该寻找哪些指标。
每当一个问题出现，围绕解决这个问题也有一个过程。在本讨论中，"过程 "一词将在最模糊的意义上使用，它可以是。
- 客户给公司的CEO打电话（警报系统），然后他给运营团队的人打电话来解决这个问题
- 依靠一个监控系统，然后通过一些不明确的方式来修复警报
- 拥有一个基于SLO的警报系统，通过确保系统在SLO的限制范围内运行，可视化并强制执行终端用户的需求。
在考虑所有这些 "过程 "时，无论实施情况如何，首先想到的问题是系统恢复的速度有多快。这将是我们想要优化警报策略的第一个指标。这被称为平均恢复时间（MTTR）。这是修复基本问题所需的时间，从问题首次出现的时间点开始计算。
基于这些例子的流程，让我们看看哪些因素构成了MTTR。
- 首先，问题发生在一个系统上。这是时钟开始计时的时候。
- 然后通知能够解决这个问题的人。在自动监测的情况下，这往往是问题发生和第一次向值班人员发出警报之间的延迟。我们将这个指标称为首次警报时间。
- 不管是明确的还是隐含的，问题都会被优先处理，并决定是否应该现在就解决，还是以后解决。我们将此称为事件优先级。
- 然后，这个问题在系统上得到修复。这是解决该问题的实际工作所需的时间。
- 即使一个系统看起来没有问题，自动监测系统也不会立即解决警报，因为它们在认为一个问题得到解决之前会监测系统的进一步缺陷。这就是所谓的警报解决之后。
当试图减少一个系统的MTTR时，第一个也是最明显的方法是减少第一个警报的时间。为了确定需要减少什么，首先，我们需要知道我们的基线。
正如我们之前在上一篇关于执行SLO的博文中所探讨的，多燃烧率警报比其他警报有更多有用的属性。这样的警报可以在PromQL中使用以下规则进行定义。
- alert: SLOBurnRateTooHigh
expr: catalog:istio_requests_total:error_rate1h >= 14.4 * 0.001
and
catalog:istio_requests_total:error_rate5m >= 14.4 * 0.001
为了简化相关的计算，我们将只检查其中一个条件。为了找到警报触发的时间，我们需要了解什么时候catalog:istio_requests_total:error_rate5m >= 14.4 * 0.001 成为真。
在这个公式中，14.4 是为警报设置的燃烧率阈值（BurnRate ），而0.001 是警报所基于的SLO的错误预算。误差预算是通过从100%减去SLO目标（SLOGoal ）来计算的。这就产生了下面的方程式。
catalog:istio_requests_total:error_rate5m = BurnRate * (100 - SLOGoal)
catalog:istio_requests_total:error_rate5m 是通过评估我们的服务水平指标在5分钟内的情况来计算的。为了得到第一次警报的时间值，让我们假设系统之前处于良好的工作状态*（当前错误率*=0），然后它开始表现失常，不断表现出当前错误率为ER 。
该图显示了当系统的当前错误率在5分钟内攀升至30%时，5分钟内的错误率(WindowSize)如何变化。
随着窗口内故障数据点数量的增加，错误率与当前错误率趋于一致。这意味着上面的公式可以改写成这种形式。
CurrentErrorRate * (t/WindowSize) = BurnRate * (100 - SLOGoal)
其中t 是第一次警报的时间。在排列方程时，我们会看到这个公式。
t = BurnRate * (100 - SLOGoal) * WindowSize / CurrentErrorRate
线性方程有一种不可思议的趋势，即总是有一个确切的解决方案。如果你会考虑之前的错误率图表，你会发现五分钟后 "五分钟内的错误率 "值会增加。结果是，如果t 大于WindowSize ，那么警报就永远不会触发，所以我们只希望解决方案在0和WindowSize 之间。
当然，这只是在计算多燃烧率警报的首次警报时间时，需要满足的两个条件之一。为了找到最终值，我们必须使用两个窗口的首次警报时间的最大值。
失败情景 🔗︎
根据这些公式来微调系统的警报策略将是相当耗时的。为了简化这一过程，我们将依靠Backyards的SLO功能--特别是其内置计算器--来显示不同警报的行为。
在之前的计算中，我们采取了一个捷径，为当前的错误率指定了一个任意的百分比。这有助于简化我们的计算；另一方面，在试图计算第一个警报的时间时，必须指定这个百分比。为了解决这个问题，Backyards向用户展示了不同的故障情况，由不同的当前错误率值代表。
从底部开始，一路向上，我们的第一个场景*（100%的错误率*）模拟了系统完全中断时的警报行为。鉴于这些问题会导致高烧毁率，从而使SLO的错误预算迅速耗尽（最后一栏），我们建议设置一个敏感的（快速）烧毁率警报来处理这种情况。正如在99.9%的SLO目标的情况下，这些问题应该在43分钟内修复，我们建议使用高（页级）事件优先级来处理这种情况。
下一个场景是关于有一个跨越三个不同故障域（可用性区域）的Kubernetes部署。在这里，33%的错误率表明当一个可用区完全失败时的警报时间。在为此实施警报策略时，建议你考虑这种错误的频率和持续时间，以及从运行的集群中移除可用性区域所需的实际工作。
为了理解10%的情况，应该注意到大多数系统故障是由于在测试过程中没有发现的代码错误造成的。对于微服务架构，假设一个服务提供多个具有不同代码路径的端点，10%是对这种故障影响的良好估计。
0.1%和0.2%的场景显示了当系统慢慢消耗其错误预算时，警报是如何表现的。这些情况下，可用的错误预算消耗得很慢，所以一般建议将其作为低优先级事件*（* Backyards中的ticketseverity）。
最后，0,005％的情景显示了当错误预算的燃烧速度超过SLO所允许的速度时，系统的表现。这个场景可以用来检查当错误预算以可接受的方式燃烧时，是否没有发送警报（默认情况下，这些都不应该发生警报）。
如果当前SLO时期的错误预算接近耗尽，或者有一个计划中的维护窗口会消耗一部分错误预算，可以改变警报以创建低严重性的票据，表明是否有东西需要修复，并确保维护窗口的错误预算。
微调快速燃烧率警报 🔗︎
快速烧毁率警报的设计方式是，当系统的错误预算被快速消耗（烧毁）时，它们会启动。
如果你有一个SLO，其目标是在30天的滚动窗口中达到99.9%，那么一个好的燃烧率警报可以通过以下参数来设置。
- 燃烧率。14.4
- 主要回看窗口。1小时
- 控制回视窗口。15 m
- 警报延迟功能被禁用
这样一个警报的特点可以这样总结。
这个警报（当考虑到99.9%的SLO目标时）似乎足够严格，但是，基于基础系统的特点，我们可能要做一些调整。首先，在完全中断的情况下，该警报的解决时间只有13秒。值得增加这个警报的控制回溯窗口，以防它在停电期间被多次触发。由于第一次警报的时间与主窗口和控制回视窗口的最大警报时间相对应，这不会改变与该警报相关的警报发射后的指标。
如果警报被证明过于敏感（发射过于频繁），可以将警报延迟设置为一到两分钟，以抑制一些警报噪音。另一方面，这样的问题往往表明系统中出现了微弱的故障，应该进行调查。另外，将警报延迟设置为2分钟，意味着警报到达的时间较晚，因此增加了MTTL。在目前的SLO期间，静默期的成本（由第一次警报的时间烧掉的错误预算金额）也将从系统总错误预算的2%增加到6.63%。
验证警报策略 🔗︎
正如我们在上一篇关于执行SLO的博文中已经提到的，当使用基于燃烧率的警报时，应该定义多个警报来执行我们的SLO。
在基于Prometheus的监控系统中，如果对同一服务发出多个警报，可以配置为只触发特定服务的第一个警报。Backyards建议以这种方式设置警报管理器。这意味着，如果定义警报与快速燃烧率警报对相同的问题作出反应，但反应速度较慢，则快速燃烧率警报将被优先考虑。
考虑到这一点，你可以看到（在前面的例子中）快速燃烧率警报将永远不会对足够零星的问题（错误率~<5%）采取行动。为了规避这个问题，我们建议实施一个或两个额外的警报。
应该创建一个慢速燃烧率警报，旨在触发一个票据严重性事件，以分析那些正在缓慢燃烧错误预算的问题。在这种情况下，第二天修复所涉及的问题是完全可以接受的。定义慢速燃烧率警报的一个好的起点如下（假设30天滚动SLO）。
- 燃烧率。1
- 主要回望窗口。3天
- 控制回视窗口。6小时
下面的图片说明了这一点，将错误率放在每一行中，并在单元格中显示慢速和快速燃烧率（列）和第一次警报值的时间。
在前面的图片中，我们可以看到1%的错误率在7小时13分钟后才会触发警报。如果根据经验，这个首次警报时间造成的MTTR的增加是不可接受的，那么应该创建第三个警报策略（中等速率）。定义中等燃烧率警报的一个好的起点如下（假设30天滚动SLO）。
- 燃烧率。6
- 主要回视窗口。6小时
- 控制回望窗口。30分钟
将这样的警报添加到组合中，就会产生这样的警报策略。
预警策略的可视化 🔗︎
当然，Backyards也提供了这种关系的图形表示。在用户界面上有以下线状图，以便更好地了解每项服务的警报策略。
快速燃烧率警报（用底线表示）只能对燃烧率超过~1.5%的停电发出警报。中等燃烧率警报（中线）通过为0.5%和1.5%之间的错误率提供高优先级的警报设置来补充它。
最后，慢速燃烧率警报（最上面一行）确保，如果我们使用错误预算的速度超过我们的SLO允许的速度，就会创建一个票据。
结论 🔗︎
基于燃烧率的警报可以是相当复杂的，因为它的框架里有许多固有的抽象概念。有了正确的工具（如Backyards），并随着警报实践的不断改进，这个框架可以根据你的系统和组织的需要进行调整，以提供一个可靠的监控和测量解决方案。
如果你想自己检查这些功能（甚至在你自己的机器上运行它们），请随时探索我们的安装指南，该指南可在Backyards的文档页面上找到。要了解如何创建自己的服务水平指标模板并将外部Prometheus指标导入Backyards，请参阅我们的《使用Backyards定义应用程序级别的SLO》博文。
