Alarmes recommandées

4XXError

Dimensions :ApiName, scène

Description de l'alarme : cette alarme détecte un taux élevé d'erreurs côté client. Cela peut indiquer un problème dans les paramètres d'autorisation ou de requête client. Cela peut également signifier qu'une ressource a été supprimée ou qu'un client en demande une qui n'existe pas. Envisagez d'activer CloudWatch les journaux et de vérifier l'absence d'erreurs susceptibles d'être à l'origine des erreurs 4XX. En outre, pensez à activer CloudWatch les métriques détaillées pour afficher cette métrique par ressource et par méthode et affiner la source des erreurs. Des erreurs peuvent également être causées par le dépassement de la limite configurée. Si les réponses et les journaux signalent des taux élevés et inattendus d'erreurs 429, suivez ce guide pour résoudre ce problème.

Intention : cette alarme peut détecter des taux élevés d'erreurs côté client pour les requêtes API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes reçoivent des erreurs 4xx. Cependant, vous pouvez ajuster le seuil en fonction du trafic des requêtes et des taux d'erreur acceptables. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

5XXError

Dimensions :ApiName, scène

Description de l'alarme : cette alarme permet de détecter un taux élevé d'erreurs côté serveur. Cela peut indiquer qu'il y a un problème sur le backend de l'API, le réseau ou l'intégration entre la passerelle d'API et l'API du backend. Cette documentation peut vous aider à résoudre la cause des erreurs 5xx.

Intention : cette alarme peut détecter des taux élevés d'erreurs côté serveur pour les requêtes API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes reçoivent des erreurs 5xx. Vous pouvez toutefois ajuster le seuil en fonction du trafic des requêtes et des taux d'erreur acceptables. Vous pouvez également analyser les données historiques pour déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 5xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

Count

Dimensions :ApiName, scène

Description de l'alarme : cette alarme permet de détecter un faible volume de trafic pour l'étape de l'API REST. Cela peut indiquer un problème lié à l'appel de l'API par l'application, par exemple lors de l'utilisation de points de terminaison incorrects. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API qui la rend inaccessible aux clients.

Intention : cette alarme peut détecter un volume de trafic étonnamment faible pour l'étape de l'API REST. Nous vous recommandons de créer cette alarme si votre API reçoit un nombre prévisible et régulier de requêtes dans des conditions normales. Si CloudWatch les métriques détaillées sont activées et que vous pouvez prévoir le volume de trafic normal par méthode et par ressource, nous vous recommandons de créer des alarmes alternatives afin de surveiller de manière plus précise les baisses de volume de trafic pour chaque ressource et méthode. Cette alarme n'est pas recommandée pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de requêtes de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible pendant les périodes de faible trafic normal et attendu. À l'inverse, si elle est réglée sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

Count

Dimensions : scèneApiName, ressource, méthode

Description de l'alarme : cette alarme permet de détecter un faible volume de trafic pour la ressource et la méthode de l'API REST au cours de l'étape. Cela peut indiquer un problème lié à l'appel de l'API par l'application, par exemple lors de l'utilisation de points de terminaison incorrects. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API qui la rend inaccessible aux clients.

Intention : cette alarme peut détecter un volume de trafic étonnamment faible pour la ressource et la méthode de l'API REST au cours de l'étape. Nous vous recommandons de créer cette alarme si votre API reçoit un nombre prévisible et régulier de requêtes dans des conditions normales. Cette alarme n'est pas recommandée pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de requêtes de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible pendant les périodes de faible trafic normal et attendu. À l'inverse, si elle est réglée sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

Count

Dimensions :ApiId, scène

Description de l'alarme : cette alarme permet de détecter un faible volume de trafic pour l'étape de l'API HTTP. Cela peut indiquer un problème lié à l'appel de l'API par l'application, par exemple lors de l'utilisation de points de terminaison incorrects. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API qui la rend inaccessible aux clients.

Intention : cette alarme peut détecter un volume de trafic étonnamment faible pour l'étape de l'API HTTP. Nous vous recommandons de créer cette alarme si votre API reçoit un nombre prévisible et régulier de requêtes dans des conditions normales. Si vous avez activé CloudWatch les métriques détaillées et que vous pouvez prévoir le volume de trafic normal par itinéraire, nous vous recommandons de créer des alarmes alternatives afin de surveiller de manière plus précise les baisses de volume de trafic pour chaque itinéraire. Cette alarme n'est pas recommandée pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez la valeur du seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de requêtes de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible pendant les périodes de faible trafic normal et attendu. À l'inverse, si elle est réglée sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

Count

Dimensions : scèneApiId, ressource, méthode

Description de l'alarme : cette alarme permet de détecter un faible volume de trafic pour la route de l'API HTTP au cours de l'étape. Cela peut indiquer un problème lié à l'appel de l'API par l'application, par exemple lors de l'utilisation de points de terminaison incorrects. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API qui la rend inaccessible aux clients.

Intention : cette alarme peut détecter un volume de trafic étonnamment faible pour la route de l'API HTTP au cours de l'étape. Nous vous recommandons de créer cette alarme si votre API reçoit un nombre prévisible et régulier de requêtes dans des conditions normales. Cette alarme n'est pas recommandée pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez la valeur du seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de requêtes de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible pendant les périodes de faible trafic normal et attendu. À l'inverse, si elle est réglée sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

IntegrationLatency

Dimensions :ApiId, scène

Description de l'alarme : cette alarme permet de détecter s'il existe une latence d'intégration élevée pour les demandes d'API d'une étape. Vous pouvez corréler la valeur de la métrique IntegrationLatency avec la métrique de latence correspondante de votre backend, telle que la métrique Duration pour les intégrations Lambda. Cela vous permet de déterminer si le backend de l'API met plus de temps à traiter les demandes des clients en raison de problèmes de performances, ou s'il existe une autre surcharge liée à l'initialisation ou au démarrage à froid. En outre, pensez à activer CloudWatch les journaux pour votre API et à vérifier les journaux pour détecter toute erreur susceptible d'être à l'origine des problèmes de latence élevée. En outre, pensez à activer CloudWatch les métriques détaillées pour avoir une vue de cette métrique par itinéraire, afin de vous aider à affiner la source de la latence d'intégration.

Intention : cette alarme peut détecter les cas où les requêtes API Gateway d'une étape présentent une latence d'intégration élevée. Nous recommandons cette alarme pour les WebSocket API, et nous la considérons comme facultative pour les API HTTP, car elles contiennent déjà des recommandations d'alarme distinctes pour la métrique de latence. Si CloudWatch les métriques détaillées sont activées et que vos exigences en matière de performances de latence d'intégration diffèrent par itinéraire, nous vous recommandons de créer des alarmes alternatives afin d'avoir une surveillance plus fine de la latence d'intégration pour chaque itinéraire.

Statistique : p90

Seuil recommandé : 2 000.0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail de l'API. Toutefois, vous pouvez l'utiliser comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API ait une latence plus élevée en général, définissez une valeur de seuil plus élevée pour rendre l'alarme moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques afin de déterminer la latence de base attendue pour la charge de travail de l'application, puis régler la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Dimensions : étapeApiId, itinéraire

Description de l'alarme : Cette alarme permet de détecter s'il existe une latence d'intégration élevée pour les demandes d' WebSocket API relatives à un itinéraire dans une étape. Vous pouvez corréler la valeur de la métrique IntegrationLatency avec la métrique de latence correspondante de votre backend, telle que la métrique Duration pour les intégrations Lambda. Cela vous permet de déterminer si le backend de l'API met plus de temps à traiter les demandes des clients en raison de problèmes de performances ou s'il existe une autre surcharge liée à l'initialisation ou au démarrage à froid. En outre, pensez à activer CloudWatch les journaux pour votre API et à vérifier les journaux pour détecter toute erreur susceptible d'être à l'origine des problèmes de latence élevée.

Intention : cette alarme peut détecter les cas où les demandes d'API Gateway pour une route dans une étape présentent une latence d'intégration élevée.

Statistique : p90

Seuil recommandé : 2 000.0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail de l'API. Toutefois, vous pouvez l'utiliser comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API ait une latence plus élevée en général, vous pouvez définir une valeur de seuil plus élevée pour rendre l'alarme moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques afin de déterminer la latence de base attendue pour la charge de travail de l'application, puis régler la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latence

Dimensions :ApiName, scène

Description de l'alarme : cette alarme détecte une latence élevée dans une étape. Recherchez la valeur de la métrique IntegrationLatency pour vérifier la latence du backend de l'API. Si les deux métriques sont globalement alignées, le backend de l'API est à l'origine d'une latence plus élevée et vous devriez examiner les problèmes à ce niveau. Envisagez également d'activer CloudWatch les journaux et de vérifier les erreurs susceptibles d'être à l'origine de cette latence élevée. En outre, pensez à activer CloudWatch les métriques détaillées pour afficher cette métrique par ressource et par méthode et affiner la source de la latence. Le cas échéant, reportez-vous aux guides résoudre les problèmes avec Lambda de résolution des problèmes pour résoudre les problèmes liés à mon point de terminaison d'API optimisé pour la périphérie.

Intention : cette alarme peut détecter les cas de latence élevée des requêtes API Gateway d'une étape. Si CloudWatch les métriques détaillées sont activées et que vos exigences en matière de performances de latence diffèrent pour chaque méthode et ressource, nous vous recommandons de créer des alarmes alternatives afin de surveiller plus précisément la latence pour chaque ressource et méthode.

Statistique : p90

Seuil recommandé : 2 500,0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail d'API. Toutefois, vous pouvez l'utiliser comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API ait une latence plus élevée en général, vous pouvez définir une valeur de seuil plus élevée pour rendre l'alarme moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques pour déterminer la latence de référence attendue pour la charge de travail de l'application, puis ajuster la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latence

Dimensions : scèneApiName, ressource, méthode

Description de l'alarme : cette alarme détecte une latence élevée pour une ressource et une méthode dans une étape. Recherchez la valeur de la métrique IntegrationLatency pour vérifier la latence du backend de l'API. Si les deux métriques sont globalement alignées, le backend de l'API est à l'origine d'une latence plus élevée et vous devriez examiner les problèmes de performances à ce niveau. Envisagez également d'activer CloudWatch les journaux et de vérifier les erreurs susceptibles d'être à l'origine de cette latence élevée. Vous pouvez également les guides résoudre les problèmes avec Lambda de résolution des problèmes pour résoudre les problèmes liés à mon point de terminaison d'API optimisé pour la périphérie, le cas échéant.

Intention : cette alarme peut détecter les cas où les demandes d'API Gateway pour une ressource et une méthode dans une étape présentent une latence élevée.

Statistique : p90

Seuil recommandé : 2 500,0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail de l'API. Toutefois, vous pouvez l'utiliser comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API ait une latence plus élevée en général, vous pouvez définir une valeur de seuil plus élevée pour rendre l'alarme moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques afin de déterminer la latence de référence attendue pour la charge de travail de l'application, puis ajuster la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latence

Dimensions :ApiId, scène

Description de l'alarme : cette alarme détecte une latence élevée dans une étape. Recherchez la valeur de la métrique IntegrationLatency pour vérifier la latence du backend de l'API. Si les deux métriques sont globalement alignées, le backend de l'API est à l'origine d'une latence plus élevée et vous devriez examiner les problèmes de performances à ce niveau. Envisagez également d'activer CloudWatch les journaux et de vérifier les erreurs susceptibles d'être à l'origine de cette latence élevée. En outre, pensez à activer CloudWatch les métriques détaillées pour afficher cette métrique par itinéraire et affiner la source de la latence. Vous pouvez également consulter le guide de résolution des problèmes d'intégration à Lambda, le cas échéant.

Intention : cette alarme peut détecter les cas de latence élevée des requêtes API Gateway d'une étape. Si CloudWatch les métriques détaillées sont activées et que vos exigences en matière de performances de latence diffèrent par itinéraire, nous vous recommandons de créer des alarmes alternatives afin de surveiller plus précisément la latence pour chaque itinéraire.

Statistique : p90

Seuil recommandé : 2 500,0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail de l'API. Elle peut toutefois être utilisée comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API présente une latence plus élevée en général, vous pouvez définir une valeur de seuil plus élevée pour la rendre moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques afin de déterminer la latence de référence attendue pour la charge de travail de l'application, puis ajuster la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latence

Dimensions : scèneApiId, ressource, méthode

Description de l'alarme : cette alarme détecte une latence élevée pour une route au cours d'une étape. Recherchez la valeur de la métrique IntegrationLatency pour vérifier la latence du backend de l'API. Si les deux métriques sont globalement alignées, le backend de l'API est à l'origine d'une latence plus élevée et doit être examiné pour détecter des problèmes de performance. Envisagez également d'activer CloudWatch les journaux et de vérifier les erreurs susceptibles d'être à l'origine de cette latence élevée. Vous pouvez également consulter le guide de résolution des problèmes d'intégration à Lambda, le cas échéant.

Intention : cette alarme est utilisée pour détecter les cas où les demandes d'API Gateway pour une route au cours d'une étape présentent une latence élevée.

Statistique : p90

Seuil recommandé : 2 500,0

Justification du seuil : la valeur de seuil suggérée ne fonctionne pas pour toutes les charges de travail de l'API. Elle peut toutefois être utilisée comme point de départ pour le seuil. Vous pouvez ensuite choisir différentes valeurs de seuil en fonction de la charge de travail et des exigences de latence, de performances et de SLA acceptables pour l'API. S'il est acceptable que l'API ait une latence plus élevée en général, vous pouvez définir une valeur de seuil plus élevée pour rendre l'alarme moins sensible. Toutefois, si l'API est censée fournir des réponses en temps quasi réel, définissez une valeur de seuil inférieure. Vous pouvez également analyser les données historiques afin de déterminer la latence de référence attendue pour la charge de travail de l'application, puis ajuster la valeur du seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

Dimensions :ApiId, scène

Description de l'alarme : cette alarme détecte un taux élevé d'erreurs côté client. Cela peut indiquer un problème dans les paramètres d'autorisation ou de requête client. Cela peut également signifier qu'une route a été supprimée ou qu'un client en demande une qui n'existe pas dans l'API. Envisagez d'activer les CloudWatch journaux et de vérifier les erreurs susceptibles d'être à l'origine des erreurs 4xx. En outre, pensez à activer CloudWatch les métriques détaillées pour afficher cette métrique par itinéraire, afin de vous aider à affiner la source des erreurs. Des erreurs peuvent également être causées par le dépassement de la limite configurée. Si les réponses et les journaux signalent des taux élevés et inattendus d'erreurs 429, suivez ce guide pour résoudre ce problème.

Intention : cette alarme peut détecter des taux élevés d'erreurs côté client pour les requêtes API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes reçoivent des erreurs 4xx. Cependant, vous pouvez ajuster le seuil en fonction du trafic des requêtes et des taux d'erreur acceptables. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

5xx

Dimensions :ApiId, scène

Description de l'alarme : cette alarme permet de détecter un taux élevé d'erreurs côté serveur. Cela peut indiquer qu'il y a un problème sur le backend de l'API, le réseau ou l'intégration entre la passerelle d'API et l'API du backend. Cette documentation peut vous aider à résoudre la cause des erreurs 5xx.

Intention : cette alarme peut détecter des taux élevés d'erreurs côté serveur pour les requêtes API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes reçoivent des erreurs 5xx. Cependant, vous pouvez ajuster le seuil en fonction du trafic des requêtes et des taux d'erreur acceptables. Vous pouvez également analyser les données historiques pour déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 5xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

MessageCount

Dimensions :ApiId, scène

Description de l'alarme : Cette alarme permet de détecter un faible volume de trafic pour la phase WebSocket API. Cela peut indiquer un problème lorsque les clients appellent l'API, par exemple en utilisant des points de terminaison incorrects ou en raison de problèmes liés à l'envoi de messages par le backend aux clients. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API, la rendant inaccessible aux clients.

Intention : Cette alarme peut détecter un volume de trafic étonnamment faible pour l'étape de l' WebSocket API. Nous vous recommandons de créer cette alarme si votre API reçoit et envoie un nombre prévisible et régulier de messages dans des conditions normales. Si CloudWatch les métriques détaillées sont activées et que vous pouvez prévoir le volume de trafic normal par itinéraire, il est préférable de créer des alarmes alternatives à celle-ci, afin d'avoir un suivi plus précis des baisses de volume de trafic pour chaque itinéraire. Nous ne recommandons pas cette alarme pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez la valeur du seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de messages de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible en période de faible trafic normal et prévu. À l'inverse, si vous le réglez sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

MessageCount

Dimensions : étapeApiId, itinéraire

Description de l'alarme : Cette alarme permet de détecter un faible volume de trafic pour la route de l' WebSocket API au cours de la phase. Cela peut indiquer un problème lié à l'appel de l'API par les clients, par exemple en utilisant des points de terminaison incorrects, ou des problèmes liés à l'envoi de messages par le backend aux clients. Cela peut également indiquer un problème lié à la configuration ou aux autorisations de l'API, la rendant inaccessible aux clients.

Intention : Cette alarme peut détecter un volume de trafic étonnamment faible pour la route de l' WebSocket API au cours de la phase. Nous vous recommandons de créer cette alarme si votre API reçoit et envoie un nombre prévisible et régulier de messages dans des conditions normales. Nous ne recommandons pas cette alarme pour les API qui ne s'attendent pas à un trafic constant et régulier.

