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.
# Configuring Log Levels
There are three log levels,
error. These can be configured either through the command line via
tendermint start --log-level "" or within the
infoInfo represents an informational message. It is used to show that modules have started, stopped and how they are functioning.
debugDebug is used to trace various calls or problems. Debug is used widely throughout a codebase and can lead to overly verbose logging.
errorError represents something that has gone wrong. An error log can represent a potential problem that can lead to a node halt.
Via the command line:
# List of modules
Here is the list of modules you may encounter in Tendermint's log and a little overview what they do.
abci-clientAs 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).
blockchainProvides storage, pool (a group of peers), and reactor for both storing and exchanging blocks between peers.
consensusThe heart of Tendermint core, which is the implementation of the consensus algorithm. Includes two "submodules":
wal(write-ahead logging) for ensuring data integrity and
replayto replay blocks and messages on recovery from a crash. here (opens new window). You can subscribe to them by calling
subscribeRPC method. Refer to RPC docs for additional information.
mempoolMempool module handles all incoming transactions, whenever they are coming from peers or the application.
p2pProvides an abstraction around peer-to-peer communication. For more details, please check out the README (opens new window).
rpc-serverRPC server. For implementation details, please read the doc.go (opens new window).
stateRepresents the latest state and execution submodule, which executes blocks against the application.
statesyncProvides a way to quickly sync a node with pruned history.
# Walkabout example
We first create three connections (mempool, consensus and query) to the
kvstore locally in this case).
Then Tendermint Core and the application perform a handshake.
After that, we start a few more things like the event switch, reactors, and perform UPNP discover in order to detect the IP address.
Notice the second row where Tendermint Core reports that "This node is a validator". It also could be just an observer (regular node).
Next we replay all the messages from the WAL.
"Started node" message signals that everything is ready for work.
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).