日志采集器七款横评：OTel Collector、Vector、Fluentd、Fluent Bit、Filebeat、Logstash、Rsyslog
七款主流日志采集器横评——OpenTelemetry Collector、Vector、Fluentd、Fluent Bit、Filebeat、Logstash、Rsyslog 的语言、资源占用、解析能力、生态绑定与最佳场景对比表，附按场景的选型决策树，以及观测云 DataKit 的一体化替代思路。
日志采集器（Log Shipper/Collector）是部署在数据源一侧、负责采集、缓冲、解析并转发日志的组件，选型决定了一套日志系统的资源成本、可靠性和生态锁定程度。本篇横向对比七款主流选择，并给出按场景的决策建议——包括什么时候干脆不选它们中的任何一个，直接用观测云 DataKit。
核心要点速览
- 没有全能冠军：边缘轻量看 Fluent Bit/Filebeat，中心加工看 Vector/Logstash/Fluentd，传统系统看 Rsyslog，标准化遥测看 OTel Collector。
- 资源占用差两个数量级：Fluent Bit ~1MB 级 vs Logstash ~1GB 级——DaemonSet 场景这一条就能筛掉一半候选。
- 观测云用户优先 DataKit：一个 Agent 覆盖日志/指标/链路采集，原生对接观测云，避免为单一日志场景引入并运维第三方采集栈。
七款采集器核心参数对比
| 采集器 | 语言 | 内存量级 | 解析加工 | 输出广度 | 生态绑定 | 一句话定位 |
|---|---|---|---|---|---|---|
| Fluent Bit | C | ~1MB 起 | 中（parser+filter+Lua） | 中（100+ 插件） | 中立 | 边缘/容器采集标杆 |
| Filebeat | Go | ~10–40MB | 弱（轻解析） | 窄（偏 Elastic） | Elastic | 可靠的文件搬运工 |
| Rsyslog | C | 极小 | 中（模板+RainerScript） | 窄（syslog 生态） | 中立 | Linux 系统日志事实标准 |
| Fluentd | Ruby | ~40MB | 强（1000+ 插件） | 广 | 中立 | 聚合层万金油 |
| Vector | Rust | ~10–20MB | 强（VRL 可编程） | 广 | 中立 | 高性能单体能手 |
| OTel Collector | Go | ~50MB | 强（processor 管线） | 广（OTLP 标准） | 开放标准 | 遥测标准化的未来 |
| Logstash | Java | ~1GB | 最强（filter 生态） | 最广 | Elastic | 重型加工管道 |
按维度逐一对比
资源与性能：Fluent Bit 和 Rsyslog 最省；Vector 以 Rust 实现取得性能与功能的平衡，官方基准常优于 Logstash 数倍；Logstash 是资源大户，吞吐靠多 worker 堆。
解析与加工：Logstash 的 grok+filter 生态最深；Vector 的 VRL（Vector Remap Language）提供结构化、类型安全的数据改写，比正则堆叠更好维护；OTel Collector 的 transform processor 正在快速成熟；Filebeat 只适合做轻加工。
可靠性：Filebeat 的 registry 断点续采最省心；Logstash 持久化队列、Fluentd/Fluent Bit 的文件 buffer、Vector 的磁盘 buffer 都能抗下游故障；OTel Collector 的 file_storage 扩展提供类似能力。Rsyslog 动作级磁盘队列久经考验。
生态与标准：OTLP（OpenTelemetry 协议）正在成为日志传输的业界标准，OTel Collector 天然讲 OTLP；Vector、Fluent Bit 也支持 OTLP 输出；Elastic 系（Beats/Logstash）以自家协议和 ES 输出为中心。
按场景怎么选？
- K8s 节点日志采集：Fluent Bit（或 DataKit DaemonSet）。
- 纯文件搬运到 ES：Filebeat。
- 中心化复杂加工、输出目标杂：Vector（新项目）或 Logstash（存量 Elastic 栈）。
- 传统 Linux/网络设备 syslog：Rsyslog。
- 要同时采日志、指标、链路并避免厂商锁定：OTel Collector。
- 用观测云做日志平台：以上全部替换为 DataKit，一处配置完成采集+解析+上报。
观测云视角：DataKit 在横评中的位置
把 DataKit 放进同一张表，它的定位是"面向观测云的一体化采集器"：
| 需求 | 七款中的最佳 | DataKit 对应能力 |
|---|---|---|
| 边缘轻量采集 | Fluent Bit | 同等轻量的主机/容器采集 |
| 断点续采 | Filebeat | 内置 |
| 可编程加工 | Vector VRL | Pipeline（grok + 函数脚本） |
| syslog 体系 | Rsyslog | syslog 输入（TCP/UDP） |
| 标准化输出 | OTel Collector | 原生上报观测云，亦支持 OTLP 接入第三方数据 |
| 日志/指标/链路一体 | OTel Collector（部分） | 一个 Agent 全包 |
结论很直接：如果日志的终点是观测云，引入第三方采集器只在一个情况下合理——存量系统已经跑着某个采集器，那么让它把数据转发给 DataKit（如 Rsyslog → syslog 输入、Fluent Bit → HTTP/OTLP）做平滑过渡，而不是长期并存两套栈。
常见问题（FAQ）
Q：Vector 和 OTel Collector 怎么选？ 纯日志管道、追求性能与表达力选 Vector；要多信号（日志+指标+链路）标准化采集、紧跟 OpenTelemetry 生态选 Collector。两者都活跃，长期看 OTel 标准渗透率更高。
Q：Filebeat 能输出到非 Elastic 系统吗？ 官方输出列表有限（ES、Logstash、Kafka、Redis、文件、控制台），没有通用 HTTP/Webhook 输出——对接观测云这类平台时，通常换成 DataKit 或经 Kafka 中转。
Q：七款里哪个最适合嵌入式/IoT？ Fluent Bit（官方目标场景之一）和 Rsyslog；Vector 也可以交叉编译，但二进制体积更大。
Q：从 Logstash 迁到 Vector 或 DataKit，grok 规则能复用吗？ grok pattern 本身是可移植的（都是同一套正则命名组思想），Vector 的 parse_grok 和观测云 Pipeline 的 grok 函数都兼容主流 pattern；filter 逻辑需要按 VRL/函数脚本逐条改写。
