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

Article
02/28/2024

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

Pour créer une règle d’alerte, vous combinez les ressources à monitorer, les données de monitoring de la ressource et les conditions à remplir pour déclencher 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.

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

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

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

Dans le portail, sélectionnez Surveiller>Alertes.
Ouvrez le menu + Créer et sélectionnez Règle d’alerte.

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

Dans le portail, accédez à la ressource.
Sélectionnez Alertes dans le volet gauche, puis + Créer une>règle d’alerte.

Modifier une règle d’alerte existante

Dans le portail, à partir de la page d’accueil ou d’une ressource spécifique, sélectionnez Alertes dans le volet gauche.
Sélectionnez Règles d’alerte.
Sélectionnez la règle d’alerte que vous souhaitez modifier, puis sélectionnez Modifier.
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

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.
Sélectionnez Appliquer.

Définir les conditions de la règle d’alerte

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.
(Facultatif) Si vous avez choisi 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 et Appliquer.
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 une des requêtes de règle d’alerte prédéfinies, développez le volet Schéma et filtre à gauche du volet Journaux. Sélectionnez ensuite l’onglet Requêtes , puis sélectionnez l’une des requêtes.

Limitations des 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 les plug-ins 'bag_unpack()', 'pivot()' et 'narrow()'.
Le mot « AggregatedValue » est un mot réservé, il ne peut pas être utilisé dans la requête sur les règles des alertes de recherche dans les journaux.
La taille combinée de toutes les données dans les propriétés d’une règle d’alerte de journal ne peut pas dépasser 64 Ko.

