Utilisation des CloudWatch alarmes Amazon - Amazon CloudWatch

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.

Utilisation des CloudWatch alarmes Amazon

Vous pouvez créer des alarmes métriques et composites dans Amazon CloudWatch.

  • Une alarme métrique surveille une seule CloudWatch métrique ou le résultat d'une expression mathématique basée sur CloudWatch des métriques. L’alarme réalise une ou plusieurs actions en fonction de la valeur de la métrique ou de l'expression par rapport à un seuil sur un certain nombre de périodes. L'action peut consister à envoyer une notification à une rubrique Amazon SNS, à exécuter une action Amazon EC2 ou Amazon EC2 Auto Scaling, ou à créer un OpsItem incident ou dans Systems Manager.

  • Une alerte composite contient une expression de règle qui prend en compte les états d'alerte des autres alertes que vous avez créées. L'alerte composite passe à l'état ALARM uniquement si toutes les conditions de la règle sont remplies. Les alertes spécifiées dans l'expression de règle d'alerte composite peuvent inclure des alertes de métrique et d'autres alertes composites.

    L'utilisation d'alertes composites peut réduire le bruit d'alerte. Vous pouvez créer plusieurs alertes de métrique, mais aussi créer une alerte composite et configurer des alertes uniquement pour l'alerte composite. Par exemple, un composite peut passer à l'état ALARM uniquement lorsque toutes les alertes de métrique sous-jacentes sont à l'état ALARM.

    Les alarmes composites peuvent envoyer des notifications Amazon SNS lorsqu'elles changent d'état, et peuvent créer des Systems Manager OpsItems ou des incidents lorsqu'elles passent en état ALARM, mais ne peuvent pas effectuer d'actions EC2 ou d'actions Auto Scaling.

Note

Vous pouvez créer autant d'alarmes que vous le souhaitez dans votre AWS compte.

Vous pouvez ajouter des alarmes aux tableaux de bord afin de surveiller et de recevoir des alertes concernant vos AWS ressources et applications dans plusieurs régions. Une fois que vous avez ajouté une alerte à un tableau de bord, elle devient grise lorsque son état est INSUFFICIENT_DATA, et elle devient rouge quand son état est ALARM. L'alerte n'a pas de couleur lorsqu'elle se trouve à l'état OK.

Vous pouvez également ajouter aux favoris les alarmes récemment visitées à l'aide de l'option Favoris et récents du volet de navigation de la CloudWatch console. L'option Favorites and recents (Favoris et récents) se compose de deux colonnes pour vos alertes favorites et les alertes que vous avez récemment consultées.

Une alerte appelle des actions uniquement lorsque l'état de l'alerte change. L'exception concerne les alertes avec des actions Auto Scaling. Dans le cas d'actions Auto Scaling, l'alerte continue d'appeler l'action une fois par minute pendant laquelle elle reste dans le nouvel état.

Une alerte peut surveiller une métrique dans le même compte. Si vous avez activé la fonctionnalité multi-comptes sur votre CloudWatch console, vous pouvez également créer des alarmes qui surveillent les statistiques d'autres AWS comptes. La création d'alertes composites entre comptes n'est pas prise en charge. La création d'alertes croisées qui utilisent des expressions mathématiques est prise en charge, sauf que les fonctions ANOMALY_DETECTION_BAND, INSIGHT_RULE, et SERVICE_QUOTA ne sont pas prises en charge pour les alertes de compte croisé.

Note

CloudWatch ne teste ni ne valide les actions que vous spécifiez, et ne détecte aucune erreur Amazon EC2 Auto Scaling ou Amazon SNS résultant d'une tentative d'appel d'actions inexistantes. Vérifiez que vos actions d'alerte existent.

États d'alerte de métrique

Une alerte de métrique peut avoir les états suivants :

  • OK – La métrique ou l'expression se trouve dans le seuil défini.

  • ALARM – La métrique ou l'expression se trouve à l'extérieur du seuil défini.

  • INSUFFICIENT_DATA – L'alerte vient de commencer, la métrique n'est pas disponible, ou la quantité de données n'est pas suffisante pour permettre à la métrique de déterminer le statut de l'alerte.

