Logging
Logging Configuration
A dedicated section in the HAKOM.Config file provides options to configure logging for the HAKOM WebTSM Services. All relevant settings are contained in the section "Logging":
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<!-- Settings -->
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
Available settings are as follows:
| Element | Description | Default value | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Format | Specifies the format of log entries. Currently there are two options available:
| Text | ||||||||||||||
| Level | Specifies what kind of information should be logged. The following values are available: https://github.com/serilog/serilog/wiki/Configuration-Basics#minimum-level or "none". | Information | ||||||||||||||
| DbConnections | Controls whether to include information about opening, closing and managing the database connection in the log entries. | false | ||||||||||||||
| DbCommands | Controls whether to include any database queries or commands that are executed in the scope of a request in the log entries | false | ||||||||||||||
| File | The following settings are contained in the subsection "File":
XML
| |||||||||||||||
| Path | Specifies the file where these logs should be written. | HAKOM.Framework.Services.log | ||||||||||||||
| SizeLimitBytes | The approximate maximum size, in bytes, to which a log file will be allowed to grow. For unrestricted growth, leave the attribute value empty. To avoid writing partial events, the last event within the limit will be written in full even if it exceeds the limit. | 1073741824 (= 1GB) | ||||||||||||||
| RollOnSizeLimit | If true, a new file will be created when the file size limit is reached. Filenames will have a number appended in the format _NNN, with the first filename given no number. | true | ||||||||||||||
| RollingInterval | Possible values:
| Infinite | ||||||||||||||
| RetainedCountLimit | The maximum number of log files that will be retained, including the current log file. For unlimited retention, leave the attribute value empty. | 31 |
Examples
The following causes only errors to be logged (rule of thumb: any HTTP Status code >= 400):
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<Level>Error</Level>
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
The following causes nothing to be logged:
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<Level>none</Level>
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
The following causes even successful requests to be logged as well as any other informative messages, and also writes these logs to a file called "requests.log" (instead of the default file "HAKOM.Framework.Services.log") within the installation directory of the service:
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<Level>Information</Level>
<File>
<Path>requests.log</Path>
</File>
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
The following causes only errors to be logged. The log file will have the default name "HAKOM.Framework.Services.log". It will have a maximum size of 1GB. A new file is generated when the current file has reached its maximum size (1GB in this case) or a new day has started. From the sixth file onwards, each newly created file will overwrite the oldest:
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<Level>Error</Level>
<File>
<SizeLimitBytes>1073741824</SizeLimitBytes>
<RollOnSizeLimit>true</RollOnSizeLimit>
<RollingInterval>Day</RollingInterval>
<RetainedCountLimit>5</RetainedCountLimit>
</File>
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
The following causes errors to be logged as JSON objects inside the log file instead of the default text-format
<HAKOMConfiguration>
<products>
<WebTSMServices>
<Logging>
<Format>JSON</Format>
<Level>Error</Level>
</Logging>
</WebTSMServices>
</products>
</HAKOMConfiguration>
Correlation IDs
In some environments it can be helpful to be able to establish a correlation between individual requests to multiple services for debugging or further event logging. For this purpose, log entries include an ID which is extracted from an optional X-Correlation-ID header in incoming requests.
Requests which do not contain such information will have an ID generated for them which will also be included in the X-Correlation-ID header of the response.