$upstream_bytes_received 单一数值无法判断tcp集群流量健康度，需结合连接上下文、时间窗口及对比维度；它是stream模块内置变量，仅表单次连接接收字节数，值为“-”表示连接失败，须与$remote_addr等联用才具归因价值。
直接用 $upstream_bytes_received 单一数值无法判断 TCP 集群流量健康度，它只反映从后端接收的字节数，必须结合连接上下文、时间窗口和对比维度才能识别异常。
明确变量作用与限制
$upstream_bytes_received 是 ngx_stream_proxy_module 提供的内置变量，仅在 stream 块中有效，表示本次 TCP 连接中从 upstream 服务器实际收到的数据总字节数。它的关键特性包括：
- 值为“-”表示连接未成功建立或中途断开，未收到任何数据
- 单次连接日志中只记录一个汇总值，不区分包、不分段
- 不体现速率、突增/突降、方向失衡（如发多收少）等健康信号
- 需与
$remote_addr、$upstream_addr、$session_time同时采集才有归因意义
构建可分析的流量健康指标
仅看字节数没意义，要转化为可比、可告警的健康维度：
-
连接级吞吐率：用
$upstream_bytes_received / $session_time（单位：B/s），识别低速长连接（如僵尸连接）或高速短连接（如扫描行为） -
收发比异常：若同时记录
$upstream_bytes_sent，计算$upstream_bytes_received / $upstream_bytes_sent；比值持续 ≪ 1 可能表明后端响应截断、协议错乱或被限流 -
空响应占比：统计
$upstream_bytes_received = 0且$session_time > 0.5的连接比例，高占比提示后端无响应或协议握手失败 -
节点级流量离散度：按
$upstream_addr分组，计算各后端平均$upstream_bytes_received的标准差 / 均值；离散度过高说明负载不均或部分节点静默
日志配置与落地建议
确保日志格式能支撑上述分析：
- 在
stream { }块顶层定义：log_format tcp_flow '$time_iso8601|$remote_addr:$remote_port|$upstream_addr|$session_time|$upstream_bytes_sent|$upstream_bytes_received'; - 在
server { }块中启用：access_log /var/log/nginx/tcp-flow.log tcp_flow; - 避免高频小连接导致日志爆炸：可加条件过滤，例如只记录
$session_time > 1或$upstream_bytes_received > 1024的连接 - 配合 Prometheus +
nginx-lua-module实现实时指标聚合，比纯日志解析更轻量、低延迟
典型异常模式识别
从聚合结果中关注这几类信号：
- 某后端
$upstream_bytes_received持续为 0，但连接数正常 → 后端进程存活但未写数据（如卡死、阻塞、配置错误） - 整体平均
$upstream_bytes_received / $session_time突降 50%+，且$upstream_bytes_sent不变 → 后端返回内容大幅缩水（如接口逻辑变更、缓存击穿） - 大量连接
$upstream_bytes_received = 0且$session_time → 可能是探测、扫描或 TLS 握手失败 - 同一
$upstream_addr下，$upstream_bytes_received分布出现双峰（如集中于 0 和 1MB，缺少中间值）→ 后端存在响应路径分裂（如主从不一致、路由策略异常）
