Hostease 专区实测讨论：nginx 日志轮转与切割实战：服务器日志管理部署需要验证哪些指标

为什么日志轮转值得单独验证

跑了一段时间的 Nginx 站点，磁盘空间经常莫名减少，很多人第一反应是查代码或删备份，其实真正在悄悄吃满磁盘的往往是不断增长的 access.log 和 error.log。这篇指南教你用 logrotate（Linux 自带的日志轮转工具，负责定期切割、压缩并清理旧日志）对 Nginx 日志做轮转与切割，让日志按天归档、自动压缩、超过保留期限自动删除，服务器不再因为日志失控而报警。日志管理看似不起眼，却是服务器稳定运行里最容易被忽视的一环，下面从日志结构讲起，帮助你一次把轮转策略落地。

Nginx 日志结构与为什么需要切割

Nginx 默认把访问日志写到 access.log，把错误日志写到 error.log。access.log 记录每一次客户端请求，包括访问者 IP、请求路径、状态码、响应大小和耗时；error.log 记录 Nginx 运行过程中的异常，比如 404 资源缺失、上游超时、SSL（Secure Sockets Layer，安全套接层，用于加密客户端与服务器之间通信的协议）握手失败等。两者职责不同，排查问题时的价值也不一样。

如果不做任何处理，access.log 会一直追加写。一个日均访问量在几万次的站点，access.log 每天可能增长几十 MB 到上百 MB，一个月就是几个 GB。日志文件越大，除了占用磁盘，还会带来两个麻烦：一是定位问题时用编辑器打开大文件非常卡；二是 Nginx 在写日志时如果磁盘已满，可能会影响正常响应。所以日志必须定期切割——把当前日志文件按周期归档成带时间戳的文件，再让 Nginx 重新打开一个新的日志文件继续写。

以一份典型的 access.log 为例，日志单行格式大致如下：

# 一行访问日志：IP - 用户 - 时间 - 请求 - 状态码 - 响应字节
127.0.0.1 - - [26/Aug/2026:10:15:30 +0800] "GET /index.html HTTP/1.1" 200 5120

上面的字段依次是客户端 IP、时间、请求行、HTTP 状态码和响应字节数。示例中的 IP 与时间为占位数据，实际以你的日志为准。当这类日志持续累积，就到了需要轮转的时候。

logrotate 基础配置：按天切割

logrotate 是绝大多数 Linux 发行版自带的服务，配置放在 /etc/logrotate.conf 以及 /etc/logrotate.d/ 目录下。我们可以在 /etc/logrotate.d/nginx 新建一个针对 Nginx 日志的轮转规则：

# Nginx 日志轮转规则：每天切割一次，保留 30 天
/var/log/nginx/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        nginx -s reopen 2>/dev/null || true
    endscript
}

这段规则的含义逐条解释：daily 表示每天切割一次，rotate 30 表示保留最近 30 份归档，compress 表示用 gzip 压缩旧日志，delaycompress 表示延迟到下一次轮转再压缩（避免压缩正在被 Nginx 写入的当前文件），missingok 表示文件不存在时不报错，notifempty 表示空日志不轮转，sharedscripts 配合 postrotate 在切割完成后统一执行一次 Nginx 日志重开命令。

nginx -s reopen 是 Nginx 提供的信号命令，作用是让 Nginx 重新打开日志文件描述符。因为 Nginx 一直持有旧文件的写句柄，如果只把文件改名而不重开句柄，Nginx 会继续往已经归档的旧文件里写，日志就”切不断”了。这一步是整个轮转能否生效的关键。

按大小切割与触发方式

有些站点的日志流量波动大，按天切割不够及时，更希望日志长到一定大小就自动切割。logrotate 用 size 指令来满足这种需求，它可以和周期指令一起使用，满足任意一个条件就触发：

