Linux服务器磁盘爆满急救指南：从Docker垃圾、日志文件到apt缓存的全链路清理实操
当服务器监控突然告警磁盘空间不足时，那种头皮发麻的感觉每个运维都深有体会。上周深夜，我们的订单处理集群突然集体报警，根目录使用率飙升至98%，眼看就要引发线上事故。经过这次惊险的救援，我总结出一套分阶段、分风险等级的清理方法论，不仅能快速释放空间，更能建立长效预防机制。
1. 安全区：无风险基础清理
面对磁盘爆满，首先要做的是安全释放基础空间。这部分操作不会影响任何正在运行的服务，适合作为紧急救援的第一步。
1.1 清理APT软件包缓存
Ubuntu/Debian系统的包管理器会保留所有下载过的deb包，这些缓存可能占用数GB空间：
# 清理过时的软件包缓存 sudo apt-get autoclean # 彻底清空所有软件包缓存 sudo apt-get clean # 删除自动安装且不再需要的依赖包 sudo apt-get autoremove --purge这三个命令的组合通常可以释放2-5GB空间。我在某台长期运行的Jenkins服务器上，曾通过这个组合一次性清理出7.3GB空间。
1.2 清理旧内核镜像
系统升级后会保留旧内核作为回退选项，这些镜像文件往往位于/boot分区：
# 查看已安装的内核版本 dpkg --list | grep linux-image # 删除特定版本内核（保留当前和上一个版本） sudo apt-get purge linux-image-5.4.0-XX-generic注意：务必确保至少保留两个可用内核版本，防止系统更新后无法启动
2. 重点嫌疑区：精准定位大文件
当基础清理仍不足时，需要精准定位磁盘占用元凶。传统du命令效率低下，推荐使用交互式工具ncdu：
2.1 安装与使用ncdu
sudo apt install ncdu运行后会自动扫描文件系统并生成可视化报告：
# 扫描根目录（耗时取决于文件数量） ncdu /常用快捷键说明：
| 按键 | 功能描述 |
|---|---|
| j/k | 上下移动光标 |
| Enter | 进入子目录 |
| d | 删除当前选中文件/目录 |
| n | 按文件名排序 |
| s | 按大小排序（最常用） |
2.2 Docker系统资源清理
/var/lib/docker是常见的大户，但直接使用docker system prune可能误删重要镜像。更安全的做法是：
# 查看Docker磁盘使用概况 docker system df # 仅清理已停止的容器和悬空镜像 docker container prune docker image prune对于生产环境，建议配合过滤条件精确清理：
# 删除所有超过2周的已停止容器 docker container prune --filter "until=336h"3. 深水区：日志文件系统化治理
应用日志是另一个磁盘杀手，需要建立标准化清理机制而非手动删除。
3.1 日志轮转配置示例
以Nginx为例，修改/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 }关键参数说明：
rotate 14：保留14天的日志compress：启用gzip压缩历史日志daily：每天轮转一次
3.2 Docker容器日志清理
容器默认的json日志驱动可能产生巨型文件，解决方案：
方案一：运行时限制日志大小
docker run --log-driver json-file \ --log-opt max-size=50m \ --log-opt max-file=3 \ nginx方案二：全局配置限制（修改/etc/docker/daemon.json）
{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }4. 预防区：建立监控告警体系
被动清理不如主动预防，需要建立三层防御体系：
- 实时监控：配置Prometheus + Grafana监控磁盘使用率
- 自动化清理：编写定期执行的清理脚本
- 容量规划：建立存储使用增长预测模型
示例的清理脚本/usr/local/bin/disk_cleaner.sh：
#!/bin/bash THRESHOLD=85 CURRENT=$(df / --output=pcent | tail -1 | tr -d '% ') if [ "$CURRENT" -ge "$THRESHOLD" ]; then logger "Disk cleanup triggered at ${CURRENT}% usage" apt-get clean journalctl --vacuum-time=7d docker system prune -f --filter "until=72h" fi设置cron每周执行：
0 3 * * 1 /usr/local/bin/disk_cleaner.sh那次深夜救援最终发现是某个微服务日志配置错误，每小时产生2GB日志文件。现在我们的运维体系新增了日志规范检查清单，所有新服务上线前必须通过存储压力测试
