Using logrotate with logback

Question

When using logback in conjunction with logrotate, what is the recommended configuration? Based on a survey blogs and such, the implicit recommended configuration is to use FileAppender.append=true and then logrotate's copytruncate option.

Is this correct? Are there dragons here I need to be aware of?

Answer 1

I'm not sure what the correct way is because earlier today I've come across this question only because I was looking for the same answer.

I think this approach would work, however it has two relatively minor problems (if you can even call them that):

• There is a race condition window where log data might get lost between the time logrotate makes a copy of the data and when truncation of that data happens
• Logrotate has to copy the entire file, which seems a bit wasteful compared with the typical approach of SIGHUP which closes/reopens log files.

In my own search, I'm now contemplating of switching from FileAppender (or Rolling one) to a SysLogAppender and using logrotate with rsyslog, both of which work very naturally together. Then again, the reason I'm considering this is because we have other python daemons in our systems and those daemons already use rsyslog. My only reservation of switching to SysLogAppender is that I don't know how it handles exception stack traces since syslog doesn't allow messages longer than 1024 chars.

And in answer to Martin Schroder's comments, I think I want to make the switch for the reason as you are. So that our logging configuration across all our services is configured and handled the same way and has the same behavior.

Answer 2

Having done this for multiple customers for many years, the favored approach has been to use TimeBasedRollingPolicy, rolling daily (can set to any frequency) and setting MaxHistory to desired number of days (often has been 30).

While I like and use logrotate for other log files, Logback's built in rolling means logrotate has not been necessary for my customers.

To coordinate across apps/centralize, Logback can include other Logback config files, so you can define a standard appender snippet in a file (Logback supports properties, so the including file can define the info as needed).

Even with the above, there may be desires that logrotate has that Logback does not... however I wanted to share the TimeBasedRollingPolicy in case it was overlooked.

At minimum, this approach could have logrotate work on the Logback rolled file, avoiding the potential issues with logrotate operating on the active Logback log file.

And keeping the logs isolated (don't mix the app logs into the syslog) has been very helpful with troubleshooting (apps and system) - neither has to deal with the others' noise.