Dynatrace发布OpenTelemetry Collector发行版技术科普博客，未含商业或财务增量

If someone has told you to “use the OpenTelemetry Collector,” you may have noticed there is no single thing to download. There’s a lean default build. There’s a much larger repository of hundreds of community-contributed components. There’s a builder tool that lets you assemble your own binary. And there’s a growing set of vendor distributions, each pre-packaged and ready to install.
This is by design. The OpenTelemetry project chose this structure deliberately, and once you understand why, the landscape makes considerably more sense. In this blog, we walk through each option, the trade-offs it brings, and how to reach a decision you will not regret six months from now.
What is the OpenTelemetry Collector?
Think of the OpenTelemetry Collector as a small program that sits between your applications and your observability backends. It is the translation and routing layer that keeps your instrumentation code independent of whatever platform you use to store and analyze telemetry.
Internally, every Collector runs the same five-component model:
Receivers
pull or accept telemetry from a source. Examples include an application pushing OTLP, a Prometheus endpoint to scrape, or a Kafka topic to consume.
Processors
transform data as it passes through. Typical examples include batching, filtering, redacting sensitive attributes, and enriching spans with resource metadata.
Exporters
send the result to one or more backends, such as a vendor platform, an object store, or another Collector.
Connectors join two pipelines, acting as an exporter for one and a receiver for the next. For example, the spanmetrics connector turns trace spans into request, error, and duration metrics, and a routing connector sends data down different pipelines based on its attributes.
Extensions
add cross-cutting capabilities outside the pipeline, such as health checks, profiling endpoints, and zpages for real-time debugging.
You wire these together in a YAML service section to declare named pipelines for traces, metrics, and logs. The power is in what the separation creates: your instrumentation code does not need to know where your telemetry is going.
If your instrumentation code knows about your vendor, you have lost the main benefit of the OpenTelemetry standard. The Collector is what keeps that promise.
Why isn’t there a single Collector?
The Collector is open source, but you do not ship the source repository. You ship a build of it, a compiled binary or container image that includes a specific set of components. Different builds include different components, and the build you choose is your distribution.
This is the part most teams miss. When someone says “we use the OTel Collector,” they are implicitly choosing a distribution. That choice determines which receivers and exporters are available, how stable they are, what the upgrade path looks like, and how much of the pipeline your team owns and maintains. It’s a foundational decision, not a minor implementation detail.
This blog focuses on the four options most teams encounter: Core (the otelcol binary), Contrib (otelcol-contrib), a custom build via OCB, and a vendor distribution.
The OpenTelemetry project also maintains three additional purpose-built distributions: otelcol-k8s, a Kubernetes-focused build that includes only vendor-neutral, Kubernetes-relevant components; otelcol-otlp, a minimal build restricted to OTLP receivers and exporters; and otelcol-ebpf-profiler, a specialist distribution for continuous profiling via eBPF. All three are scoped distributions built using the same OCB pattern covered here, rather than a separate category of choice.
Core: the conservative foundation
Core (released as otelcol) is the lean, intentionally minimal build maintained by the OpenTelemetry project. It ships the essentials: OTLP receivers and exporters, a debug exporter, the batch and memory_limiter processors, and a small set of extensions such as health_check, pprof, and zpages. That restraint is the point.
Core is intentionally minimal. Confirm the current component maturity and release notes for the version you deploy, especially if your pipeline depends on a specific signal or component. If your telemetry sources already speak OTLP and your topology is simple, Core can be a good starting point because a smaller default component set can make the pipeline easier to reason about.
receivers:
otlp:
nop:  # beta

processors:
batch:
memory_limiter:

exporters:
otlp:
nop:   # beta
debug:

connectors:
forward:   # joins two pipelines

extensions:
health_check:
pprof:
zpages:

service:
extensions: [health_check, pprof, zpages]
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [forward]
traces/export:
receivers: [forward]
exporters: [otlp]
Contrib: the full component library
Contrib (released as otelcol-contrib) is where the OpenTelemetry ecosystem lives. It includes hundreds of components contributed by the community and vendors, such as
Prometheus, Kafka, Jaeger, AWS, Azure, GCP, MongoDB, MySQL,
and many more. If you need to receive from or export to a specific system, Contrib almost certainly has a component for it.
The trade-off is stability. Each component carries its own maturity label (development, alpha, beta, or stable), and the label can vary by signal type (logs, metrics, or traces). A receiver may be stable for metrics but alpha for logs. Some capabilities sit behind feature flags that require explicit opt-in.
Contrib is useful for exploring what’s possible. Before using Contrib in production, review the maturity and support status of each included component, remove components you do not need, and test the selected build in your environment.
receivers:
# --- Metrics ---
hostmetrics:
prometheus:
statsd:
snmp:
vcenter:
sqlquery:
mongodb:
postgresql:
mysql:
redis:
elasticsearch:
kafka:
rabbitmq:
nginx:
apache:
iis:
jmx:
oracledb:
aerospike:
couchdb:
influxdb:
solr:

# --- Traces ---
otlp:
jaeger:
zipkin:
opencensus:

# --- Logs ---
filelog:
syslog:
fluentforward:
journald:
windowseventlog:
tcplog:
udplog:
googlecloudpubsub:
awss3:
awscloudwatch:
azureeventhub:
k8sobjects:
k8sevents:

