Merge pull request #231350 from AbbyMSFT/recommended-alerts

v-dirichards · web-flow · commit 8115baf8bd7e · 2023-03-20T11:12:56.000-05:00
Recommended alerts for AKS &amp; LA Workspaces + popular signals
diff --git a/articles/aks/learn/quick-kubernetes-deploy-portal.md b/articles/aks/learn/quick-kubernetes-deploy-portal.md
@@ -30,18 +30,15 @@ This quickstart assumes a basic understanding of Kubernetes concepts. For more i
 ## Create an AKS cluster
 
 1. Sign in to the [Azure portal](https://portal.azure.com).
-
-2. On the Azure portal menu or from the **Home** page, select **Create a resource**.
-
-3. Select **Containers** > **Kubernetes Service**.
-
-4. On the **Basics** page, configure the following options:
+1. On the Azure portal menu or from the **Home** page, select **Create a resource**.
+1. Select **Containers** > **Kubernetes Service**.
+1. On the **Basics** page, configure the following options:
 
     - **Project details**:
         * Select an Azure **Subscription**.
         * Select or create an Azure **Resource group**, such as *myResourceGroup*.
     - **Cluster details**:
-        * Ensure the the **Preset configuration** is *Standard ($$)*. For more details on preset configurations, see [Cluster configuration presets in the Azure portal][preset-config].
+        * Ensure the **Preset configuration** is *Standard ($$)*. For more details on preset configurations, see [Cluster configuration presets in the Azure portal][preset-config].
         * Enter a **Kubernetes cluster name**, such as *myAKSCluster*.
         * Select a **Region** for the AKS cluster, and leave the default value selected for **Kubernetes version**.
         * Select **99.5%** for **API server availability**.
@@ -54,20 +51,20 @@ This quickstart assumes a basic understanding of Kubernetes concepts. For more i
     > You can change the preset configuration when creating your cluster by selecting *Learn more and compare presets* and choosing a different option.
     > :::image type="content" source="media/quick-kubernetes-deploy-portal/cluster-preset-options.png" alt-text="Screenshot of Create AKS cluster - portal preset options.":::
 
-5. Select **Next: Node pools** when complete.
-
-6. Keep the default **Node pools** options. At the bottom of the screen, click **Next: Access**.
-
-7. On the **Access** page, configure the following options:
+1. Select **Next: Node pools** when complete. 
+1. Keep the default **Node pools** options. At the bottom of the screen, click **Next: Access**.
+1. On the **Access** page, configure the following options:
 
     - The default value for **Resource identity** is **System-assigned managed identity**. Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. For more details about managed identities, see [What are managed identities for Azure resources?](../../active-directory/managed-identities-azure-resources/overview.md).
     - The Kubernetes role-based access control (RBAC) option is the default value to provide more fine-grained control over access to the Kubernetes resources deployed in your AKS cluster.
 
     By default, *Basic* networking is used, and [Container insights](../../azure-monitor/containers/container-insights-overview.md) is enabled.
 
-8. Click **Review + create**. When you navigate to the **Review + create** tab, Azure runs validation on the settings that you have chosen. If validation passes, you can proceed to create the AKS cluster by selecting **Create**. If validation fails, then it indicates which settings need to be modified.
-
-9. It takes a few minutes to create the AKS cluster. When your deployment is complete, navigate to your resource by either:
+1. Select **Next: Networking** when complete.
+1. Keep the default **Networking** options. At the bottom of the screen, click **Next: Integrations**.
+1. On the **Integrations** page, if you want to enable the [recommended out-of-the-box alerts](../../azure-monitor/alerts/alerts-overview.md#recommended-alert-rules) for AKS clusters, select **Enable recommended alert rules**. You can see the list of alerts that are automatically enabled if you select this option. 
+1. Click **Review + create**. When you navigate to the **Review + create** tab, Azure runs validation on the settings that you have chosen. If validation passes, you can proceed to create the AKS cluster by selecting **Create**. If validation fails, then it indicates which settings need to be modified.
+1. It takes a few minutes to create the AKS cluster. When your deployment is complete, navigate to your resource by either:
     * Selecting **Go to resource**, or
     * Browsing to the AKS cluster resource group and selecting the AKS resource. In this example you browse for *myResourceGroup* and select the resource *myAKSCluster*.
 
diff --git a/articles/azure-monitor/alerts/alerts-create-new-alert-rule.md b/articles/azure-monitor/alerts/alerts-create-new-alert-rule.md
@@ -37,7 +37,8 @@ Then you define these elements for the resulting alert actions by using:
 
 1. Select **Apply**.
 1. Select **Next: Condition** at the bottom of the page.
-1. On the **Select a signal** pane, you can search for the signal name or you can filter the list of signals by:
+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. 
+1. (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](alerts-overview.md#types-of-alerts) you're creating.
     - **Signal source**: The service sending the signal. The list is pre-populated based on the type of alert rule you selected.
 
@@ -57,30 +58,17 @@ Then you define these elements for the resulting alert actions by using:
     |Resource health|Resource health|The service that provides the resource-level health status. |
     |Service health|Service health|The service that provides the subscription-level health status.         |
 
-1. Select the **Signal name** and **Apply**.
+    Select the **Signal name** and **Apply**.
 1. Follow the steps in the tab that corresponds to the type of alert you're creating.
 
     ### [Metric alert](#tab/metric)
 
-    1. On the **Configure signal logic** pane, you can preview the results of the selected metric signal. Select values for the following fields.
+    1. Preview the results of the selected metric signal in the **Preview** section. Select values for the following fields.
 
         |Field |Description |
         |---------|---------|
-        |Select time series|Select the time series to include in the results. |
-        |Chart period|Select the time span to include in the results. Can be from the last six hours to the last week.|
-
-    1. (Optional) Depending on the signal type, you might see the **Split by dimensions** section.
-
-        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.
-
-        |Field  |Description  |
-        |---------|---------|
-        |Dimension name|Dimensions can be either number or string columns. Dimensions are used to monitor specific time series and provide context to a fired alert.<br>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.  |
-        |Operator|The operator used on the dimension name and value.  |
-        |Dimension values|The dimension values are based on data from the last 48 hours. Select **Add custom value** to add custom dimension values.  |
-        |Include all future values| Select this field to include any future values added to the selected dimension.  |
+        |Time range|The time range to include in the results. Can be from the last six hours to the last week.|
+        |Time series|The time series to include in the results.|
 
     1. In the **Alert logic** section:
 
@@ -94,6 +82,19 @@ Then you define these elements for the resulting alert actions by using:
         |Threshold sensitivity| If 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. <br> - **High**: Thresholds are tight and close to the metric series pattern. An alert rule is triggered on the smallest deviation, resulting in more alerts. <br> - **Medium**: Thresholds are less tight and more balanced. There will be fewer alerts than with high sensitivity (default). <br> - **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 granularity| Select 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 evaluation|Select 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.|
+ 
+    1. (Optional) Depending on the signal type, you might see the **Split by dimensions** section.
+
+        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.
+
+        |Field  |Description  |
+        |---------|---------|
+        |Dimension name|Dimensions can be either number or string columns. Dimensions are used to monitor specific time series and provide context to a fired alert.<br>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.  |
+        |Operator|The operator used on the dimension name and value.  |
+        |Dimension values|The dimension values are based on data from the last 48 hours. Select **Add custom value** to add custom dimension values.  |
+        |Include all future values| Select this field to include any future values added to the selected dimension.  |
 
     1. (Optional) In the **When to evaluate** section: 
 
diff --git a/articles/azure-monitor/alerts/alerts-manage-alert-rules.md b/articles/azure-monitor/alerts/alerts-manage-alert-rules.md
@@ -68,6 +68,7 @@ To enable recommended alert rules:
 1. On the **Alerts** page, select **Enable recommended alert rules**. The **Enable recommended alert rules** pane opens with a list of recommended alert rules based on your type of resource.  
 1. In the **Alert me if** section, select all of the rules you want to enable. The rules are populated with the default values for the rule condition, such as the percentage of CPU usage that you want to trigger an alert. You can change the default values if you would like.
 1. In the **Notify me by** section, select the way you want to be notified if an alert is fired.
+1. Select **Use an existing action group**, and enter the details of the existing action group if you want to use an action group that already exists.
 1. Select **Enable**.
 
     :::image type="content" source="media/alerts-managing-alert-instances/alerts-enable-recommended-alert-rule-pane.png" alt-text="Screenshot of recommended alert rules pane."::: 
diff --git a/articles/azure-monitor/alerts/alerts-overview.md b/articles/azure-monitor/alerts/alerts-overview.md
@@ -59,8 +59,13 @@ This table provides a brief description of each alert type. For more information
 
 If you don't have alert rules defined for the selected resource, you can [enable recommended out-of-the-box alert rules in the Azure portal](alerts-manage-alert-rules.md#enable-recommended-alert-rules-in-the-azure-portal).
 
+The system compiles a list of recommended alert rules based on:
+
+- The resource provider’s knowledge of important signals and thresholds for monitoring the resource.
+- Telemetry that tells us what customers commonly alert on for this resource.
+
 > [!NOTE]
-> The alert rule recommendations feature is currently in preview and is only enabled for:
+> Recommended alert rules is enabled for:
 > - Virtual machines
 > - AKS resources
 > - Log Analytics workspaces
diff --git a/articles/azure-monitor/logs/log-analytics-workspace-health.md b/articles/azure-monitor/logs/log-analytics-workspace-health.md
@@ -37,15 +37,24 @@ To view your Log Analytics workspace health and set up health status alerts:
    
     :::image type="content" source="media/data-ingestion-time/log-analytics-workspace-latency.png" lightbox="media/data-ingestion-time/log-analytics-workspace-latency.png" alt-text="Screenshot that shows the Resource health screen for a Log Analytics workspace.":::  
     
-1. To set up health status alerts:
-    1. Select **Add resource health alert**.
+1. To set up health status alerts, you can either [enable recommended out-of-the-box alert](../alerts/alerts-overview.md#recommended-alert-rules) rules, or manually create new alert rules.
+    - To enable the recommended alert rules:
+        1. select **Alerts**, then select **Enable recommended alert rules**. The **Enable recommended alert rules** pane opens with a list of recommended alert rules based on your type of resource.  
+        1. In the **Alert me if** section, select all of the rules you want to enable. The rules are populated with the default values for the rule condition, you can change the default values if you would like.
+        1. In the **Notify me by** section, select the way you want to be notified if an alert is fired.
+        1. Select **Use an existing action group**, and enter the details of the existing action group if you want to use an action group that already exists.
+        1. Select **Enable**.
+
+        :::image type="content" source="../alerts/media/alerts-managing-alert-instances/alerts-enable-recommended-alert-rule-pane.png" alt-text="Screenshot of recommended alert rules pane.":::
+
+    - To create a new alert rule:
+       1. Select **Add resource health alert**.
+        
+            The **Create alert rule** wizard opens, with the **Scope** and **Condition** panes pre-populated. By default, the rule triggers alerts all status changes in all Log Analytics workspaces in the subscription. If necessary, you can edit and modify the scope and condition at this stage. 
     
-        The **Create alert rule** wizard opens, with the **Scope** and **Condition** panes pre-populated. By default, the rule triggers alerts all status changes in all Log Analytics workspaces in the subscription. If necessary, you can edit and modify the scope and condition at this stage. 
-
-        :::image type="content" source="media/data-ingestion-time/log-analytics-workspace-latency-alert-rule.png" lightbox="media/data-ingestion-time/log-analytics-workspace-latency-alert-rule.png" alt-text="Screenshot that shows the Create alert rule wizard for Log Analytics workspace latency issues.":::  
-
-    1. Follow the rest of the steps in [Create a new alert rule in the Azure portal](../alerts/alerts-create-new-alert-rule.md#create-a-new-alert-rule-in-the-azure-portal). 
+            :::image type="content" source="media/data-ingestion-time/log-analytics-workspace-latency-alert-rule.png" lightbox="media/data-ingestion-time/log-analytics-workspace-latency-alert-rule.png" alt-text="Screenshot that shows the Create alert rule wizard for Log Analytics workspace latency issues.":::
 
+       1. Follow the rest of the steps in [Create a new alert rule in the Azure portal](../alerts/alerts-create-new-alert-rule.md#create-a-new-alert-rule-in-the-azure-portal). 
 ## Investigate Log Analytics workspace health issues
 
 To investigate Log Analytics workspace health issues:
