Créer ou modifier une règle d’alerte de recherche dans les journaux

Cet article vous montre comment créer une règle d’alerte de recherche dans les journaux, ou modifier une règle d’alerte de recherche dans les journaux existante dans Azure Monitor. Pour en savoir plus sur les alertes, consultez la vue d’ensemble des alertes.

Les règles d’alerte combinent les ressources devant faire l’objet d’un monitoring, les données de monitoring de la ressource ainsi que les conditions de déclenchement de l’alerte. Vous pouvez ensuite définir des groupes d’actions et des règles de traitement des alertes pour déterminer ce qui se passe quand une alerte est déclenchée.

Les alertes déclenchées par ces règles d’alerte contiennent une charge utile utilisant le schéma d’alerte courant.

Prérequis

Pour créer ou modifier une règle d’alerte, vous devez disposer des autorisations suivantes :

• Autorisation de lecture sur la ressource cible de la règle d'alerte.
• Autorisation d’écriture sur le groupe de ressources dans lequel la règle d’alerte est créée. Si vous créez la règle d’alerte à partir du portail Azure, elle est créée par défaut dans le groupe de ressources dans lequel réside la ressource cible.
• Autorisation de lecture sur tout groupe d'actions associé à la règle d'alerte, le cas échéant).

Accéder à l’Assistant Règle d’alerte dans le portail Azure

Il existe plusieurs façons de créer ou de modifier une règle d’alerte.

Créer ou modifier une règle d’alerte à partir de la page d’accueil du portail

1. Dans le portail Azure, sélectionnez Moniteur.
2. Dans le volet gauche, sélectionnez Alertes.
3. Sélectionnez + Créer>Règle d’alerte.

Créer ou modifier une règle d’alerte à partir d’une ressource spécifique

1. Dans le portail Azure, accédez à la ressource.
2. Dans le volet gauche, sélectionnez Alertes.
3. Sélectionnez + Créer>Règle d’alerte.
4. L’étendue de la règle d’alerte est définie sur la ressource que vous avez sélectionnée. Poursuivez en définissant les conditions de la règle d’alerte.

Modifier une règle d’alerte existante

1. Dans le portail Azure, à partir de la page d’accueil ou d’une ressource spécifique, sélectionnez Alertes dans le volet gauche.

2. Sélectionnez Règles d’alerte.

3. Sélectionnez la règle d’alerte que vous souhaitez modifier, puis sélectionnez Modifier.

   

4. Sélectionnez l’un des onglets de la règle d’alerte pour modifier les paramètres.

Configurer l’étendue de la règle d’alerte

1. Sous le volet Sélectionner une ressource, définissez l’étendue de votre règle d’alerte. Vous pouvez filtrer par abonnement, type de ressource, emplacement de ressource.

   

2. Sélectionnez Appliquer.

Configurer des conditions de règle d’alerte

1. Sous l’onglet Condition, lorsque vous sélectionnez le champ Nom du signal, sélectionnez Recherche de journal personnalisée. Ou sélectionnez Afficher tous les signaux si vous souhaitez choisir un autre signal pour la condition.

2. (Facultatif) Si vous avez sélectionné Afficher tous les signaux lors de l’étape précédente, utilisez le volet Sélectionner un signal pour rechercher le nom du signal ou filtrer la liste des signaux. Filtrer par :

   • Dans Type de signal, sélectionnez Recherche de journal.
   • Source du signal : service qui envoie les signaux Recherche de journal personnalisée et Journal (requête enregistrée). Sélectionnez le nom du signal, puis Appliquer.