# 按大小切割：日志超过 100M 就轮转，同时每天最多检查一次
/var/log/nginx/*.log {
    daily
    size 100M
    rotate 14
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        nginx -s reopen 2>/dev/null || true
    endscript
}

size 100M 表示当日志文件超过 100MB 时，即使还没到每天的执行点也会触发轮转。这里的 100M 是一个典型区间，你可以根据磁盘空间和日志增长速度调整成 50M 或 200M。

需要提醒的是，logrotate 本身是一个由 cron 定时触发的任务，默认每天执行一次。也就是说，size 的判断是在每天那次 cron 运行时进行的，而不是实时的。如果你的站点日志增长极快，希望更频繁的检查，可以把 logrotate 的执行周期从 daily 改成 hourly，或在 crontab 里手动安排执行时间。示例中数值均为占位，请按实际流量调整。

压缩与保留策略

归档日志建议启用压缩，文本日志的压缩率通常非常高。一个 500MB 的 access.log 用 gzip 压缩后往往只剩 30 到 50MB，能节省大量磁盘。这也是上面配置里 compress 的意义。如果希望压缩后更省空间，可以设置 compresscmd 为 bzip2 或 xz，但要注意解压速度会变慢，一般 gzip 就够用。

保留策略要结合业务对日志的审计需求来决定。常见做法是保留 14 到 30 天，满足日常排障和访问量统计即可。如果站点有合规要求需要留更久，可以把 rotate 调大，但要同步评估磁盘空间。一个简单评估方法：先看当前 access.log 一天增长多少，乘以保留天数，再加上压缩收益，就是日志占用的预估空间。

下面用一个脚本快速统计当前日志的增长情况，帮助你估算需要预留多少磁盘：

# 查看最近 24 小时内 access.log 增长了多少（示例，按实际路径调整）
ls -lh /var/log/nginx/access.log
# 用 du 查看日志目录总占用
du -sh /var/log/nginx/

示例中，如果 access.log 显示为 200M 而目录总共 1.2G，说明归档累积明显，需要检查轮转是否真的生效。如果磁盘持续紧张，可以参考香港服务器租用带宽选择攻略：共享带宽 VS 独享带宽详解，把日志存储与带宽（单位时间内能传输的数据量）规划放在一起评估。

验证轮转是否生效

配置写好后不能只看配置内容，要实际验证轮转是否按预期工作。logrotate 提供了试运行模式，不会真正改文件，只打印将要执行的操作：

# 试运行：只预览将要执行的轮转动作，不实际切割
logrotate -d /etc/logrotate.d/nginx
# 强制运行一次：立即切割并归档，忽略周期判断
logrotate -f /etc/logrotate.d/nginx

-d 是 debug 模式，-f 是 force 强制模式。验证时先跑 -d 确认规则解析正确，再跑一次 -f 看实际的切割结果。强制运行后到日志目录确认是否生成了带日期后缀的归档文件，以及 Nginx 是否重新打开了新的 access.log：

# 列出日志目录，查看归档文件与当前日志（示例路径）
ls -lh /var/log/nginx/
# 确认 Nginx 进程持有的是新日志句柄
head -1 /var/log/nginx/access.log

示例中，如果目录里出现类似 access.log-20260826.gz 的压缩归档，同时新的 access.log 只有少量新写入，说明轮转正常。如果归档文件没有按预期生成，多半是路径写错、postrotate 命令失败，或 cron 没有运行 logrotate。

如果日志排查时还想同时掌握站点整体访问与性能趋势，可以借助可视化监控把日志里的关键指标长期沉淀下来，影响美国 VPS（虚拟专用服务器）服务器速度的核心因素与优化指南提供了一套完整的优化思路。

常见问题与避坑

日志轮转的坑大多集中在”切了但没完全切”这一类，整理几个高频问题：

• 归档后日志仍在增长：几乎都是 postrotate 里的 nginx -s reopen 没生效，确认 Nginx 主进程名与命令路径正确。
• 磁盘依然吃紧：检查 compress 是否开启，以及 rotate 保留天数是否过多。
• 轮转把 error.log 漏掉：确认配置里的通配符 *.log 是否覆盖了 error.log，或单独为 error.log 写一条规则。
• 压缩后文件仍很大：检查是否因为 delaycompress 导致上一份归档还没压缩，等下一次轮转再看。

排查时先看 logrotate 的日志输出，多数发行版会写到 /var/lib/logrotate/status 或系统日志里。如果用的是共享主机或托管面板，很多面板默认只做基础轮转，需要确认底层是否允许自定义 logrotate 规则，没有的话只能靠面板自带功能或换支持自定义的环境。

总结与行动建议

总结一下，nginx 日志轮转与切割不是”配了就行”，按天切割、按大小触发、压缩与保留策略、postrotate 重开句柄这四个环节必须逐一验证，才能确认日志管理真正生效。对日志增长稳定的站点，建议优先用 daily + rotate 30 + compress 的组合；对流量波动大的站点，建议加上 size 触发，避免单日日志暴涨。

如果你需要一套可以直接套用的验证流程，建议先在你的测试环境里跑一遍上面的 logrotate -d 和 -f 命令，把归档文件、压缩率和磁盘占用记录下来，再决定保留天数和是否启用按大小切割。如果你正在用 Hostease 的海外 VPS（虚拟专用服务器）部署 WordPress，可以参考这篇外贸建站新手如何用 Hostease 海外 VPS 部署 WordPress，把日志轮转和建站流程一起落地。关于站点迁移时的日志与数据规划，也可以看看WordPress 网站高效迁移指南，把日志管理放到更大的运维框架里判断。总结来说，先验证再调优，是避免日志轮转白忙一场的最稳妥做法。