作者来自 Elastic Roshan Gonsalkorale当 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