Here we will look at various ways to control log output generated by the node using the
json -configuration file of the node.
When you start the node using the default configuration, logging is switched on, log output is directed to the console, minimal severity is
Info, and verbosity is normal.
You can change these configurations in the node’s config file, for example: mainnet-config.json`
Enable and disable logs¶
We can disable logging completely by setting
Log messages come with different severities (
Error), and we can specify the minimal severity
of messages that will be passed on (the the console, a file or another logging backend). Messages with a lower severity will be suppressed. By changing this minimal severity to
Debug, we will therefore see messages of all severities; by changing it to
Error, we will only see the most severe messages:
The severity is displayed in the beginning of each log message (in this example, there is one message with severity
and there are two with severity
Note: Lowering the minimal severity harms efficiency, so while using a low severity can be very helpful for debugging a problem, it should be used with care during normal operation. The same is true for other options which produce more logging output described below.
In addition to severity, log messages come with verbosity, which can be
MaximalVerbosity. Changing the verbosity will not change which messages will be displayed, but the amount of information contained in each message.
By default, log output is directed to the console. This behavior is handled by so-called “scribes”, which we can configure in sections
setupScribes of the configuration file.
Control log output¶
defaultScribes makes types of scribes available. These types are
FileSK for writing to a file and
StdoutSK for writing to the console. There are also the types
systemd’s journal system and
DevNullSK for directing the output to nowhere.
setupScribes lists those scribes that are actually used. Their kinds must be configured in the
defaultScribes section before they can be used. For example, if we want logging to go to
logs/mylog.log in Json-format, we can configure this as follows:
setupScribes: - scKind: FileSK scName: "logs/mylog.log" scFormat: ScJson
Scribes of type
FileSK use rotating log files (keeping the newest log messages in the configured log file and moving older messages to archive files), and the rotation-behavior can be configured in section
The above configuration options were all global, they effected all subsystems simultaneously. It is possible to activate or deactivate logging for specific subsystems by setting the corresponding flags o
False accordingly. For example, if we want to activate logging for all subsystems related to block fetching, we can achieve this as follows:
# Trace BlockFetch client. TraceBlockFetchClient: True # Trace BlockFetch decisions made by the BlockFetch client. TraceBlockFetchDecisions: True # Trace BlockFetch protocol messages. TraceBlockFetchProtocol: True # Serialised Trace BlockFetch protocol messages. TraceBlockFetchProtocolSerialised: True # Trace BlockFetch server. TraceBlockFetchServer: True