Logging adds detail and allows the node operator to better identify what they are looking for. Tendermint supports log levels on a global and per-module basis. This allows the node operator to see only the information they need and the developer to hone in on specific changes they are working on.
There are three log levels, info, debug and error. These can be configured either through the command line via tendermint start --log-level "" or within the config.toml file.
info Info represents an informational message. It is used to show that modules have started, stopped and how they are functioning.
debug Debug is used to trace various calls or problems. Debug is used widely throughout a codebase and can lead to overly verbose logging.
error Error represents something that has gone wrong. An error log can represent a potential problem that can lead to a node halt.
Within the config.toml:
Copy
# Output level for logging, including package level options
log-level = "info"
Here is the list of modules you may encounter in Tendermint's log and a
little overview what they do.
abci-client As mentioned in Application Architecture Guide, Tendermint acts as an ABCI
client with respect to the application and maintains 3 connections:
mempool, consensus and query. The code used by Tendermint Core can
be found here(opens new window).
blockchain Provides storage, pool (a group of peers), and reactor
for both storing and exchanging blocks between peers.
consensus The heart of Tendermint core, which is the
implementation of the consensus algorithm. Includes two
"submodules": wal (write-ahead logging) for ensuring data
integrity and replay to replay blocks and messages on recovery
from a crash.
here(opens new window).
You can subscribe to them by calling subscribe RPC method. Refer
to RPC docs for additional information.
mempool Mempool module handles all incoming transactions, whenever
they are coming from peers or the application.
p2p Provides an abstraction around peer-to-peer communication. For
more details, please check out the
README(opens new window).
Next follows a standard block creation cycle, where we enter a new
round, propose a block, receive more than 2/3 of prevotes, then
precommits and finally have a chance to commit a block. For details,
please refer to Byzantine Consensus
Algorithm(opens new window).