Alarmes CloudWatch et alarmes composites

Une alarme CloudWatch surveille une seule métrique ou le résultat d’une expression de calcul de métrique sur une période que vous définissez. Lorsque la métrique franchit un seuil que vous avez défini, l’alarme change d’état et peut automatiquement déclencher une action, comme l’envoi d’une notification SNS, la mise à l’échelle d’un groupe Auto Scaling, l’arrêt d’une instance EC2 ou l’exécution d’un OpsItem de Systems Manager. Les alarmes constituent le principal mécanisme de réponse opérationnelle automatisée dans AWS.

Une alarme CloudWatch est toujours dans l’un des trois états suivants : OK — la métrique se situe dans le seuil défini ; ALARM — la métrique a franchi le seuil pendant le nombre requis de périodes d’évaluation ; INSUFFICIENT_DATA — l’alarme vient d’être créée, la métrique n’est pas disponible ou un volume de données suffisant n’a pas encore été collecté. Les transitions entre les états déclenchent les actions configurées pour ce changement d’état — vous pouvez utiliser des rubriques SNS différentes pour les états OK, ALARM et INSUFFICIENT_DATA.

Lors de la création d’une alarme, vous indiquez : la métrique et l’espace de noms, la statistique (Average, Sum, Maximum, etc.), la période (la fréquence d’évaluation de la métrique, en secondes), le nombre de périodes d’évaluation (le nombre de périodes consécutives pendant lesquelles le seuil doit être franchi), la valeur du seuil et l’opérateur de comparaison. L’alarme se déclenche lorsque la métrique franchit le seuil pendant le nombre indiqué de périodes d’évaluation consécutives.

Les actions des alarmes peuvent cibler plusieurs destinations : les rubriques Amazon SNS (pour envoyer un e-mail, un SMS ou déclencher Lambda), les politiques de mise à l’échelle automatique (pour réduire ou augmenter la taille d’un ASG) et les actions EC2 (pour arrêter, supprimer, redémarrer ou récupérer une instance EC2). Pour chaque état (OK, ALARM, INSUFFICIENT_DATA), vous pouvez indiquer un ensemble d’actions différent — par exemple, notifier l’équipe lorsque l’état est ALARM, envoyer une notification de rétablissement avec OK et générer une alerte pour INSUFFICIENT_DATA afin de détecter les lacunes de supervision.

Lorsque CloudWatch évalue une alarme et que certains points de données sont manquants, vous devez décider comment les traiter. Les options sont : notBreaching (considérer les données manquantes comme étant dans le seuil — l’alarme reste OK si les autres données sont correctes), breaching (considérer les données manquantes comme dépassant le seuil — l’alarme passe à ALARM), ignore (l’état de l’alarme ne change pas) et missing (l’alarme passe à INSUFFICIENT_DATA). Choisir la mauvaise option entraîne des faux positifs ou des défaillances silencieuses — une subtilité importante de l’examen SAA-C03.

La résolution de l’alarme correspond au produit de la période par le nombre de périodes d’évaluation. Par exemple, une période de 60 secondes avec 5 périodes d’évaluation signifie que l’alarme prend en compte 5 points de données consécutifs d’une minute. Par défaut, l’alarme ne passe à l’état ALARM que lorsque les cinq périodes franchissent le seuil. Vous pouvez configurer datapoints-to-alarm pour exiger que seuls M points sur N franchissent le seuil — par exemple, 3 sur 5 — ce qui réduit les faux positifs dus aux pics transitoires.

Une alarme composite évalue l’état de plusieurs autres alarmes à l’aide de la logique booléenne (AND, OR, NOT). Elle passe à l’état ALARM uniquement lorsque l’évaluation de son expression de règle est vraie. Les alarmes composites servent à réduire le bruit des alertes — par exemple, générer une alerte uniquement si les alarmes de processeur élevé et de latence élevée se déclenchent simultanément, car un processeur élevé peut être acceptable à lui seul pendant un traitement par lots. Vous pouvez également utiliser des alarmes composites pour supprimer les alarmes enfants pendant les fenêtres de maintenance.

Les alarmes composites prennent en charge les actions de suppression d’alarme — vous pouvez configurer une alarme composite pour supprimer ses alarmes enfants pendant une maintenance planifiée. Par exemple, pendant une fenêtre de déploiement, vous pouvez définir une alarme composite qui combine une alarme « MaintenanceMode » avec une logique OR, afin de supprimer toutes les notifications des alarmes enfants pendant la maintenance. Cela évite une avalanche d’alertes lorsque vous mettez intentionnellement des services hors ligne pour effectuer des mises à niveau.

Les groupes Auto Scaling utilisent les alarmes CloudWatch comme déclencheurs pour les politiques de mise à l’échelle par étapes et de mise à l’échelle simple. Lorsque l’alarme passe à l’état ALARM, la politique de mise à l’échelle s’exécute. Pour la mise à l’échelle par étapes, vous définissez plusieurs ajustements de mise à l’échelle correspondant à différentes plages de seuils — par exemple, ajouter 1 instance si le processeur est entre 70 et 80 %, en ajouter 3 entre 80 et 90 % et en ajouter 5 au-delà de 90 %. L’alarme déclenche la première étape applicable en fonction du niveau de dépassement lors de l’évaluation.

Vous pouvez créer des alarmes de facturation dans CloudWatch pour être averti lorsque vos frais AWS estimés dépassent un seuil. Les métriques de facturation sont publiées uniquement dans la région us-east-1, quel que soit l’emplacement de vos ressources, et sont mises à jour environ toutes les 6 heures. Pour activer les alarmes de facturation, vous devez d’abord activer les Billing Alerts dans la console AWS Billing. L’outil le plus précis est AWS Budgets, mais les alarmes de facturation CloudWatch restent une option valide évaluée à l’examen.

Vous pouvez définir manuellement l’état d’une alarme à l’aide de la commande set-alarm-state afin de tester les actions de l’alarme sans attendre qu’un seuil réel soit franchi. Cela permet de vérifier que vos rubriques SNS, vos politiques de mise à l’échelle automatique et vos fonctions Lambda réagissent correctement. Testez toujours les actions de vos alarmes dans un environnement hors production et vérifiez que les abonnements par e-mail de la rubrique SNS appropriée ont été confirmés avant de vous fier aux alarmes pour les alertes de production.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les alarmes ont trois états (OK, ALARM, INSUFFICIENT_DATA) et peuvent déclencher des actions SNS, Auto Scaling et EC2, que datapoints-to-alarm permet une évaluation M-sur-N afin de réduire les faux positifs et que les alarmes composites utilisent la logique booléenne pour combiner plusieurs alarmes et réduire le bruit des alertes. Nous allons maintenant découvrir CloudWatch Logs et Log Insights pour la gestion centralisée des journaux.