根据日志和指标构建更好的服务水平目标 (SLOs)

作者：来自 Elastic Bahubali Shetti

为了帮助管理运营和业务指标，Elastic Observability 的 SLO（Service Level Objectives - 服务级别目标）功能于 8.12 版中推出。本博客将介绍此功能以及如何将其与 Elastic 的 AI Assistant 配合使用以满足 SLOs。

在当今的数字环境中，应用程序是我们个人生活和职业生活的核心。我们已经习惯了这些应用程序始终可用且响应迅速。这种期望给开发人员和运营团队带来了沉重的负担。

站点可靠性工程师 (Site reliability engineers  - SRE) 面临着筛选大量数据的艰巨任务，这些数据不仅来自应用程序本身，还来自底层基础设施。除了数据分析之外，他们还负责确保运营工具的有效使用和开发。不断增长的数据量、每天解决问题以及工具和流程的不断发展可能会分散对业务绩效的关注。

Elastic Observability 为这一挑战提供了解决方案。它使 SRE 能够结合业务指标集成和检查所有遥测数据（日志、指标、跟踪和分析）。这种全面的数据分析方法可以促进卓越运营、提高生产力并获得关键见解，所有这些都是在苛刻的数字环境中维护高性能应用程序不可或缺的。

为了帮助管理运营和业务指标，Elastic Observability 的 SLO（Service Level Objectives - 服务级别目标）功能在 8.12 中引入。此功能允许为服务设置可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度，或者定义你自己的目标。关键组件包括：

• 定义和监控 SLI（服务级别指标）
• 监控错误预算，指示允许的性能不足
• 对显示错误预算消耗的消耗率发出警报

用户可以使用仪表板实时监控 SLOs，跟踪历史性能并接收潜在问题的警报。此外，SLO 仪表板面板提供自定义可视化效果。

服务级别目标 (SLOs) 通常适用于我们的白金和企业订阅客户。

在本博客中，我们将概述以下内容：

• 什么是 SLOs？Google SRE 视角
• 定义和管理 SLOs 的几种场景

服务级别目标概述

服务级别目标 (SLO) 是站点可靠性工程 (SRE) 的重要组成部分，如 Google 的 SRE 手册中所述。它们提供了量化和管理服务可靠性的框架。SLO 的关键要素包括：

• 服务级别指标 (Service Level Indicators - SLI)：这些是经过精心挑选的指标，例如正常运行时间、延迟、吞吐量、错误率或其他重要指标，它们代表服务的各个方面，从运营或业务角度来看很重要。因此，SLI 是所提供服务级别（延迟、正常运行时间等）的度量，它被定义为良好事件与总事件的比率，范围在 0% 到 100% 之间。
• 服务级别目标 (Service Level Objective - SLO)：SLO 是服务级别的目标值，以 SLI 的百分比来衡量。高于阈值，服务即符合要求。例如，如果我们想将服务可用性用作 SLI，成功响应数为 99.9%，那么只要失败响应数 > 0.1%，SLO 就会不合规。
• 错误预算（Error budget）：这表示可接受的错误阈值，平衡可靠性需求与实际限制。它定义为 100% 减去可容忍的 SLO 错误数量。
• 消耗率（Burn rate）：这个概念与服务消耗其错误预算的速度有关，这是服务提供商及其用户商定的不可靠性的可接受阈值。

理解这些概念并有效实施它们对于在服务交付中保持创新与可靠性之间的平衡至关重要。有关更多详细信息，你可以参考 Google 的 SRE 手册。

要记住的一件主要事情是，SLO 监控不是事件监控。SLO 监控是一种主动的战略方法，旨在确保服务满足既定的性能标准和用户期望。它涉及跟踪服务级别目标、错误预算和服务随时间的整体可靠性。这种预测方法有助于预防可能影响用户的问题，并使服务性能与业务目标保持一致。

相比之下，事件监控是一种被动过程，专注于在服务事件发生时检测、响应和缓解。它旨在实时解决意外中断或故障，最大限度地减少停机时间和对服务的影响。这包括在事件期间监控系统运行状况、错误和响应时间，重点是快速响应以最大限度地减少中断并维护服务的声誉。

Elastic® 的 SLO 功能直接基于 Google SRE 手册。所有定义和语义均按照 Google 的 SRE 手册中的描述使用。因此，用户可以在 Elastic 中对 SLO 执行以下操作：

• 在 SLI 上定义 SLO，例如 KQL（基于日志的查询）、服务可用性、服务延迟、自定义指标、直方图指标或时间片指标。此外，设置适当的阈值。
• 利用基于发生而不是时间片的预算。发生次数是良好事件数除以总事件数，以计算 SLO。时间片将整个时间窗口分成定义持续时间的短片段，并计算良好片段除以总片段数，以计算 SLO。在尝试满足商定的客户目标时，时间片目标在计算服务的 SLO 等内容时更准确、更有用。
• 在单一位置管理所有 SLOs。
• 从定义的 SLO 触发警报，无论 SLI 是否关闭、消耗率是否用完或错误率是否为 X。
• 使用 SLO 信息创建独特的服务级别仪表板，以更全面地了解服务。

SREs 需要能够管理业务指标。