3. Dans le volet Journaux, écrivez une requête qui retourne les événements de journal pour lesquels vous souhaitez créer une alerte. Pour utiliser l’une des requêtes de règle d’alerte prédéfinies, développez le volet Schéma et filtre en regard du volet Journaux. Sélectionnez ensuite l’onglet Requêtes , puis sélectionnez l’une des requêtes.

   Sachez que les limitations suivantes s’appliquent aux requêtes de règle d’alerte de recherche dans les journaux :

   • Les requêtes de règle d’alerte de recherche dans les journaux ne prennent pas en charge bag_unpack(), pivot() et narrow().
   • Les requêtes de règle d’alerte de recherche dans les journaux prennent en charge la fonction ago() avec des valeurs temporelles uniquement.
   • AggregatedValue est un mot réservé. Vous ne pouvez pas l’utiliser dans la requête sur des règles d’alerte de recherche dans les journaux.
   • La taille combinée de toutes les données dans les propriétés des règles d’alerte de recherche dans les journaux ne peut pas dépasser 64 Ko.
   • Lorsque vous définissez des fonctions personnalisées dans la requête KQL pour les alertes de recherche dans les journaux, il convient d’être prudent avec le code de fonction qui inclut des clauses temporelles relatives (par exemple, now()). Les fonctions personnalisées avec des clauses temporelles relatives qui ne sont pas définies dans la requête KQL d’alerte de recherche dans les journaux peuvent introduire des incohérences dans les résultats de la requête. Cela peut avoir un impact sur la précision et la fiabilité des évaluations d’alerte. Par conséquent :
     • Pour garantir des alertes précises et opportunes, veillez à toujours définir des clauses temporelles relatives directement dans la requête KQL d’alerte de recherche de journaux.
     • S’il faut des intervalles de temps à l’intérieur de la fonction, ils doivent être passés en tant que paramètres et utilisés dans la fonction.

   

4. (Facultatif) Si vous interrogez un cluster Azure Data Explorer ou Azure Resource Graph, l’espace de travail Log Analytics ne peut pas identifier automatiquement la colonne avec l’horodatage de l’événement. Nous vous recommandons d’ajouter un filtre d’intervalle de temps à la requête. Par exemple :

       adx('https://help.kusto.windows.net/Samples').table    
       | where MyTS >= ago(5m) and MyTS <= now()
   

       arg("").Resources
       | where type =~ 'Microsoft.Compute/virtualMachines'
       | project _ResourceId=tolower(id), tags
   

   

   Des exemples de requêtes d’alerte de recherche dans les journaux sont disponibles pour Azure Data Explorer et Resource Graph.

   Les requêtes interservices ne sont pas prises en charge dans les clouds gouvernementaux. Pour plus d’informations sur les limitations, consultez Limitations des requêtes interservices et Combiner des tables Azure Resource Graph avec un espace de travail Log Analytics.

5. Sélectionnez Exécuter pour exécuter l’alerte.

6. La section Aperçu affiche les résultats de la requête. Lorsque vous avez terminé de modifier votre requête, sélectionnez Poursuivre la modification de l’alerte.

7. L’onglet Condition s’ouvre et affiche votre requête de journal. Par défaut, la règle compte le nombre de résultats au cours des cinq dernières minutes. Si le système détecte des résultats de requête résumés, la règle est automatiquement mise à jour avec ces informations.

8. Dans la section Mesure, sélectionnez les valeurs pour ces champs :

   Champ	Description
   Mesure	Les alertes de recherche dans les journaux peuvent mesurer deux éléments que vous pouvez utiliser pour différents scénarios de surveillance : Lignes de tables : vous pouvez utiliser le nombre de lignes retournées pour utiliser des événements tels que des journaux des événements Windows, Syslog et des exceptions d’application. Calcul d’une colonne numérique : vous pouvez utiliser des calculs basés sur une colonne numérique pour inclure un nombre quelconque de ressources. Par exemple, le pourcentage d’UC.
   Type d’agrégation	Calcul effectué sur plusieurs enregistrements pour les agréger à une valeur numérique à l’aide de la précision d’agrégation. Par exemple, Total, Average, Minimum ou Maximum.
   Granularité d’agrégation	Intervalle d’agrégation de plusieurs enregistrements à une valeur numérique.

   

