从日志和指标构建更好的SLO
原创从日志和指标构建更好的SLO
原创
为了帮助管理运营和业务指标，Elastic Observability 在 8.12 版本中引入了 SLO（服务级别目标）功能。本博客将回顾这一功能，并介绍如何使用 Elastic 的 AI 助手来实现 SLO。
在当今的数字化环境中，应用程序已经成为我们个人和职业生活的核心。我们已经习惯了这些应用程序始终可用且响应迅速。这种期望给开发人员和运营团队带来了巨大的压力。
站点可靠性工程师 (SRE) 面临着处理大量数据的艰巨任务，这些数据不仅来自应用程序本身，还来自底层基础设施。除了数据分析，他们还负责确保有效使用和开发运营工具。数据量的不断增长、日常问题的解决以及工具和流程的持续演变，都可能分散对业务绩效的关注。
Elastic Observability 提供了这一挑战的解决方案。它使 SRE 能够集成和检查所有遥测数据（日志、指标、跟踪和分析）以及业务指标。这种全面的数据分析方法促进了运营卓越，提高了生产力，并提供了关键的洞察力，这些都是在要求苛刻的数字环境中维护高性能应用程序所必需的。
为了帮助管理运营和业务指标，Elastic Observability 在 8.12 版本中引入了 SLO 功能。该功能允许为服务设定可衡量的性能目标，例如可用性、延迟、流量、错误和饱和度或定义您自己的。关键组件包括：
- 定义和监控 SLIs（服务级别指标）
- 监控表示允许性能不足的错误预算
- 对消耗错误预算的速率进行警报
用户可以通过仪表板实时监控 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 上执行以下操作：
- 定义基于 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 的消息数量很少，只有 17K。
我们可以创建一个 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 和测试 Observability 功能的一个常见应用程序是 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 文档 和以下资源：
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。