Here we will look at various ways to control log output generated by the node
using the yaml-configuration file of the node.
We assume that you have built a node and are able to run it with our own custom configuration, which is described in this tutorial
and in this tutorial.
When you start the node using the default configuration,
logging is switched on, log output is directed to the console and to a (rolling) file in folder logs/,
minimal severity is Notice,
and verbosity is normal.
We will see how to change all of these and more in this tutorial using various options in the configuration file.
-
We can disable logging completely by setting
TurnOnLoggintoFalse:TurnOnLogging: False -
Log messages come with different severities (
Debug,Info,NoticeandWarningandError), 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 toDebug, we will therefore see messages of all severities; by changing it toError, we will only see the most severe messages:minSeverity: DebugThe severity is displayed in the beginning of each log message (in this example, there is one message with severity
Debug, and there are two with severityNotice):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
MinimalVerbosity,NormalVerbosityorMaximalVerbosity. Changing the verbosity will not change which messages will be displayed, but the amount of information contained in each message.TracingVerbosity: MinimalVerbosity -
As mentioned above, by default log output is directed to the console and to file
logs/mainnet.log. This behavior is handled by so-called "scribes", which we can configure in sectionsdefaultScribesandsetupScribesof the configuration file.Section
defaultScribesmakes types of scribes available. By default these types areFileSKfor writing to a file andStdoutSKfor writing to the console. (There are also the typesJournalSKforsystemd's journal system andDevNullSKfor directing the output to nowhere, but those are not available by default.)Section
setupScribeslists those scribes that are actually used. Their kinds must be configured in thedefaultScribessection before they can be used. For example, if we want logging to go tologs/mylog.login Json-format, we can configure this as follows:setupScribes: - scKind: FileSK scName: "logs/mylog.log" scFormat: ScJsonScribes of type
FileSKuse 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 sectionrotation. -
The configuration options discussed until now were all global, they effected all subsystems simulatneously. It is possible to activate or deactivate logging for specific subsystems by setting the corresponding flags to
TrueorFalseaccordingly. Those flags can be found in the section starting with the comment "##### Coarse grained logging control #####".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 -
It is also possible to exert more fine-grained control on what information to log, but we will not cover this in this tutorial.
