Access Logging
Logging a record of each request made to the server is actually unrelated to the other types of logging. Tomcat provides this ability via the AccessLogValve configuration element, which can be defined in the conf/server.xml, conf/context.xml, or application context descriptor. Please consult the AccessLogValve documentation for your version of Tomcat.
With tc Server, Hyperic provides a management interface for configuring access logs on tc Runtime instances. Other types of logging described below are not configurable through this interface.
Console Logs
Output from an application that would go to the console (standard error or standard output), including uncaught exceptions, thread dumps requested by signal, or plain System.out or System.err calls, is caught and redirected to a log file. This is generally referred to as catalina.out, though the actual log may have different names depending on platform and packaging.
Under default configuration, console output from Tomcat and all applications are logged together in this log. To separate out application console output, set the swallowOutput="true" attribute on the Context configuration element for the application. This can be done globally in the conf/context.xml file for the Tomcat instance. With this setting, console output is directed through the servlet context logger specific to the application (as described later), leaving only a few messages from Tomcat or the JVM in the console log.
Note: there are some limitations to what swallowOutput can capture (see
documentation for details).
It is not possible to configure the level of messages Tomcat writes to console logs, as the console has no concept of level. This log is simply text output from the JVM. File size may be limited by redirecting application output with swallowOutput or by rotating the log file.
Rotation of the console logs under Windows can be configured in the service wrapper.
- Rotating the console logs under Linux or Unix involves directing output to a log rotation program in the startup script.
Tomcat Internal Logging
By default, log messages generated by Tomcat itself are handled by a Tomcat-specific implementation of Apache Commons Logging, which is hardwired to wrap a Tomcat-specific customization of java.util.logging called JULI. These are necessary to overcome the inability of the standard JUL implementation to handle separate configuration for multiple classloaders. These defaults can be replaced with a different logging implementation as described in the logging documentation for your version of Tomcat.
Logging for the defaults is configured in the conf/logging.properties file for a Tomcat instance. This file defines logging handlers (which by default are configured to log to various files), as well as log levels by server components, or by class packages. Default logging thresholds are INFO and can be set using SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL.
Note: You must change the log level and relevant handler level in order to allow thresholds more verbose than INFO.
For more information on JULI configuration, see the logging documentation for your specific version of Tomcat.
Web Application Logging
Individual applications have several options for formal logging:
- If used (directly or indirectly), Tomcat's JULI is used for all such applications when the system java.util.logging API . Separate configuration per application can be specified with the application WEB-INF/classes/logging.properties file.
- The Java Servlets specification API, javax.servlet.ServletContext.log(...) - strings are logged at the INFO level, while ERROR level is used if a Throwable parameter is included. With swallowOutput set to true for a Context, console output is also directed through this route at INFO level. Thus, log level configurability is minimal.
These messages are handled by internal Tomcat logging under the category org.apache.catalina.core.ContainerBase.[${engine}].[${host}].[${context}]. For example, an app deployed at the /foo context could limit logging with the following line in conf/logging.properties:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/foo].level = ERROR
- Bundled logging implementations, including the logging implementation and configuration in individual webapps, allows complete separation. The destination for logging statements depends on the log method that results:
- Messages directed through java.util.logging are handled by Tomcat JULI as above.
- Console output is directed to the console log unless redirected by swallowOutput as described above.
- Output to file, database, email, etc. works as configured in the individual application (Tomcat has no direct role).
Some applications, or their dependencies, may informally log with System.out or System.err statements, resulting in output to the console log. For more information, see the Console Logging section above.
Impact/Risks
Excessive logging can slow down a production server significantly. However, it is difficult to determine in advance how much of a performance impact results.
When enabling logging in production, use logging settings that are as narrowly targeted to your needs as possible. You may not need to restart Tomcat in order to change the logging settings. You can configure Tomcat to allow connection and configuration with JConsole or other JMX tools at runtime.
For information on configuring Tomcat to allow connection and configuration with JConsole or other JMX tools at runtime, see
Pivotal documentation for Pivotal tc Server.
Note: Pivotal tc Server 4.0.x is discussed in the documentation, but this content is the same for all versions. This can be useful for configuring logging in production only as needed without interrupting service.