Azure MonitorAuthorCloudBrum editorial teamLast reviewed30 Oct 2026Reading time~12 minLevelBeginner to advanced

• Metrics with no setupAzure resources publish platform metrics automatically. They are kept for 93 days and arrive within about a minute, which is quick enough for autoscale and metric alerts.
• Log Analytics and KQLA workspace stores logs in tables. Kusto Query Language reads them, and one query can join logs from many resources, subscriptions and even other clouds that you connect.
• Application InsightsIt records requests, dependencies, exceptions, traces and page views from your application, shows a map of how services call each other, and runs availability tests from several locations.
• Alerts that can call anythingMetric alerts, log search alerts and activity log alerts notify an action group. A group can send email, SMS, a push message or voice call, or call a webhook, a Logic App, a Function or an ITSM tool.
• Data collection rulesAzure Monitor Agent doesn’t decide what to collect. A data collection rule does, so you change what a thousand machines send by editing one rule and not logging in to each of them.
• Prometheus and GrafanaManaged Prometheus stores Prometheus metrics in an Azure Monitor workspace, so Kubernetes teams keep PromQL and their dashboards. Azure Monitor dashboards with Grafana became generally available in 2026.
• Workbooks and insightsWorkbooks turn queries and metrics into interactive reports. Ready-made views for virtual machines, containers, networks and storage cover the common questions.
• Plans for different kinds of logsAnalytics logs are fully queryable. Basic and Auxiliary logs cost much less per gigabyte for high-volume data that you rarely search, with a narrower set of features.

Platform metrics and custom metrics

Platform metrics come from Azure resources by themselves and are kept for 93 days. Custom metrics are the ones your application or agent adds.

Log Analytics workspace

A store for log data with its own region, access control, retention and price settings. One workspace per environment is a common start.

Table

A set of records of one kind inside a workspace, such as Heartbeat, AppRequests or AzureActivity. A table has a plan (Analytics, Basic or Auxiliary) and a retention.

Kusto Query Language (KQL)

The read-only query language for logs: a table name, then a chain of operators separated by pipes.

Application Insights

The application performance monitoring part, stored in a Log Analytics workspace. New resources are workspace-based.

Azure Monitor Agent (AMA)

The agent that collects data from virtual machines, scale sets and Arc-enabled servers. It replaced the older Log Analytics agent, which was retired in August 2024.

Data collection rule (DCR)

A set of instructions that says which data to collect, how to transform it and where to send it.

Diagnostic setting

A setting on an Azure resource that sends its resource logs and metrics to a workspace, a storage account or an event hub.

Activity log

The record of subscription-level operations, such as who created or deleted a resource. It is kept for 90 days by default.

Alert rule and action group

A rule decides when an alert fires. An action group says who or what to notify, and it can be reused by many rules.

Azure Monitor workspace

A separate store for Prometheus metrics. It isn’t the same thing as a Log Analytics workspace.

Commitment tier

A discount for committing to a daily volume of Analytics log ingestion, starting at 100 GB a day.

Azure Monitor Private Link Scope (AMPLS)

The resource that lets monitoring traffic travel over private endpoints instead of the public internet.

Set up monitoring for an application with the Azure CLI

1. Pick the workspace layoutDecide how many Log Analytics workspaces you need. One per environment in a region is simple and keeps access control clear. Split further only for a legal, residency or cost reason.
2. Create the workspace with a retentionChoose the region, set the default retention (30 days is the default, and up to two years is available), and note who needs access.
3. Connect the resourcesAdd a diagnostic setting on each resource that has logs, or let Azure Policy deploy them for you. Install Azure Monitor Agent on machines and link a data collection rule.
4. Add Application Insights to the appCreate a workspace-based Application Insights resource and add the OpenTelemetry-based Azure Monitor distro to the code, or turn on the built-in auto-instrumentation for App Service and Functions.
5. Build the action groupCreate an action group with the on-call channel. Add a second channel for the case where the first fails, and test it.
6. Write alert rules for symptomsAlert on failed requests, response time and availability tests, using a few evaluation periods so one blip doesn’t page anyone. Add resource-level alerts only where they have helped.
7. Choose a plan for each noisy tableMove verbose, rarely searched tables to the Basic or Auxiliary plan, and send the rest to Analytics. Drop columns and rows you never use with a transformation in the data collection rule.
8. Build one workbook or dashboardShow request rate, failures, latency and dependency health on one page, and link it from the runbook.
9. Review cost and noise every monthUse the Usage table to see which data types cost the most, and remove alerts that nobody acts on.

