What Does Azure Monitor Metrics Mean?
Also known as: Azure Monitor Metrics, Azure monitoring, AZ-204 exam, cloud metrics, performance monitoring
On This Page
Quick Definition
Azure Monitor Metrics is a tool that gathers numbers about how your Azure services are running. It helps you see things like how much CPU your virtual machine is using or how many requests your web app is receiving. This data helps you spot problems and understand performance trends, all without needing to set up complex systems.
Must Know for Exams
Azure Monitor Metrics is a core topic in the AZ-204 exam, Developing Solutions for Microsoft Azure. The exam objectives include monitoring, troubleshooting, and optimizing Azure solutions. Specifically, the objective Configure monitoring and troubleshooting covers implementing application insights, monitoring performance with metrics, and configuring alerts.
Examiners want to test your ability to choose the right monitoring tool for a given scenario. Azure Monitor Metrics is often the correct answer when the problem requires real-time performance data that is numerical and discrete. For example, a question might describe a scenario where a developer needs to track the number of HTTP 500 errors from a web app and trigger an alert when the count exceeds 10 in five minutes.
The correct solution would rely on Azure Monitor Metrics because it provides a numeric count and supports alert rules. Another exam context is understanding the difference between metrics and logs. Questions frequently ask which type of data is best for alerting, which has lower latency, and which is simpler to set up.
Metrics are the right answer for low-latency alerting and autoscaling. The exam also tests your knowledge of dimensions. A question might give you a metric with dimensions for instance, region, and response code.
You must know that you can filter or split the metric to see details for a specific instance or response code. Another common exam topic is metric retention. You need to know that platform metrics are retained for 93 days, and if you need longer retention, you must send metrics to Log Analytics using diagnostic settings.
The exam may also test custom metrics, asking how to send application-specific metrics using the Azure Monitor SDK. Lastly, the exam expects you to understand how metrics support autoscaling. You might see a question about configuring an autoscale rule based on CPU percentage and you need to select the metric as the data source.
Because metrics appear in multiple exam objectives, you are likely to encounter at least three to five questions that directly or indirectly involve Azure Monitor Metrics. Mastering this term will help you answer those questions confidently.
Simple Meaning
Imagine you are a building manager for a large office complex. You need to know how the building is doing every day. Is the elevator working? How many people are using the front door?
Is the air conditioning too loud? You install a control panel in your office that displays a set of gauges and counters. One gauge shows the temperature in the server room. Another counts how many people entered the building in the last hour.
A third shows the electricity usage. These gauges give you a quick, clear picture of what’s happening right now. Azure Monitor Metrics works the same way for your cloud applications and services.
It is like a dashboard of gauges for your Azure resources. Each gauge measures something specific, like the percentage of your virtual machine’s processor that is busy, the number of database queries being processed, or the amount of memory being used. These measurements are called metrics.
They are numbers collected at regular intervals, often every minute or every few minutes. Azure stores these numbers for up to 93 days, so you can look back at past performance. You can view these metrics in a chart in the Azure portal, set up alerts to notify you when a metric goes above or below a threshold, and even combine metrics from different resources to understand the health of your entire application.
The best part is that most metrics are collected automatically. You don’t have to write code or install agents. For example, if you create a virtual machine in Azure, the platform automatically starts feeding metrics about its CPU usage, disk activity, and network traffic into Azure Monitor Metrics.
You can see these numbers immediately. This makes Azure Monitor Metrics an essential starting point for anyone who wants to keep their cloud applications running smoothly without getting lost in complex logging data.
Full Technical Definition
Azure Monitor Metrics is a time-series database service within Azure Monitor that ingests and stores numerical data points emitted by Azure resources. Each metric is a sequence of values captured at regular intervals, typically every minute, though some resources support sub-minute intervals. Metrics are lightweight and designed for near real-time monitoring, with a typical latency of under five minutes from resource emission to query availability.
They are optimized for alerting, autoscaling, and dashboards. The underlying storage is a custom time-series database that supports high ingestion rates and low-latency queries. Metrics are categorized into two types: platform metrics and custom metrics.
Platform metrics are emitted automatically by Azure resources such as virtual machines, Azure SQL databases, Application Gateways, and Azure Functions. For example, a virtual machine emits metrics like Percentage CPU, Disk Read Bytes/sec, and Network In. These metrics are free and retained for 93 days.
Custom metrics are created by users or applications and sent to Azure Monitor via the REST API or SDKs. They allow monitoring of application-specific performance counters, such as the number of orders processed per minute or queue depth. Custom metrics are charged per data point and can be retained longer with Log Analytics integration.
Azure Monitor Metrics supports multi-dimensional metrics, meaning a single metric can have multiple name-value pairs called dimensions. For instance, the metric Requests for an App Service might have dimensions for Response Code and Instance. You can filter, split, and group by dimensions to drill into specific aspects of performance.
The metrics explorer in the Azure portal provides a graphical interface to chart metrics, apply aggregations like average, sum, min, max, and count, and use time ranges from the last hour to the last 30 days. Advanced users can query metrics using the Azure Metrics REST API, PowerShell cmdlets, or Azure CLI. Integration with Azure Monitor Alerts allows you to create metric alert rules that trigger actions like sending an email, calling a webhook, or executing an Azure runbook when a metric crosses a defined threshold.
For example, you can create an alert to scale out a virtual machine scale set when average CPU usage exceeds 80% for five minutes. Azure Monitor Metrics also supports autoscaling directly, where you configure scaling rules based on metrics like CPU or queue length. In summary, Azure Monitor Metrics provides a scalable, low-latency, and cost-effective solution for monitoring numeric performance data across Azure resources, forming the foundation for operational health monitoring and automated responses.
Real-Life Example
Think of a busy hospital with multiple wards, each treating different kinds of patients. The hospital has a central monitoring room where a large screen displays several key numbers for each ward. Ward A shows the current number of patients, Ward B shows the average waiting time in minutes, Ward C shows the percentage of beds that are occupied, and Ward D shows how many nurses are on duty.
These numbers update every minute. The head nurse can look at this screen and immediately see if any ward is overcrowded or understaffed. If Ward C’s bed occupancy rate goes above 90%, the system flashes a yellow warning.
If it goes above 95%, a red alert sounds, and the hospital administrator receives a text message. This is exactly how Azure Monitor Metrics works. Each Azure resource is like a ward in the hospital.
The virtual machine is Ward A, and it sends out a metric called CPU Percentage, which is like the percentage of doctors who are busy. The web app is Ward B, and it sends a metric called Requests per Minute, similar to patients arriving. The Azure SQL database is Ward C, and it sends a metric called DTU Usage, which is like bed occupancy.
The Azure Functions service is Ward D, and it sends a metric called Execution Count, comparable to the number of nurses. The Azure portal becomes the central monitoring room. You can create a dashboard with charts for each metric.
You can set up alerts so that if CPU usage exceeds 90% for five minutes, you get an email or a push notification. You can even configure autoscaling so that if requests per minute go above a threshold, Azure automatically adds more virtual machines to handle the load, just like the hospital calling in extra nurses when the waiting room gets full. This system helps you react quickly and avoid problems before they affect patients, or in your case, your application users.
The numbers are always there, easy to see, and easy to act upon.
Why This Term Matters
Azure Monitor Metrics matters because it gives IT professionals a clear, immediate view of resource health without the noise and complexity of other monitoring data like logs. When you manage dozens or hundreds of Azure resources, you need a way to quickly spot trends and anomalies. Metrics provide that signal.
For example, if you are responsible for a production web application, you need to know at a glance if CPU usage is spiking, if memory is depleting, or if requests are failing. Metrics give you that visibility within minutes. This matters in real IT work because it enables proactive management.
Instead of waiting for users to report that the website is slow, you can create an alert for high latency or high CPU usage and fix the problem before it becomes noticeable. Metrics also drive automation. You can use metric thresholds to trigger autoscaling, so your application handles traffic spikes automatically without manual intervention.
That saves time and money because you do not have to overprovision resources for peak load. For troubleshooting, metrics provide historical context. When an incident occurs, you can look at metric charts from the hours before the problem to see what changed.
This helps you identify the root cause, such as a sudden increase in database queries or a memory leak. Metrics also support capacity planning. By reviewing trends over weeks and months, you can predict when you will need to add more resources and budget accordingly.
In cybersecurity, metrics like Network In and Out can help detect unusual data transfer patterns that might indicate a breach. Metrics are also critical for compliance and SLAs. If you have a service-level agreement that guarantees 99.
9 percent uptime, you need metrics to prove that you met the target. Azure Monitor Metrics gives you the data to generate uptime reports. Without metrics, you are flying blind, relying on guesswork and user complaints.
With metrics, you have a control panel that tells you exactly how your systems are performing every minute. That is why every Azure professional, from developers to sysadmins, needs to understand this term.
How It Appears in Exam Questions
Azure Monitor Metrics appears in exam questions in several distinct patterns. First, scenario-based selection questions. These present a situation where a developer needs to monitor a specific numeric value, like the number of requests to a web API or the queue length of a storage queue.
The question asks which Azure service to use. The correct answer is Azure Monitor Metrics because it stores numeric time-series data and supports alerting. Second, configuration questions.
These might describe a developer who wants to create a chart in the Azure portal showing the average CPU usage of a virtual machine over the last week. The question asks how to achieve this. The answer is to navigate to the metrics explorer, select the virtual machine resource, choose the Percentage CPU metric, and set the aggregation to Average.
Third, troubleshooting questions. A question might describe a scenario where an application becomes slow, and the developer needs to investigate. The correct approach is to look at metrics like CPU, memory, and disk I/O for the affected resources.
These questions test your understanding of which metrics are relevant for different problems. Fourth, alerting questions. These are common. For instance, a question might say that an e-commerce website needs to send an email when the number of failed login attempts exceeds 5 in 1 minute.
The correct solution involves creating a metric alert rule in Azure Monitor that uses the custom metric LoginFailures. You must know that metrics can trigger alerts and that the alert can send a notification via action groups. Fifth, difference questions.
These directly compare Azure Monitor Metrics with Azure Monitor Logs. A question might list several characteristics and ask which one belongs to metrics. Examples include low latency, designed for alerting, numerical data, and auto-collected by platform.
Sixth, autoscaling questions. You might be asked to configure a virtual machine scale set to scale out when average CPU usage is above 80%. The correct answer involves selecting the Percentage CPU metric as the scaling trigger.
Seventh, retention and export questions. A question might ask how to keep metric data for more than 93 days. The answer is to send metrics to a Log Analytics workspace using diagnostic settings, where you can retain them for up to two years or longer depending on your plan.
By practicing these question patterns, you will be well prepared for the AZ-204 exam.
Practise Azure Monitor Metrics Questions
Test your understanding with exam-style practice questions.
Example Scenario
Imagine you are a developer at a company called QuickOrders, which runs a web application for food delivery on Azure. The application runs on an App Service with two instances. One day, the marketing team launches a big promotion, and the website starts receiving a huge number of orders.
Your manager asks you to check if the application can handle the load. You open the Azure portal and go to the metrics explorer for the App Service. You add two metrics: CPU Average across all instances and Requests per Minute.
You see in the chart that CPU has jumped from 20% to 85%, and requests have doubled. You notice that the trend is still rising. Based on this data, you decide to increase the number of instances from two to four.
After scaling, the CPU drops back to 40%, and the application continues working smoothly. Later, you want to set up an automated response for any future promotion. You create a metric alert rule that triggers when CPU Average remains above 75% for five minutes.
The alert calls a webhook that runs a script to scale out the App Service automatically. This scenario shows how Azure Monitor Metrics helps you see real-time resource usage, make informed scaling decisions, and automate responses to prevent downtime.
Common Mistakes
Thinking that Azure Monitor Metrics and Azure Monitor Logs are the same thing and can be used interchangeably for any monitoring task.
Metrics are numerical time-series data optimized for real-time alerting and dashboards. Logs are event-based text data with rich querying but higher latency. Using logs for alerting on simple thresholds is inefficient and costly. Using metrics for detailed root-cause analysis with text search is not possible.
Remember that metrics answer ‘how much’ and ‘how many’ questions quickly, while logs answer ‘what happened’ and ‘why’ with detailed context. Use metrics for performance counters and alerts. Use logs for debugging and complex analysis.
Believing that you must manually configure every metric for every Azure resource.
Azure automatically collects platform metrics for most resources at no cost. You do not need to do anything for the basic metrics like CPU, memory, disk, and network for virtual machines, App Services, and many other resources.
Understand that platform metrics are enabled by default. You only need to configure custom metrics if you want to track application-specific data that is not already captured. Check the documentation for available platform metrics before building custom solutions.
Confusing the aggregation types and applying the wrong one when analyzing a metric.
For example, using the count aggregation on a Percentage CPU metric gives you the number of data points, not the average usage. This would give you meaningless information. Using the maximum aggregation on a request latency metric can hide outliers, while using average can smooth them out.
Always consider what question you are answering. For performance monitoring, average is usually appropriate for steady-state. Use maximum to catch spikes. Use sum for totals like total bytes sent. Use count to see how many data points were collected.
Expecting metric data to be available instantly in real time, within seconds of the event happening.
Azure Monitor Metrics has a typical latency of 2 to 5 minutes from when the resource emits the data to when it appears in the portal and is available for alerts. This is not true real-time for very fast-moving systems.
Plan your monitoring and alerting with a 5-minute delay in mind. For scenarios requiring sub-second response, consider using other services like Application Insights with live metrics stream, which provides near-real-time data without persistence.
Exam Trap — Don't Get Fooled
The exam presents a scenario where a developer needs to investigate why an application crashed at 3 AM. The developer wants to see the exact sequence of events leading up to the crash, including log messages. The question asks which Azure service to use.
Some answer options include Azure Monitor Metrics. Many learners choose metrics because it is the first thing that comes to mind for monitoring. Read the question carefully and identify the specific type of data needed.
If the question asks for time-stamped events, error messages, or a detailed sequence of actions, you need Azure Monitor Logs or Application Insights, not metrics. Metrics only give you numbers over time, not events. Remember: metrics for numbers, logs for events.
Commonly Confused With
Azure Monitor Logs stores event-based data like error messages, debug traces, and custom log entries from applications and resources. It allows complex queries using KQL to search and correlate data. Metrics store only numerical values optimized for quick charting and alerting. Logs are better for deep investigation, while metrics are better for real-time performance monitoring.
If you want to see the number of HTTP 500 errors per minute, use a metric. If you want to see the exact error message of each 500 error and the stack trace, use logs.
Application Insights is a specific part of Azure Monitor focused on application performance management. It collects metrics, logs, requests, dependencies, exceptions, and user behavior for web applications. It uses both metrics and logs, but it is more application-centric. Azure Monitor Metrics is broader, covering all Azure resources, not just applications.
To monitor the CPU of a virtual machine, use Azure Monitor Metrics. To track how many users click a button on your website, use Application Insights, which provides a metric called Custom Event.
Azure Service Health tells you about the health of Azure services themselves, such as if an Azure region is experiencing an outage or if a planned maintenance is scheduled. It does not give you metrics about your own resources. Azure Monitor Metrics gives you performance data specific to your own virtual machines, databases, and apps.
If your web app is slow and you want to see if Azure itself has a problem, check Service Health. If you want to see your app’s CPU usage, use Azure Monitor Metrics.
Azure Resource Health gives you a simple status (Healthy, Degraded, Unavailable) for a specific resource, but does not show granular metrics like CPU percentages. It is a high-level view. Azure Monitor Metrics provides detailed numerical data that explains why a resource might be degraded.
Resource Health says your virtual machine is Degraded. You use Azure Monitor Metrics to see that the disk latency is high, which is the reason for the degradation.
Step-by-Step Breakdown
Resource emission
Every Azure resource that supports monitoring, such as a virtual machine, App Service, or SQL database, emits platform metrics automatically. This happens at a set interval, usually every minute. The resource sends a data point for each metric, like CPU percentage or bytes received, to the Azure Monitor backend. No configuration is needed for these base metrics.
Data ingestion and storage
Azure Monitor receives these data points and stores them in a time-series database optimized for metrics. Each data point consists of a timestamp, a value, and a set of dimensions that further describe it, like instance name or region. The data is stored for 93 days by default. During this step, metrics from all resources are aggregated into a single database for fast querying.
Query and visualization
You can access the data through the Azure portal’s metrics explorer. You select a resource, choose a metric, and pick an aggregation (average, sum, minimum, maximum, count). The system then queries the time-series database and returns a chart that updates in real time. You can add multiple metrics, split them by dimensions, and change the time range to analyze historical data.
Alerting
You can create metric alert rules that continuously evaluate metric data. For example, you create a rule that checks if average CPU usage exceeds 90% for 5 consecutive minutes. When the condition is met, Azure Monitor fires the alert. The alert can trigger an action group that sends email, SMS, pushes a notification to a mobile app, or calls a webhook to run automation.
Autoscaling
Azure autoscale uses metric data to automatically adjust the number of instances of a resource, like a virtual machine scale set or App Service plan. You configure a rule based on a metric, such as adding an instance when CPU average is above 75% for 10 minutes. Azure Monitor continuously feeds the metric data to the autoscale engine, which decides when to scale out or in.
Export and long-term retention
If you need to keep metric data longer than 93 days, you can configure diagnostic settings to export metrics to a Log Analytics workspace, an Azure Storage account, or an Event Hub. In Log Analytics, metrics become part of the log data and can be retained for up to 2 years. This allows you to perform long-term trend analysis and compliance reporting.
Practical Mini-Lesson
Azure Monitor Metrics is not just a dashboard; it is a fundamental tool for cloud operations. To use it effectively, you must first know which metrics are important for your workload. For a virtual machine, the critical metrics are Percentage CPU, Available Memory, Disk Queue Depth, and Network In/Out. For a web app, look at Requests, Response Time, HTTP 5xx Errors, and Memory Working Set. For a database, focus on DTU/CPU usage, Sessions, and Deadlocks.
To configure metrics monitoring, start by creating a dashboard in the Azure portal. Add a metrics chart for each critical metric. Set the time range to the last 24 hours to get a baseline. Use the split by dimension feature if your resource has multiple instances, so you can see if one instance is misbehaving. For example, split the CPU metric by Instance to see if only one of your three VMs is running hot. Next, create alerts. A good rule is to set an alert for CPU at 85% for 10 minutes and another for disk queue length above 10. Test your alerts by temporarily stressing the resource. For instance, run a CPU stress tool on a test VM to see if the alert fires correctly. Common problems include setting the threshold too low, which leads to constant alerts, or too high, which means you miss problems. Start conservative and adjust over time. Another practical skill is using metrics for troubleshooting. When an incident occurs, open the metric chart for the affected resource and compare it to the same time window one week before. Look for sudden changes. A spike in Network Out could indicate a data breach or misconfigured backup. A gradual increase in memory usage might be a memory leak. Metrics also integrate with third-party tools via the REST API. You can pull metric data into Grafana or Power BI for custom dashboards. Finally, remember that custom metrics are powerful but come at a cost. Only emit custom metrics when the platform metric does not meet your needs. For example, if you want to track the number of items in a queue processed per second, create a custom metric and send it from your application using the Azure Monitor SDK. Monitor its cost because each data point incurs a small charge. In practice, successful cloud professionals rely on metrics to automate scaling, detect anomalies, and validate changes. Mastering Azure Monitor Metrics will make you more efficient and help you pass the AZ-204 exam.
Memory Tip
Think of M.A.L.E.: Metrics = Alerts, Logs = Events. Metrics give you the numbers to alert on; logs give you the story to read.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
AZ-204AZ-204 →Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
Do I need to pay extra for Azure Monitor Metrics?
Platform metrics are free and included with your Azure resources. Custom metrics have a cost based on the number of data points and API calls. You can track usage in the Azure portal to avoid surprises.
How long does Azure keep my metric data?
Platform metrics are retained for 93 days. If you need longer retention, you can export metrics to a Log Analytics workspace (up to 2 years) or to Azure Storage (custom retention).
Can I use metrics to debug a specific error in my application?
Not directly. Metrics tell you how many errors happened, but not why. For detailed error messages and stack traces, use Azure Monitor Logs or Application Insights.
How do I create a custom metric for my application?
Use the Azure Monitor SDK in your application code to call the TrackMetric method or the REST API. You provide a name, value, and optional dimensions. The metric will then appear in the metrics explorer.
What is a metric dimension?
A dimension is a name-value pair that provides additional context for a metric. For example, a Requests metric might have a dimension called ResponseCode. You can filter or split the metric by ResponseCode to see how many requests returned 200 versus 500.
Can I get alerts on metrics from multiple resources at once?
Yes. You can create a metric alert rule that targets a resource group or a subscription, allowing you to monitor all VMs or all App Services in one rule. Be careful with thresholds, as different resources may have different normal ranges.
Summary
Azure Monitor Metrics is a core monitoring service that collects numerical performance data from Azure resources automatically. It works like a set of gauges for your cloud environment, giving you instant visibility into CPU usage, request counts, memory consumption, and many other vital signs. This data supports real-time alerting, autoscaling, and historical analysis, making it indispensable for keeping applications healthy and responsive.
For the AZ-204 exam, you must understand that metrics are for numbers, metrics are for alerting, and metrics are retained for 93 days. You need to distinguish metrics from logs and know how to use the metrics explorer, configure alert rules, and leverage dimensions for fine-grained analysis. Common mistakes include confusing metrics with logs, thinking you must configure all metrics manually, and applying the wrong aggregation type.
Remember the memory tip M.A.L.E.: Metrics = Alerts, Logs = Events. By mastering Azure Monitor Metrics, you gain a powerful tool for both daily operations and certification success.
Keep your focus on practical scenarios, and you will find this concept both straightforward and essential.