Unified Monitoring for Multi-Cloud Ecosystems starts with service context

Unified Monitoring for Multi-Cloud Ecosystems: Stop Chasing Alerts Across Three Consoles

At 02:17, a payment API in Johannesburg began returning intermittent 504s. The application looked healthy in AWS, the Kubernetes dashboard in Azure showed no obvious failures, and the on-premise firewall reported normal traffic. The useful clue was not in any of those views. It appeared when request traces were correlated with a rise in cross-region latency to eu-west-1: a failover path was working, but working too slowly for the payment timeout.

That incident is the practical case for Unified Monitoring for Multi-Cloud Ecosystems. The objective is not to force every workload into one provider or one monitoring product. It is to give engineers one operational view of service health, regardless of whether the underlying telemetry comes from AWS, Azure, Google Cloud, a private data centre, or a branch network with an unreliable last mile.

Unified Monitoring for Multi-Cloud Ecosystems starts with service context

Cloud consoles are useful for managing their own resources. They are poor places to answer questions that cross provider boundaries: whether a customer request slowed because of a database in Cape Town, a network hop to London, or a queue running in another cloud.

A unified design begins with a consistent service model. Every metric, log and trace should carry a small set of labels or attributes that remain meaningful across environments:

• service, team and environment identify ownership and deployment stage.
• cloud, region and cluster identify placement.
• tenant or business_unit supports operational and cost analysis without exposing unnecessary customer data.
• deployment or version makes a release distinguishable from an infrastructure fault.

Do not begin by copying every provider metric into a central system. Start with the signals needed to operate a service: request rate, errors, latency, saturation, dependency health and availability from the user’s location. Provider-specific metrics can remain available for investigation, while the cross-cloud layer stays small enough to be trusted.

A practical telemetry path from Johannesburg to eu-west

Prometheus remains a sensible local collector for Kubernetes and platform metrics. It can scrape exporters close to the workload, evaluate recording rules, and continue collecting during a temporary link failure. OpenTelemetry can standardise application traces and selected metrics across languages and clouds, with collectors deployed as agents or gateways.

For long-term metrics, Mimir provides Prometheus-compatible storage at a scale that is difficult to achieve with a single Prometheus server. Loki is a good fit for centralised logs when labels are carefully controlled, while Tempo stores distributed traces and supports the correlation that turns an HTTP 504 into a dependency investigation rather than a guessing exercise.

The topology matters. A useful pattern for a South African estate is:

1. Run Prometheus and an OpenTelemetry Collector near each major workload or cluster.
2. Buffer telemetry locally so a short WAN interruption does not immediately become a monitoring outage.
3. Remote-write selected metrics to Mimir and forward logs to Loki through controlled gateways.
4. Send traces to Tempo with consistent service and deployment attributes.
5. Use Grafana as the shared query and visualisation layer, with dashboards organised around services and journeys rather than cloud accounts.

