Safeguard
Research•

What is application performance monitoring and what should it track?

Application performance monitoring turns traces, metrics and logs into answers about slow or failing requests. See what to measure and how to start small.

Safeguard Security Team
4 min read

Application performance monitoring (APM) is the practice of collecting telemetry from running software, mainly traces, metrics and logs, so you can tell whether it is doing what users expect and find out why when it is not. Good APM answers "what is slow, for whom, and where" without redeploying code.

What data does APM collect?

The OpenTelemetry project describes observability as the ability to understand a system from the outside by asking questions about it, without knowing its inner workings. For that to work, application code has to emit signals: traces, metrics and logs.

Metrics are aggregations of numeric data over time, such as error rate, CPU use and request rate. A log is a timestamped message from a service or component. A trace follows one request as it moves through the services that handle it, built from spans, where each span is a single unit of work with a start time, an end time and attributes.

Is uptime the same as performance?

No, and the OpenTelemetry primer makes the point with a shopping example. A system can be up all the time and still be unreliable if clicking "Add to Cart" for black shoes sometimes adds something else. Reliability asks whether the service does what users expect.

That is why the primer talks about service level indicators (SLIs) and service level objectives (SLOs). An SLI is a measurement of behavior from the user's point of view, such as how fast a page loads. An SLO attaches one or more SLIs to a target the organization agrees on. Without a target, a graph is just a graph.

Why do traces matter more as systems split up?

Distributed tracing lets you watch a request cross service boundaries. The primer says it is essential for distributed systems because they commonly have nondeterministic problems or are too complicated to reproduce locally. If a checkout call takes four seconds, the trace shows whether the time went to your code, the database, or a downstream API.

A constructed example

A small team runs a web app with an API and a payment service. Support reports that checkout "sometimes hangs". The metrics dashboard shows normal average latency. That is the trap with averages: a slow tail hides inside a healthy mean.

The team filters traces for checkout requests longer than three seconds. Every one of them waits on the payment service, and inside it, on a single call to an external provider with no timeout. The fix is a timeout and a retry limit, plus an SLO on checkout latency measured at the 95th percentile. None of that required guessing, because the trace carried the evidence.

What does APM have to do with security?

Telemetry is also a security data source. Unusual request rates, new error patterns and unexpected outbound calls can show up in the same signals. The flip side is that telemetry often contains sensitive data. Request attributes can pick up tokens, email addresses and query strings if nobody decides otherwise. Decide what is allowed in an attribute before you turn collection on.

How to check or apply this

  1. Pick the two or three user journeys that matter most, such as sign in and checkout, and write one SLI for each.
  2. Set an SLO for each SLI with a number the team will actually defend.
  3. Instrument with a vendor neutral standard such as OpenTelemetry so you can change backends without re-instrumenting.
  4. Make sure each service propagates trace context to the services it calls, otherwise your traces will break at the first hop.
  5. Review which attributes and log fields can carry personal data or credentials, and strip them at collection time.
  6. Alert on SLO burn, not on every spike, so people trust the pager.
  7. Keep the data retention period short enough that you can justify it.

Quick check

What is the difference between a trace and a log?

A log is a timestamped message that is not necessarily tied to a request. A trace follows one request across services as a set of spans.

Do I need all three signals to start?

No. Start with metrics for the user journeys you care about, add traces where you cannot explain a slow request, and keep logs for detail.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.