Why MCM Observability
The problems with monitoring cloud infrastructure per provider and how MCM Observability solves them.
Why MCM Observability
Understanding what your cloud infrastructure is doing in real time — whether a workload is healthy, what its error rate is, how a request flows across services — requires pulling data from separate logging platforms, metrics dashboards, and tracing tools, each scoped to a single provider. When something breaks at 2 AM, navigating between CloudWatch, Azure Monitor, and a separate APM tool to correlate a log entry with a latency spike and a failing trace is the problem, not the investigation itself.
Challenges & How MCM Solves Them
Each challenge below is a real friction point teams face when monitoring cloud workloads across providers without a unified layer.
1. Fragmented Monitoring Tools
CloudWatch handles AWS; Azure Monitor handles Azure; neither speaks to the other. Engineers switch between at least two consoles to answer "is anything broken right now?" — before they even touch application-level telemetry.
How MCM solves it: MCM Observability ingests logs, metrics, and traces from all connected providers into a single telemetry pipeline. One dashboard shows the health of your entire estate — no provider-hopping required.
2. Logs Are Siloed and Hard to Search
Log data is spread across CloudWatch Log Groups, Azure Log Analytics workspaces, and host syslog — each with its own query language, retention policy, and access model. Searching across all of them for a single event is impractical without a dedicated logging platform.
How MCM solves it: MCM centralises log collection across all connected accounts and providers. Logs from AWS, Azure, and Ubuntu hosts land in the same index, searchable with a single query. No need to run parallel searches across separate tools.
3. No Cross-Cloud Metrics Correlation
A spike in Azure VM CPU, a rise in AWS Lambda error rate, and a queue depth increase across both are separate signals in separate tools. Correlating them to diagnose a cascading failure requires exporting data manually and comparing it side by side.
How MCM solves it: MCM Observability stores metrics from all providers in a normalised time-series format. You can overlay metrics from AWS and Azure resources on the same chart and set alerts that span both — no manual export or spreadsheet comparison.
4. Distributed Traces Stop at Provider Boundaries
A request that touches an AWS Lambda, an Azure Function, and a service on a Linux host produces trace spans in three separate systems with no way to stitch them into a single end-to-end trace.
How MCM solves it: MCM's distributed tracing support correlates trace spans across cloud environments using standard trace context propagation. A single trace view shows the full request journey — across providers, across regions — in one timeline.
5. Reactive Alerting
Teams set alerts in AWS and Azure separately, with no shared thresholds or escalation policies. Alerts fire into different channels with different formats, making it hard to maintain a coherent on-call workflow.
How MCM solves it: Alerts are defined once in MCM against normalised metrics — covering both AWS and Azure resources under a single threshold and notification rule. One on-call policy, one alert stream, regardless of which provider the signal originates from.
MCM vs Managing Observability Individually
| Aspect | Individual Provider Tools | MCM Observability |
|---|---|---|
| Log search | Per-provider query language, separate indexes | Unified log index, single search interface |
| Metrics | Separate dashboards per provider | Normalised time-series, cross-provider overlay |
| Tracing | Stops at provider boundary | End-to-end traces across cloud environments |
| Alerting | Separate rules per provider | Single rule covers AWS and Azure together |
| Incident correlation | Manual export and comparison | Correlated telemetry in one view |
| Host coverage | Cloud resources only | AWS, Azure, and Ubuntu hosts |
Features
| Feature | Description |
|---|---|
| Centralised log collection | Ingest and search logs from AWS CloudWatch, Azure Monitor, and Ubuntu hosts in a single index |
| Real-time metrics | Collect and visualise real-time and historical metrics for resources, costs, and platform health across all providers |
| Cross-provider metrics overlay | Plot AWS and Azure metrics on the same chart for direct comparison and correlation |
| Distributed tracing | End-to-end trace correlation across workloads running on multiple cloud providers and hosts |
| Unified alerting | Define metric-based alerts that span AWS and Azure with a single threshold and notification rule |
| Platform health metrics | Built-in metrics for MCM module job health — discovery runs, policy evaluations, cost ingestion — alongside infrastructure metrics |
| Retention and query | Configurable log and metrics retention with a query interface for ad-hoc investigation |