Metrics in Azure Monitor

The anatomy of an Azure metric

Every metric in Azure Monitor has five defining properties:

• Resource — The Azure resource emitting the metric (a specific VM, an App Service plan, a storage account).
• Namespace — A grouping that corresponds to the resource provider. Microsoft.Web/sites is the namespace for App Service. Microsoft.Compute/virtualMachines is the namespace for VMs.
• Metric name — The specific measurement, such as CpuPercentage, Http5xx, or BytesReceived.
• Dimensions — Optional key-value pairs that let you filter or split a metric. The Http5xx metric on App Service has an Instance dimension so you can see errors per instance.
• Time granularity — The interval at which the metric is collected and stored (1 minute is most common; some resources offer finer granularity).

Aggregations: choosing the right lens

When you view a metric over time, Azure Monitor aggregates the raw data points within each time bucket. The aggregation you choose dramatically changes what you see — and what you might miss.

A practical example: your App Service reports CpuPercentage sampled every minute. With a 5-minute chart granularity, “average” shows you a smoothed trend. “Maximum” reveals the worst CPU spike within each 5-minute window. If your application is latency-sensitive, the maximum is often the number that matters — average can look healthy while individual spikes are causing timeouts.

Metrics Explorer: your first stop for investigation

Metrics Explorer is the browser-based tool in the Azure portal for visualizing metric data. You reach it by navigating to any resource and clicking “Metrics” in the left sidebar, or by going directly to Azure Monitor and opening the Metrics blade.

The workflow in Metrics Explorer follows a consistent pattern:

1. Select a scope — one resource, a resource group, or a subscription.
2. Choose a metric namespace.
3. Select a metric.
4. Choose an aggregation.
5. Optionally split by dimension or add a filter.

Splitting by dimension is particularly powerful. On an AKS cluster, you can chart CPU usage split by node to see which nodes are hot. On a storage account, you can split Transactions by ApiName to see which storage operations are generating the most traffic.

Working with metrics via the Azure CLI

The portal is useful for exploration, but the CLI lets you script metric queries, pull data into pipelines, or quickly check values during an incident without navigating the UI.

# List all metric definitions (names) for a storage account
az monitor metrics list-definitions \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storage-name> \
  --output table

# Get the maximum response time for an App Service app, last 30 minutes
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Web/sites/<app-name> \
  --metric "HttpResponseTime" \
  --interval PT1M \
  --aggregation Maximum \
  --start-time $(date -u -d '30 minutes ago' +%Y-%m-%dT%H:%MZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%MZ) \
  --output json

# Get failed requests count split by instance (multi-instance App Service)
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Web/sites/<app-name> \
  --metric "Http5xx" \
  --interval PT5M \
  --aggregation Total \
  --filter "Instance eq '*'" \
  --start-time 2026-03-19T08:00:00Z \
  --end-time 2026-03-19T09:00:00Z \
  --output table

Custom metrics: instrument what matters to your business

Platform metrics cover infrastructure health well, but they know nothing about your application logic. How many orders were processed? How long did the payment gateway call take? How many items are currently in the processing queue?

You can emit custom metrics from your application using the Application Insights SDK. These metrics flow into the same Azure Monitor store and can be charted, alerted on, and exported just like platform metrics.

# Example: emit a custom metric via the Azure Monitor REST API
# (useful when you cannot use the SDK, e.g., from a shell script)
ACCESS_TOKEN=$(az account get-access-token --resource https://monitoring.azure.com/ --query accessToken -o tsv)
RESOURCE_ID="/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Web/sites/<app-name>"
REGION="eastus"

curl -X POST \
  "https://${REGION}.monitoring.azure.com${RESOURCE_ID}/metrics" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "time": "2026-03-19T12:00:00Z",
    "data": {
      "baseData": {
        "metric": "OrdersProcessed",
        "namespace": "MyApplication",
        "dimNames": ["Region", "Environment"],
        "series": [{
          "dimValues": ["eastus", "production"],
          "min": 1,
          "max": 1,
          "sum": 1,
          "count": 1
        }]
      }
    }
  }'

Multi-dimensional analysis: real-world example

Here is a realistic scenario: you receive an alert that HTTP 5xx errors on your web app have exceeded 10 per minute. The overall error count is up, but you need to know whether it is affecting all instances or just one.

In Metrics Explorer, select the Http5xx metric, set aggregation to “Sum”, and click “Apply splitting” → “Instance”. If 95% of errors are coming from instance RD0003FF8A1234, you now know the problem is isolated to that instance — possibly a memory leak or a failed dependency connection on that specific host. You can then restart just that instance without a full deployment rollback.

This kind of dimensional drill-down is the difference between a 45-minute incident and a 4-minute fix.

Metrics vs. logs: when to use each

Metrics and logs are complementary. Neither replaces the other.

• Use metrics for: dashboards, real-time alerting, capacity planning, SLA tracking. They are cheap to store, fast to query, and available in near real-time.
• Use logs for: root cause analysis, security auditing, detailed error investigation, business event tracking. They are richer but more expensive to store and slower to query.

A common pattern: alert on a metric threshold (fast), then query logs to understand why the threshold was breached (thorough). Metrics get you to the incident. Logs help you resolve it.