1. 磁盘空间告急的紧急诊断当服务器突然弹出No space left on device的红色警告时就像汽车油表亮起红灯必须立即处理。我通常会先执行一套组合命令快速定位问题根源df -hT # 查看各分区使用情况人类可读格式 du -sh /* 2/dev/null # 快速扫描根目录下各文件夹大小 lsblk # 显示块设备挂载关系最近处理的一台Nginx服务器案例中通过df -h发现/var分区使用率100%进一步用du -sh /var/*排查发现/var/log/nginx目录竟占用了42GB空间。这种突发性增长往往意味着应用程序开启了Debug日志但未正确轮转遭遇恶意爬虫导致异常访问日志暴增日志配置错误导致重复记录关键技巧使用--time参数可以显示文件的修改时间du -sh --time /var/log/*能快速识别近期暴增的目录2. 日志文件的精准打击策略2.1 即时清理的外科手术对于已经爆满的磁盘需要像外科医生一样精准操作。我常用的清理组合拳# 找出最大的10个日志文件 find /var/log -type f -name *.log -exec du -h {} | sort -rh | head -n 10 # 安全清空日志文件比rm更安全 truncate -s 0 /var/log/nginx/access.log # 按时间清理旧日志保留7天内 find /var/log -name *.log -mtime 7 -exec rm -f {} \;特别注意直接rm正在被写入的日志文件可能导致空间不释放文件句柄未释放。此时应该用lsof | grep deleted查找被删除但未释放的文件通过echo filename或truncate方式清空2.2 日志轮转的自动化配置手动清理只是临时方案完善的logrotate配置才是治本之道。以Nginx为例这是我的标准配置模板/var/log/nginx/*.log { daily missingok rotate 30 compress delaycompress notifempty create 0640 www-data adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }关键参数解析delaycompress延迟压缩前一个日志文件方便排查最新问题create设置新建日志文件的权限和属主size 100M可替代daily达到指定大小就轮转血泪教训曾因配置copytruncate导致日志丢失建议优先使用create信号通知方式3. 高级空间管理技巧3.1 Inode用尽的隐蔽危机某次清理后磁盘空间充足但仍报空间不足最终发现是inode耗尽。诊断命令df -i # 查看inode使用情况 find / -xdev -type f | awk {print $NF} | cut -d/ -f2 | sort | uniq -c | sort -n解决方案删除小文件聚集的目录如缓存目录重建文件系统增加inode数量需备份数据对于邮件服务器等场景改用数据库存储小文件3.2 磁盘空间的幽灵占用当df和du结果不一致时可能是已删除文件被进程占用lsof L1 | grep deleted kill -9 PID # 重启相关进程释放空间挂载点覆盖mount | grep overlap umount /path # 解除错误挂载3.3 Docker的存储陷阱容器平台常隐藏着空间杀手推荐清理流程docker system df # 查看存储概况 docker prune all --filter until24h # 清理24小时前资源 # 深度清理谨慎使用 docker volume prune docker builder prune对于生产环境建议配置docker存储驱动为overlay2并在/etc/docker/daemon.json中设置存储限制{ storage-driver: overlay2, storage-opts: [ overlay2.size20GB ] }4. 长效防御体系建设4.1 监控预警方案我常用的监控组合Prometheus node_exporter监控# prometheus.yml 配置示例 - job_name: node static_configs: - targets: [localhost:9100]自定义报警规则groups: - name: disk.rules rules: - alert: DiskSpaceCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 90 for: 10m4.2 自动化清理脚本这是我维护服务器的保洁机器人脚本#!/bin/bash # 自动清理脚本 v2.1 LOG_DIR/var/log/cleanup mkdir -p $LOG_DIR # 日志轮转清理 find /var/log -type f -name *.gz -mtime 30 -delete $LOG_DIR/clean.log 21 # 临时文件清理 find /tmp -type f -atime 7 -delete $LOG_DIR/clean.log 21 # Docker清理 docker system prune -af $LOG_DIR/docker.log 21 # 发送报告 df -h | mail -s Disk Cleanup Report adminexample.com建议通过crontab每周执行0 3 * * 0 /usr/local/bin/disk-cleanup.sh4.3 架构级解决方案对于高日志量场景应考虑日志分级存储热数据本地SSD保留7天温数据NAS存储保留30天冷数据对象存储保留1年集中式日志系统# Filebeat配置示例 filebeat.inputs: - type: log paths: - /var/log/*.log output.elasticsearch: hosts: [es01:9200]无状态化改造将session数据存入Redis使用云原生存储卷5. 故障恢复的终极手段当所有清理手段都无效时最后的救命稻草紧急扩容LVM环境下pvcreate /dev/sdb1 vgextend vg01 /dev/sdb1 lvextend -L 20G /dev/vg01/lv_root resize2fs /dev/vg01/lv_root关键服务迁移rsync -avz --delete /var/www/ userbackup:/backup/www/ systemctl stop nginx tar czf /backup/nginx_conf.tar.gz /etc/nginx系统级快照# 阿里云示例 aliyun ecs CreateSnapshot --DiskId d-bp1j19q2enql0**** --SnapshotName emergency_snap经过多年运维实战我总结出磁盘空间管理的三早原则早监控、早预警、早处理。建议将磁盘检查纳入每日晨会必检项毕竟预防永远比抢救更轻松。