HTTP Access Logs

HTTP access logs maintain a record of all HTTP requests received by WebLogic Server. You can separately configure HTTP logging for each web server or virtual host defined in your WebLogic domain. The information in the access logs may be written in one of two formats: either the Common Log Format or the Extended Log Format. The Common Log Format is the default format based on standard conventions. The Extended Log Format enables you to customize the information that is recorded in the access logs.

To configure the HTTP logging facilities for a web server, start the Administration Console, then go to the Servers node in the left frame and choose the Logging/HTTP tab. To configure logging for a virtual host, select the host from the Services/Virtual Hosts node and then choose the Configuration/Logging tab. Note that the logging facilities also include a "log rotation" mechanism, which means that WebLogic Server continues to use a log file until its size reaches a certain limit or for a certain time period. After that, WebLogic renames the log file and creates a new one in its place. Table 3-4 provides a description of the configuration settings for the HTTP logging facility.

Let's now examine the two formats for the HTTP access logs.

3.3.1 Common Log Format

The Common Log Format is the default log format used by WebLogic. This format is supported by many different web servers and is documented by the W3C organization. A typical entry in the HTTP access logs matches the following pattern:

remotehost RFC931 authuser [day/month/year:hour:minute:second UTC_offset] "request" status bytes

Here's a brief description of the fields used in the log entry:

remotehost

This field indicates the DNS name or IP address of the remote host.

RFC931

This field indicates the identifier associated with the remote user. WebLogic just inserts a - here.

authuser

This field indicates the name of the authenticated user making the request.

date

This field indicates the date and time of the HTTP request. It appears in the format [day/month/year:hour:minute:second UTC_Offset], where the offset is the difference (in hours) between the local time and GMT enclosed in square brackets.

request

This field indicates the first line of the request submitted by the client, enclosed in double quotes.

status

This field indicates the HTTP status code returned by the server, or - otherwise.

bytes

This field indicates the number of bytes listed as the content length in the HTTP header, or - otherwise.

3.3.2 Extended Log Format

The Extended Log Format is based on a draft W3C specification titled "Extended Log File Format." This format is more extensible, can be more easily parsed, and is highly configurable. The Extended Log Format allows you to define the type and the order of the information that is recorded for each HTTP request. WebLogic also allows you to define custom user-defined fields, and implement a Java class that generates the output for the fields.

The Extended Log Format allows you to customize which fields get recorded, and in what order. The actual log file defines a series of field directives in the head of the file. These directives determine the fields that ought to be recorded. Each directive begins on a new line and starts with a #. If the log file doesn't exist already, WebLogic creates a new log file with a default set of directives. WebLogic then will use the directives at the start of the log file to determine the format in which the HTTP access data should be logged.

For instance, we could create a log file with the following directives at the beginning:

#Version: 1.0 #Fields: date time bytes, sc-status x-com.oreilly.wl.httplog.MyField

These directives instruct WebLogic to record the date and time of the HTTP request, the HTTP status code returned by the server, and a user-defined field identifier whose output is generated by a Java class. For a complete description of other "standard" fields available under the Extended Log Format, refer to the draft specification available at http://www.w3.org/TR/WD-logfile.html.

All custom field identifiers are designated by an x- followed by the fully qualified name of a Java class that generates the output for the field. This Java class must implement the weblogic.servlet.logging.CustomELFLogger interface. This interface requires you to implement the logField( ) method, which gets invoked whenever HTTP access data ought to be logged. The method accepts two parameters:

• An HttpAccountingInfo object that provides access to the HTTP request and response data
• A FormatStringBuffer object that is used to generate the output

Here is an example of a Java class that implements a custom field identifier:

package com.oreilly.wl.httplog; // imports omitted public class MyField implements CustomELFLogger { public void logField(HttpAccountingInfo info,FormatStringBuffer out) { out.appendValueOrDash(info.getQueryString( );); } }

This method of logging is extremely powerful. The HttpAcccountingInfo gives total access to HTTP header information, information about the servlet (such as user principals), and session and parameter data. Nevertheless, custom user-defined fields should be used with some discretion. Because the logField( ) method gets invoked whenever a client accesses the HTTP server, you should ensure that the method performs its task in as short a time as possible!