📚 课程目录第4章日志收集工具

日志收集工具：选型、配置与实战

这一章我们来聊聊日志收集工具。说白了，就是把分散在各台服务器、各个容器里的日志文件，高效地、可靠地送到一个中心化平台去。

你想想看，线上几十上百台机器，每台都在疯狂写日志。出了问题，总不能一台台登录上去 grep 吧？那就回到石器时代了。所以，一个趁手的日志收集工具，是构建异常行为识别系统的第一步，也是地基。

我个人在项目中用过不少工具，踩过不少坑，也积累了一些经验。今天我把最常用的三兄弟——Filebeat、Logstash 和 Fluentd 给大家掰开揉碎了讲讲。

淘金三兄弟：Filebeat、Logstash、Fluentd

这三个工具各有侧重。你可以把它们想象成一条流水线上的不同角色。下面这个表格能让你快速看清楚它们的定位：

维度	Filebeat	Logstash	Fluentd
核心定位	轻量级 Shippers（搬运工）	重量级数据管道（处理中心）	统一日志层（均衡型管道）
资源消耗	极低，Go 语言编写	较高，JRuby + JVM	中等，C + Ruby
数据处理	基础，支持简单字段提取和少量处理	丰富，有 200+ 插件，擅长复杂清洗和转换	中等，有 1000+ 插件，生态强大，偏向路由和结构化
适用场景	轻量采集，最好只做搬运工	数据格式混乱、需要大量 ETL 的场景	容器化、云原生环境，需要高可靠性和路由灵活性
缓冲保证	内置内存队列和磁盘缓存的背压机制	默认内存，可配持久化队列	内存 + 文件 Buffer，支持多种输出重试策略

先说说 Filebeat。我特别喜欢这工具，因为它真的轻。当年我用 Logstash 去采集日志，结果发现日志采集进程占了服务器 15% 的 CPU，那还了得？后来换成 Filebeat，CPU 占用直接掉到 1% 以下。它只用干一件事：读文件，送到下游。我建议你把 Filebeat 部署在每一台业务服务器上，让它专职做搬运工。

  避坑指南：我曾经遇到过一个 case，Filebeat 配置的 harvester_buffer_size 太小，导致某些大行日志被截断。记得根据你的业务日志最大行大小调整这个参数，默认值是 16384 字节。

然后是 Logstash。这就像一个大熔炉。你可以把各种奇形怪状的日志扔进去，通过它的 filter 插件（比如 grok、mutate、date）拆解、清洗、转换，最后输出成漂亮的 JSON 格式。

一个典型的 Logstash pipeline 长这样：

input {
  beats {
    port => 5044  # 从 Filebeat 接收数据
  }
}

filter {
  if [source_type] == "nginx-access" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
    date {
      match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
      target => "@timestamp"
    }
  }
}

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

你看，它把 Nginx 的每一行文本日志，解析成了 clientip、verb、response 这种有意义的字段。这下我们的异常检测模型就有结构化的数据可喂了。不过要注意，Logstash 的资源消耗不低。我建议把它部署在专用的处理服务器上，不要和业务服务混跑。

最后是 Fluentd。它在容器圈里特别流行。为什么？因为它有个关键的插件叫 fluent-plugin-kubernetes_metadata_filter，能从容器日志里自动打上 Pod 名、命名空间、容器名等标签。这对于在 Kubernetes 里排查问题简直太方便了。

性能警示：Fluentd 的 in_tail 插件在监控大量（比如 500+）日志文件时，可能会因为 inotify 句柄耗尽而丢日志。我建议开启 refresh_interval 并配合 pos_file 持久化记录读取位置，防止重启后重复读取或遗漏。

那到底怎么选？我的建议很简单：

资源敏感、只做搬运：选 Filebeat，没毛病。
日志格式非常混乱、需要复杂解析：Logstash 的 grok 正则和 mutate 插件是神器。
容器化、微服务、多数据源：Fluentd 的路由能力和 Kubernetes 集成最好。
最稳妥的架构：Filebeat + Logstash 组合。Filebeat 扛采集，Logstash 扛处理，各司其职。

核心逻辑总览

下面的图帮我们把这个章节的核心逻辑串起来。展示了从日志产生到被分析消费的完整链路，以及三个工具在其中的定位。

选择策略：因地制宜，别迷信银弹

到底选哪个？没有银弹。我建议你根据你团队的运维能力和场景做决定。

如果你团队小，追求轻量：就用 Filebeat + Kafka + 自定义消费程序。Filebeat 负责可靠收集，Kafka 负责解耦和缓冲。
如果你已经上了 ELK 全家桶：那就别折腾了，Filebeat + Logstash + Elasticsearch 是标准配餐。省心，官方文档支持也最好。
如果你在大力推广容器化和 Service Mesh：Fluentd 会是你最好的朋友。你能想象那种直接用 @type kubernetes_metadata 就拿到完整 Kubernetes Pod 元信息的快感吗？省去了很多手写 API 查询的麻烦。

一个实用的架构建议

嗯，这里要注意一件事。很多初学者喜欢把什么都塞进 Logstash 里处理。但我觉得最好的实践是：分工协作。

我的最佳实践流水线：

日志源头 → Filebeat（只采集、简单打标签）→ Kafka（缓冲） → Logstash（批量处理、复杂解析） → Elasticsearch（存储 + 索引）

这样做的好处是，即使 Logstash 挂了，Kafka 里的日志不会丢。Filebeat 的采集也完全不受影响。

再者，如果你不想写复杂的 Logstash 配置，也可以用 Logstash 的 pipeline to pipeline 特性。把采集、解析、输出拆成多个独立的 pipeline 文件，方便调试和维护。我习惯把每个数据源（比如 Nginx、MySQL、应用日志）拆成单独的配置文件，可读性高很多。