mod_log_sql 2.0 Documentation

Home » Projects » Apache » Mod_log_sql » Docs-2.0 » mod_log_sql 2.0 Documentation

Prev: Table Names --- Up: Configuration Directive Reference --- Next: Deprecated Commands

Configuring What Is logged

LogSQLTransferLogFormat
LogSQLTransferLogFormat format-string

Example: LogSQLTransferLogFormat huSUTv

Default: AbHhmRSsTUuv

Context: virtual host

Each character in the format-string defines an attribute of the request that you wish to log. The default logs the information required to create Combined Log Format logs, plus several extras. Here is the full list of allowable keys, which sometimes resemble their Apache counterparts, but do not always:

Table 6: Core LogFormat parameters
Symbol Meaning DB Field Data Type Example
A User Agent agent varchar(255) Mozilla/4.0 (compat; MSIE 6.0; Windows)
a CGi request arguments request_args varchar(255) user=Smith&cart=1231&item=532
b Bytes transfered bytes_sent int unsigned 32561
c [1] Text of cookie cookie varchar(255) Apache=sdyn.fooonline.net 1300102700823
f Local filename requested request_file varchar(255) /var/www/html/books-cycroad.html
H HTTP request_protocol request_protocol varchar(10) HTTP/1.1
h Name of remote host remote_host varchar(50) blah.foobar.com
I Request ID (from modd_unique_id) id char(19) POlFcUBRH30AAALdBG8
l Ident user info remote_logname varcgar(50) bobby
M Machine ID [2] machine_id varchar(25) web01
m HTTP request method request_method varchar(10) GET
P httpd cchild PID child_pid smallint unsigned 3215
p http port server_port smallint unsigned 80
R Referer referer varchar(255) http://www.biglinks4u.com/linkpage.html
r Request in full form request_line varchar(255) GET /books-cycroad.html HTTP/1.1
S Time of request in UNIX time_t format time_stamp int unsigned 1005598029
s HTTP Response Code Status status smallint 200
T Seconds to service request request_duration smallint unsigned 2
t Time of request in human format request_time char(28) [02/Dec/2001:15:01:26 -0800]
U Request in simple form request_uri varchar(255) /books-cycroad.html
u User info from HTTP auth remote_user varchar(50) bobby
v Virtual host servicing the request virtual_host varchar(255) www.foobar.com
V requested Virtual host name (mass virtualhosting) virtual_host varchar(255) www.foobar.org
Table 7: SSL LogFormat Parameters
Symbol Meaning DB Field Data Type Example
z SSL cipher used ssl_cipher varchar(25) RC4-MD5
q Keysize of the SSL connection ssl_keysize smallint unsigned 56
Q maximum keysize supported ssl_maxkeysize smallint unsigned 128
Table 8: LogIO LogFormat Parameters
Symbol Meaning DB Field Data Type Example
i Number of actual Bytes transfered in with the request bytes_in int unsigned 505
o Number of actual Bytes transfered out with the request bytes_out int unsigned 4168
LogSQLRemhostIgnore
LogSQLRemhostIgnore hostname ...

Example: LogSQLRemhostIgnore localnet.com

Context: virtual host

Lists a series of smortrings that, if present in the REMOTE_HOST, will cause that request to not be logged. This directive is useful for cutting down on log clutter when you are certain that you want to ignore requests from certain hosts, such as your own internal network machines. See section Instructing the module what NOT to log using filtering directives for some tips for using this directive.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

Each string is separated by a space, and no regular expressions or globbing are allowed. Each string is evaluated as a substring of the REMOTE_HOST using strstr(). The comparison is case sensitive.

LogSQLRequestAccept
LogSQLRequestAccept substring ...

Example: LogSQLRequestAccept .html .php .jpg

Default: if not specified, all requests are 'accepted'

Context: virtual host

Lists a series of strings that, if present in the URI, will permit that request to be considered for logging (depending on additional filtering by the "ignore" directives). Any request that fails to match one of the LogSQLRequestAccept entries will be discarded.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

This directive is useful for cutting down on log clutter when you are certain that you only want to log certain kinds of requests, and just blanket-ignore everything else. See section Instructing the module what NOT to log using filtering directives for some tips for using this directive.

