Avvisi di base per il monitoraggio e la gestione degli incidenti per Amazon EKS in AMS Accelerate - Guida utente di AMS Accelerate

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Avvisi di base per il monitoraggio e la gestione degli incidenti per Amazon EKS in AMS Accelerate

Dopo aver verificato gli avvisi, AMS abilita i seguenti avvisi per Amazon EKS e quindi si occupa del monitoraggio e della gestione degli incidenti per i cluster Amazon EKS selezionati. I tempi di risposta Service Level Agreements (SLAs) e Service Level Objectives (SLOs) dipendono dal livello di servizio (Plus, Premium) dell'account selezionato. Per ulteriori informazioni, consulta Segnalazioni di incidenti e richieste di assistenza in AMS Accelerate.

Avvisi e azioni

La tabella seguente elenca gli avvisi di Amazon EKS e le rispettive azioni intraprese da AMS:

Alert Soglie Azione

Container OOM ucciso

Il numero totale di riavvii dei container negli ultimi 10 minuti è almeno 1 e un container Kubernetes in un pod è stato chiuso con il motivo «OOMKilled» negli ultimi 10 minuti.

AMS verifica se il blocco dell'OOM è causato dal raggiungimento del limite del contenitore o dall'overcommit del limite di memoria, quindi consiglia all'utente le azioni correttive necessarie.

Pod Job non riuscito

Un job Kubernetes non viene completato. L'errore è indicato dalla presenza di almeno uno stato di lavoro non riuscito.

AMS analizza il motivo per cui il job Kubernetes o il cron job corrispondente non funziona correttamente, quindi consiglia all'utente le azioni correttive.

StatefulSet Giù

Il numero di repliche pronte a servire il traffico non corrisponde al numero attuale di repliche esistenti StatefulSet per almeno 1 minuto.

AMS determina il motivo per cui i pod non sono pronti esaminando i messaggi di errore negli eventi dei pod e i frammenti di registro degli errori nei log dei pod, quindi consiglia all'utente le azioni correttive.

Capacità di scalabilità HPA

L'Horizontal Pod Autoscaler (HPA) non è in grado di scalare perché la condizione di stato «AbleToScale» è falsa per almeno 2 minuti.

AMS determina quale Kubernetes Horizontal Pod Autoscaler (HPA) non è in grado di scalare i pod per la successiva risorsa del carico di lavoro, ad esempio un Deployment o. StatefulSet

Disponibilità metrica HPA

Horizontal Pod Autoscaler (HPA) non è in grado di raccogliere metriche perché la condizione di stato «ScalingActive» è falsa da almeno 2 minuti.

AMS determina il motivo per cui HPA non è in grado di raccogliere metriche, ad esempio metriche relative a problemi di configurazione del server o problemi di autorizzazione RBAC.

Pod non pronto

Un pod Kubernetes rimane in uno stato non in esecuzione (ad esempio Pending, Unknown o Failed) per più di 15 minuti.

AMS esamina i pod interessati per ulteriori dettagli, esamina i log dei pod alla ricerca di errori ed eventi correlati e quindi consiglia all'utente le azioni correttive necessarie.

Pod Crash Looping

Un contenitore di pod si riavvia almeno una volta ogni 15 minuti per un periodo di 1 ora.

AMS analizza i motivi del mancato avvio del pod, ad esempio risorse insufficienti, un file bloccato da un altro contenitore, il database bloccato da un altro contenitore, errori nelle dipendenze del servizio, problemi DNS per i servizi esterni e configurazioni errate.

Daemonset è programmato in modo errato

C'è almeno un pod Kubernetes Daemonset programmato in modo errato nell'arco di 10 minuti.

AMS determina il motivo per cui un Daemonset è pianificato su un nodo in cui non dovrebbe essere eseguito. Ciò potrebbe accadere quando il pod sbagliato nodeSelector/taints/affinities veniva applicato ai pod Daemonset o quando il nodo (pool di nodi) era contaminato e i pod esistenti non erano programmati per lo sfratto.

Errori dell'API Kubernetes

Il tasso di errore del server dell'API Kubernetes supera il 3% in un periodo di 2 minuti.

AMS analizza i log del piano di controllo per determinare il volume e i tipi di errori che causano questo avviso e identifica eventuali problemi di contesa delle risorse per i gruppi di scalabilità automatica del nodo master o di etcd. Se il server API non si ripristina, AMS contatta il team di assistenza Amazon EKS.

Latenza dell'API Kubernetes

La latenza del 99° percentile delle richieste al server API Kubernetes supera 1 secondo in un periodo di 2 minuti.

AMS analizza i log del piano di controllo per determinare il volume e i tipi di errori che causano la latenza e identifica eventuali problemi di conflitto di risorse per i nodi master o i gruppi di auto-scaling etcd. Se il server API non si ripristina, AMS contatta il team di assistenza Amazon EKS.

Certificato client Kubernetes in scadenza

Il certificato client utilizzato per l'autenticazione sul server API Kubernetes scadrà tra meno di 24 ore.

AMS invia questa notifica per informarti che il certificato del cluster scadrà tra 24 ore.

