edit pass: set-up-alert-rules

ShawnJackson · ShawnJackson · commit 2da902d87697 · 2024-06-12T15:13:08.000-05:00
diff --git a/articles/azure-monitor/alerts/alerts-create-log-alert-rule.md b/articles/azure-monitor/alerts/alerts-create-log-alert-rule.md
@@ -77,7 +77,7 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
 
     |Field  |Description  |
     |---------|---------|
-    |**Measure**|Log search alerts can measure two things that you can use for various monitoring scenarios:<br> **Table rows**: You can use the number of rows returned to work with events such as Windows event logs, Syslog, and application exceptions. <br>**Calculation of a numeric column**: You can use calculations based on any numeric column to include any number of resources. An example is CPU percentage.      |
+    |**Measure**|Log search alerts can measure two things that you can use for various monitoring scenarios:<br> **Table rows**: You can use the number of returned rows to work with events such as Windows event logs, Syslog, and application exceptions. <br>**Calculation of a numeric column**: You can use calculations based on any numeric column to include any number of resources. An example is CPU percentage.      |
     |**Aggregation type**| The calculation performed on multiple records to aggregate them to one numeric value by using the aggregation granularity. Examples are **Total**, **Average**, **Minimum**, and **Maximum**.    |
     |**Aggregation granularity**| The interval for aggregating multiple records to one numeric value.|
 
@@ -123,7 +123,7 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
     :::image type="content" source="media/alerts-create-new-alert-rule/alerts-create-log-rule-logic.png" alt-text="Screenshot that shows the section for alert logic in a new log search alert rule.":::
 
     > [!NOTE]
-    > The frequency is not a specific time that the alert runs every day. It's how often the alert rule will run.
+    > The frequency is not a specific time that the alert runs every day. It's how often the alert rule runs.
     >
     > There are some limitations to using an alert rule frequency of <a name="frequency">one minute</a>. When you set the alert rule frequency to one minute, an internal manipulation is performed to optimize the query. This manipulation can cause the query to fail if it contains unsupported operations. The most common reasons why a query isn't supported are:
     >
@@ -142,7 +142,7 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
    |---------|---------|
    |**Number of violations**|The number of violations that trigger the alert.|
    |**Evaluation period**|The time period within which the number of violations occur. |
-   |**Override query time range**| If you want the alert evaluation period to be different from the query time range, enter a time range here.<br> The alert time range is limited to a maximum of two days. Even if the query contains an `ago` command with a time range of longer than two days, the two-day maximum time range is applied. For example, even if the query text contains `ago(7d)`, the query only scans up to two days of data. If the query requires more data than the alert evaluation, you can change the time range manually. If the query contains an `ago` command, it will change automatically to two days (48 hours).|
+   |**Override query time range**| If you want the alert evaluation period to be different from the query time range, enter a time range here.<br> The alert time range is limited to a maximum of two days. Even if the query contains an `ago` command with a time range of longer than two days, the two-day maximum time range is applied. For example, even if the query text contains `ago(7d)`, the query only scans up to two days of data. If the query requires more data than the alert evaluation, you can change the time range manually. If the query contains an `ago` command, it changes automatically to two days (48 hours).|
 
    :::image type="content" source="media/alerts-create-new-alert-rule/alerts-rule-preview-advanced-options.png" alt-text="Screenshot that shows the section for advanced options in a new log search alert rule.":::
 
@@ -175,17 +175,17 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
     Keep these points in mind when you're selecting an identity:
 
     - A managed identity is required if you're sending a query to Azure Data Explorer or Resource Graph.
-    - Use a managed identity if you want to be able to see or edit the permissions associated with the alert rule.
+    - Use a managed identity if you want to be able to view or edit the permissions associated with the alert rule.
     - If you don't use a managed identity, the alert rule permissions are based on the permissions of the last user to edit the rule, at the time that the rule was last edited.
     - Use a managed identity to help you avoid a case where the rule doesn't work as expected because the user who last edited the rule didn't have permissions for all the resources added to the scope of the rule.
 
     The identity associated with the rule must have these roles:
 
