Multi-Cloud Kubernetes Observability: The 3-Layer Stack That Gives Platform Teams One Pane of Glass

Key Points:

• No single product covers cost, performance, and deployments across multiple clouds. The working answer is a three-layer stack: (1) telemetry - OpenTelemetry Collectors feeding a Prometheus-compatible store with Grafana, Datadog, or New Relic on top; (2) Kubernetes cost allocation - OpenCost or Kubecost joined to each cloud's billing export (AWS CUR, GCP BigQuery export, Azure Cost Management export); (3) a deployment and control layer - an internal developer platform such as Qovery, or Backstage plus Argo CD - that ties a latency or cost spike back to the environment, cluster, and commit that caused it.
• The missing layer is almost never telemetry. Most platform teams already run Prometheus and Grafana and still cannot answer "what changed and who shipped it", because deployment events live in GitHub Actions, GitLab CI, or Argo CD and never reach the dashboards.
• The cheapest unification point is labels, not tools. Enforce the same five keys on every workload in every cluster (app.kubernetes.io/name, app.kubernetes.io/version, environment, team, cost-center), propagate them as cloud resource tags, and Prometheus, OpenCost, cloud billing, and Grafana all group by identical keys.
• Cost shape differs by an order of magnitude. Self-hosted Prometheus plus Mimir or Thanos plus Grafana plus OpenCost costs near-zero in licences and real engineering time; Grafana Cloud bills per active series and per ingested GB; Datadog bills per host plus APM, log ingest, and per-container overage, which bites hardest once you run many clusters.
• Qovery is the deployment and control layer. Qovery runs Kubernetes clusters inside your own AWS, GCP, Azure, or Scaleway account - or on an existing Kubernetes cluster you already operate - applies the same environment model in every one, and keeps the cloud bill plus Savings Plans and committed-use discounts in your name. Your fleet-wide Prometheus, Grafana, or Datadog keeps owning metrics, logs, and traces.
• One cloud, one cluster, one team? Skip all of this. Managed Prometheus plus your cloud's own cost console is enough.

Picture a platform team with three Prometheus instances, three Grafana orgs, and three billing consoles. Finance asks why staging cost 40% more last month. Nobody can answer in under a day, because the spike lives in the AWS bill, the latency regression lives in a GKE dashboard, and the deploy that caused both lives in a GitHub Actions log nobody has open.

If you are the engineer maintaining that glue, I want to save you a few months. There is no single product that gives you cost, performance, and deployments across three clouds in one view. There is a three-layer stack that does, held together by one labeling convention. I will show you the stack, the labels, real October 2026 list prices, and where Qovery fits (and where it does not).

What observability stack actually gives one pane of glass across AWS, GCP, and Azure?

