Enviar uma interrupção para diagnóstico (para usuários avançados) - Amazon Elastic Compute Cloud
Tipos de instâncias compatíveisPré-requisitosEnviar uma interrupção para diagnóstico

Enviar uma interrupção para diagnóstico (para usuários avançados)

Atenção

As interrupções de diagnóstico são destinadas ao uso de usuários avançados. O uso incorreto pode ter um impacto negativo sobre sua instância. Enviar uma interrupção de diagnóstico para uma instância pode acionar uma instância para travar e reinicializar, o que pode levar à perda de dados.

É possível enviar uma interrupção para diagnóstico a uma instância do Linux inacessível ou sem resposta para acionar manualmente um pânico de kernel.

Os sistemas operacionais Linux normalmente falham e reinicializam quando ocorre um pânico de kernel. O comportamento específico do sistema operacional depende de sua configuração. Um pânico de kernel também pode ser usado para fazer com que o kernel do sistema operacional da instância execute tarefas, como a geração de um arquivo de despejo de falha. É possível usar as informações no arquivo de despejo da falha para conduzir uma análise de causa raiz e depurar a instância.

Os dados do despejo da falha são gerados localmente pelo sistema operacional na própria instância.

Antes de enviar uma interrupção de diagnóstico para sua instância, recomendamos que você consulte a documentação do seu sistema operacional e, em seguida, faça as alterações de configuração necessárias.

Tipos de instâncias compatíveis

A interrupção do diagnóstico é compatível com todos os tipos de instância baseadas em Nitro, exceto as que são ativadas pelos processadores AWS Graviton. Para obter mais informações, consulte Instances built on the AWS Nitro System e AWS Graviton.

Pré-requisitos

Antes de usar uma interrupção para diagnóstico, configure o sistema operacional da instância. Isso garante que ele desempenhe as funções necessárias quando ocorrer um pânico de kernel.

Para configurar o Amazon Linux 2 para gerar um despejo de falha quando ocorrer um pânico de kernel

  1. Conecte-se à sua instância.

  2. Instale kexec e kdump.

    [ec2-user ~]$ sudo yum install kexec-tools -y

  3. Configure o kernel para reservar uma quantidade de memória para o kernel secundário. A quantidade de memória a ser reservada depende da memória disponível total de sua instância. Abra o arquivo /etc/default/grub usando o editor de texto de sua preferência, localize a linha que começa com GRUB_CMDLINE_LINUX_DEFAULT e adicione o parâmetro crashkernel no seguinte formato: crashkernel=memory_to_reserve. Por exemplo, para reservar 160MB, modifique o arquivo grub da seguinte forma:

    GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=160M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
GRUB_TIMEOUT=0
GRUB_DISABLE_RECOVERY="true"

  4. Salve as alterações e feche o arquivo grub.

  5. Recompile o arquivo de configuração do GRUB2.

    [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  6. Em instâncias com base em processadores Intel e AMD, o comando send-diagnostic-interrupt envia uma interrupção não mascarável (NMI - non-maskable interrupt) desconhecida para a instância. É necessário configurar o kernel para falhar quando receber a NMI desconhecida. Abra o arquivo /etc/sysctl.conf usando o editor de texto de sua preferência e adicione o seguinte.

    kernel.unknown_nmi_panic=1

  7. Reinicialize e reconecte-se a sua instância.

  8. Verifique se o kernel foi inicializado com o parâmetro crashkernel correto.

    $ grep crashkernel /proc/cmdline

    A saída do seguinte exemplo indica uma configuração bem-sucedida.

    BOOT_IMAGE=/boot/vmlinuz-4.14.128-112.105.amzn2.x86_64 root=UUID=a1e1011e-e38f-408e-878b-fed395b47ad6 ro crashkernel=160M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0

  9. Verifique se o serviço kdump está em execução.

    [ec2-user ~]$ systemctl status kdump.service

    A saída do seguinte exemplo mostrará o resultado se o kdump estiver em execução.

    kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since Fri 2019-05-24 23:29:13 UTC; 22s ago
  Process: 2503 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 2503 (code=exited, status=0/SUCCESS)
nota

Por padrão, o arquivo de dump da falha é salvo em /var/crash/. Para alterar o local, modifique o arquivo /etc/kdump.conf usando o editor de texto de sua preferência.

Para configurar o Amazon Linux para gerar um despejo de falha quando ocorrer um pânico de kernel

  1. Conecte-se à sua instância.

  2. Instale kexec e kdump.

    [ec2-user ~]$ sudo yum install kexec-tools -y

  3. Configure o kernel para reservar uma quantidade de memória para o kernel secundário. A quantidade de memória a ser reservada depende da memória disponível total de sua instância.

    $ sudo grubby --args="crashkernel=memory_to_reserve" --update-kernel=ALL

    Por exemplo, para reservar 160MB para o kernel de falha, use o seguinte comando. 

    $ sudo grubby --args="crashkernel=160M" --update-kernel=ALL

  4. Em instâncias com base em processadores Intel e AMD, o comando send-diagnostic-interrupt envia uma interrupção não mascarável (NMI - non-maskable interrupt) desconhecida para a instância. É necessário configurar o kernel para falhar quando receber a NMI desconhecida. Abra o arquivo /etc/sysctl.conf usando o editor de texto de sua preferência e adicione o seguinte.

    kernel.unknown_nmi_panic=1

  5. Reinicialize e reconecte-se a sua instância.

  6. Verifique se o kernel foi inicializado com o parâmetro crashkernel correto.

    $ grep crashkernel /proc/cmdline

    A saída do seguinte exemplo indica uma configuração bem-sucedida.

    root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295 LANG=en_US.UTF-8 KEYTABLE=us crashkernel=160M

  7. Verifique se o serviço kdump está em execução.

    [ec2-user ~]$ sudo service kdump status

    Se o serviço estiver em execução, o comando retornará a resposta Kdump is operational.

nota

Por padrão, o arquivo de dump da falha é salvo em /var/crash/. Para alterar o local, modifique o arquivo /etc/kdump.conf usando o editor de texto de sua preferência.

Para configurar o SUSE Linux Enterprise, o Ubuntu ou o Red Hat Enterprise Linux

Em instâncias com base em processadores Intel e AMD, o comando send-diagnostic-interrupt envia uma interrupção não mascarável (NMI - non-maskable interrupt) desconhecida para a instância. É necessário configurar o kernel para falhar quando ele receber a NMI desconhecida. Para fazer isso, ajuste o arquivo de configuração para o seu sistema operacional. Para obter mais informações sobre como configurar o kernel para falhar, consulte a documentação do sistema operacional.

Enviar uma interrupção para diagnóstico

Depois de concluir as alterações necessárias na configuração, é possível enviar uma interrupção de diagnóstico para a instância usando a AWS CLI ou a API do Amazon EC2.

Para enviar uma interrupção para diagnóstico para sua instância (AWS CLI)

Use o comando send-diagnostic-interrupt e especifique o ID da instância.

aws ec2 send-diagnostic-interrupt --instance-id i-1234567890abcdef0