Restrictions

CloudWatch Quotas généraux

Pour plus d'informations sur les quotas de CloudWatch service généraux applicables aux alarmes, consultezCloudWatch quotas de service.

Limites applicables aux alarmes basées sur des requêtes Metrics Insights

Lorsque vous travaillez avec CloudWatch des alarmes Metrics Insights, tenez compte des limites fonctionnelles suivantes :

• Une valeur par défaut de 200 alarmes utilisant la requête Metrics Insights par compte et par région

• Seules les trois dernières heures de données peuvent être utilisées pour évaluer les conditions d’alarme. Cependant, vous pouvez visualiser jusqu’à deux semaines de données dans le graphique détaillé de l’alarme

• Les alarmes évaluant plusieurs séries temporelles limitent le taux de transitions simultanées à 100

  • En supposant que la requête récupère 150 séries chronologiques :

    • S'il y a moins de 100 contributeurs dans ALARM (par exemple 95), le StateReason résultat sera « 95 séries chronologiques sur 150 évaluées selon ALARM »

    • S'il y a plus de 100 contributeurs dans ALARM, par exemple 105, il StateReason s'agira de « plus de 100 séries chronologiques évaluées selon ALARM »

  • En outre, en fonction de la taille des données du contributeur à l'alarme, celles-ci StateReason peuvent être tronquées pour afficher moins de données de séries chronologiques. En supposant que nous réduisions le nombre de contributeurs à 85, StateReason ils seront :

    • S'il y a moins de 100 contributeurs dans ALARM (par exemple 95), le StateReason nombre de contributeurs tronqué à 85 correspond à « plus de 85 séries chronologiques sur 150 évaluées selon ALARM ».

    • S'il y a plus de 100 contributeurs dans ALARM (par exemple 105), tronqués à 85, il s'StateReasonagira de « plus de 85 séries chronologiques évaluées selon ALARM ».

• Les limites de Metrics Insights relatives au nombre maximal de séries temporelles analysées ou renvoyées s’appliquent

• Lors de l'évaluation de l'alarme, la valeur EvaluationState sera réglée sur PARTIAL_DATA les limites suivantes :

  • Si la requête Metrics Insights renvoie plus de 500 séries chronologiques.

  • Si la requête Metrics Insights correspond à plus de 10 000 métriques.

Pour plus d'informations sur les quotas et les limites de CloudWatch service, consultez la section Quotas de service CloudWatch Metrics Insights.

Limites applicables aux alarmes basées sur les sources de données connectées

• Lorsqu'il CloudWatch évalue une alarme, il le fait toutes les minutes, même si la durée de l'alarme est supérieure à une minute. Pour que l’alarme fonctionne, la fonction Lambda doit pouvoir renvoyer une liste d’horodatages commençant à n’importe quelle minute, et pas seulement à des multiples de la durée de la période. Ces horodatages doivent être espacés d’une longueur de période.

  Par conséquent, si la source de données interrogée par le Lambda ne peut renvoyer que des horodatages multiples de la durée de la période, la fonction doit « rééchantillonner » les données extraites pour qu’elles correspondent aux horodatages attendus par la requête GetMetricData.

  Par exemple, une alarme avec une période de cinq minutes est évaluée toutes les minutes à l’aide de fenêtres de cinq minutes décalées d’une minute à chaque fois. Dans ce cas :

  • Pour l'évaluation de l'alarme à 12 h 15, des points de CloudWatch données sont attendus avec des horodatages de12:00:00, et. 12:05:00 12:10:00

  • Ensuite, pour l'évaluation de l'alarme à 12 h 16, on CloudWatch attend des points de données horodatés de12:01:00, et. 12:06:00 12:11:00

• Lors de CloudWatch l'évaluation d'une alarme, tous les points de données renvoyés par la fonction Lambda qui ne correspondent pas aux horodatages attendus sont supprimés et l'alarme est évaluée en utilisant les points de données attendus restants. Par exemple, lorsque l’alarme est évaluée à 12:15:00, il attend des données horodatées 12:00:00, 12:05:00 et 12:10:00. S'il reçoit des données horodatées de12:00:00,, et 12:05:00 12:06:0012:10:00, les données sont supprimées 12:06:00 et CloudWatch évalue l'alarme en utilisant les autres horodatages.

  Ensuite, pour la prochaine évaluation à 12:16:00, il attend des données horodatées 12:01:00, 12:06:00 et 12:11:00. S’il n’a que les données horodatées 12:00:00, 12:05:00 et 12:10:00, tous ces points de données sont ignorés à 12 h 16 et l’alarme passe à l’état correspondant à celui que vous avez spécifié pour l’alarme en ce qui concerne le traitement des données manquantes. Pour de plus amples informations, veuillez consulter Évaluation des alarmes.

• Nous vous recommandons de créer ces alarmes pour prendre des mesures lorsqu’elles passent à l’état INSUFFICIENT_DATA, car plusieurs cas d’utilisation d’une défaillance de la fonction Lambda feront passer l’alarme à INSUFFICIENT_DATA quelle que soit la manière dont vous l’avez configurée pour traiter les données manquantes.

• Si la fonction Lambda renvoie une erreur :

  • En cas de problème d’autorisation lors de l’appel de la fonction Lambda, l’alarme commence à présenter des transitions de données manquantes conformément à la façon dont vous avez spécifié l’alarme pour traiter les données manquantes lors de sa création.

  • Toute autre erreur provenant de la fonction Lambda entraîne le passage de l’alarme à INSUFFICIENT_DATA.

• Si la métrique demandée par la fonction Lambda présente un retard tel que le dernier point de données est toujours manquant, vous devez utiliser une solution de contournement. Vous pouvez créer une alarme M sur N ou augmenter la période d’évaluation de l’alarme. Pour plus d’informations sur les alarmes M sur N, veuillez consulter Évaluation des alarmes.