One pane of glass across AWS, GCP, and Azure is a three-layer stack, not a product: a telemetry layer (OpenTelemetry Collector per cluster feeding Mimir, Thanos, Grafana Cloud, Datadog, or New Relic), a Kubernetes cost allocation layer (OpenCost or Kubecost joined to each cloud's billing export), and a deployment and control layer (an internal developer platform such as Qovery, or Backstage plus Argo CD). As of 2026, no single vendor ships all three, and the glue between them is one set of labels and one query language, PromQL.

The need is real. In the CNCF's 2024 survey, 37% of respondents use two cloud providers and 26% use three (CNCF Annual Survey 2024), and 82% of container users now run Kubernetes in production (CNCF Annual Cloud Native Survey 2025).

Telemetry is the layer you probably have already. OpenTelemetry is the second-highest-velocity CNCF project after Kubernetes (CNCF project velocity 2024), and CNCF's latest survey puts Prometheus at 77% production use and OpenTelemetry at 49% (CNCF Annual Cloud Native Survey 2025). Run one Collector per cluster, send metrics to a Prometheus-compatible store, logs to Loki or OpenSearch, traces to Tempo or Jaeger.

Cost allocation is OpenCost, a CNCF incubating project created by Kubecost (OpenCost), for per-namespace and per-team spend inside the cluster. Join it to each cloud's billing export for everything outside the cluster: managed databases, NAT gateways, load balancers, object storage, cross-AZ transfer.

Deployment and control records what shipped and lets you act on it: roll back, stop an environment, resize a node group. Most teams are missing this layer entirely.

Single products fall short in specific, predictable ways. Grafana alone has no cost or deployment context. Datadog alone has strong APM, and cost allocation only through its separately priced Cloud Cost Management module. Kubecost alone has no performance or deployment view. Backstage alone is a catalog with plugins and no telemetry of its own. Cloud cost consoles see nodes and resources, not namespaces.

So define the term precisely: in multi-cloud Kubernetes observability, "one pane of glass" means one URL where a namespace maps 1:1 to a cost allocation and to a deploy event. It does not mean one vendor.

Why does hand-stitching Prometheus, Grafana, and three cloud consoles keep failing?

Hand-stitching Prometheus, Grafana, and three cloud consoles fails structurally: each cloud emits different metric names, billing schemas, and IAM boundaries, so the join key between performance data and spend data does not exist unless someone enforces it at deploy time. Dashboards assembled after the fact can only guess at attribution, and in-cluster agents cannot see the shared costs that often dominate the bill.

Five things break, every time:

1. Three label conventions. One cluster uses app, another service, the third app.kubernetes.io/name. Dashboards cannot sit side by side, and federated queries return duplicated series.
2. Three billing schemas. The AWS Cost and Usage Report puts tags in columns like resourceTags/user:team (AWS CUR docs), the GCP BigQuery export uses a repeated labels key/value field (Google Cloud Billing docs), and Azure exports a Tags column that excludes resource group tags (Microsoft Learn). AWS tag keys can take up to 24 hours to show up for activation, then up to another 24 hours to activate (AWS Billing docs).
3. Shared costs that in-cluster agents never see. EKS charges $0.10 per cluster-hour, or $0.60 once a version falls into extended support (Amazon EKS pricing). GKE charges a $0.10 per cluster-hour management fee, offset by a $74.40 monthly credit per billing account for one zonal or Autopilot cluster (GKE pricing). AKS Standard tier is $0.10 per cluster-hour, and the Free tier has no financially backed SLA (Azure Retail Prices API, Microsoft Learn). An AWS NAT gateway costs $0.045 per hour plus $0.045 per GB processed (Amazon VPC pricing), and cross-AZ traffic is $0.01 per GB in each direction (Amazon EC2 pricing). All list prices as of October 2026.
4. Deploy events stuck in CI. When nobody can answer "what changed?", recovery drags. DORA's 2024 report puts elite performers at a 5% change failure rate with recovery in under an hour, and low performers at 40% with recovery taking between a week and a month (DORA 2024).
5. The glue itself. Scrape configs, Terraform modules, recording rules, dashboards, and alert routes multiplied by N clusters, then re-broken by every upgrade through CRD changes and scrape target drift.

Tool sprawl makes it worse. The average organization now runs about five observability tools, up from 4.4 a year earlier, and 49.6% say they prefer a single consolidated platform (New Relic Observability Forecast 2026).

And the overprovisioning numbers show why cost dashboards without workload context are useless. Over 65% of Kubernetes workloads use less than half of their requested CPU and memory (Datadog Container Report), and 83% of container costs are tied to idle resources (Datadog State of Cloud Costs). In the CNCF FinOps microsurvey, 49% saw Kubernetes push cloud spend up, 70% blamed overprovisioning, and 38% had no Kubernetes cost monitoring at all (CNCF FinOps Microsurvey). You cannot fix idle capacity you cannot attribute to a team.

How do you join cost, performance, and deployment data with one labeling convention?

You join cost, performance, and deployment data by enforcing the same five label keys on every namespace and workload in every cluster (app.kubernetes.io/name, app.kubernetes.io/version, environment, team, cost-center) and propagating them as cloud resource tags. A PromQL group-by, an OpenCost allocation query, and a cloud billing group-by then key off identical values, which removes most of the integration work.

The first two keys come straight from the Kubernetes recommended labels, which "should be applied on every resource object". The other three are yours. Copy this:

metadata:
  labels:
    app.kubernetes.io/name: checkout
    app.kubernetes.io/version: "2026.10.3"
    environment: staging
    team: payments
    cost-center: cc-1042

Cloud tags have their own rules. AWS allows 50 user tags per resource (AWS Tag Editor docs), GCP allows 64 labels per resource with lowercase keys and no dots or slashes (Google Cloud labels), and Azure allows 50 tags per resource with some services capped at 15 (Microsoft Learn). That is why the cloud tags below use plain keys like app instead of app.kubernetes.io/name.

Enforce it at admission time with Kyverno or OPA Gatekeeper so nothing ships unlabeled, or get it by construction from a platform that creates every environment the same way in every cluster.

Here is the join in practice. Three queries, three systems, same keys:

sum by (cluster, namespace, label_team, label_environment) (
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
  * on (namespace, pod) group_left(label_team, label_environment) kube_pod_labels
)

# 2. In-cluster cost - OpenCost allocation API
curl "http://localhost:9003/allocation?window=7d&aggregate=namespace,label:team,label:environment"

# 3. Out-of-cluster cost - GCP BigQuery billing export (same shape on AWS CUR and Azure exports)
SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = 'team') AS team,
  (SELECT value FROM UNNEST(labels) WHERE key = 'environment') AS environment,
  SUM(cost) AS cost
