Skip to content
Knowledge Hub/Article
Article

What Is APM? How Application Performance Monitoring Works

APM measures how an application performs as users see it: latency, errors, traffic and saturation. How it works, traces, observability and tool selection.

Oğuzhan Gerçek··5 min read
What Is APM? How Application Performance Monitoring Works

Short answer: APM (application performance monitoring) is the discipline and class of tools that continuously measure how an application performs as the user experiences it: how long requests take, what share of them fail, how much load there is, which component is choking. It does not stop at server monitoring's "CPU at 40 percent"; it says "the checkout page has returned 3 percent errors in the last ten minutes and the latency is in the database query". Today's APM tools collect metrics, logs and traces together; that combination is called observability, and APM is the part of it that looks at the application layer.

What is APM?

Classic monitoring looks at infrastructure: is the server up, is the disk full, what is the network latency. APM looks inside the application: it records the code path of every request, the calls to external services, the database queries and their durations. It does this with an agent or library added to the application (instrumentation); the agent marks requests, measures durations and sends them to a central system. What emerges is the numerical counterpart of the user experience: which transaction is slow, who is affected and in which layer the cause lies.

The four golden signals

The best-known answer to the question of what to measure comes from Google's SRE book. According to the Monitoring Distributed Systems chapter, the four golden signals of monitoring are latency, traffic, errors and saturation, and if you can only measure four metrics of a user-facing system, you should focus on these four:

  • Latency: The time it takes to service a request; the latency of successful and failed requests is tracked separately.
  • Traffic: The demand placed on the system; for a web application, requests per second.
  • Errors: The rate of requests that fail; explicit failures (HTTP 500) and "successful" requests that return the wrong content.
  • Saturation: How "full" the service is; the utilization of the most constrained resource.

A good APM dashboard shows these four per service, in percentiles (p50, p95, p99); average latency hides most problems.

How APM works: metrics, logs and traces

Modern APM rests on three kinds of data. Metrics are numbers in time series (request count, latency, error rate). Logs are event records; they say what happened, details in the log article. A trace is the path a request follows through the application: in OpenTelemetry's definition, "the path of a request through your application". A trace shows every step (span) from the front end to the API and on to the database, each with its duration; only a trace can tell you that 1.8 of a request's 2 seconds were spent in a single query.

On the collection side, OpenTelemetry has become the industry standard: the application is instrumented once, the data is sent to whichever tool you choose, and the code does not change when the tool does. How distributed tracing and metric collection are set up with Prometheus and Grafana is in the observability article.

The difference between APM and observability

APM focuses on application performance; observability combines metrics, logs and traces for the whole stack and answers the question "why is this system behaving like this". In practice APM is the application layer of observability; infrastructure metrics, network and security logs sit outside it. How to build the three together is in our observability service.

What APM delivers

  • Fast root cause: Which service, which query or which external call the problem sits in becomes visible within minutes.
  • Service level indicators: Latency and error rate are tied to an SLO; the alert says "the error budget is running out" instead of "CPU is high".
  • Capacity decisions: Saturation data shows which component to scale and when.
  • Deployment validation: The latency and error curve after a new release puts the rollback decision on data.
  • Cost: When needless calls and slow queries surface, the cloud bill drops too.

What to look for in an APM tool

  • Language and framework support: Is there automatic instrumentation for the languages you use, and native OpenTelemetry support?
  • Data volume and cost: Is the price tied to agent count or data volume; can sampling be tuned?
  • Retention: How many days traces are kept; can a problem be investigated after the fact?
  • Deployment model: SaaS or in your own environment; where the data resides can matter under KVKK.
  • Alert quality: Noisy alerting ends up the same as no alerting; can SLO-based alerts be built?
  • AI-assisted correlation: Is there an AIOps layer that links events together?

Frequently asked questions

What does APM mean? Application performance monitoring: tools and methods that measure an application's latency, error rate, traffic and saturation from the user's point of view.

What is the difference between APM and monitoring? Classic monitoring looks at infrastructure (server, disk, network); APM looks inside the application (request, query, external call). The two complement each other.

Are APM and observability the same thing? No. Observability combines metrics, logs and traces for the whole stack; APM is the part of it that focuses on the application layer.

What is a trace? The path a request follows inside the application, with the duration of every step (span). It shows which step the slowness is in.

Does APM require code changes? In most languages automatic instrumentation works without code changes; a few lines are added for business-specific measurements. With OpenTelemetry this is done independently of the tool.

Which applications need APM? Every user-facing application that carries revenue or operations: e-commerce, mobile back ends, ERP integrations, APIs. For small internal tools, tracking the golden signals with metrics may be enough.

Sources