📚 课程目录第3章容器日志基础

3、容器日志基础：掌握Docker和Kubernetes中日志的基本概念、标准输出与文件日志的区别、日志驱动（json-file、journald、syslog等）

在边缘推理场景中，容器日志是排查模型服务异常、分析推理延迟、追踪数据流问题的第一手资料。与传统的虚拟机或物理机日志不同，容器日志的生命周期与容器实例强绑定，且采集路径、存储格式、转发方式都受到容器运行时和编排系统的深刻影响。本章将系统梳理Docker与Kubernetes中的日志基本概念，厘清标准输出与文件日志的本质区别，并深入解析json-file、journald、syslog等主流日志驱动的工作原理与选型依据，为后续搭建日志采集管道打下坚实基础。

3.1 容器日志的核心原理与生命周期

容器日志的本质是进程输出与文件持久化的组合。在Docker或Kubernetes环境中，一个容器内运行的业务进程（如Python推理服务、TensorFlow Serving、Nginx等）会产生两类日志：一类是直接写入标准输出（stdout）和标准错误（stderr）的流式日志；另一类是应用主动写入容器文件系统内特定路径的日志文件。容器运行时（Docker Engine、containerd）负责捕获前者，并通过配置的日志驱动将其转发到宿主机或外部系统；后者则完全由应用自身管理，与容器运行时的日志机制无关。

理解容器日志的生命周期至关重要。当容器启动时，运行时会在宿主机上创建独立的日志存储空间；当容器停止或被删除时，默认情况下其标准输出日志也会随之消失（除非配置了持久化存储）。这意味着在边缘推理场景中，如果节点因断电、资源耗尽等原因重启，未及时采集的容器日志将永久丢失。因此，日志采集必须与容器生命周期解耦，通常采用边采集边转发或宿主机文件落盘的策略。

  关键认知：容器日志不是“文件”，而是“流”。Docker将stdout/stderr重定向到日志驱动，Kubernetes则通过kubelet在Pod级别统一管理。任何绕过stdout的日志（如直接写文件）都不会被docker logs或kubectl logs捕获，必须单独处理。

3.2 标准输出日志与文件日志的对比与选型

标准输出日志与文件日志是两种截然不同的日志产生方式，它们在采集难度、可靠性、适用场景上差异显著。下表从多个维度进行对比：

对比维度	标准输出（stdout/stderr）	文件日志（File Log）
产生方式	进程直接输出到控制台	应用通过日志库写入文件
采集方式	容器运行时自动捕获，docker logs/kubectl logs直接可读	需挂载Volume或使用Sidecar容器读取文件
持久性	容器删除后默认丢失（除非配置持久化驱动）	文件可持久化到宿主机或网络存储
结构化程度	纯文本流，需自行解析	可由应用控制格式（JSON、Key-Value等）
性能开销	低，内核级重定向	中，涉及文件I/O和磁盘写入
适用场景	轻量级服务、快速排障、标准格式日志	复杂应用、需要保留原始文件、多文件分离

在边缘推理场景中，推荐优先使用标准输出。原因有三：其一，边缘节点资源有限，标准输出无需额外文件I/O；其二，Kubernetes原生支持kubectl logs实时查看，便于远程排障；其三，日志采集器（如Filebeat、Fluent Bit）对stdout的采集配置最简单。但若推理框架（如TensorFlow Serving）默认将访问日志写入文件，则需通过配置修改为输出到stdout，或采用文件日志采集方案。

经验建议：在开发容器镜像时，应通过软链接或环境变量将应用日志重定向到stdout。例如：ln -sf /dev/stdout /var/log/nginx/access.log，这样既保留了文件日志的格式，又利用了标准输出的采集便利性。

3.3 主流日志驱动深度解析

Docker支持多种日志驱动，每种驱动决定了日志的存储位置、格式和转发方式。Kubernetes本身不直接配置日志驱动，而是依赖容器运行时的默认设置。以下是三种最常用的驱动：

3.3.1 json-file（默认驱动）

json-file是Docker的默认日志驱动。它将每个容器的stdout/stderr写入宿主机上的JSON文件，路径为/var/lib/docker/containers/<container_id>/<container_id>-json.log。每条日志记录包含log（原始内容）、stream（stdout或stderr）、time（RFC3339格式时间戳）三个字段。该驱动支持max-size和max-file参数进行日志轮转，防止磁盘被写满。

# 查看容器日志文件内容示例
{"log":"2025-05-20 10:15:30,123 INFO model_server - Inference request received\n","stream":"stdout","time":"2025-05-20T10:15:30.123456789Z"}
{"log":"2025-05-20 10:15:30,456 INFO model_server - Inference completed in 45ms\n","stream":"stdout","time":"2025-05-20T10:15:30.456789012Z"}

json-file的优点是简单可靠，与docker logs命令天然兼容；缺点是日志文件占用宿主机磁盘，且JSON格式存在一定的空间冗余。在边缘节点上，建议配置日志轮转：

# daemon.json 配置示例
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "OS_ENV"
  }
}

3.3.2 journald

