Observability solutions and companies

Observability is one of the most crowded markets in infrastructure software. There are open-source projects for every layer, a handful of public companies worth tens of billions, a long tail of startups, every cloud provider ships its own suite, and every few months someone buys someone else. For whoever has to pick a stack, or simply understand what the person in the meeting is talking about, the hard part is not finding options. It is knowing what each option actually is, and which ones are competing for the same job.

This post is a map. First, what the job is: the signals and the pipeline that carries them. Then, the standard that reorganized the whole market, OpenTelemetry. Then the open-source stack, layer by layer, followed by the commercial landscape, how vendors charge, where the bills explode, and a practical way to choose.

A warning about the commercial part: this market moves fast. Products get renamed, companies get acquired, pricing pages change every quarter. The categories and trade-offs below age well; specific details should be checked against the vendor’s current documentation.

Monitoring vs. observability

Monitoring answers questions you knew to ask in advance: is the CPU above 90%? Is the error rate above 1%? Is the disk filling up? You define the checks, you set thresholds, you get paged when they are crossed. It works well for failure modes you have already seen.

Observability is the ability to answer questions you did not know you would need to ask, from the outside of a system, without shipping new code. Why are checkout requests from one mobile app version, in one region, against one database shard, slow only since Tuesday’s deploy? No dashboard was built for that question. An observable system lets you slice the data until the answer shows up.

The term comes from control theory, where a system is observable if its internal state can be inferred from its outputs. In software, it became popular around 2016–2018, pushed by people like Charity Majors (Honeycomb) and Cindy Sridharan, as microservices made the old “one server, one dashboard” model collapse. In practice the two words overlap and vendors use them interchangeably. What matters is the capability: rich, correlated, high-cardinality telemetry plus tools to explore it.

The signals

Telemetry is usually described as “three pillars”, although that framing has aged and there are now at least five signals worth knowing.

Cardinality is the concept that explains most observability bills and most outages of observability systems. A metric like http_requests_total{service, method, status} with 20 services, 5 methods and 10 status codes produces at most 1,000 series. Add a user_id label with a million users and you get a billion series. Metrics databases are built to handle many points per series, not unbounded numbers of series. That is why high-cardinality data (user IDs, request IDs, full URLs) belongs in traces and logs, or in tools specifically built for wide events, and not in metric labels.

The modern view, championed by Honeycomb and increasingly adopted by others, is that the pillars are just different projections of the same thing: wide, structured events with many attributes. A span with 50 attributes can be aggregated into metrics, filtered like a log, and assembled into a trace. Several newer backends (Honeycomb, ClickHouse-based stacks, Datadog’s own event store) are built around that idea.

OpenTelemetry: the center of gravity

Until the late 2010s, every vendor had its own agent and its own SDKs. Instrumenting your code with one vendor’s library meant that switching vendors required rewriting instrumentation across every service. Lock-in was not in the contract; it was in the code.

OpenTelemetry (OTel) changed that. It was born in 2019 from the merger of two competing projects, OpenTracing and OpenCensus, under the CNCF, and it is today one of the most active projects in the foundation, second only to Kubernetes in contributors for a long time. Almost every vendor in this post now supports it, and most contribute to it. It is made of a few distinct pieces:

• API and SDKs for the main languages (Java, Go, Python, .NET, JavaScript, Ruby, PHP, Rust, C++, Swift and others), to create spans, metrics and logs in your code.
• Auto-instrumentation: agents and libraries that instrument common frameworks (HTTP servers, database drivers, gRPC, message queues) without code changes. The Java agent is the most mature; there is also a zero-code eBPF-based instrumentation (OBI, which grew out of Grafana’s Beyla donation) that observes processes from the kernel.
• OTLP, the wire protocol (gRPC or HTTP, protobuf or JSON). It is the part that matters most for portability: if your backend speaks OTLP, you can change backends without touching applications.
• The Collector, a vendor-neutral agent and gateway that receives, processes (batching, filtering, sampling, redacting, enriching with Kubernetes metadata) and exports telemetry to any number of destinations. Most vendors also ship their own distribution of it.
• Semantic conventions, the shared vocabulary for attribute names (http.request.method, db.system, k8s.pod.name, and, more recently, gen_ai.* for LLM calls). Boring on paper, essential in practice: they are what lets a backend recognize “this is an HTTP server span” no matter who produced it.

