2. Core Concepts

Azure Monitor has more nouns than most Azure services because it is several products under one name. This page defines every one you will meet in the portal, in the order they become relevant: the two stores, the things that fill them, the things that read them, and the things that shout at you.

The two stores

Everything else follows from this split. Get it wrong and every later decision is wrong.

	Azure Monitor Metrics	Azure Monitor Logs
Shape of data	Numeric time series: one value, a timestamp, a few dimensions	Typed records: many columns, arbitrary text, arbitrary shape
Written by	The platform, automatically; plus custom metrics you publish	Diagnostic settings, agents, the ingestion API, Application Insights SDKs
Stored in	A platform time-series database attached to the subscription — you do not create a resource for it	A Log Analytics workspace you create and pay for
Queried with	The metrics explorer / metrics API — aggregation over a time grain	KQL, a full query language
Retention	Fixed platform retention ⚠️ verify current value	Configurable per table, from days to years
Cost	Platform metrics are free to collect and query; custom metrics are metered	Metered per GB ingested, plus retention beyond the included period
Latency	Low — usually the freshest signal you have	Higher — ingestion latency is measured in minutes ⚠️ verify current targets
Best for	Dashboards, autoscale, fast threshold alerts	Investigation, correlation, audit, anything needing text or joins

The same event often exists in both. A Storage account's throttled-request count is a metric; the individual throttled request, with its caller IP and blob name, is a log — and only if a diagnostic setting is routing StorageRead somewhere.

The workspace and what lives in it

Log Analytics workspace · Analogy: the database you rent for your logs, with its own postcode and its own bill. · Technically: a regional ARM resource (Microsoft.OperationalInsights/workspaces) that owns a set of tables, a pricing tier, retention settings, network access rules, and the RBAC that governs reading the data inside it. It is the unit of cost, the unit of data residency, and the unit of most query scoping.

Table · Analogy: one spreadsheet per kind of telemetry. · Technically: a typed, columnar collection within the workspace. Some are built by Microsoft with fixed schemas (Heartbeat, AzureActivity, SigninLogs, AppRequests, ContainerLogV2), some are resource-specific, and some are custom tables you create — custom table names end in _CL.

AzureDiagnostics vs. resource-specific tables · Two ways a resource's logs can land. The legacy mode dumps every service's logs into one wide, sparse AzureDiagnostics table with column-name collisions and a column-count ceiling; resource-specific mode gives each log category its own properly-typed table. Choose resource-specific for anything new — it queries faster, costs less to scan, and permits table-level RBAC. The choice is made in the diagnostic setting and is annoying to change later.

Table plan · Analogy: how good a seat the data gets. · Technically: the per-table tier that decides price and capability. There are three, and this is a genuine design decision, not a footnote:

Plan	What it buys	What it costs you
Analytics	Full KQL, joins, alerting on the table, use in workbooks and dashboards	The highest ingestion price
Basic	Much cheaper ingestion for high-volume operational logs	Restricted query surface (single-table, limited operators), no log alert rules on the table, and queries are charged per GB scanned
Auxiliary	The cheapest ingest, aimed at very high-volume, low-value logs kept mostly for compliance and occasional search	The most restricted queries, longest latency, search-job-oriented access

⚠️ Which tables support which plan changes as the feature matures — verify against current Azure docs before committing a design.

Retention: interactive vs. long-term · Analogy: the filing cabinet by the desk versus the box in the basement. · Technically: each table has an interactive retention period during which data is directly queryable, after which it moves to long-term retention (formerly called archive) at a much lower storage price. Long-term data is not directly queryable — you reach it with a search job (runs a query over the archive and writes results into a new table) or a data restore (rehydrates a time range for normal querying). Both are billed operations. Design retention on purpose: the default is applied workspace-wide and then overridden per table.

Commitment tier · Analogy: buying a season ticket instead of daily fares. · Technically: a workspace pricing tier where you commit to a daily ingestion volume in fixed steps and receive a discount, with overage billed at the effective rate. Above a modest daily volume this is nearly always cheaper than pay-as-you-go, and switching is a property change, not a migration. ⚠️ Verify current tier steps and discount percentages.

Daily cap · A hard ceiling on daily ingestion that stops collection when hit. It protects the bill and destroys your evidence at exactly the moment you most need it. Use it as a circuit breaker with an alert on the cap being reached, never as a routine cost control.

[Image Prompt: 2D minimalistic labelled hierarchy diagram of Azure Monitor, showing a subscription containing a resource group with a Log Analytics workspace, the workspace containing typed tables each carrying a table plan and a retention setting, and separate boxes for the platform metrics store and an Azure Monitor Workspace holding Prometheus metrics, flat design, clean vector art style, white background]

