如何在Linux中配置Nginx访问日志分割 Linux按天切分日志的方法

如何在Linux中配置Nginx访问日志分割 Linux按天切分日志的方法

系统教程

不能直接用logrotate的daily选项完事,因为Nginx进程仍持有原日志文件描述符,不发USR1或reopen信号则持续写入旧文件,导致切割失效、双写或日志丢失;必须配合postrotate中nginx -s reopen或kill -USR1,并正确配置create、sharedscripts、dateext等参数。

为什么不能直接用 logrotate 的 daily 选项就完事?

很多用户以为给 logrotate 配个 daily 就能自动按天切分 Nginx 日志,结果发现日志文件没重命名、旧日志还在写、甚至出现双写——根本原因是 Nginx 进程仍持有原日志文件的文件描述符,logrotatemovefirst 或默认 rename 操作后,Nginx 并不知道该换新文件写入。

必须配合 kill -USR1 通知 Nginx 重新打开日志文件,否则所有“切割”只是表面移动,实际写入仍在原文件里。

  • logrotate 需配置 createsharedscripts,确保新日志权限正确且只执行一次 postrotate
  • postrotate 中必须调用 nginx -s reopen(推荐)或 kill -USR1 $(cat /var/run/nginx.pid)
  • 若 Nginx 以非 root 用户运行(如 www-data),logrotate 脚本需有足够权限发送信号,建议用 su 切换用户

logrotate 配置文件怎么写才不丢日志?

典型错误是把 /var/log/nginx/*.log 写成通配符路径却不加 missingok,导致某天没有访问日志时 logrotate 报错退出,后续切割全部中断;另一个坑是没设 dateext,靠编号轮转(.1, .2)容易覆盖旧数据,无法按日期定位。

推荐配置片段(保存为 /etc/logrotate.d/nginx):

/var/log/nginx/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0644 www-data www-data
    sharedscripts
    dateext
    dateformat -%Y%m%d
    postrotate
        if [ -f /var/run/nginx.pid ]; then
            nginx -s reopen 2>/dev/null || true
        fi
    endscript
}
  • dateformat -%Y%m%d 生成形如 access.log-20241015 的归档名,比默认 -%Y%m%d%S 更干净
  • delaycompress 避免刚切完就压缩,方便排查当天问题
  • notifempty 防止空日志触发无意义切割
  • 务必确认 www-data 是 Nginx worker 进程的实际运行用户,可通过 ps aux | grep nginx 查看

手动触发和验证切割是否生效?

别等凌晨 cron 自动跑——先用 logrotate -d /etc/logrotate.d/nginx 看调试输出,确认匹配到日志路径、执行了 postrotate;再用 logrotate -f /etc/logrotate.d/nginx 强制执行一次,观察行为是否符合预期。

Docker Desktop(linux)

当前 Docker 最新稳定版本之一,主要针对稳定性和兼容性进行了修复优化,适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力,对 Windows/macOS/Linux 平台兼容性进行了进一步优化。

下载

验证要点:

  • 执行后原 access.log 文件大小是否归零?用 ls -l /var/log/nginx/access.log 看 size
  • 是否有新文件如 access.log-20241015 生成?用 ls -t /var/log/nginx/*.log* 排序查看
  • 执行 lsof -p $(cat /var/run/nginx.pid) | grep log,确认 Nginx 打开的仍是 access.log(而非旧的带日期后缀的文件)
  • 立刻 curl 一下站点,检查新 access.log 是否有新增行,而不是写进归档文件里

systemd 环境下要注意 PID 文件位置

某些发行版(如较新 Ubuntu/Debian)用 systemd 管理 Nginx,/var/run/nginx.pid 可能不存在或被写入 /run/nginx.pid;更稳妥的方式是不用硬编码 PID 路径,直接用 nginx -s reopen——它会自己找 PID 文件位置。

如果 nginx -s reopennginx: [alert] kill(12345, 10) failed (3: No such process),说明:

  • Nginx 主进程已退出,但 worker 还在(罕见),先 systemctl restart nginx
  • nginx 命令不在 $PATH 中,logrotate 脚本里改用绝对路径:/usr/sbin/nginx -s reopen
  • SELinux 启用时可能拦截信号,临时用 setenforce 0 测试是否为此原因

最常被忽略的是:logrotate 的执行用户(通常是 root)必须对 Nginx 配置和二进制文件有读取权限,否则 nginx -s reopen 会静默失败。

本文地址:https://www.sztg.com.cn/article/680349.html

如非特殊说明,本站内容均来自于网友自主分享,如有任何问题均请联系我们进行处理!

猜您喜欢