-    - If the query is accessing a Log Analytics workspace, the identity must be assigned a reader role for all workspaces that the query accesses. If you're creating resource-centric log search alerts, the alert rule might access multiple workspaces, and the identity must have a reader role on all of them.
-    - If you're querying an Azure Data Explorer or Resource Graph cluster, you must add the reader role for all data sources that the query accesses. For example, if the query is resource centric, it needs a reader role on that resource.
+    - If the query is accessing a Log Analytics workspace, the identity must be assigned a *reader* role for all workspaces that the query accesses. If you're creating resource-centric log search alerts, the alert rule might access multiple workspaces, and the identity must have a reader role on all of them.
+    - If you're querying an Azure Data Explorer or Resource Graph cluster, you must add the *reader* role for all data sources that the query accesses. For example, if the query is resource centric, it needs a reader role on that resource.
     - If the query is [accessing a remote Azure Data Explorer cluster](../logs/azure-monitor-data-explorer-proxy.md), the identity must be assigned:
-      - A reader role for all data sources that the query accesses. For example, if the query is calling a remote Azure Data Explorer cluster by using the `adx()` function, it needs a reader role on that Azure Data Explorer cluster.
-      - A database viewer role for all databases that the query accesses.
+      - A *reader* role for all data sources that the query accesses. For example, if the query is calling a remote Azure Data Explorer cluster by using the `adx()` function, it needs a reader role on that Azure Data Explorer cluster.
+      - A *database viewer* role for all databases that the query accesses.
 
     For detailed information on managed identities, see [Managed identities for Azure resources](../../active-directory/managed-identities-azure-resources/overview.md).
 
diff --git a/articles/azure-monitor/alerts/alerts-dynamic-thresholds.md b/articles/azure-monitor/alerts/alerts-dynamic-thresholds.md
@@ -15,7 +15,7 @@ Dynamic thresholds apply advanced machine learning and use a set of algorithms a
 - Learn the historical behavior of metrics.
 - Analyze metrics over time and identify patterns such as hourly, daily, or weekly patterns.
 - Recognize anomalies that indicate possible service issues.
-- Calculate the most appropriate threshold for the metric.
+- Calculate the most appropriate thresholds for metrics.
 
 When you use dynamic thresholds, you don't have to know the right threshold for each metric. Dynamic thresholds calculate the most appropriate thresholds for you.
 
@@ -54,7 +54,7 @@ The system automatically recognizes prolonged outages and removes them from the
 
 ## Considerations for using dynamic thresholds
 
-- To ensure accurate threshold calculation, alert rules that use dynamic thresholds don't trigger an alert before collecting three days and at least 30 samples of metric data. New resources or resources that are missing metric data don't trigger an alert until enough data is available.
+- To help ensure accurate threshold calculation, alert rules that use dynamic thresholds don't trigger an alert before collecting three days and at least 30 samples of metric data. New resources or resources that are missing metric data don't trigger an alert until enough data is available.
 - Dynamic thresholds need at least three weeks of historical data to detect weekly seasonality. Some detailed patterns, such as bihourly or semiweekly patterns, might not be detected.
 - If the behavior of a metric changed recently, the changes aren't immediately reflected in the dynamic threshold's upper and lower bounds. The borders are calculated based on metric data from the last 10 days. When you view the dynamic threshold's borders for a particular metric, look at the metric trend in the last week and not only for recent hours or days.
 - Dynamic thresholds are good for detecting significant deviations, as opposed to slowly evolving issues. Slow behavior changes probably won't trigger an alert.
@@ -82,7 +82,7 @@ The system automatically recognizes prolonged outages and removes them from the
 
 ## Configuration of dynamic thresholds
 