Statistique : SampleCount

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction de l'analyse des données historiques afin de déterminer le nombre de messages de référence attendu pour votre API. Le réglage du seuil à une valeur très élevée peut rendre l'alarme trop sensible en période de faible trafic normal et prévu. À l'inverse, si vous le réglez sur une valeur très faible, l'alarme risque de ne pas détecter de petites baisses anormales du volume de trafic.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

ClientError

Dimensions :ApiId, scène

Description de l'alarme : cette alarme détecte un taux élevé d'erreurs client. Cela peut indiquer un problème dans les paramètres d'autorisation ou de message. Cela peut également signifier qu'une route a été supprimée ou qu'un client en demande une qui n'existe pas dans l'API. Envisagez d'activer les CloudWatch journaux et de vérifier les erreurs susceptibles d'être à l'origine des erreurs 4xx. En outre, pensez à activer CloudWatch les métriques détaillées pour afficher cette métrique par itinéraire, afin de vous aider à affiner la source des erreurs. Des erreurs peuvent également être causées par le dépassement de la limite configurée. Si les réponses et les journaux signalent des taux élevés et inattendus d'erreurs 429, suivez ce guide pour résoudre ce problème.

Intention : Cette alarme peut détecter des taux élevés d'erreurs client pour les messages WebSocket API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes reçoivent des erreurs 4xx. Vous pouvez ajuster le seuil en fonction du trafic des requêtes ainsi qu'en fonction de vos taux d'erreur acceptables. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ExecutionError

Dimensions :ApiId, scène

Description de l'alarme : cette alarme permet de détecter un taux élevé d'erreurs d'exécution. Cela peut être dû à des erreurs 5xx liées à votre intégration, à des problèmes d'autorisation ou à d'autres facteurs empêchant l'invocation réussie de l'intégration, tels que la limitation ou la suppression de l'intégration. Envisagez d'activer les CloudWatch journaux pour votre API et de vérifier le type et la cause des erreurs dans les journaux. En outre, pensez à activer CloudWatch les métriques détaillées pour avoir une vue de cette métrique par itinéraire, afin de vous aider à affiner la source des erreurs. Cette documentation peut également vous aider à résoudre la cause de toute erreur de connexion.

Intention : Cette alarme peut détecter des taux élevés d'erreurs d'exécution pour les messages WebSocket API Gateway.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil suggéré détecte les cas où plus de 5 % du total des requêtes présentent des erreurs d'exécution. Vous pouvez ajuster le seuil en fonction du trafic des requêtes, ainsi qu'en fonction de vos taux d'erreur acceptables. Vous pouvez analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs d'exécution fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

GroupInServiceCapacity

Dimensions : AutoScalingGroupName

Description de l'alarme : cette alarme permet de détecter lorsque la capacité du groupe est inférieure à la capacité requise pour votre charge de travail. Pour résoudre le problème, vérifiez vos activités de dimensionnement pour détecter les échecs de lancement et confirmez que la configuration de capacité souhaitée est correcte.

Objectif : cette alarme peut détecter une faible disponibilité dans votre groupe Auto Scaling en raison d'échecs de lancement ou de lancements suspendus.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur du seuil doit être la capacité minimale requise pour exécuter votre charge de travail. Dans la plupart des cas, vous pouvez le configurer pour qu'il corresponde à la GroupDesiredCapacity métrique.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

5 xxErrorRate

Dimensions :DistributionId, Région=Global

Description de l'alarme : Cette alarme surveille le pourcentage de réponses d'erreur 5xx provenant de votre serveur d'origine, afin de vous aider à détecter si le CloudFront service rencontre des problèmes. Veuillez consulter la section Résolution des réponses d'erreur de votre origine pour obtenir des informations qui vous aideront à comprendre les problèmes liés à votre serveur. En outre, l'activation de métriques supplémentaires permet d'obtenir des métriques d'erreur détaillées.

Intention : Cette alarme est utilisée pour détecter les problèmes liés au traitement des demandes provenant du serveur d'origine ou les problèmes de communication entre le serveur d'origine CloudFront et votre serveur d'origine.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de la tolérance pour les réponses 5xx. Vous pouvez analyser les données historiques et les tendances, puis définir le seuil en conséquence. Les erreurs 5xx pouvant être causées par des problèmes transitoires, nous vous recommandons de définir le seuil sur une valeur supérieure à 0 afin que l'alarme ne soit pas trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

OriginLatency

Dimensions :DistributionId, Région=Global

Description de l'alarme : l'alarme permet de vérifier si le serveur d'origine met trop de temps à répondre. Si le serveur met trop de temps à répondre, cela peut entraîner un délai d'expiration. Référez-vous à recherchez et corrigez des réponses retardées à partir des applications sur votre serveur d'origine si vous rencontrez des valeurs OriginLatency constamment élevées.

Intention : cette alarme est utilisée pour détecter les problèmes liés au fait que le serveur d'origine met trop de temps à répondre.

Statistique : p90

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez calculer la valeur d'environ 80 % du délai d'expiration de la réponse d'origine et utiliser le résultat comme valeur de seuil. Si cette métrique est toujours proche de la valeur du délai d'expiration de la réponse d'origine, il se peut que vous commenciez à rencontrer des erreurs 504.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensions :DistributionId, FunctionName, Région=Global

Description de l'alarme : Cette alarme vous aide à surveiller les erreurs de validation CloudFront des fonctions afin que vous puissiez prendre des mesures pour les résoudre. Analysez les journaux des CloudWatch fonctions et examinez le code de la fonction pour trouver et résoudre la cause première du problème. Consultez la section Restrictions relatives aux fonctions de périphérie pour comprendre les erreurs de configuration courantes des CloudFront fonctions.

Intention : Cette alarme est utilisée pour détecter les erreurs de validation des CloudFront fonctions.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : une valeur supérieure à 0 indique une erreur de validation. Nous vous recommandons de définir le seuil à 0 car les erreurs de validation impliquent un problème lorsque CloudFront les fonctions repassent à CloudFront. Par exemple, CloudFront nécessite l'en-tête HTTP Host pour traiter une demande. Rien n'empêche un utilisateur de supprimer l'en-tête Host dans son code de CloudFront fonctions. Mais lorsque vous CloudFront recevez la réponse et que l'en-tête Host est manquant, une CloudFront erreur de validation est générée.

Période : 60

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Dimensions :DistributionId, FunctionName, Région=Global

Description de l'alarme : Cette alarme vous aide à surveiller les erreurs d'exécution CloudFront des fonctions afin que vous puissiez prendre des mesures pour les résoudre. Analysez les journaux des CloudWatch fonctions et examinez le code de la fonction pour trouver et résoudre la cause première du problème.

Intention : Cette alarme est utilisée pour détecter les erreurs d'exécution des CloudFront fonctions.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : nous recommandons de définir le seuil à 0, car une erreur d'exécution indique un problème avec le code qui se produit lors de l'exécution.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensions :DistributionId, FunctionName, Région=Global

Description de l'alarme : Cette alarme vous permet de vérifier si votre CloudFront fonction est limitée. Si votre fonction est limitée, cela signifie que son exécution prend trop de temps. Pour éviter les limitations de fonction, envisagez d'optimiser le code de la fonction.

Objectif : Cette alarme peut détecter lorsque votre CloudFront fonction est limitée afin que vous puissiez réagir et résoudre le problème pour une expérience client fluide.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : nous recommandons de définir le seuil à 0, afin de permettre une résolution plus rapide des limitations de fonction.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SignUpThrottles

Dimensions :UserPool, UserPoolClient

Description de l'alarme : cette alarme surveille le nombre de requêtes limitées. Si les utilisateurs sont constamment limités, vous devez augmenter la limite en demandant une augmentation du quota de service. Consultez Quotas dans Amazon Cognito pour savoir comment demander une augmentation des quotas. Pour prendre des mesures proactives, pensez à suivre l'usage des quotas.

Intention : cette alarme permet de surveiller l'apparition de demandes d'inscription limitées. Cela peut vous aider à savoir quand prendre des mesures pour atténuer toute dégradation de l'expérience d'inscription. La limitation persistante des demandes est une expérience négative pour l'inscription des utilisateurs.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : un groupe d'utilisateurs bien dimensionné ne devrait pas être soumis à une limitation qui s'étend sur plusieurs points de données. Ainsi, le seuil typique pour une charge de travail attendue doit être de zéro. Pour une charge de travail irrégulière avec des pics fréquents, vous pouvez analyser les données historiques afin de déterminer la limitation acceptable pour la charge de travail de l'application, puis vous pouvez ajuster le seuil en conséquence. Une demande limitée doit être réitérée afin de minimiser l'impact sur l'application.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SignInThrottles

Dimensions :UserPool, UserPoolClient

Description de l'alarme : cette alarme surveille le nombre de demandes d'authentification utilisateur limitées. Si les utilisateurs sont constamment limités, vous devrez peut-être augmenter la limite en demandant une augmentation du quota de service. Consultez Quotas dans Amazon Cognito pour savoir comment demander une augmentation des quotas. Pour prendre des mesures proactives, pensez à suivre l'usage des quotas.

Intention : cette alarme permet de surveiller l'apparition de demandes de connexion limitées. Cela peut vous aider à savoir quand prendre des mesures pour atténuer toute dégradation de l'expérience de connexion. La limitation persistante des demandes est une mauvaise expérience d'authentification des utilisateurs.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : un groupe d'utilisateurs bien dimensionné ne devrait pas être soumis à une limitation qui s'étend sur plusieurs points de données. Ainsi, le seuil typique pour une charge de travail attendue doit être de zéro. Pour une charge de travail irrégulière avec des pics fréquents, vous pouvez analyser les données historiques afin de déterminer la limitation acceptable pour la charge de travail de l'application, puis vous pouvez ajuster le seuil en conséquence. Une demande limitée doit être réitérée afin de minimiser l'impact sur l'application.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Dimensions :UserPool, UserPoolClient

Description de l'alarme : vous pouvez définir la valeur seuil en fonction du trafic de la requête et pour qu'elle corresponde à une limitation acceptable pour les requêtes d'actualisation des jetons. La limitation est utilisée pour protéger votre système contre un trop grand nombre de requêtes. Cependant, il est également important de vérifier que vous n'êtes pas en situation de sous-allocation pour votre trafic normal. Vous pouvez analyser les données historiques pour trouver la limitation acceptable pour la charge de travail de l'application, puis vous pouvez régler votre seuil d'alarme pour qu'il soit supérieur à votre niveau de limitation acceptable. Les requêtes limitées doivent être réessayées par l'application/le service, car elles sont transitoires. Par conséquent, une valeur très faible du seuil peut rendre l'alarme sensible.

Intention : cette alarme permet de surveiller l'occurrence de requêtes d'actualisation de jetons limitées. Cela peut vous aider à savoir quand prendre des mesures pour atténuer les problèmes potentiels, afin de garantir une expérience utilisateur fluide ainsi que le bon fonctionnement et la fiabilité de votre système d'authentification. La limitation persistante des demandes est une mauvaise expérience d'authentification des utilisateurs.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur du seuil peut également être définie/ajustée en fonction du trafic de la requête ainsi que d'une limitation acceptable pour les requêtes d'actualisation des jetons. Les limitations sont là pour protéger votre système contre un trop grand nombre de requêtes, mais il est également important de vérifier que vous n'êtes pas en situation de sous-allocation pour votre trafic normal et de voir si cela en est la cause. Les données historiques peuvent également être analysées pour déterminer le niveau de limitation acceptable pour la charge de travail de l'application et le seuil peut être réglé à un niveau plus élevé que votre niveau de limitation acceptable habituel. Les requêtes limitées doivent être réessayées par l'application/le service, car elles sont transitoires. Par conséquent, une valeur très faible du seuil peut rendre l'alarme sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

FederationThrottles

UserPoolDimensioni : UserPoolClient, IdentityProvider

Description de l'alarme : cette alarme surveille le nombre de requêtes de fédération d'identité limitées. Si vous constatez régulièrement des limitations, cela peut indiquer que vous devez augmenter la limite en demandant une augmentation du quota de service. Consultez Quotas dans Amazon Cognito pour savoir comment demander une augmentation des quotas.

Intention : cette alarme permet de surveiller l'apparition de requêtes de fédération d'identité limitées. Cela peut vous aider à apporter des réponses proactives aux problèmes de performance ou aux erreurs de configuration, et à garantir une expérience d'authentification fluide pour vos utilisateurs. La limitation persistante des demandes est une mauvaise expérience d'authentification des utilisateurs.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : vous pouvez définir le seuil en fonction du trafic de la requête et pour qu'il corresponde à la limitation acceptable pour les requêtes de fédération d'identité. La limitation est utilisée pour protéger votre système contre un trop grand nombre de requêtes. Cependant, il est également important de vérifier que vous n'êtes pas en situation de sous-allocation pour votre trafic normal. Vous pouvez analyser les données historiques pour trouver la limitation acceptable pour la charge de travail de l'application, puis vous pouvez régler votre seuil d'alerte pour qu'il soit supérieur à votre niveau de limitation acceptable. Les requêtes limitées doivent être réessayées par l'application/le service, car elles sont transitoires. Par conséquent, une valeur très faible du seuil peut rendre l'alarme sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

AccountProvisionedReadCapacityUtilization

Dimensions : Aucune

Description de l'alarme : cette alarme détecte si la capacité de lecture du compte atteint sa limite allouée. Vous pouvez augmenter le quota du compte pour le taux d'utilisation de la capacité de lecture si cela se produit. Vous pouvez consulter vos quotas actuels pour les unités de capacité de lecture et demander des augmentations à l'aide des Service Quotas.

Objectif : l'alarme peut détecter si le taux d'utilisation de la capacité de lecture du compte est proche de celle de la capacité de lecture allouée. Si le taux d'utilisation atteint sa limite maximale, DynamoDB commence à limiter les requêtes de lecture.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : fixez le seuil à 80 %, pour que des mesures (telles que l'augmentation des limites du compte) puissent être prises avant que le compte n'atteigne sa pleine capacité afin d'éviter tout ralentissement.

Période : 300

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensions : Aucune

Description de l'alarme : cette alarme détecte si la capacité d'écriture du compte atteint sa limite allouée. Vous pouvez augmenter le quota du compte pour le taux d'utilisation de la capacité d'écriture si cela se produit. Vous pouvez consulter vos quotas actuels pour les unités de capacité d'écriture et demander des augmentations à l'aide des Service Quotas.

Intention : cette alarme peut détecter si le taux d'utilisation de la capacité d'écriture du compte est proche de celle de la capacité d'écriture allouée. Si le taux d'utilisation atteint sa limite maximale, DynamoDB commence à limiter les requêtes d'écriture.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : fixez le seuil à 80 %, pour que des mesures (telles que l'augmentation des limites du compte) puissent être prises avant que le compte n'atteigne sa pleine capacité afin d'éviter tout ralentissement.

Période : 300

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Dimensions :TableName, DelegatedOperation

Description de l'alarme : cette alarme détecte le retard de réplication vers un flux de données Kinesis. Dans des conditions normales de fonctionnement, la valeur AgeOfOldestUnreplicatedRecord ne devrait être que de quelques millisecondes. Ce nombre augmente en fonction des tentatives de réplication infructueuses causées par des choix de configuration contrôlés par le client. Les exemples de configuration contrôlés par le client qui conduisent à des tentatives de réplication infructueuses sont une capacité de flux de données Kinesis sous-allouée qui conduit à une limitation excessive ou une mise à jour manuelle des stratégies d'accès du flux de données Kinesis qui empêche DynamoDB d'ajouter des données au flux de données. Pour maintenir cette métrique à un niveau aussi bas que possible, vous devez veiller à une allocation correcte de la capacité du flux de données Kinesis et vous assurer que les autorisations de DynamoDB sont inchangées.

Intention : cette alarme peut surveiller les tentatives de réplication infructueuses et le retard de réplication qui en résulte dans le flux de données Kinesis.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du délai de réplication souhaité, mesuré en millisecondes. Cette valeur dépend des exigences de votre charge de travail et des performances attendues.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Dimensions :TableName, DelegatedOperation

Description de l'alarme : cette alarme détecte le nombre de registres que DynamoDB n'a pas pu répliquer sur votre flux de données Kinesis. Certains éléments de plus de 34 Ko peuvent augmenter en taille pour modifier les registres de données supérieurs à la limite de taille d'élément de 1 Mo de Kinesis Data Streams. Cette augmentation de taille se produit lorsque les éléments de plus de 34 Ko incluent un grand nombre de valeurs d'attribut booléennes ou vides. Les valeurs d'attribut booléennes et vides sont stockées sous la forme d'un octet dans DynamoDB. Toutefois, elles peuvent atteindre 5 octets lorsqu'elles sont sérialisées à l'aide de JSON standard pour la réplication Kinesis Data Streams. DynamoDB ne peut pas répliquer de tels registres de modification dans votre flux de données Kinesis. DynamoDB ignore ces registres de données de modification et continue automatiquement la réplication des registres suivants.

Intention : cette alarme peut surveiller le nombre de registres que DynamoDB n'a pas pu répliquer sur votre flux de données Kinesis en raison de la limite de taille des éléments de Kinesis Data Streams.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : définissez le seuil sur 0 pour détecter les enregistrements que DynamoDB n'a pas réussi à répliquer.