Nodo non pronto

Lo stato della condizione «Pronto» del nodo è falso per almeno 10 minuti.

AMS analizza le condizioni e gli eventi del nodo, come i problemi di rete, che impediscono l'accesso di Kubelet al server API.

Node High CPU

Il carico della CPU supera l'80% in un periodo di 5 minuti.

AMS determina se uno o più pod stanno consumando una quantità insolitamente elevata di CPU. Quindi, AMS verifica con te che le tue richieste, i limiti e l'attività dei pod siano quelli previsti.

Node OOM Kill rilevato

Il nodo segnala almeno un blocco OOM dell'host in una finestra di 4 minuti.

AMS determina se il kill OOM è causato dal raggiungimento del limite del contenitore o dall'overcommit del nodo. Se l'attività dell'applicazione è normale, AMS fornisce informazioni sulle richieste e sui limiti relativi agli overcommit e alla revisione dei limiti dei pod.

Node Conntrack Limit

Il rapporto tra il numero attuale di voci di tracciamento della connessione e il limite massimo supera l'80% in un periodo di 5 minuti.

AMS ti consiglia il valore di conntrack consigliato per core. I nodi Kubernetes impostano il valore massimo di conntrack proporzionalmente alla capacità di memoria totale del nodo. Le applicazioni ad alto carico, specialmente su nodi più piccoli, possono facilmente superare il valore massimo di conntrack, con conseguenti reimpostazioni e timeout della connessione.

Node Clock non sincronizzato

Lo stato di sincronizzazione minimo in un periodo di 2 minuti è 0 e l'errore massimo in secondi è 16 o superiore.

AMS determina se il Network Time Protocol (NTP) è installato e funziona correttamente.

CPU Pod High

L'utilizzo della CPU di un container supera l'80% con una frequenza di 3 minuti per un periodo minimo di 2 minuti.

AMS analizza i log dei pod per determinare le attività dei pod che consumano una quantità elevata di CPU.

Pod High Memory

L'utilizzo della memoria di un contenitore supera l'80% del limite di memoria specificato per un periodo di 2 minuti.

AMS analizza i log dei pod per determinare le attività dei pod che consumano una quantità elevata di memoria.

CoredNS inattivo

CoredNS è scomparso da Prometheus Target Discovery per più di 15 minuti.

Si tratta di un avviso critico che indica che la risoluzione dei nomi di dominio per i servizi di cluster interni o esterni è stata interrotta. AMS controlla lo stato dei pod CoreDNS, verifica la configurazione CoreDNS, verifica gli endpoint DNS che puntano ai pod CoreDNS, verifica i limiti CoreDNS e, con l'approvazione dell'utente, abilita la registrazione del debug CoreDNS.

Errori CoredNS

CoredNS restituisce errori SERVFAIL per oltre il 3% delle richieste DNS in un periodo di 10 minuti.

Questo avviso potrebbe segnalare un problema con un'applicazione o una configurazione errata. AMS controlla lo stato dei pod CoreDNS, verifica la configurazione CoreDNS, verifica gli endpoint DNS che puntano ai pod CoreDNS, verifica i limiti CoreDNS e, con l'approvazione dell'utente, abilita la registrazione del debug CoreDNS.

Latenza CoredNS

Il 99° percentile della durata delle richieste DNS supera i 4 secondi per 10 minuti.

Questo avviso segnala che CoredNS potrebbe essere sovraccarico. AMS controlla lo stato dei pod CoreDNS, verifica la configurazione CoreDNS, verifica gli endpoint DNS che puntano ai pod CoreDNS, verifica i limiti CoreDNS e, con l'approvazione dell'utente, abilita la registrazione del debug CoreDNS.

Latenza di inoltro CoredNS

Il 99° percentile del tempo di risposta per le richieste di inoltro di CoredNS a kube-dns supera i 4 secondi in un periodo di 10 minuti.

Quando CoreDNS non è il server autorevole o non dispone di una voce di cache per un nome di dominio, CoreDNS inoltra la richiesta DNS a un server DNS upstream. Questo avviso segnala che CoredNS potrebbe essere sovraccarico o che potrebbe esserci un problema con un server DNS upstream. AMS controlla lo stato dei pod CoreDNS, verifica la configurazione CoreDNS, verifica gli endpoint DNS che puntano ai pod CoreDNS, verifica i limiti CoreDNS e, con l'approvazione dell'utente, abilita la registrazione del debug CoreDNS.

Errore di inoltro CoredNS

Oltre il 3% delle query DNS fallisce in un periodo di 5 minuti.

Quando CoreDNS non è il server autorevole o non dispone di una voce di cache per un nome di dominio, CoreDNS inoltra la richiesta DNS a un server DNS upstream. Questo avviso segnala una possibile configurazione errata o un problema con un server DNS upstream. AMS controlla lo stato dei pod CoreDNS, verifica la configurazione CoreDNS, verifica gli endpoint DNS che puntano ai pod CoreDNS, verifica i limiti CoreDNS e, con l'approvazione dell'utente, abilita la registrazione del debug CoreDNS.