journald驱动将容器日志发送到systemd-journald服务。日志以二进制格式存储在/var/log/journal/目录下，通过journalctl命令查询。该驱动的优势是与系统日志统一管理，支持索引、过滤和结构化字段；劣势是日志格式非纯文本，且依赖systemd环境，在非systemd的容器宿主机上无法使用。在Kubernetes节点上，journald驱动常用于将容器日志与节点系统日志合并采集。

# 查看某个容器的journald日志
journalctl CONTAINER_ID=abc123def456 --since "10 minutes ago"
# 按容器名称过滤
journalctl CONTAINER_NAME=my-inference-server -f

3.3.3 syslog

syslog驱动将容器日志转发到指定的syslog服务器（本地或远程）。它支持RFC 3164和RFC 5424两种协议格式。该驱动适合已有集中式syslog基础设施的企业环境，但存在UDP传输丢包风险，且不支持多行日志的完整保留。在边缘推理场景中，若网络不稳定，不建议使用syslog作为主要采集方式，可考虑使用fluentd或logstash驱动进行可靠转发。

驱动名称	存储位置	查询方式	可靠性	推荐场景
json-file	宿主机文件	docker logs / 文件读取	高（本地落盘）	单机Docker、K8s默认
journald	systemd journal	journalctl	高（二进制日志）	与系统日志统一管理
syslog	远程syslog服务器	syslog工具	中（UDP可能丢包）	已有syslog基础设施
fluentd	外部存储（ES、S3等）	fluentd插件	高（支持重试）	复杂路由、多目的地

3.4 Kubernetes中的日志采集架构与实战案例

Kubernetes本身不提供日志采集组件，但定义了三种日志采集模式：节点级日志代理（DaemonSet）、Sidecar容器、应用内推送。在边缘推理场景中，最常用的是节点级日志代理模式，即每个节点部署一个Fluent Bit或Filebeat DaemonSet，采集所有容器的stdout日志和指定文件日志。

实战案例：边缘节点推理服务日志采集

背景与约束：某智慧工厂部署了20个边缘节点，每个节点运行一个YOLOv5推理容器（输出检测日志到stdout）和一个模型更新容器（将更新日志写入/var/log/model-updater.log）。节点资源受限（2核4GB），网络带宽有限，要求日志不能丢失且不能占用过多磁盘。

初始现象与目标：初期使用json-file默认驱动，未配置轮转，导致运行3天后磁盘占用达85%。同时，模型更新日志无法通过kubectl logs查看，排障困难。目标：统一采集两类日志，配置轮转，并实现日志的远程集中存储。

关键参数与配置：

# 1. 修改Docker daemon.json，配置日志轮转
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "5m",
    "max-file": "3"
  }
}

# 2. 部署Fluent Bit DaemonSet（简化配置）
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:2.1
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: dockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: model-log
          mountPath: /var/log/model-updater.log
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: dockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: model-log
        hostPath:
          path: /var/log/model-updater.log

分析判断过程：首先，通过df -h确认磁盘占用，发现/var/lib/docker/containers目录下单个容器日志文件已达2GB。其次，检查模型更新容器，确认其日志写入文件而非stdout。最后，决定采用Fluent Bit同时采集两类日志：stdout日志通过tail插件读取json-file文件；文件日志通过tail插件直接读取宿主机上的/var/log/model-updater.log。

实际操作步骤：① 修改daemon.json并重启Docker；② 删除旧的大日志文件（或等待轮转生效）；③ 部署Fluent Bit DaemonSet，配置两个input（tail）和两个output（转发到中心Elasticsearch）；④ 验证日志到达中心服务器。

结果对比：配置轮转后，单容器日志文件最大5MB，保留3个文件，磁盘占用稳定在20%以下。模型更新日志通过Fluent Bit采集后，可在Kibana中统一查询。排障效率提升约60%。

风险与代价：Fluent Bit本身占用约50MB内存，在2GB内存的节点上需注意资源预留。另外，日志转发依赖网络，若中心服务器不可达，Fluent Bit会缓存日志到磁盘（默认/var/log/flb-storage/），需确保该目录有足够空间。

重要提醒：在边缘节点上，切勿将日志直接写入容器可写层（即不挂载Volume直接写文件）。容器删除后日志即丢失，且可写层大小有限。务必使用hostPath或emptyDir挂载，并配合日志采集器及时转发。

3.5 常见误区与总结复盘

在容器日志实践中，以下误区需要特别警惕：

误区一：认为docker logs能查看所有日志。实际上，docker logs只能查看被日志驱动捕获的stdout/stderr日志，应用直接写入文件的日志无法通过该命令查看。
误区二：忽略日志轮转配置。默认json-file驱动不限制日志文件大小，长时间运行会导致磁盘写满，引发节点异常。必须配置max-size和max-file。
误区三：在容器内运行日志采集进程。容器内进程生命周期与主进程绑定，主进程退出后采集进程也会终止，且采集进程会消耗容器资源。应在宿主机或Sidecar中采集。
误区四：所有日志都走标准输出。对于需要长期保留、格式复杂或涉及多文件的日志，标准输出并不合适，应设计文件日志+Sidecar采集的方案。