Friday, 12 July 2024

Create or edit a metric alert rule

 

Create or edit a metric alert rule

Prerequisites

To create a metric alert rule, you must have the following permissions:

  • Read permission on the target resource of the alert rule.
  • Write permission on the resource group in which the alert rule is created. If you're creating the alert rule from the Azure portal, the alert rule is created by default in the same resource group in which the target resource resides.
  • Read permission on any action group associated to the alert rule, if applicable.

Create or edit an alert rule from the portal home page

Follow these steps:

  1. In the portal, select Monitor > Alerts.

  2. Open the + Create menu, and select Alert rule.

    Screenshot that shows steps to create a new alert rule.

Create or edit an alert rule from a specific resource

Follow these steps:

  1. In the portal, navigate to the resource.

  2. Select Alerts from the left pane, and then select + Create > Alert rule.

    Screenshot that shows steps to create a new alert rule from a selected resource.

Edit an existing alert rule

Follow these steps:

  1. In the portal, either from the home page or from a specific resource, select Alerts from the left pane.

  2. Select Alert rules.

  3. Select the alert rule you want to edit, and then select Edit.

    Screenshot that shows steps to edit an existing alert rule.

  4. Select any of the tabs for the alert rule to edit the settings.

Configure the scope of the alert rule

Follow these steps:

  1. On the Select a resource pane, set the scope for your alert rule. You can filter by subscriptionresource type, or resource location.

  2. Select Apply.

    Screenshot that shows the select resource pane for creating a new alert rule.

Configure the alert rule conditions

Follow these steps:

  1. On the Condition tab, when you select the Signal name field, the most commonly used signals are displayed in the drop-down list. Select one of these popular signals, or select See all signals if you want to choose a different signal for the condition.

    Screenshot that shows popular signals when creating an alert rule.

  2. (Optional) If you chose to See all signals in the previous step, use the Select a signal pane to search for the signal name or filter the list of signals. Filter by:

    • Signal type: The type of alert rule you're creating.
    • Signal source: The service sending the signal.

    This table describes the services available for metric alert rules:

    Signal sourceDescription
    PlatformFor metric signals, the monitor service is the metric namespace. "Platform" means the metrics are provided by the resource provider, namely, Azure.
    Azure.ApplicationInsightsCustomer-reported metrics, sent by the Application Insights SDK.
    Azure.VM.Windows.GuestMetricsVM guest metrics, collected by an extension running on the VM. Can include built-in operating system perf counters and custom perf counters.
    <your custom namespace>A custom metric namespace, containing custom metrics sent with the Azure Monitor Metrics API.

    Select the Signal name and Apply.

  3. Preview the results of the selected metric signal in the Preview section. Select values for the following fields.

    FieldDescription
    Time rangeThe time range to include in the results. Can be from the last six hours to the last week.
    Time seriesThe time series to include in the results.
  4. In the Alert logic section:

    FieldDescription
    ThresholdSelect if the threshold should be evaluated based on a static value or a dynamic value.
    static threshold evaluates the rule by using the threshold value that you configure.
    Dynamic thresholds use machine learning algorithms to continuously learn the metric behavior patterns and calculate the appropriate thresholds for unexpected behavior. You can learn more about using dynamic thresholds for metric alerts.
    OperatorSelect the operator for comparing the metric value against the threshold.
    If you're using dynamic thresholds, alert rules can use tailored thresholds based on metric behavior for both upper and lower bounds in the same alert rule. Select one of these operators:
    - Greater than the upper threshold or lower than the lower threshold (default)
    - Greater than the upper threshold
    - Lower than the lower threshold
    Aggregation typeSelect the aggregation function to apply on the data points: Sum, Count, Average, Min, or Max.
    Threshold valueIf you selected a static threshold, enter the threshold value for the condition logic.
    UnitIf the selected metric signal supports different units, such as bytes, KB, MB, and GB, and if you selected a static threshold, enter the unit for the condition logic.
    Threshold sensitivityIf you selected a dynamic threshold, enter the sensitivity level. The sensitivity level affects the amount of deviation from the metric series pattern that's required to trigger an alert.
    High: Thresholds are tight and close to the metric series pattern. An alert rule is triggered on the smallest deviation, resulting in more alerts.
    Medium: Thresholds are less tight and more balanced. There are fewer alerts than with high sensitivity (default).
    Low: Thresholds are loose, allowing greater deviation from the metric series pattern. Alert rules are only triggered on large deviations, resulting in fewer alerts.
    Aggregation granularitySelect the interval that's used to group the data points by using the aggregation type function. Choose an Aggregation granularity (period) that's greater than the Frequency of evaluation to reduce the likelihood of missing the first evaluation period of an added time series.
    Frequency of evaluationSelect how often the alert rule is to be run. Select a frequency that's smaller than the aggregation granularity to generate a sliding window for the evaluation.
  5. (Optional) You can configure splitting by dimensions.

    Dimensions are name-value pairs that contain more data about the metric value. By using dimensions, you can filter the metrics and monitor specific time-series, instead of monitoring the aggregate of all the dimensional values.

    If you select more than one dimension value, each time series that results from the combination triggers its own alert and is charged separately. For example, the transactions metric of a storage account can have an API name dimension that contains the name of the API called by each transaction (for example, GetBlob, DeleteBlob, and PutPage). You can choose to have an alert fired when there's a high number of transactions in a specific API (the aggregated data). Or you can use dimensions to alert only when the number of transactions is high for specific APIs.

    FieldDescription
    Dimension nameDimensions can be either number or string columns. Dimensions are used to monitor specific time series and provide context to a fired alert.
    Splitting on the Azure Resource ID column makes the specified resource into the alert target. If detected, the ResourceID column is selected automatically and changes the context of the fired alert to the record's resource.
    OperatorThe operator used on the dimension name and value.
    Dimension valuesThe dimension values are based on data from the last 48 hours. Select Add custom value to add custom dimension values.
    Include all future valuesSelect this field to include any future values added to the selected dimension.
  6. (Optional) In the When to evaluate section:

    FieldDescription
    Check everySelect how often the alert rule checks if the condition is met.
    Lookback periodSelect how far back to look each time the data is checked. For example, every 1 minute, look back 5 minutes.
  7. (Optional) In the Advanced options section, you can specify how many failures within a specific time period trigger an alert. For example, you can specify that you only want to trigger an alert if there were three failures in the last hour. Your application business policy should determine this setting.

    Select values for these fields:

    FieldDescription
    Number of violationsThe number of violations within the configured time frame that trigger the alert.
    Evaluation periodThe time period within which the number of violations occur.
    Ignore data beforeUse this setting to select the date from which to start using the metric historical data for calculating the dynamic thresholds. For example, if a resource was running in testing mode and is moved to production, you may want to disregard the metric behavior while the resource was in testing.
  8. Select Done. From this point on, you can select the Review + create button at any time.

