Linux系统日志管理与磁盘空间优化实战

1. 问题背景与现象分析

那天早上，我像往常一样打开云服务器监控面板，突然发现一台关键业务服务器的系统盘使用率飙升至100%。这台服务器的配置是4核CPU、4G内存、40G系统盘，运行着一个Java Spring Boot应用，使用systemd进行服务管理。监控面板显示的几个关键指标让我瞬间警觉：

• 系统盘使用率100%：40G空间全部耗尽
• CPU使用率100%：持续满载状态
• 内存使用率67%：尚在可控范围
• 系统盘IO写入5MB/s：持续高负载

应用响应速度明显变慢，部分接口甚至出现超时。由于业务高峰期即将到来，扩容或更换服务器都来不及，我必须立即找出问题根源并解决。

2. 问题定位与紧急处理

2.1 快速定位磁盘占用源头

我首先使用以下命令查看磁盘使用情况：

bash复制df -h /
du -sh /* 2>/dev/null

结果显示根分区/dev/vda2已用满40G，而/var目录独占约33G空间。继续深入查看：

bash复制cd /var && du -sh * 2>/dev/null

发现/var/log目录占用了约32G空间。进一步检查日志文件：

bash复制cd /var/log && du -sh * 2>/dev/null

最终锁定罪魁祸首：

• syslog：约11G
• syslog.1：约21G
• journal：约938M

2.2 紧急释放磁盘空间

在深入分析原因前，必须先释放磁盘空间，否则很多诊断命令都无法执行。我采取了以下措施：

bash复制# 清空当前syslog但保留文件
sudo truncate -s 0 /var/log/syslog

# 删除轮转的大文件
sudo rm /var/log/syslog.1

# 清理所有轮转备份
sudo rm -f /var/log/syslog.*
sudo rm -f /var/log/syslog.*.gz

# 确认空间释放
df -h /

操作后，系统盘使用率从100%降至约19%，可用空间恢复到31G左右。

3. 问题根源分析

3.1 日志链路梳理

通过分析日志流转路径，我