Add log channels to Aleth command-line help output

[halfalicious]

Aleth logs messages to various Boost log channels and has 4 levels of logging which increase in verbosity from level 0 (no logging) to 4 (verbose logging). The log level can be set at runtime (via -v<level>), and similarly log channels can be enabled or disabled via the --log-channels and --log-exclude-channels args. Aleth's command-line help output (aleth -h) lists all of these args, but it doesn't include the list of available channels which can make it difficult for one to determine which channels to enable / disable.

To address this, the command-line help output for Aleth should be updated to include the list of log channels. The logging command line help output is built here:

aleth/libdevcore/LoggingProgramOptions.cpp

Lines 24 to 42 in ad7204c

	po::options_description createLoggingProgramOptions(unsigned _lineLength, LoggingOptions& _options)
	{
	po::options_description optionsDescr("LOGGING OPTIONS", _lineLength);
	auto addLoggingOption = optionsDescr.add_options();
	addLoggingOption("log-verbosity,v", po::value<int>(&_options.verbosity)->value_name("<0 - 4>"),
	"Set the log verbosity from 0 to 4 (default: 2).");
	addLoggingOption("log-channels",
	po::value<std::vector<std::string>>(&_options.includeChannels)
	->value_name("<channel_list>")
	->multitoken(),
	"Space-separated list of the log channels to show (default: show all channels).");
	addLoggingOption("log-exclude-channels",
	po::value<std::vector<std::string>>(&_options.excludeChannels)
	->value_name("<channel_list>")
	->multitoken(),
	"Space-separated list of the log channels to hide.\n");
	return optionsDescr;
	}

Aleth calls the function here:

aleth/aleth/main.cpp

Lines 325 to 326 in ad7204c

	po::options_description loggingProgramOptions(
	createLoggingProgramOptions(c_lineWidth, loggingOptions));

A log channel is defined when a Logger object is created - for example, the following Logger writes messages to the "net" channel:

aleth/libp2p/Host.h

Line 371 in ad7204c

Logger m_logger{createLogger(VerbosityDebug, "net")};

You can build a list of all channels by searching the codebase for instances of Logger m_logger. Don't include loggers defined in test files (i.e. files under aleth\tools)

Also, createLoggingProgramOptions is used by multiple Aleth tools (e.g. aleth-bootnode) and these tools don't use the same set of log channels as Aleth, but we still want createLoggingOptions to be general purpose. To address this, you should build the list of log channels in Aleth's main.cpp and pass it into createLoggingProgramOptions where you include it in the boost::program_options:options_description being built. You can pass in empty strings in the other tools. These tools are:

• aleth-bootnode:

  aleth/aleth-bootnode/main.cpp

  Lines 42 to 43 in ad7204c

  	po::options_description loggingProgramOptions(
  	createLoggingProgramOptions(c_lineWidth, loggingOptions));

• aleth-vm:

  aleth/aleth-vm/main.cpp

  Lines 124 to 125 in ad7204c

  	po::options_description loggingProgramOptions(
  	createLoggingProgramOptions(c_lineWidth, loggingOptions));

• aleth-key:

  aleth/aleth-key/main.cpp

  Lines 41 to 42 in ad7204c

  	po::options_description loggingProgramOptions(createLoggingProgramOptions(
  	po::options_description::m_default_line_length, loggingOptions));

[twinstar26]

Hi,
I am interested in solving this issue.

[halfalicious]

Sounds good, it’s yours @twinstar26 😄

[gumb0]

Note also: not all loggers are member variables defined as Logger m_logger.
There are also global loggers, search for BOOST_LOG_INLINE_GLOBAL_LOGGER_CTOR_ARGS to find them (I think they are only in libdevcore/Log.h and libp2p/Common.h)

[twinstar26]

@halfalicious
Have a doubt regarding the last paragraph,
So when we execute ./aleth -h then and then only we want to display a section which shows list of all channels (irrespective if those channels are applicable for user or not)
and when we execute ./aleth-bootnode -h and other tools then we need not display list of all channels (we can do this by passing empty strings from these tools to aleth/libdevcore/LoggingProgramOptions.cpp)

Have I understood the issue correctly?

[halfalicious]

@halfalicious
Have a doubt regarding the last paragraph,
So when we execute ./aleth -h then and then only we want to display a section which shows list of all channels (irrespective if those channels are applicable for user or not)
and when we execute ./aleth-bootnode -h and other tools then we need not display list of all channels (we can do this by passing empty strings from these tools to aleth/libdevcore/LoggingProgramOptions.cpp)

Have I understood the issue correctly?

@twinstar26 : That's correct. From what I understand, Aleth can log to all channels which is why we want to display the entire list. I'm not sure which channels the other tools log to and will need to do some research, which is why I think we should not log channel lists for them at this point.

[twinstar26]

@halfalicious
So how is this declaration looking??
///List_logging_channels const std::multimap<string,string> list_log_channels = {{"VerbosityError","chain"}, {"VerbosityInfo","sync"}, {"VerbosityInfo","client"}, {"VerbosityInfo","snap"}, {"VerbosityInfo","tq"}, {"VerbosityDebug","blockhdr"}, {"VerbosityDebug","block"}, {"VerbosityDebug","chain"}, {"VerbosityDebug","sync"}, {"VerbosityDebug","bq"}, {"VerbosityDebug","client"}, {"VerbosityDebug","watch"}, {"VerbosityDebug","host"}, {"VerbosityDebug","ethcap"}, {"VerbosityDebug","impolite"}, {"VerbosityDebug","peer"}, {"VerbosityDebug","tq"}, {"VerbosityDebug","net"}, {"VerbosityDebug","discov"}, {"VerbosityTrace","block"}, {"VerbosityTrace","chain"}, {"VerbosityTrace","sync"}, {"VerbosityTrace","bq"}, {"VerbosityTrace","net"}}

Declaration can be found over here

aleth/libdevcore/Log.h

Lines 65 to 73 in dbbfd5b

	enum Verbosity
	{
	VerbositySilent = -1,
	VerbosityError = 0,
	VerbosityWarning = 1,
	VerbosityInfo = 2,
	VerbosityDebug = 3,
	VerbosityTrace = 4,
	};

So that user will come to know for which verbosity which channels are going to remain active.
Currently multimap has <string,string>, which can be changed to <int,string> so that user can understand it better.

#5549 (comment)
Also I will address this later.

[gumb0]

@twinstar26 How exactly do you intend to make it look in help output?
I suspect it would be too much info, which would make it less readable / too overwhelming for a user.

Also too much maintenance pain to support this kind of list (as verbosities might change more often than the channel list)

So I think the list of strings with channel names should be enough.

[twinstar26]

@gumb0
Actually I was thinking of creating an option for aleth (for eg: ./aleth --list_channels)
But if we are planning to put this in help menu then I agree with you that it will be less readable.
So should we go with option 1 or 2 or both??

[twinstar26]

Also I have made the list of channels hard-coded as this is before runtime (as in this list should be visible to user even before we start execution) which will make it hard to maintain.

Apart from aleth if we are planning the same for other tools then I think creating an option will be wise choice (for eg: ./aleth --list_channels) not for developers and maintainers but for users. 😅 🤣

[halfalicious]

@twinstar26 While I appreciate the effort and enthusiasm, I don't think --list_channels is necessary, I think including the channel list in the --help/-h output is enough. I agree with @gumb0 , I think that we want this information to be lightweight and easy to digest so just including a list of the channel names (e.g. net, discov) is sufficient.

[twinstar26]

Alright. I will start working straight away.