PM2 进程管理工具使用总结

时间 2019-11-06

标签 pm2 进程管理工具使用总结繁體版

原文原文链接

注：2016年的文章，发在掘金上，不知道是否过期了。php

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

PM2特色

先来讲一下 pm2 有哪些优势好处。node

支持进程行为配置，便可以经过配置，实现对pm2管理应用的一些基础属性更新修改，如应用名称，启动模式- 等；
支持集群模式，支持负载均衡，但因采用nodejs的cluster模块实现，仅适用于nodejs进程；
支持source map，此项针对js, source map文件是js源文件的信息文件，里面存储着源文件的位置信息；
支持热重启；
支持部署工做流，pm2可依据测试环境和线上环境自动部署到不一样的服务器，同时运行在不一样配置下；
支持监听重启，在文件更新等状况下可实现进程自动重启；
支持linux的startup进程启动，startup是指系统boot, 进程自启动，如centos的chkconfig；
日志管理，两种日志，pm2系统日志与管理的进程日志，默认会把进程的控制台输出记录到日志中；
命令自动补全功能，我的感受这个功能意义不大，并且尝试了一下，没有原生的linux命令自动补全反应敏- 捷；
监控功能，pm2 monit监控cpu和memory使用状况，keymetrics监控更为详细；
支持开发调试模式，非后台运行，pm2-dev start ；
支持pm2模块开发，实现pm2的功能扩展；
keymetrics监控，比pm2 monit监控更为详细友好，经过web页面展现；
最大内存重启，设置最大内存限制，超过限制自动重启；
编程API，提供API供开发者经过编程方式灵活管理进程；

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

pm2经常使用命令

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

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

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

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

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

先来看看 PM2 支持的配置项，以下：

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有关于这个问题的讨论。下面作个粗浅的概括：

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定时的讨论：

github.com/Unitech/pm2…

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

pm2的监控

pm2的监控有两种方式，分别是 cli 和 keymetrics。

cli方式

pm2 monit是专门用来监控的命令，监控项包括cpu与内存。缺点monit展现内容太过粗糙，不够详细

pm2 list展现当前全部pm2的管理项目，能够查看出每一个进程的运行状态。若是须要更详细的监控内容，对于cli而言通常都是能够实现的。

这种监控方式的缺点：

不够直观，须要本身去执行命令并分析结果；
不便于多台服务器的应用监控管理；

因为这些缺点，就须要一种更好的方式去监控咱们的应用

keymetrics

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

cnodejs.org/topic/56554…

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

利于多服务器监控管理；
代码异常，能够看出程序长期运行中的稳定性；
支持应用基本的启动，重启与中止等功能；

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

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

关于监控，本人经验很少，就很少妄言了

日志问题

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

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

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

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

稳定运行建议

PM2是一款很是优秀的Node进程管理工具，它有着丰富的特性：可以充分利用多核CPU且可以负载均衡、可以帮助应用在崩溃后、指定时间(cluster model)和超出最大内存限制等状况下实现自动重启。

我的几点见解保证常驻应用进程稳定运行：

定时重启，应用进程运行时间久了或许总会产生一些意料以外的问题，定时能够规避一些不可测的状况；
最大内存限制，根据观察设定合理内存限制，保证应用异常运行；
合理min_uptime，min_uptime是应用正常启动的最小持续运行时长，超出此时间则被断定为异常启动；
设定异常重启延时restart_delay，对于异常状况致使应用中止，设定异常重启延迟可防止应用在不可测状况下不断重启的致使重启次数过多等问题；
设置异常重启次数，若是应用不断异常重启，并超过必定的限制次数，说明此时的环境长时间处于不可控状态，服务器异常。此时即可中止尝试，发出错误警告通知等。

关于pm2的使用，主要仍是运用于常驻脚本。定时任务，更多仍是须要专门的定时任务管理工具crontab，不过crontab在使用中总会有各类不爽的问题，提供一个连接，关于crontab的问题，以及提出了一个新工具jobCenter，本人暂未仔细研究，粗略看了一下好像还不错:地址

最后说明，文章中有些我的思考，望不影响他人判断，若有错误，请指正，谢谢！