PM2 生产级进程管理实战指南：守护、集群、日志与开机自启全解析

PM2 生产级进程管理实战指南守护、集群、日志与开机自启全解析【免费下载链接】reference面向开发者的技术速查清单Cheat Sheets集合整理常见技术、工具与开发流程帮助快速查阅关键信息提高开发效率。项目地址: https://gitcode.com/GitHub_Trending/referen/referencePM2 是 Node.js / Bun 应用最常用的生产进程管理器提供守护进程、崩溃自动重启、日志管理、实时监控、Cluster 集群模式、开机自启与配置文件ecosystem管理等核心能力同时也能托管 Shell 脚本、Python 程序乃至任意二进制文件。本文基于本仓库的 PM2 备忘清单 展开完整覆盖从安装、启动、进程操作到集群扩缩容、配置管理、环境变量注入、重启策略、开机自启与生产排障的每一个环节读完后你将具备一套可直接落地到生产环境的 PM2 实战方案。安装与版本管理PM2 通过 npm 全局安装也可使用 Yarn命令说明npm install pm2latest -g使用 npm 全局安装最新版yarn global add pm2使用 Yarn 全局安装pm2 -v查看 PM2 版本pm2 update更新内存中的 PM2 daemonpm2 ping检查 PM2 daemon 是否可用pm2 kill停止 PM2 daemon 和所有受管进程关键注意点PM2 采用「客户端命令 常驻 daemon」的架构pm2 start等命令实际上是把请求转发给后台 daemon 执行。因此升级全局包后正在运行的 daemon 仍是旧版本必须执行pm2 update让 daemon 加载新版本代码否则可能出现命令行为不一致的诡异问题。pm2 kill会连同所有受管进程一起停止适用于彻底清理环境或排查 daemon 异常。启动应用从 Node 到任意解释器常用启动命令命令说明pm2 start app.js启动 Node.js 应用pm2 start app.js --name api指定应用名称pm2 start app.js --watch文件变化时自动重启pm2 start app.js --time日志输出添加时间前缀pm2 start app.js --no-autorestart禁用自动重启pm2 start app.js --max-memory-restart 300M超过内存阈值后重启pm2 start script.sh启动 Shell 脚本pm2 start worker.py --interpreter python3指定解释器启动脚本pm2 start app.js -- --port 3000--后参数传给应用实战示例$ pm2 start app.js --name api --time $ pm2 start server.js --watch --ignore-watchnode_modules logs $ pm2 start app.js -- --port 3000参数透传是重要细节--之后的所有内容会被原样传给应用进程本身而不是被 PM2 解析。例如pm2 start app.js -- --port 3000等价于在命令行直接运行node app.js --port 3000。这对需要动态传端口、传配置文件路径的部署脚本非常实用。进程操作list / restart / reload / stop / delete命令说明pm2 list|pm2 ls|pm2 status列出受管进程pm2 restart name\|id\|all重启进程pm2 reload name\|id\|all零停机 reload适合网络服务pm2 stop name\|id\|all停止进程pm2 delete name\|id\|all从 PM2 列表删除进程pm2 describe name\|id查看进程详细信息pm2 reset name\|id\|all重置重启次数等元数据核心概念区分reload与restart截然不同。restart是粗暴地杀掉旧进程再拉起新进程期间存在短暂停机reload则尝试平滑替换——在 Cluster 模式下逐个重启实例、等待新实例就绪后再切换流量从而实现零停机部署。若应用未实现优雅退出、超时或场景不适用如非 Cluster 模式PM2 会自动回退到普通 restart。因此网络服务HTTP/TCP/UDP建议使用reload普通任务型脚本用restart即可。日志管理命令说明pm2 logs实时查看所有进程日志pm2 logs api查看指定应用日志pm2 logs --lines 200输出最近 200 行后继续跟随pm2 logs --nostream只打印日志不持续跟随pm2 logs --json以 JSON 格式输出日志pm2 logs --err只显示错误输出pm2 logs --out只显示标准输出pm2 flush清空所有日志pm2 flush api清空指定应用日志pm2 reloadLogs重新打开日志文件常用于 logrotate 后日志默认存放在$HOME/.pm2/logs目录下每个应用对应xxx-out.log与xxx-error.log两个文件。启动时可通过以下参数控制日志路径与格式--log path合并输出与错误日志到统一文件--output path指定标准输出日志路径--error path指定错误日志路径--time为每行日志添加时间戳前缀--log-date-format format自定义时间戳格式如YYYY-MM-DD HH:mm:ss--merge-logs多实例模式下将日志合并写入同一文件生产环境中日志文件会持续增长pm2 flush只能手动清空长期方案应配合外部logrotate轮转轮转完成后执行pm2 reloadLogs让 PM2 重新打开日志文件句柄。实时监控与诊断命令说明pm2 monit打开终端实时监控面板pm2 show api查看指定应用状态、日志路径、环境等信息pm2 prettylist以格式化 JSON 输出进程列表pm2 jlist输出原始 JSON 进程列表pm2 report生成诊断报告pm2 plus连接 PM2 Plus / PM2.io 在线监控pm2 monit在终端中实时展示 CPU、内存、请求数与日志滚动是排查单机性能问题的第一工具pm2 show则集中展示重启次数、运行时长、日志路径、注入的环境变量等元信息是定位问题的信息中枢pm2 report可一次性导出系统环境、Node 版本、PM2 配置等完整诊断信息适合在反馈问题时附带。Cluster 集群模式与扩缩容集群启动命令命令说明pm2 start app.js -i max根据可用 CPU 数启动实例pm2 start app.js -i 0与max类似启动尽可能多实例pm2 start app.js -i 4启动 4 个实例pm2 reload api对应用做零停机 reloadpm2 scale api 2增加 2 个实例pm2 scale api 4调整到总共 4 个实例适用条件Cluster 模式依赖 Node.js 内置的 cluster 模块适合监听 HTTP、TCP、UDP 等网络端口的应用——PM2 会在主进程与各实例之间自动做负载均衡默认 round-robin。任务型脚本无网络端口开启 Cluster 没有意义。关键陷阱仅靠-i参数启动还不够配置文件中必须显式设置exec_mode: cluster否则 PM2 默认以fork模式运行、不会启用负载均衡。这也是文档「常见排障」中「Cluster 未负载均衡」的最常见原因。Cluster 配置示例module.exports { apps: [{ name: api, script: ./server.js, instances: max, exec_mode: cluster }] }instances: max等价于-i max按机器可用 CPU 核心数拉起实例配合exec_mode: cluster即可在单机上把多核 CPU 全部利用起来并为pm2 reload的零停机滚动更新奠定基础。配置文件 ecosystem.config.js常用命令命令说明pm2 init simple生成基础ecosystem.config.jspm2 start ecosystem.config.js启动配置文件中的应用pm2 restart ecosystem.config.js重启配置文件中的应用pm2 reload ecosystem.config.jsreload 配置文件中的应用pm2 stop ecosystem.config.js停止配置文件中的应用pm2 delete ecosystem.config.js删除配置文件中的应用pm2 start ecosystem.config.js --only api只操作指定应用pm2 start ecosystem.config.js --env production使用env_production配置文件建议以.config.js结尾如ecosystem.config.js便于 PM2 识别--only name在配置文件声明了多个应用时只操作指定应用--env name则决定注入哪一组环境变量。多应用完整配置示例module.exports { apps: [{ name: api, script: ./server.js, instances: 2, exec_mode: cluster, watch: false, max_memory_restart: 300M, env: { NODE_ENV: development, PORT: 3000 }, env_production: { NODE_ENV: production, PORT: 8080 } }, { name: worker, script: ./worker.js, autorestart: true }] }这个示例同时覆盖了本清单的核心配置维度instances实例数、exec_mode执行模式、watch文件监听、max_memory_restart内存上限、env/env_production双环境变量组以及一个独立的worker任务型应用。将配置沉淀到ecosystem.config.js而非散落的 CLI 参数是保证生产环境可重复部署的关键实践。环境变量注入配置项说明env默认环境变量env_production--env production时注入env_staging--env staging时注入NODE_APP_INSTANCEPM2 为每个实例注入的实例编号instance_var重命名实例编号变量increment_var为每个实例递增某个环境变量--update-env重启时更新环境变量示例$ PORT4000 pm2 restart api --update-env $ pm2 start ecosystem.config.js --env production三个高价值细节NODE_APP_INSTANCECluster 模式下 PM2 自动为每个实例注入从 0 开始的编号应用可据此区分实例身份例如每个实例使用独立端口或独立临时目录。该变量名可通过instance_var自定义。increment_var可指定某个环境变量按实例递增适用于需要为每个实例分配不同端口/队列分片等场景。--update-envPM2 默认在重启时保留启动时注入的环境快照如果重启前用 shell 修改了环境变量如PORT4000必须加--update-env才会把新值写入进程这也是「环境变量不更新」排障项的官方解法。重启策略常见策略命令命令说明pm2 start app.js --watch文件变化时自动重启pm2 stop app --watch停止并禁用 watch 重启pm2 restart app --watch切换 watch 选项pm2 start app.js --restart-delay3000自动重启前等待 3000mspm2 start app.js --cron-restart0 0 * * *每天 0 点重启pm2 restart app --cron-restart 0禁用 cron 重启pm2 start app.js --exp-backoff-restart-delay100使用指数退避重启pm2 start app.js --stop-exit-codes 0退出码为 0 时不自动重启PM2 默认会在应用崩溃、进程退出或 Node.js 事件循环为空时尝试自动重启。重启策略既可通过 CLI 临时设置也应沉淀进配置文件长期生效。配置文件字段速查字段说明watch: true启用文件监听ignore_watch: [node_modules]忽略监听目录watch_delay: 1000文件变化后延迟重启max_memory_restart: 300M达到内存阈值后重启restart_delay: 3000重启延迟cron_restart: 0 0 * * *cron 定时重启autorestart: false禁用自动重启stop_exit_codes: [0]指定退出码不触发重启exp_backoff_restart_delay: 100指数退避重启初始延迟指数退避exponential backoff是防止重启风暴的关键机制exp_backoff_restart_delay: 100意味着首次重启延迟 100ms之后依次翻倍100ms → 200ms → 400ms → …避免应用因启动即崩溃而在无限快速重启循环中耗尽 CPU。watch场景建议同时配合ignore_watch排除node_modules、logs等高频变化目录并用watch_delay防止保存文件过程中触发多次重启。持久化与开机自启命令说明pm2 startup生成当前平台的开机启动命令pm2 startup systemd -u www --hp /home/www指定 systemd 用户和家目录pm2 save保存当前进程列表用于重启后恢复pm2 resurrect手动恢复上次保存的进程列表pm2 unstartup删除当前开机启动配置systemctl status pm2-user查看 systemd 服务状态journalctl -u pm2-user查看 systemd 启动日志典型生产流程$ pm2 start ecosystem.config.js --env production $ pm2 save $ pm2 startup # 复制并执行 pm2 startup 输出的 sudo 命令执行逻辑pm2 startup本身只是输出一条带 sudo 的安装命令自动检测 systemd / upstart / launchd 等平台需要复制该命令实际执行才会注册开机自启服务pm2 save则将当前进程列表快照到 dump 文件供系统重启后由自启服务调用pm2 resurrect恢复。两者缺一不可——只 startup 不 save开机后无进程可恢复只 save 不 startup重启后无人触发恢复。Node.js 升级后必须重新生成启动脚本开机自启服务里固化的是生成时的 Node.js 可执行路径升级 Node.js 后旧路径可能失效导致开机后应用启动失败。此时应依次执行pm2 unstartup和pm2 startup重新生成。生产常用流程部署后平滑更新$ git pull $ npm ci $ npm run build $ pm2 reload ecosystem.config.js --env production $ pm2 save使用pm2 reload而非restart实现零停机滚动更新--env production确保注入生产环境变量最后pm2 save更新持久化快照避免下次开机恢复出旧进程列表。单机快速启动 API$ pm2 start server.js --name api --time --max-memory-restart 300M $ pm2 logs api --lines 100适合开发机或临时环境快速起服务--time给日志加时间戳便于排查--max-memory-restart 300M兜底内存泄漏随后直接跟随日志观察启动结果。清理不再需要的进程$ pm2 stop old-api $ pm2 delete old-api $ pm2 savestop只是停止进程仍留在 PM2 列表中delete才会从列表移除删除后务必pm2 save同步持久化快照否则重启后会「复活」已删除的进程。查看异常原因三步走$ pm2 describe api $ pm2 logs api --err --lines 200 $ pm2 report先用describe查看进程状态与元数据再用--err --lines 200拉取最近错误日志最后用report导出完整诊断信息。常见排障速查问题解决思路重启后进程丢失启动或删除进程后忘记执行pm2 save开机自启使用旧 Node.jsNode.js 升级后重新执行pm2 unstartup和pm2 startup环境变量不更新使用pm2 restart app --update-env日志文件过大使用pm2 flush、pm2 reloadLogs并配置外部 logrotatewatch 停止后仍会重启使用pm2 stop app --watch彻底关闭 watchCluster 未负载均衡配置文件里确认exec_mode: clusterreload 变成 restart应用未能及时优雅退出检查连接关闭与超时最后一条「reload 变成 restart」值得展开PM2 的 reload 依赖应用在收到退出信号后快速优雅关闭关闭监听端口、断开存量连接、清空任务队列。如果应用有长连接或未处理完的异步任务迟迟不退reload 会超时并退化为普通 restart。生产应用应监听SIGINT/SIGTERM信号实现优雅关闭逻辑并设置合理的连接超时。在速查清单项目中的定位本仓库是面向开发者的技术速查清单Cheat Sheets集合docs/pm2.md即「PM2 备忘清单」通过 README.md 首页导航Node.js 分类可直达配套的assets/pm2.svg图标用于首页卡片展示。整个站点由 package.json 中的refs-cli编译 Markdown 生成静态页面netlify.toml与 Dockerfile 提供了 Netlify 与 Docker 两种部署方式——无论以何种方式部署这份速查站本文介绍的 PM2 都是承载其生产进程的首选方案形成了「用 PM2 运维速查站、速查站又教 PM2 用法」的闭环。【免费下载链接】reference面向开发者的技术速查清单Cheat Sheets集合整理常见技术、工具与开发流程帮助快速查阅关键信息提高开发效率。项目地址: https://gitcode.com/GitHub_Trending/referen/reference创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考