9. (Facultatif) Dans la section Diviser par dimensions, vous pouvez utiliser des dimensions afin de fournir un contexte pour l’alerte déclenchée.

   Les dimensions sont des colonnes de vos résultats de requête qui contiennent des données supplémentaires. Lorsque vous utilisez des dimensions, la règle d’alerte regroupe les résultats de la requête en fonction des valeurs de dimension, et elle évalue les résultats de chaque groupe séparément. Si la condition est remplie, la règle déclenche une alerte pour ce groupe. La charge utile d’alerte comprend la combinaison qui a déclenché l’alerte.

   Vous pouvez appliquer jusqu’à six dimensions par règle d’alerte. Les dimensions ne peuvent être que des colonnes de chaînes ou des colonnes numériques. Si vous souhaitez utiliser comme dimension une colonne qui n’est pas un type de chaîne ou un type numérique, vous devez la convertir en valeur chaîne ou numérique dans votre requête. Si vous sélectionnez plusieurs valeurs de dimension, chaque série chronologique qui résulte de la combinaison déclenche sa propre alerte et est facturée séparément.

   Par exemple :

   • Vous pourriez par exemple utiliser des dimensions pour superviser l’utilisation du processeur sur plusieurs instances qui exécutent votre site web ou votre application. Chaque instance est supervisée individuellement, et des notifications sont envoyées pour chaque instance où l’utilisation du processeur dépasse la valeur configurée.
   • Vous pourriez décider de ne pas diviser par dimensions quand vous voulez qu’une condition s’applique à plusieurs ressources dans l’étendue. Par exemple, vous n’utiliserez pas de dimension si vous souhaitez déclencher une alerte si au moins cinq machines dans l’étendue du groupe de ressources ont une utilisation du processeur supérieure à la valeur configurée.

   En général, si l’étendue de votre règle d’alerte est un espace de travail, les alertes sont déclenchées sur l’espace de travail. Si vous souhaitez une alerte distincte pour chaque ressource Azure affectée, vous pouvez :

   • Utiliser la colonne Azure Resource Manager ID de ressource Azure en tant que dimension. Lorsque vous utilisez cette option, l’alerte est déclenchée sur l’espace de travail avec la colonne ID de ressource Azure en tant que dimension.

   • Spécifiez l’alerte en tant que dimension dans la propriété ID de ressource Azure. Cette option fait de la ressource retournée par votre requête la cible de l’alerte. Les alertes sont ensuite déclenchées sur la ressource retournée par votre requête, telle qu’une machine virtuelle ou un compte de stockage, plutôt que sur l’espace de travail.

     Lorsque vous utilisez cette option, si l’espace de travail obtient des données à partir de ressources de plusieurs abonnements, des alertes peuvent être déclenchées sur les ressources d’un abonnement différent de l’abonnement de la règle d’alerte.

   Sélectionnez des valeurs pour ces champs :

   Champ	Description
   Nom de la dimension	Les dimensions peuvent être des colonnes numériques ou de type chaîne. Les dimensions servent à superviser des séries chronologiques spécifiques, et fournissent un contexte à une alerte déclenchée.
   Opérateur	Opérateur utilisé sur le nom et la valeur de la dimension.
   Valeurs de dimension	Les valeurs de dimension sont basées sur les données des dernières 48 heures. Sélectionnez Ajouter une valeur personnalisée pour ajouter des valeurs de dimension personnalisées.
   Inclure toutes les valeurs futures	Sélectionnez ce champ pour inclure toutes les valeurs futures ajoutées à la dimension sélectionnée.

   

10. Dans la section Logique d’alerte, sélectionnez des valeurs pour ces champs :

    Champ	Description
    Opérateur	Les résultats de requête sont transformés en nombre. Dans ce champ, sélectionnez l’opérateur à utiliser pour comparer le nombre au seuil.
    Valeur du seuil	Valeur numérique pour le seuil.
    Fréquence d’évaluation	Fréquence d’exécution de la requête. Vous pouvez affecter toute valeur comprise entre une minute et un journée (24 heures).

    

    Remarque

    La fréquence n’est pas une heure spécifique à laquelle l’alerte s’exécute tous les jours. Il s’agit de la fréquence d’exécution de la règle d’alerte.

    Il existe certaines limitations relatives à l’utilisation d’une fréquence de règle d’alerte d’une minute. 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. Les raisons les plus courantes pour lesquelles une requête n’est pas prise en charge sont les suivantes :

    • La requête contient l’opération search, union ou take (limite).
    • La requête contient la fonction ingestion_time().
    • La requête utilise le modèle adx.
    • La requête appelle une fonction qui appelle d’autres tables.

    Des exemples de requêtes d’alerte de recherche dans les journaux sont disponibles pour Azure Data Explorer et Resource Graph.

