Add one more log level (notice/verbose?)

intgr commented

2019-05-26 06:57:18 -05:00

(Migrated from github.com)

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? :)

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? :)

👍 14 👎 1 ❤️ 1

KodrAus commented

2019-05-26 07:35:18 -05:00

(Migrated from github.com)

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).

Hi @intgr :wave: 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 commented

2019-05-26 09:37:30 -05:00

(Migrated from github.com)

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 commented

2020-04-12 11:07:37 -05:00

(Migrated from github.com)

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.

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.

👍 15

sfackler commented

2020-04-12 11:27:05 -05:00

(Migrated from github.com)

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

TyPR124 commented

2020-04-12 11:53:04 -05:00

(Migrated from github.com)

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.

> 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.

👍 18

ijackson commented

2020-09-06 07:47:50 -05:00

(Migrated from github.com)

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.

👍 1

Thomasdezeeuw commented

2020-10-21 10:18:34 -05:00

(Migrated from github.com)

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

rudolphfroger commented

2020-12-28 03:55:21 -06:00

(Migrated from github.com)

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.

👍 22

shutton commented

2021-05-27 21:32:37 -05:00

(Migrated from github.com)

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    -

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 - ```

👍 20 👎 1

jo-so commented

2021-06-09 11:37:40 -05:00

(Migrated from github.com)

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

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*

👍 7 👎 1

KodrAus commented

2021-11-14 23:10:47 -06:00

(Migrated from github.com)

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.

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 commented

2022-02-22 15:52:33 -06:00

(Migrated from github.com)

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.)

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.)

👍 8

ta32 commented

2022-04-08 07:33:26 -05:00

(Migrated from github.com)

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.

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 commented

2022-04-20 01:55:37 -05:00

(Migrated from github.com)

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.

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.

👍 2

Billy-Sheppard commented

2022-08-03 22:35:09 -05:00

(Migrated from github.com)

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.

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.

👍 5

BarronKane commented

2023-07-19 20:48:55 -05:00

(Migrated from github.com)

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.

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 commented

2023-08-17 02:52:16 -05:00

(Migrated from github.com)

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";

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 commented

2023-10-20 21:10:36 -05:00

(Migrated from github.com)

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.

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 commented

2024-03-06 10:21:25 -06:00

(Migrated from github.com)

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.

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 `match`ing 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.

👍 3

Sajjon commented

2024-05-03 08:37:30 -05:00

(Migrated from github.com)

Apple's swift/log has:

trace
debug
info
notice
warning
error
critical

Coming from Swift world, I miss critical and notice.

[Apple's swift/log has](https://github.com/apple/swift-log): - trace - debug - info - notice - warning - error - critical Coming from Swift world, I miss `critical` and `notice`.

👍 1

MichalLebeda commented

2024-05-18 19:29:31 -05:00

(Migrated from github.com)

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.

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 commented

2024-05-19 04:38:21 -05:00

(Migrated from github.com)

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 released 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?

> 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 released 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?

👍 1

narodnik commented

2025-01-16 02:58:59 -06:00

(Migrated from github.com)

We definitely need a log level between Info and Debug. Right now in a large project, we have a huge trace amount of trace output which is disabled by default. But then even debug is seriously noisy. We have to maintain a large list of targets that need muting for debug to be usable. We are abusing the targets when ideally there would be an extra log level.

👍 4

psztoch commented

2025-06-18 14:15:03 -05:00

(Migrated from github.com)

Please add notice and critical level. It is very necessary.

The kernel log levels are:

0 (KERN_EMERG) The system is unusable.
1 (KERN_ALERT) Actions that must be taken care of immediately.
2 (KERN_CRIT) Critical conditions.
3 (KERN_ERR) Non-critical error conditions.
4 (KERN_WARNING) Warning conditions that should be taken care of.
5 (KERN_NOTICE) Normal, but significant events.
6 (KERN_INFO) Informational messages that require no action.
7 (KERN_DEBUG) Kernel debugging messages, output by the kernel if the developer enabled debugging at compile time.

Please add notice and critical level. It is very necessary. The kernel log levels are: 0 (KERN_EMERG) The system is unusable. 1 (KERN_ALERT) Actions that must be taken care of immediately. 2 (KERN_CRIT) Critical conditions. 3 (KERN_ERR) Non-critical error conditions. 4 (KERN_WARNING) Warning conditions that should be taken care of. 5 (KERN_NOTICE) Normal, but significant events. 6 (KERN_INFO) Informational messages that require no action. 7 (KERN_DEBUG) Kernel debugging messages, output by the kernel if the developer enabled debugging at compile time.

👍 2

psztoch commented

2025-06-18 14:22:56 -05:00

(Migrated from github.com)

Why notice and critical are needed:

🔶 notice
Definition: A level between info and warn.
Use case: Meant for important but non-problematic events. Examples:
System configuration changes.
An admin user logs in.
An event that should be visible to operators but is not a warning or error.
Why info is not enough: info can be noisy—it may include routine operational logs (e.g., thread started, cache warmed up). notice highlights messages that are not errors, but still require attention.

🔴 critical
Definition: A level above error, indicating:
Threats to system stability.
Events requiring immediate action.
Catastrophic failures (e.g., data loss, system corruption).
Why error is not enough: In many applications, error is used liberally (e.g., failed login attempt, network timeout). critical distinguishes events that are truly urgent and severe:
Critical database corruption.
Out-of-memory errors.
Service crashing or halting.

Why notice and critical are needed: 🔶 notice Definition: A level between info and warn. Use case: Meant for important but non-problematic events. Examples: System configuration changes. An admin user logs in. An event that should be visible to operators but is not a warning or error. Why info is not enough: info can be noisy—it may include routine operational logs (e.g., thread started, cache warmed up). notice highlights messages that are not errors, but still require attention. 🔴 critical Definition: A level above error, indicating: Threats to system stability. Events requiring immediate action. Catastrophic failures (e.g., data loss, system corruption). Why error is not enough: In many applications, error is used liberally (e.g., failed login attempt, network timeout). critical distinguishes events that are truly urgent and severe: Critical database corruption. Out-of-memory errors. Service crashing or halting.

👍 5

kellytk commented

2025-06-18 17:57:29 -05:00

(Migrated from github.com)

As it's been six years, movement or maintainer comment would be greatly appreciated.

Thomasdezeeuw commented

2025-06-18 21:51:48 -05:00

(Migrated from github.com)

As it's been six years, movement or maintainer comment would be greatly appreciated.

Both @KodrAus and myself made comments on this thread pointing out issues, has there been any progress on fixing these?

> As it's been six years, movement or maintainer comment would be greatly appreciated. Both @KodrAus and myself made comments on this thread pointing out issues, has there been any progress on fixing these?

kellytk commented

2025-06-19 02:32:16 -05:00

(Migrated from github.com)

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

What about creating a new crate from a fork of this one? In that crate, add additional levels that:

Have community support.
Are either present in https://man.freebsd.org/cgi/man.cgi?query=syslog&apropos=0&sektion=3&manpath=FreeBSD+14.3-RELEASE&arch=default&format=html or the Linux equivalent, establishing long-standing prior art.

It would seem to need to be more system environment focused than general purpose as WASI Logging states:

LOG_EMERG and LOG_ALERT have no corresponding levels, because WASI programs don't have visibility into how their own errors affect "the system" as a whole.

> You're vastly underestimating how much effort it takes to update an entire ecosystem to a new version of a crate like log. What about creating a new crate from a fork of this one? In that crate, add additional levels that: 1. Have community support. 2. Are either present in https://man.freebsd.org/cgi/man.cgi?query=syslog&apropos=0&sektion=3&manpath=FreeBSD+14.3-RELEASE&arch=default&format=html or the Linux equivalent, establishing long-standing prior art. It would seem to need to be more system environment focused than general purpose as [WASI Logging](https://github.com/WebAssembly/wasi-logging?tab=readme-ov-file#what-levels-should-there-be) states: >LOG_EMERG and LOG_ALERT have no corresponding levels, because WASI programs don't have visibility into how their own errors affect "the system" as a whole.

👍 2

tisonkun commented

2025-09-20 23:34:02 -05:00

(Migrated from github.com)

One issue is that we expose Level's and LevelFilter's repr as usize, and there is no space between each level.

It should be possible to leave some space between levels, such as:

Error = 300
Warn = 400
Info = 500
Debug = 600
Trace = 700

Then when we want to add more level like NOTICE/CRITICAL, we won't break ourselves.

Users should not depend on the repr but use them as enum. Ord and Eq still works, but no prev/next.

Refs -

One issue is that we expose `Level`'s and `LevelFilter`'s repr as usize, and there is no space between each level. It should be possible to leave some space between levels, such as: ``` Error = 300 Warn = 400 Info = 500 Debug = 600 Trace = 700 ``` Then when we want to add more level like NOTICE/CRITICAL, we won't break ourselves. Users should not depend on the repr but use them as enum. Ord and Eq still works, but no prev/next. Refs - * https://github.com/apache/logging-log4j2/blob/9b9a0d43/log4j-api/src/main/java/org/apache/logging/log4j/spi/StandardLevel.java * https://github.com/apache/logging-log4j2/blob/9b9a0d43/log4j-api/src/main/java/org/apache/logging/log4j/Level.java * https://github.com/qos-ch/slf4j/blob/183aaa50/slf4j-api/src/main/java/org/slf4j/event/EventConstants.java * https://github.com/qos-ch/slf4j/blob/183aaa50/slf4j-api/src/main/java/org/slf4j/event/Level.java

👍 2

Thomasdezeeuw commented

2025-09-24 09:44:05 -05:00

(Migrated from github.com)

One issue is that we expose Level's and LevelFilter's repr as usize, and there is no space between each level.

That actually doesn't matter too much. Because simply adding a variant to LevelFilter is already a breaking change.

The usize representation should really been an internal detail, not a public one (maybe something to switch for the next breaking change version).

> One issue is that we expose `Level`'s and `LevelFilter`'s repr as usize, and there is no space between each level. That actually doesn't matter too much. Because simply adding a variant to `LevelFilter` is already a breaking change. The `usize` representation should really been an internal detail, not a public one (maybe something to switch for the next breaking change version).

KodrAus commented

2025-10-02 18:58:53 -05:00

(Migrated from github.com)

I've ended up softening on this issue over the years, and when we do another breaking release (which isn't planned at this stage) I'm on board with adding a level after error for critical/fatal conditions, but not on adding another notice/informational level, which we already have three of.

❤️ 1

psztoch commented

2025-10-03 01:45:57 -05:00

(Migrated from github.com)

The need for CRITICAL/FATAL is obvious and won't be a major issue. We're looking forward to it!

However, adding NOTICE is still a major need, and in my opinion, it needs to be addressed...
Currently, trace is treated as syslog debug, debug as syslog info, and info as syslog notice. This leads to significant disruptions in some applications.

I believe that NOTICE should be added.
Maybe we should add the ability to remap these levels to syslog in two modes:

old/current: notice+info -> syslog notice, info -> syslog debug, debug -> syslog trace,
new/default: notice->syslog notice, info->syslog info, debug+trace->syslog debug?

The need for CRITICAL/FATAL is obvious and won't be a major issue. We're looking forward to it! However, adding NOTICE is still a major need, and in my opinion, it needs to be addressed... Currently, trace is treated as syslog debug, debug as syslog info, and info as syslog notice. This leads to significant disruptions in some applications. I believe that NOTICE should be added. Maybe we should add the ability to remap these levels to syslog in two modes: - old/current: notice+info -> syslog notice, info -> syslog debug, debug -> syslog trace, - new/default: notice->syslog notice, info->syslog info, debug+trace->syslog debug?

👍 1

KodrAus commented

2025-10-03 03:58:17 -05:00

(Migrated from github.com)

I’m not in favour of adding Notice unless we remodel Level entirely to be based on syslog levels, which I’m currently not because it would mean removing a level we already have. The levels in this crate are not a 1-to-1 mapping with syslog, and it’s always possible to rationalise another level between 2 others based on some specific use-cases. So unless we want to anchor levels fully to an existing concept there’s no end to this discussion.

I’m not in favour of adding Notice unless we remodel `Level` entirely to be based on syslog levels, which I’m currently not because it would mean removing a level we already have. The levels in this crate are not a 1-to-1 mapping with syslog, and it’s always possible to rationalise another level between 2 others based on some specific use-cases. So unless we want to anchor levels fully to an existing concept there’s no end to this discussion.

alextes commented

2025-10-03 05:24:29 -05:00

(Migrated from github.com)

i'm in favor of "more than current". i think this crate should make breaking changes extremely rarely. like maybe the next set should be considered the final set forever and always.

what i don't understand however, beyond the stable default set discussion at hand, is, if so many clearly want a different set and it's v hard to converge, clearly different users have different needs. why not make it configurable? perhaps i'm missing something obvious? i do believe there's plenty precedent.

wise lib maintainers will stick with the default. wise app-space users will add whatever levels are convenient.

i see this suggestion was made back in aug 2022 already. is there an obvious reason we can't do this? i believe Rust's third core tenet was "productivity". i appreciate the effort made to find a good default set but agree with some its discussion will likely last forever. but at least for the vast majority of rust users, in app space, it doesn't have to. they could configure their preferred levels. happy to create a new issue for this.

i'm in favor of "more than current". i think this crate should make breaking changes extremely rarely. like maybe the next set should be considered the final set forever and always. what i don't understand however, beyond the stable default set discussion at hand, is, if so many clearly want a different set and it's v hard to converge, clearly different users have different needs. why not make it configurable? perhaps i'm missing something obvious? i do believe there's plenty precedent. wise lib maintainers will stick with the default. wise app-space users will add whatever levels are convenient. i see this suggestion was made back in aug 2022 already. is there an obvious reason we can't do this? i believe Rust's third core tenet was "productivity". i appreciate the effort made to find a good default set but agree with some its discussion will likely last forever. but at least for the vast majority of rust users, in app space, it doesn't have to. they could configure their preferred levels. happy to create a new issue for this.

👍 2

Thomasdezeeuw commented

2025-10-03 05:28:23 -05:00

(Migrated from github.com)

@alextes how do you propose to make it configurable?

alextes commented

2025-10-03 06:34:08 -05:00

(Migrated from github.com)

i don't think this is the issue to discuss this @Thomasdezeeuw . if you think its within the realm of possibility how about i create a new issue for it?

if you really want to discuss approaches here:

first steps custom level exploration

i don't know this crate well. taking a look for 5m together with AI. two possible approaches:

Custom Variant Registry

Replace the fixed enum at src/lib.rs:475 with pub enum Level { Error, …, Trace, Custom(&'static LevelDef) } and introduce a LevelDef { name: &'static str, ordinal: u16, fallback: Level }
registry guarded by an RwLock. Add log::register_level(LevelDef) that interns defs and returns a &'static LevelDef, so call-sites can write log!(Level::Custom(MY_VERBOSE), …).
Adjust lookups that currently index LOG_LEVEL_NAMES (src/lib.rs:456) to first check the built-ins and then fall back to the registry. Level::iter()/Level::from_str() emit built-ins first
and append registered entries so existing logic keeps its ordering guarantees.
Teach LevelFilter (src/lib.rs:637) to accept either built-ins or LevelDef handles by comparing ordinals; keep the existing constants but add LevelFilter::Custom(u16) for per-registry
filters.
The macros (src/macros.rs:23) stay source-compatible because they already accept any Level expression; they just need to resolve string names via the registry for formatting.
STATIC_MAX_LEVEL keeps compile-time pruning for the shipped variants, while custom levels are always decided at runtime.
Pros: existing code keeps matching on built-in variants, custom levels get real names/ordering and surface everywhere that prints a level. Cons: bumps MSRV/API because of the new payload
variant and drops the current #[repr(usize)], so this is a “next major” story and needs a migration plan for consumers relying on mem::size_of::() or integer casts.

Metadata Sidecar Level

Leave Level/LevelFilter exactly as-is, but extend Metadata (src/lib.rs:1157) and Record (src/lib.rs:841) with an optional custom_level: Option<&'static CustomLevel>, where CustomLevel
stores { name: &'static str, ordinal: u16 }. Add MetadataBuilder::custom_level() so backends (or new helper macros) can stamp records with richer level signals while still picking the
nearest built-in Level as the fallback.
Extend the private logging entry point in src/macros.rs:59 to call a new helper like __private_api::resolve_level($lvl) that returns (Level, Option<&'static CustomLevel>). For built-in
macros nothing changes; a new log_custom! (or user-provided macro) can pass a CustomLevel handle together with the fallback Level.
Logger implementors who care about the new levels read record.custom_level() and compare against their own configuration (e.g., a HashMap<&'static str, LevelFilter>); those who don’t opt
in just keep using record.level() and remain unaware.
Pros: entirely backward compatible—no change to Level, no impact on STATIC_MAX_LEVEL, and existing consumers keep compiling untouched. Lets downstream crates experiment today by shipping
new macros or using MetadataBuilder directly. Cons: filtering for the new levels is opt-in and purely runtime; the compile-time max_level_* features cannot prune custom levels, and the
fallback Level has to be chosen carefully so legacy backends don’t mis-route records.

again, v quick reading but seems there's some tough trade-offs around what macros would be available, maybe users with custom levels would have to roll their own or call a non-macro version. another tough trade-off seems to be around performance. what can we prune at compile time. i feel one would have to dive deeper to call those. like maybe there is a real perf hit, maybe not, for log probably any hit is unacceptable, but then would you still let app users set a mode where they take the hit, or suggest to create another logging crate for this entirely to wrap log. idk. tough trade-offs. would have to explore and discuss together.

i don't think this is the issue to discuss this @Thomasdezeeuw . if you think its within the realm of possibility how about i create a new issue for it? if you really want to discuss approaches here: <details> <summary>first steps custom level exploration</summary> i don't know this crate well. taking a look for 5m together with AI. two possible approaches: Custom Variant Registry - Replace the fixed enum at src/lib.rs:475 with pub enum Level { Error, …, Trace, Custom(&'static LevelDef) } and introduce a LevelDef { name: &'static str, ordinal: u16, fallback: Level } registry guarded by an RwLock. Add log::register_level(LevelDef) that interns defs and returns a &'static LevelDef, so call-sites can write log!(Level::Custom(MY_VERBOSE), …). - Adjust lookups that currently index LOG_LEVEL_NAMES (src/lib.rs:456) to first check the built-ins and then fall back to the registry. Level::iter()/Level::from_str() emit built-ins first and append registered entries so existing logic keeps its ordering guarantees. - Teach LevelFilter (src/lib.rs:637) to accept either built-ins or LevelDef handles by comparing ordinals; keep the existing constants but add LevelFilter::Custom(u16) for per-registry filters. - The macros (src/macros.rs:23) stay source-compatible because they already accept any Level expression; they just need to resolve string names via the registry for formatting. STATIC_MAX_LEVEL keeps compile-time pruning for the shipped variants, while custom levels are always decided at runtime. - Pros: existing code keeps matching on built-in variants, custom levels get real names/ordering and surface everywhere that prints a level. Cons: bumps MSRV/API because of the new payload variant and drops the current #[repr(usize)], so this is a “next major” story and needs a migration plan for consumers relying on mem::size_of::<Level>() or integer casts. Metadata Sidecar Level - Leave Level/LevelFilter exactly as-is, but extend Metadata (src/lib.rs:1157) and Record (src/lib.rs:841) with an optional custom_level: Option<&'static CustomLevel>, where CustomLevel stores { name: &'static str, ordinal: u16 }. Add MetadataBuilder::custom_level() so backends (or new helper macros) can stamp records with richer level signals while still picking the nearest built-in Level as the fallback. - Extend the private logging entry point in src/macros.rs:59 to call a new helper like __private_api::resolve_level($lvl) that returns (Level, Option<&'static CustomLevel>). For built-in macros nothing changes; a new log_custom! (or user-provided macro) can pass a CustomLevel handle together with the fallback Level. - Logger implementors who care about the new levels read record.custom_level() and compare against their own configuration (e.g., a HashMap<&'static str, LevelFilter>); those who don’t opt in just keep using record.level() and remain unaware. - Pros: entirely backward compatible—no change to Level, no impact on STATIC_MAX_LEVEL, and existing consumers keep compiling untouched. Lets downstream crates experiment today by shipping new macros or using MetadataBuilder directly. Cons: filtering for the new levels is opt-in and purely runtime; the compile-time max_level_* features cannot prune custom levels, and the fallback Level has to be chosen carefully so legacy backends don’t mis-route records. again, v quick reading but seems there's some tough trade-offs around what macros would be available, maybe users with custom levels would have to roll their own or call a non-macro version. another tough trade-off seems to be around performance. what can we prune at compile time. i feel one would have to dive deeper to call those. like maybe there is a real perf hit, maybe not, for log probably any hit is unacceptable, but then would you still let app users set a mode where they take the hit, or suggest to create another logging crate for this entirely to wrap `log`. idk. tough trade-offs. would have to explore and discuss together. </details>

👍 1

Thomasdezeeuw commented

2025-10-03 06:38:20 -05:00

(Migrated from github.com)

Your suggesting as a solution for this issue so I think place is fine to discuss it. If you want to create a new issue that's also fine.

I'm not going to read an AI answer though, I have no interest in that. Please consider other people time and don't waste it. If you have a though through proposal that's great, but letting AI generate something isn't that.

Your suggesting as a solution for this issue so I think place is fine to discuss it. If you want to create a new issue that's also fine. I'm not going to read an AI answer though, I have no interest in that. Please consider other people time and don't waste it. If you have a though through proposal that's great, but letting AI generate something isn't that.

psztoch commented

2025-10-03 07:54:08 -05:00

(Migrated from github.com)

We shouldn't blindly look only at syslog. But it certainly has additional levels that we don't have: CRITICAL (something worse than ERROR) and NOTICE (something between WARNING and INFO).
And in some applications, these additional levels are very necessary. I believe they should be added as soon as possible. They can always be flattened if the log destination doesn't support our granularity.

We shouldn't blindly look only at syslog. But it certainly has additional levels that we don't have: CRITICAL (something worse than ERROR) and NOTICE (something between WARNING and INFO). And in some applications, these additional levels are very necessary. I believe they should be added as soon as possible. They can always be flattened if the log destination doesn't support our granularity.

👍 2

KodrAus commented

2025-10-03 18:36:51 -05:00

(Migrated from github.com)

The point of using exactly syslog's levels would be to sidestep any discussion on where to draw the line on adding more levels to log.

The issue with an extensible system is that it would make any level not directly mapped by log second-class. If we were to explore it, I think something like this might be the best:

impl<'a> RecordBuilder<'a> {
    pub fn level_custom(&mut self, level: &'a impl AsRef<Level> + Any) -> &mut Self;
}

impl<'a> Record<'a> {
    pub fn level(&self) -> Option<Level> {
        self.level.or_else(|| self.level_custom.as_ref().map(AsRef::as_ref).copied())
    }

    pub fn level_custom(&self) -> Option<impl Any + 'a> {
        self.level_custom.as_ref()
    }
}

So you can set a custom level and get it, but can always reduce it down to a regular Level. That also avoids us needing to figure out how to order custom levels with predefined ones.

The point of using exactly syslog's levels would be to sidestep any discussion on where to draw the line on adding more levels to `log`. The issue with an extensible system is that it would make any level not directly mapped by `log` second-class. If we were to explore it, I think something like this might be the best: ```rust impl<'a> RecordBuilder<'a> { pub fn level_custom(&mut self, level: &'a impl AsRef<Level> + Any) -> &mut Self; } impl<'a> Record<'a> { pub fn level(&self) -> Option<Level> { self.level.or_else(|| self.level_custom.as_ref().map(AsRef::as_ref).copied()) } pub fn level_custom(&self) -> Option<impl Any + 'a> { self.level_custom.as_ref() } } ``` So you can set a custom level and get it, but can always reduce it down to a regular `Level`. That also avoids us needing to figure out how to order custom levels with predefined ones.

kanru commented

2025-10-04 08:29:45 -05:00

(Migrated from github.com)

If a breaking change will be introduced, couldn't it use numerical levels and add utility to clamp values to predefined levels?

pub struct Level(u8);

For example, standard levels are modeled after syslog with 10 steps in between. 0=Critical, 10=Error, 20=Warning, etc.

Or it can use 100 steps if the repr can be larger than u8.

Numerical levels are pretty common and it allows customization.

It might even be possible to make it ABI compatible with the current version. Just reserve the already used numbers.

If a breaking change will be introduced, couldn't it use numerical levels and add utility to clamp values to predefined levels? ``` pub struct Level(u8); ``` For example, standard levels are modeled after syslog with 10 steps in between. 0=Critical, 10=Error, 20=Warning, etc. Or it can use 100 steps if the repr can be larger than u8. Numerical levels are pretty common and it allows customization. It might even be possible to make it ABI compatible with the current version. Just reserve the already used numbers.

👍 1

Sajjon commented

2025-10-04 08:37:41 -05:00

(Migrated from github.com)

If a breaking change will be introduced, couldn't it use numerical levels and add utility to clamp values to predefined levels?
pub struct Level(u8);
For example, standard levels are modeled after syslog with 10 steps in between. 0=Critical, 10=Error, 20=Warning, etc.

Or it can use 100 steps if the repr can be larger than u8.

Numerical levels are pretty common and it allows customization.

It might even be possible to make it ABI compatible with the current version. Just reserve the already used numbers.

I was thinking the exact same thing. Using steps of 10 should be enough. E.g:

Trace = 10,
Debug = 20,
Info = 30,
Notice = 40,
Warn = 50,
Error = 60,
Critical = 70,

> If a breaking change will be introduced, couldn't it use numerical levels and add utility to clamp values to predefined levels? > > ``` > pub struct Level(u8); > ``` > > For example, standard levels are modeled after syslog with 10 steps in between. 0=Critical, 10=Error, 20=Warning, etc. > > Or it can use 100 steps if the repr can be larger than u8. > > Numerical levels are pretty common and it allows customization. > > It might even be possible to make it ABI compatible with the current version. Just reserve the already used numbers. I was thinking the exact same thing. Using steps of 10 should be enough. E.g: ``` Trace = 10, Debug = 20, Info = 30, Notice = 40, Warn = 50, Error = 60, Critical = 70, ```

👍 4

BurntSushi commented

2025-10-04 08:40:08 -05:00

(Migrated from github.com)

[That's similar to what Go's `log/slog` package does.](https://pkg.go.dev/log/slog#Level)

👍 1

Thomasdezeeuw commented

2025-10-04 13:16:45 -05:00

(Migrated from github.com)

One problem I've had in the past with numerical log levels is that two systems can disagree what level a numerical value actually is, e.g. what does 30 mean? It makes string options a lot safer as no (sane) system would parse "critical" as "info" if it didn't have a critical log level (like log currently). However, if we go with (public) numerical values we lose the option to convert it to string in all cases.

One problem I've had in the past with numerical log levels is that two systems can disagree what level a numerical value actually is, e.g. what does `30` mean? It makes string options a lot safer as no (sane) system would parse `"critical"` as `"info"` if it didn't have a `critical` log level (like log currently). However, if we go with (public) numerical values we lose the option to convert it to string in all cases.

👍 1

KodrAus commented

2025-10-04 21:58:09 -05:00

(Migrated from github.com)

I would also not want to introduce numerical levels. Log levels are already z-indexes, but that’s largely offset by their semantics and coarse granularity. I don’t want to open the door to discussions like should this log be a 102 or a 103. This also leaves the problem of components needing to agree on what numbers any levels between levels, such as Notice, mean if they want to interpret them.

I would also not want to introduce numerical levels. Log levels are already z-indexes, but that’s largely offset by their semantics and coarse granularity. I don’t want to open the door to discussions like _should this log be a 102 or a 103_. This also leaves the problem of components needing to agree on what numbers any levels between levels, such as Notice, mean if they want to interpret them.

KodrAus commented

2025-10-04 23:36:04 -05:00

(Migrated from github.com)

Having said that, if we were to introduce numerical log levels though, I think we could adopt the same scheme as OpenTelemetry: https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber

That leaves just a few values per level for intermediate severities, and is already compatible with our current set of levels (plus a critical/fatal level).

Having said that, if we were to introduce numerical log levels though, I think we could adopt the same scheme as OpenTelemetry: https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber That leaves just a few values per level for intermediate severities, and is already compatible with our current set of levels (plus a critical/fatal level).

👍 5

tisonkun commented

2025-10-29 07:49:53 -05:00

(Migrated from github.com)

That's similar to what Go's log/slog package does.

Having said that, if we were to introduce numerical log levels though, I think we could adopt the same scheme as OpenTelemetry: https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber

Ref -

I'm recently reading Go's log/slog package and would consider a similar design a possible way to go:

pub struct Level(u8); // or u16? I don't think we need more

impl Level {
  const TRACE: Level = Level(1);
  const DEBUG: Level = Level(5);
  const INFO: Level = Level(9);
  const WARN: Level = Level(13);
  const ERROR: Level = Level(17);
  const CRIT: Level = Level(21); // or FATAL? or alias to FATAL?
}

Other logics may be similar to log/slog

The overall logic should be able to be adapted into our current Level design. I'll try to implement logforth's Level in this way to demonstrate the idea.

UPDATE: However, I noticed that opentelemetry-rust defines the severity as an enum:

github.com/open-telemetry/opentelemetry-rust@c54d2b84d0/opentelemetry/src/logs/record.rs (L141-L230)

(Out of the thread, I borrowed a new LevelFilter design from spdlog that may also be helpful, but it should be a different thread if anyone is interested in it.)

> [That's similar to what Go's `log/slog` package does.](https://pkg.go.dev/log/slog#Level) > Having said that, if we were to introduce numerical log levels though, I think we could adopt the same scheme as OpenTelemetry: https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber Ref - * https://github.com/rust-lang/log/issues/708 * https://github.com/open-telemetry/opentelemetry-specification/issues/4716 * https://github.com/open-telemetry/opentelemetry-specification/issues/4714 * https://github.com/fast/logforth/issues/195 I'm recently reading Go's `log/slog` package and would consider a similar design a possible way to go: ```rust pub struct Level(u8); // or u16? I don't think we need more impl Level { const TRACE: Level = Level(1); const DEBUG: Level = Level(5); const INFO: Level = Level(9); const WARN: Level = Level(13); const ERROR: Level = Level(17); const CRIT: Level = Level(21); // or FATAL? or alias to FATAL? } ``` Other logics may be similar to [`log/slog`](https://cs.opensource.google/go/go/+/refs/tags/go1.25.3:src/log/slog/level.go;l=17) The overall logic should be able to be adapted into our current `Level` design. I'll try to implement [`logforth`'s Level](https://github.com/fast/logforth/issues/195) in this way to demonstrate the idea. UPDATE: However, I noticed that opentelemetry-rust defines the severity as an enum: https://github.com/open-telemetry/opentelemetry-rust/blob/c54d2b84d0828183a3ba347bc66fa8b8268854f9/opentelemetry/src/logs/record.rs#L141-L230 (Out of the thread, I borrowed a new [`LevelFilter` design](https://github.com/fast/logforth/blob/41a327b70d9da45fc440c69f70835a33dec970b8/core/src/record.rs#L447-L498) from spdlog that may also be helpful, but it should be a different thread if anyone is interested in it.)

👍 1

SteveLauC commented

2025-11-26 19:58:33 -06:00

(Migrated from github.com)

IMHO, log levels to use and their semantics should be specific to applications, and crates like log should provide a sufficient set of levels so that applications can choose the ones they want to use.

IMHO, log levels to use and their semantics should be specific to applications, and crates like `log` should provide a sufficient set of levels so that applications can choose the ones they want to use.

filmil commented

2025-12-05 14:40:48 -06:00

(Migrated from github.com)

In case it is helpful, perhaps one could take a look at the "glog" API, e.g. as implemented by https://abseil.io/docs/cpp/guides/logging or https://github.com/golang/glog.

There are named log levels (FATAL, ERROR, WARNING, INFO, DEBUG), but also "verbose" logs which use an integer to denote verbosity. To avoid misunderstandings about what verbose log levels mean, verbose logging can be turned off or on per module, as well as for everything. (I also think that named log levels are given negative log level values, while verbose logs ended up being positive, but that's a detail.)

I personally found this approach rather useful over the years: have a few commonly-agreed upon logging levels, and then a large sea of "verbose" logs with arbitrary level of detail. This avoids needing to litigate the log levels that something should be logged at. It also avoids needing to agree on the "correct" meaning of log levels across modules or programs. And in the end allows the user to provide debug information with varying levels of granularity, when needed.

In case it is helpful, perhaps one could take a look at the "glog" API, e.g. as implemented by https://abseil.io/docs/cpp/guides/logging or https://github.com/golang/glog. There are named log levels (FATAL, ERROR, WARNING, INFO, DEBUG), but also "verbose" logs which use an integer to denote verbosity. To avoid misunderstandings about what verbose log levels mean, verbose logging can be turned off or on per module, as well as for everything. (I also think that named log levels are given negative log level values, while verbose logs ended up being positive, but that's a detail.) I personally found this approach rather useful over the years: have a few commonly-agreed upon logging levels, and then a large sea of "verbose" logs with arbitrary level of detail. This avoids needing to litigate the log levels that something should be logged at. It also avoids needing to agree on the "correct" meaning of log levels across modules or programs. And in the end allows the user to provide debug information with varying levels of granularity, when needed.

👍 1

VinnieThePooh commented

2025-12-09 19:21:15 -06:00

(Migrated from github.com)

Fatal/Critical log level is a must here.
Coming from .NET ecosystem, i don't get how that could be an oversight for such sort of essential log level.
Regarding automation of business processes fatal/critical log level usually means some unrecoverable error that requires immediate SRE/System Administrator intervention (event itself might be extremely expensive for business).

Currently it looks like the basic logging facade is designed not accurately enough (i would say even carelessly).

Just for reference how it looks in .NET ecosystem.
LogLevel from MS Logging Facade (please note the Critical log level):

namespace Microsoft.Extensions.Logging
{
    /// <summary>
    /// Defines logging severity levels.
    /// </summary>
    public enum LogLevel
    {
        /// <summary>
        /// Logs that contain the most detailed messages. These messages may contain sensitive application data.
        /// These messages are disabled by default and should never be enabled in a production environment.
        /// </summary>
        Trace = 0,

        /// <summary>
        /// Logs that are used for interactive investigation during development.  These logs should primarily contain
        /// information useful for debugging and have no long-term value.
        /// </summary>
        Debug = 1,

        /// <summary>
        /// Logs that track the general flow of the application. These logs should have long-term value.
        /// </summary>
        Information = 2,

        /// <summary>
        /// Logs that highlight an abnormal or unexpected event in the application flow, but do not otherwise cause the
        /// application execution to stop.
        /// </summary>
        Warning = 3,

        /// <summary>
        /// Logs that highlight when the current flow of execution is stopped due to a failure. These should indicate a
        /// failure in the current activity, not an application-wide failure.
        /// </summary>
        Error = 4,

        /// <summary>
        /// Logs that describe an unrecoverable application or system crash, or a catastrophic failure that requires
        /// immediate attention.
        /// </summary>
        Critical = 5,

        /// <summary>
        /// Not used for writing log messages. Specifies that a logging category should not write any messages.
        /// </summary>
        None = 6,
    }
}

Serilog's LogLevel enum definition (.NET's most popular 3rd-party logging provider, please notice the Fatal variant, it is aligned one-to-one with Critical from logging facade):

namespace Serilog.Events;

/// <summary>
/// Specifies the meaning and relative importance of a log event.
/// </summary>
public enum LogEventLevel
{
    /// <summary>
    /// Anything and everything you might want to know about
    /// a running block of code.
    /// </summary>
    Verbose,

    /// <summary>
    /// Internal system events that aren't necessarily
    /// observable from the outside.
    /// </summary>
    Debug,

    /// <summary>
    /// The lifeblood of operational intelligence - things
    /// happen.
    /// </summary>
    Information,

    /// <summary>
    /// Service is degraded or endangered.
    /// </summary>
    Warning,

    /// <summary>
    /// Functionality is unavailable, invariants are broken
    /// or data is lost.
    /// </summary>
    Error,

    /// <summary>
    /// If you have a pager, it goes off when one of these
    /// occurs.
    /// </summary>
    Fatal
}

So, i am voting for fatal variant.
Looking at previous comments the majority of different stacks have well aligned logging levels in their ecosystem, except of Rust.

Fatal/Critical log level is a must here. Coming from .NET ecosystem, i don't get how that could be an oversight for such sort of essential log level. Regarding automation of business processes fatal/critical log level usually means some unrecoverable error that requires immediate SRE/System Administrator intervention (event itself might be extremely expensive for business). Currently it looks like the basic logging facade is designed not accurately enough (i would say even carelessly). Just for reference how it looks in .NET ecosystem. [LogLevel from MS Logging Facade](https://github.com/dotnet/runtime/blob/0fb17f7320fbaaa93e91c4c08b3a03175bb5ca15/src/libraries/Microsoft.Extensions.Logging.Abstractions/src/LogLevel.cs#L44) (please note the `Critical` log level): ``` namespace Microsoft.Extensions.Logging { /// <summary> /// Defines logging severity levels. /// </summary> public enum LogLevel { /// <summary> /// Logs that contain the most detailed messages. These messages may contain sensitive application data. /// These messages are disabled by default and should never be enabled in a production environment. /// </summary> Trace = 0, /// <summary> /// Logs that are used for interactive investigation during development. These logs should primarily contain /// information useful for debugging and have no long-term value. /// </summary> Debug = 1, /// <summary> /// Logs that track the general flow of the application. These logs should have long-term value. /// </summary> Information = 2, /// <summary> /// Logs that highlight an abnormal or unexpected event in the application flow, but do not otherwise cause the /// application execution to stop. /// </summary> Warning = 3, /// <summary> /// Logs that highlight when the current flow of execution is stopped due to a failure. These should indicate a /// failure in the current activity, not an application-wide failure. /// </summary> Error = 4, /// <summary> /// Logs that describe an unrecoverable application or system crash, or a catastrophic failure that requires /// immediate attention. /// </summary> Critical = 5, /// <summary> /// Not used for writing log messages. Specifies that a logging category should not write any messages. /// </summary> None = 6, } } ``` [Serilog's LogLevel enum definition](https://github.com/serilog/serilog/blob/7f3a5bfec73dba1c3b29780b85a53b0fe2f7c52b/src/Serilog/Events/LogEventLevel.cs#L55) (.NET's most popular 3rd-party logging provider, please notice the `Fatal` variant, it is aligned one-to-one with `Critical` from logging facade): ``` namespace Serilog.Events; /// <summary> /// Specifies the meaning and relative importance of a log event. /// </summary> public enum LogEventLevel { /// <summary> /// Anything and everything you might want to know about /// a running block of code. /// </summary> Verbose, /// <summary> /// Internal system events that aren't necessarily /// observable from the outside. /// </summary> Debug, /// <summary> /// The lifeblood of operational intelligence - things /// happen. /// </summary> Information, /// <summary> /// Service is degraded or endangered. /// </summary> Warning, /// <summary> /// Functionality is unavailable, invariants are broken /// or data is lost. /// </summary> Error, /// <summary> /// If you have a pager, it goes off when one of these /// occurs. /// </summary> Fatal } ``` So, i am voting for fatal variant. Looking at previous comments the majority of different stacks have well aligned logging levels in their ecosystem, except of Rust.

👍 2

Rows
Columns

Add one more log level (notice/verbose?) #334