pm2进程管理工具使用总结

对于后台进程的管理，常用的工具是crontab，可用于两种场景：定时任务和常驻脚本。关于常驻脚本，今天介绍一款更好用的工具：pm2，基于nodejs开发的进程管理器，适用于后台常驻脚本管理，同时对node网络应用有自建负载均衡功能。官方的说法，pm2 是一个带有负载均衡功能的Node应用的进程管理器，个人认为，并不准确，因为pm2支持多种语言，只是对于除node之外的其他进程无负载均衡的能力。

一 pm2特点：

说一些pm2有哪些优点好处呢？

01. 支持进程行为配置 ，即可以通过配置，实现对pm2管理应用的一些基础属性更新修改，如应用名称，启动模式等；

02. 支持集群模式，支持负载均衡，但因采用nodejs的cluster模块实现，仅适用于nodejs进程；

03. 支持source map，此项针对js, source map文件是js源文件的信息文件，里面存储着源文件的位置信息；

04. 支持热重启；

05. 支持部署工作流，pm2可依据测试环境和线上环境自动部署到不同的服务器，同时运行在不同配置下；

06. 支持监听重启，在文件更新等情况下可实现进程自动重启；

07. 支持linux的startup进程启动，startup是指系统boot, 进程自启动，如centos的chkconfig；

08. 日志管理，两种日志，pm2系统日志与管理的进程日志，默认会把进程的控制台输出记录到日志中；

09. 命令自动补全功能，个人感觉这个功能意义不大，而且尝试了一下，没有原生的linux命令自动补全反应敏捷；

10. 监控功能，pm2 monit监控cpu和memory使用情况，keymetrics监控更为详细；

11. 支持开发调试模式，非后台运行，pm2-dev start ；

12. 支持pm2模块开发，实现pm2的功能扩展；

13. keymetrics监控，比pm2 monit监控更为详细友好，通过web页面展示；

14. 最大内存重启，设置最大内存限制，超过限制自动重启；

15. 编程API，提供API供开发者通过编程方式灵活管理进程；

以上简要概述了pm2进程管理工具的特点。

二 pm2常用命令

常用命令通常都是比较简单。下面列举一些pm2常用的管理命令

pm2 start [options] 启动指定应用，如pm2 start index.js –name httpServer；

pm2 stop [options] 停止指定应用，如pm2 stop httpServer；

pm2 reload|restart [options]  重启指定应用，如pm2 restart httpServer；

pm2 show [options] 显示指定应用详情，如pm2 show httpServer；

pm2 delete [options] 删除指定应用，如pm2 delete httpServer，如果修改应用配置行为，最好先删除应用后，重新启动方才生效，如修改脚本入口文件；

pm2 kill 杀掉pm2管理的所有进程；

pm2 logs  查看指定应用的日志，即标准输出和标准错误；

pm2 monit 监控各个应用进程cpu和memory使用情况；

三 pm2常用配置

pm2 配置方式

命令行方式

pm2 start index.js –name HttpServer –interpreter node

此处通过命令的选项配置应用名称为httpServer，index.js脚本文件解释器为node，更多选项可查看pm2 –help获取；

配置文件方式

pm2配置文件方式支持yml与json格式

processes.yml文件

processes.json

配置项

name  应用进程名称；

script  启动脚本路径；

cwd  应用启动的路径，关于script与cwd的区别举例说明：在/home/polo/目录下运行/data/release/node/index.js，此处script为/data/release/node/index.js，cwd为/home/polo/；

args  传递给脚本的参数；

interpreter  指定的脚本解释器；

interpreter_args  传递给解释器的参数；

instances  应用启动实例个数，仅在cluster模式有效，默认为fork；

exec_mode  应用启动模式，支持fork和cluster模式；

watch  监听重启，启用情况下，文件夹或子文件夹下变化应用自动重启；

ignore_watch  忽略监听的文件夹，支持正则表达式；

max_memory_restart  最大内存限制数，超出自动重启；

env  环境变量，object类型，如{“NODE_ENV”:”production”, “ID”: “42”}；

log_date_format  指定日志日期格式，如YYYY-MM-DD HH:mm:ss；

error_file  记录标准错误流，$HOME/.pm2/logs/XXXerr.log)，代码错误可在此文件查找；

out_file  记录标准输出流，$HOME/.pm2/logs/XXXout.log)，如应用打印大量的标准输出，会导致pm2日志过大；

min_uptime  应用运行少于时间被认为是异常启动；

max_restarts  最大异常重启次数，即小于min_uptime运行时间重启次数；

autorestart  默认为true, 发生异常的情况下自动重启；

cron_restart  crontab时间格式重启应用，目前只支持cluster模式；

force  默认false，如果true，可以重复启动一个脚本。pm2不建议这么做；

restart_delay  异常重启情况下，延时重启时间；

