Allow specifying user defined log level names

[pmalek]

Is your feature request related to a problem? Please describe.

As a user of zap I'd like to define my own custom log level, let's call it TraceLevel. It's destined to be more verbose than Debug.

Because currently the log levels are checked against a known, concrete set of values

zap/zapcore/level.go

Lines 134 to 156 in 4451b47

	// CapitalString returns an all-caps ASCII representation of the log level.
	func (l Level) CapitalString() string {
	// Printing levels in all-caps is common enough that we should export this
	// functionality.
	switch l {
	case DebugLevel:
	return "DEBUG"
	case InfoLevel:
	return "INFO"
	case WarnLevel:
	return "WARN"
	case ErrorLevel:
	return "ERROR"
	case DPanicLevel:
	return "DPANIC"
	case PanicLevel:
	return "PANIC"
	case FatalLevel:
	return "FATAL"
	default:
	return fmt.Sprintf("LEVEL(%d)", l)
	}
	}

when pretty printing the log level name I cannot define a name on my level and see it in the logs.

All I can get is fmt.Sprintf("LEVEL(%d)", l)

Describe the solution you'd like

Define an interface that user defined log levels can be checked against and if they implement it then use it to get the name of the log level.

If that fails then resort to fmt.Sprintf("LEVEL(%d)", l).

Describe alternatives you've considered

None exist to the best of my knowledge.

Is this a breaking change?

No.

[JacobOaks]

Internal Ref: GO-2011

[SoulPancake]

Can I work on this ? @JacobOaks

[JacobOaks]

Can I work on this ? @JacobOaks

Of course! Feel free to open a PR.

[sywhang]

Sorry I hopped late onto this thread, but I believe we shouldn't add this feature to Zap.

Allowing definitions of custom levels is a breaking change and we do not want that. See the discussions in #680.

Existing encoders and samplers could break due to such things. For example: #713 is an example of someone defining their own custom log level which broke the sampler.