日志采集基础：挑战、工具对比与架构设计

日志采集，说白了就是整个日志分析体系的「水源」。水源要是脏了、断了，后面再牛的分析引擎也白搭。我这些年踩过的坑，十有八九都出在采集这一层。今天咱们就把这块硬骨头啃透。

一、日志采集的三大挑战

先说说为什么采集这么头疼。你想想看，一个中型互联网公司，每天产生的日志量轻松上 TB。这还不算完，真正的挑战在下面这三点。

1. 数据源的「千奇百怪」

我在项目中遇到过最夸张的情况：同一个业务线，日志格式有 JSON、有纯文本、有二进制、还有自定义的 protobuf。更别提那些遗留系统，日志直接往 Windows 事件查看器里写。嗯，采集这些数据，就像让一个厨师同时做中餐、西餐、日料——工具得足够灵活。

2. 可靠性与性能的博弈

采集器挂了怎么办？丢日志了怎么办？我曾经因为 Filebeat 内存泄漏，导致线上日志丢了整整 2 小时。事后复盘发现，问题出在采集器写入 Kafka 时没做重试机制。说白了，采集架构必须考虑「至少一次」的语义，同时不能把业务服务器拖垮。

3. 海量日志的「降噪」

你以为日志越多越好？错。我见过一个团队，把 DEBUG 级别的日志全量采集，结果 Elasticsearch 集群直接被打爆。真正的挑战在于：哪些日志该采？哪些该过滤？哪些该采样？这需要你对业务有深刻理解。

二、三大主流采集工具对比

市面上工具很多，但真正经得起生产环境考验的，就这三家：Logstash、Fluentd、Filebeat。我挨个说说它们的脾气秉性。

特性	Logstash	Fluentd	Filebeat
开发语言	Java (JRuby)	Ruby + C	Go
资源消耗	高（默认 1GB+ 堆内存）	中（约 200-500MB）	低（约 10-50MB）
插件生态	丰富（200+ 插件）	丰富（1000+ 插件）	较少（专注文件采集）
数据处理能力	强（内置 filter 丰富）	中（需配合插件）	弱（仅简单处理）
典型场景	复杂 ETL、数据中转	容器化、Kubernetes 环境	轻量级日志采集

Logstash：重型武器

Logstash 功能确实强大，但代价也大。我记得有一次，线上 Logstash 实例因为 GC 停顿，导致数据积压了 30 分钟。后来我学乖了：Logstash 只做中转和复杂处理，绝不放业务服务器上。

它的 filter 插件是真香。比如用 grok 解析非结构化日志：

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
}

这段配置能把一行 Apache 日志拆成十几个字段。但注意，grok 性能开销不小，生产环境建议用 dissect 替代。

Fluentd：容器时代的宠儿

Fluentd 在 Kubernetes 生态里几乎是标配。它的内存模型比 Logstash 优雅，而且支持热加载配置。我个人习惯在容器环境里用 Fluentd + Fluent Bit 的组合——Fluent Bit 做轻量采集，Fluentd 做聚合转发。

不过 Fluentd 有个坑：它的 buffer 机制默认是内存，一旦进程崩溃，数据就丢了。我曾经在线上加过这个配置：

<buffer>
  @type file
  path /var/log/fluentd-buffer
  flush_interval 5s
  retry_max_times 10
</buffer>

改成文件 buffer 后，再也没丢过数据。

Filebeat：轻量之王

Filebeat 是我最常用的采集器。为什么？因为它够轻、够稳。Go 写的，单实例只占几十 MB 内存，部署在业务服务器上几乎无感。

但 Filebeat 也有短板——它基本不做数据处理。说白了，它就是个「搬运工」。所以我的典型用法是：Filebeat 采集 → Kafka 缓冲 → Logstash 处理 → Elasticsearch 存储。

一个典型的 Filebeat 配置：

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/*.log
  fields:
    service: nginx
    env: production

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "nginx-logs"
  partition.round_robin:
    reachable_only: true

三、采集架构设计原则

工具选好了，怎么搭架构？我总结了四条铁律。

原则一：分层解耦

千万别把采集、处理、存储揉在一起。我见过最蠢的架构：Logstash 直接写 Elasticsearch，结果 Logstash 一挂，ES 写入也断了。正确的做法是中间加一层消息队列（Kafka 或 Redis）。

分层的好处很明显：

• 采集层挂了，数据还在队列里
• 处理层可以水平扩展
• 存储层可以独立升级

原则二：就近过滤

能早过滤的，绝不拖到后面。比如 Nginx 的 404 日志，如果不需要分析，直接在 Filebeat 里用 drop_event 过滤掉：

processors:
  - drop_event:
      when:
        equals:
          http.response.status_code: 404

这样做的好处是：减少网络传输、降低存储成本。我曾经帮一个客户做优化，光这一步就省了 60% 的日志量。

原则三：缓冲为王

任何采集架构，都必须有缓冲层。为什么？因为下游系统（ES、HDFS）随时可能挂。没有缓冲，数据就丢了。

我个人习惯用 Kafka 做缓冲，原因有三：

1. 吞吐量高（单机轻松 10 万+/秒）
2. 持久化（数据不会丢）
3. 多消费者（一个日志流可以同时喂给 ES 和 Spark）

原则四：可观测性

采集系统本身也需要监控。我见过太多团队，日志采集器挂了三天都没发现。建议至少监控这几个指标：

• 采集延迟（当前时间 - 日志时间戳）
• 采集速率（每秒多少条）
• 错误率（解析失败、写入失败）
• 资源使用（CPU、内存、磁盘）

好了，这一章的内容就到这。下一章咱们聊聊日志传输的「高速公路」——Kafka 在日志体系中的最佳实践。到时候我会分享一个线上事故，保证让你印象深刻。