日志采集与监控建议
约 740 字大约 2 分钟
Docker日志监控运维
2026-03-20
1. 先统一日志出口
Docker 环境里最怕每个容器各写各的日志，最后排查问题时入口完全不统一。
最基础的做法是先统一两件事：
- 应用日志优先输出到标准输出和标准错误。
- 再由 Docker 或外部日志系统统一收集。
这样至少可以先通过下面的命令快速查看问题：
docker logs container_name2. 控制默认容器日志体积
如果长期不限制 Docker 默认日志，单机磁盘很容易被 json 日志文件打满。
可以在 /etc/docker/daemon.json 里增加日志轮转配置：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}改完后重启 Docker 服务生效：
sudo systemctl restart docker如果你不希望所有容器共用同一套策略，也可以在 Compose 里按服务单独配置：
services:
app:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"3. 监控最少要有哪几类
即使不引入完整监控平台，至少也建议关注以下指标：
- 容器存活状态。
- CPU 和内存使用情况。
- 磁盘空间和日志占用。
- 关键端口或 HTTP 健康检查。
- 关键业务失败率或错误日志数量。
如果后面要生产化，再接 Prometheus、Grafana、Loki、ELK 等方案都可以，但最开始先把最小可见性建立起来更重要。
4. 日志排查的实用顺序
实际排查问题时，可以按这个顺序走：
docker ps -a看容器是否退出、重启或异常。docker logs看启动报错和最近异常。docker inspect看挂载、环境变量、网络和启动命令是否符合预期。docker exec -it进入容器内部核对配置和运行状态。- 再回到宿主机检查磁盘、权限、端口占用和反向代理转发。
如果问题最终指向容器间访问失败或端口未暴露，再继续参考 3.容器网络与端口映射。
5. 如果准备进一步生产化
当服务数量增加后，建议逐步补下面这些能力：
- 集中式日志采集和检索。
- 告警通知，例如容器退出、磁盘满、接口异常。
- 结构化日志，方便按请求链路和错误类型查询。
- 健康检查和自动拉起机制。
- 关键业务指标看板，而不只是机器指标。
6. 一个实用习惯
不管监控体系是否完善，都建议给每个服务保留一份最基本的排障信息：
- 容器名称。
- 镜像版本。
- 挂载目录。
- 暴露端口。
- 日志查看命令。
- 重启命令。
这样在故障发生时，排查入口会清晰很多。