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.
# Définissez et configurez les alarmes dans Incident Detection and Response
AWS travaille avec vous pour définir des métriques et des alarmes afin de fournir une visibilité sur les performances de vos applications et de leur AWS infrastructure sous-jacente. Nous demandons que les alarmes respectent les critères suivants lors de la définition et de la configuration des seuils :
+ Les alarmes ne passent à l'état « Alarme » que lorsqu'elles ont un impact critique sur la charge de travail surveillée (perte de revenus ou dégradation de l'expérience client réduisant considérablement les performances) nécessitant une attention immédiate de la part de l'opérateur.
+ Les alarmes doivent également impliquer les résolveurs que vous avez spécifiés pour la charge de travail en même temps ou avant que l'équipe de gestion des incidents ne soit engagée. Les ingénieurs de gestion des incidents doivent collaborer avec les résolveurs que vous avez spécifiés dans le cadre du processus d'atténuation, et non agir en tant qu'intervenants de première ligne pour ensuite vous contacter.
+ Les seuils d'alarme doivent être fixés à un seuil et à une durée appropriés afin qu'une enquête soit menée chaque fois qu'une alarme se déclenche. Si une alarme passe de l'état « Alarme » à l'état « OK », l'impact est suffisant pour justifier la réponse et l'attention de l'opérateur.
**Types d'alarmes** :
+ Des alarmes qui indiquent le niveau d'impact sur l'entreprise et transmettent des informations pertinentes pour une détection simple des défauts.
+ CloudWatch Canaris d'Amazon. Pour plus d'informations, consultez [Canaries and X-Ray tracing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) et [X-Ray](https://aws.amazon.com/xray/).
+ Alarme agrégée (surveillance des dépendances)
Le tableau suivant fournit des exemples d'alarmes, toutes utilisant le système CloudWatch de surveillance.
****
| Nom de la métrique/Seuil d'alarme | ARN d'alarme ou ID de ressource | Si cette alarme se déclenche | Si vous êtes engagé, soumettez un dossier de Support Premium pour ces services |
| --- | --- | --- | --- |
| Erreurs d'API/ Nombre d'erreurs >= 10 pour 10 points de données | arn:aws:cloudwatch:us-west- 2:000000000000:Alarme : E2 Lambda Errors MPmim | Ticket retiré à l'équipe d'administration de base de données (DBA) | Lambda, API Gateway |
| ServiceUnavailable (Code d'état HTTP 503) Nombre d'erreurs >=3 pour 10 points de données (clients différents) dans une fenêtre de 5 minutes | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | Ticket réduit pour l'équipe de service | Lambda, API Gateway |
| ThrottlingException (Code d'état HTTP 400) Nombre d'erreurs >=3 pour 10 points de données (clients différents) dans une fenêtre de 5 minutes | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | Ticket réduit pour l'équipe de service | EC2, Amazon Aurora |
Pour en savoir plus, consultez [Surveillance et observabilité de la détection et de la réponse aux incidents AWS](observe-idr.md).
Si vous préférez utiliser des outils d'automatisation pour intégrer les alarmes, l'interface de ligne de commande (CLI) de détection et de réponse aux incidents vous aide à déployer et à intégrer vos alarmes. Pour en savoir plus, consultez [CLI AWS pour la détection et la réponse aux incidents](idr-cli.md).
**Principaux résultats :**
+ Définition et configuration des alarmes sur vos charges de travail.
+ Compléter les détails de l'alarme sur le questionnaire d'intégration.
**Topics**
+ [Créez des CloudWatch alarmes](idr-alarms-fit-purpose.md)
+ [Créez des CloudWatch alarmes à l'aide CloudFormation de modèles](idr-create-alarms-with-cfn.md)
+ [Exemples de cas d'utilisation pour les CloudWatch alarmes](idr-ex-alarm-use-cases.md)
# Créez des CloudWatch alarmes adaptées aux besoins de votre entreprise en matière de détection et de réponse aux incidents
Lorsque vous créez des CloudWatch alarmes Amazon, vous pouvez suivre plusieurs étapes pour vous assurer que vos alarmes répondent le mieux aux besoins de votre entreprise.
**Note**
Pour des exemples d' CloudWatch alarmes recommandées Services AWS pour intégrer la détection et la réponse aux incidents, consultez les [meilleures pratiques en matière d'alarme en matière de détection et de réponse aux incidents sur AWS re:Post](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr).
## Passez en revue vos CloudWatch alarmes proposées
Passez en revue les alarmes que vous proposez pour vous assurer qu'elles ne passent à l'état « Alarme » que lorsqu'elles ont un impact critique sur la charge de travail surveillée (perte de revenus ou dégradation de l'expérience client qui réduit considérablement les performances). Par exemple, considérez-vous que cette alarme est suffisamment critique pour que vous deviez réagir immédiatement si elle passe à l'état « Alarme » ?
Voici des indicateurs suggérés susceptibles d'avoir un impact commercial critique, par exemple en influant sur l'expérience de vos utilisateurs finaux avec une application :
+ **CloudFront:** pour plus d'informations, consultez la section [Affichage CloudFront et indicateurs des fonctions Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html).
+ **Équilibreurs de charge d'application :** il est recommandé de créer les alarmes suivantes pour les équilibreurs de charge d'application, si possible :
+ HTTPCode\$1ELB\$15xx\$1Count
+ HTTPCode\$1TARGET\$15XX\$1Count
Les alarmes précédentes vous permettent de surveiller les réponses des cibles situées derrière l'Application Load Balancer ou derrière d'autres ressources. Cela permet d'identifier plus facilement la source des erreurs 5XX. Pour plus d'informations, consultez [CloudWatch les métriques de votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ **Amazon API Gateway :** si vous utilisez une WebSocket API dans Elastic Beanstalk, pensez à utiliser les métriques suivantes :
+ Taux d'erreurs d'intégration (filtré à 5XX erreurs)
+ Latence d'intégration
+ Erreurs d'exécution
Pour plus d'informations, consultez la section [Surveillance de l'exécution des WebSocket API à l'aide de CloudWatch métriques](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html).
+ **Amazon Route 53 :** surveillez la **EndPointUnhealthyENICount**métrique. Cette métrique correspond au nombre d'interfaces réseau élastiques en état de **restauration automatique**. Cet état indique les tentatives du résolveur pour récupérer une ou plusieurs interfaces réseau Amazon Virtual Private Cloud associées au point de terminaison (spécifié par **EndpointId**). Au cours du processus de restauration, le terminal fonctionne avec une capacité limitée. Le point de terminaison ne peut pas traiter les requêtes DNS tant qu'il n'est pas complètement rétabli. Pour plus d'informations, consultez la section [Surveillance des points de terminaison Amazon Route 53 Resolver avec Amazon](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html). CloudWatch
## Validez les configurations de vos alarmes
Après avoir confirmé que les alarmes que vous proposez répondent aux besoins de votre entreprise, validez la configuration et l'historique des alarmes :
+ Validez le **seuil** pour que la métrique passe à l'état « Alarme » par rapport à la tendance graphique de la métrique.
+ Validez la **période** utilisée pour interroger les points de données. L'interrogation des points de données à 60 secondes permet de détecter rapidement les incidents.
+ Validez la **DatapointToAlarm**configuration. Dans la plupart des cas, il est recommandé de définir ce paramètre sur 3 ou 5 sur 5. En cas d'incident, l'alarme se déclenche au bout de 3 minutes lorsqu'elle est définie comme [métrique de 60 secondes avec 3 sur 3 DatapointToAlarm] ou 5 minutes si elle est définie comme [métrique de 60 secondes avec 5 sur 5 DatapointToAlarm]. Utilisez cette combinaison pour éliminer les alarmes bruyantes.
**Note**
Les recommandations précédentes peuvent varier en fonction de la manière dont vous utilisez un service. Chaque AWS service fonctionne différemment au sein d'une charge de travail. De plus, le même service peut fonctionner différemment lorsqu'il est utilisé à plusieurs endroits. Vous devez être sûr de comprendre comment votre charge de travail utilise les ressources qui alimentent l'alarme, ainsi que les effets en amont et en aval.
## Validez la façon dont vos alarmes gèrent les données manquantes
Certaines sources de mesures n'envoient pas de données CloudWatch à intervalles réguliers. Pour ces indicateurs, il est recommandé de traiter les données manquantes comme étant des données de type **NotBreaching**. Pour plus d'informations, voir [Configuration de la manière dont les CloudWatch alarmes traitent les données manquantes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) et [Éviter les transitions prématurées vers l'état d'alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition).
Par exemple, si une métrique surveille un taux d'erreur et qu'il n'y a aucune erreur, elle ne rapporte aucun point de données (zéro). Si vous configurez l'alarme pour traiter les données **manquantes comme manquantes**, un seul point de données en violation suivi de deux points de données nuls fait passer la métrique à l'état « Alarme » (pour 3 points de données sur 3). Cela est dû au fait que la configuration de données manquante évalue le dernier point de données connu au cours de la période d'évaluation.
Dans les cas où les métriques surveillent un taux d'erreur, en l'absence de dégradation du service, vous pouvez partir du principe que l'absence de données est une bonne chose. Il est recommandé de traiter les données manquantes comme des violations de type **NotBreaching** afin que les données manquantes soient considérées comme « OK » et que la métrique n'entre pas dans l'état « Alarme » sur un seul point de données.
## Consultez l'historique de chaque alarme
Si l'historique d'une alarme indique qu'elle passe fréquemment à l'état « Alarme » puis se rétablit rapidement, l'alarme peut devenir un problème pour vous. Assurez-vous de régler l'alarme pour éviter le bruit ou les fausses alarmes.
## Valider les métriques pour les ressources sous-jacentes
Assurez-vous que vos indicateurs portent sur des ressources sous-jacentes valides et utilisent les bonnes statistiques. Si une alarme est configurée pour vérifier les noms de ressources non valides, elle risque de ne pas être en mesure de suivre les données sous-jacentes. Cela peut faire passer l'alarme à l'état « Alarme ».
## Création d'alarmes composites
Si vous fournissez aux opérations de détection et de réponse aux incidents un grand nombre d'alarmes à intégrer, il se peut que l'on vous demande de créer des alarmes composites. Les alarmes composites réduisent le nombre total d'alarmes à intégrer.
# Créez des CloudWatch alarmes dans Incident Detection and Response à l'aide CloudFormation de modèles
Pour accélérer l'intégration à AWS Incident Detection and Response et pour réduire les efforts nécessaires à la création d'alarmes, vous AWS propose des CloudFormation modèles. Ces modèles incluent des paramètres d'alarme optimisés pour les services couramment intégrés, tels que Application Load Balancer, Network Load Balancer et Amazon. CloudFront
**Créez des CloudWatch alarmes à l'aide CloudFormation de modèles**
1. Téléchargez un modèle à l'aide des liens fournis :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/idr-create-alarms-with-cfn.html)
1. Vérifiez le fichier JSON téléchargé pour vous assurer qu'il est conforme aux processus opérationnels et de sécurité de votre organisation.
1. Créez une CloudFormation pile :
**Note**
Les étapes suivantes utilisent le processus de création de CloudFormation pile standard. Pour connaître les étapes détaillées, consultez [la section Création d'une pile sur la CloudFormation console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html).
1. Ouvrez la AWS CloudFormation console à l'adresse [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)
1. Sélectionnez **Créer la pile**.
1. Choisissez **Le modèle est prêt**, puis téléchargez le fichier modèle depuis votre dossier local.
Voici un exemple de l'écran **Create stack**.
![\[Exemple de fichier modèle de création de stack upload\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/create-cfn-stack1.png)
1. Choisissez **Suivant**.
1. Saisissez les informations requises suivantes :
+ **AlarmNameConfig**et **AlarmDescriptionConfig**: Entrez le nom et la description de votre alarme.
+ **ThresholdConfig**: Révisez la valeur du seuil pour répondre aux exigences de votre application.
+ **Distribution IDConfig** : assurez-vous que l'ID de distribution pointe vers les bonnes ressources du compte dans lequel vous créez la CloudFormation pile.
1. Choisissez **Suivant**.
1. Vérifiez les valeurs par défaut dans les **DatapointsToAlarmConfig**champs **PeriodConfig**EvalutionPeriodConfig****, et. Il est recommandé d'utiliser les valeurs par défaut pour ces champs. Vous pouvez apporter des modifications, si nécessaire, pour répondre aux exigences de votre application.
1. Entrez éventuellement des balises et des informations de notification SNS selon les besoins. Il est recommandé d'activer la **protection de terminaison** pour empêcher la suppression accidentelle de l'alarme. Pour activer la protection contre le licenciement, sélectionnez le bouton radio **Activé**, comme indiqué dans l'exemple suivant :
![\[Exemple de protection contre les terminaisons Create Stack Activate\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/create-cfn-stack2.png)
1. Choisissez **Suivant**.
1. Vérifiez les paramètres de votre pile, puis choisissez **Create stack**.
1. Après avoir créé la pile, l'alarme apparaît dans la liste Amazon CloudWatch **Alarm**, comme illustré dans l'exemple suivant :
![\[Exemple de liste CloudWatch d'alarmes\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/create-cfn-stack3.png)
1. Une fois que vous avez créé toutes vos alarmes dans le compte et la AWS région appropriés, informez-en votre responsable de compte technique (TAM). L'équipe de détection et de réponse aux incidents d'AWS examine l'état de vos nouvelles alarmes, puis poursuit votre intégration.
# Exemples de cas d'utilisation des CloudWatch alarmes dans le cadre de la détection et de la réponse aux incidents
Les cas d'utilisation suivants fournissent des exemples d'utilisation des CloudWatch alarmes Amazon dans le cadre de la détection et de la réponse aux incidents. Ces exemples montrent comment les CloudWatch alarmes peuvent être configurées pour surveiller les indicateurs et les seuils clés de différents AWS services, ce qui vous permet d'identifier et de résoudre les problèmes potentiels susceptibles d'avoir un impact sur la disponibilité et les performances de vos applications et de vos charges de travail.
## Exemple de cas d'utilisation A : Application Load Balancer
Vous pouvez créer l' CloudWatch alarme suivante pour signaler un impact potentiel sur la charge de travail. Pour ce faire, vous créez une métrique mathématique qui émet des alarmes lorsque les connexions réussies tombent en dessous d'un certain seuil. Pour les CloudWatch métriques disponibles, consultez les [CloudWatch métriques de votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)
**Métrique :** `HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`
**NameSpace: AWS/Application** ELB
**ComparisonOperator(Seuil) :** inférieur à x (x = seuil du client).
**Période :** 60 secondes
**DatapointsToAlarm:** 3 sur 3
**Traitement des données manquantes : considérez** les données manquantes comme des [violations.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)
**Statistique :** somme
Le schéma suivant montre le flux pour le cas d'utilisation A :
![\[Exemple de cas d'utilisation d'Application Load Balancer\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/UseCaseAALB.png)
## Exemple de cas d'utilisation B : Amazon API Gateway
Vous pouvez créer l' CloudWatch alarme suivante pour signaler un impact potentiel sur la charge de travail. Pour ce faire, vous créez une métrique composite qui émet une alarme en cas de latence élevée ou d'un nombre moyen élevé d'erreurs 4XX dans l'API Gateway. Pour les statistiques disponibles, consultez les [dimensions et statistiques d'Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)
**Métrique :** `compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`
**NameSpace: AWS Passerelle** /API
**ComparisonOperator(Seuil) :** supérieur aux seuils (x ou y du client)
**Période :** 60 secondes
**DatapointsToAlarm:** 1 sur 1
**Traitement des données manquantes : considérez** les données manquantes comme s'il ne s'[agissait pas d'une violation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data).
**Statistique :**
Le schéma suivant montre le flux pour le cas d'utilisation B :
![\[Exemple de cas d'utilisation d'API Gateway\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/UseCaseBAPIGW.png)
## Exemple de cas d'utilisation C : Amazon Route 53
Vous pouvez surveiller vos ressources en créant des bilans de santé Route 53 qui permettent de collecter et CloudWatch de traiter les données brutes pour en faire des indicateurs lisibles en temps quasi réel. Vous pouvez créer l' CloudWatch alarme suivante pour signaler un impact potentiel sur la charge de travail. Vous pouvez utiliser les CloudWatch métriques pour créer une alarme qui se déclenche lorsqu'elle dépasse le seuil établi. Pour les CloudWatch métriques disponibles, consultez les [CloudWatch métriques relatives aux bilans de santé de Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)
**Métrique :** `R53-HC-Success`
**NameSpace:** AWS/Route 53
**Seuil HealthCheckStatus :** HealthCheckStatus < x pour 3 points de données en 3 minutes (étant le seuil de x pour le client)
**Durée :** 1 minute
**DatapointsToAlarm:** 3 sur 3
**Traitement des données manquantes : considérez** les données manquantes comme des [violations.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)
**Statistique :** minimum
Le schéma suivant montre le flux pour le cas d'utilisation C :
![\[Exemple de cas d'utilisation pour Route 53\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/UseCaseCR53.png)
## Exemple de cas d'utilisation D : surveiller une charge de travail avec une application personnalisée
Il est essentiel que vous preniez le temps de définir un bilan de santé approprié dans ce scénario. Si vous vérifiez uniquement que le port d'une application est ouvert, cela signifie que vous n'avez pas vérifié que l'application fonctionne. De plus, appeler la page d'accueil d'une application n'est pas nécessairement la bonne méthode pour déterminer si l'application fonctionne. Par exemple, si une application dépend à la fois d'une base de données et d'Amazon Simple Storage Service (Amazon S3), le bilan de santé doit valider tous les éléments. Pour ce faire, vous pouvez créer une page Web de surveillance, telle que **/monitor**. La page Web de surveillance appelle la base de données pour s'assurer qu'elle peut se connecter et obtenir des données. De plus, la page Web de surveillance appelle Amazon S3. Ensuite, vous pointez le contrôle de santé de l'équilibreur de charge vers la page **/monitor.**
Le schéma suivant montre le flux pour le cas d'utilisation D :
![\[Exemple de cas d'utilisation pour la surveillance à l'aide d'une application personnalisée\]](http://docs.aws.amazon.com/fr_fr/IDR/latest/userguide/images/CustomAlarm.png)