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

Structured logging with slog

go.dev

Post reply on HN
Print view View original

41–50 of 174 posts

Re: Structured logging with slog

#41

Post by numbsafari »

zknill wrote: post #28

The new structured logging library is a great addition, its nice to have structured logging in the standard lib. It's easy to get started with log/slog and one of the built in handlers, but as soon as you want to change something the library design pushes you towards implementing an entire handler. For example, if I want the built in JSON format, but with a different formatting of the Time field, that's not easy to d…

Nice middleware package.

I have to admit, the `log.InfoContext(ctx,...` style of redundancy that permeates the standard lib at this point is really gross, especially given that the most common use case for go is going to have contexts everywhere.

Re: Structured logging with slog

#43

Post by jupp0r »

mrweasel wrote: post #8

Admittedly I'm not a huge fan of having: slog.Info("hello, world", "user", os.Getenv("USER")) It's a little magical that "user" is a key. So what if you have multiple key-value pairs? Arguably it most likely going to be obvious which is the keys, but having every other value be a key and the rest values seems a little clumsy. I really like Pythons approach where you can have user="value" it makes things a bit more cl…

I think Uber chose a better approach for their Go logging library called Zap [1]

    logger.Info("failed to fetch URL",
      // Structured context as strongly typed Field values.
      zap.String("url", url),
      zap.Int("attempt", 3),
      zap.Duration("backoff", time.Second),
    )
They also have zap.Error(err) which generates the "error" key as a convention.

[1] https://github.com/uber-go/zap

Re: Structured logging with slog

#44

Post by Femolo »

Log everything as Json!

We need to start making Json viewer were we look into log files without tooling the default.

It's so much easier to use Json automatically and ship them to systems out of the box.

Linux logging should do that too. Not just container in k8s

Re: Structured logging with slog

#46

Post by tony_cannistra »

kusha wrote: post #31

Oof. We just converted all of our logging to zap[0] to get structured JSON logging for downstream parsing. Wonder how the perf stacks up. [0]: https://github.com/uber-go/zap

It looks like they've included slog in their performance benchmarks, which show zap as considerably more performant (though I don't really understand the benchmark).

Re: Structured logging with slog

#47

Post by duskwuff »

insanitybit wrote: post #9

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.

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.

Re: Structured logging with slog

#48

Post by bpicolo »

jupp0r wrote: post #43
mrweasel wrote: post #8

Admittedly I'm not a huge fan of having: slog.Info("hello, world", "user", os.Getenv("USER")) It's a little magical that "user" is a key. So what if you have multiple key-value pairs? Arguably it most likely going to be obvious which is the keys, but having every other value be a key and the rest values seems a little clumsy. I really like Pythons approach where you can have user="value" it makes things a bit more cl…

I think Uber chose a better approach for their Go logging library called Zap [1] logger.Info("failed to fetch URL", // Structured context as strongly typed Field values. zap.String("url", url), zap.Int("attempt", 3), zap.Duration("backoff", time.Second), ) They also have zap.Error(err) which generates the "error" key as a convention. [1] https://github.com/uber-go/zap

As mentioned in the article, Zap's SugaredLogger has roughly the same thing https://pkg.go.dev/go.uber.org/zap

    sugar.Infow("failed to fetch URL",
      "url", "http://example.com",
      "attempt", 3,
      "backoff", time.Second,
    )
Really slog presents mostly the same two APIs as Zap, with a single entrypoint.

Re: Structured logging with slog

#49

Post by corytheboyd »

merightnow wrote: post #12
corytheboyd wrote: post #11

Structured logging is such an easy to gain, massive improvement to observability. Assuming you can pay for the log processor to make sense of it all :) I’ve been working on a side project to bring something like the DataDog log explorer to the local development environment. The prototype I made has already been extremely helpful in debugging issues in a very complex async ball of Rails code. Does something like that…

Have you checked lnav?

I’ve seen it mentioned before, but I haven’t given it a demo yet. To be honest I wasn’t sure if TUI was the right UI for something like this, as it can’t pull off all of the things a GUI can. It’s not that I have a TUI allergy either (I can’t live without lazygit).

Re: Structured logging with slog

#50

Post by mihaitodor »

icholy wrote: post #42
mihaitodor wrote: post #40

Benthos just adopted it: https://github.com/benthosdev/benthos/commit/ee0000450413ad3...

I might have misunderstood, but shouldn't the adapter be operating on a `slog.Handler`?

slog’s top-level functions use the default logger, so using that made the most sense for now. There are some custom labels being injected (see the `WithFields()` method) but that's about it.
Post reply on HN