Replace `RUST_LOG` with a near-specific environment variable

[nagisa]

Today if you want to adjust the logging levels in nearcore, you will usually set the RUST_LOG variable, using the EnvFilter syntax. However, there is no obvious correlation to the end user between “RUST” and “neard” that they are running, nor do they need to know the relationship, either. Another problem is that, by the virtue of being the default, RUST_LOG will also affect most other programs and wrappers implemented in Rust, as they tend to not make an effort to specify their own environment variable either, possibly leading to undesirable filtering and/or log messages.

We should be reading the filters from NEARD_LOG or a similar environment variable instead.

[mina86]

Alternatively get rid of the environment variable all together and have --log-level command-line option.

[abhijeetbhagat]

@mina86 hey! can i work on this?

[mina86]

@abhijeetbhagat, sure, though this might need some more discussion of what we want the end state to be. Just when it comes to specifying the level:

1. Do we want NEARD_LOG or move away from reading environment variables. I’m in favour of not reading env.
2. Do we want --log-level switch.
3. Do we want log_config.json to be sole place where logging is configured.

https://github.com/near/nearcore/issues/6839 is also related to this. If we manage to change the default log level to info (rather than whatever current monstrosity we’re using), we could consider further changes such as:

1. Should we kill --verbose=<module> in favour of users setting level as info,<module>=debug? (I’ve never hidden that I don’t like that --verbose can take an argument).
2. And if yes, should we also get rid of LogConfig.verbose_module in favour of verbose: bool.

@nagisa, thoughts?

[nagisa]

I'm personally partial to only having an option to set a level on the CLI, especially since we already are outgrowing the concept of “just” logging. See also https://github.com/near/nearcore/pull/6874

It isn't inconceivable that we will grow a few more options in the future for related functionality, and environment variables don't scale in that respect. As far as files are concerned, I’m personally partial to the @file mechanism which reads and applies the CLI options from a file, as opposed to adding more distinct json files.

---

I'm not sure how conceivable it is that a blanket info will work out of the box easily – it is quite plausible that some of the libraries could unilaterally introduce some undesirable output at that level. But I definitely believe that the CLI should be easy to use out of the box and users shouldn't be on the hook for specifying various exceptions for all sorts of internal libraries if they want to just get useful behaviour out of specifying just a debug...

[mina86]

@abhijeetbhagat, I think at this point this isn’t the best Issue to pick up since I don’t think we have consensus on how we want logging to be configured in the end.

If you want some other Issues related to logging there’s https://github.com/near/nearcore/issues/6009 and https://github.com/near/nearcore/issues/6904.