Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Logging in Go with Slog: A Practitioner's Guide

dash0.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Logging in Go with Slog: A Practitioner's Guide

#41

Post by oefrha »

peterldowns wrote: post #36
9rx wrote: post #35

Earlier quoted context omitted.

> What I mean is that there should be a single interface for Logging that is implemented by slog.Logger, uber/zap.Logger, etc. There is: https://pkg.go.dev/golang.org/x/exp/slog#Handler If, say, zap was conformant, you'd slog.New(zap.NewHandler()) or whatever and away you go. It seems the only problem here is that the logging packages you want to use are not following the blessed, idiomatic path. > For an example fro…

I know it didn't escape anyone; I'm explaining the downside to the choices made by the stdlib authors, from my perspective. When performance is a concern, people pick uber/zap.Logger or zerolog. When performance isn't a huge concern, slog is overly complicated and annoying. I believe you understand my complaint.

Your library should just take a *slog.Logger, and using *slog.Logger is an orthogonal choice to zap/zerolog/whatever. Those compete with slog.TextHandler or slog.JSONHandler, and sure, if you’re performance sensitive don’t pick them. In my newer projects I use zap under the hood with an application-facing *slog.Logger through go.uber.org/zap/exp/zapslog just fine (actually further locked down with my own interface so that coworkers can’t go crazy, but that’s beside the point). Your bespoke interface, or that standard interface you want isn’t going to be any more performant than going through slog.Handler interface anyway.

Re: Logging in Go with Slog: A Practitioner's Guide

#42

Post by arccy »

peterldowns wrote: post #23

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 interface…

The blessed interface for libraries is to accept a slog.Logger.

The blessed interface for logging backends is slog.Handler.

Applications can then wire that up with a handler they like, for example

zap: https://pkg.go.dev/go.uber.org/zap/exp/zapslog#Handler

charm https://github.com/charmbracelet/log?tab=readme-ov-file#slog...

Re: Logging in Go with Slog: A Practitioner's Guide

#43

Post by tptacek »

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.

Re: Logging in Go with Slog: A Practitioner's Guide

#44

Post by phyrog »

peterldowns wrote: post #34
aleksi wrote: post #24

Earlier quoted context omitted.

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 and https://pkg.go.dev/testing#T.Output . Now it is possible to update slogt to provide correct callsite – the st…

1) Right, but this is complicated and annoying. Imagine a world where you could just pass your existing logger in, because my library references an interface like `stdlib/logging.GenericLoggerInterface` and slog, zap, zerolog, etc. all implement that! Would be nice! 2) TIL about `T.Output`, thank you, that's great to know about. Still annoying and would be nice if the slog package showed an example of logging from te…

But that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.

Re: Logging in Go with Slog: A Practitioner's Guide

#45

Post by arccy »

aleksi wrote: post #21
0x696C6961 wrote: post #17

Earlier quoted context omitted.

Not sure what your definition of "supported" is, but I'm afraid you're going to have to bite the bullet and ... gasp ... read the documentation https://pkg.go.dev/log/slog

Not sure I understand your sarcasm. I read the documentation, source code, handler writing guide, and issues in the Go repository multiple times over two years, and I use slog extensively. Go is my primary language since r60. I think I know how to read Go docs. Now, please point me to the place in the documentation that says if I can or can't use a value implementing the error interface as an attribute value, and wil…

https://pkg.go.dev/log/slog#JSONHandler.Handle

> Values are formatted as with an encoding/json.Encoder with SetEscapeHTML(false), with two exceptions.

> First, an Attr whose Value is of type error is formatted as a string, by calling its Error method. Only errors in Attrs receive this special treatment, not errors embedded in structs, slices, maps or other data structures that are processed by the encoding/json package.

So the json handler more or less works as if you called json.Marshal, which sounds pretty reasonable.

Re: Logging in Go with Slog: A Practitioner's Guide

#46

Post by arccy »

tptacek wrote: post #43

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 log…

OTel have logging too... https://pkg.go.dev/go.opentelemetry.io/otel/log

and even a slog bridge https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otels...

Re: Logging in Go with Slog: A Practitioner's Guide

#47

Post by 9rx »

skeezyboy wrote: post #37
9rx wrote: post #33

Earlier quoted context omitted.

> Which kind of defeats the purpose of defining the common structured logging interface. Does it, though? Why would the log producer care about how the log entires are formatted? Only the log consumer cares about that.

[flagged]

A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.

Re: Logging in Go with Slog: A Practitioner's Guide

#48

Post by skeezyboy »

9rx wrote: post #47
skeezyboy wrote: post #37

Earlier quoted context omitted.

[flagged]

A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.

[flagged]

Re: Logging in Go with Slog: A Practitioner's Guide

#49

Post by 9rx »

skeezyboy wrote: post #48
9rx wrote: post #47

Earlier quoted context omitted.

A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.

[flagged]

Certainly logs lose their value if they are wrong. And either approach is ripe for getting things wrong. But the idea is that the consumer is more in tune with getting what the consumer needs right. The producer's assumptions are most likely to be wrong, fundamentally, not having the full picture of what is needed. What is the counter suggestion?

Re: Logging in Go with Slog: A Practitioner's Guide

#50

Post by skeezyboy »

9rx wrote: post #49
skeezyboy wrote: post #48

Earlier quoted context omitted.

[flagged]

Certainly logs lose their value if they are wrong. And either approach is ripe for getting things wrong. But the idea is that the consumer is more in tune with getting what the consumer needs right. The producer's assumptions are most likely to be wrong, fundamentally, not having the full picture of what is needed. What is the counter suggestion?

[flagged]
Post reply on HN