refactor(promslog): make NewNopLogger() wrapper around New(); turn on debug log flag

[tjhop]

While discussing the fix for prometheus/prometheus#16466, it was pointed
out that our promslog.NewNopLogger() convenience function would
benefit from using the same logic used when initializing loggers with
promslog.New(). By refactoring NewNopLogger to wrap New, it inherits
that same setup logic.

Signed-off-by: TJ Hoplock [email protected]

[tjhop]

cc: @machine424 @SuperQ

[machine424]

Thanks for this.

Thinking about it more for the Prometheus use case, others may argue that the logger is no longer truly a “no-op”, it does more things now, and the added overhead may not be acceptable in some scenarios.

If that’s a concern, perhaps we can have that under a new NewDiscardLogger, NewSilentLogger or something to avoid that overhead. In Prometheus, we’d use that everywhere (we could even employ forbidigo or something similar to block NewNopLogger usage, as for Prometheus itself we always initialize a new real logger) and clearly communicate this to “Prometheus as a library” users. They could still override it on their side with NewNopLogger (if they use common) or any other no-op logger if they need.

cc @bboreham @dimitarvdimitrov as they worked on related stuff according to prometheus/prometheus#15993

[bboreham]

I see the genesis of this was for testing. I don't think we want to turn on debug logging for nop-logger in non-test situations.

Also I'm going to change the title to reflect this change.

[tjhop]

Agreed, I don't find the debug logging to be a requirement here, personally. It was a suggestion from the linked issue, the original patch I suggested just updated the function to wrap New()

[machine424]

Yes it was my idea, because the issue/panic that made me suggest this change was at a Debug log https://github.com/prometheus/prometheus/blob/2e9ab9cc62c563cfeed21eb4100d3960812ca9a6/discovery/azure/azure.go#L725

It's not ideal that when you need the Debug logs the most you find them panicing, it would just add to the frustration.

Thant's why I suggested the following for non-test/prod situations where Prom is used as a library:

If that’s a concern, perhaps we can have that under a new NewDiscardLogger, NewSilentLogger or something to avoid that overhead. In Prometheus, we’d use that everywhere (we could even employ forbidigo or something similar to block NewNopLogger usage, as for Prometheus itself we always initialize a new real logger) and clearly communicate this to “Prometheus as a library” users. They could still override it on their side with NewNopLogger (if they use common) or any other no-op logger if they need.

But if you still think that's not worth it and if you're ok with the overhead, even without debug level, that the change adds to NewNopLogger, let's go for the initial change and just change NewNopLogger.