Critical log level

[pkieltyka]

Hi there, just wondering thoughts on adding a Critical log level? the idea here is that an error may be acceptable for example fro a 401/403 http status from an unauthorized request, and a panic is of course something unexpected and includes a stacktrace. A "critical" log would be a condition that is undesired and could be an integrity check in part of a system and if triggered we shouldn't panic, but returning just an "error" isn't high enough severity.

thanks for the consideration

[pkieltyka]

also FYI, products like GCP Stackdriver (https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#LogSeverity) and Datadot logging also consider the "Critical" severity level https://docs.datadoghq.com/agent/troubleshooting/debug_mode/?tab=agentv6v7#agent-log-level

[adw1n]

@rs would you accept a PR that adds the Critical log level?

[plo-]

Any news?

[rs]

A 401/403 should usually be logged as an error or warning. I don't feel like we need a new level. The syslog critical level is currently mapped to zerolog panic level. If you want to use the panic level without actually panicking the program, you can use WithLevel(zerolog.PanicLevel).

[adw1n]

you can use WithLevel(zerolog.PanicLevel).

Right, so we don't need a new level after all but a helper function similar to Debug(), Info() etc. would be nice. @rs what are your thoughts on adding func (l *Logger) Critical() which logs the message with panic level but doesn't call panic()?

// Critical starts a new message with panic level. Contrary to Panic()
// receiver panic() function is not called by the Msg method.
// 
// You must call Msg on the returned event in order to send the event.
func (l *Logger) Critical() *Event {
	return l.newEvent(PanicLevel, nil)
}

[rs]

That would be confusing.

[Antonboom]

+1

The following logging levels are standardized in my company:

• CRITICAL
• ERROR
• WARNING
• INFO
• DEBUG
• TRACE

For the case described by the topic starter, we use ERROR/WARN, but CRITICAL is useful for critical situations (for example, when one of the internal components broke down and pod is no longer ready).

[chippyash]

A way to add new levels in client code would be most appropriate. We run PHP progs utilizing the very popular monolog logger which defines

DEBUG
INFO
NOTICE
WARNING
ERROR
CRITICAL
ALERT
EMERGENCY

And these are used extensively in our log monitoring, so maintaining compatibility from Go applications is rather important. And the fact that FatalLevel and PanicLevel will stop the application is not always appropriate.