Période : 60

Points de données pour le déclenchement d'alarme : 1

Période d'évaluation : 1

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensions : TableName

Description de l'alarme : cette alarme détecte si un grand nombre de requêtes de lecture sont limitées pour la table DynamoDB. Pour résoudre ce problème, veuillez consulter Résolution des problèmes de limitation dans Amazon DynamoDB.

Intention : cette alarme peut détecter une limitation persistante des requêtes de lecture adressées à la table DynamoDB. Une limitation persistante des requêtes de lecture peut avoir un impact négatif sur les opérations de lecture de votre charge de travail et réduire l'efficacité globale du système.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du trafic de lecture attendu pour la table DynamoDB, en tenant compte d'un niveau de limitation acceptable. Il est important de vérifier si vous êtes sous-approvisionné et si vous ne provoquez pas une limitation régulière. Vous pouvez également analyser les données historiques pour trouver le niveau de limitation acceptable pour la charge de travail de l'application, puis régler le seuil pour qu'il soit supérieur à votre niveau de limitation habituel. Les requêtes limitées doivent être réitérées par l'application ou le service, car elles sont transitoires. Par conséquent, un seuil très bas peut rendre l'alarme trop sensible et provoquer des transitions d'état indésirables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensions :TableName, GlobalSecondaryIndexName

Description de l'alarme : cette alarme détecte si un nombre élevé de requêtes de lecture sont limitées pour l'index secondaire global de la table DynamoDB. Pour résoudre ce problème, veuillez consulter Résolution des problèmes de limitation dans Amazon DynamoDB.

Objectif : l'alarme peut détecter une limitation persistante des requêtes de lecture pour l'index secondaire global de la table DynamoDB. Une limitation persistante des requêtes de lecture peut avoir un impact négatif sur les opérations de lecture de votre charge de travail et réduire l'efficacité globale du système.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du trafic de lecture attendu pour la table DynamoDB, en tenant compte d'un niveau de limitation acceptable. Il est important de vérifier si vous êtes sous-approvisionné et si vous ne provoquez pas une limitation régulière. Vous pouvez également analyser les données historiques pour trouver un niveau de limitation acceptable pour la charge de travail de l'application, puis régler le seuil pour qu'il soit supérieur à votre niveau de limitation acceptable habituel. Les requêtes limitées doivent être réitérées par l'application ou le service, car elles sont transitoires. Par conséquent, un seuil très bas peut rendre l'alarme trop sensible et provoquer des transitions d'état indésirables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReplicationLatency

Dimensions :TableName, ReceivingRegion

Description de l'alarme : l'alarme détecte si le réplica d'une région pour la table globale est en retard par rapport à la région source. La latence peut augmenter si une AWS région se dégrade et que vous disposez d'une table de réplication dans cette région. Dans ce cas, vous pouvez rediriger temporairement les activités de lecture et d'écriture de votre application vers une autre AWS région. Si vous utilisez 2017.11.29 (ancienne) de tables globales, vérifiez que les unités de capacité d'écriture (WCU) sont identiques pour chaque réplica de table. Vous pouvez également vous assurer de suivre les recommandations de la section Bonnes pratiques et exigences pour la gestion de la capacité.

Intention : l'alarme peut détecter si le réplica de table d'une région est en retard par rapport à la réplication des modifications d'une autre région. Cela pourrait entraîner une divergence entre votre réplica et les autres réplicas. Il est utile de connaître la latence de réplication de chaque AWS région et d'avertir si cette latence de réplication augmente continuellement. La réplication de la table s'applique uniquement aux tables globales.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de votre cas d'utilisation. Les latences de réplication supérieures à 3 minutes font généralement l'objet d'une enquête. Passez en revue le caractère critique et les exigences du délai de réplication et analysez les tendances historiques, puis sélectionnez le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Dimensions :TableName, Fonctionnement

Description de l'alarme : cette alarme détecte une latence élevée pour le fonctionnement de la table DynamoDB (indiquée par la valeur de la dimension de l'Operation dans l'alarme). Consultez ce document de résolution des problèmes de latence dans Amazon DynamoDB.

Objectif : cette alarme peut détecter une latence élevée pour le fonctionnement de la table DynamoDB. Une latence plus élevée pour les opérations peut avoir un impact négatif sur l'efficacité globale du système.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : DynamoDB fournit une latence moyenne d'un chiffre en millisecondes pour les opérations singleton telles que,, etc. GetItem PutItem Toutefois, vous pouvez définir le seuil en fonction d'une tolérance acceptable pour la latence en fonction du type d'opération et de la table concernés par la charge de travail. Vous pouvez analyser les données historiques de cette métrique afin de déterminer la latence habituelle pour l'opération sur la table, puis définir le seuil sur un nombre qui représente le délai critique pour l'opération.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SystemErrors

Dimensions : TableName

Description de l'alarme : cette alarme détecte un nombre élevé et persistant d'erreurs système pour les requêtes de tables DynamoDB. Si les erreurs 5xx persistent, ouvrez le tableau de bord de l'état d'un service AWS pour vérifier l'absence de problèmes opérationnels liés au service. Vous pouvez utiliser cette alarme pour être averti en cas de problème de service interne prolongé lié à DynamoDB et elle vous aide à établir une corrélation avec le problème rencontré par votre application cliente. Veuillez consulter Gestion des erreurs avec DynamoDB pour plus d'informations.

Objectif : cette alarme peut détecter des erreurs système persistantes pour les requêtes de table DynamoDB. Les erreurs système indiquent des erreurs de service internes provenant de DynamoDB et permettent d'établir une corrélation avec le problème rencontré par le client.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du trafic attendu, en tenant compte d'un niveau acceptable d'erreurs système. Vous pouvez également analyser les données historiques pour déterminer le nombre d'erreurs acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs système doivent être réitérées par l'application/le service, car elles sont transitoires. Par conséquent, un seuil très bas peut rendre l'alarme trop sensible et provoquer des transitions d'état indésirables.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Dimensions :TableName, DelegatedOperation

Description de l'alarme : cette alarme détecte les enregistrements limités par votre flux de données Kinesis lors de la réplication de la capture des données de modification vers Kinesis. Cette limitation est due à une capacité de flux de données Kinesis insuffisante. Si vous rencontrez une limitation excessive et régulière, il se peut que vous deviez augmenter le nombre de partitions de flux Kinesis en proportion du débit d'écriture observé de votre table. Pour en savoir plus sur la détermination de la taille d'un flux de données Kinesis, consultez Détermination de la taille initiale d'un flux de données Kinesis.

