先说结论：这三个东西不是三选一的竞品关系，很多人一开始就把问题问错了。它们分别对应采集链路上的不同角色------轻量转发、重量级转换、以及统一代理；真正该问的是「我的这条链路上需不需要转换层」和「队列要不要落盘」。把这两个问题答清楚，选型自然就出来了。
采集层的三类角色，真的需要三选一吗？
把整个链路拆开看，日志从产生到进存储要经过三个阶段：采集（读文件、读容器流）→ 处理（解析、富化、路由）→ 投递（写进目标）。
三类角色分别对应：
- 轻量转发器：只做采集和投递，处理能力有限，资源占用小，适合铺在每个节点上；
- 聚合与转换层：跑在中间，负责解析、路由、缓冲，资源占用大，适合集中部署；
- 统一代理：想用一个二进制同时覆盖上面两件事，还包括指标和链路数据。
把 Filebeat / Logstash / Fluent Bit 硬拉成三选一，结果通常是要么在节点上铺了太重的组件，要么在需要复杂解析时发现转发器根本做不到。
| 组件 | 语言 | 定位 | 资源特征 |
|---|---|---|---|
| Filebeat | Go | 轻量转发器，只能配一个 output | 节点级，占用小 |
| Logstash | JVM | 转换与聚合 | 单实例起步数百 MB |
| Fluent Bit | C | 轻量代理，可采集也可做聚合 | 最小足迹约 450KB，零外部依赖 |
| Fluentd | Ruby + C | 插件广度优先的聚合层 | 官方对比表标注 60MB 以上 |
顺带澄清一个在中文圈子里流传很广的错误说法：Fluent Bit 不是 Elastic 维护的。它属于 CNCF 下 Fluent 组织，是 graduated 项目，由一家可观测性厂商赞助，与 Elastic 没有维护关系。Elastic 维护的是 Beats 和 Elastic Agent 这一条线。
Filebeat 为什么只能配一个 output？
这条限制听起来像个小缺陷，实际上它是 Filebeat 定位的核心表达：它假设日志只有一个终点。
只要你的日志需要同时发往 Elasticsearch 和 Kafka，或者需要按内容分流到两个不同的索引，就必须在中间加一层能多路投递的组件。而 Filebeat 的价值恰恰来自这个「不灵活」------它的配置面窄，所以能在每个节点上稳定跑着不惹事。
它也有一条硬性的队列限制需要知道：Fleet 管理的 Agent 和独立模式的 Agent 都只能配置内存队列，不支持用户配置磁盘队列。这一条直接决定了它的数据可靠性上限，下一节展开。
什么时候必须上 Logstash？
如果你只是「把文件内容原样送进 ES」，Logstash 是过剩的。它真正不可替代的地方是这几类需求：
- 复杂解析：grok 正则拆字段、ruby filter 做任意逻辑；
- 条件路由与多目的地：一份输入分流到多个索引或多个后端；
- 当缓冲垫：下游抖动时用持久队列顶住，避免采集端被反压回退。
它的配置里最常被调的两个参数是 pipeline.workers（默认等于 CPU 核数）和 pipeline.batch.size（默认 125），后者决定一次批量处理多少事件。
text
# pipeline 段的典型关注点
pipeline.workers: 8
pipeline.batch.size: 125
pipeline.batch.delay: 50
queue.type: persisted还有一个版本门槛必须提醒：Logstash 9.4 起最低要求 Java 21，17 及以下不再支持。如果升级时只看了功能说明没看这个，容器镜像会直接起不来。
队列的默认值被改过，老教程里的数字还对吗？
这是我认为最容易让人误判的一节，因为大量中文资料引用的还是七八年前的默认值。
| 组件 | 参数 | 当前默认值 | 旧资料常见错误值 |
|---|---|---|---|
| Filebeat | queue.mem.events |
3200 | 4096 |
| Filebeat | queue.mem.flush.min_events |
1600 | 2048 |
| Filebeat | queue.mem.flush.timeout |
10 秒 | 1 秒 |
| Filebeat | ES output 的 bulk_max_size |
50 | 2048（那是 Kafka output 的值） |
| Logstash | queue.max_bytes（持久队列） |
1GB | --- |
| Logstash | queue.checkpoint.acks / writes |
1024 | --- |
| Fluent Bit | storage.type |
memory | --- |
| Fluent Bit | mem_buf_limit |
0（不限制） | --- |
yaml
# Filebeat 的内存队列：满了就阻塞输入，这是它的背压方式
queue.mem:
events: 3200
flush.min_events: 1600
flush.timeout: 10s关于 flush.min_events 还有一个已经过时的认知需要更新：从某个版本起，用它来限制批大小不再有任何性能收益 ，实际批次大小取 bulk_max_size 和 flush.min_events 里的较小值。所以现在调批量的正确落点是 bulk_max_size。
三家的背压逻辑本质相同：队列满了就阻塞输入，把压力往回传 。区别在于队列满了之后还剩多少余地。Filebeat 内存队列满时，新事件根本插不进去；Fluent Bit 的内存环形缓冲模式则是主动丢最旧的 chunk，而不是暂停------这两种行为在事故中的表现完全不同。
「采集端崩了数据丢不丢」取决于队列是否落盘
这是选型时最该问的一个问题，答案不是「会不会丢」，而是「丢多少、能不能重放」。
| 组件 | 内存队列 | 落盘队列 |
|---|---|---|
| Filebeat | 进程崩溃即丢 | 磁盘队列可跨重启保留 |
| Logstash | 崩溃即丢 | 持久队列至少一次投递，未 checkpoint 的部分会丢 |
| Fluent Bit | 官方原文明确「更容易丢数据」 | 文件系统模式「不易丢数据」，环形缓冲按设计丢最旧 |
有一点必须提前知道，否则会被「至少一次」这四个字误导：Logstash 的持久队列提供的是 at-least-once，崩溃重放会导致重复事件。也就是说，你换来的不是「不丢」，而是「不丢但可能重」。下游如果是计费或审计类场景，这个代价要先想清楚。
还有一个反直觉的取舍：Elastic 官方已经明确推荐在多数场景下用 Agent 取代独立的 Beats，但Agent 只支持内存队列。所以「用官方推荐方案」和「要磁盘队列」这两个诉求在当前是有冲突的，得自己权衡。
为什么日志会重复采集？
重复的成因基本就四类，都能事前规避：
- 多个 input 覆盖了同一个文件；
- filestream input 没写
id，或者写完之后又改了id------官方原文说得很直接：省略或更改 id 可能导致数据重复； - 老的 log input 和新的 filestream 同时采同一个文件；
- 删掉了 registry 目录，导致位移记录丢失、从头重放。
机制上值得一提的是识别方式的变化：新的 filestream 默认按内容指纹识别文件，而不是按 inode。这是为了解决 inode 复用导致的重采问题------同一台机器上文件删了又建，inode 会被回收，按 inode 认人就会认错。
text
# filestream input 必须显式给一个稳定不变的 id
- type: filestream
id: app-log-nginx
paths:
- /var/log/nginx/*.log另外那条「小于 1024 字节的文件默认不采」的规则也值得记一下，它解释了很多「日志文件明明建了却没上报」的现象。
「采不到日志」和「丢日志」，为什么要分开查？
这两类现象看起来像，根因完全不同。
丢日志 的经典成因是 harvester 关闭期间文件被移动或删除------官方文档明确写着：如果文件在采集器关闭时被移动或删除，还没读完的数据就会丢失。而且 close_* 系列参数是同步应用的，输出阻塞时文件不会被及时关闭，这一点会打乱你对「什么时候关的」的判断。
ignore_older 也有一条隐藏约束：它必须大于 close.on_state_change.inactive，否则逻辑会互相打架。并且它判断依据是文件修改时间，对从未采集过的文件会把读取位移直接设到文件末尾------也就是「当它不存在」。
采不到 的高频成因则是路径与元数据不匹配。用 /var/log/containers/ 这条路径采集时，容器元数据能够正常挂上；但如果你改成采 /var/log/pods/（因为那里有轮转文件），容器元数据就拿不到了，需要用自动发现机制补。这是 K8s 场景里非常常见的一个坑。
2026 年有哪些必须知道的变更？
四条，都会影响现有部署：
- log input 与 container input 已在 9.0 默认禁用。它们从 7.16 起就被弃用，现在需要显式加开关才能用，最终会被移除。迁移目标是 filestream。
- Elastic 官方把 Agent 设为推荐路径，Beats 的定位收缩为「数据源还没被 Agent 支持时」的备选。注意官方措辞是「多数用例」，并不是彻底下线，Beats 仍在维护。
- Logstash 9.4 起最低 Java 21，之前版本已支持到 8.19 一线。
- 许可方面 ：Elasticsearch 与 Kibana 的默认发行版走 Elastic License，源码为 AGPL / SSPL / ELv2 三选一；但 Logstash 与 Beats 仍然是 Apache 2.0，这一点常被误传。OpenSearch 是从 7.10.2 分叉、Apache 2.0 许可、现归 Linux Foundation。
关于性能排名有一个必须说明的点：各家给出的吞吐对比基本都是厂商自测。同一组组件，不同厂商的测试表能得出相反的结论，测的方法和场景也不同。选型时把资源占用、运维复杂度和社区活跃度作为主要依据，性能数字只当参考量级。
FAQ
Q：只在节点上装 Filebeat，够用吗？ A：如果日志终点只有 Elasticsearch、不需要复杂解析、也接受内存队列，够用。一旦出现「要分流」「要 grok」「要找地方缓冲」中的任何一条，就需要在中间加一层。
Q：Fluent Bit 和 Fluentd 该选哪个？ A：两者共享 forward 协议，可以配合使用。Fluentd 的强项是插件广度（千级以上），Fluent Bit 的强项是资源占用和性能，K8s 节点级采集通常选后者。
Q：持久队列能不能替代上游的可靠性设计？ A：不能。它只能吸收短时抖动和进程重启，撑不住磁盘损坏这类故障，而且它带来的是「不丢但可能重」。下游必须能处理重复。
Q：日志偶尔少几条，怎么定位？ A：按顺序排：文件是否在采集器关闭期间被轮转或删除 → ignore_older 与 close_* 的值是否互相冲突 → 队列类型是内存还是落盘 → 输出端是否有丢弃策略。四步能覆盖绝大多数情况。
Q：容器日志的元数据为什么挂不上？ A：先看采集路径。走容器日志目录时元数据是自动带的；一旦改用 pod 目录（往往是为了拿到轮转后的文件），就需要靠自动发现去补，光靠元数据处理器拿不到。