Linux配置Nginx日志自动切分与Logrotate详解

配置Nginx日志自动切分时，许多运维人员会选择经典的logrotate工具。但在实际部署中，若几个关键细节处理不当，配置可能形同虚设——日志文件看似已归档，Nginx进程却仍在向旧文件写入，或归档文件名混乱。本文将逐一解析并解决这些常见问题。

配置文件位置错误导致Cron未执行

第一个常见误区是配置文件的位置。logrotate配置必须置于 /etc/logrotate.d/ 目录下，才能被系统自动加载执行。原因是系统默认通过 /etc/cron.daily/logrotate 脚本每日执行日志轮转，该脚本会读取 /etc/logrotate.conf 主配置文件，而主配置文件中包含 include /etc/logrotate.d 指令，因此仅会包含该目录内的文件。

虽然直接修改 /etc/logrotate.conf 主文件在技术上也可生效，但强烈不推荐。一方面，该文件可能在系统更新时被覆盖；另一方面，将不同服务的配置分开管理更符合服务隔离原则，也便于维护。

常见错误是：在自定义路径（如 /root/）下创建 nginx.logrotate 配置，并通过 logrotate -f /root/nginx.logrotate 手动测试成功，便误以为配置生效。实际上，Cron任务无法找到此配置文件，导致自动轮转从未启动。

• 正确做法：使用 sudo tee /etc/logrotate.d/nginx 命令写入配置。
• 确认权限：确保文件权限为 644，属主和属组为 root:root。
• 注意后缀：logrotate仅识别文件名本身，无需添加 .conf 后缀，直接命名为 nginx 即可。

重载Nginx时使用错误信号可能导致服务中断

日志文件轮转后，必须通知Nginx重新打开日志文件句柄，否则它将继续向已被重命名或删除的旧文件写入数据。此操作通常在 postrotate 指令块中完成。

关键在于：应使用 kill -USR1 信号，而非 systemctl reload nginx。

原因是：Nginx收到 USR1 信号后，会优雅地重新打开日志文件，这是一个原子操作，对服务无影响。而 systemctl reload 会触发worker进程的平滑重启，在高并发场景下仍存在微小概率丢失请求。此外，systemctl 依赖于systemd环境，在精简的Docker容器或使用OpenRC等初始化系统的环境中可能不可用。

另一个细节是如何获取Nginx master进程的PID。不应硬编码路径。最稳妥的方法是优先读取Nginx配置文件中 pid 指令指定的路径。若启动时未指定，默认路径可能是 /var/run/nginx.pid 或 /usr/local/nginx/logs/nginx.pid，需根据实际安装方式判断。

• 安全的基础写法：if [ -f /var/run/nginx.pid ]; then kill -USR1 $(cat /var/run/nginx.pid); fi
• 更健壮的写法（尝试自动获取pid路径）：pidfile=$(nginx -t 2>&1 | grep "pid" | awk '{print $NF}'); [ -f "$pidfile" ] && kill -USR1 $(cat "$pidfile")
• 务必避免：在 postrotate 中使用 systemctl restart nginx，这会导致服务中断，且违背日志切割的初衷。

实现日志按日期命名需配对使用特定参数

默认情况下，logrotate使用数字后缀（如 access.log.1, access.log.2）。若想改为按日期命名（如 access.log-2026-04-26），需使用 dateext 参数。

但易被忽略的是：dateext 和 dateformat 必须与 daily（或 hourly 等）频率指令配合使用才会生效。仅添加 dateext 是不够的。

通常，我们希望归档文件名显示“日志内容所属的日期”，而非“执行轮转的日期”。这需要添加 dateyesterday 参数。例如，在4月27日凌晨切割日志，添加 dateyesterday 后，生成的文件名将为 access.log-2026-04-26，语义更清晰。

此外，dateformat 的格式字符串必须以 % 开头，且不能包含空格或Shell中的特殊字符，否则logrotate会直接报错退出，导致整个配置失效。

• 推荐组合：daily dateext dateyesterday dateformat -%Y-%m-%d
• 错误示例：dateformat "_%Y_%m_%d"（以下划线开头可能导致文件名解析异常）
• 验证方法：手动执行 sudo logrotate -vf /etc/logrotate.d/nginx，观察输出的新文件名是否包含预期的日期格式。

使用通配符可能引发意料之外的副作用

为简化配置，许多人习惯使用通配符，如 /var/log/nginx/*.log。这看似方便，可匹配 access.log、error.log 等多个文件。

但问题是，logrotate会将匹配到的所有文件视为一个“组”处理。这意味着它们将共享同一套 rotate（保留份数）、compress（压缩）、postrotate（后置脚本）等逻辑。这通常不符合需求：例如，error.log 文件较小，可能无需与庞大的 access.log 一同压缩；或可能只想对访问日志使用日期后缀，而错误日志保持数字后缀。

更稳妥的做法是为每个需要独立管理的日志文件单独编写配置块，并用注释清晰区分。这样各日志文件的轮转策略互不干扰，管理也更清晰。

• 不推荐的写法：/var/log/nginx/*.log { daily rotate 7 ... }
• 推荐的写法：分别为 /var/log/nginx/access.log 和 /var/log/nginx/error.log 编写两段配置。
• 特别注意：logrotate不解析Shell变量或命令。配置路径中若包含 $HOME 或 $(date +%F) 等表达式，会被当作普通字符处理，通常导致匹配失败。

最后，还有一个隐藏问题：若 postrotate 脚本中调用的外部命令执行失败，logrotate默认会静默忽略，除非添加 -v（详细）参数。这可能导致一种危险情况：你以为一切正常，但Nginx可能因信号发送失败而从未重新打开日志文件，持续向已被轮转的旧文件写入数据。

因此，最关键的一步是：在首次部署logrotate配置后，务必手动执行 sudo logrotate -vf /etc/logrotate.d/nginx，仔细检查输出中是否有“error”或“skipping”等字样。只有确认每一步都执行成功，日志自动切分才算真正部署到位。