is it possible to have a fixed key, such as 'msg'

[chenzhiwei]

A log message usually have a description, which is not key=value format, such as:

successfully created an object, name=obj1

Translate to go-kit log format:

msg="successfully created an object" name=obj1

The key "msg" can be fixed.

Something like Log(msg string, keysAndValues ...interface{})

In prometheus code: https://github.com/prometheus/prometheus/blob/main/tsdb/head.go#L466-L491

level.Info(h.logger).Log("msg", "Replaying on-disk memory mappable chunks if any")
level.Info(h.logger).Log("msg", "Chunk snapshot is enabled, replaying from the snapshot")
level.Info(h.logger).Log("msg", "Chunk snapshot loading time", "duration", time.Since(start).String())
level.Error(h.logger).Log("msg", "Failed to load chunk snapshot", "err", err)

The key "msg" is redundant here.

[ChrisHines]

It is not practical to avoid the key/value structure of the Logger interface. But it would be possible to write a Logger implementation that interpreted a specific key as special and elide it from the encoded output. None of the built in loggers do that, but it is possible to write your own along those lines. I've done that at $work in the past.

You can also expose an alternate client facing API that accepts some hard coded fields and puts them in the keyvals []interface{} data with a well known key, but that starts to erode the ability to pass around a consistent interface such as Logger as defined by this package.

So there are choices, but they are out of scope for this package.

[chenzhiwei]

I can write a prepend function to implement this, but I am not sure how much performance it will cost.

Do you have any other ideas?

func prepend(msg string, keyvals ...interface{}) []interface{} {
        s := make([]interface{}, len(keyvals)+2)
        s[0] = "msg"
        s[1] = msg
        for i, v := range keyvals {
                s[i+2] = v
        }

        return s
}

[ChrisHines]

Yes, something like that could work. You could use the builtin copy function instead of the for loop, but the overall performance will be similar. I don't know your situation enough to say if that is acceptable. You'll have to benchmark it and see. It is probably less performant than simply including a "msg" key when calling the Log method because in that case the Go compiler can make the keyvals slice with the right size at the call site without another helper function that has to reallocate and copy it to add the "msg" key.

If you decide on a helper function or wrapper API to add the "msg" field then you could append to the end of the keyvals slice instead to minimize the copying at that point and special case it in the log.Logger that serializes the record to your final format.

The best choice may also depend on how you process your log data. If the logs end up in something like ELK that really wants everything in key/value pairs then it may take extra work to add the "msg" key back during ingest and the effort to get rid of the "msg" key may be counterproductive.

Finally, if you have flexibility in what packages you use, go-kit/log's API choices are causing too much friction, and performance is a real concern then maybe another logging package would be a better fit for your project.