Como soluciono problemas de falhas na verificação de status da minha instância Linux do EC2?
Minha instância Linux do Amazon Elastic Compute Cloud (Amazon EC2) está inacessível e falha nas verificações de status.
Breve descrição
O Amazon EC2 usa três verificações de status para monitorar a integridade das instâncias do EC2.
Verificação do status do sistema
A verificação do status do sistema detecta problemas com o hardware subjacente de uma instância. Se o hardware subjacente não responder ou estiver inacessível devido a problemas de rede, hardware ou software, a verificação do status do sistema falhará.
Verificação do status da instância
A verificação do status da instância falha quando não é possível acessar a instância. As verificações de status da instância podem falhar pelos seguintes motivos:
- O sistema operacional (SO) falha ao inicializar
- Os volumes do Amazon Elastic Block Store (Amazon EBS) não são montados corretamente
- A CPU e a memória estão esgotadas
- Pânico de Kernel
- Falha na rede
- Controle de utilização dos parâmetros de volume raiz do EBS
Verificações de status do EBS anexadas
As verificações de status do EBS anexadas monitoram se os volumes do EBS anexados a uma instância estão acessíveis e podem concluir as operações de E/S. Para obter mais informações, consulte Verificações de status do EBS anexadas.
Resolução
Para ver se a verificação do status da instância ou do sistema falhou, consulte as métricas da verificação do status da instância.
Se a verificação do status do sistema falhar, consulte Por que minha instância Linux do EC2 falhou na verificação do status do sistema?
Se a verificação do status da instância falhar, verifique os logs do sistema da instância para determinar a causa da falha. Em seguida, escolha uma das seguintes opções de resolução para resolver o problema.
Importante: Algumas das resoluções a seguir exigem que você pare e inicie uma instância. Os dados em um volume de armazenamento de instâncias são perdidos quando você interrompe a instância. Se sua instância não tiver volumes suportados pelo EBS, faça backup de seus dados antes de interromper a instância. Além disso, o endereço IPv4 público da sua instância pode mudar depois que você para e inicia a instância. Para reter o mesmo endereço IPv4 público, use um endereço IP elástico. Para obter mais informações, consulte Início e interrupção de instâncias do Amazon EC2.
O SO falha ao inicializar
Se os logs do sistema contiverem erros de inicialização, consulte Como solucionar problemas de uma instância Linux do EC2 que falhou na verificação do status da instância devido a problemas no sistema operacional?
Os volumes do EBS não conseguem ser montados corretamente
Uma falha no ponto de montagem pode fazer com que a verificação do status da instância falhe.
Exemplo de saída de falha no ponto de montagem:
[FAILED] Failed to mount / See 'systemctl status mnt-nvme0n1p1.mount' for details. [DEPEND] Dependency failed for Local File Systems.
Para obter mais informações sobre esses erros, consulte Por que minha instância Linux do EC2 entra no modo de emergência quando tento inicializá-la? Além disso, consulte Como soluciono problemas de uma instância Linux do EC2 que falhou na verificação de status da instância devido a problemas no sistema operacional?
Quando você altera um tipo de instância de uma instância baseada em Xen para uma instância baseada em Nitro, a montagem do volume pode falhar. A falha na montagem ocorre porque os volumes do EBS são expostos como dispositivos de blocos NVMe em instâncias baseadas no Nitro. Por exemplo, os nomes dos dispositivos são /dev/nvme0n1 e /dev/nvme1n1. Os nomes de dispositivos que você especifica em um mapeamento de dispositivos de blocos são renomeados para nomes de dispositivos NVMe. Por exemplo, /dev/nvme[0-26]n1.
Observação: O driver do dispositivo de blocos pode atribuir os nomes dos dispositivos NVMe em uma ordem diferente da que você especifica no mapeamento de dispositivos de blocos. Para evitar falhas de montagem em instâncias baseadas no Nitro, é uma prática recomendada usar um rótulo ou um UUID para nomes de dispositivos. Para obter mais informações, consulte Disponibilizar um volume do Amazon EBS para uso.
A CPU e a memória estão esgotadas
Alta utilização da CPU
Se a métrica CPUUtilization estiver em ou perto de 100%, a instância não terá capacidade computacional suficiente para executar o kernel.
Para instâncias T2 ou T3, verifique as Métricas de crédito de CPU do Amazon CloudWatch para ver se os créditos de CPU estão em ou perto de zero. Se os créditos de CPU estiverem em zero, a métrica CPUUtilization mostrará um platô de saturação na performance de linha de base da instância. Por exemplo, o desempenho básico pode ser de 20% ou 40%. Se a utilização da CPU estiver em ou perto de 100%, ou se as instâncias T2 ou T3 tiverem atingido um patamar de saturação, a verificação de status mostrará falha devido à utilização excessiva de recursos.
Para solucionar esse problema, consulte Como soluciono problemas de uma instância Linux do EC2 que falha em uma verificação de status devido à utilização excessiva de recursos?
Erros de dispositivo de blocos, bugs de software ou pânico no kernel podem causar um pico incomum de uso da CPU. Se a utilização da CPU estiver em 100%, verifique os logs do sistema em busca de erros no dispositivo de blocos ou problemas de memória ou outros erros incomuns do sistema. Em seguida, reinicie ou pare e inicie a instância.
Sem memória
A alta pressão da memória pode causar uma falha na verificação do status da instância. No exemplo de extração de log a seguir, o SO está sem memória e o OOM-killer é iniciado. Para resolver esse erro, interrompa o processo que consome mais memória.
[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child [115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB
Por padrão, a memória da instância do EC2 e as métricas de disco não são enviadas ao CloudWatch. Para obter mais informações, consulte Colete métricas, logs e rastreamentos com o agente CloudWatch.
Para solucionar o problema de falta de memória, faça um upgrade na instância para um tipo maior de instância. Ou adicione armazenamento de troca à instância para aliviar a pressão da memória. Para obter mais informações, consulte Como alocar memória para funcionar como um arquivo de troca em uma instância do Amazon EC2? Além disso, consulte Como faço para usar uma partição no meu disco rígido para alocar memória para funcionar como espaço de troca em uma instância do Amazon EC2?
Erros de disco cheio
Se os logs do sistema contiverem erros de disco cheio, a instância estará no modo de emergência devido ao dispositivo raiz cheio.
Exemplo de log do sistema:
$: sudo service apache2 restart Error: No space left on device $: sudo /etc/init.d/mysql restart [....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device $: df -h / Filesystem Size Used Avail Use% Mounted on /dev/root 7.7G 7.7G 0 100% /
Para obter mais informações, consulte Como soluciono problemas de uma instância Linux do EC2 que falha em uma verificação de status devido à utilização excessiva de recursos? Além disso, consulte Como aumento o tamanho do volume do EBS ao receber um erro de que não há espaço disponível no meu sistema de arquivos?
Pânico de Kernel
O pânico de kernel ocorre quando o kernel detecta um erro fatal interno durante a operação. Se o kernel não carregar corretamente, o erro ocorrerá durante a inicialização do SO. Uma falha no carregamento do kernel faz com que a inicialização da instância falhe.
Exemplo de saída de erro de pânico de kernel:
Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007 Kernel command line: root=/dev/sda1 ro 4 Registering block device major 8 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
Para obter mais informações, consulte Como resolvo o erro “Kernel panic - not syncing” na minha instância do EC2? Além disso, consulte Como faço para reverter para um kernel estável conhecido depois que uma atualização bloqueia a reinicialização da minha instância do EC2?
Falha na rede
Sua rede pode falhar pelos motivos a seguir:
- O pacote cloud-init não está instalado na instância.
- O pacote cloud-init é usado para atualizar as configurações de rede na inicialização.
Para corrigir esse erro e instalar o pacote cloud-init na sua instância, execute o comando a seguir no seu terminal.
Amazon, Amazon Linux 2, Amazon Linux 2023 ou RedHat SO:
sudo yum install cloud-init -y
SO Ubuntu ou Debian:
sudo apt install cloud-init -y
O endereço MAC é codificado em um arquivo de configuração
Endereços MAC codificados estão nos arquivos de configuração do Linux e nos arquivos de configuração udev. É possível encontrar esses arquivos nos locais a seguir:
- /etc/udev/rules.d/
- /etc/udev/rules.d/70-persistent-net.rules
- /etc/udev/rules.d/80-net-name-slot.rules
Para resolver problemas de rede causados por um endereço MAC codificado, remova as entradas ou os arquivos de configuração e, em seguida, execute o comando a seguir:
sudo mv /etc/udev/rules.d/70-persistent-net.rules /root/
Depois de mover o arquivo de configuração, reinicie o serviço de rede para garantir que você receba um novo endereço MAC.
O endereço IP está codificado em um arquivo de configuração de rede
Quando você cria uma imagem de máquina da Amazon (AMI) a partir de uma instância com um endereço IP configurado estaticamente, o arquivo de configuração contém um endereço IP codificado. Para corrigir esse erro, defina sua interface de rede para usar DHCP.
Observação: Não é possível atualizar AMIs que já existem. É possível definir a interface de rede para usar o DHCP antes de criar uma nova AMI.
Os drivers de rede ENA ou Intel aprimorados estão ausentes
Para obter mais informações sobre adaptadores de rede elástica (ENAs) ausentes ou drivers de rede aprimorados da Intel, consulte Redes aprimoradas em instâncias do Amazon EC2.
A interface de rede é renomeada automaticamente na inicialização
Para desativar a renomeação previsível da interface de rede, adicione net.ifnames=0 à linha de comando do kernel. Para usar o espaço reservado, você deve ativar a rede aprimorada com ENA e reconstruir ou atualizar o arquivo de configuração grub.
Controle de utilização dos parâmetros de volume raiz do EBS
Quando os parâmetros do volume raiz do EBS são limitados, a instância pode falhar nas verificações de status porque fica inacessível e sem resposta.
O controle de utilização pode ocorrer quando as operações de E/S por segundo (IOPS) ou o throughput de um volume EBS excedem os limites já provisionados. A instância pode ficar sem resposta ou inacessível devido à degradação do desempenho causada pelo controle de utilização de volume do EBS.
Para resolver problemas de controle de utilização de volume do EBS, conclua as seguintes etapas:
- Monitore e analise as CloudWatch Metrics, como tamanho da fila de volume, operações de leitura/gravação de volume e bytes de leitura/gravação de volume. Para obter mais informações, consulte Como usar as métricas do CloudWatch para calcular o throughput médio e o número médio de IOPS fornecido pelo meu volume do EBS?
- Pare e inicie a instância ou reinicie a instância para resolver temporariamente o problema.
- Provisione mais IOPS ou throughput para o volume EBS. Ou faça o upgrade para um tipo e tamanho de volume do EBS mais adequados para o seu workload. Para obter mais informações, consulte Solicitar modificações de volume do Amazon EBS.
Informações relacionadas
Solucione problemas de instâncias Linux do Amazon EC2 com falhas nas verificações de status
Por que minha instância do Windows no EC2 está inativa com uma falha na verificação da instância?
Conteúdo relevante
- feita há um mês
- feita há 2 meses
- feita há 7 meses
- feita há 5 meses
