Résoudre les problèmes liés aux alertes de recherche dans les journaux dans Azure Monitor

Article
10/14/2024

Cet article explique comment résoudre les problèmes courants liés aux alertes de recherche dans les journaux dans Azure Monitor. Il propose également des réponses aux problèmes courants liés à la fonctionnalité et à la configuration des alertes de journal.

Vous pouvez utiliser les alertes de journal pour évaluer les journaux de ressources à une fréquence définie en utilisant une requête Log Analytics et déclencher une alerte basée sur les résultats. Les règles peuvent déclencher une ou plusieurs actions à l’aide des groupes d’actions. Pour en savoir plus sur les fonctionnalités et la terminologie des alertes de recherche dans les journaux, consultez Alertes de journal dans Azure Monitor.

Remarque

Cet article ne traite pas des cas où une règle d’alerte qui a été déclenchée et que vous pouvez voir dans le portail Azure n’envoie pas de notification. Pour des cas comme celui-ci, consultez la résolution des problèmes liés aux alertes.

Une alerte de recherche dans les journaux ne s’est pas déclenchée alors que cela aurait dû être le cas

Si votre alerte de recherche dans les journaux ne s’est pas déclenchée alors que cela aurait dû être le cas, vérifiez les points suivants :

La règle d’alerte est-elle dans un état d’intégrité détérioré ou indisponible ?

Examinez l’état d’intégrité de votre règle d’alerte de recherche dans les journaux :
1. Dans le portail, sélectionnez Surveiller, puis Alertes.
2. Dans la barre de commandes supérieure, sélectionnez Règles d'alerte. La page affiche toutes vos règles d’alerte dans tous les abonnements.
3. Sélectionnez la règle d'alerte de recherche de journal que vous souhaitez surveiller.
4. Dans le volet gauche, sous Aide, sélectionnez Santé des ressources.
Pour en savoir plus, consultez Surveiller l’intégrité des règles d’alerte de recherches dans les journaux.
Vérifiez la latence d’ingestion des journaux.

Azure Monitor traite des téraoctets de journaux de clients du monde entier, ce qui peut entraîner une latence dans l’ingestion des journaux.

Les journaux sont des données semi-structurées et ont, par nature, une latence plus importante que les métriques. Si vous constatez un retard de plus de quatre minutes dans les alertes déclenchées, vous devez envisager d’utiliser des alertes de métrique. Vous pouvez envoyer des données au magasin de métriques à partir de journaux à l’aide d’alertes de métrique pour les journaux.

Pour atténuer la latence, le système réitère l’évaluation de l’alerte plusieurs fois. Une fois les données reçues, l’alerte se déclenche, ce qui, dans la plupart des cas, ne correspond pas à l’heure d’enregistrement dans le journal.
Les actions sont-elles désactivées ou la règle d’alerte a-t-elle été configurée pour être résolue automatiquement ?

Un problème courant est de croire que l’alerte n’a pas été déclenchée, alors que la règle est configurée pour que l’alerte ne se déclenche pas. Consultez les options avancées de la règle d’alerte de recherche dans les journaux pour vérifier que les deux éléments suivants ne sont pas sélectionnés :
- Case à cocher Désactiver les actions : permet de désactiver les actions d’alerte déclenchées pendant une durée définie.
- Résoudre automatiquement les alertes : configure l’alerte pour qu’elle ne se déclenche qu’une seule fois par condition remplie.
La ressource de règle d’alerte a-t-elle été déplacée ou supprimée ?

Si une ressource de règle d’alerte cible est déplacée, renommée ou supprimée, toutes les règles d’alerte de journal qui font référence à cette ressource sont arrêtées. Pour résoudre ce problème, vous devez recréer les règles d’alerte à l’aide d’une ressource cible valide pour l’étendue.
La règle d’alerte utilise-t-elle une identité managée affectée par le système ?

Lorsque vous créez une règle d’alerte de journal avec une identité managée affectée par le système, l’identité est créée sans aucune autorisation. Après avoir créé la règle, vous devez attribuer les rôles appropriés à l’identité de la règle afin qu’elle puisse accéder aux données que vous souhaitez interroger. Par exemple, vous devrez peut-être lui attribuer un rôle Lecteur pour les espaces de travail Log Analytics appropriés, ou un rôle Lecteur et un rôle Visionneuse de base de données pour le cluster ADX approprié. Pour plus d’informations sur l’utilisation des identités managées dans les alertes de journal, consultez Identités managées.
La requête utilisée dans la règle d’alerte de recherche dans les journaux est-elle valide ?

Lorsqu’une règle d’alerte de journal est créée, la bonne syntaxe de la requête est vérifiée. Cependant, la requête fournie dans la règle d’alerte de journal peut parfois commencer à échouer. Voici quelques raisons courantes :
- Les règles ont été créées via l’API, et l’utilisateur a ignoré la validation.
- La requête s’exécute sur plusieurs ressources, et une ou plusieurs des ressources ont été supprimées ou déplacées.
- La requête échoue, car :
  - Les données ont cessé d’alimenter une table de la requête depuis plus de 30 jours.
  - Les tables de journaux personnalisés n’ont pas été créées, car le flux de données n’a pas démarré.
- Les modifications apportées au langage de requête incluent une révision du format des commandes et des fonctions, de sorte que la requête fournie précédemment n’est plus valide.
Azure Resource Health surveille l’état de vos ressources cloud, y compris les règles d’alerte de recherche de journaux. Lorsqu'une règle d'alerte de recherche de journal est saine, la règle s'exécute et la requête s'exécute correctement. Vous pouvez utiliser l’intégrité des ressources pour les règles d’alerte de Recherche dans les journaux pour découvrir les problèmes affectant vos règles d’alerte de Recherche dans les journaux.
La règle d’alerte de recherche dans les journaux a-t-elle été désactivée ?

Si une requête de règle d’alerte de recherche dans les journaux ne parvient pas à être évaluée en continu pendant une semaine, Azure Monitor la désactive automatiquement.

Vous trouverez également un exemple de l’événement Journal d’activité qui est soumis lorsqu’une règle est désactivée.

Exemple de journal d’activité lorsque la règle est désactivée

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

Une alerte de recherche dans les journaux s’est déclenchée alors que cela n’aurait pas dû être le cas

Une règle d’alerte de journal dans Azure Monitor configurée peut être déclenchée de façon inattendue. Les sections suivantes décrivent certaines raisons courantes.

L’alerte a-t-elle été déclenchée en raison de problèmes de latence ?

Azure Monitor traite des téraoctets de journaux de clients dans le monde entier, ce qui peut entraîner une latence dans l’ingestion des journaux. Il existe des capacités intégrées pour prévenir les fausses alertes, mais elles peuvent toujours se produire sur des données très latentes (plus de 30 minutes) et des données avec des pics de latence.

Les journaux sont des données semi-structurées et ont, par nature, une latence plus importante que les métriques. Si vous constatez de nombreux déclenchements par erreur dans les alertes déclenchées, songez à utiliser des alertes de métrique. Vous pouvez envoyer des données au magasin de métriques à partir de journaux à l’aide d’alertes de métrique pour les journaux.

Les alertes de recherche dans les journaux fonctionnent de manière optimale quand vous essayez de détecter des données spécifiques dans les journaux. Elles sont moins efficaces quand vous essayez de détecter l’absence de données dans les journaux, comme les alertes sur les pulsations de machines virtuelles.

Messages d’erreur lors de la configuration des règles d’alerte de recherche dans les journaux

Les sections suivantes répertorient des messages d’erreur spécifiques et leurs résolutions.

Impossible de valider la requête, car vous avez besoin d’une autorisation pour les journaux

Si vous recevez ce message d’erreur lors de la création ou de la modification de votre requête de règle d’alerte, vérifiez que vous disposez des autorisations nécessaires pour lire les journaux de ressources cibles.

Autorisations requises pour lire les journaux avec le mode d’accès en fonction du contexte de l’espace de travail : Microsoft.OperationalInsights/workspaces/query/read.
Autorisations requises pour lire les journaux avec le mode d’accès en fonction du contexte des ressources (y compris la ressource Application Insights basée sur l’espace de travail) : Microsoft.Insights/logs/tableName/read.

Pour en savoir plus sur les autorisations, consultez Gérer l’accès aux espaces de travail Log Analytics.

La fréquence d’une minute n’est pas prise en charge pour cette requête

L’utilisation d’une fréquence de règle d’alerte d’une minute présente certaines limites. Lorsque vous définissez la fréquence de la règle d’alerte sur une minute, une manipulation interne est effectuée pour optimiser la requête. Cette manipulation peut entraîner l’échec de la requête s’il contient des opérations non prises en charge.

