Panic when using production configs and small log level

[AMecea]

This is related with this issue.

When trying to use other log levels smaller than -1 (e.g. V(2)) with cfg := zap.NewProductionConfig() (with development config works fine) I've got the following panic error:

panic: runtime error: index out of range

goroutine 1 [running]:
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore.(*counters).get(0xc0001d2000, 0xc000151cfe, 0xbb762a, 0xc, 0xc000151be0)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore/sampler.go:48 +0x79
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore.(*sampler).Check(0xc00018f560, 0xfe, 0xbee5907d06b7cfd4, 0x2a36d55, 0x11b62a0, 0xbb4baf, 0x7, 0xbb762a, 0xc, 0x0, ...)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/zapcore/sampler.go:128 +0x9d
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap.(*Logger).check(0xc0000a91a0, 0x40bffe, 0xbb762a, 0xc, 0xc00010e501)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/logger.go:269 +0x137
github.com/presslabs/mysql-operator/vendor/go.uber.org/zap.(*Logger).Check(0xc0000a91a0, 0xb2a0fe, 0xbb762a, 0xc, 0xfffffffffffffffe)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/go.uber.org/zap/logger.go:172 +0x48
github.com/presslabs/mysql-operator/vendor/github.com/go-logr/zapr.(*infoLogger).Info(0xc0000bba40, 0xbb762a, 0xc, 0x0, 0x0, 0x0)
	/home/x/go/src/github.com/presslabs/mysql-operator/vendor/github.com/go-logr/zapr/zapr.go:69 +0x4e
main.main()
	/home/x/go/src/github.com/presslabs/mysql-operator/cmd/mysql-operator-sidecar/main.go:119 +0x62f

[shawn-hurley]

@DirectXMan12 This is due to sampling I believe. We worked around this the operator-sdk by forcing a user who goes below the debug level for zap to turn off sampling.

I could submit a PR here if that logic makes sense to you.

[DirectXMan12]

We could do that. Might want to rethink our levels and/or get a fix into Zap too -- IIRC, something in the Zap docs said you were allowed to do levels lower than debug, but I can't seem to find it now.

[dbenque]

@DirectXMan12 This is due to sampling I believe. We worked around this the operator-sdk by forcing a user who goes below the debug level for zap to turn off sampling.

I could submit a PR here if that logic makes sense to you.

My understanding is that this logic would work only if the log level is static (don't change after initial config).
For example on my side I am using https://github.com/uber-go/zap/blob/master/http_handler.go#L39
And the sampler is created (or not) at logger creation.
Would be good if the sampler could be protected against panic.

[DirectXMan12]

Yeah, it's mainly due to how we map numbers to log levels. We talked to the zap folks at some point IIRC, and they weren't super-enthused about custom log levels existing and mostly considered what we're doing to be a bit of a hack (see uber-go/zap#713). I'm not quite sure what we want to do.

[thockin]

After 1.0.0-rc. (#28) this seems to be fixed.