Fluentd vs Logstash：后端停了二十分钟，日志怎么办

日志后端维护了二十分钟，应用还在不断写日志。恢复以后，值班同事最想知道三件事：这段时间的数据有没有留下，积压多久能送完，重试是否让同一条错误出现了两次。平时每秒能处理多少条，到了这里才有了实际意义。

Fluentd 和 Logstash 都可以承担接收、处理与转发事件的工作。它们不是存储、搜索和告警平台的完整替代品，也不能仅凭“轻量”或“功能强”决定谁更适合。真正的选择通常落在现有插件、转换逻辑，以及下游不可用时希望保住哪一段数据上。

观测云编辑部 · 资料核对日期：2026 年 10 月 21 日。文中的容量例子是算术示意，没有执行双方吞吐或故障恢复实测。

一条事件怎样走过处理链

Fluentd 的事件由 tag、time 和 record 组成，输入插件生成事件，过滤器处理字段，匹配规则把事件路由到输出。Tag 可以参与分流，但它不是自动保证一致的业务分类；不同来源的命名与字段仍需要约定。事件生命周期。

Logstash 使用 inputs、filters、outputs 三段处理结构，并可在输入输出边界使用 codec。比如对混合文本先解码，再解析日期、转换字段类型，最后送到对应目标；它的输出并不局限于 Elasticsearch。处理模型。

这两种模型都能完成不少常见任务。若已经维护大量 Logstash 过滤逻辑，换工具意味着重新验证日期、空值、字段类型和失败事件，不只是翻译配置语法。反过来，已有 Fluentd 路由和输出插件的团队，也没有必要仅因为后端使用 Elasticsearch 就整体重写。

更有价值的试样，是几条过去真正出过问题的事件：带时区的时间、跨行异常、字段偶尔变成数组的 JSON，以及解析失败的原始文本。先确认转换后的含义保持一致，再测资源与吞吐；否则只是更快地送出了另一份数据。

缓冲的位置，决定它保护什么

Fluentd 的缓冲与支持缓冲的输出插件结合，按 chunk 管理事件，可以使用内存或文件。不是所有输出模式都经过相同缓冲；未显式指定时，还要看输出插件自身默认设置。文件缓冲更适合需要跨进程重启保留数据的场景，但磁盘路径和持久卷也必须可靠。缓冲配置、输出模式。

Logstash 的 Persistent Queue 位于输入与过滤/输出之间，默认没有开启。它把正在处理的数据写入本地队列，支持重启后的重放，但 checkpoint 提交前的异常关闭仍可能丢数据，磁盘也没有自动复制。PQ 不能把无确认机制的输入变成端到端可靠传输，例如 UDP 发送端并不知道接收方是否真正留下数据。Persistent Queue。

因此，应该沿数据路径问“谁已经确认了什么”。应用写入本地文件、采集器读到内容、接收节点返回成功、最终搜索后端可查询，是几个不同阶段。中间增加一个本地磁盘队列，可以改善其中一段，却不会自动覆盖所有阶段的故障。

如果需要承受整台采集节点永久丢失，应评估上游可重读数据、外部复制队列或其他恢复设计。单纯把内存 buffer 换成磁盘，保护的是不同的故障类型，不是给整个系统增加无限可靠性。

ACK 与重试会改变重复和丢失的边界

Fluentd 的 out_forward 默认是 at-most-once。设置 require_ack_response true 后，插件等待接收端 in_forward 的 ACK，以提供 at-least-once 语义。这个 ACK 来自下一跳，不应自动解释为最终搜索后端已经持久化。forward 输出。

At-least-once 也意味着需要处理重复：接收方完成处理、响应却在途中丢失，发送方可能再次发送。若下游用日志数量计算交易次数，重复的影响会比多看一条日志更严重。能否用稳定事件标识去重、在哪层去重，应由业务用途决定。

