在 nginx 中，`least_conn` 负载均衡算法本身不直接暴露各节点的实时活跃连接数供外部监控，但可以通过配置 `stub_status` 模块获取基础状态，并结合 `upstream` 的日志格式统计实际请求处理情况。要监控各节点的活跃连接，最直接的方法是在上游服务器（upstream）上部署 `stub_status` 接口，并在 nginx 主配置中通过自定义日志格式记录每个请求的目标节点 ip，从而在日志分析层面还原连接分布。此外，nginx plus 提供了原生的 api 来查询 upstream 的健康状态和连接数，而开源版则依赖第三方工具或脚本解析日志。
如何配置 upstream 日志以追踪目标节点
要实现对各节点活跃连接的监控，第一步是确保 Nginx 记录了每个请求被转发到了哪个后端节点。默认情况下，Nginx 的访问日志不会包含 `upstream_addr` 字段，因此需要修改 `log_format` 配置。通过在 `http` 块中定义一个新的日志格式，并加入 `$upstream_addr`、`$upstream_response_time` 等变量，可以精确记录每次请求的后端地址和处理耗时。这样，通过分析日志文件，就可以统计出每个后端 IP 在特定时间段内处理的请求数量，进而推断其负载情况。
log_format upstream_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'upstream_addr=$upstream_addr '
'upstream_response_time=$upstream_response_time';
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_pool;
access_log /var/log/nginx/upstream_access.log upstream_log;
}
}
上述配置将日志输出到 `/var/log/nginx/upstream_access.log`，格式中包含 `upstream_addr` 字段。当使用 `least_conn` 算法时，Nginx 会根据当前各节点的活跃连接数选择节点，虽然日志记录的是已完成的请求，但结合高频次的日志采样，可以近似反映节点的负载分布。需要注意的是，`least_conn` 的选择是基于 Nginx 内部维护的连接计数，而非日志中的请求计数，因此日志主要用于事后分析和趋势监控，而非实时决策依据。
如何通过 stub_status 获取后端节点实时连接数
除了日志分析，实时监控各后端节点的活跃连接数，需要在每个后端服务器上启用 `stub_status` 模块。`stub_status` 是一个轻量级的状态页面，能够返回当前的活跃连接数、总连接数等信息。在每个后端服务器的 Nginx 配置中添加一个专门的位置块，例如 `/nginx_status`，即可暴露该信息。然后，可以使用脚本定期轮询这些状态页面，汇总所有后端节点的数据，从而实现全局监控。
server {
listen 8080;
server_name localhost;
location /nginx_status {
stub_status on;
allow 127.0.0.1; # 仅允许本地访问
deny all;
}
}
在后端服务器上配置上述内容后，访问 `http://backend_ip:8080/nginx_status` 将返回类似如下的信息： Active connections: 5 server accepts handled requests 100 100 200 Reading: 1 Writing: 3 Waiting: 1 其中 `Active connections` 即为当前的活跃连接数。通过编写一个简单的 Shell 或 Python 脚本，定期抓取所有后端节点的这一数值，并将其发送到监控系统（如 Prometheus 或 Zabbix），即可实现对 `least_conn` 各节点活跃连接的实时监控。这种方法比日志分析更实时，能直接反映 Nginx 内部的连接计数状态。
least_conn 算法下节点连接数不一致时的行为表现
在 `least_conn` 算法中，Nginx 会优先将新请求分配给当前活跃连接数最少的后端节点。如果某个节点的连接数突然激增，而其他节点连接数较少，Nginx 会自动将后续请求导向低负载节点。然而，这种动态调整依赖于 Nginx 内部对连接状态的实时更新。在实际运行中，如果后端节点的处理速度差异较大，可能导致连接数分布不均。例如，一个慢速节点可能积累较多等待处理的连接，而快速节点则迅速释放连接。此时，`least_conn` 会倾向于选择快速节点，从而平衡整体负载。但需要注意的是，如果慢速节点的处理时间过长，可能导致其连接数持续偏高，影响用户体验。因此，监控各节点的连接数不仅有助于了解负载分布，还能及时发现潜在的性能瓶颈。
