日志采集架构：三大采集工具实战对比

说到审计日志的采集，我先讲一个真实场景。早些年我接手过一个金融项目，每天要处理几个TB的访问日志。当时团队用了一台单体服务器跑采集脚本，结果系统刚上线就崩了——日志积压导致磁盘写满，业务直接停摆。从那以后，我再也不敢轻视采集架构。

分布式采集不是花架子，它解决的核心问题就两个：高可用和水平扩展。那你想想看，如果一台机器挂掉，日志就丢了，审计怎么追责？所以必须让采集工具自己具备容错能力。

采集架构的核心诉求

先列几个硬性指标，你在设计告警规则前必须想清楚：

• 零丢失：采集中断后能重传，不能丢数据
• 低延迟：日志从产生到进入管道，延迟控制在秒级
• 资源轻量：不能因为采集拖垮业务进程
• 格式适配：文本、JSON、多行异常栈都能处理

我记得在电商大促期间，峰值QPS冲到每秒80万，日志采集的CPU占用必须压到5%以下。选错了工具，业务工程师会直接骂你浪费机器。

三大工具的定位差异

市场上主流的分布式采集工具就这三款：Filebeat、Logstash、Fluentd。你可能觉得都是采集，差别不大。其实它们的定位非常不同。

特性	Filebeat	Logstash	Fluentd
语言	Go	JRuby（Java）	C+Ruby
资源占用	极低（~10MB）	较高（~200MB）	中等（~50MB）
处理能力	仅采集+转发	采集+过滤+转换+输出	采集+过滤+缓存+输出
内置过滤器	无	极其丰富（grok、date、mutate等）	丰富（parser、formatter、filter）
输出插件	Elasticsearch、Kafka、Logstash	几乎所有数据目标	数百种插件
典型场景	轻量Agent + Logstash集群	集中式数据管道	微服务/容器环境
社区热度	ELK生态主力	ELK生态核心	CNCF毕业项目

Filebeat：轻量级的“哨兵”

Filebeat的设计哲学就是一个字：轻。它只做两件事——读文件、发数据。不做任何数据转换，所以CPU和内存开销都极小。

我曾经踩过一个坑：在一次压力测试中，Logstash直接吃掉40%的CPU，而Filebeat始终低于3%。后来我把Logstash的解析工作拆到下游，前端只部署Filebeat，集群压力立刻降下来了。

下面是一个典型的Filebeat配置，采集系统审计日志并发送到Kafka：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/secure
    - /var/log/auth.log
  fields:
    app_type: audit
  fields_under_root: true

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: audit-logs
  partition.round_robin:
    reachable_only: true
  required_acks: 1
  compression: gzip

Logstash：管道里的“瑞士军刀”

Logstash才是真正的数据处理中心。它的filter插件能完成：正则解析（grok）、时间格式化（date）、字段增删（mutate）、IP地理信息解析（geoip）等等。

我个人习惯把Filebeat+Logstash串成两段：Filebeat负责采集和传输，Logstash负责格式化与告警预处理。举个例子，审计日志里经常有非法登录尝试，我在Logstash里直接配置阈值过滤，一旦同一IP在60秒内出现5次失败，就打上[ALERT]标签送到Elasticsearch，再触发告警。

filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{DATA:hostname} sshd\[%{NUMBER:pid}\]: %{GREEDYDATA:msg}" }
  }
  if "Failed password" in [msg] {
    mutate {
      add_tag => ["auth_failure"]
    }
    throttle {
      key => "%{[host][ip]}"
      group => "ssh_brute"
      before_count => -1
      after_count => 5
      period => 60
      max_delay => 0
      add_tag => ["brute_force_alert"]
    }
  }
}

Fluentd：云原生的“数据流引擎”

Fluentd在CNCF生态里地位特殊。它的buffer机制非常强大，支持内存、文件两级缓存，即使后端（ES、Kafka）挂掉，数据也不会丢失。这对审计日志的完整性至关重要。

我在微服务架构里常用Fluentd配合Kubernetes DaemonSet部署。每个节点一个Pod，自动采集宿主机上所有容器的stdout和文件日志，通过tag区分namespace和服务。

<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /var/log/fluentd-containers.log.pos
  tag "kube.*"
  format json
</source>

<filter kube.**>
  @type kubernetes_metadata
</filter>

<match kube.var.log.containers.**>
  @type elasticsearch
  host elasticsearch-headless
  port 9200
  logstash_format true
  buffer_type file
  buffer_path /var/log/fluentd-buffer
  <buffer>
    flush_interval 30s
    retry_max_interval 30
    retry_forever true
  </buffer>
</match>

你注意看那个<buffer>段，retry_forever true表示后台挂掉之后Fluentd会无限重试，数据永远不丢。这就是审计场景最需要的保障。

架构决策树：到底怎么选？

说了这么多，你可能还是纠结。没事，我画了一张基于实际场景的选择流程，直接告诉你答案。

这张图我想你应该看得懂。核心逻辑就一句话：日志量越大，越需要把采集层和处理层分离。不要试图用一个工具包打天下。

生产环境中的常见陷阱

1. Filebeat的backoff设置：如果后端不可用，Filebeat会指数退避重试。默认最小值1秒，最大值60秒。我建议把max_backoff调到300秒，避免频繁重试打爆网络。
2. Logstash的内存泄漏：JVM的Metaspace区如果不设置上限，长期运行会撑爆。在jvm.options里加上-XX:MaxMetaspaceSize=256m。
3. Fluentd的buffer路径：必须和数据盘分开。我曾经因为buffer目录放在系统盘，写入日志把根分区填满了，导致整个宿主机宕机。

总结一句话

选Filebeat+Logstash还是Fluentd+Kafka，取决于你对延迟、吞吐、容错的优先级排序。没有银弹，只有最适合你当前架构的组合。嗯，这一章到这里，赶紧去检查一下你现有的采集管道吧。