直接调低 limit_req_log_level 是优化负载均衡限流日志写入频率、缓解磁盘 i/o 压力最轻量且精准的手段，它仅降低限流事件（delay/reject）的日志级别，不影响 access log 或其他 error log。
直接调低 limit_req_log_level 是优化负载均衡限流日志写入频率、缓解磁盘 I/O 压力最轻量且精准的手段——它不关闭限流日志，也不影响 access log 或其他 error log，只把“请求被延迟或拒绝”这一类事件的日志级别降下来，让高频限流不再刷爆 error.log。
明确它的作用边界
这个指令只控制 limit_req 模块自身产生的日志，也就是因速率限制触发的延迟（delay）或拒绝（reject）动作：
- 不改变 access log 的输出内容和频率
- 不影响 upstream 超时、SSL 握手失败等其他 error log
- 不决定是否记录，只决定记到哪一级：默认
error，可设为warn、notice、info - 设为
crit或更高无实际意义，因为限流本身不属于系统级严重故障
按业务场景选合适级别
不同流量特征下，对日志可观测性的要求不同，级别设置应匹配真实需要：
- 突发但可控（如秒杀开场、活动预热）→ 设
warn：保留关键追溯线索，日志量比error下降约 60–70% - 常态化配额策略（如 API 每分钟 100 次）→ 设
notice：仅表明“发生了限流”，不视为异常，日志量下降超 90% - 调试归因阶段 → 临时设
info，并配合limit_req_status 429在 access log 中标记状态码，避免 error log 混杂
配合 burst 和日志隔离进一步减压
单靠改日志级别还不够，需组合使用才能真正释放磁盘 I/O 压力：
- 去掉
nodelay，让超限请求先进burst队列排队处理——Nginx 对“延迟”日志默认比“拒绝”低一级（如设notice，延迟记info），天然减少高优先级日志 - 为限流日志单独配置路径：
error_log /var/log/nginx/limit_rej.log warn;，避免冲刷主error.log - 在
log_format中加入$limit和$limit_key变量，方便后续按 key 聚合分析（需开启limit_req_status并自定义响应码） - 用
logrotate对限流日志做高频轮转（如hourly + maxsize 10M），防止单文件过大阻塞写入
上线前必须验证效果
调优后要确认是否真正生效，且未掩盖真实问题：
- 用
ab或wrk模拟超限请求，检查目标日志文件是否只出现warn/notice行，主error.log不再新增限流条目 - 先在单台边缘节点灰度，观察磁盘
write wait、日志服务 CPU、ES ingestion rate 是否明显下降 - 监控中改用从 access log 抽取的 “429 响应数 / 秒” 指标替代 error log 统计，更稳定、更语义化
