云服务器Ubuntu磁盘满致服务宕机应急指南

云服务器Ubuntu系统因磁盘满导致服务宕机是运维中高频问题。去年双十一前，某电商平台就因用户行为日志暴增，/var/log目录48小时内占满80GB磁盘空间，最终触发服务崩溃。这种深夜被警报叫醒的场景，许多运维工程师都不陌生。本文结合真实案例，拆解从诊断到预防的全流程应对方案。

现象识别：服务宕机的"磁盘信号"

故障发生时，最直观的表现是业务系统无响应——用户反馈网站打不开，后台应用报错"无法写入文件"。登录云服务器后，首先用`df -h`命令验证：若某分区使用率显示100%（如`/dev/vda1 100G 100G 0 100% /`），基本可锁定是磁盘空间耗尽导致。此时系统无法创建新文件，日志写入中断，进程因无空间存储临时数据而崩溃。

快速诊断：三步定位"空间吞噬者"

1. 确认满盘分区：执行`df -h`，重点关注`Use%`列，找到使用率100%的分区（常见为根分区/）。
2. 查找大文件目录：使用`du -sh /* --max-depth=1`（递归计算根目录下一级目录大小），曾有案例中该命令显示`/var 78G`，锁定日志目录异常。
3. 排查日志暴涨：进入可疑目录（如/var/log），执行`ls -lhS`按文件大小排序，若发现`access.log`或`app.log`单日增长数GB，基本可判定是日志未及时清理导致。

应急解决：从临时清理到长期优化

第一步：临时释放空间
- 删除过期文件：用`find /var/log -type f -name "*.log" -mtime +7 -delete`删除7天前的日志（实测某案例释放52GB）。
- 清理系统缓存：执行`apt-get clean`清理apt安装缓存（约释放2-5GB），`rm -rf /tmp/*`删除临时文件（注意确认无正在使用的临时文件）。

第二步：日志管理优化
- 配置日志轮转（logrotate，定期归档旧日志并生成新文件的机制）：编辑`/etc/logrotate.conf`，添加规则如：

/var/log/app.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

该配置会每天切割日志，保留7份压缩归档，避免单文件无限增长（某案例实施后，单日志文件从日均15GB降至0.8GB）。

第三步：磁盘扩容
若业务长期需要更大空间，联系云服务器提供商扩容。以某客户为例，在控制台提交根分区扩容申请，10分钟内完成扩容，重启服务器后`df -h`显示可用空间增加50GB，彻底解决容量瓶颈。

长效预防：从被动响应到主动监控

- 设置阈值监控：使用Zabbix或Prometheus监控磁盘使用率，设置80%预警（邮件/短信通知）、90%紧急告警（触发自动清理脚本）。某金融客户配置后，曾提前3小时发现日志异常增长，避免了宕机。
- 自动化清理脚本：编写cron任务（`crontab -e`），每周六凌晨执行清理脚本：

0 3 * * 6 /usr/bin/find /var/log -type f -name "*.log" -mtime +14 -delete
0 4 * * 6 /usr/bin/apt-get clean >/dev/null 2>&1

确保系统自动维持磁盘空间在合理范围。

处理云服务器Ubuntu磁盘满问题，关键在"快"与"稳"：快速释放空间恢复业务，同步定位根源优化管理。通过监控+自动化的组合，能将此类故障从"紧急事件"变为"可预见风险"，真正保障云服务器的稳定运行。