怎么在 Nginx 中监控反向代理请求的成功率-Nginx-PHP中文网

nginx不直接提供成功率指标，需通过配置log_format记录$upstream_http_status，并结合日志分析或监控系统（如prometheus、elk）统计2xx/3xx响应占比；注意区分$upstream_http_status（后端状态）与$status（nginx自身状态），避免误判超时、连接失败等边界情况。

怎么在 nginx 中监控反向代理请求的成功率

Nginx 本身不直接提供“成功率”这个聚合指标，但可以通过组合标准模块、日志分析和简单计算得出反向代理请求的成功率（即后端响应状态为 2xx/3xx 的请求占比）。关键在于准确识别哪些请求是经由反向代理发出的，并区分其后端响应状态。

确保反向代理请求可被识别

Nginx 默认不会在 access_log 中记录上游响应状态码（upstream status），需显式启用：
在 location 或 server 块中配置：

proxy_pass http://backend;
proxy_set_header Host $host;
# 关键：透传上游响应状态码到日志变量
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
                         '"$request" $status $body_bytes_sent '
                         '"$http_referer" "$http_user_agent" '
                         'upstream_status:$upstream_http_status '
                         'upstream_addr:$upstream_addr '
                         'upstream_response_time:$upstream_response_time';
access_log /var/log/nginx/proxy_access.log upstream_log;

$upstream_http_status 记录真实后端返回的状态码（如 200、502、504）
$status 是 Nginx 自身返回给客户端的状态（如 502 表示代理失败，200 表示成功透传）
✅ 推荐同时记录两者，便于交叉验证（例如：$status=502 且 $upstream_http_status=-，说明后端不可达）

统计成功率的两种实用方式

实时粗略统计（命令行快速查看）

# 统计最近1万行中 upstream_status 为 2xx/3xx 的比例
tail -n 10000 /var/log/nginx/proxy_access.log | \
  awk '{match($0, /upstream_status:([0-9]+)/, arr); if (arr[1] ~ /^2|^3/) c++} END {print "Success Rate:", (c/NR)*100 "%"}'

长期可观测方案（推荐）

Nginx Hosting
通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载
- 将日志接入 ELK（Elasticsearch + Logstash + Kibana）或 Grafana + Loki
- 在查询中定义成功率指标：
```
# 如果用 Prometheus + nginx-exporter（需支持 upstream 指标）
100 * sum(rate(nginx_upstream_responses_total{code=~"2..|3.."}[1h])) 
/ sum(rate(nginx_upstream_responses_total[1h]))
```
- 或在 Kibana 中创建可视化：
  - 过滤字段：upstream_status:*
  - 计算：count(upstream_status: 2*) + count(upstream_status: 3*) ÷ total count

注意容易误判的边界情况

upstream_status 为空或 -，通常表示连接失败（超时、拒绝、DNS 解析失败），应计入失败
502 Bad Gateway、504 Gateway Timeout 是典型的代理层失败，对应 upstream_status 缺失或异常，需单独归类
若后端返回 304 Not Modified，属于合法成功响应，应纳入成功率分母和分子
避免仅用 $status 计算——它反映的是 Nginx 自身响应，不是后端真实结果（例如缓存命中返回 200，但未真正转发请求）

补充建议：主动探测辅助验证

对关键 upstream，配合健康检查：

upstream backend {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

结合 nginx -t && nginx -s reload 后观察 upstream_addr 是否持续切换或出现 *.*.*.*:port *.*.*.*:port（表示 fallback 到 backup），可佐证成功率下降是否源于节点失效。

不复杂但容易忽略