Azure Monitor is Azure's umbrella observability service. It is not one product so much as a platform: a set of data stores (metrics, logs, traces, changes), a collection layer that feeds them, and a set of tools that sit on top for querying, visualising, alerting and automating. Application Insights, Log Analytics, Container insights, VM insights and Azure Monitor managed Prometheus are all features of it rather than separate services.

The useful mental model is three layers:

 SOURCES                    COLLECTION                     DATA PLATFORM                 CONSUMPTION
 ───────                    ──────────                     ─────────────                 ───────────
 Applications ───────────── OpenTelemetry / App Insights ┐
 VMs / Arc servers ──────── Azure Monitor Agent + DCRs ──┤
 AKS / Kubernetes ───────── Container insights, Prom ────┼──► Metrics (platform/custom) ─┐
 Azure resources ────────── Platform metrics (automatic) ┤    Logs (Log Analytics) ─────┼──► Metrics explorer, Log Analytics (KQL)
                            Diagnostic settings ─────────┤    Traces (App Insights) ────┤    Workbooks, dashboards, Grafana
 Subscription / tenant ──── Activity log, Entra logs ────┤    Prometheus metrics ───────┤    Alerts → action groups
 Custom sources ─────────── Logs Ingestion API ──────────┘    (Azure Monitor workspace)  │    Autoscale, Logic Apps, export
                                                              Changes (Change Analysis) ─┘

The data platform¶

Everything Azure Monitor does depends on where the data lands, so the stores are worth understanding first.

Metrics¶

Metrics are numeric time series: a value, a timestamp, and a set of dimensions. They are lightweight, near-real-time (often available within a minute), and cheap to query, which makes them the right foundation for fast alerting and autoscale.

• Platform metrics are emitted automatically by almost every Azure resource at no cost, at one-minute granularity, and kept for 93 days.
• Custom metrics come from applications (via Application Insights) or from the Azure Monitor Agent, and are billed.
• Prometheus metrics go to a separate store, the Azure Monitor workspace, which is the backend for Azure Monitor managed service for Prometheus. It speaks PromQL and is typically paired with Azure Managed Grafana.

You can route platform metrics into Log Analytics through diagnostic settings if you need longer retention or want to join them with logs in KQL.

Logs (Log Analytics workspaces)¶

Logs are the heavy-lifting store. A Log Analytics workspace holds structured records in tables, queried with the Kusto Query Language (KQL). Resource logs, the activity log, VM logs, container logs, Application Insights telemetry and custom data all end up as tables here.

Key points about workspaces:

• Tables and schemas. Azure-defined tables (e.g. AzureDiagnostics, ContainerLogV2, AppRequests) plus custom tables whose names end in _CL.
• Table plans let you trade query capability for cost on a per-table basis:

• Retention has two parts: interactive (analytics) retention, where data is fully queryable, and long-term retention, where data is kept cheaply and pulled back with search jobs or restore. Total retention can be set up to 12 years.
• Access control is either workspace-centric (RBAC on the workspace) or resource-centric (you see the rows for resources you have access to). Table-level RBAC is available for finer splits.
• Design. Fewer workspaces is usually better: one per region or per environment is a common pattern. Split only for data sovereignty, billing separation, or hard access boundaries. Cross-workspace queries with workspace() and resource-centric queries with _ResourceId cover most "I need data from over there" cases.

Traces¶

Distributed traces (requests, dependencies, spans) are collected by Application Insights and stored in the Log Analytics workspace that backs it (AppRequests, AppDependencies and related tables). See Application Insights below.

Changes¶

Change Analysis records configuration changes to Azure resources (from Azure Resource Graph) and surfaces them next to incidents, answering "what changed just before this broke?"

Data sources¶

Collection: how data gets in¶

Diagnostic settings¶

Resource logs are off by default. Each resource needs a diagnostic setting that picks log categories (and optionally metrics) and sends them to one or more destinations:

• a Log Analytics workspace (query and alert),
• a storage account (cheap archive),
• an Event Hub (stream to a SIEM, Elastic, Splunk or a custom consumer),
• a partner solution.