Each string is separated by a space, and no regular expressions or globbing are allowed. Each string is evaluated as a substring of the URI using strstr(). The comparison is case sensitive.

This directive is completely optional. It is more general than LogSQLRequestIgnore and is evaluated before LogSQLRequestIgnore . If this directive is not used, all requests are accepted and passed on to the other filtering directives. Therefore, only use this directive if you have a specific reason to do so.

LogSQLRequestIgnore
LogSQLRequestIgnore substring ...

Example: LogSQLRequestIgnore root.exe cmd.exe default.ida favicon.ico

Context: virtual host

Lists a series of strings that, if present in the URI, will cause that request to NOT be logged. This directive is useful for cutting down on log clutter when you are certain that you want to ignore requests for certain objects. See section Instructing the module what NOT to log using filtering directives for some tips for using this directive.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

Each string is separated by a space, and no regular expressions or globbing are allowed. Each string is evaluated as a substring of the URI using strstr(). The comparison is case sensitive.

LogSQLWhichCookie
LogSQLWhichCookie cookiename

Example; LogSQLWhichCookie Clicks

Context: virtual host

In HTTP, cookies have names to distinguish them from each other. Using mod_usertrack, for example, you can give your user-tracking cookies a name with the CookieName directive.

mod_log_sql allows you to log cookie information. LogSQL_WhichCookie tells mod_log_sql which cookie to log. This is necessary because you will usually be setting and receiving more than one cookie from a client.

[Note]

You must include a 'c' character in LogSQLTransferLogFormat for this directive to take effect.

although this was origintally intended for people using mod_usertrack to create user-tracking cookies, you are not restricted in any way. You can choose which cookie you wish to log to the database - any cookie at all - and it does not necessarily have to have anything to do with mod_usertrack.

LogSQLWhichCookies
LogSQLWhichCookies cookie-name ...

Example: logSQLWhichCookies userlogin cookie1 cookie2

Context: virtual host

Defines the list of cookies you would like logged. This works in conjunction with LogSQLCookieLogTable. This directive does not require any additional characters to be added to the LogSQLTransferLogFormat string. The feature is activated simply by including this directive, upon which you will begin populating the separate cookie table with data.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

[Note]

The table must be created (see create-tables.sql, included in the package), or LogSQLCreateTables must be set to 'On'.

LogSQLWhichHeadersIn
LogSQLWhichHeadersIn header-name ...

Example: LogSQLWhichHeadersIn User-Agent Accept-Encoding Host

Context: virtual host

Defines the list of inbound headers you would like logged. This works in conjunction with LogSQLHeadersInLogTable. This directive does not require any additional characters to be added to the LogSQLTransferLogFormat string. The feature is activated simply by including this directive, upon which you will begin populating the separate inbound-headers table with data.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

[Note]

The table must be created (see create-tables.sql, included in the package), or LogSQLCreateTables must be set to 'On'.

LogSQLWhichHeadersOut
LogSQLWhichHeadersOut header-name ...

Example: LogSQLWhichHeadersOut Expires Content-Type Cache-Control

Context: virtual host

Defines the list of outbound headers you would like logged. This works in conjunction with LogSQLHeadersOutLogTable. This directive does not require any additional characters to be added to the LogSQLTransferLogFormat string. The feature is activated simply by including this directive, upon which you will begin populating the separate outbound-headers table with data.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

[Note]

The table must be created (see create-tables.sql, included in the package), or LogSQLCreateTables must be set to 'On'.

LogSQLWhichNotes
LogSQLWhichNotes note-name ...

Example: LogSQLWhichNotes mod_gzip_result mod_gzip_ompression_ratio

Context: virtual host

Defines the list of notes you would like logged. This works in conjunction with LogSQLNotesLogTable. This directive does not require any additional characters to be added to the LogSQLTransferLogFormat string. The feature is activated simply by including this directive, upon which you will begin populating the separate notes table with data.

Each string may contain a + or - prefix in a <VirtualHost> context and will cause those strings to be added (+) or removed (-) from the global configuration. Otherwise the global is completely ignored and overridden if defined in a <VirtualHost>

[Note]

The table must be created (see create-tables.sql, included in the package), or LogSQLCreateTables must be set to 'On'.