The best Kubernetes observability platform for multi-cloud operations

The problem: one fleet, three clouds and a telemetry bill that grows by itself

Running Kubernetes on one cloud is a solved operational problem. Running it on Amazon EKS, Azure AKS and Google GKE at the same time, often with an OpenShift or on-premises cluster as well, is not. Each managed service has its own add-ons, node images, logging defaults and identity model, and each cloud ships its own monitoring service that sees only its own clusters. When an incident crosses a cloud boundary, engineers end up comparing three consoles.

The second problem is cost. Kubernetes multiplies telemetry: every pod, container and label combination creates new metric series, every restart writes logs, and every service call can produce spans. The CNCF reports that 82% of container users now run Kubernetes in production, so this is no longer a niche concern. An observability platform that prices by series, host, container, gigabyte and user all at once can produce a bill nobody can forecast.

The third is lock-in. OpenTelemetry, which graduated in the CNCF in May 2026, now gives teams one way to instrument applications regardless of backend. The question is how fully each vendor embraces it once the data arrives.

Who this is for

• Platform engineering and SRE leads running production Kubernetes on at least two of EKS, AKS and GKE, with or without on-premises clusters.
• Organisations standardising on OpenTelemetry and Prometheus who want to keep the option of changing backend later.
• Buyers who need a forecastable bill and, in Australia and New Zealand, the option to keep telemetry in an Australian region.
• It is not aimed at single-cluster teams, who are usually well served by their cloud provider's native tooling.

How we evaluated

We set the criteria and weights before scoring, based on the problem above. We then reviewed official documentation, pricing pages and independent sources for seven platforms, recording a source for every finding and re-checking the decisive facts (prices, regions and Kubernetes views) against the live pages on 18 October 2026. Each product was scored from 1 to 5 on each criterion with a written evidence note.

What we did not do: we did not run these products ourselves, benchmark them, or negotiate quotes. Prices are public list prices in US dollars on the date of evaluation; enterprise agreements usually differ. Where a vendor makes a claim we could not confirm independently, we say so.

Side-by-side comparison

Why Grafana Cloud is the champion

It speaks the standards your teams already use. Grafana Cloud exposes an OTLP endpoint for metrics, logs and traces, ships its own OpenTelemetry Collector distribution (Alloy) but also accepts other distributions, and its metrics backend, Mimir, is documented as fully Prometheus compatible, including remote write and PromQL. Existing dashboards, alert rules and recording rules written for Prometheus carry over. The backends are open source, so a team that later wants to self-host is not starting from zero.

It covers the clusters multi-cloud teams actually run. The Kubernetes Monitoring Helm chart documents EKS on EC2 and Fargate, AKS, GKE Autopilot and OpenShift, and the fleet views list clusters, namespaces, workloads and nodes in one place, with drill-down to individual containers and tabs for logs and Kubernetes events.

Its pricing can be modelled before you sign. The Pro tier publishes every Kubernetes meter: $0.01 per host hour, $0.0007 per container hour, $6.50 per thousand active series, and per-GB rates for logs and traces. Two features reduce bill shock: metrics are billed on the 95th percentile of active series, so short spikes from a bad deploy are forgiven, and Adaptive Metrics recommends aggregating series nobody queries. Adaptive Logs applies the same idea to log volume.

It can keep data in Australia. Grafana Cloud lists Australian regions on both AWS and Google Cloud, which matters for ANZ organisations with data-handling policies, and holds SOC 2 Type 2 and ISO 27001 according to its security page.

It did not win every criterion. Datadog's Kubernetes views are more complete out of the box, and Dynatrace's automated root-cause analysis is stronger. Grafana Cloud won because it was never weak: it scored 4 or 5 on every criterion, while each rival had at least one score of 3 or lower on a criterion that matters for this buyer.

Where Dynatrace is the better choice

Dynatrace finished second and is the better pick for a specific kind of organisation. Its Kubernetes app gives a single overview of every cluster regardless of the cloud it runs on, grouping clusters, nodes, namespaces, workloads, pods, services and containers, with logs and events alongside. Its Davis AI engine identifies a probable root cause for each problem rather than leaving engineers to correlate alerts by hand.

It also has the strongest enterprise deployment story in this group. Dynatrace Managed runs in your own data centre for organisations that cannot send telemetry to SaaS, the SaaS platform runs in AWS Sydney with Azure Australia East on request, and Australian press reported in 2024 that it achieved IRAP PROTECTED status for its AWS-hosted SaaS.

Choose Dynatrace if your teams are stretched thin and value automated diagnosis over flexibility, if you need a self-managed deployment, or if Australian government security assessments are a requirement. Expect trade-offs on open standards: Dynatrace accepts OTLP metrics only with delta temporality, does not support summary metrics, and its supported technologies page limits GKE Autopilot and EKS on Fargate to application observability only. Its pricing is published per memory-GiB-hour and per pod-hour, but sits under an annual platform commitment.

