Episode 2 — Metrics & Metrics Explorer

Series: AZ-104 · Monitor and Maintain Azure Resources — micro-learning. Where we are: Having framed Azure Monitor as a two-halved data platform in Episode 1, we now dive into the Metrics half — the numeric, time-series side — and its analysis tool, Metrics Explorer. Next we cross into Logs in Episode 3.

Why it matters

Metrics are the fast, cheap, always-on pulse of every Azure resource: numeric values sampled at regular intervals and kept in a time-series database optimized for near-real-time charts and alerts. On the exam and on the job you must know what a metric is, where it comes from, how long it lives, and how to slice it in Metrics Explorer with aggregation, filtering, and splitting — because misreading a chart means misreading the health of your infrastructure.

Learning objectives

• By the end, you can define a metric and describe how it is stored as a time series.
• By the end, you can distinguish native (platform + custom) metrics from Prometheus metrics and name their sources, cost, and storage.
• By the end, you can explain the time-series structure (namespace, dimensions) and multi-dimensional metrics.
• By the end, you can state the retention limits (93 days, 30-day query window, 18 months for Prometheus).
• By the end, you can operate Metrics Explorer: set scope, choose aggregation, and apply filtering vs splitting.
• By the end, you can create a metric alert rule from a chart and use Drill into Logs to correlate anomalies.

1. What a metric is

A metric is a numeric value collected at regular intervals that describes some aspect of a system at a particular time. Azure Monitor Metrics collects these into a time-series database built for time-stamped data.

Mnemonic — metrics are the "heartbeat", logs are the "diary". A heartbeat is a steady number over time (metrics); a diary is rich, textual events (logs, see Episode 3).

2. Types of metrics

