Alertes de base en matière de surveillance et de gestion des incidents pour Amazon EKS dans AMS Accelerate - Guide de l'utilisateur d'AMS Accelerate

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Alertes de base en matière de surveillance et de gestion des incidents pour Amazon EKS dans AMS Accelerate

Après avoir vérifié les alertes, AMS active les alertes suivantes pour Amazon EKS, puis se charge de la surveillance et de la gestion des incidents pour les clusters Amazon EKS que vous avez sélectionnés. Le temps de réponse des accords de niveau de service (SLAs) et les objectifs de niveau de service (SLOs) dépendent du niveau de service (Plus, Premium) que vous avez sélectionné pour votre compte. Pour plus d'informations, consultez la section Rapports d'incidents et demandes de service dans AMS Accelerate.

Alertes et actions

Le tableau suivant répertorie les alertes Amazon EKS et les actions respectives entreprises par AMS :

Alerte Seuils Action

Container OOM tué

Le nombre total de redémarrages de conteneurs au cours des 10 dernières minutes est d'au moins 1 et un conteneur Kubernetes d'un pod a été fermé avec le motif « OOMKilled » au cours des 10 dernières minutes.

AMS cherche à déterminer si le kill OOM est dû à l'atteinte de la limite de conteneur ou à un dépassement de la limite de mémoire, puis vous conseille sur les mesures correctives à prendre.

Pod Job a échoué

Une tâche Kubernetes échoue. L'échec est indiqué par la présence d'au moins un statut d'échec de la tâche.

AMS étudie les raisons de l'échec de la tâche Kubernetes ou de la tâche cron correspondante, puis vous conseille sur les mesures correctives à prendre.

StatefulSet Vers le bas

Le nombre de répliques prêtes à servir le trafic ne correspond pas au nombre actuel de répliques existantes StatefulSet pendant au moins 1 minute.

AMS détermine pourquoi les pods ne sont pas prêts en consultant les messages d'erreur dans les événements des pods et les extraits du journal des erreurs dans les logs des pods, puis vous conseille sur les mesures correctives à prendre.

Capacité de mise à l'échelle HPA

L'Horizontal Pod Autoscaler (HPA) ne peut pas être redimensionné car la condition d'état « AbleToScale » est fausse pendant au moins 2 minutes.

AMS détermine quel Kubernetes Horizontal Pod Autoscaler (HPA) n'est pas en mesure de dimensionner les pods pour la ressource de charge de travail suivante, telle qu'un déploiement ou. StatefulSet

Disponibilité des métriques HPA

L'Horizontal Pod Autoscaler (HPA) ne peut pas collecter de mesures car la condition d'état « ScalingActive » est fausse pendant au moins 2 minutes.

AMS détermine pourquoi HPA ne peut pas collecter de métriques, telles que les métriques liées aux problèmes de configuration du serveur ou aux problèmes d'autorisation RBAC.

Le pod n'est pas prêt

Un pod Kubernetes reste dans un état non actif (tel que En attente, Inconnu ou Échoué) pendant plus de 15 minutes.

AMS enquête sur le ou les pods concernés pour plus de détails, examine les journaux des pods pour détecter les erreurs et les événements associés, puis vous conseille sur les mesures correctives à prendre.

Pod Crash en boucle

Un conteneur à capsules redémarre au moins une fois toutes les 15 minutes pendant une heure.

AMS étudie les raisons pour lesquelles le pod ne démarre pas, telles que des ressources insuffisantes, un fichier verrouillé par un autre conteneur, une base de données verrouillée par un autre conteneur, l'échec des dépendances de service, des problèmes de DNS pour les services externes et des erreurs de configuration.

Daemonset mal planifié

Au moins un pod Kubernetes Daemonset a été mal planifié sur une période de 10 minutes.

AMS détermine pourquoi un Daemonset est planifié sur un nœud où il n'est pas censé s'exécuter. Cela peut se produire lorsque le mauvais pod a nodeSelector/taints/affinities été appliqué aux pods Daemonset ou lorsque le nœud (pool de nœuds) a été contaminé et que l'expulsion des pods existants n'a pas été planifiée.

Erreurs d'API Kubernetes

Le taux d'erreur du serveur d'API Kubernetes dépasse 3 % sur une période de 2 minutes.

AMS analyse les journaux du plan de contrôle pour déterminer le volume et le type d'erreurs à l'origine de cette alerte, et identifie tout problème de contention des ressources pour les nœuds principaux ou les groupes de mise à l'échelle automatique etcd. Si le serveur d'API ne se rétablit pas, AMS fait appel à l'équipe de service Amazon EKS.

Latence de l'API Kubernetes

Le 99e percentile de latence des demandes adressées au serveur d'API Kubernetes dépasse 1 seconde sur une période de 2 minutes.

AMS analyse les journaux du plan de contrôle pour déterminer le volume et les types d'erreurs à l'origine de la latence et identifie tout problème de contention des ressources pour les nœuds principaux ou les groupes d'auto-scaling etcd. Si le serveur d'API ne se rétablit pas, AMS fait appel à l'équipe de service Amazon EKS.

Expiration du certificat client Kubernetes

Le certificat client utilisé pour s'authentifier auprès du serveur d'API Kubernetes expirera dans moins de 24 heures.

