本文介绍在 aws ec2 上通过 docker 部署 go 应用时，安全、可维护地采集和访问日志的两种主流方案：文件挂载与标准输出+系统日志驱动，并推荐符合云原生最佳实践的 stdout 方式。
本文介绍在 aws ec2 上通过 docker 部署 go 应用时，安全、可维护地采集和访问日志的两种主流方案：文件挂载与标准输出+系统日志驱动，并推荐符合云原生最佳实践的 stdout 方式。
在 AWS EC2 实例中运行 Go 应用的 Docker 容器时，日志管理不应依赖容器内持久化文件（如 /var/log/app.log），因其易丢失、难收集、不便于集中分析。以下是两种经过生产验证的可靠方案：
✅ 推荐方案：日志输出至 stdout + syslog 驱动（云原生首选）
Go 应用应直接将结构化日志写入 os.Stdout 和 os.Stderr（例如使用 log 或 zap 库），而非自行管理文件。启动容器时启用 syslog 日志驱动，即可将所有日志自动转发至宿主机的系统日志服务：
docker run \
--log-driver=syslog \
--log-opt syslog-address=unix:///dev/log \
--log-opt tag="{{.ImageName}}/{{.Name}}" \
your-go-app-image日志将统一落盘至 EC2 实例的 /var/log/messages（或 /var/log/syslog，取决于发行版），并可通过 journalctl -t "your-go-app-image/..." 实时查看。此方式天然兼容 AWS CloudWatch Logs：只需在 EC2 上配置 cloudwatch-agent，即可将 /var/log/messages 中匹配标签的日志自动推送至 CloudWatch，实现集中存储、检索、告警与长期保留。
⚠️ 备选方案：Docker 卷挂载（仅限临时调试）
若需快速验证日志内容，可将容器内日志路径挂载为宿主机文件：
docker run -v /home/ec2-user/logs/app.log:/var/log/app.log:rw your-go-app-image
但该方式存在明显缺陷：多容器实例无法共享同一文件、权限冲突风险高、无法自动轮转、且违背容器“无状态”设计原则，不建议用于生产环境。
? 关键注意事项
- Go 应用代码中避免使用
os.OpenFile(..., os.O_CREATE|os.O_APPEND|os.O_WRONLY)直接写文件；改用log.SetOutput(os.Stdout)统一输出； - 若使用
zap等高性能日志库，请配置zapcore.Lock(zapcore.AddSync(os.Stdout))确保并发安全； - 在 EC2 上启用
rsyslog或systemd-journald并配置日志轮转（如logrotate），防止磁盘占满； - 生产环境务必结合 CloudWatch Logs 或第三方 SIEM（如 Datadog、Splunk）构建可观测性闭环。
综上，拥抱 stdout + 日志驱动是 AWS 容器日志管理的正确姿势——轻量、标准、可扩展，让日志真正成为可观测性的第一手数据源。
