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

51–59 of 59 posts

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

#51

Post by trenchpilgrim »

arccy wrote: post #42
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...

I used slog.Logger for an OSS project and I will not do it again. The interface is terrible, and far more verbose and less expressive than something like Zap or zerolog. e.g. there's not really anything as good as zerolog's log.Dict() for dealing with complex structures.

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

#52

Post by aleksi »

arccy wrote: post #45
aleksi wrote: post #21

Earlier quoted context omitted.

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

I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.

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

#53

Post by aleksi »

9rx wrote: post #33
aleksi wrote: post #22

Earlier quoted context omitted.

My problem with that is that it makes it impossible to use slog logger safely without knowing what handler is being used. Which kind of defeats the purpose of defining the common structured logging interface.

> 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.

As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.

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

#54

Post by 9rx »

aleksi wrote: post #53
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.

As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.

Hence the design. The producer coming up with a made up language that makes sense to the producer, but probably doesn't make sense to the consumer — especially when you have many different consumers with very different needs — is far more problematic than the producer providing an abstract representation and allowing the consumer to dig into the specific details it wants.

As with everything in life, there are tradeoffs to that approach, of course, and it might be hard to grasp if you come from languages which different idioms that prioritize producer over consumer, but if you look closely everything about Go is designed to prioritize the needs of the consumer over the needs of the producer. That does seem to confuse a lot of people, interestingly. I expect because it isn't idiomatic to prioritize the consumer in a lot of other languages and people get caught up in trying to write code in those other languages using Go syntax instead of actually learning Go.

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

#55

Post by tomhow »

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

Earlier quoted context omitted.

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]

We've banned this account for continually posting unsubtantive comments and ignoring our previous request to observe the guidelines.

If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.

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

#56

Post by arccy »

aleksi wrote: post #52
arccy wrote: post #45

Earlier quoted context omitted.

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

I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.

any handler is too broad, maybe my custom handler only logs strings and ignores ints.

for a reasonable substitute subset, use the core language types, and implement LogValuer for anything complex.

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

#57

Post by vic1102 »

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!

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

#58

Post by skeezyboy »

tomhow wrote: post #55
skeezyboy wrote: post #50

Earlier quoted context omitted.

[flagged]

We've banned this account for continually posting unsubtantive comments and ignoring our previous request to observe the guidelines. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html .

[dead]

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

#59

Post by dlock17 »

sveinnthorarins wrote: post #38

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

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

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.

Post reply on HN