📚 课程目录第3章采集工具对比

3、采集工具对比：Filebeat、Fluentd、Logstash 特点与选型

日志采集工具的选择，说白了就是跟你自家环境的一场“相亲”。

Filebeat、Fluentd、Logstash 这三兄弟我用了很多年。今天咱们就掰开揉碎，看看它们各自什么脾气，到底该娶谁回家。

3.1 三款工具的核心定位

先给个总体的画像，你心里有个谱：

特性	Filebeat	Fluentd	Logstash
定位	轻量采集器（"快递小哥"）	统一日志层（"数据管道"）	全能处理引擎（"重卡运输车"）
资源消耗	极低（～10MB内存）	中（～100MB内存）	高（～500MB+）
开发语言	Go	Ruby + C	Java（JRuby）
主要功能	采集 + 简单转发	采集 + 过滤 + 路由 + 缓冲	采集 + 过滤 + 转换 + 输出
适用场景	边缘节点、容器侧、低配服务器	多云/多日志源统一管道	复杂数据清洗、ETL 场景

你看这个表格就明白了：Filebeat 像把水果刀，小巧锋利；Fluentd 像瑞士军刀，功能多但略重；Logstash 就是一把多功能瑞士军刀+钳子套装，什么活儿都能干，但也沉。

3.2 Filebeat：边缘节点的首选

我个人习惯把 Filebeat 部署在所有需要采集日志的服务器上。它真的轻——我在一个 512MB 内存的旧机器上跑过，还同时跑着 Nginx 和 MySQL，完全没压力。

优点：

资源占用极低，适合容器 sidecar 模式
内置多种模块（Nginx、MySQL、系统日志等），开箱即用
断线续传、背压感知、负载均衡——可靠性不错

缺点：

数据转换能力很弱，只能做简单的字段重命名、删除
不支持复杂过滤（如聚合、解析嵌套 JSON）
官方推荐配合 Logstash 或 Elasticsearch 使用，单兵作战能力有限

小贴士： Filebeat 的 multiline 配置很好用。遇到 Java 堆栈日志（多行一条记录），用 multiline.pattern: '^\\d{4}-\\d{2}-\\d{2}' 就能把异常堆栈合并成一条事件。

3.3 Fluentd：统一日志层的瑞士军刀

Fluentd 的生态其实挺有意思。它用 Ruby 写的，但性能并不差。我曾经在 50+ 台机器上部署过 Fluentd 作为日志中转节点，吞吐量稳定在每秒几万条。

核心机制：

使用 Input + Filter + Output 的插件链，每个环节都可定制
内置 Buffer 机制，支持内存和文件缓冲
标签路由（tag-based routing）：日志进来后打上 tag，按 tag 分发到不同输出端

# Fluentd 配置示例（采集 Nginx 日志并转发到 Kafka）
<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx-access.log.pos
  tag nginx.access
  <parse>
    @type nginx
  </parse>
</source>

<filter nginx.access>
  @type record_transformer
  <record>
    hostname "#{Socket.gethostname}"
  </record>
</filter>

<match nginx.access>
  @type kafka2
  brokers kafka1:9092,kafka2:9092
  topic_key topic
  default_topic nginx-logs
  <buffer>
    @type file
    path /var/log/td-agent/buffer/nginx
  </buffer>
</match>

你看这段配置，从采集、过滤到输出，一条龙。Fluentd 的 Buffer 特别重要——一旦下游 Kafka 挂了，它会把日志暂存到本地文件，等恢复后自动重发。我在生产环境中遇到过 Kafka 集群滚动重启，Fluentd 的 Buffer 保了我一命。

注意： Fluentd 的插件质量参差不齐。我踩过一个坑：社区版的 out_elasticsearch 插件在 Elasticsearch 版本升级时没及时适配，导致日志一直重试失败。后来换成官方维护的 fluent-plugin-elasticsearch 才稳下来。选插件一定要看 GitHub 的 star 数和更新时间。

3.4 Logstash：全能重型引擎

Logstash 是 ELK 栈里的老大哥，功能最强，但也是最重的。2016 年我第一次搭日志系统时用 Logstash 直接采集，结果公司那台 4 核 8G 的主机 CPU 被打满……后来学乖了，只在需要复杂清洗的场景下用它。

强势之处：

自带 200+ 插件：Grok 正则解析、KV 解析、GeoIP 地理位置、日期转换、Ruby 脚本……
Pipeline 多阶段处理：支持多个管道并行，互不干扰
持久化队列：保证日志不丢，即使 Logstash 重启也能续传

# Logstash 配置示例（解析 Apache 日志并写入 Elasticsearch）
input {
  beats {
    port => 5044
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  geoip {
    source => "clientip"
    target => "geo"
    add_tag => [ "geoip" ]
  }
  date {
    match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
    target => "@timestamp"
  }
}

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

看到 Grok 那块了没？一行日志能用一串正则瞬间拆出十几个字段。我处理过最复杂的场景：客户从主机的 syslog 里混了多种应用日志，用 Grok 的 break_on_match 一条管道全搞定。

重要提醒： Logstash 的 Grok 调试一定要用 kibana 自带的 Grok Debugger（本地工具也行）。别在线上直接配，我曾经手抖写了个死循环正则，导致 Logstash CPU 100% 了半小时。先在测试环境匹配通过，再上线。

3.5 选型决策：到底选哪个？

很多新人会纠结“到底用哪个好”。我的回答是：没有最好，只有最合适。

这里给你一个我总结的决策流程：

先看机器资源——如果目标机器只有 512MB 内存，放弃 Logstash 和 Fluentd，直接用 Filebeat 往远端 Logstash 或 Kafka 发。
再看日志处理复杂度——如果只是简单收集、加个字段、转成 JSON，Filebeat + 简单 filter 够用；如果需要正则解析、日期转换、URL 解码、IP 地理定位，上 Logstash。
中间还需要缓冲和路由——如果日志源分散，需要统一路由到多个目的地（比如 Elasticsearch + Kafka + S3），Fluentd 的 tag 路由和 Buffer 是最佳选择。
规模有多大？——少则几台机器：Filebeat → Logstash → ES 就完事；百台以上：推荐 Filebeat → Kafka → Fluentd/Logstash → ES，这样解耦更灵活。

下面这张图是我当年画给团队用的采集架构选型图，你可以参考着理解：

3.6 避坑总结

最后分享几个我踩过的坑，希望你绕开：

曾经踩坑1： 某次为了省资源，直接用 Logstash 采集所有服务器日志，结果 Filebeat 没上。某台机器日志量突增，Logstash 管道堵死，整个日志链路断了。后来我强制规定：边缘节点只用 Filebeat + 压缩传输，Logstash 只做汇聚清洗。

曾经踩坑2： 用 Fluentd 的 out_elasticsearch 插件时没配 buffer_chunk_limit，默认 chunk 大小 8MB。一次业务峰值日志量大了，chunk 超大，Elasticsearch 批量写入失败，导致缓冲区一直重试，最后把磁盘写满。记得根据日志量调小 chunk，加个磁盘使用监控。

我的习惯： 新项目开始前，我一般先做个小规模的压测——用 Logstash 和 Fluentd 各跑几千条真实日志，看看 CPU 和内存消耗。别信网上的 benchmark，你的日志格式、field 数、过滤规则都不同，实测最靠谱。

三款工具，各有千秋。Filebeat 像哨兵，站在最前线；Fluentd 像通信兵，负责路由和缓冲；Logstash 像情报分析员，深入处理复杂数据。你能把它们的角色分清楚，选型就不难了。