LOG4JS Multi-process traps and avoidance

Log4js Multi-process traps and avoidance

based on Log4js 0.6.14 version

Log4js Total Three blog posts

"Log4js Principle Analysis" http://write.blog.csdn.net/postedit/42844085

Detailed configuration of Log4js http://blog.csdn.net/hfty290/article/details/42843737

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

in thenodedue to the existence of a single process memory1.4GBthe upper limit, so in some large systems, it is common to useClusterthe way to run. In theClusterenvironment, in a multi-process environment, usingLog4jsIn fact there is a trap, many people may have met, let the people are startled.

in a single-process environment, you will usefileorDatefiletype ofAppenderinstance to write the log, and to scroll through the file size or date for automatic clearing of the log. But these two types ofAppenderwhen the scrolling threshold is reached, advancedRename, and then create a new file that writes the following content to the new file.

For example: in Datefile in an environment that scrolls by day, the log file is named Cheese.log

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

In a single-process environment, this is completely fine, but in a multi-process environment there is a problem. The problem is that every process has to execute the aboveRenamewith theCreateoperation. When a multi-process writes the same file, virtually as long as there is one process executingRenamewith theCreatethe operation will be fine.

For example:

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

look out, after being executed a second time,2015-01-16the data on it is actually lost,CHEESE.LOG.2015-01-17file content is just a processAback up to processBback up the logs for this period of time. Now that the problem is clear, let's think about the solution.

The key to the problem is that when multiple processes perform a change-of-day backup operation at different times, there is no problem if only one process is guaranteed to perform a day-to-month backup.

in theLog4jsTwo of these types are available in theAppender, respectively isClusteredwith themultiprocess, are inMasterprocess to turn on monitoring,workerthe process simply sends the log toMaster, log write backups, and so on.Masterprocess. But there is a drawback to this approach, where logs are transmitted over the network,nodeis to slow down to the local array and provideSocketbuffer, if the network writes slower than the log write speed, then thought the process of memory consumption will be more and more, finally imagined.

Another better way is to useDatefiletype ofAppender, but setAlwaysincludepatternproperty istrue, which means that each write log is written directly inCHEESE.LOG.2015-01-17on such a file, write to the new log file on the day of the change. This way, it removes theRenamelog process, thus avoiding multiple process-induced logsRenameconfusion.

about theClustered,multiprocess,Datefiletype ofAppenderspecific configuration, see another blog, "Log4jsin the detailed configuration"DatefileConfiguration","multiprocessConfiguration","ClusterConfiguration"the three bars.

Log4js Total Three blog posts

"Log4js Principle Analysis" http://write.blog.csdn.net/postedit/42844085

Detailed configuration of Log4js http://blog.csdn.net/hfty290/article/details/42843737

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

LOG4JS Multi-process traps and avoidance