Fundamentos teóricos presentes en la construcción de la

A Virtual Server can log the requests that users make to it. This is useful if you want to find out who has been to your web site and what pages they have

looked at. To specify what information should be recorded, and where, configure the logging functionality as follows:

1) Access the request logging page by clicking the Request Logging link in the configuration page menu.

2) Enable the request logging functionality by clicking the appropriate radio button.

Note that request logging is switched off by default, and it is recom- mended that you switch it on when setting up a new system.

3) Enter the full path and name of the file in which you want the logging information to be stored.42 To prevent users from viewing the log file, it is advisable to locate it outside the Virtual Server’s document root. 4) Click the Apply changes button.

Ensure that you commit the configuration for the changes to take effect, as described in Committing Configuration Changes on page 61.

The log file is created as soon as a user requests a file from your Virtual Server. The log file has the name you gave it with the current date appended to it. Each day a new log file is created43 and the day’s requests are recorded there. For example, if you enter /logs/myfile as the log file name, then log entries on the 30th April 2001 are saved in the file

/logs/myfile.20010430.44

Configuring the Log File Format

Each time a request is made to a Virtual Server, a new entry is made in the Virtual Server’s request log file. The entry can consist of various pieces of information, such as the IP address of the user who made the request, or the

42. The file path can contain %zeushome%, see The ZEUSHOME Environment Variable on page 370.

43. To log all requests to one file, rather than starting a new file every day, add the following line to the global.cfg file: tuning!modules!log!auto_rotate no

name of the URL they requested. The log file format string controls which pieces of information are included in each log entry.

By default, log file entries are in NCSA Common Log Format, which is the format most commonly understood by third-party log-analysis tools. You can change the format string to any one of a number of pre-defined formats, or create an customized string of your own. Using a customized string is useful because it gives you complete control over the content and layout of your log files.

You can configure the log file format in one of the following ways:

• To enter a customized format string, click the appropriate radio button, then enter the string, as described in the following section.

• To use a pre-defined format string, click the appropriate radio button, then select a format from the drop down list.

After configuring the log file format, click the Apply changes button.

Using a Custom Format String

The log file format string specifies which pieces of information about the requests are recorded in the log file. It can also contain additional text to make the log file entries more legible, including the carriage return character, \n.

The following codes can be included in the format string: The code... ...records...

%a The remote IP address

%b The number of bytes transferred in the request (including the HTTP header).

%B Specifies that log entries use Binary Logging Format. This format provides a compact representation of the standard NCSA Common Log Format. Log files in this format cannot be viewed until they have been converted into Common Log Format by using the blf2clf program (see The blf2clf Program on page 379 for details).

The %B code should not be used in conjunction with other codes.i

%f The filename portion of the URL requested.

%h The user’s IP address, or host name if your Virtual Server has DNSLookup enabled.ii

%H The request protocol (e.g. HTTP, HTTPS)

%l The remote logname. This is for compatibility only and will always return -

%m or %M The HTTP method used for the request.

%p The canonical port number of the server the request was received by.

%P The PID of the process that served the request

%q The query string of the request, (including the initial ?), or empty if there was no query string in the request. %r The first line of the request itself, in the format:

“method URL protocol/version” %s The HTTP status code returned by the Virtual Server. %t The date of the request, in the format:

“day/month/year:hh:mm:ss timezone“ %T The time of the request, in the format:

“YYMMDD-hhmmss”

%u The user’s username, if the user had to authenticate themselves by providing a username and password to access the URL.

%U The URL requested.

%v The name of the Virtual Server which dealt with the request.

%V The HTTP protocol and version in the format: The code... ...records...

Configuring Conditional Logging

You can specify that a code is only included in the format string if certain HTTP error codes have occurred. Do this by inserting the HTTP error codes as a comma-separated list between the % character and the code letter. For example, %401,403U is expanded to the requested URL only if the request returned a result code of 401 or 403. Otherwise it is entered in the log file as “-”.

%w The number of bytes of body transferred by the Virtual Server (excluding HTTP headers).

%{header-line}i An HTTP header line from the request. For example, %{cookie}i records the line in the request that starts with the word “cookie”.

%{header-line}o An HTTP header line from the output response. For example, %{Content-Type}o records the line of the response that starts with “Content-Type”.

%{name}n The contents of a note inserted by a module.

