Docker容器日志管理最佳实践
容器日志管理是运维中容易忽视但非常重要的环节。日志不管理会导致磁盘被撑满（容器宕机）、排查问题困难（日志丢失）、安全审计缺失。本文分享Docker容器日志管理的最佳实践。
在讨论「Docker容器日志管理最佳实践」时，真正决定成败的往往不是某个单点配置，而是把容器与 Kubernetes 编排放进整体架构之后的一致性设计。资源规格、网络边界、弹性策略与故障域需要放在一起权衡，任何一环脱节，都会在流量高峰或故障切换时被成倍放大。
日志驱动
Docker支持多种日志驱动（logging driver）：json-file（默认，写入JSON文件）、syslog（发送到syslog）、journald（写入systemd journal）、fluentd（发送到Fluentd）、awslogs（发送到CloudWatch）。
生产环境建议不要使用默认的json-file（日志文件会无限增长），而是使用专门的日志收集方案。
日志轮转
如果使用json-file驱动，务必配置日志轮转："log-driver": "json-file", "log-opts": {"max-size": "100m", "max-file": "3"}。这样每个容器的日志最多占用300MB磁盘空间。可以在Docker daemon.json中全局配置。
K8s容器日志
在Kubernetes中，容器标准输出（stdout/stderr）会被K8s自动收集到节点上的日志文件中。推荐使用DaemonSet方式部署日志采集Agent（如Logtail、Filebeat），自动采集所有Pod的日志。
应用日志建议输出到标准输出而非文件，这样K8s的日志采集机制可以自动处理。如果必须写文件，使用emptyDir Volume挂载日志目录，配合Sidecar容器采集。
日志格式规范
统一使用JSON格式输出日志，包含以下字段：timestamp（ISO8601格式）、level（DEBUG/INFO/WARN/ERROR）、service（服务名）、traceId（链路追踪ID）、message（日志内容）。JSON格式便于日志系统解析和检索。
日志级别管理
生产环境使用INFO级别，排查问题时动态调整为DEBUG（通过环境变量或配置中心）。ERROR级别日志应该同时触发告警。避免在循环中打印大量日志（会导致磁盘IO瓶颈）。
把容器与 Kubernetes 编排放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估容器与 Kubernetes 编排时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，容器与 Kubernetes 编排才算真正「落地」，而不是停留在方案文档里。