3、日志采集工具实战：Filebeat 安装与配置、Logstash 管道原理、Fluentd 基础使用
日志采集是整个监控系统的「水源」。水源不干净，后面的分析、告警全是白搭。我见过太多团队在 ELK 上花了大价钱，结果因为采集端配置不当，丢数据、重复采集、性能瓶颈轮番上阵。今天咱们就把这三个主流工具——Filebeat、Logstash、Fluentd 掰开揉碎讲清楚。
核心观点：没有最好的采集工具，只有最合适的场景。Filebeat 轻量、Logstash 强大、Fluentd 灵活。你想想看，一个生产环境往往需要它们配合使用。
3.1 Filebeat：轻量级采集的「尖兵」
Filebeat 是 Elastic 官方推出的日志采集器。说白了，它就是个「搬运工」——把日志文件从磁盘搬到你的消息队列或 Elasticsearch。我刚开始用 Filebeat 时觉得它功能太简单，后来才发现，简单恰恰是它的优势。
3.1.1 安装与配置
安装 Filebeat 其实就三步。以 CentOS 为例：
# 1. 下载并安装
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.17.0-linux-x86_64.tar.gz
tar -xzf filebeat-7.17.0-linux-x86_64.tar.gz
# 2. 配置采集路径
vim filebeat.yml
# 3. 启动
./filebeat -e -c filebeat.yml配置文件里最核心的是 filebeat.inputs 和 output 两个部分。我习惯这样写：
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/access.log
- /var/log/nginx/error.log
fields:
service: nginx
env: production
output.elasticsearch:
hosts: ["http://localhost:9200"]
index: "nginx-logs-%{+yyyy.MM.dd}"我的经验：paths 字段支持通配符，但别写太宽泛。我曾经见过有人写 /var/log/*.log，结果把系统日志也采集进去了，ES 索引直接炸了。
3.1.2 避坑指南
- 多行日志处理：Java 异常栈跨多行，默认 Filebeat 会按行拆分。用
multiline配置合并：
multiline:
pattern: '^\s'
negate: false
match: after- 内存控制：Filebeat 默认使用 2GB 内存？那是老版本。新版本建议设置
max_procs: 1，避免抢占业务资源。 - 注册表文件：
data/registry记录了采集进度。误删会导致重复采集。我有个同事手滑删了，结果 ES 集群被冲垮了……
3.2 Logstash：管道里的「数据炼油厂」
Logstash 的核心是管道（Pipeline）。数据从输入流进来，经过过滤器处理，再从输出流出去。你可以把它想象成一条流水线——每个工人（插件）负责一道工序。
3.2.1 管道原理
Logstash 的管道由三部分组成：
- Input：数据入口。支持 file、kafka、http、tcp 等。
- Filter：数据处理核心。grok 解析、mutate 修改、date 时间处理……
- Output：数据出口。ES、Kafka、文件、邮件……
来看一个实际例子。我处理过 Nginx 日志，原始格式是这样的：
192.168.1.1 - - [10/Oct/2023:13:55:36 +0800] "GET /api/user HTTP/1.1" 200 1234用 Logstash 解析：
input {
beats {
port => 5044
}
}
filter {
grok {
match => { "message" => "%{IP:client_ip} - - \[%{HTTPDATE:timestamp}\] \"%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}\" %{NUMBER:status} %{NUMBER:bytes}" }
}
date {
match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]
target => "@timestamp"
}
mutate {
remove_field => ["message", "timestamp"]
}
}
output {
elasticsearch {
hosts => ["http://localhost:9200"]
index => "nginx-access-%{+yyyy.MM.dd}"
}
}注意：grok 的正则表达式很吃 CPU。如果日志量超过 1000 条/秒，建议在 Filebeat 端做简单解析，Logstash 只做聚合和路由。
3.2.2 性能调优
Logstash 是 Java 写的，内存管理是个坑。我调优时主要关注三个参数：
| 参数 | 默认值 | 建议值 | 说明 |
|---|---|---|---|
| pipeline.workers | CPU 核数 | CPU 核数 * 2 | 增加并行处理能力 |
| pipeline.batch.size | 125 | 500-1000 | 批量处理条数 |
| pipeline.batch.delay | 50ms | 100ms | 等待时间，减少小批次 |
为什么会这样？因为 Logstash 每个事件都要经过完整的管道。批次越大，吞吐量越高，但延迟也越大。你需要根据业务场景做权衡。
3.3 Fluentd：云原生时代的「瑞士军刀」
Fluentd 是 CNCF 毕业项目，在 Kubernetes 生态里用得特别多。它的设计哲学和 Logstash 类似，但更轻量、插件更丰富。
3.3.1 基础使用
安装 Fluentd 推荐用 td-agent：
# 安装
curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh
# 启动
systemctl start td-agent配置文件结构：
<source>
@type tail
path /var/log/nginx/access.log
pos_file /var/log/td-agent/nginx-access.pos
tag nginx.access
format /^(?<ip>[^ ]*) - - \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>\d+) (?<size>\d+)$/
</source>
<match nginx.access>
@type elasticsearch
host localhost
port 9200
logstash_format true
logstash_prefix nginx-access
</match>我的习惯：Fluentd 的 pos_file 一定要配置。它记录了文件读取位置，重启后不会重复采集。这比 Filebeat 的 registry 更直观。
3.3.2 与 Logstash 的对比
很多人问我选 Fluentd 还是 Logstash。我一般这么看：
| 维度 | Fluentd | Logstash |
|---|---|---|
| 资源占用 | 低（Ruby + C） | 高（JVM） |
| 插件生态 | 1000+ 社区插件 | 200+ 官方插件 |
| K8s 支持 | 原生支持（DaemonSet） | 需额外配置 |
| 数据处理 | 较弱（需插件） | 强（grok、mutate） |
说白了，如果你在 K8s 里跑，Fluentd 是首选。如果要做复杂的数据清洗，Logstash 更顺手。
3.4 知识体系总览
下面这张图是我自己总结的日志采集核心逻辑。你看一眼就能明白这三个工具怎么配合：
嗯，这张图其实揭示了一个关键点：Filebeat 负责「采」，Logstash 负责「洗」，Fluentd 负责「转」。实际项目中，我经常把 Filebeat 和 Logstash 搭配使用——Filebeat 部署在每台机器上，Logstash 集中处理。如果数据量特别大，中间还会加一层 Kafka 做缓冲。
避坑总结：
- Filebeat 别采集系统日志，除非你明确知道要什么
- Logstash 的 grok 正则别写太复杂，能用 mutate 就别用 grok
- Fluentd 的 pos_file 一定要配，否则重启后你会哭
好了，这三个工具的基础用法就聊到这儿。你想想看，日志采集其实就三件事：从哪读、怎么处理、往哪写。搞清楚了这些，剩下的就是多踩坑、多总结。我当年在 Filebeat 的 registry 文件上栽过跟头，后来每次升级版本都先备份——这就是经验的价值。