9 ms·

Logging in Go with Slog: A Practitioner's Guide

84 points by ayoisaiah 1y ago

vic1102 1y ago
Great article! super helpful for someone like me who recently started building services in Go. I especially appreciated the section on slog.Attr and the !BADKEY issue, it’s one of those little things that can go unnoticed until logs break in prod. Thanks for putting this together!
codeduck 1y ago
I'm surprised this isn't a standard base pattern in languages, to be honest. Apache's commons-logging library was a standard part of enterprise java placements for many years, and only started to go away when Log4J came along.
- lmz 1y ago
  Log4j is one of the possible backends for commons logging (and was basically the reason for it - choosing between log4j and the built-in java logging). I think you mean SLF4J?
  - codeduck 1y ago
    I may be remembering it wrong, but I think log4j only became a commons logging backend several years after it became mainstream; before that I remember the two being entirely different and no interchangeable. It's a long time ago!
imiric 1y ago
I'm a big fan of slog, and this is a great overview. The fact it is so flexible and composable, while still maintaining a simple API is just great design. I wasn't aware of the performance overhead compared to something like zerolog, but this shouldn't be a concern for most applications.
aleksi 1y ago
My biggest gripe with slog is that there is no clear guidance on supported types of attributes. One could argue that supported types are the ones provided by Attr "construct" functions (like slog.String, slog.Duration, etc), but it is not enough. For example, there is no function for int32 – does it mean it is not supported? Then there is slog.Any and some support in some handlers for error and fmt.Stringer interfaces. The end result is a bit of a mess.
- 0x696C6961 1y ago
  All values are supported.
  - aleksi 1y ago
    Well, is fmt.Stringer supported? The result might surprise you: req := expvar.NewInt("requests") req.Add(1) attr := slog.Any("requests", req) slog.New(slog.NewTextHandler(os.Stderr, nil)).Info("text", attr) slog.New(slog.NewJSONHandler(os.Stderr, nil)).Info("json", attr) This code produces time=2025-09-12T13:15:42.125+02:00 level=INFO msg=text requests=1 {"time":"2025-09-12T13:15:42.125555+02:00","level":"INFO","msg":"json","requests":{}} So the code that uses slog but does not know what handler will be used can't rely on it lazily calling the `String() string` method: half of the standard handlers do that, half don't.
    - 0x696C6961 1y ago
      If you need more control, you can create a wrapper type that implements `slog.LogValuer` type StringerValue struct { fmt.Stringer } func (v StringerValue) LogValue() slog.Value { return slog.StringValue(v.String()) } Usage example: slog.Any("requests", StringerValue{req}) There might be a case for making the expvar types implement `slog.LogValuer` directly.
      - aleksi 1y ago
        So clearly not all values are supported. And I know that I can create a wrapper for unsupported types. My problem is exactly that – I don't know what types are supported. Is error supported, for example? Should I create a wrapper for it? And, as a handler author, should I support it directly or not?
awesome_dude 1y ago
I have a gripe with slog - it uses magic for config What I mean is, if you configure slog in (say) your main package, then, by magic, that config is used by any call to slog within your application. There's no "Oh you are using this instance of slog that has been configured to have this behaviour" - it's "Oh slog got configured so that's the config you have been given" I've never tried to see if I can split configs up, and I don't have a usecase, it just strikes me as magic is all
- roncesvalles 1y ago
  There's a default logger that's used when you call package-level functions (as opposed to methods on an instance of slog.Logger). The default logger is probably what you configured in your main package. In my opinion this is perfectly idiomatic Go. Sometimes the package itself hosts one global instance. If you think that's "magic" then you must think all of Go is magic. It helps to think of a package in Go as equivalent to a single Java class. Splitting up a Go package's code into multiple files is purely cosmetic.
  - sethammons 1y ago
    If you need log output in tests, you should use an instance of a logger. More teams should be validating their logging and should be leveraging structured logging and getting valuable logging insights/events.
