Nginx不直接提供成功率指标，需通过配置log_format记录$upstream_http_status，并结合日志分析或监控系统（如Prometheus、ELK）统计2xx/3xx响应占比；注意区分$upstream_http_status（后端状态）与$status（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 "%"}' -
长期可观测方案（推荐）
- 将日志接入 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），可佐证成功率下降是否源于节点失效。
不复杂但容易忽略
