opentelemetry-go: tracing and metrics for Go services

What opentelemetry-go is for, and who ends up using it

The README states the goal plainly: a single set of APIs to capture distributed traces and metrics from an application and send them to an observability platform. For Go, this repository is that set. It is aimed at people who own a service and want its behaviour measured without committing the code to one vendor's agent or one vendor's wire format.

The practical audience is narrower than "anyone writing Go". If you are adding telemetry to a library that other people will import, you want the API packages, so your callers decide where the data goes. If you are running the binary, you want the SDK and an exporter. The repository splits along that line: trace.go, metric.go, log.go, propagation.go and handler.go sit at the top level as the API surface, while sdk/, exporters/ and bridge/ hold the pieces that do the work. The README points elsewhere for the most common starting point, the officially supported instrumentation libraries in opentelemetry-go-contrib, which is where framework-specific hooks live rather than here.

How the API, SDK and exporters fit together

There are two steps in the README's framing: instrument your application, then configure an exporter. The API packages are what your code calls. The SDK is what turns those calls into spans, metric instruments and log records that can actually be shipped. Swapping the SDK for a no-op implementation is the usual way to keep instrumentation in a library without forcing a dependency on a concrete pipeline.

The repo is a multi-module Go project, and go.mod shows how the pieces are stitched together locally with replace directives:

replace go.opentelemetry.io/otel/trace => ./trace
replace go.opentelemetry.io/otel/metric => ./metric
replace go.opentelemetry.io/otel/log => ./log

That layout matters when you read version numbers. A release tag like v1.46.0 carries several module versions at once, and the release list shows exactly that pattern: v1.46.0/v0.68.0/v0.22.0/v0.0.19. The trace, metric and log modules move on their own schedules, so a single tag does not mean every module changed.

On the export side, the README gives a table of supported exporters: OTLP covers logs, metrics and traces; Prometheus covers metrics only; stdout covers all three; Zipkin covers traces only. If your backend speaks OTLP, one exporter path handles everything. If your backend is Prometheus, you are exporting metrics and nothing else through that route.

Installing opentelemetry-go and getting a first trace out

The README does not include install commands. It points to a getting started guide on opentelemetry.io and to the package documentation at pkg.go.dev/go.opentelemetry.io/otel. The module path is visible in go.mod, so the standard Go tooling applies: you fetch go.opentelemetry.io/otel itself, and the SDK and exporter modules under it in the same way, using go get against those module paths.

The exporter path follows the repository's exporters/otlp/ layout. After fetching, the shape of a first program is: build a tracer provider backed by the OTLP exporter, install it globally, start a span, end it, and shut the provider down so buffered spans are flushed. The README does not spell out that sequence, so treat the getting started guide and the examples linked from it as the authoritative walkthrough rather than improvising from the exporter table.

One detail worth checking before you wire anything: the compatibility table lists Ubuntu, macOS and Windows on Go 1.26 and 1.27 across amd64, 386 and arm64. The README says other systems should work but carry no compatibility guarantees.

For a local check without a backend, the stdout exporter is the shortest path, since the README lists it as covering logs, metrics and traces.

Logs are still a release candidate, and that has consequences

The project status table is the single most useful thing in the README. Traces are Stable. Metrics are Stable. Logs are Release Candidate, with a footnote pointing at the v1.47.0-rc.1 release. That is not a marketing qualifier; it means the log API and SDK can still change in ways the trace and metric APIs cannot.

If your plan is "instrument everything at once, uniformly", the log signal is the part where you should expect churn. The repository's own versioning documentation, VERSIONING.md, is where the stability guarantees are defined, and the README explicitly defers to it rather than restating it. Anyone building a long-lived logging pipeline on this repository should read that file before pinning versions.

The second limitation is structural. The README's exporters table is short: OTLP, Prometheus, stdout, Zipkin. There is no long list of vendor exporters here, and the README directs you to opentelemetry-go-contrib for instrumentation libraries and examples. If the thing you want to instrument is a specific framework or database driver, the odds are good that the code you need is not in this repository at all. That is a deliberate split, but it means "opentelemetry-go" as a search term covers two repositories with different release rhythms.

opentelemetry-go compared with Prometheus client_golang

The comparison people actually make is with Prometheus. The search data shows it: "Is OpenTelemetry the same as Prometheus?" They are not the same kind of thing. Prometheus's Go client library is a metrics library with a pull model at its centre; you register collectors, expose an HTTP endpoint, and a Prometheus server scrapes it. opentelemetry-go is a multi-signal API with a push-oriented SDK, and Prometheus is one of several exporters it can target.

The difference shows up in the code you write. With a Prometheus client, the metric instruments and the exposition format are the same concern. With opentelemetry-go, you create instruments against the API, and the choice of Prometheus or OTLP is an exporter decision made later. That indirection is the point: it lets a library instrument once and let the application choose the backend. It is also a cost, because you now have a provider, a reader or processor, and an exporter lifecycle to get right, and a misconfigured shutdown can lose data that a scrape-based setup would simply have re-collected.

If all you want is counters and gauges scraped by Prometheus, the Prometheus client is the smaller dependency and the shorter path. If you want traces and metrics from the same instrumentation, opentelemetry-go is the one that covers both.

Maintenance, versioning and licence

The repository is not archived, and the last push was on 2026-09-21. Releases are frequent: v1.45.0 on 2026-08-03, v1.46.0 on 2026-08-25, and v1.47.0-rc.1 on 2026-08-28. A release candidate in the list is consistent with the README's note that logs are at Release Candidate, so the RC line is not a sign of an unstable project overall, it is the log module's status showing up in the tags.

The upgrade cost is mostly a function of the multi-module layout. Because trace, metric and log are separate modules with their own versions, a bump is not always a single number. The Makefile includes multimod and crosslink under internal/tools, which is the repository's own machinery for keeping those module versions consistent, and a verify-mods target in the CI path. You do not need those tools to consume the library, but they explain why the release tags look the way they do.

On licensing: the repository is Apache-2.0, and the README carries an OpenSSF Best Practices badge plus a FOSSA licence badge. Apache-2.0 is permissive and includes an explicit patent grant, but the obligations that apply to your distribution are a question for your own legal review, not something this article can settle.

Go version support is the other recurring cost. The README quotes the Go release policy and describes a two-step process: a minor release adds support for a new Go version, and the following minor release drops compatibility testing for the oldest archived version. Upgrading Go and upgrading opentelemetry-go are therefore linked, and the compatibility table is the place to check before you move either.

Editorial conclusion

Adopt opentelemetry-go if you run Go services and want vendor-neutral traces and metrics: the trace and metric APIs are stable, and the OTLP exporter covers all three signals. Do not adopt it expecting a finished logging story, because the README marks Logs as Release Candidate, and do not treat the exporters directory as the whole answer for libraries you depend on, since much instrumentation lives in opentelemetry-go-contrib instead. Before you commit, verify which module paths your build actually resolves, and confirm the Go version your toolchain reports against the compatibility table, because the project only guarantees the OS, Go version and architecture combinations listed there.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-telemetry/opentelemetry-go on GitHub
3. Project website
4. README
5. Releases