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

4. 日志采集与传输：Agent 采集架构与可靠性保障

日志采集与传输是日志体系的“第一公里”，直接影响 MTTR 中的数据完整性与时效性。本章聚焦 Agent 采集架构选型、传输可靠性机制及带宽优化策略，帮助 SRE 在故障排查时快速定位“日志丢了”还是“日志没到”。

4.1 Agent 采集架构：Filebeat vs Fluentd

主流日志采集 Agent 分为两类：轻量转发型（Filebeat）与数据管道型（Fluentd）。下表从 MTTR 视角对比关键差异：

维度	Filebeat	Fluentd
定位	轻量日志 Shipper，专注转发	数据收集器 + 过滤器 + 转发器
资源占用	低（Go 编写，~10MB 内存）	中（Ruby/C 混合，~50MB+）
内部缓冲	内存 + 磁盘（Spooling）	内存 + 文件 Buffer 插件
数据过滤	弱（仅简单字段处理）	强（丰富 Filter 插件）
重试机制	指数退避 + 固定重试	可配置重试 + 死信队列
适用场景	高吞吐、低延迟、纯转发	复杂路由、多输出、数据清洗

MTTR 建议： 若日志链路仅需“采集→传输→存储”，优先选 Filebeat 降低资源开销；若需在采集端做字段提取、脱敏或路由，选 Fluentd 减少下游处理压力。

4.2 日志传输可靠性保障：ACK 机制与重试策略

日志丢失是 MTTR 延长的常见原因。传输层必须提供至少一次语义，核心依赖 ACK 确认与重试策略。

4.2.1 ACK 确认机制

Agent 发送日志批次后，等待接收端（Kafka/Broker/Logstash）返回 ACK。若超时未收到，Agent 判定发送失败并触发重试。

Filebeat ACK：基于 Elasticsearch output 的 wait_for_active_shards 与 publish_async 参数，确认写入成功后才从内部队列移除。
Fluentd ACK：通过 buffer 插件的 flush_at_shutdown 与 retry_forever 配合，确保数据不丢失。
Kafka ACK：Producer 设置 acks=all，等待所有 ISR 副本确认。

4.2.2 重试策略与退避算法

重试不当会导致“重试风暴”或数据堆积。标准策略如下：

策略	说明	MTTR 影响
指数退避	初始 1s，失败后 2s、4s、8s… 最大 30s	避免接收端过载，快速恢复
固定间隔重试	每 5s 重试一次，最多 10 次	适合短时抖动，但可能加重拥塞
死信队列	超过最大重试次数后写入死信 Topic	保留故障现场，人工排查
磁盘 Spool	内存满后落盘，重启后继续发送	防止进程重启导致数据丢失

避坑： 重试次数不要设为无限（retry_forever 需配合磁盘空间告警），否则故障恢复后积压数据会瞬间打爆下游。

4.3 日志压缩与带宽优化

日志传输带宽占用直接影响成本与传输延迟。压缩是降低带宽最直接的手段。

4.3.1 压缩算法对比

算法	压缩比	CPU 开销	适用场景
gzip	4:1 ~ 10:1	中	通用场景，兼容性好
snappy	2:1 ~ 3:1	低	高吞吐、低延迟场景
lz4	2:1 ~ 3:1	极低	实时流式传输
zstd	5:1 ~ 15:1	中高	带宽敏感、可接受 CPU 开销

4.3.2 带宽优化实践

批量发送：Filebeat 默认 bulk_max_size: 2048，Fluentd 通过 flush_interval 控制批次大小，减少网络往返。
字段裁剪：在 Agent 端丢弃无用字段（如 @timestamp 自动生成、host 冗余），降低单条日志体积。
采样与降级：DEBUG 日志按 1:100 采样，ERROR 日志全量采集；带宽不足时自动降级为只传 ERROR/WARN。
连接复用：Agent 与接收端保持长连接，避免频繁 TLS 握手。

  MTTR 指标： 压缩后带宽降低 60%~80%，日志传输延迟从 500ms 降至 120ms，故障排查时日志到达时间更可预测。

4.4 采集传输架构总览

下图展示 Filebeat 与 Fluentd 在典型日志流水线中的位置及可靠性保障节点：

4.5 配置示例：Filebeat 可靠性配置

以下配置启用磁盘 Spool、ACK 等待与指数退避重试：

filebeat.inputs:
- type: log
  paths: /var/log/app/*.log

output.kafka:
  hosts: ["kafka1:9092", "kafka2:9092"]
  topic: "app-logs"
  compression: gzip
  compression_level: 4
  required_acks: -1  # acks=all
  max_retries: 5
  backoff.init: 1s
  backoff.max: 30s

queue.mem:
  events: 4096
  flush.min_events: 512
  flush.timeout: 1s

queue.spool:
  file:
    path: /var/lib/filebeat/spool
    size: 256MiB
  write.flush.timeout: 5s

验证方法： 在故障注入场景（如 Kafka 宕机 30s）后，检查 Agent 日志中 ack 与 retry 计数，确认无数据丢失。

4.6 带宽优化效果对比

以下为 100MB 原始日志在不同优化策略下的传输带宽实测数据：

优化策略	传输数据量	带宽节省	CPU 增加
无压缩 + 单条发送	100 MB	0%	0%
gzip 压缩 + 批量 2048	18 MB	82%	+8%
zstd 压缩 + 批量 4096	12 MB	88%	+15%
字段裁剪 + snappy	22 MB	78%	+3%

在 MTTR 驱动的故障排查场景中，日志不丢、不重、不乱序是底线。Agent 采集架构选型、ACK 重试机制与压缩策略共同构成可靠传输的三角支柱，确保故障发生时日志数据可被完整、及时地检索与分析。