在当今的数字环境中，应用程序是我们个人和职业生活的核心。我们已经习惯于这些应用程序始终可用且响应迅速。这种期望给开发人员和运营团队带来了巨大的负担。
站点可靠性工程师 (SRE) 面临着一项艰巨的任务，即筛选大量数据，这些数据不仅来自应用程序本身，还来自底层基础设施。除了数据分析之外，他们还负责确保运营工具的有效使用和开发。不断增长的数据量、日常问题解决以及工具和流程的持续演变会分散对业务绩效的关注。
Elastic 可观测性为这一挑战提供了解决方案。它使 SRE 能够整合和检查所有遥测数据（日志、指标、跟踪和性能分析），以及业务指标。这种全面的数据分析方法有助于提高运营效率，提高生产力并产生关键见解，所有这些对于在苛刻的数字环境中维护高性能应用程序都至关重要。
为了帮助管理运营和业务指标，Elastic 可观测性的 SLO（服务级别目标）功能在8.12中推出。此功能可以为服务设置可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度或定义自己的目标。关键组件包括
-
定义和监控 SLI（服务级别指标）
-
监控指示允许的性能不足的错误预算
-
针对显示错误预算消耗的消耗率发出警报
用户可以在仪表板中实时监控 SLO，跟踪历史性能，并在出现潜在问题时收到警报。此外，SLO 仪表板面板还提供自定义的可视化效果。
服务级别目标 (SLO) 通常可供我们的 Platinum 和 Enterprise 订阅客户使用。
在本博客中，我们将概述以下内容
-
什么是 SLO？Google SRE 的角度
-
定义和管理 SLO 的几种情景
服务级别目标概述
服务级别目标 (SLO) 是站点可靠性工程 (SRE) 的一个关键组件，如Google SRE 手册中所述。它们为量化和管理服务的可靠性提供了一个框架。SLO 的关键要素包括
-
服务级别指标 (SLI)： 这些是精心选择的指标，例如正常运行时间、延迟、吞吐量、错误率或其他重要指标，代表服务的各个方面，并且从运营或业务角度来看很重要。因此，SLI 是衡量所提供服务级别（延迟、正常运行时间等）的指标，它被定义为良好事件与总事件之比，范围在 0% 到 100% 之间。
-
服务级别目标 (SLO)： SLO 是以 SLI 百分比衡量的服务级别的目标值。高于阈值，服务符合标准。例如，如果我们想使用服务可用性作为 SLI，并将成功响应的数量定为 99.9%，那么任何时候失败响应的数量 > 0.1%，SLO 都将不符合标准。
-
错误预算： 这表示可接受错误的阈值，在可靠性需求与实际限制之间取得平衡。它被定义为 100% 减去容忍的 SLO 错误量。
-
消耗率： 这个概念与服务消耗其错误预算的速度有关，错误预算是服务提供商及其用户之间商定的可接受的不可靠阈值。
理解这些概念并有效地实施它们对于在服务交付中保持创新和可靠性之间的平衡至关重要。有关更多详细信息，您可以参考Google SRE 手册。
要记住的一件事是，SLO 监控不是事件监控。SLO 监控是一种主动的战略方法，旨在确保服务符合既定的性能标准和用户期望。它涉及跟踪服务级别目标、错误预算以及服务随时间推移的总体可靠性。这种预测方法有助于防止可能影响用户的问题，并将服务性能与业务目标保持一致。
相比之下，事件监控是一个被动的过程，侧重于在发生服务事件时检测、响应和缓解事件。它旨在实时解决意外中断或故障，最大限度地减少停机时间和服务影响。这包括在事件期间监控系统运行状况、错误和响应时间，重点是快速响应，以最大限度地减少中断并维护服务的声誉。
Elastic® 的 SLO 功能直接基于 Google SRE 手册。所有定义和语义均按照 Google SRE 手册中的描述使用。因此，用户可以在 Elastic 中对 SLO 执行以下操作
-
在 SLI 上定义 SLO，例如 KQL（基于日志的查询）、服务可用性、服务延迟、自定义指标、直方图指标或时间片指标。此外，设置适当的阈值。
-
利用基于事件发生次数与时间切片的预算方法。发生次数是指良好事件数量除以事件总数来计算 SLO。时间切片将总时间窗口划分为定义持续时间的更小切片，并计算良好切片的数量除以总切片数来计算 SLO。在尝试满足约定的客户目标时，时间切片目标在计算服务 SLO 等方面更准确且更有用。
-
在单一位置管理所有 SLO。
-
从定义的 SLO 触发警报，无论 SLI 是否关闭、消耗率是否用完，还是错误率是否为 X。
-
创建包含 SLO 信息的独特服务级别仪表板，以便更全面地了解服务。
SRE 需要能够管理业务指标。
基于日志的 SLO：NGINX 可用性
定义 SLO 并不总是意味着需要使用指标。日志是一种丰富的信息形式，即使它们嵌入了指标。因此，根据日志了解您的业务和运营状态很有用。
Elastic 允许您基于日志消息中的特定字段创建 SLO，这些字段不必是指标。一个简单的例子是一个简单的多层应用程序，它有一个 Web 服务器层 (nginx)、一个处理层和一个数据库层。
假设您的处理层正在管理大量请求。您要确保服务正常运行。最好的方法是确保所有 http.response.status_code 都小于 500。任何小于 500 的代码都表示服务正常运行，任何错误（如 404）都是用户或客户端错误，而不是服务器错误。
如果我们使用 Elastic 中的 Discover，我们会看到在七天的时间范围内有将近 200 万条日志消息。
此外，http.response.status_code > 500 的消息数量极少，大约为 1.7 万条。
我们可以使用此查询创建一个 SLO，而不是创建警报
我们选择使用发生次数作为预算方法，以保持简单。
定义完成后，我们可以看到我们的 SLO 在七天的时间框架内表现如何。我们不仅可以看到 SLO，还可以看到消耗率、历史 SLI、错误预算以及针对 SLO 的任何特定警报。
我们不仅可以获得有关违规的信息，还可以获得
-
历史 SLI（7 天）
-
错误预算消耗
-
良好事件与不良事件（24 小时）
我们可以看到我们是如何轻易地耗尽了错误预算。
因此，nginx 肯定出了问题。要进行调查，我们所需要做的就是利用 AI 助手，并使用其自然语言界面提出问题，以帮助分析情况。
让我们使用 Elastic 的 AI 助手来分析过去七天所有日志中 http.response.status_code 的分解情况。这有助于我们了解我们收到了多少 50X 错误。
正如我们所看到的，与总消息数量相比，502 的数量很少，但它正在影响我们的 SLO。
但是，似乎 Nginx 存在问题。为了减少这个问题，我们还询问 AI 助手如何解决此错误。具体来说，我们询问 SRE 团队是否创建了内部操作手册。
AI 助手获取了团队已添加到其知识库的操作手册。我现在可以分析并尝试解决或减少 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 助手来了解问题。
结论
SLO 允许您根据可用性、响应时间、错误率和其他关键指标等因素，为您的服务性能设定明确、可衡量的目标。希望通过我们在本博客中提供的概述，您可以了解到
-
SLO 可以基于日志。在 Elastic 中，您可以使用 KQL 本质上查找和筛选特定日志和日志字段，以监视和触发 SLO。
-
AI 助手是一种有价值、易于使用的功能，可以分析、排除故障，甚至可能解决 SLO 问题。
-
基于 APM 服务的 SLO 易于创建和管理，并与 Elastic APM 集成。我们还使用 OTel 遥测来帮助监视 SLO。
有关 Elastic 中 SLO 的更多信息，请查看 Elastic 文档 和以下资源
准备好开始了吗？注册 Elastic Cloud，并尝试我上面概述的功能和特性，以最大限度地发挥 SLO 的价值和可见性。
本帖子中描述的任何功能或特性的发布和时间安排仍由 Elastic 自行决定。任何当前不可用的功能或特性可能不会按时或根本不交付。
在本博文中，我们可能使用或引用了第三方生成式 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 对第三方工具没有任何控制权，我们对其内容、操作或使用不承担任何责任或义务，也不对您使用此类工具可能造成的任何损失或损害负责。在使用包含个人、敏感或机密信息的 AI 工具时，请务必谨慎。您提交的任何数据都可能用于 AI 训练或其他目的。我们不保证您提供的信息将被安全或保密地保存。在使用任何生成式 AI 工具之前，您应该熟悉其隐私惯例和使用条款。
Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。