Pour obtenir la liste des scénarios non pris en charge, consultez cette remarque.

Échec de la résolution de l’expression scalaire nommée <>

Ce message d’erreur peut être retourné lorsque vous créez ou modifiez votre requête de règle d’alerte et que :

Vous référencez une colonne qui n’existe pas dans le schéma de table.
Vous référencez une colonne qui n’a pas été utilisée dans une clause de projet précédente de la requête.

Pour atténuer ce problème, vous pouvez ajouter la colonne à la clause de projet précédente ou utiliser l’opérateur columnifexists.

L’API ScheduledQueryRules n’est pas prise en charge pour les alertes OMS en lecture seule

Ce message d’erreur est retourné quand vous tentez de mettre à jour ou de supprimer des règles créées avec la version de l’API héritée à l’aide du portail Azure.

Modifiez ou supprimez la règle par programmation à l’aide de l’API REST Log Analytics.
Recommandé : mettez à niveau vos règles d’alerte de manière à utiliser l’API Règles de requête planifiées (l’API héritée sera prochainement obsolète).

La limite du service de règle d’alerte a été atteinte

Pour plus d’informations sur le nombre de règles d’alerte de Recherche dans les journaux par abonnement et les limites maximales de ressources, consultez Limites du service Azure Monitor. Consultez Vérifier le nombre total de règles d’alerte de journal en cours d’utilisation pour voir le nombre de règles d’alerte de métrique actuellement utilisées. Si vous avez atteint la limite de quota, les étapes suivantes peuvent vous aider à résoudre le problème.

Supprimez ou désactivez les règles d’alerte de recherche dans les journaux qui ne sont plus utilisées.
Utilisez le fractionnement par dimensions pour réduire le nombre de règles. Lorsque vous utilisez le fractionnement par dimensions, une règle peut surveiller plusieurs ressources.
Si vous avez besoin d’augmenter la limite de quota, continuez pour ouvrir une demande de support et fournissez les informations suivantes :
- Les ID d’abonnement et les ID de ressource pour lesquels la limite de quota doit être augmentée
- La raison de l’augmentation du quota
- La limite de quota demandée

Temps de filtrage incomplet dans des requêtes ARG et ADX

Lorsque vous utilisez Azure Data Explorer (ADX) ou Azure Resource Graph (ARG) dans des alertes de recherche dans les journaux, il est possible que vous rencontriez un problème d’absence d’application par le paramètre « Granularité d’agrégation » d’un filtre de temps à vos requêtes. Cela peut entraîner des résultats inattendus ou des éventuels problèmes de performances, car la requête renvoie les 30 jours au lieu de l’intervalle de temps prévu.

Pour résoudre ce problème, vous devez explicitement appliquer des filtres de temps dans vos requêtes ARG et ADX. Voici les étapes pour veiller à ce qui suit :

Filtrage de temps correct : identifier l’intervalle de temps : déterminez l’intervalle de temps spécifique que vous souhaitez interroger. Par exemple, si vous souhaitez interroger les données des dernières 24 heures, vous devez spécifier cet intervalle de temps dans votre requête.
Modifier la requête : ajoutez un filtre de temps à votre requête ARG ou ADX pour limiter les données renvoyées à l’intervalle de temps souhaité. Voici un exemple de modification de votre requête :

    // Original query without time filter
    resources
    | where type == "microsoft.compute/virtualmachines"

    // Modified query with time filter
    resources
    | where type == "microsoft.compute/virtualmachines"
    | where timestamp >= ago(24h)

Test de la requête : exécutez la requête modifiée pour vérifier qu’elle renvoie les résultats attendus dans l’intervalle de temps spécifié.
Mise à jour des alertes : mettez à jour vos alertes de recherche dans les journaux pour utiliser la requête modifiée avec le filtre de temps explicite. Cette opération veille à ce que vos alertes soient basées sur les données appropriées et qu’elles n’incluent pas des données historiques inutiles. L’application de filtres de temps explicites dans vos requêtes ARG et ADX vous permet d’éviter le problème de récupération de données excessives et de veiller à ce que vos alertes de recherche dans les journaux soient efficaces et exactes.

Étapes suivantes

En savoir plus sur les alertes de journal dans Azure.
En savoir plus sur la configuration des alertes de journal.
Découvrez plus en détail les requêtes dans les journaux.

Partager via