Add one more log level (notice/verbose?)

[intgr]

When writing command line programs, I often find myself wanting two distinct "info"-like log levels: one for regular output and one when a --verbose flag is requested by the user. Then implementing --verbose is simply a matter of changing the log level. I think the Debug level is wrong for this purpose because it's oriented towards developers, whereas --verbose is typically intended for troubleshooting by users.

There would be two ways to go about it:

• Warn > Notice > Info > Debug
• Warn > Info > Verbose > Debug

I realize that similar things have been requested before (#240, #229), but I think my use case is actually a quite helpful one.

If your consideration is to keep the number of built-in log levels low, I actually don't find a distinct Trace level to be useful; seems like debug output to me. But perhaps other people do? What was the justification for that in the first place? :)

[KodrAus]

Hi @intgr 👋

This doesn’t sound unreasonable, however I would still argue against another info-like level for this purpose, because the levels are really arbitrary already any changes aren’t necessary going to result in quality filtering from libraries.

If you’re looking for a way to do nice optional verbose output for your own CLI then you could define whatever semantics you need for the log levels you use (as an example, using something like env_logger’s filtering to make —verbose mean logging all events raised by your CLI, but only info or higher level events from dependencies).

[sfackler]

Trace is used often in low-level libraries like hyper and tokio for very verbose logging information that can be useful to diagnose issues.

[TyPR124]

I think a "Notice" log level and a "Critical" log level would both be very nice to have. I would argue "Critical" in particular is a very necessary addition.

I was recently integrating logging for an application with Google Cloud. They define several more log levels that log does: https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#logseverity

Personally I am thinking that (to an extent) the more levels log offers, the better. Libraries that wrap some external logging API can choose how they want to map log's levels to the API, however log doesn't currently have enough levels to meaningfully make use of the levels provided in Google's API (or any similar API with more levels than log provides).

Google says that "Info" is general runtime info, such as performance stats, while "Notice" would be more significant events, like process startup, shutdown, or config changes. I think this is a meaningful difference that is worth supporting.

In terms of a "Critical" event class, I think this is especially useful (much more than "Notice") for differentiating between "this is an error that by itself isn't a big deal" and "this is an error that by itself is likely impacting my production environment negatively right now". Google offers a few more levels worse than Critical, though I I don't see those as quite as necessary in general (but, again, more levels means logging libraries can have a more fine-grained mapping of levels, and it's not like you are forced to use every log level in your application if you don't want/need them).

I don't think either Notice or especially Critical log levels are that uncommon. I know (for example) Windows supports a Critical log level.

Given this is (AFAIK) the de-facto logging facade for Rust, it is currently disappointing that I can't utilize these additional levels in Google's or anyone else's API.

[sfackler]

Adding a log level is a breaking change. The existing levels match slf4j (with the exception of a fatal level for historical reasons).

[TyPR124]

Adding a log level is a breaking change.

Breaking changes happen. The de-facto logging crate shouldn't hinder itself by refusing to make breaking changes.

The existing levels match slf4j

The existing levels clearly do NOT match many other logging APIs. I don't see why a single Java library is considered the authority on logging levels. Why not Google? Or Microsoft? Or Amazon? All three of these entities provide a "Critical" (or "Fatal") log level that is impossible to map from log in a generic and meaningful way. Surely having the ability to better support these platforms is worthwhile.

I don't mean to sound hostile (I probably do, sorry), but I don't see either as valid reasons to avoid change.

[ijackson]

I also agree that log should have both Notice and Critical. Unix syslog has them and they are very useful. I'm currently writing an app where I'm really feeling the lack of both of these.

[Thomasdezeeuw]

Any more movement on this? I could also use some more severity levels.

[rudolphfroger]

I think the log crate needs to support the default eight Unix syslog severity levels. See RFC3164 and RFC 5424. Many systems have used these levels as a standard to build upon and/or actually use syslog.

[shutton]

Minimally, please add 'notice'. It's a key level in enterprise applications that's necessary for situations where you want low-noise logs, but need to see certain interesting events. 'Warning' is too strong, meriting attention, whereas 'notice' is something you'd log in case you needed to look back for something that might hint at a problem, but not until you notice something is awry.

For others, here's the overlap between syslog and log:

log      syslog
-------  ---------
-        emergency
-        alert
-        critical
Error    error
Warn     warning
-        notice
Info     info
Debug    debug
Trace    -

[jo-so]

Having a level between Warn and Info would allow addressing messages

• like user login/logout, account creation, device came online, ... for normal service inspection – Notice
• like user saved file, user started job ... for deeper service inspection (i.e. up-on request) – Info

Having a level higher than Error would allow distinguishing messages

• of graceful handled errors (»db connection lost«) ­– Warn
• of unhandled errors (»failed to write file«) – Error
• of errors they render the service unusable (panic, »failed to listen to socket«) – Critical

[KodrAus]

In general, I would argue against a proliferation of extra log levels in favor of better filtering on other properties of the log event. Levels are at best a coarse-grained proxy for the likelihood of an event being important to surface/retain. The crate currently offers a reasonable coarse-grained set of levels that cover the majority of cases. Adding more of them doesn't necessarily result in better diagnostics, and having to map them one-to-one to the levels of any other system isn't necessarily a path to a useful set of levels in log.

We've been steadily working towards better structured logging support over the last few years (there is also the tracing crate that already supports it) that would better serve users that want to work with some custom log levels, such as an associated syslog level.

[Sfinx]

Sad that there is no custom levels - I'd like to use the:

• 'fatal' level for critical messages
• 'always' level for banners that must be printed with any verbosity level set (app version data or licensing for ex.)

[ta32]

I wish there as an always level. Sometimes you want to print some stuff like what port and address a web server is running on. I just use warning but it looks kind of weird...

I suppose you could just make a crate and prints with the same format used by the logging system.

[KodrAus]

I think communicating end-user messages is really orthogonal to log, which is targeted at collecting diagnostic output. There might be some overlapping technical concerns but the details of end-user rendering I think are different enough that a dedicated domain-specific implementation would be better.

[Billy-Sheppard]

I would also love to see a new level added.

External crates especially love to fill up INFO with lots of useful messaging but sometimes I find wanting a MSG or NOTICE level for targeted important messages that don't make sense in ERROR/WARN. It is possible to get around this by using crate level log level filters but that's clunky imo, and I often want my scope all encompassing.

Custom levels would do some to alleviate this, I haven't looked into it, but would a PR be welcome/well received?

CRITICAL, IMPORTANT, ALERT, and ALWAYS all feel like they could be useful.

[BarronKane]

I too would like to see a higher logging level. I've always used FATAL in every language as a hint that this is a potentially irrecoverable error, and in some instances I will set a FATAL log to trigger an automatic panic or shutdown with the log message.

I understand this crate also strives to be compatible in no_std environments, but perhaps an std feature to set dynamic log levels? I've forked the repo to add in FATAL and have played with patching my fork in other logging libraries to some success.

Any further input I have would be a rehash of the above, but I would like to say that the existing levels truly are fine for serving crude categories of information and simply find a more critical category would be apt. My personal opinion would lean into a fully abstract implementation of all of these to be defined by the consumer (with the existing levels as default), but that would constitute an entirely new paradigm that probably necessitates a separate crate entirely. I may end up exploring this idea using this crate as a base, but the existing crates, like tracing, implement much of what I want even if they're a bit heavy.

As an aside, for the state this crate is in, I agree with @Billy-Sheppard whether FATAL or CRITICAL etc is used.

[skypexu]

Classic log levels can never meet a wide range of needs. For example, Ceph has more granularity, like log level from 1 to 100，they are just number. I don't think as a generical log crate, the classic log levels is enough.
their code looks like this :
dout(20) << func << " waiting for previous aio to complete" << dendl;
dout(30) << "dump:\n";

[0xForerunner]

I would also like to have a notice and critical level. I don't think better filtering is a substitute for more log levels. I think following the same spec that unix does seems reasonable to me.

[cscherrNT]

To not have a breaking change, it might be a good idea to implement the new/custom log levels behind a non-default feature. This would ensure that existing crates making use of log have no breaking changes (for example when matching the log level).

This way, users can select if they want the existing 5 log levels, or additional. Personally, I think more log levels are useful to distinguish events further. panic! is not really a replacement for FATAL, as it does not log but instantly stop the application.

[Sajjon]

Apple's swift/log has:

• trace
• debug
• info
• notice
• warning
• error
• critical

Coming from Swift world, I miss critical and notice.

[MichalLebeda]

I still fail to understand what is the reasoning behind not adding more levels except it being "breaking change" which I believe would be addressed pretty quickly & easily in the impl. crates.

I understand that some users may find the current set of levels sufficient, but that may not be the case for others, especially in case of mapping levels from other systems as the bijection is often impossible.

I think the best way to figure this out would be a simple poll.

[Thomasdezeeuw]

I still fail to understand what is the reasoning behind not adding more levels except it being "breaking change" which I believe would be addressed pretty quickly & easily in the impl. crates.

You're vastly underestimating how much effort it takes to update an entire ecosystem to a new version of a crate like log.

Take a look at the downloads of Log v0.3: https://crates.io/crates/log/0.3.9, it still gets 10,000-20,000 downloads a day (in the last 90 days). If you look at it's dependents it still list 16k crates on crates.io: https://crates.io/crates/log/reverse_dependencies.

v0.4 was related 6 years ago.

6 years and it's still being used. And that's not even the main problem. The main problem is (in)compatibility between crates using log. A lot of effort was put into the v0.3 -> v0.4 transition to make it as smoothly a possible, but it's not perfect, same will be true for a possible transition from v0.4 to v0.5 (or v1?).

I don't think we should be making breaking changes lightly, it creates a lot of churn in the ecosystem.

I understand that some users may find the current set of levels sufficient, but that may not be the case for others, especially in case of mapping levels from other systems as the bijection is often impossible.

Question is where you draw the line. What levels should be included, what shouldn't and why?