Structured logging with slog

Post by randomdata » Wed, Aug 23, 2023, 6:39 AM UTC

physicles wrote: post #107

randomdata wrote: post #102

Earlier quoted context omitted.

> providing a core library way of wrapping with stacktraces would be a very useful next step What eventually became the standard library error wrapping proposal evolved from the work done on the Upspin project. It did include stacktraces, and believed like you that it would be useful to have them. But analysis of the data showed that nobody ever really used them in practice and, for that reason, was removed from the…

In the last few months I've realized what I desperately need: a way to wrap an error with a call stack at the point where it enters our code base. This would probably save me on average 20-30 minutes a week. I see this all the time: main.go:141 error: could not transmogrify the thing: a144cd21c48 And then I literally grep the code base to find the error message. That works ~50% of the time, but the other 50%, I see t…

  func bar() error {
    err := baz.Transmogrify()
    return fmt.Errorf("transmogrify: %w", err)
  }

  func foo() error {
    err := bar()
    return fmt.Errorf("bar: %w", err)
  }

  func main() {
    err := foo()
    fmt.Printf("foo: %v", err)
    // foo: bar: transmogrify: not found
  }

Post by dgsb » Wed, Aug 23, 2023, 6:46 AM UTC

morelisp wrote: post #65

radlad wrote: post #63

Earlier quoted context omitted.

It sure has maps though... logrus famously uses `logrus.Fields{"key": "value"}`

And logrus is one of the slowest loggers by far, in part because of its heavy map usage.

Post by masklinn » Wed, Aug 23, 2023, 6:52 AM UTC

jimmcslim wrote: post #89

jasonhansel wrote: post #88

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.

I feel what is missing here is message templates [1] - the logging API should permit the key-value pairs to be substituted into a template which results in a human-readable message, while preserving the KV data separately. Take a hash of the template and add it as a KV pair so that messages of the same type can be easily filtered. [1] https://messagetemplates.org

Post by klabb3 » Wed, Aug 23, 2023, 7:36 AM UTC

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…

Post by masklinn » Wed, Aug 23, 2023, 9:17 AM UTC

masklinn wrote: post #117

richardwhiuk wrote: post #62

Earlier quoted context omitted.

Rust's slog ( https://docs.rs/slog/ ) does: use slog::info; ... info!("hello, world"; "user" => std::env::var("USER"));

It can do that because Rust’s macros can have their own mini language at the top level, and can transform that into whatever data structure they want under the cover. For better or for worse, Go doesn’t have that.

    my %hash = (
        Foo => “bar”,
        Baz => “qux”,
    );

    my %hash = (
        Foo, “bar”,
        Baz, “qux”,
    );

    my %h = (a => b => c => d);

    my %h = (a, b => c, d);