open-telemetry/opentelemetry-go

Adopt it if your Go services need tracing, metrics or logs exported to an observability platform, and you are willing to wire instrumentation and an exporter before data shows up. If you already have a vendor SDK in your code, this replaces that dependency with a vendor-neutral one.

The problem

You want to know how a request moves through a Go service: which handler is slow, where an error originates, and how a metric relates to a specific trace. Without a common layer you either drop ad-hoc timing code into handlers or install a vendor-specific agent and SDK, then rewrite when the backend changes. OpenTelemetry-Go changes the middle step: you instrument the application against its API and attach an exporter that ships the data to the platform of your choice. What you get is one instrumented codebase whose destination is a configuration concern rather than a code dependency.

What's different

The repository supplies the Go implementation of the OpenTelemetry API and SDK, with traces, metrics and logs all marked Stable in the project status table. The split matters: the API package is what your application and library dependencies call, while the SDK and exporters own collection and delivery. Official exporters cover OTLP for all three signals, Prometheus for metrics, stdout for all three and Zipkin for traces, so the same instrumentation can feed different backends.

The practical trade-off is that this is infrastructure, not a self-contained feature. Instrumentation alone produces nothing visible; you also need an export pipeline and a backend to receive it. Much of the day-to-day convenience sits outside this repository too, in the officially supported instrumentation libraries for common Go packages and the examples in the contrib project. Using the raw otel package directly is the documented path when you need custom spans or want to extend what a library provides, but it asks you to reason about spans, meters and providers rather than adding a decorator and moving on.

Compatibility is deliberately narrow. The project supports the current supported Go releases and drops the oldest when it leaves upstream support, with a minor release adding a new Go version and the following minor release removing compatibility testing for the archived one. The README lists tested combinations across Ubuntu, macOS and Windows on amd64, plus 386 and arm64 on selected platforms; other systems may work but carry no compatibility guarantee.

Who should try it

It fits teams running Go services that already have, or are choosing, an observability backend and want traces, metrics and logs sent through one API instead of three vendor SDKs. It also fits library authors who want their package to emit telemetry that downstream users can route to whichever collector or platform they use.

It is a poor fit for a small script or a single binary where you only need one counter logged to stdout, or for a team that has no backend or collector to receive the data. In those cases the setup is a larger commitment than the information gained, and the stdout exporter only helps for local inspection. Teams that must stay on Go versions no longer supported upstream should check the versioning policy before planning an upgrade cycle around this dependency.

Requirements and limitations

You need a supported Go toolchain and an export target: a collector or backend that speaks OTLP, a Prometheus scrape endpoint, or one of the other documented exporters. Plan for two distinct maintenance tasks. The first is setup: deciding what to instrument, adding the API calls or instrumentation libraries, and configuring the exporter and resource attributes. The second is ongoing: tracking Go language support windows and the related minor releases, since compatibility with an archived Go version is removed after a transition release. Instrumentation written against a library can also lag behind changes in that library or in this project's instrumentation packages.

Do not expect this repository to provide dashboards, alert rules, sampling policy for your traffic or a hosted backend. Those remain your observability platform's responsibility. The versioning documentation is the place to confirm stability guarantees before you build a long-lived dependency on specific APIs.

HotRepo's take

The only dated HotRepo observation is a single daily-board appearance on 2026-10-27 at 6,581 stars with +0 that day; with one recorded date, trend persistence cannot be judged, and the repository's age and star count say nothing about maintenance quality. The more useful check is whether the Go versions and platforms you deploy are in the compatibility table and how the project's release cadence handles dropping old Go releases; verify that against the getting started guide and versioning documentation before committing.