Observability：客户为什么选择 Elastic 做日志？

作者：Ty Bekiares

Elastic 正在改变日志体验以满足现代工作流程的需求。

在没有其他可观察信号的情况下，通常基础设施中的所有内容（硬件、软件和服务）都会发出日志行。 然而，日志通常是根据开发人员的想法构建的，并且首先也是最重要的是满足开发人员的需求（例如，调试）。 一旦投入生产，这些相同的日志行本质上会被提升为观察应用程序和基础设施的一流方法，无论其最初意图如何。 这使得日志成为众所周知的噪声可观测信号，其速率可能会随着错误和规模的变化而剧烈波动。

日志行作为可观察性信号的简单性（从根本上来说，它只是文本！）使其易于观察。 另一方面，它的噪声、非结构化性质和不可预测的速率使其成为最难利用的信号之一。

如今有许多供应商提供包括日志记录在内的可观察性解决方案。 值得注意的是，这些解决方案中的大多数仅服务于最基本的用例：文本搜索。 Elastic? 知道你的日志行包含的价值远高于任何一条消息中包含的文本。 Elastic 利用机器学习 (ML) 和人工智能 (AI) 以及生成式 AI，可以对你的日志进行聚合分析，将日志行从反应式调试工具转变为干净、主动的监控和警报工具。

在本博客中，我们将传达开发人员和站点可靠性工程师 (site reliability engineers -?SRE) 如今面临的挑战，并解释 Elastic 如何提升古老的日志行来应对这些挑战。

当分钟很重要时

当你的 SRE 和开发人员尝试对问题进行根本原因分析 (root cause analyze - RCA) 时，关键在于平均解决时间 (mean time to resolution - MTTR)：搜索速度与直观的查询语言相结合，可以区分严重中断和轻微服务中断。

当你评估日志记录供应商时，请阅读细则：虽然许多工具理论上可以满足你的搜索要求，但它们严格的 “读取模式 (schema-on-read)” 方法（其中数据未建立索引）可能会使最终用户的查询速度慢得令人沮丧， 特别是在有需要的时候（例如，试图从根本上找出影响生产的问题）。

相比之下，Elastic 本身支持写入模式 (schema-on-write)，其中数据在摄取时以针对搜索优化的方式建立索引。 与读取模式相比，这种方法使文本搜索速度极快，显着提高了需要每天处理日志信号的开发人员和 SRE 的效率。 此外，通过减少摩擦，开发人员和 SRE 更有可能采用可观察性工具作为其工作流程中的日常驱动程序，从而提高软件和系统质量。

当你需要以新的方式搜索数据时，Elastic 也很容易认识到读取模式对于用例的价值。 运行时字段使操作员可以从现有数据中提取新的见解，而无需重新索引。 在对新发现的问题执行 RCA 时，Elastic 的新 ES|QL 语言使分析师能够通过以直观、易于阅读的格式将搜索、数据提取和丰富结合在一起来快速构建战术查询。

总之，这些工具可以让你的分析师以最适合手头任务的方式查询日志行，而不是以人为的方式限制你的分析师，这可能会混淆或延迟问题的根本原因分析。

记录云规模时代

当客户将工作负载转移到云和 Kubernetes 时，引入了另一个实际约束：这些技术实现的非线性规模使得微不足道的日志观察和警报（例如，在日志行中搜索 “*error*”）可以说是不切实际的。

Elastic 认识到了行业的这一拐点，并推出了一系列独特且一流的 AI 驱动工具来应对，帮助 SRE 和开发人员减轻规模带来的复杂性。 当日志率的峰值或下降确实是异常而不是简单的预期波动时，我们开箱即用的机器学习作业可以发出警报。 这种增加的智能可以减少警报疲劳，从而使人们更加关注实际问题。

一旦触发警报，Elastic 的 AI 驱动的日志峰值分析工具就可以快速自动评估日志速率发生变化的原因：它是一个应用程序吗？ 只发生在一个地区吗？ 构成此更改的日志消息是否有共性？ 从历史上看，为了回答这些问题，SRE 需要花费大量时间手动比较日志和元数据，以确定日志速率的变化是否是真正的问题，如果是，则确定其根本原因。 借助 Elastic 的日志峰值分析工具，这一艰巨的过程可缩短至短短几秒钟。