Traces and metrics are stable across the main languages, logs are stable in most, and profiles are the newest signal, still maturing at the time of writing. The practical recommendation is simple: instrument with OpenTelemetry, ship through a Collector, and treat the backend as a replaceable component. That one decision is the biggest lever you have against lock-in.

The pipeline, end to end

Every observability system, open-source or commercial, has the same shape. Knowing the layers is what lets you compare a “platform” with a “stack” of separate tools.

  flowchart LR
  subgraph src["Sources"]
    app["Apps (OTel SDK / auto-instrumentation)"]
    infra["Hosts, Kubernetes, cloud APIs"]
    ebpf["eBPF agents"]
  end
  subgraph pipe["Collection and pipeline"]
    col["OTel Collector / Alloy / Fluent Bit / Vector"]
    route["Filter, sample, redact, route"]
  end
  subgraph store["Storage"]
    m["Metrics TSDB"]
    l["Log store"]
    t["Trace store"]
    p["Profile store"]
  end
  subgraph use["Use"]
    viz["Dashboards and exploration"]
    alert["Alerting, SLOs"]
    oncall["On-call and incident response"]
  end
  app --> col
  infra --> col
  ebpf --> col
  col --> route
  route --> m
  route --> l
  route --> t
  route --> p
  m --> viz
  l --> viz
  t --> viz
  p --> viz
  m --> alert
  alert --> oncall

A commercial platform like Datadog or Dynatrace sells you all of these boxes, with their own agent at the start. An open-source stack assembles them from separate projects. Many real setups are hybrids: open-source collection, a commercial backend for some signals, self-hosted storage for others.

The open-source stack

Collection and pipelines

Metrics

Prometheus is the foundation. Created at SoundCloud in 2012 and the second project to graduate from the CNCF after Kubernetes, it introduced the pull model (scraping /metrics endpoints), the dimensional data model with labels, and PromQL, which became the de facto query language for metrics. Version 3.0, released in late 2024, brought native OTLP ingestion, UTF-8 metric names and a new UI.

A single Prometheus server is not designed for long-term storage or global views across clusters, so a family of projects grew around it, all compatible with PromQL and remote-write:

• Thanos: adds object-storage retention and a global query layer on top of existing Prometheus servers.
• Cortex: the original horizontally scalable, multi-tenant Prometheus.
• Grafana Mimir: Grafana Labs’ fork and evolution of Cortex, the engine behind Grafana Cloud metrics.
• VictoriaMetrics: a separate, very resource-efficient implementation with its own query extensions (MetricsQL); its sibling projects VictoriaLogs and VictoriaTraces cover the other signals (more on the family below).
• M3: built at Uber, the technology that later became the core of Chronosphere.

The Victoria family: metrics, logs and traces

VictoriaMetrics started as a single, fast time series database and grew into a full stack under the Apache 2.0 license. Its selling point across the board is efficiency: less RAM, less disk and fewer moving parts than the alternatives for the same volume, which is why it is popular with teams that self-host at scale.

There is also an enterprise edition (extra features like downsampling and multi-tenant controls, plus support) and a managed offering, VictoriaMetrics Cloud.

Logs

• Elasticsearch and the ELK/Elastic Stack (Elasticsearch, Logstash, Kibana, Beats) defined log search for a decade. Its license change in 2021 led AWS to fork it as OpenSearch, now under the Linux Foundation. Elastic later added AGPL as an option, so Elasticsearch is again open source, but the two lineages remain separate.
• Grafana Loki indexes only labels, not the full text, which makes storage dramatically cheaper and queries over unindexed content slower. It fits well when you already know which stream to look at.
• ClickHouse, the columnar OLAP database, became a popular backend for logs and traces because it compresses well and scans fast. Several products are built on it (see below).
• Newer engines like Quickwit (acquired by Datadog in 2025) and VictoriaLogs target cheaper full-text search over object storage.

