nginx 不直接统计丢包率和 tcp 重传次数，需通过 error.log/access_log 异常（如 upstream timed out、client closed connection）、node_exporter 指标（tcp_retranssegs、udp_inerrors）及 grafana 日志—指标联动分析实现三层关联观测。
Nginx 本身不直接暴露网络丢包率和 TCP 重传次数，但可以通过日志信号 + 系统指标 + Grafana 联动查询实现丢包与重传的关联分析。关键不是让 Nginx “统计丢包”，而是用它的错误模式、连接行为和系统层数据交叉印证。
从 Nginx 日志中识别丢包诱发的异常行为
Nginx error.log 和 access_log 中的特定条目，是丢包在网络应用层最直接的“回声”：
- 出现大量
"upstream timed out (110: Connection timed out)"：说明后端响应迟迟未达，可能因中间链路丢包导致 SYN/ACK 或首包丢失； - 频繁
"client closed connection while waiting for upstream"：客户端因长时间无响应主动断连，常见于移动/WiFi 切换时 ACK 丢失引发重传失败； -
"recv() failed (104: Connection reset by peer)"或(111: Connection refused)集中爆发：可能对应内核因队列满或校验失败主动丢弃连接； - access_log 中
$upstream_connect_time > 500ms且$upstream_response_time == "-"：建连阶段耗时异常，高度提示 SYN 重传或 TLS 握手包丢失。
这些日志项可被 Promtail 采集进 Loki，并打上 host, upstream, status_code 等标签，便于后续与 Prometheus 指标对齐时间戳和维度。
在 Grafana 中联动展示丢包相关系统指标
真正反映丢包与重传的原始数据在操作系统内核层面。需通过 Prometheus 抓取并可视化：
- 使用
node_exporter的node_netstat_Tcp_RetransSegs（TCP 重传段数）和node_netstat_Udp_InErrors（UDP 入错，对 HTTP/3 QUIC 重要）； - 用
ss -i提取的连接级指标（需 eBPF 或自定义 exporter）：retrans,qloss,rto字段，可聚合为每秒重传次数、平均队列丢包率； - 若启用 HTTP/3，Netdata 的
quiccollector可读取/proc/net/snmp6中UdpLiteInCsumErrors等字段，间接反映 QUIC 层校验失败与丢包； - 在 Grafana 中用 LogQL 查询 Loki 日志（如
{job="nginx"} |~ "upstream timed out"），再点击右上角 “Explore with Metrics”，自动跳转到同一时间范围的node_netstat_Tcp_RetransSegs曲线，实现日志—指标双向下钻。
构建丢包—重传—服务影响三层关联看板
避免单看数字，聚焦因果链条：
-
第一层（网络层）：折线图并列显示
rate(node_netstat_Tcp_RetransSegs[1m])和rate(node_netstat_Udp_InErrors[1m])，标注突增时间点； -
第二层（Nginx 行为层）：叠加
count_over_time(nginx_error_log_lines{level="error", msg=~".*timed out.*"}[5m])，观察是否与重传峰值同步； -
第三层（业务影响层）：在同一图表下方叠加
rate(nginx_http_requests_total{code=~"5.."}[1m])和histogram_quantile(0.99, rate(nginx_vts_server_request_seconds_bucket[1m]))，确认丢包是否已传导至 5xx 错误或长尾延迟。
所有图表统一设置时间范围为 Last 15 minutes，刷新间隔 10s，确保可观测性闭环及时生效。
不复杂但容易忽略——丢包本身不可见，但它留下的痕迹处处可查。
