When does APM tell you something that distributed tracing and metrics cannot?

What is being tested

Whether you can place the three tools correctly rather than treating them as interchangeable observability products.

The division of labour

Metrics tell you that something is wrong. Cheap, aggregated, long-retained, and structurally unable to explain anything — a metric has already discarded the individuality of every event that produced it.

Distributed tracing tells you where — which service, which hop, which call in the tree. It spans services and shows the gaps between them.

APM tells you what happened inside one service: time in the framework, in the ORM, in serialisation, in garbage collection, waiting on a connection pool, and — most usefully — in which specific query.

A profiler goes one level further: which function, called from where, at a granularity APM's sampling cannot reach.

What APM finds that the others do not

• N+1 patterns, detected automatically by recognising the same query shape repeated within a request. This is the highest-value automatic finding in most applications, and it is invisible in the database's slow query log because each query is fast.
• Runtime behaviour — garbage collection pauses, thread pool saturation, connection pool waits. Neither metrics nor tracing captures these well, and they frequently dominate p99.
• Error aggregation — grouping stack traces so a hundred occurrences of the same bug appear once with a count.
• Framework overhead — time spent in middleware, serialisation and ORM materialisation, which is often a surprising share and is attributed to "the service" by any external measurement.

The costs to state

Overhead, typically a few percent and occasionally much more with aggressive instrumentation. Measure it on your workload rather than accepting the vendor's figure.

Cost that scales with hosts and volume, which becomes material and drives teams to sample so aggressively that the tool stops answering the questions it was bought for.

Vendor coupling. Proprietary agents in every service are hard to remove. Instrumenting with an open standard and exporting to a vendor backend preserves the option to change, at small extra cost at adoption time.

The practical sequence during an investigation

Metrics alert → trace identifies the service and the hop → APM attributes the time inside that service → profiler if it is still not clear. Each step narrows by roughly an order of magnitude, and skipping a step usually means guessing.