Évaluation d'une alerte

Lorsque vous créez une alarme, vous spécifiez trois paramètres à activer pour évaluer CloudWatch à quel moment il convient de modifier l'état de l'alarme :

  • La Période est la durée nécessaire pour évaluer la métrique ou l'expression afin de créer chaque point de données pour une alerte. Elle est exprimée en secondes.

  • Evaluation Periods (Périodes d'évaluation) est le nombre de périodes, ou de points de données, les plus récents à évaluer pour déterminer l'état de l'alerte.

  • Datapoints to Alarm (Points de données avant l'alerte) est le nombre de points de données pendant les périodes d'évaluation qui doit être dépassé pour que l'alerte passe à l'état ALARM. Les points de données au-delà du seuil n'ont pas besoin d'être consécutifs, mais ils doivent simplement tous correspondre au dernier nombre de points de données correspondant à la valeur Evaluation Period (Période d'évaluation).

Pour toute période d'une minute ou plus, une alerte est évaluée toutes les minutes et l'évaluation est basée sur la fenêtre de temps définie par la Période et les Périodes d'évaluation. Par exemple, si la Période est de 5 minutes (300 secondes) et que les Périodes d'évaluation sont de 1, alors à la fin de la cinquième minute, l'alerte est évaluée en fonction des données des minutes 1 à 5. Ensuite, à la fin de la minute 6, l'alerte est évaluée en fonction des données des minutes 2 à 6.

Si la durée de l'alerte est de 10 secondes ou 30 secondes, l'alerte est évaluée toutes les 10 secondes.

Dans la figure suivante, le seuil d'alerte d'une alerte de métrique est défini sur trois unités. Evaluation Period (Période d'évaluation) et Datapoints to Alarm (Points de données à l'alerte)sont définis sur 3. Cela signifie que lorsque les trois points de données des trois périodes consécutives les plus récentes sont au-dessus du seuil, l'alerte passe à l'état ALARM. Dans le schéma, cela se produit entre la troisième et la cinquième période. À la sixième période, la valeur repasse sous le seuil. L'une des périodes évaluées n'est donc pas en dépassement et l'état de l'alerte revient à l'état OK. Au cours de la neuvième période, le seuil est dépassé à nouveau, mais pendant une seule période. Par conséquent, le statut de l'alerte reste OK.


        alerte de déclenchement du seuil d'alerte

Lorsque vous configurez différentes valeurs pour Evaluation Periods (Périodes d'évaluation) et Datapoints to Alarm (Points de données avant l'alerte), vous définissez une alerte « M sur N ». Datapoints à Alarm (Points de données avant l'alerte) est (« M ») et Evaluation Periods (Périodes d'évaluation) est (« N »). L'intervalle d'évaluation correspond au nombre de périodes d'évaluation multiplié par la durée de la période. Par exemple, si vous configurez 4 points de données sur 5 avec une période de 1 minute, l'intervalle d'évaluation est de 5 minutes. Si vous configurez 3 points de données sur 3 avec une période de 10 minutes, l'intervalle d'évaluation est de 30 minutes.

Note

Si des points de données sont manquants peu après la création d'une alarme et que la métrique a été signalée CloudWatch avant que vous ne créiez l'alarme, CloudWatch récupère les points de données les plus récents avant la création de l'alarme lors de l'évaluation de l'alarme.

Actions d'alerte

Vous pouvez spécifier les actions d'une alerte lorsqu'elle change d'état entre les états OK, ALARM et INSUFFICIENT_DATA.

La plupart des actions peuvent être définies pour la transition vers chacun des trois états. À l'exception des actions Auto Scaling, elles se produisent uniquement lors des transitions d'état et ne sont pas exécutées à nouveau si la condition persiste pendant plusieurs heures ou jours. Vous pouvez utiliser le fait que plusieurs actions sont autorisées pour qu'une alerte envoie un e-mail lorsqu'un seuil est dépassé, puis un autre lorsque la condition de dépassement prend fin. Cela vous permet de vérifier que vos actions de mise à l'échelle ou de récupération sont déclenchées au moment prévu et fonctionnent comme vous le souhaitez.

Les actions d’alarme suivantes sont prises en charge.

Actions d’alarme Lambda

CloudWatch alarm garantit un appel asynchrone de la fonction Lambda pour un changement d'état donné, sauf dans les cas suivants :

  • Lorsque la fonction n'existe pas.

  • When n' CloudWatch est pas autorisé à invoquer la fonction Lambda.

Si CloudWatch vous ne parvenez pas à joindre le service Lambda ou si le message est rejeté pour une autre raison, CloudWatch réessayez jusqu'à ce que l'appel aboutisse. Lambda met le message en file d'attente et gère les nouvelles tentatives d'exécution. Pour plus d'informations sur ce modèle d'exécution, notamment sur la manière dont Lambda gère les erreurs, consultez la section Invocation asynchrone dans le guide du développeur. AWS Lambda

Vous pouvez appeler une fonction Lambda dans le même compte ou dans d'autres AWS comptes.

Lorsque vous spécifiez une alarme pour invoquer une fonction Lambda en tant qu’action d’alarme, vous pouvez choisir de spécifier le nom de la fonction, son alias ou une version spécifique d’une fonction.

Lorsque vous spécifiez une fonction Lambda comme action d'alarme, vous devez créer une politique de ressources pour la fonction afin de permettre au principal du CloudWatch service d'invoquer la fonction.

Pour ce faire, vous pouvez utiliser le AWS CLI, comme dans l'exemple suivant :

aws lambda add-permission \ --function-name my-function-name \ --statement-id AlarmAction \ --action 'lambda:InvokeFunction' \ --principal lambda.alarms.cloudwatch.amazonaws.com \ --source-account 111122223333 \ --source-arn arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name

Vous pouvez également créer une politique similaire à l’un des exemples suivants, puis l’attribuer à la fonction.

L’exemple suivant spécifie sur quel compte se trouve l’alarme, de sorte que seules les alarmes de ce compte (111122223333) peuvent invoquer la fonction.

{ "Version": "2012-10-17", "Id": "default", "Statement": [{ "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333" } } }] }

L’exemple suivant a un champ d’application plus restreint, ne permettant qu’à l’alarme spécifiée dans le compte indiqué d’invoquer la fonction.

{ "Version": "2012-10-17", "Id": "default", "Statement": [ { "Sid": "AlarmAction", "Effect": "Allow", "Principal": { "Service": "lambda.alarms.cloudwatch.amazonaws.com" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:444455556666:function:function-name", "Condition": { "StringEquals": { "AWS:SourceAccount": "111122223333", "AWS:SourceArn": "arn:aws:cloudwatch:us-east-1:111122223333:alarm:alarm-name" } } }] }

Nous ne recommandons pas la création d’une politique ne spécifiant aucun compte source, car ce type de politique est vulnérable aux problèmes d’adjoints confus.

Objet d'événement envoyé depuis CloudWatch Lambda

Lorsque vous configurez une fonction Lambda en tant qu'action d'alarme, CloudWatch fournit une charge utile JSON à la fonction Lambda lorsqu'elle l'appelle. Cette charge utile JSON sert d’objet d’événement pour la fonction. Vous pouvez extraire des données de cet objet JSON et les utiliser dans votre fonction. Voici un exemple d’objet d’événement provenant d’une alarme de métrique.

{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:444455556666:alarm:lambda-demo-metric-alarm', 'accountId': '444455556666', 'time': '2023-08-04T12:36:15.490+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'lambda-demo-metric-alarm', 'state': { 'value': 'ALARM', 'reason': 'test', 'timestamp': '2023-08-04T12:36:15.490+0000' }, 'previousState': { 'value': 'INSUFFICIENT_DATA', 'reason': 'Insufficient Data: 5 datapoints were unknown.', 'reasonData': '{"version":"1.0","queryDate":"2023-08-04T12:31:29.591+0000","statistic":"Average","period":60,"recentDatapoints":[],"threshold":5.0,"evaluatedDatapoints":[{"timestamp":"2023-08-04T12:30:00.000+0000"},{"timestamp":"2023-08-04T12:29:00.000+0000"},{"timestamp":"2023-08-04T12:28:00.000+0000"},{"timestamp":"2023-08-04T12:27:00.000+0000"},{"timestamp":"2023-08-04T12:26:00.000+0000"}]}', 'timestamp': '2023-08-04T12:31:29.595+0000' }, 'configuration': { 'description': 'Metric Alarm to test Lambda actions', 'metrics': [ { 'id': '1234e046-06f0-a3da-9534-EXAMPLEe4c', 'metricStat': { 'metric': { 'namespace': 'AWS/Logs', 'name': 'CallCount', 'dimensions': { 'InstanceId': 'i-12345678' } }, 'period': 60, 'stat': 'Average', 'unit': 'Percent' }, 'returnData': True } ] } } }

Voici un exemple d’objet d’événement provenant d’une alarme composite.

{ 'source': 'aws.cloudwatch', 'alarmArn': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:SuppressionDemo.Main', 'accountId': '111122223333', 'time': '2023-08-04T12:56:46.138+0000', 'region': 'us-east-1', 'alarmData': { 'alarmName': 'CompositeDemo.Main', 'state': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:56:46.138+0000' }, 'previousState': { 'value': 'ALARM', 'reason': 'arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild transitioned to ALARM at Friday 04 August, 2023 12:54:46 UTC', 'reasonData': '{"triggeringAlarms":[{"arn":"arn:aws:cloudwatch:us-east-1:111122223333:alarm:CompositeDemo.FirstChild","state":{"value":"ALARM","timestamp":"2023-08-04T12:54:46.138+0000"}}]}', 'timestamp': '2023-08-04T12:54:46.138+0000', 'actionsSuppressedBy': 'WaitPeriod', 'actionsSuppressedReason': 'Actions suppressed by WaitPeriod' }, 'configuration': { 'alarmRule': 'ALARM(CompositeDemo.FirstChild) OR ALARM(CompositeDemo.SecondChild)', 'actionsSuppressor': 'CompositeDemo.ActionsSuppressor', 'actionsSuppressorWaitPeriod': 120, 'actionsSuppressorExtensionPeriod': 180 } } }

Configuration de la façon dont les CloudWatch alarmes traitent les données manquantes

Parfois, tous les points de données attendus pour une métrique ne sont pas signalés CloudWatch. Cela peut par exemple se produire lorsqu'une connexion est perdue, lorsqu'un serveur tombe en panne ou lorsqu'une métrique, de par sa conception, rapporte les données de façon intermittente uniquement.

CloudWatch vous permet de spécifier comment traiter les points de données manquants lors de l'évaluation d'une alarme. Cela vous aide à configurer votre alerte afin qu'elle passe à l'état ALARM uniquement lorsque cela s'avère approprié pour le type de données surveillées. Vous pouvez éviter les faux positifs lorsque les données manquantes n'indiquent pas de problème.

De la même manière que chaque alarme est toujours dans l'un des trois états suivants, chaque point de données spécifique signalé CloudWatch appartient à l'une des trois catégories suivantes :

  • Non dépassé (seuil respecté)

  • Dépassé (au-delà du seuil)

  • Manquant

Pour chaque alarme, vous pouvez spécifier CloudWatch de traiter les points de données manquants comme suit :

  • notBreaching : les points de données manquants sont traités comme étant corrects et dans les limites du seuil

  • breaching : les points de données manquants sont traités comme étant incorrects au-delà du seuil

  • ignore : l'état de l'alerte actuel est conservé

  • missing : si tous les points de données de la plage d'évaluation des alertes sont manquants, l'alerte passe à INSUFFICIENT_DATA.

Le choix le plus adapté dépend du type de métrique. Dans le cas d'une métrique qui relève des données en continu, par exemple la métrique CPUUtilization d'une instance, vous pouvez traiter les points de données manquants comme breaching, car ils peuvent indiquer un problème. En revanche, dans le cas d'une métrique qui génère des points de données uniquement en cas d'erreur, par exemple la métrique ThrottledRequests dans Amazon DynamoDB, vous traiteriez plutôt les données manquantes comme étant notBreaching. Le comportement par défaut est missing.

Choisir la meilleure option pour votre alerte permet d'éviter des changements de condition d'alerte superflus et trompeurs, mais également de fournir une indication plus précise de l'état du système.

Important

Les alertes qui évaluent les métriques dans l'espace de noms AWS/DynamoDB ignorent toujours les données manquantes, même si vous choisissez une option différente pour le traitement des données manquantes par l'alerte. Lorsqu'une métrique AWS/DynamoDB contient des données manquantes, les alertes qui évaluent cette métrique restent dans leur état actuel.

Évaluation de l'état de l'alerte lorsqu'il manque des données

Chaque fois qu'une alarme évalue s'il faut changer d'état, CloudWatch tente de récupérer un nombre de points de données supérieur au nombre spécifié comme périodes d'évaluation. Le nombre de points de données exact qu'il tente de récupérer dépend de la longueur de la période d'alerte et du fait qu'elle est ou non basée sur une métrique avec une résolution standard ou une haute résolution. La période des points de données qu'il tente de récupérer est la plage d'évaluation.

Une fois ces CloudWatch points de données récupérés, voici ce qui se passe :

  • S'il ne manque aucun point de données dans la plage d'évaluation, CloudWatch évalue l'alarme en fonction des points de données les plus récents collectés. Le nombre de points de données évalués est égal aux Evaluation Periods (Périodes d'évaluation) pour l'alerte. Les points de données supplémentaires situés plus loin dans la plage d'évaluation ne sont pas nécessaires et sont ignorés.

  • Si certains points de données de la plage d'évaluation sont manquants, mais que le nombre total de points de données existants qui ont été extraits avec succès de la plage d'évaluation est égal ou supérieur aux périodes d'évaluation de l'alarme, CloudWatch évalue l'état de l'alarme en fonction des points de données réels les plus récents qui ont été récupérés avec succès, y compris les points de données supplémentaires nécessaires situés plus loin dans la plage d'évaluation. Dans ce cas, la valeur que vous avez définie pour traiter les données manquantes n'est pas nécessaire et est ignorée.

  • Si certains points de données de la plage d'évaluation sont manquants et que le nombre de points de données réels récupérés est inférieur au nombre de périodes d'évaluation de l'alarme, complétez CloudWatch les points de données manquants avec le résultat que vous avez spécifié sur la manière de traiter les données manquantes, puis évalue l'alarme. Cependant, tous les points de données réels de la plage d'évaluation sont inclus dans l'évaluation. CloudWatch n'utilise les points de données manquants que le moins de fois possible.

Note

Un cas particulier de ce comportement est que les CloudWatch alarmes peuvent réévaluer à plusieurs reprises le dernier ensemble de points de données pendant un certain temps après l'arrêt du flux de la métrique. Cette réévaluation peut entraîner l'alerte à changer d'état et à réexécuter des actions, si le changement d'état est survenu immédiatement avant que le flux de la métrique ne soit interrompu. Pour atténuer ce comportement, utilisez des périodes plus courtes.

Les tableaux suivants illustrent des exemples du comportement d'évaluation de l'alerte. Dans le premier tableau, les points de données relatifs aux périodes d'alarme et d'évaluation sont tous deux égaux à 3. CloudWatch récupère les 5 points de données les plus récents lors de l'évaluation de l'alarme, au cas où certains des 3 points de données les plus récents seraient manquants. 5 est la plage d'évaluation de l'alarme.

La colonne 1 montre les 5 points de données les plus récents, car la plage d'évaluation est 5. Ces points de données sont affichés avec le point de données le plus récent sur la droite. 0 est un point de données en-deçà du seuil, X est un point de données au-delà du seuil et - est un point de données manquant.

La deuxième colonne indique combien des 3 points de données nécessaires sont absents. Même si les 5 points de données les plus récents sont évalués, seuls 3 d'entre eux (le paramètre pour les Périodes d'évaluation) sont nécessaires pour évaluer l'état de l'alerte. Le nombre de points de données dans la deuxième colonne est le nombre de points de données qui doivent être « renseignés » à l'aide du paramètre pour la façon dont les données manquantes sont traitées.

