What Dynatrace shows you that logs do not
Logs tell you what one service was thinking. Distributed tracing tells you where the time went across all of them, which is usually a different story.
Most teams have logs. Fewer have tracing. The gap between them is where a surprising number of production mysteries live.
Logs answer the wrong question
A log line tells you that a service did something, and when. To reconstruct a slow request from logs you have to find the corresponding lines in six services, line up timestamps from machines whose clocks disagree slightly, and infer causality.
People do this. It takes hours, and it only works when someone already suspects where to look.
Tracing answers "where did the time go"
A distributed trace shows the actual span tree for one request: which service called what, how long each leg took, and where the gaps are. The answer is usually visible in seconds rather than reconstructed over an afternoon.
The recurring surprise is that the slow part is rarely the part anyone suspected. It is a chatty ORM making 200 queries where one would do, or a retry policy quietly tripling load on a struggling downstream.
What automatic instrumentation buys
The reason we reach for Dynatrace on larger estates is the OneAgent model: you get service topology, dependencies and traces without asking every team to instrument their code first. On a system with a dozen services owned by different people, that difference is what makes the rollout finishable.
Once the map exists, service flow shows you the dependency you did not know you had - which is frequently the one causing the incident.
Then set SLOs
Traces tell you what is happening. Service level objectives tell you whether it matters. Without them, every dashboard is just numbers, and alerting drifts toward paging humans for things nobody would act on at 3am.
Instrument, then set an objective, then alert on the objective. In that order.