准确绘制nginx带宽图表需区分出入方向、按业务路径归因、用rate()计算速率而非累计值；基于$bytes_sent/$bytes_received日志字段建模，在prometheus中用rate(nginx_http_response_size_bytes_total[1m])等指标计算b/s，grafana中组合展示实时带宽、qps及热力图，并联动分析吞吐量与带宽背离异常。
要准确绘制 Nginx 在 Grafana 中的服务器带宽流量与吞吐量图表，关键不是简单展示“总字节数”，而是区分出入口方向、按业务路径归因、并用速率而非累计值反映真实负载。Nginx 本身不直接暴露带宽指标，需通过日志字段或模块采集后建模计算。
从 access log 提取真实带宽数据
Nginx 的 $bytes_sent（响应体大小）和 $bytes_received（请求体大小，需开启 http_realip_module 或自定义 log_format 支持）是带宽计算的基础。推荐在 log_format 中显式包含：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $bytes_sent $bytes_received';- 若使用
nginx-prometheus-exporter，启动时加参数--nginx.export-metrics-from-log=true，它会自动将$bytes_sent解析为nginx_http_response_size_bytes_total等指标 - 注意：
$body_bytes_sent不含响应头，$bytes_sent包含完整响应（含 header），监控带宽应优先用后者
在 Prometheus 中建模带宽速率
带宽单位是“字节/秒”（Bps），必须用 rate() 计算，不能用 sum() 或 increase() 直接展示累计值：
- 出向带宽（下行）：
rate(nginx_http_response_size_bytes_total[1m])→ 单位为 B/s；除以 1024² 得 MB/s - 入向带宽（上行）：
rate(nginx_http_request_size_bytes_total[1m])（需 exporter 支持解析$bytes_received或$request_length） - 按 server 或 location 拆分：加
by (server)或by (location)，例如sum by (server)(rate(nginx_http_response_size_bytes_total[1m])) - 避免窗口过短（如 5s）导致毛刺，1 分钟窗口在多数场景下更稳且不失实时性
在 Grafana 中构建实用带宽视图
单值或折线图不足以反映带宽健康度，建议组合呈现：
- 顶部卡片：当前出向带宽（MB/s）+ 同比变化率（对比前 5 分钟均值）
- 主趋势图：双 Y 轴折线图，左轴为出向带宽（MB/s），右轴为 QPS（
rate(nginx_http_requests_total[1m])），观察“每请求平均带宽”是否异常升高 - 热力图：X 轴为时间（小时），Y 轴为
server或upstream，颜色深浅表示rate(nginx_http_response_size_bytes_total[1h])，快速识别带宽大户 - 慢带宽检测：叠加一个阈值线（如 80 MB/s），并配置告警规则——当连续 3 个周期超限且 QPS 未同步增长，提示可能存在大文件未走 CDN 或异常下载行为
补充说明：吞吐量 ≠ 带宽，但需联动看
吞吐量（QPS）反映处理能力，带宽反映网络承载压力。两者长期背离即暗示问题：
- QPS 稳定但带宽持续上升 → 可能是响应体变大（图片未压缩、JSON 返回冗余字段、视频直传未分片）
- 带宽稳定但 QPS 骤降 → 可能是连接被限速（
limit_rate）、SSL 握手失败增多、或客户端批量断连 - 两者同步突增 → 正常业务高峰；同步归零 → 需检查 upstream 是否全挂、或 Nginx 进程崩溃