Dans les colonnes 3 à 6, les en-têtes de colonne sont les valeurs possibles pour la façon de traiter les données manquantes. Les lignes de ces colonnes indiquent l'état d'alerte défini pour chacune de ces méthodes possibles de traitement des données manquantes.

Points de données Nombre de points de données qui doivent être remplis MANQUANT IGNORER AU-DELÀ DU SEUIL EN-DEÇÀ DU SEUIL

0 - X - X

0

OK

OK

OK

OK

- - - - 0

2

OK

OK

OK

OK

- - - - -

3

INSUFFICIENT_DATA

Conserver l'état actuel

ALARM

OK

0 X X - X

0

ALARM

ALARM

ALARM

ALARM

- - X - -

2

ALARM

Conserver l'état actuel

ALARM

OK

Dans la deuxième ligne du tableau précédent, l'alerte reste OK, même si les données manquantes sont traitées comme au-delà du seuil, car le seul point de données existant n'est pas au-delà du seuil. Cette valeur est évaluée avec deux points de données manquants qui sont traités comme au-delà du seuil. Lors de l'évaluation suivante de cette alerte, si les données sont toujours manquantes, l'état deviendra ALARM, étant donné que ce point de données en-deçà du seuil ne fera plus parti de la plage d'évaluation.

La troisième ligne, où les cinq points de données les plus récents sont manquants, illustre comment les différents paramètres de traitement des données manquantes affectent l'état d'alerte. Si les points de données manquants sont considérés comme une violation, l'alerte passe en état alerte, tandis que si elles sont considérées comme ne pas entrer en violation, l'alerte passe en état OK. Si les points de données manquants sont ignorés, l'alerte conserve l'état actuel qu'elle avait avant les points de données manquants. Et si les points de données manquants sont simplement considérés comme manquants, alors l'alerte n'a pas assez de données réelles récentes pour faire une évaluation, et passe dans INSUFFICIENT_DATA.

