01 · Definition
APM measures how an application behaves and helps explain why
Application performance monitoring (APM) is the practice of continuously measuring the health, speed, and reliability of software applications, then using that telemetry to detect problems, find their cause, and verify improvements.
The acronym is also expanded as application performance management. The two meanings overlap. Monitoring is the data collection: request rates, errors, latency distributions, traces, logs, and dependency data. Management is what you do with it: set expectations, respond to degradations, prioritize performance work, and check that releases made the system better.
APM is application-centered. Infrastructure monitoring might tell you a node is using 90% of its CPU. APM tells you whether checkout requests are slower, which service or endpoint is affected, and whether CPU is the cause or merely happening at the same time.
How APM, observability, and distributed tracing differ
| Practice | Primary question | Typical data |
|---|---|---|
| APM | Is the application healthy, and what is affecting its performance? | Service metrics, operations, traces, errors, dependencies, releases |
| Observability | Can we understand the internal state of the whole system from its outputs? | Explorable, high-context traces, logs, metrics, events, and profiles |
| Distributed tracing | What happened to this request as it crossed services? | A trace made of timed parent and child spans |
Modern APM sits inside a broader observability practice and relies heavily on distributed tracing. A dashboard can reveal a slow service. A trace can show the database call that consumed 842 ms. A correlated log can explain that the call waited for a connection.
02 · Why it matters
Users experience one request. Your system executes a chain of work.
A user clicks “Pay” once. Behind that action, a gateway authenticates the request, an application service validates the cart, inventory and pricing services respond, a database transaction commits, and a payment provider authorizes the charge. The user sees one wait and one outcome. Any of those steps could be where the wait or failure started.
Without APM, teams often discover a problem through a support ticket and debug it by checking tools one at a time. Each team sees its own slice. APM gives every team the same view, from user impact down to the technical cause.
Detect before the complaint
See regressions in the tail
Average latency can stay flat while the slowest 1% of requests becomes painful. Percentiles and error rates expose that degradation while there is still time to act.
Shorten the search
Go from symptom to cause
Service maps, operation breakdowns, and trace waterfalls reduce the number of plausible causes instead of asking every team to prove its component is healthy.
Ship with confidence
Compare releases with the same signals
Version and deployment context lets a team see whether a change moved latency, error rate, or resource consumption. If it did, the team can roll back knowing why.
Protect the experience
Connect reliability to user impact
A technically “up” application can still be unusably slow. APM measures what users actually experience, so targets track that.
03 · The operating loop
How APM works
APM is an ongoing loop: instrument the application, collect and correlate its signals, summarize health, investigate exceptions, and use the result to improve the system.
- 01
Instrument the application
Libraries, framework integrations, auto-instrumentation, or manual code create telemetry around inbound requests, internal work, database calls, queues, and outbound dependencies.
- 02
Attach stable context
Attributes such as service name, environment, version, operation, route, region, and status make the data comparable and explorable. Trace and span IDs preserve the relationship between signals.
- 03
Aggregate application health
The backend turns individual measurements into service and operation views: rate, errors, duration percentiles, dependencies, and trends over time.
- 04
Detect and investigate
An alert or anomaly narrows the time and scope. Engineers move from a service chart to the affected operation, then to representative traces, slow spans, errors, and logs.
- 05
Verify the outcome
After a rollback, configuration change, or fix, the same signals show whether performance returned to baseline and whether the user-visible symptom disappeared.
Why OpenTelemetry changes the instrumentation layer
Historically, many APM products required proprietary agents and data models. OpenTelemetry provides vendor-neutral APIs, SDKs, semantic conventions, and the OTLP protocol for producing and exporting telemetry. Its official documentation describes both code-based and zero-code instrumentation, so teams can start automatically and add business-specific spans or metrics where deeper context matters.
Open instrumentation does not choose an APM backend for you. It separates the code that produces telemetry from the platform that stores, queries, visualizes, and alerts on it. Your instrumentation code survives a change of vendor, so switching backends doesn't mean re-instrumenting.
04 · Signals
The core APM signals answer different questions
OpenTelemetry defines traces, metrics, logs, and baggage as supported signals and context. APM is most useful when the backend keeps the links between them, so you can move from one to another.
Summarize behavior across many requests. They are efficient for health views, trends, percentiles, and alerts.
Reconstruct individual requests as timed spans. They show the call path, fan-out, retries, and where duration accumulated.
Record discrete events and details. Trace and span IDs let a log explain the exact operation visible in a waterfall.
Ties data to a service, version, environment, region, tenant, or business operation so teams can isolate who and what changed.
Start with rate, errors, and duration
| Measure | What it tells you | Useful breakdowns |
|---|---|---|
| Request rate | How much work the service is receiving or completing | Service, operation, status, region |
| Error rate | What share of work fails, and whether failures are concentrated | Error type, operation, dependency, version |
| Latency | How long work takes; p50 shows typical behavior while p95 and p99 expose the tail | Operation, status, version, customer tier |
| Saturation | Whether a constrained resource is creating waits | Queue, pool, process, host, container |
Avoid using the average as the only latency signal. A small number of very slow requests can be invisible inside a healthy-looking mean. Keep a distribution or histogram and inspect percentiles that reflect the experience you need to protect. Then use traces from the slow window to explain the tail.
05 · Example
From a p99 alert to one exhausted connection pool
Imagine the checkout API normally serves p99 requests in 240 ms. Ten minutes after a release, p99 rises to 1.4 seconds while the median barely moves. The application is available, most requests are still fast, and an average could understate the problem.
Detect
An alert fires on checkout p99, scoped to production. Request rate is normal, so the change is not explained by a traffic surge.
Scope
The service view shows one operation, POST /checkout, and only the new service version carries the slow tail.
Follow the path
Slow traces share an 800–900 ms database client span. The payment and inventory calls remain near baseline.
Explain
A log on the database span records a connection-pool wait. Pool saturation rose immediately after the release increased per-request concurrency.
Prove
The release is rolled back. Pool wait, database span duration, and checkout p99 return to baseline together.
No single chart answered the question. Each step led to the next: alert to service, service to operation, operation to trace, span to log, and release to a before-and-after comparison. That is what APM looks like in practice.
06 · Evaluation
What to look for in an APM solution
Vendor pages differ in emphasis, but the core capabilities are the same: Datadog highlights service inventory, tracing, errors, databases, and user experience; SigNoz centers service latency, rate, errors, dependencies, and drill-down from metrics to traces; Dash0 emphasizes OpenTelemetry-native service context and correlated telemetry. Test a tool by running those workflows on your own data. Counting features tells you less.
Open instrumentation
Native OpenTelemetry ingestion, standard semantic conventions, and a clear path to export your data.
Service and operation health
Out-of-the-box rate, error, and latency views with filters that match how you own production.
End-to-end traces
Search across high-cardinality attributes, inspect complete waterfalls, and retain the traces that matter.
Dependency context
See databases, queues, caches, external APIs, and upstream or downstream service relationships.
Signal correlation
Move between a metric window, trace, error, and log without manually rebuilding the investigation context.
Release evidence
Attach service versions or deployment events and compare performance before and after a change.
Actionable alerts
Alert on user-relevant signals and keep the filters and time range needed to investigate.
Understandable cost
Know how ingestion, retention, cardinality, hosts, seats, and sampling affect the bill as the system scales.
What APM doesn't cover
Application telemetry can show a slow server request without seeing the browser's DNS lookup, rendering work, or a broken click handler. It can show database duration without replacing query-plan analysis. It can reveal a service failure without explaining the health of the Kubernetes node beneath it. Real user monitoring, session replay, synthetics, infrastructure monitoring, database monitoring, profiling, and security signals cover what sits outside the application.
You don't need every module. Know where each tool's view ends, and keep enough shared context (trace IDs, service names, versions) that an investigation can continue across that line.
07 · First implementation
Start with one important request path
A small APM setup that works end to end is worth more than broad telemetry nobody trusts. Choose one service or user journey that matters, then make sure you can get from a health signal to a root cause for it.
- 1
Name the promise. Define the operation, expected success rate, and latency target from the user's point of view.
- 2
Instrument the boundaries. Capture the inbound request and its database, queue, cache, and external calls with OpenTelemetry.
- 3
Verify the context. Check service name, environment, version, route, status, trace IDs, and error details before building dashboards.
- 4
Build one health view and one alert. Use rate, error rate, and latency percentiles with an owner and an investigation link.
- 5
Run a controlled failure. Add latency or trigger a safe error, then confirm you can detect, scope, explain, and verify it.
APM with Maple
From service health to traces and logs on one OpenTelemetry pipeline
Maple receives standard OpenTelemetry traces, logs, and metrics, then connects them across the service catalog and map, distributed traces, grouped errors, correlated logs, dashboards, and alerts. You instrument once, the telemetry stays portable, and an investigation uses one data model throughout.
Sources and further reading