Observability in Go: What Real Engineers Are Saying in 2025

**Observability in Go is still a puzzle** Go offers incredible performance and simplicity – but when it comes to observability, it lags behind its peers. Across interviews, we consistently heard the same theme: **instrumentation in Go is painful**. Compared to Java or Python, where tools like OpenTelemetry work out-of-the-box, Go often requires significant manual effort, boilerplate, and careful context propagation. Instrumentation in Go took us 6–8 months. It was worth it – but a huge pain.Others simply gave up on manual instrumentation entirely. **The cost of too much data** Another recurring pain point was **data overload**. As one user put it: “We generate trillions of requests. Filtering that down is everything.” … Still, even with all this tuning, **telemetry costs and data quality issues**remain a problem for many. **Tracing: loved and hated** There’s a universal recognition of the power of **distributed tracing**, but also wide frustration with the current tools and workflows. **Common issues:** - Lack of automation in Go - Forgetting to pass context - Weak trace search (especially with Jaeger) - Span gaps (especially around databases and queues) Despite these challenges, nearly everyone wanted better tracing – not fewer traces. *Tracing helped us catch a memory spike that would have taken weeks otherwise.* ... **Auto-instrumentation**: Especially for HTTP/gRPC and third-party libraries **Span coverage tools**: “Why is this path not instrumented?” **Minimal code pollution**: Nobody wants another