11. (Facultatif) Dans la section Options avancées, vous pouvez spécifier le nombre d’échecs et la période d’évaluation de l’alerte requise pour déclencher une alerte. Par exemple, si vous définissez la précision d’agrégation sur cinq minutes, vous pouvez spécifier que vous souhaitez déclencher une alerte uniquement si trois échecs (15 minutes) ont eu lieu au cours de la dernière heure. La stratégie métier de votre application détermine ce paramètre.

    Sélectionnez des valeurs pour ces champs sous Nombre de violations pour déclencher l’alerte :

    Champ	Description
    Nombre de violations	Nombre de violations à partir duquel déclencher l’alerte.
    Période d’évaluation	Période pendant laquelle les violations dénombrées se produisent.
    Remplacer l’intervalle de temps de requête	Si vous souhaitez que la période d’évaluation de l’alerte diffère de l’intervalle de temps de la requête, entrez un intervalle de temps ici. L’intervalle de temps d’alerte est limité à un maximum de deux jours. Même si la requête contient une commande ago avec un intervalle de temps supérieur à deux jours, l’intervalle de temps maximal de deux jours est appliqué. Par exemple, même si le texte de la requête contient ago(7d), la requête analyse uniquement jusqu’à deux jours de données. Si la requête nécessite plus de données que l’évaluation de l’alerte, vous pouvez changer l’intervalle de temps manuellement. Si la requête contient une commande ago, elle est automatiquement remplacée par une commande spécifiant deux jours (48 heures).

    

    Remarque

    Si votre administrateur ou vous-même avez affecté la stratégie Azure Les alertes de recherche dans les journaux Azure sur les espaces de travail Log Analytics doivent utiliser des clés gérées par le client, vous devez sélectionner l’option Vérifier le stockage lié à l’espace de travail. Si ce n’est pas le cas, la création de la règle échoue, car elle ne répond pas aux exigences de la stratégie.

12. Le graphique Aperçu affiche les résultats des évaluations de requête dans le temps. Vous pouvez modifier la période du graphique ou sélectionner différentes séries chronologiques résultant du fractionnement des alertes par dimensions.

    

13. Cliquez sur Terminé. Une fois que vous avez configuré les conditions de la règle d’alerte, vous pouvez configurer les détails de la règle d’alerte pour terminer la création de l’alerte. Vous pouvez également ajouter des actions et des balises à la règle d’alerte si vous le souhaitez.

Configurer les actions d’une règle d’alerte

Sous l’onglet Actions, vous pouvez éventuellement sélectionner ou créer des groupes d’actions pour votre règle d’alerte.

Configurer les détails d’une règle d’alerte

1. Sous l’onglet Détails, sous Détails du projet, sélectionnez les valeurs Abonnement et Groupe de ressources.

2. Sous Détails de la règle d’alerte :

   1. Sélectionnez la valeur Gravité.

   2. Entrez des valeurs pour Nom de la règle d’alerte et Description de la règle d’alerte.

      Remarque

      Une règle qui utilise une identité ne peut pas contenir de point-virgule (;) dans la valeur Nom de la règle d’alerte.

   3. Sélectionnez la valeur Région.

