.. _monitor_audit:
Audit Logging
=============
The history mode logs all requests into a database. This can put a very significant strain
on the database and can lead to insertion issues as the request table begins to host
millions of records.
As an alternative to the history mode it's possible to enable the auditing logger, which will log
the details of each request in a file, which is periodically rolled. Secondary applications can
then process these log files and built ad-hoc summaries off line.
Configuration
-------------
The ``monitor.properties`` file can contain the following items to enable and configure file auditing::
audit.enabled=true
audit.path=/path/to/the/logs/directory
audit.roll_limit=20
The ``audit.enable`` is used to turn on the logger (it is off by default).
The ``audit.path`` is the directory where the log files will be created.
The ``audit.roll_limit`` is the number of requests logged into a file before rolling happens.
The files are also automatically rolled at the beginning of each day.
In clustered installations with a shared data directory the audit path will need to be different
for each node. In this case it's possible to specify the audit path by using a JVM system variable,
add the following to the JVM startup options and it will override whatever is specified in
``monitor.properties``:
-DGEOSERVER_AUDIT_PATH=/path/to/the/logs/directory
Log Files
---------
The log directory will contain a number of log files following the ``geoserver_audit_yyyymmdd_nn.log``
pattern. The ``nn`` is increased at each roll of the file. The contents of the log directory will look like::
geoserver_audit_20110811_2.log
geoserver_audit_20110811_3.log
geoserver_audit_20110811_4.log
geoserver_audit_20110811_5.log
geoserver_audit_20110811_6.log
geoserver_audit_20110811_7.log
geoserver_audit_20110811_8.log
By default each log file contents will be a xml document looking like the following::
WMS
1.1.1
GetMap
GeoSolutions:elba-deparea
/GeoSolutions/wms
LAYERS=GeoSolutions:elba-deparea&STYLES=&FORMAT=image/png&TILED=true&TILESORIGIN=9.916,42.312&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application/vnd.ogc.se_inimage&SRS=EPSG:4326&BBOX=9.58375,42.64425,9.916,42.9765&WIDTH=256&HEIGHT=256
GET
2011-08-11T20:19:28.277Z
2011-08-11T20:19:28.29Z
13
192.168.1.5
192.168.1.5
demo1.geo-solutions.it
admin
200
1670
image/png
false
...
Customizing Log Contents
------------------------
The log contents are driven by three FreeMarker templates.
``header.ftl`` is used once when a new log file is created to form the first few lines of the file.
The default header template is::
``content.ftl`` is used to write out the request details. The default template dumps all the known fields about the request::
<#escape x as x?xml>
${service!""}
${owsVersion!""}
${operation!""}
${subOperation!""}
${resourcesList!""}
${path!""}
${queryString!""}
<#if bodyAsString??>
${bodyAsString}
${httpMethod!""}
${startTime?datetime?iso_utc_ms}
${endTime?datetime?iso_utc_ms}
${totalTime}
${remoteAddr!""}
${remoteHost!""}
${host}
${remoteUser!""}
${responseStatus!""}
${responseLength?c}
${responseContentType!""}
${cacheResult!""}
${missReason!""}
<#if error??>
true
${errorMessage!""}
<#else>
false
``footer.ftl`` is executed just once when the log file is closed to build the last few lines of the file.
The default footer template is::
The administrator is free to provide alternate templates, they can be placed in the same directory
as ``monitor.properties``, with the same names as above. GeoServer will pick them up automatically.