otel-migration

Follow a phased migration: initialize the OTel SDK with OTLP exporters, add HTTP framework middleware for automatic request spans, thread trace context through your call chain, add custom spans at I/O boundaries, then bridge existing logging and metrics. Verify connected traces after each phase.

Use a Prometheus bridge library that reads from your existing registry and exports metrics via OTLP, leaving existing counter and gauge calls unchanged. Keep the /metrics endpoint for current scrapers, or use the OTel Collector's Prometheus receiver to scrape and convert metrics without code changes.

Disconnected traces mean context propagation is breaking somewhere in the call chain. Common causes include using the wrong framework context accessor (Fiber's c.Context() instead of c.UserContext()), losing thread-local context in thread pools, or not passing context.Context through Go function calls.

Yes, via the otelfiber middleware, but you must use c.UserContext() to access the OTel-enriched context. Using c.Context() returns the fasthttp context without the span, which compiles and runs but silently breaks trace connectivity.

Yes, logging bridges exist for slog, zap, logrus, winston, pino, Log4j, Logback, and .NET ILogger. Use a multi-handler pattern to send logs to both stderr and OTel, and convert printf-style format strings to structured key-value pairs first.

This phased retrofit is for existing uninstrumented codebases. For greenfield projects, use a direct OTel instrumentation guide instead, and for Honeycomb Beeline-to-OTel transitions, use a Beeline-specific migration path.