Nginx日志降本关键在于按需切分、分级压缩、智能清理：高频服务按小时切分（≤500MB/文件），低频服务按日切分；旧日志7天后压缩，30天后归档；精简log_format并过滤静态资源与敏感参数；实行阶梯式保留策略。
要让 Nginx 日志切割真正降低存储成本，不能只靠“切得勤”，关键是在保留必要审计信息的前提下，精准控制日志的生命周期、体积和冗余度。核心是三件事：按需切分、分级压缩、智能清理。
按访问频次与业务重要性选择切分粒度
高频服务（如 API 网关、登录入口）建议按小时切分，避免单日志超 500MB；低频后台服务（如管理后台、内部接口）用每日切分即可。粒度越细，单文件越小，但文件数量增多会增加 inode 消耗和检索开销——需权衡。
- 每小时切分示例：
access_log "|/usr/bin/rotatelogs -n 24 /var/log/nginx/api_access_%Y%m%d%H.log 3600" - 每日切分示例：
access_log "|/usr/bin/rotatelogs -n 30 /var/log/nginx/www_access_%Y%m%d.log 86400" - 错误日志建议独立配置、按天切分且保留更久（如
-n 90），因 error.log 体积小但排查价值高
启用带条件的压缩与延迟归档
不是所有旧日志都值得立即压缩。刚轮转的前 7 天日志访问频繁，应保持未压缩状态；7 天后自动压缩，30 天后可转存至对象存储或归档为 .tar.gz。
- logrotate 中启用
compress+delaycompress：首次轮转不压，下次轮转时才压缩上一轮 - 配合
minsize 10M：小于 10MB 的日志不压缩，避免小文件压缩反而增大体积 - 错误日志可禁用压缩（
nocompress），因其通常很小，解压开销大于收益
结合日志内容做源头减量
存储成本高，往往不是因为切得少，而是因为记了太多无用字段。在 log_format 中剔除非必要项，比后期压缩更高效：
- 移除重复字段：如同时记录
$http_x_forwarded_for和$remote_addr，若已启用 realip 模块，只需留$realip_remote_addr - 过滤静态资源：用
map指令对图片、CSS、JS 请求设空日志格式，或直接access_log off（在 location 块中） - 脱敏敏感参数：用
map $args $clean_args抹掉token=、password=等值，既合规又减少无效文本膨胀
设置阶梯式保留策略
不同日志类型、不同时间段，保留时长应差异化。例如：
- access 日志：最近 7 天明文 → 8–30 天 gzip 压缩 → 31–180 天仅保留状态码分布统计（通过定时脚本聚合）
- error 日志：全量保留 90 天，之后只留 warning 及以上级别
- 审计类日志（满足等保）：必须保留 180 天，但可用 WORM 存储+只读挂载，避免额外备份副本
实际落地时，推荐以 logrotate 为主干（稳定、信号安全），辅以简单 shell 脚本做周级聚合与冷备，不依赖复杂平台也能把存储成本压到合理水位。
