必须在Node进程侧集成prom-client暴露/metrics端点，由Prometheus拉取process_cpu_seconds_total和process_resident_memory_bytes等指标，再通过Grafana用PromQL绘制CPU使用率（rate(process_cpu_seconds_total[5m])*100）和内存RSS曲线，并可叠加Nginx上游流量关联分析。
直接监控 Node.js 进程的内存与 CPU 负载，不能靠 Nginx——它只代理请求、不感知后端进程资源。真正要画出 Node 服务的内存/CPU 曲线，得在 Node 进程侧采集指标，再通过 Prometheus + Grafana 可视化，Nginx 只需配合暴露关键上下文（如上游地址、响应延迟）用于关联分析。
在 Node 进程中暴露指标（核心一步）
Node.js 本身不输出标准监控指标，需主动集成：
- 使用 prom-client 库（最主流）：在应用中启动一个
/metricsHTTP 端点，自动暴露process_cpu_seconds_total、process_resident_memory_bytes、事件循环延迟、GC 次数等原生指标； - 确保该端点可被 Prometheus 抓取（如监听
0.0.0.0:3001/metrics，并开放防火墙或仅允许内网访问）； - 避免在生产环境用
console.time或process.memoryUsage()手动打点——不可聚合、无时间序列语义，无法画曲线。
用 Prometheus 抓取并长期存储
Nginx 不参与指标采集，但你的监控链路需要它“不干扰”：
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
- 在 Prometheus
scrape_configs中配置 job，直连每个 Node 实例的/metrics地址（例如：static_configs: [{targets: ["192.168.1.10:3001", "192.168.1.11:3001"]}]）； - 若 Node 部署在容器或动态 IP 环境，改用服务发现（如 Consul、Kubernetes SD）；
- 确认抓取间隔（
scrape_interval: 15s）足够支撑分钟级曲线精度，且不会给 Node 带来压力（prom-client的 metrics 端点开销极低）。
用 Grafana 绘制真实负载曲线
在 Grafana 中新建面板，写 PromQL 查询即可生成连续曲线：
- CPU 使用率（近似）：
rate(process_cpu_seconds_total[5m]) * 100（单位是百分比，按单核折算）； - 内存占用（RSS）：
process_resident_memory_bytes，加max by (instance)区分不同 Node 节点； - 叠加 Nginx 关联维度：用
upstream_addr日志字段 + Prometheus relabel 规则，把 Nginx 请求流量（nginx_vts_upstream_requests_total）和对应 Node 的 CPU/内存画在同一时间轴，快速判断“高 CPU 是否伴随高请求量”； - 设置告警规则：例如当
avg by (instance)(rate(process_cpu_seconds_total[5m])) > 0.8持续 3 分钟，触发 CPU 过载告警。
为什么不能只靠 Nginx 日志或状态页？
Nginx 的 stub_status 或 vts 模块只能反映自身连接、请求、转发延迟，完全不包含 Node 进程的内存分配、V8 堆大小、GC 暂停、CPU 时间片消耗等数据。即使你看到某 upstream server 的 response_time 突增，也无法区分是 Node 内存溢出导致 GC 卡顿，还是数据库慢查询拖累——必须下钻到 Node 进程指标才能归因。
