第4章 常用采集工具对比：Filebeat、Logstash、Fluentd、Vector、Splunk Universal Forwarder

4.1 为什么要把它们放一起比

日志采集工具这么多，选型时很容易眼花。说实话，没有哪个工具能包打天下。每个工具的出身、设计哲学、擅长的场景都不一样。

我见过不少团队，上来就选某个工具，理由是「大家都用」。结果跑了大半年，发现资源吃不住、插件不够用、或者运维太折腾。

这一章，我把市面上最主流的五个采集工具拉出来，逐一拆解。你搞清楚它们的差异，选型时就不会拍脑袋了。

4.2 Filebeat — 轻量级选手

Filebeat 是 Elastic 生态里的轻量级采集器。用 Go 写的，二进制包很小，装上去几乎感觉不到它的存在。

我最早接触 Filebeat 是在一个 K8s 项目里。那时日志量不大，业务方要求采集器不能占太多资源。Filebeat 确实省心，CPU 常年维持在 1% 以下，内存也就几十 MB。

它的配置很简洁。拿最常见的文件采集来说：

filebeat.inputs:
- type: log
  paths:
    - /var/log/app/*.log
  fields:
    app: my-service

output.elasticsearch:
  hosts: ["http://localhost:9200"]

你想想看，就这么几行，采集 + 输出就搞定了。没什么学习成本。

适用场景：容器环境、边缘节点、资源受限的服务器。不适合做复杂的日志解析和过滤。

4.3 Logstash — 全能型管道

Logstash 是 ELK 里的「数据处理中枢」。它的插件生态非常丰富，输入、过滤、输出加起来两百多个插件。几乎你能想到的数据格式，它都能解析。

但代价也很明显——重。Java 写的，启动慢，内存占用随配置飙升。我记得有一次在生产环境遇到 Logstash OOM，排查下来是某个解析规则没加限流，高峰时段直接把堆内存撑爆了。

一个典型的 pipeline 长这样：

input {
  beats { port => 5044 }
}

filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{GREEDYDATA:msg}" }
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "app-logs-%{+YYYY.MM.dd}"
  }
}

适用场景：需要复杂数据清洗、格式转换、丰富处理的场景。不适合资源紧张的环境。

4.4 Fluentd — 统一日志层

Fluentd 是 CNCF 毕业的项目，在云原生领域地位很高。它的设计理念是「统一日志层」，说白了就是做数据路由和缓冲。

它的插件系统也很成熟，但和 Logstash 不同，Fluentd 用 C + Ruby 写，性能介于 Filebeat 和 Logstash 之间。配置风格偏声明式：

<source>
  @type tail
  path /var/log/app/*.log
  tag app.log
</source>

<filter app.log>
  @type parser
  key_name message
  <parse>
    @type regexp
    pattern /^(?<time>\S+) (?<level>\S+) (?<msg>.*)$/
  </parse>
</filter>

<match app.log>
  @type elasticsearch
  host localhost
  port 9200
</match>

适用场景：K8s 集群、多云架构、需要数据路由和缓冲的场景。配置稍显啰嗦，但胜在灵活。

4.5 Vector — 新生代高性能工具

Vector 是这几年冒出来的新秀。用 Rust 写，目标是成为「日志处理界的性能天花板」。我去年在一个高吞吐场景下把 Logstash 换成了 Vector，CPU 占用直接降了 60%，延迟也砍了一半。

它的配置采用 TOML 格式，清晰且易于版本管理：

[sources.app_logs]
type = "file"
include = ["/var/log/app/*.log"]

[transforms.parse]
type = "remap"
inputs = ["app_logs"]
source = '''
. = parse_regex!(.message, r'^(?P<time>\S+) (?P<level>\S+) (?P<msg>.*)$')
'''

[sinks.es]
type = "elasticsearch"
inputs = ["parse"]
endpoint = "http://localhost:9200"
index = "app-logs-%Y.%m.%d"

你注意看，它把采集、解析、输出拆成了三个组件：sources、transforms、sinks。非常模块化，想替换哪一段都很方便。

适用场景：高吞吐、低延迟需求；希望用一套工具同时搞定日志、指标、事件采集的团队。

4.6 Splunk Universal Forwarder — 企业级方案

Splunk Universal Forwarder（简称 UF）是 Splunk 生态的采集代理。它的卖点不是性能，而是企业级能力：集中管理、安全传输、合规审计。

我在一个金融客户那里接触过 UF。他们所有的服务器都部署了 UF，通过 Deployment Server 统一推送配置。安全策略非常细，传输全程加密，审计日志一应俱全。

配置集中在 inputs.conf 里：

[monitor:///var/log/app/*.log]
index = app
sourcetype = app_log
disabled = false

然后通过 outputs.conf 指定转发目标。非常轻量，安装包才几十 MB。但注意，它不做解析，只负责采集和转发。

适用场景：大型企业、强监管行业、已有 Splunk 生态的团队。

4.7 综合对比

我把五个工具的核心参数拉了一张表。你一眼就能看出差异。

维度	Filebeat	Logstash	Fluentd	Vector	Splunk UF
开发语言	Go	Java	C + Ruby	Rust	C++
资源占用	极低	高	中等	低	低
插件生态	中等	丰富	丰富	增长中	有限
数据处理能力	弱	强	中等	强	弱（仅转发）
配置复杂度	简单	中等	中等	中等	简单
延迟	低	中高	中等	极低	低
企业级能力	弱	中等	中等	中等	强
社区活跃度	高	高	高	高	中等
典型部署场景	边缘节点、容器	集中式处理管道	K8s、多云	高吞吐边缘或管道	金融、大型企业

4.8 选型建议 & 避坑指南

看完对比，你可能会问：到底选哪个？我的建议是分场景判断。

• 如果你在容器环境或 K8s 里跑，优先考虑 Filebeat 或 Fluentd。Filebeat 更轻，Fluentd 路由更灵活。
• 如果日志量巨大，对延迟敏感，Vector 是当前的最优解。我去年换掉 Logstash 后，同样的吞吐量，资源降了一半多。
• 如果业务在金融、医疗等强监管行业，Splunk UF 几乎是必选项。它的审计和安全能力，其他工具暂时追不上。
• 如果团队里已经有 ELK 生态，先用 Filebeat + Logstash 的组合最稳妥。Logstash 做复杂处理，Filebeat 做轻量采集。

选型没有标准答案，核心是匹配你的场景和团队能力。把这五个工具的特点吃透，你做决定时就有底气了。