作者：来自 Elastic Luca Wintergerst
当你的 Streams 摄取管道出现故障时，失败的文档会进入失败存储（failure store），而不是直接丢失。下面介绍如何利用这些失败记录来修复你的管道，而无需从源头重新摄取数据。
如果你已经运行 Streams 流水线超过一周，你很可能遇到过处理失败的问题。在 Streams 之前，这通常意味着数据丢失，或者需要在 shipper 层维护一个死信队列（dead letter queue），这是一套必须单独运维的额外基础设施。下面是现在的恢复流程。
当处理失败时，数据会进入失败存储
当 Streams 流水线发生失败（例如 Grok 模式无法匹配，或者字段类型与 mapping 冲突），导致失败的文档会被写入失败存储（failure store）下面的。失败存储是一组附属于你的 data stream 的底层索引。它与任何 data stream 一样具备扩展能力，因此可以承载所有失败数据。从 Elasticsearch 9.2 起，它在日志场景中默认启用。
Data quality（数据质量）标签页可以提供关于 stream 质量以及失败存储中文档的洞察。当失败不断累积时，你会看到失败文档数量上升，并同时展示错误类型以及触发这些错误的消息样本。
Data quality（数据质量）标签页显示失败数量正在上升，同时展示错误类型以及触发这些错误的文档样本。
一个 Grok 表达式不匹配（illegal_argument_exception）正在将文档发送到失败存储。原始日志行不符合预期模式。这些文档不会被丢弃，而是被保存在失败存储中，等待用于调试。
处理：将样本源切换到失败存储
首先进入 Processing（处理）标签页。
默认情况下，编辑器会从最近的实时文档中取样。将样本源切换为 Failure store（失败存储）：它会加载所有失败的文档，即 Streams 处理运行之前的原始未修改数据。你是在基于真实失败数据进行迭代。
将样本源下拉选项从默认值切换为 Failure store。
已选择 Failure store 选项的源下拉菜单。
编辑器会从失败存储中加载最多 100 个文档，并使用当前管道对它们进行处理。你可以准确看到解析在哪一步出现问题。
管道编辑器加载的是来自 failure store 的文档，而不是最近的实时样本。
修复针对真实失败的 processor
当 failure store 中的文档被加载为样本后，就可以开始迭代调整 processor。编辑器会在实时环境中展示它对这些实际失败文档的处理结果。
在这个示例中，该 pipeline 最初是为了解析 HTTP access logs 而构建的：
`
1. DELETE /api/v1/auth/logout from 26.72.241.177 - Status: 200 - Response time: 38ms - Request ID: req_24363339 - Location: São Paulo, BR - Device: desktop
2. HEAD /api/v1/notifications from 20.94.145.254 - Status: 202 - Response time: 60ms - Request ID: req_74513322 - Location: Tokyo, JP - Device: mobile
`AI写代码
最初的 Grok 模式可以成功匹配这些日志：
`%{WORD:http.method} %{URIPATH:uri.path}` AI写代码
第二种日志类型开始进入系统。缓存命中（cache hits）和外部 API 调用以不同的格式到达：
`
1. cache_hit: Cache hit for key: config
2. external_api_call: External API call completed - latency: 1695ms - Duration: 598ms
`AI写代码
原始模式完全无法匹配这些日志。所有记录都会直接进入 failure store。由于已经将 failure store 作为样本源加载，问题立刻变得非常明显：编辑器显示解析在 “以一个单词加冒号开头” 的行上失败，而不是像之前那样匹配 “HTTP 方法 + 路径”。
修复方法是添加第二个 pattern 来处理新的格式：
`%{WORD:event.type}: %{GREEDYDATA:message}` AI写代码
将其添加到 processor 中后，编辑器会立即在 failure store 样本上显示两种日志类型都能被正确解析。
当样本视图显示所有字段都能正确提取，并且解析率达到 100% 时，说明修复已经完成并可以投入使用。
在添加第二个 Grok 模式之后，两种日志类型都能被正确解析。解析率达到 100%。
没有猜测 —— 编辑器会在你保存之前就确认修复是否正确。
观察失败数量下降
保存更新后的 pipeline。新的文档现在会使用修复后的 pipeline 进行处理。切换回 Data quality 标签页，观察失败计数的变化。
随着新文档通过修复后的 pipeline 进行处理，失败数量正在下降。
当修复后的 pipeline 正确处理新到达的数据时，计数会下降。失败存储中剩余的文档是修复之前产生的失败数据，它们会随着保留策略逐渐过期并被清理。
这个修复只作用于新文档。已经进入 failure store 的文档不会自动重新处理；每一条记录都由它到达时所对应的 pipeline 版本处理生成。如果你需要把这些数据重新纳入主数据流，这是一个单独的步骤。
恢复闭环
打开 Data quality，切换到 failure store，修复 processor，保存。整个流程通常只需要几分钟。
不需要从源头重新摄取数据，也不需要在 shipper 层维护 dead letter queue。如果你最近没有检查 Streams 的 Data quality 标签页，值得看一眼，可能已经有一些失败记录，只需要一个小修复就能解决。
关于 Data quality 标签页展示内容以及 failure store 配置的更深入说明，可以参考：Elastic 可观测性：Streams 数据质量与失败存储洞察。
