限流日志刷盘瓶颈的根源是limit_req模块默认以error级别强制刷盘，应通过limit_req_log_level降级（warn/notice）、隔离日志路径、启用burst缓冲及logrotate轮转综合治理。
限流日志刷满磁盘 I/O，根本原因不是日志内容多，而是每条限流记录都以 error 级别强制刷盘。limit_req_log_level 的核心价值，就是把“被限流”这件事的日志级别降下来，让高频拒绝不再挤占磁盘写入通道。
它只管“被限流”的那一行，不管别的
这个指令作用范围非常明确：
- 仅影响
limit_req模块自身产生的日志（即请求因超速被延迟或拒绝时的记录） - 不改变 access log 内容、格式或是否写入
- 不影响其他 error log 条目（如 upstream 超时、SSL 握手失败、配置错误）
- 不控制“是否记录”，只控制“记到哪一级”：默认
error，可设为warn、notice、info
按业务场景选 warn 还是 notice
级别选择不能拍脑袋，得看限流行为在你系统里算不算“异常”：
- 突发但临时的高峰（如秒杀开场、灰度放量）→ 设
limit_req_log_level warn：保留可查痕迹，日志量比 error 下降约 60–70%，error.log 中仍可见限流条目，但监控系统不会误报故障 - 常态化配额策略（如 API 每小时 1000 次）→ 设
limit_req_log_level notice：仅表明“发生了限流”，不视为异常，日志量下降超 90%，error.log 几乎不新增限流行 - 调试归因阶段 → 可临时设
info，但必须配合limit_req_status 429和自定义 access log 格式，把限流状态落进 access 日志，避免 error.log 混杂低价值信息
单改级别不够，必须隔离 + 轮转 + 缓冲
即使设成 notice，高频限流下日志文件本身也会快速膨胀，反而引发写阻塞或磁盘撑爆：
- 单独配置限流日志路径：
error_log /var/log/nginx/limit_rej.log warn;，避免污染主 error.log - 在
log_format中加入$limit和$limit_key变量（需开启limit_req_status），方便后续用 awk 或 Prometheus 抓取分析 - 用
logrotate对限流日志做高频轮转，例如配置hourly+maxsize 10M，防止单文件过大导致 open()/write() 阻塞 - 去掉
nodelay，改用burst缓冲排队：Nginx 对“延迟”日志默认比“拒绝”低一级（如设notice，延迟记info），天然减少高优先级日志输出；加了nodelay就等于放弃缓冲，所有超限请求立刻拒绝，全部打你设的高级别日志
上线前必须验证三件事
调优后不能只看日志文件有没有新内容，要确认真实效果：
- 用
wrk -t2 -c100 -d10s http://your-api/login模拟超限请求，观察limit_rej.log是否只出现warn或notice行，且主error.log不再新增限流记录 - 执行
iostat -dx 1，对比调优前后w/s（每秒写次数）和%util（设备使用率）是否明显回落（典型下降 30–50%） - 监控指标改用从 access log 抽取的 “429 响应数 / 秒”，而非依赖 error log 统计 —— 更稳定、更语义化，也避免日志解析成为瓶颈
