日志采集器选型：Vector、Fluent Bit 与 OTel Collector

在节点上采文件、把复杂日志清洗后再发送、统一转发 OTel 数据，是三类不同工作。Fluent Bit、Vector、Collector 都能覆盖其中一部分，选择哪个主要取决于现有职责。复杂加工比较多，我会更关注 Vector；节点文件采集成熟，Fluent Bit 很合适；日志、指标和 Trace 已经统一到 OTel，Collector 更容易复用。

不过，采集器能否在异常输入下按预期工作，值得单独看。比如解析 JSON、删除 token、把耗时转成数字，只需几行规则；给它一条 duration_ms="n/a" 的日志，处理结果就不再那么直观。我们在 Vector 0.59.0 上运行了这段 VRL：

. = parse_json!(.message)
del(.token)
.duration_ms = to_int!(.duration_ms)

正常样本输出数值耗时，token 被删除。转换失败的样本，在默认 remap 配置下被原样放行，输出的 message 仍含原始 token。前面执行过 del，并没有让失败路径上的原文自动脱敏。

这不是说 Vector 不适合清洗。它把失败处理做成了可配置行为，团队需要决定保留、隔离还是丢弃。这样的选择会一路影响下游，所以接入成本不能只按正常日志的规则行数估算。

作者：观测云。核对于 2026-10-09。本文实际执行 Vector 0.59.0 的三条合成样本；Fluent Bit、OTel Collector 及其他工具的比较依据官方文档，没有做七款工具的吞吐排名。测试 token 为专门构造的非凭证字符串。

Vector 的转换失败处理

Vector 的 remap 默认不因运行错误丢弃事件，而是把原始、未经修改的事件传下去。配置 drop_on_error=true 与 reroute_dropped=true 后，本次成功事件走正常输出，转换失败和 JSON 损坏的两条进入 normalize.dropped，带有错误注释。旁路保留的仍是原始事件，并不会因为换了出口就脱敏。Vector remap。

对于“尽量保留原文，后续修正规则”的排障日志，默认放行可能是有意选择。对于必须在离开节点前移除敏感字段的日志，则必须处理失败分支：受控隔离、单独清洗、限制访问，或者经业务确认后丢弃并计数。只设置 drop_on_error 却没有接住旁路，也可能把问题从泄漏变成丢失。

多种输入、复杂字段推导和错误路由集中在一起时，VRL 很有用，规则也方便审阅和版本管理。代价是有人维护异常样本和回归。格式一变，正常输出和失败旁路都要一起检查。

Fluent Bit 有 parser 与 filter，Collector 的 filelog 和处理器也能做加工。规则简单，已有配置能完成，就没有必要为了另一种表达式语言迁一遍；规则复杂到日常难以维护，Vector 的规则组织方式才更有替换价值。Fluent Bit 解析、Collector filelog。

文件位点和发送队列

Fluent Bit 的 Tail db 使用 SQLite 记录文件和读取位置。这个文件能帮助重启后继续读取，但它不是装着待发送日志内容的队列。发送缓冲是否落盘，需要看 storage 配置和对应输出行为。

延伸阅读Redpanda vs Kafka：日志缓冲层的容量、可靠性和成本→

OTel filelog 的 storage 扩展用于持久化读取位置；发送端要抵御重启丢失，则还要按 exporter 的能力配置持久发送队列。组件在配置里声明了，也需要实际挂到相应 receiver、exporter 与 service 上。使用的发行构建必须含这些组件。Tail 输入、Collector 可靠性。

这两类持久化分开以后，重启行为就容易理解：位点告诉采集器下次从哪里读，发送队列保存已经读出、尚未送完的内容。只保留前者，位点可能已经前进，内存里的事件却在重启时丢了。重启后没有重读，反而可能掩盖这段缺失。

Vector 的磁盘缓冲和端到端确认也需要按组件组合理解。持久缓冲可以在链路中接下交付责任，确认未必意味着最终分析后端已经持久化。节点磁盘上的持久缓冲，保护范围与多副本队列也不同。Vector 交付保证、端到端确认。

如果业务只需要跨越短暂网络抖动，节点磁盘队列可能足够。若需要节点永久损坏后仍可恢复，或者多个后端独立回放，单纯换一种采集器通常解决不了架构层的要求，需要另行考虑副本与回放层。

长行与文件轮转