# --- Infrastructure ---
k8s_cluster:
kubeletstats:
docker_stats:
awscontainerinsightreceiver:
cloudfoundry:
awsxray:
# ... and many more

processors:
transform:   # OTTL-based — filter, enrich, reshape any telemetry
k8sattributes:  # auto-enrich spans/metrics/logs with pod/namespace/node metadata

exporters:
dynatrace:         # generic OTLP — Dynatrace, Grafana, etc.

prometheus:
prometheusremotewrite:
kafka:
file:
debug:

service:
pipelines:
traces:
receivers: [otlp, jaeger, zipkin]
processors: [k8sattributes, transform]
exporters: [dynatrace, otlp]
Build your own with the Collector Builder
Once you know which Contrib components you actually need, the OpenTelemetry Collector Builder (OCB) lets you assemble a custom distribution containing exactly those components. You describe the build in a
manifest.yaml
file, run OCB, and out comes a binary or container image you control entirely.
A custom build can reduce the number of included components and dependencies. Depending on implementation, that may simplify inventory and review. Validate security, startup performance, compliance controls, and upgrade behavior in your environment.
OCB is the standard answer when an organization is mature enough to know its component list and wants tight operational control over what it ships.
# manifest.yaml — Custom distribution via OCB
dist:
name: otelcol-custom
description: Lean custom collector for Kubernetes + app observability
output_path: ./otelcol-custom
otelcol_version: 0.120.0

receivers:
# Core
- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.120.0
# Contrib
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/filelog v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/kubeletstats v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/k8s_cluster v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetrics v0.120.0

processors:
# Core
- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.120.0
- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.120.0
# Contrib
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/k8sattributes v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/processor/transform v0.120.0

exporters:
# Core
- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.120.0
- gomod: go.opentelemetry.io/collector/exporter/debugexporter v0.120.0
# Contrib
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/dynatrace v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/prometheusremotewrite v0.120.0

connectors:
# Core
- gomod: go.opentelemetry.io/collector/connector/forwardconnector v0.120.0
# Contrib
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/connector/spanmetricsconnector v0.120.0
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/connector/routingconnector v0.120.0

extensions:
# Core
- gomod: go.opentelemetry.io/collector/extension/zpagesextension v0.120.0
# Contrib
- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.120.0
With the manifest in place, the build itself is a two-step process. Install OCB with
go install go.opentelemetry.io/collector/cmd/builder@v0.120.0
, then point it at your manifest:
ocb --config otelcol-builder.yaml
. OCB fetches only the modules you declared, compiles them together, and writes a single ready-to-run binary to the
output_path
you specified. Examples are illustrative; verify component names, maturity, and versions against current OpenTelemetry documentation before use. The OCB source and releases
live on github
. When you need to hunt for additional receivers, processors, or exporters to add to your manifest, the full component registry
is on github
.
Vendor distributions: curated packaging and support options
Vendor distributions are pre-assembled builds. Depending on the vendor and offering, they may include support, signed artifacts, compatibility testing, or documented upgrade guidance. Verify the specific distribution’s terms and practices before you depend on it.
Vendor distributions may be the path of least resistance, reducing some packaging and maintenance work by providing a curated build and support model. Evaluate the vendor’s included components, release practices, and support terms against your requirements.
Before committing, check the vendor’s published component manifest against your actual pipeline needs. Vendor distributions are built on OCB and include a curated subset of Contrib, not all of it. If your pipeline depends on a component that didn’t make the vendor’s cut, you will discover that gap at configuration time, not at evaluation time. A Kafka receiver or exporter is a common example: it is present in Contrib, but not every vendor distribution includes it. Review the manifest, map it to your receivers and exporters, and raise any gaps with the vendor before you build a dependency on their distribution.
How do I pick an OpenTelemetry distribution?
Distribution
Components
Stability
Maintenance overhead
Best for
Core
Minimal; OTLP, batch, debug only
More predictable component set; verify current maturity
Generally lower
Simple OTLP pipelines
Contrib
Broad; hundreds of community components
Varies by component and signal
Moderate to high, depending on usage
Prototyping and exploration
OCB (custom build)
Exactly what you declare
Your choice; you pin versions
High; you own the build pipeline
Teams needing tight operational control
Vendor distribution
Curated subset of Contrib
Depends on vendor testing and release practices
Low; vendor handles packaging
Teams that want curated packaging and support
A practical way to choose is to start broad during evaluation, then narrow as your requirements become clearer. Contrib can help you understand which receivers, processors, and exporters you need. Once your component list stabilizes in a non-production environment, decide how much build, release, and support responsibility your team wants to own.
If your organization has the engineering capacity to own a build pipeline and wants precise control over every component version, OCB may be the right next step. If you prefer a curated distribution with a vendor support model, evaluate whether the vendor’s component selection, release practices, and support terms fit your requirements.
A few habits will serve you well regardless of which path you choose:
Pin component versions.
Stage upgrades the way you would stage any other infrastructure change.
Track the maturity labels of components you depend on.
Do not enable components you do not use, because every component in your binary is one you implicitly maintain.
What comes next?
Choosing a distribution solves the first problem. At scale, teams may need processes or additional tooling for coordinated upgrades, configuration distribution, health monitoring, and fleet visibility. Requirements vary by deployment model and the management capabilities already in use.
That is the subject of the next blog in this series: managing OTel Collectors at scale.