Graylog uses the level key for its rotation

[l-vitaly]

Can you add changes to the key name?

For example: level.Key = "@level"

[ChrisHines]

Thanks for filing an issue, but I don't understand what you're asking. Are you reporting a bug, asking for a feature, or asking for advice about how to use the existing packages to solve a specific problem. Please clarify.

[l-vitaly]

Graylog uses the "level" key for its rotation, there is a conflict, I suggest making it possible to change the key name in gokit

[ChrisHines]

The same feature was requested in #592 and #503. We haven't implemented this as a feature in the log/level package for the reasons explained in the second link. In that discussion I also provided an example workaround you can implement in your own code to get the desired behavior.

Now that we've had three requests for the same feature the argument add it seems stronger. What do you think @peterbourgon?

[peterbourgon]

I'm keen to see this possible. Unfortunately, I'm not sure how to do it without futzing with package-global state. edit: Maybe we could add the SetLevelKey decorator (or something like it) proposed in #503 to the package.

[awilliams]

I'd like to propose an alternative solution. It involves modifying the level package in a way similar to the following:

var (
	keyStr = ""
	key interface{}
)

func init() {
	if envKey := os.Getenv("KIT_LEVELKEY"); envKey != "" {
		keyStr = envKey
	}
	if keyStr == "" {
		keyStr = "level"
	}
	key = keyStr
}

With this modification, users would have the option to change the level key in two ways:

• At build time using build flags, eg:

  $ go build \
  	-ldflags "-X 'github.com/go-kit/kit/log/level.keyStr=@level'"

• At runtime via an environment variable, eg:

  $ KIT_LEVELKEY=@level ./my-app

Without modification, the default level key would be used.

---

Note: When testing this, I ran into an issue with the following structure:

var keyStr = "level"
var key interface{} = keyStr

It seemed like the compiler would make an optimization and remove keyStr, making it impossible to target it via build flags.

[peterbourgon]

Package global configuration via env var in init is a non-starter, sorry.

[ChrisHines]

@peterbourgon What do you think of the -ldflags idea, though, if the env var part was removed?

[peterbourgon]

Ah, interesting, I must have missed that bit. It's clever! I like it. Is it good enough for the users who need it?