Tail 的单文件缓冲会随内容增长至配置上限。按官方文档，超过上限的长行可能导致文件被移出监控；启用 skip_long_lines 可以继续采后面的内容，代价是跳过该长行。这两种行为对业务的影响不同。把开关打开并不能说明问题已经解决，需要明确长堆栈、请求体或审计记录是否允许丢弃。

文件数量也影响内存预算。即使只按每个文件 32 KiB 的初始缓冲估算，一千个活跃文件就是约 31.25 MiB，尚未包含 chunk、解析器、输出队列和进程开销。拿一个文件测出的进程内存，不能直接外推到一台有大量容器的节点。

轮转还要区分 rename 与 copytruncate。后者复制和截断之间存在数据变化窗口；路径规则若同时匹配当前文件与轮转副本，又可能把相同内容读两遍。现有 Filebeat 已经处理好的轮转策略，是迁移时需要继承的运行知识，不能因为替代品的空载内存更小就忽略。Fluent Bit Tail 行为。

节点上主要采容器文件，已有合适插件和轮转经验，Fluent Bit 是合理选择；复杂转换集中在汇聚节点，用 Vector 承担这一层也很自然。两者可以同时存在，只要同一字段的加工职责明确，就不必追求所有节点只剩一种工具。

多种遥测数据统一接入

如果日志只是接入任务的一部分，还需要接收和转发 traces、metrics，Collector 的价值就在于统一遥测管道。此时只比较日志进程内存，会漏掉分别维护多套接入服务的成本。

OTel 统一了管道，字段映射仍然要接好。resource 里的 service.name 与日志属性的同名键可能进入不同位置；正文里的 trace ID 也未必自动成为后端的关联字段。这些配置稳定以后，多种信号可以复用同一套规范，后续新增来源的工作会少一些。

Collector 的发行构建会影响可用组件，filelog 需要使用包含相应 receiver 的构建。团队已有 OTel 标准，这部分版本和配置管理可以复用；只是采几个本地文件，再引入整套管理方式未必有收益。

缓冲容量

缓冲容量可以先按数据量估算。例如每台节点进入队列的事件平均 2 MiB/s，希望承受一小时下游中断，仅净内容就需要约 7.03 GiB；一百台节点合计约 703 GiB。序列化开销、磁盘余量和恢复时的新流量还没有计入。这里的速率应取该缓冲阶段的数据，不能混用压缩前文件大小与压缩后网络流量。

延伸阅读日志可靠交付：缓冲、消费位点和失败重试→

缓冲达到上限后的行为也有成本。Fluent Bit 文档说明，某输出的 storage.total_limit_size 耗尽时，会丢弃该输出队列中最老的 chunk，为新数据腾空间。它提供的是有边界的缓冲，不是无限保管承诺。Fluent Bit 缓冲。

下游恢复以后，消费速度高于新增速度，积压才会减少。磁盘扩容只能多等一会儿，解决不了持续追不平。预算里既要有中断期间的缓冲，也要有恢复期间额外的写入能力；瓶颈在后端时，更换采集器通常无济于事。

已有采集器要不要换

Filebeat、Logstash、Fluentd、Rsyslog 里已经稳定运行的规则和插件，也属于现成资产。替换它们需要重新处理协议、轮转、缓冲和恢复。新工具能够明显减少维护、资源或重复接入，才值得付出迁移成本；只是希望技术栈看起来统一，理由还不够。Filebeat、Logstash、Fluentd buffer、Rsyslog。

DataKit 能接替哪些工作

目标已经确定为观测云时，DataKit 的文件、容器采集和 Pipeline 可以承担不少现有职责。普通来源的解析、时间和多行处理如果直接在这里完成，就少一套加工服务和配置同步。日志采集、Pipeline。

本组文章另有六条样本的 Pipeline 调试记录，覆盖数值、事件时间和状态规范化，但没有做 DataKit 文件轮转或崩溃恢复测试。这份结果只覆盖加工行为。如果已有 Vector 规则很复杂且运行稳定，保留它承担原职责，再验证目标协议与字段，可能比全部重写更省。

已有 Vector 还承担多目标投递或特殊协议，就继续保留，不必因为后端换了就全部重写。普通采集与加工已能由 DataKit 完成，则可以减少重复部署。省下哪一层、还由谁维护哪一层，明确以后，资源与人力差价才算得出来。

Vector 输入、配置和实际结果 · 观测云 Pipeline 六条样本。测试没有覆盖性能、文件轮转、断电或节点损坏，文中相应内容是选型依据与待验收项目。