Métriques et alertes Azure Monitor

Azure Monitor est la plateforme unifiée d’observabilité de toutes les ressources Azure. Elle collecte les métriques (données numériques de séries temporelles) et les journaux (enregistrements structurés d’événements) de chaque service que vous déployez. Sans Azure Monitor, vous travailleriez à l’aveugle, sans pouvoir détecter la dégradation des performances ou les problèmes de capacité avant qu’ils n’affectent les utilisateurs.

Les métriques de plateforme sont automatiquement collectées pour chaque ressource Azure, sans coût supplémentaire. Pour une machine virtuelle, Azure Monitor capture Percentage CPU, Network In, Network Out, Disk Read Bytes et bien d’autres données. Ces métriques sont stockées avec une granularité d’une minute pendant 93 jours dans le magasin de métriques. Aucun agent ni aucune configuration n’est nécessaire pour commencer à les consulter.

Le Metrics Explorer du portail Azure vous permet de représenter interactivement n’importe quelle métrique de plateforme. Sélectionnez une ressource, choisissez un espace de noms de métriques, sélectionnez une métrique et choisissez un type d’agrégation (Moyenne, Maximum, Minimum, Nombre ou Somme). Vous pouvez superposer plusieurs métriques, les répartir par dimension (par exemple par disque ou interface réseau) et épingler le graphique à un tableau de bord Azure.

Une règle d’alerte de métrique se déclenche lorsqu’une métrique franchit un seuil fixe pendant une période d’évaluation définie. Par exemple : déclencher une alerte lorsque Percentage CPU est supérieur à 85 % pendant 5 minutes consécutives. Les règles d’alerte se composent d’une ressource cible, d’une condition et d’un groupe d’actions qui définit ce qui se produit lorsque l’alerte se déclenche.

Les seuils dynamiques utilisent l’apprentissage automatique pour définir automatiquement les limites des alertes en fonction du comportement historique. Au lieu de coder en dur un pourcentage d’utilisation du processeur, Azure Monitor apprend le comportement normal de votre métrique et déclenche une alerte uniquement lorsque la valeur s’en écarte de manière importante. Cela réduit les faux positifs pour les métriques dont le niveau naturel varie selon l’heure ou le jour de la semaine. Définissez la sensibilité sur Faible, Moyenne ou Élevée.

Un groupe d’actions définit les notifications et les actions automatisées exécutées lorsqu’une alerte se déclenche. Les types de notification pris en charge incluent Email/SMS/Push, Voix et notifications d’application Azure. Les actions automatisées comprennent l’appel d’une Azure Function, la publication vers une Logic App, le déclenchement d’un webhook ou l’exécution d’un Automation Runbook. Un même groupe d’actions peut être partagé par de nombreuses règles d’alerte.

Chaque règle d’alerte reçoit une gravité allant de Sev 0 (Critique) à Sev 4 (Verbeux). La gravité ne détermine pas le moment où l’alerte se déclenche : il s’agit de métadonnées utilisées par les équipes d’exploitation pour trier les incidents. La bonne pratique consiste à appeler les ingénieurs d’astreinte uniquement pour les alertes Sev 0 et Sev 1, à diriger les alertes Sev 2 vers une file de tickets et à traiter les alertes Sev 3–4 comme des informations.

Les alertes du journal d’activité se déclenchent lors d’opérations administratives enregistrées dans le journal d’activité Azure, et non lors de métriques. Utilisez-les pour être informé lorsqu’une personne supprime un groupe de ressources, modifie une règle de groupe de sécurité réseau ou redémarre une VM. Elles sont configurées comme les alertes de métriques, mais ciblent une condition du journal d’activité telle que le nom de l’opération ou le type de ressource.

Une instance d’alerte passe par trois états : Déclenchée → Accusé de réception → Résolue. Les règles de traitement des alertes (anciennement appelées règles de suppression) vous permettent de supprimer les notifications pendant les périodes de maintenance planifiées ou d’ajouter des groupes d’actions à toutes les alertes correspondant à une étendue, sans modifier chaque règle d’alerte individuellement. Elles sont indispensables pour gérer le volume de notifications d’alerte pendant les déploiements.

Les métriques de la plateforme ne se limitent pas aux VM. App Service expose Http5xx, RequestCount et AverageResponseTime. Azure SQL Database expose cpu_percent et dtu_consumption_percent. Azure Storage expose UsedCapacity et Transactions. Vous appliquez le même modèle d’alerte de métriques à tous ces services, ce qui vous fournit une approche uniforme de la supervision, quel que soit le type de ressource.

Azure Monitor prend en charge les alertes de métriques pour plusieurs ressources, qui appliquent une seule règle à toutes les ressources du même type dans un abonnement ou un groupe de ressources. Par exemple, une seule règle d’alerte peut surveiller l’utilisation élevée du processeur de toutes les VM d’un groupe de ressources. Cela réduit considérablement le nombre de règles à gérer par rapport à la création d’une règle par VM. Les alertes pour plusieurs ressources sont limitées à un groupe de ressources ou à un abonnement, ainsi qu’à un type de ressource spécifique.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que Azure Monitor collecte automatiquement les métriques de plateforme de chaque ressource Azure, que les règles d’alerte de métriques se déclenchent selon des seuils statiques ou dynamiques et notifient les équipes via des groupes d’actions, et que les alertes du journal d’activité se déclenchent lors d’opérations administratives telles que la suppression d’une ressource. Nous allons maintenant découvrir Log Analytics et KQL pour interroger des données de journal structurées.