njs无法直接监控每个worker进程负载，因其运行在各worker独立沙箱中，无跨进程通信机制、不暴露系统资源数据，且ngx.shared仅支持最终一致的简单类型共享。
NJS（NGINX JavaScript）本身不提供直接获取 worker 进程内部 CPU、内存或请求数的原生 API，也无法跨进程读取其他 worker 的运行时状态。因此，无法用纯 NJS 脚本实时监控“每个 worker 进程”的负载与请求分布——这是由 NGINX 多进程模型和 NJS 沙箱限制共同决定的。
为什么 NJS 不能直接监控每个 worker？
NJS 模块运行在每个 worker 进程的独立 JavaScript 上下文中，彼此隔离：
- NJS 无跨进程通信机制（如共享内存读写、消息队列），不能主动拉取其他 worker 的指标；
- NJS 不暴露底层进程级资源数据（如 CPU 使用率、RSS 内存、当前活跃连接数）；
-
ngx.shared字典仅支持字符串/数字/布尔值，且是进程间最终一致的共享存储，不适合高频、精确的实时负载采样； - worker 进程由 master 管理，NJS 无权限调用系统级 procfs 或 getrusage 等接口。
可行的替代方案：组合使用 NJS + 外部工具
若目标是感知请求分布与粗粒度负载趋势，可借助以下协作方式：
-
用 NJS 记录 per-worker 请求统计：在
log_by_lua（或 NJS 的log阶段）中，用ngx.shared.dicts累加计数器（如req_count_worker_1234），配合ngx.worker.pid()区分 worker； -
定期导出指标供外部采集：通过
location /nginx_status暴露 JSON 接口，NJS 读取共享字典并返回当前 worker 的请求数、错误数、响应延迟直方图等； -
用外部 agent 补充系统指标：部署
prometheus-node-exporter或telegraf，结合ps aux | grep nginx或/proc/PID/stat获取各 worker 的 CPU% 和 RSS； -
关联分析需外部聚合：Prometheus 抓取各 worker 的
/nginx_status接口 + node_exporter 指标，用process_id标签对齐，实现“每个 worker”的请求量 vs CPU 使用率热力图。
一个轻量级 NJS 示例：按 worker 统计 QPS
在 nginx.conf 中定义共享字典：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
在 server 块中添加：
js_import stats.js;log_by_js stats.log;
stats.js 内容：
const pid = ngx.worker.pid();
const key = `qps_${pid}`;
dict.incr(key, 1); // 每次请求+1
// 可选：每分钟重置，或用时间窗口滑动计数
更实用的建议：优先使用 NGINX Plus 或 OpenResty
若生产环境真需细粒度 worker 级监控：
- NGINX Plus 内置
stub_status增强版，支持worker_connections、requests等 per-worker 指标（需启用status模块）； - OpenResty 的
resty.core+ffi可调用系统 API，配合lua-resty-lock实现安全的跨 worker 共享状态； - 对于开源 NGINX，推荐用
nginx-module-vts（Virtual Host Traffic Status）模块，它通过共享内存汇总各 worker 数据，并提供完整 JSON 接口，NJS 可读取该模块生成的共享字典（需确认兼容性）。
