OpenTelemetry Go Logs RC Brings Structured Logging to Parity with Traces and Metrics

The OpenTelemetry project has officially promoted its Go Logs API and SDK to release candidate (RC) status as part of the v1.47.0-rc.1 release. Advancing from the previous v0.22.0 beta baseline, the packages under go.opentelemetry.io/otel/log and go.opentelemetry.io/otel/sdk/log are now aligned with the coordinated versioning used by stable OpenTelemetry Go modules. Crucially, the update deprecates previous experimental entry points under otel/log/global and introduces unified Logger and LoggerProvider accessors in the root otel package, initiating a mandatory community testing period before final v1 backward-compatibility guarantees take effect. This release is pivotal for Go developers, site reliability engineers, and platform operators. While OpenTelemetry tracing and metrics have long offered stable abstractions in Go, logging remained a fragmented operational territory reliant on isolated libraries such as Zap, Zerolog, or standard library slog without native correlation guarantees. The Logs SDK RC introduces a specification-compliant BatchProcessor featuring bounded queues and explicit flush and shutdown semantics. This design ensures that high-throughput log emissions never block active request threads or induce unexpected memory bloat in production environments. Contextually, this milestone completes a major operational goal following OpenTelemetry's graduation within the Cloud Native Computing Foundation (CNCF). Polyglot microservice environments have frequently treated Go as an outlier due to its compiled nature and independent logging ecosystem. Bringing Go logging to the brink of v1 stability aligns it with established OpenTelemetry implementations in Java, Python, and .NET, directly supporting the cloud-native industry's push toward standardized telemetry pipelines that eliminate vendor-specific agent sprawl. In practice, engineering teams should begin evaluating v1.47.0-rc.1 across staging and pre-production workloads. Developers should migrate deprecated otel/log/global references to the root otel API and stress-test the BatchProcessor against high-cardinality, heavy logging scenarios. Because downstream log exporters and test harnesses remain experimental, teams should standardize on exporting log records via OTLP/gRPC directly to an OpenTelemetry Collector gateway rather than coupling application code to vendor-specific exporters.