Envoyer une interruption de diagnostic pour déboguer une instance Amazon inaccessible EC2

Avertissement

Les interruptions de diagnostic sont destinées à être utilisées par les utilisateurs avancés. Une utilisation incorrecte pourrait avoir un impact négatif sur votre instance. L’envoi d’une interruption de diagnostic à une instance peut déclencher un plantage et un redémarrage d’une instance, ce qui peut entraîner la perte de données.

Vous pouvez envoyer une interruption de diagnostic à une instance inaccessible ou qui ne répond pas pour déclencher manuellement une panique du noyau pour une instance Linux, ou une erreur d'arrêt (communément appelée erreur d'écran bleu) pour une instance Windows.

Instances Linux

Les systèmes d’exploitation Linux tombent généralement en panne et redémarrent en cas de panique de noyau. Le comportement spécifique du système d’exploitation dépend de sa configuration. Vous pouvez aussi utiliser une panique de noyau pour que le noyau système du système d’exploitation de l’instance effectue des tâches telles que la génération d’un fichier de vidage sur incident. Vous pouvez alors utiliser les informations du fichier de vidage sur incident pour effectuer l’analyse de la cause de la panne et le débogage de l’instance. Les données de vidage sur incident sont générées localement par le système d’exploitation sur l’instance elle-même.

instances Windows

En général, les systèmes d’exploitation Windows tombent en panne et redémarrent en cas d’erreur d’arrêt, mais le comportement du système dépend de sa configuration. Une erreur d’arrêt peut également provoquer l’écriture d’informations de débogage dans un fichier par le système d’exploitation (par exemple, vidage mémoire du noyau). Vous pouvez ensuite utiliser ces informations pour effectuer une analyse de la cause racine et déboguer l’instance. Les données de vidage mémoire sont générées localement par le système d’exploitation sur l’instance elle-même.

Avant d’envoyer une interruption de diagnostic à votre instance, nous vous recommandons de consulter la documentation de votre système d’exploitation, puis d’apporter les modifications nécessaires à la configuration.

Types d’instance pris en charge

L'interruption diagnostique est prise en charge sur tous les types d'instances basées sur Nitro, à l'exception de celles alimentées par des processeurs AWS Graviton. Pour plus d'informations, consultez les instances basées sur le système AWS Nitro et AWS Graviton.

Prérequis

Avant d’utiliser une interruption de diagnostic, vous devez configurer le système d’exploitation de votre instance. Cela garantit qu'elle effectue les actions dont vous avez besoin lorsqu'une panique du noyau (instances Linux) ou une erreur d'arrêt (instances Windows) se produit.

Instances Linux

Pour configurer Amazon Linux 2 ou Amazon Linux 2023 afin qu'il génère un fichier de vidage en cas de panique du noyau

1. Connectez-vous à votre instance.

2. Installez kexec et kdump.

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

3. Configurez le noyau afin qu’il réserve une quantité appropriée de mémoire pour le noyau secondaire. La quantité de mémoire à réserver dépend de la quantité de mémoire totale disponible de votre instance. Ouvrez le fichier /etc/default/grub à l’aide de votre éditeur de texte préféré, localisez la ligne commençant par GRUB_CMDLINE_LINUX_DEFAULT, puis ajoutez le paramètre crashkernel au format suivant : crashkernel=memory_to_reserve. Par exemple, pour réserver 256MB, modifiez le fichier grub comme suit :

   GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M 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. Enregistrez les modifications, puis fermez le fichier grub.

5. Reconstruisez le fichier GRUB2 de configuration.

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

6. Sur les instances basées sur les processeurs Intel et AMD, la commande send-diagnostic-interrupt envoie une interruption non masquable (NMI) inconnue à l’instance. Vous devez configurer le noyau pour tomber en panne lorsqu’il reçoit l’interruption NMI inconnue. Ouvrez le fichier /etc/sysctl.conf à l’aide de l’éditeur de texte de votre choix et ajoutez ce qui suit.

   kernel.unknown_nmi_panic=1

7. Redémarrez votre instance et reconnectez-la.

8. Vérifiez que le noyau a été démarré avec le paramètre crashkernel correct.

   $ grep crashkernel /proc/cmdline

   L’exemple de sortie suivant illustre une configuration réussie.

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

9. Vérifiez que le service kdump est en cours d’exécution.

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

   L’exemple de sortie suivant présente le résultat lorsque le service kdump est en cours d’exécution.

   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)

Note

Par défaut, le fichier de vidage sur incident est enregistré dans /var/crash/. Pour modifier cet emplacement, modifiez le fichier /etc/kdump.conf à l’aide de l’éditeur de texte de votre choix.

Pour configurer SUSE Linux Enterprise, Ubuntu ou Red Hat Enterprise Linux

Sur les instances basées sur les processeurs Intel et AMD, la commande send-diagnostic-interrupt envoie une interruption non masquable (NMI) inconnue à l’instance. Vous devez configurer le noyau de manière à ce qu'il se ferme lorsqu'il reçoit une NMI inconnue en ajustant le fichier de configuration de votre système d'exploitation. Pour savoir comment configurer le noyau pour qu'il se ferme, consultez la documentation de votre système d'exploitation :

