Passer de l’API Alertes Log Analytics héritée à l’API Règles de requête planifiée

  • Article

Important

Comme annoncé, l’API Alerte Log Analytics sera mise hors service le 1er octobre 2025. Vous devez commencer à utiliser l’API Règles de requête planifiée pour les alertes de recherche dans les journaux avant cette date. Les espaces de travail Log Analytics créés après le 1er juin 2019 utilisent l’API scheduledQueryRules pour gérer les règles d’alerte de recherche dans les journaux. Basculez vers l’API actuelle dans des espaces de travail plus anciens pour tirer parti des avantages scheduledQueryRules d’Azure Monitor. Une fois que vous avez migré les règles vers l’API scheduledQueryRules, vous ne pouvez plus revenir à l’ancienne API d’alerte héritée Log Analytics.

Auparavant, les utilisateurs utilisaient l'API Alerte Log Analytics héritée pour gérer les règles d’alerte de recherche dans les journaux. Actuellement, les espaces de travail utilisent l'API Règles de requête planifiée pour les nouvelles règles. Cet article décrit les avantages et le processus pour basculer la gestion des règles héritées d’alerte de recherche dans les journaux avec l’API héritée vers l’API actuelle.

Avantages

  • Gérer toutes les règles d’alerte de recherche dans les journaux dans une seule API.
  • Modèle unique pour la création de règles d'alerte (auparavant, trois modèles distincts étaient nécessaires).
  • API unique pour toutes les alertes liées aux journaux de ressources Azure.
  • Prise en charge des alertes de recherche dans les journaux avec état (préversion) et d’1 minute.
  • Prise en charge des applets de commande PowerShell et d’Azure CLI pour les règles commutées.
  • Alignement des niveaux de gravité avec tous les autres types d'alertes et les règles plus récentes.
  • Possibilité de créer des alertes de journal inter-espaces de travail couvrant différentes ressources externes, telles que les espaces de travail Log Analytics ou les ressources Application Insights pour les règles commutées.
  • Les utilisateurs peuvent spécifier des dimensions pour fractionner les alertes pour les règles commutées.
  • Les alertes de recherche dans les journaux ont une période étendue à deux jours de données maximum (limitée à un jour auparavant) pour les règles échangées.

Impact

  • Les règles commutées doivent toutes être créées/modifiées avec l'API actuelle. Consultez Exemple d'utilisation via Azure Resource Template et Exemple d'utilisation via PowerShell.
  • Comme les règles deviennent des ressources suivies par Azure Resource Manager dans l'API actuelle et qu'elles doivent être uniques, l’ID de ressource des règles adopte cette structure : <WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>. Les noms d’affichage des règle d’alerte restent inchangés.

Processus

Affichez les espaces de travail à mettre à niveau à l’aide de cette requête de l’explorateur Azure Resource Graph. Ouvrez le lien, sélectionnez tous les abonnements disponibles et exécutez la requête.

Dans la plupart des cas, le processus de basculement n'est pas interactif et ne nécessite pas d'étapes manuelles. Vos règles d'alerte ne sont pas arrêtées ou bloquées, ni pendant ni après le basculement. Passez cet appel pour basculer toutes les règles d’alerte associées à chaque espace de travail Log Analytics :

PUT /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview

Avec un corps de la demande qui contient le code JSON ci-dessous :

{
    "scheduledQueryRulesEnabled" : true
}

Voici un exemple d'utilisation d'ARMClient, un outil de ligne de commande open source qui simplifie l'appel d'API ci-dessus :

$switchJSON = '{"scheduledQueryRulesEnabled": true}'
armclient PUT /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview $switchJSON

Vous pouvez également utiliser l’outil Azure CLI :

az rest --method put --url /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview --body "{\"scheduledQueryRulesEnabled\" : true}"

Si le basculement est un succès, la réponse est :

{
    "version": 2,
    "scheduledQueryRulesEnabled" : true
}

Vérifier l'état du basculement de l'espace de travail

Vous pouvez également utiliser cet appel d'API pour vérifier l'état du basculement :

GET /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview

Vous pouvez aussi utiliser l’outil ​​ARMClient :

armclient GET /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview

Vous pouvez également utiliser l’outil Azure CLI :

az rest --method get --url /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.OperationalInsights/workspaces/<workspaceName>/alertsversion?api-version=2017-04-26-preview

Si l'espace de travail Log Analytics a été basculé vers l'API SchedulerQueryRules, la réponse est :

{
    "version": 2,
    "scheduledQueryRulesEnabled" : true
}

Si l'espace de travail Log Analytics n'a pas été basculé, la réponse est :

{
    "version": 2,
    "scheduledQueryRulesEnabled" : false
}

Étapes suivantes