3. 日志采集技术：Filebeat、Logstash、Fluentd 的安装与配置、日志采集架构设计

3.1 日志采集在故障定位中的角色

在故障定位流程中，日志采集是数据管道的起点。采集层的稳定性、低延迟与资源消耗直接影响后续分析的质量。本节聚焦三种主流采集工具：Filebeat（轻量级转发器）、Logstash（重型处理管道）、Fluentd（统一日志层），并给出生产级架构设计原则。

3.2 Filebeat：轻量级日志转发器

3.2.1 安装与基础配置

Filebeat 使用 Go 编写，无外部依赖，适合部署在每台业务主机上。

# 下载并安装（以 ELK 7.17 为例）
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.17.0-linux-x86_64.tar.gz
tar xzf filebeat-7.17.0-linux-x86_64.tar.gz
cd filebeat-7.17.0-linux-x86_64

# 编辑 filebeat.yml
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/*.log
  fields:
    service: myapp
    env: production

output.elasticsearch:
  hosts: ["http://es-cluster:9200"]
  index: "filebeat-%{[fields.service]}-%{+yyyy.MM.dd}"

3.2.2 关键配置参数

3.3 Logstash：强大的数据处理管道

3.3.1 安装与配置

Logstash 基于 JRuby，功能丰富但资源消耗较高，通常部署在独立节点或与 Elasticsearch 同机。

# 下载安装
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.17.0-linux-x86_64.tar.gz
tar xzf logstash-7.17.0-linux-x86_64.tar.gz
cd logstash-7.17.0

# 创建管道配置 pipeline.conf
input {
  beats {
    port => 5044
    client_inactivity_timeout => 60
  }
}

filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{GREEDYDATA:msg}" }
  }
  date {
    match => [ "timestamp", "ISO8601" ]
    target => "@timestamp"
  }
}

output {
  elasticsearch {
    hosts => ["http://es-cluster:9200"]
    index => "logstash-%{+YYYY.MM.dd}"
  }
}

3.3.2 常用插件对比

3.4 Fluentd：统一日志层

3.4.1 安装与配置

Fluentd 使用 Ruby + C 插件，强调可插拔架构，在 Kubernetes 生态中广泛使用。

# 通过 td-agent 安装（CentOS）
curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh

# 配置文件 /etc/td-agent/td-agent.conf
<source>
  @type tail
  path /var/log/app/*.log
  pos_file /var/log/td-agent/app.pos
  tag app.log
  <parse>
    @type json
  </parse>
</source>

<match app.log>
  @type elasticsearch
  host es-cluster
  port 9200
  logstash_format true
  logstash_prefix fluentd
</match>

3.4.2 性能调优要点

• Buffer 配置：使用 @type file 或 @type memory，设置 chunk_limit_size 和 flush_interval 控制吞吐。
• 线程模型：通过 workers 参数设置并行处理线程数，建议等于 CPU 核心数。
• 重试策略：配置 retry_max_times 和 retry_wait 避免无限重试导致内存溢出。

3.5 日志采集架构设计

3.5.1 三种典型架构

3.5.2 生产级架构设计原则

• 分层隔离：采集层（Agent）与处理层（Aggregator）分离，避免业务主机负载过高。
• 缓冲层必选：至少引入 Kafka 或 Redis 作为缓冲，防止后端故障导致日志丢失。
• 幂等写入：确保日志可重复消费，下游做去重或幂等处理。
• 监控告警：对采集延迟、丢失率、队列积压设置告警阈值。

3.5.3 日志采集架构总览图

3.6 工具选型对比