OpenTelemetry has reached general availability across its core components. If you have been waiting for it to stabilize before committing to it as your instrumentation standard, the wait is over.
This matters more than most GA announcements because of what OpenTelemetry actually is: a vendor-neutral standard for collecting telemetry data from your applications.
The Problem It Solves
Before OpenTelemetry, instrumentation was a vendor decision you made once and lived with. You picked Datadog, New Relic, Dynatrace, or a dozen other options. You installed their SDK or agent. Your application code or your infrastructure started generating telemetry that flowed to their platform.
The problem is that this instrumentation is vendor-specific. If you want to switch observability platforms, you re-instrument your applications. For a large microservices environment, that can be a multi-quarter engineering project.
OpenTelemetry separates the instrumentation from the backend. You instrument your code once using the OTel SDK. That instrumentation generates telemetry in a standardized format. You send it wherever you want: Grafana, Honeycomb, Datadog, your own ClickHouse cluster, or any combination.
Switching backends becomes a configuration change, not a re-instrumentation project.
What GA Actually Means
OpenTelemetry is a collection of components: language SDKs, the Collector, the protocol (OTLP), and the semantic conventions for what signals mean. Not all of these are at the same maturity level.
GA means the core components have stable APIs that will not have breaking changes. The Collector, OTLP, and the SDKs for Go, Java, Python, JavaScript, and .NET are stable. The semantic conventions, which define standard attribute names for things like HTTP status codes and database query types, are in progress.
If you instrument your services against the stable APIs today, that instrumentation is forward-compatible.
The Migration Path
The practical starting point is the OpenTelemetry Collector. Even if you are keeping your existing observability backend for now, deploying the Collector as a sidecar or agent and routing telemetry through it decouples your application instrumentation from your backend. You can switch the backend later without touching the application.
For new services, instrument with the OTel SDK from day one. For existing services, the migration effort depends on what you are replacing. Most vendors now publish migration guides from their proprietary SDK to OTel.
Auto-instrumentation, which injects telemetry without code changes using agents or bytecode manipulation, is available for Java, Python, and Node. For most web frameworks and database clients, auto-instrumentation gives you traces, metrics, and logs without writing instrumentation code yourself.
The observability ecosystem has largely converged on OpenTelemetry as the standard. Building on it now means your instrumentation investment compounds rather than depreciates when your backend choices change.