Nginx 日志切割的正确姿势：logrotate、USR1 和 VPS 磁盘边界

很多人第一次处理 Nginx 日志轮转，都会把它想得很简单：旧日志搬走，新日志接上，事情就完了。真到线上才知道没这么轻松。轮转太频繁会把排障资料切碎，轮转太少又会把磁盘吃满，压缩、保留、重新打开文件句柄这几件事少一件都不行。

为什么别自己写脚本

自己写脚本不是不能用，就是太容易漏细节。你今天能把文件重命名，明天不一定能记得让 Nginx 重新打开日志文件；你能压缩旧日志，不代表能稳定控制保留份数；你能在测试机上跑通，也不代表机器重启、服务重载、日志异常时还能继续对。

logrotate 的好处，是把这些动作都标准化了。什么时候轮转、保留几份、要不要压缩、空日志怎么办、缺文件怎么办，都能明明白白地写出来。线上更看重能不能稳住，灵活反倒排后面。

Nginx 轮转里最容易出问题的地方

第一个问题是日志句柄。文件换了名，进程并不会自己去找新文件。Nginx 这时需要收到 USR1 信号，才会重新打开日志文件。这个步骤忘了，最常见的结果就是：你以为日志在写，实际上日志还挂在旧文件上。

第二个问题是保留策略。很多 VPS 空间都不大，日志一多很容易撑爆磁盘。反过来，保留太少又会让你在出问题时翻不到历史记录。通常更稳妥的做法是先定一个简单默认值，比如按天轮转、保留一周、压缩旧文件，再根据站点流量和排障需要去改。

一套够用的默认配置

对多数中小站点来说，daily、rotate 7、compress、delaycompress 是比较顺手的起点。这样做的意思不是“永远正确”，而是先把最容易踩坑的几件事固定住，再观察实际情况。

比如，如果你的网站流量不大，七天保留通常够用；如果你经常排障，可以再多留几天；如果压缩后还嫌占空间，再继续缩短保留周期。重点不是照抄某个模板，而是让轮转规则跟你的站点规模、磁盘容量和排障习惯匹配。

VPS 场景下，日志不是越多越好

很多人买 VPS 时，先想到的是省钱，没想到日志也会吃空间。日志不断增长，磁盘满了以后，出问题的不只是 Nginx，还可能连系统更新、数据库、备份都受影响。所以日志轮转不是“运维洁癖”，而是很实际的生存线。

如果站点还在初期，Nginx 日志可以按常规规则处理；如果机器已经很紧张，就应该把保留天数、压缩方式和清理频率看得更细。必要时甚至可以把访问日志和错误日志分开看待，别让一个爆量文件拖慢整个机器。

上线前最好自己测一遍

别等到磁盘快满了才发现规则有问题。最稳的办法，是先在测试机上手动跑一遍，看看新日志是不是还能继续写，旧日志有没有按预期被压缩，USR1 后文件句柄是不是确实重开了。只要这些动作能在测试机上跑顺，上线时就少很多惊喜。

最后就一句话：日志得留得住，但不能把机器拖死。把这条线守住，比把配置写得花哨重要得多。