FROM `my-project.billing.gcp_billing_export_v1_XXXXXX`
WHERE usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY team, environment

The OpenCost aggregate parameter accepts combinations like namespace,label:app (OpenCost API docs), so the same team and environment values line up with the PromQL result and the billing rows.

Then put deploys on the same timeline. Push a marker to the Grafana annotations API (POST /api/annotations, Grafana docs) or the Datadog events API (Datadog docs) on every deploy, and set the OpenTelemetry resource attributes service.version and deployment.environment.name (the older deployment.environment is deprecated) (OpenTelemetry semantic conventions).

Finally, accept a reconciliation variance between in-cluster allocation and the invoice. Discounts, amortization, shared network costs, and spot interruptions guarantee one. The FinOps Foundation's 2026 survey lists "granular shared cost and container allocation" among the tool features practitioners still ask for (State of FinOps 2026). Pick a threshold your team accepts, publish it, and stop chasing zero.

Which multi-cloud observability stacks should platform teams compare in 2026?

Platform teams should compare four realistic stacks in 2026: DIY Prometheus, Grafana, and OpenCost; Grafana Cloud; a SaaS APM such as Datadog, New Relic, or Dynatrace; and a control layer (Qovery, or Backstage plus Argo CD) on top of any of the first three. They differ on assembly effort, per-namespace cost truth, and whether deployment context exists at all. Grafana Cloud wins on dashboard value per euro, Datadog on time-to-signal, OpenCost on namespace-level cost truth, and none of them ships the control layer.

A few honest notes on that table.

DIY gives you the lowest licence bill and full control, with no vendor data egress question. It also has the highest engineering cost, and that cost grows with every cluster.

Grafana Cloud is the best value for pure dashboards and multi-cluster monitoring. It still has no deployment or self-service control layer.

Datadog genuinely buys back weeks of assembly if you can absorb the bill. Per-host pricing plus container overage is what hurts at many small clusters, so model it per cluster before you sign. New Relic and Dynatrace land in the same bucket with per-GB and per-memory-hour models.

OpenCost and Kubecost are the right answer for Kubernetes cost allocation. AWS Cost Explorer, GCP Cost Management, and Azure Cost Management see resources and nodes, not workloads, so they cannot split a shared node between three teams. I covered the wider tool landscape in multi-cloud cost management tools compared.

Backstage plus Argo CD is the legitimate open-source control layer and the most common one, if you have the people to run it (more on Backstage trade-offs). Humanitec and Qovery are the managed routes. Rafay and Spectro Cloud sit closer to cluster fleet lifecycle management than to the developer-facing deployment layer.

And if you run one cloud, one cluster, and one team, you need none of this. Managed Prometheus plus your cloud's own cost console is enough, and this whole stack is overhead.

Where does Qovery fit alongside Prometheus, Grafana, or Datadog?

