第一章：数据采集技术选型——Filebeat vs Fluentd vs Logstash，如何选择Agent？

大家好，我是你们的老朋友。今天咱们聊聊实时日志分析引擎的第一步——数据采集。

说白了，日志采集就是给系统装个“耳朵”。没有它，后面再牛的分析引擎都是白搭。我见过不少团队，一上来就搞复杂的流计算，结果发现日志根本收不上来，或者丢数据丢得离谱。嗯，这步走稳了，后面才踏实。

1.1 三大主流Agent概览

目前市面上最常用的日志采集Agent，无非就是Filebeat、Fluentd和Logstash。我个人的习惯是，先看场景再选工具，而不是反过来。

特性	Filebeat	Fluentd	Logstash
开发语言	Go	Ruby + C	Java (JRuby)
资源占用	极低（约10-20MB）	中等（约50-100MB）	较高（约200-500MB）
吞吐量	高（单机万级/秒）	高（单机万级/秒）	中（单机千级/秒）
插件生态	有限（主要面向ES）	丰富（1000+插件）	丰富（200+插件）
数据处理能力	弱（仅简单过滤）	中（支持解析、转换）	强（支持复杂ETL）
部署复杂度	简单（二进制直接跑）	中等（需配置Ruby环境）	较高（依赖JVM）

你看，这三兄弟各有各的脾气。Filebeat轻巧得像把瑞士军刀，Fluentd像个多功能工具箱，Logstash则是一台重型加工厂。怎么选？别急，咱们一个一个拆开看。

1.2 Filebeat：轻量级首选

Filebeat是Elastic公司亲儿子，用Go写的。我最早接触它是在一个Kubernetes集群里，那时候节点多，资源紧张，Logstash根本跑不动。Filebeat一上去，CPU占用不到1%，内存才十几兆，舒服得很。

核心优势：

• 资源占用极低：适合部署在边缘节点或容器中
• 背压机制：当下游（如Kafka、ES）处理不过来时，Filebeat会自动降速，不会丢数据
• 原生支持Kubernetes：自动发现Pod日志，配合Metadata注入

适用场景：

• 纯日志采集，不需要复杂处理
• 目标端是Elasticsearch或Kafka
• 资源受限的环境（如IoT设备、边缘节点）

# Filebeat 多行日志配置示例
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/*.log
  multiline.pattern: '^\d{4}-\d{2}-\d{2}'
  multiline.negate: true
  multiline.match: after

1.3 Fluentd：生态之王

Fluentd是云原生计算基金会（CNCF）的毕业项目，Ruby写的。说实话，我一开始对Ruby有点抵触，觉得性能不行。但后来在几个大流量场景里，Fluentd的表现让我刮目相看。

为什么？因为它有1000多个插件。你想对接什么系统，基本都能找到现成的。从Kafka到S3，从MongoDB到BigQuery，全覆盖。

核心优势：

• 插件生态极其丰富：几乎能对接任何数据源和目的地
• 内置缓冲和重试：数据不会因为网络抖动就丢了
• 标签路由机制：可以灵活地将不同日志分发到不同后端

适用场景：

• 需要对接多种数据源和目的地
• 需要一定的数据解析和转换能力
• 云原生环境（Kubernetes、OpenShift）

# Fluentd 配置示例
<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>

<match nginx.access>
  @type kafka2
  brokers kafka1:9092,kafka2:9092
  topic_key nginx_logs
  <buffer>
    @type file
    path /var/log/td-agent/buffer/nginx
    flush_interval 5s
  </buffer>
</match>

1.4 Logstash：重型加工厂

Logstash是ELK三件套的老大哥，Java写的。功能最全，但也最重。我记得有一次在客户现场，他们用Logstash做日志清洗，一个节点上跑了4个Pipeline，结果JVM堆内存飙到8GB，吓得我赶紧建议他们拆分。

核心优势：

• 强大的数据处理能力：支持Grok正则解析、日期处理、字段转换等
• 丰富的输入输出插件：200+插件，覆盖主流系统
• Pipeline灵活性高：可以定义多个Pipeline，互不干扰

适用场景：

• 需要复杂的数据清洗和转换
• 日志格式不统一，需要大量Grok解析
• 已有ELK技术栈，不想引入新组件

# Logstash 配置示例
input {
  beats {
    port => 5044
  }
}

filter {
  if [type] == "nginx-access" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
    date {
      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
    }
  }
}

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

1.5 选型决策框架

说了这么多，到底怎么选？我总结了一个简单的决策树，你照着走就行。

你看，这个决策树很直观。资源紧张选Filebeat，需要复杂ETL选Logstash，需要多后端对接选Fluentd。但实际项目中，我很少只用一种。比如在某个电商项目中，我们用了Filebeat采集所有节点日志，统一发到Kafka，然后Fluentd从Kafka消费，分流到ES和S3。这样既保证了采集端的轻量，又保留了处理端的灵活性。

1.6 我的最终建议

选型没有银弹。我个人的经验是：

• 采集层：优先用Filebeat。轻量、稳定、不占资源。你想想看，成百上千个节点，每个节点多占100MB内存，加起来就是几十GB，这成本谁扛得住？
• 缓冲层：必须上Kafka。别想着直接怼到ES，一旦ES挂了，数据全丢。Kafka就是你的保险。
• 处理层：看需求。简单清洗用Fluentd，复杂ETL用Logstash。如果两者都满足不了，那就自己写个微服务。