Dans la quatrième rangée, l'alerte passe à l'état ALARM dans tous les cas, car les trois points de données les plus récents sont en violation, et les Périodes d'évaluation ainsi que les Points de données à l'alerte de l'alerte sont tous deux réglés sur 3. Dans ce cas, le point de données manquant est ignoré et le paramètre relatif à l'évaluation des données manquantes n'est pas requis, car il y a 3 points de données réels à évaluer.

La ligne 5 représente un cas spécial d'évaluation d'alerte appelé état d'alerte prématurée. Pour plus d'informations, consultez Éviter les transitions prématurées vers l'état d'alerte.

Dans le tableau suivant, la valeur de Période est à nouveau définie sur 5 minutes et celle de Points de données avant l'alerte est seulement 2 alors que celle de Périodes d'évaluation est de 3. Il s'agit d'une alerte 2 sur 3, M sur N.

La plage d'évaluation est de 5. Il s'agit du nombre maximal de points de données récents qui sont récupérés et peuvent être utilisés au cas où certains points de données seraient manquants.

Points de données Nbre de points de données manquants MANQUANT IGNORER AU-DELÀ DU SEUIL EN-DEÇÀ DU SEUIL

0 - X - X

0

ALARM

ALARM

ALARM

ALARM

0 0 X 0 X

