Nginx stub_status模块仅提供全局连接与请求汇总数据，不支持按业务模块统计；需结合access_log分析、nginx-module-vts或自定义变量等方案实现业务维度拆解。
Nginx 的 stub_status 模块本身不支持按业务模块（如路径、参数、上游服务等）区分统计请求量，它只提供全局的连接和请求汇总数据。若想统计特定业务模块的请求量，需结合其他机制实现，核心思路是：用 stub_status 作为基础监控入口，再通过日志分析、自定义变量或 upstream 分组等方式做业务维度拆解。
理解 stub_status 的能力边界
stub_status 只暴露三个基础指标：
- Active connections：当前活跃连接数（包括 waiting 状态）
- accepts：Nginx 启动后接受的总连接数
- handled：成功处理的连接数（通常与 accepts 相等）
- requests：Nginx 启动后处理的 HTTP 请求总数
它不记录 URL、Host、状态码或任何业务标识，因此无法直接回答“/api/order/create 被调了多少次”这类问题。
通过 access_log + 日志聚合统计业务模块请求量
这是最常用、最灵活的方式。关键是在 access_log 中记录业务标识，并用外部工具（如 awk、logrotate + cron、ELK 或 Prometheus + nginxlog-exporter）做聚合。
- 在 server 或 location 块中为不同模块设置独立 log_format，例如：
log_format order_module '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent';
location /api/order/ {
access_log /var/log/nginx/order_access.log order_module;
} - 或统一日志格式，但用 map 提取业务模块名：
map $request_uri $biz_module {
~^/api/order/.* "order";
~^/api/user/.* "user";
default "other";
}
log_format biz_log '$time_iso8601 $biz_module $status $request_time'; - 定时执行统计（例如每分钟）：
awk '{print $3}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
用 Nginx 变量 + stub_status 配合 Prometheus 实现模块级监控
借助 nginx-module-vts（Virtual Host Traffic Status）替代原生 stub_status，它支持按 server、upstream、location 维度统计请求数、响应码、响应时间等。
- 编译安装 vts 模块后，在配置中启用：
vhost_traffic_status_zone; - 为每个业务模块配置独立 upstream 或 location，并打上 label：
upstream order_backend {
server 127.0.0.1:8001;
}
location /api/order/ {
proxy_pass http://order_backend;
} - vts 页面（如
/status）会自动按 upstream 名（order_backend）分组显示 requests_in、responses_2xx 等指标，再配合nginx-vts-exporter推送至 Prometheus，即可用 PromQL 查询：
nginx_vts_upstream_requests_total{upstream="order_backend"}
用 stub_status 做轻量级健康校验，而非业务统计
虽然不能直接统计模块请求，但可将 stub_status 作为探针，验证 Nginx 是否正常接收流量，再结合业务日志判断模块是否“有请求进来”：
- 写一个简单脚本，定期 curl
http://127.0.0.1/stub_status，解析requests值是否持续增长；若停滞，说明整体流量异常，再进一步查各模块日志 - 对关键模块（如支付回调），可在 location 内加
log_by_lua_block上报到 Redis 计数器，与 stub_status 的全局 requests 形成交叉验证
