Help us improve
Share bugs, ideas, or general feedback.
From opentelemetry-agent-skills
Configures OpenTelemetry SDK providers (tracer, meter, logger) via declarative YAML. Replaces scattered OTEL_* env vars and programmatic setup for telemetry pipelines with OTLP exporters and sampling strategies.
npx claudepluginhub ollygarden/opentelemetry-agent-skills --plugin otel-javaHow this skill is triggered — by the user, by Claude, or both
Slash command
/opentelemetry-agent-skills:otel-declarative-configThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Declarative configuration replaces scattered `OTEL_*` environment variables and language-specific
Guides OpenTelemetry SDK setup, custom instrumentation (spans, attributes, events, links), sampling, OTel Collector config, and OTLP export to Honeycomb for Go, Python, Node.js, Java, Ruby, .NET, Rust.
Instrument apps with OpenTelemetry and send telemetry to Grafana Cloud via OTLP. Covers SDK setup, Alloy collector, sampling, and migration from other observability tools.
Guides OpenTelemetry instrumentation setup across multiple languages (Node.js, Go, Python, Java, .NET, Ruby, PHP, browser, Next.js). Covers spans, metrics, logs, resource attributes, sampling, and sensitive data handling.
Share bugs, ideas, or general feedback.
Declarative configuration replaces scattered OTEL_* environment variables and language-specific
programmatic SDK setup with a single YAML file. One file configures all SDK components: tracer
provider, meter provider, logger provider, propagators, and resource.
For the current per-language SDK status, fetch the SDK compatibility matrix (see Sources of Truth). Use it to understand implementation coverage, not as the only source for YAML literals.
This skill teaches concepts. The schema itself, valid file_format strings, field names,
and SDK compatibility evolve per release — fetch from upstream rather than relying on
embedded copies. Cache results for the conversation; refetch only on schema-related errors.
| Fact | Fetch |
|---|---|
| Latest schema release tag | gh release view --repo open-telemetry/opentelemetry-configuration --json tagName,publishedAt |
SDK ↔ schema compatibility matrix (coverage advisory, not authoritative for literal file_format) | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/language-support-status.md |
| Field-by-field schema docs | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/schema-docs.md |
| Compiled JSON Schema (validate generated YAML against this) | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/opentelemetry_configuration.json |
| Canonical full example | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/examples/otel-sdk-config.yaml |
| Migration template (every option, with comments) | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/examples/otel-sdk-migration-config.yaml |
| Schema CHANGELOG (breaking-change history with migration steps) | WebFetch https://raw.githubusercontent.com/open-telemetry/opentelemetry-configuration/main/CHANGELOG.md |
Workflow when generating YAML:
file_format literal. If this conflicts with language-support-status.md, the
runtime/package wins.examples/otel-sdk-config.yaml → use as the structural template only after
adapting the file_format and fields to the selected runtime/package.opentelemetry_configuration.json and validate the result,
then still verify against the selected runtime/package because SDK implementations may
lag or differ from the schema repository.The latestSupportedFileFormat values in language-support-status.md are schema/version
coverage metadata. Do not mechanically copy values like 1.0.0-rc.3 into YAML unless the
target SDK parser, agent docs, or package fixtures prove that exact literal is accepted.
Terminology trap: schema coverage identifiers and YAML file_format literals are related,
but not interchangeable. A matrix entry may use a semver-shaped value such as
1.0.0-rc.3, while an SDK parser may accept a config literal such as 1.0-rc.3 or
1.0. Generated YAML must use the parser-accepted literal.
For language-specific package versions and SDK API surface, see the Sources of Truth section
in each language's otel-<lang> skill (otel-go, otel-java, otel-js).
The standard environment variable is OTEL_CONFIG_FILE:
export OTEL_CONFIG_FILE=/app/configs/otel.yaml
When set, the SDK reads this file at startup. All other OTEL_* env vars are ignored except
those referenced via ${env:VAR} substitution inside the config file.
Language-specific activation varies — see the language sdk-setup skills for details.
| Syntax | Behavior |
|---|---|
${VAR} | Substitute with value of VAR |
${env:VAR} | Same as ${VAR} (explicit prefix) |
${VAR:-default} | Use default if VAR is unset or empty |
$$ | Escape sequence, resolves to literal $ |
Rules:
${BOOL} where BOOL=true becomes boolean)Programmatic API > Environment Variables > Configuration File
(highest) (lowest)
otel-go, otel-java, otel-js (each loads its own references/declarative-setup.md).