- catlifeonmars 1y ago
  I’m not sure I understand what you mean by “magic for config”. You create and configure a logger using slog.New(…). You can use the default logger instead, slog.Default(), which is just a global and has a default config. You can also set the default logger using slog.SetDefault(…). It’s extremely unmagical in my opinion.
- gdbsjjdn 1y ago
  The "magic" is just global state? I agree that I try to avoid global state in my code but it's hardly Spring Boot levels of auto wiring bullshit.
arcaen 1y ago
The thing that gets me about slog is that the output key for the slog JSON handler is msg, but that's not compatible with Googles own GCP Stackdriver logging. Since that key is a constant I now need to use an attribute replacer to change it from msg to message (or whatever it is stackdriver wants). Good work Google.
- ImJasonH 1y ago
  We had the same annoyance, and wrote https://pkg.go.dev/github.com/chainguard-dev/clog/gcp https://pkg.go.dev/github.com/chainguard-dev/clog/gcp to bridge the gap. It's a slog handler that formats everything the way GCP wants, including with trace contexts, etc. We've had this in production for months, and it's been pretty great. You can add this at your main.go import _ "github.com/chainguard-dev/clog/gcp/init" (the rest of the library is about attaching a logger to a context.Context, but you don't need to use that to use the GCP logger)
deleted 1y ago
[deleted]
peterldowns 1y ago
It's fine for application logging but I have two gripes with slog: 1) If you're writing a library that can be used by many different applications and want to emit logs, you'll still need to write a generic log interface with adapters for slog, zap, charmlog, etc. That the golang team refuses to bless a single interface for everyone to settle on both makes sense given their ideological standpoint on shipping interfaces and also causes endless mild annoyance and code duplication. 2) I believe it's still impossible to see the correct callsite in test logs when using slog as the logger. For more information, see https://github.com/neilotoole/slogt?tab=readme-ov-file#deficiency https://github.com/neilotoole/slogt?tab=readme-ov-file#defic.... It's possible I'm out of date here — please correct me if this is wrong, it's actually a much larger annoyance for me and one of the reasons I still use uber/zap or charmbracelet/log. Overall, especially given that it performs worse than uber/zap and everyone has basically standardized on that and it provides essentially the same interface, I recommend using uber/zap instead. EDIT: just to expand further, take a look at the recommended method of wrapping helper methods that call logs. Compare to the `t.Helper()` approach. And some previous discussion. Frustrating! - https://pkg.go.dev/log/slog#example-package-Wrapping https://pkg.go.dev/log/slog#example-package-Wrapping - https://github.com/golang/go/issues/59145#issuecomment-1477040044 https://github.com/golang/go/issues/59145#issuecomment-14770...
- trenchpilgrim 1y ago
  We switched to zerolog a while back and didn't look back.
- aleksi 1y ago
  1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments. 2) It is improved in 1.25. See https://github.com/golang/go/issues/59928 https://github.com/golang/go/issues/59928 and https://pkg.go.dev/testing#T.Output https://pkg.go.dev/testing#T.Output. Now it is possible to update slogt to provide correct callsite – the stack depth should be the same.
  - 1y ago
jjice 1y ago
> The key decision is thus between two patterns: using a global logger or using dependency injection. The former is extremely convenient but adds a hidden dependency that’s hard to test, while the latter is more verbose but makes dependencies explicit, resulting in highly testable and flexible code. Curious how different people handle this. I personally pretty much always pass a logger into function, classes, structs (what have you) so it has the context I need it to. It's a tad more verbose I guess, but it's such a minor lift I've always found it worth it.
- 9rx 1y ago
  > more verbose I'd say necessarily verbose. Without injection, it is not immediately apparent that something is dependent on something else (in this case a logger) with side effects, which ultimately harms understandability. I expect by "more verbose" the author really meant "in need of more typing". I am not sure optimizing for less typing ever a good tradeoff. And if you can find good reason to optimize for less typing, you're not going to be choosing a structured language in the first place, so...
  - jjice 1y ago
    Totally agree. I'll suffer with an additional 20 characters of typing. I hadn't even considered the other ways the article goes into, I'd always used a child logger and passed it down, so I'm a bit reassured that I haven't been a _complete_ fool for all these years.