-To configure dynamic thresholds, follow the [procedure to create an alert rule](alerts-create-new-alert-rule.md#create-or-edit-an-alert-rule-in-the-azure-portal) by using these settings on the **Condition** tab:
+To configure dynamic thresholds, follow the [procedure for creating an alert rule](alerts-create-new-alert-rule.md#create-or-edit-an-alert-rule-in-the-azure-portal). Use these settings on the **Condition** tab:
 
 - For **Threshold**, select **Dynamic**.
 - For **Aggregation type**, we recommend that you don't select **Maximum**.
@@ -106,15 +106,15 @@ Use the following information to interpret the chart:
 - **Blue line**: The metric measured over time.
 - **Blue shaded area**: The allowed range for the metric. If the metric values stay within this range, no alert is triggered.
 - **Blue dots**: Aggregated metric values. If you select part of the chart and then hover over the blue line, a blue dot appears under your cursor to indicate an individual aggregated metric value.
-- **Pop-up with blue dot**: The measured metric value (blue dot) and the upper and lower values of the allowed range.  
-- **Red dot with a black circle**: The first metric value out of the allowed range. This value fires a metric alert and puts it in an active state.
+- **Pop-up box with blue dot**: The measured metric value (blue dot) and the upper and lower values of the allowed range.  
+- **Red dot with a black circle**: The first metric value outside the allowed range. This value fires a metric alert and puts it in an active state.
 - **Red dots**: Other measured values outside the allowed range. They don't trigger more metric alerts, but the alert stays in the active state.
-- **Red area**: The time when the metric value was outside 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.
+- **Red area**: The time when the metric value was outside the allowed range. The alert remains in the active state as long as subsequent measured values are outside the allowed range, but no new alerts are fired.
 - **End of red area**: A return to allowed values. 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 a black circle is set to resolved.
 
 ## Metrics not supported by dynamic thresholds
 
-Dynamic thresholds are supported for most metrics, but the following metrics can't use dynamic thresholds:
+Dynamic thresholds support most metrics, but the following metrics can't use dynamic thresholds:
 
 | Resource type | Metric name |
 | --- | --- |
diff --git a/articles/azure-monitor/alerts/alerts-metric-logs.md b/articles/azure-monitor/alerts/alerts-metric-logs.md
@@ -27,7 +27,7 @@ Benefits of using metric alerts for logs over query-based [log search alerts](./
 - Metric alerts provide multiple dimensions. They allow filtering to specific values like computers and OS types without the need for defining a complex query in Log Analytics.
 
 > [!NOTE]
-> A specific metric or dimension appears only if data for it exists in the chosen period. These metrics are available for customers who have Azure Log Analytics workspaces.
+> A specific metric or dimension appears only if data for it exists in the chosen period. These metrics are available for customers who have Log Analytics workspaces.
 
 ## Supported metrics and dimensions for logs
 
@@ -68,13 +68,13 @@ For step-by-step details and samples, see [Create or edit a metric alert rule](.
 - When you're configuring signal logic, you can create a single alert to span multiple values of dimension (like computer).
 - When you're creating a metric alert for logs by using the Azure portal, a corresponding rule for converting log data into a metric via `scheduledQueryRules` is automatically created in the background, without the need for any user intervention or action.
 
-  If you're *not* using the Azure portal for creating a metric alert for a selected Log Analytics workspace, you must first manually create an explicit rule for converting log data into a metric by using `scheduledQueryRules`.
+  If you're *not* using the Azure portal to create a metric alert for a selected Log Analytics workspace, you must first manually create an explicit rule for converting log data into a metric by using `scheduledQueryRules`.
 
 ## Resource Manager templates
 
 To create a metric alert for logs, you can use the following sample Resource Manager templates.
 
-For metric alerts for logs created through means other than the Azure portal, you can use these sample templates to create a `scheduledQueryRules`-based log-to-metric conversion rule before metric alert creation. If you don't, there will be no data for the metric alert in the logs.
+For metric alerts for logs created through means other than the Azure portal, you can use these sample templates to create a `scheduledQueryRules`-based log-to-metric conversion rule before you create a metric alert. If you don't, there will be no data for the metric alert in the logs.
 
 ### Metric alert for logs with a static threshold
 
diff --git a/articles/azure-monitor/alerts/alerts-troubleshoot.md b/articles/azure-monitor/alerts/alerts-troubleshoot.md
@@ -214,7 +214,7 @@ If you received a notification for an alert (such as an email or an SMS) more th
 
 ### **The `MetricValue` field contains "null" for resolved log search alert notifications.**
 
-   This is by design. Stateful log search alerts use a [time-based resolution logic](./alerts-create-log-alert-rule.md#configure-the-alert-rule-details) rather than value-based. Azure Monitor is sending a null metric value since there's no value that caused the alert to resolve, but rather elapsed time.
+   This is by design. Stateful log search alerts use a [time-based resolution logic](./alerts-create-log-alert-rule.md#configure-alert-rule-details) rather than value-based. Azure Monitor is sending a null metric value since there's no value that caused the alert to resolve, but rather elapsed time.
 
 ### The dimensions list is empty or alert title doesn't contain a dimension name
 
diff --git a/articles/azure-monitor/alerts/prometheus-alerts.md b/articles/azure-monitor/alerts/prometheus-alerts.md
@@ -12,7 +12,7 @@ ms.date: 04/01/2024
 
 As part of [Azure Monitor managed services for Prometheus](../essentials/prometheus-metrics-overview.md), you can use Prometheus alert rules to define alert conditions by using queries written in Prometheus Query Language (PromQL). The rule queries are applied on Prometheus metrics stored in an [Azure Monitor workspace](../essentials/azure-monitor-workspace-overview.md).
 
-Whenever the alert query results in one or more time series meeting the condition, the alert counts as pending for these metric and label sets. A pending alert becomes active after a user-defined period of time, during which all the consecutive query evaluations for the respective time series meet the alert condition. After an alert becomes active, it's fired and triggers your actions or notifications of choice, as defined in the Azure action groups configured in your alert rule.
+Whenever the alert query results in one or more time series meeting the condition, the alert counts as pending for these metric and label sets. A pending alert becomes active after a user-defined period of time during which all the consecutive query evaluations for the respective time series meet the alert condition. After an alert becomes active, it's fired and triggers your actions or notifications of choice, as defined in the Azure action groups configured in your alert rule.
 
 ## Create Prometheus alert rules
 
diff --git a/articles/governance/resource-graph/alerts-query-quickstart.md b/articles/governance/resource-graph/alerts-query-quickstart.md
@@ -458,4 +458,4 @@ For more information about the query language or how to explore resources, go to
 - [Explore your Azure resources with Resource Graph](./concepts/explore-resources.md)
 - [Overview of Log Analytics in Azure Monitor](../../azure-monitor/logs/log-analytics-overview.md)
 - [Collect events and performance counters from virtual machines with Azure Monitor Agent](../..//azure-monitor/agents/data-collection-rule-azure-monitor-agent.md)
-- [Role assignments for Azure Data Explorer clusters](../../azure-monitor/alerts/alerts-create-log-alert-rule.md#configure-the-alert-rule-details)
+- [Role assignments for Azure Data Explorer clusters](../../azure-monitor/alerts/alerts-create-log-alert-rule.md#configure-alert-rule-details)
diff --git a/articles/update-manager/manage-alerts.md b/articles/update-manager/manage-alerts.md
@@ -53,7 +53,7 @@ To enable alerts (Preview) with Azure Update Manager through Azure portal, follo
    
     :::image type="content" source="./media/manage-alerts/advance-alert-rule-configuration-inline.png" alt-text="Screenshot that shows how to configure advanced alert rule." lightbox="./media/manage-alerts/advance-alert-rule-configuration-expanded.png":::
 
-1. Select **Review + create** to create alert. For more information, see [Create Azure Monitor alert rules](../azure-monitor/alerts/alerts-create-log-alert-rule.md#configure-the-alert-rule-conditions).
+1. Select **Review + create** to create alert. For more information, see [Create Azure Monitor alert rules](../azure-monitor/alerts/alerts-create-log-alert-rule.md#configure-alert-rule-conditions).
     - To identify alerts & alert rules created for Azure Update Manager, provide unique **Alert rule name** in the **Details** tab.
         :::image type="content" source="./media/manage-alerts/unique-alert-name-inline.png" alt-text="Screenshot that shows how to create unique alert name." lightbox="./media/manage-alerts/unique-alert-name-expanded.png":::
 
