The OpenTelemetry Collector is an open-source proxy that ingests, processes, and exports traces, metrics, and logs across distributed systems. Deployable as a local agent or an independent gateway, its pipeline architecture decouples application telemetry from proprietary monitoring backends. Engineering teams use it to transform data in flight and route streams to multiple destinations without altering application code.
Why OpenTelemetry Collector instead of Dynatrace APM
Dynatrace APM uses its proprietary OneAgent daemon to auto-instrument runtimes and stream telemetry straight into the Dynatrace cloud platform. While this removes manual configuration, it binds infrastructure to proprietary agent binaries and closed ingestion formats. The OpenTelemetry Collector replaces that collection tier with an open Go binary. Teams define pipelines to batch events, scrub sensitive attributes, and apply tail sampling before data crosses network boundaries. It also enables dual-shipping: engineers can route telemetry to Dynatrace while concurrently feeding open-source backends like Jaeger or Prometheus, testing alternatives without altering application code.
The operational models differ fundamentally. Dynatrace operates as an all-in-one platform where collection, indexing, Davis AI analysis, and dashboards require no customer infrastructure maintenance. The OpenTelemetry Collector provides no persistent database, query interface, or alerting console. Running the Collector means DevOps teams take on operational ownership: tuning buffer queues, setting memory thresholds, managing collector instances, and provisioning downstream storage. Organizations choose the Collector when protocol neutrality and data governance justify the extra infrastructure work.
What it does well
Modular pipeline architecture separates receivers, processors, and exporters into independent signal graphs in a single configuration file.
Tail-based sampling drops routine health checks and retains traces containing errors, curtailing downstream ingestion expenses.
OpenTelemetry Transformation Language (OTTL) provides declarative statements to scrub sensitive data, rename spans, and mutate attributes in memory.
Dual deployment topologies allow the binary to operate as a node daemon scraping local pods or as a centralized gateway cluster.
Multi-protocol ingestion accepts legacy Jaeger, Zipkin, and Prometheus formats while standardizing output on OTLP.
Similar Open Source Tools
Internal telemetry exports runtime Prometheus metrics and health endpoints to monitor queue saturation, dropped spans, and memory use.
Limitations
In-memory queues drop buffered spans during sudden container crashes (GitHub issue #7460), requiring the file-storage extension to guarantee durability during node restarts.
Misconfigured memory limits risk out-of-memory kernel kills; the memory_limiter processor must precede other processors and coordinate with container cgroup limits.
Static exporter authentication prevents dynamic tenant routing (GitHub issue #7800), as outgoing headers cannot be injected from runtime span attributes.
Pipelines lack native unit test tooling (GitHub issue #9709), requiring custom integration tests to validate OTTL statements and routing configurations before rollout.
Who should use it
DevOps engineers running Kubernetes clusters who need a unified agent for pod logs, host metrics, and traces without multiple vendor daemons.
Platform teams managing hybrid environments who want to prevent vendor lock-in by standardizing telemetry ingestion on open protocols.
Site reliability engineers who must sanitize private fields and route high-priority incident data to separate analysis tools.
FAQ
Can OpenTelemetry Collector replace Dynatrace APM entirely?
No. The Collector handles data ingestion, processing, and routing, but it lacks persistent storage, trace indexing, and automated root-cause dashboards.
Does OpenTelemetry Collector store telemetry on disk?
No. It operates as an in-memory streaming proxy, though an optional file-storage extension can buffer data during downstream network interruptions.
Is OpenTelemetry Collector free for commercial use?
Yes. Governed by the Cloud Native Computing Foundation, the project has no licensing fees or volume-based pricing restrictions.
Verdict
The OpenTelemetry Collector is the right choice for organizations that require complete operational ownership over their telemetry pipelines and freedom from proprietary agent lock-in; it is unsuited for teams wanting turnkey monitoring without maintaining backend storage. Active maintenance through September 2026 and an Apache-2.0 license that permits internal modification and private redistribution make it a dependable foundation for cloud-native observability.
Self-host OpenTelemetry Collector with Docker
Verified install
We started this exact setup from scratch in a clean Linux machine on Nov 2, 2026 and checked it through OpenTelemetry Collector's own API: every check passed. Recipes are re-checked regularly and removed if they stop working.
OpenTelemetry Collector has no native authentication. Ports 4318 (OTLP/HTTP) and 4317 (OTLP/gRPC) are bound to 127.0.0.1: access them locally, via an SSH tunnel (ssh -L 4318:127.0.0.1:4318 -L 4317:127.0.0.1:4317 user@<your-server>), or place an authenticating TLS reverse proxy in front of them.
Verify the collector is running on <your-server> by sending a test telemetry payload via HTTP POST to http://127.0.0.1:4318/v1/traces with Content-Type: application/json.
Configure your applications and OpenTelemetry SDKs to export telemetry to http://127.0.0.1:4318 (HTTP) or 127.0.0.1:4317 (gRPC). The collector routes ingested traces, metrics, and logs to the configured exporters in /etc/otelcol/config.yaml.
security: open protocols — no unauthenticated Redis protocol on public ports
security: nuclei scan — no public TCP ports
services healthy
logs clean
Ubuntu 24.04 · Apple container, Docker 29.1.3, Compose 2.40.3+ds1-0ubuntu1~24.04.1. Images pulled in 20 s: otel/opentelemetry-collector:0.164.0.
Based on the upstream setup. Official Docker image pinned to 0.164.0. Receivers bound to 127.0.0.1 because OpenTelemetry Collector has no built-in authentication, with OTLP HTTP (4318) and gRPC (4317) pipelines configured with debug exporter.
