3、日志采集技术:Filebeat、Logstash、Fluentd 的安装与基础配置

日志采集是整个追踪系统的「眼睛」。眼睛要是瞎了,后面再好的分析工具也白搭。我见过不少团队,ELK 搭得漂漂亮亮,结果采集端没搞好,日志丢了一半,排查问题反而更费劲。

这一章,咱们把三个主流采集工具——Filebeat、Logstash、Fluentd 的安装和基础配置过一遍。不搞花架子,直接上手。

3.1 三个工具,各自什么定位?

先搞清楚它们的分工。很多人一上来就混着用,结果资源浪费,维护还麻烦。

工具 定位 资源消耗 适用场景
Filebeat 轻量采集器 极低(几 MB 内存) 服务器日志采集、边缘节点
Logstash 数据处理管道 较高(默认 1GB 堆内存) 复杂解析、过滤、转换
Fluentd 统一日志层 中等(Ruby 运行时) 多数据源聚合、Kubernetes 生态

我个人习惯是:Filebeat 负责「收」,Logstash 负责「洗」,Fluentd 负责「桥」。当然,小规模场景下,一个 Logstash 也能全包,但生产环境我建议分层。

核心原则:采集端尽量轻,处理端尽量稳。别在业务服务器上跑重负载的采集进程。

3.2 Filebeat 安装与基础配置

Filebeat 是我用得最多的采集器。为什么?因为它真的轻。我在一台 1C2G 的云服务器上跑过,内存占用不到 20MB,几乎感觉不到它的存在。

3.2.1 安装

官方提供了多种安装方式。我个人推荐用 RPM/DEB 包,方便 systemd 管理。

# Debian/Ubuntu
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.10.0-amd64.deb
sudo dpkg -i filebeat-8.10.0-amd64.deb

# CentOS/RHEL
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.10.0-x86_64.rpm
sudo rpm -vi filebeat-8.10.0-x86_64.rpm

装完之后,先别急着启动。我记得第一次用 Filebeat 时,直接默认配置就跑,结果它把系统日志全给我发出去了,搞得 Elasticsearch 里一堆垃圾。

3.2.2 基础配置

核心配置文件在 /etc/filebeat/filebeat.yml。咱们一步步来。

# 定义日志输入源
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/access.log
    - /var/log/nginx/error.log
  fields:
    service: nginx
    env: production

# 定义输出到 Logstash(推荐)
output.logstash:
  hosts: ["192.168.1.100:5044"]

# 也可以直接输出到 Elasticsearch(小规模用)
# output.elasticsearch:
#   hosts: ["http://192.168.1.100:9200"]

小技巧:用 fields 给日志打标签,后面 Logstash 或 ES 里做过滤就方便了。我习惯把 service、env、host 这三个字段都带上。

3.2.3 启动与验证

sudo systemctl start filebeat
sudo systemctl enable filebeat

# 查看状态
sudo filebeat test output
sudo journalctl -u filebeat -f

看到 Connection to elasticsearch successful 或者 Logstash connection established,就说明通了。

避坑:Filebeat 默认会记录读取位置到 registry 文件。如果你改了日志路径或清空了日志,记得删掉 /var/lib/filebeat/registry,否则它会从上次的位置继续读,导致数据重复或遗漏。我曾经因为这个被坑过一次,排查了半天。

3.3 Logstash 安装与基础配置

Logstash 是管道里的「心脏」。它负责把原始日志解析成结构化数据。但说实话,它也是资源消耗最大的一个。

3.3.1 安装

Logstash 依赖 Java,先确认 JDK 版本(推荐 JDK 17 或 21)。

# 导入 GPG 密钥
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

# 添加 APT 源
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt update && sudo apt install logstash

3.3.2 基础配置

Logstash 的配置分三段:input、filter、output。咱们写一个处理 Nginx 日志的例子。

# /etc/logstash/conf.d/nginx.conf

