log

log
Prev	Reference	Next

DESCRIPTION

This filter logs packages sent - and received .

Configurable values:

message

Specifies a custom message for the log message.

time-format

Date+time format if log is written to a custom file (see filename configuration, below), using the format of strftime(3).

Use option -m in the invocation of Metaproxy command to set format if yaz_log is used (no filename given).

filename

Specifies a name of log file. If this is omitted, logging is performed using the log system of YAZ (yaz_log).

category

Specifies the category of messages to be logged. The category is an XML attribute and value of attribute is a boolean; true for enabled; false for disabled. The following category attributes are supported:

access: One-line log messages inspired by Apache httpd access log entries. This is a brief message stating the request and response. This is enabled by default. All other categories are disabled by default. See the section ACCESS LOG.
user-access: One-line log messages similar to access but with the authenticated user on each log line.
request-apdu: Z39.50 Request APDU.
response-apdu: Z39.50 Response APDU.
apdu: Z39.50 APDU (request and response)
request-session: Request session.
response-session: Response session.
session: Session (request and response)
init-options: Z39.50 Init Request options
line: Simple one-line log message indicating the most important things from a request and response. Available from version 1.3.38 and later.

The access log

The access is is strictly one line per entry and aims for easy mangling with tools such as awk, grep, perl etc. Many values may be omitted in the packages, in which case a single dash is printed instead. This is to ensure that all values have well-defined position.

The basic format and order is:

time (position 1)

Full time of event

Custom message (position 2)

The string as given in element message.

IP (position 3)

IP address of origin (peer)

If category user-acesss is used, the user is written on position 3 and the IP is written on position 4.

session (position 4)

Session ID. Can be used to identify a particular Z39.50 session. For HTTP this session ID only tracks the HTTP socket (kept alive). NOT to be confused with the HTTP cookie mechanism.

elapsed (position 5)

Elapsed time. The elapsed time is the time between the point in time where a package was received from the client and the point where a response was received from the next filter in the chain (backend eventually).

protocol (position 6)

Protocol type which is one of Z3950 or HTTP_Request or HTTP_Response.

For packages with protocol marker Z3950, the access log line is followed by the APDU type + information depending on the type. The APDU type is on position 7.

initRequest

Z39.50 Initialize Request with the information: username, vhost, implementation ID, implementation name, implementation version.

initResponse

Z39.50 Initialize Response with the information: status (OK or FAIL), implementation ID, implementation name, implementation version.

searchRequest

Z39.50 Search Request with the information: database(s), result set ID, record syntax, query.

Multiple databases are separated by a plus-sign (+). The query itself is multiple tokens. For this reason it is placed as the last information on this log entry.

searchResponse

Z39.50 Search Response with the information: status (OK or FAIL), hit count, number of records returned, next result set position.

presentRequest

Z39.50 Present Request with the information: result Set ID, start position, number of records requested, record syntax, record composition.

presentResponse

Z39.50 Present Response with the information: status (OK, DIAG, ERROR), number of records returned, next result set position.

scanRequest

Z39.50 Scan Request with the information: database(s), number of terms requested, preferred position in response, step size, start point.

The start point is a multi-token value in PQF notation.

scanResponse

Z39.50 Scan Response with the information: status (OK, ERROR), number of entries returned, position of term, step size.

SCHEMA

# Metaproxy XML config file schemas
#
#   Copyright (C) Index Data
#   See the LICENSE file for details.

namespace mp = "http://indexdata.com/metaproxy"

filter_log =
  attribute type { "log" },
  attribute id { xsd:NCName }?,
  attribute name { xsd:NCName }?,
  element mp:message { xsd:string }?,
  element mp:time-format { xsd:string }?,
  element mp:filename { xsd:string }?,
  element mp:category {
    attribute user-access { xsd:boolean }?,
    attribute access { xsd:boolean }?,
    attribute init-options { xsd:boolean }?,
    attribute request-session { xsd:boolean }?,
    attribute response-session { xsd:boolean }?,
    attribute session { xsd:boolean }?,
    attribute apdu { xsd:boolean }?,
    attribute request-apdu { xsd:boolean }?,
    attribute response-apdu { xsd:boolean }?,
    attribute line { xsd:boolean }?
  }?

EXAMPLES

A typical configuration looks like this:

    <filter type="log">
     <message>B</message>
     <filename>logs/metaproxy.log</filename>
     <category access="true"/>
    </filter>

Name

DESCRIPTION

The access log

SCHEMA

EXAMPLES

SEE ALSO

COPYRIGHT

Prev	Up	Next
load_balance	Home	multi