stub_status模块本身不支持告警，需通过确认启用、安全暴露接口、对接监控系统三步实现闭环；它仅输出纯文本指标，须经采集解析（如Prometheus exporter）后才能用于阈值告警。
直接用 stub_status 模块本身无法实现告警，它只提供纯文本格式的实时基础指标，必须配合外部采集与判断逻辑才能完成监控告警闭环。关键在于三步：确认模块可用、安全暴露接口、对接可告警的监控系统。
确认 stub_status 模块已启用
该模块不是默认“开启”状态，而是需先确认是否被编译进当前 Nginx：
- 运行
nginx -V 2>&1 | grep -o with-http_stub_status_module，有输出说明已内置支持 - 若无输出，Ubuntu/Debian 官方包通常含该模块；Alpine 或自定义编译镜像可能被裁剪，需重新编译并添加
--with-http_stub_status_module - 注意：stub_status 仅适用于 HTTP 上下文，不能放在 stream 块或 http 外层
在 server 块中安全配置 /nginx-status 路由
必须将配置嵌套在某个 server{} 块内，且禁止公网直连：
- 推荐单独建一个仅监听
127.0.0.1:8080或内网地址的 server，不复用业务端口 - 路径建议避开
/status等通用名，改用/_nxs或/nginx-status - 配置示例：
location /_nxs { stub_status; access_log off; allow 127.0.0.1; allow 10.20.30.0/24; deny all; } -
stub_status;在 Nginx 1.7.5+ 可省略on；access_log off必须显式关闭，防止日志刷爆
用 exporter 或脚本拉取并转为可告警指标
stub_status 输出是固定格式纯文本，需解析后才能用于阈值判断或时间序列分析：
- 访问
curl -s http://127.0.0.1:8080/_nxs返回类似：Active connections: 17 server accepts handled requests 123456 123456 987654 Reading: 0 Writing: 2 Waiting: 15
- requests 是累计值，QPS 需两次采样差值除以时间间隔（如 5 秒），公式：
(req₂ − req₁) / 5 - 推荐使用
nginx-prometheus-exporter：它定期拉取 stub_status，暴露nginx_http_requests_total等指标，Prometheus 即可通过rate(nginx_http_requests_total[1m]) > 100实现 QPS 告警 - 若用脚本采集，需确保解析稳定（如用
awk 'NR==3 {print $3}'提取 requests），并写入时序库或触发告警通道（如企业微信、钉钉机器人）
常见告警场景与对应指标建议
stub_status 虽简单，但几个字段足够支撑核心稳定性判断：
-
连接堆积告警：当
Writing > 10且持续 30 秒，可能后端响应慢或网络拥塞 -
连接丢弃告警：若
handled < accepts，说明有连接被拒绝（查 error.log 中 “accept() failed”），需检查worker_connections或系统 ulimit - 空闲连接异常：Waiting 占 Active 比例长期低于 70%，可能 keepalive 被客户端关闭或 upstream 不健康
- 请求突增/归零：requests 值 10 秒内变化为 0 或暴涨 300%，结合业务时段判断是否异常
