Dynatrace vs. Uptrace: preserve evidence when tracing moves

An overnight batch finishes half an hour late. Its slowest span is a database call, but the engineer on duty still needs to explain the delay. Did a query change? Was work waiting for a connection? Did another process on the host consume the available resources? Finding the trace begins that investigation; it does not complete it.

Both Dynatrace and Uptrace accept OpenTelemetry data. The useful distinction is the evidence available beyond existing instrumentation, and who keeps it available. A team with well-structured application telemetry has a credible reason to evaluate Uptrace. A team that relies on OneAgent's runtime visibility should first identify what would disappear with the agent. This comparison uses public documentation checked on October 21, 2026. References to Dynatrace Grail and DPS concern the SaaS offering; they should not be assumed to describe Managed deployments.

Follow the slow call into its context

Uptrace is more than a trace waterfall. Its current platform includes logs, metrics, dashboards, and alerts, with a PromQL-compatible route for metrics. An engineer can group batch operations, inspect latency distributions, open a problematic request, and examine relevant logs and resource metrics. Those other signals still have to be collected: sending application spans does not automatically instrument a host or database. Uptrace features

For example, this illustrative query groups error spans by service and calculates their P95 duration within the selected time range. It is a syntax example, not a result from a production test:

group by service_name | p95(_dur_ms) | where _status_code = 'error'

Uptrace normalizes the attribute service.name to service_name; _dur_ms is measured in milliseconds. The result describes selected error spans, not the P95 of all user requests. A request can contain several spans, so investigating the batch entry point also requires an appropriate operation and span-kind filter. Span query reference

Uptrace also builds a Service Graph from span relationships. Missing service names or client/server and producer/consumer relationships can leave edges absent. If a queue appears disconnected, inspect message context propagation and instrumentation at both ends before concluding that no traffic reached the consumer. A graph is a representation of the received evidence. Service Graph requirements

Dynatrace often earns its place in the next part of the investigation: relating the request to process, runtime, and infrastructure evidence. OneAgent's coverage depends on the operating system, language, framework version, and monitoring mode. Teams that have used that evidence to diagnose garbage collection, thread behavior, or process failures should preserve the investigative capability during migration, rather than merely compare trace counts. OneAgent support matrix

An OTLP endpoint does not make the evidence identical

Dynatrace supports OpenTelemetry, so this is not a compulsory choice between a proprietary agent and an open protocol. A useful first step is to route one service through a standard export path and compare its service identity, environment, parent relationships, and log trace IDs. Where OneAgent already captures OTel spans, an additional exporter can introduce duplicates. Its documented coexistence configuration matters. Dynatrace OTel ingestion, OneAgent and OTel

Sampling changes the visible system too. Head sampling decides before the complete outcome is known and cannot guarantee retention of every request that later fails. Tail sampling can use later span status or duration, but needs stateful processing capacity. Identical percentages in two pipelines need not preserve the same slow jobs. Record incoming requests, exported spans, and retained error examples alongside the resulting charts. OpenTelemetry sampling

For the late batch, the acceptance test is a concrete sequence: find the database wait, locate the retry log for that job, and explain the resource behavior during the wait. If one step formerly depended on OneAgent and has no replacement data source, record the gap. Protocol compatibility alone does not close it.

Self-hosting means operating more than one process

A self-hosted Uptrace deployment includes its application binary and several supporting systems. ClickHouse stores telemetry, PostgreSQL holds users, projects, and dashboards, and Redis supports caching and background-job coordination. Docker Compose, Helm, and Ansible options simplify installation. They do not remove responsibility for capacity, backups, or recovery after an upgrade. Self-hosted architecture

That responsibility becomes visible during an incident. If ingestion starts backing up while the batch is failing, someone must distinguish an application slowdown from an observability-backend slowdown. Growing log storage and a failed database upgrade both create operational work. Existing ClickHouse expertise helps, but it does not make an additional production system costless.

Edition boundaries matter as well. Uptrace's current self-hosted editions separate the community core from paid collaboration, security, and operational capabilities. Community lists 14-day retention; paid editions offer custom retention, Team includes RBAC, and Business includes SSO. Listed usage tiers are evaluated over a 30-day average. Match corporate login, retention, and availability requirements to the actual edition rather than assigning every Cloud or commercial feature to the free deployment. Uptrace editions

Price the same workload and the same evidence

Dynatrace DPS Full-Stack Monitoring is measured in GiB-hours, rather than a uniform host-hour charge. The calculation uses monitored host memory, with a 4 GiB minimum, upward rounding in 0.25 GiB increments, and 15-minute billing intervals. Logs and other capabilities have separate consumption dimensions. An ephemeral batch machine therefore produces a different usage profile from an otherwise similar host that runs all month. Full-Stack billing

Uptrace Cloud currently meters logs and traces by data volume and metrics by ingested datapoints. Collection frequency affects metric volume, and server-side dropping also carries a processing charge. Its public pricing page contains conflicting starting-rate and budget-cap descriptions. Confirm the applicable terms rather than promising a hard spending ceiling or a fixed savings multiple. Uptrace Cloud pricing

Build estimates from the same workload: host memory and running time on one side, actual signal output, retention, and query needs on both. Add databases, backups, and operational work to the self-hosted option, and relevant network transfer charges to a Cloud option. A cheaper estimate is meaningful only if it still preserves the failure evidence the team needs.

Choose the responsibility you want to own

Uptrace deserves a close evaluation where OTel instrumentation is already mature, control over telemetry storage matters, and the team can operate the supporting databases. Its Cloud offering provides another route for teams that prefer not to own those systems, with retention and budget terms assessed separately.

Dynatrace is a stronger starting point to retain and optimize when investigations routinely depend on automatically collected runtime detail and existing service-to-infrastructure context. Company size does not decide the outcome. The better question is whether the on-call engineer can explain the same incident after the change, and what maintaining that investigation path will cost.

Check correlation with one real request

When evaluating Guance alongside these options, use the same batch request to inspect timing, errors, and related logs in trace details. Correlation depends on collection and identifier configuration; a different query screen cannot restore missing spans. That exercise reveals ingestion differences more directly than comparing dashboard counts. Guance trace details