Choix du type approprié de règle d’alerte
Cet article décrit les types d’alertes Azure Monitor que vous pouvez créer. Il vous aide à comprendre quand utiliser chaque type d’alerte. Pour plus d’informations sur les prix, consultez la page de tarification.
Les types d’alertes sont :
- Alertes de métriques
- Journaliser les alertes de recherche
- Alertes du journal d’activité
- Alertes de détection intelligente
- Alertes Prometheus
Types d’alertes Azure Monitor
Type d’alerte | Quand l’utiliser | Informations sur la tarification |
---|---|---|
Alerte de métrique | Les données de métrique sont stockées dans le système déjà pré-calculées. Les alertes de métrique sont utiles quand vous souhaitez être alerté sur les données qui nécessitent peu ou pas de manipulation. Utilisez des alertes de métrique si les données que vous souhaitez surveiller sont disponibles dans les données de métrique. | Chaque règle d’alerte de métrique est facturée en fonction du nombre de séries chronologiques supervisées. |
Alerte de recherche de journal | Vous pouvez utiliser les alertes de recherche de journaux pour effectuer des opérations logiques avancées sur vos données. Si les données que vous souhaitez surveiller sont disponibles dans les journaux ou nécessitent une logique avancée, vous pouvez utiliser les fonctionnalités robustes de Kusto Query Language (KQL) pour la manipulation des données à l'aide d'alertes de recherche de journaux. | Chaque règle d'alerte de recherche de journal est facturée en fonction de l'intervalle auquel la requête de journal est évaluée. Une évaluation plus fréquente des requêtes entraîne un coût plus élevé. Pour les alertes de recherche de journaux configurées pour une surveillance à grande échelle à l'aide du fractionnement par dimensions, le coût dépend également du nombre de séries temporelles créées par les dimensions résultant de votre requête. |
Alerte du journal d’activité | Les journaux d’activité fournissent un audit de toutes les actions qui se sont produites sur les ressources. Utilisez des alertes de journal d’activité pour être alerté quand un événement spécifique se produit sur une ressource, comme un redémarrage, un arrêt ou la création ou la suppression d’une ressource. Les alertes Service Health et les alertes Resource Health vous avertissent qu’il y a un problème avec l’un de vos services ou ressources. | Pour plus d’informations, consultez la page relative aux prix appliqués. |
Alertes Prometheus | Les alertes Prometheus sont utilisées pour alerter à propos des métriques Prometheus stockées dans les services managés Azure Monitor pour Prometheus. Les règles d’alerte sont basées sur le langage de requête open source PromQL. | Les règles d’alerte Prometheus sont facturées uniquement sur les données interrogées par les règles. Pour plus d’informations, consultez la page relative aux prix appliqués. |
Alertes de métrique
Une règle d’alerte de métrique supervise une ressource en évaluant les conditions sur les métriques de ressource à intervalles réguliers. Si les conditions sont remplies, une alerte est déclenchée. Une série chronologique de métriques est une série de valeurs de métriques capturées sur une période donnée.
Vous pouvez créer des règles à l’aide de ces métriques :
- Métriques de plateforme
- Métriques personnalisées
- Métriques personnalisées Application Insights
- Journaux sélectionnés à partir d’un espace de travail Log Analytics converti en métriques
Les règles d’alerte de métrique incluent ces fonctionnalités :
- Vous pouvez utiliser plusieurs conditions sur une règle d’alerte pour une seule ressource.
- Vous pouvez ajouter de la précision en supervisant plusieurs dimensions de métrique.
- Vous pouvez utiliser des seuils dynamiques qui sont pilotés par le machine learning.
- Vous pouvez configurer si les alertes de métrique sont avec état ou sans état. Les alertes de métrique sont avec état par défaut.
La cible de la règle d’alerte de métrique peut être :
- Une seule ressource, telle qu’une machine virtuelle. Pour connaître les types de ressources pris en charge, consultez Ressources prises en charge pour les alertes de métrique dans Azure Monitor.
- Plusieurs ressources du même type dans la même région Azure, comme un groupe de ressources.
Application de plusieurs conditions à une règle d’alerte de métrique
Quand vous créez une règle d’alerte pour une seule ressource, vous pouvez appliquer plusieurs conditions. Par exemple, vous pouvez créer une règle d’alerte pour superviser une machine virtuelle Azure et alerter quand le « pourcentage d’utilisation du processeur est supérieur à 90 % » et que la « longueur de la file d’attente comprend plus de 300 éléments ». Quand une règle d’alerte a plusieurs conditions, l’alerte se déclenche quand toutes les conditions de la règle d’alerte sont vraies et est résolue quand au moins une des conditions n’est plus remplie pour trois vérifications consécutives.
Limiter la cible avec des dimensions
Pour obtenir des instructions sur l’utilisation des dimensions dans les règles d’alerte de métrique, consultez Surveiller plusieurs séries chronologiques dans une seule règle d’alerte de métrique.
Superviser la même condition sur plusieurs ressources à l’aide du fractionnement par dimensions
Pour superviser la même condition sur plusieurs ressources Azure, vous pouvez utiliser le fractionnement par dimensions. Lorsque vous utilisez le fractionnement par dimensions, vous pouvez créer des alertes axées sur les ressources à grande échelle pour un abonnement ou un groupe de ressources. Les alertes sont divisées en alertes distinctes en regroupant des combinaisons. Le fractionnement sur une colonne d’ID de ressource Azure fait de la ressource spécifiée la cible d’alerte.
Vous pouvez également décider de ne pas opérer de fractionnement quand vous voulez qu’une condition s’applique à plusieurs ressources dans l’étendue. Par exemple, si vous souhaitez déclencher une alerte si au moins cinq machines de l’étendue du groupe de ressources ont une utilisation du processeur supérieure à 80 %.
Surveiller plusieurs ressources avec une règle d’alerte
Vous pouvez effectuer une supervision à grande échelle en appliquant la même règle d’alerte de métrique à plusieurs ressources du même type pour les ressources qui existent dans la même région Azure. Les notifications individuelles sont envoyées pour chaque ressource supervisée.
Le tableau suivant indique dans quels clouds Azure les métriques de plateforme sont prises en charge en fonction du service considéré :
Service | Fournisseur de ressources | Azure global | Gouvernement américain | Chine |
---|---|---|---|---|
Machines virtuelles | "Microsoft.Compute/virtualMachines" | Oui | Oui | Oui |
Bases de données SQL Server | "Microsoft.Sql/servers/databases" | Oui | Oui | Oui |
Pools élastiques SQL Server | "Microsoft.Sql/servers/elasticpools" | Oui | Oui | Oui |
Pools de capacité NetApp Files | "Microsoft.NetApp/netAppAccounts/capacityPools" | Oui | Oui | Oui |
Volumes NetApp Files | "Microsoft.NetApp/netAppAccounts/capacityPools/volumes" | Oui | Oui | Oui |
Azure Key Vault | "Microsoft.KeyVault/vaults" | Oui | Oui | Oui |
Cache Azure pour Redis | "Microsoft.Cache/redis" | Oui | Oui | Oui |
Appareils Azure Stack Edge | (Il n’existe aucun fournisseur de ressources spécifique pour cette ressource. En raison du fonctionnement des périphériques Stack, les métriques sont récupérées à partir de plusieurs fournisseurs de ressources. Pour plus d’informations sur les alertes de cette ressource, consultez cette documentation : Examiner les alertes sur Azure Stack Edge) | Oui | Oui | Oui |
Coffres Recovery Services | "Microsoft.RecoveryServices/Vaults" | Oui | No | Non |
Azure Database pour PostgreSQL - Serveur flexible | "Microsoft.DBforPostgreSQL/flexibleServers" | Oui | Oui | Oui |
Machines nues (Operator Nexus) | "Microsoft.NetworkCloud/bareMetalMachines" | Oui | Oui | Oui |
Appliances de stockage (Operator Nexus) | "Microsoft.NetworkCloud/storageAppliances" | Oui | Oui | Oui |
Clusters (Operator Nexus) | "Microsoft.NetworkCloud/clusters" | Oui | Oui | Oui |
Périphériques réseau (Operator Nexus) | Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks | Oui | Oui | Oui |
Règles de collecte de données | "Microsoft.Insights/datacollectionrules" | Oui | Oui | Oui |
Notes
Les alertes de métrique multiressources ne sont pas prises en charge pour :
- Alerter sur les métriques d’invité de machine virtuelle.
- Alerter sur les métriques de réseau de machines virtuelles (Octets entrants réseau totaux, Octets sortants réseau totaux, Flux entrants, Flux sortants, Taux de création maximal de flux entrants et Taux de création maximal de flux sortants).
Vous disposez de trois méthodes pour spécifier l’étendue de la supervision avec une règle d’alerte de métrique unique. Par exemple, avec des machines virtuelles, vous pouvez spécifier l’étendue sous les formes suivantes :
- Une liste de machines virtuelles dans une seule région Azure au sein d’un abonnement.
- Toutes les machines virtuelles dans une seule région Azure dans un ou plusieurs groupes de ressources d’un abonnement.
- Toutes les machines virtuelles dans une seule région Azure au sein d’un abonnement.
Appliquer le Machine Learning avancé avec des seuils dynamiques
Les seuils dynamiques utilisent le Machine Learning avancé pour :
- Apprendre le comportement historique des métriques.
- Identifier les modèles et les adapter aux changements de métriques au fil du temps, tels que les modèles horaires, quotidiens ou hebdomadaires.
- Reconnaître les anomalies qui indiquent les problèmes de service éventuels.
- Calculer le seuil le plus approprié pour la métrique.
Le Machine Learning utilise en permanence de nouvelles données pour en apprendre plus et rendre le seuil plus précis. Étant donné que le système s’adapte au comportement des métriques au fil du temps et qu’il émet des alertes en fonction des écarts par rapport à son modèle, vous n’avez pas besoin de connaître le seuil « approprié » pour chaque métrique.
Les seuils dynamiques vous aident à :
- Créer des alertes scalables pour des centaines de séries de métriques avec une seule règle d’alerte. Si vous avez moins de règles d’alerte, vous passez moins de temps à créer et à gérer des règles d’alertes.
- Créer des règles sans avoir à connaître le seuil à configurer.
- Configurer des alertes de métrique à l’aide de concepts généraux sans connaissances approfondies sur la métrique.
- Empêcher les seuils bruyants (faible précision) ou larges (faible rappel) qui n’ont pas de modèle attendu.
- Gérer les métriques bruyantes (telles que le processeur ou la mémoire de la machine) et les métriques avec une faible dispersion (par exemple, la disponibilité et le taux d’erreur)
Consultez Seuils dynamiques pour obtenir des instructions détaillées sur l’utilisation de seuils dynamiques dans les règles d’alerte de métrique.
Alertes de recherche dans les journaux
Une règle d'alerte de recherche de journaux surveille une ressource à l'aide d'une requête Log Analytics pour évaluer les journaux de ressources à une fréquence définie. Si les conditions sont remplies, une alerte est déclenchée. Étant donné que vous pouvez utiliser des requêtes Log Analytics, vous pouvez effectuer des opérations logiques avancées sur vos données et utiliser les fonctionnalités robustes de KQL pour manipuler des données de journal.
La cible de la règle d'alerte de recherche de journal peut être :
- Une seule ressource, telle qu’une machine virtuelle.
- Un seul conteneur de ressources, comme un groupe de ressources ou un abonnement.
- Plusieurs ressources qui utilisent une requête inter-ressources.
Les alertes de recherche de journaux peuvent mesurer deux choses différentes, qui peuvent être utilisées pour différents scénarios de surveillance :
- 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.
Vous pouvez configurer si les alertes de recherche de journaux sont avec ou sans état.
Notez que les alertes de recherche de 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
.
Remarque
Les alertes de recherche de journaux fonctionnent mieux lorsque vous essayez de détecter des données spécifiques dans les journaux, plutôt que lorsque vous essayez de détecter un manque de données dans les journaux. Comme les journaux sont des données semi-structurées, ils ont, par nature, une latence plus importante que les données de métrique sur des informations telles qu’une pulsation de machine virtuelle. Pour éviter les déclenchements d’alerte par erreur quand vous essayez de détecter un manque de données dans les journaux, envisagez 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.
Superviser plusieurs instances d’une ressource à l’aide de dimensions
Vous pouvez utiliser des dimensions lorsque vous créez des règles d'alerte de recherche de journaux pour surveiller les valeurs de plusieurs instances d'une ressource avec une seule règle. Par exemple, vous pouvez superviser l’utilisation du processeur sur plusieurs instances exécutant votre site web ou votre application. Chaque instance est surveillée individuellement. Des notifications sont envoyées pour chaque instance.
Superviser la même condition sur plusieurs ressources à l’aide du fractionnement par dimensions
Pour superviser la même condition sur plusieurs ressources Azure, vous pouvez utiliser le fractionnement par dimensions. Lorsque vous utilisez le fractionnement par dimensions, vous pouvez créer des alertes axées sur les ressources à grande échelle pour un abonnement ou un groupe de ressources. Les alertes sont divisées en alertes distinctes en regroupant des combinaisons à l’aide de colonnes numériques ou de chaînes. Le fractionnement sur la colonne d’ID de ressource Azure fait de la ressource spécifiée la cible d’alerte.
Vous pouvez également décider de ne pas opérer de fractionnement quand vous voulez qu’une condition s’applique à plusieurs ressources dans l’étendue. Par exemple, si vous souhaitez déclencher une alerte si au moins cinq machines de l’étendue du groupe de ressources ont une utilisation du processeur supérieure à 80 %.
Utiliser l'API pour les règles d'alerte de recherche de journaux
Gérez de nouvelles règles dans vos espaces de travail à l’aide de l’API ScheduledQueryRules.
Remarque
Les alertes de recherche de journaux pour Log Analytics étaient auparavant gérées à l'aide de l'ancienne API d'alerte Log Analytics. Découvrez-en plus sur le basculement sur l’API ScheduledQueryRules actuelle.
Consigner les alertes de recherche sur votre facture Azure
Les alertes de recherche de journaux sont répertoriées sous le fournisseur de ressources microsoft.insights/scheduledqueryrules
avec :
- Enregistrez les alertes de recherche sur Application Insights affichées avec le nom exact de la ressource ainsi que les propriétés du groupe de ressources et des alertes.
- Les alertes de recherche de journaux sur Log Analytics sont affichées avec le nom exact de la ressource ainsi que les propriétés du groupe de ressources et des alertes lorsqu'elles sont créées à l'aide de l'API selectedQueryRules.
- Les alertes de recherche de journaux créées à partir de l’ancienne API Log Analytics ne font pas l’objet d’un suivi des ressources Azure et n’ont pas de noms de ressources uniques imposés. Ces alertes sont toujours créées sur
microsoft.insights/scheduledqueryrules
en tant que ressources masquées, avec la structure de nommage de ressources<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>
. Les alertes de recherche de journaux sur l'ancienne API sont affichées avec le nom de ressource masqué précédent ainsi que les propriétés du groupe de ressources et des alertes.
Remarque
Caractères de ressources non pris en charge comme <, >, %, &, , ? et / sont remplacés par un trait de soulignement (_) dans les noms de ressources masqués. Ce changement de caractère est également reflété dans les informations de facturation.
Alertes de journal d’activité
Une alerte de journal d’activité supervise une ressource en vérifiant les journaux d’activité d’un nouvel événement de journal d’activité qui correspond aux conditions définies.
Vous pouvez utiliser des alertes de journal d’activité pour ces types de scénarios :
- Quand une opération spécifique se produit sur les ressources d’un groupe de ressources ou d’un abonnement spécifique. Par exemple, vous pouvez être averti quand :
- Une machine virtuelle dans un groupe de ressources de production est supprimée.
- De nouveaux rôles sont attribués à un utilisateur de votre abonnement.
- Un événement Service Health se produit. Les événements Service Health incluent les notifications des incidents et des événements de maintenance qui s’appliquent aux ressources de votre abonnement.
Vous pouvez créer une alerte de journal d’activité sur :
- Toutes les catégories d’événements du journal d’activité, autres que sur les événements d’alerte.
- Tout événement de journal d’activité se produit dans la propriété de niveau supérieur dans l’objet JSON.
Les règles d’alerte du journal d’activité étant des ressources Azure, elles peuvent être créées à l’aide d’un modèle Azure Resource Manager. Elles peuvent également être créées, mises à jour ou supprimées dans le portail Azure.
Une alerte du journal d’activité supervise uniquement les événements de l’abonnement dans lequel elle a été créée.
Alertes Service Health
Les alertes Service Health sont un type d’alerte d’activité. Service Health vous avertit des pannes, des activités de maintenance planifiée et autres avis sur l’intégrité parce que l’expérience Service Health authentifiée a connaissance des services et des ressources que vous utilisez actuellement.
Le meilleur moyen d’utiliser Service Health est de configurer des alertes Service Health pour vous avertir, par le biais de vos canaux de communication préférés, quand des problèmes de service, des maintenances planifiées et autres changements sont susceptibles d’affecter les services et régions Azure que vous utilisez.
Alertes Resource Health
Les alertes Resource Health sont un type d’alerte d’activité. La Vue d’ensemble de Resource Health vous aide à diagnostiquer et à obtenir un support pour les problèmes de service qui affectent vos ressources Azure. Il rend compte de l’intégrité actuelle et passée de vos ressources.
Resource Health s’appuie sur des signaux émis par les différents services Azure pour évaluer l’intégrité d’une ressource. Si une ressource n’est pas saine, Resource Health analyse d’autres informations pour déterminer la source du problème. Il signale également les actions que Microsoft entreprend pour résoudre le problème et identifie les mesures que vous pouvez prendre pour y remédier.
Alertes de détection intelligente
Une fois que vous avez configuré Application Insights pour votre projet et que votre application génère une certaine quantité de données, il faut 24 heures à la détection intelligente pour apprendre le comportement normal de votre application. Les performances de votre application présentent un modèle de comportement typique. Certaines demandes ou certains appels de dépendance sont davantage sujets aux erreurs que d’autres, et le taux d’échec global risque d’augmenter en même temps que la charge.
La détection intelligente utilise le machine learning pour trouver ces anomalies. La détection intelligente surveille les données reçues de votre application, en particulier les taux d’échecs. Application Insights vous alerte automatiquement en quasi temps réel si votre application web enregistre une hausse anormale du taux de requêtes ayant échoué.
À mesure qu’Application Insights reçoit les données de votre application web, la détection intelligente compare le comportement actuel avec les modèles observés au cours des derniers jours. S’il y a une augmentation anormale du taux d’échec par rapport au niveau de performance précédent, une analyse est déclenchée.
Pour vous aider à trier et à diagnostiquer un problème, les détails de l’alerte comprennent une analyse des caractéristiques des échecs et les données d’application associées. Elle fournit également des liens vers le portail Application Insights pour un diagnostic plus poussé. La fonctionnalité ne requiert aucune installation ni configuration, car elle utilise des algorithmes d’apprentissage automatique pour prédire le taux d’échec normal.
Même si les alertes de métrique vous indiquent qu’il peut y avoir un problème, la détection intelligente démarre le travail de diagnostic pour vous. Elle effectue une grande partie de l’analyse à votre place. Vous obtenez les résultats clairement empaquetés, ce qui vous permet d’accéder rapidement à l’origine du problème.
La détection intelligente peut être utilisée pour toutes les applications web, hébergées dans le cloud ou sur vos propres serveurs, qui génèrent des données sur les requêtes ou les dépendances de l’application.
Alertes Prometheus
Les alertes Prometheus sont utilisées pour surveiller les métriques stockées dans les services managés Azure Monitor pour Prometheus. Les règles d’alerte Prometheus sont configurées dans le cadre de groupes de règles Prometheus. Elles se déclenchent quand le résultat d’une expression PromQL est défini sur true. Les alertes Prometheus déclenchées sont affichées et gérées comme les autres types d’alerte.
Étapes suivantes
- Obtenir une vue d’ensemble des alertes.
- Création d’une règle d’alerte.
- Explorez plus en détail la détection intelligente.