Intention : cette alarme peut surveiller le nombre de registres qui ont été limités par votre flux de données Kinesis en raison d'une capacité insuffisante de flux de données Kinesis.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : vous pourriez rencontrer une certaine limitation lors de pics d'utilisation exceptionnels, mais les enregistrements limités devraient rester aussi bas que possible pour éviter une latence de réplication plus élevée (DynamoDB tente à nouveau d'envoyer des enregistrements limités au flux de données Kinesis). Définissez le seuil sur une valeur qui peut vous aider à détecter une limitation excessive régulière. Vous pouvez également analyser les données historiques de cette métrique afin de déterminer les taux de limitation acceptables pour la charge de travail de l'application. Ajustez le seuil à une valeur tolérée par l'application en fonction de votre cas d'utilisation.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

UserErrors

Dimensions : Aucune

Description de l'alarme : cette alarme détecte un nombre élevé et persistant d'erreurs utilisateur concernant les requêtes de table DynamoDB. Vous pouvez consulter les journaux des applications clientes pendant la période d'émission pour voir pourquoi les requêtes ne sont pas valides. Vous pouvez vérifier le code d'état HTTP 400 pour voir le type d'erreur que vous recevez et prendre les mesures nécessaires. Vous devrez peut-être corriger la logique de l'application pour créer des requêtes valides.

Intention : cette alarme peut détecter des erreurs utilisateur persistantes concernant les requêtes de table DynamoDB. Les erreurs de l'utilisateur liées aux opérations demandées signifient que le client produit des requêtes non valides et qu'elles échouent.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil à zéro pour détecter toute erreur côté client. Vous pouvez également le régler sur une valeur plus élevée si vous souhaitez éviter que l'alarme ne se déclenche en cas de très faible nombre d'erreurs. Décidez en fonction de votre cas d'utilisation et du trafic pour les requêtes.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensions : TableName

Description de l'alarme : cette alarme détecte si un grand nombre de requêtes d'écriture sont limitées pour la table DynamoDB. Veuillez consulter Résolution des problèmes de limitation dans Amazon DynamoDB pour résoudre ce problème.

Intention : cette alarme peut détecter une limitation persistante des requêtes d'écriture dans la table DynamoDB. La limitation persistante des requêtes d'écriture peut avoir un impact négatif sur les opérations d'écriture de votre charge de travail et réduire l'efficacité globale du système.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du trafic d'écriture attendu pour la table DynamoDB, en tenant compte d'un niveau de limitation acceptable. Il est important de vérifier si vous êtes sous-approvisionné et si vous ne provoquez pas une limitation régulière. Vous pouvez également analyser les données historiques pour trouver un niveau de limitation acceptable pour la charge de travail de l'application, puis régler le seuil pour qu'il soit supérieur à votre niveau de limitation acceptable habituel. Les requêtes limitées doivent être réessayées par l'application/le service, car elles sont transitoires. Par conséquent, un seuil très bas peut rendre l'alarme trop sensible et provoquer des transitions d'état indésirables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensions :TableName, GlobalSecondaryIndexName

Description de l'alarme : cette alarme détecte si un grand nombre de requêtes d'écriture sont limitées pour l'index secondaire global de la table DynamoDB. Veuillez consulter Résolution des problèmes de limitation dans Amazon DynamoDB pour résoudre ce problème.

Intention : cette alarme peut détecter une limitation persistante des requêtes d'écriture pour l'index secondaire global de la table DynamoDB. La limitation persistante des requêtes d'écriture peut avoir un impact négatif sur les opérations d'écriture de votre charge de travail et réduire l'efficacité globale du système.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du trafic d'écriture attendu pour la table DynamoDB, en tenant compte d'un niveau de limitation acceptable. Il est important de vérifier si vous êtes sous-approvisionné et si vous ne provoquez pas une limitation régulière. Vous pouvez également analyser les données historiques pour trouver le niveau de limitation acceptable pour la charge de travail de l'application, puis régler le seuil à une valeur supérieure à votre niveau de limitation acceptable habituel. Les requêtes limitées doivent être réessayées par l'application/le service, car elles sont transitoires. Par conséquent, une valeur très faible peut rendre l'alarme trop sensible et provoquer des transitions d'état indésirables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

VolumeStalledIOcheck

Dimensions :VolumeId, InstanceId

Description de l'alarme : Cette alarme vous permet de surveiller les performances d'E/S de vos volumes Amazon EBS. Cette vérification détecte les problèmes sous-jacents liés à l'infrastructure Amazon EBS, tels que les problèmes matériels ou logiciels sur les sous-systèmes de stockage sous-jacents aux volumes Amazon EBS, les problèmes matériels sur l'hôte physique qui ont un impact sur l'accessibilité des volumes Amazon EBS depuis votre instance Amazon EC2, et permet de détecter les problèmes de connectivité entre l'instance et les volumes Amazon EBS. Si la vérification des E/S bloqués échoue, vous pouvez soit attendre AWS que le problème soit résolu, soit prendre des mesures telles que le remplacement du volume concerné ou l'arrêt et le redémarrage de l'instance à laquelle le volume est connecté. Dans la plupart des cas, lorsque cette métrique échoue, Amazon EBS diagnostique et restaure automatiquement votre volume en quelques minutes.

Intention : Cette alarme peut détecter l'état de vos volumes Amazon EBS afin de déterminer à quel moment ces volumes sont altérés et ne peuvent pas terminer les opérations d'E/S.

Statistique : maximum

Seuil recommandé : 1,0

Justification du seuil : lorsqu'une vérification de l'état échoue, la valeur de cette métrique est 1. Le seuil est réglé de telle sorte que chaque fois que le vérification de l'état échoue, l'alarme soit en état ALARM.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Dimensions : InstanceId

Description de l'alarme : cette alarme permet de surveiller le taux d'utilisation du processeur d'une instance EC2. Selon l'application, des niveaux d'utilisation élevés et constants peuvent être normaux. Mais si les performances sont dégradées et que l'application n'est pas limitée par les E/S du disque, la mémoire ou les ressources réseau, un processeur au maximum peut indiquer un goulot d'étranglement des ressources ou des problèmes de performance de l'application. Un taux d'utilisation élevé du processeur peut indiquer qu'une mise à niveau vers une instance utilisant un CPU plus puissant est nécessaire. Si la surveillance détaillée est activée, vous pouvez modifier la période à 60 secondes au lieu de 300 secondes. Pour plus d'informations, veuillez consulter Activer ou désactiver la surveillance détaillée pour vos instances.

Objectif : cette alarme est utilisée pour détecter un taux d'utilisation élevé du processeur.

Statistique : moyenne

Seuil recommandé : 80,0

Justification du seuil : vous pouvez généralement définir le seuil d'utilisation du processeur entre 70 et 80 %. Toutefois, vous pouvez ajuster cette valeur en fonction de votre niveau de performance acceptable et des caractéristiques de charge de travail. Pour certains systèmes, une utilisation constamment élevée du processeur peut être normale et ne pas indiquer un problème, tandis que pour d'autres, cela peut être une source de préoccupation. Analysez les données historiques d'utilisation du processeur pour identifier l'utilisation, déterminer quelle utilisation du processeur est acceptable pour votre système et définissez le seuil en conséquence.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

StatusCheckFailed

Dimensions : InstanceId

Description de l'alarme : cette alarme permet de surveiller à la fois les vérifications de l'état de système et les contrôles de statut d'instance. Si l'un ou l'autre type de vérification de l'état échoue, cette alarme doit être en état ALARM.

Objectif : cette alarme est utilisée pour détecter les problèmes sous-jacents liés aux instances, notamment les échecs de vérification de l'état du système et les échecs de vérification de l'état des instances.

Statistique : maximum

Seuil recommandé : 1,0

Justification du seuil : lorsqu'une vérification de l'état échoue, la valeur de cette métrique est 1. Le seuil est réglé de telle sorte que chaque fois que le vérification de l'état échoue, l'alarme soit en état ALARM.

Période : 300

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_EBS attachés

Dimensions : InstanceId

Description de l'alarme : Cette alarme vous permet de vérifier si les volumes Amazon EBS attachés à une instance sont accessibles et capables d'effectuer des opérations d'E/S. Cette vérification d'état détecte les problèmes sous-jacents liés à l'infrastructure informatique ou Amazon EBS, tels que les suivants :

Problèmes matériels ou logiciels sur les sous-systèmes de stockage sous-jacents aux volumes Amazon EBS
Problèmes matériels sur l'hôte physique qui ont un impact sur l'accessibilité des volumes Amazon EBS
Problèmes de connectivité entre l'instance et les volumes Amazon EBS

Lorsque la vérification du statut EBS jointe échoue, vous pouvez soit attendre qu'Amazon résolve le problème, soit prendre une mesure telle que le remplacement des volumes concernés ou l'arrêt et le redémarrage de l'instance.

Intention : Cette alarme est utilisée pour détecter les volumes Amazon EBS inaccessibles attachés à une instance. Ils peuvent provoquer des défaillances dans les opérations d'E/S.

Statistique : maximum

Seuil recommandé : 1,0

Justification du seuil : lorsqu'une vérification de l'état échoue, la valeur de cette métrique est 1. Le seuil est réglé de telle sorte que chaque fois que le vérification de l'état échoue, l'alarme soit en état ALARM.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

CPUUtilization

Dimensions :CacheClusterId, CacheNodeId

Description de l'alarme : Cette alarme permet de surveiller l'utilisation du processeur pour l'ensemble de l' ElastiCache instance, y compris les processus du moteur de base de données et les autres processus exécutés sur l'instance. AWS Elasticache prend en charge deux types de moteurs : Memcached et Redis. Lorsque vous atteignez un taux d'utilisation élevé du processeur sur un nœud Memcached, vous devez envisager d'augmenter le type d'instance ou d'ajouter de nouveaux nœuds de cache. Pour Redis, si votre charge de travail principale provient de requêtes de lecture, vous devriez envisager d'ajouter d'autres réplicas en lecture à votre cluster de cache. Si votre charge de travail principale provient de requêtes d'écriture, vous devriez envisager d'ajouter des partitions supplémentaires pour répartir la charge de travail sur un plus grand nombre de nœuds primaires si vous opérez en mode cluster, ou d'augmenter le type d'instance si vous exécutez Redis en mode non-cluster.

Objectif : Cette alarme est utilisée pour détecter une utilisation élevée du processeur par ElastiCache les hôtes. Il est utile d'avoir une vue d'ensemble de l'utilisation du processeur sur la totalité de l'instance, y compris les processus non liés au moteur.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil sur le pourcentage qui reflète un niveau d'utilisation critique du processeur pour votre application. Pour Memcached, le moteur peut utiliser jusqu'à un nombre de cœurs égal à num_threads. Pour Redis, le moteur est principalement monothread, mais peut utiliser des cœurs supplémentaires si disponibles pour accélérer les E/S. Dans la plupart des cas, vous pouvez définir le seuil à environ 90 % de votre processeur disponible. Comme Redis est à thread unique, la valeur réelle du seuil doit être calculée en tant que fraction de la capacité totale du nœud.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

CurrConnections

Dimensions :CacheClusterId, CacheNodeId

Description de l'alarme : cette alarme détecte un nombre élevé de connexions, ce qui peut indiquer une charge importante ou des problèmes de performance. Une augmentation constante de CurrConnections pourrait entraîner l'épuisement des 65 000 connexions disponibles. Cela peut indiquer que les connexions se sont mal fermées du côté de l'application et ont été laissées établies du côté du serveur. Vous devriez envisager d'utiliser le regroupement des connexions ou des délais d'expiration pour les connexions inactives afin de limiter le nombre de connexions établies avec le cluster, ou pour Redis, envisager d'ajuster la valeur de tcp-keepalive sur votre cluster afin de détecter et d'éliminer les pairs potentiellement morts.

Objectif : L'alarme vous aide à identifier le nombre élevé de connexions susceptibles d'avoir un impact sur les performances et la stabilité de votre ElastiCache cluster.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de la plage de connexions acceptable pour votre cluster. Passez en revue la capacité et la charge de travail attendue de votre ElastiCache cluster et analysez le nombre historique de connexions lors d'une utilisation normale pour établir une base de référence, puis sélectionnez un seuil en conséquence. N'oubliez pas que chaque nœud peut prendre en charge jusqu'à 65 000 connexions simultanées.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Dimensions : CacheClusterId

Description de l'alarme : cette alarme vous permet de surveiller le taux d'utilisation de la mémoire de votre cluster. Lorsque votre DatabaseMemoryUsagePercentage atteint 100 %, la politique Redis maxmemory est déclenchée et des expulsions peuvent avoir lieu en fonction de la politique sélectionnée. Si aucun objet du cache ne correspond à la politique d'expulsion, les opérations d'écriture échouent. Certaines charges de travail prévoient ou dépendent d'expulsions, mais dans le cas contraire, vous devrez augmenter la capacité de mémoire de votre cluster. Vous pouvez monter votre cluster en puissance en ajoutant d'autres nœuds primaires, ou l'augmenter en utilisant un type de nœud plus large. Reportez-vous à la section Scaling ElastiCache for Redis clusters pour plus de détails.

Objectif : cette alarme est utilisée pour détecter un taux d'utilisation élevé de la mémoire de votre cluster afin d'éviter les défaillances lors de l'écriture sur votre cluster. Il est utile de savoir à quel moment vous devrez augmenter votre cluster si votre application ne prévoit pas d'expulsions.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : en fonction des besoins en mémoire de votre application et de la capacité de mémoire de votre ElastiCache cluster, vous devez définir le seuil sur le pourcentage qui reflète le niveau critique d'utilisation de la mémoire du cluster. Vous pouvez utiliser les données historiques d'utilisation de la mémoire comme référence pour un seuil d'utilisation de mémoire acceptable.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

EngineCPUUtilization

Dimensions : CacheClusterId

Description de l'alarme : Cette alarme permet de surveiller l'utilisation du processeur d'un thread du moteur Redis au sein de l' ElastiCache instance. Les causes courantes d'un processeur surchargé sont les suivantes : des commandes à exécution longue qui consomment beaucoup de processeur, un nombre élevé de requêtes, une augmentation du nombre de nouvelles demandes de connexion client en peu de temps et des expulsions élevées lorsque le cache ne dispose pas de suffisamment de mémoire pour contenir de nouvelles données. Vous devriez envisager de dimensionner ElastiCache les clusters Redis en ajoutant plus de nœuds ou en augmentant le type d'instance.

Intention : cette alarme est utilisée pour détecter un taux d'utilisation élevé du processeur par un thread du moteur Redis. C'est utile si vous souhaitez surveiller l'utilisation du processeur par le moteur de base de données lui-même.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : définissez le seuil sur un pourcentage qui reflète le niveau d'utilisation critique du processeur pour votre application. Vous pouvez comparer votre cluster à l'aide de votre application et de la charge de travail attendue pour corréler EngineCPUUtilization et les performances comme référence, puis définir le seuil en conséquence. Dans la plupart des cas, vous pouvez définir le seuil à environ 90 % de la capacité de votre processeur.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReplicationLag

Dimensions : CacheClusterId

Description de l'alarme : Cette alarme permet de surveiller l'état de réplication de votre ElastiCache cluster. Un retard de réplication élevé signifie que le nœud primaire ou le réplica ne peuvent pas suivre le rythme de la réplication. Si votre activité d'écriture est trop élevée, envisagez de redimensionner votre cluster en ajoutant des nœuds primaires ou en utilisant un type de nœud plus important. Reportez-vous à la section Scaling ElastiCache for Redis clusters pour plus de détails. Si vos réplicas en lecture sont surchargées par le nombre de requêtes de lecture, envisagez d'en ajouter d'autres.

Intention : cette alarme est utilisée pour détecter un délai entre les mises à jour des données sur le nœud primaire et leur synchronisation avec le nœud de réplica. Cela permet de garantir la cohérence des données d'un nœud de cluster de réplica en lecture.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction des exigences de votre application et de l'impact potentiel du retard de réplication. Vous devez tenir compte des taux d'écriture attendus de votre application et des conditions du réseau pour déterminer le délai de réplication acceptable.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

GPU ConnectivityCheckFailed

Dimensions :InstanceId, eGPUID

Description de l'alarme : cette alarme permet de détecter les défaillances de connexion entre l'instance et l'accélérateur Elastic Graphics. Elastic Graphics utilise le réseau de l'instance pour envoyer des commandes OpenGL à une carte graphique attachée à distance. Par ailleurs, un bureau exécutant une application OpenGL avec un accélérateur Elastic Graphics est généralement accessible à l'aide d'une technologie d'accès à distance. Il est important de distinguer les problèmes de performance liés au rendu OpenGL ou à la technologie d'accès distant au bureau. Pour en savoir plus sur le problème, veuillez consulter Examiner les problèmes de performance des applications.

Intention : cette alarme est utilisée pour détecter des problèmes de connectivité entre l'instance et l'accélérateur Elastic Graphics.

Statistique : maximum

Seuil recommandé : 0,0

Justification du seuil : la valeur du seuil de 1 indique que la connectivité a échoué.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

GPU HealthCheckFailed

Dimensions :InstanceId, eGPUID

Description de l'alarme : cette alarme vous permet de savoir si l'état de l'accélérateur graphique Elastic est défectueux. Si l'accélérateur n'est pas en bon état, veuillez consulter les étapes de dépannage dans Résoudre les problèmes de statut Non sain.

Intention : cette alarme est utilisée pour détecter si l'accélérateur Elastic Graphics n'est pas sain.

Statistique : maximum

Seuil recommandé : 0,0

Justification du seuil : la valeur de seuil de 1 indique un échec de la vérification de l'état.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

CPUReservation

Dimensions : ClusterName

Description de l'alarme : cette alarme vous aide à détecter une réserve de processeurs élevée du cluster ECS. Une réserve de processeur élevée peut indiquer que le cluster n'a plus de processeurs enregistrés pour la tâche. Pour résoudre le problème, vous pouvez ajouter de la capacité, mettre à l'échelle le cluster ou configurer l'autoscaling.

Intention : l'alarme est utilisée pour détecter si le nombre total d'unités de processeur réservées par les tâches du cluster atteint le nombre total d'unités de processeur enregistrées pour le cluster. Cela vous permet de savoir quand augmenter le cluster. Le fait d'atteindre le nombre total d'unités de processeur pour le cluster peut entraîner un manque d'unités de processeur pour les tâches. Si le dimensionnement géré par les fournisseurs de capacité EC2 est activé ou si vous avez associé Fargate aux fournisseurs de capacité, cette alarme n'est pas recommandée.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : définissez le seuil de réserve de processeur à 90 %. Vous pouvez également choisir une valeur inférieure en fonction des caractéristiques du cluster.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

CPUUtilization

Dimensions :ClusterName, ServiceName

Description de l'alarme : cette alarme vous aide à détecter un taux d'utilisation élevé du processeur par le service ECS. Si aucun déploiement ECS n'est en cours, une utilisation maximale du processeur peut indiquer un goulot d'étranglement des ressources ou des problèmes de performances des applications. Pour résoudre le problème, vous pouvez augmenter la limite du processeur.

Objectif : cette alarme est utilisée pour détecter un taux d'utilisation élevé du processeur par le service ECS. Un taux d'utilisation élevé et constant du processeur peut indiquer un goulot d'étranglement des ressources ou des problèmes de performance des applications.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : les métriques de service relatives à l'utilisation du processeur peuvent dépasser 100 % d'utilisation. Toutefois, nous vous recommandons de surveiller la métrique d'utilisation élevée du processeur pour éviter d'affecter les autres services. Réglez le seuil à environ 90 à 95 %. Nous vous recommandons de mettre à jour vos définitions de tâches afin de refléter l'utilisation réelle dans le but d'éviter de futurs problèmes avec d'autres services.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

MemoryReservation

Dimensions : ClusterName

Description de l'alarme : cette alarme vous aide à détecter une réserve de mémoire élevée du cluster ECS. Une réserve de mémoire élevée peut indiquer un goulot d'étranglement des ressources pour le cluster. Pour résoudre le problème, analysez les performances de la tâche de service afin de déterminer si l'utilisation de la mémoire peut être optimisée. Vous pouvez également enregistrer plus de mémoire ou configurer l'autoscaling.

Objectif : l'alarme est utilisée pour détecter si le nombre total d'unités de mémoire réservées par les tâches du cluster atteint le nombre total d'unités de mémoire enregistrées pour le cluster. Cela vous permet de savoir quand augmenter le cluster. Si vous atteignez le nombre total d'unités de mémoire pour le cluster, celui-ci peut être incapable de lancer de nouvelles tâches. Si le dimensionnement géré par les fournisseurs de capacité EC2 est activé ou si vous avez associé Fargate à des fournisseurs de capacité, cette alarme n'est pas recommandée.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : définissez le seuil de réserve du mémoire à 90 %. Vous pouvez l'ajuster à une valeur inférieure en fonction des caractéristiques du cluster.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Dimensions :ClusterName, ServiceName

Description de l'alarme : cette alarme vous aide à détecter un nombre élevé d'erreurs côté serveur pour le service ECS. Cela peut indiquer que des erreurs empêchent le serveur de répondre aux requêtes. Pour résoudre le problème, consultez les journaux de vos applications.

Objectif : cette alarme est utilisée pour détecter un nombre élevé d'erreurs côté serveur pour le service ECS.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : calculez la valeur d'environ 5 % de votre trafic moyen et utilisez cette valeur comme point de départ pour le seuil. Vous pouvez trouver le trafic moyen à l'aide de la métrique RequestCount. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence. Les erreurs 5xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

TargetResponseTime

Dimensions :ClusterName, ServiceName

Description de l'alarme : cette alarme vous aide à détecter un temps de réponse cible élevé pour les demandes de service ECS. Cela peut indiquer que certains problèmes empêchent le service de traiter les demandes à temps. Pour résoudre le problème, vérifiez la métrique CPUUtilization pour voir si le service manque de processeur, ou vérifiez le taux d'utilisation du processeur des autres services en aval dont dépend votre service.

Intention : cette alarme est utilisée pour détecter un temps de réponse cible élevé pour les demandes de service ECS.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de votre cas d'utilisation. Passez en revue la criticité et les exigences du temps de réponse cible du service et analysez le comportement historique de cette métrique afin de déterminer des seuils raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

EphemeralStorageUtilized

Dimensions :ClusterName, ServiceName

Description de l’alarme : cette alarme vous aide à détecter le stockage éphémère élevé utilisé par le cluster Fargate. Si le stockage éphémère est constamment élevé, vous pouvez vérifier l’utilisation du stockage éphémère et augmenter ce dernier.

Intention : cette alarme est utilisée pour détecter une utilisation élevée du stockage éphémère du cluster Fargate. L’utilisation constante d’un stockage éphémère élevé peut indiquer que le disque est plein et peut entraîner une défaillance du conteneur.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil à environ 90 % de la taille du stockage éphémère. Vous pouvez ajuster cette valeur en fonction de votre utilisation acceptable du stockage éphémère du cluster Fargate. Pour certains systèmes, un stockage éphémère constamment élevé peut être normal, tandis que pour d’autres, cela peut entraîner une défaillance du conteneur.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

RunningTaskCount

Dimensions :ClusterName, ServiceName

Description de l’alarme : cette alarme vous aide à détecter un faible nombre de tâches en cours d’exécution du service ECS. Si le nombre de tâches en cours d’exécution est trop faible, cela peut indiquer que l’application ne peut pas gérer la charge du service et cela peut entraîner des problèmes de performances. Si aucune tâche n’est en cours d’exécution, il est possible que le service Amazon ECS ne soit pas disponible ou qu’il s’agisse de problèmes de déploiement.

Intention : cette alarme est utilisée pour détecter si le nombre de tâches en cours d’exécution est trop faible. Un faible nombre de tâches en cours d’exécution constant peut indiquer le déploiement du service ECS ou des problèmes de performance.

Statistique : moyenne

Seuil recommandé : 0,0

Justification du seuil : vous pouvez ajuster le seuil en fonction du nombre minimal de tâches en cours d’exécution du service ECS. Si le nombre de tâches en cours est égal à 0, le service Amazon ECS ne sera pas disponible.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

InstanceIdDimensioni : ContainerInstanceId, ClusterName

Description de l’alarme : cette alarme vous aide à détecter un taux d’utilisation élevé du système de fichiers du cluster Amazon ECS. Si le taux d’utilisation du système de fichiers est constamment élevé, vérifiez l’utilisation du disque.

Intention : cette alarme est utilisée pour détecter un taux d’utilisation élevé du système de fichiers du cluster Amazon ECS. Un taux d’utilisation élevé et constant du système de fichiers peut indiquer un goulot d’étranglement des ressources ou des problèmes de performance des applications, et peut empêcher l’exécution de nouvelles tâches.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : vous pouvez généralement définir le seuil d’utilisation du processeur entre 90 et 95 %. Vous pouvez ajuster cette valeur en fonction du niveau de capacité acceptable du système de fichiers du cluster Amazon ECS. Pour certains systèmes, un taux d’utilisation élevé et constant du système de fichiers peut être normal et ne pas être le signe d’un problème, tandis que pour d’autres, cela peut être source de préoccupation, entraîner des problèmes de performances et empêcher l’exécution de nouvelles tâches.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

PercentIOLimit

Dimensions : FileSystemId

Description de l'alarme : cette alarme permet de garantir que la charge de travail reste dans les limites d'E/S disponibles pour le système de fichiers. Si la métrique atteint régulièrement sa limite d'E/S, envisagez de déplacer l'application vers un système de fichiers utilisant les performances d'E/S maximales comme mode. Pour résoudre les problèmes, vérifiez les clients connectés au système de fichiers et les applications des clients qui limitent le système de fichiers.

Intention : cette alarme est utilisée pour détecter à quel point le système de fichiers est proche d'atteindre la limite d'E/S du mode de performance à usage général. Un pourcentage d'E/S élevé et persistant peut indiquer que le système de fichiers ne peut pas s'adapter suffisamment aux requêtes d'E/S et qu'il peut constituer un goulot d'étranglement pour les applications qui utilisent le système de fichiers.

Statistique : moyenne

Seuil recommandé : 100,0

Justification du seuil : lorsque le système de fichiers atteint sa limite d'E/S, il risque de répondre plus lentement aux requêtes de lecture et d'écriture. Par conséquent, il est recommandé de surveiller la métrique afin d'éviter toute incidence sur les applications qui utilisent le système de fichiers. Le seuil peut être fixé aux alentours de 100 %. Toutefois, cette valeur peut être ajustée à une valeur inférieure en fonction des caractéristiques du système de fichiers.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Dimensions : FileSystemId

Description de l'alarme : cette alarme permet de garantir qu'un solde de crédit de débordement est disponible pour l'utilisation du système de fichiers. Lorsqu'aucun crédit de débordement n'est disponible, l'accès des applications au système de fichiers est limité en raison du faible débit. Si la métrique tombe régulièrement à 0, envisagez de changer le mode de débit en mode de débit Elastic ou alloué.

Objectif : cette alarme est utilisée pour détecter un faible solde de crédit de débordement du système de fichiers. Un faible solde de crédit de débordement persistant peut être un indicateur du ralentissement du débit et de l'augmentation de la latence des E/S.

Statistique : moyenne

Seuil recommandé : 0,0

Justification du seuil : lorsque le système de fichiers n'a plus de crédits en rafale et même si le débit de référence est inférieur, EFS continue de fournir un débit mesuré de 1 MiBps à tous les systèmes de fichiers. Cependant, il est recommandé de surveiller le faible solde de crédit de débordement de la métrique afin d'éviter que le système de fichiers ne constitue un goulot d'étranglement des ressources pour les applications. Le seuil peut être défini autour de 0 octet.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : LESS_THAN_OR_EQUAL_TO_THRESHOLD

node_cpu_utilization

Dimensions : ClusterName

Description de l'alarme : cette alarme permet de détecter une utilisation élevée du processeur dans les composants master du cluster EKS. Si le taux d'utilisation est constamment élevé, cela peut indiquer la nécessité de remplacer vos composants master par des instances dotées d'un processeur plus puissant ou de mettre à l'échelle le système horizontalement.

Objectif : cette alarme permet de surveiller l'utilisation du processeur par les composants master du cluster EKS afin que les performances du système ne se dégradent pas.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : il est recommandé de définir le seuil à un niveau inférieur ou égal à 80 % afin de laisser suffisamment de temps pour corriger le problème avant que le système ne commence à en ressentir l'impact.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

node_filesystem_utilization

Dimensions : ClusterName

Description de l'alarme : cette alarme permet de détecter un taux d'utilisation élevé du système de fichiers dans les composants master du cluster EKS. Si le taux d'utilisation est constamment élevé, vous devrez peut-être mettre à jour vos composants master pour augmenter le volume de disque, ou vous devrez peut-être effectuer une mise à l'échelle horizontale.

Objectif : cette alarme permet de surveiller le taux d'utilisation du système de fichiers par les composants master du cluster EKS. Si le taux d'utilisation atteint 100 %, cela peut entraîner une défaillance de l'application, des blocages d'E/S sur le disque, l'expulsion du pod ou un arrêt complet du nœud.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : si la pression sur le disque est suffisante (ce qui signifie que le disque est plein), les nœuds sont marqués comme non sains et les pods sont expulsés du nœud. Les pods d'un nœud soumis à une pression sur le disque sont expulsés lorsque le système de fichiers disponible est inférieur aux seuils d'expulsion définis sur le kubelet. Définissez le seuil d'alarme afin de disposer de suffisamment de temps pour réagir avant que le nœud ne soit expulsé du cluster.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

node_memory_utilization

Dimensions : ClusterName

Description de l'alarme : cette alarme permet de détecter un taux d'utilisation élevé de la mémoire dans les composants master du cluster EKS. Si le taux d'utilisation est constamment élevé, cela peut indiquer la nécessité de mettre à l'échelle le nombre de réplicas de pods ou d'optimiser votre application.

Objectif : cette alarme permet de surveiller le taux d'utilisation de la mémoire par les composants master du cluster EKS afin que les performances du système ne se dégradent pas.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : il est recommandé de définir le seuil à un niveau inférieur ou égal à 80 % afin de disposer de suffisamment de temps pour corriger le problème avant que le système ne commence à en ressentir l'impact.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Dimensions : espace ClusterName de noms, service

Description de l'alarme : cette alarme permet de détecter un taux d'utilisation élevé du processeur dans les pods du cluster EKS. Si le taux d'utilisation est constamment élevé, cela peut indiquer la nécessité d'augmenter la limite du processeur pour le pod concerné.

Objectif : cette alarme permet de surveiller le taux d'utilisation du processeur par les pods appartenant à un service Kubernetes dans le cluster EKS, afin que vous puissiez rapidement identifier si le pod d'un service consomme plus de processeur que prévu.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : il est recommandé de définir le seuil à un niveau inférieur ou égal à 80 % afin de disposer de suffisamment de temps pour corriger le problème avant que le système ne commence à en ressentir l'impact.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensions : espace ClusterName de noms, service

Description de l'alarme : cette alarme permet de détecter un taux d'utilisation élevé de la mémoire dans les pods du cluster EKS. Si le taux d'utilisation est constamment élevé, cela peut indiquer la nécessité d'augmenter la limite de mémoire pour le pod concerné.

Objectif : cette alarme permet de surveiller le taux d'utilisation de la mémoire par les pods du cluster EKS afin que les performances du système ne se dégradent pas.

Statistique : maximum

Seuil recommandé : 80,0

Justification du seuil : il est recommandé de définir le seuil à un niveau inférieur ou égal à 80 % afin de disposer de suffisamment de temps pour corriger le problème avant que le système ne commence à en ressentir l'impact.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

GetRecords.IteratorAgeMilliseconds

Dimensions : StreamName

Description de l'alarme : cette alarme peut détecter si l'ancienneté maximale de l'itérateur est trop élevée. Pour les applications de traitement de données en temps réel, configurez la conservation des données en fonction de la tolérance du délai. Il s'agit généralement de quelques minutes. Pour les applications qui traitent des données historiques, utilisez cette métrique pour surveiller la vitesse de rattrapage. Une solution rapide pour arrêter la perte de données consiste à augmenter la période de conservation pendant que vous résolvez le problème. Vous pouvez également augmenter le nombre de travailleurs qui traitent les dossiers dans votre application client. Les causes les plus courantes de l'augmentation progressive de l'ancienneté de l'itérateur sont l'insuffisance des ressources physiques ou une logique de traitement des enregistrements qui ne s'est pas adaptée à l'augmentation du débit des flux. Veuillez consulter ce lien pour plus de détails.

Intention : cette alarme est utilisée pour détecter si les données de votre flux vont expirer parce qu'elles ont été conservées trop longtemps ou parce que le traitement des enregistrements est trop lent. Il vous permet d'éviter la perte de données après avoir atteint 100 % de la durée de conservation du flux.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de la période de rétention du flux et de la tolérance du délai de traitement des enregistrements. Passez en revue vos exigences et analysez les tendances historiques, puis définissez le seuil au nombre de millisecondes qui représente un délai de traitement critique. Si l'ancienneté de l'itérateur dépasse 50 % de la période de conservation (par défaut 24 heures, configurable jusqu'à 365 jours), il y a un risque de perte de données suite à l'expiration des enregistrements. Vous pouvez surveiller la métrique pour vous assurer qu'aucune de vos partitions n'approche cette limite.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

GetRecords. Succès

Dimensions : StreamName

Description de l'alarme : cette métrique augmente chaque fois que vos clients lisent avec succès les données de votre flux. GetRecords ne renvoie aucune donnée lorsqu'il renvoie une exception. L'exception la plus courante est ProvisionedThroughputExceededException parce que le taux de requête pour le flux est trop élevé, ou parce que le débit disponible est déjà servi pour la seconde donnée. Réduisez la fréquence ou la taille de vos requêtes. Pour plus d'informations, veuillez consulter Quotas et limites de flux dans le guide du développeur Amazon Kinesis Data Streams, et Comportement des nouvelles tentatives et backoff exponentiel dans AWS (langue française non garantie).

Intention : cette alarme peut détecter si la récupération des enregistrements du flux par les consommateurs échoue. En réglant une alarme sur cette métrique, vous pouvez détecter de manière proactive tout problème lié à la consommation de données, tel qu'une augmentation du taux d'erreur ou une diminution du nombre de récupérations réussies. Cela vous permet de prendre des mesures opportunes pour résoudre les problèmes potentiels et maintenir un pipeline de traitement des données fluide.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : selon l'importance de récupérer les enregistrements du flux, définissez le seuil en fonction de la tolérance de votre application pour les enregistrements ayant échoué. Le seuil doit être le pourcentage correspondant d'opérations réussies. Vous pouvez utiliser les données GetRecords métriques historiques comme référence pour le taux d'échec acceptable. Vous devez également envisager de nouvelles tentatives lorsque vous définissez le seuil, car les enregistrements ayant échoué peuvent être réessayés. Cela permet d'éviter que des pics transitoires ne déclenchent des alertes inutiles.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

PutRecord. Succès

Dimensions : StreamName

Description de l'alarme : cette alarme détecte lorsque le nombre d'opérations PutRecord ayant échoué dépasse le seuil. Examinez les journaux des producteurs de données pour trouver les causes profondes des défaillances. La raison la plus courante est l'insuffisance du débit provisionné sur la partition à l'origine du ProvisionedThroughputExceededException. Cela se produit parce que le taux de requêtes pour le flux est trop élevé ou que le débit que l'on tente d'ingérer dans la partition est trop élevé. Réduisez la fréquence ou la taille de vos requêtes. Pour plus d'informations, consultez Streams Limits and Error Retries et Exponential Backoff in. AWS

Intention : cette alarme peut détecter si l'ingestion d'enregistrements dans le flux échoue. Elle vous aide à identifier les problèmes liés à l'écriture de données dans le flux. En réglant une alarme sur cette métrique, vous pouvez détecter de manière proactive les problèmes rencontrés par les producteurs lors de la publication de données dans le flux, tels que l'augmentation du taux d'erreur ou la diminution du nombre d'enregistrements publiés avec succès. Cela vous permet de prendre des mesures en temps opportun pour résoudre les problèmes potentiels et maintenir un processus d'ingestion de données fiable.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : selon l'importance du traitement et de l'ingestion de données pour votre service, définissez le seuil en fonction de la tolérance de votre application à l'égard des enregistrements manquants. Le seuil doit être le pourcentage correspondant d'opérations réussies. Vous pouvez utiliser les données PutRecord métriques historiques comme référence pour le taux d'échec acceptable. Vous devez également envisager de nouvelles tentatives lorsque vous définissez le seuil, car les enregistrements ayant échoué peuvent être réessayés.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Dimensions : StreamName

Description de l'alarme : cette alarme détecte lorsque le nombre de PutRecords ayant échoué dépasse le seuil. Kinesis Data Streams tente de traiter tous les enregistrements de chaque requête PutRecords, mais un seul échec d'enregistrement n'arrête pas le traitement des enregistrements suivants. La principale raison de ces défaillances est le dépassement du débit d'un flux ou d'une partition individuelle. Les causes les plus courantes sont les pics de trafic et les latences du réseau qui font que les enregistrements arrivent au flux de manière inégale. Vous devez détecter les enregistrements traités sans succès et les retenter dans un appel ultérieur. Reportez-vous à la section Gestion des défaillances lors de l'utilisation PutRecords pour plus de détails.

Objectif : cette alarme peut détecter des défaillances constantes lors de l'utilisation d'une opération par lots pour ajouter des enregistrements à votre flux. En réglant une alarme sur cette métrique, vous pouvez détecter de manière proactive une augmentation du nombre d'enregistrements échoués, ce qui vous permet de prendre des mesures opportunes pour résoudre les problèmes sous-jacents et garantir un processus d'ingestion de données fluide et fiable.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du nombre d'enregistrements ayant échoué en fonction de la tolérance de l'application pour les enregistrements échoués. Vous pouvez utiliser les données historiques comme référence pour la valeur d'échec acceptable. Vous devez également envisager de nouvelles tentatives lors de la définition du seuil, car les enregistrements ayant échoué peuvent être réessayés lors des appels suivants PutRecords .

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Dimensions : StreamName

Description de l'alarme : l'alarme suit le nombre d'enregistrements qui entraînent une limitation de la capacité de débit de lecture. Si vous constatez que vous êtes constamment limité, vous devriez envisager d'ajouter des partitions supplémentaires à votre flux afin d'augmenter le débit de lecture alloué. Si plusieurs applications consommateur s'exécutent sur le flux et qu'elles partagent la même limite GetRecords, nous vous recommandons d'enregistrer de nouvelles applications consommateur via Enhanced Fan-Out. Si l'ajout de partitions supplémentaires ne réduit pas le nombre de limitations, il se peut qu'une partition « chaude » soit lue plus souvent que les autres partitions. Activez la surveillance améliorée, trouvez la partition « chaude » et divisez-la.

Intention : cette alarme peut détecter si les consommateurs sont limités lorsqu'ils dépassent le débit de lecture que vous avez prévu (déterminé par le nombre de partitions que vous possédez). Dans ce cas, vous ne pourrez pas lire à partir du flux, et le flux pourra commencer à être sauvegardé.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : les requêtes limitées peuvent généralement être réessayées. Par conséquent, le fait de fixer le seuil à zéro rend l'alarme trop sensible. Cependant, une limitation persistante peut avoir un impact sur la lecture du flux et devrait déclencher l'alarme. Définissez le seuil sur un pourcentage en fonction des requêtes limitées pour l'application et réessayez les configurations.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Dimensions :StreamName, ConsumerName

Description de l'alarme : cette alarme détecte lorsque le délai de traitement des enregistrements dans l'application dépasse le seuil. Des problèmes transitoires tels que l'échec des opérations d'API d'une application en aval peuvent entraîner une augmentation soudaine de la métrique. Vous devriez vérifier s'ils se produisent régulièrement. Cela est souvent dû au fait que le consommateur ne traite pas les enregistrements assez rapidement en raison de ressources physiques insuffisantes ou d'une logique de traitement des enregistrements qui n'a pas été mise à l'échelle en fonction de l'augmentation du débit des flux. Le blocage des appels sur le chemin critique est souvent à l'origine de ralentissements dans le traitement des enregistrements. Vous pouvez augmenter votre parallélisme en augmentant le nombre de partitions. Vous devez également vérifier que les nœuds de traitement sous-jacents disposent de ressources physiques suffisantes pendant les pics de demande.

Intention : cette alarme peut détecter un retard dans l'événement d'abonnement à la partition du flux. Cela indique un retard de traitement et peut aider à identifier les problèmes potentiels liés aux performances de l'application client ou à l'état général du flux. Lorsque le délai de traitement devient important, vous devez examiner et corriger les éventuels obstacles ou inefficiences des applications destinées aux consommateurs afin de garantir le traitement des données en temps réel et de minimiser les retards dans le traitement des données.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : La valeur de seuil recommandée pour cette alarme dépend fortement du délai que votre application peut tolérer. Passez en revue les exigences de votre application et analysez les tendances historiques, puis sélectionnez un seuil en conséquence. Lorsque l' SubscribeToShard appel aboutit, votre client commence à recevoir SubscribeToShardEvent des événements via la connexion permanente pendant 5 minutes au maximum, après quoi vous devez appeler à SubscribeToShard nouveau pour renouveler l'abonnement si vous souhaitez continuer à recevoir des enregistrements.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Dimensions : StreamName

Description de l'alarme : cette alarme détecte le moment où le nombre d'enregistrements entraînant une limitation de la capacité du débit d'écriture a atteint le seuil. Lorsque vos producteurs dépassent le débit d'écriture prévu (déterminé par le nombre de partitions dont vous disposez), ils sont limités et vous ne pouvez pas ajouter d'enregistrements dans le flux. Pour faire face à une limitation persistante, vous devriez envisager d'ajouter des partitions à votre flux. Cela augmente le débit d'écriture que vous avez alloué et empêche toute limitation future. Vous devez également prendre en compte le choix de la clé de partition lors de l'ingestion d'enregistrements. Une clé de partition aléatoire est préférable, car elle répartit les enregistrements de manière uniforme sur les partitions du flux, dans la mesure du possible.

Intention : cette alarme peut détecter si vos producteurs sont rejetés pour avoir écrit des enregistrements en raison de la limitation du flux ou de la partition. Si votre flux est en mode provisionné, le réglage de cette alarme vous permet de prendre des mesures proactives lorsque le flux de données atteint ses limites, ce qui vous permet d'optimiser la capacité allouée ou de prendre les mesures de dimensionnement appropriées pour éviter les pertes de données et garantir un traitement fluide des données.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : les requêtes limitées peuvent généralement être réessayées. Par conséquent, le fait de définir le seuil à zéro rend l'alarme trop sensible. Cependant, une limitation persistante peut avoir un impact sur l'écriture dans le flux, et vous devez définir le seuil d'alarme pour le détecter. Définissez le seuil sur un pourcentage en fonction des requêtes limitées pour l'application et réessayez les configurations.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ClaimedAccountConcurrency

Dimensions : Aucune

Description de l'alarme : Cette alarme permet de vérifier si la simultanéité de vos fonctions Lambda se rapproche de la limite de simultanéité de votre compte au niveau de la région. Une fonction commence à être limitée si elle atteint la limite de simultanéité. Vous pouvez prendre les mesures suivantes pour éviter la limitation.

Demandez une augmentation de la simultanéité dans cette région.
Identifiez et réduisez toute simultanéité réservée inutilisée ou provisionnée.
Identifiez les problèmes de performance des fonctions afin d'améliorer la vitesse de traitement et donc le débit.
Augmentez la taille du lot des fonctions afin que davantage de messages soient traités à chaque appel de fonction.

Objectif : Cette alarme peut détecter de manière proactive si la simultanéité de vos fonctions Lambda se rapproche du quota de simultanéité régional de votre compte, afin que vous puissiez agir en conséquence. Les fonctions sont limitées si le quota de ClaimedAccountConcurrency simultanéité du compte atteint au niveau de la région. Si vous utilisez la simultanéité réservée (RC) ou la concurrence provisionnée (PC), cette alarme vous donne une meilleure visibilité sur l'utilisation de la simultanéité qu'une alarme activée. ConcurrentExecutions

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez calculer la valeur d'environ 90 % du quota de simultanéité défini pour le compte dans la région et utiliser le résultat comme valeur de seuil. Par défaut, votre compte dispose d'un quota de simultanéité de 1 000 pour toutes les fonctions d'une région. Cependant, vous devez vérifier le quota de votre compte depuis le tableau de bord des Services Quotas.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

Erreurs

Dimensions : FunctionName

Description de l'alarme : cette alarme détecte un nombre élevé d'erreurs. Les erreurs de fonction incluent les exceptions levées par votre code et par l'environnement d'exécution Lambda. Vous pouvez consulter les journaux relatifs à la fonction pour diagnostiquer le problème.

Objectif : l'alarme permet de détecter un nombre élevé d'erreurs lors des invocations de fonctions.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil sur un nombre supérieur à zéro. La valeur exacte peut dépendre de la tolérance aux erreurs de votre application. Comprenez le caractère critique des invocations gérées par la fonction. Pour certaines applications, toute erreur peut être inacceptable, tandis que d'autres applications peuvent autoriser une certaine marge d'erreur.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : GREATER_THAN_THRESHOLD

Throttles

Dimensions : FunctionName

Description de l'alarme : cette alarme détecte un nombre élevé de requêtes d'invocation limitées. La limitation se produit lorsqu'aucune simultanéité n'est disponible pour une augmentation. Plusieurs approches permettent de résoudre ce problème. 1) Demandez une augmentation de la simultanéité auprès du AWS Support de cette région. 2) Identifier les problèmes de performance de la fonction afin d'améliorer la vitesse de traitement et donc le débit. 3) Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation de fonction.

