APM

APM (Application Performance Monitoring) is the practice — and the tooling — of measuring how an application behaves internally: how long requests take, which database queries dominate that time, how often errors occur and where exactly they originate. Where infrastructure monitoring watches CPU and memory, APM watches the code itself, turning a vague "the site feels slow" into a specific, fixable diagnosis.

How APM works

APM starts with an agent or instrumentation library embedded in the application, increasingly based on the open OpenTelemetry standard. The instrumentation records every transaction — typically an HTTP request or a background job — and splits it into spans: time spent in the controller, in each SQL query, in calls to external APIs, in cache lookups. Collected data flows to an analysis backend that aggregates it into dashboards and alerts. The core capabilities include:

• Distributed tracing — following a single transaction across multiple services, essential in microservice architectures;
• Metrics — response-time percentiles (p95, p99), throughput, error rate and satisfaction scores such as Apdex;
• Error tracking — full stack traces captured with the request context that produced them;
• Alerting — notifications when a metric crosses a threshold or drifts from its baseline.

Practical application

The classic APM win: after a release, checkout latency doubles. A trace immediately shows an ORM issuing hundreds of queries in a loop — the N+1 problem — or a missing index turning a 5 ms lookup into 800 ms. Without APM, that hunt means hours of guesswork in server logs. Popular options range from SaaS platforms (New Relic, Datadog, Sentry) to self-hosted stacks built on Grafana, Tempo and Prometheus, which teams often run on their own VPS to keep telemetry in-house.

APM is one leg of the wider observability triad alongside logs and metrics, and it pairs naturally with external uptime monitoring: the outside probe raises the alarm, and the inside trace tells you which line of code to fix. Agents are engineered for low overhead and usually sample requests, so the performance cost of watching your application is a small fraction of the cost of not watching it.