3、日志采集技术：Filebeat 基础配置、Logstash 管道处理、Fluentd 插件生态、日志采集最佳实践
日志采集，说白了就是大屏监控系统的「眼睛」。数据采不上来，后面再炫酷的可视化都是白搭。我这些年踩过的坑，有一半都出在日志采集这一层。今天咱们就把 Filebeat、Logstash、Fluentd 这三兄弟掰开揉碎聊清楚。
3.1 Filebeat 基础配置：轻量级采集的「尖兵」
Filebeat 是 Elastic 家的轻量级日志采集器。为什么说它「轻」？因为它用 Go 写的，资源占用极低。我在项目中见过一台 2C4G 的虚拟机，同时跑 3 个 Filebeat 实例，CPU 占用不到 5%。
核心配置要点：
- input 配置：定义从哪读日志。支持文件、stdin、syslog 等。
- output 配置：日志发往哪里。常见的有 Elasticsearch、Logstash、Kafka。
- registry 文件：记录读取进度。Filebeat 重启后能接着读，不会丢数据。
来看一个最基础的配置示例：
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/nginx/access.log
fields:
service: nginx
env: production
output.elasticsearch:
hosts: ["http://192.168.1.100:9200"]
index: "nginx-access-%{+yyyy.MM.dd}"
logging.level: info
logging.to_files: true
logging.files:
path: /var/log/filebeat
name: filebeat.log
keepfiles: 7
嗯，这里要注意 registry 文件。我曾经有一次手贱删了它，结果 Filebeat 重新读取了所有历史日志，把 ES 集群直接打挂了。所以——千万别动 registry 文件，除非你清楚自己在干什么。
我的小技巧：生产环境建议把 output 先指向 Kafka，而不是直接怼 ES。这样即使 ES 挂了，日志也不会丢。Kafka 作为缓冲层，稳得很。
3.2 Logstash 管道处理：数据加工的「中央厨房」
Logstash 的核心是管道（Pipeline）。数据进来，经过 input → filter → output 三个阶段。我个人习惯把 filter 阶段当作「数据清洗车间」。
为什么会需要 Logstash？你想想看，原始日志通常是乱七八糟的。Nginx 的日志格式、Java 的堆栈信息、数据库的慢查询日志……格式千奇百怪。Logstash 就是用来把这些「脏数据」洗成统一格式的。
一个典型的 Logstash 管道配置：
input {
beats {
port => 5044
}
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]
target => "@timestamp"
}
mutate {
remove_field => ["message", "original"]
}
}
output {
elasticsearch {
hosts => ["http://192.168.1.100:9200"]
index => "weblog-%{+yyyy.MM.dd}"
}
}
我在项目中遇到过最头疼的问题：grok 正则写错了。有一次我写了个贪婪匹配，结果 Logstash 处理单条日志花了 3 秒，整个管道直接堵死。后来我学乖了——先用 grok debugger 工具验证正则，再上线。
避坑指南：我曾经在生产环境直接修改 Logstash 配置并 reload，结果管道状态没更新，数据丢了 2 小时。后来我改成「先停采集、再改配置、最后重启」的流程。虽然麻烦点，但稳。
3.3 Fluentd 插件生态：灵活到「变态」的采集框架
Fluentd 是 Treasure Data 家的开源项目。它的插件生态是我见过最丰富的——官方和社区加起来有 1000+ 个插件。说白了，只要你能想到的数据源，基本都有现成的插件。
Fluentd 的核心设计理念是「统一日志层」。它用 JSON 格式统一所有日志，然后用插件做输入、解析、输出。我个人觉得，Fluentd 的灵活性比 Logstash 强，但性能稍弱一些。
来看一个 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>
<filter nginx.access>
@type record_transformer
<record>
service nginx
env ${record["env"] || "production"}
</record>
</filter>
<match nginx.access>
@type elasticsearch
host 192.168.1.100
port 9200
index_name fluentd-nginx
<buffer>
@type file
path /var/log/td-agent/buffer/nginx
flush_interval 5s
</buffer>
</match>
Fluentd 的 buffer 机制是我特别喜欢的。它把数据先缓存到本地文件，再批量发送。这样即使 ES 挂了，数据也不会丢。我在一个日处理 10 亿条日志的项目中，就是靠 Fluentd 的 buffer 扛住了 ES 的两次宕机。
插件推荐：
| 插件名称 | 用途 | 我的评价 |
|---|---|---|
| fluent-plugin-kafka | 输出到 Kafka | 生产环境必备，稳如老狗 |
| fluent-plugin-rewrite-tag-filter | 动态修改 tag | 路由日志的利器 |
| fluent-plugin-elasticsearch | 输出到 ES | 支持批量写入，性能不错 |
| fluent-plugin-grok-parser | 解析非结构化日志 | 和 Logstash 的 grok 类似 |
3.4 日志采集最佳实践：我踩过的坑，你别再踩
做了这么多年数据架构，日志采集的坑我基本都踩了一遍。下面这几条，是我用真金白银换来的经验。
- 永远不要直接采集到 ES。中间加一层 Kafka 或 Redis，成本不高，但能救命。
- 日志格式必须统一。我见过一个项目，3 个团队用了 5 种日志格式，最后解析规则写了 200 行。统一格式，能省 80% 的解析工作。
- 采集端必须做限流。Filebeat 和 Fluentd 都支持
rate_limit配置。我曾经没配限流，结果日志量暴增时直接把 ES 打挂了。 - 监控采集器本身。采集器挂了，你都不知道。我习惯给每个采集器配一个心跳日志，每 5 秒发一条「我还活着」的消息。
- 日志轮转要配合好。Linux 的 logrotate 和采集器的 registry 文件要协调。我见过 logrotate 把日志删了，但 Filebeat 还在读旧文件，结果一直报错。
我的选择建议：
- 小规模（< 10 台服务器）：Filebeat + ES，简单直接
- 中等规模（10-100 台）：Filebeat + Kafka + Logstash + ES，灵活可控
- 大规模（> 100 台）：Fluentd + Kafka + 自研处理引擎，定制化强
最后说一句：日志采集没有银弹。每个公司的业务场景、技术栈、团队能力都不一样。我的建议是——先跑通最简单的方案，再逐步优化。别一开始就想着搞个完美的架构，结果半年都上不了线。
嗯，这一章就聊到这儿。下一章咱们讲讲「数据清洗与转换」，到时候我会分享一个我处理过的「脏数据」案例，保证让你大开眼界。