Monitoring & Observability Comparison

Multi-Cloud Observability Overview

Observability, the ability to understand the internal state of your systems from their external outputs, is the foundation of operating reliable cloud infrastructure. Every major cloud provider offers a native observability stack that covers metrics, logs, and traces. AWS provides CloudWatch and X-Ray. Azure offers Azure Monitor and Application Insights. Google Cloud delivers Cloud Operations Suite (formerly Stackdriver). Each is deeply integrated with its provider's services, but each creates a silo that makes multi-cloud visibility challenging.

For organizations running workloads across multiple clouds, or those who want vendor-neutral tooling, third-party platforms like Datadog, New Relic, and Grafana Cloud provide a unified observability layer. OpenTelemetry has emerged as the open standard for telemetry collection, enabling portable instrumentation that works with any backend.

This guide compares native observability services across all three major providers, evaluates third-party alternatives, and provides practical guidance for building a unified observability strategy. We cover metrics collection, log aggregation, distributed tracing, alerting, and cost optimization for each approach.

AWS CloudWatch & X-Ray

Amazon CloudWatch is the cornerstone of AWS observability. It collects metrics from over 70 AWS services automatically, stores and queries logs via CloudWatch Logs, and provides dashboards, alarms, and anomaly detection. CloudWatch Metrics supports custom metrics, high-resolution metrics (1-second granularity), and Metrics Insights for SQL-like querying across metric namespaces.

AWS X-Ray provides distributed tracing for applications running on AWS. It traces requests as they flow through API Gateway, Lambda, ECS, EKS, and downstream services. X-Ray integrates with the AWS Distro for OpenTelemetry (ADOT), allowing you to instrument applications with OpenTelemetry SDKs and send traces to X-Ray.

CloudWatch Key Capabilities

• CloudWatch Logs Insights: SQL-like query language for log analysis with visualization support
• CloudWatch Metrics Insights: Query metrics across namespaces using SQL syntax
• CloudWatch Anomaly Detection: ML-based anomaly detection on metrics using bands
• CloudWatch Synthetics: Canary scripts that monitor endpoints and APIs on a schedule
• CloudWatch RUM: Real user monitoring for web applications with Core Web Vitals
• CloudWatch Application Signals: APM for applications instrumented with OpenTelemetry
• Amazon Managed Grafana: Fully managed Grafana with native CloudWatch data source

# Query CloudWatch Logs Insights
aws logs start-query \
  --log-group-name /ecs/production/app \
  --start-time $(date -d '1 hour ago' +%s) \
  --end-time $(date +%s) \
  --query-string '
    fields @timestamp, @message, @logStream
    | filter @message like /ERROR/
    | stats count(*) as errorCount by bin(5m)
    | sort @timestamp desc
    | limit 100
  '

# Create a CloudWatch alarm on a custom metric
aws cloudwatch put-metric-alarm \
  --alarm-name high-error-rate \
  --metric-name 5xxErrors \
  --namespace Custom/MyApp \
  --statistic Sum \
  --period 300 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --treat-missing-data notBreaching

# Create a CloudWatch Synthetics canary
aws synthetics create-canary \
  --name api-health-check \
  --artifact-s3-location s3://canary-artifacts/api-health/ \
  --execution-role-arn arn:aws:iam::123456789012:role/canary-role \
  --schedule "Expression=rate(5 minutes)" \
  --code "Handler=apiCanary.handler,S3Bucket=canary-code,S3Key=canary.zip" \
  --runtime-version syn-nodejs-puppeteer-7.0

Azure Monitor & Application Insights

Azure Monitor is a comprehensive monitoring platform that collects, analyzes, and acts on telemetry from Azure and hybrid environments. It encompasses several sub-services: Application Insights (APM and distributed tracing), Log Analytics (log query and storage), Azure Monitor Metrics (time-series database), Azure Monitor Alerts, and Azure Workbooks (interactive reporting). The Kusto Query Language (KQL) powers log analysis and is one of the most powerful query languages in the observability space.

Application Insights provides automatic instrumentation for .NET, Java, Node.js, and Python applications. It captures request traces, dependencies, exceptions, and performance counters with minimal code changes. The Application Map feature visualizes service dependencies and highlights performance bottlenecks.

Azure Monitor Key Capabilities

• Log Analytics workspaces: Centralized log storage with KQL-based querying and 730-day retention
• Application Insights: APM with auto-instrumentation, smart detection, and application map
• Azure Monitor Managed Grafana: Fully managed Grafana instance with Azure AD integration
• Azure Managed Prometheus: Prometheus-compatible metrics service for Kubernetes workloads
• Change Analysis: Detects infrastructure and configuration changes correlated with incidents
• Azure Workbooks: Interactive, parameterized reports combining metrics, logs, and text
• Availability tests: Multi-location ping and URL tests with SSL certificate monitoring

