从日志到Docker：详解Linux磁盘空间被占用的6大元凶及清理方案

从日志到Docker：详解Linux磁盘空间被占用的6大元凶及清理方案

当你登录服务器准备部署新应用时，终端突然弹出"No space left on device"的红色警告——这种场景对Linux运维人员来说再熟悉不过。磁盘空间如同城市的地下排水系统，平时容易被忽视，一旦出问题却可能引发连锁反应。本文将带您深入挖掘那些吞噬磁盘空间的"隐形杀手"，并提供可立即上手的解决方案。

1. 诊断工具：快速定位磁盘黑洞

在开始清理之前，我们需要一套精准的"探测仪"。df -h无疑是第一把手术刀，它能直观显示各分区的使用情况：

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p2 100G 93G 2.1G 98% /

当根分区使用率达到98%时，就该祭出更精细的分析工具了。ncdu（NCurses Disk Usage）是我最推荐的交互式分析工具，安装和使用都非常简单：

# Debian/Ubuntu系 $ sudo apt install ncdu -y # RHEL/CentOS系 $ sudo yum install ncdu -y # 扫描根目录 $ sudo ncdu /

这个工具的优势在于：

• 可视化界面：树状结构展示目录大小占比
• 交互操作：支持直接删除或跳转到可疑目录
• 快速扫描：比传统du命令效率提升30%以上

对于需要脚本化处理的场景，可以组合使用这些命令：

# 查找大于100MB的文件 $ find / -type f -size +100M -exec ls -lh {} \; # 按修改时间排序 $ find /var/log -type f -exec ls -lt {} + | head -n 10

2. 六大空间杀手及其剿灭方案

2.1 失控的日志文件

/var/log目录是首要检查对象。某次巡检中，我发现一台Nginx服务器的access.log竟然达到了47GB！处理日志问题需要分三步走：

1. 紧急止血：

   # 清空当前日志（确保服务支持日志重载） $ sudo truncate -s 0 /var/log/nginx/access.log # 或者使用更安全的方式 $ sudo > /var/log/nginx/access.log

2. 长期治理： 配置/etc/logrotate.d/nginx示例：

   /var/log/nginx/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }

3. 系统日志管理： 对于systemd系统，定期清理journal日志：

   # 查看日志占用空间 $ journalctl --disk-usage # 保留最近500MB $ sudo journalctl --vacuum-size=500M

2.2 Docker的存储泄漏

Docker就像个贪吃蛇，不知不觉就会吞掉大量空间。某生产环境曾因未清理的镜像导致磁盘爆满，处理这类问题需要多管齐下：

镜像清理：

# 删除所有悬空镜像 $ docker image prune -f # 删除超过30天未使用的镜像 $ docker image prune -a --filter "until=720h"

容器日志管理：

# 查看容器日志大小 $ docker ps -q | xargs docker inspect --format='{{.LogPath}}' | xargs ls -lh # 全局日志驱动配置（/etc/docker/daemon.json） { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

存储驱动优化：

# 查看存储使用情况 $ docker system df # 彻底清理（慎用！） $ docker system prune --all --volumes

2.3 临时文件的僵尸军团

/tmp和/var/tmp目录经常成为"文件坟场"。建议创建定期清理任务：

# 每日凌晨清理/tmp下超过7天的文件 $ sudo vim /etc/cron.daily/tmpclean #!/bin/sh find /tmp -type f -atime +7 -delete

对于关键系统，可以使用tmpfs优化：

# /etc/fstab 添加 tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,size=2G 0 0

2.4 软件包的缓存废墟

不同包管理器的缓存位置：

2.5 幽灵文件：已删除但未释放

当df显示空间不足但du统计却正常时，可能是被删除的文件仍被进程占用：

# 查找被删除但仍被占用的文件 $ sudo lsof +L1 | grep deleted # 输出示例 nginx 1234 www-data 12w REG 253,0 4294967296 0 10485760 /var/log/nginx.log (deleted)

解决方法：

# 优雅重启相关进程 $ sudo systemctl restart nginx # 如果不知道是哪个进程，可以重启服务器（生产环境慎用） $ sudo reboot

2.6 备份文件的野蛮生长

数据库备份脚本是另一个常见陷阱。某MySQL服务器曾因每日全量备份导致磁盘告警，优化方案：

# 改进的备份脚本示例 #!/bin/bash BACKUP_DIR=/backups/mysql DATE=$(date +%Y%m%d) KEEP_DAYS=7 # 压缩备份 mysqldump -u backup -p'password' --all-databases | gzip > $BACKUP_DIR/full_$DATE.sql.gz # 清理旧备份 find $BACKUP_DIR -name "*.gz" -type f -mtime +$KEEP_DAYS -delete

3. 防御性运维：构建空间防护体系

3.1 实时监控方案

配置Prometheus报警规则示例：

groups: - name: disk.rules rules: - alert: DiskSpaceCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint="/"} * 100 / node_filesystem_size_bytes{mountpoint="/"}) > 90 for: 5m labels: severity: critical annotations: summary: "Critical disk space alert on {{ $labels.instance }}" description: "{{ $labels.mountpoint }} on {{ $labels.instance }} has only {{ printf "%.2f" $value }}% free space"

3.2 自动化清理脚本

#!/bin/bash THRESHOLD=90 CURRENT=$(df / --output=pcent | tail -1 | tr -d '% ') if [ "$CURRENT" -ge "$THRESHOLD" ]; then echo "$(date) - Disk space alert: ${CURRENT}%" >> /var/log/disk_cleaner.log # 执行清理操作 docker image prune -a --filter "until=24h" -f journalctl --vacuum-size=200M find /tmp -type f -mtime +3 -delete # 发送通知 echo "清理完成，当前使用率: $(df / --output=pcent | tail -1)" | \ mail -s "磁盘清理报告 $(hostname)" admin@example.com fi

3.3 分区规划最佳实践

推荐的分区方案（针对100GB磁盘）：

4. 高阶技巧：深入文件系统层

当常规方法无效时，可能需要检查文件系统本身：

# 检查inode使用情况（某些场景下inode耗尽会导致类似空间不足的错误） $ df -i # 查找硬链接文件 $ find / -type f -links +3 -exec ls -li {} \; # 检查是否有被隐藏的保留块（通常为5%） $ tune2fs -l /dev/nvme0n1p2 | grep "Reserved block count" # 临时调整保留空间（紧急情况下） $ sudo tune2fs -m 1 /dev/nvme0n1p2

在处理某次Kubernetes节点的磁盘危机时，我发现/var/lib/docker/overlay2占据了异常空间。最终解决方案是：

# 查看各容器实际磁盘占用 $ docker ps -s # 清理无效存储层 $ docker system prune --volumes # 限制Docker日志驱动 $ docker run --log-driver=journald my-image