• SUSE Linux Enterprise

• Ubuntu

• Red Hat Enterprise Linux (RHEL) 

Instances Linux

Pour configurer Amazon Linux 2 ou Amazon Linux 2023 afin qu'il génère un fichier de vidage en cas de panique du noyau

1. Connectez-vous à votre instance.

2. Installez kexec et kdump.

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

3. Configurez le noyau afin qu’il réserve une quantité appropriée de mémoire pour le noyau secondaire. La quantité de mémoire à réserver dépend de la quantité de mémoire totale disponible de votre instance. Ouvrez le fichier /etc/default/grub à l’aide de votre éditeur de texte préféré, localisez la ligne commençant par GRUB_CMDLINE_LINUX_DEFAULT, puis ajoutez le paramètre crashkernel au format suivant : crashkernel=memory_to_reserve. Par exemple, pour réserver 256MB, modifiez le fichier grub comme suit :

   GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M 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. Enregistrez les modifications, puis fermez le fichier grub.

5. Reconstruisez le fichier GRUB2 de configuration.

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

6. Sur les instances basées sur les processeurs Intel et AMD, la commande send-diagnostic-interrupt envoie une interruption non masquable (NMI) inconnue à l’instance. Vous devez configurer le noyau pour tomber en panne lorsqu’il reçoit l’interruption NMI inconnue. Ouvrez le fichier /etc/sysctl.conf à l’aide de l’éditeur de texte de votre choix et ajoutez ce qui suit.

   kernel.unknown_nmi_panic=1

7. Redémarrez votre instance et reconnectez-la.

8. Vérifiez que le noyau a été démarré avec le paramètre crashkernel correct.

   $ grep crashkernel /proc/cmdline

   L’exemple de sortie suivant illustre une configuration réussie.

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

9. Vérifiez que le service kdump est en cours d’exécution.

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

   L’exemple de sortie suivant présente le résultat lorsque le service kdump est en cours d’exécution.

   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)

Note

Par défaut, le fichier de vidage sur incident est enregistré dans /var/crash/. Pour modifier cet emplacement, modifiez le fichier /etc/kdump.conf à l’aide de l’éditeur de texte de votre choix.

Pour configurer SUSE Linux Enterprise, Ubuntu ou Red Hat Enterprise Linux

Sur les instances basées sur les processeurs Intel et AMD, la commande send-diagnostic-interrupt envoie une interruption non masquable (NMI) inconnue à l’instance. Vous devez configurer le noyau de manière à ce qu'il se ferme lorsqu'il reçoit une NMI inconnue en ajustant le fichier de configuration de votre système d'exploitation. Pour savoir comment configurer le noyau pour qu'il se ferme, consultez la documentation de votre système d'exploitation :

• SUSE Linux Enterprise

• Ubuntu

• Red Hat Enterprise Linux (RHEL) 

instances Windows

Pour configurer Windows afin qu’il génère un vidage mémoire en d’erreur d’arrêt

1. Connectez-vous à votre instance.

2. Ouvrez le Panneau de configuration, choisissez Système, Paramètres système avancés.

3. Dans la boîte de dialogue Propriétés, choisissez l’onglet Paramètres système avancés.

4. Dans la section Démarrage et récupération, choisissez Paramètres....

5. Dans la section System failure (Échec système), configurez les paramètres comme vous le souhaitez, puis choisissez OK.

Pour plus d’informations sur la configuration des erreurs d’arrêt de Windows, veuillez consulter Overview of memory dump file options for Windows.

instances Windows

Pour configurer Windows afin qu’il génère un vidage mémoire en d’erreur d’arrêt

1. Connectez-vous à votre instance.

2. Ouvrez le Panneau de configuration, choisissez Système, Paramètres système avancés.

3. Dans la boîte de dialogue Propriétés, choisissez l’onglet Paramètres système avancés.

4. Dans la section Démarrage et récupération, choisissez Paramètres....

5. Dans la section System failure (Échec système), configurez les paramètres comme vous le souhaitez, puis choisissez OK.

Pour plus d’informations sur la configuration des erreurs d’arrêt de Windows, veuillez consulter Overview of memory dump file options for Windows.

Envoi d’une interruption de diagnostic

Une fois que vous avez effectué les modifications de configuration nécessaires, vous pouvez envoyer une interruption de diagnostic à votre instance à l'aide de l' EC2 API Amazon AWS CLI ou de l'API Amazon.

AWS CLI

Pour envoyer une interruption de diagnostic à votre instance (AWS CLI)

Utilisez la commande send-diagnostic-interrupt et spécifiez l’ID de l’instance.

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

PowerShell

Pour envoyer une interruption de diagnostic à votre instance (AWS Tools for Windows PowerShell)

Utilisez le Send-EC2DiagnosticInterruptcmdlt et spécifiez l'ID de l'instance.

PS C:\> Send-EC2DiagnosticInterrupt -InstanceId i-1234567890abcdef0