Nginx日志切割不管理磁盘配额，需logrotate协同控制：归档目录须独立挂载、显式配置olddir；保留策略应设rotate 15、compress+delaycompress、maxsize 100M；postrotate中加入磁盘空间检查与清理逻辑，并确保通过kill -USR1或nginx -s reload重开日志释放句柄。
nginx 日志切割本身不直接管理磁盘配额，归档目录的空间控制依赖外部机制协同实现。关键在于：logrotate 负责轮转与压缩，而空间释放是否及时、归档目录是否受控，取决于三件事——是否通知 Nginx 重开日志、归档路径是否独立且可监控、是否设置合理的保留策略+定期清理逻辑。
归档目录必须与主日志目录分离
默认配置（如 /var/log/nginx/*.log）会把压缩后的归档文件（如 access.log-20260819.gz）留在原目录，长期积累仍会撑爆同一分区。正确做法是显式指定归档路径：
- 在 logrotate 配置中不用默认行为，改用
olddir /data/nginx_logs/archive/ - 确保该目录挂载在独立磁盘或 LVM 逻辑卷上，便于单独设限
- 提前创建目录并赋权：
mkdir -p /data/nginx_logs/archive && chown nginx:adm /data/nginx_logs/archive
用 logrotate 精确控制保留数量与压缩行为
仅靠 rotate 30 不够——如果归档文件未压缩，30 个原始日志可能占几十 GB；若开启压缩但没加 delaycompress，当天日志可能被立即压，导致无法实时排查。推荐组合：
-
rotate 15：保留最近 15 天归档（按天轮转） -
compress+delaycompress：旧日志压缩，但“昨天”的先不压，方便紧急查 -
maxsize 100M（可选）：单个日志超 100MB 提前触发切割，防突发流量打爆磁盘 -
prerotate+postrotate中加入空间检查脚本（见下条）
主动监控与强制清理归档目录
logrotate 不校验磁盘余量，需额外防护。可在 postrotate 段嵌入空间判断逻辑：
- 示例脚本片段（放入 logrotate 配置的
postrotate ... endscript内）：
/bin/bash
ARCHIVE_DIR="/data/nginx_logs/archive"
THRESHOLD=90 # 占用超 90% 触发清理
USAGE=$(df "$ARCHIVE_DIR" | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
find "$ARCHIVE_DIR" -name "*.gz" -mtime +7 -delete 2>/dev/null
logger "WARN: $ARCHIVE_DIR usage $USAGE%, cleaned logs older than 7 days"
fi- 也可用宝塔计划任务或 systemd timer，每天凌晨运行
du -sh /data/nginx_logs/archive+ 邮件告警
删除后空间不释放？一定是 Nginx 还握着句柄
常见于手动 rm access.log 或 logrotate 未发信号。必须确保配置含有效 reopen 指令：
- 检查 pid 文件路径是否真实存在（
/var/run/nginx.pid或/usr/local/nginx/logs/nginx.pid） - 使用
kill -USR1是安全的，不中断连接；若失败，降级用nginx -s reload - 验证方式：
lsof -p $(cat /var/run/nginx.pid) | grep delete—— 若有输出，说明旧日志仍被占用