# Query Application Insights logs using KQL via Azure CLI
az monitor app-insights query \
  --app my-app-insights \
  --resource-group rg-monitoring \
  --analytics-query '
    requests
    | where timestamp > ago(1h)
    | where resultCode >= 500
    | summarize errorCount = count() by bin(timestamp, 5m), operation_Name
    | order by timestamp desc
  '

# Create an Azure Monitor alert rule
az monitor metrics alert create \
  --name high-response-time \
  --resource-group rg-monitoring \
  --scopes /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.Web/sites/myapp \
  --condition "avg requests/duration > 2000" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --action-group ops-team-ag

# Create a Log Analytics workspace
az monitor log-analytics workspace create \
  --resource-group rg-monitoring \
  --workspace-name central-logs \
  --location eastus \
  --retention-in-days 90

GCP Cloud Operations Suite

Google Cloud Operations Suite (formerly Stackdriver) provides integrated monitoring, logging, tracing, profiling, and error reporting for Google Cloud workloads. Cloud Monitoring collects metrics from GCP services and supports custom metrics, uptime checks, and dashboard creation. Cloud Logging is a fully managed log storage and analysis service with a powerful query syntax. Cloud Trace provides distributed tracing that is tightly integrated with GCP services.

A unique strength of GCP's observability offering is Cloud Profiler, a continuous profiling service that captures CPU, memory, and heap profiles from production applications with minimal overhead (less than 0.5%). This enables production debugging without reproducing issues in staging environments.

Cloud Operations Key Capabilities

• Cloud Monitoring: Metrics collection with MQL (Monitoring Query Language) and PromQL support
• Cloud Logging: Centralized logging with log-based metrics, sinks to BigQuery/Pub/Sub, and advanced filters
• Cloud Trace: Distributed tracing with automatic instrumentation for GCP services
• Cloud Profiler: Continuous production profiling with less than 0.5% overhead
• Error Reporting: Automatic grouping and tracking of application errors across services
• Managed Prometheus: Google-managed Prometheus with global query across clusters and projects
• Service Monitoring: SLO-based monitoring with error budget tracking

# Query Cloud Logging with advanced filter
gcloud logging read '
  resource.type="k8s_container"
  AND resource.labels.cluster_name="prod-cluster"
  AND severity>=ERROR
  AND timestamp>="2024-01-15T00:00:00Z"
' --limit 100 --format json

# Create a log-based metric
gcloud logging metrics create error_count \
  --description="Count of error log entries" \
  --log-filter='severity>=ERROR AND resource.type="k8s_container"'

# Create an uptime check
gcloud monitoring uptime create \
  --display-name="API Health Check" \
  --resource-type=uptime-url \
  --hostname=api.example.com \
  --path=/health \
  --protocol=HTTPS \
  --period=60s \
  --timeout=10s \
  --regions=USA,EUROPE,ASIA_PACIFIC

# Create an alerting policy
gcloud monitoring policies create \
  --display-name="High Error Rate" \
  --condition-display-name="Error rate > 5%" \
  --condition-filter='metric.type="logging.googleapis.com/user/error_count" AND resource.type="k8s_container"' \
  --condition-threshold-value=50 \
  --condition-threshold-duration=300s \
  --notification-channels=projects/my-project/notificationChannels/12345

Feature-by-Feature Comparison

The following table compares the native observability services across all three providers. Each excels in different areas: AWS has the broadest service integration, Azure has the most powerful query language, and GCP has the strongest Kubernetes and SRE-native tooling.

OpenTelemetry for Multi-Cloud

OpenTelemetry (OTel) is the CNCF project that provides vendor-neutral APIs, SDKs, and tools for generating, collecting, and exporting telemetry data (metrics, logs, and traces). It has become the industry standard for instrumentation and is the single most important technology for achieving multi-cloud observability portability.

By instrumenting your applications with OpenTelemetry SDKs, you decouple telemetry generation from the backend that stores and analyzes it. You can send the same telemetry data to CloudWatch, Azure Monitor, Cloud Operations, Datadog, or any other OTLP-compatible backend simply by changing the exporter configuration. This flexibility is invaluable for multi-cloud organizations.

# OpenTelemetry Collector configuration for multi-cloud
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  # Scrape Prometheus metrics from Kubernetes pods
  prometheus:
    config:
      scrape_configs:
        - job_name: k8s-pods
          kubernetes_sd_configs:
            - role: pod
          relabel_configs:
            - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
              action: keep
              regex: true

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

  # Add cloud-specific resource attributes
  resourcedetection:
    detectors: [env, system, aws, azure, gcp]
    timeout: 5s

  # Filter out noisy health check spans
  filter:
    spans:
      exclude:
        match_type: regexp
        attributes:
          - key: http.target
            value: "/(health|ready|live)"

