日志轮转失效的常见信号
Linux 服务器运行时间一长，Nginx、PHP、MySQL、应用程序和系统服务都会不断写日志。正常情况下，logrotate 会按天、按周或按文件大小把旧日志切分、压缩、删除，让日志目录保持在可控范围内。可一旦轮转失效，最先出现的往往不是明显报错，而是磁盘空间突然下降、某个日志文件异常变大，甚至服务因为无法继续写入日志而表现出卡顿或启动失败。
排查这类问题时，不要一上来就删除大文件。更稳妥的做法是先确认是哪类日志增长、轮转任务有没有执行、配置条件是否真的满足，再决定清理、修复配置还是调整保留策略。尤其在生产环境里，日志可能还承担审计、故障回溯和安全分析作用，直接清空会让后续定位变得更困难。
先确认磁盘和大文件位置
第一步先看整体空间，而不是只盯着某一个目录。可以用 df -h 查看分区占用，确认是根分区、数据盘还是单独挂载的日志分区接近满载。接着用 du -sh /var/log/* 或针对站点目录执行 du -sh /www/wwwlogs/*，找出真正占空间的目录和文件。
如果发现单个 access.log、error.log 或应用日志已经达到数 GB，说明轮转策略可能没有生效，也可能是业务流量、爬虫访问或异常报错突然增多。此时建议记录文件路径、大小、修改时间和所属服务，再进入下一步，不要为了立刻释放空间就直接 rm。
检查 logrotate 是否真的在执行
logrotate 通常由 cron 或 systemd timer 定时触发。不同发行版略有差异，可以先检查 /etc/cron.daily/logrotate 是否存在，再用 systemctl status logrotate.timer 或 systemctl list-timers | grep logrotate 查看定时器状态。如果定时任务本身没有运行，配置写得再正确也不会生效。
还可以手动执行一次调试模式：logrotate -d /etc/logrotate.conf。这里的 -d 只模拟不真正轮转，适合先看它会读取哪些配置、哪些文件被匹配、为什么跳过。若需要在维护窗口强制测试，可以使用 logrotate -f /etc/logrotate.conf，但强制轮转会真实改动日志文件，生产环境要提前确认影响。
配置文件最容易错在哪里
logrotate 的主配置通常在 /etc/logrotate.conf，各服务独立配置多在 /etc/logrotate.d/。常见错误包括日志路径写错、通配符没有匹配到实际文件、权限不足、花括号格式错误、脚本段里的命令失败，以及 size、daily、weekly 等条件和预期不一致。
例如配置里写的是 /var/log/nginx/*.log，但实际面板或站点把日志放在 /www/wwwlogs/，logrotate 就根本不会处理这些文件。再比如设置了 weekly，但你以为它每天都会切分；设置了 missingok 可以忽略不存在的文件，却掩盖了路径写错的问题。排查时要把配置路径、实际日志路径和调试输出三者对起来看。
轮转后服务没有重新打开日志
有些服务在日志文件被重命名后，不会自动切换到新文件继续写入。如果配置里缺少 postrotate 脚本，服务可能仍然把内容写进已经被轮转的旧文件句柄里，表面上看新日志没有增长，实际磁盘空间却没有释放。Nginx 常见做法是在 postrotate 中执行 nginx -s reopen 或向主进程发送重新打开日志的信号。
这也是为什么删除一个大日志文件后，df -h 显示空间没有释放：进程还占着已删除文件的句柄。可以用 lsof | grep deleted 查看是否存在这类情况。正确处理通常是让对应服务重新打开日志或平滑重启，而不是继续删除更多文件。
压缩、保留天数和磁盘策略
轮转不只是切分文件，还要考虑保留多少份、是否压缩、延迟压缩和空文件处理。常见配置包括 rotate 7、compress、delaycompress、notifempty、dateext。如果站点访问量很大，只按天轮转但不按大小限制，单日日志仍可能撑爆磁盘；如果保留周期过长，压缩包累计也会占用大量空间。
比较稳妥的策略是根据业务访问量设置双重约束：既按周期轮转，也用 size 或 maxsize 限制单文件上限。对普通网站来说，访问日志可以保留 7 到 30 天，错误日志和安全相关日志视合规要求适当延长。日志量很大的业务可以考虑集中采集到日志平台，服务器本地只保留短周期文件。
临时清理时要避开两个坑
如果磁盘已经接近 100%，需要先释放少量空间让系统恢复写入能力。比起直接删除当前正在写的日志，更建议先处理历史压缩包、旧轮转文件或明确不再需要的归档文件。对当前日志，可以用 : > file.log 截断文件，但前提是确认这个文件确实可以清空，并且不会破坏正在进行的排障。
另一个坑是把问题归咎于“服务器空间太小”，然后只扩容不修配置。扩容可以缓解短期压力，但如果 logrotate 仍然没有执行，新的空间迟早还会被打满。使用 速维云云服务器 承载网站或业务系统时，也建议把日志目录、备份目录和站点上传目录分开规划，方便后续判断空间增长来自访问日志、业务数据还是备份文件。
一套安全的排查顺序
实际处理时，可以按这个顺序走：先用 df -h 确认哪个分区满；再用 du 找到大目录和大文件；然后用 logrotate -d 验证配置是否匹配；接着检查 cron 或 systemd timer 是否执行；最后确认服务在轮转后是否重新打开日志。如果需要清理，只清理确认无用的历史文件，并保留关键报错线索。
修复完成后，建议观察至少一个轮转周期，确认新日志按预期生成、旧日志被压缩或删除、磁盘占用没有继续异常增长。日志轮转看起来只是小配置，但它直接影响服务器稳定性、故障排查效率和业务连续性。把这件事配置好，比等磁盘满了再抢救要省心得多。
