What does the Dynatrace OneAgent do to a running application, and what does it still not see?

## One agent for the host, not one library per service Dynatrace's OneAgent is installed on a **host** — a virtual machine, a bare-metal box, or as a node-level component on a container platform — and is not added to any application's dependency list. Once running it enumerates the processes on that host, classifies them by technology, and keeps watching as processes come and go, so a container scheduled onto that node forty minutes later is picked up with nobody doing anything. That is the difference that surprises engineers arriving from a per-application agent: the unit of deployment is the machine, so the coverage question becomes *"is this host onboarded?"* rather than *"did this team add the library?"*. For a managed runtime such as the JVM or .NET, code-level visibility comes from the agent loading its own instrumentation into the process, and that happens **as the process starts**. A freshly onboarded host therefore reports CPU, memory, disk, network and process lifecycle immediately, but shows no method-level timings for services that were already running until they are restarted. Teams that miss this conclude on day one that the agent "does not work". Some compiled languages need a build-time step or a linked library instead, which is worth confirming before promising fleet-wide coverage. ## What arrives without anyone writing code Once instrumentation is in the process, the agent recognises the frameworks and clients inside it and instruments their boundaries: - **Inbound entry points** — the request handlers of recognised web frameworks, so each request becomes an end-to-end traced transaction (Dynatrace calls one a PurePath). - **Outbound calls** — database clients, HTTP clients, remote-call libraries and message-broker clients, which supply the caller-to-callee edges that stitch one trace across several processes. - **Code-level timing inside the process** — which methods on the request path consumed the time, at a granularity nobody had to anticipate in advance. - **Host, container and process signals** — utilisation, limits, restarts, and the lifecycle of every process on the box. - **Observed connections** — which process talks to which, including to components nobody instrumented at all. - **Log files written by the processes it already knows about**, which is how log lines land on the same entities as the traces. The property that makes this more than a pile of signals is that everything is keyed to the same entities: a slow request, the process that served it, the container it ran in and the host underneath are one connected model rather than four disconnected dashboards. ## Where the automation stops Automatic capture answers *what happened and how long it took*. It does not answer *what it meant*. | Question about a request | Captured automatically | Needs instrumentation you write | |---|---|---| | How long did the call take? | yes | — | | Which method burned the time? | yes, on supported runtimes | — | | Which process called which? | yes, from observed connections | — | | Was this a school lunch-order submission? | no | span attribute or custom metric | | Was the allergen list on the order correct? | no | business metric or validation event | | Did this queue consumer's work belong to that request? | often not | explicit context propagation | | What is happening in an unsupported runtime? | process-level signals only | your own telemetry | The recurring blind spots are worth naming explicitly, because they are the ones that cost hours: 1. **Asynchronous handoffs.** A request that ends by putting a message on a queue and a consumer that picks it up eight seconds later are two traces unless the handoff is recognised or you propagate context yourself. 2. **Unrecognised protocols and runtimes.** A custom binary protocol between two services shows as an observed connection with timing, not as a stitched call with parameters. 3. **Batch and scheduled work.** There is no inbound request to hang a trace on, so the automation has nothing to anchor to. 4. **Meaning.** The agent can tell you a call took 812 ms; it cannot tell you that the call was the only path by which 8,900 pupils get a meal booked, or that the response was fast and wrong. ## What that means in practice On a school-meal ordering estate of 47 hosts, onboarding gave the team an accurate map and full request timings within a day of restarts, and it genuinely removed the "please add the tracing library" negotiation from forty teams. What it did not remove was the need for a small number of hand-written signals: an attribute marking which requests are order submissions, a counter for accepted orders per minute, and an explicit link across the menu-import job's queue handoff. Those three additions are what later made an incident explicable that nobody could account for from the existing dashboards, in an estate whose metric store already held 2.3 million series. The honest summary for an interview is: automatic instrumentation buys you breadth, uniformity and coverage of things you would never have instrumented by hand — and it buys you none of your domain. Breadth is exactly what a platform can automate; meaning is exactly what it cannot.