LOG4JS multiple process traps and avoidance __js

LOG4JS multiple process traps and avoidance

Based on LOG4JS version 0.6.14

Log4js Total Three blog posts

"Log4js Principle Analysis" http://blog.csdn.net/hfty290/article/details/42844085

"Log4js Configuration Detailed" http://blog.csdn.net/hfty290/article/details/42843737

"Log4js and avoidance of multiple processes" http://blog.csdn.net/hfty290/article/details/42843303

In node, because a single process memory has a 1.4GB upper bound, in some large systems, cluster is usually used to run. In the cluster environment, that is, the multi-process environment, in the use of LOG4JS in fact there is a trap, may be a lot of people have met, let people startled.

In a single process environment, you use a file or datefile type of Appender instance to write the log, and scrolling is also set up for automatic cleanup of logs, scrolling by file size or date. But the two types of Appender are advanced rename when they reach the scrolling threshold, then create a new file and write the following to the new file.

For example: In an environment where datefile is scrolled by day, the log file name is Cheese.log

Rename Cheese.log cheese.log.2015-01-17
create file Cheese.log
write Cheese.log

In a single process environment, this is completely fine, but it can be problematic in a multiple-process environment. The problem is that each process performs the above rename and create operation. When multiple processes write the same file, it is virtually as long as a process performs rename and create operations.

For example:

<span style= "FONT-SIZE:12PX;" > Process A is first triggered, performing a day-change backup LOG operation:
rename cheese.log cheese.log.2015-01-17
create file Cheese.log
write Cheese.log
at some later time, process B is also triggered, and the second day of the backup log operation is performed:
rename cheese.log cheese.log.2015-01-17
create file Cheese.log
Write Cheese.log</span><span style= "FONT-SIZE:11PT;" >
</span>

See, after being executed the second time, 2015-01-16 data is actually lost, the cheese.log.2015-01-17 file content is only process a backup to process B backup, this time log. Now that the question is clear, let's think about the solution.

The key to the problem is that when multiple processes perform a day-after backup operation at different times, there is no problem if you can guarantee that only one process performs a new day backup.

Two of these types of appender are provided in LOG4JS, respectively clustered and multiprocess, all on the master process, and the worker process simply sends the log to master, All operations, such as log write backups, are performed by the master process. But this way has a disadvantage, the log through the network transmission, node is first slow rushed to the local array, and then provided to the socket buffer, if the network write speed than log write speed, then thought that the process of memory consumption will be more and more, finally imagined.

Another better way is to use the Datefile type of Appender, but set the Alwaysincludepattern property to True, which means that each write log is written directly in the CHEESE.LOG.2015-01-17 files like this, you can write to a new log file when you change the day. This eliminates the rename log process and avoids the confusion of log rename caused by multiple processes.

For clustered, multiprocess, datefile type of appender specific configuration, please see another blog "Log4js Configuration" in the "Datefile Configuration", "Multiprocess Configuration", "Cluster Configuration" Three of bars.

Log4js Total Three blog posts

"Log4js Principle Analysis" http://blog.csdn.net/hfty290/article/details/42844085

"Log4js Configuration Detailed" http://blog.csdn.net/hfty290/article/details/42843737

    LOG4JS multiple process traps and avoidance http://blog.csdn.net/hfty290/article/details/42843303