Intention : l'alarme permet de détecter un nombre élevé de requêtes d'invocation limitées pour une fonction Lambda. Il est important de savoir si les requêtes sont constamment rejetées en raison de la limitation et si vous devez améliorer les performances de la fonction Lambda ou augmenter la capacité de simultanéité pour éviter une limitation persistante.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil sur un nombre supérieur à zéro. La valeur exacte du seuil peut dépendre de la tolérance de l'application. Définissez le seuil en fonction de son utilisation et des exigences de mise à l'échelle de la fonction.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Durée

Dimensions : FunctionName

Description de l'alarme : cette alarme détecte les longues durées de traitement d'un événement par une fonction Lambda. Les longues durées peuvent être dues à des modifications du code de la fonction qui allongent son exécution ou à un allongement de l'exécution des dépendances de la fonction.

Objectif : cette alarme peut détecter une longue durée d'exécution d'une fonction Lambda. Une durée d'exécution élevée indique qu'une fonction met plus de temps à être invoquée et peut également avoir un impact sur la capacité d'invocation simultanée si Lambda gère un plus grand nombre d'événements. Il est essentiel de savoir si le temps d'exécution de la fonction Lambda est constamment plus long que prévu.

Statistique : p90

Seuil recommandé : dépend de votre situation

Justification du seuil : le seuil de durée dépend de votre application et de vos charges de travail, ainsi que de vos exigences en matière de performances. Pour les exigences de haute performance, fixez le seuil à un délai plus court pour voir si la fonction répond aux attentes. Vous pouvez également analyser les données historiques pour les métriques de durée afin de déterminer si le temps nécessaire correspond aux attentes de performance de la fonction, puis définir le seuil sur une durée supérieure à la moyenne historique. Assurez-vous de définir un seuil inférieur au délai d'expiration de fonction configuré.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ConcurrentExecutions

Dimensions : FunctionName

Description de l'alarme : cette alarme permet de vérifier si la simultanéité de la fonction se rapproche de la limite de simultanéité de votre compte au niveau de la région. Une fonction commence à être limitée si elle atteint la limite de simultanéité. Vous pouvez prendre les mesures suivantes pour éviter la limitation.

Demandez une augmentation de la simultanéité dans cette région.
Identifiez les problèmes de performance des fonctions afin d'améliorer la vitesse de traitement et donc le débit.
Augmentez la taille du lot des fonctions afin que davantage de messages soient traités à chaque appel de fonction.

Pour obtenir une meilleure visibilité sur la simultanéité réservée et l'utilisation de la simultanéité provisionnée, définissez plutôt une alarme sur la nouvelle métrique. ClaimedAccountConcurrency

Objectif : cette alarme peut détecter de manière proactive si la simultanéité de la fonction se rapproche du quota de simultanéité de votre compte au niveau de la région, afin que vous puissiez agir en conséquence. Une fonction est limitée si elle atteint le quota de simultanéité du compte au niveau de la région.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : fixez le seuil à environ 90 % du quota de simultanéité défini pour le compte dans la région. Par défaut, votre compte dispose d'un quota de simultanéité de 1 000 pour toutes les fonctions d'une région. Cependant, vous pouvez vérifier le quota de votre compte, car il peut être augmenté en contactant le AWS support.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

memory_utilization

Dimensions : function_name

Description de l'alarme : cette alarme est utilisée pour détecter si le taux d'utilisation de la mémoire par une fonction Lambda se rapproche de la limite configurée. Pour résoudre les problèmes, vous pouvez essayer de 1) Optimiser votre code. 2) Dimensionner correctement votre allocation de mémoire en estimant avec précision les besoins en mémoire. Vous pouvez vous référer à Lambda Power Tuning pour cela. 3) Utiliser le regroupement des connexions. Veuillez consulter le billet de blog Using Amazon RDS Proxy with Lambda au sujet du regroupement de connexions pour une base de données RDS. 4) Vous pouvez également envisager de concevoir vos fonctions de manière à éviter de stocker de grandes quantités de données en mémoire entre les invocations.

Intention : cette alarme est utilisée pour détecter si le taux d'utilisation de la mémoire pour la fonction Lambda se rapproche de la limite configurée.

Statistique : moyenne

Seuil suggéré : 90,0

Justification du seuil : définissez le seuil à 90 % pour recevoir une alerte lorsque le taux d'utilisation de la mémoire dépasse 90 % de la mémoire allouée. Vous pouvez l'ajuster à une valeur inférieure si la charge de travail liée à l'utilisation de la mémoire vous préoccupe. Vous pouvez également vérifier les données historiques de cette métrique et définir le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

ComparisonOperator: SUPÉRIEUR AU SEUIL

ErrorPortAllocation

Dimensions : NatGatewayId

Description de l'alarme : cette alarme permet de détecter les cas où la passerelle NAT n'est pas en mesure d'allouer des ports à de nouvelles connexions. Pour résoudre ce problème, veuillez consulter Résoudre les erreurs d'allocation de port sur la passerelle NAT.

Intention : cette alarme est utilisée pour détecter si la passerelle NAT n'a pas été en mesure d'allouer un port source.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : si la valeur de ErrorPortAllocation est supérieure à zéro, cela signifie que trop de connexions simultanées vers une seule destination populaire sont ouvertes via NatGateway.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

PacketsDropCount

Dimensions : NatGatewayId

Description de l'alarme : cette alarme permet de détecter quand des paquets sont abandonnés par la passerelle NAT. Cela peut être dû à un problème avec la passerelle NAT. Consultez le tableau de bord de santé du AWS service pour connaître l'état de la passerelle AWS NAT dans votre région. Cela peut vous aider à établir une corrélation entre le problème de réseau et le trafic utilisant la passerelle NAT.

Intention : cette alarme est utilisée pour détecter si des paquets sont abandonnés par la passerelle NAT.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : il convient de calculer la valeur de 0,01 % du trafic total sur la passerelle NAT et d'utiliser ce résultat comme valeur seuil. Utilisez les données historiques du trafic sur la passerelle NAT pour déterminer le seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

PacketsDropped

Dimensions : VPC Id, VPC Endpoint Id, Endpoint Type, Subnet Id, Service Name

Description de l'alarme : cette alarme permet de détecter si le terminal ou le service du point de terminaison est défectueux en surveillant le nombre de paquets abandonnés par le point de terminaison. Notez que les paquets de plus de 8 500 octets arrivant au point de terminaison d'un VPC sont abandonnés. Pour la résolution de ce problème, veuillez consulter Problèmes de connectivité entre le point de terminaison d'un VPC d'interface et un service de point de terminaison.

Intention : cette alarme est utilisée pour détecter si le point de terminaison ou le service de point de terminaison n'est pas sain.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil en fonction du cas d'utilisation. Si vous souhaitez être informé de l'état non sain d'un point de terminaison ou d'un service de point de terminaison, vous devez fixer un seuil bas afin de pouvoir résoudre le problème avant qu'une perte de données considérable ne se produise. Vous pouvez utiliser les données historiques pour comprendre la tolérance aux paquets abandonnés et définir le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

RstPacketsSent

Dimensions : Service Id, Load Balancer Arn, Az

Description de l'alarme : cette alarme vous aide à détecter les cibles non saines d'un service de point de terminaison en fonction du nombre de paquets de réinitialisation envoyés aux points de terminaison. Lorsque vous corrigez des erreurs de connexion avec un client de votre service, vous pouvez vérifier si le service réinitialise les connexions avec la RstPacketsSent métrique ou si quelque chose d'autre échoue sur le chemin réseau.

Intention : cette alarme est utilisée pour détecter les cibles non saines d'un service de point de terminaison.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : le seuil dépend du cas d'utilisation. Si votre cas d'utilisation peut tolérer que les cibles ne soient pas saines, vous pouvez définir un seuil élevé. Si le scénario d'utilisation ne tolère pas les cibles non saines, vous pouvez définir le seuil à un niveau très bas.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

CPUUtilization

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller un taux d’utilisation élevé et constant du processeur. Le taux d’utilisation du processeur mesure le temps de non inactivité. Envisagez d’utiliser la Surveillance améliorée ou Performance Insights pour déterminer quel temps d’attente occupe le plus de temps processeur (guest, irq, wait, nice, etc.) pour MariaDB, MySQL, Oracle et PostgreSQL. Évaluez ensuite quelles requêtes consomment le plus de ressources processeur. Si vous ne parvenez pas à ajuster votre charge de travail, envisagez de passer à une classe d’instance de base de données plus importante.

Intention : cette alarme est utilisée pour détecter une utilisation élevée constante du processeur afin d’éviter des temps de réponse et des délais d’expiration très élevés. Si vous souhaitez vérifier la microsaturation de l’utilisation du processeur, vous pouvez définir une durée d’évaluation des alarmes plus courte.

Statistique : moyenne

Seuil recommandé : 90,0

Justification du seuil : les pics aléatoires de consommation du processeur ne nuisent peut-être pas aux performances de la base de données, mais une charge processeur élevée et prolongée peut gêner les requêtes de la base de données à venir. En fonction de la charge de travail globale de la base de données, une charge processeur élevée au niveau de votre instance RDS/Aurora peut dégrader les performances globales.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

DatabaseConnections

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme détecte un nombre élevé de connexions. Passez en revue les connexions existantes et mettez fin à celles qui sont en état de « veille » ou qui ne sont pas correctement fermées. Envisagez d’utiliser le regroupement de connexions pour limiter le nombre de nouvelles connexions. Vous pouvez également augmenter la taille de l’instance de base de données pour utiliser une classe avec plus de mémoire et donc une valeur par défaut plus élevée pour « max_connections » ou augmenter la valeur « max_connections » dans RDS et Aurora MySQL et PostgreSQL pour la classe actuelle si elle peut supporter votre charge de travail.

Intention : cette alarme est utilisée pour empêcher le rejet de connexions lorsque le nombre maximum de connexions à la base de données est atteint. Cette alarme n’est pas recommandée si vous changez fréquemment de classe d’instance de base de données, car cela modifie la mémoire et le nombre maximal de connexions par défaut.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : le nombre de connexions autorisées dépend de la taille de votre classe d’instance de base de données et des paramètres spécifiques au moteur de base de données relatifs aux processus/connexions. Vous devez évaluer une valeur comprise entre 90 et 95 % du nombre maximal de connexions pour votre base de données et utiliser ce pourcentage comme valeur seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

% EBS ByteBalance

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller un faible pourcentage de crédits de débit restants. Pour résoudre les problèmes, vérifiez les problèmes de latence dans RDS.

Intention : cette métrique indique le pourcentage de crédit de débit restant dans le compartiment de débordement. Un faible pourcentage d’équilibrage des octets peut entraîner des problèmes de goulot d’étranglement au niveau du débit. Cette alarme n’est pas recommandée pour les instances Aurora PostgreSQL.

Statistique : moyenne

Seuil recommandé : 10,0

Justification du seuil : un solde de crédit de débit inférieur à 10 % est considéré comme faible et vous devez définir le seuil en conséquence. Vous pouvez également définir un seuil inférieur si votre application peut tolérer un débit inférieur pour la charge de travail.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : LESS_THAN_THRESHOLD

EBSIOBalance%

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller le faible pourcentage de crédits IOPS restants. Pour résoudre les problèmes, veuillez consulter la rubrique Problèmes de latence dans RDS.

Intention : cette métrique indique le pourcentage de crédits d’E/S restant dans le compartiment de débordement. Un faible pourcentage de solde d’IOPS peut entraîner des problèmes de blocage des IOPS. Cette alarme n’est pas recommandée pour les instances Aurora.

Statistique : moyenne

Seuil recommandé : 10,0

Justification du seuil : un solde de crédits IOPS inférieur à 10 % est considéré comme faible et vous pouvez définir le seuil en conséquence. Vous pouvez également définir un seuil inférieur si votre application peut tolérer un taux d’IOPS inférieur pour la charge de travail.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : LESS_THAN_THRESHOLD

FreeableMemory

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller une faible quantité de mémoire libérable, ce qui peut signifier qu’il y a un pic dans les connexions à la base de données ou que votre instance est soumise à une forte sollicitation de mémoire. Vérifiez la pression de la mémoire en surveillant les CloudWatch métriques pour SwapUsage « en plus deFreeableMemory. Si la consommation de mémoire de l’instance est fréquemment trop élevée, c’est le signe que vous devriez vérifier votre charge de travail ou mettre à niveau votre classe d’instance. Pour l’instance en lecture de la base de données Aurora, envisagez d’ajouter d’autres instances en lecture de la base de données au cluster. Pour plus d’informations sur le dépannage d’Aurora, veuillez consulter la rubrique Problèmes liés à la mémoire libérable.

Intention : cette alarme est utilisée pour éviter de manquer de mémoire, ce qui peut entraîner le rejet de connexions.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : en fonction de la charge de travail et de la classe d’instance, différentes valeurs de seuil peuvent être appropriées. Idéalement, la mémoire disponible ne devrait pas être inférieure à 25 % de la mémoire totale pendant de longues périodes. Pour Aurora, vous pouvez fixer un seuil proche de 5 %, car une métrique proche de 0 signifie que l’instance de la base de données a été mise à l’échelle autant qu’elle le pouvait. Vous pouvez analyser le comportement historique de cette métrique afin de déterminer des seuils raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : LESS_THAN_THRESHOLD

FreeLocalStorage

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller le faible niveau de stockage local disponible. Aurora Édition compatible avec PostgreSQL utilise le stockage local pour stocker les journaux d’erreurs et les fichiers temporaires. Aurora MySQL utilise le stockage local pour stocker les journaux d'erreurs, les journaux généraux, les journaux de requêtes lentes, les journaux d'audit et les tables temporaires autres qu'InnoDB. Ces volumes de stockage locaux sont sauvegardés par Amazon EBS et peuvent être étendus en utilisant une classe d’instance de base de données plus grande. Pour résoudre les problèmes, vérifiez Aurora Édition compatible avec PostgreSQL et Édition compatible avec MySQL.

Intention : cette alarme est utilisée pour détecter dans quelle mesure l’instance de base de données Aurora est proche de la limite de stockage locale, si vous n’utilisez pas Aurora sans serveur v2 ou version ultérieure. Le stockage local peut atteindre sa capacité maximale lorsque vous stockez des données non persistantes, telles que des tables temporaires et des fichiers journaux, dans le stockage local. Cette alarme peut empêcher qu'une out-of-space erreur ne se produise lorsque votre instance de base de données n'a plus de stockage local.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez évaluer environ 10 à 20 % de la quantité de stockage disponible en fonction de la vitesse et de la tendance de l’utilisation du volume, puis utiliser ce pourcentage comme valeur de seuil pour prendre des mesures proactives avant que le volume n’atteigne sa limite.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

FreeStorageSpace

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme surveille la faible quantité d’espace de stockage disponible. Envisagez d’augmenter le stockage de votre base de données si vous approchez fréquemment des limites de capacité de stockage. Prévoyez une marge de manœuvre pour faire face aux augmentations imprévues des besoins de vos applications. Vous pouvez également envisager d’activer l’autoscaling du stockage RDS. Pensez également à libérer de l’espace en supprimant les données et les journaux inutilisés ou périmés. Pour plus d’informations, vérifiez le document RDS manque d’espace de stockage et le document Problèmes de stockage PostgreSQL.

Intention : cette alarme permet d’éviter les problèmes de stockage saturés. Cela permet d’éviter les temps d’arrêt qui surviennent lorsque votre instance de base de données est à court d’espace de stockage. Nous ne recommandons pas l’utilisation de cette alarme si l’option autoscaling du stockage est activée ou si vous modifiez fréquemment la capacité de stockage de l’instance de la base de données.

Statistique : minimum

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur du seuil dépend de l’espace de stockage actuellement alloué. En règle générale, vous devez évaluer la valeur de 10 % de l’espace de stockage alloué et utiliser ce pourcentage comme valeur de seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

MaximumUsedTransactionIdentifiants

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet d’empêcher l’encapsulation des identifiants de transaction pour PostgreSQL. Reportez-vous aux étapes de résolution des problèmes décrites dans ce blog pour étudier et résoudre le problème. Vous pouvez également consulter ce blog pour vous familiariser davantage avec les concepts d’autovacuum, les problèmes courants et les meilleures pratiques.

Intention : cette alarme est utilisée pour empêcher l’encapsulation des identifiants de transaction pour PostgreSQL.

Statistique : moyenne

Seuil recommandé : 1,0E9

Justification du seuil : fixer ce seuil à 1 milliard devrait vous donner le temps d’étudier le problème. La valeur par défaut de autovacuum_freeze_max_age est de 200 millions. Si l’âge de la transaction la plus ancienne est de 1 milliard, autovacuum a du mal à maintenir ce seuil en dessous de l’objectif de 200 millions d’identifiants de transaction.

