Executive Summary
Decide three things before comparing products: how telemetry will be collected, who will store and query it, and which unit the bill counts.
Application performance monitoring (APM) and observability describe overlapping jobs, and most products in this guide sell both. APM tracks the speed, errors and availability of the applications you already know to watch. Observability is the wider ability to ask new questions of the telemetry those applications emit, including questions nobody planned for. The OpenTelemetry project states that observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings.
Three decisions shape the shortlist. The first is collection: a vendor's own agent, the open-source OpenTelemetry toolkit, or both. The second is the backend that stores and queries the data, which OpenTelemetry deliberately leaves to others. The third is the unit the bill counts: hosts, gigabytes, users, events or a committed consumption budget. The same estate can cost very different amounts under each.
This guide answers the APM vs observability question first, then sets out the capabilities to test, seven approaches to buying, the eight vendors that represent them, and how each pricing model grows with your estate.
Why Telemetry Volume Decides the Cost
Observability spend grows with the data a system emits, not with the number of people who look at it. Every new service, container and attribute adds telemetry. CNCF TAG Observability states that every efficient metric storage backend or vendor scales with metric cardinality, and that the true cost grows with cardinality. Cardinality is the number of unique time series a metric produces. A label such as a user ID or a container ID can multiply it by millions.
Collection is also no longer tied to the vendor that stores the data. The OpenTelemetry project describes OpenTelemetry as an observability framework and toolkit designed to facilitate the generation, export and collection of telemetry data such as traces, metrics, and logs. The OpenTelemetry project states that OpenTelemetry is not an observability backend itself. Instrumenting with OpenTelemetry lets you change the backend later without rewriting the code that produces the data. Vendors also sell their own agents, and some features work only with them.
The practical result is that observability is now bought in two parts: a collection layer you can standardize, and a backend you rent or run. The backend sets most of the bill, so the purchase turns on how each backend counts usage and what it lets you drop, sample or keep cheaply.
Ownership has changed across the field. Several of the platforms below are now part of larger security or infrastructure companies, and the vendor section records each change with its source. Ask every vendor how its observability product is packaged and priced today, because bundles change after an acquisition.
APM vs Observability: What Is the Difference?
APM is the older practice. IBM defines application performance management (APM) as a practice that uses software tools, data analysis and application management processes to help organizations optimize the performance, availability and user experience of business applications. IBM states that application performance monitoring tools focus exclusively on monitoring and represent only one aspect of APM. In practice, an APM tool instruments application code, records each transaction and its timing, and alerts when response times or error rates cross a threshold.
Monitoring of this kind answers questions you defined in advance. Google SRE defines monitoring as collecting, processing, aggregating, and displaying real-time quantitative data about a system, such as query counts and types, error counts and types, processing times, and server lifetimes. Google SRE states that the four golden signals of monitoring are latency, traffic, errors, and saturation. Those signals tell you that something is wrong. They do not always tell you why.
Observability is aimed at the why. The OpenTelemetry project states that observability allows you to easily troubleshoot and handle novel problems, that is, unknown unknowns. CNCF TAG Observability states that monitoring is sometimes called a system that can detect known unknowns, as opposed to observability, which emphasizes being able to find and reason about unknown unknowns as well. Honeycomb states that observability is about being able to ask arbitrary questions about your environment without having to know ahead of time what you wanted to ask.
The difference is about architecture as well as vocabulary. IBM describes APM as a precursor to observability solutions. IBM states that while the APM approach used to be sufficient for high-quality application management, it is ill-equipped for the job of managing distributed apps and services with multiple runtimes and multiple layers. IBM states that traditional monitoring solutions rely on agents deployed throughout the application environment to sample performance-related metrics at regular intervals, as frequently as once every minute. In a system of many small services, a single slow request can pass through dozens of them. The OpenTelemetry project states that a distributed trace records the path taken by a single request as it propagates through multiple services in an architecture.
For a buyer, APM is now one capability inside an observability platform, not a separate purchase. Every platform in this guide includes distributed tracing and application dashboards. The choice is how much raw, detailed data a platform keeps and lets you query, and what that costs. A platform built for APM summarizes early and keeps aggregates. A platform built for observability keeps more detail and charges for it in a different unit.
| APM | Observability | |
|---|---|---|
| Question it answers | Is this application fast and available, and which transaction is slow? | Why is the system behaving this way, including in ways nobody predicted? |
| Typical data | Transaction traces, response times, error rates, service maps | Metrics, logs and traces correlated, with high-cardinality attributes kept for querying |
| How you use it | Dashboards and threshold alerts on known indicators | Ad hoc queries across any attribute, comparison of failing and healthy requests |
| Instrumentation | Vendor agent per application, often automatic | Vendor agent or OpenTelemetry, often both |
| What drives cost | Hosts or applications monitored | Data volume, cardinality and retention |
How do you evaluate APM & Observability Platforms?
Collection comes first. Test how each platform instruments your languages and runtimes: automatic instrumentation from an agent, OpenTelemetry SDKs, or both. Ask which features work only with the vendor’s agent, and whether data sent over the OpenTelemetry protocol (OTLP) lands in the same views as agent data. The OpenTelemetry project states that OpenTelemetry is a Cloud Native Computing Foundation (CNCF) project that is the result of a merger between two prior projects, OpenTracing and OpenCensus.
Storage and query set what you can ask. Some platforms keep every span and log line; others sample or aggregate on the way in. Ask what is kept at full detail, for how long, and how fast a query across a week of data returns. Check the query language too, since engineers will write alerts and dashboards in it and migration means rewriting them.
Correlation is the observability promise. A trace should link to the logs written during that request and to the metrics of the host that served it. Test this on a real incident from your own history, not on the vendor’s demo application.
Cost controls decide whether the platform stays affordable. Look for sampling rules, filters that drop data before it is billed, limits per team, and usage reports that attribute spend to a service or team.
AI features are now standard and vary widely in maturity. Ask what the assistant can do without a human approving each step, what data it reads, whether it runs on regulated or government regions, and how it is billed.
| Capability | What it does | Buyer translation |
|---|---|---|
| Automatic instrumentation | Discovers processes and instruments them without code changes | Time to first trace on your own services, and which runtimes are covered |
| OpenTelemetry ingest | Accepts OTLP traces, metrics and logs | Which features work on OpenTelemetry data and which need the vendor agent |
| Distributed tracing | Follows one request across services | Whether every trace is kept or a sample, and who chooses the sample |
| High-cardinality query | Filters and groups by attributes with many values | Cost and speed when you group by customer, region or build |
| Correlation | Links traces, logs and metrics for one event | Clicks from an alert to the log line that explains it |
| Cost governance | Sampling, filtering, budgets, usage attribution | Whether you can cap spend per team before the invoice arrives |
Vendors in APM & Observability Platforms
Representative vendors include Chronosphere (Cortex XCOR), Datadog, Dynatrace, Elastic Observability, Grafana Labs, Honeycomb, New Relic and Splunk Observability. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
The approaches below follow two questions: how does the platform collect and store telemetry, and what unit does it bill? Two vendors share the full-stack suite approach.
The full-stack suites sell many products on one platform. Datadog states that the Datadog Agent is software that runs on your hosts, collects events and metrics and sends them to Datadog, and is open source. Datadog states that Single Step Instrumentation installs the Datadog Agent and instruments your application in one step, with no additional configuration steps required. Datadog describes Bits AI as an agentic teammate built to automate development, security, and operational workflows, to which you can delegate tasks like alert investigations, code fixes, or security triage. New Relic states that its language agents harvest data and store it in the New Relic Database (NRDB). New Relic describes NRQL, short for New Relic query language, as a SQL-like tool for accessing detailed data from New Relic. New Relic announced that Francisco Partners and TPG have completed their all-cash acquisition of New Relic.
The single-agent approach puts one agent on each host and a unified data store behind it. Dynatrace states that a single OneAgent per host is required to collect all relevant monitoring data. Dynatrace describes Grail as the Dynatrace data lakehouse designed explicitly for observability data, a single unified storage solution for logs, metrics, traces, events, and more. Dynatrace states that Dynatrace Intelligence applies deterministic, causation-based analysis across applications, services, infrastructure, logs, and traces.
The next approach sits inside a larger data and security company. Cisco announced on March 18, 2024 that it completed the acquisition of Splunk. Splunk lists Splunk Observability Cloud, AppDynamics and IT Service Intelligence (ITSI) under Splunk Observability. Splunk states that Splunk APM collects and analyzes every span and trace from each of the services connected to Splunk Observability Cloud.
Search-based observability stores telemetry in a search engine. Elastic states that Elastic Observability combines logs, metrics, application traces, user experience data, and more into a single, integrated platform. Elastic states that metrics can be ingested using OpenTelemetry, Prometheus remote write, or Elastic Agent integrations, and queried with ES|QL or Prometheus Query Language (PromQL). Elastic announced that Elasticsearch and Kibana can be called Open Source again, and that it would add AGPL as another license option next to ELv2 and SSPL.
The open-source stack keeps a separate store for each signal. Grafana Labs describes Loki as a horizontally scalable, highly available, multi-tenant log aggregation system using the same data model as Prometheus. Grafana Labs describes Grafana Tempo as a distributed tracing backend. Grafana Labs describes Mimir as an open source, horizontally scalable, highly available, multi-tenant TSDB for long-term storage for Prometheus. Grafana Labs announced on April 20, 2021 that its core open source projects would move from the Apache License v2.0 to AGPLv3. Grafana Labs describes Grafana Alloy as an open source telemetry collector and an OpenTelemetry Collector distribution with built-in Prometheus pipelines.
Two vendors are built around high-cardinality data. Chronosphere states that Chronosphere Metrics is purpose-built to manage high-volume and high-cardinality metric data generated by containerized microservices architectures. Palo Alto Networks announced on January 29, 2026 that it has completed its acquisition of Chronosphere. Palo Alto Networks describes Cortex XCOR as the next-generation observability platform, built on Chronosphere's foundation, and states that existing Chronosphere customers can continue to use the platform as they always have. Palo Alto Networks states that Cortex XCOR evaluates incoming telemetry against actual usage, that teams apply central Optimization Rules to drop, roll up or sample data upstream, and that Consumption Budgets enforce team caps. Honeycomb states that its high-cardinality, event-based foundation lets engineers query production data in real time, with no sampling tricks and no preaggregation. Honeycomb describes Refinery as a tail-based sampling proxy that operates at the level of an entire trace.
| Vendor | Approach | Where it fits |
|---|---|---|
| Datadog | Full-stack SaaS suites | Open-source agent, per-host and per-GB products, Bits AI agents |
| New Relic | Full-stack SaaS suites | Language agents and NRDB, billed on data ingested and users |
| Honeycomb | High-cardinality event analysis | Event-based queries on any attribute, priced by event volume |
| Splunk Observability | Observability within a security and data company | Splunk Observability Cloud and AppDynamics, owned by Cisco |
| Grafana Labs | Open-source observability stack | Grafana, Loki, Tempo and Mimir, self-run or as Grafana Cloud |
| Elastic Observability | Search-based observability | Logs, metrics and traces on Elasticsearch, queried with ES|QL or PromQL |
| Dynatrace | Single-agent platform with causal analysis | OneAgent per host, Grail data lakehouse, consumption subscription |
| Chronosphere (Cortex XCOR) | Telemetry control for cloud-native metrics | Metrics and traces with usage-based data reduction; now Cortex XCOR from Palo Alto Networks |
Eight vendors across seven approaches; Datadog and New Relic share one. The approaches were written before any vendor was selected, and a row in this table is not for sale. Cloud providers’ own monitoring services and other commercial and open-source tools also compete here, and any observability vendor can make its own case in the Spotlight below.
How much should you budget for APM & Observability Platforms?
Observability is priced on five different units: hosts, gigabytes ingested, users, events and committed consumption. Most vendors combine two or more. Model your own estate in each vendor’s unit before comparing totals.
Per-host pricing grows with infrastructure. Datadog lists Infrastructure Pro at $15 per infra host, per month, billed annually, and $18 billed month-to-month or on demand. Datadog lists log ingestion at $0.10 per ingested GB, per month. Splunk lists Splunk Observability Cloud starting at $15 per host per month for Infrastructure, $60 for App & Infra and $75 for End-to-End, billed annually. Splunk offers Observability Cloud free for up to 15 hosts.
Data and user pricing grows with volume and headcount. New Relic states that it bills for data by the amount of GB ingested, no matter the type, and that 100 GB ingested per month is free. New Relic states that the count of billable users is a billing factor. Elastic lists ingest for logs, traces, synthetics, RUM and other data as low as $0.07 per GB ingested.
Event pricing grows with traffic. Honeycomb lists a Free plan with an event volume of up to 20M per month, and a Pro plan with up to 750M events per month starting at $150 per month. Ask how each event-priced vendor counts an event, since a deep trace on a busy service can produce many per request.
Committed consumption trades flexibility for a contract. Dynatrace describes the Dynatrace Platform Subscription (DPS) as a consumption-based licensing model with an agreement of typically 1–3 years and a minimum annual commitment. Dynatrace states that once the annual commitment is reached, you can continue to use Dynatrace while incurring on-demand usage with no overage premiums.
Self-run open source has no license fee for the software. Its cost is the compute and storage for each data store and the engineers who scale, upgrade and back it up. Price that team before comparing it with a hosted bill.
| Meter | You are charged for | Grows with | Where it goes wrong |
|---|---|---|---|
| Per host | Each monitored host or container host, per product | Infrastructure size and products enabled | Autoscaling adds hosts at peak, and each product bills again |
| Per GB ingested | Data volume sent and stored | Log verbosity, trace depth, retention | A debug log level left on in production |
| Per user | People with full access | Headcount with access | Engineers given basic access and unable to debug |
| Per event | Spans and log events received | Request volume and trace depth | High-traffic services without sampling |
| Committed consumption | A yearly minimum drawn down by usage | All usage against one rate card | Commitment sized on a pilot, not production |
| Active series | Unique metric time series | Label cardinality | A label with user or container IDs |
How long does implementation take for APM & Observability Platforms?
An observability rollout is an instrumentation project with a budget attached. Set the collection standard and the cost controls before broad rollout, because retrofitting sampling and filters after the first invoice means changing every service twice.
List services, languages, runtimes and current monitoring tools. Decide where OpenTelemetry is the standard and where a vendor agent is allowed, and agree naming and attribute conventions.
Instrument a representative slice on two finalists. Replay past incidents, measure time to cause, and record projected monthly cost at production volume.
Set sampling, filtering and retention rules and per-team budgets first, then roll out by service tier. Run old and new tools side by side until alerts match.
Move alerts to service level objectives where possible, review unused dashboards and data quarterly, and retire the old tools once on-call teams have switched.
What should you ask vendors about APM & Observability Platforms?
Ask each vendor to answer in writing and to demonstrate on your own services, traffic and incidents.
-
Do your teams mainly need service dashboards and alerts on known indicators?Yes Shortlist APM-centered products and compare on languages covered, automatic instrumentation and per-host or per-application cost.No Shortlist platforms that keep detailed traces and attributes, and test them on questions you have not asked before.
-
Is metric cardinality or log volume already your largest cost?Yes Weight sampling, filtering, usage attribution and pre-storage data reduction above feature breadth.No Compare on correlation across signals and the time each platform takes to find the cause of a replayed incident.
-
Must you be able to change backends without re-instrumenting?Yes Standardize on OpenTelemetry collection and confirm which features each vendor supports on OpenTelemetry data.No Weigh the vendor agent’s automatic instrumentation against the cost of leaving it later.