Other credible options

Elastic Observability (3.75) is the best choice for teams that already run Elasticsearch for logs or security. Its Serverless pricing is low and simple per GB, it runs in AWS Sydney and Azure Australia East, and it can be self-managed. It lost ground on Kubernetes fleet views and on standards: its managed OTLP endpoint is cloud-only and has no tail-based sampling, and Elastic says its PromQL support is generally available but not complete.

Datadog (3.70) has the most complete out-of-the-box Kubernetes experience in this group, with broad distribution support, an explorer by resource type and strong log and trace correlation, plus an Australian site. It scored lowest on cost predictability: its pricing meters hosts, extra containers, custom metrics, APM hosts, log ingest and log indexing separately, and Prometheus metrics collected by its generic check count as custom metrics. Teams with disciplined tagging and a generous budget will find it excellent. See our Datadog company profile for its financial position.

New Relic (3.20) has a strong OpenTelemetry story and a simple per-GB price with 100 GB free, but it offers no Australian data region and its cross-cluster fleet view was announced as a public preview in December 2025. Check its current status before relying on it.

Splunk Observability Cloud (2.75) suits organisations already committed to Splunk for logs, because Kubernetes events depend on Log Observer Connect and Splunk Platform. Its editions start at $15, $60 and $75 per host per month billed annually, and its documentation warns that overage fees can reach 150% of list price.

Cortex XCOR (2.55), formerly Chronosphere, has excellent cost-shaping tools and full PromQL compatibility, but it publishes no price list, we found no Australian region, and it changed hands when Palo Alto Networks completed its acquisition in early 2026. It is worth a conversation for very large metrics estates, not a default recommendation.

Limitations and trade-offs

• Grafana Cloud takes more assembly. Its strengths come from composable open-source components, and user reviews on PeerSpot mention a learning curve and a complex alerting interface. Budget platform-team time for dashboards and alert rules.
• Series-based billing still rewards discipline. Grafana's p95 billing and Adaptive Metrics soften cardinality growth but do not remove it. A label carrying user or request IDs will still cost money.
• Grafana's self-managed enterprise backends have an end date. Grafana Enterprise Metrics, Logs and Traces are in long-term support and reach end of life on 1 February 2029. Organisations that need on-premises deployment should confirm the migration path, or look at Dynatrace Managed or self-managed Elastic.
• IRAP evidence differs by vendor. Grafana Labs does not list IRAP on its trust centre; Dynatrace and Datadog IRAP PROTECTED status comes from press reports. Australian government buyers should request current assessment letters.
• List prices are a starting point. Every vendor here negotiates enterprise agreements, and several bundle or discount meters. Use the published units to build a comparison model, not to predict your final invoice.

Implementation and pricing considerations

1. Standardise instrumentation first. Deploy the OpenTelemetry Collector or the vendor's OTel distribution in every cluster, with the same resource attributes for cluster name, cloud, region and environment. This makes cross-cluster views work in any tool and keeps your exit option open.
2. Model cost with real numbers. Count nodes, average containers per node, active metric series and daily log volume for each cluster, then price them against each vendor's published units. For example, on Grafana Cloud's Pro list prices, Kubernetes Monitoring for 30 nodes running 600 containers is about $516 a month (30 x $7.20 plus 600 x $0.50), before metrics, logs and traces.
3. Cut telemetry before it is stored. Drop debug logs and unused metrics in the collector, not after ingest. All of the leading platforms offer pre-storage filtering; use it from the first day.
4. Decide on data location early. If telemetry may contain personal or sensitive data, choose an Australian region at sign-up; Datadog notes that its sites are completely independent, and moving later usually means a new account.
5. Run a time-boxed proof of concept on two clouds. Include at least one managed cluster and one constrained environment such as GKE Autopilot or EKS on Fargate, where agent-based features are often reduced.

Questions to ask vendors

1. Which features are unavailable when we send data only through OpenTelemetry instead of your proprietary agent or SDK?
2. Do you accept OTLP metrics with cumulative temporality, and summary and histogram types, without conversion?
3. How are Prometheus metrics scraped from our clusters billed: as standard metrics, custom metrics or series?
4. What exactly happens to our bill during a cardinality spike, and what controls can cap it automatically?
5. Which Kubernetes features are reduced on GKE Autopilot, EKS on Fargate and OpenShift?
6. In which region is each type of data stored and processed, including metadata, support and operations data?
7. Can you provide current SOC 2 reports and, for Australian public sector use, an IRAP assessment covering the services we will use?
8. What is your roadmap commitment for self-managed or on-premises deployment beyond 2029?

What would change our verdict

We will revisit this recommendation if Grafana Labs changes its Kubernetes Monitoring pricing or its self-managed roadmap, if Dynatrace removes its delta-only restriction on OpenTelemetry metrics, if Datadog simplifies custom-metric billing for Prometheus data, or if New Relic adds an Australian region. Each change would move at least one score on the criteria above.