otel-go — Claude Code skill: setup and installation
Get task-specific guidance for OpenTelemetry in Go, from SDK configuration to instrumentation and upgrades. Useful when adding telemetry or reviewing an existing service.
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a claude-codeWhat otel-go does
The skill directs Go tasks to focused references covering SDK configuration with otelconf and YAML, API usage, contrib instrumentation such as otelhttp and otelgrpc, performance, and breaking changes. Another reference explains compile-time instrumentation with otelc.
OpenTelemetry module groups follow separate version lines. Setting contrib packages to the core SDK version can break a build, so the skill recommends resolving compatible versions per module. Upgrade checks include go mod tidy -diff, go build ./..., and go test ./.... Exporter URL and retry changes should be exercised against a disposable local receiver, not a deployment endpoint.
Use it to choose instrumentation for a Go service or review an SDK upgrade. YAML schema guidance points to the separate otel-declarative-config skill.
What it helps with
- configure the OpenTelemetry SDK with YAML
- choose instrumentation libraries for a Go service
- find deprecated calls and removed APIs
- add compile-time instrumentation with
otelc - resolve separate OpenTelemetry module versions
Example prompts for the agent
- Help me add OpenTelemetry to this Go service and choose the required modules.
- Review this code for outdated OpenTelemetry calls before an SDK upgrade.
- Show me how to instrument a Go build with
otelc.
How to install otel-go
1Skills CLI (Vercel)
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a claude-code2Manually: put the files in place
~/.claude/skills/otel-go/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/otel-go/
1Skills CLI (Vercel)
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a codex2Manually: put the files in place
.agents/skills/otel-go/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a cursor2Manually: put the files in place
.cursor/skills/otel-go/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install ollygarden/opentelemetry-agent-skills otel-go2Manually: put the files in place
.github/skills/otel-go/SKILL.md1Skills CLI (Vercel)
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a gemini-cli2Platform CLI
gemini skills install https://github.com/ollygarden/opentelemetry-agent-skills --path skills/otel-goManually: put the files in place
.devin/skills/otel-go/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about otel-go
How do I install otel-go in Claude Code?
Run npx skills add ollygarden/opentelemetry-agent-skills --skill otel-go -a claude-code. The skill file is at ~/.claude/skills/otel-go/SKILL.md.
What does otel-go do?
It guides OpenTelemetry setup in Go, instrumentation library selection, SDK upgrades, and performance tuning. It also covers compile-time instrumentation using otelc.
Why do OpenTelemetry modules need separate version choices?
Core SDK packages, log exporters, and contrib instrumentation use distinct version lines. Assigning every module the core SDK version can cause a build failure.
Source text
SKILL.md · Apache-2.0
--- name: otel-go description: OpenTelemetry in Go — SDK setup, API surface, breaking changes, contrib instrumentation libraries (otelhttp, otelgrpc, otelmongo), compile-time zero-code instrumentation (otelc), and performance tuning. Use when adding, reviewing, or configuring OpenTelemetry in a Go service. Triggers on "setup otel in go", "go telemetry", "go tracing", "otelconf go", "otelhttp", "otelgrpc", "TracerProvider go", "MeterProvider go", "otelc", "compile-time instrumentation go", "zero-code go instrumentation", "go build instrumentation", or any Go-related OTel question. --- # 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 | File | Use when | |---|---| | [`references/declarative-setup.md`](references/declarative-setup.md) | Configuring the SDK via `otelconf` and YAML: providers, propagators, shutdown, env-var substitution. | | [`references/api.md`](references/api.md) | Looking up import paths, global API access, tracer/meter/logger usage, attributes, propagation, log bridges (zap, slog). | | [`references/instrumentation-libraries.md`](references/instrumentation-libraries.md) | Picking or wiring contrib libraries (otelhttp, otelgrpc, database, AWS, message queues, propagators, resource detectors), and writing manual instrumentation that follows semconv. | | [`references/performance.md`](references/performance.md) | Tuning sampling, batch processor, metric reader, exporter compression/retry, attribute allocation, log `Enabled()` short-circuiting, graceful shutdown. | | [`references/breaking-changes.md`](references/breaking-changes.md) | Auditing existing code for deprecated calls, renamed semantic conventions, and removed APIs across recent SDK / contrib releases. | | [`references/compile-time-instrumentation.md`](references/compile-time-instrumentation.md) | Zero-code, compile-time instrumentation with `otelc`: usage modes (`otelc go build`, tool dependency, toolexec drop-in), subcommands, supported libraries, rule sources/precedence, and pinning via `otel.instrumentation.go`. | 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: | Module group | Example modules | Version line | |---|---|---| | Stable (traces, metrics, logs API/SDK) | `go.opentelemetry.io/otel`, `otel/sdk`, `otel/trace`, `otel/metric`, `otel/log`, `otel/sdk/log`, OTLP trace/metric exporters | **v1.x** (e.g. v1.47.0; logs API/SDK joined at v1.47.0) | | Log exporters and test helpers | `otel/exporters/otlp/otlplog/otlploghttp`, `.../otlploggrpc`, `otel/exporters/stdout/stdoutlog`, `otel/log/logtest`, `otel/sdk/log/logtest` | **v0.x** (separate, lower line, e.g. v0.23.0) | | Contrib instrumentation | `contrib/instrumentation/net/http/otelhttp`, `.../otelgrpc` | **v0.x** (separate line, e.g. v0.72.0) | | Contrib log bridges | `contrib/bridges/otelslog`, `otelzap`, `otellogrus`, `otellogr` | **v0.x** | **The trap:** pinning every module to the core version (e.g. `go get go.opentelemetry.io/otel/exporters/otlp/otlplog/[email protected]`) fails — log exporter, log test-helper, 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: ```bash go get go.opentelemetry.io/otel@latest go.opentelemetry.io/otel/sdk@latest # logs (API/SDK are v1.x; log exporters stay on a 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: | Fact | Fetch | |---|---| | Latest `go.opentelemetry.io/otel` core release | `gh api repos/open-telemetry/opentelemetry-go/releases/latest -q '.tag_name'` | | Latest `go.opentelemetry.io/contrib` release | `gh api repos/open-telemetry/opentelemetry-go-contrib/releases/latest -q '.tag_name'` | | Latest `otelconf` module tag | the version-sorted tag command below the table | | Latest Go semconv package | Search the selected core release's CHANGELOG for `Add the go.opentelemetry.io/otel/semconv/`; do not infer package availability from the upstream semantic-conventions release. Offline: `semconv/v1.43.0` in otel v1.47.0, verified 2026-10-15 (record: the `otel-semantic-conventions` skill's `references/sdk-semconv-packages.md`). | | `otel-go` CHANGELOG | `WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-go/main/CHANGELOG.md` | | `otel-go-contrib` CHANGELOG | `WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-go-contrib/main/CHANGELOG.md` | ```bash gh api repos/open-telemetry/opentelemetry-go-contrib/git/matching-refs/tags/otelconf -q '.[].ref' | sort -V | tail -1 ``` ## 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.
© ollygarden · Apache-2.0 · ollygarden/opentelemetry-agent-skills