## [90m[1mTRACE[22m[39m [90m[3m[11/09/2024 03:37:54 +0000][23m[39m [90mdyn.log loaded 'default' configuration successfully.[39m
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:
levels:
- name: DEBUG
description: This level designates fine-grained informational events that are most useful to debug an application.
severity: !expr 500L
log_style: !expr crayon::make_style('deepskyblue2')$bold
msg_style: !expr crayon::make_style('gray90')
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:
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:
var1 <- "abc"; var2 <- 123; var3 <- round(runif(1), digits = 6)
Logger$debug("my log message - var1: {var1}, var2: {var2}, var3: {var3}")
DEBUG [11/09/2024 03:37:54 +0000] my log message - var1: abc, var2: 123, var3: 0.377276
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().
trace | debug | info | success | warn | error | critical | fatal |
---|---|---|---|---|---|---|---|
600 | 500 | 400 | 300 | 350 | 200 | 100 | 100 |
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
[1] "DEBUG"
$description
[1] "Designates fine-grained events that are most useful to debug an application."
$severity
[1] 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.
To customize the log levels in your environment, please see the configuration vignette.