Merge pull request #186115 from yanivlavi/lsagaapichanges2

Made updates to log alerts doc post GA

Author: LJSpiller

articles/azure-monitor/alerts/alerts-log-api-switch.md

@@ -1,35 +1,36 @@
 ---
-title: Upgrade to the current Azure Monitor Log Alerts API
-description: Learn how to switch to the log alerts ScheduledQueryRules API
+title: Upgrade legacy rules management to the current Azure Monitor Log Alerts API
+description: Learn how to switch to the log alerts management to ScheduledQueryRules API
 author: yanivlavi
 ms.author: yalavi
 ms.topic: conceptual
-ms.date: 09/22/2020
+ms.date: 01/25/2022
 ---
-# Upgrade to the current Log Alerts API from legacy Log Analytics Alert API
+# Upgrade legacy rules management to the current Log Alerts API from legacy Log Analytics Alert API
 
 > [!NOTE]
 > This article is only relevant to Azure public (**not** to Azure Government or Azure China cloud).
 
 > [!NOTE]
-> Once a user chooses to switch preference to the current [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-02-01-preview/scheduled-query-rules) it is not possible to revert back to the older [legacy Log Analytics Alert API](./api-alerts.md).
+> Once a user chooses to switch rules with legacy management to the current [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-02-01-preview/scheduled-query-rules) it is not possible to revert back to the older [legacy Log Analytics Alert API](./api-alerts.md).
 
-In the past, users used the [legacy Log Analytics Alert API](./api-alerts.md) to manage log alert rules. Current workspaces use [ScheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-02-01-preview/scheduled-query-rules). This article describes the benefits and the process of switching from the legacy API to the current API.
+In the past, users used the [legacy Log Analytics Alert API](./api-alerts.md) to manage log alert rules. Currently workspaces use [ScheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-08-01/scheduled-query-rules) for new rules. This article describes the benefits and the process of switching legacy log alert rules management from the legacy API to the current API.
 
 ## Benefits
 
+- Manage all log rules in one API.
 - Single template for creation of alert rules (previously needed three separate templates).
 - Single API for all Azure resources log alerting.
