pm2详解

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

一，pm2特点：

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

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

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

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

4. 支持热重启；

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

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

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

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

9. 命令自动补全功能，个人感觉这个功能意义不大，而且尝试了一下，没有原生的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常用的管理命令

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

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

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

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

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

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

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

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

三，pm2常用配置

pm2 配置方式

1. 命令行方式

   pm2 start index.js --name HttpServer --interpreter node

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

2. 配置文件方式

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

   processes.yml文件

3.       
         
           
           
           
           
   
            
            
            
            
   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
            
            
            
            
   
           
           
           
           

   processes.json

4.       
         
           
           
           
           
   
            
            
            
            
   {
   
            
            
            
            
     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"
   
            
            
            
            
     }]}
           
           
           
           

配置项

1. name  应用进程名称；

2. script  启动脚本路径；

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

4. args  传递给脚本的参数；

5. interpreter  指定的脚本解释器；

6. interpreter_args  传递给解释器的参数；

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

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

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

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

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

12. env  环境变量，object类型，如{"NODE_ENV":"production", "ID": "42"}；

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

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

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

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

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

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

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

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

21. 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。下面做个粗浅的归纳：

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

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

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

   

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

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

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

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

五，pm2的监控

pm2的监控有两种方式：

1. cli方式监控

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

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

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

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

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

   这种监控方式的缺点：

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

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

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

2. 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. 定时重启，应用进程运行时间久了或许总会产生一些意料之外的问题，定时可以规避一些不可测的情况；

2. 最大内存限制，根据观察设定合理内存限制，保证应用异常运行；

3. 合理min_uptime，min_uptime是应用正常启动的最小持续运行时长，超出此时间则被判定为异常启动；

4. 设定异常重启延时restart_delay，对于异常情况导致应用停止，设定异常重启延迟可防止应用在不可测情况下不断重启的导致重启次数过多等问题；

5. 设置异常重启次数，如果应用不断异常重启，并超过一定的限制次数，说明此时的环境长时间处于不可控状态，服务器异常。此时便可停止尝试，发出错误警告通知等。