At scale, deploy diagnostic settings with Azure Policy (DeployIfNotExists) or Terraform rather than clicking through each resource. Prefer resource-specific destination tables over the legacy shared AzureDiagnostics table where the resource supports it; they are easier to query and work with table plans.

Azure Monitor Agent and data collection rules¶

The Azure Monitor Agent (AMA) is the single agent for VMs, scale sets and Arc-enabled servers. It replaced the Log Analytics agent (MMA/OMS), which was retired in August 2024.

AMA is driven by data collection rules (DCRs): Azure resources that declare what to collect, how to transform it, and where to send it. A DCR is associated with one or more machines through a data collection rule association, so one rule can apply to a whole fleet.

DCRs also support ingestion-time transformations: a KQL statement that runs before the data is stored. Use these to drop noisy columns or rows, parse fields, mask sensitive values, or route data to a different table. Filtering at ingestion is the single most effective cost lever in Azure Monitor.

Logs Ingestion API¶

For custom sources, the Logs Ingestion API accepts JSON over HTTPS, authenticated with Microsoft Entra ID, and writes through a DCR (and its transformation) to a custom or supported standard table. It replaced the older HTTP Data Collector API.

OpenTelemetry¶

Microsoft's recommended path for application telemetry is the Azure Monitor OpenTelemetry Distro (.NET, Java, Node.js, Python), which packages the OpenTelemetry SDK with an Azure Monitor exporter. The classic Application Insights SDKs still work but are no longer where new investment goes. Java uses an auto-instrumentation agent jar; App Service, Functions and AKS offer codeless auto-instrumentation for several runtimes.

Analysis and visualisation¶

• Metrics explorer. Chart and split metrics by dimension; pin charts to dashboards.
• Log Analytics. The KQL query editor over the workspace. Saved queries, query packs and functions make queries reusable.
• Workbooks. Interactive, parameterised reports that mix KQL, metrics, Azure Resource Graph and text. Most of the built-in "insights" experiences are workbooks under the hood.
• Azure dashboards. Pinned tiles across resources; shareable via RBAC.
• Grafana. Azure Managed Grafana, or the Grafana-based dashboards built into the Azure portal, with Azure Monitor and Prometheus data sources.
• Insights. Curated experiences per resource type, such as VM insights, Container insights, Network insights, and Storage/Key Vault/Cosmos DB insights.

A short KQL example: failed requests by operation over the last hour, workspace-based:

AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| summarize failures = count() by OperationName, ResultCode
| order by failures desc

Alerts and response¶

An alert rule has three parts: scope (what to watch), condition (what counts as a problem), and actions (what happens).

Action groups are reusable lists of notifications (email, SMS, push, voice) and actions (webhook, Azure Function, Logic App, Automation runbook, ITSM, Event Hub). Alert processing rules add or suppress action groups at scale, for example to silence everything in a resource group during a maintenance window.

Alerts can be stateful (fire once, then resolve when the condition clears) or stateless. Stateful is the right default for paging.

Beyond alerts, Azure Monitor data also drives autoscale (scale on metrics or schedule) and can be exported continuously through data export (Log Analytics to storage or Event Hub) or diagnostic settings.

Application Insights¶

Application Insights is Azure Monitor's application performance monitoring (APM) feature. Since the classic resource type was retired in February 2024, every Application Insights resource is workspace-based: telemetry is stored in a Log Analytics workspace, and the resource itself is the ingestion front door and the APM experience.

Application (OpenTelemetry Distro / SDK / auto-instrumentation)
    │  authenticates with the connection string
    ▼
App Insights ingestion endpoint
    │  stores data in
    ▼
Log Analytics workspace (AppRequests, AppTraces, AppExceptions, ...)
    │  surfaced back through
    ▼
App Insights experiences and query endpoint (requests, traces, exceptions, ...)

The ingestion side and the storage side are covered in more detail in Instrumentation key, connection string and workspace.

