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.
Table 3-4. Configuration settings for HTTP logging
Parameter
Description
Default
Enabled HTTP Logging
This setting enables logging of HTTP requests for the particular server or virtual host.
true
Log File Name
This setting determines the filename to which the log messages are written. If you provide a relative filename, it is assumed to be relative to the root directory of the machine on which the server or virtual host is running.
ServerName/access.log
Format
This setting specifies the format for the HTTP access logs. Its value can be either common or extended.
common
Log File Buffer and Flush Seconds
This setting instructs the server to check every Flush seconds whether the internal HTTP log buffer has reached Buffer KB in size. If so, the contents of the log buffer are then written to the log file. As file writes are usually slow, this allows you to optimize how much data is written to the physical log file at one time, and how often.
8Kb and 60s
Log Rotation Type
This setting specifies how the access logs are to be rotated: when the size of the log file reaches a certain limit (size), or after a certain amount of time has elapsed (date).
size
Max Log File Size KB
If log rotation is based on size, this setting determines the size limit for the current log file before it is rotated.
5000
Rotation Period and Rotation Time
If log rotation is based on date, the log files are rotated at an hourly interval determined by the Period attribute. Such a rotation will begin at the time specified by the Rotation Time attribute.
1440
Limit Number of Retained Files and Number to Retain
If you have configured log file rotation, you can use these settings to limit the number of log files that will be retained.
No limit
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:
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!