引子
日志就像服务器的"朋友圈"，记录着系统的一举一动。但当服务器集群规模爆炸式增长，谁还有精力每天挨个查看上百台机器的日志？今天咱们就来聊聊业界鼎鼎大名的日志三剑客——Fluentd、Logstash和Filebeat，用生活化的语言带你看清它们的真面目。
一、初识三位日志管家
1.1 颜值担当 Filebeat 这个由Elastic出品的轻量级日志搬运工，专为"只传输不处理"的场景而生。想象一下快递小哥的工作模式：它把打包好的日志快递（比如系统日志、Nginx日志）直接从家门口（服务器）送到分拣中心（Logstash/Elasticsearch），全程不超过30MB内存占用。
1.2 实力选手 Logstash 如果说Filebeat是快递员，那Logstash就是全能的物流中心。这个用Java编写的工具既能收取快递（input），又会拆包分拣（filter），最后还能精准配送（output）。代价就是需要吃掉稍多的服务器资源，就像个能干的"大胃王"。
1.3 万金油 Fluentd 这个云原生时代的宠儿由Ruby编写，天然适合容器环境。最厉害的是它的插件体系——500+官方插件就像瑞士军刀，从Kafka到S3存储无所不能。用过的运维都说它是"八面玲珑的多面手"。
二、配置实战：来点真功夫
咱们以最常见的Nginx日志收集场景为例，分别用三个工具实现相同功能：收集/var/log/nginx/access.log并发送到Elasticsearch。
2.1 Filebeat极简配置（技术栈：Filebeat 8.x）
filebeat.inputs:
- type: filestream
paths:
- /var/log/nginx/access.log
parsers: # 日志解析配置
- ndjson: # 假设日志是JSON格式
target: "" # 直接解析顶层字段
output.elasticsearch:
hosts: ["http://es01:9200"]
indices:
- index: "nginx-%{+yyyy.MM.dd}" # 按日期分索引
2.2 Logstash全能配置（技术栈：Logstash 7.x）
# nginx.conf
input {
file {
path => "/var/log/nginx/access.log"
start_position => "beginning"
sincedb_path => "/dev/null" # 禁用sincedb（容器环境常用）
}
}
filter {
json { # 解析JSON日志
source => "message"
}
date {
match => ["timestamp", "ISO8601"] # 转换时间戳
}
}
output {
elasticsearch {
hosts => ["http://es01:9200"]
index => "nginx-%{+YYYY.MM.dd}"
}
}
2.3 Fluentd云原生配置（技术栈：Fluentd v1.14）
<source>
@type tail
path /var/log/nginx/access.log
pos_file /var/log/nginx/access.log.pos
tag nginx.access
<parse>
@type json # 解析JSON日志
time_key timestamp # 提取时间字段
time_type string
time_format %iso8601
</parse>
</source>
<match nginx.access>
@type elasticsearch
host es01
port 9200
index_name nginx-${tag_parts[1]}-%Y%m%d # 动态索引命名
</match>
特别提示：在K8s环境中，Fluentd的DaemonSet配置还需要处理Docker日志格式：
<filter kubernetes.**>
@type parser
key_name log
reserve_data true
<parse>
@type json
</parse>
</filter>
三、华山论剑：优缺点大揭秘
3.1 性能角斗场
- Filebeat内存占用：<30MB（轻如鸿毛）
- Logstash内存消耗：~500MB（重量级选手）
- Fluentd内存表现：~80MB（中规中矩）
3.2 功能擂台
- 数据处理能力：
- Filebeat：仅支持简单处理（需要搭配Ingest Node）
- Logstash：Filter插件生态完善（Grok、Mutate等）
- Fluentd：支持流式SQL处理（Fluentd UI可视化）
3.3 特殊技能
- Filebeat：支持自动背压检测（backpressure）
- Logstash：JRuby实现支持Java插件
- Fluentd：原生支持K8s元数据注入
四、避坑指南：新手常见翻车现场
4.1 时区问题
# Logstash补救方案
filter {
ruby {
code => "event.set('@timestamp', event.get('@timestamp').time.localtime('+08:00'))"
}
}
4.2 日志丢失防护 Fluentd的缓存配置示例：
<match **>
@type elasticsearch
# ...其他配置
<buffer>
@type file
path /var/log/fluentd/buffer
flush_interval 5s
retry_forever true
</buffer>
</match>
4.3 字段映射陷阱 Elasticsearch动态映射可能导致字段类型冲突。预防方案：
// 创建索引模板
PUT _index_template/nginx_template
{
"index_patterns": ["nginx-*"],
"mappings": {
"properties": {
"response_time": { "type": "float" },
"user_agent": { "type": "text", "fields": { "keyword": { "type": "keyword" }}}
}
}
}
五、应用场景大匹配
5.1 Filebeat最佳舞台
- 边缘节点日志收集
- IoT设备日志采集
- 需要与Auditbeat/Metricbeat联动时
5.2 Logstash主场作战
- ETL复杂转换需求
- 需要对接传统数据库（Oracle/SQL Server）
- 多源数据混合处理场景
5.3 Fluentd制霸领域
- Kubernetes集群日志
- 多云环境日志统一
- 需要流式处理（搭配Apache Kafka）
六、我该怎么选？
看完三大高手的表演，选择困难症都要犯了？记住这三条黄金法则：
- 简单就是美：单一数据源→Filebeat，需要复杂处理→Logstash
- 跟着环境走：传统物理机→Logstash，云原生→Fluentd
- 混合出奇迹：Filebeat+Fluentd组合（前者采集，后者路由）
最后送大家一个私藏配方：中小规模推荐Filebeat直连ES，大规模使用Fluentd+Kafka+ES组合，超大规模考虑Fluentd+ClickHouse方案。