exporters:
  # AWS CloudWatch / X-Ray
  awsxray:
    region: us-east-1
  awsemf:
    region: us-east-1
    namespace: MyApp

  # Azure Monitor
  azuremonitor:
    connection_string: InstrumentationKey=xxx;IngestionEndpoint=https://eastus-1.in.applicationinsights.azure.com/

  # GCP Cloud Operations
  googlecloud:
    project: my-gcp-project

  # Optional: Third-party backend
  otlp/datadog:
    endpoint: https://api.datadoghq.com:4317
    headers:
      dd-api-key: ${DD_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resourcedetection, filter]
      exporters: [awsxray, azuremonitor, googlecloud]
    metrics:
      receivers: [otlp, prometheus]
      processors: [batch, resourcedetection]
      exporters: [awsemf, azuremonitor, googlecloud]
    logs:
      receivers: [otlp]
      processors: [batch, resourcedetection]
      exporters: [awsemf, azuremonitor, googlecloud]

Third-Party Observability Platforms

Third-party observability platforms provide a unified view across all cloud providers, on-premises infrastructure, and SaaS applications. They eliminate the need to context- switch between provider-specific consoles and typically offer more advanced analytics, correlation, and incident management features than native tools.

Platform Comparison

When to Use Third-Party vs. Native

Use native observability tools when you operate primarily within a single cloud provider and want to minimize cost and complexity. The native tools are free or low-cost for basic usage, deeply integrated with provider services, and require no additional agent deployment.

Use third-party platforms when you operate across multiple clouds, need a single pane of glass, require advanced analytics (ML-based anomaly detection, correlation across signals), or want to avoid vendor lock-in on your observability layer. Third-party platforms also tend to have better collaboration features (shared dashboards, annotations, incident timelines) for large teams.

Third-Party Cost Estimation

Third-party observability costs can grow quickly. The following estimates are for a mid-size deployment with 50 hosts, 500 GB logs/month, 10 million trace spans/month, and 5 users:

Centralized Logging Strategies

In multi-cloud environments, centralized logging is essential for cross-service correlation, compliance auditing, and incident investigation. There are three primary strategies for centralizing logs across providers:

Strategy 1: Third-Party Log Aggregator

Ship logs from all clouds to a single third-party platform (Datadog, Splunk, Elastic, Grafana Loki). This provides the simplest operational model with a single query interface and unified alerting. The downside is cost: ingestion-based pricing at third-party platforms can be expensive at high volume.

Strategy 2: Cloud-Native with Cross-Cloud Export

Use each provider's native logging service but export logs to a central store for cross-cloud analysis. For example, export CloudWatch Logs to S3, Azure Diagnostic Logs to Blob Storage, and Cloud Logging to Cloud Storage or BigQuery, then query them with a unified tool like Athena, Azure Data Explorer, or BigQuery.

Strategy 3: OpenTelemetry-Based Collection

Deploy the OpenTelemetry Collector on all workloads and configure it to send logs to both the native provider service (for real-time debugging) and a central backend (for cross-cloud analysis). This dual-shipping approach provides the best of both worlds but doubles log storage costs.

# AWS: Create a CloudWatch Logs subscription filter to ship logs to S3 via Firehose
aws logs put-subscription-filter \
  --log-group-name /ecs/production/app \
  --filter-name ship-to-firehose \
  --filter-pattern "" \
  --destination-arn arn:aws:firehose:us-east-1:123456789012:deliverystream/logs-to-s3

# Azure: Create a diagnostic setting to export logs to Event Hub (for third-party ingestion)
az monitor diagnostic-settings create \
  --name export-logs \
  --resource /subscriptions/<sub>/resourceGroups/rg-app/providers/Microsoft.Web/sites/myapp \
  --event-hub-rule /subscriptions/<sub>/resourceGroups/rg-shared/providers/Microsoft.EventHub/namespaces/log-hub/authorizationRules/send \
  --logs '[{"category":"AppServiceHTTPLogs","enabled":true},{"category":"AppServiceConsoleLogs","enabled":true}]'

# GCP: Create a log sink to export to BigQuery for long-term analysis
gcloud logging sinks create bq-export-sink \
  bigquery.googleapis.com/projects/my-project/datasets/centralized_logs \
  --log-filter='resource.type="k8s_container" AND severity>=WARNING'

Alerting & Incident Management