Telemetry data model¶

All of these share operation_Id (OperationId in the workspace), which ties one end-to-end transaction together across services.

Key features¶

• Application map. The topology of components and dependencies, with health and latency on each edge.
• Transaction search and end-to-end transaction details. Follow one operation across services.
• Live metrics. A near-real-time stream of request rate, failures and CPU, with no sampling and no storage cost.
• Failures and Performance blades. Triage views over requests, dependencies and exceptions.
• Availability tests. Synthetic probes from Azure regions. Standard tests are the single-request test type; classic URL ping tests were scheduled for retirement on 30 September 2026. Multi-step and custom scenarios use TrackAvailability() from an Azure Function.
• Usage analytics. Users, sessions, funnels, cohorts, retention and user flows from browser telemetry.
• Profiler and Snapshot Debugger. Production code-level traces and exception snapshots for .NET.
• Smart detection. Automatic anomaly alerts on failure rates and performance.

Connection strings, not instrumentation keys¶

Use the connection string, not the bare instrumentation key. Technical support for instrumentation-key-only ingestion ended on 31 March 2025. Connection strings carry the regional ingestion endpoint (and the key), which also makes private link, sovereign clouds and Entra ID (local-auth-disabled) ingestion work properly.

Sampling¶

High-traffic applications should sample. Options are adaptive sampling (SDK adjusts the rate to a target volume), fixed-rate sampling (consistent across client and server so traces stay whole), and ingestion sampling (applied at the endpoint, a last resort because you still pay egress). The OpenTelemetry Distro uses a fixed-rate sampler. Sampled records carry an itemCount so aggregates stay accurate; use sum(itemCount) rather than count() when counting sampled data.

Security and networking¶

• RBAC. Built-in roles include Monitoring Reader, Monitoring Contributor, Log Analytics Reader and Log Analytics Contributor. Grant at the narrowest scope that works, and use resource-context access so teams only see their own resources' logs.
• Managed identities and Entra auth. AMA, the Logs Ingestion API and Application Insights (with local auth disabled) authenticate with Entra ID instead of shared keys.
• Azure Monitor Private Link Scope (AMPLS). Brings workspace and Application Insights ingestion and query onto private endpoints. AMPLS affects DNS for all Azure Monitor traffic from that network, so plan it centrally, not per team.
• Customer-managed keys for workspaces via a dedicated cluster.
• Data hygiene. Use DCR transformations to strip secrets and personal data before storage; the purge API exists but is slow and meant for exceptions.

Cost management¶

Azure Monitor bills mainly on log ingestion volume (GB), with extra charges for long-term retention, Basic/Auxiliary queries, custom metrics, alert rules, and some features. Levers, roughly in order of impact:

1. Do not collect what you will not use. Review diagnostic setting categories and DCR counters; verbose categories add up fast.
2. Transform at ingestion. Drop rows and columns in the DCR.
3. Choose the right table plan. Move high-volume, low-value tables to Basic or Auxiliary.
4. Sample application telemetry.
5. Commitment tiers on the workspace (or a dedicated cluster) once daily volume is predictable.
6. Tune retention. Short interactive retention, longer long-term retention.
7. Daily cap as a safety net, not a budget control, because it stops ingestion, including data you need.

Find the noisy sources with the Usage table:

Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = sum(Quantity) / 1024 by DataType
| order by GB desc

Infrastructure as code¶

Most Azure Monitor configuration is ordinary ARM resources, so it belongs in Terraform or Bicep alongside the workloads it watches. The AzureRM provider resources you will use most:

Export Application Insights connection strings to Key Vault or app settings from Terraform outputs instead of copying them around by hand.

Deprecations and changes to know¶

Quick reference¶

See also¶

• Application Insights
• Instrumentation key, connection string and workspace
• Application Insights resources
• Azure Monitor overview (Microsoft Learn)
• Azure Monitor data platform (Microsoft Learn)
• Log Analytics table plans (Microsoft Learn)
• Azure Monitor best practices: cost (Microsoft Learn)