Sections

9. Glossary and Cheatsheet

10 min read

The ten-second lookup.

Glossary

Action group — A reusable set of notification channels (email, SMS, push, voice) and automated actions (webhook, Logic App, Function, runbook, ITSM connector) invoked by alert rules. The highest-leverage single object in your alerting setup: change it and every rule pointing at it changes.

Activity log — The subscription-level record of control-plane operations: who created, changed, or deleted what. Collected automatically, kept for a limited window, free to query in place; export it to keep it longer.

Alert processing rule — Suppression and routing applied after a rule fires. The correct mechanism for maintenance windows, and for attaching one action group to many rules at once.

Alert rule — A resource that evaluates a condition on a schedule and fires. Four kinds: metric alert (Microsoft.Insights/metricAlerts), log search alert (Microsoft.Insights/scheduledQueryRules), activity log alert, and Application Insights smart detection.

AMA — Azure Monitor Agent — The VM/Arc extension collecting guest-OS telemetry, configured exclusively through Data Collection Rules. Replaces the retired Log Analytics agent (also called the MMA or OMS agent).

AMPLS — Azure Monitor Private Link Scope — The object that groups workspaces and Application Insights components so a single private endpoint can serve them. Its access modes (Open vs. Private Only) apply to every resource in the scope, including ones added later.

Analytics / Basic / Auxiliary — The three table plans, trading ingestion price against query capability. Basic and Auxiliary cannot be targeted by log search alert rules.

Application Insights — Azure Monitor's application performance monitoring feature (Microsoft.Insights/components). Must be workspace-based; classic Application Insights, which stored data outside a workspace, is retired.

AzureDiagnostics — The legacy wide, sparse table into which many services' logs land unless the diagnostic setting specifies resource-specific mode. Prefer resource-specific tables for anything new.

Azure Monitor Logs — The store; the thing you pay for per gigabyte. Held in a Log Analytics workspace.

Azure Monitor Metrics — The platform time-series store. Free to collect and query for platform metrics, low latency, fixed retention, limited dimensionality.

Azure Monitor Workspace (Microsoft.Monitor/accounts) — The store for managed Prometheus metrics, queried with PromQL. Not a Log Analytics workspace, despite the name.

Commitment tier — Workspace pricing tier committing to a daily GB volume in fixed steps for a discount, with overage billed at the effective rate. A property change, not a migration.

Common alert schema — A single normalised payload shape across alert types. Turn it on in every action group so webhook handlers do not have to branch per alert type.

Container Insights — The curated AKS monitoring experience. Its default of collecting stdout and stderr from every namespace is the most common cause of a large Azure Monitor bill.

Daily cap — A hard ceiling on daily workspace ingestion that stops collection when reached. A circuit breaker, not a cost control.

DCE — Data Collection Endpoint — The regional ingestion endpoint a DCR or the Logs Ingestion API posts to, and the object a private endpoint targets for ingestion.

DCR — Data Collection Rule — The ARM resource defining data sources, destinations, and data flows for agent and custom telemetry, optionally with an ingestion-time transformation. Associated to machines via a DCR association.

Diagnostic setting — The extension resource on a monitored resource that selects log and metric categories and routes them to a workspace, storage account, Event Hub, or partner solution. Off by default. Nothing works without it.

Dynamic threshold — A metric alert condition using a learned baseline rather than a fixed number. The right choice for anything with daily or weekly seasonality.

Heartbeat — The table agents write to on a schedule. Querying it for stale entries is how you detect an agent that stopped reporting.

Insights — Curated experiences over the same data: VM Insights, Container Insights, Network Insights, Storage Insights. Convenience layers that also turn on collection, and therefore cost.

Instrumentation key — The legacy Application Insights identifier, retired in favour of the connection string, which also carries the regional ingestion endpoint.

Interactive vs. long-term retention — Interactive data is directly queryable; long-term data (formerly archive) is cheaper and reached via a search job or a data restore.

KQL — Kusto Query Language — The read-only query language for Logs, Application Insights, Sentinel, Resource Graph, and Azure Data Explorer. Filter on TimeGenerated first, always.

Log Analytics workspace (Microsoft.OperationalInsights/workspaces) — The regional resource owning tables, retention, pricing tier, network rules, and data-access RBAC. The unit of cost, data residency, and blast radius. Formerly part of Operations Management Suite (OMS).

Logs Ingestion API — The supported way to push arbitrary data into a workspace table, via a DCE and a DCR, authenticated with a Microsoft Entra token. Replaces the deprecated HTTP Data Collector API.

Resource-context vs. workspace-context — The two data-access modes. Resource-context lets a user with permission on an Azure resource query that resource's rows without workspace permission, and depends on rows carrying _ResourceId.

Sampling — Discarding a proportion of Application Insights telemetry while preserving statistical accuracy. Adaptive sampling runs in the SDK; ingestion sampling runs in the service.

Search job — A query run over long-term retention data whose results are written into a new table. Billed, and slower than an interactive query — rehearse one before you need it.

Severity — Sev 0 (most severe) through Sev 4. Metadata only; nothing behaves differently unless your action group makes it so.

Table — A typed columnar collection in a workspace. Custom tables end in _CL.

Transformation — A KQL snippet in a DCR run at ingestion time. Drops rows and columns before you pay for them — the most effective and most under-used cost lever available.

Workbook — A saved, parameterised, interactive report combining KQL, metrics, and text. An ARM resource, so deployable as code.

Cheatsheet

