Senden Sie einen Diagnose-Interrupt, um eine nicht erreichbare Amazon-Instance zu debuggen EC2 - Amazon Elastic Compute Cloud
Unterstützte Instance-TypenVoraussetzungenSenden eines Diagnose-Interrupts

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Senden Sie einen Diagnose-Interrupt, um eine nicht erreichbare Amazon-Instance zu debuggen EC2

Warnung

Diagnose-Interrupts sind für fortgeschrittene Benutzer vorgesehen. Eine falsche Verwendung kann sich negativ auf Ihre Instance auswirken. Das Senden eines Diagnose-Interrupts an eine Instance kann zum Absturz und Neustart einer Instance führen, was unter Umständen den Verlust von Daten zur Folge hat.

Sie können einen Diagnose-Interrupt an eine nicht erreichbare oder nicht reagierende Instance senden, um manuell eine Kernel-Panic für eine Linux-Instance oder einen Stop-Fehler (allgemein als Bluescreen-Fehler bezeichnet) für eine Windows-Instance auszulösen.

Linux-Instances

Linux-Betriebssysteme stürzen bei einer Kernel-Panik gewöhnlich ab und werden neu gestartet. Das spezifische Verhalten des Betriebssystems ist von seiner Konfiguration abhängig. Mit einer Kernel-Panik kann das Betriebssystem der Instance auch zum Ausführen von Aufgaben, z. B. Generieren einer Dump-Datei, veranlasst werden. Sie können dann mithilfe der Informationen in der Absturzabbilddatei eine Ursachenanalyse durchführen und die Instance debuggen. Die Absturzabbilddaten werden lokal von dem Betriebssystem auf der Instance selbst erstellt.

Windows-Instances

Im Allgemeinen stürzen Windows-Betriebssysteme ab und werden neu gestartet, wenn ein Abbruchfehler auftritt, das spezifische Verhalten hängt aber von seiner Konfiguration ab. Ein Abbruchfehler kann auch bewirken, dass das Betriebssystem Debugging-Informationen, wie z. B. ein Kernel-Speicherabbild, in einer Datei ausgibt. Sie können anhand dieser Informationen eine Ursachenanalyse durchführen, um die Instance zu debuggen. Die Speicherabbilddaten werden lokal von dem Betriebssystem auf der Instance selbst erstellt.

Bevor Sie ein Diagnose-Interrupt an Ihre Instance senden, empfehlen wir Ihnen, die Dokumentation für Ihr Betriebssystem zu konsultieren und anschließend die erforderlichen Konfigurationsänderungen vorzunehmen.

Unterstützte Instance-Typen

Der Diagnose-Interrupt wird auf allen Nitro-basierten Instance-Typen unterstützt, mit Ausnahme derjenigen, die mit Graviton-Prozessoren betrieben werden. AWS Weitere Informationen finden Sie unter Instances, die auf dem AWS Nitro System und Graviton basieren.AWS

Voraussetzungen

Bevor Sie einen Diagnose-Interrupt verwenden, müssen Sie das Betriebssystem der Instance entsprechend konfigurieren. Dadurch wird sichergestellt, dass es die Aktionen ausführt, die Sie benötigen, wenn ein Kernel-Panic (Linux-Instanzen) oder ein Stop-Fehler (Windows-Instanzen) auftritt.

So konfigurieren Sie Amazon Linux 2 zum Generieren eines Absturzabbildes bei Auftreten einer Kernel-Panik

  1. Verbinden Sie sich mit der Instance.

  2. Installieren Sie kexec und kdump.

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

  3. Konfigurieren Sie den Kernel zum Reservieren einer angemessenen Menge an Arbeitsspeicher für den sekundären Kernel. Die Menge an Arbeitsspeicher ist von dem insgesamt verfügbaren Arbeitsspeicher Ihrer Instance abhängig. Öffnen Sie die Datei /etc/default/grub in Ihrem bevorzugten Texteditor, suchen Sie die Zeile, die mit GRUB_CMDLINE_LINUX_DEFAULT beginnt, und fügen Sie dann den Parameter crashkernel im folgenden Format hinzu: crashkernel=memory_to_reserve. Um beispielsweise 160MB zu reservieren, ändern Sie die Datei grub wie folgt ab:

    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. Speichern Sie Ihre Änderungen und schließen Sie die Datei grub.

  5. Erstellen Sie die GRUB2 Konfigurationsdatei neu.

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

  6. Bei Instances, die auf Intel und AMD Prozessoren basieren, sendet der send-diagnostic-interrupt Befehl einen unbekannten, nicht maskierbaren Interrupt (NMI) an die Instanz. Sie müssen den Kernel so konfigurieren, dass er abstürzt, wenn er das Unbekannte empfängt. NMI Öffnen Sie die Datei /etc/sysctl.conf mit Ihrem bevorzugten Texteditor und fügen Sie Folgendes hinzu.

    kernel.unknown_nmi_panic=1

  7. Starten Sie Ihre Instance neu und richten Sie wieder eine Verbindung zu ihr ein.

  8. Vergewissern Sie sich, dass der Kernel mit dem richtigen crashkernel-Parameter gestartet wurde.

    $ grep crashkernel /proc/cmdline

    Die folgende Beispielausgabe weist auf eine erfolgreiche Konfiguration hin.

    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. Überprüfen Sie, ob der kdump-Service ausgeführt wird.

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

    Die folgende Beispielausgabe zeigt das Ergebnis, wenn der Service kdump derzeit ausgeführt wird.

    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)
