Dynatrace vs. Dash0: moving from OneAgent to OTel without losing context

A team is gradually moving Java services from OneAgent instrumentation to OpenTelemetry. The first service sends traces to the new backend, but its former slow-request view included process, method, and host context. The new view contains a few HTTP calls. Telemetry is arriving, yet the investigation has changed.

This is a useful way to understand Dynatrace versus Dash0. Dynatrace offers OneAgent-based depth on supported technologies and also accepts OTel. Dash0 organizes data, queries, and dashboards around OTel telemetry. Choosing an open instrumentation path is an application decision; replacing an established analysis and response process is another decision.

Guance Editorial Team · Reviewed October 21, 2026. This documentation-based guide covers Dynatrace SaaS/DPS and Dash0. Examples explain coverage and consumption; we did not deploy both products or benchmark performance or costs.

Establish where the existing evidence comes from

OneAgent capabilities vary by operating system, runtime, version, and monitoring mode. Full-Stack Monitoring includes distributed tracing, code-level visibility, CPU and memory profiling, and process monitoring on supported technologies. Basic host discovery is not the same scope as deep application monitoring. Support matrix, Full-Stack scope

A migrated trace containing only HTTP spans may indicate missing database, threading, or business-operation instrumentation. Resource collection may be missing too. Successful trace delivery does not establish complete replacement. Conversely, installing OneAgent does not guarantee identical coverage across every technology.

Dash0 instrumentation and Collectors can reduce manual work, but supported languages and collection paths still need to be selected. Its Python distribution guide distinguishes a local Collector from direct export, where the regional ingress, authorization header, and dataset settings matter. The backend cannot reconstruct business operations that were never instrumented or context that was never propagated. Dash0 ingestion example

Coexisting instrumentation is more than sending two copies

Keeping OneAgent while adding an OTel SDK is a common transition. It needs an explicit decision about which path records each operation.

Dynatrace's OneAgent Span Sensor can capture supported OTel API calls and incorporate them into its own traces. Those spans are treated as OneAgent data. Exporting them through OTLP to the same backend at the same time can create duplicates, and language/version-specific interoperability limits also apply. OneAgent with OTel, Sensor configuration

If request counts double, identify the collection paths before interpreting the chart as business growth. Routing one existing OTel stream from a Collector to two backends differs from two instrumentation systems independently generating spans. Routing adds queues, retries, traffic, and consumption; duplicate instrumentation can also alter the apparent trace structure.

Dash0 datasets introduce another boundary. Logs and traces that should correlate need to share a dataset, and the token must have write access. Seeing data somewhere in the organization does not mean it belongs to the same investigation context. Datasets

Preserve what the error-rate alert actually means

Dynatrace queries, service entities, problem handling, and notification rules do not export automatically with OTLP. Migrating an order-failure alert means preserving its denominator: all requests, retained spans, or a particular class of error records.

Dash0's Query Builder supports PromQL and can turn queries into check rules or dashboards. Logs and spans can also be analyzed as synthetic metrics derived on demand. The expression must still preserve the intended meaning; PromQL support does not make a differently defined query equivalent. Query Builder, synthetic metrics

Error percentage provides a concrete example. Dash0's tracing-query documentation uses a value between zero and one, displayed as a percentage in the interface. Check thresholds use that zero-to-one scale too. Entering 5 when the intended threshold is 5% can leave a rule silent. This is a units problem, not something an analytical model can substitute for correct configuration. Tracing query examples

Perses dashboard definitions can be exported and used in compatible systems. Data sources, queries, access controls, and notification arrangements still require work. An open format improves portability without eliminating platform migration costs. Dashboards and Perses

More memory and more requests affect different meters

Host-based Dynatrace DPS Full-Stack Monitoring consumes memory GiB-hours, measured in 15-minute intervals. Physical and virtual hosts have a 4 GiB minimum and RAM is rounded up in 0.25 GiB increments. Application-only container monitoring has different scope and calculation rules, so it should not be treated as one universal fixed host price. DPS consumption

Doubling host memory can change that consumption even without doubling requests. Trace ingestion, logs, and other capabilities have their own allowances and meters. The rate card and actual usage determine the total; a claim that a particular product is appropriate above 500 hosts has no general basis.

Dash0 splits telemetry consumption into ingestion and storage by signal count. Suppose 10,000 active metric series export every 30 seconds for 30 days. That produces 864 million data points. Using the current base rates of $0.020 per million for ingestion and $0.180 for storage, retaining them all gives:

864 × ($0.020 + $0.180) = $172.80

This example uses the published 13-month metric retention and excludes other signals, tiering, and contractual differences. New label combinations and faster export intervals increase sample counts. No host-based line item does not mean adding hosts has no indirect effect on the bill. Dash0 pricing

Reducing noise also removes potential evidence

Under current Dash0 pricing, SignalControl filtering avoids storage charges for discarded signals, while ingestion is still metered on data entering the service. Published base log and span rates are $0.060 per million for ingestion and $0.540 for storage with 30-day retention. Treating filtered received data as entirely free understates consumption.

Dropping logs or spans used by a synthetic metric can also change future investigations and aggregates. Sampling reduces retained volume and the requests available for individual inspection. What survives an incident should not be determined solely by a normal month's cost chart.

AI has separate boundaries too. Agent0 currently consumes credits, and Dash0's code-analysis product has per-user pricing. Early signal-only descriptions do not define all current products. Dynatrace analysis likewise depends on sufficient data and context; this guide does not rank either vendor's root-cause accuracy from a demonstration.

Time windows create another common false difference. Historical traces in the old platform, data just starting to reach the new one, and the alert evaluation window may not cover the same interval. A partly empty first-hour chart need not indicate lost ingestion; duplicated instrumentation during coexistence need not indicate more real failures. Fix the time and request scope before interpreting the charts.

Judge code-level evidence by the job it performed. Database and external-call spans may be enough for one team, while another regularly needs CPU profiles to identify hot code. Replacing those profiles with a request timeline loses useful evidence. Complete feature parity is not always necessary, but frequently used capabilities should not disappear merely because the new screen contains data.

The old system can leave when the new one can take the pager

Dash0 fits teams with established OTel conventions and investigations centered on logs, traces, and PromQL. The appeal is the relationship between collection, the data model, and team skills—not automatic transfer of every historical asset.

Keeping Dynatrace makes sense where OneAgent's code, process, and resource evidence is central to incident response, or where existing technologies still lack equivalent OTel coverage. A bounded group of services can move first while the rest continues to use a valuable existing path.

A migration is ready when the on-call engineer can find the failing request, understand its resources, and receive the right notification. Historical lookups, permissions, and escalation must still work before the old route is stopped. Lower spending is less useful if it creates an investigation gap.

Connecting OTel data to Guance

Guance's OpenTelemetry integration provides another backend path. Reuse supported instrumentation service by service and check whether logs and traces still connect through a familiar incident.

Attributes, sampling, and permissions remain necessary, as do service and transition-period costs. Choose the platform around continuing investigation and operating work, not solely the presence of an open-protocol label.