Recently, I encountered a challenge in one of our production systems: tracing requests across multiple Go services felt like chasing ghosts. That experience sparked my exploration into combining Chi Router with OpenTelemetry. If you’re building distributed systems in Go, this pairing offers clarity amidst complexity. Let me show you how they work together.

Chi provides a lean HTTP router for Go. OpenTelemetry delivers standardized observability. When integrated, they automatically track requests across service boundaries. Why does this matter? Because understanding request flow in microservices is critical for debugging and performance tuning.

Setting this up is straightforward. First, install the necessary packages:

go get go.opentelemetry.io/otel \
         go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp \
         github.com/go-chi/chi/v5

Next, wrap your Chi router with OpenTelemetry instrumentation:

package main

import (
	"net/http"
	"github.com/go-chi/chi/v5"
	"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
)

func main() {
	r := chi.NewRouter()
	// Your routes and middleware here
	instrumentedRouter := otelhttp.NewHandler(r, "api-gateway")
	http.ListenAndServe(":8080", instrumentedRouter)
}

This simple wrapper creates spans for every incoming request. Each span represents a unit of work—like a function call or HTTP request—and contains timing data.

But what happens inside your handlers? Consider this example:

r.Get("/users/{id}", func(w http.ResponseWriter, r *http.Request) {
	ctx := r.Context()
	_, span := otel.Tracer("user-service").Start(ctx, "get-user-data")
	defer span.End()
	
	// Database call or external API request here
	// OpenTelemetry automatically propagates context!
})

Notice how we extract the context from the request? This propagates trace identifiers downstream. Whether you’re calling databases or other services, the trace remains intact.

The benefits become obvious in production. You’ll see:

• Automatic latency metrics per endpoint
• Visualized request flows in tools like Jaeger
• Error correlation across services
• Minimal performance impact (Chi averages < 2μs per route)

How might this reveal hidden bottlenecks? Last month, this integration helped us discover an unoptimized database query buried three services deep. Without trace correlation, we’d have spent days hunting it.

For advanced scenarios, add custom attributes to spans:

span.SetAttributes(
	attribute.String("user.id", userID),
	attribute.Int("http.status_code", 200),
)

These enrich traces with domain-specific context, turning abstract spans into actionable insights.

Exporting traces to backends like Prometheus or Grafana Cloud requires just a few more lines. Here’s a snippet for OTLP export:

exporter, _ := otlptracegrpc.New(ctx)
provider := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))
otel.SetTracerProvider(provider)

This flexibility ensures your telemetry works with existing infrastructure.

What could you fix in your system today with full request visibility? The combination delivers immediate value: Chi’s efficiency paired with OpenTelemetry’s observability creates resilient services. For teams operating at scale, it transforms debugging from guesswork to precision.

If this approach resonates, share your implementation stories below. Found a creative use case? Let’s discuss in comments—and if this helped, pass it along to others wrestling with distributed tracing!