Define logging rules
Logging rules are defined separately for each part of the Alfabet functionality for which logging is provided. You can define different log levels for each functionality and different log targets. For each logging rule, you can define either one or multiple log targets, depending on your log infrastructure.
Define a default log level.
NLog uses a hierarchy of log levels. The levels are:
| Position | Log level | Description |
|---|---|---|
| 0 | Trace | Most verbose level. Usually only activated for development. |
| 1 | Debug | Debugging level including internal event logging. |
| 2 | Info | Information level logging progress or application lifetime events. |
| 3 | Warn | Warnings about validation issues or temporary failures are logged. |
| 4 | Error | Errors where functionality has failed and exceptions are logged. |
| 5 | Fatal | Most critical level. Log messages are only created when the application is about to abort. |
| 6 | Off | No logging is done. |
You can define which levels of log messages shall be used in the logging rules. NLog provides different methods for definition of log levels. In the Alfabet NLog example configuration files, specification of a minimum log level is used. If you specify, for example, a minimum log level of Error , only log levels with position 4 and higher in the hierarchy are written to the log file. You will see only Error and Fatal log messages. To ease change of the general log level, the Alfabet NLog example configuration files use a variable for the definition of the minimum log level:
- <variable name="log-level" value="Warn" />
In the rules, the minimum log level specification is specified via the variable:
- <logger name="alfabetlogger.UserLogon" minlevel="${var:log-level}" writeTo="file-all" final="true" />
To change the log level for all rules, you can change the value of the variable to the new log level and it will be automatically applied to all rules. If you want to change the log level for a single rule, you can delete the variable definition from the rule and overwrite it with the text specification of the log level.
Define logging rules.
Specify log details in the <rules> section of the NLog configuration file. Each functionality has a separate XML element <logger> with the following XML attributes:
The following information is limited to a description of the pre-configured example file. To see all options for configuring rules, consult the NLog documentation about rules definition.
- name: The functionality to be logged. A list of functionalities is given below.
-
minlevel: The minimum position in the hierarchy of log levels considered in the log file. Log messages from lower positions are not creating any entry in the log. You can define the minlevel using the standard log level variables defined in the variable in the format minlevel="${var:log-level}"
The levels are:
Position Log level Description 0 Trace Most verbose level. Usually only activated for development. 1 Debug Debugging level including internal event logging. 2 Info Information level logging progress or application lifetime events. 3 Warn Warnings about validation issues or temporary failures are logged. 4 Error Erros where functionality has failed and exceptions are logged. 5 Fatal Most critical level. Log messages are only created when the application is about to abort. 6 Off No logging is done. - writeTo: The name of the target of the log messages. You can define one target or multiple targets comma separated.
- final: If set to true , no other rules are executed after execution of this rule. As for most of the functionalities only one XML element <logger> is specified, this setting is used for all of them to end scanning for next rules.
For some of the loggers, filters are defined:
- For the alfabetlogger.System logger, two rules are defined, each having a filter. One rule implements logging to console during execution. The next rule blocks logging of .NET generated information to file.
- For the * logger, the re-execution of messages already covered by other loggers is suppressed.
If you want to change the filters or create own filters, consult the NLog documentation for details about filter syntax.
The following loggers are available for Alfabet functionality.
| name attribute value of the XML element logger | logged functionality |
|---|---|
| alfabetlogger.System |
|
| alfabetlogger.UserLogon |
|
| alfabetlogger.Workflow | Activity of the Alfabet workflow functionality. |
| alfabetlogger.ADIF | ADIF execution. Commit actions are logged with the Info log level and rollback actions are logged with the Warn log level. Execution via the Job schedule functionality is logged with the Debug log level. |
| alfabetlogger.Report | Execution of configured reports. |
| alfabetlogger.Publication | Execution of publications. |
| alfabetlogger.Database | Requests to the Alfabet database. |
| alfabetlogger.REST | Execution of the Alfabet RESTful services.
It is recommended to activate central logging of REST functionalities because the return values for the RESTful services do not cover all error details for security reasons. For example if the Alfabet Server is required to execute an ADIF job that shall be executed via a RESTful service call, the RESTful services will inform about forbidden access only and the information about the component that could not be accessed is only provided via central logging. |
| alfabetlogger.SSO | Activity related to a configured SAML authentication. This setting is only relevant if the Alfabet Web Application is configured to use SAML for user authentication. |
| alfabetlogger.Event | Execution of events configured via the Event Management functionality.
Log messages for event execution are also written to the ALFA_EVENT_BUS table in the Alfabet database. |
| alfabetlogger.Conditions | Execution of conditions. Conditions are defined in Alfabet Expand to hinge visibility of elements of the Alfabet user interface on the availability of defined preconditions. |
| alfabetlogger.License | The Alfabet license manager functionality. |
| alfabetlogger.MonitoringEvents | Monitoring of database availability. This option must be activated to test the database availability via the mechanism described in the section ATO: Checking the Accessibility of the Database below. |
| alfabetlogger.WebApplication | Web based functions of the Alfabet Web Application.
Activation of this logger considerably increases the amount of log messages. This logger should only be activated if the cause of issues cannot be detected via the logging provided by the other log options. |
| alfabetlogger.ResetPassword | Reset of user passwords for Alfabet managed users. |
| alfabetlogger.Email | Sending of emails by the Alfabet server. |
| alfabetlogger.Performance | Performance related parameter logging. This logger shall be active if performance issues occur to send the resulting log to Alfabet Support. |
| * | Startup processes. |