(Facultatif) Si vous interrogez un cluster ADX ou ARG, Log Analytics ne peut pas identifier automatiquement la colonne avec l’horodatage d’é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
```
Pour des exemples de requêtes d’alerte de recherche dans les journaux qui interrogent ARG ou ADX, consultez Exemples de requêtes d’alerte de recherche dans les journaux.

Voici les limitations relatives à l’utilisation de requêtes croisées :
- Limitations de requêtes inter-services
- Combiner des tables Azure Resource Graph avec un espace de travail Log Analytics
- Non pris en charge dans les clouds gouvernementaux
Sélectionnez Exécuter pour exécuter l’alerte.
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.
L’onglet Condition s’ouvre, affichant 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.

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

Capture d'écran illustrant l'onglet Mesures lors de la création d'une nouvelle règle d'alerte au niveau de la recherche dans les journaux.

Champ	Description
Mesure	Les alertes de recherche dans les journaux peuvent mesurer deux éléments différents, qui peuvent être utilisés pour différents scénarios d’analyse : Lignes de table : le nombre de lignes retournées peut être utilisé pour travailler avec des événements comme des exceptions d’application, des journaux des événements Windows et Syslog. Calcul d’une colonne numérique : des calculs basés sur une colonne numérique peuvent être utilisés 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.
Précision d'agrégation	Intervalle d’agrégation de plusieurs enregistrements à une valeur numérique.

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

Capture d'écran illustrant la section de Fractionnement par dimensions d'une nouvelle règle d'alerte au niveau de la recherche dans les journaux.

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 exécutant 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.

Sélectionnez des valeurs pour ces champs :

Colonne ID de ressource : 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 voulez une alerte distincte pour chaque ressource Azure affectée, vous pouvez :
- Utilisez la colonne ID de ressource Azure ARM pour la dimension (notez qu’en utilisant cette option, l’alerte est déclenchée sur l’espace de travail avec la colonne ID de ressource Azure comme dimension.
- La spécifier en tant que dimension dans la propriété ID de ressource Azure, ce qui fait de la ressource retournée par votre requête la cible de l’alerte. Les alertes sont donc déclenchées sur la ressource retournée par votre requête, par exemple une machine virtuelle ou un compte de stockage, plutôt que dans 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.

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.

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

Capture d'écran illustrant la section Logique d'alerte d'une nouvelle règle d'alerte au niveau de la recherche dans les journaux.

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. Peut être défini n’importe où d’une minute à un jour (24 heures).

Remarque

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. Voici les raisons les plus courantes pour lesquelles une requête n’est pas prise en charge :

La requête contient les opérations 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

Pour des exemples de requêtes d’alerte de recherche dans les journaux qui interrogent ARG ou ADX, consultez Exemples de requêtes d’alerte de recherche dans les journaux

(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 5 minutes, vous pouvez spécifier que vous souhaitez uniquement déclencher une alerte si trois échecs ont eu lieu (15 minutes) au cours de la dernière heure. La stratégie métier de votre application détermine ce paramètre.

Capture d'écran illustrant la section Options avancées d'une nouvelle règle d'alerte au niveau de la recherche dans les journaux.

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 sera automatiquement remplacée par une commande de 2 jours (48 heures).

Remarque

Si vous, ou votre administrateur, avez attribué la Azure Policy aux espaces de travail Azure Log Search Alerts sur Log Analytics qui 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.

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.
Cliquez sur Terminé. À partir de là, vous pouvez sélectionner le bouton Vérifier + Créer à tout moment.

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

Sous l’onglet Actions, sélectionnez ou créez les groupes d’actions requis.

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

Sous l’onglet Détails, définissez les Détails du projet.
- Sélectionnez l’abonnement.
- Sélectionnez le groupe de ressources.

Définissez les Détails de la règle d’alerte.

Capture d'écran de l'onglet Détails lors de la création d'une nouvelle règle d'alerte au niveau de la recherche dans les journaux.

Sélectionnez la Gravité.
Entrez des valeurs pour le Nom de la règle d’alerte et la Description de la règle d’alerte.

Remarque

Notez que la règle qui utilise Identity ne peut pas contenir le caractère « ; » dans le nom de la règle d’alerte
Sélectionnez la Région.

Dans la section Identité, sélectionnez l’identité utilisée par la règle d’alerte de recherche dans les journaux pour envoyer la requête de journal. Cette identité est utilisée pour l’authentification quand la règle d’alerte exécute la requête de journal.

Gardez ces éléments à 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 (ADX) ou Azure Resource Graph (ARG).
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 qui modifie 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 ADX ou ARG, vous devez ajouter le rôle Lecteur à toutes les sources de données accessibles par la requête. 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é :
- 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 ADX.
- 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 une des options suivantes pour l’identité utilisée par la règle d’alerte :

Identité	Description
None	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.
Identité gérée attribué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.
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.

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

Champ	Description
Activer à la création	Choisissez de lancer l’exécution de la règle d’alerte dès que vous avez fini de la créer.
Résoudre automatiquement les alertes (préversion)	Sélectionnez 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 trois 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 les limitations suivantes : - Elles peuvent déclencher jusqu’à 300 alertes par évaluation. - Vous pouvez avoir un maximum de 5 000 alertes avec la condition d’alerte `fired`.
Désactiver les actions	Sélectionnez cette option pour définir un délai d’attente avant le redéclenchement des actions d’alerte. Si vous activez cette case à cocher, le champ Désactiver les actions pendant dans lequel sélectionner 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 pour si le stockage lié à l’espace de travail des journaux pour les alertes est configuré. Si aucun stockage lié n’est configuré, la règle n’est pas créée.

(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, notamment un webhook, une fonction Azure ou des actions 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
- Le schéma commun remplace les configurations personnalisées. Vous ne pouvez pas utiliser à la fois des propriétés personnalisées et le schéma commun.
- 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.
- Les alertes Service Health ne prennent pas en charge les propriétés personnalisées.
Dans les exemples suivants, les valeurs des propriétés personnalisées sont utilisées pour utiliser des données d’une charge utile qui utilise le schéma d’alerte commun :

Exemple 1 :

Cet exemple montre comment créer 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 : "Détails supplémentaires"
- Valeur : "Évaluation 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"
Exemple 2 Cet exemple ajoute les données relatives à la raison de la résolution ou du déclenchement de l’alerte.
- Nom : "Raison de l’alerte ${data.essentials.monitorCondition}"
- 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ésultat : Les exemples de résultats peuvent ressembler à ceci :
  - "Raison de l’alerte résolue : Pourcentage processeur supérieur à 5 résolu. La valeur est 3,585"
  - "Raison de l’alerte résolue" : "Pourcentage processeur supérieur à 5 résolu. La valeur est 10,585"

Configurer des étiquettes de règle d’alerte

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

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

Sous l’onglet Vérifier + créer, la règle est validée et vous informe des éventuels problèmes.
Lorsque la validation réussit et que vous avez examiné les paramètres, sélectionnez le bouton Créer.