Effective alerting requires more than threshold-based rules. Modern observability platforms support composite alerts, anomaly detection, and SLO-based alerting (alert when error budgets are burning too fast rather than on raw metric thresholds). Each cloud provider's alerting system has different capabilities:

Multi-Cloud Alerting Strategy

For multi-cloud environments, centralize alerting through one of these approaches:

• Third-party platform: Use Datadog, PagerDuty, or Opsgenie as the central alerting hub. Route all cloud-native alerts to the platform via webhooks or native integrations.
• PagerDuty / Opsgenie: Use a dedicated incident management platform to aggregate alerts from all providers and manage on-call schedules, escalation policies, and runbooks.
• Grafana Alerting: Use Grafana as a unified dashboard and alerting layer with data sources for CloudWatch, Azure Monitor, and Cloud Monitoring.

Alerting Configuration Example

The following example shows how to configure a Grafana alert rule that queries metrics from all three cloud providers simultaneously, enabling a single alert definition that covers your entire multi-cloud deployment:

# Grafana provisioned alert rule for multi-cloud error rate monitoring
apiVersion: 1
groups:
  - orgId: 1
    name: multi-cloud-api-health
    folder: Production Alerts
    interval: 1m
    rules:
      - uid: multi-cloud-error-rate
        title: "API Error Rate > 5% (Any Cloud)"
        condition: C
        data:
          # AWS CloudWatch data source
          - refId: A
            datasourceUid: cloudwatch-ds
            model:
              namespace: AWS/ApplicationELB
              metricName: HTTPCode_Target_5XX_Count
              statistic: Sum
              period: "300"
              dimensions:
                LoadBalancer: ["app/prod-alb/abc123"]
          # Azure Monitor data source
          - refId: B
            datasourceUid: azuremonitor-ds
            model:
              azureMonitor:
                resourceGroup: rg-app
                metricDefinition: Microsoft.Web/sites
                metricName: Http5xx
                timeGrain: PT5M
                aggregation: Total
          # GCP Cloud Monitoring data source
          - refId: C
            datasourceUid: stackdriver-ds
            model:
              metricType: loadbalancing.googleapis.com/https/request_count
              filters:
                - response_code_class
                - "500"
        noDataState: NoData
        execErrState: Error
        for: 5m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "API error rate exceeds 5% on one or more cloud providers"
          runbook_url: "https://wiki.example.com/runbooks/api-error-rate"

SLO Monitoring Across Clouds

Service Level Objectives (SLOs) provide a framework for measuring reliability that is independent of the underlying infrastructure. Define SLOs based on user-facing metrics (availability, latency, throughput) and track error budgets across all cloud providers. GCP Cloud Monitoring has the most mature native SLO support with burn rate alerting. For multi-cloud SLO tracking, consider:

• Nobl9: A dedicated SLO platform that integrates with all three cloud providers and third-party observability tools
• Grafana SLO: Part of Grafana Cloud, provides SLO tracking with multi-data-source support
• Sloth: Open-source SLO generator for Prometheus that works with any managed Prometheus service
• Custom implementation: Use OpenTelemetry metrics with custom SLI calculations exported to a unified dashboard

Best Practices & Unified Observability

Building a unified observability strategy across multiple clouds requires intentional architecture decisions. The following best practices apply regardless of which tools you choose:

Instrumentation Standards

• Adopt OpenTelemetry: Use OpenTelemetry SDKs for application instrumentation across all services. This ensures portable telemetry that works with any backend.
• Structured logging: Use JSON-formatted logs with consistent field names (e.g., trace_id, span_id, service_name, environment) across all services and clouds.
• Consistent naming: Establish naming conventions for metrics, log groups, and traces that include the cloud provider, environment, and service name (e.g., aws.prod.api-gateway).
• Correlation IDs: Propagate trace context (W3C Trace Context headers) across all service boundaries, including cross-cloud calls.

Operational Guidelines

• SLO-driven alerting: Define SLOs for each service and alert on error budget burn rate rather than raw thresholds. This reduces alert noise and focuses on user impact.
• Dashboard hierarchy: Create a three-level dashboard hierarchy: executive (business KPIs), service (per-service health), and debug (detailed metrics and logs for incident investigation).
• Cost governance: Monitor observability spend across all providers monthly. Set up alerts when log ingestion or metric cardinality exceeds thresholds. Use sampling for high-volume, low-value telemetry.
• Runbooks: Attach runbooks to every alert. Include cross-cloud investigation procedures that reference the correct console, CLI commands, and log groups for each provider.

Related Resources

Dive deeper into provider-specific observability with these guides:

• AWS CloudWatch Observability Guide
• Azure Monitor & Application Insights Guide
• GCP Cloud Logging & Monitoring Guide