使用正确的工具，日志可以从被动式调试工具转变为主动式业务和运营监控工具。 Elastic 的 AI 驱动的日志模式分析工具可以快速识别来自应用程序的日志行模式并对其进行分类。 这使得你可以轻松地发现随时间（和频率）重复出现的日志模式，这可能表明运营状态或业务 KPI。 从那里，你可以利用我们的摄取管道将日志行中的特定数据点释放为可操作的数据（例如警报和可视化）。

你的依赖是什么？

如今的开发人员依赖无数的第三方库、服务和容器层来快速构建复杂的应用程序和服务。 然而，这些依赖关系的广泛性已经成为 SRE 的真正挑战。 SRE 通常不知道使用了哪些第三方库。 此外，不能指望 SRE 能够轻松识别这些第三方库在其相应日志行中使用的术语。

Elastic 的新 AI 助手旨在解决这个问题并为 SRE 提供公平的竞争环境。 当 SRE 遇到他们无法识别的日志行时，Elastic 的 AI Assistant 可以快速帮助他们了解日志行来自哪个库、是否是错误消息以及如何解决问题，同时保持在正确的范围内。 Elastic 可观测性接口。

如果日志行来自自定义应用程序代码，Elastic 的 AI Assistant 可以进一步参考你自己的运行手册和文档，以帮助 SRE 快速了解要采取的操作。 如果日志行指示错误，我们的 AI 助手可以将你的 SRE 引导至现有的相关 GitHub 问题，以便他们可以快速了解这是新问题还是已知问题。

Elastic AI Assistant 旨在与你的分析师合作，节省他们的手动查找时间，并引导他们比以往更快、更准确地找到 RCA。 Elastic 认识到任何 AI Assistant 技术固有的安全问题，并专门考虑到这些问题而设计了 Elastic AI Assistant。 利用 Elastic 最先进的 ESRE 和检索增强生成 (RAG) 技术，你的操作手册和文档将被保密。

我们会在你所在的地方与你会面

你的应用程序是否分布在多个云环境（例如 Azure 和 AWS）中？ 你是否混合使用本地和云应用程序部署？ 你对首选云提供商的选择在未来几年可能会发生变化吗？

毫不奇怪，公共云提供商本机的日志解决方案通常不适合从提供商边界之外捕获日志数据。 虽然存在机制，但它们通常支持很差，并且缺乏通常可用于在给定云提供商的围墙花园内运行的应用程序的功能（丰富的元数据、集中配置、错误恢复）。

一些客户可能会根据其应用程序的位置选择使用不同的日志记录解决方案。 然而，这种设计模式可能会使将来在项目之间移动应用程序或开发人员变得困难。 此外，SRE 通常需要跨应用程序团队工作，要求他们了解多种日志记录工具的细微差别。 所有这些都会增加 RCA 流程的延迟，降低团队的效率，并最终导致摩擦。 这种摩擦反过来会减少工具的使用，使你的团队对潜在的操作问题视而不见。

选择 Elastic 进行日志记录意味着不要将自己束缚于特定的云提供商。 这意味着为你的 SRE 和开发人员提供统一的用户体验，无论应用程序或服务如何。 借助 Elastic，你可以拥有一个集中式日志记录集群，独立于应用程序的操作环境。 或者，如果有令人信服的理由将日志记录集群与应用程序并置（例如，安全策略或成本），你可以在应用程序部署中分布多个 Elastic 集群。 借助 Elastic 的跨集群搜索 (CCS) 技术，你的最终用户将永远不会知道其中的差异 - 他们将通过单个用户界面执行工作，而 Elastic 则负责找出所需数据所在位置的繁重工作。

控制成本

日志信号的噪声和突发性会很快导致竞争性日志解决方案的成本失控。

对于云提供商原生的日志服务，成本结构通常非常复杂。 这使得了解如何降低成本变得具有挑战性。 此外，与云提供商日志记录解决方案相关的费用通常会被掩盖为整个云提供商账单上的一个项目，因此很容易被忽视，尽管它们的成本很高。 相比之下，Elastic 的定价透明且直接：我们向你收取在指定时间段内登陆、搜索和保留日志所需的存储和计算费用。

