[Deploying Sakai] Sakai CLE, log4j, and Tomcat logs

Seth Theriault slt at columbia.edu
Thu Feb 16 08:06:05 PST 2012


Hello,

[pardon the cross-posting]

The short question(s): How are you dealing with your production 
Tomcat logs? Are you overriding the default log4j.properties with 
different appenders or the like? Do you ever "lose" Tomcat logs?

Locally on Sakai 2.8, we override the default log4j.properties to 
send our Tomcat logs to a logs directory on each app server:

[...]
# Use "daily" instead of "Sakai"
log4j.rootLogger=INFO,daily

# Configuration for a daily rolling log file
log4j.appender.daily=org.apache.log4j.DailyRollingFileAppender
log4j.appender.daily.DatePattern='.'yyyy-MM-dd
log4j.appender.daily.File=/var/log/sakai.log
log4j.appender.daily.layout=org.apache.log4j.PatternLayout
log4j.appender.daily.layout.ConversionPattern=%d %-5p [%t] [%c]: %m%n
log4j.appender.daily.Encoding=UTF-8
[...]

This config works fine for the first 24 hours after Sakai is 
started, but soon after the first log rotation, it becomes 
unclear which log file (sakai.log or a sakai.log.yyy-MM-dd) Sakai 
is actually logging to. After a few days, it doesn't appear to 
be logging to any file at all. A quick "lsof -p <sakaipid>" often 
shows multiple log files open.

Obviously, this is frustrating. I have thought about sending 
everything over syslog to a different server, but that's not 
really practical in my environment.

One option that I have been toying with most recently is 
replacing Sakai's log4j back-end with Logback, its successor:

http://logback.qos.ch/

Logback relies on SLF4J, a widely used logging abstraction layer, 
that we already using via its legacy API bridges:

http://www.slf4j.org/legacy.html

in the kernel and some of the Wicket-based tools.

This requires a bit of work (and the licensing needs to be 
checked into), so I'd be interested in hearing what everyone else 
does first.

Seth



More information about the production mailing list