Nginx进程内存动态曲线需从OS层采集RSS/VSS，推荐Node Exporter+Prometheus或Telegraf+Procstat；Grafana中应汇总所有worker RSS、设10–30秒刷新、叠加基线与告警线，并关联活跃连接数、请求体大小及重启次数分析异常。
直接展示 Nginx 进程自身运行内存（如 RSS、VSS）的动态变化曲线，不能靠 Nginx 内置模块或 nginx-prometheus-exporter 实现——因为这些工具只采集 HTTP 层指标（连接数、请求、响应时间等），不暴露进程级内存数据。
需从操作系统层采集 Nginx 进程内存指标
Nginx 是多 worker 进程模型，真实内存消耗体现在每个 nginx: worker process 的 RSS（常驻内存）上。推荐用以下任一方式稳定采集：
-
Node Exporter + Prometheus：部署 node_exporter，它默认通过
processes和process_resident_memory_bytes指标暴露所有进程内存。在 Prometheus 中写查询：process_resident_memory_bytes{process_name=~"nginx.*worker"} -
Telegraf + Procstat 插件：配置 Telegraf 的
procstat输入插件，指定pattern = "nginx: worker process"，自动抓取 RSS、VSS、CPU 等，并写入 InfluxDB 或 Prometheus Remote Write 目标 -
自定义 Bash + cgroups（仅限容器化部署）：若 Nginx 运行在 Docker 或 systemd-cgroup 环境中，可读取
/sys/fs/cgroup/memory/nginx.slice/memory.usage_in_bytes，再通过textfile_collector推送至 Prometheus
在 Grafana 中绘制内存变化曲线的关键操作
确保数据已入库后，构建图表时注意三点：
- 用
sum by (instance) (process_resident_memory_bytes{...})汇总所有 worker 进程 RSS，避免单个 worker 波动干扰趋势判断 - 时间范围设为 “Last 1 hour”，刷新间隔设为 10–30 秒，保证曲线平滑且反映真实波动
- 叠加两条参考线：
— 当前 worker 数 × 单 worker 典型 RSS（如 20MB × 4 = 80MB）作为基线
— 告警阈值线（如 120MB），超限可能预示内存泄漏或大 body 请求堆积
关联分析：内存突增时看什么
单纯画内存曲线价值有限，建议在同一面板或联动看板中并列查看：
-
活跃连接数（
nginx_connections_active）：是否同步上升？确认是连接负载导致 -
请求体大小中位数（
histogram_quantile(0.5, rate(nginx_http_request_length_bucket[5m]))）：是否突增？说明大文件上传或日志注入类异常 -
Worker 进程重启次数（
count_over_time(process_start_time_seconds{job="node"}[1h])）：若内存上涨伴随频繁重启，可能是 worker 被 OOM Killer 杀掉
不复杂但容易忽略：Nginx 自身不管理堆内存，其“内存增长”几乎全是 worker 进程因处理请求缓存、SSL 会话、proxy_buffering 等产生的 RSS 上升。监控目标不是压低数值，而是识别异常拐点与上下文。