# --- Workspace ---
az monitor log-analytics workspace create -g $RG -n $LAW -l uksouth --retention-time 30
az monitor log-analytics workspace show   -g $RG -n $LAW --query customerId -o tsv   # the GUID
az monitor log-analytics workspace list   -o table

# --- Query (needs the workspace GUID, not the ARM ID) ---
az monitor log-analytics query -w $WS_GUID --analytics-query "Heartbeat | take 10" -o table

# --- Diagnostic settings: the thing nothing works without ---
az monitor diagnostic-settings list --resource "$RESOURCE_ID" -o table
az monitor diagnostic-settings categories list --resource "$RESOURCE_ID" -o table   # what CAN it emit
az monitor diagnostic-settings create -n diag-to-law --resource "$RESOURCE_ID" \
  --workspace "$LAW_ID" --export-to-resource-specific true \
  --logs '[{"categoryGroup":"audit","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

# --- Metrics ---
az monitor metrics list-definitions --resource "$RESOURCE_ID" -o table
az monitor metrics list --resource "$RESOURCE_ID" --metric "Percentage CPU" \
  --aggregation Maximum --interval PT5M -o table

# --- Alerts and action groups ---
az monitor action-group create -g $RG -n ag-critical --short-name crit --action email me a@b.com
az monitor metrics alert create -g $RG -n alert-cpu --scopes "$RESOURCE_ID" \
  --condition "max Percentage CPU > 90" --window-size 5m --evaluation-frequency 1m \
  --severity 2 --action ag-critical
az monitor metrics alert list -g $RG -o table
az monitor scheduled-query list -g $RG -o table

# --- Activity log: who did what ---
az monitor activity-log list --offset 1h --query "[?operationName.value contains 'delete']" -o table

# --- Data collection rules ---
az monitor data-collection rule list -g $RG -o table
az monitor data-collection rule association list --resource "$VM_ID" -o table

# --- Cost investigation, the two queries that matter ---
az monitor log-analytics query -w $WS_GUID --analytics-query \
  "Usage | where TimeGenerated > ago(30d) | where IsBillable | summarize GB=sum(Quantity)/1000 by DataType | order by GB desc" -o table

# --- Recovery ---
az monitor log-analytics workspace list-deleted-workspaces -o table
az monitor log-analytics workspace recover -g $RG -n $LAW

The KQL you will actually type

// Is anything arriving at all?
union withsource=T *
| where TimeGenerated > ago(1h)
| summarize rows = count(), latest = max(TimeGenerated) by T
| order by rows desc

// What is this costing, by table
Usage
| where TimeGenerated > ago(30d) and IsBillable == true
| summarize BillableGB = sum(Quantity) / 1000 by DataType
| order by BillableGB desc

// ...and by resource, for the worst table
AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize GB = sum(_BilledSize) / 1000000000 by _ResourceId
| order by GB desc

// Ingestion latency - before you believe "no data"
AzureDiagnostics
| where TimeGenerated > ago(2h)
| extend latency = ingestion_time() - TimeGenerated
| summarize p95 = percentile(latency, 95) by ResourceType

// Agents that stopped reporting
Heartbeat
| where TimeGenerated > ago(24h)
| summarize LastSeen = max(TimeGenerated) by Computer
| where LastSeen < ago(30m)

// Who changed monitoring configuration by hand
AzureActivity
| where TimeGenerated > ago(7d)
| where ResourceProvider in ("MICROSOFT.INSIGHTS", "MICROSOFT.OPERATIONALINSIGHTS")
| where OperationNameValue endswith "/write" or OperationNameValue endswith "/delete"
| where ActivityStatusValue == "Success" and Caller !contains "terraform-sp"
| project TimeGenerated, Caller, OperationNameValue, _ResourceId

// Application errors, grouped, last hour
AppExceptions
| where TimeGenerated > ago(1h)
| summarize count() by ProblemId, OperationName
| order by count_ desc

The one habit worth building: put the where TimeGenerated filter first, before anything else. Logs are time-partitioned, and this is the difference between scanning a day and scanning a year.

Resource ID shapes

# Log Analytics workspace
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{name}

# Application Insights component
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/components/{name}

# Data collection rule
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/dataCollectionRules/{name}

# Action group
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/actionGroups/{name}

# Log search alert rule
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/scheduledQueryRules/{name}

# Azure Monitor Workspace (managed Prometheus)
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Monitor/accounts/{name}

# Diagnostic setting - an EXTENSION resource: the monitored resource's ID, plus a suffix
{monitored-resource-id}/providers/Microsoft.Insights/diagnosticSettings/{name}

That last shape is the one to remember. It is why the permission to create a diagnostic setting is held against the monitored resource, not against the workspace — the single most common permission surprise in Azure Monitor automation.

And the other identifier trap: a workspace has both an ARM resource ID (used by diagnostic settings, policy assignments, and Terraform references) and a workspace GUID / customer ID (used by the query API, agents, and older SDKs). They are not interchangeable and the error messages when you swap them are unhelpful.

Limits worth memorising

Limit	Scope it is counted at
Ingestion volume rate	Per workspace
Daily cap	Per workspace (self-imposed; stops collection)
Query timeout, result size	Per query
Concurrent queries	Per workspace, per user
Diagnostic settings per resource	Per monitored resource
Alert rules	Per subscription
Action group notification rate	Per action group, per channel
Data collection rules	Per subscription, per region
Platform metric retention	Per subscription platform store (not raisable)

⚠️ Every number behind these is region-, region-pair-, and subscription-type-dependent, and changes — verify against current Azure docs before designing to one. The durable part is the scope column.

← Back to the Azure Monitor overview · ← Previous: Interview Questions