Elastic APM (application performance)
Elastic APM is the application-performance-monitoring component of the Elastic Stack, collecting transactions, spans, errors, and metrics from instrumented services and storing them in Elasticsearch for analysis in Kibana. This page describes its data model and privacy posture even-handedly, without ranking it against other APM tools.
What this means
Elastic APM uses language agents to instrument services, capturing transactions, distributed-trace spans, errors, and metrics, then ships them to Elasticsearch where Kibana visualizes service maps, latency, and error rates.
Because it is part of the Elastic Stack, APM data sits alongside logs and metrics in the same store, enabling correlation across signals.
Data model and posture
The model stores transactions and spans (the trace), errors, and metrics as documents in Elasticsearch, queried and visualized in Kibana. Traces tie related operations across services together.
Because agents can capture request details — headers or bodies — sanitization and field-masking settings determine what reaches storage. Posture depends on agent configuration, index retention, and access controls in the stack.
- Agents capture transactions, spans, and errors
- Stored in Elasticsearch, viewed in Kibana
- Correlates with logs and metrics
- Agent sanitization controls captured data
How it appears in analytics and logs
Elastic APM in a stack means agents send transaction traces, spans, and errors to Elasticsearch, so it covers backend application performance rather than per-user web behavior.
Diagnostic use case
Use Elastic APM to trace application transactions, capture errors, and measure service performance, analyzing the data in the Elastic Stack you may already run for logs and search.
What WebmasterID can help detect
WebmasterID covers first-party traffic; Elastic APM covers backend application performance and traces, a different layer of the same request lifecycle.
Common mistakes
- Capturing request bodies without sanitizing sensitive fields.
- Treating APM traces as user-behavior analytics.
- Ignoring index retention, letting trace data grow unbounded.
Privacy and accuracy notes
Traces and captured request bodies can include personal data, so agent sanitization settings matter. This is educational, not legal advice.
Related pages
- Kibana and Elasticsearch analytics
Elasticsearch is a distributed search and analytics engine that indexes documents (often logs and events) for fast search and aggregation; Kibana is its visualization and exploration UI, providing dashboards, search, and observability views. Together (with ingest tools, the 'Elastic Stack') they are widely used for log, search, and observability analytics rather than web-traffic reporting.
- New Relic Browser monitoring
New Relic Browser is the front-end monitoring component of the New Relic observability platform, capturing real-user page timings, errors, and AJAX/resource performance, and correlating them with backend telemetry. This page describes its observability data model and privacy posture even-handedly, distinct from web analytics, with no ranking.
- OpenTelemetry for analytics
OpenTelemetry (OTel) is a CNCF standard and SDK set for generating and exporting traces, metrics, and logs in a vendor-neutral format. While built for observability, its instrumentation and collector can also feed behavioral and performance analytics. This page describes the data model and privacy posture even-handedly, not as a ranked product recommendation.
- Website observability
Request-level signals across the page lifecycle.
Sources and verification notes
- Elastic — APM documentationVendor docs on agents, traces, and storage in Elasticsearch.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.