APM Transaction Tracing
Instrumentation that attributes application latency and errors to specific code paths, database queries and external calls, usually with automatic tracing.
APM occupies the layer between infrastructure metrics and code-level profiling: it tells you which transaction is slow and which part of it consumed the time — a query, an external call, or application logic — usually without manual instrumentation.
What it gives that generic telemetry does not: automatic transaction traces with code-level attribution; database query analysis identifying slow and frequently-executed statements, which is where a large share of application latency actually lives; error grouping with stack traces and request context; and a dependency map derived from observed calls rather than documentation.
Where it stops: APM samples transactions, so it is weak on rare events; it attributes time to a span but not to a function, which is what continuous profiling adds; and its automatic instrumentation covers common frameworks well and bespoke code poorly.
The overlap with OpenTelemetry is now substantial and worth deciding deliberately. Instrumenting with OTel and exporting to an APM backend preserves the ability to change vendors, whereas a vendor agent produces richer automatic data at the cost of re-instrumenting everything if you leave. For most estates the portability is worth more than the last increment of automatic depth.