Administrator's Guide > Administration > Logging

Logging

Logging Configuration

The PTV xServer use the log4j2-Framework for logging purposes. There are two separate logging configuration files to control the logging behaviour:

server-logging.properties
This file contains the logging parameters for the server. Typically you will want to use a rolling file appender that stores logs to a specified filename. The file name can be specified using the system properties xserver.logdirectory as placeholder for the default logging directory and xserver as placeholder for the actual service name (xmap, xroute, ...). Both system properties are set in the wrapper.conf.
module-logging.properties
This file contains the logging parameters for each PTV xServer module. The default configuration is for the module to do the logging using a console appender in order to send them to the server. The server process will then interpret and log the events.
However, you might want to add different appenders to these log settings. In that case, you can use the system properties xserver.logdirectory and xserver (see above) and xserver.moduleid in your configuration. The latter variable contains the instance id of the module.

Logging Interval: The logging configuration can be changed at runtime. These changes are checked and applied every 60 seconds. To change this interval adjust the value of the property monitorInterval.

Log File Format

By default, PTV xServer module log billing summaries into files located in the logs folder using the module name with prefix -server.log. Per request one row is written with semicolon-separated values (CSV).

Header name	Content
timestamp	The arrival time of a request. Example: `2012-08-06 17:58:44,073`
loglevel	The log level (degree of severity), ranging from `DEBUG` to `FATAL`.
RequestTimes	The string `RequestTimes` will appear for every successful request and can be used to filter log entries. In case of failures, this column contains the exception emitting class and the following column the error message, replacing all other regular columns.
id	A server-provided ID for this request. Example: `88e3d304-669b-4bde-964d-9bd75ee240a8`
client host	The IP of the client of this request. Example: `127.0.0.1`
user	The username when using http authentication. Default: `unknown-http`
port	The port of the service used. Example: `50030`
clusterId	An id for the server that can be assigned in `xserver.properties`. Default: `unknown-cluster`
service	The classname and operation used in this request. Example: `XRoute.calculateRoute`
success	Boolean value indication the successfulness of this request. Example: `true`
log1	User logging slot, configurable with the caller context object. Useful to distinguish tenants or offices, test requests and so on.
log2	User logging slot.
log3	User logging slot.
profile	Profile name from the caller context.
pool instance	An id for the concrete instance in the process pool. Example: `m001`
deserialisation	Time for the parsing of the request, in ms.
input trafo	Time for the transformation of input coordinates, in ms.
module queueing	Time that the request had to wait for a free backend module, in ms.
module time	Time spent in the backend module, the net computation time, in ms.
output trafo	Time for the transformation of output coordinates, in ms.
serialisation	Time for the assembling of the response, in ms.
total inner	Total time without parsing/assembling, in ms.
total outer	Total time for the request handling, in ms.
transaction	User-defined transactionId from the caller context. Can be used to associate responses to requests.
use-cases	Special use information, depending on service. Example: `batch locating, roadeditor:` Layer
ref-coord 1	First address of the response, or first station of a route, or center of a rendered map. Intended for country-specific billing.
ref-coord 2	Second address of the response, or last station of a route, or center of a rendered map. Intended for country-specific billing.
dynamic provider	Content from `RoutingParameter.DYNAMIC_PROFILE`.
dimensions	Number of addresses, number of waypoints, for bulk routing also the number of routes (comma-separated), width,height of the image.
additionalInfo	Intended for future use. Currently not used.
errorType	Engine error type, if applicable and available.
errorCode	Engine error type, if applicable and available.
errorMsg	Engine error type, if applicable and available.

Log Analysis

Performance Analysis

There are two ways of analysing performance. The first one is to have a look at the module specific access statistics. The statistics can be reset online to monitor a certain period of time.

The second way is to monitor the request time stamps in the log files. The management console comes with a function for exporting request time stamps into CSV format. That function requires adequate log settings:

file logging must be used
the log level for the RequestTimes category must be set to INFO

Analysing Module Restarts

There are different types of restarts. The log file contains information on each type which is necessary to see which was the reason of the restart.