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.
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 des données manquantes ne sont pas le signe d'un 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 meilleur choix dépend du type de métrique et de l’objectif de l’alarme. Par exemple, si vous créez une alarme de restauration d’application à l’aide d’une métrique qui envoie continuellement des données, vous pourriez choisir de considérer les points de données manquants comme une violation, car cela pourrait indiquer qu’un problème est survenu. 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.
Important
Les alarmes configurées sur les métriques Amazon EC2 peuvent entrer temporairement dans l’état INSUFFICIENT_DATA s’il manque des points de données de métriques. C’est rare, mais cela peut se produire lorsque l’envoi des métriques est interrompu, même si l’instance Amazon EC2 est en bon état. Pour les alarmes basées sur des métriques Amazon EC2 configurées pour arrêter, terminer, redémarrer ou restaurer une instance, nous vous recommandons de configurer ces alarmes de manière à considérer les données manquantes comme missing, et à faire en sorte qu’elles se déclenchent uniquement lorsqu’elles sont dans l’état ALARM.
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 alarmes qui évaluent les métriques de l'espace de AWS/DynamoDB noms ignorent par défaut les données manquantes. Vous pouvez annuler cette option si vous choisissez une autre option pour le traitement des données manquantes par l'alarme. 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 |
|
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
|
- - - - - |
3 |
|
Conserver l'état actuel |
|
|
|
0 X X - X |
0 |
|
|
|
|
|
- - X - - |
2 |
|
Conserver l'état actuel |
|
|
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 |
|
|
|
|
|
0 0 X 0 X |
0 |
|
|
|
|
|
0 - X - - |
1 |
|
|
|
|
|
- - - - 0 |
2 |
|
|
|
|
|
- - - - X |
2 |
|
Conserver l'état actuel |
|
|
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)).
Données manquantes dans les alarmes CloudWatch Metrics Insights
Alarmes basées sur des requêtes Metrics Insights agrégées en une seule série chronologique
Les scénarios de données manquantes et leurs effets sur l'évaluation des alarmes sont les mêmes qu'une alarme métrique standard en termes de traitement configuré des données manquantes. Consultez Configuration de la façon dont les CloudWatch alarmes traitent les données manquantes.
Alarmes basées sur des requêtes Metrics Insights qui produisent plusieurs séries chronologiques
Les scénarios de données manquantes pour les alarmes Metrics Insights se produisent lorsque :
-
Les points de données individuels d'une série chronologique ne sont pas présents.
-
Une ou plusieurs séries temporelles disparaissent lors de l'évaluation de plusieurs séries chronologiques.
-
Aucune série chronologique n'est récupérée par la requête.
Les scénarios de données manquantes affectent l'évaluation des alarmes de la manière suivante :
-
Pour l'évaluation d'une série chronologique, le traitement des données manquantes est appliqué aux points de données individuels de la série chronologique. Par exemple, si 3 points de données ont été interrogés pour la série chronologique mais qu'un seul a été reçu, 2 points de données suivront la configuration des données manquantes configurée.
-
Si une série chronologique n'est plus récupérée par la requête, elle passera au traitement des données manquantes
OKquel que soit le traitement. Les actions d'alarme associées à laOKtransition au niveau du contributeur sont exécutées etStateReasonindiquent que le contributeur susmentionné est introuvable avec le message « Aucune donnée n'a été renvoyée pour ce contributeur ». L'état de l'alarme dépendra de l'état des autres contributeurs récupérés par la requête. -
Au niveau de l'alarme, si la requête renvoie un résultat vide (aucune série chronologique du tout), l'alarme passera
INSUFFICIENT_DATAquel que soit le traitement des données manquantes défini.