%{format}t The time, in the form given by format, which should be in strftime(3) format.

\n A carriage return, which can be used to format the log file so that entries are spread over more than one line. %{gzip_bytes_in}n The number of bytes of output generated before it was

compressed (see Configuring Content Compression on page 120).

%{gzip_bytes_out}n The number of bytes of output generated after it was compressed (see Configuring Content Compression on page 120).

%{gzip_compressi on_ratio}n

The percentage ratio of the compressed output to the uncompressed output (see Configuring Content Compression on page 120).

i Using the %B code within a custom format string is the same as selecting “Binary Log For- mat” from the list of pre-defined format strings.

ii For more information about turning on DNS Lookup, refer to Advanced Configuration Set- tings on page 98.

If you want information to be logged only if the Virtual Server does not return certain error codes, insert these HTTP codes between “%!” characters and the code letter. For example, the code %!200,301,302U is expanded to the requested URL if the error code is not 200, 301 or 302. Otherwise it is entered in the log file as “-”.

Logging SSI Requests

If you use SSI (Server Side Includes)45 on your web site, then, by default, Zeus Web Server automatically logs every request for every included file. For example, if you have a standard footer which is included on every web page, then two entries are made in the log file for every page requested, one for the page itself, and one for the footer.

You can eliminate these extra log entries and make the log file easier to read by turning off the logging of SSI requests, as follows:

1) In the Logging SSI Requests section, click the appropriate radio button. 2) Click the Apply changes button.

Ensure that you commit the configuration for the changes to take effect, as described in Committing Configuration Changes on page 61.

Consolidating and Splitting Multiple Request Log Files

If you are running web servers on a cluster of machines, or have multiple Virtual Servers or Subservers, you may want to consolidate your request logs in one file or directory, and then post-process them in some way. There are a number of ways to consolidate the files, depending on the configuration of

your web servers. You may want to combine one or more of the following methods to suit your specific requirements:

• Request Logging for a Cluster of Machines

If you have a Virtual Server that is running on a cluster of machines, request logging can be configured in the following ways:

• By specifying a file on the local machine. In this case a separate log file is created on each machine in the cluster.

• By specifying a file on a shared fileserver that all the machines have access to. If the machines log to a single shared file, you may encounter problems with file corruption due to the limitations of NFS file locking. To overcome this, Zeus Web Server provides a way to automatically use a different log file name for each machine, by including one of the following codes in the log file name:

For example, if you specify a log file name of

/usr/local/logs/%h, each machine creates a log file called /usr/local/logs/machine-name.created-date, in the shared network directory. All the request log files are stored in this directory, from where you can re-combine and post-process them. • Request Logging on Multi-Processor Machines

If your machine has multiple processors, Zeus Web Server provides a way to log requests handled by each processor in a separate log file. Do this

The code... ...is replaced by...

%h The name of the machine that the Virtual Server is running on.

%d The domain name of the machine that the Virtual Server is running on.

by using the following codes in the log file name. The codes are replaced by information about the processes running on your system, as follows:

For example, if you configure the log file name for a Virtual Server to be /usr/local/logs/p_%c this results in one log file being produced per processor. Each file has a name such as

/usr/local/logs/p_0.created-date, where the number corre- sponds to the processor that handled the requests. All the request log files are stored in the same directory, from where you can combine and post-process them.

• Sharing a Log File between Multiple Virtual Servers

To configure multiple Virtual Servers, running on one machine, to share the same request log file, do the following:

1) Configure each Virtual Server’s log file name to refer to the same file. 2) Configure each Virtual Server to produce its log file using a custom

format string. The log format string should start with the %{Host}i code. For example:

%{Host}i %h %l %u %t \"%r\" %s %b

This enables you to distinguish between log entries for different Vir- tual Servers by including the name of the Virtual Server in each entry in the file.

Zeus Web Server provides a script to split a combined log file into individ- ual files for each Virtual Server. See The subserver_logsplit.pl Script on page 378 for details.

• Request Logging for Subservers

If your Virtual Server supports Subservers, the request logging informa- tion for all Subservers is recorded in a single log file. Zeus Web Server provides a script to split the log file into individual sections for each Sub-

The code... ...is replaced by...

%p The Unix Process ID of the Zeus Web Server process. (There is one process per processor.)

server. For further information, see The subserver_logsplit.pl Script on page 378.