Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
CloudWatch Alarmes
Cette solution déploie deux CloudWatch alarmes qui surveillent les conditions opérationnelles nécessitant une attention particulière. Par défaut, aucune action de notification n'est configurée pour ces alarmes. Nous recommandons d'abonner une rubrique Amazon SNS à chaque alarme afin que les opérateurs soient immédiatement avertis en cas de problème.
Abonnez-vous aux notifications d'alarme
Pour recevoir des notifications lorsqu'une alarme se déclenche :
-
Ouvrez la console CloudWatch des alarmes
. -
Recherchez les alarmes préfixées par le nom de votre pile (par exemple,
my-stack-OrphanCleanupFailure). -
Sélectionnez l'alarme, puis choisissez Modifier.
-
Sous Notification, choisissez Ajouter une notification.
-
Sélectionnez ou créez une rubrique SNS avec vos points de terminaison de notification préférés (e-mail, SMS ou Lambda).
-
Sélectionnez Update alarm (Mettre à jour une alerte).
Répétez l'opération pour chaque alarme.
OrphanCleanupFailure
| Attribut | Value |
|---|---|
|
Nom de l'alarme |
|
|
Métrique |
|
|
Threshold |
>= 1 panne en 5 minutes |
|
Traiter les données manquantes |
Violation |
Ce que cette alarme surveille : La solution utilise trois niveaux de défense pour empêcher l'emballement des services ECS :
-
Couche 1 : gestion automatisée des erreurs — Le flux de travail d'orchestration des tests inclut la gestion des erreurs à chaque étape. En cas d'échec lors du provisionnement, de la stabilisation ou de l'exécution, le flux de travail déclenche automatiquement un nettoyage pour vider et supprimer les services ECS.
-
Niveau 2 : détection des échecs d'exécution — Si le flux de travail d'orchestration lui-même s'arrête de manière inattendue (par exemple, en raison d'un délai imparti ou d'une erreur interne qui contourne le traitement normal des erreurs), une EventBridge règle détecte l'échec et déclenche indépendamment le nettoyage de chaque région impliquée dans le test.
-
Couche 3 : nettoyage orphelin toutes les heures : un processus planifié s'exécute toutes les heures, recherche les services ECS qui ne sont associés à aucun test actif et les supprime de force. Il s'agit du filet de sécurité de dernier recours : en cas de défaillance des couches 1 et 2, les services divulgués sont tout de même supprimés dans l'heure qui suit. Si le processus de nettoyage des orphelins échoue lui-même, cette alarme se déclenche.
Pourquoi c'est important : les services ECS Fargate orphelins continuent de fonctionner et d'être payants sans aucune visibilité sur la console DLT. Sans abonnement aux notifications, les opérateurs ne découvriront le problème que lorsque des frais imprévus apparaissent sur la facture.
Réponse recommandée : lorsque cette alarme se déclenche, accédez à la console Amazon ECS
MetricFilterCount
| Attribut | Value |
|---|---|
|
Nom de l'alarme |
|
|
Métrique |
|
|
Threshold |
>= 90 |
|
Traiter les données manquantes |
Pas de violation |
Ce que cette alarme surveille : La solution crée des filtres CloudWatch métriques de manière dynamique sur le groupe de journaux ECS pour prendre en charge les métriques en temps réel lors de l'exécution des tests. AWS limite chaque groupe de journaux à 100 filtres métriques. Cette alarme se déclenche lorsque l'utilisation atteint 90 % de cette limite.
Pourquoi c'est important : si la limite est atteinte, les nouveaux tests de charge échoueront.
Réponse recommandée : supprimez les scénarios de test qui ne sont plus nécessaires. Lorsqu'un scénario de test est supprimé, la solution supprime les filtres métriques associés et libère de la capacité pour de nouveaux tests.