Configure the alert rule actions

Follow these steps:

  1. Select the Actions tab.

  2. Select or create the required action groups.

    Screenshot that shows the Actions tab when creating a new alert rule.

Configure the alert rule details

Follow these steps:

  1. On the Details tab, define the Project details.

    • Select the Subscription.
    • Select the Resource group.
  2. Define the Alert rule details.

    Screenshot that shows the Details tab when creating a new alert rule.

  3. Select the Severity.

  4. Enter values for the Alert rule name and the Alert rule description.

  5. (Optional) If you're creating a metric alert rule that monitors a custom metric with the scope defined as one of the following regions and you want to make sure that the data processing for the alert rule takes place within that region, you can select to process the alert rule in one of these regions:

    • North Europe
    • West Europe
    • Sweden Central
    • Germany West Central
  6. (Optional) In the Advanced options section, you can set several options.

    FieldDescription
    Enable upon creationSelect for the alert rule to start running as soon as you're done creating it.
    Automatically resolve alerts (preview)Select to make the alert stateful. When an alert is stateful, the alert is resolved when the condition is no longer met.
    If you don't select this checkbox, metric alerts are stateless. Stateless alerts fire each time the condition is met, even if alert already fired.
    The frequency of notifications for stateless metric alerts differs based on the alert rule's configured frequency:
    Alert frequency of less than 5 minutes: While the condition continues to be met, a notification is sent somewhere between one and six minutes.
    Alert frequency of more than 5 minutes: While the condition continues to be met, a notification is sent between the configured frequency and doubles the value of the frequency. For example, for an alert rule with a frequency of 15 minutes, a notification is sent somewhere between 15 to 30 minutes.
  7. (Optional) In the Custom properties section, if this alert rule contains action groups, you can add your own properties to include in the alert notification payload. You can use these properties in the actions that the action group calls, such as by a webhook, Azure function, or logic app action.

    The custom properties are specified as key/value pairs by using static text, a dynamic value extracted from the alert payload, or a combination of both.

    The format for extracting a dynamic value from the alert payload is: ${<path to schema field>}. For example: ${data.essentials.monitorCondition}.

    Use the format of the common alert schema to specify the field in the payload, whether or not the action groups configured for the alert rule use the common schema.

     Note

    • The common alert schema overwrites custom configurations. You can't use both custom properties and the common schema.
    • Custom properties are added to the payload of the alert, but they don't appear in the email template or in the alert details in the Azure portal.
    • Azure Service Health alerts don't support custom properties.

    Screenshot that shows custom properties for creating a new alert rule.

    The following examples use values in Custom properties to utilize data from a payload that uses the common alert schema.

    This example creates an Additional Details tag with data regarding the window start time and window end time:

    • Name: Additional Details
    • Value: Evaluation windowStartTime: \${data.alertContext.condition.windowStartTime}. windowEndTime: \${data.alertContext.condition.windowEndTime}
    • Result: AdditionalDetails:Evaluation windowStartTime: 2023-04-04T14:39:24.492Z. windowEndTime: 2023-04-04T14:44:24.492Z

    This example adds data regarding the reason for resolving or firing the alert:

    • Name: Alert \${data.essentials.monitorCondition} reason
    • Value: \${data.alertContext.condition.allOf[0].metricName} \${data.alertContext.condition.allOf[0].operator} \${data.alertContext.condition.allOf[0].threshold} \${data.essentials.monitorCondition}. The value is \${data.alertContext.condition.allOf[0].metricValue}
    • Potential results:
      • Alert Resolved reason: Percentage CPU GreaterThan5 Resolved. The value is 3.585
      • Alert Fired reason": "Percentage CPU GreaterThan5 Fired. The value is 10.585

