Docker容器日志收集与管理的最佳实践

Docker 日志 管理
Docker
文章字数:   2.1k
阅读时长:   8 分

哈喽，大家好！今天我们来聊一个在Docker世界里非常重要但又常常被忽视的话d题——日志管理。在微服务和容器化的浪潮下，我们的应用被拆分成一个个独立的容器来运行。这带来了前所未有的灵活性，但也让日志的收集和管理变得复杂起来。

想象一下，几十上百个容器在跑，出了问题要去一个个docker logs捞日志，那简直是场灾难！所以，一个清晰、高效的日志管理策略是保证系统稳定性的关键。

这篇文章会用最口语化的方式，带你了解Docker日志收集的几种主流方案，并提供可以直接上手的代码案例和最佳实践。

为什么不能简单地docker logs？

首先，我们要明白为什么不能仅仅依赖docker logs命令。

根据十二要素应用（The Twelve-Factor App）的理念，现代应用应该将日志视为事件流，并将其输出到标准输出（stdout）和标准错误（stderr）。Docker默认会捕获这些输出流，所以我们可以通过docker logs命令查看到它们。

但这有几个问题：

  1. 生命周期问题：容器是“短暂”的，它们随时可能被销毁和重建。一旦容器被删除，存储在其中的日志文件也会随之消失。
  2. 日志分散：日志分散在各个宿主机上，无法进行集中的查询和分析。
  3. 性能和磁盘问题：默认的json-file日志驱动会将日志以JSON格式存储在宿主机上（通常是/var/lib/docker/containers/<容器ID>/<容器ID>-json.log）。如果不加以控制，日志文件会无限增长，最终占满你的磁盘空间。

因此，我们需要更强大的方案来集中管理这些日志。

方案一：使用Docker日志驱动（Logging Drivers）

这是最直接也是最简单的方式。Docker提供了一套日志驱动机制，允许我们将容器的日志流直接发送到不同的目的地，比如集中的日志系统。

Docker内置了多种日志驱动，如json-file、local、syslog、fluentd、gelf等。

1. 最佳本地实践：json-file驱动与日志轮转

对于开发环境或者小规模应用，默认的json-file驱动其实是个不错的选择，但前提是你必须配置日志轮转（Log Rotation）来防止磁盘爆炸。

你可以在Docker的全局配置文件/etc/docker/daemon.json中进行设置，这样所有新创建的容器都会生效。

案例代码：配置全局日志轮转

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

解析：

  • "log-driver": "json-file": 指定使用json-file驱动。
  • "max-size": "10m": 设置每个日志文件的最大体积为10MB。
  • "max-file": "3": 最多保留3个日志文件。当日志达到10MB后，Docker会自动创建一个新的，当文件数超过3个时，最旧的那个会被删除。

修改完配置后，需要重启Docker服务才能生效。

sudo systemctl daemon-reload
sudo systemctl restart docker

注意：这个配置只对新创建的容器有效，已经存在的容器需要重建才能应用新的配置。

你也可以在启动单个容器时，单独为它指定日志配置：

docker run -d --name my-app \
  --log-driver json-file \
  --log-opt max-size=5m \
  --log-opt max-file=2 \
  nginx

2. 集中日志管理：fluentd驱动与ELK技术栈

在生产环境中，我们通常会将日志发送到统一的日志中心，比如强大的ELK（Elasticsearch, Logstash, Kibana）或EFK（Elasticsearch, Fluentd, Kibana）技术栈。这里我们以fluentd为例，展示如何将Docker日志发送到ELK。

架构简介：
容器通过fluentd日志驱动，将日志发送到一个作为日志聚合器的Fluentd容器。然后，Fluentd容器对日志进行处理，并最终转发给Elasticsearch进行存储和索引。最后，我们通过Kibana进行可视化查询和分析。

案例代码：使用docker-compose搭建EFK日志系统

首先，我们需要为Fluentd创建一个配置文件fluentd/conf/fluent.conf：

# 监听从Docker日志驱动发来的数据
<source>
  @type forward
  port 24224
  bind 0.0.0.0
</source>

# 将所有匹配的日志转发到Elasticsearch
<match *.**>
  @type elasticsearch
  host elasticsearch
  port 9200
  logstash_format true
  logstash_prefix docker_logs
  # 你可以在这里添加更多处理规则，比如解析JSON日志