上面内容比较枯燥无味，下面是结合自己实践中遇到的一些坑做的思考总结。

四 fork与cluster启动模式

pm2启动进程的支持两种模式：fork与cluster，对于了解node的人知道，node的多进程编程api: child_process.fork与cluster。关于pm2的fork与cluster两者的本质区别，个人认为就是node API的child_process.fork与cluster的区别，stackoverflow有关于这个问题的讨论  http://stackoverflow.com/questions/34682035/cluster-and-fork-mode-difference-in-pm2。下面做个粗浅的归纳：

cluster是fork的派生，cluster支持所有cluster拥有的特性；

fork不支持socket地址端口复用，cluster支持地址端口复用。因为只有node的cluster模块支持socket选项SO_REUSEADDR；

fork不可以启动多个实例进程，cluster可以启动多个实例。但node的child_process.fork是可以实现启动多个进程的，但是为什么没有实现呢？就个人理解，node多为提供网络服务，启动多个实例需要地址端口复用，此时便可使用cluster模式实现，但fork模式并不支持地址端口复用，多实例进程启动会产生异常错误。但对于常驻任务脚本而言，不需要提供网络服务，此时多进程启动可以实现，同时也提高了任务处理效率。对于上述需求，可以两种方式实现，一是配置app0,app1,app2方式启动多个进程，二是通过应用实例自身调用child_process.fork多进程编程实现；

fork模式可以应用于其他语言，如php,python,perl,ruby,bash,coffee， 而cluster只能应用于node;

fork不支持定时重启，cluster支持定时重启。定时重启也就是配置中的cron_restart配置项。github上面有作者关于fork模式下是否需要实现cron-like定时的讨论：

https://github.com/Unitech/pm2/issues/496

官网文档注明说，fork模式的定时重启这个功能不久将实现，期待中吧… …

五 pm2的监控

pm2的监控有两种方式：

cli方式监控

pm2 monit是专门用来监控的命令，监控项包括cpu与内存

缺点monit展示内容太过粗糙，不够详细

pm2 list展示当前所有pm2的管理项目

可以查看出每个进程的运行状态。

如果需要更详细的监控内容，对于cli而言一般都是可以实现的。

这种监控方式的缺点：

a. 不够直观，需要自己去执行命令并分析结果；

b. 不便于多台服务器的应用监控管理；

由于这些缺点，就需要一种更好的方式去监控我们的应用

keymetrics监控

keymetrics监控是PM2的开发者的开发和维护的一款监控工具，可以尝试一下，安装配置非常容易，我也只是粗浅的尝试了一下，可以参考

http://cnodejs.org/topic/56554300ad12df5d4e050b56

本人对监控研究不多，这里的监控主体是应用进程，非服务器，就只说说我比较喜欢的几个功能：

a. 利于多服务器监控管理；

b. 代码异常，可以看出程序长期运行中的稳定性；

c. 支持应用基本的启动，重启与停止等功能；

但是，keymetrics是一款商业版的监控软件，免费版功能有限，且只有两台服务器的免费配额，这款软件的服务端非自建，采用的是将应用监控数据定时上抛第三平台，对于有着众多服务器的公司而言费用昂贵，而且服务器与应用服务进程等状态信息是敏感性数据，接入到第三方平台中无法接受。当然，如果是服务器数量有限，能够支付昂贵的使用费用，无敏感数据等场景的话，推荐使用Keymetrics，毕竟是PM2的开发者的开发和维护，功能特性很丰富。

鉴于以上问题，国内牛人开发了一款类似的免费工具，本人没有研究过，名字很有趣: pm2.5。链接地址

http://www.open-open.com/lib/view/open1451825410105.html

关于监控，本人经验不多，就不多妄言了

六 日志问题

日志系统对于任意应用而言，通常都是必不可少的一个辅助功能。pm2的相关文件默认存放于$HOME/.pm2/目录下，其日志主要有两类：

a. pm2自身的日志，存放于$HOME/.pm2/pm2.log；

b. pm2所管理的应用的日志，存放于$HOME/.pm2/logs/目录下，标准谁出日志存放于${APP_NAME}_out.log，标准错误日志存放于${APP_NAME}_error.log；

这里之所以把日志单独说明一下是因为，如果程序开发不严谨，为了调试程序，导致应用产生大量标准输出，使服务器本身记录大量的日志，导致服务磁盘满载问题。一般而言，pm2管理的应用本身都有自己日志系统，所以对于这种不必要的输出内容需禁用日志，重定向到/dev/null。

与crontab比较，也有类似情况，crontab自身日志，与其管理的应用本身的输出。应用脚本输出一定需要重定向到/dev/null，因为该输出内容会以邮件的形式发送给用户，内容存储在邮件文件，会产生意向不到的结果，或会导致脚本压根不被执行；