日志太多，磁盘说不行
用Linux的都知道，系统跑久了，/var/log底下一堆日志文件堆成山。尤其是开了systemd的服务，journald记的日志一不留神就占了几个GB，某天突然发现根分区爆了，SSH都连不上，只能进救援模式删日志——这种事不少人都踩过坑。
其实systemd自带日志轮转和清理机制，关键是怎么让它听话干活，别把硬盘当无限大。
journald的默认行为没你想的那么智能
很多人以为journald会自动清理旧日志，其实默认配置下它只按时间或大小做简单轮转，并不会主动删除。日志存太久、空间不够时，它可能只是停止记录，而不是清理腾地方。这就导致问题发现不及时，等你察觉时往往已经晚了。
真正管用的是手动调优配置，让日志保留策略符合实际需求。
修改journald配置控制日志体积
配置文件在 /etc/systemd/journald.conf，打开后可以设置几个关键参数：
[Journal]
# 限制运行时日志最大占用空间
SystemMaxUse=512M
# 设置单个日志文件的最大大小
SystemMaxFileSize=64M
# 最多保留多久的日志
MaxRetentionSec=3weeks
# 强制定期压缩旧日志
Compress=yes上面这些设置的意思很直接：整个日志目录最多用512MB，单个文件超64MB就切新文件，日志最长留三周，老的直接删。这样一来，就算服务狂写日志，也不会把系统拖垮。
动手清理现有日志
改完配置还不算完，旧日志还在占空间。可以用journald自带命令马上腾出空间：
sudo journalctl --vacuum-size=200M这条命令会保留最近200MB的日志，其余全删。也可以按时间清：
sudo journalctl --vacuum-time=2weeks比如你想留两周内的排查依据，更早的就不用管了。
配合logrotate避免双重记录
有些服务既被journald记录，又自己往/var/log写文件日志（比如nginx、rsyslog）。这时候两边都有数据，白白浪费空间。建议统一策略：要么关掉服务自身的日志输出，专注用journalctl查；要么在logrotate里加上对journald日志的协调处理。
比如在 /etc/logrotate.d/systemd-journal 里加规则：
/var/log/journal/* {
rotate 4
weekly
compress
missingok
notifempty
}不过更推荐直接用journald管理，毕竟它是现代systemd系统的原生方案，集成度高，查日志也方便。
日常查看和监控别偷懒
定期执行 journalctl --disk-usage 看一眼当前日志占了多少空间，就像检查邮箱垃圾箱一样，养成习惯能避免突发问题。如果服务器重要，还可以写个cron任务每周提醒一次日志体积。
合理的日志管理不是为了省那点磁盘，而是让系统更稳、出问题时能快速定位，同时避免小问题演变成宕机事故。