企业级nginx日志切割需兼顾按日/小时切分、压缩归档、远程备份、过期清理、失败告警和执行审计，核心是“可追溯、可恢复、不丢日志、不占磁盘”。
企业级 Nginx 日志切割不能只靠 logrotate 简单轮转，需兼顾按日/小时切分、压缩归档、远程备份、过期清理、失败告警和执行审计 —— 核心是“可追溯、可恢复、不丢日志、不占磁盘”。
一、按时间精准切分：用 date + mv 替代 kill -USR1
直接发信号给 Nginx 虽快，但存在竞争风险（如多实例、reload 期间丢失日志）。推荐原子性重命名方式：
- 每日零点前，将
/var/log/nginx/access.log重命名为access.log-$(date -d 'yesterday' +\%Y\%m\%d) - 使用
mv -f+touch确保新日志文件存在且权限一致（继承原 owner:group 和 644 模式） - 切分脚本开头加锁（
flock -n /tmp/nginx_rotate.lock），防 crontab 多次并发执行
二、归档与压缩：zstd 优先，保留原始格式可查
企业环境日志量大，gzip 压缩率低、解压慢；zstd 在压缩速度/比率间更均衡（比 gzip 快 3–5 倍，体积小 15–20%）：
- 切分后立即执行：
zstd -T0 --rm access.log-20240520（-T0自动用满 CPU，--rm压缩完删原文件） - 归档目录结构建议：
/data/logs/nginx/archive/2024/05/20/access.log-20240520.zst，便于按路径做 HDFS/S3 同步或 rsync 推送 - 保留最近 7 天未压缩的原始日志（用于快速 grep / awk 调试），其余一律 zstd 归档
三、分级清理策略：按保留周期+磁盘水位双控
仅设固定天数（如 90 天）易导致磁盘突发打满。应叠加空间阈值强制干预：
- 每日清理前检查：
df -P /data | awk 'NR==2 {print $5}' | sed 's/%//'，若 ≥ 85%，则额外清理最老的 3 天归档 - 常规策略：
find /data/logs/nginx/archive -name "*.zst" -mtime +90 -delete，但加-print0 | xargs -0 -r rm更安全（防空格/换行名崩溃） - 清理动作写入独立日志：
/var/log/nginx/rotate-cleanup.log，记录删除文件数、释放空间、触发原因（超期 or 水位）
四、可观测与兜底：失败自动告警 + 手动回滚入口
生产脚本必须自带“自检”和“逃生通道”：
- 每次执行末尾校验：
ls -l /var/log/nginx/access.log | awk '{print $5}'是否为 0（空日志说明切分失败），失败则发钉钉/企业微信告警 - 归档目录每小时生成
LAST_SYNCED时间戳文件，监控脚本比对它是否停滞 > 2 小时 - 提供手动回滚命令别名：
nginx-rotate-rollback 20240520—— 自动解压当日 zst、mv 回原位置、重载 Nginx，5 秒内恢复
脚本不是越长越好，关键是每个环节有验证、有退路、有记录。把切分、归档、清理、告警串成闭环，再套上 cron + systemd timer 双触发，就是稳定的企业级方案。