• Query with a time range and a where filter first, and project only the columns you need.
• Use summarize and bin for dashboards instead of returning raw rows to the client.
• Keep dashboard queries light, and cache or schedule the heavy ones.
• Choose fixed-rate or ingestion sampling deliberately, and keep errors at full rate.
• Use data collection rule transformations to drop noise before it is stored.
• Send application telemetry through the OpenTelemetry distro, with batching, so exporting doesn’t slow requests.
• Put the workspace in the region where most of the data is produced.
• Use query packs and saved functions so common queries are reviewed once and reused.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Azure Monitor.

• Find the expensive tables first: query Usage by DataType and look at the top five.
• Move verbose, rarely queried tables to the Basic or Auxiliary plan, which cost a fraction per gigabyte.
• Use transformations in data collection rules to drop columns and rows that nobody reads.
• Consider a commitment tier once Analytics ingestion is steady at around 100 GB a day or more.
• Prefer resource-specific tables over the shared AzureDiagnostics table, which tends to grow wide and costly.
• Keep retention to what you need. The first period is included, and longer interactive retention costs per gigabyte a month.
• Set a daily cap on development workspaces, and alert on unusual ingestion in production.
• Don’t forget alert rules: each rule, and each metric time series that a dynamic rule watches, can be billed.
• Turn off Application Insights features you don’t use, such as verbose dependency tracking in noisy services.
• Tag workspaces with an owner and add a budget alert on Azure Monitor spend.

• Give people Azure RBAC roles such as Monitoring Reader, Log Analytics Reader or Contributor at the narrowest scope.
• Use resource-context access and table-level roles so a team sees only its own logs.
• Keep sensitive data out of telemetry, and use transformations to drop or mask fields.
• Use an Azure Monitor Private Link Scope and block public ingestion and query access where policy requires it.
• Turn off local authentication on Application Insights, and use Microsoft Entra authentication from the app.
• Use customer-managed keys on a dedicated cluster when a rule demands your own key.
• Send audit and security logs to a central workspace with restricted delete and a long retention.
• Review who can edit alert rules, action groups and data collection rules, since changing them can hide a problem.
• Protect action group webhooks with secure webhooks or a secret, and keep secrets out of the URL.
• Use Azure Policy to deploy diagnostic settings and to audit workspaces that allow public access.

The activity log records who changed alert rules and monitoring settings, Azure Policy evaluates the rules above, Defender for Cloud raises recommendations, and the Microsoft Service Trust Portal holds audit reports. Microsoft operates the platform and the data stores. What is collected, who can query it, how long it stays and what happens when an alert fires are your decisions.

• Collect less: drop verbose logs and columns at the source or in the data collection rule.
• Set retention to what you need, and archive instead of keeping everything interactive.
• Use sampling for high-volume, low-value telemetry.
• Narrow KQL time ranges keep scanning small.
• A workspace in a region on a cleaner grid trims the footprint of stored logs, provided residency rules and latency allow the move.
• Microsoft’s Emissions Impact Dashboard estimates emissions by subscription. Azure Monitor has no line of its own there, so don’t publish a figure for it.

Purchase options

What you actually pay for

• Log ingestion by plan (Analytics, Basic, Auxiliary)
• Retention beyond the included period, and long-term retention
• Queries on Basic and Auxiliary tables, by data scanned
• Alert rules, and custom or Prometheus metrics
• Private link, data export, dedicated clusters and storage you add around it

Monitoring for an orders API: a Log Analytics workspace with 30 days of retention, an Application Insights resource that writes to it, an action group for the on-call address, a metric alert on failed requests, a log search alert on slow requests and a diagnostic setting that sends a resource’s logs to the workspace. The CLI tab builds the workspace, rule and alert; Terraform describes the same resources. The Python tab asks the workspace which data types cost the most, and the C# tab finds machines whose agent has stopped sending heartbeats. Replace the names, region and e-mail address with your own, and use a test subscription for the first run.

# Placeholders: replace the names, region and e-mail address with your own.
RG=rg-orders-prod
LOC=centralindia
WS=law-orders-prod
APP=orders-api

az extension add --name application-insights --only-show-errors
az extension add --name scheduled-query --only-show-errors
az extension add --name log-analytics --only-show-errors
az group create --name $RG --location $LOC

# 1. The workspace, with 30 days of retention. Pay-as-you-go pricing (PerGB2018).
az monitor log-analytics workspace create --resource-group $RG --workspace-name $WS --location $LOC \
  --sku PerGB2018 --retention-time 30
