1. Docker 日志为什么会占满磁盘？
在 Linux 服务器上运行 Docker 容器时，应用程序输出到标准输出和标准错误的内容，通常会由 Docker 日志驱动进行保存。
Docker 常见的日志驱动为 json-file。
如果没有设置日志大小限制和轮转规则，容器运行时间越长，日志文件可能越来越大。
比较常见的日志来源包括：
网站访问日志；
应用程序报错；
数据库连接错误；
接口请求日志；
爬虫任务；
程序异常重试；
定时任务输出。
如果程序出现异常循环，一段时间内就可能产生大量日志。
最终可能造成：
服务器磁盘空间快速下降；
Docker 无法正常写入数据；
数据库写入异常；
网站或应用运行异常；
服务器部分服务无法正常启动。
因此长期运行 Docker 的服务器，建议提前配置日志轮转。
2. 先检查服务器磁盘空间
首先执行：
df -h例如：
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 37G 1.1G 98% /这里可以重点查看：
Size：磁盘总容量；
Used：已经使用的空间；
Avail：剩余可用空间；
Use%：磁盘使用率。
如果系统盘已经达到 90% 以上，就建议尽快排查磁盘占用来源。
还可以执行：
docker system df查看 Docker 当前使用的镜像、容器、Volume 和 Build Cache 大致占用了多少空间。
需要注意：
docker system df 主要用于查看 Docker 整体资源占用，并不能完全替代容器日志排查。
3. 查看当前 Docker 日志驱动
执行：
docker info --format '{{.LoggingDriver}}'如果输出：
json-file说明当前 Docker 默认日志驱动为 json-file。
如果需要查看某个容器实际使用的日志驱动，可以执行：
docker inspect -f '{{.HostConfig.LogConfig.Type}}' 容器名称例如：
docker inspect -f '{{.HostConfig.LogConfig.Type}}' nginx如果输出：
json-file说明这个容器使用的是 json-file 日志方式。
4. 查找 Docker 容器日志文件
可以直接通过 Docker 查询某个容器实际使用的日志文件路径。
执行：
docker inspect --format='{{.LogPath}}' 容器名称例如：
docker inspect --format='{{.LogPath}}' nginx可能输出：
/var/lib/docker/containers/xxxxxxxx/xxxxxxxx-json.log然后查看这个日志文件的大小：
du -h /var/lib/docker/containers/xxxxxxxx/xxxxxxxx-json.log例如：
6.8G /var/lib/docker/containers/xxxxxxxx/xxxxxxxx-json.log如果某个容器日志已经占用了几 GB，甚至几十 GB，就可能是磁盘空间快速减少的主要原因。
Docker 默认数据目录通常位于：
/var/lib/docker
不过如果服务器修改过 Docker 数据目录，实际位置可能不同。
因此更推荐通过 docker inspect 获取真实日志路径，而不是直接猜日志位置。
5. 查看日志到底在输出什么
找到日志较大的容器以后，不建议第一时间直接删除。
先查看最近的日志内容：
docker logs --tail 100 容器名称例如：
docker logs --tail 100 nginx如果需要实时观察：
docker logs -f --tail 100 容器名称退出实时日志：
Ctrl + C
重点观察是否存在大量重复内容。
例如：
数据库连接失败；
接口访问失败；
DNS 解析异常；
连接超时；
程序不断重启；
某个任务持续报错；
API 不断重试。
如果相同错误每秒出现很多次，即使清理日志，后续也可能很快再次增长。
因此最好同时解决程序本身的异常。
6. 不建议直接删除 Docker 日志文件
网上经常能看到直接删除 *-json.log 的做法。
例如：
rm -f *-json.log不建议把这种方式作为长期处理方案。
因为 Docker 正在管理这些日志文件，直接从系统层面删除或者修改，可能导致日志状态和 Docker 当前使用的文件不一致。
更推荐按照以下思路处理：
找到异常容器 → 查看日志内容 → 修复程序异常 → 设置日志轮转 → 重新创建容器。
这样才能真正避免后续日志继续无限增长。
7. Docker Compose 限制单个容器日志大小
如果容器通过 Docker Compose 部署，可以在对应服务中加入 logging 配置。
例如：
services:
app:
image: example/app:latest
restart: unless-stopped
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"这里：
max-size: "10m"
表示单个日志文件达到约 10MB 后进行轮转。
max-file: "3"
表示最多保留 3 个日志文件。
这样日志就不会一直写入同一个越来越大的文件。
修改 Compose 配置以后，可以重新创建容器：
docker compose up -d --force-recreate如果运行的是正式业务，重新创建之前建议先确认应用数据已经使用 Volume 或绑定目录进行持久化。
数据库等重要业务还应该提前做好备份。
8. 修改日志配置后为什么没有生效？
这是比较容易遇到的问题。
Docker 容器的日志配置通常在创建容器时确定。
例如你已经运行了一个旧容器，然后才修改：
compose.yaml
或者：
/etc/docker/daemon.json
原来的容器并不会自动修改日志配置。
因此修改 Docker Compose 配置以后，可以执行：
docker compose up -d --force-recreate让容器按照新的配置重新创建。
创建完成以后，可以执行：
docker inspect -f '{{json .HostConfig.LogConfig}}' 容器名称查看实际日志配置。
如果已经能够看到 max-size、max-file 等参数，说明新的限制已经生效。
9. 给整台服务器设置 Docker 日志限制
如果服务器长期运行多个 Docker 项目，也可以为 Docker 设置全局默认日志限制。
编辑：
nano /etc/docker/daemon.json加入：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}这里建议特别注意：
如果 /etc/docker/daemon.json 原来已经存在其他配置，不要直接把原来的内容全部覆盖掉。
应该将日志配置和已有配置正确合并。
修改完成以后，可以检查 JSON 格式：
python3 -m json.tool /etc/docker/daemon.json如果没有报错，再重新启动 Docker：
systemctl restart docker然后查看 Docker 状态：
systemctl status docker确认 Docker 正常运行。
10. 全局设置修改后旧容器仍然不会自动变化
修改 Docker 全局日志配置以后，需要注意一个问题：
已经创建完成的旧容器，通常仍然保持原来的日志配置。
新的默认配置主要用于之后创建的容器。
因此如果希望已有 Docker Compose 项目也使用新的日志限制，可以进入对应项目目录：
docker compose up -d --force-recreate重新创建以后，再通过：
docker inspect -f '{{json .HostConfig.LogConfig}}' 容器名称确认日志配置。
11. Compose 单独设置和全局设置怎么选？
如果服务器上运行很多 Docker 项目，希望以后创建的新容器默认都有日志限制，可以使用：
/etc/docker/daemon.json
进行全局配置。
如果某个项目日志比较特殊，需要单独设置，则可以在：
compose.yaml
中为对应服务添加：
logging
例如普通应用可以设置：
max-size 为 10m
max-file 为 3
而日志比较重要或者产生量较大的业务，可以根据实际需求调整。
不建议所有业务机械地使用同一个日志大小。
12. 使用 local 日志驱动
除了 json-file，Docker 还支持其他日志驱动。
例如可以设置：
{
"log-driver": "local"
}local 日志驱动本身具有日志轮转机制，也比较适合希望控制日志磁盘占用的场景。
不过如果服务器已经长期使用 json-file，为了减少修改范围，也可以继续使用 json-file，然后增加：
max-size
和：
max-file
限制即可。
13. 磁盘占满不一定都是 Docker 日志
如果检查以后发现 Docker 日志并不大，还应该继续排查其他 Docker 数据。
执行：
docker system df可以查看：
Images；
Containers；
Local Volumes；
Build Cache。
还可以执行：
du -sh /var/lib/docker/*查看 Docker 数据目录不同部分的大致占用。
常见占用来源还包括：
大量旧镜像；
停止的容器；
Docker Build Cache；
Docker Volume；
数据库文件；
应用上传文件；
容器内部缓存；
程序临时文件。
特别需要注意 Docker Volume。
Volume 中可能保存：
MySQL 数据；
PostgreSQL 数据；
网站文件；
用户上传内容；
应用配置；
其他持久化业务数据。
因此不要在没有确认用途之前直接删除 Volume。
14. 不要看到磁盘满就直接执行 prune
一些 Docker 清理命令具有删除作用。
如果不了解当前服务器上的 Docker 项目，不建议为了释放空间直接执行大范围清理。
尤其不要在没有确认的情况下删除：
Volume；
正在使用的镜像；
业务数据；
数据库数据目录。
正确做法应该是先执行：
docker system df了解空间主要消耗在哪里，再决定具体处理哪个项目。
15. 推荐的日志限制配置
对于普通个人 Docker 服务器，可以参考：
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}这种配置适合大多数日志量不大的应用作为基础限制。
但这并不是固定标准。
例如：
Web 应用；
数据库；
API；
游戏服务；
高频任务；
不同业务每天产生的日志量可能差异很大。
应该根据业务实际情况调整。
16. Docker 日志快速排查顺序
遇到 Docker 日志或者磁盘空间异常，可以按照下面顺序排查：
检查磁盘空间
↓
确认 Docker 日志驱动
↓
找到具体容器日志路径
↓
检查日志文件大小
↓
查看日志内容
↓
确认是否存在程序异常
↓
配置日志大小限制
↓
重新创建容器
↓
再次检查日志配置
这样比单纯删除日志文件更加稳妥。
17. 如何避免日志再次写满磁盘？
服务器长期运行 Docker 项目时，建议做好以下几点。
第一，新服务器安装 Docker 后，可以提前设置合理的日志轮转。
第二，对于日志量特别大的 Compose 项目，可以单独设置 logging。
第三，定期查看服务器磁盘使用情况。
可以执行：
df -h如果服务器平时磁盘使用率只有 40%，短时间突然增长到 80% 或 90%，建议及时检查。
第四，如果发现某个应用持续大量输出相同错误，应优先修复程序本身。
日志限制只是防止磁盘被无限写满，并不能解决应用程序异常。
18. 磁盘已经接近 100% 怎么办？
如果磁盘使用率已经非常高，不建议继续进行大量写入操作。
可以先执行：
df -h确认具体哪个分区已经接近满。
再查看 Docker：
docker system df定位某个容器日志：
docker inspect --format='{{.LogPath}}' 容器名称检查大小：
du -h 日志文件路径确认真正占用空间的内容以后，再针对具体业务进行处理。
如果磁盘已经完全没有剩余空间，部分应用、数据库甚至 Docker 本身都可能出现异常，因此建议尽早处理。
19. 服务器配置建议
Docker 本身不需要特别高的服务器配置，真正决定 CPU、内存和磁盘需求的是运行在 Docker 中的应用。
如果只是运行几个轻量级 Docker 项目，普通 Linux 云服务器通常就可以使用。
如果同时运行：
网站；
MySQL；
Redis；
监控系统；
Docker 管理面板；
多个自托管项目；
则需要根据实际业务增加 CPU、内存和磁盘空间。
如果需要搭建 Docker 项目，也可以使用莱卡云 Linux 云服务器。
查看官网购买链接： https://www.lcayun.com
如果服务器还没有安装 Docker，可以参考：
安装教程： 服务器上安装docker和docker-compose教程
20. 总结
Docker 容器日志占满磁盘，比较常见的原因是容器长期使用 json-file 日志方式，但没有配置日志大小限制和轮转。
首先可以通过：
docker info --format '{{.LoggingDriver}}'确认日志驱动。
然后通过：
docker inspect --format='{{.LogPath}}' 容器名称找到实际日志文件。
检查日志大小以后，还应该通过：
docker logs --tail 100 容器名称确认应用是否存在异常刷日志。
对于 Docker Compose 项目，可以通过 logging 配置 max-size 和 max-file。
如果希望整台服务器上的新容器默认启用日志限制，也可以配置：
/etc/docker/daemon.json
需要特别注意的是：
修改 Docker 全局日志配置以后，已经存在的旧容器通常不会自动使用新的配置。
因此还需要根据实际项目重新创建对应容器。
通过合理设置日志轮转、定期检查磁盘空间，并及时处理程序异常，可以有效避免 Docker 日志再次占满服务器磁盘。
