OpenTelemetry in Go

Entry point for OpenTelemetry mechanics in Go services. Load a reference below based on the task; each reference is self-contained.

References

For upgrade reviews, always finish with a safe local verification path (go mod tidy -diff, go build ./..., and go test ./...). Test exporter URL or retry changes against a disposable local receiver, never a deployment endpoint.

Module versioning — read before adding dependencies

opentelemetry-go is split into independently versioned module groups. They do NOT share one version number. Assuming they do is the most common cause of broken builds and version churn:

The trap: pinning every module to the core version (e.g. go get go.opentelemetry.io/otel/[email protected]) fails — log and bridge modules have no v1.x tag. Hand-picking and re-guessing each @vX is the churn to avoid.

Do this instead — add each module with @latest and let Go resolve a compatible set:

go get go.opentelemetry.io/otel@latest go.opentelemetry.io/otel/sdk@latest
# logs (separate v0.x line — do NOT force the core version):
go get go.opentelemetry.io/otel/log@latest go.opentelemetry.io/otel/sdk/log@latest \
       go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp@latest
# contrib (instrumentation and bridges each resolve to their own v0.x line):
go get go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp@latest \
       go.opentelemetry.io/contrib/bridges/otelslog@latest
go mod tidy && go build ./...

If exact versions are required, fetch each module group's tag from its own source (see below) — never infer one group's version from another's.

Sources of Truth

For YAML schema details, fetch the upstream sources listed in the otel-declarative-config skill. For Go-specific facts:

Cross-References

• Schema-level facts: otel-declarative-config skill (language-agnostic YAML schema sources).
• SDK version selection across languages: otel-sdk-versions skill.
• Semantic conventions lookup: otel-semantic-conventions skill.