input {
  beats {
    port => 5044
  }
}

filter {
  if [fields][service] == "nginx" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
    date {
      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
      target => "@timestamp"
    }
    geoip {
      source => "clientip"
      target => "geo"
    }
    useragent {
      source => "agent"
      target => "ua"
    }
  }
}

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

这个配置做了三件事:解析日志格式、提取客户端地理位置、解析 User-Agent。嗯,这里要注意,grok 正则如果写错了,整条日志会被丢弃。我建议先在 Kibana 的 Grok Debugger 里测试好再上线。

3.3.3 内存调优

Logstash 默认堆内存是 1GB。如果你的服务器内存紧张,可以调小一点。

# /etc/logstash/jvm.options
-Xms512m
-Xmx512m

但别低于 256MB,否则 GC 频繁,性能反而下降。

经验之谈:Logstash 的 filter 阶段最耗 CPU。如果日志量很大(比如每秒上万条),建议用 pipeline.workers 参数调整并发数。我一般设为核心数的 2 倍。

3.4 Fluentd 安装与基础配置

Fluentd 在 Kubernetes 生态里用得特别多。它的插件机制非常灵活,但 Ruby 运行时确实比 Go 写的 Filebeat 重一些。

3.4.1 安装

官方推荐用 td-agent 包,省去自己装 Ruby 依赖的麻烦。

# 一键安装脚本(支持主流 Linux 发行版)
curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-jammy-td-agent4.sh | sudo sh

# 启动
sudo systemctl start td-agent
sudo systemctl enable td-agent

3.4.2 基础配置

Fluentd 的配置语法有点像 Ruby DSL。咱们写一个采集 Nginx 日志并输出到 Elasticsearch 的例子。

# /etc/td-agent/td-agent.conf

<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>
    service nginx
    env production
  </record>
</filter>

<match nginx.access>
  @type elasticsearch
  host 192.168.1.100
  port 9200
  index_name fluentd-nginx-${tag}
  <buffer>
    @type file
    path /var/log/td-agent/buffer/nginx
    flush_interval 5s
  </buffer>
</match>

注意那个 pos_file,作用和 Filebeat 的 registry 一样,记录读取位置。如果日志文件被轮转,Fluentd 能自动感知。

个人建议:Fluentd 的 buffer 机制很强大。如果 ES 挂了,它会先把数据缓存到磁盘,等 ES 恢复后再重发。这个特性在生产环境非常实用。

3.5 三者的选型对比

说了这么多,到底该用哪个?我画了一张图,帮你快速决策。

日志采集工具选型决策流程 日志采集需求 是否需要复杂数据转换? 否 Filebeat 是 Logstash 是否在 Kubernetes 环境? 否 Filebeat + Logstash 是 Fluentd 说明: 小规模(日均日志量 < 10GB)可直接用 Filebeat → Elasticsearch;大规模建议分层采集。

简单总结一下我的选型经验:

  • 服务器数量多、资源紧张 → 用 Filebeat 采集,Logstash 集中处理
  • 需要复杂的日志解析和转换 → Logstash 的 filter 插件最丰富
  • Kubernetes 环境、需要高可用 → Fluentd 的 DaemonSet 部署最成熟
  • 想统一管理多种数据源 → Fluentd 的 input/output 插件生态更广

避坑:别在同一个服务器上同时跑 Filebeat 和 Logstash 的采集端。我见过有人这么干,结果两个进程抢同一个日志文件的读取位置,数据要么重复要么丢失。选一个就够了。

3.6 本章小结

这一章我们聊了三个采集工具的安装和基础配置。Filebeat 轻量、Logstash 强大、Fluentd 灵活。没有最好的工具,只有最适合你场景的方案。

我个人建议:先从小规模开始,用 Filebeat + Logstash 的组合跑通流程。等规模上来了,再考虑引入 Fluentd 做统一日志层。别一开始就上全套,容易把自己搞晕。