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á.
# Monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate
O monitoramento e o gerenciamento de incidentes do Amazon EKS monitoram seus recursos do Amazon EKS em busca de falhas, degradação do desempenho e problemas de segurança. O AMS Accelerate configura e implanta as regras do gerenciador de alertas do Amazon Managed Service for Prometheus, monitora os alertas e, em seguida, executa o gerenciamento de incidentes quando esses alertas são acionados. [O monitoramento e o gerenciamento de incidentes do Amazon EKS dependem do AMS Alarm Manager e aproveitam AWS serviços nativos, como [Amazon Managed Service for Prometheus, Amazon](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html) Managed [Grafana, Amazon e. GuardDuty [AWS Lambda[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html)
**nota**
O monitoramento e o gerenciamento de incidentes do Amazon EKS não oferecem suporte AWS GovCloud (US) a nós do Windows ou contêineres do Windows.
# O que é monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate?
O monitoramento e o gerenciamento de incidentes para o Amazon EKS fornecem o seguinte:
+ Uma configuração padrão que cria, gerencia e implanta monitores e políticas em toda a sua conta gerenciada para os clusters Amazon EKS selecionados por você.
+ Uma linha de base de monitoramento para permitir que suas cargas de trabalho do Amazon EKS tenham maior disponibilidade, mesmo que você não configure nenhum outro monitoramento para seus clusters do Amazon EKS. Para obter mais informações, consulte [Alertas básicos em monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate](acc-baseline-eks-alerts.md).
+ Notificações que são geradas pelo monitoramento de linha de base configurado para seu cluster Amazon EKS. Essas notificações são conhecidas como alertas. Os alertas são gerados quando há falhas iminentes, contínuas, recorrentes ou potenciais, degradação do desempenho ou problemas de segurança. Exemplos de alertas incluem um alerta do Prometheus, um evento ou uma descoberta de AWS um serviço, como a Amazon. GuardDuty
+ Investigação de alertas com orientação sobre as ações de remediação apropriadas que você pode tomar. Para obter mais informações, consulte [Relatórios de incidentes e solicitações de serviço no AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
+ Correção de alertas e incidentes pelas operações do AMS, quando possível e com sua aprovação, para evitar ou reduzir o impacto em seus aplicativos. Para obter mais informações, consulte [Relatórios de incidentes e solicitações de serviço no AMS Accelerate](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
+ Painéis opcionais predefinidos do Amazon Managed Grafana que fornecem visibilidade sobre a utilização de recursos, desempenho, integridade do CoreDNS, alertas ativos e alertas resolvidos anteriormente. Se você configurar o Amazon Managed Grafana usando o modelo fornecido pela AMS, poderá abrir o console do Amazon Managed Grafana para visualizar métricas e alertas para seu cluster Amazon EKS.
# Como o monitoramento e o gerenciamento de incidentes do Amazon EKS funcionam no AMS Accelerate
**Geração:** como parte do monitoramento de integração e do gerenciamento de incidentes do EKS, o AMS configura o monitoramento básico para os clusters do Amazon EKS que você selecionou em sua conta gerenciada. O AMS usa uma combinação das regras do gerenciador de alertas do Amazon Managed Service for Prometheus e das regras de eventos da CloudWatch Amazon para configurar o monitoramento básico. Um servidor Prometheus configurado pelo AMS em seu cluster coleta e grava remotamente suas métricas do Prometheus em um endpoint do Amazon Managed Service for Prometheus na mesma região. A configuração básica de monitoramento gera um alerta quando uma regra do gerenciador de alertas do Prometheus é acionada ou CloudWatch um evento é gerado.
**Agregação:** o AMS envia todos os alertas que seus recursos geram para o sistema de monitoramento do AMS, direcionando-os para um tópico do Amazon Simple Notification Service gerenciado pelo AMS.
**Processamento e análise de impacto:** o AMS analisa os alertas e os processa com base em seu potencial de impacto. O AMS classifica os alertas da seguinte forma:
+ **Alertas com impacto conhecido no cliente:** para esses alertas, o AMS cria um novo relatório de incidentes usando o processo [de gerenciamento de incidentes](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-manage-incidents.html).
+ **Alertas com impacto incerto no cliente:** para esses alertas, o AMS envia um relatório de incidentes. Em muitos casos, esses alertas solicitam que você verifique o impacto antes que o AMS possa agir. Para esses alertas, o AMS envia uma [notificação de alerta](acc-baseline-eks-alerts.md#acc-alerts-and-actions) com os detalhes e verifica se o alerta precisa de uma ação mitigadora. O AMS fornece opções para mitigar ações na notificação. Se sua resposta confirmar que o alerta é um incidente, o AMS aciona a criação de um novo relatório de incidentes e inicia o processo de gerenciamento de incidentes. Qualquer notificação de serviço que receba uma resposta “sem impacto no cliente” ou nenhuma resposta por três dias é marcada como resolvida. Além disso, o alerta correspondente é marcado como resolvido.
+ **Alertas sem impacto no cliente:** se, após a avaliação, o AMS determinar que o alerta não tem nenhum impacto no cliente, o alerta será encerrado.
## Matriz de responsabilidade da AMS (RACI)
O AMS responsável, responsável, consultado e informado, ou a matriz RACI, atribui a responsabilidade principal ao cliente ou à AMS por uma variedade de atividades. A tabela a seguir fornece uma visão geral das responsabilidades do cliente e do AMS pelas atividades em um aplicativo que usa monitoramento e gerenciamento de incidentes para o Amazon EKS.
+ **R** significa a parte responsável que faz o trabalho para realizar a tarefa.
+ **A** significa a parte responsável.
+ **C** significa consultado; a parte cujas opiniões são solicitadas, normalmente como especialistas no assunto; e com quem há comunicação bilateral.
+ **I** significa informado; a parte que é informada sobre o progresso, geralmente apenas após a conclusão da tarefa ou do resultado final.
| Atividades | Cliente | AMS |
| --- | --- | --- |
| Descoberta para requisitos de AMS | eu | R |
| Ativar permissões AMS (RBAC) para acesso ao cluster | R | C |
| Instale o Amazon EC2 Systems Manager Agent nos nós de trabalho, caso ele ainda não esteja presente | R | C |
| Implante componentes do AMS no cluster, como Prometheus, Prometheus Node Exporter e em um namespace AMS, conforme necessário. kube-state-metrics | C | R |
| Provisione o Amazon Managed Service para Prometheus no plano de controle do AMS | eu | R |
| Configurar o gerenciador de alertas Prometheus no plano de controle do AMS | eu | R |
| Forneça o modelo Amazon Managed Grafana e ajude na configuração | C | R |
| Ative o monitoramento do registro de auditoria do GuardDuty EKS | C | R |
| Habilite o registro do plano de controle do Amazon EKS | eu | R |
| Monitore a integridade e o desempenho do plano de controle Amazon EKS | eu | R |
| Monitore a integridade e o desempenho do seu cluster Amazon EKS (cluster, nó, carga de trabalho, pod, servidor de API e CoreDNS) | eu | R |
| Faça a triagem de alertas e forneça respostas a incidentes para o Amazon EKS | eu | R |
| Execute comandos de diagnóstico durante incidentes | eu | R |
| Analise os registros durante incidentes (plano de controle e registros do pod) | eu | R |
| Resposta a incidentes para problemas AWS de rede | eu | R |
| Responda às descobertas do GuardDuty EKS Audit Log Monitoring | eu | R |
| Forneça orientação ao cliente sobre ações para remediar incidentes quando possível | eu | R |
# 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](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-supp-ex.html).
## 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. |
# Requisitos para monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate
Esses são os recursos and/or necessários para monitoramento e gerenciamento de incidentes do Amazon EKS for AMS Accelerate
+ **Versões **compatíveis do Kubernetes: consulte as versões do** [Kubernetes do Amazon EKS no Guia do](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) usuário do Amazon EKS.**
+ **Tipos de nós:** os nós gerenciados do Amazon EKS são compatíveis. Não há suporte para nós e contêineres do Windows.
+ **Acesso ao cluster Kubernetes: o AMS requer a função de cluster** RBAC e o usuário do cluster system:masters.
+ **Agente SSM nos EC2 nós da Amazon:** Tanto o Bottle Rocket quanto o Amazon EKS AMIs têm o SSM Agent pré-instalado. Certifique-se de que o SSM Agent esteja instalado em seus EC2 nós personalizados AMIs e da Amazon.
+ [Para obter mais informações, consulte as **cotas** de serviço do Amazon Managed Service for [Prometheus e do Amazon Managed](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html) Grafana.](https://docs.aws.amazon.com/grafana/latest/userguide/AMG_quotas.html)
+ ** AWS Regiões suportadas:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/managedservices/latest/accelerate-guide/acc-requirements.html)
**nota**
As métricas para clusters do Amazon EKS em af-south-1, África (Cidade do Cabo) e ap-east-1, Ásia-Pacífico (Hong Kong) são exportadas para o serviço de monitoramento AMS no mesmo local, respectivamente. Região da AWS As métricas para elas Regiões da AWS são então transportadas dentro do serviço de monitoramento do AMS para diferentes regiões onde são processadas e armazenadas. Consulte a tabela anterior para as regiões que o serviço de monitoramento do AMS usa para armazenar métricas.
# Integre-se ao monitoramento e ao gerenciamento de incidentes do Amazon EKS no AMS Accelerate
Execute as etapas a seguir para integrar o monitoramento e o gerenciamento de incidentes do Amazon EKS.
1. **Ative as tags de otimização de custos do Amazon EKS:** consulte Como [marcar seus recursos para faturamento no Guia](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html#tag-resources-for-billing) **do usuário do Amazon EKS**.
1. **Inicie a integração do monitoramento e gerenciamento de incidentes para o EKS:** entre em contato com seu Cloud Service Delivery Manager (CSDM) com os nomes da conta IDs e do cluster para integrar.
1. **Valide os requisitos:** Seu Cloud Architect (CA) valida se todos os [requisitos](acc-requirements.md) foram atendidos antes do início da integração.
1. **Atualize o controle de acesso baseado em funções (RBAC) do Kubernetes:** o AMS compartilha os comandos para implementar essas mudanças. `eksctl` Você pode revisar essas alterações e depois implantar. Você deve implantar atualizações do RBAC para que o AMS tenha permissões para executar comandos em seu nome. Essas atualizações incluem mapear a função do AMS IAM para um usuário do Kubernetes, criar uma nova função de cluster do Kubernetes para o AMS e vincular a função de cluster do AMS Kubernetes ao usuário.
1. **Implante componentes de cluster:** O AMS implanta os seguintes componentes em um namespace gerenciado pelo AMS em seu cluster:
+ Servidor Prometheus
+ Exportador de nós Prometheus (não aplicável para) AWS Fargate
+ kube-state-metrics
1. **Execute atualizações de configuração do Prometheus**: o AMS configura o Prometheus para permitir a gravação remota de métricas.
1. **(Opcional) Configurar painéis:** sua CA ajuda você a configurar painéis do Amazon Managed Grafana em sua conta.
**nota**
Depois que seu cluster Amazon EKS é integrado, o AMS analisa os sinais de alerta e realiza uma avaliação básica para identificar problemas existentes em seu cluster. Após a conclusão da avaliação básica, o AMS compartilha descobertas e recomendações de remediação por meio do Trusted Advisor e de uma solicitação de serviço que você pode usar para resolver problemas em seu cluster. A partir da avaliação, o AMS cria uma linha de base de monitoramento do Amazon EKS específica para seus clusters EKS ajustando nossos limites de alarme em nível de conta. Para eliminar respostas duplicadas do AMS contra essas descobertas, ajustamos nosso monitoramento para excluir esses sinais de alerta. Reajustamos nosso monitoramento para incluir os sinais quando seu CSDM nos informa que os problemas subjacentes foram corrigidos.
# Fora do monitoramento e gerenciamento de incidentes para o Amazon EKS no AMS Accelerate
Notifique seu gerente de entrega de serviços em nuvem (CSDM) com os nomes da conta IDs e do cluster para iniciar o processo de desligamento. Após a desativação, o processamento de alertas, o armazenamento de métricas e a consulta de métricas são suspensos e as métricas são excluídas de acordo com as políticas padrão de retenção de dados do [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP_quotas.html).
O AMS executa as seguintes etapas de desativação:
1. O AMS desativa os alertas que são enviados para você e para as operações do AMS.
1. O AMS remove a instância Prometheus do seu cluster Amazon EKS.
1. O AMS remove outros AWS recursos que estão instalados na sua conta, como funções e AWS Config regras do IAM.
Depois que essas etapas forem concluídas, você deverá concluir as seguintes etapas de desativação:
1. Use `eksctl` para remover as permissões RBAC do Kubernetes do. `aws-auth` `ConfigMap`
1. Se você a instalou anteriormente, remova a instância Amazon Managed Grafana que você configurou para se conectar ao AMS.