pm2详解

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

一，pm2特点：

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

支持进程行为配置，即可以通过配置，实现对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 <appName>；
支持pm2模块开发，实现pm2的功能扩展；
keymetrics监控，比pm2 monit监控更为详细友好，通过web页面展示；
最大内存重启，设置最大内存限制，超过限制自动重启；
编程API，提供API供开发者通过编程方式灵活管理进程；

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

二，pm2常用命令

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

pm2 start <script_file|config_file> [options] 启动指定应用，如pm2 start index.js --name httpServer；
pm2 stop <appName> [options] 停止指定应用，如pm2 stop httpServer；
pm2 reload|restart <appName> [options] 重启指定应用，如pm2 restart httpServer；
pm2 show <appName> [options] 显示指定应用详情，如pm2 show httpServer；
pm2 delete <appName> [options] 删除指定应用，如pm2 delete httpServer，如果修改应用配置行为，最好先删除应用后，重新启动方才生效，如修改脚本入口文件；
pm2 kill 杀掉pm2管理的所有进程；
pm2 logs <appName> 查看指定应用的日志，即标准输出和标准错误；
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文件

apps:
  - script   : ./api.js
    name     : 'api-app'
    instances: 4
    exec_mode: cluster
  - script : ./worker.js
    name   : 'worker'
    watch  : true
    env    :
      NODE_ENV: development
    env_production:
      NODE_ENV: production

Copy

processes.json

{
  apps : [{
    name        : "worker",
    script      : "./worker.js",
    watch       : true,
    env: {
      "NODE_ENV": "development",
    },
    env_production : {
       "NODE_ENV": "production"
    }
  },{
    name       : "api-app",
    script     : "./api.js",
    instances  : 4,
    exec_mode  : "cluster"
  }]}

Copy

配置项

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/346****35/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/565****00ad12df5d4e050b56

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

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

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

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

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

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

http://www.open-open.com/lib/view/open145****0105.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，因为该输出内容会以邮件的形式发送给用户，内容存储在邮件文件，会产生意向不到的结果，或会导致脚本压根不被执行；

七，稳定运行建议

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

个人几点看法保证常驻应用进程稳定运行：

1. 定时重启，应用进程运行时间久了或许总会产生一些意料之外的问题，定时可以规避一些不可测的情况；