fix more blocking issues

Author: AbbyMSFT

articles/azure-monitor/alerts/alerts-dynamic-thresholds.md

@@ -9,18 +9,18 @@ ms.date: 2/23/2022
 
 # Dynamic thresholds in Metric Alerts
 
-Metric alerts with Dynamic Thresholds detection applies advanced machine learning (ML) to learn metrics' historical behavior, identify patterns and anomalies that indicate possible service issues. It provides support of both a simple UI and operations at scale by allowing users to configure alert rules through the fully automated Azure Resource Manager API.
+ Dynamic thresholds in metric alerts use advanced machine learning (ML) to learn metrics' historical behavior, and to identify patterns and anomalies that indicate possible service issues. Dynamic thresholds in metric alerts support both a simple UI and operations at scale by allowing users to configure alert rules through the fully automated Azure Resource Manager API.
 
 An alert rule using a dynamic threshold only fires when the monitored metric doesn’t behave as expected, based on its tailored thresholds.
 
 We would love to hear your feedback, keep it coming at <[email protected]>.
 
 Alert rules with dynamic thresholds provide: 
-- **Scalable Alerting**. Dynamic threshold alert rules can create tailored thresholds for hundreds of metric series at a time, yet provide are just as easy to define as an alert rule on a single metric. They give you fewer alerts to create and manage. You can use either Azure portal or the Azure Resource Manager API to create them. The scalable approach is especially useful when dealing with metric dimensions or when applying to multiple resources, such as to all subscription resources. [Learn more about how to configure Metric Alerts with Dynamic Thresholds using templates](./alerts-metric-create-templates.md).
+- **Scalable Alerting**. Dynamic threshold alert rules can create tailored thresholds for hundreds of metric series at a time, yet are as easy to define as an alert rule on a single metric. They give you fewer alerts to create and manage. You can use either Azure portal or the Azure Resource Manager API to create them. The scalable approach is especially useful when dealing with metric dimensions or when applying to multiple resources, such as to all subscription resources. [Learn more about how to configure Metric Alerts with Dynamic Thresholds using templates](./alerts-metric-create-templates.md).
 
 - **Smart Metric Pattern Recognition**. Using our ML technology, we’re able to automatically detect metric patterns and adapt to metric changes over time, which may often include seasonality (hourly / daily / weekly). Adapting to the metrics’ behavior over time and alerting based on deviations from its pattern relieves the burden of knowing the "right" threshold for each metric. The ML algorithm used in dynamic thresholds is designed to prevent noisy (low precision) or wide (low recall) thresholds that don’t have an expected pattern.
 
-- **Intuitive Configuration**. Dynamic thresholds allows setting up metric alerts using high-level concepts, alleviating the need to have extensive domain knowledge about the metric.
+- **Intuitive Configuration**. Dynamic thresholds allow you to set up metric alerts using high-level concepts, alleviating the need to have extensive domain knowledge about the metric.
 
 ## Configure alerts rules with dynamic thresholds
 
@@ -55,7 +55,7 @@ You can choose the alert to be triggered on one of the following three condition
 
 ## What do the advanced settings in Dynamic Thresholds mean?
 
-**Failing Periods**. Dynamic Thresholds also allows you to configure "Number violations to trigger the alert", a minimum number of deviations required within a certain time window for the system to raise an alert (the default time window is four deviations in 20 minutes). The user can configure failing periods and choose what to be alerted on by changing the failing periods and time window. This ability reduces alert noise generated by transient spikes. For example:
+**Failing Periods**. Using dynamic thresholds, you can also configure a minimum number of deviations required within a certain time window for the system to raise an alert. The default is four deviations in 20 minutes. You can configure failing periods and choose what to be alerted on by changing the failing periods and time window. These configurations reduce alert noise generated by transient spikes. For example:
 
 To trigger an alert when the issue is continuous for 20 minutes, 4 consecutive times in a given period grouping of 5 minutes, use the following settings:
 
@@ -65,7 +65,7 @@ To trigger an alert when there was a violation from a Dynamic Thresholds in 20 m
 
 ![Failing periods settings for issue for 20 minutes out of the last 30 minutes with period grouping of 5 minutes](media/alerts-dynamic-thresholds/0009.png)
 
-**Ignore data before**. Users may also optionally define a start date from which the system should begin calculating the thresholds from. A typical use case may occur when a resource was a running in a testing mode and is now promoted to serve a production workload, and therefore the behavior of any metric during the testing phase should be disregarded.
+**Ignore data before**. Users may also optionally define a start date from which the system should begin calculating the thresholds. A typical use case may occur when a resource was a running in a testing mode and is now promoted to serve a production workload, and therefore the behavior of any metric during the testing phase should be disregarded.
 
 > [!NOTE]
 > An alert fires when the rule is evaluated and the result shows an anomaly. The alert is resolved if the rule is evaluated and does not show an anomaly three times in a row.
