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.
# Alerte
Les alertes sont l'une des sources d'informations les plus importantes en matière de sécurité, de disponibilité, de performance et de fiabilité de votre infrastructure informatique et de vos services informatiques. Ils notifient et informent vos équipes informatiques des menaces de sécurité continues, des pannes, des problèmes de performance ou des défaillances du système.
La bibliothèque d'infrastructure informatique (ITIL), en particulier les pratiques de gestion des services informatiques (ITSM), place les alertes automatisées au centre des meilleures pratiques de surveillance, de gestion des événements et de gestion des incidents.
L'alerte en cas d'incident se produit lorsque les outils de surveillance génèrent des alertes pour informer votre équipe et les outils automatisés (pour les éléments automatiquement exploitables) des modifications, des actions à haut risque ou des défaillances de l'environnement informatique. Les alertes informatiques constituent la première ligne de défense contre les pannes ou les modifications du système susceptibles de se transformer en incidents majeurs. En surveillant automatiquement les systèmes et en générant des alertes en cas de panne et de modifications risquées, les équipes informatiques peuvent minimiser les temps d'arrêt et réduire les coûts élevés qui en découlent.
[En tant que meilleures pratiques, le AWS Well-Architected Framework prescrit que [vous utilisiez la surveillance pour générer des notifications basées sur des alarmes, et que vous](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_monitor_instances_post_launch_generate_alarms.html) surveilliez et alertiez de manière proactive.](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_monitor_instances_post_launch_proactive.html) Utilisez un service de surveillance tiers CloudWatch ou utilisez un service de surveillance tiers pour définir des alarmes indiquant lorsque les mesures dépassent les limites attendues.
L'objectif de la gestion des alertes est d'établir des procédures efficaces et standardisées pour gérer les événements et incidents liés à l'informatique par le biais de la journalisation, de la classification, de la définition et de la mise en œuvre des actions, de la clôture et des activités d'examen post-incident.
**Sections**
+ [CloudWatch alarmes](cloudwatch-alarms.md)
+ [EventBridge règles](eventbridge-rules.md)
+ [Spécification des actions, activation et désactivation des alarmes](enable-disable-alarms.md)
# CloudWatch alarmes
Lorsque vous utilisez vos instances de base de données Amazon RDS, vous souhaitez surveiller et générer des alertes sur différents types de métriques, d'événements et de traces. Pour les bases de données MySQL et [MariaDB, les principales sources d'informations sont les métriques des instances](db-instance-monitoring.md) de base de données, les métriques du système d'[exploitation,](os-monitoring.md) les [événements, les journaux](events-logs-audit.md) et les pistes d'audit. Nous vous recommandons d'utiliser des [CloudWatch alarmes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) pour surveiller une seule métrique sur une période que vous spécifiez.
L'exemple suivant montre comment définir une alarme qui surveille la `CPUUtilization` métrique (pourcentage d'utilisation du processeur) sur toutes vos instances de base de données Amazon RDS. Vous configurez l'alarme pour qu'elle soit déclenchée si l'utilisation du processeur sur une instance de base de données est supérieure à 80 % pendant la période d'évaluation de 5 minutes.
![\[Régler une alarme pour la CPUUtilization métrique\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/setting-alarm.png)
Cela signifie que l'alarme passe à l'`ALARM`état si l'une de vos bases de données connaît une utilisation élevée du processeur (plus de 80 %) pendant 5 minutes ou plus. L'alarme reste active si `OK` le processeur atteint parfois un taux d'utilisation supérieur à 80 % pendant une courte période, puis retombe en dessous du seuil. Le graphique suivant illustre cette logique.
![\[États et seuils d'alarme\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/thresholds.png)
CloudWatch les alarmes prennent en charge les alarmes métriques et composites.
+ Une *alarme métrique* surveille une seule CloudWatch métrique et peut exécuter des expressions mathématiques sur la métrique. Une alarme métrique peut envoyer des messages Amazon SNS, qui, à leur tour, peuvent effectuer une ou plusieurs actions en fonction de la valeur de la métrique par rapport à un seuil donné sur un certain nombre de périodes.
+ Une *alarme composite* est basée sur une expression de règle, qui évalue l'état de plusieurs alarmes et passe à l'`ALARM`état uniquement si toutes les conditions de la règle sont remplies. Les alarmes composites sont généralement utilisées pour réduire le nombre d'alertes inutiles. Par exemple, vous pouvez avoir une alarme composite contenant plusieurs alarmes métriques configurées pour ne jamais effectuer d'actions. L'alarme composite enverrait une alerte lorsque toutes les alarmes métriques individuelles de l'alarme composite se trouvent déjà dans le `ALARM`
CloudWatch les alarmes ne peuvent surveiller que CloudWatch les métriques. Si vous souhaitez créer une alarme en fonction des erreurs, des requêtes lentes ou des journaux généraux, vous devez créer des CloudWatch métriques à partir de ces journaux. Vous pouvez y parvenir, comme indiqué précédemment dans les sections [Surveillance du système d'exploitation](os-monitoring.md) et [Événements, journaux et pistes d'audit](events-logs-audit.md), en utilisant des filtres pour [créer des métriques à partir des événements du journal](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html). De même, pour être alerté sur les métriques de surveillance améliorée, vous devez créer des filtres CloudWatch de métriques dans CloudWatch Logs.
# EventBridge règles
Les [événements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) sont transmis à Amazon EventBridge, et vous pouvez utiliser des [EventBridge règles](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) pour réagir à ces événements. Par exemple, vous pouvez créer des EventBridge règles qui vous avertiront et effectueront une action si une instance de base de données spécifique s'arrête ou démarre, comme le montre l'écran suivant.
![\[EventBridge règles pour les arrêts et démarrages des instances de base de données\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/eventbridge-rules.png)
La règle qui détecte l'`The DB instance has been stopped`événement possède l'ID `RDS-EVENT-0087` d'événement Amazon RDS. Vous définissez donc la `Event Pattern` propriété de la règle comme suit :
```
{
"source": ["aws.rds"],
"detail-type": ["RDS DB Instance Event"],
"detail": {
"SourceArn": ["arn:aws:rds:eu-west-3:111122223333:db:database-3"],
"EventID": ["RDS-EVENT-0087"]
}
}
```
Cette règle surveille `database-3` uniquement l'instance de base de données et surveille l'`RDS-EVENT-0087`événement. Lorsqu'il EventBridge détecte l'événement, il l'envoie à une ressource ou à un point de terminaison, appelé [cible](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html). C'est ici que vous pouvez spécifier l'action que vous souhaitez effectuer si l'instance Amazon RDS s'arrête. Vous pouvez envoyer l'événement à de nombreuses cibles possibles, notamment un sujet SNS, une file d'attente Amazon Simple Queue Service (Amazon SQS), une AWS Lambda fonction, AWS Systems Manager Automation, une tâche, Amazon AWS Batch API Gateway, etc. Par exemple, vous pouvez créer une rubrique SNS qui enverra un e-mail de notification et un SMS, et affecter cette rubrique SNS comme cible de la EventBridge règle. Si l'instance de base de données Amazon RDS `database-3` a été arrêtée, Amazon RDS envoie l'événement `RDS-EVENT-0087` à EventBridge l'endroit où il est détecté. EventBridge appelle ensuite la cible, qui est le sujet SNS. La rubrique SNS est configurée pour envoyer un e-mail (comme indiqué dans l'illustration suivante) et un SMS.
![\[Configuration des rubriques SNS\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/sns-notification.png)
# Spécification des actions, activation et désactivation des alarmes
Vous pouvez utiliser une CloudWatch alarme pour spécifier les actions que l'alarme doit effectuer lorsqu'elle passe de l'`ALARM`état`OK`, à. `INSUFFICIENT_DATA` CloudWatch intègre des rubriques SNS et plusieurs catégories d'actions supplémentaires qui ne sont pas applicables aux métriques Amazon RDS, telles que les actions Amazon Elastic Compute Cloud (Amazon EC2) ou les actions de groupe Amazon EC2 Auto Scaling. EventBridge est généralement utilisé pour écrire des règles et définir des cibles qui prennent des mesures lorsque l'alarme est déclenchée pour les métriques Amazon RDS. CloudWatch envoie des événements à EventBridge chaque fois qu'une CloudWatch alarme change d'état. Vous pouvez utiliser ces événements de changement d'état d'alarme pour déclencher une cible d'événement EventBridge. Pour plus d'informations, consultez la section [Événements d'alarme et EventBridge](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html) la CloudWatch documentation.
Vous devrez peut-être également gérer les alarmes, par exemple pour désactiver automatiquement une alarme lors de modifications de configuration planifiées ou de tests, puis réactiver l'alarme lorsque l'action planifiée est terminée. Par exemple, si vous avez une mise à niveau planifiée du logiciel de base de données qui nécessite une interruption de service et que des alarmes seront activées en cas d'indisponibilité de la base de données, vous pouvez désactiver et activer les alarmes à l'aide des actions [DisableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DisableAlarmActions.html)de l'API et/ou des [enable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/enable-alarm-actions.html)commandes [disable-alarm-actions](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/disable-alarm-actions.html)et du AWS CLI. [EnableAlarmActions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_EnableAlarmActions.html) Vous pouvez également consulter l'historique de l'alarme sur la CloudWatch console ou en utilisant l'action [DescribeAlarmHistory](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarmHistory.html)API ou la [describe-alarm-history](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarm-history.html)commande du AWS CLI. CloudWatch conserve l'historique des alarmes pendant deux semaines. Sur la CloudWatch console, vous pouvez choisir le menu **Favoris et récents** dans le volet de navigation pour définir et accéder à vos alarmes préférées et aux alertes les plus récentes.