- cfors 1y ago
  In any API service, it's better to handle via dependency injection IMO. Instantiate all of your metadata once, and then send that logger down, so that anybody who uses that logger is guaranteed to have the right metadata... the time to add logging is not when you are debugging.
- stackedinserter 1y ago
  We pass logs in contexts.
sveinnthorarins 1y ago
Cool article. I really like structured logs and am pleased the Go team saw the benefits of bringing it into the standard library. However, I feel like errors should be able to hold slog attributes. It makes for some very useful and easy error logging, especially when the logging takes place far up the execution chain from where the error happened. This is easily possible with a custom error type and some log functions. I have published on GitHub my small and crude implementation that I use in a few hobby projects, MIT licensed, if anyone is interested. https://github.com/sveinnthorarins/sterlo https://github.com/sveinnthorarins/sterlo
- dlock17 1y ago
  I felt the same way, and made my own package for adding slog attributes to an error for easier logging. It's usually all I need for my own custom errors. https://github.com/Danlock/pkg/blob/main/errors/attr_test.go https://github.com/Danlock/pkg/blob/main/errors/attr_test.go I can understand why it's not in the stdlib though, it seems easy enough to run into key overwriting issues if a dependency returned custom errors with attributes. I appreciate the built in support slog has for slog.GroupValue and the slog.LogValuer interface that enables everyone to build a solution best for their needs.
tptacek 1y ago
To guarantee correctness, you must use the strongly-typed slog.Attr helpers. They make it impossible to create an unbalanced pair by catching errors at compile time I take their point, but given the typical value of most logging lines, this does not seem worth the tax you pay in readability. This is a gripe I have with oTel too --- it really cruds your code up --- but with oTel you're getting long-term value that logging (which is still my go-to o11y) doesn't.
- arccy 1y ago
  OTel have logging too... https://pkg.go.dev/go.opentelemetry.io/otel/log https://pkg.go.dev/go.opentelemetry.io/otel/log and even a slog bridge https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelslog https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otels...

84 points by ayoisaiah 1y ago

Great article! super helpful for someone like me who recently started building services in Go. I especially appreciated the section on slog.Attr and the !BADKEY issue, it’s one of those little things that can go unnoticed until logs break in prod. Thanks for putting this together!

codeduck 1y ago

I'm surprised this isn't a standard base pattern in languages, to be honest. Apache's commons-logging library was a standard part of enterprise java placements for many years, and only started to go away when Log4J came along.

lmz 1y ago
Log4j is one of the possible backends for commons logging (and was basically the reason for it - choosing between log4j and the built-in java logging). I think you mean SLF4J?
- codeduck 1y ago
  I may be remembering it wrong, but I think log4j only became a commons logging backend several years after it became mainstream; before that I remember the two being entirely different and no interchangeable. It's a long time ago!

imiric 1y ago

I'm a big fan of slog, and this is a great overview. The fact it is so flexible and composable, while still maintaining a simple API is just great design. I wasn't aware of the performance overhead compared to something like zerolog, but this shouldn't be a concern for most applications.

aleksi 1y ago

My biggest gripe with slog is that there is no clear guidance on supported types of attributes. One could argue that supported types are the ones provided by Attr "construct" functions (like slog.String, slog.Duration, etc), but it is not enough. For example, there is no function for int32 – does it mean it is not supported? Then there is slog.Any and some support in some handlers for error and fmt.Stringer interfaces. The end result is a bit of a mess.