Two big families: Native metrics (analyzed with Azure Monitor's own tools) and Prometheus metrics (Kubernetes world). Native splits into platform and custom.

Metrics
├─ Native (Azure Monitor tools)
│   ├─ Platform metrics  → from Azure resources, no config, no cost
│   └─ Custom metrics    → from AMA / App Insights / REST API, cost varies
└─ Prometheus metrics    → from Kubernetes/AKS, PromQL + Grafana

Key contrast: native metrics are preaggregated and stored at the subscription; Prometheus metrics are raw and stored in an Azure Monitor workspace.

3. Where metrics come from (data collection)

Once collected, metrics from any source can be evaluated together in the same metric database.

Latency note: sources aggregate differently (platform = preaggregated, Prometheus = raw), so a specific sample time can show different values until latency settles and you compare at the same granularity.

4. The time-series structure

Each set of metric values is a time series with these properties:

• Timestamp — when the value was collected.
• Resource — what the value belongs to.
• Namespace — acts like a category for the metric.
• Metric name.
• Value.
• Dimensions (when present). Custom metrics are limited to 10 dimensions.

Multi-dimensional metrics

Dimensions are name/value pairs that add context. Example: a metric Available disk space with a dimension Drive whose values are C: and D: lets you see space per drive or across all drives. Dimension names and values are case-insensitive.

Nondimensional — answers only "what was my throughput at time X?":

Two dimensions ("IP" and "Direction") — now answers "throughput per IP?" and "sent vs received?":

5. Retention — how long metrics live

Watch out: the 30-day query window does not apply to log-based metrics. Also, moving or renaming a resource may lose its metric history.

Security (brief): all traffic uses TLS 1.2 (HTTPS); the agent connects with certificate-based authentication over port 443; private keys are rotated every 90 days.

6. Metrics Explorer

Metrics Explorer is the Azure portal component to plot charts, correlate trends, and investigate spikes and dips. Open it from the Azure Monitor overview page, or from a resource's Monitoring > Metrics blade (scope prepopulated).

6.1 Set the scope

Choose Subscription, Resource, and Location. To chart multiple resources, they must be in the same subscription, same region, and same resource type.

Permission: you need Monitoring Reader at the subscription level to visualize metrics across multiple resources, resource groups, or a subscription.

6.2 Time & navigation

• Time picker — default is the most recent 24 hours.
• Pan — arrows move the range back/forward by half the chart's span.
• Zoom — set time granularity, then drag the time brush to zoom. With granularity Automatic, zooming picks a smaller grain applied to all charts.

6.3 Aggregation

Each metric point is aggregated over the time granularity (one data point per time grain).

6.4 Filtering vs Splitting (exam favorite)

Both are diagnostic tools for metrics that have dimensions — but they do opposite things.

Tip: apply both on the same dimension to hide irrelevant segments and make charts readable. For multiple resources, split by resource ID or resource group to compare one metric across resources.

Mnemonic — "Filter = fewer, Split = several." Filtering reduces what you see; splitting fans it into several lines.

6.5 Lock the y-axis

Locking the value (y) axis matters for small fluctuations of large values (e.g. success rate dropping 99.99% → 99.5%). Use More options (…) > Chart settings and set the Y-axis range (or Auto to revert). If you lock the y-axis for count/sum/min/max, use a fixed time granularity, not Automatic.

6.6 Create an alert rule from a chart

Select New alert rule; the rule inherits the chart's target, metric, splitting, and filter dimensions. Set a Threshold value (shown as a horizontal line), then Name, Description, and Severity — one of Critical, Error, Warning, Informational, Verbose — and Review + create. Full alerting (action groups, processing rules) is covered in Episode 5.

6.7 Drill into Logs

Drill into Logs diagnoses root cause by correlating spikes to:

• Activity log — management-plane operations (what/who/when for PUT/POST/DELETE); one per subscription.
• Resource logs — data-plane operations inside a resource (must be enabled).
• Recommended log — scenario-based queries.

Currently available for Application Insights, Autoscale, App Service, and Storage. Deep KQL analysis of these logs comes in Episode 3.

6.8 Share

Save to dashboard > Pin to dashboard or Save to workbook; the Share menu offers Download to Excel, Copy link, Send to Workbook, and Pin to Grafana.

Numbers & names to memorize

Apply it

Scenario 1. Your web app's Successful Requests metric hovers around 99.99% and Ops complains they can't see a small dip to 99.5% because the chart auto-scales from 0. What do you configure, and why?

Scenario 2. You run 12 VMs of the same type in one region and want to compare Percentage CPU across all of them on one chart, then be alerted if any exceeds 90%. What scope, permission, and Metrics Explorer features do you use?

Q3 (single answer). Platform metrics in Azure Monitor are stored for how long, and what is the maximum window a single chart can query?

• A. 30 days stored; 30-day query
• B. 93 days stored; 30-day query
• C. 93 days stored; 93-day query
• D. 18 months stored; 32-day query

Q4 (single answer). You want a separate line per server instance for CPU usage on one chart. Which Metrics Explorer feature do you use?

• A. Filtering
• B. Splitting
• C. Aggregation = Sum
• D. Lock the y-axis

Answers

• Scenario 1: Lock the y-axis range via More options (…) > Chart settings, setting a tight Y-axis range so small fluctuations of a large value become visible.
• Scenario 2: Set the scope to the 12 VMs (must be same subscription, region, and resource type) with Monitoring Reader permission; use Splitting by resource ID to get one line per VM, then New alert rule with a threshold of 90% (inherits target/metric/splitting).
• Q3: B — platform & custom metrics are kept 93 days, but any single chart queries at most 30 days (pan for the rest).
• Q4: B — Splitting draws a separate line per dimension value; filtering would only include/exclude values.

Recap

• A metric is a numeric, time-stamped value stored in a time-series database — the fast half of the Azure Monitor data platform.
• Metrics are native (platform = free/no config; custom = cost varies) or Prometheus (raw, stored in an Azure Monitor workspace).
• A time series carries timestamp, resource, namespace, name, value, and dimensions; custom metrics allow up to 10 dimensions.
• Retention = 93 days (platform/custom), but a chart queries only 30 days at once; Prometheus = 18 months / 32-day span.
• In Metrics Explorer: set scope, pick an aggregation (Sum/Count/Average/Min/Max), then Filter (fewer) vs Split (several).
• You can create alerts from a chart and Drill into Logs to correlate spikes with activity/resource logs.

Next up

Continue to Episode 3 — we leave numbers behind and enter the Logs half of the platform: the Log Analytics workspace and the KQL query language that powers Drill into Logs.