WS_ID=$(az monitor log-analytics workspace show --resource-group $RG --workspace-name $WS --query id -o tsv)

# 2. An Application Insights resource that stores its data in that workspace.
az monitor app-insights component create --app $APP --resource-group $RG --location $LOC \
  --workspace "$WS_ID" --kind web --application-type web
AI_ID=$(az monitor app-insights component show --app $APP --resource-group $RG --query id -o tsv)

# 3. The action group: who is told. Test it before you trust it.
az monitor action-group create --resource-group $RG --name ag-$APP --short-name orders \
  --action email oncall oncall@example.com
AG_ID=$(az monitor action-group show --resource-group $RG --name ag-$APP --query id -o tsv)
az monitor action-group test-notifications create --resource-group $RG --action-group ag-$APP \
  --alert-type servicehealth --add-action email oncall oncall@example.com

# 4. A metric alert: more than 5 failed requests a minute on average over 5 minutes.
az monitor metrics alert create --resource-group $RG --name $APP-failed-requests --scopes "$AI_ID" \
  --condition "avg requests/failed > 5" --window-size 5m --evaluation-frequency 1m --severity 2 \
  --action "$AG_ID" --description "Failed requests are rising"

# 5. A log search alert: p95 of request duration above 800 ms.
az monitor scheduled-query create --resource-group $RG --name $APP-slow --scopes "$AI_ID" \
  --condition "count 'slow' > 0" --condition-query slow="requests | where timestamp > ago(5m) | summarize p95=percentile(duration, 95) | where p95 > 800" \
  --window-duration 5m --evaluation-frequency 5m --severity 3 --action-groups "$AG_ID" \
  --description "p95 request duration above 800 ms"

# 5b. The same data as a one-off question: failed requests by operation in the last hour.
az monitor log-analytics query --workspace $(az monitor log-analytics workspace show -g $RG -n $WS --query customerId -o tsv) \
  --analytics-query "AppRequests | where TimeGenerated > ago(1h) and Success == false | summarize n=count() by OperationName | top 10 by n"

# 6. A diagnostic setting: send a resource's logs and metrics to the workspace.
RES_ID=$(az webapp show --resource-group $RG --name app-orders-prod --query id -o tsv)
az monitor diagnostic-settings create --name to-workspace --resource "$RES_ID" --workspace "$WS_ID" \
  --logs '[{"category": "AppServiceHTTPLogs", "enabled": true}, {"category": "AppServiceAppLogs", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

# 7. Keep verbose data cheap: put a table on the Basic plan with 8 days of interactive retention.
az monitor log-analytics workspace table update --resource-group $RG --workspace-name $WS --name ContainerLogV2 --plan Basic

# Placeholders: pass in your own names and address. Use a test subscription for the first run.
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

variable "location" {
  type    = string
  default = "centralindia"
}

variable "alert_email" {
  type = string
}

variable "target_resource_id" {
  type        = string
  description = "A resource whose logs and metrics go to the workspace, for example the App Service"
}

resource "azurerm_resource_group" "mon" {
  name     = "rg-orders-prod"
  location = var.location
}

