作者：来自 Elastic Ken Exner
停止追逐症状。了解 Elastic Observability 中的 Streams 如何修复可观测性中的根本性缺陷，利用 AI 主动在日志中找到"原因"，以实现更快速的解决。
SRE 常常被仪表盘和警报淹没，这些工具显示了问题是什么、在哪里，但未能揭示原因。整个行业对可视化症状的关注迫使工程师手动寻找答案。关键的 "原因" 隐藏在信息丰富的日志中，但其庞大的量和非结构化特性导致行业忽视它们，或者将其视为二等公民。结果，SRE 被迫将每次调查变成高压力、耗时的线索追踪。我们可以通过日志解决这个问题，但要释放它们的潜力，需要重新构想我们与日志的工作方式，并改善整体调查流程。
可观测性 ------ 破碎的承诺
要理解当前模型为何失败，让我们看看每个 SRE 都非常熟悉的挑战：知道问题存在，却需要花费宝贵时间去寻找调查的起点。
想象你收到支持团队的 Slack 消息："一些高价值客户报告支付失败。" 你有大量警报，但大多数只是标记症状，你不知道从哪里开始。你决定查看日志，看看是否有明显问题，从有高 CPU 警报的系统开始。
你花几分钟搜索和 grep 数 TB 的日志，查找受影响的客户 ID，试图拼凑出问题。没有结果。你担心没有获取到所有日志以揭示问题，于是开启了更多的应用日志。现在你被海量数据淹没，拼命寻找模式、错误或其他"提示"，试图找到原因。
最终，其中一个更广泛的日志查询命中了与受影响客户 ID 相关的错误代码。这是第一个真正的线索。你将搜索重点转向这个新错误代码，经过一小时的挖掘，终于找到了错误信息。你最终找到了原因，但这是一次压力巨大、手动完成的追踪，耗费了过多时间，并影响了更多客户。
这一事件完美地说明了现代可观测性破碎的承诺：调查过程完全失败。调查是手动、被动的过程，SRE 每天都被迫进行。Elastic 认为指标、追踪和日志都是必不可少的，但它们的角色以及它们之间的工作流程，必须被从根本上重新设计，才能实现有效调查。
可观测性意味着对发生了什么、在哪里以及为什么有最清晰的理解。指标对于理解 "发生了什么" 至关重要。它们是系统的心跳，驱动仪表盘和警报，告诉你阈值是否被触发，例如高 CPU 使用率或错误率。但指标是聚合数据；它们显示症状，却很少揭示根本原因。追踪有助于识别 "在哪里"。它们映射请求在分布式系统中的旅程，定位延迟激增或错误发生的具体微服务或函数。然而，其有效性依赖于完整且一致的代码埋点，这持续依赖开发团队，可能导致关键可见性缺口。日志告诉你 "为什么"。它们包含事件的丰富、上下文和未经过滤的真实信息。如果我们能够更主动、高效地从日志中提取信息，就能大大提升对环境的整体理解。
现代环境中日志的挑战
虽然日志在标准工具箱中，但长期被忽视。使用现有解决方案的 SRE 面临几个主要问题：
首先，由于日志的非结构化特性，很难解析和管理日志，使其有用。因此，许多 SRE 团队花费大量时间构建和维护复杂管道来管理这一过程。
其次，高量级日志会产生高成本，团队为了控制成本会舍弃日志，从而丢失宝贵信息。因此，当发生事件时，你会浪费宝贵时间寻找正确的日志，并手动跨服务关联。
最后，还没有日志解决方案能够主动发现日志中的重要信号，并在你需要时呈现关键的 "为什么"。因此，基于日志的调查既痛苦又缓慢。
为什么会出现这种情况？随着应用变得更复杂，日志量变得无法管理。行业没有用自动化解决，而是走了捷径：放弃充分利用日志，优先使用更易管理但信息量较少的信号。
这一决策是破碎、被动模型的起源。它将可观测性强制进入一个手动的 "观察" 警报循环，而不是构建能够帮助我们真正理解系统的自动化，从而改善根因分析和问题解决。这使 SRE 从调查者变成全职数据处理者，与 Grok 模式和脆弱的 ETL 脚本斗争，而不是解决系统中断问题。
引入 Streams，重新思考如何使用日志进行调查
Streams 是一种智能 AI 解决方案，简化了日志处理，帮助 SRE 团队快速理解问题背后的原因，从而更快解决问题。Elasticsearch 与 AI 的结合，将手动管理嘈杂日志转变为自动化工作流，能够识别模式、上下文和意义，标志着可观测性的一次根本性变革。
以任意格式记录所有内容
通过将 Elasticsearch 平台应用于上下文工程，将检索和 AI 驱动的解析结合起来以跟上模式变化，我们正在重新构想整个日志管道。
Streams 将来自所有来源的原始日志汇聚到单一目的地。然后，它使用 AI 将传入日志划分为逻辑组件，并解析以提取相关字段，供 SRE 验证、批准或修改。想象一个世界，你只需将日志指向一个终端，一切就能正常工作。无需再与 Grok 模式、处理器配置和寻找合适插件作斗争。所有这些都显著降低了复杂性。Streams 是实现这一愿景的重要一步。
因此，SRE 被解放出来，不必管理复杂的日志采集管道，从而可以花更少时间处理数据，更多时间用于防止服务中断。
使用 Significant Events 更快解决事件
Streams 中的 Significant Events 功能使用 AI 自动发现重大错误和异常，使你能够主动进行调查。这样，你无需再在无尽噪声中翻找，而可以专注于真正重要的事件，如启动和关闭消息、内存溢出错误、内部服务器故障及其他重要变化信号。这些事件作为可操作的标记，给 SRE 提供预警和清晰的焦点，使他们在服务受影响之前就能开始调查。
在这个新基础上，日志将成为主要的调查信号。紧张、手动地在数字干草堆中寻找针的时代即将结束。Significant Events 就像一个智能金属探测器，在混乱中筛选，只在发现问题时发出提示，帮助你轻松忽略干草，更快找到 "针"。
现在想象我们最初的场景。你无需再疯狂、耗时地 grep TB 级日志。Streams 已经完成了繁重工作。其 AI 驱动的分析在支持团队察觉之前就检测到新的异常模式，并自动将其标记为重大事件。线索不再是你去寻找，而是线索主动找到你。
只需一次点击，你就获得了原因：特定服务组件的 Java 内存溢出错误。这是你的起点。你在两分钟内找到根因并开始修复。客户影响被阻止，开发团队获取到具体错误，问题在升级前被控制。在此案例中，指标和追踪无法帮助发现原因，答案一直就在日志中。
这一理想结果之所以可能，是因为你既可以保留所有日志，又能立即在其中找到信号。Elastic 高效的架构结合强大的压缩、可搜索快照和数据分层，使完整保留成为现实。随后，Streams 自动呈现重大事件，确保答案不会淹没在噪声中。
Elastic 是唯一提供 AI 驱动的以日志为先的方法的公司，能够提升你的可观测性信号，使发现原因变得更快、更容易。这建立在我们数十年的搜索、相关性和强大分析能力的领导地位上，为深层语义理解日志提供了基础。
Streams 的愿景
你今天看到的日志划分、解析和 Significant Events 只是起点。我们愿景的下一步是利用 Significant Events 自动生成关键的 SRE 产出物。想象一下，Streams 基于真正影响服务健康的事件，创建智能警报、即时调查仪表盘，甚至生成数据驱动的 SLO。之后的目标是利用 AI 直接从日志模式驱动自动化根因分析（RCA），并生成修复运行手册，将多小时的排查变为即时的解决建议。
一旦建立了这一 AI 驱动的日志基础，Streams 的愿景将扩展为跨所有遥测数据运行的统一智能层。重点不仅在于单独优化每个信号，而是理解它们之间的上下文和关系，从而解决复杂问题。
对于指标，Streams 不仅会提醒你单个指标的突增，还能检测多个看似无关指标之间的相关异常，例如特定服务的 p99 延迟、垃圾回收时间增加、事务成功率变化。
同样，对于追踪，它能识别关键事务路径中新出现的、意外的服务调用（如新的数据库或外部 API），或者发现某个特定 span 突然成为所有追踪中大多数错误的来源，即使整体错误率未超过阈值。
目标不是为日志、指标和追踪建立独立的 Streams，而是将它们编织成单一叙事，自动关联这三类信号。最终，Streams 的核心在于将目标从人工主导的数据收集转变为主动、AI 驱动的解决方案。
了解更多关于 Streams：
-
阅读 Streams 发布博客
-
查看 Streams 网站