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.

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é.

États d'alerte de métrique

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

Évaluation d'une alerte

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

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.

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.

Actions d'alerte

Vous pouvez spécifier les actions qu'une alarme effectue lorsqu'elle change d'état entre les DATA états OK et INSUFFICIENT _. ALARM

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 :

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 JSON charge utile à la fonction Lambda lorsqu'elle l'invoque. Cette JSON charge utile sert d'objet d'événement pour la fonction. Vous pouvez extraire des données de cet JSON objet 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 :

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

Le meilleur choix dépend du type de métrique et de l'objectif de l'alarme. Par exemple, si vous créez une alarme d'annulation d'application à l'aide d'une métrique qui rapporte des données en permanence, vous souhaiterez peut-être considérer les points de données manquants comme une violation, car cela peut 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.

É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 :

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.

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'alarme passe en ALARM état, tandis que s'ils sont considérés comme non violés, l'alarme passe à l'é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, l'alarme ne dispose pas de suffisamment de données réelles récentes pour effectuer 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.

Dans les lignes 1 et 2, l'alarme passe toujours à ALARM l'état car 2 des 3 points de données les plus récents sont violés. 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'alarme ne passe à ALARM l'état que si les données manquantes sont considérées comme une violation, auquel cas les deux derniers points de données manquants sont tous deux considérés comme une violation. Dans la ligne 4, ces deux points de données manquants considérés comme une violation fournissent les deux points de données de violation nécessaires pour déclencher l'ALARMétat.

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 se déclenche ALARM prématurément 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 n'est peut-être pas une violation, l'alarme ne passe pas immédiatement à l'ALARMétat lorsque les données sont soit l'une - - - - X ou - - - X - l'autre, soit lorsque le nombre de points de données à alarmer est égal à 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 le sont- - X - -, l'alarme se déclenche ALARM même si les points de données manquants sont considérés comme manquants. Cela est dû au fait que les alarmes sont conçues pour toujours ALARM se déclencher lorsque le plus ancien point de données de violation disponible pendant les périodes d'évaluation est au moins aussi ancien que la valeur des points de données à alarmer, et que tous les autres points de données plus récents sont violés ou manquants. Dans ce cas, l'alarme passe à ALARM l'état même si le nombre total de points de données disponibles est inférieur à M (Datapoints to Alarm).

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

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 Publication de 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 alarmes basées sur des expressions mathématiques ne peuvent pas effectuer d'EC2actions Amazon.

Pour en savoir plus sur les expressions mathématiques et la syntaxe de métrique, consultez Utilisation d'expressions mathématiques avec des CloudWatch 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 :