nginx监控需从stub_status单点指标演进至全栈可观测：1. stub_status提供基础连接状态但无时间戳；2. exporter+prometheus实现标准化采集与横向扩展；3. 全栈融合指标、日志、链路及ai预测，支撑多云与全球化业务。
nginx 监控不是配个 /status 就完事的。它背后是一条从单点可观测，到跨区域、多维度、可预测的演进路径——核心驱动力是业务规模扩大、部署形态变化（物理机→容器→多云/混合云），以及对故障响应时效要求的持续提高。
Stub Status：轻量级入口，但仅限基础连接层
stub_status 是 nginx 内置模块，需编译时显式启用（--with-http_stub_status_module）。它暴露的是一组极简指标：
- Active connections：当前所有连接总数，等于 Reading + Writing + Waiting 之和
- accepts / handled / requests：三者关系反映握手成功率与请求处理链路健康度（正常时 accepts ≈ handled）
- Reading / Writing / Waiting：状态分布揭示负载特征，比如 Waiting 长期偏高，常指向后端响应慢或 keep-alive 连接复用不合理
它的价值在于低开销、零依赖，适合单机快速验证。但输出是纯文本，无时间戳、无标签、不可聚合，无法直接对接 Prometheus 或 Zabbix —— 必须借助 nginx-prometheus-exporter 等中间件做格式转换。
Exporter + Prometheus：标准化采集，支撑横向扩展
当 nginx 实例数超过 5 台，或部署在 Kubernetes 中，stub_status 原始接口就不再适用。此时典型架构是：
- 每台 nginx 暴露专用端口（如
127.0.0.1:8080/stub_status），禁止公网访问 - 部署
nginx-prometheus-exporter（支持 DaemonSet 或 Sidecar 模式），拉取本地 stub_status 数据并转为标准 metrics 格式 - Prometheus 定期 scrape 所有 exporter 的
/metrics接口，统一存储与查询
这一层解决了指标标准化、自动服务发现、历史回溯等问题，也自然接入 Grafana 可视化大盘，是中小规模云原生环境的主流选择。
全栈可观测性：指标+日志+链路+AI分析融合
当业务进入全球化多中心阶段（例如 CDN 节点、边缘集群、主站与海外分站独立部署），单一 nginx 指标已无法定位跨组件问题。这时需要升级为可观测体系：
- 指标层：仍以 stub_status 衍生指标为基础，但叠加 Nginx 日志解析（如 access.log 中的响应时间、错误码分布）、OpenTelemetry 上报的反向代理链路追踪
- 日志层：通过 Filebeat 或 Loki 收集 access/error 日志，关联请求 ID，实现“从慢请求定位到具体 upstream”
- 链路层：Nginx 配合 opentelemetry-nginx-module 注入 trace context，使一次用户请求贯穿 CDN → LB → Nginx → 后端服务
- 智能层：基于历史流量模式训练预测模型，提前识别连接数异常增长、499/502 突增等潜在风险，触发根因推荐（如“近 10 分钟 /api/v2/orders 接口平均响应超 2s，关联 upstream pod CPU >90%”）
这种架构已脱离传统“监控”范畴，转向主动防御与容量治理，也是当前头部电商平台和 SaaS 厂商的实际落地形态。
监控能力的提升，本质是运维视角从“这台机器还活着吗”，进化到“这次用户请求是否成功、为什么慢、下次会不会再出”。stub_status 是起点，不是终点。