3. Dans la section Identité, sélectionnez l’identité utilisée par la règle d’alerte de recherche dans les journaux lors de l’envoi de la requête de journal.

   Gardez ces points à l’esprit lors de la sélection d’une identité :

   • Une identité managée est nécessaire si vous envoyez une requête à Azure Data Explorer ou à Resource Graph.
   • Utilisez une identité managée si vous voulez être en mesure de voir ou de modifier les autorisations associées à la règle d’alerte.
   • Si vous n’utilisez pas d’identité managée, les autorisations de la règle d’alerte sont basées sur les autorisations du dernier utilisateur ayant modifié la règle, au moment de la dernière modification de la règle.
   • Utilisez une identité managée pour éviter un cas où la règle ne fonctionne pas comme prévu, car l’utilisateur qui a modifié la règle pour la dernière fois n’avait pas d’autorisations pour toutes les ressources ajoutées à l’étendue de la règle.

   L’identité associée à la règle doit avoir ces rôles :

   • Si la requête accède à un espace de travail Log Analytics, un rôle de lecteur doit être attribué à l’identité pour tous les espaces de travail auxquels la requête accède. Si vous créez des alertes de recherche dans les journaux centrées sur les ressources, ces règles d’alerte peuvent accéder à plusieurs espaces de travail, et l’identité doit avoir un rôle de lecteur sur chacun d’eux.
   • Si vous interrogez un cluster Azure Data Explorer ou Resource Graph, vous devez ajouter le rôle de lecteur pour toutes les sources de données auxquelles la requête accède. Par exemple, si la requête est centrée sur les ressources, elle a besoin d’un rôle de lecteur sur ces ressources.
   • Si la requête accède à un cluster Azure Data Explorer distant, les rôles suivants doivent être attribués à l’identité :
     • Un rôle de lecteur pour toutes les sources de données auxquelles la requête accède. Par exemple, si la requête appelle un cluster Azure Data Explorer distant en utilisant la fonction adx(), elle a besoin d’un rôle de lecteur sur ce cluster Azure Data Explorer.
     • Un rôle d’observateur de base de données pour toutes les bases de données auxquelles la requête accède.

   Pour plus d’informations sur les identités managées, consultez Identités managées pour les ressources Azure.

   Sélectionnez l’une des options suivantes pour l’identité utilisée par la règle d’alerte :

   Option d’identité	Description
   Aucun	Les autorisations de règle d’alerte sont basées sur les autorisations du dernier utilisateur qui a modifié la règle, au moment où la règle a été modifiée.
   Activer l’identité managée affectée par le système	Azure crée une identité dédiée pour cette règle d’alerte. Cette identité ne dispose d’aucune autorisation et est supprimée automatiquement quand la règle est supprimée. Après avoir créé la règle, vous devez attribuer des autorisations à cette identité pour accéder à l’espace de travail et aux sources de données nécessaires pour la requête. Pour plus d’informations sur l’attribution de rôle, consultez Attribuer des rôles Azure en utilisant le portail Azure. Les règles d’alerte de recherche dans les journaux qui utilisent le stockage lié ne sont pas prises en charge.
   Activer l’identité managée affectée par l’utilisateur	Avant de créer la règle d’alerte, vous créez une identité et vous lui attribuez les autorisations appropriées pour la requête de journal. C’est une identité Azure standard. Vous pouvez utiliser une même identité dans plusieurs règles d’alerte. L’identité n’est pas supprimée quand la règle est supprimée. Quand vous sélectionnez ce type d’identité, un volet s’ouvre pour vous permettre de sélectionner l’identité associée pour la règle.

   

