Access log with logback and Jetty

Authors: Ceki Gülcü, Sébastien Pennec
Creative Commons License

Copyright © 2005-2006, QOS.ch

This work is licensed under a Creative Commons Attribution 2.5 License.

Introduction

Logback was designed as a modular framework from the start. Being able to use logback's internal core in many situations, without heavy coding or complex specific configuration was one of our goals.

Lobgack access integrates with Servlet containers such as Jetty and Tomcat to provide HTTP-access log functionality.

Integrating logback into Jetty is rather simple. Once done, you can benefit from the power and flexibility found only in fully-fledged logging systems.

To use logback-access with Jetty, after downlading the logback distribution, place the files logback-core-VERSION.jar and logback-access-VERSION.jar under $JETTY_HOME/lib directory, where $JETTY_HOME is the folder where you have installed Jetty. We tested logback-access module with Jetty version 6.0.1.

Logback's RequestLog implementation

The ch.qos.logback.access.jetty.RequestLogImpl class implements jetty's RequestLog interface. This interface is used by Jetty to allow external components to manage request logging.

In logback, logging destinations are called Appenders. These classes can be attached directly to RequestLogImpl.

To configure jetty in order to use logback's RequestLogImpl, add the following lines to the jetty configuration file, namely $JETTY_HOME/etc/jetty.xml:

<Ref id="requestLog">
  <Set name="requestLog">
    <New id="requestLogImpl"
      class="ch.qos.logback.access.jetty.RequestLogImpl">
    </New>
  </Set>
</Ref>

These lines reference the requestLog functionnality of Jetty, setting the actual class that will be called at each logging request.

By default, RequestLogImpl looks for a logback configuration file called logback-access.xml, in the same folder where jetty.xml is located. This configuration file contains directives for configuring logback components. Among others, you can specify the appenders where the logging requests will be sent, and their format.

Altough similar, the logback-access.xml file is slightly different than the usual logback classic configuration file. Appenders and Layouts are declared the exact same way. However, in the access module there is no notion of loggers and consequently loggers elements are disallowed in configuraiton files for logback-access.

As long the path is specified, you can place the logback configuration file in other location. Here is another example of jetty configuration file, with a path to the logback access configuration file.

<Ref id="requestLog">
  <Set name="requestLog">
    <New id="requestLogImpl"
      class="ch.qos.logback.access.jetty.RequestLogImpl">
    </New>
    <Set name="fileName">path/to/myaccess.xml</Set>
  </Set>
</Ref>

Example 1: logback-access configuration

Here is a sample logback-access.xml file that you can immediately put to use:

<configuration>
  <appender name="STDOUT"
    class="ch.qos.logback.core.ConsoleAppender">
    <layout
      class="ch.qos.logback.access.PatternLayout">
      <Pattern>%h %l %u %user %date "%r" %s %b</Pattern>
    </layout>
  </appender>

  <appender-ref ref="STDOUT" />
</configuration>

It declares a ConsoleAppender which directs its output at the console. The ConsoleAppender contains a PatternLayout format the output. The log format is specied using the %h %l %u %user %date "%r" %s %b" pattern which is the Commong Log Format (CLF). This format is recognized by log analysers such as Analog or AWStats.

Instead of specifying the complete pattern, the word "common" or "clf" can be used as a shorthand. Thus, the following are all equivalent

<Pattern>%h %l %u %user %date "%r" %s %b</Pattern>
<Pattern>common</Pattern>
<Pattern>clf</Pattern>

The so called "combined" format is also widely recognized. It is defined as the '%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"' pattern. As a facilitator, you can use the "combined" as a shorthand. Thus, the following directive

<layout class="ch.qos.logback.access.PatternLayout">
  <Pattern>%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"</Pattern>
</layout>

is equivalent to:

<layout class="ch.qos.logback.access.PatternLayout">
  <Pattern>combined</Pattern>
</layout>

Example 2: RollingFileAppender

Another configuration file, using logback' RollingFileAppender, could be:

<configuration>
  <appender name="FILE"
    class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy
      class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <ActiveFileName>access.log"</ActiveFileName>
      <FileNamePattern>access.%d{yyyy-MM-dd}.log.zip</FileNamePattern>
    </rollingPolicy>

    <layout class="ch.qos.logback.access.PatternLayout">
      <Pattern">combined</Pattern">
    </layout>
  </appender>
 
  <appender-ref ref="FILE" />
</configuration>

Here, there is no output to the console. Instead, logback access logs to the file named access.log. This file will be rolled over every 24 hours. We specify in the configuration the name of the file where the actual logging is added, and the pattern that the archived files must match. The newly archived file will be automatically compressed.

These two configuration examples should give you an idea of the possibilities offered by the logback-access module. In principle, most of the things that you can do with logback-classic module are equally possible with logback-access.

PatternLayout

An http-specific implementation of PatternLayout is included in the access module. The ch.qos.logback.access.PatternLayout provides a way to format the logging output that is just as easy and flexible as the PatternLayout found in logback classic.

Logback access PatternLayout offers the following possibilities:

Conversion Character or Word Effect
a / remoteIP

Remote IP address.

A / localIP

Local IP address.

b / B / byteSent

Response's content length.

h / clientHost

Remote host.

H / protocol

Request protocol.

l

Remote log name. In logback-access, this converter always returns the value "-".

reqParameter{paramName}

Parameter of the response. This conversion word can be followed by a key whose corresponding data will be extracted from the header information.

i{header} / header{header}

Request header. Just like the reqParameter conversion word, reqParameter can be followed by a key.

m / requestMethod

Request method.

r / requestURL

URL requested.

s / statusCode

Status code of the request.

t / date

Date of the event.

u / user

Remote user.

U / requestURI

Requested URI.

v / server

Server name.

localPort

Local port.

reqAttribute{attributeName}

Attribute of the request. Just like the reqParameter conversion word, reqAttribute can be followed by a key.

reqCookie{cookie}

Request cookie. Just like the reqParameter conversion word, reqCookie can be followed by a key.

responseHeader{header}

Header of the response. Just like the reqParameter conversion word, responseHeader can be followed by a key.