Migrate Safely to the Dynatrace OTel Collector
Краткое содержание
Pixel shares a guide to migrating from the OpenTelemetry Contrib image to the Dynatrace OTel Collector. It explains that configuration semantics remain standard while the curated build includes fewer components, and highlights the need to verify receivers and other components before switching to avoid startup failures.
DEV Community
Dynatrace OTel Collector: migrating from Contrib safely
Your Collector runs the Contrib image, and someone has asked you to move to the Dynatrace OTel Collector. Before you touch a line of configuration, one question matters: what actually changes? This article skips the tour of Contrib, which our Contrib components guide already covers. It looks only at the gap between the two builds and at the migration path. What I read: the introduction and deployment pages of the Dynatrace documentation, then the README of the GitHub repository, on 9 November 2026. Version numbers are those shown on those pages that day. I did not run the binary, so anything about runtime behaviour is flagged as unverified. Dynatrace OTel Collector: a curated subset, not a fork The documentation is explicit. The distribution keeps the standard configuration model and component semantics, with no proprietary abstractions and no hidden defaults. In practice, a YAML file written for Contrib stays readable as it is. The difference lies in what is compiled into the binary. Contrib ships a very large number of third-party receivers, processors and exporters. Dynatrace advises against it in production and keeps it for testing, because it uses more storage and memory than a targeted build. The Dynatrace distribution contains only components the vendor says it has verified for common use cases. The full list lives in the GitHub repository, not in the documentation. What the distribution removes: read the list before you switch This is where migrations go wrong. A component missing from the binary stops the Collector from starting, because it rejects a configuration that names an unknown component. Here is what I found in the README’s Components section. Source : github.com Receivers: otlp, filelog, hostmetrics, prometheus, statsd, syslog, fluentforward, jaeger, zipkin, kafka, kafka_metrics and four Kubernetes receivers (k8sobjects, k8scluster, kubelet_stats, k8sevents). Journald and netflow are alpha. Processors: batch, memory_limiter, attributes, resource, resource_detection, transform, k8sattributes, cumulativetodelta, metricstarttime, probabilistic_sampler, tail_sampling and groupbytrace, plus filter, redaction and genainormalizer in alpha. Exporters: otlp, otlphttp, debug and kafka, plus load_balancing in alpha. Extensions and connectors: bearertokenauth, oidcauth, healthcheck, zpages, k8sleaderelector and filestorage; forward and, in alpha, spanmetrics. I could not find a Prometheus Remote Write exporter, a file exporter, a SQL receiver or a Docker receiver in that list. If your pipelines rely on one of them, you need another route. That absence comes from my reading of the README. I did not compile the binary to confirm it. What you get in return The distribution adds no hidden feature. It adds guarantees around the binary. Bounded vendor support: x86-64 and ARM64 builds are covered by Dynatrace Support. Each minor version is supported for three months, with fixes shipped as a patch on the latest supported minor or in the next minor. Independent security patches: Dynatrace says it receives them without waiting for upstream Collector releases. Signed images: they are signed with cosign from version 0.49.0 and published on GHCR, Amazon ECR Public and Docker Hub. Limited support for everything else: for Contrib, Dynatrace only covers the components and versions present in its own distribution. GitHub issues are handled on a best-effort basis, with no contract or SLA. So the trade is fewer components for a supported perimeter. For an SRE team, it also means less surface to patch, and therefore less toil with every CVE. Migrating from Contrib in five steps This is the route I would follow. It starts from your real configuration, not from the documentation. List the components you use. With yq (version 4), print what your pipelines name, then the extensions: yq '.service.pipelines[] | .receivers[], .processors[], .exporters[]' config.yaml \
| sed 's#/.##' | sort -u
yq '.service.extensions[]' config.yaml | sed 's...

Powered by Readybot.io*