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,因为该输出内容会以邮件的形式发送给用户,内容存储在邮件文件,会产生意向不到的结果,或会导致脚本压根不被执行;

作者:波罗学的草稿
链接:https://www.jianshu.com/p/7b10123c8b88
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

发表评论