对于其他云托管的日志记录解决方案，高保留成本会不利地鼓励缩短数据保留期或离线数据湖，从而导致问题和操作状态的可见性降低。 Elastic 的冻结数据层使所有旧日志数据保持在线且可搜索，同时保持成本相对平稳。 你可以获得数据湖的所有成本优势，而无需承担与数据补充相关的运营开销。

此外，Elastic 灵活的部署模式为你提供了将日志记录成本控制在合理范围内的工具：

• 为了帮助降低在云中运行的应用程序传出日志的成本，我们支持所有主要云提供商在你的云应用程序 VPC 和 Elastic Cloud??VPC 之间进行 VPC 对等。
• 为了帮助降低测试、开发和非生产环境的成本，Elastic Cloud 可让你快速部署、扩展、测试和拆除环境； 你只需为你需要的时间付费。

将它们结合在一起

Elastic 坚信，可观察性的未来是日志记录、APM、基础设施监控、安全性和分析完全集成，通过单个统一界面提供整体视图。 这样做可以将所有可观测性数据放在一处，无摩擦。 这反过来又会鼓励你的 SRE 从多个角度看待问题，帮助他们更快、更准确地制定明确的 RCA。

Elastic Agent 以及我们对 OpenTelemetry 的支持让你可以轻松地将所有可观测信号提取到 Elastic 中。 你的日志行将使用与 APM 数据相同的元数据进行标记，从而使分析师能够快速轻松地在信号之间进行转换，而无需手动时间跨度或地址关联。

当你的内部技术路线图走向工具整合和整体监控时，请考虑哪些日志记录供应商能够最终获取你的所有遥测信号。 Elastic 允许你从日志开始，然后随着时间的推移将 APM、基础设施监控、分析和安全性添加到同一个可观察性平台。 改变是困难的，但融合可观测性解决方案的成本和运营收益是不可估量的。

最后，Elastic 还具有独特的优势，可以提取、处理并将你的业务指标和 KPI 与可观察性数据结合在一起。 你知道你的基础设施如何影响收入吗？ 或者特定的中断如何影响客户体验？ Elastic 的开放数据平台支持这种级别的关联性，使你能够以针对你的业务优化的方式花费基础设施资金； 它还可以帮助证明你在可观察性方面的支出是合理的。

把事情简单化

Elastic 了解你希望让运营人员专注于运行业务应用程序，而不是运行日志记录基础设施。 为此，Elastic 继续进行大量投资，以简化我们的可观察性平台的入门和操作。

我们对 OpenTelemetry 的持续承诺让你只需投资一次即可全面检测你的应用程序，而无需担心供应商锁定。 2023 年 4 月，Elastic 将我们的Elastic Common Schema (ECS) 贡献给 Open Telemetry，进一步使 Elastic 成为观察支持 OpenTelemetry 的应用程序的首选平台。

我们完全由 fleet 管理的 Elastic Agent可让你通过集中配置为每台主机部署一个统一代理，以轻松配置和收集基础设施和服务遥测数据。 Elastic 还与各大云提供商合作，使向 Elastic Cloud 发送日志就像向本机云提供商可观测性服务发送日志一样简单。

我们正在改变行业对入职日志文件的思考方式。 我们的新体验将抽象出索引、策略和映射的复杂性，让你专注于日志中的数据，而不是管理日志文件本身。

你的开发人员和 SRE 是否来自有竞争力的可观察平台？ 我们的 Elastic AI 助手可以帮助你的最终用户加入，使用自然语言为他们编写查询（即 “give me a list of pods whose memory was >= 90% of their limit”）。

最后，我们即将推出的 Elastic Cloud Serverless?产品将作为完全托管的云服务提供可观察性（包括日志记录）。 借助 Serverless，Elastic 将管理计算、存储和运营的各个方面； 你只需要带来遥测数据和最终用户！

我们随时为你提供帮助！

在很大程度上，由于此处详细介绍的创新，Elastic 已被 Gartner 和 Forrester 评为排名前 3 的可观测性供应商。 这也是大公司继续转向 Elastic 来满足其日志记录需求的原因。 但不要相信我们的话； 亲眼看看 Elastic 如何为古老的日志行带来新的价值。 你可以在此处使用我们的演示集群，或者通过免费的 Elastic Cloud 试用版来测试你自己的日志数据。

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

原文：https://www.elastic.co/blog/why-do-customers-choose-elastic-for-logs