0x696C6961 1y ago
All values are supported.
- aleksi 1y ago
  Well, is fmt.Stringer supported? The result might surprise you: req := expvar.NewInt("requests") req.Add(1) attr := slog.Any("requests", req) slog.New(slog.NewTextHandler(os.Stderr, nil)).Info("text", attr) slog.New(slog.NewJSONHandler(os.Stderr, nil)).Info("json", attr) This code produces time=2025-09-12T13:15:42.125+02:00 level=INFO msg=text requests=1 {"time":"2025-09-12T13:15:42.125555+02:00","level":"INFO","msg":"json","requests":{}} So the code that uses slog but does not know what handler will be used can't rely on it lazily calling the `String() string` method: half of the standard handlers do that, half don't.
  - 0x696C6961 1y ago
    If you need more control, you can create a wrapper type that implements `slog.LogValuer` type StringerValue struct { fmt.Stringer } func (v StringerValue) LogValue() slog.Value { return slog.StringValue(v.String()) } Usage example: slog.Any("requests", StringerValue{req}) There might be a case for making the expvar types implement `slog.LogValuer` directly.
    - aleksi 1y ago
      So clearly not all values are supported. And I know that I can create a wrapper for unsupported types. My problem is exactly that – I don't know what types are supported. Is error supported, for example? Should I create a wrapper for it? And, as a handler author, should I support it directly or not?

awesome_dude 1y ago

I have a gripe with slog - it uses magic for config What I mean is, if you configure slog in (say) your main package, then, by magic, that config is used by any call to slog within your application. There's no "Oh you are using this instance of slog that has been configured to have this behaviour" - it's "Oh slog got configured so that's the config you have been given" I've never tried to see if I can split configs up, and I don't have a usecase, it just strikes me as magic is all

roncesvalles 1y ago
There's a default logger that's used when you call package-level functions (as opposed to methods on an instance of slog.Logger). The default logger is probably what you configured in your main package. In my opinion this is perfectly idiomatic Go. Sometimes the package itself hosts one global instance. If you think that's "magic" then you must think all of Go is magic. It helps to think of a package in Go as equivalent to a single Java class. Splitting up a Go package's code into multiple files is purely cosmetic.
- sethammons 1y ago
  If you need log output in tests, you should use an instance of a logger. More teams should be validating their logging and should be leveraging structured logging and getting valuable logging insights/events.
catlifeonmars 1y ago
I’m not sure I understand what you mean by “magic for config”. You create and configure a logger using slog.New(…). You can use the default logger instead, slog.Default(), which is just a global and has a default config. You can also set the default logger using slog.SetDefault(…). It’s extremely unmagical in my opinion.
gdbsjjdn 1y ago
The "magic" is just global state? I agree that I try to avoid global state in my code but it's hardly Spring Boot levels of auto wiring bullshit.

arcaen 1y ago

The thing that gets me about slog is that the output key for the slog JSON handler is msg, but that's not compatible with Googles own GCP Stackdriver logging. Since that key is a constant I now need to use an attribute replacer to change it from msg to message (or whatever it is stackdriver wants). Good work Google.

ImJasonH 1y ago
We had the same annoyance, and wrote https://pkg.go.dev/github.com/chainguard-dev/clog/gcp https://pkg.go.dev/github.com/chainguard-dev/clog/gcp to bridge the gap. It's a slog handler that formats everything the way GCP wants, including with trace contexts, etc. We've had this in production for months, and it's been pretty great. You can add this at your main.go import _ "github.com/chainguard-dev/clog/gcp/init" (the rest of the library is about attaching a logger to a context.Context, but you don't need to use that to use the GCP logger)

deleted 1y ago

[deleted]

peterldowns 1y ago

It's fine for application logging but I have two gripes with slog: 1) If you're writing a library that can be used by many different applications and want to emit logs, you'll still need to write a generic log interface with adapters for slog, zap, charmlog, etc. That the golang team refuses to bless a single interface for everyone to settle on both makes sense given their ideological standpoint on shipping interfaces and also causes endless mild annoyance and code duplication. 2) I believe it's still impossible to see the correct callsite in test logs when using slog as the logger. For more information, see https://github.com/neilotoole/slogt?tab=readme-ov-file#deficiency https://github.com/neilotoole/slogt?tab=readme-ov-file#defic.... It's possible I'm out of date here — please correct me if this is wrong, it's actually a much larger annoyance for me and one of the reasons I still use uber/zap or charmbracelet/log. Overall, especially given that it performs worse than uber/zap and everyone has basically standardized on that and it provides essentially the same interface, I recommend using uber/zap instead. EDIT: just to expand further, take a look at the recommended method of wrapping helper methods that call logs. Compare to the `t.Helper()` approach. And some previous discussion. Frustrating! - https://pkg.go.dev/log/slog#example-package-Wrapping https://pkg.go.dev/log/slog#example-package-Wrapping - https://github.com/golang/go/issues/59145#issuecomment-1477040044 https://github.com/golang/go/issues/59145#issuecomment-14770...

