Logging is one of those things that every Go developer does from day one and can present challenges when it gets to production.

Sometimes logs are too many, sometimes they are expensive to search and/or store but often happen to give unclear information when trying to search events that matter in a bug investigation.

In this talk, we'll make the case for observable Go services from the ground up by watching how combining the logging structure provided by `slog` and connecting it to the open structure of OpenTelemetry.

We'll start with a brief introduction of both `slog` package and OpenTelemetry framework and we'll journey along the interaction between the two, observing the synergies they show and the tools they provide to make an actual Go application effectively observable.

By the end of the talk you'll get a clear idea of observability in Go that goes beyond the simple "how do you log?" question and will be able to see how do you get a clear view of what your Go application is doing.

I've been working with Go professionally for several years and have spoken at GoLab previously — on Go's image and GIF processing capabilities, and on implementing the board game Ticket to Ride in Go. The Ticket to Ride codebase makes a return here not as the main subject, but as a familiar, self-contained domain that lets me demonstrate observability concepts without dragging the audience through a business problem they don't know.

The logging cost and signal-quality angle comes from direct production experience working with Vector and Splunk in high-volume environments. It's a perspective I don't often see in conference talks, which tend to focus on API surfaces rather than the judgment calls that make or break an observability setup.