resource "azurerm_log_analytics_workspace" "orders" {
  name                = "law-orders-prod"
  location            = azurerm_resource_group.mon.location
  resource_group_name = azurerm_resource_group.mon.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

resource "azurerm_application_insights" "orders" {
  name                = "orders-api"
  location            = azurerm_resource_group.mon.location
  resource_group_name = azurerm_resource_group.mon.name
  workspace_id        = azurerm_log_analytics_workspace.orders.id
  application_type    = "web"
}

resource "azurerm_monitor_action_group" "oncall" {
  name                = "ag-orders-api"
  resource_group_name = azurerm_resource_group.mon.name
  short_name          = "orders"

  email_receiver {
    name                    = "oncall"
    email_address           = var.alert_email
    use_common_alert_schema = true
  }
}

resource "azurerm_monitor_metric_alert" "failed_requests" {
  name                = "orders-api-failed-requests"
  resource_group_name = azurerm_resource_group.mon.name
  scopes              = [azurerm_application_insights.orders.id]
  description         = "Failed requests are rising"
  severity            = 2
  frequency           = "PT1M"
  window_size         = "PT5M"

  criteria {
    metric_namespace = "microsoft.insights/components"
    metric_name      = "requests/failed"
    aggregation      = "Average"
    operator         = "GreaterThan"
    threshold        = 5
  }

  action {
    action_group_id = azurerm_monitor_action_group.oncall.id
  }
}

resource "azurerm_monitor_scheduled_query_rules_alert_v2" "slow" {
  name                 = "orders-api-slow"
  resource_group_name  = azurerm_resource_group.mon.name
  location             = azurerm_resource_group.mon.location
  scopes               = [azurerm_application_insights.orders.id]
  severity             = 3
  evaluation_frequency = "PT5M"
  window_duration      = "PT5M"
  description          = "p95 request duration above 800 ms"

  criteria {
    query                   = <<-KQL
      requests
      | where timestamp > ago(5m)
      | summarize p95 = percentile(duration, 95)
      | where p95 > 800
    KQL
    time_aggregation_method = "Count"
    operator                = "GreaterThan"
    threshold               = 0

    failing_periods {
      minimum_failing_periods_to_trigger_alert = 1
      number_of_evaluation_periods             = 1
    }
  }

  action {
    action_groups = [azurerm_monitor_action_group.oncall.id]
  }
}

resource "azurerm_monitor_diagnostic_setting" "to_workspace" {
  name                       = "to-workspace"
  target_resource_id         = var.target_resource_id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.orders.id

  enabled_log {
    category = "AppServiceHTTPLogs"
  }

  enabled_log {
    category = "AppServiceAppLogs"
  }

  metric {
    category = "AllMetrics"
  }
}

output "workspace_id" {
  value = azurerm_log_analytics_workspace.orders.workspace_id
}

# pip install azure-identity azure-monitor-query
# Asks the workspace which data types were billed the most in the last 7 days: the first question to ask about a Log Analytics bill.
import datetime as dt

from azure.identity import DefaultAzureCredential
from azure.monitor.query import LogsQueryClient, LogsQueryStatus

WORKSPACE_ID = "00000000-0000-0000-0000-000000000000"      # the workspace's customer ID (az monitor log-analytics workspace show --query customerId)
client = LogsQueryClient(DefaultAzureCredential())

QUERY = """
Usage
| where IsBillable == true
| summarize GB = sum(Quantity) / 1024.0 by DataType
| top 10 by GB desc
"""


def top_tables(days=7):
    result = client.query_workspace(WORKSPACE_ID, QUERY, timespan=dt.timedelta(days=days))
    if result.status == LogsQueryStatus.PARTIAL:
        print("warning: partial result:", result.partial_error)
    table = result.tables[0] if result.tables else None
    return [(row["DataType"], round(float(row["GB"]), 2)) for row in table.rows] if table else []


if __name__ == "__main__":
    total = 0.0
    for name, gb in top_tables():
        total += gb
        print("%-28s %8.2f GB" % (name, gb))
    print("top ten total: %.2f GB over 7 days" % total)

// dotnet add package Azure.Identity
// dotnet add package Azure.Monitor.Query
// Finds machines that reported in the last 7 days but have been silent for more than 15 minutes (a stopped agent or a stopped machine).
using Azure;
using Azure.Identity;
using Azure.Monitor.Query;
using Azure.Monitor.Query.Models;

string workspaceId = args.Length > 0 ? args[0] : "00000000-0000-0000-0000-000000000000";
var client = new LogsQueryClient(new DefaultAzureCredential());

const string kql = @"
Heartbeat
| where TimeGenerated > ago(7d)
| summarize last = max(TimeGenerated) by Computer, OSType
| where last < ago(15m)
| order by last asc";

Response<LogsQueryResult> response = await client.QueryWorkspaceAsync(workspaceId, kql, new QueryTimeRange(TimeSpan.FromDays(7)));
LogsTable table = response.Value.Table;

foreach (LogsTableRow row in table.Rows)
{
    DateTimeOffset last = row.GetDateTimeOffset("last")!.Value;
    Console.WriteLine($"{row.GetString("Computer"),-30} {row.GetString("OSType"),-8} silent for {(DateTimeOffset.UtcNow - last).TotalMinutes:0} min");
}

Console.WriteLine(table.Rows.Count == 0 ? "Every machine reported in the last 15 minutes." : $"{table.Rows.Count} machine(s) went quiet.");
return table.Rows.Count == 0 ? 0 : 1;

Videos picked for this service. Each one is labelled with its source, opens on YouTube if you prefer, and loads only when you press play.

Most Azure compute and data services send telemetry here, including Azure Virtual Machines, Azure Functions, Azure App Service and Azure Kubernetes Service. Customer-managed keys for a dedicated cluster come from Azure Key Vault.