重试耗尽时的行为还有版本差异。Fluentd v1.19.0，也就是 fluent-package v6 起，内置文件缓冲会在清空队列前把 chunk 文件转移到恢复目录；此前相应情况会丢弃队列。内存缓冲没有这项文件恢复能力，第三方缓冲需自行实现支持。恢复目录、磁盘空间和人工恢复过程都应纳入运行安排。缓冲与重试。

Logstash PQ 也可能在恢复时重放尚未确认完成的事件，造成重复。调小 checkpoint 间隔可以加强持久性，但会增加磁盘写入成本；它不是免费的可靠性提升。具体选择应通过自己的事件大小、存储与输出响应测试，而不是照抄某个“安全参数”。PQ 持久性说明。

缓冲满了，压力最终要去某个地方

Fluentd 对缓冲溢出有抛异常、阻塞或丢弃最旧 chunk 等策略，默认是抛异常；实际结果还取决于输入能否暂停、重试或重新读取。选择阻塞，不代表远端 UDP 发送方也会停下来。溢出行为。

Logstash PQ 填满后会对输入施加背压，而每种输入对背压的响应不同。这里最重要的是监控排队时间和余量，而不只是进程还活着。一条延迟半小时才到达的错误日志，虽然没有丢失，也可能已经错过了告警价值。PQ 与背压。

假设需要在完全无法输出时容纳 10 MB/s 的原始事件，二十分钟就是 12 GB，按十进制单位计算。这还没包括序列化、元数据、文件布局、峰值余量与其他 pipeline；不能直接把队列容量设成 12 GB 就称之为验证完成。

恢复速度同样值得算。若持续输入仍为 10 MB/s，后端只能以相同口径接收 15 MB/s，净排空能力是 5 MB/s，理想情况下清掉 12 GB 还要四十分钟。若输出能力只回到 10 MB/s，积压不会自行消失。这是容量规划的简单边界，不是两个工具的性能预测。

插件与运行时，要跟着实际版本选

Fluentd 主要使用 C 与 Ruby，插件生态与 Ruby gem 依赖有关；Fluent Bit 是相关但独立的项目，可以单独部署，也可以与 Fluentd 配合，并非随意替换配置的“小号 Fluentd”。官方两项目介绍适合了解定位，不应把其中的简化资源数字当作自己工作负载的容量保证。Fluentd 与 Fluent Bit。

Logstash 使用 JVM，插件也不应笼统描述成只能用 Ruby：官方提供 Java 插件 API。实际选择应看目标插件支持的版本、维护状态、字段语义和错误处理，再评估运行时资源。Java 插件。

许可也需看具体范围。Fluentd 主项目为 Apache 2.0；Logstash 仓库说明，除指定例外外，x-pack 外的代码为 Apache 2.0，x-pack 内适用 Elastic License。不能把 Elasticsearch 的许可变化直接套到所有 Logstash 代码，也不应把所有发行物都说成同一许可。Fluentd 许可、Logstash 许可。

先让故障恢复可解释，再决定换不换

已有成熟 Logstash 转换与运维流程，就先验证 PQ、输出响应和恢复行为；已有 Fluentd 路由与目标插件，则优先把文件缓冲、ACK 和溢出策略配置清楚。没有哪种运行时或插件数量能替代这些工作。

如果当前链路已经可靠，迁移应有明确收益，例如减少需要维护的转换逻辑，或满足新来源的协议要求。最终验收不只看正常发送成功，还要能解释下游暂停、采集器重启、缓冲耗尽和重试后的数据结果。

观测云接入仍要遵守同样的数据边界

如果也在评估后端，观测云 DataKit 可以采集日志，并通过 Pipeline 做字段处理。可以先用相同事件样本核对转换与查询结果，再安排迁移。采集器承担数据接入，平台承担后续存储分析；换成托管后端也不会取消源端文件、网络和发送失败的处理责任。观测云日志采集。