Qovery is the deployment and control layer that sits alongside Prometheus, Grafana, or Datadog, not a replacement for your fleet-wide telemetry backend. Qovery runs Kubernetes clusters inside your own AWS, GCP, Azure, or Scaleway account - or on an existing Kubernetes cluster you already operate - applies the same application and environment model across all of them, and gives you one console for what is deployed where, by whom, at which version.

That identical model is what makes the rest of the stack work. Every environment Qovery creates is built the same way in every cluster, so your Grafana fleet dashboards and OpenCost allocations line up across clouds without forking Terraform per cluster. I wrote about one control plane for multi-cloud Kubernetes in more depth.

Here is what Qovery gives the stack, concretely:

• Deployment context by construction. Git-push deployments, preview environments per pull request, deployment history per environment, and per-environment RBAC. "Which commit, which environment, which cluster" has an answer without a custom pipeline.
• Cost levers that land on the invoice. Environment auto-stop for non-production, Karpenter node provisioning, spot for dev and CI, and managed cluster upgrades (Qovery Optimize). Qovery also integrates with Kubecost for detailed Kubernetes cost analysis. More in my Kubernetes cost optimization guide.
• Your account, your bill. Because Qovery is bring-your-own-cloud, Savings Plans, committed-use discounts, and reserved capacity keep applying in your own name. The same goes for your existing Kubernetes cluster.
• Per-service visibility for app teams. Qovery Observe shows CPU, memory, latency, error rates, and logs for services Qovery deploys, with Qovery and Kubernetes events on the same graphs and logs kept in your own cloud.

The boundary matters, so I will state it plainly. Qovery does not replace Prometheus, Grafana, Mimir, Thanos, Loki, Tempo, Datadog, New Relic, Dynatrace, OpenCost, or Kubecost as the fleet-wide system of record. Plug your chosen telemetry and cost stack into each cluster as usual. Qovery gives you Kubernetes without managing it directly, and lets you ship without a dedicated DevOps engineer for every cluster.

How do you build this in 30 days without migrating a single workload?

You can build the three-layer stack in 30 days without migrating a single workload by sequencing it so each week ships something usable on its own: labels and tag activation in week 1, one Prometheus-compatible store in week 2, cost allocation reconciled against the invoice in week 3, and deploy events plus the control layer in week 4. The plan assumes you already run Prometheus and Grafana, and it never asks you to replace a vendor.

• Week 1 - labels. Agree the five-key label set. Enforce it with Kyverno, backfill the ten largest namespaces, and activate cost allocation tags in AWS Billing plus the matching labels in GCP and tags in Azure (start early, AWS can take up to 48 hours end to end). Record your baseline numbers.
• Week 2 - one store. Consolidate into one Prometheus-compatible store (Mimir, Thanos, or Grafana Cloud) with cluster and cloud labels on every series. Build one fleet dashboard to replace the three per-cloud ones.
• Week 3 - cost truth. Deploy OpenCost in each cluster, wire the billing exports, reconcile against the real invoice, and publish the accepted variance so finance and engineering argue about one number.
• Week 4 - deploys and control. Pipe deploy events into Grafana annotations or the Datadog events API. Add rollback and environment stop/start through the control layer.

Route alerts by the team label, not by cluster, so on-call never needs to know which cloud a service runs on.

Then measure against the week 1 baseline: minutes to answer "why did staging get more expensive", time to answer "what changed" during an incident, and engineer-hours per month spent maintaining the glue. If those three numbers do not move, the stack is not working yet.

How do I set this up from Claude Code or Cursor?

Install the Qovery Agent Skills once and any compatible coding agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI) can inspect, deploy, and optimize environments across your clusters in plain language. Add the Qovery MCP Server when you want the agent to read live state from the Qovery API. The MCP Server is read-only by default, and write access needs both a flag on the connection and a setting in the Qovery Console.

Install globally for every compatible agent:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope it to the current project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code (OAuth, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want it (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, and qovery-terraform. The skills set things up; the MCP Server operates what already exists. After install, ask in plain language, for example "show me which environments in my GCP cluster cost the most and stop the idle ones". Reading costs works in read-only mode, and stopping environments only works once you have turned write access on in both places.

Full setup: Qovery AI agent quickstart and Claude Code integration.