limit_req_log_level 的核心作用是调控被拒绝请求写入 error log 的级别以控制信噪比；仅对触发限流规则而被拒绝的请求生效，不影响 access log 或正常请求；常见值包括 error（默认）、warn、info/debug（排查用）、off（静默限流）；支持按 zone 分级设置，并需配合 stub_status、access log 变量或 prometheus 等手段补足可观测性。
limit_req_log_level 的核心作用不是开启或关闭限流日志，而是决定“哪些被拒绝的请求值得记进 error log”——它直接调控限流日志的信噪比。
理解 log level 与触发条件的对应关系
该指令只对 被拒绝（rejected）且已触发限流规则 的请求生效。它不控制 access log，也不影响正常通过的请求日志。
常见取值及实际效果：
- error：默认值。每次限流拒绝都写一条 error 级别日志，高频限流时 error log 迅速膨胀，掩盖真正异常
- warn：降低优先级，适合想保留拒绝痕迹但避免刷屏的场景；需确保 warn 级别未被日志系统过滤
- info 或 debug：仅建议在临时排查策略误伤时启用，生产环境慎用——容易淹没关键信息，且 debug 可能因日志级别配置被静默丢弃
配合 limit_req_status 实现“静默限流”
高并发下，大量 503 日志本身就成了性能干扰源。可通过组合配置让拒绝更“安静”：
- 将 limit_req_log_level info 与 limit_req_status 429 配合使用，把拒绝语义转移到 HTTP 状态码，便于客户端识别，同时避免 error log 泛滥
- 若业务可接受无状态拒绝，甚至可设为 limit_req_log_level off（Nginx 1.13.10+ 支持），完全不记录拒绝事件——此时需依赖监控指标（如 stub_status 或 Prometheus exporter）观测限流发生频次
按 zone 精细化设置，避免一刀切
不同限流区域关注点不同，应分而治之：
- 对登录接口（
zone=login burst=5）：设 limit_req_log_level warn，便于发现暴力尝试，又不污染主日志流 - 对静态资源（
zone=static burst=100）：设 limit_req_log_level error 或更低，因突发流量常见，拒绝属预期行为，无需每条上报 - 对内部健康检查路径（
location /health）：用 limit_req off 或独立 zone + limit_req_log_level crit，确保探测失败才告警
验证与可观测性补位
调低日志级别后，必须通过其他手段确认限流是否按预期工作：
- 启用 stub_status 或集成 nginx-module-vts，实时查看各 zone 的 dropped/rejected 数值
- 在 access log 中添加 $limit 和 $limit_key 变量（需 patch 或使用 OpenResty），标记哪些请求被限、依据哪个 key
- 用 Prometheus + nginx-exporter 抓取
nginx_http_requests_total{limit="dropped"}类指标，建立限流率基线与告警
