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 集中处理
- 需要复杂的日志解析和转换 → Logstash 的 filter 插件最丰富
- Kubernetes 环境、需要高可用 → Fluentd 的 DaemonSet 部署最成熟
- 想统一管理多种数据源 → Fluentd 的 input/output 插件生态更广
避坑:别在同一个服务器上同时跑 Filebeat 和 Logstash 的采集端。我见过有人这么干,结果两个进程抢同一个日志文件的读取位置,数据要么重复要么丢失。选一个就够了。
3.6 本章小结
这一章我们聊了三个采集工具的安装和基础配置。Filebeat 轻量、Logstash 强大、Fluentd 灵活。没有最好的工具,只有最适合你场景的方案。
我个人建议:先从小规模开始,用 Filebeat + Logstash 的组合跑通流程。等规模上来了,再考虑引入 Fluentd 做统一日志层。别一开始就上全套,容易把自己搞晕。