Difference between revisions of "Logging"
Line 32: | Line 32: | ||
; Example 1: | ; Example 1: | ||
− | < | + | <syntaxhighlight> |
01:18:12.892 SERVER admin OK Server was started (port: 1984) | 01:18:12.892 SERVER admin OK Server was started (port: 1984) | ||
01:18:15.436 127.0.0.1:4722 jack REQUEST XQUERY for $i in 1 to 5 return random:double() | 01:18:15.436 127.0.0.1:4722 jack REQUEST XQUERY for $i in 1 to 5 return random:double() | ||
Line 38: | Line 38: | ||
01:18:15.447 127.0.0.1:4722 jack REQUEST EXIT | 01:18:15.447 127.0.0.1:4722 jack REQUEST EXIT | ||
01:18:15.447 127.0.0.1:4722 jack OK 0.39 ms | 01:18:15.447 127.0.0.1:4722 jack OK 0.39 ms | ||
− | </ | + | </syntaxhighlight> |
A server has been started and a user <code>jack</code> has connected to the server to perform a query and exit properly. | A server has been started and a user <code>jack</code> has connected to the server to perform a query and exit properly. | ||
Line 44: | Line 44: | ||
; Example 2: | ; Example 2: | ||
− | < | + | <syntaxhighlight> |
01:23:33.251 127.0.0.1:4736 john OK QUERY[0] 'hi' 0.44 ms | 01:23:33.251 127.0.0.1:4736 john OK QUERY[0] 'hi' 0.44 ms | ||
01:23:33.337 127.0.0.1:4736 john OK ITER[0] 1.14 ms | 01:23:33.337 127.0.0.1:4736 john OK ITER[0] 1.14 ms | ||
Line 51: | Line 51: | ||
01:23:33.359 127.0.0.1:4736 john REQUEST EXIT | 01:23:33.359 127.0.0.1:4736 john REQUEST EXIT | ||
01:23:33.359 127.0.0.1:4736 john OK 0.14 ms | 01:23:33.359 127.0.0.1:4736 john OK 0.14 ms | ||
− | </ | + | </syntaxhighlight> |
A user <code>john</code> has performed an iterative query, using one of the client APIs. | A user <code>john</code> has performed an iterative query, using one of the client APIs. | ||
Line 57: | Line 57: | ||
; Example 3: | ; Example 3: | ||
− | < | + | <syntaxhighlight> |
01:31:51.888 127.0.0.1:4803 admin REQUEST [GET] http://localhost:8984/rest/factbook | 01:31:51.888 127.0.0.1:4803 admin REQUEST [GET] http://localhost:8984/rest/factbook | ||
01:31:51.892 127.0.0.1:4803 admin 200 4.43 ms | 01:31:51.892 127.0.0.1:4803 admin 200 4.43 ms | ||
− | </ | + | </syntaxhighlight> |
An admin user has accessed the <code>factbook</code> database via REST. | An admin user has accessed the <code>factbook</code> database via REST. |
Revision as of 15:00, 27 February 2020
This article is part of the Advanced User's Guide. It describes how client operations are logged by the server. The server logs can e.g. be used to get an overview of all processes executed on your server, trace any errors or compile performance statistics.
Contents
Introduction
The server logs are written in plain text. In your Database Directory, you can find a folder named .logs
in which all log files are stored with the according date. Note that, depending on your OS and configuration, files and folders beinning with a .
may be hidden. The log directory can be changed via the LOGPATH
option.
Template:Mark If BaseX is running as Web Application, all trace output (generated via fn:trace
, prof:dump
and similar functions) will be stored in the logs as well.
Some more notes on the logging facility:
- HTTP requests are included in the log files.
- Logging can be turned on/off via the
LOG
option. - The maximum length of logging messages can be changed via
LOGMSGMAXLEN
. - The Admin Module provides access to the log files from XQuery.
RESTXQ
Template:Mark The request attributes will be checked for a user id.
By default, RESTXQ code is executed with the admin
user. As a result, this user will be displayed in the logs for all RESTXQ requests. In a web application with a custom user management, however, the name of the actual user who has sent a request is often more relevant.
When log data is written during the processing of a RESTXQ function, the following is looked up as follows:
- The current request is checked for an
id
attribute. The attribute can be assigned via RESTXQ and therequest:set-attribute
function, and it is the recommended approach for stateless requests as all request attributes will be dropped after the finalization of a request. - If none is found, the
id
attribute is looked up in the current user session. The attribute can be assigned viasession:set
(see e. g. the DBA code for sessions and user handling). If the request path contains adba
segment, adba
session attribute will be looked up instead. - If none is found, the default path will be taken, and the user of the current database context will be included in the logs.
Format
- Example 1
<syntaxhighlight> 01:18:12.892 SERVER admin OK Server was started (port: 1984) 01:18:15.436 127.0.0.1:4722 jack REQUEST XQUERY for $i in 1 to 5 return random:double() 01:18:15.446 127.0.0.1:4722 jack OK Query executed in 2.38 ms. 2.72 ms 01:18:15.447 127.0.0.1:4722 jack REQUEST EXIT 01:18:15.447 127.0.0.1:4722 jack OK 0.39 ms </syntaxhighlight>
A server has been started and a user jack
has connected to the server to perform a query and exit properly.
- Example 2
<syntaxhighlight> 01:23:33.251 127.0.0.1:4736 john OK QUERY[0] 'hi' 0.44 ms 01:23:33.337 127.0.0.1:4736 john OK ITER[0] 1.14 ms 01:23:33.338 127.0.0.1:4736 john OK INFO[0] 0.36 ms 01:23:33.339 127.0.0.1:4736 john OK CLOSE[0] 0.21 ms 01:23:33.359 127.0.0.1:4736 john REQUEST EXIT 01:23:33.359 127.0.0.1:4736 john OK 0.14 ms </syntaxhighlight>
A user john
has performed an iterative query, using one of the client APIs.
- Example 3
<syntaxhighlight> 01:31:51.888 127.0.0.1:4803 admin REQUEST [GET] http://localhost:8984/rest/factbook 01:31:51.892 127.0.0.1:4803 admin 200 4.43 ms </syntaxhighlight>
An admin user has accessed the factbook
database via REST.
Changelog
- Version 9.3
- Updated: Store trace output in database logs
- Updated: RESTXQ: The request attributes will be checked for a user id.
- Version 8.6
- Added: The log directory can be changed with the
LOGPATH
option. - Updated: Include session attributes in log data.