Traces

• Jaeger, created at Uber and a CNCF graduated project. Jaeger v2 is built on top of the OpenTelemetry Collector.
• Zipkin, from Twitter, the original open-source tracer inspired by Google’s Dapper paper.
• Grafana Tempo, a trace store that keeps spans in object storage and relies on TraceQL and links from logs and metrics instead of heavy indexing.

Profiles

• Grafana Pyroscope (Grafana Labs acquired Pyroscope in 2023) and Parca (from Polar Signals) do continuous profiling, mostly with eBPF, so you can see flame graphs for production over time.

Visualization and alerting

• Grafana is the de facto open-source dashboarding tool, connecting to almost any data source. Most of the stacks above use it as the front end.
• Perses, a CNCF project for dashboards-as-code with an open specification.
• Alertmanager handles Prometheus alerts: grouping, silencing, routing to email, Slack, PagerDuty and others.

Grafana: OSS, Enterprise and Cloud

“Grafana” means three different things depending on who says it, and the difference matters when you compare prices or licenses.

The backends follow the same pattern: Mimir, Loki, Tempo and Pyroscope are open source (AGPLv3), and Grafana Labs sells self-managed enterprise versions of them alongside the cloud. On top of that, AWS and Azure sell their own managed Grafana (Amazon Managed Grafana, Azure Managed Grafana), which run Grafana but are not Grafana Cloud. The practical rule: start with OSS if you want to self-host and have the people for it, Cloud if you want the LGTM stack without operating it, Enterprise when you self-host but need the commercial plugins, compliance features or support.

All-in-one open-source platforms

If you do not want to assemble six projects, there are open-source platforms that bundle everything, usually with a commercial cloud or enterprise edition behind them:

• SigNoz: OTel-native, built on ClickHouse, covering metrics, logs and traces in one UI.
• ClickStack / HyperDX: ClickHouse acquired HyperDX in 2025 and turned it into its own observability stack on top of the database.
• OpenObserve, Uptrace and Coroot (the last one with a strong eBPF and automatic root-cause angle).
• Netdata: per-second infrastructure monitoring with zero configuration.
• The classics, still running in a huge number of companies: Zabbix, Nagios and Checkmk, focused on infrastructure and network monitoring rather than distributed tracing.

Ten more open-source projects worth knowing

Open-source alerting, on-call and status pages

Collecting telemetry is half the job; the other half is getting the right alert to the right person and telling users what is going on. Alertmanager covers routing for Prometheus, but a lot of open-source tooling has grown around it and around the on-call problem in general.

Grafana Labs also had an open-source on-call product, Grafana OnCall, but its repository was archived in March 2026 and on-call now lives in Grafana Cloud IRM, so GoAlert is the more natural self-hosted choice today.

The commercial landscape

The big platforms

These are the companies that sell the whole pipeline, from agent to on-call, with dozens of products on top.

What separates them in practice:

• Datadog wins on breadth and polish. Everything links to everything: a log line to its trace, the trace to the host, the host to the deploy. The trade-off is cost and a pricing model with many dimensions (per host, per GB, per million spans, per session, per custom metric), which makes bills hard to predict.
• Dynatrace wins on automation. Its agent discovers processes and dependencies on its own and its AI correlates problems into a single root cause. It is opinionated and enterprise-oriented, which some teams love and others find heavy.
• New Relic made its pricing simpler (a free tier, then mostly data volume and user seats) and is a common choice for mid-sized teams wanting a full platform at a more predictable price.
• Splunk is the default where security (SIEM) and logs already live there, and where Cisco is already a strategic vendor.
• Elastic fits where search and logs are the center, especially for teams that already operate Elasticsearch.
• Grafana Labs fits teams that want open standards and the option to self-host, with a managed version when operating it stops being worth it.

