Sections

1. What and Why

7 min read

Azure Monitor is the regional-plus-global platform service that collects, stores, queries, and alerts on every signal Azure and your applications produce. One sentence hides a family: metrics, logs, traces, alerts, autoscale, and the visualisation surfaces on top of them.

The problem before it existed

Before a platform-native monitor, running anything meant assembling an observability stack yourself: an agent on every machine, a time-series database for numbers, an indexed store for text, a tracing backend for request flows, a rules engine to notice when something went wrong, and a notification path to wake someone up. Each piece was a service you had to run, scale, secure, and pay for — and none of them could see what the platform saw. When your VM disappeared, your agent disappeared with it, and the reason lived in a control-plane log you had no access to.

The analogy: Azure Monitor is the building's own instrumentation — the smoke detectors, meters, and CCTV already wired into the walls. You do not install them. But almost none of them are recording to tape until you say where the tape lives, and there is no way to recover footage from before you plugged the recorder in.

That is the sentence that matters most in this whole topic. Concretely:

Platform metrics are collected automatically for every resource, at no cost, with a fixed retention period ⚠️ verify the current platform-metric retention against current Azure docs. You get them whether you ask or not.
The activity log — the subscription-level record of control-plane operations, "who created, changed, or deleted what" — is also collected automatically and kept for a limited window, and is free to query in place. Keeping it longer means exporting it.
Resource logs — the detailed, per-service diagnostic streams (Key Vault audit events, Storage read requests, App Service HTTP logs, AKS control-plane logs) — are collected nowhere by default. They exist only if a diagnostic setting on that resource routes them to a destination. No setting, no data, and no way to go back for it.

Most "Azure Monitor is broken" incidents are actually "nobody created the diagnostic setting".

Where it sits

Azure Monitor is in the management and governance category, and it is the substrate several other products are built on. Knowing the neighbours prevents a lot of wasted design argument:

Microsoft Sentinel is a SIEM layered onto a Log Analytics workspace. Same store, same KQL, additional analytics and a second meter. Use Sentinel when the question is "are we under attack", Azure Monitor when it is "is the system healthy". Deliberately putting both on one workspace is common and reasonable; doing it by accident is expensive.
Microsoft Defender for Cloud covers posture and workload protection. It overlaps at the storage layer, not the purpose layer.
Azure Service Health is Microsoft telling you about their outage. It arrives as activity-log events, so you alert on it through Azure Monitor.
Application Insights is not a separate product any more — it is Azure Monitor's application performance monitoring feature, and its data lives in a Log Analytics workspace.
Azure Monitor Workspace (Microsoft.Monitor/accounts) is the store for managed Prometheus metrics. It is a different resource from a Log Analytics workspace, holds a different data type, and is queried with PromQL rather than KQL. The name collision is unfortunate and permanent.
Change Analysis and Resource Health are small features that surface inside the Azure Monitor blade and are worth knowing exist, because they answer "what changed" faster than a KQL query will.

The AWS analogue, and where it breaks

Closest analogue: CloudWatch + CloudWatch Logs + X-Ray + a slice of EventBridge, in one service. The mapping holds at a coarse level — Metrics ≈ CloudWatch Metrics, Logs ≈ CloudWatch Logs Insights, Application Insights ≈ X-Ray plus RUM, alert rules ≈ CloudWatch Alarms, action groups ≈ SNS topics.

Where it breaks, and each of these has bitten a migration:

Nothing logs by default. In AWS a great many services deposit logs into a log group with little or no effort. In Azure, resource logs require an explicit diagnostic setting per resource, per destination. This is the single biggest instinct to unlearn.
One store, not one store per resource. CloudWatch gives every resource its own log group. Azure routes many resources into one Log Analytics workspace, where they land in shared, typed tables (AzureDiagnostics, or a resource-specific table). You query across resources by default, which is better for investigation and worse for isolation.
Agents are configured centrally, not locally. The Azure Monitor Agent takes its instructions from a Data Collection Rule — an ARM resource associated with the machine — not from a config file on the box. That is a genuine improvement, and it means agent configuration is IaC-able.
The query language is real. KQL is far more capable than CloudWatch Logs Insights syntax, and correspondingly steeper. Budget learning time; it pays back immediately.
Billing is by ingestion volume, not by alarm count. CloudWatch's cost surprises usually come from custom metrics and API calls; Azure Monitor's come from a single verbose log category.

[Image Prompt: 2D minimalistic diagram showing Azure Monitor sitting between upstream telemetry sources — Azure resources emitting platform metrics, resource logs via diagnostic settings, virtual machines with the Azure Monitor Agent, and applications sending Application Insights telemetry — and downstream consumers such as alerts, dashboards, workbooks, Grafana, and Microsoft Sentinel, flat design, clean vector art style, white background]

When NOT to use it

Honest anti-patterns, each of which someone has paid for:

Collecting everything "just in case." Turning on every diagnostic category for every resource is the classic first-week mistake. Verbose categories — Storage StorageRead, Application Gateway access logs, AKS kube-audit, NSG flow logs, Front Door access logs — can each individually exceed the volume of everything else combined. Pick categories deliberately, and use the Basic or Auxiliary table plan for the ones you only need for occasional forensics.
Using Logs where Metrics would do. If the question is "what was the average CPU", the metrics store answers it free, instantly, and at any resolution the platform kept. Writing the same number into a log table costs money per gigabyte and answers more slowly.
Long-term retention of application events for analytics. Log Analytics is priced for observability, not for a three-year product-analytics history. Route those events to a data lake and query them there.
Sub-second reaction loops. Ingestion latency plus alert-rule evaluation frequency means minutes. Do not build a control loop that assumes an alert fires the moment a threshold is crossed.
As your primary tool in a multi-cloud estate. If eighty percent of the fleet is elsewhere, keep the central pane where the fleet is and stream Azure telemetry to it — usually via a diagnostic setting pointed at an Event Hub, which is the supported export door.
Assuming it is a backup. A workspace is not a durable archive of record. Export what compliance requires to storage explicitly.

The one-paragraph version

Azure Monitor gives you the platform's own telemetry for free at the metric level, charges you by the gigabyte for everything richer, and collects almost none of the rich material until you explicitly route it. Metrics and Logs are separate stores with separate query models and separate economics. The design work is deciding what to collect, into which table plan, for how long — everything else in this topic is mechanics.

Next: Core Concepts →

← Back to the Azure Monitor overview