Envoi d’une interruption de diagnostic (utilisateurs avancés uniquement) - Amazon Elastic Compute Cloud

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Envoi d’une interruption de diagnostic (utilisateurs avancés uniquement)

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 ne répondant pas pour déclencher manuellement une panique au niveau 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'il exécute les actions dont vous avez besoin en cas de panique du noyau (instances Linux) ou d'erreur d'arrêt (instances Windows).

Pour configurer Amazon Linux 2 pour générer un vidage sur incident en cas de panique de 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 160MB, modifiez le fichier grub comme suit :

    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. Enregistrez les modifications, puis fermez le fichier grub.

  5. Générez à nouveau le fichier de configuration GRUB2.

    [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=160M 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 Amazon Linux pour générer un vidage sur incident en cas de panique de 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.

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

    Par exemple, pour réserver 160MB pour le noyau d’incident, utilisez la commande qui suit.

    $ sudo grubby --args="crashkernel=160M" --update-kernel=ALL
  4. 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
  5. Redémarrez votre instance et reconnectez-la.

  6. 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.

    root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295 LANG=en_US.UTF-8 KEYTABLE=us crashkernel=160M
  7. Vérifiez que le service kdump est en cours d’exécution.

    [ec2-user ~]$ sudo service kdump status

    Si le service est en cours d’exécution, la commande renvoie la réponse Kdump is operational.

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 pour qu'il se bloque lorsqu'il reçoit le NMI inconnu en ajustant le fichier de configuration de votre système d'exploitation. Pour plus d'informations sur la façon de configurer le noyau pour qu'il plante, consultez la documentation de votre système d'exploitation :

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'API Amazon EC2 AWS CLI ou Amazon EC2.

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