The cloud providers

Every cloud has a native suite. It is often the cheapest place to start and almost always the deepest integration with that cloud’s services, but it is weaker across multiple clouds and in cross-signal exploration.

A pattern worth noticing: the clouds increasingly offer managed versions of the open-source stack (managed Prometheus, managed Grafana, OTel distributions) instead of only their proprietary formats. That is OpenTelemetry and PromQL winning in practice.

The challengers

A second layer of companies competes by being better at one thing, cheaper, or architecturally different.

Sentry and SigNoz, a closer look

Two names that come up constantly in teams that start from the code rather than from the infrastructure:

• Sentry started as an open-source error tracker in 2008 and became a company in 2012. Its core strength is the developer workflow: an exception arrives with the stack trace, the release, the commit that probably caused it, the user’s breadcrumbs and, on the frontend, a session replay. It has grown into tracing, profiling, cron and uptime monitoring, but it remains the tool people reach for to answer “what broke in my code?” rather than “what is happening in my cluster?”. It is offered as SaaS and as self-hosted under the Functional Source License (source available, becomes open source after two years).
• SigNoz is an open-source, OpenTelemetry-native alternative to Datadog and New Relic, built on ClickHouse, with metrics, logs, traces, dashboards, alerts and exceptions in a single UI. You can self-host the community edition or use SigNoz Cloud. Because it speaks OTLP natively, moving to or away from it is mostly a change of Collector exporter.

Ten more companies selling observability

Telemetry pipelines

A whole category exists just to sit between the sources and the backends: collect once, then filter, reduce, transform and route data to wherever it is cheapest or most useful. The main reason people buy them is cost: cutting noisy logs before they reach an expensive backend can pay for the pipeline many times over.

• Cribl (Stream, Edge, Search, Lake) is the leader in this category, very popular with Splunk customers.
• Edge Delta, Mezmo and Observo compete in the same space.
• The OTel Collector and Vector are the open-source equivalents, and many teams build exactly this with them.

On-call and incident response

Telemetry is only useful if someone acts on it. This layer handles paging, escalation, incident coordination and post-mortems.

• PagerDuty, the long-time leader in on-call and alert routing.
• incident.io and Rootly, Slack-native incident management that grew fast in the 2020s.
• Atlassian Opsgenie has stopped being sold to new customers and Atlassian is moving its users into Jira Service Management and Compass, so anyone still on it has a migration on the calendar.
• Most big platforms (Datadog, Grafana Cloud, Splunk) now bundle their own on-call and incident features.

LLM and AI observability

The newest category. Applications built on language models fail in new ways: a call succeeds with HTTP 200 and still returns a wrong or harmful answer, costs vary by tokens rather than by requests, and an “agent” can take dozens of steps before producing anything. Tools here capture prompts, completions, token counts, latency, cost and evaluation scores for each step.

• Langfuse (open source), Arize Phoenix (open source), LangSmith (from LangChain), Helicone, Braintrust, Weights & Biases Weave and Traceloop/OpenLLMetry are among the specialized tools.
• Datadog, Dynatrace, New Relic, Elastic and Grafana all added LLM monitoring to their platforms.
• OpenTelemetry has GenAI semantic conventions, so LLM calls can be traced like any other span, which should keep this category from becoming another lock-in island.

A market built on acquisitions

A short and incomplete timeline helps explain why so many products today are bundles of formerly independent companies.

Two forces drive this. Platforms want to cover more signals and more use cases (security, product analytics, AI) under one contract. And security vendors are buying observability, because logs and runtime data are what both disciplines run on. The line between “observability” and “security operations” is getting thinner every year.

How vendors charge, and where bills explode

Observability is notorious for bills that grow faster than the infrastructure they watch. Every vendor uses some mix of these units:

The most-cited example is the roughly US$65 million Datadog bill mentioned on Datadog’s own earnings call in 2023, widely reported to belong to Coinbase. It is extreme, but the dynamic behind it is common: nobody owns the cost of telemetry, so everybody emits as much as possible.