-- Support for stateful and 1-minute log alert previews.
-- [PowerShell cmdlets support](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell).
-- Alignment of severities with all other alert types.
-- Ability to create [cross workspace log alert](../logs/cross-workspace-query.md) that span several external resources like Log Analytics workspaces or Application Insights resources.
-- Users can specify dimensions to split the alerts.
-- Log alerts have extended period of up to two days of data (previously limited to one day).
+- Support for stateful and 1-minute log alert previews for legacy rules.
+- [PowerShell cmdlets](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell) and [Azure CLI](./alerts-log.md#manage-log-alerts-using-cli) support for switched rules.
+- Alignment of severities with all other alert types and newer rules.
+- Ability to create [cross workspace log alert](../logs/cross-workspace-query.md) that span several external resources like Log Analytics workspaces or Application Insights resources for switched rules.
+- Users can specify dimensions to split the alerts for switched rules.
+- Log alerts have extended period of up to two days of data (previously limited to one day) for switched rules.
 
 ## Impact
 
-- All new rules must be created/edited with the current API. See [sample use via Azure Resource Template](alerts-log-create-templates.md) and [sample use via PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell).
+- All switched rules must be created/edited with the current API. See [sample use via Azure Resource Template](alerts-log-create-templates.md) and [sample use via PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell).
 - As rules become Azure Resource Manager tracked resources in the current API and must be unique, rules resource ID will change to this structure: `<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>`. Display names of the alert rule will remain unchanged.
 
 ## Process

articles/azure-monitor/alerts/alerts-log.md

@@ -4,7 +4,7 @@ description: Use Azure Monitor to create, view, and manage log alert rules
 author: AbbyMSFT
 ms.author: abbyweisberg
 ms.topic: conceptual
-ms.date: 12/14/2021
+ms.date: 01/25/2022
 ms.custom: devx-track-azurepowershell, devx-track-azurecli
 ---
 # Create, view, and manage log alerts using Azure Monitor
@@ -26,7 +26,6 @@ You can also [create log alert rules using Azure Resource Manager templates](../
 > This article describes creating alert rules using the new alert rule wizard. Please note these changes in the new alert rule experience:
 > - Search results are not included with the triggered alert and its associated notifications. The alert contains a link to the search results in Logs.
 > - The new alert rule wizard does not include the option to customize the triggered alert's email or to include a custom JSON payload.
-> - The new alert rule wizard does not currently support a frequency of 1 minute. 1 minute alert frequency will be supported soon.
 
 1. In the [portal](https://portal.azure.com/), select the relevant resource.
 1. In the Resource menu, under **Monitoring**, select **Alerts**.

articles/azure-monitor/alerts/alerts-troubleshoot-log.md

@@ -4,7 +4,7 @@ description: Common issues, errors, and resolutions for log alert rules in Azure
 author: yanivlavi
 ms.author: yalavi
 ms.topic: conceptual
-ms.date: 12/08/2021 
+ms.date: 01/25/2022
 ms.custom: devx-track-azurepowershell
 
 ---
@@ -27,19 +27,11 @@ Logs are semi-structured data and are inherently more latent than metrics. If yo
 
 To mitigate latency, the system retries the alert evaluation multiple times. After the data arrives, the alert fires, which in most cases don't equal the log record time.
 
-### Incorrect query time range configured
+### Actions are muted or alert rule is defined to resolve automatically
 
-Query time range is set in the rule condition definition. For workspaces and Application Insights, this field is called **Period**. For all other resource types, it's called **Override query time range**. Like in log analytics, the time range limits query data to the specified period. Even if the **ago** command is used in the query, the time range will apply. 
+Log alerts provide an option to mute fired alert actions for a set amount of time using **Mute actions** and to only fire once per condition being met using **Automatically resolve alerts**. 
 
-For example, a query scans 60 minutes when the time range is 60 minutes, even if the text contains **ago(1d)**. The time range and query time filtering need to match. In the example case, changing the **Period** / **Override query time range** to one day, works as expected.
-
-![Time period](media/alerts-troubleshoot-log/LogAlertTimePeriod.png)
-
-### Actions are muted in the alert rule
-
-Log alerts provide an option to mute fired alert actions for a set amount of time. In workspaces and Application Insights, this field is called **Suppress alerts**. In all other resource types, it's called **Mute actions**. 
-
-A common issue is that you think that the alert didn't fire the actions because of a service issue, even though it was muted by the rule configuration.
+A common issue is that you think that the alert didn't fire, but it was actually the rule configuration.
 
 ![Suppress alerts](media/alerts-troubleshoot-log/LogAlertSuppress.png)
 
@@ -67,31 +59,6 @@ Log alerts work best when you try to detect data in the logs. It works less well
 
 There are built-in capabilities to prevent false alerts, but they can still occur on very latent data (over ~30 minutes) and data with latency spikes.
 
-### Query optimization issues
-
-The alerting service changes your query to optimize for lower load and alert latency. The alert flow was built to transform the results that indicate the issue to an alert. For example, in a case of a query like:
-
-``` Kusto
-SecurityEvent
-| where EventID == 4624
-```
-
-If the intent of the user is to alert, when this event type happens, the alerting logic appends `count` to the query. The query that will run is:
-
-``` Kusto
-SecurityEvent
-| where EventID == 4624
-| count
-```
-
-There's no need to add alerting logic to the query, and doing that may even cause issues. In the preceding example, if you include `count` in your query, it always results in the value **1**, because the alert service performs a `count` of `count`.
-
-The log alert service runs the optimized query. You can run the modified query in the Log Analytics [portal](../logs/log-query-overview.md) or [API](/rest/api/loganalytics/).
-
-For workspaces and Application Insights, it's called **Query to be executed** in the Condition pane. In all other resource types, select **See final alert Query** on the **Condition** tab.
-
-![Query to be executed](media/alerts-troubleshoot-log/LogAlertPreview.png)
-
 ## Log alert was disabled
 
 The following sections list some reasons why Azure Monitor might disable a log alert rule. After those section, there's an [example of the activity log that is sent when a rule is disabled](#activity-log-example-when-rule-is-disabled).
@@ -137,7 +104,7 @@ If you've reached the quota limit, the following steps might help resolve the is
 
 #### From the Azure portal
 
-1. On the Alerts screen, select **Manage alert rules**.
+1. On the Alerts screen in Azure Monitor, select **Alert rules**.
 1. In the **Subscription** dropdown control, filter to the subscription you want. (Make sure you don't filter to a specific resource group, resource type, or resource.)
 1. In the **Signal type** dropdown control, select **Log Search**.
 1. Verify that the **Status** dropdown control is set to **Enabled**.
@@ -147,7 +114,8 @@ The total number of log search alert rules is displayed above the rules list.
 #### From API
 
 - PowerShell - [Get-AzScheduledQueryRule](/powershell/module/az.monitor/get-azscheduledqueryrule)
-- REST API - [List by subscription](/rest/api/monitor/scheduledqueryrule-2021-02-01-preview/scheduled-query-rules/list-by-subscription)
+- CLI: [az monitor scheduled-query list](/cli/azure/monitor/scheduled-query#az-monitor-scheduled-query-list)
+- REST API - [List by subscription](/rest/api/monitor/scheduledqueryrule-2021-08-01/scheduled-query-rules/list-by-subscription)
 
 ## Activity log example when rule is disabled