Anmerkung

Die Absturzabbilddatei wird standardmäßig in /var/crash/ gespeichert. Um den Speicherort zu ändern, bearbeiten Sie die Datei /etc/kdump.conf mit Ihrem bevorzugten Texteditor.

So konfigurieren Sie Amazon Linux zum Generieren eines Absturzabbildes bei Auftreten einer Kernel-Panik

  1. Verbinden Sie sich mit der Instance.

  2. Installieren Sie kexec und kdump.

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

  3. Konfigurieren Sie den Kernel zum Reservieren einer angemessenen Menge an Arbeitsspeicher für den sekundären Kernel. Die Menge an Arbeitsspeicher ist von dem insgesamt verfügbaren Arbeitsspeicher Ihrer Instance abhängig.

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

    Um beispielsweise 160MB für den Absturzkernel zu reservieren, verwenden Sie den folgenden Befehl. 

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

  4. Bei Instances, die auf Intel und AMD Prozessoren basieren, sendet der send-diagnostic-interrupt Befehl einen unbekannten, nicht maskierbaren Interrupt (NMI) an die Instanz. Sie müssen den Kernel so konfigurieren, dass er abstürzt, wenn er das Unbekannte empfängt. NMI Öffnen Sie die Datei /etc/sysctl.conf mit Ihrem bevorzugten Texteditor und fügen Sie Folgendes hinzu.

    kernel.unknown_nmi_panic=1

  5. Starten Sie Ihre Instance neu und richten Sie wieder eine Verbindung zu ihr ein.

  6. Vergewissern Sie sich, dass der Kernel mit dem richtigen crashkernel-Parameter gestartet wurde.

    $ grep crashkernel /proc/cmdline

    Die folgende Beispielausgabe weist auf eine erfolgreiche Konfiguration hin.

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

  7. Überprüfen Sie, ob der kdump-Service ausgeführt wird.

    [ec2-user ~]$ sudo service kdump status

    Wenn der Service derzeit ausgeführt wird, gibt der Befehl als Antwort Kdump is operational zurück.

Anmerkung

Die Absturzabbilddatei wird standardmäßig in gespeicher /var/crash/. Um den Speicherort zu ändern, bearbeiten Sie die Datei /etc/kdump.conf mit Ihrem bevorzugten Texteditor.

Um SUSE Linux Enterprise, Ubuntu oder Red Hat Enterprise Linux zu konfigurieren

Bei Instances, die auf Intel und AMD Prozessoren basieren, sendet der send-diagnostic-interrupt Befehl einen unbekannten, nicht maskierbaren Interrupt (NMI) an die Instanz. Sie müssen den Kernel so konfigurieren, dass er abstürzt, wenn er Unbekanntes empfängt, NMI indem Sie die Konfigurationsdatei für Ihr Betriebssystem anpassen. Informationen darüber, wie Sie den Kernel so konfigurieren, dass er abstürzt, finden Sie in der Dokumentation Ihres Betriebssystems:

So konfigurieren Sie Windows zum Generieren eines Speicherabbilds bei Auftreten von Abbruchfehlern

  1. Verbinden Sie sich mit der Instance.

  2. Öffnen Sie die Systemsteuerung und wählen Sie System, Erweiterte Systemeinstellungen.

  3. Wählen Sie im Dialogfeld Systemeigenschaften die Registerkarte Erweitert aus.

  4. Wählen Sie im Bereich Startup und Wiederherstellen die Option Einstellungen....

  5. Konfigurieren Sie die Einstellungen im Bereich Systemfehler ganz nach Bedarf und wählen Sie dann OK.

Weitere Informationen zum Konfigurieren von Windows-Abbruchfehlern finden Sie unter Overview of memory dump file options for Windows.

Senden eines Diagnose-Interrupts

Nachdem Sie die erforderlichen Konfigurationsänderungen vorgenommen haben, können Sie mithilfe von AWS CLI oder Amazon EC2 API einen Diagnose-Interrupt an Ihre Instance senden.

AWS CLI
So senden Sie einen Diagnose-Interrupt an Ihre Instance (AWS CLI)

Verwenden Sie den send-diagnostic-interruptBefehl und geben Sie die Instance-ID an.

aws ec2 send-diagnostic-interrupt --instance-id i-1234567890abcdef0
PowerShell
So senden Sie einen Diagnose-Interrupt an Ihre Instance (AWS Tools for Windows PowerShell)

Verwenden Sie das Send-EC2DiagnosticInterruptCmdlt und geben Sie die Instanz-ID an.

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