Docker容器日志收集实战：Fluentd+Elasticsearch日志分析方案

Docker容器日志驱动配置与日志收集架构

Docker容器日志管理是网站运维中的关键环节。默认情况下Docker使用json-file日志驱动，日志直接写入容器内部文件系统，随着容器运行时间增长，日志文件会占用大量磁盘空间。生产环境中必须配置集中化的日志收集方案，将容器日志统一采集、存储和分析。

Docker支持多种日志驱动，常见的配置方式是在daemon.json中全局设置：

cat > /etc/docker/daemon.json << 'EOF'
{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "docker.{{.Name}}",
    "fluentd-async": "true",
    "fluentd-buffer-limit": "10000",
    "fluentd-retry-wait": "5s",
    "fluentd-max-retries": "10"
  }
}
EOF

systemctl restart docker

tag字段使用Docker模板变量，{{.Name}}会被替换为容器名称。fluentd-async启用异步发送模式，当Fluentd不可用时日志会缓存在本地，避免日志丢失影响业务运行。

Fluentd部署与日志采集配置

Fluentd作为日志收集层的核心组件，负责接收Docker发送的日志、进行格式化处理和路由分发。使用Docker方式部署Fluentd最为便捷：

docker run -d \
  --name fluentd \
  --restart always \
  -p 24224:24224 \
  -p 24224:24224/udp \
  -v /etc/fluent/fluent.conf:/fluentd/etc/fluent.conf \
  -v /var/log/fluentd:/var/log/fluentd \
  fluent/fluentd:v1.17-debian-1

Fluentd配置文件分为source、filter、match三个部分：

# /etc/fluent/fluent.conf

<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

# 解析Docker日志中的JSON内容
<filter docker.**>
  @type parser
  key_name log
  reserve_data true
  <parse>
    @type json
  </parse>
</filter>

# 添加主机名字段
<filter docker.**>
  @type record_transformer
  <record>
    hostname "${hostname}"
    collect_time "${time}"
  </record>
</filter>

# 输出到Elasticsearch
<match docker.**>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix docker-logs
  logstash_dateformat %Y.%m.%d
  type_name _doc
  flush_interval 10s
  buffer_type file
  buffer_path /var/log/fluentd/buffer
  buffer_chunk_limit 16m
  buffer_queue_limit 32
  flush_at_shutdown true
  retry_wait 5s
  retry_max_times 10
</match>

# 错误日志输出到文件
<match fluent.**>
  @type file
  path /var/log/fluentd/error
</match>

buffer配置是日志收集方案中防止数据丢失的关键。buffer_type设置为file后，日志在发送到Elasticsearch前会先持久化到本地文件，即使Fluentd进程重启也不会丢失缓冲区中的数据。buffer_chunk_limit设置为16MB，buffer_queue_limit设置为32，即最多缓冲512MB日志数据。

Elasticsearch索引管理与日志存储策略

Elasticsearch作为日志存储后端，需要针对日志场景做专门的索引配置。日志数据写入量大、查询频率低，采用时间序列索引模式最为合理：

# 创建索引模板
PUT _index_template/docker-logs
{
  "index_patterns": ["docker-logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 1,
      "number_of_replicas": 0,
      "refresh_interval": "30s",
      "index.codec": "best_compression"
    },
    "mappings": {
      "properties": {
        "log": { "type": "text", "analyzer": "standard" },
        "container_name": { "type": "keyword" },
        "hostname": { "type": "keyword" },
        "level": { "type": "keyword" },
        "collect_time": { "type": "date" }
      }
    }
  }
}

number_of_replicas设置为0是因为日志数据通常不需要高可用副本，节省存储空间。refresh_interval设置为30秒可以降低索引刷新频率，提升写入吞吐量。best_compression编码方式可以将存储空间压缩40%左右。

使用ILM（Index Lifecycle Management）自动管理日志索引的生命周期：

PUT _ilm/policy/docker-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "10gb",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "3d",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "delete": {
        "min_age": "14d",
        "actions": { "delete": {} }
      }
    }
  }
}

该策略在索引创建后每天或达到10GB时滚动创建新索引，3天后进入warm阶段进行段合并，14天后自动删除。根据实际存储需求调整delete阶段的min_age。

Kibana可视化与日志查询配置

Kibana提供日志可视化界面，创建Index Pattern后即可查询和分析日志数据：

# 创建Index Pattern
POST /api/index_patterns/index_pattern
{
  "index_pattern": {
    "title": "docker-logs-*",
    "timeFieldName": "collect_time"
  }
}

在Kibana Discover页面可以通过KQL查询语言筛选日志。常用查询示例：

# 查询ERROR级别日志
level: "ERROR"

# 按容器名筛选
container_name: "nginx-*"

# 组合查询：特定容器的错误日志
container_name: "api-server" AND level: "ERROR"

# 时间范围查询
collect_time >= "now-1h" AND level: "WARN"

日志告警规则与异常检测

使用ElastAlert2实现基于Elasticsearch日志数据的告警功能：

rules:
  - name: container-error-alert
    type: frequency
    index: docker-logs-*
    num_events: 5
    timeframe:
      minutes: 5
    filter:
      - query:
          query_string:
            query: "level: ERROR"
    alert:
      - webhook
    webhook:
      url: "https://hooks.slack.com/services/xxx"
      method: POST
    realert:
      minutes: 30

该规则在5分钟内出现5条以上ERROR级别日志时触发告警，通过Webhook发送到Slack。realert设置为30分钟，避免同一问题反复告警造成通知疲劳。

常见问题诊断与性能优化

日志丢失问题：检查Fluentd buffer配置是否设置了file类型缓冲。查看/var/log/fluentd/buffer目录是否有积压文件。如果buffer队列满，Fluentd会丢弃新日志，调大buffer_queue_limit参数。

Elasticsearch写入延迟：使用_cat/indices?v查看索引的docs.count和store.size。如果单个索引超过20GB，检查ILM rollover是否正常触发。调整refresh_interval到60s可以进一步降低写入压力。

磁盘空间告警：Docker json-file日志驱动没有配置日志轮转时，单个容器的日志文件可能增长到数十GB。在daemon.json中增加max-size和max-file参数：

"log-opts": {
  "max-size": "50m",
  "max-file": "3"
}

该配置限制每个容器最多保留3个50MB的日志文件。在使用Fluentd收集日志后，本地日志文件仅作为短暂缓存，不需要保留过大。

这套Docker日志收集方案覆盖了日志采集、传输、存储、查询和告警全链路，适用于中小规模容器集群的日志管理需求。日均处理日志量在100GB以下时，单节点Fluentd和Elasticsearch即可稳定运行。