Builds custom OpenTelemetry Collector distributions using OCB. Helps with manifest authoring, version alignment, CI/Docker builds, and troubleshooting build failures.
How this skill is triggered — by the user, by Claude, or both
Slash command
/otel-collector-builder:otel-collector-builderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
OCB generates and compiles a custom Collector binary from a YAML manifest that lists exactly the components to include. Source of truth: [cmd/builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder) in opentelemetry-collector.
OCB generates and compiles a custom Collector binary from a YAML manifest that lists exactly the components to include. Source of truth: cmd/builder in opentelemetry-collector.
Use OCB when the stock otelcol/otelcol-contrib distributions don't fit: you need a component that ships in no distribution, a private/local component, or a slimmer binary with only the components you run.
This skill covers building the distribution. For configuring individual components, see otel-collector; for writing a new component, see the component-authoring guidance; for generating test traffic against the built binary, see otel-telemetrygen.
dist: block plus component lists. Start from the minimal manifest; full key reference in references/manifest.md.v0.x.0 version, contrib components use the same v0.x.0, and confmap providers use the paired stable v1.y.0. Getting this wrong is the #1 build failure — see Version alignment.ocb --config=builder.yaml (binary is named builder when installed via go install). CI, Docker, multi-arch, and local-component workflows are in references/workflows.md../dist/<name> validate --config=<collector-config>.yaml, then start it and send test data (otel-telemetrygen skill). If the build fails, see references/troubleshooting.md.Pick the OCB version equal to the Collector core version you're targeting.
# Release binary (named ocb): https://github.com/open-telemetry/opentelemetry-collector-releases/releases?q=cmd/builder
# Go install (binary is named `builder`, not `ocb`):
go install go.opentelemetry.io/collector/cmd/[email protected]
ocb init (experimental) scaffolds a new distribution repo — manifest, Makefile, sample config, README — in --path (default .).
# builder.yaml
dist:
name: otelcol-custom
description: Custom OpenTelemetry Collector distribution
output_path: ./dist
version: 1.0.0
receivers:
- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.156.0
processors:
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.156.0
exporters:
- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.156.0
- gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.156.0
providers:
- gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.62.0
- gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.62.0
providers: semantics. Omitting the key entirely keeps OCB's built-in default set (env, file, http, https, yaml at the paired stable version). But setting providers: at all replaces that set — listing only fileprovider silently removes ${env:VAR} substitution. Either omit the key, or list every scheme the collector's config will use.
Contrib components use the same list syntax:
processors:
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/tailsamplingprocessor v0.156.0
Two version streams exist and must be paired:
| Stream | Modules | Example |
|---|---|---|
v0.x.0 | OCB itself, all core components (go.opentelemetry.io/collector/...), all contrib components | v0.156.0 |
v1.y.0 (stable) | confmap providers (confmap/provider/...), other 1.x modules (pdata, etc.) | v1.62.0 |
Rules:
v0.x.0 for every core and contrib component, matched to the OCB version.https://github.com/open-telemetry/opentelemetry-collector/blob/cmd/builder/v0.x.0/cmd/builder/internal/config/default.yaml — check it rather than guessing (for v0.156.0 it is v1.62.0).v prefix (v0.156.0, not 0.156.0).--skip-strict-versioning defaults to true, so mismatches surface as Go module resolution errors, not friendly OCB errors. Align versions up front instead of debugging go mod tidy output.ocb --config=builder.yaml # full build: generate + go mod tidy + compile
ocb --config=builder.yaml --skip-compilation # generate sources only (two-stage CI)
ocb --config=builder.yaml --skip-generate --skip-get-modules # compile pre-generated sources untouched
| Flag | Default | Purpose |
|---|---|---|
--config | embedded default manifest | Manifest path. With no --config, OCB builds otelcorecol, a minimal test-only distribution. |
--skip-generate | false | Don't regenerate Go sources |
--skip-compilation | false | Generate sources, don't compile |
--skip-get-modules | false | Don't run go mod tidy/downloads. Since v0.154.0 also leaves go.mod unregenerated. |
--skip-strict-versioning | true | Set to false to make OCB verify resolved versions against the manifest |
--ldflags / --gcflags | — | Extra go build flags |
--verbose | false | Log the underlying Go commands |
Generated output in output_path: main.go, components.go, main_others.go, main_windows.go, go.mod, go.sum, and the compiled binary named dist.name. By default binaries are stripped (-s -w); set dist.debug_compilation: true for Delve-friendly builds.
dist: fields, component spec (gomod/import/name/path), providers, replaces, excludes, conf_resolver, telemetryopentelemetry-collector-releasesnpx claudepluginhub ollygarden/opentelemetry-agent-skills --plugin otel-collector-builderBuilds custom OpenTelemetry Collector distributions using OCB (OpenTelemetry Collector Builder). Handles manifest authoring, version alignment, CI/Docker builds, and troubleshooting build failures.
Configures and deploys the OpenTelemetry Collector: receivers, exporters, processors, pipelines, sampling, RED metrics, and custom distributions. Use for agent/gateway patterns, Kubernetes (operator, Helm chart, raw manifests), and Dash0 forwarding.
Configures OpenTelemetry Collector components (receivers, processors, exporters, connectors, extensions) with config keys, defaults, validation, stability levels, and pipeline wiring.