Kaganapan
Mar 17, 9 PM - Mar 21, 10 AM
Sumali sa serye ng meetup upang bumuo ng mga scalable AI solusyon batay sa mga kaso ng paggamit ng tunay na mundo sa mga kapwa developer at eksperto.
Magparehistro naHindi na suportado ang browser na ito.
Mag-upgrade sa Microsoft Edge para samantalahin ang mga pinakabagong tampok, update sa seguridad, at teknikal na suporta.
A single metric alert rule can be used to monitor one or many metric time series. This capability makes it easier to monitor resources at scale.
A metric time series is a series of measurements, or "metric values," captured over a period of time.
For example:
An alert rule monitors a single time series when it meets all the following conditions:
An example of such an alert rule, with only the relevant properties shown:
For this alert rule, a single metric time series is monitored:
An alert rule monitors multiple time series if it uses at least one of the following features:
A single metric alert rule can monitor multiple resources, provided the resources are of the same type and exist in the same Azure region. Using this type of rule reduces complexity and the total number of alert rules you have to maintain.
An example of such an alert rule:
For this alert rule, two metric time series are monitored separately:
In a multi-resource alert rule, the condition is evaluated separately for each of the resources (or more accurately, for each of the metric time series corresponded to each resource). As a result, alerts are also fired for each resource separately.
For example, assume we've set the preceding alert rule to monitor for CPU above 80%. In the evaluated time period, that is, the last 5 minutes:
The alert rule triggers on VM-a but not VM-b. These triggered alerts are independent. They can also resolve at different times depending on the individual behavior of each of the virtual machines.
For more information about multi-resource alert rules and the resource types supported for this capability, see Monitoring at scale using metric alerts in Azure Monitor.
Note
In a metric alert rule that monitors multiple resources, only a single condition is allowed.
A single metric alert rule can also monitor up to five conditions per alert rule.
For example:
For this alert rule, two metric time series are being monitored:
An AND operator is used between the conditions. The alert rule fires an alert when all conditions are met. The fired alert resolves if at least one of the conditions is no longer met.
Note
There are restrictions when you use dimensions in an alert rule with multiple conditions. For more information, see Restrictions when using dimensions in a metric alert rule with multiple conditions.
A single metric alert rule can also monitor multiple dimension values of a metric. The dimensions of a metric are name-value pairs that carry more data to describe the metric value. For example, the Transactions metric of a storage account has a dimension called API name. This dimension describes the name of the API called by each transaction, for example, GetBlob, DeleteBlob, and PutPage. The use of dimensions is optional, but it allows filtering the metric and only monitoring specific time series, instead of monitoring the metric as an aggregate of all the dimensional values put together.
For example, you can choose to have an alert fired when the number of transactions is high across all API names (which is the aggregated data). Or you can further break it down into only alerting when the number of transactions is high for specific API names.
An example of an alert rule monitoring multiple dimensions is:
For this alert rule, three metric time series are being monitored:
A multi-dimension metric alert rule can also monitor multiple dimension values from different dimensions of a metric. In this case, the alert rule separately monitors all the dimension value combinations of the selected dimension values.
An example of this type of alert rule:
For this alert rule, six metric time series are being monitored separately:
The pricing of metric alert rules is available on the Azure Monitor pricing page.
When you create a metric alert rule, the provided price estimation is based on the selected features and the number of monitored time series. This number is determined from the rule configuration and current metric values. The monthly charge is based on actual evaluations of the time series, so it can differ from the original estimation if some time series don't have data to evaluate, or if the alert rule uses features that can make it scale dynamically.
For example, an alert rule can show a high price estimation if it uses the multi-dimension feature, and a large number of dimension values combinations are selected, which results in the monitoring of many time series. But the actual charge for that alert rule can be lower if not all the time series resulting from the dimension values combinations actually have data to evaluate.
To prevent excess costs, each alert rule can monitor up to 5,000 time series by default. To lift this limit from your subscription, open a support ticket.
Learn more about monitoring at scale by using metric alerts and dynamic thresholds.
Kaganapan
Mar 17, 9 PM - Mar 21, 10 AM
Sumali sa serye ng meetup upang bumuo ng mga scalable AI solusyon batay sa mga kaso ng paggamit ng tunay na mundo sa mga kapwa developer at eksperto.
Magparehistro naPagsasanay
Module
Configure alerts and responses - Training
In this module, you learn how Azure Monitoring alerts proactively notifies you when Azure Monitor data indicates there might be a problem with your infrastructure or applications before the problem becomes one for your users.
Dokumentasyon
Create Azure Monitor metric alert rules - Azure Monitor
This article shows you how to create a new metric alert rule.
Create an Azure Monitor metric alert with dynamic thresholds - Azure Monitor
Get information about creating metric alerts with dynamic thresholds that are based on machine learning.
Create metric alerts in Azure Monitor Logs - Azure Monitor
Get information about creating near-real time metric alerts on popular Log Analytics data.