Azure Monitor
Azure Monitor is the platform's single observability service: every Azure resource emits metrics and logs into it, your own applications and virtual machines send telemetry into it, and you query, chart, and alert on all of it from one place. It is not one product but a family — Metrics, Logs, Application Insights, alerts, autoscale, and workbooks — sharing one ingestion story and one query language.
Names. Azure Monitor absorbed several products that people still search for under their old names. Log Analytics was Operations Management Suite (OMS) and is now the name of the workspace and the query experience, while the store itself is Azure Monitor Logs. Application Insights is now a feature of Azure Monitor and must be workspace-based — classic Application Insights resources, which held their own data outside a workspace, are retired. The Log Analytics agent (also written MMA or OMS agent) is retired and replaced by the Azure Monitor Agent (AMA); if a tutorial tells you to configure data collection on the workspace itself rather than in a Data Collection Rule, it is agent-era material. Azure Monitor Workspace is a newer, different resource that holds Prometheus metrics — it is not a Log Analytics workspace, and confusing the two costs people an afternoon. ⚠️ Verify current retirement and migration dates against current Azure docs.
What it is and where it fits
Every Azure resource is already emitting telemetry. Platform metrics — CPU, request count, queue depth, RU consumption — are collected automatically, for free, with no configuration at all. Almost everything else is opt-in: resource logs flow nowhere until you create a diagnostic setting that routes them somewhere. This single fact explains most Azure Monitor confusion. The first time you go looking for the logs of an incident that happened last week and find nothing, it is because nobody created the diagnostic setting, and there is no retroactive fix.
The problem Azure Monitor solves is fragmentation. Without it you would be running an agent fleet, a metrics store, a log store, a tracing backend, an alerting engine, and the glue between them — and you would still not have the platform's own view of the resource, which only Azure can produce. Azure Monitor's bargain is that the platform hands you the telemetry it already has, and in exchange you accept its data model, its query language (KQL), and its per-gigabyte ingestion bill.
Azure's monitoring catalogue overlaps itself, and knowing which door to walk through matters:
- Azure Monitor Metrics vs. Azure Monitor Logs — two stores, not one. Metrics is a numeric time-series database: cheap, fast, fixed retention, low dimensionality. Logs is a schema-on-write columnar store: expensive, flexible, arbitrary retention, arbitrary shape. The same event can live in both, and they are queried differently.
- Microsoft Sentinel — a SIEM built on top of a Log Analytics workspace. Same store, same KQL, different purpose and a second meter on the same data. If someone says "we already have the logs in Sentinel", they mean the workspace.
- Microsoft Defender for Cloud — security posture and workload protection. It also writes to a workspace. Monitor tells you the app is slow; Defender tells you the VM is exposed.
- Azure Service Health / Resource Health — Microsoft's view of their outage, not yours. It surfaces through Azure Monitor's activity log and alerting, which is why it feels like part of the same product.
- Azure Managed Grafana / Prometheus — Azure Monitor now speaks Prometheus natively (managed Prometheus writing into an Azure Monitor Workspace) and renders in Grafana. If your team already runs that stack, you do not have to abandon it to be on Azure.
The honest summary: Azure Monitor is not optional and not free-shaped. Treat it as a first-class resource you design, budget, and deploy with IaC — not as a checkbox you tick after go-live.
Key facts at a glance
| Category | Management & governance — observability |
| Resource providers | Microsoft.OperationalInsights/workspaces (Log Analytics), Microsoft.Insights/components (Application Insights), Microsoft.Insights/dataCollectionRules, Microsoft.Insights/scheduledQueryRules, Microsoft.Insights/metricAlerts, Microsoft.Insights/actionGroups, Microsoft.Insights/diagnosticSettings (an extension resource), Microsoft.Monitor/accounts (Azure Monitor Workspace) |
| Scope | Mixed. Metrics and the activity log are per-resource and per-subscription platform features; the workspace is a regional, resource-group-scoped resource; diagnostic settings are extension resources attached to the monitored resource, not to the workspace |
| SKU / tier axis | Two axes, both about money: the workspace pricing tier (pay-as-you-go per GB vs. commitment tiers bought in daily-GB steps) and the table plan — Analytics (full KQL, alerting), Basic (cheap ingest, restricted queries, no alerts), Auxiliary (cheapest, for high-volume low-value logs). Retention splits into interactive and long-term |
| Unit of billing | Predominantly GB ingested, then retention beyond the included period, then extras: alert rules, ITSM connectors, search jobs, data restore, web tests, and Prometheus samples. Queries themselves are generally free on Analytics tables and charged on Basic/Auxiliary ⚠️ verify against current Azure pricing |
| Query language | KQL (Kusto Query Language) for Logs; a separate, much simpler metrics query model for Metrics |
| SLA posture | The service has an availability SLA, but note the separate latency characteristic: log ingestion is not instant, and alert rules evaluate on their own cadence ⚠️ verify current latency targets |
| Usual companions | Every other Azure service (as a log source), Log Analytics workspace, Application Insights, Action Groups, Azure Policy (to enforce diagnostic settings), Managed Grafana, Microsoft Sentinel |
| Primary alternative | A third-party stack (Datadog, Splunk, Elastic, Grafana Cloud) fed from Event Hubs — common, and often the right call for multi-cloud shops |
| AWS analogue | CloudWatch + CloudWatch Logs + X-Ray + EventBridge-for-alerts, rolled into one. The analogy breaks on the opt-in point: CloudWatch Logs mostly appear by default for many services, whereas Azure resource logs appear nowhere until a diagnostic setting exists |
When to use it
- Always, for anything running in Azure. Platform metrics and the activity log are already there; the question is only how much more you turn on and where you route it.
- Alerting on Azure-native signals — resource health, autoscale events, quota, service health, and platform metrics. Nothing outside Azure sees these as cleanly.
- Application performance monitoring via Application Insights, especially if you want distributed tracing without standing up a tracing backend. It speaks OpenTelemetry.
- Ad-hoc incident forensics. KQL over a workspace holding weeks of resource logs is genuinely excellent, and there is no faster way to answer "which identity deleted that resource".
- Autoscale. Azure's autoscale engine is a part of Azure Monitor; scaling rules are metric rules.
When not to use it
- As a cheap, undesigned log dump. Ingestion is metered per gigabyte and verbose sources — AKS container stdout, Application Gateway access logs, NSG flow logs, chatty debug logging — will produce a bill that arrives before the value does. Design what you collect.
- As your only multi-cloud pane of glass. If most of your estate is elsewhere, forward from Azure into that tool rather than trying to pull the other clouds into Azure Monitor.
- As a business analytics store. Long retention of application events for product analytics is cheaper in a data lake or a warehouse. Route them there, not into an Analytics-plan table.
- As a real-time control loop. Ingestion and alert evaluation both have latency measured in minutes, not milliseconds. If a decision must be sub-second, take it in your own code path.
- For synthetic-heavy or highly custom dashboards where Grafana or a product-analytics tool is simply better UI — though you can keep Azure Monitor as the store and point Grafana at it.
Contents
| # | Sub-topic | What it covers |
|---|---|---|
| 1 | What & Why | The problem it kills, the opt-in trap, the AWS analogy and where it breaks |
| 2 | Core Concepts | Workspaces, tables and table plans, DCRs and DCEs, Application Insights, alerts, action groups, KQL |
| 3 | Architecture | The ingestion path end to end, control plane vs. data plane, metrics vs. logs internals, latency and throttling |
| 4 | Getting Started | A workspace, a diagnostic setting, and one alert — Portal, az, and minimal Terraform |
| 5 | Deployment | A parameterised Terraform module, Ansible, Bicep, CI/CD with OIDC, environments, rollback, drift |
| 6 | Integrations | Diagnostic settings, managed identity, Event Grid, Sentinel, Grafana, Logic Apps, Azure Policy |
| 7 | Production | Security, cost control, scaling and quotas, observability of the observer, reliability |
| 8 | Interview Questions | Conceptual, technical-depth, and scenario questions with answer keys |
| 9 | Glossary & Cheatsheet | Every term in one line each, the commands you actually type, resource ID shapes, limits |
Reading paths
New to Azure Monitor — What & Why, then Core Concepts, then Getting Started. The single idea to internalise early is that metrics and logs are two different stores.
Coming from CloudWatch — read Core Concepts and the control-plane section of Architecture first. Diagnostic settings and Data Collection Rules have no CloudWatch equivalent, and they are where every migration stalls.
Need to ship this week — Deployment, then the cost section of Production. Enforcing diagnostic settings with Azure Policy is the piece most teams retrofit painfully; do it up front.
Interview or certification prep — Core Concepts, Architecture, and Interview Questions. The metrics-vs-logs question and the "why is my Log Analytics bill enormous" question come up constantly in AZ-104 and AZ-305 interviews.
Chasing a cost surprise — the cost section of Production, then table plans in Core Concepts. The culprit is nearly always one verbose diagnostic setting or one AKS cluster with container stdout collection left at its default.
Azure Monitor assumes the platform basics — subscriptions, resource groups, ARM, and RBAC inheritance. Those live in foundations.
Next: What & Why →