nginx日志自动化归档应首选logrotate：需配置daily、missingok、rotate 30、compress、delaycompress、create 0644 nginx nginx及postrotate中kill -usr1，并强制验证-d/-f、添加执行日志、磁盘水位联动。
要打造高可用、自动化的工业级 Nginx 日志归档策略，核心不是堆砌工具，而是建立“可靠触发—安全轮转—可控留存—可追溯验证”四层闭环。logrotate 是当前最成熟、最稳定的选择，它被广泛用于生产环境（包括云厂商控制台底层），比自写脚本或 rotatelogs 更少出错、权限更清晰、压缩与清理语义更明确。
选对工具：优先用 logrotate，而非 rotatelogs 或自写脚本
rotatelogs 虽支持时间戳命名和管道直连，但存在隐性风险：依赖 nginx worker 进程持续向管道写入，一旦管道阻塞或权限异常（如 SELinux 限制 /dev/stdout），日志会静默丢失；且不提供压缩、过期清理等运维必需能力。自写脚本加 crontab 容易在 mv + reopen 时因并发或路径错误导致日志中断或句柄残留。logrotate 原生支持原子重命名、create 权限重建、USR1 安全重载、delaycompress 避免当日日志被锁死压缩，是工业场景事实标准。
配置必须包含的六个关键项
在 /etc/logrotate.d/nginx 中，以下配置缺一不可：
- daily：按天轮转，兼顾可读性与文件粒度
- missingok：避免某天无访问导致报错中断后续任务
- rotate 30：保留 30 个归档（即 30 天），满足常见审计与回溯需求
- compress + delaycompress：旧日志自动 gzip，但最新一轮不压，便于紧急排查
- create 0644 nginx nginx：轮转后立即重建日志文件，并确保属主、权限正确（防止 403 写入失败）
- postrotate … endscript：必须用 kill -USR1 $(cat /var/run/nginx.pid) 通知 Nginx 重新打开日志，不可省略或替换成 reload
增强可用性的三项实操加固
仅配好文件还不够，需从执行层加固稳定性：
- 强制验证机制：每次上线新配置，运行 logrotate -f -d /etc/logrotate.d/nginx（-d 查看调试过程，-f 强制执行），确认输出中含 “renaming … to …”、“compressing …”、“running postrotate script” 等关键动作
- 状态可观测：在 postrotate 段末尾追加日志记录，例如：echo "$(date): log rotated" >> /var/log/nginx-rotate.log，便于故障时快速定位是否执行成功
- 磁盘水位联动（可选但推荐）：在 crontab 中添加前置检查，例如每天 00:05 执行：[ $(df /var/log | awk 'NR==2 {print $5}' | sed 's/%//') -gt 85 ] && logrotate -f /etc/logrotate.d/nginx，实现空间告警触发紧急轮转
多站点/多路径场景下的统一管理
当有数十个站点或日志分散在不同路径（如宝塔的 /www/wwwroot/*/logs/）时，避免为每个站点单独建配置。推荐做法是：
- 用通配路径覆盖全部，例如：/www/wwwroot/*/logs/*.log { ... }
- 若需差异化策略（如 API 站点保留 90 天、静态站保留 7 天），则拆分为多个独立配置文件，如 /etc/logrotate.d/nginx-api 和 /etc/logrotate.d/nginx-static，logrotate 会依次加载
- 所有配置均启用 sharedscripts，确保多个日志文件共用同一段 postrotate，避免重复发信号
