Build custom OpenTelemetry Collector distributions with OCB (OpenTelemetry Collector Builder). Use when authoring or debugging a builder manifest (builder.yaml), choosing component and provider versions, building a collector that bundles a custom or out-of-distribution component, setting up CI or Docker builds of a distribution, or troubleshooting OCB build failures. Triggers on "ocb", "collector builder", "custom collector distribution", "builder manifest", "builder-config", and version-mismatch errors from OCB builds.
75
92%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
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/builder@v0.158.0The commands below use ocb, the release-archive binary name. If you install with
go install, invoke the same commands as builder ... instead.
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.158.0
processors:
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.158.0
exporters:
- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.158.0
- gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.158.0
providers:
- gomod: go.opentelemetry.io/collector/confmap/provider/fileprovider v1.64.0
- gomod: go.opentelemetry.io/collector/confmap/provider/envprovider v1.64.0providers: 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. The generated Collector defaults conf_resolver.default_uri_scheme to env, so an explicit list without envprovider fails configuration validation unless you set another included provider as the default. Either omit the key, or include envprovider plus 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.158.0Two 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.158.0 |
v1.y.0 (stable) | confmap providers (confmap/provider/...), other 1.x modules (pdata, etc.) | v1.64.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.158.0/cmd/builder/internal/config/default.yaml — check it rather than guessing (for v0.158.0 it is v1.64.0).v prefix (v0.158.0, not 0.158.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-releasesc5d2edc
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.