nginx不原生暴露limit_req/limit_conn拦截次数为prometheus指标,需通过日志解析(如nginxlog-exporter匹配“limiting requests”或“rejected”)或配置limit_req_status 429后利用nginx-module-vts导出code="429"计数器实现监控。

Nginx 本身不会直接暴露 limit_req 或 limit_conn 模块的拦截次数作为原生 Prometheus 指标。这些限流动作产生的统计信息(比如“被拒绝的请求数”)默认不被任何 Nginx 官方模块自动导出为 Prometheus 格式指标,需要额外手段采集。
要监控限流拦截次数,核心思路是:从 Nginx 日志中提取限流事件,再通过日志采集器(如 Prometheus Exporter 或 Loki + Promtail)转换为指标。以下是两种主流、可落地的方式:
直接采集限流日志生成 Prometheus 指标
Nginx 在触发限流时,会在 error log 中写入明确标识,例如:
2026/09/05 18:22:33 [error] 12345#0: *6789 limiting requests, excess: 5.123 by zone "one", client: 192.168.1.100, ...
或(被拒绝时):
2026/09/05 18:22:34 [error] 12345#0: *6790 limit_req zone "one" rejected, client: 192.168.1.100, ...
✅ 操作建议:
- 确保
error_log级别至少为warn(error_log /var/log/nginx/error.log warn;),否则limiting requests类日志可能被过滤掉; - 使用支持日志行匹配与计数的 exporter,例如:
-
nginxlog-exporter:配置正则匹配
limiting requests或rejected字样,自动生成nginx_log_lines_total{type="limit_req_rejected"}这类指标; -
Promtail + Loki + Grafana:用 LogQL 统计
|~ "limiting requests|rejected" | pattern "<_> limiting requests,.*zone "(?P<zone>\w+)""</zone></_>,再通过rate()聚合为每秒拦截数;
-
nginxlog-exporter:配置正则匹配
- 推荐在
http {}块中添加唯一标识,便于日志区分,例如:limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; # 启用时加日志前缀(非必须,但利于过滤) limit_req zone=api_limit burst=20 nodelay;
利用 nginx-module-vts(推荐,更精准)
如果你已采用 nginx-module-vts(当前阿里云推荐方式),它虽不直接暴露限流拦截数,但提供了一个关键替代路径:
- VTS 提供
nginx_vts_server_requests_total{code="503"}和nginx_vts_server_requests_total{code="429"}指标; - 只需将
limit_req_status 429;配置到对应 location,并确保limit_req触发时返回 429(而非默认 503),那么所有被限流拒绝的请求就会自动计入code="429"计数器中;
✅ 操作建议:
- 在 server 或 location 块中添加:
limit_req_status 429; limit_req_log_level warn; # 减少 error 日志干扰
- Prometheus 抓取 VTS 的
/status/format/prometheus接口后,即可直接查询:rate(nginx_vts_server_requests_total{code="429"}[5m])这就是真实生效的每秒限流拦截速率。
注意事项
- 不要依赖
nginx_http_requests_total的差值来反推拦截数——它只统计成功进入处理流程的请求,被limit_req拒绝的请求根本不会到达该计数器; -
limit_conn拒绝连接会记录server refused to accept connections,但同样需靠日志解析,VTS 不覆盖该场景; - 若使用 CDN,注意
$binary_remote_addr可能是代理 IP,应配合$http_x_forwarded_for和real_ip模块校准,否则日志和限流统计都会失真。
本质上,Nginx 限流拦截是前置拒绝行为,不在 HTTP 请求生命周期内,所以没有“内置指标”。可靠方案只有两个:日志解析,或统一归因到标准 HTTP 状态码并由 VTS/Stub Status 导出。