@@ -123,40 +123,40 @@ The following items are best practices on how to configure alerts on some of the
     1. **Condition Type** - Choose 'Dynamic' option.
     1. **Sensitivity** - Choose Medium/Low sensitivity to reduce alert noise.
     1. **Operator** - Choose 'Greater Than' unless behavior represents the application usage.
-    1. **Frequency** - Consider lowering based on business impact of the alert.
+    1. **Frequency** - Consider lowering the frequency based on business impact of the alert.
     1. **Failing Periods** (Advanced Option) - The look back window should be at least 15 minutes. For example, if the period is set to five minutes, then failing periods should be at least three or more.
 
 8. The metric chart displays the calculated thresholds based on recent data.
 
-9. Click **Done**.
+9. Select **Done**.
 
 10. Fill in **Alert details** like **Alert Rule Name**, **Description**, and **Severity**.
 
 11. Add an action group to the alert either by selecting an existing action group or creating a new action group.
 
-12. Click **Done** to save the metric alert rule.
+12. Select **Done** to save the metric alert rule.
 
 > [!NOTE]
 > Metric alert rules created through portal are created in the same resource group as the target resource.
 
 ### Configure dynamic thresholds on Application Insights HTTP request execution time
 
-1. In [Azure portal](https://portal.azure.com), click on **Monitor**. The Monitor view consolidates all your monitoring settings and data in one view.
+1. In [Azure portal](https://portal.azure.com), select on **Monitor**. The Monitor view consolidates all your monitoring settings and data in one view.
 
-2. Click **Alerts** then click **+ New alert rule**.
+2. Select **Alerts** then select **+ New alert rule**.
 
     > [!TIP]
     > Most resource blades also have **Alerts** in their resource menu under **Monitoring**, you could create alerts from there as well.
 
-3. Click **Select target**, in the context pane that loads, select a target resource that you want to alert on. Use **Subscription** and **'Application Insights' Resource type** drop-downs to find the resource you want to monitor. You can also use the search bar to find your resource.
+3. Select **Select target**, in the context pane that loads, select a target resource that you want to alert on. Use **Subscription** and **'Application Insights' Resource type** drop-downs to find the resource you want to monitor. You can also use the search bar to find your resource.
 
 4. Once you've selected a target resource, select **Add condition**.
 
 5. Select the **'HTTP request execution time'**.
 
-6. Optionally, refine the metric by adjusting **Period** and **Aggregation**. It is discouraged to use 'Maximum' aggregation type for this metric type as it is less representative of behavior. For 'Maximum' aggregation type static threshold maybe more appropriate.
+6. Optionally, refine the metric by adjusting **Period** and **Aggregation**. We discourage using the **Maximum** aggregation type for this metric type, since it is less representative of behavior. Static thresholds maybe more appropriate for the **Maximum** aggregation type.
 
-7. You will see a chart for the metric for the last 6 hours. Define the alert parameters:
+7. You'll see a chart for the metric for the last 6 hours. Define the alert parameters:
     1. **Condition Type** - Choose 'Dynamic' option.
     1. **Operator** - Choose 'Greater Than' to reduce alerts fired on improvement in duration.
     1. **Frequency** - Consider lowering based on business impact of the alert.
@@ -184,9 +184,9 @@ Use the following information to interpret the previous chart.
 
 - **Blue line** - The actual measured metric over time.
 - **Blue shaded area** - Shows the allowed range for the metric. As long as the metric values stay within this range, no alert will occur.
-- **Blue dots** - If you left click on part of the chart and then hover over the blue line, you see a blue dot appear under your cursor showing an individual aggregated metric value.
+- **Blue dots** - If you left select on part of the chart and then hover over the blue line, a blue dot appears under your cursor showing an individual aggregated metric value.
 - **Pop-up with blue dot** - Shows the measured metric value (the blue dot) and the upper and lower values of allowed range.  
 - **Red dot with a black circle** - Shows the first metric value out of the allowed range. This is the value that fires a metric alert and puts it in an active state.
-- **Red dots**- Indicate additional measured values outside of the allowed range. They won't fire additional metric alerts, but the alert stays in the active.
+- **Red dots**- Indicate other measured values outside of the allowed range. They won't fire additional metric alerts, but the alert stays in the active.
 - **Red area** - Shows the time when the metric value was outside of the allowed range. The alert remains in the active state as long as subsequent measured values are out of the allowed range, but no new alerts are fired.
 - **End of red area** - When the blue line is back inside the allowed values, the red area stops and the measured value line turns blue. The status of the metric alert fired at the time of the red dot with black outline is set to resolved.