为什么客户选择 Elastic 来处理日志？

作者：来自 Elastic Ty Bekiares

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

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

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

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

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

当分秒必争时

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

当你评估日志供应商时，请阅读细则：虽然许多工具理论上可以满足你的搜索要求，但它们严格的 “schema-on-read - 读取时模式” 方法（其中数据未编入索引）可能会使最终用户的查询速度慢得令人沮丧，尤其是在需要时（例如，尝试对影响生产的问题进行根本原因分析）。

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

当你需要以新的方式搜索数据时，Elastic 还很容易认识到读取时模式的价值。运行时字段（runtime fields）让操作员无需重新索引即可从现有数据中提取新见解。在对新发现的问题执行 RCA 时，Elastic 的新 ES|QL 语言使分析师能够通过以直观、易读的格式将搜索、数据提取和丰富内容串联起来，快速构建战术查询。更多关于 ES|QL 方面的知识，请详细阅读博客。

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

云规模时代的日志记录

随着客户将工作负载转移到云和 Kubernetes，另一个实际限制也随之出现：这些技术带来的非线性规模使得简单的日志观察和警报（例如，在日志行中搜索“error”）变得不切实际。

Elastic 认识到了行业中的这一转折点，并推出了一套独特且一流的 AI 驱动工具，让 SRE 和开发人员能够减轻规模带来的复杂性。我们的开箱即用机器学习作业可以在日志率的峰值或下降确实是异常而不是预期的波动时发出警报。这种额外的智能可以减少警报疲劳，从而引起人们对实际问题的更多关注。

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

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

你的依赖项是什么？

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

Elastic 的新 AI 助手旨在解决这个问题，并在 SRE 之间创造公平的竞争环境。当 SRE 遇到他们不认识的日志行时，Elastic 的 AI 助手可以快速帮助他们了解日志行来自哪个库、是否是错误消息以及如何解决问题，所有这些都在 Elastic 可观察性界面内进行。

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

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

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

你的应用是否分布在多个云环境（例如 Azure 和 AWS）中？你是否同时部署了本地和云应用？未来几年，你选择的首选云提供商会发生变化吗？

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

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

选择 Elastic 进行日志记录意味着你不必将自己绑定到特定的云提供商。这意味着为你的 SRE 和开发人员提供统一的用户体验，无论应用程序或服务如何。使用 Elastic，你可以拥有一个独立于应用程序运营环境的集中式日志记录集群。或者，如果有令人信服的理由将日志记录集群与应用程序共置（例如，安全策略或成本），你可以在应用程序部署中分布多个 Elastic 集群。借助 Elastic 的跨集群搜索（cross-cluster search）技术，你的最终用户永远不会知道其中的区别 —— 他们将通过单个用户界面执行工作，而 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 的应用程序的首要平台。

我们完全由集群管理的 Elastic Agent 允许你在每个主机上部署一个具有集中配置的统一代理，以轻松配置和收集基础设施和服务遥测数据。Elastic 还与每个主要的云提供商合作，使将日志发送到 Elastic Cloud 变得像将日志发送到原生云提供商可观察性服务一样简单。

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

你的开发人员和 SRE 是否来自竞争性可观察性平台？我们的 Elastic AI Assistant 可以帮助你的最终用户快速上手，使用自然语言为他们编写查询（比如 “give me a list of pods whose memory was >= 90% of their limit - 给我一个内存大于等于其限制的 90% 的 pod 列表”）。

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

我们随时为你提供帮助！

在很大程度上，由于本文详述的创新，Elastic 已被 Gartner 和 Forrester 评为前三大可观察性供应商之一。这也是大公司继续求助于 Elastic 来满足其日志记录需求的原因。但不要轻信我们的话；亲自看看 Elastic 如何为古老的日志线带来新的价值。你可以在此处使用我们的演示集群，或使用免费的 Elastic Cloud 试用版针对你自己的日志数据进行测试。

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

原文：Why do customers choose Elastic for logs? | Elastic Blog