What actually keeps cost under control:

• Sampling traces. Head sampling (decide at the start of a request) is cheap; tail sampling (decide at the end, keeping all errors and slow requests) is smarter and is available in the OTel Collector.
• Filtering at the pipeline. Drop health-check logs, debug levels and duplicated fields before they reach a paid backend.
• Turning logs into metrics. If you only ever count a log line, emit a counter instead.
• Tiered storage. Keep a short hot window for fast search and archive the rest in object storage, rehydrating only when needed.
• Watching cardinality. Review new metric labels like you review database schema changes.
• Showback. Report telemetry cost per team or per service. Behavior changes as soon as the cost has an owner.

How to choose

There is no best tool, only a best fit for a team’s size, budget, skills and existing contracts. Some honest heuristics:

Small team or startup. Do not operate an observability stack yourself; it is a product in its own right. Use a managed service with a generous free tier (Grafana Cloud, New Relic, Honeycomb, SigNoz Cloud, Better Stack, or your cloud’s native suite), instrument with OpenTelemetry, and revisit the decision when the bill starts to hurt.

Mid-sized company, cost-conscious, comfortable with Kubernetes. The open-source stack becomes attractive: Prometheus or VictoriaMetrics for metrics, Loki or a ClickHouse-based tool for logs, Tempo or Jaeger for traces, Grafana on top, everything fed by the OTel Collector. Budget for at least part of a team to run it. The software is free; the engineers, the storage and the 3 a.m. pages are not.

Large enterprise, many teams and technologies. A full platform (Datadog, Dynatrace, Splunk, New Relic, Elastic) often pays for itself in time saved, standard workflows and support contracts, as long as someone owns governance and cost. Put a pipeline (Collector or Cribl) in front of it from day one, so you keep the ability to negotiate or migrate.

Regulated industry or strict data residency. Look at self-hosted options, vendors that run inside your own cloud account (groundcover, Kloudfuse, some Grafana and Elastic deployments), and the data-processing locations of any SaaS before signing.

Whatever you choose, a few principles hold:

1. Own your instrumentation. OpenTelemetry in the code, OTLP on the wire. The backend should be a decision you can revisit.
2. Own your pipeline. A Collector layer between applications and vendors is cheap insurance against both lock-in and runaway cost.
3. Start from questions, not from data. Define SLOs for what users care about (latency, errors, availability of key journeys) and collect what you need to explain violations of them. More data is not more observability.
4. Test the investigation, not the demo. During a trial, take a real past incident and see how long it takes to find the cause in each tool.
5. Calculate the bill at your real scale. Ask for pricing on your current volume and on twice that. The difference between vendors often only appears at the second number.

Where it is going

A few trends are visible across the whole market:

• OpenTelemetry everywhere. Proprietary agents are not disappearing, but vendors increasingly compete on what they do with the data rather than on how they collect it.
• eBPF for zero-code visibility. Network flows, latency per request and profiles collected from the kernel, without touching applications.
• Profiling as the fourth signal. Continuous profiling linked to traces, so you can go from “this request was slow” to “this function was the reason”.
• Columnar storage and object storage. ClickHouse, Parquet and S3-style storage are pushing the cost per GB down and forcing incumbents to rethink pricing.
• AI in the investigation loop. Every platform now has an assistant that summarizes incidents, writes queries in natural language and proposes root causes. Useful when the data is good, misleading when it is not; it does not replace instrumentation.
• Observability and security converging. The same telemetry feeds detection and response, and acquisitions reflect that.

Directory of links

Everything mentioned in this post, in one place.

Open source

Commercial

Closing

Under all the brand names, the job is the same: get signals out of systems, move them somewhere affordable, and turn them into answers fast enough to matter when something breaks. The tools that last are the ones that respect that job and do not trap your data. Pick a stack that fits your team today, keep instrumentation and pipelines in open standards, and treat telemetry like any other production system, with an owner, a budget and a purpose.