Docker non-blocking 日志出现缺口：检查缓冲与投递速度

应用继续响应，集中日志里却少了一段记录。如果容器使用 non-blocking 日志模式，先检查日志生成速度是否超过驱动的投递速度，以及中间缓冲是否可能已经满了。缓冲满时，新消息不会进入队列；应用继续运行并不表示所有日志已经送达。

这里处理标准输出、标准错误已交给日志驱动之后的投递问题。若应用把内容写入 nohup.out 等文件，先核对文件日志与 Docker 标准流采集，不要直接归为缓冲溢出。

查看这个容器的配置

用容器 ID 或实际名称替换 myapp，以下命令只读取配置：

docker version
docker inspect --format '{{json .HostConfig.LogConfig}}' myapp

检查驱动 Type，以及选项中的 mode、max-buffer-size。不要只看 daemon 新配置：正在运行的容器保留创建时的日志设置。配置也可能包含后端地址或认证参数，分享前脱敏。

普通 Docker 当前默认投递模式是 blocking；显式采用 non-blocking 时，中间缓冲的默认 max-buffer-size 是 1m，即文档所指的一百万字节。这个缓冲按容器设置，不能把它当作整个日志后端的持久存储。

Amazon ECS 的默认值不同。自 2025 年 6 月 25 日起，未显式配置相应覆盖项的 ECS 默认日志模式改为 non-blocking，当前该模式的默认缓冲为 10m。排查 ECS 时应查看任务定义的 logConfiguration 和适用的账户设置，不能直接套用普通 Docker 的默认值。

扩大缓冲只能承接短时积压

日志产生后需要驱动消费。网络延迟、后端限流或不可用，可能让投递速度下降；日志突发又会同时增加输入。更大的缓冲能承接一部分短时积压，但持续输入高于消费能力时，它仍会满。

不要根据平均日志量单独选容量。应结合单容器的峰值输出、后端延迟、最长可接受中断与内存预算评估。后端实际收到的字节量只描述已到达的数据，无法证明应用原本输出了多少。

max-size、max-file 控制某些日志驱动的落盘轮转，与 max-buffer-size 的内存队列不是同一个设置。增加保留文件数不能找回已经未入队的消息，也不能解决驱动一直追不上输入的问题。

切成 blocking 也要评估业务影响

blocking 会把投递背压传回应用的标准流写入。写日志调用可能等待更久，影响响应、健康检查或任务执行；不能把切换模式写成没有代价的“保证日志完整”。日志后端自身的存储和故障边界仍要考虑。

决定模式前，明确业务对可用性与日志缺失的容忍度。必须完整保存的审计事件，应有符合要求的持久交付和确认流程，不能只靠容器的临时内存队列承诺不丢。

修改模式或容量前保存容器创建配置、当前日志和旧版本部署资料。普通 Docker 的这类创建参数需要在重建后的容器上核对，单纯重启旧容器不会自动采用新的 daemon 默认值。重建会影响连接，应安排维护窗口，保留旧配置以便回退。

用可识别事件检查交付链

在隔离环境用带连续编号的测试事件比对实际发出与后端收到的记录，覆盖正常负载及可控的投递延迟，观察应用响应和内存变化。不在生产故意切断日志后端制造缺口，也不把一次正常到达当作所有负载下的容量保证。

线上已有缺口时，保存缺失时间段、容器 ID、配置和后端错误记录，继续核对是否还有应用文件、独立持久采集或其他已保存副本。增大缓冲只影响后续投递；已经从该缓冲路径丢失的消息，不会因调整参数自动恢复。