OpenTelemetry Go Logs API and SDK Reach RC, Paving Path to Full Signal Stability

The OpenTelemetry project has officially promoted the Go Logs API and SDK (go.opentelemetry.io/otel/log and go.opentelemetry.io/otel/sdk/log) to Release Candidate (RC) status with the release of OpenTelemetry Go v1.47.0-rc.1. This major transition marks the final milestone before the project freezes the public API and issues long-term v1 backwards compatibility guarantees. Alongside the RC designation, global logging functions—such as Logger, GetLoggerProvider, and SetLoggerProvider—have been consolidated directly into the root otel package, standardizing global provider registration across traces, metrics, and logs. Go powers an enormous share of modern cloud-native backends, Kubernetes controllers, and distributed microservices. However, Go developers building on OpenTelemetry have faced an asymmetric observability story: while distributed tracing and metric collection enjoyed stable v1 guarantees, logging remained stuck in experimental and beta tiers. As a result, platform architects hesitated to bind production logging pipelines directly to OpenTelemetry Go SDKs out of concern for breaking interface changes. Reaching RC status removes this adoption blocker, giving enterprise teams the confidence to standardize on a singular telemetry ingestion framework that unifies structured logs, spans, and metrics under standard semantic conventions. This milestone fits into the broader trajectory following OpenTelemetry's graduation within the Cloud Native Computing Foundation (CNCF). Over recent quarters, the project has transitioned from defining foundational specifications to driving parity and stabilization across every major language SDK. Historically, logging was the last and most difficult pillar to standardize because mature ecosystems like Go already had deeply entrenched logging libraries—including slog, zap, and zerolog. By providing a robust, non-blocking bridge architecture with bounded batch processing rather than attempting to displace familiar logging frontends, OpenTelemetry enables frictionless interoperability while routing telemetry over standard OpenTelemetry Protocol (OTLP) pipelines. Practitioners should use the active 14-day validation window to test v1.47.0-rc.1 in staging environments before the final v1 release locks the interface. Key areas to evaluate include high-throughput log volume behavior, memory allocation overhead, and graceful shutdown semantics within the BatchProcessor. Teams currently using the deprecated otel/log/global imports should migrate to the root otel package functions. While core logging modules are entering stability, practitioners should note that specialized log exporters and test harnesses remain experimental and should be monitored accordingly during rollout.