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

51–60 of 174 posts

Re: Structured logging with slog

#51

Post by ben0x539 »

grose wrote: post #22
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…

It’s not without precedence, for example: https://pkg.go.dev/strings#NewReplacer I don’t mind it. You can use LogAttrs if you want to be explicit. Although I do wonder if there’s anything tricky with the type system that is preventing something like this from being supported: https://go.dev/play/p/_YV7sYdnZ5V

I think go loggers have tried to move away from passing log entries as maps for performance reasons.

Re: Structured logging with slog

#52

Post by bobbyi »

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.

Re: Structured logging with slog

#53

Post by hamandcheese »

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…

The same pattern can be seen in Java using Map.of(...)

Re: Structured logging with slog

#54

Post by [deleted] »

bobbyi wrote: post #52

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.

[deleted]

Re: Structured logging with slog

#55

Post by masklinn »

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

Slog allows doing that by creating Attr structs directly.

Re: Structured logging with slog

#57

Post by euroderf »

LambdaComplex wrote: post #10
earthboundkid wrote: post #5

Earlier quoted context omitted.

An iterator type is being actively worked on now. After that presumably the missing data types in the standard library will be filled out (set, deque, a usable heap, whatever other algorithms). After that, who knows. Maybe native bigints? I don’t really see the enum thing happened. Is lack of enums a real problem? Theoretically, it would be convenient, but I can’t say that I see bugs caused by its lack.

Having "type MyType int" and defining a bunch of constants isn't a great replacement for enums. Yeah, it "works," but it still lets the developer forget to check for a possible variant, or you could have an underlying int that doesn't correspond to a valid variant. The addition of enums would move all these runtime checks to compile time.

As a workaround, a list in a DB combined with a foreign key constraint. Ugly, yes.

Re: Structured logging with slog

#58

Post by politician »

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.

Re: Structured logging with slog

#59

Post by candiddevmike »

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…

Today I'm pulling this out of a context object, can I still do that?

Re: Structured logging with slog

#60

Post by jeffbee »

politician wrote: post #58

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

There are other languages of course where the logging avoids this, even in libraries written by the same company that writes Go. In C++, the Abseil logging library (f.k.a. glog) will not evaluate a condition for a disabled log level.

  LOG(INFO)
This is safe when the log level is set to WARN or higher. For the same reasons, LOG_EVERY_N and LOG_FIRST_N in the same library are pretty cheap.
Post reply on HN