This chapter covers Azure Metrics Explorer, a powerful tool within Azure Monitor for visualizing and analyzing metrics collected from Azure resources. Metrics Explorer is essential for monitoring performance, identifying trends, and setting up alerts. On the AZ-104 exam, questions related to Metrics Explorer appear in approximately 5-10% of exams, often integrated with alerting and dashboard scenarios. You will learn how to navigate the tool, create custom charts, apply filters and splitting, and understand the underlying metric data structure.
Jump to a section
Azure Metrics Explorer is like a custom dashboard in a large building management office. The building has hundreds of sensors everywhere: temperature sensors in each room, motion detectors in hallways, power meters on each floor, and water flow meters on every pipe. The raw data from all these sensors streams into a central database, but staring at that raw stream is overwhelming. The dashboard lets you pick exactly which sensors to watch, how to combine their readings, and how to display them. You can create a chart showing average temperature on the third floor over the last 24 hours, or a line graph of total power consumption for the whole building this month. You can even set a rule: if any floor's temperature exceeds 30°C, flash a red alert. The dashboard doesn't store new data; it queries the same raw data every time you look at it, so you always see the latest readings. If you want to keep a historical chart for later, you can pin it to a permanent board (like pinning a chart to an Azure Dashboard). The key point: Metrics Explorer is the tool to explore and visualize the sensor data already being collected, not to collect new data. It's like designing your own view into the building's nervous system without adding any new sensors.
What is Azure Metrics Explorer?
Azure Metrics Explorer is a graphical tool in the Azure portal that allows you to plot, query, and analyze metrics from Azure resources. Metrics are numerical values collected at regular intervals that describe some aspect of a resource at a particular time — for example, CPU percentage of a virtual machine, incoming bytes on a network interface, or queue depth of a storage account. Metrics Explorer provides a rich interface to build custom charts, apply filters, split data by dimensions, set time ranges, and pin charts to dashboards. It is the primary ad-hoc analysis tool for metrics before you build automated alerts or dashboards.
How it Works: The Metrics Pipeline
Metrics data originates from Azure resources. Each resource type emits a predefined set of metrics (for example, a VM emits Percentage CPU, Network In/Out, Disk Read/Write bytes). These metrics are collected by Azure Monitor and stored in a time-series database. When you use Metrics Explorer, you are querying this database. The key steps:
Selection: You choose a scope (the resource you want to monitor) and a metric namespace (e.g., Virtual Machine, Storage Account).
Aggregation: You choose an aggregation function (Average, Min, Max, Sum, Count) applied over the time grain (e.g., 1 minute, 5 minutes, 1 hour). The default time grain is auto-selected based on the time range.
Time Range: You set the time window (e.g., last 1 hour, last 24 hours, custom range). The tool fetches data points within that window.
Visualization: The data is plotted as a line chart, bar chart, area chart, or scatter plot. You can add multiple metrics on the same chart.
Filtering and Splitting: You can filter by dimension values (e.g., show only requests with status code 200) or split by a dimension (e.g., show separate lines for each status code category).
Key Components and Defaults
- Metric Namespace: A category of metrics. For example, "Virtual Machine" namespace includes CPU, Network, Disk metrics. Each resource type has one or more namespaces. - Metric Name: The specific measurement (e.g., "Percentage CPU"). - Dimensions: Optional key-value pairs that provide additional context. For example, the metric "Requests" on a storage account might have dimensions like "ResponseType" (Success, ClientOtherError, etc.) and "GeoType" (Primary, Secondary). Not all metrics have dimensions. - Time Grain: The interval over which data points are aggregated. Defaults: For time ranges less than 3 days, the grain is 1 minute; for 3 to 30 days, 5 minutes; for 30 days and above, 1 hour. You can override this. - Aggregation Types: - Average: Sum divided by count. Most common for metrics like CPU. - Min/Max: Useful for identifying spikes or troughs. - Sum: Useful for counting events (e.g., total requests). - Count: Number of raw samples (rarely used directly). - Time Range: Up to 30 days of data can be viewed in Metrics Explorer. For longer retention, use Log Analytics or export to a storage account.
Configuration and Verification
To open Metrics Explorer: In the Azure portal, navigate to any resource (e.g., a VM), click on "Metrics" under the Monitoring section. Alternatively, go to Azure Monitor > Metrics. The interface allows you to:
Add multiple metrics by clicking "Add metric".
Change the chart type (Line, Bar, Area, Scatter).
Adjust time range via the time picker.
Apply filters: Click "Add filter", select a dimension, operator (=, !=, contains, etc.), and value.
Apply splitting: Click "Apply splitting", select a dimension to split by (e.g., by InstanceId for VM metrics). This creates separate lines for each value of that dimension.
Pin to dashboard: Click the pin icon to add the chart to an Azure Dashboard for persistent viewing.
Example: To chart the average CPU for a VM over the last hour with 1-minute grain: 1. Select the VM resource. 2. Choose "Percentage CPU" metric. 3. Set aggregation to "Average". 4. Set time range to "Last 1 hour". 5. The chart appears automatically.
Interaction with Related Technologies
Azure Monitor Alerts: You can create a metric alert directly from Metrics Explorer by clicking "New alert rule". The chart's metric and aggregation settings pre-populate the alert condition.
Azure Dashboards: Charts can be pinned to shared dashboards for team visibility.
Workbooks: Metrics Explorer is a component of Azure Workbooks, which combine metrics, logs, and text into interactive reports.
Log Analytics: Metrics Explorer deals only with numeric metric data. For log-based queries (e.g., querying application logs), you use Log Analytics with Kusto Query Language (KQL).
Advanced Features
Multi-resource charts: You can select multiple resources of the same type (e.g., multiple VMs in the same region) to compare their metrics on one chart. This is done by changing the scope from a single resource to a resource group or subscription.
Metric namespaces in ARM: When configuring alerts via ARM templates, you need the metric namespace, e.g., Microsoft.Compute/virtualMachines for VM metrics.
Custom metrics: Applications can send custom metrics to Azure Monitor using the Application Insights SDK or the Azure Monitor custom metrics API. These appear in Metrics Explorer under the "Custom" namespace.
Common Pitfalls
Wrong aggregation: Using "Sum" for a metric like Percentage CPU can be misleading because it adds percentages over time, which is not meaningful. Always choose the aggregation that makes sense for the metric (usually Average).
Missing dimensions: If a metric has dimensions, the default chart shows aggregated data across all dimension values. To see granular data, you must apply splitting or filter.
Time grain too coarse: For short time ranges, the default grain may be too coarse (e.g., 5 minutes for a 1-hour window). Override to 1 minute for finer resolution.
Data not appearing: Ensure the resource is emitting metrics. Some resources (e.g., stopped VMs) stop emitting metrics. Also, newly created resources may take a few minutes to appear.
Select the Resource Scope
Navigate to the Azure portal and open Metrics Explorer (either from a specific resource's 'Metrics' blade or from Azure Monitor > Metrics). In the scope picker, you can select a single resource, a resource group, a subscription, or a scope like 'All virtual machines in this subscription'. For a single resource, you can also search by name. Once selected, the available metric namespaces and metrics are loaded. This step determines what data you can query. If you select a broad scope like a subscription, you can later filter down by resource type.
Choose a Metric Namespace and Metric
After selecting scope, choose a metric namespace (e.g., 'Virtual Machine' or 'Storage Account'). Then select a specific metric from the list (e.g., 'Percentage CPU'). The list is filtered based on the resource type. You can add multiple metrics by clicking 'Add metric'. Each metric can have its own aggregation and chart style. For metrics with dimensions, you will see a 'Dimensions' section where you can apply filters or splitting.
Set Aggregation and Time Grain
By default, Metrics Explorer applies 'Average' aggregation and selects a time grain based on your time range. You can change aggregation to Min, Max, Sum, or Count. For time grain, you can override the auto-selection by clicking the time grain dropdown (e.g., choose 1 minute, 5 minutes, 15 minutes, etc.). The chart updates immediately. For example, to see CPU spikes, use 'Max' aggregation with a 1-minute grain. For cumulative metrics like total bytes sent, use 'Sum'.
Apply Filters and Splitting
If the metric has dimensions, you can filter to include only specific dimension values. For example, for a Load Balancer metric 'Dip Count' with dimension 'Backend IP', you can filter to show only one backend IP. Click 'Add filter', select dimension, operator, and value. Splitting creates separate chart lines for each dimension value. For example, split 'Percentage CPU' by 'InstanceId' to see each VM's CPU line. This is powerful for comparing performance across instances.
Adjust Time Range and Chart Style
Use the time picker to select a predefined range (Last hour, Last 6 hours, Last 24 hours, Last 7 days, Last 30 days) or set a custom range. You can also change the chart type: Line (default), Bar, Area, Scatter. Line charts are best for trends over time. Bar charts for comparisons. Area charts emphasize magnitude. Scatter plots for correlation analysis. You can also adjust chart properties like legend position, gridlines, and colors.
Save, Pin, or Create Alert
Once your chart is configured, you can save it to a dashboard by clicking 'Pin to dashboard'. This creates a persistent tile on a shared or private dashboard. You can also click 'New alert rule' to create a metric alert based on the current chart's metric and aggregation. The alert condition is pre-populated. For example, you can create an alert that fires when CPU exceeds 90% for 5 minutes. Alternatively, you can download the chart as an image or share a link.
Enterprise Scenario 1: Monitoring VM Performance for a Critical Application
A company runs a line-of-business application on a fleet of 50 virtual machines in Azure. They need to ensure consistent performance and quickly identify any VM that is underperforming. Using Metrics Explorer, the operations team creates a chart that shows Average CPU across all VMs, split by InstanceId. They set the time range to the last 24 hours with a 5-minute grain. This chart is pinned to a shared dashboard visible to the entire team. Additionally, they create a metric alert on each VM to notify if CPU exceeds 85% for 10 minutes. They also monitor memory pressure using the 'Available Memory Bytes' metric (though this requires guest-level metrics via diagnostic extension). In production, they noticed that during peak hours, some VMs spike to 100% CPU while others remain low, indicating an uneven load distribution. They used Metrics Explorer to identify the specific time of the spike and correlated it with application logs to optimize the load balancer. Misconfiguration: Initially, they used 'Sum' aggregation for CPU, which showed a meaningless upward trend. Switching to 'Average' resolved the issue.
Enterprise Scenario 2: Storage Account Performance Troubleshooting
A media company uploads large video files to Azure Blob Storage. Users report slow uploads during certain hours. The storage team uses Metrics Explorer on the storage account to analyze 'Success E2E Latency' and 'Success Server Latency' metrics, split by 'ResponseType' and 'APIName'. They filter to show only 'PutBlob' API calls. The chart reveals that server latency is low but end-to-end latency is high, indicating network congestion. They also monitor 'Ingress' and 'Egress' metrics to see traffic patterns. They discover that during the slow periods, total ingress is near the storage account's scalability limits (e.g., 20 Gbps for general-purpose v2). They decide to enable CDN for video delivery and increase storage account limits. Metrics Explorer was crucial for isolating the bottleneck. Common mistake: Not splitting by API name, so they couldn't differentiate between upload and download latency.
Enterprise Scenario 3: Load Balancer Health Probe Analysis
An e-commerce site uses Azure Load Balancer in front of a backend pool of VMs. During a promotion, some VMs become unhealthy and are removed from rotation. The network team uses Metrics Explorer to monitor 'Dip Count' (healthy backend instances) and 'Health Probe Status' (percentage of successful probes). They split 'Health Probe Status' by 'Backend IP' to see which specific VMs are failing probes. They also chart 'Data Path Availability' to ensure the load balancer itself is healthy. They set an alert when 'Health Probe Status' drops below 80%. In production, they noticed a gradual decline in healthy VMs due to a memory leak. Metrics Explorer helped identify the pattern before the site went down. A common misconfiguration is forgetting to split by backend IP, so they only saw the aggregate percentage and couldn't pinpoint the faulty VM.
What AZ-104 Tests on Metrics Explorer
The AZ-104 exam objectives under 'Monitor and maintain Azure resources' (Objective 5.1) include: 'Analyze metrics using Azure Metrics Explorer'. The exam expects you to:
Understand how to select the appropriate metric, aggregation, and time grain.
Know how to apply filters and splitting to analyze metrics.
Understand the difference between metrics and logs.
Know how to pin charts to dashboards and create alerts from Metrics Explorer.
Understand that Metrics Explorer uses pre-collected metrics (no additional configuration required for platform metrics).
Common Wrong Answers and Why Candidates Choose Them
Wrong aggregation choice: A question asks 'Which aggregation should you use to see the total number of requests?' Many candidates choose 'Average' because it's the default. The correct answer is 'Sum' because total requests are cumulative. Candidates often default to 'Average' without thinking about the metric's semantics.
Confusing metrics with logs: A scenario describes needing to query application errors. Candidates might choose Metrics Explorer, but the correct tool is Log Analytics because errors are event-based log data, not numeric metrics.
Assuming dimensions are always present: A question shows a metric without dimensions and asks how to filter by instance. Candidates may try to apply a filter, but the correct answer is that the metric cannot be filtered because no dimensions exist. They might incorrectly think you can add custom dimensions.
Time grain misunderstanding: A question asks for the default time grain for a 7-day time range. The correct answer is 5 minutes (for 3-30 days). Candidates might pick 1 minute (for <3 days) or 1 hour (for >30 days).
Specific Numbers and Terms
Default time grains: <3 days = 1 min, 3-30 days = 5 min, >30 days = 1 hour.
Maximum time range viewable in Metrics Explorer: 30 days.
Aggregation types: Average, Min, Max, Sum, Count.
Metric namespaces: e.g., 'Microsoft.Compute/virtualMachines', 'Microsoft.Storage/storageAccounts'.
Dimensions: e.g., 'InstanceId' for VM metrics, 'ResponseType' for storage.
Edge Cases and Exceptions
Multi-resource charting: You can select multiple resources of the same type, but not different types (e.g., you cannot chart VM CPU and storage latency on the same chart).
Custom metrics: If an application sends custom metrics, they appear under the 'Custom' namespace. The exam may ask about how to view them — you use Metrics Explorer, not Log Analytics.
Guest OS metrics: For VMs, platform metrics (like CPU) are collected automatically. For guest OS metrics (like memory), you need to enable the Azure Diagnostics Extension. The exam tests this distinction.
Metrics retention: Platform metrics are stored for 93 days (up to 30 days in Metrics Explorer, but can be retrieved via REST API for up to 93 days).
How to Eliminate Wrong Answers
Read the question carefully: Is it asking for a 'total' (use Sum) or an 'average' (use Average)?
Determine if the data is numeric and time-series (metrics) or text/event-based (logs).
Check if the metric has dimensions: If the question mentions 'by instance' and the metric doesn't have an instance dimension, the answer is likely 'You cannot split by instance'.
Remember the default time grain rule: Use the time range to determine the default grain.
Azure Metrics Explorer is used to visualize and analyze numeric metrics from Azure resources; it does not handle log data.
Platform metrics are collected automatically; guest OS metrics require the diagnostics extension.
Default time grains: <3 days = 1 min, 3-30 days = 5 min, >30 days = 1 hour.
Aggregation types: Average, Min, Max, Sum, Count. Choose Sum for totals, Average for typical values.
Dimensions allow filtering and splitting; not all metrics have dimensions.
Charts can be pinned to dashboards and used to create metric alerts.
Metrics Explorer can display up to 30 days of data; older data requires API or export.
Multi-resource charts can only include resources of the same type.
For memory metrics on VMs, you must enable guest-level diagnostics.
Always verify the metric's unit (e.g., bytes, percentage, count) to interpret correctly.
These come up on the exam all the time. Here's how to tell them apart.
Azure Metrics Explorer
Visualizes numeric time-series metrics (e.g., CPU, IOPS).
Data is pre-collected automatically for platform metrics.
Supports aggregation, filtering, splitting by dimensions.
Chart types: Line, Bar, Area, Scatter.
Used for real-time monitoring and alerting on performance.
Azure Log Analytics
Queries log and event data using Kusto Query Language (KQL).
Requires diagnostic settings to send logs to Log Analytics workspace.
Supports complex queries, joins, and full-text search.
Results displayed as tables, charts, or time series.
Used for troubleshooting, auditing, and custom analytics.
Metrics Explorer (Platform Metrics)
Collected automatically by Azure for the resource.
Includes metrics like CPU, Network, Disk I/O (for VMs).
No additional configuration needed.
Stored for 93 days (retrievable up to 30 days in portal).
Cannot capture OS-level metrics like memory usage.
Guest OS Metrics (Diagnostics Extension)
Requires Azure Diagnostics Extension or Log Analytics agent.
Includes memory, disk space, and custom performance counters.
Must be configured via ARM template, portal, or PowerShell.
Data can be sent to Azure Monitor, Storage, or Event Hubs.
Provides deeper insight into the VM's operating system.
Mistake
Metrics Explorer can query log data from Log Analytics.
Correct
Metrics Explorer only queries metric data (numeric time-series). Log data (text, events) must be queried using Log Analytics with KQL. They are separate tools within Azure Monitor.
Mistake
You can change the aggregation after the chart is created without affecting the underlying data.
Correct
Changing aggregation recalculates the chart from the raw data. It does not modify stored data. The aggregation is just a way to summarize data points over the time grain.
Mistake
All metrics have dimensions.
Correct
Not all metrics have dimensions. For example, 'Percentage CPU' on a VM has a dimension 'InstanceId' only if the VM has multiple cores? Actually, 'Percentage CPU' typically does not have dimensions. Check the metric definition: some metrics like 'Requests' on a storage account have dimensions like 'ResponseType'.
Mistake
You can view metrics older than 30 days in Metrics Explorer.
Correct
Metrics Explorer can only display up to 30 days of data. For older data, you need to use the Metrics REST API or export metrics to a storage account or Log Analytics.
Mistake
Metrics Explorer requires you to enable diagnostic settings for all resources.
Correct
Platform metrics are collected automatically for most Azure resources without any configuration. Diagnostic settings are only needed for guest OS metrics (e.g., memory, disk space) or to send metrics to other destinations (e.g., Log Analytics, Event Hubs).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Memory usage is not a platform metric; it requires guest OS diagnostics. First, enable the Azure Diagnostics Extension on the VM. Then, in Metrics Explorer, select the VM and look under the 'Guest (classic)' or 'VM Guest' namespace for metrics like 'Memory\% Committed Bytes In Use'. Alternatively, use Log Analytics if you have the Log Analytics agent installed. On the exam, remember: CPU is platform; memory is guest.
Yes, but only if they are the same resource type (e.g., multiple VMs). In Metrics Explorer, change the scope from a single resource to a resource group or subscription, then select the resource type. You can then add metrics and they will appear combined. You cannot mix different resource types (e.g., VM and storage account) on the same chart.
A filter restricts the data shown to only those that match a condition (e.g., show only requests with status 200). Splitting creates separate chart lines for each unique value of a dimension (e.g., one line per status code: 200, 404, 500). Filters reduce the data; splitting expands it into multiple series.
Platform metrics are stored for 93 days. However, Metrics Explorer in the portal only allows you to view up to 30 days. To query older data, you can use the Metrics REST API, or export metrics to a Log Analytics workspace (which has longer retention) or to Azure Storage.
Yes. After configuring your chart, click 'New alert rule'. This opens the Create alert rule pane with the metric and aggregation pre-filled. You can then set the condition (e.g., greater than 90), the evaluation frequency, and the action group. This is a common exam scenario: creating an alert from a metric chart.
Use 'Average' for typical CPU usage. 'Max' is useful to see peak usage. 'Sum' is not meaningful because it adds percentages over time. The exam may ask which aggregation to use for a given metric; always consider the metric's semantics.
Check that the VM is running. Stopped or deallocated VMs do not emit metrics. Also, ensure the time range is correct. For a newly created VM, wait a few minutes for data to appear. If the VM has been running, verify that the metric is available for that resource type (e.g., a Basic VM may have fewer metrics than a Standard VM).
You've just covered Azure Metrics Explorer — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?