Période : 60

Points de données pour le déclenchement d'alarme : 1

Période d'évaluation : 1

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReadLatency

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller une latence de lecture élevée. Si la latence de stockage est élevée, c’est parce que la charge de travail dépasse les limites de ressources. Vous pouvez examiner l’utilisation des E/S par rapport à l’instance et à la configuration du stockage alloué. Reportez-vous au document Résoudre les problèmes de latence des volumes Amazon EBS causée par un goulot d’étranglement IOPS. Pour Aurora, vous pouvez passer à une classe d’instance dotée d’une configuration de stockage I/O-Optimized. Veuillez consulter l’article de blog Planning I/O in Aurora pour obtenir des conseils.

Intention : cette alarme est utilisée pour détecter une latence de lecture élevée. Les disques de base de données ont généralement une faible latence de lecture/écriture, mais ils peuvent connaître des problèmes susceptibles d’entraîner des opérations à latence élevée.

Statistique : p90

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de votre cas d'utilisation. Les latences de lecture supérieures à 20 millisecondes sont un motif raisonnable d’investigation. Vous pouvez également définir un seuil plus élevé si votre application peut supporter une latence plus élevée pour les opérations de lecture. Examinez la criticité et les exigences de la latence de lecture et analysez le comportement historique de cette métrique afin de déterminer des niveaux de seuil raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ReplicaLag

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme vous aide à comprendre le nombre de secondes de retard d’un réplica par rapport à l’instance principale. Un réplica en lecture PostgreSQL consigne un délai de réplication pouvant atteindre cinq minutes si aucune transaction utilisateur ne se produit sur l’instance de base de données source. Lorsque la ReplicaLag métrique atteint 0, la réplique a rattrapé l'instance de base de données principale. Si la ReplicaLag métrique renvoie -1, la réplication n'est actuellement pas active. Pour obtenir des conseils relatifs à RDS PostgreSQL, consultez les meilleures pratiques en matière de réplication et pour le ReplicaLag dépannage et les erreurs associées, consultez la section Résolution des problèmes. ReplicaLag

Intention : cette alarme peut détecter le décalage de réplication qui reflète la perte de données pouvant survenir en cas de défaillance de l’instance principale. Si le réplica prend trop de retard par rapport à l’instance principale et que cette dernière tombe en panne, les données qui se trouvaient dans l’instance principale seront manquantes dans le réplica.

Statistique : maximum

Seuil recommandé : 60,0

Justification du seuil : le délai acceptable dépend généralement de l’application. Nous recommandons de ne pas dépasser 60 secondes.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : GREATER_THAN_THRESHOLD

WriteLatency

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller une latence d’écriture élevée. Si la latence de stockage est élevée, c’est parce que la charge de travail dépasse les limites de ressources. Vous pouvez examiner l’utilisation des E/S par rapport à l’instance et à la configuration du stockage alloué. Reportez-vous au document Résoudre les problèmes de latence des volumes Amazon EBS causée par un goulot d’étranglement IOPS. Pour Aurora, vous pouvez passer à une classe d’instance dotée d’une configuration de stockage I/O-Optimized. Veuillez consulter l’article de blog Planning I/O in Aurora pour obtenir des conseils.

Intention : cette alarme est utilisée pour détecter une latence d’écriture élevée. Bien que les disques de base de données présentent généralement une faible latence de lecture/écriture, ils peuvent connaître des problèmes susceptibles d’entraîner des opérations à latence élevée. La surveillance de ce phénomène vous permettra de vous assurer que la latence du disque est aussi faible que prévu.

Statistique : p90

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de votre cas d'utilisation. Les latences d’écriture supérieures à 20 millisecondes sont un motif raisonnable d’investigation. Vous pouvez également définir un seuil plus élevé si votre application peut supporter une latence plus élevée pour les opérations d’écriture. Examinez la criticité et les exigences de la latence d’écriture et analysez le comportement historique de cette métrique afin de déterminer des niveaux de seuil raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

DBLoad

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller une charge de base de données élevée. Si le nombre de processus dépasse le nombre de vCPU, les processus sont mis en file d'attente. Lorsque la file d’attente augmente, les performances sont affectées. Si la charge de la base de données dépasse souvent le nombre maximal de processeurs virtuels et que l’état d’attente principal est CPU, cela signifie que le processeur est surchargé. Dans ce cas, vous pouvez surveiller CPUUtilization, DBLoadCPU et mettre des tâches en file d’attente dans Performance Insights/Surveillance améliorée. Vous pouvez décider de limiter les connexions à l’instance, d’ajuster les requêtes SQL dont la charge processeur est élevée ou d’opter pour une classe d’instance plus grande. Quel que soit leur état d'attente, les instances élevées et régulières indiquent que des problèmes de goulots d'étranglement ou de conflits de ressources devront peut-être être résolus.

Intention : cette alarme est utilisée pour détecter une charge élevée de la base de données. Une charge de base de données élevée peut entraîner des problèmes de performances dans l’instance de base de données. Cette alarme ne s’applique pas aux instances de base de données sans serveur.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur du nombre maximal de vCPU est déterminée par le nombre de cœurs de vCPU (processeur virtuel) de votre instance de base de données. En fonction du nombre maximal de processeurs virtuels, différentes valeurs de seuil peuvent être appropriées. Idéalement, la charge de la base de données ne doit pas dépasser la limite de vCPU.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Dimensioni : DB ClusterIdentifier

Description de l’alarme : cette alarme permet de surveiller un volume total restant faible. Lorsque le volume total restant atteint la limite de taille, le cluster signale une out-of-space erreur. Le stockage Aurora se met automatiquement à l’échelle en fonction des données contenues dans le volume du cluster et s’étend jusqu’à 128 TiB ou 64 TiB en fonction de la version du moteur de base de données. Envisagez de réduire l’espace de stockage en supprimant les tables et les bases de données dont vous n’avez plus besoin. Pour plus d’informations sur le dimensionnement du stockage, veuillez consulter la rubrique Dimensionnement du stockage.

Intention : cette alarme est utilisée pour détecter à quel point le cluster Aurora est proche de la limite de taille de volume. Cette alarme peut empêcher qu'une out-of-space erreur ne se produise lorsque votre cluster manque d'espace. Ce paramètre n’est disponible que pour Aurora.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez évaluer 10 à 20 % de la quantité de stockage disponible en fonction de la vitesse et de la tendance de l’utilisation du volume, puis utiliser ce pourcentage comme valeur de seuil pour prendre des mesures proactives avant que le volume n’atteigne sa limite.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensions : DBClusterIdentifier, Role=Writer

Description de l’alarme : cette alarme permet de surveiller l’état d’erreur de la réplication de l’instance Aurora d’enregistreur. Pour plus d'informations, consultez la section Réplication de clusters de bases de données Aurora MySQL entre AWS régions. Pour résoudre les problèmes, veuillez consulter la rubrique Problèmes de réplication Aurora MySQL.

Intention : cette alarme est utilisée pour détecter si l’instance d’enregistreur est dans un état d’erreur et n’est pas en mesure de répliquer la source. Ce paramètre n’est disponible que pour Aurora.

Statistique : moyenne

Seuil recommandé : -1,0

Justification du seuil : nous vous recommandons d’utiliser -1 comme valeur seuil, car Aurora MySQL publie cette valeur si la réplique est en état d’erreur.

Période : 60

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller un nombre élevé de transactions bloquées dans une instance de base de données Aurora. Les transactions bloquées peuvent se terminer par une restauration (rollback) ou une validation (commit). Un taux élevé de simultanéité, des interruptions de transaction ou des transactions de longue durée peuvent entraîner le blocage des transactions. Pour résoudre les problèmes, veuillez consulter la documentation d’Aurora MySQL.

Intention : cette alarme est utilisée pour détecter un nombre élevé de transactions bloquées dans une instance de base de données Aurora afin d’empêcher les restaurations de transactions et la dégradation des performances.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez évaluer 5 % de toutes les transactions de votre instance à l’aide de la métrique ActiveTransactions et utiliser ce pourcentage comme valeur de seuil. Vous pouvez également examiner la criticité et les exigences des transactions bloquées et analyser le comportement historique de cette métrique afin de déterminer des niveaux de seuil raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme vous aide à surveiller un faible taux d’accès au cache du cluster Aurora. Un faible taux de réussite indique que vos requêtes sur cette instance de base de données vont fréquemment sur le disque. Pour résoudre les problèmes, examinez votre charge de travail pour voir quelles requêtes sont à l’origine de ce comportement, et consultez le document Recommandations RAM d’une instance de base de données.

Intention : cette alarme est utilisée pour détecter un faible taux d’accès au cache constant afin d’empêcher une baisse durable des performances de l’instance Aurora.

Statistique : moyenne

Seuil recommandé : 80,0

Justification du seuil : vous pouvez définir le seuil du taux d’accès au cache tampon à 80 %. Toutefois, vous pouvez ajuster cette valeur en fonction de votre niveau de performance acceptable et des caractéristiques de charge de travail.

Période : 60

Points de données pour le déclenchement d'alarme : 10

Période d'évaluation : 10

Opérateur de comparaison : LESS_THAN_THRESHOLD

EngineUptime

Dimensions : DBClusterIdentifier, Role=Writer

Description de l’alarme : cette alarme permet de surveiller les faibles temps d’arrêt de l’instance de base de données d’enregistreur. L’instance de base de données d’enregistreur peut tomber en panne en raison d’un redémarrage, d’une maintenance, d’une mise à niveau ou d’un basculement. Lorsque le temps de fonctionnement atteint zéro en raison d’un basculement dans le cluster, et que le cluster possède un ou plusieurs réplicas Aurora, un réplica Aurora est promu en tant qu’instance d’enregistreur principale lors d’un événement d’échec. Pour augmenter la disponibilité de votre cluster de base de données, envisagez de créer une ou plusieurs répliques Aurora dans deux ou plusieurs zones de disponibilité différentes. Pour plus d’informations, vérifiez les facteurs qui influent sur les temps d’arrêt d’Aurora.

Intention : cette alarme est utilisée pour détecter si l’instance de base de données d’enregistreur Aurora est en panne. Cela permet d’éviter une défaillance prolongée de l’instance d’enregistreur en raison d’un crash ou d’un basculement.

Statistique : moyenne

Seuil recommandé : 0,0

Justification du seuil : un événement d’échec se traduit par une brève interruption, pendant laquelle les opérations de lecture et d’écriture échouent avec une exception. Cependant, le service est généralement restauré en moins de 60 secondes, et souvent en moins de 30 secondes.

Période : 60

Points de données pour le déclenchement d'alarme : 2

Période d'évaluation : 2

Opérateur de comparaison : LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Dimensioni : DB InstanceIdentifier

Description de l’alarme : cette alarme permet de surveiller une durée constante et élevée de l’historique des segments de restauration d’une instance Aurora. Une durée élevée de la liste d’historique InnoDB indique qu’un grand nombre d’anciennes versions de lignes, de requêtes et d’arrêts de la base de données sont devenus plus lents. Pour plus d’informations et pour résoudre les problèmes, veuillez consulter la documentation La longueur de la liste d’historique InnoDB a considérablement augmenté.

Intention : cette alarme est utilisée pour détecter la longueur élevée et constante de l’historique des segments de restauration. Cela peut vous aider à éviter une dégradation durable des performances et une utilisation élevée du processeur dans l’instance Aurora. Ce paramètre n’est disponible que pour Aurora.

Statistique : moyenne

Seuil recommandé : 1 000 000,0

Justification du seuil : fixer ce seuil à 1 million devrait vous donner le temps d’étudier le problème. Toutefois, vous pouvez ajuster cette valeur en fonction de votre niveau de performance acceptable et des caractéristiques de charge de travail.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Dimensions : DBClusterIdentifier, Role=Writer

Description de l’alarme : cette alarme permet de surveiller le débit élevé du réseau de stockage. Si le débit du réseau de stockage dépasse la bande passante du réseau totale de l’instance EC2, il peut en résulter une latence élevée en lecture et en écriture, ce qui peut entraîner une dégradation des performances. Vous pouvez vérifier le type de votre instance EC2 depuis AWS la console. Pour résoudre les problèmes, vérifiez les modifications apportées aux latences d’écriture/de lecture et déterminez si vous avez également déclenché une alarme pour cette métrique. Si c’est le cas, évaluez votre schéma de charge de travail pendant les périodes où l’alarme s’est déclenchée. Cela peut vous aider à déterminer si vous pouvez optimiser votre charge de travail afin de réduire le volume total du trafic réseau. Si cela n’est pas possible, vous devrez peut-être envisager de mettre votre instance à l’échelle.

Intention : cette alarme est utilisée pour détecter un débit élevé du réseau de stockage. La détection d’un débit élevé peut empêcher les pertes de paquets réseau et la dégradation des performances.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : vous devez évaluer environ 80 % à 90 % de la bande passante du réseau totale du type d’instance EC2, puis utiliser ce pourcentage comme valeur de seuil pour agir de manière proactive avant que les paquets réseau ne soient affectés. Vous pouvez également examiner la criticité et les exigences du débit du réseau de stockage et analyser le comportement historique de cette métrique afin de déterminer des seuils raisonnables.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

HealthCheckStatus

Dimensions : HealthCheckId

Description de l'alarme : cette alarme permet de détecter les points de terminaison non sains selon les outils de surveillance de l'état. Pour comprendre la raison d'un échec entraînant un état non sain, utilisez l'onglet des outils de surveillance de l'état de la console de surveillance de l'état Route 53 pour consulter l'état de chaque région ainsi que le dernier échec de surveillance de l'état. L'onglet d'état indique également la raison pour laquelle le point de terminaison est signalé comme n'étant pas sain. Reportez-vous aux étapes de résolution des problèmes.

Intention : cette alarme utilise les outils de surveillance de l'état Route 53 pour détecter les points de terminaison non sains.

Statistique : moyenne

Seuil recommandé : 1,0

Justification du seuil : l'état du point de terminaison est signalé par la valeur 1 lorsqu'il est sain. Tout ce qui est inférieur à 1 n'est pas sain.

Période : 60

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : LESS_THAN_THRESHOLD

4xxErrors

Dimensions :BucketName, FilterId

Description de l'alarme : cette alarme nous permet de signaler le nombre total de codes d'état d'erreur 4xx créés en réponse aux requêtes des clients. Les codes d'erreur 403 peuvent indiquer une politique IAM incorrecte, et les codes d'erreur 404 peuvent indiquer un mauvais comportement de l'application client, par exemple. L'activation de la journalisation des accès au serveur S3 vous aidera à identifier l'origine du problème à l'aide des champs Code de statut HTTP et Code d'erreur. Pour en savoir plus sur le code d'erreur, veuillez consulter Réponses aux erreurs.

Objectif : cette alarme est utilisée pour créer une base de référence pour les taux d'erreur 4xx typiques afin que vous puissiez examiner toute anomalie susceptible d'indiquer un problème de configuration.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : le seuil recommandé est de détecter si plus de 5 % du total des requêtes reçoivent des erreurs 4xx. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible. Vous pouvez également ajuster le seuil en fonction de la charge des requêtes, en tenant compte d'un niveau acceptable des erreurs 4xx. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

5xxErrors

Dimensions :BucketName, FilterId

Description de l'alarme : cette alarme vous permet de détecter un grand nombre d'erreurs côté serveur. Ces erreurs indiquent qu'un client a émis une requête que le serveur n'a pas pu traiter. Cela peut vous aider à établir une corrélation entre le problème auquel votre application est confrontée à cause de S3. Pour plus d'informations qui vous aideront à gérer ou à réduire efficacement les erreurs, veuillez consulter Optimisation des modèles de conception des performances. Des erreurs peuvent également être causées par un problème avec S3. Consultez le tableau de bord de l'état du service AWS pour connaître l'état d'Amazon S3 dans votre région.

Intention : cette alarme peut aider à détecter si l'application rencontre des problèmes dus à des erreurs 5xx.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : nous recommandons de définir le seuil pour détecter si plus de 5 % du total des requêtes reçoivent une erreur 5xx. Vous pouvez toutefois ajuster le seuil en fonction du trafic des requêtes, ainsi que des taux d'erreur acceptables. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

OperationsFailedReplication

SourceBucketDimensioni : DestinationBucket, RuleId

Description de l'alarme : cette alarme aide à comprendre un échec de réplication. Cette métrique suit l'état des nouveaux objets répliqués à l'aide de S3 CRR ou S3 SRR, et suit également les objets existants répliqués à l'aide de la réplication par lots S3. Veuillez consulter Résolution des problèmes de réplication pour plus de détails.

Intention : cette alarme est utilisée pour détecter l'échec d'une opération de réplication.

Statistique : maximum

Seuil recommandé : 0,0

Justification du seuil : cette métrique émet une valeur de 0 pour les opérations réussies, et rien lorsqu'aucune opération de réplication n'est effectuée dans la minute. Lorsque la métrique émet une valeur supérieure à 0, cela signifie que l'opération de réplication a échoué.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

4xxErrors

Dimensions :AccessPointName, DataSource ARN

Description de l'alarme : cette alarme nous aide à signaler le nombre total de codes d'erreur 4xx créés en réponse aux requêtes des clients. L'activation de la journalisation des accès au serveur S3 vous aidera à identifier l'origine du problème à l'aide des champs Code de statut HTTP et Code d'erreur.

