Move to log/slog logging

[rdimitrov]

This issue is about moving away from 3rd party dependency for logging and converging on using log/slog which is part of the standard library.

[ChrisJBurns]

Happy to pick this up, do we know what 3rd party dependency(ies) we use at the moment?

[evankanderson]

We currently use Zerolog, but I think none of us love it. Prior to that, I'd used Zap (which I like somewhat better). But we're looking for the following features:

1. Provide structured (JSON-LD) output. That works with our existing logs handling infrastructure.
2. Hopefully track the OpenTelemetry logging standard.
3. Support storing and retrieving a logger from the context. e.g. we use slog.Ctx(ctx).Info(...) or whatever to pick up fields like the project automatically.

[ChrisJBurns]

Thanks @evankanderson finally got some time to look at this, you mentioned Zap, but I'm assuming that it doesn't cover off the three features listed? If it does, would that be a valid alternative? As I tend to go with what people have used before and are familiar with providing there aren't any limitations to it that may be of concern in the future.

[evankanderson]

Zap can support at least the first two points, I'm not sure about tracking slog.

[evankanderson]

Zap can support at least the first two points, I'm not sure about tracking slog.

Actually, zap supports the to/from context as well.

[evankanderson]

It looks like slog supports JSONHandler for structured output. Additionally, it looks like our usage with Contexts could be done via InfoContext etc along with a custom handler that extracts some fields from the context and then delegates to JSONHandler.

[ChrisJBurns]

Doing some reading on this it seems like there we could do either:

1. Use slog for frontend and zap for backend by implementing the Handler interface
2. Use slog for frontend and backend, but would have to write the backend from scratch

I'd probably lean towards option 1. Although there is more third-party dependencies, it may be worth it given Zap is quite mature and already tracks the OTEL format as you've described. The 2nd option is great if you want to keep dependencies at a minimum, but would likely have to write more code.

I should add, am not a Go expert (yet! 😄 ) when it comes to all kinds of logging libraries, but I think the two options above represent some of the better options.

[evankanderson]

Hey @ChrisJBurns -- we're fine with either option; are you still interested in doing this?