--logging.config.file
on xUML Runtime Command Line Options). The configuration file is a JSON file in which you can specify logging details like which logging data to write where.Concepts
The logging concept of the xUML Runtime is build around the concepts of channels and sinks.
Element | Description | Allowed Values / Examples | |
---|---|---|---|
channel | A channel is an object that describes the data that will be written to a log file. It is identified by a channel name. | error | Write service logging data (bridgeserver log). |
access | Write transaction logging data. | ||
sink | A channel can contain an arbitrary number of sinks. Sinks define the logging output and how it is written:
|
Configuring Sinks
Sinks define the logging output and how it is written. You can define name and path of the log file, the log file format and filter out data to be logged.
Property | Description | Allowed Values | Example | |
---|---|---|---|---|
type | Define whether to write to a file (daily or hourly rotation), or to std_out or std_err. | std_out | Write logs to std_out. | "type": "hourly_rotated_file", |
std_err | Write logs to std_err. | |||
daily_rotated_file | Write to a daily rotated log file. | |||
hourly_rotated_file | Write to an hourly rotated log file. | |||
params | Define parameters of the sink. At the moment, only accepted parameter is name_pattern to define the name of the log file. | name_pattern | Defines the relative path and file name pattern of the log file. See Name Patterns for Log Files for available placeholders. | |
formatter | ||||
type | Define in which format the log data will be logged to the log file. | json | Log the log file data in JSON format. | Example 1: "formatter" : { Example 2: "formatter" : { |
pattern | Log the log file data according to a given pattern. The used pattern is defined in the params attribute via attribute pattern. | |||
params | If format type is pattern , specify the log file pattern. | See Format Variables for Log File Content for more on the available variables. | ||
legacy_utc | Enable UTC timestamp for monitoring logs. | true | Use UTC in timestamp. | |
false | Do not use UTC in timestamp. | |||
filters | ||||
level | Provide an array of service log levels to let pass through the filter. | One of | "filters" : [ | |
trx_level | Provide an array of transaction log levels to let pass through the filter. | One of NONE , CUSTOM , SERVICE , IO_EXTERNAL and IO_INTERNAL (case-sensitive).Refer to Transaction Log Levels of an xUML Service for more information. | ||
domains | Provide an array of error domains let pass through the filter. You can invert the filtering by adding a ! sign in front of a domain name. |
| Nothing is filtered. | |
list of domains | Let logs containing one of the listed domains pass through the filter. |
Name Patterns for Log Files
As a name pattern for log files to use in attribute name_pattern
, you can use all specifiers listed on boost Date Time Format Flags.
We recommend to use the following subset:
Pattern | Description |
---|---|
%Y | year, 4 digits |
%m | month, 2 digits |
%d | day of the month, 2 digits |
%H | hour, 24-hour format, 2 digits |
%M | minute, 2 digits |
%S | second, 2 digits |
Format Variables for Log File Content
Find below all available format variables for xUML service (bridgeserver) logs and transaction logs.
Available Variables for Service Logs
Refer to xUML Service Standard Log for more information on this log.
Field | Type | Description | Example Usage |
---|---|---|---|
code | String | error code | {code} |
domain | String | error domain | {domain} |
level | String | error level | {level} |
message | String | error message details | {message} |
pid | Numeric | process id | {pid} |
session_id | Numeric | session id | {session_id} |
timestamp | DateTime | timestamp when the log occurred | {timestamp} |
Available Variables for Transaction Logs
Refer to Contents of the Transaction Log for more information on the listed variables.
Field | Type | Description | Example Usage |
---|---|---|---|
component | String | name of the component | {component} |
correlation_id | String | correlation ID | {correlation_id} |
domain | String | error domain name | {domain} |
elapsed_ms | Numeric | milliseconds since session start | {elapsed_ms} |
param1 | String | parameter 1 | {param1} |
param2 | String | parameter 2 | {param2} |
session_id | Numeric | session ID | {session_id} |
timestamp | DateTime | timestamp when the log occurred | {timestamp} |
trx_entry_type | String | log type | {trx_entry_type} |
trx_id | String | transaction ID | {trx_id} |
trx_status | String | status | {trx_status} |
Example Patterns for Emulating the Classic Log Format
Log | Example Definition |
---|---|
xUML Service Log (bridgeserver) | {timestamp:%Y-%m-%d\t%T\t%z}\t{trx_id}\t{session_id}\t{component}\t{elapsed_ms}\t{trx_status}\t{domain}\t{trx_entry_type}\t{param1}\t{param2}\t{correlation_id} |
Transaction Log | [{timestamp:%F %T %z}][{session_id:010}][{level}][Internal][{domain}][{code}][{message}] |
Monitoring | e2eruntime[{pid}[{timestamp:%F %T UTC}[{level}[Internal[{domain}[{code}[[{message}]] |