A Guide to Application Logging in Tomcat
Understanding how logging in Tomcat works and how to correctly set up logs to monitor applications is key step in Tomcat configuration. In this blog, our expert explains Tomcat application logging, from the different types of logs and frameworks, to best practices for configuration and common mistakes.
What Are Tomcat Logs?
Back to top
Apache Tomcat uses logging mechanisms to record and report information about its operations, issues, and other important events. Understanding Tomcat's logging system is crucial for troubleshooting, monitoring, and maintaining applications running on Tomcat servers.
Types of Tomcat Logs
Access logs record every request made to the server, including details like the requested URL, client's IP address, response status, and more. Access logs are useful for analyzing traffic patterns and identifying potential attacks. The access log is separate from Tomcat’s logging framework, and it is optimized for performance as this log will be the most frequently accessed file by Tomcat. This log is output in Tomcat’s log directory and can be configured in
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
Access logs are rotatable, and a maximum number of days can be set to automatically delete these files. The Tomcat project page on the Apache site has a complete reference on how to configure this class.
Tomcat’s core console logging file by default is named
catalina.out and this is where standard out is sent by default. Tomcat’s startup and shutdown is contained in this log, as well as any deployment activities. It is desirable to keep this log as quiet as possible — using this log as the application log is not advisable as it can make troubleshooting difficult.
Also, it is not recommended to use
System.out.println() as a logging mechanism. There are frameworks, and frameworks for the frameworks, like Simple Logging Façade for Java (SLF4J) for application-specific logging. Whatever framework that is used, it is important that any application logging goes to its own log file.
In addition, Tomcat has a
host-manager.log that produces log output for the Tomcat manager web application, with the latter containing activity for the Tomcat manager web application for virtual hosts.
Finally, there is application logging provided by the servlet logging API
(javax.servlet.ServletContext.log(...)). The servlet logging API provides very basic logging, and it is not flexible for most use cases.
Tomcat Logging Framework
Tomcat uses Java's
java.util.logging framework by default; however, it can also be configured to use other logging frameworks like Log4j or SLF4J.
The logging configuration in Tomcat is managed through a properties files (
logging.properties by default) or XML configurations. This file controls the default logging behavior of Tomcat. It specifies handlers, formatters, log levels, and where the logs are stored. You can modify this file to change the logging behavior or how the logging is handled. A handler is configured to define where log messages are sent such as log levels, log file locations, output formats, and more.
java.util.logging.FileHandler (the default) are two common handlers used by Tomcat. The former writes log messages to the console, and the latter writes to a specified log file.
The loggers for this framework are in a hierarchy which typically follows the Java package hierarchy (e.g.
org, org.apache, and
org.apache.tomcat) and usually matches class names in Tomcat. Log levels can be set at any point in the package hierarchy and have the option to pass a log message up the hierarchy.
java.util.logging framework is easy to use, but it has a few limitations. It is not class loader aware, which means there can be package and class name conflicts between web applications, and the configuration file only allows one instance of a handler type.
The Java Util Logging Implementation (JULI) framework can also be configured with Apache Tomcat. This framework is class loader aware, meaning that multiple web applications can define their own handlers per app without conflicts. JULI allows its logs to be rotatable and have a max retention; it also allows multiple handlers of the same type, so logs can be sent to the console and to a file at the same time.
Back to top
Get More Tips From Tomcat Experts
Choosing Tomcat is easy, but finding long-term success can be tricky. Our free Enterprise Guide to Apache Tomcat includes best practices for performance tuning, memory configuration, security, resilience, and more.
How to Configure Tomcat Logs
logging.properties, log levels for different components or packages can be set to the following:
SEVERE: A critical problem which prevent the server or an application from starting
WARNING: Indicates potential issues or situations that may need attention, i.e. unregistered JDBC drivers or memory leaks
INFO: Informational messages (this is the default)
CONFIG: Messages related to application server configuration
FINE: Trace logs
FINER: More detailed trace logs
FINEST: Highest detailed trace logs
ALL: Outputs all log messages regardless of level; produces a lot of output
Log level messages cascade up in the list provided above. With the
INFO log level being the default, this means that
SEVERE messages will be output to the log. Setting a logger at
FINER level will show
Different log levels for different components or packages can be set in
logging.properties. For instance:
# Setting the root logger level
.level = INFO
# Setting the level for a specific package
org.apache.coyote.http2.level = FINE
This example sets the log level for across all packages to
INFO, but sets the log level to
FINE for the package
Back to top
It's important to be very selective when choosing a log level for a package especially in production. The broader and finer the log level is, the more pressure it will put on the CPU and disk to write tons of log messages which could potentially exhaust disk space. For example, do not use a log level of
ALLfor the package
Tomcat Log Examples
Unsure of what packages to enable logging on instead of enabling all logging? Here are a few examples:
Logs all session related activity in the servlet container (Catalina):
FINE and above log levels for the HA clustering component of Tomcat:
Logs all database connection pooling API calls:
Back to top
Enabling and Viewing Tomcat Logs
Tomcat logs are enabled by default and can be viewed with any editor such as
less commands. If you are unsure where a particular log file is located, then open the
logging.properties in Tomcat’s conf directory. Near the top of the file, it will show JULI file handlers for the catalina, access, manager, and host-manager logs. Running the following command will also reveal all the files that are in use by a Tomcat process:
lsof -p <Tomcat process ID>
Common Tomcat Logging Problems
Some Tomcat users will try to set a package to
DEBUG and then not receive the expected output in the log. This happens because there is no
DEBUG log level in Apache Tomcat unless the application is using another framework, such as Log4j, which supports it.
If you are making changes to
logging.propertiesand the expected logging is not being observed, then you might be modifying the wrong file. The location of
logging.propertiesused by Tomcat is set by a JVM argument,
“-Djava.util.logging.config.file=…”. If you are unsure which
logging.properties file is being used by Tomcat, then get a list of arguments on Tomcat's process ID:
ps -ef | grep <Tomcat process ID>.
Tomcat logs contain valuable information about web traffic (like where your visitors are located and what they are doing on your site) and can help identify server performance issues. Figuring out the optimal log settings make take some trial and error, depending on your use case and applications, as well as what version of Tomcat you are running. Ultimately, the goal is to generate logs that you can use to optimize your Tomcat deployments and troubleshoot when problems arise.
Struggling With Apache Tomcat? Get SLA-Backed Support
OpenLogic Enterprise Architects can solve your toughest Tomcat challenges to get your deployment(s) back on track. Chat with an expert today or see what we offer:
- White Paper - Enterprise Guide to Apache Tomcat
- Blog - Troubleshooting Tomcat Errors
- Blog - Apache Tomcat Security Best Practices
- Blog - Tomcat 11 Preview
- Guide - Apache Tomcat Overview
- Blog - 5 Apache Tomcat Performance Best Practices
- Blog - Apache Tomcat Clustering: The Ultimate Guide
- Webinar - Taming Tomcat: Key Considerations for Enterprise Deployment