Objectif : cette alarme est utilisée pour créer une base de référence pour les taux d'erreur 4xx typiques afin que vous puissiez examiner toute anomalie susceptible d'indiquer un problème de configuration.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : nous vous recommandons de définir le seuil pour détecter si plus de 5 % du total des requêtes reçoivent une erreur 4xx. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible. Vous pouvez également ajuster le seuil en fonction de la charge des requêtes, en tenant compte d'un niveau acceptable des erreurs 4xx. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

5xxErrors

Dimensions :AccessPointName, DataSource ARN

Description de l'alarme : cette alarme permet de détecter un nombre élevé d'erreurs côté serveur. Ces erreurs indiquent qu'un client a émis une requête que le serveur n'a pas pu traiter. Ces erreurs peuvent être dues à un problème avec S3. Consultez le tableau de bord de l'état du service AWS pour connaître l'état d'Amazon S3 dans votre région. Cela peut vous aider à établir une corrélation entre le problème auquel votre application est confrontée à cause de S3. Pour obtenir des informations qui vous aideront à gérer ou à réduire efficacement ces erreurs, veuillez consulter Optimisation des modèles de conception des performances.

Intention : cette alarme peut aider à détecter si l'application rencontre des problèmes dus à des erreurs 5xx.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : nous recommandons de définir le seuil pour détecter si plus de 5 % du total des requêtes reçoivent des erreurs 5xx. Vous pouvez toutefois ajuster le seuil en fonction du trafic des requêtes, ainsi que des taux d'erreur acceptables. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

LambdaResponse4xx

Dimensions :AccessPointName, DataSource ARN

Description de l'alarme : cette alarme vous aide à détecter et à diagnostiquer les défaillances (500) lors des appels à S3 Object Lambda. Ces erreurs peuvent être causées par des erreurs ou de mauvaises configurations dans la fonction Lambda chargée de répondre à vos requêtes. L'étude des flux de CloudWatch log de la fonction Lambda associée au point d'accès Object Lambda peut vous aider à identifier l'origine du problème en fonction de la réponse de S3 Object Lambda.

Intention : Cette alarme est utilisée pour détecter les erreurs du client 4xx lors des WriteGetObjectResponse appels.

Statistique : moyenne

Seuil recommandé : 0,05

Justification du seuil : nous vous recommandons de définir le seuil pour détecter si plus de 5 % du total des requêtes reçoivent une erreur 4xx. Les erreurs 4xx fréquentes doivent faire l'objet d'une alarme. Cependant, le réglage d'une valeur très faible pour le seuil peut rendre l'alarme trop sensible. Vous pouvez également ajuster le seuil en fonction de la charge des requêtes, en tenant compte d'un niveau acceptable des erreurs 4xx. Vous pouvez également analyser les données historiques afin de déterminer le taux d'erreur acceptable pour la charge de travail de l'application, puis ajuster le seuil en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_THRESHOLD

NumberOfMessagesPublished

Dimensions : TopicName

Description de l'alarme : cette alarme peut détecter lorsque le nombre de messages SNS publiés est trop faible. Pour résoudre les problèmes, vérifiez pourquoi les diffuseurs de publication envoient moins de trafic.

Objectif : cette alarme vous permet de surveiller et de détecter de manière proactive les baisses importantes du nombre de notifications publiées. Cela vous aide à identifier les problèmes potentiels liés à votre application ou à vos processus métier, afin que vous puissiez prendre les mesures appropriées pour maintenir le flux de notifications attendu. Vous devez créer cette alarme si vous vous attendez à ce que le trafic de votre système soit réduit au minimum.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : le nombre de messages publiés doit correspondre au nombre attendu de messages publiés pour votre application. Vous pouvez également analyser les données historiques, les tendances et le trafic pour trouver le bon seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Dimensions : TopicName

Description de l'alarme : cette alarme peut détecter lorsque le nombre de messages SNS délivrés est trop faible. Cela peut être dû à la désinscription involontaire d'un point de terminaison ou à un événement SNS qui retarde les messages.

Intention : cette alarme vous aide à détecter une baisse du volume des messages délivrés. Vous devez créer cette alarme si vous vous attendez à ce que le trafic de votre système soit réduit au minimum.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : le nombre de messages délivrés doit être conforme au nombre attendu de messages produits et au nombre de consommateurs. Vous pouvez également analyser les données historiques, les tendances et le trafic pour trouver le bon seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Dimensions : TopicName

Description de l'alarme : cette alarme peut détecter lorsque le nombre de messages SNS ayant échoué est trop élevé. Pour résoudre les problèmes d'échec des notifications, activez la journalisation dans CloudWatch Logs. La consultation des journaux peut vous aider à identifier les abonnés défaillants, ainsi que les codes de statut qu'ils renvoient.

Objectif : cette alarme vous aide à détecter de manière proactive les problèmes liés à l'envoi des notifications et à prendre les mesures appropriées pour y remédier.

Statistique : somme

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement de l'impact des notifications échouées. Passez en revue les SLA fournis à vos utilisateurs finaux, la tolérance aux pannes et le caractère critique des notifications, analysez les données historiques, puis sélectionnez un seuil en conséquence. Le nombre de notifications ayant échoué doit être de 0 pour les rubriques qui n'ont que des abonnements SQS, Lambda ou Firehose.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Dimensions : TopicName

Description de l'alarme : cette alarme permet de surveiller et de résoudre les problèmes potentiels avec le diffuseur de publication ou les abonnés. Vérifiez si un diffuseur de publication publie des messages dont les attributs ne sont pas valides ou si un filtre inapproprié est appliqué à un abonné. Vous pouvez également analyser CloudWatch les journaux pour identifier la cause première du problème.

Intention : l'alarme est utilisée pour détecter si les messages publiés ne sont pas valides ou si des filtres inappropriés ont été appliqués à un abonné.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : les attributs non valides sont presque toujours le résultat d'une erreur de la part du diffuseur de publication. Nous vous recommandons de définir le seuil à 0, car aucun attribut non valide n'est attendu dans un système sain.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Dimensions : TopicName

Description de l'alarme : cette alarme permet de surveiller et de résoudre les problèmes potentiels avec le diffuseur de publication ou les abonnés. Vérifiez si un diffuseur de publication publie des messages dont le corps de message n'est pas valide ou si un filtre inapproprié est appliqué à un abonné. Vous pouvez également analyser CloudWatch les journaux pour identifier la cause première du problème.

Intention : l'alarme est utilisée pour détecter si les messages publiés ne sont pas valides ou si des filtres inappropriés ont été appliqués à un abonné.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : les corps de message non valides sont presque toujours le résultat d'une erreur de la part du diffuseur de publication. Nous vous recommandons de définir le seuil à 0, car aucun corps de message non valide n'est attendu dans un système sain.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Dimensions : TopicName

Description de l'alarme : cette alarme permet de surveiller le nombre de messages déplacés vers une file d'attente de lettres mortes.

Intention : l'alarme est utilisée pour détecter les messages placés dans une file d'attente de lettres mortes. Nous vous recommandons de créer cette alarme lorsque SNS est couplé à SQS, Lambda ou Firehose.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : dans un système sain, quel que soit le type d'abonné, les messages ne doivent pas être placés dans la file d'attente de lettres mortes. Nous vous recommandons d'être averti si des messages arrivent dans la file d'attente, afin que vous puissiez identifier et traiter la cause première, et éventuellement rediriger les messages dans la file d'attente de lettres mortes afin d'éviter toute perte de données.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Dimensions : TopicName

Description de l'alarme : cette alarme permet de surveiller les messages qui n'ont pas pu être déplacés vers une file d'attente de lettres mortes. Vérifiez si votre file d'attente de lettres mortes existe et qu'elle est correctement configurée. Vérifiez également que le SNS est autorisé à accéder à la file d'attente de lettres mortes. Veuillez consulter la documentation relative aux files d’attente de lettres mortes pour en savoir plus.

Intention : l'alarme est utilisée pour détecter les messages qui n'ont pas pu être déplacés vers une file d'attente de lettres mortes.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : si les messages ne peuvent pas être déplacés vers la file d'attente de lettres mortes, il s'agit presque toujours d'une erreur. La recommandation pour le seuil est 0, ce qui signifie que tous les messages dont le traitement échoue doivent pouvoir atteindre la file d'attente de lettres mortes lorsque celle-ci a été configurée.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SMS en MonthToDateSpent dollars américains

Dimensions : TopicName

Description de l'alarme : l'alarme permet de vérifier si votre compte dispose d'un quota suffisant pour que SNS puisse envoyer des messages. Si vous atteignez votre quota, SNS ne sera pas en mesure de délivrer de SMS. Pour plus d'informations sur la définition de votre quota de dépenses mensuel par SMS, ou pour savoir comment demander une augmentation du quota de dépenses avec AWS, consultez la section Configuration des préférences de messagerie SMS.

Intention : cette alarme est utilisée pour détecter si votre compte dispose d'un quota suffisant pour que vos SMS soient envoyés avec succès.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil conformément au quota (limite de dépenses du compte) pour le compte. Choisissez un seuil qui vous informe suffisamment tôt que vous atteignez votre limite de quota afin que vous ayez le temps de demander une augmentation.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

SMS SuccessRate

Dimensions : TopicName

Description de l'alarme : cette alarme permet de surveiller le taux d'échec des livraisons de SMS. Vous pouvez configurer Cloudwatch Logs pour comprendre la nature de la défaillance et prendre des mesures en conséquence.

Intention : cette alarme est utilisée pour détecter les échecs de livraison de SMS.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : définissez le seuil d'alarme en fonction de votre tolérance en cas d'échec de livraison de SMS.

Période : 60

Points de données pour le déclenchement d'alarme : 5

Période d'évaluation : 5

Opérateur de comparaison : GREATER_THAN_THRESHOLD

ApproximateAgeOfOldestMessage

Dimensions : QueueName

Description de l'alarme : cette alarme surveille l'âge du plus ancien message de la file d'attente. Vous pouvez utiliser cette alarme pour vérifier si vos clients traitent les messages SQS à la vitesse souhaitée. Envisagez d'augmenter le nombre de clients ou le débit des clients afin de réduire l'âge des messages. Cette métrique peut être utilisée en combinaison avec ApproximateNumberOfMessagesVisible pour déterminer l'ampleur du backlog de files d'attente et la rapidité avec laquelle les messages sont traités. Pour éviter que les messages ne soient supprimés avant leur traitement, pensez à configurer la file d'attente de lettres mortes afin de mettre de côté les messages potentiels de type « poison pill ».

Intention : Cette alarme est utilisée pour détecter si l'âge du message le plus ancien de la QueueName file d'attente est trop élevé. Un âge élevé peut indiquer que les messages ne sont pas traités assez rapidement ou que certains messages considérés comme « poison pill » sont bloqués dans la file d'attente et ne peuvent pas être traités.

Statistique : maximum

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement du temps de traitement des messages attendu. Vous pouvez utiliser les données historiques pour calculer le temps moyen de traitement des messages, puis définir le seuil à 50 % de plus que le temps de traitement maximal attendu des messages SQS par les consommateurs de files d'attente.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Dimensions : QueueName

Description de l'alarme : cette alarme permet de détecter un grand nombre de messages en vol en ce qui concerne QueueName. Pour résoudre les problèmes, vérifiez comment empêcher l'augmentation du backlog de messages.

Objectif : cette alarme est utilisée pour détecter un grand nombre de messages en vol dans la file d'attente. Si les consommateurs ne suppriment pas les messages dans le délai imparti, lorsque la file d'attente est interrogée, les messages réapparaissent dans la file d'attente. Pour les files d'attente FIFO, il peut y avoir un maximum de 20 000 messages en vol. Si vous atteignez ce quota, SQS ne renvoie aucun message d'erreur. Une file d'attente FIFO examine les 20 000 premiers messages pour déterminer les groupes de messages disponibles. Cela signifie que si vous avez un arriéré de messages dans un seul groupe de messages, vous ne pouvez pas consommer les messages d'autres groupes de messages envoyés à la file d'attente ultérieurement tant que vous n'avez pas correctement consommé les messages du backlog.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : la valeur de seuil recommandée pour cette alarme dépend fortement du nombre attendu de messages en vol. Vous pouvez utiliser les données historiques pour calculer le nombre maximum attendu de messages en vol et définir le seuil à 50 % au-dessus de cette valeur. Si les utilisateurs de la file d'attente traitent des messages, mais ne les suppriment pas, ce nombre augmentera soudainement.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Dimensions : QueueName

Description de l'alarme : cette alarme détecte que le backlog de la file d'attente de messages est plus important que prévu, ce qui indique que les consommateurs sont trop lents ou qu'il n'y en a pas assez. Envisagez d'augmenter le nombre de consommateurs ou de les accélérer si cette alarme passe en état ALARM.

Intention : cette alarme est utilisée pour détecter si le nombre de messages de la file d'attente active est trop élevé et si les consommateurs sont lents à traiter les messages ou s'il n'y en a pas assez pour les traiter.

Statistique : moyenne

Seuil recommandé : dépend de votre situation

Justification du seuil : un nombre étonnamment élevé de messages visibles indique que les messages ne sont pas traités par le consommateur au rythme attendu. Vous devez prendre en compte les données historiques lorsque vous définissez ce seuil.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Dimensions : QueueName

Description de l'alarme : cette alarme permet de détecter si aucun message n'est envoyé par un producteur en ce qui concerne QueueName. Pour résoudre les problèmes, vérifiez la raison pour laquelle le producteur n'envoie pas de messages.

Intention : cette alarme est utilisée pour détecter le moment où un producteur arrête d'envoyer des messages.

Statistique : somme

Seuil recommandé : 0,0

Justification du seuil : si le nombre de messages envoyés est égal à 0, cela signifie que le producteur n'envoie aucun message. Si le TPS de cette file d'attente est faible, augmentez-en le nombre EvaluationPeriods en conséquence.

Période : 60

Points de données pour le déclenchement d'alarme : 15

Période d'évaluation : 15

Opérateur de comparaison : LESS_THAN_OR_EQUAL_TO_THRESHOLD

TunnelState

Dimensions : VpnId

Description de l'alarme : cette alarme vous aide à comprendre si l'état d'un ou de plusieurs tunnels est HORS SERVICE. Pour résoudre les problèmes, veuillez consulter Résoudre les problèmes liés aux tunnels VPN.

Intention : cette alarme est utilisée pour détecter si au moins un tunnel est à l'état HORS SERVICE pour ce VPN, afin que vous puissiez dépanner le VPN concerné. Cette alarme sera toujours à l'état ALARM pour les réseaux qui n'ont qu'un seul tunnel configuré.

Statistique : minimum

Seuil recommandé : 1,0

Justification du seuil : une valeur inférieure à 1 indique qu'au moins un tunnel est à l'état HORS SERVICE.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : LESS_THAN_THRESHOLD

TunnelState

Dimensions : TunnelIpAddress

Description de l'alarme : cette alarme vous permet de savoir si l'état de ce tunnel est HORS SERVICE. Pour résoudre les problèmes, veuillez consulter Résoudre les problèmes liés aux tunnels VPN.

Intention : cette alarme est utilisée pour détecter si le tunnel est à l'état HORS SERVICE, afin que vous puissiez dépanner le VPN concerné. Cette alarme sera toujours à l'état ALARM pour les réseaux qui n'ont qu'un seul tunnel configuré.

Statistique : minimum

Seuil recommandé : 1,0

Justification du seuil : une valeur inférieure à 1 indique que le tunnel est à l'état HORS SERVICE.

Période : 300

Points de données pour le déclenchement d'alarme : 3

Période d'évaluation : 3

Opérateur de comparaison : LESS_THAN_THRESHOLD

Rubriques

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon ECS

Amazon ECS avec Container Insights

Amazon EFS

Amazon EKS avec Container Insights

Amazon Kinesis Data Streams

Lambda

Aperçu Lambda

Amazon VPC (`AWS/NATGateway`)

AWS Lien privé (`AWS/PrivateLinkEndpoints`)

AWS Lien privé (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`

Amazon SNS

Amazon SQS

AWS VPN

Alarmes recommandées

Rubriques

Amazon API Gateway

Amazon EC2 Auto Scaling

Amazon CloudFront

Amazon Cognito

Amazon DynamoDB

Amazon EBS

Amazon EC2

Amazon ElastiCache

Amazon EC2 (AWS/ElasticGPUs)

Amazon ECS

Amazon ECS avec Container Insights

Amazon EFS

Amazon EKS avec Container Insights

Amazon Kinesis Data Streams

Lambda

Aperçu Lambda

Amazon VPC (AWS/NATGateway)

AWS Lien privé (AWS/PrivateLinkEndpoints)

AWS Lien privé (AWS/PrivateLinkServices)

Amazon RDS

Amazon Route 53 Public Data Plane

Amazon S3

S3ObjectLambda

Amazon SNS

Amazon SQS

AWS VPN

Amazon EC2 (`AWS/ElasticGPUs`)

Amazon VPC (`AWS/NATGateway`)

AWS Lien privé (`AWS/PrivateLinkEndpoints`)

AWS Lien privé (`AWS/PrivateLinkServices`)

`Amazon RDS`

`Amazon Route 53 Public Data Plane`

`Amazon S3`

`S3ObjectLambda`