topic What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ? in Dashboarding

What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ?

mukeshurmaliya — Mon, 12 Oct 2026 11:34:57 GMT

I would like to understand the technical advantages and challenges, if OTel instrumentation is used in place of Oneagent for a distributed application with synchronous and asynchronous calls to different internal and external applications hosted on cloud, containerized infra and onpremise setup.

Would operationally it be more challenging to deploy and manage Otel setup? and also creating entity relations, traces, and smartscapes be as efficient with OTel as with Oneagent?

Re: What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ?

dylan_taelemans — Mon, 12 Oct 2026 11:20:55 GMT

To give a brief comparison:
traces:

PurePath (OneAgent) automatically provides:

Detailed code-level visibility, including method calls, database queries, exception stack traces, and asynchronous operations.
Automatic correlation with infrastructure and platform context, linking traces to hosts, Kubernetes pods, processes, and cloud services without additional code changes.

OpenTelemetry offers a flexible, vendor-neutral approach, but the level of detail depends on the instrumentation and metadata provided. Achieving similar visibility and making full use of Dynatrace Intelligence may require additional development and ongoing maintenance.

Metrics =>

The same principle applies to metrics. Dynatrace automatically provides a range of metrics, built-in visualisations, and topology information linked to the relevant processes and hosts. With OpenTelemetry, you have more control/responsibilities over the data you collect, but you may need to configure the collection, export, and visualisation of that data yourself and provide necessary metadata to create the topology.

That said, you don't have to choose one over the other. Personally, I prefer combining both: let Dynatrace handle its native monitoring and creating topology and use OpenTelemetry to enrich the traces with additional information or ingest some missing metrics. This way, you get the best of both worlds. 😉

Re: What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ?

gschramm — Mon, 12 Oct 2026 11:18:33 GMT

I am currently in a situation where we are comparing oneagent to otel. We just started, but some things you want to consider:

oneagent can be updated remotely vs. OTEL libaries require it's own update strategy
changing configuration can be done in the UI for oneagents, for OTEL you need to do this in the parameter, which also means you need to have access to the machine (or some deployment automation that allows to make these changed)
Our application is not distributed, so I can't speak to how it works across process / host boundaries.
the traces we are getting from OTEL are great (Java application, with JMS and JDBC), very similar to what we get from the oneagent. Creating services was easier with OTEL, you literally name the services in the parameters. Oneagent auto-detects them and needed some manual rules to be human readable.
Most of the application is short lived batch jobs, that the worst case for any observability tool since instrumentation needs to happen every time the batch is started. So far our test have shown quite some advantaged for the oneagent when it come to "instrumentation overhead" (watch the CPU usage here). When batches are started the machines CPU is quickly maxed out using OTEL. With oneagent we only hit the 100% briefly and only if a lot of jobs are started simultaneously.

What we are still working on:

having the OTEL process show up on the oneagent (infrastructure mode) host in smartscape. So far they were seperate from the infrastructure. This is most likely just a config issue.
ootb the oneagent does not create the same traces as we have with OTEL. I was actually very puzzled by this, could be that the JDBC lib we are running is too outdated or something else is off.. we are still investigating this.

Cost wise we are running both version, oneagent infrastructrure mode + OTEL vs . oneagent fullstack, for a week and then compare the numbers.

I hope this helps for now.

Re: What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ?

Julius_Loman — Mon, 12 Oct 2026 18:44:58 GMT

Regarding cost - it also differs if you run Dynatrace SaaS or Managed (both DPS and Classic). SaaS and Managed have different sampling strategies on the cluster.

Re: What are the specific gains and losses if instead of Oneagent, OTel instrumentation is used ?

Julius_Loman — Mon, 12 Oct 2026 18:52:54 GMT

Some pros for OTEL:

Immutability - OneAgent does instrumentation at runtime, while with OpenTelemetry you typically have build-time instrumentation (well, except for the otel java agent), but mostly you are not affected by any runtime configurations. So an application has the same instrumentation, and instrumentation-wise it behaves equally across environments. With Dynatrace, you might have different OneAgent features set in different environments and all the instrumentation happens in run-time.
There will still be some libraries and frameworks where Dynatrace won't have support. One of the most requested ones is the Quarkus SmallRye library for example. More here.

With OneAgent on the other side, you get coverage in other areas such as bizevents, profiling or live debugger.