The observability market has consolidated significantly over the past few years, but "consolidated" doesn't mean "simple." Datadog, Grafana Cloud, New Relic, Honeycomb, Dynatrace, and a collection of newer entrants are all competing for the same budget line. Meanwhile, OpenTelemetry has matured to the point where vendor lock-in is significantly reduced — you can instrument once and ship to any backend.
If you're evaluating your observability stack — whether you're greenfield, cost-optimizing, or hitting limits of your current tooling — this is the state of the landscape and the framework I use to make the decision.
The Observability Maturity Model
Before evaluating tools, it's worth being honest about what you actually need. Most organizations sit in one of three maturity bands:
Band 1: Reactive observability. You have metrics (probably Prometheus or CloudWatch), logs (probably CloudWatch Logs or ELK), and you look at them when something goes wrong. No SLOs, minimal dashboards, no tracing. The bottleneck isn't tooling — it's practice and process. Buying better tooling won't fix Band 1 problems.
Band 2: Proactive observability. Defined SLOs, dashboards that surface the right metrics, structured logging, distributed tracing for critical paths. Alert noise is managed. On-call engineers have the context they need during incidents. Most mature engineering organizations are here or aspiring to be here.
Band 3: AI-augmented observability. Anomaly detection, ML-driven alerting, automated incident investigation, correlation across signals without manual joining. This is where the industry is heading, and it's what the major vendors are competing on in 2026.
Match your tooling choice to your maturity band. A Band 1 organization buying a Band 3 platform will spend money on features they won't use while the fundamental practice gaps remain.
The Major Platforms, Honestly Assessed
Datadog
Datadog's strength is integration breadth and unified correlation. 700+ integrations, everything in one place, and the UX for correlating a metric spike → relevant logs → distributed trace is genuinely excellent. For organizations with complex stacks and teams that need to investigate across many services, the out-of-the-box experience is hard to beat.
The tradeoffs: Datadog's pricing is aggressive and scales non-linearly. Custom metrics pricing, log indexing pricing, and APM host pricing can combine in ways that produce unpleasant billing surprises. At scale, Datadog can become one of your top-5 infrastructure costs. This is a real consideration, not a minor footnote.
Datadog's AI features (Watchdog anomaly detection, AI-assisted alert correlation) are ahead of most competitors. If you're targeting Band 3 observability, Datadog's ML layer is meaningfully useful, not just marketing.
Best for: Mid-to-large engineering organizations with complex stacks, where the unified correlation value outweighs the cost. Budget should be explicitly negotiated.
Grafana Cloud
Grafana's positioning is "open source, cloud hosted." Your metrics in Prometheus, logs in Loki, traces in Tempo, dashboards in Grafana — all hosted and managed by Grafana Labs. The appeal: if you're already running the open-source stack, Grafana Cloud is the path of least resistance to managed hosting.
The strength is cost predictability and the open ecosystem. Prometheus metrics are portable — you can run them locally, send them to Grafana Cloud, or ship them to any other OTLP-compatible backend without re-instrumenting. You're not locked in.
The weakness: the correlation experience across signals is less polished than Datadog. Jumping from a metric spike to relevant logs to the trace is more manual. Grafana is catching up on this with Grafana Explore and the unified query language, but it's not yet as seamless.
Best for: Engineering teams with existing Prometheus/open-source investment, or organizations prioritizing cost efficiency and portability over UX polish.
Honeycomb
Honeycomb's insight — that high-cardinality, wide event data is more valuable than pre-aggregated metrics — was ahead of its time when it launched and is now mainstream wisdom. If your primary need is debugging complex distributed systems, Honeycomb's approach to querying arbitrary attributes across traces is genuinely powerful.
The tradeoff: Honeycomb is a tracing-first platform. Metrics and logs are secondary. If you need a unified platform for metrics, logs, and traces, Honeycomb needs to be paired with other tooling.
Best for: Engineering teams doing serious distributed systems debugging who can complement with separate metrics tooling.
New Relic
New Relic made the strategically smart move to all-you-can-eat pricing based on user count rather than data volume. For high-volume environments, this pricing model can be significantly cheaper than Datadog. The platform is solid and the full-stack coverage (APM, infrastructure, logs, browser, mobile) is comprehensive.
The concern: the engineering community perception of New Relic has lagged its product improvements. It's underrated by engineers who haven't looked at it in several years, and overrated by the vendor sales process. Evaluate against your actual requirements.
Best for: High-volume environments where data ingestion cost is the primary constraint.
OpenTelemetry as the Foundation
Regardless of which backend you choose, instrument with OpenTelemetry. This isn't controversial anymore — the question is how, not whether.
The OTel ecosystem in 2026 is mature:
- Auto-instrumentation for major languages and frameworks is production-ready
- The GenAI semantic conventions (finalized late 2025) cover LLM observability
- The Collector pipeline handles routing, filtering, and transformation
- Vendor support is universal — every major platform accepts OTLP
The instrumentation pattern:
# Python service with OTel auto-instrumentation + custom spans
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor
from opentelemetry.instrumentation.sqlalchemy import SQLAlchemyInstrumentor
# Configure provider — backend is just an environment variable
provider = TracerProvider()
provider.add_span_processor(
BatchSpanProcessor(OTLPSpanExporter()) # OTEL_EXPORTER_OTLP_ENDPOINT env var
)
trace.set_tracer_provider(provider)
# Auto-instrument frameworks
FastAPIInstrumentor.instrument()
HTTPXClientInstrumentor.instrument()
SQLAlchemyInstrumentor.instrument()
# Your service code — zero changes needed for basic tracing
# For custom spans:
tracer = trace.get_tracer("my-service")
def process_order(order_id: str):
with tracer.start_as_current_span("process_order") as span:
span.set_attribute("order.id", order_id)
# ... business logicWith OTel, changing observability backends is an environment variable change, not a re-instrumentation project. This is the portability guarantee that makes the instrumentation investment durable.
Build vs. Buy for the Long Tail
The major platforms cover the common case well. The evaluation question is about the long tail: what does your stack look like in 5 years, and how does your observability choice constrain that?
The cost of observability tooling at scale is real and often underestimated at procurement time. Data volumes grow faster than traffic volumes because every new service, every new integration, every new log line adds to the indexing cost. Multi-year observability contracts signed when a company is small can become painful as the organization scales.
The risk mitigation: OTel instrumentation throughout, vendor contracts with data volume caps or predictable pricing, and a clear-eyed assessment of build vs. buy for specific capabilities where your requirements diverge from what vendors provide.
The trend I'm watching: AI-native observability platforms that build investigation capabilities into the core product rather than bolting ML onto a metrics/logs/traces foundation. The platforms that get this right will change what "good observability" means by the end of the decade.
*Zak Hassan is a Staff SRE specializing in observability, AI-powered operations, and data platform reliability. Find him at zakhassan.com or on LinkedIn.*
Topic Paths