Tomcat 6 Access Logging

One of tomcat’s strength is in it’s logging but one of the logger types disabled by default from the base configuration is one that adds access logging support into tomcat.  This provides you with a view of activity that you may find useful for debugging, troubleshooting, usage analysis, etc. Enabling it is simply a matter of removing the comment for it in server.xml. If you’re going to turn it on however, this article will discuss some of the changes you may wish to make to the “pattern” configuration item so that you can log some additional interesting data because the defaults don’t actually tell you much.
The default logging format for tomcat is the same as it is for the apache web server, the Common Log Format. Common Log Format provides just the basics: remote host, date and time of the request, requested URI with method and protocol, http status code fo the request, and the number of bytes sent in the reply. You get some additional items like the remote logical hostname or the RequestURL Path but these always seem to show up in my tests as dashes. Configuring the valve is as simple as deleting a comment from the xml configuration file and you are off and running. Below is what the configuration entry should look like.

common logging output format

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="common_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>

A sample log entry in common log format will look something like the following:

common pattern result

127.0.0.1 - - [09/Aug/2008:14:49:16 -0400] "GET / HTTP/1.1" 200 8144

Combined format is similar to Common Log Format–the only difference is that Combined Log Format includes the User-Agent and the Referer. In the old days, you would have one logfile for accesses, one for user-agents, and one for referring sites—the combined log file format was then created to give you a single consolidated log that contained elements from all three previous logs.  Today’s tomcat does not default to three separate log files–just the one in CLF format.  To utilize combined log format, change the configuration valve entry in server.xml to look something like this:

combined logging output format

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="combined_access_log." suffix=".txt" pattern="combined" resolveHosts="false"/>

Requests made to tomcat would look something like the following:

combined pattern result

127.0.0.1 - - [09/Aug/2008:14:49:16 -0400] "GET / HTTP/1.1" 200 8144 "null" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"

As you can see, the combined log format simply appends the Referer (“null” in my example since I went directly to the site) and the user-agent (most commonly also known as the browser version).
Since tomcat gives you a lot more options though, why not have some fun with them. Below is a blackbox format, similar in spirit to one for apache logs discussed in this article from 2004. This not only logs fields from the combined log format but adds a lot more interesting items like the local tcp port, thread, sessionid, etc.

blackbox logging output format

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="blackbox_access_log." suffix=".txt" pattern="%t %h %{Referer}i %l %S %{User-Agent}i %U %s %r %q %A %v %p %b %I %D" resolveHosts="false"/>

blackbox pattern result

[09/Aug/2008:14:49:16 -0400] 127.0.0.1 null - - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 / 200 GET / HTTP/1.1 192.168.1.5 localhost 8080 8144 http-8080-1 0

In this format above, reading left to right, we can see that a user at IP Address 127.0.0.1 came directly to the site (the null is the referral) using Firefox 3.0.1 on Vista submitted a GET request for the root of the site using the HTTP/1.1 protocol. The server IP address and server instance name and server port, number of bytes in the response and tomcat thread that fulfilled the request is included as well. Time taken to process the request is at the end of the line.