Unified Monitoring for Multi-Cloud Ecosystems

Unified Monitoring for Multi-Cloud Ecosystems

As a South African SRE working with teams spread across Johannesburg, Cape Town, and a couple of data centres in Europe, I’ve seen first-hand how fast organisations in our region are adopting multi-cloud. AWS for core services, Azure for data platforms, GCP for ML workloads, plus a handful of local Kubernetes clusters on-prem — it’s powerful, but it complicates one critical discipline: Unified Monitoring for Multi-Cloud Ecosystems.

In this article, I’ll show you how to approach Unified Monitoring for Multi-Cloud Ecosystems using Grafana as your central observability hub. We’ll look at architecture patterns, practical examples, code snippets, and concrete steps you can take to build a reliable, multi-cloud monitoring strategy that works for DevOps engineers and SREs.

Why Unified Monitoring for Multi-Cloud Ecosystems Matters

Multi-cloud is great for avoiding vendor lock-in and optimising cost, but it fragments your telemetry:

• AWS CloudWatch metrics and logs live in one silo.
• Azure Monitor captures another set of metrics and application insights.
• GCP operations suite (formerly Stackdriver) stores yet another set.
• On-prem clusters might be using Prometheus, Loki, or something custom.

Without Unified Monitoring for Multi-Cloud Ecosystems, you end up with:

• Slow incident response because engineers are jumping between consoles.
• Inconsistent SLO definitions across environments.
• Gaps in auditability and compliance (especially important in regulated South African industries).

The goal is simple: one pane of glass for metrics, logs, and traces, no matter which cloud or cluster they originate from. Grafana is a strong fit here because it speaks many data source “languages” and can be the unifying layer on top.

Architecture: Grafana at the Centre of Multi-Cloud Observability

A typical architecture for Unified Monitoring for Multi-Cloud Ecosystems with Grafana looks like this:

1. Each cloud/cluster exports telemetry (metrics, logs, traces) via standard protocols.
2. Telemetry is aggregated into common backends (Prometheus, Grafana Mimir, Loki, Tempo, or compatible services).
3. Grafana connects to those backends and cloud-native APIs (CloudWatch, Azure Monitor, GCP Monitoring) as data sources.
4. Dashboards and alerts are defined centrally in Grafana and scoped per environment, region, or tenant.

Practically, that means:

• Metrics: Prometheus-compatible (including managed services like Amazon Managed Prometheus) and cloud-specific metric APIs.
• Logs: Loki, plus cloud log services via plugins or gateways.
• Traces: Tempo (or Jaeger/Zipkin) with exporters from all environments.

Let’s walk through some concrete examples and code that you can reuse.

Instrumenting Kubernetes Across Clouds with Prometheus and Grafana

Deploying Prometheus in Each Cluster

One practical pattern for Unified Monitoring for Multi-Cloud Ecosystems is to run a Prometheus instance (or agent) per cluster and federate or remote-write to a central metrics backend that Grafana uses.

For example, in an EKS cluster in eu-central-1, you might define:

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s

    scrape_configs:
      - job_name: 'kubernetes-nodes'
        kubernetes_sd_configs:
          - role: node
        relabel_configs:
          - source_labels: [__address__]
            target_label: instance

    remote_write:
      - url: https://mimir.example.co.za/api/v1/push
        queue_config:
          max_samples_per_send: 10000
        write_relabel_configs:
          - source_labels: [__meta_kubernetes_cluster]
            target_label: cluster

You can replicate this pattern in AKS and GKE, only changing cluster-specific labels and remote endpoints. The key is that all clusters send metrics to a central store (Mimir, Cortex, Thanos, or a managed equivalent), so Grafana can query cross-cloud data uniformly.

Querying Cross-Cloud Metrics in Grafana

Once your metrics are centralised, a unified query could look like:

sum by (cluster, namespace) (
  rate(http_requests_total{job="frontend"}[5m])
)

This gives you an immediate view of traffic per cluster, so you can compare AWS vs Azure vs GCP behaviour in one graph and quickly see if a regional outage is affecting one provider only.

Logs Unification with Loki and Cloud-Native Services

Using Loki as a Common Logs Backend

For logs, I’ve found that using Loki as a central backend simplifies Unified Monitoring for Multi-Cloud Ecosystems. You can push logs from containers, VMs, and even cloud-native services using Promtail or other agents.

A basic Promtail configuration from an on-prem Kubernetes cluster in Johannesburg might look like:

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /var/log/promtail-positions.yaml

clients:
  - url: https://loki.example.co.za/loki/api/v1/push

scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    pipeline_stages:
      - docker: {}
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_name]
        target_label: pod
      - source_labels: [__meta_kubernetes_cluster]
        target_label: cluster

In AWS, you can do something similar via CloudWatch subscription filters pushed through a small Lambda that formats logs into Loki’s HTTP API. The same pattern applies for Azure and GCP using their respective log export mechanisms.

Cross-Cloud Log Queries in Grafana

Once everything is in Loki, Grafana can run unified queries, for example:

{app="payment-service"} |= "ERROR"
| regexp "(?P<country>ZA|NG|KE)"
| stats count() by cluster, country

From a South African SRE perspective, this is powerful: you can immediately see if errors are concentrated in a specific cloud region or in a specific market. This drives faster incident response and more accurate RCA (root cause analysis).

Traces and Distributed Systems Across Multiple Clouds

Using OpenTelemetry for Vendor-Neutral Instrumentation

To complete Unified Monitoring for Multi-Cloud Ecosystems, you need consistent tracing across clouds. OpenTelemetry has become the de facto standard here.

A simple OpenTelemetry configuration to export traces from services running in both AWS and Azure to a shared Tempo backend could look like:

receivers:
  otlp:
    protocols:
      http:
      grpc:

exporters:
  otlp:
    endpoint: tempo.example.co.za:4317
    tls:
      insecure: false

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]

All your services, regardless of cloud, send traces via OTLP to a central Tempo instance. Grafana then correlates traces with metrics and logs, giving you a complete view across your multi-cloud ecosystem.

Designing Dashboards for Unified Monitoring for Multi-Cloud Ecosystems

Key Dashboard Patterns

When building Grafana dashboards, I recommend these patterns:

• Global health overview: status of each cloud provider, region, and cluster (latency, error rates, saturation).
• Per-service cross-cloud view: the same microservice running in different clouds, shown in one panel.
• User-centric dashboards: slice data by geography (e.g., South Africa vs Europe) or customer segment, not by cloud.

For example, a latency panel using PromQL might be:

histogram_quantile(
  0.95,
  sum by (le, cluster) (
    rate(http_request_duration_seconds_bucket{service="checkout