Note: The 2016 article, posted on the Nuggets, is not sure if it is out of date.

Crontab is a common tool for background process management. It can be used in two scenarios: scheduled task and resident script. Pm2, a nodejs-based process manager, is suitable for managing resident scripts in the background, and has its own load balancing function for Node network applications. Officially, PM2 is a Node application process manager with load balancing function. In my opinion, it is not accurate, because PM2 supports multiple languages, but has no load balancing capability for other processes besides Node.

Characteristics of PM2

First, what are the advantages and benefits of PM2?

  • Supports process behavior configuration, that is, you can update and modify some basic attributes of PM2 management applications, such as application name and startup mode.
  • Supports the cluster mode and load balancing, but because the NodeJS cluster module is used, it is only applicable to the NodeJS process.
  • Support source map, this item for JS, source map file is js source file information file, which stores the location of the source file information;
  • Supports hot restart.
  • Support workflow deployment, pM2 can be automatically deployed to different servers according to the test environment and online environment, and run in different configurations at the same time;
  • Support listening restart, in the case of file update can realize automatic restart process;
  • Linux supports startup processes. Startup means that the system boot and processes are automatically started, for example, centos chkconfig.
  • Log management, two types of log, PM2 system log and management process log, by default, the process console output is recorded in the log;
  • Command auto-complete function, personally feel that this function is not meaningful, and tried, there is no native Linux command auto-complete response sensitive – quick;
  • Pm2 Monit monitors CPU and memory usage. Keymetrics monitors CPU and memory usage in more detail.
  • Support development and debugging mode, non-background operation, pm2-dev start;
  • Support PM2 module development to achieve pM2 function expansion;
  • Keymetrics monitoring, more detailed and friendly than PM2 Monit monitoring, through the Web page display;
  • Maximum memory restart, set the maximum memory limit, exceed the limit automatically restart;
  • Programming API, providing API for developers to manage the process flexibly through programming;

This is a brief overview of the features of the PM2 process management tool.

Common PM2 commands

Common commands are usually relatively simple. The following lists some common PM2 management commands

Pm2 start [options] –name httpServer; pm2 start index.

Pm2 stop [options] stop the specified application, such as pm2 stop httpServer;

Pm2 reload | restart [options] restart given application, such as pm2 restart httpServer.

Pm2 show [options] displays details about a specified application, such as pm2 show httpServer.

Pm2 delete [options] Delete the specified application, such as pm2 delete httpServer. If you modify the configuration behavior of the application, delete the application first and then restart the application to take effect.

Pm2 kill Kills all processes managed by the PM2.

Pm2 logs Displays the standard output and standard error logs of a specified application.

Pm2 Monit monitors CPU and memory usage of each application process.

Pm2 common configuration

The PM2 can be configured using the CLI or configuration file.

The command line

pm2 start index.js –name HttpServer –interpreter node

The application name is httpServer and the index.js script interpreter is Node. For more options, see pm2 –help.

Configuration file Mode

The PM2 configuration file can be in YML or JSON format

The processes, yml file

processes.json

PM2 supports the following configuration items:

  • Name Application process name.
  • Script Start script path;
  • CWD specifies the path to start the CWD application. Run in/home/polo/directory/data/release/node/index, js, the script for the/data/release/node/index, js, CWD for/home/polo /;
  • Args parameters passed to the script;
  • Interpreter Specifies the script interpreter;
  • Interpreter_args A parameter passed to the interpreter;
  • Instances Number of started application instances. This parameter is valid only in cluster mode, and the default value is fork.
  • Exec_mode Specifies the application startup mode, including fork and cluster.
  • Watch monitors the restart. When this function is enabled, the changed applications in folders or subfolders will restart automatically.
  • Ignore_watch Ignores listening folders and supports regular expressions.
  • Max_memory_restart Specifies the maximum memory capacity that can be automatically restarted.
  • Env Environment variable, object type, such as {“NODE_ENV”:”production”, “ID”: “42”};
  • Log_date_format Specifies the log date format, for example, YYYY-MM-DD HH: MM :ss.
  • Error_file record standard error stream, $HOME /. Pm2 / logs/XXXerr log), the code error can be in this file search;
  • Out_file record standard output stream, $HOME /. Pm2 / logs/XXXout log), such as applied to print a lot of standard output, can lead to pm2 log is too large;
  • Min_uptime An application running less than the specified time is considered to be abnormally started.
  • Max_restarts maximum number of restarts for an exception, that is, the restarts for the restarts for the restarts for the min_uptime running time.
  • The default value of autorestart is true. If an exception occurs, the system automatically restarts.
  • Cron_restart Crontab time to restart applications. Currently, only the cluster mode is supported.
  • Force The default value is false. If true, a script can be repeatedly started. Pm2 does not recommend this;
  • Restart_delay Delays the restart time when an abnormal restart occurs.

The above content is rather dull, the following is combined with their own practice encountered in some pits to do the thinking summary.

Fork and Cluster startup modes

The PM2 process can be started in two modes: fork and cluster. For those of you who know Node, the node multi-process programming API is child_process.fork and cluster. Child_process. fork and cluster: child_process.fork and cluster: child_process.fork and cluster: child_process.fork and cluster: child_process. cluster: child_process Here’s a rough generalization:

Cluster is a derivative of fork. Cluster supports all the features that cluster has.

Fork does not support socket address port multiplexing, whereas cluster does. Because only the Cluster module of a node supports the socket option SO_REUSEADDR;

Fork cannot start multiple instance processes. Cluster can start multiple instances. Node child_process.fork can start multiple processes, but why not? As far as I am concerned, Node mainly provides network services. In this case, the cluster mode can be used to implement address and port reuse when starting multiple instances. However, fork mode does not support address and port reuse. However, for resident task scripts, network services do not need to be provided. In this case, multi-process startup can be realized and the task processing efficiency is also improved. The above requirements can be realized in two ways: one is to configure app0, APP1, and app2 to start multiple processes; the other is to call child_process.fork multi-process programming by the application instance itself.

Fork model can be applied to other languages such as PHP, python, perl, ruby, bash, coffee, and cluster can only be applied to the node;

Fork does not support scheduled restart, whereas cluster does. Scheduled restart is the cron_restart configuration item in the configuration. Github has a discussion about whether cron-like timing should be implemented in fork mode:

Github.com/Unitech/pm2…

The documentation on the official website states that the timing of the fork restart will be implemented soon, expect it… .

The monitor pm2

Pm2 can be monitored using cli and Keymetrics.

Cli way

Pm2 Monit is specifically used to monitor the command, monitoring items including CPU and memory. Disadvantages Monit display content is too rough, not detailed enough

Pm2 list Displays all pM2 management items and displays the running status of each process. If more detailed monitoring is required, the CLI can generally implement it.

Disadvantages of this monitoring method:

  • Not intuitive, you need to execute commands and analyze the results yourself;
  • It is not convenient for application monitoring and management of multiple servers.

Because of these shortcomings, we need a better way to monitor our applications

keymetrics

Keymetrics is a monitoring tool developed and maintained by PM2 developers. You can try it. It is very easy to install and configure it

Cnodejs.org/topic/56554…

I don’t do much research on monitoring. The main body of monitoring here is the application process, not the server. I just want to talk about a few functions THAT I like:

  • Conducive to multi-server monitoring and management;
  • Abnormal code, you can see the long-term stability of the program;
  • Supports basic application startup, restart, and stop functions.

However, KeyMetrics is a commercial version of the monitoring software. The free version has limited features and only has a free quota of two servers. The server side of keyMetrics is not built by itself, and it uses the application monitoring data to be periodically transferred to a third platform, which is expensive for companies with many servers. In addition, status information such as server and application server process is sensitive data and cannot be accepted when connected to third-party platforms. Of course, if the number of servers is limited, can afford to use expensive, no sensitive data, etc., Keymetrics is recommended. After all, it is developed and maintained by PM2 developers, and features are rich.

In view of the above problems, domestic niuren developed a similar free tool, I have not studied, the name is very interesting: PM2.5. Link address.

As for monitoring, I don’t have much experience, so I won’t make any nonsense

Log problem

The log system is usually a necessary auxiliary function for any application. Pm2 files are stored in $HOME/. Pm2 / by default. Pm2 logs are classified into two types:

  • Pm2 logs are stored in $HOME/.pm2/pm2.
  • Pm2 managed application logs are stored in $HOME/. Pm2 /logs/. Standard error logs are stored in ${APP_NAME}_out.log and standard error logs are stored in ${APP_NAME}_error.log.

The reason why logging is described separately here is that if the program is not developed carefully, in order to debug the program, the application generates a large amount of standard output, so that the server itself records a large number of logs, resulting in the service disk load problem. Generally speaking, PM2 managed applications have their own logging system, so for this unnecessary output you need to disable logging and redirect to /dev/null.

Similarly, crontab logs itself and the output of the applications it manages. The output of the application script must be redirected to /dev/null because the output is sent to the user as an email and stored in an email file, resulting in unintended results or the script not being executed at all.

Suggestions for stable operation

PM2 is a very good Node process management tool, it has rich features: it can make full use of multi-core CPU and load balancing, can help the application automatically restart after a crash, the specified time (cluster model) and exceed the maximum memory limit.

Here are my suggestions to ensure the stable running of resident application processes:

  • Timed restart, the application process running for a long time may always produce some unexpected problems, timing can avoid some unpredictable situations;
  • Maximum memory limit. Set a reasonable memory limit based on observation to ensure abnormal running of applications.
  • Reasonable MIN_uptime. Min_uptime is the minimum duration for the normal startup of an application. If the duration exceeds this threshold, the application is considered as abnormal startup.
  • Set the abnormal restart delay restart_delay. If an application stops due to an abnormal situation, set the abnormal restart delay to prevent excessive restarts caused by repeated restarts in unexpected situations.
  • Set the number of abnormal restarts. If the number of abnormal restarts is exceeded, the environment is in an uncontrollable state for a long time and the server is abnormal. At this point, you can stop trying, issue error warning notifications, and so on.

The use of PM2 is primarily for resident scripts. Scheduled tasks still need special scheduled task management tool crontab, but crontab always has various unpleasant problems in use. A link is provided for crontab problems, and a new tool jobCenter is proposed, which I have not studied carefully for the moment. After a cursory look, it seems to be good: address

Finally, there are some personal reflections in the article, which will not affect others’ judgment. If there are any mistakes, please correct them. Thank you!