服务器Nginx日志过大占满盘？附2026实用切割配置

排查过程很快，登上去用df -h一看，3T的数据盘空了300多G，但20G的系统/var/log分区确实爆得死死的，再用du -sh /var/log/*往下找，教辅小程序的access.log占了19.8G——三个月前刚上线忘了切日志！那天刚好是春促预热第一天，十点开始用户量就翻了三倍，一直攒到凌晨。

虽然马上临时用gzip -c /var/log/nginx/access.log > /tmp/2026春促预热-old.log.gz && echo '' > /var/log/nginx/access.log救了场，备份到OSS后删了旧文件，老板还是凌晨三点打了语音，语气不算重但听得出来有点慌，毕竟预热第一天的前端加载数据本来要做复盘的，旧日志还差点没救回来。

踩过这种坑才明白，中小厂或者新手兼做运维，真的别嫌日志切割麻烦，系统自带的logrotate就够香，完全不用额外装Docker或者其他花里胡哨的工具。

首先得确认系统有没有logrotate，默认CentOS 7/8/9、Ubuntu 20.04/22.04/24.04/26.04这些主流发行版都装了，检查的话CentOS系列用dnf list logrotate installed（7代改成yum就行），Ubuntu/Debian用dpkg -l logrotate，能看到版本号就没问题。

然后找配置目录，默认在/etc/logrotate.d/下，yum或者apt一键装的Nginx一般会自动生成nginx这个文件，但自己编译的大概率没有，直接新建一个就行。给你们一个我现在线上所有业务都在用的配置，注释都标得很细，别瞎抄路径，换成自己Nginx实际放日志的地方：

/var/log/nginx/access.log /var/log/nginx/error.log {
 daily
 dateext
 dateformat -%Y%m%d
 rotate 30
 compress
 delaycompress

 notifempty
 missingok
 sharedscripts
 postrotate
 kill -USR1 cat /var/run/nginx.pid 2>/dev/null || true
 endscript
}

这里有几个参数新手一定要注意，首先是postrotate脚本，这个绝对不能漏！漏了的话切完日志Nginx还在往旧的临时文件写，等于白忙活。我刚入行的时候就踩过这个坑，切完发现新的access.log是空的，熬了一个通宵才找到原因。还有脚本里的命令，我个人更推荐用kill -USR1，比nginx -s reload更安全，极端情况下不会因为其他配置问题影响业务，只会让Nginx重新打开日志文件。

另一个是delaycompress，开了的话刚切完的前一天日志不会马上压缩，方便当天查问题复盘，不用每次都解压。中小厂人手少，这个太实用了。rotate的数量看你云盘的剩余空间和业务需求，比如我现在教辅业务留30天，压缩后大概180G，完全没问题，新手可以先设7天或者14天，保险。

配置写完别急着放着不管，先手动测试调试一下：logrotate -d /etc/logrotate.d/nginx，这个-d是调试模式，不会真执行，看看有没有路径不对、脚本权限错了的问题。如果没问题就强制执行一次看看效果：logrotate -f /etc/logrotate.d/nginx，然后去日志目录看看有没有带日期的新文件，再用tail -f /var/log/nginx/access.log看看有没有实时请求进来，自己也可以curl一下网站确认一下。

最后给两个新手专属的避坑提醒：第一个是日志路径的权限，默认logrotate是用root执行的，但如果新手自己改了日志路径的所有者，换成了普通用户，可能会报Permission denied，保证目录和文件是root或者nginx的运行用户就行，用ps aux | grep nginx看master进程的用户就能知道。第二个是别以为配置好了就万事大吉，一定要配合云监控的磁盘使用率告警，设置80%的阈值，提前预警，别等100%才处理。

你们在运维工作中有没有遇到过类似的日志炸盘坑？都是怎么处理的？欢迎在评论区分享你的经验。