limit_req_log_level能缓解磁盘I/O压力，因其将高频限流日志从error降级为warn或notice，避免每条日志强制刷盘，显著降低write()系统调用频次。
limit_req_log_level 为什么能直接缓解磁盘 I/O 压力
高频限流（比如每秒上千次 429）触发时，Nginx 默认用 error 级别往 error.log 写日志，而 error 日志默认刷盘（flush on write），每次写都触发一次磁盘 write() 系统调用。在 SSD 上可能扛得住，在 HDD 或高负载云盘上，%util 很快飙到 95%+，iostat -x 里能看到大量 w/s 和高 await。这不是日志内容太多，而是写频次太高 —— limit_req_log_level 的作用，就是把这部分日志从 error 降成 warn 或 notice，让它们不挤占主错误日志的刷盘通道，同时降低采集系统（如 Filebeat）的解析压力。
该设成 warn 还是 notice？看你的限流性质
别一刀切设 notice，得看限流是否属于“业务可预期行为”：
- 突发流量但属临时态（如活动开抢、灰度放量）→ 设
limit_req_log_level warn：保留可追溯痕迹，日志量下降约 60–70%，error.log里仍可见限流条目，但不再被监控系统当成故障告警 - 常态化配额策略（如 API 每小时 1000 次）→ 设
limit_req_log_level notice：只记录“发生了限流”，不视为异常，日志量下降超 90%，error.log几乎不新增限流行 - 调试归因阶段 → 临时设
info，但必须配合limit_req_status把状态码打到access.log，否则error.log会混入大量低价值日志，反而干扰真实错误定位
单靠改日志级别不够，必须隔离 + 轮转
即使设成 notice，高频限流下日志文件本身也会快速膨胀，阻塞写入或撑爆磁盘。必须配套动作：
- 为限流日志单独配置路径：
error_log /var/log/nginx/limit_rej.log warn;，避免污染主error.log - 在
log_format中加入$limit和$limit_key变量（需开启limit_req_status），方便后续用awk或 Prometheus exporter 聚合分析 - 用
logrotate对/var/log/nginx/limit_rej.log配置hourly+maxsize 10M，防止单文件过大导致open()/write()阻塞
验证是否生效：别只看日志文件有没有内容
上线后最容易忽略的是验证方式 —— 不能只检查 limit_rej.log 是否有新行，要确认三件事：
- 用
wrk -t2 -c100 -d10s http://your-api/login模拟超限请求，观察limit_rej.log是否只出现warn或notice行，且error.log不再新增限流记录 - 执行
iostat -dx 1，对比前后w/s和%util是否明显回落（典型下降 30–50%） - 检查监控中 “
429响应数 / 秒” 指标（从access.log抽取）是否稳定上升，确保没因日志降级掩盖真实限流行为
真正难的是权衡：日志级别压太低，线上突发问题时连“哪类请求被限了”都查不到；压太高，磁盘先扛不住。关键不是追求零日志，而是让每条日志都有明确归因路径和处理 SLA。