4. (Facultatif) Dans la section Options avancées, vous pouvez définir plusieurs options :

   Champ	Description
   Activer à la création	Sélectionnez cette option pour que la règle d’alerte commence à s’exécuter dès que vous avez terminé de la créer.
   Résoudre automatiquement les alertes	Sélectionnez cette option pour changer l’alerte en alerte avec état. Quand une alerte est avec état, l’alerte est résolue si la condition n’est plus remplie pendant un intervalle de temps spécifique. L’intervalle de temps diffère en fonction de la fréquence de l’alerte : 1 minute : la condition d’alerte n’est pas remplie pendant 10 minutes. 5 à 15 minutes : la condition d’alerte n’est pas remplie pendant trois périodes de fréquence. 15 minutes à 11 heures : la condition d’alerte n’est pas remplie pendant deux périodes de fréquence. 11 à 12 heures : la condition d’alerte n’est pas remplie pendant trois périodes de fréquence. Notez que les alertes de recherche dans les journaux avec état présentent ces limitations.
   Désactiver les actions	Sélectionnez cette option pour définir un délai d’attente avant le redéclenchement des actions d’alerte. Dans le champ Désactiver les actions pendant qui s’affiche, sélectionnez le délai d’attente, après le déclenchement d’une alerte, avant de déclencher à nouveau des actions.
   Vérifier le stockage lié à l’espace de travail	Sélectionnez cette option si le stockage lié à l’espace de travail pour les alertes est configuré. Si aucun stockage lié n’est configuré, la règle n’est pas créée.

5. (Facultatif) Dans la section Propriétés personnalisées, si cette règle d’alerte contient des groupes d’actions, vous pouvez ajouter vos propres propriétés à inclure dans la charge utile de notification d’alerte. Vous pouvez utiliser ces propriétés dans les actions appelées par le groupe d’actions, par exemple un webhook, une fonction Azure ou une action d’application logique.

   Les propriétés personnalisées sont spécifiées sous forme de paires clé/valeur à l’aide de texte statique, d’une valeur dynamique extraite de la charge utile d’alerte, ou d’une combinaison des deux.

   Le format pour l’extraction d’une valeur dynamique à partir de la charge utile d’alerte est le suivant : ${<path to schema field>}. Par exemple : ${data.essentials.monitorCondition}.

   Utilisez le format du schéma d’alerte commun pour spécifier le champ dans la charge utile, que les groupes d’actions configurés pour la règle d’alerte utilisent ou non le schéma commun.

   Remarque

   • Les propriétés personnalisées sont ajoutées à la charge utile de l’alerte, mais elles n’apparaissent pas dans le modèle d’e-mail ni dans les détails de l’alerte dans le portail Azure.

   

   Dans les exemples suivants, les valeurs des Propriétés personnalisées servent à utiliser des données d’une charge utile qui utilise le schéma d’alerte commun.

   Cet exemple crée une étiquette Détails supplémentaires avec des données concernant l’heure de début de la fenêtre et l’heure de fin de la fenêtre :

   • Nom : Additional Details
   • Valeur: Evaluation windowStartTime: ${data.alertContext.condition.windowStartTime}. windowEndTime: ${data.alertContext.condition.windowEndTime}
   • Résultat : AdditionalDetails:Evaluation windowStartTime: 2023-04-04T14:39:24.492Z. windowEndTime: 2023-04-04T14:44:24.492Z

   Cet exemple ajoute des données concernant la raison de la résolution ou du déclenchement de l’alerte :

   • Nom : Alert ${data.essentials.monitorCondition} reason
   • Valeur: ${data.alertContext.condition.allOf[0].metricName} ${data.alertContext.condition.allOf[0].operator} ${data.alertContext.condition.allOf[0].threshold} ${data.essentials.monitorCondition}. The value is ${data.alertContext.condition.allOf[0].metricValue}
   • Résultats potentiels :
     • Alert Resolved reason: Percentage CPU GreaterThan5 Resolved. The value is 3.585
     • Alert Fired reason": "Percentage CPU GreaterThan5 Fired. The value is 10.585

Configurer des étiquettes de règle d’alerte

Sous l’onglet Balises, vous pouvez éventuellement définir les balises requises sur la ressource de règle d’alerte.

Passer en revue et créer la règle d’alerte

1. Sous l’onglet Vérifier + créer, la règle est validée. En cas de problème, revenez en arrière et corrigez.

2. Lorsque la validation réussit et que vous avez examiné les paramètres, sélectionnez le bouton Créer.

   

Contenu connexe

• Obtenir des exemples de requêtes d’alerte de recherche dans les journaux
• Afficher et gérer les instances d’alerte