监控Nginx负载均衡性能需聚焦三大维度：后端处理节点、响应质量及异常识别；通过访问日志（含$upstream_addr等变量）、stub_status模块及脚本分析，实现零依赖可观测性。
监控 Nginx 负载均衡性能，核心是掌握“谁在处理请求”“处理得怎么样”“有没有异常节点”这三个维度。Nginx 本身不带图形化监控界面，但通过内置模块、日志分析和轻量级扩展，可以高效实现可观测性。
启用并解析 Nginx 访问日志
这是最直接、零依赖的监控起点。默认 access_log 已开启，关键在于添加变量捕获后端信息：
- 在 location 或 upstream 对应的 server 块中配置日志格式，例如：
其中：
$upstream_addr 记录实际转发到的后端地址（如 192.168.1.10:8080）；
$upstream_response_time 表示后端响应耗时（单位秒，精确到毫秒）；
$upstream_status 是后端返回的状态码（如 200、502、504），能快速识别失败节点；
$request_time 是客户端完整请求耗时，用于比对瓶颈是否在 Nginx 层或后端。
- 配合 logrotate 定期归档，用 awk/grep/Python 脚本统计各后端的平均响应时间、错误率、请求占比，即可发现性能倾斜或故障苗头。
使用 stub_status 模块获取实时连接状态
该模块提供基础运行指标，需在编译时启用（大多数发行版预装）。配置如下：
- 在 server 块中开放一个本地监控端点：
stub_status on;
allow 127.0.0.1;
deny all;
}
访问 http://localhost/nginx_status 返回类似：
Active connections: 243server accepts handled requests
117872 117872 221456
Reading: 12 Writing: 88 Waiting: 143
重点关注：
– Active connections：当前活跃连接数，突增可能预示攻击或后端卡顿；
– accepts/handled/requests 三元组对比：若 handled
– Waiting 数值持续高企，往往意味着后端响应慢或队列积压。
配置健康检查与 upstream 状态暴露
Nginx 开源版支持被动健康检查（靠失败请求计数），但主动探测更可靠。可通过以下方式增强：
- 为 upstream 添加 max_fails 和 fail_timeout，例如：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}
Nginx 会自动标记并暂时剔除连续失败的节点。 - 借助 nginx-module-vts（第三方可视化状态模块）或 nginx-plus 的 dashboard，可直观看到每个 upstream server 的请求计数、失败次数、当前权重、健康状态等实时数据，支持 JSON API 供 Prometheus 抓取。
集成 Prometheus + Grafana 实现长期趋势分析
这是生产环境推荐做法，兼顾实时性与历史回溯能力：
- 部署 nginx-prometheus-exporter，它通过解析 stub_status 和 access_log，将指标暴露为 Prometheus 可采集的格式；
- 关键指标包括：
– nginx_upstream_requests_total{upstream="backend", backend="192.168.1.10:8080"}（各后端请求数）
– nginx_upstream_response_seconds_bucket{...}（响应时间分布直方图）
– nginx_upstream_healthcheck_failures_total（健康检查失败次数） - 在 Grafana 中绘制仪表盘：观察各后端 QPS 是否均衡、P95 响应时间是否超标、5xx 错误率是否异常上升——这些信号比单次 ping 更真实反映负载均衡效果。
