百万级qps下nginx日志需专项治理：单条约250–400字节，100万qps下月增近906tb，必须通过分级输出、实时压缩轮转、异步转存清理三项策略降载，并独立挂载/var/log/nginx配监控。
百万级 QPS 下，Nginx 日志不是“顺便写一下”的附属品，而是容量增长的主力来源之一——若不单独评估，/var/log 很快会撑爆根分区，触发 No space left on device，导致服务静默中断。
先算单请求日志体积
默认 Nginx log_format combined 每条访问日志约 250–400 字节（含 IP、时间、URI、状态码、响应大小、UA 等）。实际值取决于你是否开启 $request_time、$upstream_response_time、自定义变量或长 UA。建议实测：
- 取 1 秒真实日志片段：
tail -n 1000 /var/log/nginx/access.log | wc -c，再除以 1000 得平均字节数 - 若启用详细格式（如含 trace_id、body_size、geoip），单条可能达 800+ 字节
按 QPS 和保留周期反推月增容量
假设峰值 QPS = 1,000,000，单条日志均值 350 字节，日志保留 30 天：
- 每秒写入：1,000,000 × 350 B ≈ 350 MB/s
- 每日增量：350 MB/s × 86400 s ≈ 30.2 TB
- 30 天总量：≈ 906 TB
这显然不可行——说明必须做减法：压缩、采样、分离、归档。
必须落地的三项降载策略
不靠堆磁盘，靠设计收敛日志规模：
-
分级日志输出：核心接口（如支付回调）走完整日志；静态资源（js/css/img）、健康检查（/health）、CDN 回源等路径用
access_log off或极简格式 -
实时压缩 + 轮转：用
gzip压缩归档（logrotate 配置compress+delaycompress），通常可压至原始体积 10–15% -
异步转存 + 清理：用
rsyslog或filebeat将日志实时推送至对象存储（如 S3/OSS）或日志平台（ELK/Splunk），本地只保留最近 24–72 小时热数据
分区与监控要配套设置
/var/log/nginx 必须独立挂载（不要混在 / 下），初始建议 200–500 GB，并设两级监控阈值：
- 75% → 触发告警，检查是否有异常爬虫或 debug 日志未关闭
- 90% → 自动清理最旧压缩包（
find /var/log/nginx -name "*.gz" -mtime +3 -delete）
同时禁用 tmpfs 挂载日志目录——内存溢出比磁盘满更致命。