0

ALARM

ALARM

ALARM

ALARM

0 - X - -

1

OK

OK

ALARM

OK

- - - - 0

2

OK

OK

ALARM

OK

- - - - X

2

ALARM

Conserver l'état actuel

ALARM

OK

Dans les lignes 1 et 2, l'alerte passe toujours à l'état ALARM, car 2 des 3 points de données les plus récents sont en train de franchir. Dans la ligne 2, les deux points de données les plus anciens de la plage d'évaluation ne sont pas nécessaires, car aucun des 3 points de données les plus récents n'est manquant, de sorte que ces deux points de données plus anciens sont ignorés.

Dans les lignes 3 et 4, l'alerte passe à l'état ALARM uniquement si les données manquantes sont traitées comme des violations, auquel cas les deux points de données manquants les plus récents sont tous deux traités comme des violations. Dans la ligne 4, ces deux points de données manquants qui sont traités comme étant au-delà du seuil fournissent les deux points de données au-delà du seuil pour déclencher l'état ALARM.

La ligne 5 représente un cas spécial d'évaluation d'alerte appelé état d'alerte prématurée. Pour plus d'informations, consultez la section suivante.

Éviter les transitions prématurées vers l'état d'alerte

CloudWatch l'évaluation des alarmes inclut une logique visant à éviter les fausses alarmes, lorsque l'alarme passe prématurément en état d'alarme lorsque les données sont intermittentes. L'exemple illustré à la ligne 5 des tableaux de la section précédente illustre cette logique. Dans ces lignes, et dans les exemples suivants, la propriété Evaluation Periods (Périodes d'évaluation)est 3 et la plage d'évaluation est de 5 points de données. Datapoints to Alarm (Points de données à l'alerte) est défini sur 3, sauf pour l'exemple M sur N, où Datapoints to Alarm (Points de données à l'alerte) est défini sur 2.

Supposons que les données les plus récentes d'une alerte soient - - - - X, avec quatre points de données manquants, puis un point de données de violation comme point de données le plus récent. Étant donné que le point de données suivant peut être sans violation, l'alerte ne passe pas immédiatement dans l'état ALARM lorsque les données sont - - - - X ou - - - X - et Datapoints to Alarm (Points de données à l'alerte) est défini sur 3. De cette façon, les faux positifs sont évités lorsque le point de données suivant n'est pas en violation et que les données sont - - - X O ou - - X - O.

Toutefois, si les derniers points de données sont - - X - -, l'alerte passe en état alerte même si les points de données manquants sont considérés comme manquants. En effet, les alertes sont conçues pour toujours passer à l'état ALARM lorsque le plus ancien point de données de violation disponible pendant les Evaluation Periods (Périodes d'évaluation) est au moins aussi ancien que la valeur des Datapoint to Alarm (Points de données à alerter), et que tous les autres points de données plus récents sont en violation ou manquants. Dans ce cas, l'alerte passe en état ALARM même si le nombre total de points de données disponibles est inférieur à M (Datapoints to Alarm (Points de données à l'alerte)).

Cette logique d'alerte s'applique également aux alertes M sur N. Si le point de données de violation le plus ancien au cours de la plage d'évaluation est au moins aussi ancien que la valeur de Datapoints to Alarm (Points de données à l'alerte), et que tous les points de données les plus récents sont soit en violation ou manquants, l'alerte passe en état ALARM quelle que soit la valeur de M (Datapoints to Alarm (Points de données à l'alerte)).

alertes haute résolution

Si vous définissez une alerte sur une métrique haute résolution, vous pouvez spécifier une alerte haute résolution avec une période de 10 secondes ou de 30 secondes ou vous pouvez définir une alerte régulière avec une période correspondant à n'importe quel multiple de 60 secondes. Les frais engendrés par des alertes haute résolution sont plus élevés. Pour plus d'informations sur les métriques haute résolution, consultez Publier des métriques personnalisées .

alertes sur les expressions mathématiques

Vous pouvez définir une alarme en fonction du résultat d'une expression mathématique basée sur une ou plusieurs CloudWatch mesures. Une expression mathématique utilisée pour une alerte peut inclure jusqu'à 10 métriques. Chaque métrique doit utiliser la même période.

Pour une alarme basée sur une expression mathématique, vous pouvez spécifier la manière dont vous souhaitez CloudWatch traiter les points de données manquants. Dans ce cas, un point de données est considéré comme manquant si l'expression mathématique ne renvoie aucune valeur pour ce point de données.

Les alertes basées sur des expressions mathématiques ne peuvent pas effectuer des actions Amazon EC2.

Pour en savoir plus sur les expressions mathématiques et la syntaxe de métrique, consultez Utilisation des mathématiques appliquées aux métriques.

CloudWatch Alarmes basées sur les percentiles et échantillons de données faibles

Lorsque vous définissez un centile comme statistique d'une alerte, vous pouvez préciser quelle action réaliser lorsque les données sont insuffisantes pour obtenir une estimation statistique de qualité. Vous pouvez décider que l'alerte doit évaluer la statistique quoi qu'il arrive et éventuellement qu'elle change d'état. Vous pouvez également décider que l'alerte doit ignorer la métrique si la taille de l'échantillon est réduite et attendre pour l'évaluer que les données soient en quantité suffisante pour être significatives statistiquement.

Pour les centiles entre 0,5 (inclusif) et 1,00 (exclusif), ce paramètre est utilisé lorsque moins de 10/(1-centile) points de données sont présents lors de la période d'évaluation. Par exemple, ce paramètre serait utilisé si moins de 1 000 échantillons étaient présents pour une alerte dans un centile p99. Pour les centiles entre 0 et 0,5 (exclusif), ce paramètre est utilisé lorsque moins de 10/centile points de données sont présents.

Caractéristiques communes des CloudWatch alarmes

Les fonctionnalités suivantes s'appliquent à toutes les CloudWatch alarmes :

  • Il n'existe pas de limite au nombre d'alertes que vous pouvez créer. Pour créer ou mettre à jour une alarme, vous devez utiliser la CloudWatch console, l'action PutMetricAlarmAPI ou la put-metric-alarmcommande du AWS CLI.

  • Les noms des alertes ne doivent contenir que des caractères UTF-8 et ne peuvent pas contenir de caractères de contrôle ASCII.

  • Vous pouvez répertorier une ou toutes les alarmes actuellement configurées, ainsi que toutes les alarmes dans un état particulier à l'aide de la CloudWatch console, de l'action DescribeAlarmsAPI ou de la commande describe-alarm dans le. AWS CLI

  • Vous pouvez désactiver et activer les alarmes à l'aide des actions DisableAlarmActionset de l'EnableAlarmActionsAPI ou disable-alarm-actionsdes enable-alarm-actionscommandes et du AWS CLI.

  • Vous pouvez tester une alarme en la réglant sur n'importe quel état à l'aide de l'action SetAlarmStateAPI ou de la set-alarm-statecommande du AWS CLI. Ce changement de statut temporaire ne dure que jusqu'à la comparaison d'alerte suivante.

  • Vous pouvez créer une alerte pour une métrique personnalisée avant de créer cette dernière. Pour que l'alerte soit valide, vous devez inclure toutes les dimensions pour la métrique personnalisée en plus de l'espace de nom et du nom de la métrique dans la définition de l'alerte. Pour ce faire, vous pouvez utiliser l'action PutMetricAlarmAPI ou la put-metric-alarmcommande du AWS CLI.

  • Vous pouvez consulter l'historique d'une alarme à l'aide de la CloudWatch console, de l'action de l'DescribeAlarmHistoryAPI ou de la describe-alarm-historycommande du AWS CLI. CloudWatch conserve l'historique des alarmes pendant deux semaines. Chaque transition de statut est marquée par un horodatage unique. Dans de rares cas, votre historique peut afficher plus d'une notification pour un changement de statut. L'horodatage vous permet de confirmer les modifications de statut uniques.

  • Vous pouvez ajouter des alarmes à vos favoris à l'aide de l'option Favoris et récents du volet de navigation de la CloudWatch console en passant le curseur sur l'alarme que vous souhaitez ajouter aux favoris et en choisissant le symbole en forme d'étoile à côté de celle-ci.

  • Le nombre de périodes d'évaluation pour une alerte multiplié par la longueur de chaque période d'évaluation ne peut pas dépasser un jour.

Note

Certaines AWS ressources n'envoient pas de données métriques CloudWatch sous certaines conditions.

Par exemple, il se peut qu'Amazon EBS n'envoie pas de données de métriques pour un volume disponible qui n'est pas lié à une instance Amazon EC2, car aucune activité de métrique n'est à surveiller pour ce volume. Si vous avez une alerte définie pour ce type de métrique, vous pouvez remarquer que son état passe à INSUFFICIENT_DATA. Cela peut indiquer que votre ressource est inactive et ne signifie pas nécessairement la présence d'un problème. Vous pouvez spécifier la façon dont chaque alerte traite les données manquantes. Pour plus d’informations, consultez Configuration de la façon dont les CloudWatch alarmes traitent les données manquantes.