search

Cardinal-Cryptography / AlephBFT

Rust implementation of Aleph consensus protocol
https://cardinal-cryptography.github.io/AlephBFT/index.html
Apache License 2.0
56 stars 28 forks source link

Inconvenient logging levels and logging target formats #373

Open dpc opened 11 months ago

dpc commented 11 months ago

In a context of a larger application AlephBFT crate logs a lot of errors on high levels for things that are normal and expected during typical use, even if "an error", or "warning" in the context of AlephBFT's internals. Please note that rust logging levels are global and shared for all the crates of the application, so the deeper "in the stack" given library is, the less the chance that certain logging statement is really relevant to the end user.

These logging messages are also cryptic and not useful for anyone that is not intimately familiar with its internals.

On top of it, AlephBFT currently makes it really inconvenient to disable or silence its log messages. The target: in logging statements is meant to be (and defaults to) a Rust module path. So the separator use for the hierarchical structure is ::, like Rust modules. Had it been:

info!(target: "alephbft::extender", ...);

etc. it would be natural to disable all alephbft logging with:

env RUST_LOG=info,alephbft=off

but since AlephBFT-xyz is used, this is not the case.

dpc commented 11 months ago

Correction: It seems that tracing_subscriber does use string prefix based matching so RUST_LOG=AlephBFT-=off might actually work. But it still seems to me that keeping it module-like is ideal.