Dynatrace → OpenTelemetry

Dynatrace’s pitch is depth: install the OneAgent, and it auto-instruments everything — hosts, processes, JVMs, database calls, real-user sessions — with very little effort. That depth is real, and it’s also the source of the lock-in. The OneAgent is a single proprietary binary that does discovery, instrumentation, and collection all at once, and it feeds exactly one place: Dynatrace. Pricing follows the same shape — host units, DDUs (Davis Data Units), and consumption meters that make the bill hard to predict and harder to cap.

Migrating away used to feel impossible precisely because the OneAgent did so much. OpenTelemetry changes that by unbundling those jobs into open standards you own — and letting you run both stacks in parallel until you trust the new one. This guide is the Dynatrace-specific playbook; for the general argument, see Reducing vendor lock-in with OpenTelemetry.

What the OneAgent does that OTel doesn’t (yet) replace

The OneAgent is not just a collector — it’s a deep, auto-injecting APM platform. Being honest about the gap is what keeps this migration from failing halfway:

Dynatrace capability	OTel equivalent?	Reality
Host / process / container metrics	Yes	hostmetrics + kubeletstats cover the standard set.
Distributed traces	Yes	OTel SDKs / auto-instrumentation emit OTLP spans.
Log collection	Yes	filelog / journald receivers.
Deep code auto-injection (no code change)	Partial	OTel auto-instrumentation is good but not as invisible as OneAgent’s byte-code injection; some languages need more setup.
PurePath (end-to-end code-level traces)	Partial	OTLP distributed traces cover the hops; method-level PurePath depth isn’t fully equivalent.
Smartscape topology (auto-discovered)	No	Derivable from traces/attributes, but Dynatrace’s live dependency map doesn’t transfer 1:1.
Davis AI (automatic root cause)	No	Vendor analytics; the backend you move to provides its own, if any.
Real User Monitoring (RUM)	Usually not	OTel has browser/mobile signals, but not RUM/session feature parity.
Synthetic monitoring	No	Separate capability; keep it or replace with a dedicated tool.
Metadata enrichment (auto tags, entities)	Partial	Recreate with resource/k8sattributes processors; entity model differs.

The takeaway: OTel comfortably replaces the collection and standard-telemetry layer and gives you portable traces, metrics, and logs. It does not wholesale replace Dynatrace’s analytics and auto-magic — RUM, synthetics, Smartscape, and Davis are kept, replaced with other tools, or consciously dropped, not migrated. Decide which you actually rely on before you touch anything. (See what OpenTelemetry can and cannot replace for the general version.)

The mental shift: unbundle the OneAgent

The OneAgent’s strength — one binary that does everything — is exactly what you’re undoing. In the OpenTelemetry world those responsibilities are separate, open, and individually replaceable:

Dynatrace OneAgent does…	…OpenTelemetry splits it into
Code-level tracing (auto-instrumentation)	OTel SDKs + zero-code auto-instrumentation agents
Host & process metrics	hostmetrics receiver on an OTel Collector
Log collection	filelog / journald receivers
Data forwarding to the vendor	OTLP exporter to any backend
PurePath / service topology	Distributed traces (OTLP) rendered by your backend
Fleet configuration	OpAMP control plane

The trade is honest: you give up some of the OneAgent’s turnkey auto-magic, and in return you get an instrumentation layer that is portable, inspectable, and owned by you — one no vendor can revoke or reprice. For many teams the deciding factor is that OTLP traces and metrics work with any backend, so this is the last agent migration they ever have to do.

Step 1 — Instrument with OTel alongside the OneAgent

You don’t have to remove the OneAgent to start. Add OpenTelemetry instrumentation in parallel:

• New services: use the OTel SDK or a zero-code auto-instrumentation agent (Java, .NET, Node, Python — Go via the eBPF-based zero-code option, still maturing) to emit OTLP traces and metrics.
• Hosts: deploy an OTel Collector with the hostmetrics and filelog receivers for infrastructure and log coverage.

Point that OTLP at a collector, not directly at a backend — the collector is the neutral broker that makes everything after this step possible.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      disk:
      network:

exporters:
  otlphttp/backend:
    endpoint: "https://backend.internal:4318"

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/backend]
    metrics:
      receivers: [otlp, hostmetrics]
      exporters: [otlphttp/backend]

Step 2 — Run both stacks and validate parity

This is the step that de-risks a Dynatrace migration. Keep the OneAgent reporting to Dynatrace, and run the OTel stack into a candidate backend at the same time. Then do the boring, essential work of confirming signal parity against a checklist:

• Metrics — do host, process, and container metrics match what Dynatrace shows, within a tolerance? Watch for vendor-specific metrics with no direct OTel equivalent.
• Traces — do distributed traces span the same service hops? Accept that method-level PurePath depth may not be fully equivalent, and decide if that matters for the services in question.
• Resource attributes — are service.name, deployment.environment.name, host, and ownership tags present, so entities are attributable the way Smartscape made them?
• Logs — are severities and timestamps parsed correctly, and are logs correlated to traces via trace/span IDs?
• Dropped telemetry — check the Collector’s internal metrics for refused/dropped data; a silent exporter failure reads as “cleaner data” until an incident.
• Sampling — confirm errors and slow requests are kept at 100%; only sample the high-volume happy path.
• Alerts & dashboards — rebuild the alerts you actually page on against the candidate backend and confirm they fire on the same conditions.
• Failure behavior — restart a collector, kill a backend connection; confirm it buffers and resumes without data loss.

Because both stacks run at once, you can answer these on live production data with Dynatrace still fully in place as the safety net. Nothing gets turned off until the new stack has earned it.

Step 3 — Manage the collector fleet from one place

Removing the OneAgent means giving up its centralized management — Dynatrace deploys and updates agents from the platform. If you replace it with hand-maintained OTel Collector YAML, you’ve traded a managed fleet for an unmanaged one, and that’s a regression your ops team will feel immediately.

The fix is a control plane built on OpAMP, the open standard for managing collector fleets. LinkMesh is a self-hosted one: every collector reports in with its status, version, and OpAMP mode, and you configure the whole fleet from a visual builder instead of editing files per node. It renders and validates config centrally and pushes it out — the OneAgent’s fleet-management experience, but for open-standard collectors you own.

Crucially, the telemetry never routes through the control plane — it flows straight from your collectors to your backend and stays on your infrastructure. LinkMesh only manages configuration.

Step 4 — Escape the pricing model, not just the agent

The reason many teams start this migration is the bill. Host units and DDUs meter you on how much you monitor and how much data Davis touches — so cost climbs with your estate and your usage, often unpredictably. OpenTelemetry breaks that in two ways:

• The backend becomes a choice. OTLP data can go to a cost-appropriate backend — self-hosted, open-source, or a cheaper managed OTLP store — instead of one vendor’s consumption meter.
• The pipeline cuts volume before it’s billed. Filter noise, sample high-volume streams, and drop unused attributes at the collector, so you only pay to store what you use. That’s the cost-reduction playbook applied to a Dynatrace exit.

And the tool that manages the pipeline shouldn’t reintroduce a consumption meter of its own. LinkMesh is priced per managed collector, not per host unit, DDU, or gigabyte — a flat, predictable line instead of a curve that tracks your growth.

Keep a rollback plan through the whole migration

Progressive decoupling only stays safe if you can reverse any step:

• Keep the OneAgent installed on a host class until that class has passed validation for an agreed observation period — don’t uninstall on first success.
• Decouple the exporters. The OTel path and the OneAgent are independent, so you can pull one host class back onto Dynatrace without disturbing the rest.
• Define success thresholds — metric tolerance, trace coverage, priority alerts firing — so “retire the OneAgent here” is a decision against criteria, not a hunch.
• Retain the ability to redirect. Keeping an otlphttp exporter pointed at Dynatrace’s OTLP ingest API (/api/v2/otlp — HTTP only, no gRPC) as a fallback route means you can send OTel data back to Dynatrace if a backend gap appears mid-migration.

Step 5 — Retire the OneAgent where OTel covers it

Cut over deliberately. As each service or host class hits parity in the new stack — and you’ve confirmed you’re not losing a OneAgent-only capability you actually rely on — remove the OneAgent from it and let the OTel stack stand alone. Do it in waves, non-critical services first, so the safety net stays under the parts that matter longest. Where you still need RUM, synthetics, or Smartscape, keep the OneAgent (or a replacement) for exactly that and let OTel own the standard telemetry — decoupling doesn’t have to be all-or-nothing.

As the OneAgent footprint shrinks, you’ve changed category, not just vendor: your instrumentation is OTLP, your fleet is managed on OpAMP, and your backend is a line item you can renegotiate or replace without re-instrumenting a single host.

The migration in five moves

1. Scope honestly — decide which OneAgent-only capabilities (RUM, synthetics, Smartscape, deep PurePath) you keep, replace, or drop.
2. Instrument in parallel — add OTel SDKs and Collectors alongside the OneAgent.
3. Validate parity — run both stacks, work the checklist, keep rollback ready.
4. Manage the fleet — put an OpAMP control plane over the collectors so you don’t regress on manageability.
5. Retire the OneAgent where OTel covers it — cut over in waves, and drop off the host-unit / DDU meter for the telemetry you’ve moved.

The OneAgent’s bundle was the lock-in on the collection layer. Unbundling it into open standards is the exit — done honestly, capability by capability.