limit_req_log_level仅控制限流事件写入error log的日志级别，默认error，不统计频率；真实频率需通过解析error log中“limiting requests”行数及时序分布来监控。
limit_req_log_level 本身不记录频率，它只控制“什么级别下才把限流事件写进 error log”，真正反映触发频率的是 error log 中出现的限流日志行数和时间分布。
理解 limit_req_log_level 的作用范围
该指令决定 Nginx 在执行 limit_req 时，是否以及以何种日志级别（如 error、warn、notice）记录“请求被拒绝”事件。默认是 error，即每次触发限流，就会在 error log 中写一行类似：
它不统计、不聚合、不输出速率数字——只是“开关+日志等级”。要监控频率，必须配合日志采集与分析。
实时观察限流触发频次的常用方法
-
用 tail + grep 实时计数：运行
tail -f /var/log/nginx/error.log | grep "limiting requests" | awk '{print $1,$2,$3}'查看每秒/每分钟新增条目；加watch -n 1 'grep -c "limiting requests" /var/log/nginx/error.log'可粗略看累计总数变化 -
按分钟聚合统计：用
awk提取时间戳并分组计数，例如：awk '/limiting requests/ {print substr($2,2), $3}' /var/log/nginx/error.log | cut -d: -f1,2 | sort | uniq -c | sort -nr
输出形如123 05/20 14:22，表示该分钟内触发了 123 次限流 -
结合 logrotate 后分析历史日志：若 error log 按天轮转，可对
error.log.1.gz解压后做批量统计，识别高峰时段或异常周期
关联 worker 进程与限流行为的关键点
error log 中每行日志开头的 12345#0 表示 pid#thread_id，其中 pid 就是对应 worker 进程 ID。可通过以下方式定位：
- 用
ps aux | grep nginx查看当前 worker 进程 PID 列表 - 在日志中提取高频出问题的 PID，例如：
awk '/limiting requests/ {print $4}' /var/log/nginx/error.log | cut -d# -f1 | sort | uniq -c | sort -nr
若某 PID 出现远超其他 worker，说明该进程处理的请求更集中（可能因 upstream 分配不均、IP hash 偏斜或本地缓存热点） - 注意：Nginx 默认使用
worker_processes auto，各 worker 独立维护自己的 limit_req zone（除非显式配置shared内存区），所以不同 worker 触发限流的阈值和时机可能不同
增强可观测性的实用建议
- 将
limit_req_log_level设为warn或notice，避免冲刷 error log，便于与其他真正错误区分 - 在
log_format中加入$limit和$limit_rate变量（需开启limit_req_status并配合自定义响应头），让 access log 也携带限流上下文 - 用 Prometheus + nginx-lua-prometheus 或 OpenResty 的
resty.limit.count模块实现实时指标暴露，比解析日志更高效、低延迟 - 对高频限流 zone 设置多个不同粒度的 limit_req（如 per-ip + per-token），再通过不同 log_level 或不同 zone 名区分日志来源，便于归因
