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?

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 conf/server.xml:

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %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 manager.log and 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.ConsoleHandler and 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. 

The 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. 

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. 
Download Now

How to Configure Tomcat Logs

In 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 INFO, WARNING, and SEVERE messages will be output to the log. Setting a logger at FINER level will show FINER, FINE, CONFIG, INFO, WARNING, and SEVERE messages.

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 org.apache.coyote.http2.

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 ALL for the package org.apache.

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):

org.apache.catalina.session.level=ALL

Logs FINE and above log levels for the HA clustering component of Tomcat:

org.apache.catalina.ha.level=FINE

Logs all database connection pooling API calls:

org.apache.tomcat.dbcp.level=ALL

Enabling and Viewing Tomcat Logs

Tomcat logs are enabled by default and can be viewed with any editor such as vim, nano, or 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>.

Final Thoughts 

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:

Talk to a Tomcat ExpertDownload Tomcat Support Datasheet

Additional Resources

• 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