8

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?

Nino Walker
  • 2,742
  • 22
  • 30

2 Answers2

2

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.

DXM
  • 4,413
  • 1
  • 19
  • 29
  • Like minds :) Assuming you know, but for the public record, with rsyslog you can set $MaxMessageSize (http://www.rsyslog.com/doc/rsyslog_conf_global.html), and the `SyslogAppender` can handle up to 64k long messages (https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/net/SyslogAppenderBase.java#L229). – Nino Walker Oct 02 '13 at 03:31
  • As a note on the logback `SyslogAppender` it only supports UDP transport, and not named pipes or TCP. – Nino Walker Oct 02 '13 at 03:34
  • Accepting this answer because it is consistent with the question, but @Jeff's answer will also be good, depending on your needs. – Nino Walker Oct 10 '13 at 23:24
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.

Jeff
  • 956
  • 8
  • 10
  • 2
    Jeff, I appreciate this perspective. But, my goal is operational convergence if there's a reasonable path to it; especially as we are also dealing with log-shipping containing important data; not just for audit/debug. Thoughts? – Nino Walker Oct 06 '13 at 05:57
  • I know this is old. Even so, wanted to comment that I found a disadvantage of using TimeBasedRollingPolicy. The logs are owned by the same user running the app. I don't like it since it opens a way for a hacker to delete them when there could be evidence about how he or she managed to break in. Don't you think? Do you know of an alternative? – elysch Jul 11 '15 at 15:25