trenchpilgrim 1y ago
We switched to zerolog a while back and didn't look back.
aleksi 1y ago
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments. 2) It is improved in 1.25. See https://github.com/golang/go/issues/59928 https://github.com/golang/go/issues/59928 and https://pkg.go.dev/testing#T.Output https://pkg.go.dev/testing#T.Output. Now it is possible to update slogt to provide correct callsite – the stack depth should be the same.
- 1y ago

jjice 1y ago

> The key decision is thus between two patterns: using a global logger or using dependency injection. The former is extremely convenient but adds a hidden dependency that’s hard to test, while the latter is more verbose but makes dependencies explicit, resulting in highly testable and flexible code. Curious how different people handle this. I personally pretty much always pass a logger into function, classes, structs (what have you) so it has the context I need it to. It's a tad more verbose I guess, but it's such a minor lift I've always found it worth it.

9rx 1y ago
> more verbose I'd say necessarily verbose. Without injection, it is not immediately apparent that something is dependent on something else (in this case a logger) with side effects, which ultimately harms understandability. I expect by "more verbose" the author really meant "in need of more typing". I am not sure optimizing for less typing ever a good tradeoff. And if you can find good reason to optimize for less typing, you're not going to be choosing a structured language in the first place, so...
- jjice 1y ago
  Totally agree. I'll suffer with an additional 20 characters of typing. I hadn't even considered the other ways the article goes into, I'd always used a child logger and passed it down, so I'm a bit reassured that I haven't been a _complete_ fool for all these years.
cfors 1y ago
In any API service, it's better to handle via dependency injection IMO. Instantiate all of your metadata once, and then send that logger down, so that anybody who uses that logger is guaranteed to have the right metadata... the time to add logging is not when you are debugging.
stackedinserter 1y ago
We pass logs in contexts.

sveinnthorarins 1y ago

Cool article. I really like structured logs and am pleased the Go team saw the benefits of bringing it into the standard library. However, I feel like errors should be able to hold slog attributes. It makes for some very useful and easy error logging, especially when the logging takes place far up the execution chain from where the error happened. This is easily possible with a custom error type and some log functions. I have published on GitHub my small and crude implementation that I use in a few hobby projects, MIT licensed, if anyone is interested. https://github.com/sveinnthorarins/sterlo https://github.com/sveinnthorarins/sterlo

dlock17 1y ago
I felt the same way, and made my own package for adding slog attributes to an error for easier logging. It's usually all I need for my own custom errors. https://github.com/Danlock/pkg/blob/main/errors/attr_test.go https://github.com/Danlock/pkg/blob/main/errors/attr_test.go I can understand why it's not in the stdlib though, it seems easy enough to run into key overwriting issues if a dependency returned custom errors with attributes. I appreciate the built in support slog has for slog.GroupValue and the slog.LogValuer interface that enables everyone to build a solution best for their needs.

tptacek 1y ago

To guarantee correctness, you must use the strongly-typed slog.Attr helpers. They make it impossible to create an unbalanced pair by catching errors at compile time I take their point, but given the typical value of most logging lines, this does not seem worth the tax you pay in readability. This is a gripe I have with oTel too --- it really cruds your code up --- but with oTel you're getting long-term value that logging (which is still my go-to o11y) doesn't.

arccy 1y ago
OTel have logging too... https://pkg.go.dev/go.opentelemetry.io/otel/log https://pkg.go.dev/go.opentelemetry.io/otel/log and even a slog bridge https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelslog https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otels...