Nginx 日志切割别再手写脚本：logrotate、USR1 和 VPS 运维边界

Nginx 的日志切割，最怕的不是不会配，而是把它当成一次性脚本。日志轮转这件事看起来琐碎，实际上直接决定磁盘会不会被打满、排障时能不能回看、日志归档是否稳定。生产上更稳的做法通常不是手写 cron 去搬文件，而是让 Linux 的 logrotate 接管这一层。

logrotate 的好处很简单：它是系统级工具，知道轮转、压缩、保留和清理的整套逻辑，也知道什么时候该给 Nginx 发 USR1 让它重新打开日志文件。对一个长期跑在 VPS 或独立服务器上的站点来说，这种“默认就能活得久”的特性，比花哨脚本更值钱。

先把轮转这件事想清楚

Nginx 的 access log 和 error log 会持续增长。如果你只是在日志目录里堆文件，不做轮转，最直接的后果是磁盘越来越满；更隐蔽的问题是，当你真的需要回溯一次故障时，旧日志已经被覆盖、压缩得支离破碎，甚至根本找不到对应时间段。

生产环境里，日志轮转至少要回答四个问题：多久切一次、保留几份、切完怎么压缩、切完后怎样让 Nginx 继续写新文件。logrotate 之所以成为默认答案，就是因为这四个问题它都能标准化处理。

一个可用的配置长什么样

/var/log/nginx/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            kill -USR1 `cat /var/run/nginx.pid`
        fi
    endscript
}

这里最关键的不是语法，而是思路。

daily 决定轮转节奏，通常是最稳妥的起点。
rotate 7 控制保留周期，避免归档无限增长。
compress 和 delaycompress 负责节省空间，同时保留最近一份未压缩日志便于快速查看。
sharedscripts 保证多个日志文件轮转时只执行一次后置脚本。
postrotate 里的 USR1 信号，是让 Nginx 重新打开日志文件的关键一步。

如果少了最后一步，Nginx 可能还在往旧文件里写，轮转就会变成“看起来成功，其实没切干净”。

轮转策略不要拍脑袋

有人喜欢按天切，有人喜欢按大小切。真正该按哪个切，不看习惯，看日志增速和磁盘预算。小流量站点按天切通常足够；高流量 API 或代理服务，可能还要结合 size 条件或者更短的周期。配置的目标不是“看上去整齐”，而是“在最坏情况下也不会失控”。

如果站点是跑在 VPS 上，磁盘本来就紧，日志管理更不能拖。最典型的事故就是：服务本身没挂，最后挂的是磁盘。日志、缓存、临时文件、备份叠在一起，一周就把空间吃光。

如果你是在 VPS 或独立服务器上跑站点，日志轮转和磁盘预算最好一开始就定死。

很多看似“日志问题”的事故，最后都是因为机房资源买小了、日志没切、磁盘被打满。可以先把机器底座选稳，再谈上层运维：https://www.rainyun.com/NDcxMTIz_

如何验证配置真的生效

不要等到第二天再看结果。先用 logrotate -d 做干跑，确认路径、条件和脚本都没问题；再用 logrotate -vf 强制跑一次，验证旧日志是否被归档、新日志是否正常创建、Nginx 是否继续写入。

最常见的坑有三个：一是 PID 文件路径不对；二是权限不对，导致轮转后 Nginx 无法写新文件；三是容器或精简系统里 cron / timer 没启，导致配置写了也没人执行。前两个是配置问题，第三个是运行环境问题，不能混着看。

把轮转、监控、备份放一起看

日志轮转不是孤立动作。真正上线时，最好把它和磁盘监控、错误报警、备份保留一起设计。轮转负责让日志“不会无限长”，监控负责告诉你“空间什么时候快没了”，备份负责让你在审计或复盘时还能找到足够长的历史记录。三者少一个，运维就会开始补洞。

最稳的做法，是把日志文件路径、保留周期、压缩策略和磁盘阈值写成一套统一约定，而不是不同机器临时改一改。只要业务还在增长，临时方案迟早会变成运维债务。

为什么很多事故都和日志有关

日志本身通常不是根因，但它经常是最先把问题暴露出来的地方。磁盘满、句柄没重开、压缩脚本失败、轮转任务没执行，这些问题一开始看起来都只是“日志异常”，最后往往会演变成站点不可写、Nginx 报错、甚至数据库或缓存服务被连带拖垮。

所以 Nginx 日志轮转要按“会出事故的边界”来处理，而不是按“平时看不见的配置项”来处理。

实操上最值得检查的四件事

日志目录是否和系统磁盘监控绑定。
轮转后 Nginx 是否真的重新打开了日志句柄。
压缩后的旧日志是否还在保留窗口内可读。
定时任务是否会在系统重启、升级或容器重建后继续运行。

这些检查比“配置文件能不能过语法”更重要，因为它们决定的是生产环境里的真实行为。

什么时候不要依赖脚本

如果你只是本机临时调试，简单脚本还能凑合。但只要是长期运行的站点、代理、网关、监控节点，日志轮转就应该交给成熟机制。脚本的最大问题不是不会做，而是没人记得它什么时候会失败。

对 Nginx 来说，日志轮转不是附属功能，而是运维边界的一部分。把它做稳，后面的排障、归档、审计才有前提。