Nginx 中 Python 部署如何结合状态监控模块查看实时连接

Nginx stub_status模块可实时监控前端连接状态以间接判断Python服务压力：Active connections持续高位且Writing增多，表明Python响应变慢；Waiting占比过低提示后端瓶颈；配合日志与响应时间分析可精准定位问题。

Python 应用部署在 Nginx 后端（常见于 Nginx + uWSGI/Gunicorn 模式）时，Nginx 本身不直接暴露 Python 进程状态，但可通过其内置的 stub_status 模块实时观测前端连接层健康状况——这是判断 Python 服务是否被请求压垮、响应变慢或连接堆积的关键窗口。

确认 Nginx 已启用 stub_status 并可访问

先确保 Nginx 编译时包含该模块：

1. 运行 nginx -V 2>&1 | grep -o with-http_stub_status_module，有输出即支持
2. 在任一 server 块中添加受保护的 location（如仅允许本地或监控机）：

<pre>location /nginx-status {

stub_status on;

access_log off;

allow 127.0.0.1;

deny all;

}

</pre>

重载配置：sudo nginx -s reload，再访问 http://127.0.0.1/nginx-status 应返回纯文本指标。

从连接状态反推 Python 服务压力

stub_status 不显示 Python 进程数或耗时，但以下字段组合能有效反映后端瓶颈：

1. Active connections 持续高位（接近 worker_connections 设置值），且 Writing 数量明显增多 → Python 应用响应变慢，Nginx 正在持续发送响应
2. Waiting 占比异常偏低（如 Reading + Writing 总和长期偏高 → 连接复用率下降，大量新连接涌入，可能因 Python 处理延迟导致客户端反复建连
3. accepts ≠ handled 差值持续扩大 → Nginx 接收连接能力受限，常见于 Python 后端响应过慢、阻塞 worker，导致 accept 队列积压（可用 ss -lnt | grep :80 查 Recv-Q 验证）

用 Python 脚本自动采集并告警

写一个轻量脚本定时抓取状态，结合阈值触发提醒（无需 Prometheus 等重型组件）：

<pre>import requests

import time

STATUS_URL = "http://127.0.0.1/nginx-status"

ALERT_THRESHOLD_ACTIVE = 1000# 触发告警的活跃连接数

ALERT_THRESHOLD_WRITING = 200 # Writing 过高提示后端慢

def parse_status():

try:

resp = requests.get(STATUS_URL, timeout=2)

lines = resp.text.strip().split("n")

active = int(lines[0].split()[-1])

reading, writing, waiting = map(int, lines[2].split()[1::2])

return active, reading, writing, waiting

except Exception as e:

print(f"获取状态失败: {e}")

return None

while True:

status = parse_status()

if status:

active, r, w, wait = status

if active > ALERT_THRESHOLD_ACTIVE:

print(f"[告警] Active connections = {active} (超阈值 {ALERT_THRESHOLD_ACTIVE})")

if w > ALERT_THRESHOLD_WRITING:

print(f"[注意] Writing = {w}，可能后端响应延迟")

time.sleep(5)

</pre>

保存为 nginx_monitor.py，后台运行即可持续盯梢。配合系统通知（如邮件、钉钉 Webhook）可进一步自动化。

补充：与 Python 应用日志联动排查

当 stub_status 显示异常时，立刻检查 Python 应用日志（如 Gunicorn 的 error.log 或 uWSGI 的 uwsgi.log）：

1. 是否有大量 timeout、Worker failed to boot、Connection reset by peer
2. 响应时间 P95 是否突增？可加 log-format 在 Nginx 中记录 $request_time 和 $upstream_response_time
3. 对比 upstream_response_time 和 request_time：若前者远小于后者，说明瓶颈在 Nginx 到客户端链路；若两者接近，则问题在 Python 层