[insanitybit]

Structured logging is a very sane default. Even if you end up with `{"msg": "blah blah blah"}` at least you have room to grow in the future.

[duskwuff]

And if your current logging is along the lines of

    log.Printf("failed to frob %s: %s", thing, error)

then moving from that to:

    slog.Error("failed to frob", "thing", thing, "error", error)

isn't terribly difficult, and will make log analysis dramatically easier.

[lsaferite]

Given your example of

    log.Printf("failed to frob %s: %s", thing, error)

Wouldn't you just want to use

    slog.Error("failed to frob", thing, error)

That keeps the _value_ of `thing` as the key and the _value_ of `error` as the value. That would keep more in line with your first example.

[duskwuff]

Probably not. ELK-style log analysis tools benefit from having messages follow a consistent schema. Using a variable as a key makes indexing much more difficult, and can make it impossible to detect patterns where (for example) a single error appears sporadically across many different values of "thing".

If "thing" were a variable with a small cardinality (like a class name or an enumeration), that might change matters. But I'd still be reluctant to do that; having the two values available in separate fields, rather than as a single key/value pair, is a lot more flexible.

[lsaferite]

Oh, sorry if I was unclear, I wouldn't do that. I was just suggesting that it was closer to the original log message design. :) I'm a massive structured logging fan and have used it for quite a long time. In go I've used zerolog mostly, but I bring structured logs to whatever language I'm working with.