</match>

接下来，创建docker-compose.yml文件：

version: '3.7'

services:
  # 我们的业务应用
  my-app:
    image: alpine
    command: sh -c "while true; do echo '`date` Hello from my-app' && sleep 5; done"
    logging:
      driver: "fluentd"
      options:
        fluentd-address: "localhost:24224"
        tag: "docker.my-app.{{.ID}}"
    depends_on:
      - fluentd

  # Fluentd 日志聚合器
  fluentd:
    build: ./fluentd # 或者使用官方镜像 image: fluent/fluentd-elasticsearch
    volumes:
      - ./fluentd/conf:/fluentd/etc
    ports:
      - "24224:24224"
      - "24224:24224/udp"
    depends_on:
      - elasticsearch

  # Elasticsearch 存储和索引
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
    environment:
      - "discovery.type=single-node"
    ports:
      - "9200:9200"
    volumes:
      - esdata:/usr/share/elasticsearch/data

  # Kibana 可视化界面
  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.0
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

volumes:
  esdata:

最后，在fluentd目录下创建一个简单的Dockerfile，用于安装Elasticsearch插件：

FROM fluent/fluentd:v1.14-1
USER root
RUN gem install fluent-plugin-elasticsearch --no-document
USER fluent

现在，在docker-compose.yml所在目录运行docker-compose up，你的集中式日志系统就跑起来了！你可以访问http://localhost:5601打开Kibana，创建索引模式docker_logs-*，然后就能看到来自my-app容器的日志了。

方案二：Sidecar（边车）模式

日志驱动方案非常方便，但它也有局限性。它主要处理的是标准输出流。如果你的应用程序是将日志写到容器内的某个文件里，日志驱动就无能为力了。

这时候，Sidecar模式就派上用场了。

这个模式的核心思想是：在你的应用容器旁边，再跑一个“边车”容器。这两个容器共享一个存储卷。应用容器将日志写入这个共享卷的文件中，而Sidecar容器则负责读取这个文件，然后把它发送到集中的日志服务器。

案例代码：使用docker-compose实现Sidecar日志收集

version: '3.7'

services:
  # 业务应用，将日志写入文件
  app:
    image: busybox
    command: sh -c 'i=0; while true; do echo "Log entry $$i" >> /var/log/app.log; i=$$(i+1); sleep 2; done'
    volumes:
      - app-logs:/var/log

  # Sidecar容器，读取日志文件并输出到标准输出
  # 在实际场景中，这里会是一个filebeat或fluentd容器，将日志发往远程
  sidecar:
    image: busybox
    command: tail -f /var/log/app.log
    volumes:
      - app-logs:/var/log

volumes:
  app-logs:

解析：

  1. 我们定义了一个名为app-logs的存储卷。
  2. app服务和sidecar服务都挂载了这个存储卷。
  3. app服务不断地向/var/log/app.log追加日志。
  4. sidecar服务通过tail -f命令持续读取这个文件，并将其内容输出到自己的标准输出。

在真实场景中，sidecar容器会运行一个日志收集代理（如Filebeat、Fluent Bit），配置它监控共享卷中的日志文件，并将其转发到Elasticsearch、Loki或其他日志后端。

总结：最佳实践建议

说了这么多，我们来总结一下最佳实践：

  1. 首选标准输出：尽可能让你的应用程序将日志输出到stdout和stderr。这是云原生的标准做法，也让日志管理更简单。
  2. 为本地环境配置日志轮转：即使在开发环境，也要为json-file驱动配置max-size和max-file，避免磁盘被塞满。
  3. 生产环境使用日志驱动转发：对于将日志输出到标准流的应用，直接使用fluentd、gelf等日志驱动将日志转发到中心化的日志平台，这是最高效的方式。
  4. 用Sidecar模式处理文件日志：如果你的应用（特别是老旧应用）只能将日志写入文件，那么Sidecar模式是你的不二之选。
  5. 采用结构化日志：尽量输出JSON或其他结构化格式的日志，而不是纯文本。结构化日志能让后续的查询、分析和告警变得极其方便。

希望这篇文章能帮助你更好地理解和实践Docker容器的日志管理。告别“日志灾难”，从现在开始！

Docker 日志 管理
  目录