For example, the local collector in a Cape Town data centre should not depend on a London endpoint to decide whether a pod is restarting. Local alert evaluation can handle urgent platform conditions; central storage can handle fleet-wide analysis and historical comparisons. [Grafana’s 2025 observability survey](https://grafana.co.za) reported that 67% of respondents used Prometheus in production in some capacity, while Prometheus and OpenTelemetry were both used by 71% of respondents in some capacity. These figures reflect the practical direction of the ecosystem: Prometheus compatibility for operations, with OpenTelemetry increasingly used to standardise collection. [2][3]

Make the labels portable before moving the data

Most multi-cloud monitoring failures are caused by inconsistent metadata, not missing dashboards. One cloud may call a location af-south-1, another may use South Africa North, and an on-premise cluster may simply be called prod-za. If those values are used directly in alerts, every query becomes provider-specific.

Define a small internal vocabulary and translate provider metadata at the collection edge. A Kubernetes scrape configuration might add stable labels without leaking infrastructure naming conventions into every dashboard:

scrape_configs:
  - job_name: payments
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        target_label: environment
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: service
      - replacement: za-cpt
        target_label: site
      - replacement: aws
        target_label: cloud

Keep cardinality under control. A request ID, full URL, email address or Kubernetes pod UID does not belong in a metric label. Put high-cardinality values in logs or traces instead. This is especially important when Mimir receives telemetry from several clouds: an apparently harmless label combination can multiply storage, query and network costs.

Alert on customer impact, not on every cloud tremor

Load-shedding changes the meaning of infrastructure signals. A node may disappear briefly when a facility transfers to backup power, while the application remains available because capacity is distributed across zones. Alerting on every node loss creates noise precisely when the operations team needs a short, prioritised incident queue.

Use multi-window symptoms for paging. A service-level alert should combine availability and latency, then use lower-severity alerts for capacity and telemetry gaps. A PromQL example for a payment API is:

(
  sum(rate(http_requests_total{
    service="payments",
    environment="production",
    status=~"5.."
  }[5m]))
/
  sum(rate(http_requests_total{
    service="payments",
    environment="production"
  }[5m]))
) > 0.02
and
histogram_quantile(
  0.95,
  sum by (le) (
    rate(http_request_duration_seconds_bucket{
      service="payments",
      environment="production"
    }[5m])
  )
) > 0.8

The important part is not the threshold. It is the context attached to the alert: affected service, site, cloud, deployment version, recent trace exemplars and a link to the relevant logs. An engineer should be able to move from the alert to a representative failed request without manually searching three systems.

For load-shedding-aware operations, add a separate power or facility signal where it is available, but do not page on it automatically unless it predicts customer impact. During planned maintenance, mute only the affected site and time window. A blanket silence across all production clouds hides unrelated failures.

Use logs and traces to explain the metric

Metrics tell the team that latency rose. Logs often explain which dependency failed. Traces show where the time went. The three systems are most valuable when their identifiers line up.

Applications should emit structured logs containing the trace ID, service name, deployment version and a redacted error category. Loki queries should use indexed labels for stable dimensions, then filter fields inside the log body. Avoid turning every JSON field into a Loki label; that design becomes expensive and slow as traffic grows.

{service="payments", environment="production", site="za-cpt"}
| json
| duration_ms > 800
| level="error"

Tempo can then answer whether the slow span was the payment service, an Azure queue, a database in the private data centre, or the network path to eu-west. Grafana’s exemplars make that transition practical: a latency time series can point directly to a trace, while the trace can lead to correlated Loki records.

Control ZAR cost and POPIA exposure at the same time

Centralisation has a price. Cross-region egress, log volume and long retention periods can turn an apparently open-source stack into a significant monthly bill in rand. Measure telemetry cost by service and signal, not only by platform. A team that owns a noisy debug logger should see its impact on storage and transfer.

• Keep high-volume, low-value logs at short retention, with longer retention for security or audit records.
• Use recording rules for common fleet queries instead of repeatedly scanning raw series.
• Sample successful traces while retaining errors, slow requests and important business transactions.
• Aggregate or drop redundant provider metrics at the edge before remote write.
• Store regulated or identifying data in the appropriate jurisdiction and restrict cross-border forwarding.

POPIA considerations should shape the pipeline before the first incident. Remove identity numbers, payment details, access tokens and unnecessary customer fields at source or in the collector. Access to Loki and Tempo should be role-based, with audit trails and separate views for developers, platform engineers and security teams. Data sovereignty is not solved by drawing a South African region on a dashboard; it depends on where telemetry is processed, retained and accessed.

Operate the monitoring platform like a production service

A unified view is itself a dependency. Monitor ingestion delay, remote-write failures, dropped samples, Loki distributor errors, Tempo availability and dashboard query latency. Establish a “monitoring the monitor” path that does not rely entirely on the same cloud account or network route as the workloads it observes.

Test failure modes deliberately: disconnect the link to eu-west, stop a regional collector, rotate credentials, fill a log partition and deploy a bad label rule. The expected result is not perfect visibility. It is a known degradation mode, a useful alert, and enough local telemetry to diagnose the problem.

The strongest implementation is rarely the one with the most dashboards. It is the one where an engineer can answer, quickly and with evidence: which customer journey is failing, where the failing dependency runs, whether the problem is regional or global, what changed, and whether the telemetry itself can be trusted.