AMS envoie cette notification pour vous informer que votre certificat de cluster expirera dans 24 heures.

Le nœud n'est pas prêt

Le statut « Prêt » du nœud est faux pendant au moins 10 minutes.

AMS étudie les conditions et les événements du nœud, tels que les problèmes de réseau, qui empêchent l'accès de Kubelet au serveur API.

Processeur Node High

La charge du processeur dépasse 80 % sur une période de 5 minutes.

AMS détermine si un ou plusieurs pods consomment une quantité anormalement élevée de CPU. AMS vérifie ensuite avec vous que vos demandes, vos limites et l'activité de vos pods sont conformes aux attentes.

Node OOM Kill détecté

Au moins un kill OOM de l'hôte est signalé par le nœud dans une fenêtre de 4 minutes.

AMS détermine si le kill OOM est dû à l'atteinte de la limite de conteneur ou au dépassement du nombre de nœuds. Si l'activité de l'application est normale, AMS vous conseille sur les demandes et les limites relatives aux survalidations et à la révision des limites de pods.

Limite de connexion aux nœuds

Le rapport entre le nombre actuel d'entrées de suivi des connexions et la limite maximale dépasse 80 % sur une période de 5 minutes.

AMS vous conseille sur la valeur de conntrack recommandée par cœur. Les nœuds Kubernetes définissent la valeur maximale de conntrack proportionnellement à la capacité de mémoire totale du nœud. Les applications à charge élevée, en particulier sur les petits nœuds, peuvent facilement dépasser la valeur maximale de conntrack, ce qui entraîne des réinitialisations de connexion et des délais d'attente.

L'horloge du nœud n'est pas synchronisée

L'état de synchronisation minimal sur une période de 2 minutes est 0, et l'erreur maximale en secondes est de 16 ou plus.

AMS détermine si le protocole NTP (Network Time Protocol) est installé et fonctionne correctement.

Processeur Pod High

L'utilisation du processeur d'un conteneur dépasse 80 % sur une fréquence de 3 minutes pendant une période minimale de 2 minutes.

AMS analyse les journaux du pod pour déterminer les tâches du pod qui consomment une grande quantité de processeur.

Pod High Memory

L'utilisation de la mémoire d'un conteneur dépasse 80 % de la limite de mémoire spécifiée sur une période de 2 minutes.

AMS analyse les journaux du pod pour déterminer les tâches du pod qui consomment une grande quantité de mémoire.

CoreDNS en panne

CoreDNS a disparu de la découverte de la cible de Prometheus pendant plus de 15 minutes.

Il s'agit d'une alerte critique qui indique que la résolution des noms de domaine pour les services de cluster internes ou externes s'est arrêtée. AMS vérifie l'état des pods CoreDNS, vérifie la configuration CoreDNS, vérifie les points de terminaison DNS qui pointent vers des pods CoreDNS, vérifie les limites CoreDNS et, avec votre approbation, active la journalisation du débogage CoreDNS.

Erreurs CoreDNS

CoreDNS renvoie des erreurs SERVFAIL pour plus de 3 % des requêtes DNS sur une période de 10 minutes.

Cette alerte peut signaler un problème lié à une application ou une mauvaise configuration. AMS vérifie l'état des pods CoreDNS, vérifie la configuration CoreDNS, vérifie les points de terminaison DNS qui pointent vers des pods CoreDNS, vérifie les limites CoreDNS et, avec votre approbation, active la journalisation du débogage CoreDNS.

Latence CoreDNS

Le 99e percentile des durées de requête DNS dépasse 4 secondes pendant 10 minutes.

Cette alerte indique que CoreDNS est peut-être surchargé. AMS vérifie l'état des pods CoreDNS, vérifie la configuration CoreDNS, vérifie les points de terminaison DNS qui pointent vers les pods CoreDNS, vérifie les limites CoreDNS et, avec votre approbation, active la journalisation du débogage CoreDNS.

Latence de transfert CoreDNS

Le 99e percentile du temps de réponse des demandes de transfert CoreDNS à kube-DNS dépasse 4 secondes sur une période de 10 minutes.

Lorsque CoreDNS n'est pas le serveur faisant autorité ou ne possède pas d'entrée de cache pour un nom de domaine, CoreDNS transmet la demande DNS à un serveur DNS en amont. Cette alerte indique que CoreDNS est peut-être surchargé ou qu'il peut y avoir un problème avec un serveur DNS en amont. AMS vérifie l'état des pods CoreDNS, vérifie la configuration CoreDNS, vérifie les points de terminaison DNS qui pointent vers des pods CoreDNS, vérifie les limites CoreDNS et, avec votre approbation, active la journalisation du débogage CoreDNS.

Erreur de transfert CoreDNS

Plus de 3 % des requêtes DNS échouent sur une période de 5 minutes.

Lorsque CoreDNS n'est pas le serveur faisant autorité ou ne possède pas d'entrée de cache pour un nom de domaine, CoreDNS transmet la demande DNS à un serveur DNS en amont. Cette alerte signale une éventuelle erreur de configuration ou un problème avec un serveur DNS en amont. AMS vérifie l'état des pods CoreDNS, vérifie la configuration CoreDNS, vérifie les points de terminaison DNS qui pointent vers des pods CoreDNS, vérifie les limites CoreDNS et, avec votre approbation, active la journalisation du débogage CoreDNS.