One Agent, Zero Code Changes: What Dynatrace's PurePath Actually Buys You

Instrumenting a dozen services by hand is the part of observability nobody budgets for. Every new service needs an SDK wired in, every framework upgrade risks breaking spans, and the team that owns the slowest service is usually the one with the least instrumentation. Dynatrace's bet is that a single host agent should do that work for you — and its PurePath traces are the payoff. This post looks at how that model works, walks a reproducible demo, and covers where it falls short.

The thesis: topology plus traces beats telemetry volume

Most APM tools can collect traces. Dynatrace's distinguishing move is that OneAgent — a single agent installed per host or deployed as a Kubernetes operator — auto-discovers processes (Java, .NET, Node.js, Go, web servers, database clients) and injects tracing without code changes. From that data it builds two things at once:

• Smartscape, a live dependency map of hosts, processes, services, and their call relationships.
• PurePaths, end-to-end distributed traces stitched across service hops, down to individual SQL statements.

The practical consequence: when something breaks, Dynatrace's Davis engine doesn't just fire per-metric threshold alerts. It groups symptoms against the topology and opens a single problem card with a suspected root cause. Treat that card as a well-formed hypothesis, not ground truth — Davis output is probabilistic — but it collapses an alert storm into one starting point, which is often the difference between a ten-minute and a two-hour triage.

A worked example you can reproduce

You can validate the whole pipeline on a trial tenant with a small Kubernetes cluster and any demo app that talks to a database (a sample microservices app works fine). Nothing here was run against your environment — treat it as a checklist to execute yourself.

1. Deploy the Dynatrace Operator. In your cluster, with cluster-admin permissions, apply the operator from Dynatrace's documented manifest, then create a DynaKube custom resource pointing at your tenant URL and an API token with the ingest scopes the documentation lists. The operator rolls OneAgent into your nodes and injects it into application pods.
2. Confirm discovery. Within minutes, your services should appear in Smartscape with no code changes. If a service is missing, the usual culprits are an unsupported runtime version or a pod that predates the injection webhook — restart the workload first.
3. Generate load. Run a simple loop against the demo app's entry endpoint, e.g. while true; do curl -s http://<app-url>/checkout > /dev/null; sleep 1; done from any machine that can reach the service.
4. Walk a PurePath. Open a slow request and follow it: HTTP entry at the web tier, a call into the order service, then individual SQL statements with timings. The trace should show you which hop owns the latency, not just that the request was slow.
5. Trigger a fault. Add an artificial delay to one query (or throttle the database container). Check whether Davis opens one problem card naming the database or the calling service as the suspected cause, rather than a pile of separate alerts.

If steps 2 and 4 work, the core value proposition is real in your stack. If Davis's card points at the wrong component, that's useful information too — it tells you how much to trust automated root cause in your architecture.

The trade-off: convenience versus control

OneAgent's deep auto-instrumentation is a closed, commercial agent. Licensing is consumption-based (per-host or per-volume depending on the model), and pricing and packaging change often enough that you should get current numbers from Dynatrace rather than from any blog — including this one. Depth also varies by language and framework version: mainstream stacks get full visibility, while exotic or very new runtimes may only get partial tracing.

The vendor-neutral alternative is OpenTelemetry: you instrument with open SDKs, own your span semantics, and can ship the same telemetry to multiple backends — Dynatrace ingests OTLP data, so it's not either/or. The honest comparison:

	OneAgent / PurePath	OpenTelemetry SDKs
Instrumentation effort	Near zero; automatic	Per-service code and config
Depth (SQL, methods)	Deep on supported stacks	Depends on instrumentation libraries you add
Portability	Tied to Dynatrace	Vendor-neutral, multi-backend
Topology + causal AI	Built in (Smartscape, Davis)	You assemble it in your backend

A hybrid is common: OneAgent where it's supported, OpenTelemetry for runtimes it misses or for teams that insist on owning their instrumentation.

One caveat: the platform is mid-transition

Dynatrace is moving log and event analytics toward the Grail data lakehouse and its DQL query language, so screenshots and menu paths age quickly, and some capabilities exist in both classic and newer interfaces. Verify any UI-specific instructions against the current documentation before following them.

What to do next

Spin up a trial, run the five-step demo above, and answer two questions with evidence: does auto-discovery cover your actual runtimes, and does a single Davis problem card correctly localize a fault you planted? If yes to both, the licensing conversation is worth having. If your stack is heavily OpenTelemetry already, run the same demo with OTLP ingest and compare the traces side by side — that comparison, done in your own environment, is worth more than any feature matrix.