Résolution des problèmes relatifs aux alertes Azure Monitor
Cet article décrit les problèmes courants liés aux alertes et notifications Azure Monitor. Les alertes Azure Monitor vous avertissent de façon proactive lorsque des conditions significatives sont détectées dans vos données de surveillance.
Pour plus d’informations sur la résolution des alertes de métrique ou de recherche dans les journaux Azure, consultez :
- Résoudre des problèmes liés aux alertes de métrique Azure Monitor
- Résoudre les problèmes liés aux alertes de recherche dans les journaux Azure Monitor
Avant la résolution des problèmes
Si l’alerte se déclenche comme prévu, mais que les notifications appropriées ne s’exécutent pas comme prévu, testez d’abord votre groupe d’actions pour vous assurer qu’il est correctement configuré.
Sinon, utilisez les informations contenues dans le reste de cet article pour résoudre votre problème.
Je n’ai pas reçu l’e-mail attendu
Si vous pouvez voir une alerte déclenchée dans le portail Azure, mais que vous n’avez pas reçu l’e-mail que vous avez configuré, suivez ces étapes :
L’e-mail a-t-il été supprimé par une règle de traitement des alertes ?
Vérifiez en cliquant sur l’alerte déclenchée dans le portail, puis examinez l’onglet Historique à la recherche des groupes d’actions supprimés :
Le type d’action est-il « Envoyer un e-mail au rôle Azure Resource Manager » ?
Cette action examine uniquement les attributions de rôle Azure Resource Manager qui se trouvent dans l’étendue de l’abonnement et de type Utilisateur. Assurez-vous que vous avez attribué le rôle au niveau de l’abonnement et non au niveau de la ressource ou du groupe de ressources.
Votre serveur de messagerie et votre boîte aux lettres acceptent-ils les e-mails externes ?
Vérifiez que les e-mails de ces trois adresses ne sont pas bloqués :
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
Souvent les listes de distribution internes ou les listes de diffusion bloquent les e-mails des adresses e-mail externes. Vérifiez que vous autorisez le courrier en provenance des adresses e-mail ci-dessus. À des fins de test, ajoutez une adresse de messagerie professionnelle ordinaire (pas une liste de diffusion) au groupe d’actions et vérifiez si les alertes arrivent à cet e-mail.
L’e-mail a-t-il été traité par des règles de boîte de réception ou un filtre antispam ?
Vérifiez qu’il n’existe pas de règles de boîte de réception qui suppriment ces messages ou les déplacent dans un autre dossier. Par exemple, les règles de boîte de réception peuvent intercepter des expéditeurs spécifiques ou des mots spécifiques dans l’objet. Vérifiez aussi :
- Les paramètres de courrier indésirable de votre client de messagerie (comme Outlook ou Gmail)
- Les limites d’expéditeur, les paramètres de courrier indésirable et les paramètres de mise en quarantaine de votre serveur de messagerie (comme Exchange, Microsoft 365 ou G-suite)
- Les paramètres de votre appliance de sécurité de messagerie, le cas échéant (par exemple, Barracuda ou Cisco).
Avez-vous été désabonné par erreur du groupe d’actions ?
Remarque
N’oubliez pas que si vous vous désinscrivez d’un groupe d’actions, tous les membres d’une liste de distribution seront également désinscrits. Vous pouvez continuer à utiliser votre adresse e-mail de liste de distribution. Toutefois, vous devrez informer les utilisateurs de votre liste de distribution que s’ils se désinscrivent, ils désinscrivent toute la liste de distribution et pas seulement eux-mêmes. Pour contourner cela, vous devez ajouter l’adresse e-mail de tous les utilisateurs du groupe d’actions individuellement. Un groupe d’actions peut contenir jusqu’à 1 000 adresses e-mail. Ensuite, si un utilisateur spécifique souhaite se désinscrire, il pourra le faire sans affecter les autres utilisateurs. Vous pourrez également voir quels utilisateurs se sont désinscrits.
Les e-mails d’alerte fournissent un lien pour se désabonner du groupe d’actions. Pour vérifier si vous vous êtes accidentellement désabonné de ce groupe d’actions, vous avez deux options :
- Ouvrir le groupe d’actions dans le portail et vérifier la colonne État :
- Rechercher dans votre e-mail la confirmation de résiliation d’abonnement :
Pour vous réabonner, cliquez sur le lien de l’e-mail de confirmation de désabonnement que vous avez reçu ou supprimez l’adresse e-mail du groupe d’actions, puis rajoutez-la.
Avez-vous dépassé les limites de service en envoyant de nombreux e-mails à une seule adresse e-mail ?
L’adresse de messagerie est soumise à une restriction de 100 e-mails maximum toutes les heures pour chaque adresse e-mail. Si vous dépassez ce seuil, aucune autre notification par e-mail n’est envoyée. Vérifiez si vous avez reçu un message indiquant que votre adresse e-mail est temporairement limitée :
Si vous souhaitez recevoir un volume élevé de notifications sans limitation du débit, envisagez d’utiliser une autre action, telle que :
- webhook
- Application logique
- Fonction Azure
- Runbooks Automation
Aucune de ces actions n’est limitée au niveau du débit.
Je n’ai pas reçu le SMS, l’ appel vocal ou la notification Push que j’attendais
Si vous pouvez voir une alerte déclenchée dans le portail, mais que vous n’avez pas reçu le SMS, l’appel vocal ou la notification Push que vous avez configuré, effectuez les vérifications suivantes :
L’action a-t-elle été supprimée par une règle de traitement des alertes ?
Vérifiez en cliquant sur l’alerte déclenchée dans le portail, puis examinez l’onglet Historique à la recherche des groupes d’actions supprimés :
Si cela était involontaire, vous pouvez modifier, désactiver ou supprimer la règle de traitement des alertes.
SMS/Appel vocal : Votre numéro de téléphone est-il correct ?
Vérifiez l’action SMS pour rechercher des fautes de frappe dans l’indicatif du pays ou le numéro de téléphone.
SMS/voix : avez-vous dépassé les limites de service ?
Les appels SMS et vocaux sont limités à une seule notification toutes les cinq minutes par numéro de téléphone. Si vous dépassez ce seuil, les notifications sont supprimées.
- Appel vocal : vérifiez l’historique des appels et voyez si vous avez reçu un autre appel d’Azure dans les cinq minutes précédentes.
- SMS – Vérifiez dans votre historique des SMS si vous avez reçu un message indiquant que votre numéro de téléphone fait l’objet d’une limitation de débit.
Si vous souhaitez recevoir un volume élevé de notifications sans limitation du débit, envisagez d’utiliser une autre action, comme l’une des actions suivante telle que :
- webhook
- Application logique
- Fonction Azure
- Runbooks Automation
Aucune de ces actions n’est limitée au niveau du débit.
SMS : Avez-vous été désabonné par erreur du groupe d’actions ?
Ouvrez votre historique des SMS pour voir si vous avez refusé la réception de SMS provenant de ce groupe d’actions (avec la réponse DISABLE nom_court_groupe_actions) ou de tous les groupes d’actions (avec la réponse STOP).
Pour vous abonner à nouveau, envoyez la commande SMS appropriée (ENABLE ou START nom_court_groupe_actions) ou supprimez l’action SMS du groupe d’actions, puis rajoutez-la à nouveau. Pour plus d’informations, consultez Comportement des alertes SMS dans les groupes d’actions.
Avez-vous bloqué accidentellement les notifications sur votre téléphone ?
La plupart des téléphones mobiles vous permettent de bloquer les appels ou SMS de numéros de téléphone ou de codes courts spécifiques, ou de bloquer les notifications Push émanant d’applications spécifiques (telles que les applications mobiles Azure). Pour vérifier si vous avez bloqué accidentellement les notifications sur votre téléphone, recherchez la documentation spécifique à votre système d’exploitation et votre modèle de téléphone, ou testez un autre appareil et un autre numéro de téléphone.
L’action attendue ne s’est pas déclenchée
Si vous pouvez voir une alerte déclenchée dans le portail, mais que son action configurée ne s’est pas déclenchée, procédez comme suit :
L’action a-t-elle été supprimée par une règle de traitement des alertes ?
Vérifiez en cliquant sur l’alerte déclenchée dans le portail, puis examinez l’onglet Historique à la recherche des groupes d’actions supprimés :
Si cela était involontaire, vous pouvez modifier, désactiver ou supprimer la règle de traitement des alertes.
Le webhook s’est-il déclenché ?
L’adresse IP source est-elle bloquée ?
Ajoutez les adresses IP à partir desquelles le webhook sera appelé à votre liste d’adresses IP autorisées.
Votre point de terminaison webhook fonctionne-t-il correctement ?
Vérifiez si le point de terminaison du webhook que vous avez configuré est correct et si le point de terminaison fonctionne correctement. Vérifiez vos journaux de webhook ou instrumentez son code pour pouvoir l’examiner (par exemple, enregistrez la charge utile entrante).
Utilisez-vous le format approprié pour appeler Slack ou Microsoft Teams ?
Chacun de ces points de terminaison attend un format JSON spécifique. Suivez ces instructions pour configurer une action d’application logique à la place.Est-ce que votre webhook a cessé de répondre ou a retourné des erreurs ?
Les groupes d’actions du webhook suivent généralement ces règles lors de leur appel :
- Lorsqu’un webhook est appelé et que la première tentative échoue, l’appel est retenté au moins 1 fois et jusqu’à cinq fois (5 nouvelles tentatives) à différents intervalles (5, 20, 40 secondes).
- Le délai entre la 1re et la 2e tentative est de 5 secondes
- Le délai entre la 2e et la 3e tentative est de 20 secondes
- Le délai entre la 3e et la 4e tentative est de 5 secondes
- Le délai entre la 4e et la 5e tentative est de 40 secondes
- Le délai entre la 5e et la 6e tentative est de 5 secondes
- Si les tentatives d’appel du webhook échouent, aucun groupe d’actions n’appelle le point de terminaison pendant 15 minutes.
- La logique de nouvelle tentative considère que l’appel peut faire l’objet d’une nouvelle tentative. Codes d’état : 408, 429, 503, 504 ou
HttpRequestException,WebExceptionouTaskCancellationExceptionautorisent les nouvelles tentatives d’appel.
- Lorsqu’un webhook est appelé et que la première tentative échoue, l’appel est retenté au moins 1 fois et jusqu’à cinq fois (5 nouvelles tentatives) à différents intervalles (5, 20, 40 secondes).
L’action ou la notification s’est produite plusieurs fois
Si vous avez reçu une notification pour une alerte (par exemple, un e-mail ou un SMS) plusieurs fois, ou si l’action de l’alerte (par exemple, webhook ou Azure Function) a été déclenchée plusieurs fois, procédez comme suit :
S’agit-il vraiment de la même alerte ?
Dans certains cas, plusieurs alertes similaires sont déclenchées à peu près en même temps. Par conséquent, vous pourriez avoir l’impression que la même alerte déclenche plusieurs fois ses actions. Par exemple, une règle d’alerte de journal d’activité peut être configurée pour se déclencher quand un événement démarre ou se termine (réussi ou échoué) en ne filtrant pas sur le champ État de l’événement.
Pour vérifier si ces actions ou notifications proviennent de différentes alertes, examinez les détails de l’alerte, comme son horodatage et l’ID d’alerte ou son ID de corrélation. Vous pouvez également consulter la liste des alertes déclenchées dans le portail. Si tel est le cas, vous devez adapter la logique de la règle d’alerte ou configurer autrement la source de l’alerte.
L’action se répète-t-elle dans plusieurs groupes d’actions ?
Lorsqu’une alerte est déclenchée, chacun de ses groupes d’actions est traité indépendamment. Ainsi, si une action (sur une adresse e-mail, par exemple) apparaît dans plusieurs groupes d’actions déclenchés, elle est appelée une fois par groupe d’actions.
Pour voir les groupes d’actions qui ont été déclenchés, sélectionnez l’onglet Historique des alertes. Vous verrez que les deux groupes d’actions sont définis dans la règle d’alerte et qu’ils ont été ajoutés aux règles d’alerte par le traitement des alertes :
Le contenu de l’action ou de la notification est inattendu
Une panne a-t-elle pu déclencher l’utilisation du fournisseur de messagerie de secours ?
Les groupes d’actions utilisent deux fournisseurs de messagerie différents pour garantir la remise des notifications par e-mail. Le fournisseur de messagerie principal est résilient et rapide, mais peut parfois subir des pannes. En cas de panne, le fournisseur de messagerie secondaire gère les demandes de courrier. Le fournisseur secondaire n’est qu’une solution de secours. En raison des différences entre les fournisseurs, un e-mail envoyé par notre fournisseur secondaire peut avoir une expérience de messagerie dégradée. La dégradation entraîne une mise en forme et un contenu de l’e-mail légèrement différents. Les modèles d’e-mail étant différents dans les deux systèmes, il n’est pas possible de maintenir la parité entre les deux systèmes.
Les notifications générées par la solution de secours contiennent une note indiquant :
« Ceci est une expérience de messagerie dégradée. Cela signifie que la mise en forme peut être désactivée ou que des détails peuvent être manquants. Si vous souhaitez en savoir plus sur l’expérience de messagerie dégradée, veuillez cliquer ici. »
Si votre notification ne contient pas cette note et que vous avez reçu l’alerte, mais pensez que certains de ses champs sont manquants ou incorrects, vérifiez le format de charge utile.
Quel format avez-vous utilisé lors de la configuration de la règle d’alerte ?
Chaque type d’action (e-mail, webhook, et ainsi de suite) a deux formats : le format par défaut (hérité) et le format de schéma commun. Lorsque vous créez un groupe d’actions, vous spécifiez le format de l’action. Différentes actions dans les groupes d’actions peuvent avoir des formats différents.
Par exemple, pour les actions de webhook :
Vérifiez si le format spécifié au niveau de l’action correspond à ce que vous attendez. Par exemple, vous pourriez avoir développé un code qui répond aux alertes (webhook, fonction, application logique, etc.), qui attendait un format, mais plus tard dans l’action, vous ou une autre personne avez spécifié un format différent.
Vérifiez également le format de charge utile (JSON) pour les alertes de journal d’activité, pour les alertes de recherche de journal (à la fois pour Application Insights et Log Analytics), pour les alertes de métriques, pour le schéma d’alerte commun, et pour les alertes de métriques classiques dépréciées.
Les résultats de la recherche ne sont pas inclus dans les notifications d’alerte de recherche dans les journaux.
À compter de la version 2021-08-01 de l’API des alertes de recherche dans les journaux, les résultats de la recherche ont été supprimés de la charge utile de notification d’alerte. Les résultats de la recherche sont disponibles uniquement pour les règles d’alerte créées avec les anciennes versions d’API (2018-04-16). Par défaut, la création de règles d’alerte via le portail Azure crée la règle avec la version la plus récente. Suivez Modifications apportées à l’expérience de création de règle d’alerte de journal pour en savoir plus sur les modifications et les ajustements recommandés afin d’utiliser la version mise à jour.
Le champ MetricValue contient « nul » pour les notifications d’alerte de recherche dans les journaux résolues.
C'est la procédure normale. Les alertes de Recherche dans les journaux avec état utilisent une logique de résolution basée sur le temps plutôt que celle basée sur la valeur. Azure Monitor envoie une valeur de métrique nulle, car aucune valeur n’a provoqué la résolution de l’alerte, mais plutôt la durée calendaire.
La liste des dimensions est vide ou le titre d’alerte ne contient pas de nom de dimension
Lorsque vous disposez d’une règle d’alerte de recherche dans les journaux qui ne renvoie aucun résultat, l’alerte peut se déclencher comme prévu, mais la liste des dimensions est vide ou le titre de l’alerte ne contient pas de nom de dimension. Lorsqu’une requête ne retourne aucune ligne, le champ ID de ressource (qui est la base du remplissage des champs de dimension et de titre) est vide.
Des informations sont manquantes dans une alerte de journal d’activité
Les alertes du journal d’activité sont des alertes basées sur des événements écrits dans le journal des activités Azure, par exemple des événements sur la création, la mise à jour ou la suppression de ressources Azure, les événements d’intégrité du service et d’intégrité des ressources, ou les résultats d’Azure Advisor et Azure Policy. Si vous avez reçu une alerte basée sur le journal d’activité, mais que certains champs dont vous avez besoin sont manquants ou incorrects, vérifiez d’abord les événements dans le journal d’activité lui-même. Si la ressource Azure n’a pas écrit les champs que vous recherchez dans son événement du journal d’activité, ces champs ne sont pas inclus dans l’alerte correspondante.
Les propriétés personnalisées sont manquantes dans les notifications e-mail, SMS ou Push.
Les propriétés personnalisées sont transmises à la charge utile uniquement pour les actions, telles que le webhook, la fonction Azure ou les applications logiques. Les propriétés personnalisées ne sont pas incluses dans les notifications (e-mail/SMS/push).
La règle de traitement des alertes ne fonctionne pas comme prévu
Si vous pouvez voir dans le portail qu’une alerte a été déclenchée, mais qu’une règle de traitement des alertes associée n’a pas fonctionné comme prévu, suivez ces étapes :
La règle de traitement des alertes est-elle activée ?
Regardez le champ d’état de la règle de traitement des alertes pour vérifier que le rôle d’action associé est bien activé. Par défaut, le portail affiche uniquement les règles d’alerte qui sont activées. Toutefois, vous pouvez modifier le filtre pour afficher toutes les règles.
Si elle n’est pas activée, vous pouvez l’activer en sélectionnant la règle de traitement des alertes avant de cliquer sur Activer.
Est-ce une alerte d’intégrité du service ?
Les alertes d’intégrité du service ne sont pas affectées par les règles de traitement des alertes. Par conséquent, si vous disposez d’une règle de traitement des alertes configurée pour une étendue qui inclut des alertes d’intégrité de service, tandis que les alertes d’intégrité du service se trouvent dans l’étendue, la règle de traitement des alertes ne les affecte pas.
La règle de traitement des alertes a-t-elle traité votre alerte ?
Sélectionnez l’alerte déclenchée dans le portail, puis examinez l’onglet Historique pour voir si la règle de traitement des alertes a été traitée.
Voici un exemple de règle de traitement des alertes qui supprime tous les groupes d’actions :
Voici un exemple de règle de traitement des alertes qui ajoute un autre groupe d’actions :
L’étendue et le filtre de la règle de traitement des alertes correspondent-ils à l’alerte déclenchée ?
Si vous pensez que la règle de traitement des alertes aurait dû être déclenchée mais qu’elle ne l’a pas été, ou inversement, examinez attentivement l’étendue de la règle de traitement des alertes et les conditions de filtre et les comparez aux propriétés de l’alerte déclenchée.
Problèmes lors de la création, de la mise à jour ou de la suppression de règles de traitement des alertes dans le portail Azure
Si vous avez reçu une erreur lors de la tentative de création, de mise à jour ou de suppression d’une règle de traitement des alertes, effectuez les étapes suivantes :
Vérifier les autorisations.
Vous devez disposer du rôle intégré Contributeur de supervision ou des autorisations spécifiques associées aux alertes et aux règles de traitement des alertes.
Vérifiez les paramètres de règle de traitement des alertes.
Consultez la documentation sur les règles de traitement des alertes ou la commande règle de traitement des alertes PowerShell Set-AzAlertProcessingRule.