Am Thu, 21 Oct 2010 11:13:53 +0200 schrieb André Warnier <a...@ice-sa.com>:
> In addition, it is somewhat of a moving target, since Linux > distributions seem to each superpose their own schemes to the > standard Tomcat scheme (like using jsvc, and/or re-directing to > SYSLOG e.g.). Today this is necessary because the default installation of Tomcat delivers (somehow) "managed logs" like catalina.2010-10-20.log and unmanaged logs like catalina.out at the same time. Deploying a logging facility on a server (e.g. Linux-based OS) for one or more Tomcats on one hardware / OS can become difficult because on the one hand you need a way to disconnect log file access during rotation or deletion of the log file and on the other hand you might need a logging facility that separates logging of each Tomcat-installation of one server AND gives the different Tomcats the necessary rights to write / send their log data to "their" log file. In addition it might be necessary that a "webapps" of Tomcat needs random access to the log data of "its" Tomcat to do some file analysis (e.g. Lambda Probe, Chainsaw, Splunk) which won't work if you use syslogd. Using syslogd instead file-handler might be an alternative but of course this is OS-specific. At our company we are using MS-Win for developers and CentOS/Debian/Solaris for production (and I guess that this is a typical scenario) and so we are interested in a "general" solution. This leads of course to a Java-based solution but it should work more predictable than the JULI-setup of Tomcat. > Anyway, I am interested in finding a scheme, based on JULI, and > which : > - would generally-speaking start by directing ALL Tomcat logs to one > single file, NOT rotated by JULI I think a default setup of Tomcat should deliver a logging that isn't growing endless by design. This means it should use log rotation with a clearly limited number of generations. Today "catalina.YYYY-MM-DD.log" (and "friends") seem to have no limit of generations. I wouldn't care if the rotation is happening time controlled or size controlled but initially there should be a maximal possible number of files that could be created. One file-pattern for default-Tomcat (without webapps) is enough - actually I still have no idea what all these "standard-0-Byte-logs" are used for. > - would use the system facilities (aka logrotate), to rotate, > compress and archive this logfile as I see fit, not as JULI sees fit. This could get difficult because you have to pause Tomcats access to the log files during external log rotation. Today you already have to do this in order to rotate catalina.out. We do this during a daily Tomcat-reboot every night at about the same time as the logrotate-cronjob but actually this is just a hack and there is no real synchronisation between these two events (like the reload of Apache2 by logrotate). And it would be OS-specific. > - would provide a simple path to, /when needed/, provide more > specific logfiles for one or the other application. > (but not the current standard unmanageable mess) > - create a Tomcat FAQ that explains how to do the above, so that > other sysadmin-types can enjoy the fruits of my labor > > There is already a lot of scattered information on this topic in the > archives of this list, but to my knowledge nothing really > comprehensive at one single location. This is my impression as well. Another source I use often is the book "Professional Apache Tomcat 6" but some of the described features (or attributes) doesn't work, too - e.g. generation-parameter "%g" that works if you use it for your own application but not in Tomcats conf/logging.properties. I think the concept of java.util.logging or JULI isn't so bad but 1. Tomcat shouldn't supersede parameters in the logging.properties, 2. Tomcat should inform about faults in logging.properties, 3. we need a complete documentation of logging.properties, and 4. "0-byte-logfiles" like admin, host-manager, localhost and manager should be left out by default. Regards, Tobias. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
