你的 SLO 已经告急；下面介绍如何在 Elastic Observability 中找出罪魁祸首

当 SLO 告警检测到燃烧率（ burn rate ）激增时，你可以从告警详情页面沿着 SLI 逐步深入，通过异常事件 span 和追踪瀑布图（ trace waterfall ）定位正在消耗你的 SLO 错误预算的具体依赖项，整个调查过程无需离开当前分析流程。

Elastic Observability 中重新设计的 SLO 燃烧率（ burn rate ）告警详情页面，将告警与 SLI、背后的事件以及展示哪个依赖项正在消耗你的服务级别目标（ SLO ）错误预算的追踪关联在一起。你可以查看燃烧率何时开始上升，并排比较正常事件和异常事件的 span，然后沿着异常事件进入追踪瀑布图（ trace waterfall ），定位发生故障的具体调用链路，全程无需切换工具。

本演练将使用 OpenTelemetry Demo（ Astronomy Shop ）展示完整的排查流程，其中一个发生故障的发货依赖导致每一次结账 SLI 都失败。你可以通过在 Elastic Observability 中运行该 Demo、为 checkout 定义一个 APM 可用性 SLO，并引入一个发生故障的依赖项来复现这一场景。

可用性

SLO 燃烧率分析现已在 Elastic Observability Serverless 中提供，并将在 9.5 中登陆 Elastic Cloud Hosted 和自托管部署。

Elastic Observability 中 SLO 燃烧率告警的前提条件

你需要一个已完成监测的服务，并在 Elastic Observability 中基于其 APM 数据定义一个 SLO。

应用程序监测： 使用以下任一方式：
- 适用于 Java、 .NET、 Node.js、 Python、 PHP、 Ruby、 Go 及其他受支持语言的 Elastic APM agent。
- Elastic Distributions of OpenTelemetry（ EDOT ）语言 SDK。
- 使用 OpenTelemetry SDK，通过 EDOT Collector、 Elastic Agent、 APM Server 或托管 OTLP 端点发送 OTLP 数据。如果你使用自定义的上游 Collector 流水线，请同时包含 elasticapm connector 和 elasticapm processor。这两个组件随 EDOT Collector（或自定义的 EDOT 类构建）一起提供，并不是标准 OpenTelemetry Collector Contrib 发行版的一部分。有关连接方式的详细信息，请参阅上游 Collector 配置。
SLO 定义： 为需要保护的服务定义一个基于 APM 延迟或 APM 可用性的 SLO。保存 SLO 后，Elastic 会自动创建一条默认的燃烧率告警规则。
后端： 当前支持 Elastic Observability Serverless；待 9.5 发布后，还将支持运行 Elastic Stack 9.5 的 Elastic Cloud Hosted 和自托管部署。

SLO 燃烧率分析演练：从告警定位到故障依赖项

步骤 1：在告警详情页面查看 SLO 燃烧率

从通知中打开 SLO 燃烧率告警详情页面。

图表会显示燃烧率何时开始上升，以及在当前滚动周期内还剩余多少错误预算。接着，打开与该告警关联的 SLI，并判断当前看到的是短时间的突发峰值，还是持续性的性能下降，再进一步深入分析事件。

在本示例中，checkout 的可用性 SLO 正在快速消耗错误预算，而且燃烧率是最近才开始上升的，因此问题很可能是在最近几个小时内引入的，而不是长期逐渐恶化所导致的。

步骤 2：检查导致 SLO 错误预算消耗的 SLI 错误率

在 SLI 视图中，查看驱动 SLO 的错误率。

你可以在 APM UI 中将 SLI 作为 RED 指标查看，以快速了解服务整体状况；如果需要对计入 SLO 的 span 进行过滤、比较或细分分析，则可以在 Discover 中打开 Traces。

在本示例中，checkout 的错误率已经上升，这与可用性 SLO 燃烧率的激增相吻合。

步骤 3：比较 SLI 的正常事件 span 与异常事件 span

打开 SLI 对应的事件，并在正常事件（ good events ）和异常事件（ bad events ）的 span 之间切换查看。

在打开单个追踪之前，这两组事件之间的差异通常就已经显现出来。在本示例中，异常事件具有一个正常事件所没有的共同特征，从而缩小了下一步需要排查的范围。

步骤 4：在追踪瀑布图中定位故障 span

打开几个异常事件的示例 span，并在追踪瀑布图（ trace waterfall ）中查看对应的追踪。

这样可以将发生故障的 span 放到完整的请求路径中进行分析，让你看到是哪一个调用环节导致了 SLI 未达标。在本示例中，发生故障的 span 来自一个下游调用，而不是 checkout 服务自身的应用程序逻辑。

步骤 5：确认哪个依赖项正在消耗你的 SLO 错误预算

打开拥有异常 span 的服务，并查看它的依赖项。

在本示例中，追踪瀑布图指向了 shipping 服务以及对 quote-old 的失败调用。发送到该依赖项的请求每次都会失败，因此导致 SLO 燃烧率上升的原因是外部依赖项，而不是 checkout 服务本身的代码。

SLO 燃烧率调查：从告警到根因

在 Elastic Observability 中，从一个 SLO 燃烧率告警开始，你可以查看燃烧率何时上升，打开关联的 SLI，比较正常事件和异常事件的 span，在追踪瀑布图中检查异常 span，并验证发生故障的依赖项，从而找到正在消耗错误预算的原因。

原文：SLO burn rate analysis: from alert to failing dependency --- Elastic Observability Labs