Configure alert rule tags

Follow these steps:

  1. Select the Tags tab.

  2. Set any required tags on the alert rule resource.

    Screenshot that shows the Tags tab when creating a new alert rule.

Review and create the alert rule

Follow these steps:

  1. On the Review + create tab, the rule is validated, and lets you know about any issues.

  2. When validation passes and you've reviewed the settings, select the Create button.

    Screenshot that shows the Review and create tab when creating a new alert rule.

Azure DDoS Protection features

 

Azure DDoS Protection features

Always-on traffic monitoring

Azure DDoS Protection monitors actual traffic utilization and constantly compares it against the thresholds defined in the DDoS Policy. When the traffic threshold is exceeded, DDoS mitigation is initiated automatically. When traffic returns below the thresholds, the mitigation is stopped.

Screenshot of Azure DDoS Protection Mitigation.

During mitigation, traffic sent to the protected resource is redirected by the DDoS protection service and several checks are performed, such as:

  • Ensure packets conform to internet specifications and are not malformed.
  • Interact with the client to determine if the traffic is potentially a spoofed packet (e.g: SYN Auth or SYN Cookie or by dropping a packet for the source to retransmit it).
  • Rate-limit packets, if no other enforcement method can be performed.

Azure DDoS Protection drops attack traffic and forwards the remaining traffic to its intended destination. Within a few minutes of attack detection, you are notified using Azure Monitor metrics. By configuring logging on DDoS Protection telemetry, you can write the logs to available options for future analysis. Metric data in Azure Monitor for DDoS Protection is retained for 30 days.

Adaptive real time tuning

The complexity of attacks (for example, multi-vector DDoS attacks) and the application-specific behaviors of tenants call for per-customer, tailored protection policies. The service accomplishes this by using two insights:

  • Automatic learning of per-customer (per-Public IP) traffic patterns for Layer 3 and 4.

  • Minimizing false positives, considering that the scale of Azure allows it to absorb a significant amount of traffic.

Diagram of how DDoS Protection works.

DDoS Protection telemetry, monitoring, and alerting

Azure DDoS Protection exposes rich telemetry via Azure Monitor. You can configure alerts for any of the Azure Monitor metrics that DDoS Protection uses. You can integrate logging with Splunk (Azure Event Hubs), Azure Monitor logs, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.

Azure DDoS Protection mitigation policies

In the Azure portal, select Monitor > Metrics. In the Metrics pane, select the resource group, select a resource type of Public IP Address, and select your Azure public IP address. DDoS metrics are visible in the Available metrics pane.

DDoS Protection applies three auto-tuned mitigation policies (TCP SYN, TCP, and UDP) for each public IP of the protected resource, in the virtual network that has DDoS enabled. You can view the policy thresholds by selecting the metric Inbound packets to trigger DDoS mitigation.

Screenshot of available metrics and metrics chart.

The policy thresholds are auto-configured via machine learning-based network traffic profiling. DDoS mitigation occurs for an IP address under attack only when the policy threshold is exceeded.

For more information, see View and configure DDoS Protection telemetry.

Metric for an IP address under DDoS attack

If the public IP address is under attack, the value for the metric Under DDoS attack or not changes to 1 as DDoS Protection performs mitigation on the attack traffic.

Screenshot of Under DDoS attack or not metric and chart.

We recommend configuring an alert on this metric. You'll then be notified when there’s an active DDoS mitigation performed on your public IP address.