Logging

Logging Directory

Related file: conf/wrapper.conf,

All xServer logging configurations use a central logging directory. The default directory setting is defined by an environment variable in the wrapper.conf (cf. Default Environment Settings).

set.default.XSERVER2_LOG_DIRECTORY=./logs

Logging Configuration

Related files: conf/logging.xml, conf/logging-module.xml

The PTV xServer uses the log4j2-Framework for logging purposes. Logging behavior is controlled by the configuration files conf/logging.xml and conf/logging-module.xml. These files contain the logging parameters for the server and the modules.

Predefined Logs

Request statistics log

Related file: ${sys:xserver.logdirectory}/request.statistics.log

By default PTV xServer logs statistic information on each request to the file ${sys:xserver.logdirectory}/request.statistics.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

id

A server-provided ID for this request. Example: 88e3d304-669b-4bde-964d-9bd75ee240a8

client host

The IP of the client for this request. Example: 127.0.0.1

user

The user name 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 service name and operation used in this request. Example: XRoute.calculateRoute

success

Boolean value indication of 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.

profileClosed A profile is a collection of parameters used to configure the request. Full profiles consist of a number of specialized sub-profiles like the VehicleProfile which describes the properties of a vehicle.

Profile name from the RequestBase.

pool instance

An ID for the concrete instance in the process pool. Example: m001

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.

total outer

Total time for the request handling, in ms.

use-cases

Special use information, depending on service. Example: featureLayer:PTV_TruckAttributes, zoom:13, countryCodes:LU

errorType

Exception type, if applicable and available.

errorMsg

Exception message, if applicable and available.

Server and module logs

The server process logs to the file ${sys:xserver.logdirectory}/xserver.log. Each backend process logs to its own file named ${sys:xserver.logdirectory}/m0001.log, ${sys:xserver.logdirectory}/m0002.log and so on.

Request and response logging

To configure which requests and responses are to be logged, set core.logging.logRequests or core.logging.logResponses in conf/xserver.conf to one of the following values:

  • true All requests / responses are logged.
  • exceptional Only requests / responses which caused an exception are logged. Requests which are rejected or could not be validated against the WSDL / WADL are never logged.
  • fatal Only request which caused a fatal exception such as an internal error or a module restart are logged. This value is not a valid option for core.logging.logResponses.
  • false Requests / responses are not logged at all.

To log requests and responses to a different log file uncomment the RollingFile appender named RequestLog and the Logger RequestLogging in the configuration conf/logging.xml. The requests and responses will then be written to the file ${sys:xserver.logdirectory}/requests.log.

By default only exceptional requests and no responses are logged.

How to extend logging for HTTP request headers

Synopsis: Configuration steps to have HTTP request headers logged to a certain logfile :

  1. Add all HTTP request header names as comma-separated list to core.logging.selectedRequestHeaders in conf/xserver.conf to make them available for logging.
  2. Add the conversion specifier %X for the context map to the conversion pattern of the logfile appender in conf/logging.xml

Example: Log HTTP headers Accept and traceparent to ${sys:xserver.logdirectory}/request.statistics.log:

  1. conf/xserver.conf:
        "core.logging.selectedRequestHeaders" : [ "accept", "traceparent" ]
  2. conf/logging.xml:
        <RollingFile fileName="${sys:xserver.logdirectory}/request-statistics.log"
                     filePattern="${sys:xserver.logdirectory}/archive/request-statistics-%d{MM-dd-yyyy}.log.gz"
                     name="RequestStatisticsLog">
           <Policies>
            <TimeBasedTriggeringPolicy/>
          </Policies>
          <!-- Notice: Additional pattern provided here to assure that the column names are logged in an appropriate way.
               This works as the line with the column headers is logged with the marker 'LOG_HEADERS'. -->
          <PatternLayout>
            <MarkerPatternSelector defaultPattern="%d;%m;%X%n">
              <PatternMatch key="LOG_HEADERS" pattern="%d;%m;http-headers%n"/>
            </MarkerPatternSelector>
          </PatternLayout>
        </RollingFile>

Additional information:

  • HTTP header names can be used as keys for the context map to filter the output with the conversion specifier %X (cf. Log4j documentation).
  • HTTP header names are by specification case-insensitive, thus accept is equal to Accept.
  • The notation of an HTTP header name should not differ between conf/xserver.conf and conf/logging.xml.
  • The logging of HTTP headers can be applied to any logfile appender that is defined in conf/logging.xml.
  • To preserve the structure of the logfiles some characters like ';' etc. are by default converted to a replacement before they are logged.

Scripting logs

For scripting there's also a separate log file called ${sys:xserver.logdirectory}/scripting.log. To enable scripting logs uncomment the RollingFile appender named ScriptingLog and the Logger ScriptingLogger in the configuration conf/logging.xml.

Log Analysis

Performance Analysis

There are two ways of analyzing performance. The first one is to take 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 dashboard comes with a function for exporting request time stamps into CSV format. This function requires adequate log settings:

Analyzing Module Restarts

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