Azure Monitor Overview: Metrics, Logs, and Alerts

What Azure Monitor actually does

Azure Monitor is not a single service — it is a platform made up of several interconnected capabilities. When you deploy anything in Azure, Monitor starts collecting data almost immediately. A virtual machine emits CPU and disk metrics. An App Service instance reports HTTP response times. A storage account tracks transaction counts and latency. All of this flows into Azure Monitor without you writing a line of code.

At the highest level, Azure Monitor deals with two categories of data:

• Metrics — Numerical measurements collected at regular intervals (typically every 60 seconds). Examples: CPU percentage, memory used, requests per second, HTTP 5xx errors. Metrics are lightweight and ideal for real-time dashboards and fast alerting.
• Logs — Structured or semi-structured records that capture events, errors, traces, and detailed diagnostic information. Logs live in a Log Analytics workspace and are queried using Kusto Query Language (KQL).

On top of these data types, Monitor provides alerting, dashboards, workbooks, and integration with ITSM tools like ServiceNow and PagerDuty.

Where the data comes from

Azure Monitor ingests telemetry from a wide range of sources. Understanding these sources helps you know what monitoring is automatic and what requires explicit configuration.

Metrics: fast data for fast decisions

Platform metrics are stored in Azure Monitor’s time-series database for 93 days at no cost. They are available in near real-time — usually within 2–3 minutes of the underlying event. You can view them in the Metrics Explorer, pin them to dashboards, or use them to trigger metric alerts.

Metrics support multiple aggregations: average, minimum, maximum, sum, and count. When you are charting CPU usage, “average” gives you a trend line, but “maximum” reveals the worst-case spikes that can cause latency bursts.

You can query and export metrics using the Azure CLI:

# List available metrics for an App Service plan
az monitor metrics list-definitions \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Web/serverFarms/<plan-name> \
  --output table

# Retrieve CPU percentage for the last hour, averaged every 5 minutes
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Web/serverFarms/<plan-name> \
  --metric "CpuPercentage" \
  --interval PT5M \
  --start-time 2026-03-19T10:00:00Z \
  --end-time 2026-03-19T11:00:00Z \
  --aggregation Average \
  --output table

Logs: the full story behind every event

Logs capture context that metrics cannot. A metric can tell you that your error rate spiked at 2:14 PM. A log entry tells you which request failed, which user triggered it, what the exception stack trace was, and which downstream service returned an error.

Logs in Azure Monitor are stored in a Log Analytics workspace — a centralized repository that acts like a database. Multiple resources can send their logs to the same workspace, and you query across all of them using KQL.

Here is a basic KQL query to find errors in the last hour:

// Find all error-level events in the last hour
AzureDiagnostics
| where TimeGenerated > ago(1h)
| where Level == "Error"
| project TimeGenerated, ResourceType, OperationName, ResultDescription
| order by TimeGenerated desc
| limit 50

Alerts: from data to action

Azure Monitor alerts watch your metrics and logs continuously and notify you — or trigger automated responses — when conditions are met. There are four alert types:

• Metric alerts — Trigger when a metric crosses a static or dynamic threshold. Best for real-time conditions like high CPU or low available memory.
• Log search alerts — Run a KQL query on a schedule and alert when the result count or value meets a condition. Best for error patterns in log data.
• Activity log alerts — Trigger on Azure control-plane events like resource deletion, role assignment changes, or service health advisories.
• Smart detection alerts — Used by Application Insights to automatically detect anomalies in application telemetry without manual threshold configuration.

Alerts route through action groups — reusable collections of notification targets (email, SMS, webhook, Azure Function, Logic App, ITSM connector). One action group can be shared across many alert rules.

Enabling diagnostic settings

Many Azure services do not send their detailed logs to a Log Analytics workspace by default. You need to configure a diagnostic setting to enable this. You can do this through the portal, ARM templates, or the CLI.

# Enable diagnostic settings for an Azure SQL Database
az monitor diagnostic-settings create \
  --name "sql-diagnostics" \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/<server>/databases/<db> \
  --workspace /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace> \
  --logs '[{"category": "SQLInsights", "enabled": true}, {"category": "Errors", "enabled": true}]' \
  --metrics '[{"category": "Basic", "enabled": true}]'

How the pieces fit together

Think of Azure Monitor as the central nervous system for your cloud environment. Resources generate signals. Those signals flow into the metrics store and the Log Analytics workspace. Queries and thresholds evaluate those signals. Alerts fire and route to action groups. Workbooks and dashboards visualize everything for humans.

Application Insights adds application-level depth to this picture — tracking individual HTTP requests, dependencies, exceptions, and custom business events. Container Insights does the same for Kubernetes workloads. Network Watcher covers connectivity and packet-level diagnostics.

None of these are replacements for Azure Monitor — they are components within it, each covering a specific observability layer.