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.
# Envoyez une interruption de diagnostic pour débuguer une instance Amazon EC2 inaccessible
**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.
**Topics**
+ [Types d’instance pris en charge](#diagnostic-interrupt-instances)
+ [Conditions préalables](#diagnostic-interrupt-prereqs)
+ [Envoi d’une interruption de diagnostic](#diagnostic-interrupt-use)
## 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](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) et [AWS Graviton](https://aws.amazon.com/ec2/graviton/).
## Conditions préalables
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.
1. Installez **kexec** et **kdump**.
```
[ec2-user ~]$ sudo yum install kexec-tools -y
```
1. 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"
```
1. Enregistrez les modifications, puis fermez le fichier `grub`.
1. Reconstruisez le fichier GRUB2 de configuration.
```
[ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```
1. 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
```
1. Redémarrez votre instance et reconnectez-la.
1. 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
```
1. 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](https://www.suse.com/support/kb/doc/?id=3374462)
+ [Ubuntu](https://ubuntu.com/server/docs/kernel-crash-dump)
+ [Red Hat Enterprise Linux (RHEL) ](https://access.redhat.com/solutions/6038)
### 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.
1. Ouvrez le **Panneau de configuration**, choisissez **Système**, **Paramètres système avancés**.
1. Dans la boîte de dialogue **Propriétés**, choisissez l’onglet **Paramètres système avancés**.
1. Dans la section **Démarrage et récupération**, choisissez **Paramètres...**.
1. 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](https://support.microsoft.com/en-us/help/254649/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**
Utilisez la commande [send-diagnostic-interrupt](https://docs.aws.amazon.com/cli/latest/reference/ec2/send-diagnostic-interrupt.html).
```
aws ec2 send-diagnostic-interrupt --instance-id i-1234567890abcdef0
```
------
#### [ PowerShell ]
**Pour envoyer une interruption de diagnostic à votre instance**
Utilisez l’applet de commande [Send-EC2DiagnosticInterrupt](https://docs.aws.amazon.com/powershell/latest/reference/items/Send-EC2DiagnosticInterrupt.html).
```
Send-EC2DiagnosticInterrupt -InstanceId i-1234567890abcdef0
```
------