Logging Levels

There are six available logging levels:

all
debug
info
warn
error
off

Sample logging.json:

{
 "includes": [],
 "appenders": [{
     "name": "consoleout", 
     "type": "console",
     "args": {
       "stream": "std_out",
       "level_colors": [{
           "level": "debug",
           "color": "green"
         },{
           "level": "warn",
           "color": "brown"
         },{
           "level": "error",
           "color": "red"
         }
       ]
     },
     "enabled": true
   },{
     "name": "net",
     "type": "gelf",
     "args": {
       "endpoint": "10.10.10.10",
       "host": "test"
     },
     "enabled": true
   }
 ],
 "loggers": [{
     "name": "default",
     "level": "info",
     "enabled": true,
     "additivity": false,
     "appenders": [
       "consoleout",
       "net"
     ]
   },{
     "name": "net_plugin_impl",
     "level": "debug",
     "enabled": true,
     "additivity": false,
     "appenders": [
       "net"
     ]
   }
 ]
}

Expected Output of Log Levels

error - Log output that likely requires operator intervention.
- Error level logging should be reserved for conditions that are completely unexpected or otherwise need human intervention.
- Also used to indicate software errors such as: impossible values for an enum, out of bounds array access, null pointers, or other conditions that likely will throw an exception.
- Note: Currently, there are numerous error level logging that likely should be warn as they do not require human intervention. The net_plugin_impl, for example, has a number of error level logs for bad network connections. This is handled and processed correctly. These should be changed to warn or info.
warn - Log output indicating unexpected but recoverable errors.
- Although, warn level typically does not require human intervention, repeated output of warn level logs might indicate actions needed by an operator.
- warn should not be used simply for conveying information. A warn level log is something to take notice of, but not necessarily be concerned about.
info (default) - Log output that provides useful information to an operator.
- Can be just progress indication or other useful data to a user. Care is taken not to create excessive log output with info level logging. For example, no info level logging should be produced for every transaction.
- For progress indication, some multiple of transactions should be processed between each log output; typically, every 1000 transactions.
debug - Useful log output for when non-default logging is enabled.
- Answers the question: is this useful information for a user that is monitoring the log output. Care should be taken not to create excessive log output; similar to info level logging.
- Enabling debug level logging should provide greater insight into behavior without overwhelming the output with log entries.
- debug level should not be used for trace level logging; to that end, use all (see below).
- Like info, no debug level logging should be produced for every transaction. There are specific transaction level loggers dedicated to transaction level logging: transaction, transaction_trace_failure, transaction_trace_success, transaction_failure_tracing, transaction_success_tracing, transient_trx_success_tracing, transient_trx_failure_tracing.
all (trace) - For logging that would be overwhelming if debug level logging were used.
- Can be used for trace level logging. Only used in a few places and not completely supported.
- Note: In the future a different logging library may provide better trace level logging support. The current logging framework is not performant enough to enable excess trace level output.

Expected Output of Log Levels​

Expected Output of Log Levels