$upstream_status 是 Nginx 记录上游服务真实 HTTP 状态码的关键变量，用于精准告警、实例级故障定位及与主动健康检查交叉验证。
$upstream_status 是 Nginx 反向代理场景中非常关键的变量，它记录了上游（后端）服务返回的真实 HTTP 状态码，比如 502、503、504 等。与 $status（Nginx 自身响应状态）不同，$upstream_status 能真实反映后端健康状况，是构建精准后端故障告警的核心依据。
在 access_log 中透出 upstream_status 用于采集
确保 Nginx 日志格式中包含该变量，便于后续日志解析与指标提取：
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$upstream_addr $upstream_status $upstream_response_time';注意：$upstream_status 在请求未转发到上游（如 4xx 或 Nginx 自行拒绝）时为“-”，需在采集端过滤掉；正常转发失败时会显示如 503、504 等数字。
通过日志采集+时序分析识别 5xx 上游异常突增
使用 Filebeat / Fluent Bit 收集 access_log，将 $upstream_status 解析为字段（如 upstream_status），再写入 Prometheus + Loki 或 Elasticsearch：
- 在 Prometheus 中，可用 Promtail 的 JSON stage 提取该字段，并通过
metric_relabel_configs构建指标，例如：upstream_status_count{upstream_status="503", job="nginx"} 127 - 配置 PromQL 告警规则，聚焦“短周期内 5xx 上游错误率显著上升”：
rate(upstream_status_count{upstream_status=~"5.."}[5m]) / rate(upstream_status_count[5m]) > 0.05（即 5 分钟内上游 5xx 占比超 5%） - 避免误报：可叠加条件，如仅当总 upstream 请求量 ≥ 100 时才触发，排除低流量下的毛刺干扰
结合 upstream_addr 实现后端实例级故障定位
$upstream_status 总是与 $upstream_addr 成对出现，后者记录实际通信的后端地址（如 10.0.1.22:8080）。利用这对组合可下钻到具体实例：
- 在 Grafana 中按
upstream_addr分组，绘制各后端的5xx 错误率热力图或503/504 单独计数趋势 - 告警时在 Alertmanager 的 annotations 中注入：
summary: "Upstream {{ $labels.upstream_addr }} returning {{ $value | humanize }}% 5xx" - 配合服务发现（如 Consul/Nacos），可自动标记该地址所属服务名、集群、机房，让告警自带上下文
补充验证：用 stub_status 或自定义 health_check 做交叉确认
$upstream_status 是事后响应结果，不能替代主动探测。建议叠加以下机制增强可靠性：
- 开启 Nginx
health_check指令（需 stream 或 http upstream 模块支持），对 upstream server 做 TCP/HTTP 健康检查，失败时自动摘除 - 在关键 upstream group 后配置
stub_status或自研 /health 接口，由巡检脚本定期调用并上报状态 - 当
$upstream_status连续出现 5xx 且对应 upstream 的主动探测也失败时，升级告警级别（如从“Warning”升为“Critical”）
