Por que minha instância Linux do EC2 está inacessível e falhando em suas 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

Uma falha na verificação do status da instância indica que a instância está inalcançável. Os seguintes problemas podem causar uma falha na verificação do status da instância:

• Falha ao inicializar o sistema operacional (OS).
• Falha na montagem correta dos volumes.
• CPU e memória esgotadas.
• Pânico de kernel.
• Falha na rede.

Aviso: algumas das resoluções a seguir exigem a parada e o início da instância. Antes de interromper e iniciar sua instância, observe estas condições:

• Os dados armazenados em volumes de armazenamento de instâncias são perdidos quando a instância é interrompida. Antes de interromper a instância, certifique-se de fazer backup dos dados. Diferentemente dos volumes baseados no Amazon Elastic Block Store (Amazon EBS), os volumes de armazenamento de instância não oferecem suporte à persistência de dados.
• O endereço público IPv4 estático que o Amazon EC2 atribuiu automaticamente à instância na inicialização ou no início muda após a interrupção e o início. Para manter um endereço IPv4 público que não muda quando a instância é interrompida, use um endereço IP elástico.

Para obter mais informações, consulte Início e interrupção de instâncias do Amazon EC2.

Verificações de status do EBS anexadas

As verificações de status do EBS anexado monitoram se os volumes do Amazon EBS vinculados a uma instância estão acessíveis e capazes de concluir 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, use uma das resoluções a seguir para resolver o problema.

Falha ao inicializar o sistema operacional

Se os registros 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?

Falha na montagem correta dos volumes

Uma falha no ponto de montagem pode fazer com que a verificação do status da instância falhe. Exemplo de comando para 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, consulte os seguintes artigos do Centro de conhecimentos da AWS:

• Erros de "Falha na dependência": Por que minha instância Linux do EC2 está entrando no modo de emergência quando tento inicializá-la?
• Erros "Falha ao montar" ou "Falha na dependência": 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?

Quando você altera um tipo de instância baseada em Xen para uma instância baseada em Nitro, a montagem do volume pode falhar. A falha de montagem ocorre porque os volumes do Amazon EBS ficam expostos como dispositivos de bloco NVMe em instâncias baseadas em 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 (/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 especificada 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.

CPU e memória 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 UPC 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%. A utilização da CPU em ou perto de 100% mostra que a verificação de status falhou devido à utilização excessiva de recursos. As instâncias T2 ou T3 que atingiram um patamar de saturação mostram que a verificação de status falhou devido à utilização excessiva.

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 dispositivos 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%, primeiro 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 sistema operacional está sem memória e o oom-killer foi 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 Amazon 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, atualize a instância para um tipo de instância maior. Ou adicione armazenamento de troca à instância para aliviar a pressão da memória. Para obter mais informações, consulte os seguintes artigos do Centro de conhecimentos da AWS:

• Como alocar memória para funcionar como um arquivo de troca em uma instância do Amazon EC2?
• 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 instruções detalhadas sobre como solucionar problemas e resolver erros de disco cheio, consulte os seguintes artigos do Centro de conhecimentos:

• Como soluciono problemas de uma instância Linux do EC2 que falha em uma verificação de status devido à utilização excessiva de recursos?
• Como aumento o tamanho do meu volume do EBS se eu receber um erro indicando 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 erro ocorrer durante a inicialização do sistema operacional, então o kernel não foi carregado corretamente. Essa falha no carregamento do kernel causa uma falha na inicialização da instância.

Exemplo de mensagem 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 informações sobre como solucionar problemas e resolver um erro de pânico de kernel, consulte os seguintes artigos do Centro de conhecimentos:

• Como corrigir um erro “Kernel panic - not sync” em instâncias do EC2?
• Como reverto para um kernel estável conhecido depois que uma atualização evita que minha instância do Amazon EC2 reinicie com sucesso?

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:

Para os sistemas operacionais Amazon, Amazon Linux 2, Amazon Linux 2023 ou RedHat:

$ sudo yum install cloud-init -y

Para sistemas operacionais 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/

Após mover o arquivo de configuração, reinicie o serviço de rede para garantir que um novo endereço MAC seja recebido.

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.

Informações relacionadas

Solucione problemas de instâncias Linux do Amazon EC2 com falhas nas verificações de status

Por que minha instância Windows do EC2 está inativa com uma falha na verificação do status do sistema ou na verificação de status 0/2?

Por que minha instância do Windows no EC2 está inativa com uma falha na verificação da instância?

Tipos de verificações de status