基于日志的 SLO：NGINX 可用性

定义 SLO 并不总是意味着需要使用指标。即使日志中嵌入了指标，它也是信息丰富的形式。因此，根据日志了解你的业务和运营状态非常有用。

Elastic 允许你根据日志消息中的特定字段创建 SLO，这些字段不必是指标。一个简单的示例是一个简单的多层应用程序，它具有 Web 服务器层 (nginx)、处理层和数据库层。

假设你的处理层正在管理大量请求。你想确保服务正常运行。最好的方法是确保所有 http.response.status_code 都小于 500。任何小于 500 的值都可以确保服务正常运行，并且任何错误（如 404）都是用户或客户端错误，而不是服务器错误。

如果我们使用 Elastic 中的 Discover，我们会发现在七天的时间范围内有近 200 万条日志消息。

此外，http.response.status_code > 500 的消息数量很少，大约 17K。

我们可以使用此查询创建 SLO，而不是创建警报：

我们选择使用发生次数作为预算方法，以使事情变得简单。

定义后，我们可以看到我们的 SLO 在七天时间范围内的表现如何。我们不仅可以看到 SLO，还可以看到消耗率、历史 SLI 和错误预算，以及针对 SLO 的任何特定警报。

我们不仅会获得有关违规的信息，还会获得：

• 历史 SLI（7 天）
• 错误预算消耗情况
• 好事件与坏事件（24 小时）

我们可以看到我们是如何轻易耗尽错误预算的。

因此，nginx 一定出了问题。要进行调查，我们需要做的就是利用 AI 助手，并使用其自然语言界面提出问题来帮助分析情况。

让我们使用 Elastic 的 AI 助手分析过去七天所有日志中 http.response.status_code 的细分情况。这有助于我们了解我们遇到了多少 50X 错误。

我们可以看到，与总体消息数量相比，502 的数量微不足道，但它影响了我们的 SLO。

但是，Nginx 似乎出现了问题。为了减少问题，我们还询问 AI 助手如何处理此错误。具体来说，我们询问 SRE 团队是否创建了内部运行手册。

AI Assistant 获得了团队已添加到其知识库中的运行手册。我现在可以分析并尝试解决或减少 nginx 的问题。

虽然这是一个简单的例子，但可以基于 KQL 定义无数种可能性。其他一些简单的例子：

• 99% 的请求发生在 200 毫秒内
• 99% 的日志消息不是错误

应用程序 SLO：OpenTelemetry 演示 cartservice

应用程序开发人员和 SRE 常用 OpenTelemetry 演示来了解 OpenTelemetry 并测试可观察性功能。

此演示具有功能标志来模拟问题。借助 Elastic 的警报和 SLO 功能，你还可以确定整个应用程序的运行情况以及使用这些功能标志时客户体验的保持情况。

Elastic 通过直接获取 OTLP 来支持 OpenTelemetry，无需 Elastic 特定代理。你可以直接从应用程序（通过 OTel 库）和收集器发送 OpenTelemetry 数据。

我们在 K8S 集群 (AWS EKS) 上启动了 OpenTelemetry 演示并打开了 cartservice 功能标志。这会将错误插入到 cartservice 中。我们还创建了两个 SLO 来监控 cartservice 的可用性和延迟。

我们可以看到购 cartservice 的可用性受到了影响。深入研究后，我们发现成功的交易并不多，这影响了 SLO。

深入研究该服务时，我们可以在 Elastic APM 中看到，emptyCart 服务的故障率高于正常水平，约为 5.5%。

我们可以在 APM 中进一步调查这个问题，但这是另一篇博客的讨论内容。请继续关注我们如何使用 Elastic 的机器学习、AIOps 和 AI Assistant 来了解这个问题。

结论

SLO 允许你根据可用性、响应时间、错误率和其他关键指标等因素为你的服务性能设定明确、可衡量的目标。希望通过我们在本博客中提供的概述，你可以看到：

• SLO 可以基于日志。在 Elastic 中，你可以使用 KQL 查找和过滤特定日志和日志字段来监控和触发 SLOs。
• AI Assistant 是一种有价值且易于使用的功能，可用于分析、排除故障，甚至可能解决 SLO 问题。
• 基于 APM 服务的 SLO 易于创建和管理，并可与 Elastic APM 集成。我们还使用 OTel 遥测来帮助监控 SLO。

有关 Elastic 中 SLO 的更多信息，请查看 Elastic 文档和以下资源：

• Elastic Observability 8.12 中的新功能
• Elastic AI Assistant 简介
• Elastic OpenTelemetry 支持

准备好开始了吗？注册 Elastic Cloud并试用我上面概述的功能和能力，以从你的 SLO 中获得最大价值和可见性。

本文中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。

在这篇博文中，我们可能使用或提到了第三方生成 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制第三方工具，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害承担任何责任。将 AI 工具用于个人、敏感或机密信息时请谨慎。你提交的任何数据都可能用于 AI 培训或其他目的。无法保证你提供的信息将得到安全或保密。在使用任何生成式 AI 工具之前，你应熟悉其隐私惯例和使用条款。

Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文：Build better Service Level Objectives (SLOs) from logs and metrics — Elastic Observability Labs