将 limit_req_log_level 从 error 调低可缓解高频限流日志压力：拒绝记 warn，延迟记 info；仅作用于 limit_req 触发的限流，不影响其他 error log；推荐常态设 notice（降日志量超 90%），突发设 warn（降 60–70%），并配合单独日志路径、logrotate 及监控指标验证。

直接把 limit_req_log_level 从默认的 error 调低，就能显著缓解高频限流时的日志写入压力——它不减少日志条数，但能避免大量高优先级日志刷爆磁盘和日志服务。

明确作用范围：只管“被限流”的动作，不管其他日志

这个指令专用于 limit_req 模块触发的两类行为：

• 请求被直接拒绝（超出 burst 且无缓冲）→ 记为设定级别（如 warn）
• 请求被延迟处理（进入 burst 队列等待）→ 默认记为低一级别（如设 notice，延迟就记 info）
• 它不影响 access log、upstream 超时、SSL 握手失败等其他 error log，也不控制是否记录，只控制日志级别

按场景选合适级别：拒绝用 warn，常态限流用 notice

高频限流下，error 级日志容易被误判为故障，也加重磁盘 I/O。推荐分级设置：

• 突发流量但整体可控（如秒杀预热）→ 设 limit_req_log_level warn：保留可查痕迹，日志量下降约 60–70%
• 常态化配额限流（如 API 每分钟 100 次）→ 设 limit_req_log_level notice：仅表示“发生了限流”，不视为异常，日志量下降超 90%
• 调试归因阶段 → 临时设 info，再配合 limit_req_status 429 和自定义 log_format 把状态码和限流 key 写进 access log，避免 error log 混杂

配合隔离与轮转：单独存、轻量写、及时切

单靠调级别不够，还得从落地方式上减负：

• 为限流日志单独配置路径，例如：error_log /var/log/nginx/limit_rej.log warn;，彻底避开主 error.log
• 在 log_format 中加入 $limit 和 $limit_key 变量，便于后续聚合分析（需启用 limit_req_status）
• 用 logrotate 对限流日志做高频轮转，比如 hourly + maxsize 10M，防止单文件过大阻塞写入

验证与灰度：看日志、测指标、盯监控

上线前必须确认效果真实生效，且不掩盖真实问题：

• 用 ab 或 wrk 压测超限请求，检查目标日志文件是否只出现 warn/notice 行，主 error.log 不再新增限流记录
• 先在单台边缘节点灰度，观察磁盘 write wait、日志服务 CPU、ES ingestion rate 是否明显下降
• 配套在监控中增加 “429 响应数 / 秒” 指标（从 access log 抽取），替代依赖 error log 做限流统计