在当今的数字环境中，应用程序已成为我们个人和职业生活中不可或缺的一部分。我们已经习惯了这些应用程序始终可用并能够快速响应。这种期望给开发人员和运维团队带来了巨大的压力。
站点可靠性工程师 (SRE) 面临着从海量数据中筛选信息的艰巨任务，这些数据不仅来自应用程序本身，还来自底层基础设施。除了数据分析之外，他们还负责确保有效地使用和开发运维工具。不断增长的数据量、日常问题解决以及工具和流程的持续演变可能会分散对业务绩效的关注。
Elastic 可观测性为此挑战提供了解决方案。它使 SRE 能够与业务指标结合，集成和检查所有遥测数据（日志、指标、跟踪和分析）。这种对数据分析的全面方法促进了运营卓越，提高了生产力，并产生了关键见解，所有这些对于在苛刻的数字环境中维护高性能应用程序都至关重要。
为了帮助管理运营和业务指标，Elastic 可观测性在8.12版本中引入了 SLO（服务水平目标）功能。此功能使您可以为服务设置可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度，或自定义定义。关键组件包括
-
定义和监控服务水平指标 (SLI)
-
监控错误预算，指示允许的性能下降
-
针对显示错误预算消耗的燃尽率发出警报
用户可以使用仪表板实时监控 SLO，跟踪历史性能并接收潜在问题的警报。此外，SLO 仪表板面板提供了自定义可视化效果。
服务水平目标 (SLO) 通常适用于我们的白金版和企业版订阅客户。
在本篇博文中，我们将概述以下内容
-
什么是 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 的消息数量很少，例如 17000 条。
与其创建警报，我们可以使用此查询创建 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 演示购物车服务
应用程序开发人员和 SRE 使用OpenTelemetry 演示来了解 OpenTelemetry 并测试可观察性功能。
此演示具有特性标志来模拟问题。借助 Elastic 的警报和 SLO 功能，您还可以确定整个应用程序的性能以及使用这些特性标志时客户体验的保持情况。
Elastic 通过直接接收 OTLP 来支持 OpenTelemetry，无需使用 Elastic 特定的代理。您可以直接从应用程序（通过 OTel 库）和通过收集器发送 OpenTelemetry 数据。
我们在 K8S 集群（AWS EKS）上启动了 OpenTelemetry 演示并启用了购物车服务特性标志。这会在购物车服务中插入错误。我们还创建了两个 SLO 来监控购物车服务的可用性和延迟。
我们可以看到购物车服务的可用性已违反。当我们深入挖掘时，我们会发现成功的交易数量并不多，这影响了 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. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称是其各自所有者的商标、徽标或注册商标。