from Hacker News

Structured logging with slog

by spacey on 8/22/23, 4:02 PM with 168 comments

  • by mrweasel on 8/22/23, 6:04 PM

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

  • by corytheboyd on 8/22/23, 6:13 PM

    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 sound useful to other folks? Does it already exist and I just can’t find it?

  • by ar_lan on 8/22/23, 5:18 PM

    I'm so happy this is a stdlib feature. This is good enough for me to not need to bring in external loggers (e.g. zerolog) which is nice, and I strongly think that structured logging should be the default logging format.

    Logs are data.

  • by dgb23 on 8/22/23, 5:25 PM

    The rationale:

    > With many structured logging packages to choose from, large programs will often end up including more than one through their dependencies. The main program might have to configure each of these logging packages so that the log output is consistent: it all goes to the same place, in the same format. By including structured logging in the standard library, we can provide a common framework that all the other structured logging packages can share.

    This is IMO the right way of doing it. Provide an interface with simple defaults, usable out of the box. Those who need more can use a library that builds towards the interface.

    So when evaluating any library, you can ask "How well does this integrate with interfaces in the standard library?". Discovering that some functionality is just a "Fooer" that pieces well together with existing stuff is calming. Not only do you already know how to "Foo", you also get a hidden stability benefit: There's an implied API surface contract here.

    This is in stark contrast to the "builds on top of" approach, where you end up with competing, idiosyncratic interfaces. This is often necessary, but there is always an implied risk in terms of maintenance and compatibility.

  • by baz00 on 8/22/23, 5:59 PM

    Now all we need is the 1,000,000 other components in the multiple ecosystems to log in the same format and I won't have a perpetual headache.

    Good job Go though for being opinionated but rational.

  • by geodel on 8/22/23, 5:25 PM

    With this another most requested feature is covered by Go. This leaves error handling, enum type which are often asked by users but are not actively being worked on for now.

  • by nwsm on 8/22/23, 7:08 PM

    It's nice to have this in the standard library, but it doesn't solve any existing pain points around structured log metadata and contexts. We use zap [0] and store a zap logger on the request context which allows different parts of the request pipeline to log with things like tenantId, traceId, and correlationId automatically appended. But getting a logger off the context is annoying, leads to inconsistent logging practices, and creates a logger dependency throughout most of our Go code.

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

  • by jasonhansel on 8/23/23, 12:44 AM

    I must admit: I'm not a huge fan of structured logging, beyond simple use cases like tagging messages by the thread that produced them. If you want something machine-readable, use a dedicated metrics system, analytics database, or document store. If you want something human-readable, structured logging will only make things worse.

  • by zknill on 8/22/23, 7:02 PM

    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 do. It's not obvious how to change the built in handler.

    I wrote slogmw[1] to solve this problem. It's a set of middleware and examples that make it easy to make small changes to the built in handlers without having to write a whole new handler from scratch.

    [1] https://github.com/zknill/slogmw

  • by politician on 8/22/23, 9:05 PM

    I wish there was a better approach for the problem of avoiding function calls when the log level at runtime is higher than the call site.

    So,

        slog.Info("failed to frob", "thing", GetThing(1))
    Still calls GetThing(1) when the log level is greater than Info. The only solution right now for this is to test the log level before making the logging call. It would be amazing if language designers could make the arguments late bound instead or used aspect-oriented programming approaches to protect each logging call site.

  • by Seb-C on 8/23/23, 5:14 AM

    I guess it's nice to have a standard, but I wish the Golang developers stopped introducing stuff like "args ...any" all over the place in the standard library.

    It's not the level of type-safety that I expect from a strongly typed language.

  • by mihaitodor on 8/22/23, 7:24 PM

  • by kusha on 8/22/23, 7:05 PM

    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

  • by tastysandwich on 8/22/23, 9:40 PM

    I'm really glad they've introduced this, I just wish it also had the traditional formatting methods, eg Infof, Debugf, Errorf, etc, for backwards compatibility.

    I've got a few packages that accept a basic logger interface, eg:

      type debugLogger interface {
      Debugf(format string, args ...any)
  }

  type MyThing struct {
    logger debugLogger
  }

  func New(logger debugLogger) *MyThing {
    return &MyThing{logger}
  }
    I'd love to switch to slog but I'll have to v2 these packages now.

  • by __loam on 8/22/23, 7:13 PM

    Slog is an amazing name

  • by insanitybit on 8/22/23, 6:05 PM

    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.

  • by candiddevmike on 8/22/23, 7:04 PM

    Looking for advice: logging for servers/services tends to be different than logging for CLI-based applications. How do folks differentiate them or use slog for them in a generic way? Or does it make sense to have separate logging packages for CLI vs services? CLI tends to be more verbose and procedural vs servers/service based logging which is more errors only unless debug.

  • by Femolo on 8/22/23, 7:41 PM

    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

  • by mi_lk on 8/22/23, 7:42 PM

    Q: what do people use for structured logging in Java?

  • by bobbyi on 8/22/23, 8:18 PM

    Walking past an eatery with outdoor seating, I overheard one diner say the phrase "process raw logs" and I thought, "wow, I guess that is one of those tricky problems that basically everyone ends up dealing with".

    And then I heard "... with a chainsaw. It's a chainsaw mill" and realized I may have misunderstood the context.

  • by User23 on 8/23/23, 1:13 AM

    Just log to sqlite. It’s literally better than all the alternatives, but for some reason nobody does.