As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Alertas básicos em monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate
Depois de verificar os alertas, o AMS ativa os seguintes alertas para o Amazon EKS e, em seguida, se envolve no monitoramento e no gerenciamento de incidentes para seus clusters selecionados do Amazon EKS. O tempo de resposta dos Acordos de Nível de Serviço (SLAs) e os Objetivos de Nível de Serviço (SLOs) dependem do Nível de Serviço de sua conta selecionada (Plus, Premium). Para obter mais informações, consulte Relatórios de incidentes e solicitações de serviço no AMS Accelerate.
Alertas e ações
A tabela a seguir lista os alertas do Amazon EKS e as respectivas ações que o AMS executa:
| Alerta | Limites | Ação |
|---|---|---|
|
O contêiner OOM foi eliminado |
O número total de reinicializações de contêineres nos últimos 10 minutos é de pelo menos 1 e um contêiner Kubernetes em um pod foi encerrado com o motivo “OOMKilled” nos últimos 10 minutos. |
O AMS investiga se a eliminação do OOM é causada por ter atingido o limite de contêineres ou a sobrecarga do limite de memória e, em seguida, aconselha você sobre ações corretivas. |
|
Falha no Pod Job |
Falha na conclusão de um trabalho do Kubernetes. A falha é indicada pela presença de pelo menos um status de trabalho com falha. |
O AMS investiga por que o trabalho do Kubernetes ou o cron job correspondente está falhando e, em seguida, aconselha você sobre ações corretivas. |
|
StatefulSet Para baixo |
O número de réplicas prontas para atender ao tráfego não corresponde ao número atual de réplicas existentes StatefulSet por pelo menos 1 minuto. |
O AMS determina por que os pods não estão prontos analisando as mensagens de erro nos eventos do pod e os trechos do registro de erros nos logs do pod e, em seguida, aconselha você sobre ações corretivas. |
|
Capacidade de escalabilidade HPA |
O escalonador automático horizontal de pods (HPA) não pode ser escalado porque a condição de status “AbleToScale” é falsa por pelo menos 2 minutos. |
O AMS determina qual Kubernetes Horizontal Pod Autoscaler (HPA) não consegue escalar pods para seu recurso de carga de trabalho subsequente, como uma implantação ou. StatefulSet |
|
Disponibilidade da métrica HPA |
O Horizontal Pod Autoscaler (HPA) não consegue coletar métricas porque a condição de status “ScalingActive” é falsa por pelo menos 2 minutos. |
O AMS determina por que o HPA não pode coletar métricas, como métricas relacionadas a problemas de configuração do servidor ou problemas de autorização do RBAC. |
|
O pod não está pronto |
Um pod do Kubernetes permanece em um estado sem execução (como Pendente, Desconhecido ou Falha) por mais de 15 minutos. |
O AMS investiga os pods afetados para obter detalhes, analisa os registros dos pods em busca de erros e eventos relacionados e, em seguida, aconselha você sobre ações corretivas. |
|
Pod Crash Looping |
Um contêiner de cápsulas reinicia pelo menos uma vez a cada 15 minutos por um período de 1 hora. |
O AMS investiga os motivos da não inicialização do pod, como recursos insuficientes, um arquivo bloqueado por outro contêiner, banco de dados bloqueado por outro contêiner, falhas nas dependências do serviço, problemas de DNS para serviços externos e configurações incorretas. |
|
Daemonset está programado incorretamente |
Há pelo menos um pod do Kubernetes Daemonset programado incorretamente em um período de 10 minutos. |
O AMS determina por que um Daemonset está programado em um nó onde eles não deveriam ser executados. Isso pode acontecer quando o pod errado nodeSelector/taints/affinities foi aplicado aos pods do Daemonset ou quando os nós (pools de nós) foram contaminados e os pods existentes não foram programados para serem despejados. |
|
Erros da API Kubernetes |
A taxa de erro do servidor da API Kubernetes excede 3% em um período de 2 minutos. |
O AMS analisa os registros do plano de controle para determinar o volume e os tipos de erros que estão causando esse alerta e identifica quaisquer problemas de contenção de recursos para grupos de escalonamento automático do nó principal ou do etcd. Se o servidor da API não se recuperar, o AMS contrata a equipe de serviço do Amazon EKS. |
|
Latência da API Kubernetes |
A latência do 99º percentil das solicitações para o servidor da API Kubernetes excede 1 segundo em um período de 2 minutos. |
O AMS analisa os registros do plano de controle para determinar o volume e os tipos de erros que estão causando latência e identifica quaisquer problemas de contenção de recursos para grupos de auto-scaling do nó principal ou do etcd. Se o servidor da API não se recuperar, o AMS contrata a equipe de serviço do Amazon EKS. |
|
Expiração do certificado do cliente Kubernetes |
O certificado do cliente usado para se autenticar no servidor da API Kubernetes expirará em menos de 24 horas. |
O AMS envia essa notificação para informá-lo de que seu certificado de cluster expirará em 24 horas. |
|
O Node não está pronto |
O status da condição “Pronto” do Node é falso por pelo menos 10 minutos. |
O AMS investiga as condições e os eventos do nó, como problemas de rede, que impedem o acesso do kubelet ao servidor da API. |
|
CPU Node High |
A carga da CPU excede 80% em um período de 5 minutos. |
O AMS determina se um ou mais pods estão consumindo uma quantidade anormalmente alta de CPU. Em seguida, o AMS verifica com você se suas solicitações, limites e atividades do pod estão conforme o esperado. |
|
Detectada a morte do Node OOM |
Há pelo menos uma eliminação de OOM do host relatada pelo nó em uma janela de 4 minutos. |
O AMS determina se a eliminação do OOM é causada pelo alcance do limite do contêiner ou pela sobrecarga do nó. Se a atividade do aplicativo for normal, o AMS o aconselhará sobre solicitações e limites para supercomprometimentos e sobre a revisão dos limites dos pods. |
|
Limite de conexão do Node |
A proporção entre o número atual de entradas de rastreamento de conexão e o limite máximo excede 80% em um período de 5 minutos. |
O AMS aconselha você sobre o valor de conexão recomendado por núcleo. Os nós do Kubernetes definem o valor máximo do conntrack proporcional à capacidade total de memória do nó. Aplicações de alta carga, especialmente em nós menores, podem facilmente exceder o valor máximo do conntrack, resultando em redefinições e tempos limite de conexão. |
|
O relógio do Node não está sincronizado |
O status mínimo de sincronização em um período de 2 minutos é 0 e o erro máximo em segundos é 16 ou superior. |
O AMS determina se o Network Time Protocol (NTP) está instalado e funcionando corretamente. |
|
CPU Pod High |
O uso da CPU de um contêiner excede 80% em uma taxa de 3 minutos por um período mínimo de 2 minutos. |
O AMS investiga os registros do pod para determinar as tarefas do pod que consomem uma grande quantidade de CPU. |
|
Pod de alta memória |
O uso de memória de um contêiner excede 80% do limite de memória especificado em um período de 2 minutos. |
O AMS investiga os registros do pod para determinar as tarefas do pod que consomem uma grande quantidade de memória. |
|
CoreDNS inativo |
O CoreDNS desapareceu da descoberta de alvos do Prometheus por mais de 15 minutos. |
Esse é um alerta crítico que indica que a resolução do nome de domínio para serviços de cluster internos ou externos foi interrompida. O AMS verifica o status dos pods do CoreDNS, verifica a configuração do CoreDNS, verifica os endpoints de DNS que apontam para os pods do CoreDNS, verifica os limites do CoreDNS e, com sua aprovação, ativa o registro de depuração do CoreDNS. |
|
Erros do CoreDNS |
O CoreDNS retorna erros SERVFAIL para mais de 3% das solicitações de DNS em um período de 10 minutos. |
Esse alerta pode indicar um problema com um aplicativo ou uma configuração incorreta. O AMS verifica o status dos pods do CoreDNS, verifica a configuração do CoreDNS, verifica os endpoints de DNS que apontam para os pods do CoreDNS, verifica os limites do CoreDNS e, com sua aprovação, ativa o registro de depuração do CoreDNS. |
|
Latência do CoreDNS |
O 99º percentil da duração das solicitações de DNS excede 4 segundos por 10 minutos. |
Esse alerta indica que o CoreDNS pode estar sobrecarregado. O AMS verifica o status dos pods do CoreDNS, verifica a configuração do CoreDNS, verifica os endpoints de DNS que apontam para os pods do CoreDNS, verifica os limites do CoreDNS e, com sua aprovação, ativa o registro de depuração do CoreDNS. |
| Latência de encaminhamento do CoreDNS | O 99º percentil do tempo de resposta das solicitações de encaminhamento do CoreDNS para o kube-dns excede 4 segundos em um período de 10 minutos. |
Quando o CoreDNS não é o servidor autoritativo ou não tem uma entrada de cache para um nome de domínio, o CoreDNS encaminha a solicitação de DNS para um servidor DNS upstream. Esse alerta indica que o CoreDNS pode estar sobrecarregado ou que pode haver um problema com um servidor DNS upstream. O AMS verifica o status dos pods do CoreDNS, verifica a configuração do CoreDNS, verifica os endpoints de DNS que apontam para os pods do CoreDNS, verifica os limites do CoreDNS e, com sua aprovação, ativa o registro de depuração do CoreDNS. |
|
Erro de encaminhamento do CoreDNS |
Mais de 3% das consultas de DNS falham em um período de 5 minutos. |
Quando o CoreDNS não é o servidor autoritativo ou não tem uma entrada de cache para um nome de domínio, o CoreDNS encaminha a solicitação de DNS para um servidor DNS upstream. Esse alerta sinaliza uma possível configuração incorreta ou um problema com um servidor DNS upstream. O AMS verifica o status dos pods do CoreDNS, verifica a configuração do CoreDNS, verifica os endpoints de DNS que apontam para os pods do CoreDNS, verifica os limites do CoreDNS e, com sua aprovação, ativa o registro de depuração do CoreDNS. |