Übung 1.1 Reproduzieren und Beheben eines Absturzproblems

Gilt für:   .NET Core 2.1, .NET Core 3.1, .NET 5

In diesem Artikel wird der Prozess der Wiedergabe des .NET Core-Absturzproblems in Linux vorgestellt. In diesem Artikel wird auch erläutert, wie Sie das Nginx-Tool und die Systemprotokolle auf Symptome und Anzeichen des Absturzes überprüfen.

Voraussetzungen

Die Mindestanforderung, diese Problembehandlungslabore zu befolgen, besteht darin, über eine ASP.NET Core-Anwendung zu verfügen, um Leistungsprobleme mit geringer CPU- und hoher CPU-Leistung zu demonstrieren.

Sie finden mehrere Beispielanwendungen, um dieses Ziel im Internet zu erreichen. Sie können beispielsweise das einfache Webapi-Beispiel von Microsoft herunterladen und einrichten, um unerwünschtes Verhalten zu demonstrieren. Sie können auch ASP.NET Core Anwendung als Beispielprojekt verwenden.

Wenn Sie die vorherigen Teile dieser Reihe befolgt haben, sollten Sie das folgende Setup bereit haben:

• Nginx ist so konfiguriert, dass zwei Websites gehostet werden:
  • Der erste lauscht auf Anforderungen mithilfe des hostheaders myfirstwebsite ( http://myfirstwebsite ) und Routinganforderungen an die Demo ASP.NET Core Anwendung, die auf Port 5000 lauscht.
  • Die zweite überwacht Anforderungen mithilfe des hostsamb-Hostheaders ( http://buggyamb ) und Routinganforderungen an die zweite ASP.NET Core Beispielanwendung, die auf Port 5001 lauscht.
• Beide ASP.NET Core Anwendungen sollten als Dienste ausgeführt werden, die automatisch neu gestartet werden, wenn der Server neu gestartet wird oder die Anwendung nicht mehr reagiert.
• Die lokale Linux-Firewall ist aktiviert und so konfiguriert, dass SSH- und HTTP-Datenverkehr zulässig ist.

Hinweis

Wenn Ihr Setup noch nicht bereit ist, wechseln Sie zu"Teil 2 Erstellen und Ausführen ASP.NET Core Apps".

Um diese Übung fortzusetzen, benötigen Sie mindestens eine problematische ASP.NET Core Webanwendung, die hinter Nginx ausgeführt wird.

Ziel dieser Übung

Dieser Artikel ist der erste von zwei Laborteilen. Die Übungsarbeit ist wie folgt unterteilt:

• Teil 1: Sie reproduzieren das Absturzproblem, überprüfen Nginx und Systemprotokolle, um nach den Absturzproblemen und -indikatoren zu suchen, und beheben dann eine Problembehandlung, indem Sie eine Absturzabbilddatei generieren. Schließlich erfassen Sie die vom System generierte Kernabbilddatei aus dem Absturzbericht, der vom Ubuntu-Manager, apport, generiert wird.

• Teil 2:Sie installieren und konfigurieren lldb für die Zusammenarbeit mit einer .NET Core-Debuggererweiterung namens SOS. Außerdem analysieren Sie die Speicherabbilddatei in lldb.

Reproduzieren eines Absturzproblems

Wenn Sie zur Website-URL navigieren http://buggyamb/ und den Link "Problemseiten" auswählen, werden Links zu einigen Problemszenarien angezeigt. Es gibt drei verschiedene Absturzszenarien. In dieser Übung behandeln Sie jedoch nur das dritte Absturzszenario.

Bevor Sie einen Link auswählen, wählen Sie "Erwartete Ergebnisse" aus, und stellen Sie sicher, dass Ihre Anwendung wie erwartet funktioniert. Es sollte eine Ausgabe angezeigt werden, die der folgenden ähnelt.

Die Seite sollte schnell geladen werden (in weniger als einer Sekunde) und eine Liste der Produkte anzeigen.

Um das erste Szenario "Langsame Seite" zu testen, wählen Sie den Link "Langsam" aus. Die Seite zeigt schließlich die gleiche Ausgabe wie die Seite "Erwartete Ergebnisse", wird aber viel langsamer gerendert als erwartet.

Bevor Sie das Absturzproblem reproduzieren, notieren Sie sich die Prozess-ID der Anwendung. Anhand dieser Informationen überprüfen Sie, ob Ihre Anwendung neu gestartet wird. Führen Sie den systemctl status buggyamb.service Befehl aus, um die aktuelle PID abzurufen. In den folgenden Ergebnissen lautet die PID des Prozesses, der den Dienst ausführt, 2255.

Wählen Sie den Link "Absturz 3" aus. Die Seite wird geladen und zeigt die folgende Meldung an:

In dieser Meldung wird der Benutzer aufgefordert, die folgende Frage zu berücksichtigen: Führt diese Seite zum Absturz des Prozesses? Führen Sie denselben systemctl status buggyamb.service Befehl aus, und es sollte dieselbe PID angezeigt werden. Dies weist darauf hin, dass kein Absturz aufgetreten ist.

Wählen Sie "Erwartete Ergebnisse" und dann "Langsam" aus. Obwohl die richtige Seite angezeigt werden sollte, nachdem Sie "Erwartete Ergebnisse" ausgewählt haben, sollte bei Auswahl von Slow die folgende Fehlermeldung generiert werden.

Auch wenn Sie einen anderen Link auf der Webseite auswählen, tritt für kurze Zeit derselbe Fehler auf. Nach 10 bis 15 Sekunden beginnt alles wieder wie erwartet zu reagieren.

Führen Sie erneut aus, um zu überprüfen, ob die PID geändert systemctl status buggyamb.service wird. Dieses Mal sollten Sie feststellen, dass der Prozess angehalten zu sein scheint, da die PID geändert wurde. Im vorherigen Beispiel war die Prozess-PID 2255. Im folgenden Beispiel wird es in 2943 geändert. Offensichtlich hat die Website ihre Zusage zum Absturz des Prozesses erfüllt.

Problembehandlung bei den Schritten der Wiederholung

Hier ist eine Zusammenfassung der Schritte zur Wiederholung:

1. Wählen Sie Absturz 3 aus. Die Seite wird ordnungsgemäß geladen, gibt jedoch eine verwirrende Meldung zurück, die darauf hindeutet, dass der Prozess abstürzt.
2. Wählen Sie "Langsam" aus. Anstelle der Produkttabelle wird die Fehlermeldung "HTTP 502 - Ungültiges Gateway" angezeigt.
3. Nachdem das Problem gestartet wurde, wird keine der Seiten für die nächsten 10 bis 15 Sekunden gerendert.
4. Nach 10 bis 15 Sekunden reagiert die Anwendung richtig.

Die Fehlermeldung "HTTP 502 - Ungültiges Gateway" allein sagt Ihnen nicht viel aus. Es sollte jedoch einen ersten Hinweis geben: Dies ist ein Proxyfehler, und er kann auftreten, wenn ein Proxy nicht mit der Anwendung kommunizieren kann, die hinter dem Proxy ausgeführt wird. Im vorgeschlagenen Setup arbeitet Nginx als Reverseproxy für die ASP.NET Core Anwendung. Daher weist dieser Fehler von Nginx darauf hin, dass die Back-End-Anwendung nicht erreicht werden konnte, wenn eingehende Anforderungen weitergeleitet wurden.

Überprüfen, ob Nginx ordnungsgemäß funktioniert

Bevor Sie fortfahren, sollten Sie überprüfen, ob Nginx ordnungsgemäß funktioniert. Dieser Schritt ist nicht obligatorisch, da Sie wissen, dass die Anwendung abstürzt. Sie können jedoch weiterhin den Status von Nginx überprüfen, indem Sie die Nginx-Protokolle überprüfen. Ähnliche Schritte zur Problembehandlung haben Sie weiter oben im Abschnitt "Installieren und Konfigurieren von Nginx" ausgeführt.

Nginx verfügt über zwei Arten von Protokollen: Zugriffsprotokolle und Fehlerprotokolle. Diese werden im /var/log/nginx/ Ordner gespeichert.

Zugriffsprotokolle sind genau wie IIS-Protokolldateien. Öffnen und untersuchen Sie sie, genau wie im vorherigen Abschnitt. Die Protokolle zeigen keine neuen Informationen außer dem Antwortstatuscode "HTTP 502" an, der bereits während der Navigationsversuche auf den Seiten der Website aufgetreten ist.

Überprüfen Sie die Fehlerprotokolle mithilfe des cat /var/log/nginx/error.log Befehls. Dieses Protokoll ist hilfreicher und übersichtlicher. Es zeigt, dass Nginx die Anforderung verarbeiten konnte, aber die Verbindung zwischen Nginx und der Fehlerhaften Anwendung wurde geschlossen, bevor die endgültige Antwort gesendet wurde.

Dieses Protokoll gibt deutlich an, dass das, was Sie sehen, kein Nginx-Problem ist.

Überprüfen von Systemprotokollen mithilfe des Journalctl-Befehls

Wenn die ASP.NET Core Anwendung abstürzt, sollten die Symptome an einer anderen Stelle angezeigt werden.

Da die Fehlerhafte Anwendung als Systemdienst ausgeführt wird, wird der Vorgang in den Systemprotokolldateien protokolliert. Systemprotokolldateien ähneln Systemereignisprotokollen in Windows. Der Befehl wird zum Anzeigen und Bearbeiten von journalctl systemierten Protokollen verwendet.

Sie können den journalctl Befehl ohne Schalter ausführen, um alle Protokolle anzuzeigen. Die Ausgabe ist jedoch eine große Datei. Es liegt in Ihrem Interesse, zu erfahren, wie Sie den Inhalt filtern. Sie können z. B. den folgenden Befehl ausführen:

journalctl -r --identifier=buggyamb-identifier --since "10 minute ago"

Die folgenden Optionen sind verfügbar:

• -r: Drucken Sie die Protokolle in umgekehrter Reihenfolge, sodass das neueste zuerst aufgeführt wird.
• --identifier: Denken Sie an die SyslogIdentifier=buggyamb-identifier Zeile in der Dienstdatei der Testanwendung. (Sie können dies verwenden, um zu erzwingen, dass in Protokollen nur Einträge angezeigt werden, die für die problematische Anwendung gelten.)
• --since: Zeigt Informationen an, die im angegebenen vorherigen Zeitraum protokolliert wurden. Beispiel: --since "10 minute ago" oder --since "2 hour ago" .

Es gibt mehrere nützliche Optionen für den journalctl Befehl, mit denen Sie die Protokolle filtern können. Um sich mit diesem Befehl vertraut zu machen, empfehlen wir, dass Sie die Hilfeseite aufrufen, indem Sie man journalctl ausführen.

Führen Sie journalctl -r --identifier=buggyamb-identifier --since today -o cat aus. Beachten Sie, dass einige Warnmeldungen generiert werden.

Um die Details anzuzeigen, scrollen Sie mithilfe der Pfeiltasten nach unten. Sie werden eine System.Net.WebException Ausnahme finden.

Wenn Sie die Protokolle genau untersuchen, sehen Sie den Codedateinamen und die Zeilennummer, unter der das Problem aufgetreten ist. In dieser Übung wird davon ausgegangen, dass diese Informationen nicht verfügbar sind. Dies liegt daran, dass Sie in realen Szenarien diese Art von Informationen möglicherweise nicht abrufen können. Daher besteht das Ziel darin, mit der Analyse eines Absturzabbilds fortzufahren, um die Ursache des Absturzes zu ermitteln.

Abrufen einer Zentralen Speicherabbilddatei nach einem Absturz

Rufen Sie einige der wichtigsten Systemverhalten beim Beenden eines Prozesses auf:

• Standardmäßig wird eine Kernabbilddatei generiert.
• Das Kernabbild heißt "Core" und wird im aktuellen Arbeitsordner oder im /var/lib/systemd/coredump Ordner erstellt.

Das Standardverhalten ist zwar, dass das System eine Core-Abbilddatei generiert, diese Einstellung kann jedoch überschrieben /proc/sys/kernel/core_pattern werden, um die resultierende Kernabbilddatei direkt an eine andere Anwendung weiterzuverweisen. Wenn Sie Ubuntu in den vorherigen Teilen dieser Reihe verwendet haben, haben Sie erfahren, dass Apport die Generierung von Kernabbilddateien in Ubuntu verwaltet. Die core_pattern Datei wird überschrieben, um das Kernabbild an den Apport weiterzuleitungen.

Apport verwendet /var/crash den Ordner zum Speichern der Berichtsdateien. Wenn Sie diesen Ordner überprüfen, sollte eine Datei angezeigt werden, die nach einem Absturz bereits generiert wurde.

Dies ist jedoch nicht die Kernabbilddatei. Dies ist eine Berichtsdatei, die mehrere Informationselemente zusammen mit der Abbilddatei enthält. Sie müssen diese Datei entpacken, um die Kernabbilddatei abzurufen.

Erstellen Sie einen Speicherabbildordner unter Ihrem Startordner. Sie werden angewiesen, den Bericht dort zu extrahieren. Der Befehl zum Entpacken der Apport-Berichtsdatei lautet apport-unpack . Führen Sie den folgenden Befehl aus:

sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet

Mit diesem Befehl wird der Ordner "/dumps" erstellt. Der apport-unpack Befehl erstellt den Ordner "/dumps/dotnet". Dies ist das Ergebnis.

Im Ordner "~/dumps/dotnet" sollte die Speicherabbilddatei angezeigt werden. Die Datei heißt "CoreDump" und sollte etwa 191 MB groß sein.

Das Extrahieren der automatisch generierten Kernabbilddatei kann ein umständlicher Prozess sein. In der nächsten Übung werden Sie sehen, dass es einfacher ist, kernabbilddateien mithilfe von createdump zu erfassen.

Nächste Schritte

Übung 1.2 Öffnen und analysieren Sie systemgenerierte Core-Abbilddateien in lldb-Debugger.Sie erfahren, wie Sie diese Speicherabbilddatei im lldb-Debugger öffnen, um eine schnelle Analyse durchzuführen.