One of the main objectives of dyn.log is to be as configuration driven as possible, which allows the logger to conform to the problem - not the other way around. Log levels are fully configuration driven, and they are specified in the logger configuration with the following schema:
The levels node contains the log levels you want available in your environment. When a log level is defined in the configuration, it automatically becomes accessible via a first-class function on the dispatcher, e.g.:
The attributes that define a log level are:
- name: what gets displayed as the level when a log message is rendered.
- description: a brief description of the log level & limited info on appropriate usage.
- severity: log severity is used in determining if a message should get displayed according to the currently set evaluation threshold.
- log_style: a crayon that will colorize the log level.
- msg_style: a crayon style that will gray scale the log message, with typically inverted strength, according to the severity.
Once you have defined a log level in the logger configuration, the dispatcher will automatically have a method corresponding to that level. This enables a fairly intuitive approach to invoking the log dispatcher, e.g., if you have the previous debug level defined in your configuration this is how you would log a message with that level:
DEBUG [03/26/22 18:17:52 +0000] my log message - var1: abc, var2: 123, var3: 0.613596
You’ll notice that all log messages by default use the standardize glue format so local variables are capturable in the log output.
You can see what log levels have been specified in your logging configuration by calling log_levels().
Which will output only the names of the defined levels, not all of the detail that defines them.
To get the details about a defined level you can call level_info():
$name  "DEBUG" $description  "Designates fine-grained events that are most useful to debug an application." $severity  500 $style $style$level Crayon style function, deepskyblue2, bold: example output. $style$message Crayon style function, gray75: example output. $style$example DEBUG - Designates fine-grained events that are most useful to debug an application.
The detailed information about a log level shows every configurable attribute about the level, and an example of how the level renders with its associated crayon styles for the level and message. A vanilla log layout consisting of only the level and msg would get rendered with the look of the example attribute.
The default (OTB) logging configuration closely resembles the fairly ubiquitous log4j level scheme.
There is a utility method called display_log_levels() that will output all loaded log levels from the configuration rendered with their defined styles & definitions:
TRACE Designates finer-grained informational events than the DEBUG. DEBUG Designates fine-grained events that are most useful to debug an application. INFO Designates messages that highlight progress at a coarse-grained level. SUCCESS Designates that the operation was unencumbered and completed successfully. WARN Designates potentially harmful situations that should be investigated. ERROR Designates error events that might still allow the application to continue running. CRITICAL Designates severe error events that could lead the application to abort. FATAL Designates very severe error events that will presumably lead the application to abort.
Note: even through fansi is amazing at rendering these in html format, your terminal may look slightly different; expecialy the grayscale colors on log messages.