The things that fill the stores

Diagnostic setting · Analogy: the pipe you bolt onto a resource to make its logs go somewhere. · Technically: an extension resource (Microsoft.Insights/diagnosticSettings) attached to the monitored resource — not to the workspace — that selects log categories and metric categories and routes them to up to a handful of destinations: a Log Analytics workspace, a storage account, an Event Hub, or a partner solution. Key properties: it is per-resource, it is off by default, several can coexist on one resource, and its ARM scope is the monitored resource, which matters for both RBAC and Terraform.

Category group · A shorthand in a diagnostic setting — allLogs or audit — instead of naming each category. Convenient, and a common cause of surprise bills, because allLogs grows when the service adds a category.

Azure Monitor Agent (AMA) · Analogy: the meter reader you install on a machine. · Technically: the extension installed on Azure VMs, Arc-enabled servers, and VM Scale Sets that collects guest-OS telemetry — performance counters, Syslog, Windows event logs, text logs. It replaces the retired Log Analytics/OMS agent and the Telegraf-based diagnostics extension for most cases. Critically, it is configured entirely by Data Collection Rules, not locally.

Data Collection Rule (DCR) · Analogy: the standing instruction that says what to collect, how to reshape it, and where to put it. · Technically: an ARM resource (Microsoft.Insights/dataCollectionRules) with three parts — data sources (what to collect), destinations (which workspace), and data flows (which source goes to which destination, into which stream, optionally through a transformation). A DCR is associated with a machine or a resource through a Data Collection Rule Association. One DCR can serve thousands of machines, and one machine can have several DCRs whose instructions are merged.

Transformation · A KQL snippet inside a DCR, run at ingestion time. It can drop rows you do not want to pay for, drop or add columns, redact a field, or route to a different table. This is the single most effective cost lever in Azure Monitor and the most under-used. Note the honest caveat: transformations run on ingested data and there is a processing cost consideration, and a filtered-out row is gone forever.

Data Collection Endpoint (DCE) · The regional ingestion endpoint a DCR or the Logs Ingestion API posts to. You need one explicitly in some configurations — notably private-link and certain custom ingestion paths — and not in others. If you are wiring private connectivity, this is the object the private endpoint targets.

Logs Ingestion API · The supported way to push your own arbitrary data into a workspace table: authenticate with a Microsoft Entra token, POST to a DCE, and the DCR decides the shape and destination. It replaces the deprecated HTTP Data Collector API.

Application Insights · Analogy: the tracer dye you inject into your application. · Technically: an ARM resource (Microsoft.Insights/components) representing an application's telemetry — requests, dependencies, exceptions, traces, custom events and metrics, distributed traces — that must be workspace-based, meaning its data physically lives in tables inside a Log Analytics workspace. Its vocabulary is worth knowing: the instrumentation key is legacy and being retired in favour of the connection string; sampling (adaptive on the SDK, ingestion sampling on the service) discards a proportion of telemetry to control cost while preserving statistical accuracy; Live Metrics is a separate, non-persisted, near-real-time stream; availability tests ping your endpoint from Microsoft's regions — note the classic URL ping test is retired in favour of standard tests. ⚠️ Verify current retirement dates. Modern instrumentation is OpenTelemetry-based via the Azure Monitor OpenTelemetry Distro, which is the right default for new code.

Azure Monitor Workspace · Analogy: a second, numbers-only warehouse. · Technically: Microsoft.Monitor/accounts, the store for Azure Monitor managed service for Prometheus. Queried with PromQL, typically rendered through Azure Managed Grafana. It is not a Log Analytics workspace and cannot be used as one.

The things that read the stores

KQL (Kusto Query Language) · Analogy: SQL that reads left-to-right as a pipeline. · Technically: the read-only query language for Logs, Application Insights, Sentinel, Resource Graph, and Azure Data Explorer. A query starts with a table and pipes through operators:

AzureDiagnostics
| where TimeGenerated > ago(1h)
| where ResourceType == "VAULTS" and ResultType != "Success"
| summarize failures = count() by identity_claim_upn_s, bin(TimeGenerated, 5m)
| order by failures desc

The operators worth learning on day one: where, project, extend, summarize, bin, join, union, parse, render, top, mv-expand, and ago/between for time. The single most common performance mistake is filtering on time after other operators instead of first.

Query scope · A query runs against a scope: a workspace, an Application Insights resource, a single Azure resource, or several at once via union workspace("x").Table. Scope determines both what data is visible and which permission model applies.

