主内
ー。。ー。

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.