Closes #25

I've tried a number of different approaches, but I think every single approach is just too much work and too much indirection for them to exist in a separate module.

It does not cut down on the amount of code, it makes the initialization of services more complex, the developers need to keep in mind and remember the environment variable names and how they work, how the kit is configured. All in all I don't think it's of sufficient benefit that it should be abstracted away.

Problem definition

Per the conversation on threads, the wish is to have a unified way of setting the logger to a specific level based on an environment variable.

As context:

• each service already has their own configuration structs and configuration resolution that they need for startup
• each service already has the loggers being instantiated in the services themselves mostly because the loggers need to have metadata, or key-value pairs attached to them

An example to the latter as a minimum setup

func main() {
    zerolog.TimeFieldFormat = zerolog.TimeFormatUnix
    l := zerolog.New(os.Stderr).With().
        Timestamp().
        Str("service", "builder").
        Str("version", "v1.1.1").
        Str("sha", "acab1312").
        Logger()

    // rest of the service
}

This code only runs once every time a service starts up. Of this the parts that aren't service specific are

• it needs a timestamp
• it should be of unix format
• it should go to os.Stderr (maybe?)

Possible solutions?

As an experiment I extracted all that into a Baseline function. To use that here's what the service needs to do:

import "github.com/suborbital/go-kit/loglevel"

func main() {
    l := loglevel.Baseline("BUILDER_")

    l = l.With().
        Str("service", "builder").
        Str("version", "v1.1.1").
        Str("sha", "acab1312").
        Logger()

    // rest of the service
}

It does not cut down on lines of code, it hides implementation which makes figuring out what's happening harder than necessary to do. On the other hand it adds another dependency that we need, and it does not remove dependencies that we already have.

You also don't really know what comes out of Baseline, and it takes a lot more hops to figure out what the log level depends on, what its current value is. It's opaque.

The PR also includes a bunch of other experiments, but in all cases the settings achieved in zerolog can be done in fewer lines with greater accuracy and precision directly than hiding it behind a kit function / module.

Personally I advocate for dealing with setting log levels in the services directly by using their already existing config structs and dedicating 3 lines in the setup code in all 4 places this is currently needed.

Marked the PR as draft because I do not have the intention of merging it in with current context. I am open to be persuaded if the problem definition warrants abstraction. I don't think the current one does.