Workbook · A saved, parameterised, interactive report combining KQL results, metrics charts, and text. It is an ARM resource, so it is deployable — treat your good workbooks as code.

Dashboard · The Azure portal's pinned-tile surface. Simpler than workbooks, shareable as an ARM resource, and generally less useful for anything with parameters.

Insights · Curated, pre-built experiences over the same data: VM Insights, Container Insights (AKS), Network Insights, Storage Insights, Application Insights' Application Map. They are convenience layers, not separate stores — and they turn on data collection, which means they turn on cost.

The things that shout at you

Alert rule · Analogy: a standing order to check something and raise a hand. · Technically: an ARM resource that evaluates a condition on a schedule and fires. The types you must be able to tell apart:

Type	Resource type	Evaluates	Notes
Metric alert	Microsoft.Insights/metricAlerts	Platform or custom metrics	Fast, cheap, near-real-time. Supports dynamic thresholds (a learned baseline) and multi-resource scope
Log search alert	Microsoft.Insights/scheduledQueryRules	A KQL query on a workspace or Application Insights	The flexible one. Priced per rule and per evaluation frequency; cannot run against Basic-plan tables
Activity log alert	Microsoft.Insights/activityLogAlerts	Control-plane events, service health, resource health	How you alert on "someone deleted the production resource group"
Smart detection / anomaly	Application Insights feature	Learned application behaviour	Automatic, opinionated, occasionally noisy

Severity · Sev 0 through Sev 4, with 0 the most severe. It is metadata: nothing behaves differently by severity unless your action group or ITSM integration makes it so.

Alert processing rule · Suppression and routing applied after a rule fires — the mechanism for maintenance windows and for attaching one action group to many rules at once. Use it instead of disabling rules during a deployment.

Action group · Analogy: the phone tree. · Technically: a reusable list of notifications (email, SMS, push, voice) and actions (webhook, Logic App, Azure Function, Automation runbook, Event Hub, ITSM connector) that alert rules invoke. Build a few by severity and reuse them; do not attach recipients directly to rules.

Autoscale setting · Also part of Azure Monitor: Microsoft.Insights/autoscaleSettings evaluates metric rules and changes instance counts on VM Scale Sets, App Service Plans, and others. It shares the metrics store, which is why an autoscale misfire and a metric alert misfire usually have the same root cause.

The identity and scoping model

Azure Monitor's resources sit in the ordinary hierarchy — see the scope hierarchy — with one wrinkle: diagnostic settings are extension resources, so their ARM ID is the monitored resource's ID with the diagnostic-setting path appended, and the permission to create one is held against the monitored resource, not against the workspace.

Reading data has its own model, covered in detail in Architecture:

• Workspace-context access — you have permission on the workspace, so you can see everything in it. Simple, and often too broad.
• Resource-context access — you have permission on an Azure resource, so you can see that resource's rows in the workspace even without workspace permission. This is the mode you want for application teams, and it depends on the rows carrying a _ResourceId.
• Table-level RBAC — a custom role that grants or denies specific tables, for the cases where the first two are not granular enough.

Terms in one table

Term	Analogy	Technical definition
Log Analytics workspace	The database you rent for logs	Regional Microsoft.OperationalInsights/workspaces resource owning tables, retention, pricing tier, and data-access RBAC
Diagnostic setting	The pipe bolted onto a resource	Extension resource selecting log/metric categories on one resource and routing them to a workspace, storage, Event Hub, or partner
Table plan	How good a seat the data gets	Per-table tier — Analytics, Basic, or Auxiliary — trading ingestion price against query capability and alerting
Data Collection Rule	The standing collection instruction	ARM resource defining data sources, destinations, and flows, optionally with an ingestion-time KQL transformation
Azure Monitor Agent	The meter reader on the machine	VM extension collecting guest-OS telemetry, configured exclusively through DCRs
Application Insights	Tracer dye in the application	Workspace-based Microsoft.Insights/components resource holding request, dependency, exception, and trace telemetry
Action group	The phone tree	Reusable set of notification channels and automated actions invoked by alert rules
KQL	SQL as a left-to-right pipeline	The read-only query language for Logs, Application Insights, Sentinel, and Resource Graph
Azure Monitor Workspace	A numbers-only second warehouse	Microsoft.Monitor/accounts, the store for managed Prometheus metrics, queried with PromQL
Commitment tier	A season ticket for ingestion	Workspace pricing tier committing to a daily GB volume for a discount, with overage billed at the effective rate

---

Next: Architecture →

← Back to the Azure Monitor overview · ← Previous: What & Why