1. 项目概述为什么你需要一份靠谱的PM2命令手册如果你在Node.js后端开发或者运维的圈子里待过一阵子PM2这个名字你肯定不陌生。它几乎是Node.js应用在生产环境部署的“标配”进程管理器。我第一次接触PM2是因为一个线上服务半夜挂了手动重启后手忙脚乱后来才知道有这么一个神器可以守护进程、自动重启、监控日志。但说实话PM2的命令行接口CLI功能非常丰富多到有时候你明明知道它能做某件事却记不清具体的命令参数该怎么写。网上搜“pm2命令”出来的结果要么是零散的博客片段要么是官方文档的直译缺乏场景化的梳理和实战中的“坑点”提示。今天我就结合自己这些年从踩坑到熟练使用PM2的经历为你整理一份以场景驱动、附带避坑指南的PM2常用命令汇总。这份汇总不是简单的罗列我会告诉你每个命令在什么情况下用、为什么要这么用以及我踩过的那些“雷”。无论你是刚接触PM2的新手还是想查漏补缺的老手这份手册都能让你在管理Node.js进程时更加得心应手。2. PM2核心功能与命令体系解析在深入具体命令之前我们得先理解PM2的设计哲学和它的核心能力模型。PM2不仅仅是一个启动脚本的工具它构建了一个轻量级的“进程管理生态”。2.1 PM2的四大核心支柱PM2的强大建立在四个核心功能之上我们的命令也基本围绕它们展开进程生命周期管理这是基础。包括启动、停止、重启、删除应用。对应的命令如start,stop,restart,delete。进程状态监控与展示你需要知道你的应用运行得怎么样。list(或ls,status) 命令提供了实时快照而monit命令则提供了一个动态的终端仪表盘。日志集中管理PM2会自动捕获你应用的标准输出stdout和错误输出stderr并分别记录到日志文件中。logs命令是查看日志的入口flush命令则用于清理日志。集群模式与负载均衡这是PM2的杀手级功能。通过-i参数可以轻松启动多个应用实例集群PM2内置的负载均衡器会自动分配流量。这对于利用多核CPU、提高应用性能和可靠性至关重要。2.2 配置驱动与生态命令除了直接操作进程的命令PM2还有两类重要的命令体系生态系统文件Ecosystem File当你的应用需要复杂配置如环境变量、集群实例数、日志路径等时使用一个配置文件通常是ecosystem.config.js是更优雅和可维护的方式。init命令可以生成模板start和reload命令可以读取该配置。运维与部署命令包括保存当前进程列表以便开机自启 (save,startup)、生成系统服务 (startup)、以及简单的性能监控 (pm2 plus相关但本文聚焦免费核心功能)。理解了这个体系我们再看具体命令就不会觉得杂乱无章了。下面我们就进入实战环节按使用频率和场景来梳理这些命令。3. 应用生命周期管理从启动到下线这是最常用的一组命令涵盖了把一个Node.js应用交给PM2管理的全过程。3.1 启动应用pm2 start这是所有故事的开始。但一个简单的start背后有很多门道。基础用法pm2 start app.js这将以独立模式启动app.js应用名默认为文件名不含扩展名即“app”。进阶配置与场景指定应用名在管理多个应用时一个好记的名字比脚本名更重要。pm2 start app.js --name My-API-Server监听文件变化并自动重启开发神器pm2 start app.js --watch注意--watch会监控整个项目目录的变化。在生产环境慎用因为频繁的文件变动如写日志可能会触发不必要的重启循环。通常仅用于开发环境。传递环境变量NODE_ENVproduction pm2 start app.js # 或者使用 -- 分隔符传递参数给脚本 pm2 start app.js -- arg1 arg2最大内存重启防止内存泄漏导致服务器崩溃。pm2 start app.js --max-memory-restart 300M当应用内存占用超过300MB时PM2会自动重启它。这个值需要根据你的服务器内存和应用实际情况调整。实操心得我习惯在第一次启动非简单应用时就直接使用生态系统文件而不是在命令行堆砌大量参数。因为命令行参数不易维护和版本控制。3.2 查看、停止、重启与删除查看列表pm2 list或pm2 ls或pm2 status。这是你最常用的命令之一一眼看清所有托管应用的状态online, stopped, errored、CPU/内存占用、重启次数等。停止应用pm2 stop id|name。这里的id|name可以是pm2 list中看到的数字ID也可以是你用--name指定的应用名。例如pm2 stop 0或pm2 stop My-API-Server。停止后应用状态变为stopped但并未从PM2列表中移除。重启应用pm2 restart id|name。这会先停止再启动应用。一个更优雅的命令是reload我们后面会讲。删除应用pm2 delete id|name。将应用从PM2列表中彻底移除。如果你想停止并删除可以用pm2 delete id|name如果只想停止用stop。常见问题pm2 stop all可以停止所有应用pm2 delete all会删除所有应用谨慎使用。有时候应用卡死stop无效可以尝试pm2 kill强制终止PM2守护进程本身所有托管进程也会停止然后再启动PM2 (pm2 resurrect需要配合save使用。4. 日志管理定位问题的眼睛线上应用出了问题查看日志是第一反应。PM2的日志管理非常规整。4.1 实时查看日志pm2 logspm2 logs查看所有托管应用的最新日志混合输出。pm2 logs id|name查看指定应用的日志。pm2 logs --lines 200查看最近200行日志默认是15行。pm2 logs --err只查看错误日志。pm2 logs --out只查看标准输出日志。pm2 logs --raw显示原始的日志内容不添加PM2的格式化信息如时间戳、应用名前缀。这在需要将日志管道 (pipe) 到其他工具如grep,awk) 时非常有用。实操技巧在调试时我经常用pm2 logs My-App --err --lines 50快速聚焦最近可能出现的错误。日志默认存储在~/.pm2/logs/目录下以app-name-out.log和app-name-error.log分开存储。这个路径可以在启动时通过-o和-e参数自定义。4.2 清理与重载日志pm2 flush和pm2 reloadLogspm2 flush这是一个危险但有时必要的命令。它会清空所有PM2管理的日志文件~/.pm2/logs/下的所有.log文件。通常在日志文件过大占满磁盘空间且你已确认历史日志无需保留时使用。重要警告执行flush前请确保已有日志备份或确认可丢弃。生产环境慎用建议配合日志轮转log rotation工具使用。pm2 reloadLogs这个命令很实用。它会重新打开所有日志文件流。当你使用外部工具如logrotate切割或压缩了PM2的日志文件后需要执行此命令否则PM2会继续向旧的文件描述符写入导致日志不记录到新文件。5. 集群模式与零停机重启对于Web服务这是PM2最具价值的功能之一。5.1 启用集群模式pm2 start -ipm2 start app.js -i max启动与服务器CPU核心数相等的应用实例。PM2会自动创建主进程进行负载均衡。pm2 start app.js -i 4明确指定启动4个实例。原理浅析PM2的集群模式基于Node.js的cluster模块。主进程Master不运行你的业务代码只负责管理一组工作进程Worker。当请求到来时主进程通过轮询等简单策略将其分发给空闲的工作进程从而充分利用多核CPU。5.2 优雅重启与重载reloadvsrestart这是新手和老手的一个重要分水岭。pm2 restart app-name硬重启。它会立即终止所有工作进程然后重新启动它们。这会导致服务在重启期间有短暂的不可用停机时间。pm2 reload app-name软重载/零停机重启。这是生产环境的首选。PM2会启动新的工作进程。等待新的工作进程成功启动并开始监听端口即“健康”状态。然后逐步终止旧的工作进程。在整个过程中始终有工作进程可以处理请求从而实现了理论上的“零停机”。如何实现你的Node.js应用需要能够优雅地关闭。通常这意味着你的HTTP服务器需要监听SIGINT或SIGTERM信号在收到信号后停止接收新请求完成已有请求处理后再退出。许多框架如Express, Koa对此有良好支持。使用场景当你更新了代码需要部署新版本时使用pm2 reload ecosystem.config.js是标准流程。如果reload失败例如新代码启动报错PM2会自动回滚到旧版本进程保证了服务的可用性。6. 生态系统文件复杂应用的配置管理当你的启动命令变成这样时就该使用生态系统文件了pm2 start app.js --name api --watch ./src --ignore-watchnode_modules logs --max-memory-restart 500M -i 2 --env production --log /var/log/api.log6.1 生成与使用生成模板pm2 init这会生成一个ecosystem.config.js文件。我强烈推荐使用.js格式而非.json或.yml因为它允许你使用JavaScript逻辑如根据环境变量动态配置。一个典型的配置示例module.exports { apps: [{ name: my-app, // 应用名 script: ./src/app.js, // 入口脚本 instances: max, // 集群实例数max 或数字 exec_mode: cluster, // 集群模式 watch: false, // 生产环境关闭监听 max_memory_restart: 1G, // 内存超限重启 env: { // 开发环境变量 NODE_ENV: development, PORT: 3000 }, env_production: { // 生产环境变量 (通过 --env production 指定) NODE_ENV: production, PORT: 80 }, error_file: ./logs/err.log, // 错误日志路径 out_file: ./logs/out.log, // 输出日志路径 log_date_format: YYYY-MM-DD HH:mm:ss Z // 日志时间格式 }] };使用配置启动# 启动所有应用使用默认env pm2 start ecosystem.config.js # 启动并指定使用生产环境变量 pm2 start ecosystem.config.js --env production # 重载配置零停机 pm2 reload ecosystem.config.js --env production # 仅重启某个应用 pm2 restart ecosystem.config.js --only my-app配置驱动的优势版本化、可读性强、环境隔离、便于协作。它把运维配置从口头传递或隐藏的启动脚本中解放了出来。7. 进程持久化与开机自启你肯定不希望服务器重启后需要手动登录再去敲pm2 start。PM2提供了将当前进程列表保存并设置为系统服务的能力。7.1 保存与恢复进程列表pm2 save将当前PM2进程列表包括所有应用的配置、环境变量等快照保存到~/.pm2/dump.pm2。这个文件很重要。pm2 resurrect读取dump.pm2文件恢复之前保存的所有进程。服务器重启后如果你手动启动了PM2守护进程可以执行此命令恢复所有应用。7.2 配置系统启动服务以Ubuntu/Debian为例这是实现真正开机自启的关键一步。PM2可以帮你生成对应系统的服务脚本systemd, upstart等。生成启动脚本pm2 startup执行这个命令PM2会检测你的系统并输出一条需要你以root权限执行的命令。例如[PM2] Init System found: systemd [PM2] To setup the Startup Script, copy/paste the following command: sudo env PATH$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u your_username --hp /home/your_username执行PM2输出的命令复制上面输出的命令以root身份执行。这会在/etc/systemd/system/下创建一个pm2-your_username.service文件。保存当前配置确保你的应用都已启动并且是你希望开机自启的状态然后执行pm2 save现在当服务器重启时systemd会自动启动PM2守护进程PM2则会自动加载dump.pm2并恢复所有应用。排查技巧如果开机后应用没起来首先检查PM2服务状态sudo systemctl status pm2-your_username。然后检查PM2日志pm2 logs。常见问题是pm2 save没有在正确配置后执行或者启动脚本中的环境变量PATH不对。8. 监控、性能排查与高级命令除了基础管理PM2也提供了一些内置的监控和诊断工具。8.1 终端仪表盘pm2 monit运行pm2 monit会打开一个基于终端的图形化监控界面。在这里你可以实时看到所有进程的CPU、内存使用情况、日志流甚至可以进行简单的操作如重启。对于快速检查服务器负载情况非常直观。8.2 简单性能快照pm2 show id|name显示某个应用的详细信息包括源码路径、环境变量、循环依赖等元数据。pm2 describe id|name同上是show的别名。8.3 环境与版本管理pm2 --version或pm2 -v查看PM2版本。pm2 update更新PM2自身到最新版本。pm2 install module安装PM2模块PM2早期支持插件系统但现在很多功能已内置此命令使用较少。9. 常见问题与故障排查实录即使命令用对了在实际环境中还是会遇到各种问题。这里记录几个我印象深刻的“坑”。9.1 应用启动后立即退出状态为errored这是最常见的问题。pm2 logs app-name --err查看错误日志。原因1端口被占用。检查日志是否有EADDRINUSE错误。用netstat -tlnp | grep :port查找占用进程并处理。原因2依赖缺失或Node版本不对。确保在应用目录下执行了npm install且Node版本符合要求。PM2启动时会使用系统全局的Node。原因3配置文件语法错误或路径错误。仔细检查ecosystem.config.js中的script路径是否正确JSON/JS语法有无错误。9.2 集群模式下工作进程不均衡或部分进程不工作检查负载均衡PM2集群默认是轮询round-robin。如果你的应用有状态如使用了内存Session会导致问题。需要确保应用是无状态的或者将会话存储到外部服务如Redis。检查文件描述符限制启动大量进程可能导致系统文件描述符耗尽。用ulimit -n查看必要时增加限制修改/etc/security/limits.conf。9.3pm2 reload不生效或卡住确认应用支持优雅关闭你的应用必须在收到SIGINT信号后能正常关闭。可以在代码中添加信号监听器进行测试。process.on(SIGINT, () { console.log(Received SIGINT. Closing server gracefully...); server.close(() { console.log(Server closed.); process.exit(0); }); });检查reload超时设置默认超时时间是1600ms。如果应用关闭较慢可以通过--kill_timeout ms参数增加等待时间。pm2 reload app.js --kill_timeout 50009.4 日志文件过大磁盘空间告警这是运维中的常态问题。PM2自身没有日志轮转功能需要借助系统工具。方案一使用Linux的logrotate。创建一个配置文件/etc/logrotate.d/pm2/home/username/.pm2/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty create 644 username username sharedscripts postrotate pm2 reloadLogs /dev/null 21 || true endscript }这个配置会每天轮转日志保留7天压缩旧日志并在轮转后执行pm2 reloadLogs让PM2写入新文件。记得将username替换为实际用户。方案二在生态系统文件中指定日志路径到专门的日志目录并配合日志收集系统如ELK, Loki使用及时清理本地文件。9.5 权限问题导致启动失败使用非root用户运行PM2出于安全考虑永远不要用root用户直接运行你的Node应用。应该创建一个专用用户如deploy。端口问题如果你的应用需要监听1024以下的端口如80、443非root用户无权限。解决方案是使用反向代理如Nginx监听80/443端口然后转发到Node应用的高端口如3000或者使用authbind、setcap等工具赋予Node程序特定能力。掌握这些命令和背后的原理你就能像管理一支训练有素的军队一样管理你的Node.js进程。PM2的工具链思维很清晰用配置定义状态用命令触发操作用日志观察结果。最后记住任何线上操作尤其是delete all,flush,kill这类命令三思而后行最好先在测试环境验证流程。