I tried the trick described in https://github.com/go-logr/logr/issues/149#issuecomment-1231513709 but it doesn't work for zerologr.

Here is a slightly altered example;

package main

import (
	"fmt"
	"os"

	"github.com/go-logr/logr"
	"github.com/go-logr/zerologr"
	"github.com/rs/zerolog"
)

func main() {
	zerolog.TimeFieldFormat = zerolog.TimeFormatUnixMs
	zerologr.NameFieldName = "logger"
	zerologr.NameSeparator = "/"

	zl := zerolog.New(os.Stderr)
	zl = zl.With().Caller().Timestamp().Logger().Level(zerolog.InfoLevel)
	var log logr.Logger = zerologr.New(&zl)
	lvl := 2
	fmt.Println("Lvl", lvl, "Enabled", log.V(lvl).Enabled())
	log.Info("Logr in action!", "the answer", 42)
}
// output: Lvl 2 Enabled true

https://go.dev/play/p/sR1JXKaxgPs

When the level is zerolog.InfoLevel log.V(2).Enabled() should return false.

When calling NewLogSync, zerolog.LevelField is mutated. This is problematic when an application uses zerolog as its logger and uses zerologr in order to satisfy a library's requirement to pass a logr implementation. This causes a side effect on the zerolog global state and forces the application to restore global variables.

https://github.com/go-logr/zerologr/blob/master/zerologr.go#L75-L77

Unfortunately, the optimization in the LogSink#Enabled method breaks the intended use of that function, as it is exposed to the user by logr.Logger#Enabled. Currently, it's hardcoded to return true for any value between 0 and 2. However, if I'm bothering to call log.Enabled explicitly, it's for one reason: I want to check if logging is enabled prior to doing an expensive operation solely for the sake of logging, such as doing an http dump of a request, or a stack trace.

As the comment in the code notes, Info() will do that for me already. So I never need to call Enabled but for one reason: I need to know for sure that the message will be output prior to doing that expensive operation.

This implementation breaks that, since Enabled doesn't check the actual verbosity level of the logger implementation. If it is to be of any use whatsoever, the result of Enabled must match that of the underlying logsink implementation. The only way to check that is to...well, check it.

Since there's more than one place that the zerolog.Level is compared to the int level, I added a helper function to convert consistently. I also parameterized it slightly with a constant. Although it doesn't do anything now, that levelDelta value could be configurable in the future.

bump zerolog version to the latest v1.27.0 and update dependencies with:

$ go mod tidy -compat=1.17

this also solves all currently open CVEs, see Snyk Report before:

We can only use the v-levels of 0, 1, 2, corresponding to InfoLevel, DebugLevel and TraceLevel of Zerolog.

It limits the finer level of V-level control.

This pr remove the correspondence between v-levels and zerolog levels, to more v-levels support.

func main() {
	zl := zerolog.New(os.Stderr)
	zl = zl.With().
		Caller().
		Timestamp().
		Logger()
	logger := zerologr.New(&zl)

I don't need the caller() option for regular Info() log, I want it only for Error(). Is it possible without creating two different logger ?

https://github.com/go-logr/zerologr/issues/6#issuecomment-1012533184

This gives the user an option to retain Zerolog's level key, for example if they have already configured Zerolog elsewhere in their application and want Logr to output in the same format/options, or disable it and use the v level key.

If options are not set, no changes are made to the current API and both Zerolog's level key and the v level key are printed.

Unfortunately, the optimization in the LogSink#Enabled method breaks the intended use of that function, as it is exposed to the user by logr.Logger#Enabled. Currently, it's hardcoded to return true for any value between 0 and 2. However, if I'm bothering to call log.Enabled explicitly, it's for one reason: I want to check if logging is enabled prior to doing an expensive operation solely for the sake of logging, such as doing an http dump of a request, or a stack trace.

As the comment in the code notes, Info() will do that for me already. So I never need to call Enabled but for one reason: I need to know for sure that the message will be output prior to doing that expensive operation.

This implementation breaks that, since Enabled doesn't check the actual verbosity level of the logger implementation. If it is to be of any use whatsoever, the result of Enabled must match that of the underlying logsink implementation. The only way to check that is to...well, check it.

Since there's more than one place that the zerolog.Level is compared to the int level, I added a helper function to convert consistently. I also parameterized it slightly with a constant. Although it doesn't do anything now, that levelDelta value could be configurable in the future.

When logging at a verbosity > 2 no log messages appear, despite configuring zerolog's minimum accepted level.

I can see logging is short circuited here but I'm not sure why given logr's philosophy seems to imply we choose verbosity based on the applications needs.

package main

import (
	"os"

	"github.com/go-logr/zerologr"
	"github.com/rs/zerolog"
)

func main() {
	zLogger := zerolog.New(os.Stderr)
	zLogger = zLogger.Level(-10)
	zerolog.SetGlobalLevel(-10)

	zLogger.WithLevel(-1).Msg("zLogger -1") // trace
	zLogger.WithLevel(-2).Msg("zLogger -2") // less than trace

	logger := zerologr.New(&zLogger)
	logger.V(2).Info("logger v2")
	logger.V(3).Info("logger v3")
}

Go playground.

Expected output:

{"level":"trace","message":"zLogger -1"} {"level":"-2","message":"zLogger -2"} {"level":"trace","v":2,"message":"logger v2"} {"level":"-2","v":3,"message":"logger v3"}

Actual output:

{"level":"trace","message":"zLogger -1"} {"level":"-2","message":"zLogger -2"} {"level":"trace","v":2,"message":"logger v2"}