📚 课程目录第4章日志采集与传输

4. 日志采集与传输：Filebeat/Logstash 配置、Kafka/RabbitMQ 作为日志缓冲层的架构设计

在结构化日志体系中，采集与传输层承担着从业务节点收集日志、进行轻量预处理、缓冲削峰以及可靠投递到下游存储/分析系统的职责。本章聚焦于 Filebeat + Logstash 的经典采集链路，以及 Kafka / RabbitMQ 作为缓冲层的架构选型与参数配置。

4.1 采集层核心组件：Filebeat 与 Logstash

组件	定位	资源消耗	典型部署方式
Filebeat	轻量日志采集器，读取文件/标准输出，发送到下游	极低（Go 编写，无 JVM）	Sidecar 或 DaemonSet 每节点部署
Logstash	数据管道引擎，支持丰富 filter 插件进行解析/转换	较高（JVM 堆内存 1-4GB）	独立集群或与 Kafka 消费者合并部署

4.1.1 Filebeat 配置要点

Filebeat 通过 filebeat.yml 定义输入、处理和输出。以下为针对结构化 JSON 日志的推荐配置片段：

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/app/*.log
    json.keys_under_root: true
    json.add_error_key: true
    json.message_key: log
    multiline.pattern: '^\d{4}-\d{2}-\d{2}'
    multiline.negate: true
    multiline.match: after

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - drop_fields:
      fields: ["agent", "ecs"]

output.logstash:
  hosts: ["logstash-node1:5044", "logstash-node2:5044"]
  loadbalance: true
  compression_level: 6

关键参数说明：
json.keys_under_root: true 将 JSON 字段提升到根层级，避免嵌套过深；
multiline 配置用于合并堆栈异常的多行日志；
loadbalance: true 在多个 Logstash 节点间轮询分发，提升吞吐。

4.1.2 Logstash 管道配置

Logstash 使用 pipeline.yml 或单管道配置，典型结构包含 input → filter → output 三个阶段：

input {
  beats {
    port => 5044
    client_inactivity_timeout => 60
    ssl => false   # 生产环境建议开启 SSL
  }
}

filter {
  # 如果日志已经是结构化 JSON，直接保留
  json {
    source => "message"
    target => "parsed"
    skip_on_invalid_json => true
  }

  # 补充时间戳字段
  date {
    match => ["timestamp", "ISO8601"]
    target => "@timestamp"
  }

  # 移除原始 message 字段以节省存储
  mutate {
    remove_field => ["message", "parsed"]
  }
}

output {
  # 写入 Kafka 缓冲层
  kafka {
    topic_id => "structured-logs"
    bootstrap_servers => "kafka1:9092,kafka2:9092,kafka3:9092"
    codec => "json"
    acks => "all"
    compression_type => "snappy"
  }
}

4.2 缓冲层架构设计：Kafka vs RabbitMQ

当日志量突增（如促销活动、故障恢复后日志回放），采集层与消费层之间必须引入缓冲机制，防止下游系统被压垮。Kafka 和 RabbitMQ 是两种主流选择，其适用场景有显著差异。

维度	Kafka	RabbitMQ
设计理念	分布式日志提交日志（Commit Log）	AMQP 消息代理
吞吐量	百万级 msg/s（顺序写磁盘）	万级 msg/s（内存优先）
消息持久化	默认持久化到磁盘，可配置保留策略	支持持久化，但高吞吐下性能下降明显
消费模型	Pull 模式，消费者自主控制速率	Push 模式，代理推送消息给消费者
日志场景适配	⭐ 强烈推荐：海量日志、长期存储、重放	⭐⭐ 适合：中低流量、需要复杂路由

架构决策提示： 在日日志量超过 100GB 或峰值 TPS 超过 5000 的场景下，必须使用 Kafka 作为缓冲层。RabbitMQ 在内存积压时容易触发流控甚至 OOM，不适合日志这种“写多读少”的负载模式。

4.3 基于 Kafka 的日志缓冲架构

以下为推荐的生产级日志采集与传输架构，包含 Filebeat → Logstash → Kafka → 消费端的完整链路：

4.3.1 Kafka 关键参数配置

针对日志场景，Kafka 的 server.properties 和 Topic 配置需做针对性调整：

# broker 端配置
log.retention.hours=72          # 日志保留 3 天，避免磁盘写满
log.retention.bytes=107374182400  # 单分区最大 100GB
log.segment.bytes=536870912     # 段文件 512MB，便于清理
compression.type=snappy         # 生产者端压缩，减少网络带宽

# Topic 配置（创建时指定）
bin/kafka-topics.sh --create \
  --topic structured-logs \
  --partitions 6 \
  --replication-factor 2 \
  --config cleanup.policy=delete \
  --config retention.ms=259200000

4.4 RabbitMQ 作为缓冲层的适用场景

虽然 Kafka 是日志场景的首选，但在以下特定条件下，RabbitMQ 仍可作为轻量缓冲方案：

团队已有成熟的 RabbitMQ 运维体系，且日志量级可控（日均 < 50GB）。
需要基于消息头或 routing key 做复杂路由，将不同服务日志分发到不同消费者。
日志消费端需要确认机制（ACK），确保每条日志至少被处理一次。

  RabbitMQ 配置要点（日志场景）：

  • 使用 topic 类型 Exchange，routing key 格式为 service.env.level（如 order.prod.error）。

  • 队列设置 x-max-length 和 x-max-length-bytes 限制积压上限，防止内存溢出。

  • 生产者启用 publisher-confirms 和 publisher-return，确保日志不丢失。

  • 消费者使用 basicQos(100) 控制预取数量，避免批量拉取导致内存飙升。

4.5 传输链路可靠性保障

日志传输链路中任何一环的故障都可能导致数据丢失。以下为各层级的可靠性策略：

层级	故障场景	保障措施
Filebeat → Logstash	Logstash 宕机	Filebeat 内部队列（memqueue 或 diskqueue）缓存未发送日志，自动重连
Logstash → Kafka	Kafka 集群不可用	Logstash 内置重试机制 + 持久化队列（`queue.type: persisted`）
Kafka 自身	Broker 宕机	副本机制（replication-factor ≥ 2）+ ISR 同步 + acks=all
Kafka → 消费者	消费者处理失败	手动提交 offset + 死信队列（DLQ）存储失败消息

4.6 本章小结

日志采集与传输层的设计核心在于 轻量采集 + 弹性缓冲 + 可靠投递。Filebeat 负责低资源消耗的日志读取与发送，Logstash 承担解析与格式化工作，Kafka 作为缓冲层提供削峰填谷和故障隔离能力。在配置时需重点关注：

Filebeat 的 multiline 和 json 解析参数，确保结构化日志完整进入管道。
Logstash 的 filter 阶段避免过度解析，保持管道吞吐。
Kafka 的分区数、副本数和保留策略需根据日志量和消费能力提前规划。
RabbitMQ 仅适用于中低流量场景，且必须设置队列长度上限。