tool

Application Performance Monitoring

also called APM

Instrumentation that attributes latency and errors to code paths and dependencies inside a service — the layer between metrics and a profiler.

apmprofilingtracingperformancetooling

Definition

APM tools instrument an application at runtime to break a request down into its internal components: time in the framework, in the database, in external calls, in serialisation, in garbage collection. Where tracing shows time between services, APM shows time inside one.

What it is good at

  • Attributing latency within a service. "80% of this endpoint's time is in one query" is immediately actionable.
  • Finding N+1 patterns, which it detects by recognising the same query shape repeated within a request — the highest-value automatic finding in most applications.
  • Surfacing slow dependencies including ones nobody documented.
  • Error aggregation — grouping stack traces so a hundred occurrences of the same bug appear once.
  • Runtime behaviour — garbage collection pauses, thread pool saturation, connection pool waits — that neither metrics nor tracing captures well.

What it is not

A replacement for distributed tracing, which spans services, or for a profiler, which attributes time to individual functions at a granularity APM's sampling cannot reach. The three overlap and none substitutes for the others.

The costs

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

Cost that scales with hosts and volume, which becomes material and frequently 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 difficult to remove. Instrumenting with an open standard and exporting to a vendor backend preserves the option to change, and is worth the small extra effort at adoption time.

Failure scenarios

  • Installed and never used, because nobody was taught what it answers.
  • Sampling so aggressive that the pathological request is never captured.
  • Overhead unmeasured, so the monitoring is a meaningful share of the latency it reports.
  • Alerting configured on every automatic anomaly, producing noise that trains people to ignore it.
  • Only in production, so performance regressions are found by customers rather than in staging.

Interview question

"When would APM tell you something that distributed tracing and metrics would not?"